JMS transport v/s MQ transport

Cela dépend de si doit porter sur le programme à l'autre bout de la MQ file d'attente s'attend à un JMS ou "indigène" MQ message.

MQ peut agir comme un natif de la file d'attente ou un mécanisme de transport de messages JMS. La différence étant que des messages JMS ont certains champs d'en-tête au début de la mémoire tampon de message et les "indigènes" mq messages contiennent uniquement les données de votre programme envoyé à la mémoire tampon.

OriginalL'auteur James Anderson

La Performance n'est pas la seule raison pour envoyer de la plaine des messages (MQ format) sans JMS les en-Têtes de JMS Client MQ Server. Il se peut également que le message consommateur est un non client JMS, comme Tivoli Workload Scheduler (TWS) et .net.

Je vous présente une solution pour une application Java autonome client et un pour jboss en tant que supprimer la MQRFH2 format de la JMS message et de le transformer en plaine message:

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

Serveur d'Application JBoss 7 adaptateur de ressources

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

OriginalL'auteur Andreas Panagiotidis

Juste mon 2c pour tout le monde, que peut-être ici, un peu à la vue mise à jour à compter de 2017:

• Natif MQ bibliothèques sont en "stabilisé" de l'état à partir de la version 8.0, donc il n'y aura pas de nouvelles fonctionnalités ajoutées dans les versions à venir, il y aura juste un bug/correctifs de sécurité. Par exemple, ils affirment que asynchrone de consommer et de reconnexion automatique n'est pas disponible dans non JMS bibliothèques.

Plus d'info ici Le choix de l'API

Déclaration générale depuis la v8, c'est que les nouvelles applications devraient utiliser IBM MQ classes de JMS. Ce n'est évidemment pas la nullité de tous les avantages et les inconvénients mentionnés par selotape. Vous avez encore besoin d'un peu plus de configuration et les performances peuvent être inférieures hors de la boîte. En fait il y a un MP0E document pour v8 qui prétend qu'ils ont par rapport Java JMS MQ Application avec C++ MQI application et l'ancien a été jusqu'à 35% plus lent selon le scénario (si vous obtenez de 50 vs 900 vous faites quelque chose de mal)

OriginalL'auteur domaru