托管 Windows Workflow Foundation 简介

 

穆斯塔法·哈利勒·艾哈迈德
计划经理
Microsoft Corporation

2006 年 8 月

适用于：
   Windows Workflow Foundation
   Microsoft .NET Framework 2.0
   Microsoft .NET Framework 3.0

总结： 概述托管 Windows Workflow Foundation (WF) 的应用程序如何管理和监视正在运行的工作流，并概述运行时服务及其开箱即用实现。 读者应熟悉 Microsoft .NET Framework、C# 和 WF 编程模型。 (16 个打印页)

目录

简介
管理工作流实例生命周期
可管理性和监视
可靠性和高可用性
基本运行时服务
结论
有关详细信息

简介

本文面向使用 Windows Workflow Foundation (WF) 的开发人员，以帮助他们了解可用于允许其应用程序管理和监视正在运行的工作流实例的不同选项。 本文假定读者对 Microsoft .NET Framework、C# 和 WF 有基本的了解。

WF 由活动库和框架、运行时引擎以及必须在主机应用程序进程中运行的运行时服务组件组成。 工作流构造为运行时引擎执行的一组活动。 运行时引擎必须在主机应用程序进程中运行。 下面的插图显示了如何在一个主机应用程序的进程中同时承载工作流、活动和工作流运行时引擎。

图 1. Windows Workflow Foundation 主机进程

WF 提供一个运行时引擎，它负责工作流执行和状态管理。 WF 运行时可以托管在任何 .NET 进程中，包括 ASP.NET、Windows 服务、控制台应用程序和Windows 窗体应用程序。 开发人员负责在生成启用了工作流的应用程序时编写此主机进程。 运行时服务在主机进程中工作，在运行时引擎管理工作流执行时为运行时引擎提供附加功能。

为 WF 实现主机应用程序时，需要考虑许多问题。 本文概述了主机应用程序如何管理和监视工作流，以及基本运行时服务及其现成实现的摘要。

管理工作流实例生命周期

WF 在 WorkflowInstance 类上提供现成的活动和控制操作方法，用于管理工作流状态和生命周期。 管理工作流实例生命周期部分介绍各种特定于工作流实例的运行时事件以及这些事件之间的转换及其与工作流状态的关系。

持久性点

工作流经常长时间运行且实际上处于空闲状态，等待用户或其他系统的输入继续。 由于将空闲工作流保存在内存中是不切实际的，因此建议将工作流实例状态保存到存储介质，直到工作流收到它正在等待的事件。 此外，保存工作流实例状态有助于在流程稍后发生故障时从该点恢复工作流。

图 2 介绍了如何使用持久性点恢复正在运行的工作流实例。

图 2. 使用持久性点恢复正在运行的工作流实例

如果工作流实例状态在点 B 持久化，并且 C 点发生故障，则应用程序可以从点 B 恢复工作流实例，而不会丢失在点 A 和 B 点之间完成的工作。但是，如果持久性服务不可用或工作流实例状态未持久化，则从点 A 到 B 完成的工作将丢失。

如果 存在 WorkflowPersistenceService (，则添加到 WorkflowRuntime 实例) 工作流运行时引擎使用此服务将工作流实例状态保存到存储介质中。 这可能发生在以下时间点：

• 例如，在完成使用 PersistOnCloseAttribute (标记的活动时，事务范围活动)
• 工作流实例完成之前
• 工作流实例终止之前
• 工作流空闲时
• 调用 WorkflowInstance.Unload 或 WorkflowInstance.TryUnload 时

WF 运行时引擎调用 WorkflowPersistenceService 上的 SaveWorkflowInstanceState () 方法来保存工作流实例状态。 它调用 LoadWorkflowInstanceState () 方法，以在需要时检索工作流实例持久化状态。 工作流运行时处理有关何时执行持久性的所有语义，持久性服务负责实际保存和加载工作流实例。 活动状态和工作流实例 ID 将序列化并保存到持久性存储。 此外，恢复工作流实例执行的所有其他必要信息 (例如，队列) 包含在序列化的保存状态中。

