В чем разница между ActivationSpec и ConnectionFactory? - PullRequest
20 голосов
/ 12 сентября 2011

Насколько я понимаю, что:

  • MD B s (управляемые сообщениями компоненты) подключаются через спецификацию активации.
  • MD P s (POJO, управляемый сообщениями) подключаться через фабрику соединений.

Эта диаграмма от IBM полезна:

enter image description here

Для меня это объяснение от IBM не проливает свет на разницу:

  • Фабрика соединений - используется приложением для подключения к шине обмена сообщениями.
  • Очередь - используется приложением для отправки и получения сообщений.
  • Спецификация активации - используется компонентом, управляемым сообщениями приложения, для подключения к очереди и получения сообщений.

Одна реальная разница , которую я обнаружил, заключается в том, что :

Сессионные компоненты и компоненты управления данными (также известные как MDP) позволяют отправлять сообщения JMS и получать их синхронно, но не асинхронно .Чтобы не связывать ресурсы сервера, вы можете предпочесть не использовать блокировку синхронных приемов в компоненте на стороне сервера. Чтобы получать сообщения асинхронно, используйте управляемый сообщениями компонент [MDB].

Итак, неудовлетворительный список, который у меня пока есть:

  • ИспользованиеActivationSpec с MDB и ConnectionFactory с POJO (но подождите, могут ли POJO использовать ActivationSpec тоже ?)
  • MDB работают асинхронно.MBP работают синхронно.

Мой вопрос: есть ли другие различия?Можете ли вы уточнить разницу?

Ссылки:

Ответы [ 3 ]

15 голосов
/ 14 сентября 2011

@ Джеффри Найт: Позвольте мне попытаться уточнить, основываясь на моем опыте.

Мы понимаем, что MDB - это бины для потребления входящих сообщений. Теперь необходимо указать, к какому типу сообщений и из какого пункта назначения требуется обратиться конкретный MDB.

MDB в основном является конечной точкой сообщения.

До соответствия требованиям JCA:

поток в паутине был: -

входящее сообщение -> прослушивается слушателем сообщения -> слушателем порты -> доставить в MDB

Поэтому, как правило, разработчик создает MDB и задает детали назначения сообщения в ejb-jar.xml следующим образом: -

<message-driven-destination>
    <destination-type>javax.jms.Queue</destination-type>
</message-driven-destination>
<res-ref-name>jms/QCF</res-ref-name>
<resource-ref>
    <res-type>javax.jms.QueueConnectionFactory</res-type>
    <res-auth>Container</res-auth>
</resource-ref>

и развертывателю потребуется создать порт прослушивателя и связать развернутый MDB с портом прослушивателя. Указанная выше QueueConnectionFactory создана для создания соединений с очередью.

Опубликовать совместимые с JCA MDB:

После JCA MDB рассматривается как ресурс JCA. Спецификация JCA также включает API-интерфейсы инфраструктуры обмена сообщениями. Поток в случае JCA составляет: -

incoming message --> listened by Message listener --> Resource Adapter-->deliver to MDB

Теперь, поскольку JCA был создан для работы с любым типом ресурсов, будь то JDBC, JMS, EIS и т. Д., У него есть универсальный способ «Activation Spec» для создания конфигураций для любого адаптера. В файле ra.xml упоминается, какая спецификация активации необходима для работы данного адаптера. Спецификация активации - это не объект времени выполнения, это просто сведения о конфигурации, используемые адаптером ресурсов. В вышеуказанном случае адаптер JCA будет использовать соединение с фабрикой соединений очереди, указанной в спецификации активации. Таким образом, фабрика соединений в очереди в обоих случаях одинакова.

В случае websphere вы можете использовать SIB (Service Integration Bus) для обмена сообщениями ИЛИ внешнее программное обеспечение, например websphere MQ для обмена сообщениями.

В случае адресатов SIB для обмена сообщениями : - SIB внедрил адаптер ресурсов JCA. Таким образом, MDB, использующий пункт назначения в SIB, может использовать спецификацию активации для указания деталей пункта назначения. Модуль адаптера ресурсов может взаимодействовать с механизмом обмена сообщениями и доставлять сообщения в MDB.

В случае внешней среды обмена сообщениями, такой как websphere MQ : - Поскольку в websphere MQ не реализован ни один адаптер JCA, нам потребуется настроить порт прослушивателя для подключения к адресатам, расположенным в websphere MQ. Это порт слушателя, который доставит сообщения в MDB.

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

Надеюсь, теперь это прояснится.

12 голосов
/ 20 ноября 2012

Они обе конфигурации, но фабрика соединений используется для исходящих сообщений, а спецификации активации - для входящих сообщений.

Это то, что я получил от IBM.

Спецификации активации являются частью спецификации JCA 1.5. Приложение MDB использует спецификацию активации для подключения к Администратор очередей WebSphere MQ для обработки входящих сообщений. Спецификация активации также предоставляет другие варианты, такие как безопасность настройки.

Фабрика соединений JMS содержит информацию о том, как создать подключение. Когда приложению требуется соединение JMS, фабрика создает экземпляр подключения. Фабрика соединений требует та же информация о соединении, что и в спецификации активации, создан ранее, но используется для исходящих сообщений из MDB, тогда как спецификация активации используется для входящих сообщений.

2 голосов
/ 13 сентября 2011

Клиент ConnectionFactory - это приложение. Приложение использует ConnectionFactory для отправки / извлечения сообщений в / из модуля обмена сообщениями через очередь.

Клиентом ActivationSpec является контейнер EJB. Контейнер EJB получает ActivationSpec для регистрации MessageEndpointFactory для MDB или MDP с помощью ResourceAdapter. Когда клиент отправляет сообщение в модуль обмена сообщениями, модуль обмена сообщениями будет использовать зарегистрированный MessageEndpointFactory для пересылки сообщения в приложение (например, MDB или MDP). Это позволяет приложению «асинхронно» получать сообщения, а не требовать от клиента опроса или блокировки попыток извлечь сообщение из очереди.

...