W3C home > Mailing lists > Public > www-ws@w3.org > April 2003

Re: WS-Addressing and R085

From: Mark Baker <distobj@acm.org>
Date: Mon, 14 Apr 2003 11:19:44 -0400
To: clemensv@newtelligence.com
Cc: www-ws@w3.org
Message-ID: <20030414111944.G2283@www.markbaker.ca>

(taken to www-ws@w3.org)


On Mon, Apr 14, 2003 at 01:58:13PM +0200, Clemens F. Vasters wrote:
> 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.

See, that's the issue.  Application protocols don't (when used properly)
accept messages as input, they accept data.  It's the application
protocol envelope which wraps that content which make the composite blob
a message.

Consider a description of a book;

  <title>Some book</title>
  <author>Some author</author>

That is not a message.  If I send it to you, you have no idea what I'm
asking you to do with it, and I have no expectation of what you might do
with it.  However, if I *transfer* it with an application protocol,
perhaps with HTTP PUT, then the composite thing *is* a message, and you
can understand what I'm asking; to store that data at the URI in the HTTP
request line.

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

But you just said you "write a booking record into a financial collections
system".  That is easily representable as a resource-access action.  What
happens after that initial action (presumably a POST to some URI), could
include fan-out routing of that message, as you describe there.

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

That is consistent with a REST based solution, though you may need
*additional* constraints (i.e. use REST + something else) to help make
integration simpler, for example, and make it O(1) rather than O(N).

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

Also quite consistent with a REST based solution.

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

That depends.  Is the envelope a message?  If so, then the former.
If not, the latter.  Because not all SOAP envelopes are messages.
Consider, as above;

<env:envelope env="...">
    <title>Some book</title>
    <author>Some author</author>
That is not a message until something encapsulates it to provide the
application semantic.

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

And your subset fits very well into the null architectural style[1].
All supersetting demonstrates is an ability to constrain.

 [1] http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_1_1

Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Web architecture consulting, technical reports, evaluation & analysis
Received on Monday, 14 April 2003 11:18:32 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:37:08 UTC