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