ESB企业服务总线解决方案剖析(2

其次，ESB明确强调消息(Message)处理在集成过程中的作用，这里的消息指的是应用环境中被集成对象之间的沟通。以往传统的EAI实施中碰到的最大的问题就是被集成者都有自己的方言，即各自的消息格式。作为基础架构的EAI系统，必须能够对系统范畴内的任何一种消息进行解析。传统的EAI系统中的消息处理大多是被动的，消息的处理需要各自中间件的私有方式支持，例如API的方式。因此尽管消息处理本身很重要，但消息的直接处理不会是传统EAI系统的核心。ESB系统由于集成对象统一到服务，消息在应用服务之间传递时格式是标准的，直接面向消息的处理方式成为可能。如果ESB能够在底层支持现有的各种通讯协议，那么对消息的处理就完全不考虑底层的传输细节，而直接通过消息的标准格式定义来进行。这样，在ESB中，对消息的处理就会成为ESB的核心，因为通过消息处理来集成服务是最简单可行的方式。这也是ESB中总线(Bus)功能的体现。其实，总线的概念并不新鲜，传统的EAI系统中，也曾经提出过信息总线的概念，通过某种中间件平台，如CORBA来连接企业信息孤岛，但是，ESB的概念不仅仅是提供消息交互的通道，更重要的是提供服务的智能化集成基础架构。

最后，事件驱动成为ESB的重要特征。通常服务之间传递的消息有两种形式，一种是调用(Call)， 即请求/回应方式，这是常见的同步模式。还有一种我们称之为单路消息(One-way)，它的目的往往是触发异步的事件， 发送者不需要马上得到回复。考虑到有些应用服务是长时间运行的，因此，这种异步服务之间的消息交互也是ESB必须支持的。除此之外，ESB的很多功能都可以利用这种机制来实现，例如，SOA中服务的性能监控等基础架构功能，需要通过ESB来提供数据，当服务的请求通过ESB中转的时候，ESB很容易通过事件驱动机制向SOA的基础架构服务传递信息。

ESB的适用场景及要素

首先，我们来看一看ESB有哪些基本的功能。既然ESB会以中介的身份出现，它就必须有两方面的考虑，首先它必须了解被它中介的两个端点：1)服务的请求者以及请求者对服务的要求，2)服务的提供者和它所提供服务的描述；其次，它必须具有某种机制能够完成中介的任务。我们把这两类考虑归纳为ESB的两个基本功能：面向服务的原数据(MetaData)管理功能 和中介(Mediation)功能。 作为SOA的重要构成部分，ESB承担的重任还包括怎样将企业架构中已存在的业务服务连接到总线上来，我们称之为适配器(Adapter)功能。尽管服务本身已经用公开的接口来描述，但具体的实现还是运行在不同的环境中，因此，ESB还应该提供对服务底层协议的支持，譬如应用协议J2ee，.Net， 通讯协议如Http，JMS等等。除此之外，还需要对具体应用中涉及到的服务加以管理，如性能，可靠性，安全性等等。

ESB 提供了最基本的功能来保障SOA系统的运行，这些功能应该包含下列内容：

• 在总线范畴内对服务的注册命名及寻址管理功能 - 服务的Meta-data管理
• 面向服务的中介功能
  • 提供位置透明性的服务路由和定位服务
  • 多种消息传递型式(请求/响应，单路请求，发布/订阅等等)
  • 支持广泛使用的传输协议(Http，JMS，MQ等等)
• 支持多种服务集成方式，比如 JCA、Web 服务、Messaging、Adaptor
• 对服务管理的支持，如服务调用的记录、测量和监控数据的提供

很多时候，很难界定哪些功能是应该由SOA的基础架构(infrastructure)提供的，而哪些应该放在ESB的范畴内来解决。笔者认为，放大或突出ESB在SOA架构中的地位并不很恰当。比较合理的解释是：ESB应该构筑在完善的SOA架构上，做它应该做的事-服务集成。至于怎样集成，应该根据你的上下文环境，考虑有哪些SOA的基础设施可供你使用，然后再基于SOA的基础架构来实现你的ESB设计。

在更高的层次，ESB还提供诸如服务代理，协议转换等等功能，我们称之为ESB的应用模式(ESB usage pattern)。作为SOA架构的服务集成功能提供者，我们可以总结出的一些比较常用的应用模式，例如：

