Rulecore is an ongoing research project investigating the use of different technologies to create software that support active behaviour. Especially active (near real-time) detection of event patterns. The foundations for the event pattern language of ruleCore is described in [1]
The aim of the project is to transfer knowledge from the academic community into a commercial software product and services. The project contributes to some extent to academic research too.
The Rulecore project draws its ideas mainly from a number of academic research areas:
The architectural goals of the project is to investigate how a loosely coupled component can be added to existing IT infrastructure in order to provide active capabilities. The goal is to create a new type of event-driven component which can work as a components in a massively event driven architecture supporting huge number of components and high throughput event streams.
Active capabilities are defined, in the scope of the project, as:
The complex situation is defined using ideas created by research within the active database community during 90's. The research area of sensor fusion also uses the concept of situations and situational awareness. Sensor fusion is, as the name implies, sensor oriented but shares many characteristics with the more business oriented situation detection of ruleCore.
Although immediate reaction is a goal, the ruleCore implementation lacks most of the features normally found in typical real-time systems. Processing is performed on a best effort basis without any timing guarantees. The design an architecture of ruleCore makes a basic assumption that it will solve business related problems and this it was determined that hard real-time capabilities was not needed. This simplifies the design and implementation.
A design assumption is that there is a human in the loop and thus reaction times need only be short enough to be perceived immediate by a human observer. This basic assumption reduces complexity in the implementation of the evaluation engine.
Contents |
Rulecore is designed with the following typical use-cases in mind:
RuleCore creates a uniform and coherent concept for event processing by using a number of design principles:
Events are also allowed to be sent to ruleCore from multiple unsynchronized sources. It is assumed that multiple event sources exists which are under the control of different system owners. For example events from different web sites or other distributed sources.
The ruleCore project traces its roots to work done in active databases. The active database research which were initiated during the 80s and 90' were interested in adding active behavior to static data storage systems. The idea was to add functionality to react to changes in the database. For example when the value of items in stock goes below 5. Previously this had been solved by polling the database. This approach did not scale well and put a lot of stress on the database. It also could miss transient changes in the database happening between two polls.
Initial research for ruleCore started in 2001 as a tool to extend EAI (Enterprise Application Integration) solutions with BAM (Business Activity Monitoring) capabilities. At that time the business integration wave was catching on and providing an enabler for real-time access to business data.
During the years 2001 to 2004 considerable effort were put into research and resulted in published peer-reviewed research articles. During these years two open source releases were made of ruleCore prototypes to gain experience in this new style of event driven processing tools.
Event correlation as used by network monitoring solutions were used as inspiration source for the more advanced event correlation design ideas considering event selection and partitioning.
In 2005 the project where influenced with ideas from military sensor fusion approaches and research. Leading to design and implementation of business event fusion functions into the ruleCore CEP Server, which is the commercial implementation of ruleCore.
From 2004 to current date, effort is put into create an industrial strength server application for active rule processing.
Based on experience from the open source prototypes, the development of the ruleCore rule designer GUI was stopped in 2006. An open approach based on XML was adopted instead with public and free XML schemas and by choosing XML as the native interface. Also the engine was re-written to use an event driven architecture as the native API for rule management
During 2008 support has been added for geospatial event processing to complement the temporal event processing of the previous versions. Native support for GPS location datatypes and tracking of mobile entities with respect to geographical zones and routes (Defined using Google Maps or WebService API) has been added.
In 2009, a graphical user interface platform was added which uses a high level concept to provide a model suitable for non-technical end-users.
The main characteristic concept of ruleCore is its event driven nature. In contrast to conventional database and rule systems, in which the user executes a query at a given time, ruleCore reacts to events without requiring an explicit action from the user. All processing is initiated by inbound events or the lack of them.
The event driven nature comes as a result of ruleCore being a component designed to be used as a building block in an event driven architecture. Event-driven architecture (EDA) have been proposed as one way to build better enterprise architectures in the future.
The Rulecore server uses slightly different programming interface model than traditional server software. Most traditional programming interfaces (API) uses a request/reply paradigm for interacting with clients. The API is normally accessed using a programming language such as Java, Perl or C#.
Clients interact with Rulecore purely using high level XML events. The Rulecore server and its clients are both event sinks and an event generators. This model of interaction is not common and is a research topic for future software components. The claim is that high level access using events creates software components which are more easily re-used than software with traditional APIs. Although this approach comes with it own set of problems such lower performance and synchronization and correlation issues. Future research are conducted to assert the viability of this approach.
In order to provide a coherent and easy to understand architecture an event-driven architecture is used internally in Rulecore. The aim is to try to avoid shifting paradigms when passing the Rulecore external interface. As the Rulecore interface is event-driven an event-driven architecture is used internally. Thus external and internal events can be managed in the same way.
The plug-in components of which ruleCore consists of are driven by a central event dispatcher. Automatic thread management is used to allow components to be started in separate threads in order to try to take advantage of multi cpu and multi core architectures.
RuleCore uses the concept of active rules based on ideas from the active database research conducted in the 90s.
The active database research invented the concept of active ECA (Event-Condition-Action) rules. The concept used in ruleCore is based on this research but modified and improved upon to be suitable in a message/event driven environment. It also improves the concepts in many areas on the initial research prototypes proposed in projects such as Snoop and ODE.
The Rulecore software is available freely for research and the GPL licensed source code is available on Sourceforge. The results of the project are described continuously in academic papers and reports. The Rulecore project has also contributed to EU funded research projects.
The ruleCore Event Model, and its Rule Evaluation Model and its definitions described in XML Schemas are placed in the public domain and thus freely usable for many purposes. To date, there exists one commercial implementation, marketed as the ruleCore CEP Server. and one open source version known simply as ruleCore.