4 ADFビジネス・コンポーネント

この章では、ビジネス・サービスの構築のための主要機能など、ADFビジネス・コンポーネントの概要について説明します。ここで説明する機能には、エンティティ・オブジェクト、ビュー・オブジェクト、アプリケーション・モジュールなどがあります。

この章の内容は次のとおりです。

4.1 ADFビジネス・コンポーネントについて

ADFビジネス・コンポーネントは、開発者の最小限のコード記述のみで再使用可能なデータベース対応のビジネス・サービスを作成するためのテクノロジです。開発者はウィザードとビジュアル・エディタを使用して、Javaコードを記述せずにADFビジネス・コンポーネント・サービスを作成できます。さらに高度の機能を作成するために、コアなADFビジネス・コンポーネント・クラスを拡張することも可能です。ADFビジネス・コンポーネント・サービスは、アプリケーションのビュー・レイヤーを使用してADFモデルを介して公開されます。

図4-1は、ADFビジネス・コンポーネントがADFテクノロジ・スタックにどのように適合しているかを示しています。ADFビジネス・コンポーネントの機能は直接ADFモデルと統合される点に注意してください。

図4-1 ビジネス・コンポーネントでのADFアーキテクチャ

さらに、Fusion Webアプリケーション、サービス・コンポーネント・アーキテクチャ(SCA)に従ったコンポジット・アプリケーション、およびWebサービスのコールを介したその他のアプリケーションで使用できるサービスとして、ADFビジネス・コンポーネントを使用してアプリケーションを作成し公開できます。

4.2 ADFビジネス・コンポーネントのコアな利点

ADFビジネス・コンポーネントは、ビジネス・サービスの開発者に対して次の利点を提供します。

データベース・アクセスの管理。接続、データの取得、レコードのロック、レコードの挿入および更新などが含まれます。
特定のタイプのエンド・ユーザーに合せたデータ・モデル作成機能。必要なデータのみが公開されます。
データベースで定義されたもの以外のデータ・モデル関係の追加作成。
必須フィールド、主キーの一意性、データの精度と規模および外部キー参照を強化する宣言的ルールを使用するための機能。
マルチレベルでの検証サポートが備わった、プログラムまたは宣言による、簡単なビジネス・ルールと高度なビジネス・ルール両方の取得および実行。
コードなしのエンド・ユーザーのQuery-by-Exampleのデータ・フィルタリングの実装。
他のFusion Webアプリケーションと統合し、SOAコンポジット・アプリケーションで使用できるサービスとして、コンポーネントを公開する機能。
ビジネス・プロセスを起動し、外部システムの同期をトリガーするためのビジネス・イベントを呼び出す機能。
アプリケーション・フェイルオーバーとユーザー・セッションの処理をクラスタ化された高可用性サーバー環境における複数のノードで有効化する、アプリケーションの状態管理に関する組込み機能。
静的データとアプリケーション・モジュール・プーリングを処理する共有アプリケーション・モジュールなど、パフォーマンスの最適化を対象とする機能。
手動で編集することもできるコンポーネントのXML定義を生成する、JDeveloperのウィザードとビジュアル・エディタ。

4.3 ADFビジネス・コンポーネントの主要概念

ADFビジネス・コンポーネントは、ADFモデルを直接組み込むJavaベースのビジネス・サービスの実装です。この項では、ビジネス・サービスのロールおよびADFビジネス・コンポーネントでビジネス・サービスを実装する方法の概要について説明します。

4.3.1 ビジネス・サービスの実装

ビジネス・サービスは、MVCアプリケーションとデータ・ソース(通常はデータベース)を仲介する舞台裏のコンポーネントです。通常、ビジネス・サービスでは次のタスクが実行されます。

アプリケーションの残りの部分でリクエストされたデータの取得
アプリケーションの残りの部分で使用可能なJavaオブジェクトとしての、このデータの表現(オブジェクト・リレーショナルな["O/R"]マッピング)
アプリケーションの残りの部分により加えられた変更の永続化
検証ロジック、計算属性、デフォルト設定ロジックなど、ビジネス・ルールの実装
リクエストに応じてデータ上の大規模なバッチ操作を実行できるサービスの提供

