WebLogic Server アプリケーションの開発
|
 |
 |
|
以下の節では、共有 J2EE ライブラリとオプション パッケージを使用してアプリケーション間でコンポーネントとクラスを共有する方法について説明します。
9.0 以前の WebLogic Server では、複数のエンタープライズ アプリケーションが J2EE の 1 つまたは複数のモジュールを簡単に共有することはできませんでした。J2EE モジュールを共有するには、モジュールのコピーを複数の EAR にパッケージ化するか、共有モジュールのパスをシステム クラスパスに追加して、共有モジュールのデプロイメント記述子の複製を参照側の各アプリケーションに追加する必要がありました。共有モジュールの更新には、そのモジュールを使用するすべてのエンタープライズ アプリケーションを再コピーして再パッケージ化する必要があったので、モジュールをコピーする方法では、以降のアプリケーションの更新が厄介な作業となりました。システム クラスパスにモジュールを追加する方法も同様で、更新したモジュールを使用するには、WebLogic Server インスタンスを再起動する必要がありました。
WebLogic Server 9.0 の共有 J2EE ライブラリ機能では、複数のエンタープライズ アプリケーション間で、1 つまたは複数の種類の J2EE モジュールを簡単に共有できます。共有 J2EE ライブラリは、デプロイメントに際して J2EE アプリケーション コンテナに登録される 1 つまたは複数のモジュールです。共有 J2EE ライブラリは以下のいずれかです。
共有 J2EE ライブラリを適切なアーカイブ ファイル (EAR、JAR、または WAR) にパッケージ化することをお勧めします。ただし、開発目的の場合、展開されたアーカイブ ディレクトリとして共有 J2EE ライブラリをデプロイすれば、更新と再デプロイメントの繰り返しを簡単にすることができます。
共有 J2EE ライブラリを登録後、そのライブラリを参照するエンタープライズ アプリケーションをデプロイできます。参照側の各アプリケーションは、デプロイメントの際に必要なライブラリへの参照を受け取り、参照側アプリケーション自体の一部としてパッケージ化されているかのように、ライブラリを構成するモジュールを使用できます。参照側アプリケーションのクラスパスに、ライブラリ クラスが追加され、参照側アプリケーションのデプロイメント記述子は、共有 J2EE ライブラリを構成するモジュールのデプロイメント記述子と (メモリ内で) 結合されます。
このトピックでは、大部分において、エンタープライズ アプリケーションでのみ参照可能な共有 J2EE ライブラリについて説明しています。ただし、別の Web アプリケーションでのみ参照可能なライブラリを作成することもできます。このライブラリの機能はアプリケーション ライブラリと非常に似ていますが、参照方法が多少異なります。詳細については、「Web アプリケーション共有 J2EE ライブラリの情報」を参照してください。
注意 : WebLogic Server 9.0 では、ドメイン ディレクトリの lib サブディレクトリを使用して、WebLogic Server システム クラスパスに 1 つまたは複数の JAR ファイルを追加するという簡単な方法も利用できます。「システム クラスパスへの JAR の追加」を参照してください。
WebLogic Server は、J2EE 1.4 仕様 の節 8.2「Optional Package Support」に記載のとおり、オプション パッケージをサポートしています。バージョニングについては、「Optional Package Versioning」で説明しています。オプション パッケージは、J2EE ライブラリと似た機能を提供しており、これを使用すると複数のアプリケーション間で単一の JAR ファイルを簡単に共有できます。J2EE ライブラリの場合、最初に、関連する JAR ファイルをオプション パッケージとしてデプロイし、WebLogic Server にオプション パッケージを登録する必要があります。パッケージを登録したら、そのマニフェスト ファイルでパッケージを参照する J2EE モジュールをデプロイできます。
オプション パッケージは、どの J2EE モジュール (EAR、JAR、WAR、または RAR アーカイブ) または展開されたアーカイブ ディレクトリからでも参照できる点が J2EE ライブラリとは異なります。J2EE ライブラリは、有効なエンタープライズ アプリケーションからのみ参照できます。
たとえば、複数の Web アプリケーションで必要とされるサード パーティの Web アプリケーション フレームワーク クラスを、単一の JAR ファイル内にパッケージ化およびデプロイし、ドメイン内の複数の Web アプリケーション モジュールから参照することが可能です。この場合、個々の Web アプリケーション モジュールは共有 JAR ファイルを参照する必要があるので、J2EE ライブラリではなくオプション パッケージを使用します (J2EE ライブラリの場合、完全なエンタープライズ アプリケーションのみがライブラリを参照できます)。
注意 : BEA のドキュメントと WebLogic Server ユーティリティでは、「ライブラリ」という語を J2EE ライブラリとオプション パッケージの両方の意味で使用します。必要な場合にのみオプション パッケージと呼びます。
WebLogic Server では、共有 J2EE ライブラリのバージョニングによって、参照側のアプリケーションは、使用するライブラリの最低限のバージョンを指定したり、必要なバージョンを完全一致の形で指定したりできます。WebLogic Server では、共有 J2EE ライブラリのバージョニングを、「Optional Package Versioning」の説明にある 2 種類のレベルでサポートしています。
ベスト プラクティスとして、共有 J2EE ライブラリを作成する際には、バージョン情報 (実装バージョンまたは実装バージョンと仕様バージョンの両方) を必ず含めることをお勧めします。共有コンポーネントの開発時にバージョン情報を作成および更新すると、テスト目的でコンポーネントの複数のバージョンを同時にデプロイできます。バージョン情報を指定しない場合、またはバージョン文字列のインクリメントに失敗した場合は、新しいライブラリをデプロイする前に既存のライブラリをアンデプロイする必要があります。「共有 J2EE ライブラリおよびそれに依存するアプリケーションのデプロイ」を参照してください。
参照側アプリケーションのバージョニング情報によって、そのアプリケーションで必要なライブラリとパッケージのバージョンが決まります。各アプリケーションに応じて、必要となるライブラリまたはパッケージのバージョンが異なる場合があります。たとえば、プロダクション アプリケーションがある特定のバージョンのライブラリを要求することがあります。これはそのライブラリのみがプロダクション用に完全に適しているためです。同じライブラリの最低限のバージョンを常に使用するように内部アプリケーションをコンフィグレーションできます。特定のバージョンを必要としないアプリケーションで、最新バージョンのライブラリを使用するようにコンフィグレーションすることもできます。「エンタープライズ アプリケーションでの共有 J2EE ライブラリの参照」を参照してください。
オプション パッケージと共有 J2EE ライブラリでは、以下の機能が共通しています。
オプション パッケージは、共有 J2EE ライブラリと以下の点が異なっています。
META-INF/MANIFEST.MF を使用) が、共有 J2EE ライブラリを参照できるのはエンタープライズ アプリケーションと Web アプリケーションのみである (weblogic-application.xml または weblogic.xml を使用)。通常、1 つまたは複数の EJB、Web アプリケーション、またはエンタープライズ アプリケーションを複数のエンタープライズ アプリケーション間で共有する場合は、共有 J2EE ライブラリを使用します。1 つまたは複数の (JAR ファイルにパッケージ化された) クラスを複数の J2EE モジュール間で共有する場合は、オプション パッケージを使用します。
プレーン JAR ファイルは、ライブラリとしてもオプション パッケージとしても共有できます。以下の場合には、オプション パッケージを使用します。
1 つまたは複数のエンタープライズ アプリケーションから JAR ファイルを参照するだけで、J2EE 仕様に厳密に準拠する必要がない場合は、共有 J2EE ライブラリを使用してプレーン JAR ファイルを共有します。
注意 : BEA のドキュメントと WebLogic Server ユーティリティでは、「共有 J2EE ライブラリ」という語を J2EE ライブラリとオプション パッケージの両方の意味で使用します。必要な場合にのみオプション パッケージと呼びます。
管理者側から見た共有 J2EE ライブラリ、オプション パッケージ、および参照側アプリケーションのデプロイおよび管理の詳細については、『WebLogic Server 9.0 アプリケーションのデプロイメント』の「共有 J2EE ライブラリおよびそれに依存するアプリケーションのデプロイ」を参照してください。
複数のアプリケーションで共有可能な新しい共有 J2EE ライブラリを作成するには、次の手順に従います。
「共有 J2EE ライブラリ ファイルの作成」を参照してください。
「オプション パッケージ クラス ファイルの作成」を参照してください。
「共有 J2EE ライブラリのマニフェスト属性の編集」を参照してください。
「配布およびデプロイメント用共有 J2EE ライブラリのパッケージ化」を参照してください。
以下の種類の J2EE モジュールを共有 J2EE ライブラリとしてデプロイできます。
共有 J2EE ライブラリを、スタンドアロン J2EE モジュールではなく、エンタープライズ アプリケーションとしてパッケージ化することをお勧めします。これは、スタンドアロン モジュールの URI がデプロイメント名から派生しており、モジュールがどのようにデプロイされたかによって変わる可能性があるためです。デフォルトでは、WebLogic Server はデプロイメント アーカイブ ファイル名または展開されたアーカイブ ディレクトリ名をデプロイメント名として使用します。別のファイルまたは場所からスタンドアロン共有 J2EE ライブラリを再デプロイする場合、デプロイメント名と URI も変わり、誤った URI を使用している参照側アプリケーションは、デプロイされたライブラリにアクセスできません。
スタンドアロン J2EE モジュールとして共有 J2EE ライブラリをデプロイする場合は、デプロイメント時に既知のデプロイメント名を必ず指定し、参照側アプリケーションでその名前を URI として使用します。
任意のクラスのセットをオプション パッケージ ファイルにまとめることができます。共有クラスのコレクションは、最終的に標準 JAR アーカイブにパッケージ化されます。ただし、JAR のマニフェスト ファイルを編集する必要があるので、最初にすべてのクラス ファイルを作業ディレクトリに作成します。
mkdir /apps/myOptPkg
mkdir -p /apps/myOptPkg/org/myorg/myProduct
cp /build/classes/myOptPkg/org/myOrg/myProduct/*.class /apps/myOptPkg/org/myOrg/myProduct
cd /apps/myOptPkg
jar xvf /build/libraries/myLib.jar
共有 J2EE ライブラリの名前とバージョン情報は、META-INF/MANIFEST.MF ファイルで指定します。表 8-1 では、有効な共有 J2EE ライブラリ マニフェストの属性を示します。
|
|
|
|
|
|
|
|
マニフェスト ファイルの属性を指定するには、次の手順に従います。
cd /apps/myLibrary
mkdir META-INF
emacs META-INF/MANIFEST.MF
Extension-Name: myExtension
Extension-Name: myExtension
Specification-Version: 2.0
Implementation-Version: 9.0.0
バージョン識別子に対してメジャー/マイナー フォーマットを使用すると、別のアプリケーションからライブラリを参照する際に最も柔軟な指定が可能です (表 8-1 を参照)。
注意 : デプロイ時に必要に応じてコマンドラインで Specification-Version および Implementation-Version を指定できますが、これらの文字列を MANIFEST.MF ファイルで指定しておくことをお勧めします。マニフェストにバージョン文字列を指定すると、旧バージョンと並行して新しいバージョンのライブラリをデプロイできるようになります。「共有 J2EE ライブラリおよびそれに依存するアプリケーションのデプロイ」を参照してください。
管理者によるデプロイメント用に共有 J2EE ライブラリまたはオプション パッケージを配布する場合、デプロイメント ファイルをアーカイブ ファイル (共有 J2EE ライブラリの場合は .EAR ファイルまたはスタンドアロン モジュール アーカイブ ファイル、オプション パッケージの場合は単純な .JAR ファイル) にパッケージ化して配布します。「分割開発ディレクトリからのデプロイメントとパッケージ化」を参照してください。
共有 J2EE ライブラリは標準 J2EE アプリケーションまたはスタンドアロン モジュールとしてパッケージ化されるので、『WebLogic Server 9.0 アプリケーションのデプロイメント』で説明されているように、ライブラリのデプロイメント コンフィグレーションをデプロイメント プランにエクスポートすることもできます。オプション パッケージ .JAR ファイルにはデプロイメント記述子が含まれていないので、エクスポートすることはできません。
開発目的で、展開されたアーカイブ ディレクトリとしてライブラリをデプロイすると、更新と再デプロイメントの繰り返しが簡単になります。
J2EE アプリケーションは、アプリケーションの weblogic-application.xml デプロイメント記述子のエントリを基に、登録された共有 J2EE ライブラリを参照できます。表 8-2 では、ライブラリ参照を定義する XML 要素を示します。
表 8-2 weblogic-application.xml の共有 J2EE ライブラリ参照用の要素
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
たとえば、次の weblogic-application.xml 記述子の単純なエントリでは、共有 J2EE ライブラリ myLibrary を参照します。
<library-ref>
<library-name>myLibrary</library-name>
</library-ref>
上記の例では、WebLogic Server は、依存関係にあるアプリケーションをデプロイする際に myLibrary というライブラリを探します。myLibrary のコピーが複数登録されている場合、WebLogic Server は、最新の仕様バージョンのライブラリを選択します。選択した仕様バージョンを複数のライブラリのコピーが使用している場合、WebLogic Server は、最新の実装バージョンのコピーを選択します。
次の例では、仕様バージョンの要件を指定して共有 J2EE ライブラリを参照します。
<library-ref>
<library-name>myLibrary</library-name>
<specification-version>2.0</specification-version>
</library-ref>
上記の例では、WebLogic Server は、仕様バージョン 2.0 以降のライブラリを探します。バージョン 2.0 以降のライブラリが複数ある場合、WebLogic Server は、実装バージョンに Float 値を使用しているライブラリを調べ、最新バージョンを選び出します。WebLogic Server は、実装バージョンに Float 以外の値を使用している選択ライブラリを無視します。
次の例では、仕様バージョンと非 Float 値の実装バージョンの両方を指定して共有 J2EE ライブラリを参照します。
<library-ref>
<library-name>myLibrary</library-name>
<specification-version>2.0</specification-version>
<implementation-version>81Beta</specification-Version>
</library-ref>
上記の例では、WebLogic Server は、仕様バージョンが 2.0 以降で、実装バージョンが 81Beta に完全一致するライブラリを探します。
次の例では、仕様バージョンと実装バージョンの両方が完全一致しなければならないケースを示します。
<library-ref>
<library-name>myLibrary</library-name>
<specification-version>2.0</specification-version>
<implementation-version>8.1</specification-Version>
<exact-match>true</exact-match>
</library-ref>
スタンドアロン モジュール (EJB または Web アプリケーション) としてデプロイされた共有 J2EE ライブラリの URI を参照する場合、モジュール URI は、共有 J2EE ライブラリのデプロイメント名に対応している必要があります。これは、デプロイメント時に手動で割り当てた名前でも、デプロイされたアーカイブ ファイルの名前でも、デプロイされた展開アーカイブ ディレクトリの名前でも構いません。同じモジュールを異なるファイル名で、または別の場所から再デプロイする場合、デフォルト デプロイメント名も変わるので、適切な URI を使用するように参照側アプリケーションを更新する必要があります。
この問題を避けるには、すべての共有 J2EE ライブラリを、スタンドアロン モジュールではなく、エンタープライズ アプリケーションとしてパッケージ化します。スタンドアロン J2EE モジュールとしてライブラリをデプロイする場合は、既知のデプロイメント名を必ず指定し、参照側アプリケーションでその名前を URI として使用します。
J2EE アーカイブ (JAR、WAR、RAR、EAR) は、アーカイブのマニフェスト ファイルの属性を使用して 1 つまたは複数の登録済みオプション パッケージを参照できます。
|
|
|
|
|
|
|
|
|
|
|
たとえば、依存関係のあるアーカイブの場合、マニフェスト ファイルの以下の単純なエントリでは、myAppPkg および my3rdPartyPkg という 2 つのオプション パッケージを参照します。
Extension-List: internal 3rdparty
internal-Extension-Name: myAppPkg
3rdparty-Extension-Name: my3rdPartyPkg
次の例では、仕様バージョン 2.0 以降の myAppPkg を要求します。
Extension-List: internal 3rdparty
internal-Extension-Name: myAppPkg
3rdparty-Extension-Name: my3rdPartyPkg
internal-Specification-Version: 2.0
次の例では、仕様バージョン 2.0 以降の myAppPkg、実装バージョンが完全一致する my3rdPartyPkg を要求します。
Extension-List: internal 3rdparty
internal-Extension-Name: myAppPkg
3rdparty-Extension-Name: my3rdPartyPkg
internal-Specification-Version: 2.0
3rdparty-Implementation-Version: 8.1GA
デフォルトでは、WebLogic Server は、アプリケーションまたはモジュールをデプロイする際にマニフェスト ファイルのオプション パッケージに対する参照を解決できない場合、警告を出力しますが、デプロイメントは続行します。この動作を変更するには、WebLogic Server の起動時に、コマンド ラインまたはサーバの起動を制御するコマンド スクリプト ファイルで、システム プロパティ weblogic.application.RequireOptionalPackages を true に設定します。このシステム プロパティを true に設定すると、WebLogic Server は、マニフェスト ファイルのオプション パッケージの参照を解決できない場合にアプリケーションまたはモジュールをデプロイしません。
BuildXMLGen には、1 つまたは複数の共有 J2EE ディレクトリを含むビルド ターゲットを生成するための -librarydir オプションがあります。「weblogic.BuildXMLGen を使用した基本的な build.xml ファイルの生成」を参照してください。
wlcompile および wlappc Ant タスクには、アプリケーション ビルドのクラスパスに含める 1 つまたは複数の共有 J2EE ライブラリを指定するための librarydir 属性と library 要素があります。「分割開発ディレクトリでのアプリケーションのビルド」を参照してください。
共有 J2EE ライブラリを 1 つまたは複数の WebLogic Server インスタンスに登録するには、対象サーバにライブラリをデプロイし、デプロイメントが共有されるように指定します。共有 J2EE ライブラリは、ライブラリを参照するアプリケーションのデプロイ先と同じ WebLogic Server インスタンスに登録する必要があります。必要なライブラリを登録していないサーバ インスタンスに参照側アプリケーションをデプロイする場合、参照側アプリケーションのデプロイメントは失敗します。詳細については、『WebLogic Server 9.0 アプリケーションのデプロイメント』の「WebLogic Server でのライブラリの登録」を参照してください。
Administration Console を使用して共有 J2EE ライブラリをインストール (デプロイ) する場合の詳細な手順については、「J2EE ライブラリのインストール」を参照してください。Administration Console を使用して、ライブラリを参照するアプリケーションのデプロイ先となるサーバまたはクラスタにライブラリをデプロイする場合の手順については、「J2EE ライブラリのサーバまたはクラスタへの割り当て」を参照してください。
繰り返しの開発プロセスの一部として wldeploy Ant タスクを使用する場合は、library、libImplVer、および libSpecVer 属性を使用して共有 J2EE ライブラリをデプロイします。詳細と例については、「wldeploy Ant タスクのリファレンス」を参照してください。
共有 J2EE ライブラリを登録後、そのライブラリと依存関係にあるアプリケーションおよびアーカイブをデプロイできます。依存関係のあるアプリケーションは、対象サーバが必要なライブラリを登録しており、登録されたデプロイメントがアプリケーションまたはアーカイブのバージョン要件に従っている場合にのみデプロイできます。詳細については、『WebLogic Server 9.0 アプリケーションのデプロイメント』の「ライブラリを参照するアプリケーションのデプロイ」を参照してください。
このトピックでは、大部分において、エンタープライズ アプリケーションでのみ参照可能な共有 J2EE ライブラリについて説明しています。ただし、別の Web アプリケーションでのみ参照可能なライブラリを作成することもできます。このライブラリの機能はアプリケーション ライブラリと非常に似ていますが、参照方法が多少異なります。
注意 : 便宜上、この節では、別の Web アプリケーションでのみ参照される共有 J2EE ライブラリのことを指すのに「Web アプリケーション ライブラリ」という用語を使います。
weblogic-application.xml ファイルではなく weblogic.xml デプロイメント記述子ファイルを更新します。要素は、「エンタープライズ アプリケーションでの共有 J2EE ライブラリの参照」で説明されているものとほぼ同じです。唯一の違いは、<library-ref> の <context-root> 子要素がここでは無視されることです。weblogic.xml デプロイメント記述子ファイルから、別の種類の共有 J2EE ライブラリ (EJB、エンタープライズ アプリケーション、プレーン JAR ファイル) を参照することはできません。 こうした参照方法の違いを除けば、Web アプリケーション ライブラリを作成、パッケージ化、デプロイする方法は、通常の共有 J2EE ライブラリの場合と同じです。
デプロイされた各共有 J2EE ライブラリは、LibraryRuntimeMBean で表されます。この MBean を使用すると、名前やバージョンなど、ライブラリ自体の情報を取得できます。また、デプロイされたアプリケーションに関連付けられた ApplicationRuntimeMBean を取得することもできます。ApplicationRuntimeMBean では、アプリケーションが使用するライブラリにアクセスする際に、次の 2 種類の方法を用いることができます。
getLibraryRuntimes() は、weblogic-application.xml ファイルで参照される共有 J2EE ライブラリを返します。getOptionalPackageRuntimes() は、マニフェスト ファイルで参照されるオプション パッケージを返します。詳細については、『BEA WebLogic Server 9.0 API Reference』を参照してください。
エンタープライズ アプリケーションが 1 つまたは複数の共有 J2EE ライブラリを参照し、アプリケーションが WebLogic Server にデプロイされている場合、サーバは、内部で参照側のエンタープライズ アプリケーションの weblogic-application.xml ファイルの情報を参照されるライブラリのデプロイメント記述子の情報に結合します。これは、次の順序で行われます。
記述子ファイルの結合方法の結果、weblogic-application.xml ファイルで最後に参照される共有 J2EE ライブラリの記述子の要素が、最初にあるものよりも優先されます。エンタープライズ アプリケーションの記述子自体の要素は、ライブラリの記述子のすべての要素よりも優先されます。
たとえば、myApp というエンタープライズ アプリケーションが、それぞれエンタープライズ アプリケーションとしてパッケージ化されている 2 つの共有 J2EE ライブラリ myLibA と myLibB をその順序で参照するとします。myApp アプリケーションと myLibA アプリケーションには、myEJB という EJB モジュール、myLibA アプリケーションと myLibB アプリケーションには、myOtherEJB という EJB モジュールがあります。
さらに、myApp アプリケーションがデプロイされると、クライアントが myApp アプリケーションを介して myEJB モジュールを呼び出すとします。この場合、参照側アプリケーションのモジュールは参照対象アプリケーションのモジュールよりも優先されるので、WebLogic Server は、実際には myLibA の EJB ではなく myApp アプリケーションの EJB を呼び出します。クライアントが myOtherEJB の EJB を呼び出すと、WebLogic Server は myLibB の EJB を呼び出します。これは、後者の EJB が myApp の weblogic-application.xml ファイルで最後に参照され、同じ名前を持つ myLibA アプリケーションの EJB よりも優先されるためです。
共有 J2EE ライブラリおよびオプション パッケージを開発する際には、以下のベスト プラクティスに留意してください。
/lib サブディレクトリを使用します。/lib サブディレクトリ内のクラスは、サーバの起動時にシステム クラスパスに追加されます。Extension-Name 値を必ず指定します。拡張名を指定しない場合は、ライブラリのデプロイメント名から派生した名前を使用します。デフォルトのデプロイメント名は、アーカイブ デプロイメントと展開されたアーカイブ デプロイメントでは異なります。デプロイメント コマンドで任意の値に設定できます。weblogic-application.xml デプロイメント記述子の context-root 要素を使用して、ライブラリのコンテキスト ルートをオーバーライドします。
|
|
|