在本文的第1部分中，我们介绍了企业级应用的发展过程，ESB的特性以及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现有服务定义。

　　在上面的表格中，我们尽量模拟两个银行提供的数据接口和数据格式是不一样的，因为这样更加符合现实的情况。

　　场景实现：

　　第一步：

　　如图1所示在WID（集成开发环境中）将服务的提供者（B银行C银行）引用到开发环境中，每一个服务对应于一个SCA Import，根据不同的服务提供者选择不同的绑定（Binding）这里由于服务都已Web Service方式提供，所以选用Web Service绑定。

　　第二步：

　　通过一个Mediation模块来处理服务的路由，消息格式转换等。

　　第三步：

　　将新的统一服务通过Web Service的方式Export出去，所以使用该Web Service的应用都通过该Export调用。

　　图1. WESB上开发的三个步骤
 
　　在以上三个步骤中，Mediation模块是核心ESB模块，图2和图3是针对以上应用场景开发的Mediation逻辑。

　　图2. WESB Mediation模块的请求消息流

 
　　图3. 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消息流
 
　　如图4所示，我们在BBank Compute节点和MappingToCBank mapping节点中分别采用了ESQL和mapping节点实现消息格式的转换。WMB提供了非常强大的消息mapping功能，在已知映射双方消息格式的情况下，我们可以直接利用mapping节点进行消息映射。在BBank中我们也利用了WMB特有的ESQL实现到SOAP消息的映射。

　　在CBank Compute节点中我们对存放在FTP中的文件名进行了动态赋值，其文件名字根据消息中唯一的ID信息来标识。

　　图5是Route节点的主要信息，非常简单，根据消息中的Bank的字段路由到不同的服务：

　　图5. 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开发配置界面