(57)【要約】【課題】  クライアントに提供されるプロキシ・サービスに混乱を生じさせることなく、関連する分散ディレクトリの動的トポロジ変更に適合した、方法、プロキシ・サーバ、及びプロキシ・ディレクトリ・システムを提供する。【解決手段】  プロキシ・ディレクトリ・サーバは、起動の直後かつクライアント要求の受信前に、分散ディレクトリ・サーバのトポロジを発見する。起動の直後に、プロキシ・サーバは、ディレクトリ分散情報に対応する構造化データを分散ディレクトリ・サーバから抽出するためのクエリを実行する。分散ディレクトリ・サーバの動的トポロジ再構成は、動作中にプロキシにおいてトポロジ情報に直接行われ、ディレクトリ更新動作によって分散ディレクトリ・サーバに伝達される、いずれかの動的構成変更によって達成される。【選択図】  図３
2010511948.tif 000002
【特許請求の範囲】
【請求項１】
１つ又は複数の分散ディレクトリ・サーバ（４６、４８、５０）をプロキシするプロキシ・ディレクトリ・サーバ（４２）を、前記プロキシ・ディレクトリ・サーバを起動した直後かつ前記プロキシ・ディレクトリ・サーバがクライアント要求を受信する前に、構成するための方法であって、
前記プロキシ・ディレクトリ・サーバに接続情報を格納するステップであって、前記接続情報は、前記ディレクトリ・サーバとの通信を認証してセットアップするために前記プロキシ・ディレクトリ・サーバが必要とする証明を含む、ステップと、
前記接続情報を用いて前記プロキシ・ディレクトリ・サーバを前記分散ディレクトリ・サーバのうちの１つ又は複数と接続するステップと、
前記分散ディレクトリ・サーバのうち接続に成功した分散ディレクトリ・サーバについて、前記接続された分散ディレクトリ・サーバのトポロジを作成するために構造化データを抽出するクエリを実行するステップであって、前記トポロジは、ディレクトリが複数のディレクトリ・サーバ間でどのようにパーティショニングされるかに関する情報を含む、ステップと、
を含む方法。
【請求項２】
前記接続情報は、Ｕｎｉｖｅｒｓａｌ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ、識別名、及びパスワードを含む、請求項１に記載の方法。
【請求項３】
各々の前記接続された分散ディレクトリ・サーバについての前記構造化データは、それぞれの前記分散ディレクトリ・サーバへの名前付けコンテキストのマッピングと、前記分散ディレクトリ・サーバのどれが複製されたコンテキストのマスタであるかに関する情報とを含む、請求項１に記載の方法。
【請求項４】
前記クエリは、それぞれの前記分散ディレクトリ・サーバによって以前に戻された名前付けコンテキスト属性の各々の値についてのさらに別のクエリを含む、請求項３に記載の方法。
【請求項５】
前記クエリの結果に変更が発生したときに前記トポロジを再構成するステップをさらに含む、請求項１に記載の方法。
【請求項６】
結果の変更の前記発生は、クエリを定期的に繰り返すことによって判断される、請求項５に記載の方法。
【請求項７】
結果の変更の前記発生は、前記分散ディレクトリ・サーバからの通知によって判断される、請求項５に記載の方法。
【請求項８】
前記分散ディレクトリ・サーバのトポロジを動的に再構成するステップをさらに含む、請求項１に記載の方法。
【請求項９】
前記再構成は、前記分散ディレクトリ・サーバに格納された前記構造化データを修正するように構成されたディレクトリ更新操作によって達成される、請求項８に記載の方法。
【請求項１０】
前記更新された構造化データは、それぞれの前記分散ディレクトリ・サーバへの名前付けコンテキストのマッピング、及び、前記分散ディレクトリ・サーバのどれが複製されたコンテキストのマスタであるかを表す、請求項９に記載の方法。
【請求項１１】
前記再構成は、前記分散ディレクトリ・サーバに新たなサーバを追加することと、前記分散ディレクトリ・サーバから既存のサーバを除去することとのうちの少なくとも一方によって達成される、請求項８に記載の方法。
【請求項１２】
前記接続情報を修正するステップと、
再構成された分散ディレクトリ・サーバのトポロジに対応する構造化データを抽出するために前記クエリを再実行するステップと、
をさらに含む、請求項１に記載の方法。
【請求項１３】
前記請求項のいずれかに記載の前記方法のすべてのステップを実行するのに適した手段を含むシステム。
【請求項１４】
コンピュータ・システム上で実行されたときに、前記請求項のいずれかに記載の前記方法のすべてのステップを実行するための命令を含むコンピュータ・プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、プロキシを伴う分散ディレクトリのための方法、プロキシ・サーバ、及びプロキシ・ディレクトリ・システムに関する。
【背景技術】
【０００２】
ディレクトリは、読み取りアクセスのために最適化された専門データベースであり、実世界における異なる種類のエンティティ（人物、リソース、ポリシー、サービス、アプリケーションなど）に関する情報を、そうしたエンティティを企業におけるセキュリティ及び識別情報の管理フレームワークの重要な要素とする単一のインスタンスに格納する機能を有する。典型的には、ディレクトリは、エントリのディレクトリ情報ツリー（ＤＩＴ）から成る。一例として、インターネットを介してディレクトリにアクセスする標準的な方法は、ＬＤＡＰ（Lightweight Directory Access Protocol(v3):TechnicalSpecification,RFC3377,http://www.ietf.org/rfc/rfc3377.txt）であり、これによって、複数のサーバにわたるＤＩＴの分散が可能になる。ＬＤＡＰは、照会メカニズム（referral mechanism）を用いて、ディレクトリ操作の分散処理をサポートする。各々のサーバは、名前付けコンテキスト（naming context）と呼ばれるエントリのサブツリーと、関連コンテキストを含む他のサーバへの参照とを含む。サーバは、クライアント要求に完全に応えることができないときには、別のサーバについての照会をクライアントに返信する。これには、操作処理に非常に時間がかかるという欠点がある。
【０００３】
分散ディレクトリのためのＬＤＡＰプロトコル及びサポート
ＬＤＡＰは、ＴＣＰ／ＩＰを介してＸ．５００情報モデルに準拠したディレクトリにアクセスする標準的な方法である。ＬＤＡＰｖ３は、ＲＦＣ２２５１、ＲＦＣ２２５２（http://www.ietf.org/rfc/rfc2251.txt及びhttp://www.ietf.org/rfc/rfc2252.txt）によって定められるように、ディレクトリにアクセスするために用いられる機能モデルに加えて、情報モデル、名前付けモデル及びセキュリティ・モデルを指定する。
【０００４】
ＬＤＡＰ情報及び名前付けモデル
ＬＤＡＰは、エントリから成るＤＩＴに共通にアクセスする１つ又は複数のディレクトリ・サーバが存在することを想定している。エントリは、必須属性及び任意属性を定める必要なオブジェクト・クラス属性を持つ属性値ペアの組と定義される。各々のエントリは、階層型名前空間（hierarchical namespace）に属する識別名（ＤＮ）を有する。ＤＩＴのルートは、ＤＮ「ｎｕｌｌ」を有する。図１は、ｉｎｅｔＯｒｇＰｅｒｓｏｎ［ＲＦＣ２７９８］エントリを有する例示的なディレクトリ・ツリー１０を示す。各々のノード（円で表される）は、相対ＤＮ（ＲＤＮ）を用いて名前が付けられる。エントリのＤＮは、そのＲＤＮを親ＤＮの前に付けることによって作成される。
【０００５】
機能モデル
ＬＤＡＰによって採用される機能モデル［ＲＦＣ２２５１］は、サーバに対するプロトコル操作を実施するクライアントの１つである。ＬＤＡＰは、３つのタイプの操作、すなわち、検索、比較などのクエリ操作と、追加、修正、削除、ＤＮ修正（エントリ移動）などの更新操作と、バインド、バインド解除、放棄などの接続／解除操作とを定める。追加操作は、個々のエントリをディレクトリに追加するのに用いられ、削除操作は、個々のエントリをディレクトリから削除するのに用いられる。修正操作は、エントリの１つ又は複数の属性について１つ又は複数の値を追加、削除又は置換するのに用いることができる。
【０００６】
ディレクトリは、読み取りアクセスのために最適化されているため、最も一般的なＬＤＡＰ操作は検索であり、検索は、ディレクトリから情報にアクセスする融通性のある手段を提供する。ＬＤＡＰ検索操作（クエリとも呼ばれる）は、クエリと関連付けられた意味情報を表す以下のパラメータ、すなわち、（ｉ）ベース：ＤＩＴにおける検索の開始点を定めるＤＮ、（ｉｉ）スコープ：｛ＢＡＳＥ、ＳＩＮＧＬＥ、ＳＵＢＴＲＥＥ｝が、ベースから検索するためのＤＩＴ内の深さを特定する、（ｉｉｉ）フィルタ：一般的な演算子であるＡＮＤ（＆）、ＯＲ（｜）及びＮＯＴ（！）を用いる述語のブール組み合わせであり、検索条件を特定する、（ｉｖ）属性：フィルタに適合するエントリからの必要な属性の組、から成る。特殊値「＊」は、すべてのユーザ属性を選択することに相当する。ディレクトリにおける各々のエントリは、少なくとも１つの（オブジェクト）クラスに属し、したがって、フィルタ（オブジェクト・クラス＝＊）は、ディレクトリにおけるすべてのエントリに適合する。ＬＤＡＰフィルタは、ＲＦＣ２２５４［３］の括弧前置表記（parentheses prefixnotation）、例えば(&(sn=Doe)(givenName=John))を用いて表される。述語の例として、（ｓｎ＝Ｄｏｅ）、（ａｇｅ≧３０）、（ｓｎ＝ｓｍｉｔｈ＊）があり、“Ｄｏｅ”、“３０”及び“ｓｍｉｔｈ＊”は、それぞれ等価、範囲及び文字列のアサーションを表すアサーション値である。
【０００７】
分散ディレクトリ・モデル
ＬＤＡＰは、ディレクトリを、各々が１つ又は複数の名前付けコンテキストを保持する複数のサーバに分割することをサポートする。名前付けコンテキストは、接尾辞（suffix）として知られるエントリをルートとし、リーフ・エントリ又は特殊な照会オブジェクトによって終了する、ＤＩＴのサブツリーである。照会オブジェクトは、他の従属名前付けコンテキスト（subordinate naming context）を保持するサーバを指し示す。ＤＩＴを指し示す（point down）これらの従属照会（subordinatereferrals）に加えて、サーバは、ＤＩＴにおいてＤＩＴのルートに近いサーバを指し示す（point upwards）上位（又はデフォルト）照会も持つように構成される。照会オブジェクトに遭遇したときには、それらを用いて、クライアントのための照会メッセージが作成される。照会メッセージは、ldap://<host>:<port>/<DN>の形式のＬＤＡＰ  ＵＲＬを含み、ここでＤＮは、指し示されている名前付けコンテキストの接尾辞であり、ｈｏｓｔは、名前付けコンテキストを含むサーバの、完全に記述された（fully qualified）ドメイン名又はＩＰアドレスである。クライアントは、照会された１つ又は複数のサーバとコンタクトを取ることによって、操作を進める。
【０００８】
いずれかのディレクトリ操作が実施される前に、対象オブジェクト（例えば、検索要求のベース）を探さなければならない。分散ディレクトリにおいては、これは、「分散名前解析（distributed name resolution）」と呼ばれる。一般に、分散名前解析は、ルート、又は、対象オブジェクトの先祖である接尾辞を有する名前付けコンテキストのいずれかに遭遇するまで、デフォルト照会を介してＤＩＴを上方に進む。この後、分散名前解析は、対象オブジェクトに遭遇するまで、従属照会を介してＤＩＴを下方に進む。対象が判明すると、対象が発見されたサーバで操作評価段階が開始する。評価段階の間に従属照会に遭遇するサブツリー範囲指定検索（subtree scoped search）は、クライアントに照会メッセージを送信して操作を進める。
【０００９】
図２は、ｏ＝ｘｙｚ名前空間を共同で提供する３つのサーバ、ホストＡ２２、ホストＢ２４及びホストＣ２６を有するシステム２０を示す。ホストＡ２２は、ｏ＝ｘｙｚを接尾辞とする単一の名前付けコンテキストを含み、従属サーバであるホストＣ２６及びホストＢ２４のそれぞれによって保持されるｃ＝ｉｎサブツリー及びｏｕ＝ｒｅｓｅａｒｃｈ、ｃ＝ｕｓサブツリーの下にあるエントリを除く、ｏ＝ｘｙｚの下にあるすべてのエントリを含む。クライアント２８は、ホストＢ２４から、ベースをｏ＝ｘｙｚとするサブツリー検索を要求する。ホストＢ２４は、対象を含まないため、デフォルト照会を用いてクライアントにホストＡ２２を照会させる。クライアント２８は、対象オブジェクトを含むホストＡ２２にコンタクトする。ホストＡ２２は、保持するパーティションに対して検索を実施し、３つの適合するエントリ及び照会（ホストＢ２４及びホストＣ２６については、従属名前付けコンテキスト）をクライアントに戻す。最後に、クライアント２８は、（ベースが修正された）検索要求をホストＢ２４及びホストＣ２６に送信し、両ホストは、残りのエントリを戻す。１つの要求を評価するために、クライアントとサーバとの間で４回のやりとりが必要となる。最悪の場合には、クライアントとサーバとの間で交換されるメッセージの全往復回数は、サーバ数のほぼ２倍に達する。この例は、ＬＤＡＰにおける照会ベースの分散クエリ評価メカニズムがなぜ遅いのかを示すものである。
【００１０】
他のソリューション
照会を排除する１つの方法は、ＩＴＵ−Ｔ勧告  X.500:Open Systems Interconnection-The Directory:Overview ofconcept,models and services、及び、X.518|9594「Part4:Procedures forDistributed Operationsに記載されるように、ディレクトリ要求の連鎖（chaining）を用いることである。この手法では、照会をクライアントに返送する代わりに、サーバは、照会されたサーバに要求を「連鎖」させ、その結果をクライアントに転送する。しかしながら、一般に、クライアントがサーバに含まれていない対象エントリを要求した場合には、連鎖は非効率となる可能性がある。このような場合には、エントリＤＮのソリューションが必要であり、連鎖には多数のサーバが関係することがあるため、クライアントに到達する前に幾つかのサーバ間で結果を流すことが必要である。この結果、不要なサーバ間通信が生じる。
【００１１】
照会を排除するより良い方法は、分散ディレクトリのフロント・エンドに「ディレクトリ・プロキシ（これ以降「プロキシ」という）」を有することである。プロキシは、典型的には、クライアントと分散ディレクトリ・サーバとの間に配置される。プロキシは、クライアント要求を傍受するサーバとして機能することも、クエリを評価するための分散ディレクトリ・サーバに対するクライアントとして機能することもできる。プロキシは、分散環境においてディレクトリ内の名前付けコンテキストがどのようにサーバにマッピングされているかに関する知識を有する。このディレクトリ・トポロジ情報を持つように構成されたプロキシを用いて、クライアントの操作を（必要に応じて）サブ操作に分散すること、要求を適切なサーバにルーティングすること、及び、統合された結果をクライアントに送信することができる。現在のプロキシ・ディレクトリ・ソリューション（例えば、オープンソースＯｐｅｎＬＤＡＰサーバ、http://www.openldap.orgの「プロキシ・ディレクトリ」）は、トポロジ情報を持つようにプロキシを構成することに基づいている。
【００１２】
プロキシにおいてこうしたパーティション情報の静的構成を用いることに関する欠点は、分散ディレクトリを構成する各々のサーバが、名前付けコンテキストを追加／除去することを可能にする独自の管理インターフェースを有することである。ディレクトリ・プロトコルは、クライアント（又はこの場合にはプロキシ）への更新の通知をサポートしない。さらなる欠点は、分散ディレクトリ構成に変更を行うための中心となる方法がないことである。例えば、ディレクトリ設定の構成変更は、複数のディレクトリ・サーバにおける変更を必要とすることがある。現在のソリューションに伴うさらなる欠点は、分散ディレクトリを管理することがますます難しくなり、プロキシにおけるトポロジ情報に起因するディレクトリ・クエリの不正確な評価につながることである。
【発明の概要】
【発明が解決しようとする課題】
【００１３】
本発明の目的は、クライアントに提供されるプロキシ・サービスに何ら混乱を生じさせることなく、関連する分散ディレクトリの動的トポロジ変更に適合した、方法、プロキシ・サーバ、及びプロキシ・ディレクトリ・システムを提供することである。
【００１４】
本発明のさらなる目的は、プロキシ・サーバを通して分散ディレクトリ・サーバの特定の構成属性の集中管理（動的再構成と呼ばれる）をサポートする、方法、プロキシ・サーバ、及びプロキシ・ディレクトリ・システムを提供することである。
【課題を解決するための手段】
【００１５】
本発明は、ディレクトリ標準の一般的な実装形態では、（パーティショニング及び複製などの）「ディレクトリ分散情報」を、構造化データ（すなわち、ディレクトリ・スキーマに適合するデータ）として、分散ディレクトリ・サービスに関与するディレクトリ・サーバ内に格納するということを利用する。
【００１６】
本発明は、プロキシに格納されたトポロジ情報と実際の分散ディレクトリ・トポロジとの間の双方向同期を提供する。トポロジ変更に対するプロキシの「オンライン」での動作は、トポロジ発見と、一方向の同期を行うトポロジ適応とを実装することによって、達成される。さらに、他の方向の同期を行う動的トポロジ再構成を実装することができる。
【００１７】
実施形態によれば、プロキシ・ディレクトリ・サーバは、起動の直後かつクライアント要求の受信前に、分散ディレクトリ・サーバのトポロジを発見するように構成される。有利な点は、プロキシ・ディレクトリ・サーバは、トポロジ情報を持つように構成されないことである。その代わりに、プロキシ・ディレクトリ・サーバは、プロキシ・サービスを提供することが予想される分散ディレクトリ・サーバの各々への接続情報を持つように構成される。起動の直後に、プロキシ・ディレクトリ・サーバは、ディレクトリ分散情報に対応する構造化データを分散ディレクトリ・サーバから抽出する特定の専用クエリを実行する。
【００１８】
分散ディレクトリの動的トポロジ再構成は、以下のようにプロキシ・サーバを通して達成される：動作中にプロキシ・ディレクトリ・サーバにおいてトポロジ情報に直接加えられた動的構成変更は、ディレクトリ更新動作によって分散ディレクトリ・サーバに伝達される。こうした更新動作は、トポロジ発見段階で発見された分散ディレクトリ・サーバ内の同一の構造化データに適用される。
【００１９】
発見されたトポロジ情報は、分散ディレクトリ・サーバと同期した専用クエリに対応するプロキシ・サーバのフィルタを保持することによって、最新に保たれる。
【図面の簡単な説明】
【００２０】
【図１】公知のＬＤＡＰディレクトリ情報ツリー及び関連エントリの例を示す。
【図２】分散クエリ処理のための典型的なサーバ・システムを示す。
【図３】プロキシ・ディレクトリ・システムの概略的なブロック図である。
【図４】二分木で表された６つの名前付けコンテキストを示す。
【図５】図１から図４の発生器、アーキテクチャ及び方法を実装するのに用いることができるコンピュータ・システムの概略的なブロック図である。
【発明を実施するための形態】
【００２１】
概要
図３は、プロキシ・ディレクトリ・システム４０を示す。システム４０は、まず、プロキシ・ディレクトリ・サーバ４２を含む。プロキシ・ディレクトリ・サーバ４２は、クライアント・サーバ４４と接続され、クライアント・サーバ４４からディレクトリ要求（クライアント要求）を受信する。プロキシ・ディレクトリ・サーバ４２はまた、それぞれホスト１、ホスト２及びホスト３として特定される複数のディレクトリ・サーバ４６、４８、及び５０と接続される。プロキシ・ディレクトリ・サーバ４２は、プロセッサ６２及びデータ・ストア６４も含み、その機能は以下に説明される。
【００２２】
ディレクトリ・トポロジの発見
プロキシ・ディレクトリ・サーバ４２は、クライアント要求をルーティングすることができるように、以下のトポロジ情報、すなわち、
（ｉ）名前付けコンテキストのサーバへのマッピング
（ｉｉ）どのサーバが複製されたコンテキストのマスタであるかの判断
を必要とする。
【００２３】
プロキシ・ディレクトリ・サーバ４２は、名前付けコンテキストをサーバにマッピングするために、以下のステップを実施する。
１．プロキシ・ディレクトリ・サーバ４２は、データ・ストア６４に、ディレクトリ・サーバ４６、４８及び５０についての接続情報（証明書）を格納する。１つの例においては、この情報は、ＵＲＬ（ＬＤＡＰ  ＵＲＬ）、識別名（ＤＮ）及びパスワードである。起動時に、プロキシ・ディレクトリ・サーバ４２のプロセッサ６２は、接続情報を用いてディレクトリ・サーバ４６、４８及び５０に（例えばＬＤＡＰバインド要求を用いて）接続する。
【００２４】
２．すべてのディレクトリ・サーバ接続が成功した場合には、ブール型局所変数ｐａｒｔｉａｌ＿ｒｅｓｕｌｔｓはＦＡＬＳＥに設定される。それ以外の場合には、ｐａｒｔｉａｌ＿ｒｅｓｕｌｔｓはＴＲＵＥに設定される。コンタクトすることができないディレクトリ・サーバ４６、４８、及び５０については、「Ｔｒｅｔｒｙ＿ｌｉｍｉｔ」と定義される試行の制限値に達するまで、所定の間隔「Ｔｒｅｔｒｙ＿ｉｎｔｅｒｖａｌ」で要求が送信される。
【００２５】
３．プロキシ・ディレクトリ・サーバ４２は、ディレクトリ・サーバ４６、４８、５０に保持されている名前付けコンテキストを取得するために、接続が成功したディレクトリ・サーバの各々に対してクエリを送信する。プロキシ・ディレクトリ・サーバ４２は、ｂａｓｅ：“”、ｓｃｏｐｅ：ｂａｓｅ、ｆｉｌｔｅｒ：（ｏｂｊｅｃｔｃｌａｓｓ＝＊）、ａｔｔｒｓ：｛ｎａｍｉｎｇｃｏｎｔｅｘｔｓ｝を有するＬＤＡＰ検索要求を、ＬＤＡＰディレクトリに対して送信することができる。このクエリは、サブツリーのルートから名前付けコンテキスト属性値を取り出す。この属性は多値であり、そうした値の例としては、ｃｎ＝ｕｓｅｒｓ、ｄｃ＝ｘｙｚ、ｄｃ＝ｃｏｍ、及び、ｃｎ＝ｇｒｏｕｐｓ、ｄｃ＝ｘｙｚ、ｄｃ＝ｃｏｍがある。
【００２６】
４．ネーミング・コンテキスト属性値は、ディレクトリ・サーバ４６、４８、５０の各々に保持された名前付けコンテキストのルートをプロキシ・ディレクトリ・サーバ４２に与える。しかしながら、名前付けコンテキストは、照会エントリ内で終了する場合には、エントリの完全なサブツリーではないことがある。照会エントリを取り出すために、ディレクトリ・サーバ４６、４８、５０によって戻された名前付けコンテキスト属性の各々の値について、別のクエリが送信される。ＬＤＡＰクエリ、ｂａｓｅ：＜ｎａｍｉｎｇ  ｃｏｎｔｅｘｔ  ｖａｌｕｅ＞、ｓｃｏｐｅ：ｓｕｂｔｒｅｅ、ｆｉｌｔｅｒ：（ｏｂｊｅｃｔｃｌａｓｓ＝ｒｅｆｅｒｒａｌ）、ａｔｔｒｓ：ｒｅｆを用いて、すべての照会ＵＲＬを取り出すことができる。
【００２７】
５．ディレクトリ・サーバ４６、４８、５０において定められた名前付けコンテキストが完全に発見されると、この情報を用いてルーティング・テーブルが作成される（及び、データ・ストア６４に格納される）。ルーティング・テーブルは、ディレクトリ・サーバ４６、４８、５０内の固有の名前付けコンテキストを、それらの名前付けコンテキストを含むサーバ・ホスト名にマッピングする。名前付けコンテキストは、そのルートと０又は複数の照会とによって、完全に定義される。図２の場合には、名前付けコンテキスト対サーバのテーブルは、以下の通りである。
【表１】
2010511948.tif 000003
【００２８】
複製が存在しない場合（上記の例のように）には、ルーティング・テーブルは、名前付けコンテキストとディレクトリ・サーバとの間で１対１マッピングを有することになる。複製が存在する場合には、複数のディレクトリ・サーバ（すなわちサーバ４６、４８、５０）は、所与の名前付けコンテキストを含むことができる。このテーブルは、プロキシ・ディレクトリ・サーバ４２において読み取り専用のクライアント要求をルーティングするのに用いることができるが、マスタ情報を含まないため、更新操作のための別のテーブルが必要となる。
【００２９】
６．ディレクトリにおける複製の単位は、名前付けコンテキストである。典型的には、（ディレクトリ・サーバ間の）複製承諾（replication agreement）の詳細は、複製された名前付けコンテキストのルート・エントリと関連付けられたサブエントリ又は属性に格納される。照会を取り出すために用いられるクエリと同様のクエリを用いて、名前付けコンテキストを含むディレクトリ・サーバがその特定の名前付けコンテキスト属性についてのマスタであるかスレーブであるかを指定する複製承諾から、属性を取り出すことができる。
【００３０】
７．マスタ／スレーブ情報が利用可能になると、名前付けコンテキストを、その名前付けコンテキストの「マスタ」となるディレクトリ・サーバ４６、４８、５０にマッピングする、新たなルーティング・テーブルが作成される。プロキシ４２は、このテーブルを用いてクライアント４４からの更新要求をルーティングすることができる。
【００３１】
前述のように、接続情報とは、ディレクトリ・サーバ４６、４８、５０との通信を認証してセットアップするためにプロキシ・ディレクトリ・サーバ４２（又はクライアント）が必要とする証明書（例えば、ユーザネーム、パスワード、又はＸ５０９認証）のことをいう。一方、トポロジ情報は、ディレクトリが複数のサーバ間でどのようにパーティショニングされるかに関する知識である。有利な点として、本明細書で開示されるプロキシ・ディレクトリ・サーバ４２は、接続情報のみを持つように構成される。プロキシ・ディレクトリ・サーバ４２は、上記のステップ３、４、及び６で説明されたように、分散ディレクトリ・サーバに対してクエリを実行することによって、トポロジ情報を発見する。
【００３２】
例示的な実施形態は、プロキシ・ディレクトリ・サーバ４２におけるトポロジ発見及び同期を提供する。トポロジ情報は、プロキシ・ディレクトリ・サーバ４２に格納されるメタ情報の一例である。従って、プロキシ・ディレクトリ・サーバの主な機能は、クライアント要求をルーティングすることであり、トポロジ情報は、考慮される唯一のメタ情報である。
【００３３】
トポロジ変更への適合
プロキシ・ディレクトリ・サーバ４２は、分散ディレクトリ・サーバ４６、４８、５０のトポロジ変更に適合するように、以下の２つの手法のうちの１つを用いることができる。
（ｉ）（名前付けコンテキスト、照会及び複製承諾についての）トポロジ・クエリを周期的にディレクトリ・サーバ４６、４８、５０に送信する、すなわち、トポロジ変更についてディレクトリ・サーバにポーリングする。
（ｉｉ）ディレクトリ・サーバが、クエリを行う持続モード（クエリ結果が送信された後も接続が終了せず、その後のコンテンツへの変更はいずれも同じ接続で送信される）をサポートする場合には、トポロジ・クエリは、持続モードを用いて実施される。このモードでは、ディレクトリ・サーバ４６、４８、５０は、トポロジの変更をプロキシ・ディレクトリ・サーバ４２に通知する。
【００３４】
これらのモードのいずれかを用いて、プロキシ・ディレクトリ・サーバ４２で以下のトポロジ変更を検知することができる。
（ｉ）名前付けコンテキストがディレクトリ・サーバに追加される。
（ｉｉ）名前付けコンテキストがディレクトリ・サーバから削除される。
（ｉｉｉ）名前付けコンテキストがディレクトリ・サーバ上で修正される。
ケース（ｉｉｉ）は、名前付けコンテキストを除去して別の名前付けコンテキストを追加することと同等であり、別個に考慮されることはない。
【００３５】
名前付けコンテキストの追加
ディレクトリ・サーバ４６、４８、５０において新たな名前付けコンテキストが追加されるときには、３つの可能性が存在する。
（ｉ）その名前付けコンテキストが別のディレクトリ・サーバ上に存在する。
（ｉｉ）その名前付けコンテキストのどの部分も既存の名前付けコンテキストと重複しない。
（ｉｉｉ）その名前付けコンテキストのある部分が１つ又は複数の既存のディレクトリ・サーバと重複する。
【００３６】
ルートＤＮをｒｏｏｔとし、照会リストをＲｅｆｓとして持つ新たな名前付けコンテキストが、サーバと呼ばれるホストで発見された場合には、ルーチンＡＤＤＣＯＮＴＥＸＴ（以下に説明される）を用いてルーティング情報を更新することができる。「ＤｎＦｏｒｅｓｔ」は、各々のノードが名前付けコンテキストを表すツリーの集合体である。
【００３７】
各々のノードは、以下のフィールドを含む。
・ｄｎ：名前付けコンテキストのルートの識別名
・ＳｅｒｖｅｒＬｉｓｔ：その名前付けコンテキストを有するサーバのリスト
・Ｌｅｆｔｃｈｉｌｄ：第１の従属名前付けコンテキストを指す
・Ｒｉｇｈｔｃｈｉｌｄ：ピアの名前付けコンテキストを指す
【００３８】
図４は、二分木で表される６つの名前付けコンテキスト（円で表される）を示す。ノードの名前は、対応する名前付けコンテキストのルートである。名前付けコンテキストは、ｌｅｆｔｃｈｉｌｄがＮＩＬではない場合には、１つ又は複数の照会を有する。ｒｉｇｈｔｃｈｉｌｄは、照会連鎖における他の照会を指すのに用いられる。
【００３９】
【表２】
2010511948.tif 000004
【００４０】
説明：
ＩＳＳＵＦＦＩＸ（ｘ、ｙ）は、ｘがｙの先祖である場合にはＴＲＵＥを戻し、そうでなければＦＡＬＳＥを戻す。
ＩＮＩＴＴＲＥＥ（Ｔ）：ツリーを初期化する。
２行目〜１１行目：フォレストＤｎＦｏｒｅｓｔ内の各々の名前付けコンテキスト・ツリー全体をループする。各々のツリーＴについて、追加される名前付けコンテキストのルートが、ツリーのルートと一致するか又はその子孫であるかを判断する。いずれかの場合には、名前付けコンテキストのルート及びその照会を、関数ＩＮＳＥＲＴ（以下に説明される）を用いてＴに挿入する。
１２行目〜１９行目：こうした（名前付けコンテキストのルートを挿入することができる）ツリーが発見されない場合には、名前付けコンテキストを含む新たな名前付けコンテキスト・ツリーＮｅｗＴｒｅｅが作成され、ツリーのリスト（ＤｎＦｏｒｅｓｔ）に追加される。
【００４１】
以下のルーチンを検討する。
【表３】
2010511948.tif 000005
【００４２】
説明：
ＩＮＳＥＲＴ（ｘ、ｙ、ｉｓｒｏｏｔ、ｓｅｒｖｅｒ）は、ノードｘをｙの下のサブツリーに挿入する。挿入されているノードが名前付けコンテキストのルートである場合には、ｉｓｒｏｏｔはＴＲＵＥに設定され、ｓｅｒｖｅｒは名前付けコンテキストを含むホストである。
ＩＮＩＴＬＩＳＴ：リストを初期化する。
１行目〜２行目：ｙの下にノードが存在しない場合には、ｘをｙのｌｅｆｔｃｈｉｌｄにすることによってｙの下に置く。
５行目〜１８行目：ｙの従属コンテキストを通して反復し、追加されているノードを従属コンテキストのルートと比較する。６行目〜９行目は、追加されているノードが既に存在しているケース（ケース１）を扱う。このケースでは、追加されているノードがコンテキストのルートである場合には、名前付けコンテキストを含むサーバは、コンテキストのＳｅｒｖｅｒＬｉｓｔに追加される。１０行目〜１１行目は、ｘがｙの従属コンテキストの先祖であるケース（ケース２）を扱う。１２行目〜１６行目は、ｘがｙの従属コンテキストの子孫であるケース（ケース３）を扱う。これは、ＩＮＳＥＲＴへの再帰呼び出しを含む。１７行目は、残りのケース（ケース４）を扱う。ケース２及び４の場合には、１９行目〜２２行目は実際にノード挿入を行う。
【００４３】
名前付けコンテキストの除去
名前付けコンテキストの除去は、以下のルーチンによって実施される。
【表４】
2010511948.tif 000006
【００４４】
説明：
ルーチンＲＥＭＯＶＥＣＯＮＴＥＸＴ及びルーチンＲＥＭＯＶＥは、ＡＤＤＣＯＮＴＥＸＴ及びＩＮＳＥＲＴに類似している。引数の説明は、ｒｏｏｔ、Ｒｅｆｓが除去される名前付けコンテキストを指すこと以外は同じである。
【００４５】
動的トポロジ再構成
プロキシ・ディレクトリ・サーバ４２において構成された接続情報は、構造化データとして格納することができ、動作中に修正することができる。これにより、ディレクトリ・サーバ４６、４８、５０についての接続情報を追加／削除することによって新たなサーバの追加／除去をプロキシすることが可能になる。プロキシ・ディレクトリ・サーバ４２は、接続情報の変更を定期的にチェックし、接続情報が追加／修正された分散ディレクトリ・サーバ４６、４８、５０に接続／再接続する。
【００４６】
プロキシ構成からディレクトリ・サーバ４６、４８、５０を動的に追加及び除去することとは別に、プロキシ４２を介した分散ディレクトリのトポロジ変更も行うことができる。ディレクトリ・サーバ４６、４８、５０においてトポロジ構成の変更が必要な場合には、複数のディレクトリ・サーバの変更を手動で組み込むのではなく、プロキシ・ディレクトリ・サーバ４２に格納されたトポロジ情報を直接変更することができる。プロキシ・ディレクトリ・サーバ４２は、次に追加、削除及び修正などのディレクトリ更新操作を用いて、分散ディレクトリ・サーバの構造化データに対応する更新を行う。
【００４７】
コンピュータ・プラットフォーム
図５は、本明細書で説明される方法を実施するのに用いることができるコンピュータ・システム１００の概略的なブロック図を示す。より具体的には、コンピュータ・システム１００は、プログラム・コードから語彙素（lexemes）を生成し、２つ又はそれ以上のコード本体の間のコード変更記述を生成するようにプログラムされたコンピュータ・ソフトウェアを実行する。コンピュータ・ソフトウェアは、コンピュータ・システム１００にインストールされた、ＭＳ  Ｗｉｎｄｏｗｓ２０００ＴＭ、ＭＳ  ＷｉｎｄｏｗｓＸＰＴＭ、又はＬｉｎｕｘＴＭなどのオペレーティング・システムの下で動作する。
【００４８】
コンピュータ・ソフトウェアは、プログラムされた論理命令の組を含み、これらの論理命令の組は、命令によって指定される所定の機能を実施するようにコンピュータ・システム１００に命令するために、コンピュータ・システム１００によって実行することができる。コンピュータ・ソフトウェアは、直接又は別の言語、コード若しくは表記への変換後に、特定の機能を互換性のある情報処理システムに実施させるように意図された命令の組を含む、いずれかの言語、コード又は表記で表すか又は記録することができる。
【００４９】
コンピュータ・ソフトウェア・プログラムは、コンピュータ言語による命令文を含む。コンピュータ・プログラムは、コンパイラを用いて処理し、オペレーティング・システムによる実行に適したバイナリ形式にすることができる。コンピュータ・プログラムは、前述の方法の特定のステップを実施する種々のソフトウェア・コンポーネント又はコードを含むようにプログラムされる。
【００５０】
コンピュータ・システム１００のコンポーネントは、コンピュータ１２０と、入力装置１１０、１１５と、ビデオ・ディスプレイ１９０とを含む。コンピュータ１２０は、処理ユニット１４０と、メモリ・ユニット１５０と、入力／出力（Ｉ／Ｏ）インターフェース１６０と、通信インターフェース１６５と、ビデオ・インターフェース１４５と、記憶デバイス１５５とを含む。コンピュータ１２０は、前記のユニット、インターフェース及びデバイスのいずれかのうちの２つ以上を含むものとすることができる。
【００５１】
処理ユニット１４０は、オペレーティング・システムとそのオペレーティング・システムの下で動作するコンピュータ・ソフトウェアとを実行する１つ又は複数のプロセッサを含むことができる。メモリ・ユニット１５０は、ランダム・アクセス・メモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、フラッシュ・メモリ、及び／又は、処理ユニット１４０の命令の下で用いられる当該技術分野で公知の他のいずれかのタイプのメモリを含むことができる。
【００５２】
ビデオ・インターフェース１４５は、ビデオ・ディスプレイ１９０に接続され、ビデオ・ディスプレイ１９０に表示するためのビデオ信号を提供する。コンピュータ１２０を操作するためのユーザ入力は、それぞれキーボード及びマウスを含む入力デバイス１１０及び１１５を介して提供される。記憶デバイス１５５は、ディスク・ドライブ又は他のいずれかの適切な不揮発性記憶媒体を含むものとすることができる。
【００５３】
コンピュータ１２０のコンポーネントの各々は、データ・バス、アドレス・バス及びコントロール・バスを含むバス１３０に接続され、コンポーネントは、バス１３０を介して互いに通信できるようになる。コンピュータ・システム１００は、インターネットとして表されるネットワーク１８０への通信チャネル１８５を用いて、通信インターフェース１６５を介して、１つ又は複数の他の同様のコンピュータに接続することができる。
【００５４】
コンピュータ・ソフトウェア・プログラムは、コンピュータ・プログラム製品として提供し、携帯記憶媒体上に記憶することができる。この場合には、コンピュータ・ソフトウェア・プログラムは、記憶デバイス１５５からコンピュータ・システム１００によってアクセスすることができる。あるいは、コンピュータ・ソフトウェア・プログラムは、コンピュータ１２０によってネットワーク１８０から直接アクセスするようにしてもよい。いずれの場合にも、ユーザは、キーボード１１０及びマウス１１５を用いてコンピュータ・システム１００と対話し、コンピュータ１２０上で実行されるプログラムされたコンピュータ・ソフトウェアを操作することができる。
【００５５】
コンピュータ・システム１００は、例示を目的として説明された。従って、前述の説明は、本明細書に説明された方法及びコンピュータ・プログラム製品を実現するのに適した、パーソナル・コンピュータ（ＰＣ）などの特定のタイプのコンピュータ・システムの例に関するものである。コンピュータ・プログラミング技術分野の当業者であれば、代替的な構成又は別のタイプのコンピュータ・システムを用いて、本明細書で説明された方法及びコンピュータ・プログラム製品を実現できることが容易に理解できるだろう。
【００５６】
方法、システム及びコンピュータ・プログラム製品の実施形態は、本明細書において、コード変更記述を生成するための標準的なプログラム・コードと配置されたプログラム・コードとの比較に関連して説明された。前述の詳細な説明は、例示的な実施形態のみを提示しており、本発明の範囲、適用性又は構成を限定することを意図するものではない。むしろ、例示的な実施形態の説明は、本発明の実施形態を実施するための実施可能要件を当業者に提供するものである。特許請求の範囲に記載される本発明の趣旨及び範囲から逸脱することなく、要素の機能及び配置を様々に変更することができる。
【００５７】
本明細書で言及される特定の特徴、要素及びステップが、本発明が関連する技術分野において公知の均等物を有する場合には、こうした均等物は、個々に説明された場合でも本明細書に組み込まれるものと見なされる。さらに、特定の実施形態に関して言及された特徴、要素及びステップは、特に記載のない限り必要に応じて他の実施形態のいずれかの一部を形成することができる。
【図１】
2010511948.tif 000007
【図２】
2010511948.tif 000008
【図３】
2010511948.tif 000009
【図４】
2010511948.tif 000010
【図５】
2010511948.tif 000011
【国際調査報告】
2010511948.tif 000012
2010511948.tif 000013
2010511948.tif 000014