4 エンタープライズ JavaBean の実装

以降の節では、EJB の実装プロセスを説明し、EJB を WebLogic Server で実行する方法についても説明します。

この章は、WebLogic Server の EJB の付加価値機能を理解し、アプリケーションの設計パターンをすでに選択しており、主要な設計上の決定をすでに行っている読者を対象としています。

WebLogic Server EJB の機能の概要については、「WebLogic Server の EJB の付加価値機能」を参照してください。

EJB の設計オプション、設計の過程で考慮する要素、および推奨の設計パターンについては、「エンタープライズ JavaBean の設計」を参照してください。

• EJB 開発プロセスの概要

• ソース ディレクトリを作成する

• EJB のクラスとインタフェースを作成する

• EJB タイマー サービスのプログラミング

• Web サービスの参照の宣言

• Java ソースをコンパイルする

• デプロイメント記述子を生成する

• デプロイメント記述子を編集する

• EJB ラッパー クラスとスタブおよびスケルトン ファイルを生成する

• パッケージ化する

• デプロイする

• 開発時に問題を解決する

• EJB を開発するための WebLogic Server ツール

EJB 開発プロセスの概要

この節では、EJB 開発プロセスを簡単に説明します。主な実装タスクと関連する結果について説明します。

図 4-1 に、EJB の開発プロセスを示します。プロセスの手順、および各手順の結果については、表 4-1 を参照してください。以下の節では、各手順について詳しく説明します。

図 4-1 EJB 開発プロセスの概要

「図 4-1 EJB 開発プロセスの概要」の説明

表 4-1 EJB 開発タスクと結果

手順	説明	結果
ソース ディレクトリを作成する	ソース ファイル、デプロイメント記述子、および実装の過程で生成されるファイルのディレクトリ構造を作成する。	ローカル ドライブ上のディレクトリ構造
EJB のクラスとインタフェースを作成する	Bean を構成するクラスを作成する。適切なタグをソース コードに挿入して、これ以降の実装プロセスでのデプロイメント記述子要素の自動生成を有効にする。	各クラスの .java ファイル
Java ソースをコンパイルする	ソース コードをコンパイルする。	各クラスの .class ファイル
デプロイメント記述子を生成する	Bean の実行時の動作と環境をコンフィグレーションするデプロイメント記述子を記述または生成する。	ejb-jar.xml とオプションとして以下のもの weblogic-ejb-jar.xml (WebLogic Server 固有の機能を制御する要素が格納される) weblogic-cmp-jar.xml (Bean がコンテナ管理による永続性エンティティ Bean である場合)
デプロイメント記述子を編集する	Bean の目的の実行時動作がすべて正しく反映されるように、デプロイメント記述子の編集が必要な場合もある。 Bean が使用するオプションの機能を指定するマークアップがソース全体に記述され、EJBGen を使用してデプロイメント記述子を自動的に生成する場合、デプロイメント記述子の編集は最小限にする必要がある。	ejb-jar.xml weblogic-ejb-jar.xml (WebLogic Server 固有の機能を制御する要素が格納される) weblogic-cmp-jar.xml (Bean がコンテナ管理による永続性エンティティ Bean である場合)
EJB ラッパー クラスとスタブおよびスケルトン ファイルを生成する	ホーム インタフェースやリモート インタフェースのクラスを含む、デプロイメント ユニットにアクセスするためのコンテナ クラスを生成する。	生成されたクラスはアーカイブまたはディレクトリに追加される。
パッケージ化する	コンパイル済みファイル、生成ファイル、およびデプロイメント記述子をデプロイメント用にパッケージ化する。 状況によっては、ファイルをアーカイブせずにディレクトリ形式で展開しておくことも可能。	アーカイブ (JAR または EAR)
デプロイする	選択したステージング モードに従って、アーカイブまたはアプリケーション ディレクトリの対象として目的の管理対象サーバまたは WebLogic Server クラスタを設定する。	Bean のデプロイメント設定は、config.xml の EJBComponent 要素に書き込まれる。

ソース ディレクトリを作成する

EJB をアセンブルするソース ディレクトリを作成します。

ソース ファイルと出力ファイルを並列ディレクトリ構造に分離する分割開発ディレクトリ構造をお勧めします。分割ディレクトリ構造を準備し、EJB をエンタープライズ アプリケーション アーカイブ (EAR) としてパッケージ化する方法については、『Oracle Fusion Middleware 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

EJB のクラスとインタフェースを作成する

必要なクラスは、開発する EJB のタイプによって異なります (「EJB の構成要素」を参照)。

クラス ファイルおよびインタフェース ファイルを開発するための生産性の高いツールが用意されています。EJBGen コマンドライン ユーティリティはクラス ファイルとインタフェース ファイルの作成プロセスを自動化するとともに、EJB のデプロイメント記述子ファイルも生成します。これらのツールの詳細と使い方については、「EJBGen リファレンス」を参照してください。

以降の節では、WebLogic Server 固有の EJB 機能を使用する上でのヒントとガイドラインを示します。

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 に対するクライアント アクセスをプログラミングするためのガイドラインを示します。

クライアントによる初期コンテキストの取得のプログラミング

ローカル クライアントは、次の抜粋のような 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 Fusion Middleware Oracle WebLogic Server JNDI プログラマーズ ガイド』を参照してください。

EJB リンクの使用

EJB リンクの使用は Oracle のベスト プラクティスであり、WebLogic Server は EJB 2.1 仕様で定義されている EJB リンクを完全にサポートしています。アプリケーション コンポーネント内で EJB 参照を宣言し、これを同じ J2EE アプリケーション内で宣言されたエンタープライズ Bean にリンクさせることができます。

ejb-jar.xml ファイルで、参照元アプリケーション コンポーネントの ejb-ref 要素の ejb-link 要素を使用して EJB へのリンクを指定します。ejb-link の値は、参照先 EJB の ejb-jar.xml と weblogic-ejb-jar.xml 両方の ejb-name の値と同じでなければなりません。参照先の EJB は、参照元アプリケーション コンポーネントと同じ J2EE アプリケーションの EJB JAR ファイルのどれかに含まれていると考えられます。

ejb-name は EJB JAR ファイル間で必ずしもユニークでなくてもよいため、そのリンクの絶対パスを与える必要があるかもしれません。次の構文を使って、同じ J2EE アプリケーション内の 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 要素を使用して指定します。

URL による HTTP リソースの指定