ビジネス・サービスは、アプリケーションの永続性とビジネス・ロジックを、アプリケーションのUIと制御フローを管理するロジックから分割します。永続性とビジネス・ロジックを別にすることで、それらを複数のMVCアプリケーションで再利用できるようになります。

4.3.2 標準JavaおよびXMLベース

ADFビジネス・コンポーネントはJavaに実装されたフレームワークです。ベース・フレームワーク・クラスには、一般的なメタデータ主導の機能が用意されています。XMLファイルには、各コンポーネントの実行時の動作を構成するために定義するメタデータが保存されています。また、ベース・フレームワーク機能をニーズに合せて拡張することも可能です。

図4-2は、JDeveloperの「アプリケーション」ウィンドウおよびADFビジネス・コンポーネント・サービスを構成するファイルの表示方法を示しています。たとえば、DeptVOコンポーネントは基礎となるフレームワーク・クラスに完全に依存する単一のXMLファイルで定義されます。また、CustomerVO定義はメタデータ、および基礎となるフレームワーク・クラスを拡張する3つのJavaクラスが用意されたXML定義ファイルで構成されています。

図4-2 ADFビジネス・コンポーネントのXMLおよびJavaオブジェクト

図4-3は、ADFビジネス・コンポーネント・ビュー・オブジェクト定義ファイルのソース・エディタを示しています。

図4-3 ADFビジネス・コンポーネント定義ファイルのソース・ビュー

JDeveloperには、ADFビジネス・コンポーネント定義ファイルのビジュアル概要エディタも用意されています。図4-4は、図4-3に示された同じビュー・オブジェクトの定義ファイルに対する概要エディタを示しています。

図4-4 ADFビジネス・コンポーネント定義ファイルの概要エディタ

4.3.3 アプリケーション・サーバーとデータベースの独立性

ADFビジネス・コンポーネント・サービスはプレーンJavaクラスとXMLファイルを使用して実装されているため、ADFビジネス・コンポーネントを使用して構築されたアプリケーションとサービスは、Java EE準拠のアプリケーション・サーバーなど、どのJava対応アプリケーション・サーバーでも実行できます。これらのアプリケーションとサービスは、Java EEサーバー・コンテナの内外両方で稼働できます。

ADFビジネス・コンポーネント・コンポーネントは、Oracleデータベースおよび非Oracleデータベースのいずれとも一緒に使用できます。Oracleデータベースとともに使用できるよう、多数の最適化がADFビジネス・コンポーネントに組み込まれています。

4.3.4 Java EEデザイン・パターンのサポート

ADFビジネス・コンポーネントはJava EEデザイン・パターンを実装しています。実際のエンタープライズJava EEアプリケーションを作成する際には、通常、そのデザイン・パターンを理解、実装およびデバッグする必要があります。これらのパターンは、アプリケーション・レイヤーの明確な分割、効率的なデータベースへのアクセス、アプリケーション・スケーラビリティなどの問題を解決します。

Java EE仕様のこれらのデザイン・パターンの名前をADFビジネス・コンポーネントの対応する名前と相互参照するには、『Oracle Application Development FrameworkによるFusion Webアプリケーションの開発』の「ADFビジネス・コンポーネントJava EEデザイン・パターン・カタログ」を参照してください。

4.3.5 実装クラスの宣言的メタデータ

ADFビジネス・コンポーネント・オブジェクトは、宣言的設定により制御する組込み実行時機能が用意された一連のJavaクラスに基づいています。XMLコンポーネント定義ファイルを使用して、データベース表、データ・アクセス・メソッドおよび検証ルールにオブジェクト/関係のマッピングなどのメタデータを指定します。実行時に、サービスのインスタンスを作成するために、このメタデータが実装クラスに追加されます。一般的なユースケースの場合、開発者はサービスを実装する際にJavaコードを記述する必要がありません。

4.3.6 オプションのカスタムJavaコード

カスタムJavaコードをコンポーネントの定義に追加して、コンポーネントの動作をさらに構成することが可能です。コンポーネントの動作を拡張するなど、コンポーネントのカスタム・コードを記述する必要がある場合、該当するコンポーネントに対するオプションのカスタムJavaクラスを有効にできます。

