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

Aa663362.hostingwwf01(en-us,MSDN.10).jpg

图 1. Windows Workflow Foundation 主机进程

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

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

管理工作流实例生命周期

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

持久性点

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

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

Aa663362.hostingwwf02(en-us,MSDN.10).jpg

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

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

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

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

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

工作流实例事件

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

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

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."开始"菜单 () 时,将引发 WorkflowStarted 事件。 工作流运行时引擎开始执行工作流活动之前会引发工作流启动事件。

WorkflowSuspended

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

WorkflowTerminated

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

WorkflowUnloaded

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

工作流实例事件转换

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

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

Click here for larger image

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

如果启用了持久性服务,则会发生持久性点,如图 3 所示。 这些主机应用程序应会看到 WorkflowPersistedWorkflowUnloadedWorkflowLoaded 事件(如果适用)。 如果工作流实例不在内存中,并且启用了持久性服务,则实例上的任何有效操作 (恢复中止终止等) 导致工作流实例先加载,然后继续完成请求。 例如,如果你有挂起但已卸载的工作流实例,请在它上调用 Resume ,使其首先加载,然后继续引发关系图中所示的 Resumed 事件。

工作流实例操作

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

WorkflowInstance。"开始"菜单 ()

启动已创建的工作流实例的执行。 WorkflowInstance。"开始"菜单 () 会导致工作流运行时引发 WorkflowStarted 事件,并且工作流实例处于“正在运行”状态。 如果在已启动的工作流实例上调用了 "开始"菜单 () ,则会引发 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 事件。 如果没有已注册的持久性服务,则会引发 InvalidOperationException ;如果未调用 Unload ()

WorkflowInstance.TryUnload ()

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

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

可管理性和监视

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

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

跟踪

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

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

有关使用跟踪监视工作流的详细信息,请参阅应用程序示例/工作流监视器示例中的 工作流监视器 SDK 工具 。 有关如何生成自定义跟踪服务的示例,请参阅 Technology Samples/Tracking 中的 ConsoleTrackingService 示例文件跟踪服务和查询示例 。 有关如何使用现成的 SqlTrackingService 的示例,请参阅技术示例/Trackingout-of-box 中使用 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,并将所有日志记录信息发送到它们。 使用示例中的剩余行可以指定命名空间来捕获日志记录信息,以及跟踪的信息量。 值属性的可能值包括 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的现用服务支持群集安装。 将批处理提交到SQL Server时,WF 现成SQL服务提供重试。 因此,支持故障转移方案或暂时无法访问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 为事务服务提供两个现用实现: DefaultWorkflowCommitWorkBatchServiceSharedConnectionWorkflowCommitWorkBatchService

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

DefaultWorkflowCommitWorkBatchService

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

SharedConnectionWorkflowCommitWorkBatchService

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

工作流计划程序服务

工作流计划程序服务管理工作流实例由工作流运行时引擎计划的方式,无论是在异步模式还是手动同步模式下处理它们。 WF 为 WorkflowSchedulerServiceDefaultWorkflowSchedulerService 和 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 还提供可用于查询 SqlTrackingService 中存储的跟踪数据的 SqlTrackingQuery API。 有关 SqlTrackingService 的详细信息,请参阅 WF 编程指南。

结束语

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

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

有关详细信息

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

 

关于作者

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