commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ate Douma <>
Subject Re: [SCXML] Plans for making SCXML more dynamic?
Date Mon, 27 Oct 2014 01:02:00 GMT
Hi Ben,

Very interesting use-case: Commons SCXML into space :)

I've only briefly looked at the image you shared, but it is difficult for me to 
comprehend the exact usage or how this is represented in SCXML.

If you'd be able to share some example SCXML document, and how parts of that 
should be(come) dynamically injected/removed, it might become easier to 
understand what your requirements are.



On 26-10-14 15:45, Benoît Thiébault wrote:
> Hi and thank you for your answers
>> It isn't really clear to me under what conditions you are executing the existing
state chart.
> We are developing an open source scientific software called SPIS (for Spacecraft Plasma
Interactions Software As its name implies, it models the physics of
space plasmas around in-orbit satellites, but I guess that's off-topic ;-).
> We use a state chart to represent what we call the "modelling chain" (cf. attached picture),
which is a generic definition of the steps to go through for modelling a spacecraft.
> The software is based on OSGi and is composed of modules (called bundles in OSGi terminology)
that are loaded dynamically. Roughly, we can say that each module provides the features necessary
to perform one step of the modelling chain: we have a spacecraft geometry modeller, a mesher,
an editor for initial and boundary conditions, etc. When the application starts, all bundles
are loaded (we don't know the order in which they are loaded, it's the OSGi framework that
decides depending on module dependencies). As of today, we have a unique, central state engine
that defines the steps of the modelling chain and the modules trigger the transitions when
they are done.
> For now, there is just a single version of the software, but the idea is to be able,
in the future, to provide different versions, with different capabilities depending on the
modules provided. It is somewhat similar to what you can do with Eclipse distributions (Eclipse
is OSGi-based by the way): depending on the modules installed, you have a Java IDE, a C++
IDE or a Fortran IDE (or something completely different). In our case, we could model different
physics and modify the modelling chain on the fly depending on the loaded modules. We call
that an IME (Integrated Modelling Environment). In that scenario, we would like the modules
to inject in the central state chart the steps they are able to provide, not like today where
it isn't dynamic: the state chart is defined centrally and the modules cannot modify it.
> The solution you suggest is indeed interesting and could solve our problem. I was just
wondering what was already coded in SCXML API and what needed to be done (either on our side
or in the library).
> Jake's suggestion is also interesting, but in that case I wonder how would the different
state diagrams interact with each other.
> Kind regards,
> Ben
>> Can't you simply rewrite (extend) the underlying SCXML XML document and then reload/reset
the statemachine with the updated document?
>> That should be trivial to do and always have been possible.
>> Or do you need to retain the current (context) state?
>> That might be tricky as the current state is based on and tied to the SCXML model,
so if (sub)modules 'come and go' dynamically, you would need to ensure the SCXML state is
still valid and representative for the model.
>> Maybe something like the following is an option?
>> a) lock down the statemachine (disallow concurrent access/execution)
>> b) somehow capture/clone the current internal state externally
>> c) update your SCXML document as you need, using plain XML API or Commons SCXML Java
>> d) reload the SCXML statemachine
>> e) restore the previously captured state (step b)
>> f) unlock the statemachine
>> AFAICS the above should be doable without changes to the current Commons SCXML implementation
(and likely even with the 0.9 version), but for step b and e to probably need to hook into
(possibly extend) the Commons SCXML Java API.
>> If you have more concrete problems or otherwise think Commons SCXML really need more
dynamics support I'd be happy to discuss them further, but you need to be more specific for
me to understand your requirements.
>> And of course I'd welcome contributions as well :)
>> Regards,
>> Ate
>>> Kind regards,
>>> Ben
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message