Почему выбор JMS для асинхронного решения? Почему это лучше, чем простой компонент сущности?
В большинстве проектов я участвовал, выбором асинхронного решения был источник большого обсуждения...
Каждый раз единственного компонента сущности было достаточно для управления очередью: мы просто храним сообщение (билет) в таблице, и крон обработки не складывает очередь. Это простое решение имеет преимущество того, чтобы быть очень простым, оно основано на транзакционном контексте базы данных, и мы можем управлять состоянием полученного сообщения во время его выполнения.
Я поэтому задаю следующие вопросы:
1) Что интересует, мы должны использовать JMS? Каковы преимущества JMS?
2) В которой ситуации, предпочитая JMS по сравнению с компонентом сущности?
Спасибо за Ваши ответы и обратную связь!
1 ответ
1) Какой интерес мы должны использовать JMS? Каковы преимущества JMS? 2) в какая ситуация предпочитает JMS против Бина сущности?
Вы подходите, работает хорошо, так как есть только один потребитель . В противном случае потребуется схема блокировки, чтобы одно и то же сообщение не доставляется дважды и т. Д. Это то, что JMS предлагает из коробки: трансертированные производства и потребление с помощью JMS Broker Управление всем вопросы доставки с несколькими потребителями / производителями .
Другие преимущества ДД ММ качество обслуживания и Управление , например, , например Попытка повторной обработки, мертвая очередь сообщений, управление нагрузкой, масштабируемость, кластеризация, мониторинг и т. Д.
JMS также поддерживает публикацию-подписывание или точку до точки.
Это немного похоже на сравнение оператора JDBC для вставки одной строки в базе данных по сравнению с полной стержеством ORM. Оба работают, чтобы вставить строку в БД, но ORM предоставит намного больше, плюс вы не изобретете колесо, чтобы иметь дело с проблемами низкого уровня ... (аналогия не так велика, но Ну)