W3C home > Mailing lists > Public > public-ws-chor@w3.org > April 2003

Re: Abstract Bindable Choreography

From: Monica J. Martin <monica.martin@sun.com>
Date: Fri, 11 Apr 2003 21:35:01 -0600
Message-ID: <3E978965.8070002@sun.com>
To: "Patil, Sanjaykumar" <sanjay.patil@iona.com>
CC: "Burdett, David" <david.burdett@commerceone.com>, Ricky Ho <riho@cisco.com>, public-ws-chor@w3.org

Let's put this one in the parking lot as I am not certain that a timeout 
is indeed a state, in and of itself.


Patil, Sanjaykumar wrote:

> Understood. There are acks at various levels such as messaging and 
> process level. Choreography perhaps should limits itself to handling 
> timeouts of process level acks only. Makes sense.
> I was however commenting on the other the discussion topic, that is, 
> whether Timeout is a state or a transition. Personally, I did not see 
> it clearly to be one of these and my inclination is to say that it's 
> both. This is perhaps a subtle modeling issue and we can move on 
> without getting a clear answer today. However, if we run into more 
> such cases where the state and transition are married to each other, 
> we may consider supporting it as a language feature and solve it once. 
> That's all.
> 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:* Burdett, David [mailto:david.burdett@commerceone.com]
>     *Sent:* Thursday, April 10, 2003 9:56 AM
>     *To:* Patil, Sanjaykumar; Monica J. Martin; Burdett, David
>     *Cc:* Ricky Ho; public-ws-chor@w3.org
>     *Subject:* 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]
>>                 *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
Received on Friday, 11 April 2003 23:29:01 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:00:58 UTC