Trasporto JMS v/s Trasporto MQ

Question

Utilizzo Oracle Service Bus (OSB) come MOM e l'URI di destinazione è una coda MQ IBM. Voglio solo sapere quale sarebbe il trasporto preferito. OSB fornisce 2 adattatori per lo stesso adattatore JMS e l'adattatore MQ per il trasporto. Qualcuno sa quali sono i PRO e i CONS della stessa. TIA

Answer 1

In genere, l'invio di messaggi tramite l'interfaccia MQI nativa sarà più veloce rispetto all'utilizzo di JMS. In realtà dubito che vedrai una vera differenza, a meno che non invii tonnellate di messaggi al giorno. Tuttavia, ci sono altre cose da considerare oltre alla velocità. Ad esempio, se non si ha familiarità con le applicazioni MQI, la curva di apprendimento sarà più ripida di JMS.

Le informazioni di intestazione JMS sono mappate su un'intestazione MQRFH2 quando vengono inviate a un'altra destinazione JMS tramite MQ. L'inclusione di un'intestazione MQRFH2 viene disattivata dall'oggetto Destinazione che hai creato. Se la destinazione è un endpoint JMS, viene inclusa l'intestazione.

ho inserito un link qui sotto che spiega come i campi sono mappati:

1. Mapping JMS messages onto MQI messages.

In realtà, a meno che non si inviano milioni di messaggi al giorno presumo che le prestazioni di JMS su WebsphereMQ sarà più che adeguato alle tue esigenze. Per quanto riguarda il blocco dei thread va nella richiesta di risposta, non penso che sia necessario preoccuparsi di questo. Per impostazione predefinita, la risposta in WebsphereMQ viene utilizzata da un thread separato, non dal thread richiedente.

Answer 2

Dipende dal fatto che il programma all'altro capo della coda MQ si aspetta un JMS o un messaggio MQ "nativo".

MQ può fungere da meccanismo di coda nativa o da trasporto per i messaggi JMS. La differenza è che i messaggi JMS hanno alcuni campi di intestazione standard all'inizio del buffer dei messaggi e i messaggi mq "nativi" contengono solo i dati inviati dal programma al buffer.

Answer 3

Volevo solo aggiungere quello che ho trovato che ha funzionato per me. Devi fare quanto segue quando crei la tua istanza 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) 

L'inclusione del "? TargetClient = 1" fa sì che il messaggio grezzo da inviare w/o un colpo di testa.

Spero che questo aiuti qualcuno. Mark

Answer 4

prestazioni non è l'unica ragione per inviare messaggi semplici (formato MQ) senza le intestazioni JMS da JMS client al server MQ. Può anche essere che il consumer del messaggio sia un client non JMS, come Tivoli Workload Scheduler (TWS) e .net.

vi presento una soluzione per un client standalone Java e uno per JBoss AS che rimuovere il formato MQRFH2 dal messaggio JMS e di trasformarlo in un messaggio chiaro: il client

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

Application Server JBoss adattatore 7 risorsa

<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

Dall'abbondanza di esperienza personale, I consiglia vivamente di utilizzare Native MQ se possibile.

contro

JMS Transport (quando si utilizza WMQ) -

1. tariffe dei messaggi più lento nel JMS (ho misurato!)
2. L'utilizzo di file ".bindings" (che agisce come il vostro JNDI server) è ingombrante in quanto può essere Editted soltanto usando il WMQ Explorer (o lo strumento cmd JMSAdmin orribile)
3. richiede conoscenze avanzate sia WMQ e Weblogic
4. si richiede riavvio di y il nostro dominio OSB per ogni cambio di configurazione

L'unico principale trasporto JMS pro su MQ nativo è il supporto della transazione XA. Questo problema è stato risolto in OSB 11.1.1.7 e ora entrambi i trasporti supportano XA.

Pro MQ Native -

1. più veloci
2. OSB ha accesso diretto alla MQ intestazioni (questo è grande!)
3. trasporto MQ nativo può essere configurato in fase di esecuzione (usando sbconsole)
4. gestione facile del pool di connessione

Anche in questo caso, raccomando fortemente riparare l'uso di Native MQ Trasporto in OSB quando possibile.

Answer 6

Solo il mio 2c per tutti gli altri che potrebbero essere alla ricerca qui, una visione po 'aggiornati al 2017:

• librerie MQ nativi sono in "stabilizzato" stato a partire dalla versione 8.0, quindi non ci sarà nessuna nuova funzionalità aggiunta nelle prossime versioni, ci saranno solo correzioni di bug/sicurezza. Ad esempio, affermano che il consumo asincrono e la riconnessione automatica non sono disponibili in librerie non JMS.

Maggiori informazioni qui Choice of API

dichiarazione Generale dal V8 è che le nuove applicazioni dovrebbero utilizzare le classi IBM MQ per JMS.Questo naturalmente non invalida tutti i pro e i contro menzionati da Selotape. Hai ancora bisogno di un po 'più di configurazione e le prestazioni potrebbero essere inferiori fuori dalla scatola. In realtà c'è un documento MP0E per v8 che afferma di aver confrontato l'app MQ JMS Java con l'app MQI C++ e il primo era più lento del 35% a seconda dello scenario (quindi se stai facendo 50 vs 900 stai facendo qualcosa di sbagliato)