此文是从msdn中摘录而来，并经过相关的提炼，主要介绍了WF的基础知识点，希望对大家有所帮助。本文主要包括以下11个方面：

　　1 工作流概述 ：工作流是一组存储为模型的名为活动的基本单元，活动用于描述实际进程。工作流运行时引擎用来创建和维护工作流实例的。

　　2 活动概述：活动是工作流的基本单元，可以执行单个操作，也可以是一组复合的活动。活动在其生存期内有六种状态：Initialized, Executing, Canceling, Closed, Compensating, Faulting。

　　3 服务概述 ：工作流运行的时候，需要各种服务，主要包括：计划服务（创建和管理在工作流运行时引擎以异步/同步的方式运行工作流实例的线程）；CommitWorkBatch服务（启用与提交工作批次相关的自定义逻辑） 持久性服务（满足长时间才能完成的工作流，将工作流暂时从内存转移到硬盘）；跟踪服务（宿主通过捕获工作流执行期间引发的事情，以观察到工作流实例，可以采用将信息入库、输出到控制台等多种方式）。

　　4 补偿概述 ：主要用于发生异常时的撤销。

　　5 本地通信和关联概述 ：解决宿主进程同工作流或工作流中特定活动通信的问题而提出的两个概念。

　　6 持久性概述 ：从内存中卸载工作流，而且工作流可以序列化为持久性存储。

　　7 跟踪概述 ：捕获有关工作流实例的信息，并在这些实例执行时存储该信息。

　　8 序列化概述 ：对工作流、活动和规则可以进行序列化和反序列化。

　　9 工作流更改概述： 可以在运行时动态更新工作流实例和声明性规则，不必重新编译和重新启动工作流。

　　10 “规则和条件”概述： Windows Workflow Foundation 可将业务逻辑作为规则或条件来实现，使用工作流更改来执行动态更新，可在运行时修改这些规则和声明性条件。

　　11 错误处理概述 ：Windows Workflow Foundation 中的错误处理指的是以异步方式处理异常。

　　12 工作流标记概述 ：采用XAML，使开发人员和设计人员以声明的方式为业务逻辑建模。

　　Windows Workflow Foundation 是编程模型、引擎和工具，用于在windows上快速生成启用工作流的应用程序。它包括一个命名空间、一个进程内工作流和多个VS2005设计器。

　　Windows Workflow Foundation 是一个框架，让用户可以在其为Windows Vista、Windows XP和Windows Server 2003 系列编写的应用程序中创建系统或人工工作流。

　　Windows Workflow Foundation 可用于解决简单方案，如根据用户输入显示UI控件，或用于解决大型企业遇到的复杂方案，如订单处理和库存控制。

　　Windows Workflow Foundation 可以处理的方案包括：

　　在业务线应用程序中启用工作流

　　用户界面页流

　　以文档为中心的工作流

　　人工工作流

　　面向服务应用程序的复合工作流

　　业务规则驱动的工作流

　　系统管理的工作流

　　Windows Workflow Foundation 提供了与其他 .NET Framework 3.0 技术（如 Windows Communication Foundation 和 Windows Presentation Foundation）一致和熟悉的开发体验。 Windows Workflow Foundation API 完全支持 Visual Basic .NET 和 C#、专用工作流编译器、在工作流中调试、图形工作流设计器，并支持完全用代码或标记开发工作流。 Windows Workflow Foundation 还提供了可扩展模型和设计器，用于生成为最终用户或跨多个项目重用封装工作流功能的自定义活动。

　　1 工作流概述

　　工作流是一组存储为模型的名为活动的基本单元，活动用于描述实际进程。 工作流提供了一种方法，用于描述多项短期运行或长期运行的工作之间的执行顺序和依赖关系。 此工作从头到尾地贯穿模型，并且活动可以人工执行或由系统功能执行。

　　工作流运行时引擎

　　每个正在运行的工作流实例都是由进程中运行时引擎创建和维护的，该引擎通常称为“工作流运行时引擎”。 在一个应用程序域中可以有多个工作流运行时引擎，并且运行时引擎的每个实例均可支持多个并发运行的工作流实例。

