というような要件に対して、ディレクトリサービスは答えてくれる。当然、ディレクトリに対してデータが入ってなければ検索はできないが、こういった検索に必要な項目を追加することも可能である。- hogehogeという名前の電子メールアドレスは何?
- unyo@xxxxx,co.jpという電子メールアドレスを持つ人は誰、住所、好きな色は?
- 居住している住所がpekepekeで趣味がkoryakoryaの人は?
- unyo@xxxxx,co.jpという電子メールアドレスを持つ人の証明書は?
ただし、ディレクトリサービスはインタネットでなければ使えないというわけではなく、次バージョンのWindows NTには、アクティブディレクトリなるものでユーザ管理を行うという話がある。Netscape社のサーバ製品群のユーザ管理を同社のディレクトリサーバで一括して行うという話もある。また、イントラネット等を使用して組織内で「職員録」的なものを構築することも可能である。 古くは、Novell社のNDS(Netware Directory Service)や、老舗のX.500なども存在したが、一般には馴染みが薄い。
一般的にいわれるディレクトリサービスの特性は下記の通りである。
|
|
|
処理内容 | 殆ど検索処理 | 更新,検索共に多数存在する |
分散化 | WorldWideな分散化 | ローカル内の分散化 |
トランザクションの概念 | 通常、存在しないが、実装によっては存在する | 存在する |
大サイズファイルの扱い | 可能だが向いていない | 可能だが向いていない |
リアルタイム性 | 不向き | 向いている |
存在感 | 無意識に使用される。
(DNSのように) |
殆どの場合、意識的に使用される。 |
演算、処理結果の格納 | 日々変化するデータの扱いは不向き | 向いている |
全文検索 | 不向き | DBMSによって可能 |
ディレクトリには簡単に情報を詰め込むことができるので、DBMSの様に使いたくなる方も多いと思うが、データ自身の性質を見極めて、個々の長所を生かせる形で利用すべきである。
例えば、オンラインのチケット予約システムの場合、多数の更新が発生する。その更新をすべて正しく処理して、素早くレスポンスを返さなければならない。ディレクトリは、大量の情報から、必要な情報を素早く返すことはある程度可能だが、複数ユーザから同時に更新された場合のデータの整合性は保証できない(実装にも依存するが基本的には)。そうなると、必然的にDBMSを使用すべきであることが見えてくる。プログラミング言語で、同時更新制御等を実現してディレクトリをオンラインチケット予約システムを構築することも当然可能であるが、システム構築をする人間としては、如何に楽して作るかということは、非常に大事なことである。トランザクション制御可能なディレクトリサーバ自身を実装するという人以外は、薦めない。また、後述するLDAPv3に拡張機能に、「トランザクション」のサポートというのがあるが、あくまでも、ディレクトリの原子性(ACID特性のAの部分、確かAtomicityとかいったはず)を保証するに過ぎないと私は思う。DBと同等の同時実行制御等が可能になったとしても、ディレクトリをDBの様に使うべきではないと私は思う。ロック等のAPIが提供されない予定になっているのが顕著な例だと思う。
ディレクトリは、単に、ネットワーク上のプロトコルの標準化だけではなく、全世界でただ一つの分散データベースシステムの構築を目標にしている。それゆえにディレクトリは、通常「The
Directory」と定冠詞をつけて呼ばれる。
X.400電子メール(MHS)の国際勧告が完成すると、CCITTでは、電子メールサービスにおける宛先指定をより容易にする目的で、電子メール利用者に対する情報案内サービスの検討を開始した。また、ISOでは、OSI環境でのネットワーク管理に利用することを想定して、ネットワーク上のリソースの状態を案内する機構の標準化を検討していた。しかし、両者ともシステム内に格納すべきと考えていた情報に違いはあるものの、基本的なメカニズムにはそれほどの差異はないと考えられるようになり、1986年から共同して標準化を行うことを合意し、1988年には同一文書による国際勧告/国際規格が制定された。これが1988年版X.500シリーズ勧告である。
勧告番号 | 勧告名 | 内容 |
X.500 | ディレクトリ:概説
Directory-Overview of Concepts, Models and Services |
X.500シリーズ全体で定義されているディレクトリの概要 |
X.501 | ディレクトリ:モデル
Directory-Models |
ディレクトリの機能、組織のモデル化およびディレクトリに保持されている情報の構造についての定義 |
X.509 | ディレクトリ:認証の枠組み
Directory-Authentication Framework |
ディレクトリに保持されている情報を不整なアクセスから保護するために、サービス要求者を識別、認証する手法 |
X.511 | ディレクトリ:抽象サービス定義
Directory-Abstract Service Definition |
ディレクトリがその利用者に提供するサービスの種類とその動作の定義 |
X.518 | ディレクトリ:分散操作の手順
Directory-Procedures for Distributed Operation |
ディレクトリが複数のシステムから構成されているときの動作及びディレクトリ情報の分散方法 |
X.519 | ディレクトリ:プロトコル仕様
Directory-Protocol Specifications |
ディレクトリ・アクセス・プロトコルおよびディレクトリ・システム・プロトコルの定義 |
X.520 | ディレクトリ:代表的な属性型
Directory-Selected Attribute Types |
ディレクトリ・システムを構築する際に役立つと考えられる情報の種別の定義 |
X.521 | ディレクトリ:代表的なオブジェクト・クラス
Directory-Selected Object Classes |
ディレクトリ・システムを構築する際に役立つと考えられるオブジェクトの分類とそれらがもち得る情報の種別の定義 |
上記勧告に、情報の多重保持、アクセス制御、情報構造モデル、検索機能の拡充が追加されたものが1993年、ITUによって標準として確定した。(この項は、X.500ディレクトリ入門より引用)
属性継承
ある属性を、親属性と呼ばれる他の属性から派生させて作れるようにするものである。派生属性は、他の属性と同様に振る舞うが、親属性は特殊な属性を持っている。検索や比較が親属性に対して行われると、その親属性とそこからの派生属性のすべてが、その問合せに合致しうるのである。
例えば、LDAPv3においては、nameという属性を定義している。このname属性から派生させて、cn,sn,givenName属性を名前関連の属性を定義している。クライアントは、name属性を使うと、名前関連の属性すべてに対して検索することができてしまう。これを利用することによって、新たに名前に関する属性を増やしたとしても、名前属性から派生されて作られていれば、クライアントに変更を加える必要はない。
オペレーション属性
ディレクトリの自分自身を管理するための属性。これは、エントリの一部であるが、この属性を取り扱うには、明示的にこの属性を指示して、検索、修正等を行わなければならない。LDAPv3の機能を使うためにも必要な属性がオペレーション属性として存在するらしい。
例えば、modifiersName、modifiedTimeという二つの属性は、エントリが最後に修正されたDN、時間を表すためにLDAPサーバが自動的に設定するものである。また、modifyRightというオペレーション属性は、要求者が持っているLDAPエントリの様々なフィールドに対するアクセス権を含んでいる。クライアントはこの属性からエントリのどの属性が変更可能かを知る事ができる(LDAPv3で定義されるかどうかは不明)。
2番目の解決策として、LDAPv3は、extensibleObjectと呼ばれる新しいオブジェクトクラスを提案する。この特別なオブジェクトクラスを含むエントリは、他のディレクトリスキーマ規則に関わらず、いかなる属性でも含むことが可能である。
LDAPv2では、サーバがクライアントを他のサーバへ振り向ける方法はない。ミシガン大学、Netscapeの両SDKとも、「委託」をサポートしているが、LDAPv2の裏口を使ってサポートしている。LDAPv3では、委託を明示的にサポートするために新しいプロトコル要素を追加している。
複数のエントリを更新する場合、RDB等と同じ様に、更新対象データすべてが更新終了になったのか、一つも更新されてなのかのどちらかの状態しか有り得ないようにする。いわゆる原子性の確保である。 この処理のために、「トランザクションの開始(begin transaction)」「トランザクションのコミット(commit transaction)」「トランザクションの中断(abort transaction)」というLDAPv3の拡張オペレーションを定義する。
|
|
RFC2251 | Lightweight Directory Access Protocol (v3) |
RFC2252 | Lightweight Directory Access Protocol (v3):Attribute Syntax Definitions |
RFC2253 | Lightweight Directory Access Protocol (v3):
UTF-8 String Representation of Distinguished Names |
RFC2254 | The String Representation of LDAP Search Filters |
RFC2255 | The LDAP URL Format |
RFC2256 | A Summary of the X.500(96) User Schema for use with LDAPv3 |
スタティックの次がダイナミックになり、究極はアクティブになるらしい。
ミシガン大学でLDAP APの仕様、RFC等の論文を作成してきたいわばLDAPの創始者が執筆したI文献である。対象者はLDAP
APIを使用して、ディレクトリアプリケーションを作成するプログラマが対象と思われる。LDAPを利用したアプリケーションを作成するプログラマは必見。読解するには、C言語とネットワークの基礎的な知識が必要と思われる。