Commons SCXML 2.0 Roadmap

The last SCXML release 0.9 has been quite some time ago (2008) and since then the
W3C SCXML specification has progressed and changed
quite a lot, and almost ready to move to Candidate Recommendation status.

The goal for Commons SCXML 2.0 is to get alignment (back) and be compliant with the W3C SCXML specification,
but for this a lot of major changes are needed, both to the public API and, even more so, to the internal
model and processing logic.

To be able to make such major changes in an effective way, we already cleaned out a lot of the old but no
longer relevant, working or otherwise incompatible features from the previous SCXML (0.9) version, see
Milestone 0 below.

The work needed towards Commons SCXML 2.0 has been divided in a set of high-level targets and corresponding
milestones:

Milestone 0: Cleanup (completed: 2014-03-11)

The first and already completed target was to cleanup and clean out no longer relevant or even no longer
working features, or features which would make it very hard or complicated to keep working and supported
for the major changes ahead.

The support for the following features and integrations has been dropped: Shale/JSF, Rhino/E4X, Servlet/JSP.

Note: some of the dropped features might be restored or re-implemented again once we reached a
reasonable level of stability for the new APIs and internal logic, but that also will depend on the level of
interest and support from the community.

Technically, this milestone 0 still is largely compatible with the 0.9 release,
just without those above mentioned features, and also now requires Java 6+. In addition this milestone also
contains several fixes and enhancements (like Groovy language support).

The current SCXMLSemantics interface and its implementation is so much different from
the algorithm in the specification that 'molding' it into what the algorithm now expects is too
cumbersome.

Also, developers wishing to extend or customize the SCXMLSemantics will have a hard time to match that
against the algorithm as well.

The intend therefore is to start with a new SCXMLSemantics interface from scratch which (largely)
follows the algorithm in the specification.

Better separation of concern between SCXMLExecutor and SCInstance.

The purpose of SCInstance is to be used as backing store for internal SCXML state. However
over time some processing and transient state based features have ended up in SCInstance which are more
appropriated to be managed by the SCXMLExecutor instead.

Conversely, SCXMLExecutor maintains the current Status for the SCXML state as well as the internal
events list going with it. Having the Status, without the processing related events list, to be
managed by SCInstance instead would be better fitting.

And finally, SCXMLExecutor currently doesn't yet provide a good abstraction or implementation of the
SCXML Event I/O Processor functionally.
The internal and external event I/O management is a critical requirement and many features of the
specification rely on it fulfilling this contract.
The goal for this milestone is to provide a least a basic level of support for the SCXML Event I/O
Processor and Event queue handling features.

Overall, the intend is to let SCXMLExecutor be responsible as SCXML Processor and SCXML I/O Processor
and to maintain all transient processing state including the system variables, while delegating to
SCXMLSemantics for dealing with the processing algorithm.

This milestone has now been completed and the most prominent changes and new features can be reviewed
through JIRA issues SCXML-196,
SCXML-197 as well as
SCXML-200.

Milestone 2: Datamodel and expression language aligment

The main target for milestone 2 is to get better alignment with the SCXML datamodel specification.

The Commons SCXML datamodel and context features are very flexible and can be defined and redefined in a
hierarchical way (per state element). However this also makes it much more complex to manage, especially for
XPath (XML) datamodel definitions.

The SCXML specification however is very explicit in its requirements that, while datamodel elements may be
defined in multiple locations within an SCXML document, together they must be accessible (and thus managed) as
a single datamodel definition.

The current Commons SCXML datamodel (and the backing Context handling) is to some extend actually more
flexible and generic than what is possible AND allowed by the specification.

To be able to be compliant with the specification, the default datamodel management in
Commons SCXML will have to be more restricted and simplified.
That will actually make things much easier to implement. For an XPath (XML) datamodel then only a single
(aggregated) XML datamodel document can be used and the custom Commons SCXML Data() function no longer will be
needed to access the data elements.

It is the intend to also retain the current flexible Commons SCXML datamodel and context features, but
provide this as custom extension, no longer as default.

The additional target is to be able to now run a substantial number of the
SCXML IPR tests. Currently almost
all still fail because of (simple) expression language issues, so fixing and improving the language support
is an important goal as well.

Milestone 3: External communications support

The target for milestone 3 is to complete the remaining SCXML Processor and SCXML I/O Processor required
features for external communications (send and invoke elements).

Commons SCXML 2.0 release

If and when all of the above milestone targets are met Commons SCXML should be very close to being in
compliance with the SCXML specification, and/or in any case at a good enough level for all practical purposes,
to be released as Commons SCXML 2.0.

Even though the IRP is not intended to be used for conformance testing of implementations, it is very much
used as a functional benchmark, also by other SCXML implementations.

Commons SCXML 2.0+: Optional SCXML features

There are still plenty of optional features in the SCXML specification which might be very useful to support,
like ECMAScript+JSON datamodel or HTTP Event I/O Processor support.

Also, adding extensions outside the specification, or bringing back some of the features dropped for
milestone 0, like integration with other frameworks or expression languages (Servlet, EL, etc.), will be
considered again.

Milestone tags

For the above milestones specific VCS milestone tags will be set, like commons-scxml2-2.0-M0.

These milestones tags however do not represent a formal release and are
only intended to be used for testing purposes by Commons SCXML developers.

Developers willing to test and validate these milestones can do so by checking out these tags
and building and deploying a milestone version into their local Maven repository.

Such locally installed milestone builds then can be used in your Maven project using a dependency
configuration like below (using milestone 0 as example):

Apache Commons, Apache Commons SCXML, Apache, the Apache feather logo, and the Apache Commons project logos are trademarks of The Apache Software Foundation.
All other marks mentioned may be trademarks or registered trademarks of their respective owners.