IBM Websphere MQ - миграция EJB и MDB для развертывания Tomcat

Question

Я давно с этим борюсь. У меня есть IBM Websphere MQ, который использует EJB и MDB

Ниже указано, где настроен ejb mdb.

<?xml version="1.0" encoding="UTF-8"?>
<ejb-jar-bnd xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://websphere.ibm.com/xml/ns/javaee"
    xsi:schemaLocation="http://websphere.ibm.com/xml/ns/javaee http://websphere.ibm.com/xml/ns/javaee/ibm-ejb-jar-bnd_1_0.xsd" version="1.0">
  <message-driven name="Queue1MDB">
    <jca-adapter activation-spec-binding-name="jms/Queue1MQActivationSpec" destination-binding-name="jms/Queue1RequestQueue"/>
    <resource-ref binding-name="jms/QueueConnectionFactory" name="jms/QueueConnectionFactory"/>
    <message-destination-ref binding-name="jms/SuccessfulResponseQueue" name="jms/SuccessfulResponseQueue"/>
    <message-destination-ref binding-name="jms/FailedResponseQueue" name="jms/FailedResponseQueue"/>
  </message-driven>

  <message-driven name="Queue2MDB">
    <jca-adapter activation-spec-binding-name="jms/Queue2MQActivationSpec" destination-binding-name="jms/Queue2RequestQueue"/>
    <resource-ref binding-name="jms/QueueConnectionFactory" name="jms/QueueConnectionFactory"/>
    <message-destination-ref binding-name="jms/SuccessfulResponseQueue" name="jms/SuccessfulResponseQueue"/>
    <message-destination-ref binding-name="jms/FailedResponseQueue" name="jms/FailedResponseQueue"/>
  </message-driven>

  <message-driven name="Queue3MDB">
    <jca-adapter activation-spec-binding-name="jms/Queue3MQActivationSpec" destination-binding-name="jms/Queue3RequestQueue"/>
    <resource-ref binding-name="jms/QueueConnectionFactory" name="jms/QueueConnectionFactory"/>
    <message-destination-ref binding-name="jms/SuccessfulResponseQueue" name="jms/SuccessfulResponseQueue"/>
    <message-destination-ref binding-name="jms/FailedResponseQueue" name="jms/FailedResponseQueue"/>
  </message-driven>

  <message-driven name="Queue4MDB">
    <jca-adapter activation-spec-binding-name="jms/Queue4MQActivationSpec" destination-binding-name="jms/Queue4RequestQueue"/>
    <resource-ref binding-name="jms/QueueConnectionFactory" name="jms/QueueConnectionFactory"/>
    <message-destination-ref binding-name="jms/SuccessfulResponseQueue" name="jms/SuccessfulResponseQueue"/>
    <message-destination-ref binding-name="jms/FailedResponseQueue" name="jms/FailedResponseQueue"/>
  </message-driven>
</ejb-jar-bnd>

Это настраивается в ear, который развернут в IBM WAS. Имя-привязки назначения выберет соответствующие подробности очереди из IBM WAS.

И позже, когда я настраивал MDB в моем Java-классе, как показано ниже, прослушивание выполняется во всех очередях одновременно, и сообщения принимаются:

@Resource(name = "jms/QueueContractConnectionFactory")
private ConnectionFactory connectionFactory;

@Resource(name = "jms/FailedResponseQueue")
private Queue errorQueue;

@Resource(name = "jms/SuccessfulResponseQueue")
private Queue responseQueue;

Теперь мне нужно удалить ejb и изменить конфигурации mdb, чтобы он мог развертываться в tomcat.

xml - это нечто, о чем я буквально понятия не имею, как отобразить его без параметров ejb.

Может ли кто-нибудь помочь или поделиться документом о том, как этого добиться? Я хотел бы иметь пример IBM MQ для Spring JMS со спецификацией активации.

Заранее спасибо.

Answer 1

Как уже отмечалось, это не просто вопрос замены WAS на Tomcat, так как это не тот же тип контейнера. Таким образом, вы не можете напрямую развертывать свои артефакты WAS (особенно MDB) непосредственно в Tomcat. Чтобы передать их в Tomcat, их нужно будет переписать.

