BizTalk Server 2006 or WF? Choosing the Right Workflow Tool for Your Project（BizTalk Server 2006 还是 WF？选择适合您项目的工作流工具）

项目
03/19/2008

肯特·布朗

二十六个纽约 (www.26ny.com)

2007 年 11 月

2008 年 2 月修订

适用于：

Microsoft BizTalk Server 2006

Windows Workflow Foundation

总结：本文将指导在各种应用程序和企业集成工作流方案中在 Microsoft BizTalk Server 2006 和 Windows Workflow Foundation 之间进行选择。 (16 个打印页)

工作流在日常业务流程中无处不在，因此常见的需要是查找直接支持生成工作流解决方案的编程工具。 Microsoft BizTalk Server 2006 和 Windows Workflow Foundation (WF) 是 Microsoft 用于工作流解决方案编程的两个主要工具。但是，由于它们之间存在明显的重叠，许多架构师和开发人员难以确定哪种工作流技术对他们而言有意义。

鉴于 WF 已被明确确定为未来首选工作流技术，而 BizTalk Server 2006 仍然是用于企业集成的高级服务器产品，这一点尤其如此。在BizTalk Server业务流程完全支持 WF 之前，架构师和开发人员必须仔细选择要投资的技术。

为实现工作流选择正确的技术时，一个挑战是工作流可能意味着许多事情，其中包括：

用户与之交互以完成任务的 UI 屏幕流。
应用程序或服务中的业务逻辑流。
多个人的交互以完成业务流程。
协调系统之间的多个消息交换以处理业务事务。
协调用于将数据提取、转换和加载 (ETL) 数据库的步骤。

虽然工作流方案的范围很广，但将其分为四大类会很有帮助：人工工作流、应用程序工作流、企业集成工作流和数据集成工作流。

在四个主要工作流类别中，应用程序工作流和企业集成工作流是人们最难选择技术的两个领域。从工具选择的角度来看，人工工作流和数据集成工作流方案非常简单。人工工作流需要用户界面，并且通常以文档为中心，因此 Microsoft Office SharePoint Server 2007 是构建人工工作流解决方案的推荐平台。 Microsoft SQL Server Integration Services (SSIS) 是数据集成方案的建议工具。

本文将提供在应用程序工作流和企业集成工作流方案中BizTalk Server 2006 和 WF 之间进行选择的指导。

BizTalk Server业务流程引擎

BizTalk Server业务流程引擎一直是BizTalk Server引人注目的功能之一。引入时，它是 Microsoft 可用于执行以工作流为中心的编程的最佳工具。 BizTalk Server业务流程提供了一个可视化编程环境，用于开发组件来控制复杂的多步骤消息流，以完成特定的业务事务。

BizTalk Server业务流程代码项目非常类似于流程图或统一建模语言 (UML) 活动关系图，业务分析师可能会生成活动图来记录业务流程。然后，可以在业务流程引擎运行时中编译和执行这些项目，后者提供长时间运行的事务和补偿、持续性、容错和灾难恢复等服务，这对于构建自动化任务关键型业务事务的系统至关重要。

面向未来的工作流基础

虽然工作流方案有不同的类别，但从编程的角度来看，两个方案之间有足够的共同点，因此有必要尝试为工作流开发建立通用框架。 BizTalk Server 中的业务流程引擎功能强大，但它从未设计为在BizTalk Server之外使用;因此，无法将BizTalk Server业务流程有效地重新用于其他工作流类别。

WF 在 Microsoft .NET Framework 3.0 中发布，它向.NET Framework引入了一个以工作流为中心的可视化编程模型，该模型设计为通用且可扩展，足以用于未来 Windows 平台上所有与工作流相关的方案。生成 WF 的团队能够采用BizTalk Server业务流程引擎的最佳概念，考虑对更广泛的工作流方案的要求，并设计出一个足够灵活的框架来支持所有这些方案。

