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 09:51:14 UTC