Kwert-soft.ru

IT Софт для ПК
0 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Java message queue

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 необходимо настроить его файл конфигурации /standalone/configuration/standalone.xml. По умолчанию настройки JMS не включены в конфигурационный файл и их нужно определить вручную. Но можно использовать файл конфигурации standalone-full.xml, в котором сервер включает настройки JMS провайдера HornetQ, обеспечивающего создание соответствующих очередей и обмен сообщениями.

В файл конфигурации standalone-full.xml в раздел секции добавим очередь. Две очереди (ExpiryQueue и DLQ) уже имеются в подразделе . Добавим свою очередь testQueue с JNDI ‘jms/queue/test’ :

Для примера достаточно было добавить один элемент ‘ ‘, который работает внутри контейнера. Второй элемент «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’ :

Для запуска сервера приложений Wildfly не из IDE Eclipse c конфигурационным файлом standalone-full.xml можно использовать командный файл, в котором определить файл в качестве параметра : ./standalone.sh -c standalone-full.xml

В конце страницы приведен Log сервера Wildfly, в котором показано создание соответствующих очередей и подключение MDB-объекта приложения к адаптеру HornetQ для получения JMS сообщений по подписке.

Описание примера

На следующем скриншоте приведена структура WEB-приложения jms-jboss, включающего :

  • ServiceServlet — сервлет, используемый для отправки и получения JMS сообщений;
  • Sender — отправитель JMS сообщений;
  • Receiver — MDB получатель JMS сообщений;
  • jquery-3.2.1.min.js — библиотека jQuery для асинхронных ajax-вызовов сервлета;
  • index.jsp — интерфейсная страница приложения.

Проект в среде 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.

Читать еще:  Java lang runtimeexception что это

Скачать пример

Исходный код рассмотренного примера в виде проекта Eclipse с использованием Maven можно скачать здесь (994 Кб).

Примеры взаимодействия Java приложения c Websphere MQ по отправки и чтению JMS сообщений представлены здесь.

Краткий обзор MQ (Messages queue) для применения в проектах на РНР. Часть 1

Параллельно к основной работе, я в «фоне» обдумываю и прикидываю реализации архитектуры для игровых проектов (напомню, что основная область моих интересов и работ — создание онлайновых браузерных игр). Последнее время я все чаще и чаще возвращаюсь к мысли, что интересно было бы реализовать основной игровой сервер на основе очередей сообщений (MQ или Messages queue). То есть, движок такой игры будет представлять собой набор компонентов, которые будут общаться между собой посредством асинхронных сообщений, а каждый компонент может быть как генератором сообщений, так и подписчиком, то есть исполнять другие сообщения.

Такой подход, насколько я понимаю, широко применяется в мире Java, там для этого есть стандарт Java Message Service (JMS) и применяются брокеры сообщений и на этом базируется архитектура Enterprise service bus (ESB), например, Apache ServiceMix. Но для нас это пока высокая сфера крупных проектов, а в специфике веба и веб-ориентированных приложений я бы хотел рассмотреть, можно ли что-то сделать подобное, но с меньшими затратами и обеспечить приложению отказоустойчивость, распределение нагрузки и асинхронную обработку. И конечно, очень желательно, чтобы это было реализовано на РНР как основном языке реализации всех компонентов сервера.

И так, еще раз — MQ, это архитектура и ПО промежуточного уровня, которое занимается сбором, хранение и маршрутизацией (распределением) сообщений между компонентами. Я не претендую на полноту описания, и, вполне возможно, не учитываю множества нюансов, поэтому не рассматривайте мои определения как аксиомы, лучше всего почитать дополнительную литературу, если вы хотите поглубже разобраться в архитектуре MQ (например, вот эти статьи: [1], [2], [3]) и определение в Wikipedia — Message queue

Пока давайте посмотрим очень кратко, обзорно, какие системы реализации систем сообщения есть, а, главное, какие из них можно рассматривать в качестве основы для специфика моего проекта. И хотя я думал рассмотреть только РНР реализации, оказалось, что нужно «копать глубже», поэтому мы затронем и системы на других языках, но обладающие возможность взаимодействовать с РНР-приложениями.

Apache ActiveMQ — открытая реализация брокера сообщений (Message Broker) и Enterprise Integration Patterns (если сейчас и очень кратко — расширение для реализации дополнительной обработки согласно правилам). Этот проект, по моему мнению, из всех открытых, самый мощный и развивающийся, недавно вышла версия 5.1. Он реализовывает множество стандартов и обеспечивает все возможности, необходимые для решений уровня Enterprise, входит в стек Java-технологий от Apache. Что меня заинтересовало, так это возможность кросс-языкового обмена сообщениями, а значит — клиенты могут быть реализованы на любом языке. Для платформ Java, C, C++, C# это библиотека OpenWire, реализующая Wire протокол для нативного доступа к MQ, для остальных языков, включая, что нам и интересно, РНР, есть Stomp — реализация библиотек для разных скриптовых языков, которая превращает сообщения в формат JMS. Кстати, если необходимо обеспечить безопасную коммуникацию и передачу сообщений, можно использовать SSL.

