スタンドアロンの Java クライアントからネーミングサービスへどのようにアクセスするのでしょうか？

• • アプリケーションクライアントからネーミングサービスにアクセスするには*
    \

1. クライアントの Java VM を起動するときに appserv-rt.jar を CLASSPATH に含めます。
   \JNDI ブートストラップ機構は jndi.properties ファイルを探し、このファイルは appserv-rt.jar の中にあります。このファイルには、アプリケーションサーバーのネーミングサービスに必要な全てのブートストラッププロパティがあります。クライアントの起動スクリプトやアプリケーションコードに直接記述するよりも、{appserv-rt.jar}} からこれらのプロパティを読み込んだ方が良いでしょう。
   \
2. スタンドアロンクライアントからリモート EJB にアクセスする場合、クライアントの JAR を配備したファイルから取り出したり、クライアント JVM の CLASSPATH に置く必要はありません。というのも、静的な RMI-IIOP スタブは、アプリケーションサーバーのネーミングサービスを使うときには必要ないからです。このため、前のリリースで必要だった手順を一つ取り除けることになります。（詳細はRMI-IIOP スタブはリモート EJB にアクセスする必要がありますか？ をご覧ください）。
   \
3. クライアントのコードで、引数のないデフォルトコンストラクタ InitialContext を使います。例:\\\\\~UWC_TOKEN_START~1278691907142~UWC_TOKEN_END
   \よく誤解されるのですが、クライアントが明示的に CosNaming サービスを参照するようコードを書かなければならないと言うことはありません。CosNaming はある種のアプリケーションサーバーオブジェクトでのみ使われるので、これを使っても JMS キューのような多くのリソースにアクセスすることはできません。さらに明示的に CosNaming を使うと、アプリケーションサーバーのネーミングサービスコードをバイパスしてしまいます。これは多くの場合、アプリケーションサーバーのネーミングサービスに組み込まれている多くの価値ある機能をクライアントが使えないことになります。
   \
4. ルックアップ時には、ターゲットリソースのグローバルな JNDI 名を使います。java:comp/env はスタンドアロンの Java クライアントからは使えません。というのも、そのようなクライアントは J2EE コンテナの外で動作しているからです。java:comp/env を使えるクライアントコンポーネントは、J2EE アプリケーションクライアントだけです。
   \
5. クライアントがサーバーインスタンスとは異なるホストマシンで動作している場合は、Java VM の起動時に、次のシステムプロパティを設定します。:\\\\\~UWC_TOKEN_START~1278691907143~UWC_TOKEN_END
   \この値のデフォルト値は localhost なので、クライアントのサーバーインスタンスが異なるマシンで動作するときにのみ必要となります。例:\\\\\~UWC_TOKEN_START~1278691907144~UWC_TOKEN_END
   \
6. デフォルトでは、クライアントがサーバーのネーミングサービスにアクセスする場合に、ポート 3700 を使います。3700 は、アプリケーションサーバーで使われるデフォルトのネーミングサービス用のポートなので、クライアントで追加のポートを設定する必要はありません。ポートの衝突などのケースでは、サーバーインスタンスはネーミングサービスに異なるポートを使います。サーバーインスタンスが使うネーミングサービスのポートは、domain.xml の

   <iiop-listener id="orb-listener-1" port="3700"\>

   にリストされています。
   \クライアントが使うネーミングサービスのポートを変更する場合には、クライアントの Java VM を起動するときに次のプロパティを設定してください。
   {code}-Dorg.omg.CORBA.ORBInitialPort=naming_port_of_target_server

^戻る

日本語翻訳: shioda

英文 (翻訳したバージョン: 13)