Mailing-List: contact user-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Users List" <user@commons.apache.org>
Received-SPF: pass (athena.apache.org: domain of rahul.akolkar@gmail.com
 designates 209.85.221.199 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=maMyjyi9IOw8Exgb1HOyDYhQ33oAMiZ3X0B4M72WKwk3EKPhhSTiclm0d41mh2AZnY
         NBVfXyAIeH4ptpBATfB/o4JRee4t9ZnQ4XrecvsoypptoKmnl4zF69jkldEwTQXoBslL
         KkRPA9+2Ow7aUbNXXaj8Tv1zxZrFD9wKG9DsQ=
MIME-Version: 1.0
In-Reply-To: <C66F1577.1596%cedric.nicolas@villefluide.fr>
References: <C66F1577.1596%cedric.nicolas@villefluide.fr>
Date: Thu, 2 Jul 2009 13:33:50 -0400
Message-ID: <ce1f2ea80907021033h38f96680q2bc322d142488241@mail.gmail.com>
Subject: Re: [SCXML] Synchronizing state matchines
From: Rahul Akolkar <rahul.akolkar@gmail.com>
To: Commons Users List <user@commons.apache.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Mon, Jun 29, 2009 at 7:05 PM, Cedric
NICOLAS<cedric.nicolas@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 identica=
l
> state machines that represent the mobile devices coordinated by the maste=
r
> one.
>
> The master SM changes of states according to different states of the devi=
ces
> state machines, with some complex coordination conditions.
>
> I=B9ve 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 l=
ike
> 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 =A0to
> trigger events in XML file =A0from one state machine to other states mach=
ines
> like (master->device, device->master, device->device events) =A0? It seem=
s
> 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 Ja=
va
> 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=B9s becoming confusi=
ng 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=3D"register">

    <state id=3D"register">
      <onentry>
        <send target=3D"scheme://foo.bar/master" targettype=3D"x-mobile"
              event=3D"device.register" namelist=3D"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=3D"..."/>
    </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=3D"'scheme://foo.bar/master'" rather than
target=3D"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=3D"master">

    <state id=3D"master">

      <transition event=3D"device.register">
        <my:register name=3D"_eventdata.myname" address=3D"_eventdata.myadd=
ress"/>
        <!-- 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=3D"registry.device1" targettype=3D"x-mobile"
        event=3D"device.beep" namelist=3D"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 stat=
e
> machines. Has anyone have experience of performance bottlenecks of such a=
n
> architecture, as we will have to react in quite short response time to th=
e
> 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 o=
ne
> 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=B9t be better ? =A0(real time concurrent state machines at a given=
 time
> will be a much smaller number, as we=B9ll get roughly ten to twenty event=
s
> 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/Ev=
entDispatcher.html
[4] http://commons.markmail.org/


> Thanks for your advises, as always that kind of questions in project star=
t
> 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