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
> -Doug
>
>
>
> *Christopher B Ferris/Waltham/IBM@IBMUS*
> Sent by: public-ws-addressing-request@w3.org
>
> 10/09/2006 04:48 PM
>
> 	
> To
> 	Marc Hadley <Marc.Hadley@Sun.COM>
> cc
> 	Doug Davis/Raleigh/IBM@IBMUS, public-ws-addressing@w3.org, 
> public-ws-addressing-request@w3.org
> Subject
> 	Re: An Example Use of RM's MakeConnection
>
>
>
> 	
>
>
>
>
>
>
> Marc,
>
> Fine for handling request/response I suppose. However, not everything 
> is request/response. How does this work when
> there is no "response" but rather a need to get messages from the 
> "server" to the "client"?
>
> Cheers,
>
> Christopher Ferris
> STSM, Software Group Standards Strategy
> email: chrisfer@us.ibm.com
> blog: http://www.ibm.com/developerworks/blogs/page/chrisferris
> phone: +1 508 377 9295
>
> public-ws-addressing-request@w3.org wrote on 10/09/2006 12:26:07 PM:
>
> > Looking at the message flow, I think WS-RM could make more use of  
> > wsa:RelatesTo instead of inventing a new anon URI. Here's the same  
> > message flow using the WS-A anon URI and making more use of  
> > wsa:RelatesTo and @RelationshipType.
> >
> > I think this formulation removes the requirement for additional WSRM-
> > specific anon URIs, let me know if I missed anything.
> >
> > Marc.
> >
> > Scenario: Client sends GetQuote to server unreliably.  Server wants  
> > to send GetQuoteResponse using RM so it must sent a CreateSequence  
> > before I can send the GetQuoteResponse back.
> >
> > Step 1 - Client sends GetQuote to Server
> > <soap:Envelope ...>
> >   <soap:Header>
> >    <wsa:To> http://stockquote.com </wsa:To>
> >    <wsa:Action> foo:GetQuote </wsa:Action>
> >    <wsa:MessageID> uuid://.../100 </wsa:MessageID>
> >    <wsa:ReplyTo>
> >     <wsa:Address>http://www.w3.org/.../anonymous</wsa:Address>
> >    </wsa:ReplyTo>
> >   </soap:Header>
> >   <soap:Body>
> >    <foo:GetQuote> IBM </foo:GetQuote>
> >   </soap:Body>
> > </soap:Envelope>
> >
> > Step 2 - Server sends an RM CreateSequence to the Client using the  
> > only means it has available - the transport backchannel.
> > <soap:Envelope ...>
> >   <soap:Header>
> >    <wsa:To>http://www.w3.org/.../anonymous</wsa:To>
> >    <wsa:Action> http://...wsrm/CreateSequence </wsa:Action>
> >    <wsa:MessageID> uuid://.../101 </wsa:MessageID>
> >    <wsa:RelatesTo RelationshipType="http://...wsrm/InitReliable">
> >      uuid://.../100
> >    </wsa:RelatesTo>
> >    <wsa:ReplyTo>
> >     <wsa:Address> http://stockquote.com </wsa:Address>
> >    </wsa:ReplyTo>
> >   </soap:Header>
> >   <soap:Body>
> >    <wsrm:CreateSequence> ... </wsrm:CreateSequence>
> >   </soap:Body>
> > </soap:Envelope>
> >
> > Notice the use of RelatesTo with a WSRM-specific @RelationshipType to  
> > indicate that this message is a WSRM-specific response to the initial  
> > request.
> >
> > Step 3 - Client sends a CreateSequenceResponse to wsa:ReplyTo
> > <soap:Envelope ...>
> >   <soap:Header>
> >    <wsa:To> http://stockquote.com </wsa:To>
> >    <wsa:Action> http://...wsrm/CreateSequenceResponse </wsa:Action>
> >    <wsa:RelatesTo> uuid://.../101 </wsa:RelatesTo>
> >   </soap:Header>
> >   <soap:Body>
> >    <wsrm:CreateSequenceResponse> ... </wsrm:CreateSequenceResponse>
> >   </soap:Body>
> > </soap:Envelope>
> >
> > Step 4 - Having not received the GetQuoteResponse, the Client uses  
> > MakeConnection to allow it to flow back
> > <soap:Envelope ...>
> >   <soap:Header>
> >    <wsa:To> http://stockquote.com </wsa:To>
> >    <wsa:Action> http://...wsrm/MakeConnection </wsa:Action>
> >    <wsa:ReplyTo>
> >     <wsa:Address>http://www.w3.org/.../anonymous</wsa:Address>
> >    </wsa:ReplyTo>
> >    <wsa:RelatesTo RelationshipType="http://...wsrm/InitialRequest">
> >      uuid://.../100
> >    </wsa:RelatesTo>
> >   </soap:Header>
> >   <soap:Body>
> >    <wsrm:MakeConnection>
> >    </wsrm:MakeConnection>
> >   </soap:Body>
> > </soap:Envelope>
> >
> > Notice the use of the wsa:RelatesTo with a WSRM-specific  
> > @RelationshipType to indicate that this message is requesting a  
> > response to the initial request message.
> >
> > Step 5 - Server uses the backchannel to let the GetQuoteResponse flow  
> > back to the Client
> > <soap:Envelope ...>
> >   <soap:Header>
> >    <wsa:To>http://www.w3.org/.../anonymous</wsa:To>
> >    <wsa:Action> foo://GetQuoteResponse </wsa:Action>
> >    <wsa:RelatesTo> uuid://.../100 </wsa:RelatesTo>
> >    <wsrm:Sequence> ... </wsrm:Sequence>
> >   </soap:Header>
> >   <soap:Body>
> >    <foo:GetQuoteResponse> 139.0 </foo:GetQuoteResponse>
> >   </soap:Body>
> > </soap:Envelope>
> >
> > Notice the wsa:RelatesTo points to the GetQuote request message and  
> > it is sent using RM (the Sequence header), and that the SOAP Envelope  
> > looks exactly like it would if it had been sent on the original  
> > transport backchannel - meaning, the wsa:To is derived from the  
> > wsa:ReplyTo from the GetQuote request message not the MakeConnection.
> >
> > ---
> > Marc Hadley <marc.hadley at sun.com>
> > Business Alliances, CTO Office, Sun Microsystems.
> >
> >


-- 
----------------------------------------------------
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:26:40 UTC