4.3.7 サービスをSOAアプリケーションに公開する機能

ADFビジネス・コンポーネント・サービスを開発したら、それをサービス指向型アーキテクチャ(SOA)に基づいたアプリケーションで使用できる、外部サービスとして公開できます。詳細は、「サービス対応のアプリケーション・モジュール」を参照してください。

4.3.8 アプリケーション状態管理

ADFビジネス・コンポーネントにはアプリケーション・モジュールの状態管理機能が備わっており、ユーザー・セッションの状態を保存できるため、リカバリやフェイルオーバーのシナリオを簡単にします。

アプリケーション・モジュール状態管理の詳細は、「アプリケーション・モジュール状態管理」を参照してください。セーブポイントの詳細は、「セーブポイント」を参照してください。

4.4 ADFビジネス・コンポーネントの主要コンポーネント

ADFビジネス・コンポーネント・アーキテクチャは、次のキー・コンポーネントにより構成されます。

エンティティ・オブジェクト。データベース内の表など、データ・ソース内の個々のオブジェクトをカプセル化し、そのデータと連動するビジネス・ロジックを追加します。
エンティティ・アソシエーション。個々のエンティティ・オブジェクト間の関係を定義します。
ビュー・オブジェクト。これにより、ユーザーインタフェース内のADFモデルのバインドを介して使用できる形式でデータにアクセスできます。データを更新できるビュー・オブジェクトは、エンティティ・オブジェクトに基づいています。
ビュー・リンク。ビュー・オブジェクト間のマスター/ディテールの階層を定義します。
アプリケーション・モジュール。エンドユーザーのタスクに関連した作業の論理単位に必要なビュー・オブジェクトをカプセル化します。

4.4.1 エンティティ・オブジェクト

ADFエンティティ・オブジェクトは、アプリケーションで使用される項目について、データ、永続動作、ビジネス・ルールをカプセル化するビジネス・コンポーネントです。たとえば、エンティティ・オブジェクトで次の項目を表すことができます。

ビジネスの論理構造(製品ライン、部門、売上、地域など)の要素
ビジネス文書(請求書、注文変更書、サービス要求など)
物理的な項目(倉庫、従業員、設備など)

エンティティ・オブジェクトはデータソース内のシングル・オブジェクトにマップされます。ほとんどの場合、エンティティ・オブジェクトはデータベース内の表、ビュー、シノニムまたはスナップショットです。たとえば、DEPARTMENTSという名前のデータベース表を表すDepartmentsというエンティティ・オブジェクトを作成するとします。上級プログラマは、他のデータソース(スプレッドシート、XMLファイル、フラット・テキスト・ファイルなど)のオブジェクトに基づいてベース・エンティティ・オブジェクトを作成できます。

図4-5は、エンティティ・オブジェクトがADFビジネス・コンポーネント・アプリケーションの他のオブジェクトにどのように適合しているかを示しています。

図4-5 ADFビジネス・コンポーネント・アーキテクチャ内のエンティティ・オブジェクト

4.4.1.1 エンティティ・オブジェクトの定義ファイル

JDeveloperのウィザードとビジュアル・エディタを使用してエンティティ・オブジェクトを作成および構成すると、JDeveloperではそのエンティティ・オブジェクト(そのO/Rマッピング、検証ルール、UIヒント、その他のメタデータなど)のランタイム動作を定義する宣言的メタデータを含むXMLファイルが作成されます。ランタイムに、このメタデータは汎用フレームワーク・クラスoracle.jbo.server.EntityImplのインスタンスに実装されます。

ADFビジネス・コンポーネント・フレームワーク・クラスを拡張するカスタム・クラスを記述することで、エンティティ・オブジェクトにカスタム機能を追加することも可能です。詳細は、『Oracle Application Development FrameworkによるFusion Webアプリケーションの開発』のエンティティ・オブジェクトのカスタムJavaクラスの生成に関する項を参照してください。

4.4.1.2 エンティティ・オブジェクトを構成する方法

