More Nails For SOAP's Coffin
My previous blog entry on "SOAP is Comatose but not Officially Dead!" elicited reactions both positive and negative. Many of my detractors complained that SOAP isn't dead. Well to be clear, I didn't say it was dead, I said it was comatose and there's a world of difference between the two. The latter requires life support to keep on living, and that's precisely what Microsoft and IBM are providing. Now is it alive and kicking? Well then it can't hurt to conclude that it failed the second test.
The primary argument that SOAP adherents (Chris Ferris, Mike Champion, Radovan Janecek referenced here for posterity) make is that SOAP is designed to bolt in a lot of "ilities". "Illities" are non-functional requirements (i.e. security, reliability, manageability, quality of service).
Graham Glass creator an earlier adopter and provider of SOAP based APIs for Java made this remark in a recent blog entry:
I’d like to share an anecdote about one of the items in the above list: listening to users more than analysts when determining feature sets. In the early days of web services, analysts were saying that adoption of web services would not take off until XML-based security standards like WS-security were available. Because of this sentiment, we thought that Glue might not be adopted until we implemented this particular standard. But due to resource constraints, Glue 1.0 only shipped with support for SOAP over HTTP and HTTPS. But to our surprise, most of our customers didn’t really care about WS-Security, and found that HTTPS was sufficient for secure communications. This was an example where users had a significantly different set of needs than those being suggested by the analyst community. Later, of course, we added support for WS-Security, but even to this day it is a feature that is rarely used.
If WS-Security is rarely used, HTTPS is good enough and interoperable web services is via XML Schema validation of documents then it becomes less clear what exactly SOAP brings to the table.
SOAP adherents say REST can't be made reliable. However, argue that point with Bill de Hora who recently published HTTPLR a reliable way of transmitting messages via HTTP. The spec is consistent with HTTP semantics rather than extending or abusing them. In otherwords, reliability without the extra baggage of SOAP.
However if you still holding on to your "ilities" argument then the AMQ development may be the one that ulimately kills it. The AMQ protocol is a transactional, point-to-point, high-performance publish-and-subscribe model supporting 100MB chunks of data and market feeds at the same time. In otherwords, "financial-grade" stuff available by defining a standard wire protocol. Sean McGrath says it best:
My money is on the wire protocol. I'm a bits-on-the-wire kida guy and so I prefer JXTA to JINI and XML over HTTP to just about anything. Will I prefer AMQ to JMS? I expect so. Wire protocols are the key to true interoperability. APIs on the other hand are the key to true platform lock-in. We have seen this over and over again over the years. All the useful stuff ends up outside the platform-independent API
The last nail may have been when Yahoo announced its Web Services. REST was awarded the design win over SOAP. Quoted from the specs:
The Yahoo! Search Web Services are all REST services. That means you can easily construct request URLs that will work in your browser, on the command line, and in your code.
However what was telling was that everyone and his mother announced it as "Web Services". The day REST is synonymous with "Web Services" is the day SOAP is truly dead, and that day may have arrived a day too early for many.
Last modified 2005-03-02 09:35 AM