Re: Events and States (was: timeouts & states (was: Abstract Bindable Choreography))

In David's example, "State" is not mutually exclusive.  (Correct me if I'm 
wrong).  A role can have multiple "states" at the same time and each of 
this state can accept different events and transition to another 
states.  Somewhat similar to a multi-thread scenario.  So when one thread 
reaches an end state.  The choreography can still be active because of 
other threads.

This is quite different from the traditional state chart who try to avoid 
composite states.  Am I totally lost ?

Rgds, Ricky

At 02:56 PM 4/10/2003 -0700, Jon Dart wrote:

>Cummins, Fred A wrote:
>>This raises questions about the scope of a choreography.  When does
>>it end?  When a disconnect occurs?  When a particular business
>>transaction is completed?  When a relationship is terminated?
>>Maybe any of the above?
>>Do the state machines provide the mechanism for nesting of component
>>choreographies?
>
>Very good questions. But what do you want (or perhaps more importantly, 
>need) it to do? As you say, a state machine is really a mechanism. What is 
>the functional requirement?
>
>At minimum, I would guess it is the ability to transition to a distinct 
>state when a timeout occurs. This state could be the termination of the 
>choreography (implying no more processing will occur). Or it could be an 
>error state (implying there might be some warning given, or some recovery 
>effort made, e.g. a retry - this assumes you are doing this at the 
>application level and not in some lower-level reliable messaging 
>protocol). Certainly I can think of real-world examples where you'd need 
>this functionality. This is something of a simplification of earlier 
>proposals. If we need something more complex, I'd like to see some 
>rationale behind it.
>
>--Jon
>
>

Received on Friday, 11 April 2003 12:58:12 UTC