Основные понятия JMS API
В этом разделе представлены основные понятия JMS API, необходимые для написания простых приложений-клиентов, использующих JMS API.
В следующем разделе представлена программная модель JMS API. В последующих разделах рассматриваются более сложные понятия, включая необходимые для написания приложений, использующих управляемые сообщениями бины.
Здесь рассматриваются следующие темы:
Архитектура JMS API
Приложение JMS состоит из следующих частей.
-
Провайдер JMS — это система обмена сообщениями, которая реализует интерфейсы JMS и предоставляет функции администрирования и управления. Реализация платформы Java EE, поддерживающая полный профиль, включает провайдера JMS.
-
JMS-клиенты — это программы или компоненты Java, отправляющие и получающие сообщения. Любой компонент приложения Java EE может выступать в качестве клиента JMS.
Приложения Java SE также могут выступать как клиенты JMS. Руководство разработчика по очереди сообщений для клиентов Java в документации сервера GlassFish (
https://javaee.github.io/glassfish/documentation) объясняет, как это сделать. -
Сообщения — это объекты, которые передают информацию между клиентами JMS.
-
Администрируемые объекты — это объекты JMS, настроенные для использования клиентами. Два вида администрируемых объектов JMS — пункты назначения и фабрики соединений — описаны в Администрируемые объекты JMS. Администратор может создавать объекты, доступные всем приложениям, использующим конкретную установку сервера GlassFish. Альтернативно, разработчик может использовать аннотации для создания объектов, специфичных для конкретного приложения.
Рисунок 48-2 иллюстрирует взаимодействие этих частей. Административные инструменты или аннотации позволяют связывать пункты назначения и фабрики соединений с пространством имён JNDI. Затем клиент JMS может использовать инъецирование ресурсов для доступа к администрируемым объектам в пространстве имён, а затем установить логическое соединение с теми же объектами через провайдер JMS.
Стили сообщений
До появления JMS API большинство продуктов обмена сообщениями поддерживали стиль обмена сообщениями «точка-точка» или «публикация-подписка». Спецификация JMS определяет соответствие для каждого стиля. Провайдер JMS должен реализовать оба стиля, а JMS API предоставляет интерфейсы, специфичные для каждого из них. В следующих подразделах описываются эти стили сообщений.
Однако JMS API делает ненужным использование только одного из двух стилей. Он позволяет использовать один и тот же код для отправки и получения сообщений, используя стиль "точка-точка" или "публикация-подписка". Используемые пункты назначения остаются специфичными для каждого стиля, и поведение приложения отчасти будет зависеть от того, используется ли очередь или тема (topic). Однако сам код может быть общим для обоих стилей, что делает ваши приложения гибкими и пригодными для повторного использования. В этом руководстве описывается и иллюстрируется этот подход к кодированию с использованием значительно упрощённого API, предоставляемого JMS 2.0.
Стиль обмена сообщениями "Точка-точка"
Продукт или приложение "точка-точка" основаны на концепции очередей сообщений, отправителей и получателей. Каждое сообщение адресовано определённой очереди, и получающие клиенты извлекают сообщения из очередей, созданных для хранения сообщений. Все отправленные сообщения сохраняются в очереди до тех пор, пока не будут извлечены или не истечёт время их хранения.
Обмен сообщениями "точка-точка", показанный на рисунке 48-3, имеет следующие характеристики.
-
Каждое сообщение имеет только одного потребителя.
-
Получатель извлекает сообщение независимо от того, был ли он запущен в момент отправки сообщения клиентом.
Используйте сообщения "точка-точка" в том случае, когда каждое отправленное сообщение предназначено только одному потребителю.
Стиль обмена сообщениями "публикация-подписка"
В продукте или приложении "публикации-подписки" клиенты направляют сообщения в тему, которая работает как доска объявлений. Издатели и подписчики могут динамически публиковать или подписываться на тему. Система заботится о распределении сообщений, поступающих от нескольких издателей темы, к нескольким её подписчикам. Темы сохраняют сообщения ровно столько времени, сколько требуется для их распространения среди подписчиков.
При обмене сообщениями "публикация-подписка" важно различать потребителя, который подписывается на тему (подписчик), и создаваемую подписку. Потребитель — это объект JMS в приложении, а подписка — это объект в провайдере JMS. Обычно тема может иметь много потребителей, но подписка имеет только одного подписчика. Однако можно создавать общие подписки. Смотрите Создание общих подписок для подробностей. См. Использование сообщений из тем для получения подробных сведений о семантике сообщений "публикация-подписка".
Обмен сообщениями "публикация-подписка" имеет следующие характеристики.
-
Каждое сообщение может иметь несколько потребителей.
-
Клиент, подписывающийся на тему, может получать только сообщения, отправленные после создания подписки, и потребитель должен продолжать оставаться активным, чтобы он мог принимать сообщения.
JMS API в некоторой степени смягчает это требование, позволяя приложениям создавать долговременные подписки, которые получают сообщения, отправленные при неактивности потребителей. Долговременные подписки обеспечивают гибкость и надёжность очередей и позволяют клиентам отправлять сообщения многим получателям. Для получения дополнительной информации о долговременных подписках см. Создание долговременных подписок.
Используйте сообщения "публикация-подписка", если каждое сообщение может быть обработано неопределённым количеством потребителей. Рисунок 48-4 иллюстрирует сообщения "публикация-подписка".
Получение сообщений
Продукты для обмена сообщениями по своей сути асинхронны: нет фундаментальной временнóй зависимости между отправкой и получением сообщения. Однако спецификация JMS использует более точный смысл этого термина. Сообщения могут быть использованы одним из двух способов.
-
Синхронно: потребитель явно извлекает сообщение из пункта назначения, вызывая метод
receive. Методreceiveможет блокировать до тех пор, пока не прибудет сообщение или не истечёт время ожидания, если сообщение не поступило в течение указанного периода времени. -
Асинхронно: клиентское приложение или клиент Java SE могут зарегистрировать слушатель сообщений у потребителя. Слушатель сообщений похож на слушатель событий. Всякий раз, когда сообщение поступает в пункт назначения, провайдер JMS доставляет сообщение, вызывая метод
onMessageслушателя, который обрабатывает содержимое сообщения. В приложении Java EE компонент, управляемый сообщениями, служит в качестве приёмника сообщений (он также имеет методonMessage), но клиенту не нужно регистрировать его у потребителя.
