引言

　　除了最简单的解决方案以外，企业服务总线是所有基于面向服务的体系结构解决方案的核心组成部分。那么 ESB 究竟是什么呢？您可以在整个 IT 行业中找到许多定义。本系列文章从 IBM 的角度（或者更准确地说，是在 IBM SOA Foundation 的上下文中）定义企业服务总线。要从本系列中获得最大的价值，您应该首先阅读有关 IBM SOA Foundation 的内容。

　　本系列用抽象的术语讨论 ESB 并避免讨论产品细节；也就是说，本系列不讨论 IBM WedSphere ESB 产品或 ESB 模式的任何其他实例。这种与产品无关的方法可以提供一个广泛的基础，以便了解 ESB 为面向服务的解决方案带来了什么，以及评估作为此类解决方案组成部分的特定 ESB 产品和相关技术。本文为整个系列奠定基础，讨论 ESB 在 IBM? SOA Foundation 中的定位，并描述 Foundation 的其他部分如何与 ESB 相关。特别是，本文将确定 ESB 的核心原则。最后，本文为您提供 ESB 的初步内部细节，并说明 ESB 如何实现这些核心原则。

　　IBM SOA Foundation 和 ESB

　　IBM SOA Foundation 是一个全面的体系结构和一组产品、技术和实践，用于处理 SOA 所包含的重要方面。SOA Foundation 描述了：

　　业务与 IT 部门之间的整体关系
　　用于对业务设计建模的工具和方法
　　用于使用 IT 系统来实现业务设计的工具、编程模型和技术
　　用于承载某个实现的中间件基础设施
　　该实现的管理，以确保其对业务的可用性，并确保在执行该实现的过程中高效地使用各种资源
　　治理系统，用于控制业务设计方面的变更及其在 IT 系统中的实现
　　要了解 SOA 的全部价值，您需要从不同的角度研究 SOA。类似地，必须从不同的角度研究 ESB 的作用才能了解其全部价值。

　　图 1 显示了 SOA Foundation 参考体系结构逻辑模型视图。该逻辑模型视图对 SOA 解决方案的功能基础进行了分解。这个功能性的或以 IT 为中心的视图将 ESB 描绘成一个集成 部分，此部分提供解决方案的其他 IT 部分之间的互连。

　　图 1. IBM SOA Foundation 参考体系结构逻辑模型视图
 
　　图 2 显示了 SOA Foundation 参考体系结构解决方案视图。这是一个面向服务的解决方案的以业务为中心的视图。请注意，ESB 被描绘成一个集成层，用于支持解决方案的业务组成部分之间的互连。

　　图 2. IBM SOA Foundation 参考体系结构解决方案视图
 
　　图 1 和图 2 都表明 ESB 是 Foundation 参考体系结构中的一种关键体系结构模式，并支持面向服务的解决方案中的服务请求者与服务提供者之间松散耦合的互连。松散耦合允许实现解决方案组成部分之间彻底的关注事项分离（时间、技术和组织上的分离），从而同时支持业务流程和 IT 系统的灵活性和敏捷性。本文的其余部分将详述该体系结构模式的特征以及如何能够实现这些特征。

　　ESB 核心原则

　　图 3 显示了服务请求者、服务提供者和 ESB 之间的逻辑关系。服务请求者和提供者通过交换消息进行交互。充当交互中的逻辑中间层的 ESB 提供了功能的请求者和功能的提供者之间松散耦合的互连。ESB 作为逻辑中间层的角色允许截获消息，并在消息在服务请求者和服务提供者之间流动时对消息进行处理。该处理称为中介。

　　图 3. 服务虚拟化
 
　　务必要了解 ESB 体系结构模式可以通过不同的方式物理地实现。在图 1 中，ESB 作为集中的集线器出现，并且该体系结构模式在许多解决方案中的物理实现事实上都是一个物理集线器。图 3 试图说明该体系结构模式可以具有不同的物理实现；例如，可以分散 ESB，以便能够在服务请求者环境、服务提供者环境、集中的集线器环境（或者是那些实现的任何组合）中物理地通过中介进行传递。（在本系列的后续各期中，您将了解有关各种 ESB 拓扑的更多详细信息。）

