使用多重面向服务的体系结构(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超载的问题。

　　　　关于作者

　　Judith M. Myerson是一位系统架构师和工程师。她感兴趣的领域包括中间件技术，企业级系统，数据库技术，应用程序开发，网络管理，安全性和项目管理。您可以通过jmyerson@bellatlantic.net与她联系。