Re: An Example Use of RM's MakeConnection

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?

If it is, why isn't it formulated according to the rules in section 3 of
the core?

If it isn't, why is it in the SOAP response for a SOAP request with
[reply endpoint] anon?
> Its not the output message from the WSDL because the use of RM is
> inserting additional messages into the exchange.
>
> 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.
>
>