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

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

9
ibm-mq java jms oracle-service-bus weblogic

6 ответов

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

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

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

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

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

5

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

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

2

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

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 " вызывает отправку необработанного сообщения без заголовка.

надеюсь, это кому-то поможет. Марк!--2-->

1

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

Я представляю решение для автономного клиента 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>

1

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

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

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

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

родной MQ Pros -

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

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

0

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

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

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

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

0