Transporte de JMS v/s Transporte de MQ

Question

Estoy utilizando Oracle Service Bus (OSB) como MOM, y el URI de destino es una cola de IBM MQ. Solo quiero saber cuál sería el transporte preferido. OSB proporciona 2 adaptadores para el mismo adaptador JMS y adaptador MQ para el transporte. ¿Alguien sabe cuáles son los PROS y CONS de la misma? TIA

Answer 1

Normalmente, el envío de mensajes a través de la interfaz MQI nativa será más rápido que con JMS. En realidad, dudo que veas una diferencia real, a menos que estés enviando toneladas de mensajes por día. Sin embargo, hay otras cosas a considerar además de la velocidad. Por ejemplo, si no está familiarizado con las aplicaciones MQI, la curva de aprendizaje será más pronunciada que JMS.

La información del encabezado JMS se asigna a un encabezado MQRFH2 cuando se envía a otro destino JMS a través de MQ. La inclusión de un encabezado MQRFH2 se elimina del objeto de destino que crea. Si el destino es un punto final JMS, se incluye el encabezado.

He incluido un enlace que explica cómo se asignan los campos:

1. Mapping JMS messages onto MQI messages.

En realidad, a menos que usted está enviando millones de mensajes al día que asumiría que el rendimiento de JMS en WebsphereMQ será más que adecuado para sus necesidades. En lo que respecta al bloqueo de subprocesos en la respuesta de solicitud, no creo que deba preocuparse por esto. Por defecto, la respuesta en WebsphereMQ es consumida por un hilo separado, no el hilo solicitante.

Answer 2

Depende de si el programa en el otro extremo de la cola MQ espera un JMS o un mensaje MQ "nativo".

MQ puede actuar como un mecanismo de cola nativo o un transporte para mensajes JMS. La diferencia es que los mensajes JMS tienen algunos campos de encabezado estándar al comienzo del búfer de mensajes y los mensajes mq "nativos" contienen solo los datos que su programa envió al búfer.

Answer 3

Solo quería agregar lo que encontré que funcionó para mí. Debes hacer lo siguiente cuando crees tu instancia de 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) 

La inclusión de la "? TargetClient = 1" hace que el mensaje en bruto que se enviará w/o un encabezado.

Espero que esto ayude a alguien. Mark

Answer 4

El rendimiento no es la única razón para enviar mensajes simples (formato MQ) sin los encabezados JMS del cliente JMS al servidor MQ. También puede ser que el consumidor del mensaje no sea un cliente JMS, como Tivoli Workload Scheduler (TWS) y .net.

presento una solución para un cliente independiente de Java y uno para JBoss AS que quitar el formato de MQRFH2 del mensaje JMS y convertirlo en el mensaje sencillo: el cliente

independiente 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 Application Server 7 adaptador de recursos

<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

De una gran cantidad de experiencia personal, I recomiendo usar Native MQ si es posible.

contras

JMS Transporte (cuando se utiliza WMQ) -

1. tasas más lentas de mensajes de JMS (He medido!)
2. Uso de archivo ".bindings" (que actúa como su JNDI servidor) es engorroso, ya que solo se puede editar utilizando el WMQ Explorer (o la herramienta horrible cmdmin cmdmin)
3. Requiere conocimiento avanzado tanto en WMQ como en Weblogic
4. Requiere reinicio de y nuestro dominio OSB para cada cambio de configuración

El único gran pro JMS Transport tenido sobre MQ nativo es su compatibilidad con la transacción XA. Esto se ha resolado en OSB 11.1.1.7 y ahora ambos transportes son compatibles con XA.

Pros MQ nativas -

1. más rápidas
2. OSB tiene acceso directo a MQ encabezados (esto es genial!)
3. transporte MQ nativo se puede configurar en tiempo de ejecución (utilizando sbconsole)
4. gestión sencilla del grupo de conexiones

De nuevo, recomiendo encarecidamente repare el uso de Native MQ Transporte en OSB siempre que sea posible.

Answer 6

Sólo mi 2c para todos los demás que podría estar buscando aquí, una visión actualizada de bits a partir del 2017:

• bibliotecas MQ nativos se encuentran en "estabilizado" estado partir de la versión 8.0, por lo tanto, no habrá no se agregaron nuevas características en las próximas versiones, solo habrá correcciones de errores/seguridad. Por ejemplo, afirman que el consumo asincrónico y la reconexión automática no están disponibles en las bibliotecas que no son JMS.

Más información aquí Choice of API

Declaración de interés general desde v8 es que las nuevas aplicaciones deben utilizar las clases de IBM MQ para JMS.Esto, por supuesto, no invalida todos los pros y los contras mencionados por selotape. Aún necesita más configuración y el rendimiento puede ser inferior de fábrica. En realidad hay un documento MP0E para v8 que afirma que han comparado la aplicación Java JMS MQ con la aplicación C++ MQI y la anterior era hasta un 35% más lenta según el escenario (, por lo que si recibes 50 vs 900 estás haciendo algo mal)