アプリケーションのバインディング

アプリケーション・サーバーにインストールしたアプリケーションを開始するには、そのアプリケーションで定義されたすべてのエンタープライズ Bean (EJB) 参照およびリソース参照が、アプリケーション・サーバーで定義された実際の成果物 (エンタープライズ Bean またはリソース) にバインドされている必要があります。

バインディングを定義するときには、アプリケーション内の参照可能な成果物および参照される成果物の Java™ Naming and Directory Interface (JNDI) 名を指定します。 成果物に対して指定する jndiName 値は、修飾された検索名である必要があります。 参照可能な成果物の例として、アプリケーションで定義済みの EJB があります。 参照済みの成果物の例として、アプリケーションによって使用される EJB またはリソース参照があります。

バインディング定義は、アプリケーションの ibm-xxx-bnd.xml ファイルまたは ibm-xxx-bnd.xmi ファイルに保管されます。 バージョン 7.0 以降のバインディング定義では、EJB 3.x および Web 2.5 以降のモジュールに対して、接尾部 XML を持つファイルがサポートされます。 Java EE 5 より前のモジュールは、 WebSphere® Application Serverの以前のバージョンと同様に、接尾部 XMI を持つバインディング定義ファイルを引き続き使用します。 ここで、xxx は ejb-jar、web、application、または application-client の場合があります。

バインディングについて詳しくは、以下を参照してください。

バインディングを定義可能な場合

以下の場合にバインディングを定義できます。

  • アプリケーションの開発中

    アプリケーション開発者は、EJB 3.x および Web 2.5 以降の モジュールの場合は ibm-xxx-bnd.xml ファイル内に、 Java EE 5 より前のモジュールの場合は ibm-xxx-bnd.xmi ファイル内に、 バインディング定義を作成できます。 アプリケーション開発者は、 IBM® Rational ® 開発者ツールなどのツールを使用するか、または EJB 3.x または Web 2.5 以降のモジュールの場合は XML エディターまたはテキスト・エディターを使用してファイルを作成できます。 その後、開発者は、 バインディングされたエンタープライズ・ アプリケーション (.ear ファイル) を アプリケーション・アセンブラーまたはデプロイヤーに提供します。 アプリケーションをアセンブルする場合、アセンブラーはバインディングを変更しません。 同様に、 WebSphere Application Serverでサポートされるサーバーにアプリケーションをインストールする場合、アプリケーションを正常にデプロイするためにバインディングの変更が必要でない限り、デプロイヤーはバインディングを変更またはオーバーライドしたり、デフォルト・バインディングを生成したりしません。

  • アプリケーションのアセンブルの期間中

    アプリケーション・アセンブラーは、 アプリケーションのアノテーションまたはデプロイメント記述子でバインディングを定義することができます。 Java EE 5 以降のモジュールには、ソース・コードにアノテーションが含まれています。 アノテーションを宣言するには、アプリケーション・アセンブラーでキーワードの前に 文字 @ (「場所」記号) を付けます。 事前 Java EE 5 モジュールのバインディングは、 デプロイメント記述子エディターの「WebSphere バインディング」セクションで指定します。 デプロイメント記述子を変更すると、 アプリケーションのデプロイ時に 作成された ibm-xxx-bnd.xmi ファイル 内のバインディング定義も、変更される場合があります。 バインディングの定義後、 アセンブラーはアプリケーションをデプロイヤーに渡します。 WebSphere Application Serverでサポートされるサーバーにアプリケーションをインストールする場合、アプリケーションをデプロイするためにバインディングに対する変更が必要でない限り、デプロイヤーはバインディングを変更またはオーバーライドしたり、デフォルト・バインディングを生成したりしません。

  • アプリケーションのインストール中

    アプリケーション・デプロイヤーまたはサーバー管理者は、管理コンソールを使用して WebSphere Application Server でサポートされるサーバーにアプリケーションをインストールするときに、バインディングを変更することができます。 新規バインディング定義は、インストール・ウィザード・ページで指定することができます。

    さらに、デプロイヤーまたは管理者は、アプリケーションのインストール時にデフォルト・バインディングを生成するという選択もできます。 アプリケーションのインストール時に「デフォルト・バインディングの生成」を選択すると、アプリケーションの不完全なバインディングにはデフォルトの値を入力するよう製品に指示することになります。 既存のバインディングは変更されません。

    制約事項: アプリケーション・クライアントのアプリケーション・インストール中にバインディングを定義したりオーバーライドしたりすることはできません。 アセンブリー中にアプリケーション・クライアント・モジュールのバインディングを定義し、そのバインディングを ibm-application-client-bnd.xmi ファイルに保管する必要があります。
  • インストール済みアプリケーションの構成 中

    アプリケーションが WebSphere Application Serverでサポートされるサーバーにインストールされた後、アプリケーション・デプロイヤーまたはサーバー管理者は、 エンタープライズ・アプリケーションの設定ページからアクセスされるような管理コンソール・ページの値を変更することによって、バインディングを変更することができます。

