- From: Martin Chapman <martin.chapman@oracle.com>
- Date: Tue, 5 Dec 2006 15:12:28 -0000
- To: "'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>
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:14:16 UTC