Что лучше: написать новый механизм рабочего процесса или использовать существующий механизм BPM: jBPM 5, Activiti 5?
Мое приложение является веб-приложением, и его производительность важна. Я сомневаюсь, что использование jBPM / Activiti приведет к увеличению производительности по сравнению с написанием простого механизма рабочего процесса.
Если я пойду на самореализацию, я пропущу визуализацию рабочего процесса. На производительность его можно обменять.
Это действительно зависит от ваших требований. Сначала посмотрите, действительно ли вам нужен механизм рабочего процесса (это или другие источники). Если вам это действительно не нужно, вероятно, вам следует избегать этого.
Если вам действительно нужно то, что обеспечивает движок рабочего процесса, я бы выбрал тот, который уже построен. Люди, которые работают с jbpm или activiti, имеют гораздо больший опыт, чем вы, в создании механизмов рабочих процессов, поэтому они, вероятно, уже настроены для повышения производительности.
Я согласен с ребятами, которые уже публиковали здесь ответы или в любом случае часть их ответов: P, но, поскольку здесь, в компании, где я сейчас работаю, у нас была аналогичная проблема, я взял на себя смелость добавить свое мнение, основываясь на нашем опыте.
Нам нужно было перенести приложение, которое использовало механизм рабочего процесса jBPM в производственные приложения, и, поскольку при поддержке приложения было довольно много проблем, мы решили посмотреть, есть ли на рынке лучшие варианты. Мы подошли к уже упомянутому списку:
Мы решили больше не использовать jBPM, поскольку наш первоначальный опыт работы с ним был не лучшим, к тому же обратная совместимость нарушалась с каждой новой выпускаемой версией.
Наконец, решение, которое мы использовали, заключалось в разработке облегченного механизма рабочего процесса, основанного на аннотациях с действиями и процессами как абстракциями. Это была более или менее государственная машина, которая выполняла свою работу.
Еще один момент, о котором стоит упомянуть при обсуждении механизма рабочих процессов, - это тот факт, что они зависят от поддерживающей БД - это было в случае с двумя механизмами рабочих процессов, с которыми я имел опыт (SAG webMethods и jPBM) - и по моему опыту, это было немного накладными расходами, особенно во время миграции между версиями.
Итак, я бы сказал, что использование механизма рабочего процесса имеет право только для приложений, которые действительно выиграют от этого, и где большая часть рабочего процесса приложений вращается вокруг самого рабочего процесса, в противном случае для работы есть более эффективные инструменты:
Что касается конечных автоматов, я наткнулся на этот ответ, который содержит довольно полную коллекцию java-фреймворков конечных автоматов.
Надеюсь это поможет.
Механизмы рабочих процессов на основе Java, такие как Activiti, Bonita или jBPM, поддерживают широкий спектр спецификации BPMN 2.0. Таким образом, вы можете моделировать процессы графическим способом. Кроме того, некоторые из этих движков имеют возможности моделирования, такие как Activiti (с Activiti Crystalball). Если вы кодируете процессы самостоятельно, вы не так гибки, когда вам нужно изменить процесс. Поэтому я бы также посоветовал использовать движок BPM на основе Java.
Я провел исследование движков с открытым исходным кодом на основе BPMN 2.0. Вот ключевые моменты, которые имели отношение к нашему конкретному варианту использования:
1. Бонита:
Bonita использует подход с нулевым кодированием, что означает, что они предоставляют простую в использовании IDE для построения ваших процессов без необходимости кодирования. Для этого у Bonita есть концепция соединителей. Например, если вы хотите использовать веб-службу, они предоставят вам графический мастер. Обратной стороной является то, что вам придется вручную написать простой XML-конверт SOAP и скопировать его в графическое текстовое поле. Проблема с этим подходом заключается в том, что вы можете реализовать только те варианты использования, которые предназначены Bonita. Если вы хотите интегрировать систему, для которой Bonita не разработала коннектор, вам придется самостоятельно запрограммировать такой коннектор, что очень болезненно. Например, Bonita предлагает соединитель SOAP для использования веб-служб SOAP. Этот соединитель работает только с SOAP 1.2, но не с SOAP 1.1 (http://community.bonitasoft.com/answers/consume-soap-11-webservices-bonita-secure-web-service-connector). Если у вас есть устаревшее приложение с SOAP 1.1, вы не сможете легко интегрировать эту систему в свой процесс. То же самое и с базами данных. Для выделенных версий баз данных существует всего несколько коннекторов баз данных. Если у вас есть версия, не соответствующая коннектору, вам придется самостоятельно ее запрограммировать.
Кроме того, Bonita не поддерживает LDAP или Active Directory Sync в бесплатной версии сообщества, что является серьезным препятствием для производственной среды. Еще одна вещь, которую следует учитывать, заключается в том, что Bonita лицензируется по лицензии GPL / LGPL, что может вызвать проблемы, если вы захотите интегрировать Bonita в другое корпоративное приложение. К тому же поддержка сообщества очень слабая. Есть несколько сообщений, которым больше двух лет, и на них до сих пор нет ответов.
Еще одна важная вещь - это бизнес-IT-согласование. Процессы моделирования - это совместная дисциплина, в которую вовлечены ИТ И бизнес-аналитики. Вот почему вам нужны адекватные инструменты для обеих групп пользователей (например, плагин Eclipse для разработчиков и простой в использовании веб-моделлер для деловых людей). Bonita предлагает только Bonita Studio, которую необходимо установить на вашем компьютере. Эта IDE довольно техническая и не подходит для бизнес-пользователей. Поэтому очень сложно реализовать бизнес-IT-согласование с Bonita.
Bonita - это инструмент BPM для очень простых и простых процессов. Из-за подхода с нулевым кодированием кривая обучения очень низкая, и вы можете очень быстро начать моделирование. Вам потребуется меньше навыков программирования, и вы сможете реализовать свои процессы без необходимости кодирования. Но как только ваши процессы станут очень сложными, Bonita может оказаться не лучшим решением из-за отсутствия гибкости. Вы можете реализовать только те варианты использования, которые предназначены Bonita.
2. jBPM:
jBPM - очень мощный движок BPM с открытым исходным кодом, который имеет множество функций. Средство веб-моделирования даже поддерживает готовые модели некоторых шаблонов рабочего процесса Ван дер Аалста (workflowpatterns.com). Business-IT-Alignment реализуем, потому что jBPM предлагает интеграцию с Eclipse, а также веб-модельер. Немного сложнее то, что, насколько мне известно, формы можно определять только в веб-моделере, но не в подключаемом модуле Eclipse. Подводя итог, jBPM - хороший кандидат для использования в компании. Нашим конкурентом была масштабируемость. jBPM основан на Drools механизма правил. Это приводит к тому, что экземпляры всего процесса сохраняются в базе данных как BLOB-объекты. Это критический момент, когда вы рассматриваете поиск и масштабируемость.
Кроме того, кривая обучения очень высока из-за сложности. jBPM не предлагает служебных задач, как предлагает BPMN-Standard. Напротив, вы должны определить свои собственные служебные задачи Java и зарегистрировать их вручную в движке, что приводит к программированию на довольно низком уровне.
3. Activiti:
В конце концов, мы выбрали Activiti, потому что это очень простой в использовании движок на основе фреймворка. Он предлагает подключаемый модуль Eclipse, а также современный веб-моделлер AngularJS. Таким образом, вы можете реализовать согласование между бизнесом и ИТ. REST-API защищен Spring Security, что означает, что вы можете очень легко расширить Engine с помощью функций единого входа. Благодаря лицензии Apache License 2.0 авторское лево отсутствует, что означает, что вы полностью свободны в использовании и расширяемости, что очень важно в продуктивной среде.
К тому же BPMN-покрытие очень хорошее. Не все элементы BPMN реализованы, но я не знаю ни одного движка, который бы это делал.
Activiti Explorer - это демонстрационный интерфейс, демонстрирующий использование API Activiti. Поскольку этот интерфейс основан на VAADIN, его можно очень легко расширить. Сообщество очень активное, а это значит, что вы можете очень быстро получить помощь, если у вас возникнут какие-либо проблемы.
Activiti предлагает хорошие точки интеграции для внешних форм-технологий, что очень важно для продуктивного использования. Форм-технологии всех кандидатов очень ограниченны. Следовательно, имеет смысл использовать стандартную технологию форм, такую как XForms, в сочетании с Engine. Даже такие более сложные вещи можно реализовать с помощью атрибута formKey-Attribute.
Activiti не следует подходу с нулевым кодированием, что означает, что вам понадобится немного кода, если вы хотите организовать службы. Но даже связь со службами SOAP может быть достигнута с помощью Java Service Task и Apache CXF. Усилия по кодированию невелики.
Я надеюсь, что мои ключевые моменты помогут принять решение. Чтобы было ясно, это не реклама Activiti. Правильный выбор продукта зависит от конкретных вариантов использования. Отмечу только самые важные моменты в нашем проекте.
Хочу добавить свои комментарии. Когда вы выбираете готовый движок, например jBPM, Activity и другие (их много), то вам придется потратить некоторое время на изучение самой системы, это может оказаться непростой задачей. Особенно, когда вам нужно автоматизировать только небольшой фрагмент кода.
Затем, когда возникает проблема, вам придется обратиться за помощью к поставщику, что не так быстро, как вы могли бы себе представить. Даже заплатить за консультацию.
И, наконец, самая важная причина, вы должны развиваться в экосистеме движка. Хотя производители склонны говорить, что их системы могут быть встроены в любые системы, это может быть не так. В конце концов вы переписываете свое приложение, чтобы оно соответствовало экосистеме BPM.
Вопрос в том, чего вы действительно хотите достичь, когда запрашиваете движок рабочего процесса.
Общая цель, которой вы хотели бы достичь с помощью механизма рабочего процесса, - стать более гибким в изменении бизнес-логики во время выполнения. Часть моделирования, безусловно, здесь одна из самых важных. BPMN 2.0 является стандартом де-факто в этой области, и все рассмотренные механизмы поддерживают этот стандарт.
Вторая цель - контролировать бизнес-процесс путем описания вопросов «что должно произойти, когда ...». И эта часть имеет прямое отношение к бизнес-требованиям, с которыми вы сталкиваетесь в своем проекте.
Некоторые механизмы рабочего процесса (Activity, JBPM) может помочь вам выполнить это требование путем "кодирования" ваших процессов. Это означает, что вы моделируете парадигму «что должно произойти, когда ...» таким образом, когда вы решаете, какая часть вашего кода (например, задача или событие) должна выполняться механизмом рабочего процесса в различные ситуации. Об этой концепции идет много дискуссий. И разработчики, естественно, задаются вопросом, может ли это быть реализовано самими собой. (На самом деле это не так просто, как кажется на первый взгляд)
Некоторые другие механизмы рабочего процесса (Imixs-Workflow, Bonita) может помочь вам ответить на требование "что должно произойти, когда ..." более ориентированным на пользователя способом. Это область управления бизнес-процессами, ориентированного на человека, которая поддерживает человеческие навыки и действия с помощью механизма рабочего процесса, ориентированного на задачи. Основное внимание уделяется распределению задач и процессов внутри организации. Механизм рабочего процесса помогает распределить задачу между определенным пользователем или группой пользователей, а также обеспечить безопасность, регистрацию и мониторинг длительного бизнес-процесса. Может быть, это то, что вы не очень хотите реализовывать самостоятельно.
Поэтому я советую не смешивать вещи, которые нужно рассматривать по отдельности, потому что рабочий процесс охватывает очень широкую область.
Я недавно открыл исходный код Piper (https://github.com/creactiviti/piper), распределенный и очень легкий, основанный на Spring, движок рабочего процесса.
Да, с моей точки зрения, нет причин, по которым вы должны писать свои собственные. Большинство структур BPM / Workflow с открытым исходным кодом чрезвычайно гибки, вам просто нужно изучить основы. Если вы выберете jBPM, вы получите гораздо больше, чем простой движок рабочего процесса, поэтому все зависит от того, что вы пытаетесь создать.
Ваше здоровье
Я бы порекомендовал вам использовать готовое решение. Учитывая, что разработка механизма рабочего процесса требует огромного количества ресурсов и времени, готовый механизм - лучший вариант. Взгляните на Workflow Engine. Это легкий компонент, который позволяет добавлять пользовательские исполняемые рабочие процессы любой сложности к любым решениям Java.
CamundaBPM - один из вариантов. Вы можете проверить здесь: https://camunda.com/
Мне тоже приходилось поступать так же в моей работе. Я включил в шорт-лист Activiti, Camunda и jBPM, так как они являются одними из самых мощных механизмов рабочего процесса с открытым исходным кодом в отрасли и могут обрабатывать сложные корпоративные процессы. Все они находятся под лицензией Apache License.
Activiti была разделена на jBPM, а Camunda была разделена на Activiti.
Что касается разработчика моделей, у Activiti и jBPM есть веб-разработчики моделей, а у Camunda - настольные модели. Activiti и jBPM также предоставляют плагины Eclipse, а Camunda - нет. Разработчики моделей Activiti и Camunda используют набор инструментов BPMN.IO. Если у вас есть требование встроить модели рабочего процесса в ваше веб-приложение, вы можете воспользоваться следующими ссылками
Если вам нужна поддержка Spring, лучше всего выбрать Camunda, поскольку Activiti упоминает в своих документах, что их поддержка Spring является экспериментальной, а jBPM не предоставляет встроенную поддержку Spring.
Что касается удобства разработчиков, у Activiti и Camunda есть хорошая документация и активное сообщество, которое поможет вам начать работу. Я нашел документацию Камунды действительно полезной. Но я слышал, что документация jBPM бесполезна и что ее сложно интегрировать.
По производительности Camunda превосходит Activiti и jBPM. Есть научные доказательства того, что двигатель Camunda BPMN работает лучше, чем двигатель Activiti. Camunda BPM 7 работает в 10 раз лучше, чем JBoss jBPM 6. Следовательно, Camunda - лучший выбор с точки зрения производительности.
Camunda обеспечивает более высокое покрытие BPMN (почти полное покрытие BPMN), чем Activiti. В отличие от Activiti и jBPM, Camunda имеет надежный уровень сохраняемости и обеспечивает расширенную защиту от взаимоблокировок. В то время как при использовании Activiti транзакции экземпляра внутри процесса по-прежнему блокируются при высоком уровне параллелизма.
Camunda BPM 7 стратегически нацелена на «удобство для разработчиков», в то время как JBoss jBPM 6 стремится к идеалу «Zero-Code-BPM». Camunda BPM 7 предлагает инновационные мощные функции, которые отсутствуют в JBoss jBPM 6, такие как CMMN, кабина и поддержка контейнеров.
Поскольку Camunda работает лучше, чем две альтернативы, и имеет высокое удобство использования, я рекомендую Camunda.
Я просматриваю информацию на этих сайтах, вы можете их посетить
Вы можете посмотреть @ Apache Ant, чтобы создать механизм рабочего процесса. Он гораздо более надежен и представляет собой чистый конечный автомат с большинством необходимых требований, которые уже встроены.
Кроме того, вы также можете встраивать различный динамический код / скрипты в язык Java / Groovy / JS, что делает его очень мощным. Также позволяет расширять задачи.
Вокруг него есть изрядное количество инструментов, или вы можете надстроить его, если требуется IDE.
Обновление: также доступен конечный автомат Spring, который относительно легкий и не раздутый: https://projects.spring.io/spring-statemachine/
