- 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>
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. -Charlton. 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. > >Martin. > >>-----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 >> >> >> >>Hi >> >>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 >>action="request". >> >>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 >>request. >> >>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 >>interaction >>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. >> >>Regards >>Gary >> >> >> >> > > > >
Received on Friday, 3 November 2006 14:53:37 UTC