- From: Monica Martin <monica.martin@sun.com>
- Date: Fri, 08 Aug 2003 13:01:25 -0600
- 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