RE: Abstract Bindable Choreography

 Ricky

See comments inline

David
Apologies, again for the delay, I've had PC problems. 

-----Original Message-----
From: Ricky Ho
To: Burdett, David; WS Choreography (E-mail)
Sent: 4/4/2003 12:44 PM
Subject: 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".
<DB>Yes, but we must call it "private implementation" ;). Also, a single
"private implementation" defined using BPEL4WS or WSCI could provide support
for multiple processes in multiple choreographies.</DB>

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
<DB>Good definitions.</DB>

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).  
<DB>Yes they are public and multi-role is allowed.</DB>

The state can be derivable from the message exchanges between
these two roles.
<DB>Not completely, when a message is received, for example the order
message, the state of the receiver some time later could be any of "Order
Received" or any of the states that result from the "Check Order" process.
The buyer will only know when he receives the next message.</DB>

Every arc has exactly one source state and exactly one target state.
<DB>Yes</DB>

There is exactly one incoming arc into the "outbound border state".  
<DB>Often, but not always, for example you could have a combination of inner
states that must exist before the outbound state can be realized. For
example, in a three role choreography you might want to wait for two inner
states to occur, e.g. before a seller can provide shipping details for an
order they must a) have received and checked the order, and b) received
details about the pick up from the buyer's shipper.</DB>

The source of this incoming arc MUST be an "inner state" of the same role.
<DB>Yes except that there can be more than one "inner state".</DB>

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.
<DB>Intuitively I think this is good practice, although in theory, there is
no reason why you cannot have more than one process occur upon the arrival
of a message although I can't think of a good example.</DB>

An inner state can have (0..n) incoming arcs and (0..1) outgoing arcs.
<DB>No. An inner state can have (0..n) outgoing arcs. For example a seller
in a multi-role choreography might need to notify the buyer and the shipper
if the goods can't be picked up at the expected time. I didn't include this
type of situation in the example to keep it simple ;)</DB>

It is called a "start state" if it has 0 incoming arc.
<DB>Yes</DB>
It is called an "end state" if it has 0 outgoing arc.
<DB>Yes, although the behavior of other roles can mean that some of the
other states are "conditional end states" in that, depending on the
processing, it may be the "final" state that the role reaches. For example,
the "Accept Order Sent" state will be the end state for the Seller if the
Buyer detects no errors in the Accept Order Message.</DB>

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".
<DB>Often, but not necessarily. For example, to handle a timeout, you could
have the "Order Sent" state going to another process which also had an
"Order timeout" state as an input. </DB>

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".
<DB>Often, but you can also get other states (e.g. timeout states) that do
not come from a border state and go directly to a process. On the other hand
the output of a process should always be one ore more states.
Generally, the only real restriction is that a boolean combination of states
represent a condition that trigger a process or an interaction, where the
states in the condition are states that exist within that role.
</DB>

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" ?
<DB>I think of a timeout as just another inner state that occurs which then
results in messages being sent. Again, for simplicity, I did not include
this in the example.
To handle, your specific query, the Seller would only get information if
there was problem i.e. "Accept Order Checked". In practice, I don't think
this is an issue if reliable messaging is being used as:
1. The Seller will know that the Accept Order was delivered
2. The Seller will know, if there was a problem, that the Accept Order Error
was delivered.
This means that, for the Seller, no news is good news. Although this is an
optimistic strategy, it should work, especially when any initial teething
problems in an implementation have been ironed out.
</DB>


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 Sunday, 6 April 2003 17:57:59 UTC