Patrick reminds me
how similar the “XML is a universal solution” position is to the that of
SOAP as similarly universal. In both cases, the premise is that by being
independent of data models (for XML) and application interfaces (for SOAP),
broad applicability is achieved.

Now contrast this with the Web/Semantic-Web position, that
by constructing a generic
data model
and generic
application interface,
broad applicability is achieved.

Two interesting hypotheses, for sure. If only we had some
objective manner to evaluate them!

The real issue with protocol independence, I believe, is the
word “protocol”; that the two camps in this debate – the Web/Internet
folks, and the Web services folks – each have their own, quite
different, definition of the word. For Web services proponents,
“protocol” means one thing and one thing only; a spec whose job it is
to move bits from point A to point B over a network.

Meanwhile, for the Web/Internet crowd, “protocol” has a much broader
definition. In common use, it encompasses the “bit moving” specs, but
also others which do a lot more than simply move bits (more below).
Some even (properly, IMO) refer to the data formats, such as HTML, as
protocols, though you don’t see that too often any more.

As if this disconnect wasn’t bad enough, another – interface
constraints – compounds the problem. 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). This has enormous benefit, with the big one being
it permits the
mechanics of mapping onto the network
to be optimized for the semantics; consider that without GET, HTTP wouldn’t have
needed a bunch of features, in particular caching. When semantics are detached
from the “wire format” (as with BEEP et al, as mentioned previously), it’s
optimized for no particular application, thereby
resulting in poor performance
for practically all applications.

I’ve drawn a diagram that I hope helps explain these two different
views;

Hopefully you’ll at least see the fundamentally different visions
of the stack in play here, and perhaps better appreciate my concern about
“protocol independence”. Protocols play a much more important role in the
stack on the right than they do in the one on the left!

Greg Stein writes;

The Atom publishing protocol *is* HTTP specific. Completely. I haven’t
heard of any desire nor attempt to deal with protocols other than HTTP. So
I’d suggest that being “specific” is not a problem.

Steve promptly follows up. In response to my comments about self-description, he writes;

Reading over Marks comments, I’m having a hard time determining if this is a technical criticism or more of a complaint about the division of responsibility between the standards.

I was just pointing out that the envelope he described would not, in fact,
be self-descriptive. There are many possible implications of this depending
upon your POV, but yes, in (my view of) Steve’s view of the stack, SOAP should have a
dependency on WS-Addressing, and should have defined the equivalent of wsa:Action.
In my view of the stack, it should not have, and in fact there should be no
WS-Addressing because application protocols already provide their own addressing
mechanism.

And a slight historical correction; “TCP” circa 1974 was in fact the functional
equivalent of TCP/IP, with the two layers munged into one. “The Split” into
separate specs and layers
occurred in 1978.

I absolutely would consider being independent of WS-Transfer a good thing, if my applications hard dependency on the protocol was making it really hard to accommodate the new requirements I wanted to satisfy.

How?!?!?! WS-Transfer provides the application semantics that an app
is hardcoded to use, just as a stock quote app would be hard coded to use
getStockQuote. You can’t just swap in WS-Notification, IMAP, POP3, or any
other application protocol and expect the app to work the same, because
they provide different application semantics!!

You can’t escape it; protocol dependence is a necessity, since protocols
are the basis of all interoperability. Show me a working Web service, and
I’ll show you where it’s protocol dependent.

This is the fundamental misunderstanding of Web services, and IMO what’s
preventing a majority of Web services proponents from realizing that the Web
is what they’ve been looking for all along.

I think that’s where we are with HTTP right now – it works in the simple case, but there’s all this other stuff we want to be able to do (security, transactions, duplex communication, end-to-end reliability, etc). Mapping all that stuff into HTTP is turning out to be counterproductive and quite hard. However, those problems are tractable if we assume an infoset-centric view of the world. When the status quo doesn’t work any more and something better is available, it’s time to change the status quo.

The status quo works just fine. I hear folks make the claim to the contrary all
the time, but have yet to see an example of a Web service that couldn’t be done in
an all ’round superior manner using HTTP and URIs. I’m not claiming that an example
can’t be found, only that there just aren’t that many, at least once you’ve chosen to
use coarse grained, document based messaging.

… to my latest.
He writes;

Given that in Mark’s world a SOAP envelope is not a SOAP message, then I’m assuming that a SOAP message must logically be {SOAP envelope + other stuff}. Considering Mark’s position with respect to REST, I’m assuming that the magical “other stuff” is a resource URI and an HTTP protocol verb. I don’t want to put words in Mark’s mouth, but that’s my interpretation of his view of the world.

