在企业级 SOA 中使用 Web 服务，第 1 部分: 使用多重 SOA 来消除企业系统之间的差异-UML软件工程组织-火龙果软件

UML软件工程组织

在企业级 SOA 中使用 Web 服务，第 1 部分: 使用多重 SOA 来消除企业系统之间的差异

Judith M. Myerson (jmyerson@bellatlantic.net), 系统工程师兼架构师

本文内容包括:

引言
EAI 差异
消除差异
编制 Web 服务
避免错误
独立的 SOA 场景
多重 SOA 的场景
独立 SOA 调用 EAI 应用程序
多重 SOA 调用 EAI 应用程序
有多少 SOA？
结束语

使用多重面向服务的体系结构（Service-Oriented Architectures，SOA）可以消除企业系统之间的差异。Judith M. Myerson 向您展示了四种场景，它们将 Web 服务结合到复合应用程序中，该应用程序由独立 SOA、多重 SOA、具备多重 EAI 应用程序的独立 SOA 以及具备 EAI 应用程序的多重 SOA 复合而成。然而仍旧要考虑各种权衡，确定系统可以携带的 SOA 的最大数目可以使您避免 SOA 的超载。

　引言

在服务级协议（Service-Level Agreements，SLA）系列的第三篇文章（“在 Web 服务上下文中使用 SLA”，请见参考资料）中，我谈论了 Web 服务是如何作为 EAI 限制来补充 Enterprise Application Integration（EAI）应用程序的。我进一步讨论了使用 SOA 来消除企业系统之间的差异的场景，向您展示了如何执行获取 EAI 应用程序所有权的 Web 服务的业务逻辑。我向您展示了如何复用以数据为中心的 Web 服务以及来源于一个或更多 SOA 的业务逻辑并将它们结合进复合应用程序中。

EAI 差异

我重在研究 EAI 解决方案的三个主要的局限：所有权、有限的集成以及缺少开放行业标准。在公司的 EAI 应用程序之间存在信息传递的差异，例如：

客户关系管理（Customer relationship management，CRM）
投资关系管理（Investor relationship management，IRM）
供应链管理（Supply-chain management，SCM）
企业资源规划（Enterprise resource planning，ERP）

EAI 应用程序的所有权性质受到公司应用于 EAI 应用程序中的业务流程类型和公司经营的业务类型的限制。EAI 解决方案限制了使用外部应用程序来集成 EAI 系统的范围。对于在 EAI 系统及外部应用程序之间映射业务逻辑的计划的定制是浪费时间并且代价昂贵的。

实现 EAI 的标准事实上是不存在的。没有标准，在互联网上整合多商家的 EAI 应用程序是非常困难的。与 EAI 不同，Web 服务提供了广泛的标准，为应用程序与外部的服务提供者之间搭建了桥梁。然而，EAI 比 Web 服务更加安全，IT 行业联合起来创建并改善了现有的标准（WS-Security）为 Web 服务提供了更加安全的机制。

消除差异

各种窗体的中间件技术已经被用于消除 EAI 差异。Web 服务是使得 EAI 应用程序能够互相传递信息的最好的中间件。它们提供了开放的行业标准，为独立平台的 EAI 系统搭建了桥梁。一些附加的 EAI 应用程序承担了开放行业业务流程的提供者或客户的职责，EAI 应用程序不能在封闭环境下采用该流程。

事实上，在独立 SOA 中不是所有 Web 服务都可用。您可以将 Web 服务与基本功能相结合形成复合的 Web 服务应用程序。相反，您可以将这些应用程序同其它的 Web 服务或其它 SOA 中的复合业务相结合来建立新的或更高级的业务服务。这意味着您可以使用多重 SOA 来消除 EAI 应用程序之间的或系统之间的差异。

编制 Web 服务

在 SOA 中，使用一系列高级业务服务的业务流程来编制多重 Web 服务的执行。以数据为中心的 Web 服务很少自我执行。编制的目标是使得 Web 服务能够消除 EAI 的差异，以便具有所有权的 EAI 应用程序可以通过整合的集线器来互相交流。

在编制过程中，您可以扩大或缩小编制的范围和性质，通过复用代码来改变复合应用程序的业务流程逻辑。基于个人提出的功能，SOA 中的 Web 服务可被复用并结合到高级服务的复合应用程序中来创建新的业务服务，反之，该业务服务可被复用并结合到另一个 SOA 的业务服务的高级复合应用程序中。

避免错误

我想到了当开发 Web 服务或将 Web 服务结合进复合应用程序时可能发生的四个错误，您应当避免：

简单对象访问协议（Simple Object Access Protocol，SOAP）的开销
SOAP 互用性问题
紧密结合的业务服务
处理繁重事务的环境。

在每个地方都建立 Web 服务并且将它们结合到所有 Web 服务的应用程序中是不太实际的，即使 Web 服务是基于日益扩大的开放行业标准的（EAI 应用程序缺少这些标准）。当处理 Web 服务时企业可能会产生大量的 SOAP 开销，这样就减慢了完成业务流程的速度。

企业也可能遇到 Web 服务中的 SOAP 互用性的问题。虽然已经完成了大量的工作，使 SOAP 的互用性得到了提高，但是还没有实现行业级的完全互用。

一些具备所有权的 EAI 应用程序可以在紧耦合的环境下很好地执行某些业务功能，在复合应用程序中的 Web 服务不能在松耦合的环境下很好地执行。一个紧耦合的业务服务的实例是客户将卡插入读卡机中，确认卡的金额，指定取出的现金并收到自动地从他的帐户中取款的确认。

