[SCXML] equivalent to Rhapsody Join pseudostate

[Jacob Beard <jb...@cs.mcgill.ca>]

Hi,

I'm currently working on a small compilers project based on SCXML, and
I'm trying to understand some of the ways it differs from the Rhapsody
syntax and semantics.

To start out, it's fairly clear to me how to express the equivalent of
a Rhapsody fork pseudostate in SCXML (multiple states listed on the
target attribute of a transition), but it's unclear to me how to
express something like a Rhapsody join pseudostate, where, in order
for the join transition to be taken, the configuration must include
all of the source states of the join. Is there a clear way to express
these semantics in SCXML?

If my question is unclear, or further information is required, please
let me know.

I'd appreciate any guidance anyone can offer. Thanks,

Jake

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org

Re: [SCXML] equivalent to Rhapsody Join pseudostate

[Rahul Akolkar <ra...@gmail.com>]

On Wed, Mar 10, 2010 at 12:45 AM, Jacob Beard <jb...@cs.mcgill.ca> wrote:
> Hi,
>
> I'm currently working on a small compilers project based on SCXML, and
> I'm trying to understand some of the ways it differs from the Rhapsody
> syntax and semantics.
>
> To start out, it's fairly clear to me how to express the equivalent of
> a Rhapsody fork pseudostate in SCXML (multiple states listed on the
> target attribute of a transition), but it's unclear to me how to
> express something like a Rhapsody join pseudostate, where, in order
> for the join transition to be taken, the configuration must include
> all of the source states of the join. Is there a clear way to express
> these semantics in SCXML?
>
<snip/>

Yes, using orthogonal states. Join or fork pseudostates in Rhapsody
are well-structured (i.e joins imply matching some set of previously
forked source states). In SCXML, such orthogonal states are handled
using the SCXML <parallel> element (see [1] for details). The start of
a parallel implies a fork and a join can either be modeled implicitly
(when all child states of a parallel run to completion) by waiting for
the done event of the <parallel> or explicitly by waiting for done
events of some (sub)set.

Simple example below:

<state id="s1">
  <!-- Fork below, source = s1,
                   target = {s2,s3,s4} -->
  <transition event="fork" target="p"/>
</state>

<parallel id="p">
  <state id="s2">
    ...
  </state>
  <state id="s3">
    ...
  </state>
  <state id="s4">
    ...
  </state>
  <!-- Join below, source = {s2,s3,s4},
                   target = s5 -->
  <transition event="done.state.p" target="s5"/>
</parallel>

<state id="s5">
  ...
</state>

(caveat - the done event name syntax above matches the latest SCXML
WD, but not the latest Commons SCXML release)

More elaborate fork-join topologies can be achieved by appropriate
nesting of orthogonal states.

-Rahul

[1] http://www.w3.org/TR/scxml/#parallel


> If my question is unclear, or further information is required, please
> let me know.
>
> I'd appreciate any guidance anyone can offer. Thanks,
>
> Jake
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org