- From: Martin Chapman <martin.chapman@oracle.com>
- Date: Thu, 26 Oct 2006 22:18:41 +0100
- To: "'Gary Brown'" <gary@pi4tech.com>, "'WS-Choreography List'" <public-ws-chor@w3.org>
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 Thursday, 26 October 2006 21:19:22 UTC