RE: Abstract Bindable Choreography

Ricky

See comments in line, marked with <DB2></DB2>

David


-----Original Message-----
From: Ricky Ho [mailto:riho@cisco.com]
Sent: Monday, April 07, 2003 10:08 AM
To: Burdett, David
Cc: public-ws-chor@w3.org
Subject: RE: Abstract Bindable Choreography


David, I'm thinking about bi-party scenarios when I read your diagram 
(although I know multi-roles is possible)..  Now I focus in multi-party 
scenario.  See inline...

>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>

<RH>
I'm thinking you can use different color of "border state" to represent 
multi-role scenario.  e.g. The buyer/seller interactions are using a set of 
"green" border states while the seller/shipper interactions use a set of 
"blue" border states.
I also think there can only be "ONE start state" across all roles.  In your 
example, only the buyer has a "start state".
</RH>
<DB2>I'm not sure why you want to use colors although I think they can make
easier to view.
I would generalize "ONE start state" to "ONE set of conditions" where a
condition is a boolean expression of states. For example you could have an
order recovery choreography that had a "pre-condition" of "OrderSent AND
OrderTimeout" where "OrderSent" and "OrderTimeout" are individual states.
</DB2>

>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>
<RH>
When there are multiple "inner states" connected to one "outbound border 
state", what is the triggering condition ?  Anyone state, or All states ?

For There are 2 alternatives that I can think of

1) Allow multiple inbound border state (as long as they are different 
color) connect their outgoing arc to a process.  A guard condition is 
associated with the process and determines the execution pre-conditions.

OR

2) Allow multiple inner states to connect their outgoing arc to an outbound 
border state. A guard condition is associated with the process and 
determines the interaction pre-conditions.
</RH>
<DB2>As illustrated in the previous comment, I think that the condition can
be a boolean expresion that combines states together. For example if you
wanted to send a "ChangeOrder" message then the precondition would be
something like "ChangeOrderCreated AND (OrderSent OR ChangeOrderSent)"
</DB2>

>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>

<RH>
Same as alternative 2 that I suggested above ?
</RH>


>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>

<RH>
I think allowing multiple simultaneous processing is very complex.  Same as 
all issues associated with multi-threading.  We should avoid this until we 
have a good use case to break this.  Agree ?
</RH>
<DB2>Although it is complex, sometimes business processes can be complex.
The real question is do we want to prohibit it. I don't think so.</DB2>

>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>

<RH>
Agreed.  But all outgoing arcs must be in DIFFERENT colors, right ?
</RH>
<DB2>OK but colors only apply to the diagrams and not to the XML right ;) I
also didn't think we were developing a diagramming convention.</DB2>

>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>

<RH>
There are two aspects of timeout we need to handle ..

On the sender side, each "outbound border state" should optionally has an 
outgoing "timeout" arc connecting to a process of the same role.  This 
presence of such "timeout" arc indicates the outbound border state has a 
timeout value so that if there is no message received from the same partner 
(ie: no message received from any inbound border node who has the same 
color of this outbound node), then the process will be started.

On the receiver side, he should indicate an upper bound it takes to transit 
to the next state (and send his message).  This is important for the sender 
to set his corresponding timeout value on the other side.
</RH>
<DB2>This would work, but I don't see how this is really any different from
anything else as you have a set of conditions made up out of a combination
of states that determine whether or not a timeout has occurred and if so,
what, if anything you do. In principle I don't like "special cases" (i.e.
for timeouts) as they tend to introduce unnecessary complexity.
Also, determining a timeout condition is totally within the *control* of the
sender of the message. Although the sender should take into account the
processing time of the receiver of the message you cannot force the sender
to do this as there is no-one in overall control of the complete
choreography.
I also think that the timeout *values* to use (i.e how long you wait) is
implementation dependent and therefore should be in the binding of the
choreography to the implementation.
Perhaps what we need to do is provide guidelines on how to handle timeouts.
Does this make sense.
</DB2>

>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>

<RH>
In my description above, there is NO such thing called "timeout 
states".  It is being modeled as a "timeout arc" from an outbound border
state.
</RH>


>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>

<RH>
In this example, the seller can never conclude "accept order checked OK" 
(even though he can assume that) unless a timeout is attached.  (the 
timeout says, if I don't receive the accept order send error within 2 
hours, then both of us agree "accept order checked OK").
</RH>
<DB2>I think an example of how timeouts could work in a diagram and in XML
will be useful. I will work on it.</DB2>

Rgds, Ricky