Как JMS Receive работает внутри?

Question

Я изучал различные коммуникационные технологии / архитектуры / шаблоны / реализации (читай: умные слова), включая веб-сервисы (WCF, Axis2), ESB, SOA, и хотел узнать больше о JMS в отношении обмена сообщениями.

Концептуально JMS звучит просто. Я считаю, что это промежуточный брокер, который управляет сообщениями от издателей и направляет их соответствующим подписчикам. Это делается путем помещения сообщений в очередь по мере их публикации и удаления их из очереди по мере их получения.

Вопрос 1: Правильно ли мое базовое понимание JMS?

Одна из вещей, которая мешает мне при чтении о технологиях, это когда определенный уровень (преднамеренного или непреднамеренного) махания рукой делается для какой-либо функции.

Исходя из моего базового понимания, для отправки или получения сообщений должен быть запущен JMS-провайдер. Мое предположение о публикации заключается в том, что JMS-провайдер просто ждет публикации сообщения и сохраняет его в очереди (в зависимости от реализации или в памяти или в базе данных). Тем не менее, я не совсем уверен, как работает прием.

Вопрос 2: Получает ли (как правило) блокировку, если нет доступных сообщений?

Вопрос 2b: Если да, то как достигается блокировка? Клиент постоянно опрашивает сообщения? Сервер просто не отвечает, пока сообщение не опубликовано (как это работает без тайм-аута?) Инициирует ли провайдер вызов получателю?

Вопрос 2c: Если нет, то как обеспечить своевременное получение сообщений без ущерба для производительности?

Базовое описание, кажется, склоняется к одному провайдеру JMS, чтобы гарантировать централизованное управление сообщениями, а не потерю. Я вижу, что проблема заключается в масштабировании.

Вопрос 3: Как масштабируется JMS?

При масштабировании я вижу сложности с обеспечением доставки одного сообщения всем соответствующим подписчикам, независимо от того, какой физический сервер получает сообщение.

Вопрос 3b: Как реализация JMS обеспечивает надежную доставку в масштабируемой среде?

Обратите внимание, что хотя эти вопросы относятся к JMS, они, вероятно, относятся к любой инфраструктуре обмена сообщениями. Я приветствую ответы, специфичные для JMS, а также ответы, которые являются более общими или даже специфичными для другой технологии.

Answer 1

Я пытаюсь ответить на несколько вопросов, основываясь на моем опыте в JMS.

Ответ 1: - JMS - API службы сообщений Java; это обеспечивает единый интерфейс для клиентов Java для доступа к структуре обмена сообщениями. Под JMS API находится поставщик сообщений, совместимый с JMS, например, поставщик WebSphere MQ. JMS поддерживает передачу полезной нагрузки по любому протоколу обмена сообщениями в пункты назначения. Очередь и Тема. Это основы JMS.

Как работает прием? Спецификация JMS предоставляет два важных класса: - MessageConsumer и MessageListener. Класс MessageConsumer позволяет клиенту JMS синхронно получать сообщения JMS, вызывая любой из его методов receive(). Этот вызов будет блокировать поток, пока сообщение не будет получено. В противном случае асинхронный прием может быть выполнен путем регистрации объекта MessageListener с помощью MessageConsumer. Именно JMSProvider узнает, что сообщение доставлено в его локальное место назначения, и его задача - доставлять сообщения либо в поток потребителя сообщений опроса, либо в поток не зарегистрированных опросов прослушивателей сообщений.

Ответ 2: - MessageConsumer API имеет два варианта получения: receive() и receive(long timeout). Последний вариант позволяет MessageConsumer блокировать поток до тех пор, пока сообщение не поступит в течение определенного периода времени ожидания, или же оно не истечет.

Различные структуры обмена сообщениями могут реализовывать функцию блокировки по-разному. Поскольку объекты JMS являются объектами, управляемыми JNDI, а прокси-объекты конкретного провайдера возвращаются клиенту JMS, это означает, что клиент не знает о том, как происходит блокировка в фоновом режиме. Конкретная структура обмена сообщениями может выбирать опрос потока потребителя сообщений после определенного периода времени. Кроме того, он может заблокировать, пока не будет отправлено уведомление.

Я не уверен, ищите ли вы ответ для конкретной платформы обмена сообщениями, совместимой с JMS?

Ответ 3: - Я предполагаю, что при масштабировании JMS вы имеете в виду возможность иметь много издателей / подписчиков, множество направлений на нескольких физических машинах. Для масштабирования JMS требуется поддержка основного провайдера обмена сообщениями для поддержки некоторого рода кластеризации / отработки отказа. Как таковая спецификация JMS не поддерживает масштабируемость. Поправьте меня, если я ошибаюсь по этому поводу? Например, я работал над JMS-совместимым WebSphere MQ, который обеспечивает поддержку кластеризации.

Answer 2

Вопрос 1: Правильно ли мое базовое понимание JMS?

Давайте сначала разберемся с терминологией.Вы не можете сказать JMS Provider must be running, потому что провайдер - это объект, который создал сервер JMS, и это должен быть сервер JMS.Следовательно, когда мы говорим JMS, мы имеем в виду набор API (более технически - интерфейсов), которые реализуют поставщики.Так что в основном провайдеры пишут свою собственную реализацию JMS.Например, Active MQ is a JMS server, предоставляемый Apache(provider)

