Ah, gotta love permathreads. 8-)

Stefan did such a fine job with his response, that I think I’ll just “+1” it (yes, including the agreement with Chris, gasp! 8-) rather than respond myself. Thanks, buddy.

I also wanted to add, in response to Chris, that I only brought caching up as an example of something in HTTP that wouldn’t make sense to have if its application semantics didn’t include GET. I didn’t mean to imply that caching couldn’t be implemented without modifications to SOAP. I was actually specifically thinking about two changes to SOAP which would be required for a couple of important optimizations, both having to do with coarse grained messaging, as SOAP is intended to support. The first would be a framing optimization, the “jump” feature (akin to a chunked transfer encoding). The other would be a push away from strictly interpreted XML, since XML doesn’t support streaming due to the fact that an application can’t make much in the way of forward progress until the end of the message has arrived, lest the message end up malformed.

I also just noticed this MEST response from Steve where he realizes that MEST seems familiar;

The issue was that for at least some people, that paradigm shift had already happened and confusion arose when it was given an unfamiliar name.

Hmm, there’s seems to be a lot of that going on. 8-) It’s why I’ve claimed for about 5 years now, that the Web is what Web services is trying to be. It’s also why I argue that MEST is a specialization of REST. Or, in Steve’s words, that “every behavioral entity works by processing messages” is a special case of “every resource is a container for state”.

Is my spam filter on the fritz, or is anybody else seeing a whole lot more spam in their (filtered) inbox? I usually get 2 or 3 a day, but the few days I’ve received an average of about 25 a day.

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

Bastard! First he invents the Web before me, and now this! It was close; I think I was # 50-odd million on the list)! Timbl, my nemesis. 8-) P.S. Congrats!
(link) [del.icio.us/distobj]
It goes live! It’s too bad it uses SOAP/WSDL rather than HTTP/XML or SOAP/HTTP, but hey, it’s some form of access to something that was previously unreachable (unlike their search APIs), so therefore a Good Thing.
(link) [del.icio.us/distobj]

As seen on the www-ws list. No commentary required. 8-)

I installed SOAP on my computer, but I now want to remove it.  Please
provide the mechanism in your software to allow the public to remove it and
its pop-ups.  I want my computer back when I make the decision.  I have
tried to remove the soap files only to find the web site window "Clean Now!"
continues to pop-up.  It is very upsetting that you do not provide this
option where you list: "Click here to learn more" and "Continue what I was
doing".  Again please allow this choice.

Otherwise when computer conversation comes up.I will be sure to strongly not
recommend the SOAP software.

I would appreciate if you could email me the info how I can stop the soap

I love stuff like this; a list of grand challenges for IT in the next 20 years. Too bad some reward money wasn’t allocated! 8-)

Here’s one up my alley;

Scalable ubiquitous computing systems: Not only do we want our devices to interact predictably and reliably, we also want them to interact with every other conceivable device — but the complexity of many systems grows much faster than the number of nodes in the system. Computing engineers need scalable design principles: developing and applying them is the goal of this challenge

Hmm, I dunno, that sounds pretty tough. And in only 20 years? Systems whose integration complexity scales O(N) or better? They’re talking nonsense. I bet ya that’s nigh impossible. sigh

Ouch! Who wrote that one?! It must be a Web services proponent, because folks familiar with Internet scale development know that we’ve had that problem licked for (at least) the past 40 years. “Scalable design principles”? I give you interface constraints.

With the publication of this trio of specs, I expect the WG is now finished. Phew!

Pay close attention to their work, in particular SOAP, MTOM, and XOP (RRSHB can safely be ignored). If anything remains of Web services in five years, this’ll be it.

The specification formerly known as RFC 2396bis is now known as RFC 3986, aka STD 66.

“David Fallside rocks.”. Amen to that. He was supposed to leave the WG in 2002 IIRC, yet stuck it out for the 4+ years. He’s the Steven Pemberton of XML messaging. 8-)
(link) [del.icio.us/distobj]