プログラムによるデフォルトの初期コンテキストの取得には、さまざまな方法があります。
以下の例は、デフォルトの初期コンテキストを取得するものです。 javax.naming.InitialContext コンストラクターにはプロバイダー URL が渡されないことに注意してください。
... import javax.naming.Context; import javax.naming.InitialContext; ... Context initialContext = new InitialContext(); ...
戻されるデフォルトの初期コンテキストは、JNDI クライアントのランタイム環境に依存します。以下は、さまざまな 環境内で戻される初期コンテキストです。
プロバイダー URL が指定されていない場合、 -CCproviderURL、または -CCBootstrapHost および -CCBootstrapPort コマンド行パラメーターで 指定されているホストおよびポートで稼働しているサーバーのサーバー・ルート・コンテキストです。 デフォルトのホストはローカル・ホストであり、デフォルトのポートは 2809 です。
上記の例ではプロバイダー URL は明示的に指定されていませんが、 InitialContext のコンストラクターは、プロパティーの設定の検索場所とな っている他の 場所で定義されているプロバイダー URL を見つける可能性があります。
ORB の初期化に影響するプロパティーを使用する場合は、このセクションの残りの部分を読み、 初期コンテキストの正確な取得方法についてより深く理解する必要があります。
WebSphere Application Server のネーム・サーバーは、CORBA CosNaming ネーム・サーバーであり、 WebSphere Application Server は、WebSphere Application Server のネーム・スペースで JNDI クライアントがネーミング操作を実行するための CosNaming JNDI プラグインのインプリメンテーションを提供しています。WebSphere Application Server の CosNaming プラグイン・インプリメンテーションは、InitialContext コンストラクターに渡される JNDI プロパティーを介して選択します。このプロパティーは java.naming.factory.initial で、初期コンテキストを取得するために使用する初期コンテキストのファクトリー・インプリメンテーションを指定します。このファクトリーは、そのインプリメンテーションの一部である javax.naming.Context のインスタンスを戻します。
WebSphere Application Server の初期コンテキスト・ファクトリーの com.ibm.websphere.naming.WsnInitialContextFactory は、一般的に、WebSphere Application Server のアプリケーションが JNDI 操作を行う場合に使用します。 この WebSphere Application Server の初期コンテキスト・ファクトリー が JNDI クライアントによって明示的に指定されていない場合、WebSphere Application Server のランタイム環境は、それを使用するようにセットアップされます。初期コンテキスト・ファクトリーが呼び出されると、初期コンテキスト が取得されます。以下のパラグラフでは、WebSphere Application Server の初期コンテキスト・ファクトリーが、クライアントおよびサーバーの環境で初期コンテキストを取得する方法について説明します。
すべての WebSphere Application Server では、ORB を使用して、そのサーバーで実行されているオブジェクトを受け取り、その呼び出しをディスパッチします。サーバー・プロセスで実行されているサービスは、初期参照をその ORB に登録することができます。各初期参照は、ストリング値であるキーに基づいて登録されます。任意の CORBA オブジェクトを初期参照にすることができます。WebSphere Application Server のネーム・サーバーは、いくつかの初期コンテキストを、事前定義されているキーに基づいて初期参照として登録します。各ネーム・サーバーの初期参照は、インターフェース org.omg.CosNaming.NamingContext のインスタンスです。
JNDI のピュア・クライアント、つまり WebSphere Application Server プロセスで実行されていない JNDI クライアントも ORB インスタンスを持ちます。このクライアント ORB インスタンスは InitialContext コンストラクターに渡されますが、一般的に、初期コンテキスト・ファクトリーが、クライアント ORB インスタンスを透過的に作成し、初期化します。クライアント ORB は初期参照で初期化できますが、その初期参照は、ほとんどの場合、あるサーバーで実行されているオブジェクトに解決します。初期コンテキスト・ファクトリーは、ORB を初期化する場合のデフォルトの初期参照を定義しません。初期参照が構成されていない場合に、クライアント ORB の resolve_initial_references メソッドが呼び出されると、そのメソッド呼び出しは失敗します。 この状態は、典型的なピュア・クライアント・プロセスです。NamingContext の初期参照を取得するには、 初期コンテキスト・ファクトリーは、corbaloc:iiop:myhost:2809 な どの IIOP 型の CORBA オブジェクト URL を指定して string_to_object を呼び出す必要があります。 この URL は、初期コンテキストの取得先であるサーバーのアドレスを指定します。ホストおよびポート情報は、InitialContext コンストラクターに渡されたプロバイダー URL から抽出されます。
プロバイダー URL が定義されていない場合、WebSphere Application Server の初期コンテキスト・ファクトリーは、corbaloc:iiop:localhost:2809 のデフォルトのプロバイダー URL を使用します。
プロバイダー URL が定義されていない場合、
WebSphere Application Server の初期コンテキスト・ファクトリーは、
デフォルトのプロバイダー URL である corbaloc:iiop:your.server.name:2809 を使用します。
string_to_object ORB メソッドは、その URL を解決し、ターゲット・サーバーの ORB と通信して初期参照を取得します。
JNDI クライアントが WebSphere Application Server プロセスで実行されているときに、JNDI クライアントが ORB インスタンスを提供しない場合、初期コンテキスト・ファクトリーは、サーバーの ORB への参照を取得します。通常、サーバー・プロセスで実行されている JNDI クライアントは、サーバーの ORB インスタンスを使用します。つまり、これらの JNDI クライアントは、ORB インスタンスを InitialContext コンストラクターに渡しません。サーバー・プロセスで稼働しているネーム・サーバーは、あるプロバイダー URL を java.lang.System プロパティーとして設定し、そのプロセス内のすべての JNDI クライアントのデフォルトのプロバイダー URL としてそのプロバイダー URL を提供します。このデフォルトのプロバイダー URL は corbaloc:rir:/NameServiceServerRoot です。 この URL は、そのサーバーのサーバー・ルート・コンテキストに解決します。 (この URL は、NameServiceServerRoot というキーで ORB の resolve_initial_references を呼び出すことと等価です。 ネーム・サーバーは、そのサーバー・ルート・コンテキストをそのキーでの初期参照として登録します。)
WebSphere Application Server バージョン 5 より前のリリースは、別の ORB 実装を使用していました。 これは、現在使用されている Interoperable Name Service (INS) プロトコルとは対照的にレガシー・プロトコルを使用していました。 この変更は、WebSphere Application Server の初期コンテキスト・ファクトリーに影響を与えています。いくつかのタイプのピュア・クライアントは、JNDI の初期コンテキストを取得するときに、前のリリースの WebSphere Application Server と比較して、異なる振る舞いを経験することがあります。この振る舞いについては、以下で詳細に説明します。
以下に示す ORB のプロパティーは、レガシーの ORB プロトコルと共に ORB の初期化に使用されますが、現在は使用できなくなっています。
新しい INS ORB は、初期参照が定義されていない場合でもデフォルトの振る舞いを示さないという点で、大きく異なっています。
レガシー ORB では、ブートストラップ・ホストおよびポートの値は、localhost および 900 がデフォルトです。
レガシー ORB では、ブートストラップ・ホストおよびポートの値は、
your.server.name および 900 がデフォルトです。
すべての初期参照は、ブートストラップ・ホストおよびポートで稼働しているサーバーから取得されていました。このため、ORB ユーザーがブートストラップ・ホストおよびポートを提供しなかった場合、すべての初期参照は、ポート 900 のローカル・ホストで稼働しているサーバーから解決されます。INS ORB には、ブートストラップ・ホストまたはブートストラップ・ポートという概念はありません。すべての初期参照は、個別に定義されます。つまり、初期参照が異なる場合は、解決されるサーバーも異なります。If ORB.resolve_initial_references を呼び出したキーが、そのキーを持つ初期参照では ORB は初期化されないキーである場合、その呼び出しは失敗します。
バージョン 5 より前の WebSphere Application Server のリリースでは、プロバイダー URL が存在していない場合、その ORB の初期コンテキスト・ファクトリーは、 resolve_initial_references を呼び出していました。 デフォルトのブートストラップ・ホストおよびポートにあるネーム・サーバーが稼働している場合、このアクションは成功しました。現在のリリースの INS ORB では、失敗します。 (実際に、ORB は、使用が縮小されている期間中にレガシー・プロトコルに逆戻りしますが、レガシー・プロトコルがサポートされなくなると、この操作は失敗します。)
現在では、初期コンテキスト・ファクトリーは、デフォルトのプロバイダー URL の corbaloc:iiop:localhost:2809 を使用しており、プロバイダー URL で string_to_object を呼び出します。
現在のところ、
初期コンテキスト・ファクトリーは、
corbaloc:iiop:your.server.name:2809 を
デフォルトのプロバイダー URL に使用しており、
このプロバイダー URL で string_to_object を呼び出しています。
この操作は、ピュア・クライアントが ORB ブートストラップのプロパティーまたはプロバイダー URL を設定しない場合、前のリリースのピュア・クライアントが経験した振る舞いを保持します。ただし、この異なる初期コンテキスト・ファクトリーのインプリメンテーションは、プロバイダー URL を指定しない、いくつかのレガシーのピュア・クライアントが経験する振る舞いを変更します。
この振る舞いの変更を回避するには、次の 2 つの方法があります。
このタイプの URL は、指定されたキーで ORB の resolve_initial_references を呼び出すことと等価です。 ブートストラップ・ホストおよびポートのプロパティーを使用して ORB を初 期化する場合は、ブートストラップ・ホストおよびポートのプロパティーがサ ポートされなくなると、このアプローチは機能しなくなります。
このセクションの最初に示されているコードの断片をアプリケーションが実行する場合、ブートストラップ・サーバーは、プロパティー java.naming.provider.url の値に依存します。
このプロパティーが (システム・プロパティーとしてデフォルト値が設定
されているサーバー・プロセスで) 設定されていない場合は、デフォルトの
ホストである localhost およびデフォルトのポートである
2809 が、初期コンテキストの取得先であるサーバーのアドレスとして使用されます。
このプロパティーが (システム・プロパティーとしてデフォルト値が設定
されているサーバー・プロセスで) 設定されていない場合は、デフォルトの
ホストである your.server.name と
デフォルトのポートである 2809 が、初期コンテキストの取得先サーバーのアドレスとして使用されます。
InitialContext のコンストラクターが java.naming.provider.url プロパティー設定を検索する場所は JNDI の仕様に記述されていますが、簡単に言えば、このプロパティーは、以下の順序で以下の場所から取り出されます。