We are often talking about the fact that event processing is done within a context, but what about event-driven rules in real life (not in computerized systems)?
Earlier this week there was an incident that the engine of one of the cars in the parking lot of our lab was on fire (I did not take a picture of that incident, the picture you see above is just a car on fire I found in the Web).
There was an announcement to all employees to move the cars from a certain potion of the parking lot.
The rule that local administration has is: When a fire event occurs, shut down all elevators.
However the one who composed the rule forgot to put it in context and say: when a fire event occurs in the building, shut down all elevators, and the rule has been activated. The result was counter-productive, since people ran in the stairs (we have an 8 story building).
More context-sensitive rule would be helpful.
During the next few weeks I am planned to attend two conferences in the USA, DEBS'11 and AAAI'11, in both of them I am delivering tutorials (each with another colleague). The DEBS tutorial is about non functional properties of event processing, and it is now in advanced phases of preparation.
Non functional is a strange name, since typically name refer to positive aspects and not to negative aspects (starting with "non"). The slide below sows the agenda, the two large topic we'll discuss are the "performance and scalability" and "usability". The other topics are discussed more in brief.
I think that systematic treatment in these aspects are both interesting and important -- for example, we found out that in the two major performance criteria - throughput and latency, different people mean different things and measure different things. I'll dedicate some posts in this Blog on the insights we collected during preparation of this tutorial, on these and other aspects. After the DEBS conference I'll post the full tutorial slides on slideshare, as done in the past.
I got a request today to share the slides that I am using for the event processing course at the Technion, based on the EPIA book, in order to use it for an event processing academic course. At this point I will share it in a controlled way for those who wish to use it to give a course, if you are interested to give a course based on this book, please let me know and I'll give you access to the course's site.
Continuing the series of posts about temporal windows:
Like the clock going backwards in this picture, one type of window is a window that is opened backwards. The idea is that when event occurs, open a window backwards, to start either in some time offset, or by an occurrence of a specified event. This is another type of window that is supported by some models, and emulated by using queries to databases that store past events in most models.
An example is that an event processing system detects, using some pattern detection, that a person is a suspect in money laundering, but substantiate the suspect is done by looking for another pattern on past event history. This is known as "reinforcement" pattern use.
The main difference between forward and backwards windows, is that in regular forward windows, events are being kept in the internal state only if they are required by some EPA which lives within this window, thus the events that should be kept in the system's state are well defined.
In the backwards window case, since the window is not open when the event occur, then it should still be kept, thus we need to know of all possible backwards windows that might access this event in order to determine if an event should be kept, or just keep all possible events (which in the most flexible case, since it allow unrestricted addition of backwards windows, but may not be practical, as we may not know that an event even exists until some EPA that consumes it within a backwards window is defined.
This posting concludes the series of postings on temporal windows - for now.
This illustration (as indicated in the bottom) is taken from the "enterprise irregulars" site, posted by Ray Wang.
Ray Wang cites a relatively old posting of mine, talking about real-time, right-time and other time related concepts. I admit that sometimes I abuse the term real-time (like other people do, but this is not a good excuse!), but I have not adopted the term "right-time". In that posting I bring some classical definitions of various types of real-time. Wang is making a somewhat different classification as a matrix with two axes: the reactive/proactive axis, and the business value axis (low/high). The high value proactive is called "anticipation", and the low value of proactive is called "nice things to do". My interpretation is that both deal with notifications that may allow proactive behavior, but not necessarily automated proactive behavior of the type that we talk about (see my keynote talk last year in the OMG conference), on the reactive front, the high value are mission critical reactions. and the low business value are called "timeless responses". Here, I am not sure it is the best title, as there are reactions that have low value, but are time dependent, since they lose their relevance in time. Example here is that getting an alert on available discounts in a nearby store may not be that important for me, but the discount is applicable only within the next hour, so if I would like to respond, there is time bound on this response. Anyway - interesting classification.
Carole-Ann Matignon recent Blog posting was entitled: "Plato or Aristotle", the two great Greek philosophers, that were once labeled as those in which the entire western culture is a footnote to their writings. In this context, I guess that Carole-Ann meant the major difference in their outlook of life. Plato saw the individual as part of a society, while his student Aristotle, saw the society as a collection of individuals. The difference is -- who is in the middle: the society or the individual. Carole-Ann's posting was in the issue of privacy, or data accumulated on people, which in some cases it is good for the society in general, a government agency, an ability to get credit decisions and more, but can harm the individual's interest. This is an issue that is also dominant in dilemmas about event processing for years, the relatively ease in obtaining information about events, in a world full of sensors and cameras, and the privacy considerations.
Security and privacy in event processing is one of the topics we'll discuss in the DEBS tutorial about non-functional properties of event processing in DEBS'11. Stay tuned for me.
I came across an interesting posting by Matthias Kaiserwerth, the director of the IBM Zurich Research Lab, entitled "who do you work for?". In this posting Matthias raises the dilemma, that it is much easier to identify with a smaller organization, sometimes until the level of a single project or department, rather than to identify with a big corporate, or any division of it.
I certainly agree, in the past, the department I managed had a logo, and I found that people identified much easier with this department, relative to the lab, division, or IBM. While this had a great contribution to the people's motivation and "unit pride", it was not popular in the environment (which I never thought it is a strong consideration). Creating excellence requires to have identification with a goal, it is much easier to identified with goals that one feels partner in, and not of some abstract entities.
