Project

General

Profile

Actions

JMS

Вопросы

  1. Что такое JNDI?
  2. Что такое JMS?
  3. Что такое MOM?
  4. Из каких компонентов состоит архитектура обмена сообщениями?
  5. Какие модели обмена сообщениями в JMS вы знаете? Опишите их.
  6. Назовите основные интерфейсы JMX, для чего они предназначены.
  7. Как выглядит алгоритм создания программ, работающих с JMS?
  8. Какие стандартные типы сообщений определены JMX?
  9. Из каких частей JMS сообщение?
  10. Какие параметры может содержать заголовок сообщения?
  11. Какие модели подтверждения получения сообщения вы знаете?

Ответы

Что такое JNDI?

JNDI - это API-интерфейс для доступа к службам каталогов, позволяющий клиентам осуществлять привязку и поиск объектов по имени. JNDI определяется в Java SE и не зависит от базовой реализации, то есть вы можете выполнять поиск объектов в каталоге Lightweight Directory Access Protocol (LDAP) или системе доменных имен (DNS), используя стандартный API-интерфейс.

Что такое JMS?

JMS, Java Message Service - это Java API (то есть набор интерфейсов и классов) для работы с Message-Oriented Middleware, изначально разработанная компанией Sun, чтобы предоставить разработчикам создавать гибкие и слабосвязанные приложения с использованием асинхронного обмена данными между приложениями (клиентами/серверами) через посредника. Асинхронность - это главная причина создания и использования JMS.

Данный набор определен в пакете javax.jms в дереве пакетов J2EE. JMS поддерживает две модели обмена сообщениями: point-to-point (точка - точка) и publish-subscribe (издатель-подписчик).

Что такое MOM?

MOM, Message-Oriented Middleware (промежуточное программное обеспечение) - подпрограммное обеспечение промежуточного слоя, ориентированное на обмен сообщениями в распределённом окружении. Прежде всего предназначено для реализации отложенного обмена сообщениями, на основе которого и строится Messaging System.

В отличие от традиционных систем, в Messaging System приложения общаются не напрямую, а посредством MOM. Если один компонент системы хочет послать сообщение другому компоненту, он посылает данное сообщение MOM, а MOM затем пересылает его адресату.

Из каких компонентов состоит архитектура обмена сообщениями?

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

  • Поставщик. JMS - это только API, поэтому он нуждается в реализации способа обмена сообщениями, то есть в поставщике (также известном как брокер сообщений). Поставщик обрабатывает буферизацию и доставку сообщений.
  • Клиенты. Клиентом является любое приложение Java или компонент, который производит или потребляет сообщение с помощью поставщика. "Клиент" - это общий термин для производителя, отправителя, издателя, потребителя, приемника и подписчика.
  • Сообщения. Это объект, которые клиенты отправляют или получают от поставщика.
  • Администрируемые объекты. Брокер сообщений должен предоставить клиенту администрируемые объекты (фабрики подключений и места назначения) с помощью поиска JNDI или внедрения (как вы увидите далее).

Какие модели обмена сообщениями в JMS вы знаете? Опишите их.

Существует две "основных" модели обмена сообщениями:

  • Модель Точка-Точка (Point-to-Point, P2P) - в этой модели место назначения, используемое для хранения сообщений, называется очередью. Объект Queue. В этой модели один клиент помещает сообщение в очередь, а другой получает сообщение. Как только получение сообщения подтверждено, поставщик сообщений удаляет его из очереди.
  • Модель Подписчик-Издатель (Publisher-Subscriber) - место назначения называется темой. Объект Topic. При использовании данной модели клиент публикует сообщение в теме и все абоненты этой темы получают сообщение.

Назовите основные интерфейсы JMS, для чего они предназначены.

Рассмотрим главные интерфейсы:

  • ConnectionFactory - это обьект, ответственный за создание JMS Connection. Администратор МОМ создает данный обьект и связывает его с деревом JNDI, так что клиент JMS может получить доступ к ConnectionFactory используя стандартный JNDI lookup-механизм. В параметре инициализации нужно передавать данные вашего JMS сервера. В случае point-to-point модели используется javax.jms.QueueConnectionFactory, в случае pub-sub модели - javax.jms.TopicConnectionFactor.
  • Connection - абстрактное представление реального соединения между клиентом JMS и MOM. Создает объект Session. В случае point-to-point модели используется javax.jms.QueueConnection, в случае pub-sub модели - javax.jms.TopicConnection.
  • Session - объект, создаваемый JMS Connection и используемый клиентами для посылки и принятия сообщений. В случае point-to-point используется javax.jms.QueueSession, в случае pub-sub - javax.jms.TopicSession. Фактически, это главная "рабочая лошадка" JMS.
  • Destination - это либо queue, либо topic - в зависимости от используемой модели: javax.jms.Queue или javax.jms.Topic. Как и ConnectionFactory, destination связывается с деревом JNDI.
  • MessageProducer - обьект, который, собственно, и посылает сообщения. В случае point-to-point модели это javax.jms.QueueSender, в случае pub-sub - javax.jms.TopicPublisher.
  • MessageConsumer - обьект, принимающий сообщения. В случае point-to-point модели это javax.jms.QueueReceiver, в случае pub-sub - javax.jms.TopicSubscriber.
  • Message - сообщение. О типах сообщений будет сказано ниже.

