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…
[...] Naturally, rules are a very useful tool for CEP. But if you check something like the JDL model for the typical processes (event pre-processing, event refinement, situation refinement, impact assessment, and process refinement) that are involved in CEP, you can guess that these could also be implemented in other ways, such as hard-coded in 3GL or scripts (not very flexible), or even mapped using a neural net (such as in this example). Filed in: Complex Event Processing (CEP), Rules bookmark with del.icio.us digg this About this Blog This blog’s objective is to bring TIBCO closer to our customers, potential customers, analysts, partners, and employees. Please join the discussion and add smart comments frequently. The opinions expressed here are those of the individuals and not reviewed by anyone but the individual authors. While they are employed by TIBCO, neither TIBCO nor anybody else necessarily agrees with them. [...]