The Java connector library contain an API that allows a
user-defined application-specific component to communicate with an
integration broker through business objects. Applications can
exchange information with other applications that the integration
broker handles.
WebSphere InterChange Server |
If your business integration system uses InterChange Server, the
connector can communicates with other applications through
executing a collaboration. A
collaboration represents a business process that can involve
several applications. A connector transforms data and logic into a
business object that carries information about an event in the
connector's application. The business object triggers a
collaboration business process and provides the collaboration with
information that it needs for the business process.
- Note:
- An external process can also initiate execution of
collaborations through a call-triggered flow. For more information,
see the Access Development Guide in the IBM WebSphere
InterChange Server documentation set.
|
WebSphere Message Brokers |
If your business integration system uses a WebSphere message
broker (WebSphere MQ Integrator, WebSphere MQ Integrator Broker, or
WebSphere Business Integration Message Broker), the connector might
request information from or send information to other applications
through WebSphere MQ workflows. The MQ workflow routes the
information as appropriate.
|
When an event occurs in the application, the connector's
application-specific component creates a business object to
represent this event and sends the event to the integration broker.
An application event is
any event that affects an entity associated with a business object
definition. To send an event to an integration broker, the
connector initiates an event
delivery. This event contains a business object. Therefore, the
flow trigger that a connector initiates is called an
event-triggered flow (see Figure 10).
Figure
10. Event-triggered flow for WebSphere business integration
system

