常见用例

详尽列出所有可能的用例将需要更长的篇幅。然而，其中一些较为常见的用例需要进行强调：

服务虚拟化。服务虚拟化是实施 ESB 的主要驱动因素，其他大多数用例都是它的变形。

设计时缺少清晰的层次（或“分别考虑”）会在业务逻辑和 IT 细节之间引入不必要的耦合。起初，这些交叉相关性的影响可能不太明显，但随着集成范围的扩大，它们开始以指数级速度削弱 SOA 实施最初的优点。到端点的直接链接越多，最开始灵活、松散耦合的体系结构的僵化惯性就越大。

例如，如果将端点详细信息嵌入在一个数据库中，那么将该数据库从一个网络重新定位到另一个网络将需要一个新版本的贷款审批流程。处理几个这样的链接可能还是可管理的，但如果增加到 50 个服务和数十个端点，您就会看到体系结构很快会变成一张纠缠不清的相关性网。

该示例还暴露了这种设计在 IT 事件（数据库移动）和业务逻辑（贷款审批流程）之间引入的不正常关系。当复杂的核心商业资产（如贷款审批流程）根本没有变化时，日常 IT 事件难以接受触发这些资产的整个版本控制。

当然，这个小示例可能已经通过仔细的配置以及使用诸如 JNDI 或 DNS 这样的技术缩减至最少，但它仍然可以方便地阐释服务虚拟化所能解决的问题。更现实的用例包括添加或删除数据库、更改 CRM 供应商，甚至吸收作为合并或并购的结果而产生的新系统。

如图 1 所示，服务虚拟化是保存面向服务体系结构的增长能力的关键。通过使用 ESB，您可以从业务逻辑中彻底消除所有端点详细信息（如 IP 地址、端口以及其他低级特定于计算机的详细信息），而是公开一个稳定的接口。最终结果是将业务需求与 IT 需求完全分离，从而允许 IT 和业务独立修改各自的资产。

 
图 1 服务虚拟化

集中控制策略。您只需监视几个应用程序服务器日志和配置文件的日子已经一去不返。幸运的是，ESB 可以帮助您解决如今的分布式系统中固有问题的管理和监视，即，提供有关多个应用程序和协议的端到端视图，在企业范围内配置并强制执行全局策略。

由于 ESB 逻辑上作为所有集成通信的中介，因此对 SOA 基础结构的监视变得简单。ESB 管理控制台提供了流经服务的所有交换和消息的统一视图。（请参见图 2。）这些新的监视功能可用于进行被动和主动监视。例如，构建和强制执行端到端的服务级别协议 (SLA) 变成可能。实际的监视平台可能是一个外部应用程序（如 OpenView 或 Tivoli，也可能是较新的业务活动监视 (BAM) 工具，现在越来越多地用于实时基础结构监视），但 ESB 提供了所需的统一的、基于标准（SNMP、JMX、SQL）的基础结构视图。

图 2 集中控制策略

使用 ESB 可以更轻松地全局运行像安全性或可靠性这样的策略。通过将标准化的钩子（例如，WSDL 接口）公开到集成体系结构的每个步骤中，ESB 使得插入常用的安全、审计和消息处理工具成为可能。例如，您可以拦截某些站点之间的所有通信来执行安全声明标记语言 (SAML) 断言，或者在企业级别（而非每个单独的端点）支持 64 位 DES 加密。此外，ESB 还允许对专门应用程序的特定任务（如安全策略）的责任和委托进行清晰的分层。

原有数据源支持 Web 服务。最初，没有将 ESB 作为原有集成的解决方案。但是现在，普遍认为必须在 SOA 中考虑原有数据源，事实上，这些数据源通常组成所涉及的大多数服务。

一般来说，访问原有应用程序（如 ERP 或 CRM 系统）中的服务意味着使用供应商协议和 API 与目标系统直接交谈。（请参见图 3。）这意味着构建服务使用方的团队必须了解目标系统，并且能够编译其客户端的供应商 API（更不用说购买这些 API 的许可证了）。因此，部署新服务使用方的成本非常高。

图 3 访问服务（专有方式）

然而，大多数 ESB 供应商都提供可以连接到受欢迎的原有系统的适配器。然后，只需进行配置即可访问应用程序的服务，添加新服务使用方的成本显著降低，不用再使用供应商协议，所需的只是标准（SOAP、JMS 或 ESB 公开的任何其他入口点）。（请参见图 4。）

图 4 访问服务（基于标准的方法）

进行服务虚拟化之后，即可以在许多情况下利用 ESB 了。例如，多通道支持。（请参见图 5。）只需进行简单的配置，即可向过去只能通过单独的 API 访问的服务中添加新通道。因为使用同一个体系结构来支持多个通道，因此，确保所有访问（不论是哪个通道）都归属一个全局策略中是可能的。

图 5 多通道支持

例如，通过一个 ESB，只能通过 SOAP 从客户门户访问的 Web 服务可以允许其他面向客户的系统（如可以与 JMS 或 DCOM 交谈的 IVR 或传真网关）访问相同的服务。