commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rahul Akolkar" <>
Subject Re: [SCXML] State transitions from within handler
Date Mon, 14 Apr 2008 19:18:34 GMT
On 4/14/08, Ouyang, Landon - ES/RDR -Gil <> wrote:
> Rahul,
>  Thanks for your help, I was able to implement the state transition
>  method you had described earlier.
>  The reason for this investigation is that we intend to use the Commons
>  SCXML engine to implement highly complex systems by separating all the
>  "pieces" into atomic modules (states).

Makes sense, for very simple systems [scxml] may even be overkill.

>  However, we would like the
>  decision making for the transitions to be done within the application
>  code (state handlers) and not the state machine implementation (XML). We
>  foresee problems if the XML document must specifically reference the
>  attributes needed to decide which transitions occur (ie 'result.value'
>  in our earlier example).

OK, though I don't necessarily agree. Couple of points:

 * IMO, in highly complex systems the declarative vocabulary (be it
XML or otherwise) can be thought of as merely a serialization of some
model (such as the domain UML2 state charts) which the developer(s)

 * The [scxml] library can be the basis of building components that
serve to wrapper certain conventions in place over the state machine
implementation -- conventions that mitigate problems in having to
"specifically reference the attributes needed". The
AbstractStateMachine is one such simple example (uses a convention to
call "state handlers"). However, it has drawbacks (such as invoking
handlers synchronously while processing events) and is not fit for
complex systems.

>  The only way I can think around this problem is to create a custom
>  transition/event stack in which the next event gets pushed during the
>  state handler and popped once we are officially in the current state
>  (since the previous state is still being processed while we are in the
>  handler).

May not be necessary. The following suggested replacements is how I
have understood the sentences in the above paragraph:

s/officially in a state/at rest in a state/
s/previous state is being processed/previous event is being processed/

>  Is there a better way around this issue? If not, where in
>  AbstractStateMachine will I know for a fact that the previous state's
>  processing has been completed?

See this page:

The AbstractStateMachine uses the second pattern. One of the ways to
achieve what you want is using the first pattern, "Mapping states to
activities" (current state --> state handler).

Create a variant that bootstraps similar to the AbstractStateMachine
class, waits for state machine to come to rest (initially, and when
any subsequent event is triggered on it), looks up current state
(rather than registering a listener that gets called synchronously),
and calls the corresponding state handler. Maintain a queue for
external events, have state handlers add to that queue, trigger events
in order while queue not empty. Adjustments necessary per taste etc.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message