This is a picture of the Bahai Gardens, one of the famous sites in my home-city Haifa, the Bahai religion is an interesting one, more modern than most religions (I myself am agnostic and do not practice any religion, so this is not meant to be an endorsement), the Bahai people see Haifa as one of their holy sites and invest a lot in the city, this week they have a major celebration. I have returned to Haifa after my short trip abroad, in which I have given four times the same talk about "event processing - the next generation" (I'll post in on the web soon). One of the discussion points have been what can the event processing discipline (complex or not) learn from other disciplines that succeeded. Coming from a database background, it is always interesting to me to make a comparison there. When relational databases started to become products in the early 1980-ies, I have been a database practitioner with experience in several DBMS products, and in the beginning I looked at the relational model without much respect, it seemed to me to be over-simplification that gives up semantics and creates a lot of anomalies. However, the simplicity has been the main benefit. The relational model has won, and also created a big research community around it that concentrated forces around a single model and developed query optimizations, more semantic abstractions on top of it and some other stuff. The fact that there has been a substantial brain power dedicated towards a single direction was a contribution to success. The fact that was not a critical mass of work around object-based databases contributed to the fact that its success has been modest. What can we learn from that in the "event processing" discipline ? We need to strive to find the formal model that will be the basis for concentrating the community around. The model is not extension to the relational model, since this extension will loose the main benefit of the relational model -- simplicity. There are several relational algebras around, but all of them do not meet the simplicity criterion, on the contrary -- they are quite complex. So it is still a major challenge for the community. More on that and possible directions -- in subsequent postings.
This are pictures from Aston University in Birmingham which I am visiting today within my short trip, it turns out that from the university network I cannot get into the IBM VPN, so my hosts brought one of the university IT guys who confirmed that they are blocking access to private VPNs, as a matter of security policy, and the only person who knows how to configure a bypass is away today, and even if he has not been away, he doubts if he would have willing to do it, I could in principle go to town an look for an Internet Cafe, but I am too lazy, and can live a couple of days without Emails. Besides that the visit (which has not been over yet) has been interesting and we may have grounds for collaboration . I have given my talk about "event processing - the next generation" third time this week (fourth time tomorrow in another place...), I'll post it on the web after my trip. One of the question I was asked was whether (complex?) event processing techniques could have predicted the economic crisis, but I'll leave discussion about predictions to another Blog posting. They also may teach an event processing course next year and are looking for a textbook to base the course upon.
Speaking of book -- the publisher of the "Event Processing in Action" book has gone another step and included the EPIA book (currently the first two chapter drafts) in the MEAP (Manning Early Access Program), the referenced site explains how readers can become part of the authoring process by receiving draft of new chapters, and making comments/questions to the authors using the forum to ask questions and communicate with the authors. As mentioned before the introduction chapter has been posted as a green paper, and is free download to all. Although open type of writing is somewhat more difficult and time-consuming to the authors then just write the book without interruptions, I believe that this process can improve the quality of the book beyond the formal review process. So this is a call for the community to take advantage of this program and help in creating this book. Hans Gilde has already made the first set of comments for Chapter one.
I am not sure whether it is related to blogging about the book being written, but yesterday (Tuesday the 24th of March, 2009) has been a record high in terms of amount of visitors for this Blog in a single day, today has not ended it, and is also looks strong, so I wonder why.
Tomorrow -- visiting the IBM Hursley Lab in UK, before returning home.
Today I am in Birmingham, England. Yesterday I have visited Cambridge University for a few hours and gave a presentation about "event processing - the next generation", second time out of the four times I am going to give this presentation in various places this week. Cambridge has a relatively large research group called Opera, directed by Jean Bacon and Ken Moody, which deals with event-based middleware (among other things). Jean is also the "grandmother" of Apama, since John Bates has been her Ph.D. student. Apama still maintains a site in Cambridge, and some of the Apama guys came to hear my talk. While there were some periods that I did other things and had looser connections with the research community, I have returned last year to a scientist position, and am trying to keep closer contact with the research community, by visits, collaboration, and helping in the organization of DEBS as the flagship research conference in the event-based computing area. Later today I'll be visiting Aston University here in Birmingham, where my good friend, colleague, and mentor, Robert Berry, has taken recently a position of Dean of the School of Engineering and Applied Sciences which I'll meet later today.
BTW -- for some reason I cannot get to the IBM VPN from here, probably something in security setting of the local Internet server, so anybody that contacted me by Email may have to wait until later this week.
Just a short note from Orly Airport, waiting for my flight to London this morning.
The publisher has just put the draft of chapter 1 of the EPIA book on the web as a "green paper", anybody can download it free of charge. Next thing --- establishing of a MEAP (Manning Early Access Program) in which readers are able to impact the writing process (I'll let you know when available). Enjoy.
Paris. I have arrived a few hours ago to Paris, and I went for a walk in the streets to stretch my legs after the flight, my hotel is not far from the Bastille, so I went there and watched the monument that you can see in the picture and the people who watch it.. Now, returned to my hotel to check Email and rest, before my hosts are coming to take me to dinner.
Today's topic is a short reply to some discussion that actually event processing should be done as part of DBMS, this is not a new claim, it is repeating from time to time by one database person or the other; in my past I have dealt with active databases that has attempted to put some form of event processing functionality as part of a DBMS engine, overall this approach has not lead to a big traction on the DBMS products. The main idea has been to add some language constructs in form of ECA rules (that also support composite events) to DBMS engines. The only traction on products from this works is the notion of "trigger" that does not really to justice to what the active database community has tried to do...
Anyway, twenty years have passed and the event processing thinking has been evolved from the early thinking on active databases. As said the main issue here is not performance, as some of the vendors claims, but TCO. Many of what is called "complex event processing applications" deal with the detection of patterns over multiple event instances and types, SQL may not be a natural language to express such patterns, in some cases due to its set-oriented thinking and some other limitations. In fact, in some cases customer reported that they could save 75% of the cost of development time by using language that can express patterns more naturally. This difference may not be materialized in languages that are by themselves variations or extensions of SQL, but this is only part of the EP universe.
Of course, the DBMS community can return to the idea of active databases and add language constructs to express patterns in the DBMS engine, and I guess that this may be a valid variation of event processing, but it will not naturally blend into SQL, it will have to be an hybrid language. More about this - later.
