Когда использовать Java и Message Broker?

Я разработчик в своем офисе, где разработка SOA находится на пике. Мы используем IBM MQ, IBM Message Broker и технологии Java/J2EE.

В настоящее время я запущен в проект, где Message Broker используется для разработки промежуточного программного обеспечения, которое взаимодействует между двумя приложениями. Я не совсем уверен, что Message Broker является подходящим вариантом для такого проекта, поскольку Java может сделать такую же работу очень эффективным образом, что привело меня к поиску в Интернете преимуществ в использовании этих двух.

Я читал на разных сайтах, что Message Broker используется для преобразования, маршрутизации и улучшения сообщений, это очень хорошо можно сделать, используя java эффективно. Поэтому это привело меня к этому вопросу: "Когда использовать Java и когда использовать Message Broker для разработки?" Было бы здорово, если бы кто-то помог мне с преимуществами использования двух.

-RDJ

Ответ 1

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

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

Если бы вы разработали обобщенное решение для преобразования/маршрутизации на Java, вы бы разработали брокер сообщений:) Что было бы интересно, но не обязательно, потому что уже доступно множество коммерческих брокеров сообщений с открытым исходным кодом.

Ответ 2

Как я понимаю, вы пытаетесь, например, реализовать функциональность в базовой Java, а не идти с готовым Message Broker и аналогичными технологиями, связанными с SOA. Мое предложение - не изобретать велосипед. Дело в том, что даже если вы попытаетесь это сделать, в конечном итоге вы столкнетесь с теми же техническими проблемами и приведете к аналогичному решению. Почему бы не сосредоточиться на бизнес-логике, а не пытаться разработать эквивалент того, что уже есть, что, вероятно, более проверено и доверено.

Ответ 3

С более практической точки зрения брокер сообщений websphere предлагает способ интеграции приложений, отличных от Java (C, COBOL, PHP, VB...), которые часто трудно выполнить с помощью java.

Кроме того, Java не особенно хорошо подходит для обработки XML. И ESQL, и XSLT являются гораздо лучшими транспортными средствами для преобразования xml, которые Java.

Брокер сообщений Webshpere также может иметь дело с сообщениями за пределами ограничений JMS (он также может работать с JMS).

Вы можете посмотреть на ESB Websphere, который похож на реализацию Java-брокера сообщений на Java. Этот продукт ожидает, что внешние приложения, отличные от Java, смогут адаптироваться к миру Java, поэтому он обладает меньшими возможностями интеграции, но я думаю, что пользователям java будет удобно работать.

Ответ 4

Сообщения обычно используются при интеграции гетерогенных приложений и могут использоваться в качестве замены для RPC специально, когда он является асинхронным. Он также используется для ослабления связи между приложениями и в качестве основы архитектуры, управляемой событиями. Использование сообщения для повышения масштабируемости приложений очень распространено. В некоторых случаях он используется для систем, которые не всегда доступны, но гарантируют выполнение запроса, когда они становятся доступными. Также он используется для систем, которые имеют более одного потребителя за запрос.

Ответ 5

Websphere Message Broker - это ESB, тогда как Java, с другой стороны, является языком программирования. Существуют ESB, которые используют Java в качестве своего языка реализации, например Axis, Fuse, но достаточно мощны для анализа XML файлов, организации сервисов, интеграции с системами мейнфреймов. Дизайн и разработка Webservice в Message Broker проста и удобна для пользователей. ESQL как правильно указано является мощным для преобразования XML, а обработка - это язык реализации, используемый в Message Broker. Опять же, интеграция с узлами MQ, HTTP, File является бесшовной и эффективной в MB.

Ответ 6

Первое, что нужно понять, - это то, что Java-API for Broker находится поверх C-API и не дает вам полного доступа ко всем доступным функциям.

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

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

Итак, в ESQL вы сводились к запуску с Msg1.element [1], а затем сканирование Msg2 для соответствия, чтобы оптимизировать вы можете удалять элементы из Msg2 по мере их израсходования. Тем не менее это было ужасно дорого с точки зрения ЦП, особенно когда вещи начали увеличиваться с 2000+ до 5000+. И потребовалось много времени, более 5 минут для действительно больших сообщений.

Альтернативой было использование Java-вычисления node и загрузка содержимого второго сообщения в объект дерева Java, что сократило время обработки до 3 секунд.

Итак, если вы просто выполняете преобразование, избегайте вычисления Java node. Если, однако, вы делаете что-то более сложное и/или интенсивное, то, конечно, дайте Java вычислить node попытку.