本文将介绍并定义一组连接性模式，其囊括了应用程序连接性领域一些较为常见的解决方案。其中很多模式都以一个较为通用的体系结构模式为基础，即企业服务总线（Enterprise Service Bus，ESB），并对其进行了优化。在定义这些模式的分类方案和讨论影响其选择和实现的各个因素时，本文及相关的 developerWorks wiki 可以帮助针对您的特定连接性需求选择合适的解决方案。

引言

企业服务总线的价值在企业集成实践中已经得到了大家的认可，不过，在规划和构建集成体系结构时，此类总线提供的灵活性本身可能导致在选择时举棋不定（请参阅参考资料）。而支持此类体系结构模式的中间件产品所提供的功能范围进一步加剧了这种情况。另外，这些产品通常不仅支持特定服务总线概念，在更广泛的面向服务的体系结构上下文中作为对服务进行连接和虚拟化的基础结构，而且支持更为通用的服务总线概念，作为非常通用意义上的服务的连接性基础结构。在本文中，我们使用的服务总线（或企业服务总线）的术语范围更为广泛。

这一组核心模式集以通过很多实际实现获得的经验为基础，并进行了抽象，提供了一个框架，以便进行适当的体系结构和实现决策，促进产品选择和使用，并从所建议且经过验证的企业应用程序和服务集成方法获益。在选择和描述此类模式时，需要考虑很多不同的方面：

• 总体集成解决方案体系结构模式
• 各个端点之间的交互样式
• 所需的操作方面
• 要应用的安全模型

将所有这些组合在一起，就可以定义特定的连接性中介模式。

本文将介绍一组此类模式，在使用以下这些 IBM WebSphere 企业服务总线产品组合实现的解决方案中经常采用这些模式：WebSphere Message Broker、WebSphere ESB 和 WebSphere DataPower Integration Appliance XI50。目前正在编写这些模式的详细规范和对应的实现说明及示例，具体请参见关联的 developerWorks 企业连接性模式 wiki。

连接性解决方案体系结构模式

从总体集成体系结构角度而言，我们能够确定六个连接性解决方案常见模式类别：

• 服务虚拟化
• 服务支持
• 网关
• 基于消息的集成
• 文件处理
• 事件驱动的集成

下面的部分将对每个类别进行更为详细的介绍。

服务虚拟化

服务虚拟化模式描述我们如何通过企业服务总线提供额外的间接级别来提供服务间的真正松散耦合。换个角度来看，在处理面向服务的体系结构中的连接性需求的同时，这些模式还将处理服务间的中介需求（路由、协议转换、数据转换、日志记录等）。

服务虚拟化模式封装了范围相对较窄的服务总线定义，通常用于处理一系列截然不同的需求，包括：

• 松散耦合——将现有服务在 ESB 上以虚拟服务的形式表示
• 提供者方面的部署要包括转换、充实等。
• 提供者方面的部署要为非标准服务提供标准接口
• 部署标准服务管理实用工具（安全性、日志记录、监视、计费等）

以下是此模式的一些示例。

• 简单服务代理

  使用服务代理是 ESB 的基础模式之一，能提供大部分面向服务的体系结构所需的松散耦合。此模式以现有服务为基础，将在 ESB 上部署一个新虚拟服务，以便通过受控访问点进行访问，并可能使用与原始提供者不同的协议。这就引入了一个中介点，在这个最简单的 ESB 模式中，中介经常限于各种类型的日志记录和安全配置。不过，通过将 ESB 作为中介点引入，还可以引入服务管理功能，例如，错误处理和警报、通信流量管理、服务计费以及性能指标。很多其他模式都是通过对这个基本模式充实得到的。

  此模式支持 SOA 中的服务治理，经常用于要求所有业务级别或企业级别的服务只能通过总线访问，且必须对此类服务使用标准管理功能的情况。

  通过此模式，还能保护访问安全和隐藏组织 IT 基础架构的内部结构，从而提供了从企业自身的安全区域外访问服务的入口点。

