RE: Abstract Bindable Choreography

 
Perhaps it is both. That is, a Timed-out state can only result if a timeout transition occurs. Similarly a timeout transition can only lead to a Timed-out state.
 
Now a Timed-out state may further lead to a Success or Failure outcome state based on the the logic for handling the particular situation. 
 
As shown in your example, a timeout in receiving an ack for a response may be less critical and can be perceived as a success state (with warning being logged). Whereas a timeout in receiving an ack for a request is a critical failure as the state change is predicated on the ack in this case.
 

I am not sure if there are other cases where a transition and the resultant state are tied to each other. In case there are, we may consider supporting the pattern as a language feature.

Sanjay Patil 
Distinguished Engineer 
sanjay.patil@iona.com 
------------------------------------------------------- 
IONA Technologies 
2350 Mission College Blvd. Suite 650 
Santa Clara, CA 95054 
Tel: (408) 350 9619 
Fax: (408) 350 9501 
------------------------------------------------------- 
Making Software Work Together TM 

-----Original Message-----
From: Monica J. Martin [mailto:monica.martin@sun.com]
Sent: Thursday, April 10, 2003 9:01 AM
To: Burdett, David
Cc: 'Ricky Ho'; public-ws-chor@w3.org
Subject: Re: Abstract Bindable Choreography


I would say that the transition would be a timeout, but the state would be at a minimum Failure or Success (if the timeout is not deemed substantive and in actuality a conclusion is reached).  For example, we have seen that a requestor is asked to send a receipt acknowledgement to the responder for a response.  The requestor does not send the receipt acknowledgement, but from a business perspective does not negate the transaction but a warning is logged.  Effectively, although in a different manner, the interchange concludes in Success. 

I do not think the State is a timeout but the timeout results in a state. 
Thanks. 
  


"Burdett, David" wrote: 


 MonicaI think we are basically agreeing. But I tend to think of a timeout as a transition that results in the a state that indicates a timeout has occurred. If you think of timeouts in this way, then the resultant timeout state can be used in exactly the same way any other state that occurs, for example, because a message has arrived. Here's an example:                                 Buyer           Seller  Event/Transition               State           State1. Message:Order ------------> OrderSent       OrderReceived... nothing happens, no Order Response is sent so the Buyer never reaches the "OrderResponseReceived" state, so ...2. Timeout:NoOrderResponse    OrderTimeout3. If (OrderTimeout AND NOT OrderResponseReceived) then 
   Message:OrderStatusRequest ------->4. etc ...Does this make any sense?DavidPS. I held off responding to your comments on timeouts since I thought we might talk about this in our conference call but we never got around to it. 

-----Original Message----- 
From: Monica J. Martin [ mailto:monica.martin@sun.com] 
Sent: Tuesday, April 08, 2003 10:25 AM 
To: Burdett, David 
Cc: 'Ricky Ho'; public-ws-chor@w3.org 
Subject: Re: Abstract Bindable Choreography 
 
I would have to agree with Ricky that the timeout is a transition not the state itself.  In addition, many concurrent business processes and their inter-relationships are messy, but they do exist (particularly in larger enterprises or hubs - reference my simple use case that acknowledges interactivity of business processes, exceptions, etc. that affect processing and outcomes).  We may also need to look at this heirarchically where you and have pre- and post-conditions that are inputs to other processes. 

Yes, messy. 


Monica J. Martin 
Sun Microsystems 


"Burdett, David" wrote: 


  

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