ジョン・テーラー著

5コンピューターのディレクトリとは、更新用というより検索用に最適化された特殊なデータベースです。(DOSのDIRコマンドを使用して表示されるファイル・システムのディレクトリとは異なります。) ディレクトリの検索は電話帳で名前を探すのに似ていますが、もっと柔軟にしかもすばやく検索できるようになっています。個々のオブジェクトの名前を知らない場合でも、特定のオブジェクト集合に当てはまる条件を指定してディレクトリを検索することができます。

ディレクトリは主として個人情報（たとえば電子メール・アドレス、ファックス番号など）を格納しておくために使用しますが、アプリケーションやネットワーク・サービスに対してユーザーを認証するために使用する場合が増えてきています。システム管理用アプリケーションも、ネットワークのバンド幅の利用といったシステム資源をプロファイル・ベースで管理したり、近くにあるPostScript対応カラー・プリンターを探したりするためにディレクトリを使用する例が出始めています。

ノーツ/ドミノでは、ドミノ・ディレクトリは主に電子メールやカレンダー用に使用されているように（ユーザーにとっては）見えますが、実際はユーザー（ノーツ・クライアントおよびWebクライアントのいずれも）を認証する際にディレクトリを使用しているという意味であらゆるドミノ・アプリケーションがディレクトリと対応しています。ディレクトリがないとドミノを使用することはできません。ディレクトリはまさにドミノという製品の心臓部なのです。他のアプリケーション（たとえばWebSphereアプリケーション）も認証にドミノ・ディレクトリを使用している場合があります。

ドミノ・ディレクトリのコンポーネント

ドミノ・ディレクトリは元々ノーツの公開アドレス帳（NAB: Name and Address Book）と呼ばれていました。しかしノーツ・クライアントにも個人アドレス帳と呼ばれる個人用ディレクトリがあります。またややこしいことに、ノーツのディレクトリ・データベースもドミノのディレクトリ・データベースもNames.NSFと呼ばれています。

サーバーのプライマリ・ドミノ・ディレクトリはサーバーを登録しておくディレクトリで、サーバーのノーツ・ドメインに関連付けられています。標準のノーツ・データベース複製機能を使用してドミノ・サーバー間でディレクトリを共有することができます。各サーバーに独自のプライマリ・ドミノ・ディレクトリがありますが、ドメイン内で同じディレクトリ・イメージを共有しています。

各ユーザー・エントリをユーザー文書と呼びます。ユーザーは電子メールの配信、アプリケーションの認証のどちらの場合もグループに関連付けることができます。ユーザーとグループ用のビューがあり、さらにはユーザー（たとえば退社した社員）をすばやく除外できるように「#Deny Access」というグループもあります。サーバー・ビューの他のエントリはサーバー、接続、認証、統計などといった構成タスクを処理します。

ディレクトリ・カタログはR5で導入された新しいオプションです。ディレクトリ・カタログは複数のディレクトリを集約してオンラインまたはオフライン用に使用できるようにしたものです。ディレクトリ・カタログの設計の主要ポイントはサイズを小さくしてモバイル・ユーザーをサポートすることでした。ディレクトリ・カタログを使用してIBM社員はノートPC内に会社のディレクトリ全体を20MB以下で持ち歩くことができます。

ドミノとLDAP

ディレクトリの世界で知っておかなければならない最も重要な項目はLDAP（Lightweight Directory Access Protocol：軽量ディレクトリ・アクセス・プロトコル）です。LDAPは、最初のディレクトリ標準であるX.500に準拠したディレクトリにアクセスするための、IPベースのインターネット標準です。ほとんどのネットワーク・オペレーティング・システム、グループウェア、ネットワーク・アプリケーションがLDAPをサポートしており、今やディレクトリがユーザー、アプリケーション、他のディレクトリとやりとりする際の確立された方法となっています。

