Когда использовать Java и Message Broker?
Я являюсь разработчиком в своем офисе, где разработка SOA находится на пике. Мы используем IBM MQ, IBM Message Broker и Java / J2EE Technologies.
В настоящее время я вовлечен в проект, в котором Message Broker используется для разработки промежуточного программного обеспечения, которое взаимодействует между двумя приложениями. Я не совсем уверен, является ли Message Broker правильным вариантом для такого рода проектов, поскольку Java может выполнять ту же часть работы гораздо более эффективным способом, что привело меня к поиску в Интернете преимуществ в использовании обоих.
Я читал на разных сайтах, что Message Broker используется для преобразования, маршрутизации и улучшения сообщений, это очень хорошо можно сделать с помощью Java. Так что это привело меня к вопросу "Когда использовать Java и когда использовать Message Broker для разработки?" Было бы здорово, если бы кто-нибудь мог помочь мне с преимуществами использования двух.
-RDJ
2 ответа
Посредники сообщений включают, например, операторы для мониторинга всех интеграций в одном месте. Кроме того, при изменении формата данных может оказаться тривиальным определить, какие интеграции затронуты этим изменением.
Каждая отдельная интеграция, вероятно, может быть реализована на Java (или на любом другом языке, если на то пошло), но в конечном итоге вы получите набор интеграций точка-точка, что является одной из проблем, с которыми сталкиваются брокеры сообщений. решать.
Если бы вам нужно было разработать универсальное решение преобразования / маршрутизации на Java, вы бы разработали брокер сообщений :) Что было бы интересно, но не совсем необходимо, поскольку уже доступно множество коммерческих брокеров сообщений и брокеров сообщений с открытым исходным кодом.
Насколько я понимаю, вы пытаетесь, например, реализовать функциональность в ядре Java вместо использования готового брокера сообщений и аналогичных технологий, связанных с SOA. Мое предложение - не изобретайте велосипед. Дело в том, что даже если вы попытаетесь это сделать, в конечном итоге вы столкнетесь с теми же техническими проблемами и приведете к аналогичному решению. Почему бы не сосредоточиться на бизнес-логике вместо того, чтобы пытаться разработать эквивалент того, что уже есть, что, вероятно, более проверено и заслуживает доверия.