This year DEBS is in Europe, and in Kings College Cambridge, England - surely a model for the Harry Potter Hogwarts School of Architecture, with a quite amazing internal maze of staircases that entirely obviates any need for an on-site gym, while maybe requiring some kind of RFID-enabled roomkeys so event organisors can detect and rescue guests from obscure parts of the college.

Fellow Event Processing Technical Society colleagues Adrian Paschke (Freie Universitat Berlin) and Catherine Moxey (IBM CICS) and I presented a tutorial on the EPTS Event Processing Reference Architecture journey and development, with additional contributions from Alex Alves (Oracle) and Themis Palanos (University of Trento), on Monday this week. The presentation is now posted up on Slideshare (see below or here, or if in a Flash-free environment, check out the PDF).

One of the interesting audience questions was, if I recall correctly, why the EPTS Reference Architecture team did not differentiate their architecture more from that of, say, the BPM community? This was a little surprising as nowhere had we mentioned the words “business process” or “process orchestration”; neither had these really come up in the Reference Architecture discussions (other than as consumers of events). However, we did refer to the Fast Flower Delivery use case discussed in Opher Etzion and Peter Niblett’s forthcoming book on Event Processing, and Opher assured the audience that the event-driven processes therein were valid event processing requirements as opposed to BPM. An interesting point of reference here was the TIBCO user presentation at TUCON earlier this year that also found out the difference in BPM and CEP for their particular problem.

A related comment - from an end-user organisation - was that the sales teams of companies selling CEP solutions were often too quick to offer their BPM offerings rather than their CEP solutions. For an end-user to complain to vendors that “you are trying to sell me the wrong stuff” is pretty interesting! Wonder which vendors they were?

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:

1. (Explicit) state models effectively map onto ECA rules representing state transtitions… with state just being an entity attribute.
2. ECA rules are just a special type of production rule…
3. … which can also be defined as inference rules representing more knowledge-rich processes.
4. Of course,  the normal rule hierarchy is that inference rules and ECA rules are both “types of” production rules.
5. 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.
6. Decision models here refers to things like decision tables and trees, which typically map onto production rules or some custom algorithm.
7. 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.