私たちのプロジェクトでは、特定のオブジェクトのいくつかのアクションへのマッピングに関するビジネス ロジックを実装する必要があります。特定のアクションが最終的に解決される前に、特定のタイプのオブジェクトが検証される一連の条件があります。言い換えると、7 種類のオブジェクトに対して一連のアクションを実行できます (ほぼ 45 のアクションから)。
前述のルールを書き留めるために Drools を使用することを考えていました。Drools の効率に関する限り、Drools の使用に関してポジティブ/ネガティブな経験をした人はいますか? 使用できる jBPM フレームワークもあります (私が間違っていなければ、Drools がそこで使用されています)。そのフレームワークに精通している人はいますか? おそらく、問題を解決する方法について他のアイデアがありますか？
効率に関しては、Droolsにはまったく問題がないはずです。それは私にはかなり小さな事実とルールのセットのように聞こえます。それが基づいているReteエンジンは、自分でコーディングしたif-then-elseステートメントの山よりも、意思決定がほぼ確実に高速です。そして、私が気付いた特別な利点は、応答時間が非常に予測可能であることです。
明らかにすべてのファクトモデルとルールは異なりますが、例として、私が現在構築しているアプリケーションには、いつでもワーキングメモリに数百のファクトと1000を超えるルールがあります。約20ミリ秒で着信要求を決定することができます。
完全なjBPMフレームワークは、あなたが説明するものには必要ではないようです。しかし、それはそれが何をするかは得意です。たとえば、ワークフローの設計を検討している場合はプロセスモデリングGUIがあり、技術チームがDSLの作成とデシジョンテーブルの作成に事前に取り組んでいれば、技術以外のルールの作成者がGuvnorを使用できます。
完全を期すために、主な競合相手はおそらくFICOBlazeAdviserまたはIBMILogJRulesです。一般に、ベンチマークに関しては、それらはDroolsよりもわずかに進んでいる傾向がありますが、高価です。確かに、JBoss / RedHatサービス契約の支払いを決定した場合、それはそれほど違いはありませんが、Droolsのコミュニティサポートを喜んで受ければ、無料です！
Drools に関する私の唯一の懸念は、IT 以外のビジネス関係者が実際に使用できる適切な GUI がないことです。多くの製品は、そのような UI を提供していると主張していますが、実際にはそうではないことが常に判明しています。そのため、開発チームがデシジョン テーブルやその他の形式に基づいてこれらすべてのルールを作成し、テストすることになるという事実を受け入れる必要があります。
それ以外では、Drools は政府、銀行、大企業で使用される優れた BRE です。
Drools は非常に効率的で高速です。しかし、他のテクノロジーやフレームワークと同様に、プロジェクトに統合するには投資が必要であり、特効薬ではありません。次のことを考慮する必要があります。
jBPM はルール エンジンではなく、ワークフロー エンジンです。Drools はルールエンジンです。したがって、Drools はあなたが探しているものです。
Drools と jBPM はコンパニオン プロジェクトです。ワークフローにルールが必要な場合、これらは非常にうまく統合されます。
Drools はよくできていますが、JBPM は他の BPMN エンジンと比べて少し複雑です。少し簡単で、Spring、LDAPなどの統合が簡単なので、Activitiをお勧めします。Activiti の方が簡単です。また、Drools を Activiti と統合することもできます。ワークフロー エンジンとして Activiti を、ルール エンジンとして Drools を使用してください。