8 Enterprise JavaBeansのデプロイメント・ガイドライン

次の項では、EJB固有のデプロイメント・ガイドラインを示します。すべてのデプロイ可能なアプリケーション・ユニットに共通のデプロイメント・トピックについては、『Oracle WebLogic Serverへのアプリケーションのデプロイ』(WebLogic Serverアプリケーションおよびモジュールのデプロイメントに関する包括的なガイド)のトピックへの相互参照を参照してください。

EJBをデプロイする前に
デプロイメント・タスクの概要と実行
EJBデプロイメントのガイドライン

EJBをデプロイする前に

デプロイメントのプロセスを開始する前に、以下の準備が必要です。

展開ディレクトリ形式の、またはデプロイメント記述子と一緒にアーカイブ・ファイル(スタンドアロンEJBの場合はJAR、EJBがエンタープライズ・アプリケーションの一部である場合はEAR)にパッケージされた、動作可能でテスト済みのBeanコード。本番環境では、アプリケーションをEARとしてパッケージ化することをお薦めします。

EJBの作成とパッケージ化に必要な手順の概要については、「EJB開発プロセスの概要」を参照してください。
必要なデプロイメント記述子の構成。ejb-jar.xml、weblogic-ejb-jar.xml、およびコンテナ管理による永続性を使用するエンティティEJBの場合はweblogic-cmp-jar.xmlです。

EJBデプロイメント記述子の作成については、「デプロイメント記述子を生成する」を参照してください。

デプロイメント・タスクの概要と実行

表8-1は、デプロイメント方法についての決定を支援したり、デプロイメント・タスクを実行する手順を説明したりするWebLogic Serverドキュメントのトピックへのガイドです。EJB固有のデプロイメント・トピックについては、「EJBデプロイメントのガイドライン」を参照してください。

表8-1 デプロイメントのタスクとトピック

目的とする作業	参照先
開発環境でのデプロイメント	『Oracle WebLogic Serverアプリケーションの開発』の「分割開発ディレクトリからのデプロイとパッケージ化」
デプロイメント・ツールの選択	『Oracle WebLogic Serverへのアプリケーションのデプロイ』の「デプロイメント・ツール」
デプロイメント用の適切なパッケージ化の指定	『Oracle WebLogic Serverへのアプリケーションのデプロイ』の「アプリケーションおよびモジュールのデプロイメント準備」
分割ディレクトリ構造でのEJBコンポーネントの配置	『Oracle WebLogic Serverへのアプリケーションのデプロイ』の「EJB」
ステージング・モードの選択	『Oracle WebLogic Serverへのアプリケーションのデプロイ』の「ステージング・モードによるデプロイメント・ファイルのコピーの制御」
特定のデプロイメント・タスクの実行	『Oracle WebLogic Serverへのアプリケーションのデプロイ』の「デプロイメント・プロセスの概要」

EJBデプロイメントのガイドライン

以降の節では、EJBをデプロイするためのガイドラインを示します。

エンタープライズ・アプリケーションの一部としてのEJBのデプロイメント
お互いに呼出しあう複数のEJBの同じアプリケーションでのデプロイメント
依存関係インジェクションを使用するEJBのデプロイメント
クラスタへの均一なデプロイメント
固定EJBのクラスタへのデプロイメント
EJBの再デプロイメント
FastSwapデプロイメントによるデプロイメントの最小化
警告メッセージについて
EJBデプロイメントの警告メッセージの無効化

エンタープライズ・アプリケーションの一部としてのEJBのデプロイメント

スタンドアロンのEJBアプリケーションは、エンタープライズ・アプリケーションの一部としてパッケージ化およびデプロイすることをお薦めします。エンタープライズ・アプリケーションは、Webアプリケーション、EJB、およびリソース・アダプタが1つのデプロイメント・ユニットにまとめられたJava EEデプロイメント・ユニットです。

これは、アプリケーションの移行、追加、および変更を容易に行うことができるベスト・プラクティスです。また、アプリケーションをエンタープライズ・アプリケーションの一部としてパッケージ化することにより、分割開発ディレクトリ構造を活用できます。この構造には、従来の単一ディレクトリ構造に比べて多くの利点があります。『Oracle WebLogic Serverアプリケーションの開発』の「分割開発ディレクトリ環境の概要」を参照してください。

お互いに呼出しあう複数のEJBの同じアプリケーションでのデプロイメント

あるアプリケーションのEJBが別のアプリケーションのEJBを呼び出す場合、WebLogic Serverはクラスローディング上の必要からメソッドの引数を値で渡します。EJBが同じアプリケーション内にある場合、WebLogic Serverは参照によってメソッド引数を渡せます。それにより、パラメータのコピーが行われないので、メソッド呼出しのパフォーマンスが向上します。

最高のパフォーマンスを引き出すには、お互いに呼出しあうコンポーネントを同じアプリケーションにパッケージ化し、weblogic-ejb-jar.xmlのenable-call-by-referenceをTrueに設定します。デフォルトでは、enable-call-by-referenceはFalseです。

依存関係インジェクションを使用するEJBのデプロイメント

EJBで依存関係インジェクションを使用する場合、クラスで定義したリソース名とスーパークラスは、一意でなければなりません。例:

public class ClientServlet extends HttpServlet {
    @EJB(name = 'DateServiceBean', beanInterface = DateService.class)
    private DateService bean; .... } 
