意思決定エンジン

意思決定エンジンは、ルール・セットの実行パフォーマンスを最適化するよう設計されています。意思決定エンジンはクラシック・ルール・エンジンと同様に動作しますが、ルールのコンパイルとロードに違いがあります。

デプロイメント前、Decision Center は、ルールを中間コードにコンパイルします。このコードは実行時に最後の変換で実行可能コード (Java™ バイトコード) に変換されます。

Rule Designer では、ルールをデフォルトで実行可能コードにコンパイルします。ルールを中間コードにコンパイルするには、「ルール・セット・アーカイブのエクスポート」ページの「ルール・セットのロードの最適化 (Java バイトコードの生成)」オプションをクリアします。

意思決定エンジンとクラシック・ルール・エンジンでは実装は異なりますが、意思決定エンジンにはクラシック・ルール・エンジンのほとんどの機能があります。両方のエンジンで、Fastpath、sequential、または RetePlus 実行モードを選択できます。作業メモリーおよびアジェンダ・フィーチャーを使用すると、アプリケーション・オブジェクトを保管および操作できます。作業メモリーには、アプリケーション・オブジェクトへの参照が含まれます。アジェンダは、実行に適格なルール・インスタンスをリストおよび順序付けします。

意思決定エンジンでルールを実行するためのワークフロー

意思決定エンジンでルールを実行するには、以下のステップを実行します。

レガシー・アプリケーションのビジネス・ロジックをカプセル化するための、ルール・プロジェクトを作成します。
これらのアプリケーションが COBOL に基づく場合、Rule Designer の COBOL 管理フィーチャーを使用します。詳しくは、『COBOL モデルの BOM の設計』を参照してください。
必要に応じて、ルール・プロジェクトの「ルール・エンジン」プロパティーを「クラシック・ルール・エンジン」ではなく「意思決定エンジン」に変更します。ルール・プロジェクトに ILOG® ルール言語 (IRL) での BOM から XOM へのマッピングが含まれる場合、このマッピングは拡張ルール言語 (ARL) での BOM から XOM へのマッピングに移行されます。移行は 1 回のみ実行されます。詳しくは、BOM から XOM へのマッピングの移行を参照してください。
Rule Designer でルールの実行をテストします。詳しくは、Java アプリケーションを使用した実行のテスト、およびクラシック・ルール・プロジェクトの実行とデバッグを参照してください。
分散プラットフォーム用 Rule Execution Server、z/OS® 用 WebSphere® Application Server の Rule Execution Server、または zRule Execution Server for z/OS のいずれかのパーシスタンス・レイヤーにルール・セットを配布します。詳しくは、『ビジネス・ルールの配布』を参照してください。
ルール・セットを呼び出します。
- 分散プラットフォーム用 Rule Execution Server では、ルール・セッション API を使用します。
- WebSphere Application Server for z/OS 上の Rule Execution Server では、ルール・セッションAPI を使用します。
- zRule Execution Server for z/OS では、 Decision Server for z/OS API を使用します。詳しくは、『z/OS クライアント・アプリケーションへの API 呼び出しの追加』を参照してください。
Rule Execution Server でルールを実行する場合、ルール・セットを呼び出す API は、クラシック・ルール・エンジンと意思決定エンジンで同じです。ルール・セットで定義される「ルール・エンジン」プロパティーにより、ルールを実行するエンジンが決まります。

BOM から XOM へのマッピングの移行

ルール・プロジェクトの「ルール・エンジン」プロパティーを「クラシック・ルール・エンジン」ではなく「意思決定エンジン」に初めて変更した時点で、BOM から XOM へのマッピングの移行が実行されます。

この移行では、IRL での元の BOM から XOM へのマッピング (.b2x ファイル) は変更されませんが、移行されたコードを保管する新規ファイル (.b2xa) が作成されます。これにより、ユーザーは 2 つのエンジンを切り替えることができます。

