Re: An Example Use of RM's MakeConnection

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