本系列文章由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解决方案

　　针对该客户需求，我们给出的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应用，用于将各种日志和错误信息存储到事件数据库中。

　　DataPower/Message Broker联邦ESB的关键服务组件设计

　　下面我们来介绍在这个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部署的方案设计和技术实现。

　　关于作者

　　娄丽军，IBM软件部软件架构技术支持，曾参与交通运输、电信等行业多个SOA软件项目的设计和实施。