MQ Java与MQ JMS选择

IBM MQ对java的开发支持两套接口,一套是按照JMS规范来的,一套是java接口。之前一直在考虑这两种方式有和区别,优点缺点分别在哪里,在不同的场景下用哪种更好。

比如我做过关于消息匹配的实验,MQ是支持按照MessageID、CorrelationID、GroupID等五个标识来匹配消息(这五个标识分别在不同场景下有不同意义,但其实也可以混着来),如果Sender在发送消息时在这些标识里填入了有意义的信息,而Receiver在配置时也申明了要对这些标识进行匹配,那么Receiver从队列中取消息时,只会取到匹配的消息。这套机制在MQ针对各种语言的API都可使用,包括MQ Java API。

但是MQ JMS恰恰不一样。JMS用setXXProperties()等方法来给消息增加额外的属性,在取消息时,用类似SQL语法的selector来匹配并取出想要的消息,这套与之前按照五个标识匹配不能一一对应。具体表现为:

MQ Java MQ JMS 说明
MQMessage.MessageID setJMSMessageID()/getJMSMessageID()
MQMessage.CorrelationID setJMSCorrelationID()/getJMSCorrelationID()
MQMessage.GroupID 其实MQ Java 和 JMS API都可以实现消息分组,但JMS复杂很多
MQMessage.MsgSeqNumber
MQMessage.Offset
setXXXasBytes()/setYYYasInt()

后来一直在研究怎样才能让MQ Java(或C、C#等API)与MQ JMS之间互相能够用消息匹配来收发消息。前几天在与IBM售前开会时正准备问这样的问题,话到了嘴边突然想明白了。

MQ为了支持JMS规范而提供的MQ JMS必然是会损失IBM MQ自身的一些优秀特性的,因为JMS规范设计之初就是为了通用、与平台无关性,IBM MQ JMS只是众多JMS产品选择中的一种而已,没有必要加入JMS规范中没规定的特性。而MQ Java、MQ C等API是MQ自身对多平台的支持,包含了MQ所有的特性。

因此,两者如何取舍非常容易,如果系统是Java编写,且考虑到解耦与程序可移植性,打算选用JMS的话,MQ JMS便是一个很好的选择;如果系统间不同应用是异构的,且消息中间件打算用MQ,那无疑要用MQ Java、MQ C等API。

Tags:

2 Responses to “MQ Java与MQ JMS选择”

  1. zengda Says:

    不错,不错,看看了!

    [回复]

  2. 黑曜石手链 Says:

    不错

    [回复]

Leave a Reply

You must enable javascript to see captcha here!