• 服务选择器（路由器）

  服务选择器模式对简单服务代理模式进行了扩展，引入了路由服务请求的概念。这可以是用于维护松散耦合的简单端点查询，也可以用于基于消息中的数据、请求的时间或备用提供者服务进行路由。

  此模式用于地理位置分散的中心中承载的服务提供者的多个实例的情况，将基于帐户详细信息选择相应的服务。还可以通过其保持需要一定停机时间的全球企业的全天候服务，或提供基于客户优先级或高价值服务请求实例提供优先级路由。

• 服务转换器

  服务转换器模式也是通过对简单服务代理模式扩展而来。将最终提供者的接口作为企业服务在总线上发布的接口的做法可能并不总是最好的做法。服务转换器模式引入了转换，允许对 ESB 提供的接口采用与最终提供者不同的格式。

  数据在企业中的标准化通常是想要达到的目标，但在大多数情况下，这并不是能够达到的目标。不过，此类格式的定义可以简化新开发，在定义标准数据模型的情况下，可以实现此模式，方法是通过向服务提供者提供服务 Facade，将其从企业标准转换为特定提供者。

• 服务规范化工具

  此模式对转换器和路由器模式进行了扩展，支持备选服务提供者（使用不同的接口提供语义等效的服务）概念。路由采用与服务选择器相同的方式确定，而路由后应用到服务请求的转换将确定目标服务和接口。

  通过此模式，可以在 ESB 上为虚拟服务提供单个接口，由 ESB 确定哪个提供者最适合每个请求，并在调用提供者服务之前应用必要的转换。

• 版本选择器

  此模式是服务转换器模式的专门化模式，由于自身的特殊性，它可以应用于一系列其他模式。转换器旨在对请求进行路由，而版本选择器则用于确保客户端请求路由到相应的服务版本。

服务支持

这个类别的模式处理封装功能的问题，其本身并不提供服务接口，而是通过面向服务的接口提供此功能。这代表着从更为传统的企业应用程序概念过渡到面向服务的体系结构，允许以新的方式重用现有服务，而且不需进行彻底的变更。它允许实现 ESB 来提供对企业中使用各种技术实现的功能派生出来的“服务”进行访问，并向服务使用者提供这些服务单一的一致视图。

其中一些重要的例子有：

• 简单服务 Facade

  此模式最简单的形式与服务代理接近，但在这种情况下，服务请求不会由服务提供者完成，而是由现有服务完成，此应用程序通过消息、适配器或其他 API 进行访问。适配器可以使用应用程序进行定位，或者实现为 ESB 组件，后一种方式更为常见。

  路由、转换和规范化也可以采用与扩展服务虚拟化相同的方式对此模式进行扩展。

• 复杂服务 Facade

  进一步的扩展可以包含来自功能更为丰富的 ESB 的集成逻辑，从而构建服务能力，并可以使用多个功能源，然后将其作为 ESB 上的虚拟服务提供。此模式经常用于从较低级别的 IT 服务、组件或细粒度应用程序功能构建更高级别的业务或企业服务。

  集成逻辑可以采取多种方式构建，不过通常的做法有调用序列、使用响应聚合的多个请求或信息分发。

• 客户端访问

  这一组模式为没有启用面向服务的客户端访问的客户端提供入口点。这很可能通过适配器进行，允许将现有打包应用程序纳入到包含 SOA 方法的企业体系结构中来。

网关

网关 是消息总线或服务总线的一部分，提供应用到所有传入消息且不依赖于格式的边界功能。

边界功能通常使用来自标准 Header（传输级、SOAP 级甚至数据级）的数据确定要采取什么操作，不过并不需要了解消息数据（或主体）的完整格式。网关模式然后可以直接调用服务或调用其他模式。这些边界功能包括：

• 请求路由
• 身份验证
• 授权
• 审核和日志记录
• 协议转换
• 响应相关

网关模式的示例包括：

• 安全网关

  这个相当具体的网关模式示例能从主要基础结构分流所有非标准安全处理，将执行身份验证、授权，并可能在调用真正的目的地之前进行审核。在此模式中，网关和 ESB 的其他部分之间几乎总是存在受信任链路，因此 ESB 的这些其他部分所需的安全模型可以得到简化。安全网关可能驻留在与 ESB 的其他部分不同的安全区域，将向外部客户端提供连接。此模式将支持各种传入安全协议，而且同时能简化其他 ESB 组件中的安全措施。

