8

私はルール指向のプロジェクトに飛び込もうとしています (ILOGs Rules for .NET - 現在は IBM を使用)。また、ルール処理のセットアップ方法とルール エンジンとの対話方法に関するいくつかの異なる視点を読みました。

私が見た 2 つの主な考えは、ルール エンジンを (独自のサーバー ファームに) 集中化し、Web サービス API を介して (または ILOG の場合は WCF を介して) ファームに対してプログラムすることです。もう 1 つは、各アプリ サーバーでルール エンジンのインスタンスを実行し、各インスタンスが独自のルールのコピーを持っている状態でローカルに対話することです。

集中化の利点は、集中化された場所へのルールの展開が容易になることです。ルールは、アプリケーション サーバー構成を拡張するたびにスケーリングするのではなく、必要に応じてスケーリングします。これにより、購入したライセンスの観点から無駄が削減されます。このセットアップの欠点は、サービス呼び出しやネットワーク遅延などのオーバーヘッドが追加されることです。

ルール エンジンをローカルで実行することの長所と短所は、集中型構成の長所と短所の正反対です。遅いサービス呼び出し (高速な API 呼び出し) やネットワークの問題はなく、各アプリ サーバーはそれ自体に依存しています。ルールの展開の管理はより複雑になります。アプリ クラウドにノードを追加するたびに、ルール エンジンのライセンスがさらに必要になります。

ホワイト ペーパーを読むと、Amazon がアプリ サーバー構成ごとにルール エンジンを実行していることがわかります。彼らはルールの展開に時間がかかっているようで、ビジネス ロジックが一定期間同期していなくても、ルール公開の遅れは「許容できる」ことを認識しています。

質問:あなたの経験から、ルール主導の世界での作業にまだ多くの時間を費やしていないショップのために、ルールを .net ベースの Web アプリに統合するための最良の方法は何ですか?

4

4 に答える 4

3

私は中央集権化の議論が好きではありませんでした。これは、すべてがルール エンジンに結合され、システム内のすべてのルールのゴミ捨て場になることを意味します。すぐに、未知への恐怖で何も変えることができなくなります。

私は、独立した自律的なコンポーネントとしてのサービスに関する Amazon の考え方に従うことを好みます。これは、サービスがデータとルールを所有していることを意味すると解釈します。

これには、ルール空間を分割するという追加の利点があります。ルール セットは、大きくなるにつれて保守が難しくなります。それらを扱いやすいサイズに保つことをお勧めします。

ルール セットの一部が共有されている場合、サービスがルール エンジンの独自のインスタンスを持ち、起動時にデータベースから共通のルールをロードできる、データ駆動型の DI アプローチを好みます。iLog ライセンスによって複数のインスタンスのコストが法外に高くなる場合、これは実行できない可能性があります。それは、助けになるはずの製品が、実際には悲しみをもたらすアーキテクチャの選択を決定している可能性があるというケースです。これは、より安価な代替手段 (Java ランドの JBoss Rules など) の良い議論になるでしょう。

データ駆動型のデシジョン ツリー アプローチについてはどうでしょうか。Rete ルール エンジンは本当に必要ですか? 「エンタープライズ ツール」の決定があなたの選択の原動力になっていますか?

私はルール エンジンをセットアップして、企業の他の部分から可能な限り切り離すようにしました。可能であれば、データベースやサービスを呼び出す必要はありません。決定を求めるオブジェクトの責任にする方が良いでしょう。必要な Web サービスとデータベースを呼び出して必要なデータを収集し、それをルール エンジンに渡して、処理を任せます。カップリングは敵です: カップリングを最小限に抑えるようにシステムを設計してください。ルール エンジンを分離しておくことは、そのための良い方法です。

于 2009-07-28T01:22:06.910 に答える
2

