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

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 06:35:10 UTC