Enterprise Applications embraces a lot
of business rules. These business rules are often critical areas in
decision making processes that attribute to changes in the behavior of
an enterprise transaction. While these business rules should be an
integral part of the Enterprise Solution transactions, they should be
easy to use, easily adaptable to modifications, should be segregated
from the programming logics so as to be easily maintainable.
Most often, one of the architectural
mistakes that we do is to embed these business rules as a part of the
software application code. This methodology poses some severe
disadvantages.
- When new rules are enforced, it becomes all the more difficult to
add them. The software program has to be modified to add this rule
thereby causing a downtime of the application.
- Embedding business rules with software program affords less maintainability.
- Access to these critical business rules for business experts is minimal since they are bundled with the core application logic.
- Efficient use of a business rules engine or a management system is inherently over looked.
- Reliability of IT departments on the business rule modification.
- Reduced or no usage of efficient algorithms for automated business decision process.
There are quite a number of business
rule engines (management systems) available in the market. One of those
that is prominent and noteworthy is the Drools (aka) JBoss Rules ™ that
provides efficient way to handle business rules within an enterprise
transaction. There are quite a number of advantages of Drools that makes
it attractive to the others such as but not limited to:
- Drools cater to many programming languages such as Java, Python, and Groovy etc.
- Drools can run on .NET
- Drools are Declarative in nature allowing programmers to use it at ease.
- Drools are flexible enough to be used by means of Domain Specific Language (DSL) to address the semantics of problem domain.
- Drools can be configured via decision tables (excel tables)
- Drools is based on forward chaining inference mechanism, which means
that changes to inference during rule executions dynamically change the
output behavior. What this means is that the data is iterated through
until the pre defined goal is reached unlike the backward chaining
approach.
Drools employ the famous pattern
matching RETE algorithm. When known facts are asserted into the
knowledge base, the implementation fires the rules (defined by the rule
set) in a sequenced manner until the end of the rule is reached and then
looping back to the first if necessary.
Drools for Airline
Airlines reservation system is mission critical system and is characterized by deployment across the world requiring split second
response for any input. I am considering a small business rule in the
airlines passenger services space to explain the importance of the
drools at runtime. A passenger list display for a flight might be
queried with different parameters to search for. I am considering that a
query has been supplied to match the requested origin and destination
and a specific booking status of a passenger to match for display. The
rule of thumb is to display only the confirmed passengers on board.
Further the rule should check if the segment being queries is open for
display.
Below is a snapshot of how the drools file would look like (denoted by *.drl extension)
Well, one might argue that the above
rule might be written through a java (or any program in that case) code.
The code would not look complex but would not look simple either. The
rule explained above is the simplest in its form. Resolving the above
simpler logic into an application code itself would amount to redundant iterations, in efficient loops
etc. Notice the line where the status of the FlightLeg is being checked
for from the list of Flight Legs and the line where the passengers with
confirmed status are collected. It is just a single line
that does the work! Furthermore any one can infer the outcome of this
decision, not mandating that java knowledge is absolutely essential.
There are flexible expression language
extensions employed by drools which cannot be programmed efficiently
when the business logic is embedded into the application code.
Furthermore drools bring in an abstraction to employing the business
rules thus keeping the application code more readable and more
manageable. Above all the power of drools is realized when there are
complex decision making processes during forward chaining inference,
especially when a decision outcome should have inherent effect on the
other.
The Rule Explained
As can be seen from the above screen
shot, the rule file contains a package declaration at the top followed
by a list of imports needed for the rule (similar to java environments).
The next section is a set of rule definitions. A rule is recognized by a
name followed by a set of conditions to check (denoted by the when keyword) and a set of actions to take as the conditions are satisfied (denoted by the then
keyword). A rule file can define any number of rules to be fired and
optionally a sequence in the firing manner (denoted by the salience keyword). You should probably use this salience attribute if the firing of one rule has a consequence on the other. The no-loop keyword in the second rule as can be seen from the screen shot is used to instruct the rules engine to skip looping.
Drools also provides a set of pre
defined enriched functions to work with collections and the like (as can
be seen from the above rule snapshot like the collect function), the retract function to evict objects from the working memory when they are no longer needed.
Invoking the rule
Invoking the drools rule file that we
defined is simple. To start with,…… the rule we defined has to be built
into a form of package. This is achieved by using the KnowledgeBuilder.
KnowledgeBuilder kBuilder = KnowledgeBuilderFactory.newKnowledgeBuilder();
A Knowledge builder in drools is
responsible for taking an input rule definition file (the individual
rule files, decision tables or the DSL files) and turning them into what
is called a KnowledgePackage which the KnowledgeBase can consume. Typically this is achieved in the following way.
kBuilder.add(ResourceFactory.newClassPathResource(“person.drl”),
ResourceType.DRL);
KnowledgeBuilder can report
errors if the input rules definitions or decision tables cannot be
compiled to knowledge packages. As a better programming practice it is
always good to check if the KnowledgeBuilder has errors before adding
resources.
When the Knowledge Packages are built,
it is then ready to be consumed by the KnowledgeBase. This is
accomplished in the following way,
KnowledgeBase kBase = KnowledgeBaseFactory.newKnowledgeBase();
kBase.addKnowledgePackages(kBuilder.getKnowledgePackages());
StatefulKnowledgeSession session = kBase.newStatefulKnowledgeSession();
//insert the objects that you want the rules to be fired for!
session.insert($object1);
session.insert($object2);
session.insert($object3);
//fire all the rules……
session.fireAllRules();
//dispose of this session since it is stateful.
session.dispose();
Wasn’t it simple? As can be inferred,
writing business rules using Drools simplifies the task of embedding the
rules into the application code that could otherwise result in
redundant iterations, complex logics during dynamic decision inference
etc. All of those are done behind the scenes through Drools. All the
more Drools employ efficient algorithms for best performance which would
otherwise have to be designed (or compromised which is what happens
most of the time). Above all the rules can be written as decision
tables, XML files which makes it more attractive.
Let us consider a small (rather ‘naïve’
to be precise) example to see how to employ Drools at run time. I am
assuming a face book class where a single face book has a collection of
persons and each person has an address. I am considering making use of
drools for these 2 business rules:
- No 2 persons in the face book instance can share the same email address.
- When the address type of the person is not specified it should be defaulted to ‘Residence’
A downloadable
source code (a small stand alone example to start with) is provided for
reference (as an eclipse project). The source code uses the drools
binary distribution (v5.x, http://www.jboss.org/drools),
XStream (another impressive library to convert your java objects to XML
without the need for schema definition Xor ML annotations, can be found
at http://xstream.codehaus.org) and Apache Log4J http://logging.apache.org)
