Last week saw 2 questions come up regarding the relationship between Complex Event Processing tools and object oriented databases or OODBs. First, while at OMG’s Technical Meeting, we were asked about TIBCO’s interest in the OMG ODMG RFP to plan a successor to ODMG3.0. Then came a question from ODBMS.ORG asked the community about common design patterns for ODBMS installations. So it is probably time to explore the how an advanced event processing platform like TIBCO BusinessEvents relates to an ODBMS.

Firstly, what is an ODBMS? The ODBMS.ORG definition says “[per] Malcolm Atkinson and others …  An object-oriented database system must satisfy two criteria: it should be a DBMS, and it should be an object-oriented system, i.e., to the extent possible, it should be consistent with the current crop of object-oriented programming languages.

• The first criterion translates into five features: persistence, secondary storage management, concurrency, recovery and an ad hoc query facility.
  
• The second one translates into eight features: complex objects, object identity, encapsulation, types or classes, inheritance, overriding combined with late binding, extensibility and computational completeness.”

TIBCO BusinessEvents (BE) includes what can be thought of as a “distributed grid-based real-time obect database” for storing events (and event objects) for use across multiple Event Processing Agents during complex event processing.

The RDBMS-style criteria compare well to BE as follows:

• BE persists the event and data objects.
• BE has a secondary back-up option to a conventional RDBMS.
• Provides concurrency through supporting multiple Event Processing Agents (indeed, it is based on cache technology usually used to share information across applications in real-time).
• Supports fault tolerence / recovery features (through redundancy in its cache nodes).
• Although the objects are used to feed the Event Processing Agents, you can run ad hoc continuous (or static) queries in consoles against BE.

However, BusinessEvents has a mixed score on the object criteria:

• Complex objects (and events) and identity (unique names for instances): in BE’s case the “classes” are called Concepts, and can be defined in terms of properties and (reference and inclusion) associations. Different types (and concept/class associations) are supported, per UML Class.
• For encapsulation, BE encapsulates information, but not behaviors. BE uses UML State, production rules and queries against the objects; state models are defined per Concept / class, but rules and queries are not encapsulated… arguably you cannot encapsulate rules inside the objects they refer to, as rules will generally work against multiple objects. At best, the encapsulation is at the Event Processing Agent level.
• Both Concepts and Events support single inheritance, like Java. State models are also inherited.
• Overriding is not really supported (as BE does not support methods, let alone overridable methods).  Nor is late binding, except note that when transforming an “event” into an “event object”, your rules specify what object or objects to create or enrich…
• For extensibility and completeness, the BE event processing language can be extended as required, and should be considered complete…

Some of the other BE OODB characteristics are:

• BE has 2 options for controlling object persistence:
  • automatic persistence and update, for default persistence, and
  • explicit persistence via controlling functions, for fine-tuned control.
• An OQL-based query language, extended for continuous monitoring of data / event updates (sliding time-based windows etc).
• No direct API for 3rd party applications to do CRUD operations on BE’s OODB contents. Although this could be done…
• The main processing type carried out on the OODB data is via the inference rules engine, not queries embedded in some process - although the query language can be used to provide supporting set-based facts for the rules’ operation. Indeed, BE’s queries are not used for “insert” or “update” type operations - those are done by rule actions.
• No batch-type “report generators” – BE’s OODB is used to serve the Event Processing Agents which in turn can provide event-based “reports” (as event payloads), as BAM-style notifications.

At best, TIBCO BusinessEvents, as a general purpose event processing platform with object persistence, can be described as providing an “embedded OODB” rather than being a “general purpose OODBMS”. In other words, it provides not a “general purpose object persistence server”, but instead an “object and event persistence service, supporting event processing”. Subtle, but maybe significant.

Last week’s OMG standards meeting included an interesting presentation by John Hall of Model Systems (and SSADM fame) on the role of (business) events in linking business (policy-type) rules to business processes. John normally deals with business modeling artifacts like OMG BMM and OMG SBVR, so it was interesting to see how this community sees “business events” as being the key glue between “business rules” and “business processes” - something that Ron Ross has also been advocating [*1].

Now, neither BMM nor SBVR are particularly “event-aware” standards, and the goal for SBVR pundits is to exploit such business rules to determine the content of (and ensure enforcement within) business processes (as defined in models like BPMN). John’s presentation was basically how “events” linked policy-type business rules to business processes (in BPMN). Interestingly John proposed analyzing the available terms and facts for appropriate events (as in “new”, “update”, “delete” etc) through a cross-reference table. Compared to event processing IT systems:

• the observable business events tend to be what is already on the event bus, and are very much a subset of all possible CRUD operations on all available business concepts
• complex events often align to interesting “business facts”, and CEP is about determining, from some prior sequence of other events, when these business events occur (or will occur).