MQS (Minimalist Queue Services) — проект, если можно так сказать, с друго конца. Это небольшая система, написанная на Perl, организовывает систему очередей сообщений, используя XML-RPC протокол, сами сообщения могут хранится как в любой базе данных, так и в файлах. К сожалению, по всей видимости, проект заброшен, так как последняя новость на сайте датирована апрелем 2005 года, а текущая версия — 0.0.14.

Spread — еще одна реализация очереди сообщений, на этот раз на С++, и версии есть для различных платформ, включая Win32, Linux, BSD и MacOS. Текущая версия — 4.0. Система распределенная и ориентирована на высокопроизводительные системы, где клиентов и, соответственно, сообщений, очень много. Заявлена поддержка, в последней 4.0 версии, технологии Virtual Synchrony. Что интересно — в поставку сразу включены бинарные версии для нескольких платформ, а также встроенные интерфейсы для некоторых языков — C/C++, Java, Perl, Python, Ruby. Странно, что четвёртого Р — РНР, среди них нет, но существует расширение в PECL, которое реализовывает весь интерфейс Spread API. Текущая версия 2.1 и достаточно новая, значит проект развивается. Существуют и реализации для других языков, в том числе и альтернативы встроенным интерфейсам, поэтому посмотрите на список здесь, там даже для MS Excel есть расширение. Среди интересных проектов — модуль mod_log_spread для Apache, позволяющий собирать логи доступа с нескольких веб-серверов.

RabbitMQ — высокопроизводительная платформа, написанная на Erlang, основанная на Open Telecom Platform, а значит — очень надежная и масштабированная система, часто применяемая в телекоммуникационных приложениях и других подобных системах. Есть интерфейс только для Java и C++. Система поддерживает стандарт AMQP (Open Standard for Messaging Middleware). Система интересная, знать бы только Erlang, хотя что-то мне подсказывает, что проектируя весь серверный модуль на этой платформе, мы получили бы много «плюшек», в частности, на этой же платформе написан самый популярный Jabber-сервер ejabberd, который также можно применять в он-лайн игровых проектах.

Beanstalkd — также интересный проект, созданный в рамках разработки одного из приложений для социальной сети Facebook, которым пользуется около 10 млн человек (приложением, не сетью). Это специализированный сервер для хранения и обработки очередей заданий, использующий хранение данных в памяти для обеспечения скорости, однако в ущерб отказоустойчивости. Этот проект очень похож на уже ранее описанный нами MemcacheQ, да и сами разработчики выражают благодарность создателям memcached за принципы архитектуры и протокол. Система предназначена для создания асинхронной очереди обработчиков пользовательских задач, которые не требуют немедленного ответа, например, отсылки писем, фоновые обработки и т.п. Существуют клиентские API для различных языков, в том числе для Erlang, OCaml, Perl, PHP, Python, Ruby. Для РНР библиотека расположена здесь и пока имеет версию 0.11, сама разработка началась всего пару месяцев назад (судя по регистрации проекта). Детальнее можно почитать отличный обзор: Beanstalk Messaging Queue Сервер написан на С, что обеспечивает высокую скорость работы, однако специфика проекта в плане хранения всех данных в оперативной памяти не подойдет для тех сфер, где остро необходима максимальная отказоустойчивость, пусть даже ценой дополнительного ПО и затрат на хранение данных в базе.

Пока это все. А как же РНР, спросите вы? Описанные решения основаны на сторонних платформах, однако имеют библиотеки для обеспечения коммуникации с РНР-приложениями. Но существуют и нативные, РНР решения такого рода приложений, конечно, не полные аналоги, здесь уже скажется специфика среды РНР, однако достаточные для многих областей применения. О таких решения я расскажу вам в продолжении этого материала.

Читать еще:  String isempty java

JMS Queue Example

Posted by: Ram Mokkapaty in jms November 5th, 2015 3 Comments Views

JMS Message queue is a destination to which producers send messages. Consumer connects to the broker to receive the message sitting in the queue. Queue is used in point-to-point messaging. In point-to-point messaging, there may be more than one receiver connected to the queue but each message in the queue may only be consumed by one of the queue’s receivers.

The messages can be sent and received either synchronously or asynchronously.

In this article, we will see some examples of JMS Queue.

1. Dependencies

In order to send and receive JMS messages to and from a JMS message broker, we need to include the message service library. In this example we are using activeMq so our pom.xml will have dependencies related to spring as well as activeMq.

2. Creating a Queue

First let’s see how to create a queue.

