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/CEP/GettingStarted"

< VIATRA‎ | CEP
(Graph patterns)
(The special case of model events)
Line 22: Line 22:
  
 
==The special case of ''model events''==
 
==The special case of ''model events''==
As mentioned [VIATRA2/CEP#cep-with-iq|earlier], a unique feature of the VIATRA-CEP stack is the tight integration with an incremental graph query engine ([[http://www.eclipse.org/incquery EMF-IncQuery]]). This enables observing events arising from an underlying EMF model, and that in a '''fully automated way'''.
+
As mentioned [[VIATRA2/CEP#cep-with-iq|earlier]], a unique feature of the VIATRA-CEP stack is the tight integration with an incremental graph query engine ([http://www.eclipse.org/incquery EMF-IncQuery]). This enables observing events arising from an underlying EMF model, and that in a '''fully automated way'''.
  
 
The workflow in this case is similar to the default one above. There are two important differences though.
 
The workflow in this case is similar to the default one above. There are two important differences though.

Revision as of 17:16, 2 February 2015

The default workflow

Based on the case studies we met, the usual workflow with VIATRA-CEP is the following.

Cep-workflow.png

First, you define your event model featuring

  • atomic event patterns,
  • complex event patterns, and
  • rules, which define executable actions and associate them with the occurrence of previously defined atomic or complex event patterns.


During modeling event patterns and rules, high-quality Java code is generated. Only one of the generated packages is relevant for the user to implement his application, which is the base package. Its name is the same as the one defined in the event model. The base package contains a factory (CepFactory.java) providing factory methods for every event and rule class the user might want to reuse (instantiate) in the application.

After setting up the application, an instance of the VIATRA-CEP engine is acquired and subsequently an event stream is acquired as well from the engine's stream manager to publish the events of the application upon.

When the application starts, we enter the actual event processing phase. During this phase:

  • events from the application are pushed to the event stream, whilst
  • the engine continuously processes the events and
  • executes actions upon the recognized event patterns

in parallel.

The special case of model events

As mentioned earlier, a unique feature of the VIATRA-CEP stack is the tight integration with an incremental graph query engine (EMF-IncQuery). This enables observing events arising from an underlying EMF model, and that in a fully automated way.

The workflow in this case is similar to the default one above. There are two important differences though.

Graph patterns

First, before defining the event model, one also has to define graph pattern queries for the underlying model.

Cep-workflow-iq-extension1.png

Once the graph patterns are defined via EMF-IncQuery, they can be imported and used in the event pattern as Query result change event patterns.

Runtime behavior

The second important difference does not actually affect the user, since it is a change in the runtime execution.

Cep-workflow-iq-extension2.png

In order to observe events of the underlying model, these events are required to be forwarded to the CEP engine. Although, this is fully automated and therefore, completely invisible to the user. In the background, the an bridge component (IncQuery2ViatraCep.java) is generated which

  • produces events on both newly found and disappearing graph pattern matches, and
  • forwards them to the CEP engine on a dedicated event stream.

Back to the top