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, 11 April 2003 13:18:17 UTC