W3C home > Mailing lists > Public > public-ws-chor@w3.org > August 2003

Re: Correlation Requirements

From: Monica Martin <monica.martin@sun.com>
Date: Fri, 08 Aug 2003 13:01:25 -0600
Message-ID: <3F33F385.5030001@sun.com>
To: "Cummins, Fred A" <fred.cummins@eds.com>
CC: "Burdett, David" <david.burdett@commerceone.com>, "'Martin Chapman'" <martin.chapman@oracle.com>, "'Yves Lafon'" <ylafon@w3.org>, jdart@tibco.com, "'Ugo Corda'" <UCorda@SeeBeyond.com>, public-ws-chor@w3.org

Cummins, Fred A wrote:

> David,
>  
> I think you really have only one requirement for which #1 is 
> sufficient.  I would
> be more abstract and say " the recipient must be able to determine the
> choreography instance to which the message belongs."  The other
> "requirements" are describing how that may be implemented.
>  
> I think it is important to note that requirement #1 does not establish 
> that the
> choreography identifier must be referencable by the choreography 
> specification.
> If a choreography describes a sequence of exchanges between two roles, 
> then
> the messages participating in that exchange implicitly belong to the same
> choreography instance.  If a binary choreography (two roles) is part 
> of a composite
> choreography, then there is a need to link the exchanges occuring in
> one binary choreography with exchanges in others.  This is not addressed
> by a choreography instance identifier since at the time the specification
> is defined, there are no instances.  Rather the issue is when does a state
> in one binary exchange affect an action or alternative in another binary
> exchange.  For example, in a purchase exchange, the acceptance of the
> order may be conditioned on receipt of a credit authorization from a
> bank exchange.  This is not a linkage of messages, but a linkage
> of states and state changes.
>  

mm1: I agree on both counts, and this reinforces my point that we define 
requirements, not solutions (and the 'how').

> Fred
>
>     -----Original Message-----
>     *From:* Burdett, David [mailto:david.burdett@commerceone.com]
>     *Sent:* Thursday, August 07, 2003 6:15 PM
>     *To:* 'Monica Martin'; Burdett, David
>     *Cc:* 'Martin Chapman'; 'Yves Lafon'; jdart@tibco.com; 'Ugo
>     Corda'; 'Cummins Fred A'; public-ws-chor@w3.org
>     *Subject:* RE: Correlation Requirements
>
>     Monica
>
>     The reason I included requirements 2 and 3 is that they reflect
>     two use cases ...
>
>     If we assume that there has to be some data in the message that
>     can be used for correlation when the message is taking part in a
>     choreography then requirement 2 arises becaus it is possible that
>     there is no data in the payload (or anywhere else) that can be
>     used for correlation purposes.
>
>     Requirement 3 arises because there maybe data that can be used in
>     the payload and therefore you don't want to have to be forced to
>     use an identifier in the header.
>
>     However, I can also see your point that the existing requirement
>     definitions could be a bit too presrcriptive, so how about these
>     as alternatives, I've added a fourth requirement which hopefully
>     makes it clearer. The complete set is as follows ...
>
>     Requirement 1 (not changed)
>     If a message is being sent between roles as part of the
>     "performance" of a choreography, then that message MUST identify
>     the "choreography instance" to which it belongs.
>
>     Requirement 2 (changed)
>     A choreography instance MUST be identified by specifying a
>     separate identifier associated with the payloads in the message
>     where there is no combination of data in the "payload(s)" that can
>     be used to uniquely identify the choreography instance that is
>     being performed.
>
>     Requirement 3 (changed)
>     A choreography instance MAY be identified by referencing a
>     combination of one or more items of data in the "payload(s)" of
>     the message where that combination of data can be used to uniquely
>     identify the choreography instance that is being performed.
>
>     Requirement 4 (new)
>     A choreography  instance MAY be identified by specifying a
>     separate identifier associated with payload(s) in the message even
>     if there is a combination of data in the "payload(s)" that can be
>     used to uniquely identify the choreography instance that is being
>     performed.
>
>     David
>     -----Original Message-----
>     From: Monica Martin [mailto:monica.martin@sun.com]
>     Sent: Thursday, August 07, 2003 3:03 PM
>     To: Burdett, David
>     Cc: 'Martin Chapman'; 'Yves Lafon'; jdart@tibco.com; 'Ugo Corda';
>     'Cummins Fred A'; public-ws-chor@w3.org
>     Subject: Re: Correlation Requirements
>
>
>     Burdett, David wrote:
>
>     > A very good point Martin - I was presuming "a" solution which is
>     > perhaps premature.
>     >
>     > So let's do this the "right" way and think about it in terms of
>     > requirements so here's my $0.02c on what they might be ...
>     >
>     > Requirement 1
>     > If a message is being sent between roles as part of the
>     "performance"
>     > of a choreography, then that message MUST identify the
>     "choreography
>     > instance" to which it belongs
>     >
>     > Requirement 2
>     > A choreography instance MAY be identified by specifying a unique
>     > identifier in "metadata" (e.g. a SOAP header) associated with
>     the message.
>     >
>     > Requirement 3
>     > A choreography instance MAY be identified by referencing a
>     combination
>     > of one or items of data in the "payload(s)" (e.g. the SOAP body
>     and/or
>     > attachments) of the message.
>     >
>     mm1: I would suggest on Reqt 2 and 3 that we specify the
>     requirement not
>     the solution, of which these requirements appear to do both. 
>     Particularly, a choreography instance may be referenced, - do we
>     specify
>     how?
>
>     > To make these complete, we should also define, roles, performance,
>     > choreography instance, metadata and payload, but that can come
>     later!
>     >
>     > Thoughts?
>     >
>     > David
>     >
>
Received on Friday, 8 August 2003 14:58:03 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:01:00 UTC