RE: WS-Addressing and R085

-----Original Message-----
From: Mark Baker [mailto:distobj@acm.org] 
Sent: Montag, 14. April 2003 03:19
To: Clemens F. Vasters
Cc: www-ws-desc@w3.org
Subject: Re: WS-Addressing and R085

Hi Mark,

>[...]
>
>It doesn't sound like any of them use application protocols though.  I
agree that *transport* protocol neutrality is a Good Thing.  But
application protocol neutrality >is a Very Bad Thing.  Unlike transport
protocols, application protocols include information which effects the
application semantics of the message (which is why they're >called
application protocols, of course 8-).

Maybe I don't even want an application protocol that governs the
message. Maybe I think that the message in itself is expressive enough
so that the application knows how to deal with it. Once a message sits
in a message queue waiting to be processed in a batch run, I don't
really care whether someone PUT it there, POSTed it there or how it
otherwise got there. 

In my world, contrary to your RESTish world, it's much less likely that
I am talking to a well-identifiable resource than to dozens or hundreds
of different buckets that are and can be identified only by the content
of messages and their interpretation based on rule-sets (in other words:
they are purely data-driven). If you write a booking record into a
financial collections system that gets split up into 534 different
bookings across four systems (and I am not exaggerating), the last thing
you think of is "accessing a resource". Such systems are so much in flux
internally, that anything that you could identify uniquely as a
"resource" may be slashed into dozens of independent pieces the next
time you look. The most stable "resource" is something that gives you a
report on the current state of things. All you want in such environments
are messages in queues that flow through pipelines and that get split
into more messages in more queues. All you will want to deal with are an
opening and a closing angle bracket and lots of stuff in the middle from
which you pick the pieces you are interested in.  

Requiring the presence of an application protocol that additionally
governs the interpretation of messages is an entirely arbitrary
limitation. In my view, bindings to application protocols such as the
HTTP binding do exist so that there is consensus on how "web services"
(I can't say how much I've started to hate the "web" in that term just
because of these type of discussions) shall work on that particular
application protocol.

If I choose to take a SOAP envelope with all the goo that it contains,
print it, tie it to the foot of a carrier pigeon and send it back to its
home loft, will I require it to say "PUT!" or "POST!" whenever it gets
there? Or will the envelope be wrapped in another envelope that says
that?

So, getting to the heart of the problem, which is "I want to use HTTP,
because it serves billions very well": True, but that particular
protocol is only used at the surface. Once the data makes its way into
the core of systems, one-way messaging pipelines, content based routing
and batch processing rule the place. HTTP is a nice gatekeeper. I would
argue that neither Amazon nor Google nor Hotmail scale because they're
using HTTP -- even quite to the contrary. 

Lastly, I have a hard time seeing how one can achieve the required
transport independence given a pre-defined application protocol that is
layered on top of -- at the very least -- a set of assumptions about
transport (such as bidirectionality).

Conclusion: I think I understand well where you are coming from and why
you are saying what you are saying, but I can't agree on the quite
arbitrary limitations your preferences put on my preferences. Looking at
it from the other side, your subset (request/response, app-protocol
governed messaging) fits very well into my superset (any style data
flow, message on bare transport or governed by app-protocol).


Best Regards,
Clemens

Received on Monday, 14 April 2003 08:03:35 UTC