commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rahul Akolkar <rahul.akol...@gmail.com>
Subject Re: Re: [SCXML] Synchronizing state matchines
Date Fri, 03 Jul 2009 05:15:54 GMT
On Thu, Jul 2, 2009 at 6:55 PM, Cedric
NICOLAS<cedric.nicolas@villefluide.fr> wrote:
> Rahul,
>
> 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://foo.bar/master" 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 ?
<snip/>

I made no assumptions about the distribution model here. In a model
where not all the state machines can be referenced locally (in the
same JVM), the URL syntax in the above lines was meant to signify
endpoints for each of the state machines (in that scenario, the
EventDispatchers would speak to the local state machine on one end and
these endpoints or their proxies on the other). Ofcourse, if direct
references to all SCXMLExecutor instances are available, then the
scheme would be to use those directly so the URL syntax will not apply
(i.e. myaddress would be a reference to the device's executor
instance).


> I do not understand exactly the send parameters description in
> documentation.
>
<snap/>

When using custom targettypes (such as above), its really upto the
EventDispatcher to define the semantics of the parameters in the
namelist. In the above lines, I was sketching out a scenario where the
<send> would cause an event (i.e. TriggerEvent instance) with name
'device.register' to be triggered on the appropriate state machine and
its payload would be a map with two keys 'myname' and 'myaddress' and
corresponding values which would be picked up from the originating
state machine's (the one which contains the <send>) context. See how
this matches up with the _eventdata expressions within the
<transition> gating on event 'device.register' in the destination
state machine below.


>  <send target="registry.device1" targettype="x-mobile"
>        event="device.beep" namelist="beepduration"/>
>  <!-- registry.device1 may return scheme://foo.bar/device1
>       for instance -->
>
> In the same idea, this line seems to address by its name the device #1. You
> say registry.device1 may return //foo.bar/device1 But how and where does
> this translation occurs ? Here of course the target will be the
> SCXMLExecutor instance of device1.
>
<snip/>

Yup, if local, indeed. In the expression 'registry.device1',
'registry' would be a Map in the state machine's context whose keys
are device logical names and values are references to SCXMLExecutors
(or URLs that point to the remote state machine endpoints in a
distributed scenario).


> Other (and last!) question :
>
<snap/>

Theres no limit, keep'em coming :-)


> 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.
>
<snip/>

The XML for actions is simply a reusable patten extracted from
procedural code (and implemented as such, so manipulation is none the
harder or easier). To add some more detail, the registry would be a
Map stored in the root context like so (when the executor is
initialized):

  executor.getRootContext().set("registry", new HashMap());

Now, the following <my:register> action's execute(...) method would
complete the registration by accessing the above Map:

  <transition event="device.register">
    <my:register name="_eventdata.myname"
                 address="_eventdata.myaddress"/>
  </transition>

  public class RegisterAction extends Action {
      ...
      public void execute(..., SCInstance si, ...) {
          Map registry = si.getRootContext().get("registry");
          registry.put(this.name, this.address);
          // send an ack, whatever else is needed
      }
  }

-Rahul


> Thanks a lot for support.
>
> Regards,
>
>
> -----Original Message-----
> From: Rahul Akolkar [mailto:rahul.akolkar@gmail.com]
> 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<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
>> 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/EventDi
> spatcher.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


Mime
View raw message