W3C home > Mailing lists > Public > public-ws-chor@w3.org > November 2006

RE: Exchange type issue

From: Charlton Barreto <charlton_b@mac.com>
Date: Fri, 03 Nov 2006 06:52:21 -0800
To: Martin Chapman <martin.chapman@oracle.com>
Cc: "'Gary Brown'" <gary@pi4tech.com>, "'WS-Choreography List'" <public-ws-chor@w3.org>
Message-ID: <CB12FBAB-010E-1000-C1E3-2EBA21CD2627-Webmail-10012@mac.com>

Should it be illegal? While we agreed in issue X that a choreography should only "officially" support the use of in-only, in-out and robust in-only MEPs from WSDL 2.0, there's nothing as far as I can see in the spec that indicates that a choreography could not describe any of the WSDL 2.0 MEPs. This implies that we could support responses that wouldn't be matched to a request. If we have but one response in the choreo, and that is not matched to the initiating request, we in effect described an out-only with that choreo. 

I agree with Gary that 'notify' is a suitable value for that exchange action type, because in this case we are describing a 'notification'/out-only MEP with the choreo. 

On Friday, November 03, 2006, at 02:34PM, "Martin Chapman" <martin.chapman@oracle.com> wrote:
>In 1), why would we ever allow a response that has not had a preceeding request? This should be illegal! The only chellange is being
>able to match a response with a request. We could also allow fancy patterns such as one request and mutiple responses (of same or
>different type) without introducing this "notify" flag.
>>-----Original Message-----
>>From: public-ws-chor-request@w3.org 
>>[mailto:public-ws-chor-request@w3.org] On Behalf Of Gary Brown
>>Sent: Wednesday, November 01, 2006 9:06 AM
>>To: 'WS-Choreography List'
>>Subject: Exchange type issue
>>As discussed on the conf call last night, I will outline the 
>>requirements for this change and the benefits if can offer.
>>1) We need the ability to distinguish whether or not an exchange with 
>>action="respond" is coupled with a preceding exchange with 
>>A simple scenario would be where an interaction, with a request 
>>exchange, is followed by a choice that has two paths, and each 
>>path has 
>>an interaction with a 'respond' exchange for a normal response. 
>>Currently it is not possible to determine whether one of these is 
>>intended to be a response coupled with the request, or whether 
>>both are 
>>'out only' messages, or whether the user has in fact made an error in 
>>the choreography design, and is expecting both to be responses to the 
>>2) The benefits of having a clear and explicit understanding 
>>of whether 
>>a response is actually coupled to a preceding request are:
>>a) Static validation - we can determine when a user has made an error, 
>>by specifying two normal responses.
>>b) Deriving correct service interfaces - service interfaces can be 
>>derived from the choreography description. However at the 
>>moment, even a 
>>simple case where there is a request followed by a separate 
>>including a respond exchange, it may be unclear whether they are a 
>>one-way request followed by an 'out-only', or whether they are a 
>>request-response pair. Making this explicit in the choreography means 
>>that these ambiguities would not arise.
>>In relation to the terminology question, after further thought 
>>I believe 
>>that 'notify' is actually a suitable value for the new exchange action 
>>type. This is because it is exactly that, an action. The term notify 
>>simply means that someone will be informed, it does not imply whether 
>>there is one or more parties being informed. This is determined by the 
>>communication structure on which that notification is being sent - and 
>>at present CDL only supports point to point.
Received on Friday, 3 November 2006 14:53:37 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:01:09 UTC