あらゆる電子メール・クライアント（ノーツ、Netscape Communicator、Microsoft Outlookなど）はディレクトリ検索機能を使用してLDAPディレクトリにアクセスできます。クライアントはローカルのLDAPディレクトリだけでなく、YahooやVerisignといったインターネット・ベースのLDAPディレクトリ内も検索することができます。ノーツ/ドミノはR5以降主要なLDAP標準のほとんどをサポートしており、ノーツ/ドミノ6（ND6については後述します）ではさらにサポートが強化されています。

LDAPを使用して認証要求を渡すこともできます。たとえばWebサイト上でドミノとWebSphereを結合してスケーラビリティを向上させeコマースを実現したいが、その際セキュリティ管理下にあるユーザーに対してこの2つのアプリケーションで別々にサインオンさせたくないとしましょう。こうするにはドミノ・ディレクトリをLDAPに対応させ、WebSphereに対して認証にはドミノ・ディレクトリを使用するように指示するだけでよいのです。また、ドミノは他のLDAPディレクトリ（たとえばOS/400のLDAPディレクトリ）を使用することもできます。

OS/400との統合

OS/400の長所の一つにディレクトリ･オプションの豊富さが挙げられます。一方、OS/400の弱点もディレクトリ･オプションが多いことなのです。

OS/400はドミノ･ディレクトリ用の最も重要なサーバー環境です。つまり、他のUnixプラットフォームをすべてあわせたよりもOS/400のドミノ・ライセンス数の方が多く（Windowsについで二番目）、大規模なドミノ環境のほとんどがOS/400上でホスティングされています。

OS/400のドミノ･ディレクトリに最も近いのはユーザー･プロファイルではないかと思うかもしれません。今日現在、ユーザー･プロファイルがユーザーを認証する通常の方法だからです。しかしユーザー･プロファイルは厳密な意味ではディレクトリではありません。

OS/400にはシステム・ディストリビューション・ディレクトリ（SDD）もあります。SDDはDB2内に格納されており、X.500標準をサポートしています。SDDはSNAディストリビューション・サービス（SNADS）、OV/400、iSeries Access（旧Client Access）、NetServer、メール・サーバー・フレームワーク（AnyMail/400）、SMTP、Facsimile Suport/400、OS/400ドキュメント・ライブラリ・シリーズ（/QDLSまたは共有フォルダ）などが使用しています。これらのアプリケーションのユーザーはすでにSDDにエンロールされているので、起動前にSDDにかなりのコンテンツが格納されているはずです。

SDDはローカルとリモート両方の個人に関する情報を一覧表示します。すべてのエントリにユーザーID、アドレス、説明があります。オプションのフィールドとしては、姓名、肩書き、会社名、勤務地、部署名、電話番号、Fax番号、住所、ユーザー定義フィールドがあります。電子メール・アドレスはSNADS（OV/400が使用）、X.400、SMTP、cc:Mail用にフォーマットできますし、ユーザー定義フォーマットにすることもできます。SDD APIを使用して社員の入退社時に人事アプリケーションからディレクトリを自動的に更新するようにしているお客様もいらっしゃいます。

OS/400のディレクトリ・シャドーイングにより、複数のOS/400システムのSDD中のエントリを同期させることができます。OS/400ネットワークに対してすべてのSDDが1セットのディレクトリ・データとなるよう設定するためには、ディレクトリ・シャドーイングが必要となる場合がほとんどです。

ドミノR5では、OS/400用のディレクトリ同期機能によりドミノ・ディレクトリ中のユーザー情報とOS/400のSDDのユーザー情報を自動的に同期させることができます。この機能を利用するにはOS/400上で1台のドミノ・サーバーを稼動させる必要があります。