エンティティ・オブジェクトは、ADFモデルのADFビジネス・コンポーネント実装の一部です。そのため、エンティティ・オブジェクトの定義に宣言的メタデータを追加してその動作を構成できます。次に示すのは、エンティティ・オブジェクトのメタデータを設定できる事項の一部です。

UIヒント。ロケールに依存した一貫性のある方法で問合せ情報を自動表示する際にビュー・レイヤーで使用される設定です。
検証ルール。エンティティ・オブジェクトまたは個々の属性の両方のレベルで設定できます。
ビジネス・イベント。ビジネス・プロセスを起動し、外部システムの同期をトリガーする際に使用できます。

4.4.2 エンティティ・アソシエーション

エンティティ・オブジェクトの定義の関係は、2つのエンティティ・オブジェクトの定義間の関係をそれぞれの一連のエンティティ属性に基づいて定義する、エンティティ・アソシエーションによって処理されます。アソシエーションは、データソースのシングル・オブジェクト間の関係にマップされます。ほとんどの場合、アソシエーションはデータベース内の表、ビュー、シノニムおよびスナップショットです。上級プログラマは、アソシエーションを使用して他のデータソース(スプレッドシート、XMLファイル、フラット・テキスト・ファイルなど)内の関係を表現できます。

データソースがデータベースの場合、通常、アソシエーションはそのデータベースにある表と表の間の外部キー関係にマップされます。対応するエンティティ・オブジェクトの間に1対1または1対多のアソシエーションを作成する場合、表と表の間に外部キー制約を設定する必要はありませんが、適切な論理的関係が表の間に必要です。

4.4.3 ビュー・オブジェクト

ADFのビュー・オブジェクトはビジネス・コンポーネントであり、データソースのデータを収集してクライアント用に形成し、クライアントがそのデータをADFビジネス・コンポーネントのキャッシュで変更できるようにします。特に、ビュー・オブジェクト定義を使用して、次の操作に必要な情報を収集できます。

単一の表要素のフォームへの移入
挿入フォームまたは編集フォームの作成および処理
ドロップダウン・リストへの移入に使用する値リストの作成
特定の検索基準を使用した検索フォームの作成

ビュー・オブジェクトの定義を作成してそれをアプリケーション・モジュールのデータ・モデルに追加したら、「データ・コントロール」パネルを使用して、そのビュー・オブジェクトのコレクション、属性および操作に基づいてUIコンポーネントを作成します。

図4-6 ADFビジネス・コンポーネント・アーキテクチャ内のビュー・オブジェクト

ビュー・オブジェクトの定義には、データソースからデータを取得するメカニズムが必要です。通常、データ・ソースはデータベースで、メカニズムはSQL問合せです。ADFビジネス・コンポーネントは、自動的にJDBCを使用して問合せをデータベースに渡し、結果を受け取ります。ビュー・オブジェクトの定義でSQL問合せが使用される場合、問合せ列がそのビュー・オブジェクト定義のビュー属性にマップされます。これらの属性の定義は、データ型、精度、スケールの仕様など、それらの列のプロパティを反映しています。ビュー・オブジェクトの定義を別のデータ・ソースに使用すると、ビュー・オブジェクトの属性が、プログラマの定義に応じて、それらのデータ・ソースからデータの「列」にマップされます。

ビュー・オブジェクトを操作する場合は、通常、単一の結果行セットのみを1回で操作します。このユースケースを単純化するために、ビュー・オブジェクトにはデフォルトのRowSetが含まれ、また、それにはデフォルトのRowSetIteratorが含まれています。デフォルトのRowSetIteratorにより、デフォルト行セットに自動的に適用されることを認識しながら、ViewObjectコンポーネント自体でデータ取得メソッドのすべてを直接コールできるようになります。

さらに、ビュー・オブジェクトにビュー基準を宣言的に定義できます。ビュー基準では、結果をフィルタリングするために、ターゲット・ビュー・オブジェクトのWHERE句を拡張する問合せ条件を指定します。次に、それらのビュー基準を使用して、Query-by-Example検索フォームを作成したり、実行時に行セットまたは値リスト(LOV)をフィルタリングしたり、または単一のビュー・オブジェクトの定義に基づいて可変ビュー・インスタンスを作成したりできます。

