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
>