原文:http://www.lrsolution.com/docs/MQvsWLJMS.html
刘睿
2005年7月
在面向消息的中间件(MOM)这个领域,IBM MQSeries (又称WebSphere MQ)一直是当仁不让的超级大哥,其它还有一些小兄弟,比如SwiftMQ、SonicMQ之类。但近年来随着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”的警告:
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服务器的实例读消息了。
分享到:
相关推荐
IBM MQSeries使用指南 随着计算机网络和分布式应用的不断发展,远程消息传递越来越成为应用系统中不可缺少的组成部分。商业消息中间件的出现保证了消息传输的可靠性,高效率和安全性,同时也减少了系统的开发周期。...
\IBM MQSeries 使用指南.pdf
许多厂商目前都支持 JMS,包括 IBM 的 MQSeries、BEA的 Weblogic JMS service和 Progress 的 SonicMQ,这只是几个例子。 JMS 使您能够通过消息收发服务(有时称为消息中介程序或路由器)从一个 JMS 客户机向另一个 ...
IBM MQSeries Workflow 概念和体系结构 版本3.3 (GH84-0581-03).pdf
随着计算机网络和分布式应用的不断发展,远程消息传递越来越成为应用系统中不可缺少的组成部分。...目前应用最多的消息中间件产品为IBM MQSeries。本文就针对MQ的基本操作与配置进行详细的阐述,希望对读者有所帮助。
IBM MQSeries Workflow 安装指南 版本 3.2.1 (SH84-0584-04).pdf
IBM MQSeries Workflow Buildtime 入门 版本 3.2.1 (SH84-0582-04).pdf
IBM MQSeries Workflow Buildtime 入门 版本 3.2.2 (SH84-0582-05).pdf
websphere 中间件 工作流
BizTalk Server 2006中使用MQSeries适配器问题处理
介绍了IBM MQSeries的工作原理,对程序中使用MQSeries进行进程间通信提供了指南帮助
随着计算机网络和分布式应用的不断发展,远程消息传递越来越成为应用系统中不可缺少的组成部分。...目前应用最多的消息中间件产品为IBM MQSeries。本文就针对MQ的基本操作与配置进行详细的阐述,希望对读者有所帮助。
• Client/server solutions • Platform knowledge (IBM and non-IBM) • Open systems Objectives After completing this course, you should be able to: • Compare and contrast MQSeries with other forms of ...
MQSeries AIX 版 V5.1 手册 MQSeries AIX 版 V5.1 手册 标题 MQSeries 规划指南 MQSeries Intercommunication MQSeries 客户程序 MQSeries 系统管理 MQSeries 命令参考手册 MQSeries 可编程系统管理 MQSeries...
Tuxedo概述 Tuxedo基本概念 BEA Tuxedo的功能 BEA Tuxedo的环境变量 BEA Tuxedo管理进程 BEA Tuxedo常用命令使用方法 BEA Tuxedo的开发 BEA Tuxedo配置信息UBBCONFIG BEA Tuxedo与XA规范 ...IBM MQSeries简单介绍
MQSeries 安装配置操作维护手册
MQSeries+编程模式.pdfMQSeries+编程模式.pdfMQSeries+编程模式.pdf
本文介绍了Sybase的解决方案集:NEON Access IBM MQSeries, S.W.I.F.T.接口。NEON取消了传真和电报接收数据时慢速、低效的手工方式,而代之以一种非常稳定的解决方案,它可以大大缩短处理S.W.I.F.T消息所需要的时间...
MQSeries 应用程序可使用多种编程语言和风格进行开发。程序化和面向对象的编程可 通过Visual Basic、C、C++、Java、以及COBOL 来实现。Microsoft Windows NT ActiveX/COM 技术也同样可对其进行支持。 无论多么庞大或...