ビジネスルールエンジン

ビジネスルール エンジンは、ランタイム運用環境で1 つ以上のビジネス ルールを実行するソフトウェア システムです。ルールは、法的規制(「従業員は、いかなる理由でも、または理由なく解雇される可能性がありますが、違法な理由による解雇はできません」)、会社のポリシー (「一度に 100 ドル以上購入するすべての顧客に 10% の割引を提供します」)、またはその他のソースから取得される場合があります。ビジネス ルール システムを使用すると、これらの会社のポリシーやその他の運用上の決定を、アプリケーション コードとは別に定義、テスト、実行、および保守できます。

ルール エンジンは通常、ルール、ファクト、優先順位 (スコア)、相互排他性、前提条件、およびその他の機能をサポートします。

ルール エンジン ソフトウェアは、通常、ビジネス ルール管理システムのコンポーネントとして提供され、他の機能の中でも、すべてのルールを登録、定義、分類、管理する機能、ルール定義の一貫性を確認する機能 (「ゴールド レベルのお客様は、注文数量が 10 を超える場合、送料無料の対象となります」および「シルバー レベルのお客様の最大注文数量 = 15」)、異なるルール間の関係を定義する機能、およびこれらのルールの一部を、影響を受ける、または 1 つ以上のルールを適用する必要があるITアプリケーションに関連付ける機能を提供します。

どのようなITアプリケーションでも、ビジネス ルールはアプリケーション コードの他の部分よりも頻繁に変更される可能性があります。ルール エンジンまたは推論エンジンは、ビジネス ルール アプローチによってアプリケーション コードから外部化または分離されたビジネスルールを実行する、プラグ可能なソフトウェア コンポーネントとして機能します。この外部化または分離により、ビジネス ユーザーは IT の介入なしにルールを変更できます。システム全体は、このような外部ビジネス ルールによって簡単に適応できるようになりますが、これによってQAやその他のテストの通常の要件が排除されるわけではありません。

Computerworldの記事では、ルールエンジンの起源は1990年代初頭まで遡り、 Pegasystems、Fair Isaac Corp、ILOG ^{[1] 、} SapiensのeMerge ^[2]などの製品が登場したとされています。

多くの組織のルールの取り組みでは、一般的にワークフロー設計と見なされるものの側面と従来のルール設計が組み合わされています。この 2 つのアプローチを分離できないと、ビジネス ルールとワークフローの両方を再利用および制御する機能に問題が生じる可能性があります。このジレンマを回避する設計アプローチでは、ビジネス ルールとワークフローの役割を次のように分離します。^[3]

• ビジネスルールは知識を生み出します。
• ワークフローはビジネス作業を実行します。

具体的には、ビジネス ルールは、ビジネス状況が発生したことを検出してビジネス イベントを発生させたり (通常はメッセージング インフラストラクチャを介して実行)、より高レベルのビジネス ナレッジを作成したり (たとえば、ローンが引受基準を満たしているかどうかに関する一連の組織、製品、規制ベースのルールを評価する) するなどの処理を実行できます。一方、ワークフローは、ルーティング ポイントの過負荷などを示すイベントに応答して、一連のアクティビティを開始します。

この分離は、同じビジネス判断 (住宅ローンが引受基準を満たしている) またはビジネス イベント (ルーターが過負荷になっている) に、さまざまなワークフローが反応できるため重要です。ルール主導の知識作成に応じて行われた作業をルール自体に埋め込むと、ビジネス ルールがワークフロー固有になるため、組織全体でビジネス ルールを再利用する能力が大幅に低下します。

ビジネス ルール エンジンを採用したアーキテクチャを作成するには、イベントに応答したり、ビジネス ルールによって定義されたビジネス判断を検証したりするプロセスに基づくBPM (ビジネス プロセス管理) プラットフォームとBRM (ビジネス ルール管理) プラットフォーム間の統合を確立することが不可欠です。市場には、この統合をネイティブに提供する製品がいくつかあります。他の状況では、このタイプの抽象化と統合は、特定のプロジェクトまたは組織内で開発する必要があります。

ほとんどの Java ベースのルール エンジンは、さまざまなアプリケーションとの統合を可能にするために、JSR-94アプリケーション プログラミング インターフェイス(API) 標準に基づいた技術的な呼び出しレベルのインターフェイスを提供し、多くのルール エンジンは、 WSDLやSOAPなどの Web ベースの標準を通じてサービス指向の統合を可能にします。

ほとんどのルール エンジンは、ルールを記述する対象となるビジネス エンティティと関係を表すデータ抽象化を開発する機能を提供します。このビジネス エンティティ モデルは、通常、 XML、POJO、フラット ファイルなどのさまざまなソースから取り込むことができます。ルール自体を記述するための標準言語はありません。多くのエンジンはJavaのような構文を使用しますが、一部のエンジンではカスタムのビジネス フレンドリーな言語の定義が可能です。

