JMS transport v/s MQ transport

StackOverflow https://stackoverflow.com/questions/3385576

Question

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

Was it helpful?

Solution

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.

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.

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

  1. Mapping JMS messages onto MQI messages.

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.

OTHER TIPS

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 = 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.

Hope this helps someone. Mark

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

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.

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.

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:

Standalone JMS client

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

<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>

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

JMS Transport cons (when using 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

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.

Native MQ Pros -

  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

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

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

  • Native MQ libraries are 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.

More info here Choice of 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)

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top