WF includes a core runtime engine that is represented by the WorkflowRuntime class (found in the System.Workflow.Runtime namespace). The workflow runtime is not a self-contained application. Instead, an instance of this class must be hosted by your application in order to execute and manage workflows. You host the workflow runtime and the runtime hosts the individual workflow instances. The workflow runtime is the component that provides an execution environment for the workflow instances.
The WorkflowRuntime class includes methods that permit you to configure and control the workflow runtime. By subscribing to events that are exposed by this class, you can also receive status change notifications. For example, you can receive an event notification when an individual workflow instance starts, terminates, or completes successfully.
The runtime engine provides an execution environment for your workflows. You don’t directly execute workflows within your application. Instead, you ask the runtime engine to create an instance of a workflow which you then instruct to start.
By default, workflows execute asynchronously in a thread that is managed by the runtime engine. This allows you to start multiple workflows from your host application at the same time, with all of them under the control of the runtime engine.
Each workflow can go through multiple execution states throughout its lifetime. For example, all workflows start in the created state and then move into the running state when execution begins. The workflow can also pass into states such as suspended, terminated, or completed. Other events associated with a workflow such as idled, persisted, loaded, or unloaded are possible. It is the runtime engine that manages the life and death of each workflow as it passes through these states.
The runtime engine is also responsible for scheduling and managing execution threads, workflow persistence, workflow transactions (committing of batched work), and workflow tracking. However, while the responsibility for these tasks rests with the runtime engine, it doesn’t actually handle these duties by itself. Each of these tasks has been implemented as a runtime service that you create and register with the runtime engine during application startup. This modular design permits you to swap out a default implementation in favor of one that you’ve developed.
These core services can only be added to the runtime engine before it is started. Once the StartRuntime method is called on the WorkflowRuntime object, you are no longer allowed to add core services. This restriction only applies to these core services and not to local services, which are covered in the next section.
With the exception of the Tracking service, only one instance of each type of service can be added to the runtime engine. And since these services must be added prior to starting the runtime engine, you are unable to replace a service later. However, you are allowed to create and register multiple instances of the tracking service.
With this design, Microsoft is encouraging you to implement your own services in order to customize and extend the core runtime engine. As a starting point, WF includes multiple implementations of some of the services, each one with a different behavior.