[SCXML] Synchronizing state matchines

[Cedric NICOLAS <ce...@villefluide.fr>]

Hi everybody,

We are starting to use SCXML and Java implementation to set up state
machines that represent a coordinated network of mobile devices. We are
using a master state machine that acts as a coordinator and many identical
state machines that represent the mobile devices coordinated by the master
one.

The master SM changes of states according to different states of the devices
state machines, with some complex coordination conditions.

I¹ve two questions related to this :

* as our project will integrate an increasing and important number of
states, transitions and events for the device states machines, we would like
to avoid at maximum to use Java for describing the states and event flow,
but do that in SCXML. Reason is maintainability and readability of code. How
to trigger easily events to device states machines from the master state
machine or the opposite ? More precisely, how to reference in the master
state machine the associated devices state machines ? Each device state
machine has a different SCXMLExecutor instance and context , as they of
course might be in different states at one specific moment. But how  to
trigger events in XML file  from one state machine to other states machines
like (master->device, device->master, device->device events)  ? It seems
that the target field is to be used for this, but how to reference other
state machines from the XML file ? Of course we know how to do this in Java
code, but triggering events as well as from Java code and from XML code,
increase a lot the tuning of the whole system, as it¹s becoming confusing to
understand who triggers what and when, when state machine becomes complex.
* we may have a quite important number of device state machines running
simultaneously (thousands) coordinated by several independent master state
machines. Has anyone have experience of performance bottlenecks of such an
architecture, as we will have to react in quite short response time to the
device events ? In other words, if we load in memory thousands of state
machines (typical life time of one device state machine will be between one
and two hours), will we face important memory consumptions problems ? A
solution based on data base persistent state machines, loaded on request
when we got an event, then updated in database and released from memory
wouldn¹t be better ?  (real time concurrent state machines at a given time
will be a much smaller number, as we¹ll get roughly ten to twenty events
from the devices during the lifetime.)

Thanks for your advises, as always that kind of questions in project start
time are key for future scalability

Cedric NICOLAS
Ville Fluide

Re: [SCXML] Synchronizing state matchines

[Rahul Akolkar <ra...@gmail.com>]

On Mon, Jun 29, 2009 at 7:05 PM, Cedric
NICOLAS<ce...@villefluide.fr> wrote:
> Hi everybody,
>
> We are starting to use SCXML and Java implementation to set up state
> machines that represent a coordinated network of mobile devices. We are
> using a master state machine that acts as a coordinator and many identical
> state machines that represent the mobile devices coordinated by the master
> one.
>
> The master SM changes of states according to different states of the devices
> state machines, with some complex coordination conditions.
>
> I¹ve two questions related to this :
>
> * as our project will integrate an increasing and important number of
> states, transitions and events for the device states machines, we would like
> to avoid at maximum to use Java for describing the states and event flow,
> but do that in SCXML. Reason is maintainability and readability of code. How
> to trigger easily events to device states machines from the master state
> machine or the opposite ? More precisely, how to reference in the master
> state machine the associated devices state machines ? Each device state
> machine has a different SCXMLExecutor instance and context , as they of
> course might be in different states at one specific moment. But how  to
> trigger events in XML file  from one state machine to other states machines
> like (master->device, device->master, device->device events)  ? It seems
> that the target field is to be used for this, but how to reference other
> state machines from the XML file ? Of course we know how to do this in Java
> code, but triggering events as well as from Java code and from XML code,
> increase a lot the tuning of the whole system, as it¹s becoming confusing to
> understand who triggers what and when, when state machine becomes complex.
<snip/>

Yup, the idea is to model these interaction patterns as SCXML actions
(standard or custom [1]) so that these become a little more
declarative, and more importantly, can be expressed in the SCXML
document itself rather than auxiliary procedural code. Some
brainstorming in terms of the scenario above:

 * The master state machine needs to be a well-known endpoint (could
be REST, webservice, any addressing means that make sense) for all the
mobile devices that want to coordinate. The master state machine
perhaps needs to be instantiated first, though with timeouts and
retries things can also be managed either way.

 * When a device's state machine comes up, one of the first things to
