NoSQLに裏打ちされたBPM向けの成熟したJavaワークフローエンジンはありますか？

Question

ワークフロー中心のアプリケーションを構築するための一般的なアプリケーションまたはマイクロサービスの構築方法を研究しています。私はフレームワーク（以下を参照）についていくつかの調査を行いました。最も有望な候補者はJPAアノテーション付きエンティティと組み合わせてワークフローとプロセス状態を保存するRDBMSに強く依存しています。私の意見では、これは一般的なデータ駆動のワークフローマイクロサービスを設計する可能性を損なうものです。 MondoDBやCassandraのようなNoSQLソリューションでは、JSONやXMLでデータオブジェクトやルールを格納することで、本当に一般的なワークフローシステムを構築できるようです。これらは、コードを実行することでタイプまたはスキーマを強制し、1つまたは2つの単純なJavaオブジェクトを使用してエンティティを取得および保存します。私はこれを見ると、異なるドメインのModel-Viewペアのコントローラとして、単一のアプリケーションを変更せずに導入することが可能になる可能性があります（間違いなく非常に巧妙なインターフェイスが与えられています）。

私は、NoSQLバックエンドをサポートするワークフローエンジン/ BPMフレームワークを見つけようとしました。私が見つけた最も近いものはActiviti-Neo4Jで、これはActivityとNeo4Jの間のコネクターを可能にする放棄されたプロジェクトのようです。

NoSQLバックエンドをサポートし、特定のPOJOエンティティを必要とせずにデータオブジェクトを一般化するJava Work Engine/BPMフレームワークはありますか？

私の理想的な、魔法のような一般的な解決策をあきらめるなら、おそらく偉大な機能セットを持って成熟しているのでjBPMとActiviのようなフレームワークを選択するでしょう。他の候補者を探す際に、私はthis one on Java-Source.netのような放棄されたプロジェクトの真実の墓地を見つけました。

Answer 1

Activitiプロジェクトの設計者も、あなたが述べた問題を認識していましたが、その柔軟性を実現するためにはかなりの書き直しが必要であることは分かっていました。下に示すリンクで見てきたように、問題は、リレーショナルデータベース以外のさまざまな実装をコーディングするためのインタフェースの欠如です。バージョン6では、彼らは先に進んでバンダイを切り裂き、さまざまな実装（Neo4J、MongoDB、またはあなたが気に入っている他のパーシスタンス技術を思い浮かべてください）が書き込まれ、差し込まれる一連のインタフェースでフレームワークをリファクタリングしました。

以下のリンクされた記事では、前述のインターフェイスの簡単なインメモリ実装のコード例を示します。かなりクールに見え、おそらくあなたが探しているものと正確に聞こえます。

https://www.javacodegeeks.com/2015/09/pluggable-persistence-in-activiti-6.html

Answer 2

は、私は、ワークフローエンジンは、多くの場合、RDBMSに基づいている理由は、トランザクションセーフデータストアへのデータベーススキーマが、より多くの組み合わせではないと思います。 トランザクションの堅牢性は、特に複雑なワークフローにとって典型的な長期実行型トランザクションまたはネスト型トランザクションの場合、ワークフローエンジンにとって重要な要素です。 これはおそらく、ほとんどのエンジン（ac​​tiviなど）がデータ駆動型アプローチに焦点を当てていなかった理由の1つです。 （ここでは、ほとんどの場合NoSQLデータベースの対象となるデータ複製については言及していません）

Imixs-Workflow Projectをご覧になると、Java Enterpriseに基づいた別のアプローチが見つかります。このエンジンは、あらゆる種類のシリアライズ可能なデータ値を使用できる汎用データオブジェクトを使用します。データ検索の問題はLucene Search技術で解決されています。各オブジェクトは、各アイテムの名前と値のペアを持つ仮想ドキュメントに変換されます。これにより、処理されたビジネスデータを検索したり、ステータス情報やプロセス所有者などの構造化ワークフローデータを検索したりすることも容易になります。したがって、これは1つの可能な解決策です。

それ以外にも、ビジネスデータをNoSQLデータベースに保存するオプションが常に用意されています。これは、実行中のプロセス・インスタンスのワークフロー・データとは独立しています。 トランザクションの堅牢性の側面に戻って、NoSQLデータストレージへの参照を、トランザクションを認識するプロセスインスタンスに格納することをお勧めします。見てもhereを見てください。

唯一の問題は、トランザクションコンテキストをEJB/JPAから「外部」NoSQLデータベースに同期させることが非常に難しいことです。たとえば、データがNoSQLデータストレージ（例：Casnadra）に保存されたが、ワークフローエンジンのトランザクションが失敗してロールバックがトリガーされたときはどうしますか？