必要なバインディング

アプリケーションを正常にデプロイするには、以下の成果物への参照に対してバインディングを定義する必要があります。

EJB JNDI 名
EJB 2.1 以前の各エンタープライズ Bean (EJB) に、JNDI 名を指定する必要があります。 その名前は、EJB ホーム・オブジェクトのグローバル JNDI 名前空間にエントリーをバインドするために使用されます。 例えば、Store アプリケーションの Product EJB に対する JNDI 名は、store/ejb/Product になります。 バインディング定義は、META-INF/ibm-ejb-jar-bnd.xmi ファイルに保管されます。

アプリケーションのインストール時に、デプロイヤーが デフォルト・バインディングの生成を選択した場合は、 インストール・ウィザードにより、prefix/EJB_name という 書式を持つ EJB JNDI 名が、 不完全なバインディングに割り当てられます。 デフォルトの接頭部は ejb ですが、オーバーライドすることができます。 EJB_name は、 デプロイメント記述子の <ejb-name> タグと同様に指定します。

アプリケーションのインストール時およびその後に、「Bean の JNDI 名を指定」ページで EJB JNDI 名を指定できます。 インストール後に、管理コンソールで「 アプリケーション > アプリケーション・タイプ > WebSphere エンタープライズ・アプリケーション > application_name > EJB JNDI 名 」をクリックします。

EJB コンテナーがデフォルト・バインディングを割り当てるため、エンタープライズ Bean 上で各 EJB 3.x ホームまたはビジネス・インターフェースごとに JNDI バインディング名を指定する必要はありません。

エンティティー Bean のデータ・ソース
コンテナー管理パーシスタンス (CMP) Bean などのエンティティー Bean は、パーシスタント・データをデータ・ストアに保管します。 CMP Bean の場合は、EJB コンテナーが Bean の永続状態を管理します。 EJB モジュールまたは個々のエンタープライズ Bean をデータ・ソースにバインディングすることにより、どのデータ・ストアを Bean が使用するかを指定します。 EJB モジュールをデータ・ソースにバインディングすると、そのモジュール内のすべてのエンティティー Bean が、パーシスタンスに対して同一のデータ・ソースを使用するようになります。

例えば、Store アプリケーションの Store データ・ソースに対する JNDI 名は、store/jdbc/store になります。 Java EE 5 より前のモジュールの場合は、バインディング定義は ibm-ejb-jar-bnd.xmi などの IBM バインディング・ファイルに保管されています。 デプロイヤーは、認証がコンテナーで処理されるか、またはアプリケーション・レベルで処理されるかを指定できます。

WebSphere Application Server バージョン 8.x は、EJB 2.x または 1.x モジュールで CMP Bean をサポートします。 バージョン 8.x では、EJB 3.0 モジュールの CMP Bean はサポートされません。

アプリケーションのインストール時に、デプロイヤーがデフォルト・バインディングの生成を選択した場合は、インストール・ウィザードにより、不完全なバインディングに対して以下のバインディングが生成されます。

  • EJB 2.x .jar ファイルの場合、指定された JNDI 名および権限情報を基にした接続ファクトリー・バインディング
  • EJB 1.1 .jar ファイルの場合、指定された JNDI 名、データ・ソースのユーザー名、およびパスワードを基にしたデータ・ソース・バインディング