Будучи MDB, контейнер управляет вами: подключение к серверу JMS, маршрутизация сообщений из очереди / темы в вашу логику, обработка многопоточных сообщений (обработка более одного сообщения в очереди одновременно) и, большинство в частности, управление транзакциями.

Теперь обработка сообщений в JMS довольно проста. Вы можете легко подключиться к JMS. Вы можете скопировать пример из сети и заставить его работать. Запуск обработки в фоновом режиме прост, есть примеры этого. JMS 2.0 проще в использовании, чем JMS 1.x. Нет причин не портировать на это (если MQ не поддерживает JMS 2.0).

Выполнение нескольких экземпляров логики в транзакционном режиме не так просто, но, возможно, это не очень важный аспект вашей обработки.

Однако, даже если вы смогли заставить все это работать, на данном этапе нет гарантии, что ваша логика будет работать напрямую. Мы не знаем, вызывает ли ваша логика другие EJB-компоненты или использует какую-либо другую инфраструктуру Java EE. Если это так, то вам придется портировать и этот аспект вашей логики, а не только подключение MDB.

Итак, это более глубокая проблема. Легко сказать «просто разверните его в Tomcat», но могут быть детали, которые могут его разрушить, и его необходимо учитывать.

Другой способ - преобразовать логику в Spring, поскольку она может легко развернуться в Tomcat. Но это не обязательно проще, чем что-либо еще - все предостережения остаются.

Наконец, «развертывание в Tomcat» в данном случае практически не является следствием, поскольку MDB не являются веб-приложениями, а Tomcat развертывает веб-приложения. Вы можете создать оболочку веб-приложения, в которой нет ничего, кроме размещения вашей логики, управляемой сообщениями. Это легко сделать, я и многие другие использовали злоупотребления жизненными циклами веб-приложений в наших собственных гнусных целях для подобных вещей.

Итак, в конце, я думаю, вам нужно больше ясности относительно того, что на самом деле означает «развертывание в Tomcat», каковы ожидания в конечном итоге, и полагается ли ваша логика сообщений на другую инфраструктуру Java EE и т. Д. Является ли целью работать в Tomcat или не запускаться в WAS (в этом случае, как отмечено в комментариях, есть другие серверы приложений, которые вы могли бы использовать, на которые было бы гораздо проще перейти).

Answer 2

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

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

Получите среду Spring, работающую в приложении, которое вы создали в RAD. Вы сделали это успешно? Просто вставьте любой компонент из контекста приложения и посмотрите, сможете ли вы заставить его работать на WAS. Если вы можете сделать это успешно, это означает, что вы получили преимущество, остальное можно сделать. Дайте мне знать, когда вы дойдете до этого - вставьте свой контекст приложения или конфигурацию здесь. Я могу сказать вам, что делать дальше. Помните, вам не нужно сразу переключаться на tomcat - ваша цель должна состоять в том, чтобы заменить MDB пружинным компонентом, который может прослушивать сообщения, - и это может работать на WAS.

Answer 3

Есть одна вещь, о которой вы должны знать в отношении Websphere MQ. Пул соединений с классами MQ для JMS поддерживается только через сервер приложений Websphere. Когда вы переходите на Tomcat, вы можете столкнуться с ухудшением производительности и вам, возможно, придется реализовать некоторую сумму пула. Я думаю, что весна может помочь в этом отношении. Я процитирую это из документации IBM

public void setUseConnectionPooling (логическое использованиеPooling)

Запрещены. JMS больше не использует пул соединений. любой объединение соединений должно осуществляться с использованием средств, предоставляемых Сервер приложений. Установите использование ConnectionPooling в более ранних версиях классы IBM MQ для JMS. Этот метод сохранен для совместимости со старыми приложениями MQJMS, но, потому что это пул соединений функциональность была удалена из версии 7, установив это свойство не будет иметь никакого эффекта.

https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_9.0.0/com.ibm.mq.javadoc.doc/WMQJMSClasses/com/ibm/mq/jms/MQConnectionFactory.html#setUseConnectionPooling-boolean-

Я думаю, что ваш лучший способ - запустить приложение WAS, а затем переключиться на Tomcat. Как только вы перейдете к весне, это будет кусок пирога для переключения. Он должен быть независимым от контейнера. В Интернете есть множество отзывов о том, как перенести Java EE в весенние приложения. Это упражнение было сделано в течение многих лет (так как весна существует:).

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