EJB が要求を送信する URL を指定するには、次の手順に従います。

1. ejb-jar.xml の resource-ref 要素の <jndi-name> 要素で URL を指定します。

2. 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 にバインドします。

JNDI 名による HTTP リソースの指定

URL を指定する代わりに、JNDI でバインドされ、URL に対応するオブジェクトを指定するには、次のようにします。

1. ejb-jar.xml の resource-ref 要素の <jndi-name> 要素で、URL が JNDI でバインドされている名前を指定します。

2. 次のように、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 をバインドします。

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 に割り当てることによって設定できます。WebLogic Server のネットワーク チャネルとそれに関連するコンフィグレーション手順については、『Oracle Fusion Middleware 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 コンテナは、システム例外に基づくエラーが原因で失敗したトランザクションは再試行しません。

コンテナ管理によるトランザクションの自動的な再試行をコンフィグレーションするには、次の手順に従います。

1. 使用する Bean がコンテナ管理によるセッション Bean またはエンティティ Bean であることを確認します。

   コンテナ管理によるセッション Bean およびエンティティ Bean の場合にのみ、コンテナ管理によるトランザクションの自動再試行をコンフィグレーションできます。メッセージ駆動型 Bean の場合は、コンテナ管理によるトランザクションの自動再試行をコンフィグレーションできません。MDB は、メッセージの受信を含むトランザクションがロールバックされたときに、そのメッセージの受信の確認応答を行わないため、メッセージは確認応答が行われるまで自動的に再試行されます。また、タイマー Bean の場合も、コンテナ管理によるトランザクションの自動再試行はコンフィグレーションできません。タイマー Bean の ejbTimeout メソッドが開始されてロールバックされると、タイムアウトが常に再試行されるからです。

2. トランザクションの自動再試行をコンフィグレーションする場合、対象となるビジネス メソッドは、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 のドキュメント。

3. トランザクションの自動再試行を有効にする場合、対象となるメソッドは再呼び出しできなければなりません。失敗したメソッドの再試行によって得られる結果は、直前の再試行が成功した場合に得られる結果と同じでなければなりません。特に、以下の場合です。

   • メソッドの呼び出しによって呼び出しチェーンが開始された場合、そのメソッドを再試行するときは呼び出しチェーン全体を再呼び出しするのが安全です。

   • メソッドのすべてのパラメータを再利用できなければなりません。メソッドが再試行される場合、そのメソッドは失敗したメソッドを呼び出すために使用されたパラメータで再試行されます。一般に、再利用できるパラメータは、プリミティブ、不変オブジェクト、または読み込み専用オブジェクトの参照です。パラメータがメソッドによって変更されるオブジェクトの参照である場合、メソッドの再呼び出しによってメソッド呼び出しの結果に悪影響が生じてはなりません。

   • 再試行されるメソッドを保持する Bean がステートフル セッション Bean である場合、その Bean の対話状態は再呼び出し時に失われてはなりません。ステートフル セッション Bean の状態はトランザクション対応ではなく、トランザクションのロールバック中に復元できないので、トランザクションの自動再試行の機能を使用する場合、Bean の状態がロールバック後も有効であることを確認しておく必要があります。

4. EJB コンテナがどのメソッドのトランザクションを自動的に再試行するか、およびその回数は、weblogic-ejb-jar.xml の retry-methods-on-rollback 要素で指定します。

   retry-methods-on-rollback の retry-count 下位要素は、Administration Console からも変更できます。

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 を参照してください。

コード リスト 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");
// ユーザ トランザクションを開始する
    tx.begin();
//トランザクション アイソレーション レベルを TransactionReadCommitted に設定する
Transaction tx = TxHelper.getTransaction();
    tx.setProperty (TxConstants.ISOLATION_LEVEL, new Integer
    (Connection.TransactionReadCommitted));
//トランザクションの処理を実行する 
    tx.commit();

• 制限されたメソッドの回避 - Bean 管理によるトランザクションでは、EJBContext インタフェースの getRollbackOnly メソッドと setRollbackOnly メソッドは呼び出さないでください。これらのメソッドは、コンテナ管理によるトランザクションのみで使用します。Bean 管理によるトランザクションでは、UserTransaction インタフェースの getStatus メソッドと rollback メソッドを呼び出します。

• アクティブなトランザクション コンテキストにつき 1 つの接続の使用 - アクティブなトランザクション コンテキストに関連付けることができるのは、1 つのデータベース接続だけです。

複数の 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 を呼び出して銀行振替などのアクションを実行し、ラッパーは新しいトランザクションを開始して、トランザクションの処理を実行する 1 つまたは複数の EJB を呼び出します。

ラッパー EJB は、他の EJB を呼び出す前にトランザクション コンテキストを明示的に取得できます。あるいは、ejb-jar.xml でラッパーの trans-attribute 要素が Required または RequiresNew に設定されている場合、WebLogic Server は新しいトランザクション コンテキストを自動的に作成できます。

ラッパー EJB によって呼び出されるすべての EJB は、そのラッパー EJB のトランザクション コンテキストをサポートしている必要があります。つまり、その trans-attribute 要素が Required、Supports、または Mandatory に設定されていなければなりません。

EJB タイマー サービスのプログラミング

このリリースの WebLogic Server は、EJB 2.1 仕様で定義されている EJB タイマー サービスをサポートしています。EJB タイマー サービスは EJB コンテナによって提供されるサービスです。このサービスを使用すると、タイマー オブジェクトが期限切れになったときに発生するコールバックをスケジューリングするタイマーを作成できます。タイマー オブジェクトは、エンティティ Bean、メッセージ駆動型 Bean、およびステートレス セッション Bean 用に作成できます。タイマー オブジェクトは、指定した時間、指定した期間の経過後、または指定した間隔で期限切れになります。たとえば、タイマー サービスを使用して、EJB が一定期間にわたって特定の状態のままであるときに通知を送信できます。

WebLogic EJB タイマー サービスは、大まかなタイマー サービスとして使用するように設計されています。大量のタイマー オブジェクトを使用してデータ セットに対して同じタスクを実行するより、少数のタイマーを使用して大量のタスクを実行することをお勧めします。たとえば、従業員の経費レポートを表す EJB があるとします。各経費レポートは、マネージャの承認を受けてから処理されなければなりません。この場合、1 つの EJB タイマーを使用してすべての未決の経費レポートを定期的に検査し、担当のマネージャに対して、承認待ちのレポートを決裁するように促す電子メールを送信できます。

