Drools is an Object-Oriented Rule Engine for Java. Drools is an augmented implementation of Forgy's Rete algorithm tailored for the Java language. Adapting Rete to an object-oriented interface allows for more natural expression of business rules with regards to business objects. More importantly, Drools provides for declarative logic programming and is flexible enough to match the semantics of your problem domain. The various parts that compose a rule may be extended to lend domain-specific sense to the rule.

Drools Rule Engine

A rule engine may be viewed as a sophisticated if/then statement interpreter. The if/then statements that are interpreted are called rules.

The if portions of rules contain conditions such as account.getMoney() < 0. The then portions of rules contain actions such as send Warning(account). if (account.getMoney() < 0) send Warning(account);

The inputs to a rule engine are a rule execution set and some data objects. The outputs from a rule engine are determined by the inputs and may include the original input data objects with possible modifications, new data objects, and side effects such as sendMail('Thank you for shopping').

Rules are stored in a forward-chaining rule engine, i.e. the engine implements an execution cycle that allows the action of one rule to cause the condition of other rules to become met. In this way, a cascade of rules may become activated and each rule action executed. Forward-chaining rule engines are suitable for problems that require drawing higher-level conclusions from simple input facts.

These core tutorials will help you to learn the Drools Rules Engine. For an in-depth understanding and practical
 experience, explore Online Drools Training.

So, here's how you could rewrite the above check as a rule:

global AccountManager manager;

rule "checkMoney" when $account : Account( money < 0 ) then manager.warn($account); end

As you can see, a Rule file is based on two basic concepts:

Rules: declarative statements that govern the conduct of business processes. A rule consists of a condition and actions. The condition is evaluated, and if it evaluates to true, the rule engine initiates one or more actions.

Facts: are the data upon which rules operate. In our example, the available money are facts.

Using a Rule Engine

Rule systems are capable of solving very, very hard problems, providing an explanation of how the solution was arrived at and why each "decision" along the way was made. Among the main benefit of a Rule engine can be mentioned:

Logic and Data Separation: Breaking your domain objects from business rules can lead to a mach easier to maintain application as it can shield from changes in the future, since the logic is all laid out in rules.

Speed and Scalability: Many times we apply "if" conditions that we didn't really need. The Rete algorithm, as implemented by Drools, replaces all of the if ... then statements with an optimized network.

Centralization of Knowledge: By using rules, you create a repository of knowledge (a knowledgebase) which can be considered as a single point of truth, for business policy (for instance) - ideally rules are so readable that they can also serve as documentation

Tool Integration: Writing rules means also to get accustomed with Rule language, validation and debugging. Eclipse provide an excellent tool to deliver and test your Rules.

Understandable Rules JBoss Drools: rules can make it easy to express solutions to difficult problems and consequently have those solutions verified (rules are much easier to read then code).Often, business users are more comfortable with expressing things that they know to be true, than to express things in an if...then format.

Advantages of Rule Engines

Turning to rules adds a set of advantages to your applications:

Greater flexibility: keeping your rules into a Knowledge base let you adapt easily your decisions when they are changing.

Easier to grasp: Rules are easier to understand than procedural code so they can be effectively used to bridge the gap between business analyst and developers.

Reduced complexity: When embedding lots of decision points to your procedural codes it can easily turn your application into a nightmare. On the other hand rules can handle much better increasing complexity because they use a consistent representation of business rules.

Reusability: By keeping rules are kept in one place leads to a greater reusability of your business rules. Also, traditional procedural code often impose unnecessary variations of base rules which are therefore more difficult to reuse in other contexts.

Learn more about Drools Interview Questions in this blog post.

The shortest answer to this is "when there is no satisfactory traditional programming approach to solve the problem.". Given that short answer, some more explanation is required. The reason why there is no "traditional" approach is possibly one of the following:

If rules are a new technology for your project teams, the overhead in getting going must be factored in. It is not a trivial technology, but this document tries to make it easier to understand.

Typically in a modern OO application you would use a rule engine to contain key parts of your business logic,especially the really messy parts. This is an inversion of the OO concept of encapsulating all the logic inside your objects. This is not to say that you throw out OO practices, on the contrary in any real world application, business logic is just one part of the application. If you ever notice lots of conditional statements such as "if" and "switch", an overabundance of strategy patterns and other messy logic in your code that just doesn't feel right: that would be a place for rules. If there is some such logic and you keep coming back to fix it, either because you got it wrong, or the logic or your understanding changes: think about using rules. If you are faced with tough problems for which there are no algorithms or patterns: consider using rules.

Rules could be used embedded in your application or perhaps as a service. Often a rule engine works best as "stateful" component, being an integral part of an application. However, there have been successful cases of creating reusable rule services which are stateless.

For your organization it is important to decide about the process you will use for updating rules in systems that are in production. The options are many, but different organizations have different requirements. Frequently, rules maintenance is out of the control of the application vendors or project developers.

When not to use a Rule Engine?

As rule engines are dynamic (dynamic in the sense that the rules can be stored and managed and updated as data), they are often looked at as a solution to the problem of deploying software. (Most IT departments seem to exist for the purpose of preventing software being rolled out.) If this is the reason you wish to use a rule engine, be aware that rule engines work best when you are able to write declarative rules. As an alternative, you can consider data-driven designs (lookup tables), or script processing engines where the scripts are managed in a database and are able to be updated on the fly.

For an Indepth knowledge on Drools click on below:

• Drools Installation