Re: An Example Use of RM's MakeConnection

On Oct 10, 2006, at 7:41 PM, Doug Davis wrote:
>
> We're not talking about state information - we're talking about an  
> endpoint's identity.

You seemed to be claiming that only an EPR is required to communicate  
with an endpoint, I was pointing out that there are other things  
associated with a long running conversation that are equally  
important unless you always want to restart the communication from  
scratch.

> http://...wsrm/anon?id=123 does not convey state information any  
> more than http://www.cnn.com does. Both simply provide a way for us  
> to know we're not talking to http://abcnews.com.  See my previous  
> note [1]
>
I agree, but both could have multiple "bags" of state associated with  
them if you are already in communication with the endpoints. If you  
want to hand off part of a conversation to another "subsystem" then  
you need to hand over the state along with the EPR.

Is that any clearer ?

Marc.

>
>
> [1] http://lists.w3.org/Archives/Public/public-ws-addressing/ 
> 2006Oct/0067.html
>
>
>
>
> Marc Hadley <Marc.Hadley@Sun.COM>
> Sent by: Marc.Hadley@Sun.COM
> 10/10/2006 07:17 PM
>
> To
> Doug Davis/Raleigh/IBM@IBMUS
> cc
> public-ws-addressing@w3.org
> Subject
> 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.
>
>
>

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