对构建企业面向服务的体系结构（Service-Oriented Architecture，SOA）中间件应用程序感兴趣吗？Judith Myerson将向您提供四种可能的方法：自顶向下(top-down)、自底向上(bottom-up)、旁路(sideway)和嵌入式(embedding)，同时帮助您探究每种方法的各种利弊。您还会了解到如何确定中间件应用程序可以支持的共享SOA的最大数目。

　　引言

　　在我的关于企业级SOA系列的第一篇文章“在企业级SOA中使用Web服务，第1部分: 使用多重SOA来消除企业系统之间的差异”中，我曾谈及使用SOA消除企业系统差异的场景，展示了如何重用来自一个或多个SOA的Web服务（以数据为中心且具有业务逻辑），以及如何将它们组合到组织控制之下的一个复合应用程序中。

　　在第二篇文章“在企业级SOA中使用Web服务，第2部分: 使外部Web服务互操作性最优”中，我给出了不引起多重SOA过载的服务互操作性实例，从简单的协议共存到复杂的多平台互操作性。并且您了解了如何更改每个Web服务的服务类型、位置和平台来实现原始应用程序的业务流程。

　　本系列的第三部分“在企业级SOA中使用Web服务，第3部分: 将您的SOA合并成三维的整合中心以提高速度和可靠性”中，我解释了您可以如何将Web服务和非Web服务的多重SOA合并成单个三维的集成中心来连接到各种后端企业大型机系统。在本文中，我将解释您可以如何使用来自IBM? Rational?软件的开发工具在三维空间中开发企业SOA中间件应用程序。同时您还将了解到如何将Web服务组件组合成跨多重SOA的中间件应用程序，以及如何使用下面四种不同的方法来开发它们：

　　·自顶向下
　　·自底向上
　　·旁路
　　·嵌入式

　　让我们首先从物理和逻辑的角度研究每种方法。

　　逻辑和物理Web服务

　　物理Web服务即在存储库中所发布和找到的Web服务。创建一个逻辑Web服务后，可以继续将一个逻辑Web服务与另一个物理Web服务组合起来，创建一个新的逻辑Web服务以供使用。之后，您可以将最后得到的逻辑Web服务与另一个物理或逻辑Web服务组合起来。您也可以将逻辑Web服务转换成物理Web服务组件，以在存储库中发布和发现它们。

　　通过定义中间件应用程序的业务模型和物理Web服务组件的业务模型之间的关系，您可以创建逻辑Web服务的SOA中间件应用程序。为此，您可以使用Rational Software Architect和Rational Software Modeler中的一个或同时使用它们来支持使用统一建模语言（Unified Modeling Language，UML）的模型驱动(model-driven)开发，以及支持分别记录系统的不同视图的UML可视化建模设计。

　　自顶向下方法

　　自顶向下方法从Web服务或非Web服务中间件应用程序金字塔（请参见图1）的顶端开始。您需要将其划分成更小的Web服务或组件，在金字塔的每个低层继续这个过程，直到最小的部分或组件到达金字塔的底部为止。系统的所有部分都将顺利地集成在一起并进行互操作。

　　图1. 自顶向下方法
 
　　然而，互操作性可能具有不同的含义，这取决于应用程序的预定用途。例如，如果应用程序是以数据为中心，那么互操作性就是以数据为中心的。但是如果应用程序的主要目标是实现业务流程，那么互操作性就是基于流程的。

　　现在，让我们从逻辑的角度来研究自顶向下方法。自顶向下方法考虑由企业SOA中间件应用程序组成的应用程序的目标。这个目标又分成子目标，每个子目标更进一步分成更小的单元。这个过程一直继续下去，直到达到SOA中间件应用程序的金字塔的底部为止。

　　显然，确保所有子目标都顺利地进行互操作非常重要。如果目标针对的是提供一个服务或一组服务，那么服务互操作性就成为首要关注的事情。然而，如果目标针对的是实现策略和规则，那么我们就需要将重点放在策略的互操作性上。

　　在现实世界中，并不存在单纯的以数据为中心、基于流程或策略互操作性。相反，我们通常碰到的都是数据、流程、服务和策略互操作性混合在一起。每种互操作性类型所占的比例可以动态地变化，这取决于每个Web服务如何模块化、设置优先级、最优化，以及如何通过松耦合的方式使彼此的交互达到最大程序。同样，它也依赖于Web服务所运行的平台（例如开放的Eclipse体系结构）。

