« Don't Shoehorn Event Processing into SOA | Main | Sentient CEP and the Rights of Algorithms »

Thursday, March 08, 2007

On CEP and Standardization

Posted by Progress Apama

Last week Anita Howard wrote an article about the adoption of event processing in capital markets.  The first part was great - she reports that event processing is being broadly adopted in the capital markets (and other markets as well).  She also suggests that SQL is an approach to addressing the complex event processing (CEP) technology issue.  But then the article implied, via quotes from StreamBase, that SQL is the "only candidate" for a standard event processing language and that SQL is "widely used," and there was follow up in the blog from StreamBase marketing people that there was "broad support" for SQL as a standard for event processing.  Although it's accurate to say that a SQL based approach is a viable, and in some ways effective, approach to CEP, there are lots of other language-based approaches that are, arguably,  more effective, and, arguably, more "widely used." I'm waiting for the next claim that SQL has been adopted for CEP on Jupiter, indicating that SQL is, indeed, an intergalactic standard. 

But the real issue I have is that StreamBase continues to polarize the industry and provoke CEP-by-SQL religious language wars.  Naturally software vendors will emphasize that their approach is better than the next guy's, but tactics that divide early stage technology markets are not healthy and should be stopped immediately.

Research in CEP began simultaneously in the mid 1990's at Stanford University (David Luckham), Cal Tech (Mani Chandy), and Cambridge University (John Bates).  This work, and subsequent commercial work, has resulted in a range of language approaches to CEP, including:

  • Graphical point-and-click environments
  • CEP rules
  • CEP languages (e.g., David's RAPIDE, and Apama's EPL)
  • Java
  • SQL-like syntax

Vendors, of course, are a proxy for customer demand and preference, and so far, there is no "intergalactic CEP standard." Progress Apama supports graphical tools, CEP rules, a CEP language, and Java; I believe Aptsoft has visual tools;  I believe TIBCO BusinessEvents is Java based, and has graphical tools; I believe Kaskad has a language based approach; and I believe Aptsoft has a visual environment.  In other words, these vendors, and by proxy their customers, represent that there is strong support for visual, Java, rules, and language-based approaches to CEP.

At Apama, we will continue to avoid polarizing discussions about standards, and participate in the nascent standards discussions that are inclusive of all approaches.  We'll also continue to advocate other important issues like customer use cases, the business value of those use cases, architectural discussion about the relationship between EDA and SOA, continued work on the event processing glossary, and more.

Constructive discourse that unites, not divides, will help the tide rise for event processing, and lift all boats along with it - customers, vendors, and more.

TrackBack

TrackBack URL for this entry:
https://www.typepad.com/services/trackback/6a00d83452154069e200d834ea413253ef

Listed below are links to weblogs that reference On CEP and Standardization:

Comments

Colin Clark

Mark,

Excellent post. (I can see Mark's eye's roll as he slowly realizes that I am agreeing with him on something...)

I have commented upon Streambase's tactics before in that something is not even close to being a standard until you can buy a book on it. But that still doesn't make it a standard.

Without diving into the standard of SQL (which is not implemented the same way by the 3 major players anyway), I am going to support Mark's point in a different way.

Organizations adopt technology because they want to get something done. Either its a new thing they are doing or the pain of an existing application is bad enough to make them want to switch to something else. So, most of the companies that I deal with have this rule - 10x performance increase and no more than 2x increase in difficulty. That means that better, bigger, faster is mandatory. It also means that the implementation and support requirements have to warrant the gains provided by the result.

It has been shown that license costs in a project are typically no more than 10% of the project's total cost. The rest is organizational.

Now, the software that Kaskad sells (and others in this space as well) does something for our clients that they couldn't do before. So that nails the better, bigger, faster part.

The question then, at the end of the day, is whether or not SQL *based* languages for CEP provide any benefit over other approaches, i.e., development, testing, support, etc. I think the jury is still out on that. (If I lost you on this one, refer to pain above - does SQL based CEP lessen the pain?)

To quote Mark, "A rising tide lifts all boats." It would be interesting to see Streambase acknowledge this - to date, they have published nothing with hard, quantitative facts, that says their approach to implementation is any better than the rest of us.

Progress Apama

No eye rolling here. I have great admiration for the way Kaskad is going about things - a focus on customers, the evidence of which is your recent announcement and endorsement by the Boston Stock Exchange:

http://apama.typepad.com/my_weblog/2007/02/kascad_goes_liv.html

Credible customer success says it all. Your use case, and your publication of it, will help educate the market, and promote the rising event processing tide. Well done!

The comments to this entry are closed.

<-- end entry-individual -->