管理服务

    请注意，面向服务的解决方案的一些重要功能（尤其是作为任何面向服务的解决方案组成部分的管理服务）也定位在 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。这种情况下的支持意味着关联工具中的内置模型识别功能，甚至是优化的运行时转换功能。