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

前
 
次
 

5 アプリケーション・デプロイメントの理解

パッケージ化とは、アプリケーションがアプリケーション・サーバーにデプロイされるとき、またはスタンドアロンJVMで実行されるときに、インフラストラクチャが正しく解釈して使用できる方法で、アプリケーションのすべての要素を組み合せることです。

詳細は、JPA仕様の第6章「Entity Packaging」を参照してください。

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

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

5.1 アプリケーション・サーバーとの統合

この項では、次のようなアプリケーション・サーバーの統合に固有の概念について説明します。

5.1.1 ソフトウェア要件

EclipseLinkアプリケーションをJava EEコンテナ内で実行するには、システムが次のソフトウェア要件を満たしている必要があります。

  • アプリケーション・サーバーまたはJava EEコンテナ

  • XMLパーサー

  • ローカル・データベース・システムに接続するように構成されたJDBCドライバ(詳細は、使用しているデータベースの管理ドキュメントを参照)

  • 次のいずれか:

    • Sun JDK 1.6以上と互換性のある任意のJava環境

    • コマンドラインのJVM実行可能ファイル(java.exejre.exeなど)

5.1.2 セキュリティ・パーミッションの設定

デフォルトでは、デフォルトでないjava.lang.SecurityManagerで構成されたJVMでアプリケーションを実行すると、ランタイム環境は、java.security.AccessControllerメソッドdoPrivilegedPrivilegedActionを実行して、特定の内部関数を実行します。これにより、EclipseLinkがその大部分の共通の操作を実行するために、EclipseLinkに多くのパーミッションを付与する必要がなくなります。使用するオプションの機能のタイプに応じて、特定のパーミッションを付与するだけで済みます。

デフォルトでないSecurityManagerのないJVMでEclipseLink対応アプリケーションを実行する場合は、パーミッションを設定する必要はありません。詳細は、『Oracle Fusion Middleware Oracle TopLinkソリューション・ガイド』のOracle DatabaseでのOracle TopLinkの使用に関する項を参照してください。『Oracle Databaseセキュリティ・ガイド』およびOracle Label Security管理者ガイドも参照してください。

5.1.3 EclipseLink永続性マネージャへのアプリケーションの移行

EclipseLinkを永続性マネージャとして使用するように、アプリケーション・サーバーを構成できます。JARファイルに含まれるコンテナ管理の永続性を備えたすべてのエンティティに対して、ただ1つの永続性マネージャのみを使用できます。

5.2 永続性ユニットについて

永続性ユニットでは、エンティティ・マネージャを取得する際に必要な詳細を定義します。EclipseLink JPAアプリケーションをパッケージ化するには、persistence.xmlファイルの作成時に永続性ユニットを構成する必要があります。各永続性ユニットは、persistence.xmlファイルのpersistence-unit要素で定義します。

persistence.xmlファイルを使用して、エンティティをパッケージ化します。パッケージ化方針を選択したら、任意のアーカイブのMETA-INFディレクトリにpersistence.xmlファイルを配置します。次の項では、永続性ユニットの指定方法の詳細について説明します。詳細および例は、JPA仕様の「persistence.xml file」を参照してください。persistence.xmlファイルに対するEclipseLinkの拡張機能の詳細は、『Oracle Fusion Middleware Oracle TopLink Java Persistence API (JPA)拡張機能リファレンス』の永続性プロパティの拡張機能リファレンスに関する項を参照してください。

5.2.1 永続性ユニット名について

Java EE環境でアプリケーションを開発する場合、永続性ユニット名が各モジュール内で一意であることを確認してください。たとえば、emp_ejb.jarファイル内で定義できるEmployeeServiceという名前の永続性ユニットは、1つのみです。

詳細は、JPA仕様の「name」を参照してください。

5.2.2 トランザクション・タイプ、永続性プロバイダおよびデータ・ソースについて

Java EE環境でアプリケーションを開発する場合、デフォルトのトランザクション・タイプであるJTAを受け入れ、永続性プロバイダ設定については、provider要素に永続性プロバイダを設定します。データ・ソースは、jta-data-source要素に指定します。

詳細は、JPA仕様の「transaction-type」および「provider」を参照してください。

5.2.3 マッピング・ファイルについて

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

詳細は、JPA仕様の「mapping-file, jar-file, class, exclude-unlisted-classes」を参照してください。

