Rete?

It seems that every thing that is to be called a Rules Engine must claim to implement the Rete Algorithm.  Microsoft's BRE does, Oracle's new Business Rules product does, iLog does, and the list goes on.  Going against the tide, the Rules Engine in Windows Workflow Foundation (WF Rules) does not implement the Rete algorithm.  That is not to say that it won't in the future, but in the near term, it won't.

Why not?

Let me first give a simple practical reason.  WF Rules was developed on a short development cycle, so we just didn't have time to implement it, let alone test it.

There are plenty of resources out there that describe what the Rete algorithm does and why it is so often used in Rules engines.  At the end of the day, Rete is an optimization.  You don't need a Rete engine to implement a forward-chaining rules engine; however, the Rete optimization may improve the runtime performance of a Rule Set.  That's what optimizations do.  In particular, Rete reduces the number of predicate evaluations by remembering the most recent value and re-using it on subsequent re-evaluations.

Ironically, I love optimization.  I have a compiler-development background, and local & global compiler optimization techniques are fascinating subjects, and fun projects.  Implementing the Rete optimization for WF Rules would have been a cool way to spend a coding milestone.

However, I also know that before you try applying a lot of cool optimizations to a project, you should try to make sure that they solve real bottlenecks.  Turning on the C++ compiler's global optimizer will do a lot of cool optimizing transformations to your program; but if your program's performance is dominated by network I/O, it won't make a bit of difference.

The same logic applies to Rules solutions.  Sometimes (quite often, I'd actually argue), a Rule Set is structured in such a way that there are no opportunities for the Rete optimization to make any difference.  For example, if each rule evaluates totally independent expressions against different facts, the Rete algorithm will yield no improvement.  In fact, its intrinsic overhead may result in a net loss of performance.

I certainly concede that there are many examples of Rule Sets that contain a lot of common predicates.  In those cases, a Rete-based Rules engine like BRE will crush a non-Rete engine like WF Rules.   However, in cases where there are few common predicates, the reverse has also been demonstrated:  WF Rules and its non-Rete execution mechanism will crush Rete-based BRE.

My point is simply that Rete is an optimization strategy that is not necessarily appropriate for all Rules-based solutions.  For WF Rules, we placed much more importance on how much you can express in your Rules, how easy it is to express it, and how well it integrates into Windows Workflow Foundation and the .NET framework.

Performance optimizations for WF Rules are certainly coming in the future.  But even without Rete, WF Rules is already a highly performant Rules engine.