Что такое бин, управляемый сообщениями?

Бин, управляемый сообщениями, — это Enterprise-бин, который позволяет приложениям Java EE асинхронно обрабатывать сообщения. Этот тип компонента обычно действует как слушатель сообщений JMS, что аналогично слушателю событий, только вместо событий — сообщения JMS. Сообщения могут отправляться любым компонентом Java EE (клиентским приложением, другим Enterprise-бином или веб-компонентом) или приложением или системой JMS, которые не используют технологию Java EE. Управляемые сообщениями Managed-бины могут обрабатывать сообщения JMS или другие виды сообщений.

Здесь рассматриваются следующие темы:

Что отличает бины, управляемые сообщениями, от сессионных?
Когда использовать бины, управляемые сообщениями

Что отличает бины, управляемые сообщениями, от сессионных?

Наиболее заметное различие между компонентами, управляемыми сообщениями, и сессионными компонентами заключается в том, что клиенты не получают доступ к компонентам, управляемым сообщениями, через интерфейсы. Интерфейсы описаны в разделе Доступ к Enterprise-бинам. В отличие от сессионного компонента, управляемый сообщениями компонент имеет только класс компонента.

В некотором отношении управляемый сообщениями компонент напоминает сессионный компонент без сохранения состояния.

Объекты компонента, управляемого сообщениями, не сохраняют данные или состояние диалога для конкретного клиента.
Все объекты бина, управляемого сообщениями, эквивалентны, что позволяет контейнеру EJB назначать сообщение любому из них. Контейнер может объединять эти объекты в пулы для одновременной обработки потоков сообщений.
Один управляемый сообщениями компонент может обрабатывать сообщения от нескольких клиентов.

Переменные компонента, управляемого сообщениями, могут содержать некоторое состояние при обработке клиентских сообщений, например, соединение JMS API, соединение с открытой базой данных или ссылка на объект Enterprise-бина.

Клиентские компоненты не используют поиск JNDI для доступа к управляемым сообщениями компонентам и не вызывают их методы непосредственно. Вместо этого клиент получает доступ к бину, управляемому сообщениями, например, через JMS, отправляя сообщения в пункт назначения сообщений, для которого класс бина, управляемого сообщениями, является MessageListener. Вы назначаете пункт назначения бина, управляемого сообщениями, во время развёртывания, используя ресурсы GlassFish Server.

Бины, управляемые сообщениями, имеют следующие характеристики.

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

Когда приходит сообщение, контейнер вызывает метод onMessage объекта, управляемого сообщениями, для обработки сообщения. Метод onMessage обычно преобразует сообщение в один из пяти типов сообщений JMS и обрабатывает его в соответствии с бизнес-логикой приложения. Метод onMessage может вызывать вспомогательные методы или может вызывать сессионный компонент для обработки информации в сообщении или для сохранения её в базе данных.

Сообщение может быть доставлено управляемому сообщениями компоненту в контексте транзакции, поэтому все операции в методе onMessage являются частью одной транзакции. Если обработка сообщения откатывается, сообщение будет доставлено. Для получения дополнительной информации см. Асинхронный приём сообщений с использованием бина, управляемого сообщениями и главу 55 «Транзакции».

Когда использовать бины, управляемые сообщениями

Сессионные компоненты позволяют отправлять сообщения JMS и получать их синхронно, но не асинхронно. Чтобы не связывать ресурсы сервера, не используйте блокирующее синхронное получение в серверных компонентах. В общем, сообщения JMS не должны отправляться или приниматься синхронно. Для асинхронного получения сообщений используйте бин, управляемый сообщениями.