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.
