| Oracle Fusion Middleware Oracle TopLink開発者ガイド 11gリリース1（11.1.1） B56246-01 |
|
 戻る |
 次へ |
この章では、TopLinkアプリケーションの作成方法について説明します。推奨する開発プロセス、アーキテクチャ、テクノロジについても説明します。
この章の内容は次のとおりです。
TopLinkアプリケーションの設計を最適化するために、反復型の段階的な開発プロセスに従うことをお薦めします。TopLinkには、あらゆる開発ツールを使用できるという柔軟性があります。
この項では、次の推奨される開発プロセスについて説明します。
この項では、TopLinkアプリケーションの一般的な開発段階のそれぞれについて説明します。図2-1は、TopLink開発プロセスを示しています。
アプリケーションの設計（1）
アプリケーション要件を定義し、アーキテクチャを選択し、ターゲット・プラットフォームを決定します。詳細は、2.2項「TopLinkを使用するアプリケーションの設計」を参照してください。TopLinkはあらゆるアーキテクチャおよびあらゆるプラットフォームで使用できることを覚えておいてください。
アプリケーションを設計する際、そのアプリケーションに対するオブジェクト・モデルも作成する必要があります。詳細は、2.8項「オブジェクトの永続化」を参照してください。TopLinkを使用してオブジェクトをマップする前にオブジェクト・モデルを作成することが重要です。これは、誤ったモデルまたは急速に変化するモデルに対して永続マッピングを定義すると非常に面倒なことになるためです。
アプリケーションの開発（2、3、4）
Javaクラスを作成し、そのクラスがデータ・ソースによってどのように実装される必要があるかを決定します。レガシー・システムを使用する場合、クラスが既存データにどのように関連するかを決定します。統合するレガシー・データ・ソースがない場合は、データ・ソースに各クラスを格納する方法を決定し、必要なスキーマを作成します。または、TopLinkを使用して初期の表を作成することもできます。
Oracle JDeveloper TopLinkエディタまたはTopLink Workbenchを使用して、永続クラスに対するディスクリプタとマッピングを作成します。TopLinkセッションを使用して、永続クラスの操作（データの問合せおよび変更など）を行います。詳細は、第II部「TopLink開発ツールの概要」を参照してください。
1回の開発サイクルで、モデルのディスクリプタをすべて作成することは避けます。クラスの小さなサブセットから開始してください。それらのディスクリプタを作成およびテストしてから、段階的に新規のディスクリプタとリレーションシップを追加します。これにより、一般的な問題が設計全体にわたって拡散する前にこのような問題を捕捉できます。
データベース・セッションを使用するJavaコードを記述します。セッションは、データベース・オブジェクトの問合せおよびデータベースへのオブジェクトの書込みに使用します。詳細は、第87章「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の使用に関する質問を投稿して回答を得ることができます。次を参照してください。
アプリケーションを設計する際、どこでどのようにTopLinkを使用するかを選択する必要があります。TopLinkを使用して、いろいろなJavaサポートのプラットフォーム上で（2.2.2項「ターゲット・プラットフォーム」を参照）、永続化およびデータ・トランスフォーメーションを行う様々な機能を実行できます（2.2.1項「アプリケーション設計におけるTopLinkの使用方法」を参照）。アプリケーション・アーキテクチャを設計する際は、これらの機能があることを考慮してください（2.3項「TopLinkを使用するアーキテクチャの選択」を参照）。
この項では、TopLinkの基本的な使用方法について説明します。使用方法には次の種類があります。
TopLinkを使用すると、JDBCを使用してアクセスされる、SQLデータ・タイプをサポートするリレーショナル・データベースに、Javaオブジェクトを永続化できます。
詳細は、18.1.1項「リレーショナル・データベース用リレーショナル・プロジェクトの作成方法」を参照してください。
TopLinkを使用すると、オブジェクト・ストレージ用に特化されたデータ・タイプをサポートする、JDBCを使用してアクセスされるオブジェクト・リレーショナル・データ・タイプ・データベース（Oracle Databaseなど）に、Javaオブジェクトを永続化できます。
詳細は、18.1.2項「オブジェクト・リレーショナル・データ・タイプ・データベース用リレーショナル・プロジェクトの作成方法」を参照してください。
TopLinkを使用して、TopLinkのXMLタイプへ直接マッピングを使用したOracle XMLデータベースに、XML文書を永続化できます。
詳細は、第18章「リレーショナル・プロジェクトの概要」および27.4項「XMLタイプへ直接マッピング」を参照してください。
TopLinkでJCAアダプタを使用して、EISデータ・ソースにJavaオブジェクトを永続化できます。
このシナリオでは、JCAアダプタがEISとのインタラクションを受信することで、アプリケーションがEISデータ・ソースによって定義された操作を起動します。操作により、EISレコードが取得されたり返されます。TopLink EISディスクリプタとマッピングを使用して、JCAアダプタとEISデータ・ソースによってサポートされるEISレコード・タイプに、Javaオブジェクトを容易にマップできます。
この使用方法は、レガシー・データ・ソースに接続するアプリケーションでは一般的であり、Webサービスにも適用できます。
詳細は、第71章「EISプロジェクトの概要」を参照してください。
TopLinkで、XML文書およびJAXBをベースにしたXMLスキーマ（XSD）を使用して、インメモリーの非永続JavaオブジェクトをXMLにトランスフォーメーションできます。
TopLink JAXBコンパイラをXSDとともに使用して、JAXB固有の生成物（コンテンツと要素のインタフェース、実装クラス、オブジェクト・ファクトリ・クラスなど）とTopLink固有の生成物（セッション、プロジェクトXMLファイル、TopLink Workbenchプロジェクトなど）を両方とも生成できます。詳細は、47.1.1項「TopLinkによるJava Architecture for XML Binding（JAXB）のサポート」を参照してください。
この使用方法は、メッセージ機能やWebサービスを含んでいるため、多くのアプリケーションで利用されます。
詳細は、第47章「XMLプロジェクトの概要」を参照してください。
TopLinkでは、次のようなJavaを使用するすべてのエンタープライズ・アーキテクチャをサポートします。
Java EE
Spring
Java Webサーバー（Tomcatなど）
Javaクライアント（Java SE、Webブラウザなど）
サーバーのJavaプラットフォーム
開発者によるTopLinkの使用方法および構成方法は、ホストのJavaまたはJava EE環境にデプロイするための、特定のターゲット・プラットフォームでのアプリケーションのパッケージ化要件の影響を受けます。たとえば、Java EEアプリケーションをエンタープライズ・アーカイブ（EAR）ファイルにパッケージします。EARファイル内では、永続エンティティをWeb Archive（WAR）およびJava Archive（JAR）内にパッケージするための方法がいくつかあります。開発者によるTopLinkの構成方法は、部分的に、アプリケーションのパッケージ方法およびホスト・アプリケーション・サーバーのクラス・ローダーの使用方法に依存します。
さらに、TopLinkは様々なアプリケーション・サーバーに対してカスタムCMP統合を可能にします。
サポートされるアプリケーション・サーバーのバージョン、カスタム統合、構成要件の詳細は、第8章「TopLinkとアプリケーション・サーバーの統合」を参照してください。
この項では、TopLinkに適用されるアプリケーション・アーキテクチャの主な点をいくつか説明し、それぞれの点で利用可能な様々なオプションについて説明します。次の点について説明します。
この項では、アプリケーション・アーキテクチャでクライアントの機能とサーバーの機能の分離方法を決定する際に必要となる選択について説明します。
これらの選択については、次のようにまとめることができます。
Webクライアント
XML/Webサービス・クライアント
Java（ファット・）クライアント
3層アプリケーション・アーキテクチャをお薦めします。3層アーキテクチャの場合、EclipseLink JPAまたはサーバー・セッションとクライアント・セッション（87.3項「サーバーおよびクライアントのセッション」を参照）とTopLink作業ユニット（第113章「TopLinkトランザクションの概要」を参照）の使用をお薦めします。
詳細は、2.11項「3層アーキテクチャについて」を参照してください。
TopLinkは、Java EEのアプリケーション・アーキテクチャでもJava EE以外のアプリケーション・アーキテクチャでも使用できます。Java EEアプリケーション・アーキテクチャの使用をお薦めします。
Java EEアプリケーションの場合、外部接続プールを使用する必要があります（96.1.6.2項「外部接続プール」を参照）。JPAまたはCMP、EJBセッションBeanおよびJava Transaction API（JTA）統合（113.1.2.1項「JTAによって制御されるトランザクション」を参照）の使用を検討できます。
Java EE以外のアプリケーションの場合、内部接続プールを使用する必要があります（96.1.6.1項「内部接続プール」を参照）。この場合も、JPAの使用を検討できます。
3層アプリケーション・アーキテクチャでは、次のいずれかのタイプのクライアントを実装できます。
Webクライアント: Webクライアントの実装をお薦めします。
XML/Webサービス・クライアント: このクライアント・タイプの場合、TopLink XMLを使用できます（2.2.1.5項「XMLでの使用方法」を参照）。
Java（ファット・）クライアント: このクライアント・タイプの場合、サーバーとの通信手段を選択できます。
EJBセッションBean: 推奨アプローチです。デシリアライズされたオブジェクトのマージを処理するには、UnitOfWorkのmergeCloneメソッドの使用をお薦めします（115.5項「作業コピーのクローンでの変更内容のマージ」を参照）。このアプローチの短所は、アプリケーションがシリアライズを処理する必要があることです。深いオブジェクト・グラフはシリアライズしないようにしてください。インダイレクション（JPAでは遅延ロードとも呼ばれる）の使用をお薦めします（121.3項「インダイレクション（遅延ロード）の構成」を参照）。データ転送オブジェクト・パターンの使用も検討してください。
XML/Webサービス: TopLink XMLを使用します（2.2.1.5項「XMLでの使用方法」を参照）。
EJBエンティティBean: TopLink CMP統合またはBMPサポートを使用します。このアプローチの短所は、リモート・エンティティBeanが高いパフォーマンスやスケーラビリティを示さなくなることです。
RMI: TopLinkリモート・セッションの使用をお薦めします（87.9項「リモート・セッション」を参照）。このアプローチの短所は、リモート・セッションがステートフルであり、高いスケーラビリティを持たなくなることです。
2.3.2項「サービス層」も参照してください。
2層アプリケーション・アーキテクチャの場合、TopLinkデータベース・セッション（87.8項「データベース・セッション」を参照）とTopLink作業ユニット（第113章「TopLinkトランザクションの概要」を参照）の使用をお薦めします。このアーキテクチャの短所は、Web対応ではないことと、大規模なデプロイへのスケーラビリティを持たないことです。
詳細は、2.12項「2層アーキテクチャについて」を参照してください。
この項では、アプリケーションのビジネス・ロジック（またはサービス）のカプセル化方法を決定する際に必要となる選択について説明します。
これらの選択については、次のようにまとめることができます。
関連項目:
EJBセッションBeanの使用をお薦めします。
EJBセッションBeanの場合、JTA統合（113.1.2.1項「JTAによって制御されるトランザクション」を参照）と外部接続プール（96.1.6.2項「外部接続プール」を参照）を使用する必要があります。作業ユニットを取得する必要があります（115.13.1項「外部トランザクション・サービスを持つ作業ユニットの取得方法」を参照）。
詳細は、2.13項「EJBセッションBeanファサード・アーキテクチャについて」を参照してください。
ステートフル・セッションBeanを使用している場合、クライアント・セッションの参照を非アクティブ化できません。この場合、アクティブ化されたとき、またはリクエストごとに、クライアント・セッションを再取得する必要があります（87.2.4項「セッション・マネージャによる実行時のセッションの取得」を参照）。
ステートレス・セッションBeanを使用している場合、リクエストごとに新しいクライアント・セッションを取得する必要があります（87.2.4項「セッション・マネージャによる実行時のセッションの取得」を参照）。
EJBエンティティBeanのインタフェースにより、TopLinkの機能がクライアント・アプリケーション開発者から完全に隠されてしまうため、EJBエンティティBeanのアーキテクチャは他のTopLinkアーキテクチャとは若干異なります。
エンティティBeanは、ほとんどすべてのJava EEアプリケーションで使用できます。TopLinkにとって、アプリケーションでエンティティBeanがどのように使用されるかは重要ではありません。エンティティBeanがどのようにマップされ、実装されるかが、TopLinkにとって重要です。
コンテナ管理の永続性を備えたエンティティBeanの使用をお薦めします。この場合、アプリケーション・サーバーに対してTopLink CMP統合を使用する必要があります。TopLinkでサポートされるJava EEサーバーを使用しているかどうかを確認する必要があります（第8章「TopLinkとアプリケーション・サーバーの統合」を参照）。
詳細は、2.14項「CMPを使用するEJBエンティティBeanのアーキテクチャについて」を参照してください。
Bean管理の永続性を備えたエンティティBeanを使用している場合、TopLink BMP統合を使用する必要があります。このアーキテクチャの短所は、BMPアーキテクチャが制限的で、良好なパフォーマンスが示されない場合があることです。
詳細は、2.15項「BMPを使用するEJBエンティティBeanのアーキテクチャについて」を参照してください。
Java Persistence API（JPA）は、Java EEおよびJava SEアプリケーションの永続性のための仕様です。JPAでは、永続クラスはエンティティと呼ばれます。エンティティは、Plain Old Java Object（POJO）クラス（2.3.2.4項「Plain Old Java Object（POJO）」を参照）であり、データベースにマップされ、注釈、永続性XMLまたはその両方を通じてJPAで使用できるよう構成されます。
JPAでは、アプリケーションがコンテナ内で実行される場合、コンテナによるサポートや利便性などのすべての利点が適用されます。ただし、同じアプリケーションをコンテナの外部で実行するよう構成することも可能です。
アプリケーションとJPAの対話の手段として、セッションBean（2.3.2.1項「EJBセッションBean」を参照）を使用できます。
EclipseLink JPAは、標準準拠のJPA永続性プロバイダであり、EclipseLink Foundation Libraryに基づいています。EclipseLink JPAには、基礎となるEclipseLink APIへのフル・アクセスを可能にする幅広いベンダー拡張機能（注釈および永続性単位プロパティ）があり、機能性およびパフォーマンスを向上できます。
詳細は、次を参照してください。
Java EEアプリケーション・サーバーを使用してEJB以外のJavaオブジェクトでサービス層を作成することを選択する場合は、外部接続プールを使用する必要があります（96.1.6.2項「外部接続プール」を参照）。Java EE以外のWebサーバーを使用する場合は、内部接続プールを使用する必要があります（96.1.6.1項「内部接続プール」を参照）。いずれの場合も、JTA統合の使用をお薦めします（113.1.2.1項「JTAによって制御されるトランザクション」を参照）。
この項では、アプリケーション・アーキテクチャでサポートするデータのタイプを決定する際に必要となる選択について説明します。
これらの選択については、次のようにまとめることができます。
2.3.5項「ロック」も参照してください。
TopLinkを使用して次のデータ・タイプのいずれかを管理することができます。
リレーショナル（2.2.1.1項「リレーショナル・データベースでの使用方法」を参照）
オブジェクト・リレーショナル・データ・タイプ（2.2.1.2項「オブジェクト・リレーショナル・データ・タイプ・データベースでの使用方法」を参照）
Oracle XDB（2.2.1.3項「Oracle XML Database（XDB）での使用方法」を参照）
EISデータ、非リレーショナル・データ、レガシー・データ（2.2.1.4項「企業情報システム（EIS）での使用方法」を参照）
XMLおよびWebサービスのデータ（2.2.1.5項「XMLでの使用方法」を参照）
アプリケーション・アーキテクチャが複数のデータ・ソースにアクセスする必要がある場合、2フェーズ・コミットを行うためにセッション・ブローカ（87.7項「セッション・ブローカおよびクライアント・セッション」を参照）とJTA統合（113.1.2.1項「JTAによって制御されるトランザクション」を参照）を使用することをお薦めします。
または、複数セッションを使用することもできます。
アプリケーション・アーキテクチャが一部のデータを、プライベート・キャッシュにのみ持って、TopLinkによって共有されるセッション・キャッシュから分離する必要がある場合、独立セッションの使用をお薦めします（87.5項「独立クライアント・セッション」を参照）。Oracle Virtual Private Database（VPD）機能により独立セッションを使用することもできます（87.5.1項「独立クライアント・セッションとOracle Virtual Private Database（VPD）」を参照）。
データ・ソースが過去バージョンすなわち履歴バージョンのオブジェクトを保持している場合、この履歴データにアクセスするため、TopLink履歴セッションを使用することをお薦めします。これにより、ある期間にどのようにオブジェクトが変更されているかについての条件を付けた読込み問合せを表現できるようになります（87.6項「履歴セッション」を参照）。
この項では、アプリケーション・アーキテクチャでのTopLinkキャッシュの使用方法を決定する際に必要となる選択について説明します（第102章「キャッシュの概要」を参照）。
これらの選択については、次のようにまとめることができます。
2.3.5項「ロック」も参照してください。
アプリケーションが処理するデータのタイプに対して適切なキャッシュ・タイプを選択します（102.2.1項「キャッシュ・タイプおよびオブジェクト・アイデンティティ」を参照）。たとえば、揮発性のデータに対しては、弱アイデンティティ・マップを検討します（102.2.1.6項「キャッシュおよびアイデンティティ・マップの構成のガイドライン」を参照）。
アプリケーション・アーキテクチャにおける失効データの影響を検討します（102.2.3項「失効したデータの処理」を参照）。たとえば、問合せまたはディスクリプタのリフレッシュ・オプション（2.3.4.2項「リフレッシュ」を参照）またはキャッシュの無効化（102.2.5項「キャッシュの無効化」を参照）の使用を検討します。揮発性データに対しては、独立セッションのキャッシュを使用することを検討します（87.5項「独立クライアント・セッション」を参照）。
リレーションシップに含まれるオブジェクト、またはオブジェクトのアイデンティティを必要とするオブジェクトに対しては、アイデンティティ・マップなし（102.2.1.5項「アイデンティティ・マップなし」を参照）を使用しないでください。
TopLinkは、分散キャッシュ・コーディネーション機能を提供します。この機能では、セッションの複数（大部分の場合、分散によるもの）のインスタンスが相互にオブジェクト変更をブロードキャストでき、これにより、各セッションのキャッシュは最新の状態を保つことができます（102.3項「キャッシュ・コーディネーション」を参照）。キャッシュ・コーディネーションを使用する前に、この機能がアプリケーションに適切かどうかを確認します（102.3.1項「キャッシュ・コーディネーションの使用が必要な場合」を参照）。
変更がブロードキャストされるようにキャッシュ・コーディネーションを構成する際、次の通信プロトコルのいずれかを使用できます。
Java Message Service（JMS）: JMSコーディネート・キャッシュの使用をお薦めします（102.3.3.1項「JMSコーディネート・キャッシュ」を参照）。
Remote Method Invocation（RMI）: 同期変更伝播が必要な場合のみ、RMIキャッシュ・コーディネーションの使用をお薦めします（103.2項「同期変更伝播モードの構成」を参照）。詳細は、102.3.3.2項「RMIコーディネート・キャッシュ」を参照してください。
Common Object Request Broker Architecture（CORBA）: 現リリースから、TopLinkはSun ORBに対するサポートを提供します（102.3.3.3項「CORBAコーディネート・キャッシュ」を参照）。
オブジェクトが変更されたときにコーディネート・キャッシュが何をブロードキャストするかを決定するために使用する同期方法を構成できます。これは、プロジェクト・レベル（117.12項「プロジェクト・レベルでのキャッシュ・コーディネーション変更伝播の構成」を参照）またはディスクリプタ・レベル（119.15項「ディスクリプタ・レベルでのキャッシュ・コーディネーション変更伝播の構成」を参照）で次のように構成できます。
変更済オブジェクトの無効化: 他のすべてのセッションでオブジェクトを無効としてマークする、オブジェクト無効化を伝播します。これにより、他のセッションは次回このオブジェクトを読み取るときに、セッションのキャッシュをデータ・ソースにより更新する必要があることがわかります。この同期方法の使用をお薦めします。
変更の同期化: 変更された各属性を含んだ変更通知を伝播します。
変更および新規オブジェクトの同期化: 変更された各属性を含んだ変更通知を伝播します。新規オブジェクトの場合、オブジェクト作成を、新規インスタンスのすべての属性とともに伝播します。
この項では、アプリケーション・アーキテクチャでのTopLinkロック・オプションの使用方法を決定する際に必要となる選択について説明します。同時システムでは必ずロック・ポリシーを使用することをお薦めします（119.26項「ロック・ポリシーの構成」を参照）。
これらの選択については、次のようにまとめることができます。
3層アプリケーションを作成している場合、そのアーキテクチャにより、ロックの使用方法が影響を受けることに留意してください（16.4.6項「3層アプリケーションでのロック」を参照）。
詳細は、16.4項「ディスクリプタとロック」を参照してください。
TopLinkオプティミスティック・ロックの使用をお薦めします。オプティミスティック・ロックを使用した場合、すべてのユーザーにデータへの読取りアクセス権限があります。ユーザーが変更を書き込もうとすると、アプリケーションにより、ユーザーがデータを読み取ってから、そのデータが変更されていないかが確認されます。
バージョン（16.4.1項「オプティミスティック・バージョン・ロック・ポリシー」を参照）またはフィールド（16.4.4項「オプティミスティック・フィールド・ロック・ポリシー」を参照）のロック・ポリシーを使用できます。バージョン・ロック・ポリシーの使用をお薦めします。
ペシミスティック・ロックを使用した場合は、データを更新する目的でそのデータにアクセスする最初のユーザーが、更新を完了するまでデータをロックします。このアプローチの短所は、並行性が損われること、デッドロックになる可能性があることです。
問合せレベルでのペシミスティック・ロック・サポートの使用を検討してください（119.7.1.9項「名前付き問合せのオプションの構成」を参照）。
CMPを使用している場合は、Beanレベルのペシミスティック・ロック・サポートの使用をお薦めします（119.7.1.9項「名前付き問合せのオプションの構成」を参照）。
Oracle TopLinkでは、クラスを永続化するには、そのクラスが一定の最低要件を満たしている必要があります。これに対して、TopLinkでは、大部分の要件を満たすための代替方法も用意しています。TopLinkは、オブジェクト・モデルへの介入を最小限にできるメタデータ・アーキテクチャを使用した、非介入型アプローチを使用します。
この項では、次の内容について説明します。
TopLinkを使用して永続層を実装する際は、次のオプションを検討してください。
JPAを使用している場合は、標準のJPAの注釈およびpersistence.xml、EclipseLink JPAの注釈の拡張機能およびEclipseLink JPAのpersistence.xmlの拡張機能を任意に組み合せて永続層コンポーネントを指定できます。
詳細は、2.16項「JPAエンティティのアーキテクチャについて」を参照してください。
永続層コンポーネントは、Oracle JDeveloperまたはTopLink Workbenchからメタデータとして生成できます。
必要なメタデータを作成（XMLとして保存）するにはOracle JDeveloperまたはTopLink Workbenchを使用することをお薦めします。project.xmlおよびsessions.xmlファイルを容易にエクスポートおよび更新できます。これにより、プロジェクトを変更するたびにJavaコードを再生成および再コンパイルする必要がなくなり、開発コストが削減されます。Oracle JDeveloperまたはTopLink Workbenchでは、独自のアプリケーション・クラスと必要な修正メソッドに関してのみ、Javaコードを記述します。project.xmlおよびsessions.xmlファイルのXML構造の詳細は、TOPLINK_HOME/xsdsディレクトリの該当するXMLスキーマ（XSD）を参照してください。
TopLink Workbenchには、TopLink Workbenchを自動ビルドに統合する際に使用できるAntタスクが用意されています。
詳細は、次を参照してください。
永続層コンポーネントは、Oracle JDeveloperまたはTopLink WorkbenchからJavaとしてコーディングまたは生成できます。
Javaコードを使用するには、project、login、platform、descriptorsおよびmappingsなど、TopLinkプロジェクトの各要素に関して、コードを手動で記述する必要があります。アプリケーションがモデルベースであり、コード生成に強く依存する場合は、TopLink Workbenchを使用した方が効率的です。作成しているプロジェクトのタイプに応じて、Oracle JDeveloperおよびTopLink Workbenchはプロジェクト、表およびモデル・ソース用にJavaコードをエクスポートできます。
TopLink Workbenchには、TopLink Workbenchを自動ビルドに統合する際に使用できるAntタスクが用意されています。
詳細は、次を参照してください。
クラスのフィールド（データ・メンバー）にアクセスする際は、getter/setterメソッドを使用してアクセスするか（プロパティ・アクセスとも呼ばれる）、フィールド自体に直接アクセスできます。
メソッド・アクセスと直接フィールド・アクセスのどちらを使用するかは、アプリケーション設計によって決まります。次のガイドラインを考慮してください。
クラス外ではメソッド・アクセスを使用します。
これは、クラスの本来のパブリックAPIです。getter/setterメソッドは、必要なすべての副次的な処理を行うため、クライアントはその詳細を認識する必要がありません。
クラス内では、パフォーマンス向上のため直接フィールド・アクセスを使用します。
この場合は、getter/setterメソッドを使用しないために起動されない副次的な処理を考慮に入れる必要があります。
メソッド・アクセスと直接フィールド・アクセスのどちらを使用するかを検討する際は、次の制限を考慮してください。
getter/setterメソッドで変更追跡を有効にした場合（たとえば、メソッドsetPhoneを@ChangeTrackingで修飾した場合）は、クライアントでgetter/setterメソッドを使用してフィールド（phone）を変更すると、TopLinkではその変更を追跡します。
同様に、フィールドで変更追跡を有効にした場合（たとえば、フィールドphoneを@ChangeTrackingで修飾した場合）は、クライアントでフィールド（phone）を直接変更すると、TopLinkではその変更を追跡します。
ただし、getter/setterメソッドで変更追跡を有効にした場合（たとえば、メソッドsetPhoneを@ChangeTrackingで修飾した場合）でも、クライアントがフィールド（phone）に直接アクセスする場合は、TopLinkでは変更を検出しません。クラス内ではパフォーマンス向上のためフィールド・アクセスを、クラス外ではメソッド・アクセスを使用する形でのコーディングを選択する場合は、この制限に注意してください。
詳細は、次を参照してください。
『EclipseLink Developer's Guide』の「How to Use the @ChangeTracking Annotation」（http://wiki.eclipse.org/Using_EclipseLink_JPA_Extensions_%28ELUG%29#How_to_Use_the_.40ChangeTracking_Annotation）
ウィービングは、コンパイル済のJavaクラスのバイトコードを操作する方法です。
JPAエンティティとPlain Old Java Object（POJO）クラスの両方のパフォーマンスを向上するために、遅延ロード、変更追跡、フェッチ・グループ、内部最適化などの操作にウィービングを使用します。
詳細は、2.10項「ウィービングの使用」を参照してください。
次の要件は、プレーンJavaオブジェクトに適用されます。
privateまたはprotected属性への直接アクセスを使用することができます。直接アクセスおよびメソッド・アクセスの詳細は、121.6項「マッピング・レベルでのメソッドまたは直接フィールド・アクセスの構成」を参照してください。
非透過インダイレクションを使用する場合、属性は、オリジナルの属性タイプではなく、ValueHolderInterfaceタイプにする必要があります。ValueHolderは、参照オブジェクトを、必要となるまではインスタンス化しません。
TopLinkは、任意のコレクション・マッピングに対して、Collection、List、SetおよびMapの属性タイプの透過インダイレクションを提供します。透過インダイレクションの使用には、ValueHolderInterfaceまたはその他のオブジェクト・モデル要件を使用する必要はありません。
ウィービングを使用している場合、ValueHolderInterfaceは必要ありません。詳細は、2.4.1.5項「ウィービングの使用」を参照してください。
|
注意: コンテナ管理の永続性を備えたEJB 2.0エンティティBeanの場合、Beanの要件はEJB 2.0仕様に定義されています。コンテナ管理の永続性を備えたEJB 2.1エンティティBeanの場合、Beanの要件はEJB 2.1仕様に定義されています。 |
インダイレクションと透過インダイレクションの詳細は、17.2.4項「インダイレクション（遅延ロード）」を参照してください。
通常、TopLink永続層には次のコンポーネントが含まれます。
TopLinkアプリケーションのメタデータ・モデルは、TopLinkのプロジェクトに基づいています。プロジェクトは、ディスクリプタ、マッピングおよびランタイム機能をカスタマイズする各種ポリシーで構成されています。セッションからプロジェクトを参照することにより、このマッピングと構成情報を特定のデータ・ソースとアプリケーションに関連付けます。
詳細は、次を参照してください。
セッションは、クライアント・アプリケーションとTopLinkとの間のプライマリ・インタフェースで、基礎となるデータ・ソースへの接続を表します。
TopLinkには、いくつかの異なるセッション・タイプが用意されており（第87章「TopLinkセッションの概要」を参照）、各タイプは様々な設計要件およびアーキテクチャについて最適化されています。最も一般的に使用されるセッションは、サーバー・セッションです。これは、クライアントがサーバー上でクライアント・セッションを介してアクセスするセッションです。サーバー・セッションは、共有キャッシュおよび共有接続リソースを提供します。セッション・メタデータを使用してセッションを定義します。
CMPプロジェクトの場合、TopLinkランタイムは、セッションを内部的に作成して使用しますが、アプリケーションがこのセッションを直接取得したり使用することはありません。使用するアプリケーション・サーバーに応じて、この内部セッションに対するパラメータのいくつかを指定できます。
EclipseLink JPAプロジェクトの場合、EntityManagerはセッションを表します（つまり、ラップします）。
詳細は、次を参照してください。
デフォルトでは、TopLinkセッションはオブジェクト・アイデンティティを保証するオブジェクトレベルのキャッシュを提供し、アプリケーションがデータ・ソースにアクセスする回数を減らしてパフォーマンスを向上します。TopLinkは、ロック、リフレッシュ、無効化、分離およびコーディネーションなどの、様々なキャッシュ・オプションを提供します。キャッシュ・コーディネーションを使用して、デプロイされたアプリケーションの他のインスタンスと変更を同期化するようにTopLinkを構成できます。ほとんどのキャッシュ・オプションは、セッション・レベルで構成します。また、問合せ単位またはディスクリプタでキャッシュ・オプションを構成して、参照クラスのすべての問合せに適用されるようにできます。
詳細は、第102章「キャッシュの概要」を参照してください。
TopLinkには、いくつかのオブジェクトおよびデータ問合せタイプが用意されており、問合せ選択条件に対して次のような柔軟なオプションが提供されています。
TopLinkの式
JPQL（Java Persistence Query Language）
SQL
ストアド・プロシージャ
例による問合せ
これらのオプションを使用して、あらゆるタイプの問合せを作成できます。事前定義問合せを使用してアプリケーション問合せを定義することをお薦めします。事前定義問合せは、プロジェクトのメタデータ内に保持され、名前で参照されます。これにより、アプリケーション開発は簡単になり、問合せはカプセル化されてメンテナンス・コストが軽減します。
エンティティBeanを使用する場合は、（他のTopLink問合せオプションとともに）EJB QLを使用すると、ファインダを完全にコーディングできます。これにより、アプリケーションをJava EE仕様に準拠させることができます。
アーキテクチャまたは永続エンティティのタイプに関係なく、あらゆる問合せオプションを自由に使用できます。Oracle JDeveloperおよびTopLink Workbenchには、問合せを定義するための最も簡単な方法が用意されています。また、TopLink APIを使用してコードで問合せを作成することもできます。
詳細は、第108章「TopLink問合せの概要」および第110章「TopLinkの式の概要」を参照してください。
TopLinkには、作業ユニットという特定のトランザクション・セッションを使用して、基礎となるデータベースおよびスキーマから分離されたトランザクション・コードを記述するための機能が用意されています。
作業ユニットは、トランザクション内で行われた変更を、その変更がデータベースに正常にコミットされるまで、他のスレッドから分離します。その他のトランザクション・メカニズムとは異なり、作業ユニットはトランザクション内のオブジェクトに対する変更、変更の順序および他のTopLinkのキャッシュを無効にする可能性がある変更を自動的に管理します。作業ユニットは、最小のチェンジ・セットを計算し、参照整合性規則に準拠してデッドロックを回避するようにデータベース・コールを順序付けし、変更されたオブジェクトを共有キャッシュにマージして、これらの問題を管理します。クラスタ化環境では、作業ユニットはコーディネート・キャッシュ内の他のサーバーと変更を同期化することもできます。
アプリケーションがエンティティBeanを使用する場合は、開発者は直接作業ユニットAPIにアクセスしませんが、その機能の利点を活用できます。TopLinkランタイムとJava EEコンテナ間の統合により、自動的に作業ユニットが使用されるので、アプリケーションが享受できる利点にき損はありません。
詳細は、第108章「TopLink問合せの概要」を参照してください。
実行時に、アプリケーションはTopLinkメタデータを使用します（2.9項「TopLinkメタデータの使用」を参照）。
POJO（非CMP）プロジェクトの場合、アプリケーションは、実行時にセッション・マネージャを使用してsession.xmlファイルをロードします（第90章「実行時のセッションの取得と使用」を参照）。session.xmlファイルには、マッピング・メタデータproject.xmlファイルへの参照が含まれています。アプリケーションは、セッションを使用して、TopLinkランタイムとproject.xmlマッピング・メタデータにアクセスします。
CMPプロジェクトの場合、必要なメタデータは、アプリケーションをデプロイするJava EEアプリケーション・サーバーによって異なります（第9章「デプロイ用TopLinkファイルの作成」を参照）。すべてのアプリケーション・サーバーは、ejb-jar.xmlとTopLinkプロジェクトXMLファイルを必要とします。セッション構成は、各Java EEアプリケーション・サーバーに依存します。
アプリケーションのパッケージ化（JavaまたはJava EEのホスト環境にデプロイするため）は、TopLinkの使用方法および構成方法に影響します。たとえば、開発者はJava EEアプリケーションをEARファイルにパッケージします。EARファイル内では、永続エンティティをWARとJAR内にパッケージする方法がいくつかあります。開発者によるTopLinkの構成方法は、部分的に、アプリケーションのパッケージ方法およびホスト・アプリケーション・サーバーのクラス・ローダーの使用方法に依存します。
この項では、TopLinkの観点からパッケージ化とデプロイについて説明します。ただし、アプリケーションをJava EEコンテナにデプロイする場合、TopLinkでのコンテナ・サポートが有効になるようにアプリケーションの要素を構成する必要があります。
この項では、次の内容について説明します。
詳細は、第III部「TopLinkアプリケーション・デプロイ」を参照してください。
TopLinkのデプロイ方法では、アプリケーション・ファイルをJARファイルやEARファイルなどの1つのファイルにパッケージ化します。この方法に従うと、ファイル管理をそれほど必要としない、クリーンな自己完結型のデプロイ・ファイルを作成できます。
これらのファイルを作成した後、プロジェクトをデプロイします。
TopLinkはJava EEアプリケーションに不可欠ですが、多くの場合、クライアントは直接TopLinkと対話しません。そのかわりに、EJBコンテナのコールバックを経由してTopLink機能が間接的に起動されます。
このため、一般的なデプロイ・プロセスの手順は次のようになります。
Bean、クラス、データ・ソースなどのプロジェクトの要素を作成します。
Oracle JDeveloper TopLinkエディタまたはTopLink Workbenchでアプリケーション・マッピングを定義します。
アプリケーション・デプロイ・ファイルを作成します。ファイルの作成には、Oracle JDeveloperまたはTopLink Workbenchを使用します。
アプリケーションをパッケージ化してデプロイします。
クライアント・アプリケーションにコードを追加し、クライアント・アプリケーションがTopLinkアプリケーションにアクセスできるようにします。
TopLinkには、パフォーマンスを最適化するために次のような様々な機能が用意されています。
問合せの機能拡張
キャッシュのチューニング
複数サーバー構成への拡張
ほとんどの機能はディスクリプタまたはセッションで有効/無効を切り替えることができるため、グローバルなパフォーマンスの向上が可能になります。
TopLink EISを使用すると（2.2.1.4項「企業情報システム（EIS）での使用方法」を参照）、JCAアダプタを使用してTopLinkアプリケーションをレガシー・データ・ソースと統合できます。これは、非標準のシステムに対応するようTopLinkアプリケーションをカスタマイズするための最も効率的な方法です。
TopLink XMLを使用すると（2.2.1.5項「XMLでの使用方法」を参照）、Webサービスを使用してTopLinkアプリケーションをレガシー・データ・ソースと統合できます。
TopLInkの最適化とカスタマイズの詳細は、第IV部「TopLinkアプリケーションの最適化およびカスタマイズ」を参照してください。
開発およびデプロイを含むTopLinkアプリケーションのすべての点に関するトラブルシューティングの詳細は、付録A「TopLinkアプリケーションのトラブルシューティング」を参照してください。
この項では、リレーショナル・マッピングについて簡単に説明し、オブジェクト・モデリングとリレーショナル・モデリングへの手引きとなる重要な情報および制限が提供されます。この情報は、TopLinkアプリケーションを作成するときに役立ちます。
この項では、次の内容について説明します。
これらの項には、これらの機能についての追加詳細が含まれており、TopLinkによるこれらの機能の実装および使用方法の説明があります。
オブジェクト・モデリングとは、アプリケーション・オブジェクトを表現するJavaクラスを設計することです。TopLinkを使用すると、自分で選んだ統合開発環境（IDE）かまたはUnified Modeling Language（UML）モデリング・ツールを使用して、アプリケーション・オブジェクト・モデルを定義および作成できます。
TopLinkデータベース・セッションにディスクリプタを登録するクラスは、すべて永続クラスと呼ばれます。TopLinkでは、永続クラスは、データベースに格納されるあらゆるprivateまたはprotected属性に対してpublicアクセッサ・メソッドを提供する必要はありません。詳細は、2.4.2項「永続クラス要件」を参照してください。
データ・ストレージ・スキーマとは、アプリケーションの永続データを編成するために実装する設計のことです。このスキーマは、永続データ自体を参照するのであって、実際のデータ・ソースを参照するのではありません（例、リレーショナル・データベースや非リレーショナル・レガシー・システム）。
TopLinkアプリケーション開発プロセスの設計フェーズで（2.1.1項「一般的な開発段階」を参照）、データ・ソースのクラスの実装方法を決定する必要があります。既存のデータ・ソース情報を統合する場合、クラスと既存データの関係を確認する必要があります。統合するレガシー情報がない場合は、各クラスを格納する方法を決定してから必要なスキーマを作成します。
また、必要な情報の作成には、Oracle JDeveloper（第4章「Oracle JDeveloper TopLinkエディタの使用」を参照）、TopLink Workbench（第5章「TopLink Workbenchの使用」を参照）またはデータベースのSchema Manager（第6章「Schema Managerの使用」を参照）を使用することもできます。
オブジェクトを永続化する際、保存および取得の際に一意に識別するため、各オブジェクトにはアイデンティティが必要になります。オブジェクト・アイデンティティは、一般に一意の主キーを使用して実装されます。このキーは、各オブジェクトを識別し、参照を作成および管理するために、TopLinkによって内部的に使用されます。オブジェクト・アイデンティティが損われると、オブジェクト・モデルが破損することがあります。
Javaアプリケーションでは、メモリー内の各オブジェクトが1つのみのオブジェクト・インスタンスによって表される場合にオブジェクト・アイデンティティが維持されます。同じオブジェクトの複数取得は、同一オブジェクトの複数コピーを返すのではなく、同一オブジェクト・インスタンスへの参照を返します。
TopLinkは、複数アイデンティティ・マップをサポートして、オブジェクト・アイデンティティを保持します（コンポジット主キーを含む）。詳細は、102.2.1項「キャッシュ・タイプおよびオブジェクト・アイデンティティ」を参照してください。
TopLinkは、データ・ソースへのオブジェクトおよびBeanのマップ方法を記述するために、Oracle JDeveloperまたはTopLink Workbenchによって生成されたメタデータを使用します（2.9項「TopLinkメタデータの使用」を参照）。このアプローチは、オブジェクト・モデルから永続性情報を分離します。開発者は自分の理想的なオブジェクト・モデルを自由に設計し、DBAは自分の理想的なスキーマを自由に設計します。
開発者は、Oracle JDeveloperまたはTopLink Workbenchを使用して、マッピング情報を作成および管理します。実行時に、TopLinkはメタデータを使用して、アプリケーションが必要とするたびにシームレスおよび動的にデータ・ソースと対話します。
TopLinkは、オブジェクト・モデルに含まれる可能性のある様々なデータ・タイプと参照をサポートする、広範なマッピング階層を提供します。詳細は、第17章「マッピングの概要」を参照してください。
外部キーは、別の表内の一意のキー（通常は主キー）を参照する列の組合せです。主キーと同様、外部キーは任意の数のフィールドで、これらすべてが1つの単位として扱われます。外部キーと参照先の親である主キーは、フィールドの数およびタイプが同じである必要があります。
外部キーは、1つの表の1つ以上の列から別の表の1つ以上の列へのリレーションシップを表します。たとえば、すべてのEmployeeに属性addressがあり、この属性にAddress（独自のディスクリプタおよび表を所有）のインスタンスが含まれている場合、address属性に対する1対1マッピングにより、特定のEmployeeの住所を見つけるための外部キー情報が指定されます。
詳細は、28.7項「表およびフィールド参照の構成（外部キーおよびターゲット外部キー）」を参照してください。
オブジェクト指向システムでは、クラスを、他のクラスに基づいて定義できます。たとえば、オートバイ、セダン、バンはすべて車両タイプです。それぞれの車両タイプは、Vehicleクラスのサブクラスです。同様に、Vehicleクラスはそれぞれの特定の車両タイプのスーパークラスです。各サブクラスはそのスーパークラスから属性およびメソッドを継承します（これらにそのクラス独自の属性とメソッドを追加します）。
継承により、次のようなアプリケーションの利点が提供されます。
サブクラスを使用することにより、スーパークラスから提供された共通の要素をベースとして特殊化した動作を提供できます。継承を使用することで、スーパークラスのコードが何度も再利用できます。
汎用的な動作を定義する抽象スーパークラスの実装。この抽象スーパークラスは、動作を定義し一部実装できます。詳細は特殊化したサブクラスを使用して完成します。
TopLinkによる継承の使用の詳細は、119.20項「子（ブランチまたはリーフ）クラス・ディスクリプタに関する継承の構成」および119.23項「サブクラスでの継承属性マッピングの構成」を参照してください。
同時クライアントを同時にログインさせるには、サーバーが各クライアント用に実行の専用スレッドを生成する必要があります。これは、Java EEアプリケーション・サーバーによって自動的に行われます。専用スレッドにより、各クライアントは他のクライアントの完了を待たずに作業できるようになります。TopLinkは、これらのスレッドがアイデンティティ・マップを変更するときやデータベース・トランザクションを実行する際、互いに干渉しないように保証します。TopLink UnitOfWorkクラスを使用して、独立したスレッド・セーフな方法でクライアントがトランザクションによる変更を行うことができます。作業ユニットは、変更するオブジェクトのクローンを管理することで、各クライアントの作業を他の同時クライアントおよびスレッドから分離します。作業ユニットとは、データベース・トランザクションとしてACID（Atomicity、Consistency、Isolation、Durability）トランザクション方針のすべてを維持する、オブジェクトレベルのトランザクション・メカニズムです。作業ユニットの詳細は、第113章「TopLinkトランザクションの概要」を参照してください。
TopLinkでは、オプティミスティックおよびペシミスティック・ロック方法が構成できるようにサポートされていて、TopLink並行性マネージャが使用するロックのタイプをカスタマイズできます。詳細は、16.4項「ディスクリプタとロック」を参照してください。
TopLinkキャッシュは、データベースからオブジェクトとして返されたデータを将来の使用のために自動的に保存しておくことにより、アプリケーションのパフォーマンスを向上させます。このキャッシュにはいくつかの利点があります。
データベースから以前に読み取られたJavaオブジェクトを再利用することで、データベース・アクセスが最小限に抑えられます。
オブジェクトがキャッシュにすでに存在している場合、データベースへのSQLコールが最小限に抑えられます。
データベースへのネットワーク・アクセスが最小限に抑えられます。
キャッシュ・ポリシーはクラス単位またはBean単位に設定できます。
キャッシュのオプションおよび動作のベースを、Javaガベージ・コレクションにすることができます。
TopLinkには、複数のキャッシュ・ポリシーがサポートされているという高い柔軟性があります。開発者は、個々のアプリケーション・パフォーマンスに基づいて、パフォーマンスを最大限にするためにキャッシュを微調整できます。詳細は、第XXIII部「キャッシュ」を参照してください。
TopLinkの永続性を実現するためのメタデータ・アーキテクチャによる非介入型アプローチ（2.9項「TopLinkメタデータの使用」を参照）とは、オブジェクト・モデルへの介入がほとんどないことを意味しています。
Javaオブジェクトを永続化する際、TopLinkでは次のいずれも不要です。
永続スーパークラスまたは永続インタフェースの実装
オブジェクト・モデルにおける必要なメソッドの保存、削除またはロード
特殊永続メソッド
オブジェクト・モデルへのソース・コードの生成またはラップ
コンテナ管理の永続性を備えたエンティティBeanを使用する際、TopLinkは、CMP仕様要件以外にはオブジェクト・モデルへの追加の介入を必要としません。
この非介入型アプローチの詳細は、2.4項「永続層の構築および使用」を参照してください。
インダイレクション・オブジェクトは、アプリケーション・オブジェクトのかわりとなるため、アプリケーション・オブジェクトは必要とされるまでデータベースから読み取られません。インダイレクション（またはJPAの遅延ロード）の使用により、TopLinkは関連オブジェクトに対する代用を作成できます。これにより、特にアプリケーションが取得したオブジェクトのみのコンテンツを必要とし、そのオブジェクトに関連するすべてのオブジェクトのコンテンツは必要としない場合に、パフォーマンスの大幅な向上が見られます。
インダイレクションを使用しないと、アプリケーションは永続オブジェクトを取得するたびに、そのオブジェクトによって参照されるすべてのオブジェクトも取得します。これは、アプリケーションによってはパフォーマンスの低下につながります。
|
注意: すべての場合にインダイレクションを使用することをお薦めします。 |
TopLinkは、プロキシ・インダイレクション、透過インダイレクションおよびValueHolderインダイレクションなど、いくつかのインダイレクション・モデルを提供します。TopLinkは、EJBに対するインダイレクション・サポートも提供します（17.2.4.6項「インダイレクションおよびEJB 2.n CMP」を参照）。
詳細は、17.2.4項「インダイレクション（遅延ロード）」を参照してください。
可変性とは、複雑なフィールドのプロパティの1つであり、フィールド値を（置換ではなく）変更できるかどうかを指定します。
不変マッピングでは、オブジェクトのオブジェクトIDが変更されないかぎり、つまり、オブジェクト値が別のオブジェクト値と完全に置換されないかぎり、マップされたオブジェクト値は変更できません。
可変マッピングでは、オブジェクトのオブジェクトIDを変更しなくても、マップされたオブジェクト値を変更できます。
すべてのTransformationMappingインスタンスは可変
すべてのJPA @Basicマッピング・タイプ（Serializableタイプは除く）は不変（DateおよびCalendarタイプを含む）
すべてのJPA @BasicマッピングのSerializableタイプは可変
値が不変または可変かどうかは、主にアプリケーションでの永続クラスの使用方法によって決まります。たとえば、デフォルトでは、TopLinkではタイプDateの永続フィールドは不変であると想定します。つまり、フィールドの値が同じオブジェクトIDであるかぎり、TopLinkでは値は変更されていないと想定します。アプリケーションでDateクラスのsetメソッドを使用している場合は、DateオブジェクトのIDを変更せずにオブジェクト値の状態を変更できます。この場合、TopLinkではその変更を検出できません。この問題を回避するために、マッピングを可変として構成できます。この場合、TopLinkでは、オブジェクトIDのみでなく、永続値の状態も調べます。
可変性を構成できる対象は次のとおりです。
TransformationMappingインスタンス
各JPA @Basicマッピング・タイプ（DateおよびCalendarタイプを含む）
すべてのDateおよびCalendarタイプ
可変性は、変更追跡のパフォーマンスに影響を与える場合があります。たとえば、トランスフォーメーション・マッピングが可変値をマップする場合、TopLinkは、作業ユニットで値をクローンし、比較する必要があります（119.29項「コピー・ポリシーの構成」を参照）。マッピングで単純な不変の値をマップする場合は、マッピングを不変として構成すると、作業ユニットのパフォーマンスを向上できます。
可変性は、ウィービングにも影響を与えます。TopLinkがウィービングを実行できるのは、不変マッピングの属性変更追跡ポリシーのみです。
詳細は、次を参照してください。
『EclipseLink Developer's Guide』の「How to Use the @Mutable Annotation」（http://wiki.eclipse.org/Using_EclipseLink_JPA_Extensions_%28ELUG%29#How_to_Use_the_.40Mutable_Annotation）
TopLinkのメタデータは、アプリケーションの開発とデプロイされたランタイム環境の間の橋渡しをします。メタデータは次のものを使用して取得します。
JPAの注釈、persistence.xml、orm.xml、EclipseLink JPAの注釈およびpersistence.xmlのプロパティの拡張機能: EclipseLink JPA永続性プロバイダは、メタデータのこれらの全ソースを解析し、インメモリー・セッションとプロジェクトを実行時に作成します。
Oracle JDeveloper TopLinkエディタまたはTopLink Workbench（2.9.2項「プロジェクト・メタデータの作成」および2.9.3項「セッション・メタデータの作成」を参照）: TopLinkのランタイム環境に渡すTopLinkのsessions.xmlおよびproject.xmlファイルの作成に使用します。
JavaおよびTopLink API（この方法は最も労力が必要とされます）
メタデータを通じて、構成情報をランタイム環境に渡すことができます。ランタイム環境では、この情報を永続クラス（Javaオブジェクト、JPAエンティティまたはEJBエンティティBean）、およびTopLink APIを使用して記述されたコードとともに使用して、アプリケーションが完成します。
EclipseLink JPAを使用すると、JPAおよびEntityManagerを使用して永続クラスにアクセスしている間に、sessions.xmlおよびproject.xmlを使用してメタデータを指定することもできます。詳細は、『EclipseLink Developer's Guide』の「What You May Need to Know About EclipseLink JPA Overriding Mechanisms」（http://wiki.eclipse.org/Using_EclipseLink_JPA_Extensions_%28ELUG%29#What_You_May_Need_to_Know_About_EclipseLink_JPA_Overriding_Mechanisms）を参照してください。
この項の内容は次のとおりです。
TopLinkメタデータ・アーキテクチャにより、次のような多くの重要な利点が提供されます。
ドメイン・モデル・オブジェクト内ではなく、XMLディスクリプタ内にマッピング情報を格納します。
メタデータを使用することにより、TopLinkはオブジェクト・モデルまたはデータベース・スキーマに介入しません。
開発者は、特定の設計を強引に通すことなく、必要に応じてオブジェクト・モデルを設計できるようになります。
DBAは、特定の設計を強引に通すことなく、必要に応じてデータベースを設計できるようになります。
コード生成（設計、実装、メンテナンスなどの重大な問題の原因になる可能性がある）に依存しません。
非介入型です。TopLinkに適合するようにオブジェクト・モデルまたはデータベース・スキーマを設計することを開発者に要求するのではなく、TopLinkメタデータ自らがオブジェクト・モデルおよびデータベース・スキーマに適応します。
EclipseLink JPAを使用すると、標準のJPAの注釈、デプロイXMLまたはその両方を使用して永続性メタデータを柔軟に表現でき、EclipseLink JPAの注釈およびpersistence.xmlのプロパティの拡張機能もオプションで利用できます。
TopLinkプロジェクトには、TopLinkランタイムがオブジェクトをデータ・ソースへマップするために使用するマッピング・メタデータが含まれています。プロジェクトは、TopLinkランタイムが使用するプライマリ・オブジェクトです。
この項では、プロジェクト・メタデータの最も重要な、次のような内容について説明します。
TopLinkランタイムは、EclipseLink JPAを使用して、JPAの注釈、persistence.xml、orm.xml、EclipseLink JPAの注釈およびpersistence.xmlのプロパティの拡張機能の任意の組合せに基づき、インメモリー・プロジェクトを構成します。project.xmlファイルの使用はオプションです（『EclipseLink Developer's Guide』の「What You May Need to Know About EclipseLink JPA Overriding Mechanisms」（http://wiki.eclipse.org/Using_EclipseLink_JPA_Extensions_%28ELUG%29#What_You_May_Need_to_Know_About_EclipseLink_JPA_Overriding_Mechanisms）を参照）。
project.xmlメタデータの作成の詳細は、9.1.1項「project.xmlファイル」を参照してください。
TopLinkは、開発者がOracle JDeveloper TopLinkエディタまたはTopLink Workbenchで作成したディスクリプタとマッピングを使用して、アプリケーション内で永続エンティティをデータベースにマップします。これらのツールは、次のプロジェクト開発へのアプローチをサポートします。
マッピング用のクラスと表のインポート
クラスのインポート、および表とマッピングの生成
表のインポート、およびクラスとマッピングの生成
クラス定義と表定義の作成
TopLink Workbenchでは、これらすべてのオプションをサポートします。最も一般的なソリューションは、Oracle JDeveloperのような統合開発環境（IDE）などの開発ツールまたはモデリング・ツールを使用して永続エンティティを開発すること、および適切なリレーショナル設計ツールを使用してリレーショナル・モデルを開発することです。その後、開発者はOracle JDeveloper TopLinkエディタまたはTopLink Workbenchを使用して、これら2つのモデルを関連付けるマッピングを作成します。
Oracle JDeveloper TopLinkエディタおよびTopLink Workbenchには、アプリケーションの永続エンティティまたはリレーショナル・モデル・コンポーネントを生成するための機能が用意されていますが、これらのユーティリティはアプリケーションのラウンドトリップ開発を完了するのではなく、短期間の初期開発方法を支援することのみを目的としています。
詳細は、第16章「ディスクリプタの概要」および第17章「マッピングの概要」を参照してください。
修正メソッドにより、Oracle JDeveloper TopLinkエディタまたはTopLink Workbenchで現在サポートされていないTopLink機能を実装できます。ディスクリプタをロードした後にこのディスクリプタを修正するJavaメソッドを記述し、Oracle JDeveloper TopLinkエディタまたはTopLink Workbenchでこのメソッドをプロジェクト・メタデータに含めるように指定するのみです。TopLinkディスクリプタの修正メソッドの実装の詳細は、119.35項「修正メソッドの構成」を参照してください。
POJOプロジェクトの場合、データ・ソースへのアクセスに必要な情報を指定するセッション・メタデータでセッション・ログインを構成します（2.9.3項「セッション・メタデータの作成」を参照）。
CMPプロジェクトの場合、プロジェクトにはデータ・ソースへのアクセスに必要な情報を指定するデプロイメント・ログインが含まれています。
詳細は、15.2.4項「プロジェクトおよびログイン」を参照してください。
TopLinkのセッションには、特定のproject.xmlファイルへの参照とデータ・ソースへのアクセスに必要な情報が含まれています。セッションは、TopLinkランタイムの機能にアクセスするためにアプリケーションが使用するプライマリ・オブジェクトです。
セッション・メタデータの作成およびアクセスを担当するエージェントは、CMPプロジェクトを作成するかどうかに応じて異なります。POJOプロジェクトでは、アプリケーションは直接セッションにアクセスし、セッションを取得します（9.1.2.2項「POJOアプリケーションおよびセッション・メタデータ」を参照）。CMPプロジェクトでは、TopLinkランタイムによって内部的に取得されたセッションに、アプリケーションが間接的にアクセスします（9.1.2.4項「CMPアプリケーションおよびセッション・メタデータ」を参照）。
TopLinkランタイムは、EclipseLink JPAを使用して、JPAの注釈、persistence.xml、orm.xml、EclipseLink JPAの注釈およびpersistence.xmlのプロパティの拡張機能の任意の組合せに基づき、インメモリー・セッションを構成します。sessions.xmlファイルの使用はオプションです（『EclipseLink Developer's Guide』の「What You May Need to Know About EclipseLink JPA Overriding Mechanisms」（http://wiki.eclipse.org/Using_EclipseLink_JPA_Extensions_%28ELUG%29#What_You_May_Need_to_Know_About_EclipseLink_JPA_Overriding_Mechanisms）を参照）。
project.xmlおよびsessions.xmlファイルは、デプロイしているアプリケーションのタイプに応じて異なる方法でデプロイ用にパッケージ化します。
詳細は、次を参照してください。
EclipseLink JPAを使用すると、JPAおよびEntityManagerを使用して永続クラスにアクセスしている間に、sessions.xmlおよびproject.xmlを使用してメタデータを指定することもできます。詳細は、『EclipseLink Developer's Guide』の「What You May Need to Know About EclipseLink JPA Overriding Mechanisms」（http://wiki.eclipse.org/Using_EclipseLink_JPA_Extensions_%28ELUG%29#What_You_May_Need_to_Know_About_EclipseLink_JPA_Overriding_Mechanisms）を参照してください。
ウィービングは、コンパイル済のJavaクラスのバイトコードを操作する方法です。JPAエンティティとPlain Old Java Object（POJO）クラスの両方のパフォーマンスを向上するために、遅延ロード、変更追跡、フェッチ・グループ、内部最適化などの操作にウィービングを使用します。
この項の内容は次のとおりです。
EJB 3.0コンテナ外でEclipseLink JPAを使用する場合は、動的ウィービングを検討します。詳細は、『EclipseLink Developer's Guide』の「How to Configure Dynamic Weaving for JPA Entities Using EclipseLink Agent」（http://wiki.eclipse.org/Using_EclipseLink_JPA_Extensions_%28ELUG%29#How_to_Configure_Dynamic_Weaving_for_JPA_Entities_Using_the_EclipseLink_Agent）を参照してください。
詳細は、次の項を参照してください。
『EclipseLink Developer's Guide』の「How to Configure Dynamic Weaving for JPA Entities Using EclipseLink Agent」（http://wiki.eclipse.org/Using_EclipseLink_JPA_Extensions_%28ELUG%29#How_to_Configure_Dynamic_Weaving_for_JPA_Entities_Using_the_EclipseLink_Agent）
該当するすべてのクラス・ファイルのウィービングをビルド時に実行し、事前ウィービング済のクラス・ファイルを配信する場合に、このオプションの使用を検討してください。詳細は、『EclipseLink Developer's Guide』の「How to Configure Static Weaving for JPA Entities」（http://wiki.eclipse.org/Using_EclipseLink_JPA_Extensions_%28ELUG%29#How_to_Configure_Static_Weaving_for_JPA_Entities）を参照してください。
ウィービングを実行するには、JPAおよびPOJOの両方のアプリケーションでpersistence.xmlファイルを使用します。
POJOアプリケーションのパッケージ化およびデプロイの詳細は、2.10.4項「ウィービングを実行するPOJOアプリケーションのパッケージ化」を参照してください。
ウィービングを無効にするには、JPAおよびPOJOの両方のアプリケーションで永続性単位プロパティを使用します。詳細は、『EclipseLink Developer's Guide』の「How to Disable Weaving Using EclipseLink Persistence Unit Properties」（http://wiki.eclipse.org/Using_EclipseLink_JPA_Extensions_%28ELUG%29#How_to_Disable_Weaving_Using_EclipseLink_Persistence_Unit_Properties）を参照してください。
POJOアプリケーションのパッケージ化およびデプロイの詳細は、2.10.4項「ウィービングを実行するPOJOアプリケーションのパッケージ化」を参照してください。
ウィービングを実行するPOJOアプリケーションをパッケージ化するには、sessions.xmlファイルおよびpersistence.xmlファイルを含むJARを作成します。
アプリケーション用のsessions.xmlファイルを作成します。
詳細は、第87章「TopLinkセッションの概要」を参照してください。
例2-1に示すように、アプリケーション用のpersistence.xmlファイルを作成し、sessions.xmlファイルを参照します。
例2-1 EclipseLink JPAアプリケーション用のpersistence.xmlファイル
<persistence>
<persistence-unit name="appname">
<exclude-unlisted-classes>false</exclude-unlisted-classes>
<properties>
<property
name="eclipselilnk.session-name"
value="appname-session"
>
<property
name="eclipselink.sessions-xml"
value="sessions.xml"
>
</properties>
</persistence-unit>
</persistence>
例2-2に示すように、POJOクラス、sessions.xmlファイルおよびpersistence.xmlファイルを含むJARファイルを作成します。
persistence.xmlおよびsessions.xmlの両方のファイルをMETA-INFディレクトリに配置します。
JARのウィービングを実行します。
詳細は、次を参照してください。
TopLinkでは、POJOクラスで次の機能を有効にするためにウィービングを使用します。
遅延ロード（インダイレクション）: 121.3項「インダイレクション（遅延ロード）の構成」を参照
変更追跡: 119.30項「変更ポリシーの構成」を参照
フェッチ・グループ: 119.33項「フェッチ・グループの構成」を参照
内部最適化
TopLinkでは、ウィービングを実行するPOJOアプリケーションをパッケージ化する際に、作成したJAR内のすべてのPOJOクラスのウィービングを実行します。詳細は、2.10.4項「ウィービングを実行するPOJOアプリケーションのパッケージ化」を参照してください。
TopLinkでは、persistence.xmlファイルに定義されているすべてのクラスのウィービングを実行します。このクラスは次のとおりです。
persistence.xmlファイルにリストしたすべてのクラス
persistence.xmlファイルを含むJARに関連するすべてのクラス（要素<exclude-unlisted-classes>がfalseの場合）
TopLinkのデフォルトのウィービング動作は、EclipseLink JPA永続性プロバイダを使用するあらゆるJava EE JPA準拠アプリケーション・サーバーに適用されます。この動作を変更するには、JPAエンティティまたはPOJOクラスのpersistence.xmlを変更し、EclipseLink JPAのプロパティ、EclipseLink JPAの注釈またはその両方を使用するように設定します。
Java EEとJava SEアプリケーションの遅延ロード（インダイレクション）の違いについては、『EclipseLink Developer's Guide』の「EclipseLink JPA Support for Lazy Loading by Mapping Type」の表（http://wiki.eclipse.org/Using_EclipseLink_JPA_Extensions_%28ELUG%29#Table_19-33）を参照してください。
3層Webアプリケーション・アーキテクチャには、通常、JDBC接続を介したデータベースへのサーバー・サイドJavaアプリケーションの接続が含まれます（図2-3を参照）。このパターンでは、TopLinkは、いくつかのサーバー統合ポイントを所有できるJavaサーバー（Java EEサーバーまたはカスタム・サーバー）内に存在します。アプリケーションでは、サーブレット、Javaクライアント、汎用クライアントなどのWebクライアントを、XMLまたはCommon Object Request Broker Architecture（CORBA）を使用してサポートできます。
3層アプリケーションは、TopLinkがJavaサーバー（Java EEサーバーまたはカスタム・サーバーのいずれか）内に存在する、一般的なアーキテクチャです。このアーキテクチャでは、サーバー・セッションにより、JDBC接続および共有オブジェクト・キャッシュへの共有アクセスがクライアントに与えられます。単一のJVM上に存在するため、このアーキテクチャはシンプルで、簡単に拡張できます。このアーキテクチャにおけるTopLinkの永続エンティティは、通常、Javaオブジェクトです。
このアーキテクチャでは、多くの場合、Webベースのアプリケーションをサポートします。その場合のクライアント・アプリケーションはWebクライアント、Javaクライアントまたはサーバー・コンポーネントです。
すべての3層アプリケーションがWebベースとはかぎりませんが、このアーキテクチャは分散Webアプリケーションに最適です。また、WebアプリケーションでEJBを使用することも一般的ですが、このTopLinkのアーキテクチャでは使用しません。
3層アーキテクチャの実装例には、次のものがあります。
Model-View-Controllerモデル2のアーキテクチャ設計パターン。Java EEコンテナで稼働し、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）を使用するように構成できます。
リモート・セッション操作には、対応するクライアント・セッションがサーバー上に必要です。
これは、クライアント層からサーバー層へのアクセスを簡略化したい開発者にとっては優れたオプションですが、クライアント・セッションの使用に比べてスケーラビリティに欠け、サーバー側の動作を簡単に変更できません。
詳細は、87.9項「リモート・セッション」を参照してください。
ステートレス・クライアントを使用した3層アプリケーションには、次のような技術的な問題がいくつかあります。
ステートレス環境でのトランザクション管理
一般的な設計では、単一の作業ユニット（トランザクション・セッション）内でクライアント・リクエストを区切ります。ステートレス環境では、このことがプレゼンテーション層の設計方法に影響する場合があります。たとえば、クライアントがトランザクションの情報を収集するために複数のページを必要とする場合、プレゼンテーション層は、アプリケーションが変更またはリクエストの一式を収集するまで、情報をページ間で保有する必要があります。その時点で、プレゼンテーション層はデータベースを変更するために作業ユニットを起動します。
ステートレス環境でのオプティミスティック・ロック
ステートレス環境では、期限切れの（失効した）データを処理しないよう、特に注意する必要があります。失効したデータを処理しないための一般的な方法は、オプティミスティック・ロックを実装し、オプティミスティック・ロックの値をオブジェクトに格納することです。
この方法は、ステートレス・アプリケーションがオブジェクトをシリアライズする場合、またはオブジェクトの内容を代替形式でクライアントに送信する場合には、十分注意して行う必要があります。これらの場合、オプティミスティック・ロックの値を編集ページのHTTPコンテンツとしてクライアントに転送します。次に、任意の書込みトランザクションの戻り値を使用して、クライアントが処理を実行しているときに、データが変更されていないことを確認する必要があります。
ロックの詳細は、119.26項「ロック・ポリシーの構成」を参照してください。
外部JDBCプール
デフォルトでは、TopLinkは独自の接続プールを管理します。ホスト・アプリケーション・サーバーによって提供される接続プールを使用するようにTopLinkを構成することもできます。この機能は、共有接続プールの場合に有効です。また、JTA/JTSの統合には必須です（97.4項「外部接続プーリングの構成」を参照）。
JTA/JTSの統合
JTAおよびJTSは、標準的なJavaコンポーネントで、これにより、セッションは分散トランザクションにかかわることができます。アーキテクチャでセッションBeanを使用するため、JTA/JTSを使用できるようTopLinkを構成する必要があります（115.13項「作業ユニットと外部トランザクション・サービスの統合」を参照）。
キャッシュ・コーディネーション
複数のサーバーを使用したアプリケーションの拡張を選択する場合、TopLinkキャッシュ・コーディネーションが必要になることがあります（第102章「キャッシュの概要」を参照）。
2層アプリケーションには、通常、TopLinkを介して直接データベースに接続するJavaクライアントが含まれています。2層アーキテクチャは、デプロイが制限された複雑なユーザー・インタフェースでは最も一般的です。データベース・セッションにより、2層アプリケーションに対するTopLinkのサポートが提供されます。
詳細は、第87章「TopLinkセッションの概要」を参照してください。
2層アーキテクチャは、TopLinkアプリケーションの最もシンプルなパターンですが、各クライアント・アプリケーションに独自のセッションが必要となるため、最も制限的でもあります。そのため、2層アプリケーションは、他のアーキテクチャほど簡単に拡張できません。
2層アプリケーションは、多くの場合、データベースに直接アクセスするユーザー・インタフェースとして実装されます（図2-4を参照）。また、非インタフェース処理エンジンにもなります。どちらの場合でも、2層モデルは3層モデルほど一般的ではありません。
TopLinkを使用した効率的な2層（クライアント/サーバー）アーキテクチャの主な要素は次のとおりです。
クライアントからデータベースへの最小限の専用接続
独立したオブジェクト・キャッシュ
2層設計の利点は、その単純さです。2層化されたアーキテクチャを作成するTopLinkのデータベース・セッションは、すべてのTopLinkの機能を1つのセッション・タイプで提供するため、2層アーキテクチャの構築および使用は単純になります。
2層アーキテクチャの最も重要な制限は、各クライアントに独自のデータベース・セッションが必要であるため、スケーラブルではないことです。
多層Webアプリケーションが最新の傾向であり、2層アーキテクチャは本番環境では一般的ではありませんが、それでも実用的ではあります。2層システムには共有キャッシュがないため、アプリケーションの複数のインスタンスを実行する場合に、失効したデータに遭遇するリスクがあります。このリスクは、個々のデータベース・セッション数が多くなるにつれて大きくなります。
この問題を最小限に抑えるために、TopLinkでは、いくつかのデータ・ロック方法をサポートしています。これらのロック方法には、ペシミスティック・ロックおよびオプティミスティック・ロックのいくつかのバリエーションがあります。詳細は、119.26項「ロック・ポリシーの構成」を参照してください。
このアーキテクチャは、アプリケーション層へのアクセスをラップするEJBセッションBeanを加えて3層パターンを拡張したものです。セッションBeanは、アプリケーション操作へのパブリックなAPIアクセスを提供するため、プレゼンテーション層とアプリケーション層を分けることができます。また、このアーキテクチャにより、Java EEコンテナ内でセッション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を使用してJava EEコンテナで稼働し、EJBを使用せずTopLink対応のセッションBeanを使用してデータにアクセスします。
EJBセッションBeanファサード・アーキテクチャは、永続Javaオブジェクトのパフォーマンスと、標準化されたクライアント開発およびサーバーのスケーラビリティに関するEJBの利点の両方を効率よく兼ね備えた一般的な設計です。次のような利点があります。
EJB CMPアプリケーションよりも小さいオーバーヘッド:
TopLinkでは、プロジェクト、ディスクリプタおよびログイン情報へのアクセスをアプリケーションのBean間で共有します。
その他のサーバーとの将来的な互換性:
この設計は、ログインおよびEJBサーバー固有の情報をBeanと切り離すため、大規模な記録または再作成をしなくても、アプリケーション・サーバー間でアプリケーションを移植できます。
共有リード・キャッシュ:
この設計は、オブジェクトを読み取るために共有キャッシュを提供することで効率性を高めることができます。
このモデルの主な短所は、永続モデルをクライアントへ転送する必要があることです。モデルに複雑なオブジェクト・グラフがインダイレクション（遅延ロード）とともに含まれる場合、継承、インダイレクションおよびリレーションシップについて多くの問題が発生する可能性があります。
継承、インダイレクションおよびリレーションシップの管理の詳細は、第VIII部「マッピング」を参照してください。
セッション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の統合には必須です（97.4項「外部接続プーリングの構成」を参照）。
JTA/JTSの統合
JTAおよびJTSは、標準的なJavaコンポーネントで、これにより、セッションは分散トランザクションにかかわることができます。アーキテクチャでセッションBeanを使用するため、JTA/JTSを使用できるようTopLinkを構成する必要があります（115.13項「作業ユニットと外部トランザクション・サービスの統合」を参照）。
キャッシュ・コーディネーション
複数のサーバーを使用したアプリケーションの拡張を選択する場合、TopLinkキャッシュ・コーディネーションが必要になることがあります（102.3項「キャッシュ・コーディネーション」を参照）。
作業ユニットを使用して、クライアント・アプリケーションでデータベース内のオブジェクトを変更できます。作業ユニットのマージ機能では、マッピングを採用して、シリアライズされたオブジェクトから作業ユニットに値をコピーし、変更を計算します。
詳細は、115.5項「作業コピーのクローンでの変更内容のマージ」を参照してください。
CMPは、Java EEコンポーネント・モデルの構成要素であり、EJBコンテナがエンティティBeanの永続化に使用するオブジェクト永続化サービスを提供します。CMPは、保証付きのポータブルなインタフェースにより、永続データへの分散型、トランザクション型でセキュアなアクセスを提供します。
このアーキテクチャは、3層アーキテクチャを拡張したもので、永続化メソッドの実装は、実行時にコンテナによって処理されます。Beanの開発者として、デプロイメント・ディスクリプタで指定する必要があるのは、コンテナがデータ・アクセスを処理する必要がある永続フィールドとリレーションシップ、およびデータベース・スキーマの抽象表現（オプション）のみです。
TopLink CMPは、TopLink永続フレームワークを拡張したものであり、様々なアプリケーション・サーバーのEJBコンテナへのカスタム統合を提供します（8.1項「アプリケーション・サーバーのサポートの概要」を参照）。アプリケーション・サーバーの選択の詳細は、2.2.2項「ターゲット・プラットフォーム」を参照してください。TopLinkは、このアーキテクチャでEJBコンテナと連携し、EJBコンテナの永続マネージャを強化します。
TopLink CMP統合は非介入型です（図2-6を参照）。ランタイム統合とコード生成の組合せにより、コンテナはTopLinkを内部的に使用し、Beanユーザーは各自の標準のAPIを使用してコンテナ管理の永続性を備えたエンティティBeanと対話します。これにより、標準インタフェースならびにCMPおよびコンテナの能力を、TopLinkの柔軟性、パフォーマンスおよび生産性と結合することができます。
詳細は、次を参照してください。
コンテナ管理の永続性を備えたエンティティBeanの実装例には、Model-View-Controllerモデル2のアーキテクチャ設計パターンがあります。このパターンはJava EEコンテナで稼働し、セッションBean、またはコンテナ管理の永続性を備えたエンティティBean（TopLinkによる機能強化版）のいずれかにアクセスするサーブレットおよびJSPがあります。
コンテナ管理の永続性を備えたエンティティBeanを使用する3層アーキテクチャには、次の長所があります。
コンテナ管理の永続性を備えたエンティティBeanは、キャッシュおよびマッピングのサポート、複数の表にわたるBeanデータの保存、コンポジット主キーならびにデータ変換など、TopLinkの高度な機能を利用できます。
データにアクセスするための標準的なメソッドがあり、これにより、開発者は標準化された再利用可能なビジネス・オブジェクトを作成できます。
粗粒度オブジェクトの作成に最適です。これらのオブジェクトは、TopLinkによって依存型の軽量標準Javaオブジェクトに関連付けられます（TopLinkは軽量依存型Javaオブジェクトへのコンテナ管理のリレーションシップも管理できます）。
TopLinkでは、参照されるオブジェクトおよびBeanの遅延初期化ができます（17.2.4項「インダイレクション（遅延ロード）」を参照）。
TopLinkには、Beanのトランザクション・コピーの機能があります。この機能により、個別のシリアライズに依存せずに、複数のクライアントによる同時アクセスが可能になります。
TopLinkには、高度な問合せ機能があり、動的問合せの他に、データ・ソース・レベルではなくBeanレベルでの問合せ定義、ならびに問合せおよびファインダの豊富なオプションを使用できます。
TopLinkにより、Beanおよびオブジェクト・アイデンティティが維持されます。
このアーキテクチャの短所は、コンテナ管理の永続性を備えた純粋なエンティティBeanアーキテクチャは一般管理コストが高くなる可能性があることです。これは、データ・モデルに複雑なリレーションシップを持った細粒度クラスが多数ある場合、特に当てはまります。
このアーキテクチャの主な技術的な問題は、コンポーネントと、統一されたまとまりのあるシステムとの統合にあります。たとえば、このアーキテクチャには、TopLinkとアプリケーション・サーバーまたはJava EEコンテナとの特別な統合が必要です。
その他に、次のような問題があります。
デフォルトでは、TopLinkは独自の接続プールを管理します。ホスト・アプリケーション・サーバーによって提供される接続プールを使用するようにTopLinkを構成することもできます。この機能は、共有接続プールの場合に有効です。また、JTA/JTSの統合には必須です（97.4項「外部接続プーリングの構成」を参照）。
JTAおよびJTSは、標準的なJavaコンポーネントで、これにより、セッションは分散トランザクションにかかわることができます。アーキテクチャでセッションBeanを使用するため、JTA/JTSを使用できるようTopLinkを構成する必要があります（115.13項「作業ユニットと外部トランザクション・サービスの統合」を参照）。
複数のサーバーを使用したアプリケーションの拡張を選択する場合、TopLinkキャッシュ・コーディネーションが必要になることがあります（102.3項「キャッシュ・コーディネーション」を参照）。
1対1または多対多リレーションシップが双方向である場合、リレーションシップの変更時にバックポインタを維持する必要があります。
TopLinkでは、2つのエンティティBean間のリレーションシップが自動的に維持されます。
バックポインタを手動で設定するには、次のいずれかを実行します。
リレーションシップを確立または変更したときにバックポインタが設定されるように、エンティティBeanをコーディングすることをお薦めします。
クライアントをコーディングする際、明示的にバックポインタを設定します。
バックポインタを設定するようにエンティティBeanをコーディングする場合は、クライアントがバックポインタを設定する必要はありません。これには、この設定の実装をBean内にカプセル化する利点があります。
1対多リレーションシップでは、ソースBeanが複数の依存ターゲット・オブジェクトを所有できます。たとえば、EmployeeBeanは、複数の依存PhoneNumberインスタンスを所有できます。従業員に新規の依存オブジェクト（この例ではPhoneNumber）を追加する際、そのオブジェクトの所有者（従業員）へのPhoneNumberインスタンスのバックポインタを設定する必要があります。エンティティBeanで1対多リレーションシップを設定するには、例2-3に示されているように、EmployeeBeanのコンテキストからローカル・オブジェクト参照を取得し、バックポインタを更新する必要があります。
例2-3 エンティティ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-4に示されているように、発生する可能性のある問題を回避するには、リレーションシップのコレクションに依存オブジェクトを追加する際に、Beanのsetterメソッドを使用します。これにより、TopLinkではキャッシュ内のオブジェクトのマージ処理が可能になります。
コレクションでは、通常、equalsメソッドを使用してオブジェクトを比較します。オブジェクトにEJBObjectオブジェクトのコレクションが含まれる場合、等価性はEJBコンテナ・コレクションで適切に処理されるため、オブジェクトの比較は不要です。
BMPはJava EEコンポーネント・モデルの構成要素であり、これを使用して、Beanの開発者は、エンティティBeanクラスまたは自分が用意する1つ以上のヘルパー・クラスにエンティティBeanの永続データを直接実装できるようになります。
このアーキテクチャは、3層アーキテクチャを拡張したもので、永続データは、実装されたコードを使用してエンティティBean内でBean管理されています。クライアント・コードは、エンティティBeanインタフェースを介してデータにアクセスします。
TopLink BMPは、TopLink永続フレームワークを拡張したものであり、BMP開発の開始点となるベース・クラスBMPEntityBaseを提供します。このクラスは、3.0より前のEJB仕様に必要とされるすべてのメソッド（ejbPassivateを除く）を実装します。BMPEntityBaseをサブクラス化して、Bean管理の永続性を備えたTopLink対応のエンティティBeanを作成します。BMPEntityBaseクラスを使用するには、次のように行います。
アプリケーションに対してTopLinkセッションを作成します（第87章「TopLinkセッションの概要」を参照）。
Bean管理の永続性を備えたエンティティBeanを表すディスクリプタそれぞれにBMPWrapperPolicyを追加します。
このBMPWrapperPolicyは、TopLinkにエンティティBeanのリモート・オブジェクトを作成するための情報、およびリモート・オブジェクトからデータを抽出するための情報を提供します。
ホームおよびリモートのインタフェースを作成します。
デプロイメント・ディスクリプタを作成します（第8章「TopLinkとアプリケーション・サーバーの統合」および第9章「デプロイ用TopLinkファイルの作成」を参照）。
アプリケーションをパッケージ化します（第10章「TopLinkアプリケーションのパッケージ化」を参照）。
Beanをデプロイします（第11章「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のアーキテクチャ設計パターンがあります。このパターンはJava EEコンテナで稼働し、セッションBean、およびBean管理の永続性を備えたエンティティBean（TopLinkによる機能強化版）にアクセスするサーブレットおよびJSPがあります。
TopLinkの3層アーキテクチャを持つBMPを使用することには、次のような利点があります。
BMPメソッド・コールが簡略化されます。これらは、生成されるのではなく、抽象Beanクラスから継承できます。
TopLinkにより、BMPをより簡単に実装できます。
開発者は、データベースに依存しないコードをBeanのメソッドに実装できます。
このアーキテクチャでは、複合リレーションシップ、キャッシュ、オブジェクト・レベルの問合せと動的な問合せ、および作業ユニットなどの機能をサポートします。
BMPの主な短所は次のとおりです。
永続性のメカニズムをBeanコードで作成する必要があります。
CMPほど透過的または効率的ではありません。
TopLink専用のJavaオブジェクト・アプリケーションには、アプリケーション・サーバーからの同程度の独立性があります。
このアーキテクチャの主な技術的な問題は、コンポーネントと、統一されたまとまりのあるシステムとの統合にあります。たとえば、このアーキテクチャには、TopLinkとアプリケーション・サーバーまたはJava EEコンテナとの特別な統合が必要です。
その他に、次のような問題があります。
デフォルトでは、TopLinkは独自の接続プールを管理します。ホスト・アプリケーション・サーバーによって提供される接続プールを使用するようにTopLinkを構成することもできます。この機能は、共有接続プールの場合に有効です。また、JTA/JTSの統合には必須です（97.4項「外部接続プーリングの構成」を参照）。
JTAおよびJTSは、標準的なJavaコンポーネントで、これにより、セッションは分散トランザクションにかかわることができます。アーキテクチャでセッションBeanを使用するため、JTA/JTSを使用できるようTopLinkを構成する必要があります（115.13項「作業ユニットと外部トランザクション・サービスの統合」を参照）。
複数のサーバーを使用したアプリケーションの拡張を選択する場合、TopLinkキャッシュ・コーディネーションが必要になることがあります（102.3項「キャッシュ・コーディネーション」を参照）。
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を管理します。
JPAのTopLink実装は、EclipseLinkにより提供されます。
詳細は、次を参照してください。
『EclipseLink Developer's Guide』のJPAに関する項（http://wiki.eclipse.org/EclipseLink/UserGuide/Developing_JPA_Projects_%28ELUG%29）
EclipseLink API（http://www.eclipse.org/eclipselink/api/1.0/index.html）
Bean管理の永続性を備えたエンティティBeanの実装例には、Model-View-Controllerモデル2のアーキテクチャ設計パターンがあります。このパターンはJava EEコンテナで稼働し、セッションBean、およびEclipseLink JPA永続性プロバイダを使用するEJB 3.0準拠のエンティティにアクセスするサーブレットおよびJSPがあります。
EclipseLink JPAエンティティを使用することには、次のような利点があります。
POJO永続性: JPAでは、永続オブジェクトはPOJOです。
オブジェクト・リレーショナル・マッピングは、完全にメタデータ駆動型です。
永続性APIは、永続オブジェクトとは別のレイヤーとして存在しており、永続オブジェクトに介入することはありません。
問合せフレームワークを使用すると、個々の外部キーやデータベース列を使用することなく、エンティティおよびリレーションシップ全体を問い合せることができます。また、メタデータの形式で静的に問合せを定義することや、作成時に問合せ基準を渡すことで動的に問合せを作成することができます。問合せにより、結果としてエンティティが返されます。
エンティティは移行可能です。オブジェクトは、あるJVMと別のJVM間を自由に移動でき、同時にアプリケーションで使用できます。
Java SE 5の注釈またはXML（あるいはその両方の組合せ）を使用して永続化機能を構成できます。また、デフォルトに従うことも可能です。
アプリケーションがコンテナ内で実行される場合、コンテナによりサポートや利便性が提供されます。ただし、同じアプリケーションをコンテナの外部で実行するよう構成することも可能です。
Webサービス・アーキテクチャは、3層アーキテクチャ（2.11項「3層アーキテクチャについて」を参照）またはセッションBeanアーキテクチャ（2.13項「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
EclipseLink SDOアーキテクチャでは、データ・アプリケーションおよび開発にSDO 2.1フレームワークを使用します。詳細は、『EclipseLink Developer's Guide』の「Considering EclipseLink Service Data Objects (SDO) Architecture」（http://wiki.eclipse.org/Introduction_to_EclipseLink_Application_Development_%28ELUG%29#Considering_EclipseLink_Service_Data_Objects_.28SDO.29_Architecture）を参照してください。
