WebServices dot org

Async

In synchronous messaging, resources are dedicated in one party while the other party and/or network are processing the message. The classic is obviously request-response where the client keeps a connection open, and probably a thread for the connection, while waiting for the response. These two systems are coupled in time.

Asynchrony relaxes the coupling in time but adds a coupling in space. In asynchronous messaging, the message sender devotes fewer resources to the message exchange pattern. The simplest is a one-way message, where the sender puts the message into the transport and continues. Request-response is often layered onto asynchronous messaging by using of a "callback", sometimes called asynchronous request-response. A request contains an address for the receiver to send a message to.

There is further coupling in space because the state of the system is spread across two machines. To re-use the resources on the sender, the "state" of the sender must somehow be passivated, so that it can be reified when the response comes back. The correct instance of state on the server, often called correlation, must also be identifiable from the response message. The protocol between the two systems must necessarily be more complicated for asynchrony, because it requires the correlation between messages and/or instances to be in the messages. FWIW, these correlations are why WS-Addressing has MessageIds, RelatesTo and Reference Parameters.

The trade-off between coupling in space and time is that the resources that are used for synchronous communications, such as socket connections, program and cpu threads, may be inefficiently allocated. Asynch allows the sender to free up these resources for other tasks. While there are resources that must be allocated for waiting for the callback (such as waiting for an inbound connection) and there is an increase in the complexity of the protocol (adding in correlation) and sender machinery (passivating and reifining state), these are often less than the synchronous resources. In situations where the resources are not effectively used, asynchrony increases the scalability and performance of applications.

When Asynch

The next question is when to use Asychronous versus Synchronous communications. As with all trade-offs, there are no hard and fast rules. Clearly communications that will take hours or days to answer are strong candidates for asynchrony. But how many minutes or seconds would suggest using asynch? Most web sites have a guideline that a web page must respond within 30 seconds. Perhaps this is a good guideline for the line between synchronous and asynchronous.

Callback specs

If you believe that Asynchrony is a vital component in building scalable distributable systems and you are using Web services, then SOAP and a few other WS-* specs provide the prerequisite infrastructure. WS-Addressing is probably the core specification for asynchrony, it's likely to be very widely deployed. BEA poineered and shipped a couple of predecessors in SOAP-Conversation and WS-Callback , and WS-I specified a basic Callback scenario . Additional specifications that layer on top are WS-Eventing (PDF) and WS-Notification . I don't want to get into the obviousness of the political nature of why there isn't a single notification spec that has publish,subscribe,renew, terminate and pause/continue messages.

Polling

Another style of asynch uses "polling" rather than "callbacks". This avoids the opening up of the sender's address space, but causes increased complexity on both sender and receiver, inefficient message flow (as polls are often wasted) and potentially tardy responses. We have few WS-* specs in this area. I think a very intriguing possibility for polling is the use of blogging or RSS/Atom. Imagine using blogging for publish and subscribe.

Who specifies

A final aspect of Asynch worth speaking about is who decides whether a request is synchronous or asynchronous. There are only 2 choices: either the sender decides or the receiver decides. There is no clear answer.. In cases where the sender can't do asynch, it would obviously prefer to do synchronous comm. And in the same manner, if the receiver knows that the communication will take a long time, it will prefer async. WS-Addressing using a model where a receiver allows sender-specified. The sender will specify a callback by the presence of a non-anonymous value in the ReplyTo field.

Conlusion

Asynchrony is a powerful tool in building distributed systems. This article has provided some technical explanation of the tradeoffs between synchronous and asynchronous, when async can be applied, comparison of the callback and polling styles, and the specifications like WS-Addressing that can be used for asynch.