本系列文章的第 1 部分和第 2 部分主要探索企业集成模式的发展，介绍一些基本概念，并重点介绍基于面向服务的体系结构 (SOA) 的集成模式。第 1 部分介绍了两个早期模式：数据共享（socket 编程）和 RPC，探索了服务提供者和服务使用者、平台独立性和连接性的概念。
为改进 RPC 的功能，现在我们介绍以下两种方法：
- 分布式对象，也称为对象请求代理（Object Request Broker，ORB）：此方法侧重于代码重用和语言独立性。
- 异步消息传递：此方法解决了应用程序之间的紧密耦合问题。
让我们首先了解一下分布式对象这一方法，因为它与 RPC 的关系更密切一些。目前，大多数应用服务器都基于 ORB 技术。
分布式对象技术的实现有三个主要类型。其中之一就是语言独立性和平台独立性，即所谓的公共对象请求代理体系结构（Common Object Request Broker Architecture，CORBA）。其他技术则依赖于语言或者依赖于平台和语言。Java 远程方法调用 (RMI) 是依赖于语言技术的示例，而 Microsoft 分布式对象组件模型 (DCOM) 和 IBM® 系统对象模型 (SOM) 是依赖于平台技术的示例。
现在我们将详细介绍 CORBA，因为它是最常见（独立于语言和平台）的技术，并且来自不同供应商且基于此技术的产品可以一起使用。例如，基于 ORB 的 IBM WebSphere® Application Server 可以与许多其他供应商的应用服务器通信。
除引入面向对象的优点（如继承、多态性和封装）外，CORBA 还引入了大量的新功能。最重要的可能要数 ORB 这一概念，ORB 提取了用于封送输入和输出参数的代码和用于从客户端和服务器应用程序到独立软件组件通信的代码。另外，ORB 还提供了用于获取远程对象引用的设备，以便调用该远程对象上的方法。
此分离允许多个应用程序重用同一代码，并通过从点到点的集成中移去应用程序，使这些应用程序之间能够进行一定程度的分离。从点到点的集成中移去应用程序可能是 ESB 概念发展的第一步。图 1 演示了这一情况，该图显示了同一台计算机上的多个应用程序可以使用同一 ORB 相互通信，并可以与不同计算机上的应用程序进行通信。
图 1. 多个应用程序通过 ORB 相互通信，演示代码重用和通过 ESB 的间接通信（ESB 方向的第一步）
图 2 显示了 ORB 的基本工作原理。当应用程序需要使用另一个组件的服务时，它首先获取提供该服务的对象的引用。获取对象引用后，客户端应用程序可以调用该对象上的方法，该对象就好像是本地对象。
图 2. 远程对象上使用 ORB 的方法调用，包括获取远程对象引用
CORBA 还引入了接口定义的语言独立性概念。这是通过引入接口定义语言 (IDL)（类似于 C++ 编程中的头文件）完成的。它只定义接口，但不包括实现。IDL 负责确保在不同的语言之间正确地交换数据，从而负责 CORBA 的语言独立性。这允许使用一种语言（如 C++）实现客户端，使用另一种语言（如 Java）实现服务器。清单 1 显示了一个 IDL 示例。
清单 1. IDL 接口定义示例，它使用单个远程操作为计算数的平方定义单个接口
module Test {
interface square
attribute double arg1;
double getSquare (in double arg1);
};
};
|
CORBA 中提出的另一个重要概念是命名服务，它允许 CORBA 对象注册，并按名称查找这些对象。此概念包含了 SOA 中注册概念所需的种子。
总的说来，CORBA 引入了大量的新功能，并允许重用通信代码，对代码进行封送和解封送处理。远程对象的注册和位置概念、语言独立性接口定义和从点到点集成移除是引入的重要新功能。因此，对于许多集成项目，基于 ORB 的解决方案可能是合适的选择。不过，使用基于 ORB 的集成存在一些缺点，因此，在某些情况下，这可能不是最佳选择。其中的一些注意事项包括：
- 基于 ORB 的解决方案无法进行大容量扩展，因此，在希望处理大量的事务时，该解决方案并不合适。缺乏扩展性是由于交互操作的同步特性，该特性使客户端应用程序在收到服务器的响应之前无法继续进行其工作。
- 客户端对象和服务器对象之间的交互粒度太细，在网络中会导致许多问题。因此，无法有效地使用网络带宽，这将进一步限制解决方案的可扩展性。
- 基于 ORB 的通信是不可靠的，无法保证将消息和返回值发送到既定目标。因此，在某些情况下（如网络连接中的中断），客户端应用程序在其操作过程可能会发生挂起。
- 尽管从理论上讲，CORBA 是独立于语言的，但是，使用 ORB 的大多数商业产品都是特定于语言的，如 Java 或 Java 2 Platform Enterprise Edition (J2EE)。这是因为 CORBA 开放标准已证明由于太难而无法实现最常见的形式。这限制了 ORB 对使用这些特定语言编写的应用程序的集成能力。
为处理这些问题，就出现了并行开发，并行开发基于异步消息传递，并包含开发另一个类型的 ESB 所需的种子。此类型的 ESB 提供了比基于 ORB 的 ESB 类型更具扩展性的解决方案。在异步消息传递 中，客户端或客户端对象将消息发送到目标应用程序，但是不等待响应就继续其工作。这将导致在涉及的应用程序之间发生某种程度的分离。因此，如果期望处理大量事务，可以将异步消息传递用作集成的基础。
在消息传递过程中，应用程序不直接相互通信，它们之间没有建立专用通信链接。相反，它们可以通过队列进行间接通信（如图 3 所示）。应用程序 A 将消息发送到队列。应用程序 A 提交消息后，应用程序 B 从队列中检索该消息，不过，如果每个接收应用程序都有专用队列，则通信仍属于点到点的通信。在异步消息传递中，存在一个名为发布和订阅 的选项，多个应用程序可以从中接收同一消息。但这常常是不够的，因为一个应用程序需要更复杂的消息路由。例如，可能需要基于消息的内容和大小来路由消息。在这种情况下，除消息传递软件外，中间件还必须包括通常称为消息代理 的消息路由器。中心消息代理可以从不同的应用程序接收消息，为每种消息类型确定正确的目的地，并将消息路由到适当的目的地应用程序。它允许应用程序相互通信，而无需知道接收应用程序的位置。图 4 显示了这一流程，还指示消息传递以及消息代理可以形成 ESB 的框架。
图 4. 使用消息传递软件和中心消息代理（路由器）组件的多个应用程序可以相互通信，并可以与通过网络连接的其他计算机上的应用程序进行通信
同步消息传递的另一个优点是能够保证消息的提交。通过在连接应用程序的网络两端保留该消息可以做到这一点。这可以确保即使在网络临时中断或者接收应用程序与发送应用程序未同时运行时也能提交消息。使用 RPC 或 ORB 则不能够提供此保证。
而使用消息传递中间件（如 IBM WebSphere MQ）的另一个优点是可以通过网络交换和传输大量的数据，从而进行粗粒度的数据传输。这将能够更高效地使用网络带宽。
尽管从理论上讲异步消息传递是单向通信，但是可以让它调用接收应用程序中的一些功能。接收应用程序中此类功能调用的一个示例是消息驱动的 bean (MDB)。MDB 和类似的软件部分没有返回值。可以使用异步消息传递模拟使用两个队列的同步消息传递。图 5 显示了此内容，其中一个队列（即请求队列）用于提交请求，而通过另一个队列获取返回值。请求队列是请求应用程序（应用程序 A）的输出队列；同时它又充当接收应用程序（应用程序 B）的输入队列。类似地，响应队列用作应用程序 B 的输出队列和应用程序 A 的返回值的输入队列。
在目前所描述的选项中，当涉及大量事务时，异步消息传递可能是应用程序共享数据和功能的最高效方法。不过，这并不适用于所有情况；必须进行适当的调整，才能得到适合您的情况的解决方案。异步消息传递也存在一些缺点：
- 一般来说，异步消息传递软件价格昂贵，ESB 的价格依赖于异步消息传递的中间件，有时比基于 ORB 的中间件 ESB 的成本要高很多。
- 需要一个与异步消息传递环境相关的学习过程。
- 在模拟两个应用程序之间的同步交互时，涉及一定量的开销和进行一些簿记。