对构建企业面向服务的体系结构（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 过载。