WebLogic JNDI を使用したプログラミング



\| WebLogic Server ホーム \| JNDI プログラマーズガイド \| 前へ \| 次へ \| 目次 \| 索引 \| PDF 版

この節では、WebLogic JNDI を使用するプログラミングについて説明します。内容は以下のとおりです。

Java クライアントからの WebLogic JNDI の使い方

The WebLogic Server JNDI サービスプロバイダインタフェース（SPI）には、リモート Java クライアントから WebLogic Server への接続を可能にする InitialContext 実装が用意されています。クライアントでは、特定の WebLogic Server デプロイメントを識別する標準の JNDI 環境プロパティと、WebLogic Server へのログインに関連する接続プロパティを指定できます。

WebLogic Server とセッションに参加するには、Java クライアントはリモートオブジェクトへのオブジェクト参照を取得し、そのオブジェクトで操作を呼び出す必要があります。この処理を行うには、クライアントアプリケーションコードで、以下の手順を実行します。

InitialContext に JNDI 環境プロパティを設定します。
WebLogic Server との InitialContext を作成します。
そのコンテキストを使用して、WebLogic Server ネームスペースで名前付きオブジェクトをルックアップします。
名前付きオブジェクトを使用してリモートオブジェクトへの参照を取得し、そのリモートオブジェクトで操作を呼び出します。
セッションを終了します。

以降の節では、特定の WebLogic Server に接続するための JNDI クライアントの操作について説明します。WebLogic Server のクラスタでの JNDI の使い方については、クラスタ環境でのクライアントからの WebLogic JNDI の使い方を参照してください。

JNDI を使用して WebLogic Server 環境内のオブジェクトにアクセスする前に、WebLogic Server の JNDI ツリーにそのオブジェクトをロードしておく必要があります。JNDI ツリーにオブジェクトをロードする手順については、JNDI の管理を参照してください。

InitialContext への JNDI 環境プロパティの設定

Java クライアントアプリケーションで、まず実行しなければならない作業は、環境プロパティの作成です。InitialContext ファクトリは、各種のプロパティを使用して、特定の環境に合った InitialContext をカスタマイズします。これらのプロパティは、ハッシュテーブル、または WebLogic Environment オブジェクトの set() メソッドを使用して設定できます。名前と値の組み合わせで指定される、これらのプロパティによって、WLInitialContextFactory ファクトリでのコンテキストの作成方法が決まります。

以下のプロパティが、InitialContext のカスタマイズに使用されます。

Context.PROVIDER_URL －ネームサービスを提供する WebLogic Server の URL を指定します。デフォルトは t3://localhost:7001 です。
Context.SECURITY_PRINCIPAL －ユーザ（つまり、WebLogic Server セキュリティレルムで定義されているユーザ）の認証用の ID を指定します。スレッドが既に WebLogic Server ユーザに関連付けられていない限り、プロパティのデフォルト値は guest になります。詳細については、http://edocs.beasys.co.jp/e-docs/wls61/adminguide/cnfgsec.html にある「セキュリティの管理」を参照してください。
Context.SECURITY_CREDENTIALS －この Context.SECURITY_CREDENTIALS プロパティを使用して、Context.SECURITY_PRINCIPAL プロパティで定義されているユーザのパスワード、または weblogic.security.acl.UserInfo インターフェイスを実装するオブジェクトのいずれかを指定します。このプロパティに UserInfo オブジェクトを渡すと、Context.PROVIDER_URL プロパティは無視されます。スレッドが既にユーザに関連付けられていない限り、プロパティのデフォルト値は guest になります。詳細については、http://edocs.beasys.co.jp/e-docs/wls61/adminguide/cnfgsec.html にある「セキュリティの管理」を参照してください。

クライアントまたはサーバのどちらでも、同じプロパティを使用できます。サーバサイドオブジェクトでプロパティを定義する場合は、ローカルコンテキストが使用されます。クライアントまたは別の WebLogic Server でプロパティを定義する場合は、Context.PROVIDER_URL プロパティで指定された WebLogic Server で実行中のリモートコンテキストに委託されます。

コードリスト 2-1 は、Context.INITIAL_CONTEXT_FACTORY プロパティと Context.PROVIDER_URL プロパティを使用して、コンテキストを取得する方法を示しています。

