Является ли Apache ServiceMix возможным решением? Это достаточно быстро? - PullRequest
1 голос
/ 06 сентября 2011

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

Я намерен создать компонент для обработки каждого поставщика услуг. Компонент будет слабо связан, и поэтому будет очень легко добавлять или удалять поставщиков услуг.

enter image description here

Компонент будет

  1. Обработать запрос, полученный от веб-уровня, и обработать его для перевода в формат, требуемый поставщиком услуг.
  2. Отправить запрос поставщику услуг
  3. Обработка ответа, полученного от поставщика услуг, для перевода его в формат, требуемый нашим приложением.

Можем ли мы использовать Apache Service Mix здесь? Достаточно ли быстро, чтобы обработать цикл запрос-ответ менее чем за 5 секунд (при условии, что поставщики услуг отправляют ответы менее чем за секунду).

ИЛИ

Можем ли мы использовать какой-либо другой ESB и достаточно ли быстр ESB для удовлетворения наших требований?

Заранее спасибо.

Shardul.

Ответы [ 6 ]

6 голосов
/ 06 сентября 2011

Servicemix должен быть в состоянии справиться с этим. Главный вопрос, если вам даже нужно servicemix.

Если вы хотите, чтобы ваши компоненты работали в OSGi, вы можете использовать servicemix или karaf + camel (что-то вроде lightmix light).

Для связи между веб-интерфейсом и компонентом я бы использовал jms, а для реализации компонента я предлагаю использовать camel + pojos.

Если вам нужна дополнительная помощь, свяжитесь со мной снова. Кажется, вы уже нашли меня на IRC :-) имя пользователя: cschneide или cschneider

3 голосов
/ 12 сентября 2011

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

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

1 голос
/ 07 сентября 2011

На FuseESB версии 4.2 я достиг 15 000 вызовов в секунду на ноутбуке DualCore с 2 ГБ ОЗУ.Звонки были сделаны в службу CXF, предоставляемую ServiceMix.Внутри был вызван один бин Spring, внедренный OSGi, который просто возвращал случайные данные.И ServiceMix может быть кластеризован.Поэтому я думаю, что он достаточно быстрый как контейнер Java.

0 голосов
/ 20 февраля 2013

Для получения последней информации о производительности ESB, вы можете посмотреть ESB Performance - создание самого быстрого ESB

0 голосов
/ 26 марта 2012

Относительно "достаточно быстро?"Фактически вы можете взглянуть на http://esbperformance.org для сравнения производительности 8 ESB с открытым исходным кодом.В то время как большинство ESB в настоящее время работают действительно хорошо, UltraESB является самым эффективным ESB.

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

Фильтр будет решать, какой поток следует вызывать, основываясь на содержимом сообщения или свойствах, таких как входящий URL-адрес и т. Д., И перенаправлять в нужный поток.Каждый поток должен быть снабжен необходимой логикой преобразования для вызова поставщика услуг.Точно так же обратный ответ будет отправлен правильному потоку для выполнения обратного преобразования.

Отказ от ответственности: я работаю в компании AdroitLogic, поддерживающей UltraESB.

0 голосов
/ 07 сентября 2011

WSO2 ESB - еще одна крутая альтернатива. WSO2 ESB основан на платформе WSO2 Carbon на основе OSGI и это 100% бесплатный и открытый исходный код и предлагает количество образцов , которые вы можете попробовать прямо из коробки. Кроме того, WSO2 - это не просто ESB, а всеобъемлющая SOA-платформа , где у нас есть ESB, Identity Server, Data Services Server, Business Process Server и т. Д., Работающие поверх Carbon на основе OSGi. Попробуйте.

...