The workflow runtime is just a class, you create a instance of the class in your application, make it a static or global, so the instance live through all the live of your application, in this case, your application is hosting the workflow runtime. In fact your application can create more than one runtime. However, you typically won't need to do that. A single instance of the workflow runtime is capable of managing the execution of multiple workflow instances. One possible reason to create multiple runtime instances in a single appDomain would be if each instance required a different set of conflicting runtime services or configuration settings. You can also extend the WorkflowRuntme class to initialize the runtime engine.

Beginning with .NET 3.5, Microsoft has added the ability to expose workflow instances as WCF services. To implement this, they developed a hybrid workflow runtime class named WorkflowServiceHost (found in the System.ServiceModel namespace and packaged in the System. WorkflowServices assembly). This class combines the basic capabilities of WorkflowRuntime (it hosts workflow instances) with ServiceHost (a WCF class that exposes services to clients). Use WorkflowServiceHost when you implement your own service host application instead of using Internet Information Services (IIS) or Windows Activation Services (WAS).

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.

Included in the runtime engine is a flexible rules evaluation engine. This engine is able to evaluate simple rule conditions such as those that you add to an IfElseActivity or WhileActivity. Or it can handle a complex set of rules (called a RuleSet) that you specify within a PolicyActivity. A RuleSet defines multiple rules that are evaluated in sequence and automatically reevaluated based on the actions of rules later in the set.

The workflow runtime engine also exposes several public events that can be handled by the host application. These events allow you to directly monitor the status of each workflow as it passes between execution states. Each event carries with it an instance of the WorkflowInstance class. This class acts as a proxy to the real workflow instance that is managed by the runtime engine.

<img style="cursor:pointer; cursor:hand;width: 400px; height: 274px;" src="http://1.bp.blogspot.com/_yUba7cqllFE/ST6VM4W1nNI/AAAAAAAAAPo/CJjSe5DJf3k/s400/wf+runtime.PNG" border="0" alt=""id="BLOGGER_PHOTO_ID_5277819861843942610" />