Introduction

When knowledge is manipulated, many rules may become activated. The consequences of the rules fire serially and thus must be ordered in the activation queue. Since firing one consequence may manipulate knowledge, the order of rule firing is important. Different end-results may occur based upon different firing order. Applying an order to the activations is called a conflict resolution strategy. Each RuleBase has a conflict resolution strategy chain that determines how rules are prioritized.

Drools provides the following Conflict Resolution Strategies:

Each strategy is a singleton implementation of ConflictResolver, which itself extends Comparator and simply compares two Activations indicating which, according to that strategy, should be placed at the top of the Agenda.

However these strategies should not be used indivually instead they should be chained together; so that when a ConflictResolver has two equal Activations the next ConlictResolver the chain will try to decide. CompositeConflictResolver is used and takes an array of ConflictResolvers as it's constructor.

DefaultConflictResolver extends CompositeConflictResolver and passes an array of Salience, Recency, Complexity, LoadOrder to its constructor - this is used by the system unless specified elsewhere. DefaultConflictResolver ensures that if there is still a conflict after Salience the most recent and most specific rule is fired; if the conflict is still not resolved then the conflicting rules are arbitrarily fired, in this case based on load order.

To specify an alternative conflict resolution strategy create a new CompositeConflictResolver using the required conflict resolvers and pass that as a parameter to RuleSetLoader or set via a method in RuleBaseBuilder.

ConflictResolver[] conflictResolvers = 
new ConflictResolver[] { SalienceConflictResolver.getInstance( ),
                         FifoConflictResolver.getInstance( ) };

RuleBase ruleBase = java.io.RuleBaseLoader( url, CompositeConflitResolver( conflictResolvers ) );

Conflict resolvers should not be specified by the user working with the WorkingMemory, instead they should be setup by the person who deploys and maintains the central RuleBase repositories; e.g. JNDI, see Using Rules at Runtime.

Conflict Resolution Strategies

Salience

Each rule has a salience attribute that can be assigned an Integer number, defaults to zero, the Integer and can be negative or positive.

Salience is a form of priority where rules with higher salience values are given higher priority when ordered in the activation queue. When a conflict occurs, i.e. more than one matching salience value for the current activation, then a sublist of those conflicts is returned.

Recency

Recency looks at the counter assigned to each Fact in an Activation. Activations with the highest counter are placed at the top of the Agenda

Primacy

Primacy looks at the counter assigned to each Fact in an Activation. Activations with the lowest counter are placed at the top of the Agenda

Fifo

A depth based strategy dictacted by the order of activation. New Activations are placed on the top of the agenda. Due to each Activation creation being given a unique number conflicts will not occur for this strategy.

Lifo

A breadth based strategy dictacted by the order of activation. New Activations are placed on the bottom of the agenda. Due to each Activation creation being given a unique number conflicts will not occur for this strategy.

Complexity

This is a specifity based strategy and takes into account the complexity of the conflicting rules. The more complex the rule, ie the more conditions it has, the more specific it is - the number of parameters is not taken into account. Activations with a higher specifity are placed at the top of the Agenda.

Simplicity

This is a specifity based strategy and takes into account the simplicity of the conflicting rules. The more simple the rule, ie the less conditions it has, the less specific it is - the number of parameters is not taken into account. Activations with a lower specifity are placed at the top of the Agenda.

LoadOrder

As each rule is added to a ruleset it is given a loadOrder number; this can be used to "arbitrarily" resolve conflicts. Rules with a higher loadOrder number are placed at the top of the Agenda. As each number is unique conflicts will not occur for this strategy. This rule is semamtic module implementation based and should not be consider a "constant"; as semantic modules are updated loadOrder may change.

Random

Activations are randomly inserted into the Agenda;

References

Nambiar, Ullas B. "Study of JAVA based Expert System Shell - JESS" Dept. of Comp. Sci. Arizona State University
Jackson Peter "Introduction to Expert Systems" Addison-Wesley 1999

Conflict Resolution