Java topic что это
Many publish/subscribe (pub/sub) providers group topics into hierarchies and provide various options for subscribing to parts of the hierarchy. The JMS API places no restriction on what a Topic object represents. It may be a leaf in a topic hierarchy, or it may be a larger part of the hierarchy.
The organization of topics and the granularity of subscriptions to them is an important part of a pub/sub application’s architecture. The JMS API does not specify a policy for how this should be done. If an application takes advantage of a provider-specific topic-grouping mechanism, it should document this. If the application is installed using a different provider, it is the job of the administrator to construct an equivalent topic architecture and create equivalent Topic objects.
| Method Summary | |
|---|---|
| String | getTopicName () Gets the name of this topic. |
| String | toString () Returns a string representation of this object. |
getTopicName
String getTopicName() throws JMSException
Clients that depend upon the name are not portable.
Returns: the topic name Throws: JMSException — if the JMS provider implementation of Topic fails to return the topic name due to some internal error.
toString
Overrides: toString in class Object Returns: the provider-specific identity values for this topic
| Java EE 5 SDK | ||||||||
| PREV CLASS NEXT CLASS | FRAMES NO FRAMES | ||||||||
| SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD | ||||||||
Copyright 2007 Sun Microsystems, Inc. All rights reserved. Use is subject to license terms.
Работа с JMS сообщениями и MDB в JEE
Работа с сообщениями подразумевает взаимодействие между компонентами системы посредством передачи сообщений. JMS позволяет реализовать это взаимодействие в java приложении, а MDB бины позволяют асинхронно обрабатывать получаемые сообщения на сервере приложений без дополнительных усилий по асинхронной обработке.
Ниже представлен простой пример обработки JMS сообщения с помощью MDB.
Немного теории
Для работы с сообщениями используется вспомогательное программное обеспечение, обычно входящее в поставку сервера приложений.
Компоненты системы могут посылать сообщения (producer) и получать их (consumer). Сообщение
отправляет producer на пункт назначения (destination), являющимся на сервере queue или topic, после чего consumer может забрать оттуда сообщение
В зависимости от того, какой тип имеет destination, разделяют две модели работы с сообщениями.
Первая модель — Point-to-Point
В случае если на сервере destination имеет тип queue, то сообщение, которое отправил producer, получает единственный consumer. Если на эту очередь сообщений подписано несколько получателей, то сообщение получит только один из них.
Вторая модель — Publish-subscribe
В случае если на сервере destination имеет тип topic, то одно сообщение может быть прочитано неограниченным количеством consumer, подписанных на этот на этот destination.
Структура JMS сообщения
Сообщение состоит из заголовка, поля свойств и тела.
Заголовок хранит мета информацию сообщения, заполняемую автоматически.
Поле свойств схоже с заголовком, но оно заполняется программно, и позже получатель сможет прочитать эту информацию.
Тело содержит полезную нагрузку сообщения. Тип нагрузки определяется при создании сообщения. Конкретные типы унаследованы от интерфейса javax.jms.Message
Создание очереди на сервере.
Для примера создадим topic на сервере. Использовать я буду glassfish 3.1.
Для начала создадим Connection Factory. Возможны несколько типов в зависимости от того, какой тип очереди сообщений будет использоваться.
Затем создаем destination с указание типа.
Создание отправителя сообщений
В данном случае producer будет находиться на сервере приложений. В случае если вам необходимо отправлять сообщения из отдельного клиента, то необходимо будет стандартным образом получить доступ к объектам по их JNDI имени из контекста.
//получаем ресурсы сервера для отправки сообщений @Resource(name="jms/TutorialPool") private ConnectionFactory connectionFactory; @Resource(name="jms/TutorialTopic") private Destination destination; public String getEnterString() < return enterString; >public void sendString(String enterString) < try < //создаем подключение Connection connection = connectionFactory.createConnection(); Session session = connection.createSession(true, Session.AUTO_ACKNOWLEDGE); MessageProducer producer = session.createProducer(destination); TextMessage message = session.createTextMessage(); //добавим в JMS сообщение собственное свойство в поле сообщения со свойствами message.setStringProperty("clientType", "web clien"); //добавляем payload в сообщение message.setText(enterString); //отправляем сообщение producer.send(message); System.out.println("message sent"); //закрываем соединения session.close(); connection.close(); >catch (JMSException ex) < System.err.println("Sending message error"); ex.printStackTrace(); >> Message-Driven Bean
Для обработки приходящих сообщений на сервере мы будем использовать MDB.
Сообщения можно было бы получать и обрабатывать и с помошью pojo, выступающего как consumer. Но использование MDB позволит параллельно обрабатывать сообщения, не заботясь о сложности асинхронной обработки и дополнительного кода для подписки на очередь сообщений.
Асинхронная обработка реализуется через пул объектов, из которых на обработку сообщения сервер выделят объекты при необходимости.
Для реализации MBD достаточно унаследовать бин от интерфейса javax.jms.MessageListener, реализуя метод onMessage(), и аннотировать соответствующим образом класс.
Сделаем пример MDB, который выводит в консоль сервера информацию о поступившем сообщении.
@MessageDriven( //имя topic, на который подписан бин mappedName="jms/TutorialTopic", name = "ExampleMDB") public class MDBExample implements MessageListener < //метод, вызываемый при получении нового сообщения @Override public void onMessage(Message msg) < try < TextMessage message = (TextMessage)msg; //считываем свойство из соответствующего поля, заданное вручную в consumer System.out.println("FROM MDB - client type IS " + message.getStringProperty("clientType")); //считываем само сообщение System.out.println("FROM MDB - payload IS" + message.getText()); >catch (JMSException ex) < ex.printStackTrace(); >> > В onMessage метод добавляется необходимая бизнес логика, в зависимости от типа сообщения, его содержания и тд.
При необходимости, для ручной обработки сообщений можно самостоятельно создать обработчика.
Например так:
@Resource(name="jms/TutorialPool") private ConnectionFactory connectionFactory; @Resource(name="jms/TutorialTopic") private Destination destination; void onMessage() < try < Connection connection = connectionFactory.createConnection(); Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE); MessageConsumer consumer = session.createConsumer(destination); connection.start(); while(true)< Message msg = consumer.receive(); //обработка сообщения >//закрыть connection > catch (JMSException ex) < ex.printStackTrace(); >> Для более подробного изучения JMS и EJB в целом, могу рекомендовать книги:
EJB 3 in Action — Debu Panda, Reza Rahman, Derek Lane
Пару книг от Adam Bien
Java topic что это
Many publish/subscribe (pub/sub) providers group topics into hierarchies and provide various options for subscribing to parts of the hierarchy. The JMS API places no restriction on what a Topic object represents. It may be a leaf in a topic hierarchy, or it may be a larger part of the hierarchy.
The organization of topics and the granularity of subscriptions to them is an important part of a pub/sub application’s architecture. The JMS API does not specify a policy for how this should be done. If an application takes advantage of a provider-specific topic-grouping mechanism, it should document this. If the application is installed using a different provider, it is the job of the administrator to construct an equivalent topic architecture and create equivalent Topic objects.
See Also: Session#createConsumer(Destination) , Session#createProducer(Destination) , TopicSession.createTopic(String)
| Method Summary | |
|---|---|
| java.lang.String | getTopicName () Gets the name of this topic. |
| java.lang.String | toString () Returns a string representation of this object. |
getTopicName
Clients that depend upon the name are not portable.
Returns: the topic name Throws: JMSException — if the JMS provider implementation of Topic fails to return the topic name due to some internal error.
toString
Overrides: toString in class java.lang.Object Returns: the provider-specific identity values for this topic
| ||||||||
| PREV CLASS NEXT CLASS | FRAMES NO FRAMES | |||||||
| SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD | |||||||
Copyright © 2009-2011, Oracle Corporation and/or its affiliates. All Rights Reserved. Use is subject to license terms.
Generated on 10-February-2011 12:41