工作流实例事件

工作流实例可以处于以下五种状态之一：“已创建”、“正在运行”、“已挂起”、“已完成”和“已终止”。 工作流在工作流实例的整个生存期内有 13 个事件发生。 这些事件可以指示转换到其他状态。 例如， WorkflowCompleted 事件指示实例已从“正在运行”转换为“已完成”。 某些事件并不指示实例已转换到其他状态。 例如， WorkflowPersisted 事件指示实例为“持久化”，但仍处于“正在运行”状态。 在 13 个事件中，有 11 个通过运行时事件和跟踪工作流事件与主机应用程序通信。 两个事件“已更改”和“异常”仅通过跟踪工作流事件传达给主机应用程序。

WF 在 WorkflowInstance 类上提供控制操作方法，使主机应用程序能够管理工作流生命周期。 此外，应用程序还可以设置策略来管理工作流生命周期。 例如，应用程序可以具有卸载策略来指示 WF 引擎卸载工作流实例。 WF 提供可能影响工作流实例统计信息的现成活动。例如， SuspendActivity 和 TerminateActivity 活动可用于分别挂起和终止工作流实例。 以下部分介绍工作流运行时引发的各种特定于工作流实例的事件，以传达工作流实例事件和工作流实例的统计信息转换。

WorkflowAborted

当工作流运行时引擎丢弃内存中实例时，工作流实例被视为中止。 主机应用程序可以通过调用 WorkflowInstance.Abort () 来中止工作流实例。 中止的工作流实例可以通过调用 WorkflowInstance.Resume () 从其最后一个持久性点恢复。 中止工作流实例适用于在调用 WorkflowInstance.Abort () 之前，应用程序决定放弃从最后一个持久性点完成的所有工作。

WorkflowCompleted

当实例完成执行时，将完成工作流实例。 此时，主机应用程序可以检查队列中工作流实例未使用的消息和其他事件。

WorkflowCreated

在完全构造实例时，但在活动开始执行之前，将创建工作流。 工作流实例是通过调用多个 WorkflowRuntime.CreateWorkflow () 重载方法中的任何一个来创建的。

WorkflowIdled

工作流实例在等待外部事件 (计时器、消息或其他自定义事件) 继续执行时处于空闲状态。 为了节省系统资源，应用程序可以设置其卸载策略，以在工作流实例处于空闲状态时从内存中卸载工作流实例。 如果主机应用程序使用现成的 SqlWorkflowPersistenceService，则可以在应用程序配置文件中设置 UnloadOnIdle 标志，以指示 WF 运行时引擎在实例空闲时保留工作流状态。

WorkflowLoaded

当实例状态从持久性存储加载到内存中时，将引发 WorkflowLoaded 事件。

WorkflowPersisted

将现成的 SqlWorkflowPersistenceService 或自定义持久性服务添加到 WorkflowRuntime 实例时，当工作流实例状态保存到持久性存储区时，工作流实例将持久保存。

WorkflowResumed

在挂起或中止的工作流实例上调用 WorkflowInstance.Resume () 时，将恢复工作流实例。

WorkflowStarted

调用 WorkflowInstance.Start () 时，将引发 WorkflowStarted 事件。 工作流启动事件在工作流运行时引擎开始执行工作流活动之前引发。

WorkflowSuspended

通过 WorkflowInstance.Suspend () 调用或在 SuspendActivity 活动执行时暂停工作流实例。 因此，工作流实例处于挂起状态。

WorkflowTerminated

终止工作流实例是通过 WorkflowInstance.Terminate () 调用完成的，当 TerminateActivity 活动执行时，或者当正在运行的工作流实例中发生未经处理的异常时。 引发此事件后，工作流实例将处于终止状态。

WorkflowUnloaded

当工作流实例从内存卸载到持久性存储时，将引发 WorkflowUnloaded 事件。 这取决于持久性策略，或通过调用 WorkflowInstance.Unload () 或 WorkflowInstance.TryUnload () 来完成。

