トップ :: G 物理学 :: G06 計算;計数




【発明の名称】 ディレクトリアシスタンスシステムに対するライトウエイトディレクトリアクセスプロトコルインターフェース
【発明者】 【氏名】マーティン・エイ・アムブロシニ

【氏名】エドワード・イー・ヒュース

【氏名】ビクター・エス・ムーア

【氏名】ウェンディ・エル・ナスビッケル

【氏名】ブライアン・イー・ヨーダー
【要約】 【課題】現存するディレクトリアシスタンス（ＤＡ）システムの上にＬＤＡＰプロトコルを付け加えるための方法及びシステムを提供すること。

【解決手段】ライトウエイトディレクトリアクセスプロトコル（ＬＤＡＰ）インターフェースをディレクトリアシスタンス（ＤＡ）システムにマッピングするための方法であって、以下のステップを含む。第１に、ＬＤＡＰデータベースを検索するためのＬＤＡＰコンパチブルな検索引き数がＬＤＡＰリクエストから抽出される。次に、このＬＤＡＰコンパチブルな検索引き数はＤＡシステムデータベースとコンパチブルな検索引き数に変換される。第三に、そのＤＡシステムデータベースは、上記変換された検索引き数を用いて照会される。第４に、ＤＡシステムデータベースからのリストの結果セットが、上記照会に応答して受信される。そして、その結果セットはＬＤＡＰコンパチブルな結果セットに変換される。
【特許請求の範囲】
【請求項１】 ライトウエイトディレクトリアクセスプロトコル（ＬＤＡＰ）インターフェースを、ディレクトリアシスタンス（ＤＡ）システムにマッピングする方法であって、（ａ）ＬＤＡＰデータベースを検索するために、ＬＤＡＰリクエストからＬＤＡＰコンパチブルな引数を抽出するステップと、（ｂ）当該ＬＤＡＰコンパチブルな引数を、ＤＡシステムデータベースコンパチブルな検索引き数に変換するステップと、（ｃ）変換された検索引数を用いて前記ＤＡシステムを検索するステップと、（ｄ）前記検索に応答して、前記ＤＡシステムデータベースからリストの結果セットを受信するステップと、（ｅ）前記リストの結果セットをＬＤＡＰコンパチブルな結果セットに変換するステップと、を含む方法。
【請求項２】 前記ＬＤＡＰリクエストをＬＤＡＰクライアントから受信するステップを更に有する、請求項１に記載の方法。
【請求項３】 前記ＬＤＡＰリクエストを、ＬＤＡＰサーバー内で受信するステップを更に有する、請求項１に記載の方法。
【請求項４】 前記ＬＤＡＰリクエストはＬＤＡＰフィルター属性を含む、請求項１に記載の方法。
【請求項５】 前記変換するステップ（ｂ）は、前記フィルター属性内の検索引数を、前記ＤＡシステムデータベースとコンパチブルな検索引数にマッピングするステップを含む、請求項４に記載の方法。
【請求項６】 前記マッピングするステップは、各レコードがローカリティをローカリティＩＤセットにマッピングしているローカリティ解決データベースに照会し、前記ローカリティ解決データベース内で、前記検索引数に対応するレコードを特定し、特定されたレコード内のローカリティＩＤセットを用いてＤＡシステムデータベース検索ステートメントを構成する、請求項５に記載の方法。
【請求項７】 前記ローカリティＩＤセットは、エリアコード、ブック及びロケーションのうち少なくとも１を含む、請求項６に記載の方法。
【請求項８】 ステップ（ａ）乃至（ｅ）は前記ＬＤＡＰサーバーへのプラグイン内で行われる、請求項３に記載の方法。
【請求項９】 ライトウエイトディレクトリアクセスプロトコル（ＬＤＡＰ）インターフェースをディレクトリアシスタンス（ＤＡ）システムにマッピングするためのシステムにおいて、ディレクトリ情報に対するＬＤＡＰリクエストを転送するためのＬＤＡＰクライアントと、前記ＬＤＡＰリクエストを受信し、処理するためのＬＤＡＰサーバーと、ＤＡシステムデータベース内に記憶されているＤＡシステムディレクトリ情報に対するＤＡシステムコンパチブルなリクエストに応答して、ディレクトリ情報を提供するためのＤＡシステムと、前記ＬＤＡＰサーバーに結合するプラグインであって、前記プラグインは、前記ＬＤＡＰリクエストをインターセプトし、前記ＬＤＡＰリクエストの中からＬＤＡＰデータベースを検索するためのＬＤＡＰコンパチブルな検索引数を抽出し、前記ＬＤＡＰコンパチブルな検索引数をＤＡシステムデータベースとコンパチブルな検索引き数に変換し、変換された検索引き数を用いて前記ＤＡシステムを照会し、前記照会に応答して前記ＤＡシステムからリストの結果セットを受信し、前記結果セットをＬＤＡＰとコンパチブルな結果セットに変換し、前記ＬＤＡＰコンパチブルな結果セットを前記ＬＤＡＰサーバーに渡し、前記ＬＤＡＰサーバーは前記ＬＤＡＰコンパチブルな結果セットを前記ＬＤＡＰクライアントに提供する、システム。
【請求項１０】 前記ＬＤＡＰリクエストは識別名である、請求項９に記載のシステム。
【請求項１１】 前記プラグインは、前記識別名中の検索引き数を前記ＤＡシステムデータベースとコンパチブルな検索引き数にマッピングすることにより、前記ＬＤＡＰコンパチブルな検索引き数を前記ＤＡシステムとコンパチブルな検索引き数に変換する、請求項１０に記載のシステム。
【請求項１２】 ローカリティ解決データベースを更に有し、前記マッピングが前記ローカリティ解決データベースにより決定され、前記ローカリティ解決データベース内の各々のレコードはローカリティをローカリティＩＤセットにマッピングしている、請求項１１に記載のシステム。
【請求項１３】 前記ローカリティＩＤセットは、エリアコード、ブック及びロケーションのうち少なくとも１つを含む、請求項１２に記載のシステム。
【請求項１４】 前記ＤＡシステムデータベース内のローカリティ及びディレクトリ情報をロードするための、ファイル更新プログラムと、前記ローカリティ情報に基づいて、前記ローカリティ解決データベースを前記プラグインとインターフェースするロードファイルを生成するための、ローカリティプロセッサーを更に有する、請求項１２に記載のシステム。
【請求項１５】 前記ロードファイルは更にＬＤＡＰデータベースを前記プラグインにインターフェースする、請求項１４に記載のシステム。
【請求項１６】 ライトウエイトディレクトリアクセスプロトコル（ＬＤＡＰ）インターフェースをディレクトリアシスタンス（ＤＡ）システムにマッピングするための複数のコードセクションを有するコンピュータプログラムが記憶されているマシン可読記憶装置であって、前記コードセクションはマシンにより実行可能であり、（ａ）ＬＤＡＰデータベースを検索するための、ＬＤＡＰコンパチブルな検索引き数をＬＤＡＰリクエストの中から抽出するステップと、（ｂ）前記ＬＤＡＰコンパチブルな検索引き数をＤＡシステムデータベースとコンパチブルな検索引き数に変換するステップと、（ｃ）変換された引き数を用いて前記ＤＡシステムデータベースを照会するステップと、（ｄ）前記照会に応答して前記ＤＡシステムデータベースからリストの結果セットを受信するステップと、（ｅ）前記結果セットをＬＤＡＰとコンパチブルな結果セットに変換するステップとをマシンに実行させる、記憶装置。
【請求項１７】 ＬＤＡＰクライアントから前記ＬＤＡＰリクエストを受信するためのステップをマシンに実行させる、請求項１６に記載の記憶装置。
【請求項１８】 ＬＤＡＰサーバー内に前記ＬＤＡＰリクエストを受信するステップをマシンに実行させる、請求項１６に記載の記憶装置。
【請求項１９】 前記ＬＤＡＰリクエストがＬＤＡＰ識別名である、請求項１６に記載の記憶装置。
【請求項２０】 前記変換するステップ（ｂ）が、前記識別名中の検索引き数を、前記ＤＡシステムデータベースとコンパチブルな検索引き数にマッピングするためのステップを含む、請求項１９に記載の記憶装置。
【請求項２１】 前記マッピングするためのステップが、各レコードが、ローカリティをローカリティＩＤセットにマッピングしているローカリティ解決データベースに問い合わせるステップと、前記検索引き数に対応するローカリティ解決データベースレコードを特定するステップと、特定されたレコード中のローカリティＩＤセットを用いてＤＡシステムデータベース照会ステートメントを形成するステップとを更に有する、請求項２０に記載の記憶装置。
【請求項２２】 前記ローカリティＩＤセットが、エリアコード、ブック及びロケーションのうちの少なくとも１つを含む請求項２１に記載の記憶媒体。
【発明の詳細な説明】【０００１】
【発明の属する技術分野】本発明は、ネットワークディレクトリサービスの分野に関連し、特に詳細にはディレクトリアシスタンスシステムと、ツリーベースのライトウエイトディレクトリアクセスプロトコル（ＬＤＡＰ）インターフェースとをインターフェースするためのシステム及び方法に関する。
【０００２】
【従来の技術】ディレクトリは、クライアントがエントリーやそのエントリーについての属性を検索するために使うしくみである。クライアントは多くの場合人間であり、たとえば、誰かがディレクトリを調べたりするが、クライアントがプログラムであっても良い。例えば、あるアプリケーションがあるユーザーの属性を調べたりする。エントリーとは、プリンター、ウエッブページ若しくは人間（ホワイト・ページディレクトリという）等のネットワーク資源を含む。クライアント及びエントリーに加え、情報にアクセスするのに使われるクエリーのタイプも重要である。クエリーの構造は、ディレクトリからの情報検索の意味を定義する。ディレクトリタイプ、エントリータイプ、クエリータイプの様々な組み合わせにより、様々なディレクトリアプリケーションが生まれる。要するに、ディレクトリは次のような重要な特徴を有するデータベースであると考えられる。すなわち、一般には、データベース読み出し操作の回数が書き込み操作の回数よりも一桁以上多い。更に、ディレクトリサーバーは、クライアントがエントリーと属性を、構造化クエリを用いて検索するのに用いることのできる、属性/値の組のリポジトリーと定義することができる。
【０００３】ディレクトリアシスタンス（ＤＡ）解決は、ディレクトリとディレクトリサーバーを具体化したものであり、それにより、ディレクトリ内に格納されている電話番号をサービスセンターのオペレーターを介して、電話をかけてきた者に提供することが可能になる。典型的な例を挙げると、ある者が”インフォメーション”（例えば番号４１１）に電話をして、ある人若しくは企業の電話番号を得ようとする。次に、ＤＡシステムは、要求された情報を得るために、索引参照メカニズムを使う。現存する数々のＤＡシステムは、その中に含まれる情報にアクセスするための専用インターフェースを有する。個々のＤＡシステムは普通、他のＤＡシステム内に格納されたデータとは異なった様式で、システム内のデータを組織化している。現在に至っても、例えば通信会社のような、ＤＡシステムの顧客向けに、個々のＤＡシステム内に別々の様式で組織化されて記憶されている情報を共有させたり、或いはそれら情報に対するアクセス権を販売することに対するニーズがある。
【０００４】にもかかわらず、これまでに、標準化、或いはオープンシステム環境のいずれの方法でも、顧客のＤＡシステムのデータの共有やそのシステムへのアクセス権の販売についての問題は解決されていない。現在のところ、異種ＤＡシステム、及び異なる態様でインストールされた同じＤＡシステム間の通信は、閉鎖的で、管理された環境で行われてきた。例えば、ユーザーにはハイパーテキストマークアップ言語（ＨＴＭＬ）ページと組合されたカスタマイズ済みのインターネットプログラムが与えられて、ファイアウォールの向こう側に置かれた専用ＤＡシステムへのイントラネットアクセスが許されてきた。しかしながらこれまでのところ、特別のアプリケーションプログラムやプログラマーのサポートを必要としない、異種ＤＡシステム間のデータ交換を容易にするためのオープンスタンダードは考え出されていない。更に、現行のＤＡシステムは、直接外部アプリケーションに開放するのが容易ではない専用インターフェースを使用している。特に、ＤＡシステムへの外部からのアクセスを提供しようとすれば、ＤＡシステム自体のインターフェースについてのトレーニングの問題とともに、機密保持上の問題を招来する。たとえば、ＤＡシステムの専用インターフェースを外部に公開すると、ＤＡシステムに対するアクセスを制御するためのセキュリティ機構を作ること要求されるかもしれない。更に、ＤＡシステムの専用インターフェースを外部に公開すれば、そのシステムを使う上でユーザーをトレーニングする必要もあろう。とりわけ、トレーニングを行えば、文書やサポートチームの編成が必要にもなろう。ＤＡシステムへの専用インターフェースが常に直感的なわけではないので、トレーニングは必要であろう。その結果、ＤＡシステムのユーザーはＤＡシステム内に記憶されている基礎的な情報の専用性を理解していなければならない。また更に、ＤＡシステムへの外部からのアクセスを行うと、専用ＤＡシステムからマイグレートするユーザーに対しマイグレーション問題を引き起こし得る。特に、ＤＡシステムに対する専用インターフェースとやりとりするように設計されたアプリケーションは、別のＤＡシステムに移るかそのＤＡシステムに対する別のインターフェースに移るかする場合に、うまくゆかないかもしれない。
【０００５】現行のＤＡシステムのプロプリエタリーなインターフェースと異なり、ライトウエイトディレクトリアクセスプロトコル（ＬＤＡＰ）は、産業界のオープンなディレクトリサービスプロトコルであって、データアクセスに対し一貫した、かつ管理されたシステムを提供する。ＬＤＡＰはパワフルではあるがシンプルなディレクトリサービスの役割を果たす。そのディレクトリサービスによれば、パワフルなディレクトリサービスクエリを実行できるし、クライアントは、ディレクトリサービスエントリーを付加し、削除し、若しくは変更するコマンドを発行することが可能となる。ＬＤＡＰサーバー間で、情報の基礎的なストレージは異なるかもしれないが、ＬＤＡＰプロトコルは、ＬＤＡＰインターフェースのユーザーに対しこの相違を露にしない。ＬＤＡＰでは、情報の基本単位はエントリから成る。個々のエントリは個々のディレクトリ内に記憶される。ディレクトリエントリは階層的ツリー様構造に配列されており、例えばロケーション若しくは組織のような、実社会における領域（バウンダリ）を反映させることができる。このような階層的ツリー様構造によって、ディレクトリサービスのユーザーが、良く知られた方法でそこに蓄積されている情報の中をナビゲートできるようになる。更に、標準化されたインターフェースを通して、ＬＤＡＰディレクトリ内の属性のスキーマ（schema）若しくは編成を取得することができる。その結果、例えば、ＬＤＡＰが使用可能なＮｅｔｓｃａｐｅ ＣｏｍｍｕｎｉｃａｔｏｒやＭｉｃｒｏｓｏｆｔ Ｉｎｔｅｒｎｅｔ ＥｘｐｌｏｒｅｒのようなＬＤＡＰアプリケーションは、ユーザーに特別のトレーニングや、基礎をなす情報システムに関する知識を要求することなく、ＬＤＡＰディレクトリインターフェースを使用することができる。
【０００６】Ｘ.５００ディレクトリアクセスプロトコル（ＤＡＰ）を簡略化したものであるＬＤＡＰは、ＲＦＣ（Ｒｅｑｕｅｓｔ ｆｏｒ ｃｏｍｍｅｎｔ）―１７７７、"ライトウエイトディレクトリアクセスプロトコル”の中で定義されており、次のＵＲＬフルアドレスを持つＩｎｔｅｒｎｉｃ ＨＴＴＰサーバー上で利用することができる。
ｄｓ．ｉｎｔｅｒｎｉｃ．ｎｅｔ／ｒｆｃ／ｒｆｃ１７７７．ｔｘｔ特にＬＤＡＰは、インターネットのクライアントに対し、ポート３８９を用いたＴＣＰ／ＩＰ接続を通して、階層的な属性／値のペアの任意のデータベースを検索したり管理したりするのに合理的で簡潔な機構を定義している。ＬＤＡＰディレクトリサービスモデルはエントリに依拠している。エントリはフィルタ属性の集合であり、識別名（ＤＮ）と呼ばれる、名前を有する。ＤＮは、そのエントリを間違いなく参照するために用いることができる。個々のエントリの属性は、型（type）及び１若しくはそれ以上の値を保有することが可能である。典型的な型として、ニーモニック文字列があり、例えば、コモンネームに対し”ｃｎ”若しくは電子メールアドレスに対し”ｍａｉｌ”等である。値は、対応する属性に依存する。例えば、メール属性が、値”ｊｈｏｎｄ＠ｘｙｚ．ｃｏｍ"を含むなどのようにである。同様に、ｊｐｅｇ写真属性が、バイナリのＪＰＥＧフォーマットの写真を含んでいても良い。エントリのＤＮは、エントリ自身の名前を取って構成されても良く、相対識別名（ＲＤＮ）と呼ばれる。また、エントリのＤＮは、ＲＤＮの親エントリの名前を連結することによって構成されても良い。例えば、Ｊｏｈｎ Ｄｏｅ用のエントリは、ＲＤＮが”ｃｎ＝ＪｈｏｎＤｏｅ”及びＤＮが”ｃｎ＝Ｊｈｏｎ Ｄｏｅ，ｏ＝ｘｙｚ， ｃ＝ＵＳ”を持つようにすることができる。
【０００７】ＬＤＡＰにおいて、ディレクトリエントリは、政治的、地理的、及び／若しくは組織的境界を反映する、階層的なツリー状構造に配置される。国々を表現するエントリはツリーのトップに存在する。国エントリの下は、州や国家の組織を表すエントリである。州や国家の組織を表すエントリの下には、人々、組織単位、プリンタ、文書若しくはその他の分類分けされたサブユニットが存在し得る。特に留意したいのは、ＬＤＡＰ内の階層はデータベース内のエントリの階層であって、サーバー接続若しくは他のネットワーク構成情報の階層ではないという点である。一般的にＬＤＡＰエントリは、オブジェクトクラス属性により分類される。例えば、ディレクトリの検索対象を、アクセスコントロールリストを専ら含むエントリに限定するために、サーチフレーズを、”ｏｂｊｅｃｔｃｌａｓｓ＝ａｃｌ”と定義し、アクセスコントロールリストであるとされるエントリのみ検索されるようにすることができる。ＬＤＡＰによればユーザーは、特定のオブジェクトクラスに対して、どの属性が要求され、また許可されるのかをコントロールすることが可能になる。つまり、エントリーが従うべきスキーマルールを定めることが可能になる。属性の名前やＬＤＡＰの階層構造の選択はＬＤＡＰのＸ.５００ルートから導出されるが、ここで、ＬＤＡＰはＸ.５００ディレクトリではないことに留意しておくことは重要である。より正確に言うと、ＬＤＡＰは、あらゆる階層的、属性ベースの、ディレクトリに関連するビジネス処理を行っているパーティー間のプロトコルである。ごく簡単な場合には、階層は１階層であり得、属性はその場合任意の専有情報であろう。
【０００８】ＬＤＡＰは、ディレクトリに質問をしたり、更新するためのオペレーションを定義する。更に、ＬＤＡＰは、ディレクトリのエントリを追加、削除したり、現存するエントリを変更したり、エントリの名前を変更するためのオペレーションを提供する。それでも、ＬＤＡＰの基本的なオペレーションは、ディレクトリ内に蓄積された情報を検索することである。従って、ＬＤＡＰ検索オペレーションによって、ディレクトリのある部分は、検索フィルタにより特定されたある基準と合致するエントリについてサーチされるようになる。クライアントは、当該基準に合致する個々のエントリからの情報をリクエストすることが可能である。例えば、ユーザーは、会社ＸＹＺの下の全てのディレクトリをサーチしてＪｈｏｎＤｏｅという名前の人を捜し、見つかった個々のエントリについて電子メールアドレスを取り出すことができる。また一方で、ＬＤＡＰによれば、ユーザーは、アメリカ合衆国（ｃ＝ＵＳ）用のエントリの下のエントリを直接検索して、組織名が”Ａｃｍｅ”の文字列を含んで、更にその組織がファックス番号を保有する組織を検索することが可能である。
【０００９】ＲＦＣ−１５５８、”ＬＤＡＰサーチフィルタの文字列表現”は、下記フルＵＲＬアドレスのＩｎｔｅｒｎｉｃ ＨＴＴＰサーバー上で利用できる。
ｄｓ．ｉｎｔｅｎｉｃ．ｎｅｔ／ｒｆｃ／ｒｆｃ１５５８．ｔｘｔＲＦＣ−１５５８は、検索を定義することのできるフィルタ用の文法を規定している。この検索のしくみを用いて、クライアント開発者は容易にパワフルなサーチ機能を提供できる。ディレクトリ照会を実行する場合、ＬＤＡＰクライアントは、ディレクトリツリー内の例えば検索ロケーションなどのフィルタ属性を選択し、その場所からの検索をフィルタすることができる。サンプル”ｂａｓｅ”値は、”ｓｔ＝ＦＬ．．．ｃ＝ｕｓ”でも”Ｉ＝Ｂｏｃａ Ｒａｔｏｎ, Ｉ＝Ｈｉｇｈｌａｎｄ Ｂｅａｃｈ Ｄｉｒｅｃｔｏｒｙ, ｓｔ＝ＦＬ，．．．，ｃ＝ｕｓ”でも良い。その上、ＬＤＡＰ検索は、ＬＤＡＰディレクトリツリーの殆どどのようなノードからも開始することができる。この場合、ＬＤＡＰクライアントは、ツリーの中のをサーチ開始点決定するためにサーチベースを設定できるのみである。
【００１０】ＬＤＡＰサーチの有利な点は、ＬＤＡＰディレクトリツリーの中で一致したエントリ位置の各々について結果セットを返すことである。結果セットは、ＬＤＡＰ識別名（ＤＮ）を用いて、ＬＤＡＰクライアントに知らせることが可能である。ＤＮは、ＬＤＡＰクライアントに、ＬＤＡＰディレクトリエントリへのパスを示し、例えば、”ｄｎ：ｃｎ＝Ｊｈｏｎ Ｄｏｅ,Ｉ＝Ｂｏｃａ Ｒａｔｏｎ,Ｉ＝Ｈｉｇｈｌａｎｄ Ｂｅａｃｈ Ｄｉｒｅｃｔｏｒｙ， ｓｔ＝ＦＬ，．．．，ｃ＝ｕｓ”となる。この例では、”Ｊｈｏｎ Ｄｏｅ”は、”Ｂｏｃａ Ｒａｔｏｎ”市内に位置し、”Ｈｉｇｈｌａｎｄ Ｂｅａｃｈ”ディレクトリ内にあり、更に”ＦＬ”州内、そして”ＵＳ”国内にある。ＬＤＡＰディレクトリサービスは、クライアントサーバーモデルに準拠している。詳細には、１つ若しくはそれ以上のＬＤＡＰサーバーが、ＬＤＡＰディレクトリツリーを含むデータを有する。ＬＤＡＰクライアントは、ＬＤＡＰサーバーに接続でき、データ要求を転送することができる。サーバーはこのデータを用いて応答することもできるし、或いはローカルではそのデータを利用できない場合には、別のサーバー、典型的にはその要求を満たすことの可能な別のサーバーに接続することが可能である。ＬＤＡＰはこのような参照能力によって、個々別々のＬＤＡＰサーバーの協働関係を実現し、あらゆるデータベースの更新が、特定のマスターＬＤＡＰサーバーにより参照されるようにする。特に、個々のＬＤＡＰサーバーが同じネーミングの規則を使っているとき、クライアントがどのＬＤＡＰサーバーに接続するかに関係なく、接続しているクライアントはディレクトリの同じビューを見ることになる。すなわち、１つのＬＤＡＰサーバーに与えられたある名前は、別のＬＤＡＰサーバーにあるかもしれない同じエントリを参照する。
【００１１】最下層レベルでは、ディレクトリ情報へのアクセスを要求するあらゆるクライアントはＬＤＡＰサーバーに、ＴＣＰ／ＩＰによって接続する。そして、クライアントはＬＤＡＰコマンドをＬＤＡＰサーバーにＴＣＰ／ＩＰ接続により転送する。特に、ＬＤＡＰコマンドを転送するためには、ドメインネームシステム（ＤＮＳ）ネーム若しくはＬＤＡＰサーバーに対する明示的なインターネットプロトコルアドレス及び、例えばポート３８９のようなポート番号のみが要求される。ＬＤＡＰサーバーは、ＬＤＡＰコマンドを受取次第、ＬＤＡＰコマンドを処理でき、必要ならば、ディレクトリ情報にて応答する。ゆえに、ＵＲＬ ｄｉｒｅｃｔｏｒｙ.ｘｙｚ.ｃｏｍを持つＬＤＡＰサーバーにコマンドを出すには、クライアントは、ＬＤＡＰクライアントの中で次の指定を行うことができる。
”ｌｄａｐ：／／ｄｉｒｅｃｔｏｒｙ．ｘｙｚ．ｃｏｍ／＜ＬＤＡＰ コマンド＞ここで、ｌｄａｐ：は、ポート３８９を呼出し、ｄｉｒｅｃｔｏｒｙ．ｘｙｚ．ｃｏｍは有効なＤＮＳネームであり、＜ＬＤＡＰコマンド＞は、ＬＤＡＰクライアントによってＬＤＡＰサーバーに対して発行されるＬＤＡＰプロトコルコマンドである。下記Ｃプログラミング言語で記述されたソースコードは、クライアントからＬＤＡＰサーバーに対してＬＤＡＰコマンドを発行し、ＬＤＡＰサーバーからディレクトリ情報の応答を受け取る方法の例である。
【００１２】
ｍａｉｎ（）
｛ ＬＤＡＰ ＊ｌｄ；
ＬＤＡＰＭａｓｓａｇｅ ＊ｒｅｓ， ＊ｅ；
ｉｎｔ ｉ；
ｃｈａｒ ＊ａ， ＊ｄｎ；
ｖｏｉｄ ＊ｐｔｒ；
ｃｈａｒ ＊＊ｖａｌｓ；
／＊コネクションオープン＊／ ｉｆ（（ｉｄ＝ｌｄａｐ＿ｏｐｅｎ（”ｄｏｔｔｅｄ．ｈｏｓｔ．ｎａｍｅ”， ＬＤＡＰ＿ＰＯＲＴ））＝＝ＮＵＬＬ）ｅｘｉｔ（１）；
／＊だれも居ないことを確認＊／ ｉｆ（ｌｄａｐ＿ｓｉｍｐｌｅ＿ｂｉｎｄ＿ｓ（ｌｄ， ＮＵＬＬ, ＮＵＬＬ）！＝ＬＤＡＰ＿ＳＵＣＣＥＳＳ）
｛ ｌｄａｐ＿ｐｅｒｒｏｒ（ｌｄ，”ｌｄａｐ＿ｓｉｍｐｌｅ＿ｂｉｎｄ＿ｓ”）；
ｅｘｉｔ（１）；
｝
／＊ｃｎ ”Ｊｈｏｎ Ｄｏｅ”を持つエントリーを検索し、すべての属性を返す＊／ ｉｆ（ｌｄａｐ＿ｓｅａｒｃｈ＿ｓ（ｌｄ， ”ｏ＿ｍｙｏｒｇａｎｉｚａｔｉｏｎ， ｃ＝ＵＳ”， ＬＤＡＰ＿ＳＣＯＰＥ＿ＳＵＢＴＲＥＥ，”（ｃｎ＝Ｊｈｏｎ Ｄｏｅ）”, ＮＵＬＬ，０，＆ｒｅｓ）！＝ＬＤＡＰ＿ＳＵＣＣＥＳＳ）
｛ ｌｄａｐ＿ｐｅｒｒｏｒ（ｌｄ， ”ｌｄａｐ＿ｓｅａｒｃｈ＿ｓ”）；
ｅｘｉｔ（１）；
｝
／＊返された各々のエントリーの処理＊／ ｆｏｒ（ｅ＝ｌｄａｐ＿ｆｉｒｓｔ＿ｅｎｔｒｙ（ｌｄ，ｒｅｓ）；ｅ！＝ＮＵＬＬ； ｅ＝ｌｄａｐ＿ｎｅｘｔ＿ｅｎｔｒｙ（ｌｄ， ｅ））
｛ ／＊ネームの表示＊／ ｄｎ＝ｌｄａｐ＿ｇｅｔ＿ｄｎ（ｌｄ， ｅ）；
ｐｒｉｎｔｆ（”ｄｎ：％ｓ０，ｄｎ）；
ｆｒｅｅ（ｄｎ）
／＊各々の属性を表示＊／ ｆｏｒ（ａ＝ｌｄａｐ＿ｆｉｒｓｔ＿ａｔｔｒｉｂｕｔｅ（ｌｄ， ｅ， ＆ｐｔｒ）；ａ！＝ＮＵＬＬ；
ａ＝ｌｄａｐ＿ｎｅｘｔ＿ａｔｔｒｉｂｕｔｅ（ｌｄ， ｅ， ｐｔｒ））
｛ ｐｒｉｎｔｆ（”ａｔｔｒｉｂｕｔｅ： ％ｓ０，ａ）；
／＊各々の値を表示＊／ ｖａｌｓ ＝ ｌｄａｐ＿ｇｅｔ＿ｖａｌｕｅｓ（ｌｄ， ｅ， ａ）；
ｆｏｒ（ｉ＝０； ｖａｌｓ［ｉ］！＝ＮＵＬＬ；ｉ＋＋）
｛ ｐｒｉｎｔｆ（”ｖａｌｕｅ：％ｓ０，ｖａｌｓ［ｉ］）；
｝
ｌｄａｐ＿ｖａｌｕｅ＿ｆｒｅｅ（ｖａｌｓ）；
｝
／＊検索結果を開放＊／ ｌａｄｐ＿ｍｓｇｆｒｅｅ（ｒｅｓ）；
／＊コネクション資源を閉じ、解放＊／ ｌａｄｐ＿ｕｎｂｉｎｄ（ｌｄ）；
【００１３】ＬＤＡＰｖ３．１はプラグインアーキテクチュアを提供し、これによりサードパーティプロバイダーは、種々のサービスをＬＤＡＰサーバーに統合することができ、かつその結果、ホストＬＤＡＰサーバーのユーザーがＬＤＡＰツリー中のプラグインのノードを指定した場合に、プロセスの制御を取得することができる。ＬＤＡＰサーバープラグインは、共有されるオブジェクト若しくはライブラリであり、ＬＤＡＰサーバーに供給されるファンクション群に対する外部ファンクション群を含む。プラグインファンクションは、以下のタスクを実行するために記載される。すなわち、サーバーがあるデータについてのＬＤＡＰオペレーションを実行する前に、そのデータを確認し、サーバーがＬＤＡＰオペレーションを完了した後にいくつかのユーザー定義アクションを実行し、そして拡張オペレーションを実行し、ある属性値を比較する場合に代替（alternate）マッチングルールを供給する。本発明においては、ＬＤＡＰプラグインは、現存するバックエンドのデータベースを、専用ＤＡシステムのデータベースに置き換える。ＬＤＡＰサーバープラグインを使用する場合、スタートアップに際しＬＤＡＰサーバーは特定の共有オブジェクト若しくはライブラリをロード可能であり、様々なＬＤＡＰリクエストを処理する過程においてＬＤＡＰサーバー内に記憶されたプラグインファンクションを呼び出すことが可能である。特に、ＬＤＡＰサーバーはＬＤＡＰリクエストにサービスする過程において、幾つかのポイントでプラグインファンクションを呼び出すことが可能である。例えば、ＬＤＡＰサーバーはＬＤＡＰオペレーションを実行する前に、或いはＬＤＡＰサーバーがデータベース内のエントリーを加え、変更し、削除し又は検索する場合に、或いは、データベースにエントリーを書きこむ場合、或いは、データベースからエントリーを読み出した後、或いはＬＤＡＰオペレーションを実行した後、或いはＬＤＡＰオペレーションが拡張オペレーションを含む場合、或いはＬＤＡＰサーバーが属性にインデックスを付ける場合、或いはある属性に基づいたサーチ結果の候補をＬＤＡＰサーバーがフィルターする場合に、ＬＤＡＰサーバープラグインファンクションを呼び出すことが可能である。
【００１４】多くの場合、ＬＤＡＰサーバーがＬＤＡＰサーバープラグインファンクションを呼び出す場合、ＬＤＡＰサーバーはプラグインファンクションにパラメーターブロックを渡す。パラメーターブロックは、プラグインファンクションによって実行されるオペレーションに関連するデータを含んでいる。例えば、ＬＤＡＰ追加オペレーションでは、パラメーターブロックはディレクトリに追加されるエントリー及びそのエントリーのＤＮを含んでいる。その結果、サーバープラグインファンクションは、パラメーターブロック内のデータにアクセスし、変更できる。更に、ＬＤＡＰサーバープラグインファンクションがＬＤＡＰオペレーションが実行される前に呼び出される場合には、プラグインファンクションはそのＬＤＡＰオペレーションが実行されないようにすることが可能である。例えば、プラグインファンクションは新しいエントリーがディレクトリに追加される前に、データを確認することができる。データが有効でない場合、プラグインファンクションはＬＤＡＰ追加オペレーションを中止し、ＬＤＡＰクライアントにエラーメッセージを返すことができる。
【００１５】
【発明が解決しようとする課題】未だ、ＬＤＡＰは現状のＤＡシステムと統合されていない。事実、ＬＤＡＰと現存するＤＡシステムとの統合には問題があることがわかるだろう。特に、ＤＡシステム内のデータが、伝統的なＬＤＡＰ準拠システムの階層的ツリー様の構造と互換性の無い方法で構造化されている場合には問題になる。したがって、現存するＤＡシステムの上にＬＤＡＰプロトコルを付け加えるための方法若しくはシステムに対するニーズのみならず、ＤＡシステム内のデータが、典型的なＬＤＡＰ階層的ツリー様構造中に構造的に組織化されていると見えるように、下層のＤＡシステムを抽象化する方法に関しニーズがある。大規模ディレクトリアシスタンス（ＤＡ）システムは、アクセスタイムと何百万ものディレクトリ素リストのすべてのスケーリングを効率化するために、専用アクセスを有する専用データベース構造を使用する。しかしながら、ライトウエイトディレクトリアクセスプロトコル（ＬＤＡＰ）に代表されるような、最近のオープンで、標準化されたディレクトリ情報へのアクセスによって、専用ＤＡシステムのオペレーターは、複数のシステムを並行して使用することを強いられ、これは、システムの導入にも維持にもコストが嵩む。
【００１６】
【課題を解決するための手段】本発明によるシステム及び方法によれば、専用ＤＡシステムのオペレーターは、本発明による、多様なアクセスの態様をサポートできる単一のＤＡシステムを導入し、維持することが可能になる。ライトウエイトディレクトリアクセスプロトコル（ＬＤＡＰ）インターフェースをディレクトリアシスタンス（ＤＡ）システムにマッピングする方法は、例えば以下のステップを含む。第一に、ＬＤＡＰデータベースを検索するためのＬＤＡＰコンパチブルな検索引き数がＬＤＡＰリクエストの中から抽出される。次に、そのＬＤＡＰコンパチブルな検索引き数は、ＤＡシステムデータベースとコンパチブルな検索引き数に変換される。そして第三に、ＤＡシステムデータベースが、変換された検索引き数を用いて検索される。第四にその検索に応答し、ＤＡシステムデータベースからのリストの結果セットが受信される。最後に、その結果セットは、ＬＤＡＰとコンパチブルな結果セットに変換される。好ましくは、これら五つのステップは、ＬＤＡＰサーバーへに対するプラグインの中で実行される。更に、上記方法は、ＬＤＡＰクライアントからのＬＤＡＰリクエストを受信するステップを含んでいても良い。また更には、上記方法は、ＬＤＡＰサーバー内でＬＤＡＰリクエストを受信するステップを含んでいても良い。
【００１７】発明の実施の形態では、ＬＤＡＰリクエストはＬＤＡＰフィルター属性としている。したがって、発明の実施の形態では、上記変換ステップは、フィルター属性中の検索引き数を、ＤＡシステムのデータベースとコンパチブルな引数にマッピングするステップを含んでいても良い。特に、マッピングするステップは、各レコードがローカリティを、ローカリティＩＤセットにマッピングしているローカリティ解決データベースに問い合わせ、そのローカリティ解決データベースの中で検索引き数に対応するデータベースレコードを特定し、そして、特定されたレコードに含まれるローカリティＩＤセットを用いてＤＡシステムデータベースのクエリステートメントを構成するステップを含んでいても良い。そして更に、このローカリティＩＤセットは、エリアコード、ブック、ロケーションのうちの少なくとも１つを含んでいても良い。ライトウエイトディレクトリアクセスプロトコル（ＬＤＡＰ）インターフェースをディレクトリアシスタンス（ＤＡ）システムにマッピングするシステムは、下記の構成要素を含んでいる。（１）ディレクトリ情報に対するＬＤＡＰリクエストを転送するためのＬＤＡＰクライアント、（２）そのＬＤＡＰリクエストを受信し、処理するためのＬＤＡＰサーバー、（３）ＤＡシステムディレクトリ情報に対するＤＡシステムコンパチブルなリクエストに応答して、ＤＡシステムデータベース内に記憶されているＤＡシステムディレクトリ情報を与えるためのＤＡシステム、及び（４）ＬＤＡＰサーバーと結合したプラグインである。特に、このプラグインは、ＬＤＡＰリクエストをインターセプトし、そこからＬＤＡＰデータベースを検索するためのＬＤＡＰコンパチブルな検索引き数を抽出し、そのＬＤＡＰコンパチブルな検索引き数を、ＤＡシステムデータベースとコンパチブルな検索引き数に変換することができる。更に、このプラグインは、変換された検索引き数を用いてＤＡシステムを検索し、その検索に応答したリストの結果セットを受取り、その結果セットをＬＤＡＰとコンパチブルな結果セットに変換し、そのＬＤＡＰコンパチブルな結果セットをＬＤＡＰサーバーに送るようにしても良い。更にまた、ＬＤＡＰサーバーがＬＤＡＰクライアントに対し、ＬＤＡＰコンパチブルな結果の組を与えるようにしても良い。
【００１８】発明の実施の形態においては、ＬＤＡＰリクエストは、ＬＤＡＰコンパチブルな検索である。プラグインは、フィルター属性の中の検索引き数を、ＤＡシステムデータベースとコンパチブルな検索引き数にマッピングすることによって、ＬＤＡＰコンパチブルな検索引き数を、ＤＡシステムデータベースとコンパチブルな検索引き数に変換可能であるならば好ましい。本発明によるこのようなシステムは、ローカリティ解決データベースを更に含んでも良く、マッピングは、ローカリティ解決データベースにより決定される。ローカリティ解決データベース内の各レコードは、ローカリティを、ローカリティＩＤセットにマッピングしている。さらに、ローカリティＩＤセットは、エリアコード、ブック及びローカリティのうちの少なくとも一つを含んでいる。本発明によるシステムは更に、ＤＡシステムデータベース内にあるローカリティ及びディレクトリ情報をロードするためのファイル更新プログラム及び、そのローカリティ情報に基づくロードファイルを生成するためのローカリティプロセッサーを含んでいても良い。特に、このロードファイルはローカリティ解決データベースとプラグインとのインターフェースを取ることが可能である。また更に、このロードファイルは、ＬＤＡＰデータベースをプラグインともインターフェースするようにしても良い。
【００１９】
【発明の実施の形態】以下、図面を参照しながら本発明の実施の形態を説明するが、これらの図面は現在最も好ましいと思われる実施の形態を図示したものであり、本発明は図示された通りの構成及び機器に限定されるわけではない。ディレクトリアシスタンス（ＤＡ）システムに対するライトウエイトディレクトリアクセスプロトコル（ＬＤＡＰ）インターフェースは、ＬＤＡＰスキーマと専用ＤＡシステム相互間をマップすることのできるＬＤＡＰサーバーに統合されるソフトウエアのレイヤーを提供することが可能である。特に、このＬＤＡＰインターフェースは、たとえＤＡシステムそれ自体がＬＤＡＰツリー様構造に組織化されておらずとも、ＤＡシステム内に含まれるデータをＬＤＡＰスキーマにマップすることができる。その結果、クライアントは、情報の専用性を意識せずに或いはＤＡデータの機密性について妥協をせずに、標準化されたＬＤＡＰインターフェースを用いてＤＡシステムにアクセスすることが可能である。
【００２０】
【実施例】図１は、ＤＡシステムに対するＬＤＡＰインターフェースが機能している典型的なネットワーク環境１を示す。このネットワーク環境１は、クライアントコンピュータ１２及びＬＤＡＰサーバー１６０及びディレクトリアシスタンス（ＤＡ）システム１８０を相互接続する、コンピュータ通信ネットワーク１０を含んでおり、これらのサーバーは、少なくとも１のＬＤＡＰサーバーアプリケーション１６及び少なくとも１のＤＡシステムアプリケーション１８を含む。ただし、簡単のため、図１には、単一のクライアント１２、単一のＬＤＡＰサーバー１６０及び単一のＤＡシステム１８０のみ示されている。しかしながら、典型的にはネットワーク環境１は、何百万ものクライアント１２及び数千のＬＤＡＰサーバー１６０とＤＡシステム１８０を含む可能性があろう。コンピュータ通信ネットワーク１０は，ＬＡＮ（ｌｏｃａｌ ａｒｅａ ｎｅｔｗｏｒｋ）若しくはＷＡＮ（ｗｉｄｅ ａｒｅａ ｎｅｔｗｏｒｋ）のような公衆にアクセス不可能なあらゆるタイプのネットワーク、或いは好ましくはインターネットのようなものであって良い。ＬＤＡＰサーバー１６０、ＤＡシステム１８０とクライアント１２間の相互接続は、特別の目的の通信のための、ＬＤＡＰサーバー１６０、ＤＡシステム１８０及びクライアント１２間に確立されたバーチャル・サーキットであると考えることができる。動作時において、クライアント１２は、ＤＡシステム１８０内に記憶されたデータに対するリクエストをコンピュータ通信ネットワーク１０を介して転送するために、ＬＤＡＰサーバー１６０とコネクションを確立することが可能である。典型的な例では、データとは、ディレクトリリストのような、通信関係のデータである。
【００２１】図１に示された通り、各サーバー１６０、１８０は好ましくは、中央演算処理ユニット（ＣＰＵ）２６、ランダムアクセスメモリー（ＲＡＭ）のような、内部メモリーデバイス２４、及びハードディスクドライブ（ＨＤＤ）のような固定記憶装置２２を内部に有するコンピュータを含んでいる。サーバー１６０及び１８０は、サーバーをコンピュータ通信ネットワーク１０に通信接続するための、ネットワークインターフェース回路（ＮＩＣ）２８をも含む。またサーバーは、キーボード（不図示）や、サーバーとやりとりするためにコンピュータに機能的に接続されたビデオディスプレイターミナル（ＶＤＴ）のような少なくとも１つのユーザーインターフェース表示ユニット（不図示）を含んでいても良いが、本発明はこれに限定されるものではなく、それどころか本発明による動作を行うのに、サーバーはキーボードもＶＤＴも必須とはしない。ＣＰＵ２６は、当業者には良く知られている通り、適切なあらゆるマイクロプロセッサー若しくは他の電子プロセッシングユニットを含んでいて良い。適当なＣＰＵの例として、Ｉｎｔｅｌ Ｐｅｎｔｉｕｍ（登録商標）クラスのプロセッサー、ＩＢＭ ＰｏｗｅｒＰＣ（登録商標）クラスのプロセッサー若しくはＡＭＤ Ａｔｈｌｏｎ（登録商標）クラスのプロセッサーが含まれる。固定記憶装置２２は、オペレーティングシステム、例えばＩＢＭ ＡＩＸ（登録商標、不図示）を記憶することが可能である。更に、サーバー１６０がＬＤＡＰサーバーアプリケーションをホストする場合、固定記憶装置２２中に、ディレクトリ情報に対するＬＤＡＰリクエストを処理することのできるＬＤＡＰサーバーアプリケーション１６を記憶することができる。これに対して、サーバー１８０がＤＡシステムをホストする場合、ＤＡシステムアプリケーション１８が同様に固定記憶２２内に記憶される。更に、ディレクトリ情報データベース３０が固定記憶２２内のデータベースに記憶されても良いが、本発明はこれには限定されず、その上、このデータベースとは、コンピュータ通信ネットワーク１０内のどこか他の固定記憶に記憶された分散データベースであっても良い。更に、本発明はＬＤＡＰサーバーアプリケーション１６をＤＡシステムアプリケーション１８から分離することに関し限定されるものではなく、両者は同じ固定記憶装置内に存在しても良い。
【００２２】ＬＤＡＰサーバー１６をホストするサーバーコンピュータ１６０において、固定記憶２６は、ＬＤＡＰサーバー１６に対するＬＤＡＰプラグイン２０を更に記憶していても良い。ＬＤＡＰプラグイン２０は、ＬＤＡＰインターフェースをＤＡシステムと通信的にリンクするための機能を含んでいる。好適な実施例において、通常の当業者のプログラマーであれば、プラグイン機能を、例えばＡＮＳＩＣのような第三世代言語テクノロジーを用いる、良く知られたＬＤＡＰプログラミング方法を援用し、実装することが可能である。これらの方法は、前述のオペレーティングシステム向けの商業的に利用可能な開発ツールを用いてプラグイン機能に実装され、具体化される。しかしながら、本発明は、プラグインを実装するために用いられるプログラミング言語テクノロジーによっては限定されない。次に図２を用いて説明する。サーバー１６０、１８０と同様に、クライアント１２もまた、上記したところとほとんど同様に、好ましくは、ＣＰＵ３２、内部メモリーデバイス３４、固定記憶３６及びネットワークインターフェース回路３８を有する。クライアント１２は、パーソナルコンピュータであれば良い。したがって、クライアント１２は、更にキーボード４０及び、クライアント１２とやりとりするためにクライアントに機能的に接続されたビデオディスプレイターミナル（ＶＤＴ）のような、少なくとも一つのユーザーインターフェースディスプレイユニット４２を含んでも良い。更に、クライアント１２は、ポインティングデバイス４４を含んでいても良い。サーバー１４の場合のように、ＣＰＵ３２は、当業者にはよく知られた通り、あらゆる適切なマイクロプロセッサー若しくは他の電子プロセッシングユニットを含んで良い。適切なＣＰＵとして、Ｉｎｔｅｌ Ｐｅｎｔｉｕｍ（登録商標）クラスのプロセッサー、ＩＢＭ ＰｏｗｅｒＰＣ（登録商標）クラスのプロセッサー若しくはＡＭＤ Ａｔｈｌｏｎ（登録商標）クラスのプロセッサーが含まれる。
【００２３】固定記憶３６はオペレーティングシステム４６、及び例えばウェッブページのようなハイパーメディア文書５０を表示するためのハイパーメディア文書ブラウザアプリケーション４８を各々含む。オペレーティングシステム４６とハイパーメディア文書ブラウザーアプリケーション４８は内部メモリーデバイス３４に初期化時にロードされるのが望ましい。このハイパーメディア文書ブラウザーアプリケーション４８により、クライアント１２が、コンピュータ通信ネットワーク１０に通信接続されたウエブサーバーへ／或いはから、ハイパーメディア文書５０に対するリクエストを送り／若しくは受信できれば好ましい。このハイパーメディア文書ブラウザーはＬＤＡＰクライアントとして、ＬＤＡＰプロトコルをサポート可能である。ハイパーメディア文書ブラウザー４８は、好ましくは、サーバー１４に対するディレクトリ情報のＬＤＡＰリクエストを、コンピュータ通信ネットワーク１０を経由して送信することが可能であれば更に好ましい。ハイパーメディア文書ブラウザーアプリケーション４８は、例えば、ＮｅｔｓｃａｐｅＣｏｍｍｕｎｉｃａｔｏｒ(登録商標)若しくはＭｉｃｒｏｓｏｆｔ Ｉｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒ（登録商標）のようなＬＤＡＰ利用可能なウエブブラウザーであることが好ましい。以上は、本発明をインターナショナルビジネスマシーンズコーポレーション製のＤＡシステムであって、”ＡＩＸ用リスト照会プログラム”（ＬＳＩＰ）と呼ばれる専用データベースを有するシステムに対する、本願発明の好ましい実装についての記載であるが、本発明は、ＩＢＭ ＤＡシステム若しくはＬＳＩＰ照会データベースには限定されない。ＩＢＭ ＤＡシステムは単に、本発明で使用される専用ＤＡシステムの例として示されるに過ぎない。
【００２４】ＩＢＭ ＤＡシステムにおいて、ＤＡシステムデータベース３０は、ＬＳＩＰ照会データベースであって、ＬＳＩＰローカリティＩＤセットを用いた、カスタマーのローカリティの階層的ビューを含んでいる。特に、このＬＳＩＰ照会データベースは、フラットデータベースである。フラットＬＳＩＰ照会データベースを用いる結果、ＬＤＡＰをＬＳＩＰコンパチブルなリクエストに変換する際に、ＬＤＡＰプラグイン２０は、他とは完全に異なるデータスキーマの抽象を生成する。より詳細には、本発明では、ローカリティベースのツリーを含むＬＤＡＰホワイトページスキーマが、専用フラットＬＳＩＰ照会データベースに対し、或いはから抽象化される。しかしながら、プラグイン２０アブストラクションレイヤーは、なおクエリ入力及び結果出力において、ＬＤＡＰサーバーに対して仮想的なＬＤＡＰツリー風の外観を提供することができる。このような抽象化を実行するために、プラグイン２０は、ＬＤＡＰリクエストに含まれるＬＤＡＰコンパチブルな検索引き数を、専用ＬＳＩＰフォーマットにマッピングすることが可能である。このＬＤＡＰコンパチブルな検索引き数は、例えば、ローカリティベースのＤＮであることが好ましい。比較により、ＬＳＩＰリクエストは、ＮＰＡ（エリアコード）、ブック（ハードコピーの電話帳を指す）及びＬｏｃ ＩＤ（そのＬＳＩＰサーチに対する特定のローカリティ）を結合する。したがって、例えば、入力されたサーチベースが”Ｉ＝Ｂｏｃａ Ｒａｔｏｎ，Ｉ＝ＨＩｇｈｌａｎｄ Ｂｅａｃｈ Ｄｉｒｅｃｔｏｒｙ，ｓｔ＝ＦＬ，．．．ｃ＝ｕｓ”の場合、プラグイン２０は、リスティングサーチを行うために、このローカリティベースのＤＮを、ＮＰＡ、ブック及びＬｏｃ ＩＤに基づくＬＳＩＰリクエストに変換することができる。ＬＳＩＰローカリティ解決データベースは、”キャプション設定レベル”フィールド、”サーチ／表示ネーム”フィールド、”代替検索名”フィールド及び”ローカリティＩＤ設定”フィールドを含んでいる。このローカリティ解決データベースのサーチクエリは、通常のＬＳＩＰリスティングクエリを実行するのに使用されるＮＰＡ、ブック及びＬｏｃを返すことが可能である。
【００２５】以下、図３を参照しながら説明する。動作時において、ＬＤＡＰサーバーアプリケーション１６は、ＤＡシステムのデータベース３０に記憶されたデータに対するリクエストにサービスするために、クライアント１２からのＬＤＡＰリクエストを受信する。詳細には、ＬＤＡＰリクエストは、コンピュータ通信ネットワーク１０を介し、ネットワークインターフェース回路２８Ａ内で受信される。ネットワークインターフェース回路２８Ａは、ＬＤＡＰリクエストをオペレーティングシステム（不図示）に渡し、オペレーティングシステムは、そのＬＤＡＰリクエストを固定記憶２２Ａに記憶されメモリー２４Ａ内で実行されている、ＬＤＡＰサーバーアプリケーション１６に渡す。続いて、ＬＤＡＰプラグイン２０は、そのリクエストをインターセプトし、ＤＡシステムアプリケーション１８に認識され得るクエリに変換する。プラグイン２０は、ＤＡシステムコンパチブルなリクエストをＤＡシステムアプリケーション１８に転送することが可能である。詳細には、プラグイン２０は、そのリクエストをＴＣＰ／ＩＰ通信プロトコルを用いて、オペレーティングシステム（不図示）に渡し、オペレーティングシステムはそのリクエストをネットワークインターフェース回路２８Ａを介して、コンピュータ通信ネットワーク１０に転送する。ＤＡシステムコンパチブルなリクエストは、コンピュータ通信ネットワーク１０を介し、ネットワークインターフェース回路２８Ｂ内で受信される。ネットワークインターフェース回路２８ＢはＬＤＡＰリクエストをオペレーティングシステム（不図示）に渡し、オペレーティングシステムはそのＬＤＡＰリクエストを、固定記憶２２Ｂに記憶されメモリー２４Ｂ内で実行されている、ＤＡシステムアプリケーション１８に渡す。
【００２６】続いて、ＤＡシステムアプリケーション１８は、クエリに基づいてデータベース３０の検索を行い、プラグイン２０を介してＬＤＡＰサーバーアプリケーション１６に対して、結果セットを返す。詳細には、ＤＡシステムアプリケーション１８はその結果セットをＴＣＰ／ＩＰ通信プロトコルを用いてオペレーティングシステム（不図示）に渡し、オペレーティングシステムは更にそのリクエストをコンピュータ通信ネットワーク１０に、ネットワークインターフェース回路２８Ｂを介して送信する。結果セットは、コンピュータ通信ネットワーク１０を介し、ネットワークインターフェース回路２８Ａ内で受信される。ネットワークインターフェース回路２８Ａはその結果セットをオペレーティングシステム（不図示）に渡し、オペレーティングシステムは結果セットをプラグイン２０に渡すことが可能である。プラグイン２０はそのＤＡシステムコンパチブルな結果をＬＤＡＰフォーマットコンパチブルなフォーマットに変換し、変換後の結果をＬＤＡＰサーバーアプリケーション１６に渡す。次に、ＬＤＡＰサーバーアプリケーション１６は、結果セットをクライアント１２内に存在し、実行されている要求元のＬＤＡＰクライアントに送信することができる。ＬＤＡＰリクエストの変換が行われると、プラグイン２０は変換されたＤＡシステムコンパチブルなリクエスト、例えばＬＳＩＰリクエストを、ＤＡシステム１８に送信する。詳細には、プラグイン２０は、そのリクエストをＴＣＰ／ＩＰ通信プロトコルを使ってオペレーティングシステム（不図示）に送信可能で、オペレーティングシステムは、そのリクエストを、ネットワークインターフェース回路２８Ａを介してコンピュータ通信ネットワーク１０に送信する。ＤＡシステムコンパチブルなリクエストは、コンピュータ通信ネットワーク１０を介し、及びネットワークインターフェース回路２８Ｂを介してＤＡシステム１８内で受信される。より詳細には、ネットワークインターフェース回路２８Ｂは、ＤＡシステムコンパチブルなリクエストを含むデータパケットを受信でき、更にそのＤＡシステムコンパチブルなリクエストを、固定記憶２２Ｂに記憶されメモリー２４Ｂで実行されているＤＡシステムアプリケーション１８に送信する。
【００２７】次に、ＤＡシステム１８はＤＡシステムコンパチブルなリクエストに基づいてデータベース３０の検索を実行可能である。データベース３０からリストが取得できたら、結果セットが生成される。例えば、ＩＢＭ ＤＡシステムの場合、ＬＳＩＰ照会データベースからリストが取得されると、マッチングリストに対応し、個々のマッチングリストに含まれているＮＰＡ、ブック及びＬｏｃの各々が結果セットとして返される。ＤＡシステム１８は、その結果セットをＴＣＰ／ＩＰ通信プロトコルを用いてオペレーティングシステム（不図示）に転送可能であり、オペレーティングシステムはそのリクエストを、ネットワークインターフェース回路２８Ｂを介してコンピュータ通信ネットワーク１０に送信可能である。結果セットは、コンピュータ通信ネットワーク１０を介し、ネットワークインターフェース回路２８Ａ内で受信される。ネットワークインターフェース回路２８Ａは、その結果セットをオペレーティングシステム（不図示）に渡し、オペレーティングシステムはその結果セットをプラグイン２０に渡す。重要な点は、プラグイン２０が更にＤＡシステムコンパチブルな結果セットをＬＤＡＰコンパチブルなフォーマットに変換可能で、更にそれをＬＤＡＰサーバーアプリケーション１６に渡すことができることである。すなわち、この結果セットは、仮想的なＬＤＡＰツリーの中で結果セットの相対的位置を示すために、ＬＳＩＰベースのリスト向けのＤＮに逆変換される。続いてＬＤＡＰサーバーアプリケーション１６は、結果セットを、クライアント１２内に存在し実行されている要求元のＬＤＡＰクライアントに転送する。
【００２８】図４は、ＤＡシステムにＬＤＡＰインターフェースを実装するための好ましい方法を示す。現状のＤＡシステムにおいて、カスタマーのデータのローカリティを適切に表現するために、カスタマーのリストを含む全てのローカリティを含むよう、地理的な表現が定義される。このようなプロセスは、ファイル更新プログラム（ＦＵＰ）プロセス５４により実行される。本発明においては、カスタマーデータをロードするステップをＦＵＰプロセスに付け加えることが可能である。詳細には、この追加ステップは、ディレクトリ情報のＬＤＡＰローカリティベースの構成及び、ディレクトリ情報のＬＳＩＰローカリティベースの構成を生成することが可能である。片方を他方にマッピングするためには、ローカリティ解決データベース７０が更に生成される。特に、ローカリティ入力５２及び可能性としてはその他の入力５８があると、ＦＵＰプロセス５４は、ＬｏｃＭｅｎｕデータベース６８内のローカリティ６０、ドメインデータベース６６内のドメイン６２及びＬＳＩＰ照会データベース３０内のリスト６４をそれぞれ更新する。更に、ローカリティプロセッサー５６は、ＬＳＩＰとＬＤＡＰ双方用にロードファイルを構成するために、現存するデータベース６６、６８内に記憶されているローカリティ及びドメイン情報６０、６２を利用することが可能である。カスタマーのローカリティのすべてが、ローカリティプロセッサー５６に送出されるのが望ましい。ローカリティプロセッサー５６は、ドメイン／ローカリティロードファイル７２を生成可能である。ドメイン／ローカリティロードファイルは、中間レコードフォーマット（ＩＲＦ）７４及びＬＤＡＰディレクトリ情報フォーマット（ＬＤＩＦ）７６を並行処理することが可能である。
【００２９】特に、ＬＤＩＦ ７６は、ＬＳＩＰデータベース３０とは対照的に、カスタマーが、現実の”真の”ＬＤＡＰディレクトリデータベース４０に存在するであろう拡張リストを所有する場合にのみ使用されるのが好ましい。ＬＤＩＦ ７６は、トップダウンからリストエントリーまでのローカリティベースの階層構造を有する。したがって、ディレクトリ内のノード若しくは識別名（ＤＮ）が、”ｃｎ＝Ｊｈｏｎ Ｄｏｅ， Ｉ＝Ｂｏｃａ Ｒａｔｏｎ， Ｉ＝Ｂｏｃａ Ｒａｔｏｎ Ｗｉｎｄｏｗ， Ｉ＝Ｈｉｇｈｌａｎｄ Ｂｅａｃｈ Ｄｉｒｅｃｔｏｒｙ， ｓｔ＝ＦＬ，．．．ｃ＝ｕｓ”を含む場合、対応するＬＤＩＦ表現は、以下のようになろう。
ｒｏｏｔ ｜ ∧ ｃ＝ｕｓ ．．．
∧ ｓｔ＝ＦＬ ∧ I＝ＨＩｇｈｌａｎｄ Ｂｅａｃｈ Ｄｉｒｅｃｔｏｒｙ ∧ Ｉ＝Ｂｏｃａ Ｒａｔｏｎ ∧ ｃｎ＝Ｊｈｏｎ Ｄｏｅ【００３０】リストエントリーは、識別ネーム内の上記ローカリティ階層に依存するので、カスタマーサイト向けのローカリティのＬＤＩＦファイルは、現実のリストレコードのローディングに際しての必要条件としてロードされることが望ましい。同様に、ＩＲＦ ７４はＬＳＩＰローカリティ解決データベース７０内で索引付けられた場所の階層を表現することが可能である。例えば、ＩＲＦ ７４はローカリティ解決データベース７０内に記憶された、表１に示されるような場所の階層を表現することができる。
【表１】

以上要約すると、本発明の好適な実施例において、カスタマーサイトのローカリティは、二つのフォーマットで表現され、その１つはＬＳＩＰローカリティ解決データベース７０ロードのためのＩＲＦであり、他は、カスタマーが、ＬＳＩＰローカリティ解決データベース７０内に存在しない拡張リストを有する場合のＬＤＡＰデータベース４０ロードのためのＬＤＩＦである。
【出願人】 【識別番号】３９０００９５３１
【氏名又は名称】インターナショナル・ビジネス・マシーンズ・コーポレーション
【氏名又は名称原語表記】ＩＮＴＥＲＮＡＴＩＯＮＡＬ ＢＵＳＩＮＥＳＳ ＭＡＳＣＨＩＮＥＳ ＣＯＲＰＯＲＡＴＩＯＮ
【出願日】 平成１３年７月１７日（２００１．７．１７）
【代理人】 【識別番号】１０００８６２４３
【弁理士】
【氏名又は名称】坂口 博 （外２名）
【公開番号】 特開２００２−１０８６８３（Ｐ２００２−１０８６８３Ａ）
【公開日】 平成１４年４月１２日（２００２．４．１２）
【出願番号】 特願２００１−２１６４５４（Ｐ２００１−２１６４５４）