Nick links to DaveO’s “leaky abstraction” bit from a while back, and comments;
Good discussion (as usual) of design issues (incl design conflicts) between SOAP and WSDL MEPs. Also points out that apparently SOAP envelopes don’t contain MEP metadata, so SOAP intermediaries cannot tell be examining a SOAP envelope which MEP it is part of! This seems like a huge design oversight and proof of how little experience we have with protocols with first-class treatment of intermediaries. Perhaps SOAP and WSDL have bitten off more than the critcal mass of programmers can chew on.
It’s a feature, not a bug! I can’t find it, but I remember when MEPs were introduced back in the early days of XMLP, that I expressed concern that MEP information would find its way into the message.
The problem is that application protocols determine the “MEP”, not the SOAP envelope. For example, if the transfer protocol is HTTP then you know you’re in the middle of a request-response interaction because it’s HTTP. Want to use HTTP with a new MEP that enables, say, out-of-order responses? Tough! HTTP doesn’t support it. Well, I suppose you could define an HTTP extension to support it, but you still don’t need anything in the SOAP envelope.
It’s just another example of how protocol independence really is the root of all evil in Web services.
As for Nick’s suggestion that we lack experience with protocols with first-class treatment of intermediaries, I disagree; as an industry, we have a huge amount of experience with them, in particular with SMTP and HTTP, both of which have been deployed for ages, and at massive scale. Unfortunately, the overlap between those with that knowledge and experience, and advocates of WS-*, is essentially the empty set. 8-(
Phil Windley summarizes a point by Dion Hinchecliffe;
I spoke with Dion yesterday and he talked to me about governance mistakes he sees clients making. The number one problem is something he called the “tyranny of the `MUST understand’ flag.” You get a SOAP-based Web service loaded up with WS-* header elements all tagged ‘MUST understand’ and you end up with something every-bit as much a central command and control structure as if you’d just reintroduced the mainframe. No one can do anything unless they’re using the same toolset.
I think I understand the issue here, but I think there’s more to it than you might extract from that paragraph.
First off, mandatory extension mechanisms like mustUnderstand are a Good Thing, because it makes messages more self-descriptive; if a message is extended in such a way that older processors can’t accurately interpret the message, then you need it to save those processors from processing a message which they can’t process.
That said though, there needs to be recognition that there’s a fairly high cost of deployment of these kinds of extensions because each one that’s defined basically bifurcates the space of interoperable agents (you know, just like deploying a new service interface does … but that’s another issue 8-).
And that’s where I agree with Dion. If you find yourself using mustUnderstand in more than a handful of your interactions, chances are that you’ve messed up somewhere, likely by failing to account for sufficient extensibility in previous versions. In fact, I’d even extrapolate from that to suggest that if you’re using mustUnderstand in version 1.0 of your system, and that system is closed (i.e. behind a firewall, or otherwise not interacting with pre-existing software), you’ve definitely screwed up.
Speaking of which… Perhaps the worst offender in this regard is WS-Addressing, because it effectively mandates the use of at least one mandatory extension in every message; wsa:To. Well, technically it doesn’t require that it be tagged as mandatory, but I think it’s pretty obvious that if a recipient didn’t understand where the message was addressed, that all hell would break lose if it tried to process it. So, if you use WS-Addressing, then all of your messages are prima facie unprocessable by all existing SOAP software. Oopsie!
a common mistake is to take a layered design as a requirement for a correspondingly layered implementation
From Gaining Efficiency in Transport Services by Appropriate Design and Implementation Choices, by Watson and Mamrak, ACM TOCS, 1987.
Compare and contrast;
Specifically, Internet based efforts (including the Web, of course) always start with an interface constraint. This is simply for the reason that they’re (usually) always focused on a single task – for example, email exchange, mail folder access and synchronization, file transfer – and pay little to no attention to what it means to define interoperability between those applications, since that’s tangential to their primary objective. A consequence of this approach is that there becomes little value in using a common sub-layer-7 protocol (like BEEP, IIOP, or how most people use SOAP).
Jeff Schneider apparently takes offense to my Service Oriented Web presentation;
Yes Mark, you can order a pizza with SOAP, with REST, with CORBA, with RMI, with EJB and more.
Don’t tell that to the designers of the WS-Splat stack. As late as 2002, I was still being told by some of them that REST based solutions required humans in the loop (and as late as this year, by a well known CTO of a public company in our industry!). Does that not concern you, that these bright folks – and they really are bright, I’m not being facetious – who much of the industry are entrusting their future architectural direction to – can make such a massive mistake? Does that not warrant further investigation, to see how that can happen, and more importantly, why it happened? Is it not in the realm of possibility that the industry has simply screwed up in a very big way?
What’s your point? The world needs REST? Let’s be clear: “REST” is unnecessary – as is all of this stuff! If we want to build our distributed systems with Sockets and EDI we could – BUT WE DON’T!
Jeff, the point of that part of the presentation was that in 1998, before SOAP came along, we already had at our disposal the largest and most successful distributed application in the history of mankind (hmm, I suppose it might have been smaller than email at the time, but worst case, second largest), and it was capable of solving pretty much all the problems that Web services were being tapped to solve. The Web just needed some extensions; some things built on top that leveraged what was beneath.
We were already well on our way with the Web, to achieving what’s now known as the “SOA vision”. Web services have set us back in that pursuit, at least six years in real time, but architecturally, decades, since they’ve disregarded – no, explicitly rejected – known best practices for large scale integration .
That’s not worth calling out? I beg to differ.
Mark – if you want to compare and contrast REST and Web services than do it right. This is crap and you know it. The funny thing is, I’m a REST fan – I just can’t stomach this one-sided bullshit.
I don’t peddle crap, Jeff. It’s a perfectly valid comparison which I stand by 100%. Sometimes issues really are black and white, and this, very regrettably, is one of them.
I would, however, be interested to know what you mean by “do it right”. Are you saying that some things are best done with REST, and others with SOA? If so, please, do tell.
P.S. Loved your shot at UDDI 8-);
The UBR was a really dumb idea and we apologize for making you sit through lectures on a service oriented yellow pages hosted in the cloud
Gee, if only they listened to me back in 2000/2001 when my startup joined on as a UDDI promoter(?) and submitted a proposal suggesting that UDDI servers become Web servers!
A bold statement from Ian Davis on his piece called “SOAP Destined to A Life of Obscurity“. He declares his suspicion that;
[…] SOAP is finally being sidelined into a niche activity.
I think that’s slowly being realized by more and more people. It’s just never fast enough for me. 8-) As I mentioned in the Q&A after my panel session at WWW2005, in response to a question about what would happen to SOAP, I observed that CORBA/OMA is still under development in the OMG right now… but who knew or cared?
And to anticipate Steve‘s reaction 8-), I’m sure what’s going on with CORBA/OMA at the OMG is very important to some folks like banks, telcom, and other LargeCos – as it has been for ages now. But that is most definitely a niche.
I’ve finally revised my RDF Forms specification.
The big changes were to simplify it by getting rid of the SOAP-specific action/intent support (so much for that olive branch 8-), adding support for PUT via the Settable abstraction, and adding a shortcut style of form whereby the method is explicitly declared (though there’s issues with this, as an Ed Note points out).
I also removed a closed world assumption by replacing the use of “indexedBy” with “parameterizedWith” for non-Indexable forms. Darn, those are hard to find sometimes.
As he promised yesterday, Clemens describes his RESTful extensions to WCF/Indigo in a most enjoyable article on his weblog.
I really liked his detailed comparison of the HTTP and SOAP (as-practiced) dispatching models, as well as that of RPC vs. uniform operations. While there were a few little things I disagreed with, they weren’t significant enough to warrant mention, so I won’t.
Unfortunately, I’m not a big fan of his extensions.
I think the mapping he lays out there is reasonable in cases where you’ve already got legacy code with legacy interfaces which need binding to the Web, because you can just annotate those existing interfaces with these extensions. But when you’re developing new code, what purpose do service-specific interfaces serve? Nobody’s invoking them, since they’re just invoking the HTTP methods. So why are they there? I think that can only serve to hide the resource-centric REST model away from developers, and make other tasks more difficult; for example, dealing with resource collections.
I think the general approach to Web based models should resemble HTTP Servlets. Not to suggest that Java, nor inheritance, nor any language-specific feature of Servlets themselves need be used. But instead, just to say that the logical model of a RESTful programming framework should be one which requires “objects” (or “services”, or whatever you want to call them) expose the uniform interface.
FWIW, the best (for my definition of “best” 8-) one I’ve seen so far – though I haven’t vetted it yet – is this nameless Ruby one which is, AIUI, proposed for use as a Rails extension.