　　工作流模型经过编译后，可以在包括控制台应用程序、基于窗体的应用程序、Windows 服务、ASP.NET 网站和 Web 服务在内的任意 Windows 进程中执行。 由于工作流是在进程中承载，因此工作流可以轻松地与其宿主应用程序通信。

　　下面的插图显示了如何在一个宿主应用程序的进程中同时承载工作流、活动和工作流运行时引擎。

　　2 活动概述

　　活动是工作流的基本单元。 以编程方式将活动添加到工作流中，与向根节点添加 XML DOM 子节点的方式类似。 当给定流路径中的所有活动都完成运行时，工作流实例即完成。

　　活动可以执行单个操作，如向数据库写入值，也可以执行复合活动并包含一组活动。 活动有两种行为类型：运行时和设计时。 运行时行为在执行时指定操作。 设计时行为在设计器中显示时可以控制活动的外观及其交互。

　　Windows Workflow Foundation 包括一个标准活动库，并为您提供创建自己的活动的机制。 这支持工作流之间的扩展性和可重用性。

　　Windows Workflow Foundation 包含一组默认活动，这些活动提供了有关控制流、条件、事件处理、状态管理以及与应用程序和服务通信的功能。 在设计工作流时，可以使用 Windows Workflow Foundation 提供的活动，并且可以创建自己的自定义活动。

　　活动是工作流的基本构造块。 工作流是一组以树状结构分层组织的活动。 活动表示工作流中的操作。 它可以是延迟之类的简单操作，也可以是由多个子活动组成的复合活动。

　　与工作流一样，活动可以是顺序的，这意味着其操作顺序在设计时指定。 活动也可以是事件驱动的，这意味着其操作顺序是在运行时为响应外部事件而确定的。

　　每个活动都有一个活动执行上下文，它表示活动的执行环境。 活动执行上下文类似于 HTTP 上下文：对象具有状态、一组参数以及它在给定时间点所独有的构造。 某些复合活动（如 ReplicatorActivity 活动和 WhileActivity 活动）会在执行期间创建其子活动的多个实例，每个子活动都有其自己的活动执行上下文作为其运行环境。有关活动执行上下文的更多信息，请参见了解活动执行上下文。

　　ActivityExecutionContext (AEC) 是在宿主应用程序调用 Start 方法时为活动创建的执行环境。

　　AEC 提供了一种复合活动，该复合活动具有执行 (ExecuteActivity) 或取消 (CancelActivity) 子活动的能力。 它也可以通过 CloseActivity 方法来关闭自己。 这些是仅有的父活动可以通过 AEC 控制的执行状态更改。 所有其他活动状态都是由工作流运行时引擎控制的。

　　AEC 具有名为 ExecutionContextManager 的属性，使其可以生成新 AEC。 这些 AEC 是父活动（如 WhileActivity 活动、ReplicatorActivity 活动或 ConditionedActivityGroup 活动）每次运行其子活动超过一次时生成的。 每次迭代都使用其自己的 AEC 创建一个克隆的活动，因此子活动的这些不同实例可以独立运行（而对于 ReplicatorActivity 活动则可能并行运行）。

　　此外，ActivityExecutionContextManager 恢复保持的上下文和完成的上下文，其中所有活动处于 Closed 或 Initialized 状态，并具有可选的持久性。AEC 只有在其相关活动处于 Closed 或 Initialized 状态时才能完成。

　　活动只有在生成的所有执行上下文 (CreateExecutionContext) 都已完成 (CompleteExecutionContext) 时才能关闭。 违反此行为将导致工作流运行时引擎引发异常。

　　了解活动状态模型

　　活动在其生存期内可以有六种状态。 这些状态分别为 Initialized、Executing、Canceling、Closed、Compensating 和 Faulting。

　　在 Initialized 状态期间，将为活动创建 ActivityExecutionContext，并将执行特定于该活动的其他初始化详细信息。 例如，某些 Windows Workflow Foundation 活动（如 SuspendActivity）会在初始化期间检查其是否具有父级复合活动。当某个活动进入 Executing 状态时，将会执行该活动的主要功能。 活动的 Canceling 状态可以由父活动显式置入，也可以因为在执行该活动期间引发异常而置入。 Closed 状态是活动的最后和最终状态。 需要注意的一个问题是，如果某活动成功完成，但根据业务逻辑随后必须经过 Compensating 活动。 因此，该活动将会从 Closed 转换到 Compensating，然后在完成补偿逻辑后转换回 Closed。 有关补偿的更多信息，请参见在工作流中使用补偿和使用 CompensateActivity 活动。如果在活动的 Executing 状态、Canceling 状态或 Compensating 状态期间引发异常，活动将转换到 Faulting 状态。

