… with the announcement that Oracle is now shipping, in Oracle 11g, an enhanced notification mechanism for its continuous query support. This has potential to replace the tedious notions of database triggers and polling mechanisms with a “registered query” that could invoke a Java stored procedure. Through this it can propagate the “data update event” beyond the database and into the event processing world. Thanks to Oracle’s EPTS contributor Dieter Gawlick for this tip at last week’s DEBS09.

Note that Oracle databases are often used as the “backing store” for TIBCO BusinessEvents‘ distributed event store, from which one can run TIBCO Spotfire analytics etc. For some customers (i.e. those without low latency requirements), this backing store can also be used directly as the event store…

The next DEBS “tutorial” was effectively the EPTS Language Analysis group report. As a vendor not involved in this group I wondered if it would miss something that is covered (or planned) in TIBCO BusinessEvents. But instead this proved a well executed and informative session by 3 presenters covering stream processing, rules, agents, semantics, IDEs and formal theory.

A few comments from a TIBCO perspective on the content. Firstly, there was a summary slide showing all the different language approaches by vendor and research event processing systems including TIBCO (BusinessEvents). Now, guess which of the following BusinessEvents was aligned to: “Inference Rules”, “ECA rules”, “Agent oriented”, “SQL Extension”, “State Oriented” or “Imperative/script based”? Well, the first was correct, but you could also make a case for all of these being supported (events driving production rules, multiple-agents, continuous query language, state models, and what we call rule functions).

On the differences between ECA rules and production rules: event-driven inference rule engines combine the features of both Rete-based inference rules AND Event Condition Action rules. If no event is defined then the rule acts as a normal production rule; if (one or more) events are part of the rule definintion then the event(s) must occur for the rule to fire. And its not as if the rule firing order of ECA rules is standardized…

On the IDEs for event processing languages: of course many might complain that rule languages don’t have the draw-your-application simplicity of the stream-processing-via-queries community. This is because production rules used in inference engines are “declarative” - they can be defined in any order: and you can’t (or shouldn’t) draw lines between declarative rules (although creating such a diagram from the current rule definitions would work!). Instead, conventional production rule systems are often supported by a (process) diagram called a ruleflow; on the other hand, BusinessEvents supports a drag-and-drop state model diagram tool.

Overall an excellent and informative session - sorry, tutorial!

… with the announcements and discussions of Microsoft’s SQLServer-or-.NET-library-no-one -seems-quite-sure-yet stream processing tooling, and then IBM’s you-can’t-have-too-many-CEP-tools System S announcement. Looks like IBM has donated this software to some good causes as part of its beta program - good on IBM - although presumably future users will be expected to pay for the technology.

These arrivals mean that, finally, all the Big 3 (Oracle, IBM, Microsoft) have now declared some interest in query-based stream processing. Possibly this will increase interest (from a somewhat low base) for standardising SQL extensions (syntax and semantics) for continuous queries (as also provided for in TIBCO BusinessEvents 3.0 and later). We’ll see…