Saturday, October 10, 2009

What is an "Event Processing Pattern" ?

My last trip abroad was a mix of vacation and business trip (to attend the Tretno event processing symposium, and the meeting of the EASSy consortium that is writing a proposal for EU project), as such I took a piece of luggage with me, and deposit it (in Hebrew the words "to deposit" and "to abandon" are very close --: "lehafkid" vs. "lehafkir", thus I am typically saying that I have abandoned the luggage in the airline...), anyway, standing near the carousel (something I really hate to do !), I realized that I am actually doing a pattern matching. I have a mental model of my luggage in my mind (shape, color, other characteristics), and I am trying to match this mental model with the pieces of luggage flowing on the carousel. There may be more than one that fits my mental model, and sometimes I grab one, look closely, and decides that this has been a "false positive". Likewise, we are matching patterns many times in our daily life.

So - what exactly is an event processing pattern? In the EPIA book, we have dedicated a (long!) chapter to pattern matching in event processing, and started it with the following definition:

A Pattern is a function that takes a collection of input event instances and produces a matching set that consists of zero or more of those input events

This is, in essence, what we do in the luggage case, selecting one out of a set. Interesting cases are cases in which we should find events that the pattern relate to their combination (this, according to some definitions, what makes the "Complex" in the "Complex Event processing" pharas), so they need to satisfy some pattern as a collection of events, and not as individual events. An example is we wish to determine if a moving object (say: motorcycle) is moving north, by looking at the location of the motorcycle over some period of time, we can observe whether the progression of location satisfies the pattern of "moving north". I'll write more about pattern types soon.


Anonymous said...

Hello Opher,

have you been lucky and finally your pattern matching worked?

Sometimes it happens that even after waiting for several hours, the piece does not appear on the belt. For this, we need to add a temporal aspect to that pattern, which reacts on the stopping belt and not matching a piece of luggage.

If this "temporal" or "belt stop pattern" matches, we call a process of discovering the luggage with an airport employee.
This happened to me on my last trip to Brazil.

Luckily I got my stuff couple of hours later.



Opher Etzion said...

Hi Cristoph. Over the years my luggage did not arrive with me 3 times, this is a small percentage of my many travels over the years, but each single case is traumatic, that's why I prefer not to abandon my luggage to airlines, if I don't have to. From event processing perspective, the context ends when the belts stops, and if an "absence" pattern is detected at that time, then you have to go to the airline counter, start filling forms, and pray for the best... I think that the panelties to airline for not getting the luggage on time is too low, thus they don't have incentives to operate a zero defects system, or somethig close to it.



Hans said...

This definition does not have the flavor of incremental processing that I would expect. A function from a set to a subset is certainly correct in a sense, but there is an added property of "when" the matched events are delivered in and out of the function.

There is a big difference between matching your bag as it comes around the belt vs. waiting for the belt to deliver all bags for the flight, then searching out yours.

Opher Etzion said...

Hi Hans. You are right that besides the function there are also context and policies that determine various things about the semantics of the executation, but I just described the first concept... Stay tuned for more (the chapter talking about patterns is around 40 pages long).