Rules-based Programming – Part 1

Definition of a ‘Rule’

A `Rule’ is a principle or a regulation, an action or a procedure, an arrangement or a statement. It can be defined as a statement that constrains some aspect of the business. Business rule is intended to assert business structure and to control or influence the business’s behavior.  The power of business rules lies in its ability both to separate knowledge from its implementation logic and to be changed without changing source code.

What are ‘Facts’?

Facts are simply your domain objects / models. Rules are run against these facts to match conditions declared in the rules with the state of the fact currently being used and this determines the rule / rules to run.

What is a ‘Rule Engine’?

Rule Engine uses Knowledge representation to facilitate the codification of knowledge into a knowledge base which can be used for processing the data with this knowledge-base to infer conclusions. It focuses on knowledge representation to express logic in a concise, non-ambiguous and declarative manner. A Business Rule is a two-part structure using First Order Logic for reasoning over knowledge representation.

when
 <conditions>
 then
 <actions>;

The most important part of a Rule is its `when’ part. If the`when’ part is satisfied, the `then’ part is triggered.

rule <rule_name>
 <attribute> <value>
 when
 <conditions>
 then
 <actions>
 End

The process of matching the new or existing facts against Business Rules is called Pattern Matching, which is performed by the Rule Engine. There are a number of algorithms used for Pattern Matching by Rule Engines including:

1. Linear
2. Rete
3. Treat
4. Leaps

The Rules are stored in the Production Memory and the facts that the Rule Engine matches against are kept in the Working Memory. Facts are asserted into the Working Memory where they may then be modified or retracted.

There are two methods of execution for a Rule system:

1. Forward Chaining, and
2. Backward Chaining.

Systems that implement both are called Hybrid Chaining Systems. Drools is a forward chaining engine.

Forward chaining is `data-driven’ and thus reactionary with facts being asserted into working memory, which results in one or more rules being concurrently true and scheduled for execution by the Agenda. In short, it starts with a fact, it propagates it and we end in a conclusion.

Backward chaining is “goal-driven” i.e. It starts with a conclusion which the engine tries to satisfy. If it can’t, it then searches for conclusions that it can satisfy; these are known as sub-goals.

Advantages of a Rule Engine

1. Declarative Programming
2. Logic and Data Separation
3. Speed and Scalability
4. Centralization of knowledge
5. Rules can be changed without changing source code. Thus, there is no need to recompile the application’s code.
6. Explanation facility
7. Understandable rules
8. Cost of production and maintenance decreases.

When to use Rule Engine

1. The problem is just too difficult for traditional code.
2. The problem is beyond any obvious algorithmic solution.
3. The logic changes often.
4. Domain experts (or business analysts) are readily available, but are non-technical.

When not to use a Rule Engine

1. The logic behind the rules is simple.
2. It is impossible to write the rules without using a series of if… else… statements inside the rule files.
3. Regardless of the problem’s complexity – if it is not a subject to frequent changes or doesn’t change at all – hard code the logic.
4. The problem can be divided into a small set of conditions and actions.

Conclusion

Using a `rules’ engine can significantly reduce the complexity of components that implement the business-rules logic in our Java applications. An application that uses a `rules’ engine to express rules using a declarative approach has a higher chance of being more maintainable and extensible than one that doesn’t. In the next part of this blog, will discuss about rule-based programming with reference to Drools.