生成されたバインディングにより、インストールされるアプリケーションの各 EJB 2.x .jar ファイルに対してはデフォルトの接続ファクトリーが、さらに各 EJB 1.1 .jar ファイルに対してはデフォルトのデータ・ソースが、設定されます。 Bean レベルの接続ファクトリーのバインディングまたはデータ・ソースのバインディングは、デフォルトのバインディング生成中に提供されるカスタム・ストラテジー・ルールで指定されていない限り、生成されません。

アプリケーションのインストール時およびその後に、「2.x CMP Bean データ・ソース」ページおよび「2.x エンティティー Bean データ・ソース」ページで、データ・ソースを 2.x エンティティー Bean にマップすることができます。 インストール後に、管理コンソールで「 アプリケーション > アプリケーション・タイプ > WebSphere エンタープライズ・アプリケーション > application_name 」をクリックし、 「2.x CMP Bean データ・ソース または 2.x エンティティー Bean データ・ソース」を選択します。 「すべての 1.x CMP Bean のデータ・ソースをマップ」ページおよび「1.x エンティティー Bean が含まれたモジュールのデフォルトのデータ・ソース・マッピングの提供」ページで、データ・ソースを 1.x エンティティー Bean にマップすることができます。 インストール後に、1.x CMP Bean に対するリンクをクリックする点を除いて 2.x CMP Bean の場合と同様のコンソール・ページを使用します。

EJB モジュールのバックエンド ID
CMP Bean を定義する EJB .jar ファイルに、 複数のバックエンド・データベースのマッピングが含まれている場合は、 実行時にロードするパーシスター・クラスを決定するために、 適切なバックエンド ID を指定してください。

アプリケーションのインストール時に、 バックエンド ID を指定します。 アプリケーションをサーバーにインストールした後では、バックエンド ID を選択できません。

個々の EJB モジュールのバックエンド ID を使用可能にするには、以下のステップを実行します。

  1. アプリケーションのインストール中に、 「インストール・オプションの選択」 ページで 「エンタープライズ Bean のデプロイ」 を選択します。 「エンタープライズ Bean のデプロイ」を選択すると、「EJB デプロイを行うためのオプションの提供」ページにアクセスできます。
  2. 「EJB デプロイを行うためのオプションの提供」ページで、データベース・タイプを "" (NULL) に設定します。

アプリケーションのインストール時に、「インストール・オプションの選択」ページで「エンタープライズ Bean のデプロイ」を選択し、「EJB デプロイを行うためのオプションの提供」ページで EJB デプロイメント・ツールにデータベース・タイプを指定すると、すべての EJB モジュールに対して事前に定義されていたバックエンド ID が、選択したデータベース・タイプによって上書きされます。

デフォルトのデータベース・タイプは DB2UDB_V81 です。

EJB デプロイメント・ツールは、EJB 3.0 以降のモジュールのインストール時には実行されません。

EJB 参照
エンタープライズ Bean (EJB) 参照は、エンタープライズ Bean のホーム・インターフェースを検索するために使用される論理名です。 EJB 参照はデプロイメント時に指定されます。 実行時に、EJB 参照は、ターゲット操作環境のエンタープライズ Bean の物理ロケーション (グローバル JNDI 名) にバインドされます。 EJB参照は、 java:comp/env/ejb Javaネーミング・サブコンテキストで利用可能になります。参照名が java:module、 java:app、 java:global URL の場合は、別の java: ネームスペースで利用可能になります。 URL 名を持つ EJB 参照は、URL に従って、対応する名前空間内にバインドされます。

製品により、不完全な EJB 3.0 参照ターゲット用のデフォルト JNDI 値が割り当てられるか、または自動的に解決されます。

各 EJB 2.1 または以前の EJB 参照の場合は、JNDI 名を指定する必要があります。 例えば、Store アプリケーションの Supplier EJB 参照に対する JNDI 名は、store/ejb/Supplier になります。 バインディング定義は、ibm-ejb-jar-bnd.xmi などの IBM バインディング・ファイルに保管されます。 参照された EJB が同一のアプリケーション・サーバーにもデプロイされた場合、サーバーを有効範囲とした JNDI 名を指定できます。 ただし、参照された EJB が別のアプリケーション・サーバーにデプロイされた場合、または ejb-ref がアプリケーション・クライアント・モジュールに定義されている場合は、グローバルなセルを有効範囲とした JNDI 名を指定する必要があります。

