中文BTS04 Architecture Whitepaper

BizTalk Server 2004 架构

描述：本白皮书针对面向服务的架构（Service Oriented Architecture ,SOA）模型介绍了它的基础概念和开发思想，以及它在 Microsoft BizTalk Server 2004 中的实现方式。尤其值得注意的是，本白皮书从两个具体的环节上审视了该 SOA的实现。它们是： 所创建 BizTalk Server 应用程序的设计、行为和功能；以及应用程序开发过程本身。本白皮书还介绍了 BizTalk Server 开发工具是如何在 SOA 模型和 .NET Framework 架构之间搭起一座桥梁的。

关键词：企业应用集成, 业务流程自动化, 架构, 面向服务的架构, SOA, .NET, Visual Studio .NET, BizTalk Server, XML, XML 架构, Web 服务, BPEL, 简单对象访问协议, SOAP, Web 服务定义语言, WSDL

发布日期： 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 模型之间搭起一座桥梁的。

1678302900.doc

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

2. 创建和定义面向任何文档交换操作的转换要求。

如果应用程序是由 XML 对象之间的松散交互组成的，文档转换将是一个在功能上向外界暴露的映射子过程。在 BizTalk Server 中，这种子过程将通过 BizTalk Server 映射器来创建。通过转换映射，可对任何源信息（基于其架构表示）的内容和结构进行处理，然后转换为任何目标文档格式（比如报告）。通过使用与 BizTalk 架构编辑器一样的架构树状节点模型，BizTalk Server 映射器可以用可视化的方式显示源信息和目标信息的格式。信息可以从源架构的一个或多个节点映射到目标架构的一个或多个节点，方法是用线条连接这些节点。Functoid 提供了补充性(额外的)的转换、处理和解析功能（循环、累加、日期和时间、递归，等等）。通过（图形化实现）将一个或多个源节点连接到某个 functoid，然后将该 functoid 连接到一个或多个目标节点。

1678302900.doc

每个转换映射（以及所涉及的源和目标架构）都将变成 BizTalk Server 的项目资源，随后可作为一个流程环节将这些资源嵌入业务流程中并编译成业务流程程序集。可以根据需要重新利用和修改映射，以实现任意数量的转换要求以及将它们部署在任何数量的业务流程中。BizTalk Server 映射器创建的映射基于转换 XML 信息的开放式标准协议，即 XSLT。 3. 指定控制事件执行的业务逻辑。

4

如果业务逻辑比较简单，则可以将它作为一个表达式直接嵌入到 BizTalk Server 业务流程决策步骤中。如果业务逻辑比较复杂，可以使用 BizTalk Server 业务规则设计器来创建和处理复杂的规则集。每个规则集（或者说“策略”）驱动一种特定的操作或功能，并且将成为内嵌在 BizTalk Server 业务流程中的资源对象。

同整个 BizTalk Server 架构一样，创建和实现业务规则的整个过程也是透明的，并且联系松散。一个嵌入BizTalk Server业务流程的业务规则集可以在设计或者运行时被查看、修改或者完全被替换而不影响其它的流程操作或者中断本流程的实例的运行。由一个向外界暴露功能的组件化规则引擎提供灵活修改商业流程的特点具有极其重要的意义。在传统的应用程序开发过程中，业务规则逻辑嵌入在程序的代码之中，如果不修改代码，则无法修改这些业务逻辑。由于对业务流程生命期的大多数修改都仅限于业务规则的变动（相对与技术方面的修改），因此是否能将业务规则同程序代码完全隔离开来，或者同任何流程实现机制隔离开来，将决定是否能大幅度提高在整个业务流程生命期中管理和调整业务流程的效率。