Pretty close, yes, but the “other stuff” is more than just the HTTP envelope of
URI/method/headers, it’s also the stuff contributed by TCP/IP, Ethernet, or whatever
else frames the SOAP envelope.

If my assumptions about Mark’s view are correct, I have a hard time seeing why it’s so important that this “other stuff” be externalized from the envelope. I don’t see why including the destination URI and protocol verb as headers is such an offensive concept. This is, after all, exactly what WS-Addressing does – it puts all the information necessary to process an envelope inside of the envelope itself, so the envelope is totally decoupled from its delivery mechanism. What am I missing here – why is having the envelope stand on its own such a terrible thing? It’s still a “document wrapper” at that point – one that happens to be fully self-describing, in fact.

Actually, it’s not in fact, self-descriptive, which is a large part
of my complaint and concern.

If you worked your way up the stack,
outside-in through the message, each frame tells you how to
process the next; the ethernet frame includes a field which says that it
contains an IP packet,
the IP packet contains a field which says
it’s a TCP packet,
the TCP packet contains a port number which says
it’s an HTTP message,
and the HTTP message contains a header which says
it’s a SOAP message.
Along the way, of course, the semantics of the message are determined,
including the application semantics provided by HTTP; the operation,
message endpoints (the request URI), and the various headers. But
there is nothing in the Ethernet, IP, TCP, HTTP, or even SOAP specs
which says to expect that there are actually
new
operations, and
new
endpoint references
which override those of HTTP, within the SOAP envelope itself.

Some more good comments and questions …

I’m curious as to what’s most important to Mark – constraining the number of verbs or using HTTP as a universal protocol. Hypothetically, what if WS-Addressing was written such that the wsa:Action URI was constrained to 4 verbs, each of which had a direct 1:1 correspondence with an HTTP protocol verb? That’s sort of the thought experiment I see in the WS-Transfer protocol. That’s a compromise that offers REST-style universal semantics while still keeping all the information required to process an envelope inside of the envelope itself. Along with that comes the ability to use any mechanism of moving bits from point A to point B and removes the strict reliance on HTTP.

What’s most important, IMO, is the constrained interface. So yah, I’d
be all for stuffing more things into the SOAP envelope if wsa:Action were
constrained to uniform interface semantics. But such an envelope, for all
the same reasons of self-description above, would only be suitable to be
used on top of transport protocols (like TCP), not application protocols.

What you describe in that last sentence is “protocol independence”, and
I consider it the root of all WS-Evil (so to speak). HTTP isn’t a bit moving
protocol, TCP is. HTTP provides the application semantics, just like WS-Transfer
does. Would you consider it a selling point that your WS-Transfer-using app
was made independent of WS-Transfer? I didn’t think so. That’s how absurd I
see the requirement that apps which use HTTP should do so independent of HTTP.

I think he’s incorrect about his first statement – to be technically correct, you’d have to say that WS-Transfer reinvents HTTP on top of SOAP on top of any number of network protocols, one of which happens to coincidentally be HTTP

Yes, true. I just like saying “HTTP over SOAP over HTTP”. 8-)

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.

Jim
has published a
great article
about WSDL – well, modulo the “protocol independence” bit, of course 8-).

But I wonder, how many Web services proponents would agree with him? His
views have, as I recall, have been rather controversial.

Ordinarily this wouldn’t be such a big deal, but from a Web services
perspective this is basic interop that’s at stake; if a smart guy like Jim can
interpret one thing from a WSDL document, and that interpretation is different than
the publisher intends, or others read, then Web services interoperability simply
will not happen.

The WSDL 2.0 spec doesn’t help much here, and seems to go out of its way to be
ambiguous. It
describes an operation
like so;

An operation is an interaction with the service consisting of a set (ordinary and fault) messages exchanged between the service and the other roles involved in the interaction, in particular the service requester.

Wha? Somebody answer me, please; is it an operation ala an IDL operation?
If not, what is it, and how does that differ from Jim’s interpretation?
Where’s the
contract?

ROTFL!
(link) [del.icio.us/distobj]

Sounds great, but do we really want to burden every writable service out there with this requirement? Why not take it upon ourselves with a personal server with generic comment (or any POST for that matter) following code ala HEP?
(link) [del.icio.us/distobj]

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-)