Первый взгляд на Activiti

    activiti
    На этой неделе пришлось столкнуться с 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 движка для следующего проекта, хотя я сейчас, если честно, теряюсь какой же выбор правильный.

    Similar posts

    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 38

      +1
      Вообще iBatis создает такую кучу геморроя, что страшно делается. Я-то всегда был большим сторонником JPA именно из-за его простоты, но по сравнению с iBatis Hibernate — это как букварь по сравнению с учебником по Haskell…
      • UFO just landed and posted this here
          0
          Ну я и говорю, по сравнению с JPA Hibernate выглядит трудным. Но все-таки у него не приходится в иксэмэлях писать sql…
          • UFO just landed and posted this here
              0
              Ну, в Hibernate есть вполне удобный Criteria API и свой удобный HQL.
                0
                Блин.
                А писать что-то в xml — как-то не кошерно помойму. Так что скорее правильно сказать, что меня пугает все вместе.
                А еще я пишу в нетбинс и для JPA он умеет от базы автоматически генерировать все базовые сущности и все необходимые запросы…
                А еще нынче появился Spring Roo, который делает разработку софта связанного с базами данных вообще легким и непринужденным, что на Hibernate, что на JPA
                0
                В третьей версии iBatis-а, которая теперь MyBatis, поддерживаются аннотации. SQL теперь пишется в них.
              0
              «Каждая поганка в лесу к чему нибудь да предназначена» (с) Леший из «Домовенка Кузи». Есть задачи в которых iBatis может быть лучше Hibernate — это в перую очередь когда идет разработка над существующей базой, или когда разработка идет «от базы». Но мне не показалось что Activiti относится к таким случаям
                0
                А можете поподробнее рассказать (а еще лучше статью написать :))? Я, видимо, недостаточно знаком с темой…
                  +2
                  Вам никогда не приходилсоь видеть изумленные глаза ораклистов типа «Нафига вам оракл если вы долбите его усредненными хибернетовскими запросами»? То есть, если разработка идет «от базы» — когда сначала разрабатывается база определенной структуры и вам важно какая это структура и какие запросы идут в базу, а java — это так — «тоненькая надстройка» просто что бы куда-то вывести данные — в этом случае тот контроль над SQL который дает iBatis — будет самое то. Потому как iBatis по сути дела это облагороженный JDBC (наверное JDBC как раз и должен быть как iBatis). Понятное дело, что и Hibernate можно оттьюнить что бы он слал именно те запросы что надо — просто в таком случае процесс может быть боле долгим и мучительным.
                    0
                    Так ведь в хибере можно не только Criteria API пользоваться, но и HQL! А при желании даже SQL, но зато каой удобной он делает работу с сущностями…
                      +1
                      Можно, но то что делает Hibernate «по умолчанию» очень далеко от идеала с точки зрения «суровых ораклистов». Просто на HSQL вы не напишете действительно сложный запрос причем так как вам надо со всеми нюансами. А везде писать native sql query — так получится практически тот же iBatis
                        +1
                        Причем select-ы — это одно. А представим кучу entity с кучей связей one-to-many, many-to-many, вот вы все это меняете, а потом говорите flush();
                        Какие SQL запросы пойдут в базу? Какие insert-ы и update-ы? Тут уже значительно меньше возможностей для tuning-а

                        Да и select-ы — надо же всегда следить, что бы при выводе на странице табличных данных для каждой строки не шли отдельные селекты для подсасывания связанных сущностей — то есть надо играться с fetch-ами и пр. Все это можно сделать — но все это требует времени.

                        Я сам предпочитаю использовать JPA или Hibernate, но просто хотел сказать что и iBatis имеет право на жизнь и есть случаи когда он может быть предпочтительней — и это в случаях когда вам надо четко контролировать как и где вы используете базу. Но опять-таки — по моему мнению Activiti к таким случаям не относится
                          0
                          Ну, в его праве на жизнь я не сомневаюсь. Иначе он не развивался бы и им не пользовалось такое количество народу :)

                          Мне просто по роду деятельности приходится раотать с самыми разными базами — sqlite, Линтер. мускуль, постгри, оракл… Конечно, я не знаю тонкосстей оракла, все мои «расширенные» познание оракла ограничиваются синтаксическим сахаром для джойнов…

                          А насчет fetch — мне показалось, что jpa как-то весьма грамотно с ним работает, так что все лишнее начинает вытягиваться только когда нужно.
                            0
                            Да вопрос не в том что бы лишнего не тащить — с этим как раз Lazy успешно справляется. А вот что бы максимум данных за один запрос вытянуть.
                            Например — надо вывести список из ста сущностей, у каждой есть связанная сущность, которая тоже участвует в выводе.
                            Если вы сделаете по умолчанию, то hibernate сгенерирует один запрос для селекта 100 сущностей, а потом еще 100 запросов для селекта 100 связанных сущностей. Получаем 101 sql запрос.

                            А можно было бы один SQL с join-ом обойтись. Вот теперь и объясняйте Hibernate что вам все сразу надо вытянуть. Это можно сделать — но просто так как в hibernate sql запрятан глубже — не всегда это очевидно
                              0
                              Criteria API: fetch?
                                0
                                Точнее Criteria API: jpin?
                  –1
                  Вгляд?
                    –1
                    Исправил
                    +3
                    Не могу ничего сказать про удобство разработки с iBatis и c Activity пока не знаком, но, после перехода на iBatis c Hibernate, Alfresco WCM стал работать не порядок быстрее. Мне тот релиз спас проект, т.к. были жуткие проблемы с производительностью.
                      +1
                      Простите за темность, но что такое workflow framework и зачем он нужен. Даже родная википедия умалчивает. Если не сложно расскажите подробнее use case, можно отправить и к мануалам только со сылочками пожалуйста.
                        0
                        Что-то вроде этого, только надо абстрагироваться от BPEL и WebServices: habrahabr.ru/blogs/soabpm/47538/
                          0
                          Это слишком абстрактно, понять как это применять очень мне сложно. Из введения я уяснил что существует концепция бизнесс-процесса.

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


                          Помимо этого, как я понял, существует язык стандартизации сервисов (BEPL, BPM). Фактически сервис можно считать модулем выполняющим какую-то свою задачу, неким черным ящиком (например программа написаная на Java, которая фиксирует время прихода — ухода работника с работы), способ взаимодействия с которым как раз и описывается через стандартизирующий язык.

                          После того как мы имеем n-реализованных модулей, мы можем в более абстрактной среде, возможно визуальной, устанавливать взаимосвязи между этими модулями реализуя бизнесс процесс.

                          На примере расчета з/п: сервис определяющий кол-во часов потраченных на работу -> сервис определения ставки -> сервис определения премии -> сервис перевода денег на счет работника. Задача бухгалтера зайти на сайт и нажать кнопку выплаты зарплаты :)

                          Такое мое примитивное представление, и если это так, то в моей концепции workflow framework это способ стандартизировать взаимодействие сервисов. Т.е. это язык стандартизации и различные способы организации цепочки вызовов. Это так? А если это так, не понятно причем тут hibernate, spring и прочие, в моей концепции workflow framework как раз ничего о них не ведает, все возложено на сервисы.
                            +1
                            Ваше представление в целом верно.

                            Единственное, BEPL это не язык стандартизации сервисов, а стандартизированный язык описания взаимодействия между сервисами. По сути — один из путей реализации Workflow Framework.

                            В общем случае, workflow framework не обязан взаимодействовать именно с сервисами, он может взаимодействовать, например, со спринговыми бинами.

                            Конкретно с Activiti не работал, зачем там Hibernate не знаю. Возможно для хранения внутренних состояний описываемых в Activiti бизнес-процессов. Могу ошибаться.
                              0
                              >Конкретно с Activiti не работал, зачем там Hibernate не знаю. Возможно для хранения внутренних состояний описываемых в Activiti бизнес-процессов. Могу ошибаться.

                              да, так и есть + для хранения шагов самого бизнесс-процесса
                          0
                          Как например это использовалось в EmForge — предположим bug-tracking система. В каждом проекте ошибки обрабатываются по своему — в одном проекте ошибку вносит пользователь, потом тестер проверяет воспроизводится или нет, потом manager назначает на разработчика и на релиз в котором ошибка будет исправлена, потом разработчик исправляет, тестер тестирует, а релиз-инженер включает фикс в выпускаемый проудукт. А в другом проекте где нет и manager-а, ни тестера ни релиз-индеженера все баги вылются в одну кучу, разработчики берут баги из кучи, исправляют и закрывают.
                          Все это workflow — и если написать систему (как тот же EmForge) где администратор может описывать процесс под конкретный проект — то получаем гибкий bug-tracking адаптируемый под нужды и процессы проекта.
                            +1
                            Теоретически Workflow — это конечный автомат. Не более, не менее. Описывается набором своих состояний и действиями которая, которые нужно совершить при переходе от одного состояния к другому. Чаще всего представляется графически как ориентированный граф, где узлы — определенные действия (activity), а связи — условия переходов (transitions). Иногда используется обратная схема, где узлы — это устойчивые состояния, а связи — действия для перехода от одного состояния к другому. Можно обойтись вообще без графа, создав матрицу состояний. Можно использовать декларативный язык, что делают различные Rule Engines.

                            Технически Workflow Engine обеспечивает выполнение конечного автомата (процесса). Одно важное отличие от обычной программы это то, что workflow как правило ориентирован НА ДЛИТЕЛЬНОЕ выполнение БОЛЬШОГО числа процессов, когда основное время процесс находится в состоянии ожидания внешнего события. Для этого Workflow Engine умеет сохранять состояние процесса и восстанавливать при необходимости. Таким образом основа любого Workflow — это асинхронное выполнение.

                            Чаще всего Workflow используется для организации работы персонала в компании, а также его взаимодействия для решения типовой для компании задачи (бизнес процессы). Бизнес процесс — это своего рода конвейер. Для этого Workflow предоставляет интерфейс пользователя для решения типовой задачи (формочка), а также специфический тип узлов, называемый human task.

                            Для описания процессов были созданы стандарты BPEL, BPMN и другие. Для связи Workflow с другими системами в расово верных системах используют стандарты SOA и соответственно WebServices для описания интерфейсов. Основная идея, чтобы дяденька-бизнесаналист мог мышкой думать как у него будут работать люди, а индийский программист потом вместо фигаринья быдлокода, также мышкой подцеплял сервисы и делал меппинг данных. Реально же от такого «содрудничества» нанимают еще штат обезьян, чтобы на продакшне решали проблемы и ставили подпорки.
                            0
                            а сталкивался ли кто-нибудь в продакшене с droolsflow? чем он каридально отличается от jbpm4?
                              0
                              У меня вопрос — как у него с версионированием? Т.е. запущено N экземпляров бизнес-процесса, затем в бизнес-процесс вносятся изменения. Будут ли продолжаться выполняться уже запущенные экземпляры или нет?
                                0
                                так же как и в jBPM — то есть у одного process definition может быть несколько версий. Но каждый process instance привязан к конкретной версии process definition. В случае если деплоится новая версия — предыдущие process instance продолжают жить «по старому».
                                Насколько я знаю автоматически upgrade процесса на новую версию не разруливается — делается в «ручном режиме» — и если честно — не знаю что бы это поддерживал (intalio точно не поддерживает и советует делать процессы как можно короче по времени исполнения)
                                  0
                                  У ActiveBPEL да и у почти всех BPEL-движков с версионированием реальная проблема: стоит отдеплоить новую версию процесса — экземпляры старых версий перестают исполняться.
                                    0
                                    В Intalio (базируется на Apache ODE) экземпляры старых версий продолжат работать — но как описано в старой версии процесса (новая версия будет использовать только для новых экземпляров)
                                0
                                > Родная интеграция со Spring-ом
                                Прошу прощения, где это родная интеграция со спрингом в jBPM 4? По-моему на офсайте лежит ссылка на левый мануал от одного чувака, который смог прикрутить jbpm к спрингу, и то версии 2.5. Нормального бандла для 3.0 до сих пор не существует в природе (оно и понятно). В свое время это меня остановило.

                                jBPM убил jPDL и ужасный плагин для начертания процессов. Работать неудобно и отвратно. Нужно раньше было смотреть в сторону BPMN (BPEL изначально был мертворожденный), хотя бы тулзы сторонних разработчиков можно было бы использовать. Сам по себе движок JBPM неплохой, достаточно простой и расширяемый. Но в Activi есть все, что так не хватало — интергация со спрингом, BPMN 2.0 и неплохой дизайнер процессов.
                                  0
                                  вы наверное путаете jBPM3 (который интегрировался со Spring-ом через spring-modules) и jBPM4 — у него все хорошо (уверяю вас как человек эту интеграцию использовавший).
                                  В этом плане в Activiti ничего нового нет.

                                  BPEL изначально создан для оркестрации веб-сервисов — там в принципе отсуствует понятие «user task» — что делает его неприменимум для реализации workflow (как вы выше сказали workflow чаще всего используется для «организации работы персонала в компании»). Плюс BPEL слишком технический — с трудом представляю себе бизнес аналитика описывающего бизнес-процесс на BPEL. То есть — по сути это язык выполнения — своего рода ассемблер.

                                  BPMN — это уже язык более высокого уровня — он не исключает bpel — например тот же Intalio использует BPMN для моделирования (кстати — их моделер — построеный тоже на базе Eclipse на порядки лучше того что было в jBPM, что есть сейчас в Activiti — и им еще расти и расти!) и транслирует его в BPEL для выполнения в Apache ODE. да — остается проблема — а как же пользователи (которых нет в BPEL) — для этого приходится извращаться и добавлять BPEL4PEOPLE

                                  Я это к чему — что BPMN и BPEL все таки немного разные вещи и один другого не убивает — один это язык моделирования, другой — выполнения (хотя некоторые как jBPM и Activiti выполняют BPMN напрямую)

                                    0
                                    Да знаю я этот мануал от Andries Inzé. Есть куча способов засандалить движок jBPM в программу на спринге. Я говорю о Spring 3.0 dm — сервере. У меня на нем вся ESB построена (Apache Camel). Вобщем что до сих пор ищется, это: Opensource BPMN с визуальными средствами моделирования и OSGI-deployment.

                                    Что мне было нужно, так это бандлить процессы в отдельные OSGI-модули, имеющие свой цикл жизни и поддерживающие нативно версионность. Для этого необходимо было иметь jBPM, запакованный в OSGI-модуль с API доступным на уровне OSGI-сервисов. Тем не менее, прототип был состряпан и даже вроде работал. Однако начальство сделало ошибочную ставну на Websphere.

                                    Хорошо, что есть автоматические конвертеры BPMN в BPEL, а то в нашем проекте все делается вручную: аналисты используют Tibco Studio BPMN, а программисты переписывают BPEL на WebSphere. Однако схема конвертации BPMN в BPEL обладает одним существенным недостатком: зачастую администратор хочет видеть наглядно что произошло с его процессом и где он в данный момент находится. А машинно-сгенерированный BPEL будет сильно отличаться от модели процесса.
                                  0
                                  >Надеюсь изложенная тут информация поможет вам в выборе workflow движка для >следующего проекта, хотя я сейчас, если честно, теряюсь какой же выбор правильный.
                                  После проверки

                                  www.mvnbrowser.com/artifacts-search.html?search=jbpm

                                  лично для меня пока ответ очевиден. Поддержка Мавена для activiti никакая:

                                  www.mvnbrowser.com/artifacts-search.html?search=activiti

                                  Т.е. пока Баянс не освоил прогрессивных средств разработки можно о его светлом гении забыть, т.к. минимальный upgrade вылbется в огромную Ж с «поиском нужных JARs».

                                  Для jbpm ребята уже Continuous Integration заточили, что (для меня) о многом в плане качества говорит.

                                  PS
                                  поразителная любовь к «неЛёгким путям»! 19 MB! Yet Another BlackBox.
                                    +1
                                    ан нет — таки мавен изначально запланирован. Беру свой наезд обратно.
                                    надо копнуть поглубже. Спасибо за статью.
                                      0
                                      Activiti собирается мавеном — просто видимо не выкладывают свои артифакты в центральные репозитории.

                                  Only users with full accounts can post comments. Log in, please.