- From: Burdett, David <david.burdett@commerceone.com>
- Date: Sun, 13 Apr 2003 16:17:07 -0700
- To: "'Monica J. Martin'" <monica.martin@sun.com>, "Burdett, David" <david.burdett@commerceone.com>
- Cc: "'Patil, Sanjaykumar'" <sanjay.patil@iona.com>, Assaf Arkin <arkin@intalio.com>, Ricky Ho <riho@cisco.com>, public-ws-chor@w3.org
- Message-ID: <C1E0143CD365A445A4417083BF6F42CC053D1994@C1plenaexm07.commerceone.com>
>>> the timeout is actually an event that triggers the transition from one state to another such as send response to failure.<<< I agree. David -----Original Message----- From: Monica J. Martin [mailto:monica.martin@sun.com] Sent: Friday, April 11, 2003 9:03 PM To: Burdett, David Cc: 'Patil, Sanjaykumar'; Assaf Arkin; Ricky Ho; public-ws-chor@w3.org Subject: Re: Abstract Bindable Choreography Burdett, David wrote: > I like this idea. It means that you have a state that can be > classified into a number of types which means it has specific > semantics associated with it. For example: > > 1. "StartState" a state that triggers the initiation of a choreography > 2. "EndState" a state that marks the end of a choreography - no > further transitions from this state are valid. > 3. "ConditionalEndState" a state that CAN mark the end of the > choreography - there might be more transitions from this state but not > necessarily > > 4. "ErrorState" a state that arises because of abnormal processing of > some kind > 5. "TimedOutState" a state that arises because of timeout event of > some kind has occurred. > I believe we should still discuss this further as the timeout is actually an event that triggers the transition from one state to another such as send response to failure. > > 6. "MessageStartState" a state which causes the sending of a message > 7. "MessageReceivedState" a state that is caused by the arrival of a > message. > > In practice these should probably be arranged into a hierarchy as > ErrorState is a subtype of EndState. > > Does this make sense? > > David > > See inline. > > -----Original Message----- > From: Patil, Sanjaykumar [mailto:sanjay.patil@iona.com] > Sent: Thursday, April 10, 2003 12:06 PM > To: Assaf Arkin > Cc: Burdett, David; Monica J. Martin; Ricky Ho; public-ws-chor@w3.org > Subject: RE: Abstract Bindable Choreography > > > > >> It's easy to say that the transition occureed due to a time constraint > >> and label it as a "time-out transition". The state you are in may have > >> some meaningful name, like "no response provided" or "time to > cancel and > >> report error". But generally speaking, if you only get to this > state due > >> to the time-out event, you may as well characterize it as "time-out > state". > > So, you find it useful to tag "both" transition and the state as of > type "time-out". Also, I agree that specifying just time-out will not > be greatly useful and we need to provide for fully defining the > time-out constraints, etc. > > Now, in the choreography language, we could either treat time-out > transitions and states as any other. Or define explicitly in the > language time-out as a type of transition, a type of state, and also > define the bondage that a timeout transition results into a timeout > state (I guess we already assume certain types for the state:- start, > end, error, etc and timed-out become one more! Is that right?) >
Received on Sunday, 13 April 2003 19:17:19 UTC