ヘッダーをスキップ
Oracle® Fusion Middleware Oracle WebLogic Server Enterprise JavaBeansの開発
12c (12.1.2)
E48054-02
  ドキュメント・ライブラリへ移動
ライブラリ		 製品リストへ移動
製品		 目次へ移動
目次
前
前 		 次
次		  

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

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

この章の内容は次のとおりです。

EJBをデプロイする前に

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

デプロイメント・タスクの理解と実行

表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をデプロイするためのガイドラインを示します。

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

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

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

『Oracle WebLogic Serverアプリケーションの開発』の分割開発ディレクトリ環境の概要に関する項を参照してください。

Webアプリケーションの一部としてのEJBのデプロイメント

エンタープライズ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ファイルが生成されます。

第4章「WARでのEJBのパッケージ化」を参照してください。

お互いに呼出しあう複数の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要素を使用すると、特定のメッセージを無効化できます。無効化できるメッセージのリストとメッセージを無効化する方法の詳細は、『Oracle WebLogic Server Enterprise JavaBeansバージョン2.1の開発』の「weblogic-ejb-jar.xmlデプロイメント記述子のリファレンス」の章のdisable-warningに関する項を参照してください。

  前
前 		 次
次
  ドキュメント・ライブラリへ移動
ライブラリ		 製品リストへ移動
製品		 目次へ移動
目次