OS/400ではV4R3以降、ディレクトリ・サーバー（旧SecureWayディレクトリ）、LDAPサーバー、およびC、Cobol、RPG、Client Access、Java、コマンドラインなどからアクセスするための完全なLDAPクライアント・セットが備わっています。このLDAPサーバーはオペレーティング・システムに組み込まれており、ディレクトリ情報を格納するためにDB2を使用しています。OS/400はネットワーク・ハードウェアやネットワーク・ソフトウェアのインベントリをLDAPディレクトリ中に格納する機能をサポートしています。またユーザー定義データも追加することができます。

SDDのエントリをこのLDAPサーバーに自動的にパブリッシュすることができ、SDDが更新されたときに同期を取ることができます。OS/400およびLDAPの詳細については http://www-1.ibm.com/servers/eserver/iseries/ldapをご覧ください。

以上により、すべてのディレクトリ・タイプをリンクさせるためにはユーザー・プロファイルからSDDへの同期機能の実装だけが必要となります。IBMはドミノとOS/400を統合するためのBlueNotesファミリーとしてさまざまな製品を発表しています。この処理を自動化するためにBlueNotesディレクトリ・ビルダー・コンポーネントが有用となる場合があります。詳細については
http://www-1.ibm.com/servers/eserver/iseries/ldap/ldapbp.htmをご覧ください。

なぜ分類が必要か

ドミノのディレクトリは良くできていますが、一点だけ足りないところがあります。それは分類です。分類は単なる階層的に構造化されたインデックスです。たとえばYahooのホームページはその例です。YahooのホームページではWeb上のすべての情報のカテゴリ（たとえば、「芸術と人文」、「ビジネスと経済」など）を定義しています。自社のビジネスには、たとえば事業部、部、所在地、製品群などといった異なるカテゴリを使用することができます。

OS/400のSDDといった完全にX.500をベースとしたディレクトリと異なり、ドミノ･ディレクトリには所在地や部署などのフィールド用には階層がありません。エントリはプロンプトなしに手入力され、お互いに無関係です。ドミノ・ディレクトリでは、ユーザー文書のオフィス/自宅-組織階層情報フィールドを更新してアドレスを検索する際に組織階層ビューを使用すれば、エントリを階層表示できるようにする方法があります。こうすれば、単純な名前別一覧ではなく、南北アメリカ/米国/ミネソタ州/ロチェスター（図1）やeServer/iSeries/ソフトウェア/開発などといったビューを表示させることができます。

とはいえすべてのユーザーに対して上記の28個の階層フィールドを手操作で管理したくはないでしょう。BlueNotesディレクトリ・ビルダーの分類モジュールといった製品は、こうした所在地、部署、その他のフィールドからのエントリを構築するためのツールの理想的な例です。「分類された」データベースのサンプルはhttp://www.bluenotes.comのディレクトリ・ビルダーのリンクからダウンロードできます。

ディレクトリの柔軟性

ドミノ・ディレクトリは、複数のアプリケーション間で使用される単一の共有レジストリを可能とするので、ロータスSametimeやQuickPlaceといったドミノをベースとしたアプリケーションで使用することができ、また使用すべきものです。スタッフ・メンバーが抜けた際、そのメンバーをディレクトリから削除するだけでSametimeやQuickPlaceからも自動的に削除されます。

ドミノはネイティブのWebサーバーであるので、連絡先リストの詳細を自動的にイントラネットやインターネットにパブリッシュすることもできます。ドミノ・デザイナーの機能により、ディレクトリをグラフィックに表示するビュー（たとえば、部門の構成に応じた組織図）を構築することができます。これにより、分類をしていればデータをよりわかりやすく表示するビューが得られます。

ノーツとEasySynch Proを使用すると、アドレス帳のレプリカをIBMのWorkPadなどのPDA上に保持することができます。モバイル・ノーツを使用すれば、WAP対応の携帯電話やハイブリッド型のPDAなどといった携帯端末上にディレクトリ全体を保持することもできます。IBM社員が小さなWAPブラウザ上に25万人もの社員のリストを表示させている姿を想像すれば、名前別のリスト表示がどれだけ時間のかかるものか、所在地や上司別に社員をグループ化した分類を使えばどれだけ時間が節約できるかがおわかりいただけるでしょう。