　　对各种类型的中介的支持使 ESB 可以满足支持关注事项分离的两个核心原则：服务虚拟化和面向方面的连接。第一个原则（服务虚拟化）指的是 ESB 在服务交互期间虚拟化以下内容的能力：

　　协议和模式。 交互参与者不需要使用相同的通信协议或交互模式。例如，某个请求者可能需要通过某种固有的同步协议进行交互，而服务提供者可能需要使用某种固有的单向协议进行交互，并使用两个相互关联的交互。ESB 提供所需的转换以屏蔽协议和模式切换。
　　接口。服务请求者和提供者不需要就用于交互的接口达成一致。例如，请求者可以使用一种形式的消息来检索客户信息，提供者可以使用另一种形式的消息。ESB 提供所需的转换以协调差异。
　　身份。交互中的参与者不需要知道交互中的其他参与者的身份（例如，地址）。例如，某个请求可能由不同物理位置的多个潜在提供者中的任何一个来满足，而服务请求者不需要意识到这一点。实际提供者仅对 ESB 可知，并且事实上可以更改而不影响请求者。ESB 提供所需的路由以隐藏身份。
　　第二个核心原则是面向方面的连接。面向服务的解决方案包括多个横切方面 (cross-cutting aspect)，例如安全性、管理、日志记录和审核。ESB 可以代表服务请求者和提供者实现或执行横切方面，从而从请求者和提供者的关注事项中消除此类方面。面向方面的连接和更熟悉的面向方面的编程概念之间的相似性是非常明白的，并且在不同的上下文中提供了同样的价值。

　　通过中介应用这些核心原则使得 ESB 可以影响交互中的服务质量。可以通过抽象让参与者不必了解交互的某些方面。例如，可以考虑审核：如果某个解决方案需要审核，ESB 可以向交互中添加审核而不影响参与者。类似地，ESB 可以通过使用自己的虚拟化功能来重试失败的交互，从而添加或增强服务级别协议，或者在更复杂的情况下，ESB 可以将请求者的要求与提供者的功能进行匹配。不过存在相关的限制，因为交互的某些方面是无法抽象的。例如，如果 ESB 无法可靠地与参与者之一进行交互，则 ESB 就无法提供可靠的端到端交互。

　　逻辑模型的以 ESB 为中心的视图

　　本文前面一个部分已将 ESB 在整个 SOA Foundation 范围中进行了定位（请参见图 1 和图 2），并且主要以从外到内的角度研究 ESB。下面将以从内到外的角度研究 ESB。图 4 描绘了 ESB 与该参考体系结构逻辑模型的其他部分之间的许多重要关系。

　　图 4. 逻辑模型的以 ESB 为中心的视图
 
　　应用程序逻辑与集成逻辑的比较

　　请注意，有几个 SOA Foundation 部分通过 ESB 互连，即交互、流程、信息、合作伙伴、业务应用程序和访问服务。这些部分已分组到单个标签为应用程序服务 的类别中，该类别定位在 ESB 外面。分组为应用程序服务的 Foundation 部分用于实现不同形式的服务请求者和服务提供者。这是解决方案中的应用程序或业务逻辑，旨在实现特定于领域的业务目标。ESB 实现解决方案中的连接或集成逻辑。此逻辑执行服务虚拟化和面向方面的连接，旨在实现应用程序服务之间随需应变的互连。

　　在理想的面向服务的解决方案中，应用程序和业务逻辑与连接和集成逻辑之间的分离是“彻底的”，意味着服务请求者和服务提供者（应用程序服务）不包含连接或集成逻辑，并且 ESB 不包含应用程序或业务逻辑。只有通过架构这种彻底的分离，企业才能实现从 SOA 中寻求的灵活性、敏捷性和重用。