作为 WF 灵活性的证据，Microsoft Office SharePoint Server 2007 使用它来实现人类工作流解决方案。目的是让第三方 BPM 供应商也基于 WF 构建解决方案，而不是构建自己的专有工作流引擎;一些供应商已经这样做了。单个开发人员还可以使用 WF 在.NET Framework应用程序中实现自定义应用程序工作流。该计划还适用于未来版本的 BizTalk Server，用于在 WF 上实现业务流程引擎，以实现企业集成工作流解决方案。

图 1. 使用正确的工作流工具：BizTalk Server 2006 与 WF

选择合适的工作流工具的过程

我们用于提供指导的方法来帮助你确定哪个工作流工具适合你的项目，即描述最常见的工作流方案，以便你可以确定最适合你的项目的方案或方案组合。然后，我们将为每个方案提供具体指导，说明哪种工具（BizTalk Server 2006 或 WF）最适合，以及原因。此外，我们将利用应用程序平台基础结构优化 (APIO) 模型（用于对组织应用程序平台和开发功能的成熟度进行分级的模型）在有效使用任一工具的方案中提供特定于组织的指导。最后，我们将查看 BizTalk Server 2006 和 WF 的路线图，以便你可以做出最佳决策，使你能够针对当前构建的应用程序做出最佳决策。

常见工作流方案

即使在将我们的范围限制在应用程序和企业集成类别的工作流之后，仍需要考虑广泛的工作流方案。如图 2 所示，在频谱的一侧，WF 显然是正确的选择。例如，独立软件供应商 (ISV) 产品中的工作流功能，其中 2006 BizTalk Server 的许可成本和部署复杂性非常高昂。在这种情况下，作为 ISV，你从事制作商业软件的业务，托管 WF 免版税所需的额外编程工作量是合理的投资。

图 2. 集成和工作流连续性

另一方面是企业 IT 部门内部构建的企业集成解决方案，BizTalk Server 2006 显然是正确的选择。在此方案中，你希望专注于创造业务价值，而不是投资构建“管道”，使解决方案可缩放、可靠且可管理;因此，BizTalk Server 2006 年的许可成本非常值得，因为它提供了什么。

大多数项目都位于光谱的这两端之间。下面是要求决定工作流解决方案的一些常见方案：

