RE: Correlation Requirements

Assaf, David,

I think this thread has gone in the right direction, but I want
to resolve a concern about how an action/response is determined.
The choreography should define the possible alternative actions
to be taken by a participant.  The choreography should not define
how the choice is made.  So when a PO is received, the recipient
may respond with an acceptance, a rejection or a revision/amendment.
The failure to receive a message is just another event that evokes
a response, and there are likely to be different alternatives
from those if a message were received.  Similarly, receipt of 
a message of an unexpected type may have defined alternative
responses.  The "no message" and "wrong message" events may be
different depending on the state of exchange, but in many cases
it may be the same.  These exceptions could result in termination
of the exchange, or they might result in actions intended to
recover and continue.  The choreography doesn't decide, but only
defines the options.  Therefore the choreography does not need
access to the decision criteria, only a way of describing the
possible events (message received or timed out) and the 
alternative actions (types of message sent or termination).  The
participant must be able to interpret the choreography specification
in terms of the messages it receives and the messages it sends.

In other words, the choreography says

for a seller: if you are in an initial state and you receive a PO, then you 
may respond with an ack, a reject, or an amendment; if you are in an initial

state and you receive a PO cancellation, you can respond with an ack or a 
rejection; if you are in an initial state and you receive any other type
of message, then you can only return a terminiation.

for a buyer: if you sent a PO and you receive an ack, then you send a 
confirmation; if you sent a PO and you receive a reject, you may send an
another 
PO; if you sent a PO and you receive a termination, you may sent the PO
again 
and respond to a termination up to 3 times before quitting.

And so on. 

Note that the choreography does not define how to decide and does not
know how to determine what type of message was sent or received.  It only
prescribes what the participant is allowed to do based on the knowledge
of the participant.

Fred