　　有时很难在应用程序和业务逻辑与连接和集成逻辑之间进行区分。不存在严格的指导原则，事实上，具体的选择可能取决于企业的性质甚至是企业中的特定情况。一个通常有效的指导原则是利用语义和语法之间的区别。应用程序和业务逻辑创建、读取、更新或删除与实现业务目标相关联的语义。相反，连接和集成逻辑仅修改与实现必要的互连相关联的语法。一个相关的指导原则是利用交互特征。应用程序和业务逻辑是主动的，因为此逻辑创建或使用服务交互中使用的消息（请求和响应）；连接和集成逻辑是被动的，因此此逻辑只是对业务逻辑生成的消息做出反应，并且只是将消息从一个参与者移动到另一个参与者。

　　管理服务

　　请注意，面向服务的解决方案的一些重要功能（尤其是作为任何面向服务的解决方案组成部分的管理服务）也定位在 ESB 之外。这是因为诸如安全性和 IT 管理等功能具有解决方案级别的范围，并且需要解决方案的组成部分之间进行超出 ESB 范围的协调和合作。

　　请注意，ESB 并不提供应用程序服务和管理服务之间的连接，并且可以在没有 ESB 参与的情况下保护和管理解决方案。ESB 在保护和管理解决方案方面发挥显式的主动作用是可能的，并且经常是可取的。在此情况下，安全和管理策略由 ESB 之外的策略管理点设定，并且适合于将 ESB 视为此类策略的策略执行点。因此，虽然策略是使用与 ESB 没有直接关系的管理和安全服务来设定的，但是 ESB 帮助执行该策略。结果，管理服务的特征就是松散耦合 到 ESB。

　　服务注册中心

　　服务注册中心（有时称为服务存储库或服务注册中心/存储库）包含并管理元数据，这些元数据描述面向服务的解决方案中的服务。元数据的示例包括接口描述、端点地址和涵盖服务级别协议、安全关系等的策略。注册中心包含的服务元数据（因此也包括注册中心本身）在面向服务的解决方案中具有非常广的范围，并跨越治理、开发和管理以及运行时。图 2 特别说明了注册中心在面向服务的解决方案中的重要性质；图中将注册中心描绘为一个操作系统，此操作系统跨越从集成到治理的垂直层堆栈。

　　图 1 和图 4 表明 ESB 需要服务元数据以执行服务虚拟化和面向方面的连接。ESB 可以仅使用开发期间提供的静态元数据来提供价值。然而，要实现完全自动的服务虚拟化和面向方面的连接，ESB 需要在运行时访问服务注册中心，以获得必要的服务元数据来控制解决方案的动态行为。因此，我们断言服务注册中心是配置和控制 ESB 行为的首选方法；可以说服务注册中心是控制 ESB 行为的策略的策略管理点，并且 ESB 是服务注册中心中与连接相关的策略的策略执行点。因此，我们可以认为服务注册中心的特点是与 ESB 紧密耦合。

　　开发服务

　　图 4 中的开发服务提供了可用于开发和管理 ESB 的工具。开发人员希望使用工具来开发在 ESB 中运行的连接和集成逻辑，或者中介。类似地，管理员可以在部署后使用工具来管理 ESB。理想情况下，此类工具使用服务注册中心。例如，开发工具可能允许中介开发人员使用注册中心查找某个交互所需要的服务提供者。此外，管理工具可能允许添加、删除或修改旨在影响解决方案动态行为的服务元数据。

　　ESB 内部结构一瞥

　　图 5 显示了 ESB 内部结构的初步详细信息。您可以看到 ESB 如何提供服务虚拟化和面向方面的连接。

　　图 5. ESB 内部结构
 
　　通信协议

　　为了支持服务请求者和提供者之间的交互（即接收和发送消息），ESB 必须使用通信协议连接到请求者和提供者。ESB 可以利用不同的通信协议，以支持请求者和提供者之间的不同服务质量；例如，支持“尽最大努力”或“有保证”的交付。ESB 利用的协议范围越广，ESB 能够与之互连的请求者和提供者的范围就越广。