ファイルが作成された後、特定エンジンに対して行った変更は各ファイルに個別に保存されますが、2 つのファイル間で変更は同期されません。「クラシック・ルール・エンジン」に切り替え、BOM から XOM へのマッピングを変更すると、.b2x ファイルが変更されます。「意思決定エンジン」に再び切り替えても、BOM から XOM へのマッピングは変更されません。つまり、.b2xa ファイルは未変更のままです。

元の本文に移行できないステートメントが含まれる場合、移行されたコードには空の本文が含まれることがあります。

コンパイルおよび実行

意思決定エンジンは、ルール・アーティファクトをコンパイルして、コンパイルと最適化が済み、Java バイトコードに変換されると実行可能になるコードを含むアーカイブにします。

対して、クラシック・ルール・エンジンでビルドされたルール・セットには、コンパイルと最適化の前に構文解析が必要なテキスト・ファイルが含まれています。ルール・セットのロード時に、コードの構文解析、コンパイル、および最適化を行うのは大変なことです。

ですから、意思決定エンジンでルール・セットをロードする方が高速です。なぜなら、コードを実行時に構文解析する必要も解釈する必要もないからです。コードはすべて、すでに (中間コードまたは Java バイトコードに) コンパイルされているし、ルール実行用に完全に最適化されています。

下図は、クラシック・ルール・エンジンと意思決定エンジンでの、Java バイトコード生成がある場合とない場合の、コンパイルと実行のプロセスを示しています。このプロセスは、ルールの初回のコンパイルからルールの実行まで、さまざまなステージを辿ります。

重要: バイトコードの生成により、意思決定エンジンで作成されるルール・セットのロード時間が改善されます。 Rule Designer では、バイトコードの生成オプションはデフォルトで選択されています。ただし、意思決定エンジンで使用される、Decision Center から生成されるルール・セット・アーカイブにはバイトコードは含まれません。これは、実行時に生成されます。Rule Execution Server には、中間コードから Java バイトコードへの変換を最適化する方法があります。コンパイル済みのアーカイブ・キャッシュを使用して、このバイトコード生成を、初回に意思決定エンジンのルール・セットがロードされる場合のみに制限することができます。詳しくは、『コンパイル済みアーカイブ・キャッシュの設定』を参照してください。

以下の表では、クラシック・ルール・エンジンと意思決定エンジンとの違いを比較しています。

表 1. ルール・エンジンの違い
クラシック・ルール・エンジン	意思決定エンジン
ルールは IRL に変換されます。IRL は、ルールの低レベルのテキスト表現です。	エンジンのこの実装は、IRL に依存しません。代わりに、BAL ルールが拡張ルール言語 (ARL) に変換されます。したがって、Rule Designer では、 BAL ルール用およびルール・フロー用 IRL タブは、いずれもルール・エディターでは利用できません。ただし、BOM エディターでは、ARL を直接操作して、意思決定エンジン用に設計されたルール・プロジェクトに対してBOM から XOM へのマッピングを定義できます。また、クラシック・ルール・エンジンと同様に、テクニカル・ルール、ルール・フロー・アクション・タスク、および関数で引き続き IRL を使用できます。
クラシック・ルール・エンジンは、以下のように、ルール・アーティファクトを別の方法で処理します。ルール・フローおよび RetePlus ルール・アクションはインタープリットされます。 useJit プロパティーを使用する RetePlus ルール条件は、バイトコードにコンパイルされます。 Sequential アルゴリズムおよび Fastpath アルゴリズムを使用するルールは、バイトコードにコンパイルされます。	ルールとルール・フローは、配布前に、中間コードまたは Java バイトコードへ完全にコンパイルされます。
ルール・セット・アーカイブ .jar ファイルでは、ルールは IRL テキストファイルに含まれます。	ルール・セット・アーカイブ .dsar ファイルは、ルールとルール・フロー用の実行コードを含む、バイナリー・ファイルで構成されています。