ルール・アプリケーションにおける外部データへのアクセス

一般的に、WebSphereのルール実行コンポーネントにデプロイされたルール・アプリケーションから、外部アプリケーション・データにアクセスすることは勧められていませんが、特定の状況では、このアクセスを確実に実行することができます。この記事では、これらの状況について説明し、外部データを処理するための各種オプションを比較します。例として使用するシナリオでは、実践で役立つ手法を紹介しています。

Raj Rao, ILOG Solution Architect, IBM

Rajesh (Raj) Rao はビジネス・ルール管理システムとエキスパートシステムの領域を20年以上担当してきました。この間に彼は製造、交通、金融など多様なお客様の分析、スケジューリング、資格認定や構成決定業務アプリケーションに対してビジネス・ルールのテクノロジーを適用してきました。彼はIBMにほぼ2年間在籍しています。人口知能に関する知識を背景に彼の興味は自然言語処理やセマンティックWebにまで及びます。



2012年 9月 27日

はじめに

意思決定サービスは、意思決定を行うための再利用可能なサービス操作であり、この記事のコンテクストにおいては、ビジネス・ルール・エンジンのテクノロジーによって実装されるサービスを指します。意思決定サービスは、IBM の SOA リファレンス・アーキテクチャーのビジネス・サービス層の一部をなすものであり、これらのサービスの設計は、疎結合および粗粒度の操作、さらには最小ペイロードなどの各種のベスト・プラクティスに基づいて行う必要があります。ビジネス・ルールは、JRules Rule Execution Server (RES) のルール・セットとしてデプロイされ、これらのルールはその後に意思決定サービスによって使用されます。通常、ビジネス・ユーザーが、ビジネス・ルールを管理しますが、意思決定サービスは IT グループによって全面的に管理されています。

ルール・セットは、ルール・セッション API を使用して RES 内で実行されます。このAPI は、クライアントがルール・セッションを取得し、そのセッション内でルールを実行することを可能にします。意思決定サービスは、ルール・セッションのクライアントですが、SOA 以外のアーキテクチャーでは、Web アプリケーションが、サーブレットからルール・セッション API を直接使用するクライアントとなることがあります。この記事では、ルール・アプリケーションのデータ・アクセスに関する各種のオプションを検討しますが、これらのオプションは、Web アプリケーションのルール・クライアント、意思決定サービスまたはビジネス・ルールからの直接のアクセスなど、それぞれに大きく異なるオプションが含まれます。

ルール・セッションは、外部の依存関係がないステートレスなセッションが理想と言えます。従って、通常は、JRules ルール・セットが、ルールの処理時に、データベースまたはサービスから、参照データないしはトランザクション・データにアクセスしないようにすることが勧められています。ルール実行時に、ルール・セットからデータにアクセスしないことには、以下のような主要なメリットがあります。

  • Rule Execution Server (RES) のより優れたパフォーマンス

    通常、外部データへのアクセスには、他のルールの実行よりもはるかに多くの時間がかかります。そのため、合計の処理時間に大きな影響を与えます。それぞれのルール・エンジンは、単一スレッドで実行されるため、このスレッドは、データのアクセス時にブロックされます。そのため、ルール・サーバーは、その間に CPU をフルに利用できなくなる可能性が高くなります。さらに、外部接続が最大数に達すると、ルール・エンジン・プールのサイズにおけるもう 1つの障害が生じる可能性があります。データ・アクセスを実行しないルール・エンジンの場合には、トランザクション負荷が同じ場合でも、必要な RES サーバー数はより少なくなります。

  • より簡単な例外処理:

    外部サービスがダウンするか、またはネットワークの問題が原因となって、外部システムの呼び出しが失敗する可能性は常にあります。失敗すると、例外がスローされます。ルール・エンジンからデータにアクセスしない場合には、これらの例外を処理する必要がありません。

  • より簡単な単体テスト:

    要求ペイロードが自己完結型で、ルール・エンジンが意思決定を行うために必要なすべてのデータを定義している場合、外部サービスまたはデータベースへの依存関係は一切存在しません。この分離されたアーキテクチャーでは、外部データ・ソースまたはデータ・サービスがルール・セットに影響を与えることはありません。依存関係が一切存在しないことから、ルール・セットの単体テストまたは回帰テストを、独立したユニットとして実行することがより容易になります。

しかしながら、ルール・アプリケーションから、ランタイムでのデータ・アクセスを確実に実行できる状況もいくつかあります。例えば、一部のルール処理構成パラメーターがデータベースで維持されている場合には、単純なルックアップ操作でこの構成情報をデータベースから取得できる場合があります。さらに複雑なルックアップ操作では、トランザクション・データベースを呼び出せることがあります。この例として、請求処理アプリケーションが請求内容審査の意思決定サービスに請求 ID を送信した後に、このサービスがトランザクション・データベースの請求履歴を検索する場合があります。また、参照データがデータベースから検索される場合もあります。例えば、車両在庫を管理するルール・セットの場合、オイル交換の時期は、車両カテゴリー、メーカー、モデルおよび年度などに関する、データベースに格納された参照データの内容によって異なるものです。さらに別の一般的な状況として、検証時に外部データの検索が実行される場合があります。例えば、請求の検証ルールには、所定の請求診断コードに対して請求手続きコードが有効であることを確認する検査が含まれる場合があります。参照データベースには、手続きコードを検証コードに関連付ける数万件のレコードが存在することがあり、このルールは、これらのレコードにアクセスすることが必要になる場合があります。

データのソースは、多岐に及びます。データベース、Web サービス、別の意思決定サービス、または長期間実行されるプロセスの場合もあります。これらのデータの中には、アクセスに多くの時間とコストがかかるものもあります。

相違点を考慮する上での別の重要な視点として、要求がどの程度動的であるかという点があります。データ・アクセスに使用されるパラメーターは、ルール・セット内のルールによって計算されることがあります。これらのデータ要求は、この記事の目的上、「動的」要求と呼ぶことにします。動的なデータ・アクセス要求の一例には、ロイヤルティーを計算してから、算出された値と顧客の郵便番号を使用し、データベースから割引率を検索する割引計算ルール・セットがあります。

この記事では、データ検索の要求を処理するさまざまな代替オプションについて説明し、各オプションの評価と共に、全体的な比較を行います。


前提条件

この記事は、中級および上級の JRules 技術開発者向けに書かれており、実装の特定の分野に焦点を当てています。さらに、読者は、開発者の観点で、ILOG JRules の十分な製品知識があることを前提としています。さらに詳しい情報については、「参考文献」セクションを参照してください。

この記事で使用される製品のバージョンは、以下のとおりです。

  • WebSphere ILOG Rule Studio V7.1.x
  • WebSphere ILOG Rule Execution Server V7.1.x
  • WebSphere Application Server V7.0
  • Rational Application Developer V7.5 または Rational Software Architect V7.5

: この記事で紹介されている手法は、JRules, WebSphere Operational Decision Management V7.5 の新バージョンにも適用できます。


シナリオの概要

