The last SCXML release 0.9 has been quite some time ago (2008) and since then the W3C SCXML specification, as of 11 March 2014 a "Candidate Recommendation", has progressed and changed quite a lot.
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:
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 target for milestone 1 is a redesign and better separation of concerns of the main SCXML processing components: SCXMLSemantics, SCXMLExecutor and SCInstance.
The high-level plan is to:
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.
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.
The 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 target for milestone 3 is to complete the support for the remaining SCXML model elements.
The current Commons SCXML is still missing implementation of some SCXML element features, or is providing functionality or behavior not compliant with the specification.
The target for milestone 4 is to complete the remaining SCXML Processor and SCXML I/O Processor required features for session management and external communications (send and invoke elements).
There are several requirements and restrictions with respect to environment variables which also needs to be supported.
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.
As part of validation the implementation, the SCXML 1.0 Implementation Report Plan will be used to test against.
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.
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.
For the above milestones specific VCS milestone tags will be set, like commons-scxml-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):
org.apache.commons
commons-scxml2
2.0-M0
]]>