JMS 传输与 MQ 传输

Question

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

Answer 1

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

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

我在下面添加了一个链接，解释了如何映射字段：

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

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

Answer 2

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

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

包含“?targetClient=1”会导致发送带有 oa 标头的原始消息。

希望这对某人有帮助。标记

Answer 3

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

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

Answer 4

性能并不是从 JMS 客户端向 MQ 服务器发送不带 JMS 标头的纯消息（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...

应用程序服务器 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 传输缺点（使用 WMQ 时）-

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

唯一主要的专业 JMS 传输超过本机 MQ就是它对XA事务的支持。此问题已在 OSB 11.1.1.7 中得到解决，现在两种传输都支持 XA。

本机 MQ 优点 -

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

再次，我强烈建议使用 <尽可能使用 OSB 传输本机 MQ。

Answer 6

对于其他可能在这里查看的人来说，我的 2c 是截至 2017 年的一点更新视图：

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

更多信息请参见此处 选择API

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