　　下面的流程图演示了活动如何在各种活动状态之间转换。

　　红色实线表示工作流运行时引擎负责将活动从 Initialized 状态转换到 Executing 状态，或从 Closed 状态转换到 Compensating 状态。

　　黄色实线表示父活动负责将子活动从 Executing 状态转换到 Closed 状态。 如果您创建自定义复合活动，则必须亲自进行处理。

　　蓝色实线表示工作流运行时引擎负责将活动从 Executing、Canceling 或 Compensating 状态转换到 Faulting 状态。

　　黄色虚线表示工作流运行时引擎负责将活动从 Canceling 状态、Compensating 状态或 Faulting 状态转换到 Closed 状态。

　　注意:

　　活动不能从 Closed 状态转换到 Executing 状态。 如果试图进行转换，将会在调用 Execute 时引发异常。

　　仅当所有子活动都处于 Closed 或 Initialized 状态时，才能关闭活动。 由于这是一条递归规则，因此意味着试图关闭的活动下面的整个树必须为 Closed 或 Initialized 状态，调用才会成功。

 

活动	说明
CallExternalMethodActivity	与 HandleExternalEventActivity 活动一起使用，以实现与本地服务之间的输入和输出通信。 有关更多信息，请参见使用 CallExternalMethodActivity 活动。
CancellationHandlerActivity	用于包含在复合活动的所有子活动执行完毕之前取消的复合活动的清理逻辑。 有关更多信息，请参见使用 CancellationHandlerActivity 活动。
CodeActivity	可用于向工作流中添加 Visual Basic 或 C# 代码。 有关更多信息，请参见使用 CodeActivity 活动。
CompensatableSequenceActivity	SequenceActivity 的可补偿版本。 有关更多信息，请参见使用 CompensatableSequenceActivity 活动。
CompensatableTransactionScopeActivity	TransactionScopeActivity 的可补偿版本。 有关更多信息，请参见使用 CompensatableTransactionScopeActivity 活动。
CompensateActivity	可用来调用代码以撤消或补偿在发生错误时已由工作流执行的操作。 有关更多信息，请参见使用 CompensateActivity 活动。
CompensationHandlerActivity	为已完成的 TransactionScopeActivity 活动执行补偿的一个或多个活动的包装。 有关更多信息，请参见使用 CompensationHandlerActivity 活动。
ConditionedActivityGroup	根据应用于 ConditionedActivityGroup 活动本身的条件以及分别应用于每个子活动的条件来执行子活动。 有关更多信息，请参见使用 ConditionedActivityGroup 活动。
DelayActivity	可用于在工作流中根据超时间隔建立延迟。 有关更多信息，请参见使用 DelayActivity 活动。
EventDrivenActivity	包装在指定事件发生时执行的一个或多个活动。 有关更多信息，请参见使用 EventDrivenActivity 活动。
EventHandlersActivity	提供一个用于将事件与活动关联的框架。 有关更多信息，请参见使用 EventHandlersActivity 活动。
EventHandlingScopeActivity	将其主要子活动与 EventHandlersActivity 活动并发执行。 有关更多信息，请参见使用 EventHandlingScopeActivity 活动。
FaultHandlerActivity	用于处理指定类型的异常。 有关更多信息，请参见使用 FaultHandlerActivity 活动。
FaultHandlersActivity	表示一个复合活动，它有一个由类型为 FaultHandlerActivity 的子活动组成的有序列表。 有关更多信息，请参见使用 FaultHandlersActivity 活动。
HandleExternalEventActivity	与 CallExternalMethodActivity 活动一起使用以实现与本地服务之间的输入和输出通信。 有关更多信息，请参见使用 HandleExternalEventActivity 活动。
IfElseActivity	测试每个分支条件，在第一个条件为 true 的分支上执行活动。 有关更多信息，请参见使用 IfElseActivity 活动。
IfElseBranchActivity	表示 IfElseActivity 活动的一个分支。 有关更多信息，请参见使用 IfElseBranchActivity 活动。
InvokeWebServiceActivity	使工作流能够调用 Web 服务。 有关更多信息，请参见使用 InvokeWebServiceActivity 活动。
InvokeWorkflowActivity	使工作流能够调用其他工作流。 有关更多信息，请参见使用 InvokeWorkflowActivity 活动。
ListenActivity	只包含 EventDrivenActivity 子活动的复合活动。 有关更多信息，请参见使用 ListenActivity 活动。
ParallelActivity	用于计划将两个或更多个 SequenceActivity 子活动分支同时进行处理。 有关更多信息，请参见使用 ParallelActivity 活动。
PolicyActivity	用于表示一个规则集合。 规则由条件和引起的操作组成。 有关更多信息，请参见使用 PolicyActivity 活动。
ReplicatorActivity	创建单个子活动的多个实例。 有关更多信息，请参见使用 ReplicatorActivity 活动。
SequenceActivity	提供一种将多个活动链接在一起以顺序执行的简单方法。 有关更多信息，请参见使用 SequenceActivity 活动。
SetStateActivity	指定到新状态的转换。 有关更多信息，请参见使用 SetStateActivity 活动。
StateActivity	表示状态机工作流中的一个状态。 有关更多信息，请参见使用 StateActivity 活动。
StateFinalizationActivity	在 StateActivity 活动中用作容器，以容纳在离开 StateActivity 活动时执行的子活动。 有关更多信息，请参见使用 StateFinalizationActivity 活动。
StateInitializationActivity	在 StateActivity 活动中用作容器，以容纳在进入 StateActivity 活动时执行的子活动。 有关更多信息，请参见使用 StateInitializationActivity 活动。
SuspendActivity	挂起工作流的操作，以便能够在出现某种需要特别注意的错误情况时进行干预。 有关更多信息，请参见使用 SuspendActivity 活动。
SynchronizationScopeActivity	在同步域中按顺序执行所包含的活动。 有关更多信息，请参见使用 SynchronizationScopeActivity 活动。
TerminateActivity	可用于在发生错误情况时立即结束工作流的操作。 有关更多信息，请参见使用 TerminateActivity 活动。
ThrowActivity	可用于捕获作为工作流的过程元数据的一部分引发的业务异常。 有关更多信息，请参见使用 ThrowActivity 活动。
TransactionScopeActivity	提供一个用于事务和异常处理的框架。 有关更多信息，请参见使用 TransactionScopeActivity 活动。
WebServiceFaultActivity	用于对 Web 服务错误的发生进行建模。 有关更多信息，请参见使用 WebServiceFaultActivity 活动。
WebServiceInputActivity	接收来自 Web 服务的数据。 有关更多信息，请参见使用 WebServiceInputActivity 活动。
WebServiceOutputActivity	响应对工作流发出的 Web 服务请求。 有关更多信息，请参见使用 WebServiceOutputActivity 活动。
WhileActivity	使工作流能够在条件得到满足之前进行循环。 有关更多信息，请参见使用 WhileActivity 活动。

