| Oracle® Fusion Middleware Oracle WebLogic Server Enterprise JavaBeansのプログラミング 11gリリース1(10.3.6) B61624-04 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle WebLogic Server Enterprise JavaBeansのプログラミング 11gリリース1(10.3.6) B61624-04 |
|
前 |
次 |
以降の節では、EJBの実装プロセスを説明し、EJBをWebLogic Serverで実行する方法についても説明します。
この章は、WebLogic ServerのEJBの付加価値機能を理解し、アプリケーションの設計パターンをすでに選択しており、主要な設計上の決定をすでに行っている読者を対象としています。
WebLogic Server EJBの機能の概要については、「WebLogic ServerのEJBの付加価値機能」を参照してください。
EJBの設計オプション、設計の過程で考慮する要素、およびお薦めの設計パターンについては、「Enterprise JavaBeansの設計」を参照してください。
この節では、EJB開発プロセスを簡単に説明します。主な実装タスクと関連する結果について説明します。
図4-1に、EJBの開発プロセスを示します。プロセスの手順、および各手順の結果については、表4-1を参照してください。以下の節では、各手順について詳しく説明します。
表4-1 EJB開発タスクと結果
| 手順 | 説明 | 結果 |
|---|---|---|
|
|
ソース・ファイル、デプロイメント記述子、および実装の過程で生成されるファイルのディレクトリ構造を作成します。 |
ローカル・ドライブ上のディレクトリ構造 |
|
|
Beanを構成するクラスを作成します。適切なタグをソース・コードに挿入して、これ以降の実装プロセスでのデプロイメント記述子要素の自動生成を有効にします。 |
各クラスの |
|
|
ソース・コードをコンパイルします。 |
各クラスの |
|
|
Beanの実行時の動作と環境を構成するデプロイメント記述子を記述または生成します。 |
|
|
|
Beanの目的の実行時動作がすべて正しく反映されるように、デプロイメント記述子の編集が必要な場合もあります。 Beanが使用するオプションの機能を指定するマークアップがソース全体に記述され、EJBGenを使用してデプロイメント記述子を自動的に生成する場合、デプロイメント記述子の編集は最小限にする必要があります。 |
|
|
EJBラッパー・クラスとスタブおよびスケルトン・ファイルを生成する |
ホーム・インタフェースやリモート・インタフェースのクラスを含む、デプロイメント・ユニットにアクセスするためのコンテナ・クラスを生成します。 |
生成されたクラスはアーカイブまたはディレクトリに追加されます。 |
|
|
コンパイル済みファイル、生成ファイル、およびデプロイメント記述子をデプロイメント用にパッケージ化します。 状況によっては、ファイルをアーカイブせずにディレクトリ形式で展開しておくことも可能です。 |
アーカイブ(JARまたはEAR) |
|
|
選択したステージング・モードに従って、アーカイブまたはアプリケーション・ディレクトリのターゲットとして目的の管理対象サーバーまたはWebLogic Serverクラスタを設定します。 |
Beanのデプロイメント設定は、 |
EJBをアセンブルするソース・ディレクトリを作成します。
ソース・ファイルと出力ファイルを並列ディレクトリ構造に分離する分割開発ディレクトリ構造をお薦めします。分割ディレクトリ構造を準備し、EJBをエンタープライズ・アプリケーション・アーカイブ(EAR)としてパッケージ化する方法については、『Oracle WebLogic Serverアプリケーションの開発』の「分割開発ディレクトリ構造の概要」を参照してください。
EJBをJARファイルにパッケージ化してデプロイする場合は、クラス・ファイルのディレクトリと、デプロイメント記述子ファイル用のMETA-INFというサブディレクトリを作成します。
必要なクラスは、開発するEJBのタイプによって異なります(「EJBの構成要素」を参照)。
クラス・ファイルおよびインタフェース・ファイルを開発するための生産性の高いツールが用意されています。EJBGenコマンド・ライン・ユーティリティはクラス・ファイルとインタフェース・ファイルの作成プロセスを自動化するとともに、EJBのデプロイメント記述子ファイルも生成します。これらのツールの詳細と使い方については、「EJBGenリファレンス」を参照してください。
以降の節では、WebLogic Server固有のEJB機能を使用する上でのヒントとガイドラインを示します。
WebLogic Serverでは、各EJBタイプについて、ほとんどのEJBで必要なJavaコールバック(リスナー)が含まれる汎用クラスが提供されます。それらの汎用クラスは、weblogic.ejb パッケージにあります。
GenericEnterpriseBean
GenericEntityBean
GenericMessageDrivenBean
GenericSessionBean
汎用Beanテンプレートは、その汎用クラスを作成中のクラスにインポートすることで独自のクラスで実装できます。次の例では、GenericSessionBeanクラスがHelloWorldEJBにインポートされます。
import weblogic.ejb.GenericSessionBean;
...
public class HelloWorldEJB extends GenericSessionBean {
以降の節では、EJBに対するクライアント・アクセスをプログラミングするためのガイドラインを示します。
ローカル・クライアントは、次の抜粋のようなgetInitialContextメソッドを使用して初期コンテキストを取得します。
例4-2 ルックアップを実行するローカル・クライアント
...
Context ctx = getInitialContexLt("t3://localhost:7001", "user1", "user1Password");
...
static Context getInitialContext(String url, String user, String password) {
Properties h = new Properties();
"weblogic.jndi.WLInitialContextFactory");
h.put(Context.PROVIDER_URL, url);
h.put(Context.SECURITY_PRINCIPAL, user);
h.put(Context.SECURITY_CREDENTIALS, password);
return new InitialContext(h);
}
リモート・クライアントは、WebLogic Server InitialContextファクトリからInitialContextを取得します。
クライアントは、次の2つの方法のいずれかでエンティティBeanのホーム・インタフェースをルックアップできます。
EJB参照に従います。Java Naming and Directory Interface (JNDI)から直接ホーム・インタフェースをルックアップする方法であり、もう1つの方法よりパフォーマンスがよく、Oracleのベスト・プラクティスです。EJB参照の使い方については、次節「EJBリンクの使用」を参照してください。
Java Naming and Directory Interface (JNDI)から直接。コンテナが、グローバルなサーバー側のJNDIネームスペースでエンティティBeanのホーム・インタフェースをバインドします。手順については、『Oracle WebLogic Server JNDIのプログラミング』を参照してください。
EJBリンクの使用はOracleのベスト・プラクティスであり、WebLogic ServerはEJB 2.1仕様で定義されているEJBリンクを完全にサポートしています。アプリケーション・コンポーネント内でEJB参照を宣言し、これを同じJava EEアプリケーション内で宣言されたエンタープライズBeanにリンクさせることができます。
ejb-jar.xmlファイルで、参照元アプリケーション・コンポーネントのejb-ref要素のejb-link要素を使用してEJBへのリンクを指定します。ejb-linkの値は、参照先EJBのejb-jar.xmlとweblogic-ejb-jar.xml両方のejb-nameの値と同じでなければなりません。参照先のEJBは、参照元アプリケーション・コンポーネントと同じJava EEアプリケーションのEJB JARファイルのどれかに含まれていると考えられます。
ejb-nameはEJB JARファイル間で必ずしも一意でなくてもよいため、そのリンクの絶対パスを与える必要があるかもしれません。次の構文を使用して、同じJava EEアプリケーション内のEJBへのパス名を与えます。
<ejb-link>../products/product.jar#ProductEJB</ejb-link>
この参照では参照先のEJBが含まれるEJB JARファイルのパス名を与え、「#」でパス名と区別して参照先Beanのejb-nameを追加します。このパス名は、参照元のアプリケーション・コンポーネントJARファイルからの相対パスです。
EJBがjava.net.URLリソース・マネージャ接続ファクトリ・タイプを使用して外部HTTPサーバーとのHttpURLConnectionを開くようにするには、URLまたはURLに対応するJNDIツリーでバインドされたオブジェクトをejb-jar.xmlのresource-ref要素およびweblogic-ejb-jar.xmlのres-ref-name要素を使用して指定します。
EJBがリクエストを送信するURLを指定するには:
ejb-jar.xmlのresource-ref要素の<jndi-name>要素でURLを指定します。
weblogic-ejb-jar.xmlのresource-description要素の<jndi-name>要素でURLを指定します。
<resource-description>
<res-ref-name>url/MyURL</res-ref-name>
<jndi-name>http://www.rediff.com/</jndi-name>
</resource-description>
WebLogic Serverは指定されたjndi-nameでURLオブジェクトを作成し、そのオブジェクトをjava:comp/envにバインドします。
URLを指定するかわりに、JNDIでバインドされ、URLに対応するオブジェクトを指定するには、次のようにします。
ejb-jar.xmlのresource-ref要素の<jndi-name>要素で、URLがJNDIでバインドされている名前を指定します。
次のように、weblogic-ejb-jar.xmlのresource-description要素の<jndi-name>要素で、URLがJNDIでバインドされている名前を指定します。
<resource-description>
<res-ref-name>url/MyURL1</res-ref-name>
<jndi-name>firstName</jndi-name>
</resource-description>
firstNameは、URLに対応するJNDIツリーにバインドされたオブジェクトです。このバインディングは、起動クラスで行うこともできます。jndi-nameが有効なURLでない場合、WebLogic ServerはそれをURLに対応し、すでにJNDIツリーにバインドされているオブジェクトとして取り扱い、LinkRefとそのjndi-nameをバインドします。
HTTPリソースの指定方法(URLかURLに対応するJNDI名か)に関係なく、次のようにしてEJBのコードからそのHTTPリソースにアクセスできます。
URL url = (URL) context.lookup("java:comp/env/url/MyURL");
connection = (HttpURLConnection)url.openConnection();
EJBが通信に使用するネットワーク接続の属性は、カスタム・ネットワーク・チャネルを構成してEJBに割り当てることによって設定できます。WebLogic Serverのネットワーク・チャネルとそれに関連する構成手順については、『Oracle WebLogic Serverサーバー環境の構成』の「ネットワーク・リソースの構成」を参照してください。カスタム・チャネルを構成したら、weblogic-ejb-jar.xmlのnetwork-access-point要素を使用してEJBに割り当てます。
トランザクション設計上の決定事項については、「トランザクションの設計と管理のオプション」を参照してください。以降の節では、トランザクション・プログラミングのガイドラインを示します。
トランザクションをエンティティBeanと使用することについては、「ejbLoad()とejbStore()の動作について」を参照してください。
コンテナ管理によるトランザクションは、Bean管理によるトランザクションよりもプログラミングが簡単です。その理由は、境界設定(トランザクションの開始と停止)がEJBコンテナで行われるからです。
トランザクション動作は、ejb-jar.xmlおよびweblogic-ejb-jar.xmlで構成します。関連情報については、「コンテナ管理によるトランザクション要素」を参照してください。
コンテナ管理によるトランザクションの主なプログラミング・ガイドラインは以下のとおりです。
トランザクション境界の保持 - コンテナが設定したトランザクションの境界に干渉するメソッドは呼び出さないでください。以下のメソッドは使用しないでください。
java.sql.Connectionのcommit、setAutoCommit、およびrollbackメソッド
javax.ejb.EJBContextのgetUserTransactionメソッド
javax.transaction.UserTransactionのすべてのメソッド
トランザクションの明示的なロールバック - 明示的にコンテナがコンテナ管理によるトランザクションをロールバックするようにするには、EJBContextインタフェースのsetRollbackOnlyメソッドを呼び出します。Beanからアプリケーション例外がスローされる場合(通常はEJBException)、ロールバックは自動的に行われます。
シリアライゼーション問題の回避 - 多くのデータ・ストアでは、シリアライゼーションに関する問題の検出は、単一ユーザー接続の場合でさえ制限されています。そのような場合は、weblogic-ejb-jar.xmlのtransaction-isolationがTransactionSerializableに設定されていても、同じ行でクライアント間に競合が発生した場合はEJBクライアントで例外またはロールバックが発生する場合があります。そのような例外を回避するために、以下のことができます。
SQL例外を捕捉して(たとえばトランザクションを再起動などして)適切に解決するコードをクライアント・アプリケーションに含める
Oracleデータベースの場合は、「isolation-level」で説明されているトランザクションのアイソレーション設定を使用する
このリリースのWebLogic Serverでは、トランザクションを開始したビジネス・メソッドが、システム例外に関連のないトランザクション・ロールバックが原因で失敗した場合、EJBコンテナが新しいトランザクションを開始し、失敗したメソッドを指定された回数まで再試行するように指定できます。メソッドの失敗が指定された再試行回数に達した場合、EJBコンテナは例外をスローします。
|
注意: EJBコンテナは、システム例外に基づくエラーが原因で失敗したトランザクションは再試行しません。 |
コンテナ管理によるトランザクションの自動的な再試行を構成するには:
使用するBeanがコンテナ管理によるセッションBeanまたはエンティティBeanであることを確認します。
コンテナ管理によるセッションBeanおよびエンティティBeanの場合にのみ、コンテナ管理によるトランザクションの自動再試行を構成できます。メッセージドリブンBeanの場合は、コンテナ管理によるトランザクションの自動再試行を構成できません。MDBは、メッセージの受信を含むトランザクションがロールバックされたときに、そのメッセージの受信の確認応答を行わないため、メッセージは確認応答が行われるまで自動的に再試行されます。また、タイマーBeanの場合も、コンテナ管理によるトランザクションの自動再試行は構成できません。タイマーBeanのejbTimeoutメソッドが開始されてロールバックされると、タイムアウトが常に再試行されるからです。
トランザクションの自動再試行を構成する場合、対象となるビジネス・メソッドは、Beanのリモートまたはローカル・インタフェースの内部か、またはホーム・インタフェースのホーム・メソッド(特定のBeanインスタンスに固有ではないローカル・ホーム・ビジネス・ロジック)として定義されている必要があります。メソッドには、以下のコンテナ管理トランザクション属性の1つが設定されていなければなりません。
RequiresNew。メソッドのトランザクション属性(ejb-jar.xmlのtrans-attribute要素)がRequiresNewの場合、メソッドの呼出し前に常に新しいトランザクションが開始され、構成されている場合、そのトランザクションが失敗すると自動再試行が行われます。
Required。メソッドのトランザクション属性(ejb-jar.xmlのtrans-attribute要素)がRequiredの場合、メソッドが新しいトランザクションで再試行されるのは、失敗したトランザクションがそのメソッドのために開始された場合のみです。
詳細については、以下を参照してください。
プログラミング・インタフェースについては、「EJBのクラスとインタフェースを作成する」とSunのドキュメント。
ejb-jar.xmlのtrans-attribute要素については、「コンテナ管理によるトランザクション要素」のtrans-attributeとSunのドキュメント。
トランザクションの自動再試行を有効にする場合、対象となるメソッドは再呼出しできなければなりません。失敗したメソッドの再試行によって得られる結果は、直前の再試行が成功した場合に得られる結果と同じでなければなりません。特に、以下の場合です。
メソッドの呼出しによって呼出しチェーンが開始された場合、そのメソッドを再試行するときは呼出しチェーン全体を再呼び出しするのが安全です。
メソッドのすべてのパラメータを再利用できなければなりません。メソッドが再試行される場合、そのメソッドは失敗したメソッドを呼び出すために使用されたパラメータで再試行されます。一般に、再利用できるパラメータは、プリミティブ、不変オブジェクト、または読取り専用オブジェクトの参照です。パラメータがメソッドによって変更されるオブジェクトの参照である場合、メソッドの再呼出しによってメソッド呼出しの結果に悪影響が生じてはなりません。
再試行されるメソッドを保持するBeanがステートフル・セッションBeanである場合、そのBeanの対話状態は再呼出し時に失われてはなりません。ステートフル・セッションBeanの状態はトランザクション対応ではなく、トランザクションのロールバック中に復元できないので、トランザクションの自動再試行の機能を使用する場合、Beanの状態がロールバック後も有効であることを確認しておく必要があります。
EJBコンテナがどのメソッドのトランザクションを自動的に再試行するか、およびその回数は、weblogic-ejb-jar.xmlのretry-methods-on-rollback要素で指定します。
retry-methods-on-rollbackのretry-count下位要素は、管理コンソールからも変更できます。
この節では、Bean管理によるトランザクションのプログラミング上の考慮事項を示します。Beanレベルのトランザクションの特徴的な機能の概要や関連する設計上の考慮事項の説明については、「Beanレベルのトランザクション管理」を参照してください。
トランザクションの境界設定 - EJBまたはクライアント・コードにトランザクション境界を定義するには、Java Transaction Service (JTS)またはJDBCデータベース接続を取得する前に、UserTransactionオブジェクトを取得してトランザクションを開始しなければなりません。UserTransactionオブジェクトを取得するには、次のコマンドを使用します。
ctx.lookup("javax.transaction.UserTransaction");
UserTransactionオブジェクトを取得した後は、tx.begin()、tx.commit()、tx.rollback()でトランザクションの境界を指定します。
データベース接続を取得してからトランザクションを開始した場合、その接続は新しいトランザクションと何の関連性も持たず、以後のトランザクション・コンテキストにその接続を「入れる」ためのセマンティクスも存在しません。JTS接続がトランザクション・コンテキストに関連付けられていない場合、JTS接続はautocommitをtrueに設定した標準のJDBC接続と同じように動作し、更新はデータ・ストアに自動的にコミットされます。
いったんトランザクション・コンテキスト内にデータベース接続が作成されると、その接続はトランザクションがコミットまたはロールバックされるまで確保されます。パフォーマンスとスループットを最適化するには、トランザクションを迅速に完了させることによって、データベース接続を解放し、他のクライアント・リクエストが使用できるようにする必要があります。
|
注意: アクティブなトランザクション・コンテキストには単一のデータベース接続しか関連付けることができません。 |
トランザクション分離レベルの設定 - Bean管理によるトランザクションでは、分離レベルはBeanコードで定義します。有効な分離レベルは、java.sql.Connectionインタフェースで定義されます。各分離レベルの詳細は、「isolation-level」を参照してください。
サンプル・コードについては、例4-3を参照してください。
例4-3 BMTでのトランザクション分離レベルの設定
import javax.transaction.Transaction;
import java.sql.Connection
import weblogic.transaction.TxHelper:
import weblogic.transaction.Transaction;
import weblogic.transaction.TxConstants;
User Transaction tx = (UserTransaction)
ctx.lookup("javax.transaction.UserTransaction");
//Begin user transaction
tx.begin();
//Set transaction isolation level to TransactionReadCommitted
Transaction tx = TxHelper.getTransaction();
tx.setProperty (TxConstants.ISOLATION_LEVEL, new Integer
(Connection.TransactionReadCommitted));
//perform transaction work
tx.commit();
制限されたメソッドの回避 - Bean管理によるトランザクションでは、EJBContextインタフェースのgetRollbackOnlyメソッドとsetRollbackOnlyメソッドは呼び出さないでください。これらのメソッドは、コンテナ管理によるトランザクションのみで使用します。Bean管理によるトランザクションでは、UserTransactionインタフェースのgetStatusメソッドとrollbackメソッドを呼び出します。
アクティブなトランザクション・コンテキストにつき1つの接続の使用 - アクティブなトランザクション・コンテキストに関連付けることができるのは、1つのデータベース接続だけです。
この節では、複数のBean(複数のサーバー・インスタンスに存在する場合もある)にトランザクションを分散させる2つのアプローチを説明します。
次の断片的なコードは、UserTransactionオブジェクトを取得し、それを使用してトランザクションを開始およびコミットするクライアント・アプリケーションから引用したものです。クライアントは、トランザクションのコンテキストの中で2つのEJBを呼び出します。
import javax.transaction.*;...u = (UserTransaction) jndiContext.lookup("javax.transaction.UserTransaction");u.begin();account1.withdraw(100);account2.deposit(100);u.commit();...
account1とaccount2のBeanで実行される更新は、1つのUserTransactionのコンテキスト内で行われます。同じサーバー・インスタンス上にあるか、異なるサーバー・インスタンスにあるか、またはWebLogic Serverクラスタにあるのかに関係なく、EJBは1つの論理単位として一緒にコミットまたはロールバックされます。
1つのトランザクション・コンテキストから呼び出されるEJBはすべて、クライアント・トランザクションをサポートしている必要があります。つまり、ejb-jar.xmlの各Beanのtrans-attribute要素が、Required、Supports、またはMandatoryに設定されている必要があります。
トランザクションをカプセル化する「ラッパー」EJBを使用できます。クライアントはラッパーEJBを呼び出して銀行振替などのアクションを実行し、ラッパーは新しいトランザクションを開始して、トランザクションの処理を実行する1つまたは複数のEJBを呼び出します。
ラッパーEJBは、他のEJBを呼び出す前にトランザクション・コンテキストを明示的に取得できます。あるいは、ejb-jar.xmlでラッパーのtrans-attribute要素がRequiredまたはRequiresNewに設定されている場合、WebLogic Serverは新しいトランザクション・コンテキストを自動的に作成できます。
ラッパーEJBによって呼び出されるすべてのEJBは、そのラッパーEJBのトランザクション・コンテキストをサポートしている必要があります。つまり、そのtrans-attribute要素がRequired、Supports、またはMandatoryに設定されていなければなりません。
WebLogic Serverは、EJB 2.1仕様とEJB 3.0仕様で定義されているEJBタイマー・サービスをサポートしています。EJBタイマー・サービスはEJBコンテナによって提供されるサービスです。このサービスを使用すると、タイマー・オブジェクトが期限切れになったときに発生するコールバックをスケジューリングするタイマーを作成できます。タイマー・オブジェクトは、エンティティBean、メッセージドリブンBean、およびステートレス・セッションBean用に作成できます。タイマー・オブジェクトは、指定した時間、指定した期間の経過後、または指定した間隔で期限切れになります。たとえば、タイマー・サービスを使用して、EJBが一定期間にわたって特定の状態のままであるときに通知を送信できます。
WebLogic EJBタイマー・サービスは、大まかなタイマー・サービスとして使用するように設計されています。大量のタイマー・オブジェクトを使用してデータ・セットに対して同じタスクを実行するより、少数のタイマーを使用して大量のタスクを実行することをお薦めします。たとえば、従業員の経費レポートを表すEJBがあるとします。各経費レポートは、マネージャの承認を受けてから処理されなければなりません。この場合、1つのEJBタイマーを使用してすべての未決の経費レポートを定期的に検査し、担当のマネージャに対して、承認待ちのレポートを決裁するように促す電子メールを送信できます。
EJBタイマー・サービスは、2つのタイプ(クラスタまたはローカル)を構成することができます。
クラスタ化EJBタイマー・サービスには、次の利点があります。
可視性に優れています。
クラスタ内のすべてのノードからタイマーにアクセスできます。たとえば、javax.ejb.TimerService.getTimers()メソッドを使用すると、EJBに対して作成されたクラスタに含まれるすべてのステートレス・セッションBeanタイマーまたはメッセージドリブンBeanタイマーの完全なリストが返されます。エンティティBeanの主キーをgetTimers()メソッドに渡すと、そのエンティティBeanのタイマーのリストが返されます。
自動ロード・バランシングおよびフェイルオーバー
クラスタ化EJBタイマー・サービスは、ジョブ・スケジューラのロード・バランシング機能とフェイルオーバー機能を利用できます。
クラスタ化EJBタイマー・サービスの構成については、「クラスタ化EJBタイマーの構成」を参照してください。
ローカルEJBタイマー・サービスは、ローカルEJBタイマー・サービスが作成されたサーバー上でのみ実行され、そのサーバー上のBeanにしか認識されません。ローカルEJBタイマー・サービスを使用する場合、クラスタ化EJBタイマー・サービスとは異なり、クラスタ、データベース、JDBCデータ・ソース、またはリース・サービスを構成する必要はありません。
ローカルEJBタイマー・オブジェクトは、別のサーバーに移行できません。タイマー・オブジェクトは、サーバー全体の一部としてのみ移行できます。EJBタイマーが存在するサーバーが何らかの理由でダウンした場合、サーバーを再起動するか、またはサーバー全体を移行しなければタイマーを実行できません。
この節では、EJB 2.1仕様に定義されている、タイマーのプログラミングに使用できるJavaプログラミング・インタフェースについて説明します。これらのインタフェースの詳細は、EJB 2.1仕様を参照してください。また、この節では、WebLogic Server固有のタイマー関連インタフェースについて詳しく説明します。
次の表に、タイマーのプログラミングに使用できるEJB 2.1インタフェースを示します。
表4-2 EJB 2.1タイマー関連プログラミング・インタフェース
| プログラミング・インタフェース | 説明 |
|---|---|
|
|
タイマー・コールバックのためにタイマー・サービスに登録されるBeanのエンタープライズBeanクラスによって実装されます。このインタフェースは、単一のメソッド、 |
|
|
|
|
|
EJBの新しいEJBタイマーを作成するか、既存のEJBタイマーにアクセスします。 |
|
|
特定のEJBタイマーに関する情報にアクセスします。 |
|
|
永続化できるシリアライズ可能なタイマー・ハンドルを定義します。タイマーはローカル・オブジェクトなので、 |
EJB 2.1のタイマー関連プログラミング・インタフェースの詳細は、EJB 2.1仕様を参照してください。
タイマーのプログラミングに使用できるWebLogic Server固有のインタフェースは以下のとおりです。
weblogic.management.runtime.EJBTimerRuntimeMBean。特定のEJBHomeのタイマーの実行時情報と管理機能を提供します。例4-4にweblogic.management.runtime.EJBTimerRuntimeMBeanインタフェースを示します。
例4-4 weblogic.management.runtime.EJBTimerRuntimeMBeanインタフェース
public interface weblogic.management.runtime.EJBTimerRuntimeMBean {
public int getTimeoutCount(); // get the number of successful timeout notifications that have been made
public int getActiveTimerCount(); // get the number of active timers for this EJBHome
public int getCancelledTimerCount(); // get the number of timers that have been cancelled for this EJBHome
public int getDisabledTimerCount(); // get the number of timers temporarily disabled for this EJBHome
public void activateDisabledTimers(); // activate any temporarily disabled timers
}
weblogic.ejb.WLTimerServiceインタフェース。javax.ejb.TimerServiceインタフェースの拡張です。このインタフェースを使用すると、タイマーに関するWebLogic Server固有の構成情報を指定できます。例4-5にweblogic.ejb.WLTimerServiceインタフェースを示します。javax.ejb.TimerServiceの詳細は、EJB 2.1仕様を参照してください。
例4-5 weblogic.ejb.WLTimerServiceインタフェース
public interface WLTimerService extends TimerService {
public Timer createTimer(Date initial, long duration, Serializable info,
WLTimerInfo wlTimerInfo)
throws IllegalArgumentException, IllegalStateException, EJBException;
public Timer createTimer(Date expiration, Serializable info,
WLTimerInfo wlTimerInfo)
throws IllegalArgumentException, IllegalStateException, EJBException;
public Timer createTimer(long initial, long duration, Serializable info
WLTimerInfo wlTimerInfo)
throws IllegalArgumentException, IllegalStateException, EJBException;
public Timer createTimer(long duration, Serializable info,
WLTimerInfo wlTimerInfo)
throws IllegalArgumentException, IllegalStateException, EJBException;
}
weblogic.ejb.WLTimerInfoインタフェース。weblogic.ejb.WLTimerServiceインタフェースで使用され、タイマーに関するWebLogic Server固有の構成情報を渡します。例4-6にweblogic.ejb.WLTimerInfoインタフェースを示します。
例4-6 weblogic.ejb.WLTimerInfoインタフェース
public final interface WLTimerInfo {
public static int REMOVE_TIMER_ACTION = 1;
public static int DISABLE_TIMER_ACTION = 2;
public static int SKIP_TIMEOUT_ACTION = 3;
/**
* Sets the maximum number of retry attempts that will be
* performed for this timer. If all retry attempts
* are unsuccesful, the timeout failure action will
* be executed.
*/
public void setMaxRetryAttempts(int retries);
public int getMaxRetryAttempts();
/**
* Sets the number of milliseconds that should elapse
* before any retry attempts are made.
*/
public void setRetryDelay(long millis);
public long getRetryDelay();
/**
* Sets the maximum number of timeouts that can occur
* for this timer. After the specified number of
* timeouts have occurred successfully, the timer
* will be removed.
*/
public void setMaxTimeouts(int max);
public int getMaxTimeouts();
/**
* Sets the action the container will take when ejbTimeout
* and all retry attempts fail. The REMOVE_TIMER_ACTION,
* DISABLE_TIMER_ACTION, and SKIP_TIMEOUT_ACTION fields
* of this interface define the possible values.
*/
public void setTimeoutFailureAction(int action);
public int getTimeoutFailureAction();
}
weblogic.ejb.WLTimerインタフェース。javax.ejb.Timerインタフェースの拡張であり、タイマーの現在の状態に関する追加情報を提供します。例4-7にweblogic.ejb.WLTimerインタフェースを示します。
タイマーに関連するデプロイメント記述子の要素は以下のとおりです。
表4-3 タイマー・デプロイメント記述子
| 要素 | 説明 |
|---|---|
|
|
EJBタイマー・オブジェクト。 |
|
|
EJBタイマー・サービスのクラスタリングの有無。クラスタ化EJBタイマー・サービスについては、「クラスタ化EJBタイマーの構成」を参照してください。 |
|
|
WebLogic Serverがタイマー・オブジェクトを格納する、サーバーのファイル・システム上の永続ストアの名前。 |
これらの要素の詳細は、「weblogic-ejb-jar.xmlデプロイメント記述子のリファレンス」を参照してください。
EJBタイマーのクラスタリングを構成するには、次のステップを実行します:
以下について構成したかどうかを確認します。
クラスタ化ドメイン。詳細は、『Oracle WebLogic Serverクラスタの使い方』の「WebLogicクラスタの設定」を参照してください。
ジョブ・スケジューラの以下の機能。
HAデータベース(Oracle、DB2、Informix、MySQL、Sybase、MSSQLなど)。
config.xmlファイルの<data-source-for-job-scheduler>要素を使用してHAデータベースにマップされているJDBCデータ・ソース。
リース・サービス。デフォルトでは、データベース・リースが使用され、config.xmlファイルの<data-source-for-job-scheduler>要素によって定義されたJDBCデータ・ソースが使用されます。
ジョブ・スケジューラの構成については、『Oracle WebLogic Server Timer and Work Manager API (CommonJ)プログラマーズ・ガイド』を参照してください。
クラスタ化EJBタイマー・サービスを有効にするために、weblogic-ejb-jar.xmlデプロイメント記述子のtimer-implementation要素をClusteredに設定します。
<timer-implementation>Clustered</timer-implementation>
詳細は、「timer-implementation」を参照してください。
クラスタ化EJBタイマー・サービスでは、以下のように動作が変更されることに注意してください。
weblogic.ejb.WLTimer*インタフェースは、クラスタ化EJBタイマー・サービスではサポートされません。
createTimer()メソッドを使用してクラスタ化EJBタイマーを新しく作成する場合、タイマーの初期セット・アップ時にタイムアウトの実行が遅延する場合があります。
ジョブ・スケジューラでは、「少なくとも1回」の実行が保証されます。クラスタ化EJBタイマーが期限切れになった場合、データベースはリスナー・コールバック・メソッドが完了するまで更新されません。データベースが更新される前にサーバーがクラッシュした場合、タイマーはもう一度実行されます。
クラスタ化EJBタイマー・サービスでは、障害が発生した場合に実行するアクションに関するタイマーの構成オプションは使用できません。これらの構成オプションには、再試行の遅延、再試行の最大数、タイムアウトの最大数、およびタイムアウト・エラー・アクションがあります。
ジョブ・スケジューラは、期限切れになるタイマーを識別するために30秒ごとにデータベースに対して問合せを実行します。30秒未満の間隔でタイマーの実行が遅延する場合があります。
障害が発生した場合、トランザクション対応のタイマーのみ再試行されます。
タイマー実行の固定間隔スケジューリングはサポートされません。
このリリースのWebLogic Serverは、外部のWebサービスの宣言およびアクセスに関するEJB 2.1の要件を満たしています。Webサービスの参照をEJBのデプロイメント記述子で宣言することによって、Webサービスの論理名が実際のWebサービス・インタフェースにマップされます。これにより、論理名を使用してWebサービスを参照できるようになります。次に、BeanコードはWebサービスの参照名を使用してJNDIルックアップを実行します。
詳細は、『Oracle WebLogic Server JAX-WS Webサービス・スタート・ガイド』を参照してください。
コンパイル・プロセスをサポートしているツールを確認するには、表4-1を参照してください。
コンパイル・プロセスについては、『Oracle WebLogic Serverアプリケーションの開発』を参照してください。
Beanのクラス・ファイルにJDK 1.5のアノテーションを追加すると、EJBGenを使用してEJBアプリケーションのリモート・クラス、ホーム・クラス、およびデプロイメント記述子ファイルを生成できます。
デプロイメント記述子の生成には、EJBGenを使用することをお薦めします。詳細については、付録E「EJBGenリファレンス」を参照してください。
ejb-jar.xml、weblogic-ejb-jar.xml、およびweblogic-cmp-jar.xml (コンテナ管理による永続性エンティティBeanの場合)の要素は、アプリケーションの実行時の特性を制御します。
記述子要素を修正する必要がある場合は、任意のテキスト・エディタを使用して記述子ファイルを編集できます。ただし、エラーを防止するために、XML編集用に設計されたツールを使用してください。WebLogic Server管理コンソールで編集できる記述子要素については、表4-1を参照してください。
以下の節では、WebLogic Server固有のデプロイメント要素を簡単に参照できます。各節では、特定のタイプの機能または動作に関連する要素が取り上げられています。各節の表では、制御する動作、関連するBeanタイプ(Beanタイプ固有の場合)、その要素が含まれるweblogic-ejb-jar.xmlの親要素、およびweblogic-ejb-jar.xmlで明示的に指定しない場合に予想される動作に基づいて関連要素が定義されています。
各記述子ファイルの要素、定義、および使用例の包括的なドキュメントについては、以下を参照してください。
ejb-jar.xmlの要素に関するSunのドキュメント
|
注意: 以降の節では、「要素」列の要素名をクリックすると、その要素の詳しい説明が表示されます。 |
この表は、セキュリティに関連するweblogic-ejb-jar.xmlの要素を示しています。
表4-4 weblogic-ejb-jar.xmlのセキュリティ要素
| 要素 | 説明 | デフォルト値 |
|---|---|---|
|
|
ejb-jar.xmlがアプリケーション・ロールを定義する場合に必須です。 |
なし |
|
|
このEJBに付与される追加のJavaセキュリティ許可。 |
なし |
|
|
|
なし |
|
|
RMI-IIOPプロトコルを使用するBeanのセキュリティ・オプション。 |
なし |
この表は、ソース・コードで使用されるBeanまたはリソースの名前をデプロイメント環境のJNDI名にマッピングするweblogic-ejb-jar.xmlの要素を示しています。
表4-5 weblogic-ejb-jar.xmlのリソース・マッピング要素
| 要素 | Beanタイプ | 説明 | デフォルト値 |
|---|---|---|---|
|
|
すべて |
WebLogic Serverのリソースまたは参照のJNDI名。 注意: JNDI名をBeanに割り当てるのは推奨されません。グローバルJNDI名は、クラスタ化サーバーの起動時に大量のマルチキャスト・トラフィックを引き起こします。より適切なプラクティスについては、「EJBリンクの使用」を参照してください。 |
なし |
|
|
すべて |
Beanのローカル・ホームのJNDI名。Beanがリモート・ホームとローカル・ホームを持つ場合は、それぞれのホームに1つずつのJNDI名を指定する必要があります。 |
なし |
|
|
MDB |
キューおよびトピックの作成にBeanが使用するJMS接続ファクトリのJNDI名。 |
|
|
|
MDB |
JNDIツリーでメッセージドリブンBeanとキューまたはトピックを関連付けるJNDI名。 |
なし |
|
|
MDB |
接続ファクトリの作成にEJBコンテナが使用する初期コンテキスト・ファクトリ。 |
|
|
|
MDB |
恒久サブスクライバ・トピックと関連付けられたメッセージドリブンBeanのクライアントID。 |
ejb-nameの値 |
|
message-destination-descriptor |
MDB |
|
なし |
|
|
MDB |
|
|
この表は、Beanの状態がどのように保持されるのかを指定するweblogic-ejb-jar.xmlの要素を示しています。
表4-6 weblogic-ejb-jar.xmlの永続性要素
| 要素 | Beanタイプ | 説明 | デフォルト値 |
|---|---|---|---|
|
|
エンティティ |
EJBの永続性タイプを指定します。WebLogic Server RDBMSベースの永続性では、 |
なし |
|
|
エンティティ |
この永続性タイプのデータを格納するファイルのパスを、EJBのデプロイメントJARファイルまたはデプロイメント・ディレクトリの最上位を基準にして定義します。 WebLogic Server RDBMSベースの永続性では通常、Beanの永続性データを格納するのに |
なし |
|
|
エンティティ |
type-identifierで指定された永続性タイプのバージョン。WebLogic 2.0 CMPの永続性の場合は、値 WebLogic 1.1 CMPの永続性の場合は、値1.1を使用します。 |
なし |
|
|
エンティティ |
trueの場合、EJBコンテナはトランザクションが終わるまでBeanの状態の更新をデータベースに書き込むのを遅らせようとします。ただしコンテナは、問合せの コンテナ管理による永続性BeanとBean管理による永続性Beanの両方に適用可能です。 |
True |
|
|
エンティティ |
注意: コンテナ管理による永続性Beanでのみ適用可能です。 |
True |
|
|
ステートフル・セッション |
パッシブ化されたステートフル・セッションBeanのインスタンスの状態が格納されるディレクトリ。 |
|
|
|
エンティティ |
Beanが変更されていて、その変更をデータベースに書き込む必要があるかどうかを判断するためにコンテナから呼び出されるメソッド。 Bean管理による永続性BeanまたはEJB 1.1コンテナ管理による永続性Beanに適用されます。 |
指定しないと、Beanの状態は各メソッドの完了後に保持されることになります。 |
この表は、クラスタリングに関連するweblogic-ejb-jar.xmlの要素を示しています。これらの要素は、WebLogic Serverクラスタのクラスタ化Beanのフェイルオーバーおよびロード・バランシング動作を制御します。
表4-7 weblogic-ejb-jar.xmlのクラスタリング要素
| 要素 | Beanタイプ | 説明 | デフォルト値 |
|---|---|---|---|
|
|
ステートフル・セッション ステートレス・セッション エンティティ |
ホーム・メソッド呼出しのルーティングに使用するカスタム・クラス。このクラスは |
なし |
|
|
ステートフル・セッション ステートレス・セッション エンティティ |
Beanのホームがクラスタリングできるかどうかを示します。 |
True |
|
|
ステートフル・セッション ステートレス・セッション エンティティ |
Beanホームのレプリカ間でロード・バランシングを行うためのアルゴリズム。 |
|
|
|
ステートレス・セッション エンティティ |
クラスタ化EJBの多重呼出し不変メソッド。多重呼出し不変のメソッドは、ネガティブな副作用なしに繰り返すことができます。 ステートレス・セッションBeanのホームおよび読取り専用エンティティBeanインスタンスのメソッドは、明示的に指定する必要はありません。それらのメソッドは自動的に多重呼出し不変として設定されます。 |
なし |
|
|
ステートフル・セッション |
クラスタのステートフル・セッションBeanに使用するレプリケーションを示します( |
|
|
stateless-bean-call-router-class-name |
ステートレス・セッション |
Beanメソッド呼出しのルーティングに使用するカスタム・クラス。 |
なし |
|
|
ステートレス・セッション |
Beanがクラスタリングできるかどうかを示します。 ejb-jar.xmlで |
True |
|
|
ステートレス・セッション |
Beanのレプリカ間でロード・バランシングを行うためのアルゴリズム。 |
|
|
|
ステートレス・セッション |
Beanホームがサーバー・コンテキストでサーバー側スタブを使用するようにします。 |
False |
この表は、Beanインスタンスのデータとデータベースの一貫性に関連するweblogic-ejb-jar.xmlの要素を示しています。これらの要素は、Beanインスタンスの値を反映して、いつどのようにデータベースが更新されるのかなどの動作を制御します。
表4-8 weblogic-ejb-jar.xmlのデータ一貫性要素
| 要素 | Beanタイプ | 説明 | デフォルト値 |
|---|---|---|---|
|
|
エンティティ |
エンティティBeanへの同時アクセスがどのように管理されるのか。 |
データベース |
|
|
エンティティ |
このコンテナ管理による永続性エンティティBeanが変更されたときに無効化する読取り専用エンティティBean。 注意: EJB 2.x CMP Beanにのみ適用できます。 |
なし |
|
|
エンティティ |
trueの場合、EJBコンテナはトランザクションが終わるまでBeanの状態の更新をデータベースに書き込むのを遅らせようとします。ただしコンテナは、問合せの コンテナ管理による永続性BeanとBean管理による永続性Beanの両方に適用可能です。 |
True |
表4-9は、コンテナ管理によるトランザクションに関連するejb-jar.xmlの要素を示しています。
表4-9 ejb-jar.xmlのコンテナ管理によるトランザクション要素
| 要素 | 説明 | デフォルト値 |
|---|---|---|
|
|
値は |
なし。EJB 2.xではこの属性の指定は必須となっています。 |
|
|
メソッドの呼出しをエンタープライズBeanのビジネス・メソッドに委託するときにコンテナがトランザクションの境界をどのように管理するのかを指定します。有効な値は次のとおりです:
注意: 9.0より前のリリースのWebLogic Serverでは、EJBコンテナは、トランザクションが存在せず、 クライアントはMDBの呼出しでトランザクション・コンテキストを提供しないので、コンテナ管理によるトランザクションを使用するMDBでは |
指定しないと、EJBコンテナは警告を発し、MDBでは |
|
|
この省略可能な要素は、エンタープライズBeanがそのメソッドで分散トランザクションを必須とするかどうか、またはローカル・トランザクションの最適化を使用できるかどうかを指定します。 値は |
指定しない場合、コンテナは分散トランザクションが使用されなければならないものと想定します。 |
表4-10は、コンテナ管理によるトランザクションに関連するweblogic-ejb-jar.xmlの要素を示しています。
表4-10 weblogic-ejb-jar.xmlのコンテナ管理によるトランザクション要素
| 要素 | 説明 | デフォルト値 |
|---|---|---|
|
|
ここで指定したメソッドに対して、EJBコンテナはロールバックされたコンテナ管理によるトランザクションを自動的に再試行します。 注意: この要素で指定されたメソッドに関わらず、EJBコンテナは、システム例外に基づくエラーが原因で失敗したトランザクションは再試行しません。 |
なし |
|
|
メソッドがトランザクションを開始するときに使用するトランザクション分離レベル。指定されたトランザクション・レベルは、メソッドが既存のトランザクションを継承する場合は使用されません。 |
基底のDBMSのデフォルト |
|
|
トランザクションの最長継続時間。 |
なし |
この表は、パフォーマンスに関連するweblogic-ejb-jar.xmlの要素を示しています。
表4-11 weblogic-ejb-jar.xmlのパフォーマンス要素
| 要素 | Beanタイプ | 説明 | デフォルト値 |
|---|---|---|---|
|
|
ステートフル・セッション |
ステートフル・セッションBeanインスタンスによるメソッド呼出しの処理中に、同時に他のメソッド呼出しがサーバーに送信されたときに、サーバーは |
False |
|
|
エンティティ |
コンテナがトランザクション間でエンティティBeanの永続データをキャッシュするようにします。 |
False |
|
|
ステートフル・セッション |
ステートフル・セッションBeanがキャッシュから削除される順序。 |
NRU (最近未使用) |
|
|
すべて |
Beanのすべてのクライアントが同じサーバー・インスタンス上でそのBeanと連結されていることを示します。この要素は、EJBにグローバルJNDI名がある場合のみ使用します。 値を |
False |
|
|
エンティティ |
ただしコンテナは、問合せの コンテナ管理による永続性BeanとBean管理による永続性Beanの両方に適用可能です。 |
True |
|
|
すべて |
Beanへのリクエストを処理するために使用するスレッド・プールを指定します。 |
なし |
|
|
エンティティ |
アプリケーション・レベルのエンティティ・キャッシュ。同じアプリケーションに属する複数のエンティティBeanのインスタンスをキャッシュできます。 注意: アプリケーション・レベルのキャッシュは |
なし |
|
|
エンティティ |
エンティティBeanのインスタンスの推定平均サイズ(バイト単位)。 |
なし |
|
|
エンティティ |
注意: コンテナ管理による永続性Beanでのみ適用可能です。 |
True |
|
|
エンティティ |
Beanがパッシブ化されるまでの活動のない状態の秒数。 注意: この要素は現在は使われていません。 |
600 |
|
|
ステートフル・セッション |
Beanがパッシブ化されるまでの活動のない状態の秒数。 |
600 |
|
|
エンティティ メッセージドリブン ステートレス・セッション |
起動時にコンテナによってインスタンス化されるEJBのインスタンスの数。 |
0 |
|
|
エンティティ |
Beanの状態を変更するメソッド。このメソッドを指定すると、WebLogic serverはメソッドの完了時にBeanの状態を保持します。 注意: Bean管理による永続性BeanまたはEJB 1.1コンテナ管理による永続性Beanに適用されます。 |
指定しないと、Beanの状態は各メソッドの完了後に保持されることになります。 |
|
|
メッセージドリブン |
アクセスできなくなっているJMS宛先にEJBコンテナが再接続しようとする試みの秒間隔。 |
10 |
|
|
エンティティ ステートフル・セッション |
キャッシュ内のインスタンスの最大数。 |
1000 |
|
|
エンティティ ステートレス・セッション メッセージドリブン |
フリー・プールのインスタンスの最大数。 |
1000 |
|
|
エンティティ |
読取り専用 |
600 |
コンテナ・クラスには、WebLogic Serverが使用するEJBの内部表現に加えて、クライアントが使用する外部インタフェース(ホーム、ローカル、またはリモート)の実装も格納されます。コンテナ・クラスを生成するには、Oracle Workshop for WebLogic Platformまたはappcを使用します。
コンテナ・クラスは、weblogic-ejb-jar.xmlの記述子要素に従って生成されます。たとえば、クラスタリング要素を指定すると、appcはデプロイメントで使用されるクラスタ化可能クラスを作成します。appcは、必要なオプションと引数を指定することでコマンド・ラインから直接使用できます。詳細については、「appc」を参照してください。
次の図は、EARまたはJARファイルの作成時にデプロイメント・ユニットに追加されるコンテナ・クラスを示しています。
まれなことではありますが、appcでクラス名を生成したとき、生成したクラス名の衝突に遭遇し、これがClassCastExceptionや他の例外を招くことがあります。これは、生成されるクラス名が、Beanクラス名、Beanクラス・パッケージ、そのBeanのejb-nameの3つのキーを基にしているためです。この問題が起こるのは、複数のJARファイルを含むEARファイルを使用し、その2つ以上のJARファイルのそれぞれにBeanクラス、パッケージ、または、クラス名を同じくするEJBが含まれ、双方のEJBがそれぞれのJARファイル内で同じejb-nameを持っている場合です。この問題が発生した場合は、いずれかのBeanのejb-nameを一意のものに変更してください。
ejb-nameはファイル名の基となるキーの1つであり、ejb-nameはJARファイル内で一意でなければならないので、同じJARファイルにある2つのEJB間ではこの問題は起きません。また、EARファイルではファイルごとに個別のクラスローダーになるため、別々のEARファイルに置かれた2つのEJB間でこの問題は起きません。
エンタープライズ・アプリケーションの一部としてEJBをパッケージ化することをお薦めします。詳細は、『Oracle WebLogic Serverアプリケーションの開発』の「分割開発ディレクトリからのデプロイとパッケージ化」を参照してください。
WebLogic Serverでは、別のアプリケーションのプログラムに基づくクライアントがEJBへのアクセスに必要とするEJBクラスをパッケージ化するためのejb-client.jarファイルの使用がサポートされています。
Beanのejb-jar.xmlファイルのejb-client-jar要素でクライアントJARの名前を指定します。appcコンパイラを実行すると、EJBにアクセスするために必要なクラスを持つJARファイルが生成されます。
クライアントJARをリモート・クライアントからアクセスできるようにします。Webアプリケーションの場合は、ejb-client.jarを/libディレクトリに配置します。非Webクライアントの場合は、クライアントのクラスパスでejb-client.jarを指定します。
|
注意: WebLogic Serverのクラスローディング動作は、クライアントがスタンドアロンかどうかによって異なります。ejb-client.jarにアクセスできるスタンドアロンのクライアントは、ネットワーク経由で必要なクラスをロードできます。ただし、セキュリティ上の理由から、サーバー・インスタンスで動作しているプログラムに基づくクライアントはネットワーク経由でクラスをロードすることはできません。 |
EJBをデプロイすると、WebLogic ServerはEJBのコンポーネントをクライアントに提供できるようになります。EJBは、ユーザーの環境とEJBが本番環境に置かれるかどうかに基づいて、複数の手順のうちの1つでデプロイできます。
WebLogic Serverアプリケーションおよびモジュール(EJBを含む)をデプロイする一般的な手順については、『Oracle WebLogic Serverへのアプリケーションのデプロイ』を参照してください。EJB固有のデプロイメントの問題と手続きについては、このドキュメント『Oracle WebLogic Server Enterprise JavaBeansのプログラミング』の第8章「Enterprise JavaBeansのデプロイメント・ガイドライン」を参照してください。
以降の節では、デプロイしたEJBのチェックとデバッグに便利なWebLogic Serverの機能を説明します。
appcでEJBをコンパイルする場合は、appc -lineNumbersコマンド・オプションを使用して、デバッグしやすいように生成したクラス・ファイルに行番号を追加できます。詳細については、付録D「appcリファレンス」を参照してください。
WebLogic Serverは、デプロイされたEJBの実行時の処理について様々なデータを収集します。管理コンソールの「デプロイメント」ノードで表示できるこのデータは、EJBが目的の処理を完了しているかどうかを判断する上で便利です。EJBの実行時の統計を表示するには、管理コンソールで「デプロイメント」ノードを展開し、そのBeanが含まれているJAR EARを見つけて「モニター」タブを選択します。
参照できるデータについては、Oracle WebLogic Server管理コンソール・オンライン・ヘルプにある次のページを参照してください。
この節では、EJB開発プロセスをサポートするOracleのツールについて説明します。各ツールの機能の比較については、表4-14を参照してください。
Oracle JDeveloperは、EJBのエンドツーエンドの開発に使用できるフル機能のJava IDEです。詳細については、Oracle JDeveloperのオンライン・ヘルプを参照してください。JDeveloperのインストールについては、『Oracle Fusion Middleware Installation Guide for Oracle JDeveloper』を参照してください。
Oracle Enterprise Eclipse (OEPE)はWebLogic Webサービスの開発を容易にするEclipse IDEプラットフォームのプラグイン群を提供します。詳細については、Eclipse IDEプラットフォームのオンライン・ヘルプを参照してください。
管理コンソールでは、多くのデプロイメント記述子要素について表示、修正、およびEJB内の記述子ファイルへの保持を行うことができます。記述子は、EJBの管理サーバー・コピー、ならびにEJBのすべてのデプロイされたコピー(デプロイメント後)において、修正されます。記述子を修正した場合、変更はユーザーのEJBのオリジナル・コピー(デプロイメント前)に対して行われます。
ただし、これらの記述子要素の更新は、EJBを再デプロイする必要なしに、実行時に動的に行われます。管理コンソールで変更できる記述子要素は、表4-13にまとめられているように、実行時に動的に変更できるものに限定されています。
Java SE JDKに付属のjavacコンパイラは、javaコンパイル機能を提供します。javacの詳細は、http://www.oracle.com/technetwork/java/index-jsp-142903.html#documentationを参照してください。
EJBGenは、EJB 2.xのコード・ジェネレータです。Beanクラス・ファイルにjavadocタグでアノテーションを付けた後、EJBGenを使用してEJBアプリケーションのリモート・インタフェース・クラス、ホーム・インタフェース・クラス、および、デプロイメント記述子ファイルを生成することができるので、編集および管理すべきEJBファイルの数を1つに減らせます。
デプロイメント記述子の生成には、EJBGenの使用をお薦めします; これは、EJBの維持を容易化および簡略化できる、Oracleのベスト・プラクティスです。EJBGenを使用する場合、記述してアノテーションを付ける必要があるBeanクラスは1つだけです。そのため、記述、デバッグ、および維持が簡略化されます。開発環境としてOracle Workshop for WebLogic Platformを使用すると、EJBGenタグが自動挿入されます。
EJBGenの詳細は、付録E「EJBGenリファレンス」を参照してください。
DDInitは、WebLogic Serverアプリケーションのデプロイメント記述子を生成するためのユーティリティです。DDInitでは、クラス・ファイルからの情報に基づいてデプロイメント記述子ファイルを作成します。
『Oracle WebLogic Serverコマンド・リファレンス』の「DDInit」を参照してください。
WebLogic Serverには、スケルトン・デプロイメント記述子を作成するためのAntユーティリティが用意されています。
Antタスクでは、EJBを含むディレクトリが検証され、そのディレクトリの内容に基づいてデプロイメント記述子が作成されます。Antユーティリティは、個別のEJBに必要な構成やマッピングに関する情報をすべて保持しているわけではないので、Antユーティリティによって作成されるスケルトン・デプロイメント記述子は不完全なものです。ユーティリティがスケルトン・デプロイメント記述子を作成した後で、テキスト・エディタやXMLエディタを使ってデプロイメント記述子を編集し、EJBの構成を完全なものにしてください。
詳細は、『Oracle WebLogic Serverアプリケーションの開発』の「wldeployを使用したアプリケーションのデプロイ」を参照してください。
weblogic.Deployerコマンド・ライン・ツールは、WebLogic ServerデプロイメントAPIにコマンド・ライン・インタフェースを提供する、Javaベースの開発ツールです。このツールは、コマンド・ライン、シェル・スクリプト、またはJava以外の自動化された環境からデプロイメントを開始する必要がある管理者および開発者向けに開発されました。
『Oracle WebLogic Serverへのアプリケーションのデプロイ』の「weblogic.Deployerコマンドライン・リファレンス」を参照してください。
appcコンパイラは、EJBおよびJSPをWebLogic Serverにデプロイするのに必要なクラスを生成し、コンパイルします。それは、個別のモジュール・レベルとアプリケーション・レベルの両方で、現在の仕様に準拠しているかどうかデプロイメント記述子を検証します。アプリケーション・レベルのチェックでは、個別のモジュールに対するアプリケーション・レベルのデプロイメント記述子のチェックと、モジュール全体の検証チェックが行われます。
|
注意: appcは、非推奨のejbcユーティリティの後継ツールです。非推奨のejbcではなくappcを使用することをお薦めします。 |
付録D「appcリファレンス」を参照してください。
DDConverterは、WebLogic Serverの旧リリースのデプロイメント記述子をアップグレードするコマンド・ライン・ツールです。最新のJava EE仕様とWebLogic Serverリリースの機能を活用するために、常にデプロイメント記述子をアップグレードすることをお薦めします。
weblogic.DDConverterを使用すると、デプロイメント記述子をアップグレードできます。weblogic.DDConverterの使い方については、『Oracle WebLogic Serverアプリケーションの開発』を参照してください。
|
注意: このリリースのWebLogic Serverでは、EJB固有のDDConverterであるweblogic.ejb20.utils.DDConverterは非推奨になっています。使用しているアプリケーションのデプロイメント記述子(EJB固有のデプロイメント記述子を含む)を変換するには、アプリケーション・レベルの新しいDDConverterであるweblogic.DDConverterを使用してください。 |
次の表はEJB開発のOracleツールと、各ツールの機能を示しています。はいは、そのツールが対応する機能を備えていることを示します。
表4-14 EJBツールとその機能
| EJBツール | インタフェースおよびホーム・インタフェースの生成 | Javaコードのコンパイル | デプロイメント記述子を生成する | デプロイメント記述子の表示と編集 | デプロイ |
|---|---|---|---|---|---|
|
WebLogic Workshop |
はい |
はい |
はい |
いいえ |
はい |
|
appc |
いいえ |
はい |
いいえ |
いいえ |
いいえ |
|
javac |
いいえ |
はい |
いいえ |
いいえ |
いいえ |
|
EJBGen |
はい |
いいえ |
はい |
はい |
いいえ |
|
DDInit |
いいえ |
いいえ |
はい |
いいえ |
いいえ |
|
管理コンソール |
いいえ |
いいえ |
いいえ |
はい |
はい |
|
Deployer |
いいえ |
いいえ |
いいえ |
いいえ |
はい |
|
DDConverter |
いいえ |
いいえ |
はい |
いいえ |
いいえ |