4.4.3.1 ビュー・オブジェクトのタイプ

ビュー・オブジェクトには次の2つの主要なタイプがあります。

エンティティベースのビュー・オブジェクト。1つまたは複数のエンティティ・オブジェクトからデータにアクセスし、ユーザーのアクションに基づいてデータ・ソースを更新するためにそれらのエンティティ・オブジェクトと連携します。
読取り専用ビュー・オブジェクト。データへ直接アクセスできます。読取り専用ビュー・オブジェクトには中間オブジェクトが不要なため、エンティティベースのビュー・オブジェクトより素早くデータにアクセスします。使用するユースケースでデータを変更せずにアクセスする必要がある場合、読取り専用ビュー・オブジェクトを作成します。同じ表に対して、読取り専用ビュー・オブジェクトとエンティティベースのビュー・オブジェクトがある場合があります。

さらに、次のようなデータ・ソースでビュー・オブジェクトを作成することもできます。

データベースのダイレクトSQL問合せ
プログラム関連のソース
CSVファイルからの静的データ

多相ビュー・オブジェクトを作成することも可能です。それには、一般的な継承階層を備えた複数の行セット・タイプが単一のビュー・オブジェクトで表されています。

4.4.3.2 ビュー・オブジェクトの定義ファイル

エンティティ・オブジェクトとの連動と同様、JDeveloperのウィザードとビジュアル・エディタを使用してビュー・オブジェクトの定義を作成および構成すると、JDeveloperではそのビュー・オブジェクトのランタイム動作とUIで使用される機能(UIヒント、検証ルールなど)を定義する宣言的メタデータを含むXMLファイルが作成されます。このメタデータは、実行時に汎用フレームワーク・クラスoracle.jbo.server.ViewObjectImplのインスタンスに実装されます。

ADFビジネス・コンポーネント・フレームワーク・クラスを拡張するカスタム・クラスを記述することで、ビュー・オブジェクトにカスタム機能を追加することも可能です。詳細は、『Oracle Application Development FrameworkによるFusion Webアプリケーションの開発』の「ビュー・オブジェクトのプログラムによる操作」を参照してください。

4.4.3.3 ビュー・オブジェクトを構成する方法

ビュー・オブジェクトは、ADFモデルのADFビジネス・コンポーネント実装の一部です。そのため、ビュー・オブジェクトの定義に宣言的メタデータを追加してその動作を構成できます。

同じ宣言的メタデータを、エンティティ・オブジェクトに定義したように、ビュー・オブジェクトにも定義できます(ビュー・オブジェクトではビジネス・イベントを呼び出せないことを除いて)。さらに、次のような他のタイプのメタデータをビュー・オブジェクト用に設定できます。

ビュー基準。さらに改良した問合せとして機能し、「データ・コントロール」パネルで名前付き問合せとして表示され、それを使用して検索フォームを宣言的に作成できます。
リストUIヒント。値のリストをユーザー・インタフェースで表す方法を示すために使用できます。
UIカテゴリ。属性のタイトル付きグループを動的な形式で表すために使用できます。
ビュー・アクセッサ。リスト・ベースの属性検証または値リストのいずれかに関係するビュー・インスタンス属性のデータ・ソースを提供するために使用できます。
行検索。非キー属性の値によってビュー・インスタンス行を照合して、プログラムまたはADF Webサービスのいずれかで行更新を開始するために使用できます。

4.4.4 ビュー・リンク

ビュー・オブジェクト間の関係は、2つのビュー・オブジェクト間の関係をそれぞれの一連のエンティティ属性に基づいて定義する、ビュー・リンクによって処理されます。エンティティ・アソシエーションのように、外部キーに基づく単純な1対多関係から複雑な多対多関係まで、様々な関係を作成できます。

