Windows Workflow: Scheduler and Threads
I dont think the world has seen so much emphasis on a feature of product even before pre-launched. In this context, I am talking about _WF_ and the emphasis on a non-feature, actually - that it is a non-product and it doesnt come with batteries host included.
Windows Workflow consists of an activity library and a framework, a runtime engine, and a runtime services components. Most of these will work out-of-the-box and some of them comes with extensibility mechanisms which you can further enhance or customize on.
All of those must run within a host application process - which you have to build.
In other words, Windows Workflow is just a framework with managed APIs and not a designed as a product. It would be a lot of work to build your own host, which is why I wouldnt recommend it. You can implement workflows in existing hosts such as IIS6 or a Windows NT Service or soon-to-be-shipped - WAS in IIS7.
That said, if you want ready hosts of domain-specific workflows with user-customizability, you can always look at Windows Sharepoint Services v3.0. I believe BizTalk 2008 will be a host for Windows Workflows when it ships as well.
Anyways, one of the key points that confuse many developers is how workflow instances are scheduled by the workflow runtime engine. There are 2 ways - via a Synchronous and an Asynchronous approach. Both of them are implemented via the ManualWorkflowSchedulerService and DefaultWorkflowSchedulerService respectively.
Obviously, if you dont tinker with the WorkflowRuntime with regards to the Scheduling Services, it will use the DefaultWorkflowSchedulerService service. It creates and manages the threads that run workflow instances in an asynchronous manner on the runtime engine and it supports multiple workflow instances queued in the runtime thread pool. In other words, this default scheduler will automatically queue the workflow to run on a thread from the process-wide CLR thread pool. With this default setting on the WorkflowRuntime, the workflow will always execute asynchronously on a different background thread which, in turn, explains why so many of the SDK samples waits for the workflow to finish by blocking the main thread with an AutoResetEvent.
However, you can use the ManualWorkflowSchedulerService if you crave for synchronous execution of workflow instances. The workflow instances are executed on the calling thread from the host application, thus blocking the execution of the host application until the workflow instance becomes idle. To do so, the host must donate threads to the workflow runtime, which will then use this donated thread to execute a workflow.
Running a workflow with the ManualWorkflowSchedulerServic is slightly different as well. It involves a two-step process. First, you call Start on the workflow instance. But that is not enough as it only prepares the runtime for this instance and does not actually run the workflow. We have to be more explicit by calling RunWorkflow and passing the Workflow's Instance ID. This is how a thread is donated by the host. The WorkflowRuntime will then use this calling thread to execute the workflow synchronously. In other words, the workflow instance will execute on the same thread as the calling program.
Subtle differences, but understanding it will enable the use of the right tool to do the right job.
