Для начала, разберемся что такое ESB и зачем системы такого класса используются в информационной инфраструктуре предприятий. На современных предприятиях используется всё большей приложений различного класса: ERP, CRM, BPM, DWH, ECM и ещё множество трех-буквенных аббревиатур. Все эти приложения используют для интеграции различные протоколы и различные форматы данных. Для того чтобы связать все эти системы между собой и используется ESB.
Итак ESB-системы выполняют следующие основные функции:
- подключение по различным протоколам
- маршрутизация запросов и сообщений
- преобразование данных
Обе системы Apache ServiceMix и Red Hat JBoss Fuse имеют в своей основе следующие компоненты:
Apache Camel реализует непосредственно функции ESB на основе паттернов EIP (Enterprise Integration Patterns). Apache Camel имеет свой DSL для задач интеграции. Существует несколько его реализаций: Spring DSL, Blueprint DSL, Java DSL, Groovy DSL, Scala DSL. Так же, в состав Apache Camel входит более 100 компонент отвечающих за подключение по различным протоколам и преобразование данных.
Apache ActiveMQ — система очередей сообщений. Реализуется различные функции обмена сообщениями: обмен сообщениями по моделям отправитель-получатель (sender-receiver), издатель-подписчик (publish-subscribe), синхронный обмен (request-response), персистентные сообщения (persistent message), поддержку транзакций, включая распределенные XA-транзакции.
Apache CXF — библиотека, реализующая функции веб-сервисов, включая SOAP и REST.
Apache Karaf — платформа для запуска приложений на основе OSGi. OSGi позволяет устанавливать, удалять и обновлять различные модули (bundle) без перезапуска всей системы и без остановки зависимых модулей. Это особенно важно в корпоративной инфраструктуре, где остановки компонент крайне нежелательны, так как могут привести к прямым финансовым потерям. В системах на основе OSGi всё является модулем (bundle): библиотеки, маршруты интеграции, подключения к ресурсам.
Для Red Hat JBoss Fuse существует альтернативный вариант запуска. Вместо Apache Karaf можно использовать Red Hat JBoss EAP.
Обе системы поддерживают отказоустойчивую (failover) конфигурацию по модели master-slave.
Встает резонный вопрос, если Apache ServiceMix и Red Hat JBoss Fuse состоят из одних и тех же компонент, реализуют одну и ту же функциональность, разрабатываются одними и теми же людьми, то зачем платить больше? Кроме указанных выше компонентов, Red Hat JBoss Fuse включает несколько дополнительных, упрощающих работу администратора и позволяющих управлять кластером.
Hawtio — графическая консоль управления, позволяющая подключать различные плагины, в том числе для управления Apache Camel, Apache ActiveMQ, Fuse Fabric и т.д… Несмотря на то что Hawtio не входит в состав Apache ServiceMix, она может быть установлена на любую версию Apache ServiceMix двумя командами.
Fuse Fabric — система управления кластером на основе Fabric8. Позволяет управлять конфигурациями узлов кластера группами или по отдельности. Поддерживает версионирование конфигурации. Так же как и Hawtio, Fabric8 может быть легко установлена на Apache ServiceMix. Кроме того, для Apache ServiceMix имеется альтернативный способ управления кластером на основе Apache Karaf Cellar.
При приобретении подписки Red Hat JBoss Fuse вы получаете поддержку от компании Red Hat и возможность использовать инструмент мониторинга Red Hat JBoss Operation Network. Для Apache ServiceMix можно использовать RHQ, open-source аналог Red Hat JBoss Operation Network. Как альтернатива, для целей мониторинга Apache ServiceMix может быть использован Apache Karaf Decanter.
Apache ServiceMix'у тоже есть чем похвастаться. В состав последних версий Apache ServiceMix входит движок бизнес-процессов Activiti, который позволяет реализовывать персистентные интеграционные процессы. Apache Camel не предназначен для реализации интеграционных взаимодействий разнесенных по времени. Если при использовании Apache Camel без Activiti происходит сбой, то все не отправленные данные будут потеряны, все транзакции откатятся. В то же время, с использованием Activiti мы можем сохранить состояние процесса в БД. Red Hat для решения подобных задач предлагает использовать Red Hat JBoss BPM Suite.
Основным преимуществом Apache ServiceMix перед Red Hat JBoss Fuse является то что Apache ServiceMix включает более новые версии компонент.
| Компонент | Apache ServiceMix | Red Hat JBoss Fuse |
|---|---|---|
| Последняя версия | 6.1.2 | 6.2.1 |
| Apache Camel | 2.16.3 | 2.15.1 |
| Apache ActiveMQ | 5.12.3 | 5.11.0 |
| Apache CXF | 3.1.5 | 3.0.4 |
| Apache Karaf | 3.0.7 | 2.4 |
Что выбрать? Универсального ответа нет. Если у вас есть команда профессионалов, имеющих опыт работы с Apache ServiceMix или Red Hat JBoss Fuse, то можно задействовать все преимущества Apache ServiceMix и заплатить при этом меньше. Если же опыт отсутствует, то поддержка от компании Red Hat не будет лишней.
Кроме рассмотренных систем, на основе Apache Camel существует Talend ESB. Но я не имел практического опыта работы с ней, поэтому в обзор она не включена.
Комментарии (18)
sshikov
03.10.2016 09:55Насчет BPM и транзакций — это вы кстати того, преувеличили…
Персистентность процессов и транзакции — вещи перпендикулярные, и друг от друга практически не зависят. Никто не мешает завести в camel route transaction manager (ровно так, как это описано в документации), и реализовать любой сценарий обработки ошибок, включая и откат транзакции, конечно. Никакой BPM движок для этого не нужен совершенно.
kefirfromperm
03.10.2016 10:46Ничего противоречащего вашим словам я не писал.
sshikov
03.10.2016 10:59Если при использовании Apache Camel без Activiti происходит сбой, то все не отправленные данные будут потеряны, все транзакции откатятся.
А вот тут, по-вашему, об Activity зачем написано? Я не знаю, может вы имели в виду что-то другое, но читается это странно, и запутывает знатно.
kefirfromperm
03.10.2016 12:35+1Ну может быть запутанно. основная мысль такая, что у Camel нет механизма сохранения состояния. Соответственно, если произойдет сбой в тот момент когда обмен еще не закончится, то все данные этого обмена будут потеряны. Если мы имеем дело с транзакционными ресурсами, то транзакции откатятся.
А вот Activiti такой механизм персистентности предоставляет. Если на полпути процесса произойдет какой-нибудь сбой, то при восстановлении работы, процесс продолжится с этого места.
Впрочем, персистентности можно добиться с использованием БД и персистентных очередей сообщений. Но это уже от задачи зависит.
igor_suhorukov
03.10.2016 15:55Activity полезен, когда аналитики могут рисовать BPMN2 диаграммы или принимающие проект, с радостью подписывают работы, если там больше диаграмм.
kefirfromperm
03.10.2016 16:30У вас есть какие-то конкретные предложения по управлению бизнес-процессами? Ну или вот частный случай, оркестрации веб-сервисов?
sshikov
03.10.2016 16:37У меня есть только печальный трехлетний опыт. К сожалению, BPMN в разработке — это скорее обуза, чем подмога. Как только вы начинаете делать что-то серьезное, вы почти со 100% вероятностью натыкаетесь на несколько врожденных недостатков диаграмм как средства для представления логики программы. Для простоты, упомяну лишь некоторые: 1. Диаграммы плохо комбинируются, и это известно со времен распространения блок-схем. 2. Диаграммы плохо версионируются, что делает их в некотором роде write once инструментом. 3. Мощность BPMN как языка недостаточна, поэтому приходится комбинировать с другими.
Activity, кстати, далеко не худший выбор в том случае, когда бизнес-процессы все-таки реально нужны.
Оркестрация — это область скорее BPEL, как мне кажется.
kefirfromperm
03.10.2016 16:45Не знаю чем вам так насолили диаграммы. Но у меня такое же мнение, что по возможности BPM'ов надо избегать. Хотя личном мне не нравятся реализации, а не сама концепция. Ни одна реализация мне не нравится. И Activiti — «далеко не худший выбор».
sshikov
03.10.2016 16:59+1Насолили? Да ничем, кроме того, что мне пришлось их несколько лет делать. Реализации — почти все отстой. И это еще мягко говоря.
Что же до концепции… То если упростить скажем пункт 2, то все выглядит так — вы делаете в IDE диаграмму. Потом вы решаете сходить скажем в отпуск. Вернувшись, вы хотите понять, что же именно в диаграмме поменялось, пока вас не было. И тут вас ждет огорчение по полной программе. Вы этого не можете сделать, или это потребует столько времени, что просто ах.
На мой взгляд — это недостаток именно концепции.
Т.е. диаграммы не позволяют развивать проект. Вы не видите истории кода, вы не понимаете, откуда взялось то или иное изменение, вы не можете слить две разные ветки разработки процесса. Слить как диаграммы — конечно, вы можете залезть в XML, и покопаться там. Но это обычно ужас-ужас.
Т.е. у вас нет простейших вещей, которые в сегодняшней разработке являются привычными и обязательным. Привычными везде — кроме мира BPM.
sshikov
Я бы выбрал чистый karaf без примесей :) Все остальное интегрируется один раз, небольшими усилиями, а в итоге практически ничем не отличается от решения из коробки.
kefirfromperm
Тоже хороший вариант.
igor_suhorukov
Не все так просто. Karaf Cellar и рядом не стоял с fabric8 для деплоймента распределенных приложений, распределенного реестра и т.п.
sshikov
Погодите, а разве fabric8 где-то привязан к ServiceMix или Fuse? Мне всегда казалось, что на чистый karaf его вполне можно прикрутить.
igor_suhorukov
fabric8 под капотом содержит сконфигурированный karaf с предустановленными бандлами. Его так легко не установить на чистый karaf.
sshikov
Да ладно. В karaf нет ровным счетом никакой магии. Все чем отличается Fuse от голого карафа — это сами некие бандлы в репозитории (папка system), и кое-что в etc (startup.properties, в основном).
Это все либо устанавливается путем копирования, либо делается сравнительно простой merge для конфигов. Один раз — а потом клонирование. Вот простой upgrade на более новые версии никто не обещал — и его так просто не сделать, да.
Можно конечно считать и наличие hawtio из коробки достоинством — но факт в том, что последняя версия ставится двумя командами и сразу работает. Также, как наличие из коробки Camel — но при этом текущая версия его вовсе не 2.16.3, а скорее 2.17.3 — т.е. решение из коробки отстает от новых версий, причем сильно.
kefirfromperm
Никто не мешает и fabric8 прикрутить.
А вообще мне сложно представить кластер ESB, такой большой, что мне понадобится вся мощь fabric8. Я, конечно, понимаю, что сейчас модно облака да контейнеры. Но в нашем кровавом энторпрайзе это всё пока где-то на горизонте чуть виднеется.
sshikov
В нашем тоже. Типовой кластер — две-три машины. В пределах 1000 бандлов, может чуть больше. Мы пока и без cellar успешно обходимся.