- From: Abbie Barbir <abbieb@nortel.com>
- Date: Tue, 5 Dec 2006 10:22:28 -0500
- To: "Martin Chapman" <martin.chapman@oracle.com>, "Steve Ross-Talbot" <steve@pi4tech.com>, "Gary Brown" <gary@pi4tech.com>
- Cc: "Charlton Barreto" <charlton_b@mac.com>, "WS-Choreography List" <public-ws-chor@w3.org>
Hi, Well I do agree with Martin (for a change) Abbie -----Original Message----- From: public-ws-chor-request@w3.org [mailto:public-ws-chor-request@w3.org] On Behalf Of Martin Chapman Sent: Tuesday, December 05, 2006 10:12 AM To: 'Steve Ross-Talbot'; 'Gary Brown' Cc: 'Charlton Barreto'; 'WS-Choreography List' Subject: RE: Exchange type issue I'm very much opposed to this, as notify is just a bastardization of a one-way request. It is also not well thouht out or supported in current Web Service technology, so why should this version of WS-CDL account for it? Martin. >-----Original Message----- >From: public-ws-chor-request@w3.org >[mailto:public-ws-chor-request@w3.org] On Behalf Of Steve Ross-Talbot >Sent: Tuesday, December 05, 2006 9:49 AM >To: Gary Brown >Cc: Charlton Barreto; 'WS-Choreography List' >Subject: Re: Exchange type issue > > > >I must admit I am still mystified as to the objection. As a description >language being clear about the intent seems a good thing and so adding >"notify" or "notification" to the description in an exchange adds >clarity. How one chooses to implement said "notification" or "notify" >is entirely up to the implementor(s) of the end point(s). It turns out >many protocols have the concept of a notification as distinct from a >respond and benefit from the distinction. Given that it does nothing to >the semantics of WS-CDL but does enable a response to be distinguished >in some way is it not a good thing as opposed to a bad thing? > >I guess we shall talk more on the call tonight/today. > >Cheers > >Steve T > >On 5 Dec 2006, at 09:32, Gary Brown wrote: > >> >> Hi >> >> Personally I don't see this as being any different to having an >> action called 'notify'. The term still being used is related to >> notification - which is what I thought the objection was about. >> >> Although the suggested approach could be taken, my issue is that it >> is adding a new flag that is only relevant when action="respond", and >> represents a state that is distinct from both a normal >> action="request" and action="respond" - therefore I see it as being a >> redundant additional flag, where a new 'action' state could easily be >> used instead. >> >> However, if this proposal does overcome previous objections, then I >> will support it. >> >> Regards >> Gary >> >> >> Charlton Barreto wrote: >>> 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 15:23:55 UTC