Steve Maine reports
on Don Box’s latest presentation that asks a very good question; why? He summarizes;
WS-Addressing is something that really should have been included in the original SOAP specification. However, when SOAP was written nobody was really thinking about transports other than HTTP. As a result, pure SOAP relies on the characteristics of the HTTP transport to convey addressing information. For example, a pure SOAP message does not contain any information about the address to which it was sent – that information is carried by the transport and is lost once the message is pulled off the wire.
Paraphrase; Doctor, doctor, it hurts when I lose information that I pull off the wire!. Sigh.
A SOAP envelope is not a SOAP message, and pretending otherwise turns a
perfectly good document wrapper into a perfectly crappy application protocol.
Sorry Don, you were
wrong then,
and you’re wrong now.
All
this
just because the layering got totally screwed up by the broken
requirement of
protocol independence?
Egads. Time to check back with those first principles, me thinks.
The
SOAP response MEP,
though not without problems, at least gets the layering right. And with this same layering,
the best that could likely be done for a GET binding – even though it may have had deployment
problems of its own – was
described
nearly three years ago. Too bad it was rejected. If only we knew then what we know now!
Oh, wait, … 8-)
He writes;
Perhaps REST versus WS is really about private and public interfaces.
That’s exactly right, but exactly opposite of what he suggests; that
SOA is better for public interfaces, while REST is better for private.
REST’s uniform interface is superior for public interfaces because
its semantics are, well,
public. Each new
interface that is presented to a customer via SOAP/WSDL introduces a
barrier to entry because the customer has to learn the semantics of
that interface. Reusing a pervasively deployed one presents no such
barrier.
IMO, before any new WG is chartered at the W3C,
the objective of that WG should be validated for architectural consistency
with the Web (you know, the thing it’s trying to
lead to its full potential?).
Here we have a WG whose
primary objective is to produce a spec which will, prima facie based upon its
charter,
violate a key architecture principle (what, it’s just “good practice”?) of the Web;
identify things with URIs.
How can you get any more architecturally inconsistent than that?
I’m not upset, I’m just confused. How has it gone this far?
Mass hysteria
should not be an excuse. It’s a good thing that OASIS seems to have done the bulk of
of the WS-* heavy lifting, leaving just four
at the W3C. But that’s three (SOAP is goodness)
too many, and it could have been much worse for the W3C.
Anyhow, best of luck Mark,
you’re gonna need it.
Update: just noticed
this comment from Jorgen;
As they say, “You can’t finish unless you start”.
Unless you’re finished before you start, of course.
He writes;
I don’t think people are embracing REST services because of architectural purity (the rest of the Web isn’t pure REST, so I don’t know why this would be). Rather, they embrace it because it’s easier in a lot of cases. There is no reason that SOAP couldn’t be the same, except that toolkits hide raw XML and you have to know how to get it.
To the first point, yes, certainly, they embrace it because it’s simpler and easier.
Absolutely. As we’ve seen, they often
screw up,
but even then it’s very often preferable to SOA.
To the second point, there actually is a critical reason (in addition to
the “hide the XML” problem) why SOA/WS cannot be as simple as REST; that the
architectural constraints
which induce the bulk of the simplicity
in REST (uniform interface, self-description), are eschewed by SOA/WS. Isn’t it ironic
that their raison d’etre – service specific interfaces – is the reason they will fail
to see widespread deployment? I think so. 8-)
After much time and anguish, “application/soap+xml” is finally a done deal;
RFC 3902
Wow, the shit’s really hitting the fan this time, isn’t it?
Go go stop energy!
The latest entrant is a surprise (to me at least);
Simon Fell,
author of
PocketSOAP.
Though Simon and I may not like the stack for different reasons, any way you look
at it, WS-* seems to be on its last legs.
Onwards and upwards to true loosely coupled, document exchanged based
distributed services! You know, the World Wide Web.
Patrick asks
for clarification of my
previous statement
about how, IMO, REST proponents generally like SOAP and dislike SOA. He writes;
I consider myself a REST convert, to the extent I think I understand it and its incarnation in HTTP. Though I don’t understand the position above. Is there even a concrete definition of SOA with which to make this statement?
I thought SOA was a fairly innocuous term, being so vaguely defined that an SOA could be built using REST and HTTP.
“innocuous”? I wouldn’t say that. I think it’s actively harmful as a name for an
architectural style. As I see it, “SOA” means different things to different people. As such,
it’s almost entirely useless since it does nothing to constrain how
one might go about building distributed systems. That’s why I don’t like it.
It’s for the same reason that I wouldn’t recommend the
null architectural style
as a guide from which to design
an architecture; all REST and SOA based architectures are instances of the null
style too! 8-)
According to Michael Curry,
Forrester has a
report on REST vs. SOAP
which concludes saying basically that SOAP is a better long-term bet.
First of all, the debate isn’t REST vs SOAP, it’s REST vs. SOA. SOAP can
be used in the context of many architectural styles, and the SOAP spec
itself says basically nothing about which should be used; though it does
have explicit support for RPC and REST (by virtue of some design decisions
made regarding the HTTP binding, thanks to yours truly). Also, Forrester’s
claim that REST proponents rag on SOAP is backwards; we like SOAP, mostly.
We just don’t like SOA.
Also, apparently the principle argument against REST is
that it lacks standards support. Seriously?! Ever heard
of URIs and
HTTP? You know,
two of the most wildly successful standards in the history of
distributed computing? How one can compare WS-* with 100s of millions
of deployed and currently-interoperable servers and clients, and then
conclude that the latter suffers from a lack of standards
support, boggles my mind.
Michael also adds his own critique;
Randy makes some good points on the standards issue that I failed to bring up. He doesn’t bring up the fact that REST breaks the MVC paradigm, however.
Who knew that MVC was a benchmark by which large scale distributed systems
are evaluated? Back to the drawing board for me! 8-)
It’s been a long time coming, but the Web services stack finally
catches up to where the Web was 15 years ago, and where email was 20
years before that;
exchanging documents
over the Internet. Happy days! <groan/>
Facetiousness aside though, it’s unfortunate that the layering is
still so butchered; WS-Transfer just reinvents HTTP on top of SOAP on
top of HTTP. And for what exactly? They could have just reused
HTTP’s methods which are already outside the envelope, the way most
people use application protocols, and still get all the goodness of SOAP. Who
the heck wants to try to bootstrap a whole new Web when the one we’ve got is
doing just fine, thank-you-very-much?
It’s also curious that POST is missing, yet CREATE has been added.
This seems an obvious attempt to equate the uniform interface with CRUD,
but it’s unclear whether that’s to try to restrict the range of
possible applications WS-Transfer could be used for, or because the
authors honestly thought nothing was being lost with this omission?
Knowing many of the authors, I bet the latter, but who knows …
As interesting as this is to see though, I don’t see anybody choosing
to use it over vanilla HTTP or RESTful SOAP+HTTP. I’d be interested in
anybody’s thoughts who disagreed with me on that.