How the WebSphere business integration system works

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

Data flow in the business integration system

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:

  1. Event notification
  2. Integration broker processing
  3. Request processing

Each of these is explained in more detail below.

Event notification

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:

  1. The connector framework initiates to the application-specific component to have it check for changes to the application's event store.
  2. The application-specific component polls for changes to the application's event store.
  3. The application-specific component determines whether the changed data maps to a supported business object definition.
  4. The application-specific component instantiates a business object and uses it to retrieve the changed data.
  5. The application-specific component initiates an event delivery to transfer the business object to the connector framework.

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.

Integration broker processing

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.

Request processing

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.

Summary of the business integration process

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.

Example of sending changed data to another application

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:

  1. Connector A's application-specific component detects a change to data in application A. It determines that a business object definition exists for communicating this change and uses the business object definition to construct a business object to carry the changed information.
  2. The application-specific component passes the business object to the connector framework.
  3. The connector framework invokes the data handler to transform the business object into a WebSphere MQ message of the correct XML-based wire format and places the message on a WebSphere MQ queue for the integration broker.
  4. The integration broker receives and processes the message. In a WebSphere Application Server environment, this takes place when an MDB receives the message from the queue and routes it to the appropriate EJB for processing.
  5. After processing the message that originated from the connector for application A, the integration broker places the resulting message on the WebSphere MQ queue for the connector for application B.
  6. Connector B's connector framework removes the message from the queue and calls the data handler to convert it to a business object that can be processed by the application-specific component.
  7. Application B updates its customer information to reflect the change of address.

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.

Example of obtaining data from another application

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.

  1. Connector A's application-specific component detects that application A has requested data from application B. It determines that a business object definition exists for communicating this request and uses the business object definition to construct a business object for the requested information.
  2. The application-specific component passes the business object to the connector framework.
  3. The connector framework invokes the data handler to transform the business object into a WebSphere MQ message of the correct wire format and places the message on a WebSphere MQ queue for the integration broker.
  4. In a WebSphere Application Server environment, an MDB in the integration broker receives the message and invokes an EJB that will process it.
  5. One or more EJBs process the incoming message and then place the resulting outgoing message on the WebSphere MQ queue for the connector for application B.
  6. Connector B's connector framework removes the message from the queue and calls the data handler to convert it to a business object that can be processed by the application-specific component.
  7. Connector B's application-specific component retrieves the information specified in the request and passes it back to the connector framework as a business object.
  8. Connector B's connector framework invokes the data handler to transform the business object to a response message and places it on the reply-to queue specified in the originating request.

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.

Copyright IBM Corp. 1997, 2003