アプリケーションのインストール時に、デプロイヤーがデフォルト・バインディングの生成を選択した場合は、インストール・ウィザードにより、以下のように EJB 参照がバインドされます。<ejb-link> が検出された場合は、それに従います。 アプリケーションで 定義された EJB の ejb-name が ejb-ref 名と 一致した場合は、その EJB が選択されます。 それ以外では、固有の EJB が、参照 Bean として、一致するホーム (またはローカル・ホーム) インターフェースとともに検出された場合、 その参照は自動的に解決されます。

アプリケーションのインストール時およびその後に、「EJB 参照を Bean にマップ」ページで EJB 参照 JNDI 名を指定することができます。 インストール後に、管理コンソールで「 アプリケーション > アプリケーション・タイプ > WebSphere エンタープライズ・アプリケーション > application_name > EJB 参照 」をクリックします。

ヒント: 参照が EJB 2.1 以前のモジュールまたは Web 2.3 以前のモジュールからのものである場合に、EJB 参照ターゲットが自動的に解決されるようにするには、 アプリケーション・インストールの準備 ページで デフォルト・バインディングの生成 を選択するか、 インストール・オプションの選択、 EJB 参照を Bean にマップ、または EJB 参照 コンソール・ページで EJB 参照ターゲットの自動解決を許可する を選択します。
リソース参照
リソース参照は、アプリケーション用の外部リソースを検索するために使用される論理名です。 リソース参照はデプロイメント時に指定されます。 実行時に、参照は、ターゲット操作環境のリソースの物理ロケーション (グローバル JNDI 名) にバインドされます。 以下のようにして JNDI 名に URL を使用しないリソース参照を使用可能にできます。
表 1. リソース参照サブコンテキスト。 JNDI java:comp/env 名は、リソース参照サブコンテキストに使用されます。
リソース参照タイプ サブコンテキストが宣言される場所
Java DataBase Connectivity (JDBC) データ・ソース java:comp/env/jdbc
JMS 接続ファクトリー java:comp/env/jms
JavaMail 接続ファクトリー java:comp/env/mail
Uniform Resource Locator (URL) 接続ファクトリー java:comp/env/url

または、アプリケーションはリソース参照に対し、java:module、java:app、java:global などの接頭部付き java: URL の名前を割り当てることができます。 これらの URL は、コンポーネント名前空間 (この名前空間は java:comp/env 名前バインディングを含んでいる) 以外の名前空間にマップされます。 URL 名を持つリソース参照は、その URL に応じて、対応する名前空間にバインドされます。

それぞれのリソース参照に対し、JNDI 名を指定する必要があります。 アプリケーションのインストール時にデプロイヤーがデフォルト・バインディングの生成を選択した場合、インストール・ウィザードは、 java:comp/env 名がリソース・グローバル JNDI 名と同じであると想定して、 <res-ref-name> タグから派生したリソース参照バインディングを生成します。

アプリケーションのインストール時に、「リソースへのリソース参照をマップ」ページで、リソース参照 JNDI 名を指定することができます。 リソース参照に定義された論理名を表す JNDI 名をリソースに指定します。 リソースのログイン構成名および認証プロパティーをオプションで指定することができます。 認証プロパティーを指定した後に、「OK」をクリックして値を保存し、 マッピングのステップに戻ります。 アプリケーションで定義された各リソース参照は、 WebSphere Application Server 構成で定義されたリソースにバインドされている必要があります。 インストール後に、管理コンソールで 「アプリケーション」 > 「アプリケーション・タイプ」 > WebSphere エンタープライズ・アプリケーション」 > application_name > 「リソース参照」 をクリックして、 「リソース参照」 ページにアクセスします。

Web モジュールの仮想ホスト・バインディング
各 Web モジュールを指定の仮想ホストにバインドする必要があります。 このバインディングにより、仮想ホストにマッチングするすべての要求は Web アプリケーションにより処理される必要があることが、Web サーバー・プラグインに対して、通知されます。 例えば、Store Web アプリケーションにバインドされる仮想ホストは、store_host になります。 バインディング定義は、WEB-INF/ibm-web-bnd.xmi などの IBM バインディング・ファイルに保管されます。