In order to create a queue object, you need to first create a session and then call createQueue() on the session object. You need to pass the queue name to it.

The queue stores all messages until they’re delivered or until they expire.

3. Sending message to a Queue

Now that we have a queue object, let’s send a message to it.

As you can see from above, a producer sends a message to the queue.

4. Receive message from Queue

Each message received on the queue is delivered once and only once to a single consumer which is why this style of messaging is called point-to-point messaging. Consumer will first connect to the broker to receive the message from the queue. Just like the producer, consumer also needs a session using which it will connect to the queue.

Note that connection is started so that any message listener registered will get the notification as soon as a message lands in the queue.

Consumer receives the message using MessageConsumer.receive() method or asynchronously by registering a MessageListener implementation using the MessageConsumer.setMessageListener() method. Multiple consumers can be registered on a single queue but only one consumer will receive a given message.

5. Receiving a message Asynchronously

In our last example, we have seen consumer receiving message explicitly using MessageConsumer.receive(). In in this section, we will see ow a consumer can register a message listener. Instead of explicitly receiving the message, consumer just registers a message listener. Moment a message lands in the queue, the broker passes on the message to one of the message listeners.

Let’s first create a message listener.

A message listener is created by implementing javax.jms.MessageListener and implementing onMessage(Message) .

Consumer will register its own message listener. It will pass a name to it so we know which consumer is consuming the message.

Next, we need to make sure start() is called on connection object. This is an important step for the broker to make sure the message is passed on to one of the listeners.

6. Multiple Consumers

The workload of message processing can be distributed among more than one consumer. When multiple receivers are attached to a queue, each message in the queue is delivered to one receiver. The absolute order of messages cannot be guaranteed, since one receiver may process messages faster than another.

Storage for queue is on the basis of first in, first out order (FIFO). One message is dispatched to a single consumer at a time. Only when that message has been consumed and acknowledged, it is deleted from the queue.
In the below example, we create multiple consumers, each one registered with a message listener. Next, we create a producer and make it send multiple messages. Each message is received by just one consumer and the order in which the messages are received is according to FIFO.

Each consumer will register its own message listener. It will pass a name to it so we know which consumer is consuming the message.

You can see from output, the messages are delivered in a round-robin fashion between all the message consumers.

7. Creating a Temporary Queue

A temporary queue is a queue which can only be consumed by the JMS client that created it. It is created using the createTemporaryQueue() method on QueueSession/code> object.

8. Browsing a Queue

JMS allows you to peek ahead at pending messages on a Queue without actually consuming them using QueueBrowser object. Since we can browse through the messages without actually consuming them, this is very unique and important feature to point-to-point messaging.

We create the QueueBrowser object using the below statement on session object.

As you can see createBrowser() takes the Queue object that we are interested to browse.

To enumerate through the messages, we will call QueueBrowser.getEnumeration() .

When we are done with the browser we should close it.

In the below example, we create a producer and post a bunch of messages to a queue. Next we create a consumer. In order to browse, we create a QueueBrowser object and navigate through the messages.

Finally, we call consumer.receive() to receive one of the messages from queue.

Messages obtained from a QueueBrowser are copies of messages contained in the queue and are not considered to be consumed as they are merely for browsing. Below is the output.

Национальная библиотека им. Н. Э. Баумана
Bauman National Library

Персональные инструменты

Sun Java System Message Queue

Sun Java System Message Queue

Создатели:Sun Microsystems
Разработчики:Sun Microsystems
Состояние разработки:Поддержка прекращена
Написана на:Java, C
Операционная система:Любая, с поддержкой Java
Платформа:Sun Java System
Тип ПО:Обмен сообщениями
Лицензия:Проприетарное
Веб-сайтdocs .oracle .com /cd /E19693-01 /819-0995 /fhktn /index .html

Sun Java System Message Queue – это продукт промежуточного программного обеспечения для обмена сообщениями, который реализует стандарт службы сообщений Java (JMS). Кроме того, Message Queue обеспечивает возможности корпоративной прочности, включая расширенные функции интеграции, администрирования, безопасности и высокой доступности.

Message Queue — это система обмена сообщениями с бизнес-интеграцией, предназначенная для обеспечения исключительной надежности и масштабируемости.

Содержание

Краткий обзор возможностей

