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.
|