「どのサーバーか」という質問について私が言うことはあまりありませんが、意思決定サービス (ルールを使用して意思決定を行うが、ビジネスの状態を変えない呼び出し可能なサービス) を開発することを強くお勧めします。デシジョン・サービスを呼び出した結果、どのようなデータ変更を行うかを呼び出し元のアプリケーション/サービス/プロセスに決定させ、呼び出し側コンポーネントにデシジョン・サービスによって提案されたアクションを実際に開始させることで、デシジョン・サービスを何度も簡単に使用できるようになります。再び（チャネル間、プロセスなど）。意思決定サービスがクリーンで他のインフラストラクチャとの結びつきが少ないほど、再利用可能で管理しやすくなります。ここでの ebizQに関する議論は、この点で読む価値があるかもしれません。

于 2009-07-29T20:51:57.497 に答える
2

ILOG For DotNet を使用しており、パイロット プロジェクトを展開しています。

未熟なルール アーキテクチャの概要を以下に示します。

  1. ルール外で行われるすべてのデータ アクセス。
  2. ルールはコードと同じ方法で展開されます (ソース管理、リリース プロセス、やだやだ)。
  3. ルールを使用するプロジェクト (サービス) にはILOG.Rules.dll、カスタム プーリング クラスを介して新しい RuleEngine への参照と新しいルールがあります。RuleSet を RuleEngine にバインドするにはコストがかかるため、RuleEngine はプールされます。
  4. ほとんどすべてのルールは、RuleFlow パラメータではなく、Assert されたオブジェクトを期待するように記述されています。
  5. ルールは同じメモリ空間で実行されるため、ルールによって変更されたインスタンスはプログラム内の同じインスタンスです。つまり、状態が即座に伝播されます。
  6. ほとんどすべてのルールは RuleFlow を介して実行されます (RuleFlow 内の単一の RuleStep であっても)。

RuleExecutionServer をホスティング プラットフォームとして、RuleTeamServerForSharePoint をルール ソースのホストとして検討しています。最終的には、コード リリース プロセスの外でルールを本番環境にデプロイする予定です。

すべてのルールの取り組みにおける主な障害は、モデリングとルール作成のスキルセットです。

于 2009-07-29T21:07:47.503 に答える
0

ルール エンジンに関する私の経験では、ルール エンジンとのやり取りを管理するために、かなり基本的な一連のプラクティスを適用しました。まず第一に、これらは常に商用のルール エンジン (iLog、Corticon) であり、オープン ソース (Drools) ではないため、ライセンス コストのために、各アプリ サーバーにローカルに展開することは現実的な選択肢ではありませんでした。したがって、主に 2 つの特徴がありますが、私たちは常に集中型モデルを採用してきました。

  • Web サービスのリモート実行- 質問で指定したのと同じ方法で、ルール エンジン製品によって提供される SOAP ベースのサービスを呼び出します。Web サービス領域内で、いくつかのオプションを見つけました。(1) リクエストを「ボックスカー」して、アプリケーションがリクエストを処理するルールをキューに入れ、1 回限りのメッセージではなくチャンクで送信できるようにします。(2) ベンダーが提供するスレッドとプロセスのオプションを調整します。これには、意思決定サービスを機能ごとに分離し、それぞれに W3WP を割り当てたり、Web ガーデンを使用したりすることが含まれます。ボックスカー、スレッド、およびプロセスで実行できる微調整は非常に多く、適切な組み合わせを得るには、正確な科学よりも試行錯誤のプロセス (およびルールセットとデータを知ること) が必要です。
  • 処理中のルール エンジンをリモートで呼び出す- シリアライゼーションとデシリアライゼーションのオーバーヘッドを回避するための従来のバッチ スタイルのトリック。ルール エンジンへのインプロセス コールを起動するコールをリモートで行います。これは、スケジュールされたもの (バッチなど) または要求に基づいたもの (つまり、要求の「ボックスカー」) のいずれかで実行できます。いずれにせよ、サービス呼び出しのオーバーヘッドの多くは、プロセスおよびデータベースと直接やり取りすることで回避できます。このプロセスの欠点は、IIS または EJB/サーブレット コンテナーがスレッドを管理していないため、自分で行う必要があることです。
于 2009-07-28T04:00:35.343 に答える