JMS и переносимость

Я хотел бы знать, какие методы лучше всего подходят для обеспечения переносимости MDB. Я работаю над приложением, которое использует ConnectionFactory, а также Queue и Topic. При тестировании приложения на некоторых серверах приложений (в основном Glassfish 3.1.2.2 и JBoss EAP 6.1) я обнаружил, что ресурс имеет следующую аннотацию:

@Resource(name="jms/myConnectionFactory", lookup="java:/jms/myConnectionFactory")
private ConnectionFactory myConnectionFactory;

@Resource(name="jms/myTopic", lookup="java:/jms/myTopic")
private Topic myTopic;

Я где-то читал, что использование свойства mappedName в @Resource считается не переносимым, поскольку оно специфично для AS. Но я также борюсь с вышеупомянутым подходом, фактически работая над Glassfish, но не в JBoss. Существует ли действительно переносимый подход к определению объектов JMS?

Большое спасибо.


person fabpicca    schedule 03.06.2013    source источник


Ответы (2)


Например, если вы перейдете с WebSphere MQ API на обычный JMS, вы можете обнаружить, что в MQ есть некоторые специальные функции, которые не сопоставляются с JMS.

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

Если вы используете очереди JMS без сервера приложений (= без JNDI), обычно различаются только способы подключения.

Если вы используете очереди JMS на сервере приложений (= используя JNDI), обычно отличается только имя JNDI.

В случае MDB я предпочитаю настраивать фабрику соединений в конкретных файлах дескриптора сервера приложений (а не в исходном коде), чтобы разделить исходный код и конфигурацию. В любом случае ответственность за настройку приложения лежит на центре обработки данных. Это может помочь создать разные пакеты для разных сред и/или серверов приложений.

person Beryllium    schedule 03.06.2013
comment
Я предполагаю, что разделение исходного кода и конфигурации определенно является хорошим подходом. Как вы сказали, использование специфичных для AS дескрипторов развертывания очень помогает поддерживать исходный код чистым и по-настоящему переносимым. Я должен сказать, что очень жаль не использовать аннотации для ресурсов. - person fabpicca; 03.06.2013

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

Проблема JBoss в том, что он поддерживает их только в версии 8.0.

person 2020    schedule 03.06.2013