ディレクトリの問題でその重要性がますます大きくなっているものの1つにIBMの企業アイデンティティ・マッピング（EIM）があります。任意のeServerプラットフォーム上では、EIMによりWindows、ドミノ、OS/400、AIXなどといったアプリケーションとオペレーティング・システム間でシングル・サインオンが可能です。EIMは特に大規模で複雑な環境において効果を大きく発揮するツールです。詳細についてはhttp://www-1.ibm.com/servers/eserver/security/eimをご覧ください。

多くのお客様が抱えている問題はEIMのレポジトリをどのようにして各ユーザーのアイデンティティで埋めるか、です。ユーザー・アイデンティティはユーザーがサインオンする場所に対して1つ存在します。Kim Greene Consulting社は、他のコンポーネントと連携してOS/400やディレクトリ・データ（ドミノのディレクトリを含む）を収集して分類し、各ユーザーに対してサインオンをマッピングしEIMにエキスポートできるツールをまもなく出荷すると発表しました。詳細についてはhttp://www.kimgreene.comをご覧ください。

ND6の新機能 ND6はドミノを複数のディレクトリ環境に容易に統合できるようにすることを狙いとしています。分散ディレクトリ・アーキテクチャからドミノを集中型ディレクトリとして使用するアーキテクチャに移行するオプションもあります。ディレクトリ全体を中央のサーバー1台（実際にはディレクトリ・サーバーのフェイルオーバーが自動的に発生するので2台）に格納して、ドメイン内の他方のサーバー上にドミノ固有のデータからなる小規模構成のディレクトリを格納することもできます。中央のディレクトリ情報は全ユーザーが利用可能で、ドメイン中のすべてのサーバー上にこのディレクトリの複製を置いておく必要はありません。

LDAPサポートも新しくなり、LDAP構造を自動的なプロセスで保守、拡張、パブリッシュするための標準的なスキーマや新しいSchema.NSFも追加されました。オブジェクト・クラスの継承もサポートし、LDAPデータ交換ファイル（LDIF）形式によるスキーマのインポートもサポートしています。これにより、ディレクトリ構造を管理しやすい構造に調整することができます。新しいLDAPアップグレード・サービスによりユーザーやグループのエントリをLDAPからディレクトリに移行することができます。2次ディレクトリ（ドミノまたはLDAP）を使用して、HTTPクライアントだけでなくIMAP、POP3、LDAP、NNTPのクライアントをインターネット・クライアントとして認証することもできます。これはドミノがドミノ以外のディレクトリを使えるようにするための過程の第一歩です。

iSeriesをお使いのお客様のほとんどはネットワーク上でWidowsサーバーもお使いです。新しいADSyncプロセスによりプロパティやパスワードを登録、同期させたり、Windows 2000のアクティブ･ディレクトリ中のアクションなどを実行する際にドミノ・ディレクトリ中のユーザーやグループの名前を変更したり削除したりすることができます。

アプリケーション・サービス・プロバイダ（ASP）機能とホスティング機能を新たにサポートしたことにより、1つのディレクトリで複数の組織をサポートすることができます。これによりサーバー管理の複雑さが低減されました。管理者は1台のサーバーで作業しますが、そのサーバーを利用している各組織は組織固有のサーバーでホスティングされているかのように（たとえば、独自のHTTPアプリケーションやファイル・ロケーションおよび組織固有の認証管理など）機能します。テンプレートによりホスティングされている各組織用にきめ細かな構成管理が可能です。ドミノ管理クライアントによりASP業者は新組織の登録、ホスト構成の作成、新しい認証の生成、サブディレクトリの作成、セキュリティ機構の実装を自動化することができます。ディレクトリ中の各文書は拡張ACL（xACL）によってアクセス権が管理されています。物理的に同じサーバーでホスティングされている複数の組織は共有のデータベースにアクセスすることもできます。