• 服务连接器

  网关模式可以提供最简单的方法，将大量现有服务连接到 ESB 中，并将其作为基于面向服务原则的企业体系结构的一部分引入。网关在企业体系结构中引入了一个控制点，可以将一系列临时服务置于服务注册中心和关联的治理之下，但不需要为每个服务开发单个中介流。消息进入网关，并路由到最终提供者、提供者 Facade 或其他中介流。

• 边界中介器

  边界中介器 模式对服务连接模式进行扩展，允许将标准中介应用到所有传入（和/或传出）服务请求或消息。这些标准（独立于内容的）中介在网关中进行一次性开发，可以应用于所有传入消息。这些中介可以包含任何或全部验证、日志记录、审核、身份验证和授权。还可以基于网关属性全部或有选择性地应用，基于请求数据或传入请求中的数据（通常位于 Header）进行查询。

基于消息的集成

ESB 可以扩展现有消息传递基础结构，提供用于构建和部署“基础结构级别”的基于消息的“应用程序”。此类“应用程序”的例子包括路由和转换服务、日志记录服务等等。这可以对单个底层消息传递基础结构进行扩展，也可以在不同的产品和技术之间提供桥梁。可以使用适配器来提供对不具有内置消息传递功能的应用程序或服务的访问。

就功能而言，基于消息的模式某种程度上与服务虚拟化模式对应。不过，在我们对其的认识方面有一个关键的差别。在面向服务的模型中，我们通常关注可供很多任意“客户端”使用的服务的提供，即我们从“提供者到使用者”的角度看待问题。在面向消息的模型中，我们通常更关注在系统中流动的数据和要应用到这些动态数据的操作，即我们从“生产者到使用者”的角度看待问题。虽然这并非绝对，不过这些看法可能会影响我们希望应用每个模式的环境。

一些具体的示例如下：

• 消息路由器

  消息路由器 模式可以用于提供应用程序或服务之间的较强级别的分离，这些应用程序或服务需要交换数据，允许基于各种条件将从一个应用程序发出的数据路由到多个潜在目标应用程序之一。

  基于上下文的路由器 基于发送方身份或协议 Header 中包含的某些数据选择相应的目标。基于内容的路由器 基于消息有效负载的内容进行选择。基于负载的路由器 使用关于各个目标系统上的应用程序负载的信息进行选择。
  　

• 消息转换器

  消息转换器 模式允许将来自一个应用程序的数据映射到另一个应用程序所需的格式，而且两个应用程序都不会认识到需要或进行了此类映射。这个模式涉及范围非常广，包括从直接映射到涉及查询和交叉引用的高度复杂的转换。
  　

• 消息传递桥接

  消息传递桥接 模式将数据从一个传输机制映射到另一个传输机制，无需修改消息有效负载的格式或内容。此模式的实现还必须处理独立消息传递系统可能使用的不同寻址方案间的差异。

  此模式的一个常见例子是对来自不同供应商的 JMS 实现进行桥接。
  　

• 消息聚合器

  消息聚合器 模式处理从一个或多个应用程序获取多个消息并将其合并为单个信息，以作为新消息传播。入站消息可以来自独立应用程序或可以为来自一组应用程序的异步响应消息，而这些应用程序从消息拆分器模式（在下面描述）实现接收请求。

  此模式的实现可以直接连接各个源消息，或包含一些更为复杂的数据映射功能。它还必须能够处理预期入站消息未能在归档时间内送达的失败以及后来延迟送达的此消息。
  　

• 消息拆分器

  消息拆分器 模式提取消息的子集，然后将其作为独立的消息发送到多个目标应用程序。映射规则集定义原始入站消息如何划分为多个部分。

• 消息请求/响应相关器

  典型的消息代理系统经常将以异步方式处理来自相同流或并行队列的多个请求。将此类请求路由到其他系统时，需要将任何响应消息与原始请求相关。消息请求/响应相关器模式提供了处理这个特定问题的解决方案。

文件处理

ESB 可以提供用于处理文件（本地或使用 FTP 协议）的托管执行环境。