クラスタ化された EJB タイマー サービスとローカル EJB タイマー サービス

EJB タイマー サービスは、2 つのタイプ (クラスタまたはローカル) をコンフィグレーションすることができます。

クラスタ化された EJB タイマー サービス

クラスタ化された EJB タイマー サービスには、次の利点があります。

• 可視性に優れている。

  クラスタ内のすべてのノードからタイマーにアクセスできます。たとえば、javax.ejb.TimerService.getTimers() メソッドを使用すると、EJB に対して作成されたクラスタに含まれるすべてのステートレス セッション Bean タイマーまたはメッセージ駆動型 Bean タイマーの完全なリストが返されます。エンティティ Bean の主キーを getTimers() メソッドに渡すと、そのエンティティ Bean のタイマーのリストが返されます。

• 自動ロード バランシングおよびフェイルオーバ

  クラスタ化された EJB タイマー サービスは、ジョブ スケジューラのロード バランシング機能とフェイルオーバ機能を利用できます。

クラスタ化された EJB タイマー サービスのコンフィグレーションについては、「クラスタ化された EJB タイマーのコンフィグレーション」を参照してください。

ローカル EJB タイマー サービス

ローカル EJB タイマー サービスは、ローカル EJB タイマー サービスが作成されたサーバ上でのみ実行され、そのサーバ上の Bean にしか認識されません。ローカル EJB タイマー サービスを使用する場合、クラスタ化された EJB タイマー サービスとは異なり、クラスタ、データベース、JDBC データソース、またはリース サービスをコンフィグレーションする必要はありません。

ローカル EJB タイマー オブジェクトは、別のサーバに移行できません。タイマー オブジェクトは、サーバ全体の一部としてのみ移行できます。EJB タイマーが存在するサーバが何らかの理由でダウンした場合、サーバを再起動するか、またはサーバ全体を移行しなければタイマーを実行できません。

Java プログラミング インタフェースを使用してタイマー オブジェクトをプログラミングする

この節では、EJB 2.1 仕様に定義されている、タイマーのプログラミングに使用できる Java プログラミング インタフェースについて説明します。これらのインタフェースの詳細については、EJB 2.1 仕様を参照してください。また、この節では、WebLogic Server 固有のタイマー関連インタフェースについて詳しく説明します。

EJB 2.1 タイマー関連プログラミング インタフェース

次の表に、タイマーのプログラミングに使用できる EJB 2.1 インタフェースを示します。

表 4-2 EJB 2.1 タイマー関連プログラミング インタフェース

プログラミング インタフェース	説明
javax.ejb.TimedObject	タイマー コールバックのためにタイマー サービスに登録される Bean のエンタープライズ Bean クラスによって実装される。このインタフェースは、単一のメソッド、ejbTimeout を備えている。
EJBContext	getTimerService メソッドを使用してタイマー サービスにアクセスする。
javax.ejb.TimerService	EJB の新しい EJB タイマーを作成するか、既存の EJB タイマーにアクセスする。
javax.ejb.Timer	特定の EJB タイマーに関する情報にアクセスする。
javax.ejb.TimerHandle	永続化できるシリアライズ可能なタイマー ハンドルを定義する。タイマーはローカル オブジェクトなので、TimerHandle は Bean のリモート インタフェースまたは Web サービス インタフェースを介して渡してはならない。

EJB 2.1 のタイマー関連プログラミング インタフェースの詳細については、EJB 2.1 仕様を参照してください。

WebLogic Server 固有のタイマー関連インタフェース

タイマーのプログラミングに使用できる 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(); // 行われた正常なタイムアウト通知の合計数を取得する
  public int getActiveTimerCount(); // この EJBHome のアクティブなタイマーの数を示す
  public int getCancelledTimerCount(); この EJBHome のキャンセルされたタイマーの数を示す
  public int getDisabledTimerCount(); // この EJBHome の一時的に無効化されたタイマーの数を示す
  public void activateDisabledTimers(); // 一時的に無効化されているタイマーをアクティブにする
}

• weblogic.ejb.WLTimerService インタフェース。javax.ejb.TimerService インタフェースの拡張です。このインタフェースを使用すると、タイマーに関する WebLogic Server 固有のコンフィグレーション情報を指定できます。コード リスト 4-5 に weblogic.ejb.WLTimerService インタフェースを示します。javax.ejb.TimerService の詳細については、EJB 2.1 仕様を参照してください。

  
  

  注意 : weblogic.ejb.WLTimerService インタフェースは、クラスタ化された EJB タイマー サービスではサポートされません (「クラスタ化された EJB タイマーのコンフィグレーション」を参照)。

  
  

コード リスト 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 インタフェースを示します。

  
  

  注意 : weblogic.ejb.WLTimerService インタフェースは、クラスタ化された EJB タイマー サービスではサポートされません (「クラスタ化された EJB タイマーのコンフィグレーション」を参照)。

  
  

コード リスト 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;
  /**
   * このタイマーの実行される再試行の最大数を
   * 設定する。すべての再試行が
   * 失敗した場合、タイムアウト エラー アクションが
   * 実行される   */
  public void setMaxRetryAttempts(int retries);
  public int getMaxRetryAttempts();
  /**
   * 再試行が行われるまでの
   * 経過秒数を設定する
   */
  public void setRetryDelay(long millis);
  public long getRetryDelay();
  /**
   * このタイマーのタイムアウトの最大数を
   * 設定する。指定した回数のタイムアウトが
   * 正常に行われた場合、タイマーは
   * 削除される   */
  public void setMaxTimeouts(int max);
  public int getMaxTimeouts();
/**
   * ejbTimeout とすべての再試行が失敗した場合にコンテナが実行する
   * アクションを設定する。このインタフェースの REMOVE_TIMER_ACTION、
   * DISABLE_TIMER_ACTION、および SKIP_TIMEOUT_ACTION フィールドによって
   * 有効な値が定義される
   */
  public void setTimeoutFailureAction(int action);
  public int getTimeoutFailureAction();
}

• weblogic.ejb.WLTimer インタフェース。javax.ejb.Timer インタフェースの拡張であり、タイマーの現在の状態に関する追加情報を提供します。コード リスト 4-7 に weblogic.ejb.WLTimer インタフェースを示します。

  
  

  注意 : weblogic.ejb.WLTimerService インタフェースは、クラスタ化された EJB タイマー サービスではサポートされません (「クラスタ化された EJB タイマーのコンフィグレーション」を参照)。

  
  