　　自底向上方法

　　从物理的角度来说，自底向上方法将基本的Web服务组件定义为最小的基础部分。这使您可以将它与上一层更大的元素组合在一起，继续这个过程，直到所有部分都在金字塔顶点处集成为一个完整的复杂Web服务和关系的中间件应用程序为止，如图2所示。

　　图2. 自底向上方法
 
　　这个物理角度假定系统的所有部分都可以顺利地进行互操作。互操作性的含义依赖于Web服务交互的类型：以数据为中心、业务流程或组合。应用程序之间互操作性的每种类型所占的比例可以动态地变化。

　　从逻辑的角度来说，自底向上方法从作为SOA企业目标的基础构件的子目标（例如服务组件）开始。作为一名开发人员，您可以与分析人员一起，将它们组合成上一层的更大目标。继续这个过程，直到所有的子目标都在金字塔的顶点处集成为一个SOA中间件的企业目标为止。

　　确保所有的子目标都将顺利地进行交互非常重要。如果子目标针对的是提供一个服务或一组服务，我们首要关注的事情就是子目标之间的服务互操作性。然而，如果子目标针对的是实现策略和规则，那么我们关心的事情就变成子目标之间的策略互操作性。

　　旁路方法

　　从物理的角度来说，旁路方法（如图3所示）允许您在自顶向下或自底向上方法的旁路添加或删除Web服务组件。这使您能够在保持现有中间件完整的同时，更好地响应变更的设计和开发需求。旁路角度假定要添加的组件将可以与现有的组件顺利地交互。同样，它也假定要删除的组件将不会破坏剩余组件之间的互操作性。

　　图3. 旁路方法
 
　　从逻辑的角度来说，旁路方法使您能够从在自顶向下或自底向上方法的旁路添加逻辑Web服务的子目标开始。这使您可以添加诸如新的Web服务的服务类型和位置这样的子目标。您可以使用任一方法的旁路从逻辑Web服务中删除子目标。

　　您还可以更改Web服务的子目标，以便重用它来开发各种中间件应用程序。请确保在逻辑上添加、删除或者更改子目标时，Web服务之间的互操作仍然能够在生产环境中顺利地进行。您还需要确保在测试环境中运行的Web服务能够顺利地出色工作。

　　嵌入式方法

　　从物理和逻辑的角度来说，嵌入式方法是上述三种方法的混合，至少要嵌入金字塔某层中的两级或三级深。在这个嵌套、两级嵌入式方法示例中，您可以在自底向上方法中嵌入自顶向下方法（请参见图4），或者反过来。您也可以在自顶向下或自底向上方法中嵌入旁路方法。

　　图4. 嵌入式方法
 
　　您可以获得三级嵌套的嵌入式方法。例如，通过将旁路方法嵌入到自顶向下方法，接着嵌入到自底向上方法，您可以做到这一点。您也可以将自顶向下方法嵌入到第二个自顶向下方法，接着再嵌入到自底向上方法。

　　决定使用哪种方法

　　在开放的体系结构中开发SOA中间件应用程序依赖于（举例）您想要使用哪种关系型或WebSphere?包。正如前面提到的，您可以使用Rational Software Architect和Rational Software Modeler来对企业SOA中间件进行建模，将Web服务当作对象、关系实体或者两者的混合。您也可以使用Rational Web Developer for WebSphere Software for Linux、Windows 2000、Windows 2003 Server和Windows XP来简化您的Web服务开发。

　　结束语

　　开发企业SOA中间件需要事先计划好可以将多少SOA作为中间件应用程序组合在一起。最好就使用哪些方法开发中间件的问题与业务分析人员小组进行沟通。您还将发现，解决了这些问题使开发企业SOA中间件更加容易。您可以为中间件应用程序开发这样的SOA，它们既重用，又可以交互和集成。而且通过事先决定使用哪些方法或方法的组合，使分析人员设计和分析中间件的工作变得简单。分析人员能够确定使用哪种方法以及将多少个SOA组合在一起，因为中间件基于它们之间各种类型的互操作性，并且可能引起企业SOA过载。