通常，这将涉及到各种活动，包括对文件中包含的数据进行转换、将文件划分为多个事务记录、记录的路由、将记录累积为目标文件和/或将文件（整体或各个记录）路由到指定的位置/处理器。此模式的示例及用例有：

• 文件记录处理器

  此模式处理输入文件中的每个记录，并将所得到的经过处理的结果累积为一个或多个“临时”目标文件，此文件将在完成时移动到目标目录。此模式支持提供包含间隔事务结束的批处理文件处理需求。这可能是在源和目标系统不支持事务接口时传输累积事务，或者可以是预期在特定时间发生的事务的传输。
  　

• 记录批处理器

  此模式接收服务请求、消息中的数据或通过适配器接收数据，并在处理后将记录生成临时文件，以供在完成后移动到目标位置。它支持较新的系统和仅支持批处理接口的遗留系统之间的交互。这可能是第一步，帮助过渡到面向服务特征更明显的体系结构，或者在收购后将获得的批处理系统集成到更为事务化的环境。此模式还能为累积数据进行夜间处理的需求提供支持，这可能包括货品计价、帐单编制、合同问题和相关文档及更新通知。
  　

• 文件记录分发器

  此模式将文件划分为记录，并使用每个记录进行一次服务调用，或将消息传递到具有事务接口的一个或多个系统。此模式的典型用途是处理 EDI 文件，此类文件包含一系列不同类型的事务，需要各个进行路由和处理。也采用此方法通过使用参考数据更新系统，尤其是此类更新的时间不重要时，例如在给定开始日期进行更新的情况。

事件驱动的集成

本文中的模式考虑的是 ESB 上的连接性，我们并不打算建立“事件驱动的体系结构”的完整模式集。不过，尽管尚未明确建立“事件驱动的体系结构”（此术语可能涉及一系列不同的应用场景），但是在有些“EDA”场景中，ESB 将发挥关键作用。这包括与复杂事件驱动引擎的集成，包括筛选信息或事件流的能力、事件的“实时”分发（我们所指的是应用程序所需的速度）和物理设备（检测仪、传感器）事件的处理。

此模式的示例及用例有：

• 事件分发器

  此模式可将事件（采用按“主题”和关联数据的相应分类）分发到多个相关方，这些相关方注册了基于每个事件的标记（“主题”）或关联数据通知所发布事件的子集的需求。数据发布 到 ESB 上的发布点，并从该发布点分发到注册了该信息的所有订阅者。

  发布到发布点的事件可能代表状态的更改，并提供了对所有订阅者（新订阅者或请求刷新的订阅者）可用的最新状态。或者，事件可能代表数据流，每个“事件”将分发并随后删除。

• 事件筛选器

  此模式提供了进入 ESB 的事件（交互）的处理，对其进行筛选，并转换为重要事件流，以传递到事件引擎。这可能是用于检测复杂事件的事件处理引擎，或监视业务事件的系统（例如，仪表板应用程序）。此模式支持单向通信，纯粹充当事件引擎的预处理器。

  此模式的特殊专门化模式将为来自各种传感器、执行器和适配器的数据提供入口点。

• 事件提取器

  此模式监视 ESB 上的交互，并对其进行处理，以提取相关事件并传递到事件处理引擎。此模式支持单向通信，纯粹充当事件引擎的预处理器。

• 事件反应器

  此模式与前一模式类似，充当事件引擎的预处理器。不过，此模式支持与事件引擎的同步交互，并可能接收到响应，指示最近的事件已触发了一个复杂事件。ESB 流然后可能会对此事件进行响应，例如，向出现此类事件时需要进行操作的目标发送警报。

操作方面

总线的面向方面的连接性 功能包括在后续部分描述的交互样式和安全模型，并提供了各种标准服务管理功能或实用工具，通常包括：

• 验证
• 日志记录
• 审核
• 错误处理
• SLA/性能指标

中介这些方面是抽象的，根据总体解决方案体系结构的需求与特定的集成模式结合使用。

交互样式

契约行为模式定义交互样式和服务质量。我们当前确定了八个关键交互模式：

