In the WebSphere business integration system, connectivity for moving data between applications and the integration broker is supplied by connectors using Java Message Service (JMS) over WebSphere MQ queues. A connector can reside on any machine from which it can access the necessary queues and communicate with the application.
Each connector consists of two parts--the connector framework and the application-specific component:
The subcomponents of a connector are shown in Figure 2..
Figure 2. Subcomponents of a connector
Data is exchanged between applications by means of application-specific business objects, which are transported between the connector framework and the integration broker as WebSphere MQ messages (also referred to as business object messages).
Business objects encapsulate and transmit business data for the several purposes. They convey:
Instructions, associated with each piece of data, encoded as metadata, specify the location in the application's database where the data is to be found, created, or updated. New instances of business objects are created by the application-specific component based on templates called business object definitions, which specify the structure and organization of the business object's attributes, values, and metadata.
Because application-specific information and other metadata in the business object definition guide the actions of the application-specific component, such an application-specific component's behavior can be described as metadata-driven. An application-specific component that is metadata-driven is flexible because it has no hard-coded instructions for each type of business object that it supports. Without recoding or recompiling, the application-specific component automatically supports new business object definitions, as long as the corresponding application data can be accurately described by the connector's metadata syntax.
Within the integration broker, WebSphere MQ message flows define the steps in the processing of business object messages by the integration broker. They specify the set of actions, or rules, executed between receipt of the message by the integration broker, and delivery of the message to the destination application.
In the business integration system, data flow--the movement and processing of data sent from one application or entity to another-- can occur either as an asynchronous or a synchronous exchange between applications on a local network.
An application might need to exchange data with another application to communicate changes in its data store or to obtain data.
The exchange of data in the business integration system consists of these steps:
Each of these is explained in more detail below.
The process of conveying changed application data to the integration broker is called event notification. Most applications that participate in the business integration system are modified during the configuration process to include an event store, such as a table for logging the application's data changes and data requests. To detect that an application has newly changed data to share or that it needs information from another application, the connector framework initiates a poll call at periodic intervals. The poll call asks the application-specific component to check for changes to the application's event store.
If there has been a change since the last poll call, the application-specific component determines if a business object definition exists to represent the changed data or the data request. The presence of a suitable business object definition in the connector's local repository is an indicator that this particular change or request needs to be communicated to another application. The application-specific component sends the application data, in the form of a business object, to the connector framework. This is referred to as an event delivery, because a change to an application's data or a request for data is considered an event.
Figure 3 shows a connector and its supporting infrastructure detecting a change to the application's data store and constructing an application-specific business object to convey the changed data to the integration broker.
Figure 3. The connector detecting and delivering an event.
The numbers in the figure show the sequence of steps:
When the connector framework of the source application receives the application-specific business object, it converts the business object to a WebSphere MQ message that can be placed on a WebSphere MQ queue for receipt by the integration broker. A data handler is used by the connector framework to transform the business object into a message in the appropriate XML-based wire format for the destination WebSphere MQ queue. Figure 4 shows this process.
Figure 4. The connector framework transforming a business object into an MQ message.
Once the message is placed on the WebSphere MQ event delivery queue for the integration broker, the integration broker removes the message from the queue, and passes it through the message flow for the queue. Processing might involve:
The resulting message, now called a request, is placed on a
WebSphere MQ request queue to be transferred to the connector framework of the
destination application. Figure 5 illustrates the processing performed by the integration
broker.
Figure 5. Integration broker processing
Once the request has been placed on the queue for the destination connector, a listening mechanism notifies the connector framework that a WebSphere MQ message has arrived on its request queue and needs to be processed. The connector framework invokes the data handler to convert the WebSphere MQ message into a business object that can be processed by the destination application, as shown in Figure 6.
Figure 6. Request processing by the connector.
In some cases, the request might require a response from the destination application. Generally, a response is used to:
If a response is needed, the application-specific component modifies the request business object to carry the information and sends the business object back to the connector framework. The connector framework calls the data handler to convert the business object to a WebSphere MQ message and places the message on the reply-to queue specified in the originating request message. A correlation ID in the response message identifies the message to which it is responding. Figure 7 illustrates how response processing is performed.
Figure 7. Response processing by the connector.
Now that you have learned about each step in the business integration process, you can step back for a look at the system as a whole. Figure 8 shows a summary diagram of the business integration system. Two scenarios, illustrating its operation, are presented below.
Figure 8. Data flow in the WebSphere business integration system.
As an example, here are the steps by which the business integration system enables application A to send changed data to application B for synchronization:
If application A were requesting data from application B instead of notifying it of a data change, application B would need to send a response back to application A. The following example illustrates this scenario.
Here are the steps by which the business integration system enables application A to retrieve information about a customer's most recent purchase from application B.
The chapters that follow describe in more detail the business integration components introduced here and the process by which they enable applications to share data.