WebLogic JNDI プログラマーズガイド

WebLogic JNDI

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

WebLogic JNDI を使用した Java クライアントから単一サーバへの接続

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

Java クライアントが WebLogic Server と対話するには、リモートオブジェクトへの参照を取得し、そのオブジェクトで操作を呼び出すことができなければなりません。そのためには、クライアントアプリケーションコードで次の手順を実行する必要があります。

InitialContext に JNDI 環境プロパティを設定します。

WebLogic Server との InitialContext を作成します。

そのコンテキストを使用して、WebLogic Server ネームスペースで名前付きオブジェクトをルックアップします。

名前付きオブジェクトを使用してリモートオブジェクトへの参照を取得し、そのリモートオブジェクトで操作を呼び出します。

コンテキストを閉じます。

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

JNDI を使用して WebLogic Server 環境内のオブジェクトにアクセスする前に、WebLogic Server の JNDI ツリーにそのオブジェクトをロードしておく必要があります。

注意 : WebLogic Server 6.1 のクラスを使用して構築したオブジェクトを WebLogic Server 7.0 以上にバインドしてデプロイすることは、サポートされていないため、起動時にエラーが発生する場合があります。

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 になります。詳細については、「WebLogic ユーザとセキュリティコンテキストの関連付け」を参照してください。
Context.SECURITY_CREDENTIALS - この Context.SECURITY_CREDENTIALS プロパティを使用して、Context.SECURITY_PRINCIPAL プロパティで定義されているユーザのパスワード、または weblogic.security.acl.UserInfo インタフェースを実装するオブジェクトのいずれかを指定します。このプロパティに UserInfo オブジェクトを渡すと、Context.PROVIDER_URL プロパティは無視されます。スレッドが既にユーザに関連付けられていない限り、プロパティのデフォルト値は guest になります。詳細については、「WebLogic ユーザとセキュリティコンテキストの関連付け」を参照してください。

クライアントまたはサーバのどちらでも、同じプロパティを使用できます。サーバサイドオブジェクトでプロパティを定義する場合は、ローカルコンテキストが使用されます。クライアントまたは別の WebLogic Server でプロパティを定義する場合は、Context.PROVIDER_URL プロパティで指定された WebLogic Server で実行中のリモートコンテキストに委託されます。サーバにバインドされたリモートオブジェクトには peerGone のサービスが提供されないため、クライアントに障害が発生すると、これらのオブジェクトはアクセス不能になります。

コンテキスト作成後は変更できないプロパティもあります。プロバイダの URL、ユーザの資格、ファクトリなどのプロパティです。AddToEnvironment を使用すると、コンテキスト作成後に他のプロパティを変更できます。

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

コードリスト 3-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 Environment オブジェクトを作成するたびに、新しいセキュリティスコープが作成されます。このセキュリティスコープは、context.close() メソッドで終了します。

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

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

コードリスト 3-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");
InitialContext ctx = environment.getInitialContext;

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

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

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

  Context ctx = new InitialContext();

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

WebLogic ユーザとセキュリティコンテキストの関連付け

「JNDI コンテキストとスレッド」を参照してください。

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

ユーザ名とパスワードで JNDI コンテキストを作成する場合、ユーザをスレッドに関連付けます。コンテキストが作成されると、ユーザはスレッドに関連付けられているコンテキストスタックにプッシュされます。スレッドで新しいコンテキストを開始する場合は、最初のコンテキストを閉じて、最初のユーザとスレッドとの関連付けを解除しておく必要があります。このようにしない場合、新しいコンテキストが作成されるたびにユーザがスタックにプッシュされます。このため、リソースが効率的に使用されず、ctx.lookup() 呼び出しによって誤ったユーザが返される場合があります。次の手順で、このシナリオについて説明します。

user1 用に ctx1 というコンテキストを (ユーザ名と資格を使用して) 作成します。コンテキストの作成処理で、user1 がスレッドに関連付けられ、そのスレッドに関連付けられているスタックにプッシュされます。現在のユーザはこの時点で user1 です。

