Для чего нужен JMS?

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

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

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

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

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

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

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

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

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

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

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

2. jms обрабатывает публикацию / подписку, что немного сложнее, чем приведенный вами пример точка-точка

3. вы не привязаны к конкретной реализации и можете поменять ее, если ваши потребности изменятся в будущем, без беспорядка с вашим java-кодом.

JMS и обмен сообщениями - это две совершенно разные вещи.

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

См. Дополнительную информацию на как очередь сравнивается с темой

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

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

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

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

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

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

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

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

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

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

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

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

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 Softwares или ActiveMQ от Apache, HornetQ, OpenMQ и т. д. Другие используемые термины: объекты администратора (темы, очереди, фабрики соединений), производитель / издатель JMS, клиент JMS и само сообщение.

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

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

Есть эта функция под названием LVC (Кэш последнего значения)

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

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