实际业务场景用 IBM ESB 产品的实现

实际业务场景用 IBM ESB 产品的实现
通用业务场景
业务场景：（虚拟场景）A 银行最近和 B 银行及 C 银行形成合作关系，合作合同的一项指出，在其中任何一个银行有存款的用户，可以在其他任意两家银行用该存款作为贷款担保来获得一定倍数数量的贷款。如，若某人张三在 A 银行有 1 万元的存款，则该用户可以用这 1 万元的存款作为担保在 B，C 银行取得 10 倍于 1 万元（10 万元）的贷款。A 需要创新的解决方案，使得这项新的协议在 IT 系统中实现，并服务于他们的客户。如果用户在 B 和 C 之一具有一定的存款，则 A 的解决方案将自动从 B 和 C 取得该客户的存款额，并将该存款额应用到贷款流程中。（在本场景中，为了介绍 ESB 的连接性，我们将问题简单化，并没有考虑以下可能的情况：某客户分别在 B 和 C 都有一定存款，需要用 B 和 C 的存款之和在 A 进行贷款担保的情况。当然这种情况属于业务逻辑，应该在 A 的贷款流程中实现）
A 银行决定使用 SOA 来个构建这一新的解决方案，利用 IBM SOA Foundation 来构建体系结构模型，用 IBM ESB 作企业服务总线，统一进行服务的注册，查找，路由等，并在 ESB 上运行其他应用程序。前提条件：B 银行和 C 银行都已经向 A 公司提供了各自的获取某用户存款在本公司存款的服务，而且已经定义了良好的接口。
注：在这篇文章中，我们旨在介绍 IBM 几款 ESB 产品的各自特点，而不介绍开发细节。所以我们花更多笔墨来展示实现过程的一些重要特点，而不去详细介绍实现上述场景的整个过程。
使用 WESB 实现场景
场景描述：
B、C 银行提供的查询客户存款的服务已通过 Web Service 方式实现；
并发的请求不会很多；
A 银行的整合中多个应用都会使用到 B、C 银行提供的查询客户存款的服务。
我们希望通过 ESB 向整合环境提供统一的、可复用的查询客户存款的服务，该服务自动根据客户的来源，动态路由到 B、C 提供的客户存款的服务。
下面我们选择 WESB 作为该场景的 ESB 实现。
下表描述了 B，C 现有服务定义。
服务来源 接口 操作 输入 输出
B 银行 BDepositService queryDeposit Customer DepositInfo
C 银行 CDepositService cxDeposit Client ClientDeposit
在上面的表格中，我们尽量模拟两个银行提供的数据接口和数据格式是不一样的，因为这样更加符合现实的情况。
场景实现：
第一步：
如图 1 所示在 WID（集成开发环境中）将服务的提供者（B 银行 C 银行）引用到开发环境中，每一个服务对应于一个 SCA Import，根据不同的服务提供者选择不同的绑定（Binding）这里由于服务都已 Web Service 方式提供，所以选用 Web Service 绑定。