この記事では、Tutorial: Creating a web application to call JRules on IBM Rational Application Developer というJRules V7.x に付属するチュートリアルから開始し、これを、外部 Web サービスの呼び出しに応用させていきます。シナリオを十分に理解するには、このチュートリアルを実行してみるか、または少なくともこれにざっと目を通すことをお勧めします。このチュートリアルは、IBM Rational Application Developer に固有のものですが、この記事で紹介するデータ・アクセスの各種オプションは、他の IDE や他のアプリケーション・サーバーのデプロイメントにも同様に適用できるものです。このチュートリアルでは、Java® EE のルール・セッションを使用して、単純なローン処理ルール・セットを実行します。図1に示されるように、このルール・セットには、借り手 (入力)、ローン (入力および出力) およびレポート (出力) の3つのパラメーターが必要です。

図1. ルール・セット・パラメーター
図1. ルール・セット・パラメーター

チュートリアルで言及されているように、ローンの検証アプリケーションは、以下を実行します。

  1. Web アプリケーションから入力データを検証する。
  2. 顧客の個人プロファイル、スコアおよび必要なローン金額に基づき、適格性を判定する。
  3. ローンを accept (受入) または reject (拒否) するための特定条件またはスコアを評価する。
  4. 算出されるスコアに応じ、ローン申請が受け入れられた場合の保険料を算出する。

上記は、図2に示すルール・フローを使って実装されます。

図2. ローン処理のルール・フロー
図2. ローン処理のルール・フロー

新規ビジネス・ポリシー

ローン処理を行う企業が、昨今のマクロ経済の不確実性の高まりを背景として、適格性要件をより厳格にすることにした場合を考えてみましょう。この企業は、雇用の追跡を行う外部機関が編纂した最新の指数である「雇用安定指数 (employment stability index)」 を検査することによって適格性を決定するビジネス・ポリシーを新たに追加しました。具体的には、この新規のビジネス・ポリシーは以下になります。

  • 雇用安定指数は、企業スコアが 600 未満で、ローン金額が $50,000 を超える場合は 72 以上になる。
  • 雇用安定指数は、信用スコアが 780 未満で、ローン金額が $80,000 未満の場合に 60 以上になる。
  • 雇用安定指数は、信用スコアが 830 未満で、ローン金額が $80,000 を超える場合に 64 以上なる。

申請者の雇用安定指数は、外部の Employment Service (雇用サービス) にアクセスして取得することができます。このサービスは、社会安定番号(SSN) を入力として受け取り、EmploymentRecord オブジェクトを返します。この Web サービスの呼び出しにはコストがかかるため、これらの呼び出しは最小限に抑える必要があります。

アーキテクチャー

この記事では、この雇用サービスが、雇用指数として 25 から 100 までのランダムな値を返す簡単な Web サービスとして実装されます。図3に示されるように、Web サービスのクライアント・プロキシーが、この Web サービスにアクセスするために LoanValidationWeb アプリケーションで使用されます。Rational Application Developer の標準ウィザードが、Web サービスとクライアント・プロキシーの開発に使用されますが、この詳細は、この記事のコンテクストからは重要でないため、ここでは省略します。図3に示されるように、構造上、重要な実行モジュールは、ローン・データを収集する We b アプリケーション、Rule Execution Server (RES) および Employment Web サービス (雇用 Web サービス)です。

図3. WebSphere の実行コンポーネント
WebSphere execution components

図3に示される Rule Execution Server の4つのルール・セットは、この記事で論じる4つのデータ・アクセスのオプションに対応しているルールの実装です。これらは以下のようになります。

  • オプション A: 外部要求の拡張。
  • オプション B: ルールの左辺部から起動する直接的なデータ・アクセス。
  • オプション B2: ルールの右辺部から起動する直接的なデータ・アクセス。
  • オプション C: 連続的な要求の拡張。

この記事では、上記のオプションについて詳述します。これらのルール・セットは、ローン検証アプリケーションで定義される対応のコントローラー・クラスによって実行されます。オリジナルのチュートリアルとは異なり、これらのコントローラーは、JSP に組み込まれていませんが、Java クラスとして定義されます。

図4に示されるように、オリジナルのチュートリアルの Web アプリケーションのユーザー・インターフェースは、コントローラーのオプションと雇用安定指数を組み込むように変更されます。Web アプリケーションのビルド、デプロイおよびアクセスの方法についての詳細は、チュートリアルの資料でご確認ください。オリジナルのチュートリアルでは、デフォルトでデプロイされる URL は http://localhost:9080/LoanValidationWeb/ ですが、これも若干修正されています。

図4. ローン検証用 Web アプリケーション
図4. ローン検証用 Web アプリケーション

ルールは、ローン・データや、借り手のデータおよび雇用安定度に基づいて承認するか拒否するかを決定します。この処理が終了すると、ローン申請の承認または拒否の理由を説明する一連のメッセージを含むレポートが表示されます。図5は、雇用安定指数が十分な値に満たないためにローンが拒否された例を示しています。これらのメッセージは、ルール・エンジンで生成されます。

図5. ローン処理の結果
図5. ローン処理の結果

ダウンロード資料

この記事では、関連するワークスペースについてのみ詳述します。ただし、Rational Application Developer V7.5 と共に Rule Studio V7.1.x をインストールしている場合には、ワークスペース全体をダウンロードし、この記事の補足となるすべての詳細情報に目を通すことができます。Rational Application Developer に Rule Studio をインストールする方法については、「参考文献」を参照してください。別の実装オプションを含むワークスペースについては、この記事の「ダウンロード」から入手できます。

プロジェクトをインポートするには、以下のステップを実行してください。

  1. dataAccess_pif.zip ファイルをローカル・ディスクにダウンロードする。
  2. Rational Application Developer V7.5 または Rational Software Architect V7.5 を開き、新規ワークスペースを作成する。
  3. 「File (ファイル)」 → 「Import (インポート)」を選択する。
  4. 「Import (インポート)」ダイアログで、「Project Interchange (プロジェクトの交換)」を選択し、「Next (次へ)」をクリックする。
  5. 図6に示されるように、「Import Project Interchange Contents (プロジェクトの交換コンテンツのインポート)」ダイアログで、ダウンロードしたばかりの .zip ファイルを選択し、「Select All (すべて選択)」をクリックしてから、「Finish (終了)」をクリックする。
    図6. プロジェクトのインポート
    図6. プロジェクトのインポート
    図7に示されるように、すべてのプロジェクトがワークスペースにインポートされます。
    図7. インポートされたプロジェクト
    図7. インポートされたプロジェクト
  6. 未完了の JSP ファイルがインポートされる場合には、例えば footer.jsp に JSP エラーが出る場合があります。このエラーを排除するには、「Window (ウィンドウ)」 → 「Preferences (設定)」を選択します。「Preferences (設定)」ページの左ペインにある「Validation(検証)」を選択し、「JSP Content Validator (JSP コンテンツ・バリデーター)」を選択解除します。「Apply (適用)」をクリックしてから「OK」をクリックします。プロジェクトを再度ビルドすると、JSP エラーが表示されなくなります。

この記事のサンプルでは、それぞれの実装オプションを図示するために、別々のプロジェクトを使用しています。表1は、それぞれの実装に関連付けられたルールと ruleapp プロジェクトを示しています。それぞれのルール・プロジェクトには、特定のルール実装が含まれており、これに対応するビジネス・オブジェクト・モデル (BOM) が組み込まれています。ruleapp プロジェクトは、ルールを RES にデプロイするための標準的な方法です。