public class DerivedClientServlet extends ClientServlet { 
    @EJB(name = MyDateServiceBean', beanInterface = DateService.class)
    private DateService bean; .... }

依存関係インジェクションについては、『Oracle WebLogic Serverアプリケーションの開発』の「Java EEアノテーションと依存関係インジェクションの使用」を参照してください。

クラスタへの均一なデプロイメント

EJBがWebLogic Serverクラスタで動作する場合は、それらのEJBを均一に(クラスタ内の各管理対象サーバーに)デプロイすることをお薦めします。EJBは、クラスタ内の1つのサーバーのみにデプロイする(つまり、モジュールをサーバーに"固定"する)こともできます。このタイプのデプロイメントはそれほど一般的ではなく、固定サービスが要求される特別な状況においてのみ行うようにする必要があります。詳細は、『Oracle WebLogic Serverクラスタの使い方』の「クラスタの構成について」を参照してください。

固定EJBのクラスタへのデプロイメント

JARファイルに未コンパイルのクラスおよびインタフェースが含まれているときに、クラスタ内の単一のサーバー・インスタンスへEJBをデプロイまたは再デプロイする場合(固定デプロイメント)に関して、既知の問題があります。

未コンパイルのEJBは、デプロイメント中にクラスタ内の各サーバー・インスタンスにコピーされますが、このEJBはデプロイ先のサーバー・インスタンス上でしかコンパイルされません。その結果、クラスタ内でEJBのターゲットとなっていないサーバー・インスタンスでは、EJBの呼出しに必要な、コンパイル中に生成されるクラスが不足します。別のサーバー・インスタンスのクライアントが固定EJBを呼び出そうとしても失敗し、RMIレイヤーでアサーション・エラーがスローされます。

クラスタ内の1つのサーバー・インスタンスにEJBをデプロイまたは再デプロイする場合は、生成されたクラスが、クラスタ内のすべてのノードで利用可能なすべてのサーバー・インスタンスに必ずコピーされるように、デプロイ前にそのEJBをappcでコンパイルしてください。

固定デプロイメントの詳細は、『Oracle WebLogic Serverクラスタの使い方』の「単一のサーバー・インスタンスへのデプロイ(固定デプロイメント)」を参照してください。

EJBの再デプロイメント

デプロイしたEJBのクラスに変更を加えたら、そのEJBを再デプロイする必要があります。自動デプロイメントを使用すると、WebLogic Serverの再起動時にデプロイメントが自動的に行われます。それ以外の場合は、EJBを明示的に再デプロイする必要があります。

EJBデプロイメントを再デプロイすると、EJBプロバイダがデプロイ済みのEJBクラスを変更し、再コンパイルしてから、動作中のサーバーのクラスを「リフレッシュ」できるようになります。

再デプロイを行うと、そのEJBで現在ロードされているクラスがサーバー内ですぐに使用不可になったことが示され、EJBのクラスローダーと関連クラスが削除されます。同時に、改版されたEJBのクラスをロードして維持する新規のEJBクラスローダーが作成されます。

クライアントが次にEJBへの参照を必要とする場合、クライアントのEJBメソッドの呼出しでは、変更済みのEJBクラスが使用されます。

EJBは、スタンドアロンで、またはアプリケーションの一部として、weblogic.Deployerツールまたは管理コンソールを使用して再デプロイできます。手順については、『Oracle WebLogic Serverへのアプリケーションのデプロイ』の「本番環境でのアプリケーションの再デプロイ」を参照してください。

以下のものに対しては、本番再デプロイメントはサポートされません。

JTSドライバを使用するアプリケーション。
EJB 1.1のコンテナ管理による永続性(CMP) EJBを含むアプリケーション。CMP EJBを含むアプリケーションで本番再デプロイメントを使用するには、EJB 1.1 CMPではなくEJB 2.x CMPを使用します。

本番再デプロイメントの制限の詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』の「本番再デプロイメントの要件と制限事項」を参照してください。

FastSwapデプロイメントによるデプロイメントの最小化

あるEJBアプリケーションを繰返し開発する場合は、EJBの実装クラス・ファイルに多くの変更を加えて、通常は開発中に何度もEJBモジュールを再デプロイします。

Java EE 5では、ClassLoaderを削除したり既存のインスタンスを破棄したりすることなく、実行時にクラスを再定義する機能が導入されています。これにより、コンテナは実行中のアプリケーションに影響を与えることなく、変更されたクラスを再ロードできるため、反復的な開発サイクル時間が大幅に短縮され、開発およびテスト全体が改善されています。

FastSwapを使用すると、ClassLoaderを再ロードせずにインプレースでJavaクラスを再定義するため、所要時間を短縮できるという点で明らかに有利です。つまり、変更がアプリケーションによって再デプロイされて有効になるまで待つ必要はありません。かわりに、変更を追加すると、自動でコンパイルされ、すぐに結果が確認できます。

FastSwapの詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』の「FastSwapデプロイメントによる再デプロイメントの最小化」を参照してください。

警告メッセージについて

特定の警告に関する詳細情報は、weblogic.GetMessageツールで取得できます。例:

java weblogic.GetMessage -detail -id BEA-010202

EJBデプロイメントの警告メッセージの無効化

WebLogic Serverでは、デプロイメント中に発生する特定の警告メッセージを無効化できます。この機能は、すでにわかっている情報をメッセージが通知する場合に便利です。

たとえば、EJBのメソッドが値ではなく参照で呼出しを行う場合、WebLogic Serverはデプロイメントの過程で「Call-by-reference not enabled.」という警告メッセージを生成します。

weblogic-ejb-jar.xmlでdisable-warning要素を使用すると、特定のメッセージを無効化できます。無効にできるメッセージのリスト、およびメッセージを無効にする手順については、「disable-warning」を参照してください。