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