　　ESB 本身并不实际提供通信协议，而是利用其操作环境（SOA Foundation 参考逻辑模型中的基础设施服务）提供的一个或多个基础通信结构。可以说 ESB 本身提供了接入点 (on-ramp) 和接出点 (off-ramp) 或绑定，以支持使用各种协议进行交互。

　　由于基础通信结构的特征，通信协议本来就支持一种或多种交互模式。一些常见的交互模式包括同步请求/应答、单向（有时称为事件）和发布/订阅（有时称为事件传播）。

　　消息模型

　　为了与服务请求者和提供者交互，ESB 必须支持相关的消息模型，这些模型定义了交互中使用的消息内容。为此，ESB 必须是与消息模型无关的，并提供配置灵活性以支持服务请求者和提供者定义的消息模型。

　　消息模型本身基于元模型，元模型是一种表示消息内容的方法。消息元模型的一个示例为 XML 模式定义语言；事实上，这是 ESB 产品中最常用的消息元模型。消息模型是元模型的特定应用；内容模型的一个示例是某个特定的 XML 模式。ESB 必须显式支持至少一种消息元模型，并且能够支持多种消息元模型。

　　虽然该体系结构模式与消息模型无关，但是特定的 ESB 产品可以提供对一组跨行业或特定于行业的标准消息模型的支持，例如卫生保健业的 HL7。这种情况下的支持意味着关联工具中的内置模型识别功能，甚至是优化的运行时转换功能。

　　中介流

　　为了支持服务请求者和提供者之间的交互所必需的服务虚拟化和面向方面的连接，ESB 提供了中介流。中介流（通常简称为中介）包括通过某个接出点接收来自请求者的入站请求消息，处理请求消息，然后使用某个接入点向提供者发送出站消息。如果适用的话，中介还可以包括接收相关的入站响应消息，处理相关的响应消息，以及向请求者发送出站响应消息。

　　解决方案中的中介流可根据复杂性的不同（从非常简单到非常复杂）而变化各异。中介流还可以具有不同的可重用性，从特定于单个交互，到适用于某个解决方案中甚至跨解决方案的所有交互。中介流中执行的某些类型的消息处理往往是高度可重用的。这些经常出现、高度可重用、定义良好的消息处理类型称为中介模式。ESB 产品可以提供一个或多个预先构建的中介模式。提供多个预构建中介模式的 ESB 产品提供了一个中介框架，此框架支持通过组合中介模式来创建中介流。

　　中介流如何实现服务虚拟化？协议和模式的虚拟化意味着不同通信协议和交互模式之间的转换。如果某个 ESB 同时拥有用于两种协议的接入点和接出点或绑定，则该 ESB 只能在这两种协议中的一种协议与另一种协议之间转换。交互模式之间的转换可能本来就具有对入站或出站协议的支持，或者可能需要附加的处理。例如，从使用 SOAP/HTTP 的入站单向请求到使用基于队列的协议的出站单向请求的转换（其中消息模型相同）是固有的，因为基于队列的协议本来就是单向的。相反，使用 SOAP/HTTP 的入站同步请求/应答，到使用基于队列的单向请求和单向应答的出站异步请求/应答之间的转换，将要求中介流支持基于队列的请求和应答之间的相关性。与转换相关的中介模式包括接入点和接出点以及相关性模式，不过由于相关性是中介流的核心，在许多情况下，中介框架都隐含地包括了相关性模式。

　　接口的虚拟化要求 ESB 支持服务请求者和提供者定义的消息模型之间的句法转换。使用一种消息模型的服务请求者发送的入站消息，可能必须转换为服务提供者所需的特定消息模型，并且任何响应消息也都必须进行转换。与转换相关的中介模式包括支持单个元模型的模式（例如 XSLT）、支持多个元模型更通用的“任意到任意”转换模式，以及其他形式的消息处理，例如消息充实和消息筛选（更改语法而不是语义）。

