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.  

Event processing as blasphemy

The fire in the Carmel mountain is still on  for the third day, although it is somewhat reduced due to the fire fighting aircraft from all over the world - the most notable one from Russia, but also from other countries; it is good to see that when a disaster happens, many countries in the world are getting to help, Israel has also a record of helping other countries while disaster occurs.   I guess that the fire will be overcome eventually, but this does not change the very bitter feeling that the population here has about the incompetency of the government, where a series of faults came together to bring this disaster.   For everybody who sent me worried Emails from all over the universe:  the fire did not get into the city of Haifa, so have not been in real danger, the site of IBM Haifa Research Lab, is relatively close to the fire area, as it is located on the Haifa University campus.  The campus was confiscated to be the headquarter of the fire fighting forces, so it is still blocked.   While in Haifa we were not in danger, people in some villages lost their home to the fire, and 42 people were killed when a bus was caught in the fire.   

Now for this posting's topic -- you probably wonder what's event processing has to do with blasphemy or religion at all?  I think that I have written before about all of these, but will put it within a single perspective. When I was young I had several friends who moved through the process of becoming religious (what the Christians call "borne again", Jewish people are using a different term), I watched this process with interest, and has many discussions with them (well, they tried to convince me that they saw the light and I just have to look more carefully to discover it).   One thing that I have learned about religious people is that it is useless to argue with them, since their beliefs are based on axioms, and once you identified this fact, one cannot argue over axioms, since this is the nature of an axiom.    Likewise, there are many professional religions, I have seen religious wars in other areas of computing, and this is not really a new phenomenon, just different gods.

Here are three religions for which event processing serve as blasphemy to that specific religions.

Religion one:   The data-centric religion.

The religion's belief:   the world is data centric, everything can be done within database tools. The is a small niche which requires high scalability, but it can also be dealt using database techniques,

The blasphemy:   events processing is a distinct discipline; it has some unique characteristics. 

Religion two:  The programming model religion

The religion's belief:   all functions need to be expressed using the programming languages we know and love.

The blasphemy:   event processing has various languages abstractions that are not part of the regular languages. 

Religion three:  The "true CEP" religion

The religion belief:  The term CEP was coined to cope with application of types of intrusion detection; any person who did not work directly on intrusion detection applications is not qualified as a priest for the religion, thus cannot really deal with event processing. 

The blasphemy:  Anybody using the term "CEP" for any other application type is a blasphemer, any technique that tries to address any other event processing application is simply irrelevant  (comment:  I don't really  tend to use the term CEP, but some of the vendors  indeed use it).

As said,  the prophets (and disciples) of these religions believe in them in an emotional way, and there is no use arguing with them, so the best way is just to expose the axioms they believe in and let people think whether they believe in these axioms or not.     One of the motivations of the EPTS use case survey is to find out about the  usage of event processing today;   since it is generally agreed that the event processing area barely scratched the surface of its potential, an equally important issue is to identify what are the gaps in th state of the art  that are required in order to achieve it, and this is another major activity of the community that will be discussed within the event processing manifesto and   other related activities -- more about these topics - later. 

Fire in the Carmel mountain

 The biggest fire in the history of Israel is now taking place on the Carmel Mountain, where I live.
It started in late morning, now it is evening and there are many branches of the fire. 

In the lunch break we went out for a short walk in the Haifa University campus, where our lab is located, and saw the sun looking like this - a result of  the fire. 

. 

This is another picture of the fire, taken from the Ynet site,  an Israeli Internet news site.  


The damage is huge, much of the Carmel forests have been burned, dozens of people killed, mostly those who came to evacuate other people.   Some villages and neighborhoods in nearby towns have been evacuated, and it seems that the local firefighters don't have means to control the fire, and have approached other countries for help, well - I guess the government has other priorities than to invest in firefighting equipment.    Meanwhile, where we are located it seems to be safe, but everybody is in the mercy of the wind directions...   more - later. 

More on ACM SIG

Some people who are not familiar with ACM asked me by Email (and one comment on the Blog) to elaborate on the idea of ACM SIG for event processing, what is ACM SIG, and what will be the benefits of creating one?


The main answer, IMHO, is to get recognition that "event processing" is a discipline, and to have the logistic support for publications (periodic newsletter and scientific journal) and conferences, ACM also manages the  budget for SIGs, whose income are memberships and conferences' revenues, a capability we don't have in EPTS.   Note that DEBS is already ACM conference, currently sponsored by two SIGs:  SIGSOFT (the software engineering SIG) and SIGMOD (the database SIG).  Complete list of current SIGs is on the ACM site.   This kind of recognition will help grow the research community in this area and can help in accelerating the development of this area.  The main benefit will be to the research community, whose members have initiated this idea.     


You can look at a recent proposal about establishing "social computing SIG" on the ACM site to get the flavor.

Towards an ACM SIG for Event Processing?

One of the ideas that have been discussed several times is to apply for ACM SIG (Special Interest Group) dedicated to event processing; the idea was discussed again last week in the EPTS steering committee monthly call.    The decision has been to apply to the EPTS members and the community at large and check the interest in devising this EP SIG.   This is not intended to replace EPTS but to have an established home for the research oriented activities of the communities.   In parallel to sending a call for interest expression to the EPTS members, I am also applying to the other readers of this blog;  if you wish to support this initiative, or think it is premature, or just a bad idea -- you can take the poll in the right-hand side bar of this blog.