The Windows Workflow Foundation (WF) ships with a Policy Activity that allows you to execute a set of rules against your workflow. This activity contains a design time rules editor that allows you to create a set of rules. At run time, the Policy Activity runs these rules using the WF Rules engine. Among other features, the rules engine allows you to prioritize rules and to set a chaining policy to govern rules evaluation. The rules engine uses a set of Code DOM expressions to represent the rules. These rules can be run against any managed object, not just a workflow. Hence, the mechanisms of the rules engine have nothing to do with workflow. You can actually instantiate and use this rules engine without having to embed it inside of a workflow. You can use this rules engine to build rules-driven .NET applications. I gave a talk at the last Las Vegas VSLive! that demonstrates how to do this. The first sample in the talk uses a workflow to demonstrate the power of the rules engine. The second and third samples use a very simple example to demonstrate how to use the engine outside of a workflow. Two problems have to be solved. You have to create a set of Code DOM expressions for the rules. You have to host the engine and supply it the rules and the object to run the rules against. While the details are in the slides and the examples, here is the gist of the solution. To use the rules engine at runtime, you pull the workflow rules out of some storage mechanism. The first sample uses a file. A WorkflowMarkupSerializer instance deserializes the stored rules to an instance of the RuleSet class. A RuleValidation instance validates the rules against the type of the business object against which you will run the rules against. The Execute method on the RuleExecution class is used to invoke the rules engine and run the rules. How do you create the rules? Ideally you would use some domain language, or domain based application, that would generate the rules as Code DOM expressions. If you were masochistic enough, you could create those expressions by hand. As an alternative, the second sample hosts the Workflow rules editor dialog (RuleSetDialog class) to let you create the rules. This solution has two problems. Like the workflow designer, this is a programmer's tool, not a business analyst's tool. In addition, the rules editor dialog only works with business objects that inherit from the Activity class. Note that is the rules editor that has this issue, not the workflow engine itself. There are two possible ways to get around this issue although they do not solve all the problems. You could inherit your business object from the Activity class. This is ugly. The second solution "reflects" the fact that you only need the type information about your business class for the editor. You could create a stub (not a mock) object that only has the methods (without implementation) and fields that the rules will use. In any case, the object will need an empty constructor.
Read More...