JP4771321B2 - データをジャバ・システム・データベース・エントリ及びｌｄａｐディレクトリ・サービスの間で交換するための方法及びデータ・フォーマット - Google Patents
データをジャバ・システム・データベース・エントリ及びｌｄａｐディレクトリ・サービスの間で交換するための方法及びデータ・フォーマット Download PDFInfo
- Publication number
- JP4771321B2 JP4771321B2 JP2000022256A JP2000022256A JP4771321B2 JP 4771321 B2 JP4771321 B2 JP 4771321B2 JP 2000022256 A JP2000022256 A JP 2000022256A JP 2000022256 A JP2000022256 A JP 2000022256A JP 4771321 B2 JP4771321 B2 JP 4771321B2
- Authority
- JP
- Japan
- Prior art keywords
- server
- directory
- directory service
- configuration
- ldap
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
- G06F11/3466—Performance evaluation by tracing or monitoring
- G06F11/3476—Data logging
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/28—Databases characterised by their database models, e.g. relational or object models
- G06F16/282—Hierarchical databases, e.g. IMS, LDAP data stores or Lotus Notes
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
- G06F2201/80—Database-specific techniques
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99941—Database schema or data structure
- Y10S707/99944—Object-oriented database structure
- Y10S707/99945—Object-oriented database structure processing
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99941—Database schema or data structure
- Y10S707/99948—Application of database or data structure, e.g. distributed, multimedia, or image
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Databases & Information Systems (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Quality & Reliability (AREA)
- Computer Hardware Design (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Data Mining & Analysis (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Computer And Data Communications (AREA)
- Communication Control (AREA)
Description
【０００１】
【発明の背景】
一般的に、本発明はコンピュータ・ソフトウェア及びコンピュータ・ネットワーク・アプリケーションに関する。より詳細には、本発明はクライアント・サーバー・アプリケーションに関し、さらには、コンピュータ・ネットワーク内の複数のコンポーネント間またはストレージ領域間におけるコンフィギュレーション・データの転送及び配置に関する。
【０００２】
従来のコンピュータ・ネットワークは、一般的にクライアントと称される一連のパーソナル・コンピュータを１つ以上のサーバー・コンピュータへ接続することを伴う。一般的に、クライアント・コンピュータは自立しており、ユーザー・アプリケーションを実行し、かつ、ネットワークと通信するために必要な情報の殆どを自身の常駐メモリ内に格納している。この情報はソフトウェア及びハードウェアの機能及び用件に関するクライアント・コンピュータのコンフィギュレーション情報を含む。一般的に、ネットワーク・ソフトウェア・アプリケーションへのアクセス、電子メールの送受信、ネットワーク・データベース上の情報の収集及び格納、またはインターネットへのアクセスなどの様々な理由から、クライアント・コンピュータはネットワーク・サーバーへアクセスする。しかし、一般的に、特定のクライアント・コンピュータに固有の情報は、そのクライアント・コンピュータ上に存在する。例えば、この情報はメモリ仕様、バス・タイプ、追加プロセッサ及び他のハードウェア仕様を含み得る。クライアント・コンピュータは比較的自立しており、自己のコンフィギュレーション情報を自身で格納している（これはこの種のデータをサーバー上に格納するのとは全く異なる）。このため、エンド・ユーザー・アプリケーション・データ以外に、コンフィギュレーション及びユーザーに関するデータをクライアント・コンピュータ上で管理するタスクは大きな負担になってきている。
【０００３】
ネットワーク・サーバー上に存在するアプリケーションの小規模なアップグレードまたは修正をクライアント・コンピュータへ伝達することは可能である。しかし、全てのクライアントに影響を及ぼす大規模なアップグレード、大規模な修正、または新たなアプリケーションのインストールでは、ネットワーク管理者がクライアント・コンピュータへ個々にアクセスし、かつ、アップデートすることを必要とする。ネットワークに接続されているコンピュータの数量の増加（幾つかの企業では、この数は何万台にも達している）によって、アプリケーション・ソフトウェアまたは汎用コンフィギュレーション・ソフトウェアに対する大規模なリビジョンまたはアップグレードのインストールの負担は、費用が嵩み、非効率的であり、かつ、多くの時間を必要とするものとなっている。更に、殆どのクライアント・コンピュータが自立しているので、アプリケーション及びコンフィギュレーション・データに関する個人設定（personal preferences）を維持することは、複数の異なる場所（location）にそれぞれ位置する複数の異なるクライアント・コンピュータを使用しているユーザーにとって困難である。即ち、ユーザーは個人設定を自分が通常使用するクライアント・コンピュータへデフォルトとしてインストールできる。しかし、他のクライアント・コンピュータのデフォルトを変更せずに、自分が通常使用するクライアント・コンピュータのデフォルトを他のクライアント・コンピュータへ複製することは厄介である。
【０００４】
前記のように、従来のネットワーク・コンフィギュレーションでは、新たなソフトウェアまたは新たなアプリケーションをインストールするプロセスは、静的プロセスである。そして、このコンフィギュレーションでは、各クライアントに関するコンフィギュレーション情報は各クライアント・マシン上で定義されている。従って、ネットワーク管理者は各クライアント上のコンフィギュレーションを静的に決定（define）する。従来のコンピュータ・ネットワークでは、特定の各サブシステム、即ち、クライアントに関するコンフィギュレーション情報は、このクライアント内にハードコード化されている。更に、ネットワーク・サーバーへ接続された自立しているクライアントを使用する従来のネットワーク・コンフィギュレーションでは、サブシステムのコンフィギュレーションへのアクセスを要する、ソフトウェアに対する大規模なアップグレードのインストールなどといったアプリケーション・メインテナンスは、通常、そのメインテナンスを実施するためのネットワークの“ダウン”を必要とする。
【０００５】
複数のクライアントと、クライアントが様々な理由で必要とする情報を有するサーバーとを含む従来のコンピュータ・ネットワークでは、多くの場合、クライアントが必要とするデータまたはクライアントに関連するサーバー上の全てのデータは、サーバーからクライアントへ移される。一般的に、これは大量のデータの移動を伴う。そして、これらのデータのうちの殆どは、クライアントを動作させるために使用されないものであり、または不必要なものである。全てのデータをクライアントへ移動させることは非効率的であり、かつ、ネットワーク・トラフィックを増大させる。更に、サーバーから送信されたクライアントに関する全ての情報を格納するために、このクライアントは十分なメモリ及びストレージを有する必要がある。例えば、大きなストレージ容量を持たないＰＤＡ及びスマート・カードなどのデバイスは、そのデバイスに関連するコンフィギュレーション情報を含む全ての必要な情報を常駐メモリに格納できない。
【０００６】
多くの従来のエンタープライズ・ワイド・ネットワークの別のコンポーネントとしては、ディレクトリ・サービス及びネーミング・サービスが挙げられる。これらのサービスはネットワーク・ユーザー及びハードウェア・コンポーネントに関するコンフィギュレーション及びマッピングの情報を格納するために使用される。ネットワーク・サービスを要する特定のファンクションを実行するために、ネットワーク内のユーザー及びコンポーネントはこの情報を必要とする。広く使用されている幾つかのディレクトリ・サービスとしては、ウィンドウズＮＴ（商標名）環境内で使用されているＤＮＳ（ディレクトリ・ネーム・サービス）及びＡＤ（アクティブ・ディレクトリ）と、ユニックス環境内でのＮＩＳとが挙げられる。より最近の技術を使用する更に新しく、かつ、パワフルなディレクトリ・サービスとしては、ディレクトリ・サービスのためにエンタープライズ・ネットワーク内で更に広く使用されているライトウェイト・ディレクトリ・アクセス・プロトコル（Lightweight Directory Access Protocol）、即ち、ＬＤＡＰが挙げられる。図１はクライアントがＬＤＡＰディレクトリ・サービス内のデータへアクセスする方法を示すブロック図である。エンタープライズ環境１０４内のクライアント・コンピュータ１０２はＬＤＡＰアクセス・モジュール、即ち、アドオン１０６を有する。クライアント１０２がＬＤＡＰディレクトリ１０８へアクセスする必要がある際、クライアント１０２は線１１０で示すようにモジュール１０６を使用して直接アクセスする。実質的に、ＬＤＡＰディレクトリ１０８は、データベース及びソフトウェア・デーモン（図示略）を有するソフトウェア・サーバーである。コンフィギュレーション及び関連するデータを全て含むデータベース・セグメントの機能は、２つの列を有するテーブル１１２として説明できる。このうちの１つの列は属性を有し、第２列は１つ以上の実際の値を有する。属性はユーザー名（user name）、ログオン名（logon name）、部門識別子（department identifier）またはハードウェア識別子（hardware identifier）を表すものなどの任意のデータ・カテゴリの属性であり得る。ディレクトリ・サービスの１つの効果としては、ネットワーク管理者が、ネットワーク内のユーザーまたはコンポーネントがアクセスする必要のある任意の種類のデータを格納することができるという、柔軟性が挙げられる。１つ以上の値を属性に関連付け得る。例えば、ユーザー固有の設定を表す属性は、自身に関連する幾つかの値を有し得る。そして、これらの値はある種のデリミタで区切られ、かつ、同じ値エントリ内に存在する。ＬＤＡＰディレクトリ１０８の構造及び編成は、コンピュータ・ネットワーク・アドミニストレーションの分野では周知である。
【０００７】
レガシー・システムと称されるこれらの既存のディレクトリ・サービス内に格納された情報は、エンタープライズ・ネットワーク内のクライアント・コンピュータからのアクセスを可能にする必要がある。従って、拡大するネットワーク内におけるアプリケーション及びコンフィギュレーション・データの管理に関する前記の問題点を解決する任意のタイプのコンフィギュレーション・リポジトリ（repository）は、ＬＤＡＰディレクトリ・サービスなどのレガシー・システム上のコンフィギュレーション・データを格納するか、または該コンフィギュレーション・データへのアクセスを有することが必要である。コンフィギュレーション及びユーザー固有のデータを効果的な方法でクライアント・コンピュータへ提供できるコンフィギュレーション・サーバーは、コンフィギュレーション・データを有する既存のディレクトリ・サービスとの間におけるデータの交換を可能にする必要がある。
【０００８】
従って、クライアント・コンフィギュレーション及びユーザー・コンフィギュレーションをセントラル・リポジトリに格納することによって、これらの情報の分散管理をサポートするシステムが望まれる。ネットワーク管理者がサブシステムのコンフィギュレーションをサーバーから管理し、かつ、アプリケーションに対するあらゆる種類の変更をサーバーから伝達することを、これは可能にする。更に、セントラル・リポジトリがレガシー・システム内のコンフィギュレーション・データへのアクセスを最小限のオーバーヘッド処理で迅速に行うとともに、このアクセスをクライアント・コンピュータにとって透過な（transparent）状態で実施することが望ましい。
【０００９】
【発明の概要】
本発明に基づき、データをコンフィギュレーション・サーバー・スキーマと、ネットワーク・ディレクトリ・サービスと、の間で伝達するための方法、データ構造（data structures）及びコンピュータ読取り可能媒体を開示する。本発明の１つの態様では、ディレクトリ・サービス属性と、コンフィギュレーション・サーバー・プロパティと、の間のマッピングを可能にするディレクトリ・サービスに対するエクステンション（extension。データベース・サーバ・スキーマ。）を開示する。ディレクトリ・サービスのエントリは、特定のディレクトリ・サービス属性にそれぞれ対応する複数のシャドー属性を含む。そして、前記の特定のディレクトリ・サービス属性は、対応するプロパティをコンフィギュレーション・サーバー内に有する。更に、エクステンションは、対応情報ファイル、即ち、パス・マッチング・ファイルを有する。それらのファイルは、ディレクトリ・サービス・アドレスと、コンフィギュレーション・サーバー・ロケーション識別子、即ち、パスと、の間の一致情報を含む。
【００１０】
１つの実施形態では、エクステンションは、ディレクトリ・サービス内のタイプのリストと、各ディレクトリ・タイプで使用できる属性を含む属性リストとを有するディレクトリ・サービス・メタ・ディレクトリを、有する。別の実施形態では、各シャドー属性は、対応するコンフィギュレーション・サーバー・プロパティと、コンフィギュレーション・サーバー・ロケーション識別子、即ち、パスと、を有する。更に別の実施形態では、各シャドー属性は、対応するコンフィギュレーション・サーバー・プロパティに関連付けられたクラス名を有する。更に別の実施形態では、コンフィギュレーション・サーバーは、複数のクライアント及び複数のネットワーク・ユーザーに関するコンフィギュレーション・データを有するジャバ・システム・データベース・サーバーである。更に、ロケーション識別子は一連のノードであり、各ノードは情報のカテゴリを示す。更に別の実施形態では、ディレクトリ・サービスはライトウェイト・ディレクトリ・アクセス・プロトコルである。
【００１１】
本発明の別の態様において、コンフィギュレーション・データベースと通信可能なネットワーク・ディレクトリ・サービス内のシャドー属性のためのフォーマットを開示する。シャドー属性は、コンフィギュレーション・データベース内で使用するプロパティ名を格納するコンフィギュレーション・データベース・プロパティを保持するためのフィールドを、有する。シャドー属性は更に、コンフィギュレーション・データベースを検索していく（traverse）ために使用可能なコンフィギュレーション・データベース・パスのためのフィールドを、有する。シャドー属性をシャドー属性として識別するために、シャドー属性に関連付けられたマーカーが、更に含まれている。
【００１２】
１つの実施形態では、シャドー属性フォーマットは、コンフィギュレーション・データベース内へ格納した値に関連付けられたクラス名を格納するための、コンフィギュレーション・データベース・クラス名フィールドを有する。別の実施形態では、ロケーション識別子は階層構造内の一連のノードである。更に別の実施形態では、ディレクトリ・サービスはライトウェイト・ディレクトリ・アクセス・プロトコルであり、コンフィギュレーション・データベースはジャバ・システム・データベースである。
【００１３】
本発明の更に別の態様では、コンフィギュレーション・データをネットワーク・ディレクトリ・サービスからコンフィギュレーション・データベースへ送信する方法を開示する。１つ以上のレギュラー・ディレクトリ・サービス・エントリ及びそれに対応する値を、ネットワーク・ディレクトリ・サービスから収集し、かつ、コンフィギュレーション・データベースへ送信する。ネットワーク・ディレクトリ・サービス内に位置するディレクトリ・サービス内のシャドー・エントリに対するクエリーによって、コンフィギュレーション・データベース内における前記の各対応する値のロケーション及びプロパティ名を決定する。ディレクトリ・サービス内のシャドー・エントリから決定したロケーション、即ち、パスに基づいて、前記の対応する値をコンフィギュレーション・データベース内へ格納する。
【００１４】
１つの実施形態では、前記の１つ以上のディレクトリ・サービス・エントリ及び対応する値を収集する先のネットワーク・ディレクトリ・サービス内のコンテキストを決定する。別の実施形態では、各レギュラー・ディレクトリ・サービス・エントリを各シャドー・ディレクトリ・サービス・エントリと区別する。別の実施形態では、シャドー・ディレクトリ・サービス・エントリは、コンフィギュレーション・データベース上のパスと、コンフィギュレーション・データベースに関連付けられたプロパティ名とを含む。
【００１５】
本発明の更に別の態様において、データをＬＤＡＰサーバーから収集し、かつ、ジャバ・ベースのコンフィギュレーション・サーバーへ送信する方法を開示する。ジャバ・ベースのコンフィギュレーション・サーバー内の上位パスと、特定のＬＤＡＰアドレスと、の間の一致関係（match）を見つけるために、ロケーション一致情報ファイル（location matching file）をサーチする。
サーチすべきＬＤＡＰサーバーの一部を決定するために、前記の特定のＬＤＡＰアドレスを使用しつつ、１つ以上の属性を見つけるために、ＬＤＡＰサーバーの一部をサーチする。前記の１つ以上の属性に対応する１つ以上の値を収集する。前記の値をジャバ・ベースのコンフィギュレーション・サーバーへ送信し、これによって、前記の値をジャバ・オペレーティング・システム環境内のクライアント・コンピュータで使用可能にする。
【００１６】
【詳細な開示】
本発明の特定の実施形態を以下に詳述する。更に、この特定の実施形態の例を添付図面に示す。本発明を特定の実施形態に関連して詳述するが、これは本発明を１つの特定の実施形態に限定することを意図するものではない。逆に、請求の範囲に定義する本発明の精神及び範囲に属する別例、変更例及び等価なものを網羅することを意図する。
【００１７】
ＬＤＡＰディレクトリ・サービス内の属性またはエントリをコンフィギュレーション・サーバー・スキーマへマッピングするための方法及びシステムを複数の図面に示す。本実施形態では、コンフィギュレーション・サーバーはジャバ・システム・データベース（Java System Database、略して“ＪＳＤ”と称する）と呼ばれるソフトウェア・コンポーネントを有する。本発明のＪＳＤは、１９９８年５月１４日に出願された“コンフィギュレーション情報をサーバー・コンピュータ上に格納するためのジェネリック・スキーマ（A Generic Schema for Storing Configuration Information on a Server Computer）”と称される継続中の米国特許出願第０９／０７９，５００号と、１９９８年５月１４日に出願された“ジャバ・システム・データベース”と称される米国仮特許出願第６０／０８５，４２５号とに更に詳細に開示されており、これら２つの米国特許出願の内容はこの開示をもって本明細書中に開示したものとする。以下に詳述するように、ＪＳＤサーバー・スキーマは１つ以上のプロパティ及び対応するデータ値を含む効果的に定義されたノード及び“リーフ”ノードを有するツリー構造である。従って、ＪＳＤサーバー・スキーマ内の特定の各データ・アイテムの場所（location）は、スラッシュで区切られた一連のノード名として伝達できる。図１０に示すように、本発明におけるＪＳＤサーバー内の各プロパティのパスを定義する能力は、ＬＤＡＰディレクトリ・サービスのエントリまたは属性をＪＳＤサーバー・プロパティへ“マッピング”することを可能にする。
【００１８】
ＴＣＰ／ＩＰ上で実行するオープン・スタンダード・プロトコルであるライトウェイト・ディレクトリ・アクセス・プロトコル（ＬＤＡＰ）を使用するネットワーク・ディレクトリ・サービスの構造及び使用方法は、当該技術分野では周知であるが、本発明のマッピングの特徴（feature）に特に関連したＬＤＡＰの幾つかの特定の特徴（feature）を説明することは効果的である。一般的に、ネットワークＬＤＡＰディレクトリ・サービスはネットワークのコンフィギュレーション・データを格納している。そして、このデータは従来のデータベース内に格納されているデータより更に記述的であり、かつ、属性に基づいている。一般的に、このデータは書き込まれる頻度よりも読み出される頻度のほうが高い。大量の照合オペレーション（high-volume lookup operation）、即ち、サーチ・オペレーションに対する素早いレスポンスを提供すべくディレクトリは調整されている。コンフィギュレーション・データは、クライアント・コンピュータなどのシステムを設定するために使用するデータとして、広く記述されている。そして、ユーザーがネットワーク内のどのクライアント・コンピュータへログオンしているかには無関係に、ユーザー環境をセットアップするための、ユーザー・プロフィールに関連するデータである。更に、ＪＳＤサーバー・スキーマはコンフィギュレーション・データを格納するが、ＬＤＡＰサーバーのスケーラビリティを有していない。従って、大量のデータをＬＤＡＰサーバー上に格納し、これらのデータをネットワーク上の全てのユーザーが使用できるようにすることは、これらの全データをＪＳＤサーバー上に格納することより更に効果的である。
【００１９】
ＬＤＡＰサーバーの１つの特徴（feature）としては、属性またはキーと称されるデータ・アイテムの場所（location）を定義するために使用する、絶対ネーム及び相対ネームのコンベンション（convention）が挙げられる。このうちの特に関連するものとしては、ＬＤＡＰディレクトリ内の属性を探し当てるために使用する絶対ネームが挙げられる。絶対ネームはＪＤＳサーバー内のノードに類似する一連の“識別ネーム（distinguished names）”を含む。一般的に、ＬＤＡＰモデルはエントリに基づいている。エントリは属性の集合（collection）である。このようなエントリは識別ネーム（distinguished name、略して、“ＤＮ”）と称される。属性は１つ以上の値を有することが可能であり、かつ、特定のタイプに属し得る。一般的に、タイプはユーザー名を示すｕｎ若しくはｕ、電子メール・アドレスを示すｍｌ、または組織を示すｏなどの記憶用文字列、ニーモニック・ストリング（mnemonic string）である。各タイプは属性のコレクションを有する。例えば、ｕｎは一般名（common name）、ラスト・ネーム（last name）及びログオン名（logon name）などの属性を有し得る。識別ネームｏは属性であるメール（mail）及びファックス（fax）を有することが可能であり、メール及びファックスの後には、１つ以上の値がそれぞれ続いている。
【００２０】
ＬＤＡＰ内のエントリは、組織の境界を一般的に表す階層ツリーに似た構造（structure）内に配置されている。例えば、国を表すエントリは、ツリーのトップの識別ネームｃの下に見られることが多い。そして、この国を表すエントリの次には、ビジネス・ユニット（ｂｕ）を表すエントリが続き、その次には、例えば、プリンタ、クライアント・コンピュータまたはネットワーク・ユーザーのうちの任意の１つを表す更に具体的なエントリが続いている。図２はＬＤＡＰディレクトリ・ツリーの階層ブロック図である。ＬＤＡＰオープン・スタンダードの更なる詳細と、このスタンダードのデータ編成と、識別ネームの使用法とは１９９５年３月に発行されたWengyik Yeong、Tim Howes及びSteve Killeによる“ライトウェイト・ディレクトリ・アクセス・プロトコル（The Lightweight Directory Access Protocol）”と称されるリクエスト・フォー・コメンツ（Request for Comments、略して、“ＲＦＣ”）のナンバー１７７７と、１９９５年３月に発行されたSteve Killeによる“識別ネームのストリング表現（A String Representation of Distinguished Names）”と称されるＲＦＣ１７７９とに開示されており、これら２つの文献の内容は、この開示をもって本明細書に開示したものとする。
【００２１】
図２に示すディレクトリ・ツリー２００は、ニーモニックｃで表される国のトップレベル識別ネームに対応する３つのノードを有する。ノード２０２は米国を表す。ニーモニックｃはタイプとも称される。ノード２０２は、そこから分岐した２つのノード２０４，２０６を有し、これら２つのノード２０４，２０６は組織を示す識別ネームoに属する。ノード２０４は組織としてのネットスケープ（Netscape）を示す。タイプｏを有するネットスケープは、この例で示す２つの属性、即ち、“メール（mail）”及び“ファックス（fax）”を有しており、対応する値がこれらの後に続いている。ノード２０６は別の組織、即ち、サン（Sun）を示しており、２つのノードがそこから分岐している。ノード２０６はノード２０４に類似する属性のリスト（全てタイプｏ）を有し得るが、図示は省略してある。次のレベルの識別ネームはビジネス・ユニット・タイプを示すｂｕである。サン・ノード２０６の下には、２つのノードが存在し、これらは２つともタイプｂｕである。ノード２０８は“サン・ソフト（SunSoft）”ビジネス・ユニットを示す。更に、サン・ソフトは属性の集合（collection）（全てタイプｂｕであり、図２における図示略）を有する。ノード２０８の下には、識別ネームｕで表されるユーザー、即ち、Jonathan A. Smithのノード２１０が存在する。サン・ソフト・ビジネス・ユニットは、該ビジネス・ユニット内の全てのネットワーク・ユーザーを表すノード２１０に類似した多数のノードを有し得る。ｕタイプは属性のリスト２１２を有する。各属性の後には、１つ以上の値が続いている。ＬＤＡＰの多くのインプリメンテーションでは、これらの値はストリング・フォームまたはバイナリ・フォームであることを要する。図２に示す例では、ｕの識別ネームの下には、別の識別ネームは存在しない。ＬＤＡＰで実現（implement）されるディレクトリ・サービスの１つの効果としては、ハードウェア・コンポーネントに関係するデータ、ユーザー設定及びスタートアップ・データなどの全ての種類の情報を格納する柔軟性が挙げられる。
【００２２】
一般的に、ＬＤＡＰディレクトリは複数のコンテキストを有する。新たなコンテキストを形成した際、そのコンテキストに関する図３に示す１つの絶対ネーム、即ち、識別ネームの階層を定義する。コンテキストは、特定のファンクションをアドレスするために定義される。コンテキストの幾つかの例としては、“クライアント・ブートアップ（client boot-up）”、“ユーザー固有のプリファレンス（user-specific preferences）”、“ファイナンシャル・リポート（financial reports）”または“エンジニアリング・デパートメント・データ（engineering department data）”が挙げられる。コンテキストは、ＬＤＡＰディレクトリのデータベース部分を構成する上位セグメントと見なし得る。例えば、ＬＤＡＰディレクトリ内のデータへのクライアントによるアクセスの制限は、コンテキスト・レベルでセットされる。
【００２３】
各コンテキストは、そのコンテキストが形成された際に定義された１つの絶対ネーム・スキーマ（一般的に、これはネットワーク管理者が定義する）を有する。ＬＤＡＰ内の絶対ネーム・スキーマまたは絶対ネーム・コンベンションは識別ネームのリストである。図３はＬＤＡＰディレクトリ・サービス内における図２の階層構造を表すネーム・スキーマ及びそれに関連する属性を示す図である。ネーミング・コンフィギュレーション、即ち、階層はネーム・スキーマの右側に位置する識別ネーム“c=US”２１４から始まる。識別ネームｃは、異なる国をそれぞれ表す多数の値のうちの任意の１つを有し得る。次の識別ネームo=Sun２１６は階層内の次の下側のレベルを表す。この例では、識別ネームoは“組織”を表し、かつ、他の組織または企業を示すストリング値を有し得る。その左側の識別ネームは更に具体的であり、ｂｕはビジネス・ユニット２１８を表し、ｕはユーザー２２０を表す。各識別ネーム、即ち、タイプは一連の属性を有する。例えば、識別ネームu=Jonathan A. Smith２２０は図２で最初に説明した一連の特定の属性２１２を有する。識別ネームの全体ストリング２２２は絶対アドレスと呼ばれたり、時には、完全識別ネームと呼ばれたりする。
【００２４】
前記のように、ネットワーク内のクライアント・コンピュータ、ユーザー及び他のコンポーネントのコンフィギュレーション・データの一部は、ＪＳＤサーバー・スキーマ内に格納される。これはクライアントに関するコンフィギュレーション・データをクライアント・マシン上でハードコード化する、即ち、格納する従来のネットワークとは対照的である。ネットワーク管理者がエンタープライズ・ネットワーク内の各コンピュータに関するコンフィギュレーション情報をセントラル・リポジトリ（repository）から管理することを、ＪＳＤサーバー・スキーマは可能にする。従って、サブシステム（例：クライアント・コンピュータ）のコンフィギュレーションに関する知識と、同コンフィギュレーションへのアクセスとを必要とする任意のソフトウェア・アップデート、バージョン・アップグレードまたは新たなアプリケーションのインストールをセントラル・リポジトリから実行（implement）し、かつ、各サブシステムへ伝達できる。例えば、アプリケーションの新たなアップグレードまたはバージョンをインストールまたは伝達するために、クライアント・コンピュータ上のユーザーはアプリケーションを終了させる必要がないうえ、ネットワークをメインテナンスのためにダウンさせる必要がない。
【００２５】
図４は本発明の１つの実施形態に基づくシステム・ワイド・データ・スキーマを有するコンピュータ・ネットワークのコンポーネントを示す概略図である。本実施形態では、システム・ワイド・データ・スキーマはネットワーク３０７の一部としてクライアント・マシン３０５上に存在するクライアント・スキーマ３０３からなるジャバ・システム・データベース、即ち、ＪＳＤ３０１として実現（implement）されている。ＪＳＤサーバー・スキーマ３１１はネットワーク３０７の一部をなすサーバー・コンピュータ３０９上に存在する。前記のように、ＬＤＡＰディレクトリ・サービスと通信するのは、サーバー３０９（“ＪＳＤサーバー”）上のＪＳＤサーバー・スキーマ３１１である。従って、ＪＳＤサーバー・スキーマ３１１を以下に詳述する。
【００２６】
図５は本発明の１つの実施形態に基づくＪＳＤサーバー・スキーマの構造を示すブロック図である。これは図４のサーバー・コンピュータ３０９及びサーバー・スキーマ３１１の更なる詳細を示す。本実施形態では、ｎ分岐ツリーのトップには、“CONFIG”と呼ばれるルート・エントリ・ノード４０１が存在する。２つのネームスペースがサーバー・スキーマ内に存在する。領域４０３はマシン・ノード３０５を有するマシン・ネームスペース（MACHINE namespace）を表す。領域４０７はユーザー・ノード４０９を有するユーザー・ネームスペース（USER namespace）を表す。
【００２７】
本実施形態では、マシン・ネームスペース４０３は３つのカテゴリ、即ち、プラットフォーム（platform）４１１、識別子（identifier）４１３及びプロフィール（profile）４１５を有する。プラットフォーム３１１の下には、例えば、特定のコンピュータ製造業者を示す多数のエントリが存在する。別の実施形態では、マシン・ネームスペース４０３はネットワークのプラットフォーム及び要件に基づいて更に多くの数のサブ・カテゴリまたは更に少ない数のサブ・カテゴリを有し得る。この詳細を図６に示す。
【００２８】
図６はサーバー・スキーマ３１１内のマシン・ネームスペース４０３の階層構造を示す概略図である。プラットフォーム４１１のカテゴリの下には、一般的に、ベンダー固有のサブ・レンジ５０１，５０３が存在する。このレベルにおけるエントリの総数は、例えば、ネットワーク内で使用されている異なる複数のコンピュータ製造業者から供給されたコンポーネントの総数に基づいて定まり得る。サン・マイクロシステムズ（Sun Microsystems）などの特定の製造業者の下には、サン・マイクロシステムズが製造した特定のモデル、即ち、タイプのコンピュータを示す２つのエントリ５０５，５０７が存在する。例えば、サン（Sun）の下には、コンピュータ・タイプＪＤＭ１が存在する。各コンピュータ・モデルの下には、そのタイプのコンピュータのアプリケーション・コンフィギュレーション・データを特定するノード５０９などのリーフ・ノードが存在する。リーフ・エントリ内のアプリケーション・コンフィギュレーション・データは、親エントリ（例：ノード５０７）内に示されている特定のコンピュータへ適用可能な全てのコンフィギュレーションを含む。
【００２９】
識別子カテゴリ４１３の下には、図４のネットワーク３０７内の各コンピュータのノード５１１内に示す識別子などの固有識別子を含むエントリが存在する。本実施形態では、各コンピュータのメディア・アクセス・コントロール（media access control、略して、ＭＡＣ）アドレスを固有識別子として使用している。クライアント識別子５１１の下のリーフ・ノード５１３は、この特定のコンピュータに固有のアプリケーション・コンフィギュレーション情報を含む。識別子４１３の下のコンフィギュレーション・データ５１３は特定のユーザーが設定した特定のコンピュータへ適用されるので、コンフィギュレーション・データ５１３をプラットフォーム・カテゴリ４１１の下のコンフィギュレーション・データ５０９と区別できる。本実施形態では、識別子カテゴリの下の固有識別子４１１と、プラットフォーム・カテゴリ４１１の下のエントリとの間には、クロス・リファレンス（図示略）が存在する。即ち、特定の識別子から特定のタイプのコンピュータへのリファレンスが存在する。これにより、特定の固有識別子が示すプラットフォームまたはコンピュータのタイプをサーバーが決定することができる。
【００３０】
プロフィール・カテゴリ４１５の下には、ネットワーク内のコンピュータの特定のカテゴリまたは使用方法を記述するエントリが存在する。例えば、企業内の部門を表し得る特定のプロフィールに関するコンフィギュレーション情報はプロフィール・カテゴリ４１５の下に含まれる。この例を財務（finance）プロフィールのノード５１５及び販売（sales）プロフィールのノード５１７に示す。財務ノード５１５の下には、財務プロフィールに関連するデータを含むアプリケーション固有データ５１９が存在する。固有識別子からプラットフォーム・エントリへのリファレンスと同じように、必要に応じて、特定の識別子リーフ・ノード５１３からプロフィール・エントリ、即ち、ノード５１９へのリファレンスが存在する。即ち、経理部門で使用しているコンピュータまたは受付係端末としてのみ使用しているコンピュータなどの特定のコンピュータが特定のプロフィールを有する場合、そのコンピュータの識別子から適切なプロフィール・エントリへのリファレンスが存在する。
【００３１】
図７は本発明の１つの実施形態に基づくユーザー・ネームスペースを示す概略図である。本実施形態では、ユーザー・ネームスペース４０７は２つのカテゴリ、即ち、ユーザー（users）及びグループ（groups）を有する。ユーザー・カテゴリ（Users category）４１７はノード６０１，６０３，６０５などに示すネットワーク３０７上の各ユーザーの名前を表す。各ユーザーのノードの下には、リーフ・ノード６０７で示すような各ユーザーの個人設定を含む特定のコンフィギュレーション・データが存在する。例えば、ワードプロセッシング・アプリケーションでは、特定のユーザー設定（user preference）は、デフォルトのフォント及び文書のフォーマット設定を含み得る。このカテゴリによれば、各ユーザーがネットワーク３０７上の任意のコンピュータを使用することができ、かつ、そのユーザー個人のコンフィギュレーション（即ち、個人設定）が、そのコンピュータに知らされるようになる。例えば、このユーザーがワード・プロセッシング・プログラムを起動した場合、そのユーザーの個人設定（preference）がコンピュータの通常のユーザーのデフォルトに代わってデフォルトとなる。
【００３２】
ユーザー・ネームスペース内のもう一方のカテゴリはグループ・カテゴリである。このカテゴリは特定のユーザーのグループに関するエントリを含む。グループ（Groups）４１９は様々なカテゴリを含み得る。このカテゴリの例としては、ノード６０９，６１１に示すような企業内の部門、即ち、企業内の各従業員を他の従業員と区別するカテゴリが挙げられる。本実施形態では、適切な場合、ユーザー・カテゴリ４１７の下の各ユーザー６０３，６０５から１つ以上の特定のグループへのリファレンス・ポインタが存在する。
【００３３】
図８は本発明の１つの実施形態に基づくジャバ・システム・データベース環境内で動作するコンフィギュレーション・サーバーからＬＤＡＰディレクトリ内のデータへアクセスするプロセスを示すフローチャートである。図８のフローチャートはクライアント・ネットワークを保持すべく前記の図４〜図７で説明したＪＳＤサーバー・スキーマによって設定したコンフィギュレーション・サーバーと、ユーザー・コンフィギュレーション・データとを使用している。ステップ７０２では、ＪＳＤサーバーのブートアップ後、該ＪＳＤサーバーはコンフィギュレーション・データをＬＤＡＰディレクトリ・サーバーからインポートする、即ち、キャッシングする。このステップでは、ＪＳＤサーバー・スキーマはＬＤＡＰディレクトリ・サービスから得られた自身が必要とするコンフィギュレーション・データの“イニシャル・ポピュレーション”を調べる。このステップは以下の図９で詳述する。ステップ７０４では、クライアント・コンピュータをブートアップし、特定のユーザーがこれにログオンする。このクライアント・コンピュータのコンフィギュレーション・データと、前記の特定のユーザーのコンフィギュレーション・データとを収集する（retreave）ために、このクライアント・コンピュータはＪＳＤサーバーへアクセスする。データをクライアントＪＳＤスキーマ及びサーバーＪＳＤスキーマの間で交換するためのプロトコルは、１９９８年５月１４日に出願された“コンフィギュレーション・データをコンピュータ・ネットワーク内で交換するためのプロトコル（A Protocol for Exchanging Configuration data in a Computer Network）”と称される米国特許出願第０９／０７９，４９９号に更に詳細に開示されており、この特許出願の内容はこの開示を持って本明細書中に開示したものとする。
【００３４】
ステップ７０６では、通常のユーザー・アクティビティ及びクライアント・オペレーション中、ＪＳＤサーバーはクライアントが要求（request）したデータ、即ち、クライアントが必要とするデータがＪＳＤサーバー・スキーマ内に存在するか否かを判定する。クライアントが必要とするコンフィギュレーション・データをＪＳＤサーバーから入手可能な場合、このコンフィギュレーション・データを収集する。そして、コントロールはステップ７１０へ移行し、このコンフィギュレーション・データをクライアントへ送信する。コンフィギュレーション・データをＪＳＤサーバーから入手できない場合、コントロールはステップ７０８へ移行し、必要なコンフィギュレーション・データをＬＤＡＰディレクトリ・サーバー上で探し当てる。このプロセスは図１３で詳細に説明する。前記のコンフィギュレーション・データ・アイテムを有する正しいリーフ・ノードに到達するまで、適切なネームスペース（マシン・ネームスペースまたはユーザー・ネームスペース）及びそれに続くカテゴリを識別していくことによって、前記のコンフィギュレーション・データ・アイテムをＪＳＤサーバー内で探し当て得る。例としては、CONFIG/MACHINE/identifier/（ＭＡＣアドレス）/（特定のコンフィギュレーション・プロパティ）のような“パス”が挙げられる。
【００３５】
以下に詳述するマッピング・プロセスを介することにより、このパスの一部はデータをＬＤＡＰサーバーからＪＳＤサーバー・スキーマへ返すために使用される。ＬＤＡＰサーバーからのデータは収集され、かつ、ＪＳＤサーバー・スキーマへ送信される。ステップ７１０では、コンフィギュレーション・データはクライアントへ送信され、プロセスは完了する。
【００３６】
図９は本発明の１つの実施形態に基づくＪＳＤサーバーをＬＤＡＰディレクトリ・サービスを用いて初期化するプロセスを示すフローチャートである。これは図８のステップ７０２の詳細を示す。ステップ８０２では、ＪＳＤサーバーは、ＪＳＤサーバーをブートアップするためのデータのインポート元となるＬＤＡＰディレクトリ内の適切なコンテキストを、決定する。本実施形態では、ＬＤＡＰディレクトリは、すべてスタートアップさせる必要はないがＪＳＤサーバーが必要とする全てのデータを含む、“ＪＳＤ”と呼ばれるコンテキストまたは他の適切な名前のコンテキストを有する。本実施形態では、ＪＳＤユーザー・ネームスペース内の殆どのデータは、ＤＡＰサーバーから収集（populate）されている。別の実施形態では、ユーザー・データの一部は、ＪＳＤサーバー上に既に存在している。別の実施形態では、ＪＳＤサーバー・スタート・アップ・データをＬＤＡＰディレクトリ内の複数のコンテキストにわたって分散させ得る。更に別の実施形態では、ＪＳＤサーバーは殆どまたは全てのスタート・アップ・コンフィギュレーション・データを既に有し得る。
【００３７】
ステップ８０４では、ＪＳＤサーバーはＬＤＡＰディレクトリ上の“ＪＳＤ”コンテキスト内の全てのエントリを収集する。本実施形態では、ＪＳＤサーバーはこのコンテキスト内の全てのエントリを収集する。別の実施形態では、必要に応じて、１つ以上のコンテキスト内の更に多くの数のエントリまたは更に少ない数のエントリをＪＳＤサーバーは収集し得る。ステップ８０６では、ＬＤＡＰエントリ内の属性に対応したＪＳＤパスを収集する。このプロセスは図１４で詳述する。ステップ８０８では、コンフィギュレーション・データをステップ８０６で決定したＪＳＤエントリ内に格納し、プロセスはこの段階で完了する。
【００３８】
図１０は本発明の１つの実施形態に基づくＪＳＤサーバー内のユーザー固有のコンフィギュレーション・データのリーフ・ノードのフォーマットと、ＬＤＡＰディレクトリ・サーバー内の属性を有するユーザー・エントリとを示す図である。ＪＳＤサーバー内のユーザー固有のコンフィギュレーション・データは図７におけるノード６０７として最初に説明した。図１０は図７のノード６０１に示すユーザーの“Jon”に関するＪＳＤプロパティ９０２のリストを示す。例えば、リスト９０２はユーザーのログオンＩＤ（logon_ID）、アドレス（address）、電子メール・アドレス（email_address）、ユーザーＩＤ（user_ID）及び所属部門（department）を含む。リーフ・ノード６０７内の特定のユーザー・コンフィギュレーション・データ・アイテムはユーザー、ネットワーク及びアプリケーションの特定の要求仕様（needs）に基づくとともに、リスト９０２内に示すプロパティに限定されない。
【００３９】
更に、ユーザーのJonathan A. Smithのタイプ、即ち、識別ネームｕのＬＤＡＰエントリ９０４を図１０は示す。これは図２に示すエントリ２１０の改良、即ち、変更である。ここでは、属性リスト（attribute list）２１２は、ログオン（logon）９０８、メール（mail）９１０及びコンピュータ（computer）９１２の追加の“シャドー属性”を含む拡張属性リスト（enhanced attribute list）９０６として、示されている。これらのシャドー属性はＪＳＤサーバーの“イニシャル・ポピュレーション”スタート・アップ中に使用される。このプロセスは図１４で詳述する。簡単に言えば、シャドー属性によって、図９のステップ８０６及びステップ８０８で最初に説明したＪＳＤサーバー・スキーマのイニシャル・ポピュレーションを、ＬＤＡＰサーバーが迅速に実施することが可能となる。対応するプロパティをＪＳＤサーバー・スキーマ内に有するＬＤＡＰサーバー内の属性は、“シャドー”を有する。本実施形態では、シャドー属性は対応するＪＳＤプロパティの名前と、ＪＳＤプロパティを探し当てることが可能なＪＳＤパスと、ＪＳＤプロパティに関連付けられたジャバ・クラスの名前とを含む。
【００４０】
本実施形態では、シャドー属性はドット（．）で始まる。別の実施形態では、シャドー属性を示すために、他の特別なキャラクタまたはマークを使用できる。ピリオドに続いて、“ログオン（logon）”または“メール（mail）”などのシャドーになっているＬＤＡＰ属性の名前が存在する。このＬＤＡＰ属性名の次には、ＪＳＤプロパティ名が続いている。シャドー属性９０８内では、このＪＳＤプロパティ名はリスト９０２内の最初のＪＳＤプロパティである“ログオンＩＤ（logon_ID）”である。プロパティの順番またはシャドー属性の順番は重要ではなく、本実施形態では機能的な役目はない。ＪＳＤプロパティ名の後には、ＪＳＤパスが存在する。属性９０８内では、ＪＳＤパスはユーザー・ネームスペース内に存在し、かつ、ユーザー“Jon”で終わる。このＪＳＤパス名の後には、ログオンＩＤ（logon_ID）に関連するジャバ・クラス名（Java class name）が続いている。属性９１２内では、ＪＳＤプロパティはＬＤＡＰ内のコンピュータ・シリアル・ナンバー・タイプ属性に対応するクライアントＩＤ（client_ID）である。クライアントＩＤは特定のマシンに関連付けられているので、このクライアントＩＤに関するパスはマシン・ネームスペース内に存在する。
【００４１】
図１４で詳述するように、ＪＳＤサーバー・スキーマを最初にポピュレートする際、特定のコンフィギュレーション・データ・アイテムを格納するＪＳＤサーバー・スキーマ内の正確な場所を迅速に識別するために、シャドー属性を使用する。このデータ・アイテムの実際の値はエントリ内のレギュラー属性、即ち、“非シャドー”属性から獲得する。本実施形態では、シャドー・エントリはＪＳＤサーバー・スキーマに熟知したネットワーク・コンピュータ・管理者（manager）によって手動で形成される。ＪＳＤスキーマ及びジャバ・クラス名の知識を有する個人は、対応するプロパティをＪＳＤスキーマ内に有するＬＤＡＰ内の属性を識別可能である。このような個人はシャドー属性をＬＤＡＰエントリ内へ挿入可能である。本実施形態では、シャドー属性はＪＳＤサーバーからアクセス可能であり、ＪＳＤサーバーはシャドー属性を読み取り可能（permission）にしている。
【００４２】
図１１は本発明の１つの実施形態に基づくＬＤＡＰサーバーに含まれるＬＤＡＰメタ・ディレクトリ（LDAP meta directory）のフォーマットを示す図である。ＬＤＡＰメタ・ディレクトリ９１４はｃ、ｂｕ及びｕなどのＬＤＡＰタイプ、即ち、識別ネームのリストであり、その後には、関連する各属性のリストが続いている。ＪＳＤサーバーがコンフィギュレーション・データ・アイテムをＬＤＡＰサーバーから収集する必要がある際、メタ・ディレクトリが使用される。これにより、特定のタイプが特定の属性を有するか否かをＬＤＡＰサーバーが迅速に決定することが可能となる。同じＬＤＡＰコンテキスト内のデータへアクセスする必要のあるネットワーク内の他のレガシー・システムにとっても、これは効果的である。エントリへアクセスする前に、特定のタイプ内のどの属性が必要かを決定するために、これらのレガシー・システムはメタ・ディレクトリ９１４を使用し得る。値をエントリから収集する際、レガシー・システムが探し求めている属性の値のみを抽出するために、このレガシー・システムはメタ・ディレクトリから学んだ情報を使用できる。レガシー・システムはメタ・ディレクトリをＬＤＡＰエントリ上のマスクとして実質的に使用する。エントリ内へのシャドー属性の追加は、シャドー属性を有する属性の値を収集する際の、エラーの確率を減少させる。このため、シャドー属性をエントリ内へ追加すれば、このマスキング・ファンクションは特に効果的といえる。
【００４３】
図１２は本発明の１つの実施形態に基づく上位パス・マップ・コンポーネント（high-level path map component）のフォーマットを示す図である。上位パス・マップ・コンポーネント９１６は各上位ＪＳＤパスと、これに対応する識別ネームからなるＬＤＡＰ階層パスと、の間のマッピングを含む。本実施形態では、ＪＳＤサーバー・スキーマ内の上位パスはCONFIGと称されるルート・エントリから始まり、その後には、２つの一次ネームスペース、即ち、マシン・ネームスペース及びユーザー・ネームスペースのうちの一方が続き、最後には、これら２つのネームスペースの下の５つのカテゴリのうちの１つが位置する。図８のステップ７０８で最初に説明したように、ＪＳＤサーバーが自分の持っていないデータ・アイテムを要求（request）した際、ＬＤＡＰサーバー内で行われるサーチを限定するために、前記のマッピングを使用する。ＬＤＡＰサーバー内のデータ・アイテムを収集する際のその役目は、図１３で詳述する。本実施形態では、上位パス・マップはＬＤＡＰディレクトリ・サービスを管理するネットワーク・コンピュータ管理ツール内のコンポーネントであり、かつ、ＪＳＤと通信可能である（即ち、“ＪＳＤを認識している”）。従って、ＪＳＤがＬＤＡＰサーバーから特定のコンフィギュレーション・データ・アイテムを必要とする際、スタンダード・サーチング・ファンクションを使用してサーチするＬＤＡＰ階層構造の“枝”を決定するために、ＪＳＤは上位パス・マップへ最初にアクセスする。ＪＳＤスキーマ・パス（これらは全て効果的に定義されている）と、ＬＤＡＰサーバー内の上位識別ネームと、の間のマッピングは、これら２つのスキーマに熟知したネットワーク・コンピュータ管理者が実施する。
【００４４】
図１３はコンフィギュレーション・データ・アイテムがＪＳＤサーバー上に存在しない場合に、このデータ・アイテムをＬＤＡＰディレクトリ・サービスから収集する本発明の１つの実施形態に基づくプロセスを示すフローチャートである。図１３は図８のステップ７０８の詳細を示す。ステップ１００２では、ＪＳＤサーバーはＪＳＤサーバー・スキーマの上位パスと、ＬＤＡＰ階層構造と、の間の一致関係（match）を見つけるためのサーチを、図１２のテーブル９１６を使用して開始する。例えば、クライアント・コンピュータ上でのユーザー要求（request）が特定のユーザー、即ち、Jon Smithのラスト・ネームのみであるとする。しかし、ＪＳＤサーバー・スキーマはユーザーのラスト・ネームのみを提供するプロパティを有していない。パス、即ち、CONFIG/USER/users/Jon/を通って（traverse）、ラスト・ネームのみを有するプロパティに関するユーザー固有のコンフィギュレーション・データをチェックすることによって、ＪＳＤサーバー・スキーマはこれを決定する。
【００４５】
ステップ１００２では、パスの上位部分、即ち、CONFIG/USER/usersを見つけるためのサーチを図１２のパス名テーブル９１６内で実施する。bu=SunSoft; o=Sun; c=USなどの一連の識別ネームによって表される対応する上位ＬＤＡＰパス名を識別する。本実施形態では、可能性のある５つの上位ＪＳＤパス名が存在し、このうちの３つはマシン・ネームスペース内に存在し（即ち、プラットフォーム、識別子及びプロフィール）、２つはユーザー・ネームスペース内に存在する（即ち、ユーザー及びグループ）。対応するＬＤＡＰ上位パス名を識別すると、ステップ１００４では、識別した上位パスの“下”のＬＤＡＰデータベース内で、サーチが実施される。前記の例では、これはbu=SunSoftより下の全てのデータとなる。ＬＤＡＰデータベースはユーザーのJon Smithに関するラスト・ネーム属性をＬＤＡＰ内のＬＤＡＰカーソル・サーチ・メカニズムを使用してサーチする。本実施形態では、ユーザー・タイプがラスト・ネームに対応する属性を有するか否かを判定するために、図１１のメタ・ディレクトリ９１４を使用する。
【００４６】
ステップ１００６では、図１０のリスト９０６に示すように、ＬＤＡＰサーバーは“ｌｎ（ラスト・ネーム）”属性及びその値を収集し、かつ、データをＪＳＤサーバー・スキーマへ返す。ステップ１００８では、ＪＳＤサーバー・スキーマは“ｌｎ”属性に対応するプロパティを形成し、かつ、属性値を書き込む（insert）。次いで、このデータはそれを要求したクライアントへ送信され、プロセスは完了する。本実施形態では、ＪＳＤサーバー上に最初に存在せず、よって、ＬＤＡＰサーバーから収集したコンフィギュレーション・データ・アイテムは、要求への応答としてクライアントへ提供されるのみならず、ＪＳＤサーバーをアップデートするためにも使用される。
【００４７】
図１４はＬＤＡＰエントリをＪＳＤエントリへマッピングする本発明の１つの実施形態に基づくプロセスを示すフローチャートである。これは図９のステップ８０６の詳細を示す。このプロセスは図１０の属性リスト９０６で最初に説明したシャドー属性を使用する。図９は、ブートアップにおいてＪＳＤサーバーを初期化するプロセスを示していた。本実施形態では、このプロセスにおいて、ＪＳＤスキーマ内のユーザー・ネームスペース・データのかなりの部分はＬＤＡＰサーバーからのデータによって構成（populate）されている。別の実施形態では、前記の実施形態におけるマシン・ネームスペース・データの場合と同様に、ユーザー・データの一部はＪＳＤサーバー上にあらかじめ存在していることもある。マシン・ネームスペース・データの量（volume）はユーザー・ネームスペース・データの量より遙かに小さいので、その情報をＪＳＤサーバー上に維持することは実行可能であり、かつ、効果的である。一般的に、ユーザー・ネームスペース・データは１つのＬＤＡＰコンテキスト（例：“ＪＳＤ”コンテキスト）内に存在し、かつ、ＪＳＤサーバー内にインポートされる、即ち、キャッシングされる。
【００４８】
ステップ１１０２では、ＬＤＡＰサーバーは適切なＬＤＡＰコンテキスト内の各エントリを読み出す。ＬＤＡＰのデザイン及びプロトコルが軽量であるため、これを迅速に実行できる。本実施形態では、ＪＳＤサーバー・スキーマ内のユーザー・ネームスペースを構成（populate）するために必要な全てのコンフィギュレーション・データを含む１つのコンテキストが存在する。ステップ１１０４では、ＬＤＡＰサーバーはシャドー属性及び対応する“非シャドー”属性を区別、即ち、分離する。図１０の属性９０８，９１０，９１２に示すように、シャドー属性はドットなどの固有のリーディング・シンボルを有するので、これも迅速に実行可能である。ステップ１１０６では、“logon: jsmith”などの属性またはエントリの実際の値を決定するために、ＬＤＡＰサーバーは非シャドー属性を使用し、さらには、この値を格納するＪＳＤサーバー・スキーマ内の場所と、この値の格納先となるオブジェクト・タイプとに関する命令において、ＬＤＡＰサーバーは対応するシャドー属性を使用する。ステップ１１０８では、ＪＳＤサーバーはこの値をアクセプトするとともに、この値に対応するオブジェクトを形成するために、適切なオブジェクト・コンストラクタを使用し、形成されたオブジェクトをシャドー属性内に提供されているＪＳＤパスのボトムのリーフ・ノード内に格納する。ＬＤＡＰが、前記のＪＳＤロケーション生成のためにシャドー属性を使用し、前記の値の生成のために非シャドー属性を使用することによって、ＪＳＤサーバーのスタートアップ時間が長くなることが回避され得る。
【００４９】
ソフトウェア及びデータ・フォーマットまたはデータ構造に主に関連する本発明は、コンピュータ・システム内に格納されたデータを使用する様々なコンピュータ実行オペレーションによって実現される（employ）。これらのオペレーションは物理量の物理操作を必要とするオペレーションを含む（但し、同オペレーションに限定されない）。一般的に、必ずしも必要でないが、これらの量は格納、転送、結合、比較及び他の操作が可能な電気信号または磁気信号の形態をなす。本発明の一部を構成する本明細書中に開示するオペレーションは、効果的なマシン・オペレーションである。実施する操作は生成（producing)、識別（identifying）、実行（running）、決定（determining）、比較（comparing）、実行（executing）、ダウンローディング（downloading）または検出（detecting）等の用語で示されることが多い。特に、共通の用法を確立するために、これらの電気信号または磁気信号をビット、値、エレメント、変数、キャラクターまたはデータ・アイテム等として示すと都合が良い。しかし、これらの用語またはこれらに類似する用語の全ては、適切な物理量に結びつけて考えられるべきであり、かつ、これらの用語は、これらの物理量に適用された都合の良いラベルにすぎない点を覚えておく必要がある。
【００５０】
更に、本発明はＪＳＤサーバー及びＬＤＡＰサーバーなどの前記のオペレーションを実施するためのデバイス、システムまたは装置に関する。これらのシステムは要求された目的のために特別に構築し得る。また、これらのシステムは、コンピュータ内に格納されたコンピュータ・プログラム、またはライトウェイト・ディレクトリ・アクセス・プロトコル（ＬＤＡＰ）などの特定のプロトコルに基づいて動作するコンピュータ・プログラムによって選択的に作動または設定される汎用コンピュータとして構築し得る。前記の複数のプロセス及びデータ・フォーマットは特定のコンピュータまたは他のコンピューティング装置に固有のものではない。特に、本明細書の開示内容に基づいて記述されたプログラムを様々な汎用コンピュータ上で実行可能である。また、これに代えて、必要なオペレーションを実施するために、更に特化したコンピュータ・システムを形成することは更に都合が良く、このコンピュータ・システムの例としては、ＪＳＤサーバーとして動作すべく形成されたサーバー・コンピュータなどが挙げられる。
【００５１】
図１５は本発明の１つの実施形態に基づく処理の実施に適した汎用コンピュータ・システム１２００のブロック図である。図１５はＬＤＡＰディレクトリ・サーバーまたはＪＳＤサーバーなどのサーバー・コンピュータとして動作させるために設定または拡張（enhance）できる汎用コンピュータ・システムの１つの例を示す。本発明の処理を実施するために、他のコンピュータ・システム・アーキテクチャ及びコンフィギュレーションを使用し得る。以下に詳述する様々なサブシステムからなるコンピュータ・システム１２００は少なくとも１つのマイクロプロセッサ・サブシステム（中央処理装置、即ち、ＣＰＵとも称される）１２０２を含む。即ち、ＣＰＵ１０２はシングルチップ・プロセッサまたは複数のプロセッサによって実現し得る。ＣＰＵ１０２はコンピュータ・システム１２００のオペレーションを制御する汎用デジタル・プロセッサである。メモリから収集した命令を使用して、ＣＰＵ１２０２は入力データの受信及び操作と、出力デバイス上でのデータの出力及び表示とを制御する。
【００５２】
ＣＰＵ１２０２は一般的にランダム・アクセス・メモリ（ＲＡＭ）からなる第１の一次ストレージ１２０４へメモリ・バス１２０８を通じて両方向接続されている。更に、ＣＰＵ１２０２は一般的にリード・オンリ・メモリ（ＲＯＭ）からなる第２の一次ストレージ領域１２０６へメモリ・バス１２０８を通じて単方向接続されている。当該技術分野でよく知られているように、一次ストレージ１２０４は汎用ストレージ領域及び作業メモリとして使用可能であり、さらには入力データ及び処理済みデータを格納するためにも使用できる。前記の図面に示すように、一次ストレージ１２０４は、プログラミング命令及びデータを、エンハンスドＬＤＡＰ属性若しくはエントリの形態またはＪＳＤ階層の形態等で格納できる。これはＣＰＵ１２０２上で実施するプロセスのための他のデータ及び命令煮付け加えられるものであるとともに、データ及び命令をメモリ・バス１２０８を通じて両方向で高速転送するために一般的に使用される。同様に、当該技術分野でよく知れられているように、一次ストレージ１２０６は、ＣＰＵ１２０２がその機能を果たすために使用する基本オペレーティング命令、プログラム・コード、データ及びオブジェクトを一般的に含む。データ・アクセスが両方向または単方向のいずれを必要とするかなどの条件に基づいて、一次ストレージ・デバイス１２０４，１２０６は以下に詳述する任意の適切なコンピュータ読み取り可能ストレージ媒体を含み得る。ＣＰＵ１２０２は頻繁に必要となるデータをキャッシュ・メモリ１２１０内へ高速で直接収集し、かつ、格納できる。
【００５３】
取り外し可能大容量ストレージ・デバイス１２１２はコンピュータ・システム１２００のための別のデータ・ストレージ能力を提供し、かつ、周辺バス１２１４を通じてＣＰＵ１２０２へ両方向または単方向で接続されている。例えば、ＣＤ−ＲＯＭとして一般的に知られている特定の取り外し可能大容量ストレージ・デバイスはデータを単方向でＣＰＵ１２０２へ送信する。その一方、フロッピー・ディスクはデータを両方向でＣＰＵ１２０２へ送信し得る。例えば、ＪＳＤサーバー内のマシン・ネームスペース内のデータは、取り外し可能大容量ストレージ・デバイス１２１２内に格納し得る。ストレージ１２１２は磁気テープ、フラッシュ・メモリ、搬送波に組み込まれた信号、ＰＣカード、ポータブル大容量ストレージ・デバイス、ホログラフィック・ストレージ・デバイス及び他のストレージ・デバイス等のコンピュータ読み取り可能媒体を更に含み得る。固定大容量ストレージ１２１６は別のデータ・ストレージ能力を提供し、かつ、周辺バス１２１４を通じてＣＰＵ１２０２へ両方向で接続されている。大容量ストレージ１２１６の最も一般的な例は、ハード・ディスク・ドライブである。一般的に、これらの媒体へのアクセスは一次ストレージ１２０４，１２０６へのアクセスより遅い。ＣＰＵ１２０２が頻繁に使用しない他のプログラミング命令及びデータ等を大容量ストレージ１２１２，１２１６は一般的に格納する。必要に応じて、大容量ストレージ１２１２，１２１６内に保持された情報は、一次ストレージ１２０４（例：ＲＡＭ）の一部を構成する仮想記憶（virtual memory）として標準的に組込み可能である。
【００５４】
ストレージ・サブシステムへのＣＰＵ１２０２のアクセスを提供する以外に、周辺バス１２１４は他のサブシステム及びデバイスへのアクセスを提供するために使用される。本実施形態では、これらは、ディスプレイ・モニタ１２１８及びアダプタ１２２０、プリンタ・デバイス１２２２、ネットワーク・インターフェース１２２４、補助入出力装置インターフェース１２２６、サウンド・カード１２２８及びスピーカー１２３０、並びに必要とされる他のサブシステムを含む。
【００５５】
図示するように、ネットワーク接続を使用することにより、ネットワーク・インターフェース１２２４はＣＰＵ１２０２を別のコンピュータ、コンピュータ・ネットワークまたはテレコミュニケーション・ネットワークへ接続可能にする。前記の方法のステップを実行するうえで、ＣＰＵ１２０２はコンフィギュレーション・データ、コンフィギュレーション・データに関する要求（request）、またはプログラム命令などの情報を別のネットワークからネットワーク・インターフェース１２２４を通じて受信するか、または情報をネットワーク・インターフェース１２２４を通じて別のネットワークへ送信し得る。ＣＰＵで実行する複数の命令のシーケンスに代表される情報は、搬送波に組み込まれたコンピュータ・データ信号などの形態で別のネットワークに対して送受信可能である。インターフェース・カードまたはこれに類似するデバイスと、ＣＰＵ１２０２によって実行される適切なソフトウェアとは、コンピュータ・システム１２００を外部ネットワークへ接続し、かつ、データを標準プロトコルに基づいて転送するために使用できる。即ち、本発明の方法はＣＰＵ１２０２上で単独で実行し得る。これに代えて、処理の一部を共有する遠隔ＣＰＵと協動することにより、本発明の方法をインターネット、イントラネットワークまたはローカル・エリア・ネットワーク（例えば、エンタープライズ・ワイド・ネットワーク内）等のネットワークを通じて実行し得る。別の大容量ストレージ・デバイス（図示略）をネットワーク・インターフェース１２２４を通じてＣＰＵ１２０２へ接続し得る。
【００５６】
補助入出力装置インターフェース１２２６は、マイクロホン、タッチ・ディスプレイ、トランスデューサ・カード・リーダー、テープ・リーダー、音声認識装置、手書き文字認識装置、バイオメトリクス・リーダー、カメラ、ポータブル大容量ストレージ・デバイス及び他のコンピュータ等の装置に対するＣＰＵ１２０２によるデータの送受信を可能にする汎用インターフェース及びカスタム・インターフェースを、表す。
【００５７】
キーボード１２３６またはポインタ・デバイス１２３８からの入力を受信し、さらにはデコードしたシンボルをキーボード１２３６またはポインタ・デバイス１２３８からＣＰＵ１２０２へ送信するために、キーボード・コントローラ１２３２がローカル・バス１２３４を通じてＣＰＵ１２０２へ接続されている。ポインタ・デバイスはマウス、スタイラス、トラック・ボールまたはタブレットであり得る。そして、ポインタ・デバイスはグラフィカル・ユーザー・インターフェースとの相互作用に効果的である。
【００５８】
更に、本発明の実施形態は様々なコンピュータ実行オペレーションを実施するためのプログラム・コードを含むコンピュータ読み取り可能媒体を有するコンピュータ・ストレージ・プロダクト（computer storage products）に関する。コンピュータ読み取り可能媒体は、コンピュータ・システムによる後からの読み取りが可能なデータを格納し得る任意のデータ・ストレージ・デバイスである。媒体及びプログラム・コードは、ＬＤＡＰサーバーからのコンフィギュレーション・データの収集などの本発明の目的のために特別に設計され、かつ、形成されたものであるか、またはコンピュータ・ソフトウェアの分野における当業者に周知のものであり得る。コンピュータ読み取り可能媒体の例としては、ハード・ディスク、フロッピー・ディスク及び磁気テープなどの磁気媒体と、ＣＤ−ＲＯＭディスクなどの光媒体と、光フロッピー・ディスクなどの磁気光媒体と、特定用途向け集積回路（ＡＳＩＣ）、プログラム可能論理回路（ＰＬＤ）、ＲＯＭデバイス及びＲＡＭデバイスなどの特別に構成されたハードウェア・デバイスとを含めた前記の全ての媒体が挙げられる（但し、これらに限定されない）。コンピュータ読み取り可能媒体は搬送波に組み込まれたデータ信号として結合コンピュータ・システムのネットワーク上に分散させ得る。従って、コンピュータ読み取り可能コードは分散した形態で格納及び実行できる。プログラム・コードの例としては、コンパイラ等によって形成されたマシン・コード、またはインタプリタを使用して実行し得る更に高いレベルのコードを含むファイルが挙げられる。
【００５９】
前記のハードウェア・エレメント及びソフトウェア・エレメントが標準的なデザイン及び構成を有することを当業者は理解し得る。本発明に適した他のコンピュータ・システムは更に多くの数のサブシステムまたは更に少ない数のサブシステムを含み得る。更に、メモリ・バス１２０８、周辺バス１２１４及びローカル・バス１２３４は複数のサブシステムをリンクするために使用する任意の相互接続方式の実例である。例えば、ローカル・バスはＣＰＵを固定大容量ストレージ１２１６及びディスプレイ・アダプタ１２２０へ接続するために使用可能である。図１５に示すコンピュータ・システムは本発明に適したコンピュータ・システムの例である。サーバー・コンピュータのコンフィギュレーションのように、サブシステムの別のコンフィギュレーションを有する他のコンピュータ・アーキテクチャを使用し得る。
【００６０】
以上、理解を容易にする目的で、本発明をある程度詳しく説明したが、特定の変更及び修正を本発明の請求の範囲内で実施しても良い。更に、本発明のプロセス及び装置の両方をインプリメントする別の方法が存在することに注意する必要がある。例えば、本発明をコンフィギュレーション・データを使用して説明したが、他のタイプの非コンフィギュレーション・データをジャバ・システム・データベース内に格納し、ネットワーク内のＬＤＡＰディレクトリ・サービスからこの非コンフィギュレーション・データへアクセス可能である。この場合、ＬＤＡＰデータベースは非コンフィギュレーション・タイプのデータを格納する。別の例では、一部のユーザー・ネームスペース・コンフィギュレーション・データはＪＳＤサーバー上に永続的に存在し得る。これによって、ＪＳＤサーバーのスタートアップ後、このデータをＬＤＡＰサーバーからインポートする、即ち、キャッシングする必要がなくなる。更に別の例では、コンフィギュレーション・データを格納するために、前記のＪＳＤサーバー・スキーマ以外のコンフィギュレーション・リポジトリを使用し得る。シャドー属性及び上位パス・マッピングの概念を、別の種類のコンフィギュレーション・リポジトリと一緒に使用できる。従って、本明細書に開示した複数の実施形態は例示を目的とするものであって、限定を目的としない。更に、本発明は本明細書に開示する詳細部分に限定されることなく、請求の範囲及びそれに等価なものの範囲内で変更できる。
【図面の簡単な説明】
【図１】クライアントがＬＤＡＰディレクトリ・サービス内のデータへアクセスする方法を示すブロック図である。
【図２】ＬＤＡＰディレクトリ・ツリーの階層ブロック図である。
【図３】ＬＤＡＰディレクトリ・サービス内における図２の階層構造を表すネーム・スキーマ及び関連する属性を示す図である。
【図４】本発明の１つの実施形態に基づくシステム・ワイド・データ・スキーマを有するコンピュータ・ネットワークのコンポーネントを示す概略図である。
【図５】本発明の１つの実施形態に基づくＪＳＤサーバー・スキーマの構造を示すブロック図である。
【図６】本発明の１つの実施形態に基づくサーバー・スキーマ内のマシン・ネームスペースの階層構造を示す概略図である。
【図７】本発明の１つの実施形態に基づくユーザー・ネームスペースを示す概略図である。
【図８】本発明の１つの実施形態に基づくジャバ・システム・データベース環境内のＬＤＡＰディレクトリ内のデータへアクセスするプロセスを示すフローチャートである。
【図９】本発明の１つの実施形態に基づくＪＳＤサーバーをＬＤＡＰディレクトリ・サービスを用いて初期化するプロセスを示すフローチャートである。
【図１０】本発明の１つの実施形態に基づくＪＳＤサーバー内のユーザー固有のコンフィギュレーション・データ・リーフ・ノードのフォーマットと、属性をＬＤＡＰディレクトリ・サーバー内に有するユーザー・エントリとを示す図である。
【図１１】本発明の１つの実施形態に基づくＬＤＡＰサーバーに含まれるＬＤＡＰメタ・ディレクトリのフォーマットを示す図である。
【図１２】本発明の１つの実施形態に基づく上位パス・マップ・コンポーネントのフォーマットを示す図である。
【図１３】コンフィギュレーション・データ・アイテムがＪＳＤサーバー上に存在しない場合に、このデータ・アイテムをＬＤＡＰディレクトリ・サービスから収集する、本発明の１つの実施形態に基づくプロセスを示すフローチャートである。
【図１４】ＬＤＡＰエントリをＪＳＤエントリへマッピングする本発明の１つの実施形態に基づくプロセスを示すフローチャートである。
【図１５】本発明の実施形態の実現に適した一般的なコンピュータ・システムのブロック図である。
【発明の背景】
一般的に、本発明はコンピュータ・ソフトウェア及びコンピュータ・ネットワーク・アプリケーションに関する。より詳細には、本発明はクライアント・サーバー・アプリケーションに関し、さらには、コンピュータ・ネットワーク内の複数のコンポーネント間またはストレージ領域間におけるコンフィギュレーション・データの転送及び配置に関する。
【０００２】
従来のコンピュータ・ネットワークは、一般的にクライアントと称される一連のパーソナル・コンピュータを１つ以上のサーバー・コンピュータへ接続することを伴う。一般的に、クライアント・コンピュータは自立しており、ユーザー・アプリケーションを実行し、かつ、ネットワークと通信するために必要な情報の殆どを自身の常駐メモリ内に格納している。この情報はソフトウェア及びハードウェアの機能及び用件に関するクライアント・コンピュータのコンフィギュレーション情報を含む。一般的に、ネットワーク・ソフトウェア・アプリケーションへのアクセス、電子メールの送受信、ネットワーク・データベース上の情報の収集及び格納、またはインターネットへのアクセスなどの様々な理由から、クライアント・コンピュータはネットワーク・サーバーへアクセスする。しかし、一般的に、特定のクライアント・コンピュータに固有の情報は、そのクライアント・コンピュータ上に存在する。例えば、この情報はメモリ仕様、バス・タイプ、追加プロセッサ及び他のハードウェア仕様を含み得る。クライアント・コンピュータは比較的自立しており、自己のコンフィギュレーション情報を自身で格納している（これはこの種のデータをサーバー上に格納するのとは全く異なる）。このため、エンド・ユーザー・アプリケーション・データ以外に、コンフィギュレーション及びユーザーに関するデータをクライアント・コンピュータ上で管理するタスクは大きな負担になってきている。
【０００３】
ネットワーク・サーバー上に存在するアプリケーションの小規模なアップグレードまたは修正をクライアント・コンピュータへ伝達することは可能である。しかし、全てのクライアントに影響を及ぼす大規模なアップグレード、大規模な修正、または新たなアプリケーションのインストールでは、ネットワーク管理者がクライアント・コンピュータへ個々にアクセスし、かつ、アップデートすることを必要とする。ネットワークに接続されているコンピュータの数量の増加（幾つかの企業では、この数は何万台にも達している）によって、アプリケーション・ソフトウェアまたは汎用コンフィギュレーション・ソフトウェアに対する大規模なリビジョンまたはアップグレードのインストールの負担は、費用が嵩み、非効率的であり、かつ、多くの時間を必要とするものとなっている。更に、殆どのクライアント・コンピュータが自立しているので、アプリケーション及びコンフィギュレーション・データに関する個人設定（personal preferences）を維持することは、複数の異なる場所（location）にそれぞれ位置する複数の異なるクライアント・コンピュータを使用しているユーザーにとって困難である。即ち、ユーザーは個人設定を自分が通常使用するクライアント・コンピュータへデフォルトとしてインストールできる。しかし、他のクライアント・コンピュータのデフォルトを変更せずに、自分が通常使用するクライアント・コンピュータのデフォルトを他のクライアント・コンピュータへ複製することは厄介である。
【０００４】
前記のように、従来のネットワーク・コンフィギュレーションでは、新たなソフトウェアまたは新たなアプリケーションをインストールするプロセスは、静的プロセスである。そして、このコンフィギュレーションでは、各クライアントに関するコンフィギュレーション情報は各クライアント・マシン上で定義されている。従って、ネットワーク管理者は各クライアント上のコンフィギュレーションを静的に決定（define）する。従来のコンピュータ・ネットワークでは、特定の各サブシステム、即ち、クライアントに関するコンフィギュレーション情報は、このクライアント内にハードコード化されている。更に、ネットワーク・サーバーへ接続された自立しているクライアントを使用する従来のネットワーク・コンフィギュレーションでは、サブシステムのコンフィギュレーションへのアクセスを要する、ソフトウェアに対する大規模なアップグレードのインストールなどといったアプリケーション・メインテナンスは、通常、そのメインテナンスを実施するためのネットワークの“ダウン”を必要とする。
【０００５】
複数のクライアントと、クライアントが様々な理由で必要とする情報を有するサーバーとを含む従来のコンピュータ・ネットワークでは、多くの場合、クライアントが必要とするデータまたはクライアントに関連するサーバー上の全てのデータは、サーバーからクライアントへ移される。一般的に、これは大量のデータの移動を伴う。そして、これらのデータのうちの殆どは、クライアントを動作させるために使用されないものであり、または不必要なものである。全てのデータをクライアントへ移動させることは非効率的であり、かつ、ネットワーク・トラフィックを増大させる。更に、サーバーから送信されたクライアントに関する全ての情報を格納するために、このクライアントは十分なメモリ及びストレージを有する必要がある。例えば、大きなストレージ容量を持たないＰＤＡ及びスマート・カードなどのデバイスは、そのデバイスに関連するコンフィギュレーション情報を含む全ての必要な情報を常駐メモリに格納できない。
【０００６】
多くの従来のエンタープライズ・ワイド・ネットワークの別のコンポーネントとしては、ディレクトリ・サービス及びネーミング・サービスが挙げられる。これらのサービスはネットワーク・ユーザー及びハードウェア・コンポーネントに関するコンフィギュレーション及びマッピングの情報を格納するために使用される。ネットワーク・サービスを要する特定のファンクションを実行するために、ネットワーク内のユーザー及びコンポーネントはこの情報を必要とする。広く使用されている幾つかのディレクトリ・サービスとしては、ウィンドウズＮＴ（商標名）環境内で使用されているＤＮＳ（ディレクトリ・ネーム・サービス）及びＡＤ（アクティブ・ディレクトリ）と、ユニックス環境内でのＮＩＳとが挙げられる。より最近の技術を使用する更に新しく、かつ、パワフルなディレクトリ・サービスとしては、ディレクトリ・サービスのためにエンタープライズ・ネットワーク内で更に広く使用されているライトウェイト・ディレクトリ・アクセス・プロトコル（Lightweight Directory Access Protocol）、即ち、ＬＤＡＰが挙げられる。図１はクライアントがＬＤＡＰディレクトリ・サービス内のデータへアクセスする方法を示すブロック図である。エンタープライズ環境１０４内のクライアント・コンピュータ１０２はＬＤＡＰアクセス・モジュール、即ち、アドオン１０６を有する。クライアント１０２がＬＤＡＰディレクトリ１０８へアクセスする必要がある際、クライアント１０２は線１１０で示すようにモジュール１０６を使用して直接アクセスする。実質的に、ＬＤＡＰディレクトリ１０８は、データベース及びソフトウェア・デーモン（図示略）を有するソフトウェア・サーバーである。コンフィギュレーション及び関連するデータを全て含むデータベース・セグメントの機能は、２つの列を有するテーブル１１２として説明できる。このうちの１つの列は属性を有し、第２列は１つ以上の実際の値を有する。属性はユーザー名（user name）、ログオン名（logon name）、部門識別子（department identifier）またはハードウェア識別子（hardware identifier）を表すものなどの任意のデータ・カテゴリの属性であり得る。ディレクトリ・サービスの１つの効果としては、ネットワーク管理者が、ネットワーク内のユーザーまたはコンポーネントがアクセスする必要のある任意の種類のデータを格納することができるという、柔軟性が挙げられる。１つ以上の値を属性に関連付け得る。例えば、ユーザー固有の設定を表す属性は、自身に関連する幾つかの値を有し得る。そして、これらの値はある種のデリミタで区切られ、かつ、同じ値エントリ内に存在する。ＬＤＡＰディレクトリ１０８の構造及び編成は、コンピュータ・ネットワーク・アドミニストレーションの分野では周知である。
【０００７】
レガシー・システムと称されるこれらの既存のディレクトリ・サービス内に格納された情報は、エンタープライズ・ネットワーク内のクライアント・コンピュータからのアクセスを可能にする必要がある。従って、拡大するネットワーク内におけるアプリケーション及びコンフィギュレーション・データの管理に関する前記の問題点を解決する任意のタイプのコンフィギュレーション・リポジトリ（repository）は、ＬＤＡＰディレクトリ・サービスなどのレガシー・システム上のコンフィギュレーション・データを格納するか、または該コンフィギュレーション・データへのアクセスを有することが必要である。コンフィギュレーション及びユーザー固有のデータを効果的な方法でクライアント・コンピュータへ提供できるコンフィギュレーション・サーバーは、コンフィギュレーション・データを有する既存のディレクトリ・サービスとの間におけるデータの交換を可能にする必要がある。
【０００８】
従って、クライアント・コンフィギュレーション及びユーザー・コンフィギュレーションをセントラル・リポジトリに格納することによって、これらの情報の分散管理をサポートするシステムが望まれる。ネットワーク管理者がサブシステムのコンフィギュレーションをサーバーから管理し、かつ、アプリケーションに対するあらゆる種類の変更をサーバーから伝達することを、これは可能にする。更に、セントラル・リポジトリがレガシー・システム内のコンフィギュレーション・データへのアクセスを最小限のオーバーヘッド処理で迅速に行うとともに、このアクセスをクライアント・コンピュータにとって透過な（transparent）状態で実施することが望ましい。
【０００９】
【発明の概要】
本発明に基づき、データをコンフィギュレーション・サーバー・スキーマと、ネットワーク・ディレクトリ・サービスと、の間で伝達するための方法、データ構造（data structures）及びコンピュータ読取り可能媒体を開示する。本発明の１つの態様では、ディレクトリ・サービス属性と、コンフィギュレーション・サーバー・プロパティと、の間のマッピングを可能にするディレクトリ・サービスに対するエクステンション（extension。データベース・サーバ・スキーマ。）を開示する。ディレクトリ・サービスのエントリは、特定のディレクトリ・サービス属性にそれぞれ対応する複数のシャドー属性を含む。そして、前記の特定のディレクトリ・サービス属性は、対応するプロパティをコンフィギュレーション・サーバー内に有する。更に、エクステンションは、対応情報ファイル、即ち、パス・マッチング・ファイルを有する。それらのファイルは、ディレクトリ・サービス・アドレスと、コンフィギュレーション・サーバー・ロケーション識別子、即ち、パスと、の間の一致情報を含む。
【００１０】
１つの実施形態では、エクステンションは、ディレクトリ・サービス内のタイプのリストと、各ディレクトリ・タイプで使用できる属性を含む属性リストとを有するディレクトリ・サービス・メタ・ディレクトリを、有する。別の実施形態では、各シャドー属性は、対応するコンフィギュレーション・サーバー・プロパティと、コンフィギュレーション・サーバー・ロケーション識別子、即ち、パスと、を有する。更に別の実施形態では、各シャドー属性は、対応するコンフィギュレーション・サーバー・プロパティに関連付けられたクラス名を有する。更に別の実施形態では、コンフィギュレーション・サーバーは、複数のクライアント及び複数のネットワーク・ユーザーに関するコンフィギュレーション・データを有するジャバ・システム・データベース・サーバーである。更に、ロケーション識別子は一連のノードであり、各ノードは情報のカテゴリを示す。更に別の実施形態では、ディレクトリ・サービスはライトウェイト・ディレクトリ・アクセス・プロトコルである。
【００１１】
本発明の別の態様において、コンフィギュレーション・データベースと通信可能なネットワーク・ディレクトリ・サービス内のシャドー属性のためのフォーマットを開示する。シャドー属性は、コンフィギュレーション・データベース内で使用するプロパティ名を格納するコンフィギュレーション・データベース・プロパティを保持するためのフィールドを、有する。シャドー属性は更に、コンフィギュレーション・データベースを検索していく（traverse）ために使用可能なコンフィギュレーション・データベース・パスのためのフィールドを、有する。シャドー属性をシャドー属性として識別するために、シャドー属性に関連付けられたマーカーが、更に含まれている。
【００１２】
１つの実施形態では、シャドー属性フォーマットは、コンフィギュレーション・データベース内へ格納した値に関連付けられたクラス名を格納するための、コンフィギュレーション・データベース・クラス名フィールドを有する。別の実施形態では、ロケーション識別子は階層構造内の一連のノードである。更に別の実施形態では、ディレクトリ・サービスはライトウェイト・ディレクトリ・アクセス・プロトコルであり、コンフィギュレーション・データベースはジャバ・システム・データベースである。
【００１３】
本発明の更に別の態様では、コンフィギュレーション・データをネットワーク・ディレクトリ・サービスからコンフィギュレーション・データベースへ送信する方法を開示する。１つ以上のレギュラー・ディレクトリ・サービス・エントリ及びそれに対応する値を、ネットワーク・ディレクトリ・サービスから収集し、かつ、コンフィギュレーション・データベースへ送信する。ネットワーク・ディレクトリ・サービス内に位置するディレクトリ・サービス内のシャドー・エントリに対するクエリーによって、コンフィギュレーション・データベース内における前記の各対応する値のロケーション及びプロパティ名を決定する。ディレクトリ・サービス内のシャドー・エントリから決定したロケーション、即ち、パスに基づいて、前記の対応する値をコンフィギュレーション・データベース内へ格納する。
【００１４】
１つの実施形態では、前記の１つ以上のディレクトリ・サービス・エントリ及び対応する値を収集する先のネットワーク・ディレクトリ・サービス内のコンテキストを決定する。別の実施形態では、各レギュラー・ディレクトリ・サービス・エントリを各シャドー・ディレクトリ・サービス・エントリと区別する。別の実施形態では、シャドー・ディレクトリ・サービス・エントリは、コンフィギュレーション・データベース上のパスと、コンフィギュレーション・データベースに関連付けられたプロパティ名とを含む。
【００１５】
本発明の更に別の態様において、データをＬＤＡＰサーバーから収集し、かつ、ジャバ・ベースのコンフィギュレーション・サーバーへ送信する方法を開示する。ジャバ・ベースのコンフィギュレーション・サーバー内の上位パスと、特定のＬＤＡＰアドレスと、の間の一致関係（match）を見つけるために、ロケーション一致情報ファイル（location matching file）をサーチする。
サーチすべきＬＤＡＰサーバーの一部を決定するために、前記の特定のＬＤＡＰアドレスを使用しつつ、１つ以上の属性を見つけるために、ＬＤＡＰサーバーの一部をサーチする。前記の１つ以上の属性に対応する１つ以上の値を収集する。前記の値をジャバ・ベースのコンフィギュレーション・サーバーへ送信し、これによって、前記の値をジャバ・オペレーティング・システム環境内のクライアント・コンピュータで使用可能にする。
【００１６】
【詳細な開示】
本発明の特定の実施形態を以下に詳述する。更に、この特定の実施形態の例を添付図面に示す。本発明を特定の実施形態に関連して詳述するが、これは本発明を１つの特定の実施形態に限定することを意図するものではない。逆に、請求の範囲に定義する本発明の精神及び範囲に属する別例、変更例及び等価なものを網羅することを意図する。
【００１７】
ＬＤＡＰディレクトリ・サービス内の属性またはエントリをコンフィギュレーション・サーバー・スキーマへマッピングするための方法及びシステムを複数の図面に示す。本実施形態では、コンフィギュレーション・サーバーはジャバ・システム・データベース（Java System Database、略して“ＪＳＤ”と称する）と呼ばれるソフトウェア・コンポーネントを有する。本発明のＪＳＤは、１９９８年５月１４日に出願された“コンフィギュレーション情報をサーバー・コンピュータ上に格納するためのジェネリック・スキーマ（A Generic Schema for Storing Configuration Information on a Server Computer）”と称される継続中の米国特許出願第０９／０７９，５００号と、１９９８年５月１４日に出願された“ジャバ・システム・データベース”と称される米国仮特許出願第６０／０８５，４２５号とに更に詳細に開示されており、これら２つの米国特許出願の内容はこの開示をもって本明細書中に開示したものとする。以下に詳述するように、ＪＳＤサーバー・スキーマは１つ以上のプロパティ及び対応するデータ値を含む効果的に定義されたノード及び“リーフ”ノードを有するツリー構造である。従って、ＪＳＤサーバー・スキーマ内の特定の各データ・アイテムの場所（location）は、スラッシュで区切られた一連のノード名として伝達できる。図１０に示すように、本発明におけるＪＳＤサーバー内の各プロパティのパスを定義する能力は、ＬＤＡＰディレクトリ・サービスのエントリまたは属性をＪＳＤサーバー・プロパティへ“マッピング”することを可能にする。
【００１８】
ＴＣＰ／ＩＰ上で実行するオープン・スタンダード・プロトコルであるライトウェイト・ディレクトリ・アクセス・プロトコル（ＬＤＡＰ）を使用するネットワーク・ディレクトリ・サービスの構造及び使用方法は、当該技術分野では周知であるが、本発明のマッピングの特徴（feature）に特に関連したＬＤＡＰの幾つかの特定の特徴（feature）を説明することは効果的である。一般的に、ネットワークＬＤＡＰディレクトリ・サービスはネットワークのコンフィギュレーション・データを格納している。そして、このデータは従来のデータベース内に格納されているデータより更に記述的であり、かつ、属性に基づいている。一般的に、このデータは書き込まれる頻度よりも読み出される頻度のほうが高い。大量の照合オペレーション（high-volume lookup operation）、即ち、サーチ・オペレーションに対する素早いレスポンスを提供すべくディレクトリは調整されている。コンフィギュレーション・データは、クライアント・コンピュータなどのシステムを設定するために使用するデータとして、広く記述されている。そして、ユーザーがネットワーク内のどのクライアント・コンピュータへログオンしているかには無関係に、ユーザー環境をセットアップするための、ユーザー・プロフィールに関連するデータである。更に、ＪＳＤサーバー・スキーマはコンフィギュレーション・データを格納するが、ＬＤＡＰサーバーのスケーラビリティを有していない。従って、大量のデータをＬＤＡＰサーバー上に格納し、これらのデータをネットワーク上の全てのユーザーが使用できるようにすることは、これらの全データをＪＳＤサーバー上に格納することより更に効果的である。
【００１９】
ＬＤＡＰサーバーの１つの特徴（feature）としては、属性またはキーと称されるデータ・アイテムの場所（location）を定義するために使用する、絶対ネーム及び相対ネームのコンベンション（convention）が挙げられる。このうちの特に関連するものとしては、ＬＤＡＰディレクトリ内の属性を探し当てるために使用する絶対ネームが挙げられる。絶対ネームはＪＤＳサーバー内のノードに類似する一連の“識別ネーム（distinguished names）”を含む。一般的に、ＬＤＡＰモデルはエントリに基づいている。エントリは属性の集合（collection）である。このようなエントリは識別ネーム（distinguished name、略して、“ＤＮ”）と称される。属性は１つ以上の値を有することが可能であり、かつ、特定のタイプに属し得る。一般的に、タイプはユーザー名を示すｕｎ若しくはｕ、電子メール・アドレスを示すｍｌ、または組織を示すｏなどの記憶用文字列、ニーモニック・ストリング（mnemonic string）である。各タイプは属性のコレクションを有する。例えば、ｕｎは一般名（common name）、ラスト・ネーム（last name）及びログオン名（logon name）などの属性を有し得る。識別ネームｏは属性であるメール（mail）及びファックス（fax）を有することが可能であり、メール及びファックスの後には、１つ以上の値がそれぞれ続いている。
【００２０】
ＬＤＡＰ内のエントリは、組織の境界を一般的に表す階層ツリーに似た構造（structure）内に配置されている。例えば、国を表すエントリは、ツリーのトップの識別ネームｃの下に見られることが多い。そして、この国を表すエントリの次には、ビジネス・ユニット（ｂｕ）を表すエントリが続き、その次には、例えば、プリンタ、クライアント・コンピュータまたはネットワーク・ユーザーのうちの任意の１つを表す更に具体的なエントリが続いている。図２はＬＤＡＰディレクトリ・ツリーの階層ブロック図である。ＬＤＡＰオープン・スタンダードの更なる詳細と、このスタンダードのデータ編成と、識別ネームの使用法とは１９９５年３月に発行されたWengyik Yeong、Tim Howes及びSteve Killeによる“ライトウェイト・ディレクトリ・アクセス・プロトコル（The Lightweight Directory Access Protocol）”と称されるリクエスト・フォー・コメンツ（Request for Comments、略して、“ＲＦＣ”）のナンバー１７７７と、１９９５年３月に発行されたSteve Killeによる“識別ネームのストリング表現（A String Representation of Distinguished Names）”と称されるＲＦＣ１７７９とに開示されており、これら２つの文献の内容は、この開示をもって本明細書に開示したものとする。
【００２１】
図２に示すディレクトリ・ツリー２００は、ニーモニックｃで表される国のトップレベル識別ネームに対応する３つのノードを有する。ノード２０２は米国を表す。ニーモニックｃはタイプとも称される。ノード２０２は、そこから分岐した２つのノード２０４，２０６を有し、これら２つのノード２０４，２０６は組織を示す識別ネームoに属する。ノード２０４は組織としてのネットスケープ（Netscape）を示す。タイプｏを有するネットスケープは、この例で示す２つの属性、即ち、“メール（mail）”及び“ファックス（fax）”を有しており、対応する値がこれらの後に続いている。ノード２０６は別の組織、即ち、サン（Sun）を示しており、２つのノードがそこから分岐している。ノード２０６はノード２０４に類似する属性のリスト（全てタイプｏ）を有し得るが、図示は省略してある。次のレベルの識別ネームはビジネス・ユニット・タイプを示すｂｕである。サン・ノード２０６の下には、２つのノードが存在し、これらは２つともタイプｂｕである。ノード２０８は“サン・ソフト（SunSoft）”ビジネス・ユニットを示す。更に、サン・ソフトは属性の集合（collection）（全てタイプｂｕであり、図２における図示略）を有する。ノード２０８の下には、識別ネームｕで表されるユーザー、即ち、Jonathan A. Smithのノード２１０が存在する。サン・ソフト・ビジネス・ユニットは、該ビジネス・ユニット内の全てのネットワーク・ユーザーを表すノード２１０に類似した多数のノードを有し得る。ｕタイプは属性のリスト２１２を有する。各属性の後には、１つ以上の値が続いている。ＬＤＡＰの多くのインプリメンテーションでは、これらの値はストリング・フォームまたはバイナリ・フォームであることを要する。図２に示す例では、ｕの識別ネームの下には、別の識別ネームは存在しない。ＬＤＡＰで実現（implement）されるディレクトリ・サービスの１つの効果としては、ハードウェア・コンポーネントに関係するデータ、ユーザー設定及びスタートアップ・データなどの全ての種類の情報を格納する柔軟性が挙げられる。
【００２２】
一般的に、ＬＤＡＰディレクトリは複数のコンテキストを有する。新たなコンテキストを形成した際、そのコンテキストに関する図３に示す１つの絶対ネーム、即ち、識別ネームの階層を定義する。コンテキストは、特定のファンクションをアドレスするために定義される。コンテキストの幾つかの例としては、“クライアント・ブートアップ（client boot-up）”、“ユーザー固有のプリファレンス（user-specific preferences）”、“ファイナンシャル・リポート（financial reports）”または“エンジニアリング・デパートメント・データ（engineering department data）”が挙げられる。コンテキストは、ＬＤＡＰディレクトリのデータベース部分を構成する上位セグメントと見なし得る。例えば、ＬＤＡＰディレクトリ内のデータへのクライアントによるアクセスの制限は、コンテキスト・レベルでセットされる。
【００２３】
各コンテキストは、そのコンテキストが形成された際に定義された１つの絶対ネーム・スキーマ（一般的に、これはネットワーク管理者が定義する）を有する。ＬＤＡＰ内の絶対ネーム・スキーマまたは絶対ネーム・コンベンションは識別ネームのリストである。図３はＬＤＡＰディレクトリ・サービス内における図２の階層構造を表すネーム・スキーマ及びそれに関連する属性を示す図である。ネーミング・コンフィギュレーション、即ち、階層はネーム・スキーマの右側に位置する識別ネーム“c=US”２１４から始まる。識別ネームｃは、異なる国をそれぞれ表す多数の値のうちの任意の１つを有し得る。次の識別ネームo=Sun２１６は階層内の次の下側のレベルを表す。この例では、識別ネームoは“組織”を表し、かつ、他の組織または企業を示すストリング値を有し得る。その左側の識別ネームは更に具体的であり、ｂｕはビジネス・ユニット２１８を表し、ｕはユーザー２２０を表す。各識別ネーム、即ち、タイプは一連の属性を有する。例えば、識別ネームu=Jonathan A. Smith２２０は図２で最初に説明した一連の特定の属性２１２を有する。識別ネームの全体ストリング２２２は絶対アドレスと呼ばれたり、時には、完全識別ネームと呼ばれたりする。
【００２４】
前記のように、ネットワーク内のクライアント・コンピュータ、ユーザー及び他のコンポーネントのコンフィギュレーション・データの一部は、ＪＳＤサーバー・スキーマ内に格納される。これはクライアントに関するコンフィギュレーション・データをクライアント・マシン上でハードコード化する、即ち、格納する従来のネットワークとは対照的である。ネットワーク管理者がエンタープライズ・ネットワーク内の各コンピュータに関するコンフィギュレーション情報をセントラル・リポジトリ（repository）から管理することを、ＪＳＤサーバー・スキーマは可能にする。従って、サブシステム（例：クライアント・コンピュータ）のコンフィギュレーションに関する知識と、同コンフィギュレーションへのアクセスとを必要とする任意のソフトウェア・アップデート、バージョン・アップグレードまたは新たなアプリケーションのインストールをセントラル・リポジトリから実行（implement）し、かつ、各サブシステムへ伝達できる。例えば、アプリケーションの新たなアップグレードまたはバージョンをインストールまたは伝達するために、クライアント・コンピュータ上のユーザーはアプリケーションを終了させる必要がないうえ、ネットワークをメインテナンスのためにダウンさせる必要がない。
【００２５】
図４は本発明の１つの実施形態に基づくシステム・ワイド・データ・スキーマを有するコンピュータ・ネットワークのコンポーネントを示す概略図である。本実施形態では、システム・ワイド・データ・スキーマはネットワーク３０７の一部としてクライアント・マシン３０５上に存在するクライアント・スキーマ３０３からなるジャバ・システム・データベース、即ち、ＪＳＤ３０１として実現（implement）されている。ＪＳＤサーバー・スキーマ３１１はネットワーク３０７の一部をなすサーバー・コンピュータ３０９上に存在する。前記のように、ＬＤＡＰディレクトリ・サービスと通信するのは、サーバー３０９（“ＪＳＤサーバー”）上のＪＳＤサーバー・スキーマ３１１である。従って、ＪＳＤサーバー・スキーマ３１１を以下に詳述する。
【００２６】
図５は本発明の１つの実施形態に基づくＪＳＤサーバー・スキーマの構造を示すブロック図である。これは図４のサーバー・コンピュータ３０９及びサーバー・スキーマ３１１の更なる詳細を示す。本実施形態では、ｎ分岐ツリーのトップには、“CONFIG”と呼ばれるルート・エントリ・ノード４０１が存在する。２つのネームスペースがサーバー・スキーマ内に存在する。領域４０３はマシン・ノード３０５を有するマシン・ネームスペース（MACHINE namespace）を表す。領域４０７はユーザー・ノード４０９を有するユーザー・ネームスペース（USER namespace）を表す。
【００２７】
本実施形態では、マシン・ネームスペース４０３は３つのカテゴリ、即ち、プラットフォーム（platform）４１１、識別子（identifier）４１３及びプロフィール（profile）４１５を有する。プラットフォーム３１１の下には、例えば、特定のコンピュータ製造業者を示す多数のエントリが存在する。別の実施形態では、マシン・ネームスペース４０３はネットワークのプラットフォーム及び要件に基づいて更に多くの数のサブ・カテゴリまたは更に少ない数のサブ・カテゴリを有し得る。この詳細を図６に示す。
【００２８】
図６はサーバー・スキーマ３１１内のマシン・ネームスペース４０３の階層構造を示す概略図である。プラットフォーム４１１のカテゴリの下には、一般的に、ベンダー固有のサブ・レンジ５０１，５０３が存在する。このレベルにおけるエントリの総数は、例えば、ネットワーク内で使用されている異なる複数のコンピュータ製造業者から供給されたコンポーネントの総数に基づいて定まり得る。サン・マイクロシステムズ（Sun Microsystems）などの特定の製造業者の下には、サン・マイクロシステムズが製造した特定のモデル、即ち、タイプのコンピュータを示す２つのエントリ５０５，５０７が存在する。例えば、サン（Sun）の下には、コンピュータ・タイプＪＤＭ１が存在する。各コンピュータ・モデルの下には、そのタイプのコンピュータのアプリケーション・コンフィギュレーション・データを特定するノード５０９などのリーフ・ノードが存在する。リーフ・エントリ内のアプリケーション・コンフィギュレーション・データは、親エントリ（例：ノード５０７）内に示されている特定のコンピュータへ適用可能な全てのコンフィギュレーションを含む。
【００２９】
識別子カテゴリ４１３の下には、図４のネットワーク３０７内の各コンピュータのノード５１１内に示す識別子などの固有識別子を含むエントリが存在する。本実施形態では、各コンピュータのメディア・アクセス・コントロール（media access control、略して、ＭＡＣ）アドレスを固有識別子として使用している。クライアント識別子５１１の下のリーフ・ノード５１３は、この特定のコンピュータに固有のアプリケーション・コンフィギュレーション情報を含む。識別子４１３の下のコンフィギュレーション・データ５１３は特定のユーザーが設定した特定のコンピュータへ適用されるので、コンフィギュレーション・データ５１３をプラットフォーム・カテゴリ４１１の下のコンフィギュレーション・データ５０９と区別できる。本実施形態では、識別子カテゴリの下の固有識別子４１１と、プラットフォーム・カテゴリ４１１の下のエントリとの間には、クロス・リファレンス（図示略）が存在する。即ち、特定の識別子から特定のタイプのコンピュータへのリファレンスが存在する。これにより、特定の固有識別子が示すプラットフォームまたはコンピュータのタイプをサーバーが決定することができる。
【００３０】
プロフィール・カテゴリ４１５の下には、ネットワーク内のコンピュータの特定のカテゴリまたは使用方法を記述するエントリが存在する。例えば、企業内の部門を表し得る特定のプロフィールに関するコンフィギュレーション情報はプロフィール・カテゴリ４１５の下に含まれる。この例を財務（finance）プロフィールのノード５１５及び販売（sales）プロフィールのノード５１７に示す。財務ノード５１５の下には、財務プロフィールに関連するデータを含むアプリケーション固有データ５１９が存在する。固有識別子からプラットフォーム・エントリへのリファレンスと同じように、必要に応じて、特定の識別子リーフ・ノード５１３からプロフィール・エントリ、即ち、ノード５１９へのリファレンスが存在する。即ち、経理部門で使用しているコンピュータまたは受付係端末としてのみ使用しているコンピュータなどの特定のコンピュータが特定のプロフィールを有する場合、そのコンピュータの識別子から適切なプロフィール・エントリへのリファレンスが存在する。
【００３１】
図７は本発明の１つの実施形態に基づくユーザー・ネームスペースを示す概略図である。本実施形態では、ユーザー・ネームスペース４０７は２つのカテゴリ、即ち、ユーザー（users）及びグループ（groups）を有する。ユーザー・カテゴリ（Users category）４１７はノード６０１，６０３，６０５などに示すネットワーク３０７上の各ユーザーの名前を表す。各ユーザーのノードの下には、リーフ・ノード６０７で示すような各ユーザーの個人設定を含む特定のコンフィギュレーション・データが存在する。例えば、ワードプロセッシング・アプリケーションでは、特定のユーザー設定（user preference）は、デフォルトのフォント及び文書のフォーマット設定を含み得る。このカテゴリによれば、各ユーザーがネットワーク３０７上の任意のコンピュータを使用することができ、かつ、そのユーザー個人のコンフィギュレーション（即ち、個人設定）が、そのコンピュータに知らされるようになる。例えば、このユーザーがワード・プロセッシング・プログラムを起動した場合、そのユーザーの個人設定（preference）がコンピュータの通常のユーザーのデフォルトに代わってデフォルトとなる。
【００３２】
ユーザー・ネームスペース内のもう一方のカテゴリはグループ・カテゴリである。このカテゴリは特定のユーザーのグループに関するエントリを含む。グループ（Groups）４１９は様々なカテゴリを含み得る。このカテゴリの例としては、ノード６０９，６１１に示すような企業内の部門、即ち、企業内の各従業員を他の従業員と区別するカテゴリが挙げられる。本実施形態では、適切な場合、ユーザー・カテゴリ４１７の下の各ユーザー６０３，６０５から１つ以上の特定のグループへのリファレンス・ポインタが存在する。
【００３３】
図８は本発明の１つの実施形態に基づくジャバ・システム・データベース環境内で動作するコンフィギュレーション・サーバーからＬＤＡＰディレクトリ内のデータへアクセスするプロセスを示すフローチャートである。図８のフローチャートはクライアント・ネットワークを保持すべく前記の図４〜図７で説明したＪＳＤサーバー・スキーマによって設定したコンフィギュレーション・サーバーと、ユーザー・コンフィギュレーション・データとを使用している。ステップ７０２では、ＪＳＤサーバーのブートアップ後、該ＪＳＤサーバーはコンフィギュレーション・データをＬＤＡＰディレクトリ・サーバーからインポートする、即ち、キャッシングする。このステップでは、ＪＳＤサーバー・スキーマはＬＤＡＰディレクトリ・サービスから得られた自身が必要とするコンフィギュレーション・データの“イニシャル・ポピュレーション”を調べる。このステップは以下の図９で詳述する。ステップ７０４では、クライアント・コンピュータをブートアップし、特定のユーザーがこれにログオンする。このクライアント・コンピュータのコンフィギュレーション・データと、前記の特定のユーザーのコンフィギュレーション・データとを収集する（retreave）ために、このクライアント・コンピュータはＪＳＤサーバーへアクセスする。データをクライアントＪＳＤスキーマ及びサーバーＪＳＤスキーマの間で交換するためのプロトコルは、１９９８年５月１４日に出願された“コンフィギュレーション・データをコンピュータ・ネットワーク内で交換するためのプロトコル（A Protocol for Exchanging Configuration data in a Computer Network）”と称される米国特許出願第０９／０７９，４９９号に更に詳細に開示されており、この特許出願の内容はこの開示を持って本明細書中に開示したものとする。
【００３４】
ステップ７０６では、通常のユーザー・アクティビティ及びクライアント・オペレーション中、ＪＳＤサーバーはクライアントが要求（request）したデータ、即ち、クライアントが必要とするデータがＪＳＤサーバー・スキーマ内に存在するか否かを判定する。クライアントが必要とするコンフィギュレーション・データをＪＳＤサーバーから入手可能な場合、このコンフィギュレーション・データを収集する。そして、コントロールはステップ７１０へ移行し、このコンフィギュレーション・データをクライアントへ送信する。コンフィギュレーション・データをＪＳＤサーバーから入手できない場合、コントロールはステップ７０８へ移行し、必要なコンフィギュレーション・データをＬＤＡＰディレクトリ・サーバー上で探し当てる。このプロセスは図１３で詳細に説明する。前記のコンフィギュレーション・データ・アイテムを有する正しいリーフ・ノードに到達するまで、適切なネームスペース（マシン・ネームスペースまたはユーザー・ネームスペース）及びそれに続くカテゴリを識別していくことによって、前記のコンフィギュレーション・データ・アイテムをＪＳＤサーバー内で探し当て得る。例としては、CONFIG/MACHINE/identifier/（ＭＡＣアドレス）/（特定のコンフィギュレーション・プロパティ）のような“パス”が挙げられる。
【００３５】
以下に詳述するマッピング・プロセスを介することにより、このパスの一部はデータをＬＤＡＰサーバーからＪＳＤサーバー・スキーマへ返すために使用される。ＬＤＡＰサーバーからのデータは収集され、かつ、ＪＳＤサーバー・スキーマへ送信される。ステップ７１０では、コンフィギュレーション・データはクライアントへ送信され、プロセスは完了する。
【００３６】
図９は本発明の１つの実施形態に基づくＪＳＤサーバーをＬＤＡＰディレクトリ・サービスを用いて初期化するプロセスを示すフローチャートである。これは図８のステップ７０２の詳細を示す。ステップ８０２では、ＪＳＤサーバーは、ＪＳＤサーバーをブートアップするためのデータのインポート元となるＬＤＡＰディレクトリ内の適切なコンテキストを、決定する。本実施形態では、ＬＤＡＰディレクトリは、すべてスタートアップさせる必要はないがＪＳＤサーバーが必要とする全てのデータを含む、“ＪＳＤ”と呼ばれるコンテキストまたは他の適切な名前のコンテキストを有する。本実施形態では、ＪＳＤユーザー・ネームスペース内の殆どのデータは、ＤＡＰサーバーから収集（populate）されている。別の実施形態では、ユーザー・データの一部は、ＪＳＤサーバー上に既に存在している。別の実施形態では、ＪＳＤサーバー・スタート・アップ・データをＬＤＡＰディレクトリ内の複数のコンテキストにわたって分散させ得る。更に別の実施形態では、ＪＳＤサーバーは殆どまたは全てのスタート・アップ・コンフィギュレーション・データを既に有し得る。
【００３７】
ステップ８０４では、ＪＳＤサーバーはＬＤＡＰディレクトリ上の“ＪＳＤ”コンテキスト内の全てのエントリを収集する。本実施形態では、ＪＳＤサーバーはこのコンテキスト内の全てのエントリを収集する。別の実施形態では、必要に応じて、１つ以上のコンテキスト内の更に多くの数のエントリまたは更に少ない数のエントリをＪＳＤサーバーは収集し得る。ステップ８０６では、ＬＤＡＰエントリ内の属性に対応したＪＳＤパスを収集する。このプロセスは図１４で詳述する。ステップ８０８では、コンフィギュレーション・データをステップ８０６で決定したＪＳＤエントリ内に格納し、プロセスはこの段階で完了する。
【００３８】
図１０は本発明の１つの実施形態に基づくＪＳＤサーバー内のユーザー固有のコンフィギュレーション・データのリーフ・ノードのフォーマットと、ＬＤＡＰディレクトリ・サーバー内の属性を有するユーザー・エントリとを示す図である。ＪＳＤサーバー内のユーザー固有のコンフィギュレーション・データは図７におけるノード６０７として最初に説明した。図１０は図７のノード６０１に示すユーザーの“Jon”に関するＪＳＤプロパティ９０２のリストを示す。例えば、リスト９０２はユーザーのログオンＩＤ（logon_ID）、アドレス（address）、電子メール・アドレス（email_address）、ユーザーＩＤ（user_ID）及び所属部門（department）を含む。リーフ・ノード６０７内の特定のユーザー・コンフィギュレーション・データ・アイテムはユーザー、ネットワーク及びアプリケーションの特定の要求仕様（needs）に基づくとともに、リスト９０２内に示すプロパティに限定されない。
【００３９】
更に、ユーザーのJonathan A. Smithのタイプ、即ち、識別ネームｕのＬＤＡＰエントリ９０４を図１０は示す。これは図２に示すエントリ２１０の改良、即ち、変更である。ここでは、属性リスト（attribute list）２１２は、ログオン（logon）９０８、メール（mail）９１０及びコンピュータ（computer）９１２の追加の“シャドー属性”を含む拡張属性リスト（enhanced attribute list）９０６として、示されている。これらのシャドー属性はＪＳＤサーバーの“イニシャル・ポピュレーション”スタート・アップ中に使用される。このプロセスは図１４で詳述する。簡単に言えば、シャドー属性によって、図９のステップ８０６及びステップ８０８で最初に説明したＪＳＤサーバー・スキーマのイニシャル・ポピュレーションを、ＬＤＡＰサーバーが迅速に実施することが可能となる。対応するプロパティをＪＳＤサーバー・スキーマ内に有するＬＤＡＰサーバー内の属性は、“シャドー”を有する。本実施形態では、シャドー属性は対応するＪＳＤプロパティの名前と、ＪＳＤプロパティを探し当てることが可能なＪＳＤパスと、ＪＳＤプロパティに関連付けられたジャバ・クラスの名前とを含む。
【００４０】
本実施形態では、シャドー属性はドット（．）で始まる。別の実施形態では、シャドー属性を示すために、他の特別なキャラクタまたはマークを使用できる。ピリオドに続いて、“ログオン（logon）”または“メール（mail）”などのシャドーになっているＬＤＡＰ属性の名前が存在する。このＬＤＡＰ属性名の次には、ＪＳＤプロパティ名が続いている。シャドー属性９０８内では、このＪＳＤプロパティ名はリスト９０２内の最初のＪＳＤプロパティである“ログオンＩＤ（logon_ID）”である。プロパティの順番またはシャドー属性の順番は重要ではなく、本実施形態では機能的な役目はない。ＪＳＤプロパティ名の後には、ＪＳＤパスが存在する。属性９０８内では、ＪＳＤパスはユーザー・ネームスペース内に存在し、かつ、ユーザー“Jon”で終わる。このＪＳＤパス名の後には、ログオンＩＤ（logon_ID）に関連するジャバ・クラス名（Java class name）が続いている。属性９１２内では、ＪＳＤプロパティはＬＤＡＰ内のコンピュータ・シリアル・ナンバー・タイプ属性に対応するクライアントＩＤ（client_ID）である。クライアントＩＤは特定のマシンに関連付けられているので、このクライアントＩＤに関するパスはマシン・ネームスペース内に存在する。
【００４１】
図１４で詳述するように、ＪＳＤサーバー・スキーマを最初にポピュレートする際、特定のコンフィギュレーション・データ・アイテムを格納するＪＳＤサーバー・スキーマ内の正確な場所を迅速に識別するために、シャドー属性を使用する。このデータ・アイテムの実際の値はエントリ内のレギュラー属性、即ち、“非シャドー”属性から獲得する。本実施形態では、シャドー・エントリはＪＳＤサーバー・スキーマに熟知したネットワーク・コンピュータ・管理者（manager）によって手動で形成される。ＪＳＤスキーマ及びジャバ・クラス名の知識を有する個人は、対応するプロパティをＪＳＤスキーマ内に有するＬＤＡＰ内の属性を識別可能である。このような個人はシャドー属性をＬＤＡＰエントリ内へ挿入可能である。本実施形態では、シャドー属性はＪＳＤサーバーからアクセス可能であり、ＪＳＤサーバーはシャドー属性を読み取り可能（permission）にしている。
【００４２】
図１１は本発明の１つの実施形態に基づくＬＤＡＰサーバーに含まれるＬＤＡＰメタ・ディレクトリ（LDAP meta directory）のフォーマットを示す図である。ＬＤＡＰメタ・ディレクトリ９１４はｃ、ｂｕ及びｕなどのＬＤＡＰタイプ、即ち、識別ネームのリストであり、その後には、関連する各属性のリストが続いている。ＪＳＤサーバーがコンフィギュレーション・データ・アイテムをＬＤＡＰサーバーから収集する必要がある際、メタ・ディレクトリが使用される。これにより、特定のタイプが特定の属性を有するか否かをＬＤＡＰサーバーが迅速に決定することが可能となる。同じＬＤＡＰコンテキスト内のデータへアクセスする必要のあるネットワーク内の他のレガシー・システムにとっても、これは効果的である。エントリへアクセスする前に、特定のタイプ内のどの属性が必要かを決定するために、これらのレガシー・システムはメタ・ディレクトリ９１４を使用し得る。値をエントリから収集する際、レガシー・システムが探し求めている属性の値のみを抽出するために、このレガシー・システムはメタ・ディレクトリから学んだ情報を使用できる。レガシー・システムはメタ・ディレクトリをＬＤＡＰエントリ上のマスクとして実質的に使用する。エントリ内へのシャドー属性の追加は、シャドー属性を有する属性の値を収集する際の、エラーの確率を減少させる。このため、シャドー属性をエントリ内へ追加すれば、このマスキング・ファンクションは特に効果的といえる。
【００４３】
図１２は本発明の１つの実施形態に基づく上位パス・マップ・コンポーネント（high-level path map component）のフォーマットを示す図である。上位パス・マップ・コンポーネント９１６は各上位ＪＳＤパスと、これに対応する識別ネームからなるＬＤＡＰ階層パスと、の間のマッピングを含む。本実施形態では、ＪＳＤサーバー・スキーマ内の上位パスはCONFIGと称されるルート・エントリから始まり、その後には、２つの一次ネームスペース、即ち、マシン・ネームスペース及びユーザー・ネームスペースのうちの一方が続き、最後には、これら２つのネームスペースの下の５つのカテゴリのうちの１つが位置する。図８のステップ７０８で最初に説明したように、ＪＳＤサーバーが自分の持っていないデータ・アイテムを要求（request）した際、ＬＤＡＰサーバー内で行われるサーチを限定するために、前記のマッピングを使用する。ＬＤＡＰサーバー内のデータ・アイテムを収集する際のその役目は、図１３で詳述する。本実施形態では、上位パス・マップはＬＤＡＰディレクトリ・サービスを管理するネットワーク・コンピュータ管理ツール内のコンポーネントであり、かつ、ＪＳＤと通信可能である（即ち、“ＪＳＤを認識している”）。従って、ＪＳＤがＬＤＡＰサーバーから特定のコンフィギュレーション・データ・アイテムを必要とする際、スタンダード・サーチング・ファンクションを使用してサーチするＬＤＡＰ階層構造の“枝”を決定するために、ＪＳＤは上位パス・マップへ最初にアクセスする。ＪＳＤスキーマ・パス（これらは全て効果的に定義されている）と、ＬＤＡＰサーバー内の上位識別ネームと、の間のマッピングは、これら２つのスキーマに熟知したネットワーク・コンピュータ管理者が実施する。
【００４４】
図１３はコンフィギュレーション・データ・アイテムがＪＳＤサーバー上に存在しない場合に、このデータ・アイテムをＬＤＡＰディレクトリ・サービスから収集する本発明の１つの実施形態に基づくプロセスを示すフローチャートである。図１３は図８のステップ７０８の詳細を示す。ステップ１００２では、ＪＳＤサーバーはＪＳＤサーバー・スキーマの上位パスと、ＬＤＡＰ階層構造と、の間の一致関係（match）を見つけるためのサーチを、図１２のテーブル９１６を使用して開始する。例えば、クライアント・コンピュータ上でのユーザー要求（request）が特定のユーザー、即ち、Jon Smithのラスト・ネームのみであるとする。しかし、ＪＳＤサーバー・スキーマはユーザーのラスト・ネームのみを提供するプロパティを有していない。パス、即ち、CONFIG/USER/users/Jon/を通って（traverse）、ラスト・ネームのみを有するプロパティに関するユーザー固有のコンフィギュレーション・データをチェックすることによって、ＪＳＤサーバー・スキーマはこれを決定する。
【００４５】
ステップ１００２では、パスの上位部分、即ち、CONFIG/USER/usersを見つけるためのサーチを図１２のパス名テーブル９１６内で実施する。bu=SunSoft; o=Sun; c=USなどの一連の識別ネームによって表される対応する上位ＬＤＡＰパス名を識別する。本実施形態では、可能性のある５つの上位ＪＳＤパス名が存在し、このうちの３つはマシン・ネームスペース内に存在し（即ち、プラットフォーム、識別子及びプロフィール）、２つはユーザー・ネームスペース内に存在する（即ち、ユーザー及びグループ）。対応するＬＤＡＰ上位パス名を識別すると、ステップ１００４では、識別した上位パスの“下”のＬＤＡＰデータベース内で、サーチが実施される。前記の例では、これはbu=SunSoftより下の全てのデータとなる。ＬＤＡＰデータベースはユーザーのJon Smithに関するラスト・ネーム属性をＬＤＡＰ内のＬＤＡＰカーソル・サーチ・メカニズムを使用してサーチする。本実施形態では、ユーザー・タイプがラスト・ネームに対応する属性を有するか否かを判定するために、図１１のメタ・ディレクトリ９１４を使用する。
【００４６】
ステップ１００６では、図１０のリスト９０６に示すように、ＬＤＡＰサーバーは“ｌｎ（ラスト・ネーム）”属性及びその値を収集し、かつ、データをＪＳＤサーバー・スキーマへ返す。ステップ１００８では、ＪＳＤサーバー・スキーマは“ｌｎ”属性に対応するプロパティを形成し、かつ、属性値を書き込む（insert）。次いで、このデータはそれを要求したクライアントへ送信され、プロセスは完了する。本実施形態では、ＪＳＤサーバー上に最初に存在せず、よって、ＬＤＡＰサーバーから収集したコンフィギュレーション・データ・アイテムは、要求への応答としてクライアントへ提供されるのみならず、ＪＳＤサーバーをアップデートするためにも使用される。
【００４７】
図１４はＬＤＡＰエントリをＪＳＤエントリへマッピングする本発明の１つの実施形態に基づくプロセスを示すフローチャートである。これは図９のステップ８０６の詳細を示す。このプロセスは図１０の属性リスト９０６で最初に説明したシャドー属性を使用する。図９は、ブートアップにおいてＪＳＤサーバーを初期化するプロセスを示していた。本実施形態では、このプロセスにおいて、ＪＳＤスキーマ内のユーザー・ネームスペース・データのかなりの部分はＬＤＡＰサーバーからのデータによって構成（populate）されている。別の実施形態では、前記の実施形態におけるマシン・ネームスペース・データの場合と同様に、ユーザー・データの一部はＪＳＤサーバー上にあらかじめ存在していることもある。マシン・ネームスペース・データの量（volume）はユーザー・ネームスペース・データの量より遙かに小さいので、その情報をＪＳＤサーバー上に維持することは実行可能であり、かつ、効果的である。一般的に、ユーザー・ネームスペース・データは１つのＬＤＡＰコンテキスト（例：“ＪＳＤ”コンテキスト）内に存在し、かつ、ＪＳＤサーバー内にインポートされる、即ち、キャッシングされる。
【００４８】
ステップ１１０２では、ＬＤＡＰサーバーは適切なＬＤＡＰコンテキスト内の各エントリを読み出す。ＬＤＡＰのデザイン及びプロトコルが軽量であるため、これを迅速に実行できる。本実施形態では、ＪＳＤサーバー・スキーマ内のユーザー・ネームスペースを構成（populate）するために必要な全てのコンフィギュレーション・データを含む１つのコンテキストが存在する。ステップ１１０４では、ＬＤＡＰサーバーはシャドー属性及び対応する“非シャドー”属性を区別、即ち、分離する。図１０の属性９０８，９１０，９１２に示すように、シャドー属性はドットなどの固有のリーディング・シンボルを有するので、これも迅速に実行可能である。ステップ１１０６では、“logon: jsmith”などの属性またはエントリの実際の値を決定するために、ＬＤＡＰサーバーは非シャドー属性を使用し、さらには、この値を格納するＪＳＤサーバー・スキーマ内の場所と、この値の格納先となるオブジェクト・タイプとに関する命令において、ＬＤＡＰサーバーは対応するシャドー属性を使用する。ステップ１１０８では、ＪＳＤサーバーはこの値をアクセプトするとともに、この値に対応するオブジェクトを形成するために、適切なオブジェクト・コンストラクタを使用し、形成されたオブジェクトをシャドー属性内に提供されているＪＳＤパスのボトムのリーフ・ノード内に格納する。ＬＤＡＰが、前記のＪＳＤロケーション生成のためにシャドー属性を使用し、前記の値の生成のために非シャドー属性を使用することによって、ＪＳＤサーバーのスタートアップ時間が長くなることが回避され得る。
【００４９】
ソフトウェア及びデータ・フォーマットまたはデータ構造に主に関連する本発明は、コンピュータ・システム内に格納されたデータを使用する様々なコンピュータ実行オペレーションによって実現される（employ）。これらのオペレーションは物理量の物理操作を必要とするオペレーションを含む（但し、同オペレーションに限定されない）。一般的に、必ずしも必要でないが、これらの量は格納、転送、結合、比較及び他の操作が可能な電気信号または磁気信号の形態をなす。本発明の一部を構成する本明細書中に開示するオペレーションは、効果的なマシン・オペレーションである。実施する操作は生成（producing)、識別（identifying）、実行（running）、決定（determining）、比較（comparing）、実行（executing）、ダウンローディング（downloading）または検出（detecting）等の用語で示されることが多い。特に、共通の用法を確立するために、これらの電気信号または磁気信号をビット、値、エレメント、変数、キャラクターまたはデータ・アイテム等として示すと都合が良い。しかし、これらの用語またはこれらに類似する用語の全ては、適切な物理量に結びつけて考えられるべきであり、かつ、これらの用語は、これらの物理量に適用された都合の良いラベルにすぎない点を覚えておく必要がある。
【００５０】
更に、本発明はＪＳＤサーバー及びＬＤＡＰサーバーなどの前記のオペレーションを実施するためのデバイス、システムまたは装置に関する。これらのシステムは要求された目的のために特別に構築し得る。また、これらのシステムは、コンピュータ内に格納されたコンピュータ・プログラム、またはライトウェイト・ディレクトリ・アクセス・プロトコル（ＬＤＡＰ）などの特定のプロトコルに基づいて動作するコンピュータ・プログラムによって選択的に作動または設定される汎用コンピュータとして構築し得る。前記の複数のプロセス及びデータ・フォーマットは特定のコンピュータまたは他のコンピューティング装置に固有のものではない。特に、本明細書の開示内容に基づいて記述されたプログラムを様々な汎用コンピュータ上で実行可能である。また、これに代えて、必要なオペレーションを実施するために、更に特化したコンピュータ・システムを形成することは更に都合が良く、このコンピュータ・システムの例としては、ＪＳＤサーバーとして動作すべく形成されたサーバー・コンピュータなどが挙げられる。
【００５１】
図１５は本発明の１つの実施形態に基づく処理の実施に適した汎用コンピュータ・システム１２００のブロック図である。図１５はＬＤＡＰディレクトリ・サーバーまたはＪＳＤサーバーなどのサーバー・コンピュータとして動作させるために設定または拡張（enhance）できる汎用コンピュータ・システムの１つの例を示す。本発明の処理を実施するために、他のコンピュータ・システム・アーキテクチャ及びコンフィギュレーションを使用し得る。以下に詳述する様々なサブシステムからなるコンピュータ・システム１２００は少なくとも１つのマイクロプロセッサ・サブシステム（中央処理装置、即ち、ＣＰＵとも称される）１２０２を含む。即ち、ＣＰＵ１０２はシングルチップ・プロセッサまたは複数のプロセッサによって実現し得る。ＣＰＵ１０２はコンピュータ・システム１２００のオペレーションを制御する汎用デジタル・プロセッサである。メモリから収集した命令を使用して、ＣＰＵ１２０２は入力データの受信及び操作と、出力デバイス上でのデータの出力及び表示とを制御する。
【００５２】
ＣＰＵ１２０２は一般的にランダム・アクセス・メモリ（ＲＡＭ）からなる第１の一次ストレージ１２０４へメモリ・バス１２０８を通じて両方向接続されている。更に、ＣＰＵ１２０２は一般的にリード・オンリ・メモリ（ＲＯＭ）からなる第２の一次ストレージ領域１２０６へメモリ・バス１２０８を通じて単方向接続されている。当該技術分野でよく知られているように、一次ストレージ１２０４は汎用ストレージ領域及び作業メモリとして使用可能であり、さらには入力データ及び処理済みデータを格納するためにも使用できる。前記の図面に示すように、一次ストレージ１２０４は、プログラミング命令及びデータを、エンハンスドＬＤＡＰ属性若しくはエントリの形態またはＪＳＤ階層の形態等で格納できる。これはＣＰＵ１２０２上で実施するプロセスのための他のデータ及び命令煮付け加えられるものであるとともに、データ及び命令をメモリ・バス１２０８を通じて両方向で高速転送するために一般的に使用される。同様に、当該技術分野でよく知れられているように、一次ストレージ１２０６は、ＣＰＵ１２０２がその機能を果たすために使用する基本オペレーティング命令、プログラム・コード、データ及びオブジェクトを一般的に含む。データ・アクセスが両方向または単方向のいずれを必要とするかなどの条件に基づいて、一次ストレージ・デバイス１２０４，１２０６は以下に詳述する任意の適切なコンピュータ読み取り可能ストレージ媒体を含み得る。ＣＰＵ１２０２は頻繁に必要となるデータをキャッシュ・メモリ１２１０内へ高速で直接収集し、かつ、格納できる。
【００５３】
取り外し可能大容量ストレージ・デバイス１２１２はコンピュータ・システム１２００のための別のデータ・ストレージ能力を提供し、かつ、周辺バス１２１４を通じてＣＰＵ１２０２へ両方向または単方向で接続されている。例えば、ＣＤ−ＲＯＭとして一般的に知られている特定の取り外し可能大容量ストレージ・デバイスはデータを単方向でＣＰＵ１２０２へ送信する。その一方、フロッピー・ディスクはデータを両方向でＣＰＵ１２０２へ送信し得る。例えば、ＪＳＤサーバー内のマシン・ネームスペース内のデータは、取り外し可能大容量ストレージ・デバイス１２１２内に格納し得る。ストレージ１２１２は磁気テープ、フラッシュ・メモリ、搬送波に組み込まれた信号、ＰＣカード、ポータブル大容量ストレージ・デバイス、ホログラフィック・ストレージ・デバイス及び他のストレージ・デバイス等のコンピュータ読み取り可能媒体を更に含み得る。固定大容量ストレージ１２１６は別のデータ・ストレージ能力を提供し、かつ、周辺バス１２１４を通じてＣＰＵ１２０２へ両方向で接続されている。大容量ストレージ１２１６の最も一般的な例は、ハード・ディスク・ドライブである。一般的に、これらの媒体へのアクセスは一次ストレージ１２０４，１２０６へのアクセスより遅い。ＣＰＵ１２０２が頻繁に使用しない他のプログラミング命令及びデータ等を大容量ストレージ１２１２，１２１６は一般的に格納する。必要に応じて、大容量ストレージ１２１２，１２１６内に保持された情報は、一次ストレージ１２０４（例：ＲＡＭ）の一部を構成する仮想記憶（virtual memory）として標準的に組込み可能である。
【００５４】
ストレージ・サブシステムへのＣＰＵ１２０２のアクセスを提供する以外に、周辺バス１２１４は他のサブシステム及びデバイスへのアクセスを提供するために使用される。本実施形態では、これらは、ディスプレイ・モニタ１２１８及びアダプタ１２２０、プリンタ・デバイス１２２２、ネットワーク・インターフェース１２２４、補助入出力装置インターフェース１２２６、サウンド・カード１２２８及びスピーカー１２３０、並びに必要とされる他のサブシステムを含む。
【００５５】
図示するように、ネットワーク接続を使用することにより、ネットワーク・インターフェース１２２４はＣＰＵ１２０２を別のコンピュータ、コンピュータ・ネットワークまたはテレコミュニケーション・ネットワークへ接続可能にする。前記の方法のステップを実行するうえで、ＣＰＵ１２０２はコンフィギュレーション・データ、コンフィギュレーション・データに関する要求（request）、またはプログラム命令などの情報を別のネットワークからネットワーク・インターフェース１２２４を通じて受信するか、または情報をネットワーク・インターフェース１２２４を通じて別のネットワークへ送信し得る。ＣＰＵで実行する複数の命令のシーケンスに代表される情報は、搬送波に組み込まれたコンピュータ・データ信号などの形態で別のネットワークに対して送受信可能である。インターフェース・カードまたはこれに類似するデバイスと、ＣＰＵ１２０２によって実行される適切なソフトウェアとは、コンピュータ・システム１２００を外部ネットワークへ接続し、かつ、データを標準プロトコルに基づいて転送するために使用できる。即ち、本発明の方法はＣＰＵ１２０２上で単独で実行し得る。これに代えて、処理の一部を共有する遠隔ＣＰＵと協動することにより、本発明の方法をインターネット、イントラネットワークまたはローカル・エリア・ネットワーク（例えば、エンタープライズ・ワイド・ネットワーク内）等のネットワークを通じて実行し得る。別の大容量ストレージ・デバイス（図示略）をネットワーク・インターフェース１２２４を通じてＣＰＵ１２０２へ接続し得る。
【００５６】
補助入出力装置インターフェース１２２６は、マイクロホン、タッチ・ディスプレイ、トランスデューサ・カード・リーダー、テープ・リーダー、音声認識装置、手書き文字認識装置、バイオメトリクス・リーダー、カメラ、ポータブル大容量ストレージ・デバイス及び他のコンピュータ等の装置に対するＣＰＵ１２０２によるデータの送受信を可能にする汎用インターフェース及びカスタム・インターフェースを、表す。
【００５７】
キーボード１２３６またはポインタ・デバイス１２３８からの入力を受信し、さらにはデコードしたシンボルをキーボード１２３６またはポインタ・デバイス１２３８からＣＰＵ１２０２へ送信するために、キーボード・コントローラ１２３２がローカル・バス１２３４を通じてＣＰＵ１２０２へ接続されている。ポインタ・デバイスはマウス、スタイラス、トラック・ボールまたはタブレットであり得る。そして、ポインタ・デバイスはグラフィカル・ユーザー・インターフェースとの相互作用に効果的である。
【００５８】
更に、本発明の実施形態は様々なコンピュータ実行オペレーションを実施するためのプログラム・コードを含むコンピュータ読み取り可能媒体を有するコンピュータ・ストレージ・プロダクト（computer storage products）に関する。コンピュータ読み取り可能媒体は、コンピュータ・システムによる後からの読み取りが可能なデータを格納し得る任意のデータ・ストレージ・デバイスである。媒体及びプログラム・コードは、ＬＤＡＰサーバーからのコンフィギュレーション・データの収集などの本発明の目的のために特別に設計され、かつ、形成されたものであるか、またはコンピュータ・ソフトウェアの分野における当業者に周知のものであり得る。コンピュータ読み取り可能媒体の例としては、ハード・ディスク、フロッピー・ディスク及び磁気テープなどの磁気媒体と、ＣＤ−ＲＯＭディスクなどの光媒体と、光フロッピー・ディスクなどの磁気光媒体と、特定用途向け集積回路（ＡＳＩＣ）、プログラム可能論理回路（ＰＬＤ）、ＲＯＭデバイス及びＲＡＭデバイスなどの特別に構成されたハードウェア・デバイスとを含めた前記の全ての媒体が挙げられる（但し、これらに限定されない）。コンピュータ読み取り可能媒体は搬送波に組み込まれたデータ信号として結合コンピュータ・システムのネットワーク上に分散させ得る。従って、コンピュータ読み取り可能コードは分散した形態で格納及び実行できる。プログラム・コードの例としては、コンパイラ等によって形成されたマシン・コード、またはインタプリタを使用して実行し得る更に高いレベルのコードを含むファイルが挙げられる。
【００５９】
前記のハードウェア・エレメント及びソフトウェア・エレメントが標準的なデザイン及び構成を有することを当業者は理解し得る。本発明に適した他のコンピュータ・システムは更に多くの数のサブシステムまたは更に少ない数のサブシステムを含み得る。更に、メモリ・バス１２０８、周辺バス１２１４及びローカル・バス１２３４は複数のサブシステムをリンクするために使用する任意の相互接続方式の実例である。例えば、ローカル・バスはＣＰＵを固定大容量ストレージ１２１６及びディスプレイ・アダプタ１２２０へ接続するために使用可能である。図１５に示すコンピュータ・システムは本発明に適したコンピュータ・システムの例である。サーバー・コンピュータのコンフィギュレーションのように、サブシステムの別のコンフィギュレーションを有する他のコンピュータ・アーキテクチャを使用し得る。
【００６０】
以上、理解を容易にする目的で、本発明をある程度詳しく説明したが、特定の変更及び修正を本発明の請求の範囲内で実施しても良い。更に、本発明のプロセス及び装置の両方をインプリメントする別の方法が存在することに注意する必要がある。例えば、本発明をコンフィギュレーション・データを使用して説明したが、他のタイプの非コンフィギュレーション・データをジャバ・システム・データベース内に格納し、ネットワーク内のＬＤＡＰディレクトリ・サービスからこの非コンフィギュレーション・データへアクセス可能である。この場合、ＬＤＡＰデータベースは非コンフィギュレーション・タイプのデータを格納する。別の例では、一部のユーザー・ネームスペース・コンフィギュレーション・データはＪＳＤサーバー上に永続的に存在し得る。これによって、ＪＳＤサーバーのスタートアップ後、このデータをＬＤＡＰサーバーからインポートする、即ち、キャッシングする必要がなくなる。更に別の例では、コンフィギュレーション・データを格納するために、前記のＪＳＤサーバー・スキーマ以外のコンフィギュレーション・リポジトリを使用し得る。シャドー属性及び上位パス・マッピングの概念を、別の種類のコンフィギュレーション・リポジトリと一緒に使用できる。従って、本明細書に開示した複数の実施形態は例示を目的とするものであって、限定を目的としない。更に、本発明は本明細書に開示する詳細部分に限定されることなく、請求の範囲及びそれに等価なものの範囲内で変更できる。
【図面の簡単な説明】
【図１】クライアントがＬＤＡＰディレクトリ・サービス内のデータへアクセスする方法を示すブロック図である。
【図２】ＬＤＡＰディレクトリ・ツリーの階層ブロック図である。
【図３】ＬＤＡＰディレクトリ・サービス内における図２の階層構造を表すネーム・スキーマ及び関連する属性を示す図である。
【図４】本発明の１つの実施形態に基づくシステム・ワイド・データ・スキーマを有するコンピュータ・ネットワークのコンポーネントを示す概略図である。
【図５】本発明の１つの実施形態に基づくＪＳＤサーバー・スキーマの構造を示すブロック図である。
【図６】本発明の１つの実施形態に基づくサーバー・スキーマ内のマシン・ネームスペースの階層構造を示す概略図である。
【図７】本発明の１つの実施形態に基づくユーザー・ネームスペースを示す概略図である。
【図８】本発明の１つの実施形態に基づくジャバ・システム・データベース環境内のＬＤＡＰディレクトリ内のデータへアクセスするプロセスを示すフローチャートである。
【図９】本発明の１つの実施形態に基づくＪＳＤサーバーをＬＤＡＰディレクトリ・サービスを用いて初期化するプロセスを示すフローチャートである。
【図１０】本発明の１つの実施形態に基づくＪＳＤサーバー内のユーザー固有のコンフィギュレーション・データ・リーフ・ノードのフォーマットと、属性をＬＤＡＰディレクトリ・サーバー内に有するユーザー・エントリとを示す図である。
【図１１】本発明の１つの実施形態に基づくＬＤＡＰサーバーに含まれるＬＤＡＰメタ・ディレクトリのフォーマットを示す図である。
【図１２】本発明の１つの実施形態に基づく上位パス・マップ・コンポーネントのフォーマットを示す図である。
【図１３】コンフィギュレーション・データ・アイテムがＪＳＤサーバー上に存在しない場合に、このデータ・アイテムをＬＤＡＰディレクトリ・サービスから収集する、本発明の１つの実施形態に基づくプロセスを示すフローチャートである。
【図１４】ＬＤＡＰエントリをＪＳＤエントリへマッピングする本発明の１つの実施形態に基づくプロセスを示すフローチャートである。
【図１５】本発明の実施形態の実現に適した一般的なコンピュータ・システムのブロック図である。
Claims (22)
- プロセッサと、
前記プロセッサと通信するコンフィギュレーション・サーバーと、
前記プロセッサに接続されるストレージデバイスであって、前記ストレージデバイスは、前記プロセッサによって実行されるエクステンションを格納しており、前記エクステンションは、ディレクトリサービスと前記コンフィギュレーション・サーバーとの間のマッピングを可能にする、ストレージデバイスと、
ディレクトリ・サービス・サーバーと、
を備えるシステムであって、
前記エクステンションは、
少なくとも一つのディレクトリ・エントリと、
ディレクトリ・アドレスとコンフィギュレーション・サーバー・ロケーション識別子との対応情報ファイルと、
を備えており、
前記ディレクトリ・エントリは、１つ以上のシャドー属性を含み、
前記各シャドー属性は、特定のスタンダード・ディレクトリ属性にそれぞれ対応しており、
前記特定のスタンダード・ディレクトリ属性は、対応するプロパティをコンフィギュレーション・サーバー内に有し、
前記対応情報ファイルは、ディレクトリ・アドレスと、コンフィギュレーション・サーバー・ロケーション識別子と、の間の一致情報を含み、
前記ディレクトリ・サービス・サーバーは、
一つの特定のコンフィギュレーション・サーバー・ロケーション識別子について、前記特定のコンフィギュレーション・サーバー・ロケーション識別子と、一つの特定のディレクトリ・アドレスとの一致関係を見つけるために、前記ディレクトリ・アドレスとコンフィギュレーション・サーバー・ロケーション識別子との対応情報ファイルを、サーチし、
前記ディレクトリ・サービス・サーバーに格納された複数のディレクトリ・サービス・エントリのうちサーチすべき一部を決定するために、前記一つの特定のディレクトリ・アドレスを使用して、１つ以上のディレクトリ・エントリを求めて、前記ディレクトリ・サービス・サーバーに格納された複数のディレクトリ・サービス・エントリの前記一部をサーチし、
前記１つ以上のディレクトリ・エントリの前記１つ以上のシャドー属性に対応する１つ以上の値を収集し、
前記１つ以上の値をコンフィギュレーション・サーバーに送信する、システム。 - 請求項１に記載のディレクトリ・サービスに対するエクステンションを提供するシステムであって、
前記エクステンションは、さらに、
１つ以上のディレクトリ・タイプのタイプ・リストを含むディレクトリ・サービス・メタ・ディレクトリと、
前記各ディレクトリ・タイプで使用できる１つ以上の属性の属性リストと、
を含むシステム。 - 請求項２に記載のディレクトリ・サービスに対するエクステンションを提供するシステムであって、
前記各ディレクトリ・タイプはディレクトリ・サービス識別ネームである、システム。 - 請求項１に記載のディレクトリ・サービスに対するエクステンションを提供するシステムであって、
前記各シャドー属性は、対応するコンフィギュレーション・サーバー・プロパティ及びコンフィギュレーション・サーバー・ロケーション識別子を有する、システム。 - 請求項４に記載のディレクトリ・サービスに対するエクステンションを提供するシステムであって、
前記各シャドー属性は、さらに、前記対応するコンフィギュレーション・サーバー・プロパティに関連付けられたクラス名を含む、システム。 - 請求項１に記載のディレクトリ・サービスに対するエクステンションを提供するシステムであって、
前記コンフィギュレーション・サーバーは、複数のクライアント及び複数のネットワーク・ユーザーに関するコンフィギュレーション・データを有するジャバ・システム・データベース・サーバーである、システム。 - 請求項１に記載のディレクトリ・サービスに対するエクステンションを提供するシステムであって、
前記各シャドー属性は、同属性がシャドー属性であることを示すマーカーを冒頭に有する、システム。 - 請求項４に記載のディレクトリ・サービスに対するエクステンションを提供するシステムであって、
前記コンフィギュレーション・サーバー・ロケーション識別子は、一連のノードであり、
前記各ノードは、情報のカテゴリを示す、システム。 - 請求項１に記載のディレクトリ・サービスに対するエクステンションを提供するシステムであって、
前記ディレクトリ・サービスは、ライトウェイト・ディレクトリ・アクセス・プロトコルである、システム。 - プロセッサおよび前記プロセッサに接続されるストレージデバイスと、前記プロセッサと通信しコンフィギュレーション・データベースを備えるコンフィギュレーション・サーバーと、前記プロセッサと通信するディレクトリ・サービス・サーバーと、を備えるシステムであって、
前記コンフィギュレーション・データベースは、
前記コンフィギュレーション・データベース内で使用する少なくとも一つのプロパティ名を格納するためのコンフィギュレーション・データベース・プロパティ・フィールドと、
前記コンフィギュレーション・データベースをサーチするために使用する少なくとも一つのロケーション識別子を格納するためのコンフィギュレーション・データベース・ロケーション・フィールドと、
前記シャドー属性をシャドー属性として識別するために、前記シャドー属性に関連付けられたマーカーと、を有し、
前記ディレクトリ・サービス・サーバーは、
前記ディレクトリ・サービス・サーバーに格納された複数のディレクトリ・サービス・エントリのうちサーチすべき一部を決定するために、一つの特定のコンフィギュレーション・サーバー・ロケーション識別子と一致する一つの特定のディレクトリ・アドレスを使用して、前記ディレクトリ・サービス・サーバーに格納された１つ以上のディレクトリ・エントリであって属性の集合を含むディレクトリ・エントリを求めて、ディレクトリ・サービス・サーバーの一部をサーチし、
前記１つ以上の前記ディレクトリ・エントリからの少なくとも一つの前記属性の集合から１つ以上の値を収集し、
前記１つ以上の値のそれぞれに対応する前記ロケーション識別子とプロパティ名とを決定するために、１つ以上のシャドー属性をクエリーし、
前記１つ以上の値と、前記対応するプロパティ名およびロケーション識別子とを、前記コンフィギュレーション・サーバーに送信する、システム。 - 請求項１０に記載のシャドー属性のための属性フォーマットのデータを格納するシステムであって、さらに、
前記コンフィギュレーション・データベース内へ格納する値に関連付けられたクラス名を格納するためのコンフィギュレーション・データベース・クラス名フィールドを更に有する、システム。 - 請求項１０に記載のシャドー属性のための属性フォーマットのデータを格納するシステムであって、
前記ロケーション識別子は階層構造内の一連のノードである、システム。 - 請求項１０に記載のシャドー属性のための属性フォーマットのデータを格納するシステムであって、
前記ディレクトリ・サービスは、ライトウェイト・ディレクトリ・アクセス・プロトコルであり、
前記コンフィギュレーション・データベースは、ジャバ・システム・データベースである、システム。 - ディレクトリ・サーバーのディレクトリ・サービスをサーチすることにより、１つ以上のディレクトリ・サービス・エントリ、そして、前記１つ以上のディレクトリ・サービス・エントリのそれぞれの対応する値を、ネットワーク・ディレクトリ・サービスから、収集する工程と、
前記１つ以上のディレクトリ・サービス・エントリ、および前記１つ以上のディレクトリ・サービス・エントリのそれぞれの対応する値を、コンフィギュレーション・サーバー上のコンフィギュレーション・データベースへ送信する工程と、
前記ネットワーク・ディレクトリ・サービス内のシャドー・ディレクトリ・サービス・エントリに対するクエリーによって、前記コンフィギュレーション・データベース内における前記各対応する値のロケーション及びプロパティ名を決定する工程と、
前記シャドー・ディレクトリ・サービス・エントリから決定した前記ロケーションに基づいて、前記対応する値を前記コンフィギュレーション・データベース内へ格納する工程と
を含む方法。 - 請求項１４に記載の方法であって、さらに、
前記ディレクトリ・サーバーに格納された前記１つ以上のディレクトリ・サービス・エントリと、前記１つ以上のディレクトリ・サービス・エントリそれぞれからの対応する値と、を収集する先の前記ネットワーク・ディレクトリ・サービス内のコンテキストを決定する工程を含む、方法。 - 請求項１４に記載の方法であって、さらに、
前記各ディレクトリ・サービス・エントリを前記各シャドー・ディレクトリ・サービス・エントリと区別する工程を含む、方法。 - 請求項１４に記載の方法であって、
前記シャドー・ディレクトリ・サービス・エントリは、
前記コンフィギュレーション・データベース上のパスと、
前記コンフィギュレーション・データベースに関連付けられたプロパティ名と、を含む、方法。 - 請求項１７に記載の方法であって、
前記シャドー・ディレクトリ・サービス・エントリは、さらに、クラス名を含む、方法。 - ジャバ・ベースのコンフィギュレーション・サーバー内で定義された上位パスと、ＬＤＡＰサーバー内で定義された対応するＬＤＡＰ階層パスと、の間の一致関係を見つけるために、前記ジャバ・ベースのコンフィギュレーション・サーバーにおいて、ネットワーク・コンピュータ管理ツール上のロケーション一致情報ファイルであって、ディレクトリ・サービス・アドレスとコンフィグレーション・サーバー・ロケーション・パスとの一致を定義するロケーション一致情報ファイルを、サーチする工程と、
サーチするＬＤＡＰサーバーの一部を決定するために、前記対応するＬＤＡＰ階層パスを使用しつつ、前記ＬＤＡＰサーバーに格納された１つ以上のコンフィギュレーション・データの属性を見つけるために、前記ＬＤＡＰサーバーの一部をサーチする工程と、
前記１つ以上のコンフィギュレーション・データの属性から１つ以上の値を収集する工程と、
前記１つ以上の値を前記ジャバ・ベースのコンフィギュレーション・サーバーおよびクライアントへ送信する工程と
を含む方法。 - 請求項１９に記載の方法であって、
前記ロケーション一致情報ファイルは、前記ジャバ・ベースのコンフィギュレーション・サーバー内の複数のパスと、対応する複数のＬＤＡＰアドレスと、を含む方法。 - プロセッサで実行可能なコンピュータ・プログラムを格納したコンピュータ読み取り可能な記録媒体であって、
前記コンピュータ・プログラムは、
ジャバ・ベースのコンフィギュレーション・サーバー内で定義された上位パスと、ＬＤＡＰサーバーの特定のＬＤＡＰアドレスと、の間の一致関係を見つけるために、前記ジャバ・ベースのコンフィギュレーション・サーバー内で定義された前記上位パスを求めて、ネットワーク・コンピュータ管理ツール上のロケーション一致情報ファイルに、前記ジャバ・ベースのコンフィギュレーション・サーバーによってアクセスするコンピュータ・コードと、
サーチされるＬＤＡＰサーバーの一部を決定するために、前記特定のＬＤＡＰアドレスを使用しつつ、前記ＬＤＡＰサーバーに格納された１つ以上のコンフィギュレーション・データ・アイテムの属性を見つけるために、前記ＬＤＡＰサーバーの一部をサーチするコンピュータ・コードと、
前記１つ以上の属性から１つ以上の値を収集するコンピュータ・コードと、
前記１つ以上の値を前記ジャバ・ベースのコンフィギュレーション・サーバーおよびクライアントへ送信するコンピュータ・コードと、
を有するコンピュータ読み取り可能な記録媒体。 - プロセッサで実行可能であり、データをネットワーク・ディレクトリ・サービスからコンフィギュレーション・データベースへ送信するためのコンピュータ・プログラムを格納したコンピュータ読み取り可能な記録媒体であって、
前記コンピュータ・プログラムは、
コンフィギュレーション・サーバー上のコンフィギュレーション・データベースへ送信する、ディレクトリ・サーバーに格納された１つ以上のディレクトリ・サービス・エントリを前記ディレクトリ・サーバーのディレクトリ・サービスから、そして、前記１つ以上のディレクトリ・サービス・エントリのそれぞれの対応する値をネットワーク・ディレクトリ・サービスから、収集するコンピュータ・コードと、
前記ネットワーク・ディレクトリ・サービス内のシャドー・ディレクトリ・サービス・エントリに対するクエリーによって、前記コンフィギュレーション・データベース内における前記各対応する値のロケーション及びプロパティ名を決定するコンピュータ・コードと、
前記シャドー・ディレクトリ・サービス・エントリから決定した前記ロケーションに基づいて、前記対応する値を前記コンフィギュレーション・データベース内へ格納するコンピュータ・コードと、
を有するコンピュータ読み取り可能な記録媒体。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US09/239596 | 1999-01-29 | ||
| US09/239,596 US6366954B1 (en) | 1998-05-14 | 1999-01-29 | Method and data format for exchanging data between a Java system database entry and an LDAP directory service |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2000311123A JP2000311123A (ja) | 2000-11-07 |
| JP4771321B2 true JP4771321B2 (ja) | 2011-09-14 |
Family
ID=22902861
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2000022256A Expired - Lifetime JP4771321B2 (ja) | 1999-01-29 | 2000-01-31 | データをジャバ・システム・データベース・エントリ及びｌｄａｐディレクトリ・サービスの間で交換するための方法及びデータ・フォーマット |
Country Status (4)
| Country | Link |
|---|---|
| US (1) | US6366954B1 (ja) |
| EP (1) | EP1039380B1 (ja) |
| JP (1) | JP4771321B2 (ja) |
| DE (1) | DE60019839T2 (ja) |
Families Citing this family (43)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4159181B2 (ja) * | 1999-05-24 | 2008-10-01 | 沖電気工業株式会社 | サービス属性管理装置 |
| US6587874B1 (en) * | 1999-06-29 | 2003-07-01 | Cisco Technology, Inc. | Directory assisted autoinstall of network devices |
| US6636961B1 (en) * | 1999-07-09 | 2003-10-21 | International Business Machines Corporation | System and method for configuring personal systems |
| US6496977B1 (en) * | 1999-10-21 | 2002-12-17 | International Business Machines Corporation | Method and system for implementing network filesystem-based aid for computer operating system upgrades |
| US6947953B2 (en) * | 1999-11-05 | 2005-09-20 | The Board Of Trustees Of The Leland Stanford Junior University | Internet-linked system for directory protocol based data storage, retrieval and analysis |
| US6490619B1 (en) * | 1999-12-07 | 2002-12-03 | International Business Machines Corporation | Method and system for managing multiple lightweight directory access protocol directory servers |
| US6732172B1 (en) * | 2000-01-04 | 2004-05-04 | International Business Machines Corporation | Method and system for providing cross-platform access to an internet user in a heterogeneous network environment |
| US20020013827A1 (en) * | 2000-05-18 | 2002-01-31 | Edstrom Claes G.R. | Personal service environment management apparatus and methods |
| US6685090B2 (en) * | 2000-05-24 | 2004-02-03 | Fujitsu Limited | Apparatus and method for multi-profile managing and recording medium storing multi-profile managing program |
| FR2809511B1 (fr) * | 2000-05-26 | 2003-09-12 | Bull Sa | Systeme et procede de gestion des transactions de composants ejb dans un annuaire accede par ldap |
| US20080040550A1 (en) * | 2000-07-07 | 2008-02-14 | Lindner David J | Method and apparatus for providing enhanced access to a lightweight directory access protocol (ldap) directory server |
| US20020029203A1 (en) * | 2000-09-01 | 2002-03-07 | Pelland David M. | Electronic personal assistant with personality adaptation |
| US6983269B2 (en) * | 2000-12-19 | 2006-01-03 | International Business Machines Corporation | Apparatus for indirect directory searches and method therefor |
| US6973494B2 (en) * | 2000-12-29 | 2005-12-06 | Bellsouth Intellectual Property Corporation | System and method for bi-directional mapping between customer identity and network elements |
| US6862692B2 (en) | 2001-01-29 | 2005-03-01 | Adaptec, Inc. | Dynamic redistribution of parity groups |
| US6990667B2 (en) | 2001-01-29 | 2006-01-24 | Adaptec, Inc. | Server-independent object positioning for load balancing drives and servers |
| US7054927B2 (en) * | 2001-01-29 | 2006-05-30 | Adaptec, Inc. | File system metadata describing server directory information |
| US7107595B2 (en) * | 2001-04-05 | 2006-09-12 | Hewlett-Packard Development Company, L.P. | Mechanism for mapping Java objects onto an LDAP repository |
| US7016976B2 (en) * | 2001-05-31 | 2006-03-21 | Sun Microsystems, Inc. | UniqueID-based addressing in a directory server |
| US7519575B1 (en) * | 2001-08-31 | 2009-04-14 | Novell, Inc. | Method and apparatus for presenting, searching, and viewing directories |
| DE10149977A1 (de) * | 2001-10-10 | 2003-04-24 | Siemens Ag | Verfahren zum Zugriff auf Nutzerdaten, zugehörige Datenverarbeitungsanlage, zugehöriges Programm und zugehörige Datenstruktur |
| US6915287B1 (en) * | 2001-12-13 | 2005-07-05 | Novell, Inc. | System, method and computer program product for migrating data from one database to another database |
| US7107615B2 (en) * | 2002-01-30 | 2006-09-12 | Hewlett-Packard Development Company, L.P. | Parameter verification in an authentication system and method |
| US7917466B2 (en) | 2002-02-21 | 2011-03-29 | Hewlett-Packard Development Company, L.P. | Automatically processing digital assets of a digital camera |
| IL166717A0 (en) * | 2002-08-26 | 2006-01-15 | Computer Ass Think Inc | Web services apparatus and methods |
| US20040205240A1 (en) * | 2002-11-21 | 2004-10-14 | International Business Machines Corporation | Method, system, and computer program product for providing a four-tier corba architecture |
| US7184995B2 (en) * | 2003-02-26 | 2007-02-27 | America Online Inc. | Data interoperability between open standard directory service and proprietary database |
| JP2004295867A (ja) * | 2003-03-07 | 2004-10-21 | Ricoh Co Ltd | 情報処理装置，画像形成装置および情報処理方法 |
| US7539771B2 (en) * | 2003-06-06 | 2009-05-26 | Microsoft Corporation | Organizational locality in prefix-based structured peer-to-peer overlays |
| US20050015383A1 (en) * | 2003-07-15 | 2005-01-20 | Microsoft Corporation | Method and system for accessing database objects in polyarchical relationships using data path expressions |
| US7549149B2 (en) * | 2003-08-21 | 2009-06-16 | International Business Machines Corporation | Automatic software distribution and installation in a multi-tiered computer network |
| US20050234932A1 (en) * | 2004-04-08 | 2005-10-20 | Wong Daniel M | Method and apparatus for facilitating secure centralized administration of databases |
| US7760746B2 (en) * | 2004-11-30 | 2010-07-20 | Computer Associates Think, Inc. | Cascading configuration using one or more configuration trees |
| US7797332B1 (en) * | 2006-01-17 | 2010-09-14 | Fortinet, Inc. | Computer-implemented method and device for providing security on a computer network |
| US8606832B2 (en) * | 2006-10-24 | 2013-12-10 | Red Hat, Inc. | Dynamic management of groups |
| US8738658B2 (en) * | 2007-06-04 | 2014-05-27 | Hewlett-Packard Development Company, L.P. | Method for using paths in a directory for locating objects |
| US8156484B2 (en) * | 2007-08-22 | 2012-04-10 | International Business Machines Corporation | LDAP server performance object creation and use thereof |
| JP5136159B2 (ja) * | 2008-03-31 | 2013-02-06 | 富士通株式会社 | 構成情報管理装置、構成情報管理プログラム及び構成情報管理方法 |
| EP2131293A1 (en) | 2008-06-03 | 2009-12-09 | Alcatel Lucent | Method for mapping an X500 data model onto a relational database |
| JP5244743B2 (ja) * | 2009-08-31 | 2013-07-24 | 京セラドキュメントソリューションズ株式会社 | 画像形成装置およびインストール方法 |
| US10404710B2 (en) * | 2016-03-30 | 2019-09-03 | Change Healthcare Holdings, Llc | Methods and apparatuses for providing improved directory services |
| CN110704481B (zh) * | 2018-06-25 | 2024-04-05 | 北京京东尚科信息技术有限公司 | 展示数据的方法和装置 |
| CN112114885B (zh) * | 2020-09-15 | 2024-05-10 | 青岛海信移动通信技术有限公司 | 一种终端、控制设备及服务处理方法 |
Family Cites Families (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH05204726A (ja) * | 1992-01-24 | 1993-08-13 | Chugoku Nippon Denki Software Kk | データファイル変換装置 |
| US5819283A (en) * | 1993-05-11 | 1998-10-06 | Apple Computer, Inc. | Method and system for the extensibility of objects |
| US5873093A (en) * | 1994-12-07 | 1999-02-16 | Next Software, Inc. | Method and apparatus for mapping objects to a data source |
| US5826000A (en) * | 1996-02-29 | 1998-10-20 | Sun Microsystems, Inc. | System and method for automatic configuration of home network computers |
| US6119118A (en) * | 1996-05-10 | 2000-09-12 | Apple Computer, Inc. | Method and system for extending file system metadata |
| EP0810755B1 (en) * | 1996-05-31 | 2003-04-16 | Hewlett-Packard Company, A Delaware Corporation | Systems and methods for operating a network management system |
| US6253254B1 (en) * | 1996-07-11 | 2001-06-26 | Ansgar Erlenkoetter | Hyper media object management |
| JP3097844B2 (ja) * | 1998-03-06 | 2000-10-10 | 株式会社ボッシュオートモーティブシステム | 平行軸差動歯車装置 |
| US6052720A (en) * | 1998-05-14 | 2000-04-18 | Sun Microsystems, Inc. | Generic schema for storing configuration information on a server computer |
| US6119157A (en) * | 1998-05-14 | 2000-09-12 | Sun Microsystems, Inc. | Protocol for exchanging configuration data in a computer network |
-
1999
- 1999-01-29 US US09/239,596 patent/US6366954B1/en not_active Expired - Lifetime
-
2000
- 2000-01-12 EP EP00300189A patent/EP1039380B1/en not_active Expired - Lifetime
- 2000-01-12 DE DE60019839T patent/DE60019839T2/de not_active Expired - Lifetime
- 2000-01-31 JP JP2000022256A patent/JP4771321B2/ja not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| US6366954B1 (en) | 2002-04-02 |
| EP1039380A2 (en) | 2000-09-27 |
| JP2000311123A (ja) | 2000-11-07 |
| DE60019839D1 (de) | 2005-06-09 |
| DE60019839T2 (de) | 2005-10-06 |
| EP1039380B1 (en) | 2005-05-04 |
| EP1039380A3 (en) | 2003-11-05 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4771321B2 (ja) | データをジャバ・システム・データベース・エントリ及びｌｄａｐディレクトリ・サービスの間で交換するための方法及びデータ・フォーマット | |
| JP4533474B2 (ja) | コンピュータネットワーク内でデータを変換するための方法 | |
| US6052720A (en) | Generic schema for storing configuration information on a server computer | |
| US6161125A (en) | Generic schema for storing configuration information on a client computer | |
| US8090693B2 (en) | System, method, and article of manufacture for maintaining and accessing a whois database | |
| US7827280B2 (en) | System and method for domain name filtering through the domain name system | |
| US6233582B1 (en) | Persistent storage interface for a configuration object-based system | |
| US6564370B1 (en) | Attribute signature schema and method of use in a directory service | |
| US6816864B2 (en) | System and method for handling set structured data through a computer network | |
| US8856068B2 (en) | Replicating modifications of a directory | |
| US20020032775A1 (en) | System and method for transmitting and retrieving data via a distributed persistence framework | |
| US20020032684A1 (en) | Directory information management apparatus, directory information management method, and computer readable recording medium having directory information management program stored therein | |
| US20090119376A1 (en) | Hint-Based Email Address Construction | |
| US6715128B1 (en) | Method for converting directory data, and program and device therefor | |
| JPH11331245A (ja) | ネットワ―ク・ディレクトリ・アクセス機構及び方法 | |
| US20070094301A1 (en) | Application programming interface for centralized storage of principal data | |
| US6370545B1 (en) | Method of accessing removable storage media | |
| JP2001076005A (ja) | データベースシステム | |
| US7363328B2 (en) | Method and system for modifying schema definitions | |
| US8041689B2 (en) | Flexible LDAP templates | |
| EP0957617A2 (en) | A generic schema for storing configuration information on a client computer and a server computer | |
| US7664758B1 (en) | Integrated database system and method for accessing a plurality of databases | |
| US5546573A (en) | Specification of cultural bias in database manager | |
| US7096236B2 (en) | Change sequence number generator | |
| JPH08329093A (ja) | 分散ディレクトリシステム及び知識情報変更方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20070109 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20090428 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20090512 |
|
| A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20090811 |
|
| A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20090814 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20091112 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20100202 |
|
| A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20100426 |
|
| A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20100430 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20100802 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20101026 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20110228 |
|
| A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20110412 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20110517 |
|
| RD03 | Notification of appointment of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7423 Effective date: 20110613 |
|
| RD04 | Notification of resignation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7424 Effective date: 20110614 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20110614 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140701 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 4771321 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| EXPY | Cancellation because of completion of term |