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

// Производитель
@Inject
@JMSConnectionFactory("jms/connectionFactory")
@JMSSessionMode(JMSContext.AUTO_ACKNOWLEDGE)
private JMSContext context;
…
context.createProducer(). send(queue, message);

··// Потребитель
message.acknowledge();

Создание стойких потребителей

Недостатком использования модели pub-sub является то, что потребитель сообщения должен быть запущен, когда сообщение отправляется в тему, — в противном случае он его не получит. С помощью стойких потребителей JMS API предоставляет способ сохранить сообщения в теме, пока все подписчики не получат их. Используя такой способ подписки, потребитель может находиться в автономном режиме в течение некоторого времени, но, когда он подключится, он получит сообщения, которые прибыли за время его отсутствия. Чтобы достичь этого, клиент создает стойкого потребителя с использованием JMSContext:

context.createDurableConsumer(topic, "javaee7DurableSubscription"). receive();

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

Определение приоритетов

Вы можете использовать уровни приоритета, чтобы указать поставщику JMS доставлять срочные сообщения в первую очередь. JMS определяет десять значений приоритета, начиная с 0 (самый низкий) и заканчивая 9 (самый высокий). Вы можете задать значение приоритета с помощью метода setPriority() JMSProducer:

context.createProducer(). setPriority(2). send(queue, message);

Большинство этих методов возвращают JMSProducer. Это позволяет объединять вызовы методов, что дает возможность использовать «текучий» стиль программирования. Например:

context.createProducer(). setPriority(2)
························.setTimeToLive(1000)
························.setDeliveryMode(DeliveryMode.NON_PERSISTENT)
························.send(queue, message);

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

До сих пор в этой главе демонстрировалось, как асинхронный обмен сообщениями обеспечивает слабую связанность и повышенную гибкость между системами с использованием JMS API. Компоненты, управляемые сообщениями (MDB), обеспечивают стандарт этой модели асинхронных сообщений для промышленных приложений, работающий в контейнере EJB.

MDB — это асинхронный потребитель, который вызывается контейнером в результате прихода сообщений. Для поставщика сообщений MDB являются простым потребителем сообщений, скрытым за местом назначения, которое они слушают.

MDB — часть спецификации EJB, и их модель близка к модели сессионных компонентов, поскольку они не имеют состояния и работают внутри контейнера EJB. Контейнер слушает место назначения и делегирует вызов MDB по мере прибытия сообщений. Как и любой другой EJB, MDB могут получить доступ к ресурсам, управляемым контейнером (другие EJB, соединения JDBC, ресурсы JMS, диспетчер объектов и т. д.).

Зачем использовать MDB, когда можно задействовать отдельные клиенты JMS, как мы уже видели ранее? Это следует делать, так как контейнер управляет многопоточностью, безопасностью и операциями, что существенно упрощает код вашего потребителя JMS. Он также управляет входящими сообщениями для нескольких экземпляров MDB (доступных в хранилище), которые сами по себе не имеют специального кода для работы с многопоточностью. Как только новое сообщение достигнет места назначения, экземпляр MDB извлекается из хранилища для обработки сообщения. Простой потребитель MDB показан в листинге 13.9.

Листинг 13.9. Простой потребитель MDB

@MessageDriven(mappedName = "jms/javaee7/Topic")
public class BillingMDB implements··MessageListener {

··public void onMessage(Message message) {
····System.out.println("Сообщение получено: " + message.getBody(String.class));
··}
}

Данный код (обработка исключений опущена для простоты) показывает, что использование MDB освобождает программиста от всех механических аспектов обработки типов сообщений, которые объяснялись ранее. MDB реализуют интерфейс MessageListener и метод onMessage(), при этом не нужен никакой другой код для подключения к провайдеру или начала потребления сообщений. MDB также полагаются на механизм конфигурации с помощью исключений, и необходимо только несколько аннотаций, чтобы он работал (см. аннотацию @MessageDriven).

Структура MDB

MDB отличаются от сессионных компонентов, поскольку не реализуют локальные или удаленные бизнес-интерфейсы. Вместо этого они реализуют интерфейс javax.jms.MessageListener. Клиенты не могут вызывать непосредственно методы MDB, однако, как и в случае сессионных компонентов, MDB имеют богатую модель программирования, которая включает в себя жизненный цикл, аннотации функций обратного вызова, перехватчики, внедрение и транзакции. Использование этой модели предоставляет приложению больше функциональности.

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