DEBS last day and a half included talks of both the research and industry tracks on various topics. From our team - Ella Rabinovich has delivered two talks: one in the industry track summarizing the experience of Amit over the years (I have written some background for this paper recently), and the other in the research track on analyzing the behavior of event processing applications. We got a lot of interest and have follow-ups in possible research collaborations, I'll write in details about the behavior analysis work in the future.
In addition -- more keynote talks, and also a follow-up meeting to the Dagstuhl seminar.
Got back home -- travelling through London, and had some time to take a walk in Hyde Park.
DEBS 2010 has ended, it was great to meet many friends again, and now it is the time to start working on DEBS 2011.
1 comment:
I am not sure I follow. If I have data requirements for OLTP, I am going to look at a transactional database product, not build one. Same goes for event processing requirements. The question is, can system designers tease apart the event processing requirements as they do with transactional data requirements, to recognize the fit for a particular CEP product? I do not think so. CEP is not a common topic in undergraduate studies. As an undergrad (1988-1992), I took a database course, learning about relational modeling, ACID transactions, two-phased commit, etc. IN the industry, every customer I ever talked to knows of the basic functions of the database and the value of database brings to the organization. They may not be able to dissect the details and choose the proper data storage solution, but the value and the basic application was well understood. CEP has a long way to go. It starts by integrating CEP into information system curriculum at universities and by CEP vendors reaching more broadly to different problem domains. Truviso has taken the only approach they could. They moved towards a business solution rather than a pure CEP solution, thus targeting a common recognizable business problems. Many CEP vendors made their debut in the stock trading space. This got the word out, but also created a stigma of CEP as targeting these complex, high event volume type specialty environments. We have be learning with increasing momentum that CEP is term that defines a broad spectrum applications thus allowing wide spread use general 'CEP' type products. So the 'role your own' solutions will get replaced with solid enterprise products just as the billions of lines of Perl code has been replaced by ETL tools in the enterprise today.
Post a Comment