| Oracle® Fusion Middleware Oracle WebLogic Server Enterprise JavaBeansの開発 12c (12.2.1.3.0) E90322-03 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle WebLogic Server Enterprise JavaBeansの開発 12c (12.2.1.3.0) E90322-03 |
|
|
前 |
次 |
この章の内容は次のとおりです。
デプロイメントのプロセスを開始する前に、以下の準備が必要です。
展開ディレクトリ形式の、またはデプロイメント記述子と一緒にアーカイブ・ファイル(スタンドアロンEJBの場合はJAR、EJBがエンタープライズ・アプリケーションの一部である場合はEAR、EJBがWebアプリケーションの一部である場合はWAR)にパッケージ化された、動作可能でテスト済のBeanコード。本番環境では、アプリケーションをEARとしてパッケージ化することをお薦めします。
注意:
EJB 3.1(以降)では、エンタープライズBeanクラスをejb-jarファイルの中にパッケージ化しなければならないという制限が取り除かれました。そのため、Webアプリケーション・クラスに適用される同じパッケージ化のガイドラインを使用して、EJBクラスをWebアプリケーション・アーカイブ(WAR)の中に直接パッケージ化できます。「Webアプリケーションの一部としてのEJBのデプロイメント」を参照してください
EJBの作成とパッケージ化に必要な手順の概要については、「EJB開発プロセスの概要」を参照してください
必要なアノテーション付きEJBクラスをプログラムして、@javax.ejb.Stateful、@javax.ejb.Stateless、@javax.ejb.Singletonまたは@javax.ejb.MessageDrivenのいずれかのEJBのタイプを指定します。
Beanクラスのプログラミングの詳細やサンプルについては、「アノテーション付きEJBクラスのプログラミング」を参照してください。
オプションではあるものの、サポートされているデプロイメント記述子の構成。ejb-jar.xml、weblogic-ejb-jar.xml、およびコンテナ管理による永続性を使用するエンティティEJBの場合はweblogic-cmp-jar.xmlです。
EJBデプロイメント記述子の作成については、Oracle WebLogic Server Enterprise JavaBeansバージョン2.1の開発のデプロイメント記述子の生成を参照してください。
表6-1は、デプロイメント方法についての決定を支援したり、デプロイメント・タスクを実行する手順を説明したりするWebLogic Serverドキュメントのトピックへのガイドです。EJB固有のデプロイメント・トピックについては、「EJBデプロイメントのガイドライン」を参照してください
表6-1 デプロイメントのタスクとトピック
| 目的とする作業 | 参照先 |
|---|---|
開発環境でのデプロイメント |
Oracle WebLogic Serverアプリケーションの開発の分割開発ディレクトリからのデプロイとパッケージ化。 |
デプロイメント・ツールの選択 |
Oracle WebLogic Serverへのアプリケーションのデプロイのデプロイメント・ツール |
デプロイメント用の適切なパッケージ化の指定 |
Oracle WebLogic Serverへのアプリケーションのデプロイのアプリケーションおよびモジュールのデプロイメント準備。 |
分割ディレクトリ構造でのEJBコンポーネントの配置 |
Oracle WebLogic ServerへのアプリケーションのデプロイのEJB。 |
ステージング・モードの選択 |
Oracle WebLogic Serverへのアプリケーションのデプロイのステージング・モードによるデプロイメント・ファイルのコピーの制御 |
特定のデプロイメント・タスクの実行 |
Oracle WebLogic Serverへのアプリケーションのデプロイのデプロイメント・プロセスの概要。 |
以降の節では、EJBをデプロイするためのガイドラインを示します。
スタンドアロンのEJBアプリケーションは、エンタープライズ・アプリケーションの一部としてパッケージ化およびデプロイすることをお薦めします。エンタープライズ・アプリケーションは、Webアプリケーション、EJB、およびリソース・アダプタが1つのデプロイメント・ユニットにまとめられたJava EE 7デプロイメント・ユニットです。
これは、アプリケーションの移行、追加、および変更を容易に行うことができるベスト・プラクティスです。また、アプリケーションをエンタープライズ・アプリケーションの一部としてパッケージ化することにより、分割開発ディレクトリ構造を活用できます。この構造には、従来の単一ディレクトリ構造に比べて多くの利点があります。
Oracle WebLogic Serverアプリケーションの開発の分割開発ディレクトリ環境の概要を参照してください。
エンタープライズBeanは、Webアプリケーション・モジュール(WAR)内にパッケージ化することもできます。
EJB 3.1(以降)では、エンタープライズBeanクラスをejb-jarファイルの中にパッケージ化しなければならないという制限が取り除かれました。そのため、Webアプリケーション・クラスに適用される同じパッケージ化のガイドラインを使用して、EJBクラスをWebアプリケーション・アーカイブ(WAR)の中に直接パッケージ化できます。単にEJBクラスをWEB-INF/classesディレクトリかWEB-INF/libディレクトリ内のJARファイルに入れるのみです。必要に応じて、EJBデプロイメント記述子も使用する場合は、それをWEB-INF/ejb-jar.xmlとしてパッケージ化できます。appcコンパイラを実行すると、EJBコンポーネントにアクセスするために必要なクラスを持つWARファイルが生成されます。
WARでのEJBのパッケージ化を参照してください。
あるアプリケーションの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クラスタの管理』の「クラスタ構成の理解」を参照してください。
未コンパイルのEJBは、デプロイ中にクラスタ内のすべてのサーバー・インスタンスにコピーされますが、このEJBはデプロイ先のサーバー・インスタンス上でしかコンパイルされません。その結果、クラスタ内でEJBのターゲットとなっていないサーバー・インスタンスでは、EJBの呼出しに必要なクラスが不足します。
クラスタ内の単一のサーバー・インスタンスへEJBをデプロイまたは再デプロイする場合、クライアントはクラスタ内の別のサーバーを通じてEJBアプリケーションを呼び出せるようになります。
固定デプロイメントの詳細は、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要素を使用すると、特定のメッセージを無効化できます。無効化できるメッセージのリストとメッセージを無効化する方法の詳細は、Oracle WebLogic Server Enterprise JavaBeansバージョン2.1の開発のweblogic-ejb-jar.xmlデプロイメント記述子のリファレンスの章のdisable-warningを参照してください。
