Re: [SCXML] Plans for making SCXML more dynamic?
On Oct 26, 2014, at 10:45 AM, Benoît Thiébault thieba...@artenum.com wrote: Jake's suggestion is also interesting, but in that case I wonder how would the different state diagrams interact with each other. Each SCXML instance should receive a sessionId. Statechart instances can communicate with one another using SCXML send targetexpr=“target.sessionId”/. “target.sessionId” can be passed in dynamically when an SCXML instance is initialized. I’m not sure if sessionId is currently supported by SCXML Commons. Feel free to contact me off-list to discuss in more detail. All the best, Jacob Beard
Re: [SCXML] Plans for making SCXML more dynamic?
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 http://dev.spis.org). 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 API 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: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [SCXML] Plans for making SCXML more dynamic?
We use a state chart to represent what we call the modelling chain (cf. attached picture) OK, I can't attach pictures on the mailing list. Here it is: http://dev.artenum.com/projects/keridwen/images/modellingChain_jpg
Re: [SCXML] Plans for making SCXML more dynamic?
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. Thanks, Ate 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 http://dev.spis.org). 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 API 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: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
[SCXML] Plans for making SCXML more dynamic?
Hi everyone, I am very pleased to learn that SCXML is back online and that new evolutions are coming with version 2.0. Congrats and good luck to the development team! I already use SCXML 0.9 in one of my applications and one feature I was missing was a more dynamic state engine. My application is OSGi-based and thus very dynamic: modules come and go at runtime. What I wanted to do was to be able to modify the state diagram at runtime: when a new bundle is loaded, it injects its own state chart as a sub-set of the existing state chart. If I understood SCXML correctly, this was not really possible with 0.9. Is it planned for future versions? Kind regards, Ben - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [SCXML] Plans for making SCXML more dynamic?
On 25-10-14 09:22, Benoît Thiébault wrote: Hi everyone, I am very pleased to learn that SCXML is back online and that new evolutions are coming with version 2.0. Congrats and good luck to the development team! I already use SCXML 0.9 in one of my applications and one feature I was missing was a more dynamic state engine. My application is OSGi-based and thus very dynamic: modules come and go at runtime. What I wanted to do was to be able to modify the state diagram at runtime: when a new bundle is loaded, it injects its own state chart as a sub-set of the existing state chart. If I understood SCXML correctly, this was not really possible with 0.9. Is it planned for future versions? It isn't really clear to me under what conditions you are executing the existing state chart. 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 API 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: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [SCXML] Plans for making SCXML more dynamic?
Hi Ben, Could you create a new SCXML instance for each module? So, rather than having one global SCXML for the entire application, you have a number of small SCXML components, which you would instantiate when your module is loaded? Jake On Oct 25, 2014, at 3:22 AM, Benoît Thiébault thieba...@artenum.com wrote: Hi everyone, I am very pleased to learn that SCXML is back online and that new evolutions are coming with version 2.0. Congrats and good luck to the development team! I already use SCXML 0.9 in one of my applications and one feature I was missing was a more dynamic state engine. My application is OSGi-based and thus very dynamic: modules come and go at runtime. What I wanted to do was to be able to modify the state diagram at runtime: when a new bundle is loaded, it injects its own state chart as a sub-set of the existing state chart. If I understood SCXML correctly, this was not really possible with 0.9. Is it planned for future versions? Kind regards, Ben - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
