- From: Martin Chapman <martin.chapman@oracle.com>
- Date: Tue, 5 Dec 2006 15:46:43 -0000
- To: "'Gary Brown'" <gary@pi4tech.com>
- Cc: "'Steve Ross-Talbot'" <steve@pi4tech.com>, "'Charlton Barreto'" <charlton_b@mac.com>, "'WS-Choreography List'" <public-ws-chor@w3.org>
My main technical argument is that there is no such thing as a notify: there is either a one-way message request, or a request-response; this is current, and as I see near future, web services technology. Martin >-----Original Message----- >From: public-ws-chor-request@w3.org >[mailto:public-ws-chor-request@w3.org] On Behalf Of Gary Brown >Sent: Tuesday, December 05, 2006 3:29 PM >To: Martin Chapman >Cc: 'Steve Ross-Talbot'; 'Charlton Barreto'; 'WS-Choreography List' >Subject: Re: Exchange type issue > > > >Hi Martin, > >When should WS-CDL be limited by what is well supported in Web Service >technology today? This would imply that when it is well >supported, there >is going to be a time period where web services can execute >it, but CDL >cannot describe it. Why does it have to be that way around? > >Would it not be better to ensure the CDL language is as expressive as >possible, and then enable tools to apply suitable restrictions or >warnings based on the capabilities of the technology they are >deploying >to? As I have mentioned a number of times, CDL is applicable >outside of >the Web Service arena, where notifications are not only supported but >common place. > >Regards >Gary > > >Martin Chapman wrote: >> 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:50:01 UTC