Conflict Resolution - Why BRE’s Give Different Results

Dietrich Kappe, Tuesday, July 11, 2006 @ 9:00 am

A while back in 2004, Daniel Selman, the JSR-94 Specification Lead, published an article on the future of the specification. It's well worth reading in any case, but one particular observation stuck out:

In my opinion the root problem is not the lack of a standard rule language, it is the lack of a standard execution semantic for rule engines.

What the heck does that mean and why is it important? Well, without getting too technical, a BRE engine has a way of expressing rules. This way of expressing rules constitues a programming language. Any programming language has a syntax -- what are the valid programs, made up of keywords, identifiers, operators, etc. that can be written in the language -- and semantics -- what the program actually means or does. There are ways of formally specifying the semantics of a programming language, typically by translating the programming language into another language that already has a semantics or by mapping a trace-based semantics to the syntax of the language. I said "without getting too technical," so we won't go there.

In the case of BRE rule-sets, we can think of them being translated into data structures for a production systems pattern matching algorithm such as the RETE algorithm, which provides the execution semantics for the rule language. There are at least two ways that this can make for different semantics, i.e. different results from the execution of a rule-set. First, different algorithms can have different execition semantics, i.e. they process the rule-sets in ways different enough to give different results. Second, some parts of an algorithm can be variable.

The one bit of variability that immediately comes to mind is conflict resolution. Whenever a rule engine evaluates a rule-set, there is a likelihood that more than one rule will be activated. How to choose amongst these rules? There are a few different conflict resolution algorithms, each designed to achieve a different effect. Just a few examples:

• Salience. This is where the rule author assigns a priority to a particular rule. The highest priority rule is picked from all the matching rules. In a medical scenario, you may want the cancer rules to have a higher priority than the asthma ones.
• Longest matching. With this strategy, you execute the rules with the most number of clauses, i.e. the greatest number of AND'ed an OR'ed conditions. The idea here is that the rule with the most clauses is the most specific and should be fired first.
• Newest facts. Here the rule that was triggered by the newest fact or facts takes precedence. If you view the firing of foward chaining rules, this is sort of like a depth-first search -- keeping going down the branch that generated the latest new facts.
• Don't choose instantiations that have previously fired. If a rule already matched on certain facts and was fired, don't fire it again. The idea is to always do new things.

There are quite a few other conflict resolution strategies, of course, but I've listed a few of the more common ones here. (We haven't really touched on domain specific conflict resolution strategies here.) You can chain these together, i.e. salience first, then, if you have several rules of the same salience, pick the longest matching one, etc.. The important point is that different resolution strategies can result in rules being fired in a different order. A change is some facts can result in some rules that were matched early on, but passed over by the conflict resolution strategy, not being executed at all.

Now you should probably write your rule-sets so that order of execution doesn't matter. But in practice, this ideal isn't the case. Often, rules are harvested from existing business processes where order is already enforced in some way.

While building rule-sets that are execution order independent is a good best practice, it isn't always practical. BRE's are complex systems with complex behaviors. Having different conflict resolution strategies is often necessary and desirable. I'm not proposing a silver bullet here to make all rule exection semantics the same, though it might be nice to make them more transparent and configurable. Just be aware that standards like JSR-94 are great for integration, but don't guarantee that you'll get the same results with those different engines. Understand the tools you use.

business rules

Comments: 1 so far

• Leave a comment
• Comment feed for this post
• TrackBack URL

1. 

   When were were initially trying to get Miss Manners to work in Drools 3 the conflict resolution had some unexpected surprises. For this reason we did a complete paper on the Manners example, which should throw light on the intracacies of the benchmark. This paper shows the problems that conflict resolution and non documented arbitrary behaviour can have on complex problems.
   http://labs.jboss.com/file-access/default/members/jbossrules/freezone/docs/3.0.2/html_single/index.html#d0e3382

   Extract from the conclusion:
   “What have we learned from this? That Manners was designed to run with OPS5 Recency and that if works with Jess or Clips under Depth then from a user point of view it should be considered purely coincidence - even if the design was by developers intent.”

   Comment by Mark Proctor, Wednesday, July 12, 2006 @ 5:05 am

Leave a comment