15

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

4

6 回答 6

8

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

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

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

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

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

于 2010-08-15T14:13:49.253 回答
5

只是想添加我发现对我有用的东西。创建 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)

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

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

于 2011-11-14T19:11:39.717 回答
3

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

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

于 2010-08-02T06:54:31.460 回答
3

性能并不是从 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>

于 2013-09-12T05:59:58.677 回答
0

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

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

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

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

原生 MQ 优点 -

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

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

于 2013-12-30T18:33:30.747 回答
0

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

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

更多信息在这里API 的选择

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

于 2017-03-10T14:48:08.027 回答