ヘッダーをスキップ
Oracle® Fusion Middleware Oracle TopLinkの理解
12c (12.1.2)
E48006-01
  ドキュメント・ライブラリへ移動
ライブラリ
製品リストへ移動
製品
目次へ移動
目次

前
 
次
 

2 マッピングの理解

この章では、オブジェクト・リレーショナルおよびObject-XMLマッピングで使用できるアイテムについて説明します。

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

2.1 オブジェクト・リレーショナル・マッピングについて

EclipseLinkでは、完全なJPA準拠のJPA実装が提供されます。これは、すべての必須機能および多くのオプション機能に完全に準拠しています。これは、JPA仕様に記載されていないEclipseLink機能(オブジェクトレベル・キャッシュ、分散キャッシュ調整、広範なパフォーマンス・チューニング・オプション、Oracle Databaseサポートの拡張機能、高度なマッピング、オプティミスティック・ロック・オプションとペシミスティック・ロック・オプション、広範な注釈と問合せのヒントなど)もサポートしています。

詳細は、『Oracle Fusion Middleware Oracle TopLink Java Persistence API (JPA)拡張機能リファレンス』を参照してください。

次の各項で、これらの機能の多くについて説明します。

2.1.1 オブジェクト・リレーショナル・エンティティ・アーキテクチャの理解

このエンティティ・アーキテクチャは、エンティティ、永続性ユニット、永続性コンテキスト、エンティティ・マネージャ・ファクトリおよびエンティティ・マネージャで構成されています。図2-1に、これらの要素の関係を示します。

  • 永続性は、1つ以上のEntityManagerFactoryオブジェクトを作成します。

  • EntityManagerFactoryは、1つの永続性ユニットによって構成されます。

  • EntityManagerFactoryは、1つ以上のEntityManagerオブジェクトを作成します。

  • 1つ以上のEntityManagerは、1つのPersistenceContextを管理します。

図2-1 エンティティ・アーキテクチャの要素間の関係

エンティティ・アーキテクチャの要素間の関係
「図2-1 エンティティ・アーキテクチャの要素間の関係」の説明

2.1.1.1 エンティティ

エンティティは、アプリケーションで定義されたオブジェクトで、次の特性があります。

  • 永続化することが可能です。

  • 永続識別子を持ちます(永続識別子とは、エンティティ・インスタンスを一意に識別し、そのインスタンスを同じエンティティ・タイプの他のインスタンスから区別するキーです。エンティティは、データ・ストアにそのエンティティを表現するオブジェクトが存在する場合、永続識別子を持ちます)。

  • エンティティの永続性ビューに関してトランザクション的であるという点で、トランザクション的です(エンティティは、トランザクション内で作成、更新および削除され、変更のデータベースへのコミット時にはトランザクションが必要です)。ただし、メモリー内エンティティは、変更を永続化することなく更新できます。

  • プリミティブ・オブジェクト、プリミティブ・ラッパー・オブジェクトまたは組込みオブジェクトではありません。エンティティは、単一の場所(表の行など)に通常格納される集約された状態のセットを保持する粒度の細かいオブジェクトであり、他のエンティティに対するリレーションシップを持ちます。

エンティティには、エンティティを記述するエンティティ・メタデータも含まれています。エンティティ・メタデータは、データベースに対して永続化されません。これは、エンティティがロードされてから実行時に起動されるまでの間、永続性レイヤーがエンティティを管理するために使用されます。メタデータは、Javaプログラミング要素またはXMLファイル(ディスクリプタ)の注釈として表現できます。詳細は、第4章「エンティティの理解」を参照してください。

現在のリリース以降では、マッピングを自動的に追加できる拡張可能なエンティティを定義および使用できます。この場合、エンティティには、静的属性ではなく、マップ内に拡張された属性が保存されます。次に、エンティティは、eclipselink-orm.xmlマッピング・ファイルを使用して、このマップの値をデータベースにマップする方法を定義します。EclipseLinkでは、動的にマッピングを定義できることに加えて、これらの拡張されたマッピングを保存して外部から管理することもできます。この外部保存によって、アプリケーションの実行中に、拡張されたマッピングを定義できるようになりました。エンティティを拡張可能にする方法の詳細は、『Oracle Fusion Middleware Oracle TopLinkソリューション・ガイド』のSoftware as a Serviceの提供に関する項を参照してください。

