что такое jms java
Работа с JMS сообщениями и MDB в JEE
Работа с сообщениями подразумевает взаимодействие между компонентами системы посредством передачи сообщений. JMS позволяет реализовать это взаимодействие в java приложении, а MDB бины позволяют асинхронно обрабатывать получаемые сообщения на сервере приложений без дополнительных усилий по асинхронной обработке.
Ниже представлен простой пример обработки JMS сообщения с помощью MDB.
Немного теории
Для работы с сообщениями используется вспомогательное программное обеспечение, обычно входящее в поставку сервера приложений.
Компоненты системы могут посылать сообщения (producer) и получать их (consumer). Сообщение
отправляет producer на пункт назначения (destination), являющимся на сервере queue или topic, после чего consumer может забрать оттуда сообщение
В зависимости от того, какой тип имеет destination, разделяют две модели работы с сообщениями.
Первая модель — Point-to-Point
В случае если на сервере destination имеет тип queue, то сообщение, которое отправил producer, получает единственный consumer. Если на эту очередь сообщений подписано несколько получателей, то сообщение получит только один из них.
Вторая модель — Publish-subscribe
В случае если на сервере destination имеет тип topic, то одно сообщение может быть прочитано неограниченным количеством consumer, подписанных на этот на этот destination.
Структура JMS сообщения
Сообщение состоит из заголовка, поля свойств и тела.
Заголовок хранит мета информацию сообщения, заполняемую автоматически.
Поле свойств схоже с заголовком, но оно заполняется программно, и позже получатель сможет прочитать эту информацию.
Тело содержит полезную нагрузку сообщения. Тип нагрузки определяется при создании сообщения. Конкретные типы унаследованы от интерфейса javax.jms.Message
Создание очереди на сервере.
Для примера создадим topic на сервере. Использовать я буду glassfish 3.1.
Для начала создадим Connection Factory. Возможны несколько типов в зависимости от того, какой тип очереди сообщений будет использоваться.
Затем создаем destination с указание типа.
Создание отправителя сообщений
В данном случае producer будет находиться на сервере приложений. В случае если вам необходимо отправлять сообщения из отдельного клиента, то необходимо будет стандартным образом получить доступ к объектам по их JNDI имени из контекста.
Message-Driven Bean
Для обработки приходящих сообщений на сервере мы будем использовать MDB.
Сообщения можно было бы получать и обрабатывать и с помошью pojo, выступающего как consumer. Но использование MDB позволит параллельно обрабатывать сообщения, не заботясь о сложности асинхронной обработки и дополнительного кода для подписки на очередь сообщений.
Асинхронная обработка реализуется через пул объектов, из которых на обработку сообщения сервер выделят объекты при необходимости.
Для реализации MBD достаточно унаследовать бин от интерфейса javax.jms.MessageListener, реализуя метод onMessage(), и аннотировать соответствующим образом класс.
Сделаем пример MDB, который выводит в консоль сервера информацию о поступившем сообщении.
В onMessage метод добавляется необходимая бизнес логика, в зависимости от типа сообщения, его содержания и тд.
При необходимости, для ручной обработки сообщений можно самостоятельно создать обработчика.
Например так:
Для более подробного изучения JMS и EJB в целом, могу рекомендовать книги:
EJB 3 in Action — Debu Panda, Reza Rahman, Derek Lane
Пару книг от Adam Bien
Знакомство с JMS 2.0
Не так давно, 12 июня 2013, миру был представлен релиз Java EE 7. Одним из ключевых моментов в этом релизе было появление JMS версии 2.0, которая не обновлялась с 2002 года.
Данный текст является вольным переводом начала статьи Найджела Дикина. Текст предназначен для ознакомления заинтересованного читателя с новым API.
API JMS 1.1 требует для работы достаточно много кода, но успело себя хорошо зарекомендовать, потому, с 2002 года не изменялось. В JMS 2.0 новое API призвано упростить отправку и прием JMS-сообщений. Прежнее API не упраздняется и продолжает работать наравне с новым.
В API JMS 2.0 появились новые интерфейсы: JMSContext, JMSProducer и JMSConsumer.
Отправка JMS
Для сравнения. JMS 1.1:
Отличительной особенностью нового API является то, что его методы бросают RuntimeException — JMSRuntimeException, вместо checked-исключения JMSException. Это дает возможность при желании не обрабатывать JMS-исключения.
Синхронное получение JMS
Сравниваем разницу при синхронном получении сообщений.
JMS 1.1:
Асинхронное получение JMS
В JavaSE, что бы получать сообщения асинхронно, в JMS 1.1 используется следующий код:
В JMS 2.0 это выглядит так:
Вместо MessageConsumer — JMSConsumer. Соединение стартует автоматически.
В Java EE Web или EJB приложениях, как и прежде, надо использовать message-driven bean, вместо метода setMessageListener
Вставка объекта JMSContext в Java EE приложении
В Java EE приложении JMSContext можно вставить посредством аннотации Inject. После вставки JMSContext будет находиться под управлением сервера приложений.
Следующий фрагмент кода позволяет вставлять JMSContext в session bean или сервлет.
Закрытие JMSContext производится автоматически сервером приложений. Если во время запроса выполняется JTA-транзакция, то JMSContext закроется автоматически после коммита, если без транзакции, то закроется в конце запроса.
На этом я решил остановиться. Для ознакомления и начала работы этой информации должно быть достаточно. Много детаей и дополнительной информации тут:
What’s New in JMS 2.0, Part One: Ease of Use
What’s New in JMS 2.0, Part Two—New Messaging Features
Русские Блоги
Руководство по началу работы с JMS (Служба сообщений Java)
Читать каталог
Что такое служба сообщений Java
Зачем тебе JMS
В JAVA, если два приложения не понимают друг друга или даже эти две программы могут быть развернуты на разных континентах, как они отправляют сообщения между ними? Например, приложение A развернуто в Индии, другое приложение развернуто в Соединенных Штатах, и затем, когда A запускает что-то, B хочет получить обновленную информацию от A. Конечно, также возможно, что более одной B интересуется обновленной информацией A, и может быть N приложений, подобных B, которые хотят получить обновленную информацию от A.
JMS также подходит для приложений, основанных на событиях, таких как службы чата, и требует механизма публикации событий для отправки сообщений всем клиентам, подключенным к серверу. JMS отличается от RMI. При отправке сообщения получателю не нужно быть в сети. Сервер отправляет сообщение, а затем игнорирует его, и когда клиент подключается к сети, он может убедиться, что сообщение, отправленное сервером, получено. Это очень мощное решение, которое может решить многие распространенные проблемы в современном мире.
Преимущества JMS
асинхронный
JMS по своей сути асинхронный: когда клиент получает сообщение, ему не нужно активно отправлять запрос, и сообщение автоматически отправляется доступному клиенту.
надежный
JMS гарантирует, что сообщение будет доставлено только один раз. Каждый сталкивался с проблемой повторного создания сообщений, и JMS может помочь вам избежать этой проблемы.
Модель обмена сообщениями JMS
До появления JMS API большинство продуктов использовали для передачи сообщений методы «точка-точка» и «публикация / подписка». JMS определяет спецификации этих двух моделей обмена сообщениями, которые не зависят друг от друга. Любой JMS-провайдер может реализовать одну или обе эти модели по своему выбору. Спецификация JMS предоставляет общий интерфейс, чтобы гарантировать, что наши программы, основанные на JMS API, подходят для любой модели.
Давайте рассмотрим эти две модели обмена сообщениями более подробно:
Модель обмена сообщениями точка-точка
В модели обмена сообщениями точка-точка приложение состоит из очереди сообщений, отправителя и получателя. Каждое сообщение отправляется в специальную очередь сообщений, в которой хранятся все отправленные ему сообщения (кроме сообщений, полученных и истекших получателем). Модель сообщений «точка-точка» имеет следующие особенности:
Модель публикации / подписки на сообщения
В модели сообщений публикации / подписки издатель публикует сообщение, которое передается всем клиентам через тему. В этой модели издатели и подписчики не знают друг друга, являются анонимными и могут динамически публиковать и подписываться на темы. Тема в основном используется для сохранения и доставки сообщений и будет сохранять сообщения до тех пор, пока сообщение не будет доставлено клиенту.
Характеристики модели сообщения публикации / подписки следующие:
Чтобы облегчить такую строгую корреляцию времени, JMS позволяет подписчикам создавать долговременную подписку. Таким образом, даже если подписчик не активирован (запущен), он может получить сообщение издателя.
Получить сообщение
В JMS сообщения могут быть получены следующими двумя способами:
синхронный
Если сообщение получено синхронно, подписчик сообщения вызывает метод receive (). В receive (), если сообщение не приходит или раньше указанного времени, метод блокируется, пока сообщение не станет доступным.
асинхронный
Чтобы получать сообщения асинхронно, подписчику сообщения необходимо зарегистрировать прослушиватель сообщений, аналогичный прослушивателю событий, до тех пор, пока сообщение поступает, поставщик услуг JMS доставит сообщение, вызвав onMessage () прослушивателя.
Интерфейс программирования JMS
Приложение JMS состоит из следующих основных модулей:
Объекты управления JMS
Эти два объекта управления создаются системным администратором JMS с помощью консоли управления сервера приложений и хранятся в пространстве имен JNDI или в реестре JNDI сервера приложений.
Фабрика соединений (ConnectionFactory)
Клиент использует объект фабрики соединений для соединения с поставщиком услуг JMS, который создает соединение между поставщиком услуг JMS и клиентом. Клиенты JMS (такие как отправители или получатели) будут искать и получать соединение в пространстве имен JNDI. Используя это соединение, клиент может связываться с получателем и отправлять / получать сообщения в очередь или тему. Давайте рассмотрим пример, чтобы понять, как отправить сообщение:
Пункт назначения (назначения)
Пункт назначения указывает пункт назначения, куда отправлено сообщение, и источник, из которого клиент получает сообщение. JMS использует два пункта назначения, очереди и темы. Следующий код определяет очередь и тему.
Создать сеанс очереди
Создать тему Сессия
JMS-соединение
Объект соединения инкапсулирует виртуальное соединение с JMS-провайдером. Если у нас есть объект ConnectionFactory, мы можем использовать его для создания соединения.
После создания соединения его необходимо закрыть после завершения программы:
Сессия JMS
Сеанс представляет собой однопоточный контекст, используемый для создания и потребления сообщений, вы можете создать производителя сообщений и потребителя сообщений.
Объект Session реализует интерфейс Session.После создания соединения мы можем использовать его для создания Session.
Производитель сообщений JMS
Источник сообщений создается сеансом и используется для отправки сообщений в пункт назначения. Производители реализуют интерфейс MessageProducer, и мы можем создавать производителей для пунктов назначения, очередей или тем;
После создания источника сообщения вы можете использовать метод send для отправки сообщения:
Потребитель сообщений JMS
Получатель сообщения создается сеансом для приема сообщений, отправленных адресатом. Потребители реализуют интерфейс MessageConsumer, и мы можем создавать потребителей для пунктов назначения, очередей или тем;
Приемник сообщений JMS
Приемник сообщений JMS является обработчиком событий по умолчанию для сообщений. Он реализует интерфейс MessageListener, который содержит метод onMessage. В этом методе необходимо определить конкретное действие после получения сообщения. Вызывая метод setMessageListener, мы определяем прослушиватель сообщений для указанного потребителя.
Структура сообщения JMS
Клиент JMS использует сообщения JMS для связи с системой. Хотя формат сообщения JMS прост, но очень гибок, сообщение JMS состоит из трех частей:
Заголовок сообщения
Заголовок сообщения JMS предопределяет несколько полей для идентификации и отправки сообщений между клиентом и поставщиком JMS. Предварительно скомпилированные заголовки следующие:
– JMSDestination
– JMSDeliveryMode
– JMSMessageID
– JMSTimestamp
– JMSCorrelationID
– JMSReplyTo
– JMSRedelivered
– JMSType
– JMSExpiration
– JMSPriority
Атрибут сообщения
Мы можем установить пользовательские свойства для сообщения, эти свойства в основном предоставляются приложению. Атрибуты сообщений очень полезны для реализации функций фильтрации сообщений. API-интерфейс JMS определяет некоторые стандартные атрибуты, а поставщики услуг JMS могут дополнительно предоставлять некоторые стандартные атрибуты.
Тело сообщения
В теле сообщения JMS API определяет пять типов форматов сообщений, что позволяет нам отправлять и получать сообщения в различных формах и обеспечивает совместимость с существующими форматами сообщений. Существуют следующие типы сообщений:
Text message⑤: javax.jms.TextMessage, представляющий текстовый объект.
Object message: Javax.jms.ObjectMessage, представляющий объект JAVA.
Bytes message⑤: javax.jms.BytesMessage, представляющий байтовые данные.
Stream message: Javax.jms.StreamMessage, представляющий поток данных исходного значения Java.
Map message• javax.jms.MapMessage, представляющий пары ключ-значение.
Наконец, добавим, что поставщики общих служб JMS с открытым исходным кодом:
Что такое jms java
Служба сообщений Java, JMS, предоставляет межплатформный стандарт для асинхронного обмена бизнес-данными и событиями в предприятии. Обмен информацией обычно происходит между процессами и компьютерами. Объекты в приложениях, обычно работающих на разных компьютерах, обмениваются информацией, обращаясь к службам промежуточного программного обеспечения, ориентированного на работу с сообщениями (MOM), через стандартный набор интерфейсов, определенный в JMS.
JMS предоставляет набор интерфейсов, изолирующих программиста на Java (реализующего поставщики и приемники сообщений) от провайдеров MOM.
Эта страница информационного наполнения описывает основные концепции и типичное применение JMS.
Сообщения
В JMS сообщение инкапсулируется в объект, реализующий интерфейс javax.jms.Message. Программа на Java может обращаться к блокам сообщения через этот интерфейс, как показано на следующей диаграмме. У полезной нагрузки может быть несколько разновидностей, обсуждаемых ниже.
Заголовок содержит обязательные свойства сообщения. Это следующие свойства:
Свойства позволяют прикладному программисту предоставлять метаданные для сообщения. Свойства состоят из произвольного набора пар имя-значение.
JMS поддерживает шесть видов полезной нагрузки:
Типы полезной нагрузки отражены в иерархии классов, в которой интерфейсы расширяют javax.jms.Message. На следующей диаграмме классов показаны часто используемые текстовые, объектные и байтовые сообщения. Текстовые сообщения обычно содержат данные XML.
Места назначения
JMS определяет концепцию места назначения. Сообщения отправляют и получают из мест назначения. Места назначения бывают двух видов:
Доставка сообщений
Доставка сообщений может быть двух типов:
Постоянная доставка предусматривает хранение сообщения в файле или базе данных, что означает гарантированную доставку. Непостоянная доставка выполняется быстрее и не требует таких затрат памяти, но доставка сообщения не гарантируется. В большинстве приложений, работающих с JMS, обычно применяется постоянная доставка.
Клиенты JMS
На следующей диаграмме представлена схема взаимодействия поставщика, приемников и провайдеров JMS.
Поставщиком сообщений может быть любой класс Java, у которого есть доступ к реализации JMS. Поставщики сообщений создают и отправляют сообщения.
Приемником сообщений может быть любой класс Java, у которого есть доступ к реализации JMS. Приемники сообщений принимают и обрабатывают сообщения.
Провайдеры JMS
Дополнительная информация
Дополнительная информация о JMS приведена на Web-сайте http://java.sun.com/products/jms/.
© Copyright IBM Corp. 1987, 2006. Все права защищены.
Использование JMS
JMS является еще одной технологией создания распределенных приложений, основанных на модели обмена сообщениями.
Введение
При разработке JMS в качестве основной задачи рассматривалось создание обобщенного Java API для приложений, ориентированных на работу с сообщениями ( message-oriented application programming ), и обеспечение независимости от конкретных реализаций соответствующих служб обработки сообщений.
Модель обмена сообщениями (и JMS ) удобно использовать в том случае, если распределенное приложение обладает следующими характеристиками:
Архитектура JMS
Архитектура JMS выглядит следующим образом (рис. 13.1):
JMS предоставляет два подхода к передаче сообщений. Первый называется «издание-подписка» ( publish an subscribe ) (рис. 13.3) и используется в том случае, если сообщение, отправленное одним клиентом, должно быть получено несколькими.
Второй подход называется «точка-точка» ( point to point ) (рис. 13.2) и служит для реализации обмена сообщениями между двумя компонентами.
Спецификация JMS называет эти два подхода зонами сообщений ( messaging domains ).
Модель взаимодействия «издание-подписка»
При использовании модели взаимодействия «издание-подписка» один клиент (поставщик) может посылать сообщения многим клиентам (потребителям) через виртуальный канал, называемый темой ( topic ). Потребители могут выбрать подписку ( subscribe ) на любую тему. Все сообщения, направляемые в тему, передаются всем потребителям данной темы. Каждый потребитель принимает копию каждого сообщения. Модель передачи сообщений «издание-подписка», по существу, представляет собой модель сервера, инициирующего соединение и «проталкивающего» информацию на клиента. В JMS эта концепция реализуется с помощью специальных «слушателей» (листенеров), регистрируемых в системе. При возникновении нового события листенер, закрепленный за данной темой, возбуждается.
Следует отметить, что при использовании модели «издание-подписка» клиенты JMS могут устанавливать долговременные подписки, позволяющие потребителям отсоединиться и позже снова подключиться и получать сообщения, поступившие во время отключения связи.