Introduction
This Rules Engine was formulated from my need to provide automation based on external rules. The rules were to govern how the graphical user interface (GUI) behaved in response to Rule execution. De-coupling the rules of the application enabled me to then develop the GUI independently of the Rules and to develop the Rules independently of the application. The connection between the application and the rules is a rules engine whose responsibility is the execution of the rules and notifying the application of changes to variables.
This is the original intent of this Rules Engine, it has since evolved in scope and applicability.
Background
The original intent of this library precluded any notion of ambiguous or non-determinant rule execution. The original need required absolute determination of results since the automation of a GUI cannot resolve ambiguity. I decided to define Rules such that the Rule maker made the decision tree(s).
Rules engines that I have seen (Corticon's offering excepted) are built upon the RETE algorithm. This engine does not utilize the RETE algorithm. RETE can produce non-determinant results which can be disastrous to automation. RETE is better suited to analysis than automation.
This engine has evolved to accommodate various use cases.
Thread-safety is integral to the engine and is implemented using the ReaderWriter
lock in .NET. Rule execution based on variable changes is implemented by defining "Triggers". Events for rule execution as well as variable changes are also defined.
Using the Code
The Rules Engine is utilized by instantiating a Rule Engine object from the class. The Rules Engine can then be loaded with Rules.
Instantiating a Rules Engine and adding delegate
s:
Variable _oVariableEngine = new VariableEngine();
RulesEngine _oRulesEngine = new RulesEngine();
_oRulesEngine.VarEngine = _oVariableEngine;
_oRulesEngine.VariableChanging +=
new RulesEngine.VariableChangingDelegate(_oRulesEngine_VariableChanging);
_oRulesEngine.VariableChanged +=
new RulesEngine.VariableChangedDelegate(_oRulesEngine_VariableChanged);
_oRulesEngine.VariableAdded +=
new RulesEngine.VariableAddedDelegate(_oRulesEngine_VariableAdded);
_oRulesEngine.RuleEntered +=
new RulesEngine.RuleEnteredDelegate(_oRulesEngine_RuleEntered);
_oRulesEngine.RuleComplete +=
new RulesEngine.RuleCompleteDelegate(_oRulesEngine_RuleComplete);
Rules can be defined and loaded into the engine from any source. The source code contains a Reader/Writer Visual Studio Solution as well as an XML Schema (with documentation) for using an XML file to define and persist Rules.
Links of Interest
Points of Interest
- Type-safe collections are implemented by extending
CollectionBase
and using a binary search algorithm to provide high performance access to any item in the collection.
- Variables are class objects that have overloaded operators.
- There is an Interface that allows any object to be used as a variable. Using
DataSet
s as variables are implemented using this methodology
- The source code contains the complete Visual Studio Solution of Jaxlab Rules Engine, complete Visual Studio Solution for
Reader
/Writer
class, Rule XML Schema and documentation, complete documentation of Rules Engine (HTML and CHM).
- A Rule can contain Rules to create rule trees to organize rules and rule processing.
History
- 29th August, 2006: Initial post