OdeToCode IC Logo

My Gripes with Windows Workflow

Friday, August 18, 2006

Brian Noyes' post "Understanding Windows Workflow and its complexities" has me thinking.

I know a few people who have given up on Windows Workflow altogether. WF imposes its own paradigm. If your way of thinking is different from the WF way of thinking, you are going to live in a house of pain.

Brian's first complaint is about the designer. I've found the designer to be clunky. There are behaviors you come to expect in Visual Studio, like being able to double-click somewhere and have the designer perform some work. The WF designer never acts intuitively. There are also places where the behavior seems inconsistent - some properties permit data binding and some properties do not. It's not until you learn about dependency properties and meta-properties that this behavior make sense.

Brian's third point was about the HandleExternalEvent activity. Setting up communications between a workflow and its host is a tremendous amount of work, and it's easy to get wrong (a working title for my InfoQ article was "How To Screw-up the HandleExternalEvent activity"). The work doesn't payoff until you see an event arrive for a workflow that has been living in a database table for 8 days. The runtime can re-load the correct workflow and still deliver the event! It's amazing to see this happen, but requires a lot of work to get there.

There are some common gotchas in WF programming:

1) Spawned execution contexts. The rule is that an activity executes once and only once. If you write code that forgets this rule, it's going to hurt!

2) Serialization. You don't need database persistence to see exceptions from the BinarySerializer - spawned execution contexts also make a deep copy of activities using serialization. Make sure those custom properties are serializable!

3) Transactions. It's easy to get MSDTC involved in heavy duty transactions with WF. Just using a persistence service and transactional tracking service at the same time will get the DTC involved (unless a special SharedConnectionWorfklowCommitWorkBatchService is added to the runtime). Something makes me nervous when a class name has 46 characters.

WF isn't as easy as it first appears. It's powerful, but requires an investment of time.  

Thomas Wagner Friday, August 18, 2006
We looked at WWF a while back for use as an action framework and it ended up being the equivalent of an 18 wheeler when all we needed was a little pick-up truck. It does seem like there were a bunch of programmers at MS with nothing to do except to write this huge thing.
scott Monday, August 21, 2006

the good news is that MS is dogfooding WF - it will be used by MOSS, BizTalk, and Speech Server.
Simon Ince Tuesday, August 22, 2006

Interesting thoughts - especially your conclusion comment of "WF isn't as easy as it first appears. It's powerful, but requires an investment of time."

I think that sums it all up for me. I've just posted some similar thoughts...

Gravatar Patrick Parker Saturday, July 17, 2010
WF really is a paradigm shift. I have seen quite a few customers attempting to apply a traditional coding model and know how in the workflow world and the shoehorning process is painful to watch. Once they do make a mental switch though it is like a new religion - everything is possible and everything starts looking like a workflow. We make a complete .NET WF development studio and server platform that solves almost all of the gripes that we had and have heard about. It will be offering a community edition and site soon so please check it out.


Comments are closed.