- From: David Hull <dmh@tibco.com>
- Date: Fri, 13 Oct 2006 11:06:00 -0400
- To: Marc Hadley <Marc.Hadley@Sun.COM>, "public-ws-addressing@w3.org" <public-ws-addressing@w3.org>
- Message-id: <452FAB58.7020902@tibco.com>
IIUC the interaction you're proposing is:
1. Client sends server GetQuote with [reply endpoint] anon.
2. Server sends back a CreateSequence, to anonymous, correlated as a
reply, and also correlated as InitReliable
3. Client sends CreateSequenceResponse to server (one-way)
4. Client sends MakeConnection to server
5. 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?
For reference, Dug's original proposal, IIUC, was
1. Client sends server GetQuote with [reply endpoint] an instance of
the RM anon template
2. Server sends back CreateSequence, to the RM anon address, not
correlated in any particular way.
3. Client sends CreateSequenceResponse to server (one-way)
4. Client sends MakeConnection to server
5. 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.
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.
>
>
Received on Friday, 13 October 2006 15:06:35 UTC