commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rahul Akolkar <>
Subject Re: [SCXML] History in parallel?
Date Thu, 14 Jan 2010 19:53:55 GMT
On Wed, Jan 13, 2010 at 6:24 PM, Bill Herring <> wrote:
> I didn't think of that, and it's more elegant than the workaround I used,
> which was to put history tags in the talk_status, call_status, etc. inside
> the parallel state and target those histories instead of a single one.
>  Thanks for the tip!  I'll make sure I prefix future subject lines with
> SCXML too.
> Also,  have another unrelated question - please let me know if you'd rather
> me post it to the list under a new subject, and I'll do so.

Yup, updated email subjects are useful (for the archives etc.). If
this discussion continues, please use an appropriate subject for your
next post, thanks!

> In my ignorance of CommonsSCXML (I picked it up a few weeks ago), I'm trying
> to programatically inject some bits of data into the datamodel for a state
> before I fire an event that will target that state.  Then when the
> transition fires and the target state is reached, a <send> that makes use of
> the datamodel (ala the namelist attribute) fires onentry.  The goal is to
> communicate data from one "client" of the state machine to another.
> If this seems overly complicated, perhaps it is...  But assuming there's not
> a better way, my current problem is that I can modify the datamodel of the
> target easily enough, via getDataModel() and setDateModel().  This works
> fine the first time, but fails to "send" any new data after that because the
> target state's context gets created once and then is not updated when I
> change the datamodel - the two are out of synch.

Yup, thats the template vs. instance distinction -- changes to the
model won't be picked up once a state machine executor instance is set
in motion. Indeed, the data model for an SCXML defined state machine
is supposed to be fully populated and available at load time. There
are usecases for injecting parts of the datamodel at state machine run
time, but such client usage needs to be responsible (Commons SCXML
provides a limited means to this by allowing access to the root
context as you note). Ideally, one would not touch the datamodel while
events are being processed or transitions are being filtered for
example. Any additional information may come in as event payloads and
be utilized / copied to the appropriate datamodel using executable
actions such as assign (this ensures that such behavior is modeled as
part of the state machine, rather than procedural injection that is
otherwise invisible to the reader of the SCXML document).

> So I need to be able to synch the two - there are public methods to get the
> root context, but how do you get the context for a specific state?

Following the mantra of modeling the state machine entirely as SCXML,
rather than procedurally injecting such data, one can use event
payloads and custom actions to perform this. So, lets say the data to
be added comes in as the payload of event with name "", then on
transition one could populate the specific state context like so:

 <scxml:transition event="" ...>
   <my:save stateid="baz" .../> <!-- payload has data for baz's context -->

such that <my:save> is a fictitious custom action that is a fancy
version of assign for your usecase. Custom actions have access to all
of the state machine instance (via the SCInstance parameter of the
Action#execute method). Ofcourse, may need to adjust per taste -- but
do investigate whether this is a suitable pattern for your usecase.

>  I guess
> I could just use the root context to do everything, but that seems clumsy,
> and I'm interested in how I can manipulate other contexts anyway (preferably
> without modifying the CommonsSCXML interfaces).

In addition to my comments above, note that there have been
discussions in the Working Group about removing data model scoping
altogether. IOW, there may be a flat scope for SCXML documents i.e.
only one context for the entire SCXML document going forward.
Ofcourse, we will have to wait for the next Working Draft to see if
this change goes through. And in that case, using the root context for
everything will be a necessity rather than a choice (though Commons
SCXML is designed so we can continue to support all kinds of scoping
patterns users need).

> There are clearly other ways to structure the passing of such data, but I am
> assuming that the code that fires the transitioning event and the code that
> handles the send event have no way to communicate other than via the state
> machine.  Also, I don't want to depend on the send event being handled
> immediately after the firing of the transition event, even though that may
> be the case in my current implementation (i.e. another transition might
> happen and trigger another send before the current one is processed).

Right. The solution above takes care of that (<my:save> happens in the
said <transition> and the current event payload will persist inspite
of other <send>s etc.).

>  And,
> finally, though I can see ways to not use it, I believe <send> best reflects
> my intent - to send a message to an object/thread/program that is external
> to the state machine.

Seems reasonable with the details so far.


> Of course, I could be wrong... :)
> Thanks again for your help,
> Bill
> On Jan 13, 2010, at 3:40 PM, Rahul Akolkar wrote:
>> Please prefix the email subject with the Commons component name when
>> posting, as I've done here (since this is a shared mailing list).
>> Response below ...
>> On Thu, Jan 7, 2010 at 5:51 PM, Bill Herring <>
>> wrote:
>>> My reading of the latest W3C working draft is that SCXML supports history
>>> pseudo-states in parallel ones.   When I run my app with the SCXML model
>>> below, I get:
>>>       WARNING: Ignoring element <history> in namespace
>>> ""
>>> and then it cannot find the two resume_ targets.
>>> Does Commons SCXML support history elements as parallel children?  Am I
>>> doing something wrong here?
>> <snip/>
>> The current release (v0.9) does not support history in parallel.
>> Work has been done in a development branch on a version of the parser
>> that does support history as used below, but its yet incomplete and
>> unreleased.
>> While using v0.9, I'd suggest using a state wrapper element around the
>> parallel to hold the deep history.
>> -Rahul
>>> <?xml version="1.0"?>
>>> <scxml xmlns=""
>>>      version="1.0" initial="off_call">
>>>       <state id="off_call">
>>>               <transition event="dial" target="call_active"/>
>>>       </state>
>>>       <parallel id="call_active">
>>>               <state id="talk_status" initial="talking">
>>>                       <state id="talking">
>>>                               <transition event="hold"   target="held"
>>>                       </state>
>>>                       <state id="held">
>>>                               <transition event="retrieve"
>>> target="talking" />
>>>                       </state>
>>>               </state>  <!-- END talk_status -->
>>>               <state id="call_status" initial="on_call">
>>>                       <state id="on_call">
>>>                               <transition event="hangup"
>>>  target="off_call"/>
>>>                               <transition event="consult"
>>> target="consult_active"/>
>>>                       </state>
>>>                       <state id="on_call_consult">
>>>                               <transition event="hangup"
>>>  target="off_call"/>
>>>                               <transition event="alternate"
>>> target="resume_consult"/>
>>>                       </state>
>>>               </state>    <!-- END call_status -->
>>>               <history id="resume_call" type="deep"/>
>>>       </parallel>  <!-- END call_active -->
>>>       <parallel id="consult_active">
>>>               <state id="consult_talk_status" initial="consult_talking">
>>>                       <state id="consult_talking">
>>>                               <transition event="hold"
>>> target="consult_held" />
>>>                       </state>
>>>                       <state id="consult_held">
>>>                               <transition event="retrieve"
>>> target="consult_talking" />
>>>                       </state>
>>>               </state>  <!-- END consult_talk_status -->
>>>               <state id="consult_status" initial="on_consult">
>>>                       <state id="on_consult">
>>>                               <transition event="hangup"
>>>  target="resume_call"/>
>>>                               <transition event="alternate"
>>> target="resume_call"/>
>>>                       </state>
>>>               </state>    <!-- END consult_status -->
>>>               <history id="resume_consult" type="deep"/>
>>>       </parallel>  <!-- END consult_active -->
>>> </scxml>
>>> Thanks,
>>> Bill
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> Bill Herring
> OpenMethods
> 4741 Central Street  |  Suite 285  |  Kansas City, MO  |  64112-1533
> o| +1.816.283.VXML (8965) x105
> |
> P This email is composed of 100% recycled electrons. Please print only when
> necessary.

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

View raw message