Jon Flanders weights in on the complexity of Windows Workflow Foundation, saying he disagrees with some of the points raised by Brian and Scott. I think he exaggerates a little bit when he says we think it is too complex, I just said it was complex :-).
While Jon raises many good points, I don't quite buy his argument. Seems to me he's saying WF is simple bacause, well, it behaves as it was supposed to behave based on the design the WF team chose for the product. Jon does raise the very good point that, as any other technology, you have to understand it in order to use it effectively, which is something I do agree with (see? we do agree on something! ;-)).
However, I'll like to explain my comments on WF complexity a little more (though I know it's something Jon and I disagree on). I expected WF to be a complex technology, because the underlying problem domain is complex. And for what it's worth, complexity is not bad, and I personally happen to like a lot about WF.However, I don't think that going for this complexity is warranted in everycase, which seems like it is what MS is advocating when they raised the "Workflow is Everywhere" mantra. For example, I happen to think that going for the complexity of WF for your website navigation (PageFlows) is unwarranted in most cases, unless you have some seriously complex scenarios to tailor to. There will definitely be a need for good architectural guidelines as to when going with WF is really a good investment.
But besides that, my main concern with WF is that it is deceptively simple. Windows Workflow Foundation, for better or worse, is an extremely leaky abstraction, and it shows in several places. In particular, the WF programming model makes it seems as if programming WF was actually simpler than it really is, and manages to hide some crucial aspects of the WF behavioral model so that you might not be aware of them until it is too late and you're about to hit a brick wall at a 100MPH. But let's bring some clear examples of this:
Spawned Contexts
Scott and Jon brought the Spawned Contexts concept to the table, with Jon saying that they are a very important part of the model. I agree, they are. They are also a direct consequence of the WF design around workflow definitions being prototype instances of the workflow at runtime, and the persitency requirements of workflow. Spawned Contexts are not a problem per se, and they are actually a pretty clever solution to the problems they solve.
The real problem is that nothing in the WF programming model forces you to be aware of Spawned Contexts.It is incredibly easy to write code (both in a simple workflow as well as in custom activities) that will appear to work fine at first but that later completely breaks down when spawned contexts are introduced into the mix. The other part of the equation is that it's also not very clear from just looking at a workflow definition what will introduce spawned contexts into the workflow. Sure, perhaps you spot a ReplicationActivity or a WhileActivity, but with the introduction of complex custom activities whose implementation you are not aware of it might not be so easy.
Serialization and Extensibility
Jon has talked quite a bit on the serialization requirements of workflows and custom activities. I think this is one of those aspects to add to the apparent complexity of WF, and it's again one of those aspects where the programming model fails short; this time in the name of extensibility.
The default workflow persistence services in WF depend on runtime serialization (i.e. System.Runtime.Serialization.*) to persist workflow instances. This is just fine, and in fact happens to be very similar to the model used by BizTalk server, which also requires you to ensure you make things serializable (unless you introduce atomic scopes). However, unlike BizTalk, with WF this is just one possible persistence model.
You could potentially create a replacement persistence service that saves workflow instances using a mechanism different from runtime serialization. This is a good thing. It's a good example of how extensible the WF runtime is and how powerful the service-based mechanism on which the WF runtime is based is. However, this comes at a price in complexity: Since the Serialization-based persistence model is just one possible model, and it isn't even required, then the design time experience for workflows and activities again does not force you to play by the rules. It is very easy to end up with non-serializable workflows and activities (particularly since the .NET based model on which WF based makes things non-serializable by default).
Again, you wouldn't notice this at all until things break down on you at runtime, maybe in unexpected ways. At least with BizTalk you had the serialization requirements clearly stated and verified at compile time.
Now, Jon says that this could be worked around by creating our own workflow and activitity Validators. Again, this is a testament of how extensible the WF model is. Problem is, I'm a lazy bastard and I don't want to have to create those myself. Plus, I can't rely on everyone around implementing their own validators for this, nor can I rely on everyone remembering to put their own stuff through the kind of tests that will ensure things work fine with workflow persistence. And that impacts what trust I will put on third party stuff (such as third party activities) meant to be used with WF.
Event Driven
Event driven activities are very important in WF, particularly if you're interested in State-Machine workflows (one of the coolest WF features by far!). However, writing good event-driven activities in WF isn't quite as trivial as one would expect, and it can be a little daunting. I know I did have to wade through a lot of reflection to be able to understand the low-level model behind it! Again, nothing wrong with that, but it is complex.
Conclusion
I could certainly bring on more examples about WF complexity. But, I'd like to close with a different theme: Complexity is not wrong. Perhaps I wasn't clear before but I don't think that the fact that WF is complex is a bad thing per se and that it was crappy. It isn't.
I happen to think WF is the more interesting technology (and the one with more potential) from the holy .NET FX 3 trinity, and I'm very excited by the capabilities it brings to the table and the extensiblity model. However, I also think that precisely because of this, more architectural and development guidelines will be needed to make sure we can take advantage of it in the best possible way. And a lot of help from the community will be needed to ensure that people know the gotchas and tricks of the technology so they don't crash and burn while creating their WF-based systems. I'm also very looking forward to when (I'm assuming there's no question of if!) BizTalk starts hosting WF.
