JP4197753B2 - 多数ディレクトリサービスに一様にアクセスするための方法及びシステム - Google Patents
多数ディレクトリサービスに一様にアクセスするための方法及びシステム Download PDFInfo
- Publication number
- JP4197753B2 JP4197753B2 JP21114897A JP21114897A JP4197753B2 JP 4197753 B2 JP4197753 B2 JP 4197753B2 JP 21114897 A JP21114897 A JP 21114897A JP 21114897 A JP21114897 A JP 21114897A JP 4197753 B2 JP4197753 B2 JP 4197753B2
- Authority
- JP
- Japan
- Prior art keywords
- directory service
- function
- interface
- class
- oleds
- 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
-
- 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/289—Object oriented databases
-
- 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
-
- 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
Landscapes
- Engineering & Computer Science (AREA)
- Databases & Information Systems (AREA)
- Theoretical Computer Science (AREA)
- Data Mining & Analysis (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Stored Programmes (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Description
【０００１】
【発明の属する技術分野】
この発明はコンピュータベースのディレクトリサービスに関し、特に、ディレクトリサービスに同じようにアクセスするための方法及びシステムに関する。
【０００２】
【従来の技術】
コンピュータシステムは一般的には、コンピュータシステム及びそのユーザに関する多量のデータをストアし且つ保持する。例えば、コンピュータシステムはコンピュータシステムのユーザの名前、電子メールアドレス、及び、電話番号を保持する。コンピュータシステムはまた、コンピュータシステムに接続された種々のプリンタに関する情報も保持する。この情報は、プリンタ特性（例えば、レーザ及びカラー）及び各プリンタを使用するのに許可された使用者の名前を含む。「クライアント」として知られる種々の異なるタイプのコンピュータプログラムは、この情報にアクセスする必要がある。例えば、あるクライアントは、プリンタが書類をカラーでプリントするのに使用されることができることを判断するのに必要であるコンピュータプログラムであってよい。別のクライアントは、例えば、新しく追加されたプリンタに関する情報を反映するように、システム管理者が情報を更新することができるコンピュータプログラムであってよい。コンピュータシステムは、伝統的には、かかる情報を様々な位置及びフォーマットにストアしてきた。例えば、プリンタに関する情報はコンフィギュレーションファイルにストアされ、ユーザに関する情報はデータベースにストアされたりする。従って、一般的には、クライアントを開発するプログラマはこの情報にアクセスする仕方を知ることはもちろんとして、この情報を探すための場所を知ることさえ困難であった。
【０００３】
あるコンピュータシステムは、この情報をストアし且つ保持するのに有用なディレクトリサービスを提供する。ディレクトリサービスは、クライアントがネットワークにアクセス可能な情報のリポジトリを提供する。一般的には、ディレクトリサービスは、情報が「オブジェクト」として保持されているもの（例えば、ユーザ、プリンタ、又は、アクセスグループ）を参照する。ディレクトリサービスは、このようなオブジェクトの階層をディレクトリに構成する。即ち、コンテナオブジェクトと呼ばれるあるオブジェクトは、コンテナに格納されたオブジェクトを参照する他の種々のオブジェクトを包含する。例えば、共通アクセス権をリソースに対して共有するユーザを含むアクセスグループは、コンテナに格納されたオブジェクトのユーザを包含するコンテナオブジェクトである。ディレクトリサービスが情報を保持する各オブジェクトは、クライアントがオブジェクトを識別することができる固有の識別子（例えば、名前）を有する。ディレクトリサービスは、元々は、コンピュータシステムに関する情報を保持するように開発されたのだが、コンピュータシステムと関係が無い情報を保持するのに使用することもできる。例えば、飛行機の構成要素及びサブコンポーネントのための部品リストを保持するために、飛行機製造業者がディレクトリサービスを使用することができる。
【０００４】
図１はディレクトリサービスの階層構造を表す一例である。各ブロックは特定の「オブジェクトクラス」のオブジェクトを表わす。例えば、会社を表わすオブジェクトは、「会社（Company)」と名付けられたオブジェクトクラスを有する。各オブジェクトクラスは、そのオブジェクトクラスのオブジェクトプロパティ(property)を定義する。例えば、前記会社オブジェクトクラスは、プロパティとして「名前」及び「住所」を定義することができる。各オブジェクトは、オブジェクトクラスのために定義された各プロパティに関するプロパティ値を有する。例えば、会社オブジェクトクラスのオブジェクトは、名前のプロパティのために、プロパティ値「ＭＳ」を有することができる。ブロック101 は会社オブジェクトクラスのオブジェクトに対応し、名前及び住所のプロパティに関する値を有する。ブロック102 は、部門オブジェクトクラスのオブジェクトに対応し、部門の名前（例えば、「システム（System) 」）に関する値を有する。ブロック103 はユーザオブジェクトクラスのオブジェクトに対応し、ユーザの電子メールアドレスに関する値を有する。ディレクトリサービスは階層的に構成されているので、ルート(root)からオブジェクトまでのパス(path) 情報によって、各オブジェクトを一意的に識別することができる。例えば、オブジェクト102 は、パス「Company=MS＼Division=Systems」によって一意的に識別される。ディレクトリサービスは、ネームスペース（namespace ）と呼ばれる概念的な有限空間を提供し、任意の名前を解読することができる。ディレクトリサービスは、ディレクトリのオブジェクトに対するパスを明瞭に解読する。
【０００５】
種々のベンダは、ディレクトリサービスシステムを提供する。典型的には、各ベンダは、クライアントがそのディレクトリサービスにアクセスすることを可能にするために、アプリケーションプログラミングインターフェース（ＡＰＩ）を設計し且つインプリメント（実装）する。したがって、各ディレクトリサービスシステムは、非常に異なるＡＰＩセット（集合）を有しており、且つ、そのようなＡＰＩセットを有するのが一般的である。クライアントが異なるディレクトリサービスシステムを使用する必要がある場合、例えば、クライアントはパーソナルコンピュータ及びメインフレームコンピュータを含む環境で作動するので、クライアントのプログラマは、各ディレクトリサービスのＡＰＩセットについて知っておく必要があり、ＡＰＩセットの各々をサポートするようにクライアントを設計する必要がある。
【０００６】
各ＡＰＩセットはベンダ固有であるけれども、一般的にはＡＰＩセットは類似した機能性を提供する。一般的には、ＡＰＩセットは、オブジェクトのプロパティ値にアクセスするためのファンクション（関数）と、新しいオブジェクトクラスを定義するためのファンクションとを含む。オブジェクトを処理するファンクションは、例えば、OpenObject、ReadObject、WriteObject 、ListObject、CloseObject 、CreateObject及びDereteObjectである。オブジェクトに対する識別（例えば、パス情報）がファンクションOpenObjectに渡され、ファンクションOpenObjectは、そのオブジェクトを識別するハンドル(handle)をリターンする。その後、このハンドルはクライアントによって使用されることで、ディレクトリサービスに対するオープンオブジェクトを識別する。ファンクションOpenObjectはオブジェクトを識別するために識別を使用し、次いで、識別されたオブジェクトのプロパティを見つけ出す。オープンオブジェクト、及び、検索されるべきそのオブジェクトのプロパティの名前リストへのハンドルが、ファンクションReadObjectにパスされる。ファンクションReadObjectは、それらのプロパティに関する現在のプロパティ値をリターンする。オープンオブジェクトと、プロパティ名及びプロパティ値の組のリストへのハンドルが、ファンクションWriteObject にパスされる。ファンクションWriteObject は、前記組のプロパティ値に対するオープンオブジェクトにおいて名付けられた各プロパティを設定する。オープンオブジェクトへのハンドルがファンクションListObjectに渡され、ファンクションListObjectはオープンオブジェクト内に格納された各オブジェクトの識別を有するリストをリターンする。オープンオブジェクトへのハンドルがファンクションCloseObject に渡され、そのハンドルでもはやアクセスすることができないようにするため、ファンクションCloseObject はオブジェクトを閉じる。オブジェクトクラスがファンクションCreateObjectに渡され、ファンクションCreateObjectは、オープンオブジェクト内に格納されているオブジェクトクラスのオブジェクトを作り、ハンドルをコンテナに格納されたオブジェクトにリターンする。オープンオブジェクトへのハンドルがファンクションDeleteObjectに渡され、ファンクションDeleteObjectは、オープンオブジェクトをそのコンテナオブジェクトから除去する。
【０００７】
オブジェクトクラスを定義するためのファンクションは、CreateObjectClass 、DeleteObjectClass 、CreateProperty、DeleteProperty、AddPropertyToObjectClass、DeletePropertyFromObjectClass 、及びListPropertiesOfObjectClass である。新しいオブジェクトクラスの名前がファンクションCreateObjectClass に渡され、ファンクションCreateObjectClass は新しいオブジェクトクラスを作る。いったんオブジェクトクラスが作られたら、次にクライアントはそのオブジェクトクラスのオブジェクトを作ることができる。プロパティの名前及びプロパティタイプ（例えば、整数又は列）がファンクションCreatePropertyに渡され、ファンクションCreatePropertyはそのプロパティタイプ（例えば、「文字列」のプロパティタイプを有する「住所」のプロパティ名）のプロパティを作る。オブジェクトクラスの名前及びプロパティの名前がファンクションAddPropertyToObjectClassに渡され、ファンクションAddPropertyToObjectClassは名付けられたオブジェクトクラスのプロパティとして、ネーミングされたプロパティを加える。オブジェクトクラスの名前がファンクションListPropertiesOfObjectClass に渡され、ファンクションListPropertiesOfObjectClass はそのオブジェクトクラスに加えられているプロパティのリストをリターンする。ファンクションDeleteObjectClass 、DeleteProperty、及びDeletePropertyFromObjectClass は、それらの名前によって示される動作を行う。
【０００８】
後述するように、本発明はオブジェクト指向技術を使用し、従って、周知のオブジェクト指向プログラミング技術の概略を提供するものである。（「オブジェクト」という用語は、異なる文脈において使用された場合、多くの異なる意味を有する。そこで、この従来技術の以降の説明においては、「オブジェクト」という用語を、インメモリデータ構造に 言及するために、オブジェクト指向の意味において使用されるものとする。）オブジェクト指向プログラミング言語において共通する２つの特徴は、データ隠蔽と、データ型の承継に関するサポートである。データ隠蔽は、ファンクション（関数）とデータを結びつけることを指す。承継は、他のデータ型があることから、データ型を宣言することができることを指す。Ｃ++言語では、これらデータ隠蔽及び承継がクラスの使用を介してサポートされるものである。クラスは、ユーザ定義による型である。クラス宣言は、クラスのデータメンバ及びファンクション（関数）メンバを記述する。ファンクションメンバはまた、クラスのメソッドとして示される。クラスのデータメンバとファンクションメンバとは、そのファンクションがクラスのインスタンスで機能するように一緒に結びつけられる。クラスのインスタンスはまた、クラスのオブジェクトと称される。したがって、クラスは、類似のプロパティと共通の処理動作を有するオブジェクトのグループのための定義を提供するものである。
【０００９】
特定の型のオブジェクト（クラス）のための記憶領域を割り当てるために、オブジェクトがインスタンスされる。ひとたびインスタンスされると、特定のオブジェクトのデータメンバに対するデータを指定することができる。また、ひとたびインスタンスされると、特定のオブジェクトのファンクションメンバがアクセスのために呼び出され、そしてデータメンバを操作する。その結果、このやり方の場合、ファンクションメンバは、オブジェクトの処理動作をインプリメント（実装）し、そしてオブジェクトはデータ及び処理動作を単一のエンティティ(entity) に隠蔽するための構造を提供する。
承継のコンセプトをサポートするために、クラスは（他のクラスの宣言に基づいて）他のクラスから派生される。派生クラスとは、その基本クラスの特徴（データメンバ及びファンクションメンバ）を承継するクラスである。別のクラスの特徴を承継するクラスが派生クラスである。別のクラスの特徴を承継しないクラスがプライマリ（ルート）クラスであり、その特徴が別のクラスによって承継されるクラスが基本クラスである。派生クラスは種々のクラスの特徴を承継することができる。即ち、派生クラスは幾つかの基本クラスを有しても良い。
【００１０】
クラスはまた、そのファンクションメンバがバーチャル(virtual)であるかどうかを指定することができる。ファンクションメンバがバーチャルであると宣言されると、派生クラスにおいて同じ名前及び同じ型のファンクションによってそのファンクションがオーバーライド (override) されることを意味する。バーチャルファンクションがインプリメンテーション（実装）を提供することなく宣言されるならば、そのバーチャルファンクションは ピュア（純粋 )バーチャルファンクションとして参照される。ピュアバーチャルファンクションは、ピュア指定子 (pure specifier)「＝０」で宣言されたバーチャルファンクションである。仮にクラスがピュアバーチャルファンクションを指定するならば、ファンクションメンバが呼び出される前に、いかなる派生クラスもそのファンクションメンバのためにインプリメンテーション（実装）を指定する必要がある。少なくとも１つのピュアバーチャルファンクションメンバを含むクラスが、アブストラクトクラス（抽象クラス）である。
【００１１】
図２は、オブジェクトを表わすのに使用される典型的なデータ構造を図示したブロック図である。オブジェクトは、オブジェクトの処理動作を実装するインスタンスデータ（データメンバ）及びファンクションメンバをもつ。オブジェクトを表わすのに使用されるデータ構造は、インスタンスデータ構造201 と、バーチャルファンクションテーブル202 と、ファンクションメンバ203,204,205 を含む。インスタンスデータ構造201 は、バーチャルファンクションテーブル202に対するポインタ及びデータメンバを含む。バーチャルファンクションテーブル202 は、オブジェクトのために定義された各バーチャルファンクションメンバに関するエントリを含む。各エントリは、対応するファンクションメンバをインプリメントするコードへのリフェレンス（参照）を含む。このサンプルオブジェクトのレイアウトは、本願に組み入れられた「オブジェクト指向プログラミング言語に関するコンパイラにおけるバーチャルファンクション及びバーチャルベースをインプリメントするための方法」と題する、米国特許第5,297,284 号に説明されたモデルに一致する。以下の説明では、Ｃ++プログラミング言語によって定義されるクラスのインスタンスとしてオブジェクトを説明する。当業者であれば、他のオブジェクトモデルが他のプログラミング言語を使用して定義され得ることは明らかであろう。
【００１２】
オブジェクト指向技術を用いることの利点は、これらの技術がオブジェクトの共有を容易にするために使用できることである。例えば、例示されたオブジェクトのファンクションメンバ（「サーバプログラム」）をインプリメント（実装）するプログラムは、別のプログラム（「クライアントプログラム」）とオブジェクトを共有することができる。任意のクラスのオブジェクトがクライアントプログラムで共有されようにするため、クライアントプログラムを必要とすることなくオブジェクトにアクセスできるインタフェースを定義する。そして、コンパイル時点でそのクラス定義にアクセスする。インターフェースは、論理的に関連したファンクションメンバの集合である。Ｃ++の場合、インターフェースはデータメンバを有しないアブストラクトクラスであり、そしてそのバーチャルファンクションは全てピュアである。したがって、インターフェースは２つのプログラムが通信するための公開プロトコルを提供する。インターフェースは、典型的には派生のために使用される。即ち、プログラムは、クラスを派生させるインターフェースのためのインプリメンテーション（実装）を提供するクラスを定義（インプリメント）する。その後、オブジェクトはこれらの派生クラスのインスタンスとして作られる。特定のインターフェースをインプリメントする派生クラスからインスタンスされたオブジェクトは、インターフェースを「サポート」すると言う。オブジェクトは、所望の機能に依存する１又はそれ以上のインターフェースをサポートする。
【００１３】
クライアントプログラムがオブジェクトを共有することを望む場合、クライアントプログラムはオブジェクト（派生クラスコード）のためのインターフェースをインプリメントするコードにアクセスする必要がある。ワシントン州レッドモンドのマイクロソフトコーポレーションによって確立されたＯＬＥ2.01環境では、派生クラスコード（または、クラスコードとして称する。）にアクセスするために、各クラスのインプリメンテーションは、固有のクラス識別子（「CLSID 」）が与えられる。ＯＬＥ2.01は、『インサイドＯＬＥ』第２版（マイクロソフト発行、1995年、Kraig Brockschmidt著）に記述されている。例えば、マイクロソフトコーポレーションによって開発されたスプレッドシートオブジェクトをインプリメントするコードは、「MSSpreadsheet 」というクラス識別子を有するのに対して、別の会社によって開発されたスプレッドシートオブジェクトをインプリメントするコードは、「LTSSpreadsheet」というクラス識別子を有する。各コンピュータシステムの保存性レジストリは、クラスをインプリメントするコードに各CLSID をマップするということを保持する。典型的には、スプレッドシートプログラムがコンピュータシステムにインストールされたとき、保存性レジストリは、スプレッドシートオブジェクトのそのクラスの使用可能性を反映するために更新される。スプレッドシート開発者がスプレッドシートオブジェクトによってサポートされるべきインターフェースによって定義された各ファンクションメンバをインプリメントする限り、及び、保存性レジストリが保持されている限り、クライアントプログラムは、共有されたスプレッドシートオブジェクトのファンクションメンバにアクセスすることができ、この場合、サーバプログラムはファンクションメンバをインプリメントしたか、或いはどのようにしてインプリメントされているかが考慮されなくてよい。
【００１４】
オブジェクトはあるインターフェースをサポートし、他のインターフェースをサポートしないので、クライアントプログラムは、特定のオブジェクトが特定のインターフェースをサポートするかどうかを実行時に判断する必要がある。この判断を可能にするために、全てのCOM オブジェクトは、ファンクションメンバを含むIUnknownインターフェースと、オブジェクトのためにどのインタフェースがインプリメントされたかを指示するQueryInterfaceとをサポートする。QueryInterfaceメソッドは以下のように定義される：
virtual HRESULT QueryInterface(REFID iid, void**ppv)=0;
（REFID 型の）パラメータiid におけるインターフェース識別子がQueryInterfaceメソッドに渡され、QueryInterfaceメソッドは、パラメータppv においてポインタを指定されたインターフェース「iid 」のインプリメンテーションにリターンする。したがって、QueryInterfaceメソッドは、典型的には、それが属するオブジェクトの使用可能な全てのインターフェースについて知るためにコード化される。オブジェクトがそのインターフェースをサポートしないならば、QueryInterfaceメソッドは偽をリターンする。タイプHRESULT は、所定のステータスを示す。
【００１５】
IUnknownインターフェースはまた、メソッド AddRef 及び Release を定義し、そのメソッドはリファレンスカウントをインプリメントするのに使用される。インターフェースに対して新しいリファレンスが作られるときはいつでも、AddRefメソッドはオブジェクトのリファレンス（参照）カウントを増加させるために呼び出される。リファレンスがもはや必要とされないとき、Release メソッドがオブジェクトのリファレンスカウントを減少させるために呼び出され、そしてリファレンスカウントがゼロに至るとき、オブジェクトは開放される。
【００１６】
【課題を解決するための手段】
本発明はＯＬＥインターフェースに関する定義と、複数のディレクトリサービスに同じようにアクセスすることができるプロバイダソフトウェアのためのモデルとを提供する。各ディレクトリサービスプロバイダは、そのディレクトリサービスのオブジェクトに関する情報を管理する。ディレクトリサービスがオブジェクトのために管理する情報のタイプは、そのオブジェクトのオブジェクトクラスによって定義される。オブジェクトクラスは、ディレクトリサービスがそのオブジェクトクラスのオブジェクトのために管理するプロパティ（即ち、情報）を定義する。各プロパティは、プロパティ名とプロパティタイプを有する。ディレクトリサービスは、各オブジェクトのオブジェクトクラスによって定義された各プロパティに関するプロパティ値を有する。ディレクトリサービスシステムは、スキーマブラウジング部 (schema browsing component)、名前解読部 (name resolving component)、結合部 (binding component)、及び、拡張部 (extending component) を含む。スキーマブラウジング部は、各ディレクトリサービスの各オブジェクトクラスにおける各プロパティのプロパティ名及びプロパティタイプを検索することを制御する。ディレクトリサービスシステムのクライアントは、オブジェクトクラスのプロパティ名及びプロパティタイプを検索するために、スキーマブラウジング部を使用する。名前解読部は、オブジェクトの固有識別子をディレクトリサービス内で受信することや、オブジェクトをディレクトリサービス内で見つけ出すことを制御する。結合 (binding) 部は、ディレクトリサービス内で見つけ出されたオブジェクトを表わすインメモリ(in-memory)オブジェクトと関連づけることを制御する。拡張部は、各ディレクトリサービスのために、新しいオブジェクトクラス及び新しいプロパティを定義することを制御する。ディレクトリサービスシステムのクライアントは、新しいオブジェクトクラス及び新しいプロパティを定義するために拡張部を使用する。
【００１７】
【発明の実施の形態】
本発明は、種々の異なるディレクトリサービスに同じようにアクセスするためのフレームワークを提供する。好ましい実施形態では、OleDs と称されるディレクトリサービスシステムがアーキテクチャを提供し、このアーキテクチャにより、クライアントが、OleDs オブジェクト、属性、及びインターフェースの単一で共通のセットを使用しながら様々なディレクトリサービスのコンテンツにアクセスすることを可能にする。OleDs オブジェクトは、ディレクトリサービスのオブジェクト、及びディレクトリサービスのオブジェクトクラスに対応するインメモリデータ構造(in-memory data structure)である。OleDs オブジェクトがオブジェクトに対応するとき、それはそのオブジェクトのプロパティ値及びメソッドにアクセスするインターフェースを提供する。OleDs オブジェクトがオブジェクトクラスに対応するとき、それはそのオブジェクトクラスの定義にアクセスするインターフェースを提供する。ディレクトリサービスの各プロバイダは、ＡＰＩセットの処理動作をこれらOleDs インターフェースの処置動作にマップするディレクトリサービスに関するインターフェースのインプリメンテーションを提供する。この方法では、OleDs アーキテクチャを使用するために開発されたクライアントが、ディレクトリサービスのＡＰＩセットに相違があるにもかかわらず、これらディレクトリサービスの各々にアクセスすることができる。
【００１８】
OleDs は、「ネームスペース」コンテナ（ "namespaces" container ）と称される、ルートコンテナオブジェクト内にあるすべてのディレクトリサービスをモデル化する。図３は、ネームスペースコンテナを図示したものである。ネームスペーシズ（namespaces）コンテナ内のオブジェクトは、種々のディレクトリサービスを表わす。OleDs は、ネームスペースコンテナ内に格納されたディレクトリサービスを列挙するためのインターフェースを提供する。格納された各ディレクトリサービスは、OleDs ネームスペースコンテナオブジェクトによって表わされる。クライアントは、ディレクトリサービスの存在に気がつくようなインターフェースを用いることができ、そしてディレクトリサービスのオブジェクトクラスの定義を決定するためにそのスキーマにアクセスすることができる。スキーマはディレクトリサービスのオブジェクトクラスの定義を含む。インターフェースがOleDs によって提供されることを介して、クライアントはコンパイル時で未知であったディレクトリサービスの存在及びコンテンツを実行時に発見することができる。
【００１９】
典型的には、各ディレクトリサービスがそのオブジェクトをネーミングする独自の規定を有するので、OleDs は、様々なディレクトリサービスにある各オブジェクトと競合することなく一意的に識別する統一ネーミング規定（uniform naming convention ）を提供する。固有の識別子は、OleDs パスと称される。OleDs パスは、ディレクトリサービスと、識別されたオブジェクトにアクセスするようにオープンにされる必要があるネスト型の (nested)コンテナオブジェクトのセットとを識別する文字列である。OleDs は以下のようなフォーマットを有する：
@NamespaceIdentifier!<namaspace path to object>
又は
NamespaceIdentifier://<namespace path to object>
「NamespaceIdentifier 」はディレクトリサービスを一意的に識別する。「! 」又は「: 」の後の列は、ディレクトリサービスに依存するフォーマット内にある。即ち、各ディレクトリサービスはその独自フォーマットを定義することができる。
【００２０】
OleDs は、OleDs パス (path) と、OleDs パスが識別するオブジェクトに一致するOleDs オブジェクトとを結びつけるための結合ファンクション (binding function)を提供する。OleDs パスがこの結合ファンクションに渡され、そして結合ファンクションはオブジェクトに対応するOleDs オブジェクトにポインタをリターンする。OleDs オブジェクトと結びつけるために、結合ファンクションは、OleDs パスからのネームスペース識別子を構文解析する。結合ファンクションは、識別されたネームスペースへのアクセスをインプリメントするコード（例えば、ダイナミックリンクライブラリ）を検索するために、このネームスペース識別子を使用する。（OleDs は、OleDs インターフェースのインプリメンテーションの位置を登録するディレクトリサービスプロバイダのためのレジストリを維持する。）
次に、結合ファンクションは検索されたコードを呼び出して、OleDs パスを渡す。呼び出されたコードは、識別されたオブジェクトにアクセスし、且つOleDs インターフェースによって定義された処理動作をインプリメントするために、ディレクトリサービスのＡＰＩセットを使用する。
【００２１】
OleDs は、各ディレクトリサービスのオブジェクトを、OleDs コンテナオブジェクト又はOleDs リーフ(leaf)オブジェクトの何れかとしてモデル化する。ディレクトリサービスのコンテナオブジェクトにアクセスするために、ディレクトリサービスのプロバイダによって提供されたインプリメンテーションを有するOleDs コンテナオブジェクトがインスタンスされる。同様に、ディレクトリサービスのリーフオブジェクトにアクセスするために、ディレクトリサービスのプロバイダによって提供されたインプリメンテーションを有するOleDs リーフオブジェクトがインスタンスされる。各OleDs オブジェクトは、ディレクトリサービスの対応オブジェクトのプロパティにアクセスするためのインターフェースを公開する。各OleDs コンテナオブジェクトはまた、インターフェースを公開し、このインタフェースを介してクライアントが包含されたオブジェクトにアクセスできるようにする。
【００２２】
図４は、ディレクトリサービスにおける、OleDs オブジェクトと、それらの対応オブジェクトとの間の関係を図示したものである。各ディレクトリサービスプロバイダは、OleDs オブジェクトによって公開された各インターフェースのインプリメンテーションを提供する。これらのインプリメンテーションは、プロバイダのＡＰＩセットに関する処理動作をOleDs インターフェースの処理動作にマッピングすることに影響をもたらす。したがって、各クライアントは、OleDs インターフェースのプロバイダ・インプリメンテーションを使用して、複数のディレクトリサービスに同じようにアクセスすることができる。
ディレクトリサービスのオブジェクトにアクセスするクライアントを助けるために、OleDs は、各ディレクトリサービスのスキーマを表わすモデルを定義する。概念的に言えば、各オブジェクトクラスのためのスキーマオブジェクトを含むスキーマコンテナオブジェクトを有するとき、各ディレクトリサービスが閲覧 (view) される。スキーマオブジェクトは、オブジェクトクラスのプロパティを定義する。スキーマコンテナは、ネームスペース内にある所定の名前（例えば、「schema」）を指定する。スキーマコンテナにアクセスするため、クライアントはOleDs 結合ファンクションを使用して、スキーマのOleDs パス（例えば、「@WinNTDS!Schema 」）を渡す。OleDs 結合ファンクションは、スキーマコンテナオブジェクトに対応するOleDs コンテナオブジェクトに対して、ポインタをリターンする。クライアントは、格納されたスキーマオブジェクトを列挙するために、OleDs コンテナオブジェクトのインターフェースを使用することができる。この方法では、クライアントは、様々なオブジェクトクラスの定義を実行時に決定することができる。更に、クライアントは、スキーマオブジェクトをスキーマコンテナオブジェクトに加えることによって、追加のオブジェクトクラスを定義することができる。
【００２３】
OleDs は、ディレクトリサービスＡＰＩセットの処理動作を、OleDs インターフェースの処理動作にマッピングするインプリメンテーションを容易にするために、幾つかのオブジェクトクラスを予め定義する。特に、OleDs は、組織的な機関及び国といった、共通のコンテナオブジェクトのためのオブジェクトクラス定義や、ユーザ或いはリソースといった共通のリーフオブジェクトに関するオブジェクトクラス定義を提供する。
OleDs は、デフォルトネームスペース又はディレクトリサービスの概念を定義する。デフォルトネームスペースは、ネームスペースがOleDs パス内に指定されていない場合に、クライアントが使用することを望むネームスペースである。クライアント又はユーザのためのデフォルトネームスペースの識別は、典型的には、レジストリにストアされ、クライアント又はユーザによってインデックス付けされるであろう。
【００２４】
OleDs はまた、クライアントが新たに定義したオブジェクトクラスのオブジェクトを、ディレクトリサービスに加えることを可能にするために、各プロバイダによって実行されるデフォルトOleDs オブジェクトのコンセプトを定義する。典型的には、ディレクトリサービスプロバイダは、ディレクトリサービス内にある各オブジェクトクラスに関するOleDs オブジェクトのインプリメンテーションを提供する。例えば、プロバイダは、コンピュータオブジェクト及び会社オブジェクトのためのオブジェクトクラスに関する異なるインプリメンテーションを提供しうる。各インプリメンテーションは、対応オブジェクトクラスのためにインプリメンテーションのプロパティが定義されていることを知っており、ＡＰＩセットに要求してプロパティの値を検索することができる。しかしながら、クライアントが新しいオブジェクトクラスを実行時に定義するならば、対応のインプリメンテーションはないであろう。その結果、そのディレクトリサービスのために新しいオブジェクトクラスが定義されることを許可する各プロバイダはまた、デフォルトOleDs オブジェクトのインプリメンテーションを提供する。クライアントが、インプリメンテーションをもたないオブジェクトのためにOleDs オブジェクトをインスタンスする要求をするときはいつでも、デフォルトOleDs オブジェクトがインスタンスされる。デフォルトOleDs オブジェクトが対応のオブジェクトクラスの名前を含み、それはオブジェクトクラスの定義をスキーマから検索するのに使用される。この定義を使用することで、デフォルトOleDs オブジェクトは、ディレクトリサービスの対応オブジェクトにアクセスすることができる。
【００２５】
図３Ａは、OleDs の階層構造を図示するブロック図である。階層は、「ネームスペーシズ（Namespaces）」と称されるルート(root)コンテナを含む。ネームスペーシズコンテナは、各ディレクトリサービスのネームスペースを論理的に含む。図３Ｂは、OleDs のアーキテクチャを図示するブロック図である。ディレクトリサービスの各プロバイダは、プロバイダのＡＰＩセットの処理動作をOleDs インターフェースの処理動作にマッピングすることをインプリメントする。各OleDs コンテナオブジェクトは、ディレクトリサービスのコンテナオブジェクトに対応し、そして各OleDs リーフオブジェクトは、ディレクトリサービスのリーフオブジェクトに対応する。
OleDs は、OleDs オブジェクトに対する、クライアントの早期結合 (early binding)と遅い結合 (late binding)の両方を提供する。早期結合は、クライアントの開発者が各オブジェクトのプロパティ名をコンパイル時に知ることを意味する。したがって、クライアントは、プロパティを「getting 」及び「putting 」するメソッド（例えば、「ｇｅｔ＿Ａｄｄｒｅｓｓ」又は「ｐｕｔ＿Ｎａｍｅ」）を直接使用して、これらのプロパティからそれらの値にアクセスするようにプログラムすることができる。各OleDs オブジェクトは、クライアントが実行時に（即ち、遅い結合）プロパティを結び付けることを可能にする、IDispatch インターフェース（ Ole 2.01 で定義されている）を公開する。
【００２６】
各OleDs オブジェクトはIOleDsインターフェースを公開する。このIOleDsインターフェースは、ディレクトリサービスにおいて、対応オブジェクトのプロパティにアクセスするメソッドと一緒に、OleDs オブジェクトの様々な属性を定義する。（以下においては、「プロパティ（property）」という用語はディレクトリサービス内のデータを指し、「属性（attribute ）」という用語は、OleDs によって定義された、OleDs オブジェクトに関するデータを指す。）コンテナである各OleDs オブジェクトはまた、IOleDsContainer インターフェースを提供する。IOleDsContainer インターフェースは、コンテナオブジェクトに関係する様々な属性、及び操作されたコンテナオブジェクトのためのメソッドを定義する。更に、各OleDs オブジェクトは、IOleDs<class> 又はIOleDs<class>operations と名づけられたインターフェースを任意に提供することができる。この場合、<class> はディレクトリサービスにおける対応オブジェクトのオブジェクトクラスの名前に相当し、<class>operations はオブジェクトで実行され得るオペレーションに相当する。例えば、ポイントキューオブジェクト(point queue object)が、プリントジョブを休止させ、開始させ、削除するようなオペレーションを有する。以下においては、これらの OleDs インターフェース及び他のOleDs インターフェースの各々は、インターフェースのあるメソッドを一 例として実行したときの記述ともに定義される。
【００２７】
図４は、本発明を実施するために構成されたコンピュータシステムのブロック図である。コンピュータシステム400 は、メモリ401 と、中央処理装置402 と、I/O インターフェース403 と、記憶装置404 と、表示装置405 とを含む。OleDs オブジェクトの様々なインプリメンテーションは、ディスク等のコンピュータ読み取り可能メモリにストアされる。これらのインプリメンテーションは実行するためにコンピュータメモリにロードされる。コンピュータメモリはクライアント406,407 を含む。メモリはまた、３つのディレクトリサービスのために、OleDs オブジェクト408,411,414 のインプリメンテーションを含む。OleDs オブジェクトの各インプリメンテーションは、ディレクトリサービス409,412,415 の対応ＡＰＩセットにアクセスする。これらのＡＰＩセットは、基礎をなすディレクトリサービスのために、オブジェクト410,413,416 のプロパティへのアクセスを行う。更に、OleDs 自身は、結合ファンクションのインプリメンテーションと、ネームスペーシズコンテナと、ディレクトリサービスの典型的なオブジェクトに対応する様々なOleDs オブジェクトとを提供する。
【００２８】
OleDsGetObject ファンクション
図５は、OleDs の結合ファンクションであるファンクションOleDsGetObjectのフローチャートである。オブジェクト及びインターフェース識別子へのOleDs パスをファンクションOleDsGetObjectに渡すと、ファンクションOleDsGetObjectはオブジェクトを表わすOleDs オブジェクトのインターフェースにポインタをリターンする。ステップ501 では、このファンクションは、OleDs パスからのネームスペース識別子を構文解析する。このファンクションは、ネームスペース識別子を使用して、識別されたネームスペースのプロバイダが提供する構文解析インターフェースのインプリメンテーションを見つけ出す。ステップ502 では、本ファンクションは、（ OLE 2.0.1 で定義された）ファンクション CoGetClassObject をコールし、識別されたネームスペースのプロバイダがインプリメントしたParseDisplayNameクラスのクラスファクトリオブジェクトへのポインタを検索する。本ファンクションは、識別されたネームスペースのためのParseDisplayNameクラスのクラス識別子を動的に生成する。例えば、構文解析されたネームスペースが「WinNTDS 」ならば、クラス識別子は「CLSID＿PDNWinNTDS」であってよい。クラスファクトリオブジェクトは、ParsedDisplayName クラスのオブジェクトをインスタンスし、これはインスタンスされるべきIParseDisplayName インターフェースを公開する。IParseDisplayName インターフェースは、名前をリターンするメソッドを、OleDs パスによって識別されたオブジェクトに関するOleDs オブジェクトに提供する。ステップ503 では、本ファンクションは、IParseDisplayName インターフェースの識別子を渡すメソッドIClassFactory::CreateInstance を呼び出し、そしてIParseDisplayName インターフェースへのポインタを受信する。メソッドCreateInstanceは、動的に生成されたクラス識別子によって識別されたクラスのインスタンスを作成する。ステップ504 では、本ファンクションは、OleDs パスを渡すメソッドIParseDisplayName::ParseDisplayName を呼び出す。メソッドParseDisplayNameは、OleDs パスによって識別されたオブジェクトに関する名前（IMonikerインターフェース）へのポインタをリターンする。ステップ505 では、本ファンクションは、メソッド IMoniker::BindToObject を呼び出し、OleDs パスによって識別されたオブジェクトを表わすOleDs オブジェクトへのポインタを検索する。次いで、本ファンクションは、このポインタをOleDs オブジェクトにリターンする。
【００２９】
IOleDs インターフェース
IOleDsインターフェースは、各OleDs オブジェクトに共通な属性及びメソッドを定義する。以下は、その属性及びメソッドの記述を加えたインターフェースの定義である：
Interface IOleDs：IDispatch
｛ HRESULT get Name(string*pName)
HRESULT get Class(string*pClass);
HRESULT get GUID (string*GUID);
HRESULT get OleDsPath(string*pOleDsPath);
HRESULT get Parent (string*pParentContainer);
HRESULT get Schema (string*pSchemaClassObject);
HRESULT Access(IOleDsAccess**ppComponentAccessControl);
HRESULT PropAccess(string PropName, IOleDsAccess**ppComponent
AccessControl);
HRESULT GetInfo(variant vHints);
HRESULT SetInfo(void);
HRESULT Get(string Name,variant*pProp);
HRESULT Put(string Name,variant Prop);
｝
【００３０】
属性
名前 記述
名前（Name) コンテナオブジェクト内のこのオブジェクトの相対的な名前
OleDsPath このオブジェクトのOleDs パス
クラス(Class) このオブジェクトのオブジェクトクラスのネーム
GUID このオブジェクトクラスのオブジェクトに関する一意的識別子
Parent このオブジェクトのコンテナオブジェクトのOleDs パス
Schema このオブジェクトクラスを表わすスキーマオブジェクトのOleDs パス
メソッド
名前 記述
Access このオブジェクトのセキュリティパーミッションに一致するOleDs アクセスコントロールオブジェクトの（下で説明される）IOleDsAccessインターフェースを得る。
PropAccess これのプロパティにアクセスコントロールを表わすOleDs アクセスコントロール従属オブジェクトのIOleDsAccessインターフェースにポインタを戻す。
GetInfo ディレクトリサービスからこのオブジェクトのプロパティ値を検索し、それらをOleDs オブジェクトにストアする。vHintsパラメータによって、クライアントが、検索されるべきファンクショナルセット又はプロパティを指示することができるので、メソッドはネットワークアクセスを最適化することができる。
SetInfo このオブジェクトに変化を完遂（コミット）する。プロパティがこのオブジェクトで変化しているならば、メソッドはプロパティ値をOleDs オブジェクトからディレクトリサービスに書込む。
Get OleDs オブジェクトから名前をつけられたプロパティに関する値を検索する。
Put OleDs オブジェクトに名前をつけられたプロパティに関する値をセットする。
【００３１】
図６及び図７はIOleDsインターフェースのメソッドのインプリメンテーションを図示する。図６はメソッドIOleDs::GetInfo の流れ図である。このメソッドはオブジェクトに関するプロパティをディレクトリサービスからOleDs オブジェクトにロードする。OleDs はコミットプロセス又はトランザクションプロセスを定義し、オブジェクトのプロパティに対する更新が該コミットプロセス又はトランザクションプロセスによって、（メソッドPut を使用する）OleDs オブジェクトにのみストアされ、クライアントが（メソッドSetInfo を使用して）リクエストしたときにだけディレクトリサービスにストアされる。OleDs オブジェクトが最初に例示されたとき、例えば、ファンクションOleDsGetObjectが呼び出されたとき、例示されたオブジェクトは典型的には、ディレクトリサービスのＡＰＩセットに対するオブジェクトを識別するハンドルを含む。ステップ601 では、メソッドは、ハンドルをオブジェクトと、オブジェクトに関するプロパティ名のリストとにパスさせるファンクションReadObjectを呼び出す。ファンクションReadObjectはディレクトリサービスから名付けられたプロパティに関する値を検索する。
OleDs デフォルトオブジェクトに関するメソッドGetInfo のインプリメンテーションでは、メソッドは、このオブジェクトのオブジェクトクラスに関してスキーマオブジェクトからプロパティ名のリストを検索する。ステップ702 乃至704 では、メソッドループは検索された値をOleDs オブジェクトにストアする。ステップ702 では、メソッドは次の値を選択して、最初から始まる。ステップ703 では、すべての値が既に選択されているならば、次いで、メソッドは戻り、代わりにメソッドはステップ704 に続く。ステップ704 では、メソッドは選択された値をOleDs オブジェクト内にストアし、次の値を選択すべくステップ702 にループする。
【００３２】
図７はメソッドIOleDs::Get の流れ図である。メソッドはプロパティ名をパスし、パスされたプロパティのその値をOleDs オブジェクトから検索し、且つ、戻す。
【００３３】
IOleDsContainer インターフェース
IOleDsContainer インターフェースは、コンテナである各OleDs オブジェクトに共通な属性及びメソッドを定義する。以下は、その属性及びメソッドの記述を加えたインターフェースの定義である。
Interface IOleDsContainer:IDispatch
｛
HRESULT get Count(long*pCount);
HRESULT get NewEnum(IUnknown*ppEnum);
HRESULT get Filter（Variant*pFiler);
HRESULT put Filter（Variant Filter);
HRESULT GetObject(string Class,string RelativeName,IOleDS **
ppNameObject);
HRESULT Create (string Class,string RelativeName,IOleDS**ppNew
Object);
HRESULT Delete (string Class,String RelativeName);
HRESULT CopyHere(string SourceObject,string NewName,IOleDs**
ppNewObject);
HRESULT MoveHere(string SourceObject,string NewName,IOleDs**
ppNewObject);
｝
【００３４】
属性
名前 記述
Filter 特定の目録に戻されるべきオブジェクトクラスに関するフィルタの配列。フィルタが空ならば、すべてのオブジェクトクラスのすべてのオブジェクトは戻される。各配列エントリは以下のフォーマットを有する。
<FilterEntry>::=<ClassName>
｜<ClassName>.<PropName>
｜<ClassName>.<FuncSetName>
｜<ClassName>.<FuncSetName>.<PropName>
｜<GUID>
｜"Provider Specific String"
Count フィルタをパスするコンテナ内のOleDs オブジェクトの数
＿NewEnum 収容されたオブジェクトのエニュメレータ
メソッド
名前 記述
GetObject オブジェクトのIOleDsインターフェースを、コンテナオブジェクト内のオブジェクトクラス及び相対的な名前によって識別されるこのコンテナオブジェクトに戻す。
Create このコンテナオブジェクト内に指定されたオブジェクトクラス及び相対的な名前のオブジェクトを作り、ポインタをIOleDsインターフェースに戻す。オブジェクトは、メソッドIOleDs::SetInfo が呼び出されるまでディレクトリサービス内に実際には作られないので、コミットされたプロパティはセットされるべきである。
Delete このコンテナオブジェクト内のオブジェクトクラスと相対的な名前によって識別されたオブジェクトを削除する。
CopyHere 指定されたオブジェクトと同一である新しいオブジェクトをこのコンテナオブジェクトに作り、IOleDsインターフェースへのポインタを新しいオブジェクトに戻す。NewName は、存在するならば、コンテナオブジェクト内にある新しいオブジェクトの名前を含む選択的なパラメータである。
MoveHere ソースオブジェクトがコピーの後で削除されることを除いて、メソッドCopyHereと同様である。
【００３５】
図８はメソッドIOleDsContainer::CopyHere のフローチャートである。このメソッドは、このコンテナオブジェクト内にある指定されたソースオブジェクトのコピーを作る。ステップ801 では、本メソッドは、コピーされるべきオブジェクトのオブジェクトクラスを決定する。ステップ802 では、本メソッドは、ファンクションCreateObjectを呼び出すことによって、決定されたオブジェクトのオブジェクトクラスをディレクトリサービス内に作る。ステップ803 では、本メソッドは、オブジェクトクラスのためのスキーマオブジェクトへのOleDs パスを検索する。ステップ804 では、メソッドはOleDs パスをスキーマオブジェクトに渡すファンクションOleDsGetObjectを呼び出し、OleDs スキーマオブジェクトのIOleDsインターフェースへのポインタを検索する。ステップ805 では、本メソッドは、IOleDsClass インターフェースへのポインタを検索するために、OleDs スキーマオブジェクトのメソッドIOleDs::QueryInterfaceを呼び出す。IOleDsClass インターフェースは、このオブジェクトクラスのために定義されたプロパティ名を検索するメソッドを提供する。ステップ806 では、本メソッドは、このスキーマクラスの必須のプロパティリストを検索するために、メソッドIOleDsClass::GetMandatoryProperties を呼び出す。ステップ807 では、本メソッドは、このクラスに関する追加のプロパティを検索するために、メソッドIOleDs::Propertiesを呼び出す。ステップ808〜811 では、本メソッドループ(method loops)は、プロパティの各値を、ソースOleDs オブジェクトから宛先OleDs オブジェクトまでコピーする。ステップ808 では、本メソッドは次のプロパティを選択し、最初から始める。ステップ809 では、全てのプロパティが既に選択されているならば、本メソッドはステップ812 に続き、他の場合は、本メソッドはステップ810 に続く。ステップ810 では、メソッドは、選択されたプロパティに関する値を検索するために、ソースOleDs オブジェクトのメソッドIOleDs::Get を呼び出す。ステップ811 では、本メソッドは宛先 IOleDs オブジェクトで検索された値をストアし、次のプロパティを選択するためにステップ808 にループする。ステップ812 では、メソッドはソースOleDs オブジェクトの属性を宛先OleDs オブジェクトにコピーし、リターンする。
図９は、メソッドIOleDs::Createのフローチャートである。ステップ901 では、本メソッドは、オブジェクトクラスを渡すディレクトリサービスのファンクションCreateObjectを呼び出し、そのオブジェクトクラスの新たに作られたオブジェクトへのハンドルを受信する。
【００３６】
IOleDsClass インターフェース
IOleDsClass インターフェースは、オブジェクトクラスの定義へのアクセスを提供するために、OleDs スキーマによって公開される。以下は、その属性とメソッドの記述を加えたインターフェースの定義である。
Interface IOleDsClass:IOleDs
｛
HRESULT get PrimaryInterface(string*GUID);
HRESULT get CLSID(string CLSID);
HRESULT put CLSID(string CLSID);
HRESULT get OID(string*OID);
HRESULT put OID(string OID);
HRESULT get Abstract(boolean*Abstract);
HRESULT put Abstract(boolean Abstract);
HRESULT get MandatoryProperties(Variant*Mandatory);
HRESULT put MandatoryProperties(Variant Mandatory);
HRESULT get DerivedFrom(Variant*pDerivedFrom);
HRESULT put DerivedFrom(Variant DerivedFrom);
HRESULT get Containment(Variant*pContainment);
HRESULT put Containment(Variant Containment);
HRESULT get Container(boolean*pContainer);
HRESULT put Container(boolean Container);
HRESULT get HelpFileName(string*pHelpFile);
HRESULT put HelpFileName(string HelpFile);
HRESULT get HelpFileContext(long*pHelpContext);
HRESULT put HelpFileContext(long HelpContext);
HRESULT Attributes(IOleDsCollection**ppAttributes)
｝
【００３７】
属性
名前 記述
CLSID このオブジェクトクラスに関してOLE DSオブジェクトを実行するコードのCLSID
OID このオブジェクトクラスを定義するネームスぺーススペシフィックオブジェクト識別子。これは、オブジェクトクラスのためのネームスペーススペシフィックOIDsを要求するネームスペースにおいて、OLE DSを介してスキーマ拡大を可能にするように提供される。
Abstract このオブジェクトクラスがアブストラクトであるかどうか指示するブール値
MandatoryProperties 記憶領域に書き込まれるべきオブジェクトクラスに設定されなければならないプロパティのリスト
Primary Interface このオブジェクトクラスのオブジェクトに関するプライマリインターフェース識別子。これは、IOleDsUserをサポートすることによって定義されるならば、例えば「user」クラスを定義するインターフェースに関するIID である。
DriverdFrom このオブジェクトクラスが得られる中間スーパークラスを示すOleDs パス列の配列
Container このオブジェクトクラスがコンテナであるかどうか決定するプロパティ
HelpFileName このオブジェクトクラスのオブジェクトについて更なる情報を含むヘルプファイルの名前
HelpFileContext このオブジェクトクラスで特定の情報を見つけることができるHelpFileName内のContext ID
メソッド
名前 記述
Attributes このプロパティの追加の属性[delete???] を説明するOleDs オブジェクトの集合をリターンする
IOleDsProperty インターフェース
OleDs はオブジェクトクラスの各プロパティに対応するOleDs プロパティオブジェクトを定義する。OleDs プロパティオブジェクトはプロパティの定義を検索するインターフェースを公開する。以下は、属性とメソッドの記述を加えたインターフェースの定義である。
Interface IOleDsProperty：IOleDs
｛
HRESULT get OleDsNames(Variant*pOleDsNames);
HRESULT get DsNames(Variant*pDsName);
HRESULT get OID(string OID);
HRESULT put OID(string*OID);
HRESULT get Syntax(string*pSyntax);
HRESULT put Syntax(string Syntax);
HRESULT get MaxRange(long*pMaxRange);
HRESULT put MaxRange(long MaxRange);
HRESULT get MinRange(long*pMinRange);
HRESULT put MinRange(long MinRange);
HRESULT get MultiValued(long*pMultiValued);
HRESULT put MultiValued(long MultiValued);
HRESULT Attributes(IOleDsCollection**ppAttributes)
｝
【００３８】
属性
名前 記述
OleDsNames OleDs がこのプロパティにアクセスすることができる名前を含む文字列の配列
DsNames 基礎をなすネームスペースがこのプロパティにアクセスすることができる名前を含むストリングの配列
OID このプロパティを定義するネームスペーススペシフィックオブジェクト識別子
Syntax このプロパティの構文を定義するスキーマシンタックスオブジェクトの相対的なパス。現在のスキーマコンテナに関連している。
MaxRange プロパティに指定した値の上限
MinRange プロパティに指定した値の下限
Normal このプロパティが標準的に複製されるべきかどうか決定する値
MultiValued このプロパティがマルチバリュー（multi-value ）であるかどうか決定する値
メソッド
名前 記述
Attributes このプロパティの追加の属性を説明するOLE DSオブジェクトの集合をリターンする
IOleDs<Class> インターフェース
OleDs は、IOleDs<class> と名付けられたインターフェースをサポートすることができる全てのオブジェクトクラスを定義し、ここで<class> はオブジェクトクラスの名前である。このインターフェースはメソッドを有し、オブジェクトクラスによってサポートされた各ファンクション集合は、そのファンクション集合のためのOlDsFunctionalSet オブジェクトに対するポインタをリターンする。
Interface IOleDsUser：IOleDs
｛
HRESULT get BusinessInfo
(IOleDs FS UserBusinessInfo**ppFuncSet);
｝：
【００３９】
OleDs オブジェクトクラス定義
OleDs は、コンテナオブジェクトとリーフオブジェクトの両方のための様々なオブジェクトクラスを定義する。OleDs は、コンテナオブジェクトのために以下のオブジェクトクラス定義する。
ネームスペーシズ（Namespaces）
ネームスペース（Namespace ）
国（Country ）
地域（Locality）
組織（Organization）
ドメイン（Domain）
組織ユニット（Organizational Unit ）
コンピュータ（Computer）
ファイルサービス（File Service）
OleDs は、リーフオブジェクトのために以下のオブジェクトクラス定義する。
ユーザ（User）
グループ（Group ）
エイリアス（Alias ）
サービス（Service ）
ポイントキュー（Point Queue ）
ポイントジョブ（Point Job ）
ポイントデバイスセッション（Point Device Session）
リソース（Resource）
ファイル共有（File Share）
ネームスペーシズオブジェクトは、ネームスペースオブジェクトのコンテナである。ネームスペーシズオブジェクトのインプリメンテーション（実装）は、OleDs の一部である。ネームスペーシズオブジェクトは、IOleDsネームスペーシズインターフェースを公開する。このインターフェースを以下に示す。
Interface IOleDsNamespaces：IOleDs
｛
get DefaultContainer(string *pDefault);
set DefaultContainer(string Default);
｝
ネームスペースオブジェクトは、所定のネームスペースに関する全てのOleDs オブジェクトソースであるコンテナオブジェクトである。国オブジェクトは、国に関するプロパティを有するコンテナオブジェクトである。地域オブジェクトは、地域（例えば、州）に関するプロパティを有するコンテナオブジェクトである。以下は、地域オブジェクトのプロパティを得て設定するインターフェースの定義である。
Interface IOleDsFSLocalityGeneralInfo:IDispatch
｛
HRESULT get Description(string*Description);
HRESULT put Description(string Description);
HRESULT get LocalityName(string LocalityName);
HRESULT put LocalityName(string LocalityName);
HRESULT get PostalAddress(string*pPostalAddress);
HRESULT put PostalAddress(string pPostalAddress);
HRESULT get SeeAlso(VARIANT*pSeeAlso);
HRESULT put SeeAlso(VARIANT Also);
HRESULT Access(IOleDsAccess**ppFuncSetAccessControl);
HRESULT PropAccess(string PropName, IOleDsAccess **ppPropAccess
Control);
｝
メソッド
名前 記述
Access アクセスコントロール依存オブジェクトの IOleDsAccess インターフェースにポインタをリターンする。ここで、 IOleDsAccess インターフェースは、本インターフェース上でアクセス制御を表わす。
PropAccess PropNameによって指示されるとき、アクセスコントロール依存オブジェクトの IOleDsAccess インターフェースにポインタをリターンする。ここで、 IOleDsAccess インターフェースは、本インターフェース上でアクセス制御を表わす。
【００４０】
属性
名前 記述
Description 地域を説明するテキスト
LocalityName 地域名。地域名はコンテナが物理的に配置される地図エリアを特定する。
PostalAddress 地域のメイン郵便アドレス
SeeAlso このオブジェクトに関連し得る他のディレクトリオブジェクト名の配列
OleDs 定義されたオブジェクトクラスの各々は、そのオブジェクトクラスのオブジェクトに関するプロパティを定義する。ドメインオブジェクトは、コンピュータシステムのドメインに対応し、且つそのドメインオブジェクトに関するプロパティ（例えば、パスワード）を備えたファンクション集合を有する。組織ユニットオブジェクトは、会社等のエンティティ (entity)に対応する。コンピュータオブジェクトは、ドメイン(domain)のコンピュータに対応する。ユーザオブジェクトは、ビジネス情報、アカウント制限、アカウント統計、及び、ユーザを記述するための他の情報ファンクショナル集合を有する。ビジネス情報ファンクション集合は、国、部、課、マネージャ、オフィスの場所等のビジネスの説明に関するプロパティを含む。アカウント制限ファンクション集合は、無効にされたアカウント、ユーザがログインすることができる時間数等のユーザのアカウントの一般的な特徴を説明したプロパティを含む。アカウント統計ファンクショナン集合は、パスワードが変更された最後の時間及びユーザがアカウントにログインした最後の時間のようなユーザアカウントの統計を特定したプロパティを有する。他の情報ファンクショナル集合は、電子メールアドレス、ホームディレクトリ等の他のユーザ情報に関するプロパティを含む。
【００４１】
OleDs のクライアントの例
図１０は、全てのネームスペーシズ(namespaces)を表示する手順のフローチャートである。この手順は、OleDs のクライアントが全てのネームスペーシズの名前を検索するやり方を図示している。ステップ1001では、ファンクション CoGetClassObject を呼び出し、OleDs ネームスペーシズオブジェクトのためのクラス、及びIClassFactory インターフェースに関するインターフェース識別子を渡す。本ファンクションは、OleDs ネームスペーシズのためのクラスファクトリインターフェースにポインタをリターンする。ステップ1002では、メソッド IClassFactory::CreateInstance を呼び出して、IOleDsContainer インターフェースのためのインターフェース識別子を渡す。本メソッドは、OleDs ネームスペーシズオブジェクトのインスタンスを作り、ポインタをIOleDsContainer インターフェースにリターンする。ステップ1003では、メソッド IOleDsContainer::get ＿ NewEnum を呼び出し、ネームスペーシズオブジェクトのためのエニュメレータ（ enumerator ）を検索する。ステップ1004〜1008では、各ネームスペースを列挙しながらループし、ネームスペースを表示する。ステップ1004では、メソッド IEnumerator::Next を呼び出し、ネームスペースオブジェクトのためのIUnknownインターフェースに対するポインタを検索する。ステップ1005では、全てのネームスペーシズが既に列挙されてしまっているならば本手順はリターンし、そうでなければステップ1006に続く。ステップ1006では、メソッド IUnknown::QueryInterface を呼び出し、ネームスペースオブジェクトのためのIOleDsインターフェースに対するポインタを検索する。ステップ1007では、メソッド IOleDs::get ＿ Name を呼び出し、ネームスペースオブジェクトと関係している名前を検索する。ステップ1008では、検索された名前を表示し、次のネームスペースオブジェクトを列挙するためにステップ1004にループする。
【００４２】
以上、好ましい実施形態に関して本発明を説明してきたが、本発明を本実施形態に限定すべきではない。本発明の精神の範囲内での変更は当業者にとって明らかであろう。本発明の範囲は特許請求の範囲によって定義される。
【図面の簡単な説明】
【図１】 ディレクトリサービスのサンプル階層構造を図示する。
【図２】 オブジェクトを表わすのに使用される典型的なデータ構造を図示する。
【図３Ａ】 OleDs の階層構造を図示する。
【図３Ｂ】 ディレクトリサービスにおけるOleDs オブジェクトとそれらに対応するオブジェクトとの間の関係を図示する。
【図４】 本発明を実施するために構成されたコンピュータシステムのブロック図である。
【図５】 OleDs の割り当てファンクションである、ファンクションOleDsGetObjectのフローチャートである。
【図６】 メソッドIOleDs::GetInfo のフローチャートである。
【図７】 メソッドIOleDs::Get のフローチャートである。
【図８】 メソッドIOleDsContainer::CopyHere のフローチャートである。
【図９】 メソッドIOleDs::Createのフローチャートである。
【図１０】 全てのネームスペースを表示するためのプロシージャのフローチャートである。
【符号の説明】
400 コンピュータシステム
401 メモリ
402 中央処理装置
403 I/O インターフェース
404 記憶装置
405 表示装置
406,407 クライアント
408,411,414 OleDs オブジェクト
409,412,415 ディレクトリサービス
410,413,416 オブジェクト
【発明の属する技術分野】
この発明はコンピュータベースのディレクトリサービスに関し、特に、ディレクトリサービスに同じようにアクセスするための方法及びシステムに関する。
【０００２】
【従来の技術】
コンピュータシステムは一般的には、コンピュータシステム及びそのユーザに関する多量のデータをストアし且つ保持する。例えば、コンピュータシステムはコンピュータシステムのユーザの名前、電子メールアドレス、及び、電話番号を保持する。コンピュータシステムはまた、コンピュータシステムに接続された種々のプリンタに関する情報も保持する。この情報は、プリンタ特性（例えば、レーザ及びカラー）及び各プリンタを使用するのに許可された使用者の名前を含む。「クライアント」として知られる種々の異なるタイプのコンピュータプログラムは、この情報にアクセスする必要がある。例えば、あるクライアントは、プリンタが書類をカラーでプリントするのに使用されることができることを判断するのに必要であるコンピュータプログラムであってよい。別のクライアントは、例えば、新しく追加されたプリンタに関する情報を反映するように、システム管理者が情報を更新することができるコンピュータプログラムであってよい。コンピュータシステムは、伝統的には、かかる情報を様々な位置及びフォーマットにストアしてきた。例えば、プリンタに関する情報はコンフィギュレーションファイルにストアされ、ユーザに関する情報はデータベースにストアされたりする。従って、一般的には、クライアントを開発するプログラマはこの情報にアクセスする仕方を知ることはもちろんとして、この情報を探すための場所を知ることさえ困難であった。
【０００３】
あるコンピュータシステムは、この情報をストアし且つ保持するのに有用なディレクトリサービスを提供する。ディレクトリサービスは、クライアントがネットワークにアクセス可能な情報のリポジトリを提供する。一般的には、ディレクトリサービスは、情報が「オブジェクト」として保持されているもの（例えば、ユーザ、プリンタ、又は、アクセスグループ）を参照する。ディレクトリサービスは、このようなオブジェクトの階層をディレクトリに構成する。即ち、コンテナオブジェクトと呼ばれるあるオブジェクトは、コンテナに格納されたオブジェクトを参照する他の種々のオブジェクトを包含する。例えば、共通アクセス権をリソースに対して共有するユーザを含むアクセスグループは、コンテナに格納されたオブジェクトのユーザを包含するコンテナオブジェクトである。ディレクトリサービスが情報を保持する各オブジェクトは、クライアントがオブジェクトを識別することができる固有の識別子（例えば、名前）を有する。ディレクトリサービスは、元々は、コンピュータシステムに関する情報を保持するように開発されたのだが、コンピュータシステムと関係が無い情報を保持するのに使用することもできる。例えば、飛行機の構成要素及びサブコンポーネントのための部品リストを保持するために、飛行機製造業者がディレクトリサービスを使用することができる。
【０００４】
図１はディレクトリサービスの階層構造を表す一例である。各ブロックは特定の「オブジェクトクラス」のオブジェクトを表わす。例えば、会社を表わすオブジェクトは、「会社（Company)」と名付けられたオブジェクトクラスを有する。各オブジェクトクラスは、そのオブジェクトクラスのオブジェクトプロパティ(property)を定義する。例えば、前記会社オブジェクトクラスは、プロパティとして「名前」及び「住所」を定義することができる。各オブジェクトは、オブジェクトクラスのために定義された各プロパティに関するプロパティ値を有する。例えば、会社オブジェクトクラスのオブジェクトは、名前のプロパティのために、プロパティ値「ＭＳ」を有することができる。ブロック101 は会社オブジェクトクラスのオブジェクトに対応し、名前及び住所のプロパティに関する値を有する。ブロック102 は、部門オブジェクトクラスのオブジェクトに対応し、部門の名前（例えば、「システム（System) 」）に関する値を有する。ブロック103 はユーザオブジェクトクラスのオブジェクトに対応し、ユーザの電子メールアドレスに関する値を有する。ディレクトリサービスは階層的に構成されているので、ルート(root)からオブジェクトまでのパス(path) 情報によって、各オブジェクトを一意的に識別することができる。例えば、オブジェクト102 は、パス「Company=MS＼Division=Systems」によって一意的に識別される。ディレクトリサービスは、ネームスペース（namespace ）と呼ばれる概念的な有限空間を提供し、任意の名前を解読することができる。ディレクトリサービスは、ディレクトリのオブジェクトに対するパスを明瞭に解読する。
【０００５】
種々のベンダは、ディレクトリサービスシステムを提供する。典型的には、各ベンダは、クライアントがそのディレクトリサービスにアクセスすることを可能にするために、アプリケーションプログラミングインターフェース（ＡＰＩ）を設計し且つインプリメント（実装）する。したがって、各ディレクトリサービスシステムは、非常に異なるＡＰＩセット（集合）を有しており、且つ、そのようなＡＰＩセットを有するのが一般的である。クライアントが異なるディレクトリサービスシステムを使用する必要がある場合、例えば、クライアントはパーソナルコンピュータ及びメインフレームコンピュータを含む環境で作動するので、クライアントのプログラマは、各ディレクトリサービスのＡＰＩセットについて知っておく必要があり、ＡＰＩセットの各々をサポートするようにクライアントを設計する必要がある。
【０００６】
各ＡＰＩセットはベンダ固有であるけれども、一般的にはＡＰＩセットは類似した機能性を提供する。一般的には、ＡＰＩセットは、オブジェクトのプロパティ値にアクセスするためのファンクション（関数）と、新しいオブジェクトクラスを定義するためのファンクションとを含む。オブジェクトを処理するファンクションは、例えば、OpenObject、ReadObject、WriteObject 、ListObject、CloseObject 、CreateObject及びDereteObjectである。オブジェクトに対する識別（例えば、パス情報）がファンクションOpenObjectに渡され、ファンクションOpenObjectは、そのオブジェクトを識別するハンドル(handle)をリターンする。その後、このハンドルはクライアントによって使用されることで、ディレクトリサービスに対するオープンオブジェクトを識別する。ファンクションOpenObjectはオブジェクトを識別するために識別を使用し、次いで、識別されたオブジェクトのプロパティを見つけ出す。オープンオブジェクト、及び、検索されるべきそのオブジェクトのプロパティの名前リストへのハンドルが、ファンクションReadObjectにパスされる。ファンクションReadObjectは、それらのプロパティに関する現在のプロパティ値をリターンする。オープンオブジェクトと、プロパティ名及びプロパティ値の組のリストへのハンドルが、ファンクションWriteObject にパスされる。ファンクションWriteObject は、前記組のプロパティ値に対するオープンオブジェクトにおいて名付けられた各プロパティを設定する。オープンオブジェクトへのハンドルがファンクションListObjectに渡され、ファンクションListObjectはオープンオブジェクト内に格納された各オブジェクトの識別を有するリストをリターンする。オープンオブジェクトへのハンドルがファンクションCloseObject に渡され、そのハンドルでもはやアクセスすることができないようにするため、ファンクションCloseObject はオブジェクトを閉じる。オブジェクトクラスがファンクションCreateObjectに渡され、ファンクションCreateObjectは、オープンオブジェクト内に格納されているオブジェクトクラスのオブジェクトを作り、ハンドルをコンテナに格納されたオブジェクトにリターンする。オープンオブジェクトへのハンドルがファンクションDeleteObjectに渡され、ファンクションDeleteObjectは、オープンオブジェクトをそのコンテナオブジェクトから除去する。
【０００７】
オブジェクトクラスを定義するためのファンクションは、CreateObjectClass 、DeleteObjectClass 、CreateProperty、DeleteProperty、AddPropertyToObjectClass、DeletePropertyFromObjectClass 、及びListPropertiesOfObjectClass である。新しいオブジェクトクラスの名前がファンクションCreateObjectClass に渡され、ファンクションCreateObjectClass は新しいオブジェクトクラスを作る。いったんオブジェクトクラスが作られたら、次にクライアントはそのオブジェクトクラスのオブジェクトを作ることができる。プロパティの名前及びプロパティタイプ（例えば、整数又は列）がファンクションCreatePropertyに渡され、ファンクションCreatePropertyはそのプロパティタイプ（例えば、「文字列」のプロパティタイプを有する「住所」のプロパティ名）のプロパティを作る。オブジェクトクラスの名前及びプロパティの名前がファンクションAddPropertyToObjectClassに渡され、ファンクションAddPropertyToObjectClassは名付けられたオブジェクトクラスのプロパティとして、ネーミングされたプロパティを加える。オブジェクトクラスの名前がファンクションListPropertiesOfObjectClass に渡され、ファンクションListPropertiesOfObjectClass はそのオブジェクトクラスに加えられているプロパティのリストをリターンする。ファンクションDeleteObjectClass 、DeleteProperty、及びDeletePropertyFromObjectClass は、それらの名前によって示される動作を行う。
【０００８】
後述するように、本発明はオブジェクト指向技術を使用し、従って、周知のオブジェクト指向プログラミング技術の概略を提供するものである。（「オブジェクト」という用語は、異なる文脈において使用された場合、多くの異なる意味を有する。そこで、この従来技術の以降の説明においては、「オブジェクト」という用語を、インメモリデータ構造に 言及するために、オブジェクト指向の意味において使用されるものとする。）オブジェクト指向プログラミング言語において共通する２つの特徴は、データ隠蔽と、データ型の承継に関するサポートである。データ隠蔽は、ファンクション（関数）とデータを結びつけることを指す。承継は、他のデータ型があることから、データ型を宣言することができることを指す。Ｃ++言語では、これらデータ隠蔽及び承継がクラスの使用を介してサポートされるものである。クラスは、ユーザ定義による型である。クラス宣言は、クラスのデータメンバ及びファンクション（関数）メンバを記述する。ファンクションメンバはまた、クラスのメソッドとして示される。クラスのデータメンバとファンクションメンバとは、そのファンクションがクラスのインスタンスで機能するように一緒に結びつけられる。クラスのインスタンスはまた、クラスのオブジェクトと称される。したがって、クラスは、類似のプロパティと共通の処理動作を有するオブジェクトのグループのための定義を提供するものである。
【０００９】
特定の型のオブジェクト（クラス）のための記憶領域を割り当てるために、オブジェクトがインスタンスされる。ひとたびインスタンスされると、特定のオブジェクトのデータメンバに対するデータを指定することができる。また、ひとたびインスタンスされると、特定のオブジェクトのファンクションメンバがアクセスのために呼び出され、そしてデータメンバを操作する。その結果、このやり方の場合、ファンクションメンバは、オブジェクトの処理動作をインプリメント（実装）し、そしてオブジェクトはデータ及び処理動作を単一のエンティティ(entity) に隠蔽するための構造を提供する。
承継のコンセプトをサポートするために、クラスは（他のクラスの宣言に基づいて）他のクラスから派生される。派生クラスとは、その基本クラスの特徴（データメンバ及びファンクションメンバ）を承継するクラスである。別のクラスの特徴を承継するクラスが派生クラスである。別のクラスの特徴を承継しないクラスがプライマリ（ルート）クラスであり、その特徴が別のクラスによって承継されるクラスが基本クラスである。派生クラスは種々のクラスの特徴を承継することができる。即ち、派生クラスは幾つかの基本クラスを有しても良い。
【００１０】
クラスはまた、そのファンクションメンバがバーチャル(virtual)であるかどうかを指定することができる。ファンクションメンバがバーチャルであると宣言されると、派生クラスにおいて同じ名前及び同じ型のファンクションによってそのファンクションがオーバーライド (override) されることを意味する。バーチャルファンクションがインプリメンテーション（実装）を提供することなく宣言されるならば、そのバーチャルファンクションは ピュア（純粋 )バーチャルファンクションとして参照される。ピュアバーチャルファンクションは、ピュア指定子 (pure specifier)「＝０」で宣言されたバーチャルファンクションである。仮にクラスがピュアバーチャルファンクションを指定するならば、ファンクションメンバが呼び出される前に、いかなる派生クラスもそのファンクションメンバのためにインプリメンテーション（実装）を指定する必要がある。少なくとも１つのピュアバーチャルファンクションメンバを含むクラスが、アブストラクトクラス（抽象クラス）である。
【００１１】
図２は、オブジェクトを表わすのに使用される典型的なデータ構造を図示したブロック図である。オブジェクトは、オブジェクトの処理動作を実装するインスタンスデータ（データメンバ）及びファンクションメンバをもつ。オブジェクトを表わすのに使用されるデータ構造は、インスタンスデータ構造201 と、バーチャルファンクションテーブル202 と、ファンクションメンバ203,204,205 を含む。インスタンスデータ構造201 は、バーチャルファンクションテーブル202に対するポインタ及びデータメンバを含む。バーチャルファンクションテーブル202 は、オブジェクトのために定義された各バーチャルファンクションメンバに関するエントリを含む。各エントリは、対応するファンクションメンバをインプリメントするコードへのリフェレンス（参照）を含む。このサンプルオブジェクトのレイアウトは、本願に組み入れられた「オブジェクト指向プログラミング言語に関するコンパイラにおけるバーチャルファンクション及びバーチャルベースをインプリメントするための方法」と題する、米国特許第5,297,284 号に説明されたモデルに一致する。以下の説明では、Ｃ++プログラミング言語によって定義されるクラスのインスタンスとしてオブジェクトを説明する。当業者であれば、他のオブジェクトモデルが他のプログラミング言語を使用して定義され得ることは明らかであろう。
【００１２】
オブジェクト指向技術を用いることの利点は、これらの技術がオブジェクトの共有を容易にするために使用できることである。例えば、例示されたオブジェクトのファンクションメンバ（「サーバプログラム」）をインプリメント（実装）するプログラムは、別のプログラム（「クライアントプログラム」）とオブジェクトを共有することができる。任意のクラスのオブジェクトがクライアントプログラムで共有されようにするため、クライアントプログラムを必要とすることなくオブジェクトにアクセスできるインタフェースを定義する。そして、コンパイル時点でそのクラス定義にアクセスする。インターフェースは、論理的に関連したファンクションメンバの集合である。Ｃ++の場合、インターフェースはデータメンバを有しないアブストラクトクラスであり、そしてそのバーチャルファンクションは全てピュアである。したがって、インターフェースは２つのプログラムが通信するための公開プロトコルを提供する。インターフェースは、典型的には派生のために使用される。即ち、プログラムは、クラスを派生させるインターフェースのためのインプリメンテーション（実装）を提供するクラスを定義（インプリメント）する。その後、オブジェクトはこれらの派生クラスのインスタンスとして作られる。特定のインターフェースをインプリメントする派生クラスからインスタンスされたオブジェクトは、インターフェースを「サポート」すると言う。オブジェクトは、所望の機能に依存する１又はそれ以上のインターフェースをサポートする。
【００１３】
クライアントプログラムがオブジェクトを共有することを望む場合、クライアントプログラムはオブジェクト（派生クラスコード）のためのインターフェースをインプリメントするコードにアクセスする必要がある。ワシントン州レッドモンドのマイクロソフトコーポレーションによって確立されたＯＬＥ2.01環境では、派生クラスコード（または、クラスコードとして称する。）にアクセスするために、各クラスのインプリメンテーションは、固有のクラス識別子（「CLSID 」）が与えられる。ＯＬＥ2.01は、『インサイドＯＬＥ』第２版（マイクロソフト発行、1995年、Kraig Brockschmidt著）に記述されている。例えば、マイクロソフトコーポレーションによって開発されたスプレッドシートオブジェクトをインプリメントするコードは、「MSSpreadsheet 」というクラス識別子を有するのに対して、別の会社によって開発されたスプレッドシートオブジェクトをインプリメントするコードは、「LTSSpreadsheet」というクラス識別子を有する。各コンピュータシステムの保存性レジストリは、クラスをインプリメントするコードに各CLSID をマップするということを保持する。典型的には、スプレッドシートプログラムがコンピュータシステムにインストールされたとき、保存性レジストリは、スプレッドシートオブジェクトのそのクラスの使用可能性を反映するために更新される。スプレッドシート開発者がスプレッドシートオブジェクトによってサポートされるべきインターフェースによって定義された各ファンクションメンバをインプリメントする限り、及び、保存性レジストリが保持されている限り、クライアントプログラムは、共有されたスプレッドシートオブジェクトのファンクションメンバにアクセスすることができ、この場合、サーバプログラムはファンクションメンバをインプリメントしたか、或いはどのようにしてインプリメントされているかが考慮されなくてよい。
【００１４】
オブジェクトはあるインターフェースをサポートし、他のインターフェースをサポートしないので、クライアントプログラムは、特定のオブジェクトが特定のインターフェースをサポートするかどうかを実行時に判断する必要がある。この判断を可能にするために、全てのCOM オブジェクトは、ファンクションメンバを含むIUnknownインターフェースと、オブジェクトのためにどのインタフェースがインプリメントされたかを指示するQueryInterfaceとをサポートする。QueryInterfaceメソッドは以下のように定義される：
virtual HRESULT QueryInterface(REFID iid, void**ppv)=0;
（REFID 型の）パラメータiid におけるインターフェース識別子がQueryInterfaceメソッドに渡され、QueryInterfaceメソッドは、パラメータppv においてポインタを指定されたインターフェース「iid 」のインプリメンテーションにリターンする。したがって、QueryInterfaceメソッドは、典型的には、それが属するオブジェクトの使用可能な全てのインターフェースについて知るためにコード化される。オブジェクトがそのインターフェースをサポートしないならば、QueryInterfaceメソッドは偽をリターンする。タイプHRESULT は、所定のステータスを示す。
【００１５】
IUnknownインターフェースはまた、メソッド AddRef 及び Release を定義し、そのメソッドはリファレンスカウントをインプリメントするのに使用される。インターフェースに対して新しいリファレンスが作られるときはいつでも、AddRefメソッドはオブジェクトのリファレンス（参照）カウントを増加させるために呼び出される。リファレンスがもはや必要とされないとき、Release メソッドがオブジェクトのリファレンスカウントを減少させるために呼び出され、そしてリファレンスカウントがゼロに至るとき、オブジェクトは開放される。
【００１６】
【課題を解決するための手段】
本発明はＯＬＥインターフェースに関する定義と、複数のディレクトリサービスに同じようにアクセスすることができるプロバイダソフトウェアのためのモデルとを提供する。各ディレクトリサービスプロバイダは、そのディレクトリサービスのオブジェクトに関する情報を管理する。ディレクトリサービスがオブジェクトのために管理する情報のタイプは、そのオブジェクトのオブジェクトクラスによって定義される。オブジェクトクラスは、ディレクトリサービスがそのオブジェクトクラスのオブジェクトのために管理するプロパティ（即ち、情報）を定義する。各プロパティは、プロパティ名とプロパティタイプを有する。ディレクトリサービスは、各オブジェクトのオブジェクトクラスによって定義された各プロパティに関するプロパティ値を有する。ディレクトリサービスシステムは、スキーマブラウジング部 (schema browsing component)、名前解読部 (name resolving component)、結合部 (binding component)、及び、拡張部 (extending component) を含む。スキーマブラウジング部は、各ディレクトリサービスの各オブジェクトクラスにおける各プロパティのプロパティ名及びプロパティタイプを検索することを制御する。ディレクトリサービスシステムのクライアントは、オブジェクトクラスのプロパティ名及びプロパティタイプを検索するために、スキーマブラウジング部を使用する。名前解読部は、オブジェクトの固有識別子をディレクトリサービス内で受信することや、オブジェクトをディレクトリサービス内で見つけ出すことを制御する。結合 (binding) 部は、ディレクトリサービス内で見つけ出されたオブジェクトを表わすインメモリ(in-memory)オブジェクトと関連づけることを制御する。拡張部は、各ディレクトリサービスのために、新しいオブジェクトクラス及び新しいプロパティを定義することを制御する。ディレクトリサービスシステムのクライアントは、新しいオブジェクトクラス及び新しいプロパティを定義するために拡張部を使用する。
【００１７】
【発明の実施の形態】
本発明は、種々の異なるディレクトリサービスに同じようにアクセスするためのフレームワークを提供する。好ましい実施形態では、OleDs と称されるディレクトリサービスシステムがアーキテクチャを提供し、このアーキテクチャにより、クライアントが、OleDs オブジェクト、属性、及びインターフェースの単一で共通のセットを使用しながら様々なディレクトリサービスのコンテンツにアクセスすることを可能にする。OleDs オブジェクトは、ディレクトリサービスのオブジェクト、及びディレクトリサービスのオブジェクトクラスに対応するインメモリデータ構造(in-memory data structure)である。OleDs オブジェクトがオブジェクトに対応するとき、それはそのオブジェクトのプロパティ値及びメソッドにアクセスするインターフェースを提供する。OleDs オブジェクトがオブジェクトクラスに対応するとき、それはそのオブジェクトクラスの定義にアクセスするインターフェースを提供する。ディレクトリサービスの各プロバイダは、ＡＰＩセットの処理動作をこれらOleDs インターフェースの処置動作にマップするディレクトリサービスに関するインターフェースのインプリメンテーションを提供する。この方法では、OleDs アーキテクチャを使用するために開発されたクライアントが、ディレクトリサービスのＡＰＩセットに相違があるにもかかわらず、これらディレクトリサービスの各々にアクセスすることができる。
【００１８】
OleDs は、「ネームスペース」コンテナ（ "namespaces" container ）と称される、ルートコンテナオブジェクト内にあるすべてのディレクトリサービスをモデル化する。図３は、ネームスペースコンテナを図示したものである。ネームスペーシズ（namespaces）コンテナ内のオブジェクトは、種々のディレクトリサービスを表わす。OleDs は、ネームスペースコンテナ内に格納されたディレクトリサービスを列挙するためのインターフェースを提供する。格納された各ディレクトリサービスは、OleDs ネームスペースコンテナオブジェクトによって表わされる。クライアントは、ディレクトリサービスの存在に気がつくようなインターフェースを用いることができ、そしてディレクトリサービスのオブジェクトクラスの定義を決定するためにそのスキーマにアクセスすることができる。スキーマはディレクトリサービスのオブジェクトクラスの定義を含む。インターフェースがOleDs によって提供されることを介して、クライアントはコンパイル時で未知であったディレクトリサービスの存在及びコンテンツを実行時に発見することができる。
【００１９】
典型的には、各ディレクトリサービスがそのオブジェクトをネーミングする独自の規定を有するので、OleDs は、様々なディレクトリサービスにある各オブジェクトと競合することなく一意的に識別する統一ネーミング規定（uniform naming convention ）を提供する。固有の識別子は、OleDs パスと称される。OleDs パスは、ディレクトリサービスと、識別されたオブジェクトにアクセスするようにオープンにされる必要があるネスト型の (nested)コンテナオブジェクトのセットとを識別する文字列である。OleDs は以下のようなフォーマットを有する：
@NamespaceIdentifier!<namaspace path to object>
又は
NamespaceIdentifier://<namespace path to object>
「NamespaceIdentifier 」はディレクトリサービスを一意的に識別する。「! 」又は「: 」の後の列は、ディレクトリサービスに依存するフォーマット内にある。即ち、各ディレクトリサービスはその独自フォーマットを定義することができる。
【００２０】
OleDs は、OleDs パス (path) と、OleDs パスが識別するオブジェクトに一致するOleDs オブジェクトとを結びつけるための結合ファンクション (binding function)を提供する。OleDs パスがこの結合ファンクションに渡され、そして結合ファンクションはオブジェクトに対応するOleDs オブジェクトにポインタをリターンする。OleDs オブジェクトと結びつけるために、結合ファンクションは、OleDs パスからのネームスペース識別子を構文解析する。結合ファンクションは、識別されたネームスペースへのアクセスをインプリメントするコード（例えば、ダイナミックリンクライブラリ）を検索するために、このネームスペース識別子を使用する。（OleDs は、OleDs インターフェースのインプリメンテーションの位置を登録するディレクトリサービスプロバイダのためのレジストリを維持する。）
次に、結合ファンクションは検索されたコードを呼び出して、OleDs パスを渡す。呼び出されたコードは、識別されたオブジェクトにアクセスし、且つOleDs インターフェースによって定義された処理動作をインプリメントするために、ディレクトリサービスのＡＰＩセットを使用する。
【００２１】
OleDs は、各ディレクトリサービスのオブジェクトを、OleDs コンテナオブジェクト又はOleDs リーフ(leaf)オブジェクトの何れかとしてモデル化する。ディレクトリサービスのコンテナオブジェクトにアクセスするために、ディレクトリサービスのプロバイダによって提供されたインプリメンテーションを有するOleDs コンテナオブジェクトがインスタンスされる。同様に、ディレクトリサービスのリーフオブジェクトにアクセスするために、ディレクトリサービスのプロバイダによって提供されたインプリメンテーションを有するOleDs リーフオブジェクトがインスタンスされる。各OleDs オブジェクトは、ディレクトリサービスの対応オブジェクトのプロパティにアクセスするためのインターフェースを公開する。各OleDs コンテナオブジェクトはまた、インターフェースを公開し、このインタフェースを介してクライアントが包含されたオブジェクトにアクセスできるようにする。
【００２２】
図４は、ディレクトリサービスにおける、OleDs オブジェクトと、それらの対応オブジェクトとの間の関係を図示したものである。各ディレクトリサービスプロバイダは、OleDs オブジェクトによって公開された各インターフェースのインプリメンテーションを提供する。これらのインプリメンテーションは、プロバイダのＡＰＩセットに関する処理動作をOleDs インターフェースの処理動作にマッピングすることに影響をもたらす。したがって、各クライアントは、OleDs インターフェースのプロバイダ・インプリメンテーションを使用して、複数のディレクトリサービスに同じようにアクセスすることができる。
ディレクトリサービスのオブジェクトにアクセスするクライアントを助けるために、OleDs は、各ディレクトリサービスのスキーマを表わすモデルを定義する。概念的に言えば、各オブジェクトクラスのためのスキーマオブジェクトを含むスキーマコンテナオブジェクトを有するとき、各ディレクトリサービスが閲覧 (view) される。スキーマオブジェクトは、オブジェクトクラスのプロパティを定義する。スキーマコンテナは、ネームスペース内にある所定の名前（例えば、「schema」）を指定する。スキーマコンテナにアクセスするため、クライアントはOleDs 結合ファンクションを使用して、スキーマのOleDs パス（例えば、「@WinNTDS!Schema 」）を渡す。OleDs 結合ファンクションは、スキーマコンテナオブジェクトに対応するOleDs コンテナオブジェクトに対して、ポインタをリターンする。クライアントは、格納されたスキーマオブジェクトを列挙するために、OleDs コンテナオブジェクトのインターフェースを使用することができる。この方法では、クライアントは、様々なオブジェクトクラスの定義を実行時に決定することができる。更に、クライアントは、スキーマオブジェクトをスキーマコンテナオブジェクトに加えることによって、追加のオブジェクトクラスを定義することができる。
【００２３】
OleDs は、ディレクトリサービスＡＰＩセットの処理動作を、OleDs インターフェースの処理動作にマッピングするインプリメンテーションを容易にするために、幾つかのオブジェクトクラスを予め定義する。特に、OleDs は、組織的な機関及び国といった、共通のコンテナオブジェクトのためのオブジェクトクラス定義や、ユーザ或いはリソースといった共通のリーフオブジェクトに関するオブジェクトクラス定義を提供する。
OleDs は、デフォルトネームスペース又はディレクトリサービスの概念を定義する。デフォルトネームスペースは、ネームスペースがOleDs パス内に指定されていない場合に、クライアントが使用することを望むネームスペースである。クライアント又はユーザのためのデフォルトネームスペースの識別は、典型的には、レジストリにストアされ、クライアント又はユーザによってインデックス付けされるであろう。
【００２４】
OleDs はまた、クライアントが新たに定義したオブジェクトクラスのオブジェクトを、ディレクトリサービスに加えることを可能にするために、各プロバイダによって実行されるデフォルトOleDs オブジェクトのコンセプトを定義する。典型的には、ディレクトリサービスプロバイダは、ディレクトリサービス内にある各オブジェクトクラスに関するOleDs オブジェクトのインプリメンテーションを提供する。例えば、プロバイダは、コンピュータオブジェクト及び会社オブジェクトのためのオブジェクトクラスに関する異なるインプリメンテーションを提供しうる。各インプリメンテーションは、対応オブジェクトクラスのためにインプリメンテーションのプロパティが定義されていることを知っており、ＡＰＩセットに要求してプロパティの値を検索することができる。しかしながら、クライアントが新しいオブジェクトクラスを実行時に定義するならば、対応のインプリメンテーションはないであろう。その結果、そのディレクトリサービスのために新しいオブジェクトクラスが定義されることを許可する各プロバイダはまた、デフォルトOleDs オブジェクトのインプリメンテーションを提供する。クライアントが、インプリメンテーションをもたないオブジェクトのためにOleDs オブジェクトをインスタンスする要求をするときはいつでも、デフォルトOleDs オブジェクトがインスタンスされる。デフォルトOleDs オブジェクトが対応のオブジェクトクラスの名前を含み、それはオブジェクトクラスの定義をスキーマから検索するのに使用される。この定義を使用することで、デフォルトOleDs オブジェクトは、ディレクトリサービスの対応オブジェクトにアクセスすることができる。
【００２５】
図３Ａは、OleDs の階層構造を図示するブロック図である。階層は、「ネームスペーシズ（Namespaces）」と称されるルート(root)コンテナを含む。ネームスペーシズコンテナは、各ディレクトリサービスのネームスペースを論理的に含む。図３Ｂは、OleDs のアーキテクチャを図示するブロック図である。ディレクトリサービスの各プロバイダは、プロバイダのＡＰＩセットの処理動作をOleDs インターフェースの処理動作にマッピングすることをインプリメントする。各OleDs コンテナオブジェクトは、ディレクトリサービスのコンテナオブジェクトに対応し、そして各OleDs リーフオブジェクトは、ディレクトリサービスのリーフオブジェクトに対応する。
OleDs は、OleDs オブジェクトに対する、クライアントの早期結合 (early binding)と遅い結合 (late binding)の両方を提供する。早期結合は、クライアントの開発者が各オブジェクトのプロパティ名をコンパイル時に知ることを意味する。したがって、クライアントは、プロパティを「getting 」及び「putting 」するメソッド（例えば、「ｇｅｔ＿Ａｄｄｒｅｓｓ」又は「ｐｕｔ＿Ｎａｍｅ」）を直接使用して、これらのプロパティからそれらの値にアクセスするようにプログラムすることができる。各OleDs オブジェクトは、クライアントが実行時に（即ち、遅い結合）プロパティを結び付けることを可能にする、IDispatch インターフェース（ Ole 2.01 で定義されている）を公開する。
【００２６】
各OleDs オブジェクトはIOleDsインターフェースを公開する。このIOleDsインターフェースは、ディレクトリサービスにおいて、対応オブジェクトのプロパティにアクセスするメソッドと一緒に、OleDs オブジェクトの様々な属性を定義する。（以下においては、「プロパティ（property）」という用語はディレクトリサービス内のデータを指し、「属性（attribute ）」という用語は、OleDs によって定義された、OleDs オブジェクトに関するデータを指す。）コンテナである各OleDs オブジェクトはまた、IOleDsContainer インターフェースを提供する。IOleDsContainer インターフェースは、コンテナオブジェクトに関係する様々な属性、及び操作されたコンテナオブジェクトのためのメソッドを定義する。更に、各OleDs オブジェクトは、IOleDs<class> 又はIOleDs<class>operations と名づけられたインターフェースを任意に提供することができる。この場合、<class> はディレクトリサービスにおける対応オブジェクトのオブジェクトクラスの名前に相当し、<class>operations はオブジェクトで実行され得るオペレーションに相当する。例えば、ポイントキューオブジェクト(point queue object)が、プリントジョブを休止させ、開始させ、削除するようなオペレーションを有する。以下においては、これらの OleDs インターフェース及び他のOleDs インターフェースの各々は、インターフェースのあるメソッドを一 例として実行したときの記述ともに定義される。
【００２７】
図４は、本発明を実施するために構成されたコンピュータシステムのブロック図である。コンピュータシステム400 は、メモリ401 と、中央処理装置402 と、I/O インターフェース403 と、記憶装置404 と、表示装置405 とを含む。OleDs オブジェクトの様々なインプリメンテーションは、ディスク等のコンピュータ読み取り可能メモリにストアされる。これらのインプリメンテーションは実行するためにコンピュータメモリにロードされる。コンピュータメモリはクライアント406,407 を含む。メモリはまた、３つのディレクトリサービスのために、OleDs オブジェクト408,411,414 のインプリメンテーションを含む。OleDs オブジェクトの各インプリメンテーションは、ディレクトリサービス409,412,415 の対応ＡＰＩセットにアクセスする。これらのＡＰＩセットは、基礎をなすディレクトリサービスのために、オブジェクト410,413,416 のプロパティへのアクセスを行う。更に、OleDs 自身は、結合ファンクションのインプリメンテーションと、ネームスペーシズコンテナと、ディレクトリサービスの典型的なオブジェクトに対応する様々なOleDs オブジェクトとを提供する。
【００２８】
OleDsGetObject ファンクション
図５は、OleDs の結合ファンクションであるファンクションOleDsGetObjectのフローチャートである。オブジェクト及びインターフェース識別子へのOleDs パスをファンクションOleDsGetObjectに渡すと、ファンクションOleDsGetObjectはオブジェクトを表わすOleDs オブジェクトのインターフェースにポインタをリターンする。ステップ501 では、このファンクションは、OleDs パスからのネームスペース識別子を構文解析する。このファンクションは、ネームスペース識別子を使用して、識別されたネームスペースのプロバイダが提供する構文解析インターフェースのインプリメンテーションを見つけ出す。ステップ502 では、本ファンクションは、（ OLE 2.0.1 で定義された）ファンクション CoGetClassObject をコールし、識別されたネームスペースのプロバイダがインプリメントしたParseDisplayNameクラスのクラスファクトリオブジェクトへのポインタを検索する。本ファンクションは、識別されたネームスペースのためのParseDisplayNameクラスのクラス識別子を動的に生成する。例えば、構文解析されたネームスペースが「WinNTDS 」ならば、クラス識別子は「CLSID＿PDNWinNTDS」であってよい。クラスファクトリオブジェクトは、ParsedDisplayName クラスのオブジェクトをインスタンスし、これはインスタンスされるべきIParseDisplayName インターフェースを公開する。IParseDisplayName インターフェースは、名前をリターンするメソッドを、OleDs パスによって識別されたオブジェクトに関するOleDs オブジェクトに提供する。ステップ503 では、本ファンクションは、IParseDisplayName インターフェースの識別子を渡すメソッドIClassFactory::CreateInstance を呼び出し、そしてIParseDisplayName インターフェースへのポインタを受信する。メソッドCreateInstanceは、動的に生成されたクラス識別子によって識別されたクラスのインスタンスを作成する。ステップ504 では、本ファンクションは、OleDs パスを渡すメソッドIParseDisplayName::ParseDisplayName を呼び出す。メソッドParseDisplayNameは、OleDs パスによって識別されたオブジェクトに関する名前（IMonikerインターフェース）へのポインタをリターンする。ステップ505 では、本ファンクションは、メソッド IMoniker::BindToObject を呼び出し、OleDs パスによって識別されたオブジェクトを表わすOleDs オブジェクトへのポインタを検索する。次いで、本ファンクションは、このポインタをOleDs オブジェクトにリターンする。
【００２９】
IOleDs インターフェース
IOleDsインターフェースは、各OleDs オブジェクトに共通な属性及びメソッドを定義する。以下は、その属性及びメソッドの記述を加えたインターフェースの定義である：
Interface IOleDs：IDispatch
｛ HRESULT get Name(string*pName)
HRESULT get Class(string*pClass);
HRESULT get GUID (string*GUID);
HRESULT get OleDsPath(string*pOleDsPath);
HRESULT get Parent (string*pParentContainer);
HRESULT get Schema (string*pSchemaClassObject);
HRESULT Access(IOleDsAccess**ppComponentAccessControl);
HRESULT PropAccess(string PropName, IOleDsAccess**ppComponent
AccessControl);
HRESULT GetInfo(variant vHints);
HRESULT SetInfo(void);
HRESULT Get(string Name,variant*pProp);
HRESULT Put(string Name,variant Prop);
｝
【００３０】
属性
名前 記述
名前（Name) コンテナオブジェクト内のこのオブジェクトの相対的な名前
OleDsPath このオブジェクトのOleDs パス
クラス(Class) このオブジェクトのオブジェクトクラスのネーム
GUID このオブジェクトクラスのオブジェクトに関する一意的識別子
Parent このオブジェクトのコンテナオブジェクトのOleDs パス
Schema このオブジェクトクラスを表わすスキーマオブジェクトのOleDs パス
メソッド
名前 記述
Access このオブジェクトのセキュリティパーミッションに一致するOleDs アクセスコントロールオブジェクトの（下で説明される）IOleDsAccessインターフェースを得る。
PropAccess これのプロパティにアクセスコントロールを表わすOleDs アクセスコントロール従属オブジェクトのIOleDsAccessインターフェースにポインタを戻す。
GetInfo ディレクトリサービスからこのオブジェクトのプロパティ値を検索し、それらをOleDs オブジェクトにストアする。vHintsパラメータによって、クライアントが、検索されるべきファンクショナルセット又はプロパティを指示することができるので、メソッドはネットワークアクセスを最適化することができる。
SetInfo このオブジェクトに変化を完遂（コミット）する。プロパティがこのオブジェクトで変化しているならば、メソッドはプロパティ値をOleDs オブジェクトからディレクトリサービスに書込む。
Get OleDs オブジェクトから名前をつけられたプロパティに関する値を検索する。
Put OleDs オブジェクトに名前をつけられたプロパティに関する値をセットする。
【００３１】
図６及び図７はIOleDsインターフェースのメソッドのインプリメンテーションを図示する。図６はメソッドIOleDs::GetInfo の流れ図である。このメソッドはオブジェクトに関するプロパティをディレクトリサービスからOleDs オブジェクトにロードする。OleDs はコミットプロセス又はトランザクションプロセスを定義し、オブジェクトのプロパティに対する更新が該コミットプロセス又はトランザクションプロセスによって、（メソッドPut を使用する）OleDs オブジェクトにのみストアされ、クライアントが（メソッドSetInfo を使用して）リクエストしたときにだけディレクトリサービスにストアされる。OleDs オブジェクトが最初に例示されたとき、例えば、ファンクションOleDsGetObjectが呼び出されたとき、例示されたオブジェクトは典型的には、ディレクトリサービスのＡＰＩセットに対するオブジェクトを識別するハンドルを含む。ステップ601 では、メソッドは、ハンドルをオブジェクトと、オブジェクトに関するプロパティ名のリストとにパスさせるファンクションReadObjectを呼び出す。ファンクションReadObjectはディレクトリサービスから名付けられたプロパティに関する値を検索する。
OleDs デフォルトオブジェクトに関するメソッドGetInfo のインプリメンテーションでは、メソッドは、このオブジェクトのオブジェクトクラスに関してスキーマオブジェクトからプロパティ名のリストを検索する。ステップ702 乃至704 では、メソッドループは検索された値をOleDs オブジェクトにストアする。ステップ702 では、メソッドは次の値を選択して、最初から始まる。ステップ703 では、すべての値が既に選択されているならば、次いで、メソッドは戻り、代わりにメソッドはステップ704 に続く。ステップ704 では、メソッドは選択された値をOleDs オブジェクト内にストアし、次の値を選択すべくステップ702 にループする。
【００３２】
図７はメソッドIOleDs::Get の流れ図である。メソッドはプロパティ名をパスし、パスされたプロパティのその値をOleDs オブジェクトから検索し、且つ、戻す。
【００３３】
IOleDsContainer インターフェース
IOleDsContainer インターフェースは、コンテナである各OleDs オブジェクトに共通な属性及びメソッドを定義する。以下は、その属性及びメソッドの記述を加えたインターフェースの定義である。
Interface IOleDsContainer:IDispatch
｛
HRESULT get Count(long*pCount);
HRESULT get NewEnum(IUnknown*ppEnum);
HRESULT get Filter（Variant*pFiler);
HRESULT put Filter（Variant Filter);
HRESULT GetObject(string Class,string RelativeName,IOleDS **
ppNameObject);
HRESULT Create (string Class,string RelativeName,IOleDS**ppNew
Object);
HRESULT Delete (string Class,String RelativeName);
HRESULT CopyHere(string SourceObject,string NewName,IOleDs**
ppNewObject);
HRESULT MoveHere(string SourceObject,string NewName,IOleDs**
ppNewObject);
｝
【００３４】
属性
名前 記述
Filter 特定の目録に戻されるべきオブジェクトクラスに関するフィルタの配列。フィルタが空ならば、すべてのオブジェクトクラスのすべてのオブジェクトは戻される。各配列エントリは以下のフォーマットを有する。
<FilterEntry>::=<ClassName>
｜<ClassName>.<PropName>
｜<ClassName>.<FuncSetName>
｜<ClassName>.<FuncSetName>.<PropName>
｜<GUID>
｜"Provider Specific String"
Count フィルタをパスするコンテナ内のOleDs オブジェクトの数
＿NewEnum 収容されたオブジェクトのエニュメレータ
メソッド
名前 記述
GetObject オブジェクトのIOleDsインターフェースを、コンテナオブジェクト内のオブジェクトクラス及び相対的な名前によって識別されるこのコンテナオブジェクトに戻す。
Create このコンテナオブジェクト内に指定されたオブジェクトクラス及び相対的な名前のオブジェクトを作り、ポインタをIOleDsインターフェースに戻す。オブジェクトは、メソッドIOleDs::SetInfo が呼び出されるまでディレクトリサービス内に実際には作られないので、コミットされたプロパティはセットされるべきである。
Delete このコンテナオブジェクト内のオブジェクトクラスと相対的な名前によって識別されたオブジェクトを削除する。
CopyHere 指定されたオブジェクトと同一である新しいオブジェクトをこのコンテナオブジェクトに作り、IOleDsインターフェースへのポインタを新しいオブジェクトに戻す。NewName は、存在するならば、コンテナオブジェクト内にある新しいオブジェクトの名前を含む選択的なパラメータである。
MoveHere ソースオブジェクトがコピーの後で削除されることを除いて、メソッドCopyHereと同様である。
【００３５】
図８はメソッドIOleDsContainer::CopyHere のフローチャートである。このメソッドは、このコンテナオブジェクト内にある指定されたソースオブジェクトのコピーを作る。ステップ801 では、本メソッドは、コピーされるべきオブジェクトのオブジェクトクラスを決定する。ステップ802 では、本メソッドは、ファンクションCreateObjectを呼び出すことによって、決定されたオブジェクトのオブジェクトクラスをディレクトリサービス内に作る。ステップ803 では、本メソッドは、オブジェクトクラスのためのスキーマオブジェクトへのOleDs パスを検索する。ステップ804 では、メソッドはOleDs パスをスキーマオブジェクトに渡すファンクションOleDsGetObjectを呼び出し、OleDs スキーマオブジェクトのIOleDsインターフェースへのポインタを検索する。ステップ805 では、本メソッドは、IOleDsClass インターフェースへのポインタを検索するために、OleDs スキーマオブジェクトのメソッドIOleDs::QueryInterfaceを呼び出す。IOleDsClass インターフェースは、このオブジェクトクラスのために定義されたプロパティ名を検索するメソッドを提供する。ステップ806 では、本メソッドは、このスキーマクラスの必須のプロパティリストを検索するために、メソッドIOleDsClass::GetMandatoryProperties を呼び出す。ステップ807 では、本メソッドは、このクラスに関する追加のプロパティを検索するために、メソッドIOleDs::Propertiesを呼び出す。ステップ808〜811 では、本メソッドループ(method loops)は、プロパティの各値を、ソースOleDs オブジェクトから宛先OleDs オブジェクトまでコピーする。ステップ808 では、本メソッドは次のプロパティを選択し、最初から始める。ステップ809 では、全てのプロパティが既に選択されているならば、本メソッドはステップ812 に続き、他の場合は、本メソッドはステップ810 に続く。ステップ810 では、メソッドは、選択されたプロパティに関する値を検索するために、ソースOleDs オブジェクトのメソッドIOleDs::Get を呼び出す。ステップ811 では、本メソッドは宛先 IOleDs オブジェクトで検索された値をストアし、次のプロパティを選択するためにステップ808 にループする。ステップ812 では、メソッドはソースOleDs オブジェクトの属性を宛先OleDs オブジェクトにコピーし、リターンする。
図９は、メソッドIOleDs::Createのフローチャートである。ステップ901 では、本メソッドは、オブジェクトクラスを渡すディレクトリサービスのファンクションCreateObjectを呼び出し、そのオブジェクトクラスの新たに作られたオブジェクトへのハンドルを受信する。
【００３６】
IOleDsClass インターフェース
IOleDsClass インターフェースは、オブジェクトクラスの定義へのアクセスを提供するために、OleDs スキーマによって公開される。以下は、その属性とメソッドの記述を加えたインターフェースの定義である。
Interface IOleDsClass:IOleDs
｛
HRESULT get PrimaryInterface(string*GUID);
HRESULT get CLSID(string CLSID);
HRESULT put CLSID(string CLSID);
HRESULT get OID(string*OID);
HRESULT put OID(string OID);
HRESULT get Abstract(boolean*Abstract);
HRESULT put Abstract(boolean Abstract);
HRESULT get MandatoryProperties(Variant*Mandatory);
HRESULT put MandatoryProperties(Variant Mandatory);
HRESULT get DerivedFrom(Variant*pDerivedFrom);
HRESULT put DerivedFrom(Variant DerivedFrom);
HRESULT get Containment(Variant*pContainment);
HRESULT put Containment(Variant Containment);
HRESULT get Container(boolean*pContainer);
HRESULT put Container(boolean Container);
HRESULT get HelpFileName(string*pHelpFile);
HRESULT put HelpFileName(string HelpFile);
HRESULT get HelpFileContext(long*pHelpContext);
HRESULT put HelpFileContext(long HelpContext);
HRESULT Attributes(IOleDsCollection**ppAttributes)
｝
【００３７】
属性
名前 記述
CLSID このオブジェクトクラスに関してOLE DSオブジェクトを実行するコードのCLSID
OID このオブジェクトクラスを定義するネームスぺーススペシフィックオブジェクト識別子。これは、オブジェクトクラスのためのネームスペーススペシフィックOIDsを要求するネームスペースにおいて、OLE DSを介してスキーマ拡大を可能にするように提供される。
Abstract このオブジェクトクラスがアブストラクトであるかどうか指示するブール値
MandatoryProperties 記憶領域に書き込まれるべきオブジェクトクラスに設定されなければならないプロパティのリスト
Primary Interface このオブジェクトクラスのオブジェクトに関するプライマリインターフェース識別子。これは、IOleDsUserをサポートすることによって定義されるならば、例えば「user」クラスを定義するインターフェースに関するIID である。
DriverdFrom このオブジェクトクラスが得られる中間スーパークラスを示すOleDs パス列の配列
Container このオブジェクトクラスがコンテナであるかどうか決定するプロパティ
HelpFileName このオブジェクトクラスのオブジェクトについて更なる情報を含むヘルプファイルの名前
HelpFileContext このオブジェクトクラスで特定の情報を見つけることができるHelpFileName内のContext ID
メソッド
名前 記述
Attributes このプロパティの追加の属性[delete???] を説明するOleDs オブジェクトの集合をリターンする
IOleDsProperty インターフェース
OleDs はオブジェクトクラスの各プロパティに対応するOleDs プロパティオブジェクトを定義する。OleDs プロパティオブジェクトはプロパティの定義を検索するインターフェースを公開する。以下は、属性とメソッドの記述を加えたインターフェースの定義である。
Interface IOleDsProperty：IOleDs
｛
HRESULT get OleDsNames(Variant*pOleDsNames);
HRESULT get DsNames(Variant*pDsName);
HRESULT get OID(string OID);
HRESULT put OID(string*OID);
HRESULT get Syntax(string*pSyntax);
HRESULT put Syntax(string Syntax);
HRESULT get MaxRange(long*pMaxRange);
HRESULT put MaxRange(long MaxRange);
HRESULT get MinRange(long*pMinRange);
HRESULT put MinRange(long MinRange);
HRESULT get MultiValued(long*pMultiValued);
HRESULT put MultiValued(long MultiValued);
HRESULT Attributes(IOleDsCollection**ppAttributes)
｝
【００３８】
属性
名前 記述
OleDsNames OleDs がこのプロパティにアクセスすることができる名前を含む文字列の配列
DsNames 基礎をなすネームスペースがこのプロパティにアクセスすることができる名前を含むストリングの配列
OID このプロパティを定義するネームスペーススペシフィックオブジェクト識別子
Syntax このプロパティの構文を定義するスキーマシンタックスオブジェクトの相対的なパス。現在のスキーマコンテナに関連している。
MaxRange プロパティに指定した値の上限
MinRange プロパティに指定した値の下限
Normal このプロパティが標準的に複製されるべきかどうか決定する値
MultiValued このプロパティがマルチバリュー（multi-value ）であるかどうか決定する値
メソッド
名前 記述
Attributes このプロパティの追加の属性を説明するOLE DSオブジェクトの集合をリターンする
IOleDs<Class> インターフェース
OleDs は、IOleDs<class> と名付けられたインターフェースをサポートすることができる全てのオブジェクトクラスを定義し、ここで<class> はオブジェクトクラスの名前である。このインターフェースはメソッドを有し、オブジェクトクラスによってサポートされた各ファンクション集合は、そのファンクション集合のためのOlDsFunctionalSet オブジェクトに対するポインタをリターンする。
Interface IOleDsUser：IOleDs
｛
HRESULT get BusinessInfo
(IOleDs FS UserBusinessInfo**ppFuncSet);
｝：
【００３９】
OleDs オブジェクトクラス定義
OleDs は、コンテナオブジェクトとリーフオブジェクトの両方のための様々なオブジェクトクラスを定義する。OleDs は、コンテナオブジェクトのために以下のオブジェクトクラス定義する。
ネームスペーシズ（Namespaces）
ネームスペース（Namespace ）
国（Country ）
地域（Locality）
組織（Organization）
ドメイン（Domain）
組織ユニット（Organizational Unit ）
コンピュータ（Computer）
ファイルサービス（File Service）
OleDs は、リーフオブジェクトのために以下のオブジェクトクラス定義する。
ユーザ（User）
グループ（Group ）
エイリアス（Alias ）
サービス（Service ）
ポイントキュー（Point Queue ）
ポイントジョブ（Point Job ）
ポイントデバイスセッション（Point Device Session）
リソース（Resource）
ファイル共有（File Share）
ネームスペーシズオブジェクトは、ネームスペースオブジェクトのコンテナである。ネームスペーシズオブジェクトのインプリメンテーション（実装）は、OleDs の一部である。ネームスペーシズオブジェクトは、IOleDsネームスペーシズインターフェースを公開する。このインターフェースを以下に示す。
Interface IOleDsNamespaces：IOleDs
｛
get DefaultContainer(string *pDefault);
set DefaultContainer(string Default);
｝
ネームスペースオブジェクトは、所定のネームスペースに関する全てのOleDs オブジェクトソースであるコンテナオブジェクトである。国オブジェクトは、国に関するプロパティを有するコンテナオブジェクトである。地域オブジェクトは、地域（例えば、州）に関するプロパティを有するコンテナオブジェクトである。以下は、地域オブジェクトのプロパティを得て設定するインターフェースの定義である。
Interface IOleDsFSLocalityGeneralInfo:IDispatch
｛
HRESULT get Description(string*Description);
HRESULT put Description(string Description);
HRESULT get LocalityName(string LocalityName);
HRESULT put LocalityName(string LocalityName);
HRESULT get PostalAddress(string*pPostalAddress);
HRESULT put PostalAddress(string pPostalAddress);
HRESULT get SeeAlso(VARIANT*pSeeAlso);
HRESULT put SeeAlso(VARIANT Also);
HRESULT Access(IOleDsAccess**ppFuncSetAccessControl);
HRESULT PropAccess(string PropName, IOleDsAccess **ppPropAccess
Control);
｝
メソッド
名前 記述
Access アクセスコントロール依存オブジェクトの IOleDsAccess インターフェースにポインタをリターンする。ここで、 IOleDsAccess インターフェースは、本インターフェース上でアクセス制御を表わす。
PropAccess PropNameによって指示されるとき、アクセスコントロール依存オブジェクトの IOleDsAccess インターフェースにポインタをリターンする。ここで、 IOleDsAccess インターフェースは、本インターフェース上でアクセス制御を表わす。
【００４０】
属性
名前 記述
Description 地域を説明するテキスト
LocalityName 地域名。地域名はコンテナが物理的に配置される地図エリアを特定する。
PostalAddress 地域のメイン郵便アドレス
SeeAlso このオブジェクトに関連し得る他のディレクトリオブジェクト名の配列
OleDs 定義されたオブジェクトクラスの各々は、そのオブジェクトクラスのオブジェクトに関するプロパティを定義する。ドメインオブジェクトは、コンピュータシステムのドメインに対応し、且つそのドメインオブジェクトに関するプロパティ（例えば、パスワード）を備えたファンクション集合を有する。組織ユニットオブジェクトは、会社等のエンティティ (entity)に対応する。コンピュータオブジェクトは、ドメイン(domain)のコンピュータに対応する。ユーザオブジェクトは、ビジネス情報、アカウント制限、アカウント統計、及び、ユーザを記述するための他の情報ファンクショナル集合を有する。ビジネス情報ファンクション集合は、国、部、課、マネージャ、オフィスの場所等のビジネスの説明に関するプロパティを含む。アカウント制限ファンクション集合は、無効にされたアカウント、ユーザがログインすることができる時間数等のユーザのアカウントの一般的な特徴を説明したプロパティを含む。アカウント統計ファンクショナン集合は、パスワードが変更された最後の時間及びユーザがアカウントにログインした最後の時間のようなユーザアカウントの統計を特定したプロパティを有する。他の情報ファンクショナル集合は、電子メールアドレス、ホームディレクトリ等の他のユーザ情報に関するプロパティを含む。
【００４１】
OleDs のクライアントの例
図１０は、全てのネームスペーシズ(namespaces)を表示する手順のフローチャートである。この手順は、OleDs のクライアントが全てのネームスペーシズの名前を検索するやり方を図示している。ステップ1001では、ファンクション CoGetClassObject を呼び出し、OleDs ネームスペーシズオブジェクトのためのクラス、及びIClassFactory インターフェースに関するインターフェース識別子を渡す。本ファンクションは、OleDs ネームスペーシズのためのクラスファクトリインターフェースにポインタをリターンする。ステップ1002では、メソッド IClassFactory::CreateInstance を呼び出して、IOleDsContainer インターフェースのためのインターフェース識別子を渡す。本メソッドは、OleDs ネームスペーシズオブジェクトのインスタンスを作り、ポインタをIOleDsContainer インターフェースにリターンする。ステップ1003では、メソッド IOleDsContainer::get ＿ NewEnum を呼び出し、ネームスペーシズオブジェクトのためのエニュメレータ（ enumerator ）を検索する。ステップ1004〜1008では、各ネームスペースを列挙しながらループし、ネームスペースを表示する。ステップ1004では、メソッド IEnumerator::Next を呼び出し、ネームスペースオブジェクトのためのIUnknownインターフェースに対するポインタを検索する。ステップ1005では、全てのネームスペーシズが既に列挙されてしまっているならば本手順はリターンし、そうでなければステップ1006に続く。ステップ1006では、メソッド IUnknown::QueryInterface を呼び出し、ネームスペースオブジェクトのためのIOleDsインターフェースに対するポインタを検索する。ステップ1007では、メソッド IOleDs::get ＿ Name を呼び出し、ネームスペースオブジェクトと関係している名前を検索する。ステップ1008では、検索された名前を表示し、次のネームスペースオブジェクトを列挙するためにステップ1004にループする。
【００４２】
以上、好ましい実施形態に関して本発明を説明してきたが、本発明を本実施形態に限定すべきではない。本発明の精神の範囲内での変更は当業者にとって明らかであろう。本発明の範囲は特許請求の範囲によって定義される。
【図面の簡単な説明】
【図１】 ディレクトリサービスのサンプル階層構造を図示する。
【図２】 オブジェクトを表わすのに使用される典型的なデータ構造を図示する。
【図３Ａ】 OleDs の階層構造を図示する。
【図３Ｂ】 ディレクトリサービスにおけるOleDs オブジェクトとそれらに対応するオブジェクトとの間の関係を図示する。
【図４】 本発明を実施するために構成されたコンピュータシステムのブロック図である。
【図５】 OleDs の割り当てファンクションである、ファンクションOleDsGetObjectのフローチャートである。
【図６】 メソッドIOleDs::GetInfo のフローチャートである。
【図７】 メソッドIOleDs::Get のフローチャートである。
【図８】 メソッドIOleDsContainer::CopyHere のフローチャートである。
【図９】 メソッドIOleDs::Createのフローチャートである。
【図１０】 全てのネームスペースを表示するためのプロシージャのフローチャートである。
【符号の説明】
400 コンピュータシステム
401 メモリ
402 中央処理装置
403 I/O インターフェース
404 記憶装置
405 表示装置
406,407 クライアント
408,411,414 OleDs オブジェクト
409,412,415 ディレクトリサービス
410,413,416 オブジェクト
Claims (8)
- コンピュータシステムにおいて、所定のインタフェースが、複数のディレクトリサービスプロバイダーにより提供される複数のディレクトリサービスにオブジェクト・属性・インタフェースの共通セットを用いてアクセスする方法であって、
前記コンピュータシステムにおけるディレクトリサービスプロバイダーのクライアントプログラムは、前記オブジェクト・属性・インタフェースの共通セットを用いてアプリケーションプログラミングインタフェースを備えた様々な各ディレクトリサービスにアクセスして、ディレクトリサービスのオブジェクトにアクセスし、そして、
少なくとも２つの前記ディレクトリサービスプロバイダーが、異なるアプリケーションプログラミングインタフェースを有しながら類似の機能性をもつ少なくとも１つのディレクトリサービス機能を提供するように構成されており、
前記コンピュータシステムは、
前記複数のディレクトリサービスプロバイダーの各々のために、前記オブジェクト・属性・インタフェースの共通セットを用いて、前記何れかのディレクトリサービスのオブジェクトにアクセスするための関数の定義を含む前記所定のインタフェースの実装をインストールする処理と、この際に、前記所定のインタフェースの実装は、あるディレクトリサービスプロバイダーにおける前記アプリケーションプログラミングインタフェースの機能から、前記所定のインタフェースの機能へのマッピングを与え、
前記オブジェクトに関係する情報を含むディレクトリサービスを特定するとともに、当該特定されたディレクトリサービス内のオブジェクトへのパス (path) を特定するためのオブジェクトの識別（特定）を、ディレクトリサービスプロバイダーのクライアントプログラムから受信する処理と、
前記特定されたディレクトリサービスを使用することにより、前記識別されたオブジェクトがどのディレクトリサービスプロバイダーから提供されるかを決定する処理と、
前記決定されたディレクトリサービスプロバイダーのためにインストールされた、前記所定のインタフェースの実装と前記特定されたパスとを使用して、前記識別されたオブジェクトに対する前記所定のインタフェースの対応オブジェクトを探し出し結びつける処理と、
を含み、これにより、
前記ディレクトリサービスプロバイダーのクライアントプログラムは、そのディレクトリサービスに関する所定のインタフェースの実装を用いて、各ディレクトリサービスにアクセスすることができることを特徴とする方法。 - 前記各オブジェクトはオブジェクトクラスを有し、前記所定のインタフェースは、前記所定のインタフェースのデフォルト (default) ・オブジェクトのインスタンスを実装することによって、オブジェクトクラスの定義をディレクトリサービスに追加するための関数の定義を含む、請求項１に記載の方法。
- 前記各オブジェクトはオブジェクトクラスを有し、所定のインタフェースはディレクトリサービスのオブジェクトクラスの定義を検索するための関数の定義を含む、請求項１に記載の方法。
- 前記所定のインタフェースは、前記ディレクトリサービスに対してオブジェクトへの変更を完追するための関数の定義を含む、請求項１に記載の方法。
- コンピュータシステムに所定のインタフェースを提供し、複数のディレクトリサービスプロバイダーが提供する複数のディレクトリサービスにアクセスするように機能させるプログラムを記録したコンピュータ読取り可能な記録媒体であって、
前記各ディレクトリサービスは、オブジェクト・属性・インタフェースの共通セットを用いて前記ディレクトリサービスのオブジェクトにアクセスするための関数の定義を含む前記アプリケーションプログラミングインタフェースを有し、前記所定のインタフェース を用いるために開発されたクライアントプログラムが、前記オブジェクト・属性・インタフェースの共通セットを用いて前記ディレクトリサービスの各々にアクセスできるよう構成されており、
これにより、前記コンピュータシステムに、
複数のディレクトリサービスプロバイダーの各々のために前記所定のインタフェースの実装をインストールする処理であって、前記オブジェクト・属性・インタフェースの共通セットを用いて前記何れかのディレクトリサービスのオブジェクトにアクセスする関数が前記所定のインタフェースによって定義され、前記実装によって前記アプリケーションプログラミングインタフェースの機能から、前記所定のインタフェースの対応の機能へのマッピングが与えられる、当該処理と、
前記オブジェクトに関係する情報を含むディレクトリサービスを特定するとともに、当該特定されたディレクトリサービス内のオブジェクトへのパス (path) を特定するためのオブジェクトの識別を受信する処理と、
前記オブジェクトの識別を使用して前記特定されたディレクトリサービスを識別する処理と、
前記特定されたパスを前記オブジェクトに渡すことによって、前記識別されたディレクトリサービスの所定のインタフェース実装への対応の関数を呼び出す処理と、その呼び出された関数は前記オブジェクトの参照（リファレンス）を返し、
前記オブジェクトに関係する情報が得られるようにするため、前記呼び出された関数と前記参照を結びつける処理と、
を実行させるためのプログラムを記録したコンピュータ読取り可能な記録媒体。 - 前記各オブジェクトはオブジェクトクラスを有し、前記所定のインタフェースは、前記所定のインタフェースのデフォルト (default) ・オブジェクトを実装することによって、オブジェクトクラスの定義をディレクトリサービスに追加するための関数の定義を含む、ことを特徴とする請求項５に記載のコンピュータ読取り可能な記録媒体。
- 前記各オブジェクトはオブジェクトクラスを有し、前記所定のインタフェースは、ディレクトリサービスのオブジェクトクラスの定義を検索するための関数の定義を含む、ことを特徴とする請求項５に記載のコンピュータ読取り可能な記録媒体。
- 前記所定のインタフェースは、前記ディレクトリサービスに対してオブジェクトへの変更を完追するための関数の定義を含む、ことを特徴とする請求項５に記載のコンピュータ読取り可能な記録媒体。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US08/674,318 US5893107A (en) | 1996-07-01 | 1996-07-01 | Method and system for uniformly accessing multiple directory services |
| US08/674318 | 1996-07-01 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH10154095A JPH10154095A (ja) | 1998-06-09 |
| JP4197753B2 true JP4197753B2 (ja) | 2008-12-17 |
Family
ID=24706140
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP21114897A Expired - Lifetime JP4197753B2 (ja) | 1996-07-01 | 1997-07-01 | 多数ディレクトリサービスに一様にアクセスするための方法及びシステム |
Country Status (5)
| Country | Link |
|---|---|
| US (2) | US5893107A (ja) |
| EP (2) | EP1460565B1 (ja) |
| JP (1) | JP4197753B2 (ja) |
| CA (1) | CA2209170C (ja) |
| DE (1) | DE69730657T2 (ja) |
Families Citing this family (90)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6185611B1 (en) * | 1998-03-20 | 2001-02-06 | Sun Microsystem, Inc. | Dynamic lookup service in a distributed system |
| US5893107A (en) * | 1996-07-01 | 1999-04-06 | Microsoft Corporation | Method and system for uniformly accessing multiple directory services |
| US6061726A (en) * | 1997-05-27 | 2000-05-09 | Novell, Inc. | Dynamic rights assignment apparatus and method using network directory services |
| US6209036B1 (en) * | 1997-06-06 | 2001-03-27 | International Business Machines Corporation | Management of and access to information and other material via the world wide web in an LDAP environment |
| GB2345167B (en) * | 1997-08-11 | 2002-08-21 | Seagate Technology | Object oriented data storage device |
| US6134706A (en) * | 1997-08-14 | 2000-10-17 | International Business Machines Corporation | Software business objects in a multi-level organizational structure |
| JP3808608B2 (ja) * | 1997-10-20 | 2006-08-16 | 富士通株式会社 | 蓄積交換型電子会議システムにおけるオブジェクトの移動処理装置及び方法並びに移動処理プログラムを記録したコンピュータ読取可能な記録媒体 |
| US6044467A (en) * | 1997-12-11 | 2000-03-28 | Sun Microsystems, Inc. | Secure class resolution, loading and definition |
| US6044379A (en) * | 1997-12-18 | 2000-03-28 | Sun Microsystems, Inc. | Method and apparatus for efficiently implementing multiple storage mechanism for name services associated with a computer system |
| US6026408A (en) * | 1998-01-28 | 2000-02-15 | Unisys Corp. | Method for synchronizing the schema of a database with its representation in an object-oriented repository |
| US6862736B2 (en) | 1998-02-06 | 2005-03-01 | Microsoft Corporation | Object manager for common information model |
| US6138122A (en) * | 1998-03-02 | 2000-10-24 | Agilent Technologies | Modeling of internet services |
| US6317748B1 (en) * | 1998-05-08 | 2001-11-13 | Microsoft Corporation | Management information to object mapping and correlator |
| US6961748B2 (en) | 1998-10-27 | 2005-11-01 | Murrell Stephen J | Uniform network access |
| FR2785412B1 (fr) * | 1998-10-30 | 2001-08-24 | Bull Sa | Creation dynamique de classes d'objets |
| US6477539B1 (en) * | 1998-12-22 | 2002-11-05 | Nortel Networks Limited | Method and apparatus for interfacing a manager and a plant |
| US6609153B1 (en) | 1998-12-24 | 2003-08-19 | Redback Networks Inc. | Domain isolation through virtual network machines |
| US6154741A (en) * | 1999-01-29 | 2000-11-28 | Feldman; Daniel J. | Entitlement management and access control system |
| US7076476B2 (en) * | 1999-03-02 | 2006-07-11 | Microsoft Corporation | Method and system for integrated service administration via a directory service |
| US6842903B1 (en) * | 1999-05-19 | 2005-01-11 | Sun Microsystems, Inc. | System and method for providing dynamic references between services in a computer system |
| GB2351370A (en) * | 1999-06-25 | 2000-12-27 | Ibm | Data processing with policed object union |
| US7058956B1 (en) * | 1999-09-01 | 2006-06-06 | Microsoft Corporation | Directory services interface extensions with aggregatable software objects |
| US6622170B1 (en) | 1999-09-10 | 2003-09-16 | International Business Machines Corporation | System and method for DEN/LDAP client database access with a backoff capability |
| US6604148B1 (en) * | 1999-10-01 | 2003-08-05 | International Business Machines Corporation | Method, system, and program for accessing a network namespace |
| US7331058B1 (en) * | 1999-12-16 | 2008-02-12 | International Business Machines Corporation | Distributed data structures for authorization and access control for computing resources |
| US6847959B1 (en) * | 2000-01-05 | 2005-01-25 | Apple Computer, Inc. | Universal interface for retrieval of information in a computer system |
| US6484177B1 (en) * | 2000-01-13 | 2002-11-19 | International Business Machines Corporation | Data management interoperability methods for heterogeneous directory structures |
| US6578035B1 (en) | 2000-01-14 | 2003-06-10 | Novell, Inc. | Method for dynamic validation of a distributed database segment which yields a suitable successor |
| US6665674B1 (en) | 2000-02-02 | 2003-12-16 | Nortel Networks Limited | Framework for open directory operation extensibility |
| US6760720B1 (en) | 2000-02-25 | 2004-07-06 | Pedestrian Concepts, Inc. | Search-on-the-fly/sort-on-the-fly search engine for searching databases |
| US20010048448A1 (en) * | 2000-04-06 | 2001-12-06 | Raiz Gregory L. | Focus state themeing |
| US6753885B2 (en) * | 2000-04-06 | 2004-06-22 | Microsoft Corporation | System and theme file format for creating visual styles |
| US6873337B1 (en) * | 2000-04-06 | 2005-03-29 | Microsoft Corporation | Application programming interface for changing the visual style |
| US20050091576A1 (en) * | 2003-10-24 | 2005-04-28 | Microsoft Corporation | Programming interface for a computer platform |
| US7899173B2 (en) * | 2000-07-14 | 2011-03-01 | Context Connect, Llc | Communication connectivity via context association, advertising sponsorship, and multiple contact databases |
| US6731927B1 (en) | 2000-07-14 | 2004-05-04 | Context Connect, Inc. | System and method for context association |
| US7340048B2 (en) * | 2000-07-14 | 2008-03-04 | Context Connect Llc | System and method for directory services and e-commerce across multi-provider networks |
| US7051114B1 (en) * | 2000-11-01 | 2006-05-23 | Cisco Technology, Inc. | System and method for integrating directory servers |
| US7200627B2 (en) * | 2001-03-21 | 2007-04-03 | Nokia Corporation | Method and apparatus for generating a directory structure |
| US7756835B2 (en) * | 2001-03-23 | 2010-07-13 | Bea Systems, Inc. | Database and operating system independent copying/archiving of a web base application |
| US6721758B1 (en) | 2001-03-30 | 2004-04-13 | Novell, Inc. | System and method for using schema attributes as meta-data in a directory service |
| US7017162B2 (en) * | 2001-07-10 | 2006-03-21 | Microsoft Corporation | Application program interface for network software platform |
| US7546602B2 (en) | 2001-07-10 | 2009-06-09 | Microsoft Corporation | Application program interface for network software platform |
| US7581231B2 (en) | 2001-07-10 | 2009-08-25 | Microsoft Corporation | Computing system and method for allowing plurality of applications written in different programming languages to communicate and request resources or services via a common language runtime layer |
| US7117504B2 (en) | 2001-07-10 | 2006-10-03 | Microsoft Corporation | Application program interface that enables communication for a network software platform |
| US7165239B2 (en) | 2001-07-10 | 2007-01-16 | Microsoft Corporation | Application program interface for network software platform |
| US20030035381A1 (en) * | 2001-08-16 | 2003-02-20 | Yihsiu Chen | Network-based teleconferencing capabilities utilizing data network call set-up requests |
| US7519575B1 (en) * | 2001-08-31 | 2009-04-14 | Novell, Inc. | Method and apparatus for presenting, searching, and viewing directories |
| EP1298526A1 (en) * | 2001-09-26 | 2003-04-02 | Sap Ag | Communicating message with type, object and identifiers from business application to service application |
| US7448045B1 (en) * | 2002-04-30 | 2008-11-04 | Extreme Networks | Method and apparatus to extend a program |
| US6947942B1 (en) | 2002-05-30 | 2005-09-20 | Taiwan Semiconductor Manufacturing Company, Ltd. | Methods of managing user and computer objects in directory service |
| US20040167868A1 (en) * | 2003-02-20 | 2004-08-26 | Bea Systems, Inc. | System and method for a virtual content repository |
| US20040177339A1 (en) * | 2003-03-07 | 2004-09-09 | Microsoft Corporation | Customization of fields in objects in a computing environment |
| US7290052B2 (en) * | 2003-06-19 | 2007-10-30 | Microsoft Corporation | System and method for enforcing quotas on object creation in a replicated directory service database |
| US7721254B2 (en) * | 2003-10-24 | 2010-05-18 | Microsoft Corporation | Programming interface for a computer platform |
| US7716357B2 (en) * | 2003-10-24 | 2010-05-11 | Microsoft Corporation | Service discovery and publication |
| US7426734B2 (en) * | 2003-10-24 | 2008-09-16 | Microsoft Corporation | Facilitating presentation functionality through a programming interface media namespace |
| US7418507B2 (en) * | 2003-12-18 | 2008-08-26 | Microsoft Corporation | Virtual resource serving of consolidated server shares |
| US7558799B2 (en) * | 2004-06-01 | 2009-07-07 | Microsoft Corporation | Method, system, and apparatus for discovering and connecting to data sources |
| US7840615B2 (en) * | 2004-08-05 | 2010-11-23 | Siemens Enterprise Communications, Inc. | Systems and methods for interoperation of directory services |
| US20060101091A1 (en) * | 2004-10-22 | 2006-05-11 | International Business Machines Corporation | Recovering references in an extended model |
| US8185555B2 (en) * | 2004-10-22 | 2012-05-22 | International Business Machines Corporation | Model extension framework |
| US20060129526A1 (en) * | 2004-12-14 | 2006-06-15 | Sitze Richard A | System, apparatus and method of providing at least one of a plurality of serivce providers of a service based on a context in which the service is to be used |
| US7979405B2 (en) * | 2005-01-14 | 2011-07-12 | Microsoft Corporation | Method for automatically associating data with a document based on a prescribed type of the document |
| US7966286B2 (en) * | 2005-02-14 | 2011-06-21 | Microsoft Corporation | Hierarchical management of object schema and behavior |
| US7653653B2 (en) * | 2005-02-14 | 2010-01-26 | Microsoft Corporation | Dynamically configurable lists for including multiple content types |
| US7330855B2 (en) * | 2005-05-25 | 2008-02-12 | Microsoft Corporation | Converting data between a front end schema node and a back end schema node |
| FR2888019A1 (fr) * | 2005-07-04 | 2007-01-05 | France Telecom | Procede de construction d'une base de donnees d'annuaire, produit programme d'ordinateur et serveur correspondants |
| US7483893B2 (en) * | 2005-09-26 | 2009-01-27 | Bae Systems, Inc. | System and method for lightweight loading for managing content |
| US20070073673A1 (en) * | 2005-09-26 | 2007-03-29 | Bea Systems, Inc. | System and method for content management security |
| US7818344B2 (en) * | 2005-09-26 | 2010-10-19 | Bea Systems, Inc. | System and method for providing nested types for content management |
| US7752205B2 (en) * | 2005-09-26 | 2010-07-06 | Bea Systems, Inc. | Method and system for interacting with a virtual content repository |
| US7953734B2 (en) | 2005-09-26 | 2011-05-31 | Oracle International Corporation | System and method for providing SPI extensions for content management system |
| US7917537B2 (en) * | 2005-09-26 | 2011-03-29 | Oracle International Corporation | System and method for providing link property types for content management |
| US20070073674A1 (en) * | 2005-09-26 | 2007-03-29 | Bea Systems, Inc. | System and method for providing federated events for content management systems |
| US20070073784A1 (en) * | 2005-09-26 | 2007-03-29 | Bea Systems, Inc. | System and method for type inheritance for content management |
| US7831948B2 (en) * | 2006-02-02 | 2010-11-09 | The Boeing Company | Method and system for automatically generating schematics |
| US20070261045A1 (en) * | 2006-05-05 | 2007-11-08 | Dell Products L.P. | Method and system of configuring a directory service for installing software applications |
| US7849069B2 (en) * | 2006-06-21 | 2010-12-07 | International Business Machines Corporation | Method and system for federated resource discovery service in distributed systems |
| US8463852B2 (en) * | 2006-10-06 | 2013-06-11 | Oracle International Corporation | Groupware portlets for integrating a portal with groupware systems |
| US20080133533A1 (en) * | 2006-11-28 | 2008-06-05 | Krishna Ganugapati | Migrating Credentials to Unified Identity Management Systems |
| US7797281B1 (en) | 2007-01-12 | 2010-09-14 | Symantec Operating Corporation | Granular restore of data objects from a directory service |
| US20090019115A1 (en) * | 2007-02-01 | 2009-01-15 | Microsoft Corporation | Communications server objects for configuration information access |
| DE102007057248A1 (de) * | 2007-11-16 | 2009-05-20 | T-Mobile International Ag | Verbindungsschicht für Datenbanken |
| JP5538788B2 (ja) * | 2008-09-29 | 2014-07-02 | キヤノン株式会社 | 画像形成装置 |
| US20130198171A1 (en) * | 2012-01-26 | 2013-08-01 | Microsoft Corporation | Method and system for managing database object information |
| US9477698B2 (en) * | 2012-02-22 | 2016-10-25 | Salesforce.Com, Inc. | System and method for inferring reporting relationships from a contact database |
| US9578130B1 (en) | 2012-06-20 | 2017-02-21 | Amazon Technologies, Inc. | Asynchronous and idempotent distributed lock interfaces |
| US20150242531A1 (en) * | 2014-02-25 | 2015-08-27 | International Business Machines Corporation | Database access control for multi-tier processing |
| CN113158204A (zh) * | 2021-04-09 | 2021-07-23 | 深圳市联软科技股份有限公司 | 一种docker容器访问控制宿主机的方法及系统 |
Family Cites Families (18)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CA1252903A (en) * | 1985-06-11 | 1989-04-18 | Frank D. Bartocci | Dynamic update of database directories using directed or undirected mechanisms |
| US5377323A (en) * | 1991-09-13 | 1994-12-27 | Sun Microsytems, Inc. | Apparatus and method for a federated naming system which can resolve a composite name composed of names from any number of disparate naming systems |
| EP0930566A3 (en) * | 1992-07-06 | 2006-07-05 | Microsoft Corporation | Method and system for composing objects |
| US5497463A (en) * | 1992-09-25 | 1996-03-05 | Bull Hn Information Systems Inc. | Ally mechanism for interconnecting non-distributed computing environment (DCE) and DCE systems to operate in a network system |
| US5805885A (en) * | 1992-12-24 | 1998-09-08 | Microsoft Corporation | Method and system for aggregating objects |
| US5491817A (en) * | 1993-05-25 | 1996-02-13 | Bell Communications Research Inc. | Linking system and method for accessing directory information about an object in one context when information in another context is known |
| US5485617A (en) * | 1993-12-13 | 1996-01-16 | Microsoft Corporation | Method and system for dynamically generating object connections |
| US5548726A (en) * | 1993-12-17 | 1996-08-20 | Taligeni, Inc. | System for activating new service in client server network by reconfiguring the multilayer network protocol stack dynamically within the server node |
| US5689700A (en) * | 1993-12-29 | 1997-11-18 | Microsoft Corporation | Unification of directory service with file system services |
| US5588147A (en) * | 1994-01-14 | 1996-12-24 | Microsoft Corporation | Replication facility |
| US5911066A (en) * | 1994-02-22 | 1999-06-08 | Microsoft Corporation | Data transfer utilizing a single functionally independent data transfer mechanism |
| US5600831A (en) * | 1994-02-28 | 1997-02-04 | Lucent Technologies Inc. | Apparatus and methods for retrieving information by modifying query plan based on description of information sources |
| US5682532A (en) * | 1994-05-02 | 1997-10-28 | Microsoft Corporation | System and method having programmable containers with functionality for managing objects |
| US5831606A (en) * | 1994-12-13 | 1998-11-03 | Microsoft Corporation | Shell extensions for an operating system |
| US5682478A (en) * | 1995-01-19 | 1997-10-28 | Microsoft Corporation | Method and apparatus for supporting multiple, simultaneous services over multiple, simultaneous connections between a client and network server |
| US5692180A (en) * | 1995-01-31 | 1997-11-25 | International Business Machines Corporation | Object-oriented cell directory database for a distributed computing environment |
| US5893107A (en) * | 1996-07-01 | 1999-04-06 | Microsoft Corporation | Method and system for uniformly accessing multiple directory services |
| US6016499A (en) * | 1997-07-21 | 2000-01-18 | Novell, Inc. | System and method for accessing a directory services respository |
-
1996
- 1996-07-01 US US08/674,318 patent/US5893107A/en not_active Expired - Lifetime
-
1997
- 1997-06-27 CA CA002209170A patent/CA2209170C/en not_active Expired - Lifetime
- 1997-07-01 EP EP04014741.5A patent/EP1460565B1/en not_active Expired - Lifetime
- 1997-07-01 DE DE69730657T patent/DE69730657T2/de not_active Expired - Lifetime
- 1997-07-01 EP EP97110830A patent/EP0817101B1/en not_active Expired - Lifetime
- 1997-07-01 JP JP21114897A patent/JP4197753B2/ja not_active Expired - Lifetime
-
1998
- 1998-11-18 US US09/195,568 patent/US6360230B1/en not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| EP1460565B1 (en) | 2017-08-02 |
| EP0817101A3 (en) | 1998-07-29 |
| DE69730657T2 (de) | 2005-02-10 |
| US6360230B1 (en) | 2002-03-19 |
| DE69730657D1 (de) | 2004-10-21 |
| US5893107A (en) | 1999-04-06 |
| EP1460565A1 (en) | 2004-09-22 |
| EP0817101A2 (en) | 1998-01-07 |
| CA2209170C (en) | 2006-02-07 |
| CA2209170A1 (en) | 1998-01-01 |
| JPH10154095A (ja) | 1998-06-09 |
| EP0817101B1 (en) | 2004-09-15 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4197753B2 (ja) | 多数ディレクトリサービスに一様にアクセスするための方法及びシステム | |
| US5787280A (en) | Apparatus and method for providing a facility for managing versions and configurations of persistent and transient objects | |
| US5682532A (en) | System and method having programmable containers with functionality for managing objects | |
| CN101329636B (zh) | 虚拟化窗口信息的方法和设备 | |
| US5815703A (en) | Computer-based uniform data interface (UDI) method and system using an application programming interface (API) | |
| US7584207B2 (en) | Customization of metadata describing objects in a computing environment | |
| US5838918A (en) | Distributing system configuration information from a manager machine to subscribed endpoint machines in a distrubuted computing environment | |
| JP4365142B2 (ja) | プロパティをオブジェクトに関連付けするための、コンピュータ可読媒体、システム、および、方法 | |
| US5797128A (en) | System and method for implementing a hierarchical policy for computer system administration | |
| US6366921B1 (en) | System and method for data manipulation in a dynamic object-based format | |
| US7840597B2 (en) | Method and apparatus for managing metadata associated with entities in a computing system | |
| US6385767B1 (en) | Method and system for creating and manipulating extensions to version control systems | |
| US6789086B2 (en) | System and method for retrieving registry data | |
| US20070106629A1 (en) | System and method for accessing data | |
| JP2004280830A (ja) | ソフトウェアシステムのための拡張可能なカスタマイズフレームワーク | |
| US20120246664A1 (en) | Method for providing stand-in objects | |
| JP2004280814A (ja) | ソフトウェアシステム内での処理ロジックのカスタマイズ方法 | |
| US20060031817A1 (en) | Integrated dynamic control flow and functionality generation for network computing environments | |
| US20110029577A1 (en) | Computer program product and method for sharing information between multiple computer applications using a grafted model network | |
| US6401100B1 (en) | Method for associating classes contained in the same or different models | |
| JP2006504194A (ja) | 透過的ｅｊｂサポート及び水平データパーティショニング | |
| WO2002046909A1 (en) | Automatically deploy and upgrade an application based on markup language application definition | |
| JP2004272911A (ja) | コンピューティング環境におけるオブジェクト内のフィールドのカスタマイズ | |
| US7702648B1 (en) | Localization of data represented by business entities |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20040510 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20071015 |
|
| A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20080115 |
|
| A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20080118 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080415 |
|
| 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: 20080916 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20080930 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111010 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121010 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121010 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131010 Year of fee payment: 5 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313113 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| 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 |