The EPTS Languages Working Group did a nice presentation on their work at the DEBS09 conference earlier this year, and it will be interesting to see how things have progressed at EPTS5 in a few weeks.
Meanwhile, here is an attempt at classifying the original models and languages defined by the working group at DEBS, based on the original presentation’s classification of event processing languages into “inference rules”, “ECA rules”, “agent oriented”, “SQL extensions”, “state oriented” and “imperative script based”. (As commented at the time, many or all of these could be used to describe some of the CEP tools on the market today).
Note that:
- (Explicit) state models effectively map onto ECA rules representing state transtitions… with state just being an entity attribute.
- ECA rules are just a special type of production rule…
- … which can also be defined as inference rules representing more knowledge-rich processes.
- Of course, the normal rule hierarchy is that inference rules and ECA rules are both “types of” production rules.
- Custom imperative code or scripts can be viewed just as explicit coded algorithms (in any language), or as a type of production rule (where they are following a condition-action model): such imperative or sequential rule execution modes are provided by the main commercial rule engines today.
- Decision models here refers to things like decision tables and trees, which typically map onto production rules or some custom algorithm.
- For “agent model” I’ve assumed the “distributed agent” model or architecture, although in an EPTS perspective the term “agent” seems to be the much more generic (and therefore, by definition, non-differentiating) “entity that processes event objects”.
Incidentally, mapping this hierarchy to an example like TIBCO BusinessEvents really requires some further annotation: for example, many of the transforms are hidden from view (you cannot edit the state model representation as just a list of ECA rules, for example, only the model’s state transition rules). Nonethless, it can help to understand that these transformations exist.
In some ways this analysis just validates the EPTS Languages Working Group work: there are multiple models and language types, and they are often related. Possibly the next task will be to relate these languages and models to different event processing pattern types, and hence lead to best practices for selecting models and constructs per problem domain. Equally, there are possibly more language classifications likely to be defined.