5.2.4 管理対象クラスについて

通常、すべてのエンティティおよび他の管理対象クラスは、単一のJARファイルと、META-INFディレクトリのpersistence.xmlファイルおよび1つ以上のマッピング・ファイルに配置します(XMLにメタデータを格納する場合)。

EclipseLink永続性プロバイダは、永続性ユニットを処理するときに、特定の各永続性ユニットで管理するエンティティ、マップ済スーパークラスおよび埋込みオブジェクトのセットを特定します。

EclipseLink永続性プロバイダは、デプロイ時に、次のいずれかのソースから管理対象クラスを取得できます。管理対象クラスは、次のいずれかである場合に含まれます。

  • ローカル・クラス: persistence.xmlファイルがパッケージ化されているデプロイメント・ユニットの@Entity@MappedSuperclassまたは@Embeddable注釈付きのクラス。詳細は、JPA仕様の「Entity」を参照してください。


    注意:

    アプリケーションをJava EE環境にデプロイする場合、EclipseLink永続性プロバイダではなくアプリケーション・サーバー自体によってローカル・クラスが検出されます。Java SE環境で、exclude-unlisted-classes要素をfalseに設定すると、この機能を有効化できます(この要素をfalseに設定すると、EclipseLink永続性プロバイダによってローカル・クラスの検出が試行されます)。JPA仕様の「mapping-file, jar-file, class, exclude-unlisted-classes」を参照してください。


  • マッピング・ファイルのクラス: XMLマッピング・ファイルのentity (JPA仕様の「entity」を参照)、mapped-superclass、embeddableなどのマッピング・エントリを持つクラス。詳細は、JPA仕様の「mapped-superclass」および「embeddable」を参照してください。

    デプロイされたコンポーネント・アーカイブにこれらのクラスが含まれる場合、それらはすでにクラスパスに存在します。存在しない場合、それらを明示的にクラスパスに含める必要があります。

  • 明示的にリストされたクラス: persistence.xmlファイルにclass要素としてリストされているクラス。

    次のいずれかの場合、クラスを明示的にリストすることを検討してください。

    • デプロイメント・ユニットのJARにローカルではない追加クラスが存在する場合。たとえば、永続性ユニットのエンティティで使用する異なるJARに埋込みオブジェクト・クラスが存在する場合です。この場合、persitence.xmlファイルのclass要素に完全修飾されたクラスをリストします。また、クラスを含むJARまたはディレクトリが、デプロイ済のコンポーネントのクラスパスに含まれることを確認する必要があります(たとえば、デプロイメントJARのマニフェスト・クラスパスにそれを追加します)。

    • エンティティとして注釈を付けることのできる1つ以上のクラスを除外する場合。クラスに@Entity注釈を付けることができても、デプロイされた特定のコンテキストでそれをエンティティとして扱いません。たとえば、特定のエンティティを転送オブジェクトとして使用し、デプロイメント・ユニットの一部にする必要がある場合です。この場合、Java EE環境で、persistence.xmlファイルのexclude-unlisted-classes要素を使用する必要があります(この要素のデフォルト設定の使用によって、ローカル・クラスが永続性ユニットに追加されなくなります)。詳細は、JPA仕様の「mapping-file, jar-file, class, exclude-unlisted-classes」を参照してください。

    • アプリケーションをJava SE環境で実行する予定で、Java SEでそれ以外に移植可能な方法がないため、クラスを明示的にリストする場合。

  • 管理対象クラスの追加のJARファイル: persistence.xmlファイルのjar-file要素にリストされている名前付きJARファイルの注釈付きクラス。詳細は、JPA仕様の「mapping-file, jar-file, class, exclude-unlisted-classes」を参照してください。

    jar-file要素にリストされているJARファイルが、デプロイメント・ユニットのクラスパスに含まれることを確認する必要があります。これを行うには、デプロイメント・ユニットのマニフェスト・クラスパスに手動でJARファイルを追加します。

    jar-file要素のJARファイルは、persistence.xmlファイルが存在しているJARファイルの親を基準としてリストする必要があることに注意してください。これは、マニフェスト・ファイルのクラスパス・エントリに指定する内容と一致します。

5.2.5 ベンダー・プロパティについて