第二步：
通过一个 Mediation 模块来处理服务的路由，消息格式转换等。
第三步：
将新的统一服务通过 Web Service 的方式 Export 出去，所以使用该 Web Service 的应用都通过该 Export 调用。
图 1. WESB 上开发的三个步骤
WESB 上开发的三个步骤
在以上三个步骤中，Mediation 模块是核心 ESB 模块，图 2 和图 3 是针对以上应用场景开发的 Mediation 逻辑。
图 2. WESB Mediation 模块的请求消息流
WESB Mediation 模块的请求消息流
图 3. WESB Mediation 模块的响应消息流
WESB Mediation 模块的响应消息流
从上述简要的开发过程来看，我们将来自不同服务提供者的两个服务注册在 WESB 上；由 WESB 提供一个统一的服务；今后，服务请求者不需要去关心具体应该调用由哪个后台服务；整个开发过程不需要写一行代码。
此外，WESB 基于 WAS J2EE 容器之上，对安全事务处理等方面都有很好的支持，同时 WESB 遵循标准的 SCA/SDO 的规范，使得我们开发的组件可以很容易的和其他应用集成。
使用 WMB 实现场景
场景描述：
B 银行提供的服务由 Web Service 的方式实现，C 银行提供的服务由 FTP 方式实现，只要把消息放到 C 银行指定的 FTP Server 即可 , 数据格式由 C 银行指定
对 B.C 服务性能要求较高，需要每秒钟能同时处理 1000 到 10，000 条消息
B 银行和 C 银行都支持通过 MQ 的方式对其提供的服务进行访问
利用 ESB 构建一个统一的查询客户存款服务的，该服务通过查询不同的客户来源，动态路由到不同的服务提供银行
场景实现：
第一步：将开发好的 BBank 提供的 WSDL 导入 WMB 中，我们在 SOAPRequest 节点中可以利用该 WSDL 文件提供对 BBank 的访问。CBank 提供的是某个 FTP 服务，MB 中提供的 FileOutput 节点可以实现对 FTP 的访问。
第二步：利用 WMB 提供的 Route 节点实现对消息的路由，Route 节点是 MB6.1 的一个新 feature，开发起来和 WESB 中的 Route 节点非常类似。之前的 WMB 版本一般利用 Filter 节点来实现类似的路由功能。
第三步：提供一个 MQ Input 节点给 A 客户，A 客户可以通过该 MQ 节点发送消息，从而访问 BBank 和 CBank 提供的服务。
第四步：由于 A 银行支持对 MQ 的访问，故 B，C 银行的返回结果都存放在 MQ 中，A 银行只要访问相应的队列就可以取回结果。本例不介绍 A 银行应用系统对 MQ 的访问
图 4. 使用 Message Broker 开发 Mediation 消息流
使用 Message Broker 开发 Mediation 消息流
如图 4 所示，我们在 BBank Compute 节点和 MappingToCBank mapping 节点中分别采用了 ESQL 和 mapping 节点实现消息格式的转换。WMB 提供了非常强大的消息 mapping 功能，在已知映射双方消息格式的情况下，我们可以直接利用 mapping 节点进行消息映射。在 BBank 中我们也利用了 WMB 特有的 ESQL 实现到 SOAP 消息的映射。
在 CBank Compute 节点中我们对存放在 FTP 中的文件名进行了动态赋值，其文件名字根据消息中唯一的 ID 信息来标识。
图 5 是 Route 节点的主要信息，非常简单，根据消息中的 Bank 的字段路由到不同的服务：
图 5. Router 规则表
Router 规则表
总的来说，WMB 提供了更为丰富的内置节点，支持不同协议间的转换，在本例中我们采用 FTP 作为演示，WMB 还支持 JMS、HTTP、TCP/IP 等其他常用协议。由于和 MQ 天然的内在联系，支持 MQ 访问的应用系统使用 WMB 作为 ESB 将非常自然，和 WESB 相比，WMB 不仅提供了的丰富的消息处理机制，在性能方面也更为优越。
使用 Datapower 实现场景
场景描述：
在该场景中，服务的注册，路由等功能和前面描述的 WESB 相似，除此之外，还需要以下安全方面的支持：
B,C 提供的服务在服务端已经实现了服务端的安全机制，请求者只有满足相应的机制才能请求服务。
要求服务的请求和返回在安全的传输层（SSL）之上传输。
返回的消息是加密的，需要请求者解密消息。
请求的消息要数字签名，保证消息在请求过程中未被修改。
防范 XML 攻击（XML 攻击的介绍参见参考文献部分）
以上这些安全方面的要求在 WESB 中完全可以实现，但是对安全性的增加会导致：1）开发的复杂度；2）系统性能的大幅下降。
在这样的高安全要求应用场景下，用 Datapower 来做 ESB 则成为最佳选择。在有的情况下 Datapower 会和 WESB 或者 Message Broker 联合起来使用，参考联合使用章节。这里我们单独介绍 Datapower 单独做 ESB 时所能提供的功能。
场景实现：
在 Datapower 下实现该场景的过程中，我们分两个步骤来实现
第一步：实现基本的 ESB 服务注册、路由、消息转换等功能。
第二部：在此基础之上，我们再增加对安全方面的支持，下面我们来看看在 Datapower 上增加安全是如何的便捷及高效。
实现第一步，我们通过两个 XML Firewall 来封装 B，C 银行提供的服务，图 6 是对 B 服务建立 Firewall 的开发配置界面：
图 6. 封装 B 服务的 Firewall 开发配置界面
封装 B 服务的 Firewall 开发配置界面
建立好两个 Firewall 后，我们现在来建立一个新的 Firewall 来实现 ESB 中的路由和消息转换，如图 7：
图 7. ESB 路由 Firewall
ESB 路由 Firewall
Policy 的定义如图 8：
图 8. Policy 定义
Policy 定义
我们需要配置请求消息流和返回消息流中的各个节点来完成 ESB 的功能。转换节点中，我们开发 XSL 来进行格式转换；在路由节点中，我们要定义路由表，如图 9 所示，
图 9. 路由规则表
路由规则表
下面，我们对上述 ESB 消息流增加安全方面的支持。假定 Datapower 使用在 A 银行的内部网中，那么我们只需要在和 B，C 银行之间的传输中增加安全支持，如图 10 所示。
图 10. 实现场景图中的安全需求
实现场景图中的安全需求
加入 SSL
SSL 在 Datapower 中是一个独立开发的对象，我们开发好 SSL 的对象后，我们只需要在 XML Firewall 的配置界面上选择该对象即可，如图 11：
图 11. 在 Firewall 中增加 SSL
在 Firewall 中增加 SSL
签名和确认
B 银行要求传过去的请求消息是带有数字签名，我们需要在 B FirewallService 中加入 Sign（签名）节点来支持此项功能，如图 12 所示：
图 12. 消息流中增加签名
消息流中增加签名
加密解密
B 银行返回消息是加密的，我们需要在 B FirewallService 的 Firewall Policy 中加入 Decrypt（解密）的节点，如图 13 所示。
图 13. 消息流中增加解密节点
消息流中增加解密节点
上面几张图中我们介绍了如何对 B 提供的服务增加安全支持，对 C 的服务业一样处理。至此，我们方便得在 Datapower 和 B,C 银行之间提供安全的服务请求，通过配置的方式即可完成安全的支持，节省了很大的开发成本，此外，Datapower 对 XML 的处理速度达到线速，有兴趣的读者可以参考相关文献。
回页首
ESB 产品的联合应用的场景介绍
三款产品并不是独立使用的，在某些环境下可能需要三款产品的联合使用
WESB 和 WMB 联合使用
在图 14 的场景中，某跨国公司在世界各地都有分公司，由于时区的原因，每天的信息需要通过异步的方式统一到总公司，由于总公司的业务量大，我们可以使用 WMB 做总公司的 ESB，而在分支机构，业务量小，且都是 J2EE 和 Web Service 的应用，我们可以使用 WESB 作为分公司的 ESB。
图 14. WMB 和 WESB 联合使用的场景
WMB 和 WESB 联合使用的场景
Datapower 和 WESB 联合使用
如图 15 所示，我们可以在 WPS 上实现负责的业务流程，在企业内部使用 WESB 作为 ESB。在该场景中 WESB 只负责服务的注册、路由和查找功能，而安全方面的处理，以及部分消息格式转换的功能由 Datapower 处理（外部传来的非 XML 格式的数据通过 Datapower 处理成 XML 格式的数据），该场景既利用到 Datapower 在安全和 XML 处理方面的优势，有利用到 WESB 和 WPS 集成的优势。
图 15. Datapower 和 WESB 联合使用的场景
Datapower 和 WESB 联合使用的场景
Datapower 和 WMB 联合使用
如图 16 所示，Datapower 可以和 WMB 配合使用。WMB 提供了多种多样的消息协议和格式的支持，比如遗留的 EIS 系统，SAP、PeopleSoft 等，也可以充分利用 WMB 的扩展性自定义消息集或者消息节点，以此来满足特殊的应用需求。Datapower 可以提供高性能的 Web Service 安全网关。客户端通过 SOAP over HTTP 可以访问到 Datapower，而 Datapower 用过 MQ 访问 WMB。该场景兼顾了 Datapower 在性能上强大的优势和 WMB 丰富的消息协议与格式支持。
图 16. Datapower 和 WMB 联合使用的场景
Datapower 和 WMB 联合使用的场景
回页首
结束语
在和客户以及合作伙伴交流的过程中，我们经常会被问到 IBM 的三款 ESB 产品的差别以及如何选择合适的 ESB 产品。在这篇文章中，我们分成两个部分介绍了 ESB 以及 IBM 的三款 ESB 产品的各自特点和适用的场景，并通过一个实际案例基于三款产品的实现来描述其开发部署的差异。至此，希望能帮助读者在选择正确 ESB 产品时起到一定的作用。