Complex Events are Composed of Objects Defined by States
Often you will read or hear people talking about CEP and they will define a “complex event” as an event composed of other event-objects. Caution is advised, because a complex event is more than just a simple composite or aggregation of other events.
For example, in my earlier post Modelling Situations for Event Processing, we illustrated modelling in CEP by looking at an example situation, “airplane collision”. This complex event is composed of many objects than are not event-objects. In fact, depending on how you define “event” most of the components of the complex event, “airplane collision” are not events at all, but other situations or sub-states of the objects under observation, in this case an aircraft.
For example, the direction an airplane is flying is not necessarily an “event” per se. Also, the amount of fuel on the aircraft at any given moment in time is not necessarily an “event” either. The same holds true for other components that comprise the object we are modelling. In fact, again depending on how you define “event”, most of the states of the components that are critical to processing a complex event are not events at all, they are simply object-states.
Complex events are generally composed of objects and the state of the complex event is defined by the objects in the complex event determined by the states of the components of the objects in the model.
Another way to view this key point is that CEP is characterised as predicting outcomes (states) based on the relationship between the objects in the model which are, in turn, composed of the states of various components of each of the objects.
So, in a nutshell, what is important to complex event processing is not just processing events, but processing the relative state of objects that comprise model of the complex event.
Furthermore, if you are someone who defines “event” as simply a “change of state,” stay tuned in to the blog for another discussion in a future post; because the vast amount of state changes are not events per se; they are simply changes in states which may or may not have context and meaning in complex event processing.
Having said that, a complex event can be comprised of other events, including other complex events, that is why the notion of OO modelling and programming is very important in CEP.
Filed under: CEP Terminology, CEP Tutorials, Complex Event Processing, Development and Evaluation, Event Processing, Event Processing Language, Event Processing Modelling, Event Stream Processing, Modelling and Simulation, Systems Engineering, Use Cases
Hi Tim,
What’s the relationship between situations, states and events in interactive systems? Situations are sets of states and states are sequences of events, therefore situations are sets of sequences of events (i.e. posets of events). Now, why is an state a set of events? Does this makes sense? A stateful component in an interactive system can only change its state as a reaction to something happening outside of it, let’s call this something an event, it follows that each state of the stateful component corresponds to a particular history of events. In your example, the interactive system is the airplane’s information system, the state “the direction the airplane is flying” is just a piece of state inside that system, it changes according to some external input (the automatic pilot or the manual controls) and possibly some sensors, these inputs are events, and the “direction the airplane is flying” at a given point in time is just the history of these input events, don’t get confused by the fact that the system internally abbreviates this history of events with a direction vector or something like that, that’s a convenient way to implemnt it, but, fundamentally, the direction vector is just a compact representation the history of (changing direction) events. The same can be said from the state “reamining amount of fuel”, this state updates as a reaction to the output of some sensors…
So, fundamentally, the state of an interactive system, that is the set of all states of an interactive system, is just a poset of events.
Regards,
PatternStorm
Hi Claudi,
Thanks for stopping by and commenting.
Yes, I agree completely that there are levels of abstraction/granularity issues that surface in this discussion, similiar to the level of abstract ion/granularity issue that surfaces in SOA discussions.
I do think the event-model should not require designers to force all state-transitions to be modelled as events. Events should have some significant context, in my opinion - but we will not resolve this easily.
For example, the level of fuel in a fuel tank can be modelled as event-state changes (as you mentioned), or it can simply be a property that presents the state at a point in time, a tuple.
So, I guess it depends if you are modelling the nodes (the state) or the arrows (the state transition), so to speak. In my mind, I was talking about first modelling the objects (the nodes or states as a complex event) before modelling the process of state transitions, or complex event processing.
Thanks for reminding me that I failed to mention the state-transitions! My intention of recent was to define and model the object “complex event” before “complex event” processing.
Also see:
http://www.thecepblog.com/2008/07/15/a-simple-situation-model-for-complex-events/
… where I go up in abstraction, versus down the rabbit hole.
Yours faithfully, Tim
“states are sequences of events”
I’m not sure I agree with that. My current state is that I’m sitting here in a hotel room. How is this state = to a sequence of events? It is a *consequence* of a sequence of events, for sure (airplane landed, caught a taxi, slept through alarm call, …).
Not sure I understand the statement “states are sequences of events” as a general purpose definition. When I think of states, I think of transactions or finite state machines. A system could receive a variety of messages, which produces different states. All I care about from a development perspective is “which states are important?” I don’t care what events occurred to transition from state B to state C. I may only care about a fraction of the possible states, so modeling a state problem as events feel like a “square peg round hole” problem to me.
Just because we “can” model a problem as state, it doesn’t mean we should or that is it optimal. As I learn more about CEP, I end up with more questions and find scenarios where CEP just isn’t appropriate.
What I would like to see is a more practical approach, which gives the user the option to model a problem as states or events. There’s definitely cases where a problem should be modeled as an event, so there is value in both models.
Yes, I agree Paul and Peter that Claudi’s comment “states are sequences of events” does not make a good general definition.
Events should be something “more significant” than just changes-of-state. Having said that, the problem lies in that it is the observer that deterimines significance.
For example, an atomic physicist observation vantage point is different than a fireman, who considers and reacts to events very differently.
For those with SOA expertise, the graularity and level of abstract to the question “what is a service?” is debated endlessly.
CEP/EP will experience the same never ending debates on granularity when folks try to answer “what is an event?”
What is “an event” depends on the the observer. It’s relative based on the model being constructed to address a particular problem (if you ask me).
Hi all,
please find my answers here => http://forum.complexevents.com/viewtopic.php?f=13&t=115
I have been unable (don’t know hy) to post them in this blog…
Regards,
PatternStorm
Hi Claudi!
Thanks for such a well thought our reply. I will look into why your (long) reply could not post as a comment. Maybe there is a restriction on the length. I tried to post your comments and had the same result.
I would be very pleased if you would open an account and blog here, BTW.
Yours sincerely, Tim