Oracle® Fusion Middleware Oracle WebLogic Server Enterprise JavaBeansバージョン2.1の開発 12c (12.2.1.3.0) E90325-02 |
|
![]() 前 |
![]() 次 |
すべてのデプロイ可能なアプリケーション・ユニットに共通のデプロイメント・トピックについては、『Oracle WebLogic Serverへのアプリケーションのデプロイ』(WebLogic Server のアプリケーションおよびモジュールのデプロイに関する包括的なガイド)のトピックへのクロス・リファレンスが示されています。
この章の内容は次のとおりです。
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へのアプリケーションのデプロイのデプロイメント・プロセスの概要。 |
WebLogic ServerにEJBをデプロイするためのガイドラインを理解します。
以降の節では、EJBをデプロイするためのガイドラインを示します。
スタンドアロンのEJBアプリケーションは、エンタープライズ・アプリケーションの一部としてパッケージ化およびデプロイすることをお薦めします。エンタープライズ・アプリケーションは、Webアプリケーション、EJB、およびリソース・アダプタが1つのデプロイメント・ユニットにまとめられたJava EEデプロイメント・ユニットです。
これは、アプリケーションの移行、追加、および変更を容易に行うことができるベスト・プラクティスです。また、アプリケーションをエンタープライズ・アプリケーションの一部としてパッケージ化することにより、分割開発ディレクトリ構造を活用できます。この構造には、従来の単一ディレクトリ構造に比べて多くの利点があります。Oracle WebLogic Serverアプリケーションの開発の分割開発ディレクトリ環境の概要を参照してください。
あるアプリケーションのEJBが別のアプリケーションのEJBを呼び出す場合、WebLogic Serverはクラスローディング上の必要からメソッドの引数を値で渡します。EJBが同じアプリケーション内にある場合、WebLogic Serverは参照によってメソッド引数を渡せます。それにより、パラメータのコピーが行われないので、メソッド呼出しのパフォーマンスが向上します。
最高のパフォーマンスを引き出すには、お互いに呼出しあうコンポーネントを同じアプリケーションにパッケージ化し、weblogic-ejb-jar.xml
のenable-call-by-reference
をTrue
に設定します。(デフォルトでは、enable-call-by-reference
はFalse
です。)
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クラスタの管理』のクラスタ構成の理解に関する項を参照してください。
JARファイルに未コンパイルのクラスおよびインタフェースが含まれているときに、クラスタ内の単一のサーバー・インスタンスへEJBをデプロイまたは再デプロイする場合(固定デプロイメント)に関して、確認済みの問題があります。
未コンパイルのEJBは、デプロイ中にクラスタ内の各サーバー・インスタンスにコピーされますが、このEJBはデプロイ先のサーバー・インスタンス上でしかコンパイルされません。その結果、クラスタ内でEJBのターゲットとなっていないサーバー・インスタンスでは、EJBの呼出しに必要な、コンパイル中に生成されるクラスが不足します。別のサーバー・インスタンスのクライアントが固定EJBを呼び出そうとしても失敗し、RMIレイヤーでアサーション・エラーが送出されます。
クラスタ内の1つのサーバー・インスタンスにEJBをデプロイまたは再デプロイする場合は、生成されたクラスが、クラスタ内のすべてのノードで利用可能なすべてのサーバー・インスタンスに必ずコピーされるように、デプロイ前にそのEJBをappc
でコンパイルしてください。
固定デプロイメントの詳細は、Oracle WebLogic Serverクラスタの管理の単一のサーバー・インスタンスへのデプロイ(固定デプロイメント)を参照してください。
デプロイしたEJBのクラスに変更を加えたら、そのEJBを再デプロイする必要があります。自動デプロイメントを使用すると、WebLogic Serverの再起動時にデプロイメントが自動的に行われます。それ以外の場合は、EJBを明示的に再デプロイする必要があります。
EJBデプロイメントを再デプロイすると、EJBプロバイダがデプロイ済みのEJBクラスを変更し、再コンパイルしてから、動作中のサーバーのクラスを「更新」できるようになります。
再デプロイを行うと、そのEJBで現在ロードされているクラスがサーバー内ですぐに使用不可になったことが示され、EJBのクラスローダーと関連クラスが削除されます。同時に、改版されたEJBのクラスをロードして維持する新規のEJBクラスローダーが作成されます。
クライアントが次にEJBへの参照を必要とする場合、クライアントのEJBメソッドの呼出しでは、変更済みのEJBクラスが使用されます。
Oracle WebLogic Serverの理解のシステム管理ツールおよびAPIのサマリーにリストされている管理ツールのいずれかを使用して、スタンドアロンのEJBまたはアプリケーションの一部であるEJBを再デプロイできます。『Oracle WebLogic Serverへのアプリケーションのデプロイ』の本番環境でのアプリケーションの再デプロイに関する項を参照してください。
以下のものに対しては、プロダクション再デプロイメントはサポートされません。
JTSドライバを使用するアプリケーション。
EJB 1.1のコンテナ管理による永続性(CMP) EJBを含むアプリケーション。CMP EJBを含むアプリケーションでプロダクション再デプロイメントを使用するには、EJB 1.1 CMPではなくEJB 2.x CMPを使用します。
本番再デプロイメントの制限の詳細は、Oracle WebLogic Serverへのアプリケーションのデプロイの本番再デプロイメントの要件と制限事項を参照してください。
あるEJBアプリケーションを繰返し開発する場合は、EJBの実装クラス・ファイルに多くの変更を加えて、通常は開発中に何度もEJBモジュールを再デプロイします。
Java EE 5では、ClassLoaderを削除したり既存のインスタンスを破棄したりすることなく、実行時にクラスを再定義する機能が導入されています。これにより、コンテナは実行中のアプリケーションに影響を与えることなく、変更されたクラスを再ロードできるため、反復的な開発サイクル時間が大幅に短縮され、開発およびテスト全体が改善されています。
FastSwapを使用すると、ClassLoaderを再ロードせずにインプレースでJavaクラスを再定義するため、所要時間を短縮できるという点で明らかに有利です。つまり、変更がアプリケーションによって再デプロイされて有効になるまで待つ必要はありません。代わりに、変更を追加すると、自動でコンパイルされ、すぐに結果が確認できます。
FastSwapの詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』のFastSwapデプロイメントによる再デプロイメントの最小化に関する項を参照してください。
特定の警告に関する詳細情報は、weblogic.GetMessage
ツールで取得できます。例:
java weblogic.GetMessage -detail -id BEA-010202
WebLogic Serverでは、デプロイメント中に発生する特定の警告メッセージを無効化できます。この機能は、すでにわかっている情報をメッセージが通知する場合に便利です。
たとえば、EJBのメソッドが値ではなく参照で呼出しを行う場合、WebLogic Serverはデプロイメントの過程で「Call-by-reference not enabled.」
という警告メッセージを生成します。
weblogic-ejb-jar.xml
でdisable-warning
要素を使用すると、特定のメッセージを無効化できます。無効にできるメッセージのリスト、およびメッセージを無効にする手順については、「disable-warning」を参照してください