JMS транспорт v / s MQ транспорт - PullRequest
Новая
       28

JMS транспорт v / s MQ транспорт

10 голосов
/ 02 августа 2010

Я использую Oracle Service Bus (OSB) в качестве MOM, а целевой URI является очередью IBM MQ.Я просто хочу знать, какой будет предпочтительным транспортом.OSB предоставляет 2 адаптера для одного и того же, JMS-адаптер и MQ-адаптер для транспортировки.Кто-нибудь знает, какие плюсы и минусы одинаковы.ТИА

Ответы [ 6 ]

6 голосов
/ 15 августа 2010

Как правило, отправка сообщений через собственный интерфейс MQI будет быстрее, чем при использовании JMS. На самом деле я сомневаюсь, что вы увидите реальную разницу, если вы не отправляете тонны сообщений в день. Однако есть и другие вещи, которые следует учитывать, кроме скорости. Например, если вы не знакомы с приложениями MQI, кривая обучения будет круче, чем JMS.

Информация заголовка JMS отображается в заголовок MQRFH2 при отправке в другой пункт назначения JMS через MQ. Включение заголовка MQRFH2 выполняется за счет создаваемого вами объекта Destination. Если пункт назначения является конечной точкой JMS, тогда включается заголовок.

Я включил ссылку ниже, которая объясняет, как поля отображаются:

  1. Отображение сообщений JMS на сообщения MQI.

В действительности, если вы не отправляете миллионы сообщений в день, я бы предположил, что производительность JMS на WebsphereMQ будет более чем адекватной вашим потребностям. Что касается блокировки потоков в ответе на запрос, я не думаю, что вам нужно беспокоиться об этом. По умолчанию ответ в WebsphereMQ используется отдельным потоком, а не запрашивающим потоком.

2 голосов
/ 14 ноября 2011

Просто хотел добавить то, что нашел, и это сработало для меня.При создании экземпляра очереди необходимо выполнить следующие действия. 

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

Включение «? TargetClient = 1» приводит к отправке необработанного сообщения без заголовка.

Надеюсь, это кому-нибудь поможет.Mark

2 голосов
/ 02 августа 2010

Это зависит от того, ожидает ли программа на другом конце очереди MQ JMS или «собственного» сообщения MQ.

MQ может действовать как собственный механизм очереди или транспорт для сообщений JMS.Разница заключается в том, что сообщения JMS имеют некоторые стандартные поля заголовка в начале буфера сообщений, а «собственные» сообщения mq содержат только данные, которые ваша программа отправила в буфер.

1 голос
/ 12 сентября 2013

Производительность - не единственная причина для отправки простых сообщений (в формате MQ) без заголовков JMS с клиента JMS на сервер MQ. Также может быть, что получатель сообщения не является клиентом JMS, таким как Tivoli Workload Scheduler (TWS) и .net.

Я представляю решение для автономного клиента Java и одно для jboss, так как оно удаляет формат MQRFH2 из сообщения JMS и превращает его в простое сообщение:

Автономный клиент 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 7 

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

0 голосов
/ 10 марта 2017

Просто мой 2c для всех, кто может искать здесь, немного обновленное представление по состоянию на 2017 год:

  • Собственные библиотеки MQ находятся в "стабилизированном" состоянии с версии8.0, поэтому в следующих версиях не будет добавлено никаких новых функций, будут только исправления ошибок и безопасности.Например, они утверждают, что асинхронный прием и автоматическое переподключение недоступны в библиотеках, отличных от JMS.

Подробнее здесь Выбор API

Общее утверждение, поскольку v8что новые приложения должны использовать классы IBM MQ для JMS.Это, конечно, не лишает законной силы все плюсы и минусы, упомянутые selotape.Вам по-прежнему нужно больше конфигурации и производительность может быть ниже, чем в стандартной комплектации.На самом деле существует документ MP0E для v8, в котором утверждается, что они сравнивали Java JMS MQ App с приложением C ++ MQI, причем первое было медленнее на 35% в зависимости от сценария (, поэтому, если вы получаете 50 против 900, вы делаетечто-то не так )

0 голосов
/ 30 декабря 2013

Из-за личного опыта я настоятельно рекомендую использовать Native MQ , если это возможно.

JMS Транспортные минусы (при использовании WMQ) -

  1. Более низкая скорость сообщений в JMS (я измерил!)
  2. Использование файла ".bindings" (который выступает в качестве вашего сервера JNDI) является обременительным, поскольку его можно редактировать только с помощью WMQ Explorer (или ужасного инструмента JMSAdmin cmd)
  3. Требуются расширенные знания как в WMQ, так и в Weblogic
  4. Для каждого изменения конфигурации требуется перезапуск вашего домена OSB

Единственная важная профессиональная версия JMS Transport по сравнению с собственным MQ - это поддержка транзакций XA. Это было восстановлено в OSB 11.1.1.7, и теперь оба транспорта поддерживают XA.

Native MQ Pros -

  1. быстрее
  2. OSB имеет прямой доступ к заголовкам MQ (это здорово!)
  3. Собственный MQ-транспорт можно настроить во время выполнения (используя sbconsole)
  4. простое управление пулом соединений

Опять же, я настоятельно рекомендую по возможности использовать Native MQ Transport в OSB.

...