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
usage.

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]