工作流实例事件转换

工作流实例事件通过工作流运行时事件和跟踪工作流事件传达给主机。 主机应用程序可以订阅运行时事件或使用跟踪服务来接收通知。 异常和更改事件仅通过跟踪服务传达给主机应用程序。 Exception 事件指示在执行工作流实例时发生异常。 Changed 事件指示工作流实例在执行时已动态更新。

图 3 演示了各种工作流事件与工作流状态之间的转换。

图 3. 工作流事件与状态之间的转换 (单击图像将其放大)

如果启用了持久性服务，则持久性点将发生，如图 3 所示。 这些主机应用程序应会看到 WorkflowPersisted、 WorkflowUnloaded 和 WorkflowLoaded 事件（如果适用）。 如果工作流实例不在内存中，并且启用了持久性服务，则实例上的任何有效操作 (Resume、 Abort、 Terminate 等) 导致工作流实例先加载，然后继续满足请求。 例如，如果有一个挂起但已卸载的工作流实例，则对它调用 Resume 会导致它首先加载，然后继续引发 Resumed 事件，如关系图所示。

工作流实例操作

如前所述， WorkflowInstance 类具有用于控制工作流实例生命周期的方法。 本部分介绍这些方法。

WorkflowInstance.Start ()

启动创建的工作流实例的执行。 WorkflowInstance.Start () 会导致工作流运行时引发 WorkflowStarted 事件，并且工作流实例处于“正在运行”状态。 如果在已启动的工作流实例上调用 Start () ，则会引发 InvalidOperationException。

WorkflowInstance.Abort ()

中止工作流实例。 中止成功后，工作流运行时将引发 WorkflowAborted 事件。

WorkflowInstance.Load ()

将卸载的工作流实例从持久性存储加载到内存中。 然后，从卸载实例之前处于的状态计划执行实例。 加载成功后，工作流运行时将引发 WorkflowLoaded 事件。

WorkflowInstance.Resume ()

恢复 (继续执行) 挂起或中止的工作流实例。 工作流运行时在继续执行工作流实例之前引发 WorkflowResumed 事件。

WorkflowInstance.Suspend ()

暂停工作流实例的执行。 成功调用 WorkflowInstance.Suspend () 后，工作流运行时将引发 WorkflowSuspended 事件。

WorkflowInstance.Terminate ()

终止工作流实例并清除内存中的工作流实例。 工作流运行时通知已注册的持久性服务工作流实例已从内存中清除。 对于 SqlWorkflowPersistenceService，这意味着该工作流实例的所有状态信息在终止时将从数据库中删除。 不能从以前存储的持久性点重新加载工作流实例。 当 WorkflowInstance.Terminate () 成功时，工作流运行时将引发 WorkflowTerminated 事件。

WorkflowInstance.Unload ()

将工作流实例从内存卸载到持久性存储区。 WorkflowInstance.Unload () 是同步的。 它阻止，直到当前计划的工作完成或达到事务范围的结束，以便成功执行卸载。 当 WorkflowInstance.Unload () 成功时，工作流运行时将引发 WorkflowUnloaded 事件。 如果没有注册的持久性服务，如果调用 Unload () ，则会引发 InvalidOperationException。

WorkflowInstance.TryUnload ()

与 WorkflowInstance.Unload () 不同，在可以卸载工作流之前 ，WorkflowInstance.TryUnload () 不会阻止。 WorkflowInstance.TryUnload () 将工作流实例从内存卸载到持久性存储，并在实例挂起或空闲时返回 true 。 否则，调用将返回 false。 如果没有已注册的持久性服务，则调用 TryUnload () 时，将引发 InvalidOperationException。

有关 WorkflowInstance 上的各种控制方法的详细信息，请参阅 Windows Foundation SDK。

可管理性和监视

托管工作流的应用程序负责管理和监视它们托管和执行的工作流。 WF 为各种可管理性和监视工具提供支持。 例如，WF 提供端到端跟踪，可用于低级调试，还可以跟踪工作流数据提取和监视的基础结构。

