Thursday, January 10, 2008

On the classification of events


I am returning to the area of "classification of events", although it has been discussed in this blog several times regarding certain aspects, the reason is - some discussion in which I realized that the confusion is still alive and kicking.
Events can be classified according to their structure, semantics, or pragmatics. This classification is orthogonal.
Based on Structure:
  • Simple or atomic event - an event that reports on a single occurrence.

The event structure may be flat (like relational database), or semi-structured (XML) - which also can express non-flat structure (e.g. hierarchical). In some cases events are represented as objects. Typically events contain "header" - information about this event (event class, time stamp, source...), and "payload" - the content of the event.

  • Complex event - an event that is composed of multiple events

There is some difference between this and the term "composite event" from active databases which mixes structure and semantic aspect, but I don't see it useful to use this term any more.

Based on source

  • Raw event: Event that has been reported to the event processing system by an external event producer.

Note that a raw event can be simple or complex. The term "raw" is relative, since it can be result of some computation process in the event producer that is transparent to the event processing system.

  • Derived event: Event that is created by the event processing system as a result of some processing.

Again, the derived event can be simple/atomic - where the attributes are computed as functions of raw and derived events, or complex - in which the derived event is a concatenation of events.

Based on ontology:

  • Real event: An event that designates something that occurs in reality
  • Virtual event: Hypothetical, simulated or uncertain event.

Again, this is a separate dimension - can be in any structure and by any source.

Based on pragmatics

  • Reactionable event (AKA situation): An event that is consumed by an external consumer at the end of the event processing network (either notify or orchestrate).

We used the term "situation" for a phenomenon in the consumer's domain of discourse that the consumer wishes to react to. This can be raw event (and in this case the event processing system is reduced to "simple event processing" - i.e. filtering and routing) or derived event, it can also be real or virtual, and in any structure.

BTW - ECA - "Event-Condition-Action" rules are rules in which the events are situations, and they are executed within the consumer domain, but I'll continue to discuss the conceptual model in the next posting.

4 comments:

Marco Seiriƶ said...

Do we need to consider the source of an event? To me, it confuses things. At least at a conceptual level.

Could we not treat an event in the same manner independently of it's origin?

I would like to process events in the same manner if they were generated internally or sent to us by an external source. If the event content is the same, should I care where is comes from?

I never got the hang of the raw/derived distinction. Well, I understand what is meant by it but I still have not found a good use for it. Maybe there's a good use-case showing the need for that which I missed totally?

Come to think of it. Do we need complex events? Can't we just have events? A complex event could be an event with a payload which consists of a number of events? Or is this too restrictive?

I like simple things so I would love to have a model with just one type of events and that's it. But perhaps there's too many limitations introduced this way?

Opher Etzion said...

Hi Marco. For processing purposes there is no real difference between all of these events - the classification between raw and derived event start to be of interest when we need to trace back decisions/actions and find the lineage of an event. Anyway, the purpose has not been to argue for usability of any of them - but to take existing terms and show how they relate (or does not relate) since people tend to mix things - e.g. derived event and complex event are sometimes bein confused, raw event and simple event are sometimes being confused, virtual event and derived event are confused etc...

cheers,

Opher

Brian Connell said...

Fascinating discussion. Lots to agree and disagree with here. For example, do we need to distinguish "real" and "virtual" events? All events are equal...

Also, you said
"(and in this case the event processing system is reduced to "simple event processing" - i.e. filtering and routing)"

Is this true? How are you defining "simple event processing"? I sometimes refer to "single event processing" when an event can be processed in isolation (no references to other events made during the processing - e.g. check if a value in an event is within a range, etc). Is this different?

Brian said...

Fascinating discussion. Lots to agree and disagree with here. For example, do we need to distinguish "real" and "virtual" events? All events are equal...

Also, you said
"(and in this case the event processing system is reduced to "simple event processing" - i.e. filtering and routing)"

Is this true? How are you defining "simple event processing"? I sometimes refer to "single event processing" when an event can be processed in isolation (no references to other events made during the processing - e.g. check if a value in an event is within a range, etc). Is this different?