Workflow Foundation Design Concerns/Considerations?

I am reviewing this technology but have a few design concerns that made me pause a few times. Can someone help straighten me up?

1) Inside the workflow all variables are either global or activity scoped. If you want to bind them to input/output argument of an activity, then they will need to be globally scoped. And we all have dealt with managing long lasting, globally scoped variables.

My other fear 开发者_JAVA百科is that there is great temptation with such globally scoped variables that these activity can be re-arranged with little consequence, when in fact they can't be.

Also that each activity must be aware of who is setting/modifying their input values, which is actually an alias to the globally scoped variables, violating the "Tell don't ask principle".

2) Unit Testing, I can see how each activity can be tested, but I am not seeing how the workflow as a whole can be tested yet. Eg. How am I supposed to simulate the workflow sending an email when it does not receive an input from a user after 30 days? However, I'm not comfortable leaving Unit Test out of the picture entirely, since the workflow is after all a branching logic, hence complex, hence the potential for error is too great to ignore.

3) The whole workflow foundation looks so heavily coupled ie. it's persistence + workflow + expression tree builder (kinda). I wished it were a little more elegant somehow (like the reactive framework Rx), but I gotta humbly admit, I don't know a better/faster way of doing things for long running processes.

So in conclusion, finite state machine is usually complex. Especially with feature creeps (yeah seriously think about covariant and contravariant etc.) and more so on long running processes. I'm fine with using FSM for things that rarely change eg. the C# compiler, but for something that is supposed to be fluid rather than rigid like your average business requirement, I fear that there is great temptation to abuse it and thereby making the code unmaintainable. However, workflow in a business process is just so critical, it is hard to pass up on the technology.

Am I just too defensive? What's your take? How can I avoid the pitfalls?

Thanks in advance!

It appears that you're looking at WF 3.5, not WF 4.

1) Inside the workflow all variables are either global or activity scoped.

WF 4 introduces container activities that create scopes.

2) Unit Testing.

See Windows Workflow Foundation on CodePlex, especially Microsoft.Activities.UnitTesting. The book Pro WF: Windows Workflow in .NET 4.0 has examples of unit-testing activities. Remember that workflows and activities are interchangeable. See WorkflowInvoker.Invoke for one way to execute a workflow (or activity) synchronously in a unit test.

3) The whole workflow foundation looks so heavily coupled

WF 4 decoupled persistence, for one.

And yes, workflows can be abused; see The Danger of Centralized Workflows. I believe they have their place for long-running processes that involve human actors.