In a previous post we commented on IBM’s Conceptual Model for Event Processing Systems, but failed to observe that IBM’s rule engine group, Ilog, was noticably absent from its contributor list. So perhaps it was both fortuitous and timely that Ilog’s Daniel Selman recently added another “viewpoint” on the position of event processing (aka the rules viewpoint).

Daniel’s take on the “primary users (sic) of rules technology” are the (use cases for) automating decisions, event responses, processes and inferences. I think these might be better classified by renaming then as decision processing, event processing, and business process processing. But inferencing, which Daniel notes as being a technology to support Artificial Intelligence, is not so much a (user or) use case, but a means of providing knowledge-based reasoning to support any of decisions, processes, etc - “AI” is not (or should not be) a means unto itself.

Standard Event Processing Design Pattern

Indeed, one could probably argue that:

• all business processes are driven by events of some kind, and involve decisions and (re)actions;
• all processes, decisions and event processing are context (i.e. state) driven; however, some processes and algorithms are used in a subordinate fashion to a stateful process (consider a typical decision service that is subordinate to its application server and database layers);
• inferencing can be used to enhance any part of the event-handling process as a form of declarative rule control.

In TIBCO’s experience, an event driven rule engine (like TIBCO BusinessEvents) can be used to provide dynamic business processes, event-driven decisions, and real-time control mechanisms - and often all 3 - exploiting and building on the fundamentals of complex event processing.

So, on the utility of rule engines, we totally agree with Daniel!

Jacob Feldman from 4C presented to OMG this week on the need for standardization in the Constraint Programming (CP) community. Although you can (and often do) represent business contraints in business rules and CEP systems (for example, you can argue that any rule condition is a constraint, or a value range in a decision table is a constraint), CP usually uses special techniques to solve complex business optimization problems that require juggling / relaxing these constraints to find an optimal or near-optimal “solution”. Examples might be aircraft load planning, bus schedules, and delivery vehicle routing. CP solutions to these problems also intersect with the CEP space, as plans are disrupted by events (such as an aircraft flight diversion due to turbulence, an event requiring more bus capacity, and a delivery vehicle breakdown). Sometimes such constraint systems are implemented using production rules, too.

With respect to rule model standards, OMG PRR has defined a baseline “rule behavior” definition, and OMG UML already has object constraints in OCL. It will be interesting to see if standardizing the metamodel for CP problems and engines will exploit or work with these, and how future CP systems will be used with CEP systems.

… was the catchy snappy hip punchy title of our contribution to this year’s BPM(I) (aka OMG) Think Tank 2008’s RoundTable sessions. These are used to get feedback from end-users, consultants and indeed other vendors on a variety of issues - which in this case was the role of Complex Event Processing and business events in BPM (aka BPMN models).

For a warm-up, Jim Sinur (Gartner) gave a keynote covering “The Economics of Business Process”, explaining that businesses should expect to invest in BPM in a down-economy as they have even more to gain than in an up-economy. More to the point, he expanded on the need to augment conventional BPM with things like decision management, rule-driven processes, complex event processing, and maybe even “scenario management” (which could mean any of case management, case-based reasoning, or test case generation - it wasn’t clear). In particular Jim mentioned:

• the role of complex events combined with AI techniques to improve decisions
• rules will need to “surround” process, not just be invoked from decision tasks

Jim was a good segue into the CEP-BPMS roundtable, whose participants included a large insurance company, a DOD supplier, a government agency, the co-creator of the BPMN modeling standard, and some curious fellow (BPM and EA) vendors.

Firstly, and not surprisingly, none of the participants disputed the value of CEP to business processes.  There were a few different areas of CEP-BPM focus that were discussed:

• CEP providing a generic business-logic container for cross-process / cross-BPMS / cross-abstraction-level, system+process monitoring (a bit like TIBCO SPM provides, but more general)
• CEP was another reason for standardizing the enterprise view of events and event patterns alongside processes - as BPMN events provide a very process / task-oriented view of an event, which may have a totally different meaning in some other process (see also the OMG EMP effort for event metamodels, which hopefully EPTS will have an input to)
• Agility was provided by the CEP elements (like state models, declarative inference rules) being “easier to maintain” than (some) large process flows, as well as the fact that event-driven decisions are more useful in real-time scenarios where high responsiveness is required
• The use of rules, queries, states, alongside or augmenting process flows overlaps with “knowledge representation / management” (which is an interesting thought)
• CEP also had a BAM-type role to play in business process control and oversight: one participant used the terms “issue prevention, detection and correction”, which is a neat description.

The slides for the session (roundtable intro and feedback) are available in the file BPMI_EPandPRoundtableResults1008.pdf .

