There are various types of models and languages used for event pattern detection (and subsequent actions and operations) in what we call Complex Event Processing. Popular language-types from multiple vendors are:
a. Rules: comparisons across individual events (i.e. discrete-event-centric)
b. Continuous queries: comparisons across event streams (as if they were tables) (i.e. channel-centric)
c. Temporal regular expressions: event-patterns defined explicitly as event relationships (i.e. pattern-centric)
d. Sequential: conventional programming via scripting or 3GL to orchestrate event processing operations (i.e. process-centric)
We can quite easily map some of the CEP world’s terminology to these language types. The most common subtype of CEP is no doubt Event Stream Processing, or channel-centric computing, which is ideal for when you need to operate on sets of events (such as for aggregations). This is almost always associated with continuous query systems and is traditionally associated with financial data feeds, although might also be used in detecting patterns in streams for smart grid meter feeds, web site monitoring feeds, and so on.
For discrete event types of the type you register in rule-oriented systems, an equivalent term might be Event Cloud Processing – contrasting the Cloud of business events against specific channels used in Stream Processing. Business event clouds are typically used in CEP-based business processing, event-decision-action architectures, regulatory compliance and so forth, in industries such as transport, telco, logistics, manufacturing, and government.
Event Pattern Languages and normal sequential languages are also of course very useful, with the former probably being the most unique to the CEP world and also probably the most underutilised. Typically both of these are available today as extensions to rule and query languages. The latter are also interesting. For example, consider what is most important today for business process development – the graphical BPMN model or the oft-used BPEL XML representation of processes? That’s right – when the graphical notation becomes the dominant semantic representation, the syntax-based language underlying it can be irrelevant! One wonders if this (dominance of a graphical notation) will also come to pass for event pattern specifications?
One additional point of course is that various vendor systems combine elements of all of the above types of language. For example, TIBCO BusinessEvents is primarily rule-based, but also has a sequential supporting language (used in procedural “rule functions”). There is also a continuous query language (separate from the rules syntax) and an event pattern language.
In Part 2 we shall analyse these language types in more detail.
