Brian Noyes postes here about the complexities in developing for Windows Workflow Foundation. In general, I have to agree with his sentiment. Workflow in general is not trivial and requires approaching it with a somewhat different mindset, and it's no different with Workflow Foundation.
Some of what Bryan talks about is caused in part by this conceptual model differences, and partly just because of the way WF works. But, up to a point, most of what he mentions is just the superficial issues. Things get far more complex once you start diving deeper into it, and there are quite a few issues that will bite you if you're not aware of the WF model.
Some examples:
- The execution model is not exactly trivial (though it is extremely powerful). It has several points that are not very intuitive and the overal design-time experience might make you feel it should work different than what it actually does. For example:
- WF workflows (or rather activities) basically operate as prototype definitions at runtime. This can cause issues when manipulating properties, so you need to be careful to ensure you are manipulating the executing instance and not the prototype instance.
- The WF execution model and thus the behavior of running workflows can be substantially affected by what services are configured in the WF runtime. This can be quite surprising in some scenarios and can easily break your workflow definitions.
- The threading model in WF is far more complex than your regular .NET code (which is expected), but since there are multiple alternative scheduling services, they can also affect how your workflow definitions get executed with sometimes surprising results.
- The extensibility model in WF is pretty amazing, and how the runtime is completely supported by a set of configurable and extensible services is one of the really strong points in WF. However, it also adds a lot to the complexity because what you tested and worked under one configuration might very well not work under another and it also means you need to be aware of the type of workflow you're building and the activities you're using and what services they require.
- Even with the Activity Binding facilities in WF (which are really cool), no-code (or little-code) workflows are still hard, and people will tend to escape this by using a lot of CodeActivities and event handlers to hook things together through code. This has both advantages and disadvantages.
- Creating new activities is easy. Creating good activities can be pretty hard.
None of this retracts overall from the WF platform; it's still a pretty important part of the .NET FX 3 platform; it just means you need to be well informed about what you're getting into if you decide to take advantage of it. At the end, it ain't no silver bullet.
