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!

This week OMG’s Technical Meeting has had most buzz around the BPMN 2.0 submission (and congratulations to that team, for which TIBCO is a supporter). Some of the other stuff going on includes:

• PRR or Production Rules Representation (which, for complex event processing like in TIBCO BusinessEvents, can include event-condition-action rules using standard forward-chaining semantics) starts the Revision Task Force process for PRR1.1. A few tweaks are due, but more interesting was to see 2 more vendors attend the PRR session this week. Also, note that UML tool NoMagic is presenting on PRR at ORF’09 later in the year…
• DMN or Decision Model and Notation started on its first stage of development, which is the identification of use cases and roles for defining UML-based decisions for a future RFP. We had some good discussions (which I’ll report in a future post once I have reported to the DMN community), and it is clear that this could be a very key standard for business modelers, end-users and tool vendors. Of course the relevance of this to event processing is that many CEP/EP systems’ role is to support decisions…

A somewhat hotter debate continues (/is) regarding the proposed Case Management RFP, which was developed from a Dynamic Business Activity Modeling RFI last year (which TIBCO responded to, and was also covered by our session at the recent Semantic BPM day in Berlin). Many BPM applications are also case management applications, but some case management requires more sophisticated event-handling, rule-driven processes, decision management, and case record management and recording (technologies that TIBCO mostly covers under BPM+). One school of thought is that the more sophisticated requirements for case management need to be rolled into the common BPM standards stack (including BPMN); another is that multiple different standards should be used flor flexibility (such as combining BPMN with BMM, PRR and DMN). From an event processing perspective, of course, case management (by one definition at least!) involves applying incoming events to the state of some case in order to determine whether processes need to be started, continued, halted or changed - in other words CEP technology can often be applied for case management areas in government, finance, healthcare, etc.

Some of the other case management discussions can be found from EBizQ, Bruce Silver, and Derek Miers.