persistence.xmlファイルの最後のセクションは、propertiesセクションです。properties要素によって、永続性ユニットに対してEclipseLink永続性プロバイダ固有の設定を指定できます。JPA仕様の「properties」を参照してください。『Oracle Fusion Middleware Oracle TopLink Java Persistence API (JPA)拡張機能リファレンス』の永続性プロパティの拡張機能リファレンスに関する項も参照してください。

5.2.6 デプロイメント・クラスパスについて

EJB JAR、WARまたはEARファイルにアクセスできるようにするには、クラスまたはJARファイルがデプロイメント・クラスパスに含まれる必要があります。これは次のいずれかの方法で可能になります。

  • JARファイルをEJB JARまたはWARファイルのマニフェスト・クラスパスに配置します。

    これを行うには、JARまたはWARファイルのMETA-INF/MANIFEST.MFファイルにクラスパス・エントリを追加します。空白で区切ることで、1つ以上のディレクトリまたはJARファイルを指定できます。

  • EARファイルのライブラリ・ディレクトリにJARファイルを配置します。

    これによって、アプリケーション・クラスパスでJARファイルを使用できるようになり、EARファイル内にデプロイされたすべてのモジュールからアクセス可能になります。デフォルトでは、これはEARファイルのlibディレクトリになりますが、application.xmlデプロイメント・ディスクリプタのlibrary-directory要素を使用して、EARファイルの任意のディレクトリとなるように構成できます。

5.2.7 永続性ユニットのパッケージ・オプションについて

Java EEでは、様々なパッケージ構成で永続性がサポートされます。アプリケーションは、次のモジュール・タイプにデプロイできます。

  • EJBモジュール: エンティティをEJB JARにパッケージ化できます。EJB JARで永続性ユニットを定義する場合、persistence.xmlファイルはオプションではなく、それを作成してデプロイメント・ディスクリプタ(存在する場合)とともにJARのMETA-INFディレクトリに配置する必要があります。

  • Webモジュール: WARファイルを使用してエンティティをパッケージ化できます。この場合、WEB-INF/classes/META-INFディレクトリにpersistence.xmlファイルを配置します。WARのクラスパスにWEB-INF/classesディレクトリが自動的に含まれるため、そのディレクトリを基準としてマッピング・ファイルを指定します。

  • 永続性アーカイブ: 永続性アーカイブは、META-INFディレクトリにpersistence.xmlファイルを含み、そのpersistence.xmlで定義された永続性ユニットの管理対象クラスを含むJARです。異なるJava EEモジュールの複数のコンポーネントで永続性ユニットを共有するか、それにアクセスする場合、永続性アーカイブを使用します。

    永続性アーカイブを作成したら、それをEARのルートまたはアプリケーション・ライブラリ・ディレクトリに配置できます。または、永続性アーカイブをWARのWEB-INF/libディレクトリに配置することもできます。この場合、永続性ユニットにアクセスできるのは、WAR内のクラスのみになりますが、永続性ユニットの定義とWebアーカイブ自体を分離することができます。

詳細は、JPA仕様の「Persistence Unit Packaging」を参照してください。

5.2.8 永続性ユニットの有効範囲について

1つのpersistence.xmlファイルに任意の数の永続性ユニットを定義できます。次に、定義済およびパッケージ化済の永続性ユニットを使用するためのルールを示します。

  • 永続性ユニットには、その定義の有効範囲内でのみアクセス可能です。

  • 永続性ユニット名は、その有効範囲内で一意である必要があります。

詳細は、JPA仕様の「Persistence Unit Scope」を参照してください。

5.3 クラスタリングの統合

大部分のアプリケーション・サーバーは、TopLinkアプリケーションで利用できるクラスタリング・サービスを備えています。

アプリケーション・サーバーのクラスタでTopLinkを使用するには、次の一般的な手順を実行します。

  1. 各アプリケーション・サーバーにあるtoplink.jarファイルを、TopLinkアプリケーションをデプロイするためのクラスタにインストールして、このファイルをクラスパスに含めます。

  2. アプリケーションに適したキャッシュの一貫性オプションを構成します。

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

  3. アプリケーション・サーバーに対するコーディネート・キャッシュのサポートを構成します(存在する場合)。

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

  4. 各アプリケーション・サーバーでクラスタリングを構成します。

    詳細は、アプリケーション・サーバーのドキュメントを参照してください。