1.2.3 Windows Workflow运行时
从Windows Workflow的角度看，可以将工作流活动当成是交给一个工作流处理器去执行的一系列指令或操作码。在Windows Workflow中，这个处理器就是WF运行时（WF runtime）。为了启动一个工作流，我们首先需要一个宿主来承载运行时和工作流服务。
1.2.3.1 承载Windows Workflow运行时
Windows Workflow不是一个单独运行的软件。像ASP.NET那样，WF存在于多个程序集中（最重要的就是System.Workflow.Runtime.dll这个程序集）。像ASP.NET运行时那样，WF需要一个宿主进程来加载、初始化和启动它的运行时，随后才是工作流粉墨登场。然而，不同于ASP.NET那样的传统服务器端应用，WF可以在许多不同种类的宿主中运行。例如，我们可以在智能客户端应用、控制台应用或者Windows服务中承载WF。
下面的类图展示的就是在WF中执行工作流所必需的类。
为了准备工作流的执行环境，我们要先生成一个WorkflowRuntime类的实例，然后调用其StartRuntime方法。WorkflowRuntime类定义了一些可以对运行环境进行定制化的方法。该类中也定义了一些事件，我们可以在运行期间对它们进行侦听。当工作流处于结束、中止、空闲等不同状态时，运行时都会引发相应的事件。
当我们创建好了运行时的实例，就可以用它的CreateWorkflow方法来生成工作流。CreateWorkflow的返回值是一个WorkflowInstance类对象。WorkflowInstance类代表了一个单独的工作流。通过调用工作流实例对象的Start方法就可以启动这个工作流。如果出现了异常，工作流将调用Terminate方法（该方法将导致运行时抛出一个WorkflowTerminated事件）。下图展示了一个典型的调用顺序。
WorkflowRuntime和WorkflowInstance几乎是运行期间最重要的两个类，但它们不是仅有的两个类。在WF程序集中，还有其它的类为工作流运行时提供一些重要的服务。这些服务将在第5章里给予详细的说明，下面只是提供一个简短的介绍。
1.2.3.2 运行时服务
WorkflowRuntime仅仅提供了用于执行工作流的基本功能。我们在前面曾经谈到了一些应该由工作流引擎实现的重要功能，比如对运行中的工作流进行追踪的功能，以及对空闲工作流实行失活操作的功能。别担心，在WorkflowRuntime类的扩展机制——AddService方法中，这些功能都是可用的。
AddService允许我们为运行时提供一个或多个服务。这些服务可以是我们为特定的应用域编写的自定义服务，比如自定义调度服务，也可以是微软在WF中提供的现成的服务。让我们先看看目前都有哪些现成可用的服务。
调度服务
第一种调度服务能够对工作流运行时使用的那些工作流执行线程实施控制。这种服务是由DefaultWorkflowSchedulerService类实现的。通过它，我们可以创建新的工作流执行线程。因为这些线程是与宿主程序相分离的，所以工作流以异步方式执行，不会阻塞任何宿主程序的线程。工作流执行线程的最大并发数值是可以通过配置来设定的。
另一种调度服务是由ManualWorkflowSchedulerService类提供的，当宿主程序希望为工作流运行时提供线程时，我们就会用到这种服务。在ASP.NET Web应用和Web Service这类服务器端应用中，为运行时提供线程是一项非常有用的技术。服务器端应用通常每次都是从线程池中取出一个响应线程来为一个客户请求提供服务。宿主程序可以把这个响应线程继续借给WF运行时去同步地执行工作流。这种做法是有实际意义的，因为这样就不需要为每个客户请求提供2个处理线程了（译者注：一个线程响应客户请求，另一个线程执行工作流），可以降低对系统可伸缩性方面的要求。
如果WF内建的调度服务无法满足需求，你也可以自行定义调度服务。这一点对其它WF内建服务同样适用。
事务服务
事务服务，就像其名称所揭示的，能够让一个正在运行时中执行的工作流与其在持久存储器中的副本之间保持状态上的一致，这个持久存储器可以是关系型数据库。默认的事务服务是由一个DefaultWorkflowTransactionService类实例提供的。如果把一个服务提供给一个运行中的工作流实例，那么这个服务与工作流中的所有活动将共享同一个事务上下文。
WF是依靠.NET的System.Transactions命名空间来实现事务服务的。Transaction类提供了一种轻量级、自动登记、可提升的事务处理功能。它起初作为本地事务运行，如果需要的话，运行时可以在随后将其提升为一个重量级的分布性事务。
持久化服务
持久化服务负责将工作流的状态保存到持久存储器中。由SqlWorkflowPersistenceService类提供的服务可以将工作流状态存储到一个SQL Server数据库中。长期运行的工作流需要持久化，因为我们无法容忍一个发票处理工作流一直在内存中运行30天，而这期间它几乎什么也不做，只是在等待一个用户的付款到账。实际上在这种情况下，运行时会将这个工作流状态保存到持久存储器中，然后把它的实例从内存中卸载掉。在30天内（我们希望时间会更短些），运行时可以重新加载这个工作流实例并继续执行下去。如果已经配置了持久化服务，WF运行时会自动对处于空闲或挂起状态的工作流执行持久化操作。
SqlWorkflowPersistenceService类能够与SQL Server 2000或更新版本的Microsoft SQL Server（包括免费的MSDE和Express版本）协同工作。当然，我们还需要持久化服务能够识别的数据库架构。在第5章里，我们会学习如何使用.NET 3.0提供的T-SQL安装脚本来完成与持久化服务相关的数据库设置。
追踪（Tracking）服务
调度服务负责为工作流选择一个执行线程，而追踪服务则负责监视和记录工作流的执行信息。追踪服务将所需的工作流信息类型以追踪配置的形式通知给运行时。这种配置一旦建立好，追踪服务就能够打开一个追踪通道开始接收事件和数据。第5章里会有更详细的关于追踪配置和通道的内容。
WF提供了一个能够将追踪数据保存至SQL Server数据库的追踪服务类，SqlTrackingService。这个服务借助前面讨论过的事务服务来确保追踪数据与目标工作流的状态保持一致。默认情况下，运行时不会启动追踪服务，但是我们可以通过编码的方式为运行时添加这项服务（或者通过一个应用程序配置文件对追踪服务进行配置）。
到目前为止，我们已经了解了WF的所有基本功能，下面让我们开始运行工作流软件吧。
章节链接：
【翻译习作】 Windows Workflow Foundation程序开发
【翻译习作】 Windows Workflow Foundation程序开发-前言
【翻译习作】 Windows Workflow Foundation程序开发-第一章01