Windows Workflow scheduling services manage how workflow instances are scheduled by the workflow runtime engine. Whether they are handled in an asynchronous manner through the DefaultWorkflowSchedulerService, or in a manual, synchronous manner through the ManualWorkflowSchedulerService, these services are an important part of your workflow solution.

The application I'm working on right now uses ManualWorkflowScheduler, so I needed to figure out the exact differences between the two scheduler, luckily MSDN actually offers pretty clear documentation:

Default Workflow Scheduler Service

DefaultWorkflowSchedulerService is used by the workflow runtime engine by default. It creates and manages the threads that run workflow instances in an asynchronous manner on the workflow runtime engine. Workflows that are waiting to run are stored in the internal queue of the DefaultWorkflowSchedulerService . When the DefaultWorkflowSchedulerService wants to start a workflow, a thread is acquired from the .NET Framework thread pool and used to run the workflow. The MaxSimultaneousWorkflows property determines how many simultaneous threads the scheduler service will allow at one time. If the limit is four, for example, the DefaultWorkflowSchedulerService will acquire up to four threads from the .NET Framework thread pool to execute the workflows. If four workflows are already running, additional work items (workflows) are placed in the queue and eventually executed as threads become available. The following figure shows how the DefaultWorkflowSchedulerService executes workflows in an asynchronous manner.

You can set the maximum number of workflow instances that can be active at any one time by passing a parameter to the DefaultWorkflowSchedulerService constructor or by using an application configuration file. Task 1: Configure Runtime Services Using Code shows how to configure the DefaultWorkflowSchedulerService class by using the constructor. Task 2: Configure Runtime Services using App.Config shows the same configuration of the DefaultWorkflowSchedulerService but uses an application configuration file.

Manual Workflow Scheduler Service

The ManualWorkflowSchedulerService provides a threading service that enables the host application that creates a workflow instance to donate the Thread on which the workflow instance is run. Using this threading service, host applications can run a workflow instance on a single Thread (that is, in synchronous mode). This mode blocks the execution of the host application until the workflow instance becomes idle. Subsequently, the workflow instance can only be executed by using the RunWorkflow method of this service.

Alternatively, the workflow can be run on a thread created by a .NET timer by setting the useActiveTimers constructor parameter to true. When this timer expires, the workflow is executed on the timer's thread, rather than the host application's thread. This timer is implemented as a DelayActivity activity.

ManualWorkflowSchedulerService controls the number of threads spawned in an ASP.NET process by reusing the thread that made the ASP.NET Web request to run the workflow instance. This ensures that at any time, the number of active threads in the workflow runtime equals the number of active Web requests in the ASP.NET process.

ManualWorkflowSchedulerService does not automatically run a workflow instance that is in the queue. The host must call RunWorkflow to run a specified workflow.