[
https://issues.apache.org/jira/browse/SCXML-197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ate Douma resolved SCXML-197.
-----------------------------
Resolution: Fixed
> Better separation of concern between SCXMLExecutor and SCInstance and
> introducing a new SCXMLExecutionContext
> -------------------------------------------------------------------------------------------------------------
>
> Key: SCXML-197
> URL: https://issues.apache.org/jira/browse/SCXML-197
> Project: Commons SCXML
> Issue Type: New Feature
> Affects Versions: 2.0
> Reporter: Ate Douma
> Assignee: Ate Douma
> Fix For: 2.0
>
>
> For the execution of a SCXML instance, several external services are used and
> needed as well as management of intermediate state and external Invoker
> instances.
> Currently these are spread out between the SCXMLExecutor and SCInstance (both
> marked as Serializable...) making it confusing and even incorrect how these
> are managed.
> The SCInstance keeps a map of current Invoker instances, while the semantics
> for these Invokers are necessarily asynchronous and running in their own
> thread.
> This makes them unqualified to be serialized together with the SCInstance.
> I'll move these to a new SCXMLExecutionContext instead.
> The SCXMLExecutionContext will encapsulate all non-persistable SCXML state,
> the internal event queue and all external services like the ErrorReporter,
> the (external) EventDispatcher
> and the NotificationRegistry (see below).
> The SCInstance currently holds the NotificationRegistry, which maintains a
> map of external SCXMListeners, which likewise should not be serialized
> together with the SCInstance.
> And the SCInstance hold a public reference to the SCXMLExecutor, which is
> used for the callback handling from Invokers, but if the SCInstance and/or
> SCXMLExecutor would be serialized, there is nothing to 'talk back' to.
> It will require some changes in the handling and communication with the
> Invokers, but once done then the SCInstance also no longer need to reference
> the SCXMLExecutor.
> For the SCXMLExecutor I will introduce an external event queue, which can be
> access concurrently, and the Invokers can and only need access to the
> SCXMLExecutor for adding events to this queue. The SCXMLExecutor thus will
> provide all the 'external' APIs, the SCXMLExecutionContext all the 'internal'
> APIs.
> The intend is to make the SCXMLExecutor and the SCXMLExecutionContext
> non-serializable and instead move the current Status and SCXML model object
> to the SCInstance instance,
> which then properly and completely will encapsulate all 'persistable' SCXML
> instance state, and can be 'detached' and 're-attached' from the
> SCXMLExecutor to be persisted or serialized.
> The SCXMLExecutionContext then will be used as single 'context' parameter for
> the SCMLSemantics provided algorithms, besides the current processing 'step'
> state, which will makes the current API a lot cleaner and the new Algorithm
> inplementations (SCXML-196) a lot easier.
> For the execution of Actions (SCXML executable content), I'll also introduce
> a new ActionExecutionContext, on top of the SCXMLExecutionContext, which
> expose only a subset of the SCXMLExecutionContext as only needed by the
> Action execution, thereby reducing the exposure of the internal API and state
> management.
> These changes will have a big impact on the current APIs, but the advantage
> is that further and future changes will be much easier to do, and with a lot
> less impact than this one time upfront big change now.
> All the internal APIs have to change anyway, no matter what, to be able to
> support and implement the current SCXML specification requirements.
> Because both the internal events and external events will now properly be
> managed through separate queues, it now also becomes easy to implement the
> 'single event step' sequential processing, as required by the specification,
> including asynchronous handling (receiving) of external events.
> To a large extend this thus also will solve SCXML-112.
> The result of all this is a SCXMLExecutor which only will need and have 3
> (primary) instance variables: a SCXMLSemantics, SCInstance and
> SCXMLExecutionContext,
> and with a clean separation of concern between them.
> This will then complete a major step for Milestone 0 of the
> [Roadmap|http://commons.apache.org/proper/commons-scxml/roadmap.html] towards
> Commons SCXML 2.0.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
