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 核心原则示例

    某银行有一个必须检查信用记录的现有应用程序。该银行正在自动化其信用检查流程，并将使用一个业务合作伙伴的信贷审批 Web 服务。该现有的应用程序使用一个通过 MQ 的文本消息和一个相关联的响应，从而与当前信用检查系统进行交互。考虑该银行的 ESB 中的一个能够完成以下任务的中介：

    *侦听 MQ 队列并将相关联的响应发送到 MQ 队列
    *将现有应用程序中的文本消息转换为与合作伙伴的信贷审批模式兼容的消息，并执行反向转换。
    *与安全基础设施交互以插入必要的安全信息
    *调用业务合作伙伴的 Web 服务并留下已做的审核跟踪

    作为该银行的面向服务的体系结构的一部分实现 ESB 可以提供以下好处：

    *现有的应用程序逻辑不会更改。如果 ESB 可以使用该应用程序原先使用的相同 MQ 队列，则配置也不需要更改。
    *审核跟踪支持与合作伙伴之间的业务协议的协调。
    *如果业务合作伙伴的服务不满足其服务级别协议，该银行可以通过在 ESB 中修改路由和转换以切换到新的服务提供者，而不会干扰使用该服务的客户端应用程序。

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

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

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