Data flow in an InterChange Server implementation

In an InterChange Server implementation, a data flow--the movement and processing of data from one application or entity to another-- can include all of the following:

A data flow can be 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 InterChange Server 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 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 InterChange Server 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 5 shows a simplified view of a business process that is initiated through a publish-and-subscribe interaction and completed through request/response interactions. (In this simplified view, connector controllers and connector agents are shown as a single unit, and no distinction is made between connectors for applications residing on a local network and connectors for applications residing across an Internet firewall.) 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 5. A publish-and-subscribe, request/response interaction


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

Sample data flows

Figure 6 shows a high-level view of the IBM WebSphere InterChange Server system components used in typical access request, publish-and-subscribe, and request/response interactions to move data among applications (or other entities, such as web servers and browser).

The data moves in a flow through InterChange Server at the hub, and is exchanged with applications on the local network, applications configured with connector agents beyond an Internet firewall, and external entities such as web servers and browsers.

The flow can be initiated by a access request or by an event--or by any type of external or internal process. Once the flow has been initiated, the collaboration uses the request/response interaction to complete the business process with either local or remote applications or other entities.

In this diagram, one connector is shown publishing an application event to collaborations, and another connector is shown engaging in a request/response interaction between a collaboration and a web server destination. Note that this illustrates only one possible configuration; most connectors can be configured to both publish events and respond to requests from collaborations.

Not shown in this diagram is the possible configuration in which a connector interacts with a locally configured technology server--such as a TPI server or Email server--to exchange data over the Internet.

In addition, note that a connector agent and its corresponding application need not reside locally. Using remote agent technology, connector agents at remote URL locations can both publish events and respond to collaboration requests.

Figure 6. Business data flow


Figure 7 shows some types of data that are exchanged along some of the possible data paths.

The numbers indicate the specific sequence of just one possible data path--in this example, from an external web browser into the collaborations by way of the Server Access Interface, and then, after the collaboration's business processing, to an external web server.

Figure 7. Sample business data flow


In the Figure 7 example, the following process takes place:

  1. A client program communicates with a server to send an access request to a collaboration. The client program could be a web browser communicating with a web server over the HTTP or HTTPS protocol, or a J2EE client making a J2EE method invocation on a J2EE application server using either RMI or IIOP.
  2. The call is handled by the appropriate server-side component (a servlet in the case of a web server, and an EJB in the case of a J2EE application server) that has been configured to communicate with the IBM WebSphere InterChange Server system. The component specifies a business object that will be created and a collaboration that will be triggered by the call and sends the call to the Server Access Interface.
  3. The Server Access Interface receives the call and passes it to an appropriate data handler (in this example, an XML data handler). The data handler transforms the data into a business object and passes it back to the Server Access Interface.
  4. The Server Access Interface passes the business object to the specified collaboration.
  5. The collaboration: (a) Performs its business processes on the business object, and (b) synchronously returns a business object to the Server Access Interface, to be passed on to the originating client browser or application. The business object can contain business data that is the result of the processing, or it can be an exception notification.
  6. In this example, the collaboration's business logic tells it to send a business object as a request to a technology connector that will be used to send the data across the Internet to an external web server.

    In still other scenarios, the collaboration might instead send a business object to an application connector rather than a technology connector. The application could reside locally or, if the remote agent technology is being used, the application and its connector agent could reside across the Internet, remote from the hub.

  7. In this example, the XML connector transforms the business object into an XML document and sends it to a web server.
  8. The web server sends a response to the XML connector.
  9. The XML connector transforms the response into a business object and sends it to the collaboration.
  10. The collaboration performs business processes for that business object.
  11. The collaboration sends the business object to the Server Access Interface.
  12. The Server Access Interface sends the business object to the appropriate data handler, and receives the data back in that format.
  13. The Server Access Interface uses the IIOP protocol to send the data to the servlet.
  14. The servlet uses the HTTP or HTTPS protocol to send the data to the originating web browser or other entity.

Copyright IBM Corp. 1997, 2004