commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ate Douma (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SCXML-197) Better separation of concern between SCXMLExecutor and SCInstance and introducing a new SCXMLExecutionContext
Date Thu, 03 Apr 2014 07:19:25 GMT

    [ https://issues.apache.org/jira/browse/SCXML-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13958595#comment-13958595
] 

Ate Douma commented on SCXML-197:
---------------------------------

The new definition and implementation of the SCXMLSemantics by SCXML-196 also automatically
resulted in some further  separation of concerns for the SCXMLExecutor, SCInstance and SCXMLExecutionContext,
which 'fitted well' with the goals for this issue.
While those changes have been committed against SCXML-196, I'm describing the high-level changes
here.

The SCXMLExecutor now is completely 'detached' from both SCInstance and SCXMLExecutionContext,
and only holds a reference to the SCXMLSemantics and SCXMLExecutionContext itself.

Functionally, the SCXMLExecutor now is reduced to be only a 'driver' providing the public
(user) interface for executing SCXML based state machines, and receiving events to do so.

Behind this public executor facade, the SCXMLExecutionContext now manages everything except
the external event queue and driving the SCXMLSemantics.
The state machine processing through the SCXMLSemantics is driven by the SCXMLExecutor providing
it the SCXMLExecutionContext as input.

The SCInstance now hold all and only the state machine persistable state, and can be 'detached'
and 're-attached' in the SCXMLExecutionContext (serviced through the SCXMLExecutor).

The default SCXMLSemantics implementation is fully stateless and invoked from the SCXMLExecutor
through only three main entry points: firstStep, nextStep and finalStep, taking the SCXMLExecutionContext
as parameter. 

With these changes in SCXML-196 and SCXML-197, the goals for Milestone 1 on the roadmap to
SCXML 2.0 have been completely met and I'll create a milestone 1 svn tag for it shortly.

> 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)

Mime
View raw message