表1. 各Optionのルールと ruleapp プロジェクト
実装Optionルール・プロジェクトRuleapp プロジェクト
Option A loanvalidation-rules_A loanvalidation-ruleapp_A
Option B loanvalidation-rules_B loanvalidation-ruleapp_B
Option B2 loanvalidation-rules_B2 loanvalidation-ruleapp_B2
Option C loanvalidation-rules_C loanvalidation-ruleapp_C

その他のプロジェクトはすべてのオプションで共通しています。表2は、これらのオプションをリストしています。

表2. プロジェクトの説明
プロジェクト説明
EmploymentWebService雇用安定指数を計算する EmploymentWebServices
EmploymentWebServiceEAREmploymentWebServices のデプロイメント・ユニット。
JRulesEARLoanValiadtion アプリケーションのデプロイメント・ユニット。
LoanValidationWebLoanValidationWeb アプリケーション。これには Java の実行オブジェクト・モデル (XOM) が含まれます。便宜上、この XOM はすべてのオプションに対し、XOM のスーパーセットになります。ただし、BOM は各オプションごとに異なります。

WebContent ディレクトリーに含まれる JSP (ビュー) とは異なり、以下のような3つの主な Java ソース・パッケージが含まれます。

  • loan: XOM が含まれます(モデル)。
  • web: JSP のコントローラーと bean が含まれます (コントローラー)。
  • employment: EmploymentWebServices プロキシーが含まれます。
Rule Execution Server Configurationローカルの WebSphere サーバーにデプロイする RES 構成です。これは、ruleapps によって使用されます。

オプション A: 要求の拡張

単純なオプションには、外部の拡張プロセスにより、ルール要求を外部データで拡張するものです。図8 に示されるように、すべてのデータ・アクセスは、呼び出し側アプリケーションによって、外部データベースに対する JDBC 要求、または他の Web サービスへの SOAP 呼び出しのいずれかを使用して実施され、外部データが要求データと共に渡されます。ルール・セットの点から見ると、要求は自己完結型です。つまり、ルール・セットの実行オブジェクト・モデル (XOM) は、外部データの定義を含む拡張された要求クラスです。

図8. ルール要求の拡張
図8. ルール要求の拡張

図8 は、同一のアプリケーション・サーバー JVM における RES および意思決定サービスか、または Web アプリケーションのいずかのルール・クライアントについて説明しています。さらに、図9 に示されるように、リモート・サーバーか、またはエンタープライズ・サービス・バス (ESB) でもこの拡張が実行できるため、ルール・サーバー上の負荷を減らすこともできます。

図9. リモートの拡張
図9. リモートの拡張

