EJB 3.0 および EJB 3.1 アプリケーション・バインディングの概要
アプリケーション・サーバーにインストールしたアプリケーションを開始するには、その前に、そのアプリケーションで定義されたすべての Enterprise JavaBeans (EJB) 参照およびリソース参照が、アプリケーション・サーバーで定義された実際の成果物 (エンタープライズ Bean またはリソース) にバインドされている必要があります。
バージョン 8.0 からは、EJB コンテナーのバインディング・サポートが拡張されています。 EJB コンテナーは、アプリケーション名、モジュール名、およびコンポーネント名に基づいて、EJB 3.x ビジネス・インターフェースに対するデフォルトの JNDI バインディングを割り当てます。EJB 3.x モジュール内のインターフェースまたは EJB ホームのそれぞれに対して、あるいは EJB 3.1 内の各非インターフェース・ビューに対して JNDI バインディング名を明示的に定義する必要はありません。
バインディングを定義する場合は、アプリケーションの参照可能な成果物と参照済みの成果物に対して、Java™ Naming and Directory Interface (JNDI) 名を指定します。 成果物に対して指定する jndiName 値は、修飾された検索名である必要があります。
EJB 3.x モジュールのエンタープライズ Bean 上のインターフェース、EJB ホーム、または非インターフェース・ビューのそれぞれに対して、 JNDI バインディング名を手動で割り当てる必要はありません。バインディングが明示的に割り当てられていない場合、EJB コンテナーはデフォルト・バインディングを割り当てます。
デフォルトの EJB JNDI バインディングの名前空間
デフォルトの EJB バインディングは、アプリケーション・サーバーによって従来および java:[scope] の名前空間のセットの両方に配置される場合があります。
従来の名前空間のセットは、ejblocal: およびグローバル JNDI 名前空間で構成されます。従来の名前空間には、WebSphere® 拡張子が含まれており、 この名前空間はバージョン 8.0 より前のアプリケーション・サーバーにあります。
java:[scope] 名前空間のセットは、java:global、java:app、および java:module の名前空間から構成されます。java:[scope] 名前空間は Java EE 6 仕様で規定されているもので、WebSphere Application Server にはバージョン 8 で導入されました。これらの名前空間は、従来の名前空間に代わるものではありません。 むしろ、従来の名前空間に追加されています。
従来の名前空間についての詳細
- Java 仮想マシン (JVM) 有効範囲 ejblocal: 名前空間
- グローバル JNDI 名前空間
ローカル EJB インターフェース、ホーム、および非インターフェース・ビューは、常に JVM 有効範囲の従来の ejblocal: 名前空間にバインドする必要があります。これらは、同じアプリケーション・サーバー・プロセス内からのみアクセス可能です。
一方、リモート EJB インターフェースおよびホームは、常に従来のグローバル有効範囲の WebSphere JNDI 名前空間にバインドされる必要があります。 これらは、他のサーバー・プロセスおよび他のリモート・クライアントを含む、任意の場所からアクセス可能です。 ローカル・インターフェースおよび非インターフェース・ビューを 従来のグローバル有効範囲 JNDI 名前空間にバインドすることも、リモート・インターフェースを JVM 有効範囲の従来の ejblocal: 名前空間にバインドすることもできません。
従来の ejblocal: 名前空間と従来のグローバル有効範囲 JNDI 名前空間は、まったく別のものです。例えば、「ejblocal:AccountHome」でバインドされた EJB ローカル・インターフェースまたは非インターフェース・ビューは、 従来のグローバル有効範囲名前空間の「AccountHome」でバインドされたリモート・インターフェースとは異なります。この振る舞いは、ローカルおよびリモートのインターフェース参照間の区別を維持する場合に役に立ちます。さらに、JVM 有効範囲ローカル名前空間がある場合は、Java Platform, Enterprise Edition (Java EE) アプリケーション境界を含む JVM サーバー・プロセスの任意の場所から、アプリケーションがローカル EJB インターフェースおよび非インターフェース・ビューを直接検索したり、参照したりすることも可能になります。
アプリケーション、モジュール、およびコンポーネント名に基づいた EJB 3.x コンテナー内の EJB ビジネス・インターフェースに対するデフォルトの従来の JNDI バインディング
EJB コンテナーは、アプリケーション名、モジュール名、およびコンポーネント名に基づいて、EJB 3.x ビジネス・インターフェースに対するデフォルトの従来の JNDI バインディングが割り当てるため、これらの名前の定義方法を理解することが重要になります。これらの名前は、いずれも 文字ストリングです。
- EJB モジュール、Java EE アプリケーション・クライアント・モジュール、およびユーティリティー・クラス・モジュール用の Java アプリケーション・アーカイブ (JAR) ファイル
- Web モジュール用の Web アプリケーション・アーカイブ (WAR) ファイル
- リソース・アプリケーション・アーカイブ (RAR) ファイルなどのテクノロジー固有の他のモジュール、および他のタイプのモジュール
Java EE モジュールが Java EE アプリケーション・アーカイブ内にパッケージ化され、次に Java EE コンポーネントが Java EE モジュール内にパッケージ化されるため、各コンポーネントの「ネスト・パス」を使用することにより、そのアプリケーション名、モジュール名、およびコンポーネント名に基づいて Java EE アプリケーション・アーカイブ内のそれぞれのコンポーネントを一意的に識別することができます。
従来のバインディングで使用されるアプリケーション名
- 製品へのアプリケーションのインストール中に、製品の管理コンソールに指定されたアプリケーション名の値、または wsadmin コマンド行スクリプト・ツールに指定された appname パラメーターの値。
- アプリケーションの META-INF/application.xml デプロイメント記述子内の <display-name> パラメーターの値。
- .ear というファイル接尾部を除外した EAR ファイル名。例えば、CustomerServiceApp.ear という名前のアプリケーション EAR ファイルの場合は、「CustomerServiceApp」というアプリケーション名になります。
- アプリケーションの application.xml デプロイメント記述子内の <application-name> パラメーターの値。
- .ear というファイル接尾部を除外した EAR ファイル名。例えば、CustomerServiceApp.ear という名前のアプリケーション EAR ファイルには、「CustomerServiceApp」というアプリケーション名があります。このアプリケーションがスタンドアロン・モジュールである場合、java:global 検索名にはアプリケーション・コンポーネントが含まれません。
従来のバインディングで使用されるモジュール名
モジュールの名前は、EAR ファイルが常駐するルートを基準とする、モジュール・ファイルの Uniform Resource Identifier (URI) として定義されます。言い換えれば、モジュール名は、そのモジュール・ファイルがネストされているすべてのサブディレクトリーを含む EAR ファイルのルートを基準とする、モジュールのファイル名です。この命名規則は、論理モジュール名が、モジュール名エレメントをデプロイメント記述子に使用して明示的に指定されている場合でも適用されます。
CustomerServiceApp.ear:AccountProcessing.jar
com/mycompany/AccountProcessingServiceBean.class AccountProcessingService.class
Utility/FinanceUtils.jar META-INF/ejb-jar.xml
com/mycompany/InterestCalculatorServiceBean.class InterestCalculatorService.class
AppPresentation.war META-INF/web.xml
- モジュールの ejb-jar.xml または web.xml デプロイメント記述子内の <module-name> パラメーターの値。
- .jar または .war 接尾部を除外したモジュール URI。 例えば、URI が CustomerService.jar または CustomerService.war であるモジュールのモジュール名は、「CustomerService」となります。
従来のバインディングで使用される EJB コンポーネント名
- ejb-jar.xml デプロイメント記述子内の Bean に関連付けられた ejb-name タグ (存在する場合) の値。
- Bean に関連付けられた @Stateless または @Stateful アノテーション内の、「名前」パラメーターの値 (存在する場合)。
- パッケージ・レベルの修飾子が付かない Bean 実装クラスの名前。
バインディング
EJB 3.x モジュールでサポートされる以下のバインディングを検討してください。
- ビジネス・インターフェース、ホーム、および非インターフェース・ビューの デフォルトの従来のバインディング
- デフォルトの従来のバインディング・パターン
- java:[scope] バインディング
- EJB ビジネス・インターフェース、ホーム、および非インターフェース・ビューのユーザー定義バインディング
- 参照および注入ターゲットを解決する ユーザー定義バインディング
- EJB 参照および EJB 注入のデフォルトの解決: AutoLink フィーチャー
- EJB および リソースの参照と注入の解決: ルックアップ機能
- アプリケーションで定義された環境エントリーのオーバーライド
- データ・ソース定義のオーバーライド
- クラスター環境内の ネーミング考慮事項
- ユーザー定義 EJB 拡張設定
- レガシー (XMI) バインディング
- ユーザー指定 XML バインディング
EJB ビジネス・インターフェース、ホーム、および非インターフェース・ビューの デフォルトの従来のバインディング
EJB 3.x モジュール内のインターフェースまたは EJB ホームのそれぞれに対して、あるいは EJB 3.1 内の各非インターフェース・ビューに対して JNDI バインディング名を明示的に定義する必要はありません。バインディングを明示的に割り当てない場合は、製品の EJB コンテナーにより、ここで説明されている規則を使用してデフォルトの従来のバインディングが割り当てられます。これは、EJB 3.0 仕様がサポートされるより前の製品における EJB サポートとは異なります。
EJB コンテナーは、各エンタープライズ Bean 上で各インターフェース (ビジネス、リモート・ホーム、またはローカル・ホーム)、または非インターフェース・ビューごとに 2 つのデフォルトの従来のバインディングを実行します。ここでは、これら 2 つの従来のバインディングをインターフェースまたは非インターフェース・ビューの短い バインディングおよび長い バインディングと呼びます。短いバインディングは、インターフェースまたは非インターフェース・ビューのパッケージ修飾 Java クラス名のみを使用し、一方長いバインディングはパッケージ修飾されたインターフェース・クラス名または非インターフェース・ビュー・クラス名の前にエンタープライズ Bean のコンポーネント ID を追加修飾子として使用します。この場合、コンポーネント ID とインターフェース・クラス名または非インターフェース・クラス名との間には、ハッシュまたは番号記号 (# 記号) が使用されます。 これら 2 つの形式間の相違点は、短い TCP/IP ホスト名 (マシン名のみ) と長い ホスト名 (前にドメイン名が付加されるマシン名) との関係と類似であると考えることができます。
例えば、インターフェースまたは非インターフェース・ビューの短いデフォルトの従来のバインディングおよび長いデフォルト・バインディングは、それぞれ com.mycompany.AccountService と AccountApp/module1.jar/ServiceBean#com.mycompany.AccountService です。
デフォルトでは、EJB デフォルトの従来のバインディングのコンポーネント ID は、 エンタープライズ Bean のアプリケーション名、モジュール名、およびコンポーネント名を使用して構成されますが、代わりに任意のストリングを割り当てることもできます。コンポーネント ID として独自のストリングを定義することにより、共通のユーザー定義部分はエンタープライズ Bean の長い形式のバインディングで共有され、システム定義部分は各インターフェース・クラスまたは非インターフェース・ビュー・クラスの名前に基づいて得られるような命名規則を設定することができます。また、デフォルトの EJB バインディング名を、アプリケーション・モジュール階層内でのエンタープライズ Bean のパッケージ化方法から独立させることもできます。エンタープライズ Bean のデフォルトのコンポーネント ID の指定変更については、このトピックの『EJB ビジネス・インターフェース、ホーム、および非インターフェースのユーザー定義バインディング』セクションで説明されています。
従来の JVM 有効範囲ローカル名前空間および従来のグローバル有効範囲 JNDI 名前空間に関するセクションで前に説明したように、すべてのローカル・インターフェース、ホーム、および非インターフェース・ビューは、従来の ejblocal: 名前空間にバインドされる必要があり、これは同じサーバー・プロセス (JVM) 内でのみアクセス可能です。一方、リモート・インターフェースおよびホームは従来のグローバル有効範囲名前空間にバインドされる必要があり、これは WebSphere 製品セル内の任意の場所からアクセス可能です。 このことから予想されるように、EJB コンテナーは これらのデフォルト・バインディング規則に従います。
さらに、リモート・インターフェースの長い デフォルト・バインディングは、ejb コンテキスト名の下でグループ化されるという点で、推奨されている Java EE のベスト・プラクティスに従っています。デフォルトでは、 リモート・ホームおよびビジネス・インターフェースは、アプリケーション・サーバーの ネーミング・コンテキストのルートにバインドされます。ただし、アプリケーション・サーバー・ルート・コンテキストは、EJB インターフェース以外のバインディングにも使用されます。したがって、このコンテキストが雑然と使用されすぎないようにするために、"ejb" 関連のバインディングを直接サーバー・ルート・コンテキストに配置せずに、共通の「ejb」サブコンテキストにグループ化することをお勧めします。これは、すべてのファイルをルート・ディレクトリーに配置せずに、 ディスク・ボリューム上のサブディレクトリーを使用する理由と類似しています。
- 短いデフォルト・バインディングでは、単純で直接的な方法によって EJB インターフェースにアクセスすることができます。それらを直接サーバー・ルート・コンテキストに配置し、 インターフェース名または ejblocal: を前に付加したインターフェース名で参照することは、 単純化の目標と合致していました。
- 同時に、長いデフォルト・バインディングを ejb コンテキスト内に配置するか、または ローカル・インターフェースの場合は ejblocal: コンテキスト内に配置することにより、 サーバーのルート・コンテキストからこれらのバインディングが除外され、ルート・コンテキスト内が雑然と使用されずに短いバインディングだけを配置できるようになりました。
- これにより、類似の命名規則を使用する他の Java EE アプリケーション・サーバーとのある程度の相互互換性が提供されます。
要約すると、すべての短いローカル・デフォルト・バインディングと長いローカル・デフォルト・バインディングは従来の ejblocal: サーバー/JVM 有効範囲名前空間に配置され、一方リモート・デフォルト・バインディングは、短いバインディングの場合には従来のグローバル有効範囲名前空間のサーバー・ルート・コンテキストに配置され、長いバインディングの場合には <server_root>/ejb コンテキスト (サーバー・ルート・コンテキストの後) に配置されるということになります。つまり、サーバーのグローバル有効範囲ルート・コンテキスト内の デフォルト・バインディングのみがリモート・インターフェースの短いバインディングになります。 これは、単純で移植可能な使用モデルを提供することと、サーバーのグローバル有効範囲ルート・コンテキストが雑然と使用され過ぎないようにすることとの間の、ベスト・バランスです。
デフォルトの従来のバインディング・パターン
各タイプの 従来のバインディングのパターンを、以下の表に示します。これらのパターンにおいては、 <ブラケットで囲まれた斜体> のストリングが値を示します。例えば、<package.qualified.interface> は com.mycompany.AccountService となり、<component-id> は AccountApp/module1.jar/ServiceBean となります。
バインディング・パターン | 説明 |
---|---|
ejblocal:<package.qualified.interface> | 短い形式のローカル・インターフェース、ホーム、および非インターフェース・ビュー |
<package.qualified.interface> | 短い形式のリモート・インターフェースおよびホーム |
ejblocal:<component-id>#<package.qualified.interface> | 長い形式のローカル・インターフェース、ホーム、および非インターフェース・ビュー |
ejb/<component-id>#<package.qualified.interface> | 長い形式のリモート・インターフェースおよびホーム |
component-id のデフォルト・パターンは、次のセクション『複数のエンタープライズ Bean が同じインターフェースを実装する場合の短いデフォルト・バインディング名の競合』で説明されているように、component-id 属性を使用して EJB モジュール・バインディング・ファイル内で指定変更されない限り、<application-name>/<module-jar-name>/<ejb-name> になります。EJB モジュール・バインディング・ファイルによって指定変更されない限り、論理モジュール名がデプロイメント記述子で指定されていたとしても、前の『モジュール名』セクションで説明されたとおりに、<module-jar-name> 変数が拡張子 (.jar、.ear、.war など) を含む EAR 内の物理的モジュール・ファイルの名前になります。
複数のエンタープライズ Bean が同じインターフェースを実装する場合の短いデフォルトの従来のバインディング名の競合
アプリケーション・サーバーで実行中の複数のエンタープライズ Bean が特定のインターフェースまたは非インターフェース・ビューを実装する場合は、短いデフォルトの従来のバインディング名ではあいまいになります。これは、短い名前がこのインターフェースまたは非インターフェース・ビューを実装する任意の Enterprise JavaBeans を参照する可能性があるためです。 この状況を回避するには、次のセクションで説明されているように特定のインターフェースまたは非インターフェース・ビューを実装する各 Enterprise JavaBeans のバインディングを明示的に定義するか、WebSphere 製品の JVM カスタム・プロパティーである com.ibm.websphere.ejbcontainer.disableShortDefaultBindings を定義して、これらの Enterprise JavaBeans を含むアプリケーションの短いデフォルトの従来のバインディングを使用不可にする必要があります。 JVM カスタム・プロパティーの定義について詳しくは、Java 仮想マシンのカスタム・プロパティーについて参照してください。
この JVM カスタム・プロパティーを使用するには、プロパティー名に com.ibm.websphere.ejbcontainer.disableShortFormBinding を設定し、プロパティー値には、ワイルドカード値の * (アスタリスク) を設定してサーバーのすべてのアプリケーションに対して短い形式のデフォルトの従来のバインディングを使用不可にするか、 あるいは、短いデフォルトの従来のバインディングを使用不可にする Java EE アプリケーション名をコロンで区切った文字列 (例えば PayablesApp:InventoryApp:AccountServicesApp) を設定します。
デフォルトの従来のバインディングの 明示的割り当ての影響

java:[scope] 名前空間
java:global、java:app、および java:module の名前空間が、Java EE 6 仕様によって導入されました。 この仕様は、アプリケーション・サーバー間で移植可能な、リソースのバインディングおよび検索のメカニズムを提供します。
サーバーは、常にデフォルトの長い形式のバインディングを非インターフェース・ビューを含む各 EJB インターフェースに対して作成し、java:global、java:app、および java:module の名前空間に配置します。また、Bean が非インターフェース・ビューを含む 1 つのインターフェースしか公開しない場合、短い形式のバインディングも作成されて java:global、 java:app、および java:module の名前空間に配置されます。デフォルト・バインディングは、セッション Bean に対してのみ作成されます。エンティティー Bean またはメッセージ駆動型 Bean に対しては作成されません。
長い形式および短い形式のバインディングの両方には、アプリケーション名、モジュール名、および Bean のコンポーネント名が含まれています。アプリケーション名は、デフォルトで .ear ファイルの拡張子なしのベース名です。アプリケーション名は、application.xml ファイルの application-name エレメントを使用して上書きできます。モジュール名は、デフォルトでモジュールのパス名です。このとき拡張子は削除され、ディレクトリー名が含まれます。モジュール名は、ejb-jar.xml または web.xml ファイルのモジュール名エレメントを使用して上書きできます。Bean コンポーネント名は、デフォルトで Bean クラスの非修飾名です。 Bean コンポーネント名は、アノテーションを定義する EJB コンポーネントの名前属性、または ejb-jar.xml ファイルの ejb-name エレメントを使用して上書きできます。
長い形式のバインディング・パターンは、java:global/<アプリケーション名>/<モジュール名>/<Bean コンポーネント名>!<完全修飾インターフェース名> となります。
短い形式のバインディング・パターンは、java:global/<アプリケーション名>/<モジュール名>/<Bean コンポーネント名> となります。
- java:global/myApp/myModule/MyBeanComponent!com.foo.MyBeanComponentLocalInterface
- java:global/myApp/myModule/MyBeanComponent
- java:app/myModule/MyBeanComponent!com.foo.MyBeanComponentLocalInterface
- java:app/myModule/MyBeanComponent
- java:module/MyBeanComponent!com.foo.MyBeanComponentLocalInterface
- java:module/MyBeanComponent
- @EJB アノテーションで lookup 属性を使用します。例:
@EJB(lookup="java:global/myApp/myModule/MyBeanComponent")
- ejb-jar.xml で lookup-name エレメントを使用します。例:
<lookup-name>java:global/myApp/myModule/MyBeanComponent!com.ibm.MyBeanComponentLocalInterfaces</lookup-name>
- InitialContext オブジェクトで検索を完了します。例:
initialContext.lookup("java:global/myApp/myModule/MyBeanComponent!com.foo.MyBeanComponentLocalInterfaces")
アプリケーション・サーバーによって作成されるデフォルト・バインディングに加え、ユーザーは、java:global、java:app、および java:module の名前空間の参照を定義できます。java:global 名前空間、java:app 名前空間、および java:module 名前空間で定義された参照は、コンポーネント名前空間には入りません。java:global、java:app、または java:module の名前空間で定義される参照は、これらの名前空間から検索または注入する必要があります。コンポーネントの名前空間から検索または注入することはできません。
Bean のコンポーネントは、java:module 名前空間を使用すると、同じモジュールでパッケージされるコンポーネントが使用できる参照を宣言できます。java:app 名前空間を使用すると、同じアプリケーション内の別のモジュールでパッケージされるコンポーネントが使用できる参照を宣言できます。java:global 名前空間を使用すると、別のアプリケーションでパッケージされるコンポーネントが使用できる参照を宣言できます。
java:global、java:app、または java:module 名前空間で同一の名前を使用した参照は、コンポーネントの名前空間で同一の名前を使用した参照が競合する可能性があるように、相互に競合する場合があります。1 つのアプリケーションに対して java:app 名前空間を有効範囲とする参照は、別のアプリケーションに対して java:app 名前空間を有効範囲とする同一の名前の参照と競合しません。 同様に、1 つのモジュールに対して java:module 名前空間を有効範囲とする参照は、別のモジュールに対して java:module 名前空間を有効範囲とする同一の名前の参照と競合しません。
@EJB(name="java:global/env/myBean")
<resource-ref>
<res-ref-name>java:global/env/myDataSource</res-ref-name>
....
</resource-ref>
java:[scope] 名前空間に関する追加の資料については、 Java EE 6 仕様のセクション 5.2.2 と、Enterprise JavaBeans 3.1 仕様のセクション 4.4 を参照してください。
EJB ビジネス・インターフェース、ホーム、および非インターフェース・ビューのユーザー定義バインディング
製品のデフォルト・バインディングを使用せずに、手動でバインディング・ロケーションを割り当てる場合は、EJB モジュール・バインディング・ファイルを使用して、特定のインターフェース、ホーム、および非インターフェース・ビューに対して独自のバインディング・ロケーションを割り当てることができます。また、このファイルを使用して、 モジュール内の 1 つ以上のエンタープライズ Bean 上で、デフォルト・バインディングのコンポーネント ID 部分のみを指定変更することもできます。コンポーネント ID を指定変更することにより、 バインディングを完全にデフォルトにしたり、各インターフェースまたは非インターフェースにバインディング名をすべて指定したりする代わりに、それらの中間の設定を行うことができます。
EJB 3.x モジュールのユーザー定義バインディング情報を指定するには、EJB Java アーカイブ (JAR) ファイルの META-INF ディレクトリー内に ibm-ejb-jar-bnd.xml ファイルを配置します。このファイルの接尾部は XML です。さらに、ローカル・インターフェースまたは非インターフェース・ビューの従来のバインディングを定義する場合は、「ejblocal:」というストリングを名前の前に付けて、そのバインディングが classic JVM 有効範囲 ejblocal: 名前空間にバインドされるようにする必要があります。
- XMI ファイル・フォーマットで宣言されたバインディングおよび拡張は、当該ファイル内のエレメントに接続された固有の ID 番号を明示的に参照する、対応する ejb-jar.xml デプロイメント記述子ファイルの存在に依存します。この方式は EJB 3.0 以降のモジュールでは機能しません。 EJB 3.0 モジュールでは、モジュールに ejb-jar.xml デプロイメント記述子が含まれている必要がなくなりました。
- XMI ファイル・フォーマットは、製品開発ツールおよびシステム管理機能によってのみ機械編集されるように設計されていました。 つまりこれは、事実上製品の内部実装の一部であり、ファイルの構造が外部に対して文書化されることはありませんでした。これにより、開発者はサポートされる方法でバインディング・ファイルを手動で編集したり、それらのファイルを WebSphere から独立したビルド・プロセスとして作成したりすることができませんでした。
- XML ベースのバインディング・ファイルは、ejb-jar.xml デプロイメント記述子内でエンコードされた ID 番号を参照するのではなく、その EJB 名で EJB コンポーネントを参照します。モジュール内の各 EJB コンポーネントには、デフォルトかまたは開発者による 明示的な割り当てのいずれかによって、固有の EJB 名が付けられています。そのため、この動作によってバインディングおよび拡張を明確にターゲットにできます。
- 新規バインディング・ファイルは XML ベースであり、外部に対して構造を文書化するために XML スキーマ定義 (XSD) ファイルが提供されます。これらの .xsd ファイルは、構文検証およびコード完了機能を支援するために、一般的に使用される多くの XML ファイル・エディターによって消費される可能性があります。結果的に、開発者はアプリケーション・サーバー・インフラストラクチャーから独立して、バインディングおよび拡張ファイルを作成したり編集したりすることができるようになっています。
エレメントまたは属性 | 使用方法 | 例 | コメント |
---|---|---|---|
<session> | セッション Bean のバインディング割り当てのグループを宣言します。 | <session name="AccountServiceBean"/> | simple-binding-name 属性、local-home-binding-name 属性、remote-home-binding-name 属性または <interface> エレメントのうち少なくとも 1 つ、および name 属性が必要です。 |
name | <session>、<message-driven>、<entity>、または他のエレメントが適用される エンタープライズ Bean の ejb-name を識別する属性。 | <session name="AccountServiceBean"/> | name 値は ejb-jar.xml デプロイメント記述子ファイルの <ejb-name> エレメントで宣言された名前、@Stateful、@Stateless、@Singleton、または @MessageDriven アノテーションの name 属性、または (XML デプロイメント記述子で <ejb-name> 値が宣言されておらず、アノテーションで name パラメーターが宣言されていない場合) デフォルトで、@Session または @MessageDriven アノテーションでアノテーションを付けられた EJB 実装クラスの修飾されないクラス名になります。 |
component-id | エンタープライズ Bean のデフォルトのコンポーネント ID 値を 指定変更する属性。このエンタープライズ Bean のデフォルトの長い書式の従来のバインディングは、<app_name>/<module_jar_name>/<bean_name> の代わりに、指定されたコンポーネント ID を使用します。 |
上の例では、Bean の ejb-name が AccountServiceBean になり、その長い書式のデフォルトの従来のローカル・インターフェースは、ejblocal:Department549/AccountProcessor#<package.qualified.interface> でバインドされます。長い書式のデフォルトの従来のリモート・インターフェースは、ejb/Department549/AccountProcessor#<package.qualified.interface> でバインドされます。 |
これは単独で使用することも、<interface> エレメント、local-home-binding-name 属性、または remote-home-binding-name 属性と組み合わせて使用することもできます。明示的なバインディングが割り当てられていないインターフェースについては、
ユーザー指定のコンポーネント ID 値を使用してデフォルトの従来のバインディングを実行することもできます。明示的なバインディングが割り当てられているインターフェースは、
それらの値を使用してバインドされます。 simple-binding-name 属性は (インターフェースがデフォルトのままになっていない) 特定のエンタープライズ Bean 上で定義されたすべてのインターフェースに適用されることを意図しているため、一般的に component-id を simple-binding-name と組み合わせて適用することはできません。 |
simple-binding-name | 以下のような Enterprise JavaBeans のインターフェース・バインディングを割り当てる単純な機構。
|
この例では、Bean の ejb-name が AccountServiceBean になり、
そのローカル・ビジネス・インターフェースまたはホームが存在する場合は、従来のローカル JVM 有効範囲 EJB 名前空間にある ejblocal:ejb/AccountService で、リモート・ビジネス・インターフェースまたはホーム (存在する場合) は従来のグローバル有効範囲 JNDI 名前空間のアプリケーション・サーバーのルート・コンテキストにある ejb/AccountService でバインドされます。
重要: 重要:
このインターフェースが ejblocal: 名前空間にバインドされたローカル・インターフェースの場合であっても、属性の正確な値 (この例の「ejb」サブコンテキスト名など) が使用されます。ユーザー定義バインディングが指定されると、
属性によって指定された正確な名前が使用されます。 |
local-home-binding-name または remote-home-binding-name 属性、または <interface> エレメントと組み合わせて使用しないでください。さらに、複数のビジネス・インターフェースを実装する Bean 上では使用しないでください。その場合は、代わりに <interface> エレメントを使用します。 この属性が、複数のビジネス・インターフェースを実装するか、またはビジネス・インターフェースとホームを持つローカル/リモート・コンポーネント・インターフェースとの組み合わせを実装するエンタープライズ Bean 上で使用される場合は、属性値にハッシュまたは番号記号 (# 記号) を追加し、その後に、エンタープライズ Bean 上の各インターフェースまたはホームのいずれか、あるいはそれら両方のパッケージ修飾クラス名を指定することにより、作成されるバインディングが明確になります。しかし、simple-binding-name を使用する代わりに ビジネス・インターフェースごとにバインディングを定義する <interface> エレメントを使用すれば、 このあいまいさを回避することができます。 重要: 重要:
複数のビジネス・インターフェースを実装する Bean 上で simple-binding-name を定義することは、<component-id> を使用して Bean のデフォルト・コンポーネント ID を指定変更することと同じではありません。component-id を使用して定義されたリモート・インターフェースのデフォルト・バインディングは、
(すべてのリモート・インターフェースのデフォルト・バインディングと同様に) EJB コンテキストの下でグループ化されますが、複数のインターフェースを使用する Bean 上で simple-binding-name を誤って使用した結果として EJB コンテナーによって明確化されたリモート・インターフェース・バインディングは、ejb コンテキストの下でグループ化されません。 |
local-home-binding-name | エンタープライズ Bean のローカル・ホームのバインディング・ロケーションを 指定する属性。 |
|
simple-binding-name 属性との組み合わせでは 使用されません。ローカル・ホームは常に従来の JVM 有効範囲名前空間にバインドされる必要があるため、 この値は ejblocal: 接頭部で始まる必要があります。 |
remote-home-binding-name | エンタープライズ Bean のリモート・ホームのバインディング・ロケーションを 指定する属性。 |
|
simple-binding-name 属性との組み合わせでは 使用されません。リモート・ホームは従来の ejblocal: 名前空間にはバインドされないため、 この値は従来の ejblocal: 接頭部で始まることはできません。 |
<interface> | バインディングを特定の EJB ビジネス・インターフェースまたは非インターフェース・ビューに割り当てる <session> エレメントのサブエレメント。simple-binding-name、 local-home-binding-name、および remote-home-binding-name 属性とは対照的に、binding-name パラメーターおよび class パラメーターの両方が必要になります (属性ではなく 別個の XML エレメントが必要な理由は、この区別があるためです)。class パラメーターにより、 バインドされるビジネス・インターフェース・クラスまたは非インターフェース・ビュー・クラスのパッケージ修飾名が指定されます。 |
(<session> エレメント内のサブエレメントとして宣言) |
simple-binding-name 属性との組み合わせでは 使用されません。ローカル・インターフェースおよび非インターフェース・ビューは常に従来の JVM 有効範囲名前空間にバインドされる必要があるため、 このエレメントがローカル・インターフェースまたは非インターフェース・ビューに適用される場合、binding-name 値は ejblocal: 接頭部で始まる必要があります。 |
binding-name | <interface> エレメントを使用してバインドされるビジネス・インターフェースの バインディング・ロケーションを指定する属性。 |
(<session> エレメント内のサブエレメントとして宣言) |
<interface> エレメントと組み合わせることが必要 (そのエレメントでのみ使用)。ローカル・インターフェースは常に従来の JVM 有効範囲名前空間にバインドされる必要があるため、 ローカル・インターフェースに適用される場合、binding-name 値は ejblocal: 接頭部で始まる必要があります。 |
バインディング・ファイルの例 1
<?xml version="1.0" encoding="UTF-8?">
<ejb-jar-bnd xmlns=http://websphere.ibm.com/xml/ns/javaee xmlns:xsi="
http://www.w3.org/2001/XMLSchema-instance "xsi:schemaLocation"=
http://websphere.ibm.com/xml/ns/javaee
http://websphere.ibm.com/xml/ns/javaee/ibm-ejb-jar-bnd_1_0.xsd "version 1.0">
<session name="S01" component-id="Department549/AccountProcessors"/>
<session name="S02" simple-binding-name="ejb/session/S02"/>
<session name="S03">
<interface class="com.ejbs.BankAccountService" binding-name="ejblocal:session/BAS"/>
</session>
</ejb-jar-bnd>
バインディング・ファイルは、以下のようになります。- ejb-name S01 が指定されたセッション Bean にはユーザー定義コンポーネント ID が割り当てられ、その Bean 上のすべてのインターフェースおよび非インターフェース・ビューについて、デフォルトのコンポーネント ID (アプリケーション名/ejb-jar モジュール名/Bean 名) を指定変更します。この Bean 上のローカル・インターフェースおよび非インターフェース・ビューは ejblocal:Department549/AccountProcessors#<package.qualified.interface.name> でバインドされ、リモート・インターフェースは ejb/Department549/AccountProcessors#<package.qualified.interface.name> でバインドされます。
- ejb-name S02 が指定されたセッション Bean は、単一の EJB 3.x
ビジネス・インターフェース、または EJB 3.1 非インターフェース・ビューを持つと想定されます。あるいは、ローカル・ホーム、リモート・ホーム、またはその両方を使用する、EJB 3.0 より前の「コンポーネント」インターフェースを備える場合もあります。ビジネス・インターフェース、またはコンポーネント・インターフェースのホーム (複数の場合あり) は、ejblocal:ejb/session/S02 (ローカルの場合)、または ejb/session/S02 (リモートの場合) にバインドされます。
Bean S02 が 複数のビジネス・インターフェース、またはビジネス・インターフェースおよびホームを持つ場合は、simple-binding-name は不明確になります。この場合、コンテナーは、#<package.qualified.interface.name> を各 Bean のインターフェースの単純なバインディング名 ejb/session/S02 に追加することにより、バインディング割り当てを明確にします。
- ejb-name S03 を使用するセッション Bean 上の EJB 3.x ビジネス・インターフェースまたは EJB 3.1 非インターフェース・ビューである com.ejbs.BankAccountService は、ejblocal:session/BAS でバインドされます。
次のセクションではこの例を 拡張して、XML デプロイメント記述子またはアノテーションを使用して宣言された、さまざまな種類の参照および注入エントリーのターゲットを解決するエレメントを紹介します。
参照および注入ターゲットを解決する ユーザー定義バインディング
前のセクションでは、ビジネス・インターフェース、ホーム、および非インターフェース・ビューに対して ユーザー定義のバインディング名を割り当てる方法を示しました。このセクションでは、 参照、注入ディレクティブ、およびメッセージ駆動型 Bean 宛先に関するリンケージ・ターゲットの解決について説明します。
エレメントまたは属性 | 使用方法 | 例 | コメント |
---|---|---|---|
<jca-adapter> | メッセージ駆動型 Bean へのメッセージの配信に関して、JCA 1.5 アダプターのアクティベーション・スペックおよび message-destination JNDI ロケーションを定義します。 |
|
activation-spec-binding-name 属性が必要です。 対応するメッセージ駆動型 Bean が、<message-destination-link> エレメントを使用してそのメッセージ宛先を識別しない場合、destination-binding-name 属性も必要です。 オプションで activation-spec-auth-alias 属性を組み込むこともできます。 |
<ejb-ref> | @EJB アノテーションまたは ejb-jar.xml デプロイメント記述子内の ejb-ref を使用して宣言された 、ejb-ref 宣言のターゲットを解決します。これにより、コンポーネント有効範囲 java:comp/env 名前空間で宣言された名前と、従来の JVM 有効範囲 ejblocal: または従来のグローバル有効範囲 JNDI 名前空間のターゲット・エンタープライズ Bean の名前との間のリンケージが提供されます。 |
|
name および binding-name 属性が必要です。 |
<message-driven> | メッセージ駆動型 Bean のバインディング割り当てのグループを宣言します。 |
|
name 属性および <jca-adapter> サブエレメントが必要です。 |
<message-destination> | Java EE は、Java EE モジュール・デプロイメント記述子で定義された論理名であるメッセージ宛先の名前を、JNDI 名前空間での実際の名前である特定のグローバル JNDI 名に関連付けます。 これにより、Java EE モジュール・デプロイメント記述子内の <message-destination-ref> エレメント、またはメッセージ宛先を注入する @Resource 注入ディレクティブは、<message-destination-line> エレメントを使用して、宛先論理名でこの message-destination を参照できるようになります。この場合、定義されたそれぞれの message-destination-ref ごとにバインディング・ファイル内に個別の <message-destination-ref> バインディング・エントリーを指定する必要はありません。 |
|
name および binding-name 属性が必要です。 |
<message-destination-ref> | @Resource アノテーションまたは ejb-jar.xml 内の message-destination-ref を使用して宣言された、message-destination-ref 宣言のターゲットを解決します。これにより、コンポーネント有効範囲 java:comp/env 名前空間で宣言された名前と、グローバル JNDI 名前空間のターゲット・リソース環境の名前との間のリンケージが提供されます。 |
|
name および binding-name 属性が必要です。 |
<resource-ref> | @Resource アノテーションまたは ejb-jar.xml 内の resource-ref を使用して宣言された、resource-ref 宣言のターゲットを解決します。これにより、コンポーネント有効範囲 java:comp/env 名前空間で宣言された名前と、グローバル JNDI 名前空間のターゲット・リソースの名前との間のリンケージが提供されます。 |
|
name および binding-name 属性が必要です。 authentication-alias または custom-login-configuration 属性を組み込むことができます。 |
<resource-env-ref> | @Resource アノテーションまたは ejb-jar.xml 内の resource-env-ref を使用して宣言された、resource-env-ref 宣言のターゲットを解決します。これにより、コンポーネント有効範囲 java:comp/env 名前空間で宣言された名前と、グローバル JNDI 名前空間のターゲット・リソース環境の名前との間のリンケージが提供されます。 |
|
name および binding-name 属性が必要です。 |
<env-entry> | ストリング形式で表される指定された値、またはデフォルト初期コンテキストに適用される指定された検索名での JNDI 検索によりアクセス可能なオブジェクトで、環境エントリーを指定変更します。 |
|
name 属性と、value 属性か binding-name 属性のいずれか一方 (両方は指定できません) が必要です。 |
<data-source> | アプリケーションで @DataSourceDefinition アノテーションまたは data-source エレメントを使用して宣言されたデータ・ソース定義、またはモジュール・デプロイメント記述子を、管理対象リソースで指定変更します。 |
|
name および binding-name 属性が必要です。 |
name | ネーミング・ロケーション (一般的には、コンポーネント固有の java:comp/env 名前空間内にあります) を識別する属性。これにより、ejb-ref、resource-ref、resource-env-ref、 message-destination、または message-destination-ref などにおける参照/ターゲット・リンケージの「ソース」サイドが定義されます。 |
|
|
binding-name | 従来の ejblocal: 名前空間または従来のグローバル有効範囲 JNDI 名前空間、あるいは java: グローバル名前空間内のネーミング・ロケーションを識別する属性。これにより、ejb-ref、resource-ref、resource-env-ref、 message-destination、または message-destination-ref などにおける参照/ターゲット・リンケージの「ターゲット」サイドが定義されます。 |
|
|
value | env-entry バインディングに使用する値を指定する属性。 |
|
|
activation-spec-binding-name | メッセージ駆動型 Bean にメッセージを配信するのに使用される JCA 1.5 アダプターに関連付けられた、アクティベーション・スペックの JNDI ロケーションを識別する属性。 |
|
この名前は、WebSphere Application Server に対して定義する JCA 1.5 アクティベーション・スペックの名前と一致する必要があります。 |
activation-spec-auth-alias | JCA リソース・アダプターへの接続の認証に使用される J2C 認証別名の名前を識別する、オプションの属性。 J2C 認証別名は、 JCA リソース・アダプターへの新規接続の作成を認証するために使用されるユーザー ID およびパスワードを指定します。 |
|
この名前は、WebSphere Application Server に対して定義する J2C 許可別名の名前と一致している必要があります。 |
destination-binding-name | メッセージ駆動型 Bean が JNDI 名前空間で JMS 宛先を検索するのに使用する JNDI 名を識別する属性。 |
|
この名前は、WebSphere Application Server に対して定義する JMS キューまたはトピックの名前と一致する必要があります。 |
authentication -alias | <resource-ref> バインディング・エレメントのオプションのサブエレメント。リソース参照が接続ファクトリー用である場合は、オプションの JAAS ログイン構成を指定することができます。この場合は、単純な認証別名の名前を指定します。 |
|
この名前は、WebSphere Application Server に対して定義する JAAS 認証別名の名前と一致している必要があります。 |
custom-login-configuration | <resource-ref> バインディング・エレメントのオプションのサブエレメント。リソース参照が接続ファクトリー用である場合は、オプションの JAAS ログイン構成を指定することができます。この場合は、プロパティーのセット (名前/値のペア) を指定します。 |
|
この名前は、WebSphere Application Server に対して定義する JAAS ログイン構成の名前と一致している必要があります。 |
バインディング・ファイルの例 2
<?xml version="1.0" encoding="UTF-8"?>
<ejb-jar-bnd xmlns="http://websphere.ibm.com/xml/ns/javaee" "xmlns:xsi"=
"http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://websphere.ibm.com/xml/ns/javaee"
"http://websphere.ibm.com/xml/ns/javaee/ibm-ejb-jar-bnd_1_0.xsd version" "1.0">
<session name="S01" component-id="Department549/AccountProcessors"/>
<session name="S02" simple-binding-name="ejb/session/S02"/>
<session name="S03">
<interface class="com.ejbs.BankAccountService"
binding-name="ejblocal:session/BAS"/>
<ejb-ref name="com.ejbs.BankAccountServiceBean/goodBye"
binding-name="ejb/session/S02"/>
<resource-ref name="com.ejbs.BankAccountServiceBean/dataSource"
binding-name="jdbc/Default"/>
</session>
<message-driven name="MO1">
<jca-adapter activation-spec-binding-name="jms/InternalProviderSpec"
destination-binding-name=jms/"ServiceQueue"/>
</message-driven>
<session name="S04" simple-binding-name="ejb/session/S04">
<resource-ref name="ejbs.S04Bean/dataSource"
binding-name="jdbc/Default">
<authentication-alias name="defaultlogin"/>
</resource-ref>
</session>
<session name="S05">
<interface class="com.ejbs.InventoryService"
binding-name="ejb/session/S05Inventory"/>
<resource-ref name="ejbs.S05Bean/dataSource"
binding-name="jdbc/Default">
<custom-login-configuration name="customLogin">
<property name="loginParm1" value="ABC123"/>
<property name="loginParm2" value="DEF456"/>
</custom-login-configuration>
</resource-ref>
</session>
</ejb-jar-bnd>
バインディングは、以下のようになります。- S01、S02、および S03 という名前のセッション Bean に対するビジネス・インターフェース、ホーム、および非インターフェースのバインディングは、前の例と変わりません。
- ejb-name が S03 であるセッション Bean には、以下の 2 つの参照ターゲット
解決バインディングが組み込まれるようになりました。
- ejb-ref バインディングは、java:comp/env/com.ejbs.BankAccountServiceBean/goodBye で定義された EJB 参照を、アプリケーション・サーバーのルート JNDI コンテキスト内の JNDI ロケーション ejb/session/S02 に解決します。クラス com.ejbs.BankAccountServiceBean 内で、「goodBye」という名前のインスタンス変数に @EJB を注入することで、EJB 参照を定義することもできます。注: ejb/session/S02 は、この同じバインディング・ファイルでも定義されたセッション Bean S02 の JNDI ロケーションです。これは、参照が、S02 という名前のセッション Bean を指し示していることを意味します。
- resource-ref バインディングは、java:comp/env/com.ejbs.BankAccountServiceBean/dataSource で定義されたリソース参照を、JNDI ロケーション jdbc/Default に解決します。「dataSource」という名前のインスタンス変数に対して、クラス com.ejbs.BankAccountServiceBean 内の @Resource 注入を行うことでリソース参照を定義することもできます。
- ejb-ref バインディングは、java:comp/env/com.ejbs.BankAccountServiceBean/goodBye で定義された EJB 参照を、アプリケーション・サーバーのルート JNDI コンテキスト内の JNDI ロケーション ejb/session/S02 に解決します。クラス com.ejbs.BankAccountServiceBean 内で、「goodBye」という名前のインスタンス変数に @EJB を注入することで、EJB 参照を定義することもできます。
- バインディングは、ejb-name が M01 であるメッセージ駆動型 Bean に対して定義されます。MDB は、WebSphere Application Server に対して定義された、jms/ServiceQueue という JNDI 名の JMS 宛先から、メッセージを受信します。その際には、WebSphere Application Server に対して jms/InternalProviderSpec という名前で JCA 1.5 アクティベーション・スペックが定義された、JCA 1.5 アダプターを使用します。
- ejb-name が S04 であるセッション Bean は単一のビジネス・インターフェースまたは非インターフェース・ビューを持つと仮定されます。そのインターフェースは、リモートの場合は ejb/session/S04 にバインドされ、ローカルの場合は ejblocal:ejb/session/S04 にバインドされます。名前 java:comp/env/ejbs/S04Bean/dataSource の resource-ref を保持します。 これは、変数 dataSource への @Resource 注入を使用した、クラス ejbs.S04Bean となることもあります。この resource-ref は、JNDI ロケーション jdbc/Default に解決されます。resource-ref は J2C 接続を参照し、WebSphere Application Server で定義された defaultlogin という名前の単純な認証別名を使用してこのリソースに接続します。
- ビジネス・インターフェース・バインディングは、ejb-name が S05 であるセッション Bean によって実装された、クラス名が com.ejbs.InventoryService であるインターフェースに関して定義されます。このインターフェースは「ejblocal:」という接頭部を持たないためリモートであると想定され、従来のグローバル有効範囲名前空間におけるサーバーのルート JNDI コンテキストの ejb/session/S05Inventory でバインドされる場合があります。この Bean によって実装された 他のすべてのビジネス・インターフェースには、デフォルトの従来のバインディングが割り当てられます。この Bean は java:comp/env/ejbs/S05Bean/dataSource という名前の resource-ref (または、クラス ejbs.S05Bean での「dataSource」という名前の変数への @Resource 注入) を持ち、JNDI ロケーション jdbc/Default に解決されます。resource-ref は J2C 接続を参照し、2 つの名前/値のペアを含むカスタム・ログイン構成を使用してこのリソースに接続します。
バインディング・ファイルの例 3
このセクション内で後から示す例では、同じ WebSphere Application Server セル内のアプリケーション・サーバー・インスタンス全体で JNDI 検索を実行するために使用する、EJB 参照バインディングの定義および解決方法について説明します。ここでは 2 つの EJB Bean を使用します。1 つは、simple-binding-name 属性を使用して明示的バインディングを定義する呼び出し先 Bean です。もう 1 つは、@EJB 注入を実行し、関連するバインディング・ファイル内の ejb-ref エレメントを使用して参照を解決する呼び出し元 Bean です。解決された参照は、別のアプリケーション・サーバー・プロセスにある呼び出し先 Bean を指し示すようになります。
ibm-ejb-jar-bnd.xml (呼び出し先 Bean)
<?xml version="1.0" encoding="UTF-8"?>
<ejb-jar-bnd xmlns="http://websphere.ibm.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://websphere.ibm.com/xml/ns/javaee"
"http://websphere.ibm.com/xml/ns/javaee/ibm-ejb-jar-bnd_1_0.xsd" version="1.0">
<session name="FacadeBean" simple-binding-name="ejb/session/FacadeBean"/>
</ejb-jar-bnd>
このバインディング・ファイル・コンテンツでは、ejb-name が「FacadeBean」であるセッション Bean が単一のビジネス・インターフェースを実装すると想定されています。したがって、<interface> サブエレメントの代わりに simple-binding-name 属性を使用できると想定されています。この場合、FacadeBean は、それが配置されるアプリケーション・サーバーのサーバー・ルート JNDI コンテキスト内の ejb/session/FacadeBean でバインドされた、単一のリモート・ビジネス・インターフェースを実装します。コード・スニペット (呼び出し元 Bean)
@EJB(name="ejb/FacadeRemoteRef")
FacadeRemote remoteRef;
try {
output = remoteRef.orderStatus(input);
}
catch (Exception e) {
// Handle exception, etc.
}
このコード・スニペットでは、FacadeRemote タイプの「remoteRef」という名前のインスタンス変数への EJB リソース注入が実行されます。この注入により
「name」パラメーターが指定変更され、ejb-ref 参照名が ejb/FacadeRemoteRef に設定されます。このコードは、注入された参照上でビジネス・メソッドを呼び出します。ibm-ejb-jar-bnd.xml (呼び出し元 Bean)
<?xml version="1.0" encoding="UTF-8"?>
<ejb-jar-bnd xmlns="http://websphere.ibm.com/xml/ns/javaee"
"xmlns:xsi="
"http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://websphere.ibm.com/xml/ns/javaee"
"http://websphere.ibm.com/xml/ns/javaee/ibm-ejb-jar-bnd_1_0.xsd" version="1.0">
<session name="CallingBean">
<ejb-ref name="ejb/FacadeRemoteRef"
binding-name="cell/nodes/S35NLA1/servers/S35serverA1/ejb/session/FacadeBean"/>
</session>
</ejb-bnd-jar>
最終的に、このバインディング・ファイルは、ejb/FacadeRemoteRef という ejb-ref 名を使用して EJB 参照を解決し、
cell/nodes/S35NLA1/servers/S35serverA1/ejb/session/FacadeBean の従来のグローバル有効範囲 JNDI 名を指し示すようにします。この従来のグローバル有効範囲 JNDI 名は、呼び出し元 Bean の WebSphere Application Server セル内の「S35NLA1」というノード上にある「S35serverA1」という名前のサーバーのサーバー・ルート・コンテキストにおける ejb/session/FacadeBean でバインドされたインターフェースを表します。別の WebSphere Application Server セル内のロケーションを指し示すために、標準 JNDI 名の代わりに CORBAName スタイルの名前を使用することができます。ibm-ejb-jar-bnd.xml ファイルの変更方法に関する手順は、トピック『アプリケーション・ファイルの更新方法』に示されています。
注入と参照との関係
注入ディレクティブと 参照宣言との間には 1 対 1 の対応関係が存在します。つまり、すべての注入は暗黙的になんらかのタイプの参照を定義し、その反対にすべての参照はオプションで注入も定義することができます。注入アノテーションは、 参照を XML デプロイメント記述子で定義する代わりに、アノテーションを使用して定義する機構であると考えることができます。
デフォルトでは、注入が参照を定義します。その際に使用される名前は、注入を実行するコンポーネントのパッケージ修飾クラス名、それに続くスラッシュ (/)、さらにその後に続く注入対象の変数またはプロパティーの名前によって構成されます。例えば、「depositService」という名前の変数またはプロパティーに対して、クラス com.ejbs.AccountService 内で注入を実行すると、参照名は java:comp/env/com.ejbs.AccountService/depositService になります。ただし、 注入ディレクティブでオプションの「name」パラメーターを指定するとこのデフォルト名が指定変更され、「name」パラメーターの値に従って参照に名前が付けられます。
このルールを知っておくと、 XML デプロイメント記述子で宣言されている参照のターゲットを解決する場合のみでなく、アノテーション注入ディレクティブによって暗黙的に宣言されている参照のターゲットを解決する場合にも、バインディング・ファイルがどのように使用されるのかを容易に理解できます。注入アノテーションでは「name」パラメーターの値をそのまま使用してください。「name」パラメーターが指定されていない場合には、XML デプロイメント記述子で参照の名前を宣言するときと同じように、クラス名および変数/プロパティー名のデフォルトの参照名の値を使用してください。
EJB 参照および EJB 注入のデフォルトの解決: EJBLink フィーチャーと AutoLink フィーチャー
EJBLink フィーチャーおよび AutoLink フィーチャーは、同じアプリケーションおよびアプリケーション・サーバー・プロセスにおいて参照コンポーネントとしてパッケージ化された、EJB コンポーネントへの参照を解決する 2 つの異なるメカニズムです。EJBLink および AutoLink のいずれを使用しても、バインディング情報で EJB 参照を明示的に解決する必要がなくなります。 EJBLink フィーチャーは EJB 仕様によって定義される一方で、AutoLink フィーチャーは WebSphere Application Server の拡張機能です。
EJBLink フィーチャーおよび AutoLink フィーチャーでは、異なる検索基準を使用してターゲットとなる Bean コンポーネントが検索されます。EJBLink では、明示的に指定された Bean 名を使用して、ターゲットとなる Beanコンポーネントを検索します。AutoLink では、Bean が実装するインターフェースを使用して、ターゲットとなる Bean コンポーネントを検索します。明示的なバインディングがなく、Bean 名のみが提供される場合は、EJBLink フィーチャーが使用されます。明示的なバインディングがなく、Bean 名もない場合は、AutoLink フィーチャーが使用されます。EJBLink フィーチャーおよび AutoLink フィーチャーは、同じ検索プロセスとして併用されることはありません。
EJBLink フィーチャーおよび AutoLink フィーチャーは、検索基準が異なる点を除けば類似の機能です。 いずれのフィーチャーも、最初に特定モジュールを検索してから、必要に応じて同じアプリケーションまたはアプリケーション・サーバー・プロセス内の他のモジュールの検索にフォールバックします。両方のフィーチャーでは、検索基準によってただ 1 つの Bean コンポーネントに解決する必要があるため、検索基準によって複数 Bean コンポーネントに解決された場合はエラー状態として認識されます。エラー状態となるのは、複数 Bean コンポーネントの中で使用するべきコンポーネントがアプリケーション・サーバーによって認識されないためです。この場合、例外 exception com.ibm.websphere.ejbcontainer.AmbiguousEJBReferenceException が発生します。この例外がスローされるのは、参照コンポーネントがターゲットとなる Bean コンポーネントの検索を試みる実行時です。
- Bean コンポーネントの名前のみを指定します。例えば、MyBean です。
- 拡張子を含む物理的なモジュール・ファイルの名前を指定します。これには、ターゲットの Bean コンポーネント、# 記号、Bean コンポーネント名が含まれます。例えば myModule.jar#MyBean です。
- ターゲットの Bean コンポーネント、スラッシュ記号 (/)、Bean コンポーネント名を含むモジュールの論理名を指定します。例えば、MyModule/MyBean です。
オプションで、ejb-jar モジュールの場合は EJB デプロイメント記述子で module-name エレメントを使用して、また EJB コンテンツを含む WAR モジュールの場合は Web デプロイメント記述子ファイルで module-name エレメントを使用して、モジュールの論理名を指定できます。EJB コンテンツを含む WAR モジュールの場合、EJB デプロイメント記述子で指定された module-name エレメントは無視され、Web デプロイメント記述子で指定された module-name エレメントが処理されます。デプロイメント記述子で module-name 値が指定されていない場合は、デフォルトの論理名がモジュールに割り当てられます デフォルトの論理モジュール名は、モジュール・ファイルのベース名から拡張子を削除したものです。例えば、モジュール・ファイル MyModule.jar の デフォルトの論理モジュール名は MyModule になります。
物理モジュール・ファイルの名前の指定は、モジュールに論理名が含まれている場合でもサポートされます。モジュールの論理名の指定は、デプロイメント記述子で論理モジュール名が構成されていなくてもサポートされています。この場合、 モジュールのベース名が、モジュールの論理名として使用されます。
組み込み可能 EJB コンテナーでは、すべての EJBLink 形式がサポートされます。物理モジュール・ファイル・フォーマットをサポートするために、組み込み可能な EJB コンテナーでは同じベース名の複数のモジュールを開始することはできません。
AutoLink は WebSphere Application Server の付加価値フィーチャーであり、これを使用すると、特定の使用シナリオにおいて明示的に EJB 参照ターゲットを解決する必要がなくなります。WebSphere Application Server V8 では、AutoLink は各 WebSphere Application Server プロセスの境界内に実装されます。AutoLink アルゴリズムは、以下のように動作します。
製品に含まれる EJB コンテナーは、特定の EJB モジュール内で EJB 参照を検出すると、モジュールのバインディング・ファイルへのエントリーの取り込みによってその参照のターゲットが明示的に解決されているかどうかを、最初にチェックします。バインディング・ファイル内でそのターゲットが明示的に 解決されていないことが判明した場合、コンテナーは、参照を行うモジュール内を検索して、その参照内でユーザーが定義したインターフェース・タイプまたは非インターフェース・ビューを実装するエンタープライズ Bean を探します。
インターフェースまたは非インターフェース・ビューを実装するモジュール内でただ 1 つの エンタープライズ Bean が検索された場合は、そのエンタープライズ Bean を EJB 参照のターゲットとして使用します。 コンテナーは、 モジュールからそのタイプのエンタープライズ Bean が見つからない場合は、モジュールを含むアプリケーションまで検索有効範囲を拡張して、そのアプリケーション内にある、参照側モジュールと同じアプリケーション・サーバーに割り当てられているその他のモジュールを検索します。この場合にも、参照側モジュールと同じサーバーに割り当てられているアプリケーションの他のモジュール内で、ターゲット・インターフェースまたは非インターフェース・ビューを実装するただ 1 つの エンタープライズ Bean が見つかった場合、コンテナーはそのエンタープライズ Bean を参照ターゲットとして使用します。
AutoLink の有効範囲は、EJB 参照が出現するアプリケーションおよび参照モジュールが割り当てられるアプリケーション・サーバーに制限されます。別のアプリケーション内のエンタープライズ Bean、別のアプリケーション・サーバーに割り当てられたモジュール内のエンタープライズ Bean、または WebSphere Application Server クラスターに割り当てられたモジュールにあるエンタープライズ Bean に対する参照は、EJB モジュールの ibm-ejb-jar-bnd.xml ファイルまたは Web モジュールの ibm-web-bnd.xmi ファイル内の参照ターゲットのバインディングを使用して明示的に解決する必要があります。
AutoLink は、 EJB コンテナー、Web コンテナー、およびアプリケーション・クライアント・コンテナー からサポートされるにもかかわらず、EJB 参照についてのみサポートされ、他のタイプの参照についてはサポートされないことに注意してください。また、AutoLink 機能の有効範囲は、参照モジュールが割り当てられているサーバーに制限されるか、あるいは Java EE クライアント・コンテナーの場合は、クライアント・コンテナーがその JNDI ブートストラップ・サーバーとして構成されているサーバーに制限されているため、AutoLink は、主として開発環境および他のシングル・サーバー使用シナリオで役に立ちます。 これらの制限が存在しますが、EJB 参照の明示的な解決が不要になるため、このフィーチャーは開発過程において非常に有効です。
EJB とリソースの参照と注入の解決: 検索機能
検索機能は、EJB 3.1 の仕様で、明示的な JNDI 名によって EJB またはリソースの参照を解決するメカニズムとして定義されます。lookup 属性は、javax.ejb.EJB アノテーション、または javax.annotation.Resource アノテーションで指定できます。ejb-jar.xml ファイル内の対応する XML 属性は <lookup-name> であり、 エレメント <ejb-ref>、<ejb-local-ref>、<env-entry>、<resource-ref>、<resource-env-ref>、または <message-destination-ref> のいずれかにあります。 lookup または <lookup-name> は、java:comp/env ネーミング・コンテキストに相対的な JNDI 名です。
EJB 参照で、lookup または <lookup-name> を beanName または <ejb-link> と共に指定してはなりません。lookup-name および ejb-link は、管理コンソールに読み取り専用として表示されます。ただし、JNDI 名がアプリケーション・インストール手順「EJB 参照を Bean にマップ」で指定されている場合は、JNDI 名によって lookup-name 値または ejb-link 値がオーバーライドされます。
アプリケーションで定義された環境エントリーのオーバーライド
<env-entry name="name" value="value"/>
ここで、name はアプリケーションに定義された env-entry 名であり、value はストリング形式で表される env-entry に割り当てられた値です。
value のストリングは、値が env-entry-value を使用してデプロイメント記述子に指定された場合のように、環境エントリーのタイプに従って構文解析されます。以下に例を示します。
<env-entry name="java:module/env/taxYear" value="2010"/>
「java:module/env/taxYear」という名前の env-entry を、値「2010」に関連付けます。<env-entry name="name" binding-name="lookupName"/>
ここで、name はアプリケーションに定義された env-entry 名であり、lookupName はデフォルト初期コンテキストでの検索に適用されたときに解決される JNDI 名です。以下に例を示します。
<env-entry name="java:module/env/taxYear" binding-name="cell/persistent/MyApp/MyModule/taxYear"/>
これは、"java:module/env/taxYear" という名前の env-entry を、
"cell/persistent/MyApp/MyModule/taxYear" に対するデフォルト初期コンテキスト検索操作から返される値に関連付けます。
JNDI オブジェクト・バインディングの作成は、ユーザーの責任で行います。
バインドされたオブジェクトのクラスは、関連付けられた env-entry のオブジェクト・タイプに割り当てることが可能でなければなりません。環境エントリーは、EJB、Web、およびクライアントの各モジュールでアプリケーション・レベルで定義できます。 それらのレベルは、バインディング・ファイル application-bnd.xml、ejb-jar-bnd.xml、 web-app-bnd.xml、 および application-client-bnd.xml に対応しています。
データ・ソース定義のオーバーライド
Java EE 6 では、@DataSourceDefinition アノテーションまたは <data-source> デプロイメント記述子エントリーを使用してデータ・ソースを定義するアプリケーションを開発できます。
<data-source name="name" binding-name="lookupName"/>
ここで、name はアプリケーションに定義された env-entry 名であり、lookupName はデフォルト初期コンテキストでの検索に適用されたときに解決される JNDI 名です。以下に例を示します。
<data-source name="java:module/env/myDS" binding-name="jdbc/DB2DS"/>
このようにすると、"java:module/env/myDS" に対する検索が、デフォルト初期コンテキストを基準とする相対名である "jdbc/DB2DS" にバインドされたデータ・ソースに解決されます。
jdbc/DB2DS の下でバインドされたデータ・ソースは、管理コンソールなどで作成できます。データ・ソースは、アプリケーション・レベルで定義することも、EJB、Web、およびクライアントの各モジュールで定義することもできます。 それらのレベルは、バインディング・ファイル application-bnd.xml、ejb-jar-bnd.xml、 web-app-bnd.xml、 および application-client-bnd.xml に対応しています。
クラスター環境および クロス・サーバー環境におけるネーミングの考慮事項
cell/clusters/<cluster-name>/<name-binding-location>
例えば、アプリケーション・サーバー・ルート・コンテキスト内の EJB インターフェース・バインディング・
ロケーションの場合は、以下のようになります。ejb/Department549/AccountProcessors/CheckingAccountReconciler
cell/clusters/Cluster47/ejb/Department549/AccountProcessors/CheckingAccountReconciler
cell/nodes/<node-name>/servers/<server-name>/<name binding location>
この場合にも、アプリケーション・サーバー・ルート・コンテキスト内の EJB インターフェース・バインディング・
ロケーションの場合は、以下のようになります。ejb/Department549/AccountProcessors/CheckingAccountReconciler
cell/nodes/S47NLA1/servers/Server47A1/ejb/Department549/AccountProcessors/CheckingAccountReconciler
ユーザー定義 EJB 拡張設定
WebSphere Application Server EJB 拡張設定の値を指定する場合、EJB モジュール拡張ファイル を使用して、これらの設定を当該モジュール内の特定の EJB タイプに割り当てることができます。定義されている拡張タイプに応じて、2 つのファイルの一方または両方を EJB JAR ファイルの META-INF ディレクトリーに配置することで、EJB 3.x モジュールの拡張設定情報を指定します。 この 2 つのファイルの名前は ibm-ejb-jar-ext.xml および ibm-ejb-jar-ext-pme.xml です。
- xmi ファイル・フォーマットで宣言されたバインディングおよび拡張は、対応する ejb-jar.xml デプロイメント記述子ファイルの存在に従属し、そのファイル内のエレメントに付加された固有の ID 番号を明示的に参照します。この方式は EJB 3.0 以降のモジュールでは機能しません。 EJB 3.0 モジュールでは、モジュールに ejb-jar.xml デプロイメント記述子が含まれている必要がなくなりました。
- xmi ファイル・フォーマットは、WebSphere 開発ツールおよびシステム管理機能によってのみ機械編集されるように設計されていました。つまりこれは事実上 WebSphere の内部実装の一部であり、ファイルの構造が外部に対して文書化されることはありませんでした。 これにより、開発者はサポートされる方法でバインディング・ファイルまたは拡張ファイルを手動で作成または編集したり、それらのファイルを WebSphere から独立したビルド・プロセスとして作成したりすることができませんでした。
- XML ベースの拡張ファイル・フォーマットは、ejb-jar.xml 内でエンコードされた ID 番号を参照するのではなく、その EJB 名で EJB コンポーネントを参照します。モジュール内の各 EJB コンポーネントは、デフォルトかまたは開発者による 明示的な割り当てのいずれかを使用して、固有の EJB 名を持つことを保証されているため、 バインディングおよび拡張を明確なターゲットとすることができます。
- 新規バインディングおよび拡張のファイル・フォーマットは XML ベースであり、外部に対して構造を文書化するために XML スキーマ定義 (xsd) ファイルが提供されます。これらの .xsd ファイルは、構文検証およびコード完了機能を支援するために、一般的に使用される多くの XML ファイル・エディターによってコンシュームされる可能性があります。結果的に、開発者は任意の汎用 XML エディターまたはスクリプト・システムを使用し、WebSphere Application Server インフラストラクチャーから独立して、これらのバインディング・ファイルおよび拡張ファイルの作成や編集を行うことができるようになりました。
META-INF/ibm-ejb-jar-ext.xml で定義される拡張
エレメントまたは属性 | 説明 | 例 | 使用上の注意 |
---|---|---|---|
<session> | セッション Bean の拡張設定のグループを宣言します。 |
|
name 属性が必要です。有効にするには、少なくとも 1 つの拡張設定の定義サブエレメントも指定します。 |
<message-driven> | メッセージ駆動型 Bean の拡張設定のグループを宣言します。 |
|
name 属性が必要です。有効にするには、少なくとも 1 つの拡張設定の定義サブエレメントも指定します。 |
エレメントまたは属性 | 説明 | 例 | 使用上の注意 |
---|---|---|---|
<time-out> | オプションでメソッド呼び出し間の秒数を宣言する、<session> エレメントのサブエレメント。この秒数の経過後、ステートフル・セッション Bean は使用不可になります。 |
|
value 属性が必要です (正整数)。 注: ステートフル・セッション Bean にのみ適用可能です。ステートレス Bean では使用しないでください。
属性のデフォルト: 300 (5 分) |
<bean-cache> | ステートフル・セッション Bean の Bean 活性化/非活性化設定を宣言するために使用する、<session> エレメントのサブエレメント。 |
|
有効にするには、activation-policy 属性も指定します。 |
activation-policy | Bean インスタンスが活性化および非活性化される条件を宣言する、<bean-cache> エレメントの属性。ステートフル・セッション Bean に適用可能です。使用可能な値とその意味は以下のとおりです。
|
|
属性のデフォルト: ステートフル・セッション Bean では ONCE |
エレメントまたは属性 | 説明 | 例 | 使用上の注意 |
---|---|---|---|
<global-transaction> | この特定の EJB タイプにより開始されるトランザクションで使用するトランザクション・タイムアウト (秒単位) を宣言するのに使用できる (グローバル・トランザクション・タイムアウトのサーバー設定がオーバーライドされる)、<session> エレメントおよび <message-driven> エレメントのサブエレメント。異機種混合の Web サービス環境にわたって、この EJB タイプが、Web サービス・アトミック・トランザクション経由で受信したグローバル・トランザクション・コンテキストを伝搬するかどうかも宣言できます。 |
|
少なくとも 1 つの transaction-time-out または send-wsat-context 属性が必要です。 属性のデフォルト: transaction-time-out のサーバー・トランザクション・タイムアウト設定 (send-wsat-context では FALSE) |
<local-transaction> | ローカル・トランザクションに関連する設定を宣言するのに使用できる、<session> エレメントおよび <message-driven> エレメントのサブエレメント。サポートされる属性は boundary、resolver、および unresolved-action です。
これらの属性は、コンポーネントに対して、グローバル・トランザクションが存在しない場合に必ずコンテナーが確立する、そのコンテナーのローカル・トランザクション内包 (LTC) 環境の動作を構成します。
各属性の意味は、次のとおりです。
boundary この設定では、そこに含まれるすべてのリソース・マネージャー・ローカル・トランザクション (RMLT) が完了している必要がある保持境界が指定されます。指定可能な値は、以下のとおりです。
resolver この設定では、RMLT の開始および終了を行うコンポーネントが指定されます。指定可能な値は、以下のとおりです。
unresolved-action この設定は、これらのトランザクションが LTC 境界の有効範囲の最後で未解決であり、resolver が APPLICATION に設定されている場合、コンテナーが RMLT に要求する方向を指定します。
指定可能な値は、以下のとおりです。
|
|
少なくとも 1 つの boundary、resolver、または unresolved-action 属性が必要です。 属性のデフォルト:
|
エレメントまたは属性 | 説明 | 例 | 使用上の注意 |
---|---|---|---|
<method> | 特定の設定を適用できる場合があるメソッド名、メソッド・シグニチャー、またはメソッド・タイプの指定に使用する、<method-session-attribute> エレメントおよび <run-as-mode> エレメントのサブエレメント。サポートされる属性は type、name、および params です。各属性は、以下のようになります。 type
name 設定が適用されるメソッドの名前。名前にかかわらず、設定がすべてのメソッドに適用される場合はアスタリスク (*)。 params 設定が適用されるメソッドのパラメーター・シグニチャー。 複数のメソッドが同じ名前を使用する場合、これを使用して、特定のメソッドを一意的に修飾できます。 パラメーター・シグニチャーは、Java 型のコンマ区切りリストです。 - 基本型は、その名前のみを使用して指定されます。非基本型は、Java パッケージを含むその完全修飾クラスまたはインターフェースの名前を使用して指定されます。Java 型の配列は、1 つ以上の大括弧のペアが続く配列エレメントのタイプで指定されます (int[][] など)。 |
|
|
<run-as-mode> | 特定の EJB メソッドが別のメソッドを呼び出す際に使用するセキュリティー識別を宣言するのに使用できる、<session> エレメントおよび <message-driven> エレメントのサブエレメント。この識別を設定して、呼び出し元の識別 (mode = CALLER_IDENTITY)、EJB サーバーの識別 (mode = SYSTEM_IDENTITY)、または特定のセキュリティー・ロールの識別 (mode = SPECIFIED_IDENTITY) を使用できます。 |
|
mode 属性および <method> サブエレメントが必要です。mode が SPECIFIED_IDENTITY である場合、<specified-identity サブエレメントも必要です。 |
<start-at-app-start> | アプリケーションにより EJB タイプが最初に使用されたときではなく、アプリケーションが最初に始動されたときに、指定された EJB タイプが初期化されることを EJB コンテナーに対して通知するのに使用できる、<session> エレメントおよび <message-driven> エレメントのサブエレメント。 |
|
value 属性が必要です。 属性のデフォルト: メッセージ駆動型 Bean 以外の Bean では FALSE (アプリケーションにより EJB が最初に使用されたときに EJB タイプを初期化)。 メッセージ駆動型 Bean では常に TRUE。 |
<resource-ref> | Java EE リソース参照での追加設定 (参照により、参照される接続経由で駆動されるトランザクションで使用する分離レベルなど) を宣言するのに使用できる、<session> エレメントおよび <message-driven> エレメントのサブエレメント。許可される属性は isolation-level です。
属性は次のように定義されています。 isolation-level
|
|
name 属性が必要です。有効にするには、isolation-level 属性も指定します。 |
META-INF/ibm-ejb-jar-ext-pme.xml ファイルで定義される拡張
エレメントまたは属性 | 説明 | 例 | 使用上の注意 |
---|---|---|---|
<internationalization> | EJB タイプにより使用される場合があるロケール (呼び出し元のロケールまたはサーバーのロケール) を宣言するのに使用できるエレメント。 |
|
この拡張については、『コンテナー国際化対応属性: WebSphere Application Server』を参照してください。 この機能は複雑なため、WebSphere Application Server 用に設計されたツール (Rational® Application Developer など) を使用して目的の拡張ファイル・スタンザを作成し、それから必要に応じて XML ファイルを変更するといいでしょう。 |
<activity-sessions> | 指定されたセッション Bean (BEAN または CONTAINER) で使用されるアクティビティー・セッション管理のタイプ (コンテナー管理アクティビティー・セッションでは、コンテナーにより提供されるアクティビティー・セッション動作のタイプ) をオプションで宣言するエレメント。 |
|
この拡張については、『EJB モジュールの ActivitySession デプロイメント属性の設定』を参照してください。
この機能は複雑なため、WebSphere Application Server 用に設計されたツール (Rational Application Developer など) を使用するといいでしょう。 |
<app-profiles> | 1 つ以上の EJB ファイルのアプリケーション・プロファイル設定をオプションで宣言するエレメント。 |
|
この機能は複雑なため、WebSphere Application Server 用に設計されたツール (Rational Application Developer など) を使用して目的の拡張ファイル・スタンザを作成し、それから必要に応じて XML ファイルを変更するといいでしょう。 |
レガシー (XMI) バインディング
既存の モジュールおよびアプリケーションは、製品で提供されているレガシー・バインディングのサポートを継続して使用できるため、既存のツールおよびウィザードを使用して、アプリケーションおよびモジュールに対するバインディングおよび拡張の情報を指定することができます。レガシー・サポートの使用は、 J2EE 1.4 スタイルの XML デプロイメント記述子を使用する EAR ファイルおよびモジュールに制限されます。
バージョン 3.x XML デプロイメント記述子スキーマを使用する EJB モジュール、または XML デプロイメント記述子ファイルを持たない EJB モジュールは、デフォルト・バインディングと AutoLink、またはユーザー指定の XML バインディング・ファイルのいずれかを使用する必要があります。
既存のツールを使用してマッピング、バインディング、および拡張サポートが提供できるようにするために、CMP エンティティー Bean は常に 2.1 XML デプロイメント記述子スキーマ・バージョンを使用するモジュールにパッケージ化される必要があります。
ユーザー指定 XML バインディング
各インターフェースのデフォルト・バインディングおよび各参照の AutoLink 参照解決は、 META-INF/ibm-ejb-jar-bnd.xml ファイルを作成して EJB モジュール に関するバインディングを指定することによって、指定変更できます。
- <session> エレメントを使用するセッション Bean
- <message-driven> エレメントを使用するメッセージ駆動型 Bean
- id 属性
- name 属性
- simple-binding-name 属性
- component-id 属性
- ejb-ref エレメント
- resource-ref エレメントおよびその属性
- resource-env-ref エレメントおよびその属性
- message-destination-ref エレメントおよびその属性
- env-entry エレメント
- data-source エレメント
- id 属性
- name 属性
- jca-adapter 属性
- ejb-ref エレメントおよびその属性
- resource-ref エレメントおよびその属性
- resource-env-ref エレメントおよびその属性
- message-destination-ref エレメントおよびその属性
- env-entry エレメント
- data-source エレメント