Commons SCXML
  1. Commons SCXML
  2. SCXML-197

Better separation of concern between SCXMLExecutor and SCInstance and introducing a new SCXMLExecutionContext

    Details

    • Type: New Feature New Feature
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0
    • Fix Version/s: 2.0
    • Labels:
      None

      Description

      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 towards Commons SCXML 2.0.

        Activity

        Ate Douma created issue -
        Ate Douma made changes -
        Field Original Value New Value
        Summary 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
        Ate Douma made changes -
        Description 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.
         
        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.
        Ate Douma made changes -
        Description 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.
        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.
        Ate Douma made changes -
        Description 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.
        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.
        Ate Douma made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]

          People

          • Assignee:
            Ate Douma
            Reporter:
            Ate Douma
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development