On ACM Distinguished Speaker Program

Today the ACM Distinguished Speaker program announced my inclusion in the list of "ACM Distinguished Speakers".   The program is described in the ACM DSP site,  while this is a big honor, especially looking at list of speakers that include some real giants,  it is not a recognition program, but a program that has a mission stated as:  The DSP is an outreach program if ACM that brings distinguished speakers from academia, industry and government to give presentations to ACM chapters, members and the greater IT community. 


The outreach mission means that by accepting the nomination to ACM Distinguished Speaker, I commit to 
travel and give talks by request of local ACM chapters worldwide, there are some ground rules that can be found on the site,  e.g. to justify international travel (fully funded by ACM) there should be an accumulated audience of 300 people, so it typically entails multiple talks during a single trip.     I am in the opinion that I should spend some of my time in sharing knowledge with the greater community, this is the reason I am teaching, providing long tutorials in various conferences, and wrote (together with Peter Niblett) the book "Event Processing in Action".    Thus, accepting this nomination is another link in the chain, and I'll try to do my best to satisfy requests, especially from places in the world which don't get a lot of talks on the event processing area.


My speaker page shows four proposed talks, three of them deal in event processing:

•  A short tutorial that serves as introduction to event processing -- summarizing the material in the EPIA book.
• A talk about the research challenges that exist and a "call for action" to the research community in a way to move the event processing area towards its next generations
• A talk about proactive computing, one of the extension directions of event processing, on which I concentrate recently.

The fourth talk is on more general theme:   Computer Science Research in Industry -- some history and different models of how it operates.


I hope that it will be both useful to the audience and fun. 

On the 4Ds -- past version and the proactive version

The climate in Israel this year is quite strange, it is December, and today I still saw people going in the street with short dress, the summer just did not go away.  However, the forecast for the next three days, starting tonight is of a major winter storm (which here means a lot of rain, not snow) and much colder weather, so getting the winter clothes ready.   


Today I've read a blog posting by Jeff Adkins,  one of the people with most practical knowledge about event processing, who relatively recently joined IBM  GBS (Global Business Services).  Jeff blogged about the 4Ds-- detect, derive, decide, do.    These four are part of smart systems that sense and respond, what is known as reactive system.  I knew that this looked familiar, so went back to my archive and found that seven years ago we  were engaged with a project called "active integration"  (the actual application was in the insurance area, but we have generalized the concept), roughly what was known by Gartner as "real-time enterprise".    Here is the original flow from that project:

  
I don't think it has been original invention, it was a variation of concepts from control theory, but it looks very similar to the 4Ds, with a more detailed granularity.


The first D: Detect spread into two phases on our model: sense and detect, where the sense dealt with instrumentation and sensing of raw events, and detect with a detection of the meaningful situations by pattern detection.


The second D: Derive is the same:  created a derived event (and sometimes also derived data) as a result of this detection


The third D:  Decide is partitioned to three phases:  Analyze - determine the possible alternatives and recommend,  Collaborate - in case of "human in the loop" within the decision, and Decide -- apply some decision procedure to select among the alternatives (simulation, analytic methods, predetermined rules).


The fourth D: Do we called "effect", since it had to effect a running system.  


The loop indicates that the after effecting the system, it feedbacks through its instrumentation mechanism and the sense phase is looking again for things that needs reaction.


I agree that the 4D is much more catchy then our more detailed drawing.


And one comment:  when we did this work, we worked on REACTIVE system - something has occurred, we detect it, and then do something to repair.   This drawing is also a good description of our current project that deal with PROACTIVE systems, but the semantics is somewhat different:  the detection is of predicted undesired states instead of situations that require reaction since something already happened.   

Some Blog statistics - December 2010

This year I have not posted the annual statistics about this Blog readership, so taking advantage of the vacation to do it, along with going to movies, musical on stage, and bowling with my daughters.   The Blog now showing on the bottom some of the most popular postings, however, it started recording only several months ago, thus the more accurate statistics are accumulated in Google  Analytics, where this blog is tracked from September 2007.   Starting with the quantities:  There are around 1800 regular readers that are reading each posting in this blog, and additional 3600 who get into the blog from time to time (once every two-three weeks),  There are also  people who entered the blog less frequently, some of them only one time, the total number of this blog visitors is around 65000 people.  The geographic distribution is also interesting, the map is mostly painted in several green variants, so what stands out are the white space, countries from which there was no reader so far.   Europe has not white spot, America has one white spot: Suriname.   Asia has three white spots:  North Korea, Turkmenistan and Tajikistan.   Africa still has only partial coverage, all countries in the north part and south part of the continent are green, but the middle is mostly white.    This may be an indication that the Internet infrastructure in these countries still needs to go some way, or that the content of my blog does not appeal to people in these countries.

As far as the  ten countries with most views, these are:  1). USA; 2). UK; 3). Germany; 4). Canada; 5). Israel; 6). India; 7). France;  8). Japan;  9). Sweden and 10). Australia.  The readers come from 178 countries.