データ・アクセスのパフォーマンスは、とりわけデータがデータベースからアクセスされる場合には、アプリケーション・レベルか、またはデータ・アクセサー・サービスで参照データをキャッシュすることで改善できる場合があります。データのサイズおよび使用法の特徴に応じ、最も関連性のあるデータをキャッシュに入れる、FIFO (First In First Out) などの戦略を駆使`した部分キャッシュが実行される場合があります。データ量が過剰にならない場合は、初期化の段階で、参照データ全体をキャッシュできます。この場合には、メモリーとパフォーマンスのトレードオフの考慮事項が当てはまります。当然のこととして、キャッシングは、データが頻繁に変更されないことが前提になります。データが頻繁に変更される場合には、キャッシュの更新メカニズムが必要になります。そのため、キャッシングは、定常的であるか、または変更頻度の低い参照データにより適しています。

実装の詳細

先に言及したとおり、ここでのルール・セットの XOM は、拡張された要求クラスであり、これには外部データの定義が含まれます。そのため、XOM は、図10 に示されるように、関連する EmploymentRecord を持つ Borrower で拡張されます。次に、この EmploymentRecord クラスには、新規のビジネス・ルールで使用される雇用安定指数が組み込まれます。さらに、Report クラスも、EmploymentRecord で拡張されるため、雇用安定指数を最終レポートの一部として表示することができます。

図10. XOM の拡張
図10. XOM の拡張

外部の Web サービスにアクセスして雇用レコードを取得するタスクは、LoanValidation web アプリケーションによって行われます。とくに、web コントローラー (web.BusinessBeanController_A.java) には、リスト1に示されるように、 Employment Web サービス (下記の12行目) にアクセスし、EmployeeRecord を Borrower (17 行目) に関連付ける executeRulesOnPojoRuleSession と呼ばれるメソッドがあります。

リスト 1. web.BusinessBeanController_A.java
1. public Report executeRulesOnPojoRuleSession(String rulesetPath) throws
    IlrFormatException, IlrSessionException  {
2. IlrSessionRequest sessionRequest = pojoFactory.createRequest();
3. ExternalDataAccessorHelper dataAccessor = 
	dataAccessorFactory.createExternalDataAccessorHelper();
4. Report report = null;
5.			
6. sessionRequest.setRulesetPath(IlrPath.parsePath(rulesetPath));
7. sessionRequest.setForceUptodate(true);
8. // Enable trace to retrieve infos on executed rules
9. sessionRequest.setTraceEnabled(true);
10. sessionRequest.getTraceFilter().setInfoAllFilters(true);
11. // Set the input parameters for the execution of the rules
12. EmploymentRecord empRecord = 
	dataAccessor.getEmploymentRecord(getBorrower().getSSN().toString());
13. if (empRecord == null) {
14.	report = new Report(getBorrower(), getLoan());
15.	report.addErrorMessage("Could not access employment profile. Please try again 
		later");
16.  } else {
17.	getBorrower().setEmploymentRecord(empRecord);
18.	Map<String, Object> inputParameters = sessionRequest.getInputParameters();
19.	inputParameters.put("borrower", getBorrower());
20.	inputParameters.put("loan", getLoan());
21.	// Create a stateless rule session
22.	IlrStatelessSession ruleSession = pojoFactory.createStatelessSession();
23.	// Execute the rules
24.	IlrSessionResponse sessionResponse = ruleSession.execute(sessionRequest);
25.	printResults(sessionResponse);
26.	report = (Report) sessionResponse.getOutputParameters().get("report");
27.  }
28.  return report;
29. }
30.	
31.	
32. @Override
33. public Report executeRules() throws IlrFormatException, IlrSessionException {
34.	return executeRulesOnPojoRuleSession("/loanvalidation_A/loanvalidationrules_A");
35.}

このアプローチでは、例外処理はいたって単純です。 Employment Web サービスにアクセスする際にエラーが生じた場合には、雇用レコードが NULL になります。これにより、エラー・メッセージがレポートに追加され、ルール・エンジンがバイパスされます (13~15行目)。

ルールの実行には、ルール・セットの /loanvalidation_A/loanvalidationrules_A (34行目) が使用されます。ダウンロード可能なコードに従うルールは、loanvalidation-rules_A のルール・プロジェクトで定義されます。

ここで、「新規ビジネス・ポリシー」のセクションに戻って、実装用に設定した新規のビジネス・ルール・セットについて思い起こしてみましょう。2つのビジネス・ルールが、雇用安定度に関連する新規ポリシーを実装するために、eligibility.employment ルール・パッケージに追加されます。1つ目のビジネス・ルールは、企業スコアに基づく検査を行うためのビジネス・アクション言語 (BAL ) ルールとして実装され、2つ目のビジネス・ルールは、信用スコアに基づく検査を行うための意思決定テーブルとして実装されます。リスト2は、BAL ルールを示し、図11は意思決定テーブルを示しています。基本的に、これらのルールは、借り手の雇用安定度を単純な属性として使用し、簡単な方法でこれにアクセスします。

リスト2. BAL のルール・コード
definitions
    set 'employment stability' to the employment stability index of the 
employment record of 'the borrower';
if 
    the amount of 'the loan' is more than  50000
    and the corporate score in 'the loan report' is less than  600
    and 'employment stability' is less than 72
then 
    in 'the loan report', refuse the loan with the message "Insufficient 
employment stability of " + 'employment stability' ;
図11. 雇用安定度に関する意思決定テーブル
図11. 雇用安定度に関する意思決定テーブル

ルール・セットのルール・フローは一切変更されないため、これらの新規ビジネス・ルールを組み込むために必要なルール・セットの変更は簡単に実行できます。つまり、BOM を更新するのみで、新規の XOM エレメント (EmployeeRecord) と新規ビジネス・ルールの2つの成果物を取得できます。

マイナスの点を挙げるとすれば、 Employment Web サービスは、不要な場合 (例えば、ローン金額が 30,000 で信用スコアが 800 の場合) でも呼び出されるために、無駄が発生します。さらに Employment Web サービスがダウンしている場合は、雇用安定指数を検査する必要がないローン申請を含むローンが一切承認されなくなります。最も重要な点として、このシナリオには該当しませんが、このアプローチは動的なデータ・アクセスを処理できません。例えば、Web サービスの呼び出しパラメーターとして、ルール処理時に導き出される企業スコアなどの算出値が使用される場合には、このオプションの実行は明らかに不可能になります。

評価

表3は、このアプローチのプラス面とマイナス面をまとめています。

表3. データ拡張に関する評価
プラスマイナス
  • 意思決定サービスを他のシステムから切り離せる。
  • ルールのコンポーネント・テストが簡単。
  • ルール・オーサリングへの影響を最小限にできる。
  • リモート・サーバーでデータ・アクセスを実行できるため、RES サーバーの CPU 負荷を減らすことができる。
  • XSD XOM を使用できるため、デプロイメント・オプションとして Hosted Transparent Decision Service (HTDS) を使用できる。
  • 拡張を、このタスクにより適した ESB メディエーターに委任できる。さらに、これにより、データ・キャッシュを行い、外部アクセスを減らすことができる。
  • 動的なデータ・アクセスの要求には対応できない。
  • データ・アクセスがコンテクスト・ベースではないため、取得されるすべてのデータが特定の要求の処理に不要になる場合には無駄が発生する。
  • アプリケーションの一定期間の変化に伴って、追加のデータ・エレメントが必要になる場合、(図9 に示すように) データがリモートで拡張された場合には意思決定サービスのシグニチャーの変更が必要になる。

オプション B: ルール実行時の直接的なデータ・アクセス

さらに直接的なオプションとして、ルールの実行中に随時データ・アクセスを実行するオプションがあります。ここでもまた、データ・アクセスは、データベースに対する JDBC 呼び出しか、または外部 Web サービスへの呼び出しのいずれかになります。データ・アクセスは、Java コードを使用して実行されます。この Java コードは、XOM の一部であり、図12に示されるように、ルールの実行中にルールによって呼び出されます。

図12. 直接的なデータ・アクセス
図12. 直接的なデータ・アクセス

実装の詳細

外部データのアクセスは、XOM の Java クラスを使用して実施されます。ExternalDataAccessorHelperFactoryExternalDataAccessorHelper という2つの主要なインターフェースが、これを実行するために XOM に追加されます。ファクトリーが、getEmploymentRecord というメソッドを持つExternalDataAccessorHelper を初期化するために使用され、Web サービス・プロキシーを使用して Employment Web サービスから雇用レコードが取得されます。

上記は、特定のクラスではなく、インターフェースとして定義されていますが、この理由には、以下の2つがあります。1) 不要な Web サービス関連のクラスによってBOM を複雑にしない、2) このファクトリー・インターフェースの別の実装を単体テストに使用できるようにする。図13では、ExternalWebServerHelperFactoryExternalWebServerHelperImpl の特定のクラスが、典型的なファクトリー設計パターンを使用して、これらのインターフェースを実装します。

図13. 外部データ・アクセサーの Java クラス
図13. 外部データ・アクセサーの Java クラス

クリックして大きなイメージを見る

図13. 外部データ・アクセサーの Java クラス

図13. 外部データ・アクセサーの Java クラス

ExternalWebServerHelperImpl は、リスト3に示されるように、Web サービスを呼び出してから、結果をローカル・キャッシュに保存します。このようにすることで、データ・アクセス要求が、要求の処理中にルールによって再実行される場合にも、ローカル・キャッシュから値が取得されるため (6~7 行目)、外部 Web サービスの呼び出しを行う必要がなくなります。

リスト 3. データ・アクセサーの実装
1. @Override
2. public EmploymentRecord getEmploymentRecord(String ssn) {
3.	EmploymentRecord record = null;
4.			
5.	// check if it is already fetched during this session
6.	record = recordMap.get(ssn);
7.	if (record == null) {
8.	  // access web service
9.	  try {
10.		EmploymentServiceDelegate port = 
			employmentService.getEmploymentServicePort();
11.		record = port.getRecord(ssn);
12.		recordMap.put(ssn, record);
13.	} catch (Exception e) {
14.		e.printStackTrace();
15.			}
16.	} 
17. return record;
18. }

ExternalDataAccessorHelperFactoryExternalDataAccessorHelper の2つのインターフェースは、BOM にインポートされます。ここで、ルールは必要に応じて getEmploymentRecordを呼び出すことができます。しかし、ルール・セットはどのようにExternalDataAccessorHelperFactory を取得するのでしょうか。これは、図14に示されるように、入力パラメーターとして渡されます。

図14. データ・アクセサー・ファクトリーを含むルール・セット・パラメーター
図14. データ・アクセサー・ファクトリーを含むルール・セット・パラメーター

データ・アクセサー・ファクトリーは、ルール内で直接使用されないために言語化されません。図15に示されるように、ルールで使用されるものはデータ・アクセサーであり、これはルール・セットの変数として定義され、言語化されます。

図15. データ・アクセサーのルール・セット変数
図15. データ・アクセサーのルール・セット変数

この変数は、リスト4に示されるように、ルール・フローの初期のアクションで設定されます。

リスト4. ルール・フローの初期アクション
loan.ExternalDataAccessorHelperFactory factory = 
	(loan.ExternalDataAccessorHelperFactory)context.getParameterValue
	("dataAccessorFactory");
context.setParameterValue("dataAccessor", 
    factory.createExternalDataAccessorHelper());

ルール・フローは、必要時にのみ適格性ルールを起動するように調整されます。この場合、初期検証が失敗しても、外部 Web サービスへのコストのかかる呼び出しを行う必要がないことに注意してください。ローンが拒否されていない場合にのみ、雇用安定度に関するガイドラインを起動する適格性サブフローを作成して処理が実行されます。図16が、このサブフローを説明しています。

図16. 適格性サブフロー
図16. 適格性サブフロー

これで Web サービスを呼び出すルールを検査できるようになりました。使用している用語について簡単に説明すると、「ルール」は、if 「P」 then 「Q」 の形式で表されます。ここで、「P」は、ルールの一連の条件であり、ルールの左辺 (LHS) とも呼ばれています。それに対し「Q」は、ルールの動作を表し、ルールの右辺 (RHS) とも呼ばれています。

この時点で、以下の2つのオプションのいずれかを選択できます。

  1. オプション B: ルールの条件、つまりルールの左辺 (LHS) からデータ・アクセサーを起動する。
  2. オプション B2: ルールの動作、つまりルールの右辺 (RHS) からデータ・アクセサーを明示的に呼び出す。

オプション B: ルールの条件から外部データにアクセスする

データ・アクセサーは、employmentRecord という Borrower の読み取り専用の仮想属性を追加することで、ルールの 左辺 (LHS) から透過的に起動できます。図17 に示されるように、これは BOM エディターで実行できます。

図17. BOM にある Borrower の仮想属性「employmentRecord」
図17. BOM にある Borrower の仮想属性「employmentRecord」

この属性の種類は、EmploymentRecord です。当然のこととして、これは仮想属性に過ぎないため、BOM から XOM (B2X) へのマッピングによってバックアップする必要があります。データ・アクセサーを使用して外部 Web サービスを呼び出し、雇用レコードを戻す実際のタスクは、B2X で行われます。例外処理もこのB2X で行われます。リスト5に示されるように、このサービスから戻される雇用レコードが NULL の場合、例外がデータ・アクセス時に発生したことを示すため、エラー・メッセージが作成されます。データ・アクセサーは、借り手 (Borrower) の SSN を使用して実行されます (2行目)。この処理中に例外がある場合には、エラー・レコードがインスタンス化されます (6-9 行目)。

リスト5. Borrower.employmentRecord BOM から XOM へのマッピング
1. ExternalDataAccessorHelper accessor = (ExternalDataAccessorHelper) 
	context.getParameterValue("dataAccessor");
2. EmploymentRecord record = accessor.getEmploymentRecord(this.getSSN().toString());
3. Report rpt = (Report) context.getParameterValue("report");
4. if (record == null) {
5. 	//create a "error" record with negative index
6.	record = new EmploymentRecord();
7.	record.ssn = "ERROR";
8.	record.employmentStabilityIndex = -1;
9.	rpt.addErrorMessage("Error retrieving employment profile! 
		Please try again later.");
10.}
11.rpt.employmentRecord = record;
12.return record;

データのアクセスは、借り手の雇用レコードへのアクセス時に背後で行われるため、データ・アクセサーのルール自体への侵入は最小限に抑えられます。例えば、リスト6に示されるように、企業スコアに基づいて雇用安定度を検査するルールでは、データ・アクセサーを直接参照しません。

リスト6. 左辺 (LHS) からのデータ・アクセス
if 
    the amount of 'the loan' is more than  50000
    and the corporate score in 'the loan report' is less than  600
    and the employment stability index of the employment record of 
	'the borrower' is less than 72
then 
    in 'the loan report', refuse the loan with the message "Insufficient 
	employment stability of " 
      + the employment stability index of the employment record of 'the 
	borrower' ;

このオプションの主なメリットは、オプション A と同様に、データ・アクセスが、ルール開発者やビジネス・ユーザーに見えない方法で行われる点です。さらに、データ・アクセスは、必要な場合にのみ実行されるため、データ・アクセスの無駄が発生しません。例えば、図18 では、ローンがすでに承認されており、信用スコアと企業スコアがどちらも高いため、雇用安定度の検査が不要なケースについて説明しています。

図18. 雇用レコードを必要としないシナリオ
図18. 雇用レコードを必要としないシナリオ

別のメリットは、例外処理がビジネス・ユーザーの介入なしに内部で行われる点にあります。図19 は、例外シナリオ(Web サービスがダウンした場合) の安全な処理について説明しています。先のリスト 5 に示されるように、これは B2X で処理されます。

図19. データ・アクセサーの例外結果
図19. データ・アクセサーの例外結果

一方で、データ・アクセサー・ファクトリーが入力ルール・セット・パラメーターとして提供されるため、要求データは完全な自己完結型ではなく、そのため単体テストを実行するのがやや難しくなります。さらに、Employment Web サービスのインターフェースが変更される場合、ルール・セットの XOM (および BOM) も、これに対応されるように修正する必要があります。

さらに別の危険として、Rete ネットワークのアクティブ化に関連する点があります。オブジェクトが同等であっても異なる場合には、同一の引数に対するデータ・アクセサーの呼び出しによって戻されます。つまり、同一ルールが複数回起動される可能性があります。これは、パフォーマンスにネガティブな影響を与え、無限ループが発生する可能性を発生させます。しかし、この問題は、先のリスト 3で実行したように、データ・アクセサーで応答をローカルにキャッシュし、Web サービスを呼び出す前にキャッシュを検査することで、簡単に回避することができます。キャッシングについては、1つのルール要求に対して多数のデータ・アクセスが発生する場合には、キャッシングに使用するメモリーを管理可能なレベルに維持する必要があることに注意してください。

このアプローチのもう1つの不利な点は、データが随時取得されるという点であり、ユーザーはこの事実に留意する必要があります。そのため、ルール・フローの設計時に注意深い検討が必要になります。同一のルール・タスク内に複数のデータ・アクセスが設定されている場合、これらのデータ・アクセス要求すべてが、不要なものも含めて実行されてしまう可能性があることを意味します。従って、ルール・セットは、同一ルール・タスク内に複数の従属的なデータ・アクセスを設定しないことにより、データの取り出しの無駄を回避できるように設計する必要があります。

評価

表4は、このアプローチのプラス面とマイナス面を示しています。

表 4. 左辺 (LHS) からの直接的なデータ・アクセスに関する評価
プラスマイナス
  • データは必要な場合にのみ取得される。
  • 動的なデータ・アクセス要求を処理できる。
  • 追加のデータ・エレメントが後に必要になる場合にも、意思決定サービスのシグニチャーを変更する必要がない。
  • 透過的なデータ・アクセスと例外処理。
  • データ・アクセスの意思決定サービスのスループットのパフォーマンスにマイナスの影響がある。
  • コンポーネント・テストがより難しくなる。制御されたコンポーネント・テストを実施するには模擬データ・アクセス層が必要。
  • Java XOM が必要となり、HTDS.Java の使用は不可になる。
  • BOMへの影響がある。
  • ルール・フローは、データ・アクセスの無駄を最小限に抑えるように注意深く設計する必要がある。

オプション B2: ルール動作から外部データにアクセスするルール

このオプションでは、ルールは、必要に応じて、ルールの動作 (RHS) から追加データを明示的に要求します。この追加データの要求は、図20 に示されるように XOM のAugmentationAction クラスによって実装されます。

図20. AugmentationAction XOM
図20. AugmentationAction XOM

このクラスの属性については、以下のサンプルのインスタンスを使って説明します。オブジェクトのインスタンスは以下のようになることがあります。

データ・エレメントコメント
augmentationType = EMPLOYMENT_RECORDThis request is to fetch the employment record (only available option for this scenario)(この要求は、雇用レコードの取り出しです) (このシナリオの場合にのみ有効なオプションです。)
requestParameters = <SSN, “123-45-6789”> Fetch employment record for the specified SSN (指定の SSN についての雇用レコードを取り出します。)
requestContext = 72The rule that created this request mandates a minimum stability index requirement is 72 (この要求を作成したルールは、安定指数の最小値の要件が 72 になることを規定しています。)

データ・アクセサーは、この動作を実行するために使用され、結果として、動作オブジェクトの他の属性が入力されます。例えば、この動作の実行後に、インスタンスには以下が含まれる場合があります。

データ・エレメントコメント
augmentationResponse = EmploymentRecord<"123-45-6789", 56> The retrieved employment record has a stability index of 56 (取得された雇用レコードの、安定指数 は 56 です。)
resultType = SUCCESS Successfully retrieved (正常に取得されました。)
logMessage = ""No messages from the data accessor. (データ・アクセサーからのメッセージがありません。)

例えば、信用スコアが低く、雇用安定度の検査が必要となる場合に、ルールは、AugmentationAction オブジェクトを作成し、これをルール・エンジンのワーキング・メモリーに挿入する場合があります。リスト7はこのルールを示しています。

リスト 7. 追加データを要求するルール
1. if 
2.	the amount of 'the loan' is more than  50000
3.	and the corporate score in 'the loan report' is less than  600
4. then 
5.    execute employment record action with stability requirement of 72 ;

ここで、「execute employment record action」(5行目) は、図21に示される BOM で定義される、仮想の静的メソッドです。

図21. 仮想のcreateEmploymentRecordAction メソッド
図21. 仮想のcreateEmploymentRecordAction メソッド

リスト 8 に示されるように、このメソッドでの BOM から XOM へのマッピングにより、AugmentationAction インスタンスが作成され (1~2行目)、そのインスタンスの必要な属性が設定 (3~7 行目) された後にこれを実行して、データ・アクセサーによって雇用レコードを取得します (8行目)。その後、このオブジェクトが他のルールでも使用できるようにワーキング・メモリーに挿入されます (9行目)。

リスト 8. 右辺 (RHS) からのデータ・アクセスにおける BOM から XOM へのマッピング
1. definitions 
2.  set 'augmentation action' to an augmentation action 
3.	where the augmentation type of this augmentation action is EMPLOYMENT_RECORD
4.	  and the result type of this augmentation action is SUCCESS;
5.  set 'employment record' to an employment record from the response of 'augmentation 
        action' ;  
6.  set 'employment stability' to the employment stability index of 'employment record' ; 
7.  set 'stability requirement' to the stability requirement of 'augmentation action' ;  
8. if
9.  'employment stability' is less than 'stability requirement' 
10. then
11.	in 'the loan report', refuse the loan with the message 
12.		"Insufficient employment stability of " + 'employment stability' ;

ワーキング・メモリーに挿入されたこの AugmentationAction 結果を処理するために、他の2つの汎用ルールが追加されます。1つ目のルールは、リスト 9 に示されるように、データが正常に取得された場合の処理を行います。これは、正常なデータ・アクセスを処理する汎用ルール (2~4行目) であり、実際の雇用安定指数が「augmentation action (拡張アクション)」オブジェクトを作成したルールのガイドラインに満たさない場合は、ローンを拒否します (9 行目)。

リスト9. 正常なデータ・アクセスの実行を処理するルール
1. definitions 
2.   set 'augmentation action' to an augmentation action 
3.	where the augmentation type of this augmentation action is EMPLOYMENT_RECORD
4.	   and the result type of this augmentation action is SUCCESS;
5.   set 'employment record' to an employment record from the response of 
		'augmentation action' ;  
6.   set 'employment stability' to the employment stability index of 
        'employment record' ; 
7.   set 'stability requirement' to the stability requirement of 'augmentation action' ;  
8. if
9.   'employment stability' is less than 'stability requirement' 
10. then
11.	in 'the loan report', refuse the loan with the message 
12.		"Insufficient employment stability of " + 'employment stability' ;
リスト 10. データ・アクセスの例外を処理するルール
definitions
    set 'augmentation action' to an augmentation action 
	where the augmentation type of this augmentation action is 
		EMPLOYMENT_RECORD
	   and the result type of this augmentation action is ERROR;
then
    in 'the loan report', add the error message 
    	"System error while accessing employment profile. Please try 
		again later.";

評価

表5は、このアプローチのプラス面とマイナス面をまとめています。

表 5. ルール動作から外部データにアクセスするルールに関する評価
プラスマイナス
  • データは必要な場合にのみ取得される。
  • 動的なデータ要求を処理できる。
  • 追加のデータ・エレメントが後に必要になる場合にも、意思決定サービスのシグニチャーを変更する必要がない。
  • データ・アクセスをより明示的にコントロールできる。
  • 複雑度が高い。
  • ルール・オーサリングに大きな影響がある。
  • データ・アクセスの意思決定サービスのスループットのパフォーマンスにマイナスの影響がある。
  • コンポーネント・テストがより難しくなる。制御されたコンポーネント・テストを実施するには模擬データ・アクセス層が必要。
  • Java XOM が必要となり、HTDS は不可になる。
  • データベース関連の例外処理を、ルール内で明示的に実行することが必要になる場合がある。
  • ルール・フロー/ルールと XOM への影響がある。
  • 戻り値のより効果的な処理方法 (この例では、要求コンテキストの使用など) が必要になる場合がある。

オプション C: 連続的なデータ拡張

このオプションを使用すると、ルール・セットは、追加データの取り出し要求と共に、ルール・クライアントに応答を戻します。その後、データの取り出し要求は、呼び出し側アプリケーションによって実行されます。つまり、データ・アクセスは、ルール・セットと呼び出し側アプリケーションの共同責任になり、ルール・セットは、取得するデータを指定し、呼び出し側アプリケーションは、データを取得し、段階的に拡張された要求を再送します。

図22. 連続的なデータ拡張
図22. 連続的なデータ拡張

以下のような順序になります。

  1. アプリケーションを呼び出して、ルール要求をルール・セットに送信する。
  2. ルールの実行時に外部データが必要となる場合には、ルール・セットの応答に必要なデータの要求が組み込まれる。
  3. ルール・セットの応答にデータ要求が含まれる場合、アプリケーションの呼び出しにより、データが取得され、要求が拡張される。
  4. ルール・セットの応答に追加データの要求がなくなると、ルール処理は完了する。ループを終了します。
  5. ステップ1に戻る。

このアプローチでは、ルール・セットの複数の呼び出しが、外部要求を処理するために必要になる場合があります。要求は、ルール・セットによって要求されるデータによって連続的に拡張されます。ルール・クライアントは、ルール・セットをローカルか、またはリモートで呼び出すことができます。どちらの場合にも、オーケストレーションの要件により、ルール・セットは、ルール・クライアントと併用する場合にのみ、使用可能になります。

このアプローチにおける小規模な差異は、ルール・クライアントは、データの拡張時に複数の異なるルール・セットを徐々に呼び出すという点です。

実装の詳細

ここまでで、このオプションとオプションB2 にはいくらかの類似点があることに気付かれるかもしれません。確かにこれらのオプションは似ており、このオプションでも、追加データの要求を拡張アクションによって取り込む必要があります。実際、このオプションでは、先に定義したAugmentationAction クラスと同様の ExternalAugmentationAction クラスを定義します。AugmentationAction クラスの場合には、図23に示されるような execute() メソッドが付加されていない点が異なります。

図23. オプション C における XOM の変更
図23. オプション C における XOM の変更

この ExternalAugmentationActionn クラスは、ルール・セットで指定される要求パラメーターと、データ・アクセスの結果を含む拡張応答を保持します。このクラスは、「オプション B2: ルール動作から外部データにアクセスするルール」というセクションで詳述されている AugmentationAction クラスと非常に似ています。

ここには、dataRequestsdataAugmentations という2つの新たなルール・セット・パラメーターがあります。ルール・セットは、ExternalAugmentationAction クラスのインスタンスを作成し、これらを dataRequests という出力パラメーターに入れることにより、追加データの要求を行います。 ルールが ExternalAugmentationAction のインスタンスを作成すると、そのステータスが「NOT_PERFORMED」に初期設定されます。アプリケーションは、これらの要求を満たすために外部 Web サービスからデータを取得した後、拡張されたデータが dataAugmentations 入力パラメーターの呼び出しによってルール・セットに渡されます。これらのインスタンスには、データが外部 Web サービスから正常に取得されたかどうかに応じて、「SUCCESS」または「ERROR」のいずれかの結果タイプが含まれます。図24は、ルール・セット・パラメーターを示しています。

図24. データ要求とデータ拡張を含むルール・セット・パラメーター
図24. データ要求とデータ拡張を含むルール・セット・パラメーター

Web コントローラーは、データ要求があるかどうかを確認し、要求がある場合には、それらの要求を満たすべく、拡張データを要求される通りに送信します。コードの主要な部分は、リスト11に太字で示されています。8~30行目のコードは、連続的なデータ・アクセスを実行します。ルールは、18行目と21行目で実行され、新規のデータ要求が特定されます。24行目では、実際の外部データ・アクセスが実行され、26行目ではデータの拡張が設定され、これが次のルール・セットの呼び出しで送信されます (14行目)。

リスト11. BusinessBeanController_C.java の抜粋
1. public Report executeRulesOnPojoRuleSession(String rulesetPath) throws 
      IlrFormatException, IlrSessionException  {
2.	IlrSessionRequest sessionRequest = pojoFactory.createRequest();
3.	ExternalDataAccessorHelper dataAccessor = 
    dataAccessorFactory.createExternalDataAccessorHelper();
4.	Report report = null;
5.	ExternalAugmentationAction[] dataAugmentations = new 
		ExternalAugmentationAction[0];
6.	int iterationNum = 0;
7.	boolean continueRuleInvocation = true;
8.	while (continueRuleInvocation && iterationNum++ < MAX_INVOCATIONS) {
9.	sessionRequest.setRulesetPath(IlrPath.parsePath(rulesetPath));
10.		// Set the input parameters for the execution of the rules
11.		Map<String, Object> inputParameters = sessionRequest.getInputParameters();
12.		inputParameters.put("borrower", getBorrower());
13.		inputParameters.put("loan", getLoan());
14.		inputParameters.put("dataAugmentations", dataAugmentations);
15.		// Create a stateless rule session
16.		IlrStatelessSession ruleSession = pojoFactory.createStatelessSession();
17.		// Execute the rules
18.		IlrSessionResponse sessionResponse = ruleSession.execute(sessionRequest);
19.		report = (Report) sessionResponse.getOutputParameters().get("report");
20.		ExternalAugmentationAction[] additionalDataRequests 
21.					= (ExternalAugmentationAction[])	
     sessionResponse.getOutputParameters().get("dataRequests");
22.		if (additionalDataRequests != null && 
			additionalDataRequests.length > 0) {
23.			//execute
24.			execute (additionalDataRequests, dataAccessor);
25.			//add it to response list!
26.			dataAugmentations = addAll(dataAugmentations, 
                additionalDataRequests);
27.		} else {
28.			continueRuleInvocation = false;
29.		}
30.	}
31.	return report;
32.   }

リスト12は、このデータ拡張要求を作成するルールを示しています。このルールには、データ拡張がすでに試行 (正常に実行されたか、またはエラーが発生したか) されているかを検査する条件 (4-7 行目) が含まれます。

リスト12. 追加データを要求するルールの抜粋
1. if 
2.	the amount of 'the loan' is more than  50000
3.	and the corporate score in 'the loan report' is less than  600
4.	and the number of external augmentation actions
5.	where the augmentation type of each external augmentation action is 
		EMPLOYMENT_RECORD 
6.	     and the result type of each external augmentation action is one of 
		{ ERROR , SUCCESS }  , 
7.	is 0     
8. then 
9.  create employment record action with stability requirement of 72;

ルールの動作 (9 行目) は、データ要求を作成する仮想の静的メソッドであり、図25に示されるように、これを出力アレイに追加します。

図25. 拡張要求を作成する仮想メソッド
図25. 拡張要求を作成する仮想メソッド

リスト13に示されるように、この仮想メソッドは、B2X マッピング・コードによってバックアップされます。このメソッドでは、ExternalAugmentationAction が作成され、適切なデータを使って初期化 (1~5行目) された後に、ワーキング・メモリーに挿入されます (6行目)。最後に、この新たに作成されたアクション・インスタンスが出力アレイに追加されます (17 行目)。

リスト 13. データ拡張要求を作成するためのBOM から XOM へのマッピングの抜粋
1. ExternalAugmentationAction augmentationAction 
2.	= new ExternalAugmentationAction
		(AugmentationRequestType.EMPLOYMENT_RECORD);
3. Borrower borrower = (Borrower) context.getParameterValue("borrower");
4. augmentationAction.addRequestParameter("SSN", borrower.getSSN().toString());
5. augmentationAction.requestContext = new java.lang.Integer((int) stabilityIndex);
6. context.insert(augmentationAction);
7.
8. //add to the data augmentation requests to be sent back
9.   ExternalAugmentationAction[] request 
10.	= (ExternalAugmentationAction[]) context.getParameterValue
		("dataRequests");
11.   ExternalAugmentationAction[] newRequestArray = new 
		ExternalAugmentationAction[request.length + 1];
12.   int i = 0;
13.   for (i=0; i<request.length; i++) {
14. 	newRequestArray[i] = request[i];
15.   }
16.   newRequestArray[request.length] = augmentationAction;
17.   context.setParameterValue("dataRequests", newRequestArray);

拡張データが利用可能になると、これがルール内の意思決定を行うために使用されます。リスト14に示されるルールは、正常な拡張動作により、ローンを拒否するという意思決定を行うプロセスを示しています。

リスト 14. 拡張データに基づいて意思決定を行うルール
definitions 
   set 'augmentation action' to an external augmentation action 
	where the augmentation type of this external augmentation action is 
	  EMPLOYMENT_RECORD	
	  and the result type of this external augmentation action is SUCCESS;
   set 'employment record' to an employment record from the response of 
	'augmentation action' ;  
   set 'employment stability' to the employment stability index of 'employment 
	record' ; 
   set 'stability requirement' to the stability requirement of 'augmentation 
	action' ;  
if
   'employment stability' is less than 'stability requirement' 
then
   in 'the loan report', refuse the loan with the message "Insufficient employment 
	stability of " + 'employment stability' ;

例外は、ルールを使用して明示的に処理されます。リスト15は、データ要求のいずれかが ERROR ステータスで戻される場合 (2~4行目) に、エラー・メッセージをレポートに追加する (8行目) ルールを説明しています。

リスト15. 例外処理のルール
1. definitions 
2.   set 'augmentation action' to an external augmentation action
3.     where the augmentation type of this external augmentation action 
	is EMPLOYMENT_RECORD
4.       and the result type of this external augmentation action is ERROR;
5. if
6.   true
7. then
8.       in 'the loan report', add the error message "System error while 
		accessing employment profile. Please try again later." ;

ここまでで、このアプローチはかなり複雑であるということにお気付きかもしれません。ルールは、データを明示的に要求すると共に、ルールが成功および失敗したデータ・アクセス応答を明示的に処理します。これらのルールには、非常にテクニカルなものや、かなり一定したあるものが含まれますが、これについては、ビジネス・ユーザーが保守する必要がなく、IT が保守する別個のルール・パッケージに移管できます。ただし、この複雑性の影響は、他のビジネス・ルールにも及びます。そのため、ビジネス・ユーザーは、データ・アクセスにまつわる複雑性から完全に保護される訳ではなく、またルールの保守をビジネス・ユーザー外に移管し、開発者の関与が増えることになるため、ビジネス・ルール管理システムの主要な利点の1つが失われることになります。

1つのプラスの点として、ルール開発が IT 開発者に委ねられる場合、IT 開発者によるデータ・アクセスの例外処理の管理が強化されることになります。さらに、このアプローチでは、動的なデータ・アクセス要求の処理が可能です。例えば、ルールの処理時に導き出される信用格付けをパラメーターとして使用してWeb サービスを呼び出すシナリオなどを想定できます。このシナリオでは、要求パラメーターの ExternalAugmentationAction によって、信用格付けの引き渡しが行われます。

評価

表6は、このアプローチのプラス面とマイナス面をまとめています。

表6. 連続的なデータ拡張に関する評価
プラスマイナス
  • データは必要な場合にのみ取得される。
  • ルール要求は自己完結型であり、ルール・セットには外部の依存関係がない。
  • データ・アクセスによるルール・スループットのパフォーマンスへの直接的な影響はない。
  • Java XOM が不要なため、HTDS は除外されない。ただし、XOM を Java で使用する方がより柔軟かつ便利。
  • 1つの要求ごとに複数の意思決定サービスの呼び出しが必要になる。これにより、多くのラウンドトリップが必要になる場合にはパフォーマンスへのマイナスの影響がある。
  • コンポーネント・テストがより難しくなる。
  • 複雑度が高まる。
  • 明示的なデータ・アクセス・ルールが必要になる。ビジネス・ユーザーは、データ・アクセスの複雑さを免れることができない。

各種オプションの比較

以下の表は、データ・アクセスの各種オプションを、一連の条件に基づいて比較評価した結果をまとめたものです。「+」記号は、該当するオプションが条件を満たしていることを示し、「-」記号はそうではないことを示しています。記号の数 (1-3の間) は、各オプションがそれぞれの条件を満たしているか、または満たしていないかの度合いを示しています。例えば、「+」記号が3つある場合には、該当するデータ・アクセスのオプションが、その条件を非常によく満たしていることを示しています。

Request augmentationDirect access (LHS)Direct access (RHS)Successive request enrichment
Loose coupling (ruleset is unaware of data access)plusplusplusminusminusplus
High ruleset throughputplusminusminusminusminusminus
Handle truly dynamic data accessminusminusminusplusplusplusplusplusplusplusplusplus
Ease of exception handlingplusplusplusminusminusminusminusminus
Reduce wasteful data accessminusminusminusplusplusplusplusplusplusminusminusminus
Minimize integration layer complexityplusplusplusplusminusminus
Minimize object model complexityplusplusminusminusminusminus
Minimize rule authoring impactplusplusplusplusminusminusminusminusminus
Ease of ruleset component testingplusplusplusminusminusplus
Allows HTDS (no Java XOM requirement)plusplusplusminusminusminusminusminusminusplus

上記の表より、最初の「要求の拡張」オプションは、仮に以下の2つの条件が真である場合には、データ・アクセスの実行における最善のアプローチであることが明らかになります。

  1. 実行可能である。データ収集の要求は動的ではない。
  2. さほど無駄が発生しない。データ・アクセス操作にさほどコストがかからない。

しかし、上記のいずれかの条件が真にならない場合には、左辺のルールからデータに直接アクセスする方法が望ましいオプションになります。右辺からの直接的なデータ・アクセスは、ルール・セットがビジネス・ユーザーではなく、IT 開発者によって保守される場合で、これらの IT 開発者が積極的に例外処理の管理を行う場合には望ましいオプションと言えるでしょう。図26では、これらの要因に基づく、適切なデータ・アクセスのオプションの判断に役立つ意思決定ツリーを示しています。

図26. データ・アクセス・オプションを判断するための意思決定ツリー
図26. データ・アクセス・オプションを判断するための意思決定ツリー

検討中のシナリオでは、 Employment Web サービス・アクセスがコストのかかる操作であるため、優先されるアプローチは、左辺のルールから直接データにアクセスするオプション (オプション B) ということになります。


結論

この記事では、ビジネス要件が外部データの使用法をどのように定めるものとなるかを検討してきました。このデータ・アクセスは、単純なものもあれば、コンテクストに基づくもの、または動的なものもあります。データ・アクセスの要求の処理にあたっては、複数のオプションがあります。最も簡単なオプションは、外部データを直接取り出し、ルール要求をこのデータで拡張する方法です。ただし、これには、無駄が伴い、動的なデータ・アクセス要求の場合には対応できない可能性があります。他のオプションには、ルールの実行時に、左辺または右辺のルールからデータを取り出す方法や、ルール・エンジンへの複数のラウンドトリップを通して要求を連続的に拡張する方法があります。この記事では、同じシナリオを使用してこれらのオプションを詳述し、比較評価を行い、さらに読者の状況に適したデータ・アクセスのオプションとは何かを判断する上でに役立つ意思決定ツリーを記載しています。


ダウンロード

内容ファイル名サイズ
Project interchange filedataAccess_pif.zip333KB

参考文献

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=WebSphere
ArticleID=837296
ArticleTitle=ルール・アプリケーションにおける外部データへのアクセス
publish-date=09272012