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:29:28 UTC