アプリケーションのインストール時にデプロイヤーがデフォルト・バインディングの生成を選択した場合、インストール・ウィザードは仮想ホストを以下のように設定します。default_host.war ファイルごとに。

アプリケーションのインストール時およびその後に、アプリケーションで定義された Web モジュールに仮想ホストをマップすることができます。 「Web モジュールの仮想ホストをマップ」 ページで、仮想ホストを指定します。 仮想ホスト定義で指定されたポート番号は、Web モジュール内のサーブレットや JavaServer Pages (JSP) ファイルなどの成果物にアクセスするために URL で使用されます。 例えば、JSP ファイルなどの Web 成果物に対する外部 URL は、http://host_name:virtual_host_port/context_root/jsp_path になります。 インストール後、管理コンソールで ［アプリケーション ］>［ アプリケーションの種類 ］ >［ WebSphere エンタープライズアプリケーション ］>［ アプリケーション名 ］>［ バーチャルホスト ］をクリックします。

メッセージ駆動型 Bean
メッセージ駆動型 Bean ごとに、Bean が listen するキューまたはトピックを指定する必要があります。 メッセージ駆動型 Bean は、Java Messaging Service (JMS) リスナーがモニターしている入力キューにメッセージが到着すると、JMS リスナーによって呼び出されます。 デプロイヤーは、アセンブリー・ツール EJB デプロイメント記述子エディターの「Bean」ページにある「 WebSphere バインディング 」の下のコネクター・モジュール (.rar ファイル) で定義されている、アクティベーション・スペックのリスナー・ポートまたは JNDI 名を指定します。 例えば、Store アプリケーションが 使用するリスナー・ポートに対する JNDI 名は、 StoreMdbListener になります。 バインディング定義は、ibm-ejb-jar-bnd.xmi などの IBM バインディング・ファイルに保管されます。
アプリケーションのインストール時に、デプロイヤーがデフォルト・バインディングの生成を選択した場合は、インストール・ウィザードにより、不完全なバインディングに JNDI 名が割り当てられます。
  • JCA 1.5 準拠リソースとしてデプロイされた EJB 2.0 またはそれ以降のメッセージ駆動型 Bean の場合は、インストール・ウィザードにより、activationSpec インスタンスに対応する JNDI 名が eis/MDB_ejb-name という書式で割り当てられます。
  • リスナー・ポートに対してデプロイされた EJB 2.0 またはそれ以降のメッセージ駆動型 Bean の場合は、 リスナー・ポートはメッセージ 駆動型 Bean の <ejb-name> タグから 派生し、ストリング Port が付加されます。

管理コンソールを使用したアプリケーションのインストール時に、「メッセージ駆動型 Bean のリスナーをバインド」ページ上で、すべてのメッセージ駆動型 Bean に対して、リスナー・ポート名またはアクティベーション・スペック JNDI 名を指定することができます。 JMS プロバイダー (バージョン 5 のデフォルト・メッセージング、 WebSphere MQ、または汎用) を使用する場合は、リスナー・ポート名を指定する必要があります。 デフォルト・メッセージング・プロバイダーを使用するか、またはインバウンド・メッセージングをサポートする汎用 J2C リソース・アダプターを使用してアプリケーションのリソースを構成する場合、アクティベーション・スペックを指定する必要があります。 どちらも指定されていない場合は、「要約」ページで「終了」をクリックすると、 検証エラーが表示されます。

アプリケーションのインストール後に、 リソース > JMS とは > JMS プロバイダー または リソース > リソース・アダプターの下のコンソール・ページで JNDI 名を指定し、メッセージ駆動型 Bean を構成することができます。

制約事項: EJB 3.0 以降のモジュールで定義されているメッセージ駆動型 Bean のみをアクティベーション・スペックにバインドできます。
メッセージ宛先参照
メッセージ宛先参照は、メッセージ宛先として機能する EJB モジュール内のエンタープライズ Bean を検索するために使用される論理名です。 メッセージ宛先参照は、以下の J2EE 1.4 およびそれ以降の成果物内にのみ存在します。
  • J2EE 1.4 アプリケーション・クライアント
  • EJB 2.1 プロジェクト
  • 2.4 Web アプリケーション