• 单向保证交付
• 同步读取请求
• 无事务的同步更新
• 全局事务的同步更新
• 具有确认和回调的同步更新请求
• 具有确认的同步更新请求；提供者保证操作
• 具有确认的同步更新请求；ESB 处理错误
• 采用异步方式的单向模式
• 轮询完成状态的单向模式

这些模式是抽象模式。他们从同步/异步接口、交付的保证级别、处理时间超时及响应延迟和错误处理的角度定义交互行为。此类行为契约不直接实现，而是与特定交互模式组合来创建具体的行为模式。

单向保证交付
此交互模式的目的是确保可靠交付和处理。 所有通信都得到了保证。 每个被调用的组件都将可靠地报告错误 消息在出现错误时将得以保持。 ESB 并不拒绝消息，但会尝试进行处理。 捕获错误时将包含完整消息内容 错误处理（在 ESB 范围外）修复问题。 应该按吞吐量（时间段平均消息数/请求数）测定 SLA。
同步读取请求
此模式的目的是提供不会因错误产生副作用的简单请求机制。 请求方等待响应，但必须超时 不保证从提供者获得及时的响应 ESB 等待时间比请求方短，而且 ESB 可能会向请求方提供显式超时错误 消息不会保持 应该按响应时间测定 SLA，即等待响应达到的时间。
无事务的同步更新
此模式旨在提供更新机制，并不保证交付或处理，而且请求方必须负责处理错误或超时情况。 基本行为与同步读取请求相似 请求方在超时时的错误处理可能包括： 如果操作是等幂操作，且错误是超时，则重复 到时间后进行协调 调用手动或半自动错误处理 ESB 在调用提供者超时或收到错误响应的情况下进行错误处理 如果操作是等幂操作，且错误是超时，则重复 告知客户端 置于错误队列上 到时间后进行协调 应该按响应时间测定 SLA，即等待响应达到的时间。
全局事务的同步更新
此模式旨在提供跨服务请求方、ESB 和服务提供者进行同步更新的机制。 所有参与方都必须支持事先达成一致的事务协调协议，例如 WS-AtomicTransaction 提交失败将导致对任何组件所完成的任何更新进行回滚 出现事务时资源将锁定 所有应用程序必须做好在指定时间内事务未完成的情况下进行回滚的准备。 应该按响应时间测定 SLA，即事务完成的时间。
具有确认和回调的同步更新请求
此模式的目的在于，允许请求方使用同步协议确定请求已提交，且将会被处理，并在处理请求后告知请求方。 请求方仅支持同步协议/行为 请求方进行更新请求，然后收到已被接受（或拒绝）的确认信息 在确定消息已收到前，ESB 并不会进行确认。 ESB 使用有保证的交付向提供者发出更新请求 提供者服务同意使用更新结果进行回调（异步）的行为 请求方可能会保留待处理更新请求列表 代理必须确保请求方已收到了回调（如果超时则进行重试） 可以将错误处理分配给任何参与方 应该根据确认信息响应时间和请求完成的时间间隔测定 SLA
具有确认的同步更新（ESB 处理错误）
此模式旨在允许请求方使用同步协议确定请求已提交并将被处理。此模式保证错误将得到处理，不会对请求方进行回调。 请求方仅支持同步协议/行为 请求方发出更新请求，并得到确认信息，指示已接受（或拒绝）。是否已接受操作由代理和提供者进行保证。 ESB 使用有保证的交付向提供者发出更新请求，或在失败时调用错误处理 提供者服务具有事先达成一致的行为来确保进行更新或调用处理流程 应该根据确认信息响应时间和/或请求完成的时间间隔测定 SLA
采用异步回调的单向模式
对于可靠的单向请求，服务提供者可能返回对原始请求方的异步调用。 应该按吞吐量（时间段平均消息数/请求数）测定 SLA。
采用轮询完成状态的单向模式
所有通信都得到了保证。 每个参与方依赖于下一步按照预期行为可靠执行 每个被调用的组件必须可靠地将错误报告给错误处理流程 在出现系统错误的情况下，消息必须得以保存。 请求方轮询提供者，以确定何时完成了更新。 应该按吞吐量（时间段平均消息数/请求数）测定 SLA。

安全模型

在定义安全模型和模式时，需要考虑两个方面：