Как выглядит алгоритм создания программ, работающих с JMS?

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

  • Подключаемся к серверу, используя ConnectionFactory.
  • Получаем соединение Connection из ConnectionFactory.
  • Создаем однопоточный контекст Session из соединения.
  • Получаем буфер Destination привязанный к определенному адресу для создания интерфейсов отправки и получения сообщений.
  • Создание объектов MessageProducer для отправки или MessageConsumer для получения сообщений.
  • Отдельно идет этап создания сообщения для отправки.

Какие стандартные типы сообщений определены JMS?

В JMS определены следующие стандартные типы сообщений:

  • StreamMessage - это поток примитивных типов Java. Считывать можно со стандартных интерфейсов ввода/вывода.
  • MapMessage - содержит информацию на подобии коллекций в виде ключ-значение (String, Object).
  • TextMessage - обычное текстовое сообщение содержащее строку.
  • ObjectMessage - для передачи Serializable-объектов.
  • ByteMessage - список не интерпретированных байт. С его помощью можно передавать файлы.

Кроме того, некоторые имплементации (например, OpenFusion и WebLogic) предоставляют еще один "почти стандартный" тип:

  • XMLMessage - расширение TextMessage, используется для доставки XMLсообщений

Все типы сообщений являются подклассами javax.jms.Message.

Из каких частей JMS сообщение?

Любое JMS сообщение имеет в себе 3 составные части:

  • Заголовок (header). Набор свойств, поставляемый по умолчанию для любого сообщения, содержит стандартную информацию для идентификации и маршрутизации сообщений.
  • Свойства (properties). Пары «имя/значение», которые приложение может установить или считать; свойства также позволяют месту назначения фильтровать сообщения на основе их значений.
  • Тело (body). фактически содержит сообщение и может иметь один из нескольких форматов (текст, байты, объект и т. д.).

Какие параметры может содержать заголовок сообщения?

Заголовок сообщения содержит дополнительную информацию, которую разработчик может использовать в своем приложении. JMS предоставляет get и set методы для каждого поля заголовка. Некоторые из них устанавливаются автоматически, другие могут быть использованы разработчиком приложения.

  • JMSDestination(тип String) - содержит имя destination, в который посылается сообщение.
  • JMSDeliveryMode (тип int) - определяет, является ли сообщение сохраняемым или нет. Может иметь только два значения: DeliveryMode.PERSISTENT и DeliveryMode.NON_PERSISTENT. Персистентное сообщение доставляется "один раз и только один раз"; не персистентное сообщение доставляется "не более одного раза". "Не более одного раза" подразумевает возможность отсутствия доставки.
  • JMSExpiration (тип long) - определяет, когда сообщение устареет и будет удалено из системы. 0 - означает что сообщение будет жить пока оно не будет доставлено.
  • JMSPriority (тип int) - как и следует из названия, определяет приоритет сообщения (от 0 до 9). По умолчанию равно 4.
  • JMSMessageID (тип String) - уникальный идентификатор сообщения
  • JMSTimestamp (тип long)- содержит информацию, когда именно MOM приняла сообщение от producer.
  • JMSCorrelationID (тип String) - может быть использовано разработчиком для согласования сообщений: например, если вы хотите переслать ряд сообщений, обьединенных в одну логическую группу (такую как набор товаров в заказе, при этом в каждое сообщение о товаре вы можете добавить в данное поле заголовка номер заказа).
  • JMSReplyTo (тип Destination) - может быть использовано разработчиком для того, чтобы consumer знал, кому (то есть в какой destination) при желании отсылать ответ.
  • JMSType (тип String) - поле может быть использовано разработчиком для того, чтобы дать приложению информацию, как обращаться с данным сообщением. Тип здесь понимается как application-specific type, а не тот, что использован выше в разделе "типы сообщений".
  • JMSRedelivered (тип Boolean) - означает, что сообщение было доставлено получателю, но он не подтвердил прием сообщения.

Какие модели подтверждения получения сообщения вы знаете?

JMS поддерживает три "основных" модели подтверждения получения сообщения.

  • AUTO_ACKNOWLEDGE - в случае синхронного получения сообщений, подтверждение получения будет произведено автоматически, когда метод receive() возвратит значение не вызвав никакой исключительной ситуации. В случае асинхронного получения сообщений, подтверждение получения будет произведено, когда метод onMessage() вернет значение.
  • DUPS_OK_ACKNOWLEDGE - работа по подтверждению получения сообщения перекладывается на Session. Сообщения будут вновь доставлены в случае возникновения ошибки или "гибели" системы.
  • CLIENT_ACKNOWLEDGE - клиент должен вызвать метод acknowledge() интерфейса javax.jms.Message для того, чтобы явно подтвердить получение сообщения. При вызове данного метода будет подтверждено получение текущего и всех предыдущих полученных сообщений.

Updated by Александр Александров 9 months ago · 8 revisions

Go to top