Bring out your de-ad!

Via Mark, who was spotted recently dancing around a fire like Rumplestiltskin wringing his hands gleefully while chanting:

"Today I bake, to-morrow brew,
the next I'll wake the vendor's child
Ha! glad am I that no one knew
that RESTafarian I am styled."

comes a link to a post on the Manageability blog proclaiming that SOAP is comatose, but not officially dead! which concludes:

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.

In addition to citing some recent quotes from the blogosphere, which purport to support this conclusion, the writer (whom I don't know) proceeds to (inaccurately) trash SOAP ("but, I'm not dead yet!") as being somehow fundamentally flawed with regards to interoperability:

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.

As alleged evidence to support this claim, some interoperability guidance from a presentation by Simon Guest of Microsoft is cited:

• 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.

This is followed by an analysis of this guidance, most of which I agree with, but none of which is inherent exclusively to SOAP or Web services. The analysis concludes (emphasis mine):

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.

Yeah, riiiight; easy... NOT! At least not for your average code slinger faced with dealing with a complex schema.

As recent blogosphere entrant, and SAX API creator, David Megginson readily admits:

I have to admit that Dare is absolutely right – building complex applications that use SAX and DOM is very difficult and usually results in messy, hard-to-maintain code.

The problem is that I have not yet been able to find an XML API that doesn’t, um, suck. So-called simplified APIs like StAX or JDOM always look easier with the simple examples used in introductions and tutorials, but as soon as you try to use them in a real-world application, their relatively minor advantages disappear in the noise of trying to deal with the complexity of XML structure.

The simple truth is that none of the alleged flaws of SOAP cited in the Manageability post have anything at all to do with SOAP. Arguments which try to assert that REST and SOAP are somehow mutually exclusive, and that POX (I love that acronym!) over HTTP is soooo much simpler than SOAP are nothing more than simplistic, uninformed, and inane drivel.

Even Mark acknowledges this, and for once, I have to agree with him:

Again, it's a shame SOAP is getting caught up in this backlash, since it's not the spec that's the problem, it's how people are (mis)using it.

The interoperability issues being incorrectly attributed to SOAP are in fact inherent to how the XML is being processed. The interoperability advice that Simon offers applies equally to POX over HTTP using RESTful style interactions (whenever the user agent is not a browser) as it does for SOAP.

The real crux of the issue is the inadequacy of the various programming models used for processing XML, whether it be POX or SOAP, and the tooling which developers use to "simplify" the task of cutting code. They are either considered "too complicated for average developers", or they are too simplistic (or constrained) in their underlying assumptions (most XML->domain object mapping).