Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "VIATRA/Transformation/EventDrivenVM"

(design decisions and development ideas added)
Line 33: Line 33:
 
* A '''rule engine''' is created for a given EMF-IncQuery engine and an optional set of rule specifications, and has its own agenda.
 
* A '''rule engine''' is created for a given EMF-IncQuery engine and an optional set of rule specifications, and has its own agenda.
 
* A '''execution schema''' is a special rule engine, that also has a scheduler set up.
 
* A '''execution schema''' is a special rule engine, that also has a scheduler set up.
 +
 +
== Example code ==
 +
 +
TODO simple example based on some metamodel
  
 
== Usage scenarios ==
 
== Usage scenarios ==
Line 45: Line 49:
 
==== Efficiently reacting to pattern match set changes ====
 
==== Efficiently reacting to pattern match set changes ====
 
TODO
 
TODO
 +
 +
== Design decisions and code style ==
 +
 +
These guidelines are derived from the main decision to create a defensive framework to minimize the internal argument checks and idiot-proofing required.
 +
 +
=== User interaction with the framework ===
 +
 +
* Users interact with rules and activations through Façade classes:
 +
** RuleEngine façade provides access to an Agenda and it's rule instances
 +
** ExecutionSchema façade provides access to a Scheduler and through that to the Executor
 +
** These Façade classes can be retrieved through the static methods of EventDrivenVM or by static create methods (for specific implementations)
 +
* Any object that a user can access through the Façade must have only public methods that do not endanger their engine (e.g. Activation.fire(), but not Activation.setState())
 +
* Any collection that a user can access through the Façade must be immutable to avoid modifications (e.g. getActivations)
 +
* Any object that is provided by the user must be copied if it's later modification can cause internal problems (e.g. life cycle for rules)
 +
 +
=== Parameters, input checking and logging ===
 +
 +
* Method parameters cannot be null!
 +
** This is checked by Preconditions.checkNotNull(ref, msg). Return a meaningful message on null.
 +
** Use the ''this.field = checkNotNull(field, msg)'' form in constructors when possible.
 +
** Define delegate methods where optional parameters are allowed.
 +
* All logging is done through the IncQueryEngine, if available, use the debug level for detailed report messages and error or warning when encountering a real problem (e.g. IncQueryException)
 +
 +
=== Default implementations ===
 +
 +
There are a high number of notification mechanisms and event processing, that must have an interface for extendibility, a good default implementation and a clear way of overriding.
 +
 +
* In RuleInstance notification providers and listeners are created in prepareX methods.
 +
* Default life cycles prepared with unmodifiable static instances.
 +
* Update complete provider implementations (IQBase and EMF transaction).
 +
* Scheduler implementations (update complete and timed).
 +
* Job implementations (stateless with a single match processor, and recording for transactional model modification).
 +
 +
== Development ideas ==
 +
 +
=== Related issues on BugZilla ===
 +
 +
* engine lifecycle: https://bugs.eclipse.org/bugs/show_bug.cgi?id=398744
 +
* activation ordering: https://bugs.eclipse.org/bugs/show_bug.cgi?id=403825
 +
* exception handling: https://bugs.eclipse.org/bugs/show_bug.cgi?id=404307
 +
 +
=== Other future tasks not yet created as an issue ===
 +
 +
* systematic testing: both unit and component tests on API classes and default implementation
 +
 +
* add identifier to RuleSpecification (also allow finding rule by id in RuleEngine?)
 +
 +
* support main transformation scenarios
 +
** batch
 +
** single job appear-disappear
 +
** semi and fully automated execution
 +
** ignore initial activations
 +
 +
* support retrieval of filtered activations of a rule with a partial match
 +
 +
* integrate into upstream components
 +
** query-based features
 +
 +
* ensure that commands stored by RecordingJobs are only kept in Context when necessary or for a short time (e.g. clear at start of scheduled execution?)
 +
 +
* make EVM core EMF and EMF-IncQuery independent (IPatternMatch as Activation context is acceptable, since interface is clear)
 +
 +
* event queueing is problematic (job execution during activation firing can change the state)

Revision as of 04:03, 10 April 2013

The EMF-IncQuery Event-driven Virtual Machine

Overview

Nowadays, collaboration and scalability challenges in modeling tools are typically addressed with dedicated problem-specific solutions e.g.:

  • On-the-fly constraint evaluation engines (to provide scalability for model validation)
  • Incremental model transformation tools (to address performance issues of e.g. model synchronization)
  • Incremental model comparison algorithms (to support versioning and model merge in collaborative scenarios)
  • Design space exploration tools (to optimize models towards a design goal).

The common recurring task in these applications is to capture and process not only the models, but also their changes as a stream of events (operations that affect models). We generalized this approach to provide a common conceptual framework for an event-driven virtual machine (EVM) architecture.

