One of the neat changes announced in TIBCO BusinessEvents 4.0 was the recognition that as a declarative, distributed event processing platform covering multiple event processing use cases it provided very much a superset of functionality for many use cases. For example:

• a BPM user wanting to exploit Decision Manager may initially only be interested in the Decision Manager module and supporting rules
• a BAM project might only need Views dashboards and supporting rules
• a sense and respond application might only use state modeling (Data Modeller) with supporting rules
• a monitoring application might use Event Stream Processing and associated rules, possibly in conjunction with Data Modeling.
• etc

As a result, BE4 is structured into a core product providing the essentials like channels, events and concepts, rules and rule functions, distributed cache, monitoring and management, tester, etc, and a set of modules for specific functions and roles:

• Event Stream Processing
  = continuous queries and the event pattern matching framework
• Data Modeling
  = entity lifecycle management via state machines with direct database interaction via JDBC
• Decision Manager
  = decision tables and trees representing actionable business rules, with associated workflow management
• Views
  = real-time web-based dashboards

We will drill down into more detail on these modules in the coming weeks.

At TUCON last month we announced BusinessEvents 4.0, which went GA (General Availability) at the end of May. It is worth going into a bit more detail over what is new and how this moves the game on for complex event processing applications.

First, a few comments on the typical use cases where BusinessEvents is being applied:

1. high throughput (eXtreme Transaction Processing style) event processing distributed across multiple  systems (with the latter being a requirement for enterprise applications in any case to cover High Availability and Fault Tolerence)
2. knowledge-rich, complex, adaptive application / business logic being applied to events with low latency
3. combinations of both of the above!

So how does BE4 move the CEP game forward? Lets look at the main features:

• Product selection: a modular installer, allowing different combinations of event processing elements / languages / features / services
  allows for tuned deployments, such as web-service based decisions…
• Development and testing: new Eclipse-based IDE (BusinessEvents Studio), with productivity enhancements and things like remote debugging / stepping through distributed agents on the network
  allows for easier development of large business models and applications
• Complex event definintions: a new Pattern Matcher Framework for creating declarative complex event patterns without intermediate rules, states, timers etc
  allows for simple complex event definitions without learning a rule language, query language etc
• Integration types: new channels, for HTTP SOAP (and associated WSDL) and also TCP-IP, for new use cases involving web services and internet monitoring
  allows for new event processing types, such as internet service gateways, without resorting to TIBCO BusinessWorks interfaces
• Decision management: visual test environment in-situ with the decision table editor
  allows easier business user development of decisions based on complex events
• End-user support: graphical dashboards for end-user KPIs
  allows for graphical business user interfaces to allow interaction with the managed events
• Operations support: graphical Monitoring and Management utility for operations, and platform support for ZLinux on mainframes (!)
  allows operations staff to monitor the event processing agents and performance.

We’ll go over these and the use cases they support over the next weeks.

Whenever I meet production-rule fan (and now co-chair of OMG Production Rule Representation) James Owen, he always asks me “so what exactly is the conflict resolution strategy in the TIBCO rule engine?“. Recently, TIBCO BusinessEvents 4.0 introduced a feature to make him (and other rule programming specialists) very happy - the customisable conflict resolution mechanism!

What is that?

OK, here’s an attempt at a simple explanation. When a rules engine executes rules, it executes them against “working memory” (i.e. the available event and concept instances available in an agent). Sometimes several rules might be available to execute, and several data and event combinations in turn might be valid for each rule. Conflict resolution is the name given to the task of choosing the order for rule firing with which data - for example by assigning priorities to rules.

So what is this new rule engine capability?

The production rule metadata is now extended in TIBCO BusinessEvents to include a rank - this is a rulefunction / procedure that is executed per rule when conflict resolution is required. Of course this is entirely optional, but it does mean that advanced rule users can now specify any type of depth or breadth-first rule execution strategy…

Naturally this capability is mostly aimed at those doing very specific types of rule processing. For example, if you are looking for specific types of patterns across a large event cloud, you might want to prioritise rules using some special cost function to execute check rules and possibly avoid many other tests if a pattern is found.