本系列文章由 3 部分组成，在前 2 部分当中，介绍了两个企业ESB 解决方案的设计案例，这两个案例分别来自于交通运输行业和制造行业，我们针对不同行业的业务和应用特点设计了不同的
ESB 解决方案。第 3 部分内容我们介绍了 ESB 项目实施的一些方法论和经验。
我们知道企业 ESB 实施的模式大致分为 Global ESB、ESB Gateway、Federated
ESB、Brokered ESB 等若干种，IBM 的 ESB 产品主要包括 WebSphere Message
Broker、WebSpehere ESB、WebSphere DataPower 三种，并且在特定的用户需求下，我们需要将这三种产品组合使用，在本系列文章的第
2 部分，我们再为大家介绍一个制造业企业使用 WebSphere DataPower 和 WebSphere
Message Broker 作为企业级联邦 ESB 平台的案例和技术实现。
图 1. 系统交互图
图 1 给出了某制造行业客户现有各个系统间的系统交互图 (System Context Diagram)，通过系统交互图，我们可以清晰地了解到
ESB 平台和周边涉及到的系统之间交互的通信协议类型以及数据接口格式。从上图 1 中我们可以看出，其合作伙伴以多种方式调用该企业内部的后台服务，包括标准的
SOAP/HTTP 方式、XML/MQ 的方式、EDI/MQ 的方式甚至 FTP 的方式等；该企业内部的一个主要核心业务系统运行在
IBM 大型主机上，对外的接口方式采用 WebSphere MQ，数据格式采用传统的 COBOL CopyBook
的方式，除了该主机系统之外，该企业的其他一些内部应用会以 SOAP/HTTP 和 XML/MQ 的方式与外界交互。
针对该客户需求，我们给出的 DataPower 和 Message Broker 联邦 ESB 解决方案架构如下图
2 所示：
图 2. 联邦 ESB
解决方案
在这个解决方案中，我们使用的 IBM 产品主要包括 Data Power XI50 和 WebSphere
Message Broker V6.0.2，DB2 V9 以及 WebSphere Application
Server V6.1。其中，WebSphere DataPower XI50 是一个实现 ESB 的硬件解决方案，它的主要功能包括：
- XML 高速转换引擎；
- 基于消息内容的路由；
- 协议桥接 : HTTP, MQ, JMS, FTP 等；
- XML/SOAP 防火墙：过滤任何内容、元数据和网络数据；
- 数据验证：对进出的 XML 和 SOAP 进行数据验证；
- 保护数据域级别安全：对不同的数据域可以进行 WS-Security, 加密和签名；
- 访问控制：验证、授权和审计 (AAA)，支持 SAML, LDAP, RADIUS 等；
- Web Services 管理：中心服务级别管理、服务虚拟化和策略管理等。
该客户的联邦 ESB 解决方案由下列组件构成：
Gateway DataPower：
在 DataPower 和 Message Broker 组合 ESB( 以下简称 DP/MB 组合
ESB) 方案中，常见的产品分工定位方法是：由 DataPower 作为企业对外的 ESB 入口，即担任
B2B 网关的角色，侧重提供其它企业的接入服务以及安全控制方面的工作；而采用 Message Broker
作为企业内部的 ESB 总线，实现企业内部各种应用系统，包括传统应用系统之间的集成平台。
在我们给出的这个实际案例中，采用了两台 DataPower，其中 Gateway DataPower
主要负责外围的接入，接入的通信协议包括 MQ，HTTP(S)，JMS，FTP 四种。Gateway DataPower
位于网络架构中的 DMZ 区，它负责 XML threat protection，信息属性传递 ( 例如
IP 地址的传递 ) 和 SSL 传输层安全控制。
ESB DataPower：
这台设备位于网络架构中的受信区，对输入的消息进行更进一步的处理，其中包括：
1. 校验 Inbound/Outbound XML 类型消息的 Schema；
2. 实现非 MQ 通信协议和 MQ 通信协议之间的转换，在我们的设计中，我们在 ESB DataPower
和 ESB WMB 之间采用 MQ 的通讯协议，因此在 ESB DataPower 上我们要将所有的协议转换为
MQ；
3. 信息头的处理：在此我们将创建我们为应用设定的消息头并且插入到接收到的数据包头或 SOAP 头中。
4. 认证 / 授权：通过 LDAP 进行发送者的认证和授权；
5. 日志：为了审计目的，通过日志服务 (Logging Service) 组件对输入信息进行日志处理。
ESB Message Broker：
由于我们的后台核心系统是位于 IBM 大型主机上的应用系统，需要的数据格式是 COBOL Copybook
的格式，因此在 Message Broker 上我们将实现 XML 到 Copybook 的转换。在 Message
Broker 上，我们设计了 3 种典型的 Message Flow，
1. OnBoard Flow: 通过查询数据库设置消息的环境树 (Environment Tree)，把输入消息转换为标准的
XML 格式；
2. Main Application Flow：用于应用逻辑处理；
3. OffBoard Flow: 依据消息的 Environment Tree，将消息路由到特定的
Service Endpoint（服务端点），并且将数据转换为后台系统需要的格式。
Application Server 组件：
该组件接收和响应 Web Services 请求，并且 Logging 组件也运行在该组件上。
后台主机系统：
负责后台的业务逻辑处理。
LDAP 组件：
存储认证/授权相关的信息。
Routing Database（路由表）：
路由表中存储了服务路由信息、服务版本信息等，其中包含了特定于应用程序的配置信息，通过 Java API
对其进行访问来决定服务的路由和绑定。
Event Database/ Event Logger（事件数据库/事件日志处理器）：
Event Database（事件数据库）中存储了各种日志和错误信息，Event Logger（事件日志处理器）是一个
Java 应用，用于将各种日志和错误信息存储到事件数据库中。
下面我们来介绍在这个 DP/MB 联邦 ESB 方案中的关键服务组件设计。如下图 3 是 ESB 服务组件图：
图 3. 联邦 ESB
服务组件图
从服务的角度，联邦 ESB 主要由以下服务组件构成：
1. Gateway Services（网关服务）
2. Schema Validation Services（模式校验服务）
3. Security Services（安全服务）
4. Routing Services（路由服务）
5. Transformation Services（转换服务）
6. Logging, Error Handling and Notification Services（日志服务）
下面我们分别介绍这些服务的设计和实现方式。
Gateway
Services（网关服务）
这个组件的所有功能都是通过对 DataPower 的配置实现的。它是 Internet 和 Intranet
之间的一个网关，从 ESB 的角度，它就像第一道防火墙，起到对企业外部服务调用的安全控制和协议转换的作用。同时，它根据来源数据的格式，例如
SOAP，XML，文本或 CopyBook 等，进行粗粒度的路由。
Schema Validation Services（模式校验服务）
这个组件的所有功能也都是通过对 DataPower 的配置实现的，开发者可以在部署时，在 DataPower
设备上配置有关的 Schema，对 XML Schema 的高速校验是 DataPower 的一个非常重要的功能。需要注意的是，在我们的案例中，我们的联邦
ESB 除了 XML 格式之外，还必须支持 Copybook 的主机格式，这是 DataPower 不擅长的，对这种格式的解析，我们将交给后面的
Message Broker 来实现，这正是体现了在这个联邦 ESB 解决方案中 DataPower 与
Message Broker 的各自定位以及无缝配合。图 4 描述了模式校验服务的序列图：
图 4. 模式校验服务序列图
模式验证服务主要由 ESB DataPower 实现，它负责对 SOAP/XML 消息模式的校验，如果失败，则调用日志服务进行错误处理。
1. 服务请求者通过 HTTPS 经由 Gateway DataPower 向 ESB DataPower
发送 SOAP/XML 消息；
2. ESB DataPower 对该消息进行校验；
3. 如果校验失败，Logging Service（日志服务）组件将向数据库写入日志信息，向服务请求者返回“Schema
Validation Error”；
4. 如果校验成功，将继续安全校验等其它操作。
Security
Services（安全服务）
安全服务将负责认证、授权和审计 (3A)。所有这些功能也都是通过对 DataPower 的配置实现的，在该方案中，我们采用
SSL 作为传输级安全控制，对于 MQ 的消息我们使用 MQRFH2 消息头来实现消息级安全控制，对于
SOAP 消息我们采用 WS-Security 标准来进行安全控制，如图 5 所示。
图 5.
SOAP/XML 消息认证授权序列图
本序列图描述了对输入消息的认证授权处理，其步骤如下：
1. 服务请求者经由 Gateway DataPower 向 ESB DataPower 发送 SOAP
或 XML 消息，消息中包含了 WS-Security 头信息，其中包括 Username Token
and Password；
2. ESB DataPower 接收到消息，它调用 LDAP API 对从 SOAP 消息头或者 MQ
消息头中取得的发送者凭证进行认证；
3. 如果认证失败，日志服务组件将记录失败的日志信息；
4. 如果认证成功，ESB DataPower 将通过访问 LDAP 进行粗粒度的授权，决定发送者是否有权限进行服务调用；如果失败，也记录日志信息；
5. 如果认证 / 授权都成功，则消息将被发送到 Message Broker 上进行后续处理，并且记录审计信息。
Routing
Services（路由服务）
整个系统的路由服务将分为两层，第一层是介于 ESB DataPower 和 ESB Message Broker
之间，第二层是在 Message Broker 内部。
第一层的路由是一层粒度较粗的路由，我们使用请求者的 URI 来决定其调用的服务名称，然后我们将服务名称和
MQ 队列的名称一一对应，这样我们就把请求数据路由到后面的 Message Broker 上对应的队列中了，当然这是一种简单的处理方式，从理想的角度而言，我们可以使用
WebSphere Service Registry&Repository 这样的服务目录和注册库产品来实现。
第二层路由将由 Message Broker 来实现，它通过访问路由表 (Routing DataBase)
来获取路由信息，如图 6 所示。
图 6. 路由服务序列图
该序列图描述了由 Data Power 和 Message Broker 共同实现的路由服务功能：
1. 服务请求者通过 Gateway DataPower 向 ESB DataPower 发送消息；
2. ESB DataPower 从 URI 中获得服务名称，然后消息被转发到 Message Broker
上；
3. WMB OnBoard Flow 根据服务名称查询路由数据库获得路由信息；路由信息被存储到 Message
Broker 消息的全局 EnvironmentTree 中；然后 Application Flow 对消息进行处理；最后由
Message Broker OffBoard Flow 将消息路由到目的服务提供者。
Transformation Services（转换服务）
转换服务由 DataPower 和 Message Broker 分别完成，其中 DataPower
实现 XML 到 XML 的转换，Message Broker 实现 XML 和非 XML，如 XML
与 COBOL Copybook 之间的转换。
Logging
Services（日志服务）
日志服务由 3 个组件构成，分别是 Event Logger（日志处理器）, Event DB（日志数据库）以及
Log Viewer（日志查看器）。日志处理器是一个 J2EE 应用，它通过 Message Driven
Bean 读取 Log Queue（日志队列），然后将日志信息写入日志数据库。日志查看器是一个 GUI
应用，用来查看日志信息。从方案设计的角度，整个系统应该采用一致的日志和错误处理策略，在此我们仅列举 Data
Power 的日志设计作为参考，其他的日志设计雷同。
图 7. 日志服务序列图
图 7 描述了 DataPower 的日志处理逻辑：
1. 当 DataPower 发生异常时，发送错误日志信息到消息队列，消息类型为永久性消息；
2. Event Logger 从队列中接收到错误消息，并将其记录数据库 Event DB；
3. 若入库失败，则将消息回滚。
本文介绍了一个制造业企业使用 WebSphere DataPower 和 WebSphere Message
Broker 作为企业级联邦 ESB 平台的案例，以此介绍了在此类联邦 ESB 项目中 DataPower
和 Message Broker 如何协同工作，并介绍了这种复杂的 ESB 部署的方案设计和技术实现。
学习
获得产品和技术
| 
