commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cedric NICOLAS <>
Subject Re: Re: [SCXML] Synchronizing state matchines
Date Thu, 02 Jul 2009 22:55:29 GMT

Thanks a lot for this long and very precise answer and for the time taken to
think about it. 

I¹ve just 2 or 3 clarifications questions about the following line of codes
you¹ve proposed :

        <send target="scheme://" targettype="x-mobile"
              event="device.register" namelist="myname myaddress"/>

Why do you use an url-like syntax for target. Our target is an SCXMLExecutor
instance representing the master machine. How to link this url with that
instance ? I do not understand exactly the send parameters description in

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

In the same idea, this line seems to address by its name the device #1. You
say registry.device1 may return // But how and where does
this translation occurs ? Here of course the target will be the
SCXMLExecutor instance of device1.

Other (and last!) question :

You also suggest that registry would have to be stored in root context. I
suppose through Context class APIs. What are the benefits to do this instead
of using a Java code like HashMap to do this, triggered by the event above ?
Manipulating variables contents through XML is not so easy and readable if
we manage collection of objects, and may be not very optimized.

Thanks a lot for support.


-----Original Message-----
From: Rahul Akolkar []
Sent: jeudi 2 juillet 2009 19:34
To: Commons Users List
Subject: Re: [SCXML] Synchronizing state matchines

On Mon, Jun 29, 2009 at 7:05 PM, Cedric
NICOLAS<> 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.

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

 * 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://", then all device state machines
may boot like so:

  <scxml ... initial="register">

    <state id="register">
        <send target="scheme://" 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).
      <transition target="..."/>

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


(you may need to single quotes literals depending on expression language in
use throughout these snippets, so target="'scheme://'" rather
than target="scheme://" 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

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"
        <!-- All the registration bits, including the ack may be handled
             by the above custom action, for example -->

      <!-- The master state machine -->


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://
       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.)

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:



> 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:
For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message