ビジネス・サービスは、MVCアプリケーションとデータソースの間を媒介する裏方のコンポーネントです。ビジネス・サービスの役割は次のとおりです。
アプリケーションの他の部分からリクエストされたデータの取得
取得データの、他のアプリケーション部分が使用可能なJavaオブジェクトとしての表示(オブジェクトとリレーショナル・データベースとのO/Rマッピング)
アプリケーションの他の部分による変更の永続化
検証ロジック、計算属性およびデフォルト化ロジックといったビジネス・ルールの実装
リクエストに応じてデータへの大規模なバッチ操作を実行可能なサービスの提供
ビジネス・サービスは、アプリケーションの永続性とビジネス・ロジックを、アプリケーションのUIおよび制御フローを管理するロジックから切り離します。永続性とビジネス・ロジックが分離されるため、複数のMVCアプリケーションでそれらを使用できます。
この章では、Oracle Application Development Frameworkですぐに使用できるビジネス・サービス・テクノロジの概要を説明します。
JDeveloperでは、複数のテクノロジを使用してビジネス・サービスを開発するためのツールが用意されています。通常ビジネス・サービス・テクノロジは、アプリケーションの他の部分の設計に関係なく選択できます。後述するOracle ADFモデルはすべてのビジネス・サービスに共通なインタフェースを提供し、ビューおよびコントローラからは、ほとんど互換的にビジネス・サービスにアクセスできます。以降に記載するすべてのテクノロジは、そのままADFモデルで使用できます。また、独自のデータ・コントロール・クラスを作成すれば、この他のビジネス・サービス・テクノロジも使用できます。
ADF Business Componentsは、あらゆる機能を備えた、XMLベースのビジネス・サービス作成用フレームワークです。ADF Business Componentsは、Oracle9i以前のJDeveloperで配布されていたBusiness Components for Java(BC4J)が発展したものです。ADF Business Componentsのランタイム・ライブラリはほとんどのビジネス・サービス機能を扱い、これらは宣言的(JDeveloperのRADツールでXMLファイルを変更)またはプログラム的(ライブラリ・クラスを拡張)にカスタマイズ可能です。Oracle ADF Business Componentsの機能は次のとおりです。
独自のライブラリ・クラスのインスタンスに対し、O/Rマッピングと永続性を自動的に処理します。
SQLを使用してデータ取得用の複雑なリクエストを作成できます。
コミット時ロックまたは即時ロックを含むトランザクション管理を自動的に処理します。
複雑なビジネス・ロジックを実装するためのフレームワークを提供します。
多数のJ2EEデザイン・パターンを自動的に実装します。
強力なキャッシュおよびデータの非アクティブ化システムにより、アプリケーションのパフォーマンスとスケーラビリティを向上させます。
これらの機能はどれも自由にカスタマイズできます。たとえば、ADF Business ComponentsによるO/Rマッピングの処理方法を使用しない場合はオーバーライドできます。
Enterprise JavaBeansは、フレームワークなしでビジネス・サービスを作成する場合に使用します。EJBの実行はEJBコンテナ(J2EE準拠のアプリケーション・サーバーの一部)に依存しますが、EJB Beanの実行には、Oracle専用のランタイム・ライブラリも他のOracle専用テクノロジも必要ありません。
Enterprise JavaBeansの機能は次のとおりです。
一般的には、O/Rマッピングと永続性の処理はアプリケーション・サーバーで行われます(コンテナ管理の永続性: CMP)が、経験豊富なEJB開発者であれば、アプリケーション・サーバーをオーバーライドし、独自に永続性ロジックをコーディングできます(Bean管理の永続性: BMP)。
データに対するリクエストは、Java APIまたはEJB QLと呼ばれるEJB専用の問合せ言語を使用して作成する必要があります。
一般的には、トランザクション・ロジックの処理はアプリケーション・サーバーで行われます(コンテナ管理のトランザクション: CMT)が、経験豊富なEJB開発者であれば、アプリケーション・サーバーをオーバーライドし、独自にトランザクション・ロジックをコーディングできます(Bean管理のトランザクション: BMT)。
独自のビジネス・ロジックを実装する必要があります。
必要な場合、J2EEデザイン・パターンを実装する必要があります。
アプリケーション・サーバーのJavaオブジェクト・キャッシュ機能を利用できます。
OracleAS TopLinkは、Javaオブジェクトとリレーショナル・データベース間の複雑なマッピングを提供するためのテクノロジです。TopLink POJOでは、一般のJavaBeansをJavaオブジェクトとして使用します。ADF BCのユーザーと異なり、TopLink POJOのユーザーはフレームワークを拡張しません。かわりに独自のオブジェクト・モデルを作成し、TopLinkランタイムによってデータベースと統合します。
TopLink POJOの機能は次のとおりです。
任意のJavaオブジェクトに対し、O/Rマッピングと永続性ロジックを自動的に処理します。
SQL、EJBQLまたはTopLink独自の式言語を使用してデータ取得用の複雑なリクエストを作成できます。
トランザクションを自動的に管理します。
独自のビジネス・ロジックを実装する必要があります。
必要な場合、J2EEデザイン・パターンを実装する必要があります。
強力なキャッシュおよびデータの非アクティブ化システムにより、アプリケーションのパフォーマンスとスケーラビリティを向上させます。
ADF Business Components同様、TopLinkのマッピング・テクノロジも自由にカスタマイズ可能です。
TopLinkマッピングは、EJBのEntity Beanにコンテナ管理の永続性を提供する場合にも使用できます。その場合、アプリケーション・サーバーのCMP動作がオーバーライドされます。
Enterprise JavaBeansとTopLink CMPの機能は次のとおりです。
TopLinkを使用して複雑なO/Rマッピングおよび永続性を処理します。
SQL、EJBQLまたはTopLink独自の式言語を使用してデータ取得用の複雑なリクエストを作成できます。
トランザクションを自動的に管理します。
独自のビジネス・ロジックを実装する必要があります。
必要な場合、J2EEデザイン・パターンを実装する必要があります。
アプリケーション・サーバーのJavaオブジェクト・キャッシュ機能を利用できます。
Webサービスは特別なケースです。Webサービスは、ビジネス・サービスを実装するテクノロジではなく、XMLベースの標準を使用して、プラットフォーム、言語またはデータ形式に関係なくWeb内でアプリケーション間の対話を可能にします。MVCアプリケーションでは、Web上の任意の場所にデプロイされているあらゆる形式のビジネス・サービスに対し、Webサービスをラッパーとして使用できます。
たとえば、WebサービスはEnterprise JavaBeans、ADF Business Components、データベース内のストアド・プロシージャ、またはJavaをはじめとする言語で記述されたその他のビジネス・サービスをラップできます。MVCアプリケーションは、Web上で送信されたXMLメッセージを使用してサービスのAPIにアクセスできます。
このため、Webサービス自体はO/Rマッピング、永続性、データ検証またはキャッシュを処理せず、基盤となっているクラスが処理します。
Oracle ADFでは、JavaBeans準拠のあらゆるJavaオブジェクトをアプリケーションのビジネス・サービスとして使用できます。この方法を選択した場合、データ取得、永続性および操作用に独自のフレームワークを実装する必要があります。これには通常次の作業が含まれます。
JDBCを使用してデータベースからデータを取得します。
独自のO/Rマッピング・フレームワークを実装します。
JDBCを使用してデータベースへデータを永続化します。
JDBCを使用してトランザクション管理を手動でコーディングします。
使用するクラスのgetterおよびsetterに独自のビジネス・ロジックを追加します。
独自のキャッシュ・メカニズムを作成するか、またはスケーラビリティを低下させます。
ほとんどのユーザーにとって、このオプションはお薦めできません。本来、独自の複雑なビジネス・サービス用フレームワークをすでに作成しているユーザーを対象としたものです。
どのビジネス・サービス・テクノロジがベストかという質問の答えは1つではありません。ビジネス・サービス・テクノロジの選択は、それぞれのニーズ、背景および優先順位に左右されます。
注意: Webサービスは、以降の説明の対象として含まれません。Webサービスには、MVCアプリケーションとそのビジネス・サービスをごくゆるやかに結び付けるという特定の目的があります。このような結びつきが必要な場合にはWebサービスが唯一の選択肢ですが、それ以外の場合には適していません。 |
OracleAS TopLink POJOは、任意のJavaオブジェクトに対し、O/Rマッピングとキャッシュを提供できます。このため、Javaオブジェクトのフレームワークを使用している、または作成しようとしている開発者および企業の場合、一般的にOracleAS TopLinkが最善の選択肢です。ビジネス・オブジェクトの表現、ビジネス・ロジックの実装、およびクライアント向けデータの処理と集計に対し、独自のシステムまたは要件がある場合には、TopLink POJOが最善の選択と考えられます。EJBではコンポーネントがEJB仕様に一致している必要があり、ADF BCコンポーネント・クラスはADF BCフレームワーク・クラスを拡張する必要がありますが、TopLinkはあらゆるオブジェクト・モデルを扱い、O/Rマッピング、データの取得とキャッシュ、およびトランザクション機能を提供します。
既存のアプリケーション・インフラストラクチャを1つも使用せずにまったく新しいアプリケーションを作成する場合、Oracle ADF Business Componentsが最も生産的な選択です。ADF Business Componentsは、アプリケーション構築のすべての側面(O/Rマッピング、データの取得とキャッシュ、トランザクション管理およびADFデータ・バインディング・レイヤーとの統合)を扱います。さらに、主要なJ2EEデザイン・パターンを自動的に実装してパフォーマンスとスケーラビリティを向上させ、検証ルールやその他のビジネス・ロジックを作成するためのフレームワークを提供し、エンティティおよびビューを表すためのベース・クラスを含みます。
Oracle ADF Business ComponentsおよびOracleAS TopLinkはどちらも100% J2EE準拠のテクノロジで、J2EEに準拠したあらゆるアプリケーション・サーバー上で稼働します。2つのテクノロジのどちらも、Oracleのデータベースまたはアプリケーション・サーバーを使用する必要はありません。また、アプリケーションのビュー・レイヤーまたはコントローラ・レイヤーに使用できるテクノロジにもいっさい制限はありません。
ただしどちらのテクノロジも、アプリケーション・サーバー上でいくつかのOracleランタイム・クラスを使用します。ADF Business Componentsを使用した場合、ビジネス・サービスによってADF Business Componentsベース・クラスが拡張されます。OracleAS TopLinkを使用した場合、ビジネス・サービスはO/Rマッピングとキャッシュの提供をTopLinkランタイムに依存します。
実行時にいっさいのOracleクラスを使用できない条件がある場合には、他のビジネス・サービス・テクノロジ(アプリケーション・サーバーによるCMPを伴うEJB、または完全に手動でコーディングされたJavaBeansベースのビジネス・サービスのどちらか)を選択してください。
すべてのビジネス・サービスには、次の3つの主要タスクを処理する手段が必要です。
データの表示
クライアントが使用するためのデータの取得と処理
クライアントへのデータおよび特定サービスの提示
それぞれのタスクは、それぞれに対応するコンポーネント(永続的ビジネス・オブジェクト、データ・アクセス・オブジェクト、サービス・オブジェクト)の別々のレイヤーによって達成されます。
注意: コンポーネントおよびオブジェクトという単語は、ここではプログラム的な意味ではなく論理的な意味で使用されています。永続的ビジネス・オブジェクト、データ・アクセス・オブジェクトおよびサービス・オブジェクトにJavaオブジェクトを使用するビジネス・サービス・テクノロジもあれば、メソッド、問合せまたはその他の論理的構造を使用するビジネス・サービス・テクノロジもあります。 |
一般にビジネス・サービスには、データの最も論理的な表現に基づく永続的ビジネス・オブジェクトのレイヤーが必要です。適切に設計されたデータソースがすでにある場合、永続的ビジネス・オブジェクトの構造にそのデータソースの構造を反映させてください。これにより、最も論理的な方法(アプリケーションで表示する実際のエンティティのプロパティと要件を指定)でビジネス・ルールを記述できます。
たとえば、顧客、注文および注文品目を扱うアプリケーションの場合、一般に顧客、注文および注文品目を表現する永続的ビジネス・オブジェクトが個別に必要です。これらのオブジェクトに対するビジネス・ルールを記述する場合、顧客、注文および注文品目のプロパティと用件を指定します。
永続的ビジネス・オブジェクトはデータの論理的表現を提供しますが、常にアプリケーションが必要とする状態でデータを提供するとはかぎりません。データ・アクセス・コンポーネントは、特定のアプリケーションのニーズに合せてデータを編成および処理します。
たとえばアプリケーションでは、次のSQL問合せで戻されるようなデータを扱うことがあります。
SELECT * FROM ORDER_ITEMS WHERE PRODUCT_ID = 501;
次のような、さらに複雑な問合せも考えられます。
SELECT CUSTOMERS.CUSTOMER_ID, CUSTOMERS.FIRST_NAME, CUSTOMERS.LAST_NAME, ORDERS.ORDER_ID FROM CUSTOMERS, ORDERS WHERE CUSTOMERS.CUSTOMER_ID=ORDERS.ORDER_ID;
このような情報の取得は、データ・アクセス・コンポーネントで行います。データ・アクセス・コンポーネントの能力は、使用するビジネス・サービス・テクノロジによって異なります。どんなに複雑な問合せでも処理可能なものもあれば、永続的ビジネス・オブジェクトのコレクションのみを取得可能なもの(SELECT *
で始まり、FROM
句に表が1つのみある問合せと同等)もあります。
すべてのビジネス・サービス・テクノロジには、3種類のビジネス・サービス・レイヤーを実装する手段が必要です。
注意: Webサービス、および永続性が手動でコーディングされたJavaオブジェクトは、特別なケースです。Webサービスの場合、Webサービス自体がサービス・オブジェクトを提供しますが、永続的ビジネス・オブジェクトとデータ・アクセス・オブジェクトの実装は、Webサービスを記述する開発者が行います。永続性が手動でコーディングされたJavaオブジェクトの場合も、永続的ビジネス・オブジェクト、データ・アクセス・コンポーネントおよびサービス・オブジェクトの実装は、すべて開発者が行います。 |
次の表は、その他のビジネス・サービス・テクノロジでの、永続的ビジネス・オブジェクト、データ・アクセス・コンポーネントおよびサービス・オブジェクトの実装方法を示しています。
テクノロジ | 永続的ビジネス・オブジェクト | データ・アクセス・コンポーネント | サービス・オブジェクト |
---|---|---|---|
Oracle ADF Business Components | ADF Business Componentsによる永続的ビジネス・オブジェクトの提供方法 |
ADF Business Componentsによるデータ・アクセス・コンポーネントの提供方法 |
ADF Business Componentsによるサービス・オブジェクトの提供方法 |
Enterprise JavaBeans | Enterprise JavaBeansによる永続的ビジネス・オブジェクトの提供方法 |
Enterprise JavaBeansによるデータ・アクセス・コンポーネントの提供方法 |
Enterprise JavaBeansによるサービス・オブジェクトの提供方法 |
OracleAS TopLink POJO | OracleAS TopLink POJOによる永続的ビジネス・オブジェクトの提供方法 |
OracleAS TopLink POJOによるデータ・アクセス・コンポーネントの提供方法 |
OracleAS TopLink POJOによるサービス・オブジェクトの提供方法 |
Enterprise JavaBeansとTopLink CMP | Enterprise JavaBeansとTopLink CMPによる永続的ビジネス・オブジェクトの提供方法 |
Enterprise JavaBeansとTopLink CMPによるデータ・アクセス・コンポーネントの提供方法 |
Enterprise JavaBeansとTopLink CMPによるサービス・オブジェクトの提供方法 |
ADF Business Componentsでは、ADFエンティティ・オブジェクト定義を永続的ビジネス・オブジェクトとして使用します。他のテクノロジの永続的ビジネス・オブジェクト同様、1つのエンティティ・オブジェクトがデータソース(ほとんどの場合、データベース内の表またはビュー)内の1つのエンティティにマップします。
エンティティ・オブジェクト定義は、エンティティ・オブジェクト・インスタンス(データベース表の個々の行を表す1つのJavaオブジェクト)のテンプレートです。たとえば、Departmentsという名前のエンティティ・オブジェクト定義は、DEPARTMENTS表の個々の行を表すエンティティ・オブジェクト・インスタンス用のテンプレートを提供します。
エンティティ・オブジェクト定義は、最大で次の4つのパーツで構成されます。
XMLファイル: エンティティ・オブジェクト定義のうち、宣言的に開発可能な部分を表します。ほとんどの情報がO/Rマッピングに必要なものですが、Validatorと呼ばれる単純な検証ルールも含むことができます。多くのエンティティ・オブジェクト定義では、XMLファイルのみで十分です。
エンティティ・オブジェクト・クラス: 個々のエンティティ・オブジェクト・インスタンスを表します。エンティティ・オブジェクト・クラスでは、XMLのValidatorが十分でない場合に、複雑なビジネス・ロジックをJavaで記述できます。エンティティ・オブジェクト・クラスはクラスoracle.jbo.server.EntityImpl
を拡張します。カスタムのJavaビジネス・ロジックが必要でない場合には、エンティティ・オブジェクト・クラスを作成する必要はありません。ADFでは、oracle.jbo.server.EntityImpl
をそのまま使用してデータソースの行を表すことが可能です。
エンティティ定義クラス: データ・ソース・オブジェクトを全体として表します。エンティティ定義クラスはXMLファイルに対するJavaラッパーの役割をします。このため、メタデータの特別な扱いが必要な場合(動的に変更する必要がある場合など)には、そのコードをエンティティ定義クラスに追加できます。エンティティ定義クラスはクラスoracle.jbo.server.EntityDefImpl
を拡張します。メタデータの特殊な扱いが必要でない場合には、エンティティ定義クラスを作成する必要はありません。ADFでは、oracle.jbo.server.EntityDefImpl
をそのまま使用してメタデータをラップすることが可能です。
エンティティ・コレクション・クラス: 1人のユーザー用にメモリーに格納される行のキャッシュ(エンティティ・オブジェクト・クラスのインスタンス)を表します。ほとんどの場合、エンティティ・コレクション・クラスを作成する必要はありません。ADF Business Componentsのデフォルトのキャッシュ方法をオーバーライドする場合にのみ作成します。
エンティティ・オブジェクト定義がデータベース・オブジェクトに基づいている場合、データベース・オブジェクト内の列は、エンティティ・オブジェクト定義内の1つのエンティティ・オブジェクト属性にマップします。これらの属性の定義(エンティティ・オブジェクト定義のXMLファイルに反映される)は、それぞれの列のプロパティ(列のデータ型、列制約、および精度とスケールの仕様など)を反映します。エンティティ・オブジェクト定義が他のデータソースのオブジェクトに基づいている場合、エンティティ・オブジェクト属性は、開発者の定義に従ってそのオブジェクトの列にマップします。エンティティ・オブジェクト・クラスを作成すると、属性もそのクラスのフィールドとして表されます。
前述したように、エンティティ・オブジェクト定義または属性には、検証ロジックをValidatorとして宣言的に追加できます。JDeveloperには、次の4つの単純なValidatorが用意されています。
CompareValidator: 属性を値(リテラル値またはデータソースから引き出した値)と比較します。
ListValidator: 属性が値のリスト(リテラル・リストまたは問合せの結果)にあるかどうかをチェックします。
RangeValidator: 属性が2つのリテラル値の間にあるかどうかをチェックします。
MethodValidator: ブール値を戻すあらゆるメソッドを起動できます。メソッドがTRUE
を戻した場合、検証は有効です。
この他に、独自のValidatorを作成できます。そのためにはコーディングが必要ですが、作成したValidatorはいくつもの異なるプロジェクトで宣言的に適用可能です。
デフォルトのValidatorがニーズを満たさない場合に独自のValidatorを作成せずに、エンティティ・オブジェクト・クラスに検証コードを追加することもできます。属性レベルの検証の場合はsetterメソッドに、複数属性の検証の場合はvalidateEntity()
という名前のメソッドに追加します。
エンティティ・オブジェクト・クラスは、他のビジネス・ロジックに対する関連付けも提供します。たとえば、create()
メソッドは新しい行が作成されるたびにコールされ、remove()
メソッドは行が削除されるたびにコールされます。これらのメソッドにビジネス・ロジックを追加すれば、行が作成または削除される際に必ずそのロジックが起動されます。
最後に、ADF Business Componentsは(INSERT、UPDATEおよびDELETEコマンドをデータベースに発行することで)DML操作を自動的に処理しますが、エンティティ・オブジェクト・クラスのdoDML()
メソッドをオーバーライドすればこの動作を上書きすることもできます。たとえば、データベース内のストアド・プロシージャを使用してDML操作を処理する場合などです。
エンティティ・オブジェクト定義間の関連はOracle ADFアソシエーションで処理されます。アソシエーションは、2つのOracle ADFエンティティ・オブジェクト定義間の関連を、それぞれのエンティティ属性のセットに基づいて定義します。関連は、外部キーに基づく単純な1対多のものから、複雑な多対多のものまで様々です。たとえば、次のような関連をアソシエーションで表すことができます。
顧客とその顧客によるすべての注文との間の1対多の関連
製品とその詳細説明との間の1対1の関連(それぞれが別々のエンティティ・オブジェクト定義で表されている場合)
製品と現在その製品の在庫がある倉庫との間の多対多の関連
ADF Business Componentsでは、ADFビュー・オブジェクト定義をデータ・アクセス・コンポーネントとして使用します。ADFビュー・オブジェクト定義はデータソースからデータを収集し、MVCアプリケーションで使用するためにデータを処理し、アプリケーションがOracle ADF Business Componentsキャッシュ内でそのデータを変更できるようにします。
ビュー・オブジェクト定義は、最大で次の4つのパーツで構成されます。
XMLファイル: エンティティ・オブジェクトのうち、宣言的に開発可能な部分を表します。この情報は、ビュー・オブジェクトがデータソースからのデータの取得に使用するメカニズム(通常はSQL問合せ)、およびSQL問合せの列とエンティティ属性とのマッピング方法(実際のO/Rマッピングを扱う)で構成されます。多くのビュー・オブジェクト定義では、XMLファイルのみで十分です。
ビュー・オブジェクト・クラス: 問合せ結果セットの個々のインスタンス(ビュー・オブジェクト・インスタンス)を表します。別々のユーザーは必ず別々のビュー・オブジェクト・インスタンスを使用しますが、同じユーザーでも複数のビュー・オブジェクト・インスタンスを使用できます。ビュー・オブジェクト・クラスを使用すると、問合せの複数の行に作用するカスタム・メソッドを記述できます。ビュー・オブジェクト・クラスはクラスoracle.jbo.server.ViewObjectImpl
を拡張します。カスタムのビュー・オブジェクト・メソッドが必要でない場合には、ビュー・オブジェクト・クラスを作成する必要はありません。ADFでは、oracle.jbo.server.ViewObjectImpl
をそのまま使用して問合せ結果セットのインスタンスを表すことが可能です。
ビュー行クラス: 問合せ結果の個々の行を表します。ビュー行クラスでは1行のデータに作用するカスタム・メソッドの記述が可能で、データを取得および変更するためのタイプセーフなアクセッサが提供されます。ビュー行クラスはクラスoracle.jbo.server.ViewRowImpl
を拡張します。カスタムの行レベル・メソッドまたはタイプセーフなアクセッサが必要でない場合には、ビュー行クラスを作成する必要はありません。ADFでは、oracle.jbo.server.ViewRowImpl
をそのまま使用してデータソースの行を表すことが可能です。(ViewRowImpl
には、データの取得と変更を行うgetAttribute()
メソッドとsetAttribute()
メソッドが含まれますが、これらはタイプセーフではありません。)
ビュー定義クラス: 問合せ自体を表します。ビュー定義クラスはXMLファイルに対するJavaラッパーの役割をします。このため、メタデータの特別な扱いが必要な場合(動的に変更する必要がある場合など)には、このコードをビュー定義クラスに追加できます。ビュー定義クラスはクラスoracle.jbo.server.ViewDefImpl
を拡張します。メタデータの特殊な扱いが必要でない場合には、ビュー定義クラスを作成する必要はありません。ADFでは、oracle.jbo.server.ViewDefImpl
をそのまま使用してメタデータをラップすることが可能です。
問合せ内の列は、ビュー・オブジェクト定義内の個々のビュー・オブジェクト属性にマップします。これらの属性の定義(ビュー・オブジェクトのXMLファイルに反映される)は、それぞれの列のプロパティ(データ型、およびエンティティ・オブジェクト属性にマップされる場合はその方法)を反映します。ビュー行クラスを作成すると、属性もそのクラスのフィールドとして表されます。
ビュー・オブジェクト定義は、様々な内容の問合せに基づくことができ、結合や計算属性はもちろん、グループ関数も表すことができます。
前述したように、ビュー・オブジェクト定義は、問合せ列からエンティティ・オブジェクト属性へのマッピングを扱います。あるビュー・オブジェクトの属性は、すべて同じエンティティ・オブジェクトの属性にマップする必要もなければ、どのエンティティ・オブジェクトの属性にもマップしなくても構いません。ビュー・オブジェクトはデータソースからの読込みを処理し、エンティティ・オブジェクト定義(ある場合)はDMLを処理します。ADF Business Componentsキャッシュのこのような操作は、最も強力な機能の1つです。
Sun社のJ2EE BluePrintsデサイン・パターンの1つにFast Lane Readerパターンがあります。必要なデータのために永続的ビジネス・オブジェクトを検索するかわりに、Fast Lane Readerはデータソースに直接問い合せます。この方法は永続的ビジネス・オブジェクトを検索するよりも格段に速い反面、データソースへの更新は永続的ビジネス・オブジェクトが扱うため、読取り専用になるというデメリットがあります。
ビュー・オブジェクト定義は、Fast Lane Readerパターンを改良したものです。Fast Lane Reader同様にデータベースに直接問い合せますが、オプションとしてエンティティ・オブジェクト・インスタンスに結果を保存し、そのインスタンスへのポインタを管理します。このため、Fast Lane Readerのスピードでデータベースを問合せ可能である一方、標準のFast Lane Readerのような読取り専用のデメリットを回避できます。
ビュー・オブジェクト定義間の関連はOracle ADFビュー・リンク定義で処理されます。ビュー・リンク定義は、2つのOracle ADFビュー・オブジェクト定義間の関連を、それぞれのエンティティ属性のセットに基づいて定義します。アソシエーション同様、関連は、外部キーに基づく単純な1対多のものから、複雑な多対多のものまで様々です。
個々のビュー・オブジェクト・インスタンスも、個々のビュー・リンク・インスタンスによって互いに関連付けることができます。その結果、問合せ結果セット間にマスター/ディテール関係が作成されます。たとえば、部門情報への問合せと従業員情報への問合せを表す2つのビュー・オブジェクト定義があり、部門と所属従業員との関連を表すビュー・オブジェクト定義間のビュー・リンクがあるとします。1つ目のビュー・オブジェクト定義のインスタンスallDepartments
が、ビュー・リンクのインスタンスによって、2つ目のビュー・オブジェクト定義のインスタンスemployeesInDepartment
に関連付けられている場合、この2つのインスタンスは同期化されます。その結果、allDepartments
の特定の行が選択されると、employeesInDepartment
には常にその行の詳細のみが表示されます。
ADF Business Componentsでは、ADFアプリケーション・モジュール定義をサービス・オブジェクトとして使用します。ADFアプリケーション・モジュール定義は、MVCアプリケーションとビジネス・サービス・レイヤー間を1箇所で連結する役目をします。具体的には、トランザクションを管理し、ビュー・オブジェクトとビュー・リンク・インスタンスのコンテナを提供します。
アプリケーション・モジュール定義は、次の1つまたは2つのパーツで構成されます。
XMLファイル: アプリケーション・モジュール定義のうち、宣言的に開発可能な部分を表します。具体的には、アプリケーション・モジュール定義に含まれるビュー・オブジェクトおよビュー・リンクのインスタンス、およびそれらの関連方法です。多くのアプリケーション・モジュール定義では、XMLファイルのみで十分です。
アプリケーション・モジュール・クラス: カスタム・コード(MVCアプリケーションでバッチ・データ処理用に起動可能なサービス・メソッドなど)を記述できます。アプリケーション・モジュール・クラスはクラスoracle.jbo.server.ApplicationModuleImpl
を拡張します。カスタムのサービス・メソッドを記述する必要がない場合には、アプリケーション・モジュール・クラスを作成する必要はありません。ADFでは、oracle.jbo.server.ApplicationModuleImpl
をそのまま使用できます。
アプリケーション・モジュール定義の最も重要な機能は、そのデータ・モデル(定義に含まれるビュー・オブジェクトおよびビュー・リンクのインスタンス)です。データ・モデルは、クライアントがアクセス可能なデータ、およびデータ内の関連を指定します。
アプリケーション・モジュール定義は、次の2種類の方法で使用できます。
サービス・オブジェクトとして使用: MVCアプリケーションの各インスタンスがアプリケーション・モジュールの1つのインスタンスにアクセスできます。このようなルート・レベルのアプリケーション・モジュール・インスタンスはADF BCトランザクション・オブジェクトを制御し、ADF BCトランザクション・オブジェクトはエンティティ・キャッシュおよびビュー・キャッシュを制御します。
ネストした再利用可能オブジェクトとして使用: データ・モデルとサービス・メソッドを作成し、そのインスタンスの1つを他のアプリケーション・モジュール定義にネストできます。このようなアプリケーション・モジュール定義は、ネストされたモジュールのメソッドおよびデータ・モデルにアクセスできます。ネストされたアプリケーション・モジュールは、ルート・レベルのアプリケーション・モジュールのトランザクションを共有します。
アプリケーション・モジュール・インスタンスはアプリケーション・モジュール・プール内の要素です。アプリケーション・モジュール・プールは、あるインスタンスをメモリー内にキャッシュとともに保持する必要があるか、データベースにシリアライズしてメモリーを節約できるか、またはインスタンス全体を削除できるかを自動的に判断する構成可能なリソース・マネージャです。アプリケーション・モジュールのプーリングは、アプリケーションのスケーラビリティを大幅に向上させます。
Enterprise JavaBeansでは、EJB Entity Beanを永続的ビジネス・オブジェクトとして使用します。他のテクノロジの永続的ビジネス・オブジェクト同様、1つのEntity Beanがデータソース(ほとんどの場合、データベース内の表またはビュー)内の1つのエンティティにマップします。ほとんどの場合、アプリケーションではコンテナ管理の永続性(CMP)を使用してください。CMPでは、外部コンテナ(アプリケーション・サーバーやTopLinkランタイムなど)を使用してO/Rマッピングを処理できます。CMPにかわる選択肢がBean管理の永続性(BMP)で、手動でコーディングされた永続性を使用するJavaクラスと共通する多くのデメリットがあります。BMP Entity Beanを使用するには、O/Rマッピング、永続性およびデータ取得を自分で行う必要があります。BMP Beanは、データベース以外のデータソースを使用する必要があるアプリケーションで有効です。
EJB CMPのEntity Beanは、最大で次の6つのパーツで構成されます。
EJBデプロイメント・ディスクリプタ内の要素: EJB Beanセットのすべての内容を指定するXMLファイル。Beanのフィールドからデータベース列へのマッピング方法など、Beanのメタデータを表します。
Beanクラス: Beanのフィールドをリストする抽象クラス。
ローカル・ホーム・インタフェース: Beanクラスのインスタンスを、同じコンテナ内の他のBeanで使用するために作成するメソッドが含まれます。
ホーム・インタフェース: Beanクラスのインスタンスを、コンテナ外部のクラスで使用するために作成するメソッドが含まれます。
ローカル・インタフェース: 他のEJB BeanとEntity Beanとの対話方法。
リモート・インタフェース: EJBコンテナ外部のJavaオブジェクトとBeanとの対話方法。
CMP Entity Beanには直接インスタンス化できるパーツはなく、1つのXML要素、1つの抽象クラス、および3つのインタフェースで構成される点に注意してください。CMPプロバイダは自動的に抽象クラスを拡張して実装クラスを作成し、実装クラスがそのままインスタンス化されてEntity Beanインスタンスが作成されます。このEntity Beanインスタンスがデータベース内の1つの行を表します。同様に、CMPプロバイダはホーム・インタフェースまたはローカル・ホーム・インタフェース、あるいはその両方を自動的に実装します。開発者が実装クラスを直接操作する必要はありません。アプリケーションでは、常に、ローカル・インタフェースまたはリモート・インタフェースを介してEntity Beanインスタンスが参照され、ホーム・インタフェースまたはローカル・ホーム・インタフェースを介してホームが参照されます。
データベース・オブジェクト内の列は、Entity Beanクラスの1つのフィールドおよびXML要素の1つのサブ要素にマップします。XMLサブ要素の属性は、これらの列のプロパティ(列のデータ型、列制約、および精度とスケールの仕様など)を反映します。
ADFエンティティ・オブジェクト定義と異なり、EJB Entity Beanはビジネス・ロジックへの関連付けは提供しません。アクセッサ・メソッドの実装はCMPプロバイダが行うため(Beanクラスで、メソッドは抽象)、これらのメソッドにビジネス・ロジックを実装することはできません。ただし、JDeveloperではEntity Bean用にデータ転送オブジェクトを自動的に作成できます。データ転送オブジェクトはJ2EE BluePrintsデサイン・パターンの実装で、MVCアプリケーションとEntity Beanを媒介する役割を果たします。データ転送オブジェクトはEntity Beanの属性の一部またはすべてを公開し、ビジネス・ロジックの実装用に変更可能なgetterとsetterを含みます。ただし、複数属性に関連するロジックは簡単には実装できません。EJBを使用する場合、複数属性のロジックはコントローラ・レイヤーに実装するか、または独自のフレームワーク・コードを記述して作成する必要があります。
Entity Bean間の関連はコンテナ管理の関連性(CMR)で処理されます。CMRは、2つのEntity Bean間の関連を、それぞれのフィールド・セットに基づいて定義します。関連は、外部キーに基づく単純な1対多のものから、複雑な多対多のものまで様々です。たとえば、次のような関連をCMRで表すことができます。
顧客とその顧客によるすべての注文との間の1対多の関連
製品とその詳細説明との間の1対1の関連(それぞれが別々のエンティティ・オブジェクト定義で表されている場合)
製品と現在その製品の在庫がある倉庫との間の多対多の関連
ADF Business Componentsと異なり、Enterprise JavaBeansはデータ・アクセス・コンポーネントの提供に実際のオブジェクトを使用しません。そのかわり、EJBアプリケーションは、EJB finderメソッドをデータ・アクセス・コンポーネントとして使用します。
EJB finderメソッドは、EJBのホーム・インタフェース上のメソッドです。finderメソッドを作成する際には、EJBQLと呼ばれる専用の問合せ言語で問合せを指定できます。指定した問合せはデプロイメント・ディスクリプタに追加され、CMPプロバイダがこれを使用してコードを生成し、問合せの条件に一致するEntity Beanインスタンスが検索されます。
ADFビュー・オブジェクト定義と異なり、EJB finderメソッドの内容には制限があります。このメソッドはEntity Beanのコレクションを戻すだけで、結合や計算属性を実装することはできません。また、EJB finderメソッドはデータベースではなくEntity Beanを問い合せるため、Fast Lane Readerパターンのような速度は得られません。もちろん自分でFast Lane Readerパターンを実装することは可能ですが、このパターンではEntity Beanのコレクションは作成されずに単なるデータのリストが作成されるため、DML操作の実行には使用できません。最適のパフォーマンスを実現するには、読取り専用のデータで十分な場合はFast Lane Readerを作成して使用し、その他の場合はEJB finderメソッドを使用してください。
Enterprise JavaBeansでは、EJB Session Beanをサービス・オブジェクトとして使用します。Session Beanは、MVCアプリケーションとビジネス・サービス・レイヤーを1箇所で連結する役目をし、Entity Beanのホーム・インタフェースおよびローカル・ホーム・インタフェースへのアクセスを提供します。
Entity Beanと同じくSession Beanには2つのタイプがあります。ほとんどの場合、アプリケーションではコンテナ管理のトランザクション(CMT)を使用してください。CMTでは、外部コンテナ(アプリケーション・サーバーやTopLinkランタイムなど)でトランザクションを処理できます。もう1つのタイプはBean管理のトランザクション(BMT)で、開発者がコードを記述してトランザクションを処理する必要があり、トランザクション処理に特別な要件がある場合にのみ適しています。
EJB CMTのSession Bean定義は、最大で次の6つのパーツで構成されます。
EJBデプロイメント・ディスクリプタ内の要素。Entity Bean用の要素と異なり、この要素にはBeanの名前のみが含まれます。
Beanクラス: カスタム・コード(MVCアプリケーションでバッチ・データ処理用に起動可能なサービス・メソッドなど)を記述できます。CMP Entity Bean用のBeanクラスと異なり、このクラスは抽象クラスではありません。
ローカル・ホーム・インタフェース: Beanクラスのインスタンスを、同じコンテナ内の他のBeanで使用するために作成するメソッドが含まれます。
ホーム・インタフェース: Beanクラスのインスタンスを、コンテナ外部のクラスで使用するために作成するメソッドが含まれます。
ローカル・インタフェース: コンテナ内の他のEJB BeanとSession Beanとの対話方法。
リモート・インタフェース: EJBコンテナ外部のJavaオブジェクトとBeanとの対話方法。
ADFアプリケーション・モジュール定義と異なり、Session Beanには完全なデータ・モデルは含まれません。そのかわり、マスターEntity Beanのローカル・ホーム・インタフェースへのEJBローカル参照があります。ディテールEntity Beanへは、コンテナ管理の関連性を介してマスターからアクセスします。
現在ADFモデル・レイヤーで使用できるのは、ステートレスSession Beanのみです。ステートレスBeanはクライアント・アクセス間の状態(ステート)を管理せず、単にクライアントとデータベースの間を直接媒介します。MVCアプリケーションはデータを取得するリクエストを1つBeanに送信し、Entity Beanインスタンスをキャッシュし、次にデータをポストしてコミットするもう1つのリクエストをBeanに送信します。JDeveloperではステートフルSession Beanも作成できますが、そのBeanからはデータ・コントロールを作成できません。
TopLink POJOでは、一般のJavaBeansクラスを永続的ビジネス・オブジェクトとして使用します。クラスは開発者が作成し、データベースとの対話を除くすべてを実装します。データベースとの対話は、ディスクリプタを使用するTopLinkランタイムによって処理されます。ディスクリプタはTopLinkデプロイメント・ディスクリプタ(JavaBeansクラスのセットに対するTopLinkマッピングのすべての内容を記述したXMLファイル)内の要素です。ディスクリプタは、クラスからデータベース列へのマッピング方法を記述し、キーおよび順序に関する情報を提供します。
TopLinkの最も重要な機能の1つに、複雑なO/Rマッピングの自動化があります。TopLinkでは、このO/Rマッピングにより、データベース内のオブジェクトとは実質的に構造が異なるJavaオブジェクトも含めて、任意のJavaオブジェクトにデータベース・オブジェクトをマップできます。
TopLinkでは、フィールドとデータベース列間の次のマッピングを提供します。
フィールドへ直接マッピング: 1つのフィールドと1つのデータベース列の間の単純なマッピング。
タイプ変換マッピング: フィールドとデータベース列のデータ型間でより複雑な変換(StringからNUMBERまたはDATEへの変換など)が可能なマッピング。
オブジェクト・タイプ・マッピング: データベースのデータとは基本的に異なるデータをJavaオブジェクトに格納できます。たとえば、データベース内の値「M」をフィールド内の値「male」に、「F」を「female」にマップ可能です。
シリアライズ・オブジェクト・マッピング: BLOBやマルチメディア・ファイルなどの大規模データを効率的にマップできます。
トランスフォーメーション・マッピング: 複数のデータベース列を1つのフィールドにマップできます。
配列マッピング: VARRAYおよびネストされた表をJava配列にマップします。
構造マッピング: データベース構造をJavaクラスにマップします。
ADF Business Componentsと異なり、TopLinkは特に既存のJavaオブジェクト・フレームワークとデータベース間の対話の管理を目的としています。このため、TopLinkには検証ルールやその他のビジネス・ルール機能はなく、これらの機能はオブジェクト・モデルで行います。
JavaBeansクラス間の関連は、Javaオブジェクト・マッピングによってデプロイメント・ディスクリプタで処理されます。TopLinkでは、O/Rマッピングと同様に関連についても非常に柔軟な体系が用意されています。開発者は、データベース内の次のような様々な関連に基づいて、Javaオブジェクトを関連付けることができます。
顧客とその顧客によるすべての注文との間などの、単純な1対多の関連。
製品とその詳細説明との間など(それぞれが別々のエンティティ・オブジェクト定義で表されている場合)の、単純な1対1の関連。
製品と現在その製品の在庫がある倉庫との間などの、多対多の関連。
マップされたオブジェクトとされていないオブジェクト(Stringなど)との間の1対多の関連。
集計オブジェクトの関連: JavaBeansクラス間の1対1の関連。JavaBeansクラスは同じデータベース行にマップしている必要があります。
集計コレクションの関連: (属性の一致や外部キーに基づく1対多の関連と異なり)プログラム的に定義可能な1対多の関連。
JavaBeansではなく(可変実装クラスで)インタフェースを互いに関連付けることができる、可変1対1の関連。
REFに基づく関連。
ネストされた表に基づく1対多、または多対多の関連。
Enterprise JavaBeansと同様、TopLink POJOはデータ・アクセス・コンポーネントの提供に実際のオブジェクトを使用しません。そのかわり、TopLink問合せをデータ・アクセス・コンポーネントとして使用します。
TopLink問合せは、JavaBeansディスクリプタ内の要素です。TopLink問合せを作成する際には、SQL、EJBQLまたはTopLinkの独自に構成された式言語を使用できます。TopLinkランタイムは、この問合せに一致するオブジェクトをTopLinkキャッシュ内で検索します。
EJB finderメソッド同様、TopLink問合せの内容には制限があります。この問合せはデータベース表にマップされたJavaBeansクラスのコレクションを戻すだけで、結合や計算属性を実装することはできません。また、Fast Lane Readerパターンのような速度も得られません。ただし、TopLinkにはレポート問合せと呼ばれるもう1つの問合せがあり、こちらでは同様の速度を得ることができます。ただしレポート問合せの結果は、DML操作の実行には使用できません。
OracleAS TopLinkでは、本来のサービス・オブジェクトは提供されません。TopLinkデプロイメント・ディスクリプタがすべてのJavaBeansクラスを集計し、アプリケーションのMVC部分がこれと直接やり取りします。
TopLinkには固定されたデータ・モデルはありません。アプリケーションは動的にJavaオブジェクト・マッピングを横断して、ソース・オブジェクトから詳細やその他の関連オブジェクトを取得できます。
TopLinkはキャッシュを維持します。ADF Business Componentsや標準のEJBと異なり、TopLinkキャッシュおよび単独のデータベース・トランザクションがユーザー間で共有されます。TopLinkランタイムは、自動的にデータをマージして一貫性を維持します。キャッシュおよびトランザクションには、TopLinkセッションと呼ばれるJavaオブジェクトを介してアクセスします。
TopLinkランタイムは、EJB Entity BeanへのCMPプロバイダとしても使用できます。TopLinkをCMPプロバイダとして使用すると、格段に複雑なO/Rマッピングを自動化できます。TopLink CMPを使用すると、フィールドへ直接、タイプ変換、オブジェクト・タイプ、シリアライズ・オブジェクトおよびトランスフォーメーションといった各種マッピングをEJB Entity Beanで使用できます。
他のEntity Bean同様、TopLinkのEntity BeanもCMRを介して関連付けられます。
他のCMPプロバイダ同様、TopLinkランタイムはEJB finderメソッドをデータ・アクセス・コンポーネントとして使用します。ただし、TopLinkランタイムでは、SQL、EJBQLまたはTopLinkの独自に構成された式言語を使用して問合せを指定できます。