UI 页面控制器 — 复杂应用程序中的一个常见要求是，根据正在实现的特定用例的业务规则强制实施 UI 屏幕导航。最简单的示例是一个向导，它引导用户完成一组规定的屏幕以完成任务。通常，它是基于用户操作和数据状态的屏幕导航可能性的更复杂的图形。
模型-视图-控制器 (MVC) 模式是一种经典技术，用于将此导航逻辑从表单本身中拉出，使其更简单、更易于在不同的用例中重复使用。 MVC 模式中的控制器实际上是工作流或状态机;因此，在实现这些类型的应用程序时，寻找工作流工具很自然。
长时间运行的业务逻辑 - 当需要执行许多步骤才能完成业务事务时，用户可能需要在进程中间停止，或者等待其他用户或系统执行的操作，然后才能继续操作。暂时暂停 (或“休眠”) 进程，然后根据外部事件重启它的功能是工作流的核心理念。如果没有工作流引擎，开发人员将被迫手动设计和编写用于存储不完整进程状态的机制，并在进程继续时召回该状态。使用设计良好的工作流引擎，此功能在本机受支持，无需开发人员进行额外的工作。
动态可更新流程流 - 虽然最初似乎有可能将业务流程编入定义完善的顺序步骤，但人类通常必须修改中游流，以考虑到现实生活中的情况。在费用审批过程中，提交支出报表的员工经理可能是默认审批者。但是，例如，经理可能会决定将任务委托给秘书 (，因为经理准备打高尔夫球) 或将审批上报给上级 (，因为经理不确定特定费用) 的策略。允许用户更新流通常比提前预测流的每个可能排列更简单。
从业务逻辑抽象规则 - 在此方案中，目标是将业务规则与其他业务逻辑分开。表单验证规则就是一个很好的示例。在抵押贷款申请计划中，贷款申请表单可能有一组字段验证规则，然后用户才能按“ 提交 ”按钮提交贷款申请。如果贷款人员使用相同的表单来审查和批准贷款，则需要额外的验证规则，因为它处于流程的不同阶段。
从窗体中单独实现验证规则可以更轻松地在不同的方案中重复使用表单，并且只需评估适用于该方案的相应规则集即可强制实施相应的验证规则。
Web 服务聚合器 - 应用程序通常必须聚合来自多个不同 Web 服务的数据。在许多情况下，聚合逻辑本身可以而且应该从应用程序中提取，并作为服务本身公开，可以从其他应用程序重复使用。这些服务通常称为 复合 Web 服务，它们是面向服务的成熟体系结构的重要元素。 Web 服务聚合器方案通常同步且运行时间短。
长时间运行的业务流程 - 本文使用长时间运行的业务流程方案来指定将多个应用程序集成在一起的基于服务器的流程，而 业务逻辑 用于单个应用程序中的逻辑。这些基于服务器的长运行业务流程对多线程处理、异步行为、进程状态持久性、消息与进程实例的关联、可伸缩性、可靠性、事务完整性等的要求远远高于应用程序中的业务逻辑。
企业到企业 (B2B) 流程 - B2B 流程方案本质上与长时间运行的业务流程方案相同，只是前者除了内部应用程序外，还位于组织之间。因此，安全要求至关重要。此外，你对特定数据格式和传输协议的控制甚至更少，因为这些协议可能由业务合作伙伴决定;因此，你需要能够支持各种格式和协议，并支持大量合作伙伴的特定交换配置。
从业务流程抽象规则 - 与业务逻辑中的规则抽象方案类似，此方案适用于你想要将业务规则与长时间运行的业务流程方案和 B2B 流程方案中的业务规则与main代码分开的情况。此方案需要更高级别的性能和可伸缩性。此外，它可能需要工具来允许非程序编写者查看和编辑规则。
企业规则存储库 - 在此方案中，目标是生成可从企业中的所有应用程序调用的中央共享规则存储库。这为组织中的所有应用程序提供一致性，以便应用重要的业务规则。与“业务流程中的规则抽象”方案类似，此方案需要高可伸缩性和工具，以允许非编程者查看和编辑规则。此外，此方案要求规则存储库能够在企业中作为自己的实体存在，具有独立于工作流引擎的托管机制，以及用于从各种应用程序执行规则的组件或 API。
企业服务总线 (ESB) /Message Broker - 许多组织需要为所有服务提供标准化的通信基础结构。此基础结构的两个最常见拓扑是 ESB 和消息代理。发布/订阅消息传送和基于主题的路由是此基础结构通常预期的功能。

应用程序平台基础结构优化模型

在某些工作流方案中，BizTalk Server 2006 和 WF 都令人满意地满足技术要求。对于这些方案，做出正确的工作流技术选择需要将解决方案与特定组织的需求相匹配。为了提出适用于特定组织的建议，我们将使用应用程序平台基础结构优化 (APIO) 模型，如图 3 所示。

图 3. 应用程序平台基础结构优化 (APIO) 模型

APIO 模型是一种技术，用于分析组织在其应用程序基础结构、体系结构和开发实践方面的成熟度。此模型的目标是为组织提供一个路线图，用于优化其提供 IT 解决方案的灵活性，以满足业务需求。

APIO 模型使用以下四个组织的成熟度配置文件：

