Модели использования JMS. Основные объекты и термины, их назначение (алгоритм реализации)
Java Message Service (JMS) – это Java API (то есть набор интерфейсов и классов) для работы с Message-Oriented Middleware (МОМ). Данный набор определен в пакете javax.jms в дереве пакетов J2EE.
В Messaging System приложения общаются не напрямую, а посредством MOM (промежуточного программного обеспечения). Если один компонент системы хочет послать сообщение другому компоненту, он посылает данное сообщение MOM, а уж MOM затем пересылает его адресату.
MOM реализует асинхронность обмена сообщениями.
Существует две "основных" модели обмена сообщениями:
· point-to-point
· publish-subscribe (pub-sub)
Point-to-point модель применяется, когда одному или нескольким компонентам (так называемые senders) необходимо послать сообщение одному компоненту-адресату (receiver).
Publish-subscribe (Pub-sub) модель применима, когда одному или нескольким компонентам (publishers) необходимо послать сообщение одному или нескольким компонентам-адресатам (subscribers). Данная модель основана на понятии message topic.
ConnectionFactory – это обьект, ответственный за создание JMS Connection. Администратор МОМ создает данный обьект и связывает его с деревом JNDI, так что клиент JMS может получить доступ к ConnectionFactory используя стандартный JNDI lookup-механизм.
Connection – абстрактное представление реального соединения между клиентом JMS и MOM.
Session – обьект, создаваемый JMS Connection и используемый клиентами для посылки и принятия сообщений.
Destination – это либо queue, либо topic – в зависимости от используемой модели. Как и ConnectionFactory, destination связывается с деревом JNDI.
MessageProducer – обьект, который, собственно, и посылает сообщения.
MessageConsumer – обьект, принимающий сообщения. Message– сообщение. О типах сообщений будет сказано ниже.
Алгоритм реализации:
· Используем JMS и JNDI пакеты, инициализируем контекст сервиса JNDI;
· достаем ссылку на ConnectionFactory, опираясь на заданное нами имя; при создании (развертывании ресурса);
· создадим Connection (абстакция реального соединения);
· Создадим Session;
· Находим Destination, либо создаем ее;
· Создадим простейшее текстовое сообщение ;
· Создадим MessageProducer
· Активизация связи Connection
· Посылаем сообщение
Существует два пути получения сообщений:
· Первый – синхронное затребование сообщений из queue, используя метод receive() интерфейса javax.jms.QueueReceiver.
· Второй – асинхронное получение сообщений как только они становятся доступны – используя интерфейс javax.jms.MessageListener.
45. Особенности использования модели Point - to – Point (алгоритм и шаги реализации).
Point-to-point модель применяется, когда одному или нескольким компонентам (так называемые senders) необходимо послать сообщение одному компоненту-адресату (receiver).
Модель основана на понятии message queue (очередь). Senders посылают сообщения в queue, а Receiver читает сообщения из queue.
Часто говорят, что в point-to-point модели есть один и только один receiver. Однако это не совсем верно. Может существовать несколько receivers, присоединенных к одной и той же очереди. Но MOM доставит сообщение только одному из них. Какому именно – зависит от реализации. Некоторые MOM доставляют сообщение первому зарегистрированному receiver, в то время как существуют реализации, осуществляющие round-robin (карусельный метод использования адресов пула по кругу. При этом, используется определение адресов через таблицы.)
Модель «точка-точка» более удобна, если требуется, чтобы отдельный получатель обработал данное сообщение только один раз. Возможно, это наиболее существенное различие между двумя моделями:p2p гарантирует, что только один потребитель обработает каждое сообщение. Это чрезвычайно важно, когда сообщения должны быть обработаны отдельно и последовательно друг за другом.
Алгоритм реализации:
· Сначала найдем сервис JNDI, инициализируем контекст
· Теперь найдем ConnectionFactory с помощью JNDI
· А теперь создадим Connection (абстакция реального соединения)
4. Создадим Session со следующими свойствами
· Найдем Destination с помощью JNDI queue.
· 5.1. проверяем есть ли Queue в JNDI
· 5.2. Если еще не существует (не зарегистрирована в JNDI) – создадим и зарегистрируемекта Destination
· Создадим простейшее текстовое сообщение textMessag
· Создадим MessageProducer (объект посылающий сообщение в рoint-to-рoint имеет тип QueueSender)
9. Пошлем сообщение.
Существует два пути получения сообщений:
Первый – синхронное затребование сообщений из queue, используя метод receive() интерфейса javax.jms.QueueReceiver.
Второй – асинхронное получение сообщений как только они становятся доступны – используя интерфейс javax.jms.MessageListener.
46. Особенности использования модели PUB-SUB(алгоритм и шаги реализации).
Publish-subscribe (Pub-sub) модель применима, когда одному или неск-м компонентам (publishers) необх. послать сообщение одному или неск-м компонентам-адресатам (subscribers). Данная модель основана на понятии message topic(топики). Сам объект Topic предст. незав. от сетевой реализации пункт назначения, в к-й будет отпр-но сообщение. Publishers посылают сообщения в topic, и все subscribers данного topic получают эти сообщения.
Тема предст. соб. аналог списка рассылки: любое прил-е, облад-е дост-ми правами, может принимать сообщения из темы и посылать сообщения в тему. Когда клиент JMS принимает сообщения из темы, говорят, что клиент подписан (subscribed) на данную тему. JMS разделяет прикладные программы, позволяя им посылать сообщения друг другу через пункт назначения, который работает в качестве вирт-го канала.
Какую именно модель исп-ть – это зависит от хар-ра системы и, какой MOM-продукт исп-тся. Не все реализации поддерживают обе модели. Pub-sub модель кажется более элегантной, но следует помнить, что многие pub-sub системы не гарант-т доставку сообщений в том порядке, в каком они были посланы (в отличие от point-to-point, где queue реализует принцип first-in/first-out). Поэтому в случае pub-sub модели следует по возможности избегать ситуаций, когда порядок следования сообщений важен (либо использовать заголовки и раздел свойств сообщений для синхронизации). В JMS сообщения посылаются в пункт назначения (тему или очередь), а не другим прикладным программам непосредственно.
Алгоритм реализации:
· Сначала найдем сервис JNDI, инициализируем
· Найдем ConnectionFactory
· Создадим TopicConnection соединении
· Создадим TopicSession
· Найдем topic в дереве JNDI (или создадим новый, если он не существует)
· Создадим простейшее текстовое сообщение textMessage
· Создадим MessageProducer, (в данном случае TopicPublisher)
· Посылаем сообщение.
В Pub-Sub subscriber существует два способа получения сообщения:
· синхронный, с использованием метода receive() интерфейса TopicSubscriber
· асинхронный, с использованием интерфейса MessageListener.
В синхронном варианте, получив (либо создав) Topic, создадим consumer (объект принимающий сообщения): TopicSubscriber subscriber = session.createSubscriber(topic);
После активизации connection, вы можете получать сообщения: TextMessage textMessage = (TextMessage)subscriber.receive();
В случае асинхронного получения сообщений реализуйте метод onMessage интерфейса MessageListener, и зарегистрируйте новый Listener с помощью метода setMessageListener интерфейса TopicSubscriber.