Drools basics

Source

What is a Rules Engine?

If you've ever taken a series of conditional statements, tried to evaluate the combinations, and found yourself writing deep nested logic to solve a problem, these are just the sorts of entanglements that a rule engine can help you unrave.

Complex business rules when expressed as rules are easier to understand.

What is a business rule?

Its a business-oriented statement that encompasses a business decision. Often implemented by a if-then statement.

e.g.

Given a car and a driver, if all of the following conditions are met:
The car is red
The car is in a sport class
The driver is male
The driver is between the ages of 16-25

The consequence is a 20% insurance premium increase.

These business rules are not new: they are the business logic that is the core of many business software applications. If you're a developer, you've seen these rules time and again expressed as a subset of requirements. They're statements like "give a twenty-percent discount on orders over three items on Mondays" or "we don't insure sixteen-year-old males on supersport motorcycles."

The difference is in how the rules are implemented in the code. Traditionally these rules are written as if-else statements in application code. In drools, these rules are specified in Business rules form.

A rules engine takes these rules and executes them. Apart from that the engine also facilitates creation, deployment, storage, versioning and other administrative functions on rules.

Given a set of rules, the rules engine needs to determine whether a given rule should be selected for execution or not. Once selected for execution, the engine needs to determine the order in the selected rules must be executed in.

The rules engine uses a matching algorithm to determine which rules to execute. Drools uses a matching algorithm called Rete. Rete constructs a tree of business rules. Each node is a rule. Each leaf in the rules tree is a rule consequence (e.g. increase premium by 20%). A Fact (an applicant of age 21 applied for insurance for a green sedan [a 4 door car]) enters the top of the fact tree. Based on whether or not the fact satisfies a rule in a node, the fact navigates through the tree until it hits a leaf or a rule consequence. Treat, Leaps, Rete II and Rete III are improvisations of Rete.

Rules engines make sense when there is a certain level of complexity in the rules. If the rules are trivial or if every rule has to be run on every fact, then the overhead of using the rules engine may not be necessary. If the rules are complex, then the overhead makes sense.

Different rule engines expect rules to be specified in different ways. In java drools rules can be specified in xml files or java annotations or java POJOs that are wired with spring.

an example drools 3.0 .drl file:
package com.insurance.auto
import com.insurance.auto.Driver
import com.insurance.auto.Car
import com.insurance.auto.Policy
import com.insurance.auto.Style
import com.insurance.auto.Color
import com.insurance.auto.Percentage;
rule "High Risk"
when
Driver( male=true, age >= 16, age <= 25 )
Car ( style == Style.SPORT, color==Color.RED )
$p: Policy ()
then
$p.increasePremium( new Percentage( 20 ) );

Flavors:
The rule server can be embedded or can run as a server. If the application using the rules is already in a distributed env. (like EJB, web services, corba etc..) then hosting the rules in a server is better otherwise embedded mode is good.