基本 - 组织将软件视为成本。它们基本上是孤立的应用程序，几乎没有集成或重用。他们拥有的应用程序可能位于各种平台上。它们在基础结构或开发技术上没有一致的标准：它们没有一致的体系结构愿景。
标准化 - 组织仍将软件视为成本，但他们已采取措施提高效率。他们具有体系结构愿景，并尝试考虑重复使用的机会。他们已开始集成某些应用程序，但它们大多是点到点集成。
高级 - 组织将软件视为业务支持者。他们有专门的架构师和清晰的体系结构愿景。它们有许多服务，并实现了高级别的重用。所有核心业务流程都是自动化和监视的。它们使用集中式打包集成平台。
动态 - 组织将软件视为战略资产。他们在愿景和实施方面具有非常成熟的 SOA。它们具有明确的动态版本控制流程和重新部署服务。可以快速适应业务需求更改，并可以快速与新的业务合作伙伴集成。

这不仅仅是你在哪里，而是你要去的地方

APIO 模型中有些隐含的概念是，每个组织都渴望转向动态配置文件。实际上，这取决于业务的性质和关于技术的管理理念。某些企业可能完全满意地保留基本或标准化配置文件。

应考虑当前配置文件以及近期和长期目标，近期目标最为重要。基本配置文件中的组织，希望最终加入动态配置文件，可能明智地选择最初专注于进入标准化配置文件;因此，其技术决策应与标准化配置文件基本一致。

一般来说，BizTalk Server 2006 将更适合在高级或动态配置文件中具有近期目标的组织。基本配置文件中对此配置文件相对满意的组织可能既没有采用 2006 BizTalk Server的战略动机，也没有有效利用它的能力;因此，他们不太可能想要进行投资。但是，如果基本配置文件中的组织已决定积极转向高级配置文件，则采用 BizTalk Server 2006 可能是朝着该方向迈出的战略步骤。

在讨论中引入 APIO 模型的要点是，充分了解组织的当前和有针对性的 APIO 配置文件将有助于在 WF 和 2006 BizTalk Server之间做出决定，这两种技术何时都能很好地支持技术方案。两个不同的组织很可能做出不同的选择，每个组织都为其组织配置文件做出正确的选择。

一切都在主机中

在 BizTalk Server 2006 和 WF 之间进行选择时要考虑的最重要方面之一是工作流的托管要求。与 BizTalk Server 2006 不同，WF 不提供“现成”的托管;你必须实现一个主机来建立 Windows 进程并启动工作流运行时引擎，在其中执行工作流。

为了构建能够实际支持所有工作流方案的框架，WF 抽象化了环境（如 BizTalk Server 2006）提供的核心行为，以便各种主机可以为这些服务提供特定的所需行为。

WF 工作流主机提供的核心服务如下：

计划服务 - 创建和管理运行时引擎用于执行工作流实例的线程。
提交工作批处理服务 - 管理运行时引擎用于数据库操作的事务。
持久性服务 - 当运行时引擎指示工作流实例执行此操作时，处理工作流实例的持久性。此服务是可选的。如果未提供，则不会保留工作流实例，并且它们必须在其整个生存期内在内存中运行。
跟踪服务 - 提供在工作流中记录跟踪事件的功能。此服务是可选的。

生成工作流主机需要什么

根据工作流方案和必须提供给工作流的服务，构建 WF 主机可能琐碎或令人不禁。对于工作流在应用程序上下文中的方案，托管 WF 非常简单。应用程序本身充当进程主机，并且核心服务的标准实现只需最少的工作量即可进行配置。

但是，当你进入高度可缩放的基于服务器的方案中时，主机的必要复杂性会大幅提升。表 1 显示了可能需要的主机服务的洗衣列表，其中大多数服务在 2006 BizTalk Server提供。

表 1. 主机服务

扩展配置
负载均衡
故障转移
限制
线程管理
内存管理
服务隔离
异常配置
失败的消息管理
消息跟踪

存档和清除
标识和模拟
多环境部署模型
运行状况监视
利用率/性能跟踪
复合进程状态管理
脚本编写
灾难恢复
法规符合性
配置管理

