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 Friday, 11 April 2003 23:56:56 UTC