Re: An Example Use of RM's MakeConnection

+1

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 02:03:27 PM:

> This looks like a layering problem.
> 
> The client and server would like to establish a virtual connection, 
> so that if either the request or response is dropped it can be 
> retried.  Normally I would expect a two-step process in which a 
> connection is first established then used for any number of 
> application-level operations, including request-responses and/or 
> one-way messaging either way (always keeping in mind that this is 
> not proper use of HTTP unless you consider each side's message queue
> as a resource, in which case I can't see a thing in the world wrong with 
it).
> 
> As far as I can tell, the magic URI in this case is a cue to the 
> server to establish a virtual connection if it needs to (I would 
> expect that if the referenced connection already existed, the server
> could just use it and dispense with the RM create sequence).  The 
> wire trace provided overlaps the "create the sequence" and "use the 
> sequence" steps.
> 
> The ReplyTo should be application-level, so it should be something 
> like "virtual connection 1234 upstream" (arbitrarily calling the 
> client-to-server direction "upstream").  As such, I don't think it 
> should be based on the WSA anonymous URI, but instead on something 
> with RM baked into the name.
> 
> At the SOAP level, the server gets a normal request message with a 
> ReplyTo of "virtual connection 1234 upstream".  That's not 
> anonymous, and it's not none, so it's up to the server to decide 
> what to do.  We say that it SHOULD NOT use the SOAP response 
> message, but that just means "make sure you know what you're doing."
> So for example if connection 1234 had already been established, the 
> server could go ahead and send back the reply as the SOAP response 
> (maybe with some other RM acks or whatever).  Or if a handshake 
> needs to take place first (and we can't piggyback the response with 
> the server's side of the handshake), then the server's side of the 
> handshake goes back as the SOAP response, and the application 
> response comes back as the SOAP response to some other request. 
> This is also in line with the core and SOAP binding.
> 
> So (back at CR33), RM can create its magic URI and define behavior 
> for them, and we just need a way for the server to advertise "I 
> understand virtual connections and I can accept magic RM URI as 
> ReplyTo."  This is compatible with either wsaw:Anonymous="optional" 
> or "prohibited", since these make no statement about what other URI 
> might be acceptable besides anon.  It's not compatible with 
> "required", but that's to be expected.  Required means "I will only 
> deliver responses in the SOAP response message of the current 
> instance of the request-response MEP".
> 
> Strictly speaking we could close this with no action, but CR33 gives
> a use case for providing some tools and guidance on the "What URI 
> are acceptable besides anon and none?" question, instead of punting 
> it as we currently do (BTW, this was also one of the handful of 
> consensus points that came out of the async task force).  IMO, the 
> basic two-connection HTTP case would also benefit from a way to say 
> "you can put HTTP URI in response endpoints." as opposed to just 
> "you MUST/MAY/MUST NOT use anon (or none)".
> 
> 
> Doug Davis wrote: 
> 
> Bob asked me to send a set of example flows using MakeConnection in 
> the hopes of helping people's understanding of its usage model. 
> Below is a very simple request-response message flow. The WS-RM spec
> also has an example message flow that shows how the RM anon URI 
> template can be used in a more interesting pattern - a notification 
> scenario - sort of like a one-in/many-out scenario (see section C.6 in 
> http://docs.oasis-open.org/ws-rx/wsrm/200608/wsrm-1.1-spec-cd-04.pdf ). 
> 
> 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://...wsrm/anonymous?id=...1 </wsa:Address> 
>   </wsa:ReplyTo> 
>  </soap:Header> 
>  <soap:Body> 
>   <foo:GetQuote> IBM </foo:GetQuote> 
>  </soap:Body> 
> </soap:Envelope> 
> 
> Notice the wsa:ReplyTo uses the RM anon URI template.  If the Server
> didn't need to use RM then it could just use the transport 
> backchannel to send the GetQuoteResponse if it wanted (but that 
> would be boring :-) 
> 
> 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://...wsrm/anonymous?id=...1 </wsa:To> 
>   <wsa:Action> http://...wsrm/CreateSequence </wsa:Action> 
>   <wsa:MessageID> uuid://.../101 </wsa:MessageID> 
>   <wsa:ReplyTo> 
>    <wsa:Address> http://stockquote.com </wsa:Address> 
>   </wsa:ReplyTo> 
>  </soap:Header> 
>  <soap:Body> 
>   <wsrm:CreateSequence> ... </wsrm:CreateSequence> 
>  </soap:Body> 
> </soap:Envelope> 
> 
> 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> 
>  </soap:Header> 
>  <soap:Body> 
>   <wsrm:MakeConnection> 
>    <wsrm:Address> http://...wsrm/anonymous?id=...1 </wsrm:Address> 
>   </wsrm:MakeConnection> 
>  </soap:Body> 
> </soap:Envelope> 
> 
> Notice: no wsa:ReplyTo since its a one-way 
> 
> Step 5 - Server uses this backchannel to let the GetQuoteResponse 
> flow back to the Client 
> <soap:Envelope ...> 
>  <soap:Header> 
>   <wsa:To> http://...wsrm/anonymous?id=...1 </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. 
> 
> HTH.  BTW, I will try to join the WSA call tomorrow but I have a 
> conflict from 4-5 eastern, so if there are any questions on this 
> example I should be able to answer them at 5. 
> 
> thanks 
> -Doug