|
|
| (26 intermediate revisions by the same user not shown) |
| Line 1: |
Line 1: |
| − | =VIATRA-CEP Examples=
| + | The following demonstrations highlight the essentials of the VIATRA-CEP framework using a simple example introduced by Martin Fowler, commonly referred as the ''state machine DSL'', presented in his [http://martinfowler.com/books/dsl.html DSL book]. The sources are available from the official [http://git.eclipse.org/c/viatra/org.eclipse.viatra.examples.git VIATRA Examples repository]. To run them, the [[VIATRA/CEP#Installation|environment must be set up first]]. |
| − | The following demonstrations highlight the essentials of the VIATRA-CEP framework using a simple example introduced by Martin Fowler, commonly referred as the ''state machine DSL'', presented in his [http://martinfowler.com/books/dsl.html DSL book]. The sources are available on GitHub. | + | |
| | | | |
| − | ==Example #1: Simple event processing==
| + | *[[VIATRA/CEP/Examples/SimpleEventProcessing|Simple event processing]] |
| − | We are about to design a security system which controls secret compartments in a real estate. The system is rather old-school. For example, one would open a drawer first then turn on the light and knock on the wall twice to open a compartment. For that purpose, sensors are installed on the significant points of the real estate which emit events if something interesting happens; and a central controller deals with the events. The essentials of complex event modeling and processing are obvious even in this plain simple example:
| + | *[[VIATRA/CEP/Examples/ModelEvents|Processing model events]] |
| − | *we would like to depict the interesting happenings as atomic events (e.g. a knocking on the wall) and | + | *[[VIATRA/CEP/Examples/EcoreIntegration|Processing Ecore notifications]] |
| − | *complex events (e.g. a series of events which would open a secret compartment), then
| + | |
| − | *define actions to be executed based on identified complex event patterns (e.g. to open a secret compartment), and finally,
| + | |
| − | *employ some sort of a central reasoning system to process atomic events and identify complex event patterns.
| + | |
| − | | + | |
| − | ===Modeling atomic events===
| + | |
| − | We follow the conventions of the original example, i.e. identify atomic events using four-character IDs. We have different sensors on stock: a door sensor (DO), a drawer sensor (DW), a light swich sensor (LI) and a wall sensor (WL). The door is either in a closed (''DOCL'') or open (''DOOP'') state. On every state change, an event is triggered with the given four-character ID. The same applies for the drawer (''DWOP'', ''DWCL''). Similarly, the light can be turned on (''LION'') or off (''LIOF''). Finally, every knock on the wall triggers a separate event (''WLKC''). The outlined events will serve as the '''atomic events''' in our example.
| + | |
| − | | + | |
| − | Let's define the above atomic events using '''VEPL''', i.e. the '''VIATRA-CEP Event Processing Language'''.
| + | |
| − | | + | |
| − | '''AtomicEvent''' DOCL(){}
| + | |
| − | '''AtomicEvent''' DOOP(){}
| + | |
| − | '''AtomicEvent''' DWCL(){}
| + | |
| − | '''AtomicEvent''' DWOP(){}
| + | |
| − | '''AtomicEvent''' LIOP(){}
| + | |
| − | '''AtomicEvent''' LIOF(){}
| + | |
| − | '''AtomicEvent''' WLKC(){}
| + | |
| − | | + | |
| − | The complete source is available --here--. (For the sake of simplicity, the events do not feature parameters, nor any special features, hence the empty parentheses and braces.)
| + | |
| − | | + | |
| − | ===Modeling complex event patterns===
| + | |
| − | Setting up the security system is a twofold task: (i) we have to deploy the mentioned sensors, and (ii) we have to configure them. The latter on means that we have to define the '''complex event patterns''' to depict the "security codes" of the customer; and we also have to define the '''actions''' triggered when these complex event patterns are identified.
| + | |
| − | | + | |
| − | Let's say, the first secret compartment will open (SC1O) when the following sequence of events is observed: the door opens, the lights go on and the drawer is opened. Using VEPL, this complex event looks like this:
| + | |
| − | '''ComplexEvent''' SC1O(){
| + | |
| − | '''definition''': DOOP '''->''' LION '''->''' DWOP
| + | |
| − | }
| + | |
| − | The pattern begins with the keyword ''ComplexEvent'', then a unique name follows. Again, the parentheses are empty because we do not use parameters in our patterns. To see a parameterized example, jump to (--link--). The ''definition'' features a very straightforward operator, the ''followed by'' operator, denoted by an arrow (''->''). The complex event will be observed if all the required atomic events occur in this order.
| + | |
| − | | + | |
| − | We want to allow the second compartment to be opened by two knocks on the wall:
| + | |
| − | '''ComplexEvent''' SC2O(){
| + | |
| − | '''definition''': WLKC'''{2}'''
| + | |
| − | }
| + | |
| − | Here, the ''{2}'' after the atomic event denotes its required multiplicity. It would be equivalent to write it in this form:
| + | |
| − | '''ComplexEvent''' SC2O(){
| + | |
| − | '''definition''': WLKC '''->''' WLKC
| + | |
| − | }
| + | |
| − | | + | |
| − | Finally, let's say the third secret compartment can be opened in two ways. One either has to turn the light on and subsequently off within a second, ''or'' has to open and then subsequently close the drawer twice within two seconds.
| + | |
| − | ComplexEvent SC3O(){
| + | |
| − | '''definition''': ((LION '''->''' LIOF)'''[1000]''' '''OR''' (DWOP '''->''' DWCL)'''{2}[2000]''')
| + | |
| − | }
| + | |
| − | The definition is actually a combination of two complex event patterns, connected with an or-clause (''OR''). The first part (on the left side of the ''OR'' operator) defines the case when the light is turned on and off again within a second. Timing criteria can be defined between brackets: the number will define an ''upper'' limit for the pattern it follows to appear within. Timing and multiplicity criteria can be combined, as the second part of the definition shows it.
| + | |
| − | | + | |
| − | ===Actions===
| + | |
| − | To actually open the secret compartments when the appropriate complex events are observed, we define '''actions''' in which we activate an appropriate actuator. The logic of the actuator is pretty simple, we only have to invoke its ''openCompartment'' method with the appropriate compartment number, then we will see a message about the appropriate compartment being opened:
| + | |
| − | | + | |
| − | '''public class''' CompartmentActuator {
| + | |
| − | '''public static void''' openCompartment('''int''' compartmentNumber) {
| + | |
| − | System.out.println(String.''format''("Opening compartment #%d.", compartmentNumber));
| + | |
| − | }
| + | |
| − | }
| + | |
| − | | + | |
| − | The actual method invocation is placed into an block called ''rule'':
| + | |
| − | | + | |
| − | '''Rule''' openSC1{
| + | |
| − | '''events''': SC1O
| + | |
| − | '''action'''{
| + | |
| − | CompartmentActuator::openCompartment(1)
| + | |
| − | }
| + | |
| − | }
| + | |
| − | | + | |
| − | In the above rule, we invoke the actuator with the compartment number "1", since the action will be triggered by the complex event SC1O, which describes the required pattern to open compartment #1. The action block is defined using Xbase syntax. [ref?] The other two rules look pretty similar, only the required event and the parameter of the actuator is changed.
| + | |
| − | | + | |
| − | ==Example #2: Reasoning over non-materialized models==
| + | |
| − | One of the great features of VIATRA-CEP is the tight integration with EMF-IncQuery, an incremental query engine for EMF models, which enables defining event patterns essentially describing elementary or compound changes in EMF models.
| + | |
The following demonstrations highlight the essentials of the VIATRA-CEP framework using a simple example introduced by Martin Fowler, commonly referred as the state machine DSL, presented in his DSL book. The sources are available from the official VIATRA Examples repository. To run them, the environment must be set up first.
