Another type of proactive systems

Today I had a meeting with PhD student and her adviser to help them do sanity checks for a research idea related to event processing.    One of the ideas coming from them is actually looking at another type of proactive systems relative to what we have been looking at.   The difference stems from the fact that event producer can be of two types:  observer and creator.   An observer, e.g. sensor, observes that an event has happened and reports it, but it does not take any part in the event creation.   A creator is a producer that creates the event, and can decide whether an event is created, or in some cases can retract events.  Such a creator can be an instrumented program, BPM,  transaction system etc...

The proactive systems we have been looking at assumed that the producer is observer, thus we cannot control the creation of events but we can try to predict it, and eliminate it, or mitigate the damage it might inflict.   

Contrary, when the event producer is a creator, we can control the event.   There might be a few cases here.

One case can be that we again predict that event is going to happen since there is some causality relations with events that have already been detected, and within a certain context we don't want this event to happen,  we can then tell the producer -- if this event is being produced (again, within certain context, e.g. time window) -- don't produce the event.    Another case can be that the event is being created by a transaction system,  this event, within some context, and maybe in conjunction with other events, derives a situation that we want to eliminate.  The fact that the event is part of transaction that has not committed, gives the possibility to retract the event and eliminate it from being produced to the outside world when the transaction commits.  

The pure view of event processing puts producers and consumers outside the boundaries of the event processing system,  however, in reality there are cases where either the producers or the consumers (maybe even both) are controlled by the same logic, and thus detection of situation may impact the producers and consumers.   I think it gives rise to interesting applications.  I'll get back to this topic later.

DEBS 2012 - on Dave Maier's keynote, frames, and fragmantation

I have arrived home 49 hours later than planned,  in Sunday early morning instead of Friday early morning, due to a malfunction of the aircraft which required to replace a part, and a combination of the fact the the airline ELAL, does not fly in Saturday, thus, although the aircraft has been fixed in Friday, it was too late to take-off,  and the German liking to paperwork and red tape, which inflicted a long process of releasing this part from the German custom on Friday, and also delayed the takeoff on Saturday night -- since half of the passengers dropped out and found alternative ways to fly,  the aircraft was half empty, and the crew let people occupy the business class,  however, it turns out that the German authorities inspected the aircraft and found out that the number of people in the business class does not match the flight authorization request and wanted that the paperwork will be done again,  so after some minutes of trying to convince them. the crew asked all passengers moved to the business class to return to their seats until after the takeoff.  We in Israel has the completely opposite mentality, we are good in improvising, and find that doing things by the book is boring.  I must also say that ELAL treated us much better than a similar case I had in Delta Airlines,  which caused me not to fly Delta. 

Anyway -- back to DEBS 2012.  The organizers quickly assembled all presentations, and they can be found on the conference's website.   There are also pictures from the conference posted on Facebook, you can read through the presentations and find anything you are interested at.

I'll concentrate in the keynote of the third day - Dave Maier.  Dave is a senior figure in the database community, and got involved in recent years also in data streams research, he is also involved in related work with Microsoft.    

Dave gave an interesting talk whose title was:  "capturing episodes - may the frame be with you".  The rationale is that the notion of window in stream processing is too limited and the event stream is partitioned according to slices of times or event count,  but in different cases there is a need to slice the event stream differently,  such as: as long as an episode holds.    

While the notion of frame is indeed a useful abstraction if we take the pure data stream management primitives as given,  it seems that the fragmentation that exists due to people's starting point, results in duplicating work within different sub-communities, without being aware of work in other sub-communities.  More specifically, I think that the notion of frame has strong  relation to the notion of context that we have introduced, furthermore, I have written before that the notion of context also makes  the concept of punctuation redundant., The notion of punctuation also  came from Dave Maier (with his student Peter Tucker).

I am going to get deeper into Dave's paper and make more thorough comments on the relationship between "context" and "frame"  (and can add "fluent" in event calculus as a third term for comparison).  I also sent Dave some material on context (following a corridor chat), and he mentioned it during his talk. 

One of the good things that the relational model brought to the database community, was that it was accepted as a starting point (years before the standard approved),  and then let the research community focus on doing absolute new work, instead of relative new work,  which was one of the reasons to the big influence of the research community on reality in the database area.    We should strive to do the same in the event processing domain -- more later.