　　3 服务概述

　　当工作流实例运行时，工作流运行时引擎使用多种服务。 Windows Workflow Foundation 提供可满足多种应用程序需要的运行时服务的默认实现，例如在 SQL 数据库中存储工作流实例的执行详细信息的持久性服务。 这些服务组件是可插入的，这样，应用程序就可以以特定于执行环境的方式提供这些服务。运行时引擎使用的其他类型服务包括计划服务、事务服务和跟踪服务。

　　通过从基服务类派生可以创建自定义服务以扩展 Windows Workflow Foundation 平台。使用 XML 文件而不使用数据库进行存储的持久性服务就属于这种情况。

　　Windows Workflow Foundation 提供了多项服务，您的应用程序可以使用这些服务来执行以下操作：通过事务执行批处理工作、管理工作流实例的线程、将工作流实例保留到存储介质中以在日后进行检索，以及跟踪工作流实例的执行情况。

　　Windows 工作流计划服务

　　Windows 工作流计划服务管理工作流运行时引擎计划工作流实例的方式。 无论这些服务是通过 DefaultWorkflowSchedulerService 以异步方式处理的，还是通过 ManualWorkflowSchedulerService 以手动、同步的方式处理的，它们都是工作流解决方案的重要部分。

　　默认情况下，DefaultWorkflowSchedulerService 由工作流运行时引擎使用。它创建和管理在工作流运行时引擎上以异步方式运行工作流实例的线程。 等待运行的工作流存储在 DefaultWorkflowSchedulerService 的内部队列中。 当 DefaultWorkflowSchedulerService 要启动工作流时，从 .NET Framework 线程池中获取一个线程并使用此线程运行工作流。 MaxSimultaneousWorkflows 属性确定调度程序服务同一时间允许的并发线程数。例如，如果限值为 4，则 DefaultWorkflowSchedulerService 将从 .NET Framework 线程池中最多获取 4 个线程来执行工作流。如果已经运行 4 个工作流，则其他工作项（工作流）将放入队列中，最终在线程可用时执行。 下图演示 DefaultWorkflowSchedulerService 如何以异步方式执行工作流。

　　

