Async

Dave has put up a post on Async that, as usual, is both thoughtful and quite thought provoking. However, I'm not sure I would necessarily agree with his characterizations though.

As an aside, this topic was beaten to a pulp in the WSAWG during the summer of 2003, but I digress. Please feel free to rummage around in the W3C WSAGW archives if you wish to relive the experience:-)

He characterizes the distinction between "synchronous" and "asynchronous" in terms of time and space (emphasis mine):

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.

On this point, I am pretty certain that I disagree. I think of the distinction as a matter of implicit state versus explicit state. He even hints at this in his characterization (highlighted). In the context he describes above, it is the implicit state of the connection itself that provides the correlation between the request and response messages rather than anything in the messages themselves. Certainly, this is true as regards to HTTP request/response pairs.

He continues:

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.

I'm not sure that I grok the "coupling in space" analogy.

He continues:

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.

Ah, now we're getting somewhere! This is exactly my point. The real distinction is the use of implicit versus explicit state for correlation.

It isn't clear to me that explicit state, carried in each message so as to enable correlation, is necessarily more complex than is use of implicit state. Certainly, the messages appear more complex because there's more goop in them (MessageId, RelatesTo, etc.). However, as with all things, eventually software will evolve to the point where these things are well hidden.