Secret Garden
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。

发表评论

textsms
account_circle
email

6 + 3 =

  • 威武中国

    你主题都换了,就不能更新篇文章吗。。。。。。

    5月前回复
    • 小金钟博主

      @威武中国: 一直想写点什么,工作太忙,力不从心啊。。。。

      5月前回复
  • zengda

    不错,不错,看看了!

    3年前回复
  • 黑曜石手链

    不错

    3年前回复

Secret Garden

MQ Java与MQ JMS选择
IBM MQ对java的开发支持两套接口,一套是按照JMS规范来的,一套是java接口。之前一直在考虑这两种方式有和区别,优点缺点分别在哪里,在不同的场景下用哪种更好。 比如我做过关于消息…
扫描二维码继续阅读
2015-03-20