また、ビュー・オブジェクトの個々のインスタンスはビュー・リンクの個々のインスタンスによって関連付けることができます。これにより、問合せ結果セットの間にマスター/ディテールの関係が作成されます。たとえば、部署の情報と従業員の情報に対する問合せを表すビュー・オブジェクトの定義と、部署およびその従業員間の関係を表すビュー・オブジェクト間にビュー・リンクがあるとします。前者のビュー・オブジェクトの定義のインスタンスallDepartmentsが、ビュー・リンクのインスタンスにより、後者のインスタンスemployeesInDepartmentに関連付けられている場合、それらのインスタンスは同期化されます。allDepartmentsの特定の行が選択されていると、employeesInDepartmentは必ずその行の詳細のみを表示します。

4.4.5 アプリケーション・モジュール

Oracle ADFアプリケーション・モジュールは、ADFモデルのデータ・コントロールのADFビジネス・コンポーネント実装です。アプリケーション・モジュールは、特定のアプリケーション・タスクを表しています。アプリケーション・モジュールの定義は、タスクに必要なビュー・オブジェクト・インスタンスおよびビュー・リンク・インスタンスを集約することによって、そのタスクにデータ・モデルを提供します。また、クライアントのタスクの実行に役立つサービスも提供します。たとえば、アプリケーション・モジュールは次のようなタスクを表し、支援できます。

顧客情報の更新
新規注文の作成
昇給の処理

図4-7は、アプリケーション・モジュールが他のビジネス・コンポーネントと連携する様子を示しています。

図4-7 ADFビジネス・コンポーネント・アーキテクチャ内のアプリケーション・モジュール

さらに、アプリケーション・モジュールにはプーリング機能と状態管理機能が備わっており、アプリケーションを容易に拡張可能にし、十分に機能できるようにし、フェイルオーバーの処理を簡単にします。

4.4.5.1 アプリケーション・モジュールのタイプ

アプリケーション・モジュールの定義は、次の方法で使用できます。

サービス・オブジェクトとして使用。この場合、MVCアプリケーションの各インスタンスはアプリケーション・モジュールの1つのインスタンスへアクセスできます。これらのルートレベルのアプリケーション・モジュール・インスタンスは、ADFビジネス・コンポーネントのトランザクション・オブジェクトを制御し、トランザクション・オブジェクトではエンティティ・キャッシュとビュー・キャッシュが制御されます。
再使用可能なネスト用のオブジェクトとして使用。この場合、データ・モデルを作成し、その上にサービス・メソッドを作成してから、そのインスタンスの1つを別のアプリケーション・モジュールの定義にネストできます。それらのアプリケーション・モジュールの定義は、同様に、ネストされたモジュールのメソッドおよびデータ・モデルにアクセスできます。ネストされたアプリケーション・モジュールは、ルートレベル・アプリケーション・モジュールのトランザクションを共有します。
共有されたアプリケーション・モジュールとして使用。ここでは、データはセッションとリクエスト全体で再利用のためにキャッシュされます。共有アプリケーション・モジュールは、それほど頻繁に変更せず、複数のセッションとリクエスト間でアクセスする必要のあるデータがある場合、パフォーマンスの最適化には特に有用です。

4.4.5.2 アプリケーション・モジュールの定義ファイル

アプリケーション・モジュールの定義には、次の1つまたは2つの部分を含めることができます。

XMLファイル。宣言的に開発できるアプリケーションの部分(アプリケーション・モジュールに備わったビュー・オブジェクトとビュー・リンク・インスタンスおよびそれらが関連する方法)を表します。多くのアプリケーション・モジュールでは、XMLファイル単独で十分です。
アプリケーション・モジュール・クラス。これにより、MVCアプリケーションがバッチ・データ処理を起動できるサービス・メソッドなど、カスタム・コードを記述できます。アプリケーション・モジュール・クラスは、クラスoracle.jbo.server.ApplicationModuleImplを拡張します。カスタム・サービス・メソッドを記述する必要がない場合、アプリケーション・モジュール・クラスを生成する必要はありません。ADFでは、oracle.jbo.server.ApplicationModuleImplを直接使用できます。

4.4.5.3 サービス対応アプリケーション・モジュール

サービス対応アプリケーション・モジュールは、サービス・インタフェースを使用して、サービス利用者に通知するADFアプリケーション・モジュールです。サービス利用者が公開されたサービス対応アプリケーション・モジュールを利用するには、次の3つの使用例があります。

