Eden Ridgway's Blog

I've recently been landed with a project with rather ambitious timeliness. It's one of those systems that you could look at from two angles. It could be developed as a:

1. Rules oriented system - with work flow and decisioning being the core of the system. The considerations here are:
   1. This is going to be far riskier because of the increased complexity. Of course this is compounded by the delivery timelines, so there is not much room for error.
   2. It will be far more flexibile and easier to productise.
   3. Done correctly it will be an elegant system architecture
   4. Does one go for a custom workflow engine or build on an existing standard such as the Workflow Manamgent Coallition compliant(WfMC). In this instance a full blown WfMC standards compliant implementation would be overkill.
   5. The rules engine could be slow and hamper performance
   6. Will they ever modify the workflow element or will it be used purely for status tracking and work queues? If not, this could be handled by a much simpler status based system (of course one could say that about a workflow engine too :) ).
2. Or a status driven system with configurable product manager and a decisioning element to it. This would be the simplest to implement of the two and I'm not certain that if done correctly it would hinder the product. The way this would be implemented is:
   1. One could simply use the status of the target system element to determine which work queue it should appear in (as opposed to using the correctly outstanding set of tasks).
   2. Product configuration could handle the dynamic capture of certain elements that one may consider workflow.
   3. The decisioning engine end result may be used to trigger certain actions and change statuses (sounds like workflow doesn't it, but there is a difference).
   4. Progress tracking could be handled through logging/history on system elements.

Before leaping on any one approach I decided to scrounge around the net to see if there weren't any kind souls who had offered their hard work in these areas to the public. In the .Net area I found two rules engines that I could possibly use:

• NxBRE - This one looks very promising as it has been released under LGPL and it seems fairly mature (it is a port of JxBRE 1.7 and currently release is version 2.3). It offers a data driven (forward chaining) inference engine that supports Facts, Queries and Implications. RuleML is used as its rule definition language and comes with a Visio 2003 adapter for rule editing. It also has an XML based Flow Engine with if/then/foreach/while statements. What I really enjoy about this framework is that is offers Business Object Binders. The problem with this is that it uses reflection to get the information which as you know is slow. One could possibly extend this and implement an interface or a default indexer that returns the value of an object property when the property name is supplied [eg. GetProperty(string PropertyName)]. This is an approach that Paul Wilson used for his ORMapper project.
• SRE (Simple Rules Engine) - This project, still in alpha, is also a forward chaining engine but apparently the rules are simple to write. Of course that appeals to me immensely.

As usual there are several open-source Java engines around. Java-Source.Net has quite a long list of open source engines such as, Drools which uses Rete as its basis. This is supposedly a more efficient than standard fact/knowledge base lookup systems.

I didn't find any complete .Net work flow engines out there, but I did find a Java ones (I've come across more but could not be bothered to go and find them all again):

• OpenWFE - there is a OpenWFE-dotnet C# library which allows you to access all the function from .Net
• http://freefluo.sourceforge.net/ - It uses WSFL and XScufl as the definition language. It also forms part of the Taverna project.