Лучше ли писать новый механизм документооборота или использовать существующий механизм BPM: jBPM 5, Activiti 5?
Мое приложение - это веб-приложение, и производительность важна. Я сомневаюсь, что использование jBPM/Activiti будет накладными расходами по сравнению с написанием простого механизма документооборота.
Если я пойду с самореализацией, я пропущу визуализацию рабочего процесса. Для производительности можно торговать.
Это действительно зависит от ваших требований. Во-первых, посмотрите, действительно ли вам нужен механизм рабочего процесса (этот или другие источники). Если вам это действительно не нужно, вероятно, вам следует избегать этого.
Если вам действительно нужно то, что обеспечивает механизм рабочего процесса, я бы выбрал тот, который уже построен. Люди, которые работают с jbpm или activiti, имеют гораздо больше опыта, чем вы, при создании механизмов документооборота, поэтому он, вероятно, уже настроен на повышение производительности.
Я согласен с ребятами, которые уже отправили ответы здесь или часть их ответов в любом случае: P, но, как здесь, в компании, в которой я сейчас работаю, у нас была аналогичная проблема, я позволил добавить свое мнение, основанное на наш опыт.
Нам нужно было перенести приложение, использующее механизм рабочего процесса jBPM в приложениях, связанных с производством, и, поскольку было довольно много проблем в обслуживании приложения, мы решили посмотреть, есть ли лучшие варианты на рынке. Мы пришли к упомянутому выше списку:
Мы решили больше не использовать jBPM, поскольку наш первоначальный опыт работы с ним был не лучшим, кроме того, обратная совместимость была нарушена с каждой новой версией, выпущенной.
Наконец, решение, которое мы использовали, заключалось в разработке легкого механизма документооборота на основе аннотаций, имеющих действия и процессы как абстракции. Это была более или менее государственная машина, которая выполняла эту работу.
Еще один момент, который стоит упомянуть при обсуждении механизма документооборота, заключается в том, что они зависят от базы данных резервного копирования - это было в случае с двумя механизмами документооборота, с которыми у меня есть опыт (SAG webMethods и jPBM) - и по моему опыту это было немного накладных расходов, особенно во время миграций между версиями.
Итак, я бы сказал, что использование механизма workflow имеет право только на приложения, которые действительно выиграют от него, и где большая часть рабочего процесса приложений вращается вокруг самого процесса работы, в противном случае есть лучшие инструменты для работы:
Что касается состояний машин, я столкнулся с этим ответом, который содержит довольно полную коллекцию java-фреймворков конечного автомата.
Надеюсь, что это поможет.
Механизмы рабочего процесса на основе Java, такие как Activiti, Bonita или jBPM, поддерживают широкий диапазон спецификаций BPMN 2.0. Поэтому вы можете моделировать процессы графическим способом. Кроме того, некоторые из этих двигателей имеют возможности моделирования, такие как Activiti (с Activiti Crystalball). Если вы сами кодируете процессы, вы не будете гибкими, когда вам нужно будет изменить процесс. Поэтому я бы посоветовал использовать javas-based BPM-движок.
Я провел исследование относительно двигателей с открытым исходным кодом, основанных на BPMN 2.0. Вот ключевые моменты, которые имеют отношение к нашему конкретному варианту использования:
1. Bonita:
Bonita использует подход с нулевым кодированием, что означает, что они обеспечивают простую в использовании среду IDE для создания ваших процессов без необходимости кодирования. Чтобы достичь этого, у Bonita есть концепция разъемов. Например, если вы хотите использовать веб-службу, они предоставляют вам графический wizzard. Недостатком является то, что вам нужно написать простой XML-SOAP-конверт вручную и скопировать его в графическом текстовом поле. Проблема с этим подходом заключается в том, что вы можете реализовать варианты использования, которые предназначены Бонитой. Если вы хотите интегрировать систему, в которой у 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 в другое корпоративное приложение. Кроме того, поддержка сообщества очень слаба. Есть несколько должностей, которым больше двух лет, и эти должности по-прежнему не отвечают.
Еще одна важная вещь - Business-IT-Alignment. Процессы моделирования - это совместная дисциплина, в которой ИТ-специалисты и бизнес-аналитики настроены. Вот почему вам нужны адекватные инструменты для обеих групп пользователей (например, Eclipse Plugin для разработчиков и простой в использовании веб-модельер для деловых людей). Bonita предлагает только Bonita Studio, которая должна быть установлена на вашем компьютере. Эта IDE довольно техническая и не подходит для бизнес-пользователей. Поэтому очень сложно реализовать Business-IT-Alignment с Bonita.
Bonita - это инструмент BPM для очень простых и простых процессов. Из-за подхода с нулевым кодированием кривая поиска очень низкая, и вы можете начать очень быстро моделировать. Вам нужно меньше навыков программирования, и вы можете реализовать свои процессы без необходимости кодирования. Но как только ваши процессы станут очень сложными, Бонита может оказаться не лучшим решением из-за отсутствия гибкости. Вы можете реализовать варианты использования, которые предназначены Бонитой.
2. jBPM:
jBPM - очень мощный движок BPM с открытым исходным кодом, который имеет множество функций. Веб-модельер даже поддерживает сборные модели некоторых шаблонов рабочего процесса van der Aalst (workflowpatterns.com). Business-IT-Alignment реализуется, потому что jBPM предлагает интеграцию Eclipse, а также веб-модельер. Насколько сложно, вы можете определять формы в веб-моделере, но не в плагине Eclipse, насколько я знаю. Подводя итог, jBPM является хорошим кандидатом для использования в компании. Наш showstopper был масштабируемостью. jBPM основан на правилах. Это приводит к тому, что все экземпляры процесса сохраняются как BLOBS в базе данных. Это критический showstopper, когда вы рассматриваете поиск и масштабируемость.
Кроме того, кривая обучения очень высока из-за сложности. jBPM не предлагает сервисную задачу, например, BPMN-Standard. Напротив, вы должны определить свои собственные задачи Java-службы, и вам нужно зарегистрировать их вручную в движке, что приводит к довольно низкоуровневому программированию.
3. Activiti:
В конце концов, мы пошли с Activiti, потому что это очень простой в использовании механизм на основе рамок. Он предлагает плагин Eclipse, а также современный веб-модель AngularJS. Таким образом, вы можете реализовать Business-IT-Alignment. REST-API защищен Spring безопасностью, что означает, что вы можете очень легко расширять движок с помощью функций Single Sign-on. Из-за Apache License 2.0 нет copyleft, что означает, что вы совершенно свободны в плане использования и расширяемости, что очень важно в продуктивной среде.
Кроме того, покрытие BPMN очень хорошее. Не все элементы BPMN реализованы, но я не знаю ни одного движка, который это делает.
Проводник Activiti - это демонстрационный интерфейс, демонстрирующий использование API-интерфейсов Activiti. Поскольку этот интерфейс основан на VAADIN, он может быть продлен очень легко. Сообщество очень активно, что означает, что вы можете получить помощь очень быстро, если у вас возникнут проблемы.
Activiti предлагает хорошие точки интеграции для внешних форм-технологий, что очень важно для продуктивного использования. Форм-технологии всех кандидатов очень ограничены. Поэтому имеет смысл использовать стандартную форму-технологию, такую как XForms, в сочетании с движком. Даже такие более сложные вещи реализуются через formKey-Attribute.
Activiti не следует подходом с нулевым кодированием, что означает, что вам потребуется немного кодирования, если вы хотите организовать услуги. Но даже связь с SOAP-сервисами может быть достигнута с помощью службы Java Service Task и Apache CXF. Недостаточно усилий по кодированию.
Я надеюсь, что мои ключевые моменты помогут, приняв решение. Чтобы быть понятным, это не реклама для Activiti. Правильный выбор продукта зависит от конкретных вариантов использования. Я хочу лишь отметить наиболее важные моменты в нашем проекте
Вопрос заключается в том, чего вы действительно хотите достичь, когда вы запрашиваете механизм рабочего процесса.
Общая цель, которую вы хотели бы достичь с помощью механизма документооборота, должна стать более гибкой в изменении бизнес-логики во время выполнения. Модельная часть, безусловно, одна из самых важных здесь. BPMN 2.0 является де-факто стандартом в этой области, и все обсуждаемые двигатели поддерживают этот стандарт.
Вторая цель - контролировать бизнес-процесс, чтобы описать вопросы "что должно произойти когда...". И эта часть имеет много общего с бизнес-требованиями, с которыми вы сталкиваетесь в рамках своего проекта.
Некоторые из механизмов рабочего процесса (Активность, JBPM) может помочь вам ответить на это требование, "кодируя" ваши процессы. Это означает, что вы моделируете парадигму "что должно произойти, когда...", где вы решаете, какая часть вашего кода (например, задача или событие) должна выполняться механизмом рабочего процесса в различных ситуациях. Об этой концепции идет много дискуссий. И разработчики, естественно, спрашивают, не могут ли они быть реализованы сами по себе. (На самом деле это не так просто, как кажется на первый взгляд)
Некоторые другие механизмы документооборота (Imixs-Workflow, Bonita) может помочь вам ответить на требование "что должно произойти, когда..." более ориентированным на пользователя способом. Это область управления бизнес-процессами, ориентированных на человека, которая поддерживает человеческие навыки и действия с помощью ориентированного на задачи рабочего процесса. Основное внимание уделяется распределению задач и процессов внутри организации. Механизм рабочего процесса помогает распределить задачу определенному пользователю или группе пользователей, а также защищать, регистрировать и отслеживать длительный бизнес-процесс. Возможно, это то, что вы действительно не хотите реализовать самостоятельно.
Итак, мой совет - не смешивать вещи, которые нужно учитывать отдельно, потому что рабочий процесс охватывает очень широкую область.
Я хотел бы добавить свои комментарии. Когда вы выбираете готовый движок, такой как jBPM, Activity и другие (их много), вы должны потратить некоторое время на изучение самой системы, это может быть непростой задачей. Особенно, когда вам нужно только автоматизировать небольшой фрагмент кода.
Затем, когда возникает проблема, вам приходится иметь дело с поддержкой поставщика, что не так быстро, как вы могли себе представить. Даже заплатите за консультацию.
И, наконец, самая важная причина, вы должны развиваться в экосистеме двигателя. Хотя, поставщики, как правило, заявляют, что их система является гибкой для включения в какие-либо системы, это может быть не так. В конце концов вы в конечном итоге переписываете свое приложение в соответствии с экосистемой BPM.
Да, в моей перспективе нет причин, по которым вы должны писать свои собственные. Большинство структур с открытым исходным кодом BPM/Workflow чрезвычайно гибкие, вам просто нужно изучить основы. Если вы выберете jBPM, вы получите гораздо больше, чем простой механизм рабочего процесса, так что это зависит от того, что вы пытаетесь построить.
Приветствия
Я бы рекомендовал вам использовать готовое решение. Учитывая, что для разработки механизма документооборота требуется огромное количество ресурсов и времени, готовый движок является лучшим вариантом. Посмотрите Workflow Engine. Это легкий компонент, который позволяет добавлять пользовательские исполняемые рабочие процессы любой сложности в любые Java-решения.
Недавно я открыл источник Piper (https://github.com/creactiviti/piper) распределенный и очень легкий вес, Spring, основанный на рабочем процессе движок.
Вы можете посмотреть @Apache Ant, чтобы создать механизм рабочего процесса. Он гораздо более надежен и представляет собой чистый конечный автомат с большинством необходимых требований, уже встроенных.
Кроме того, вы также можете встраивать различные динамические коды/скрипты в язык Java/Groovy/JS, что делает его очень мощным. Также позволяет расширение задач.
Вокруг него есть достаточное количество инструментов, или вы можете построить поверх него, если требуется IDE.
Обновление: доступен конечный автомат Spring, который имеет небольшой вес и не раздутый: https://projects.spring.io/spring-statemachine/