デプロイメント記述子およびシン・クライアントにおける検索名のサポート
エンタープライズ Bean (EJB) ホームなどのサーバー・アプリケーション・オブジェクトは、アプリケーションがインストールされているサーバーのサーバー・ルート・コンテキストを基準にしてバインドされています。 リソースなどの他のオブジェクトも、特定のサーバー・ルートにバインドすることができます。これらのオブジェクトを検索するために使用される名前は、正しいサーバー・ルートが選択されるよう修飾されている必要があります。 このトピックでは、相対名および修飾名とは何か、いつそれらを使用できるのか、それらをどのように構成できるのかについて説明します。
バージョン 8.0 から、 EJB ホームは java:global/appName/moduleName/beanName という名前でバインドされています。 その形式の名前はトポロジー・ベースではなく、既に完全修飾となっています。 同様に、java:global、java:app、または java:module と いう名前を使用してバインドされたすべてのアプリケーション・リソースには、java:global、 java:app、または java:module 検索名の指定時に 追加の修飾は必要ありません。アプリケーション・リソースには、例えば、EJB 参照、 リソース参照、環境エントリーなどがあります。
相対名
すべての名前は、コンテキストを基準にしています。このため、名前空間のあるコンテキストから解決できる名前は、必ずしも名前空間の別のコンテキストから解決できるとは限りません。システムは、 アプリケーションがインストールされているサーバーのサーバー・ルート・コンテキストを基準にした名前でオブジェクトをバインドするため、この点は非常に重要です。各サーバーには、独自のサーバー・ルート・コンテキストがあります。デフォルトでは、Java™ Naming and Directory Interface (JNDI) の初期コンテキストは、初期コンテキストの取得に使用されるプロバイダー URL によって識別されるサーバーの、サーバー・ルート・コンテキストです。 (一般的に、URL はホストおよびポートで構成されています。)サーバー・プロセスで実行されているアプリケーションの場合、JNDI のデフォルトの初期コンテキストは、そのサーバーのサーバー・ルートです。ターゲット・オブジェクトを含むサーバーから初期コンテキストが取得される場合、相対名は正常に解決されますが、別のサーバーから取得された初期コンテキストからは正常に解決されません。
サーバー・アプリケーションのすべてのクライアントが、アプリケーションと同じサーバー・プロセスで実行されている場合、そのアプリケーションに関連付けられているすべてのオブジェクトは、クライアントの初期コンテキストと同じ初期コンテキストにバインドされます。この場合、これらのサーバー・オブジェクトにアクセスするには、サーバーのサーバー・ルート・コンテキストを基準にした名前のみが必要となります。ただし、サーバー・アプリケーションが、そのアプリケーションのサーバー・プロセスの外部で稼働するクライアントを持つ場合があります。これらのクライアントの初期コンテキストは、サーバー・アプリケーションの初期コンテキストと異なる場合があり、サーバー・オブジェクトの相対名の検索に失敗する可能性があります。これらのクライアントは、サーバー・オブジェクトの修飾名を使用する必要があります。Java Platform, Enterprise Edition (Java EE) クライアント・アプリケーションのデプロイメント記述子に jndiName の値をセットアップする場合、およびシン・クライアントで検索名を構成する場合は、この点を考慮する必要があります。 修飾名は、セル内の初期コンテキストから正常に解決します。
修飾名
すべての名前は、コンテキストを基準にしています。ここで、修飾名 という用語は、セル内のいずれかの初期コンテキストから解決できる名前を示します。このアクションを行うには、同一のコンテキストであるセル・ルートにナビゲートする名前を使用します。このため、修飾名の残りは、セル・ルートを基準としたものになり、セル全体を通じてオブジェクトを一意に識別します。サーバー内のすべての初期コンテキスト (つまり、初期参照として ORB に登録されているサーバー内のすべてのネーミング・コンテキスト) には、cell という名前とのバインディングが含まれており、この名前はセルのルート・コンテキストにリンク・バックしています。すべての修飾名は、cell/ というストリングで始まり、現在の初期コンテキストからセルのルート・コンテキストに戻ります。
オブジェクトの修飾名は、セル全体で同一です。この名前は、トポロジーをベースにするか、またはセルのパーシスタント・ルートの下でバインドされている何らかの固定名にします。トポロジー・ベースの名前 (このセクション内で後で詳細に説明します) は、システムの名前空間を経て、ターゲット・オブジェクトにナビゲートします。セルのパーシスタント・ルートにバインドされている固定名は、セル全体を通じて同じ修飾名を持ち、トポロジーには依存しません。サーバー・アプリケーション・オブジェクトのセル・パーシスタント・ルートの下に固定名を作成する場合は、サーバー・アプリケーションのインストール時に追加のステップが必要になりますが、このステップを行うことにより、アプリケーションがセル・トポロジー内の別のロケーションに移動されても、クライアントは影響を受けることがなくなります。 固定名の作成プロセスについても後述します。
一般的に、Java EE クライアント・アプリケーションのデプロイメント記述子の EJB jndiName 値、およびシン・クライアントの EJB 検索名には、修飾名を使用する必要があります。 唯一の例外は、ターゲット・オブジェクトが存在しているサーバーから初期コンテキストが取得された場合です。例えば、Entity Bean にとってクライアントである Session Bean は、 これらの 2 つの Bean が同じサーバーで実行されている場合には、相対名を使用できます。 Session Bean と Entity Bean が異なるサーバーで実行されている場合、Entity Bean の jndiName は、Session Bean のデプロイメント記述子内で修飾されている必要があります。同じ要件は、リソースについても同様に当てはまりますが、これはリソースの有効範囲に依存します。
- トポロジー・ベースの名前
セルの名前空間内のシステムの名前空間区画は、セルのトポロジーを反映しています。この構造は、セルの名前空間にバインドされている任意のオブジェクトまでナビゲートできます。トポロジー・ベースの修飾名には、セル内のオブジェクトの場所を反映するトポロジーのエレメントが含まれています。
EJB ホームなどのシステム・バインド・オブジェクトの場合、トポロジー・ベースの修飾名の形式は、そのオブジェクトが単一サーバーにバインドされているのか、またはクラスターにバインドされているのかによって異なります。両方の形式を、次に説明します。
- 単一サーバー
- 単一サーバー内でバインドされているオブジェクトは、以下の形式のトポロジー・ベースの修飾名を持ちます。
ここで 、nodeName と serverName は、オブジェクトがバインドされているサーバーのノード名と サーバー名で、relativeJndiName は、オブジェクトの非修飾名です。 つまり、そのサーバーのサーバー・ルート・コンテキストに対して相対であるオブジェクトの名前です。cell/nodes/nodeName/servers/serverName/relativeJndiName
- サーバー・クラスター
- サーバー・クラスター内でバインドされているオブジェクトは、以下の形式のトポロジー・ベースの修飾名を持ちます。
ここで、clusterName は、オブジェクトがバインドされているサーバー・クラスターの名前です。relativeJndiName は、オブジェクトの非修飾名です。つまり、クラスター・メンバーのサーバー・ルート・コンテキストを基準にしたオブジェクトの名前です。cell/clusters/clusterName/relativeJndiName
- 固定名
修飾名がセルのトポロジーに依存しないよう、サーバー・オブジェクトに固定名を作成することができます。アプリケーションのクライアントが他のサーバー・プロセスで実行されていたり、ピュア・クライアントとして実行されている場合は、この品質が望まれます。固定名には、オブジェクトが他のサーバーに移動されても変わらないという利点があります。 Java EE クライアント・アプリケーションのデプロイメント記述子の jndiName 値は、クライアント・アプリケーションまたはサーバー・アプリケーションがインストールされているセルのトポロジーには関係なく、サーバー・オブジェクトの固定修飾名を参照できます。
サーバー・アプリケーション・オブジェクトにセル全体の固定名を定義するには、サーバー・アプリケーションをインストールした後に、追加のステップが必要になります。つまり、オブジェクトのバインディングをセルのパーシスタント・ルートの下に作成する必要があります。セルのパーシスタント・ルートの下にバインドされている固定名は任意の名前にすることができますが、セルのパーシスタント・ルートの下のすべての名前は、セルのパーシスタント・ルートがセル全体に対してグローバルであるため、セル内では固有である必要があります。
修飾固定名は、以下の形式です。
ここで、fixedName は、任意の固定名です。cell/persistent/fixedName
バインディングは、(例えば JNDI を使用して) プログラマチックに作成できます。ただし、サーバー・オブジェクトにセルの有効範囲を持つバインディングを構成する方がより簡単です。
プログラマチックなバインディングまたは構成されたバインディングは、最新に保つ必要があります。 構成済みの EJB バインディングは、 セルのトポロジー内にある エンタープライズ Bean の場所に基づいています。 例えば、EJB アプリケーションを 別のサーバーに移動するには、 構成済みのバインディングを更新する必要があります。 同様の変更によって、プログラマチックにバインドされている EJB ホームの参照が影響を受けるため、 固定名を現行の参照に再バインドする必要があります。 ただし、Java EE クライアントの場合は、オブジェクトの jndiName 値が、またシン・クライアントの場合は、オブジェクトの検索名が同一のままです。 つまり、固定名でオブジェクトにアクセスするクライアントは、 アクセス先のサーバー・アプリケーションの構成が変更されても、影響を受けません。
デプロイメント記述子バインディングでの検索名の使用
Java EE アプリケーションには、さまざまなタイプの参照を宣言するために使用されるデプロイメント記述子 (ejb-ref、resource-ref、resource-env-ref など) を含めることができます。これらの参照宣言では、対応する Java コンポーネントで使用できる java:comp/env 検索名が定義されています。各 java:comp/env 検索名は、グローバル名前空間の検索名にマップされる必要があります。検索名は、デフォルトの初期 JNDI コンテキストであるサーバー・ルート・コンテキストを起点にした相対名です。
参照は、検索を行うコンポーネントと同じサーバーのサーバー・ルート・コンテキストの下でバインドされているオブジェクトにマップされている必要があります。参照が、別のサーバーのサーバー・ルート・コンテキストの下でバインドされているオブジェクトにマップされている場合は、検索名を修飾する必要があります。例えば、あるサーバーで稼働しているサーブレットで、別のサーバーで稼働している EJB に対して ejb-ref が宣言されている場合は、検索名を修飾する必要があります。同様に、名前空間のパーシスタント区画にバインドされているオブジェクト、またはセル・スコープかノード・スコープの構成済み名前空間バインディングを介してバインドされているオブジェクトに参照がマップされている場合は、修飾名を使用する必要があります。
アプリケーションをインストールしたときにデプロイメント記述子の参照バインディングの値を指定し、アプリケーションのインストール後にそれらを変更することができます。参照のマップ先の JNDI 検索名を変更する必要がある場合、管理コンソールで、ターゲット・リソース JNDI 名」フィールドで新規の名前を指定します。
をクリックします。「参照」セクションには、このアプリケーションにより宣言されているさまざまな参照タイプ (EJB 参照やリソース環境エントリー参照など) に対応しているリンクがあります。変更する必要がある参照タイプのリンクをクリックし、次に「