RE: Exchange type issue

Hi,

I agree again with Martin, specifically, there is either a one-way
message request, or a request-response.

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:47 AM
To: 'Gary Brown'
Cc: 'Steve Ross-Talbot'; 'Charlton Barreto'; 'WS-Choreography List'
Subject: RE: Exchange type issue


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:57:47 UTC