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