Существует две "основных" модели обмена сообщениями:
Point-to-point модель применяется, когда одному или нескольким компонентам (так называемые senders) необходимо послать сообщение одному компоненту-адресату (receiver).
Подход PTP базируется на концепции очередей сообщений, отправителей и получателей. Каждое сообщение адресуется в определенную очередь, и получающие их клиенты извлекают их из соответствующих очередей. Очереди содержат все отправленные в них сообщения, пока они не будут забраны, либо пока не истечет срок хранения.
Характеристики ptp messaging следующие:
- Каждое сообщение имеет только одного потребителя.
- Отправитель и получатель сообщения не зависят от времени.
- Получатель может достать сообщение независимо от того, был ли он запущен во время отправки сообщения.
- Получатель узнает об успешной обработке сообщения.
Publish-subscribe (Pub-sub) модель применима, когда одному или нескольким компонентам (publishers) необходимо послать сообщение одному или нескольким компонентам-адресатам (subscribers). Данная модель основана на понятии message topic.
В этом случае клиент адресует сообщение в topic (набор тем. Публикаторы и подписчики обычно анонимны и могут динамически публиковать и подписываться на сообщения в пределах иерархии содержания топика. Система заботится о распределении сообщений, прибывших от множества публикаторов, множеству подписчиков. Топики содержат сообщения столько времени, сколько требуется на распределение их подписчикам.
Характеристики:
- Каждое сообщение может иметь множество потребителей.
- Публикаторы и подписчики зависят от времени. Клиент, который подписывается на топик, может потребить только то сообщение, которое пришло после его подписки. Для потребления сообщений подписчик должен оставаться активным. JMS API ослабляет эту временную зависимость, предусматривая создание подписчиками длительных подписок (durable subscriptions), которые позволяют получать сообщения, отправленные в то время, когда подписчики были не активны.
Java Message Service (JMS) – это Java API (то есть набор интерфейсов и классов) для работы с Message-Oriented Middleware (МОМ). Данный набор определен в пакете javax.jms в дереве пакетов J2EE
Клиент начинает работу с нахождения фабрики соединения и очереди:
1). QueueConnectionFactory queueConnectionFactory = (QueueConnectionFactory)
jndiContext.lookup
("java:comp/env/jms/MyQueueConnectionFactory"); //фабрика
queue = (Queue)
jndiContext.lookup("java:comp/env/jms/QueueName");//очередь
Далее клиент создает соединение очереди, сеанс и отправителя:
queueConnection=queueConnectionFactory.createQueueConnection(); //очередь
queueSession =queueConnection.createQueueSession(false, Session.AUTO_ACKNOWLEDGE); //сессия
queueSender = queueSession.createSender(queue);//создать отправит.
Наконец, клиент посылает несколько сообщений в очередь:
message = queueSession.createTextMessage();
for (int i = 0; i < NUM_MSGS; i++) {
message.setText("This is message " + (i + 1));
System.out.println("Sending message: " +
message.getText());
queueSender.send(message);
}
22. Организация клиент-серверного взаимодействия на JMS (обобщенный алгоритм реализации взаимодействия). Код серверной части JMS. КСЮША
Java Message Service (JMS) – это Java API (то есть набор интерфейсов и классов) для работы с Message-Oriented Middleware (МОМ). Данный набор определен в пакете javax.jms в дереве пакетов J2EE
Существует две "основных" модели обмена сообщениями:
Point-to-point модель применяется, когда одному или нескольким компонентам (так называемые senders) необходимо послать сообщение одному компоненту-адресату (receiver).
Подход PTP базируется на концепции очередей сообщений, отправителей и получателей. Каждое сообщение адресуется в определенную очередь, и получающие их клиенты извлекают их из соответствующих очередей. Очереди содержат все отправленные в них сообщения, пока они не будут забраны, либо пока не истечет срок хранения.
Характеристики PTP messaging следующие:
- Каждое сообщение имеет только одного потребителя.
- Отправитель и получатель сообщения не зависят от времени.
- Получатель может достать сообщение независимо от того, был ли он запущен во время отправки сообщения.
- Получатель узнает об успешной обработке сообщения.
Publish-subscribe (Pub-sub) модель применима, когда одному или нескольким компонентам (publishers) необходимо послать сообщение одному или нескольким компонентам-адресатам (subscribers). Данная модель основана на понятии message topic.
В этом случае клиент адресует сообщение в 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.
public class MySender {
public static void main(String[] args) {
try { //Create and start connection
InitialContext ctx=new InitialContext();
TopicConnectionFactory f=(TopicConnectionFactory)ctx.lookup("myTopicConnectionFactory");
TopicConnection con=f.createTopicConnection();
con.start();
//2) create queue session
TopicSession ses=con.createTopicSession(false,Session.AUTO_ACKNOWLEDGE);
//3) get the Topic object
Topic t=(Topic)ctx.lookup("myTopic");
//4)create TopicPublisher object
TopicPublisher publisher=ses.createPublisher(t);
//5) create TextMessage object
TextMessage msg=ses.createTextMessage();
//6) write message
BufferedReader b=new BufferedReader(new InputStreamReader(System.in));
while(true)
{
System.out.println("Enter Msg, end to terminate:");
String s=b.readLine();
if (s.equals("end"))
break;
msg.setText(s);
//7) send message
publisher.publish(msg);
System.out.println("Message successfully sent.");
}
//8) connection close
con.close();
}catch(Exception e){System.out.println(e);} } }
public class MyReceiver {
public static void main(String[] args) {
try {
//1) Create and start connection
InitialContext ctx=new InitialContext();
TopicConnectionFactory f=(TopicConnectionFactory)ctx.lookup("myTopicConnectionFactory");
TopicConnection con=f.createTopicConnection();
con.start();
//2) create topic session
TopicSession ses=con.createTopicSession(false, Session.AUTO_ACKNOWLEDGE);
//3) get the Topic object
Topic t=(Topic)ctx.lookup("myTopic");
//4)create TopicSubscriber
TopicSubscriber receiver=ses.createSubscriber(t);
//5) create listener object
MyListener listener=new MyListener();
//6) register the listener object with subscriber
receiver.setMessageListener(listener);
System.out.println("Subscriber1 is ready, waiting for messages...");
System.out.println("press Ctrl+c to shutdown...");
while(true){
Thread.sleep(1000); }
}catch(Exception e){System.out.println(e);} } }
public class MyListener implements MessageListener {
public void onMessage(Message m) {
try{
TextMessage msg=(TextMessage)m;
System.out.println("following message is received:"+msg.getText());
}catch(JMSException e){System.out.println(e);}
}
}
23. Модели использования JMS. Основные объекты и термины, их назначение. Особенности использования модели Point - to – Point (пример реализации алгоритма и шаги реализации при разработке клиента и сервера). ЯНА
Приложение JMS состоит из следующих частей.
Провайдер JMS — это система обмена сообщениями, которая реализует интерфейсы JMS и предоставляет функции администрирования и управления. Реализация платформы Java EE, поддерживающая полный профиль, включает провайдера JMS.
JMS-клиенты — это программы или компоненты Java, отправляющие и получающие сообщения. Любой компонент приложения Java EE может выступать в качестве клиента JMS. Приложения Java SE также могут выступать как клиенты JMS. Руководство разработчика по очереди сообщений для клиентов Java в документации сервера GlassFish (https://javaee.github.io/glassfish/documentation) объясняет, как это сделать.
Сообщения — это объекты, которые передают информацию между клиентами JMS.
Администрируемые объекты — это объекты JMS, настроенные для использования клиентами. Два вида администрируемых объектов JMS — пункты назначения и фабрики соединений — описаны в Администрируемые объекты JMS. Администратор может создавать объекты, доступные всем приложениям, использующим конкретную установку сервера GlassFish. Альтернативно, разработчик может использовать аннотации для создания объектов, специфичных для конкретного приложения.
Продукт или приложение "точка-точка" основаны на концепции очередей сообщений, отправителей и получателей. Каждое сообщение адресовано определённой очереди, и получающие клиенты извлекают сообщения из очередей, созданных для хранения сообщений. Все отправленные сообщения сохраняются в очереди до тех пор, пока не будут извлечены или не истечёт время их хранения.
Обмен сообщениями "точка-точка", показанный на рисунке, имеет следующие характеристики.
Каждое сообщение имеет только одного потребителя.
Получатель извлекает сообщение независимо от того, был ли он запущен в момент отправки сообщения клиентом.
Используйте сообщения "точка-точка" в том случае, когда каждое отправленное сообщение предназначено только одному потребителю.
Строительные блоки JMS-приложения:
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;
Посылаем сообщение
24. Модели использования JMS. Основные объекты и термины, их назначение Особенности использования модели PUB-SUB (пример реализации алгоритма и шаги реализации при разработке клиента и сервера). САША
Java Message Service (JMS) – это Java API для работы с Message-Oriented Middleware (МОМ). Данный набор определен в пакете javax.jms в дереве пакетов J2EE.
В Messaging System приложения общаются не напрямую, а посредством MOM (промежуточного программного обеспечения). Если один компонент системы хочет послать сообщение другому компоненту, он посылает данное сообщение MOM, а уж MOM затем пересылает его адресату.
MOM реализует асинхронность обмена сообщениями.
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.