不管怎样，你从事什么业务？

如果你的任务是生成一个具有紧迫期限的特定应用程序，你可能不希望团队在应专注于实现必要的业务逻辑时，不得不构建复杂的主机来分散注意力。在这种情况下，BizTalk Server 2006 非常值得投资购买（而不是尝试构建）一个可靠的工作流主机。如果你是大公司的中心体系结构团队的一员，则可以选择投资构建一个可以在整个组织中使用的主机。即便如此，这一努力也不应掉以轻心。

Workflow-Technology建议

对于应用程序中的方案：WF

对于应用程序中包含的所有方案（包括 UI 页面控制器、长时间运行的业务逻辑、可动态更新的过程流、Web 服务组合和业务逻辑中的规则抽象），WF 是正确的工作流技术选择。

在大多数以应用程序为中心的方案中，使用模式需要在应用程序和工作流之间进行同步、低延迟的交互，这与 BizTalk Server 2006 的强度不相同。出于性能原因，2006年BizTalk Server不适合这些方案：BizTalk Server业务流程在专用 BizTalk 服务器上运行，并且从客户端应用程序调用它们需要跨网络进行往返。此外，2006 BizTalk Server将每条消息保存到 MessageBox 数据库以提高持久性的设计引入了额外的延迟，如果必须同步调用工作流，在交互式 UI 的上下文中，这种延迟可能不可接受。

WF 更适合这些方案;它满足工作流要求，并且比 2006 BizTalk Server更简单、更便宜。在这些方案中，不需要 BizTalk Server 2006 的消息传送功能（例如映射和适配器）。托管服务的要求适中，因此在应用程序中托管 WF 运行时不需要大量的工作。

对于大多数Business-Process方案：BizTalk Server 2006

对于大多数涉及基于服务器的业务流程的方案，BizTalk Server 2006 是正确的选择。其中包括 B2B 流程、业务流程中的规则抽象、企业规则存储库和企业服务总线 (ESB) /Message Broker。

这些方案需要高可伸缩性。此外，它们需要能够查看正在运行的进程，以及停止和重启它们。最后，它们需要支持横向扩展到多个服务器。在这些方案中，BizTalk Server 2006 的高级托管功能是必需的，并且非常值得投资。

基本	标准化	高级	动态
WF → BizTalk Server 2006	BizTalk Server 2006	BizTalk Server 2006	BizTalk Server 2006

图 4。长时间运行的业务流程方案

BizTalk Server 2006 通常将成为长时间运行的业务流程方案的最佳平台。这些进程往往是异步的、长时间运行的和有状态的。这些流程通常是组织的任务关键型;因此，它们需要高可用性、可见性、安全性和可管理性。 BizTalk Server 2006 的组或“场”拓扑允许管理服务器数组以提供可伸缩性和冗余。

BizTalk Server 2006 用于存储进程状态的持久性机制内置了强大的安全性，以保护持久状态的隐私，这可能出于法规原因而非常重要。 BizTalk Server 2006 的 Business Activity Monitoring (BAM) 以安全的方式提供对正在运行的流程的适当业务级别可见性。最后，这些方案通常需要支持异类消息格式和传输协议，包括旧系统。

出于这些原因，BizTalk Server 2006 通常是面向标准化、高级和动态配置文件的组织的最佳选择。这些组织通常认为长时间运行的业务流程方案对业务非常重要，在企业中非常常见;因此，他们购买BizTalk Server 2006年专门为他们建立一个标准化的平台。

但是，对于基本 APIO 配置文件中的组织来说，WF 可能是更好的选择。这些组织通常不希望投资构建标准化的应用程序平台。相反，他们希望将成本降到最低，BizTalk Server 2006 的许可和硬件成本可能令人望而却步。本指南的例外情况是，对于高可伸缩性、监视以及对各种消息格式和传输协议的支持有要求。在这种情况下，尽管组织不愿对其应用程序平台进行投资，但从头开始构建托管和消息传递功能的成本可能会超过 2006 BizTalk Server的成本。

