ASP.NET企业服务总线实现模式

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，此产品可提供非常高的性能。

IBM ESB 产品

很多产品都可以用于创建企业服务总线（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 MQ 为多种不同平台提供可靠消息。很多公司都使用 WebSphere MQ 作为消息传递中枢。

WebSphere Service Registry and Repository 提供了集成的服务元数据存储库来治理服务和管理服务生命周期。它可促进服务可见性、一致性，还将减少 SOA 中的服务冗余。

WebSphere Transformation Extender 提供了通用转换功能，非常适合满足极为复杂的需求或快速变化的需求，如 EDI 等。

WebSphere Adapters 是外接程序，可帮助为打包应用程序或其他遗留资产启用服务，以便参与到 SOA 中来。其中提供的适配器允许将各种遗留信息系统和技术包含到 ESB 中来。

WebSphere Process Server 提供流程工作流功能，并包括 WebSphere ESB。有些情况需要对来自很多个系统的服务调用和响应进行协调，而此解决方案提供了在此情况下编排复杂 ESB 交互的功能。

IBM Tivoli Composite Application Management for SOA 是专门针对 SOA 环境的 Tivoli 监视产品。通过 IBM Tivoli Composite Application Manager for SOA，可充分利用现有系统管理工具，提供了 SOA 环境的全面操作视图。

WebSphere Business Services Fabric 是用于进行组合业务服务的建模、组装、部署、管理和治理的端到端 SOA 平台。WebSphere Business Services Fabric 可帮助创建业务级别的服务，以供组装为扩展的跨企业业务流程和解决方案，而且可以基于服务请求的业务上下文对这些流程和解决方案进行动态个性化和交付。

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，可以用于表述与最佳实践和所得到的经验教训相符的可重复中介模式。ESB 用例可以表示为这些核心模式的组装。

协议切换

• 支持服务请求者使用各种交互协议或 API（如 SOAP/HTTP、JMS 和 MQ Integrator (MQI)）来发送其消息。
• 将请求转换为目标服务提供者的格式。
• 可以在交互的请求者和/或提供者端或两者间的任何位置应用。
• 此模式的中介通常在格式和彼此关系有明确定义的情况下自动创建。

修饰符

 

在不更改上下文信息的情况下更新消息的有效负载

 

转换子模式
消息有效负载从一个格式（模式）转换为另一个格式，从而将请求者的消息定义与提供者的消息定义匹配
包括“封装和取消封装”，即将采用一个网络格式的消息放入另一个网络传输所需的格式信封或对应的删除信封的过程。
包括加密

 

充实子模式
通过添加来自外部数据源的信息（如中介的自定义参数或数据库查询）来更新消息有效负载

 

路由器 (Router)

更改消息的既定路由，在与中介关联的服务提供者之间进行选择
示例：从金牌客户到备用的高级 SLA 提供者间

 

发现

查询 ESB 注册中心，以发现匹配请求者需求的一组服务提供者，选择其中一个，然后将消息路由到该提供者
路由模式的增强：
可能的服务提供者集不是在中介预先配置的
提供者匹配请求者的消息格式、所需的 QOS 或从中介到可能的提供者所支持的协议
示例：数据中心故障转移场景。在不更新每个中介的配置的情况下将数据中心上线，注册服务，将通信流量路由到对应服务

 

分发

将消息分发到一组相关方，通常由订阅者的兴趣概要驱动。

 

监视

用于在消息通过 ESB 的规程中观察消息，不过不会以任何方式更改这些消息。示例：
监视服务级别
提供用于进行问题确定的数据
退款测定
记录业务级别事件（超过特定收益值的交易）
记录消息供审核

 

相关（复杂事件处理）

从消息或事件流派生复杂事件。包含模式标识规则和响应模式发现规则，例如，通过生成从触发事件流的内容派生的复杂事件。

 

可以对这些基本模式进行聚合，以得到更为复杂的模式。

规范适配器

所有各方使用的消息和业务对象集规范化为规范格式。规范适配器模式可以将端点的本机总线附加协议转换为标准协议，对有效负载进行规范化并在交付时进行反向转换。此模式是协议切换和转换模式聚合后得到的。

 

转换、记录、路由

这是一个常见的 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 设备进行实例化，因为这样可以在提