Business Rule Engine

A Business Rules engine works by separating execution code for business rules from the rest of
the business process management system. This allows the end user to change business rules
without having to ask a programmer for help. When a change is made, the engine will evaluate
the change's effect on other rules in the system and flag the user if there is a conflict.

Rule Engine Algorithm

There are different algorithms that run rule engine. We chose algorithm based on what
we need our rule engine to do. The algorithms are

1) RetePlus
2) Sequential
3) FastPath

1.1 Rete Algorithm

The Rete algorithm can be broken into 2 parts:

I. Rule compilation
II. Runtime execution.

The compilation algorithm describes how the Rules in the Production Memory
are processed to generate an efficient discrimination network. In non-technical terms, a
discrimination network is used to filter data as it propagates through the network. The
nodes at the top of the network would have many matches, and as we go down the
network, there would be fewer matches. At the very bottom of the network are the
terminal nodes.

1
1.2 Rete Nodes

Fig 1

1.2.1 Root Node

The root node is where all objects enter the network. From there, it
immediately goes to the ObjectTypeNode.

1.2.2 Object Type Node

The purpose of the ObjectTypeNode is to make sure the engine doesn't
do more work than it needs to. For example, say we have 2 objects:
Account and Order. If the rule engine tried to evaluate every single node
against every object, it would waste a lot of cycles. To make things

2
 efficient, the engine should only pass the object to the nodes that match
the object type. The easiest way to do this is to create an
ObjectTypeNode and have all 1-input and 2-input nodes descend from it.

ObjectTypeNodes can propagate to AlphaNodes,

LeftInputAdapterNodes and BetaNodes.

1.2.3 Alpha Nodes

AlphaNodes are used to evaluate literal conditions. Drools extends Rete

by optimizing the propagation from ObjectTypeNode to AlphaNode using
hashing. Each time an AlphaNode is added to an ObjectTypeNode it adds
the literal value as a key to the HashMap with the AlphaNode as the
value. When a new instance enters the ObjectTypeNode, rather than
propagating to each AlphaNode, it can instead retrieve the correct
AlphaNode from the HashMap,thereby avoiding unnecessary literal
checks.

1.2.4 Beta Nodes

There are two two-input nodes, JoinNode and NotNode, and both are
types of BetaNodes. BetaNodes are used to compare 2 objects, and their
fields, to each other. The objects may be the same or different types. By
convention we refer to the two inputs as left and right. The left input for
a BetaNode is generally a list of objects; in Drools this is a Tuple. The right
input is a single object.Two Nodes can be used to implement 'exists'
checks. BetaNodes also have memory. The left input is called the Beta
Memory and remembers all incoming tuples. The right input is called the
Alpha Memory and remembers all incoming objects. Drools extends Rete
by performing indexing on the BetaNodes. For instance, if we know that a
BetaNode is performing a check on a Stringfield, as each object enters we
can do a hash lookup on that String value. This means when facts enter
from the opposite side, instead of iterating over all the facts to find valid

3
 joins, we do a lookupreturning potentially valid candidates. At any point a
valid join is found the Tuple is joined with the Object; which is referred to
as a partial match; and then propagated to the next node.

1.2.5 Left Input Adapter Nodes

To enter the network we use a LeftInputNodeAdapter - this takes an

Object as an input and propagates a single Object Tuple.

rule
when
Cheese( $cheddar : name == "cheddar" )
$person : Person( favouriteCheese == $cheddar )
then
System.out.println( $person.getName() + " likes cheddar" );
End

rule
when
Cheese( $cheddar : name == "cheddar" )
$person : Person( favouriteCheese != $cheddar )
then
System.out.println( $person.getName() + " does not like cheddar" );
End

4
A diagram to illustrate the given code

Fig 2

5
1.3 Where to use RetePlus and Why ?

There is a principle called Chaining. Chaining can be understood as if a rule is fired and it
affects another rule by modifying it, we term this process as chaining.

There are tasks which do not have chaining. Like loosely interrelated rules, By loosely
interrelated we mean rules based on validation. Business rules in such applications
generally have a yes or no result and provide some explanation on the decision.

