Transport JMS v/s Transport MQ

Question

Używam usługi Oracle Service Bus (OSB) jako MOM, a docelowy identyfikator URI to kolejka produktu IBM MQ. Chcę tylko wiedzieć, który byłby preferowany transport. OSB zapewnia 2 adaptery dla tego samego adaptera JMS i adaptera MQ do transportu. Czy ktoś wie, co to jest PROS i CONS tego samego. TIA

Answer 1

Zazwyczaj wysyłanie wiadomości za pośrednictwem natywnego interfejsu MQI będzie szybsze niż przy użyciu JMS. W rzeczywistości wątpię, że zobaczysz prawdziwą różnicę, chyba że będziesz wysyłać mnóstwo wiadomości dziennie. Są jednak inne rzeczy do rozważenia niż tylko szybkość. Na przykład, jeśli nie znasz aplikacji MQI, krzywa uczenia się będzie bardziej stroma niż JMS.

Informacje nagłówka JMS są mapowane do nagłówka MQRFH2, gdy są wysyłane do innego miejsca docelowego JMS za pośrednictwem MQ. Włączenie nagłówka MQRFH2 jest wyłączane z tworzonego obiektu docelowego. Jeśli miejsce docelowe jest punktem końcowym JMS, nagłówek jest uwzględniany.

mam włączone link poniżej, który wyjaśnia, jak pola są odwzorowane:

1. Mapping JMS messages onto MQI messages.

W rzeczywistości, chyba że wysyłasz miliony wiadomości dziennie Przypuszczam, że przy wykonywaniu JMS w WebsphereMQ będzie więcej niż wystarczający dla twoich potrzeb. Jeśli chodzi o blokowanie wątków w odpowiedzi na żądanie, nie sądzę, że musisz się tym martwić. Domyślnie odpowiedź w WebsphereMQ jest zużywana przez osobny wątek, a nie przez wątek z prośbą.

Answer 2

To zależy od tego, który program na drugim końcu kolejki MQ oczekuje komunikatu JMS lub "natywnego" komunikatu MQ.

MQ może działać jako mechanizm macierzystej kolejki lub transportu dla wiadomości JMS. Różnica polega na tym, że wiadomości JMS mają pewne standardowe pola nagłówków na początku bufora komunikatów, a "natywne" komunikaty mq zawierają tylko dane, które Twój program wysłał do bufora.

Answer 3

Chciałam tylko dodać to, co znalazłem, które sprawdziło się u mnie. Podczas tworzenia kolejki należy wykonać następujące czynności.

Queue queue = queueSession.createQueue("queue:///" + queueName + "?targetClient=1"); 
//Send w/o MQRFH2 header (i.e. receiver is not a JMS client but just MQ) 

Włączenie "? TargetClient = 1" powoduje wysłanie nieprzetworzonej wiadomości bez nagłówka.

Mam nadzieję, że to komuś pomaga. Mark

Answer 4

Wydajność nie jest jedynym powodem wysyłania zwykłych wiadomości (formatu MQ) bez nagłówków JMS z klienta JMS do serwera MQ. Może się również zdarzyć, że konsument komunikatów jest klientem innym niż JMS, takim jak Tivoli Workload Scheduler (TWS) i .net.

przedstawiam rozwiązanie samodzielny klient Java i jeden dla JBoss jako że usunąć format MQRFH2 z komunikatu JMS i przekształcić go w zwykły komunikat: Klient

Samodzielny 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 adapter 7 zasób

<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

Z obfitości osobistego doświadczenia, Zdecydowanie zalecamy używanie Native MQ jeśli to możliwe.

JMS transportowe minusy (przy użyciu WMQ) -

1. Wolniejsze stopy message JMS (mam zmierzyć!)
2. użycie ".bindings" pliku (który działa jako JNDI serwer) jest kłopotliwe, gdyż może to być editted tylko przy użyciu WMQ Explorer (lub straszne JMSAdmin narzędzie cmd)
3. to wymaga zaawansowanej wiedzy w obu WMQ WebLogic
4. to wymaga restartu y Nasza domena OSB dla każdej zmiany konfiguracji

Jedynym ważnym produktem Pro JMS Transport, który miał nad rodzimym MQ, jest wsparcie dla transakcji XA. Zostało to rozwiązane w OSB 11.1.1.7 i teraz oba transporty obsługują XA.

Native MQ Plusy -

1. szybsze
2. OSB ma bezpośredni dostęp do MQ nagłówki (to jest wielki!)
3. Native Transport MQ mogą być konfigurowane w czasie pracy aplikacji (za pomocą sbconsole)
4. łatwe zarządzanie pulą połączeń

Ponownie, zdecydowanie polecam Jeśli jest to możliwe, skorzystaj z opcji Natywny MQ Transport na płycie OSB.

Answer 6

Tylko moja 2c dla wszystkich innych, które mogą być tu szuka, nieco zaktualizowana widok jak z 2017 roku:

• natywne biblioteki MQ są w „stabilizowany” stan Począwszy od wersji 8.0, dlatego nie będzie brak nowych funkcji dodanych w nadchodzących wersjach, będą tylko poprawki błędów/zabezpieczeń. Na przykład twierdzą, że asynchroniczne używanie i automatyczne ponowne łączenie nie są dostępne w bibliotekach innych niż JMS.

Więcej informacji tutaj Choice of API

ogólne oświadczenie od v8 to, że nowe aplikacje powinny używać klasy IBM MQ dla JMS.To oczywiście nie unieważnia wszystkich zalet i wad wymienionych przez selotape. Nadal potrzebujesz więcej konfiguracji, a wydajność może być gorsza po wyjęciu z pudełka. W rzeczywistości istnieje dokument MP0E dla wersji 8, który twierdzi, że porównał aplikację Java JMS MQ z aplikacją C++ MQI, a pierwsza z nich była do 35% wolniejsza w zależności od scenariusza (, więc jeśli otrzymujesz 50 vs 900, robisz coś źle)