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

Dear Ricky,

Sorry I have not replied to this one before - probably a dead thread now but
I feel I ought to answer Ricky's question for completeness now I have found
this message again.

As far as I know there are two ways of recording that you have entered this
state before when using the finite state machine approach.  One is to
increment a state variable on each passage through the state  - let us call
it COUNTER being very inventive!  Then you can test the value of this 'state
variable and use it to determine the next state (for instance).  So you
could have If  timeout expires and COUNTER<5 then go to state X else if
timeout expires and COUNTER>=5 then go to state Y.  Obviously once you have
the notion of these variables you can use them for other purposes as well.
I think the are always used in conditional tests.

If you do not admit to state variables in your finite state machine then
another way of recording past history is to have different states.  So
instead of having one "awaiting message A or timeout" state you could have
six.  Now these are actually different states.  I do not know if it is
correct / accepted terminology, but I called these sub states as they all
have basically the same purpose.

See also Assaf's reply which gives a different, but good example of the use
of state variables to save states and give more flexibility in the design of
finite state machines

Best Regards     Tony
A M Fletcher
 
Cohesions 1.0 (TM)
 
Business transaction management software for application coordination
 
Choreology Ltd., 13 Austin Friars, London EC2N 2JX     UK
Tel: +44 (0) 20 76701787   Fax: +44 (0) 20 7670 1785  Mobile: +44 (0) 7801
948219
tony.fletcher@choreology.com     (Home: amfletcher@iee.org)


-----Original Message-----
From: Ricky Ho [mailto:riho@cisco.com] 
Sent: 11 April 2003 18:18
To: Fletcher, Tony; public-ws-chor@w3.org
Subject: RE: Events and States (was: timeouts & states (was: Abstract
Bindable Choreography))


Can you define the new terms you introduce: "state variable", "substate" ?

Rgds, Ricky

At 11:34 AM 4/11/2003 +0100, Fletcher, Tony wrote:

>I think basically I agree with Fred below, and with Assaf's messages a
>few back.
>
>A timeout is an event that I would have thought any usable choreography
>language is going to have to deal with overtly or covertly.
>
>When such an event occurs there are a number of possibilities that it
>should be possible to specify in the language for the reaction.  I am 
>not sure the following list is complete, but I would have thought the 
>reaction to a timeout event should include:
>
>A) Do nothing (i.e. ignore in the current state)
>
>B) Record the fact that the event has occurred (e.g. by incrementing a
>state variable or moving from one (sub)state to another)
>
>C) Transition to a new state (which thus provides some level of
>'memory' of the occurrence of this event).
>
>The naming of states and transitions could, in principle, be regarded
>as an independent matter, though it is common, and I think good, 
>practise to name things in a meaningful fashion.  So transitions are 
>often named after the event that caused them and states can either be 
>named after the history that caused them to be entered or the 
>anticipated next main event, or the main action that is performed while 
>in the state.
>
>In response to a recent mail from Steve (Ross-Talbot), yes I think the
>choreography language will have to deal with at least relative time 
>(both this must happen before / after this sequencing and something 
>must happen within so many seconds / minutes / hours / days of this 
>event or .... (specification of what may or shall happen).
>
>As someone pointed out, real implementations may need to be 'conscious'
>of absolute time and be able to switch chorography behaviour at a given 
>time (or indeed on the detection of some other condition).  If we 
>produce a language to describe such then we will have to cater for 
>these conditions somehow.  However, if we major on the external 
>behaviour then these events (certain conditions being satisfied / not 
>satisfied) can be 'hidden' just as an internal event - I would have 
>thought we will have to at least allow for such 'internal' events 
>occurring.
>
>
>Best Regards     Tony
>A M Fletcher
>
>Cohesions 1.0 (TM)
>
>Business transaction management software for application coordination
>
>Choreology Ltd., 13 Austin Friars, London EC2N 2JX     UK
>Tel: +44 (0) 20 76701787   Fax: +44 (0) 20 7670 1785  Mobile: +44 (0)
>7801 948219
>tony.fletcher@choreology.com     (Home: amfletcher@iee.org)
>
>
>-----Original Message-----
>From: public-ws-chor-request@w3.org
>[mailto:public-ws-chor-request@w3.org] On Behalf Of Cummins, Fred A
>Sent: 10 April 2003 22:32
>To: jdart@tibco.com; public-ws-chor@w3.org
>Subject: Events and States (was: timeouts & states (was: Abstract 
>Bindable Choreography))
>
>
>
>I don't see this as implementation, although it is dipping into a bit
>of detail that might be deferred.
>
>I think the discussion has demonstrated that we are talking about
>public state machines and events that correspond to the sending, 
>receiving or time-out of messages.
>
>We might consider generic state machines as implied by David Burdett's
>note, where a transition from start state may occur by the sending of a 
>message (client?) or the receipt of a message (server?).  The state 
>machine is then in an active state, may have a number of sub- states as 
>the exchange progresses, and may leave the active state as a result of 
>certain events such as a time-out.
>
>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?
>
>Fred
>
> > -----Original Message-----
> > From: Jon Dart [mailto:jdart@tibco.com]
> > Sent: Thursday, April 10, 2003 4:20 PM
> > To: public-ws-chor@w3.org
> > Subject: RE: timeouts & states (was: Abstract Bindable Choreography)
> >
> >
> >
> > IMO this thread is veering into implementation, which, although the
> > proposals seem reasonable, is premature IMO.
> >
> > Can I suggest a re-focusing of the thread on the requirements for
> > timeout handling (and perhaps error handling in general)?
> >
> > --Jon
> >
> >

Received on Friday, 23 May 2003 02:47:26 UTC