Hopefully this will be the start of business modelling of abstract events to help join the business rule documenters with the business rule automators - and its my opinion that event-driven rule-based systems are probably going to prove the easiest to join this gap.

Notes:

[1] This is an interesting Lithuanian paper that looks at rules in UML from both an SBVR and IT perspective. Note the mention of state models, production rules and events - which should be familiar to any user of TIBCO BusinessEvents (although as existing COTS prior art this didn’t warrant a reference in the paper).

I see from Tim Bass’ blog that Brian Husted of Pyxis has published a paper titled “Event Driven Grid Computing“. This is regarding a US DOD SOA application that exploited “CEP to enable scalability for SOA“, handling tasks like intelligent routing, governance, monitoring and complex workflows.

Brian comes across as pretty enthusiastic about the use of the TIBCO BusinessEvents event processing platform, for example commenting “… a small number of people (2 or 3) can turn out big things with BE”. Hopefully he’ll find time in the near future to write about some of his other BusinessEvents applications.

Notes: See also this past post on the topic of CEP, EDA and SOA.

Bruce Silver has blogged on BPMN 2.0’s current status, and of interest to the CEP community are the new event handling features:

1. “Non-interrupting events”: events can occur that are handled in a process without derailing it. Of course this is standard behavior in a CEP tool: events can be processed independently and later combined with other event processing…
2. “Escalation events”: events generated internally by the process. Again, standard fare in CEP tools. Bruce on comments the power of this for ad hoc and semi-structured behaviors, and indeed some CEP use cases are for just monitoring BPM / SOA systems, intepreting all types of generated events…
3. “Event subprocesses”: event handlers for events. Again, standard fare for CEP to do some processing to any event, in parallel with other event processing.

From these it seems that BPM is taking a step towards more sophisticated event handling, or at least a step up from “basic” event handling. Of course, complex event processing additionally involves continuous event processing, whereas BPM usually involves human interactions and workflow control / management, so there continues to be differentiators.

Bruce makes an interesting comment on business rules too: that “routing logic in process gateways” are not “business rules”. That doesn’t really make sense: for sure some gateways will be process-housekeeping decisions of little interest to the business user, but others will surely embed business-critical decisions. On the other hand, it has long been acknowledged that a best practice for BPM is to delegate such business decisions to a managed decision service - hence the explicit new business rule (aka decision) task in BPMN 2.0. And,in the CEP world, for tools like TIBCO BusinessEvents to invoke a decision managed by its Decision Manager tool.

I resisted the temptation to title this blog “Choosing between CEP, SOA and BPM“, even though those acronyms effectively describe where these products are targeted. And it is not such a silly question: I recently listened in on a conversation regarding “when to choose” TIBCO BusinessEvents (the distributed event processing platform - hereafter BE), in lieu of TIBCO ActiveMatrix BusinessWorks (the service integration tool - hereafter BW), or TIBCO iProcess (the BPM tool - hereafter …  iProcess). Clearly all 3 of these tools can process “events” of one type or another, and exist to automate business processes…

Here is 1 attempt at a comparison:

For automated processes and event-based services, one typically uses BW for services integration (or service-oriented systems) and BE for “more complex” scenarios. Typically BW provides links to multiple existing systems via pre-built adapters, whereas BE provides the stateful “complex event” view of the world. Both BE and BW can act as containers for application components, including each other, at runtime. Both can manipulate XML. Often they are used together when we use:

• BE as the container, delegating to BW for interfaces to existing systems / extracting data as required for event processing
• BW as the container, delegating to BE as an embedded rule engine for complex decisions in service integration applications

The main characteristic to be aware of in these tools is that BE is primarily rule-based (using an embedded rule engine), whereas BW and iProcess are orchestration / flow engines. In BE we can use a state diagram to indicate a sequence of states which may define what process / rules apply, but this is really just another way of specifying a particular type of rules (i.e. state transition rules).

The main advantages to specifying behavior as declarative rules are:

1. Handling complex, event-driven behavior and choreography
2. Iterative development, rule-by-rule

The main advantages of flow diagrams and BPMN-type models are:

1. Ease of understanding (especially for simpler process routes)
2.  Process paths are pre-determined and therefore deemed guaranteeable.

In combination these tools provide many of the IT capabilities required in an organization. For example, a business automation task uses BW to consolidate information from multiple existing sources, with human business processes for tasks such as process exceptions managed by iProcess. BE is used to consolidate (complex) events from systems to provide business information, or feed into or drive both BW and iProcess, and also monitors end-to-end system and case performance.

[On a side note, the tool or technology is of course only part of the solution - the application of that tool or technology by appropriate specialists is also key.]