RE: concatenating web services

> -----Original Message-----
> From: Rand Anderson [mailto:randerson@macgregor.ws]
> Sent: Monday, February 10, 2003 9:02 AM
> To: Don Box
> Cc: xml-dist-app@w3.org
> 
> > The interesting question (to me at least) is whether or not B is an
> intermediary or an ultimate receiver.
> > In my mind, B is an ultimate receiver, however, strictly speaking,
one
> could model this such that B was an
> > intermediary between A and C (albeit an "active" intermediary).
> 
> I hadn't thought about it much, now I'm interested as well - your
focus on
> and use of the term 'ultimate receiver' has me questioning my
assumptions
> about how to think about this. Who/what determines whether a node is
an
> 'ultimate receiver' or some kind of 'intermediary'? Is it more the
node
> itself, in declaring its services and role? I guess if the node
doesn't
> support routing, then that would be equivalent to saying "I'm just an
> ultimate receiver". Or is it the consumer, based on context of use?
I've
> been assuming the latter, and that by supporting routing, even if you
> think
> of yourself initially as an 'ultimate receiver', you then better
support
> modularity, and position for emergence, serendipity, re-use, and other
> good
> and interesting things.
> 
> I should go re-read and study what the spec suggests, I guess, at
least to
> start, to see if there is any thinking on this there.

For what it's worth, the team I work on (we build the SOAP stack for our
company's operating system) has done a fair amount of navel
contemplation on this one. Our primary conclusion was that because SOAP
has no notion of message identity, intermediaries have a great deal of
freedom. That stated, here are some guidelines to think about:

1) Intermediaries SHOULD NOT contradict the intention of the original
sender and the ultimate receiver. When these two conflict, the ultimate
receiver's intention wins.

2) Intermediaries SHOULD NOT change the "action" of the message. If you
are going this far, consider becoming an ultimate receiver.

3) Intermediaries typically get used to address limitations in
request/reply protocols, both the transport and the app kind.

DB

Received on Monday, 10 February 2003 12:12:08 UTC