Комментарии 18
Что выбрать? Универсального ответа нет.
Я бы выбрал чистый karaf без примесей :) Все остальное интегрируется один раз, небольшими усилиями, а в итоге практически ничем не отличается от решения из коробки.
Погодите, а разве fabric8 где-то привязан к ServiceMix или Fuse? Мне всегда казалось, что на чистый karaf его вполне можно прикрутить.
Да ладно. В karaf нет ровным счетом никакой магии. Все чем отличается Fuse от голого карафа — это сами некие бандлы в репозитории (папка system), и кое-что в etc (startup.properties, в основном).
Это все либо устанавливается путем копирования, либо делается сравнительно простой merge для конфигов. Один раз — а потом клонирование. Вот простой upgrade на более новые версии никто не обещал — и его так просто не сделать, да.
Можно конечно считать и наличие hawtio из коробки достоинством — но факт в том, что последняя версия ставится двумя командами и сразу работает. Также, как наличие из коробки Camel — но при этом текущая версия его вовсе не 2.16.3, а скорее 2.17.3 — т.е. решение из коробки отстает от новых версий, причем сильно.
А вообще мне сложно представить кластер ESB, такой большой, что мне понадобится вся мощь fabric8. Я, конечно, понимаю, что сейчас модно облака да контейнеры. Но в нашем кровавом энторпрайзе это всё пока где-то на горизонте чуть виднеется.
Насчет BPM и транзакций — это вы кстати того, преувеличили…
Персистентность процессов и транзакции — вещи перпендикулярные, и друг от друга практически не зависят. Никто не мешает завести в camel route transaction manager (ровно так, как это описано в документации), и реализовать любой сценарий обработки ошибок, включая и откат транзакции, конечно. Никакой BPM движок для этого не нужен совершенно.
Если при использовании Apache Camel без Activiti происходит сбой, то все не отправленные данные будут потеряны, все транзакции откатятся.
А вот тут, по-вашему, об Activity зачем написано? Я не знаю, может вы имели в виду что-то другое, но читается это странно, и запутывает знатно.
А вот Activiti такой механизм персистентности предоставляет. Если на полпути процесса произойдет какой-нибудь сбой, то при восстановлении работы, процесс продолжится с этого места.
Впрочем, персистентности можно добиться с использованием БД и персистентных очередей сообщений. Но это уже от задачи зависит.
Это сарказм был, я надеюсь? )
У меня есть только печальный трехлетний опыт. К сожалению, BPMN в разработке — это скорее обуза, чем подмога. Как только вы начинаете делать что-то серьезное, вы почти со 100% вероятностью натыкаетесь на несколько врожденных недостатков диаграмм как средства для представления логики программы. Для простоты, упомяну лишь некоторые: 1. Диаграммы плохо комбинируются, и это известно со времен распространения блок-схем. 2. Диаграммы плохо версионируются, что делает их в некотором роде write once инструментом. 3. Мощность BPMN как языка недостаточна, поэтому приходится комбинировать с другими.
Activity, кстати, далеко не худший выбор в том случае, когда бизнес-процессы все-таки реально нужны.
Оркестрация — это область скорее BPEL, как мне кажется.
Насолили? Да ничем, кроме того, что мне пришлось их несколько лет делать. Реализации — почти все отстой. И это еще мягко говоря.
Что же до концепции… То если упростить скажем пункт 2, то все выглядит так — вы делаете в IDE диаграмму. Потом вы решаете сходить скажем в отпуск. Вернувшись, вы хотите понять, что же именно в диаграмме поменялось, пока вас не было. И тут вас ждет огорчение по полной программе. Вы этого не можете сделать, или это потребует столько времени, что просто ах.
На мой взгляд — это недостаток именно концепции.
Т.е. диаграммы не позволяют развивать проект. Вы не видите истории кода, вы не понимаете, откуда взялось то или иное изменение, вы не можете слить две разные ветки разработки процесса. Слить как диаграммы — конечно, вы можете залезть в XML, и покопаться там. Но это обычно ужас-ужас.
Т.е. у вас нет простейших вещей, которые в сегодняшней разработке являются привычными и обязательным. Привычными везде — кроме мира BPM.
Обзор ESB-систем ServiceMix и Fuse