基本	标准化	高级	动态
WF	WF → BizTalk Server 2006	BizTalk Server 2006	BizTalk Server 2006

图 5。 Web 服务聚合器方案

BizTalk Server业务流程和 WF 工作流都对工作流中的外部使用 Web 服务以及将工作流公开为 Web 服务提供强有力的支持。因此，对于生成 Web 服务聚合器解决方案，与长时间运行的业务流程解决方案一样，选择取决于组织配置文件和托管要求。

如果聚合 Web 服务仅用于聚合其他 Web 服务，BizTalk Server 2006 支持异类消息格式和传输协议的能力几乎没有增加任何价值。但是，如果服务还应聚合未作为 Web 服务公开的旧环境中的数据，BizTalk Server 2006 将增加价值。

由于使用模式是快速的同步请求/响应调用，因此BizTalk Server 2006 提供的消息持续性通常并不重要。事实上，由对 MessageBox 的持久性引入的延迟实际上是一种责任。 BizTalk Server 2006 为此方案提供的main值是能够跨多个服务器管理部署并监视正在运行的实例。 BizTalk Server 2006 的 BAM 功能还可用于监视满足服务级别协议 (SLA) 。

出于这些原因，WF 非常适合用于实现 Web 服务聚合器，尤其是在基本配置文件和标准化配置文件中的组织中。 BizTalk Server 2006 可能有利的一个示例是，你必须为不同的客户端组织管理大量终结点。 BizTalk Server 2006 的接收端口和接收位置配置专门处理此问题。在这种情况下，证书可能也很重要，BizTalk Server 2006 对配置和管理证书以及将其应用于加密/解密的支持可能很有用。

Future-Proofing

你希望确保在软件许可成本、学习工作流技术以及构建特定工作流组件方面的投资将在未来为你提供最大的价值。除了为特定的工作流方案和组织选择正确的工作流外，还必须考虑 BizTalk Server 2006 和 WF 的产品路线图。这不是一个简单的答案。下面的评论并没有为选择任一技术提出强有力的论据：相反，它们是有助于做出决策的数据点。

BizTalk Server 2006 R2 添加的内容

BizTalk Server 2006 R2 添加了两个可能会影响所选工作流平台的功能：WCF 适配器以及 WCF 和 WF 的 BAM 侦听器。

WCF 适配器

如果你的团队已采用 Windows Communication Foundation (WCF) 作为在生成 SOA 时实现服务的标准技术，则BizTalk Server 2006 没有 WCF 支持的事实可能已取消它作为构建和托管复合 Web 服务的平台的资格。即使 BizTalk Server 2006 与你的方案和 APIO 配置文件非常匹配，这可能已将你推到了 WF。

幸运的是，随着 BizTalk Server 2006 R2 中引入出色的 WCF 集成，这不再是一个问题。 BizTalk Server 2006 现在与 WCF 具有强大的集成，它是一个出色的平台，用于从更精细的服务中生成复合服务，并将这些复合服务公开为 WCF 服务。

WF 的 BAM 侦听器

第二个相关BizTalk Server 2006 R2 功能是引入适用于 WF 的 BAM 侦听器。如果业务活动监视是解决方案的一项重要功能，则当 WF 更适合你的方案时，你可能已被迫使用 BizTalk Server 2006（只是为了利用 BAM）。使用适用于 WF 的 BAM 侦听器，如果 WF 是适合项目的工作流技术，并且仍然将 BAM 用作企业业务活动监视解决方案，则可以选择 WF。