本部分讨论到位的可管理性和监视基础结构，以及如何在主机应用程序中使用它。

跟踪

WF 提供跟踪基础结构，用于在执行工作流实例时捕获工作流、活动以及用户事件和数据。 任何工作流运行时实例都可以有多个已注册的跟踪服务，或者没有。 跟踪信息将发送到已注册的跟踪服务。 跟踪服务负责根据主机应用程序的需求存储和处理此信息。 WF 提供基于 SQL 的现成跟踪服务， (SqlTrackingService) 主机应用程序可以使用。 此外，主机应用程序开发人员可以编写自己的自定义跟踪服务并将其用于主机应用程序。

可以使用跟踪来检查工作流实例执行的历史记录，并确定在系统上运行的工作流实例的当前状态。 此外，跟踪可以提供可与工作流定义一起使用的信息，以预测系统中运行的工作流实例的未来预期执行路径。 WF 提供了一个应用程序示例 工作流监视器示例，该示例使用现成的 SqlTrackingService 和工作流设计器控件来显示有关已完成和当前正在执行的工作流的工作流和活动状态信息。

有关使用跟踪监视工作流的详细信息，请参阅应用程序示例/工作流监视器示例中的工作流监视器 SDK 工具 。 有关演示如何生成自定义跟踪服务的示例，请参阅 ConsoleTrackingService 示例 和 文件跟踪服务以及技术示例 /跟踪中的查询示例。 有关演示如何使用现成 的 SqlTrackingService 的示例，请参阅 简单跟踪示例 和使用 SQLTrackingService 示例进行查询技术示例 /现成跟踪。

跟踪和端到端跟踪

可以使用跟踪来监视应用程序的运行状况，并在不干扰正在运行的系统的情况下隔离和修复问题。 WF 使用 System.Diagnostics API 跟踪有关工作流运行时和工作流实例执行的信息，包括规则集评估信息。 默认情况下，跟踪处于关闭状态，但你可以根据需要将其打开。

此外，WF 还参与端到端跟踪。 端到端跟踪功能使跟踪查看者能够查看各个组件的延续跟踪信息，以及这些组件之间的转换。 这有助于进行端到端调试。

如果使用应用程序配置文件，则必须添加以下内容才能为多个 WF 命名空间启用日志记录跟踪：

<system.diagnostics>
    <switches>
        <add name="System.Workflow LogToTraceListeners" value="1" />
        <add name="System.Workflow.Runtime" value="All" />
        <add name="System.Workflow.Runtime.Hosting" value="All" />
        <add name="System.Workflow.Runtime.Tracking" value="All" />
        <add name="System.Workflow.Activities" value="All" />
        <add name="System.Workflow.Activities.Rules" value="All" />
    </switches>
</system.diagnostics> 

使用 LogToTraceListeners 时，WF 枚举在主机应用程序中创建的每个 TraceListener，并将所有日志记录信息发送给它们。 通过示例中的其余行，可以指定要捕获日志记录信息的命名空间，以及跟踪的信息量。 value 属性的可能值包括 All、Off、Critical、Error、Warning、Information 和 Verbose。 有关使用值属性的详细信息，请参阅 WF SDK。

工作流运行时事件

运行时事件由工作流运行时引发，并为主机应用程序提供管理工作流运行时和工作流实例生命周期的方法。 事件处理程序在 WorkflowRuntime 类上定义，主机应用程序必须订阅这些事件才能使用它们。

当主机应用程序需要处理特定事件时，运行时事件充当轻型通知系统，而不是存储这些事件及其关联数据以用于查询。 对于后者，建议使用跟踪基础结构。

WorkflowRuntime 的实例可能正在运行多个工作流实例;每个工作流实例都有自己的生命周期。 因此，工作流实例事件的事件参数包含工作流实例 ID 和其他信息。 此信息可用于将事件与导致工作流运行时引发此事件的工作流实例相关联。