1）协议转换模型，用于当服务的请求者与服务提供者基于不同协议时的消息转换情形

2）消息广播模式，用于事件驱动多个动作或者消息广播的情形

3）服务匹配模式，用于需要动态选择服务提供者的情形，例如可以根据消息的内容，或负载情况，或服务级别约定(SLA)，来为服务请求者选择合适的服务。

这里我们只列举了3个典型的模式，而这样的例子实在太多了，发挥你的创造性，你还会想出来更多的，这也是ESB的魅力所在。但是，在ESB的设计上，注意不能喧宾夺主，ESB的功能在于帮助服务的集成，而不是参与业务逻辑。业务逻辑应该封装在业务服务中，或通过业务编排服务(Process Service)来组织。

实战

关于ESB，目前还没有被一致接受的标准。我们可以通过选择成熟的EAI 中间件来实现服务的集成与互操作性。这样做的好处是你的开发过程会很顺畅，因为它已经足够稳定且有丰富的工具支持。通常这样的EAI产品在目前阶段都还不是基于开放的标准，例如IBM的WebSphere MQ5.3，作为IBM EAI实现ESB的消息平台，就不是开放的标准。如果一定要选择开放标准的ESB实现方式，Web 服务加上WS-* 协议几乎是我们唯一的选择，但毕竟SOA、ESB仍处于起步的阶段，一方面我们还没有很成熟的产品支持所有的WS-*协议，另一方面这些WS-* 协议本身还处在频繁变化的阶段。因此当你选择ESB实施方案的时候，最好考虑平衡ESB实施、开发的工作量。

这里你可能会有疑问，既然SOA架构追求开放性，为什么我们要容忍用私有的ESB产品如IBM WBI/MQ来构建SOA架构的集成环境？这是一个好问题。SOA始终是我们追求的大目标，开放是必然的趋势，这是毋庸置疑的。但是，请注意ESB的定义，至少到目前为止，还没有明确的要求它的实现一定是开放的，每一个软件供应商对它都可能有不同的理解和实现的策略。我们不用怀疑ESB将来的开放之路，但至少在目前阶段，我们不能坐下来等待它的到来。 其实，ESB充当的是SOA中的中介角色，因此，即使将来ESB变化了，对服务的请求者和服务的提供者都不会造成很大的冲击，因为它本来就是对用户透明的。举个例子，J2EE，它的标准一直在变化中，但是大家通常都能接受它的变化，社会总是要进步的，IT也一样。你不可能因为J2EE 两年以后要出1.6就不再使用现在的1.4了。

IBM目前可以用于ESB实施的产品也可以分为两大阵营：

1. 以目前稳定的产品如WS MQ，WBI Message Broker，Tivoli等为代表的EAI解决方案。
2. 以WAS6 SIBUS为代表的专用ESB平台。

现有的EAI解决方案，可能涉及如下的IBM软件产品：

• WebSphere BI Message Broker用于提供ESB的message 中介功能(Mediation)
• WebSphere MQ / JMS 用于消息传输服务
• WebSphere Process Choreographer 用于实现服务流程
• WebSphere Adaptor用于连接遗留系统
• Web Service Gateway用于实现Web服务 Proxy，屏蔽企业内部/外部Web服务的实现细节

WAS6 中提供了崭新的消息服务平台WPM(WebSphere platform messaging)，并基于这一平台提供了ESB的一个具体实现- SIBus(Service Integration Bus) 它可以支持同步和异步的消息通信。总线(Bus)通过互联的消息引擎管理消息源。同时支持基于Web服务和JMS，MQ格式的消息交互。你可以从WAS6身上看到IBM战略的变化，SIBus只是IBM加大对于SOA支持的一步，你还会很快看到更多的变化，例如独立的ESB产品，ESB的开发工具等等。但是，你完全不必担心，这些变化都会保持兼容性，现在SOA的投入，无论是以哪一种方式，都会在IBM的SOA整体考虑之中。

上述的两种方案并不是对立的，你可以选择基于成熟产品实现ESB，也可以尝试一下IBM的最新技术。这两种方案甚至可以互联，见图八。我们将在系列的第四部分讲解这一较为复杂的场景。