Webサービスへのアクセス
Service Component Architecture (SCA)コンポジット・アクセス
別のADFアプリケーション・モジュールによるアクセス

Service Component Architecture (SCA)は、リモートで使用可能なサービスを実装するためのオープンで技術に中立なモデルを提供します。SCAはビジネス機能の観点から定義されており、アプリケーション開発者によるミドルウェア機能のアクセスを容易にします。ADFビジネス・コンポーネントはサービス・インタフェースで公開可能なアプリケーション・モジュールにより、SCA準拠ソリューションをサポートしています。サービス・インタフェースはWSDLとXSDを組み合せた中立言語で、Fusion Webアプリケーション・クライアント用に記述されます。

アプリケーション・モジュールをサービス対応にすると、JDeveloperでは次のファイルで構成されるアーティファクトが生成されます。

サービスを定義するJavaインタフェース
このJavaインタフェースを実装するEJBセッションBean
サービスの操作を説明するWSDLファイル
サービスのデータ構造を定義するXMLスキーマ・ドキュメント(XSD)

SCAは次の2種類のサービスを定義します。

リモート対応可能なサービス。通常はきめが粗く、結合が緩いSOAアーキテクチャでのリモート公開用に設計されます。
ローカル・サービス。通常はきめが細かく、緊密に結合されたアーキテクチャ内で同時にデプロイされる他の実装でのローカルな使用のために設計されます。

ADFビジネス・コンポーネント・サービスは最初のカテゴリに分類され、リモート対応可能サービスとしてのみ使用する必要があります。

リモート・アプリケーション・モジュールによって定義されたADFビジネス・コンポーネント・サービス(データ・アクセスとメソッド・コールを含む)は、その他のあらゆるアプリケーション・モジュールとの相互運用が可能です。これは、同じアプリケーション・モジュールで、ADFデータ・コントロールおよびWebサービス・クライアントを使用している対話型のWebユーザー・インタフェースをサポートできるということを意味しています。

サービス対応アプリケーション・モジュールは、開発チームが公開し、Fusion Webアプリケーションに提供できます。リモート・サービスからアセンブルされたFusion Webアプリケーションも、単一のアプリケーション・サーバー上で稼働するための参加サービスが不要です。

Webアプリケーションは異なる複数のアプリケーション・サーバーで実行されることがありますが、SCAは統合アプリケーションのように見えます。利用するクライアント・プロジェクトはADFサービス・ファクトリ検索メカニズムを使用して、データおよびサービス対応アプリケーション・モジュールによってカプセル化されたあらゆるビジネス・メソッドにアクセスします。実行時は、サービスの起動に使用されるプロトコル(SOAPまたはRMI)に応じて、コール元のクライアントとADF Webサービスが同じトランザクションに参加する場合とそうでない場合があります。RMIプロトコルとJava Transaction API (JTA)マネージド・トランザクションのみで、コール元のクライアントと同じトランザクションでサービスをコールすることができます。デフォルトでは、ADF Webサービスは、RMIプロトコルをサポートするために、同じトランザクションに参加するように構成されます。

サービス・データ・オブジェクト(SDO)コンポーネントとしてアプリケーション・モジュールを有効にする方法の詳細は、『Oracle Application Development FrameworkによるFusion Webアプリケーションの開発』のサービス対応アプリケーション・モジュールの統合に関する項を参照してください。

4.4.5.4 アプリケーション・モジュール・プーリング

アプリケーション・モジュールをそのビジネス・サービスとして利用するアプリケーションを作成すると、そのアプリケーションでは自動アプリケーション・モジュール・プーリング機能を使用できます。この機能は、構成可能な一連のアプリケーション・モジュールのインスタンスを管理し、アプリケーションの変更に応じてエンドユーザーの負荷を増加したり軽減したりします。アプリケーション・ユーザー・インタフェースとのエンド・ユーザーの対話に特有の思考時間の性質により、プール内のアプリケーション・モジュール・インスタンスの数は、システムを使用しているアクティブ・ユーザーの合計数より少なくなる場合があります。特定のエンドユーザーがアプリケーションの複数のページにアクセスして論理タスクを実行すると、プール内のアプリケーション・モジュールのインスタンスが各リクエストの存続時間中にプールから自動的に取得されます。リクエストの最後に、インスタンスはプールに自動的に戻され、別のユーザー・セッションで使用可能になります。