• 全体参与方
• 所需的全部安全执行策略

参与方必须一起执行安全措施来确保满足对身份验证、授权、审核、机密性、完整性和可用性的要求，而且不会将性能降级到不可接受的程度。

SOA 安全模型中的参与方

任何基于交互的服务都将包括以下主要参与方：

• 请求应用程序或流程
• 中间服务：中间件功能，提供请求方和提供者之间的集成功能，通常归为总线或 ESB。
• 提供者应用程序/服务提供者

其中假定配备了用于对这些组件进行增强的基本安全措施，作为模式基础的信任模型随后会将相对于运行时交互的安全能力分配给每个参与者。

可能还有其他支持参与方参与模式的实现，并对所使用的机制的能力具有影响。

• 当不同于请求应用程序时启动用户和关联的设备/软件。
• 提供以下功能的安全性提供者：
  • 身份验证
  • 授权
  • 审核
  • 监视和警报
  • 标识/凭据，可能会在某些上下文中作为安全令牌服务器引用

    尽管与这些提供者关联的用户注册中心的部署显然是总体安全解决方案的一部分，但运行时模式中不用考虑这些注意事项，会假定部署了足够的机制。

• 防火墙和代理
• 网络组件
• 服务注册中心，如果安全策略或配置文件在注册中心中使用服务定义配置

上面的参与方列表并不足以分离组件，可能会使用产品或组件构建场景，这些产品或组件在一个或多个此类参与方角色中运行。例如，应用程序可能在不同的端到端交互中同时支持请求方和提供者角色，或者外部安全服务可能支持所列出的一个或多个功能。

当安全功能跨 SOA 事务中的参与方分布时，在各自完成总体安全中相应部分的参与方之间必须具有信任关系。

由于这些功能在各个参与方间的分布，会产生对参与方之间的信任关系以及不同组件的功能的不同需求。每个组件可能在执行安全角色方面有多个选择，而必须确定端到端路径来与所有功能的情况相匹配。

安全模式

经常会遇到信任模型的以下主要模式：

• 端到端信任

  ESB 信任请求应用程序，由后者对最终用户进行身份验证和授权，而服务提供者将 ESB 视为经过身份验证和授权的用户。安全执行中不使用最终用户标识，但可能包括在数据中用于进行审核。安全模型仅要求能够在交互中标识每个组件，这可以在网络体系结构级别或通过使用通用应用程序标识实现。

  此场景经常用于所有组件都是内部组件、使用相同的安全性管理且属于受信任计算机群的情况。具有定义良好的身份验证和授权的企业 CRM 系统与企业后端办公室系统间的集成通常采用此模型。

• ESB 基于应用程序标识执行安全性

  在此模型中，ESB 不再完全信任请求应用程序，将需要凭据来对请求方的身份进行验证。ESB 将在处理前断言此用户是否得到了进行此请求的授权。由于请求应用程序不受信任，因此审核要求将由 ESB 满足。

  提供者服务会将 ESB 视为受信任用户，所有请求都使用 ESB 的标识或 ESB 上已知的受信任服务的标识发出。

  端到端安全模型意味着所有提供者将授予所有受信任的请求应用程序访问权限。在要求对信任进行分区的情况下，例如要将特定财务敏感服务限制为仅能由受信任应用程序的请求访问，而此类应用程序又仅允许特权用户访问，此模型会将此分区职责分配给 ESB。

• ESB 基于最终用户标识执行安全性

  此场景与前一种情况非常相似，都由 ESB 应用身份验证和授权，但本场景中需要使用最终用户的标识，而不是请求应用程序的标识。在此模型中，提供者服务信任 ESB，但要求提供最终的标识，因此需要 ESB 断言最终用户的标识。ESB 和提供者服务之间的链路可能由网络体系结构、ESB 凭据或使用 PKI 的加密进行保护。

  此模型用于提供者服务需要最终用户标识的安全断言的情况，以基于提供者内的业务逻辑提供细粒度授权，或通过安全地针对发起请求的用户对提供者中的操作进行审核来确保可靠性。

