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)
