Ответ 1

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

Ответ 1: - JMS - это Java Message Service API; он обеспечивает единообразный интерфейс для клиентов 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, который обеспечивает поддержку кластеризации.

Ответ 2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ответ 3

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

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

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

Ответ 4

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

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

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

Ответ 5

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

• P oint- T o- P oint (PTP) Домен объявлений
• Домены для издателей/подписчиков

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

Очередь несет ответственность за сообщение, пока приемник не будет готов.

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

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

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

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

источник

M essage D riven B ean (MDB)

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