　　身份的虚拟化要求 ESB 支持各种形式的路由。路由使 ESB 可以基于请求时的条件，将来自服务请求者的消息发送到静态（例如，在部署时）或动态选择的服务提供者。路由中介流涵盖从非常简单到非常复杂的情况。例如，简单的路由中介流可能除了提供一个不同的提供者地址外，其他什么也不做；该地址可能来自某个在部署时设置的属性。较复杂的路由中介流可能执行以下任务：

　　访问某个注册中心，以了解请求者的需求和潜在提供者的供给。
　　使用复杂的匹配算法来确定“正确”的提供者。
　　执行上面讨论的各种转换和变换。
　　与路由相关的中介模式允许进行简单地址操作、各种形式的注册中心访问和各种形式的决策。更大粒度的路由模式可以帮助实现不同的服务质量；例如，提供请求重试和故障转移，甚至基于从服务注册中心提取的策略来对请求者和提供者进行动态匹配。ESB 可以支持更复杂和更成熟的路由模式，例如请求的分发和响应的相关性聚合，甚至是复杂的事件处理。

　　中介流如何实现面向方面的连接？中介流可以简单地记录某个请求已从请求者传递到了提供者，阻止来自未知或未经授权的请求者的请求，或者基于提供者可用性来阻止请求。相关中介模式包括适合于解决方案的审核和日志记录。其他中介模式提供了对安全和管理策略定义点的直接或间接访问，以便中介流能够执行适当的控制。

　　通过此讨论，可以清楚看到许多中介流可能由支持各种形式的服务虚拟化和面向服务的连接的中介模式组成。各个中介模式被适当地放在中介流中以实现预期的交互目标，以及执行管理和安全策略。

　　SOA 生命周期和 ESB

　　面向方面的解决方案的一个关键元素是其组成部分的生命周期。下面研究一下 SOA 生命周期如何适用于 ESB。在图 6 中，您可以看到 SOA Foundation 生命周期。

　　图 6. SOA Foundation 生命周期
 
　　模型阶段包括以下活动：

　　通过分析服务请求者和提供者的交互来收集互连和元数据要求；相关需求和供给可以在注册中心进行描述。
　　对支持所需互连所必需的中介流进行建模和设计。
　　
　　组装阶段包括以下活动：

　　从较小粒度的中介模式组合成中介流。可以将中介模式作为 ESB 产品的一部分预先进行构建。这些中介模式可存在于企业特定的资产存储库中。或者，这些中介模式可以是为解决方案新开发的。
　　在服务注册中心存储关于中介的元数据以供服务请求者使用。该元数据描述相关的连接方面，例如安全性。

　　部署阶段包括以下活动：

　　配置用于部署到特定运行时拓扑中的中介；部分必需的配置信息将作为服务元数据存储在注册中心。
　　将中介部署到一个或多个运行时环境。
　　修改服务元数据以影响解决方案的动态行为。

　　管理阶段包括以下活动：

　　监视使用中介模式的服务交互的行为。
　　作为安全和管理服务以及注册中心的策略执行点，对服务交互进行管理和保护。

　　ESB 在面向服务的解决方案的治理流程中起着间接的作用，因为治理驱动着用于安全、管理和服务交互性的策略。正如已说明的那样，ESB 可以用作这些方面的策略执行点。还必须将 ESB 考虑进治理决策中。例如，治理流程确定哪些服务可通过 ESB 进行访问以保证松散耦合，从而确定要在 ESB 中部署哪些中介。

　　总结

　　在这篇介绍性文章中，您了解了企业服务总线如何是 SOA 和 IBM 的 SOA Foundation 中的一个关键体系结构模式。本文用与产品无关的术语描述了 ESB 如何支持服务虚拟化和交互参与者之间面向方面的连接。该体系结构模式可以使用各种各样的逻辑拓扑和各种各样的中间件技术和产品来实现。本系列的后续文章将探索各种 ESB 拓扑以及它们如何提供价值。您还将更详细地研究中介流、与服务注册中心的关系，以及诸如 WebSphere ESB、WebSphere Message Broker 和 WebSphere DataPower 等 IBM ESB 产品如何与该体系结构模式相关。