RE: An Example Use of RM's MakeConnection

Tony,
  The biggest reason for MakeConnection being a one-way is so that we 
don't run into conflicts between the wsa:ReplyTo of the MakeConnection and 
the wsa:ReplyTo of the original request message.  Clearly in the case of a 
simple request/response the messages being pulled back should have the 
ref-p's from the original request's wsa:ReplyTo - otherwise it may not be 
able to be delivered properly.  However, if MakeConnection were a two-way 
operation then because we have to follow the WSA processing rules for 
formulating responses, we'd either run into a conflict between two 
wsa:ReplyTo EPRs (one from the original request and one from 
MakeConnection), or we'd have to require them to always be the same - 
which may not always be possible - the component sending the 
MakeConnection may be able to know its identity (ie. its wsa:Address 
value) but not necessarily know the specific ref-p's specified that any 
one particular set of messages.

  There were other reasons (like a gateway using MakeConnection to get 
messages from lots of different applications) but the above reason was the 
main one.  Once we realized that what we really wanted to do was just 
create a connection and identify the initiator endpoint, thus allowing the 
recipient to decide what messages to send to that endpoint (whether they 
be responses or requests - just like in the async world) it made a lot 
more sense that MakeConnection should be a one-way that just passed in 
correlating info.  What the server/receiver of it does with that 
connection is then up to it - and it doesn't need to worry about the data 
in the message - it can just put whatever it would normally put in there 
just like in the async case - just as long as its destined for the correct 
endpoint.

thanks
-Doug


public-ws-addressing-request@w3.org wrote on 10/09/2006 12:40:58 AM:

> I wonder what the rationale was for deciding that MakeConnection was
> one-way? It seems to me that it should be Request-Response, so that 
> it can either receive the pending response, or a message saying 
> "message still pending" (something I saw on another e-mail).
> 
> I note with interest that you say that the To in the HTTP response 
> to MakeConnection is the replyTo from the original request - that 
> seems a little odd (to my uneducated eyes). I would have expected it
> to be the replayTo from the MakeConnection (yes, I know that MC 
> doesn't have a replyTo, but see above ponderings)
> 
> If nothing else, I hope these discussions are providing material for
> the Primer/FAQ for RM :-)
> 
> Tony Rogers
> tony.rogers@ca.com
> 
> 
> From: public-ws-addressing-request@w3.org [mailto:public-ws-
> addressing-request@w3.org] On Behalf Of Doug Davis
> Sent: Monday, 9 October 2006 11:08
> To: public-ws-addressing@w3.org
> Subject: An Example Use of RM's MakeConnection

> 
> 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