| Oracle TopLink開発者ガイド 10g（10.1.3.1.0） B31861-01 |
|
 戻る |
 次へ |
この章では、TopLinkアプリケーションの作成方法について説明します。推奨する開発プロセス、アーキテクチャ、テクノロジについても説明します。
この章の内容は次のとおりです。
TopLinkアプリケーションの設計を最適化するために、反復型の段階的な開発プロセスに従うことをお薦めします。TopLinkには、あらゆる開発ツールを使用できるという柔軟性があります。
この項では、次の推奨される開発プロセスについて説明します。
この項では、TopLinkアプリケーションの一般的な開発段階のそれぞれについて説明します。図2-1は、TopLink開発プロセスを示しています。
アプリケーションの設計（1）
アプリケーション要件を定義し、アーキテクチャを選択し、ターゲット・プラットフォームを決定します。詳細は、「TopLinkを使用するアプリケーションの設計」を参照してください。TopLinkはあらゆるアーキテクチャおよびあらゆるプラットフォームで使用できることを覚えておいてください。
アプリケーションを設計する際、そのアプリケーションに対するオブジェクト・モデルも作成する必要があります。詳細は、「オブジェクトの永続化の概要」を参照してください。TopLinkを使用してオブジェクトをマップする前にオブジェクト・モデルを作成することが重要です。これは、誤ったモデルまたは急速に変化するモデルに対して永続マッピングを定義すると非常に面倒なことになるためです。
アプリケーションの開発（2、3、4）
Javaクラスを作成し、そのクラスがデータ・ソースによってどのように実装される必要があるかを決定します。レガシー・システムを使用する場合、クラスが既存データにどのように関連するかを決定します。統合するレガシー・データ・ソースがない場合は、データ・ソースに各クラスを格納する方法を決定し、必要なスキーマを作成します。または、TopLinkを使用して初期の表を作成することもできます。
TopLink Workbenchを使用して、永続クラスに対するディスクリプタとマッピングを作成します。TopLinkセッションを使用して、永続クラスの操作（データの問合せおよび変更など）を行います。詳細は、第II部「TopLinkの開発ツールの使用」を参照してください。
1回の開発サイクルで、モデルのディスクリプタをすべて作成することは避けます。クラスの小さなサブセットから開始してください。それらのディスクリプタを作成およびテストしてから、段階的に新規のディスクリプタとリレーションシップを追加します。これにより、一般的な問題が設計全体にわたって拡散する前にこのような問題を捕捉できます。
データベース・セッションを使用するJavaコードを記述します。セッションは、データベース・オブジェクトの問合せおよびデータベースへのオブジェクトの書込みに使用します。詳細は、第72章「TopLinkセッションの概要」を参照してください。
アプリケーションのデプロイ（5）
必要なファイルを生成し、パッケージ化して、アプリケーション・サーバーにデプロイします。必要な情報は、環境およびアーキテクチャによって異なります。詳細は、第III部「TopLinkアプリケーションのデプロイ」を参照してください。
アプリケーションのメンテナンス（6）
TopLinkには、アプリケーションのパフォーマンスを向上させるための数多くのオプションが含まれています。TopLinkの大部分の機能は、要件に合うようにカスタマイズできます。高度なTopLinkの機能を使用したりカスタム問合せルーチンを書いて、特定の方法でデータベースにアクセスし、パフォーマンスを最適化します。詳細は、第IV部「TopLinkアプリケーションの最適化およびカスタマイズ」を参照してください。
Oracleでは、Oracle Technology Network（OTN）上でTopLink開発者に対して次のような追加サポートを提供しています。
OTNを使用する前にオンラインで登録を行う必要があります。登録は無料であり、次のサイトで行うことができます。
http://www.oracle.com/technology/membership
すでにOTNのユーザー名とパスワードを取得している場合は、次のOTN Webサイトの「Documentation」セクションに直接アクセスできます。
http://www.oracle.com/technology/docs
OTNのユーザー名とパスワードを使用して、TopLink開発者のForumにアクセスし、TopLinkの使用に関する質問を投稿して回答を得ることができます。次を参照してください。
http://forums.oracle.com/forums/forum.jsp?forum=48
アプリケーションを設計する際、どこでどのようにTopLinkを使用するかを選択する必要があります。TopLinkを使用して、いろいろなJavaサポートのプラットフォーム上で（「ターゲット・プラットフォームの概要」を参照）、永続化およびデータ・トランスフォーメーションを行う様々な機能を実行できます（「TopLinkの使用方法の概要」を参照）。アプリケーション・アーキテクチャを設計する際は、これらの機能があることを考慮してください（「TopLinkを使用するアーキテクチャの選択」を参照）。
この項では、TopLinkの基本的な使用方法について説明します。使用方法には次の種類があります。
TopLinkを使用すると、JDBCを使用してアクセスされる、SQLデータ・タイプをサポートするリレーショナル・データベースに、Javaオブジェクトを永続化できます。
詳細は、「リレーショナル・データベース用リレーショナル・プロジェクトの作成」を参照してください。
TopLinkを使用すると、オブジェクト・ストレージ用に特化されたデータ・タイプをサポートする、JDBCを使用してアクセスされるオブジェクト・リレーショナル・データベース（Oracle Databaseなど）に、Javaオブジェクトを永続化できます。
詳細は、「リレーショナル・データベース用リレーショナル・プロジェクトの作成」を参照してください。
TopLinkでXMLタイプへ直接マッピング機能を使用して、Oracle XMLデータベースにXML文書を永続化できます。
詳細は、「リレーショナル・プロジェクト」および「XMLタイプへ直接マッピング」を参照してください。
TopLinkでJ2Cアダプタを使用して、EISデータ・ソースにJavaオブジェクトを永続化できます。
このシナリオでは、J2CアダプタがEISとのインタラクションを受信することで、アプリケーションがEISデータ・ソースによって定義された操作を起動します。操作により、EISレコードが取得されたり返されます。TopLink EISディスクリプタとマッピングを使用して、J2CアダプタとEISデータ・ソースによってサポートされるEISレコード・タイプに、Javaオブジェクトを容易にマップできます。
この使用方法は、レガシー・データ・ソースに接続するアプリケーションでは一般的であり、Webサービスにも適用できます。
詳細は、「EISプロジェクト」を参照してください。
TopLinkで、XML文書およびJAXBをベースにしたXMLスキーマ（XSD）を使用して、インメモリーの非永続JavaオブジェクトをXMLにトランスフォーメーションできます。
TopLink JAXBコンパイラをXSDとともに使用して、JAXB固有の生成物（コンテンツと要素のインタフェース、実装クラス、オブジェクト・ファクトリ・クラスなど）とTopLink固有の生成物（セッション、プロジェクトXMLファイル、TopLink Workbenchプロジェクトなど）を両方とも生成できます。詳細は、「TopLinkによるJava Architecture for XML Binding（JAXB）のサポート」を参照してください。
この使用方法は、メッセージ機能やWebサービスを含んでいるため、多くのアプリケーションで利用されます。
詳細は、「XMLプロジェクト」を参照してください。
TopLinkでは、次のようなJavaを使用するすべてのエンタープライズ・アーキテクチャをサポートします。
Javaアプリケーション・サーバーとJ2EEコンテナ（例、Oracle Application ServerとOracle Containers for J2EE（OC4J））
Javaをサポートするデータベース（Oracle Databaseなど）
Javaと互換性のあるブラウザ（Netscape、Internet Explorerなど）
サーバーのJavaプラットフォーム（AS/400、OS/390、UNIXなど）
開発者によるTopLinkの使用方法および構成方法は、ホストのJavaまたはJ2EE環境にデプロイするための、特定のターゲット・プラットフォームでのアプリケーションのパッケージ化要件の影響を受けます。たとえば、J2EEアプリケーションをエンタープライズ・アーカイブ（EAR）ファイルにパッケージします。EARファイル内では、永続エンティティをWeb Archive（WAR）およびJava Archive（JAR）内にパッケージするための方法がいくつかあります。開発者によるTopLinkの構成方法は、部分的に、アプリケーションのパッケージ方法およびホスト・アプリケーション・サーバーのクラス・ローダーの使用方法に依存します。
さらに、TopLinkは様々なアプリケーション・サーバーに対してカスタムCMP統合を可能にします。
サポートされるアプリケーション・サーバーのバージョン、カスタム統合、構成要件の詳細は、「TopLinkとアプリケーション・サーバーの統合」を参照してください。
この項では、TopLinkに適用されるアプリケーション・アーキテクチャの主な点をいくつか説明し、それぞれの点で利用可能な様々なオプションについて説明します。次の点について説明します。
この項では、アプリケーション・アーキテクチャでクライアントの機能とサーバーの機能の分離方法を決定する際に必要となる選択について説明します。
これらの選択については、次のようにまとめることができます。
Webクライアント
XML/Webサービス・クライアント
Java（ファット・）クライアント
3層アプリケーション・アーキテクチャをお薦めします。3層アーキテクチャの場合、TopLinkサーバー・セッションとクライアント・セッション（「サーバーおよびクライアントのセッション」を参照）とTopLink作業ユニット（第97章「TopLinkトランザクションの概要」を参照）の使用をお薦めします。
詳細は、「3層アーキテクチャの概要」を参照してください。
TopLinkは、J2EEのアプリケーション・アーキテクチャでもJ2EE以外のアプリケーション・アーキテクチャでも使用できます。J2EEアプリケーション・アーキテクチャの使用をお薦めします。
J2EEアプリケーションの場合、外部接続プールを使用する必要があります（「外部接続プール」を参照）。Java Transaction API（JTA）統合（「JTAによって制御されるトランザクション」を参照）、EJBセッションBeanまたはエンティティBean（あるいはこれらの組合せ）の使用を検討できます。
J2EE以外のアプリケーションの場合、内部接続プールを使用する必要があります（「内部接続プール」を参照）。
3層アプリケーション・アーキテクチャでは、次のいずれかのタイプのクライアントを実装できます。
Webクライアント: Webクライアントの実装をお薦めします。
XML/Webサービス・クライアント: このクライアント・タイプの場合、TopLink XMLを使用できます（「XMLでの使用方法」を参照）。
Java（ファット・）クライアント: このクライアント・タイプの場合、サーバーとの通信手段を選択できます。
EJBセッションBean: 推奨アプローチです。デシリアライズされたオブジェクトのマージを処理するには、UnitOfWorkのmergeCloneメソッドの使用をお薦めします（「作業コピーのクローンでの変更内容のマージ」を参照）。このアプローチの短所は、アプリケーションがシリアライズを処理する必要があることです。深いオブジェクト・グラフはシリアライズしないようにしてください。インダイレクションの使用をお薦めします（「インダイレクションの構成」を参照）。データ転送オブジェクト・パターンの使用も検討してください。
XML/Webサービス: TopLink XMLを使用します（「XMLでの使用方法」を参照）。
EJBエンティティBean: TopLink CMP統合またはBMPサポートを使用します。このアプローチの短所は、リモート・エンティティBeanが高いパフォーマンスやスケーラビリティを示さなくなることです。
RMI: TopLinkリモート・セッションの使用をお薦めします（「リモート・セッション」を参照）。このアプローチの短所は、リモート・セッションがステートフルであり、高いスケーラビリティを持たなくなることです。
「サービス層」も参照してください。
2層アプリケーション・アーキテクチャの場合、TopLinkデータベース・セッション（「データベース・セッション」を参照）とTopLink作業ユニット（第97章「TopLinkトランザクションの概要」を参照）の使用をお薦めします。このアーキテクチャの短所は、Web対応ではないことと、大規模なデプロイへのスケーラビリティを持たないことです。
詳細は、「2層アーキテクチャの概要」を参照してください。
この項では、アプリケーションのビジネス・ロジック（またはサービス）のカプセル化方法を決定する際に必要となる選択について説明します。
これらの選択については、次のようにまとめることができます。
関連項目:
EJBセッションBeanの使用をお薦めします。
EJBセッションBeanの場合、JTA統合（「JTAによって制御されるトランザクション」を参照）と外部接続プール（「外部接続プール」を参照）を使用する必要があります。ServerのgetActiveUnitOfWorkメソッドを使用して作業ユニットを取得する必要があります（「外部トランザクション・サービスを持つ作業ユニットの取得」を参照）。セッションBeanとデータ・ソースが同じJVMにない場合は、デシリアライズされたオブジェクトのマージを処理するために、UnitOfWorkのmergeCloneメソッドの使用を考慮できます（「作業コピーのクローンでの変更内容のマージ」を参照）。
詳細は、「EJBセッションBeanファサード・アーキテクチャの概要」を参照してください。
ステートフル・セッションBeanを使用している場合、クライアント・セッションの参照を非アクティブ化できません。この場合、アクティブ化されたときかまたはリクエストごとに、クライアント・セッションを再取得する必要があります（「セッション・マネージャによる実行時のセッションの取得」を参照）。
ステートレス・セッションBeanを使用している場合、リクエストごとに新しいクライアント・セッションを取得する必要があります（「セッション・マネージャによる実行時のセッションの取得」を参照）。
EJBエンティティBeanのインタフェースにより、TopLinkの機能がクライアント・アプリケーション開発者から完全に隠されてしまうため、EJBエンティティBeanのアーキテクチャは他のTopLinkアーキテクチャとは若干異なります。
エンティティBeanは、ほとんどすべてのJ2EEアプリケーションで使用できます。TopLinkにとって、アプリケーションでエンティティBeanがどのように使用されるかは重要ではありません。エンティティBeanがどのようにマップされ、実装されるかが、TopLinkにとって重要です。
コンテナ管理の永続性を備えたエンティティBeanの使用をお薦めします。この場合、アプリケーション・サーバーに対してTopLink CMP統合を使用する必要があります。TopLinkでサポートされるJ2EEサーバーを使用しているかどうかを確認する必要があります（「TopLinkとアプリケーション・サーバーの統合」を参照）。
詳細は、「CMPを使用するEJBエンティティBeanのアーキテクチャの概要」を参照してください。
Bean管理の永続性を備えたエンティティBeanを使用している場合、TopLink BMP統合を使用する必要があります。このアーキテクチャの短所は、BMPアーキテクチャが制限的で、良好なパフォーマンスが示されない場合があることです。
詳細は、「BMPを使用するEJBエンティティBeanのアーキテクチャの概要」を参照してください。
EJB 3.0 Java Persistence API（JPA）は、Java EEおよびSEアプリケーションの永続性のための仕様です。JPAでは、永続クラスはエンティティと呼ばれます。エンティティは、Plain Old Java Object（POJO）クラス（「Plain Old Java Object（POJO）」を参照）であり、データベースにマップされ、注釈やXMLを通じてJPAで使用できるよう構成されます。
JPAでは、アプリケーションがコンテナ内で実行される場合、コンテナによるサポートや利便性などのすべての利点が適用されます。ただし、同じアプリケーションをコンテナの外部で実行するよう構成することも可能です。
アプリケーションとJPAの対話の手段として、セッションBean（「EJBセッションBean」を参照）を使用できます。
アプリケーション開発でJPAを使用する場合、次のオプションを考慮してください。
TopLink Essentials: TopLinkのオープンソース・コミュニティ版。TopLink Essentialsは、EJB 3.0におけるJPAのリファレンス実装に必要なオブジェクト・リレーショナル・マッピングの中核機能を提供するTopLinkを基盤としています。TopLink Essentialsは、GlassFish Open Source Java EE 5 Application Serverのエンティティ永続性モジュールとしてソース配布およびバイナリ配布の形式で使用できます。
TopLink: JPAのプレビュー機能を提供する商用実装版。
どちらのオプションでも、この新しい標準仕様とその追加機能およびパフォーマンス向上に対する優れたサポートが提供されます。
詳細は、「EJB 3.0 JPAエンティティのアーキテクチャの概要」および「TopLinkアプリケーションのアーキテクチャ」を参照してください。
J2EEアプリケーション・サーバーを使用してEJB以外のJavaオブジェクトでサービス層を作成することを選択する場合は、外部接続プールを使用する必要があります（「外部接続プール」を参照）。J2EE以外のWebサーバーを使用する場合は、内部接続プールを使用する必要があります（「内部接続プール」を参照）。いずれの場合も、JTA統合の使用をお薦めします（「JTAによって制御されるトランザクション」を参照）。
この項では、アプリケーション・アーキテクチャでサポートするデータのタイプを決定する際に必要となる選択について説明します。
これらの選択については、次のようにまとめることができます。
「ロック」も参照してください。
TopLinkを使用して次のデータ・タイプのいずれかを管理することができます。
リレーショナル（「リレーショナル・データベースでの使用方法」を参照）
オブジェクト・リレーショナル（「オブジェクト・リレーショナル・データベースでの使用方法」を参照）
Oracle XDB（「Oracle XML Database（XDB）での使用方法」を参照）
EISデータ、非リレーショナル・データ、レガシー・データ（「企業情報システム（EIS）での使用方法」を参照）
XMLおよびWebサービスのデータ（「XMLでの使用方法」を参照）
アプリケーション・アーキテクチャが複数のデータ・ソースにアクセスする必要がある場合、2フェーズ・コミットを行うためにセッション・ブローカ（「セッション・ブローカおよびクライアント・セッション」を参照）とJTA統合（「JTAによって制御されるトランザクション」を参照）を使用することをお薦めします。
または、複数セッションを使用することもできます。
アプリケーション・アーキテクチャが一部のデータを、プライベート・キャッシュにのみ持って、TopLinkによって共有されるセッション・キャッシュから分離する必要がある場合、独立セッションの使用をお薦めします（「独立クライアント・セッション」を参照）。Oracle Virtual Private Database（VPD）機能により独立セッションを使用することもできます（「独立クライアント・セッションとOracle Virtual Private Database（VPD）」を参照）。
データ・ソースが過去バージョンすなわち履歴バージョンのオブジェクトを保持している場合、この履歴データにアクセスするため、TopLink履歴セッションを使用することをお薦めします。これにより、ある期間にどのようにオブジェクトが変更されているかについての条件を付けた読込み問合せを表現できるようになります（「履歴セッション」を参照）。
この項では、アプリケーション・アーキテクチャでのTopLinkキャッシュの使用方法を決定する際に必要となる選択について説明します（第87章「キャッシュの概要」を参照）。
これらの選択については、次のようにまとめることができます。
「ロック」も参照してください。
アプリケーションが処理するデータのタイプに対して適切なキャッシュ・タイプを選択します（「キャッシュ・タイプおよびオブジェクト・アイデンティティ」を参照）。たとえば、揮発性のデータに対しては、弱アイデンティティ・マップを検討します（「キャッシュおよびアイデンティティ・マップの構成のガイドライン」を参照）。
アプリケーション・アーキテクチャにおける失効データの影響を検討します（「失効したデータの処理」を参照）。たとえば、問合せまたはディスクリプタのリフレッシュ・オプション（「リフレッシュ」を参照）またはキャッシュの無効化（「キャッシュの無効化」を参照）の使用を検討します。揮発性データに対しては、分離セッション・キャッシュを使用することを検討します（「独立クライアント・セッション」を参照）。
リレーションシップに含まれるオブジェクト、またはオブジェクトのアイデンティティを必要とするオブジェクトに対しては、アイデンティティ・マップなし（「アイデンティティ・マップなし」を参照）を使用しないでください。
TopLinkは、分散キャッシュ・コーディネーション機能を提供します。この機能では、セッションの複数（大部分の場合、分散によるもの）のインスタンスが相互にオブジェクト変更をブロードキャストでき、これにより、各セッションのキャッシュは最新の状態を保つことができます（「キャッシュ・コーディネーションの概要」を参照）。キャッシュ・コーディネーションを使用する前に、この機能がアプリケーションに適切かどうかを確認します（「キャッシュ・コーディネーションの使用が必要な場合」を参照）。
変更がブロードキャストされるようにキャッシュ・コーディネーションを構成する際、次の通信プロトコルのいずれかを使用できます。
Java Message Service（JMS）: JMSコーディネート・キャッシュの使用をお薦めします（「JMSコーディネート・キャッシュ」を参照）。
Remote Method Invocation（RMI）: 同期変更伝播が必要な場合のみ、RMIキャッシュ・コーディネーションの使用をお薦めします（「同期変更伝播モードの構成」を参照）。詳細は、「RMIコーディネート・キャッシュ」を参照してください。
Common Object Request Broker Architecture（CORBA）: 現リリースから、TopLinkはSun ORBに対するサポートを提供します（「CORBAコーディネート・キャッシュ」を参照）。
オブジェクトが変更されたときにコーディネート・キャッシュが何をブロードキャストするかを決定するために使用する同期方法を構成できます。これは、プロジェクト・レベル（「プロジェクト・レベルでのキャッシュ・コーディネーション変更伝播の構成」を参照）またはディスクリプタ・レベル（「ディスクリプタ・レベルでのキャッシュ・コーディネーションの変更伝播の構成」を参照）で次のように構成できます。
変更済オブジェクトの無効化: 他のすべてのセッションでオブジェクトを無効としてマークする、オブジェクト無効化を伝播します。これにより、他のセッションは次回このオブジェクトを読み取るときに、セッションのキャッシュをデータ・ソースにより更新する必要があることがわかります。この同期方法の使用をお薦めします。
変更の同期化: 変更された各属性を含んだ変更通知を伝播します。
変更および新規オブジェクトの同期化: 変更された各属性を含んだ変更通知を伝播します。新規オブジェクトの場合、オブジェクト作成を、新規インスタンスのすべての属性とともに伝播します。
この項では、アプリケーション・アーキテクチャでのTopLinkロック・オプションの使用方法を決定する際に必要となる選択について説明します。同時システムでは必ずロック・ポリシーを使用することをお薦めします（「ロック・ポリシーの構成」を参照）。
これらの選択については、次のようにまとめることができます。
3層アプリケーションを作成している場合、そのアーキテクチャにロックの使用方法が影響を受けることに留意してください（「3層アプリケーションでのロック」を参照）。
詳細は、「ディスクリプタとロックの概要」を参照してください。
TopLinkオプティミスティック・ロックの使用をお薦めします。オプティミスティック・ロックを使用した場合、すべてのユーザーにデータへの読取りアクセス権限があります。ユーザーが変更を書き込もうとすると、アプリケーションにより、ユーザーがデータを読み取ってから、そのデータが変更されていないかが確認されます。
バージョン（「オプティミスティック・バージョン・ロック・ポリシー」を参照）またはフィールド（「オプティミスティック・フィールド・ロック・ポリシー」を参照）のロック・ポリシーを使用できます。バージョン・ロック・ポリシーの使用をお薦めします。
ペシミスティック・ロックを使用した場合は、データを更新する目的でそのデータにアクセスする最初のユーザーが、更新を完了するまでデータをロックします。このアプローチの短所は、並行性が損われること、デッドロックになる可能性があることです。
問合せレベルでのペシミスティック・ロック・サポートの使用を検討してください（「名前付き問合せのオプションの構成」を参照）。
CMPを使用している場合は、Beanレベルのペシミスティック・ロック・サポートの使用をお薦めします（「名前付き問合せのオプションの構成」を参照）。
Oracle TopLinkでは、クラスを永続化するには、そのクラスが一定の最低要件を満たしている必要があります。これに対して、TopLinkでは、大部分の要件を満たすための代替方法も用意しています。TopLinkは、オブジェクト・モデルへの介入を最小限にできるメタデータ・アーキテクチャを使用した、非介入型アプローチを使用します。
この項では、次の内容について説明します。
永続層コンポーネントは、TopLink Workbenchからメタデータとして生成するか（「TopLinkメタデータの概要」を参照）、またはJavaクラスとして表現することができます。
必要なメタデータを作成（XMLとして保存）するにはTopLink Workbenchを使用することをお薦めします。project.xmlおよびsessions.xmlファイルを容易にエクスポートおよび更新できます。これにより、プロジェクトを変更するたびにJavaコードを再生成および再コンパイルする必要がなくなり、開発コストが削減されます。TopLink Workbenchを使用して、独自のアプリケーション・クラスと必要な修正メソッドに関してのみ、Javaコードを記述します。project.xmlおよびsessions.xmlファイルのXML構造の詳細は、<TOPLINK_HOME>\config\xsdsディレクトリの該当するXMLスキーマ（XSD）を参照してください。
Javaコードを使用するには、project、login、platform、descriptorsおよびmappingsなど、TopLinkプロジェクトの各要素に関して、コードを手動で記述する必要があります。アプリケーションがモデルベースであり、コード生成に強く依存する場合は、TopLink Workbenchを使用した方が効率的です。作成しているプロジェクトのタイプに応じて、TopLink Workbenchはプロジェクト、表およびモデル・ソース用にJavaコードをエクスポートできます（「プロジェクト情報のエクスポート」を参照）。
次の要件は、プレーンJavaオブジェクトに適用されます。
|
注意: コンテナ管理の永続性を備えたEJB 2.0エンティティBeanの場合、Beanの要件はEJB 2.0仕様に定義されています。コンテナ管理の永続性を備えたEJB 2.1エンティティBeanの場合、Beanの要件はEJB 2.1仕様に定義されています。 |
privateまたはprotected属性への直接アクセスを使用することができます。直接アクセスおよびメソッド・アクセスの詳細は、「メソッド・アクセスの構成」を参照してください。
非透過インダイレクションを使用する場合、属性は、オリジナルの属性タイプではなく、ValueHolderInterfaceタイプにする必要があります。ValueHolderは、参照オブジェクトを、必要となるまではインスタンス化しません。
TopLinkは、任意のコレクション・マッピングに対して、Collection、List、SetおよびMapの属性タイプの透過インダイレクションを提供します。透過インダイレクションの使用には、ValueHolderInterfaceまたはその他のオブジェクト・モデル要件を使用する必要はありません。
インダイレクションと透過インダイレクションの詳細は、「インダイレクション」を参照してください。
通常、TopLink永続層には次のコンポーネントが含まれます。
TopLinkアプリケーションのメタデータ・モデルは、TopLinkのプロジェクトに基づいています。プロジェクトは、ディスクリプタ、マッピングおよびランタイム機能をカスタマイズする各種ポリシーで構成されています。セッションからプロジェクトを参照することにより、このマッピングと構成情報を特定のデータ・ソースとアプリケーションに関連付けます。
詳細は、次を参照してください。
セッションは、クライアント・アプリケーションとTopLinkとの間のプライマリ・インタフェースで、基礎となるデータ・ソースへの接続を表します。
TopLinkには、いくつかの異なるセッション・タイプが用意されており（第72章「TopLinkセッションの概要」を参照）、各タイプは様々な設計要件およびアーキテクチャについて最適化されています。最も一般的に使用されるセッションは、サーバー・セッションです。これは、クライアントがサーバー上でクライアント・セッションを介してアクセスするセッションです。サーバー・セッションは、共有キャッシュおよび共有接続リソースを提供します。セッション・メタデータを使用してセッションを定義します。
CMPプロジェクトの場合、TopLinkランタイムは、セッションを内部的に作成して使用しますが、アプリケーションがこのセッションを直接取得したり使用することはありません。使用するアプリケーション・サーバーに応じて、この内部セッションに対するパラメータのいくつかを指定できます。
詳細は、次を参照してください。
デフォルトでは、TopLinkセッションはオブジェクト・アイデンティティを保証するオブジェクトレベルのキャッシュを提供し、アプリケーションがデータ・ソースにアクセスする回数を減らしてパフォーマンスを向上します。TopLinkは、ロック、リフレッシュ、無効化、分離およびコーディネーションなどの、様々なキャッシュ・オプションを提供します。キャッシュ・コーディネーションを使用して、デプロイされたアプリケーションの他のインスタンスと変更を同期化するようにTopLinkを構成できます。ほとんどのキャッシュ・オプションは、セッション・レベルで構成します。また、問合せ単位またはディスクリプタでキャッシュ・オプションを構成して、参照クラスのすべての問合せに適用されるようにできます。
詳細は、第87章「キャッシュの概要」を参照してください。
TopLinkには、いくつかのオブジェクトおよびデータ問合せタイプが用意されており、問合せ選択条件に対して次のような柔軟なオプションが提供されています。
TopLinkの式
EJB問合せ言語（QL）
SQL
ストアド・プロシージャ
例による問合せ
これらのオプションを使用して、あらゆるタイプの問合せを作成できます。事前定義問合せを使用してアプリケーション問合せを定義することをお薦めします。事前定義問合せは、プロジェクトのメタデータ内に保持され、名前で参照されます。これにより、アプリケーション開発は簡単になり、問合せはカプセル化されてメンテナンス・コストが軽減します。
エンティティBeanを使用する場合は、（他のTopLink問合せオプションとともに）EJB QLを使用すると、ファインダを完全にコーディングできます。これにより、アプリケーションをJ2EE仕様に準拠させることができます。
アーキテクチャまたは永続エンティティのタイプに関係なく、あらゆる問合せオプションを自由に使用できます。TopLink Workbenchには、問合せを定義するための最も簡単な方法が用意されています。また、TopLink APIを使用してコードで問合せを作成することもできます。
詳細は、第93章「TopLink問合せの概要」および第95章「TopLinkの式の概要」を参照してください。
TopLinkには、作業ユニットという特定のトランザクション・セッションを使用して、基礎となるデータベースおよびスキーマから分離されたトランザクション・コードを記述するための機能が用意されています。
作業ユニットは、トランザクション内で行われた変更を、その変更がデータベースに正常にコミットされるまで、他のスレッドから分離します。その他のトランザクション・メカニズムとは異なり、作業ユニットはトランザクション内のオブジェクトに対する変更、変更の順序および他のTopLinkのキャッシュを無効にする可能性がある変更を自動的に管理します。作業ユニットは、最小のチェンジ・セットを計算し、参照整合性規則に準拠してデッドロックを回避するようにデータベース・コールを順序付けし、変更されたオブジェクトを共有キャッシュにマージして、これらの問題を管理します。クラスタ化環境では、作業ユニットはコーディネート・キャッシュ内の他のサーバーと変更を同期化することもできます。
アプリケーションがエンティティBeanを使用する場合は、開発者は直接作業ユニットAPIにアクセスしませんが、その機能の利点を活用できます。TopLinkランタイムとJ2EEコンテナ間の統合により、自動的に作業ユニットが使用されるので、アプリケーションが享受できる利点にき損はありません。
詳細は、第93章「TopLink問合せの概要」を参照してください。
実行時に、アプリケーションはTopLinkメタデータを使用します（「TopLinkメタデータの概要」を参照）。
非CMPプロジェクトの場合、アプリケーションは、実行時にセッション・マネージャを使用してsession.xmlファイルをロードします（第75章「実行時のセッションの取得と使用」を参照）。session.xmlファイルには、マッピング・メタデータproject.xmlファイルへの参照が含まれています。アプリケーションは、セッションを使用して、TopLinkランタイムとproject.xmlマッピング・メタデータにアクセスします。
CMPプロジェクトの場合、必要なメタデータは、アプリケーションをデプロイするJ2EEアプリケーション・サーバーによって異なります（「デプロイ用TopLinkファイルの作成」を参照）。すべてのアプリケーション・サーバーは、ejb-jar.xmlとTopLinkプロジェクトXMLファイルを必要とします。セッション構成は、各J2EEアプリケーション・サーバーに依存します。
アプリケーションのパッケージ化（JavaまたはJ2EEのホスト環境にデプロイするため）は、TopLinkの使用方法および構成方法に影響します。たとえば、開発者はJ2EEアプリケーションをEARファイルにパッケージします。EARファイル内では、永続エンティティをWARとJAR内にパッケージする方法がいくつかあります。開発者によるTopLinkの構成方法は、部分的に、アプリケーションのパッケージ方法およびホスト・アプリケーション・サーバーのクラス・ローダーの使用方法に依存します。
この項では、TopLinkの観点からパッケージ化とデプロイについて説明します。ただし、アプリケーションをJ2EEコンテナにデプロイする場合、TopLinkでのコンテナ・サポートが有効になるようにアプリケーションの要素を構成する必要があります。
この項では、次の内容について説明します。
詳細は、第III部「TopLinkアプリケーションのデプロイ」を参照してください。
TopLinkのデプロイ方法では、アプリケーション・ファイルをJARファイルやEARファイルなどの1つのファイルにパッケージ化します。この方法に従うと、ファイル管理をそれほど必要としない、クリーンな自己完結型のデプロイ・ファイルを作成できます。
これらのファイルを作成した後、プロジェクトをデプロイします。
TopLinkはJ2EEアプリケーションに不可欠ですが、多くの場合、クライアントは直接TopLinkと対話しません。そのかわりに、EJBコンテナのコールバックを経由してTopLink機能が間接的に起動されます。
このため、一般的なデプロイ・プロセスの手順は次のようになります。
Bean、クラス、データ・ソースなどのプロジェクトの要素を作成します。
TopLink Workbenchでアプリケーション・マッピングを定義します。
アプリケーション・デプロイ・ファイルを作成します。ファイルの作成には、TopLink Workbenchを使用します。
アプリケーションをパッケージ化してデプロイします。
クライアント・アプリケーションにコードを追加し、クライアント・アプリケーションがTopLinkアプリケーションにアクセスできるようにします。
TopLinkには、パフォーマンスを最適化するために次のような様々な機能が用意されています。
問合せの機能拡張
キャッシュのチューニング
複数サーバー構成への拡張
ほとんどの機能はディスクリプタまたはセッションで有効/無効を切り替えることができるため、グローバルなパフォーマンスの向上が可能になります。
TopLink EISを使用すると（「企業情報システム（EIS）での使用方法」を参照）、J2Cアダプタを使用してTopLinkアプリケーションをレガシー・データ・ソースと統合できます。これは、非標準のシステムに対応するようTopLinkアプリケーションをカスタマイズするための最も効率的な方法です。
TopLink XMLを使用すると（「XMLでの使用方法」を参照）、Webサービスを使用してTopLinkアプリケーションをレガシー・データ・ソースと統合できます。
TopLInkの最適化とカスタマイズの詳細は、第IV部「TopLinkアプリケーションの最適化およびカスタマイズ」を参照してください。
開発およびデプロイを含むTopLinkアプリケーションのすべての点に関するトラブルシューティングの詳細は、第V部「TopLinkアプリケーションのトラブルシューティング」を参照してください。
この項では、リレーショナル・マッピングについて簡単に説明し、オブジェクト・モデリングとリレーショナル・モデリングへの手引きとなる重要な情報および制限が提供されます。この情報は、TopLinkアプリケーションを作成するときに役立ちます。
この項では、次の内容について説明します。
これらの項には、これらの機能についての追加詳細が含まれており、TopLinkによるこれらの機能の実装および使用方法の説明があります。
オブジェクト・モデリングとは、アプリケーション・オブジェクトを表現するJavaクラスを設計することです。TopLinkを使用すると、自分で選んだ統合開発環境（IDE）かまたはUnified Modeling Language（UML）モデリング・ツールを使用して、アプリケーション・オブジェクト・モデルを定義および作成できます。
TopLinkデータベース・セッションにディスクリプタを登録するクラスは、すべて永続クラスと呼ばれます。TopLinkでは、永続クラスは、データベースに格納されるあらゆるprivateまたはprotected属性に対してpublicアクセッサ・メソッドを提供する必要はありません。詳細は、「永続クラス要件」を参照してください。
データ・ストレージ・スキーマとは、アプリケーションの永続データを編成するために実装する設計のことです。このスキーマは、永続データ自体を参照するのであって、実際のデータ・ソースを参照するのではありません（例、リレーショナル・データベースや非リレーショナル・レガシー・システム）。
TopLinkアプリケーション開発プロセスの設計フェーズで（「一般的な開発段階」を参照）、データ・ソースのクラスの実装方法を決定する必要があります。既存のデータ・ソース情報を統合する場合、クラスと既存データの関係を確認する必要があります。統合するレガシー情報がない場合は、各クラスを格納する方法を決定してから必要なスキーマを作成します。
また、必要な情報の作成には、TopLink Workbench（第4章を参照）またはデータベースのSchema Manager（第5章を参照）を使用することもできます。
オブジェクトを永続化する際、保存および取得の際に一意に識別するため、各オブジェクトにはアイデンティティが必要になります。オブジェクト・アイデンティティは、一般に一意の主キーを使用して実装されます。このキーは、各オブジェクトを識別し、参照を作成および管理するために、TopLinkによって内部的に使用されます。オブジェクト・アイデンティティが損われると、オブジェクト・モデルが破損することがあります。
Javaアプリケーションでは、メモリー内の各オブジェクトが1つのみのオブジェクト・インスタンスによって表される場合にオブジェクト・アイデンティティが維持されます。同じオブジェクトの複数取得は、同一オブジェクトの複数コピーを返すのではなく、同一オブジェクト・インスタンスへの参照を返します。
TopLinkは、複数アイデンティティ・マップをサポートして、オブジェクト・アイデンティティを保持します（コンポジット主キーを含む）。詳細は、「キャッシュ・タイプおよびオブジェクト・アイデンティティ」を参照してください。
TopLinkは、データ・ソースへのオブジェクトおよびBeanのマップ方法を記述するために、TopLink Workbenchによって生成されたメタデータを使用します（「TopLinkメタデータの概要」を参照）。このアプローチは、オブジェクト・モデルから永続性情報を分離します。開発者は自分の理想的なオブジェクト・モデルを自由に設計し、DBAは自分の理想的なスキーマを自由に設計します。
開発者は、TopLink Workbenchを使用して、マッピング情報を作成および管理します。実行時に、TopLinkはメタデータを使用して、アプリケーションが必要とするたびにシームレスおよび動的にデータ・ソースと対話します。
TopLinkは、オブジェクト・モデルに含まれる可能性のある様々なデータ・タイプと参照をサポートする、広範なマッピング階層を提供します。詳細は、第30章「マッピングの概要」を参照してください。
外部キーは、別の表内の一意のキー（通常は主キー）を参照する列の組合せです。主キーと同様、外部キーは任意の数のフィールドで、これらすべてが1つの単位として扱われます。外部キーと参照先の親である主キーは、フィールドの数およびタイプが同じである必要があります。
外部キーは、1つの表の1つ以上の列から別の表の1つ以上の列へのリレーションシップを表します。たとえば、すべてのEmployeeに属性addressがあり、この属性にAddress（独自のディスクリプタおよび表を所有）のインスタンスが含まれている場合、address属性に対する1対1マッピングにより、特定のEmployeeの住所を見つけるための外部キー情報が指定されます。
詳細は、「表およびフィールド参照の構成（外部キーおよびターゲット外部キー）」を参照してください。
オブジェクト指向システムでは、クラスを、他のクラスに基づいて定義できます。たとえば、オートバイ、セダン、バンはすべて車両タイプです。それぞれの車両タイプは、Vehicleクラスのサブクラスです。同様に、Vehicleクラスはそれぞれの特定の車両タイプのスーパークラスです。各サブクラスはそのスーパークラスから属性およびメソッドを継承します（これらにそのクラス独自の属性とメソッドを追加します）。
継承により、次のようなアプリケーションの利点が提供されます。
サブクラスを使用することにより、スーパークラスから提供された共通の要素をベースとして特殊化した動作を提供できます。継承を使用することで、スーパークラスのコードが何度も再利用できます。
汎用的な動作を定義する抽象スーパークラスの実装。この抽象スーパークラスは、動作を定義し一部実装できます。詳細については、特殊化したサブクラスを使用して完成します。
TopLinkによる継承の使用の詳細は、「子（ブランチまたはリーフ）クラス・ディスクリプタに関する継承の構成」および「サブクラスでの継承属性マッピングの構成」を参照してください。
同時クライアントを同時にログインさせるには、サーバーが各クライアント用に実行の専用スレッドを生成する必要があります。これは、J2EEアプリケーション・サーバーによって自動的に行われます。専用スレッドにより、各クライアントは他のクライアントの完了を待たずに作業できるようになります。TopLinkは、これらのスレッドがアイデンティティ・マップを変更するときやデータベース・トランザクションを実行する際、互いに干渉しないように保証します。TopLink UnitOfWorkクラスを使用して、独立したスレッド・セーフな方法でクライアントがトランザクションによる変更を行うことができます。作業ユニットは、変更するオブジェクトのクローンを管理することで、各クライアントの作業を他の同時クライアントおよびスレッドから分離します。作業ユニットとは、データベース・トランザクションとしてACID（Atomicity、Consistency、Isolation、Durability）トランザクション方針のすべてを維持する、オブジェクトレベルのトランザクション・メカニズムです。作業ユニットの詳細は、第97章「TopLinkトランザクションの概要」を参照してください。
TopLinkでは、オプティミスティックおよびペシミスティック・ロック方法が構成できるようにサポートされていて、TopLink並行性マネージャが使用するロックのタイプをカスタマイズできます。詳細は、「ディスクリプタとロックの概要」を参照してください。
TopLinkキャッシュは、データベースからオブジェクトとして返されたデータを将来の使用のために自動的に保存しておくことにより、アプリケーションのパフォーマンスを向上させます。このキャッシュにはいくつかの利点があります。
データベースから以前に読み取られたJavaオブジェクトを再利用することで、データベース・アクセスが最小限に抑えられます。
オブジェクトがキャッシュにすでに存在している場合、データベースへのSQLコールが最小限に抑えられます。
データベースへのネットワーク・アクセスが最小限に抑えられます。
キャッシュ・ポリシーはクラス単位またはBean単位に設定できます。
キャッシュのオプションおよび動作のベースを、Javaガベージ・コレクションにすることができます。
TopLinkには、複数のキャッシュ・ポリシーがサポートされているという高い柔軟性があります。開発者は、個々のアプリケーション・パフォーマンスに基づいて、パフォーマンスを最大限にするためにキャッシュを微調整できます。詳細は、第XVII部「キャッシュ」を参照してください。
TopLinkの永続性を実現するためのメタデータ・アーキテクチャによる非介入型アプローチ（「TopLinkメタデータの概要」を参照）とは、オブジェクト・モデルへの介入がほとんどないことを意味しています。
Javaオブジェクトを永続化する際、TopLinkでは次のいずれも不要です。
永続スーパークラスまたは永続インタフェースの実装
オブジェクト・モデルにおける必要なメソッドの保存、削除またはロード
特殊永続メソッド
オブジェクト・モデルへのソース・コードの生成またはラップ
コンテナ管理の永続性を備えたエンティティBeanを使用する際、TopLinkは、CMP仕様要件以外にはオブジェクト・モデルへの追加の介入を必要としません。
この非介入型アプローチの詳細は、「永続層の構築および使用」を参照してください。
インダイレクション・オブジェクトは、アプリケーション・オブジェクトのかわりとなるため、アプリケーション・オブジェクトは必要とされるまでデータベースから読み取られません。インダイレクションの使用により、TopLinkは関連オブジェクトに対する代用を作成できます。これにより、特にアプリケーションが取得したオブジェクトのみのコンテンツを必要とし、そのオブジェクトに関連するすべてのオブジェクトのコンテンツは必要としない場合に、パフォーマンスの大幅な向上が見られます。
インダイレクションを使用しないと、アプリケーションは永続オブジェクトを取得するたびに、そのオブジェクトによって参照されるすべてのオブジェクトも取得します。これは、アプリケーションによってはパフォーマンスの低下につながります。
|
注意: すべての場合にインダイレクションを使用することをお薦めします。 |
TopLinkは、プロキシ・インダイレクション、透過インダイレクションおよびValueHolderインダイレクションなど、いくつかのインダイレクション・モデルを提供します。TopLinkは、EJBに対するインダイレクション・サポートも提供します（「インダイレクションおよびEJB」を参照）。
詳細は、「インダイレクション」を参照してください。
TopLinkのメタデータは、アプリケーションの開発とデプロイされたランタイム環境の間の橋渡しをします。TopLink Workbenchを使用してメタデータを取り込み（「プロジェクト・メタデータの作成」および「セッション・メタデータの作成」を参照）、project.xmlやsessions.xmlなどのデプロイXMLファイルを使用してランタイム環境にメタデータを渡します。JavaおよびTopLink APIを使用してこれらのファイルを手動でコーディングすることもできますが、このアプローチはより多くの労力が必要になります。
メタデータは、デプロイXMLファイルにカプセル化されており、開発者は構成情報をランタイム環境に渡すことができます。ランタイム環境では、この情報を永続エンティティ（JavaオブジェクトまたはEJBエンティティBean）、およびTopLink APIを使用して記述されたコードとともに使用して、アプリケーションが完成します。
この項の内容は次のとおりです。
TopLinkメタデータ・アーキテクチャにより、次のような多くの重要な利点が提供されます。
ドメイン・モデル・オブジェクト内ではなく、XMLディスクリプタ内にマッピング情報を格納します。
メタデータを使用することにより、TopLinkはオブジェクト・モデルまたはデータベース・スキーマに介入しません。
開発者は、特定の設計を強引に通すことなく、必要に応じてオブジェクト・モデルを設計できるようになります。
DBAは、特定の設計を強引に通すことなく、必要に応じてデータベースを設計できるようになります。
コード生成（設計、実装、メンテナンスなどの重大な問題の原因になる可能性がある）に依存しません。
非介入型です。TopLinkに適合するようにオブジェクト・モデルまたはデータベース・スキーマを設計することを開発者に要求するのではなく、TopLinkメタデータ自らがオブジェクト・モデルおよびデータベース・スキーマに適応します。
TopLinkプロジェクトには、TopLinkランタイムがオブジェクトをデータ・ソースへマップするために使用するマッピング・メタデータが含まれています。プロジェクトは、TopLinkランタイムが使用するプライマリ・オブジェクトです。
この項では、プロジェクト・メタデータの最も重要な、次のような内容について説明します。
project.xmlメタデータの作成の詳細は、「project.xmlファイル」を参照してください。
TopLinkは、開発者がTopLink Workbenchで作成したディスクリプタとマッピングを使用して、アプリケーションの永続エンティティをデータベースにマップします。TopLink Workbenchは、次のプロジェクト開発へのアプローチをサポートします。
マッピング用のクラスと表のインポート
クラスのインポート、および表とマッピングの生成
表のインポート、およびクラスとマッピングの生成
クラス定義と表定義の作成
TopLink Workbenchでは、これらすべてのオプションをサポートします。最も一般的なソリューションは、Oracle JDeveloperのような統合開発環境（IDE）などの開発ツールまたはモデリング・ツールを使用して永続エンティティを開発すること、および適切なリレーショナル設計ツールを使用してリレーショナル・モデルを開発することです。その後、開発者はTopLink Workbenchを使用して、これら2つのモデルを関連付けるマッピングを作成します。
TopLink Workbenchには、アプリケーションの永続エンティティまたはリレーショナル・モデル・コンポーネントを生成するための機能がいくつか用意されていますが、これらのユーティリティの目的はアプリケーションのラウンドトリップ開発を完了することではなく、短期間の初期開発方法を支援することのみです。
詳細は、第23章「ディスクリプタの概要」および第30章「マッピングの概要」を参照してください。
修正メソッドにより、TopLink Workbenchによって現在サポートされていないTopLink機能を実装できます。ディスクリプタをロードした後に修正するJavaメソッドを記述し、TopLink Workbenchでこのメソッドをプロジェクト・メタデータに含めるように指定するだけです。TopLinkディスクリプタの修正メソッドの実装の詳細は、「修正メソッドの構成」を参照してください。
非CMPプロジェクトの場合、データ・ソースへのアクセスに必要な情報を指定するセッション・メタデータでセッション・ログインを構成します（「セッション・メタデータの作成」を参照）。
CMPプロジェクトの場合、プロジェクトにはデータ・ソースへのアクセスに必要な情報を指定するデプロイメント・ログインが含まれています。
詳細は、「プロジェクトおよびログイン」を参照してください。
TopLinkのセッションには、特定のproject.xmlファイルへの参照とデータ・ソースへのアクセスに必要な情報が含まれています。セッションは、TopLinkランタイムの機能にアクセスするためにアプリケーションが使用するプライマリ・オブジェクトです。
セッション・メタデータの作成およびアクセスを担当するエージェントは、CMPプロジェクトを作成するかどうかに応じて異なります。非CMPプロジェクトでは、アプリケーションは直接セッションにアクセスし、セッションを取得します（「CMP以外のアプリケーションおよびセッション・メタデータ」を参照）。CMPプロジェクトでは、TopLinkランタイムによって内部的に取得されたセッションに、アプリケーションが間接的にアクセスします（「CMPアプリケーションおよびセッション・メタデータ」を参照）。
project.xmlおよびsessions.xmlファイルは、デプロイしているアプリケーションのタイプに応じて異なる方法でデプロイ用にパッケージ化します。
詳細は、次を参照してください。
3層Webアプリケーション・アーキテクチャには、通常、JDBC接続を介したデータベースへのサーバー・サイドJavaアプリケーションの接続が含まれます（図2-3を参照）。このパターンでは、TopLinkは、いくつかのサーバー統合ポイントを所有できるJavaサーバー（J2EEサーバーまたはカスタム・サーバー）内に存在します。アプリケーションでは、サーブレット、Javaクライアント、汎用クライアントなどのWebクライアントを、XMLまたはCommon Object Request Broker Architecture（CORBA）を使用してサポートできます。
3層アプリケーションは、TopLinkがJavaサーバー（J2EEサーバーまたはカスタム・サーバーのいずれか）内に存在する、一般的なアーキテクチャです。このアーキテクチャでは、サーバー・セッションにより、JDBC接続および共有オブジェクト・キャッシュへの共有アクセスがクライアントに与えられます。単一のJVM上に存在するため、このアーキテクチャはシンプルで、簡単に拡張できます。このアーキテクチャにおけるTopLinkの永続エンティティは、通常、Javaオブジェクトです。
このアーキテクチャでは、多くの場合、Webベースのアプリケーションをサポートします。その場合のクライアント・アプリケーションはWebクライアント、Javaクライアントまたはサーバー・コンポーネントです。
すべての3層アプリケーションがWebベースとはかぎりませんが、このアーキテクチャは分散Webアプリケーションに最適です。また、WebアプリケーションでEJBを使用することも一般的ですが、このTopLinkのアーキテクチャでは使用しません。
3層アーキテクチャの実装例には、次のものがあります。
Model-View-Controllerモデル2のアーキテクチャ設計パターン。J2EEコンテナで稼働し、TopLinkを使用してデータにアクセスするサーブレットおよびJSPがあり、EJBはありません。
SwingまたはAbstract Window Toolkit（AWT）クライアント。RMIを介してサーバー・サイドJavaアプリケーションに接続し、アプリケーション・サーバーまたはコンテナはありません。
3層Webアプリケーション・アーキテクチャには、次のような利点があります。
高いパフォーマンスの軽量永続オブジェクト
デプロイ・プラットフォームおよび構成における高い柔軟性
このアーキテクチャの短所は、EJBほど標準的ではないことです。
TopLinkには、リモート・セッションと呼ばれるセッション・タイプがあります。このセッションは、フル・セッションAPIを提供し、独自のキャッシュがありますが、TopLinkサーバーではなくクライアント・システム上に存在します。通信は、RMIまたはRMI-Internet Inter-Object Request Broker Protocol（IIOP）を使用するように構成できます。
リモート・セッション操作には、対応するクライアント・セッションがサーバー上に必要です。
これは、クライアント層からサーバー層へのアクセスを簡略化したい開発者にとっては優れたオプションですが、クライアント・セッションの使用に比べてスケーラビリティに欠け、サーバー側の動作を簡単に変更できません。
詳細は、「リモート・セッション」を参照してください。
ステートレス・クライアントを使用した3層アプリケーションには、次のような技術的な問題がいくつかあります。
ステートレス環境でのトランザクション管理
一般的な設計では、単一の作業ユニット（トランザクション・セッション）内でクライアント・リクエストを区切ります。ステートレス環境では、このことがプレゼンテーション層の設計方法に影響する場合があります。たとえば、クライアントがトランザクションの情報を収集するために複数のページを必要とする場合、プレゼンテーション層は、アプリケーションが変更またはリクエストの一式を収集するまで、情報をページ間で保有する必要があります。その時点で、プレゼンテーション層はデータベースを変更するために作業ユニットを起動します。
ステートレス環境でのオプティミスティック・ロック
ステートレス環境では、期限切れの（失効した）データを処理しないよう、特に注意する必要があります。失効したデータを処理しないための一般的な方法は、オプティミスティック・ロックを実装し、オプティミスティック・ロックの値をオブジェクトに格納することです。
この方法は、ステートレス・アプリケーションがオブジェクトをシリアライズする場合、またはオブジェクトの内容を代替形式でクライアントに送信する場合には、十分注意して行う必要があります。これらの場合、オプティミスティック・ロックの値を編集ページのHTTPコンテンツとしてクライアントに転送します。次に、任意の書込みトランザクションの戻り値を使用して、クライアントが処理を実行しているときに、データが変更されていないことを確認する必要があります。
ロックの詳細は、「ロック・ポリシーの構成」を参照してください。
外部JDBCプール
デフォルトでは、TopLinkは独自の接続プールを管理します。ホスト・アプリケーション・サーバーによって提供される接続プールを使用するようにTopLinkを構成することもできます。この機能は、共有接続プールの場合に有効です。また、JTA/JTSの統合には必須です（「外部接続プーリングの構成」を参照）。
JTA/JTSの統合
JTAおよびJTSは、標準的なJavaコンポーネントで、これにより、セッションは分散トランザクションにかかわることができます。アーキテクチャでセッションBeanを使用するためにJTA/JTSを使用するよう、TopLinkを構成する必要があります（「作業ユニットと外部トランザクション・サービスの統合」を参照）。
キャッシュ・コーディネーション
複数のサーバーを使用してアプリケーションを拡張することを選択する場合、TopLinkキャッシュ・コーディネーションが必要になることがあります（第87章「キャッシュの概要」を参照）。
2層アプリケーションには、通常、TopLinkを介して直接データベースに接続するJavaクライアントが含まれています。2層アーキテクチャは、デプロイが制限された複雑なユーザー・インタフェースでは最も一般的です。データベース・セッションにより、2層アプリケーションに対するTopLinkのサポートが提供されます。
詳細は、第72章「TopLinkセッションの概要」を参照してください。
2層アーキテクチャは、TopLinkアプリケーションの最もシンプルなパターンですが、各クライアント・アプリケーションに独自のセッションが必要となるため、最も制限的でもあります。そのため、2層アプリケーションは、他のアーキテクチャほど簡単に拡張できません。
2層アプリケーションは、多くの場合、データベースに直接アクセスするユーザー・インタフェースとして実装されます（図2-4を参照）。また、非インタフェース処理エンジンにもなります。どちらの場合でも、2層モデルは3層モデルほど一般的ではありません。
TopLinkを使用した効率的な2層（クライアント/サーバー）アーキテクチャの主な要素は次のとおりです。
クライアントからデータベースへの最小限の専用接続
独立したオブジェクト・キャッシュ
2層設計の利点は、その単純さです。2層化されたアーキテクチャを作成するTopLinkのデータベース・セッションは、すべてのTopLinkの機能を1つのセッション・タイプで提供するため、2層アーキテクチャの構築および使用は単純になります。
2層アーキテクチャの最も重要な制限は、各クライアントに独自のデータベース・セッションが必要であるため、スケーラブルではないことです。
多層Webアプリケーションが最新の傾向であり、2層アーキテクチャは本番環境では一般的ではありませんが、それでも実用的ではあります。2層システムには共有キャッシュがないため、アプリケーションの複数のインスタンスを実行する場合に、失効したデータに遭遇するリスクがあります。このリスクは、個々のデータベース・セッション数が多くなるにつれて大きくなります。
この問題を最小限に抑えるために、TopLinkでは、いくつかのデータ・ロック方法をサポートしています。これらのロック方法には、ペシミスティック・ロックおよびオプティミスティック・ロックのいくつかのバリエーションがあります。詳細は、「ロック・ポリシーの構成」を参照してください。
このアーキテクチャは、アプリケーション層へのアクセスをラップするEJBセッションBeanを加えて3層パターンを拡張したものです。セッションBeanは、アプリケーション操作へのパブリックなAPIアクセスを提供するため、プレゼンテーション層とアプリケーション層を分けることができます。また、このアーキテクチャにより、J2EEコンテナ内でセッションBeanを利用することが可能になります。このタイプのアーキテクチャには、通常、JTA統合およびクライアントに対するデータのシリアライズが含まれます。
3層アーキテクチャに対する一般的な拡張は、セッションBeanとTopLink管理の永続Javaオブジェクトを組み合せることです。結果のアプリケーションには、TopLinkの3層アーキテクチャ上のセッションBeanおよびJavaオブジェクトが含まれます（図2-5を参照）。
3層アーキテクチャは、サーバー・セッションを作成し、それをアプリケーションのセッションBean間で共有します。セッションBeanがTopLinkのセッションにアクセスする必要がある場合、Beanは共有サーバー・セッションからクライアント・セッションを取得します。このアーキテクチャの主な特徴は、次のとおりです。
セッションBeanはトランザクションを区切ります。
JTAシステムおよび関連の接続プールと連携するようにTopLinkを構成してください。
クライアント側で永続オブジェクトにアクセスすると、そのオブジェクトはシリアライズされます。
これらのオブジェクトが再度サーバー側に出現するときに、適切にキャッシュにマージされアイデンティティが保持されるようにしてください。
EJBセッションBeanファサード・アーキテクチャの実装例には、Model-View-Controllerモデル2のアーキテクチャ設計パターンがあります。このパターンはサーブレットおよびJSPを使用してJ2EEコンテナで稼働し、EJBを使用せずTopLink対応のセッションBeanを使用してデータにアクセスします。
EJBセッションBeanファサード・アーキテクチャは、永続Javaオブジェクトのパフォーマンスと、標準化されたクライアント開発およびサーバーのスケーラビリティに関するEJBの利点の両方を効率よく兼ね備えた一般的な設計です。次のような利点があります。
EJBエンティティBeanアプリケーションよりも小さいオーバーヘッド:
TopLinkでは、プロジェクト、ディスクリプタおよびログイン情報へのアクセスをアプリケーションのBean間で共有します。
その他のサーバーとの将来的な互換性:
この設計は、ログインおよびEJBサーバー固有の情報をBeanと切り離すため、大規模な記録または再作成をしなくても、アプリケーション・サーバー間でアプリケーションを移植できます。
共有リード・キャッシュ:
この設計は、オブジェクトを読み取るために共有キャッシュを提供することで効率性を高めることができます。
このモデルの主な短所は、永続モデルをクライアントへ転送する必要があることです。モデルに複雑なオブジェクト・グラフがインダイレクションとともに含まれる場合、継承、インダイレクションおよびリレーションシップについて多くの問題が発生する可能性があります。
継承、インダイレクションおよびリレーションシップの管理の詳細は、第IX部「マッピング」を参照してください。
セッションBeanはプロセス、オペレーションまたはサービスなどをモデル化しますが、永続エンティティではありません。ただし、セッションBeanは永続性のメカニズムを使用して、モデル化したサービスを実行します。
セッションBeanモデルでは、クライアント・アプリケーションはセッションBeanに対してメソッドを起動し、次にオペレーションをTopLink対応のJavaオブジェクトに対して実行します。セッションBeanは、TopLink関連のオペレーションすべてをクライアントのかわりに実行します。
EJB仕様では、セッションBeanをステートレスまたはステートフルとして説明しています。
ステートフルBeanは、クライアントとの対話状態を保持します。つまり、特定のクライアントによって発行されたメソッド・コール間で情報を保持します。これにより、クライアントは複数のメソッド・コールを使用して永続オブジェクトを操作できます。
ステートレスBeanは、メソッド・コール間でデータを保持しません。クライアントがステートレス・セッションBeanと対話する場合、単一のメソッド・コール内ですべてのオブジェクト操作を完了する必要があります。
アプリケーションは、TopLinkのクライアント・セッションまたはデータベース・セッションで、ステートフルとステートレスの両方のセッションBeanを使用できます。TopLinkのセッションでセッションBeanを使用する場合、使用されるBeanのタイプがセッションとの対話方法に影響します。
ステートレス・セッションBeanとTopLinkのセッション
ステートレスBeanは、クライアントからのメソッド・コール間で情報を保存しません。そのため、クライアントのメソッド・コールのたびに、セッションへのBeanの接続を再度確立します。TopLinkを介したメソッド・コールはそれぞれクライアント・セッションを取得し、適切なコールを行い、クライアント・セッションへの参照を解放します。
ステートフル・セッションBeanとTopLinkのセッション
EJBサーバーの構成には、Beanの管理方法に影響する設定、つまりパフォーマンスの向上、メモリーのフットプリントの制限、またはBeanの最大数の設定を目的とした設定が含まれています。ステートフルBeanを使用する場合、これらの設定のいずれかを満たすために、サーバーはTopLink対応のステートフル・セッションBeanを、コール間でJVMメモリー領域から出して非アクティブ化することがあります。その後、サーバーは必要に応じてBeanを再度アクティブ化し、メモリーに戻します。
この動作は、TopLinkのセッション・インスタンスが非アクティブ化後に残存しないため、非常に重要です。セッションをメソッド・コール間で維持するには、非アクティブ化処理時にセッションを解放し、Beanを再度アクティブ化する際に再取得します。
外部JDBCプール
デフォルトでは、TopLinkは独自の接続プールを管理します。セッションBeanアーキテクチャの場合、ホスト・アプリケーション・サーバーによって提供される接続プールを使用するようにTopLinkを構成する必要があります。この機能は、共有接続プールの場合に有効です。また、JTA/JTSの統合には必須です（「外部接続プーリングの構成」を参照）。
JTA/JTSの統合
JTAおよびJTSは、標準的なJavaコンポーネントで、これにより、セッションは分散トランザクションにかかわることができます。アーキテクチャでセッションBeanを使用するためにJTA/JTSを使用するよう、TopLinkを構成する必要があります（「作業ユニットと外部トランザクション・サービスの統合」を参照）。
キャッシュ・コーディネーション
複数のサーバーを使用してアプリケーションを拡張することを選択する場合、TopLinkキャッシュ・コーディネーションが必要になることがあります（「キャッシュ・コーディネーションの概要」を参照）。
作業ユニットを使用して、クライアント・アプリケーションでデータベース内のオブジェクトを変更できます。作業ユニットのマージ機能では、マッピングを採用して、シリアライズされたオブジェクトから作業ユニットに値をコピーし、変更を計算します。詳細は、「作業コピーのクローンでの変更内容のマージ」を参照してください。
CMPは、J2EEコンポーネント・モデルの構成要素であり、EJBコンテナがエンティティBeanを永続化するために使用するオブジェクト永続化サービスを提供します。CMPは、保証付きのポータブルなインタフェースにより、永続データへの分散型、トランザクション型でセキュアなアクセスを提供します。
このアーキテクチャは、3層アーキテクチャを拡張したもので、永続化メソッドの実装は、実行時にコンテナによって処理されます。Beanの開発者として、デプロイメント・ディスクリプタで指定する必要があるのは、コンテナがデータ・アクセスを処理する必要がある永続フィールドとリレーションシップ、およびデータベース・スキーマの抽象表現（オプション）のみです。
TopLink CMPは、TopLink永続フレームワークを拡張したものであり、様々なアプリケーション・サーバーのEJBコンテナへのカスタム統合を提供します（「アプリケーション・サーバーのサポート」を参照）。アプリケーション・サーバーの選択の詳細は、「ターゲット・プラットフォームの概要」を参照してください。TopLinkは、このアーキテクチャでEJBコンテナと連携し、EJBコンテナの永続マネージャを強化します（または、OC4Jの場合は、EJBコンテナの永続マネージャそのものになります）。
|
注意: OC4JおよびJava 1.5を使用している場合、TopLinkは、EJB 3.0の最終仕様で予定されている永続性機能のサブセットをサポートします。EJB 3.0サポートの詳細は、『Oracle Containers for J2EE Enterprise JavaBeans開発者ガイド』を参照してください。EJB 3.0の機能のサポートは、最終仕様の内容に応じて変更されることがあります。 |
TopLink CMP統合は非介入型です（図2-6を参照）。ランタイム統合とコード生成の組合せにより、コンテナはTopLinkを内部的に使用し、Beanユーザーは各自の標準のAPIを使用してコンテナ管理の永続性を備えたエンティティBeanと対話します。これにより、標準インタフェースならびにCMPおよびコンテナの能力を、TopLinkの柔軟性、パフォーマンスおよび生産性と結合することができます。
詳細は、次を参照してください。
コンテナ管理の永続性を備えたエンティティBeanの実装例には、Model-View-Controllerモデル2のアーキテクチャ設計パターンがあります。このパターンはJ2EEコンテナで稼働し、セッションBean、またはコンテナ管理の永続性を備えたエンティティBean（TopLinkによる機能強化版）のいずれかにアクセスするサーブレットおよびJSPがあります。
コンテナ管理の永続性を備えたエンティティBeanを使用する3層アーキテクチャには、次の長所があります。
コンテナ管理の永続性を備えたエンティティBeanは、キャッシュおよびマッピングのサポート、複数の表にわたるBeanデータの保存、コンポジット主キーならびにデータ変換など、TopLinkの高度な機能を利用できます。
データにアクセスするための標準的なメソッドがあり、これにより、開発者は標準化された再利用可能なビジネス・オブジェクトを作成できます。
粗粒度オブジェクトの作成に最適です。これらのオブジェクトは、TopLinkによって依存型の軽量標準Javaオブジェクトに関連付けられます（TopLinkは軽量依存型Javaオブジェクトへのコンテナ管理のリレーションシップも管理できます）。
TopLinkでは、参照されるオブジェクトおよびBeanの遅延初期化ができます（「インダイレクション」を参照）。
TopLinkには、Beanのトランザクション・コピーの機能があります。この機能により、個別のシリアライズに依存せずに、複数のクライアントによる同時アクセスが可能になります。
TopLinkには、高度な問合せ機能があり、動的問合せの他に、データ・ソース・レベルではなくBeanレベルでの問合せ定義、ならびに問合せおよびファインダの豊富なオプションを使用できます。
TopLinkにより、Beanおよびオブジェクト・アイデンティティが維持されます。
このアーキテクチャの短所は、コンテナ管理の永続性を備えた純粋なエンティティBeanアーキテクチャは一般管理コストが高くなる可能性があることです。これは、データ・モデルに複雑なリレーションシップを持った細粒度クラスが多数ある場合、特に当てはまります。
このアーキテクチャの主な技術的な問題は、コンポーネントと、統一されたまとまりのあるシステムとの統合にあります。たとえば、このアーキテクチャには、TopLinkとアプリケーション・サーバーまたはJ2EEコンテナとの特別な統合が必要です。
その他に、次のような問題があります。
デフォルトでは、TopLinkは独自の接続プールを管理します。ホスト・アプリケーション・サーバーによって提供される接続プールを使用するようにTopLinkを構成することもできます。この機能は、共有接続プールの場合に有効です。また、JTA/JTSの統合には必須です（「外部接続プーリングの構成」を参照）。
JTAおよびJTSは、標準的なJavaコンポーネントで、これにより、セッションは分散トランザクションにかかわることができます。アーキテクチャでセッションBeanを使用するためにJTA/JTSを使用するよう、TopLinkを構成する必要があります（「作業ユニットと外部トランザクション・サービスの統合」を参照）。
複数のサーバーを使用してアプリケーションを拡張することを選択する場合、TopLinkキャッシュ・コーディネーションが必要になることがあります（「キャッシュ・コーディネーションの概要」を参照）。
1対1または多対多リレーションシップが双方向である場合、リレーションシップの変更時にバックポインタを維持する必要があります。
TopLinkでは、2つのエンティティBean間のリレーションシップが自動的に維持されます。
バックポインタを手動で設定するには、次のいずれかを実行します。
リレーションシップを確立または変更したときにバックポインタが設定されるように、エンティティBeanをコーディングすることをお薦めします。
クライアントをコーディングする際、明示的にバックポインタを設定します。
バックポインタを設定するようにエンティティBeanをコーディングする場合は、クライアントがバックポインタを設定する必要はありません。これには、この設定の実装をBean内にカプセル化する利点があります。
1対多リレーションシップでは、ソースBeanが複数の依存ターゲット・オブジェクトを所有できます。たとえば、EmployeeBeanは、複数の依存PhoneNumberインスタンスを所有できます。従業員に新規の依存オブジェクト（この例ではPhoneNumber）を追加する際、そのオブジェクトの所有者（従業員）へのPhoneNumberインスタンスのバックポインタを設定する必要があります。エンティティBeanで1対多リレーションシップを設定するには、例2-1に示されているように、EmployeeBeanのコンテキストからローカル・オブジェクト参照を取得し、バックポインタを更新する必要があります。
例2-1 エンティティBeanでのバックポインタの設定
// obtain owner and phoneNumber owner = empHome.findByPrimaryKey(ownerId); phoneNumber = new PhoneNumber("cell", "613", "5551212"); // add phoneNumber to the phoneNumbers of the owner owner.addPhoneNumber(phoneNumber); // Maintain the relationship in the Employee's addPhoneNumber method public void addPhoneNumber(PhoneNumber newPhoneNumber) { // get, then set the back pointer to the owner Employee owner = (Employee)this.getEntityContext().getEJBLocalObject(); newPhoneNumber.setOwner(owner); // add new phone getPhoneNumbers().add(newPhoneNumber); }
詳細は、次を参照してください。
EJBとは異なり、TopLinkの依存永続オブジェクトは、クライアントとサーバーの間で双方向に送信されます。オブジェクトがシリアライズされる際には、そのオブジェクトのためにキャッシュがオブジェクト・アイデンティティを失う、または重複して同一のオブジェクトをキャッシュしようとするリスクが存在します。例2-2に示されているように、発生する可能性のある問題を回避するには、リレーションシップのコレクションに依存オブジェクトを追加する際に、Beanのsetterメソッドを使用します。これにより、TopLinkではキャッシュ内のオブジェクトのマージ処理が可能になります。
コレクションでは、通常、equalsメソッドを使用してオブジェクトを比較します。オブジェクトにEJBObjectオブジェクトのコレクションが含まれる場合、等価性はEJBコンテナ・コレクションで適切に処理されるため、オブジェクトの比較は不要です。
BMPはJ2EEコンポーネント・モデルの構成要素であり、これを使用して、Beanの開発者は、エンティティBeanクラスまたは自分が用意する1つ以上のヘルパー・クラスにエンティティBeanの永続データを直接実装できるようになります。
このアーキテクチャは、3層アーキテクチャを拡張したもので、永続データは、実装されたコードを使用してエンティティBean内でBean管理されています。クライアント・コードは、エンティティBeanインタフェースを介してデータにアクセスします。
TopLink BMPは、TopLink永続フレームワークを拡張したものであり、BMP開発の開始点となるベース・クラスBMPEntityBaseを提供します。このクラスは、3.0より前のEJB仕様に必要とされるすべてのメソッド（ejbPassivateを除く）を実装します。BMPEntityBaseをサブクラス化して、Bean管理の永続性を備えたTopLink対応のエンティティBeanを作成します。BMPEntityBaseクラスを使用するには、次のように行います。
アプリケーションに対してTopLinkセッションを作成します（第72章「TopLinkセッションの概要」を参照）。
Bean管理の永続性を備えたエンティティBeanを表すディスクリプタそれぞれにBMPWrapperPolicyを追加します。
このBMPWrapperPolicyは、TopLinkにエンティティBeanのリモート・オブジェクトを作成するための情報、およびリモート・オブジェクトからデータを抽出するための情報を提供します。
ホームおよびリモートのインタフェースを作成します。
デプロイメント・ディスクリプタを作成します（「TopLinkとアプリケーション・サーバーの統合」および「デプロイ用TopLinkファイルの作成」を参照）。
アプリケーションをパッケージ化します（「TopLinkアプリケーションのパッケージ化」を参照）。
Beanをデプロイします（「TopLinkアプリケーションのデプロイ」を参照）。
TopLinkセッションと作業ユニット機能を完全活用するための手段として、TopLinkにはBMPDataStoreクラスが用意されています。このクラスは、EJB必須の機能を単純なコールに変換するために使用します。
BMPDataStoreクラスは、LOADとSTORE、複数のファインダおよびREMOVE機能を実装します。BMPDataStoreクラスには、TopLinkセッションが必要です。セッション内では、デプロイされたBeanタイプごとにBMPDataStoreのインスタンスが1つ存在する必要があります。BMPDataStoreを作成する際に、Beanを永続化するためにBMPDataStoreで使用する必要があるセッションのセッション名および永続化されるBeanタイプのクラスを渡します。BMPDataStoreは、Beanタイプの各インスタンスで適切なstoreメソッドを使用できるようにグローバル・ロケーションに格納します。
TopLink BMPサポート（図2-7を参照）により、Bean管理の永続性を備えたエンティティBeanの標準インタフェースをTopLinkの柔軟性、パフォーマンスおよび生産性と組み合せることができます。
TopLinkではBMPがサポートされます。BMPサポートを使用するには、ホーム・インタフェースはoracle.toplink.ejb.EJB20Homeを継承する必要があります。BMPEntityBaseをコールするには、findAllメソッドがEJB 2.0バージョンのメソッドをコールする必要があります。これらのメソッドは、先頭にejb20が付いています。たとえば、EJB 2.0のfindAllメソッドは、ejb20FindAllとして表示されます。
ローカルBeanを使用するには、デフォルトのoracle.toplink.ejb.EJB20Homeのかわりに、oracle.toplink.ejb.EJB20LocalHome設定を使用します。oracle.toplink.ejb.BMPWrapperPolicy設定のかわりに、oracle.toplink.ejb.bmp.BMPLocalWrapperPolicy設定を使用します。
ローカル構成とリモート構成の両方に対応するには、次のことを確認します。
単一のインタフェースを持つBeanの場合、ディスクリプタの該当するラッパー・ポリシー（ローカルまたはリモート）を使用します。
Beanは、ローカルまたはリモートのインタフェースのいずれかとしてのみリレーションシップにかかわることができますが、両方はできません。
詳細は、次を参照してください。
Bean管理の永続性を備えたエンティティBeanの実装例には、Model-View-Controllerモデル2のアーキテクチャ設計パターンがあります。このパターンはJ2EEコンテナで稼働し、セッションBean、およびBean管理の永続性を備えたエンティティBean（TopLinkによる機能強化版）にアクセスするサーブレットおよびJSPがあります。
TopLinkの3層アーキテクチャを持つBMPを使用することには、次のような利点があります。
BMPメソッド・コールが簡略化されます。これらは、生成されるのではなく、抽象Beanクラスから継承できます。
TopLinkにより、BMPをより簡単に実装できます。
開発者は、データベースに依存しないコードをBeanのメソッドに実装できます。
このアーキテクチャでは、複合リレーションシップ、キャッシュ、オブジェクト・レベルの問合せと動的な問合せ、および作業ユニットなどの機能をサポートします。
BMPの主な短所は次のとおりです。
永続性のメカニズムをBeanコードで作成する必要があります。
CMPほど透過的または効率的ではありません。
TopLink専用のJavaオブジェクト・アプリケーションには、アプリケーション・サーバーからの同程度の独立性があります。
このアーキテクチャの主な技術的な問題は、コンポーネントと、統一されたまとまりのあるシステムとの統合にあります。たとえば、このアーキテクチャには、TopLinkとアプリケーション・サーバーまたはJ2EEコンテナとの特別な統合が必要です。
その他に、次のような問題があります。
デフォルトでは、TopLinkは独自の接続プールを管理します。ホスト・アプリケーション・サーバーによって提供される接続プールを使用するようにTopLinkを構成することもできます。この機能は、共有接続プールの場合に有効です。また、JTA/JTSの統合には必須です（「外部接続プーリングの構成」を参照）。
JTAおよびJTSは、標準的なJavaコンポーネントで、これにより、セッションは分散トランザクションにかかわることができます。アーキテクチャでセッションBeanを使用するためにJTA/JTSを使用するよう、TopLinkを構成する必要があります（「作業ユニットと外部トランザクション・サービスの統合」を参照）。
複数のサーバーを使用してアプリケーションを拡張することを選択する場合、TopLinkキャッシュ・コーディネーションが必要になることがあります（「キャッシュ・コーディネーションの概要」を参照）。
EJB 3.0仕様の一部であるJava Persistence API（JPA）は、Java永続性を提供するPOJOベースの軽量フレームワークです。JPAは、オブジェクト・リレーショナル・マッピングに重点を置いており、完全なオブジェクト・リレーショナル・マッピング仕様を含みます。この仕様では、Javaオブジェクトとリレーショナル・データベース間のマッピングを定義するJava言語のメタデータ注釈やXMLディスクリプタの使用がサポートされます。JPAによるオブジェクト・リレーショナル・マッピングは、完全にメタデータ駆動型です。JPAでは、静的問合せと動的問合せの両方で、SQLに似た問合せ言語がサポートされます。また、プラッガブルな永続性プロバイダの使用もサポートされます。
JPAには、次の概念が含まれます。
エンティティ: エンティティとなることができるのは、次の特徴を備えたアプリケーション定義の任意のオブジェクトです。
永続化することが可能です。
永続識別子を持ちます（永続識別子とは、エンティティ・インスタンスを一意に識別し、そのインスタンスを同じエンティティ・タイプの他のインスタンスから区別するキーです。エンティティは、データ・ストアにそのエンティティを表現するオブジェクトが存在する場合、永続識別子を持ちます）。
エンティティの永続性に関してトランザクション的であるという点で、一部トランザクション的です（エンティティは、トランザクション内で作成、更新および削除され、変更のデータベースへのコミット時にはトランザクションが必要です）。ただし、メモリー内エンティティは、変更を永続化することなく更新できます。
プリミティブ・オブジェクト、プリミティブ・ラッパー・オブジェクトまたは組込みオブジェクトではありません。エンティティは、単一の場所（表の行など）に通常格納される集約された状態のセットを保持する粒度の細かいオブジェクトであり、他のエンティティに対するリレーションシップを持ちます。
エンティティ・メタデータ: すべてのエンティティを記述します。メタデータは、注釈（Javaのプログラム要素に挿入するか、プログラム要素の前に配置できる特に定義されたタイプ）またはXML（ディスクリプタ）として表現することが可能です。
エンティティ・マネージャ: APIコールでエンティティに対する操作を実行できます。エンティティ・マネージャを使用してエンティティの作成、読取りまたは書込みを行うまで、エンティティは単に通常の非永続Javaオブジェクトにすぎません。エンティティ・マネージャがエンティティに対する参照を取得すると、そのエンティティはエンティティ・マネージャにより管理された状態となります。任意の時点におけるエンティティ・マネージャ内の管理エンティティ・インスタンスのセットは、永続コンテキストと呼ばれます。任意の時点で永続コンテキスト内に存在できるのは、同じ永続識別子を持つただ1つのJavaインスタンスのみです。
開発者は、特定タイプのオブジェクトの永続化または管理、特定のデータベースを対象とする読取りまたは書込み、および特定の永続性プロバイダによる実装が可能となるようエンティティ・マネージャを構成できます。永続性プロバイダにより、EntityManagerインタフェース実装、Query実装、SQL生成などのJPAの基盤となる実装エンジンが提供されます。
エンティティ・マネージャは、EntityManagerFactoryにより提供されます。エンティティ・マネージャの構成は、EntityManagerFactoryに依存しますが、永続性単位として個別に定義されます。永続性単位に名前を付けることで、各EntityManagerFactoryオブジェクトを区別できます。この方法により、特定のエンティティの操作にどの構成を使用するかをアプリケーションで制御できます。永続性単位を記述する構成は、persistence.xmlファイルで定義します。
次の説明により、JPAの概念間の関係を示します。
Persistenceは、1つ以上のEntityManagerFactoryオブジェクトを作成します。
各EntityManagerFactoryは、1つの永続性単位によって構成されます。
EntityManagerFactoryは、1つ以上のEntityManagerオブジェクトを作成します。
1つ以上のEntityManagerは、1つのPersistenceContextを管理します。
詳細は、次を参照してください。
http://www.oracle.com/technology/products/ias/toplink/jpa/index.html
『Oracle Containers for J2EE Enterprise JavaBeans開発者ガイド』
Bean管理の永続性を備えたエンティティBeanの実装例には、Model-View-Controllerモデル2のアーキテクチャ設計パターンがあります。このパターンはJava EEコンテナで稼働し、セッションBean、およびTopLinkベースのJPA永続性プロバイダを使用するEJB 3.0準拠のエンティティにアクセスするサーブレットおよびJSPがあります。
TopLink JPAエンティティを使用することには、次のような利点があります。
POJO永続性: JPAでは、永続オブジェクトはPOJOです。
オブジェクト・リレーショナル・マッピングは、完全にメタデータ駆動型です。
永続性APIは、永続オブジェクトとは別のレイヤーとして存在しており、永続オブジェクトに介入することはありません。
問合せフレームワークを使用すると、個々の外部キーやデータベース列を使用することなく、エンティティおよびリレーションシップ全体を問い合せることができます。また、メタデータの形式で静的に問合せを定義することや、作成時に問合せ基準を渡すことで動的に問合せを作成することができます。問合せにより、結果としてエンティティが返されます。
エンティティは移行可能です。オブジェクトは、あるJVMと別のJVM間を自由に移動でき、同時にアプリケーションで使用できます。
Java SE 5の注釈またはXML（あるいはその両方の組合せ）を使用して永続化機能を構成できます。また、デフォルトに従うことも可能です。
アプリケーションがコンテナ内で実行される場合、コンテナによりサポートや利便性が提供されます。ただし、同じアプリケーションをコンテナの外部で実行するよう構成することも可能です。
Webサービス・アーキテクチャは、3層アーキテクチャ（「3層アーキテクチャの概要」を参照）またはセッションBeanアーキテクチャ（「EJBセッションBeanファサード・アーキテクチャの概要」を参照）と似ていますが、Webサービス・アーキテクチャでは、セッションBeanを使用せず（または使用する他に）、Webサービスにビジネス・ロジック（サービス）をカプセル化します。Webサービス・アーキテクチャでは、クライアントがSOAPメッセージ（HTTP上のXML）を介してアプリケーションと通信します。
他のアーキテクチャの場合と同様に、TopLinkを使用して、リレーショナルまたはEISデータ・ソースへオブジェクトを永続化できます。なお、Webサービス・アーキテクチャでは、TopLinkを使用して、Webサービスで使用するXMLスキーマか、またはWebサービスのXMLシリアライザとして使用するXMLスキーマへ、オブジェクト・モデルをマッピングすることもできます。
Webサービス・アーキテクチャの実装例として、Webサービスを使用して、既存アプリケーションの一部をリモート・クライアント（通常は別のアプリケーション）にSOAPメッセージ経由で公開することができます。このアプリケーションでは、TopLink XMLを使用して、リクエストを容易にするためにXMLメッセージをJavaオブジェクトにアンマーシャリングし、クライアントへの送信用にJavaオブジェクトのレスポンスをXMLにマーシャリングすることができます。
Webサービス・アーキテクチャでのTopLinkの使用には、次を初めとする長所が多数あります。
XMLメッセージを既存のJavaオブジェクト・モデルにマップできます。
高度で複雑なマッピングのサポートを実現できます。
JAXB標準に準拠します。
スケーラブルで高パフォーマンスのソリューションを提供します。
短所として議論の余地があるのは、このソリューションが単純なRMIセッションBeanサービスに対して複雑であることです。
他のテクノロジと同様に、Webサービス・アーキテクチャでのTopLinkの使用にも技術上の課題があります。これらの技術上の課題は、ほとんどが特殊なケースに関連するものです。たとえば、Javaオブジェクトとスキーマの両方があるために、カスタム・シリアライザを実装する必要がある場合などです。
詳細は、次を参照してください。
JAX-RPC 1.1 Webサービスにおけるカスタム・シリアライザとしてのOracle TopLink: http://www.oracle.com/technology/products/ias/toplink/technical/tips/jaxRpc11/index.htm
