In the WebSphere business integration system implemented with WebSphere Application Server, connectivity for moving data between applications and WebSphere Application Server is supplied by connectors using WebSphere MQ as the Java Message Service (JMS) provider. 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 JMS 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 meta-data, 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 meta-data.
Because application-specific information and other meta-data in the business object definition guide the actions of the application-specific component, such an application-specific component's behavior can be described as meta-data-driven. An application-specific component that is meta-data-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 meta-data syntax.
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, either on a local network or across the Internet.
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.
After the message is placed on the WebSphere MQ event delivery queue for the integration broker, the integration broker removes the message for processing. In a WebSphere Application Server environment, this task, and the processing that follows, are performed by J2EE components that have been created using WebSphere Studio Application Developer, Integration Edition. Messages picked up from the queue are handled by MDBs and processed by EJBs.
The processing in the integration broker produces a message that is to be sent to the destination application. The message, called a request (or HubRequest in an WebSphere Application Server environment), is placed on a WebSphere MQ request queue to be transferred to the connector framework of the destination application.
Once the request has been placed on the queue for the destination connector, a listening mechanism notifies the connector framework of the destination application's adapter 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 5.
Figure 5. 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 6 illustrates how response processing is performed.
Figure 6. 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. Two scenarios are presented below.
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.