ORCAS WCF+WF Training: Windows Workflow Foundation
In "WCF+WF in ORCAS: Deep Dive Training at Redmond", I promised a dedicated post about WinWF.
What is Windows Workflow Foundation in .NET 3.0? A runtime engine, topped up with services and tools.
Workflow runtime engine is superior. It implements traditional sequential and state-machine workflow, the two can nicely interplay. Dynamic update of a running workflow instance – known in WfMC fundamentals as AdHoc Workflows is there, too. Long running workflows are supported. Sweet part of WinWF, the Rule Engine, rulez and can be rehosted outside of WinWF applications. Runtime scales up and down, performs exceptionally well. It is well designed for flexibility and extencibility. They call it "future proof". Ok, my bullfighter is scorning at me here.
What is cooking with ORCAS?
Two new activities - ReceiveActivity and SendActivity – bring elegant integration with WCF. We did a lab, which soon will be available on the community site. Handling external events will be simplified: workflow/host communication made easier. That’s it, in my notes. Will double check when I get the presentation video & .ppt.
There is no updates on UI components. This is disappointing. Rule Set Editor can be rehosted, but you can’t use it unless you are a programmer. Workflow designer can be rehosted. But it’s a total usability disaster, even for a programmer. Everyone agrees that normal user can’t possibly use it. Microsoft acknowledges but “choose not to work on this problem” So if you think of exposing Workflow or Rules in your product, you are on your own. Like these people who reimplemented workflow designer with style.
Matt Winkler gave an exciting presentation on WinWF performance. He was sharing tricks to tune Worfklow Runtime to get the right performance trade-offs, based on scenarios. What I picked up:
Think when to track. Choose full reliability (Persist on Choice) or full speed (no persistence). Or, use controlled save point. Implement them as an empty activity with [PersistOnClose] attribute on Execute override. Think what to track. Track only what you need. Partition tracking service to avoid polluting DB. Batch tracking reduces the load on SQL server. Bindable properties do not slow things down too much, but when you don’t need binding, use simple properties. Nesting compensations are expensive. Transactions use DTS – take performance hit. While is expencive: it’s 2000 times faster to do it inside [code] activity then using workflow while. Dynamic updates ARE SLOW (and if you think you need them, think again). Farms of workflow hosts are easily configurable with SQL Tracking Service. When tuned well, WinWF performs (detailed metrics in this article).
Am I sold on WinWF? Almost. I like the technology, but not entirely sure if it is ready for a prime time yet. In the next post, I will share my reservation.
Labels: technology, WinWF, Workflow
posted by Dmitri Zimin(e) @ Tuesday, May 01, 2007
0 Comments
