RE: Correlation Requirements

Fred
 
I *think* (and hope) I've answered most of the points you make in my last,
most recent email, however you also said ...
 
[FAC] I was thinking about the case where the buyer needs to ensure that he
has credit with the bank before submitting the order, i.e., both buyer and
seller are having dependent conversations with the bank. In order to achieve
this coordination, the choreography needs to express an abstract description
of the interactions between the choreographies, i.e., how their internal
processes are expected to affect the public states.  
 
I think that the scope of a "well designed" choreography should include
roles on a strictly "need-to-know" basis. In the example you cite, I think
you are suggesting the following interactions (please correct me if I am
wrong) ...
 
1. Buyer checks he has sufficient credit with the bank
2. Buyer places order with seller
3. Seller checks buyer's credit with the bank
4. Seller notifies the buyer that the order is accepted/rejected depending
on whether credit check is OK or not.
 
If you put all four steps into single choreography then it would mean, for
example:
1. The seller would know that the buyer had done a credit check with the
bank, and
2. The buyer would know that the seller had checked their credit with the
bank.
 
I don't the buyer/seller "needs-to-know" any of this. To avoid divulging
this information means that you have three separate choreographies:
1. Buyer checks credit with the bank
2. Buyer places order with sell and receives an acceptance/ rejection in
return, and
3. Seller checks credit with the bank.
 
Is the "need-to-know" principle helpful?

David
 

-----Original Message-----
From: Cummins, Fred A [mailto:fred.cummins@eds.com]
Sent: Monday, August 11, 2003 10:52 AM
To: Burdett, David; Burdett, David; 'Monica Martin'
Cc: 'Martin Chapman'; 'Yves Lafon'; jdart@tibco.com; 'Ugo Corda';
public-ws-chor@w3.org
Subject: RE: Correlation Requirements


David,
 
See comments, below.
 
Fred




[FAC]  I think you really have only one requirement for which #1 is
sufficient.  I wouldbe 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"? 
[FAC] I think the choreography reference to correlation data can be strictly
symbolic.  There is no need for the choreography to specify conditions or
decisions, only to constrain decisions (i.e., alternative responses/state
transtions). 
 

[FAC]  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.
[FAC] I don't understand.  A message could be used in two different
choreographies by one participant, but that should be transparent to the
choreography of a conversation between two participants.  If the message is
the basis for correlation between two conversations, then the correlation
(i.e., the shared message/variable) can be specified symbolicly in the
choreography specification.  At run time (when there are instances) the
correlation must be handled by the executable (internal)  processes. 
 

[FAC]    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.
[FAC] Agreed 
 

[FAC]   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.
[FAC] I don't believe we will need to reference instance identifiers since
the choreography is not executed, per se.  The participants must reference
correlation variables that they use to determine the conversation to which a
message belongs. 
 

[FAC]   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.
[FAC] I was thinking about the case where the buyer needs to ensure that he
has credit with the bank before submitting the order, i.e., both buyer and
seller are having dependent conversations with the bank. In order to achieve
this coordination, the choreography needs to express an abstract description
of the interactions between the choreographies, i.e., how their internal
processes are expected to affect the public states.  
 
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 
>