rednight

0x2B|~0x2B,That's not a question,Just do it.
posts - 32, comments - 14, trackbacks - 0, articles - 0

转自http://www.lrsolution.com/docs/MQvsWLJMS.html


比较IBM MQSeries和BEA WebLogic JMS Server

刘睿
2005年7月

在面向消息的中间件(MOM)这个领域,IBM MQSeries (又称WebSphere MQ)一直是当仁不让的超级大哥,其它还有一些小兄弟,比如SwiftMQSonicMQ之类。但近年来随着J2EE中的JMS规范的建立,完备地支持JMS的服务器如雨后春笋般地出现,比如BEA WebLogic Server的JMS Server就是其中一个佼佼者。

仅仅就JMS规范来说,MQSeries与WebLogic JMS没有什么不同之处。但JMS规范仅仅定义了消息服务器的一个开发接口,而且还忽略了许多细节,所以不同之处就在JMS规范之外的这些内容,很多也是非常重要的。总的来说,MQSeries的功能和性能方面明显占优,而WebLogic JMS的某些JMS配置更加简单易行。

在本文中,我尽量试图从客观的角度分析两种产品的差异,如有不妥之处,请读者不吝赐教。

1. 产品体系架构不同造成的差异

WebLogic JMS是一个纯Java实现的支持C-S架构的实现JMS规范的服务器产品;而MQSeries是使用本地语言(比如在UNIX和Windows上的C语言)编写的既支持C-S架构,又支持对等访问的实现完备MOM(包括JMS规范)的产品。于是就产生出以下的不同点:

1.1 MQSeries支持真正的异步数据传输;而WebLogic JMS不支持。

异步发送数据到远端的消息服务器,是MQSeries等完备的MOM的特色。JMS规范规定了一个C-S架构,定义了JMS客户机与JMS服务器的开发接口,并没有定义JMS服务器与JMS服务器的规范,而客户机方面没有任何队列,所以只能说是规范了消息的存取,而没有规范消息数据的传输。因为JMS客户机并不拥有存放数据的队列,所以所有发送的操作都要由应用程序来控制,JMS服务器本身并不代理传输,也不保证数据在远程队列间传输的可靠性。WebLogic JMS就是这样的体系。

这种体系结构有时候是不能直接满足应用的要求的。首先,为了充分利用资源和提高效率,许多应用需要采用异步消息的机制。其次,许多需要快速返回的应用也必须使用异步传输。比如电话自动语音应答(IVR)的程序,某个操作需要把数据传输到远程的服务器上,但是必须立即返回,接受客户的下一个按键。

MQSeries通过通道与传输队列和远程队列来完成这一任务。能充分利用网络的带宽,甚至支持断网续传,保证数据传输的可靠性。当然,虽然应用程序不必作任何工作,但配置方面确实还要多学一些概念。

1.2 MQSeries支持多种语言的开发;而WebLogic JMS基本上只支持JAVA

MQSeries支持的语言包括C, C++, COBOL, JAVA, PL/1, REXX, RPG, Visual Basic (使用COM/ActiveX)等。老板本的MQSeries支持JAVA是通过一个叫MA88的SupportPac来实现,虽然经过广泛的使用和验证,但给人的感觉是不太方便。好在从5.3版起(目前最新的是6.0版),JAVA支持已经内置在MQSeries中。

WebLogic JMS一般只支持JAVA开发。但BEA也在dev2dev.bea.com网站上提供了一套免费的C的支持,称作“JMS C API”。参见http://dev2dev.bea.com/utilitiestools/environment.html?highlight=utilitiestools。但这个工具与老的MA88也是不能相提并论的,因为BEA并不真正支持它,因此也基本没有什么用户。参见BEA网站上关于“JMS C API”的警告:

This is *not* a supported product of BEA. However, if you have questions about this API you can post them to weblogic.developer.interest.jms.

1.3 纯JAVA实现的利与弊

MQSeries是用本地语言实现的,因此带来的好处是高性能和高并发的支持能力。MQSeries相对WebLogic JMS等产品的性能优势是非常明显的,所以MQSeries非常适于企业级的大数据量和高并发的数据传输业务。谁也无法想象一个企业级的数据应用会采用一个纯Java实现的数据库,因为其性能无法满足要求,对较大的数据传输应用也是一样的,纯Java实现的JMS服务器例如WebLogic JMS无法满足其性能的要求。

纯JAVA实现的JMS服务器也有其好处,就是与其它的J2EE服务完美地集成在一起。所以WebLogic的JMS配置显得更简洁。WebSphere+MQSeries也配合得很好,但总是能感觉到是这两个产品。WebLogic JMS的对象体系完全符合JMS的概念体系。而MQSeries要通过WebSphere Application Server或者一个叫JMSAdmin的工具,借助于目录服务来完成MQSeries概念体系到JMS概念体系的映射。应该是看到了这件事造成的麻烦,所以IBM在WebSphere v6也提供了一套纯JAVA实现的、与MQSeries可以互操作的JMS服务器。另外一点是WebLogic不需要WebSphere以及MQSeries那样的冗长的CLASSPATH等环境变量的设置,这点对开发人员有吸引力。

