Jon Udell urges the REST movement to not dismiss SOA.
Specifically …
Now that the benefits of REST are abundantly clear, it’s time to circle back and ask when REST isn’t sufficient. The answer is that we’ll need the kinds of capabilities WS-* provides as our point-to-point, client/server-like applications evolve into webs of communicating services.
Yes, absolutey, we’ll need the capabilities that the
WS-* stack provides (for the most part). But do we need the WS-* stack
itself to provide those capabilities? I’m certainly all for trying to reuse
existing specs where that makes sense. The issue though, is that with
most of them, they explicitly or implicitly require disregarding
a key contraints of REST, disrespecting Web architecture, or both.
WSDL’s probably the poster child for this, as its raison d’etre is
primarily to encourage rejection of REST’s uniform interface.
The good news is that not all of the Web services specs have this problem.
Some off the top of my head that I consider more or less workable on
the Web (not to suggest that they’re otherwise without fault, and also
not to suggest I’ve had a serious look at every spec out there, even
these) include SOAP, WS-Security, and SAML. If that’s what Jon has in mind,
then we’re good to go. But if he was thinking about the likes of UDDI, the
various reliability specs, transactions, etc.., I’d have to disagree with
him. We need capabilities provided by solutions which were built with
the Web and REST in mind, like those of the Semantic Web and
ARRESTED.
Chris points to,
and agrees with, some
words
from my old dist-obj buddy
Stu Charlton.
Those words include this snippet;
There are numerous SOAP successes today that are invisible to the blogosphere, because their inside corporations. Millions, if not billions of dollars of transactions run through SOAP at this very moment.
I’m confident that’s true.
But correct me if I’m wrong, but wasn’t the objective of “Web services”
to build a universal, Internet (inter-corporate) scale,
application-to-application integration platform? If so, then what exactly
does pointing out that it’s primarily used for intra-corporate
integration demonstrate?
My point has
always been
that Web services are unsuitable for Internet scale integration, and Stu’s
observation just reinforces this for me (not that it needed reinforcing,
of course 8-).
Via Danny,
a question from
Julien Boyreau;
URI is first-class pillar in SemWeb AND Rest : do you know if there are large bridges between REST and SemWeb ?
There are a couple I’m aware of.
- Hash vs. Slash – when using
URIs with hashes to identify resources, REST’s resource identification constraint
(that resources be identified by a single datum, the URI in the case of the Web)
isn’t being respected
- RDF and media types –
the Semantic Web has a self-description problem in that there’s no path from an
application/rdf+xml OWL or RDFS message to the axiomatic triples it encapsulates.
Did the sender intend to communicate those triples to the recipient, or not?
More on that last point here.
Excellent comparison of XForms and Web Forms 2.0
(
link) [
del.icio.us/distobj]
Sean McGrath:
So, the next time somebody says to you “lets just use SOAP”, say “Great!” and then ask him/her for a quick run-down of the proposed conversation models, the synch/asynch selections, the granularity, the semantics of the payloads. I’ll bet you that nine times out of ten none of the above will have been thought through.[…]
Architectural properties don’t appear out of thin air, they emanate from
the principled application of architectural constraints. No constraints,
no properties.
What if Web services fail and people fail to understand why?
” Delta’s Paul Matsen says the airline is changing because the food-sale program is difficult to manage, causes confusion and goes against Delta’s push for simplification.”. Free snacks as an architectural constraint.
(
link) [
del.icio.us/distobj]
Representations which aren’t, considered harmful … and costly 8-) Awesome.
(
link) [
del.icio.us/distobj]