- From: Doug Davis <dug@us.ibm.com>
- Date: Tue, 10 Oct 2006 13:32:01 -0400
- To: tom@coastin.com
- Cc: public-ws-addressing@w3.org
- Message-ID: <OF864E9EF2.B79C1E47-ON85257203.00602C70-85257203.00604FBF@us.ibm.com>
Tom,
I'm not talking about the failure case - look at the message flow that
started this thread.
-Doug
Tom Rutt <tom@coastin.com>
10/10/2006 01:26 PM
Please respond to
tom@coastin.com
To
Doug Davis/Raleigh/IBM@IBMUS
cc
public-ws-addressing@w3.org
Subject
Re: An Example Use of RM's MakeConnection
Doug Davis wrote:
>
> Also, let's not forget that WSA's definition is pretty clear that anon
> means the _current_ backchannel. RM's anon URI allows for the
> messages to flow over a subsequent backchannel - this is a change to
> the semantics of Anon. Doesn't seem like having a ref-p or some
> wsa:RelatesTo change those semantics is kosher.
Lets assume that wsrm is not in use. If the backchannel for a request
is not available (due to tcp faulure perhaps) the http response will not
flow.
The user will be made aware of the underlying transport fault, but it
cannot get the response using normal ws addressing.
But wsrm has an additional mechanism, to allow unsent responses, from
specific identified backchannels ("this is me again") using the
makeConnection message.
If we view what we are doing in this way, the make connection stuff can
be made part of the behaviour of the wsrm implementation
(e.g, retaining queues for each idenfitied back channel, rather than
the ws addressing implementation, directly.
After all, WS Reliable messaging protocol is outside the scope of the ws
addressing prescribed behavious (e.g, reply message header requirements).
Tom
--
----------------------------------------------------
Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744 Fax: +1 732 774 5133
Received on Tuesday, 10 October 2006 17:32:12 UTC