Asynchronous invocation

When a service component is called asynchronously, the service requester and the service provider run in different threads of execution. For an asynchronous invocation, the calling component within IBM® Process Server is not blocked while the request is processed by the provider. The SCA runtime returns control to the requester immediately, allowing it to continue processing.

With asynchronous invocation in SCA, there are three types of asynchronous interaction styles available: one way, deferred response, and request with callback. With all three types of asynchronous invocation, the service requester receives control back immediately from the SCA runtime.

There are two ways that the service requester can capture the response at a later time.

Asynchronous with deferred response, where the service requester calls an operation on the service provider, and then continues processing. At a later time, the service requester calls the service provider for a response.
Asynchronous with callback, where the service requester calls an operation on the service provider and specifies a callback handler. When the response is available, the SCA runtime returns the response to the requester by calling this callback handler.

Asynchronous with deferred response SCA invocation

Asynchronous with deferred response SCA invocation is useful if the service requester has further processing to perform that does not depend on information to be returned in the response.

When using asynchronous with deferred response invocation, resources within the SCA runtime thread are held until a response is available from the service provider. If the service provider takes a hours or days to process the request, the invocation style asynchronous with callback should be used. Asynchronous with deferred response SCA invocation is shown in Figure 1.

Figure 1. Asynchronous with deferred response SCA invocation

Asynchronous with deferred response SCA invocation shows how processing continues for the service requester.

Example scenario

A car insurance comparison website would prefer to use the asynchronous with deferred response style of invocation. The service requester requests a search on car insurance from two different car insurance providers. The responses are not dependent upon each other. When the car insurance providers return a response, the service requester can choose the cheapest quote. Figure 2 shows how the service requester can call both service provider A and B.

Figure 2. Car insurance comparison website using asynchronous with deferred response invocation

Asynchronous with deferred response SCA invocation shows how processing continues for the service requester. The service requester is able to send many calls to many service provider.

The service requester creates a request to service provider A, and calls the SCA runtime. The SCA runtime returns control to the requester immediately, allowing it to continue processing. The service requester is then able to create a second request for service provider B.

The service requester makes further calls to the SCA runtime to collect the responses. These are processed, and the final response is then returned to the user.

Asynchronous with callback SCA invocation

In this invocation style, the calling component (service requester) specifies a callback handler that will be used to receive and process the response. After the service requester has sent the request, the thread that made the request completes processing. SCA runtime resources associated with that thread are then released. When the response from the service provider is available, a new SCA runtime thread is used to call the callback handler to perform the processing required by the service requester.

This style of invocation is used for long running processes or services which could take hours or days to return a response. Asynchronous with callback SCA invocation is shown in Figure 3.

Figure 3. Asynchronous with callback SCA invocation

Asynchronous with callback SCA invocation shows how processing continues for the service requester.

Example Scenario

A company would prefer to use this style of invocation if they perform audits. The service requester wants to update employees' payment details, and only needs to be notified when the update has been made.

The service requester sends a series of calls to update employees' payment details, to the service provider. The service provider invokes an audit service for each request. The audit can take from a few hours to a whole day to make a record of each employees payment details. When the audit service is complete, the response is returned to the service requester using a callback handler, and an email is sent to the user to notify them that the update has been successful.