I promised to follow-up on my previous post
on the neverending permathread that is REST v SOAP.Patrick Logan
wants some constructive counter-arguments to Steve Loughran's contribution
to the permathread.
Steve, in reference to Mike Champion's post
Mike also thinks that XSD interop is now mostly solved (!), and that the language hits the sweet spot for O/X binding. I disagree with both of these points.
Actually, I disagree with Mike's suggestion as well. There is no "sweet spot for O/X binding". Anyone who has hung around with me long enough knows that one of my favorite adages is: "databinding is evil"
. Whether O/R or O/X, the IT community has long suffered through the painful experience of using tools that purport to yield developer nirvana. While these tools often work effectively for the trivial examples shipped with the tool, they typically fail miserably when applied to most real-world use cases either because of impedance mismatch, excruciatingly poor performance, or both.
In REST-land, few people work with XSD, even less try to seamlessly map from the schema to native types, and nobody expects the runtime to infer a REST state model from implementation classes. Yet despite the lack of all this integration, REST appears to work better.
Would someone please point me to the spcification that says that a SOAP stack MUST "seamlessly map from the schema to native types"? Call me crazy, but I have yet to find that conformance requirement in any of the specifications I've read, and I have read, not to mention written, quite a few in my time.
Most SOAP stacks, with which I am familiar, provide for the ability to bypass the databinding, passing the received XML content of the soap:Body directly to the application for processing (or to the SOAP processor for message content being sent), allowing for the use of a broad range of the very same APIs
that the people in "REST-land" employ (SAX, DOM, StAX, you name it). For that matter, you can do a (compiled) XSLT transform on the received XML to both validate its content with the likes of schematron, and to construct the inevitable database query lurking as the ultimate derivative of what most applications do after all of the (IMO) unnecessary X/O databinding. Seriously, why go to all the time and trouble of doing X/O databinding if all you are doing is taking the result object(s) and invoke its accessor methods to construct a database query?
If we have to work with SOAP, then I think this is how it will survive:
1. Use RelaxNG as the type language. No more xsd:nil problems.
repeat after me: RelaxNG is not
a type language. RelaxNG depends on external datatype libraries such as the W3C XML Schema language (part 2). Its native datatype system is limited to the types "string" and "token". Maybe that's what Steve meant. Somehow, I think that "string" and "token" are probably not sufficient for most uses and that people will end up needing somthing like the XSD datatypes
to complement RelaxNG. However, I don't think that this will necessarily fix the problems that Steve cites. It may actually lead to more confusion and even less interoperability if not handled carefully and wisely. It isn't as simple as Steve would have you believe. There would have to be transition rules to accomodate legacy implementation/deployments, and the databinding problem doesn't just go away because you start using RelaxNG. Plus, you have the challenge of getting all of the runtime and tooling vendors (and open source projects) to support RelaxNG. Good luck with that. That would make an exercise in cat herding seem simple by comparison.
Frankly, a better idea would be to avoid being "too clever by half"
. Cease and desist in the folly of inside-out (or as some call it, bottom-up) design of Web services with the misguided expectation that you can achieve interoperable round-tripping of constructs such as HashTables across disparate platforms. You are wasting your time. Keep your schema designs simple and straight-forward. Just because you can do something, doesn't mean that you should.
Steve continues to outline his ideal SOAP stack:
2. Stop ignoring the HTTP layer underneath, and integrate better with HTTP error codes, and things like redirects. Reported errors should include http codes, headers and text
3. View XSD as the Cobol of XML.
I must confess that I have no idea whether he meant this as a derogatory statement about COBOL or if he had something else in mind. If he thinks that COBOL has gone the way of the dinosaur, then I've got a bridge I'd like to sell him.
As for his point #2, I couldn't agree more. I would add to that that more SOAP stacks should
support (for SOAP1.1, the equivalent of) the SOAP Response MEP
using HTTP GET. IMO, HTTP GET is what makes REST so valuable.
4. Use XMPP as the back channel. Not WS-Eventing, or WS-Notification. Or let people poll. It actually works quite well when the number of polling clients is very low, as it probably is for most communications between two nodes, and it works around the whole firewall problem. I also believe that by decoupling the links between client and server more, you avoid the intermingled object model that is the curse of large distributed object applications.
Two things: 1) yeah, XMPP is kewl, but so is BEEP
, and BEEP already has a SOAP binding
; 2) check out WS-Polling
5. Replace WSDL with something people can read and write. I'd look at SSDL, whose cover artwork apparently includes someone writing XML with a fountain pen. However, it ought to have a human-friendly syntax, just at RelaxNG does.
6. Stabilise or kill WS-Addressing. WS-A is the recurring bane of my life. People ask me why, and I have to point them at code that tries to move data to and from the various versions of wsa:epr on the wire. URLs, that's all you should need. If you want async two-way comms, then give a URL for responses; an xmpp: one for xmpp responses.
7. Sort out attachments.
With regards to #5, does RelaxNG Compact Syntax replace
RelaxNG? No, of course it doesn't. It complements it. It is just an alternate form of expression without the awkward pointy brackets. There's no reason why a compact, non-pointy bracket-based, alternative notation for WSDL couldn't be produced as a tool to simplify WSDL authoring for developers. Many tools, such as the eclipse WST project
, now have graphical WSDL authoring capabilities. I'm not a big fan myself (my IDE of choice is vi), but many seem to prefer it over manually editing pointy-brackets.
With regards to #6, I'm not going to argue with this point, because I happen to agree that EPR reference parameters are unnecessary. However, I don't see what the problem is. WS-Addressing isn't rocket science, even with refPs.
Finally, with regards to #7, I couldn't agree more, and no, I don't think for a moment that MTOM
is the panacea that some claim it to be. However, for the class of use case(s) that these specifications do
support, they will eventually serve as the foundation of the necessary interoperability that is the real underlying requirement.
The more that gets added to this inane debate, the more it becomes clear that the issues people have with SOAP have nothing to do with SOAP, per se, but everything to do with the way in which it is used (or should I say, abused?) and even more with the tools they use
Over time, things will improve. If you think that HTTP and HTML popped out of the oven fully baked and had (have!) no interoperability (or usability) issues from day one, then you are either sadly delusional or were living in a cave during the 1990's "browser wars" when the phrase "this page renders best (or only) in IE" ruled the day.
I predict (and I certainly hope) that many implementations will incorporate support for RESTful applications using SOAP messages. As even Mark Baker would agree, there's nothing inherently wrong with SOAP itself and there is no reason it can't be a used as a first-class citizen of a completely RESTful application.[Read More