Summary
SOAP is comatose, but hasn't declared legally dead by either IBM or Microsoft. But how did this all happen? Isn't SOAP the underpinnings of Web Services, the same technology that was billed as the silver bullet to extinguish our collective integration nightmare? Well the time of reckoning has now arrived.

SOAP is comatose, but hasn't declared legally dead by either IBM or Microsoft. But how did this all happen? Isn't SOAP the underpinnings of Web Services, the same technology that was billed as the silver bullet to extinguish our collective integration nightmare? Well the time of reckoning has now arrived.

The arguments for and against Web Services have been raging on since the pinnacle and eventual bursting of the Internet bubble. My first blog entry on the subject of SOAP's fundamental weakness in support of interoperability was back in 2002. Back then it was already clear that SOAP was built on tight coupling and to make progress one need to make some design choices away from the familiar. In mid 2003, it was becoming quite apparent that the Web Standards bodies were repeating the same mistakes as the CORBA standardization that came before it. Finally, by the middle of 2004, the trade press finally saw the train wreck coming.

Today, half a year since my prediction of the rise of REST and the fall of SOAP, denial has been now replaced with panic. The RESTful approach has now born fruit. Applications like BlogLines, Flickr, Mappr, Del.icio.us and 43Things are revealing that proof is in the pudding. All of these have shunned SOAP in favor of more RESTful designs. In stark contrast, the SOAP high priests have nothing to show but fancy visual tools. Their followers are at the brink of rebellion and if they don't act quickly they could find themselves swinging from a high treetop.

To witness the SOAP panic, here's a sampling from the blogsphere:

James Govenor writes in "SOAP is boring, wake up Big Vendors or get niched:

Evidence continues to mount that developers can' t be bothered with SOAP and the learning requirements associated with use of the standard for information interchange. It is often described as "lightweight", but its RPC roots keep showing.

Developers are turning their backs on the standard. Folks that is, building interesting information splicing apps--semantically rich platforms like flickr and Amazon are being accessed by RESTful methods, not IBM/MS defined "XML Web Services" calls.

What is a web service? That’s still a great question. But anyone that defines a Web Service using SOAP in the definition is missing out on where the action is. Distinctions between enterprise and "consumer" are breaking down. REST is evidently where that convergence is being played out, not WS-I.

Stephen O'Grady writes:

Case in point is what longer term readers will recognize as one of the windmills I tilt at regularly, simple, RESTian web services. I have yet to hear any vendor - not one - talk to me about how they help developers design, implement and consume RESTian web services.

In yet another blog entry about a project for Creative Commons webservice:

At the time, we planned to develop both SOAP and REST implementations, but left the SOAP implementation incomplete due to time constraints. It’s been on my list to finish “real soon now” ever since.

The one developer who asked me about the SOAP version was a Java developer who wanted to use the WSDL definition to make life easier. That I can sympathize with. But the fact of the matter is that I don’t currently have the bandwidth to finish and maintain two separate implementations.

Over the weekend Mike pointed me to an interview with Stewart Butterfield, CEO of Flickr. In it he describes a similar phenomenon to what we’ve observed (although on a much larger scale): far more interest in REST than SOAP.

Stuart Butterfield on Flickr:

On the strictly practical side, I think we had one person inquire about using the SOAP version of the API. I don't know if any apps were actually built. There is at least one application built on XML-RPC. But all the others--I don't even know how many there are--are built on the REST API. It's just so easy to develop that way; I think it's foolish to do anything else.

Mike Champion of course is prepared to defend the faith. Where he writes:

Users of browser-based applications come to expect the quality of service one associates with the Web. Web services toolkits such as Indigo on the other hand, are oriented toward use cases that demand high-security, support for existing enterprise messaging systems, message failure is not an option, and industrial-strength transaction processing is assumed. The REST approach (as far as I can tell after years of discussion) assumes that all these features are provided at the application level rather than being provided by the infrastructure. I am convinced that developers with demanding requirements for security, reliability, transactions, etc. Generally DO want what WS-* and Indigo promise.

What Mike seems to be saying is that REST is the Yugo and if you want the features then you have to buy a Rolls Royce. It's a sales pitch used all too commonly. Unfortunately, if I wanted a Rolls Royce I would have purchased a JMS implementation, not a Web Services implementation with a yet to be defined solution for security. It appears that Web Services are stuck between a rock and a hard place (see de hOra's rebuttal). Fortunately, history does tend to repeat itself and gives us insight on this. See Tim Bray's 80/20 point and Clay Shirky's "In Praise of Evolvable Systems" for reference.

However, let's go beyond this name-calling and look at the crux of the matter. The primary rationale behind Web Services is to support interoperability. So, let's examine SOAP today to discover if it is superior to REST in supporting the primary requirement.

Simon Guest of Microsoft (masters of interoperability) has a very revealing video (unfortunately only available using IE) about the gothchas in Web Service interoperability. He enumerates 10 tips of Web Services Interoperability:

• Avoid returning empty Arrays.
• Services that share datatypes should be handled with care.
• Do not test for Null, rather check if the a returned object is Nil instead.
• Avoid null Dates. In .NET dates are a value type, in Java they are reference types
• Don't make exact Date comparisons.
• Always use a Trace tool.
• Learn how to change the URL and ports.
• Unit test.
• Use doc/literal.
• Always start from the XML Schema Definition.

Now take away the tips that apply to just about any software development activity (i.e debugging and unit testing) and you end up with some telling flaws in the Web Services specification.

• The first flaw is that you should not violate Postel's Law. That is "Be liberal in what you accept and conservative in what you send". Returning empty arrays, sharing datatypes, returning null dates should never break a clients view of the world. If the spec were rigid enough returning any of these objects should never lead to a misinterpretation in the client side.
• Always hide implementation. This should be pretty obvious, however most these gotchas point to the problem of implementation leaking through the abstractions. Why should the fact that two services that share the same datatype affect how its handled in the client? Why should client care if the server handles dates as reference types or not? Why isn't a return of a Null date abstracted away from a client?
• XML Documents are not the same as Objects. Simon St. Laurent says this best when he said "a schema language that describes document structures, not type structures abstracted on top of document structures."
• Finally, what's the complication with switching URLs and ports? The RESTful way is entirely obvious, while in SOAP the machinery usually requires digging deep inside WSDL to get access.

Of course, the last 2 tips are the most revealing of all. If everything is sent over the wire as a XML document that is described by an XSD then it all boils down to how easy you can work with these documents. That is working with XML api's like DOM and XPath. The enclosing envelope should be irrelevant to the concerns of the average developer; it should be treated like just any other transport protocol. All that extra machinery provided to support the SOAP envelope is precisely that, extra machinery and has never been shown to improve interoperability. Therefore, in terms of effort, interoperability via SOAP is not any easier than doing it in REST. In fact, its actually more insidious because a developer is all too easily lulled in the fallacy that an object is the same as the XML document.

So here I'm going to reiterate again that SOAP is brain dead. I sincerely hope not to write similar piece years from now when the conclusion would be entirely obvious.

Talk Back!

Have an opinion? Readers have already posted 5 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Carlos Perez adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Carlos E. Perez has been an object-oriented practitioner for over a decade. He holds a Bachelor's Degree in Physics and a Master's Degree in Computer Science from the University of Massachusetts. He has polished his craft while working in IBM's Internet Division and IBM's TJ Watson Research Center in Hawthorne, New York. He now works for a startup 1/100,000th the size of his former employer. He writes about topics covering emerging aspect and object oriented paradigms, loosely coupled architecture, open source projects and Java evangelism.