Platform Edition. Представляет собой бесплатную реализацию JMS на уровне коммерческого продукта, идеально подходящую для размещения систем небольшого масштаба и для сред разработки в различных операционных системах

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

  • Память: 256 МБ
  • Пространство на диске: 45 МБ для Microsoft Windows (сам продукт и дополнительно Java
Читать еще:  Java io outputstream

Runtime Environment 1.4.0; 8 МБ для ОС Solaris и Linux (только продукт) Поддерживаются:

ОС RedHat Advanced Server 2.1 Update 2

  • ОС Microsoft Windows XP Professional, Windows 2000 Professional SP3, Windows 2000 Advanced Server SP3, .NET Server 2003 Enterprise Edition

Основные возможности и преимущества

  • Соответствие спецификациям интерфейса JavaAPI for XML Messaging (JAXM)
  • Более быстрая разработка компонентов с возможностью многократного использования
  • Поддержка различных моделей передачи сообщений
  • Гибкость в разработке приложений со слабыми связями
  • Поддержка нескольких брокеров
  • Масштабирование для поддержки большего числа одновременных соединений
  • Инструментальные средства администрирования службы сообщений
  • Простота использования, конфигурирования и управления
  • Шифрование сообщений с использованием SSL
  • Средства защиты данных при передаче по маршруту

Принцип работы

Очередь сообщений

Очередь сообщений может использоваться как автономная служба обмена сообщениями или может использоваться как технология включения, развернутая на сервере приложений Java EE для обеспечения асинхронной передачи сообщений. Это неотъемлемая технология GlassFish Application Server (ранее Sun Java Application Server), а также является ключевым компонентом программного обеспечения промежуточного программного обеспечения Java Enterpirse.

Очередь сообщений Sun Java System Message Queue представляет собой сервер сообщений для интеграции инфраструктуры предприятия. Это недорогое решение способствует максимальной окупаемости инвестиций в IT-инфраструктуру, обеспечивает эффективные коммуникации и совместную работу различных приложений в масштабе предприятия.

Существует две версии данного продукта. Версия Java System Message Queue Platform Edition основана на спецификации JMS и предназначена для интеграции в небольшие системы. Продукт можно загрузить бесплатно в комплекте с ОС Solaris и сервером приложений Sun Java System Application Server 7.

Версия Java System Message Queue Enterprise Edition Edition представляет собой высокопроизводительную систему интеграции приложений, предназначенную для инфраструктур уровня предприятия. Она обладает масштабируемостью, надежностью и улучшенной системой защиты информации, что полностью отвечает стандартам для систем масштаба предприятия. [Источник 1]

Технология Message-Oriented Middleware

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

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

В качестве поставщика JMS Message Queue предлагает службу сообщений, которая реализует интерфейсы JMS, а также обеспечивает административное управление и контроль. До сих пор, иллюстрируя поставщиков JMS, основное внимание уделялось роли брокера в предоставлении сообщений. Но на самом деле поставщик JMS должен включать в себя множество дополнительных элементов для обеспечения надежной, безопасной и масштабируемой передачи сообщений.

Элементы Message Queue service:

В основе службы сообщений лежит брокер, который надежно передает и доставляет сообщения, аутентифицирует пользователей и собирает данные для мониторинга производительности.

  • Поддержка времени выполнения клиента(Client Runtime Support)

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

  • Универсальная служба сообщений (UMS)

Служба универсальных сообщений (UMS) и ее API сообщений предоставляют доступ к очереди сообщений с любого устройства с поддержкой http. В результате почти любое приложение может связываться с любым другим приложением и извлекать выгоду из надежности и гарантированной доставки службы очереди сообщений.

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

Кроме того, для этих встроенных средств администрирования Message Queue также поддерживает спецификацию Java Management Extensions (JMX) для настройки и мониторинга брокеров, получателей, служб соединений и т д. Используя API администрирования JMX, вы можете выполнять эти функции администрирования программным путем из приложения Java.

  • Брокерские кластеры(Broker Clusters): масштабируемость и доступность

Брокеры очереди сообщений могут быть подключены к кластеру брокеров: набор брокеров, которые работают коллективно для доставки сообщений между производителями сообщений и потребителями. Брокерские кластеры добавляют масштабируемость и доступность к службе очереди сообщений.

Описание функции очереди сообщени (Message Queue Feature Summary)

Очередь сообщений (Message Queue) имеет возможности и функции, которые намного превосходят требования спецификации JMS и JMS API. Эти функции позволяют Message Queue интегрировать системы, состоящие из большого количества распределенных компонентов, обменивающихся тысячами сообщений в круглосуточных критически важных операциях.

Снизу описан список всех корпоративных возможностей:

  • Поддержка интеграции:
    • Несколько служб соединений, включая HTTP-соединения и защищенные соединения
    • Адаптеры ресурсов Java EE
    • Поддержка SOAP
    • Проверка схемы XML-сообщений
    • Поддержка сервера LDAP
  • Безопасность:
    • Аутентификация
    • Авторизация, включая аутентификацию на основе JAAS
    • Безопасные подключения, включая шифрование
  • Производительность:
    • Настраиваемая производительность
    • Управление ресурсами памяти
    • Управление потоком сообщений
    • Настраиваемые физические объекты
    • Сжатие сообщения [Источник 3]
Ссылка на основную публикацию
Adblock
detector