2.1.1.2 永続性と永続性ユニット

永続性は、エンティティの特性です。つまり、エンティティはデータ・ストアで表すことができ、後でアクセスできます。

永続性ユニットは、永続化可能なユニットを識別し、それに関連するプロパティを定義します。また、永続化する必要があるオブジェクトも定義します。オブジェクトは、エンティティ・クラス、埋込み可能クラス、マップされたスーパークラスのいずれかです。永続性ユニットでは、エンティティ・マネージャ・ファクトリの構成が提供されます。エンティティ・マネージャ・ファクトリによって作成されたエンティティ・マネージャは、永続性ユニットに定義されたプロパティを継承します。

2.1.1.3 エンティティ・マネージャ

エンティティ・マネージャは、エンティティに対して操作を実行するAPIコールを有効にします。エンティティ・マネージャを使用してエンティティの作成、読取り、書込みのいずれかを行うまで、エンティティは、非永続性Javaオブジェクトです。エンティティ・マネージャがエンティティへの参照を取得すると、そのエンティティはエンティティ・マネージャによって管理されるようになります。特定の時点でのエンティティ・マネージャ内の管理対象エンティティ・インスタンスのセットは、永続性コンテキストと呼ばれ、同じ永続性IDのJavaインスタンスは、永続性コンテキスト内に特定の時点で1つのみ存在できます。

特定のデータベースを対象とする読取りまたは書込み、特定タイプのオブジェクトの永続化または管理、および特定の永続性プロバイダによる実装を行うようエンティティ・マネージャを構成できます。永続性プロバイダにより、EntityManagerインタフェース実装、Query実装、SQL生成などのJPAの実装が提供されます。エンティティ・マネージャはEntityManagerFactoryによって提供されます。エンティティ・マネージャの構成は、EntityManagerFactoryに依存しますが、永続性ユニットとして個別に定義されます。永続性ユニットに名前を付けることで、各EntityManagerFactoryオブジェクトを区別できます。この方法により、特定のエンティティの操作にどの構成を使用するかをアプリケーションで制御できます。永続性ユニットを記述する構成は、persistence.xmlファイルで定義します。特定の構成をEntityManagerFactoryにバインドするようにリクエストできるようにするために、永続性ユニットに名前を付けます。

2.1.2 注釈を使用したメタデータの追加

注釈は、JPA永続性プロバイダが永続動作を管理するために実行時に解釈できるように、対応するJavaクラス・ファイルにコンパイルされるメタデータを使用してJavaソース・コードを修飾するための簡単な表現手段です。

メタデータ注釈は、構造化メタデータおよび型指定メタデータをソース・コードに添付するJava言語の機能を表します。メタデータ指定には注釈のみで十分であり、XMLを使用する必要はありません。標準のJPA注釈は、javax.persistenceパッケージにあります。

