WebLogic エンタープライズ JavaBeans (EJB) プログラマーズ ガイド
この章では、EJB 固有のデプロイメント ガイドラインを示します。すべてのデプロイ可能なアプリケーション ユニットに共通のデプロイメント トピックについては、『WebLogic Server アプリケーションのデプロイメント』(WebLogic Server アプリケーションおよびモジュールのデプロイメントに関する包括的なガイド) のトピックへの相互参照を参照してください。
デプロイメントのプロセスを開始する前に、以下の準備が必要です。
EJB の作成とパッケージ化に必要な手順の概要については、「EJB 開発プロセスの概要」を参照してください。
ejb-jar.xml
、weblogic-ejb-jar.xml
、およびコンテナ管理による永続性を使用するエンティティ EJB の場合は weblogic-cmp-jar.xml
。 EJB デプロイメント記述子を作成するには、「デプロイメント記述子を生成する」および「デプロイメント記述子を編集する」を参照してください。
表 8-1 は、デプロイメント方法についての決定を支援したり、デプロイメント タスクを実行する手順を説明したりする WebLogic Server マニュアルのトピックへのガイドです。EJB 固有のデプロイメント トピックについては、「EJB デプロイメントのガイドライン」を参照してください。
|
|
|
|
|
|
|
|
|
|
|
以降の節では、EJB をデプロイするためのガイドラインを示します。
スタンドアロンの EJB アプリケーションは、エンタープライズ アプリケーションの一部としてパッケージ化およびデプロイすることをお勧めします。エンタープライズ アプリケーションは、Web アプリケーション、EJB、およびリソース アダプタが 1 つのデプロイメント ユニットにまとめられた J2EE デプロイメント ユニットです。
これは、アプリケーションの移行、追加、および変更を容易に行うことができるベスト プラクティスです。また、アプリケーションをエンタープライズ アプリケーションの一部としてパッケージ化することにより、分割開発ディレクトリ構造を活用できます。この構造には、従来の単一ディレクトリ構造に比べて多くの利点があります。『WebLogic Server アプリケーションの開発』の「分割開発ディレクトリ環境の概要」を参照してください。
あるアプリケーションの EJB が別のアプリケーションの EJB を呼び出す場合、WebLogic Server はクラスローディング上の必要からメソッドの引数を値で渡します。EJB が同じアプリケーション内にある場合、WebLogic Server は参照によってメソッド引数を渡せます。それにより、パラメータのコピーが行われないので、メソッド呼び出しのパフォーマンスが向上します。
最高のパフォーマンスを引き出すには、お互いに呼び出しあうコンポーネントを同じアプリケーションにパッケージ化し、weblogic-ejb-jar.xml
の enable-call-by-reference を True
に設定します。デフォルトでは、enable-call-by-reference
は False
です。
EJB が WebLogic Server クラスタで動作する場合は、それらの EJB を均一に (クラスタ内の各管理対象サーバに) デプロイすることをお勧めします。EJB は、クラスタ内の 1 つのサーバのみにデプロイすることもできます (つまり、モジュールをサーバに固定する、ということ)。このタイプのデプロイメントはそれほど一般的ではなく、固定サービスが要求される特別な状況においてのみ行うようにする必要があります。詳細については、『WebLogic Server クラスタ ユーザーズ ガイド』の「クラスタのコンフィグレーションとアプリケーションのデプロイメント」を参照してください。
JAR ファイルに未コンパイルのクラスおよびインタフェースが含まれているときに、クラスタ内の単一のサーバ インスタンスへ EJB をデプロイまたは再デプロイする場合 (固定デプロイメント) に関して、確認済みの問題があります。
未コンパイルの EJB は、デプロイ中にクラスタ内の各サーバ インスタンスにコピーされますが、この EJB はデプロイ先のサーバ インスタンス上でしかコンパイルされません。その結果、クラスタ内で EJB の対象となっていないサーバ インスタンスでは、EJB の呼び出しに必要な、コンパイル中に生成されるクラスが不足します。別のサーバ インスタンスのクライアントが固定 EJB を呼び出そうとしても失敗し、RMI レイヤでアサーション エラーが送出されます。
クラスタ内の 1 つのサーバ インスタンスに EJB をデプロイまたは再デプロイする場合は、生成されたクラスが、クラスタ内のすべてのノードで利用可能なすべてのサーバ インスタンスに必ずコピーされるように、デプロイ前にその EJB を appc
または ejbc
でコンパイルしてください。
固定デプロイメントの詳細については、『WebLogic Server クラスタ ユーザーズ ガイド』の「1 つのサーバ インスタンスにデプロイする (固定デプロイメント)」を参照してください。
デプロイした EJB のクラスに変更を加えたら、その EJB を再デプロイする必要があります。自動デプロイメントを使用すると、WebLogic Server の再起動時にデプロイメントが自動的に行われます。それ以外の場合は、EJB を明示的に再デプロイする必要があります。
EJB デプロイメントを再デプロイすると、EJB プロバイダがデプロイ済みの EJB クラスを変更し、再コンパイルしてから、動作中のサーバのクラスを「更新」できるようになります。
再デプロイを行うと、その EJB で現在ロードされているクラスがサーバ内ですぐに使用不可になったことが示され、EJB のクラスローダと関連クラスが削除されます。同時に、改版された EJB のクラスをロードして維持する新規の EJB クラスローダが作成されます。
クライアントが次に EJB への参照を必要とする場合、クライアントの EJB メソッドの呼び出しでは、変更済みの EJB クラスが使用されます。
EJB は、スタンドアロンで、またはアプリケーションの一部として、weblogic.Deployer
ツールまたは Administration Console を使用して再デプロイできます。手順については、『WebLogic Server アプリケーションのデプロイメント』の「デプロイメント ユニットの再デプロイまたは停止」を参照してください。
ある EJB アプリケーションを繰り返し開発する場合は、EJB の実装クラス ファイルに多くの変更を加えて、通常は開発中に何度も EJB モジュールを再デプロイします。
WebLogic Server 8.1 より前のバージョンでは、すべての実装クラスとユーティリティ クラスを含めて、EJB モジュールのレベルで EJB の実装クラスを再デプロイすることができました。WebLogic Server 8.1 からは、実装クラスを個別に再デプロイすることができます。この機能の詳細については、『WebLogic Server アプリケーションの開発』の「実装クラスのための個々の EJB クラスローダ」を参照してください。
この機能を有効化するには、weblogic-ejb-jar.xml
の enable-bean-class-redeploy
要素を True
に設定します。この機能は、プロダクション環境での使用はお勧めしません。個々の実装クラスのデプロイメントに関連する考慮事項と制限については、「enable-bean-class-redeploy」を参照してください。
特定の警告に関する詳細情報は、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」を参照してください。