There is no well-defined way to represent the business logic in Java or C#. What usually happens is that every application represents business logic differently.

For example, consider this code that does some checking on customer level, customer accounts, and account balance:

if (customer.getLevel() == Level.Gold) {
  // do something for Gold customer
} else if (customer.getLevel() == Level.Silver) {
  if (customer.getAccounts() == null) {
    // do something else for Silver customer with no accounts
  } else {
    for (Account account : customer.getAccounts()) {
      if (account.getBalance < 0) {
        // do something for Silver Customer that has                        // account with negative balance
      }
    }
  }
}

Code listing 1: Code written in standard Java (or any imperative-style language)

First, the code checks if the customer's level is Gold and does something, then it checks if the customer's level is Silver, and if so, it checks if this customer has no accounts and does something in this case. If the customer has accounts, the code performs some logic for each account that has a negative balance.

The point of this Java "spaghetti code" is to give you an idea about what we are trying to prevent. You may think that it doesn't look that bad; however, after a couple of changes in requirements and developers who are maintaining the code, it can get much worse. It is usually the case that if you fix one bug, you are more likely to introduce several new bugs. Lots of requirements are literally packed into few lines of code. This code is hard to maintain or change to accommodate new requirements.

It is not only difficult to represent business logic in an imperative programming style language, but it is also hard to differentiate between code that represents the business logic and the infrastructure code that supports it.

For developers, it is hard to change the business logic. For the domain experts, it is impossible to verify the business logic and even harder to change it.

There is a need for a different paradigm for representing the business logic.

The problem is that with an imperative-style language, we are implementing both: what needs to be done (business requirements) and how it needs to be done (algorithm). Let's look at declarative-style programming, for example, the SQL in relational databases. The SQL describes what we want to search; it doesn't say anything about how the database should find the data. This is exactly what we need for our business requirements.

A rule engine provides an alternative computation model. We declare rules in pretty much the same way as the business analyst does requirements, that is, as a group of if-then statements. The rule engine can then take these rules and execute them over our data in the most efficient way. Rules that have all their conditions true have their then part evaluated. This is different to imperative-style programming languages where the developer has to explicitly specify how it needs to be done (with sequence of conditionals and loops).

If we rewrite code from Code listing 1 in a declarative manner, it might look something like this:

if Customer( level == Level.Gold )
then do something else for Gold customer

if Customer( level == Level.Silver )
and no Account( )
then do something for Silver customer who has no accounts

if Customer( level == Level.Silver)
and Account( balance < 0, customer.accounts contains account )
then do something for Silver Customer that has account with negative balance

Code listing 2: Rules from Code listing 1 written using declarative style

Each rule represents one requirement. This is more readable and maps to business requirements more naturally.

It is also useful to note that in an imperative program, the piece of code evaluating the customer's level in the first example needs to be explicitly invoked, passing to it a specific customer. In a declarative program you cannot invoke a given rule directly; do not decide on which data you want to run it, because the customer instance is actually taken from a working memory (this will be described later).

Drools is a Business Logic integration Platform (BliP). It is written in Java. It is an open source project that is backed by JBoss and Red Hat, Inc. It is licensed under the Apache License, Version 2.0 (http://www.apache.org/licenses/LICENSE-2.0.html). This book will focus on Version 5.5 of this platform that was released in November 2012.

Work on Drools (the rule engine) began in 2001. From its beginning Drools underwent many changes. Drools 1.0 started with a brute force linear search. It was then rewritten in Version 2.0, which was based on the Rete algorithm. The Rete algorithm boosted Drools' performance. Rules were written mainly in XML. The next Version 3.0 introduced a new .drl format. This is a domain-specific language specially crafted for writing rules. It proved to be a great success and it became the main format for writing rules. Version 4.0 of the rule engine had some major performance improvements together with first release of Business Rules Management System (BRMS). This formed the base for the next big release 5.0, where Drools became a BliP. The platform consists of four main modules:

Drools has several optional modules. For example, OptaPlanner for solving planning problems or Drools Chance that adds uncertainty support. Another very important part of Drools is its Eclipse plugin.

Drools has a very active and friendly community. It is growing with every year. You can get in touch by visiting the Drools blog, wiki, or the mailing lists. For more information please visit the Drools website at http://www.jboss.org/drools/.

We've learned why there is a need for a business logic integration platform such as Drools. What problems it is trying to solve and in what ways it is trying to solve them. We've seen advantages and disadvantages of this solution.

In the following chapter we're going to look at how to set up the development environment before starting with some basics needed to write and execute rules in Drools.