Flexible Event I/O - For Simple Integration

The ruleCore CEP Server provides connectivity using a powerful and easy-to-use Event I/O front-end module.

The Event I/O module provides a large number of pluggable event transport protocols enabling streams of real-time events into the ruleCore CEP Server.

The Event I/O module is based on the popular open source Mule ESB. A number of important enhancements for event processing are added to the standard Mule ESB by the ruleCore CEP Server:

• Security
• Traffic logging
• Database-driven configuration
• Event re-sequencing
• Error management

The Event I/O module is an important foundation for enabling the creation of distributed architectures with the ruleCore CEP Server. The Event I/O module connects to back-end rule evaluation engines which can be distributed among multiple servers. This allows for scalable multi-server configurations with one or several Event I/O modules serving a number of back-end engines. The Event I/O module can be easily customized and adapted for various tasks by adding new Java components into the ruleCore specific event flow implemented by the enhanced Mule ESB.

Location Aware Rules

RuleCore provides native support for defining location aware rules. Location data from GPS, AIS or other sensors can be natively processed by ruleCore.

The ruleCore rule language defines event types for sending location data into using the WGS84 standard, used by GPS and other systems.

Native support for defining geographical zones is built right into the rule language in order to make location aware rules easy to create.

Special support for is also included in the language to create virtual event streams which contain events only from specified zones. 

Detection of Non-Events

 The temporal features of ruleCore makes detection of missing events simple. For example, a common requirement is that a sequence of events must occur within a specified timeframe. Temporal operators can be used to trigger a rule when all events are not seen in time.

Driven by Business Events

The API of ruleCore is purely event driven. Creating a unified rule management model which can be controlled from any XML enabled application.

Inbound business events are received from your applications and outbound notification events are delivered back to your applications.

Rules are also created and managed by sending events containing rule declarations. The state and progress of rule evaluation is monitored using event interactions too.

The benefit of this high level approach is that any system which can generate or parse XML formatted events can easily manage rules or monitor the state of the ruleCore CEP Server. All this means that the ruleCore CEP Server is truly a critical component of an Event Driven Architecture (EDA).

Creating a new rule is simply a matter of creating an event and sending it to the ruleCore CEP Server. This allows for easy and automatic rule management where rules are created and deleted on demand.

High Level Declarative Reaction Rules

A business situation, the sequence of events that contribute to it, and how it is reported using an outbound reaction event are all described using high level declarations. This declarative approach uses standard XML for all its definitions.

A high level declarative approach avoids problems normally associated with language approaches as there is no procedural code to write, debug and maintain.

Dynamic Rule Management

Rules can be added, removed, modified and monitored in a live ruleCore CEP Server.

Commonly, rules are created, modified and deleted in the ruleCore CEP Server as a response to business activity performed in a variety of business applications.

A typical ruleCore usage scenario is to automatically manage rules without any user intervention. New rules could, for example, be created automatically as a new business process is defined to monitor various aspects of the process.

Causality Tracking

Normally, a number of events contribute to the detection of a particular situation. The contributing events and their payloads can be listed in the outbound reaction event. This trigger event is the notification provided to external systems about a detected situation, and the contributing events describe the sequence of events which lead to the detection. The last event in the sequence of contributing events has a special meaning because it is the event which actually causes the situation to be detected. The situation is said to be caused by that event.

The ruleCore CEP Server automatically keeps track of event causality and adds meta-data information to each outbound event to indicate what event caused it. As the ruleCore CEP Server is completely event driven, each event is caused by some other event. Inbound events can also carry meta-data indicating what event caused them. This information is preserved and added to in the outbound event. By following the event causality list, it is possible to easily determine the root cause of an event.

Situational Monitoring

Run-time monitoring of a live system is a critical factor in any solution in the Operational Business Intelligence space. The ruleCore CEP Server stays true to its coherent, event-driven architecture and provides an event-driven approach to monitoring.

All aspects of rule evaluation can be monitored using events. Thus, all systems which can generate and parse XML can monitor the state of the ruleCore CEP Server.

All rules, situations and actions can be listed using a monitoring query sent in as an event. The rule instance for each rule can also be listed and each rule instance can be queried in detail. This provides insight into the situation detection process. It is possible to track the situation detection as each situation develops; to provide early warnings, for example.

The live state of the ruleCore CEP Server can also be queried to find rule instances tracking a specific business entity. This allows for easy monitoring on the behavior or movement of a particular process, item or other business entity.

Semantic Event Correlation

One of the key factors to the high expressive power of the active rules in the ruleCore CEP Server is the concept of an event stream view. The event stream view creates a dynamic window into the inbound stream of events. Each rule instance has its own view providing context for the rule evaluation. The context provided by the view assures that each rule instance operates only on semantically related events—not all events in the event stream.

As an example, a rule could be interested only in events from a specific business entity, like a customer, vehicle, order, or a complete business transaction. The view groups together relevant events which provide a context for the situation detection.

A particular situation can be used in multiple rules and executed in different contexts provided by the rule's event stream view. For example, one rule could monitor excessive readings from a single RFID sensor and another rule could be used to monitor all sensors in a building for the same situation.

Situation Description

The key reactive capabilities of the active rules are provided by an extremely flexible and extensible situation detection capability. The ruleCore CEP Server provides a situation description capability with extremely high expressive power.

A description of a situation consists of a combination of event patterns as they happen over time.

A sequence of event patterns can be described in a way that closely matches the real business situation, allowing for easy mapping from the actual business problem to the ruleCore CEP Server’s definitions.

Flexible Situational Alerts

Actions are the way ruleCore CEP Server notifies your applications about a detected situation. The actions provide a very flexible way to create reaction events based on the sequence of events which led to the detection of the situation.

The reaction event contains a summary or contents of the actual event instances which contributed to the detection of a particular situation. The contents of the reaction event are created by executing an XSLT transformation. Thus, very powerful and complex summaries can be created to describe the detected situation.

Supports Long Lived Situations

A situation can consist of a long sequence of events which must be tracked for long periods before the situation is fully detected.

The state of tracking long-lived situations is automatically kept persistent, and automatic recovery procedures restore the state of all rule instances and their situation detectors in case of sudden server reboots or crashes.

The automatic crash recovery procedures protect the integrity of long-lived rule instances and ensure that all events and rule instances are automatically restored to the same state as before the crash without any user intervention.