Что такое jms java
Знакомство с 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 приложении
JMS (Java Message Service) является стандартом обмена сообщениями между приложениями. Java приложения, выполненные по технологии Java SE (standalone) или Java EE (WEB) могут создавать, отправлять и получать JMS сообщения. Программное обеспечение, используемое для передачи сообщений между приложениями по стандарту JMS, формирует очереди сообщений queue.
Отправка сообщений java-приложениями выполняется в асинхронном режиме, т.е. процедура не ждет ответа от получателя. В качестве получателей сообщений, организующих очереди (queue), может быть либо программное обеспечение типа WebSphere MQ, связывающее приложения через канал обмена сообщениями, либо WEB-контейнер типа JBoss, GlassFish, обеспечивающих обмен сообщениями между приложениями контейнера, либо по каналам Интернета с использованием JNDI.
Получение сообщений java-приложением осуществляется либо по «подписке» (технология «издатель-подписчик»), либо из очереди («точка-точка»). Для получения сообщений по подписке необходимо должным образом подключиться к соответствующей очереди. При появлении в очереди сообщений они отправляются всем подписчикам. В модели «точка-точка» для получения сообщений необходимо периодически подключаться к соответствующей очереди и читать в ней сообщения.
В статье рассматриваются примеры отправки и получения сообщений с использованием как WEB-приложения (Java EE), так standalone приложения (Java SE). Описание примеров разделено на две части. На этой странице рассматривается взаимодействие WEB-приложения с провайдером HornetQ. Взаимодействие standalone Java приложения с Websphere MQ рассматривается здесь.
Пример обмена сообщения с сервером JBoss
В первом простейшем WEB-приложении «jms-jboss» для отправки и получения JMS сообщений в качестве контейнера будет использован сервер приложений Wildfly версии 8.2 (ранее JBoss Application Server или JBoss AS).
Настройка сервера приложений Wildfly
Чтобы использовать Wildfly для обмена сообщениями JMS необходимо настроить его файл конфигурации
Для примера достаточно было добавить один элемент ‘ ‘, который работает внутри контейнера. Второй элемент «java:jboss/exported/jms/queue/test» может работать за пределами контейнера, т.е. из другой JVM. Для него обязательным условием является определение в начале наименования «java:jboss/exported/». Можно было бы конечно использовать и существующие очереди (ExpiryQueue и DLQ).
Примечание :
DLQ (Dead Letter Queue) – это локальная очередь, называемая инача как очередь недоставленных сообщений. Такую очередь создают для каждого менеджера очередей, чтобы отлавливать неотправленные сообщения, связанные с проблемами в сети или у получателя.
Если не создать DLQ, то ошибки в приложениях могут отключать каналы. В этом случае не только прекратится получение сообщений в очереди, но может нарушиться работа и провайдера MQ, к примеру, не будут получены и выполнены команды администратора. Рекомендуется проектировать приложения таким образом, чтобы избегать подобных сценариев. Кроме того, следует проводить мониторинг DLQ, поскольку поступающие в эту очередь сообщения чаще всего содержат ошибки.
Чтобы стартовать Wildfly с файлом конфигурации standalone-full.xml из IDE Eclipse необходимо открыть окно ‘JBoss Runtime’ и определить значение ‘Configuration file’. Для этого откройте вкладку Servers (Perspective ‘Java EE’) и дважды щелкните мышью на сервере Wildfly. В открывшемся окне Overview нажмите на ссылку ‘Runtime Enviroment’, в результате чего будет открыто окно ‘JBoss Runtime’ :
В конце страницы приведен Log сервера Wildfly, в котором показано создание соответствующих очередей и подключение MDB-объекта приложения к адаптеру HornetQ для получения JMS сообщений по подписке.
Описание примера
На следующем скриншоте приведена структура WEB-приложения jms-jboss, включающего :
Проект в среде IDE Eclipse с использованием maven представлен на следующем скриншоте.
Листинг сервлета ServiceServlet
Сервлет ServiceServlet вызывается со страницы index.jsp из браузера с использованием jQuery. В качестве параметров сервлет получает ‘prefix’ сообщения и команду ‘mode’. Для отправки JMS сообщения сервлет использует метод sendMessage класса Sender. Отправленные сообщения сервер Wildfly сразу же возвращает подписчику Receiver. Полученные сообщения сервлет читает из статической коллекции Receiver.messages, после чего очищает её.
Отправленные и полученные сообщения сервлет оформляет в виде HTML-кода и возвращает в браузер.
Листинг дескриптора приложения, web.xml
В дескрипторе приложения web.xml описывается сервлет ServiceServlet и его URL (url-pattern) для вызова, а также открываемая по умолчанию страница приложения.
Листинг класса отправителя сообщений Sender
Класс отправителя создается и «живет» вместе с WEB-приложением согласно аннотации @ApplicationScoped. При инсталляции сразу же определяются context и очередь queue. Сервлет отправляет текстовые сообщения, вызывая метод sendMessage.
Листинг получателя сообщений Receiver
Здесь следует несколько слов сказать о MDB (Message Driven Beans). Объект MDB используется для поддержки асинхронных коммуникаций в приложении, как правило, в сочетании с очередями. Клиент посылает сообщение в очередь, а MDB объект получает эти сообщения из очереди по подписке. Клиент не может вызывать MDB напрямую, связь обеспечивается с помощью сообщений JMS. MDB никогда не отвечает клиенту.
Класс получателя сообщений оформлен как MDB объект с использованием аннотации, в которой определен ряд параметров, включающий JNDI очереди ‘jms/queue/test’. Получатель реализует интерфейс javax.jms.MessageListener, согласно которому переопределяет метод onMessage.
При появлении в очереди ‘jms/queue/test’ сообщения сервер приложений Wildfly сразу же вызовет метод onMessage данного MDB-объекта и передаст ему в качестве параметра сообщение javax.jms.Message, текст которого будет сохранен в коллекции messages. Сервлет имеет прямой доступ к набору полученных сообщений messages с модификаторами public и static.
Листинг страницы index.jsp
На странице index.jsp определена библиотека jquery-3.2.1.min.js и JavaScript методы, которые используются для ajax-вызова сервлета. Интерфейс страницы включает текстовое поле ‘prefix’ и кнопки ‘Отправить’ и ‘Получить’.
Интерфейс страницы в браузере представлен на следующем скриншоте.
При нажатии на кнопку ‘Отправить’ вызывается JavaScript процедура sendMessages, определяющая значения параметров (mode, prefix) и вызывающая сервлет для отправки сообщений. Результат выполнения команды в виде набора сообщений, оформленных в HTML-коде, возвращается в функцию success, которая выкладывает его в поле sendJMS на странице. Если префикс не определен, то сервлет будет использовать по умолчанию значение ‘prefix’. Как только сообщения попадут в очередь сервер вернет их объекту ‘Receiver’ по подписке.
При нажатии на кнопку ‘Получить’ вызывается JavaScript процедура receiveMessages, определяющая значение параметры mode и вызывающая сервлет для чтения полученных по подписке сообщений. Результат выполнения команды в виде набора сообщений, оформленных в HTML-коде, возвращается в функцию success, которая выкладывает его в поле receiveJMS на странице.
Старт сервера Wildfly
Сервер приложений Wildfly «логирует» всю информацию. При старте из IDE Eclipse эта информация дополнительно выводится в консоль. Ниже представлена информация (в сокращенном виде), связанная с настройкой сервером JMS очередей и стартом приложения «jms-jboss». В предпоследней строке отображено подключение MDB (Message Driven Bean) ‘Receiver’ к провайдеру HornetQ.
Скачать пример
Исходный код рассмотренного примера в виде проекта Eclipse с использованием Maven можно скачать здесь (994 Кб).
Примеры взаимодействия Java приложения c Websphere MQ по отправки и чтению JMS сообщений представлены здесь.
Работа с 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 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. Все права защищены.
Getting Started with Java Message Service (JMS)
by Qusay H. Mahmoud
Published November 2004
The Java Message Service (JMS), which is designed by Sun Microsystems and several other companies under the Java Community Process as JSR 914, is the first enterprise messaging API that has received wide industry support. The Java Message Service (JMS) was designed to make it easy to develop business applications that asynchronously send and receive business data and events. It defines a common enterprise messaging API that is designed to be easily and efficiently supported by a wide range of enterprise messaging products. JMS supports both messaging models: point-to-point (queuing) and publish-subscribe.
JMS was defined to allow Java application to use enterprise messaging systems. More importantly, it provides a common way for Java applications to access such enterprise messaging systems. JMS falls under middleware, and specifically Message-Oriented Middleware (MOM), which is a relatively low-level of abstraction that runs underneath complementary layers such as database and application adapters, event processing, and business process automation. MOM is becoming an essential component for integrating intra-company operations as it allows separate business components to be combined into a reliable, yet flexible, system.
JMS defines a set of interfaces and semantics that allow Java applications to communicate with other messaging implementations. A JMS implementation is known as a JMS provider. JMS makes the learning curve easy by minimizing the set of concepts a Java developer must learn to use enterprise messaging products, and at the same time it maximizes the portability of messaging applications.
Architecture
A JMS application is composed of the following parts:
Message Delivery Models
JMS supports two different message delivery models:
The JMS Programming Model
A JMS application consists of a set of application-defined messages and a set of clients that exchange them. JMS clients interact by sending and receiving messages using the JMS API. A message is composed of three parts: header, properties, and a body.
Producing and Consuming Messages
Here are the necessary steps to develop clients to produce and consumer messages. Note that there are some common steps that shouldn’t be duplicated if the client is both producing and consuming messages. Figure 1 depicts the high-level view of the steps:
Figure 1: Producing and consuming messages
Client to Produce Messages
A client uses a connection factory, which is an instance of either QueueConnectionFactory (point-to-point) or TopicConnectionFactory (publish/subscribe), to create a connection to a provider. The following snippet of code demonstrates how to use JNDI to find a connection factory object:
Alternatively, you can directly instantiate a connection factory as follows:
ConnectionFactory connFactory = new com.sun.messaging.ConnectionFactory();
Connection connection = connFactory.createConnection();
Note that you must close all connections you have created. This is done using the Connection.close() method.
Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE)
The createSession() method takes two arguments: the first (false in this case) means that the session is not transacted, and the second means that the session will automatically acknowledge messages when they have been received successfully.
A destination object is used by the client to specify the source of messages it consumes and the target of messages it produces. In the point-to-point messaging, destinations are known as queues, and in the publish/subscribe model of messaging, they are known as topics. The following snippet of code demonstrates how to perform a JNDI lookup of a queue named jms/SomeQueue :
Destination dest = (Queue) ctx.lookup(«jms/SomeQueue»);
Or, you can directly instantiate and configure a destination object as follows:
Queue q = new com.sun.messaging.Queue(«world»);
MessageProducer producer = session.createProducer(SomeQueue OR SomeTopic);
Once a producer has been created, it can be used to send messages as follows:
Client to Consume Messages
The first four steps are the same as above.
5. Use a Session object and a Destination object to create any needed MessageConsumer objects that are used for receiving messages. This can be done as follows:
MessageConsumer consumer = session.createConsumer(SomeQueue or SomeTopic);
Note that if topic is being used, then you can use the Session.createDurableSubscriber() to create a durable topic subscriber.
Once the consumer has been created, it can be used to receive messages. Message delivery, however, doesn’t begin until you start the connection created earlier, which can be done by calling the start() method:
A long parameter can be passed to the receive() method to specify a time-out (for example, 3000L for 3 seconds).
It is important to note that the receive() method is used to consume a message synchronously. In order to consume a message asynchronously, a message listener is used.
6. If asynchronous communication is desired, instantiate a MessageListener object and register it with a MessageConsumer object.
In the following snippet of code, the class MyListener implements the MessageListener interface. The message listener is registered with a specific consumer using the setMessageListener() :
In order to avoid missing messages, the start() method should be called on the connection after the listener has been registered. When message delivery begins, the JMS provides automatically invokes the message listener’s onMessage() whenever a message is delivered.
7. Instruct the Connection object to start delivery of messages by calling the start() method.
Sun Java System Message Queue 3.5
Sun is one of the principal designers of JMS, and therefore they have been shipping a production implementation of JMS since 1999.
The Sun Java System Message Queue is a currently shipping product, which has been formerly known by the names: Java Message Queue, iPlanet Message Queue for Java, and Sun ONE Message Queue. This product acts as one system for all business messaging needs through support for point-to-point and publish/subscribe messaging models as well as support for synchronous and asynchronous messaging.
Using this product, processes running on different platforms and operating systems can connect to a common Message Queue service to send and receive information. Application developers can focus on the business logic of their applications rather than the low-level details of how to achieve or implement reliable communication across the network.
This product is a leading business integration enterprise message server that provides a standards-based messaging solution. It is available in two edition: Platform Edition and Enterprise Edition.
Note: JMS doesn’t define functionality that addresses load balancing, fault tolerance, security, and administration. Such mechanisms must be provided by JMS providers.
Note, however, that if you download the free Platform Edition, it comes with a 90 day trial of the Enterprise Edition
It is worth noting that the product includes a J2EE 1.4 compliant Resource Adapter that enables you to use Sun Java System Message Queue as a JMS provider for any J2EE 1.4 technology-compliant application server. This enables businesses to maximize their investments in current IT assets by being able to continue using their existing application server, but leverage the benefits of Sun Java System Message Queue.
Download and install Java System Message Queue. Once installed, the \bin directory contains a utility to install and uninstall the broker as a Window Service ( imqsvcadmin ). In addition, it contains the executable for the broker ( imqbrokerd ) and the following administration tools:
Test Your Installation
To test your installation, do the following:
The broker will start and display a few messages before displaying «imqbroker@hostname:7676 ready»
If everything is fine, it will display information as follows:
Sample Application
To give you a flavor of the effort involved in developing JMS applications, here is a sample application that uses point-to-point communication to send and receive a text message. Note that in this example, the sample application is acting as a sender (sends the message to the queue) and receiver (receives the same message from the queue). As you can see, the application is straightforward and simple to code.
To experiment with this sample application, do the following:
Note: The choice of PATH SEPARATER CHARACTER, <;|:>, is platform dependent. ‘:’ on UNIX/Linux, and ‘;’ on Windows
Here is the sample output:
Synchronous and Asynchronous Message Consumption
A JMS client can consume messages either synchronously or asynchronously.
Reliable Messaging
JMS defines two delivery modes:
This, however, is all about performance trade-offs. The more reliable the delivery of messages, the more bandwidth and overhead required to achieve that reliability. Performance can be maximized by producing non-persistent messages, or you can maximize the reliability by producing persistent messages.
For more information on using such advanced features, please see Chapter 33 of the J2EE 1.4 Tutorial.
Message-Driven Beans
JMS is a mandatory API and service in J2EE platform. A good example is the message-driven bean, one of a family of EJBs specified in EJB 2.0/2.1. The other two EJBs are session beans and entity beans, which can only be called synchronously.
A JMS Message-Driven Bean (MDB) is a JMS message consumer that implements the JMS MessageListener interface. The onMessage() method is invoked when a message is received by the MDB container. Note that you do not invoke remote methods on MDBs (like with other enterprise beans) and as a result there are no home or remote interfaces associated with them. It also worth noting that with J2EE 1.4, MDBs are not limited to JMS; rather, a multiplicity of MDB interfaces can be declared and consumed by application components implementing those interfaces.
If you would like to see sample J2EE applications using the JMS API, please refer to Chapter 34 of the J2EE 1.4 Tutorial.
Conclusion
The Java Message Service (JMS) makes it easy to develop enterprise applications that asynchronously send and receive business data and events. It defines a common enterprise messaging API that is designed to be easily and efficiently supported by a wide range of enterprise messaging products. JMS supports both messaging models: point-to-point (queuing) and publish-subscribe style of messaging. This article provided a fast track introduction and tutorial to JMS and its programming model.
The JMS specification has been implemented by most application servers and other software vendors. One of these implementations is Sun Java System Message Queue Platform Edition, which is an enterprise message server designed for small-scale deployments and development environments. It implements JMS 1.1 specification and has support for SOAP. This software is available for free; however, note that it doesn’t include key enterprise benefits such as scalability, reliability, and advanced security. Such features are available in the Enterprise Edition of the Java System Message Queue, but a 90-day trial version is included in the Platform Edition.
For More Information
Acknowledgments
Special thanks to George Tharakan of Sun Microsystems, whose feedback helped me improve this article.