ほとんどのルール エンジンは、呼び出し可能なライブラリとして機能します。ただし、RDBMS の動作に似た汎用プロセスとして実行することが一般的になりつつあります。ほとんどのエンジンは、ルールをプロセス インスタンスにロードされる構成として扱いますが、一部のエンジンは実際にはルール実行インスタンス全体のコード ジェネレーターであり、他のエンジンはユーザーが選択できます。

ルール エンジンにはさまざまな種類があります。これらの種類は (一般的に) ルールの実行スケジュール方法が異なります。

企業が使用するルール エンジンのほとんどは前向き連鎖であり、さらに次の 2 つのクラスに分類できます。

• 最初のクラスは、いわゆる生成/推論ルールを処理します。これらのタイプのルールは、IF 条件 THEN アクション タイプの動作を表すために使用されます。たとえば、このようなルールは、「IF some-condition THEN allow-customer-a-mortgage」という形式のルールを実行することで、「この顧客に住宅ローンを許可する必要がありますか?」という質問に答えることができます。
• もう一方のタイプのルール エンジンは、いわゆる反応/イベント条件アクションルールを処理します。反応型ルール エンジンは、着信イベントを検出して反応し、イベント パターンを処理します。たとえば、反応型ルール エンジンを使用して、特定の品目が在庫切れになったときにマネージャーに警告することができます。

これらのタイプの最大の違いは、プロダクション ルール エンジンは、ユーザーまたはアプリケーションが呼び出したときに、通常はステートレスな方法で実行されることです。リアクティブ ルール エンジンは、イベントが発生すると、通常はステートフルな方法で自動的に反応します。多くの (実際、ほとんどの) 一般的な商用ルール エンジンには、プロダクション ルール機能とリアクション ルール機能の両方が備わっていますが、どちらかのクラスを他のクラスよりも重視している場合があります。たとえば、ほとんどのビジネス ルール エンジンは主にプロダクション ルール エンジンですが、複雑なイベント処理ルール エンジンはリアクション ルールを重視しています。

さらに、一部のルール エンジンは後方連鎖をサポートしています。この場合、ルール エンジンは特定の目標に合うように事実を解決しようとします。既存の情報に基づいて何かが存在するかどうかを判断しようとするため、 目標駆動型と呼ばれることがよくあります。

別の種類のルール エンジンは、推論の実行中にバック チェーンとフォワード チェーンを複数回自動的に切り替えます。たとえば、Web で検索すると見つかるインターネット ビジネス ロジック システムがあります。

ルール エンジンの 4 番目のクラスは、決定論的エンジンと呼ばれることがあります。これらのルール エンジンは、前向き連鎖と後向き連鎖の両方を放棄し、代わりにドメイン固有の言語アプローチを使用してポリシーをより適切に記述します。このアプローチは、実装と保守が簡単な場合が多く、前​​向き連鎖または後向き連鎖システムよりもパフォーマンス上の利点があります。

ルール処理でブールルールではなくヒューリスティックが使用される場合、ファジーロジックベースの推論がより適切な場合があります。例としては、顧客分類、欠損データ推論、顧客価値計算などが挙げられます。DARL言語^[4]と関連する推論エンジンおよびエディターは、このアプローチの例です。

ルール エンジンの一般的な使用例の 1 つは、アプリケーションへの標準化されたアクセス制御です。OASISは、XACML (eXtensible Access Control Markup Language)と呼ばれるアクセス制御専用のルール エンジン アーキテクチャと標準を定義しています。XACML ルール エンジンとビジネス ルール エンジンの主な違いの 1 つは、XACML ルール エンジンはステートレスであり、データの状態を変更できないことです。ポリシー決定ポイント(PDP) と呼ばれる XACML ルール エンジンは、バイナリ Yes/No の質問 (例: 「Alice はドキュメント D を表示できますか?」) を期待し、許可/拒否などの決定を返します。

• ビジネスルール
• 生産システム
• 推論エンジン
• Reteアルゴリズム
• 波及効果のルール
• ビジネスルール管理システム
• セマンティック推論
• ワークフローエンジン
• ビジネスプロセス実行言語(BPEL)
• BPELエンジンのリスト
• BPMN 2.0 エンジンのリスト

• テイラー、ジェームズ、ラデン、ニール (2007)。スマート（十分な）システム。プレンティスホール 。ISBN 0-13-234796-2。 
• David Linthicum (2007-02-14)。「ルール エンジンと SOA」。InfoWorld、2007-02-14。2009-09-23 に http://www.infoworld.com/d/architecture/rules-engines-and-soa-158 から取得。

• ルール エンジンを使用するかどうかを決定するためのガイドラインはありますか?