There is a large literature concerning rule engines (forward chaining or backward chaining). During the last thirty years there were various proposals such as RETE, TREAT and the derived Gator algorithm. Signi cantly, RETE was embedded into various expert systems such as Clips and its successor Jess, and Drools including in a number of commercial rule engines and was extended various times including with support for ECA rules. However, none of them is able to directly process DOM Events. The goal of this paper is to present the architecture of a forward chaining Event-Condition-Action (ECA) rule engine capable to handle Document-Object-Model Events. This architecture is instantiated into a JavaScript-based rule engine working with JSON rules.
There is a large literature concerning rule engines (forward chaining or backward
chaining). During the last thirty years there were various proposals such as
RETE [
However, none of them is able to directly process DOM Events. The goal
of this paper is to present the architecture of a forward chaining ECA rule
engine capable to handle Document-Object-Model Events. This architecture is
instantiated into a JavaScript-based rule engine working with JSON rules [
The main goals this design should address are:
{ to move the reasoning process to the client-side resulting in reduced network
tra c and faster response;
{ to handle complex business work ows;
{ information can be fetched and displayed in anticipation of the user response;
{ pages can be incrementally updated in response to the user input, including
the usage of cached data;
{ to o er support for intelligent user interfaces;
{ enable users to collaborate and share information on the WWW through
real-time communication channels (rule sharing and interchange);
Complex event processing (CEP), is a methodology of processing events
taking into consideration processing multiple events with the goal of identifying
the meaningful events within a speci c time-frame or event cloud. CEP employs
techniques such as detection of complex patterns, event correlation, event
abstraction, event hierarchies, and relationships between events such as causality,
membership, and timing, and event-driven processes. A number of projects were
developed in the last ten years on these issues. However, there is one event
ontology which o ers large opportunities to be exploited in the context of actual
technologies such as Asynchronous JavaScript and XML (AJAX) [
This ontology is already implemented into browsers giving extremely powerful capabilities to RIAs which use it. Nowadays, several Web 2.0 applications use heavily AJAX in order to provide desktop-like behavior to the user. The number of RIAs is increasing because of the broad bandwidth of today's Internet connections, as well as the availability of powerful and cheap personal computers. However, traditional ways of programming Internet applications no longer meet the demands of intelligent (rule-enabled) RIAs. For example a highly responsive Web 2.0 application such as Google Mail, can be much easily personalized/customized using rules towards a declarative description of its behavior.
Implementing intelligent RIAs require reasoning possibilities inside the browser. In addition, using Event-Condition-Action (ECA) Rules to represent knowledge unveils the opportunity to design and run rule-based applications in the browser. 2
The Architecture of an ECA Rule Engine for Web Browsers 2.1
As depicted in Figure 1, the complete system comprises the Event Manager, Rule Repository, Inference Engine and Working Memory.
The main design goal of this architecture was to comply with the principles
of Software as a Service (SaaS) architectures [
{ Event-driven architecture - We emphasize that both human agents and software agents interact with this architecture by creating events i.e. the reasoning is event driven. Moreover, the architecture instantiation gets translated into a full event driven engine.
This architecture is a live system i.e. an event-based system that is reactive and proactive. It is reactive because it reacts based on the events it receives. It is proactive because by itself generates events, that can be consumed also by other entities being part of the whole system. 2.2
In the database community the main goal of designing ECA engines was to
provide generic functionality independent from the actual languages and semantics
of event detection, queries, and actions (see for example, [
During the last years there is an intense work either on de ning design patterns
for complex event processing [
Our goal is to provide a light Event Manager capable to process faster simple events without duration. Particularly, this architecture must handle DOM Level 3 Events. However, the extension points in the Event Manager make possible future extensions for complex events processing if we will be able to provide motivating use cases.
Basically the Event Manager (depicted in Figure 2) has an event vocabulary and listen for events. Its main activity is to create an event queue to be processed by the inference engine.
Inference
Engine Consumed events
WM events ActionProcessor events
resetEventQueue listenForWMEvents addEventToQueue consumeActionProcessorEvents
The Event Manager keeps on catching Working Memory (WM) event-facts and stores them in an event queue. In addition, it listens for two internal Action Processor messages: { busy - The Event Manager keeps on catching WM events and storing them in the working queue of events. { idle - The Action Processor informs that it is not working right now. The Event Manager pro-actively takes control and send its own message to the Inference Engine with the actual working queue of events. Each time an event is caught by the Event Manager it tries to nd out about the state of the Action Processor. If there is no new message from the Action Processor it keeps going on based on its actual knowledge of the Action Processor state. It changes its knowledge when it receives a new message from the Action Processor.
Finally, the manager handles the inference engine consumed events. Our model looks for mandatory handling of engine consumed events as the default mechanism to achieve the event consumption. Therefore if there are events which are not processed/consumed by the inference engine they are kept by the manager on its lifetime or until they are consumed by rules. 2.4
Our goal were not to use RETE and its variants (although in uences exist) but to build a lightweight engine. Our goals were not to embed strong e cient execution algorithms rather to o er a simple, extensible and fast rule execution engine. All these design goals were coming from our main goal: running rules in the Web browser.
receiveEventsQueue EventManager events queue extractEvent noMoreEvents
sendActions action queue
yes addAction extractRule Consumed Events
noRules
The basic activities inside the Inference Engine (see the Figure 3) are to
consume events (from the events queue delivered by the Event Manager ) match rule
conditions (match) and deliver action queue to the Action Processor (sendActions).
Despite other architectures where the actions are consumed inside the inference
engine, we decided for a separate component since the Action Processor is not
just a blind action executor but is able to perform various consistency checks
after it has received its queue of actions. The rules intended to be handled by
this architecture are JSON Rules [
Example 1 (JSON Rule example). {"id": "rule101", "appliesTo": ["http://mail.yahoo.com/"], "eventExpression": {"type": "click", "target": "$X" }, "condition": [ }
], "actions":["append($X.textContent)"] 2.5
"$X:HTMLAnchorElement($hrefVal:href)", "new RegExp(/showMessage\?fid=Inbox/).test($hrefVal)" As we already know, the purpose of business rules repositories is to support the business rule information needs of all the rule owners in a business rules-based approach in the initial development of systems and their lifetime enhancement. Speci cally, the purpose of a business rules repository is to provide: (a) Support for the rule-related requirements of all business, (b) Query and reporting capability for impact analysis, traceability and business rule reuse including web-based publication and (c) Security for the integrity of business rule and rule-related information.
Parts of our previous work (see for example, [
JSON Rules - Architecture Instantiation
We introduce the instantiation of our architecture in the JSON Rules context.
Recall from [
According to the reference architecture for Web Browsers introduced in [
In the case of the Mozilla 2 browser's architecture [
The general components view depicted in Figure 1 gets instantiated in the JSON Rules context as depicted in Figure 4.
Depicted in Figure 4 are the main packages of the JSON Rules engine. While
the engine and repository packages are self explanatory to some extent lang
package contains all the JSON Rules language entities. The utils package
contains entities dealing with di erent aspects such as: JSON parsing, or object
introspection and so on. The io package provides the necessary entities
managing IO operations. The engine package contains the following sub-packages:
eventmanager, actionprocessor, and matcher. The general ow of the whole
system is described in the Figure 5 (initially introduced in [
io
WorkingMemory
FireEvents ComputePossibleRulesToFire
InformOfEvents FireRules
ChangeWorkingMemory The MainSystem (Figure 6) is the interface through which the inference engine is accessed. As seen in the Figure 6 the only mandatory input is an Uniform Resource Identi er (URI) pointing towards a rule repository, from where rules will be loaded. 2 http://www.mozilla.com/ 3 http://www.mozilla.org/xpfe/ m e t s y S n i a M
run
Although not concretely depicted here through this interface a user could also specify other settings such as di erent event type for which the event manager should listen for.
Having speci ed a repository location the MainSystem performs the run activity.
The lifetime of the rule engine is in the scope of the lifetime of the current DOM inside the browser. Using the engine is simple. Firstly one must load the engine e.g. this <script type="text/javascript"
src="http://www.domain.com/jsonRulesEngine_Version.js"> </script>.
Secondly one must create an instance of the engine, for example: var jsonRulesEngine=new org.jsonrules.JSONRulesMainSystem(); Having the engine instantiated, it is now possible to run it by calling run() with the URI of location of the repository as input parameter:
In a basic application the main steps that happen are: { When an event is raised, the EventManager catches that event. Then the
EventManager checks the ActionProcessor's state. { If the ActionProcessor is running, then EventManager stores the event in the queue of events that the InferenceEngine must later on process. { However if the ActionProcessor is idle then the EventManager sends a message to the InferenceEngine containing the queue of events that must be processed. The InferenceEngine responds back to the EventManager, and informs it that it has received/consumed the queue such that the EventManager can reset its own queue. { Events are processed one by one. For each event rules triggered by that event will be matched against the WorkingMemory. The action of each executable rule is added to the list of executable actions (to be processed by the ActionProcessor) according with possible priority of rules. { The list of executable actions it is send to the ActionProcessor, to execute them. 3.2
As already introduced in [
In addition to DOM Level 3 Events, the DOM speci cation provides the necessary interfaces through which an user-de ned event can be created. However, in general, DOM events are simple events even though users could create their own events. There is also the possibility to use and de ne complex events by means of user de ned APIs such as Yahoo YUI4, Dojo toolkit5 etc. To deal with such user de ned APIs the EventManager uses the concept of adapter. An adapter can be written for each API and in this way events de ned using those APIs could also be tackled by the EventManager.
Another signi cant aspect of the browser based instantiation is that the whole ow is by nature sequential. Actual browsers' JavaScript engines are sequential, and because of this, so is the whole engine introduced here. However in the eventuality of a browser with capabilities to run parallel JavaScript tasks then the general architecture could be instantiated following the ability to run parallel tasks.
While a more detailed perspective on rule repositories has been already
introduced in [
I repositoryURI page page
run instantiateInferenceEngine itory refer to a speci c URI. This means that a speci c rule can be used in the context of a speci c resource. Rules referring to the same URI are grouped in rule sets.
Figure 8 depicts the interaction between the MainSystem and the RuleRepository. Basically, the MainSystem triggers a RuleRepository instance. The repository loads the rules from the repositoryURI speci ed location. Readers may notice that the repository might contain rules that do not refer to the current active resource. As such the MainSystem requests the URI of the current resource from the WorkingMemory. Based on that URI it requests from the repository the rule set referring to the current resource. Finally, based on this information (i.e. the URI of the current resource and the rule set associated) the MainSystem creates a Page object which will be used by the InferenceEngine. 4
This paper describes the general architecture of an ECA rule-based and forward chaining engine for web browsers. The design of such an engine derives from the goal to perform intelligent RIAs. The instantiation of the architecture results in a JavaScript-based ECA rule engine capable to load and execute ECA rule sets in the browser. This way we achieve a main goal: Implementing intelligent RIAs require reasoning possibilities inside the browser. The next steps related to this research are: (1) to investigate the capabilities of this engine to handle rulebased mashups on the Web and (2) to analyze scalability of the engine against the main browsers.