Проект

Общее

Профиль

JMS » История » Редакция 5

Редакция 4 (Александр Александров, 05.02.2020 17:00) → Редакция 5/8 (Александр Александров, 05.02.2020 17:17)

h1. JMS 

 h2. Вопросы 

 # Что такое JNDI? 
 # Что такое JMS? 
 # Что такое MOM? 
 # Из каких компонентов состоит архитектура обмена сообщениями? 
 # Какие модели обмена сообщениями в JMS вы знаете? Опишите их. 
 # Назовите основные интерфейсы JMX, для чего они предназначены. 
 # Как выглядит алгоритм создания программ, работающих с JMS? 
 # Какие стандартные типы сообщений определены JMX? 
 # Из каких частей JMS сообщение? 
 # Какие параметры может содержать заголовок сообщения? 
 # Какие модели подтверждения получения сообщения вы знаете? 

 h2. Ответы 

 h3. Что такое JNDI? 

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

 h3. Что такое JMS? 

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

 h3. Что такое MOM? 

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

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

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

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

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

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

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

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

 

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

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

 * 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 - сообщение. О типах сообщений будет сказано ниже. 

 

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

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

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

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

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

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

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

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

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

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

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

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

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

 Заголовок сообщения содержит дополнительную информацию, которую разработчик может использовать в своем приложении. 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-speciÙc type, а не тот, что использован выше в разделе "типы сообщений". 
 * JMSRedelivered (тип Boolean) - означает, что сообщение было доставлено получателю, но он не подтвердил прием сообщения. 

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

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

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