An old Jewish folk story is about husband and wife who came to a Jewish Rabbi for marriage counseling, the Rabbi listened to the husband and said: you are right, then listened to the wife and said again: you are right. After they left his assistant asked him: "Rabbi - why did you say to both of them that they were right, it is not possible that both of them are right", and the Rabbi answered again - "you are also right". I recalled this story after reading Mark Palmer's Blog entitled: "how broad is the appeal of CEP". The story starts with the CEO of SAS claiming that CEP has limited appeal continuing with the rebuttal of Progress and TIBCO, saying that the SAS guy underestimates the potential and there are many applications in multiple industries. Mark Palmer has a counter-opinion saying that relative to BI, EP is still small, but has a potential to grow, and it is hot within a single industry - capital markets, with relatively modest interest in other industries - Chad Gadya!
So why does it remind me the Rabbi's story? -- since each of them is right in something.
EP is indeed a smaller market relative to BI, and much younger and less mature. Some of the BI people regard EP as a "non issue" since one can do anything with BI tools, or database queries, and the only reason to use EP is when there are latency and throughput requirements that cannot be satisfied. However, as noted many times, the bigger appeal of EP is the abstractions that enable to develop and maintain applications of that type more easily and substantially reduce the TCO. The observation that EP market is much smaller than the BI market today is certainly true, maybe the fact that the SAS guy bothered to react on it is a sign that they start feel some presence in their territory. BTW -- I don't view BI and EP as competitive technologies, each of them are destined to do different things, some applications need both.
Next -- inside the EP house, it seems that there is some agreement, about the potentially bright future, and some disagreement about the present and even more about the scope. I guess that appeal is in the eyes of the beholder, but let me make one observation: when Streambase is looking at the universe it looks at the market for a stand-alone event processing product; when some of the bigger companies look at the universe, they look at event processing capabilities as part of a larger enterprise computing infrastructure. When we did, a few years ago, the business evaluation work for IBM, towards the decision to enter this market, we have identified both of them as opportunities, the stand-alone one has its own existence, but is more limited in scope, for the "embedded" one -- possibilities are much higher, but more work is needed to make event processing capabilities as part of facets of enterprise computing infrastructure -- decision support platforms, business process management platforms, messaging oriented middleware, sensors and actuators frameworks and even business analytics framework. These two view points of the universe provide different perspectives to the beholders, and so each of them is right from his own perspective. More - later.
In 1998 I have edited a book of articles about temporal databases (together with Sushil Jajodia, and Sury Sripada), this followed a Dagstuhl seminar we held in 1997 about temporal databases, an area that was hot at that time in the research community, and somewhat cooled off. Today a Master student I supervised took her final exam on "final work" (which is less than a thesis, a track that require to take more credit work), and did an implementation of a temporal database model from a paper in this book that was co-authored by Arie Segev, Avi Gal and myself. This is somewhat more expressive model than the TSQL based models, and had its own interesting featured like: ability to freeze and unfreeze data, ability to distinguish between modification and revision, ability to deal with simultaneous value. In fact some of these ideas found themselves into our work on event processing (e.g. policies when there are repeating events that may match the same pattern).
Temporal databases as an area started in the Israeli army. Kobi Ben-Zvi who went from the Israeli army to do PhD in UCLA has invented the area, by formalizing the terms, and there has been a lot of work later in the research communities in the 1990-ies. There was even big fight about how to extend the SQL standard to support temporal databases between two parties, I don't really remember the details, in the book you can find the position of the two sides of this battle, as the Dagstuhl seminar was one of the battle fields. The end result is that it never became part of the SQL standard, partly because of the fights, and more importantly since at that time the DBMS vendors have higher priorities on their mind -- e.g. Web related stuff, XML data etc.. There are some features, but it did not get fully into the mainstream of databases, although there are quite a few of specialized implementations. One of the future directions of event processing will involve getting back to temporal databases as an infrastructure, which is the area of retrospective event processing, I'll write more about it in the future.
