Почему я должен использовать JMS, а не RMI+Queue?

Другие ответы охватывают многие аспекты JMS, но я чувствую, что очень важный из них нуждается в большем акценте, а именно тот факт, что JMS поддерживает несколько одновременных потребителей в транзакционном способе. Это для меня функция Убийцы.

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

Когда мы говорим о JMS масштабируемости , мы, однако, говорим об этом: способность приложение. сервер для добавления / удаления потребителя / производителя для управления нагрузкой.

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

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

Что вы используете для части вашего решения" очередь"? Твой собственный код?

JMS - это всего лишь API над системой массового обслуживания некоторых поставщиков, но он включает в себя аспекты удаленного доступа. Поэтому с точки зрения клиента вы просто помещаете сообщение в очередь (или тему, Если вы делаете Pub sub) и забываете о нем. Инфраструктура доставляет его слушателю(слушателям).

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

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

Я думаю, что справедливо сказать, что JMS и остальная часть Java EE предназначена для того, чтобы ваше приложение было корпоративного качества. Первоначально я думал, что Java EE overal была сложной, хотя я думал, что JMS был одним из более простых углов. Сегодня я не уверен, что написать RMI + свою собственную очередь проще, чем просто использовать JMS.

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

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

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

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

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