The RAPIDE Event Pattern Language
Designing event pattern languages
The Rapide event pattern language (Rapide-EPL)
Classes of events
Pattern matchingthe fundamental operation in CEP
Single event patterns
Complex event patterns
Repetitive and recursive event patterns
Event pattern macros
Building libraries of patterns
So far we have explored the concepts of CEP using a simple event pattern language, STRAW-EPL. We chose the tabular format because it lays out all the elements of an event pattern in a way similar to a graphical user interface. STRAW-EPL is fine for explaining easy examples. But when we deal with how to build real applications of CEP, we need a more powerful event pattern language.
In this chapter, we describe in some detail the features of a particular event pattern language that formed the basis for early research into CEP.
This is the Rapide-EPL for specifying patterns of events in causal event executions (posets). The Rapide-EPL contains a core of features that are needed to support CEP. We use it extensively in later chapters to illustrate example applications of CEP because it is a more powerful and succinct notation than the tabular format of STRAW-EPL. As the complexity of CEP applications develops over time, we expect that EPLs will include many more features.
8.1 Event Pattern LanguagesBasic Requirements
First, we discuss some general requirements that an event pattern language should meet in order to adequately support CEP.
An event pattern language is a computer language in which we can precisely describe patterns of events. It is similar to mathematical language for logical expressions or a Web search language with more than the usual options and some other bells and whistles. It lets us describe, without any ambiguity, exactly the patterns in which we are interested.
A pattern matcher for an EPL is a program that processes one or more event executions in real time and picks out all, and only, posets that match a pattern.
An EPL must have the following properties.
Power of expression: It must be powerful enough to specify the kinds of complex patterns that are needed in order to apply CEP to the problems described in Chapters 1 through 4. To do this, it must provide relational operators corresponding to relationships between events (for example, "and," "or," "causes," and "is independent of"), temporal operators (for example, "during," "at," "within") that refer to time bounds and time intervals, and ways to refer to data inside events and to context.
Notational simplicity: It must let us write patterns easily and succinctly. The tabular format of our STRAW-EPL is too lengthy and restrictive for "heavy-duty" use. Some powerful pattern language constructs would be difficult to express in tabular format.
Precise semantics: It must have a mathematically precise concept of match so that when we specify a pattern, we know the posets of events that can match it.
Scalable pattern matching: It must have an efficient pattern matcher that can scale to matching large numbers of patterns over high volumes of events in real time. This issue will inevitably influence language design.
When it comes to designing EPLs, we have a "tension" between our requirements: simplicity, ease of use, and efficiency of pattern matching versus power of expression.
There is a fact-of-life reason for this. If an EPL is simple and easy to use, we won't be able to specify some kinds of complex patterns in it. On the other hand, if it is powerful and lets us specify complex patterns, it will contain "advanced" features or options that take time to learn how to use. And pattern matching for complex patterns is computationally demanding and difficult to implement efficiently.