Monday, October 29, 2007

classification of event processing applications - part I

You may need a good eyesight to look at this slide, so let's skip it for now, and return to it later.
Paul Vincent, in his recent blog tells us that he is struggling with classification - and talks about "simple event simple processing" to "complex event complex processing". Well - here are some thoughts that may ease the struggle. You have noticed that Paul Vincent constantly writes about Complex Event Processing and I constantly write about Event Processing - are they synonyms and I am just omitting the C ? the answer is - no!, Complex Event Processing is a subset of Event processing, according to one of the classifications, but there are some other types of Event Processing. Back to the classification issue -- there are different dimensions by which we can classify "event processing applications" :
(1). By processing type - and CEP is part of this classification
(2). By goal - what they intend to achieve
(3). By non-functional requirements
(4). By type of events that are processed.
Maybe more classifications. So in this blog I'll concentrate in (1) - "by processing type".
The slide above is showing a relatively simple application that checks orders against supplies, in the following way:
  • Supply may arrive in multiple ways - there is an aggregation function that aggregates all events about arrival of supply.
  • When all the supply arrived it is matched against the original order - this is a "pattern matching" - in this case - sequence of two events (order, aggregated supply) with some matching condition
  • If does not match - then - there is a "non matching" event reported and then enriched from a database in more details about the order
  • The enriched event is then reported to the supplier, and some decision is being taken.
  • A decision is taken by "supplier type" - thus there is some filtering and routing based on the type.
The functions that we have here are : aggregation, enrichment, pattern detection and filtering.
They belong to three different families:
  • simple event processing: operations on events that do not change the events - just filter and route them.
  • mediated event processing: aggregation and enrichment - this is a type of processing that transform the event. In enrichment it is transformed by adding attributes taken from an external store (e.g. database), while in aggregation - multiple events create one event with (in this case - sum of products in the different supplies).
  • complex event processing -- detecting pattern - here the pattern is: order occurred and later all supplies arrive - but the quantities don't match. This is very simple pattern, but it is complex event processing, because it deals with complex events.

Some more observations:

  • The border between mediated event processing and complex event processing (which both derive new events) is that mediated event processing does not detect a pattern, and does not need to keep the raw events in a state, however, it may be statefull (aggregation is statefull, but not complex event processing - the event that is kept at the end is simple.
  • The names may not be very good - since pattern of complex event processing can be quite simple, while filter of simple event processing may be rather complex - however, the "complex" name became pervasive in the industry, and derives the others...

More about the other types of classifications - later


Anonymous said...

Hi Opher, if you happen to agree to the classification I posted in of derived, composite, abstract, aggregated and complex events that I claim logically follows from the definitions of the glossary, then an enrichment is a particular kind of derivation and since any derivation is a complex event, an enrichment is also a complex even. The same thing happens with aggregation which is defined in the glossary to be a particular kind of complex event. Moreover, the example of aggregation that you mention, if you were to follow my classification would be a derived aggregation since it does not use a predertmined set of operators to combine elements of the different suply events, but, nevertheless, according to the glossary, it is also a complex event. On the other hand, nowhere in the glossary is mentioned that pattern detection is what characterizes complex events. All in all, is it that you have progressed in your EP thinking beyond the glossary? Is it that my classification is wrong?...


Opher Etzion said...

Reading again the glossary - it seems that the definition of "complex event" indeed became somewhat more wide - and thus unfit to specify the classification according to functions that I have introduced here - since it is now functionally overloaded. The solution - use different names for this classification, I'll return to this issue in the next blog.