asynchronous operations and Web services, part 1th: Getting Started with asynchronous transactions

Not all Web services work synchronously, and in some cases the response to a Web service request is not provided immediately, but at some point after the initial request transaction completes. WEB Service specifications and standards do not explicitly support this asynchronous operation, but those standards do contain the infrastructure and mechanisms that can be used as the basis for asynchronous operations. In this article, Holt Adams explains why any Web service architect needs to understand how asynchronous operations work. This article will help you start adapting your services to the asynchronous environment.

The WEB service invocation is inherently asynchronous, because the service provider must be able to receive requests from the client without notice. However, sometimes the response of a WEB service request is available on the same execution thread that is invoked, which is often referred to as a synchronous operation. This discussion of asynchronous operations will not focus on the client's startup of the request message or the service provider's handling of the request message, but rather on how to handle the response to the WEB service request, which is not provided immediately, but only after the initial request transaction completes. This asynchronous behavior is common for services that require complex processing that can take a few minutes or even a few days to complete-for example, when a WEB service implementation relies on batch processing or manual steps that require human intervention.

In this article, I'll discuss the rationale for asynchronous Web services. You will learn what the asynchronous transaction is made of, and what kind of transport can deliver this transaction. I'll also explore the specific problems developers face when they build asynchronous operations support into their WEB services.

The designer of a Web service client needs to decide how to handle an asynchronous response and how to ensure that his or her implementation is consistent with the way the service provider supports asynchronous operations. One option for a client is to send a request and then block its thread of execution while waiting for a response, but for some obvious reason this is not a good alternative; it can lead to inefficient resource utilization and also cause transactional and scalability issues and other issues. The preferred solution is to build the asynchronous behavior into the client. The client sends a request as part of a transaction and then uses the execution thread. The response message is then processed by another thread within a separate transaction. In this model, the client, as a service requester, requires a notification mechanism and a registered listener component to receive the response. Similarly, there must be a correlator (correlator) exchanged between the client and the service provider (a dependency or transaction identity) that associates the response with their request.

A typical asynchronous case will include the following:

The client generates and transmits request messages.

The service provider processes the request message.

Service providers generate and transmit response messages

Client consumption response message.

The exchanged message can be treated as such a datagram, and the datagram does not need or expects no reply in order for the transaction to be processed. By using this datagram, the sender of the message (or the originator) can be separated from the receiver, taking into account the true asynchronous relationship between the two parties.

The problem to be solved

To support asynchronous operations, many problems that do not exist in response to synchronization must be resolved. The issues that need to be addressed in asynchronous implementations include:

Defines a correlator and a mechanism for its exchange.

Define a reply (reply-to address) to specify where the response should be sent and ensure that the destination is notified to the service provider.

The process by which a service provider generates a response is separated from the request as a transaction.

The client receives an asynchronous response.

The client and service provider associate the response with the request.