ヘッダーをスキップ
Oracle® Fusion Middleware Oracle WebLogic Server JNDI プログラマーズ ガイド
11g リリース 1 (10.3.1)
B55539-01
 


 

Oracle® Fusion Middleware

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

11g リリース 1 (10.3.1)

B55539-01

2009 年 5 月

このマニュアルでは、WebLogic JNDI を設定する方法について説明します。WebLogic Server アプリケーションを開発しており、JNDI 機能を使用する必要のある開発者を対象としています。

このマニュアルは、Sun Microsystems の Java Platform, Enterprise Edition (Java EE) を使用してアプリケーションの設計、開発、コンフィグレーション、および管理を行い、エンタープライズ内で複数のネーミングおよびディレクトリ サービスに対し、統一されたインタフェースを提供するために JNDI API を使用する、アプリケーション開発者に向けて書かれています。読者には、JNDI および Java プログラミング言語に関する知識があることが前提となっています。

目次

このマニュアルは次のトピックから構成されています。

概要とロードマップ

以下の節では、このマニュアル『Oracle Fusion Middleware Oracle WebLogic Server JNDI プログラマーズ ガイド』の内容と構成について説明します。

このドキュメントの手引き

  • この章「概要とロードマップ」では、このマニュアルの構成を紹介します。

  • WebLogic JNDI について」では、WebLogic Server における Java Naming and Directory Interface (JNDI) 実装の概要を示します。

  • WebLogic JNDI」では、WebLogic JNDI によるプログラミングについて説明します。

関連ドキュメント

詳細については、以下のマニュアルを参照してください。

Web アプリケーション開発者向けのサンプル

このマニュアルに加えて、Avitek Medical Records アプリケーション (MedRec) サンプルのコンテキスト内で、ソフトウェア開発者向けのサンプル (JNDI サンプル コードを含む) が用意されています。

Avitek Medical Records アプリケーション (MedRec)

MedRec は WebLogic Server に付属したエンドツーエンドのサンプル Java EE アプリケーションであり、一元的で独立した医療記録管理システムをシミュレートします。MedRec アプリケーションには、患者、医師、および管理者に対して、さまざまなクライアントを使用して患者のデータを管理するフレームワークが用意されています。

MedRec は WebLogic Server と Java EE の機能を例示し、Oracle が推奨するベスト プラクティスを重要点として示します。MedRec は WebLogic Server 配布キットに含まれており、Windows マシンの [スタート] メニューからアクセスできます。Linux などのプラットフォームでは、WL_HOME\samples\domains\medrec ディレクトリから MedRec を起動します。WL_HOME は、WebLogic Platform の最上位のインストール ディレクトリです。

WebLogic Server 配布キットの JNDI サンプル

WebLogic Server では、必要に応じて API サンプル コードを WL_HOME\samples\server\examples\src\examples にインストールできます。WL_HOME は WebLogic Server の最上位インストール ディレクトリです。WebLogic Server のスタート メニューからサンプル サーバを起動して、サンプルとその実行手順に関する情報を確認できます。

このリリースでの新機能と変更点

このリリースで導入された WebLogic Server の新機能の一覧については、『Oracle Fusion Middleware Oracle WebLogic Server の新機能』を参照してください。

WebLogic JNDI について

以下の節では、WebLogic Server の Java Naming and Directory Interface (JNDI) 実装の概要について説明します。

JNDI とは

アプリケーションでは、ネーミング サービスを使用してネットワーク上のデータ ソース、EJB、JMS、MailSession などのオブジェクトを検索します。ネーミング サービスは、オブジェクトに名前を関連付けたり、指定した名前に基づいてオブジェクトを検索したりします。RMI レジストリは、ネーミング サービスの 1 つです。

JNDI は、LDAP (Lightweight Directory Access Protocol) や DNS (Domain Name System) など、既存のさまざまなネーミング サービスに対する共通インタフェースを提供します。これらのネーミング サービスは、バインディングのセットを管理します。名前はバインディングによってオブジェクトに関連付けられるので、オブジェクトを名前でルックアップできるようになります。したがって、JNDI を使用すると、分散アプリケーションのコンポーネントが互いを検索できます。