以下部分介绍可用的工作流运行时事件。

WorkflowRuntime.ServiceExceptionNotHandled

当服务拥有的线程引发异常时，将引发此事件。 派生自 WorkflowRuntimeService 类的服务可以调用 RaiseServicesExceptionNotHandledEvent () 方法，以通知 ServicesExceptionNotHandled 事件的订阅者在执行过程中发生了异常，并且无法处理此异常。 在这种情况下，开箱即用的服务会引发此事件。 主机应用程序可以订阅此事件来实现恢复机制。 与此事件关联的事件参数为 ServicesExceptionNotHandledEventArgs。

WorkflowRuntime.Started

当 WorkflowRuntime 的指定实例启动时，将引发此事件。 与此事件关联的事件参数为 WorkflowRuntimeEventArgs。

WorkflowRuntime.Stopped

当 WorkflowRuntime 的指定实例停止时，将引发此事件。 与此事件关联的事件参数为 WorkflowRuntimeEventArgs。

表 1. WorkflowInstanceEvents

事件	说明	事件参数
WorkflowAborted	工作流实例中止时引发。	WorkflowEventArgs
WorkflowCompleted	工作流实例完成时引发。	WorkflowCompletedEventArgs
WorkflowCreated	在完全构造工作流实例时，但在处理活动之前引发;即，在工作流开始执行之前。	WorkflowEventArgs
WorkflowIdled	当工作流实例进入空闲状态时引发;也就是说，工作流实例正在等待外部事件 (例如计时器、消息等) 继续执行。	WorkflowEventArgs
WorkflowLoaded	当工作流实例加载到内存中时引发，通常是从持久性存储中。	WorkflowEventArgs
WorkflowPersisted	在保留工作流实例时引发。	WorkflowEventArgs
WorkflowResumed	工作流实例恢复时引发，通常处于挂起或中止状态。	WorkflowEventArgs
WorkflowStarted	在工作流实例开始执行时引发。	WorkflowEventArgs
WorkflowSuspended	工作流实例挂起时引发。	WorkflowSuspendedEventArgs
WorkflowTerminated	工作流实例终止时引发。	WorkflowTerminatedEventArgs
WorkflowUnloaded	当工作流实例从内存卸载到持久性存储时引发。	WorkflowEventArgs

有关各种事件以及工作流如何进入各种状态的详细信息，请参阅本文前面的“管理工作流生命周期”部分。

有关如何使用各种工作流运行时事件的信息，请参阅 Windows Workflow Foundation SDK 示例。

性能计数器

可以使用 Windows 性能工具监视工作流性能。 它由两个部分组成：系统监视器和性能日志和警报。 通过性能日志和警报，可以将性能计数器配置为记录性能数据，并设置系统警报，以便在指定计数器的值高于或低于定义的阈值时通知你。

WF 提供一组性能计数器，其中包含可用于跟踪工作流性能的 WF 性能对象。 有关 性能计数器 的完整列表，请参阅 WF SDK 中的工作流性能计数器部分。

有关如何将性能计数器添加到性能工具的详细信息，请参阅 Microsoft TechNet 网站。

卸载策略

系统可以在给定时间同时运行数千个工作流。 让它们全部保留在内存中可能会变得不切实际。 若要更好地管理系统的资源，可以设置卸载策略来保留工作流状态并从内存中卸载它们。

如果使用现成的持久性服务，则 WF 提供空闲时卸载策略。 在 SqlWorkflowPersistenceService 类上设置 UnloadOnIdle 属性以指示运行时引擎在工作流空闲时卸载工作流时，策略处于活动状态。 如果主机应用程序通过配置文件启用 SqlWorkflowPersistenceService ，可以通过将 UnloadOnIdle 标志设置为 true 来执行此操作。 如果 SqlWorkflowPersistenceService 是通过代码构造和启用的，则主机应用程序必须使用 SqlWorkflowPersistenceService (String、Boolean、TimeSpan、TimeSpan) 构造它。 主机应用程序可以实现其他复杂的卸载策略。

