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>


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


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


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


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


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

Rgds, Ricky

Received on Monday, 7 April 2003 12:14:12 UTC