drools - ルールエンジンについての神話は何ですか？

Question

ルールエンジンテクノロジー、特にJBossDroolsについてのプレゼンテーションを書いています。

ルールエンジンに関する「神話」のいくつかは何ですか。

私が考えることができるのは、ビジネスユーザーがルールエンジンを制御できることです。それは可能だと思いますが、制御と教育が必要です。すべてのビジネスユーザーがそれを実行できるわけではありません。

賛成/反対ですか？他に何か考えはありますか？

クリエイティブ・コモンズの下で私の最後の「発見」をリリースして幸せです...

Answer 1

神話についてはわかりませんが、ビジネスマンにルールを維持させることはスラムダンクではないことに同意します。

ITの仕事をするために必要な細部への忍耐と肛門性格の注意をビジネスの人々に期待することは、幻想だと思います。プログラマー全員を解雇できるように、秘書にコードを書かせるための方法として3G言語（プログラミングへのグラフィカルなアプローチ）が提供されて以来、これは機能しています。

ルールセットのサイズが大きくなると、それが正しく、自己矛盾がないことを保証する可能性が低くなることを指摘しておきます。ルールセットに数千のルールがある場合、テストするのは困難です。

そういえば、組み合わせの組み合わせ爆発は、ルールエンジンのテストを困難にします。

ルールエンジンは素晴らしいテクノロジーですが、注意してください。

Answer 2

実際、droolsを多用しているので、ユーザーが簡単に操作できるという点については意見が分かれます。強力なルールを動的に生成するためのシンプルなインターフェイスをユーザーに提供するのは比較的簡単だと思います。

私が間違いなくリストに追加するものは次のとおりです。

神話：ルールエンジンは遅い！

そうではありませんが、繰り返しになりますが、私は1秒あたり数千のイベントでさえも非常に簡単に垂れ下がっています。

私が絶対に嫌ったもう一つは：

神話：重すぎて複雑すぎて使用できません。

ナンセンス、構文は簡単で、Javaの数行で、本当にファンキーなことを行うことができます！これが暴言のように思われる場合は申し訳ありませんが、私がこの技術を紹介しようとしていたので、前の雇用主でこのがらくたを何ヶ月も過ごしました！

Answer 3

神話...
1/ビジネスユーザーは次のことができます：作成
者のルール
を展開して
テストし、ITの助けを借りずに
実行します
...セールスマンがそう言ったので、実際にそれが真実だと思っていたクライアントにトレーニングを提供しました...ああああああ彼らは私の日/山/年を作った!!!

ITチームの後ろにサービスを展開するリスクを冒す会社について真剣に考えることができますか？ありえない！
私が次のようなルールを書くのを防ぐためにもセキュリティが必要です
。クライアントの名前が「Damien」の場合、100％割引-グルーヴィーな赤ちゃん！

プロジェクトのアーキテクチャは、技術者以外のユーザーが行うことはできません

2/ルールプロジェクトは何も気にせず簡単に管理できます。
処理できるルールの数には制限があります。理論的には、必要な数のルールを持つことができますが、これは完全には正しくありません。JRulesは、EclipseとRTS間のルールの同期を約3,000ルールから停止します。すべてRETEに100,000のルールがあるプロジェクトがある場合、それは永遠にかかります。ツリーの構築には長い時間がかかります。シーケンシャルモードでも、続行するのに長い時間がかかります。
「マイドキュメント」フォルダのようなルールリポジトリを使用して、ルールを追加し続けることはできません。

3 /ビジネスユーザーは、トレーニングなしであらゆる種類のルールを作成できます。
さまざまなこと：
a/条件の順序がパフォーマンスに影響を与える可能性があります。
b /一部のルールは複雑で、言語を十分に理解する必要があります
c/使用されるアルゴリズムは実行の結果に影響を与える可能性があります
d/単一の不適切に記述されたルールは実行時間をn倍にする可能性があります。
私は、1つのルールだけがいくつかのランダムなタイムアウトの原因となっているプロジェクトに取り組みました。
e/いくつかの複雑な問題を1つのルールで表現できます。
この問題は1つのルールで解決され、1つの結果
が得られます。4人のゴルファーが左から右に並んでお茶の前に立っています。
-フレッドのすぐ右にいるゴルファーは青いズボンをはいている
-ジョーは2番目に並んでいる
-ボブは格子縞のズボンを着用してい
ます-トムはポジション1または4になく、オレンジ色のズボンを着用していませんところで
：これはJBossの例です。
ビジネスユーザーはどのようにこれを行うことができますか？

4 /ルールエンジンは後向き連鎖
を行うことができますJBossはできると言っていると思いますが、これについてはよくわかりません。BlazeとJRulesはできません。

5/ルールを書くのにプログラム言語は必要ありません。
正解ですが、ルールを実行するためにいくつか必要になります。オブジェクトモデルとして単純なXSDを使用している場合を除きます。しかし、あなたの意思決定サービスはそれほど賢いことをしません。

6 / JAVAよりも遅い
もちろんですが、BRMSを使用すると、ビジネスロジックを外部化するため、コストがかかります。
データを外部化するときとまったく同じです。データベース呼び出しにはコストがかかります。
相互に呼び出していた4つのダミールールを含むプロジェクトで、5,000個のオブジェクトをJRulesのワーキングメモリに送信しました...パフォーマンステストの目的
結果：75秒で1,900万個のルールが実行されました。あなたの数学をしてください...それはそれほど遅くはありません。

7 /ルール内で何でも実行できますルール
内でデータベース呼び出しを行わないでください（特に条件で）。理論的には、Reteを使用すると、ルールは条件を「テスト」して、メモリ内で何千回も一致する結果を見つけることができます。
アプリケーションでデータベースをそれほど呼び出したくない人はいないでしょう。

それが役に立てば幸い