The EVM is a rule-based system with a special focus on versatile model transformations, with built-in support for reacting to model and query result changes and user interactions. The EVM integrates various execution schemes into a uniform and flexible architecture, to provide a common framework that even allows for combinations of advanced model transformation scenarios, e.g. by the interleaving of various execution strategies (batch, live/triggered and exploratory) within a single transformation program.

Core architecture

Overview of the Event-driven VM

The event-driven virtual machine allows the central management of executable actions defined on event sources and can execute these actions automatically with a predefined schedule.

  • An activation is wrapper of a pattern match with a corresponding rule instance and state.
    • Activation states are: inactive, appeared, fired, updated, disappeared
  • A rule instance manages the activations corresponding to a rule specification in a given EMF-IncQuery engine.
  • A rule specification defines the life cycle for changing the activation state in response to events and the possible actions that can be executed on an activation in a given state.
    • Events related to a life cycle are: match appears/disappears/updates, activation fires
    • State transitions in a life cycle always have a source state, an event and a target state. There can be only one (source state, event) pair in the life cycle, thus the target state is always deterministic.
    • Jobs are atomic actions that are performed if an activation is fired when in a state defined by the job.
    • An activation is enabled if there is at least one job that is defined for the current state of the activation.
  • An agenda is a collection of rule instances with an added responsibility of ordering the enabled activations of all rule instances related to the same EMF-IncQuery engine
    • The agenda keeps track of the activations of the rule instances by an activation notification mechanism. Rule instances notify the agenda if one of their activations changed state in response to an event.
  • An executor is responsible for executing enabled activations in the agenda when it is scheduled to do so, and to provide an execution context to store execution results or other data related to execution.
  • A scheduler is defined to respond to some kind of global event (e.g. transaction commit, user request, or EMF-IncQuery Base update callback) by scheduling its executor.
  • A rule engine is created for a given EMF-IncQuery engine and an optional set of rule specifications, and has its own agenda.
  • A execution schema is a special rule engine, that also has a scheduler set up.

Example code

TODO simple example based on some metamodel

Usage scenarios

Both the data binding and validation frameworks of EMF-IncQuery use the EVM for handling events.

  • Data binding: observable match result collections are created in the createRuleSpecification method of ObservableCollectionHelper (org.eclipse.incquery.databinding.runtime.collection package)
  • Validation constraints are created in the constructor of ConstraintAdapter (org.eclipse.incquery.validation.runtime package)

Programming against the EVM API

Efficiently reacting to pattern match set changes

TODO

Design decisions and code style

These guidelines are derived from the main decision to create a defensive framework to minimize the internal argument checks and idiot-proofing required.

User interaction with the framework

  • Users interact with rules and activations through Façade classes:
    • RuleEngine façade provides access to an Agenda and it's rule instances
    • ExecutionSchema façade provides access to a Scheduler and through that to the Executor
    • These Façade classes can be retrieved through the static methods of EventDrivenVM or by static create methods (for specific implementations)
  • Any object that a user can access through the Façade must have only public methods that do not endanger their engine (e.g. Activation.fire(), but not Activation.setState())
  • Any collection that a user can access through the Façade must be immutable to avoid modifications (e.g. getActivations)
  • Any object that is provided by the user must be copied if it's later modification can cause internal problems (e.g. life cycle for rules)

Parameters, input checking and logging

  • Method parameters cannot be null!
    • This is checked by Preconditions.checkNotNull(ref, msg). Return a meaningful message on null.
    • Use the this.field = checkNotNull(field, msg) form in constructors when possible.
    • Define delegate methods where optional parameters are allowed.
  • All logging is done through the IncQueryEngine, if available, use the debug level for detailed report messages and error or warning when encountering a real problem (e.g. IncQueryException)

Default implementations

There are a high number of notification mechanisms and event processing, that must have an interface for extendibility, a good default implementation and a clear way of overriding.

  • In RuleInstance notification providers and listeners are created in prepareX methods.
  • Default life cycles prepared with unmodifiable static instances.
  • Update complete provider implementations (IQBase and EMF transaction).
  • Scheduler implementations (update complete and timed).
  • Job implementations (stateless with a single match processor, and recording for transactional model modification).

Development ideas

Related issues on BugZilla

Other future tasks not yet created as an issue

  • systematic testing: both unit and component tests on API classes and default implementation
  • add identifier to RuleSpecification (also allow finding rule by id in RuleEngine?)
  • support main transformation scenarios
    • batch
    • single job appear-disappear
    • semi and fully automated execution
    • ignore initial activations
  • support retrieval of filtered activations of a rule with a partial match
  • integrate into upstream components
    • query-based features
  • ensure that commands stored by RecordingJobs are only kept in Context when necessary or for a short time (e.g. clear at start of scheduled execution?)
  • make EVM core EMF and EMF-IncQuery independent (IPatternMatch as Activation context is acceptable, since interface is clear)
  • event queueing is problematic (job execution during activation firing can change the state)

Back to the top