第 14 章 仮想ディレクトリの配備

「仮想ディレクトリ」は Directory Proxy Server の高度な機能の 1 つであり、複数のデータリポジトリの情報をリアルタイムで集約します。この章では、Directory Server Enterprise Edition 配備における仮想ディレクトリの使用方法について説明します。

仮想ディレクトリのアーキテクチャー上の概念については、『Sun Java System Directory Server Enterprise Edition 6.2 Reference』の第 18 章「Directory Proxy Server Virtualization」を参照してください。仮想ディレクトリの設定手順については、『Sun Java System Directory Server Enterprise Edition 6.2 管理ガイド』の第 23 章「Directory Proxy Server による仮想化」を参照してください。

この章で説明する内容は次のとおりです。

• 「どのような場合に仮想ディレクトリを使用すべきか」

• 「仮想ディレクトリの典型的なシナリオ」

どのような場合に仮想ディレクトリを使用すべきか

ディレクトリサービスの要件に次のいずれかが含まれる場合に、仮想ディレクトリの機能を配備できます。

• 複数のデータリポジトリ上に分散するエントリの集約されたビューを、クライアントアプリケーションが必要としている

  たとえば、いくつかのディレクトリサーバーが存在しており、それらのサーバーには同じユーザーが含まれているが、それらがすべて異なるデータであるとします。仮想ディレクトリを使えば、あるユーザーのすべてのディレクトリにわたるエントリの単一ビューを作成できます。さらに、仮想ディレクトリは、個々のすべてのディレクトリを管理するための単一点として機能します。

  サポートされるデータリポジトリの種類としては、LDAP ディレクトリ、MySQL などの Java Database Connectivity ( JDBC^TM) に準拠したソース、LDIF フラットファイルなどが挙げられます。

• ユーザー資格情報とアプリケーション固有データにそれぞれ異なるデータストアが必要である。

  たとえば、アプリケーションによっては、企業ディレクトリ内に格納したくない固有データが存在する可能性があります。仮想ディレクトリを使えば、そうしたデータを分離しても、それがアプリケーションのソースの 1 つとして見えるようにすることができます。これにより、アプリケーション開発やデータ管理が単純化されます。なぜなら、アプリケーションがデータインフラストラクチャーの詳細を知る必要がなくなるからです。さらに、バックエンドデータソースに対する変更をアプリケーションから抽象化できます。

• ユーザーの企業が別の企業を買収したか、別の企業と合併した。

  仮想ディレクトリを使えば、2 つの企業のディレクトリをマージし、それらが単一のディレクトリとして表示されるようにすることができます。たとえば、2 つのディレクトリ dc=example,dc=com および dc=acquisition,dc=com があるとします。どちらのディレクトリも dc=example,dc=com のように見えることを要求するクライアントアプリケーションも存在します。

• データベースのテーブルが DIT 階層の形式で表示されることを、クライアントアプリケーションが要求する。

• 複数のデータリポジトリに対する読み取りおよび書き込み操作が必要である。

• 類似点のない属性名に基づいて複数のフィールドを結合する条件が必要となる。

• 複数の LDAP または JDBC バックエンドのディレクトリやデータベース上に分散する複数値属性のサポートを、クライアントアプリケーションが要求する。

• 属性の名前変更、DN の書き換え、および DN 構文属性の属性値の書き換えが必要となる。

• クライアントアプリケーションごとに、ある単一データリポジトリの異なるビューが必要となる。

仮想ディレクトリの典型的なシナリオ

この節では、仮想ディレクトリがどのようにして特定のビジネス要件を実現するかを示す単純なシナリオを提供します。より複雑なサンプルシナリオや仮想ディレクトリ構成の詳細については、『Sun Java System Directory Server Enterprise Edition 6.2 管理ガイド』の「仮想設定の例」を参照してください。

異なるデータソースからのユーザー ID の結合

Example.com ストアでは、異なる 3 つのデータリポジトリ内にユーザーデータを格納します。Example.com の Directory Server には、ユーザーデータの大部分が格納されています。ユーザーの電子メールアドレスは Active Directory 内に、HR データは MySQL データベース内に、それぞれ格納されています。

Example.com には、すべてのユーザーデータベースの完全なビューを必要とするクライアントアプリケーションがいくつか存在しています。次の図は、あるユーザーの ID の完全なビューを仮想ディレクトリがどのようにしてクライアントアプリケーションに提供するかを示したものです。

図 14–1 複数リポジトリからの集約データの仮想ビュー

既存ディレクトリ構造への新しい企業データのマージ

このシナリオでは、Example.com が新しい企業 Acquisition.com を買収します。この新しい企業のユーザーデータは、専用の Directory Server 内に格納されています。管理上の都合により、Example.com はこのディレクトリの構造を維持することを望んでいます。ただし、特定のクライアントアプリケーションでは、Acquisition.com のユーザーデータを「あたかも」Example.com のユーザーデータであるかのように表示する必要があります。

次の図は、仮想ディレクトリがどのようにして、買収した企業のデータを既存ディレクトリの構造内に仮想化マージするかを示したものです。

図 14–2 買収先ディレクトリのユーザーデータのマージ

Acquisition.com のディレクトリは、ou=people ブランチの下の個別のブランチとして表示されます。Acquisition.com のディレクトリ内のエントリの DN は、仮想ディレクトリ経由で表示される際に変換されます。