Callout programming models
Use this programming model to send outbound messages from an IMS™ application to request services or data from message-driven beans (MDBs), Enterprise JavaBeans (EJB) components, or web services and, optionally, receive response data.
In the IMS callout programming models, IMS acts as a client to interact with business data or logic that resides in a MDB, an EJB component, or a Web service. IMS applications invoke external Java™ applications by issuing callout requests. From the perspective of WebSphere® Application Server, on the contrary, these messages from IMS applications are inbound messages.
Depending on whether a response from the external Java application is expected, and whether the response is expected by the initiating IMS application in the same transaction, different programming models can be employed.
Synchronous callout
A synchronous callout request is a request that expects a response from the external Java application or Web service to return in the same transaction to the same IMS application.
When an IMS application issues a synchronous callout request by using the IMS DL/I ICAL call, an OTMA transaction pipe (tpipe) is used to hold the request. The IMS application in the dependent region remains scheduled and waits for the response. After the external application pulls the request message from the tpipe, the tpipe is in a wait status until a response is returned from the external application.
For message-driven beans (MDBs), you can take advantage of the Java EE Connector Architecture 1.5 inbound specification, and the tooling support in various Rational® or WebSphere integrated development environments (IDEs). The IMS TM resource adapter listens for callout messages from IMS Connect and handles the correlation of the request and its response.
For non-MDB applications, it is the application's responsibility to poll IMS Connect for any callout requests on the hold queue. The application also needs to handle the correlator token that is passed as a property of the IMSInteractionSpec class.
The key benefit of having the callout request and the response in the same transaction instance is that the programming logic for issuing the request and for processing the response can be contained in the same IMS application. This approach does, however, require that the IMS application wait for the response, and the dependent regions would be blocked.
Asynchronous callout
An asynchronous callout request is a request that does not expect a response, or expects the response to return in a different transaction.
After the IMS application issues the asynchronous callout request by using the ISRT ALPCB call, an OTMA transaction pipe (tpipe) or an alternative destination (as coded in an exit routine), is used to hold the request. After the external application pulls the request message from the hold queue, the IMS application is no longer scheduled in the IMS dependent region, and the dependent region is freed up.
If a response is expected, the response message returns as a new IMS transaction request to either the same or a different IMS application with the output data, depending on your application design.
The key benefit of having the response return asynchronously is to avoid blocking the dependent regions and therefore locking IMS resources for an excessive period of time. However, this approach does require that, if a response needs to be processed, the IMS application must be designed to be capable of handling the output in a separate transaction instance. It is also the responsibility of the application to correlate that response with the request.