Modelling Situations for Event Processing
CEP, in a nutshell, is about the real-time detection of business opportunities and threats in cyberspace. Business opportunities and threats are often referred to as situations, so we can simply say that CEP is about the real-time situation detection.
We represent situations in the domain of event processing by building and refining models of situations. This means that one way to develop CEP applications or designing CEP architectures is to define situations of interest and build models that define the situation.
After we have a working model of the situation we will generally have a hierarchical model of the situation composed of various components of the situation. For purposes of discussion I refer to this as situation modelling.
If a situation is modelled with 15 components then we need to detect these components of the situation. In addition, it is generally not good enough to simply detect each one of these components of the situation. We also have to hold the state of each one of the situational components.
However, it is not good enough to simply observe the state of 15 components of a situation in the detection process; we also need to observe the relationship between the components.
So, let’s say the situation we are looking for is “commercial air plane collision” and we are building a model of this situation. To keep the model simple we will limit the model to airplanes and omit objects like birds, buildings; but we will include wind, air speed, and direction.
Our situational model consists of primary objects, in this case an airplane. Now we need a simple model of an airplane, which is modelled, in this overly simple example, as span, velocity, acceleration, altitude, orientation and relative wind speed and direction. Generally, an object-oriented approach to model building is preferred so we can reuse the model and overload, morph, inherit and encapsulate as necessary.
One example would be when our boss comes to us and says, great job on the airplane collision model, but I also want to know how much jet fuel is on the planes at the moment of our projected situation, so we can estimate the intensity of the explosion. So we need another model and our earlier very simple airplane model would inherit the jet fuel tank model our boss requires.
I hope from this simple example of model building that you will conclude that modelling is one of the most important aspects of CEP. Without good models, situation detection impossible, and CEP engines are useless. Situation modelling is critical to CEP.
So, if a CEP vendor comes to you and says they have a very powerful CEP engine, ask them to show you a complex model of a situation that is important to you and explain to you how they represent the object. If models are not represented using an object-oriented approach, I recommend you send the vendor back to their software development lab, because without an OO approach to modelling, you can only represent very simple situations.
Furthermore, let’s say you are leading a team building a large model. If there are several teams working on various parts of the model, you need a common framework to integrate the work of the various teams. I strongly recommend an OO approach to your model building systems architecture and work breakdown structure.
In a future post, I will write about the companion to modelling – simulation
2 Comments
One Trackback
-
[...] Modelling Situations for Event Processing [...]
Changhai Ke says:
Tuesday, July 15, 2008 at 6:52pm
Tim,
I would like to comment several points in this post.
I don’t know whether you said that a CEP application must necessarily have a model. It may have, or it may not. A rule-based approach (in its general acceptation) is not considered as a model. In the AI terminology, rules are considered as “shallow knowledge”, while models are considered as “deep knowledge”. Shallow knowledge expresses the people’s experience, links symptoms to causes directly, while deep knowledge establishes the links using a model, and the model can be interpreted. Shallow knowledge is very helpful in many cases, and as deep knowledge it also allows detecting situations. Of course, the cooperation of both is desirable to build more powerful systems. I did a rapid search, and below are 3 entries for reference:
o Shallow knowledge: http://decisionautomation.com/glossary/12.php
o Deep Knowledge: http://decisionautomation.com/glossary/13.php
o General explanation: http://decisionautomation.com/
If you build models, are they necessarily object-oriented? Certainly most of the programming languages are OO, so OO models fit well. But there are also functional languages, actor languages, etc. It’s too narrowed to be limited to OO modeling and bundled to its limited tools. As an example, a DFA (Deterministic Finite Automata), often used in grammars is completely detached from any notion of object.
Finally, the “real-time” term needs some clarification. If you are trying to detect a security fraud situation over months, the CEP still applies. The system may conclude to the fraudulent situation at some day and some hour, or maybe a few hours later, or even a few days later. Over a long period, one hour is not a matter, the important thing is to discover the fraud. Here, the real-time rather means business time. The analysis can be done every night in batch, when machine resource is available and the transaction state is stable (is this still CEP or something else?). This is different from the “hard real-time” when dealing with sensors, stock trades, etc, where by the design itself, you want the application to react in seconds or fraction of seconds.
Sincerely,
Changhai Ke
Hari Kishan says:
Tuesday, July 29, 2008 at 4:50am
Hi Tim,
I must apprecieate your thoughts here, I fully agree here with CEP as a usage for real-time situation detection. This is the biggest differentiator between CEP and other technologies such as event stream processing and rules engine. Only CEP enables us to build the platform to modelling situations and not ESP or rules engine.
Regards,
Hari