Data flow in an InterChange Server Express implementation

A data flow is initiated by either of two types of interactions: publish-and-subscribe interactions or service call interactions. Both types of interaction supply triggers that start the execution of a collaboration's business processes. The collaboration then uses a third type of interaction--request/response --to complete the exchange of data with the intended destination.

Publish-and-subscribe interactions

Connectors and collaborations use a publish-and-subscribe interaction to move information about application events into the IBM WebSphere Business Integration Server Express for processing.

In the publish-and-subscribe interaction, a collaboration begins its business process when it is triggered to do so by receipt of a business object for a particular type of triggering event--for example, Employee.Create--that represents an application operation. The name of the business object (Employee) indicates a type of business entity. The verb (Create) indicates an operation that occurred on that entity. Therefore, the Employee.Create event reports the creation of an employee entity.

The publish-and-subscribe interaction enables a triggering event to reach a collaboration as follows:

Depending on the connector, an event can be published to a collaboration either asynchronously or synchronously. In addition, if the long-lived business process feature of the collaboration is enabled, a collaboration can maintain the event in a waiting state, in anticipation of incoming events satisfying pre-defined matching criteria.

Access requests

A collaboration can be designed to be triggered by direct calls that are sent by an access client, received by the Server Access Interface, and sent to the collaboration as business objects. In an InterChange Server Express implementation, calls sent to collaborations through the Server Access Interface are referred to as access requests. Access requests can originate from external sources or from sources that are configured within the InterChange Server Express implementation.

Access request interactions are useful when synchronous communication is important--as when, for example, a customer representative uses a web browser to request inventory status information over the Internet.

Request/response interactions

A collaboration begins processing data when it is triggered to do by receipt of a triggering business object. The triggering business object can be the result of either an access request or an event notification. Once a collaboration has been triggered, it can make requests of connectors to which it has been bound, and receive responses.

The collaboration makes its requests--referred to as service call requests--in the form of generic business objects. The connectors transform the generic business objects into data entities that are understood by the specific application or data format for which the connector is designed.

The responses that the collaboration receives from the connectors--referred to as service call responses--can be business objects containing business data (in the case of retrieve requests) or status reports (successful or unsuccessful).

Figure 3 shows a simplified view of a business process that is initiated through a publish-and-subscribe interaction and completed through request/response interactions. The example shows a distributed business process that automatically generates an invoice when a customer service representative finishes working on a case. In this example, a hypothetical service billing collaboration uses connectors to exchange business data with three different applications.

Figure 3. A publish-and-subscribe, request/response interaction


Figure 3 illustrates the following sequence in the business process:

  1. A customer service representative completes work on a case. The connector detects the case closure as an event in the customer service management application and retrieves the relevant case data. The connector then publishes the event, making it available to a collaboration that has subscribed to it. These actions comprise a publish-and-subscribe interaction.
  2. In order to compute the invoice amount, the collaboration needs the terms of the customer contract. The collaboration sends a service call request to retrieve the necessary data from the connector for the customer records application. The connector responds to the request. These actions comprise a request/response interaction between the collaboration and the customer records application and connector.
  3. Using both the case information and the customer contract, the collaboration produces the information needed to generate an invoice. It sends the invoice creation request to the connector for the accounting application, which forwards the request to the application itself, and responds to the collaboration with a notification of success or failure. These actions comprise a request/response interaction between the collaboration and the accounting application and connector.

A site can tune the closeness with which collaborations and connectors are coupled. The collaboration might, for example, execute on a 24-hour basis, sending requests to a connector that communicates with its application only between midnight and 2:00 A.M. The collaboration could be designed and configured to send the requests without requiring a response and simply process the responses when they come.

Alternatively, a collaboration that has been enabled for long-lived business processes can save the flow context of a request, and send the request with a timeout value, specifying the period of time in which a response can cause the saved processing flow to resume.

Copyright IBM Corp. 2004