- From: Burdett, David <david.burdett@commerceone.com>
- Date: Fri, 8 Aug 2003 18:55:29 -0700
- To: "'Cummins, Fred A'" <fred.cummins@eds.com>, "Burdett, David" <david.burdett@commerceone.com>, "'Monica Martin'" <monica.martin@sun.com>
- Cc: "'Martin Chapman'" <martin.chapman@oracle.com>, "'Yves Lafon'" <ylafon@w3.org>, jdart@tibco.com, "'Ugo Corda'" <UCorda@SeeBeyond.com>, public-ws-chor@w3.org
- Message-ID: <C1E0143CD365A445A4417083BF6F42CC053D1CFA@c1plenaexm07-b.commerceone.com>
Fred Thanks for the feedback. Comments in line. David -----Original Message----- From: Cummins, Fred A [mailto:fred.cummins@eds.com] Sent: Friday, August 08, 2003 11:49 AM To: Burdett, David; 'Monica Martin' Cc: 'Martin Chapman'; 'Yves Lafon'; jdart@tibco.com; 'Ugo Corda'; Cummins, Fred A; public-ws-chor@w3.org Subject: RE: Correlation Requirements 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. [Burdett, David] Eventually, we are going to need to get round to implementation approaches as, without this level of detail, we won't have a spec that is implementable. I also think the use case that some "payloads" will contain data that can be used for correlation whilst others do not, is something that we will need to factor into any eventual design. So ... is there any benefit in recording these points somewhere under headings such as "implementation ideas" or "implementation issues"? 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. [Burdett, David] True, if you are talking about the message *types*, but not true if you are talking about the message *instances* as: a) you can have the same message instance taking part in the performance of two different choreographies, and b) without some way of identifying which instance of a choreography performance a message belongs to, you will not normally be able to process it correctly. 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. [Burdett, David] Maybe. If the reason the two binary exhanges are being linked is because their performance is part of a business process being *executed* by a single entity (or to use an earlier phrase [1] a "domain of control"), then there is no need to link the choreographies and no choreography instance identifier is required. On the other hand, if the two binary exchanges are between the same roles, and the roles need to know that one binary choreography has to occur before the second binary choreography can occur, then linking them is important. In which case having a choreography instance identifier for the "composite choreography will be required. This is not addressed by a choreography instance identifier since at the time the specification is defined, there are no instances. [Burdett, David] Totally agree, choreography instance identifiers only ever required once the choreography definition is being performed. However our choreography definition *specification* that *we* will write will need to reference choreography instance identifiers if performances of a choreography definition are to be interoperable. 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. [Burdett, David] I would go further and say that since a) these two choreographies are between different roles (i.e. the seller and the buyer for the purchase exchange, and the seller and his bank, for the credit authorization); AND, b) the process is totally under the control of a single "control domain" (i.e. the supplier) then these two choreographies do NOT need to be composed as the buyer (probably) does not need to know anything about the suppliers bank. Instead, the supplier needs to create "business process" that combines the use of the two choreographies definitions. Fred [Burdett, David] [1] See the thread starting with http://lists.w3.org/Archives/Public/public-ws-chor/2003Mar/0053.html <http://lists.w3.org/Archives/Public/public-ws-chor/2003Mar/0053.html> -----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 <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 21:53:23 UTC