There are well-known trade-offs between synchronous and asynchronous messaging. The trade-offs roughly mean a choice between coupling in time versus coupling in space. 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 reifieing state0, 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.
Dave,
I don't quite understand your definition of "coupled in space". Coupling in space (in the Linda sense) refers to the decoupling of location. One example of such decoupling is publish-and-subscribe where the publisher may not know the identity of the subscriber. Decoupling in space applies for both synchrnous and asynchronous modes of communication. It's orthogonal to them.
Carlos
Carlos, even in the pub-sub case where the publisher doesn't know the "address" of the subscriber (say ws-brokerednotification), the subscriber's address must be known by the broker. In a synchronous case, the subscriber never has to publish an address.
Further, the state of the subscriber must be storeable and identifiable, so that the state can be reified when a notify message comes in to the subscribers address. In a synchronous case, the subscriber's state never has to be stored or identified.
David,
IMHO, your picture of the synchronous case is over-simplified, because you're focusing your attention on just one thread of execution involved in a synchronous request-response interaction. However, by the very nature of synchronicity - where each individual thread can do only one thing at a time - there need to be (potentially many) other threads running in parallel. These threads are all part of some global process and each thread contributes to the state of that global process. This usually means they share some global data and have to protect their accesses to these data through some sort of mutual exclusion mechanism. Furthermore, there may be interactions between threads such as the receipt of a fault message by one thread necessitating to kill all the other threads.
This inherent complexity of a synchronous setup consumes resources (threads, CPU, memory) and consequently hampers scalability. Contrast this with a purely asynchronous setup, where each message received is directly handled in the context of the global process state, all in a single thread of execution.
Harm.
Harm - I definitely agree with your picture of complexity in a synchronous model, in fact by its very nature today, most Enterprises delivering synchronously are doing so because they have a requirement for thousands of complex threads and are experiencing the concomitant association with large quantities of infrastructure to deal with them. However, to defend David - the answer is still the same; its a Trade-off. I dont think David could tackle this in more detail in a blog before turning it into a White Paper. The real question (in these terms) to me is "what are the dependencies"? Some elements of the Enterprise might be routeable using asyn, some may (e.g. banking, with sub 10second response scenario's) only be acheivable via synch and the cost imperative is "Response Time" not "Hardware cost/software complexity". Clearly a trade-off scenario. Rgds, Marc.