此外，可以调用 WorkflowInstance.Unload () 方法来请求从内存中卸载此特定工作流实例并保留其状态。 主机应用程序稍后可以在实例上调用 Load () 方法，以继续从最后一个持久性点执行它们。 卸载工作流实例时，将引发运行时事件 WorkflowUnloaded 事件。

可靠性和高可用性

WF 通过提供以下支持来支持选择可靠和高可用性的主机：

SQL 群集

基于 SQL 的现成服务支持聚类分析安装。 WF 现成的基于 SQL 的服务在将批处理提交到SQL Server时提供重试。 因此，支持故障转移方案或暂时无法访问的 SQL 服务器。 可以在以下任一服务的组合上设置重试逻辑：

• DefaultWorkflowCommitWorkBatchService
• SharedConnectionWorkflowCommitWorkBatchService
• SqlTrackingService
• SqlWorkflowPersistenceService

默认情况下，重试逻辑为 OFF。 主机应用程序必须显式打开重试逻辑才能使用该功能。 应用程序可以选择对每个服务或前面提到的所有服务启用重试次数。 为此，可以在服务类上设置 EnableRetries 属性，或通过配置文件。 使用配置文件，主机应用程序可以使用共享标志 EnableRetries 在所有受影响的服务上将启用重试设置为 ON 或 OFF。 如果在服务上设置了 EnableRetries 属性，则其值将覆盖 EnableRetries 共享标志值。 WF 现成的基于 SQL 的服务重试固定次数。 重试次数不可配置。 但是，应用程序可以调整服务连接字符串中的连接超时，以部分调整重试之间的时间。

设置重试

以下示例演示如何通过添加通用参数 EnableRetries 并将其值设置为 True 为所有现成的服务设置 EnableRetries。 它演示了如何通过为此服务添加 EnableRetries 标志并将其设置为 False 来禁用 SqlWorkflowPersistenceService 的 EnableRetries。

<WorkflowRuntime Name="SampleApplication" UnloadOnIdle="false">
    <CommonParameters>
        <add name="ConnectionString" value="Initial Catalog=WorkflowStore;Data Source=localhost;Integrated Security=SSPI;" />
        <add name="EnableRetries" value="True" />
    </CommonParameters>
    <Services>
        <add type="System.Workflow.Runtime.Hosting.SqlWorkflowPersistenceService, 
System.Workflow.Runtime, Version=3.0.00000.0, Culture=neutral, 
PublicKeyToken=31bf3856ad364e35" EnableRetries="False"  />
    </Services>
</WorkflowRuntime>

通常，建议将所有服务的重试次数设置为 ON 或 OFF。

请注意， WorkflowCommitWorkBatchService 类负责重试所有非 TransactionScopeActivity 活动 的相关批处理提交 (持久性点) 。 WorkflowCommitBatchService 类无法重试 TransactionScopeActivity 活动的工作批处理提交。 这是因为在这种情况下，它未启动事务，因此不拥有事务。 对 TransactionScopeActivity 活动的工作批处理提交的重试必须建模到工作流中。 这通常以 while 循环和 TransactionScopeActivity 外部的异常处理程序的形式完成。

如果以非事务模式运行，则对现成的 SqlTrackingService 重试，并且现成的 SqlWorkflowPersistenceService 控制与工作批处理提交无关的 SQL 相关工作。 这包括检查过期的计时器和加载工作流实例。

负载均衡和Front-End缩放

托管 WF 的应用程序负责管理负载均衡方案和前端缩放方案。 WF 在引擎和基于 SQL 的现成服务中提供支持，使不同的主机应用程序实例能够指向相同的持久性或跟踪 SQL 数据库。

如果有多个主机应用程序连接到同一个持久性存储，则其中任何一个应用程序都可以从数据库加载任何工作流实例类型。 WF 现成的 SqlWorkflowPersistenceService 不支持分配工作流类型或实例，当它们共享相同的持久性存储时，要加载到特定主机上。 如果此行为不满足主机应用程序需求，则需要实现自定义持久性服务。