In a city view ten cities with most views, there are: 1). London; 2). NYC; 3). Paris; 4). Karlsruhe;  5). Haifa; 6). Tokyo; 7). Singapore; 8). Bangalore; 9). Göteborg; 10). Vienna. 

About 10.5% of the page views were direct requests, around 25% results of searches, and the rest, references by various websites. 

The most popular posting, is still ,by far, the one entitled "On unicorn, professor and elephant",  which answers a claim that everything done until today in the event processing area is just a hype and worth nothing. Since the time it was written two years ago, there were many proof points the the EP area has value to customers in various industries, and the assertion that it is still an infant, and some vendors do over-hype it is also still valid. 

The second most popular posting, is the one entitled: "On simple event and simple event processing".   This is an early posting.  In the past we used a terminology of: simple event processing (filtering and routing), mediated event processing (aggregation, transformation, composition)  and complex event processing (pattern matching).  However, I stopped using these terms since it got people more confused, due to the fact that different people have different associations with the terms simple and complex, especially the ambiguousness of  complex event processing,  that is interpreted by some as (complex event) processing and by some as complex (event processing).   I also tend to use composite event instead of complex event when talking about event that is composed of events.

The third most popular posting, is the one entitled: "On Enterprise Service Bus and Event Processing"   which is also an early posting,  this also states that event processing capabilities should be part of enterprise computing infrastructure, where ESB is a natural place to be a center point for it.  Since that time EP capabilities became even more pervasive among various technologies.

Somehow related to this is the most popular among the 2010 postings entitled: "Consolidation and pure play in the EP market".  This deals with the fact that most of the EP vendors today are big software vendors that consolidated EP within their products, while there is still a niche for pure play vendors.

While, as the blog title indicates, most of the blog postings deal with event processing, there are several off-topic postings that won a lot of responses, such as the one on positive thinking, and the one in which I described things that I heard from my father about the holocaust.   My last posting on accountability belongs to this family.

This year I spent less time on blogging, so the quantity of postings is less than either 2008 or 2009,  but I intend to catch up.    

The book "Event Processing in Action" is in someway descendant on this blog,  the publishers read the blog before approaching me to write the book,  but of course, there is more emphasis on rigor and quality within the book, the blog is "quick and dirty".      

End of summary -- next posting will go back to professional stuff

On accountability

We on the Carmel ridge are still in the after-shock of the big fire,  a good article in English describing it was written by Professor Fania Oz from Haifa University.   The rain that arrived yesterday (a little bit too late) has washed away some of the smell,  but the feeling here is bitter, also due to the politicians behavior.   Even during the four days of fire fighting, the politicians became busy in sending the blames to others.   The current political culture is that nobody is accountable for anything.   Imagine that in the business world, a corporate would have suffered a major disaster, and its executives would keep blaming each other, and nobody would think he is accountable.     While I don't tend to write about politics in this Blog, I think that in general, people who takes responsibilities need to be accountable,  and when a major disaster in a corporate happens, the CEO should draw the conclusions, otherwise the board of directors spell out these conclusions. I wish this was also part of our political culture, but where is exactly the country's board of directors?  

On intention language - take one

I am in a one week vacation now (not related to the big fire in the Carmel mountain),  had some vacation days to finish before the end of the year, and thought that the week of Hannukah is a good timing.   When I lived in the USA I surprisingly found out that Hannukah became a major Jewish holiday, but this was done due to its proximity to Christmas so that the Jewish children would not be deprived of the holiday season spirit, and the gifts.   In Israel, Hannukah is a minor holiday, people are working (unless they take vacation), and it is a week vacation in schools, thus the timing of my own vacation, spending time with my daughters. 

Driving one of my daughters today got me a good example why an "intention language" is needed if we want "business users" to program event processing systems.  I have a Bluetooth support in my Toyota Verso car, and with some effort I succeeded to program my mobile phone to connect to it, so if I am getting a call while driving I don't have to touch the phone, but can answer using the car's buttons, and hear the voice on the car's radio system.   

Today,  I realized that I need to reset the phone, something was not working properly, and I closed and opened it again -- did it while parking, I am not playing with the phone while driving!   when the phone came to live again it was working properly, but did not connect to the car's Bluetooth.  I realized that the connection is event-driven, assuming that the phone is operating when one enters the car, and the car is the one who is starting, so I tried to validated this theory by turning the car's engine off, and then turning it on again, and as I assumed, this did the trick.   


What I really want to have is an intention language:  whenever the car engine and the phone are both working, the phone should be connected to the car's Bluetooth.   


The way it really works is:   When the car is starting and the phone is already working, connect it to Bluetooth.


In most cases there is no difference between the two, but in case where the car is already working, it really does not.


When writing things in event-driven way -- it sometimes difficult to capture all possible cases, so we need and intention language which should be then translated to an event-driven one.    This is not an easy task, but one of the big challenges ahead.  I wonder if there are any relevant work, not just for simple cases like this one.
More - later.