Re: Abstract Bindable Choreography

David,  there are some "rules" that I guess by reading your model.  Can you 
confirm my following understanding of these rules ?

"Process" is where each party (who wants to play a role of the 
choreography) plug-in their private implementation.  In other words, 
"process" is the hook between "choreography" and "orchestration".

I categorize the states into various types
a) Border state - states sitting at the dotted line
     - Outbound border state - source state of an "interaction"
     - Inbound border state - target state of an "interaction"
b) Inner state - States within the swimlane

All states are "public" in the sense that it is known by at least 2 roles 
(assume multi-role is allowed) at any given point in time (logical 
time).  The state can be derivable from the message exchanges between these 
two roles.

Every arc has exactly one source state and exactly one target state.

There is exactly one incoming arc into the "outbound border state".  The 
source of this incoming arc MUST be an "inner state" of the same role.

There is exactly one outgoing arc from the "inbound border state".  The 
target of this incoming arc MUST be a "process" of the same role.

An inner state can have (0..n) incoming arcs and (0..1) outgoing arcs.  It 
is called a "start state" if it has 0 incoming arc.  It is called an "end 
state" if it has 0 outgoing arc.

Direct connection between inner state is disallowed.  In other words, if an 
inner state has 1 outgoing arc, the arc must connect to an "outbound border 
state".  Similarly, if an inner state has an incoming arc, it must come 
from a "process".

A process has (1..n) incoming arcs and (1..n) outgoing arcs.  Each incoming 
arc must be coming from an "inbound border state".  Each outgoing arc must 
go to an inner state.  At most one of the outgoing arc can connect to an 
"end state".

It is not mentioned in your diagram and xml, but I consider the "process" 
should have a timeout concept so that it will be automatically triggered 
after certain time.  For example, in the buyer side process "check accept 
order", how can the seller conclude whether the buyer-side state "accept 
order checked OK" or state "accept order checked error" ?

Best regards,
Ricky

At 11:08 AM 4/3/2003 -0800, Burdett, David wrote:
>There has been some discussion around the idea of an abstract bindable
>choreography so I thought I would provide an example in the form of a
>diagram (PDF) which shows the flow associated with the placement of an order
>and an XML representation of the same in a declarative style. I strongly
>suggest you look at the diagram first.
>
>Comments welcome ;-)
>
>David
>  <<PlaceOrderChoreography.pdf>>
>  <<PlaceOrderChoreography.xml>>
>
>Director, Product Management, Web Services
>Commerce One
>4440 Rosewood Drive, Pleasanton, CA 94588, USA
>Tel/VMail: +1 (925) 520 4422; Cell: +1 (925) 216 7704
>mailto:david.burdett@commerceone.com; Web: http://www.commerceone.com
>
>

Received on Friday, 4 April 2003 15:44:42 UTC