MQ and ESB and Message Broker

<转自http://blog.sina.com.cn/s/blog_5fdcb4a00100into.html>

首先从概念上来说，MQ是消息中间件，MB是ESB产品

MQ负责在两个系统之间传递消息，这两个系统可以是异构的，处于不同硬件、不同操作系统、用不同语言编写，只需要简单的调用几个MQ的API，就可以互相通讯，你不必考虑底层系统和网络的复杂性。MQ作为IBM的一个拳头产品，虽然功能看上去很简单，就是个消息队列，但他却是IBM中间件的核心，也是相比其他厂商（比如BEA）的一个优势。MQ不仅有很高的性能，而且对各种平台的支持非常好，几乎你能想到的硬件和操作系统平台以及编程语言，MQ都有专门的API支持。

但MQ的功能仅限于消息队列，至于应用A发给应用B的消息格式是怎样的、能不能被应用B解析，MQ管不了，他只是尽力将消息发到目的地（MQ能够应付多种异常情况，例如网络阻塞、临时中断等等）。此外，如果应用的数目多了，那互相之间都要建立MQ连接，网络拓扑就成了蜘蛛网了（就好像是最初的电话系统）

因此，我们将网络的星型拓扑引入系统架构中，把一对一的MQ换成一个中心节点，即ESB，MB即是IBM的ESB产品。

MB处于系统的中心，起到一个总线的作用，所有应用都直接连接到MB，而不是应用之间直接互联，这样的好处不言而喻，可以极大的降低应用之间的耦合性。由此引出MB的两大核心功能：消息路由和数据转换
因为各个应用都插入到MB上，所以应用A只管把消息丢给MB，MB自动根据消息字段、以及业务逻辑，判断要把消息交给谁，这就像路由器一样，根据数据包的头把包路由到相应地址。MB内部的业务逻辑由开发人员设定，当然利用MB的Toolkit，编写业务逻辑也非常简单：拖一些节点，用箭头把它们连起来，就像是画流程图一样，非常形象简单。再用MB的脚本语言（类似sql的脚本）实现逻辑判断，通俗地说就是判断要走哪个逻辑分支（if...else.....）。

不过各个应用是怎样与MB连接的呢？MB提供了三种方式：MQ、文件和web service

MQ方式即是利用MQ将MB与应用互联；文件方式则是指定某个目录，MB会自动监视那个文件目录，一旦文件有改变则认为是新的消息到来，MB自动读取指定文件的内容；而web service就不用解释了，直接利用web service进行通讯。MB支持这些互联方式也是为了最大化兼容性，特别是对于那些遗留系统或是不支持主流通讯方式的系统

最后说说一个比较偏门的ESB产品：websphere ESB。听过的人可能不多，因为IBM在中国推广的比较少，这个WESB很像是MB的精简版，只支持JMS、WS等少数几种J2EE的通讯方式，所以是为J2EE专门准备的。不像MB，支持数十种平台和通讯方式，例如FTP，甚至很多你根本没听说过的很古老的通信协议。这两者的性能相差不少，价格也有三四倍的差距。更要命的是，原先在WESB上开发的东西，是不能迁移到MB使用的，IBM似乎铁了心要狠狠宰我们，唯一的方法是再买一个MB，然后用MQ把WESB和MB连接起来，各跑各的

漏了一个DataPower，这东西我只是略有了解，它的卖点在于硬件支持XML，所以性能比较好，此外还支持一下web service安全方面的东东。因此，WESB是最小功能集，而MB与datapower功能上有一定重叠，如XML

最后声明，我不是在给IBM打广告