do would be to send a registration event to the master. The purpose of
this event would be to enable the master in addressing the device,
either directly or via a local proxy that gets injected as part of the
event payload -- again, the addressing scheme and registration
mechanism are completely application-specified, and very likely the
master state machine will hold some sort of device registry in its
(root) context [2]. The master may complete the handshake with an ack
before the device does anything else. Beyond that, events can flow
either way.

 * Now coming to the question of expressing all this in the various
SCXML document(s). Since you already know the recipe in Java code, we
just need to package it as a parameterized SCXML action. The SCXML
<send> standard action is designed for such communication (you can
always use your own custom action to further specialize any of this
processing, but lets see how this will work with <send> here). Lets
say the well-known endpoint for the master is the fictitious
"scheme://foo.bar/master", then all device state machines may boot
like so:

  <scxml ... initial="register">

    <state id="register">
      <onentry>
        <send target="scheme://foo.bar/master" targettype="x-mobile"
              event="device.register" namelist="myname myaddress"/>
        <!--
            'x-mobile' is a custom targettype, though x-* is generally
            discouraged scheme these days, you can use some such name.
            'myname' and 'myaddress' are variables in this context
            contain this state machine's info that the master can use.
            There could be more than two pieces of information that gets
            sent here ofcourse (whatever is needed).
        -->
      </onentry>
	  <transition target="..."/>
    </state>

    <!-- The rest of the device state machine -->

  </scxml>

(you may need to single quotes literals depending on expression
language in use throughout these snippets, so
target="'scheme://foo.bar/master'" rather than
target="scheme://foo.bar/master" if needed)

The Java code that does the actual work now needs to be packaged as
part of the EventDispatcher [3] that gets registered with this
device's state machine.

In the master state machine, the above event may be captured by a
transition in a top level state like so:

  <scxml ... initial="master">

    <state id="master">

      <transition event="device.register">
        <my:register name="_eventdata.myname" address="_eventdata.myaddress"/>
        <!-- All the registration bits, including the ack may be handled
             by the above custom action, for example -->
	  </transition>

      <!-- The master state machine -->
	</state>

  </scxml>

Likewise, the master state machine will have a similar EventDispatcher
that will allow it to send events to the devices.

  <send target="registry.device1" targettype="x-mobile"
        event="device.beep" namelist="beepduration"/>
  <!-- registry.device1 may return scheme://foo.bar/device1
       for instance -->

Device to device events then with some sharing of the device registry
that is currently with the master (update events could be multicast,
broadcast or anycast per design when devices come on and drop off).


> * we may have a quite important number of device state machines running
> simultaneously (thousands) coordinated by several independent master state
> machines. Has anyone have experience of performance bottlenecks of such an
> architecture, as we will have to react in quite short response time to the
> device events ? In other words, if we load in memory thousands of state
> machines (typical life time of one device state machine will be between one
> and two hours), will we face important memory consumptions problems ? A
> solution based on data base persistent state machines, loaded on request
> when we got an event, then updated in database and released from memory
> wouldn¹t be better ?  (real time concurrent state machines at a given time
> will be a much smaller number, as we¹ll get roughly ten to twenty events
> from the devices during the lifetime.)
>
<snap/>

It really depends on what the state machines look like, how much data
is in each one's context, how much listeners and other associated
state needs to be maintained etc. The simplest state machines can be
lightweight. Its possible to tune the datamodel to be global to reduce
memory usage (with the downsides of a global datamodel). Sometimes it
may help to pool state machines executors. Executors are serializable,
any other persistence mechanism can be implemented as an
application-specific solution per taste. There have been some recent
discussions on this topic. You can try to look through the list
archives here [4]. Here is a pointer to one such thread:

  http://markmail.org/thread/7rzalbdmbtvhr4kq

-Rahul

[1] http://commons.apache.org/scxml/guide/custom-actions.html
[2] http://commons.apache.org/scxml/guide/contexts-evaluators.html
[3] http://commons.apache.org/scxml/0.9/apidocs/org/apache/commons/scxml/EventDispatcher.html
[4] http://commons.markmail.org/


> Thanks for your advises, as always that kind of questions in project start
> time are key for future scalability
>
> Cedric NICOLAS
> Ville Fluide
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org