　　ManualWorkflowSchedulerService 提供了一个线程服务，该服务允许创建工作流实例的宿主应用程序指定用于运行工作流实例的 Thread。 使用此线程服务，宿主应用程序可在单个 Thread 上运行一个工作流实例（即处于同步模式）。 此模式将阻止宿主应用程序的执行，直到工作流实例进入空闲状态。 随后，只能通过使用此服务的 RunWorkflow 方法执行工作流实例。或者，可以通过将 useActiveTimers 构造函数参数设置为 true，在 .Net 计时器创建的线程上运行该工作流。如果此计时器过期，将在该计时器的线程（而不是宿主应用程序的线程）上执行该工作流。 此计时器作为 DelayActivity 活动来实现。

　　ManualWorkflowSchedulerService 通过重用一个线程（该线程发出 ASP.NET Web 请求以运行该工作流实例），对 ASP.NET 进程中生成的线程数进行控制。 这确保了工作流运行时中的活动线程数在任意时候都等于 ASP.NET 进程中的 Web 活动请求数。

　　ManualWorkflowSchedulerService 不会自动运行队列中的工作流实例。宿主必须调用 RunWorkflow 来运行指定的工作流。

　　Windows 工作流 CommitWorkBatch 服务

　　Windows 工作流 CommitWorkBatch 服务的用途是启用与提交工作批次相关的自定义逻辑（又称作持久性点）。 当提交工作批次时，运行时将对当前 CommitWorkBatch 服务进行调用并传递委托，该委托可以对工作批次执行实际提交。运行时仍必须执行提交，但是它允许服务将自身插入到进程中，从而支持针对提交进程进行一些自定义。

　　DefaultWorkflowCommitWorkBatchService 服务的目的在于允许自定义逻辑提交工作批次（又称作持久点）。当提交工作批次时，工作流运行时将对 DefaultWorkflowCommitWorkBatchService 服务进行调用并为其提供委托，调用该委托可以对工作批次执行实际提交。运行时仍必须执行提交；但是它允许该服务将自身插入到进程中，以便根据提交进程进行自定义。

　　DefaultWorkflowCommitWorkBatchService 服务唯一的真正要求是：在调用它的 CommitWorkBatch 方法时，如果不存在事务，则将创建一个事务。 如果事务不存在（当 Current 属性返回 null 时会发生这种情况），DefaultWorkflowCommitWorkBatchService 必须在调用 CommitWorkBatchCallback 委托之前创建一个事务并设置环境事务。 这是通过用 TransactionScope 包装委托调用来完成的。

　　使用此服务类型的主要目的在于启用自定义的错误处理逻辑。 如果该事务由 DefaultWorkflowCommitWorkBatchService 服务拥有，那么，由于它会在 Current 返回 null（在 Visual Basic 中为 Nothing）时创建一个事务，因此它可以多次调用委托，并为每个调用创建一个新事务。 一个最常见的示例就是处理间歇性网络问题或 SQL 群集故障转移。 如果在调用 CommitWorkBatchCallback 时引发异常，则 WorkflowCommitWorkBatchService 可以捕获此异常、启动新事务并再次调用委托。 这为工作流实例执行提供了一定的弹性，否则将导致工作流终止。

