WebLogic エンタープライズ JavaBeans (EJB) プログラマーズ ガイド
以降の節では、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
というサブディレクトリを作成します。
コード リスト 4-1JAR をパッケージ化するためのディレクトリ構造
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 Workshop からも利用できます。WebLogic Workshop は EJBGen の機能と他の開発支援ツールを統合した開発環境であり、使いやすいユーザ インタフェースを備えています。それらのツールの詳しい情報と使い方については、「EJBGen リファレンス」と「WebLogic Workshop のヘルプ」を参照してください。
以降の節では、WebLogic Server 固有の EJB 機能を使用する上でのヒントとガイドラインを示します。
WebLogic Server では、各 EJB タイプについて、ほとんどの EJB で必要な Java コールバック (リスナ) が含まれる汎用クラスが提供されます。それらの汎用クラスは、weblogic.ejb
パッケージにあります。
汎用 Bean テンプレートは、その汎用クラスを作成中のクラスにインポートすることで独自のクラスで実装できます。次の例では、GenericSessionBean
クラスが HelloWorldEJB
にインポートされます。
import weblogic.ejb.GenericSessionBean;
...
public class HelloWorldEJB extends GenericSessionBean {
以降の節では、EJB に対するクライアント アクセスをプログラミングするためのガイドラインを示します。
ローカル クライアントは、次の抜粋のような getInitialContext
メソッドを使用して初期コンテキストを取得します。
コード リスト 4-2ルックアップを実行するローカル クライアント
...
Context ctx = getInitialContexLt("t3://localhost:7001", "user1", "user1Password");
...
static Context getInitialContext(String url, String user, String password) {
Properties h = new Properties();
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 のホーム インタフェースをルックアップできます。
WebLogic Server では、EJB 2.0 仕様で定義されている 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 を指定するには、次の手順を行います。
weblogic-ejb-jar.xml
の resource-description スタンザの <jndi-name>
要素で URL を指定します。URL を指定する代わりに、JNDI でバインドされ、URL に対応するオブジェクトを指定するには、次のようにします。
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();
トランザクション設計上の決定事項については、「表 3-2 機能と設計パターン」を参照してください。以降の節では、トランザクション プログラミングのガイドラインを示します。
トランザクションをエンティティ 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 クライアントで例外またはロールバックが発生する場合があります。そのような例外を回避するために、以下のことができます。この節では、Bean 管理によるトランザクションのプログラミング上の考慮事項を示します。Bean レベルのトランザクションの特徴的な機能の概要や関連する設計上の考慮事項の説明については、「Bean レベルのトランザクション管理」を参照してください。
UserTransaction
オブジェクトを取得してトランザクションを開始しなければなりません。UserTransaction
オブジェクトを取得するには、次のコマンドを使用します。ctx.lookup("javax.transaction.UserTransaction");
UserTransaction
オブジェクトを取得した後は、tx.begin()
、tx.commit()
、tx.rollback()
でトランザクションの境界を指定します。
データベース接続を取得してからトランザクションを開始した場合、その接続は新しいトランザクションと何の関連性も持たず、以後のトランザクション コンテキストにその接続を「入れる」ためのセマンティクスも存在しません。JTS 接続がトランザクション コンテキストに関連付けられていない場合、JTS 接続は autocommit
を true
に設定した標準の JDBC 接続と同じように動作し、更新はデータストアに自動的にコミットされます。
いったんトランザクション コンテキスト内にデータベース接続が作成されると、その接続はトランザクションがコミットまたはロールバックされるまで確保されます。パフォーマンスとスループットを最適化するには、トランザクションを迅速に完了させることによって、データベース接続を解放し、他のクライアント リクエストが使用できるようにする必要があります。詳細については、「表 3-2 機能と設計パターン」を参照してください。
注意 : Oracle のみのアイソレーション レベル値 - TRANSACTION_READ_COMMITTED_FOR_UPDATE
と TRANSACTION_READ_COMMITTED_FOR_UPDATE_NO_WAIT
は、Bean 管理によるトランザクションでは設定できません。
コード サンプルについては、「コード リスト 4-3」を参照してください。
コード リスト 4-3BMT でのトランザクション アイソレーション レベルの設定
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");
//トランザクションのアイソレーション レベルを TRANSACTION_READ_COMMITED に設定する
Transaction tx = TxHelper.getTransaction();
tx.setProperty (TxConstants.ISOLATION_LEVEL, new Integer
(Connection.TRANSACTION_READ_COMMITED));
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 Workshop は、クラス ファイルをコンパイルするための推奨ツールです。WebLogic Workshop の詳細については、「WebLogic Workshop のヘルプ」を参照してください。他にどのツールがコンパイル プロセスをサポートしているのか確認するには、表 4-11 を参照してください。
コンパイル プロセスについては、『WebLogic Server アプリケーションの開発』の「Java コードのコンパイル」を参照してください。
WebLogic Workshop または EJBGen を使用してソース ファイルに希望の Bean 機能および実行時動作のタグでアノテーションを付けている場合は、記述子が自動的に生成されます。
それらのツールは、Bean クラス ファイルからホーム インタフェースやリモート インタフェースを生成するだけでなく、クラス ファイルから必要なデプロイメント記述子を自動的に生成します。
ejb-jar.xml
、weblogic-ejb-jar.xml
、および weblogic-cmp-jar.xml
(コンテナ管理による永続性エンティティ Bean の場合) の要素は、アプリケーションの実行時の特性を制御します。
記述子要素を修正する必要がある場合は、任意のテキスト エディタを使用して記述子ファイルを編集できます。 ただし、エラーを防止するために、EJBgen や WebLogic Builder などの XML 編集用に設計されたツールを使用してください。WebLogic Server Administration Console で編集できる記述子要素については、表 4-10を参照してください。
以下の節では、WebLogic Server 固有のデプロイメント要素を簡単に参照できます。各節では、特定のタイプの機能または動作に関連する要素が取り上げられています。各節の表では、制御する動作、関連する Bean タイプ (Bean タイプ固有の場合)、その要素が含まれる weblogic-ejb-jar.xml
の親スタンザ、および weblogic-ejb-jar.xml
で明示的に指定しない場合に予想される動作という観点で関連要素が定義されています。
各記述子ファイルの要素、定義、および使用例の包括的なドキュメントについては、以下を参照してください。
ejb-jar.xml.
の要素に関する Sun のドキュメントこの表は、セキュリティに関連する weblogic-ejb-xml.jar
の要素を示しています。
表 4-2 weblogic-ejb-jar.xml のセキュリティ要素
|
||
|
||
この表は、ソース コードで使用される Bean またはリソースの名前をデプロイメント環境の JNDI 名にマッピングする weblogic-ejb-xml.jar
の要素を示しています。
表 4-3 weblogic-ejb-jar.xml のリソース マッピング要素
|
|||
|
|||
この表は、Bean の状態がどのように保持されるのかを指定する weblogic-ejb-xml.jar
の要素を示しています。
表 4-4 weblogic-ejb-jar.xml の永続性要素
この表は、クラスタ化に関連する weblogic-ejb-jar.xml
の要素を示しています。これらの要素は、WebLogic Server クラスタのクラスタ化された Bean のフェイルオーバおよびロード バランシング動作を制御します。
表 4-5 weblogic-ejb-jar.xml のクラスタ化要素
この表は、Bean インスタンスのデータとデータベースの一貫性に関連する weblogic-ejb-jar.xml
の要素を示しています。これらの要素は、Bean インスタンスの値を反映していつどのようにデータベースが更新されるのかなどの動作を制御します。
注意 : コンテナ管理による永続性に関連する要素については、「エンティティ Bean のプールとキャッシュの管理」を参照してください。
表 4-6 weblogic-ejb-jar.xml のデータ一貫性要素
表 4-7 は、コンテナ管理によるトランザクションに関連するejb-xml.jar
の要素を示しています。
表 4-7 ejb-jar.xml のコンテナ管理によるトランザクション要素
表 4-8は、コンテナ管理によるトランザクションに関連する weblogic-ejb-xml.jar
の要素を示しています。
表 4-8 weblogic-ejb-jar.xml のコンテナ管理によるトランザクション要素
この表は、パフォーマンスに関連する weblogic-ejb-xml.jar
の要素を示しています。
表 4-9 weblogic-ejb-jar.xml のパフォーマンス要素
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
コンテナ クラスには、WebLogic Server が使用する EJB の内部表現に加えて、クライアントが使用する外部インタフェース (ホーム、ローカル、またはリモート) の実装も格納されます。コンテナ クラスを生成するには、WebLogic Workshop または 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 アプリケーションの作成」を参照してください。
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 固有のデプロイメントの問題と手続きについては、この『WebLogic エンタープライズ JavaBeans (EJB) プログラマーズ ガイド』の「エンタープライズ JavaBean のデプロイメント ガイドライン」を参照してください。
以降の節では、デプロイした EJB のチェックとデバッグに便利な WebLogic Server の機能を説明します。
appc
で EJB をコンパイルする場合は、appc -lineNumbers
コマンド オプションを使用して、デバッグしやすいように生成したクラス ファイルに行番号を追加できます。詳細については、「appc と ejbc のリファレンス」を参照してください。
WebLogic Server は、デプロイされた EJB の実行時の処理についてさまざまなデータを収集します。Administration Console の [デプロイメント] ノードで表示できるこのデータは、EJB が目的の処理を完了しているかどうかを判断する上で便利です。EJB の実行時の統計を表示するには、Administration Console で [デプロイメント] ノードを展開し、その Bean が含まれている JAR EAR を見つけて [モニタ] タブを選択します。
参照できるデータについては、Administration Console オンライン ヘルプの以下のページを参照してください。
バグや問題のトラブルシューティングおよび解決に役立つメッセージをアプリケーションで作成する手順については、『WebLogic Server ロギング サービスの使い方』の「デバッグ メッセージの書き込み」を参照してください。
この節では、EJB 開発プロセスをサポートする BEA のツールについて説明します。各ツールの機能の比較については、「表 4-11」 を参照してください。
WebLogic Workshop は、BEA WebLogic Platform の共有開発環境です。WebLogic Workshop はコードの作成からデプロイメントに至る EJB 開発のあらゆる局面をサポートし、EJB 開発の BEA 推奨ツールとなっています。主な機能は次のとおりです。
WebLogic Workshop については、「WebLogic Workshop のヘルプ」を参照してください。
Administration Console の [記述子] タブを使用すると、多くのデプロイメント記述子要素について表示、修正、および EJB 内の記述子ファイルへの保持を行うことができます。記述子は、EJB の管理サーバ コピー、ならびに EJB のすべてのデプロイされたコピー (デプロイ後) において、修正されます。WebLogic Builder または手動の編集ツールを使用して記述子を修正した場合、変更はユーザの EJB のオリジナル コピー (デプロイ前) に対して行われます。
ただし、これらの記述子要素の更新は、EJB を再デプロイする必要なしに、実行時に動的に行われます。[記述子] タブに含まれる記述子要素属性は、表 4-10にまとめられているように、実行時に動的に変更できるものに限定されています。
注意 : アーカイブ ファイルからデプロイされたアプリケーションとモジュールのデプロイメント記述子は、Administration Console を使用して編集できません。
Sun Java J2SE SDK に付属の javac
コンパイラは、java コンパイル機能を提供します。javac
については、http://java.sun.com/docs/ を参照してください。
EJBGen は、EJG 2.0 のコード ジェネレータです。 Bean クラス ファイルに javadoc タグでアノテーションを付けた後、EJBGen を使用して EJB アプリケーションのリモート インタフェース クラス、ホーム インタフェース クラス、および、デプロイメント記述子ファイルを生成することができるので、編集および管理すべき EJB ファイルの数を 1 つに減らせます。
デプロイメント記述子の生成には、EJBGen
の使用をお勧めします。これは、EJB の維持を容易化および簡略化できる、BEA のベスト プラクティスです。EJBGen
を使用する場合、記述してアノテーションを付ける必要がある Bean クラスは 1 つだけです。そのため、記述、デバッグ、および維持が簡略化されます。開発環境として WebLogic Workshop を使用すると、EJBGen タグが自動挿入されます。
EJBGen を使用するアプリケーションの例については、WebLogic 8.1 Server のサンプルをインストールして、WL_HOME\samples\server\examples\src\examples\ejb20\ejbgen
を参照してください。アプリケーションの名前は Bands です。
EJBGen については、「EJBGen リファレンス」を参照してください。
WebLogic Builder は、デプロイメント記述子ファイルを表示したり、XML を直接編集することなくその内容を修正したりするためのビジュアル環境です。
WebLogic Builder は、以下の開発タスクをサポートしています。
『WebLogic Builder オンライン ヘルプ』を参照してください。
DDInit は、WebLogic Server アプリケーションのデプロイメント記述子を生成するためのユーティリティです。DDInit は、クラス ファイルの情報を利用してデプロイメント記述子ファイルを作成します。
WebLogic Builder は、DDInit を使用してデプロイメント記述子を生成します。詳細については、「WebLogic Builder」を参照してください。
『WebLogic Server コマンド リファレンス』の「DDInit」を参照してください。
WebLogic Server には、スケルトン デプロイメント記述子を作成する Ant ユーティリティが含まれています。
Ant タスクは、EJB の含まれるディレクトリを調べて、そのディレクトリの内容に基づいてデプロイメント記述子を作成します。Ant ユーティリティは、個別の EJB に必要なコンフィグレーションやマッピングに関する情報をすべて備えているわけではないので、Ant ユーティリティによって作成されるスケルトン デプロイメント記述子は不完全なものです。Ant ユーティリティでスケルトン デプロイメント記述子を作成した後で、テキスト エディタ、XML エディタ、または WebLogic Builder を使ってデプロイメント記述子を編集し、EJB のコンフィグレーションを完全なものにしてください。
詳細については、『WebLogic Server アプリケーションのデプロイメント』の「wldeploy Ant タスク」を参照してください。
weblogic.Deployer
コマンドライン ツールは、WebLogic Server デプロイメント API にコマンドライン インタフェースを提供する、Java ベースの開発ツールです。このツールは、コマンドライン、シェル スクリプト、または Java 以外の自動化された環境からデプロイメントを開始する必要がある管理者および開発者向けに開発されました。
『WebLogic Server アプリケーションのデプロイメント』の「weblogic.Deployer ユーティリティ」を参照してください。
appc
コンパイラは、EJB および JSP を WebLogic Server にデプロイするのに必要なクラスを生成し、コンパイルします。appc は、個別のモジュール レベルとアプリケーション レベルの両方で、現在の仕様に準拠しているかどうかデプロイメント記述子を検証します。アプリケーション レベルのチェックでは、個別のモジュールに対するアプリケーション レベルのデプロイメント記述子のチェックと、モジュール全体の検証チェックが行われます。
注意 : appc は、非推奨の ejbc
ユーティリティの後継ツールです。ejbc
ではなく appc
を使用することをお勧めします。
「appc と ejbc のリファレンス」を参照してください。
DDConverter
は、以前のバージョンの EJB デプロイメント記述子を本バージョンの WebLogic Server に準拠した EJB デプロイメント記述子に変換するコマンドライン ツールです。
アプリケーションを新しい WebLogic Server リリースに移行するときには、必ず記述子を変換することをお勧めします。
次の表は EJB 開発の BEA ツールと、各ツールの機能を示しています。