Для чего подходит JMS?

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

Гипотетическим примером такой системы является то, что всем новым зарегистрированным пользователям следует отправлять приветственное электронное письмо в течение 24 часов после регистрации. Для аргумента предположим, что БД не записывает время, когда каждый пользователь зарегистрировался, но вместо этого ссылочный (внешний ключ) каждому новому пользователю хранится в таблице pending_email. Задача отправителя электронной почты выполняется один раз каждые 24 часа, отправляет электронное письмо всем пользователям в этой таблице, а затем удаляет все записи pending_email.

Это похоже на проблему, для которой JMS следует использовать, но мне непонятно, какая польза JMS для описанного мной подхода. Одним из преимуществ подхода БД является то, что сообщения являются постоянными. Я понимаю, что очереди сообщений JMS также могут сохраняться, но в этом случае, по-видимому, мало различий между JMS и подходом "база данных как очередь сообщений", который я описал?

Что мне не хватает? - Дон

Ответ 1

JMS и обмен сообщениями действительно о 2 совершенно разных вещах.

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

Подробнее о о том, как очередь сопоставляется с темой

Дело, о котором вы говорите, - это второй случай, когда да, вы можете использовать таблицу базы данных, чтобы подобрать имидж очереди сообщений.

Основное отличие состоит в том, что очередь сообщений JMS представляет собой высокопроизводительный высокопроизводительный балансировщик нагрузки, предназначенный для большой пропускной способности; вы можете отправлять обычно десятки тысяч сообщений в секунду многим параллельным потребителям во многих процессах и потоках. Причина этого в том, что очередь сообщений в основном очень асинхронна - хороший поставщик JMS будет передавать сообщения досрочно каждому пользователю, чтобы тысячи сообщений доступны для обработки в ОЗУ, как только потребитель будет доступен. Это приводит к массивной пропускной способности и очень низкой задержке.

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

При использовании таблицы базы данных обычно один поток имеет тенденцию блокировать всю таблицу, поэтому вы пытаетесь получить очень низкую пропускную способность при попытке реализовать высокопроизводительный балансировщик нагрузки.

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

Ответ 2

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

Асинхронная связь. Приложению необходимо уведомить другого о том, что событие произошло, и не нужно ждать ответа.
Надежность. Обеспечьте доставку сообщений один раз и один раз. С вашим подходом DB вы должны "изобретать колесо", особенно если у вас несколько клиентов, читающих сообщения.
Свободная связь. Не все системы могут связываться с использованием базы данных. Таким образом, JMS очень хорош для использования в гетерогенных средах с развязанными системами, которые могут связываться через границы системы.

Ответ 3

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

Ответ 4

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

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

Ответ 5

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

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

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

c) Балансировка нагрузки - если есть много сообщений, легко получить пул обработчиков сообщений в JMS.

d) В общем случае реализация через JMS будет проще и потребует меньше усилий, чем маршрут базы данных

Ответ 6

Guido имеет полное определение. По моему опыту все это важно для хорошей подгонки.

Одно из применений, которое я видел, - это распределение заказов на складах. Представьте себе компанию по поставкам канцелярских товаров, в которой имеется большое количество складов, которые снабжают большие офисы офисными принадлежностями. Эти заказы выйдут в центральное место, а затем будут собраны для правильного склада для распространения. В большинстве случаев на складах нет или требуется высокоскоростное соединение, поэтому заказы нажимаются на них по модемам dialup, и здесь происходит асинхронное подключение. Телефонные линии на самом деле не так важны, так что половина заказов может попасть и здесь важна надежность.

Ответ 7

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

Банки - яркий пример, при котором внутридневные сообщения используются для передачи живых изменений данных по мере их возникновения. Это очень легко для исходной системы бросить сообщение "над стеной"; недостаток очень мало в том, что касается контракта между этими системами, и вы обычно видите, что госпитализация осуществляется на стороне потребителя. Он почти слишком слабо связан.

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

Ответ 8

Там хорошая запись с некоторыми примерами здесь: http://www.winslam.com/laramee/jms/index.html

Ответ 9

JMS - это API, используемый для передачи сообщений между двумя или более клиентами. Спецификации определены в JSR 914.

The major advantage of JMS is the decoupled nature of communicating 
entities - Sender need not have information about the receivers.Other advantages
include the ability to integrate heterogeneous platforms, reduce system 
bottlenecks, increase scalability, and respond more quickly to change.

JMS - это просто интерфейсы /API, и конкретные классы должны быть реализованы. Они уже реализованы различными организациями/поставщиками. они называются провайдерами JMS. Пример WebSphere от IBM или FioranoMQ Fiorano Software или ActiveMQ от Apache, HornetQ, OpenMQ и т.д. Другими используемыми терминами являются объекты администрирования (темы, очереди, подключения), разработчик/издатель JMS, клиент JMS и само сообщение.

Итак, на ваш вопрос - what is JMS good for? Я хотел бы привести практический пример, чтобы проиллюстрировать его важность.

Дневная торговля

Эта функция называется LVC (кеш последнего значения)

В торговле цены акций публикуются издателем через определенные промежутки времени. Каждая доля имеет связанную с ней тему, к которой она опубликована. Теперь, если вы знаете, что такое Тема, вы должны знать, что сообщения не сохраняются как очереди. Сообщения публикуются подписчикам, живым на момент публикации сообщения (Исключение составляют абоненты Durables, которые получают все сообщения, опубликованные с момента его создания, но затем снова мы не хотим получать слишком старые цены акций, которые отбрасывают возможность используй это). Поэтому, если клиент хочет знать цену акций, он создает подписчика, а затем ему приходится ждать, пока не будет опубликована следующая цена акций (что опять не то, что мы хотим). Здесь LVC входит в картину. Каждое сообщение LVC имеет связанный ключ. Если сообщения отправляются с ключом LVC (для определенного запаса), а затем другим сообщением об обновлении с одним и тем же ключом, то последующее переопределяет предыдущее. Когда подписчик подписывается на тему (с поддержкой LVC), абонент получает все сообщения с отдельными ключами LVC. Если мы сохраним отдельный ключ в каждой зарегистрированной компании, тогда, когда клиент подпишет его, он получит последнюю цену акций и, в конечном итоге, все обновления.

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

Ответ 10

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

Ответ 11

JMS в сочетании с JTA (Java Transaction API) и JPA (Java persistence API) могут быть очень полезными. С помощью простой аннотации вы можете поместить несколько операций с базой данных + отправку/получение сообщений в одной транзакции. Поэтому, если один из них не работает, все откатывается с использованием одного и того же механизма транзакций.