| Oracle Fusion Middleware Oracle Business Rulesユーザーズ・ガイド 11g リリース1(11.1.1.7) B55917-05 |
|
 前 |
 次 |
この章では、Oracle Business Rulesをサポートするデシジョン・コンポーネントについて説明します。また、デシジョン・コンポーネントの使用方法について、ルールおよびルールセットを、複数のビジネス・プロセスから起動できる再利用可能なサービスとして公開するメカニズムとして説明します。
デシジョン・コンポーネントは、コンポジット内で使用でき、かつBPELコンポーネントに接続できるSCAコンポーネントです。それ以外に、デシジョン・コンポーネントはHuman WorkflowでのMediatorおよび拡張ルーティング・ルールの動的ルーティング機能に使用されます。
この章の内容は次のとおりです。
デシジョン・コンポーネントは、基礎となるデシジョン関数にルール・セッションをラップするWebサービスです。
デシジョン・コンポーネントは、次の要素で構成されています。
Rules Engineを使用して評価されるルールまたはデシジョン表。これらはRules Designerを使用して定義し、ビジネス・ルール・ディクショナリに格納します。
特定のルールの評価に必要なファクトを記述したメタデータ。ルールまたはデシジョン表を含む各ルールセットは、入力および出力であるファクトとともにサービスとして公開されます。これらのファクトは、XSD定義を介して公開される必要があります。
たとえば、信用格付ルールセットにはファクトとして顧客IDおよび過去のローン履歴が必要ですが、年金支払ルールセットにはファクトとして従業員の勤続年数、給与および年齢の値が必要です。
詳細は、第11.2.1項「デシジョン・コンポーネント・メタデータの使用」を参照してください。
Webサービスは、基礎となるルール・エンジンに入力、出力およびコールをラップします。
このサービスにより、ビジネス・プロセスはファクトをプロセスの一部としてアサートしたり、取り消すことができます。すべてのファクトをビジネス・プロセスから1単位としてアサートできる場合があります。また、ビジネス・プロセスでファクトを増分アサートし、最終的にルール・エンジンによる推論を参照する場合もあります。したがって、サービスではステートレスな相互作用とステートフルな相互作用の両方をサポートする必要があります。
このような多様なビジネス・ルール・サービス・コンポーネントを作成できます。
詳細は、『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』を参照してください。
Oracle JDeveloperとRules Designerを使用すると、これらのツールにより必須のメタデータおよびWSDL操作すべてが自動的に生成されます。デシジョン・コンポーネントは、次の方法でSOAコンポジット・アプリケーションに統合できます。
SOAコンポジット・エディタで、デシジョン・コンポーネントをスタンドアロン・コンポーネントとして作成します。このシナリオでは、デシジョン・サービスはコンポジット・レベルで公開されるため、任意のWebサービス・クライアントから起動できます。
詳細は、『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』のOracle Business Rulesの開始に関する項を参照してください。
SOAコンポジット・エディタでデシジョン・コンポーネントを作成し、BPELプロセスに関連付けます。このシナリオでは、デシジョン・サービスはコンポジット・レベルで公開されません。ただし、BPEL、Oracle Mediator、Oracle Human Workflowなど、コンポジット内の他の任意のコンポーネントに接続できます。
詳細は、『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』のOracle Business Rulesの開始に関する項を参照してください。
この統合には、次のメリットがあります。
動的な処理: 適切なルーティング、プロセス内のポリシーの検証および制約チェックの提供
非定型ヒューマン・タスクとの統合: ポリシーベースのタスクの割当て、各種エスカレーション・ポリシーおよびタスクのロード・バランシングを提供
デシジョン・コンポーネントは、次のファイルで定義されています。
通常、これらのファイルの生成およびメンテナンスにはOracle JDeveloperを使用します。
コンポジット内のすべてのデシジョン・コンポーネントには、1つのビジネス・ルール・メタデータ・ファイルが含まれています。ビジネス・ルール・メタデータ・ファイルにより、コンポーネントのビジネス・ルール・ディクショナリの場所およびデシジョン・コンポーネントによって公開されるデシジョン・サービスに関する情報が提供されます。
1つのデシジョン・コンポーネントは、1つ以上のデシジョン・サービスを公開します。たとえば、CreditRatingデシジョン・コンポーネントは、2つのサービス、CheckEligibilityおよびCalculateCreditRatingを公開します。Oracle Fusion Middleware 11g リリース1(11.1.1)では、デシジョン・サービス・メタデータにはWebサービスとして公開されるデシジョン関数名が含まれます。Oracle SOA Suiteの以前のリリースから移行されたプロジェクトに対し、デシジョン・サービス・メタデータは、10.1.3.xで使用された相互作用のパターンによっては、より多くの情報を保持していることが一般的です。
ビジネス・ルール・メタデータ・ファイル(business_rule_name.decs)では、ビジネス・ルールとデザインタイムおよびバックエンドOracle Rules Engineとの相互作用に関与するコンポーネント間の規定が定義されます。
このファイルは、SOAコンポジット・アプリケーションの場合、Oracle JDeveloperの「アプリケーション・ナビゲータ」の「SOAコンテンツ」領域にあります。表11-1に、デシジョン・サービスの.decsファイルの最上位レベル要素を示します。
表11-1 デシジョン・メタデータ・ファイル(.decs)の最上位レベル要素
| 要素 | 説明 |
|---|---|
|
|
<ruleEngineProvider name="OracleRulesSDK" provider="Oracle_11.0.0.0.0">
<repository type="SCA-Archive">
<path>AutoLoanComposite/oracle/rules/AutoLoanRules.rules</path>
</repository>
</ruleEngineProvider>
デシジョン・コンポーネントの場合、リポジトリ・タイプは
|
|
|
デシジョン・サービスは、ビジネス・ルールのWebサービス(SOA)イネーブラです。Webサービスという意味ではサービスであるため、サービス指向アーキテクチャ(SOA)にビジネス・ルールをもたらします。11g リリース1(11.1.1.7)では、デシジョン・サービスはサービスのメタデータおよびWSDL規定で構成されます。
通常、デシジョン・サービスには、次の要素が含まれています。
操作(パターン)とは別に、操作のパラメータ型(ファクト・タイプ)が指定されています(後で実行時に検証されます)。したがって、各デシジョン・サービスでは強い型指定を持つ規定が公開されます。 |
SCAのbusiness_rule_name.componentTypeファイルは、各デシジョン・コンポーネントとともに組み込まれています。このファイルには、ビジネス・ルール・サービス・コンポーネントにより公開されるサービスがリストされます。次の例では、2つのサービスCreditRatingServiceおよびLoanAdvisorServiceが公開されています。
<?xml version="1.0" encoding="UTF-8" ?> <!-- Generated by Oracle SOA Modeler version 1.0 at [5/24/07 9:27 AM]. --> <componentType xmlns="http://xmlns.oracle.com/sca/1.0"> <service name="CreditRatingService"> <interface.wsdl interface="http://xmlns.oracle.com/creditrating/Rating#wsdl.interface(IDecisionSer vice)"/> </service> <service name="LoanAdvisorService"> <interface.wsdl interface="http://xmlns.oracle.com/loanoffer/Advisor#wsdl.interface(IDecisionServi ce)"/> </service> </componentType>
デシジョン・コンポーネントに対してcomposite.xml内にエントリが作成されます。次に例を示します。
<component name="OracleRules1">
<implementation.decision src="OracleRules1.decs"/>
</component>
ビジネス・ルール・サービス・エンジンでは、サービス・エンジンに対するリクエストを処理するためにこの実装タイプからの情報が使用されます。SCAの視点からは、デシジョン・コンポーネントは新しい実装タイプです。
デシジョン・サービスを使用すると、Oracle Business Rulesデシジョン関数をサービスとして公開できます。デシジョン関数は、Java EEアプリケーションやBPELプロセスからルールをコールするためのRL Languageプログラミングを使用せずに、宣言的に構成される関数です。
例11-1に、サービスとして公開されるOracle Business Rulesデシジョン関数のメタデータを定義する、business_rule_name.decsファイルのdecisionServices要素を示します。
例11-1 デシジョン関数実行用のdecisionService
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<decisionServices xmlns="http://xmlns.oracle.com/bpel/rules" name="PurchaseItems">
<ruleEngineProvider name="OracleRulesSDK" provider="Oracle_11.0.0.0.0">
<repository type="SCA-Archive">
<path>PurchasingSampleProject/oracle/rules/com/example/PurchaseItems.rules</path>
</repository>
</ruleEngineProvider>
<decisionService targetNamespace="http://xmlns.oracle.com/PurchaseItems/PurchaseItems_DecisionService_ValidatePurchasesDF"
ruleEngineProviderReference="OracleRulesSDK" name="PurchaseItems_DecisionService_ValidatePurchasesDF">
<catalog>PurchaseItems</catalog>
<pattern name="CallFunctionStateless">
<arguments>
<call>com.example.PurchaseItems.ValidatePurchasesDF</call>
</arguments>
</pattern>
<pattern name="CallFunctionStateful">
<arguments>
<call>com.example.PurchaseItems.ValidatePurchasesDF</call>
</arguments>
</pattern>
</decisionService>
</decisionServices>
この場合、デシジョン関数ValidatePurchasesDF自体は、PurchaseItems.rulesファイルで全体が指定されています。
詳細は、第6章「デシジョン関数の使用」を参照してください。
ステートフルなデシジョン・サービスを提供するには、デシジョン関数を作成し、そのデシジョン関数をステートレスでないように指定します。そのためには、デシジョン関数の「ステートレス」チェック・ボックスの選択を解除します。
デシジョン・コンポーネントとのステートフルな相互作用については、次の詳細に注意してください(図11-2も参照)。
キャッシュからのルール・セッションおよびプールからのルール・セッションは相互排他です。
ルール・セッション・プールは、単純でステートレスな相互作用専用です。
ルール・セッション・キャッシュでは、デシジョン・サービス・リクエスト間でルール・セッションの状態が維持されます。
ビジネス・ルール・サービス・エンジンで実行されるデシジョン・コンポーネントでは、ステートフルな操作とステートレスな操作のいずれかがサポートされます。「ビジネス・ルールの作成」ダイアログの「セッションのリセット」(ステートレス)チェック・ボックスを使用して、これら2つの操作モードを切り替えることができます。
「セッションのリセット」チェック・ボックスを選択すると、ステートレスな操作が指定されます。
「セッションのリセット」(ステートレス)チェック・ボックスが選択されていない場合、基礎となるOracle Business Rulesオブジェクトは、(操作の終了時にルール・セッション・プールに戻されないように)別の場所にあるビジネス・ルール・サービス・エンジンのメモリー内に保持されます。このオプションが必要な場合にのみステートフルな操作を使用してください(ステートフルな操作を使用すると実行時にエラーが発生する場合があり、そのエラーによってサービス・エンジンのメモリーが大量に使用される場合があります)。
「セッションのリセット」(ステートレス)チェック・ボックスが選択されていない場合、デシジョン・コンポーネントがその後使用されると、キャッシュされたRuleSessionオブジェクトはcallFunctionStatefulの起動以降のすべての状態情報とともに再利用され、callFunctionStateless操作の終了後、解放されてルール・セッション・プールに戻されます。
デシジョン・サービスは、サービスの記述のみで構成されます。他のすべてのアーティファクトは、図11-1に示すようにデシジョン・コンポーネント内で共有されます。
ランタイムの中心部分は、ツリー構造で編成されたデシジョン・サービス・キャッシュです。各デシジョン・コンポーネントは、そのキャッシュのサブツリーを(コンポジット識別名(DN)、コンポーネントおよびサービス名に応じて)所有します。この点では、デシジョン・コンポーネントのデシジョン・サービスは次のデータを共有していることになります。
デシジョン・コンポーネントのメタデータ
ファクト・タイプのメタデータ
関数のメタデータ
ルールセットのメタデータ
ルール・セッション・プール
デシジョン・コンポーネントごとにルール・セッション・プールが1つ作成されます。
プール内のルール・セッションは、データ・モデルのOracle RLおよび実行済のルールセットのOracle RLを使用して事前に初期化されます。
必要に応じて新規のルール・セッションが作成されます。
ルール・セッションは再利用でき、その回数は構成可能です。
ルール・セッション・プールの初期サイズは構成可能です。
ステートフルなルール・セッション・キャッシュ
ステートフルなルール・セッションの場合は、特別なキャッシュがメンテナンスされます。
詳細は、第11.2.3項「デシジョン・コンポーネントとのステートフルな相互作用の使用」を参照してください。
デプロイメント・アーティファクト
デシジョン・コンポーネントのデプロイメントにより、最終的にJAXBファクト・タイプのクラスを生成できます。これらのクラスはコンポジット間で共有できます。
図11-2に、デシジョン・サービス・リクエスト中の、ステートレスなルール・セッションおよびステートフルなルール・セッションとルール・セッション・プールの相互作用、およびステートフルなルール・セッションとステートフルなルール・セッション・キャッシュの相互作用を示します。
図11-2 デシジョン・サービス・リクエストに対するステートレスおよびステートフルなルール・セッションの使用方法
