Complex Event Processing involves 2 basic concepts: dealing with events, and processing them. Simple! And typically / traditionally, this is achieved in IT departments by designing and coding event consumers with dedicated processing code per some specification / requirement.
In the brave new world of model-driven development, though, we need to define CEP solutions at a more abstract, and hopefully standards-rich, level. Defining events and processing at the model level rather than implementation level makes them easier to understand, easier to reuse, and easier to change. For example, the information represented in events can be defined in UML(TM) diagrams. However, there is no “good” standard construct for defining the “processing” part in event processing. In the OMG(TM) Model Driven Architecture(TM) world, UML models have relationships and constraints defined through OCL (Object Constraint Language) and behaviors through Action Semantics – neither of which are particularly well known or common in usage. Why is this? Simply put, if I am defining a behavior for a class, I may as well use my final implementation language rather than bothering to learn some intermediate model-level language and relying on some, hopefully efficient, transformation to my implementation language of choice.
Better still, one could use a declarative language to define behaviors. Declarative means I don’t need to worry about ordering, and is an ideal abstraction for modeling. The behaviors I need for CEP are of the type “when this state or situation is true, do this” where “this” can be some event data combination, event creation etc. This is precisely the idea of, and what constitutes, a Production Rule, usually thought of as an “if..then..” construct and well understood by any IT developer or even Excel macro writer. At runtime, the production rules can be executed in a consistent and standardized way by some “rule engine”. In TIBCO BusinessEvents, for example, we use a modern compiled varient of the Rete algorithm for class-leading performance.
There is one small problem with production rules: all the implementation languages are proprietary. TIBCO’s BusinessEvents’ rules are as close to Java as possible, but Java is still a “platform specific” language. Hence TIBCO’s support of the ongoing OMG work on the Production Rule Representation – hopefully to be realized soon as a UML-level PR language. We’ll be reporting on progress here as this develops…
