本文将介绍选择 ESB 的技术标准，说明
IBM 产品可以如何实现 ESB，然后将对一些常见的 ESB 实现模式进行总结。本文将讨论三个主要 IBM
ESB 产品（WebSphere Message Broker、WebSphere ESB 和 WebSphere
DataPower SOA Appliances）和支持或扩展 ESB 模式的产品（WebSphere
MQ、WebSphere Service Registry and Repository、WebSphere
Transformation Extender、WebSphere Adapters、WebSphere
Process Server、WebSphere Business Services Fabric 和
IBM Tivoli Composite Application Management for SOA）。本文还将详细介绍两个
ESB 实现案例研究。
面向服务的体系结构（Service Oriented Architecture，SOA）提供了灵活、可扩展且可组合的方法来重用及扩展现有应用程序和构造新应用程序。SOA
最为重要的特征是其灵活性，其中将业务流程和底层 IT 基础设施作为安全的标准化服务对待，可供重用和组装，以处理不断变化的业务需求。SOA
中的服务具有定义良好的接口，此接口由消息接收和发送的一组消息定义，而且接口的实现在部署之后将绑定到所记录的服务端口。
企业服务总线（Enterprise Service Bus，ESB）是一种体系结构模式，支持通信各方间的服务交互的虚拟化和管理。它充当
SOA 中服务提供者和请求者之间的连接服务的中间层。它是一个灵活的连接框架，可促进可靠而安全的系统集成，并同时减少应用程序接口的数量、大小和复杂度。
其中的服务不直接交互，而是通过服务连接框架 (ESB) 进行通信；此框架提供实现和扩展
SOA 核心定义的虚拟化和管理功能。ESB 模式提供以下方面的虚拟化：
- 位置和标识：ESB 标识消息并在交互服务之间路由这些消息。这些服务不需要知道通信中的其他方的位置或标识。例如，请求方不需要知道多个提供者中是否有提供者可以处理请求。您可以向正在工作的
ESB 添加其他服务提供者，从而允许将消息路由到这些提供者，而且不会对请求者造成干扰。
- 通信协议：ESB 允许消息在服务请求者和服务提供者之间来回传递的过程中跨不同的传输协议或交互样式中传递。例如，以
SOAP/HTTP 格式表示的请求可能送到仅接收 JMS 输入的提供者。
- 接口：服务的请求者和提供者不需要就单一接口达成一致。ESB
可以对请求者发出的消息进行转换和充实来得到提供者预期的格式，从而协调差异。
您可以使用各种中间件产品（硬件和软件）、编程模型和交互样式实现 ESB
模式。ESB：
- 标识消息并在应用程序和服务间路由这些消息
- 允许消息在服务请求者和服务提供者之间来回传递的过程中跨不同的传输协议传递
- 在请求者和服务之间转换消息格式
- 识别和区分不同源之间的业务事件
- 提供可靠而安全的通信
- 创建基于可插入组件的可扩展体系结构
- 提供智能路由和独立于位置的处理
- 通过元数据管理消息及其格式的描述和定义
- 集成所有类型的资产，以满足您企业的需求
很多 ESB 实现都利用了服务连接性标准，如 XML 和 Web 服务，此类标准封装了行业对
ESB 定义的统一认识。不过没有必要将 ESB 限制为仅使用这些标准。可以对 ESB 体系结构模式进行扩展，以支持现有
IT 投资，此类投资包括大型机资产、打包应用程序、传感器和设备以及文件和不基于任何公用标准的自定义协议。ESB
应该支持企业的所有连接性需求。
ESB 应该支持不同类型的服务交互：单向消息及请求/响应、异步调用及同步调用和发布/订阅模型以及复杂事件处理（在其中可能会观察或使用一系列事件来产生一个事件，将其作为系列事件中的关系的结果）。
建立 ESB 是组织中建立 SOA 的过程中一项十分关键的基础投资。组织可通过其实现以下目标：
- 简化：减少接口的数量、大小和复杂度。
- 减少风险和成本：提高 IT 对业务需求变更的响应能力。
- 促进重用：提高数据和业务逻辑的可用性，使应用程序更易于启用服务。
- 支持动态、实时、事件驱动的 SOA：替代了呆板、无响应能力或采用批处理方式更新的
IT 系统。
SOA 和任何 IT 活动一样，都依赖于技术、人员和流程。ESB 采用过程中的一项关键的成功因素是，ESB
技术必须能够在治理框架内进行管理，以便为组织带来价值。
很多组织发现，SOA 卓越中心（SOA Center of Excellence，COE）价值很大，能促进
SOA 技术的采用。COE 必须涵盖整个组织内的团队，以分享经验、提供培训、提出流程改进建议和确保 SOA
环境的成熟度。COE 需要帮助 SOA 治理委员会处理 SOA 出现的问题，如版本控制、服务共享和安全性等。SOA
COE 是整个组织范围内的 IT 团队，负责指导 SOA 远景和战略所确定的战略共享 IT 解决方案的
IT 投资、涉及决策和实现。COE 可帮助处理一系列问题，如：
- 治理
- 在组织内为 SOA 提供信息传播机制
- 在定义 SOA 治理和管理流程方面为 SOA 治理委员会提供支持
- 实现 SOA 治理和管理流程
- 充当思想领袖并进行远景规划：充当 SOA 治理和管理流程的思想带头人
- 提供专业 SOA 技能和资源
- 演示资产收集过程中的知识管理
- 进行整个 IT 团队内及与组织的其他部门的沟通
下面以图形方式说明了 COE 所充当的很多角色。
交互样式
为了完全支持全面的 SOA 中所需的各种集成模式（如请求/响应、发布/订阅和事件等），ESB
应该最好能在一个基础设施中支持三个主要企业集成样式：
- SOA，其中应用程序通过具有定义良好的显式接口的可重用服务进行通信。面向服务的交互将充分利用底层消息传递和事件通信模型。
- 消息驱动的体系结构，其中应用程序通过 ESB 发送消息，以调用其他应用程序。
- 事件驱动的体系结构，其中应用程序以彼此独立的方式生成和使用消息。
使用者可以采用不同的方式实现服务调用。从使用者的角度而言，差异在于：
- 同步：使用者使用单线程来调用服务；线程发送请求，会在服务运行时阻塞，等待响应。
- 异步：使用者使用两个线程来调用服务；一个线程发送请求，然后另一个线程侦听并接收响应。
- 发布/订阅：服务将消息发布到特定的主题。多个服务（订阅者）可以订阅此主题并接收发布的消息。
对于单个服务，ESB 可以提供这些调用模型的任意组合，让使用者选择首选调用模型。
交互样式可能影响 ESB 实现。IBM® WebSphere®
Message Broker 特别适合基本流范式为异步或伪异步方式的体系结构。
有状态性
某些情况可能需要 ESB 在消息通过其中时维护状态。从最后适用的消息的上下文信息中选择特定的服务端点就是这方面的简单示例。而在更为复杂的示例中，可以通过检测涉及上下文敏感的消息和事件组合（语义上下文、时间上下文、空间-时间上下文）的复杂情况来扩展
ESB 范式。在应用到来自多个事件源的输入处理时，此功能极为强大：从不同上下文中的业务、应用程序或基础设施的角度而言均是如此。例如，此类场景可能涉及到服务水平协议
(Service Level Agreement) 警报和适用于安全、财务、银行和保险行业的遵从性检查。
硬件 ESB 实现通常并不支持有状态交互，这就使得有状态性成为了软件
ESB 实现的一个标准。WebSphere Message Broker 以独特的方式在产品中直接实现了复杂的消息处理，使其最适合需要此功能的用例。
端点、标准和协议
端点是通过 ESB 交互的使用者和服务。
采用标准技术和协议（如 Web 服务）的端点在 ESB 技术选择方面提供了最大的灵活性。不过，将端点限制为存在大量遗留投资的标准的做法经常不实际或不经济高效。类似地，虽然可以使用专用
API 集成打包应用程序，但将这个集成工作委托给中介供应商完成的做法通常很有用。为了处理这些顾虑，出现了能极大简化集成的适配器。
适配器的使用会对 ESB 产品选择造成影响，因为适配器需要软件运行时（在硬件
ESB 实现上并不支持适配器），而且各种适配器的先决条件各不相同。
基于策略的交互管理和动态服务选择
在一项新兴的 ESB 技术中采用了动态端点选择，其选择以服务器使用率和运行状况等基于代理的统计数据为基础。在某些
IBM ESB 产品通过与 IBM Tivoli Composite Application Manager
的集成提供了对此的现成支持。
消息量、大小和类型
ESB 产品具有不同的可伸缩性特征。通常，基于硬件的实现可以很好地扩展，而且具有很好的行业标准数据格式支持。不过，他们并不提供软件实现的通用性。WebSphere
Message Broker 性能优良，提供了丰富的 ESB 功能，而且可以使用自定义组件和适配器进行扩展。WebSphere
ESB 具有丰富的行业标准格式、Java 和 Web Services 标准支持，可以使用自定义组件和适配器进行扩展。
可靠性、可用性和可服务性（Reliability,
availability, and serviceability，RAS）
ESB 产品具有不同的操作特征，它们通过不同的机制和体系结构规模（例如，应用服务区集群和操作系统级别的集群）来实现可伸缩性和高可用性。必须对此加以考虑，而且所得到的解决方案体系结构必须在
RAS 考虑事项和现有预算、组织内的技能以及操作复杂性方面求得平衡。
所需的中介
ESB 产品在不采用自定义编程的情况下处理中介的能力方面存在差异。最值得注意的是，WebSphere
Message Broker 提供了对各种标准数据格式（如 ACORD、SWIFT 和 COBOL Copybook）的广泛支持。如果数据格式是
XML 和 Web Services，则最适合使用 Websphere DataPower® SOA
Appliances，此产品可提供非常高的性能。
很多产品都可以用于创建企业服务总线（Enterprise Service
Bus，ESB）。IBM 提供了创建 ESB 的多个选项。这就允许客户根据其具体的需求选择 ESB 技术。在很多大型组织中，由于地理位置、技术或其他原因，可能会使用多项
ESB 技术来创建混合 ESB。当两个大型部门各自以独立的方式开始 SOA 然后又发现需要彼此进行互操作时，可能采用混合
ESB。
IBM 的三个主要 ESB 产品是 WebSphere Message
Broker、WebSphere ESB 和 WebSphere DataPower SOA Appliances。
WebSphere Message
Broker
WebSphere Message Broker 提供了很多客户用于创建其
ESB（或混合解决方案中的中央 ESB）的功能。WebSphere Message Broker 源自
WebSphere MQ 消息传递领域，特别适合 MQ 消息传递的环境。该产品提供 WSDL 和其他消息格式的接口定义，通过消息流提供中介功能，并支持各种通信格式，包括
WMQ 和 HTTP。WebSphere Message Broker 还基于发布/订阅交互和托管主题空间提供内容。
WebSphere Message Broker 支持各种服务交互端点的中介模式实现。它支持各种行业标准消息集（当然，只有其中一部分使用
XML 编码），支持添加对其他用户定义的消息格式的支持。以下典型客户需求非常适合使用 WebSphere
Message Broker 解决方案加以处理：
- 事务
- 发布/订阅
- ACORD、SWIFT 或 COBOL Copybook 标准格式
- 采用 XML 格式的数据
- 符合 WS-* 标准
- WebSphere MQ 消息传递
- 复杂转换
- 复杂事件处理
WebSphere Message Broker 提供了多个 ESB
连接选项和任意格式间的数据转换。通过这样，遗留应用程序和不符合标准的应用程序就可以连接到 ESB。
WebSphere ESB
WebSphere ESB 是 ESB 的 J2EE 实例化成果。WebSphere
ESB 在 IBM WebSphere Application Server 内的 J2EE 容器中运行。该产品非常适合基于
J2EE 和 WS-* 标准的应用程序，特别是只需要与其他应用服务器通信的应用程序。另外，该产品可作为进入
SOA 世界的敲门砖，允许将基本 Web 服务作为进入更为可靠的 SOA 环境的垫脚石加以利用。
WebSphere ESB 提供基于标准的 Web Services
连接性、JMS 消息传递和面向服务的集成。用于端到端和发布/订阅消息传递的 JMS 应用程序和面向 JAX-RPC
服务的应用程序可以直接连接到 WebSphere ESB，或者可以通过各种传输协议（包括 WMQ、SOAP/HTTP
和 SOAP/JMS）将消息交付到 WebSphere ESB。WebSphere ESB 实现了 Web
服务网关，此网关可以在基于 SOAP/HTTP 和 SOAP/JMS 的应用程序之间进行中介。最后，它还提供了统一描述、发现和集成（Universal
Description, Discovery and Integration，UDDI）的实现。以下典型客户需求非常适合使用
WebSphere ESB 解决方案加以处理：
- J2EE 实现
- Web Services 接口
- SOAP/HTTP
WebSphere DataPower
SOA Appliance
WebSphere DataPower SOA Appliance 是同时包含硬件和软件的产品，提供了大量的重要功能：XML
加速、安全措施执行和 ESB 功能。DataPower 具有多个重要特征：
- 经过优化的硬件、固件和嵌入式操作系统
- 确保配置锁定的高级保证措施
- 减少安全漏洞
- 加密密钥的硬件存储和锁定的审核日志
- 没有硬盘、CD ROM 或 USB 端口
- 篡改防护机箱，在机箱打开的情况下机器将变为不可用状态
- 降低操作复杂性，真正的 SOA 设备。通过 DataPower，能以最快的速度实现
SOA 入门，而且同时还能提供增强的安全环境。
以下典型客户需求非常适合使用 DataPower 解决方案加以处理：
- 安全网关
- XML 防火墙、解析和验证
- 基本路由
- 基于内容的路由
- 协议桥接（HTTP、WebSphere MQ 客户机、FTP、ODBC
等）
辅助技术
除了上面讨论的 ESB 技术外，以下补充产品还可以进一步加快或扩展 ESB
实现：
WebSphere Service
Registry and Repository
WebSphere Service Registry and Repository
提供了基本 UDDI 服务目录所不提供的很多功能。事实上，很多组织发现，由于 UDDI 规范尚不完全明确，不同提供商实现该规范的方式也不一样。WebSphere
Service Registry and Repository 不仅提供了关于存在哪些服务的注册中心，而且还提供了工具来向
ESB 提供这些服务和允许开发人员搜索现有服务供使用。WebSphere Service Registry
and Repository 包括：
- 包含关于服务的信息（如服务接口、其操作及参数）的服务注册中心
- 具有可靠框架和适合各种服务使用方法特征的可扩展性的元数据存储库
WebSphere Service Registry and Repository
几乎可以和 SOA 生命周期的所有部分进行交互：
- 通过标准资产管理解决方案与服务开发生命周期交互
- 在进行服务的变更和发布管理流程的过程中跟踪服务生命周期阶段
- 提供对运行时工具的优化访问
- 通过操作系统管理实用工具共享关于服务和服务元数据的信息
WebSphere Service Registry and Repository
提供关于何时何人对哪个服务进行了何种操作的信息。此功能将在下面的案例研究中进行讨论。
下面部分将介绍核心 ESB 中介功能的通用语言。这些模式可以非常方便地帮助在上下文中说明
ESB，可以用于表述与最佳实践和所得到的经验教训相符的可重复中介模式。ESB 用例可以表示为这些核心模式的组装。
协议切换
- 支持服务请求者使用各种交互协议或 API（如 SOAP/HTTP、JMS
和 MQ Integrator (MQI)）来发送其消息。
- 将请求转换为目标服务提供者的格式。
- 可以在交互的请求者和/或提供者端或两者间的任何位置应用。
- 此模式的中介通常在格式和彼此关系有明确定义的情况下自动创建。
|
|
| 修饰符 |
|
| |
|
- 转换子模式
- 消息有效负载从一个格式（模式）转换为另一个格式，从而将请求者的消息定义与提供者的消息定义匹配
- 包括“封装和取消封装”，即将采用一个网络格式的消息放入另一个网络传输所需的格式信封或对应的删除信封的过程。
- 包括加密
|
|
- 充实子模式
- 通过添加来自外部数据源的信息（如中介的自定义参数或数据库查询）来更新消息有效负载
|
|
路由器 (Router)
- 更改消息的既定路由，在与中介关联的服务提供者之间进行选择
- 示例：从金牌客户到备用的高级 SLA 提供者间
|
|
发现
- 查询 ESB 注册中心，以发现匹配请求者需求的一组服务提供者，选择其中一个，然后将消息路由到该提供者
- 路由模式的增强：
- 可能的服务提供者集不是在中介预先配置的
- 提供者匹配请求者的消息格式、所需的 QOS
或从中介到可能的提供者所支持的协议
- 示例：数据中心故障转移场景。在不更新每个中介的配置的情况下将数据中心上线，注册服务，将通信流量路由到对应服务
|
|
分发
- 将消息分发到一组相关方，通常由订阅者的兴趣概要驱动。
|
|
监视
- 用于在消息通过 ESB 的规程中观察消息，不过不会以任何方式更改这些消息。示例：
- 监视服务级别
- 提供用于进行问题确定的数据
- 退款测定
- 记录业务级别事件（超过特定收益值的交易）
- 记录消息供审核
|
|
相关（复杂事件处理）
- 从消息或事件流派生复杂事件。包含模式标识规则和响应模式发现规则，例如，通过生成从触发事件流的内容派生的复杂事件。
|
|
可以对这些基本模式进行聚合，以得到更为复杂的模式。
规范适配器
- 所有各方使用的消息和业务对象集规范化为规范格式。规范适配器模式可以将端点的本机总线附加协议转换为标准协议，对有效负载进行规范化并在交付时进行反向转换。此模式是协议切换和转换模式聚合后得到的。
|
|
转换、记录、路由
- 这是一个常见的 ESB 聚合模式。转换传入消息（转换），对其进行记录（监视）并路由到相应的端点。
|
|
代理或网关模式
- 路由或协议切换模式的变体，其中将对服务端点进行映射，并可能提供安全功能（授权和访问控制）和日志记录或审核功能。
- 可能包含转换和监视中介，以提供加密和日志记录或审核。还可能会采用一对多关系对消息进行聚合和取消聚合。
示例：充当多个服务的单个接触点并隐藏“内部”服务的服务门户 |
|
这些模式从更为现实的角度说明了如何使用 ESB 来实现所需的丰富服务虚拟化。在很多大型组织或没有
SOA 合作伙伴的组织中，经常会需要多个 ESB。很多原因都会导致此需求的出现，包括：
以下模式供演示之用，绝不能视为全面的叙述。其中很多模式都可以彼此进行结合，具体取决于特定项目的需求。
全局 ESB
全局 ESB 为所有服务请求者提供对一个注册中心的访问，每个服务对每个服务请求者都可见。此模式虽然可能适合小型系统测试环境，但可能不适合在生产环境中使用。这个适用性讨论所指的是没有其他
ESB 的全局 ESB，也就是说采用的是非混合方法。混合方法将在此部分稍后进行讨论。
- 在集中管理但地理位置分散的整个异类环境中，所有服务共享一个命名空间，而且每个服务提供者对每个服务请求者都可见。
- 供所有服务可能适用于整个组织的部门或小型企业使用。
对于全局 ESB 的情况，有两个主要 ESB 技术选项：WebSphere
Message Broker 和 WebSphere ESB。WebSphere ESB 是首选技术，其整个环境都基于
J2EE 和相关标准。存在与非 J2EE 系统的复杂转换和交互时，WebSphere Message Broker
可能更为适用。大型组织可能会发现同时运行这两个产品的做法更为合适，在此方法中按照下一个示例联合 ESB
中所讨论的方式根据消息类型和目的地对消息进行路由。
ESB 网关
ESB 网关模式提供内部和外部域边界间的受控制的安全服务交互。
ESB 网关模式经常使用 DataPower 设备进行实例化，因为这样可以在提供所需的网关功能之外提供
XML 防火墙。DataPower 非常适合用于网络边界，因为它使用的是嵌入式操作系统和软件实现，因此能减少设置操作系统环境所固有的风险。
联合 ESB
联合 ESB 提供了使用多个服务注册中心和管理域的功能，并同时将异类注册中心映射为服务联合集。联合
ESB 可促进采用多个 ESB 实现时的服务交互。联合 ESB 经常用于提供适用于整个企业的服务子集。
- 多个从 ESB 联合到一个主 ESB 中。
- 服务使用者和提供者连接到主 ESB 或从 ESB，以访问整个网络中的服务。
- 供希望将一系列具有适度自主控制的部门联合到一个监管部门之下的组织使用。
对于联合 ESB，“核心”ESB 可能为 WebSphere Message
Broker，而非核心 ESB 可以为 WebSphere ESB，或者对于小型远程办公室的情况，可以使用
DataPower 设备。在此模式中，每个站点都有自己的服务注册中心。在联合 ESB 模式中，最佳实践是在网络边界使用
DataPower 设备，以执行授权和身份验证以及在提交给内部系统前解析和验证 XML。通过这样，DataPower
设备可以加快事务处理速度和降低 ESB 服务器的 CPU 使用率。
代理 ESB
代理 ESB 用于在以下情况下支持多个注册中心，即服务子集适用于整个组织，但其中不存在单个服务的多个实现。
- 对选择性地将请求者或提供者向其他 ESB 域中的合作伙伴公开的服务进行桥接
- 每个 ESB 管理自己的命名空间。
- ESB 间的服务交互通过实现桥接服务的公用代理来加以促进。
- 如果各个部门开发和管理自己的服务，但共享其中的部分服务，或选择性地访问整个企业中提供的服务，则可使用此模式。
代理 ESB 模式与联合 ESB 模式非常相似，不过代理 ESB 充当执行点和服务路由器。
JBI 标准 (JSR 208) 的讨论中经常提到联合 ESB。到目前为止，IBM
已经放弃了 JBI 规范，因为此规范并没有在客户已经能实现的工作之上有足够的发展。很多技术和开放规范都提供了更为有竞争力的互操作性和更好的组件组合机制。IBM
首先关注的是支持最广泛的产品、应用程序和现有业务资产集成。
ABC Hotel 是一家全球性的酒店与休闲企业。该公司拥有多个品牌，提供豪华与高档全面服务的酒店。这包括超过
900 家全资、托管或特许经营酒店，房间总数超过 230,000 间。
ABC 开始了一个持续多年的大型 IT 项目，将其基于大型机的大型独立中央预订系统（Central
Reservations System，CRS）替换为作为分布式 J2EE 服务实现的系统。进行此项目的推动因素是要减少成本（替换大型机）和提高业务灵活性。该项目被普遍认为是将采用
SOA 的概念和理论的项目。服务要部署在两个分布在不同地方的数据中心中。将为各个服务部署多个实例，以促进系统吞吐能力和可用性。
值得注意的是，CRS 项目最初并没有考虑通用 ESB 框架。随着项目的逐渐成熟，服务集成的复杂性达到了不可接受的程度。这给架构师、开发人员和操作带来了极大的负担，成为了成功完成
CRS 项目的阻碍因素。因此作出了进行重构来包含 ESB 的决策。ABC 进行了相关评估，以选择合适的行动方案。
向 IBM 提出的 ESB 需求的摘要：
- 请求路由和工作负载管理：在基础设施内为各个服务部署多个副本，以提高可靠性、可服务性和可用性。ESB
应该将客户机请求路由到所请求服务相应的版本和实例。ESB 还应该进行一些工作负载管理的部署，将请求分发到相同的服务实例。这可以为简单的负载分布算法，但该公司对更为主动性的端点驱动的负载工作负载管理有着很强烈的兴趣。
- 注册中心集成：ABC 采用了基于 UDDI 的服务注册中心处理构建时服务目录。没有部署更为主动的运行时服务注册中心，但支持此类注册中心的需求得到了公司的认可。
- 中介：ABC 希望使用 ESB 来在客户机和服务之间进行中介。服务数据以
WSDL / XML 格式表示，因此不需要处理更为深奥的数据格式。消息验证（WS-I 和 XSD）以及对性能/转换加速的支持是主要的推动因素。
- 事务管理：ABC 具有某些特殊的用例，此类用户将需要对提交的服务请求进行补偿和回滚（组合服务中的分布式事务支持）。他们需要支持基于规则、流程驱动的原子事务。
- 服务编排和工作流：复杂工作流支持是服务交互的小子集的一项需求。最好在这些情况下有
BPEL 支持。最好还支持业务状态机、交互的计划和安排、事件相关和涉及人工交互的工作流。
- 能够促进与后端系统的集成：希望有直接与 Siebel
及其他后端系统集成的能力。
- 高性能/低延迟：ESB 应该对总体性能和延迟的负面影响最小。
- 监视、管理、维护：总的说来，在服务级别监视、收集标准和自定义标准、错误检查、根源分享、报告和历史分析方面存在各种广泛的需求。自动操作员警告和通知工具非常关键。
- 安全性：需要与 Tivoli Access Manager、LDAP
和其他第三方安全产品实现集成。凭据和密钥管理功能、基于标准的身份验证、访问控制、加密/解密、SSL
加速、Sarbanes-Oxley (SOX) 控制和 DMZ 部署的适合性都需要考虑。
- SDLC：ABC 使用基于 Eclipse 的 Rational
Application Developer 和 Rational Software Architect。最好能使用适合其现有环境的
ESB 开发工具。
- 快速部署：ABC 在选择重构来包含 ESB 之前已经进行了大量的投资。部署的成本和速度是非常关键的考虑事项。
- 减少操作复杂性：减少风险和复杂性是推动 ABC 进行重构以获得基于
ESB 的体系结构的重要因素。ABC 非常希望得到了高效且复杂度低的解决方案。
示例用例
调用后端服务的业务合作伙伴
ABC 定期与业务合作伙伴通信，以获得房间可用性和预订请求。需要使用
DMZ 部署模式实现后端服务调用的虚拟化。必须对客户进行身份验证和授权。另外，必须监视和记录所有活动。
将来可能会需要按客户机、请求类型或其他信息对通信流量进行划分。
调用后端服务的酒店属性
各个属性都具有本地属性管理系统（Property Management
System，PMS），而这些系统必须通过接口与 CRS 连接。一个场景是更新房间和清算可租房间总量的属性。CRS
必须注意可租房间总量的变化。属性使用 XML over MQ 通过接口与 CRS 连接，而 CRS 服务可能使用其他连接协议（如
SOAP/HTTP）部署。
类似地，可以对此模式进行扩展，添加按端点使用率统计数据进行路由的能力。
上面两个用例一起处理了所有 ESB 通信流量中的大部分流量。
复杂恢复错误场景
在此场景中，假定在从属性满足客户机请求时在组合服务交互中出现错误。从错误恢复非常重要，需要可能包括人工任务的工作流。核心
ESB 模式并不会更改，不过执行体系结构将包括额外的组件，以支持这个功能。
包含后端集成的复杂工作流
在此场景中，一个创建客户的请求进入了首选客户跟踪系统。业务用户希望将此信息中的各个部分输入到作为中介的一部分
Siebel 中。 ESB 充当现有服务的标准中介，而同时还包括对 ISV 后端系统的更新。这里适用传输-监视-路由
ESB 聚合模式，但执行体系结构将利用多个 IT 组件来处理服务请求。
解决方案体系结构概述
IBM 建议采用混合 ESB 体系结构，其中既包括硬件 ESB 实现，也包括软件
ESB 实现。每个实现的 ESB 功能方面存在不同的优缺点。
设备
- 经过优化，可提供很高的性能，而且处理延迟非常小
- 配置、部署和操作最简单
- 安全，篡改防护
- 从通用平台分流开销大的处理负载
软件
- 应用程序承载支持、工作流支持和复杂中介
- 通过适配器进行应用程序集成
- 支持业务活动监视
IBM 希望广大客户都部署可充分利用这两个方法的优势的混合体系结构。在混合体系结构中增加了
SOA 服务注册中心和管理功能。
解决方案组件
- DataPower XI50（硬件 ESB）
- WebSphere Process Server（包括 WebSphere
ESB）
- WebSphere Business Integration Adapter（与后端系统集成）
- IBM Tivoli Composite Application
Management for SOA（服务监视和管理）
- WebSphere Service Registry and Repository（服务注册中心）
以下系统上下文关系图说明了这些组件的交互。
DataPower XI50 在此体系结构中充当两个角色：服务网关（在
DMZ 中）和通用硬件 ESB（在受信任区域中）。需要软件 ESB 实现的任务（如使用 Siebel Adapter
或涉及人工交互的复杂错误恢复）分流到 WebSphere Process Server（其中包括核心组件
WebSphere ESB）。
DataPower 处理 ABC 的大部分 ESB 通信请求，可保证非常高的性能。WebSphere
Process Server 和 WebSphere ESB 对 DataPower 的功能进行补充，以支持在体系结构中实现最大的灵活性。
IBM Tivoli Composite Application Management
产品支持对 ESB 及与其交互的组件进行监视和管理。监视代理收集的信息可以支持复杂的 ESB 充实和路由模式，如动态服务选择（根据监视代理收集的承载服务器负载之类的信息选择目标服务）。
WebSphere Service Registry and Repository
支持服务的完整生命周期管理，在支持 ESB 中的动态服务选择方面扮演着重要的角色。正如上面所述，仅仅 UDDI
并不足以处理这些任务。
此体系结构旨在在性能和灵活性方面取得较好的平衡。
XYZ Insurance 是一家医疗保险提供商。该公司为数百万客户提供保险服务，必须与客户、提供商、第三方代理和其他实体进行交互。此示例是多个实际保险项目的组合。
XYZ 决定开始 SOA 项目，以实现其信息技术的现代化，并充分利用在使用
COBOL、Assembler 和 PL/I 编写的大型机 (z/OS) 应用程序方面的大量投资。这些系统适用
DB2 和 IMS 数据库，与最终用户的大量通信都是通过客户信息控制系统（Customer Information
Control System，CICS）进行的。IBM 的 WebSphere MQ 提供了应用程序内和应用程序间的消息传递中枢的大部分功能。其中有一个主数据中心，该数据中心连接到多个外围数据中心和第三方系统。
XYZ 决定使用面向服务的体系结构 (SOA) 来构建新呼叫中心环境（Call
Center Environment，CCE）和构建新的索赔处理应用程序（Claims Processing
Application，CPA）。还有很多其他应用程序和更改，但我们将重点关注这两个主要系统。
IBM 和 XYZ 用于定义体系结构的总体项目需求包括：
- 在无需重新编写代码的情况下利用遗留应用程序
- 利用大型机系统，并同时在为该应用程序所选的平台上创建新服务
- 支持多通信协议（SOAP/HTTM、WebSphere MQ 等）
- 安全地支持与外部组织的 SOA 交互
- 在包含分散在不同位置的多个数据中心的环境中操作
- 提供实时监视和根据所需的服务级别路由事务的能力
其 ESB 需求与 ABC 案例研究类似，不过需要更为复杂的中介。另外，由于很多法律法规的要求，其安全性和可审核性必须比
ABC 案例研究中更为可靠。
示例用例
调用主数据中心服务的远程数据中心
远程数据中心之一频繁调用主数据中心，以支持呼叫中心环境 (CCE)。虽然这是在组织内进行，但这种情况下仍然使用了网关来确保满足应用程序安全性和审核要求。
在本例中，对主数据中心的单个服务调用可能会导致遗留应用程序内出现多次服务调用，从而需要服务编排和工作流组件将所得到的信息组装为单个服务响应。
服务交互的远程数据中心端如下所示：
服务交互的主数据中心端如下所示。请注意，为了清楚起见，并没有在关系图中给出网关和监视组件，不过它们当然是解决方案中至关重要的组件：
主数据中心调用远程数据中心服务
主数据中心将频繁调用远程数据中心之一，以确认最新的呼叫中心环境 (CCE)
活动。这就要求远程数据中心具有完整的 SOA 环境，并具有与主数据中心完全相同的安全性和审核功能。
服务交互的主数据中心端如下所示：
主数据中心调用第三方服务进行地址验证
在接受地址并将其存储在 XYZ 的数据中之前，主数据中心将调用第三方服务来验证地址是否有效。
外部代理对遗留应用程序服务进行服务调用
虽然外部第三方应用程序将没有必要知道所调用的服务是遗留应用程序，但此用例在体系结构的角度非常有意义。
服务交互的远程数据中心端如下所示：
服务交互的主数据中心端如下所示。请注意，为了清楚起见，并没有在关系图中给出网关和监视组件，不过它们当然是解决方案中至关重要的组件：
基于服务调用模式的欺诈检测
基于服务调用模式的欺诈检测是较为复杂的情况，不仅需要监视调用的数量，还要监视进行调用的实体以及调用的时间。在本例中，如果获知某个特定用户涉嫌对一个使用者或提供者进行异常的大量调用，将临时禁止用户的访问权限，并通知
XYZ 调查此异常行为。这个监视、记录、相关和安全系统集成存在着极大的挑战，不过可以使用现有 ESB 技术并结合其他
SOA 技术来加以处理。
解决方案体系结构概述
IBM 和 XYZ 合作创建了包含硬件和软件 ESB 组件的混合 ESB
体系结构。在本例中，应用了所有三项 IBM 的 ESB 技术来提供所需的功能。对遗留集成、服务编排和基本工作流的需求推动了关于使用这组技术的体系结构决策。
以下系统上下文关系图说明了这些组件的交互。
和 ABC 示例中的情况一样，DataPower XI50 扮演着两个角色：DMZ
中的安全防火墙和受信任区域中的 ESB.WebSphere Process Server/ESB 用于对复杂服务交互进行编排，负责从数据结构获取数据并将其组合为更为复杂的业务服务响应。WebSphere
Message Broker 用于处理与遗留系统交互所需的复杂消息转换。此示例说明了在一个设计中使用所有三个
IBM ESB 解决方案的价值，其中的每个解决方案都得到了充分的利用，体现了各自最重要的功能。
IBM 认识到很多组织将具有与 XYZ 类似的复杂需求。这些需求将对多项技术的使用起到促进作用，从而提供最为恰当的功能，满足可用性、性能和安全性需求。
解决方案组件
XYZ 使用的解决方案包括：
- DataPower XI50（硬件 ESB、XML 安全网关）
- WebSphere Process Server（包括 WebSphere
ESB 和复杂服务交互的流程编排）
- WebSphere Message Broker（支持复杂消息转换和非标准消息传递的软件
ESB）
本文提供了 ESB 使用的概念和实际示例。文中讨论了创建 ESB 的技术选项以及哪些产品最适合各个特定情况。和任何技术主题一样，使用本指南时应该结合有经验的专业人员的经验来设计最适合特定情况的解决方案。
| 
