java JMS 传输与 MQ 传输

JMS transport v/s MQ transport

提问by hakish

I am using Oracle Service Bus(OSB) as the MOM, and the destination URI is a IBM MQ queue. I just want to know which would be the preferred transport. OSB provides 2 adapters for the same, JMS adapter and MQ adapter for transport. Does any one knows what are the PROS and CONS of the same. TIA

我使用 Oracle Service Bus(OSB) 作为 MOM，目标 URI 是 IBM MQ 队列。我只想知道哪种交通工具是首选。OSB 提供了 2 个适配器，用于传输的 JMS 适配器和 MQ 适配器。有谁知道相同的优点和缺点是什么。TIA

采纳答案by gregwhitaker

Typically, sending messages via the native MQI interface will be faster than using JMS. In reality I doubt you will see a real difference, unless you are sending tons of messages per day. However, there are other things to consider than just speed. For example, if you are not familiar with MQI applications the learning curve will be steeper than JMS.

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

JMS header information is mapped to an MQRFH2 header when sent to another JMS destination via MQ. The inclusion of a MQRFH2 header is driven off of the Destination object you create. If the destination is a JMS endpoint then the header is included.

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

I have included a link below that explains how the fields are mapped:

我在下面包含了一个链接，解释了字段的映射方式：

1. Mapping JMS messages onto MQI messages.

1. 将 JMS 消息映射到 MQI 消息。

In reality, unless you are sending millions of messages a day I would assume that the performance of JMS on WebsphereMQ will be more than adequate for your needs. As far as thread blocking goes in request reply I don't think you need to worry about this. By default the reply in WebsphereMQ is consumed by a seperate thread, not the requesting thread.

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

回答by Mark

Just wanted to add what I found that worked for me. You have to do the following when you create your Queue instance.

只是想添加我发现对我有用的内容。创建 Queue 实例时，您必须执行以下操作。

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

The inclusion of the "?targetClient=1" causes the raw message to be sent w/o a header.

包含“?targetClient=1”会导致原始消息被发送 w/oa 头。

Hope this helps someone. Mark

希望这可以帮助某人。标记

回答by Andreas Panagiotidis

Performance is not the only reason to send plain messages (MQ format) without the JMS Headers from JMS Client to MQ Server. It can also be that the message consumer is a non JMS client, such as Tivoli Workload Scheduler (TWS) and .net.

性能并不是从 JMS 客户端向 MQ 服务器发送没有 JMS 标头的纯消息（MQ 格式）的唯一原因。也可能消息使用者是非 JMS 客户端，例如 Tivoli Workload Scheduler (TWS) 和 .net。

I present a solution for a Java standalone client and one for jboss as that remove the MQRFH2 format from the JMS message and turn it into plain message:

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

Standalone JMS client

独立的 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 resource adapter

应用服务器 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>

回答by James Anderson

It depends on whther the program at the other end of the MQ queue is expecting a JMS or "native" MQ message.

这取决于 MQ 队列另一端的程序是期待 JMS 还是“本机”MQ 消息。

MQ can act as a native queue mechanism or a transport for JMS messages. The difference being that JMS messages have some standard header fields at the begining of the message buffer and "native" mq messages contain just the data your program sent to the buffer.

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

回答by selotape

From an abundance of personal experience, I strongly recommend using Native MQif possible.

根据丰富的个人经验，我强烈建议尽可能使用 Native MQ。

JMS Transport cons(when using WMQ) -

JMS 传输缺点（使用 WMQ 时）-

1. Slower message rates in JMS (I have measured!)
2. Use of ".bindings" file (which acts as your JNDI server) is cumbersome as it can only be editted using the WMQ Explorer (or the horrible JMSAdmin cmd tool)
3. It requires advanced knowledge in both WMQ and Weblogic
4. It requires restart of your OSB Domain for every change of configuration

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

The only major pro JMS Transport had over native MQ is its support of XA transaction. This has been resoled in OSB 11.1.1.7 and now both transports support XA.

JMS Transport 唯一优于原生 MQ 的主要优点是它对 XA 事务的支持。这已在 OSB 11.1.1.7 中解决，现在两种传输都支持 XA。

Native MQ Pros -

原生 MQ 优点 -

1. faster
2. OSB has direct access to MQ Headers (this is great!)
3. Native MQ transport can be configured during runtime (using sbconsole)
4. easy management of connection pool

1. 快点
2. OSB 可以直接访问 MQ 标头（这很棒！）
3. 可以在运行时配置本机 MQ 传输（使用 sbconsole）
4. 轻松管理连接池

Again, I strongly recommend use of Native MQTransport in OSB whenever possible.

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

回答by domaru

Just my 2c for everybody else that might be looking here, a bit updated view as of 2017:

只是我的 2c 给可能在这里看的其他人，截至 2017 年的一些更新视图：

• Native MQ librariesare in "stabilized" state as of version 8.0, therefore there will be no new features added in the upcoming versions, there will be just bug/security fixes. For example they claim that asynchronous consume and automatic reconnection is not available in non JMS libraries.

• 自8.0 版起，本机 MQ 库处于“稳定”状态，因此在即将推出的版本中不会添加任何新功能，只会修复错误/安全性。例如，他们声称异步消费和自动重新连接在非 JMS 库中不可用。

More info here Choice of API

这里有更多信息选择 API

General statement since v8 is that new applications should use IBM MQ classes for JMS. This of course does not invalidate all the pros and cons mentioned by selotape. You still need some more configuration and performance may be inferior out of the box. Actually there is a MP0E document for v8 that claims that they've compared Java JMS MQ App with C++ MQI app and the former was up to 35% slower depending on scenario (so if you are getting 50 vs 900 you are doing something wrong)

自 v8 以来的一般声明是，新应用程序应使用 IBM MQ 类进行 JMS。这当然不会使 selotape 提到的所有优点和缺点都无效。您仍然需要更多配置，开箱即用的性能可能较差。实际上有一个 v8 的 MP0E 文档声称他们已经将 Java JMS MQ 应用程序与 C++ MQI 应用程序进行了比较，并且前者根据场景慢了 35%（所以如果你得到 50 vs 900 你做错了什么）