Есть ли зрелый Java Workflow Engine для BPM, поддерживаемый NoSQL?
Я исследую, как создать общее приложение или микросервис для создания приложений, ориентированных на рабочий процесс. Я провел некоторое исследование по фреймворкам (см. Ниже), и наиболее многообещающие кандидаты твердо полагаются на СУРБД для хранения рабочего процесса и состояния процесса в сочетании с аннотированными JPA сущностями. На мой взгляд, это наносит ущерб возможности создания общего микросервиса, основанного на данных. Кажется, что действительно общая система рабочего процесса может быть построена на решениях NoSQL, таких как MondoDB или Cassandra, путем хранения объектов данных и правил в JSON или XML. Это позволит выполнять код для принудительного применения типов или схем при использовании одного или двух простых объектов Java для извлечения и сохранения объектов. На мой взгляд, это может позволить развернуть отдельное приложение в качестве контроллера для пар модели-представления разных доменов без изменений (по общему признанию, с очень умным интерфейсом).
Я попытался найти механизм рабочего процесса /BPM, который поддерживает NoSQL бэкэнды. Самым близким, что я нашел, является Activiti-Neo4J, который, похоже, является заброшенным проектом, позволяющим соединить Activity и Neo4J.
Существует ли платформа Java Work Engine/BPM, которая поддерживает бэкэнды NoSQL и обобщает объекты данных, не требуя специальных объектов POJO?
Если бы я отказался от своего идеального, волшебного общего решения, я бы, вероятно, выбрал бы фреймворк, такой как jBPM и Activi, так как они имеют отличный набор функций и являются зрелыми. Пытаясь найти других кандидатов, я нашел настоящее кладбище заброшенных проектов, подобных этому, на Java-Source.net.
2 ответа
Да, https://cadenceworkflow.io/ имеет подключаемое постоянство и работает как в Cassandra, так и в базах данных SQL. Он был протестирован на 100 узлах Cassandra и мог поддерживать десятки тысяч событий в секунду и сотни миллионов открытых рабочих процессов.
Он позволяет моделировать логику вашего рабочего процесса как простые старые классы Java и гарантирует, что код полностью отказоустойчив и устойчив ко всем видам сбоев. Это включает локальную переменную и потоки.
См. Эту презентацию, в которой подробно рассказывается о модели программирования.
Я думаю, что причина, по которой механизмы рабочих процессов часто основаны на СУБД, заключается не в схеме базы данных, а в большей степени в сочетании с безопасным для транзакций хранилищем данных. Надежность транзакций является важным фактором для механизмов рабочих процессов, особенно для длительных или вложенных транзакций, которые типичны для сложных рабочих процессов. Так что, возможно, это одна из причин, почему большинство движков (например, activi) не фокусировались на подходе, основанном на данных. (Я не говорю о репликации данных, которая в большинстве случаев покрывается базами данных NoSQL)
Если вы посмотрите на проект Imixs-Workflow, вы найдете другой подход, основанный на Java Enterprise. Этот механизм использует универсальный объект данных, который может использовать любые виды сериализуемых значений данных. Проблема поиска данных решается с помощью технологии Lucene Search. Каждый объект переводится в виртуальный документ с парами имя / значение для каждого элемента. Это облегчает поиск по обработанным бизнес-данным, а также для запроса структурированных данных рабочего процесса, таких как информация о состоянии или владельцы процесса. Так что это одно из возможных решений.
Кроме того, у вас всегда есть возможность сохранить свои бизнес-данные в базе данных NoSQL. Это не зависит от данных рабочего процесса запущенного экземпляра процесса, поскольку вы связываете оба объекта вместе. Возвращаясь к аспекту надежности транзакций, будет хорошей идеей сохранить ссылку на ваше хранилище данных NoSQL в экземпляре процесса, который осведомлен о транзакции. Посмотрите также здесь.
Таким образом, единственная проблема, с которой вы можете столкнуться, заключается в том, что очень трудно синхронизировать контекст транзакции из EJB/JPA с "внешней" базой данных NoSQL. Например: что вы будете делать, когда ваши данные были успешно сохранены в вашем хранилище данных NoSQL (например, Casnadra), но транзакция механизма рабочего процесса завершается неудачно и запускается обратная роль?
Разработчики проекта Activiti также знали о проблеме, о которой вы говорили, но знали, что для такой гибкости было бы достаточно переписать, что, возможно, должно было быть заложено в проект с самого начала. Как вы увидите по ссылке, приведенной ниже, проблема заключалась в отсутствии интерфейсов для кодирования различных реализаций, отличных от реляционной базы данных. С версией 6 они пошли дальше, сняли полосу и реорганизовали структуру с набором интерфейсов, для которых можно было бы написать и подключить различные реализации (например, Neo4J, MongoDB или любую другую технологию персистентности, которая вам нравится).
В связанной статье ниже они предоставляют некоторые примеры кода для простой реализации в памяти вышеупомянутых интерфейсов. Выглядит довольно круто и звучит, возможно, именно то, что вы ищете.
https://www.javacodegeeks.com/2015/09/pluggable-persistence-in-activiti-6.html