2012-12-11 10 views
9

プロジェクトでは、特定のオブジェクトをいくつかのアクションにマッピングするビジネスロジックを実装する必要があります。特定のアクションが最終的に解決される前に、特定のタイプのオブジェクトが検証されるための一連の条件があります。言い換えれば、7つのタイプのオブジェクトに対して、一連のアクションを実行できます(ほぼ45のアクションから)。Droolsはビジネスルール/ロジックをマッピングする最も効率的な方法ですか?

私はDroolsを使用して上記のルールを書き留めることを考えていました。効率性に関する限り、Droolsを使用することで誰かが肯定的/否定的な経験をしていますか?使用できるjBPMフレームワークもあります(もし私がDroolsがそこで使われていると誤解されていなければ) - 誰でもそのフレームワークに精通していますか?おそらく、あなたは問題を解決する方法のいくつかの他のアイデアを持っているでしょうか?

答えて

7

効率に関しては、Droolsに全く問題はありません。それは、私にとってかなり小さな事実とルールのように思えます。それが基礎としているReteエンジンは、if-then-elseステートメントの積み重ねよりも決定を下すのがほぼ確実です。そして、私が気づいた特別な利点は、応答時間が非常に予測可能であることです。

明らかにすべてのファクトモデルとルールは異なりますが、例として、私が現在構築しているアプリケーションには、いつでも作業メモリに数百の事実と1000以上のルールがあります。着信要求について約20ミリ秒で決定することができます。

完全なjBPMフレームワークは、あなたの記述には必要ないと思います。しかし、それは何が良いかです。例えば、ワークフローを設計しようと思えばプロセスモデリングGUIがあり、技術チームがDSLの作成やデシジョンテーブルの作成に何らかの初期の努力をしていれば、Guvnorは非技術的ルールの作者にも利用可能です。

主な競合相手はおそらくFICO Blaze AdviserまたはIBM ILog JRulesです。一般的に、ベンチマークの場合は、Droolsよりも少し先になる傾向がありますが、コストが高くなります。確かに、あなたがJBoss/RedHatサービス契約の代金を支払うことにした場合、それほど変わることはありませんが、Droolsのコミュニティサポートを受けられるのがうれしいならば、それは無料です!

+0

ありがとうございました!私たちはプロジェクトでDroolsを使うことに決めました。本当に満足しています。非常に良いことは、私たちのルールをDRLファイルに保存し、毎回アプリケーションを再デプロイする必要がないことです。 –

4

Droolsについて私が懸念しているのは、IT以外のビジネスの人々が実際に使用できる適切なGUIがないことです。そのようなUIを提供していると主張する製品はたくさんありますが、それは本当に真実ではないことが常に判明しています。したがって、開発チームがデシジョン・テーブルやその他の形式に基づいてすべてのルールを作成してテストするという事実に同意する必要があります。

Droolsはそれ以外にも、政府、銀行、大企業で使用される優れたBREです。

+1

100%true。しかし、彼が提供している説明によれば、おそらく決定表が良い候補になる可能性があります。そうであれば、少数の痛みを伴うIT管理者でもルールを管理することができます。 –

+3

@EstebanAliverti理論的にはあなたは絶対に正しいです。デシジョン・テーブルの全前提はITをビジネスから抽象化することでした。実際にはこれは決してうまくいかない。私は15年間BREを扱ってきましたが、すべての大きなものを通過しました。私はビジネスマンが助けなしにテーブルを作成/編集するプロジェクトは見たことがありません。それはITからの支援です。書式/行動/条件が常に変更され、新しいビジネス関係者が来るなど。 – Kizz

+1

ありがとうございました!私たちはプロジェクトでDroolsを使うことに決めました。本当に満足しています。もちろん、GUIには問題がありますが、スプレッドシートのデシジョン・テーブルを使用して上書きできます。私は自分のブログに投稿しました[リンク](http://toomuchcoding.blogspot.com/2013/02/drools-decision-tables-with-camel-and.html) –

1

Droolsは非常に効率的で高速です。しかし、どのような技術でも、&フレームワークと同じように、プロジェクトに統合するための投資が必要になりますし、魔法の弾丸でもありません。あなたは次の点を考慮する必要があります:

  • いくつのルールがありますか?ルールが20未満の場合、ルールエンジンはお勧めしません。 7つのオブジェクトと45のアクションだけのためにルールエンジンを追加するという複雑さのために費やす努力を正当化できないかもしれません...
  • DSL(Domain Specific Language)機能が必要ですか?つまり技術者以外の人々はルールを書くだろうか? IMHOこれは、例えばDroolsと比較してDroolsではあまり使用できません。 Oracle OPAしかし、やはり私は、技術者ではない人がルールシステムで安全に手を触れているのを見たことはありません。決定表の値を変更することは別として
  • あなたのルールはどのくらいの頻度で変更されますか? Drools Guvnorは、ルールを管理、バージョンアップ、パッケージ化、テストするための集中化されたシステムが必要な場合、非常に有能な製品です。
1

jBPMはルールエンジンではなく、ワークフローエンジンです。 Droolsはルールエンジンです。だからDroolsはあなたが探しているものです。

DroolsとjBPMは、コンパニオンプロジェクトです。ルールを使用してワークフローが必要な場合は、本当にうまく統合されます。

他のBPMNエンジンと比較して、JBPMはビットが複雑です。私はActivitiのために行くことをお勧めします。なぜなら、それは少し楽になり、何かの統合がSpring、LDAPなどと言うからです。 Activitiを使う方が簡単です。また、DroolsとActivitiを統合することもできます。アクティビティをaworkflowエンジンとして、Droolsをルールエンジンとして使用してください。

関連する問題