コード リスト 4-7 weblogic.ejb.WLTimer インタフェース

public interface WLTimer extends Timer {
  public int getRetryAttemptCount();
  public int getMaximumRetryAttempts();
  public int getCompletedTimeoutCount();
}

タイマー デプロイメント記述子

タイマーに関連するデプロイメント記述子の要素は以下のとおりです。

表 4-3 タイマー デプロイメント記述子

要素	説明
timer-descriptor	EJB タイマー オブジェクト。
timer-implementation	EJB タイマー サービスのクラスタ化の有無。クラスタ化された EJB タイマー サービスについては、「クラスタ化された EJB タイマーのコンフィグレーション」を参照。
persistent-store-logical-name	WebLogic Server がタイマー オブジェクトを格納する、サーバのファイル システム上の永続ストアの名前。

これらの要素の詳細については、「weblogic-ejb-jar.xml デプロイメント記述子のリファレンス」を参照してください。

クラスタ化された EJB タイマーのコンフィグレーション

注意 : クラスタ化された EJB タイマーの利点については、「クラスタ化された EJB タイマー サービスとローカル EJB タイマー サービス」を参照してください。

EJB タイマーのクラスタ化をコンフィグレーションするには、次の手順に従います。

1. 以下についてコンフィグレーションしたかどうかを確認します。

   • クラスタ化されたドメイン。詳細については、『Oracle Fusion Middleware 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 Fusion Middleware Oracle WebLogic Server Timer and Work Manager API (CommonJ) プログラマーズ ガイド』を参照してください。

2. クラスタ化された EJB タイマー サービスを有効にするために、weblogic-ejb-jar.xml デプロイメント記述子の timer-implementation 要素を Clustered に設定します。詳細については、「timer-implementation」を参照してください。

クラスタ化された EJB タイマー サービスでは、以下のように動作が変更されることに注意してください。

• weblogic.ejb.WLTimer* インタフェースは、クラスタ化された EJB タイマー サービスではサポートされない。

• createTimer() メソッドを使用してクラスタ化された EJB タイマーを新しく作成する場合、タイマーの初期セットアップ時にタイムアウトの実行が遅延する場合がある。

• ジョブ スケジューラでは、「少なくとも 1 回」の実行が保証される。クラスタ化された EJB タイマーが期限切れになった場合、データベースはリスナ コールバック メソッドが完了するまで更新されません。データベースが更新される前にサーバがクラッシュした場合、タイマーはもう一度実行されます。

• クラスタ化された EJB タイマー サービスでは、障害が発生した場合に実行するアクションに関するタイマーのコンフィグレーション オプションは使用できない。これらのコンフィグレーション オプションには、再試行の遅延、再試行の最大数、タイムアウトの最大数、およびタイムアウト エラー アクションがあります。

• ジョブ スケジューラは、期限切れになるタイマーを識別するために 30 秒ごとにデータベースに対してクエリを実行する。30 秒未満の間隔でタイマーの実行が遅延する場合があります。

• 障害が発生した場合、トランザクション対応のタイマーのみ再試行される。

• タイマー実行の固定間隔スケジューリングはサポートされない。

Web サービスの参照の宣言

このリリースの WebLogic Server は、外部の Web サービスの宣言およびアクセスに関する EJB 2.1 の要件を満たしています。Web サービスの参照を EJB のデプロイメント記述子で宣言することによって、Web サービスの論理名が実際の Web サービス インタフェースにマップされます。これにより、論理名を使用して Web サービスを参照できるようになります。さらに、Bean コードは Web サービスの参照名を使用して JNDI ルックアップを実行します。

詳細については、『Oracle Fusion Middleware Oracle WebLogic Server JAX-WS を使用した Web サービス入門』を参照してください。

Java ソースをコンパイルする

コンパイル プロセスをサポートしているツールを確認するには、表 4-1 を参照してください。

コンパイル プロセスについては、『Oracle Fusion Middleware Oracle WebLogic Server アプリケーションの開発』を参照してください。

デプロイメント記述子を生成する

Bean のクラス ファイルに JDK 1.5 のアノテーションを追加すると、EJBGen を使用して EJB アプリケーションのリモート クラス、ホーム クラス、およびデプロイメント記述子ファイルを生成できます。

デプロイメント記述子の生成には、EJBGen を使用することをお勧めします。詳細については、「EJBGen リファレンス」を参照してください。

デプロイメント記述子を編集する

ejb-jar.xml、weblogic-ejb-jar.xml、および weblogic-cmp-jar.xml (コンテナ管理による永続性エンティティ Bean の場合) の要素は、アプリケーションの実行時の特性を制御します。

記述子要素を修正する必要がある場合は、任意のテキスト エディタを使用して記述子ファイルを編集できます。ただし、エラーを防止するために、XML 編集用に設計されたツールを使用してください。WebLogic Server Administration Console で編集できる記述子要素については、表 4-1 を参照してください。

以下の節では、WebLogic Server 固有のデプロイメント要素を簡単に参照できます。各節では、特定のタイプの機能または動作に関連する要素が取り上げられています。各節の表では、制御する動作、関連する Bean タイプ (Bean タイプ固有の場合)、その要素が含まれる weblogic-ejb-jar.xml の親要素、および weblogic-ejb-jar.xml で明示的に指定しない場合に予想される動作に基づいて関連要素が定義されています。

• セキュリティ要素

• リソース マッピング要素

• 永続性要素

• クラスタ化要素

• データの一貫性要素

• コンテナ管理によるトランザクション要素

• パフォーマンス要素

• ネットワーク通信要素

各記述子ファイルの要素、定義、および使用例の包括的なドキュメントについては、以下を参照してください。

• weblogic-ejb-jar.xml デプロイメント記述子のリファレンス

• weblogic-cmp-jar.xml デプロイメント記述子のリファレンス

• ejb-jar.xml の要素に関する Sun のドキュメント

  
  

  注意 : 以降の節では、「要素」カラムの要素名をクリックすると、その要素の詳しい説明が表示されます。

  
  

セキュリティ要素

この表は、セキュリティに関連する weblogic-ejb-jar.xml の要素を示しています。

表 4-4 weblogic-ejb-jar.xml のセキュリティ要素

要素	説明	デフォルト値
security-role-assignment	ejb-jar.xml ファイルのセキュリティ ロールを WebLogic Server のセキュリティ プリンシパルの名前にマッピングする。 ejb-jar.xml がアプリケーション ロールを定義する場合に必須。	なし
security-permission	この EJB に付与される追加の Java セキュリティ パーミッション。	なし
run-as-principal-name	ejb-jar.xml で security-identity run-as-role-name を指定した Bean の run-as プリンシパルとして使用されるセキュリティ プリンシパル名。	なし
iiop-security-descriptor	RMI-IIOP プロトコルを使用する Bean のセキュリティ オプション。	なし

リソース マッピング要素

この表は、ソース コードで使用される Bean またはリソースの名前をデプロイメント環境の JNDI 名にマッピングする weblogic-ejb-jar.xml の要素を示しています。

表 4-5 weblogic-ejb-jar.xml のリソース マッピング要素

要素	Bean タイプ	説明	デフォルト値
jndi-name	すべて	WebLogic Server のリソースまたは参照の JNDI 名。 注意 : JNDI 名を Bean に割り当てるのは推奨されない。グローバル JNDI 名は、クラスタ化されたサーバの起動時に大量のマルチキャスト トラフィックを引き起こす。より適切なプラクティスについては、「EJB リンクの使用」を参照。	なし
local-jndi-name	すべて	Bean のローカル ホームの JNDI 名。Bean がリモート ホームとローカル ホームを持つ場合は、それぞれのホームに 1 つずつの JNDI 名を指定する必要がある。	なし
concurrency-strategy	MDB	キューおよびトピックの作成に Bean が使用する JMS 接続ファクトリの JNDI 名。	weblogic.jms.Message.DrivenBeanConnectionFactory
destination-jndi-name	MDB	JNDI ツリーでメッセージ駆動型 Bean とキューまたはトピックを関連付ける JNDI 名。	なし
initial-context-factory	MDB	接続ファクトリの作成に EJB コンテナが使用する初期コンテキスト ファクトリ。	weblogic.jndi.WLInitial.Context.Factory
jms-client-id	MDB	恒久サブスクライバ トピックと関連付けられたメッセージ駆動型 Bean のクライアント ID。	ejb-name の値
message-destination-descriptor	MDB	ejb-jar.xml ファイル内のメッセージ送り先の参照を、WebLogic Server の実際のメッセージ送り先 (JMS キュー、トピックなど) にマップする。	なし
provider-url	MDB	InitialContext で使用される URL プロバイダを指定する。	t3://localhost:7001

永続性要素

この表は、Bean の状態がどのように保持されるのかを指定する weblogic-ejb-jar.xml の要素を示しています。

表 4-6 weblogic-ejb-jar.xml の永続性要素

要素	Bean タイプ	説明	デフォルト値
type-identifier	エンティティ	EJB の永続性タイプを指定する。WebLogic Server RDBMS ベースの永続性では、WebLogic_CMP_RDBMS という識別子を使用する。	なし
type-storage	エンティティ	この永続性タイプのデータを格納するファイルのパスを、EJB のデプロイメント JAR ファイルまたはデプロイメント ディレクトリの最上位を基準にして定義する。 WebLogic Server RDBMS ベースの永続性では通常、Bean の永続性データを格納するのに weblogic-cmp-jar.xml という XML ファイルを使用する。このファイルは、JAR ファイルの META-INF サブディレクトリにある。	なし
type-version	エンティティ	type-identifier で指定された永続性タイプのバージョン。WebLogic 2.0 CMP の永続性の場合は、値 2.0 を使用する。 WebLogic 1.1 CMP の永続性の場合は、値 1.1 を使用する。	なし
delay-updates-until-end-of-tx	エンティティ	true の場合、EJB コンテナはトランザクションが終わるまで Bean の状態の更新をデータベースに書き込むのを遅らせようとする。ただしコンテナは、クエリの include-updates 要素 (weblogic-cmp-jar.xml の weblogic-query 要素) が true の場合は EJB ファインダまたは select クエリを実行する前にデータベースに更新をフラッシュする。 コンテナ管理による永続性 Bean と Bean 管理による永続性 Bean の両方に適用可能。	True
finders-load-bean	エンティティ	finder または ejbSelect メソッドで返された Bean がメソッドの復帰前に直ちにキャッシュにロードされるようにする。 注意 : コンテナ管理による永続性 Bean でのみ適用可能。	True
persistent-store-dir	ステートフル セッション	パッシベーションされたステートフル セッション Bean のインスタンスの状態が格納されるディレクトリ。	pstore
is-modified-method-name	エンティティ	Bean が変更されていて、その変更をデータベースに書き込む必要があるかどうかを判断するためにコンテナから呼び出されるメソッド。 Bean 管理による永続性 Bean または EJB 1.1 コンテナ管理による永続性 Bean に適用される。	指定しないと、Bean の状態は各メソッドの完了後に保持されることになる。

クラスタ化要素

この表は、クラスタ化に関連する weblogic-ejb-jar.xml の要素を示しています。これらの要素は、WebLogic Server クラスタのクラスタ化された Bean のフェイルオーバおよびロード バランシング動作を制御します。

表 4-7 weblogic-ejb-jar.xml のクラスタ化要素

要素	Bean タイプ	説明	デフォルト値
home-call-router-class-name	ステートフル セッション ステートレス セッション エンティティ	ホーム メソッド呼び出しのルーティングに使用するカスタム クラス。このクラスは weblogic.rmi.extensions.CallRouter() を実装する必要がある。	なし
home-is-clusterable	ステートフル セッション ステートレス セッション エンティティ	Bean のホームがクラスタ化できるかどうかを示す。	True
home-load-algorithm	ステートフル セッション ステートレス セッション エンティティ	Bean ホームのレプリカ間でロード バランシングを行うためのアルゴリズム。	weblogic.cluster.defaultLoadAlgorithm の値
idempotent-methods	ステートレス セッション エンティティ	クラスタ化された EJB の多重呼び出し不変メソッド。多重呼び出し不変のメソッドは、ネガティブな副作用なしに繰り返すことができる。 ステートレス セッション Bean のホームおよび読み込み専用エンティティ Bean インスタンスのメソッドは、明示的に指定する必要はない。それらのメソッドは自動的に多重呼び出し不変として設定される。	なし
replication-type	ステートフル セッション	クラスタのステートフル セッション Bean に使用するレプリケーションを示す (in-memory または none)。	none
stateless-bean-call-router-class-name	ステートレス セッション	Bean メソッド呼び出しのルーティングに使用するカスタム クラス。	なし
stateless-bean-is-clusterable	ステートレス セッション	Bean がクラスタ化できるかどうかを示す。 ejb-jar.xml で session-type が Stateless になっているセッション Bean でのみ使用する。	True
stateless-bean-load-algorithm	ステートレス セッション	Bean のレプリカ間でロード バランシングを行うためのアルゴリズム。	weblogic.cluster.defaultLoadAlgorithm プロパティの値
use-serverside-stubs	ステートレス セッション	Bean ホームがサーバ コンテキストでサーバサイド スタブを使用するようにする。	False

データの一貫性要素

この表は、Bean インスタンスのデータとデータベースの一貫性に関連する weblogic-ejb-jar.xml の要素を示しています。これらの要素は、Bean インスタンスの値を反映して、いつどのようにデータベースが更新されるのかなどの動作を制御します。

注意 : コンテナ管理による永続性に関連する要素については、「エンティティ Bean のプールとキャッシュの管理」を参照してください。

表 4-8 weblogic-ejb-jar.xml のデータ一貫性要素

要素	Bean タイプ	説明	デフォルト値
concurrency-strategy	エンティティ	エンティティ Bean への同時アクセスがどのように管理されるのか。	データベース
invalidation-target	エンティティ	このコンテナ管理による永続性エンティティ Bean が変更されたときに無効化する読み込み専用エンティティ Bean。 注意 : EJB 2.x CMP Bean にのみ適用できる。	なし
delay-updates-until-end-of-tx	エンティティ	true の場合、EJB コンテナはトランザクションが終わるまで Bean の状態の更新をデータベースに書き込むのを遅らせようとする。ただしコンテナは、クエリの include-updates 要素 (weblogic-cmp-jar.xml の weblogic-query 要素) が true の場合は EJB ファインダまたは select クエリを実行する前にデータベースに更新をフラッシュする。 コンテナ管理による永続性 Bean と Bean 管理による永続性 Bean の両方に適用可能。	True

コンテナ管理によるトランザクション要素

表 4-9 は、コンテナ管理によるトランザクションに関連する ejb-jar.xml の要素を示しています。

表 4-9 ejb-jar.xml のコンテナ管理によるトランザクション要素

要素	説明	デフォルト値
transaction-type	値は Bean または Container のいずれか。	なし。EJB 2.x ではこの属性の指定は必須となっている。
trans-attribute	メソッドの呼び出しをエンタープライズ Bean のビジネス メソッドに委託するときにコンテナがトランザクションの境界をどのように管理するのかを指定する。有効な値は以下のとおり。 NotSupported 値が NotSupported の場合、エンティティ Bean が指定されていないトランザクションで実行されており、トランザクションが存在するとき、EJB コンテナはトランザクションを中断する。エンティティ Bean が指定されていないトランザクションで実行され、トランザクションが存在しない場合、EJB コンテナはアクションを実行しない。 Supports 値が Supports の場合、エンティティ Bean が指定されていないトランザクションで実行されており、トランザクションが存在するとき、EJB コンテナは現在のトランザクションを使用する。エンティティ Bean が指定されていないトランザクションで実行され、トランザクションが存在しない場合、EJB コンテナはアクションを実行しない。 Required RequiresNew Mandatory Never 値が Never の場合、エンティティ Bean が指定されていないトランザクションで実行されており、トランザクションが存在するとき、EJB コンテナは例外を送出する。エンティティ Bean が指定されていないトランザクションで実行され、トランザクションが存在しない場合、EJB コンテナはアクションを実行しない。 注意 : 9.0 より前のリリースの WebLogic Server では、EJB コンテナは、トランザクションが存在せず、trans-attribute の値が NotSupported、Supports、および Never の場合、新しいトランザクションを開始した。EJB コンテナを 9.0 より前のリリースの WebLogic Server と同じように動作させて新しいトランザクションを作成する場合は、weblogic-ejb-jar.xml の entity-always-uses-transaction を True に設定する。 クライアントは MDB の呼び出しでトランザクション コンテキストを提供しないので、コンテナ管理によるトランザクションを使用する MDB では trans-attribute が Required でなければならない。	指定しないと、EJB コンテナは警告を発し、MDB では NotSupported、それ以外の EJB では Supports を使用する。
transaction-scope	この省略可能な要素は、エンタープライズ Bean がそのメソッドで分散トランザクションを必須とするかどうか、またはローカル トランザクションの最適化を使用できるかどうかを指定する。 値は Local と Distributed のいずれか。	指定しない場合、コンテナは分散トランザクションが使用されなければならないものと想定する。

表 4-10 は、コンテナ管理によるトランザクションに関連する weblogic-ejb-jar.xml の要素を示しています。

表 4-10 weblogic-ejb-jar.xml のコンテナ管理によるトランザクション要素

要素	説明	デフォルト値
retry-methods-on-rollback	ここで指定したメソッドに対して、EJB コンテナはロールバックされたコンテナ管理によるトランザクションを自動的に再試行する。 注意 : この要素で指定されたメソッドに関わらず、EJB コンテナは、システム例外に基づくエラーが原因で失敗したトランザクションは再試行しない。	なし
transaction-isolation	メソッドがトランザクションを開始するときに使用するトランザクション アイソレーション レベル。指定されたトランザクション レベルは、メソッドが既存のトランザクションを継承する場合は使用されない。	基底の DBMS のデフォルト
trans-timeout-seconds	トランザクションの最長継続時間。	なし

パフォーマンス要素

この表は、パフォーマンスに関連する weblogic-ejb-jar.xml の要素を示しています。

表 4-11 weblogic-ejb-jar.xml のパフォーマンス要素

要素	Bean タイプ	説明	デフォルト値
allow-concurrent-calls	ステートフル セッション	Remote Exception が送出されることなく、複数のクライアントが Bean に同時にアクセスできるかどうか。 ステートフル セッション Bean インスタンスによるメソッド呼び出しの処理中に、同時に他のメソッド呼び出しがサーバに送信されたときに、サーバは RemoteException を送出する。	False
cache-between-transactions	エンティティ	コンテナがトランザクション間でエンティティ Bean の永続データをキャッシュするようにする。	False
cache-type	ステートフル セッション	ステートフル セッション Bean がキャッシュから削除される順序。	NRU (最近未使用)
clients-on-same-server	すべて	Bean のすべてのクライアントが同じサーバ インスタンス上でその Bean と連結されていることを示す。この要素は、EJB にグローバル JNDI 名がある場合のみ使用する。true に設定すると、JNDI 名がレプリケートされない。 値を true にすると、大規模なクラスタで開始時間を短縮できる。	False
delay-updates-until-end-of-tx	エンティティ	true の場合、EJB コンテナはトランザクションが終わるまで Bean の状態の更新をデータベースに書き込むのを遅らせようとする。 ただしコンテナは、クエリの include-updates 要素 (weblogic-cmp-jar.xml の weblogic-query 要素) が true の場合は EJB ファインダまたは select クエリを実行する前にデータベースに更新をフラッシュする。 コンテナ管理による永続性 Bean と Bean 管理による永続性 Bean の両方に適用可能。	True
dispatch-policy	すべて	Bean への要求を処理するために使用するスレッド プールを指定する。	なし
ejb-local-reference-description	すべて	パラメータの参照渡しを可能にして、同じアプリケーション内で呼び出されるメソッドのメソッド呼び出しのパフォーマンスを向上させる。 注意 : メソッドのパラメータは、EJB がリモートで呼び出されたときには常に値で渡される。	False
entity-cache-name	エンティティ	アプリケーション レベルのエンティティ キャッシュ。同じアプリケーションに属する複数のエンティティ Bean のインスタンスをキャッシュできる。 注意 : アプリケーション レベルのキャッシュは weblogic-application.xml で宣言する。	なし
estimated-bean-size	エンティティ	エンティティ Bean のインスタンスの推定平均サイズ (バイト単位)。	なし
finders-load-bean	エンティティ	finder または ejbSelect メソッドで返された Bean がメソッドの復帰前に直ちにキャッシュにロードされるようにする。 注意 : コンテナ管理による永続性 Bean でのみ適用可能。	True
idle-timeout-seconds	エンティティ	Bean がパッシベーションされるまでの活動のない状態の秒数。 注意 : この要素は現在は使われていない。	600
idle-timeout-seconds	ステートフル セッション	Bean がパッシベーションされるまでの活動のない状態の秒数。	600
initial-beans-in-free-pool	エンティティ メッセージ駆動型 ステートレス セッション	起動時にコンテナによってインスタンス化される EJB のインスタンスの数。	0
is-modified-method-name	エンティティ	Bean の状態を変更するメソッド。このメソッドを指定すると、WebLogic server はメソッドの完了時に Bean の状態を保持する。 注意 : Bean 管理による永続性 Bean または EJB 1.1 コンテナ管理による永続性 Bean に適用される。	指定しないと、Bean の状態は各メソッドの完了後に保持されることになる。
jms-polling-interval-seconds	メッセージ駆動型	アクセスできなくなっている JMS 送り先に EJB コンテナが再接続しようとする試みの秒間隔。	10
max-beans-in-cache	エンティティ ステートフル セッション	キャッシュ内のインスタンスの最大数。	1000
max-beans-in-free-pool	エンティティ ステートレス セッション メッセージ駆動型	フリー プールのインスタンスの最大数。	1000
read-timeout-seconds	エンティティ	読み込み専用エンティティ Bean で ejbLoad を呼び出す間隔の秒数。read-timeout-seconds が 0 の場合、ejbLoad は Bean がキャッシュされた場合のみ呼び出される。	600

ネットワーク通信要素

この表は、ネットワーク通信に関連する weblogic-ejb-jar.xml の要素を示しています。

表 4-12 weblogic-ejb-jar.xml のネットワーク通信要素

要素	Bean タイプ	説明	デフォルト値
network-access-point	すべて	EJB にカスタム ネットワーク チャネルを割り当てる。	なし

EJB ラッパー クラスとスタブおよびスケルトン ファイルを生成する

コンテナ クラスには、WebLogic Server が使用する EJB の内部表現に加えて、クライアントが使用する外部インタフェース (ホーム、ローカル、またはリモート) の実装も格納されます。コンテナ クラスを生成するには、Oracle Workshop for WebLogic Platform または appc を使用します。

コンテナ クラスは、weblogic-ejb-jar.xml の記述子要素に従って生成されます。たとえば、クラスタ化要素を指定すると、appc はデプロイメントで使用されるクラスタ対応クラスを作成します。appc は、必要なオプションと引数を指定することでコマンドラインから直接使用できます。詳細については、「appc」を参照してください。

次の図は、EAR または JAR ファイルの作成時にデプロイメント ユニットに追加されるコンテナ クラスを示しています。

図 4-2 EJB コンテナ クラスの生成

「図 4-2 EJB コンテナ クラスの生成」の説明

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 は、エンタープライズ アプリケーションの一部としてパッケージ化することをお勧めします。詳細については、『Oracle Fusion Middleware 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 Fusion Middleware Oracle WebLogic Server アプリケーションのデプロイメント』を参照してください。EJB 固有のデプロイメントの問題と手続きについては、この『Oracle Fusion Middleware Oracle WebLogic Server エンタープライズ JavaBeans (EJB) プログラマーズ ガイド』の「エンタープライズ JavaBean のデプロイメント ガイドライン」を参照してください。

開発時に問題を解決する

以降の節では、デプロイした EJB のチェックとデバッグに便利な WebLogic Server の機能を説明します。

行番号をクラス ファイルに追加する

appc で EJB をコンパイルする場合は、appc -lineNumbers コマンド オプションを使用して、デバッグしやすいように生成したクラス ファイルに行番号を追加できます。詳細については、「appc リファレンス」を参照してください。

データをモニタする

WebLogic Server は、デプロイされた EJB の実行時の処理についてさまざまなデータを収集します。Administration Console の [デプロイメント] ノードで表示できるこのデータは、EJB が目的の処理を完了しているかどうかを判断する上で便利です。EJB の実行時の統計を表示するには、Administration Console で [デプロイメント] ノードを展開し、その Bean が含まれている JAR EAR を見つけて [モニタ] タブを選択します。

参照できるデータについては、Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプにある以下のトピックを参照してください。

• 「デプロイメント : モニタ : EJB : ステートフル」

• 「デプロイメント : モニタ : EJB :ステートレス」

• 「デプロイメント : モニタ : EJB : メッセージ駆動型」

• 「デプロイメント : モニタ : EJB : エンティティ」

デバッグ メッセージを作成する

デバッグ メッセージを作成する バグや問題のトラブルシューティングおよび解決に役立つメッセージをアプリケーションで作成する手順については、『Oracle Fusion Middleware Oracle WebLogic Server ログ ファイルのコンフィグレーションとログ メッセージのフィルタ処理』を参照してください。

EJB を開発するための WebLogic Server ツール

この節では、EJB 開発プロセスをサポートする Oracle のツールについて説明します。各ツールの機能の比較については、表 4-14 を参照してください。

Oracle JDeveloper

Oracle JDeveloper は、EJB のエンドツーエンドの開発に使用できるフル機能の Java IDE です。詳細については、Oracle JDeveloper のオンライン ヘルプを参照してください。JDeveloper のインストールについては、『Oracle Fusion Middleware Installation Guide for Oracle JDeveloper』を参照してください。

Oracle Enterprise Pack for Eclipse

Oracle Enteprise Eclipse (OEPE) — WebLogic Web サービスの開発を容易にする Eclipse IDE プラットフォームのプラグイン群を提供します。詳細については、Eclipse IDE プラットフォームのオンライン ヘルプを参照してください。

Administration Console

Administration Console では、多くのデプロイメント記述子要素について表示、修正、および EJB 内の記述子ファイルへの保持を行うことができます。記述子は、EJB の管理サーバ コピー、ならびに EJB のすべてのデプロイされたコピー (デプロイ後) において、修正されます。記述子を修正した場合、変更はユーザの EJB のオリジナル コピー (デプロイ前) に対して行われます。

ただし、これらの記述子要素の更新は、EJB を再デプロイする必要なしに、実行時に動的に行われます。Administration Console で変更できる記述子要素は、表 4-13 にまとめられているように、実行時に動的に変更できるものに限定されています。

表 4-13 Administration Console からアクセスできる記述子要素

EJB タイプ	編集可能な要素
エンティティ	max-beans-in-cache max-beans-in-free-pool key-cache-size trans-timeout-seconds read-timeout-seconds (読み込み専用エンティティ Bean のみ)
メッセージ駆動型	max-beans-in-free-pool message-selector (http://www.java.sun.com/dtd/ejb-jar_2_0.dtd を参照) jms-polling-interval-seconds trans-timeout-seconds
ステートレス	max-beans-in-free-pool trans-timeout-seconds
ステートフル	max-beans-in-free-pool idle-timeout-seconds trans-timeout-seconds

javac

Sun Java J2SE SDK に付属の javac コンパイラは、java コンパイル機能を提供します。javac については、http://java.sun.com/docs を参照してください。

EJBGen

EJBGen は、EJB 2.x のコード ジェネレータです。Bean クラス ファイルに javadoc タグでアノテーションを付けた後、EJBGen を使用して EJB アプリケーションのリモート インタフェース クラス、ホーム インタフェース クラス、および、デプロイメント記述子ファイルを生成することができるので、編集および管理すべき EJB ファイルの数を 1 つに減らせます。

デプロイメント記述子の生成には、EJBGen の使用をお勧めします。これは、EJB の維持を容易化および簡略化できる、Oracle のベスト プラクティスです。EJBGen を使用する場合、記述してアノテーションを付ける必要がある Bean クラスは 1 つだけです。そのため、記述、デバッグ、および維持が簡略化されます。開発環境として Oracle Workshop for WebLogic Platform を使用すると、EJBGen タグが自動挿入されます。

EJBGen の詳細については、「EJBGen リファレンス」を参照してください。

DDInit

DDInit は、WebLogic Server アプリケーションのデプロイメント記述子を生成するためのユーティリティです。DDInit では、クラス ファイルからの情報に基づいてデプロイメント記述子ファイルを作成します。

『Oracle Fusion Middleware Oracle WebLogic Server コマンド リファレンス』の「DDInit」を参照してください。

WebLogic Server Ant ユーティリティ

WebLogic Server には、スケルトン デプロイメント記述子を作成するための Ant ユーティリティが用意されています。

この Ant タスクでは、Web アプリケーションを含むディレクトリが検証され、そのディレクトリの内容に基づいてデプロイメント記述子が作成されます。Ant ユーティリティは、個別の EJB に必要なコンフィグレーションやマッピングに関する情報をすべて保持しているわけではないので、Ant ユーティリティによって作成されるスケルトン デプロイメント記述子は不完全なものです。Ant ユーティリティがスケルトン デプロイメント記述子を作成した後で、テキスト エディタや XML エディタを使ってデプロイメント記述子を編集し、EJB のコンフィグレーションを完全なものにしてください。

詳細については、『Oracle Fusion Middleware Oracle WebLogic Server アプリケーションの開発』の「wldeploy を使用したアプリケーションのデプロイメント」を参照してください。

weblogic.Deployer

weblogic.Deployer コマンドライン ツールは、WebLogic Server デプロイメント API にコマンドライン インタフェースを提供する、Java ベースの開発ツールです。このツールは、コマンドライン、シェル スクリプト、または Java 以外の自動化された環境からデプロイメントを開始する必要がある管理者および開発者向けに開発されました。

『Oracle Fusion Middleware Oracle WebLogic Server アプリケーションのデプロイメント』の「weblogic.Deployer コマンドライン リファレンス」を参照してください。

appc

appc コンパイラは、EJB および JSP を WebLogic Server にデプロイするのに必要なクラスを生成し、コンパイルします。appc は、個別のモジュール レベルとアプリケーション レベルの両方で、現在の仕様に準拠しているかどうかデプロイメント記述子を検証します。アプリケーション レベルのチェックでは、個別のモジュールに対するアプリケーション レベルのデプロイメント記述子のチェックと、モジュール全体の検証チェックが行われます。

注意 : appc は、非推奨の ejbc ユーティリティの後継ツールです。ejbc ではなく appc を使用することをお勧めします。

「appc リファレンス」を参照してください。

DDConverter

DDConverter は、WebLogic Server の旧リリースのデプロイメント記述子をアップグレードするコマンドライン ツールです。最新の J2EE 仕様と WebLogic Server リリースの機能を活用するために、常にデプロイメント記述子をアップグレードすることをお勧めします。

weblogic.DDConverter を使用すると、デプロイメント記述子をアップグレードできます。weblogic.DDConverter の使い方については、『Oracle Fusion Middleware 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	不可	可	不可	不可	不可
EJBGen	可	不可	可	可	不可
DDInit	不可	不可	可	不可	不可
Administration Console	不可	不可	不可	可	可
Deployer	不可	不可	不可	不可	可
DDConverter	不可	不可	可	不可	不可