WF学习系列之一：WF基本知识点概述
此文是从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 状态，调用才会成功。
|
活动 |
说明 |
|
与 HandleExternalEventActivity 活动一起使用，以实现与本地服务之间的输入和输出通信。 有关更多信息，请参见使用 CallExternalMethodActivity 活动。 |
|
|
用于包含在复合活动的所有子活动执行完毕之前取消的复合活动的清理逻辑。 有关更多信息，请参见使用 CancellationHandlerActivity 活动。 |
|
|
可用于向工作流中添加 Visual Basic 或 C# 代码。 有关更多信息，请参见使用 CodeActivity 活动。 |
|
|
SequenceActivity 的可补偿版本。 有关更多信息，请参见使用 CompensatableSequenceActivity 活动。 |
|
|
TransactionScopeActivity 的可补偿版本。 有关更多信息，请参见使用 CompensatableTransactionScopeActivity 活动。 |
|
|
可用来调用代码以撤消或补偿在发生错误时已由工作流执行的操作。 有关更多信息，请参见使用 CompensateActivity 活动。 |
|
|
为已完成的 TransactionScopeActivity 活动执行补偿的一个或多个活动的包装。 有关更多信息，请参见使用 CompensationHandlerActivity 活动。 |
|
|
根据应用于 ConditionedActivityGroup 活动本身的条件以及分别应用于每个子活动的条件来执行子活动。 有关更多信息，请参见使用 ConditionedActivityGroup 活动。 |
|
|
可用于在工作流中根据超时间隔建立延迟。 有关更多信息，请参见使用 DelayActivity 活动。 |
|
|
包装在指定事件发生时执行的一个或多个活动。 有关更多信息，请参见使用 EventDrivenActivity 活动。 |
|
|
提供一个用于将事件与活动关联的框架。 有关更多信息，请参见使用 EventHandlersActivity 活动。 |
|
|
将其主要子活动与 EventHandlersActivity 活动并发执行。 有关更多信息，请参见使用 EventHandlingScopeActivity 活动。 |
|
|
用于处理指定类型的异常。 有关更多信息，请参见使用 FaultHandlerActivity 活动。 |
|
|
表示一个复合活动，它有一个由类型为 FaultHandlerActivity 的子活动组成的有序列表。 有关更多信息，请参见使用 FaultHandlersActivity 活动。 |
|
|
与 CallExternalMethodActivity 活动一起使用以实现与本地服务之间的输入和输出通信。 有关更多信息，请参见使用 HandleExternalEventActivity 活动。 |
|
|
测试每个分支条件，在第一个条件为 true 的分支上执行活动。 有关更多信息，请参见使用 IfElseActivity 活动。 |
|
|
表示 IfElseActivity 活动的一个分支。 有关更多信息，请参见使用 IfElseBranchActivity 活动。 |
|
|
使工作流能够调用 Web 服务。 有关更多信息，请参见使用 InvokeWebServiceActivity 活动。 |
|
|
使工作流能够调用其他工作流。 有关更多信息，请参见使用 InvokeWorkflowActivity 活动。 |
|
|
只包含 EventDrivenActivity 子活动的复合活动。 有关更多信息，请参见使用 ListenActivity 活动。 |
|
|
用于计划将两个或更多个 SequenceActivity 子活动分支同时进行处理。 有关更多信息，请参见使用 ParallelActivity 活动。 |
|
|
用于表示一个规则集合。 规则由条件和引起的操作组成。 有关更多信息，请参见使用 PolicyActivity 活动。 |
|
|
创建单个子活动的多个实例。 有关更多信息，请参见使用 ReplicatorActivity 活动。 |
|
|
提供一种将多个活动链接在一起以顺序执行的简单方法。 有关更多信息，请参见使用 SequenceActivity 活动。 |
|
|
指定到新状态的转换。 有关更多信息，请参见使用 SetStateActivity 活动。 |
|
|
表示状态机工作流中的一个状态。 有关更多信息，请参见使用 StateActivity 活动。 |
|
|
在 StateActivity 活动中用作容器，以容纳在离开 StateActivity 活动时执行的子活动。 有关更多信息，请参见使用 StateFinalizationActivity 活动。 |
|
|
在 StateActivity 活动中用作容器，以容纳在进入 StateActivity 活动时执行的子活动。 有关更多信息，请参见使用 StateInitializationActivity 活动。 |
|
|
挂起工作流的操作，以便能够在出现某种需要特别注意的错误情况时进行干预。 有关更多信息，请参见使用 SuspendActivity 活动。 |
|
|
在同步域中按顺序执行所包含的活动。 有关更多信息，请参见使用 SynchronizationScopeActivity 活动。 |
|
|
可用于在发生错误情况时立即结束工作流的操作。 有关更多信息，请参见使用 TerminateActivity 活动。 |
|
|
可用于捕获作为工作流的过程元数据的一部分引发的业务异常。 有关更多信息，请参见使用 ThrowActivity 活动。 |
|
|
提供一个用于事务和异常处理的框架。 有关更多信息，请参见使用 TransactionScopeActivity 活动。 |
|
|
用于对 Web 服务错误的发生进行建模。 有关更多信息，请参见使用 WebServiceFaultActivity 活动。 |
|
|
接收来自 Web 服务的数据。 有关更多信息，请参见使用 WebServiceInputActivity 活动。 |
|
|
响应对工作流发出的 Web 服务请求。 有关更多信息，请参见使用 WebServiceOutputActivity 活动。 |
|
|
使工作流能够在条件得到满足之前进行循环。 有关更多信息，请参见使用 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。
通过跟踪活动执行情况，可以隐式地跟踪活动上的规则条件的计算结果。
自定义跟踪服务
Windows Workflow Foundation 包含 SqlTrackingService 服务，该服务可用于跟踪存储在 SQL Server 数据库中的数据。但是，由于 Windows Workflow Foundation 使用了扩展性模型，因此可以创建使用如本地文件等各种存储介质的自定义跟踪服务，这是因为运行时引擎不关心数据的最终目标或交付格式。有关如何创建自定义跟踪服务的更多信息，请参见创建自定义跟踪服务。
4 补偿概述
补偿是由于工作流中其他位置发生异常而做出的一种行为，这种行为撤消由成功完成的可补偿活动所执行的任何操作。
已完成事务的 Windows Workflow Foundation 补偿模型是一个处理工作流中发生的任何业务异常并合乎逻辑地撤消已完成事务的过程。
Windows Workflow Foundation 补偿可以是：
未指定异常处理程序或未处理特定异常时，默认为隐式。
使用 CompensateActivity 活动时为显式。
5 本地通信和关联概述
宿主进程可以通过经由自定义本地通信服务交换数据来与工作流进行通信。 这些本地通信服务实现了一些用户定义的接口，这些接口定义了将在工作流和宿主进程之间进行传递的方法和事件。
通过使用在宿主进程和工作流之间作为事件参数传递的唯一 ID，宿主进程还可以在特定的工作流实例中与特定的活动进行交互。 这称为“关联”。
Windows Workflow Foundation 支持工作流的承载环境中的本地通信服务和 Web 服务通信。
Windows Workflow Foundation 通信服务使工作流能够使用方法和事件通过消息与外部系统交互。 事件用于将数据发送到工作流，而工作流使用方法将数据发送到主机应用程序。 通过事件与工作流进行通信的功能提供了一种将数据发送到工作流的异步方式。
在工作流中使用本地服务
Windows Workflow Foundation 工作流通信服务向工作流编写器公开用户定义的服务类，作为方法调用和事件处理程序，以简化出站和入站消息交换的建模。 单个服务类实例到多个工作流实例的多路复用允许主机编写器对出站消息的单个位置进行编程，而引发事件时仍针对特定工作流实例。
下图演示本地通信服务如何与其主机应用程序通信。
工作流实例上的 HandleExternalEventActivity 和 CallExternalMethodActivity 活动与在自定义接口中声明并在自定义本地服务中实现的事件和方法交互。 HandleExternalEventActivity 活动响应由主机应用程序引发且由本地服务实现的特定事件。 CallExternalMethodActivity 对本地服务调用方法。
工作流通信服务
Windows Workflow Foundation 工作流通信服务实现一种供对象与工作流实例通信的简单机制。通信通道的定义是一个接口，其实现是添加到运行时以方便通信的服务类。对于服务类，工作流的行为很像任何其他类，您通过引发事件和接收方法调用与其通信。 对于工作流，通信接口显示为包含入站事件接收和出站操作方法调用的通道。ExternalDataExchangeService 将接口上的外部方法声明转换为服务对象上的方法调用。 我们可以视为本地服务的类能够引发事件，工作流运行时引擎截获这些事件并将其作为工作流的入站消息加以传送。
下面的代码示例演示如何定义本地工作流通信接口的示例。
[ExternalDataExchange]
public interface ICommunicationService
{
void HelloHost(string message);
event EventHandler<ExternalDataEventArgs> HelloWorkflow;
}
服务类
服务类实现用于定义与工作流进行通信的接口。 接口上的所有事件都是单向的，也就是说，这些事件没有 ref 或 out 参数，并且没有返回值。 但是，对于传出请求，接口上的方法可以具有 ref 和 out 参数，并且有返回值。
通信模型为多对一：有很多工作流实例，每个实例可以使用此单一实例服务对象在很多会话上传递。这意味着对所有工作流中的特定方法 m 的所有出站调用由同一个对象上的同一个 m 提供服务。相反，所有入站调用必须显式定向到正确的工作流实例和会话。 Windows Workflow Foundation 为 m 提供一种机制以区别出站调用的工作流实例和会话。 使用这两段信息，对象可以将响应定向回正确的工作流实例上的正确的会话。
Windows Workflow Foundation 在出站调用线程上的 System.Workflow.Runtime.WorkflowEnvironment.WorkflowInstanceId 中提供调用工作流的实例标识符。
下 面的代码示例演示通信服务实现。
public class CommunicationService : ICommunicationService
{
public event EventHandler<ExternalDataEventArgs> HelloWorkflow;
public void HelloHost(string message)
{
Console.WriteLine("This is the message: {0}", message);
// Raise the HelloWorkflow event.
HelloWorkflow(null, new ExternalDataEventArgs(WorkflowEnvironment.WorkflowInstanceId));
}
}
您启动工作流的实例之前，必须将 ExternalDataExchangeService 添加到工作流运行时引擎，然后将自定义通信服务添加到 ExternalDataExchangeService，如下面的代码示例所示。
ExternalDataExchangeService externalService = new ExternalDataExchangeService();
workflowRuntime.AddService(externalService);
externalService.AddService(new CommunicationService());
在工作流中使用关联
Windows Workflow Foundation 运行时引擎使用关联将入站消息映射到某个工作流实例中的特定 HandleExternalEventActivity 活动。 对实例的映射是在将工作流实例 InstanceId 传递到 ExternalDataEventArgs 构造函数时完成的。通过使用接口属性来定义关联。 Windows Workflow Foundation 工作流通信服务接口可以为关联指定附加的元数据。 关联某个工作流实例的事件活动时需要此关联数据。 关联元数据规范采用接口属性的形式，即 CorrelationParameterAttribute 属性。
注意:
为通信接口提供关联属性是可选的。 默认情况下，通信接口都是无关联的。 用户只有在需要使用关联将消息传递给特定活动实例时才应添加关联属性。
接口属性
下表描述在可供 Windows Workflow Foundation 工作流通信服务使用的接口定义中可以使用的接口属性全集。
|
属性 |
说明 |
|
用于指定在接口中定义的方法和事件的用于关联的参数名称。 如果方法或事件包含一个与该名称匹配的形参，则该参数定义该方法或事件上的相关值。 如果方法或事件没有此类参数，则方法或事件可以使用 CorrelationAliasAttribute 来定义相关值的位置。 此属性在一个接口中可以出现多次。 |
|
|
用于在方法或事件中指示相关参数的值是在调用该方法或引发该事件时初始化的。 对于给定的 CorrelationToken，必须在对话中的任何其他方法或事件执行之前调用或接收初始值设定项方法或事件。 任何可以初始化新对话（即新的相关令牌）的方法或事件都必须使用此属性进行标记。 对于每个相关令牌，方法或事件必须包含一个适当的命名参数或一个 CorrelationAliasAttribute。 |
|
|
在方法或事件定义中用来重写该成员的 CorrelationParameter 设置。 CorrelationAliasAttribute 属性指定可用参数中可以获得相关值的位置。 该字符串参数是针对形参集的以点分隔的路径。 该参数指示在何处可以找到匹配数据值。 如果定义了多个相关令牌，还必须指定令牌 Name 命名参数。 |
使用相关属性
CorrelationParameterAttribute 命名对话标识符和关联。 然后，使用该名称的形参对接口上的每个方法或事件进行声明（例如 id），如下面的 ITaskService 接口代码示例所示。 也可以使用其他属性来说明更复杂的相关映射。 当实例和相关信息已为某个对话所了解时，该类将引发其本地服务事件。它在调用上的参数数据中指定关联。
下面的代码演示与接口定义相关的工作流通信服务 ITaskService。
[Serializable]
public class TaskEventArgs : ExternalDataEventArgs
{
private string id;
public TaskEventArgs(Guid instanceId,string id)
:base(instanceId)
{
this.id = id;
}
public string Id
{
get { return id; }
set { id = value; }
}
}
[ExternalDataExchange]
[CorrelationParameter("taskId")]
public interface ITaskService
{
[CorrelationInitializer]
void CreateTask(string taskId, string assignee, string text);
[CorrelationAlias("taskId", "e.Id")]
event EventHandler<TaskEventArgs> TaskCompleted;
}
任何启动新对话的操作、方法或事件必须具有 CorrelationInitializerAttribute 属性。 如果发生对 CorrelationInitializerAttribute 方法 m 的调用，则服务类能了解该调用正在初始化新对话。 工作流对话生存期由相关引用的生存期指示。 工作流可以在对话之间卸载或加载。
下面的代码示例演示实现 ITaskService 的服务类。
public class TaskService : ITaskService
{
public void CreateTask(string taskId, string assignee, string text)
{
Console.WriteLine("task " + taskId + " created for " + assignee);
}
public void RaiseEvent(TaskEventArgs args)
{
if (TaskCompleted != null)
TaskCompleted(null, args);
}
public event EventHandler<TaskEventArgs> TaskCompleted;
}
6 持久性概述
Windows Workflow Foundation 简化了有状态的、长期运行的持久性工作流应用程序的创建过程。 工作流运行时引擎管理工作流的执行情况，而且允许工作流长期保持活动状态并在应用程序重新启动之后存在。这种持久性是 Windows Workflow Foundation 的关键原则。 它意味着可以在等待输入时从内存中卸载工作流，而且工作流可以序列化为持久性存储（如 SQL 数据库或 XML 文件）。 只要收到了输入，工作流运行时引擎就会将工作流状态信息重新加载到内存中并继续执行工作流。
Windows Workflow Foundation 提供的 SqlWorkflowPersistenceService 可以与 Microsoft SQL Server 2005 Express、SQL Server 2000（或更高版本）或 SQL Server 2000 Desktop Engine (MSDE) 很好地集成，以便方便而又高效地保持工作流信息。 您还可以通过从 WorkflowPersistenceService 基类派生来创建自己的持久性服务，以便按照所需的方式存储工作流状态信息。
7 跟踪概述
“跟踪”是一项功能，用于指定并捕获有关工作流实例的信息，并在这些实例执行时存储该信息。 Windows Workflow Foundation 提供了 SqlTrackingService 这一跟踪服务，该服务使用 SQL 数据库来存储所收集的跟踪信息。您也可以编写自己的跟踪服务来收集该信息，并以您应用程序需要的任何格式将其存储下来。
创建新工作流时，该跟踪服务会请求一个要与该工作流相关联的跟踪通道。 之后，会将该工作流中的所有跟踪信息发送到该跟踪通道。
该跟踪服务可以跟踪三种类型的事件：工作流实例事件、活动事件和用户事件。 通过提供跟踪配置文件，您可以配置您的服务要为特定工作流实例或特定类型的工作流接收的信息类型和数量。
跟踪框架还能够在事件期间提取与活动或工作流相关的信息。 如果需要跟踪活动或工作流中的特定属性或字段，您可以在跟踪配置文件的提取节中提供此信息，将在指定事件期间提取该信息。
8 序列化概述
对工作流、活动和规则可以进行序列化和反序列化。 这样就可以保持它们，在工作流标记文件中使用它们，以及在工作流设计器中查看其属性、字段和事件。
Windows Workflow Foundation 为标准活动提供了默认的序列化功能，您也可以为自定义活动创建自己的序列化功能。例如，利用自定义活动序列化程序，可以决定对哪些成员进行序列化以及如何对其进行序列化。 这也将确定这些成员在工作流设计器中是可见还是隐藏。
9 工作流更改概述
使用 Windows Workflow Foundation，可以在运行时动态更新工作流实例和声明性规则。在计划待执行的活动之前，可以更改预期行为、流控制等。 使用该功能，可以修改业务处理逻辑，且不必重新编译和重新启动工作流。
10 “规则和条件”概述
Windows Workflow Foundation 可将业务逻辑作为规则或条件来实现。 IfElseBranchActivity、ConditionedActivityGroup、WhileActivity 和 ReplicatorActivity 活动使用条件来控制活动的执行。 条件可以声明方式表示，也可以在代码中定义。 声明性条件以代码 DOM 语句的形式在规则的 XML 文件中创建。 基于代码的条件可引用工作流的代码文件中的一个方法，该方法通过 Result 属性返回其结果。
与条件一样，规则以代码 DOM 语句的形式表示，并收集到规则的 XML 文件中。 规则包含一个条件语句和一些操作集合，这些集合中的操作是根据条件的结果来执行的。规则将会收集到规则集中，规则集既支持规则的简单依序执行，也支持规则的复杂正向链接。 规则集由 PolicyActivity 活动执行。
使用规则和声明性条件定义逻辑的一个主要优点是，通过使用工作流更改来执行动态更新，可在运行时修改这些规则和声明性条件。 此外，规则使您可将业务逻辑与工作流分开，以便与其他工作流共享这些规则。最后，通过在规则中定义业务逻辑，可在对象模型之上构建高级工具，如依赖关系可视化工具和影响分析工具。
11 错误处理概述
工作流运行时引擎在一个称为“错误处理”的进程中异步处理活动中所出现的异常。 异常被安排在队列中以便日后处理。 如果异常类型与特定 FaultHandlerActivity 活动所处理的类型相符，则该活动将处理此异常。 如果无法处理异常，则通过父活动向上冒泡，直到最终导致工作流实例终止。
Windows Workflow Foundation 中的错误处理指的是以异步方式处理异常。这意味着工作流运行时引擎会捕获在活动中（显式或隐式）引发的异常，然后将其安排在队列中以便以后处理。 这与常规异常处理不同，因为在常规异常处理中，如果异常是在 try 块中引发的，则它可以由相应的 catch exception 块捕获，也可以立即对用户引发。
异常的原因
在工作流中，异常可能通过下列方式生成：
TransactionScopeActivity 或 CompensatableTransactionScopeActivity 中的事务超时。
工作流通过使用 ThrowActivity 活动引发的显式异常。 有关更多信息，请参见使用 ThrowActivity 活动。
从代码活动的处理程序或自定义活动的代码旁置引发的 .NET Framework 异常。
从库或在工作流中使用的组件等外部代码引发的异常。
捕获异常
在错误处理中，如果引发异常的活动不能处理异常，则该异常将被传输到其父活动以进行解决。 在处理异常或工作流运行时引擎终止工作流实例之前，该异常将被传输到工作流层次结构中。
异常由 FaultHandlerActivity 活动来处理。 每个 FaultHandlerActivity 活动都与 .NET Framework 异常类型相关联，并且如果引发的异常与该异常类型匹配，则该活动还包含一组所执行的活动。 FaultHandlerActivity 活动是包含 0-n 个 FaultHandlerActivity 活动的 FaultHandlersActivity 活动的父级。 FaultHandlersActivity 可以是任何复合活动的子活动。
Windows Workflow Foundation 中错误处理的目标是撤消已发生异常的活动的部分工作及不成功的工作。 FaultHandlerActivity 活动的完成从不被视为其相关活动的成功完成。 这意味着，当执行 FaultHandlerActivity 活动时，引发异常的活动被置于错误状态。当 FaultHandlerActivity 活动完成时，相关联的活动被置于关闭状态。 此外，相关联活动的任何同级活动（如 ParallelActivity 活动的其他子级）被置于取消状态，然后置于关闭状态。它们永远不会成功执行。
错误处理与补偿
错误处理与补偿之间的区别是，补偿只能对已成功完成的活动执行，不能对引发异常和处于错误状态的活动执行；但是，在与引发异常的活动相关联的 FaultHandlerActivity 活动内可以执行 CompensateActivity 活动。 例如，补偿处理的典型情形是，一项活动成功完成，但在工作流后面的另一活动中引发异常。该活动的错误处理程序包含一个 CompensateActivity，后者可撤消在工作流中以前完成的任何操作。 若要对此进行进一步扩展，您可能要在工作流后面由另一活动引发 ItemDiscontinuedException 之后向客户退款。
12 工作流标记概述
基于可扩展应用程序标记语言 (XAML) 的工作流标记可以使开发人员和设计人员以声明方式为业务逻辑建模，并将其与由代码旁置文件建模的低级实现细节区分开。因为工作流可以声明方式建模，所以可以在运行时，通过直接将工作流标记文件加载到工作流运行时引擎的方式来激活工作流。
posted on 2008-12-09 15:47 mjgforever 阅读(2252) 评论(2) 编辑 收藏 举报
