RE: Abstract Bindable Choreography

I think that two different types of timeout can occur associated with:
1. Delivery of an individual message, and
2. Completion of the processing of a message
 
For the first case, you can ask for a *message* acknowledgement receipt on
any message that is sent. If the acknowledgement is received it does NOT
mean that the message has been processed it only means its been delivered
and it SHOULD be processed. This is what the Reliable Messging specs (note
the "s") all do. I don't think that this type of protocol is within our
scope although we should recognize that they exist, we could even recommend
that they are used.
 
In the second case you get a response that is based on processing the
message. In this case it might be just *process* acknowledgement receipt
which means that the message was successfully processed. For example if you
are doing a subscription to a service then this might be all you need. This
type of acknowledgement receipt is, I think within our scope.
 
These two types of receipts also lead to two different types of timeout:
1. The reliable messaging timeout which is the time you wait for the
*message* acknowledgement receipt before resending the message. This is also
part of the RM spec.
2. The process timeout, which is the time you wait for any message as
defined in the choreography to comeback.
 
Note you could get a message acknowledgement receipt and still get a
proccess timeout.
 
David

-----Original Message-----
From: Patil, Sanjaykumar [mailto:sanjay.patil@iona.com]
Sent: Thursday, April 10, 2003 9:35 AM
To: Monica J. Martin; Burdett, David
Cc: Ricky Ho; public-ws-chor@w3.org
Subject: 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
<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 <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