Complex business logic is the main issue that keeps developers awake at night. As the application evolves, it’s very hard to write and maintain this code.
The problem behind this is that this cannot be easily solved using standard imperative programming style (imperative programs are a sequence of commands for the computer to perform, e.g. languages like Java, C++ …). The most straightforward approach is to use declarative programming (languages that describe a problem rather than defining a solution, e.g. Prolog, SQL, XSLT) i.e. you are not saying “how” the computer should do it, but “what” it should do.
Since we are using an imperative programming languages one common way to avail of benefits that declarative programming brings is to use a Rule Engine or Expert System. Wikipedia defines the use of a rule engine in IT as follows:
“For any application the business rules change more frequently then the rest of the application code. Rule Engine or Inference Engines are the pluggable software components that separate the business rules from the application code. This allows the business users to modify the rules frequently without the need of IT intervention and hence allowing the applications to be more adaptable with the dynamic rules.”
An imperative method for ensuring you have your sunglasses if the sun is shining would be:
- Step outside and determine if it the sun is shining.
- If the sun is shining, then get sunglasses from shelf
The above could also be represented by two declarative rules:
If it the sun is shining
Then you need you’re sunglasses
If you need your sunglasses
Then get them from the shelf
Given declarative rules, the knowledge that it is sunny could produce two
courses of action:
- You already have your sunglasses, perhaps because you’re cool, in
which case, you’re ready.
- You don’t have your sunglasses, so you go get them from the shelf.
This allows you to use the knowledge you have and respond to that knowledge in the most appropriate way. You could, for example, already know it is sunny and simply get your sunglasses from the shelf. If you thought the sun was going to shine you could add another rule to the ones above:
If the sun might shine later, and
If you’ll be away from the house
Then you need your sunglasses
At this point, you only need to get your sunglasses if you know you don’t already have then, and either the sun is shining, or that it might shine later while you’re away from the house. If you were to write that all out in procedural code, it’d quickly get tangled and complex.
Some of the advantages of the declarative method:
- Simpler (i.e. cheaper) maintenance
- Reduced development time for complex business logic
- Higher performance, due to the algorithm optimization (business logic doesn’t run more times than necessary)
It might be surprising to discover that rule engines receive a lot of attention in the insurance claims, tax preparation, and medical industries. Sometimes, just having a system that can sift through reams of data and highlight the extreme cases can be of tremendous help.
Jess – Java Expert System Shell
Jess is the JSR-94 reference implementation. The syntax for the rules definition in Jess is based on LISP. The cost of learning a new language to define rules was considered too high to justify the uses of Jess for projects here in DSI. Coupled with that, Jess requires a license for commercial use. However, there is an interesting article on when to use a rule engine. I would disagree with the conclusions on ROI we saw payback almost immediately. This was mainly due to changing requirements.
“Drools is a Rules Engine implementation based on Charles Forgy’s Rete algorithm tailored for the Java language.”
Here at DSI we are using Drools. Currently rules can be written in Java, Python and Groovy. It supports the JSR-94 specification. This is not as important as it would seem as the specification only defines the interaction with a rule engine. So even though we can switch between rule engines by changing Spring configuration files, in pratice this would require a rewrite of the rules themselves to comply with the new engines rule syntax.
Drools adds another convenience to writing rules called Decision tables.
“Decision tables are a useful way to represent conditional logic in a compact format. This format is also readily readable and editable by non technical users (such as business analysts). Drools decision tables can utilise a spreadsheet (such as Excel) as the means to capture decision logic, in a user friendly way.”
We then take the spreadsheet and use a converter that converts these rules into drools-rules representation.
Declarative programming, for many, is a completely alien paradigm which should warrant a careful and thoughtful study before attempting to write “live” code. In some respects, Jess’s use of a LISP like syntax help people make that paradigm shift. Failing to do so can result in inefficient rules and seemingly unpredictable results. Debugging can be extremely difficult without an understanding of how the underlying system is working. Rule engines have many advantages, but on the other side they can be dangerous if you don’t know exactly what’s going on.
– Noel Keating
– Michal Bali