Мое предположение о публикации заключается в том, что провайдер JMS просто ждет публикации сообщения, а затем сохраняет его в очереди (память или база данных).поддерживается, в зависимости от реализации).

Правда в некоторой степени.Есть разные модели, которые следуют.JMS-сервер держит сокет открытым.Всякий раз, когда клиент-отправитель должен отправить сообщение, он просто открывает соединение с сокетом и отправляет сообщение.Как получать ведет себя совершенно иначе.У вас есть pull и push .В push-сервер отправит сообщения клиенту живого получателя, как только он получит сообщение.Это также называется асинхронный режим .В модели «pull» клиентский приемник отправляет запрос на сервер для получения сообщений ( синхронный режим ).

Получает ли (обычно) блокировку, если нет доступных сообщений?

Как я упоминал в предыдущем пункте, это будет зависеть от используемой вами модели.Приемник будет заблокирован в модели извлечения ( синхронный прием ).Также это происходит в потоке сеанса , а не в основном потоке.

Если так, как достигается блокировка?Клиент постоянно опрашивает сообщения?

Да, клиент будет непрерывно опрашивать в случае модели извлечения.Как правило, существует тайм-аут, после которого клиент будет прерван.

Если нет, то как обеспечить своевременное получение сообщений без ущерба для производительности?

Использование асинхронный режим .Вам просто нужно зарегистрировать MessageListener , и он получит сообщение о переопределении onMessage (Message msg) при наличии сообщений на сервере.

Вопрос 3: Как масштабируется JMS?

Это действительно вопрос для провайдеров.Когда вы говорите, что сообщение получено всеми подписчиками, вы имеете в виду модель связи PUBSUB (другое - PTP ).В PUBSUB сообщение, отправленное в тему, будет доставлено всем подписчикам, подписавшимся на эту тему.

Вопрос 3b: Как реализация JMS обеспечивает надежную доставку в масштабируемой среде?

Надежность?Не всегда.Опять же, это зависит от варианта использования.Вы можете иметь постоянных , а также непостоянных сообщений.В случае постоянных сообщений, сообщения хранятся в БД (файл или другие), и его доставка обеспечивается.В случае непостоянных сообщений такой гарантии нет.Сбой сервера может привести к потере сообщения.

Answer 3

Я думаю, что следует упомянуть разницу между очередью и темой, поскольку существуют важные различия в способе доставки сообщений.

Очередь: только один клиент получит сообщение. Для масштабирования, например, вы можете иметь 10 клиентов, подключенных к одной и той же очереди, но только один из них получит конкретное сообщение. Если ни один клиент не подключен, сообщение будет оставаться в очереди до тех пор, пока кто-либо не подключится или сообщение не прекратит работу.

Тема: все клиенты будут получать копии каждого сообщения. Обычно используется в сценарии подписчика, где множество конечных точек потенциально заинтересованы в каждом сообщении. Постоянный абонент может даже на некоторое время отключиться; сообщение будет храниться до тех пор, пока абонент не будет снова активирован или время ожидания не истечет. Если клиенты не подключены и нет постоянных подписчиков, сообщение будет отброшено.

Answer 4

JMS поддерживает потребление сообщений с помощью синхронного метода (получение с блокированием потока и без него, или с обратным вызовом, управляемым событиями (прослушиватель асинхронного сообщения)).

Вы можете решить, какой метод лучше соответствует вашим потребностям, но вам также может понадобиться посмотреть на фактическую реализацию. Например, некоторые реализации JMS выполняют обход туда и обратно по сети для receive (), и поэтому их лучше использовать с таймаутом или с прослушивателем.

С поведением потока слушателя сообщения и приостановкой приема сообщения не так легко управлять, как с блокирующим вызовом приема. Как правило, большая часть контроля достигается за счет того, что ваш собственный пул блокирует вызовы receive () с таймаутами и отправляет их вашим работникам.

Answer 5

Существует два типа доменов обмена сообщениями в JMS.

1. P oint- T o- P oint ( PTP ) Домен обмена сообщениями
2. Домен обмена сообщениями издателя / подписчика

---

В модели PTP одно сообщение доставляется только одному получателю,Здесь очередь используется как M essage O в режиме ожидания M iddleware ( MOM ).

Очередьотвечает за удержание сообщения до готовности получателя.

В модели PTP нет временной зависимости между отправителем и получателем.

---

В модели Pub / Sub всем абонентам доставляется одно сообщение.Это как трансляция.Здесь Topic используется в качестве промежуточного программного обеспечения, ориентированного на сообщения, которое отвечает за хранение и доставку сообщений.

В модели PTP существует зависимость от времени между издателем и подписчиком.

---

Модель программирования JMS

источник

---

M essage D riven B ean (MDB)

• MDB - это компонент, содержащий бизнес-логику.Но он вызывается передачей сообщения.Таким образом, это похоже на JMS Receiver.
• MDB асинхронно принимает сообщение и обрабатывает его.
• MDB получает сообщение из очереди или темы.
• MDB подобен сессионному компоненту без сохранения состояния, который инкапсулирует бизнес-логику и не поддерживает состояние компонента.