当多个主机应用程序使用相同的持久性存储时，WF 运行时引擎提供锁定语义来支持前端缩放方案。 锁定语义阻止应用程序加载已由另一个应用程序加载的工作流实例。 WorkflowPersistenceService 类支持此工作流运行时引擎功能，方法是向 SaveWorkflowInstanceState () 方法提供参数（指定是否应在数据存储中解锁工作流实例的状态信息），并提供 UnlockWorkflowInstanceState () 方法以解锁以前锁定的工作流状态信息。 在实现锁定的持久性服务中，对 LoadWorkflowInstanceState () 方法的调用应锁定工作流实例的状态信息。

有关工作流实例锁定语义的详细信息，请参阅 WF 编程指南中的 Windows 工作流 持久性服务和创建自定义持久性服务 部分。

基本运行时服务

WF 运行时引擎使用运行时服务执行工作流。 运行时服务模型使主机应用程序能够灵活地向 WF 运行时引擎提供各种服务。 本部分介绍 WF 提供的运行时服务以及这些服务的现成实现。

有关运行时 服务 实现的详细信息，请参阅 WF 编程指南中的 Windows Workflow Foundation Services 和开发 Windows Workflow Foundation Services 部分。

WF 运行时提供四项服务。 这些服务具有现成的实现，或者主机应用程序可以实现其自己的服务并将其提供给工作流运行时。

工作流事务服务

Windows 工作流事务服务 (WorkflowCommitWorkBatchService) 的目的是启用有关工作批处理 (也称为 持久性点) 承诺的自定义逻辑。 提交工作批处理时，运行时将调用当前事务服务，并传递委托以调用以执行工作批处理的实际提交。 运行时仍必须执行提交，但是它允许服务将自身插入到进程中，从而支持针对提交进程进行一些自定义。

WF 框架不支持将自己的事务从外部引入工作流实例的功能。 WorkflowCommitWorkBatchService 支持的环境事务类型是工作流实例发起的事务。 执行工作流运行时的主机应用程序发起的环境事务会暂时从当前线程中删除，以减少其副作用。 工作流空闲后，包含的主机应用程序原始环境事务将放回线程中。

WF 为事务服务提供两种现成的实现： DefaultWorkflowCommitWorkBatchService 和 SharedConnectionWorkflowCommitWorkBatchService。

WF 运行时引擎需要工作流事务服务。 默认情况下，它使用 DefaultWorkflowCommitWorkBatchService。 主机应用程序可以选择将 DefaultWorkflowSchedulerService 替换为 SharedConnectionDefaultWorkflowCommitWorkBatchService 或自定义服务。

DefaultWorkflowCommitWorkBatchService

工作流运行时引擎启动时，如果未添加其他事务服务，则会创建 DefaultWorkflowCommitWorkBatchService 的实例并将其添加到 WorkflowRuntime 。 此服务为每个数据库连接创建.NET Framework事务。 例如，SQL 跟踪服务与 SQL 持久性服务之间的连接不共享。 可以在工作流中使用此服务来支持数据完整性所需的事务。

SharedConnectionWorkflowCommitWorkBatchService

此服务用于在不同对象之间使用共享连接的数据库事务。 如果主机应用程序想要使用此服务，它应通过使用 AddService 方法或通过配置文件将其添加到 WorkflowRuntime。

工作流计划程序服务

工作流计划程序服务管理工作流实例由工作流运行时引擎计划的方式，无论这些实例是在异步还是手动同步模式下进行处理。 WF 为 WorkflowSchedulerService 提供两个现成的实现： DefaultWorkflowSchedulerService 和 ManualWorkflowSchedulerService。

WF 运行时引擎需要工作流计划程序服务来执行工作流。 默认情况下，它使用 DefaultWorkflowSchedulerService。 主机应用程序可以选择将 DefaultWorkflowSchedulerService 替换为 ManualWorkflowSchedulerService 或自定义服务。

