There are lots of articles in the web that compare between BRE and WF Rule ,but most of them compare the performance , Rule model and how the core system work:
(http://geekswithblogs.net/cyoung/articles/56488.aspx)
http://geekswithblogs.net/cyoung/archive/2007/08/12/114597.aspx
The problem is that there is no good compare about the development effort, implementation ,extensibility and maintains of each one.
I would like to share some of our experiences with the 2 rules system and what the consideration before we decide which system to implement.
The BRE have lots of benefits like DB and XML vocabularies ,drag and drop facts to rules(very "impressive" composer UI) ,call the rules/policies directly from BizTalk (with special BizTalk task) and of course to call the BRE engine directly from code.
The BRE engine work very fast and very efficient(RETE Algo.) and can handle (of course with the help of the BTS) lot of process on the same time w/o the need to develop any special framework from scratch.
One of the strength of the the BRE is the option to create and run rules from several and different facts ,so the model and the layouts of the facts are organize well.
The BRE already have stable and defined tables in BTS DB's include tables relations , specifics sp's and jobs ,so you don't need to develop any piece of DB code. and it is just plug and play.
if you have several rules that most of the time you don't need to change them or that most of them can modify and control by the BizTalk administrator or any BizTalk users and not by any business users, the BRE is really good for that. you have full control on your process and good tracking of the results.
On the other hand to install or to work with BRE composer you need to have license for each BRE composer(you need to install the BTS for each BRE composer on each machine), so the idea to have BRE composer on each client it is something problematic, and most of the time the BRE composer need to be open on the BTS productions server or on any terminal server that link to this BTS production.
BRE deploy can be something not so simple and each time that you create new policy or need to update current policy , you need to un-deploy , deploy and save version again. this can be worse if you run the the policies directly from policy action in the orchestration because in such case you need also to turn on the new policy version in the BTS. something that not work perfect and sometimes you need to do it twice until the updated rules run in BTS.
Another problem is that with the current BRE composer if you have lots of polices it become not easy to work with the policies tree because you don't have any option to arrange the policies in any nested arrangement and the only option is to see them only in flat mode. of course if you more than 1,000 of policies (not too much if you calculate versions) it very difficult to maintains and aggregate such list.
Of course there is the option to create your own composer and just get/set the data with BRE Db and with the BRE API. of course it is manner of developing time.
The WF rule can be a very good alternative especially if you host it inside the BTS or run it inside webservice or any WCF service and just call it from BTS orchestration. with such combination you get very strong host and very common rule engine.
One other benefit that the WF rule editor have is the option to launch the rule set dialog directly from any .net. This capability give really good solution if you need that your business users will add/update rules directly from your application w/o the need to install any other application on their computer or open any other server. it is simple to de/serialize the rules set to text and keep it with mapping to your need. such freedom give a big benefit to work with the WF rules w/o the need to mess with deploy/versions operation in BTS
of course the limitation that there are no standard repository for the rules ,yo need to implement some db tables and some code that handle all these set/get rules data and running the engine on such rules sets (good example for that :http://richardsbraindump.blogspot.com/2007/08/how-to-use-windows-workflow-rules.html)
If you run the wf rule engine outside the WF (call it directly) the tracking can be a problem and there some examples in the web how to track the rules with the tracer. the solution with the tracer is very limit and you don't get all the calculations data for each rule. Other option is to use the visitor pattern on each rule fact(function or property) so each time that the rule engine run on the rule condition (or action) and invoke the functions ,the function itself track the calculation and insert it into static member tracking.(each function have his own visitor and create unique message and information for the tracking) , in the end ,when the action (or else action) is running ,their visitor just collect the member tracking.
for summarization,if you need rule engine that you can extend it very simple and you need that the business users will add/write rules in your application w/o any external components and the versions/deploy management will be as you like ,WF rule will be the best option, especially if you host it in stable and efficiency host (like BTS). if you just need to write rules in your orchestrations or you need to get facts data from db directly or you don't want to develop from scratch all the rules db/functions BRE will be better especially if you extend the current bre composer.
Shuki