詳細は、JPA仕様(http://jcp.org/en/jsr/detail?id=317)の第10章「Metadata Annotations」を参照してください。

EclipseLinkには、Javaソース・コードに簡単にメタデータを追加できるように、一連の独自仕様の注釈が用意されています。メタデータは、対応するJavaクラス・ファイルにコンパイルされ、実行時にJPA永続性プロバイダによって解釈されて、永続性動作が管理されます。注釈は、クラス、メソッドおよびフィールドのレベルに適用できます。

EclipseLinkの注釈では、JPAメタデータの使用を介して現在入手できない一部の機能が公開されています。

  • 基本プロパティ: デフォルトでは、EclipseLinkの永続性プロバイダは、シンプル・タイプに対する基本マッピングを自動的に構成します。これらの注釈を使用して、フィールドまたはプロパティのエンティティの即時の状態を微調整します。

  • 関係: EclipseLinkには、1対1や1対多などの一部の関係がデフォルトで含まれます。他の関係は、明示的にマップする必要があります。注釈を使用して、エンティティ関係のタイプおよび特性を指定して、これらの関係をデータベースでどのように実装するかを微調整します。

  • 埋込みオブジェクト: 埋込みオブジェクトには、それ自体の永続識別子は存在せず、識別子に関しては、エンティティに依存しています。デフォルトで、永続性プロバイダでは、すべてのエンティティがそれ自体の表にマップされることが想定されます。それに続く注釈を使用すれば、他のエンティティが所有するエンティティに対して、この動作をオーバーライドできます。

2.1.2.1 注釈使用の長所と短所

注釈を使用する場合の利点は、次のとおりです。

  • 比較的簡単に使用および理解できます。

  • 記述しているコード内にインラインのメタデータとして提供されるため、メタデータの適用先となるソース・コードのコンテキストを複製する必要がありません。

注釈の主な短所は、メタデータが不必要にコードに結合されるため、メタデータを変更する場合にソース・コードを変更して再コンパイルする必要があることです。

2.1.3 構成の基本について

次の項では、オブジェクト・リレーショナル・マッピング・プロジェクトの主な構成ファイルのいくつかについて説明します。

2.1.3.1 デフォルトの構成値

各注釈には、デフォルト値があります(詳細はJPA仕様を参照)。永続性エンジンにより、アプリケーションの大半に適用されるデフォルトが定義されます。デフォルト値をオーバーライドするには、単に値を指定します。したがって、必ずしも構成値を指定する必要はなく、指定はこの原則の例外となります。これは、例外による構成と呼ばれます。


注意:

必要時に動作を変更できるように、ユーザーはデフォルト値を把握しておく必要があります。


デフォルト値の詳細は、『Oracle Fusion Middleware Oracle TopLink Java Persistence API (JPA)拡張機能リファレンス』を参照してください。JPA仕様の第10章「Metadata Annotations」も参照してください。

http://jcp.org/en/jsr/detail?id=317

この構成は例外処理として行われます。つまり、構成ファイルのいずれかに値が指定されていない場合は、デフォルト値が使用されます。

2.1.3.2 persistence.xmlを使用した永続性ユニットの構成

永続性ユニットでは、エンティティ・マネージャを取得する際に必要な詳細を定義します。エンティティ・マネージャ・ファクトリを取得する場合、永続性ユニットを名前で指定します。永続性ユニットを構成するには、JPA永続性ファイルpersistence.xmlを使用します。ベンダー固有の拡張機能は、<properties>要素を使用して、このファイルに指定できます。

このファイルは、永続性ユニットのJARファイルのMETA-INF/ディレクトリまたはクラスパスにあります。

詳細は、5.2項「永続性ユニットについて」を参照してください。『Oracle Fusion Middleware Oracle TopLink Java Persistence API (JPA)拡張機能リファレンス』の永続性プロパティの拡張機能リファレンスに関する項も参照してください。

2.1.3.3 オブジェクト・リレーショナル・データ・タイプ・マッピング

オブジェクト・リレーショナル・データ・タイプ・マッピングは、特定オブジェクトのデータ・メンバー・タイプを、Oracle Databaseのような特別なオブジェクト・リレーショナル・データベースでの格納に最適化された構造化データ・ソース表現に変換します。オブジェクト・リレーショナル・データ・タイプ・マッピングを使用すると、オブジェクト・モデルをオブジェクト・リレーショナル・モデルにマップできます。オブジェクト・リレーショナル・データ・タイプ・マッピングは、オブジェクト・リレーショナル・データ・タイプ・データ・ソース表現をサポートするために最適化された特別のオブジェクト・リレーショナル・データベースにのみ使用できます。

詳細は、『Oracle Fusion Middleware Oracle TopLink Java Persistence API (JPA)拡張機能リファレンス』を参照してください。

2.1.3.3.1 orm.xmlを使用したオブジェクト・リレーショナル・マッピングの指定

orm.xmlファイルを使用して、メタデータを永続性ユニットに適用します。このメタデータは、すべてのマッピング・ファイルと注釈の集合です(xml-mapping-metadata-complete要素が存在しない場合)。メタデータに対して1つのマッピングorm.xmlファイルを使用し、そのファイルをクラスパスのMETA-INFディレクトリに配置する場合、それを明示的にリストする必要はありません。このファイル(orm.xml)は、永続性プロバイダによって自動的に検索され、使用されます。

JPA 2.0 orm.xmlのスキーマは、orm_2_0.xsdです。(http://java.sun.com/xml/ns/persistence/orm_2_0.xsd)

マッピング・ファイルを異なる名前で使用するか、異なる場所に配置する場合、それらをpersistence.xmlファイルのmapping-file要素にリストする必要があります。

2.1.3.3.2 eclipselink-orm.xmlを使用したEclipseLinkオブジェクト・リレーショナル・マッピングの指定

標準のJPAのorm.xmlファイルによって、メタデータを永続性ユニットに適用します。これは、すべてのJPA 2.0マッピングをサポートしています。このファイルを注釈のかわりに使用するか、ソース・コードのJPA注釈をオーバーライドするために使用できます。eclipselink-orm.xmlファイルは、orm.xmlファイルで定義されているマッピングに加え、JPA 2.0では定義されていないEclipseLink拡張機能のフル・セットもサポートしています。eclipselink-orm.xmlファイルに指定した設定によって、orm.xmlファイルの設定がオーバーライドされます。

eclipselink-orm.xmlファイルの詳細は、『Oracle Fusion Middleware Oracle TopLink Java Persistence API (JPA)拡張機能リファレンス』のeclipselink-orm.xmlのスキーマ参照に関する項を参照してください。


注意:

このマッピング・ファイルを使用すると、EclipseLinkの多くの高度な機能が有効になりますが、他のJPA実装に対する永続性ユニットの移植性がなくなる場合があります。


オーバーライド値の詳細は、次を参照してください。

2.1.3.4 マッピング情報のオーバーライドおよびマージ

orm.xmlファイルのマッピングをオーバーライドするには、プロジェクトでMETA-INF/eclipselink-orm.xmlファイルを定義する必要があります。orm.xmleclipselink-orm.xmlの両方を指定すると、eclipselink-orm.xmlの内容によって、orm.xmlと、永続性ユニットに指定されている他のすべてのJPAマッピング・ファイルがオーバーライドされます。複数のORMファイルの指定が重複している場合、競合エンティティが存在しなければそれらのファイルはマージされます。

詳細は、『Oracle Fusion Middleware Oracle TopLink Java Persistence API (JPA)拡張機能リファレンス』のオーバーライドおよびマージに関する項を参照してください。

2.1.3.5 XMLスキーマの検証

デフォルトでは、.orm XMLファイルの内容は、JPAの.orm XMLスキーマに対して検証されません。

開発時に、.orm XMLファイルをスキーマに対して検証し、その妥当性を確認することをお薦めします。EclipseLinkで.orm XMLスキーマの検証を有効にするには、persistence.xmlファイルの永続性ユニット・プロパティeclipselink.orm.validate.schemaを使用します。

2.1.3.6 XML使用の長所と短所

注釈のかわりにXMLを使用する場合の利点は、次のとおりです。

  • メタデータとソース・コード間の結合がありません。

  • 既存のEJB 3.0以前の開発プロセスに準拠しています。

  • IDEおよびソース・コントロール・システムでサポートされます。

XMLによるマッピングの主な短所は、次のとおりです。

  • 注釈と比較して、本質的に複雑です。

  • コード・コンテキストを複製する必要があります(XMLとソース・コードの両方で構造を定義する必要があります)。

詳細は、JPA仕様の第10章「Metadata Annotations」を参照してください。

http://jcp.org/en/jsr/detail?id=317

2.1.4 データ・ソースについて

永続性ユニットの定義で重要なのは、プロバイダが読み書きするデータを検出可能な場所です。これを、データ・ソースと呼びます。データ・ソースは、通常はデータベースです。データベースの場所は、サーバーのJNDIネームスペースのJDBCデータ・ソースの形式で指定します。

通常、EclipseLinkを使用するアプリケーションは、JTAトランザクションのコンテキストで実行します。データ・ソースの名前は、persistence.xmlファイルのjta-data-source要素に指定します。アプリケーションがトランザクションのコンテキストで実行されない場合は、resource-localと見なされます。この場合は、non-jta-data-source要素に、データ・ソースの名前を指定します。

XMLスキーマなどのリレーショナル・データベース以外のデータ・ソースも指定できます。

詳細は、第8章「データ・アクセスの理解」を参照してください。

アプリケーションは、スタンドアロン(Java SE)・モードで実行できます。このモードでは、非JTA準拠のデータ・ソースとともに、非Oracleスタックにおいて、サーバーの外部でアプリケーションが実行されます。この場合、JDBCドライバ・クラス、データベースに接続するためにクライアントが使用するURL、データベースにアクセスするためのユーザー名とパスワードなどのドライバ固有の情報を指定する必要があります。アプリケーションをスタンドアロン・モードで実行する方法の詳細および例は、『Oracle Fusion Middleware Oracle TopLinkソリューション・ガイド』のコンテナ外部でのTopLink JPAのテストに関する項を参照してください。

2.1.5 EclipseLinkキャッシュについて

EclipseLinkのデフォルトでは、読み取られて永続性ユニットに対して永続化されたすべてのオブジェクトのサブセットがキャッシュされる、共有オブジェクト・キャッシュが使用されます。共有キャッシュは、ローカルのEntityManagerキャッシュとは異なります。共有キャッシュは、永続性ユニット(EntityManagerFactoryまたはサーバー)の期間存在し、永続性ユニットのすべてのEntityManagerおよびユーザーによって共有されます。ローカルのEntityManagerキャッシュは共有されず、EntityManagerまたはトランザクションの期間のみ存在します。

共有キャッシュの利点は、オブジェクトを読み取ると、同じオブジェクトを再度読み取る際にデータベースにアクセスする必要がないことです。また、問合せを使用してオブジェクトを読み取る場合は、オブジェクトを再作成する必要はなく、オブジェクトの関係も再度フェッチする必要がありません。

共有キャッシュの制限は、JDBC経由または別のアプリケーションやサーバーによってデータベースが直接変更されると、共有キャッシュのオブジェクトが失効することです。

EclipseLinkには、失効データを扱うために、次のようなメカニズムが用意されています。

  • リフレッシュ

  • 無効化

  • オプティミスティック・ロック

  • キャッシュ・コーディネーション

  • データベース変更通知(DCN)

共有キャッシュは無効にしたり、@Cacheまたは@Cacheable注釈を使用して、選択的に有効化または無効化することもできます。EclipseLinkには、キャッシュするオブジェクト数および使用するメモリー量を構成するためのキャッシュ戦略もいくつか用意されています。

キャッシュが最新でないことをアプリケーションが検出した場合、アプリケーションはプログラムでキャッシュをクリア、リフレッシュまたは無効化できます。キャッシュされているオブジェクトのいずれかが使用中の場合にキャッシュをクリアすると、オブジェクト・アイデンティティの問題が発生する場合があるので、無効化する方が安全です。キャッシュされているオブジェクトのいずれも使用中でないことがわかっている場合は、キャッシュをクリアできます。

詳細は、第9章「キャッシュの理解」を参照してください。

2.1.5.1 キャッシュ動作の定義

EclipseLinkには、キャッシュ・プロパティを定義できる@Cache注釈が用意されています。プロパティには、キャッシュのタイプ、サイズ、リフレッシュ・ルールなどが含まれます。『Oracle Fusion Middleware Oracle TopLink Java Persistence API (JPA)拡張機能リファレンス』を参照してください。

2.1.5.2 クラスタ環境でのキャッシング

あるサーバーでの変更は他のサーバーにキャッシュされているオブジェクトには反映されないため、クラスタ環境でのキャッシングでは問題が発生する場合があります。これは、読取り専用オブジェクトでは問題になりませんが、頻繁に更新されるオブジェクトでは問題になります。

EclipseLinkには、この問題に対する解決策がいくつか用意されています。

  • 頻繁に変更されるクラスに対してはキャッシュを無効にできます。

  • キャッシュ・コーディネーションを使用して、クラスタ内のサーバー間で変更をブロードキャストして、変更されたオブジェクトを更新または無効化できます。

  • 存続時間または時刻に基づいてキャッシュを無効化できます。

  • オプティミスティック・ロックを使用して、無効なオブジェクトへの更新を防ぎ、キャッシュ内でオブジェクトが無効化されるようにトリガーすることができます。

詳細は、9.11.4項「コーディネートされたキャッシュおよびクラスタリング」を参照してください。

2.1.6 データベース問合せについて

EclipseLinkのオブジェクト・リレーショナル・コンポーネントは、様々な問合せをサポートしています。

  • JPQL問合せ

  • SQL問合せ

  • Criteria API問合せ

  • ネイティブSQL問合せ

  • EclipseLink JPA問合せヒント

  • 問合せのキャスト

  • 問合せ用のOracle拡張機能

  • 拡張EclipseLinkネイティブ問合せ

これらの問合せの詳細は、第10章「問合せの理解」を参照してください。

2.2 Object-XMLマッピングについて

EclipseLinkによって提供されるObject-XMLコンポーネントでは、JavaクラスをXMLスキーマに効率的にバインドできます。Object-XMLではJAXBが実装されるので、注釈でマッピング情報を提供でき、マッピングをXML形式で保存できます。

JAXB (Java Architecture for XML Binding—JSR 222)は、JavaのXMLバインディングの標準です。JAXBでは、XMLスキーマの概念が100%カバーされています。EclipseLinkでは、JAXBの実装が多くの拡張機能とともに提供されています。

EclipseLink Object-XMLをJAXBプロバイダとして使用する際には、既存のオブジェクト・モデルをXMLに変換するためのメタデータは不要です。XML表記を微調整する必要がある場合は、(注釈またはXMLを使用して)メタデータを指定できます。

Object-XMLには、Javaクラス・モデルでスキーマをミラーリングしなくても、複雑なXML構造を処理できる高度なマッピングが多数含まれています。

詳細は、『Oracle Fusion Middleware Oracle TopLinkによるJAXBアプリケーションの開発』を参照してください。

次の各項で、これらの機能の多くについて説明します。

2.2.1 JAXBプロバイダとしてのEclipseLink Object-XMLの使用

Object-XMLをJAXBプロバイダとして使用するには、JAXBランタイムへのエントリ・ポイントを指定する必要があります。このエントリ・ポイントは、EclipseLink JAXBContextFactoryクラスです。

jaxb.propertiesというテキスト・ファイルを作成して、JAXBContextFactoryクラスへのパスをjavax.xml.bind.context.factoryコンテキスト・パラメータの値として、次のように入力します。

javax.xml.bind.context.factory=org.eclipse.persistence.jaxb.JAXBContextFactory 

jaxb.propertiesファイルは、ドメイン・クラスと同じパッケージに存在する必要があります。

2.2.2 Object-XMLのアーキテクチャの理解

図2-2に示されているObject-XMLのサンプル・アーキテクチャでは、開始点はXMLスキーマになっています。バインディング・コンパイラは、スキーマから導出されたプログラム・クラスおよびインタフェースのセットにソース・スキーマをバインドします。アプリケーション内のJAXBの注釈が付いたクラスは、スキーマ・コンパイラで生成されるか、開発者がJAXB注釈を既存のJavaクラスに追加した結果によって生成されます。アプリケーションは、データをXML文書にマーシャリングするか、データをコンテンツ・オブジェクトのツリーにアンマーシャリングできます。各コンテンツ・オブジェクトは、導出されたスキーマ、またはスキーマ・ジェネレータによってマップされた既存のプログラム要素のどちらかのインスタンスで、XML内のインスタンスに対応しています。

図2-2 Object-XMLのサンプル・アーキテクチャ

Object-XMLプロジェクト内のプロセス。
「図2-2 Object-XMLのサンプル・アーキテクチャ」の説明

2.2.2.1 JAXBコンテキストおよびJAXBコンテキスト・ファクトリ

JAXBContextFactoryクラスは、EclipseLink JAXBランタイムへのエントリ・ポイントです。これは、必須のファクトリ・メソッドを提供し、JAXBContextオブジェクトの新しいインスタンスを作成できます。

JAXBContextFactoryクラスでは、次のことが可能です。

  • クラスの配列およびプロパティ・オブジェクトからのJAXBContextオブジェクトの作成

  • コンテキスト・パスおよびクラスローダーからのJAXBContextオブジェクトの作成

JAXBContextクラスは、JAXB APIに対するクライアントのエントリ・ポイントを提供します。JAXBContextクラスは、メタデータの解釈、スキーマ・ファイルの生成、およびJAXBオブジェクト(MarshallerUnmarshallerBinderIntrospectorおよびValidator)のインスタンスの作成を行います。

Object-XMLには、JAXBContextオブジェクトを作成する際にいくつかのオプションが用意されています。次のいずれかから開始できます。

  • JAXBの注釈の付いた1つ以上のクラスのリスト

  • Javaクラスのマッピングが定義された1つ以上のEclipseLink XMLバインディング・ドキュメントのリスト

  • クラスとXMLバインディングの組合せ

  • コンテキスト・パスのリスト

  • sessions.xmlに定義されているEclipseLinkセッションを参照するセッション名のリスト

2.2.3 Object-XMLに対するメタデータの提供

2.2.2.1項「JAXBコンテキストおよびJAXBコンテキスト・ファクトリ」に説明されている入力オプションに加えて、Object-XMLには、MetadataSourceオブジェクトの概念が用意されています。このオブジェクトによって、マッピング情報をアプリケーションの外部に保存して、アプリケーションのJAXBContextオブジェクトが作成またはリフレッシュされるときにそれを取得できるようになります。MetadataSourceの実装の詳細は、『Oracle Fusion Middleware Oracle TopLinkによるJAXBアプリケーションの開発』を参照してください。

2.2.4 XMLバインディングについて

EclipseLinkでは、すべての標準JAXB注釈を使用できます。EclipseLinkには、標準注釈に加えて、EclipseLink XMLバインディング・ドキュメントという、メタデータを表現する別の方法も用意されています。XMLバインディングは、マッピング情報を実際のJavaクラスから分離できるだけでなく、次のような高度なメタデータ・タスクにも使用できます。

  • 追加のマッピング情報で、既存の注釈を拡張またはオーバーライドできます。

  • Java注釈を使用せずに、すべてのマッピング情報を外部指定できます。

  • 複数のバインディング文書にまたがるマッピングを定義できます。

  • 具体的なJavaフィールドに対応しない仮想マッピングを指定できます。

詳細は、『Oracle Fusion Middleware Oracle TopLinkによるJAXBアプリケーションの開発』を参照してください。

2.2.4.1 eclipselink-oxm.xmlを使用したEclipseLink Object-XMLマッピングの指定

Java注釈を使用して、プロジェクトにJAXBの機能を指定できます。EclipseLinkには、Java注釈に加えて、eclipselink-oxm.xmlというXMLマッピング構成ファイルが用意されています。このマッピング・ファイルには、標準のJAXBマッピングと、高度なマッピング・タイプ用の構成オプションが含まれています。eclipselink-oxm.xmlファイルを、ソース・コードのJAXB注釈のかわりに使用するか、JAXB注釈をオーバーライドするために使用できます。


注意:

このマッピング・ファイルを使用すると、多くの高度な機能が有効になりますが、他のJAXB実装に対するモデルの移植性がなくなる場合があります。


2.2.5 Object-XMLデータ・タイプ・マッピングについて

XMLマッピングは、オブジェクトのデータ・メンバーを、構造がXMLスキーマ・ドキュメント(XSD)により定義されているXML文書のXML要素に変換します。様々なXMLマッピング・タイプを使用して、XMLの単純および複合型の組合せにJavaオブジェクトの属性をマップできます。

クラスは複合型にマップされ、オブジェクトの関係はXML要素にマップされ、単純属性はテキスト・ノードとXML属性にマップされます。Object-XMLを使用する場合の真価は、オブジェクト属性をXML文書にマッピングする際に、XPath文を使用してXMLデータの場所を指定できることにあります。

EclipseLinkでは、クラスのディスクリプタに各クラスのXMLマッピングを格納します。EclipseLinkでは、ディスクリプタを使用してXML文書からマップされたオブジェクトをインスタンス化し、新規または変更済のオブジェクトをXML文書として格納します。

EclipseLinkには、JAXB仕様には定義されていないXMLマッピングが用意されています。Object-XMLの拡張機能には、EclipseLinkの注釈を介して使用できるものと、基礎となるメタデータに対するプログラムの変更が必要なものがあります。

これらのマッピングの詳細は、『Oracle Fusion Middleware Oracle TopLinkによるJAXBアプリケーションの開発』を参照してください。

2.2.6 XPathによるオブジェクトの問合せ

EclipseLink Object-XMLでは、従来のJavaのアクセス・メソッドを使用してオブジェクトの値を取得および設定する方法に加えて、XPath文を使用して値にアクセスすることもできます。EclipseLinkのJAXBContextオブジェクトには、XPathで値を取得および設定できる特別なAPIがあります。詳細は、『Oracle Fusion Middleware Oracle TopLinkによるJAXBアプリケーションの開発』を参照してください。