Figure 10 shows
event-triggering flow within the IBM WebSphere business integration
system, which involves the following steps:
- The connector creates the
triggering event, which
it sends to the integration broker during event delivery.
When an event that affects an application entity occurs (such as
when a user of the application creates, updates, or deletes
application data), a connector creates a business object, which
contains data from the application entity and a verb that indicates
the operation performed on this data.
- The application-specific component of the connector calls the
gotApplEvent() method of the Java connector library to
send the triggering event to the connector framework. Through this
method call, the connector performs an event delivery, which
initiates the event-triggered flow.
- The connector framework performs any needed conversion of the
triggering event to a business object, then sends this event to the
integration broker.
WebSphere InterChange Server |
If your business integration system uses InterChange Server, the
connector controller receives the triggering event, performing any
needed mapping of the application-specific business object data to
the appropriate generic business object. The connector controller
then sends the triggering event to the specified collaboration to
trigger its execution. This collaboration is one that has
subscribed to the business object that the event represents. The
collaboration receives this business object in its incoming
port.
|
- The integration broker uses whatever logic it provides to route
the event to the appropriate application. If it is so programmed,
it might perform a request, routing the event information to
the connector of some destination application, which would receive
the event containing its request business object. In addition, this
destination connector might send a request response back to
the integration broker.
WebSphere InterChange Server |
If your business integration system uses InterChange Server, the
collaboration might perform a
service call request to send a business object to the
connector controller of the destination connector, which is bound
to its outgoing port. This connector controller performs any needed
conversion from the resulting generic business object to the
appropriate application-specific business object. It then performs
a service call response
to send the event response to the connector controller, which
routes it back to the collaboration.
|
As Figure 10 shows, a
connector can participate in
one of two roles:
- Event notification--the
connector sends an event (in the form of a business object) to the
integration broker to notify it of some operation that has occurred
in the application.
- Request processing--the
connector receives a request business object from an integration
broker.
Each of these connector roles is described in more detail in the
following sections.
One role of a connector is to detect changes to application
business entities. When an event that affects an application entity
occurs, such as when a user of the application creates, updates, or
deletes application data, a connector sends an event to the
integration broker. This event contains a business object
and a verb. This role is called event notification.
This section provides the following information about event
notification:
A connector assumes that the business integration system uses a
publish-and-subscribe
model to move information from an application to an integration
broker for processing:
- An integration broker subscribes to a business object
that represents an event in an application.
WebSphere InterChange Server |
If your business integration system uses InterChange Server, a
collaboration subscribes
to a business object that represents an event in an application,
and then the collaboration waits.
|
- A connector uses an event-notification mechanism to monitor
when application events occur. When an application event does
occur, the connector publishes a notification of the event
in the form of a business object and a verb. When the integration
broker receives an event in the form of the business object that it
has subscribed to, it can begin the associated business logic on
this data.
WebSphere InterChange Server |
If your business integration system uses InterChange Server, the
connector controller checks its own subscription list when it receives a business object
from the connector framework to determine which any collaborations
have subscribed to this type of business object. If so, it then
forwards the business object to the subscribing collaboration. When
a collaboration receives the subscribed event, it begins
executing.
|
An event-notification mechanism enables a connector to
determine when an entity within an application changes. When an
event occurs in an application, the connector application-specific
component processes the event, retrieves related application data,
and returns the data to the integration broker in an business
object.
- Note:
- This section provides an introduction to event notification.
For more information on how to implement an event-notification
mechanism, see Event
notification.
The following steps outline the tasks of an event-notification
mechanism:
- An application performs an event and puts an event record into
the event store.
The event store is a
persistent cache in the application where event records are saved
until the connector can process them. The event record contains information about the
change to an event store in the application. This information
includes the data that has been created or changed, as well as the
operation (such as create, delete, or update) that has been
performed on the data.
- The connector's application-specific component monitors the
event store, usually through a polling mechanism, to check for
incoming events. When it finds an event, it retrieves its event
record from the event store and converts it into an
application-specific business object with a verb.
- Before sending the business object to the integration broker,
the application-specific component can verify that the integration
broker is interested in receiving the business object.
WebSphere InterChange Server |
If your business integration system uses InterChange Server, the
connector framework does not assume that the integration
broker is always interested in every supported business objects. At
initialization, the connector
framework requests its
subscription list from the connector controller. At runtime, the
application-specific component can query the connector framework to
verify that some collaboration subscribes to a particular business
object. The application-specific connector component can send the
event only if some collaboration is currently subscribed.
The application-specific component sends the event, in the form of
a business object and a verb, to the connector framework, which in
turn sends it to the connector controller within ICS. For more
information, see "Mapping
services".
|
Other integration brokers |
If your business integration system uses a WebSphere message broker (WebSphere MQ Integrator,
WebSphere MQ Integrator Broker, or WebSphere Business Integration
Message Broker) or WebSphere Application Server, the connector
framework assumes that the integration broker is interested in
all the connector's supported business objects. If the
application-specific connector component queries the connector
framework to verify whether to send the business object, it will
receive a confirmation for every business object that the
connector supports.
|
- If the integration broker is interested in the business object,
the connector application-specific component sends the event, in
the form of a business object and a verb, to the connector
framework, which in turn sends it to the integration broker.
Figure 11 illustrates the
components of the event-notification mechanism. In event
notification, the flow of information is from the application to
the connector and then to the integration broker.
Figure
11. Event detection and retrieval

