Give Your Business Logic a Framework with Drools

Most web and enterprise Java applications can be split into three parts: a front end to talk to the user, a service layer to talk to back-end systems such as databases, and business logic in between. While it is now common practice to use frameworks for both front- and back-end requirements (e.g., Struts, Cocoon, Spring, Hibernate, JDO, and Entity Beans), there is no standard way of structuring business logic. Frameworks like EJB and Spring do this at a high level, but don't help us in organizing our code. Wouldn't it would be great if we could replace messy, tangled if...then statements with a framework that gave us the same benefits of configurability, readability, and reuse that we already enjoy in other areas? This article suggests using the Drools rules engine as a framework to solve the problem.

The sample code below gives a sample of the problem we're trying to avoid. It shows some business logic in a typical Java application.

if ((user.isMemberOf(AdministratorGroup)
      && user.isMemberOf(teleworkerGroup))
     || user.isSuperUser(){
         
         // more checks for specific cases
         if((expenseRequest.code().equals("B203")
           ||(expenseRequest.code().equals("A903")
                        &&(totalExpenses<200)
                &&(bossSignOff> totalExpenses))
           &&(deptBudget.notExceeded)) {
               //issue payments
           } else if {
               //check lots of other conditions
           }
} else {
     // even more business logic
}

We've all come across similar (or even more complex) business logic. While this has been the standard way of implementing business logic in Java, there are many problems with it.

• What if the business users come up with another form ("C987") that needs to be added to the already hard-to-understand code? Would you want to be the person to maintain it, once all of the original programmers had moved on?
• How do we check that these rules are correct? It's hard enough for technical people--never mind commercial folks--to review. Do we have any methodical way of testing this business logic?
• Many applications have similar business rules--if one of the rules change, can we be sure that it is changed consistently across all systems? If a new application uses some of these rules, but also adds some new ones, do we need to rewrite all of the logic from scratch?
• Is the business logic easily configurable, not so firmly tied to Java code that we need to recompile/redeploy every time that a small change is made?
• What if other (scripting) languages want to leverage the existing investment in business rule logic?

Related Reading Spring: A Developer's Notebook By Bruce A. Tate, Justin Gehtland Table of Contents Index Sample Chapter Read Online--Safari Search this book on Safari:   Only This Book All of Safari Code Fragments only

J2EE/EJB and "inversion of control" frameworks (such as Spring, Pico, and Avalon) give us the ability to organize our code at a high level. While they are very good at providing reusability, configuration, and security, none of them would replace the "spaghetti code" in the above example. Ideally, whatever framework we choose will be compatible with not only J2EE applications, but also "normal" Java (J2SE--Standard Edition) programs, and most of the widely used presentation and persistence frameworks. Such a framework should allow us to do the following:

• Business users should be able to easily read and verify the business logic.
• Business rules should be reusable and configurable across applications.
• The framework should be scalable and performant under heavy load.
• It should be as easy to use for Java programmers as existing front-end (Struts, Spring) and back-end (object-relational mapping) frameworks.

An additional problem is that while there are only so many ways to organize web pages and database access, business logic tends to differ widely between applications. Our framework should be able to cope with this and still promote code reuse. Ideally, our application would be "frameworks all the way down." By using frameworks in this way, we can a large amount of our application "out of the box," allowing us to write only the parts that add value for the customer.

Rule Engines to the Rescue

How are we going to solve this problem? One solution that is gaining traction is to use a rule engine. Rule engines are frameworks for organizing business logic that allow the developer to concentrate on things that are known to be true, rather than the low-level mechanics of making decisions.

Often, business users are more comfortable with expressing things that they know to be true, than to express things in an if...then format. Examples of things that you might hear from a business expert are:

• "FORM 10A is used for expense claims over 200 Euro."
• "We only trade shares in quantities of 10,000 or more."
• "Purchases over €10m need the approval of a company director."

By focusing on what we know to be true, rather than the mechanics of how to express it in Java code, the above statements are clearer than our previous code sample. Still, clear as they may be, we still need a mechanism to apply these rules to the facts that we know and get a decision. Such a mechanism is a rule engine.