1.4 MQSeries的通信功能更加强大,WebLogic JMS也有自己的一些特色

JMS对通信功能的要求很少,所以对二者对通信支持能力还是有很大的差别的。总的来说,历史更悠久的MQSeries占优,但WebLogic JMS也有自己的特色。

  • MQSeries支持支持真正的远程异步数据传输,甚至支持消息的路由,可以“多级跳”;WebLogic JMS不支持。
  • MQSeries支持消息的分组和分段传输,对于大消息传输和不稳定的网络非常有意义。WebLogic JMS没有这方面的功能。
  • 二者都支持SSL、持久性、优先级、超时等功能。除了完备的SSL实现之外,MQSeries的安全体系 遭到了一些批评,使用通道的安全出口程序显得很麻烦,而使用用户名称但无须口令保护的远程数据通信,如何能令人满意?但在这一点上WebLogic JMS也很难说就好一些,因为WebLogic JMS仅仅支持C-S的操作,系统本身并不支持远程的数据传输(需要应用实现)。
  • WebLogic JMS支持IP多播会话,能显著地提高 局域网内广播通信的性能,但这种方式不保证数据接收的可靠性,只适于某些特定的应用。MQSeries本身不提供此功能,但在Event Broker和Message Broker等MQSeries的升级产品中提供IP多播的支持。

1.5 MQSeries的管理功能更加强大

JMS对管理功能的要求很少,在这方面MQSeries也有比较明显的优势。

  • JMS对事务处理的支持包括的对XASession和XAConnection实现,这一点对MQSeries和WebLogic JMS是相同的。MQSeries本身还可以作为事务管理器,协调两阶段提交。
  • MQSeries和WebLogic JMS都支持Message Driven Bean作为触发新的应用的一种方式。WebLogic JMS还支持一种称作Session Pool的类似的触发机制。但这类触发机制过于简化,也就是每个消息都触发一个新的线程的应用。MQSeries的触发机制更丰富,不但包括这种被称作Every的方式,还包括First和Depth等方式。另外MQSeries还可以触发各种执行程序或者MQSeries的通道。
  • MQSeries拥有一套完备的日志系统,可以进行独立的系统备份和恢复,因此适于高规格的数据/消息传输的应用。WebLogic JMS没有这方面的支持。

 

2. 产品历史的不同造成的差异

MQSeries是个历史悠久的产品,而WebLogic JMS是个新兵,因此会有以下的差异:

2.1 MQSeries支持更多的系统平台

支持30多种系统平台。当然值得注意的是某些平台的MQSeries是由合作伙伴实现的。

WebLogic JMS是个新产品,支持的平台数与WebLogic Server一样,只有常用的几个。有人说所有支持JDK的平台都能跑WebLogic JMS的客户机,这是不正确的说法。因为JMS是J2EE规范的一种,J2SE的SDK并不包括JMS的支持,更不要说支持WebLogic的J2EE了。

2.2 MQSeries支持更多的 通信协议

MQSeries支持很多通信协议,但目前在实践中常用的是TCP/IP协议和SNA协议。

WebLogic JMS仅支持TCP/IP协议。

有些人对MQSeries的单向通道的概念提出了异议,认为增加了配置的复杂性,仅仅是SNA协议的需要,而不是TCP/IP协议的需要。我个人认为这点也不无一些道理。但是在有防火墙的TCP/IP网络上,不同的方向还是有差异的。

 

3. 群集实现的差异

MQSeries与WebLogic JMS在支持群集时,差异比较大,应该说各有各的特点。

  • MQSeries的群集建立在配置库和群集通道基础之上,可以定义“共享队列”;WebLogic JMS的群集建立在WebLogic群集基础之上,可以定义“分布式队列”。
  • MQSeries在写共享队列时,如果发现本地有,就只写本地的队列(这称作本地优先);如果本地没有,就会轮流写到所有定义了此共享队列的队列管理器。MQSeries在读共享队列时,只能从本地取。WebLogic JMS在读写分布式队列时,不受本地影响,总是进行轮流或权重选择。听起来似乎WebLogic JMS的群集更灵活,其实也不尽然。当取得了JMS的对象QueueSender或QueueReceiver后,WebLogic实际上已经绑定了一个JMS服务器的实例。如果每次写或读一个消息,都重新生成QueueSender或QueueReceiver,虽然比较好地支持了负载均衡,但势必造成很大的性能损失。而MQSeries在轮流写共享队列时,没有这方面的问题。
  • WebLogic JMS的分布式队列有一个叫做Forward Delay的有意思的属性,定义了一个时间的长度。系统一旦发现超过这个时间长度,还没有人读这个队列,就把它的消息转送给群集中有消费者的队列。有了这个属性,应用程序就可以只从一个JMS服务器的实例读消息了。

只有注册用户登录后才能发表评论。


网站导航: