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

Question

В настоящее время я использую RMI или гессианскую библиотеку для связи между моим сервером и клиентами (через LinkedBlockingQueue). Сейчас я читаю о JMS , которые можно использовать и в этой области. Это правильно? Если да, не могли бы вы дать мне простой список преимуществ / недостатков, потому что это, кажется, довольно сложная и «полноценная сфера деятельности».

Каковы преимущества? А как насчет производительности по сравнению с RMI + Queue? Может ли JMS побить RMI + Queue?

PS: я знаю, что есть похожих вопросов , но я хотел бы иметь JMS по сравнению с RMI + Queue.

Answer 1

Упрощенное сравнение будет (не для JMS, скорее для сравнения с MQ в целом) ...

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

2. Постоянная очередь
   Поскольку вы используете LinkedBlockingQueue, вы можете иметь ограниченную очередь или неограниченную очередь в памяти. Первый из них начнет перехватывать потоки, как только очередь заполнится, и в конечном итоге потерпит неудачу при высокой нагрузке. Позднее в конечном итоге вместо этого будет выбрасываться OutOfMemoryError. Однако, если вы будете использовать JMS, он может автоматически начать «сохранять» сообщения в «постоянном хранилище». Обычно «постоянное хранилище» - это БД, которая обычно имеет гораздо большую емкость, чем очередь в памяти. Конечно, содержимое очереди в памяти теряется, когда сервер выключается и т. Д., Тогда как в JMS вы можете выбрать постоянное сообщение / постоянное сообщение, которое сохраняется после такого события. Это также позволяет вам кластеризоваться, что также очень важно для корпоративных программ ...

3. абстракция
   Вы будете использовать стандартизированный API (хорошо, у вас также есть протоколы в RMI, но если вы хотите передавать сообщения, MQ обеспечивает намного более высокий уровень абстракции, чем очередь RMI + в памяти). Это означает, что вы можете использовать будущие реализации JMS. Возможно, что-то, что не требует БД для обеспечения долговечности и постоянства, более масштабируемо, чем сегодняшняя реализация и т. Д. Или, возможно, вы можете отправить одно и то же сообщение совершенно другому сервису из-за Стандеризация. По сути, более высокая абстракция может дать вам гибкость, чего нет в очереди RMI + в памяти.

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

Answer 2

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

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

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

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

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

Answer 3

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

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

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

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

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

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

Answer 4

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

Answer 5

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

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

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