アプリケーションのパフォーマンスを最適化するために、初期および最大プール・サイズや、アプリケーション・モジュールのインスタンスが非アクティブな時間がどれだけ経過したら、プールからそのインスタンスを削除できるかなど、アプリケーション・モジュールのプール・プロパティを調整できます。

4.4.5.5 アプリケーション状態管理

アプリケーション・モジュール・コンポーネントを使用して、完全にステートレスなアプリケーションを実装したり、複数のブラウザ・ページが関係する作業単位をサポートしたりできます。アプリケーション・モジュールは、保留中トランザクション状態のXMLドキュメントへの受動化(保存)をサポートし、XMLドキュメントは、データベースの単一の汎用的な表に、一意の受動化スナップショットIDをキーとして格納されます。また、これらの保存されているXMLスナップショットの1つから保留中トランザクション状態を能動化する逆の操作もサポートします。この受動化と能動化は、必要に応じて、アプリケーション・モジュール・プールにより自動的に行われます。アクティブ化は、サーバーのフェイルオーバーによりトリガーできます。または、単にユーザー・セッションがアプリケーション・モジュール・プールの複数のインスタンスに渡っているため、セッションが完了する前にトリガーできます。

4.5 ADFビジネス・コンポーネント・プロセス・フローの概要

ADFビジネス・コンポーネントに基づくビジネス・サービス・レイヤーの作成は、次の一般的な手順で構成されます。

JDeveloperで、そのアプリケーション用のアプリケーション・ワークスペースを作成します。
ベース・フレームワーク・クラスを拡張するカスタム・クラスを作成し、作成したビジネス・コンポーネントがそれらのカスタム・クラスをベースとするようにモデル・プロジェクトを構成します。これらのクラスには、ベース・フレームワークの動作を後で変更し、それらの変更内容をアプリケーション内で作成済のすべてのビジネス・コンポーネントに適用するためのメカニズムが用意されています。
JDeveloperの「新規ギャラリ」でウィザードを使用して、次のオブジェクトの組合せを作成します。
- エンティティ・オブジェクト
- エンティティ・アソシエーション
- エンティティ・オブジェクトに基づいたビュー・オブジェクト
- オプションで、データベースに対する直接の問合せに基づいたビュー・オブジェクト
- マスター/ディテール関係を確立するビュー・オブジェクト間のビュー・リンク
- アプリケーション・モジュールを作成し、データ・モデルを確立するためにアプリケーション・モジュール内に適切なビュー・オブジェクトとビュー・リンクを追加します。
オプションで、JDeveloperのビジュアル・エディタを使用して、エンティティ・オブジェクトとビュー・オブジェクトのビジネス・ルールを宣言的に指定します。
ADFモデル・テスターを使用して、データ・モデルのビジネス・ロジックをテストします。
パフォーマンスのためにアプリケーション・モジュールを調整します。
SOAアプリケーションに関連している場合、外部アプリケーションで利用できるようにサービスを公開します。
「データ・コントロール」パネルと様々なバインディング・エディタを使用して、データバインドされたコンポーネントをビュー・レイヤーに作成します。

4.6 ADFビジネス・コンポーネントの詳細について

次のリソースには、アプリケーションでのADFビジネス・コンポーネントの使用に関する詳細が記載されています。

ADFビジネス・コンポーネントを使用したビジネス・サービスの作成の詳細は、『Oracle Application Development FrameworkによるFusion Webアプリケーションの開発』.の「ビジネス・サービスの構築」を参照してください。
ADFモデルのデータ・バインディングを使用したユーザー・インタフェース作成の詳細は、『Oracle Application Development FrameworkによるFusion Webアプリケーションの開発』の「データバインドされたWebユーザー・インタフェースの作成」を参照してください。
ADFビジネス・コンポーネントに関連したJavadocドキュメントは、Oracle ADFモデルのJava APIリファレンスのoracle.jboパッケージを参照してください。