在短时间内一些 Web 服务连同其它的 Web 服务（包括长期运行的基于一套复合业务规则的应用程序）一起完成了业务流程，在整合这样的 Web 服务的过程中您可能会发现问题。Web 服务非常适合于短时间运行的应用程序，而不适合于处理繁重事务的环境，因为在这样的环境下需要很长时间才能完成业务流程。

独立的 SOA 场景

现在我们来看一下您怎样才能使 Web 服务同基本功能相结合来构建复合的 Web 服务应用程序，假设装载的性能是令人满意的。考虑下面的 Web 服务，每个都来自于完全互用的系统：

零售商的标识符
零售商的名称
零售商的地址
定购的数量
价格
税务

如图 1 所示，前四种 Web 服务仅包含基本功能的数据，而最后两个主要使用业务逻辑来达到向零售商发送帐单的目的。我将所有的都结合到复合的具备帐单功能的应用程序中，也就是在结帐应用程序中进行处理。

图 1. 独立 SOA 的场景

　我使用零售商标识符的 Web 服务来启动流程，该服务向零售商名称的 Web 服务发出请求来获得与零售商标识符相匹配的名称。当确认信息的时候，零售商名称的 Web 服务与零售商地址的 Web 服务、定购数量的 Web 服务、价格的 Web 服务和税务的 Web 服务相结合来建立具备零售商帐单功能的复合应用程序。随后，在基于服务的业务逻辑的结帐应用程序中处理了该复合应用程序。

　多重 SOA 的场景

我们假设小公司缺乏内部的 Tax Service 部门。对于更新、维护的业务有外来的税务服务并且管理外来税务的 Web 服务。对于该公司，我将第一个场景中的前五种 Web 服务结合进具有帐单功能的复合应用程序中，同时假设装载流程的性能是令人满意的。

我们假设 Web 服务发出了请求——将第二个 SOA 中外来的 Web 服务与第一个 SOA 中的复合应用程序相结合。如果接受并实现了该请求，那么在基于价格和税务服务的业务逻辑的结帐应用程序中将处理高级的复合应用程序。如图 2 所示，第二个 SOA 与第一个 SOA 交叠，该交叠的部分可能包含 SOA 中普遍的 Web 服务和非 Web 服务。

图 2. 多重 SOA 的场景

　独立 SOA 调用 EAI 应用程序

重在关联、链式管理，资源规划的 Web 服务有不同的整合规则（或虚拟的整合集线器），即使它们在整合企业之间的应用程序的过程中可以互相合作。相反，EAI 系统的组件可以通过中间件技术的整合集线器来互相传递信息使得 EAI 应用程序能够同遗留系统、数据库、Web 服务及非 Web 服务进行交互。

我们将 SOA 作为实现多重 EAI 应用程序（在防火墙内部及防火墙外部）的业务功能的主要的中间件技术。为了避免 SOAP 开销，限制 Web 服务的数量。同时，避免降低装载由 Web 服务调用的 EAI 应用程序的速度。

在独立 SOA 调用多重 EAI 应用程序的场景中，零售商标识符的 Web 服务首先调用了 Retail Management System（请见图 3）。在成功地装载了所应调用的应用程序之后，Web 服务发出了将标识符与名称及地址相链接的请求。

图 3. 调用多重 EAI 应用程序的独立 SOA

　然后 EAI 应用程序在数据库中搜索请求的项目。如果找到了名称及地址，那么它就向 SOA 发出信息来将定购数量及价格的 Web 服务添加到复合应用程序中。同时卸载 Retail Management System 来为今后调用其它 EAI 应用程序提供空间。

接下来，复合应用程序调用了 Finance Management System，该系统维护 Tax Service 流程规则的数据库。在成功地装载了该 EAI 应用程序之后，定购的数量及价格的应用程序与其相连。高级复合帐单功能就形成了。同时卸载 Finance Management System。

多重 SOA 调用 EAI 应用程序

现在，我们假设需要两个 SOA 连接两个 EAI 应用程序。在该场景中，我将 Order Quantity 和 Order Description Web Services 结合到第一个 SOA 中。我重复了第三个场景中的流程，调用并装载了零售商标识符的 Web 服务，并且向 Retail Management System（请见图 4）发出搜索请求。在成功搜索完之后，该 EAI 应用程序向 SOA 发出信息来将其添加到复合应用程序中。

图 4. 多重 SOA 调用多重 EAI 应用程序

　接下来，复合应用程序调用并向 Order Management System 发出请求来搜索 Pricing Policies 数据库。在成功搜索之后，Order Management System 将其本身与第二个 SOA 中的税务 Web 服务相连接。然后，税务 Web 服务被并入了第一个 SOA 的复合帐单功能中。所有装载及卸载的流程都成功地完成了，没有出现 SOAP 开销问题。

有多少 SOA？

您用于链接 EAI 应用程序的可用的 SOA 的数量依赖于对项目的复杂性、互用性问题、业务流程及装载性能问题的权衡。同您避免 SOAP 的开销一样，您需确保在整个开发周期中不会出现 SOA 超载问题。您应当在开发的每个阶段都进行超载测试。

结束语

使用 SOA 来消除企业系统之间的差异需要提前规划，设置需开发的 SOA 的数量限制。您应当同业务分析师及 IT 专家小组对于各种性能问题进行交流。您会发现使用 SOA 来消除 EAI 差异这种方法使您开发应用程序的工作变得更加容易。您可以将来源于一个或更多 SOA 的 Web 服务的业务逻辑结合成一个或更多的复合应用程序。分析师将会发现消除差异使得他们设计及分析 SOA 系统的工作变得更加容易。他们可以确定结合哪些 Web 服务能够达到最佳的性能，并且不会发生 SOAP 超载的问题。