Re: Exchange type issue

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:32:22 UTC