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.

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?

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.