BAM 是 BizTalk Server 2006 的一项功能，它提供一个框架，用于从BizTalk Server业务流程和消息流捕获事件和数据，并在门户中显示该数据，以便业务用户能够端到端地了解业务流程。 BAM 适用于 BizTalk Server 2006 应用程序的一个强大方面是，在部署 BizTalk Server 2006 应用程序后，可以 (或“检测”) 配置 BAM 监视，而无需修改 BizTalk Server 2006 代码项目。

BAM 设计为企业范围的业务活动监视解决方案;因此，非 BizTalk Server 2006 应用程序可以将事件和数据馈送至 BAM。但是，执行此操作的 API 需要在外部应用程序中编写大量代码。 BizTalk Server 2006 R2 中的 BAM WF 侦听器提供了更简单地检测 BAM 的 WF 工作流的功能，而无需修改代码。通过使用 BAM 侦听器，可以跟踪业务流程，而无需重新编译 WF 或 WCF 解决方案;集成是通过配置文件完成的。

适用于 WF SDK 的 BizTalk Server 2006 扩展

BizTalk Server 2006 扩展的 WF SDK 在 TechEd 2007 上发布并演示。此 SDK 提供用于在 BizTalk Server 2006 中托管 WF 工作流的简单机制。此工具适用于目前正在构建 WF 工作流的 .NET 开发人员，并寻求一种简单方法来实现这些工作流的可靠、可缩放的托管。

SDK 提供两个自定义 WF 活动（一个 btsReceive 活动和一个 btsSend 活动），可在 WF 工作流中用于通过 BizTalk Server 2006 接收和发送消息。作为开发人员，你可以为入站和出站消息定义 WCF DataContracts ，并为 ServiceContract 定义消息交换模式。在 WF 工作流中，btsReceive 和 btsSend 活动配置为使用定义的 ServiceContract，如图 6 所示。

图 6。 btsReceive 和 btsSend 活动，用于定义的 ServiceContract

完成并编译 WF 工作流后，右键单击工作流项目并选择“生成业务流程”以自动生成包装业务流程 (请参阅图 7) ，它将启动 WF 工作流并将BizTalk Server 2006 消息路由到该工作流和从中路由 2006 消息。

自动生成的包装器业务流程包含 ServiceContract 中定义的消息的架构。它还包含 BizTalk Server用于接收BizTalk Server 2006 消息、创建和启动工作流实例、将入站消息 () 传递到工作流实例、接收出站消息 () 以及将它们转发回 BizTalk Server 2006 消息传送引擎的业务流程形状和代码。若要完成 WF 工作流的托管，只需编译和部署包装器业务流程，并使用正常的 BizTalk Server 2006 机制进行绑定。

图 7。自动生成包装器业务流程

除了利用适用于 WF 工作流的 BizTalk Server 2006 的可靠且可缩放的托管机制之外，BizTalk Server 2006 Extensions for WF SDK 还允许你利用 BizTalk Server 2006 消息传送基础结构。因此，可以利用许多可用的适配器将消息传入和传入BizTalk Server 2006，以及管道处理，包括映射功能。

BizTalk Server 2006 Extensions for WF SDK 虽然功能强大，但应用作一种工具，允许 WF 开发人员在 BizTalk Server 2006 的基础上部署其工作流，而不是在我们确定BizTalk Server 2006 为适当工具的情况下替代业务流程。某些 WF 形状在业务流程中包装时不起作用。这是因为使用 BizTalk Server 2006 扩展 for WF SDK 在 BizTalk Server 2006 中托管 WF 工作流不会提供与本机业务流程相同的托管行为。 SDK 有一个常见问题解答列表 (包含在快速入门指南) 中，其中概述了这些差异。

结论

BizTalk Server 2006 和 Windows Workflow Foundation 是 Microsoft 用于在应用程序和企业集成工作流类别中实现工作流解决方案的主要工具。若要选择适合你的项目，首先必须确定要面向的工作流方案。

接下来，使用图 8 中的表查看适用于你的方案的建议工作流技术。对于应用程序中的工作流，建议使用 WF。对于大多数基于服务器的业务流程和 B2B 方案，建议BizTalk Server 2006。

