Question

我使用Oracle Service Bus（OSB）作为MOM，目标URI是IBM MQ队列。我只是想知道哪个是首选的运输工具。 OSB为相同的JMS适配器和MQ适配器提供2个适配器以进行传输。有没有人知道什么是PROS和相同的CONS。 TIA

Answer 1

通常，通过本机MQI接口发送消息比使用JMS更快。实际上，我怀疑你会看到真正的区别，除非你每天发送大量的消息。但是，还有其他事情要考虑而不仅仅是速度。例如，如果您不熟悉MQI应用程序，则学习曲线将比JMS更陡峭。

当通过MQ发送到另一个JMS目标时，JMS头信息被映射到MQRFH2头。包含MQRFH2标头是由您创建的Destination对象驱动的。如果目标是JMS端点，则包含标头。

我在下面添加了一个链接，说明了字段的映射方式：

Mapping JMS messages onto MQI messages.

实际上，除非您每天发送数百万条消息，否则我认为WebsphereMQ上的JMS性能将足以满足您的需求。至于线程阻塞在请求回复中我不认为你需要担心这一点。默认情况下，WebsphereMQ中的回复由单独的线程使用，而不是请求线程。

Answer 2

这取决于MQ队列另一端的程序是否需要JMS或“本机”MQ消息。

MQ可以充当本机队列机制或JMS消息的传输。区别在于JMS消息在消息缓冲区的开头有一些标准的头字段，而“本机”mq消息只包含程序发送到缓冲区的数据。

Answer 3

只是想添加我发现的对我有用的东西。创建队列实例时，必须执行以下操作。

Queue queue = queueSession.createQueue("queue:///" + queueName + "?targetClient=1");
//Send w/o MQRFH2 header (i.e. receiver is not a JMS client but just MQ)

包含＆＃34;？targetClient = 1＆＃34;导致原始消息无标题发送。

希望这有助于某人。标记

Answer 4

性能不是在没有JMS客户端从JMS客户端到MQ服务器的情况下发送纯文本消息（MQ格式）的唯一原因。消息使用者也可以是非JMS客户端，例如Tivoli Workload Scheduler（TWS）和.net。

我提供了一个Java独立客户端的解决方案和一个用于jboss的解决方案，因为它从JMS消息中删除MQRFH2格式并将其转换为明文消息：

独立JMS客户端

import com.ibm.msg.client.wmq.WMQConstants;
import com.ibm.mq.jms.MQQueue;

Hashtable<String, String> env = new Hashtable<String, String>();
env.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.ldap.LdapCtxFactory");
env.put(Context.PROVIDER_URL, "ldap://...);

InitialContext context = new InitialContext(env);

ConnectionFactory connectionFactory = (ConnectionFactory)   context.lookup(JNDI_QUEUE_CONNECTION_FACTORY);

//the following to extra lines make sure that you send 'MQ' messages
MQQueue mqQueue = (MQQueue) iniCtx.lookup(queueJNDI);
mqQueue.setTargetClient(WMQConstants.WMQ_CLIENT_NONJMS_MQ);

Destination destination = (Destination) mqQueue;
...proceed as usual...

Application Server JBoss 7资源适配器

<subsystem xmlns="urn:jboss:domain:resource-adapters:1.0">
<resource-adapters>
<resource-adapter>
    <archive>wmq.jmsra.rar</archive>
    <transaction-support>NoTransaction</transaction-support>
    <connection-definitions>
        <connection-definition class-name="com.ibm.mq.connector.outbound.ManagedConnectionFactoryImpl" jndi-name="java:jboss/jms/MqConnectionFactory" pool-name="MqConnectionFactoryPool">
            <config-property name="connectionNameList">${mqserver}</config-property>
            <config-property name="channel">${mqchannel}</config-property>
        </connection-definition>
    </connection-definitions>
    <admin-objects>
        <admin-object class-name="com.ibm.mq.connector.outbound.MQQueueProxy" jndi-name="java:jboss/jms/MyQueue" pool-name="MyQueuePool">
        <config-property name="baseQueueName">${queuename}</config-property>
        <config-property name="targetClient">MQ</config-property>
    </admin-object>
 </admin-objects>

Answer 5

从丰富的个人经验来看，如果可能，我强烈建议使用Native MQ 。

JMS Transport cons （使用WMQ时） -

JMS中的消息速率较慢（我测量过了！）
使用“.bindings”文件（充当您的JNDI服务器）很麻烦，因为它只能使用WMQ Explorer（或可怕的JMSAdmin cmd工具）进行编辑。
它需要WMQ和Weblogic
每次更改配置时都需要重新启动OSB域

唯一的主要专业JMS Transport超过本机MQ是对XA事务的支持。这已在OSB 11.1.1.7中重新解析，现在两个传输都支持XA。

原生MQ专业人士 -

更快
OSB可以直接访问MQ标头（这很棒！）
可以在运行时（使用sbconsole）
轻松管理连接池

同样，我强烈建议尽可能在OSB中使用 Native MQ 传输。

Answer 6

对于其他可能在这里寻找的人来说，只是我的2c，截至2017年的更新观点：

原生MQ库处于稳定状态＆＃34;从版本8.0开始，因此在即将推出的版本中不会添加任何新功能，只会出现错误/安全修复。例如，他们声称异步消费和自动重新连接在非JMS库中不可用。

此处有更多信息Choice of API

自v8以来的一般声明是新应用程序应该将IBM MQ类用于JMS。这当然不会使selotape提到的所有利弊无效。您仍需要更多配置，性能可能低于开箱即用。实际上有一个针对v8的MP0E文档声称他们已经将Java JMS MQ应用程序与C ++ MQI应用程序进行了比较，前者的速度高达35％，具体取决于场景（所以如果你得到50 vs 900你做错了）

JMS传输v / s MQ传输

6 个答案: