4 Enterprise JavaBeansの実装
この章は、WebLogic ServerのEJBの付加価値機能を理解し、アプリケーションの設計パターンをすでに選択しており、主要な設計上の決定をすでに行っている読者を対象としています。
WebLogic Server EJBの機能の概要については、「WebLogic ServerのEJBの付加価値機能」を参照してください
EJBの設計オプション、設計の過程で考慮する要素、およびお薦めの設計パターンについては、「Enterprise JavaBeansの設計」を参照してください
この章の内容は次のとおりです。
- EJB開発プロセスの概要
EJBを開発するプロセスにおける主な実装タスクおよび対応する結果を学習します。 - ソース・ディレクトリを作成する
EJBをアセンブルするソース・ディレクトリを作成する方法を学習します。 - EJBのクラスとインタフェースを作成する
- EJBタイマー・サービスのプログラミング
WebLogic Serverは、EJB 2.1仕様とEJB 3.2仕様で定義されているEJBタイマー・サービスをサポートしています。EJBタイマー・サービスはEJBコンテナによって提供されるサービスです。このサービスを使用すると、タイマー・オブジェクトが期限切れになったときに発生するコールバックをスケジューリングするタイマーを作成できます。 - Webサービスの参照の宣言
Webサービスの参照をEJBのデプロイメント記述子で宣言することによって、Webサービスの論理名が実際のWebサービス・インタフェースにマップされます。これにより、論理名を使用してWebサービスを参照できるようになります。さらに、BeanコードはWebサービスの参照名を使用してJNDIルックアップを実行します。 - Javaソースをコンパイルする
コンパイルおよびコンパイル・プロセスをサポートしているツールを学習します。 - デプロイメント記述子を編集する
ejb-jar.xml
、weblogic-ejb-jar.xml
、およびweblogic-cmp-jar.xml
(コンテナ管理による永続性エンティティBeanの場合)の要素は、アプリケーションの実行時の特性を制御します。XML編集ツールを使用して、これらのデプロイメント記述子を変更できます。 - EJBラッパー・クラスとスタブおよびスケルトン・ファイルを生成する
コンテナ・クラスには、WebLogic Serverが使用するEJBの内部表現に加えて、クライアントが使用する外部インタフェース(ホーム、ローカル、またはリモート)の実装も格納されます。コンテナ・クラスを生成するには、Oracle Workshop for WebLogic Platformまたはappc
を使用します。 - パッケージ化する
エンタープライズ・アプリケーションの一部としてEJBをパッケージ化できます。 - デプロイする
EJBをデプロイすると、WebLogic ServerはEJBのコンポーネントをクライアントに提供できるようになります。EJBは、ユーザーの環境とEJBが本番環境に置かれるかどうかに基づいて、複数の手順のうちの1つでデプロイできます。 - 開発時に問題を解決する
デプロイしたEJBのチェックとデバッグに便利なWebLogic Serverの機能を学習します。 - EJBを開発するためのWebLogic Serverツール
EJB開発プロセスをサポートするOracleのツールについて調べます。
EJB開発プロセスの概要
EJBを開発するプロセスにおける主な実装タスクおよび対応する結果を学習します。
この節では、EJB開発プロセスを簡単に説明します。主な実装タスクと関連する結果について説明します。
図4-1に、EJBの開発プロセスを示します。プロセスのステップ、および各ステップの結果については、「表4-1」を参照してください。以下の節では、各ステップについて詳しく説明します。
表4-1 EJB開発タスクと結果
ステップ | 説明 | 結果 |
---|---|---|
ソース・ファイル、デプロイメント記述子、および実装の過程で生成されるファイルのディレクトリ構造を作成します。 |
ローカル・ドライブ上のディレクトリ構造 |
|
Beanを構成するクラスを作成します。適切なタグをソース・コードに挿入して、これ以降の実装プロセスでのデプロイメント記述子要素の自動生成を有効にします。 |
各クラスの |
|
ソース・コードをコンパイルします。 |
各クラスの |
|
Beanの目的の実行時動作がすべて正しく反映されるように、デプロイメント記述子の編集が必要な場合もあります。 |
|
|
ホーム・インタフェースやリモート・インタフェースのクラスを含む、デプロイメント・ユニットにアクセスするためのコンテナ・クラスを生成します。 |
生成されたクラスはアーカイブまたはディレクトリに追加されます。 |
|
コンパイル済みファイル、生成ファイル、およびデプロイメント記述子をデプロイメント用にパッケージ化します。 状況によっては、ファイルをアーカイブせずにディレクトリ形式で展開しておくことも可能です。 |
アーカイブ(JAR |
|
選択したステージング・モードに従って、アーカイブまたはアプリケーション・ディレクトリのターゲットとして目的の管理対象サーバーまたはWebLogic Serverクラスタを設定します。 |
Beanのデプロイメント設定は、 |
親トピック: Enterprise JavaBeansの実装
ソース・ディレクトリを作成する
EJBをアセンブルするソース・ディレクトリを作成する方法を学習します。
ソース・ファイルと出力ファイルを並列ディレクトリ構造に分離する分割開発ディレクトリ構造をお薦めします。分割ディレクトリ構造を準備し、EJBをエンタープライズ・アプリケーション・アーカイブ(EAR)としてパッケージ化する方法については、Oracle WebLogic Serverアプリケーションの開発の分割開発ディレクトリ構造の概要を参照してください。
EJBをJARファイルにパッケージ化してデプロイする場合は、クラス・ファイルのディレクトリと、デプロイメント記述子ファイル用のMETA-INF
というサブディレクトリを作成します。
例4-1 JARをパッケージ化するためのディレクトリ構造
myEJB/ META-INF/ ejb-jar.xml weblogic-ejb-jar.xml weblogic-cmp-jar.xml foo.class fooHome.class fooBean.class
親トピック: Enterprise JavaBeansの実装
EJBのクラスとインタフェースを作成する
必要なクラスは、開発するEJBのタイプによって異なります(EJBの構成要素を参照)。
以降の節では、WebLogic Server固有のEJB機能を使用する上でのヒントとガイドラインを示します。
- WebLogic Serverの汎用的なBeanテンプレートの使い方
- クライアントによるEJBへのアクセスのプログラミング
- クライアントによる初期コンテキストの取得のプログラミング
- クライアントによるホーム・インタフェースのルックアップのプログラミング
- URLに要求を送信するようにEJBを構成する
- URLによるHTTPリソースの指定
- JNDI名によるHTTPリソースの指定
- BeanコードからのHTTPリソースへのアクセス
- EJBのネットワーク通信の構成
- トランザクションのプログラミングと構成
- コンテナ管理によるトランザクションのプログラミング
- コンテナ管理トランザクションの自動的な再試行の構成
- Bean管理のトランザクションのプログラミング
- 複数のEJBで分散されるトランザクションのプログラミング
親トピック: Enterprise JavaBeansの実装
WebLogic Serverの汎用的なBeanテンプレートの使い方
WebLogic Serverでは、各EJBタイプについて、ほとんどのEJBで必要なJavaコールバック(リスナー)が含まれる汎用クラスが提供されます。それらの汎用クラスは、weblogic.ejb
パッケージにあります。
-
GenericEnterpriseBean
-
GenericEntityBean
-
GenericMessageDrivenBean
-
GenericSessionBean
汎用Beanテンプレートは、その汎用クラスを作成中のクラスにインポートすることで独自のクラスで実装できます。次の例では、GenericSessionBean
クラスがHelloWorldEJB
にインポートされます。
import weblogic.ejb.GenericSessionBean; ... public class HelloWorldEJB extends GenericSessionBean {
親トピック: EJBのクラスとインタフェースを作成する
クライアントによるEJBへのアクセスのプログラミング
以降の節では、EJBに対するクライアント・アクセスをプログラミングするためのガイドラインを示します。
親トピック: 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
を取得します。
親トピック: EJBのクラスとインタフェースを作成する
クライアントによるホーム・インタフェースのルックアップのプログラミング
クライアントは、次の2つの方法のいずれかでエンティティBeanのホーム・インタフェースをルックアップできます。
-
EJB参照に従います。Java Naming and Directory Interfaceから直接ホーム・インタフェースをルックアップする方法であり、もう1つの方法よりパフォーマンスがよく、Oracleのベスト・プラクティスです。EJB参照の使い方については、次節「EJBリンクの使用」を参照してください
-
Java Naming and Directory Interface (JNDI)から直接。コンテナが、グローバルなサーバー側のJNDIネームスペースでエンティティBeanのホーム・インタフェースをバインドします。『Oracle WebLogic Server JNDIアプリケーションの開発』を参照してください。
親トピック: EJBのクラスとインタフェースを作成する
EJBリンクの使用
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ファイルからの相対パスです。
URLに要求を送信するようにEJBを構成する
EJBがjava.net.URL
リソース・マネージャ接続ファクトリ・タイプを使用して外部HTTPサーバーとのHttpURLConnection
を開くようにするには、URLまたはURLに対応するJNDIツリーでバインドされたオブジェクトをejb-jar.xml
のresource-ref
要素およびweblogic-ejb-jar.xml
のres-ref-name
要素を使用して指定します。
親トピック: EJBのクラスとインタフェースを作成する
JNDI名によるHTTPリソースの指定
URLを指定する代わりに、JNDIでバインドされ、URLに対応するオブジェクトを指定するには、次のようにします。
親トピック: EJBのクラスとインタフェースを作成する
BeanコードからのHTTPリソースへのアクセス
HTTPリソースの指定方法(URLかURLに対応するJNDI名か)に関係なく、次のようにしてEJBのコードからそのHTTPリソースにアクセスできます。
URL url = (URL) context.lookup("java:comp/env/url/MyURL"); connection = (HttpURLConnection)url.openConnection();
親トピック: EJBのクラスとインタフェースを作成する
EJBのネットワーク通信の構成
EJBが通信に使用するネットワーク接続の属性は、カスタム・ネットワーク・チャネルを構成してEJBに割り当てることによって設定できます。WebLogic Serverのネットワーク・チャネルとそれに関連する構成手順の詳細は、Oracle WebLogic Serverサーバー環境の管理のネットワーク・リソースの構成を参照してください。カスタム・チャネルを構成したら、weblogic-ejb-jar.xml
のnetwork-access-point
要素を使用してEJBに割り当てます。
親トピック: EJBのクラスとインタフェースを作成する
トランザクションのプログラミングと構成
トランザクション設計上の決定事項については、「トランザクションの設計と管理のオプション」を参照してください以降の節では、トランザクション・プログラミングのガイドラインを示します。
トランザクションをエンティティBeanと使用することについては、「ejbLoad()とejbStore()の動作の理解」を参照してください
親トピック: EJBのクラスとインタフェースを作成する
コンテナ管理によるトランザクションのプログラミング
コンテナ管理によるトランザクションは、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」で説明されているトランザクションのアイソレーション設定を使用する
-
親トピック: EJBのクラスとインタフェースを作成する
コンテナ管理トランザクションの自動的な再試行の構成
このリリースのWebLogic Serverでは、トランザクションを開始したビジネス・メソッドが、システム例外に関連のないトランザクション・ロールバックが原因で失敗した場合、EJBコンテナが新しいトランザクションを開始し、失敗したメソッドを指定された回数まで再試行するように指定できます。メソッドの失敗が指定された再試行回数に達した場合、EJBコンテナは例外を送出します。
ノート:
EJBコンテナは、システム例外に基づくエラーが原因で失敗したトランザクションは再試行しません。
コンテナ管理によるトランザクションの自動的な再試行を構成するには、次の手順に従います。
親トピック: EJBのクラスとインタフェースを作成する
Bean管理のトランザクションのプログラミング
この節では、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を参照してください。
-
制限されたメソッドの回避 - Bean管理によるトランザクションでは、
EJBContext
インタフェースのgetRollbackOnly
メソッドとsetRollbackOnly
メソッドは呼び出さないでください。これらのメソッドは、コンテナ管理によるトランザクションのみで使用します。Bean管理によるトランザクションでは、UserTransaction
インタフェースのgetStatus
メソッドとrollbackメソッドを呼び出します。 -
アクティブなトランザクション・コンテキストにつき1つの接続の使用 - アクティブなトランザクション・コンテキストに関連付けることができるのは、1つのデータベース接続だけです。
例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();
親トピック: EJBのクラスとインタフェースを作成する
複数のEJBで分散されるトランザクションのプログラミング
この節では、複数のBean (複数のサーバー・インスタンスに存在する場合もある)にトランザクションを分散させる2つのアプローチを説明します。
クライアントのトランザクション・コンテキストから複数のEJBを呼び出す
次の断片的なコードは、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「ラッパー」を使用してEJB間トランザクションをカプセル化する
トランザクションをカプセル化する「ラッパー」EJBを使用できます。クライアントはラッパーEJBを呼び出して銀行振替などのアクションを実行し、ラッパーは新しいトランザクションを開始して、トランザクションの処理を実行する1つまたは複数のEJBを呼び出します。
ラッパーEJBは、他のEJBを呼び出す前にトランザクション・コンテキストを明示的に取得できます。あるいは、ejb-jar.xml
でラッパーのtrans-attribute
要素がRequired
またはRequiresNew
に設定されている場合、WebLogic Serverは新しいトランザクション・コンテキストを自動的に作成できます。
ラッパーEJBによって呼び出されるすべてのEJBは、そのラッパーEJBのトランザクション・コンテキストをサポートしている必要があります。つまり、そのtrans-attribute
要素がRequired
、Supports
、またはMandatory
に設定されていなければなりません。
親トピック: 複数のEJBで分散されるトランザクションのプログラミング
EJBタイマー・サービスのプログラミング
EJBタイマー・サービスの詳細は、Enterprise JavaBean 3.2仕様ドキュメントのタイマー・サービスに関する章を参照してください。このドキュメントは、Community Development of Java Technology Specificationsページからダウンロードできます。
タイマー・オブジェクトは、エンティティBean、メッセージドリブンBean、およびステートレス・セッションBean用に作成できます。タイマー・オブジェクトは、指定した時間、指定した期間の経過後、または指定した間隔で期限切れになります。たとえば、タイマー・サービスを使用して、EJBが一定期間にわたって特定の状態のままであるときに通知を送信できます。
WebLogic EJBタイマー・サービスは、大まかなタイマー・サービスとして使用するように設計されています。大量のタイマー・オブジェクトを使用してデータ・セットに対して同じタスクを実行するより、少数のタイマーを使用して大量のタスクを実行することをお薦めします。たとえば、従業員の経費レポートを表すEJBがあるとします。各経費レポートは、マネージャの承認を受けてから処理されなければなりません。この場合、1つのEJBタイマーを使用してすべての未決の経費レポートを定期的に検査し、担当のマネージャに対して、承認待ちのレポートを決裁するように促す電子メールを送信できます。
- クラスタ化されたEJBタイマー・サービスとローカルEJBタイマー・サービス
- クラスタ化されたEJBタイマー・サービス
- ローカルEJBタイマー・サービス
- Javaプログラミング・インタフェースを使用してタイマー・オブジェクトをプログラミングする
- EJB 2.1タイマー関連プログラミング・インタフェース
- WebLogic Server固有のタイマー関連インタフェース
- タイマー・デプロイメント記述子
- クラスタ化されたEJBタイマーの構成
親トピック: Enterprise JavaBeansの実装
クラスタ化されたEJBタイマー・サービスとローカルEJBタイマー・サービス
EJBタイマー・サービスは、2つのタイプ(クラスタまたはローカル)を構成することができます。
親トピック: EJBタイマー・サービスのプログラミング
クラスタ化されたEJBタイマー・サービス
クラスタ化されたEJBタイマー・サービスには、次の利点があります。
-
可視性に優れています。
クラスタ内のすべてのノードからタイマーにアクセスできます。たとえば、
javax.ejb.TimerService.getTimers()
メソッドを使用すると、EJBに対して作成されたクラスタに含まれるすべてのステートレス・セッションBeanタイマーまたはメッセージドリブンBeanタイマーの完全なリストが返されます。エンティティBeanの主キーをgetTimers()
メソッドに渡すと、そのエンティティBeanのタイマーのリストが返されます。 -
自動ロード・バランシングおよびフェイルオーバー
クラスタ化されたEJBタイマー・サービスは、ジョブ・スケジューラのロード・バランシング機能とフェイルオーバー機能を利用できます。
クラスタ化されたEJBタイマー・サービスの構成については、「クラスタ化されたEJBタイマーの構成」を参照してください
親トピック: EJBタイマー・サービスのプログラミング
ローカルEJBタイマー・サービス
ローカルEJBタイマー・サービスは、ローカルEJBタイマー・サービスが作成されたサーバー上でのみ実行され、そのサーバー上のBeanにしか認識されません。ローカルEJBタイマー・サービスを使用する場合、クラスタ化されたEJBタイマー・サービスとは異なり、クラスタ、データベース、JDBCデータ・ソース、またはリース・サービスを構成する必要はありません。
ローカルEJBタイマー・オブジェクトは、別のサーバーに移行できません。タイマー・オブジェクトは、サーバー全体の一部としてのみ移行できます。EJBタイマーが存在するサーバーが何らかの理由でダウンした場合、サーバーを再起動するか、またはサーバー全体を移行しなければタイマーを実行できません。
エンタープライズBeanのタイマーには、プログラムによるタイマーと自動タイマーの2つのタイプがあります。
エンタープライズBeanのプログラムによるタイマーについて
エンタープライズBeanのプログラムによるタイマーを設定するには、TimerService
インタフェースのタイマー作成メソッドの1つを明示的に呼び出します。
次に、プログラムによるタイマーを作成するEJBの例を示します。このタイマーは、createTimer
メソッドが呼び出されると、1分(6,000ミリ秒)で時間切れになります。
import javax.ejb.*;
public class TimerServiceExampleBean
{
@Resource
private TimerService timerService;
public void createTimer()
{
long duration = 6000;
Timer timer = timerService.createSingleActionTimer(duration, new TimerConfig());
}
@Timeout
public void timeout()
{
System.out.println("timeout() method invoked in TimerServiceExampleBean... ");
…
}
}
親トピック: ローカルEJBタイマー・サービス
エンタープライズBeanの自動タイマーについて
エンタープライズBeanの自動タイマーは、java.ejb.Schedule
またはjava.ejb.Schedules
アノテーションが付けられたメソッドを含むエンタープライズBeanが正常にデプロイされると作成されます。
次に、自動タイマーおよびautomaticTimeout
タイムアウト・メソッドがあるEJBの例を示します。自動タイマーは3分ごとに時間切れになるように設定されており、@Schedule
アノテーションでカレンダベースのタイマー式を使用して設定されます。
public class TimerSessionBean {
@Schedule(minute="*/3", hour="*")
public void automaticTimeout() {
this.setLastAutomaticTimeout(new Date());
logger.info("Automatic timeout occured");
}
}
親トピック: ローカルEJBタイマー・サービス
Javaプログラミング・インタフェースを使用してタイマー・オブジェクトをプログラミングする
この節では、EJB 2.1仕様に定義されている、タイマーのプログラミングに使用できるJavaプログラミング・インタフェースについて説明します。これらのインタフェースの詳細については、EJB 2.1仕様を参照してください。また、この節では、WebLogic Server固有のタイマー関連インタフェースについて詳しく説明します。
親トピック: EJBタイマー・サービスのプログラミング
EJB 2.1タイマー関連プログラミング・インタフェース
次の表に、タイマーのプログラミングに使用できるEJB 2.1インタフェースを示します。
表4-2 EJB 2.1タイマー関連プログラミング・インタフェース
プログラミング・インタフェース | 説明 |
---|---|
|
タイマー・コールバックのためにタイマー・サービスに登録されるBeanのエンタープライズBeanクラスによって実装されます。このインタフェースは、単一のメソッド、 |
|
|
|
EJBの新しいEJBタイマーを作成するか、既存のEJBタイマーにアクセスします。 |
|
特定のEJBタイマーに関する情報にアクセスします。 |
|
永続化できるシリアライズ可能なタイマー・ハンドルを定義します。タイマーはローカル・オブジェクトなので、 |
EJB 2.1のタイマー関連プログラミング・インタフェースの詳細については、EJB 2.1仕様を参照してください。
親トピック: EJBタイマー・サービスのプログラミング
WebLogic Server固有のタイマー関連インタフェース
タイマーのプログラミングに使用できるWebLogic Server固有のインタフェースは以下のとおりです。
-
weblogic.management.runtime.EJBTimerRuntimeMBean
。特定のEJBHome
のタイマーの実行時情報と管理機能を提供します。例4-4にweblogic.management.runtime.EJBTimerRuntimeMBean
インタフェースを示します。
-
weblogic.ejb.WLTimerService
インタフェース。javax.ejb.TimerService
インタフェースの拡張です。このインタフェースを使用すると、タイマーに関するWebLogic Server固有の構成情報を指定できます。例4-5にweblogic.ejb.WLTimerService
インタフェースを示します。javax.ejb.TimerService
の詳細は、EJB 2.1仕様を参照してください。ノート:
weblogic.ejb.WLTimerService
インタフェースは、クラスタ化EJBタイマー・サービスではサポートされません(「クラスタ化EJBタイマーの構成」を参照)。
-
weblogic.ejb.WLTimerInfo
インタフェース。weblogic.ejb.WLTimerService
インタフェースで使用され、タイマーに関するWebLogic Server固有の構成情報を渡します。例4-6にweblogic.ejb.WLTimerInfo
インタフェースを示します。ノート:
weblogic.ejb.WLTimerService
インタフェースは、クラスタ化EJBタイマー・サービスではサポートされません(「クラスタ化EJBタイマーの構成」を参照)。
-
weblogic.ejb.WLTimer
インタフェース。javax.ejb.Timer
インタフェースの拡張であり、タイマーの現在の状態に関する追加情報を提供します。例4-7にweblogic.ejb.WLTimer
インタフェースを示します。ノート:
weblogic.ejb.WLTimerService
インタフェースは、クラスタ化EJBタイマー・サービスではサポートされません(「クラスタ化EJBタイマーの構成」を参照)。
例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 }
例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; }
例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(); }
例4-7 weblogic.ejb.WLTimerインタフェース
public interface WLTimer extends Timer { public int getRetryAttemptCount(); public int getMaximumRetryAttempts(); public int getCompletedTimeoutCount(); }
親トピック: EJBタイマー・サービスのプログラミング
タイマー・デプロイメント記述子
タイマーに関連するデプロイメント記述子の要素は以下のとおりです。
表4-3 タイマー・デプロイメント記述子
要素 | 説明 |
---|---|
EJBタイマー・オブジェクト。 |
|
EJBタイマー・サービスのクラスタ化の有無。クラスタ化されたEJBタイマー・サービスについては、「クラスタ化されたEJBタイマーの構成」を参照してください |
|
WebLogic Serverがタイマー・オブジェクトを格納する、サーバーのファイル・システム上の永続ストアの名前。 |
これらの要素の詳細については、「weblogic-ejb-jar.xmlデプロイメント記述子のリファレンス」を参照してください
親トピック: EJBタイマー・サービスのプログラミング
クラスタ化されたEJBタイマーの構成
ノート:
クラスタ化されたEJBタイマーの利点については、「クラスタ化されたEJBタイマー・サービスとローカルEJBタイマー・サービス」を参照してください
EJBタイマーのクラスタ化を構成するには、次のステップに従います。
クラスタ化されたEJBタイマー・サービスでは、以下のように動作が変更されることに注意してください。
-
weblogic.ejb.WLTimer*
インタフェースは、クラスタ化されたEJBタイマー・サービスではサポートされません。 -
createTimer()
メソッドを使用してクラスタ化されたEJBタイマーを新しく作成する場合、タイマーの初期セット・アップ時にタイムアウトの実行が遅延する場合があります。 -
ジョブ・スケジューラでは、「少なくとも1回」の実行が保証されます。クラスタ化されたEJBタイマーが期限切れになった場合、データベースはリスナー・コールバック・メソッドが完了するまで更新されません。データベースが更新される前にサーバーがクラッシュした場合、タイマーはもう一度実行されます。
-
クラスタ化されたEJBタイマー・サービスでは、障害が発生した場合に実行するアクションに関するタイマーの構成オプションは使用できません。これらの構成オプションには、再試行の遅延、再試行の最大数、タイムアウトの最大数、およびタイムアウト・エラー・アクションがあります。
-
ジョブ・スケジューラは、期限切れになるタイマーを識別するために30秒ごとにデータベースに対して問合せを実行します。30秒未満の間隔でタイマーの実行が遅延する場合があります。
-
障害が発生した場合、トランザクション対応のタイマーのみ再試行されます。
-
タイマー実行の固定間隔スケジューリングはサポートされません。
親トピック: EJBタイマー・サービスのプログラミング
Webサービスの参照の宣言
Webサービスの参照をEJBのデプロイメント記述子で宣言することによって、Webサービスの論理名が実際のWebサービス・インタフェースにマップされます。これにより、論理名を使用してWebサービスを参照できるようになります。さらに、BeanコードはWebサービスの参照名を使用してJNDIルックアップを実行します。
このリリースのWebLogic Serverは、外部のWebサービスの宣言およびアクセスに関するEJB 2.1の要件を満たしています。
親トピック: Enterprise JavaBeansの実装
Javaソースをコンパイルする
コンパイルおよびコンパイル・プロセスをサポートしているツールを学習します。
コンパイル・プロセスをサポートしているツールを確認するには、表4-1を参照してください。
コンパイル・プロセスについては、『Oracle WebLogic Serverアプリケーションの開発』を参照してください。
親トピック: Enterprise JavaBeansの実装
デプロイメント記述子を編集する
ejb-jar.xml
、weblogic-ejb-jar.xml
、およびweblogic-cmp-jar.xml
(コンテナ管理による永続性エンティティBeanの場合)の要素は、アプリケーションの実行時の特性を制御します。XML編集ツールを使用して、これらのデプロイメント記述子を変更できます。
記述子要素を修正する必要がある場合は、任意のテキスト・エディタを使用して記述子ファイルを編集できます。ただし、エラーを防止するために、XML編集用に設計されたツールを使用してください。WebLogic Server管理コンソールで編集できる記述子要素については、表4-1を参照してください。
以下の節では、WebLogic Server固有のデプロイメント要素を簡単に参照できます。各節では、特定のタイプの機能または動作に関連する要素が取り上げられています。各節の表では、制御する動作、関連するBeanタイプ(Beanタイプ固有の場合)、その要素が含まれるweblogic-ejb-jar.xml
の親要素、およびweblogic-ejb-jar.xml
で明示的に指定しない場合に予想される動作に基づいて関連要素が定義されています。
各記述子ファイルの要素、定義、および使用例の包括的なドキュメントについては、以下を参照してください。
-
ejb-jar.xml
の要素に関するSunのドキュメントノート:
以降の節では、「要素」列の要素名をクリックすると、その要素の詳しい説明が表示されます。
親トピック: Enterprise JavaBeansの実装
セキュリティ要素
この表は、セキュリティに関連する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の値 |
|
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に使用するレプリケーションを示します( |
|
|
ステートレス・セッション |
Beanメソッド呼出しのルーティングに使用するカスタム・クラス。 |
なし |
|
ステートレス・セッション |
Beanがクラスタ化できるかどうかを示します。 ejb-jar.xmlで |
True |
|
ステートレス・セッション |
Beanのレプリカ間でロード・バランシングを行うためのアルゴリズム。 |
|
|
ステートレス・セッション |
Beanホームがサーバー・コンテキストでサーバー・サイド・スタブを使用するようにします。 |
False |
親トピック: デプロイメント記述子を編集する
データの一貫性要素
この表は、Beanインスタンスのデータとデータベースの一貫性に関連するweblogic-ejb-jar.xml
の要素を示しています。これらの要素は、Beanインスタンスの値を反映して、いつどのようにデータベースが更新されるのかなどの動作を制御します。
ノート:
コンテナ管理による永続性に関連する要素については、「エンティティ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-ejb-jar.xml
の要素を示しています。
表4-12 weblogic-ejb-jar.xmlの通信要素
要素 | Beanタイプ | 説明 | デフォルト値 |
---|---|---|---|
すべて |
EJBにカスタム・ネットワーク・チャネルを割り当てます。 |
なし |
親トピック: デプロイメント記述子を編集する
EJBラッパー・クラスとスタブおよびスケルトン・ファイルを生成する
コンテナ・クラスには、WebLogic Serverが使用するEJBの内部表現に加えて、クライアントが使用する外部インタフェース(ホーム、ローカル、またはリモート)の実装も格納されます。コンテナ・クラスを生成するには、Oracle Workshop for WebLogic Platformまたはappc
を使用します。
コンテナ・クラスは、weblogic-ejb-jar.xml
の記述子要素に従って生成されます。たとえば、クラスタ化要素を指定すると、appc
はデプロイメントで使用されるクラスタ対応クラスを作成します。appc
は、必要なオプションと引数を指定することでコマンド・ラインから直接使用できます。詳細については、「appc」を参照してください。
次の図は、EARまたはJARファイルの作成時にデプロイメント・ユニットに追加されるコンテナ・クラスを示しています。
appcと生成されたクラス名の衝突
まれなことではありますが、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をパッケージ化できます。
EJBをエンタープライズ・アプリケーションの一部としてパッケージ化することをお薦めします。『Oracle WebLogic Serverアプリケーションの開発』の「分割開発ディレクトリからのデプロイメントとパッケージ化」を参照してください。
クライアントが他のアプリケーションにあるEJBのパッケージ化の考慮事項
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バージョン2.1の開発』の「Enterprise JavaBeansのデプロイメント・ガイドライン」を参照してください。
親トピック: Enterprise JavaBeansの実装
開発時に問題を解決する
デプロイしたEJBのチェックとデバッグに便利なWebLogic Serverの機能を学習します。
次の各項では、WebLogic Serverのデバッグ機能について説明します。
行番号をクラス・ファイルに追加する
appc
でEJBをコンパイルする場合は、appc -lineNumbers
コマンド・オプションを使用して、デバッグしやすいように生成したクラス・ファイルに行番号を追加できます。詳細は、「appcリファレンス」参照してください。
親トピック: 開発時に問題を解決する
データをモニターする
WebLogic Serverは、デプロイされたEJBの実行時の処理についてさまざまなデータを収集します。このデータは、WebLogic Server管理コンソールの「デプロイメント」ノードで表示でき、EJBが目的の処理ステップを完了しているかどうかを判断する上で便利です。EJBの実行時の統計を表示するには、WebLogic Server管理コンソールで「デプロイメント」ノードを展開し、そのBeanが含まれているJAR EARを見つけて「モニタリング」タブを選択します。
参照できるデータについては、Oracle WebLogic Server管理コンソール・オンライン・ヘルプにある次のページを参照してください。
親トピック: 開発時に問題を解決する
デバッグ・メッセージを作成する
バグや問題のトラブルシューティングおよび解決に役立つメッセージをアプリケーションで作成する手順については、『Oracle WebLogic Serverログ・ファイルの構成とログ・メッセージのフィルタ処理』を参照してください。
親トピック: 開発時に問題を解決する
EJBを開発するためのWebLogic Serverツール
EJB開発プロセスをサポートするOracleのツールについて調べます。
各ツールの機能の比較については、表4-14を参照してください。
- Oracle JDeveloper
- Oracle Enterprise Pack for Eclipse
- 管理コンソール
- javac
- WebLogic Server Antユーティリティ
- weblogic.Deployer
- appc
- DDConverter
- EJBツールの機能の比較
親トピック: Enterprise JavaBeansの実装
Oracle JDeveloper
Oracle JDeveloperは、EJBのエンドツーエンドの開発に使用できるフル機能のJava IDEです。詳細は、Oracle JDeveloperのオンライン・ヘルプを参照してください。JDeveloperのインストールについては、『Oracle JDeveloperのインストール』を参照してください
Oracle Enterprise Pack for Eclipse
Oracle Enterprise Eclipse (OEPE) - WebLogic Webサービスの開発を容易にするEclipse IDEプラットフォームのプラグイン群を提供します。詳細については、Eclipse IDEプラットフォームのオンライン・ヘルプを参照してください。
管理コンソール
WebLogic Server管理コンソールでは、多くのデプロイメント記述子要素について表示、修正、およびEJB内の記述子ファイルへの保持を行うことができます。記述子は、EJBの管理サーバー・コピー、ならびにEJBのすべてのデプロイされたコピー(デプロイ後)において、修正されます。記述子を修正した場合、変更はユーザーのEJBのオリジナル・コピー(デプロイ前)に対して行われます。
ただし、これらの記述子要素の更新は、EJBを再デプロイする必要なしに、実行時に動的に行われます。WebLogic Server管理コンソールで変更できる記述子要素は、表4-13にまとめられているように、実行時に動的に変更できるものに限定されています。
表4-13 管理コンソールからアクセスできる記述子要素
EJBタイプ | 編集可能な要素 |
---|---|
エンティティ |
|
メッセージドリブン |
|
ステートレス |
|
ステートフル |
javac
Java SE JDKに付属のjavac
コンパイラは、javaコンパイル機能を提供します。javac
の詳細は、http://www.oracle.com/technetwork/java/index-jsp-142903.html#documentation
を参照してください。
WebLogic Server Antユーティリティ
WebLogic Serverには、スケルトン・デプロイメント記述子を作成するためのAntユーティリティが用意されています。
このAntタスクは、EJBを含むディレクトリを検証し、そのディレクトリの内容に基づいてデプロイメント記述子を作成します。Antユーティリティは、個別のEJBに必要な構成やマッピングに関する情報をすべて保持しているわけではないので、Antユーティリティによって作成されるスケルトン・デプロイメント記述子は不完全なものです。このユーティリティがスケルトン・デプロイメント記述子を作成した後で、テキスト・エディタやXMLエディタを使ってデプロイメント記述子を編集し、EJBの構成を完全なものにしてください。
Oracle WebLogic Serverアプリケーションの開発のwldeployを使用したアプリケーションのデプロイを参照してください。
weblogic.Deployer
weblogic.Deployer
コマンド・ライン・ツールは、WebLogic ServerデプロイメントAPIにコマンド・ライン・インタフェースを提供する、Javaベースの開発ツールです。このツールは、コマンド・ライン、シェル・スクリプト、またはJava以外の自動化された環境からデプロイメントを開始する必要がある管理者および開発者向けに開発されました。
Oracle WebLogic Serverへのアプリケーションのデプロイのweblogic.Deployerコマンドライン・リファレンスを参照してください。
appc
appc
コンパイラは、EJBおよびJSPをWebLogic Serverにデプロイするのに必要なクラスを生成し、コンパイルします。それは、個別のモジュール・レベルとアプリケーション・レベルの両方で、現在の仕様に準拠しているかどうかデプロイメント記述子を検証します。アプリケーション・レベルのチェックでは、個別のモジュールに対するアプリケーション・レベルのデプロイメント記述子のチェックと、モジュール全体の検証チェックが行われます。
ノート:
appc
は、非推奨のejbc
ユーティリティの後継ツールです。ejbc
ではなくappc
を使用することをお薦めします。
「appcリファレンス」を参照してください。
DDConverter
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ツールの機能の比較
次の表はEJB開発のOracleツールと、各ツールの機能を示しています。可は、そのツールが対応する機能を備えていることを示します。
表4-14 EJBツールとその機能
EJBツール | インタフェースおよびホーム・インタフェースの生成 | Javaコードのコンパイル | デプロイメント記述子を生成する | デプロイメント記述子の表示と編集 | デプロイ |
---|---|---|---|---|---|
WebLogic Workshop |
可 |
可 |
可 |
いいえ |
可 |
appc |
いいえ |
可 |
いいえ |
いいえ |
いいえ |
javac |
いいえ |
可 |
いいえ |
いいえ |
いいえ |
DDInit |
いいえ |
いいえ |
可 |
いいえ |
いいえ |
WebLogic Server管理コンソール |
いいえ |
いいえ |
いいえ |
可 |
可 |
Deployer |
いいえ |
いいえ |
いいえ |
いいえ |
可 |
DDConverter |
いいえ |
いいえ |
可 |
いいえ |
いいえ |