Asynchronous operations and web services, Part 1

A primer on asynchronous transactions

Build a web services architecture that handles requests and responses as separate transactions


Content series:

This content is part # of # in the series: Asynchronous operations and web services, Part 1

Stay tuned for additional content in this series.

This content is part of the series:Asynchronous operations and web services, Part 1

Stay tuned for additional content in this series.

Invocations of web services are asynchronous in nature in that the service provider must be capable of accepting requests from clients without notice. However, sometimes the response to the web service request is available on the same thread of execution as the invocation; such operations are often labeled as synchronous. This discussion of asynchronous operations will not focus on the initiation of request messages by clients or the consumption of request messages by service providers; rather, I'll focus on how to handle responses to web service requests that are not provided immediately but at a time after the initial request transactions complete. Such asynchronous behavior is common for services that require complex processing that may take minutes or even days to complete -- when, for example, the web service implementation is dependent on batch processing or manual steps requiring human intervention.

In this paper, I'll examine the theoretical basis for asynchronous web services. You'll learn what constitutes an asynchronous transaction, and what transports can carry it. I'll also explore the specific challenges that developers face when building support of asynchronous operations into their web services.

The designer of a web services client needs to decide how to handle asynchronous responses and how to ensure that his or her implementation is compatible with the way in which a service provider supports asynchronous operations. One option for the client is to issue a request and then block its thread of execution waiting for a response, but for obvious reasons this is not a good alternative; among other problems, it results in resource inefficiencies and raises transactional and scalability issues. The preferred solution is to build asynchronous behavior into the client. The client makes a request as part of one transaction and carries on with the thread of execution. The response message is then handled by a different thread within a separate transaction. In this model, the client as a service requestor requires a notification mechanism and a registered listener component to receive responses. Likewise, there must be a correlator (a correlation or transaction ID) exchanged between the client and service provider for associating responses with their requests.

A typically asynchronous scenario would include the following:

  • Production and transmission of a request message by a client.
  • Consumption of the request message by the service provider.
  • Production and transmission of a response message by the service provider.
  • Consumption of the response message by the client.

The messages exchanged may be thought of as datagrams for which no reply is needed or expected in order for the transaction to be processed. Through the use of such datagrams, the sending or initiating party of the messages can be fully decoupled from the receiving party, allowing for a truly asynchronous relationship between the two.

Challenges to be addressed

To support asynchronous operations, you must address many issues that do not exist when responses are synchronous. The tasks that need to be addressed by asynchronous implementations include:

  • Defining a correlator and a mechanism for its exchange.
  • Defining a reply-to address specifying where the response should be sent, and ensuring that the service provider is informed of this destination.
  • The generation of a response by a service provider as a transaction separate from the request.
  • The receipt of an asynchronous response by the client.
  • The correlation of response with request by both the client and service provider.

Transports and local interfaces

The transports that can be used for web services communications vary in their capabilities to facilitate the support of asynchronous operations. Thus, it's not only web services behavior that can be described as either asynchronous or synchronous; the transport used for exchanging web services messages also falls into one category or the other. Transports whose interfaces inherently support the correlation of response messages to request messages for application use and support a push and pull type of message exchange are often described as being asynchronous transports. Synchronous transports do not provide these facilities and, when used for asynchronous operations, require that the applications (the client and service provider, for the purposes of this discussion) manage the correlation of messages exchanged by not only defining how the correlator will be passed within each message, but by also matching responses with requests. Examples of transports that can be used in support of asynchronous operations include:

  • Asynchronous transports
    • HTTPR
    • JMS
    • IBM MQSeries Messaging
    • MS Messaging
  • Synchronous transports
    • HTTP
    • HTTPS
    • RMI/IIOP
    • SMTP

You can find more information on many of these transports in the Related topics section below.

Regardless of the transport being used for an asynchronous operation, the client (or service proxy used by the client) and the service provider are responsible for generating a correlator that the transports can use in managing the requests and responses.

Typically, when business partners are utilizing web services to integrate their business processes, they will prefer to use HTTP, HTTPS, and HTTPR as transports for communications across the Internet; within an enterprise, when there are similar application platforms, native transports and interfaces will be used, such as JMS, RMI/IIOP, and JCA (Java Connection Architecture).

The asynchronous transports enable a client to continue processing on its thread of execution immediately after requesting a service invocation; they also provide mechanisms to enable a client to determine the status of its web service requests, and to retrieve responses to those requests.

Web service implementations that do not provide the ability to initiate the transmission of a response on a separate thread of execution can not be used for asynchronous operations. Examples of such implementations would be those that use EJBs to front-end database applications or implementations that provide access to enterprise systems through the use of local interfaces such as JCA.

Conclusions and coming attractions

As the industry further develops specifications that determine how to coordinate flows between web services and how to describe dependencies between web services that realize business processes, support for asynchronous operations will be simplified. However, today's web services specifications and standards do not directly describe the support of asynchronous operations, though they do include the infrastructure and mechanisms on which asynchronous operations can be based. You should now have an idea of how you can start building support of asynchronous operations into your web services today.

In the second installment of this series, I'll take a look at some asynchronous web services patterns. These patterns will serve as foundations on which you can build advanced asynchronous web patterns. You can prepare yourself for that article by mastering the concepts outlined here.

Downloadable resources

Related topics


Sign in or register to add and subscribe to comments.

Zone=SOA and web services
ArticleTitle=Asynchronous operations and web services, Part 1: A primer on asynchronous transactions