| Oracle® Fusion Middleware Oracle WebLogic Server エンタープライズ JavaBeans (EJB) プログラマーズ ガイド 11g リリース 1 (10.3.1) B55528-01 |
|
 戻る |
 次へ |
| Oracle® Fusion Middleware Oracle WebLogic Server エンタープライズ JavaBeans (EJB) プログラマーズ ガイド 11g リリース 1 (10.3.1) B55528-01 |
|
戻る |
次へ |
この章では、EJB 固有のデプロイメント ガイドラインを示します。すべてのデプロイ可能なアプリケーション ユニットに共通のデプロイメント トピックについては、『Oracle Fusion Middleware Oracle WebLogic Server アプリケーションのデプロイメント』(WebLogic Server アプリケーションおよびモジュールのデプロイメントに関する包括的なガイド) のトピックへの相互参照を参照してください。
デプロイメントのプロセスを開始する前に、以下の準備が必要です。
展開ディレクトリ形式の、またはデプロイメント記述子と一緒にアーカイブ ファイル (スタンドアロン 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 Fusion Middleware Oracle WebLogic Server アプリケーションの開発』の「分割開発ディレクトリからのデプロイメントとパッケージ化」 |
|
デプロイメント ツールの選択 |
『Oracle Fusion Middleware Oracle WebLogic Server アプリケーションのデプロイメント』の「デプロイメント ツール」 |
|
デプロイメント用の適切なパッケージ化の指定 |
『Oracle Fusion Middleware Oracle WebLogic Server アプリケーションのデプロイメント』の「アプリケーションおよびモジュールのデプロイメント準備」 |
|
分割ディレクトリ構造での EJB コンポーネントの配置 |
『Oracle Fusion Middleware Oracle WebLogic Server アプリケーションの開発』の「EJB」 |
|
ステージング モードの選択 |
『Oracle Fusion Middleware Oracle WebLogic Server アプリケーションのデプロイメント』の「ステージング モードによるデプロイメント ファイルのコピーの制御」 |
|
特定のデプロイメント タスクの実行 |
『Oracle Fusion Middleware Oracle WebLogic Server アプリケーションのデプロイメント』の「デプロイメント プロセスの概要」 |
以降の節では、EJB をデプロイするためのガイドラインを示します。
スタンドアロンの EJB アプリケーションは、エンタープライズ アプリケーションの一部としてパッケージ化およびデプロイすることをお勧めします。エンタープライズ アプリケーションは、Web アプリケーション、EJB、およびリソース アダプタが 1 つのデプロイメント ユニットにまとめられた J2EE デプロイメント ユニットです。
これは、アプリケーションの移行、追加、および変更を容易に行うことができるベスト プラクティスです。また、アプリケーションをエンタープライズ アプリケーションの一部としてパッケージ化することにより、分割開発ディレクトリ構造を活用できます。この構造には、従来の単一ディレクトリ構造に比べて多くの利点があります。『Oracle Fusion Middleware 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 Fusion Middleware Oracle WebLogic Server アプリケーションの開発』の「Java EE アノテーションと依存性注入の使用」を参照してください。
EJB が WebLogic Server クラスタで動作する場合は、それらの EJB を均一に (クラスタ内の各管理対象サーバに) デプロイすることをお勧めします。EJB は、クラスタ内の 1 つのサーバのみにデプロイすることもできます (つまり、モジュールをサーバに固定する、ということ)。このタイプのデプロイメントはそれほど一般的ではなく、固定サービスが要求される特別な状況においてのみ行うようにする必要があります。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server クラスタの使い方』の「クラスタのコンフィグレーションについて」を参照してください。
JAR ファイルに未コンパイルのクラスおよびインタフェースが含まれているときに、クラスタ内の単一のサーバ インスタンスへ EJB をデプロイまたは再デプロイする場合 (固定デプロイメント) に関して、確認済みの問題があります。
未コンパイルの EJB は、デプロイ中にクラスタ内の各サーバ インスタンスにコピーされますが、この EJB はデプロイ先のサーバ インスタンス上でしかコンパイルされません。その結果、クラスタ内で EJB の対象となっていないサーバ インスタンスでは、EJB の呼び出しに必要な、コンパイル中に生成されるクラスが不足します。別のサーバ インスタンスのクライアントが固定 EJB を呼び出そうとしても失敗し、RMI レイヤでアサーション エラーが送出されます。
クラスタ内の 1 つのサーバ インスタンスに EJB をデプロイまたは再デプロイする場合は、生成されたクラスが、クラスタ内のすべてのノードで利用可能なすべてのサーバ インスタンスに必ずコピーされるように、デプロイ前にその EJB を appc でコンパイルしてください。
固定デプロイメントの詳細については、『Oracle Fusion Middleware Oracle WebLogic Server クラスタの使い方』の「1 つのサーバ インスタンスにデプロイする (固定デプロイメント)」を参照してください。
デプロイした EJB のクラスに変更を加えたら、その EJB を再デプロイする必要があります。自動デプロイメントを使用すると、WebLogic Server の再起動時にデプロイメントが自動的に行われます。それ以外の場合は、EJB を明示的に再デプロイする必要があります。
EJB デプロイメントを再デプロイすると、EJB プロバイダがデプロイ済みの EJB クラスを変更し、再コンパイルしてから、動作中のサーバのクラスを「更新」できるようになります。
再デプロイを行うと、その EJB で現在ロードされているクラスがサーバ内ですぐに使用不可になったことが示され、EJB のクラスローダと関連クラスが削除されます。同時に、改版された EJB のクラスをロードして維持する新規の EJB クラスローダが作成されます。
クライアントが次に EJB への参照を必要とする場合、クライアントの EJB メソッドの呼び出しでは、変更済みの EJB クラスが使用されます。
EJB は、スタンドアロンで、またはアプリケーションの一部として、weblogic.Deployer ツールまたは Administration Console を使用して再デプロイできます。手順については、『Oracle Fusion Middleware Oracle WebLogic Server アプリケーションのデプロイメント』の「プロダクション環境でのアプリケーションの再デプロイメント」を参照してください。
以下のものに対しては、プロダクション再デプロイメントはサポートされません。
JTS ドライバを使用するアプリケーション。
EJB 1.1 のコンテナ管理による永続性 (CMP) EJB を含むアプリケーション。CMP EJB を含むアプリケーションでプロダクション再デプロイメントを使用するには、EJB 1.1 CMP ではなく EJB 2.x CMP を使用します。
プロダクション再デプロイメントの制限の詳細については、『Oracle Fusion Middleware Oracle WebLogic Server アプリケーションのデプロイメント』の「プロダクション再デプロイメンの要件と制限事項」を参照してください。
ある EJB アプリケーションを繰り返し開発する場合は、EJB の実装クラス ファイルに多くの変更を加えて、通常は開発中に何度も EJB モジュールを再デプロイします。
Java EE 5 では、ClassLoader を削除したり既存のインスタンスを破棄したりすることなく、実行時にクラスを再定義する機能が導入されています。これにより、コンテナは実行中のアプリケーションに影響を与えることなく、変更されたクラスを再ロードできるため、反復的な開発サイクル時間が大幅に短縮され、開発およびテスト全体が改善されています。
FastSwap を使用すると、ClassLoader を再ロードせずにインプレースで Java クラスを再定義するため、所要時間を短縮できるという点で明らかに有利です。つまり、変更がアプリケーションによって再デプロイされて有効になるまで待つ必要はありません。代わりに、変更を追加すると、自動でコンパイルされ、すぐに結果が確認できます。
FastSwap の詳細については、『Oracle Fusion Middleware 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」を参照してください。