　　注意:

　　如果当前的环境事务是由 WorkflowCommitWorkBatchService 服务创建的，则该服务只能重试提交。 如果在运行时调用 CommitWorkBatch 方法时已经存在环境事务，则意味着某个其他对象拥有该事务，并且可能已对它执行了某些工作。由于 DefaultWorkflowCommitWorkBatchService 服务不能重新生成外部工作，因此它重试提交无效。 TransactionScopeActivity 事务或者在调用 Unload 方法之前由宿主代码创建的事务就是这样的示例。

　　也可以选择使用 SharedConnectionWorkflowCommitWorkBatchService 服务。 此服务用于在不同对象之间使用共享连接的数据库事务。 若要在 WorkflowRuntime 实例中使用 SharedConnectionWorkflowCommitWorkBatchService 服务而不是 DefaultWorkflowCommitWorkBatchService 服务，请使用 AddService 方法，如下例所示。 SharedConnectionWorkflowCommitWorkBatchService 构造函数的参数是数据库连接字符串。

　　注意:

　　如果 SharedConnectionWorkflowCommitWorkBatchService 服务所用的 SQL Server 已关闭（例如由于 SQL 群集故障转移或间歇性网络问题所致），则 SharedConnectionWorkflowCommitWorkBatchService 服务将重试提交过程至少 15 至 20 次，然后引发 ServicesExceptionNotHandled 事件。 但是，仅当 SharedConnectionWorkflowCommitWorkBatchService 服务的 EnableRetries 属性设置为 true 时，才会发生此行为。

　　Windows 工作流持久性服务

　　许多业务流程都需要花很长时间才能完成（长达数月或甚至数年）。 将工作流保存在内存中不仅不切实际（由于内存限制的原因），而且，因为必须在单一服务器上处理实例，所以还会妨碍缩放。 许多这些长期运行的工作流都是执行不活跃的流程或过程逻辑，并且实际上处于空闲状态，等待来自用户或其他系统的输入。通过卸载空闲的实例，主机应用程序将能够节省内存，并且能够跨处理服务器进行缩放。

　　当工作流运行的时候发生特定情况时，工作流运行时引擎就会使用持久性服务（如果在运行时加载了持久性服务）保留有关工作流实例的状态信息。这些情况包括：

　　当完成 TransactionScopeActivity 活动和 CompensatableTransactionScopeActivity 活动中的原子事务时。

　　当工作流实例空闲，且对 WorkflowPersistenceService 将 UnloadOnIdle 标志设置为 true 时。 例如，在使用 DelayActivity 活动时会发生此情况。

　　当运行时主机应用程序对工作流实例调用 System.Workflow.Runtime.WorkflowInstance.Unload 或 System.Workflow.Runtime.WorkflowInstance.TryUnload 时。

　　当中止工作流实例或工作流实例结束时。

　　当使用 PersistOnCloseAttribute 属性的自定义活动完成时。

　　如果满足这些条件之一且将持久性服务添加到运行时引擎，则运行时引擎会调用由持久性服务提供的方法，以保存关于工作流实例的状态信息。同样，当工作流运行时引擎必须还原以前保留的工作流实例时，它调用由持久性服务提供的方法，以加载此状态信息。 换句话说，工作流实例决定持久性发生的时间，但持久性服务决定是否执行必要的持久性操作。

　　由 SqlWorkflowPersistenceService 管理的工作流状态的另一部分是计时器信息。 每当在您的工作流定义内配置 DelayActivity 活动，且使用类似 SqlWorkflowPersistenceService 的持久性服务时，与该活动相关的时间跨度信息会作为工作流状态的一部分被保留下来。 每当由工作流运行时计算工作流实例时，都会处理挂起计时器事件。

　　创建持久性服务

　　可以通过从 WorkflowPersistenceService 类派生一个类来创建持久性服务。通过调用 AddService 或在应用程序配置文件中添加合适的项，可以将持久性服务添加到工作流运行时引擎。 Windows Workflow Foundation 提供了 SqlWorkflowPersistenceService 类，这是一种全新的持久性服务，可以按原样使用或对其进行扩展。 有关创建自定义持久性服务的更多信息，请参见创建自定义持久性服务。有关使用 SqlWorkflowPersistenceService 类的更多信息，请参见使用 SqlWorkflowPersistenceService。