But some tasks have strongly interrelated rules. These rules exhibit chaining hence we
need Rete algorithm.

Rete has the ability to do the pattern matching b/w object and rule and if a match is
found an instance of it is inserted in agenda. And then it has the ability to reinsert the
object in working memory if any object is changed. These properties can handle strongly
interrelated rules.

1.4 RetePlus Algorithm

RetePlus is the Decision Server extension based on the Rete algorithm. In RetePlus
mode, rule execution uses an environment based on a working memory and agenda.

Fig 3

6
The first step involves in the matching of the conditions of the rule in the ruleset against
the objects in the working memory.

If a match is found, a rule instance is created and inserted into agenda. Agenda has
some techniques like refraction, priority, recency based on which it selects the rule
instance to be executed.

The execution of rule instance is the execution of the rule action. The
execution/processing of action leads to

1. Adding a new object to the working memory.

2. Removing an old object from the working memory.
3. Modifying the object in the memory.

This process goes on until no more rule instances are left in agenda.

Superior performance on computation and correlation types of

applications

In Rete Plus, whenever the working memory is modified, the rule engine repeats the
pattern matching process. It reassesses matches after each rule instance is executed and
modifies the data. As a possible consequence, the list of rule instances in the agenda can
change. Thus, Rete Plus is incremental and data-driven. These execution characteristics
give Rete Plus superior performance on computation and correlation types of
applications

7
2. Sequential Algorithm

The sequential mode executes all the eligible rules for a given rule task in sequence,
which provides specific performance advantages.

Fig 4

The sequential algorithm operates as follows:

I. The rule engine performs pattern matching on input rule set parameters and on
the conditions defined on the collections of objects in working memory.

II. For each match, a rule instance is created and immediately executed. When a
rule instance is executed, it sets the value of an attribute or an output rule set
parameter.

The sequential algorithm operates rather like an execution stack where pattern–
matching rule instances are executed once with no re-evaluation of the rules.
Because of its systematic nature, the sequential execution mode performs
particularly well on validation and compliance types of applications. Rules can be
processed sequentially using rule tasks within a ruleflow.

8
3. FastPath Algorithm

The Fastpath execution mode improves the sequential compilation and execution of
a rule project. Fastpath is a sequential mode of execution that also detects semantic
relations between rule tests during the pattern matching process, like RetePlus.
The following diagram shows how the Fastpath algorithm works.

Fig 5
The Fastpath algorithm operates as follows:

I. The rule engine uses a working memory that references application objects
or ruleset parameters. Fastpath performs the pattern matching process, as in
RetePlus, by creating a tree based on semantic relations between rule
condition tests.
II. For each match, a rule instance is created and immediately executed. When
a rule instance is executed, it modifies objects in working memory, but these
modifications are not taken into account and the rule engine does not repeat
the pattern matching process. The action of the executed rule also sets an
output ruleset parameter

9
 Fastpath combines features of the RetePlus mode for pattern matching and features
of the sequential mode for rule execution. In this sense, it compares well for
correlation types of applications as well as for validation and compliance
applications.

Like the sequential mode, the Fastpath mode is stateless. As such, it is dedicated to
matching objects against a very large number of rules that individually perform
simple discriminations or light join tests. It is best for very large number of rules to
be executed in sequence directly without any agenda support. In addition to its
advantages as a variant of the sequential mode, the Fastpath execution mode is
designed to further optimize the execution of the compliance and validation rules,
which constitute a substantial part of business rules.

We can also refer to the image in the next page to have better idea on preferring one Algorithm
over another based on the task they are to perform.

10
In your rule task: RetePlus Sequential Fastpath

Compliance and
validation
application

Computation
application

Correlation
application

Stateful
application

Working memory
objects

Rule chaining

Tests on
existence or
collection items
directly in working
memory

Shared test
patterns

Heterogeneous
bindings

Dynamic priorities

Runtime rule
selection that
selects a few
rules among
many

Numerous rules

11