|
|
以降の節では、EJB の実装プロセスを説明し、EJB を WebLogic Server で実行する方法についても説明します。
この章は、WebLogic Server の EJB の付加価値機能を理解し、アプリケーションの設計パターンをすでに選択しており、主要な設計上の決定をすでに行っている読者を対象としています。
WebLogic Server EJB の機能の概要については、「WebLogic Server の EJB の付加価値機能」を参照してください。
EJB の設計オプション、設計の過程で考慮する要素、および推奨の設計パターンについては、「エンタープライズ JavaBean の設計」を参照してください。
この節では、EJB 開発プロセスを簡単に説明します。主な実装タスクと関連する結果について説明します。
図 4-1 に、EJB の開発プロセスを示します。プロセスの手順、および各手順の結果については、表 4-1 を参照してください。以下の節では、各手順について詳しく説明します。
ソース ファイルと出力ファイルを並列ディレクトリ構造に分離する分割開発ディレクトリ構造をお勧めします。分割ディレクトリ構造を準備し、EJB をエンタープライズ アプリケーション アーカイブ (EAR) としてパッケージ化する方法については、『WebLogic Server アプリケーションの開発』の「分割開発ディレクトリ環境の概要」を参照してください。
EJB を JAR ファイルにパッケージ化してデプロイする場合は、クラス ファイルのディレクトリと、デプロイメント記述子ファイル用の META-INF というサブディレクトリを作成します。
myEJB/ META-INF/ ejb-jar.xml weblogic-ejb-jar.xml weblogic-cmp-jar.xml foo.class fooHome.class fooBean.class
必要なクラスは、開発する EJB のタイプによって異なります (表 2-1 を参照)。
クラス ファイルおよびインタフェース ファイルを開発するための生産性の高いツールが用意されています。EJBGen コマンドライン ユーティリティはクラス ファイルとインタフェース ファイルの作成プロセスを自動化するとともに、EJB のデプロイメント記述子ファイルも生成します。これらのツールの詳細と使い方については、「EJBGen リファレンス」を参照してください。
以降の節では、WebLogic Server 固有の EJB 機能を使用する上でのヒントとガイドラインを示します。
WebLogic Server では、各 EJB タイプについて、ほとんどの EJB で必要な Java コールバック (リスナ) が含まれる汎用クラスが提供されます。それらの汎用クラスは、weblogic.ejb パッケージにあります。
汎用 Bean テンプレートは、その汎用クラスを作成中のクラスにインポートすることで独自のクラスで実装できます。次の例では、GenericSessionBean クラスが HelloWorldEJB にインポートされます。
import weblogic.ejb.GenericSessionBean;
...
public class HelloWorldEJB extends GenericSessionBean {
以降の節では、EJB に対するクライアント アクセスをプログラミングするためのガイドラインを示します。
ローカル クライアントは、次の抜粋のような getInitialContext メソッドを使用して初期コンテキストを取得します。
...
Context ctx = getInitialContexLt("t3://localhost:7001", "user1", "user1Password");
...
static Context getInitialContext(String url, String user, String password) {
Properties h = new Properties();
h.put(Context.INITIAL_CONTEXT_FACTORY,
"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 リンクの使用は BEA のベスト プラクティスであり、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 ファイルからの相対パスです。
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 のネットワーク チャネルとそれに関連するコンフィグレーション手順については、『WebLogic Server 環境のコンフィグレーション』の「ネットワーク リソースのコンフィグレーション」を参照してください。カスタム チャネルをコンフィグレーションしたら、weblogic-ejb-jar.xml の network-access-point 要素を使用して EJB に割り当てます。
トランザクション設計上の決定事項については、「機能と設計パターン」を参照してください。以降の節では、トランザクション プログラミングのガイドラインを示します。
トランザクションをエンティティ Bean と使用することについては、「ejbLoad() と ejbStore() の動作について」を参照してください。
コンテナ管理によるトランザクションは、Bean 管理によるトランザクションよりもプログラミングが簡単です。その理由は、境界設定 (トランザクションの開始と停止) が EJB コンテナで行われるからです。
トランザクション動作は、ejb-jar.xml および weblogic-ejb-jar.xml でコンフィグレーションします。関連情報については、「コンテナ管理によるトランザクション要素」を参照してください。
コンテナ管理によるトランザクションの主なプログラミング ガイドラインは以下のとおりです。
EJBContext インタフェースの setRollbackOnly メソッドを呼び出します。Bean からアプリケーション例外が送出される場合 (通常は EJBException)、ロールバックは自動的に行われます。 weblogic-ejb-jar.xml の transaction-isolation が TransactionSerializable に設定されていても、同じ行でクライアント間に競合が発生した場合は EJB クライアントで例外またはロールバックが発生する場合があります。そのような例外を回避するために、以下のことができます。
このリリースの WebLogic Server では、トランザクションを開始したビジネス メソッドが、システム例外に関連のないトランザクション ロールバックが原因で失敗した場合、EJB コンテナが新しいトランザクションを開始し、失敗したメソッドを指定された回数まで再試行するように指定できます。メソッドの失敗が指定された再試行回数に達した場合、EJB コンテナは例外を送出します。
| 注意 : | EJB コンテナは、システム例外に基づくエラーが原因で失敗したトランザクションは再試行しません。 |
コンテナ管理によるトランザクションの自動的な再試行をコンフィグレーションするには、次の手順に従います。
コンテナ管理によるセッション Bean およびエンティティ Bean の場合にのみ、コンテナ管理によるトランザクションの自動再試行をコンフィグレーションできます。メッセージ駆動型 Bean の場合は、コンテナ管理によるトランザクションの自動再試行をコンフィグレーションできません。MDB は、メッセージの受信を含むトランザクションがロールバックされたときに、そのメッセージの受信の確認応答を行わないため、メッセージは確認応答が行われるまで自動的に再試行されます。また、タイマー Bean の場合も、コンテナ管理によるトランザクションの自動再試行はコンフィグレーションできません。タイマー Bean の ejbTimeout メソッドが開始されてロールバックされると、タイムアウトが常に再試行されるからです。
RequiresNew。メソッドのトランザクション属性 (ejb-jar.xml の trans-attribute 要素) が RequiresNew の場合、メソッドの呼び出し前に常に新しいトランザクションが開始され、コンフィグレーションされている場合、そのトランザクションが失敗すると自動再試行が行われます。Required。メソッドのトランザクション属性 (ejb-jar.xml の trans-attribute 要素) が Required の場合、メソッドが新しいトランザクションで再試行されるのは、失敗したトランザクションがそのメソッドのために開始された場合のみです。ejb-jar.xml の trans-attribute 要素については、「ejb-jar.xml のコンテナ管理によるトランザクション要素」の trans-attribute と Sun のドキュメント。weblogic-ejb-jar.xml の retry-methods-on-rollback 要素で指定します。
retry-methods-on-rollback の retry-count 下位要素は、Administration Console からも変更できます。
この節では、Bean 管理によるトランザクションのプログラミング上の考慮事項を示します。Bean レベルのトランザクションの特徴的な機能の概要や関連する設計上の考慮事項の説明については、「Bean レベルのトランザクション管理」を参照してください。
UserTransaction オブジェクトを取得してトランザクションを開始しなければなりません。UserTransaction オブジェクトを取得するには、次のコマンドを使用します。
ctx.lookup("javax.transaction.UserTransaction");
UserTransaction オブジェクトを取得した後は、tx.begin()、tx.commit()、tx.rollback() でトランザクションの境界を指定します。
データベース接続を取得してからトランザクションを開始した場合、その接続は新しいトランザクションと何の関連性も持たず、以後のトランザクション コンテキストにその接続を「入れる」ためのセマンティクスも存在しません。JTS 接続がトランザクション コンテキストに関連付けられていない場合、JTS 接続は autocommit を true に設定した標準の JDBC 接続と同じように動作し、更新はデータストアに自動的にコミットされます。
いったんトランザクション コンテキスト内にデータベース接続が作成されると、その接続はトランザクションがコミットまたはロールバックされるまで確保されます。パフォーマンスとスループットを最適化するには、トランザクションを迅速に完了させることによって、データベース接続を解放し、他のクライアント リクエストが使用できるようにする必要があります。詳細については、「機能と設計パターン」を参照してください。
| 注意 : | アクティブなトランザクション コンテキストには単一のデータベース接続しか関連付けることができません。 |
コード サンプルについては、コード リスト 4-3 を参照してください。
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();EJBContext インタフェースの getRollbackOnly メソッドと setRollbackOnly メソッドは呼び出さないでください。これらのメソッドは、コンテナ管理によるトランザクションのみで使用します。Bean 管理によるトランザクションでは、UserTransaction インタフェースの getStatus メソッドと rollback メソッドを呼び出します。
この節では、複数の Bean (複数のサーバ インスタンスに存在する場合もある) にトランザクションを分散させる 2 つのアプローチを説明します。
次の断片的なコードは、UserTransaction オブジェクトを取得し、それを使用してトランザクションを開始およびコミットするクライアント アプリケーションから引用したものです。クライアントは、トランザクションのコンテキストの中で 2 つの EJB を呼び出します。
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 タイマー サービスをサポートしています。EJB タイマー サービスは EJB コンテナによって提供されるサービスです。このサービスを使用すると、タイマー オブジェクトが期限切れになったときに発生するコールバックをスケジューリングするタイマーを作成できます。タイマー オブジェクトは、エンティティ Bean、メッセージ駆動型 Bean、およびステートレス セッション Bean 用に作成できます。タイマー オブジェクトは、指定した時間、指定した期間の経過後、または指定した間隔で期限切れになります。たとえば、タイマー サービスを使用して、EJB が一定期間にわたって特定の状態のままであるときに通知を送信できます。
WebLogic EJB タイマー サービスは、大まかなタイマー サービスとして使用するように設計されています。大量のタイマー オブジェクトを使用してデータ セットに対して同じタスクを実行するより、少数のタイマーを使用して大量のタスクを実行することをお勧めします。たとえば、従業員の経費レポートを表す EJB があるとします。各経費レポートは、マネージャの承認を受けてから処理されなければなりません。この場合、1 つの EJB タイマーを使用してすべての未決の経費レポートを定期的に検査し、担当のマネージャに対して、承認待ちのレポートを決裁するように促す電子メールを送信できます。
この節では、EJB 2.1 仕様に定義されている、タイマーのプログラミングに使用できる Java プログラミング インタフェースについて説明します。これらのインタフェースの詳細については、EJB 2.1 仕様を参照してください。また、この節では、WebLogic Server 固有のタイマー関連インタフェースについて詳しく説明します。
タイマーのプログラミングのために使用できる EJB 2.1 インタフェースは以下のとおりです。
javax.ejb.TimedObject インタフェース。タイマー コールバックのためにタイマー サービスに登録される Bean のエンタープライズ Bean クラスによって実装されます。このインタフェースは、単一のメソッド、ejbTimeout を備えています。EJBContext インタフェース。getTimerService メソッドを備え、タイマー サービスへのアクセスに使用します。javax.ejb.TimerService インタフェース。EJB の新しい EJB タイマーを作成するか、既存の EJB タイマーにアクセスできます。javax.ejb.Timer インタフェース。特定の EJB タイマーに関する情報が格納されます。javax.ejb.TimerHandle インタフェース。WebLogic Server は、このインタフェースを使用して、永続化できるシリアライズ可能なタイマー ハンドルを取得できます。タイマーはローカル オブジェクトなので、TimerHandle は Bean のリモート インタフェースまたは Web サービス インタフェースを介して渡してはなりません。
EJB 2.1 のタイマー関連プログラミング インタフェースの詳細については、EJB 2.1 仕様を参照してください。
この節では、タイマーのプログラミングに使用できる WebLogic Server 固有のインタフェースについて説明します。
WebLogic Server 固有のタイマー関連プログラミング インタフェースは以下のとおりです。
weblogic.management.runtime.EJBTimerRuntimeMBean。特定の EJBHome のタイマーの実行時情報と管理機能を提供します。コード リスト 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 仕様を参照してください。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 インタフェースを示します。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 インタフェースを示します。public interface WLTimer extends Timer {public int getRetryAttemptCount();
public int getMaximumRetryAttempts();
public int getCompletedTimeoutCount();
}
タイマーに関連するデプロイメント記述子の要素は以下のとおりです。
これらの要素の詳細については、「weblogic-ejb-jar.xml デプロイメント記述子のリファレンス」を参照してください。
タイマー オブジェクトは、別のサーバに移行できません。タイマー オブジェクトは、サーバ全体の一部としてのみ移行できます。EJB タイマーが存在するサーバが何らかの理由でダウンした場合、サーバを再起動するか、またはサーバ全体を移行しなければタイマーを実行できません。
WebLogic Server はタイマーを使用する EJB のクラスタ化をサポートしていません。タイマーは、タイマーが作成されたサーバ上でのみ動作し、そのサーバ上の Bean からしか見えません。EJB をクラスタにデプロイし、タイマーを作成するために EJB を呼び出した場合、その呼び出しはクラスタ内のいずれかのサーバに届きます。別の呼び出し (タイマーの取り消しなど) もクラスタ内のどのサーバにも届く可能性があり、必ずしも、タイマーを作成する呼び出しが届いた同じサーバに届くとは限りません。たとえば、タイマーを作成する呼び出しが server1 にリダイレクトされ、タイマーを取り消す呼び出しが server2 にリダイレクトされた場合、server2 にある EJB には server1 にあるタイマーが見えないため、タイマーを取り消すことはできません。
この制限を回避するには、以下のいずれかの方法を使用できます。
cancelTimer メソッドを呼び出します。ただし、この方法を使用するとアプリケーションがより複雑になり、すべてのサーバ上でタイマーを取り消そうとするのは効率がよくありません。
このリリースの WebLogic Server は、外部の Web サービスの宣言およびアクセスに関する EJB 2.1 の要件を満たしています。Web サービスの参照を EJB のデプロイメント記述子で宣言することによって、Web サービスの論理名が実際の Web サービス インタフェースにマップされます。これにより、論理名を使用して Web サービスを参照できるようになります。さらに、Bean コードは Web サービスの参照名を使用して JNDI ルックアップを実行します。
詳細については、『WebLogic Web サービス プログラマーズ ガイド』を参照してください。
コンパイル プロセスをサポートしているツールを確認するには、表 4-12 を参照してください。
コンパイル プロセスについては、『WebLogic Server アプリケーションの開発』の「Java コードのコンパイル」を参照してください。
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-11 を参照してください。
以下の節では、WebLogic Server 固有のデプロイメント要素を簡単に参照できます。各節では、特定のタイプの機能または動作に関連する要素が取り上げられています。各節の表では、制御する動作、関連する Bean タイプ (Bean タイプ固有の場合)、その要素が含まれる weblogic-ejb-jar.xml の親要素、および weblogic-ejb-jar.xml で明示的に指定しない場合に予想される動作に基づいて関連要素が定義されています。
各記述子ファイルの要素、定義、および使用例の包括的なドキュメントについては、以下を参照してください。
ejb-jar.xml. の要素に関する Sun のドキュメント| 注意 : | 以降の節では、「要素」カラムの要素名をクリックすると、その要素の詳しい説明が表示されます。 |
この表は、セキュリティに関連する weblogic-ejb-jar.xml の要素を示しています。
この表は、ソース コードで使用される Bean またはリソースの名前をデプロイメント環境の JNDI 名にマッピングする weblogic-ejb-jar.xml の要素を示しています。
|
|||||
この表は、Bean の状態がどのように保持されるのかを指定する weblogic-ejb-jar.xml の要素を示しています。
|
|||||
この表は、クラスタ化に関連する weblogic-ejb-jar.xml の要素を示しています。これらの要素は、WebLogic Server クラスタのクラスタ化された Bean のフェイルオーバおよびロード バランシング動作を制御します。
この表は、Bean インスタンスのデータとデータベースの一貫性に関連する weblogic-ejb-jar.xml の要素を示しています。これらの要素は、Bean インスタンスの値を反映して、いつどのようにデータベースが更新されるのかなどの動作を制御します。
| 注意 : | コンテナ管理による永続性に関連する要素については、「エンティティ Bean のプールとキャッシュの管理」を参照してください。 |
|
|||||
表 4-7 は、コンテナ管理によるトランザクションに関連する ejb-jar.xml の要素を示しています。
|
||||
表 4-8 は、コンテナ管理によるトランザクションに関連する weblogic-ejb-jar.xml の要素を示しています。
|
||||
この表は、パフォーマンスに関連する weblogic-ejb-jar.xml の要素を示しています。
weblogic-cmp-jar.xml の weblogic-query 要素) が true の場合、EJB ファインダまたは select クエリを実行する前にデータベースに更新をフラッシュする。 |
|||||
|
|||||
|
|||||
|
|||||
|
|||||
|
|||||
この表は、ネットワーク通信に関連する weblogic-ejb-jar.xml の要素を示しています。
コンテナ クラスには、WebLogic Server が使用する EJB の内部表現に加えて、クライアントが使用する外部インタフェース (ホーム、ローカル、またはリモート) の実装も格納されます。コンテナ クラスを生成するには、BEA Workshop for WebLogic Platform 9.2 または 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 は、エンタープライズ アプリケーションの一部としてパッケージ化することをお勧めします。詳細については、『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 を含む) をデプロイする一般的な手順については、『WebLogic Server アプリケーションのデプロイメント』を参照してください。EJB 固有のデプロイメントの問題と手続きについては、このガイドの「エンタープライズ JavaBean のデプロイメント ガイドライン」を参照してください。
以降の節では、デプロイした EJB のチェックとデバッグに便利な WebLogic Server の機能を説明します。
appc で EJB をコンパイルする場合は、appc -lineNumbers コマンド オプションを使用して、デバッグしやすいように生成したクラス ファイルに行番号を追加できます。詳細については、「appc リファレンス」を参照してください。
WebLogic Server は、デプロイされた EJB の実行時の処理についてさまざまなデータを収集します。Administration Console の [デプロイメント] ノードで表示できるこのデータは、EJB が目的の処理を完了しているかどうかを判断する上で便利です。EJB の実行時の統計を表示するには、Administration Console で [デプロイメント] ノードを展開し、その Bean が含まれている JAR EAR を見つけて [モニタ] タブを選択します。
参照できるデータについては、Administration Console オンライン ヘルプの以下のページを参照してください。
バグや問題のトラブルシューティングおよび解決に役立つメッセージをアプリケーションで作成する手順については、『ログ ファイルのコンフィグレーションとログ メッセージのフィルタ処理』を参照してください。
この節では、EJB 開発プロセスをサポートする BEA のツールについて説明します。各ツールの機能の比較については、「表 4-12 EJB ツールとその機能」を参照してください。
Administration Console では、多くのデプロイメント記述子要素について表示、修正、および EJB 内の記述子ファイルへの保持を行うことができます。記述子は、EJB の管理サーバ コピー、ならびに EJB のすべてのデプロイされたコピー (デプロイ後) において、修正されます。記述子を修正した場合、変更はユーザの EJB のオリジナル コピー (デプロイ前) に対して行われます。
ただし、これらの記述子要素の更新は、EJB を再デプロイする必要なしに、実行時に動的に行われます。Administration Console で変更できる記述子要素は、表 4-11 にまとめられているように、実行時に動的に変更できるものに限定されています。
|
|
Sun Java J2SE SDK に付属の javac コンパイラは、java コンパイル機能を提供します。javac については、http://java.sun.com/docs/ を参照してください。
EJBGen は、EJB 2.x のコード ジェネレータです。Bean クラス ファイルに javadoc タグでアノテーションを付けた後、EJBGen を使用して EJB アプリケーションのリモート インタフェース クラス、ホーム インタフェース クラス、および、デプロイメント記述子ファイルを生成することができるので、編集および管理すべき EJB ファイルの数を 1 つに減らせます。
デプロイメント記述子の生成には、EJBGen の使用をお勧めします。これは、EJB の維持を容易化および簡略化できる、BEA のベスト プラクティスです。EJBGen を使用する場合、記述してアノテーションを付ける必要がある Bean クラスは 1 つだけです。そのため、記述、デバッグ、および維持が簡略化されます。開発環境として BEA Workshop for WebLogic Platform 9.2 を使用すると、EJBGen タグが自動挿入されます。
EJBGen については、「EJBGen リファレンス」を参照してください。
weblogic.Deployer コマンドライン ツールは、WebLogic Server デプロイメント API にコマンドライン インタフェースを提供する、Java ベースの開発ツールです。このツールは、コマンドライン、シェル スクリプト、または Java 以外の自動化された環境からデプロイメントを開始する必要がある管理者および開発者向けに開発されました。
『WebLogic Server アプリケーションのデプロイメント』の「weblogic.Deployer コマンドライン リファレンス」を参照してください。
appc コンパイラは、EJB および JSP を WebLogic Server にデプロイするのに必要なクラスを生成し、コンパイルします。appc は、個別のモジュール レベルとアプリケーション レベルの両方で、現在の仕様に準拠しているかどうかデプロイメント記述子を検証します。アプリケーション レベルのチェックでは、個別のモジュールに対するアプリケーション レベルのデプロイメント記述子のチェックと、モジュール全体の検証チェックが行われます。
| 注意 : | appc は、非推奨の ejbc ユーティリティの後継ツールです。ejbc ではなく appc を使用することをお勧めします。 |
「appc リファレンス」を参照してください。
DDConverter は、WebLogic Server の旧リリースのデプロイメント記述子をアップグレードするコマンドライン ツールです。最新の J2EE 仕様と WebLogic Server リリースの機能を活用するために、常にデプロイメント記述子をアップグレードすることをお勧めします。
weblogic.DDConverter を使用すると、デプロイメント記述子をアップグレードできます。weblogic.DDConverter の使い方については、『WebLogic Server アプリケーションの開発』の「以前のリリースの J2EE および WebLogic Server のデプロイメント記述子のアップグレード」を参照してください。
| 注意 : | このリリースの WebLogic Server では、EJB 固有の DDConverter である weblogic.ejb20.utils.DDConverter は非推奨になっています。使用しているアプリケーションのデプロイメント記述子 (EJB 固有のデプロイメント記述子を含む) を変換するには、アプリケーション レベルの新しい DDConverter である weblogic.DDConverter を使用してください。 |
次の表は EJB 開発の BEA ツールと、各ツールの機能を示しています。
  
|