　　注意:

　　WorkflowRuntime 必须仅包含一个持久性服务。

　　锁定工作流状态信息

　　工作流运行时引擎具有锁定工作流状态信息的语义，当在其他进程中运行的持久性服务可能有权访问单个数据存储区时，可以使用该语义。使用 WorkflowPersistenceService 类，您可以通过以下方法支持工作流引擎的这一功能：向指定是否应该在存储区解锁工作流实例的状态信息的 SaveWorkflowInstanceState 提供参数，以及提供解锁以前锁定的工作流状态信息的 UnlockWorkflowInstanceState 方法。在实现锁定的持久性服务中，对 LoadWorkflowInstanceState 的调用将锁定工作流实例的状态信息。

　　在创建自己的持久性服务时，如果该服务不将状态信息保存到其数据存储区或从其数据存储区加载状态信息，则引发 PersistenceException。 工作流运行时引擎需要此行为。

　　持久性服务批处理行为

　　为使用持久性存储区来保存工作流状态信息的服务提供了批处理机制。 在这种情况下，在持久性服务使用的持久性存储区与工作流运行时引擎内部状态之间保持一致十分重要。您可以将由 IPendingWork 接口定义的功能添加到服务，然后通过将数据存储区更改作为工作项添加到 WorkBatch，来参与由 WorkflowCommitWorkBatchService 服务提供的工作流事务批处理。 有关更多信息，请参见 SaveCompletedContextActivity 或 SaveWorkflowInstanceState。

　　复杂的宿主情形

　　Windows Workflow Foundation 解决方案部署的一个可能的情形是创建多个主机应用程序，每个应用程序都有在不同的桌面和服务器配置上运行的一组不同的服务。在这种情形下，可能要求在解决方案中定义的一些工作流只能在特定的系统上执行。 Windows Workflow Foundation 中全新的服务（如 SqlWorkflowPersistenceService 服务）不支持这种配置。 若要控制在哪些系统上加载哪些工作流实例，必须创建自定义持久性服务。 有关更多信息，请参见创建自定义持久性服务。

　　Windows 工作流跟踪服务

　　使用 Windows Workflow Foundation 可以以一致、可靠而灵活的方式跟踪与工作流相关的信息。 Windows Workflow Foundation 跟踪框架旨在使宿主通过捕获工作流执行期间引发的事件，而在执行期间可以观察到工作流实例。 此框架为可插入式设计，使宿主可以编写自己的跟踪服务，也可以使用现成可用的或第三方跟踪服务。此外，由于使用 Windows Workflow Foundation 运行时引擎可以在其生存期过程中添加多个运行时服务，因此可以同时启用多个不同类型的跟踪服务。例如，Windows Workflow Foundation 包含一个现成可用的 SqlTrackingService 服务，此服务将数量可配置的跟踪信息写入 SQL Server 数据库。 Windows Workflow Foundation 示例还包含一个示例 ConsoleTrackingService Sample，用于侦听事件和这些事件向控制台输出的内容。 可以将这两个服务一起运行，以使最终用户可以查看工作流执行，并在开发过程中生成调试信息。

　　Windows Workflow Foundation 中的跟踪功能

　　Windows Workflow Foundation 内置多种功能，使得在启用工作流的应用程序中可以进行跟踪。

 

	功能	说明
	确保以一致的方式进行跟踪。	用户和应用程序可以跟踪工作流状态以及实时工作流和已存档到磁盘的工作流的历史记录。 跟踪服务所采用的一致框架确保自定义跟踪服务符合逻辑和连贯的模式。
	提供可伸缩性和可靠性。	跟踪框架属于轻量级，足以部署在单台计算机上，但与此同时，它也可以进行适当伸缩，以满足大多数企业业务（如要求群集和分布式数据中心环境的那些业务）的要求。
	无论基础数据存储区是什么，都使工作流数据可跟踪。	对于管理跟踪事件的数据存储区，跟踪框架为不可知。 最终用户可以获得用于跟踪事件的定义完善的架构；但是，最终将由数据存储区控制基础持久性数据的架构。
	提供一个位置以便跨宿主环境查询与工作流相关的数据。	可在多个环境中承载 Windows Workflow Foundation；而应用程序要求接口保持一致，才能通过该接口查询工作流信息。
