WS-REST

Mark Nottingham entered the Matrix in search of the spoon.

First, I tip my hat to Mark for tackling a complex issue.

Mark points a handful of things out:
1. A single http request is indeed synchronous
2. The http request doesn't have to block for the end result, instead it can block for an ACK or a fault code
3. Two http requests can be combined to create an asynchronous message exchange pattern
4. Pub/sub can be simulate via polling.
So far, so good.

He continues, to say:
5. One can hold open a TCP connection and use event looping to minimize the resource consumption issue.
Ok, this is an interesting one. In my opinion, there are some problems here:
1. It assumes that not only the end server utilizes a specific mechanism (event looping), but also every intermediary between the client and the server.
2. Connection oriented protocols don't work well when the server crashes (all connections must be reestablished; kiss your performance gain bye-bye).
3. Clustering connection oriented protocols (IMHO) is more cumbersome than connection-less protocols.

Then he introduces the peer-to-peer model, where the client has a well-known address and continues on to acknowledge the firewall/NAT issue. Very good.

Ultimately Mark points out that many people hear 'http' and think synchronous - which is right and wrong. Yes under the covers the application blocks, but not necessarily for the 'answer'. He also states that people should consider the level of abstractions that they need (describe the message exchange versus describe the implementation). I agree. He ends his post with noting that modern distributed computing practices require the ability to describe the interface and the message exchange pattern, then he goes on to mock one up.

In my opinion, Mark has blasted past the issue of 'WS-I' style versus 'RESTifarian' style and is well on his way to finding the best-of-breed. This will be one to watch.