コードリスト 2-1 コンテキストの取得

  Context ctx = null;
  Hashtable ht = new Hashtable();
  ht.put(Context.INITIAL_CONTEXT_FACTORY,
         "weblogic.jndi.WLInitialContextFactory");
  ht.put(Context.PROVIDER_URL,
         "t3://localhost:7001");

  try {
    ctx = new InitialContext(ht);
    // プログラムではこのコンテキストを使用する
  }
  catch (NamingException e) {
    // エラー発生
  }
  finally {
    try {ctx.close();}
    catch (Exception e) {
    // エラー発生
    }
  }

この他にも、セキュリティパラメータをコンフィグレーションしたり、オブジェクトをクラスタワイドの JNDI ツリーにバインドする方法を指定したりするための WebLogic 固有のプロパティがあります。バインドは、クラスタ内にある各サーバの JNDI ツリー間でレプリケートされる場合とされない場合があります。このようなプロパティは、weblogic.jndi.WLContext クラス内の定数によって示されます。JNDI に関連するクラスタ化の問題の詳細については、クラスタ環境でのクライアントからの WebLogic JNDI の使い方を参照してください。

ハッシュテーブルを使用したコンテキストの作成

ハッシュテーブルを使用して、コンテキストを作成できます。ハッシュテーブルには、 InitialContext への JNDI 環境プロパティの設定で説明したプロパティを指定しておきます。

まず、ハッシュテーブルを InitialContext のコンストラクタに渡します。java.naming.factory.initial プロパティを使用して、InitialContext の作成方法を指定します。WebLogic JNDI を使用するには、java.naming.factory.initial プロパティを常に weblogic.jndi.WLInitialContextFactory に設定する必要があります。この設定値は、コンテキストを実際に作成するファクトリを示します。

WebLogic Environment オブジェクトを使用したコンテキストの作成

weblogic.jndi.environment インタフェースによって実装される WebLogic Environment オブジェクトを使用して、コンテキストを作成することもできます。Environment オブジェクトは WebLogic 固有のものですが、以下のような利点があります。

一連のデフォルト値が用意されているので、記述するコードが少なくて済みます。
コンパイルタイプのタイプ保証を提供する便利な set() メソッドが用意されています。タイプ保証の set() メソッドを使用することで、コードの記述とデバッグの時間を短縮することができます。

WebLogic Environment オブジェクトには、以下のデフォルト値が用意されています。

InitialContext ファクトリを指定しない場合は、デフォルト値として WLInitialContextFactory が使用されます。
Context.SECURITY_PRINCIPAL プロパティおよび Context.CREDENTIALS プロパティでユーザおよびパスワードを指定しない場合は、スレッドが既にユーザに関連付けられていない限り、ユーザとパスワードのデフォルト値として、guest が使用されます。
Context.PROVIDER_URL プロパティを指定しない場合は、デフォルト値として t3://localhost:7001 が使用されます。

これらのデフォルト値を使用して InitialContext を作成する場合のコードは、以下のようになります。

  Environment env = new Environment();
  Context ctx = env.getInitialContext();

たとえば、クライアントのクラスタアクセスのために、1 つの WebLogic Server だけにドメインネームサービス（DNS）名を設定する場合のコードは、以下のようになります。

  Environment env = new Environment();
  env.setProviderURL("t3://myweblogiccluster.com:7001");
  Context ctx = env.getInitialContext();

注意: 新しい JNDI Environmental オブジェクトを作成するたびに、新しいセキュリティスコープが作成されます。このセキュリティスコープは、context.close() メソッドで終了します。

environment.getInitialContext() メソッドは、IIOP プロコトルでは正しく動作しません。

コードリスト 2-2 は、JNDI Environment オブジェクトを使用してセキュリティコンテキストを作成する方法を示しています。

コードリスト 2-2 JNDI Environment オブジェクトを使用するセキュリティコンテキストの作成

weblogic.jndi.Environment environment = new weblogic.jndi.Environment();
environment.setInitialContextFactory(
  weblogic.jndi.Environment.DEFAULT_INITIAL_CONTEXT_FACTORY);
