Feedback on WF 4 Rules Guidance

Question

Hi folks,

In order to help migrate WF customers from .NET Framework 3.0 / 3.5 to .NET Framework 4.0 (Beta1 and beyond), our team has posted a set of migration documents over here. I'd encourage you to go through them - they provide guidance on best practices to follow today to help you move to WF 4 more easily later, and they also provide general guidance on how to accomplish certain key scenarios.

Please use this thread to provide feedback on the WF 4 Rules Guidance document. We are looking forward to hearing from you and we hope you find the docs useful - if you'd like to see additional content, samples on the topic, please let us know so in future revs, we can incorporate your feedback and provide you with resources that will help you move to WF 4.
-Kavita Kamani
Lead Program Manager, WF

---

Senior Lead Program Manager, Windows Workflow Foundation http://blogs.msdn.com/kavitak

Answer 1

I found the WF 4 Rules Guidance document very useful and informative.  I have been evaluating the WF3 stack for both workflow scenarios and policy/rule scenarios outside of workflow and while I understand the vision and motivation for the WF3 stack I was turned off by some of the complexity in the implementation details (such as the use of CodeDom for serializing rules).  I am encouraged about the changes and improvements coming in the new WF4 model and it is obvious that much though has gone into simplifying and unifying the implementation for declaritive logic.  The guidance document's explanation of how the same problems can be solved using existing WF4 activites such as sequence and if..else makes total sense and I agree with your choice to get that general purpose declaritive logic experience nailed for the first release and leave a more first class rule/policy activity for a later release because for my scenarios I think I will be able to express my logic using the WF4 techniques described.

Thank you for providing this document and for the candid content that acknowledges some of the weaknesses of the WF3 model while providing very clear guidance on the options available in WF4 to address similar problems.  In my opinion you have handled the WF stack change in exactly the way you should - you made sure all existing WF3 stuff still works as is with no change by making sure all WF3 code can run on the 4.0 runtime, you are providing a brand new model that addresses numerous shortcomings and lessons learned from 2+ years of feedback and you did not compromise or hold back but instead really went back and rethought about how to implement the workflow model, and you are providing interop and guidance for anyone that did choose to make a bet on WF3 so that they can migrate in an incremental fashion.

Answer 2

Thanks Paul! It's great to hear you found it useful and like the direction we're taking. We're definitely aware of and looking into building on top of this model to provide a better Rules oriented experience in the future releases.
Kavita

---

Senior Lead Program Manager, Windows Workflow Foundation http://blogs.msdn.com/kavitak

Answer 3

Hi,

We are using RuleEngines, RuleSets and Rules from WF3 standalone (we have even created a simple web-based editors for these). As far as I understand, WF4 will support only sequential rule engine execution, where the Sequence and IF-THEN-ELSE activity are used. My question is - if we compare a WF3 rule set with 2 rules which simply check a variable and set another one as an output with WF4 workflow with the corresponding constructs, what is the difference in the runtime execution from the performance point of view? At a first glance WF4 sequential rule engines equivalent seem to be much more heavyweight whatever the performance optimizations in WF4 are ...


Best regards,
Deyan Petrov

Answer 4

Hi Kavita,

Our current scenario is similar to the one described by Deyanp: we are using WF3 Rule Engine stand-alone, to execute our rules that are stored without any activity associated with them. Moreover, to avoid using of CodeDOM for simple rules, we serialize them using a custom rule editor and parse using WF3 rule parser.

Since this thread has shown that we are not alone, it can be useful to get guidance on this case, even though it is not related to workflow execution. Will we have to wrap our rules in new custom activities? Can we continue calling WF rule engine and parser as stand-alone .NET components? What is the recommended practice for this?

Thanks in advance

Vagif

---

Vagif Abilov

Answer 5

Does the rules guidance document only apply to Beta 1?  I ask because Stephen W. Thomas from BizTalkGurus.com demonstrated native WF4 Rules and RuleSets (i.e. not Interop) in a sequential workflow (http://www.biztalkgurus.com/media/p/21917.aspx).  He seemed to be using bits from a pre-Beta 1.

Answer 6

Does the rules guidance document only apply to Beta 1?  I ask because Stephen W. Thomas from BizTalkGurus.com demonstrated native WF4 Rules and RuleSets (i.e. not Interop) in a sequential workflow (http://www.biztalkgurus.com/media/p/21917.aspx).  He seemed to be using bits from a pre-Beta 1.

Yes - the guidance documents relate to the features, functionality, and object model released with .NET 4 Beta 1.

The CTP release that was given to PDC attendees had partial/early implementation of a native WF4 rules engine that has been postponed until after the .NET 4 release.

Answer 7

@Vagif,

If you are using the WF3 rules engine, that will continue to ship in the .NET 4 framework (and will ship mostly unchanged), so your code will keep working against the existing wf3 rules engine. 

let me know if that helps,

matt

---

Program Manager -- Modeling Platform and Tools http://blogs.msdn.com/mwinkle

Answer 8

Matt,

Thank you for the clarification. I have figured out that WF3 rule engine will work as before, so our applications won't be broken.

Vagif

---

Vagif Abilov

Answer 9

Deyan,
I would recommend trying out WF for your sequential rules scenarios. It's very snappy, and they are also simple to invoke with WorkflowInvoker.  As a data point, when we built a rule set activity on top of the WF4 runtime we were able to achieve better performance than the WF3 standalone rules engine.

Thanks,
Kenny

Answer 10

Hi Kenny,

Thanks for the advice, we will benchmark WF4 sequential rules. Have in mind, that our rulesets contain a flat list of more than 100 rules... Another potential stopper for migrating to WF 4 rules is, however, the fact that we use full chaining in our rulesets, which is not available in WF4's sequential rules support. We have a number of rule engines which need to return only 1 value and this immediately after the first rule sets it, that's why we have a rule like this:

Name: exitAfterFirstValueSet
Condition: this.OutputValue != 0
ThenActions: Halt
Priority: 9999

Br,
Deyan