Topic Archive: JSR-94

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.

• Digg
• Reddit
• del.icio.us

Comments (1)

business rules

JSR-94 - Getting Your Feet Wet

Dietrich Kappe, Friday, July 7, 2006 @ 10:08 pm

Over at the Sun Developer Network, you'll find a nice tutorial on writing a business rules application using JSR-94. It makes use of Jess rule engine for its example.

What is JSR-94? From the tutorial:

The specification for the Java Rule Engine API (JSR 94), developed through the Java Community Process (JCP)
program, defines a Java runtime API for rule engines by providing a
simple API to access a rule engine from a Java Platform, Standard
Edition (Java SE, formerly known as J2SE) or a Java Platform,
Enterprise Edition (Java EE, formerly known as J2EE) Java technology
client.

Beyond being useful in that the JSR-94 allows you to interface with any rule engine that supports the standard, it's also useful from a pure code reading perspective. Rule-based systems are different from OO and procedural systems; you have to think and design the applications differently. Reading the Java code of the example should give anyone who has never written a rule-based application a practical understanding of how these things should be built.

Give it a look and study the code. Of course, the standard doesn't solve all of your problems. While it does allow you to write one set of Java code to interface with any compliant rule engine, not all rule engines behave the same. More on that later.

• Digg
• Reddit
• del.icio.us

Comments (0)

business rules