user2 用に ctx2 という 2 番目のコンテキストを (ユーザ名と資格を使用して) 作成します。この時点で、スレッドには複数のユーザが関連付けられます。User2 はスタックの一番上に存在し、user1 はその下に存在します。このため、user2 が現在のユーザとなります。

ctx1.lookup("abc") 呼び出しを行った場合、user2 がスタックの一番上に存在するため、user1 ではなく user2 が ID として使用されます。目的の結果を得る、つまり、ctx1.lookup("abc") 呼び出しが user1 として実行されるようにするには、ctx2.close() 呼び出しを行う必要があります。ctx2.close() 呼び出しにより、スレッドに関連付けられているスタックから user2 が削除され、ctx1.lookup("abc") 呼び出しで user1 が使用されます。

注意 : weblogic.jndi.enableDefaultUser フラグが有効化されている場合、close() 呼び出しを行っても現在のユーザがスタックから削除されず、JNDI コンテキストの問題が発生する恐れのある状況が 2 つあります。JNDI コンテキストの問題の回避方法については、「JNDI コンテキストの問題の回避方法」を参照してください。

JNDI コンテキストの問題の回避方法

close() 呼び出しを発行すると、通常は「JNDI コンテキストとスレッド」の説明のように動作します。ただし、weblogic.jndi.enableDefaultUser フラグが有効化されていると、予期される動作に対して次の例外が発生します。

最後に使用されたもの

IIOP を使用する場合、スタックにコンテキストが 1 つあり、そのコンテキストが close() によって削除される場合に、予期された動作に対する例外が発生します。スタックから削除された最後のコンテキストの ID によって、ユーザの現在の ID が決まります。次の手順で、このシナリオについて説明します。

user1 用に ctx1 というコンテキストを (ユーザ名と資格を使用して) 作成します。コンテキストの作成処理で、user1 がスレッドに関連付けられてスタックに格納されます。つまり、現在の ID は user1 に設定されます。

ctx1.close() 呼び出しを行います。

ctx1.lookup() 呼び出しを行います。現在のユーザはこの時点で user1 です。

user2 用に ctx2 というコンテキストを (ユーザ名と資格を使用して) 作成します。コンテキストの作成処理で、user2 がスレッドに関連付けられてスタックに格納されます。つまり、現在の ID は user2 に設定されます。

ctx2.close() 呼び出しを行います。

ctx2.lookup() 呼び出しを行います。現在のユーザはこの時点で user2 です。

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

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

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

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

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

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

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

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

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

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

Servicebean.additem(66);

コンテキストのクローズ

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

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

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

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

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

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

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

RMI と JNDI の関係を利用した WebLogic クラスタの有効化

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 プロパティを指定します。コードリスト 3-6 は、REPLICATE_BINDINGS プロパティの使い方を示しています。

コードリスト 3-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 ツリーからカスタムオブジェクトが削除されます。この動作によって、カスタムオブジェクトの可用性が低下するおそれがあります。

データキャッシング設計パターン

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 オブジェクトにアクセスできます。

高可用性が求められるサービスの場合、RMI オブジェクトの別サーバへの自動的な移行をコンフィグレーションすることができます。自動的な移行の詳細については、『WebLogic Server クラスタユーザーズガイド』を参照してください。

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

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

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

現在、ネーミングサービスプロバイダは、ClusterAddress 属性で定義できるクラスタの DNS 名を使用して WebLogic の中から選択されます。この属性は、クラスタに接続するためにクライアントで使用されるアドレスを定義します。このアドレスは、複数の IP アドレスに対応する DNS ホスト名か、単一アドレスのホスト名または IP アドレスで構成されるカンマ区切りのリストのいずれかになります。ネットワークチャネルがコンフィグレーションされている場合は、クラスタアドレスをチャネルごとに設定できます。『WebLogic Server クラスタユーザーズガイド』を参照してください。

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

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

コードリスト 3-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 クラスタユーザーズガイド』の「クラスタのコンフィグレーションとアプリケーションのデプロイメント」を参照してください。

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

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

次の例では、同じポートを使用する WebLogic Server のリストが指定されています。

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

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

次の例では、異なるポートを使用する WebLogic Server のリストが指定されています。

