- From: Charlton Barreto <charlton_b@mac.com>
- Date: Mon, 04 Dec 2006 20:56:45 -0800
- To: Gary Brown <gary@pi4tech.com>
- Cc: "'WS-Choreography List'" <public-ws-chor@w3.org>
In considering this, it is clear that we need the ability to distinguish whether an respond is associated with a particular request. However, there seems to be some difficulty with introducing a new action="notify" to do this. As such, would it be acceptible to everyone to instead use an additional attribute for action="respond"? I don't see that adding an attribute is semantically any different from adding a new action. However, it may be more amenable to those who would prefer not to express "in-out"/"notification" as a distinct action. If this direction is desired we could then have an attribute, notification="true", used/parsed only when action="respond", that would indicate that the response is not associated with a request. On Wednesday, November 01, 2006, at 09:09AM, "Gary Brown" <gary@pi4tech.com> wrote: > >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 Tuesday, 5 December 2006 04:56:57 UTC