На этой неделе пришлось столкнуться с Activiti — новым workflow движком для Java, и так как тема эта еще не обсуждалась на Хабре, решил поделиться впечатлениями. Сразу скажу — впечатления немного печальные, но об этом под катом
Немного предыстории
jBPM 3
Жил да был такой workflow framework для java как jBPM. Хороший был framework (в принципе он и сейчас есть, но почему в прошедшем времени станет ясно позднее). Я его использовал еще во времена разработки первой версии EmForge. Мне этот framework нравился по нескольким причинам:
* Легкая встраиваемость в приложение — по сути дела кладешь к себе Jar-ник (с зависимостями) — и у тебя в приложении появляется поддержка конфигурируемых процессов;
* Понятное API;
* Знакомые технологии (тот же Hibernate);
* Как результат использования Hibernate — поддержка большого числа баз данных;
* «Близость» к разработчику — процессы рисуются в Eclipse, тут же можно написать unit-test который тестирует написанный процесс;
* Используемая нотация jPDL хотя и не являлась каким-либо стандартом, была удобна для описания «повседневных» процессов.
Все это в сумме делало jBPM очень дружественным в первую очередь для разработчика, при том что для «серьезных» архитекторов SOA решений оставался «игрушкой» — поддержка BPEL в jBPM не прижилась, да и выглядело это все как какое-то несерьезное, «детское» решение — ну да каждому свое. Тем не менее jBPM стал (я думаю не ошибусь) самым популярным workflow решением для java.
В той версии с которой я начал работать (jBPM 3) не все было гладко — были и проблемы. Я бы выделил:
* Интеграция со Spring Framework через «костыли» spring-modules;
* Ориентация на Hibernate — я бы предпочел использование JPA с возможностью работы с разными реализациями (улучшило бы возможности интеграции в разрабатываемое приложение);
* API было неудобно для реализации «поиска» задач и процессов — приходилось писать свои «прямые» sql-запросы, то есть лезть внутрь реализации jBPM.
* Были определенные ограничения именно в описании процессов.
С чем-то приходилось мириться, что-то обходилось костылями, что-то исправлялось собственными «надстройками». Вообщем — логично было бы ожидать от следующей версии «улучшений» и «исправлений»
jBPM 4
Однако в следующей версии — jBPM 4 разработчики пошли по пути «глубокого» рефакторинга. По сути дела был написан новый движок, с абсолютно новым API и новой базой. Не знаю, насколько надо было так все перерабатывать, но тем не менее — в новой версии были определенные плюсы:
* Родная интеграция со Spring-ом
* Более удобное описание процессов и вызовов java-кода или spring-компонент;
* API более удобное для поиска;
* Отдельное хранение в базе runtime данных и «истории» — по идее должно ускорить работу.
В целом — новая версия оставила приятное впечатление — хотя и не вся функциональность которая присутствовала в jBPM3 была в jBPM4. Из недостатков можно наверное отнести прежнюю привязку с Hibernate — хотя вполне возможно что это решение политическое — так как jBPM разрабатывался «под крылом» jBoss
Activiti
Ну что ж, код отрефакчили, можно и пользователей сатисфакать — то есть доводить новую версию до ума. Но — не тут то было. Основной разработчик jBPM — Tom Baeyens уходит из RedHat (jBoss) и переходит в Alfresco
Как результат, запускается новый проект, Activiti. Проект получает сразу версию 5.0 (намекая на продолжение jBPM) и к текущему моменту дошел до стадии 5.0.rc1. Из основных изменений:
* Hibernate выкинут — вместо него используется iBatis (колотитис!). Как я понял — решение политическое: использование только компонент под Apache лицензией (чем из LGPL компонент помешал не понимаю — это по идее не накладывает лицензионных ограничений на сам конечный продукт), плюс Alfresco по каким-то своим соображениям переходит с Hibernate на iBatis;
* Вместо jPDL используется BPMN2 нотация;
Я поработал с Activiti при реализации интеграции Activiti и Liferay. И вот некоторые впечатления от текущей версии (близкой к релизу):
* API осталось очень похожим на JBPM 4 — по сути дела поменяли пакеты и названия классов;
* Вроде как после долгих обсуждений добавили поддержку работы с базой через JPA — хотя это «experimental» и на свой страх и риск (я еще не пробовал);
* В проект влились и другие компании — что обещает более широкую поддержку (хотя jBPM тоже много кто использовали поддерживал);
Но, по сути дела — это не шаг вперед — а шаг вбок. И хорошо если дальше проект пойдет вперед — а не будет очередного «глобального» рефакторинга или ребрендеринга.
Зато в качестве минусов получаем:
* Значительно сузился список поддерживаемых баз данных (из-за отказа от Hibernate в пользу myBatis), плюс тип базы не определяется автоматом, с апгрейдом схемы тоже есть непонятки;
* Из-за отказа от jPDL в пользу BPMN2 потерялись некоторые удобные фичи которые были в jPDL (например несколько output transitions из задач). Я за использование стандартов, но там где это разумно. Процесс описанный в Activiti дизайнере нельзя будет выполнять нигде кроме Activiti, так что стандарт тут ничего не дает, а jPDL был (имхо) более удобен именно для повседневных задач (BPMN более академичен — и по сути дела является очеловеченым BPEL-ем). Вообщем понятно что тут можно спорить и спорить — но факт остается фактом — некоторые вещи, которые легко делались в jBPM 4 — нельзя сделать в Activiti;
* Качество кода мне показалось хуже. Просто бросилось в глаза — описание interface-а сервиса оперирует не только interface-ами объектов (как было в jBPM 4) — но и конкретными реализациями. например IdentitySession оперирует не только интерфейсами User & Group, но и их реализациями — UserEntity & GroupEntity. Для сравнения — тот же класс в jBPM — обратите внимание на количество javaDoc комментариев. Это все в принципе мелочи — но у меня создается впечатление что Activiti разрабатывается в некоторой спешке — что может не очень хорошо сказаться на качестве кода. (Кстати — сам не идеален — и javadoc комменты пишу далеко не всегда — но тут дело в том, что в jBPM они были — а в Activiti их не стало)
* Новой функциональности сильно обнаружено не было (с точки зрения API и разработки процессов) — а вот много чего из того что было в jBPM — «потерялось». То есть, если вы сейчас используете jBPM 4, то никаких поводов для перехода на Activiti я не вижу.
Почему в итоге мысли грустные?
* Вместо планомерного, эволюционного развития хорошего проекта получаем череду рефакторингов-ребрендерингов и «политических» прыжков, в результате которых проект (ИМХО) только теряет в функциональности;
* jBPM по сути дела мертв. Я скептически отношусь к тому, что проект продолжит жить после ухода своего основного разработчика, хотя jBoss и аннонсирует jBPM 5.0
* При этом как будет дальше жить Activiti — не совсем понятно. Возможно, что вместо одного хорошего движка мы получим два — но какие они будут?
Ладно — поплакался — и хватит. Надеюсь изложенная тут информация поможет вам в выборе workflow движка для следующего проекта, хотя я сейчас, если честно, теряюсь какой же выбор правильный.
