- 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