複数のメッセージ宛先参照が単一のメッセージ宛先リンクに関連付けされている場合、メッセージ宛先リンク、次にリンクされたすべてのメッセージ宛先参照にマップされるエンタープライズ Bean の単一の JNDI 名が、デプロイメント中に収集されます。 実行時に、メッセージ宛先参照は、ターゲット操作環境の管理メッセージ宛先にバインドされます。

メッセージ宛先参照とメッセージ駆動型 Bean が同じメッセージ宛先にリンクされている場合、参照および Bean の両方ともが同じ宛先 JNDI 名である必要があります。 両方が同じ名前の場合、メッセージ駆動型 Bean の宛先 JNDI 名だけが収集され、対応するメッセージ宛先参照に適用されます。

アプリケーションのインストール時に、デプロイヤーがデフォルト・バインディングの生成を選択した場合は、インストール・ウィザードにより、以下のように JNDI 名が不完全なメッセージ宛先参照に割り当てられます。メッセージ宛先参照に <message-destination-link> がある場合、JNDI 名は ejs/message-destination-linkName に設定されます。 それ以外の場合、JNDI 名は eis/message-destination-refName に設定されます。

アプリケーション内の参照およびアプリケーションで使用される成果物によっては、他の参照および成果物に対してバインディングを定義しなければならないこともあります。

アプリケーション・リソースの競合

本製品のバージョン 8 より前では、参照や環境エントリーなどのアプリケーション定義リソースは、java:comp/env に対して相対的なコンポーネント名前空間にバインドされていました。 バージョン 8.0 以降では、アプリケーション開発者は、リソースに対して、 java:module、java:app、 または java:global という接頭部の付いた java: URL である名前を割り当てることができます。 これらの各 URL は、コンポーネント名前空間とは異なる別個の名前空間に解決されます。 1 つのモジュール内のすべてのコンポーネントは 1 つの java:module 名前空間 を共有し、1 つのアプリケーション内のすべてのモジュールは 1 つの java:app 名前空間を共有し、 1 つのセル内のすべてのアプリケーションは 1 つの java:global 名前空間を 共有します。 これらの名前空間は共有されるため、複数の異なるリソースに同じ名前が割り当てられた場合には、競合が発生することがあります。

モジュール有効範囲での競合は、モジュール内の 2 つのコンポーネントが同じ名前でリソースを定義した場合にのみ発生する可能性があります。 この有効範囲は規模が小さいため、モジュールで実際の競合が発生する可能性はまずありません。 ただし、同じリソース定義のインスタンスが複数存在する場合には、それらの構成が同じでなければなりません。 例えば、特定の EJB タイプに対する 2 つの EJB 参照の両方に同じ java:module 名が割り当てられている場合、これらの EJB 参照はともに、同じバインディング・データを使用して構成されている必要があります。 そうでないと、2 つのリソースが競合し、アプリケーション構成アクションが失敗します。

アプリケーションを有効範囲とするリソースは、モジュールを有効範囲とするリソースの場合と似ています。 唯一の違いは、アプリケーション内の任意のモジュールから定義が生成される可能性があることです。 モジュールを有効範囲とするリソースと同様に、同じ名前を持つ、有効範囲がアプリケーションであるすべてのリソースは、同じリソース・タイプでなければならず、同じバインディング・データで構成されている必要があります。

グローバルな有効範囲のリソースは、アプリケーションおよびモジュールを有効範囲とするリソースとは違って、異なるアプリケーション間で競合が 発生する可能性があります。 競合が発生した場合、リソースが論理的に同じではない場合、競合するアプリケーションが共存することはできません。 グローバルな有効範囲のリソースが複数出現し、そのすべてが論理的に同じリソースを識別する場合、製品がそれを競合として検出しないようにするには、それらのリソースが同じバインディング・データで構成されている必要があります。 グローバルな有効範囲のリソースが複数のアプリケーション用に複数存在する場合、そのリソースを編集するには、競合が発生しないようにするために、定義するアプリケーションのすべてを同じセッションで編集する必要があります。 そのようにしないと、セッションの保存時に障害が発生します。