- From: Christopher B Ferris <chrisfer@us.ibm.com>
- Date: Mon, 9 Oct 2006 16:48:42 -0400
- To: David Hull <dmh@tibco.com>
- Cc: Doug Davis <dug@us.ibm.com>, public-ws-addressing@w3.org, public-ws-addressing-request@w3.org
- Message-ID: <OFCCA41355.F7EBC7B9-ON85257202.00717158-85257202.00725256@us.ibm.com>
+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
Received on Monday, 9 October 2006 21:01:19 UTC