Revision as of 09:57, 14 February 2013

Event-driven Virtual Machine

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). In the current paper, we generalize this approach to provide a common conceptual framework for an event-driven virtual machine (EVM) architecture.

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

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.

Usage examples

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)