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-)
no comment until now