级别: 中级 李传峰 , IBM中国软件研发实验室SOA设计中心工程师
2005 年 12 月 29 日 概述 WebSphere V6中增加了一个新的特性：服务集成总线（Service Integration Bus，SIBus），基于服务集成总线可以灵活实现ESB（Enterprise Service Bus），为SOA搭建良好的基础架构。SIBus基于成熟的企业应用平台WebSphere Application Server，充分利用WebSphere上灵活的消息机制，可以适应各种用户需求，甚至对于同一个服务集成需求，也会有多种不同的实现方式。 本文针对ESB的路由模式（Routing Pattern），阐述SIBus上各种不同的实现方式及相互间的比较。
ESB路由模式
图 1：ESB 路由模式
路由模式是ESB的一种基本模式，将服务申请者（Service Requester）的请求按照一定的路由规则（Routing Rules）发送到相应的服务提供者（Service Provider）。ESB路由模式的应用范围很广，比如，每个库房存放不同种类的货物，并且每个库房有自己的库存管理系统（服务提供者），对于一个库存数量查询请求，需要按照待查询货物的类型路由到相应库房的库存管理系统查询库存数量。
在SIBus上实现 ESB 路由模式 SIBus上可以有多种方式实现ESB路由模式，接下来我们将按照是否需要服务整合以及实现路由选择的位置不同，分成四种实现方式来依次阐述。 所谓服务整合，就是将多个服务提供者整合成为一个新的服务提供者，多个WSDL文件整合成为一个，整合后服务提供者的端口类型（Port Type）是整合前各服务提供者端口类型的并集。对于提供类似服务的多个服务提供者，将它们整合成为单一的服务提供者，可以有效减少服务提供者的数量，不过，整合的过程通常不能做到自动化，需要大量的手工配置。
经过服务整合，在服务目标（Service Destination）实现路由选择
图 2：服务整合后，在服务目标实现路由选择
一般来说，采用ESB路由模式集成的服务提供者具备类似的功能，只是接口形式不同。比如，各个库存管理系统都支持查询库存数量的服务，其中有些库房管理系统支持Web Service格式的查询接口，有些只支持基于RMI-IIOP协议的接口。 对于服务申请者而言，只关心一个抽象的服务，并不关心支撑这个抽象服务的具体的服务提供者。比如，查询库存数量的用户，只关心是否能够查询到准确的库存数量，不关心这个数量具体是从哪个库存管理系统中查询出来的。 因此，可以将多个服务提供者整合到SIBus的一个出站服务（Outbound Service）之中，其中的服务目标（Service Destination）对应抽象服务，而每个端口目标（Port Destination）对应一个服务提供者。SIBus中的入站服务（Inbound Service）和出站服务（Outbound Service）以服务目标（Service Destination）作为联系枢纽，服务申请首先到达服务目标，从服务目标再经端口目标到达最终的服务提供者。 这种实现方式的概念清晰，结构简单，只需要一个服务目标。不过，还需要为出站服务手工整合各个服务提供者的WSDL文件，存在一定的实施难度；而且，在整合出站服务WSDL文件时，如果各个服务提供者WSDL文件存在Operation重名现象，就会造成整合后的WSDL文件中出现函数重载，在实际生产环境中，函数重载是要尽量避免的。
未经服务整合，在队列目标（Queue Destination）实现路由选择
图 3：未经服务整合，在队列目标实现路由选择
在相应的SIBus上，创建一个新的队列目标（Queue Destination），在该队列目标上接收入站服务（Inbound Service）的服务申请。同时，为多个服务提供者各自创建出站服务（Outbound Service），每个出站服务包含一个服务目标（Service Destination）和一个端口目标（Port Destination）。 入站服务和出站服务的目标（Destination）之间，可以互通消息。在队列目标上实现路由选择，直接将消息转发给相应的端口目标，不再经过服务目标。 采取这种实现方式无需手工整合各个服务提供者的WSDL文件，配置相对比较简单，只是增加了SIBus上需要管理的出站服务和服务目标的数量。不过，另一方面，由于SIBus只能允许通过JAX-RPC直接访问服务目标，不允许直接访问队列目标和端口目标，因此，这种实现方式下，服务申请者不能直接快速的访问SIBus，只能通过入站服务访问SIBus，从某种意义上降低了性能。
未经服务整合，在服务目标（Service Destination）实现路由选择
图 4：未经服务整合，在服务目标实现路由选择
这种实现方式与第二种方式比较类似，只是无需创建队列目标（Queue Destination），消息直接到达其中一个出站服务（Outbound Service）的服务目标（Service Destination），在其上实现路由选择，决定消息路由到该出站服务的端口目标（Port Destination）还是到其它出站服务的端口目标上。 这种方式从多个出站服务的服务目标中选择一个作为路由选择点；如果多个出站服务之间的关系是对等的，那么这种实现方式概念上不如第二种方式清晰，如果多个出站服务的关系不是对等的，则可以其中最常用的出站服务为主，其它出站服务为辅，以主出站服务的服务目标作为路由选择点，对外抽象服务的接口格式也尽量接近主出站服务，概念比较清晰。 另外，由于可以通过服务目标直接访问SIBus，相对于第二种实现方式，这种方式可以通过JAX-RPC直接访问SIBus上的服务目标，获取对SIBus的访问，性能较高。
未经服务整合，在端口目标（Port Destination）实现路由选择
图 5：未经服务整合，在端口目标实现路由选择
这是最直接的一种实现方式，无需创建队列目标（Queue Destination），绕过了服务目标（Service Destination），消息直接到达端口目标（Port Destination），在端口目标上实现路由选择。 这种实现方式在SIBus内部的最短路径只需要经过一个目标（Detination），通信的开销较少。 作为与最终服务提供者的接口，端口目标一般承担协议格式和消息内容转换的工作，很少作为路由选择点；这种实现方式的概念不够清晰。不过，对于性能要求非常苛刻的场合，也不失为一种可能的选择。
各种路由选择实现方式的比较
相关问题 - 无论在什么位置实现路由选择，都需要在相应位置的目标（Destination）上增加消息中介（Mediation），该消息中介改变服务申请消息的前进路径，进而实现路由选择的功能。关于路由选择消息中介，IBM developerWorks很多文章中都有详细介绍，本文不再具体阐述，仅列出一个基本的代码实现片断，方便用户参考。
- 无论哪一种实现方式，消息都需要从SIBus的端口目标（Port Destination）发出到达最终的服务提供者，端口目标是SIBus与最终服务提供者的接口。
- 如果多个服务提供者接口的方法名称或参数格式不同，还需要在相应的端口目标（Port Destination）上增加专门用于消息格式转换的中介（Mediation），这属于ESB的另外一种模式（转换模式，Transform Pattern）的内容，本文中不再具体介绍。
总结 SIBus提供了非常灵活的机制，可以有多种方式实现ESB的路由模式，每种实现方法有其长处和不足，也有各自的应用范围，读者可以从中选择最适合的一种实现方法。
代码下载 以下的样例代码演示了一个路由选择消息中介将第奇数个服务申请路由到第一个服务提供者，第偶数个服务申请路由到第二个服务提供者。 基本代码实现片断：SelectorMediation.java
参考资料 - 企业服务总线解决方案剖析，第 2 部分: 利用 WebSphere 6 中的 SIBus 实现 ESB
- 用于实现 Web 服务的 SOA 编程模型，第 4 部分: IBM 企业服务总线介绍 定义了ESB 模式和它在 SOA 内的角色
- Patterns: Implementing an SOA Using an Enterprise Service Bus，IBM 红皮书详细介绍了如何使用企业服务总线来实现SOA。
关于作者
| 