> -----Original Message-----
> From: Assaf Arkin [mailto:arkin@intalio.com]
> Sent: Thursday, August 21, 2003 10:31 PM
> To: Burdett, David
> Cc: Keith Swenson; 'Monica Martin'; 'Martin Chapman'; 'Yves Lafon';
> jdart@tibco.com; 'Ugo Corda'; 'Cummins Fred A'; public-ws-chor@w3.org
> Subject: Re: Correlation Requirements
> 
> 
> David, I perfectly agree with all these three options and the 
> fact that 
> there's no right one.
> 
> In all three cases, if I read them correctly, it seems that 
> you would be 
> doing different activities depending on which path you 
> follow. It may be 
> a different choreography (hence different activity) or different 
> activities in the same larger (composed or not) choreography. So it's 
> easy to associate a different operation with each activity, and build 
> these operations using a common set of types.
> 
> For example, you can define a generic type for a PO, a 
> specific type for 
> a local PO and a specific type for an export PO (extended to include 
> export-related information). You then use the appropriate type when 
> defining the operation to perform as part of a particular 
> flow. So you 
> get a lot of commonality which helps the implementation - you 
> can have 
> one way to handle billing or item allocation for both cases - but you 
> also have specific knowledge of which message type is used where.
> 
> Would this approach be consistent with what you had in mind?
> 
> arkin
> 
> Burdett, David wrote:
> 
> >Assaf said ...
> >
> >  
> >
> >>>>Are you saying that a choreography would select one of 
> two alternative
> >>>>        
> >>>>
> >flows based on this state, or that there are two different 
> choreographies,
> >depending on which type of order is being sent?<<<
> >
> >It all depends, for example I can think of three ways of solving this
> >problem all of which could be appropriate depending on the 
> circumstances.
> >
> >1. IT's A BUSINESS PROCESS
> >You could imagine a business process (i.e. it's under the 
> control of a
> >single entity) that decides independently which of two 
> choreographies to
> >use. In this case, the decision would probably be part of a 
> BPEL or some
> >other process-oriented language and not in the choreography
> >
> >2. IT's A COMPOSED CHOREOGRAPHY
> >In this case you have two separate choreographies one for
> >"export-restricted" and one for "non-export restricted" orders. These
> >separately defined choreographies are then referenced by a 
> third higher
> >level choreography that uses "choreography composition" to 
> combine them.
> >
> >3. IT's ONE BIG CHOREOGRAPHY
> >This is similar to the second example above, except that all the
> >interactions in the choreoraphy are in one single 
> choreography definition so
> >there is no referencing of separately defined choreographies.
> >
> >Which style you use is a choreography design decision that 
> depends on such
> >things as:
> >a) Whether all the parties involved need to know about 
> combined choreography
> >or can treat them as separate. If they don't then you can do the BPEL
> >approach, if they do, then you need to do have one big 
> choreography of
> >compose two choreographies.
> >b) The degree of commonality between the choreographies, if they are
> >similar, then you might want to do one big choreography to avoid the
> >duplication.
> >c) Whether or not there are some pre-existing choreographies 
> that you can
> >just reuse. If they already exist then a composed 
> choreography could be the
> >way to go.
> >
> >As in all design decisions, there is rarely one right way of 
> doing things
> >that applies to all situations ...
> >
> >Hope this helps
> >
> >David
> >-----Original Message-----
> >From: Assaf Arkin [mailto:arkin@intalio.com]
> >Sent: Wednesday, August 20, 2003 4:49 PM
> >To: Burdett, David
> >Cc: Keith Swenson; 'Monica Martin'; 'Martin Chapman'; 'Yves Lafon';
> >jdart@tibco.com; 'Ugo Corda'; 'Cummins Fred A'; public-ws-chor@w3.org
> >Subject: Re: Correlation Requirements
> >
> >
> >Burdett, David wrote:
> >
> >  
> >
> >>Assaf
> >>
> >>You said ...
> >>
> >> 
> >>
> >>    
> >>
> >>>>>You have very specific structures like RN vs OAG and you 
> want to avoid
> >>>>>       
> >>>>>
> >>>>>          
> >>>>>
> >>dependency on those so as to allow multiple over-the-wire 
> formats (as you
> >>discuss below). But there's also the content model or 
> information structure
> >>that is important to convey. If you send me some message that is
> >>semantically a PO, that's not very helpful if I can't find 
> some line items,
> >>billing address, etc in there.<<<
> >>
> >>I totally agree. But I would separate this problem into three parts:
> >>1. Define the relevant states - by specifying in the 
> choreography, *what*
> >>"states" are relevant. For example the fact that an order 
> contained goods
> >>that had export restrictions, might have a substantive 
> effect on the flow
> >>    
> >>
> >of
> >  
> >
> >>the choreography. In this case, the state 
> "ExportRestrictedOrder", or
> >>something like it, would need to be defined.
> >>
> >>    
> >>
> >Are you saying that a choreography would select one of two 
> alternative 
> >flows based on this state, or that there are two different 
> >choreographies, depending on which type of order is being sent?
> >
> >arkin
> >
> >  
> >
> >>2. Determine document formats compatible with the choreography. For
> >>    
> >>
> >example,
> >  
> >
> >>there will be rules that uses information about an order 
> and the parties
> >>involved to determine whether or not it is export 
> restricted. This means
> >>that, before you can use a particular choreography, you 
> need to make sure
> >>that the order document format (or information derivable 
> from eleswhere
> >>using data in the document) contains the required 
> information. Once you
> >>    
> >>
> >have
> >  
> >
> >>done that analysis, you can specify which choreographies 
> can be used which
> >>document formats.
> >>3. Define the choreography binding. Finally, once you have 
> identified
> >>compatible combinations of document format and 
> choreography, you can build
> >>an implementation and specify exactly which choreography, 
> document formats,
> >>message formats, security, RM protocol, etc. as well as the 
> services you
> >>    
> >>
> >are
> >  
> >
> >>going to use. You can also bind the state, e.g. 
> "ExportRestrictedOrder" to
> >>an executable set of conditions that allows the value of 
> the state to be
> >>determined for any order instance. At this point, you are 
> specifying the
> >>"how".
> >>
> >>David
> >> 
> >>
> >>    
> >>
> >
> >  
> >
> 
> 
>

Received on Saturday, 23 August 2003 22:26:45 UTC