At work we struggle with our feelings concerning our rules engine (Jess). The promise of rules engines is that the business can make rules and the Rete algorithm will determine the correct answer every time. However, the business has never shown an interest in learning how to program new rules using Jess’ lisp like language. Additionally, QA doesn’t approve of Jess’ deterministic Rete algorithm. The fact that one acceptable and correctly written new rule can change expected behaviors for all related rules and break regression tests is a nightmare for QA. As a result, I found Martin Fowler’s observations about rules engines very interesting.
- “At one time there was the notion of building an entire system using a tool like this, but now people (wisely) tend to use rule engines just for the sections of a system. The production rule computational model is best suited for only a subset of computational problems, so rules engines are better embedded into larger systems”
- The idea that “once you have a rules engine then the business can manage the rules” doesn’t seem to work out in practice. The rules tend to be managed in programmatic way that the business is not interested in learning.
- Individual rules can make sense but once the list becomes significantly large then it becomes impossible to get your head around the expected results when new rules are added. “The interaction of rules can often be quite complex – particularly with chaining – where the actions of rules changes the state on which other rules’ conditions are based. So I often hear that it was easy to set up a rules system, but very hard to maintain it because nobody can understand this implicit program flow.”
Mr. Fowler’s Recommendations
- It does seem that it’s important to limit the number of rules, indeed any system with enough rules to need sophisticated algorithms to get good performance probably has too many rules to be understood.
- Similarly I’m inclined to think one should be wary of rules that do a lot of chaining.
- As in many places, testing is often undervalued here, but implicit behavior makes testing more important – and it needs to be done with production data.
- While building a rules system, I’d look to do things that would cause Early Painwith modifications of the rule base.When looking into rules engine solutions, implement small rules engines for specific cases with a narrow context. If the context is narrow enough then a “hand-rolled domain specific approach” may be a better fit and easier to maintain/understand. It would be worth proving out both implementation to see which one would be a better solution.
Challenges
On-Line Transaction Processing (OLTP)
Fact capturing doesn’t always fit with an OLTP model. Where transaction speed is essential adding statements that roll up data or increase the number of inserts to persist facts feels at odds. Where possible it would make sense to offload the fact saving and gathering for another system.
Contradictory Observations
In separate bliki, Mr. Fowler discusses Contradictory Observations. He describes the need to capture data that is not absolute.
In his example, there is a patient and the hospital needs to save his blood type. Instead of simply adding a blood type column to the patient table, the hospital would like to track any instances where the blood type was determined to be different. Say hospital A has the blood type as O hospital B may have recorded the blood type for the same patient as AB.
He introduces the idea of observations. Saving all blood type determinations in an observations table. One aspect is that a future observation can reject a previous observation. But it is still necessary to track the rejected observation as it may be necessary to reject other resulting observations.
Observation Data Modeling
Modeling contradictory observations could be tricky using a relational data model. Anders Nawroth follows up with Mr. Fowler’s bliki post by suggesting that a graph database like Neo4j would be an appropriate way to store this observational data.
Observational Data Modeling
I like this idea of observation data modeling as it could relate to rules engines. The idea that there could be contradictory observations with one observation rejecting another and its sibling observations, is fascinating.