ドミノのコードを複数のプラットフォームに渡って標準化するという方針の副作用として、OS/400版ドミノ6ではSDDとドミノ・ディレクトリの同期がサポートされなくなったことが挙げられます。ただし、この機能の代替および拡張に関するソリューションについては、http://www.bluenotes.comのBlueNotesディレクトリ・ビルダーを参照してください。

今後の動向

おそらく今年後半にかけてドミノのリリース6.xでLDAPディレクトリの完全同期がサポートされるでしょう。スケーラビリティについても動きがあるものと期待しています。

IBMがソフトウェア・ポートフォリオをJ2EEベースで開発する動きが勢いを増しているため、製品の脱バンドル化、モジュール化が見え始めてきました。ドミノの部品がWebSphereのコンポーネントとなったり、DB2に格納されているデータを使用したりできるのです。これにより統合に関する問題の解決が容易になります。このシナリオではディレクトリをドミノから分離することが想像できます。ドミノ・ディレクトリを認証に使用したドミノ以外のクライアントもすでにあります。ドミノ以外のLDAPサーバーでノーツ・クライアントを使用することもできます。

OS/400に関しては、V5R2でバックエンド・プロジェクションが備わり、LDAPディレクトリ経由でユーザー・プロファイルにアクセスすることができます。これはディレクトリをユーザー・プロファイルへの「フロント・エンド」にしようとする流れの始まりといえます。

今後、ディレクトリはナレッジ・マネジメント（KM）フレームワークの基礎となっていくでしょう。KMでは、（実在のあるいは仮想的な）場所でミーティングをしたり（知識や文書などの）事物を使用したりする（社員、契約社員、顧客、サプライヤなどの）人間がすべてであるとロータスは説明しています。ディレクトリは実際の人間をKMの人間、場所、事物の中に位置付けます。ディレクトリにより、企業内のインターネット利用が可能なユーザーを取り込み、組織の知的所有権を管理、利用することが可能になります。

すでにIBM自身の企業ディレクトリをオンラインで検索することができます（http://www.ibm.com/contact/employees/us）。こうした機能を提供する企業、少なくともそのデータの一部をビジネス・パートナーに対して提供する企業、が近い将来現れてくるでしょう。95,000社のパートナー企業を持つIBMのような企業の社員がこうしたディレクトリ全てに対して単一の検索でアクセスできるようになったとき、本当の恩恵が得られることになるでしょう。

次の一歩

ドミノにとってディレクトリがいかに重要か、ノーツの電子メール・アドレスで利用する以外にどのように利用できるのか、iSeries上のドミノ・ディレクトリが将来いかに重要なディレクトリ・プラットフォームとなるかについて述べました。これまでご説明したことを理解いただいた上で、ドミノ・ディレクトリについてさらに勉強されたいのであれば、下記の「Redbooks Explaining Domino Director」にリストされているIBMのレッドブックから読み始めるのが良いでしょう。レッドブックはhttp://www.redbooks.ibm.comからダウンロード可能です。グッド・ラック！

ジョン・テーラー氏はIBM、Symantec、AT&T's Global Networkのビジネス・パートナーであるTypex Group Plcのテクニカル・ディレクターです。Typex社はIBMのサーバーとロータス・ドミノを統合し、それをセキュアにインターネットに接続するビジネスの支援を専門としています。テーラー氏はIBMのレッドブックや雑誌記事の執筆も担当し、世界中のユーザー向け会議で講演しています。同氏はIBMのBlueNotesファミリー・ソフトウェア製品のアーキテクトです。同ファミリーはロータス・ノーツ/ドミノにIBM eServerへのインタフェースを提供するものです。同氏はCOMMON UKユーザー・グループの理事を務め、また公認土木技師を職業としており、奥様とお嬢さんと共に英国TyneのNewcastleにお住まいです。