A transport of delight

When I saw Steve Vinoski's recent pointer to his colleague's article about “Where HTTP Fails SOAP“, I immediately thought of a song from the 60's by the English satirists Flanders and Swann. It's about the London Routemaster double-decker bus and titled “A Transport of Delight”. In the introduction on their album At the Drop of a Hat, they describe it as being about the omnibus, which they loosely translate from the Latin as meaning by, with or for, everybody.

People often criticize HTTP's use for Web services. Beyond the REST argument, which I don't want to go into here, people worry about its ability to scale to handle the style of processing in back-end business systems. Basically, because it was designed for a user at a browser, there are connection management, concurrency and directionality issues that need to be dealt with. The theory is that using SOAP over other transport protocols might be able to solve these problems.

I've thought for a long time that two interesting choices for alternate protocols with design tensions different from HTTP are SMTP and Jabber. We could use SMTP for disconnected message-queuing style communication and Jabber for connected, bidirectional async messaging. Both would offer indirect addressing. And both are open protocols with lots of implementations. Yes, there is overhead for using either one because you have to have set up a server for the protocol itself. On the other hand, we'd be using protocols that are actually designed for the kind of communication we envision Web services doing and it would stop the REST people from complaining.

However, as far as I can tell, most vendors are not moving in this direction. For instance, Iona supports CORBA bindings and Indigo supports an as yet undocumented TCP binding. Toolkits that support durable message queuing send SOAP over whatever proprietary protocols existing messaging systems use on the wire (this is true even for SOAP over JMS because JMS leaves wire protocol to the implementor). That means that when you use these protocols, you lose the wire-level compatibility that you have with SOAP over HTTP.

One solution to this is to build bridges that map SOAP messages augmented with WS-* functionality from one proprietary protocol to another. For instance, you could build a bridge from MSMQ to a JMS implementation, protecting the message with WS-* all the way. The trouble with that is that you have a lot more complicated pieces to manage. It would be simpler if MSMQ and a given JMS implementation just spoke the same protocol on the wire, but that isn't going to happen any time soon. So you have to add these complicated intermediaries, or just buy into a single vendor's solution. Maybe that's the point, but it doesn't seem like people will fall for it this time.

Instead, they'll opt for a second solution, which is to workaround the issues HTTP presents by designing applications very particular ways. This ought to be unnecessary given what other protocols offer, but not if the cost is increased complexity of lots of protocol bridging or proprietary protocol vendor lock-in. As someone in the office here pointed out, there's evidence of this already in that many companies, in setting out to redesign their IT systems, opted to use XML over HTTP even before SOAP existed. They new what the issues were and what the alternatives were, and they chose the thing that was easy to work with and ubiquitous, a combination that almost always wins.

Today, SOAP over HTTP is the only transport that works with two different toolkits at the ends of the wire. Until we have that with other open protocols, HTTP will dominate. Like the Routemaster, HTTP is by, with or for everybody. It is a transport of delight.