Изучаем Java EE 7 - [199]

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

Компоненты, управляемые сообщениями (Message-Driven Beans, MDB) являются асинхронными потребителями сообщений, которые выполняются внутри контейнера EJB. Как вы уже знаете из глав 7–9, контейнер EJB выполняет несколько задач (транзакции, безопасность, параллельный доступ, подтверждение сообщений и т. д.), а MDB фокусируются на потреблении сообщений. MDB не сохраняют свое состояние, что означает, что контейнер EJB может иметь множество их объектов, которые выполняются параллельно, для обработки сообщений, приходящих от различных производителей. Даже если они выглядят как компоненты, не сохраняющие состояние, клиентские приложения не могут получить доступ непосредственно к MDB; единственный способ общения с MDB — отправить сообщение по месту назначения, которое слушают MDB.

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

Обзор спецификаций обмена сообщениями

Обмен сообщениями в Java представлен в основном JMS, который может использоваться в приложениях, работающих в стандартном (Java SE) или производственном (Java EE) окружении. MDB предоставляют простой способ для сессионных EJB, не сохраняющих свое состояние, являться потребителями сообщений и быть связанными со спецификацией EJB.

Краткая история обмена сообщениями

Вплоть до конца 1980-х годов компании не имели простого способа связи для разных приложений. Разработчикам приходилось писать отдельные адаптеры для систем, чтобы преобразовать данные одного формата в другой, который смогла бы распознать система на месте назначения (и наоборот). Из-за несоответствия возможностей серверов и требований к ним были созданы буферы, позволившие ослабить связывание при обработке так, что общее время обмена сообщениями не увеличилось. Отсутствие однородных транспортных протоколов породило низкоуровневые адаптеры протоколов. К концу 1980-х годов стало появляться промежуточное программное обеспечение, которое решило этот вопрос интеграции. Первые MOM были созданы как отдельное программное обеспечение, которое может располагаться между приложениями и управлять «связыванием» систем. Они были в состоянии управлять разными платформами, языками программирования, сетевыми протоколами и аппаратными средствами.

Спецификация JMS была впервые опубликована в августе 1998 года. Она была создана основными поставщиками промежуточного программного обеспечения, чтобы организовать возможность обмена сообщениями в Java. В JSR 914 произошли незначительные изменения (JMS 1.0.1, 1.0.2 и 1.0.2b), что позволило наконец достичь версии 1.1 в апреле 2002 года. JMS 1.1 был интегрирован в J2EE 1.2 и с тех пор стал частью Java EE. Тем не менее JMS и MDB не являются частью спецификации Web Profile. Это означает, что они доступны только на серверах приложений, реализующих полную платформу Java EE 7.

Что нового в JMS 2.0

JMS 1.1 не изменялись в течение более чем десяти лет. Все API Java EE 5, за исключением JMS, медленно модернизировались, чтобы соответствовать изменениям языка (аннотации, обобщенные типы…). Настало время и для JMS следовать по тому же пути, использовать аннотации и упрощать API. Действительно, в JMS API были внесены некоторые изменения, чтобы сделать его проще в использовании:

• Connection, Session и другие объекты с методом close() теперь реализуют интерфейс java.jang.AutoCloseable, чтобы их можно было использовать в утверждении try-with-resources в Java SE 7;

• добавлен новый «упрощенный API», который предлагает более простую альтернативу стандартному и устаревшему API;

• внедрен новый метод getBody, что позволяет приложению извлечь тело непосредственно из объекта класса Message без необходимости преобразовать его к соответствующему подтипу;

• создан набор новых непроверенных исключений, которые наследуются от типа JMSRuntimeException;

• добавлены новые методы, позволяющие приложению отправлять сообщения асинхронно.

Что нового в EJB 3.2

В EJB 2.0 были введены MDB, которые были улучшены в EJB 3.0, следуя общей парадигме Java EE 5 «простота использования». Они не изменились внутренне, поскольку продолжали быть потребителями сообщений, но введение аннотаций и конфигурации с помощью исключений упростило их создание. Новая спецификация EJB 3.2 (JSR 345) привнесла некоторые изменения в MDB, добавив больше портативной конфигурации (подробнее об этом — позже).

Как вы узнали из главы 7, асинхронные вызовы в настоящее время возможны в рамках сессионных компонентов, не сохраняющих состояния (с помощью аннотации @Asynchronous). В предыдущих версиях Java EE нельзя было осуществить асинхронный вызов между EJB. Таким образом, единственным возможным способом было применять JMS и MDB — это дорогое решение, поскольку используется много ресурсов (место назначения JMS, соединения, фабрики и т. д.), только чтобы вызвать метод асинхронно. Сегодня асинхронные вызовы возможны между сессионными компонентами без необходимости использования MDB, позволяя им сосредоточиться на интеграции систем на основе обмена сообщениями.