[
https://issues.apache.org/jira/browse/SCXML-197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ate Douma updated SCXML-197:
----------------------------
Summary: Better separation of concern between SCXMLExecutor and SCInstance
and introducing a new SCXMLExecutionContext (was: Provide a SCXMLEnvironment
to encapsulate all non-persitable and intermediate SCXML state and external
Services for a SCXMLExecutor)
> 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 intermediate state management and non-persistable objects
> as well.
> Currently these are spread out between the SCXMLExecutor and SCInstance (and
> 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 the new SCXMLEnvironment instead.
> SCInstance also holds the NotificationRegistry, which maintains a map of
> external SCXMListeners, which likewise should not be serialized together with
> the SCInstance. I will also move this NotificationRegistry to the
> SCXMLEnvironment.
> And the SCInstance hold a 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.
> The SCXMLExecutor then, currently holds an EventDispatcher and ErrorReporter
> which also are 'externally' provided. These 'services' also should move to
> the new SCXMLEnvironment.
> My intend is to make the SCXMLExecutor, and the new SCXMLEnvironment both
> non-serializable and instead move the current Status and SCXML model object
> to the SCInstance instance, which then properly and completely can
> encapsulate all SCXML instance state, and be serialized (or persisted
> otherwise) if desired.
> The SCXMLExecutor also currently holds the internal and external event queue
> which I also will move to the SCXMLEnvironment.
> The SCXMLEnvironment then will manage these event queues, and provide the
> SCMXL I/O Processor services on top of them. This then also can be used to
> 'connect' the Invokers instead of via the SCXMLExecutor like it is right now.
> Finally, I will introduce a dedicated EnvironmentContext, also managed by the
> SCXMLEnvironment, which will 'expose' the specification based environment
> variables to the SCXML runtime (and ensure these variables are properly
> readonly as required). This EnvironmentContext will be 'injected' between the
> (external data) RootContext and the SCXML state contexts so they always will
> be accessible from within the SCXML runtime.
> The end result will be that the SCXMLExecutor only will need and have 3
> (primary) instance variables: a SCXMLSemantics, SCInstance and
> SCXMLEnvironment.
> The SCXMLExecutor role then properly and only will become a 'driver' for
> executing an SCXML instance and also no longer needs to be serializable
> itself.
>
--
This message was sent by Atlassian JIRA
(v6.2#6252)
