commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ouyang, Landon - ES/RDR -Gil" <>
Subject RE: [SCXML] State transitions from within handler
Date Thu, 17 Apr 2008 18:54:18 GMT
Hi Rahul,

Thanks for your informative response.

Using your suggestions I created my own state machine class that did not
utilize a listener. I overwrote the Initialize() and fireEvent()
routines to invoke the state methods and utilize an event stack to
process external events.

The only issue with my implementation is that an event must be fired for
a state method to be invoked. For example, if we make state 4
automatically (unconditionally) transition to state 5 in the SCXML file,
state5() will not be called. It will only be called if we fire an event
in state 4 to transition to state 5.

Is there a place where I can call invoke() in the state machine
implementation (without a listener) so that the state handler is called
on a transition regardless of whether an event was fired or not?

Landon Ouyang
Member Technical Staff
ITT Electronics Systems, Radar Systems - Gilfillan
7821 Orion Ave,
Van Nuys, CA 91406
(818) 901-2982

-----Original Message-----
From: Rahul Akolkar []
Sent: Monday, April 14, 2008 12:19 PM
To: Jakarta Commons Users List
Subject: Re: [SCXML] State transitions from within handler

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
>  SCXML engine to implement highly complex systems by separating all
>  "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).
>  foresee problems if the XML document must specifically reference the
>  attributes needed to decide which transitions occur (ie
>  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
>  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:

This e-mail and any files transmitted with it may be proprietary and are intended solely for
the use of the individual or entity to whom they are addressed. If you have received this
e-mail in error please notify the sender. Please note that any views or opinions presented
in this e-mail are solely those of the author and do not necessarily represent those of ITT
Corporation. The recipient should check this e-mail and any attachments for the presence of
viruses. ITT accepts no liability for any damage caused by any virus transmitted by this e-mail.

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

View raw message