- From: Burdett, David <david.burdett@commerceone.com>
- Date: Thu, 10 Apr 2003 13:00:01 -0700
- To: "'Patil, Sanjaykumar'" <sanjay.patil@iona.com>, Assaf Arkin <arkin@intalio.com>
- Cc: "Burdett, David" <david.burdett@commerceone.com>, "Monica J. Martin" <monica.martin@sun.com>, Ricky Ho <riho@cisco.com>, public-ws-chor@w3.org
- Message-ID: <C1E0143CD365A445A4417083BF6F42CC053D196B@C1plenaexm07.commerceone.com>
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. 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 -----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 Thursday, 10 April 2003 16:00:08 UTC