Gudge graciously
continues the discussion.
Here’s my lengthy response that I spent far too much time writing, then rewriting… despite
having two Monday deadlines! 8-O
Regarding my concern that WS-A doesn’t require placing the destination address
in, for example, the HTTP request line rather than the wsa:To header, he writes;
I really don’t see how WS-Addressing can specify this given that the spec itself doesn’t know anything about the underlying protocols [...]
Let me stop him there, since that’s actually my issue; IMO, WS-Addressing
should know things about the underlying protocol. As I
described
when I first raised it, this issue is more about the whole concept of “protocol
independence” than it is about anything to do with WS-Addressing.
He then responds to my plea to spend some serious time focusing on the
difference between application and transport protocols;
Now, I think I have some idea of the difference between the two, although I’m obviously no expert; transport protocols just move bits around without any regard to what those bits are, whereas application protocols, while still moving bits around, care somewhat about what those bits look like.
Hmm, that’s difficult to respond to because it’s not very specific! 8-O
But Gudge didn’t appear mention what I personally believe to be the biggest distinction
between the two; an application protocol defines application semantics.
This relates closely to my earlier comment that there’s no analogue to
such an entity in the historical CORBA/DCOM/DCE style stacks. The reason for
this makes total sense though; when you need to support arbitrary application
semantics, the only stack that would make any sense would need to separate those
semantics from the “thing that frames the bits”. And that’s where the whole
concept of “protocol independence” comes from, and as I said, it makes total
sense when arbitrary application semantics are required.
Now, consider a system that only has a single application interface, like,
say, email, a tuple space based system, or indeed any system built with a
coordination language.
Does this layering make the same
sense there? I don’t believe so. There’s no need to be independent of that
layer because there’s no need for any other application semantics. This allows
the optimization of the framing and features to the application semantics.
For example, had HTTP not had a GET semantic, then there’d be no need for
caching. Now consider that with a “protocol independent” equivalent of GET, ala
WS-Transfer,
you’ve lost the ability to optimize the transfer features for that case. So
while you could certainly try to deploy WS-Transfer, it would necessarily
perform a whole lot worse than HTTP because optimization would require
modifying SOAP. At least HTTP is optimized for the general case because
it is the result of the merging of the two layers we’re talking about.
Gudge then clarifies that his background includes messaging and queueing
systems, which I presume is a reference to MOM. That’s great; it’s good to
have experience with varied architectural styles. I wonder then, if he was
aware that a MOM based architecture natively (i.e. it can be abused) uses
the same uniform interface constraint as REST (although it goes further
to constrain the interface to a single “ProcessMessage” semantics, ala
MEST)?
It’s not commonly recognized that MOM adopts this
constraint because the fact that there’s only ever a single application
semantic means that the semantic can be excluded entirely from the message
resulting in a pure looking document-in/document-out system with no
operations anywhere. I emphasize “looking” there, because REST is just as
pure a document-oriented architectural style as MOM, only because it permits
operations other than MOM’s one, those operations need to be made explicit
in the message… which is why HTTP has “POST”; it’s the name given to the
same “ProcessMessage” semantic from MEST/MOM.
Finally, regarding my comment that I didn’t really care what the outcome
of the resolution of the issue was, Gudge writes;
It seems somewhat odd, to me, to raise an issue and then not care about the outcome. Like shooting for a basketball hoop but then immediately leaving the court, without caring whether the shot went in or not. I guess this means that if the TAG decide that the decision made by the WS-Addressing WG was OK, then Mark won’t push back.
Ah, minor misunderstanding there. What I don’t care much about is – assuming
that the TAG agrees the WG needs to remedy the problem – how the problem
is addressed by the WG. Certainly, if the TAG, after considering my issue, decides
that it wasn’t a problem after all, I’ll have a lot to say about that. 8-)