Модели использования 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.