ht.put(Context.PROVIDER_URL,"t3://node1:7001,node2:7002,node3:7003");

複数のサーバにマップする DNS 名を使用する場合、WebLogic Server は DNS に依存してロードバランシングを行います。

WebLogic Server ノードの DNS 名をカンマで区切ったリストを使用する場合は、フェイルオーバがラウンドロビン方式で実行されます。この方式では、リスト内のランダムに選択されたサーバにリクエストを送り、そのサーバが応答に失敗すると、その後はリスト内の次のサーバにリクエストを送ります。サーバが応答に失敗するたびに次のサーバで続行します。

クライアントがコンテキストを受け取った後は、失敗がない限り、それ以上のロードバランシングは生じません。失敗があった場合、WebLogic Server はクラスタ内の別のノードへフェイルオーバを行います。

リモートクライアントは、最初に使用可能なサーバからコンテキストを取得します。クラスタ内のサーバのローカルクライアントは、リモートサーバで JNDI 操作を行うことはありません。

スタブをルックアップすると、そのスタブの最初の呼び出しは通常、コンテキストの取得元のサーバに送られます。スタブがクラスタ可能な場合、その後の呼び出しは、ユーザ定義のロードバランシングポリシーに基づいてロードバランシングされます。

JNDI とクラスタの詳細については、「WebLogic Server のクラスタ化について」を参照してください。

J2EE コンポーネント内からの JNDI の使い方

J2EE コンポーネントからグローバル環境を直接使用することは可能ですが、コンポーネント環境を使用することをお勧めします。J2EE アプリケーション内の各 J2EE コンポーネントには、コンポーネントのデプロイメント記述子に含まれる情報に基づいて設定される独自のコンポーネント環境がありました。

J2EE コンポーネントは以下のコードを使用して独自のコンポーネントをルックアップできます。

Context ctx = new InitailContext();

Context comp_env = (Context)ctx.lookup("java:comp/env");

J2EE コンポーネント内での操作であるため、接続情報を定義するための Hashtable または Environment オブジェクトを設定する必要はありません。

このコンテキストはグローバル環境と同じ方法で使用します。ただし、使用する名前は、コンポーネントのデプロイメント記述子に定義された名前です。たとえば、デプロイメント記述子に次のような ejb-ref があるとします。

<ejb-ref>

...

<ejb-ref-name>ejb1</ejb-ref-name>

<ejb-ref-type>Session</ejb-ref-type>

...

</ejb-ref>

<ejb-ref-name> で定義された名前をルックアップします。この場合は ejb1 です。

グローバル環境ではなくコンポーネント環境を使用して JNDI 名を設定すると、JNDI 名によって参照される名前がデプロイメント時に解決されるという利点があります。つまり、コードを書き換えなくても、名前の衝突を解決できるということです。

コンポーネント環境の設定と使用に関する詳細については、J2EE 仕様 (http://java.sun.com/j2ee/j2ee-1_3-fr-spec.pdf) を参照してください。

外部 JNDI の設定

外部 JNDI は、リモートの JNDI ツリーに直接接続しないでも、そのリモートツリーにあるオブジェクトへアクセスできるようにする API です。

これを使用すると、WebLogic Server や Java プログラム内の JNDI ツリーなど、別のサーバまたはプロバイダ上の JNDI ツリーへのリンクを作成できます。外部 JNDI をコンフィグレーション後は、WebLogic Server インスタンス内にバインドされたオブジェクトを使用するのと同じくらい容易に、別の場所にあるオブジェクトを使用できます。

外部 JNDI をコンフィグレーションするには、使用するオブジェクトがあるリモート JNDI プロバイダのアドレスで ForeignJNDIProvider を作成し、それらのオブジェクトにアクセスするためのユーザ名とパスワードを作成します。その後は、ローカル JNDI ツリー内の名前と、リモートツリー内のオブジェクトの関係を設定する、ForeignJNDILinks および ForeignJNDIObjects を作成できます。

外部 JNDI のコンフィグレーション方法の詳細については、Administration Console オンラインヘルプの「外部 JNDI プロバイダの作成」を参照してください。