Re: An Example Use of RM's MakeConnection

On Oct 10, 2006, at 1:08 PM, Doug Davis wrote:
>
>   So, if people are passing around EPRs I get really worried at the  
> suggestion that something else needs to be passed around as well in  
> order to correctly talk to that EPR.  The thought that people will  
> need to revamp all of their code that deals with EPRs to also pass  
> along additional information is something that should not be taken  
> lightly.

In a long running exchange there can be a lot more context to keep  
track of than just the address of the endpoint you are talking to.  
E.g. if you are using WS-SecureConversaiton you need to track the  
security context you go to lots of trouble to establish. There can  
also be transaction contexts, message sequence numbers and assorted  
other state information. Its also possible that two endpoints can  
have multiple simultaneous exchanges where each of the above things  
is different. I don't think its really practical to only use EPRs in  
the way you suggest and I don't think we should try to cram all that  
state information into the EPR either.

Marc.

>
>
> Alastair Green <alastair.green@choreology.com>
> 10/09/2006 08:40 PM
>
> To
> Christopher B Ferris/Waltham/IBM@IBMUS
> cc
> Marc Hadley <Marc.Hadley@Sun.COM>, 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
>
>
>
>
>
> I think we need to take a step back.
>
> The example I gave (shorn of XML) is in my view exhaustive. If you  
> can support this use case, then you're done -- for all applications  
> (including RM) that need to create a bilaterally-initiated  
> conversation out of a monologue.
>
> Here it is again:
>
> Given a connection identified as X, between endpoint A (that is non- 
> addressable) and endpoint B (that is addressable), I posited the  
> following canonical use case in a recent posting to WS-RX:
>
> A req: message 1, connection X, reply to anon if available.
> B resp: message 2
> A req: message 3, connection X, reply to anon if available
> B resp: no envelope, 202, i.e. message not available
> A req: MakeConnection, X
> B resp: message 4, MessagePending
> A req: MakeConnection, X
> B resp: message 5
>
> Net effect, for connection/conversation identified as X:
>
> A to B: message 1
> B to A: message 2
> A to B: message 3
> B to A: message 4
> B to A: message 5
>
> >From this you can draw out four semantic elements for which  
> someone must define types and syntax:
>
> 1. An identifier for the conversation (X is an instance of this type)
> 2. An indication that a response on the back channel is legitimate  
> (but optional), if the recipient has a message that belongs to the  
> conversation X
> 3. A no-op message, that invites an (optional) message on the back  
> channel that belongs to the conversation X
> 4. An indication that it is worth sending no-op message 3 again,  
> because the number of responses to a message bearing indication 2,  
> or a message of type 3, is > 1.
>
> These are elements of a protocol that is a) nothing inherently to  
> do with WS-RM (one can imagine other uses) and b) nothing  
> inherently to do with WS-Addressing as it currently stands (you can  
> do it all without WS-A as it is today, hence the impulse to waive  
> WS-A 3.4.)
>
> Examples of things like X are: conversation identifiers, and sub- 
> conversation identifiers, which map to a conversation identifier  
> (UUID and sequence id, in RM's case).
>
> Concretely, for a protocol called TalkToMe, ns prefix T:
>
> 1) A header element <T:Identifier/> whose content is any  
> application-meaningful element (e.g. a UUID, or a sequence  
> identifier), and whose presence imports: "know this identifier, and  
> respond to it on the back channel of this or any subsequent message  
> containing the same identifier"
>
> 2) A body element <T:Pull/>, which must have present and associated  
> a header <T:Identifier>, whose back-channel response may be any  
> message relating to the value of <T:Identifier>.
>
> 3) A header element <T:MessagePending/>, which should only be  
> present in a message on the back-channel which relates to a prior  
> message carrying the header element <T:Identifier/>, which imports:  
> "I have another message relating to this conversation to send you".
>
> If WS-Addressing defined this protocol, then we could all use it,  
> and all users would stop pestering WS-Addressing.
>
> In other words, the "novel, unorthodox, interesting" MEP would find  
> a natural home, and become "customary, acknowledged, orthodox,  
> usual -- and generic".
>
> Each application would then be responsible for defining its valid  
> types for the child element (content) of <T:Identifier/>.
>
> This approach fully exploits the self-correlating nature of the  
> back-channel. I can't see why we need to explicitly state a  
> relationship that is unambiguous by its very fact. The identifier  
> needed does not relate to an individual message, but to a  
> conversation.
>
> Alastair
>
>
>
> Christopher B Ferris wrote:
>
> 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.
> >
> >

---
Marc Hadley <marc.hadley at sun.com>
Business Alliances, CTO Office, Sun Microsystems.