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

アプリケーション・サーバーにインストールしたアプリケーションを開始するには、そのアプリケーションで定義されたすべてのエンタープライズ 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 を持つバインディング定義ファイルが引き続き使用されます。ここで、xxxejb-jarwebapplication、または application-client の場合があります。

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

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

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

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

    アプリケーション開発者は、EJB 3.x および Web 2.5 以降の モジュールの場合は ibm-xxx-bnd.xml ファイル内に、 Java EE 5 より前のモジュールの場合は ibm-xxx-bnd.xmi ファイル内に、 バインディング定義を作成できます。アプリケーション開発者は、これらのファイルを、 IBM® Rational® Developer ツール などのツールを使用するか、または、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 デプロイメント・ツールおよび ejbdeploy コマンドに関する V8.5.5 の資料を参照してください。

EJB 参照
エンタープライズ Bean (EJB) 参照は、エンタープライズ Bean のホーム・インターフェースを検索するために使用される論理名です。EJB 参照はデプロイメント時に指定されます。 実行時に、EJB 参照は、ターゲット操作環境のエンタープライズ Bean の物理ロケーション (グローバル JNDI 名) にバインドされます。 EJB 参照は、java:comp/env/ejb Java ネーミング・サブコンテキストで使用可能になり、参照名が java:modulejava:app、 または java:app 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-nameejb-ref 名と 一致した場合は、その EJB が選択されます。 それ以外では、固有の EJB が、参照 Bean として、一致するホーム (またはローカル・ホーム) インターフェースとともに検出された場合、 その参照は自動的に解決されます。

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

ベスト・プラクティス ベスト・プラクティス: 参照が EJB 2.1 またはそれよりも前のモジュールのものであるか、Web 2.3 またはそれよりも前のモジュールのものであるかを EJB 参照ターゲットが自動的に解決できるようにするには、「アプリケーション・インストールの準備」ページで「デフォルト・バインディングの生成」を選択するか、または「インストール・オプションの選択」、「Bean への EJB 参照をマップ」、または「EJB 参照」コンソール・ページで「EJB 参照ターゲットの自動解決の許可」を選択します。best-practices
リソース参照
リソース参照は、アプリケーション用の外部リソースを検索するために使用される論理名です。 リソース参照はデプロイメント時に指定されます。 実行時に、参照は、ターゲット操作環境のリソースの物理ロケーション (グローバル 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:modulejava:appjava: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 バインディング・ファイルに保管されます。

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

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

メッセージ駆動型 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 名を指定することができます。バージョン 5 デフォルト・メッセージング、WebSphere MQ、または汎用の JMS プロバイダーを使用する場合は、リスナー・ポート名を指定する必要があります。 デフォルト・メッセージング・プロバイダーを使用するか、またはインバウンド・メッセージングをサポートする汎用 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:modulejava: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 つのリソースが競合し、アプリケーション構成アクションが失敗します。

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

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


トピックのタイプを示すアイコン 概念トピック



タイム・スタンプ・アイコン 最終更新: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=crun_app_bindings
ファイル名:crun_app_bindings.html