JNDI API (http://java.sun.com/products/jndi/index.html) は、特定のネーミング サービスまたはディレクトリ サービスの実装とは無関係に定義されています。JNDI では、複数の方法で、さまざまな新しいサービスや既存のサービスにアクセスできます。このサポートでは、標準サービス プロバイダ インタフェース (SPI) 規約を使用して JNDI フレームワークに任意のサービス プロバイダ実装をプラグインできます。

WebLogic Server の JNDI

WebLogic Server の JNDI 実装では、以下のようなメソッドが用意されています。

  • クライアントに WebLogic Server ネーミング サービスへのアクセスを提供するメソッド

  • オブジェクトを WebLogic ネームスペースで使用可能にするメソッド

  • オブジェクトを WebLogic ネームスペースから取り出すメソッド

各 WebLogic Server クラスタは、レプリケートされたクラスタワイドの JNDI ツリーによってサポートされています。このツリーから、レプリケートされたり、固定されたりしている RMI オブジェクトおよび EJB オブジェクトにアクセスできます。クラスタを表す JNDI ツリーは、クライアントからは単一のグローバル ツリーのように見えますが、クラスタワイドのサービスを含むツリーは、実際には、クラスタ内の各 WebLogic Server 間でレプリケートされたものです。詳細については、「クラスタ環境での WebLogic JNDI の使い方」を参照してください。

他の WebLogic サービスは、WebLogic Server JNDI に統合されたネーミング サービスを使用できます。たとえば、WebLogic RMI では、標準 RMI メソッドと JNDI メソッドの両方を使用して、リモート オブジェクトにバインドし、アクセスできます。

JNDI の標準 Java インタフェースに加えて、WebLogic Server には、標準 JNDI インタフェースを使用する独自の実装である weblogic.jndi.WLInitialContextFactory もあります。

このクラスを直接インスタンス化する必要はありません。代わりに、標準の javax.naming.InitialContext クラスを使用して、適切なハッシュテーブル プロパティを設定できます (「InitialContext への JNDI 環境プロパティの設定」を参照)。すべての対話は、javax.naming.Context インタフェースを経由して行われます (JNDI Javadoc を参照)。

クライアント接続用に WebLogic JNDI API を使用する手順については、「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 と対話するには、リモート オブジェクトへの参照を取得し、そのオブジェクトで操作を呼び出すことができなければなりません。そのためには、クライアント アプリケーション コードで次の手順を実行する必要があります。

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

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

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

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

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

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

JNDI を使用して WebLogic Server 環境内のオブジェクトにアクセスする前に、WebLogic Server の 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 になります。詳細については、「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 を使用すると、コンテキスト作成後に他のプロパティを変更できます。

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

コード リスト 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 プロトコルでは正しく動作しません。

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

コード リスト 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() 呼び出しによって誤ったユーザが返される場合があります。次の手順で、このシナリオについて説明します。

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

  2. 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 が決まります。次の手順で、このシナリオについて説明します。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ServiceBean bean = ServiceBean.Home.create("ejb.ServiceBean")
Servicebean.additem(66);

コンテキストのクローズ

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

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

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

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

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

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

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

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

WebLogic RMI を使用すると、ある JVM のクライアントが別の JVM のクライアントから EJB サービスや JMS サービスにアクセスできるようになります。RMI スタブは、RMI オブジェクトに対するクライアントからの呼び出しを受信し、マーシャリングします。クライアントで Java EE サービスを利用できるようにするために、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 プロパティを指定します。コード リスト 6 は、REPLICATE_BINDINGS プロパティの使い方を示しています。

コード リスト 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 オブジェクトの別サーバへの自動的な移行をコンフィグレーションすることができます。自動的な移行の詳細については、『Oracle Fusion Middleware Oracle 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 アドレスで構成されるカンマ区切りのリストのいずれかになります。ネットワーク チャネルがコンフィグレーションされている場合は、クラスタ アドレスをチャネルごとに設定できます。『Oracle Fusion Middleware Oracle WebLogic Server クラスタの使い方』の「クラスタでの通信」を参照してください。

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

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

コード リスト 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 は、このクラスタ内のネーミング サービスを提供するホストのリストにマップします。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server クラスタの使い方』の「クラスタのコンフィグレーションについて」を参照してください。

コード リスト 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 とクラスタの詳細については、『Oracle Fusion Middleware Oracle WebLogic Server クラスタの使い方』の「WebLogic Server のクラスタ化について」を参照してください。

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

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

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

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

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

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

<ejb-ref>
...
<ejb-ref-name>ejb1</ejb-ref-name> 
<ejb-ref-type>Session</ejb-ref-type>
<home>ejb1.EJB1Home</home>
<remote>ejb1.EJB1</remote>
...
</ejb-ref>

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

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

外部 JNDI の設定

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

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

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

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

ドキュメントのアクセシビリティについて

オラクル社は、障害のあるお客様にもオラクル社の製品、サービスおよびサポート・ドキュメントを簡単にご利用いただけることを目標としています。オラクル社のドキュメントには、ユーザーが障害支援技術を使用して情報を利用できる機能が組み込まれています。HTML形式のドキュメントで用意されており、障害のあるお客様が簡単にアクセスできるようにマークアップされています。標準規格は改善されつつあります。オラクル社はドキュメントをすべてのお客様がご利用できるように、市場をリードする他の技術ベンダーと積極的に連携して技術的な問題に対応しています。オラクル社のアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/accessibility/を参照してください。

ドキュメント内のサンプル・コードのアクセシビリティについて

スクリーン・リーダーは、ドキュメント内のサンプル・コードを正確に読めない場合があります。コード表記規則では閉じ括弧だけを行に記述する必要があります。しかしJAWSは括弧だけの行を読まない場合があります。

外部Webサイトのドキュメントのアクセシビリティについて

このドキュメントにはオラクル社およびその関連会社が所有または管理しないWebサイトへのリンクが含まれている場合があります。オラクル社およびその関連会社は、それらのWebサイトのアクセシビリティに関しての評価や言及は行っておりません。

聴覚に障害があるお客様のOracleサポート・サービスへのアクセス

Oracleサポート・サービスに連絡するには、テレコミュニケーション・リレー・サービス(TRS)を使用してOracleサポート(+1-800-223-1711)までお電話ください。Oracleサポート・サービスの技術者が、Oracleサービス・リクエストのプロセスに従って、技術的な問題を処理し、お客様へのサポートを提供します。TRSの詳細は、http://www.fcc.gov/cgb/consumerfacts/trs.htmlを参照してください。電話番号の一覧は、http://www.fcc.gov/cgb/dro/trsphonebk.htmlを参照してください。

サポートおよびサービス

次の各項に、各サービスに接続するためのURLを記載します。

Oracleサポート・サービス

オラクル製品サポートの購入方法、およびOracleサポート・サービスへの連絡方法の詳細は、次のURLを参照してください。

http://www.oracle.com/lang/jp/support/index.html

製品マニュアル

製品のマニュアルは、次のURLにあります。

http://www.oracle.com/technology/global/jp/documentation/index.html

研修およびトレーニング

研修に関する情報とスケジュールは、次のURLで入手できます。

http://education.oracle.com/pls/web_prod-plq-dad/db_pages.getpage?page_id=3

その他の情報

オラクル製品やサービスに関するその他の情報については、次のURLから参照してください。

http://www.oracle.com/lang/jp/index.html 
http://www.oracle.com/technology/global/jp/index.html 

注意:

ドキュメント内に記載されているURLや参照ドキュメントには、Oracle Corporationが提供する英語の情報も含まれています。日本語版の情報については、前述のURLを参照してください。 



Oracle Fusion Middleware Oracle WebLogic Server JNDI プログラマーズ ガイド、11g リリース 1 (10.3.1)

B55539-01

Copyright © 2007, 2009, Oracle and/or its affiliates. All rights reserved.

制限付権利の説明

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアおよび関連ドキュメントが米国政府機関、もしくは米国政府機関に代わってこのソフトウェアをライセンスまたは使用する者に提供される場合は、次の注意が適用されます。

U.S. GOVERNMENT RIGHTS

Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, the use, duplication, disclosure, modification, and adaptation shall be subject to the restrictions and license terms set forth in the applicable Government contract, and, to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, Commercial Computer Software License (December 2007). Oracle USA, Inc., 500 Oracle Parkway, Redwood City, CA 94065.

このソフトウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアを危険が伴うアプリケーションで使用する際、このソフトウェアを安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

Oracle は Oracle Corporation およびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

このソフトウェアおよびドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。