Re: An Example Use of RM's MakeConnection

On Oct 13, 2006, at 11:06 AM, David Hull wrote:

> IIUC the interaction you're proposing is:
> Client sends server GetQuote with [reply endpoint] anon.
> Server sends back a CreateSequence, to anonymous, correlated as a  
> reply, and also correlated as InitReliable
> Client sends CreateSequenceResponse to server (one-way)
> Client sends MakeConnection to server
> Server sends back GetQuoteResponse, to anonymous, correlated as a  
> reply.
> Is this correct, and if so, how would one advertise this in WSDL?   
> Particularly, is it an in-out operation, or some other operation?
>
Looks about right. I guess you'd advertise it in the WSDL as a normal  
in-out with some kind of policy to make it clear that RM is  
(potentially) active. I think the same approach would be taken  
regardless of whether the message flow is the one above or below.

> For reference, Dug's original proposal, IIUC, was
> Client sends server GetQuote with [reply endpoint] an instance of  
> the RM anon template
> Server sends back CreateSequence, to the RM anon address, not  
> correlated in any particular way.

Incidentally, related to the above, if the CreateSequence goes to the  
[reply endpoint] doesn't that make it a reply ? If so we require a  
[relationship] according to the rules in core section 3.2 and the two  
flows will share the characteristic you are concerned about below.

> Client sends CreateSequenceResponse to server (one-way)
> Client sends MakeConnection to server
> Server sends back GetQuoteResponse, to the RM anon address,  
> correlated as a reply.
> It does seem like a good idea to have (2) above correlated as  
> InitReliable.  It doesn't seem like a good idea to correlate it as  
> a reply, particularly if this is only being done to satisfy the  
> rules in core section 3.
>
> It's a bit unexpected that a single request message would be liable  
> to produce two separate messages with completely different content,  
> both correlated as replies, one of interest to the application and  
> one not.  Quite possibly this can be made to square with the specs  
> (though it's worrisome that the first attempt failed), but it seems  
> like swimming upstream, particularly since a simple alternative is  
> available:  A GetQuote message produces (barring error) a single  
> message correlated as a reply, that being a GetQuoteResponse.   
> Other messages also happen, but they are marked differently.
>
> This may not matter much if everything in the system is RM-aware.   
> The RM layer will have to sort through retried replies, for  
> example, which will all be correlated as replies, and it will also  
> have to eat the CreateSequence message in any case.  I'm concerned,  
> though, that any module that knows WSA but not RM would get  
> confused by having both CreateSequence and GetQuoteResponse  
> correlated as replies.
>
Any module that doesn't know RM would be thoroughly confused by the  
CreateSequence message in either case.

Marc.

> Marc Hadley wrote:
>> On Oct 12, 2006, at 11:58 PM, David Hull wrote:
>>
>>> Marc Hadley wrote:
>>>> The message in step 2 is still a response in WS-A and SOAP  
>>>> binding terms.
>>> Actually, the more relevant question is: Is it a reply in WSA terms?
>>>
>> Section 3 of core says:
>>
>> "The basic interaction pattern from which all others are composed  
>> is "one way". In this pattern a source sends a message to a  
>> destination without any further definition of the interaction.  
>> "Request Reply" is a common interaction pattern that consists of  
>> an initial message sent by a source endpoint (the request) and a  
>> subsequent message sent from the destination of the request back  
>> to the source (the reply). A reply in this case can be either an  
>> application message, a fault, or any other message. Note, however,  
>> that reply messages may be sent as part of other message exchanges  
>> as well, and are not restricted to the usual single Request,  
>> single Reply pattern, or to a particular WSDL MEP. The contract  
>> between the interacting parties may specify that multiple or even  
>> a variable number or replies be delivered."
>>
>> Given the above I think the message in step 2 is a reply in WSA  
>> terms falling into the "other message" category.
>>
>>> If it is, why isn't it formulated according to the rules in  
>>> section 3 of the core?
>>>
>> It mostly is but, looking closely, I see that I missed an  
>> additional wsa:RelatesTo with the standard "reply" RelationshipType.
>>
>> Marc.
>>
>>>>
>>>> On Oct 12, 2006, at 1:37 PM, David Hull wrote:
>>>>
>>>>> According to section 5 of the SOAP binding, if [reply endpoint] is
>>>>> anonymous, then "any response MUST be the
>>>>> http://www.w3.org/2003/05/soap/mep/OutboundMessage property of  
>>>>> the same
>>>>> instance of the SOAP request-response MEP".  There is no  
>>>>> definition of
>>>>> "response" in this section, but given that we define "response  
>>>>> endpoint"
>>>>> as [reply endpoint] or [fault endpoint] and lacking any other  
>>>>> plausible
>>>>> interpretation, the intent is clear: a response is a reply or a  
>>>>> fault.
>>>>>
>>>>> A reply MUST be formulated according to the rules in section  
>>>>> 3.  Section
>>>>> 4 of the WSDL spec says that the reply message would have an  
>>>>> [action] of
>>>>> foo:GetQuoteResponse and otherwise follow the WSDL operation  
>>>>> description
>>>>> (assuming this description is WSA-aware).  In other words, the  
>>>>> message
>>>>> in step 5 is the reply.
>>>>>
>>>>> The server below is behaving incorrectly in step 2.  The [reply
>>>>> endpoint] of anonymous requires it to send the message it sends  
>>>>> in step
>>>>> 5 in step 2 instead.
>>>>>
>>>>>
>>>>> Marc Hadley wrote:
>>>>>> 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.
>>
>>
>

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