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

Question

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

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

Поэтому я задаю следующие вопросы:

1) Какой интерес у нас есть в использовании JMS? Каковы преимущества JMS?

2) В какой ситуации предпочтение отдается JMS-компоненту?

Спасибо за ваши ответы и отзывы!

Answer 1

1) Какой интерес у нас есть к использованию JMS? Каковы преимущества JMS? 2) В какая ситуация предпочитает JMS по сравнению с бин сущности?

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

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

JMS также поддерживает публикацию-подписку или двухточечное соединение.

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

Предлагаю вам посмотреть FAQ .

Answer 2

В Java EE существует три основных механизма работы с асинхронностью:

1. JMS
2. Шина событий CDI
3. @ Асинхронные аннотированные методы сессионных компонентов без сохранения состояния

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

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

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

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

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