An interesting post on Tim Bass’ CEP blog [*1] describing Blackboard Systems, which is an established term from the era of AI research for “distributed knowledge systems” that co-operatively solve problems. Tim and I have previously mentioned blackboards and blackboard systems in the context of Complex Event Processing (CEP), but the passage of time has meant that “blackboard” is more significant for implying “distributed shared memory” [*2] in a CEP context, rather than just co-operating threads or agents looking at a shared database or memory structure [*3]. Distributed memory is a requirement we see for scalable, high-throughput event processing beyond what you can fit into a single machine’s (or JVM’s) memory space.

A general progression for “CEP system complexity” on how the system handles memory is:

• in-memory only, with persistence for reliability / restore operations
  = small, fast, independent CEP or Event Stream Processing (ESP) applications
• single-machine, multi-process (for example using multiple cores), sharing the same memory
  = small-medium, pretty fast, with a restricted number of co-operating processes
• multi-machine network of processes (exploiting control as well as data events across the network):
  • independent memory models
    = where the problem area can be partitioned without side effects: multiple parallel identical processes (for performance)
  • shared-memory models (usually using some cache technology)
    = where the problem area is large and inter-dependent, requiring inter-dependent or co-operating processes (for solution complexity) (as well as allowing for parallelism for performance).

CEP frameworks can generally support all these models (out of the box as for TIBCO BusinessEvents, or with various amounts of custom development work). Of course, the last model (multi-machine network with shared memory) is the interesting one for “Blackboard System” types of architectures (i.e. cooperative CEP agents working against a shared information model and event store, possibly under the control of a Master Control Program / Agent).

Other useful references are:

• IITB course material on Blackboard Systems
• Naval Research  sponsored paper on Blackboard Systems

One suspects the “blackboard systems” domain and terminology is overdue some updates thanks to developments in the Complex Event Processing space.

Notes:

[1] Disclaimer: Tim is an ex-colleague and runs a vendor-independent blog on aspects of CEP.

[2] Blackboard systems historically used a single memory model (i.e. multiple threads or processes using a single machine’s memory model). But the interesting aspect for CEP is not that event processing agents can create new events to be used by other CEP agents (which is pretty much de facto CEP runtime behavior), but that the memory model can exist across multiple machines (i.e. can be distributed).

[3] This old paper even suggested that blackboard systems’ reign in AI research was curtailed by rule systems’ use of independent rulesets operating on a shared working memory - i.e. standard rule engine behavior. Rule-driven CEP engines like TIBCO BusinessEvents can certainly operate this way, with “independent” declarative rulesets cooperating on a problem. This approach is more difficult if you can represent your CEP or ESP solution only as a “flow diagram”, as you are explicitly fixing (non-declaratively) the interoperation of the CEP processing elements.

Interesting to see a fascinating blog entry by Roeland Loggen on “Future Patterns of BPM Technology” which showed CEP as a solution to semi-structured processes, between Straight Through Processing for full structured processes and Agent technology and AI for unstructured processes. As it happens, I had just been discussing Agent Technology with agent-guru James Odell, who is leading the OMG standardization efforts around Agent technologies. Earlier this week, reading the description of Event Processing given by Jack Van Hoof in his SOA-EDA blog on “Event Processor Tracks State of Objects”, it had seemed like CEP could easily map to agent technologies . But would it be worthwhile?

• Agent technology handles extreme scaleability issues by going from “database” processing (single instruction, multiple data records) to “via message” processing (instruction decomposition via separate multiple agents and their intercommunication). Note that CEP usually uses a half-way approach: “in-memory and cache”.
  .
  
• Agents are characterised by being autonomous, having interactions, and being adaptive. CEP engines can be autonomous and interactive to the extent that they simply respond to multiple (complex and continuous) events; adaptiveness could be via machine-learning or more commonly via statistical functions. The main attribute of CEP engines is “memory” (of event histories) which presumably is an advantage in “intelligent” distributed agents too!
  .
  
• Agent Communication Languages often combine rules with agent control commands: indeed CEP engines could be considered (or used as) coarse-grained agents (although typically their control and behaviour are relatively fixed compared to some more dynamic agent-based approaches). One suspects that agent communication languages could easily embed the W3C Rule Interchange working group rule format.
  .
  
• One needs to be aware of the latency issues in communications between agents, especially for time-constrained problems. Agent techniques may be ideal for things like continuous scheduling where they might be controlled by a CEP engine that determines when to reschedule.
  

.
With CEP being associated with event-driven middleware, and such middleware being an integral part of agent communities, it seems there is likely to be some cross-fertilization in future between these technologies.

Further reading

Apart from Jim’s papers, it is interesting to see some real-time / event driven thoughts on agents here, and thoughts on Enterprise Agents here and here.