W3C home > Mailing lists > Public > public-ws-chor@w3.org > October 2006

Re: Clarifying exchange type

From: Gary Brown <gary@pi4tech.com>
Date: Fri, 27 Oct 2006 08:57:49 +0100
Message-ID: <4541BBFD.3050703@pi4tech.com>
To: Martin Chapman <martin.chapman@oracle.com>
CC: 'WS-Choreography List' <public-ws-chor@w3.org>

Hi Martin

Possibly nobody uses notifications in Web Services at the moment, 
although I don't think we want to have restrictions in CDL that then 
prevent notifications being used in the future, in case WS notifications 
does take off.

However, CDL as we know is not bound to just web services, it can also 
be used with other technologies which do use notifications extensively - 
e.g. pub/sub messaging.

Your point about WS-Addressing may be true at the runtime level, but I 
am primarily thinking about static validation.

Regards
Gary


Martin Chapman wrote:
> But nobody uses notifications, so doubt if one will ever be sent!
> Also ws-addressing can be used to correlate a response with a request using
> message-id.
>
>
> Martin.
>
>   
>> -----Original Message-----
>> From: public-ws-chor-request@w3.org 
>> [mailto:public-ws-chor-request@w3.org] On Behalf Of Gary Brown
>> Sent: Tuesday, October 24, 2006 2:18 PM
>> To: 'WS-Choreography List'
>> Subject: Clarifying exchange type
>>
>>
>>
>> Hi
>>
>> Currently the 'exchange' within an 'interaction' can have an action 
>> attribute with the values:
>>
>> "Within the |exchange| element, the attribute |action| specifies the 
>> direction of the information exchanged in the interaction:
>>
>>    *
>>
>>      When the |action| attribute is set to "request", then the
>>      information exchange happens from the 'from' roleType to the 'to'
>>      roleType
>>
>>    *
>>
>>      When the |action| attribute is set to "respond", then the
>>      information exchange happens from the 'to' roleType to the 'from'
>>      roleType"
>>
>>
>> Where a request and response exchange are separated into different 
>> interactions, to enable intervening activities to be described, it 
>> requires the implementation to correlate the response exchange 
>> with the 
>> request exchange to determine they are part of a request-response MEP.
>>
>> Although in most situations, the use of operation names should support 
>> the correlation of the responses with appropriate requests, 
>> there may be 
>> some situations where a response exchange that actually represents a 
>> notification may be incorrectly associated with a preceding request. 
>> This is because the action type for a notification exchange would also 
>> be 'respond'.
>>
>> Therefore, although the chance of a notification exchange having the 
>> same operation name as a preceding request is remote, it is not 
>> forbidden, and therefore for clarity it would be useful to add a third 
>> exchange action type called "notify".
>>
>> This would enable better static validation as it will now be 
>> clear what 
>> each exchange represents. For example, if an exchange is defined as a 
>> 'respond' but no request precedes it, then this can be flagged as an 
>> error. Currently the assumption would be that it is a 
>> notification, and 
>> this would be silently ignored.
>>
>> If the change is acceptable, then the following updates are 
>> required in 
>> section 6.2.3:
>>
>> 1) Modify second bullet point above:
>> From:
>>
>>    *
>>
>>      When the |action| attribute is set to "respond", then the
>>      information exchange happens from the 'to' roleType to the 'from'
>>      roleType"
>>
>> To:
>>
>>    *
>>
>>      When the |action| attribute is set to "respond", then the
>>      information exchange happens from the 'to' roleType to the 'from'
>>      roleType" and the exchange MUST be associated directly or
>>      indirectly with a preceding exchange of action type "request" for
>>      the same operation and channel
>>
>>
>> 2) Additional bullet point on text above:
>>
>>    *
>>
>>      When the |action| attribute is set to "notify", then the
>>      information exchange happens from the 'to' roleType to the 'from'
>>      roleType"
>>
>>
>>
>> 3) Following the para that starts "The OPTIONAL record element....."
>>
>> From:
>> "When the |action| element is set to "response", then the recordings 
>> specified within the |source| and the |target| elements MUST occur at 
>> the 'to' roleType for the send and at the 'from' roleType for 
>> the receive"
>> To:
>> "When the |action| element is set to "respond" or "notify", then the 
>> recordings specified within the |source| and the |target| 
>> elements MUST 
>> occur at the 'to' roleType for the send and at the 'from' roleType for 
>> the receive"
>>
>>
>> Regards
>> Gary
>>
>>
>>
>>
>>
>>     
>
>
>
>
>
>   
Received on Friday, 27 October 2006 07:58:11 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 18 December 2010 01:01:47 GMT