Oracle® Fusion Middleware Oracle WebLogic Server Enterprise JavaBeansバージョン3.0のプログラミング 11g リリース1 (10.3.6) B61625-05 |
|
前 |
次 |
次の項では、EJB 3.0の一般的な実装プロセスを説明し、EJB 3.0をWebLogic Serverで実行する方法について説明します。
WebLogic Server EJBの機能の概要については、「WebLogic ServerのEJB 3.0の付加価値機能」を参照してください。
この節では、EJB 3.0の開発プロセスを簡単に説明します。主な実装タスクと関連する結果について説明します。
次の節の大部分では、EJB 3.0プログラミング・モデルについて説明しています。3.0と2.Xでのプログラミング・モデルの相違点については、一部で簡単に触れているだけです。EJB 2.Xに精通しており、2つのモデルの相違点について詳しく知りたい場合は、「EJB 3.0の新機能およびEJB 2.Xとの相違点」を参照してください。
表4-1 EJB開発タスクと結果
# |
ステップ | 説明 | 結果 |
---|---|---|---|
1 |
|
Javaソース・ファイルのディレクトリ構造を作成し、必要に応じてデプロイメント記述子を作成します。 |
ローカル・ドライブ上のディレクトリ構造 |
2 |
|
EJBを記述するために必要なビジネス・インタフェースを作成します。 |
|
3 |
|
ビジネス・インタフェースを実装するJavaファイルを作成し、EJBの動作を記述するEJB 3.0メタデータ・アノテーションを含めます。 |
|
4 |
|
必要に応じて、ビジネス・メソッド呼出しやライフサイクル・コールバック・イベントをインターセプトするインターセプタを記述したインターセプタ・クラスを作成します。 |
|
5 |
|
ソース・コードをコンパイルします。 |
各クラスおよびインタフェースの |
6 |
|
必要に応じて、EJB固有のデプロイメント記述子を作成します。この手順は、EJB 3.0プログラミング・モデルを使用する場合は不要です。 |
|
7 |
|
コンパイル済みのクラス(および、必要に応じてデプロイメント記述子)をデプロイメント用にパッケージ化します。 状況によっては、ファイルをアーカイブせずにディレクトリ形式で展開しておくことも可能です。 |
アーカイブ・ファイル(EJB JARまたはエンタープライズ・アプリケーションEAR)、または対応する展開済みディレクトリ |
8 |
|
選択したステージング・モードに従って、アーカイブまたはアプリケーション・ディレクトリのターゲットとして目的の管理対象サーバーまたはWebLogic Serverクラスタを設定します。 |
Beanのデプロイメント設定は、 |
EJB 3.0をアセンブルするソース・ディレクトリを作成します。
ソース・ファイルと出力ファイルを並列ディレクトリ構造に分離する分割開発ディレクトリ構造をお薦めします。分割ディレクトリ構造を準備し、EJB 3.0をエンタープライズ・アプリケーション・アーカイブ(EAR)としてパッケージ化する方法については、『Oracle WebLogic Serverアプリケーションの開発』の分割開発ディレクトリ環境の概要に関する項を参照してください。
EJB 3.0をJARファイルにパッケージ化してデプロイする場合は、クラス・ファイル用のディレクトリを作成します。また、デプロイメント記述子も作成する場合は、META-INF
というサブディレクトリに格納します(なお、EJB 3.0プログラミング・モデルでは、デプロイメント記述子は省略可能ですがサポートはされています)。
EJB 3.0ビジネス・インタフェースは、EJBのすべてのビジネス・メソッドの完全なシグネチャを記述するプレーンJavaインタフェースです。たとえば、Account
EJBが顧客の当座預金口座を表す場合であれば、そのビジネス・インタフェースには顧客がその口座を管理するためのメソッド(withdraw
、deposit
、balance
など)を含めます。
EJB 3.0ビジネス・インタフェースは、他のインタフェースを拡張できます。メッセージドリブンBeanの場合であれば、ビジネス・インタフェースはメッセージ・リスナー・インタフェースにするのが一般的です。どのメッセージング・リスナー・インタフェースにするかは、そのBeanで使用するメッセージングの種類によって決まります。たとえば、JMSの場合はjavax.jms.MessageListener
になります。セッションBeanのインタフェースには、このような明確な種類はありません。ビジネス・ニーズに合わせて、どのようなインタフェースでも使用できます。
注意: EJB 3.0ビジネス・インタフェースの唯一の要件は、 |
ステートレスおよびステートフル・セッションBeanによって実装されたビジネス・インタフェースのサンプルについては、「単純なステートレスEJBのサンプル」および「単純なステートフルEJBのサンプル」を参照してください。
EJBのビジネス・メソッドを設計する場合は、EJBのビジネス・インタフェースのメソッドのthrows
句にアプリケーション例外を定義できます。「アプリケーション例外」とは、Beanクラス内に作成したプログラムからクライアントに、アプリケーション・レベルの異常な状態を警告するための例外です。たとえば、顧客が当座預金口座の引出し可能額を超える金額を引き出そうとしたときに、その口座を表すAccount
EJBのwithdraw()
メソッドからアプリケーション例外をスローできます。
アプリケーション例外は、システム例外とは異なります。システム例外は、データベース管理システムが利用できないなど、システム・レベルの例外をクライアントに警告するためにEJBコンテナからスローされる例外です。システム・レベルのエラーが、アプリケーション例外として報告されないようにしてください。
また、インタフェースがリモート・ビジネス・インタフェースである場合や、Beanクラスに@WebService
JWSアノテーションが含まれている場合、およびメソッドに@WebMethod
アノテーションが含まれている場合でも、ビジネス・メソッドがjava.rmi.RemoteException
例外をスローしないようにする必要があります。唯一の例外は、ビジネス・インタフェースがjava.rmi.Remote
を拡張している場合です。EJBコンテナでプロトコル・レベルの問題が発生すると、基底のRemoteException
をラップしたEJBException
がスローされます。
注意:
|
EJB 3.0プログラミング・モデルでは、ビジネス・インタフェースにおいてクラス・レベルでジェネリックスを使用できます。
ジェネリックスを使用する場合のベスト・プラクティスとしては、まずジェネリックスを使用するスーパーインタフェースを定義し、実際のビジネス・インタフェースでは特定のデータ型を使用してこのスーパーインタフェースを拡張することをお薦めします。
次に、この方法のサンプルを示します。まず、ジェネリックスを使用するスーパーインタフェースをプログラミングします。
public interface RootI<T> { public T getObject(); public void updateObject(T object); }
次に、実際のビジネス・インタフェースをプログラミングし、特定のデータ型でRootI<T>
を拡張します。
@Remote public interface StatelessI extends RootI<String> { }
最後に、実際のステートレス・セッションBeanをプログラミングしてビジネス・インタフェースを実装します。メソッドの実装では、指定したデータ型(この場合はString
)を使用します。
@Stateless public class StatelessSample implements StatelessI { public String getObject() { return null; } public void updateObject(String object) { } }
ビジネス・インタフェースまたはクラスで型変数を定義しても削除されます。この場合、ビジネス・インタフェースがBeanクラスによって他のジェネリック情報ではなくその型パラメータの上限値でパラメータ化されている場合のみ、EJBアプリケーションを正常にデプロイすることができます。たとえば、次の例の上限値はObject
です。
public class StatelessSample implements StatelessI<Object> { public Object getObject() { return null; } public void updateObject(Object object) { } }
ビジネス・オブジェクトのシリアライズとデシリアライズは、以下のインタフェースでサポートされます。これらのインタフェースは、すべてのビジネス・オブジェクトで実装されます。
weblogic.ejb.spi.BusinessObject
weblogic.ejb.spi.BusinessHandle
BusinessObject._WL_getBusinessObjectHandle()
メソッドを使用して、ビジネス・ハンドル・オブジェクトを取得し、シリアライズします。
ビジネス・オブジェクトをデシリアライズするには、ビジネス・ハンドル・オブジェクトをデシリアライズし、BusinessHandle.getBusinessObject()
メソッドを使用してビジネス・オブジェクトを取得します。
EJB Beanクラスは、EJBプログラミングの主要なアーティファクトで、EJBビジネス・インタフェースを実装し、EJBメタデータ・アノテーションを含みます。EJBメタデータ・アノテーションの用途としては、EJBコンテナへのセマンティクスおよび要件の指定、コンテナ・サービスのリクエスト、アプリケーション・デプロイヤやコンテナ・ランタイムへの構造情報および構成情報の提供などがあります。
EJB 3.0プログラミング・モデルで必須なアノテーションは、EJBのタイプを指定する@javax.ejb.Stateful
、@javax.ejb.Stateless
、または@javax.ejb.MessageDriven
のいずれか1つのみです。他にも様々なアノテーションを使用してEJBを細かく構成できますが、それらのアノテーションには一般的なデフォルト値が設定されているため、デフォルト以外の動作を設定したい場合を除けば、Beanクラス内で明示的にそれらのアノテーションを使用する必要はありません。このようなプログラミング・モデルにより、一般的な動作を実行するEJBのプログラミングが非常に簡単になっています。
Beanクラスのプログラミングの詳細やサンプルについては、第5章「アノテーション付きEJB 3.0クラスのプログラミング」を参照してください。
インターセプタは、ビジネス・メソッドの呼出しやライフサイクル・コールバック・イベントをインターセプトするメソッドです。
インターセプタ・メソッドは、実際のBeanクラス内に定義できますが、Beanクラスとは別にインターセプタ・クラスをプログラミングして@javax.ejb.Interceptor
アノテーションでBeanクラスに関連付けることもできます。
インターセプタを使用するBeanクラスのプログラミングについては、「ビジネス・メソッドまたはライフサイクル・コールバック・イベントのインターセプタを指定する」を参照してください。
EJB BeanクラスのJavaソース・コードの記述と、必要に応じてインターセプタ・クラスの記述が完了したら、それらをクラス・ファイルにコンパイルする必要があります。コンパイルするためのツールとしては以下が一般的です。
weblogic.appc
: weblogic.appc
Javaクラス(またはこれと同等のAntタスクwlappc
)は、EJBおよびJSPをWebLogic Serverにデプロイするのに必要なクラスを生成し、コンパイルします。また、オプションのデプロイメント記述子を検証して、個別のモジュール・レベルとアプリケーション・レベルの両方で現在の仕様に準拠しているかどうかをチェックします。アプリケーション・レベルのチェックでは、個別のモジュールに対するアプリケーション・レベルのデプロイメント記述子のチェックと、モジュール全体の検証チェックが行われます。詳細は、『Oracle WebLogic Serverアプリケーションの開発』のwlappcを使用したモジュールとアプリケーションのビルドに関する項を参照してください。
wlcompile
Antタスク: javac
コンパイラを呼び出して、アプリケーションのJavaコンポーネントを分割開発ディレクトリ構造にコンパイルします。詳細は、『Oracle WebLogic Serverアプリケーションの開発』のwlcompileを使用したアプリケーションのコンパイルに関する項を参照してください。
javac
: Java SE JDKに付属のjavac
コンパイラは、javaコンパイル機能を提供します。http://www.oracle.com/technetwork/java/index-jsp-142903.html#documentation
を参照してください。
新しいEJB 3.0プログラミング・モデルの非常に重要な点は、メタデータ・アノテーションが導入されたことです。アノテーションを使用すると、コンテナ内でのBeanの動作、依存関係インジェクションのリクエスト方法などをJavaクラス自体の中で指定でき、EJBの開発プロセスを簡略化できます。アノテーションは、EJBの2.X以前のバージョンで必要だったデプロイメント記述子にかわるものです。
デプロイメント記述子は、EJB 3.0でも引続き完全にサポートされます。ただし、Java Platform, Enterprise Edition (Java EE)バージョン5標準のデプロイメント記述子は必須ではありません。たとえば、従来の2.Xプログラミング・モデルを使用したい場合や、後々の開発やデプロイメントの段階でより細かくカスタマイズできるようにしたい場合、メタデータ・アノテーションに加えて(またはメタデータ・アノテーションの代わりに)標準のデプロイメント記述子を作成できます。
デプロイメント記述子要素は、対応するアノテーションを常にオーバーライドします。たとえば、Beanクラス内に@javax.ejb.TransactionManagement(BEAN)
アノテーションを指定した上で、そのEJB用のejb-jar.xml
デプロイメント記述子を作成し、<transaction-type>
要素をcontainer
に設定した場合は、デプロイメント記述子の値が優先され、このEJBではコンテナ管理によるトランザクションの境界設定が使用されます。
注意: EJB 3.0バージョンでは、2.XでサポートされていたWebLogic固有のEJB機能がすべてサポートされます。ただし、 |
『Oracle WebLogic Server Enterprise JavaBeansのプログラミング』の2.Xバージョンでは、Java EE標準およびWebLogic固有のEJBデプロイメント記述子の作成と編集について詳しく説明しています。特に、次の項を参照してください。
「EJBデプロイメント記述子」(EJBデプロイメント記述子の概要)
「デプロイメント記述子を編集する」
「デプロイメント記述子スキーマおよびドキュメント・タイプ定義リファレンス」
「weblogic-ejb-jar.xmlデプロイメント記述子のリファレンス」
「weblogic-cmp-jar.xmlデプロイメント記述子のリファレンス」
EJBをエンタープライズ・アプリケーションの一部としてパッケージ化することをお薦めします。詳細は、『Oracle WebLogic Serverアプリケーションの開発』の分割開発ディレクトリからのデプロイとパッケージ化に関する項を参照してください。
EJB固有のパッケージ化に関するその他の情報については、『Oracle WebLogic Server Enterprise JavaBeansのプログラミング』のクライアントが他のアプリケーションにあるEJBのパッケージ化の考慮事項に関する項を参照してください。
EJBをデプロイすると、WebLogic ServerはEJBのコンポーネントをクライアントに提供できるようになります。EJBは、ユーザーの環境とEJBが本番環境に置かれるかどうかに基づいて、複数の手順のうちの1つでデプロイできます。3.0プログラミング・モデルで作成したEJBのデプロイメント方法は、2.Xプログラミング・モデルで作成したEJBのデプロイメント方法と同じです。
WebLogic Serverアプリケーションおよびモジュール(EJBを含む)をデプロイする一般的な手順については、『Oracle WebLogic Serverへのアプリケーションのデプロイ』を参照してください。EJB固有のデプロイメントの問題と手順については、2.Xプログラミング・モデルに特化した『Oracle WebLogic Server Enterprise JavaBeansのプログラミング』のEnterprise JavaBeansのデプロイメント・ガイドラインに関する項を参照してください。