There are several changes to this file to integrate the data
access layer with our business rules:

At the top of the file, we have several new
<java:import> statements to reference the
StockNameDao, DaoImplementation, and
DaoFactory classes that we added to the system.

We have a new tag, <application-data>, which
assigns an instance of the DaoFactory class to a
variable. <application-data> tags are similar to
parameters, except they apply to all business rules, and not just
one.

The Stock Price Low Enough rule has a new condition, which uses
the DaoFactory and StockNameDao to check
if the stock is on the list of those that we deal with.

We run our BusinessRulesTest (simulator) again. The
simulator/unit tests run OK, since even though we have changed the
structure of the program, we haven't (yet) changed what it does.
From looking at the output logs, we can see that our business rules
are using StockNameDao as part of their evaluations,
and that DaoImplementation.isOnStockList() is being
called.

While this example shows the reading of information from a data
source, the principles are the same for writing information, if
that is what a rule has decided should be done. The differences
would be that our DAO would have a setSomeInformation()
method, and that the method would be called in the
<java:consequence> part of the business rule,
once the specific conditions had been met.

Summary

In this article, we showed that most Java server applications
have three tiers: presentation, business logic, and data
persistence. While the use of frameworks is widely accepted in the
presentation and persistence layers, until now no framework has
been available to encapsulate low-level business logic. As we've
seen in the examples, Drools and JSR-94 are ideal candidates for
reducing the complexity and speeding the development of Java
applications. I hope that these examples inspire you to take a
closer look at rule engines, and that they save many hours of
development and maintenance time in your applications.