environment.setProviderURL(“t3://bross:4441”);
environment.setSecurityPrincipal(“guest”);
environment.setSecurityCrendentials(“guest”);
Hashtable props = environment.getProperties();
InitialContext ctx = new InitialContext(props);

サーバサイドオブジェクトからのコンテキストの作成

また、エンタープライズ JavaBean（EJB）オブジェクトや Remote Method Invocation（RMI）オブジェクトのような、WebLogic Server の Java 仮想マシン（JVM）でインスタンス化されるオブジェクトからコンテキストを作成することが必要になる場合もあります。サーバサイドオブジェクトを使用する場合は、Context.PROVIDER_URL プロパティを指定する必要はありません。特定のユーザとして署名し、ログオンする場合にのみ、ユーザ名とパスワードが必要になります。サーバサイドのコンテキストは WebLogic Server のコンテキストで動作します。

サーバサイドオブジェクト内からコンテキストを作成するには、まず次のように、新しい InitialContext を作成する必要があります。

  Context ctx = new InitialContext();

ファクトリやプロバイダの URL を指定する必要はありません。デフォルトで、コンテキストは Context として作成され、ローカルのネーミングサービスに接続されます。

JNDI コンテキストとスレッド

ユーザ名とパスワードを使用してJNDI コンテキストを作成すると、ユーザとスレッドが関連付けられます。コンテキストが作成されると、ユーザはスレッドと関連付けられたコンテキストスタック上にプッシュされます。スレッドで新しいコンテキストを開始する前に、最初のコンテキストを閉じて、最初のユーザとスレッドの関連付けを断つ必要があります。そうしないと、新しいコンテキストが作成されるたびに、ユーザはスタックの中で下にプッシュされていきます。これはリソースの使い方として効率の良いものではなく、ctx.lookup() の呼び出しに対して正しくないユーザが返される場合があります。このシナリオについては、以下の手順を使って説明します。

user1 に対して ctx1 という名前のコンテキスト (ユーザ名と資格を指定して) を作成します。コンテキストを作成する処理において、user1 はスレッドと関連付けられ、スレッドに関連付けられたスタックにプッシュされます。この時点では、現在のユーザは user1 です。
user2 に対して ctx2 という名前の 2 番目のコンテキスト (ユーザ名と資格を指定して) を作成します。この時点で、スレッドにはユーザのスタックが関連付けられています。スタックの 1 番上には User2 があり、user1 はその下にあるので、現在のユーザとしては user2 が使用されます。
ctx1.lookup("abc") の呼び出しを行うと、user2 がスタックの 1 番上にあるので、ID としては user1 ではなく user2 が使用されます。意図した結果を得るため、つまりctx1.lookup("abc") の呼び出しが user1 として行われるようにするためには、ctx2.close() を呼び出す必要があります。ctx2.close() を呼び出すと、スレッドに関連付けられたスタックから user2 が削除されて、ctx1.lookup("abc") の呼び出しは意図したとおりに user1 を使用するようになります。

注意: ただし、スタック上のユーザが 1 人だけの場合は、 close() を呼び出してもスタックから現在のユーザは削除されず、JNDI コンテキストで問題が発生する可能性があります。JNDI コンテキストの問題を避ける方法については、 JNDI コンテキストの潜在的な問題を避ける方法を参照してください。

JNDI コンテキストの潜在的な問題を避ける方法

close() を呼び出すと、通常は JNDI コンテキストとスレッドで説明されている処理が行われますが、最初のログインの場合には動作が異なります。この場合にはユーザは「貼り付いた」ような状態になり、ほかのユーザがいない場合のデフォルトユーザになります。以下の手順では、このシナリオについて説明します。

user1 に対する ctx1 という名前のコンテキスト (ユーザ名と資格を指定して) を作成します。コンテキスト作成の過程で、user1 はスレッドと関連付けられ、スタックに格納されます。つまり、現在の ID は user1 に設定されます。
ctx1.close() を呼び出します。これは最初のユーザなので、現在の ID は user1 に設定されたままになります。user1 はこのスレッドでの現在のユーザであるだけでなく、ほかの ID が定義されていないすべてのスレッドにおける現在のユーザでもあることに注意してください。つまり、ほかのユーザ ID が存在していない場合、user1 がデフォルトユーザになります。それ以降のログインでユーザ名と資格が示されないと、デフォルトとして user1 の ID が与えられてしまうので、これはよい方法ではありません。

この問題に対処するには、guest のユーザ名とパスワードを使用してログインするコンテキストを作成します。必ず、これがクライアント上での最初のログオンになるようにします。ctx.close() の呼び出しを直ちに実行して、スレッドのユーザスタックから guest を削除します。guest はログオンする最初のユーザであるため、デフォルトユーザになります。以後、空のユーザスタックを持つすべてのスレッドの ID は guest になります。

コンテキストを使用した名前付きオブジェクトのルックアップ

すべての Java クライアントアプリケーションは、アプリケーションにサービスを提供する最初のオブジェクトを取得する必要があります。ただし、そのオブジェクトが WebLogic Server ネームスペースにロードされていない限り、それをルックアップすることはできません。詳細については、『管理者ガイド』のJNDI の管理を参照してください。

コンテキストで lookup() メソッドを使用して、名前付きオブジェクトを取得します。lookup() メソッドに渡される引数は、目的のオブジェクト名を含む文字列です。コードリスト 2-3 は、ServiceBean という名前の EJB を取り出す方法を示しています。

コードリスト 2-3 名前付きオブジェクトのルックアップ

  try {
    ServiceBean bean = (ServiceBean)ctx.lookup("ejb.serviceBean");
  }
  catch (NameNotFoundException e) {
    // バインドが存在しない
  }
  catch (NamingException e) {
    // エラー発生
  }

名前付きオブジェクトを使用したオブジェクト参照の取得

EJB クライアントアプリケーションは、EJB ホームから EJB リモートオブジェクトへのオブジェクト参照を取得します。RMI クライアントアプリケーションは、最初の名前付きオブジェクトからその他の RMI オブジェクトへのオブジェクト参照を取得します。これらの最初の名前付きリモートオブジェクトは共に、ファクトリとして WebLogic Server に認識されます。ファクトリとは、WebLogic ネームスペース内にある別のオブジェクトへの参照を返すことができるオブジェクトのことです。

クライアントアプリケーションは、ファクトリでメソッドを呼び出し、特定のクラスのリモートオブジェクトへの参照を取得します。その後、リモートオブジェクトでメソッドを呼び出し、必要な引数を渡します。

コードリスト 2-4 は、リモートオブジェクトを取得した後に、そのオブジェクトでメソッドを呼び出すコードを示しています。

コードリスト 2-4 名前付きオブジェクトを使用したオブジェクト参照の取得

ServiceBean bean = ServiceBean.Home.create("ejb.ServiceBean")

Servicebean.additem(66);

コンテキストのクローズ

クライアントは、コンテキストの操作が終了したらコンテキストを閉じて、リソースを解放し、メモリリークを防ぐことが推奨されます。この処理は finally{} ブロックで行い、close() メソッドは try{} ブロックの中に入れることをお勧めします。エラーが原因で一度もインスタンス化されなかったコンテキストを閉じようとすると、Java クライアントアプリケーションでは例外が送出されます。

コードリスト 2-5 では、クライアントでコンテキストが閉じられ、リソースが開放されています。

コードリスト 2-5 コンテキストのクローズ

try {
       	ctx.close();
} catch (Exception e) {
// エラー発生
}

クラスタ環境での WebLogic JNDI の使い方

WebLogic JNDI の目的は、J2EE サービス、特に EJB、RMI、および Java Messaging Service（JMS）の各サービスに対してネーミングサービスを提供することです。そのため、クラスタ環境でオブジェクトを JNDI ツリーにバインドすることによる影響を十分理解しておく必要があります。

以降の節では、クラスタ環境での WebLogic JNDI の実装方法について説明し、独自のオブジェクト（カスタムオブジェクト）を JNDI クライアントで使用できるようにするための方法を紹介します。

J2EE サービスのクラスタ化

WebLogic RMI を使用すると、ある JVM のクライアントが別の JVM のクライアントから EJB サービスや JMS サービスにアクセスできるようになります。RMI スタブは、RMI オブジェクトに対するクライアントからの呼び出しを受信し、マーシャリングします。クライアントで J2EE サービスを利用できるようにするために、WebLogic は、特定のサービスの RMI スタブを、特定の名前で JNDI ツリーにバインドします。RMI オブジェクトの他のインスタンスがクラスタ内の他のサーバにデプロイされると、RMI スタブはその場所で更新されます。クラスタ内のサーバに障害が発生すると、他のサーバの JNDI ツリー内の RMI スタブが更新されてサーバの障害を反映します。

クライアントがクラスタに接続する場合、実際には、既にクラスタ内にある WebLogic Server の 1 つに接続されます。その WebLogic Server の JNDI ツリーには、そのサーバによって提供されるサービスだけでなく、クラスタ内の他のサーバによって提供されるすべてのサービスの RMI スタブが含まれているため、クライアントには、クラスタがクラスタワイドのサービスをすべて提供する 1 つの WebLogic Server のように表示されます。クラスタに新しい WebLogic Server が加わった場合、既にクラスタ内に存在する各 WebLogic Server は、それぞれの独自のサービスに関する情報を新しい WebLogic Server に渡して共有する必要があります。クラスタ内の他のすべてのサーバから収集された情報を使用して、新しいサーバはクラスタワイドの JNDI ツリーの独自のコピーを作成できます。

以下に示すように、RMI スタブは、クラスタ環境での WebLogic JNDI の実装方法に大きな影響を与えます。

RMI スタブは比較的小さいものです。このため、WebLogic JNDI ではサーバ間通信のオーバーヘッドが少ない状態で、クラスタ内のすべての WebLogic Server にスタブをレプリケートできます。
RMI スタブは、クラスタ全体をレプリケートするメカニズムとして機能します。RMI オブジェクトのインスタンスは 1 つの WebLogic Server にデプロイされますが、スタブはクラスタ全体にレプリケートされます。

カスタムオブジェクトを WebLogic Server クラスタで使用できるようにする方法

カスタムオブジェクト（非 RMI オブジェクト）を WebLogic Server のクラスタ内の JNDI ツリーにバインドすると、オブジェクトはクラスタ内の全サーバにレプリケートされます。ただし、ホストサーバがダウンした場合は、カスタムオブジェクトはクラスタの JNDI ツリーから削除されます。カスタムオブジェクトは、再度バインドされない限り、レプリケートされません。カスタムオブジェクトに加えられた変更を伝播するには、その都度カスタムオブジェクトをアンバインドし、リバインドする必要があります。そのため、WebLogic JNDI は、分散オブジェクトのキャッシュとして使用することはできません。分散キャッシュは、WebLogic Server でサードパーティ製ソリューションを使用して提供することができます。

カスタムオブジェクトにアクセスする必要があるのは、1 つの WebLogic Server にデプロイされている EJB だけであると仮定します。この場合、明らかに、カスタムオブジェクトをクラスタ内のすべての WebLogic Server にレプリケートする必要はありません。実際には、サーバ間の不要な通信によるパフォーマンスの低下を回避するために、カスタムオブジェクトがレプリケートされないようにする必要があります。クラスタ内の WebLogic Server 間でレプリケートされないバインドを作成するには、カスタムオブジェクトをネームスペースにバインドするコンテキストの作成時に、REPLICATE_BINDINGS プロパティを指定します。コードリスト 2-6 は、REPLICATE_BINDINGS プロパティの使い方を示しています。

コードリスト 2-6 REPLICATE_BINDINGS プロパティの使い方

  Hashtable ht = new Hashtable();
  // バインドのレプリケーションを無効にする
  ht.put(WLContext.REPLICATE_BINDINGS, "false");
  try { 
    Context ctx = new InitialContext(ht);
    // オブジェクトをバインドする
    ctx.bind("my_object", MyObect);
  } catch (NamingException ne) {
    // エラー発生
  }

この方法でカスタムオブジェクトを使用する必要がある場合は、WebLogic Server の InitialContext を明示的に取得する必要があります。クラスタ内の他の WebLogic Server に接続した場合は、バインドは JNDI ツリーに表示されません。

クラスタ内のどの WebLogic Server からもカスタムオブジェクトにアクセスできるようにするには、JNDI バインドをレプリケートせず、カスタムオブジェクトをクラスタ内の各 WebLogic Server にデプロイします。

WebLogic JNDI を使用してバインドをレプリケートすると、バインドされているオブジェクトは、ホストになっている WebLogic Server によって所有されているように処理されます。ホストになっている WebLogic Server に障害が発生すると、クラスタ内のすべての WebLogic Server のすべての JNDI ツリーからカスタムオブジェクトが削除されます。この動作によって、カスタムオブジェクトの可用性が低下するおそれがあります。

注意: JNDI の Context.bind(String Name) では、/ または - を使用することはできません。バインド名の文字列に / または - が含まれる場合、javax.naming.NameNotFoundException が送出されます。

「データキャッシュ」設計パターン

Web アプリケーションには、複数のオブジェクトによって使用されるデータを一定期間キャッシュし、データ計算や別のサービスへの接続に関連するオーバーヘッドを回避するという一般的なタスクがあります

単一の WebLogic Server で正常に動作するカスタムデータキャッシュオブジェクトを既に設計しており、WebLogic クラスタ内でこのオブジェクトの使用を希望していると仮定します。いずれかの WebLogic Server の JNDI ツリーにそのデータキャッシュオブジェクトをバインドすると、デフォルトでは、WebLogic JNDI はクラスタ内のその他の各 WebLogic Server にそのオブジェクトをコピーします。このオブジェクトは RMI オブジェクトではないので、JNDI ツリーにバインドされ、他の WebLogic Server にコピーされているものはオブジェクト自身であり、いずれかの WebLogic Server をホストにするオブジェクトの単一のインスタンスを参照するスタブではない点に注意してください。WebLogic Server がサーバ間でオブジェクトをコピーしても、カスタムオブジェクトを分散キャッシュとして使用できるわけではありません。カスタムオブジェクトは、バインドされている WebLogic Server に障害が発生するとクラスタから削除されます。カスタムオブジェクトへの変更は、オブジェクトをアンバインドして JNDI ツリーにリバインドしない限り、クラスタ内に伝播されません。

パフォーマンスと可用性の理由から、クラスタ内のすべての WebLogic Server で高可用性が求められる場合は、WebLogic JNDI のバインドのレプリケーションを使用して大きなカスタムオブジェクトをコピーすることはお勧めできません。その代わりに、カスタムオブジェクトの別々のインスタンスを各 WebLogic Server にデプロイする方法があります。各 WebLogic Server の JNDI ツリーにオブジェクトをバインドするときは、カスタムオブジェクトを WebLogic Server クラスタで使用できるようにする方法で説明するように、バインドのレプリケーションを無効にしておく必要があります。この設計パターンでは、各 WebLogic Server はカスタムオブジェクトのコピーを保持しますが、サーバ間で大量のデータがコピーされることはありません。

どの手法を使用する場合でも、オブジェクトの各インスタンスは、クラスタ内の他のデータキャッシュオブジェクトとは無関係に自分のキャッシュを更新する必要があるときに備えて、独自のロジックを保持する必要があります。たとえば、ある WebLogic Server 上のデータキャッシュにクライアントがアクセスすると仮定します。そのキャッシュオブジェクトがアクセスされるのはその時が初めてなので、オブジェクトは情報を計算または取得し、将来のリクエストに備えて情報のコピーを保存します。次に、別のクライアントがクラスタに接続し、最初のクライアントと同じタスクを実行すると仮定します。ただし、今回は、クラスタ内の別の WebLogic Server に接続します。この特定のデータキャッシュオブジェクトにとってそれが最初に受け付けるアクセスである場合は、クラスタ内の他のデータキャッシュオブジェクトが既に情報をキャッシュしているかどうかに関係なく、アクセスされたオブジェクトは情報を計算する必要があります。もちろん、データキャッシュオブジェクトのこのインスタンスは、将来のリクエストに対しては保存してある情報を参照することができます。

「サービスを各クラスタに一度しか表示しない」設計パターン

サービスをクラスタ内に一度だけ表示させることが望ましい場合もあります。これを実現するには、1 つのマシンだけにサービスをデプロイします。RMI オブジェクトの場合は、WebLogic JNDI のデフォルト動作を使用して、バインド（RMI スタブ）をレプリケートすることによって、クラスタ内のすべての WebLogic Server からオブジェクトの単一のインスタンスにアクセスできるようになります。このようなサービスは、固定サービスと呼ばれます。非 RMI オブジェクトの場合は、オブジェクトをネームスペースにバインドするときに、必ず REPLICATE_BINDINGS プロパティを使用してください。この場合、オブジェクトにアクセスするには、ホストになっている WebLogic Server に明示的に接続する必要があります。代わりに、RMI オブジェクトを作成し、ホストになっている同じ WebLogic Server にデプロイすることもできます。この RMI オブジェクトは、非 RMI オブジェクトのプロキシとして機能します。WebLogic JNDI のデフォルト動作を使用してプロキシのスタブをレプリケートすれば、クラスタ内の任意の WebLogic Server に接続したクライアントは、RMI プロキシを経由して非 RMI オブジェクトにアクセスできます。

このような、サービスを各クラスタに一度しか表示しない設計パターンでは、高可用性が求められるサービスには新たな課題が発生します。WebLogic クラスタのフェイルオーバ機能は、クラスタ化されたサービスごとに複数のデプロイメントがあることに基づいているため、サービスを各クラスタに一度しか表示しない場合は、フェイルオーバ機能を使用できません。高可用性が求められるサービスの場合は、ホストになっている WebLogic Server にハードウェアによる高可用性（HA:High-Availability）フレームワークを実装することをお勧めします。フレームワークにより、障害が発生した場合でも、サービスの可用性の低下を最小限に留めた状態で、WebLogic Server を再起動できます。

クラスタ環境でのクライアントからの WebLogic JNDI の使い方

オブジェクトの JNDI バインドは、クラスタ内の 1 つの WebLogic Server の JNDI ツリーに表示することも、クラスタ内のすべての WebLogic Server にレプリケートすることもできます。目的のオブジェクトがただ 1 つの WebLogic Server だけにバインドされている場合は、 Java クライアントからの WebLogic JNDI の使い方で説明されているように、初期コンテキストの作成時に、Context.PROVIDER_URL プロパティをホストになっている WebLogic Server の URL に設定することで、ホストになっている WebLogic Server に明示的に接続する必要があります。

ただし、ほとんどの場合、目的のオブジェクトは、クラスタ化されたサービスか、または固定サービスです。つまり、クラスタ内の各 WebLogic Server の JNDI ツリーには、サービスのスタブが表示されます。この場合、クライアントは、ネーミングサービスを提供する特定の WebLogic Server の名前を指定する必要はありません。実際、WebLogic クラスタにネーミングサービスを提供するようリクエストするのが、クライアントにとって最善の方法です。その場合、WebLogic Server のコンテキストファクトリによって、クライアントに対して最も適切であると思われる WebLogic Server がクラスタの中から選択されます。現在、ネーミングサービスプロバイダは、DNS ラウンドロビン方式を使用して WebLogic の中から選択されます。

一般に、クラスタ化されたサービスのクライアントに対して返されるコンテキストは、フェイルオーバスタブとして実装されており、選択された WebLogic Server との間で通信障害などの障害が発生した場合は、ネーミングサービスプロバイダを透過的に変更できます。

コードリスト 2-7 は、クラスタのネーミングサービスをクライアントが使用する方法を示しています。

コードリスト 2-7 WebLogic クラスタでのネーミングサービスの使い方

  Hashtable ht = new Hashtable();
  ht.put(Context.INITIAL_CONTEXT_FACTORY,
         "weblogic.jndi.WLInitialContextFactory");
  ht.put(Context.PROVIDER_URL, "t3://acmeCluster:7001");
  try {
    Context ctx = new InitialContext(ht);
    // クライアントの作業を行う
  }
  catch (NamingException ne) {
    // エラー発生
  }
  finally {
    try {ctx.close();}
    catch (Exception e) {
    // エラー発生
    }
  }

プロバイダの URL の一部として指定されている hostname は、クラスタの DNS 名であり、config.xml ファイルの Cluster スタンザの ClusterAddress 設定で定義できます。ClusterAddress は、このクラスタでネーミングサービスを提供しているホストのリストに対応しています。詳細については、WebLogic Server とクラスタのコンフィグレーションを参照してください。

コードリスト 2-7 では、acmeCluster というクラスタ名を使用して、クラスタ内の任意の WebLogic Server に接続しています。結果として得られるコンテキストは、クラスタ内の任意の WebLogic Server に透過的にフェイルオーバできるようにレプリケートされます。

WebLogic クラスタとの最初の接続ポイントを指定するもう 1 つの方法は、次のコードで示すように、カンマで区切った DNS サーバ名または IP アドレスのリストを入力することです。

ht.put(Context.PROVIDER_URL, "t3://acme1,acme2,acme3:7001");

すべての WebLogic Server は URL の最後で指定されているポートと同じポートでリスンする必要があります。