用于查询过去和现在的工作流生命周期，并确定工作流实例未来执行时所可能采用的路径。			跟踪框架提供一种发出工作流定义和与工作流关联的元数据的方式，以实现指南类型查询。 还提供一种发出数据状态更改的方式，以便可以跟踪用户定义的状态。
支持以编程方式更改跟踪配置文件。			可以使用跟踪配置文件对象模型创建跟踪配置文件。 这样就可以在执行活动工作流的过程中根据需要加载自定义配置文件。

　　跟踪配置文件

　　跟踪服务通过使用跟踪配置文件筛选数据，从而确定接收的数据量。 跟踪服务可以接收工作流事件、活动执行状态和自定义用户跟踪数据项。工作流实例在运行的时候，跟踪服务负责跟踪其从运行时引擎接收的数据。 此服务可以在文件或数据库中存储数据、在内存中创建查询存储区、将数据写入系统事件日志或仅仅将跟踪数据输出到控制台。

　　可以使用跟踪配置文件 XML 架构以声明方式创作跟踪配置文件，也可以使用跟踪配置文件对象模型以编程方式进行创作。 此外，还可以使用 TrackingProfileSerializer API 将 XML 格式的跟踪配置文件反序列化为 TrackingProfile 实例。

　　有关跟踪配置文件的更多信息，请参见创建和使用跟踪配置文件。

　　跟踪事件类型

　　使用 Windows Workflow Foundation 中的跟踪时，可以跟踪工作流执行过程中所引发的单个事件或事件组。 ActivityExecutionStatus 枚举中定义了对于活动可以跟踪的事件：

　　·Initialized

　　·Executing

　　·Canceling

　　·Closed

　　·Compensating

　　·Faulting

　　除了跟踪活动的事件之外，使用跟踪基础结构还可以跟踪工作流实例级别发生的事件。 TrackingWorkflowEvent 枚举中定义了可以跟踪的实例级别事件：

　　·Created

　　·Completed

　　·Idle

　　·Suspended

　　·Resumed

　　·Persisted

　　·Unloaded

　　·Loaded

　　·Exception

　　·Terminated

　　·Aborted

　　·Changed

　　·Started

　　有关跟踪单个事件的信息，请参见创建和使用跟踪配置文件。

　　显式代码级别跟踪

　　生成工作流和任务的开发人员可能要以显式跟踪事件来检测其代码。 只有在跟踪配置文件无法用于为所需的跟踪事件检测运行时的情况下才应该这样做。

　　工作流创作者可以对 ActivityExecutionContext 使用 TrackData 重载方法之一来跟踪任何类型的信息。 对用户跟踪点的数量没有限制，而对可以从跟踪方法发出的数据类型也没有限制。 在 SqlTrackingService 实现中，如果传入 TrackData 方法的第二个参数的对象不能进行二进制序列化，则所保存的数据是调用该对象 ToString 方法所得的结果。

　　跟踪仅标记工作流

　　借助于仅工作流标记的工作流和 Windows Workflow Foundation 跟踪功能，您可以使用常规跟踪配置文件，也可以在启动每个工作流实例之前对此实例使用 ReloadTrackingProfiles（如果要从此实例跟踪特定的事件/项）。如果决定使用 ReloadTrackingProfiles，则必须为 XML BLOB 创建工作流实例、获取实例 GUID、生成特定于该实例的跟踪配置文件，然后让实例重新加载其配置文件。调用含有实例 ID 的 GetProfile 时，跟踪服务应将此配置文件返回到工作流运行时引擎。 这是实例与配置文件之间发生关联的地方。

　　跟踪规则

　　执行 RuleSet 时，将向在宿主上配置的跟踪服务发送跟踪事件，这些宿主已通过向其跟踪配置文件添加 UserTrackPoint 注册了这些事件。 将发送 RuleActionTrackingEvent，其中提供了已计算的规则的名称以及条件计算结果 (true/false)。 有关更多信息，请参见 RuleActionTrackingEvent Sample。

　　通过跟踪活动执行情况，可以隐式地跟踪活动上的规则条件的计算结果。