• 按请求应用程序进行信任身份验证

  和端到端信任类似，此模型假定请求应用程序是已知的受信任软件。不过，在本模型中，仅信任应用程序执行身份验证和将最终用户标识断言到 ESB，然后由后者授权访问并将最终用户标识断言到提供者。在此模型中，ESB 和提供者服务之间的信任与前面 ESB 执行身份验证时的情况一样。

  此模型支持用户单点登录到受信任应用程序，由后者以用户的身份进行服务请求。标识断言可能简单地采用用户名令牌，也可能涉及到请求应用程序代表用户获取令牌，并在后续操作中由 ESB 对此类令牌进行验证。

• 端到端身份验证，需要机密性和完整性

  此模型假定提供者服务只获得了 ESB 的有限信任，需要提供凭据，以允许提供者直接对请求发出者进行身份验证。在此模型中，还可能需要保密性和完整性。

  这不是假定 ESB 中没有信任关系的模型，ESB 几乎肯定被信任，可根据预期的服务级别协议将请求交付到相应的提供者，并充当尝试访问此类敏感信息时的第一个筛选器。不过，会使用其他级别的端到端安全性（如数字签名）来标识发起请求的用户，以实现不可否认性，而端到端加密可用于防止操作人员访问高度敏感的信息。在正常处理期间出现异常，或在 ESB 中执行审核/日志记录时就可能出现操作人员访问高度敏感信息的情况。

• 发布/订阅

  尽管发布/订阅模型仍然具有相同的主要参与方，但安全性模型不同，其中有两个级别的安全性：

  • 对功能访问的控制
  • 对主题访问的控制

  针对发布者和订阅的功能访问的控制与任何对 ESB 请求的控制相同。从理论上而言，这可以使用可用于通用 SOA 交互的任何机制，这些控制将得到一个用户名，此用户名可随后用于进行更为细粒度的访问控制。

  对主题访问的控制将通常由发布引擎基于主题层次结构中的访问控制列表进行管理。

总结

我们介绍并描述了使用 IBM 企业服务总线产品构建的企业连接性解决方案中常见的一组模式。这些模式和其他相关模式将在相关的 developerWorks wiki 中进行更为详细的介绍，并会提供具体的实现说明和示例。

致谢

本文所述的理念源自与很多人的讨论，不过我们要特别感谢 Rob Phippen、Kim Clark 和 Greg Flurry 对本文的初稿提出了非常有帮助的反馈和建议。

参考资料

• 访问 ESB and Connectivity Patterns developerWorks wiki，了解关于这些主题的更多细节
• Gregor Hohpe 和 Bobby Woolf 撰写的企业集成模式（Addison Wesley ISBN 0321200683；2003 年 10 月）提供了模式目录和大量实际解决方案，充分展示了消息传递的强大功能，能帮助您为企业设计出有效的消息传递解决方案。
• IBM 提供了各种有关 ESB 设计模式的资料。有关此主题的更多信息，请参见以下参考资料：
  • 来自 IBM Systems Journal 的“The Enterprise Service Bus: Making service-oriented architecture real”（2005 年 12 月）。
  • “用于实现 Web 服务的 SOA 编程模型，第 4 部分: IBM 企业服务总线介绍”（developerWorks，2005 年 7 月）。
  • “理解面向服务的体系结构中企业服务总线场景和解决方案，第 1 部分：企业服务总线中的工作角色”（developerWorks，2004 年 7 月）。
  • “使用企业服务总线简化集成体系结构”（developerWorks，2005 年 11 月）。
  • “开发人员为何需要企业服务总线？”（developerWorks，2005 年 11 月）。
  • “探索企业服务总线，第 1 部分: 了解 ESB 如何帮助您满足 SOA 解决方案的需求”（developerWorks，2008 年 4 月）。
  • “探索企业服务总线，第 2 部分: 为什么 ESB 是 SOA 的基本组成部分”（developerWorks，2008 年 4 月）
• 浏览技术书店，以了解有关这些技术主题及其他技术主题的相关书籍。

• 下载 IBM 产品评估版，获得来自 DB2®、Lotus®、Rational®、Tivoli® 和 WebSphere® 的应用程序开发工具和中间件产品。

• 参与论坛讨论。
• 访问 developerWorks Blog，从而加入到 developerWorks 社区中来。