DefaultWorkflowSchedulerService

DefaultWorkflowSchedulerService 创建和管理在工作流运行时引擎上以异步方式运行工作流实例的线程，并包括对在运行时线程池中排队的多个工作流实例的默认支持。 如果未将其他工作流计划程序服务实例添加到 WorkflowRuntime，则默认使用 DefaultWorkflowSchedulerService 。

ManualWorkflowSchedulerService

ManualWorkflowSchedulerService 用于同步执行工作流实例。 如果使用此服务，则会在主机应用程序的调用线程上执行工作流实例，从而阻止主机应用程序的执行，直到工作流实例变为空闲。

工作流暂留服务

持久性服务负责存储和检索 (加载和卸载) 工作流实例状态。 WF 提供持久性服务的基于 SQL 的现成实现： SqlWorkflowPersistenceService。

SqlWorkflowPersistenceService

此现成的实现将状态和计时器信息存储为 SQL Server/MSDE。 SqlWorkflowPersistenceService 参与工作流事务并实现锁定访问。 此外， SqlWorkflowPersistenceService 提供了在 SQL 服务器不可用时启用重试的功能。 这可以通过在服务上设置 EnableRetries 属性来控制。 有关 SqlWorkflowPersistenceService 的详细信息，请参阅 WF 编程指南。

工作流跟踪服务

跟踪服务管理跟踪配置文件和跟踪信息的存储。 WF 提供 SqlTrackingService 类中实现的跟踪服务的基于 SQL 的现成实现。

SqlTrackingService

此实现将跟踪配置文件和数据存储到 SQL Server/MSDE。 该服务支持以下各项：

• 默认情况下参与工作流事务;行为由 SqlTrackingService.IsTransactional 属性控制。

• 提供一种机制，用于对所有类型使用默认跟踪配置文件，或为每个工作流类型或工作流实例关联跟踪配置文件。

• 通过提供实时和按需分区功能支持数据维护。

  WF 编程指南 的“使用 SqlTrackingService 进行数据维护 ”部分提供了有关数据维护的详细信息。

此外，WF 还提供 SqlTrackingQuery API，可用于查询存储在 SqlTrackingService 中的跟踪数据。 有关 SqlTrackingService 的详细信息，请参阅 WF 编程指南。

结论

WF 提供运行时引擎和服务，用于执行工作流和管理其状态。 必须将主机应用程序或进程写入主机 WF 工作流。 此主机应用程序负责向工作流运行时引擎提供各种运行时服务。 WF 现成的运行时服务旨在解决常见方案。 但是，如果现成的服务不符合主机应用程序的需求，则主机应用程序应实现自定义服务并将其提供给工作流运行时。

此外，WF 还提供基础结构来管理和监视正在运行的工作流实例，并支持选择可靠且高度可用的主机应用程序。 主机应用程序应根据其特定于托管的方案来决定如何使用各种选项。

有关详细信息

本文与以下资源一起，应帮助不熟悉工作流技术的开发人员了解该技术，并快速提高使用效率。

• MSDN 工作流开发人员中心
  • 包含指向网络广播和实验室的文档和链接。
• 社区网站示例
• Windows SDK 文档
  • 如果没有 Windows Foundation SDK，请从 Windows SDK 站点下载它。 Windows 工作流 SDK 是 Windows SDK 的一部分。 它包含 WF 编程指南参考、API 参考以及各种 技术和应用程序示例。
• MSDN 工作流论坛
  • 讨论论坛，可解答与 WF 运行时托管或 WF 一般相关的问题。

 

关于作者

穆斯塔法·哈利勒·艾哈迈德是华盛顿州雷德蒙德 Microsoft Corp.的 WF 团队的项目经理。 自 2000 年加入 Microsoft 以来，他一直致力于开发各种服务器组件，并帮助交付了四种服务器产品，包括 Microsoft BizTalk Server。 在 Microsoft 工作之前，Moustafa 是埃及开罗 ITWorx 的软件工程师、业务分析师和客户经理。