In addition to detecting application events, another role of a
connector is to respond to requests from the integration broker. A
connector receives a request
business object from a integration broker when the broker
requests a change to the connector's application or needs
information from the connector's application. In general,
connectors perform create, retrieve, and update operations on
application data in response to requests from a collaboration.
Depending on the application's policies, the connector might also
support delete operations. This role is called request
processing.
WebSphere InterChange Server |
If your business integration system uses InterChange Server,
request processing can sometimes be called "service call request
processing". The connector receives a business object from its
connector controller, which receives it from a service call of a
collaboration.
|
- Note:
- This section provides an introduction to request processing.
For more information on how to implement request processing in your
connector, see Request processing.
Request processing involves the following steps:
- As Figure 10 shows, an
integration broker initiates request processing by sending a
request to the connector framework. This request is in the form of
a business object, called the
request business object,
and a verb. For more information, see "Initiating a request".
- The connector framework has
the task of determining which business object handler in the
application-specific component should process the request business
object. For more information, see "Choosing a business object
handler".
- The connector framework passes the request business object to
the business object handler defined for it in its business object
definition.
The connector framework does this by calling the doVerbFor() method defined in
the business object class and passing in the request business
object. The business object handler then processes the business
object, converting it to one or more application requests.
- When the business object handler completes the interaction with
the application, it returns a return-status descriptor and possibly
a response business object to the connector framework. For more
information, see "Handling a request
response".
The way a request is initiated depends on the integration broker
in your IBM WebSphere business integration system:
If your business integration system uses InterChange Server, the
collaboration initiates a
service call request,
sending the request over one of its collaboration ports. When you
bind a port of a collaboration object, you associate the port with
a connector (or another collaboration object). Collaboration ports
enable communication between bound entities, so that the
collaboration object can accept the business object that triggers
its business processes, and then send and receive business objects
as service call requests and responses.
- Note:
- For more information on how to define collaboration ports, see
the Collaboration Development Guide. For information
on how to bind ports of a collaboration object, see the
Implementation Guide for WebSphere InterChange Server.
Both these documents are in the IBM WebSphere InterChange Server
documentation set.
One the service call request is initiated, the InterChange
Server system takes the following steps:
- The connector controller for the connector bound to the
collaboration port receives the service call request. If necessary,
the connector controller maps the generic business object to an
application-specific business object before sending the request to
the connector framework.
- The connector controller forwards the service call request to
the connector framework. The connector controller sends the request
business object as a Java object.
If your business integration system uses a WebSphere message
broker (WebSphere MQ Integrator, WebSphere MQ Integrator Broker, or
WebSphere Business Integration Message Broker) or WebSphere
Application Server, the integration broker initiates a request by
sending a message to the WebSphere MQ queue associated with the
connector. One the request is initiated, the connector framework
gets the WebSphere MQ message off using its transport layer and
converts the message to the appropriate business object using a
custom data handler.
For more information on the IBM WebSphere business integration
system and request processing, see the implementation guide for
your integration broker.
A business object
handler is the Java class that is responsible for transforming
the request business object into a request for the appropriate
application operation. An application-specific component includes
one or more business object
handlers to perform tasks for the verbs in the connector's
supported business objects. Depending on the active verb, a
business object handler can insert the data associated with a
business object into an application, update an object, retrieve the
object, delete it, or perform another task.
Based on this response business object's business object
definition, the connector framework obtains the correct business
object handler for the associated business object:
- When the connector starts up, the connector framework receives
from the connector controller the list of business objects
that the connector supports.
- The connector framework
calls the
getConnectorBOHandlerForBO() method (defined in the connector
base class) to instantiate one or more business object
handlers.
- For each supported business object, the
getConnectorBOHandlerForBO() method returns a reference to
a business object handler, and this reference is stored in the
business object definition in the memory of the connector
process.
All conversions between business objects and application
operations take place within the business object handler (or
handlers).
For more information about how to implement the
getConnectorBOHandlerForBO() method, see "Obtaining the business
object handler"..
Once a connector has processed this request and completed the
interaction with the application, it can return a response to the
integration broker.
WebSphere InterChange Server |
If your business integration system uses InterChange Server, the
connector framework returns a
service call response to the collaboration. Using
information in the return-status descriptor, the collaboration can
determine the state of its service call request and take
appropriate actions.
|
Other integration brokers |
If your business integration system uses a WebSphere message
broker (WebSphere MQ Integrator, WebSphere MQ Integrator Broker, or
WebSphere Business Integration Message Broker) or WebSphere
Application Server, the connector framework's response
includes:
- A status indicator, which contains the information
return-status descriptor
- Any business object messages, which contain the optional
response business objects
The connector framework puts this response information onto the
connector's queue. However, for the message transport to be
synchronous (that is, for some program to wait for a response), a
program must post its request message to the integration broker on
a synchronous request queue and expect its response from the broker
on a synchronous response queue. A correlation ID on the response
message identifies the message request to which it is responding.
|