图 8。特定于方案的工作流技术

对于长时间运行的业务流程和 Web 服务聚合器方案，这两种技术都可以有力地应用。对于这些方案，应评估组织的当前和近期目标 APIO 配置文件。处于高级配置文件或动态配置文件中的组织应对这些方案使用 BizTalk Server 2006。 “基本”和“标准”配置文件中的组织可以针对这些方案有效地使用 WF。

最后，应考虑解决方案的发布日期和所需的生存期，相对于 BizTalk Server 2006 和 WF 的产品路线图。使用此框架和本文中的指南，应该能够为项目选择正确的工作流。

附录

消除关于 BizTalk Server 2006 年与 WF 的误解

以下是关于 WF 和 2006 BizTalk Server 的一些常见误解，以及我们用来消除这些错误的明确论点：

WF 是 2006 BizTalk Server 的替代项。不。由于 WF 是 Microsoft 提供的用于编程工作流的“最新且最伟大的”产品/服务，许多不熟悉 BizTalk Server 2006 的人最初都认为 WF 的发布已过时。纠正这种印象的简单答案是，WF 是用于生成各种工作流的低级开发人员框架，而 BizTalk Server 2006 是一款完整的服务器产品，具有适用于特定工作流方案类别的高级功能：企业集成。 (见图 1.)
WF 仅提供此功能的一小部分：工作流和业务规则。虽然对于不需要 BizTalk Server 2006 提供的所有其他功能的方案，WF 可能是更简单、更具成本效益的解决方案，但它绝不会取代 2006 BizTalk Server 2006 设计支持的核心企业集成方案BizTalk Server 2006。
BizTalk Server要走了不。类似的误解是，由于 WF 作为未来的工作流工具发布，并且BizTalk Server尚未重写为使用 WF，因此 Microsoft 不再投资BizTalk Server，最终会将其替换为基于 WF 的新产品。情况并非如此：BizTalk Server是一个非常成功的产品，它面向的企业集成领域仍然是 Microsoft 致力于提供支持的领域。
你必须选择2006 BizTalk Server比.NET Framework。不。对于不熟悉 BizTalk Server 2006 的 .NET 开发人员来说，选择 WF 而不是 BizTalk Server 2006 可能会很诱人，只是因为他们宁愿使用“纯”.NET。然而，这实际上不是一个有用的标准：BizTalk Server 2006 本身建立在.NET Framework之上。
事实上，BizTalk Server 2006 表示可应用于解决方案的 200 多万行 .NET 代码，从而节省从头开始开发其功能的时间、麻烦和成本。此外，BizTalk Server 2006 编程本身是在 Microsoft Visual Studio .NET 中完成的，组件作为 .NET 程序集进行编译和部署。此外，最重要的BizTalk Server 2006 项目将 BizTalk Server 2006 组件与自定义 .NET 组件相结合;因此，BizTalk Server 2006 开发应被视为专用的 .NET 开发，而不是外部或不同的开发。
真正的问题是，BizTalk Server 2006 功能是否为你的特定工作流方案提供足够的价值来证明许可成本的合理性。你不想用大锤挂照片：你也不想用木匠的锤子压碎大石头。
功能最多胜出。一个糟糕的选择。我们可以建立一个特征矩阵，将 WF 的粒度特征与 2006 BizTalk Server 特征进行比较。但是，这种比较没有很大帮助：BizTalk Server 2006 具有大量专门针对企业集成空间的功能。如果这不是目标方案，则功能比较将毫无意义。 BizTalk Server 2006 在功能检查框的数量方面可能会获胜;但是，如果这些功能与目标工作流方案无关，则这是一个苹果到橙色的比较。

致谢

我要感谢保罗·安德鲁和克里斯·霍罗克斯，以及所有评论这篇文章的人。

通过