发布日期： 2004 年
1 月 适用范围：
Microsoft BizTalk Server 2004 简介要想用一种动态的和高性价比的方式实现业务流程的自动化和维护这种业务流程，将是一个十分具有挑战性的工作。即使对那些拥有最高水平技术的组织，亦是如此。然而幸运的是，一种崭新的应用程序开发和集成机制已应运而生，它可以有效解决这些问题。这就是“面向服务的体系结构”（Service
Oriented Architecture，SOA）。 (该方法基于XML和Web服务技术并已集成于业务流程管理和企业应用集成（BPM/EAI）平台) SOA 模型的出现，使得应用程序的概念被重新定义。应用程序不再是一种非透明、程式化的实现机制。相反，它是一个由通讯、路由、处理和转换事件构成的和谐体系，可以处理丰富(XML)文档公开声明的属性。 工作流程、集成应用或者业务伙伴的交流都是SOA
模型的特定类，仅通过有关参与者的特性、执行位置以及参与者的特有安全需求来区分。融合了
SOA 模型后，BPM/EAI 平台将变得如虎添翼，它们可以在开发和操作方面体现诸多优点： ·
它们可以改善严重的低效开发现象，并且为实现有效的生命周期维护减少障碍。 ·
它们有利于在高度分散的基础上对组件实现灵活的“松散耦合”。 ·
它们允许在不影响流程的情况下添加、删除和重新配置任何流程操作。 ·
它们从根本上为长期运行的异步事务提供支持，并且这些事务可以灵活地缩放。 ·
它们为应用程序的良好管理和监视提供了保证，因为进程操作、组件和函数都是公开的，并且都能自我描述。 ·
借助它们，可以对应用程序组件和整个应用程序进行扩展或者重新利用。 ·
它们可以利用 Internet 网络基础设施和 World Wide Web 协议标准。 使用基于 SOA 模型的开发环境需要对应用程序的开发概念和思想进行重新定位。在本文中，我们介绍了最基本的
SOA 概念和开发思想。随后从两个具体的环节上探讨了
Microsoft® EAI 开发环境，即 BizTalk®
Server 2004，是如何实现这些概念和思想的。这两个环节是： 所创建应用程序的设计、行为和功能；以及开发过程本身。本文最后介绍了同 Visual Studio® .NET 集成在一起的 BizTalk Server 开发工具是如何在 .NET
Framework 架构和 SOA 模型之间搭起一座桥梁的。 BizTalk Server – SOA 实现如果您希望获得上述的开发和操作优点，则在 BizTalk Server 中实现
SOA 的价值也就不言而喻了。首先，我们可以审视一下开发过程的低效现象以及 BizTalk Server 解决它们的具体方式。 传统的编程思想不足以将应用程序或业务流程的概念模型（例如：设计规范）转换成可执行的形式（即程序）。尽管开发注释系统（如
UML）允许业务分析人员使用结构化方法编写功能规范和使用范畴，但编程人员仍需要对这些文档进行分析，并将其意图转换为不同的语言和结构。这种手工化并且需要高度分析的转换过程有着非常明显的不足之处，这就使得效率低下，尤其是需要反复进行修订。一旦将业务流程精确地转换为程序代码，另一个问题通常又会凸现出来： 同代码所模拟的业务流程相比，代码的行为更加缺乏可预见性。这种偏差来源于程序化代码实现方法的本质。程序化代码同机器执行模型紧密联系在一起，在它对业务流程的不透明体现中封装了多个级别的相互联系、相互依存的功能。其结果便是：程序化代码非常容易导致程序错误，而这些错误往往很难和需要大量的时间来进行识别和修正。这样就不难理解，为何在软件稳定运行后就不鼓励进行后续修改。通常的情况是，即使到了非修改业务流程不可的时候，也会容忍这些僵化的代码所存在的种种限制。 BPM/EAI 开发环境允许业务分析人员和编程人员在一个融合并关联了两者各自任务的可视化流程模型上使用公共的工作区进行协作。通过使用拖放式的图形用户界面对代表消息、消息事件、业务规则和逻辑、信息流、活动、操作、转换以及子流程的高级对象进行协调安排，编程人员和分析人员可以协同创建应用程序。而模型自身会直接针对流程生成可执行的运行时程序集。这种机制将传统方法所固有的模糊性和大量修订过程减少到最低程度，从而大幅度提高开发效率和灵活性。尤其是，对于那些极度复杂的函数，比如需要两步式的事务提交过程、回滚
ACID 事务支持以及嵌套和并行操作，它都将其实现机制内置于对象的函数中，因此不再需要编写复杂的程序语句来实现这些功能。 为了更好地说明 SOA 开发机制，下述步骤介绍了在遵循该模型的 BizTalk Server 中创建应用程序的过程： 1.
创建在应用程序/流程中涉及的文档及其各自的架构定义。 这将在“架构编辑器”（BizTalk Schema
Editor）中完成。“架构编辑器”是一个
BizTalk Server 模块，可从 Visual Studio .NET 内访问。通过架构编辑器，您可以定义结构和语义方面的元数据。对从该架构创建的文档（即一个“实例”），这些元数据“声明”了其内容的含义、功能和处理要求。当 BizTalk Server 收到一个文档实例时，同该文档关联的流程会根据该文档的架构定义来检查其内容，以确保该文档的形式和内容都符合架构以及符合应用程序的处理要求。BizTalk Server 架构编辑器可以为架构创建符合 W3C 标准的 XSD 文档以及可视化的树状节点参考模型。以下是架构编辑器的示例。该架构编辑器在左窗格中显示了架构的树状节点模型，在右窗格中显示了文档架构的 XML 表示形式。 
2.创建和定义面向任何文档交换操作的转换要求。
如果应用程序是由
XML 对象之间的松散交互组成的，文档转换将是一个在功能上向外界暴露的映射子过程。在 BizTalk Server 中，这种子过程将通过 BizTalk Server 映射器来创建。通过转换映射，可对任何源信息（基于其架构表示）的内容和结构进行处理，然后转换为任何目标文档格式（比如报告）。通过使用与
BizTalk 架构编辑器一样的架构树状节点模型，BizTalk
Server 映射器可以用可视化的方式显示源信息和目标信息的格式。信息可以从源架构的一个或多个节点映射到目标架构的一个或多个节点，方法是用线条连接这些节点。Functoid
提供了补充性(额外的)的转换、处理和解析功能（循环、累加、日期和时间、递归，等等）。通过（图形化实现）将一个或多个源节点连接到某个 functoid，然后将该 functoid 连接到一个或多个目标节点。 
每个转换映射（以及所涉及的源和目标架构）都将变成 BizTalk
Server 的项目资源，随后可作为一个流程环节将这些资源嵌入业务流程中并编译成业务流程程序集。可以根据需要重新利用和修改映射，以实现任意数量的转换要求以及将它们部署在任何数量的业务流程中。BizTalk
Server 映射器创建的映射基于转换 XML 信息的开放式标准协议，即 XSLT。
3. 指定控制事件执行的业务逻辑。 
如果业务逻辑比较简单，则可以将它作为一个表达式直接嵌入到 BizTalk Server 业务流程决策步骤中。如果业务逻辑比较复杂，可以使用 BizTalk
Server 业务规则设计器来创建和处理复杂的规则集。每个规则集（或者说“策略”）驱动一种特定的操作或功能，并且将成为内嵌在 BizTalk Server
业务流程中的资源对象。
同整个 BizTalk Server 架构一样，创建和实现业务规则的整个过程也是透明的，并且联系松散。一个嵌入BizTalk Server业务流程的业务规则集可以在设计或者运行时被查看、修改或者完全被替换而不影响其它的流程操作或者中断本流程的实例的运行。由一个向外界暴露功能的组件化规则引擎提供灵活修改商业流程的特点具有极其重要的意义。在传统的应用程序开发过程中，业务规则逻辑嵌入在程序的代码之中，如果不修改代码，则无法修改这些业务逻辑。由于对业务流程生命期的大多数修改都仅限于业务规则的变动（相对与技术方面的修改），因此是否能将业务规则同程序代码完全隔离开来，或者同任何流程实现机制隔离开来，将决定是否能大幅度提高在整个业务流程生命期中管理和调整业务流程的效率。
在定义业务规则方面，BizTalk Server 业务规则编辑器支持创建同行业领域有关的词汇，其功能是通过公共接口呈现的，因此它具有极其高的灵活性和扩展性。下图显示了
BizTalk Server 业务规则编辑器模块。 4. 确定和实现消息前期处理和后期处理的要求。 这一步在 BizTalk
Server 管道设计器模块中完成。管道设计器可从
BizTalk Server 的业务流程工作区访问。该模块用于实现同外部应用程序和团体在交换上的加密、身份验证和数据格式转换要求。 
管道是指在业务流程或消息数据仓库收到消息或从它们分派消息之前发生的处理操作序列。“接收管道”可根据要求接受传入的消息、将消息解密或解压缩、将消息分解成消息的部件，将消息转换为
XML 文档（按照在 BizTalk Server 架构中的说明）、验证消息以及验证消息发送者的身份。一旦有消息通过管道，该消息就会被传送到
BizTalk Server 的MessageBox存储。“发送管道”执行的操作与“接收管道”相同，只不过是反方向的。它可以根据外部接收者的要求对消息进行组装、格式化、加密、压缩和数字签名。
5.
编辑和编排应用程序/流程环节。 这一步在
BizTalk Server 业务流程设计器中进行。业务流程设计器是 Visual
Studio .NET 中的主要工作区，在此可以开发和实现完整的 BizTalk Server 应用程序。通过拖放业务流程工具箱上的对象形状并将它们连接在一起，可以编排业务流程图表。这些形状代表了各种流程活动，比如接收、调用、序列、流程、连接和来源。借助这些形状，可以编辑和执行消息流、消息事件、业务规则、活动、操作、转换以及子流程。 下图显示的 BizTalk
Server 业务流程图表实现了这样的工作流程： ·
流程应用程序（一个BizTalk Server 业务流程）收到一个库存订单补给请求（“Request”）。 ·
流程应用程序检查所订购商品的数量。如果订单的商品数量超过
500 件，则拒绝该订单。如果订单的商品数量未超过 500 件，则接受该订单。 ·
如果订单被拒绝，将创建通知（“ReqDenied”）并发送给进行订购的人员。 ·
如果接受了订单，则原始的订单请求将被提交给
ERP 系统处理。 
在编辑如图所示的流程图时，可以从工具箱中拖放下列形状，然后对其进行修改： ·
在设计窗口的顶部放置一个“接收”（Receive）形状，并将其命名为 Receive_Req。 ·
在 Receive 形状之下放置一个“决策”（Decision）形状，并将其命名为 CheckQuantity。 该决策形状会自动创建两个活动分支形状（“If”或者“Else”）。If 形状被重命名为
Decline。Decline 形状被连接到一个表达式编辑器。在该编辑器中创建了“RequestInstance.Item.Quantity >
500”的 XPATH 表达式。该
XPATH 表达式将按照“If”规则（该规则指定了对订单请求的拒绝条件）执行操作。 ·
在 Decline 形状之下放置一个“构造消息”（Construct Message）形状，并将其命名为Construct_ReqDenied。 ·
在 Construct_ReqDenied 形状中放置一个“转换”（Transform）形状。 ·
在 Construct_ReqDenied 形状之下放置一个“发送”（Send）形状，并将其命名为
Send_ReqDenied。 ·
在 Else 形状图形之下放置一个“发送”（Send）形状，并将其命名为 Send_REQToERP。 6. 将设计形状同实现对象链接起来。 编排了各个流程步骤之后，下一步是将这些形状同为实现流程而所需的对象链接到一起。这些对象可能包括实际的消息文档、发送和接收消息的端口位置以及为了传送消息而要求的传输机制。该阶段也同样在业务流程设计器中执行。 在业务流程图表示例中，当运行的进程收到一个 Request 文档实例时（注意，该进程是 Receive 形状启动的），该进程会根据该文档的架构定义来检查其内容，以确保该文档的形式和内容都符合架构以及符合应用程序的处理要求。如果 Request 文档不符合要求，嵌入在
Construct Message 流程中的 Transform 子流程将引用一个负责将 Request 文档转换为 ReqDenied 文档的 XSLT 转换映射（按照在步骤 2 中的说明）。 7.
如果可行，定义团体和团体的角色，并将其连接到业务流程功能。 这一步在
BizTalk Server 浏览器（为构成具体 BizTalk Server 项目的业务流程和外部组件提供配置信息的工具）中完成。该浏览器以分层的树状结构组织。借助该浏览器，可以配置项目业务流程编排同其它项目组件（比如角色、团体、发送和接收端口以及接收位置）的关系和交互。 在业务流程编排图表中实现了所有的逻辑步骤之后，则可通过对该业务流程图表执行“生成”操作来生成
Visual Studio .NET 运行时程序集（DLL 文件）。该程序集可作为一个单独的应用程序来实现，或作为一个组件包括在更大的
BizTalk Server 解决方案中。 BizTalk Server 解决方案（一个流程应用程序）包括一个或多个
Visual Studio .NET 项目，而后者又含有架构、业务流程、转换映射和管道等
BizTalk Server 组件。就以此前介绍的示例来说，在一个不连续的 BizTalk
Server 项目（该项目生成经过编译的程序集）中包含有Request 和
ReqDenied 文档以及它们的转换映射。 在该解决方案中，对流程进行了详细描述的 BizTalk Server 业务流程图表也是一个不连续的 BizTalk Server 项目。通过引用（封装）架构和映射程序集，该编排图表可以像功能对象那样引入这些架构和映射。随后可将所有的
BizTalk Server 项目程序集作为在 BizTalk
Server 运行时引擎管理下的可执行应用进行部署和安装。 SOA —— 底层技术
介绍了如何使用 BizTalk Server 2004 中的高级工具来开发和实现应用程序之后，现在我们可以站在面向服务架构
(SOA) 模型的底层支持技术的角度来审视这种开发思想。如前所述，SOA
的基本原则是暴露功能、用文档交换信息、松散耦合以及平台无关性。XML 提供了透明性和应用程序无关性，它使用元标记“声明”数据的含义和作用。使用
XML 的前提条件是，将同程序相关的数据转换为自我描述因此同程序无关的数据。这不仅涉及内容，而且还包括用来处理内容的指令。 XML 架构提供了语义上的一致性和互操作性。作为一种规范，XML
架构为创建 XML 文档正式定义了一组扩展的数据类型基元和结构组件；其作用就有如用来提取元素、属性实体和组织规则的一本词典。创建符合架构“词典”的
XML 文档将具有非凡意义： 对支持 XML 并且可以访问 XML 文档的底层架构的应用程序来说，可以了解 XML 文档内容的含义、功能和使用方法，并且可以执行相应的操作。在各个行业中，所有针对信息交换和处理而制定通用词汇和过程集合的行业计划都无一例外地基于
XML 架构。事实上，XML 架构甚至已充当了 Web 服务协议的基础。 Web 服务协议包括简单对象访问协议
(SOAP) 和 Web 服务定义语言 (WSDL)。借助它们所提供的功能和消息处理能力，用户无需自定义代码即可在任何平台上的任何位置绑定和执行程序化功能。Web 服务规范的意义在于，它们为在 Internet 上构建复杂、可互操作的计算流程提供了第一个切实可行的架构。 SOAP 是一个基于 XML
的消息处理协议，用于对文档进行编码，以便通过网络进行传输。“SOAP
客户程序”可在 SOAP 封装中插入
XML 文档，并使用 HTTP 将其发送到接收该信息的“SOAP 接收程序”（后一个操作也被称为“编组”）。SOAP 消息处理具有诸多优点： ·
SOAP 客户程序和接收程序的构建都比较简单。用户可以方便地将
SOAP 客户程序作为例程嵌入任何程序或网页中，并且使用 URL
终端程序作为 SOAP 接收程序。 ·
通过使用 HTTP 作为传输机制，SOAP 消息可被发送到任何位置，并且可使用现有的 SSL 功能进行身份验证和加密。另外，还可以充分利用万维网现有的基础设施规模。 ·
消息、SOAP 封装、消息头以及消息正文中的所有信息都以 XML 表示，因而使得整个对象都完全透明。由于文档的语义和结构都是完全暴露的，因此不必编写应用程序代码即可对文档执行广泛的验证、操作、路由和转换功能。与
CORBA 不同的是，Web 服务网络终端（HTTP、URL 或其它地址）可以支持多种 XML
格式，从而可以实现真正多形态的接口，并且不会受新版本的影响。 ·
由于 HTTP 是 SOAP 使用的传输机制之一，因此可以在全球任何位置的任何支持 Web 的计算机之间调用 Web 服务方法。这样一来，SOAP
就有望建立同万维网的规模一样大的分布式计算流程。 Web 服务定义语言
(WSDL) 是通过信息交换或远程过程调用（二者都使用 SOAP
协议和按照 XML 格式封装的信息）来描述、传达以及调用程序功能的规范。WSDL 文档驻留在 URL 位置，并且同位于其它任意位置的实际程序模块链接在一起。业务流程内或者可通过业务流程访问的大多数功能都可以用 Web 服务的方式暴露出来，例如查看数据库、调用复杂的业务规则或者调用整个业务流程自身。由于公共
Web 服务接口同程序的私有实现方法无关，因此可以非常容易地构造高度模块化和高度分布的应用程序。 BizTalk Server 中的
Business Rule Framework（业务规则架构） 代表了一种实现面向服务架构（SOA）模型的创新途径。每一个单独和组合级别的功能在设计上都是公开、独立，并且可以进行松散组合。任何策略组件（词汇或规则集）都可以随时查看或更改，并且不会影响其它任何流程操作或者相关流程正在运行的实例。另外，还可以利用策略的语义和可声明的 XML 定义将策略直接编译到
Visual Studio .NET 程序集中，从而完全不再需要任何程序化的编程实现方式。该功能使得开发效率和生命周期管理效率得到了质的飞跃，仅此就可以证明面向服务架构模型的价值所在。 一个公开的组件化的规则引擎是否能为修改业务流程提供足够的灵活性，其意义将非常重大。在传统的应用程序开发中，业务规则逻辑内嵌在程序代码中，如果不更改代码，将无法修改业务规则逻辑。而频繁改动代码，不仅费时费力，而且往往会造成不可预计的程序行为。.
我们可以清楚地看到，如果能将业务规则同程序代码或者同任何流程实现机制完全隔离开来，将可以大幅度提高管理效率和针对新需求或新业务形势做出调整的效率。 单从在业务流程设计器中的开发过程来看，就足以说明何谓功能暴露和何谓松散耦合。借助业务流程设计器，开发人员可以让复杂的业务逻辑及其对应的实现方法变得可见，从而提高了软件开发的可管理性和降低了其抽象性。每个逻辑流程都同离散的实现机制相组合。这些实现机制含有自我描述的方法。借助功能上的透明和隔离，可从
Visual Studio .NET 宿主环境或直接通过 XML表述来访问解决方案中各个对象的属性（业务流程、架构、映射等等）。此外，已完成的业务流程还可以为整个流程生成业务流程执行语言（BPEL）文档。 由于 BPEL 指令集是流程的 XML 表示，具有精确的语言和语法结构，因此可为流程描述提供可阅读和可理解的指令集。这个价值不可低估。在过去，描述方面的欠缺使得软件和流程无法轻易修改和调整。事实上，业务流程设计器中的流程形状形象地描述了基本和结构化的
BPEL 元素，比如接收、调用、序列、流程、角色、连接和来源。在 BizTalk Server 业务流程设计器中开发的流程可以用 BPEL 文档的格式导出，然后可以导入其它任何兼容 BPEL 的应用程序中。反过来看，也可以将 BPEL 文档导入 BizTalk Server 业务流程设计器来生成业务流程图表。这种流程指令的标准化交换，可以有力促进业务伙伴之间的协作性业务流程开发。 随着在 BizTalk Server 2004 中应用 SOA 模型，XML
功能的重要性无疑将与日俱增： ·
XML 和 XML 架构使得 Web 服务协议（SOAP 和 WSDL）的创建成为可能。 ·
BPEL 功能在上述核心的 Web 服务协议之上，为在流程中添加额外的 XML 功能（比如业务规则或处理逻辑）创造了条件。 ·
虽然每个流程的价值都是独立的，但一旦同其它流程组合在一起，它们就能发挥整体性效应并且针对众多的难题提供创新性的解决方案。这也正好说明了整体要优于组件的简单组合。 由于 BizTalk Server 业务流程设计器内嵌在
Visual Studio .NET 内，因此它还成为了 SOA
和 .NET 这两个框架之间的桥梁。.NET 框架包括两个主要部件： 公共语言运行时
(CLR) 和一组统一的类库。这些类库包括用于 Web 应用和 Web 服务的 ASP.NET、用于智能客户端应用的 Windows Forms以及用于松散组合式数据访问的 ADO.NET。.NET 框架为将现有的信息技术投资同下一代应用和服务进行集成提供了高生产性和基于标准的环境。一旦同
BizTalk Server 中高级的 XML 抽象功能和可视化设计能力结合，它将为人们呈现一个提供了空前功能和效率的开发和部署环境。另外，它还提供了始终一致的风格，开发人员不仅可迅速掌握
SOA 方法，而且仍然能利用他们原有的 .NET 技术专长。 我们正在迈入一个新的计算时代。在这个新时代中，信息来源于各种完全独立的应用，但各个信息的结构、成分以及行为都将基本相同。在创建和发布信息时将不必考虑信息的处理或使用方式。应用程序将同时处理信息和方法，然后它又被其它系统继续处理。流程将可以实现自我配置和修改。我们将看到从面向服务的架构模型涌现出全新的应用程序、新的业务模型以及新的手段，而它们将为我们带来前所未有的新体验。 同任何模型转换一样，SOA 凭借它所携带的优势必将得到广泛的认同。各方面的事实都明显证明了这一点。开发效率的大步提升、投资回报的加快以及资源可用性的提高，是那些采用了
SOA 开发模型的早期采用者已经获得的益处。尽管 XML、Web 服务和 BPM/EAI 平台为业务流程的开发展示了一个新的概念模型，但实现和部署这种模型所必需的技术却是成熟而完善的 Microsoft 产品，这些产品已经由Microsoft进行了大力改进，以便能够为这种新的模型提供支持。 更多详细信息，请访问： http://www.microsoft.com/biztalk。 本文包含的信息代表了
Microsoft Corporation 在本文发布之时对本文所介绍的问题的最新看法。由于 Microsoft 必须响应不断变化的市场，因此不应将这些信息视作 Microsoft 一方的承诺，Microsoft 无法保证任何信息在发布之后的准确性。 本白皮书仅供参考。MICROSOFT 不对本文档中的信息作任何明确或隐含的担保。 遵守所有现行的版权法是用户的义务。没有 Microsoft Corporation 明确的书面许可，严禁以任何形式或方式（电子的、机械的、影印、录制或其它方式）或出于任何目的复制、传播本文档的任何部分，或将本文档的任何部分存储或引入到检索系统。但不限制版权法下的权利。 本文档的主题可能包含 Microsoft 的专利、专利应用程序、商标、版权或其它知识产权。除非 Microsoft 明确提供了任何书面许可协议，否则本文档的信息并未授予您对这些专利、商标、版权或其它知识产权的任何许可。 除非另有说明，否则文中描述的示例性公司、机构、产品、域名、电子邮件地址、徽标、人员、场所和事件均纯属虚构。不应在主观上或根据推断认为同任何真实的公司、机构、产品、域名、电子邮件地址、徽标、人员、场所或事件有任何关联。 ©
2003 Microsoft Corporation。保留所有权利 Microsoft、BizTalk 和 Visual Studio 是 Microsoft Corporation 在美国或其它国家和地区的注册商标或商标。 此处提及的实际公司和产品的名称可能是它们各自所有者的商标。 | 