JP2000276391A - ディレクトリ同期方法 - Google Patents

Abstract

(57)【要約】 （修正有） 【課題】ディレクトリサービスに登録されるエントリの
数が増加した場合も、ディレクトリサービスとアプリケ
ーションの同期に要する時間を一定に保つ。 【解決手段】更新履歴取得部３は、ディレクトリデータ
に対して行った更新履歴を定期的に取得する。スナップ
ショット逐次更新部１７は、取得した更新履歴を順に参
照し、ディレクトリデータのスナップショットを逐次更
新する。更新種別決定部１８は、更新履歴の内容と、ス
ナップショットの情報に従い、上記アプリケーションサ
ーバへの更新種別を決定する。スキーマ変換部４は、更
新履歴の内容をアプリケーションサーバへの更新へ変換
する。アプリケーションデータ更新部５は、このアプリ
ケーションサーバへの更新内容を基にアプリケーション
サーバの更新を実行することにより、ディレクトリデー
タの同期を行なう。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、ディレクトリサー
ビスに対する更新を、アプリケーションのデータベース
に反映させるディレクトリ同期方法に関する。

【０００２】

【従来の技術】ディレクトリサービスとは、電子メール
の送信相手の姓名等から電子メールの宛先を検索できる
サービスであり、電子メールシステムにおける電子的な
電話帳機能として利用されている。

【０００３】ディレクトリサービスに関する標準として
は、ＣＣＩＴＴの勧告であるＸ．５００（ＩＳＯ９５９
４）が挙げられる。Ｘ．５００は、ディレクトリサービ
スをクライアント−サーバ型の分散システム・アーキテ
クチャとして規定しており、クライアント−サーバ間の
通信プロトコルとしてＯＳＩ（Open Systems Interconn
ection）の７レイヤ構造に従ったＤＡＰ（Directory Ac
cess Protocol）を定めている。

【０００４】Ｘ．５００準拠のディレクトリサービス
は、木構造（ディレクトリツリー）として階層管理され
たデータモデルを有する。木の枝葉に相当する個所に
は、ディレクトリエントリが配置される。各々のエント
リは、同一の親エントリを持つエントリ間で一意である
相対名称（ＲＤＮ：Relative Distinguished Name）
と、木構造の根（ルート）からの経路を示すＲＤＮの列
である名称（ＤＮ：Distinguished Name）で一意に識別
される。各々のエントリはユーザのメールアドレスに加
え、姓名、電話番号、ＦＡＸ番号、写真等、様々な情報
を属性として記憶可能である。エントリは、必ず１つ以
上のオブジェクトクラスに属する。ここで、オブジェク
トクラスとは、或るエントリに存在しなければならない
必須の属性、及び存在しても良い属性の集合を定義す
る。このオブジェクトクラス定義と木構造の定義をあわ
せ、ディレクトリスキーマと称している。

【０００５】一方、インターネットにおける標準化機関
であるＩＥＴＦ（Internet Engineering Task Force）
は、ＴＣＰ／ＩＰスタック上で動作するディレクトリ・
クライアント−サーバ間プロトコルとして「ＬＤＡＰ：
Light Weight Directory Access Protocol(RFC2251)」
を標準化している。ＬＤＡＰは、ＯＳＩスタック上で動
作するＤＡＰに比べて軽量である。

【０００６】ところで、最近の企業内、或いは企業間に
跨る大規模情報システムにおいては、電子メールシステ
ムやグループウェアなどの複数のアプリケーションを導
入している事が多く、システム管理者は新入社員の入社
や人事異動が発生する度に、複数のアプリケーションへ
ユーザ登録を行なう必要がある。ところが、このような
大規模情報システムにおいて実際に稼動しているアプリ
ケーションの多くは、ユーザ情報を独自のデータベース
を用いて、独自の形式で登録，管理しているため、一元
管理は困難であるのが現状である。

【０００７】この問題を解決する技術として期待されて
いるのが、ディレクトリ同期技術である。ディレクトリ
同期技術とは、従来各アプリケーションが独自に登録，
管理していた情報を全てディレクトリサービスにも登録
して、ユーザ情報の更新は全てディレクトリサービスに
対して行うよう一元化するとともに、ディレクトリサー
ビスに対して行われた更新を自動的にアプリケーション
のデータベースへ反映させる事により、ディレクトリサ
ービスに登録された情報とアプリケーションのデータベ
ースに登録された情報を同期させる技術である。

【０００８】ディレクトリ同期技術において、ディレク
トリサービスに対する更新をアプリケーションのデータ
ベースへ反映させる方法には、同期的反映方法と、非同
期的反映方法がある。同期的反映方法は、ディレクトリ
サービスに対して更新が実行された時点で、アプリケー
ションのデータベースを更新する方法であり、ディレク
トリサービスの情報とアプリケーションの情報の間の整
合性がリアルタイムで保たれるものである。一方、非同
期的反映方法は、指定された時刻、或いは一定間隔でデ
ィレクトリサービスの情報とアプリケーションの情報を
同期させる方法であり、ディレクトリサービスに対する
更新性能が劣化しないものである。

【０００９】非同期的反映方法を用いて同期を行うディ
レクトリ同期技術の具体例として、例えば、Zoomit社が
開発したディレクトリ同期製品Zoomit VIAが知られてい
る。Zoomit VIAでは、同期処理を行う際、ディレクトリ
サービス上に存在する全ディレクトリエントリの情報
（スナップショット）と、前回同期処理を行った時点で
のスナップショットとの差分をとることで、アプリケー
ションに対して追加，変更，削除すべきユーザ情報を取
得する。つまり、最初に、前回の同期処理時に取得した
スナップショットから、共通エントリと、それとリンク
している固有エントリの組を洗い出す。次に、今回の同
期処理時に取得したスナップショットに関しても、同様
の処理を行う。そして、前回取得したスナップショット
には存在せず、今回取得したスナップショットには存在
するエントリの組に関しては、それらに登録されたユー
ザ情報をアプリケーションデータに対して追加する。逆
に、前回取得したスナップショットには存在したが、今
回取得したスナップショットには存在しないエントリの
組に関しては、アプリケーションデータからユーザ情報
を削除する。どちらのスナップショットにも存在するエ
ントリの組に関しては、属性値を比較し、変更があれ
ば、その変更をアプリケーションに対して反映する。変
更が無い場合は、アプリケーションに対する更新は行わ
ないものである。

【００１０】

【発明が解決しようとする課題】しかしながら、従来の
非同期的反映方法を用いて同期を行うディレクトリ同期
方法では、ディレクトリサービスに登録するディレクト
リエントリの数が増加する毎に、ディレクトリサービス
のスナップショットの容量も増大するため、スナップシ
ョットを取得する処理に要する時間が比例的に増加し、
結果として、ディレクトリサービスとアプリケーション
の同期に要する時間が比例的に増加するという問題があ
った。

【００１１】本発明の目的は、ディレクトリサービスに
登録されるディレクトリエントリの数が増加した場合
も、ディレクトリサービスとアプリケーションの同期に
要する時間を一定に保つことができるディレクトリ同期
方法を提供することにある。

【００１２】

【課題を解決するための手段】（１）上記目的を達成す
るため、本発明は、ディレクトリサーバに記憶されたデ
ィレクトリデータと、このディレクトリサーバにネット
ワークを介して接続された少なくとも１つ以上のアプリ
ケーションサーバに記憶されたアプリケーションデータ
との同期を行なうディレクトリ同期方法において、Ａ）
上記ディレクトリデータに対して行った更新履歴を定期
的に取得し、Ｂ）この取得した更新履歴を順に参照し、
ディレクトリデータのスナップショットを逐次更新し、
Ｃ）更新履歴の内容と、スナップショットの情報に従
い、上記アプリケーションサーバへの更新種別を決定
し、Ｄ）更新履歴の内容をアプリケーションサーバへの
更新へ変換し、Ｅ）このアプリケーションサーバへの更
新内容を基にアプリケーションサーバの更新を実行する
ようにしたものである。かかる方法により、ディレクト
リサービスに登録されるディレクトリエントリの数が増
加した場合も、ディレクトリサービスとアプリケーショ
ンの同期に要する時間を一定に保ち得るものとなる。

【００１３】

【発明の実施の形態】以下、図１〜図２３を用いて、本
発明の一実施形態によるディレクトリ同期方法について
説明する。最初に、図１を用いて、本実施形態によるデ
ィレクトリ同期方法を実行するディレクトリ同期システ
ムの構成について説明する。

【００１４】ディレクトリサーバ１は、ディレクトリデ
ータ１１をデータベース（ＤＢ）１４に記憶し、ディレ
クトリデータ１１に対する更新の履歴を、更新履歴記憶
領域１６に記憶する。更新履歴記憶領域１６に記憶され
る更新履歴の構成については、図６を用いて後述する。

【００１５】アプリケーションサーバ１２は、アプリケ
ーションデータ１３を、データベース（ＤＢ）１５に記
憶している。ディレクトリサーバ１とアプリケーション
サーバ１２は、ＬＡＮ等のネットワーク３０によって、
ディレクトリ同期サーバ２と接続されている。

【００１６】ディレクトリ同期サーバ２は、更新履歴取
得部３と、スキーマ変換部４と、アプリケーションデー
タ更新部５と、フィルタリング規則テーブル６と、スキ
ーマ変換規則テーブル７と、更新履歴情報８と、ディレ
クトリデータ１１のスナップショット９と、同期内容テ
ーブル１０と、スナップショット逐次更新部１７と、更
新種別決定部１８とを有している。

【００１７】更新履歴取得部３は、ディレクトリサーバ
１が出力した更新履歴を取得し、更新履歴情報８を更新
するものであり、その処理内容については、図１２を用
いて後述する。更新履歴情報８は、ディレクトリサーバ
１の更新履歴を記憶するものであり、そのデータ構成に
ついては、図７を用いて後述する。

【００１８】スキーマ変換部４は、スキーマ変換規則テ
ーブル７を参照し、更新履歴情報８に記憶されたディレ
クトリデータ１１に対する更新内容をアプリケーション
データ１３に対する更新内容に変換するものであり、そ
の処理内容については、図１３を用いて後述する。スキ
ーマ変換規則テーブル７は、ディレクトリデータ１１を
アプリケーションデータ１３へ変換する際の変換規則を
記憶するものであり、そのデータ構成ついては、図５及
び図６を用いて後述する。

【００１９】更新種別決定部１８は、更新履歴情報８に
記憶された更新に対する同期処理を行う際に、フィルタ
リング規則テーブル６とスナップショット９を参照し、
アプリケーションデータ１３に対する更新種別を決定す
るものであり、その処理内容については、図１４〜図１
８を用いて後述する。フィルタリング規則テーブル６
は、全ディレクトリエントリの内、アプリケーションデ
ータ１３との同期が必要なディレクトリエントリの選別
規則を記憶するものであり、そのデータ構成について
は、図４を用いて後述する。また、スナップショット９
のデータ構成については、図９を用いて後述し、スナッ
プショット９内に形成されるリンクインデックス７０の
データ構成については、図１０を用いて後述する。

【００２０】スナップショット逐次更新部１７は、更新
履歴情報８に記憶された更新を、スナップショット９に
反映するものであり、その処理内容については、図１９
〜図２２を用いて後述する。

【００２１】アプリケーションデータ更新部５は、同期
内容テーブル１０に記憶された更新内容に従ってアプリ
ケーションサーバ１２に対して更新要求を発行するもの
であり、その処理内容については、図２３を用いて後述
する。同期内容テーブル１０は、アプリケーションデー
タ１３に対する更新内容を記憶しており、そのデータ構
成については、図１１を用いて後述する。

【００２２】次に、図２を用いて、本実施形態によるデ
ィレクトリシステムを構成するディレクトリサーバ１，
アプリケーションサーバ１２及びディレクトリ同期サー
バ２のシステム構成について説明する。なお、図１と同
一符号は、同一部分を示している。

【００２３】ディレクトリサーバ１は、中央演算装置Ｃ
ＰＵ２５ｄと、ハードディスク装置等の磁気ディスク２
４ｄと、磁気ディスク２４ｄを制御するディスクコント
ローラ２３ｄと、ＯＳ２２ｄとディレクトリサーバプロ
グラム２０ｄを記憶する主メモリ２１ｄと、ＬＡＮ３０
を介した他マシンとの通信を制御するＬＡＮコントロー
ラ２６ｄとを備えている。ディレクトリサーバプログラ
ム２０ｄは、当初磁気ディスク２４ｄに格納され、必要
に応じて主メモリ２１ｄに転送された後、ＣＰＵ２５ｄ
で実行される。図１に示したＤＢ１４は、ディレクトリ
データ１１を磁気ディスク２４ｄ上にファイルとして格
納する。また、ディレクトリサーバプログラム２０ｄ
は、更新履歴記憶領域１６を磁気ディスク２４ｄ上にフ
ァイルとして格納する。

【００２４】また、アプリケーションサーバ１２は、Ｃ
ＰＵ２５ａと、磁気ディスク２４ａと、ディスクコント
ローラ２３ａと、ＯＳ２２ａとアプリケーションサーバ
プログラム２０ａを記憶する主メモリ２１ａと、ＬＡＮ
コントローラ２６ａとを備えている。アプリケーション
サーバプログラム２０ａは、当初磁気ディスク２４ａに
格納され、必要に応じて主メモリ２１ａに転送された
後、ＣＰＵ２５ａで実行される。図１に示したＤＢ１５
は、アプリケーションデータ１３を磁気ディスク２４ａ
上にファイルとして格納する。

【００２５】ディレクトリ同期サーバ２は、ＣＰＵ２５
ｓと、磁気ディスク２４ｓと、ディスクコントローラ２
３ｓと、ＯＳ２２ｓとディレクトリ同期プログラム２０
ｓを記憶する主メモリ２１ｓと、ＬＡＮコントローラ２
６ｓとを備えている。ディレクトリ同期プログラム２０
ｓは、図１に示した更新履歴取得部３の処理内容である
更新履歴取得プログラム３’と、更新種別決定部１８の
処理内容である更新種別決定プログラム１８’と、スキ
ーマ変換部４の処理内容であるスキーマ変換プログラム
４’と、スナップショット逐次更新部１７の処理内容で
あるスナップショット逐次更新プログラム１７’と、ア
プリケーションデータ更新部５の処理内容であるアプリ
ケーションデータ更新プログラム５’とから構成され
る。これらのプログラムは、当初磁気ディスク２４ｓに
格納され、必要に応じて主メモリ２１ｓに転送された
後、ＣＰＵ２５ｓで実行される。また、磁気ディスク２
４ｓには、スナップショット９と、同期内容テーブル１
０と、変更履歴情報８と、フィルタリング規則テーブル
６と、スキーマ変換規則テーブル７がファイルとして格
納される。

【００２６】ここで、図３を用いて、ディレクトリデー
タの論理構造について説明する。ディレクトリ同期技術
において、アプリケーションデータをディレクトリサー
ビスに登録する際のディレクトリスキーマとして、アプ
リケーションが管理するユーザ情報を、アプリケーショ
ンに依存しない情報（氏名，電話番号など）と、アプリ
ケーション固有の情報（アプリケーションサーバのホス
ト名など）に分類し、それぞれの情報を異なるディレク
トリツリーのディレクトリエントリに登録するディレク
トリスキーマを用いている。

【００２７】図３は、ディレクトリスキーマに従って登
録されたディレクトリデータの論理構造を示している。
アプリケーションデータ１３は、アプリケーションが利
用するユーザなどの情報であり、或る一つのユーザ情報
は、アプリケーションに依存しない情報である共通情報
４６と、アプリケーション固有の情報４７に分類され
る。

【００２８】一方、ディレクトリデータ１１は、ディレ
クトリサービスが登録，管理する情報である。アプリケ
ーションのユーザ情報は、ディレクトリデータ１１にお
いては、別のディレクトリツリーに属する２つのディレ
クトリエントリに分割して格納される。すなわち、共通
情報４６は、共通ツリー４０に属するエントリに、アプ
リケーション固有情報４７は、アプリケーション固有ツ
リー４１に属するエントリにそれぞれ格納される。共通
ツリー４０は、ＣＣＩＴＴ勧告であるＸ．５２１や「A
Summary of the X.500(96) User Schema for use with
LDAPv3(RFC2256）」で定義されている標準的なディレク
トリスキーマに従って登録される共通エントリ４２から
成る。アプリケーション固有ツリー４１は、アプリケー
ション固有のディレクトリスキーマに従って登録される
固有エントリ４３から成る。

【００２９】また、アプリケーション非依存の情報を格
納する共通エントリ４２と、アプリケーション固有の情
報を格納する固有エントリ４３の間には、同一のユーザ
の情報を格納することを表すリンク４５が設定される。
リンク４５は、固有エントリ４３に共通エントリ４２の
名称を格納する属性を持たせることを示している。

【００３０】ここで、共通エントリ４２と固有エントリ
４３は、個別にディレクトリサービスに登録，更新，削
除され得る。また、リンク４５も、固有エントリ４３を
登録した後に、遅れて設定され得る。

【００３１】次に、図４〜図１１を用いて、本実施形態
において用いる各テーブルのデータ構造について説明す
る。最初に、図４を用いて、本実施形態によるディレク
トリ同期方法に用いるフィルタリング規則テーブル６の
データ構造について説明する。

【００３２】フィルタリング規則テーブル６は、同期の
対象となるディレクトリエントリの選別規則に関する情
報及び選別されたディレクトリエントリが共通エントリ
か固有エントリかを表す情報を記憶している。フィルタ
リング規則テーブル６は、配列構造をなし、フィルタリ
ング規則を複数格納可能である。

【００３３】フィルタリング規則テーブル６は、テーブ
ル中のレコードを一意に識別する為の識別名の記憶領域
９０と、同期対象となるディレクトリツリーを指定する
ベースエントリの名称の記憶領域９１と、スコープの記
憶領域９２と、ベースエントリとスコープで指定された
範囲に属するディレクトリエントリの内、同期対象とな
るディレクトリエントリを更に選別する為のフィルタ条
件の記憶領域９３と、当該フィルタリング規則に適合す
るディレクトリエントリが、図３に示した共通エントリ
４２か、固有エントリ４３かを表すエントリ種別の記憶
領域９４とから構成されている。

【００３４】フィルタリング規則テーブル６の情報例９
５に示すように、例えば、識別名９０である「filUsr」
は、このフィルタリング規則テーブルが、「ユーザ(Use
r)」のフィルタリングのテーブルであることを示してい
る。また、例えば、ベースエントリ名称９１である「OU
=PEOPLE,O=XYZ,C=JP」は、ベースエントリ名称が、国コ
ード（C=Country Code）が日本(JP)で、会社名（組織
名）(O=Orgnization)がＸＹＺ会社で、組織単位（OU=Or
ganization Unit）が人事(PEOPLE)であることを示して
いる。また、スコープ９２である「subtree」は、スコ
ープがベースエントリ以下の全エントリ(Subtree)であ
ることを示している。なお、スコープ９２としては、他
に、「base」(ベースエントリのみ)、「onelevel」(ベ
ースエントリの子エントリ)等がある。さらに、フィル
タ条件９３である「(objectclass=inetOrgPerson)」
は、OjbectClassの属性として、ＩＦＴＦで、人を表す
ものとして標準化されたものであることを示している。
また、エントリ種別９４である「0」は、フィルタリン
グ規則に適合するディレクトリエントリが、共通エント
リ４２であることを示している。なお、エントリ種別９
４である「1」の場合には、フィルタリング規則に適合
するディレクトリエントリが固有エントリ４３であるこ
とを示している。

【００３５】フィルタリング規則テーブル６には、同期
処理を開始する前に、少なくとも、共通エントリを選別
するフィルタリング規則と、固有エントリを選別するフ
ィルタリング規則の２規則を登録しておく必要がある。

【００３６】次に、図５を用いて、本実施形態によるデ
ィレクトリ同期方法に用いるスキーマ変換規則テーブル
７のデータ構造について説明する。スキーマ変換規則テ
ーブル７は、ディレクトリデータ１１をアプリケーショ
ンデータ１３へ変換する際の変換規則を記憶するもので
ある。スキーマ変換規則テーブル７は、配列構造をな
し、スキーマ変換規則を複数格納可能である。

【００３７】スキーマ変換規則テーブル７は、テーブル
中のレコードを一意に識別する為の識別名の記憶領域１
００と、スキーマ変換規則を適用する共通エントリ４２
について、それが属するオブジェクトクラスの記憶領域
１０１と、共通エントリの属性に関する属性変換規則の
記憶領域１０２と、スキーマ変換規則を適用する固有エ
ントリ４３について、それが属するオブジェクトクラス
の記憶領域１０３と、固有エントリの属性に関する属性
変換規則の記憶領域１０４と、アプリケーションデータ
１３を一意に識別する値を格納する属性の名称の記憶領
域１０５とから構成されている。

【００３８】スキーマ変換規則テーブル７の情報例１０
６に示すように、例えば、識別名１００である「mapUs
r」は、このスキーマ変換規則テーブルが、「ユーザ(Us
er)」用の変換規則テーブルであることを示している。
また、対象クラス（共通）である「inetOrgPerson」
は、スキーマ変換規則を適用する共通エントリ４２が属
するオブジェクトクラスがＩＦＴＦで、人を表すものと
して標準化されたものであることを示している。

【００３９】ここで、図６を用いて、属性変換規則（共
通）１０２及び属性変換規則（固有）１０４の構成につ
いて説明する。属性変換規則１０２，１０４は、ディレ
クトリデータ１１の属性であるマッピング元属性の名称
１０７と、前記属性に対応するアプリケーションデータ
１３の属性であるマッピング先属性の名称１０８の組か
ら成る。例えば、図５に示した属性変換規則（共通）１
０２である「cn,Name」は、ディレクトリデータ１１の
属性であるマッピング元属性の名称「cn」が、この属性
に対応するアプリケーションデータ１３の属性であるマ
ッピング先属性の名称が「Name」であることを示してお
り、「sn,FamiliyName」ィレクトリデータ１１の属性で
あるマッピング元属性の名称「sn」が、この属性に対応
するアプリケーションデータ１３の属性であるマッピン
グ先属性の名称が「FamilyName」であることを示してい
る。属性変換規則（固有）１０４も同様である。

【００４０】また、対象クラス（固有）１０３である
「app1Person」は、スキーマ変換規則を適用する固有エ
ントリ４１が属するオブジェクトクラスが、図３に示し
たアプリケーション１（App1）であることを示してい
る。さらに、識別子格納属性１０５である「uid」は、
アプリケーションデータ１３を一意に識別する値を格納
する属性の名称が「uid」であることを示している。

【００４１】スキーマ変換規則は、アプリケーションが
管理する情報の種類（ユーザ，組織，情報処理装置等）
毎に必要であり、同期処理を開始する前に登録しておく
必要がある。

【００４２】次に、図７を用いて、本実施形態によるデ
ィレクトリ同期方法に用いる更新履歴記憶領域１６のデ
ータ構造について説明する。図１に示した更新履歴記憶
領域１６は、ディレクトリサーバ１内のディレクトリデ
ータ１１の更新履歴を記憶している。更新履歴記憶領域
１６は、更新履歴テーブル１１０を記憶する。更新履歴
テーブル１１０は、配列構造をなし、更新履歴の内容を
複数格納可能である。

【００４３】更新履歴テーブル１１０は、更新履歴番号
の記憶領域１１１と、更新の対象となるエントリの名称
の記憶領域１１２と、更新種別の記憶領域１１３と、更
新内容の記憶領域１１４とから構成されている。

【００４４】ここで、更新履歴番号１１１とは、各更新
情報を一意に識別するための整数値であり、更新が処理
された順番に１ずつ増加してゆくものである。例えば、
更新履歴テーブル１１０の情報例１１５の中の更新履歴
番号１１１である「１２４５」は、１２４５番目に更新
された番号であることを示している。また、例えば、対
象エントリ名称１１２である「UID=98001,OU=USR,OU=AP
P1,O=XYZ,C=JP」は、図３に示したように、国コード(C)
が日本であり、組織名(O)がXYZ会社であり、単位がアプ
リケーション１(APP1)で、ユーザ(USR)であり、ユーザ
ＩＤ(UID)が９８０００１のエントリを有することを示
している。さらに、更新種別１１３である「add」は、
更新の種別が追加(add)であることを示している。更新
種別としては、他に、削除や変更がある。また、更新内
容１１４である「objectclass:appPerson uid:98001
appServerName:Server1」は、オブジェクトクラス属性
(objectclass)がappPersonで、ユーザーＩＤ(uid)が９
８００１のアプリケーションデータは、サーバー名称(a
ppServerName)がServer1というサーバが有していること
を示している。更新履歴テーブル１１０内のレコード
は、更新履歴番号１１１の小さい順に並んでいる。

【００４５】次に、図８を用いて、本実施形態によるデ
ィレクトリ同期方法に用いる更新履歴情報８のデータ構
造について説明する。更新履歴情報８は、ディレクトリ
同期サーバ２が取得した更新履歴に関する情報を記憶す
るものである。

【００４６】更新履歴情報８は、取得済みの更新履歴の
内、最後に取得した更新履歴の更新履歴番号５１を記憶
する更新履歴番号記憶領域５０と、各更新履歴の内容を
記憶する取得済更新履歴テーブル５２とから構成されて
いる。取得済更新履歴テーブル５２は配列構造をなし、
更新情報を複数格納可能である。

【００４７】取得済更新履歴テーブル５２は、更新履歴
テーブル１１０と同様のデータ構造を持ち、更新履歴番
号の記憶領域５３と、更新対象エントリの名称の記憶領
域５４と、更新種別の記憶領域５５と、更新内容の記憶
領域５６とから構成されている。取得済更新履歴テーブ
ル５２の情報例５７は、図７に示した更新履歴テーブル
１１０の情報例１１５と同様となる。取得済更新履歴テ
ーブル５２内のレコードは、更新履歴番号５３の小さい
順に並んでいる。

【００４８】次に、図９を用いて、本実施形態によるデ
ィレクトリ同期方法に用いるスナップショット９のデー
タ構造について説明する。スナップショット９は、配列
構造をなし、エントリ情報を複数格納可能である。スナ
ップショット９は、スナップショット逐次更新部１７
が、同期処理中に更新履歴の情報を基に作成する。

【００４９】スナップショット９は、レコード番号の記
憶領域６０と、エントリ名称の記憶領域６１と、エント
リ内容の記憶領域６２とから構成されている。スナップ
ショット９の情報例６３に示すように、レコード番号５
である「５」は５番目のレコードであることを示してい
る。また、エントリ名称６１である「UID=98001,OU=US
R,OU=APP1,O=XYZ,C=JP」は、図６に示したエントリ名称
１１２と同様である。エントリ内容６２である「pbject
class:app1Person uid:98001appl1ServerName:Server1
mail:suzuki@xyz.co.jp …… seeAlso:cn=一郎,sn=
鈴木, ou=総務部, o=XYZ, c=jp」の中で、ユーザＩＤが
９８００１である人のアプリケーション１のサーバー名
やメールアドレスがエントリ内容であり、また、「seeA
lso」は、リンクが張られていることを示している。リ
ンク先には、鈴木一郎氏(cn=一郎,sn=鈴木)の所属（日
本のＸＹＺ会社の総務部）があることを示している。

【００５０】次に、図１０を用いて、本実施形態による
ディレクトリ同期方法に用いるリンクインデックス７０
のデータ構造について説明する。リンクインデックス７
０は、或る共通エントリへのリンクを持つ固有エントリ
の検索を高速化する為のものである。リンクインデック
ス７０は、配列構造をなし、インデックス情報を複数格
納可能である。リンクインデックス７０は、スナップシ
ョット逐次更新部１７が、同期処理中に更新履歴の情報
を基に作成する。

【００５１】リンクインデックス７０は、エントリ名称
の記憶領域７１と、そのエントリへリンクしているエン
トリのレコード番号の記憶領域７２とから構成されてい
る。リンクインデックス７０の情報例７３に示すよう
に、エントリ名称である「CN=ichiro, SN=suzuki, OU=P
EOPLE, O=XYZ, C=jp」は、固有エントリのエントリ名称
を示している。

【００５２】次に、図１１を用いて、本実施形態による
ディレクトリ同期方法に用いる同期内容テーブル１０の
データ構造について説明する。同期内容テーブル１０
は、アプリケーションデータ１３に対する更新内容を記
憶するものである。同期内容テーブル１０は、配列構造
をなし、アプリケーションデータ１３に対する更新内容
を複数格納可能である。

【００５３】同期内容テーブル１０は、同期内容番号の
記憶領域８０と、更新種別の記憶領域８１と、更新内容
の記憶領域８２とから構成されている。同期内容テーブ
ル１０の情報例８３に示すように、例えば、更新種別８
１である「add」は、更新内容が追加(add)であることを
示している。更新種別としては、他に、変更や削除があ
る。更新内容８２である「table:USER userId:98001na
me:ichirosuzuki serverName:Server1」は、サーバ名
がServer1のユーザテーブル(USER)のユーザＩＤが９８
００１に、ichirosuzukiの名前を追加することを示して
いる。

【００５４】次に、図１２〜図２３を用いて、本実施形
態によるディレクトリ同期方法の動作について説明す
る。最初に、図１２を用いて、本実施形態によるディレ
クトリ同期方法における更新履歴取得部３の処理内容に
ついて説明する。

【００５５】更新履歴取得部３は、更新履歴の取得に関
わる動作を定期的に実行する。最初に、ステップＳ９０
１において、更新履歴取得部３は、図８に示した更新履
歴情報８の中の更新履歴番号記憶領域５０の取得済更新
履歴番号５１を参照する。

【００５６】次に、ステップＳ９０２において、更新履
歴取得部３は、ディレクトリサーバ１が出力した更新履
歴の内、ステップＳ９０１で取得した取得済更新履歴番
号５１より大きい更新履歴番号を持つ更新履歴を全て取
得する。例えば、取得済更新履歴番号５１が「１２４
４」であったとすると、更新履歴番号が「１２４４」ま
での更新履歴が更新済みであるので、取得済更新履歴番
号が「１２４５」以降の更新履歴（例えば、図７に示し
た更新履歴テーブル１１０の情報例１１５以降の更新履
歴）を、更新履歴テーブル１１０から取得する。

【００５７】そして、ステップＳ９０３において、更新
履歴取得部３は、それら更新履歴の情報を、図８に示し
た取得済更新履歴テーブル５２に、情報例５７のように
登録する。最後に、ステップＳ９０４において、更新履
歴取得部３は、ステップＳ９０２で取得した更新履歴の
内、最後に取得した更新履歴の更新履歴番号を、更新履
歴番号記憶領域５０の取得済更新履歴番号５１に登録す
る。

【００５８】以上で、更新履歴取得部３の処理を終了し
て、ステップＳ９０５では、その後、スキーマ変換部４
のスキーマ変換処理に移行する。スキーマ変換処理の詳
細については、図１３を用いて説明する。

【００５９】次に、図１３を用いて、本実施形態による
ディレクトリ同期方法におけるスキーマ変換部４の処理
内容について説明する。最初に、ステップＳ１００１に
おいて、スキーマ変換部４は、図８に示した更新履歴情
報８の中の取得済更新履歴テーブル５２の先頭レコード
に登録されたディレクトリデータ１１に対する更新に関
して、更新種別決定部１８の更新種別決定処理を実行す
る。更新種別決定処理の詳細については、図１４及び図
１５を用いて後述する。

【００６０】次に、ステップＳ１００２において、スキ
ーマ変換部４は、アプリケーションデータ１３への更新
内容を決定するため、属性マッピング処理を実行する。
属性マッピング処理の詳細については、図１６〜図１８
を用いて後述する。

【００６１】次に、ステップＳ１００３において、スナ
ップショット逐次更新部１７は、スナップショットの逐
次更新処理を実行する。スナップショットの更新処理の
詳細については、図１９〜図２２を用いて後述する。

【００６２】次に、ステップＳ１００４において、スキ
ーマ変換部４は、アプリケーションデータ１３に対する
更新が不要と判断されたか否かを確認し、更新が不要な
らば、ステップＳ１００６以降の処理へ移行し、更新が
必要ならば、ステップＳ１００５を実行する。

【００６３】更新が必要な場合には、ステップＳ１００
５において、スキーマ変換部４は、図１１に示した同期
内容テーブル１０に新規レコードを登録する。新規レコ
ードの同期内容番号７０，更新種別７１及び更新内容７
２には、それぞれ、現在処理中である取得済更新履歴テ
ーブル５２のレコードの更新履歴番号５３，ステップＳ
１００１で決定した更新種別及びステップＳ１００２で
決定した更新内容を登録する。

【００６４】次に、ステップＳ１００６において、スキ
ーマ変換部４は、取得済更新履歴テーブル５２の全レコ
ードに対して上述した処理を実行したか否かを判断す
る。実行していない場合には、ステップＳ１００７にお
いて、スキーマ変換部４は、取得済更新履歴テーブル５
２から次履歴を取得し、ステップＳ１００１〜Ｓ１００
５を繰り返し実行する。

【００６５】また、全履歴の処理が終了すると、ステッ
プＳ１００８において、スキーマ変換部４は、図８に示
した取得済更新履歴テーブル５２を削除する。そして、
スキーマ変換処理が終了すると、ステップＳ１００９に
おいて、アプリケーションデータ更新部５のアプリケー
ションデータ更新処理へ移行する。アプリケーションデ
ータ更新処理の詳細については、図２３を用いて後述す
る。

【００６６】ここで、図１４及び図１５を用いて、本実
施形態によるディレクトリ同期方法における更新種別決
定部１８の処理内容について説明する。更新種別決定処
理では、更新の対象となったディレクトリエントリが、
更新が実行される前と更新が実行された後に関して、ア
プリケーションデータ１３への同期条件を満足するか否
かを、スナップショット９を用いて調べ、その結果から
アプリケーションデータ１３への更新種別を決定する。
ここで、「同期条件」とは、更新対象のエントリがフィ
ルタリング規則テーブル６に登録されたフィルタリング
規則のいずれかに適合し、かつ、そのエントリが共通エ
ントリの場合は固有エントリとリンクしており、そのエ
ントリが固有エントリの場合は共通エントリとリンクし
ているという条件のことである。

【００６７】最初に、ステップＳ１１０１〜Ｓ１１０５
において、更新種別決定部１８は、更新対象のディレク
トリエントリが更新前に同期条件を満足していたか否か
の判定を行なう。即ち、ステップＳ１１０１において、
更新種別決定部１８は、図８に示した取得済更新履歴テ
ーブル５２の更新種別５５のデータにより、ディレクト
リデータ１１に対する更新種別が追加か否かを確認す
る。追加の場合、追加される以前に更新対象のエントリ
は存在しておらず、同期条件を満足していなかったのは
自明であるため、ステップＳ１１０６以降の処理に移行
する。

【００６８】追加以外の変更や削除の場合は、ステップ
Ｓ１１０２において、更新種別決定部１８は、図８に示
した取得済更新履歴テーブル５２の対象エントリ名称５
４と、図９に示したスナップショット９のエントリ名称
６１が一致するという条件でスナップショット９を検索
し、合致するレコードのスナップショット９のエントリ
内容６２を取得する。これは、更新対象のエントリの更
新前のエントリ内容である。

【００６９】次に、ステップＳ１１０３において、更新
種別決定部１８は、図４に示したフィルタリング規則テ
ーブル６に登録されたレコードを順に参照し、ベースエ
ントリ名称９１とスコープ９２で特定されたディレクト
リツリー内に更新対象のエントリが存在し、かつ、ステ
ップＳ１１０２で取得したエントリ内容がフィルタ条件
９３を満たすか否か調べることで、適合するフィルタリ
ング規則を検索する。例えば、図４に示したベースエン
トリ名称９１の情報例９５は、「OU=PEOPLE,O=XYZ,C=J
P」であり、スコープ９２の情報例９５は、「subtree」
であるので、図８に示した取得済更新履歴テーブル５２
の対象エントリ名称５４の情報例５７では、更新対象の
エントリが存在しないことになる。また、ベースエント
リ名称９１が、「OU=APP1,O=XYZ,C=JP」であり、スコー
プ９２の情報例９５が、「subtree」であるならば、図
８に示した取得済更新履歴テーブル５２の対象エントリ
名称５４の情報例５７は、「UID=98001, OU=USR, OU=AP
P1, O=XYZ, C=JP」であるため、ベースエントリ以下のs
ubtreeにおいて更新対象のエントリが存在することにな
る。そして、ステップＳ１１０２で取得したエントリ内
容６２がフィルタ条件を満たすかどうか調べる。

【００７０】適合するフィルタリング規則が存在しない
場合、更新種別決定部１８は、更新前は同期条件を満足
しなかったと判断し、ステップＳ１１０６以降の処理に
移行する。また、適合するフィルタリング規則が存在し
た場合、更新種別決定部１８は、そのフィルタリング規
則のエントリ種別９４を参照し、値が「０」である場合
は前記ディレクトリエントリは共通エントリであると判
断し、値が「１」である場合は固有エントリであると判
断する。

【００７１】次に、ステップＳ１１０５において、更新
種別決定部１８は、更新対象のエントリとリンクするエ
ントリが、更新前に存在したか否かの確認処理を行な
う。存在した場合、更新前は同期条件を満足したと判断
し、存在しなかった場合、更新前は同期条件を満足しな
かったと判断する。

【００７２】ここで、図１５を用いて、リンク先エント
リの存在確認処理の内容について説明する。リンク先エ
ントリの存在確認処理は、更新対象のディレクトリエン
トリとリンクするエントリの存在確認をする処理であ
り、或る更新が実行される前の確認処理（図１４のステ
ップＳ１１０５）と、実行された後の確認処理（図１４
のステップＳ１１１３）がある。

【００７３】最初に、ステップＳ１２０１において、更
新種別決定部１８は、図１４のステップＳ１１０４或い
はステップＳ１１１２の処理で取得したエントリ種別が
共通エントリか固有エントリで処理を分岐する。固有エ
ントリの場合は、ステップＳ１２０２に進み、共通エン
トリの場合には、ステップＳ１２０８に進む。

【００７４】固有エントリの場合、ステップＳ１２０２
において、更新種別決定部１８は、図１４のステップＳ
１１０２の処理で取得した更新前のエントリ内容、或い
はステップＳ１１０７〜Ｓ１１１０の処理で取得した更
新後のエントリ内容が、リンクを格納する属性を含むか
否かを調べる。リンクを格納する属性を含む場合とは、
図９に示したスナップショット９のエントリ内容６２の
中に、情報例６３に示すように、「seeAlso」の文を含
む場合である。含む場合には、ステップＳ１２０３に進
み、含まない場合には、ステップＳ１２０７に進む。

【００７５】含む場合、ステップＳ１２０３において、
更新種別決定部１８は、リンク先の共通エントリの存在
確認のため、スナップショット９を、リンクを格納する
属性の値とエントリ名称６１が一致するという条件で検
索する。ここで、リンクを格納する属性の値とは、例え
ば、「sn=鈴木」である。そして、ステップＳ１２０４
において、更新種別決定部１８は、合致するレコードが
存在するか否か調べる。存在する場合には、ステップＳ
１２０５に進み、存在しない場合には、ステップＳ１２
０７に進む。

【００７６】存在した場合、ステップＳ１２０５におい
て、更新種別決定部１８は、リンク先エントリが存在し
たと判断する。次に、ステップＳ１２０６において、更
新種別決定部１８は、合致したレコードを、スナップシ
ョット９から取得する。

【００７７】ステップＳ１２０２の判断で、リンクが存
在しない場合、また、ステップＳ１２０４の判断で、レ
コードが存在しない場合、ステップＳ１２０７におい
て、更新種別決定部１８は、リンク先エントリはしない
と判断する。

【００７８】更新対象のエントリが共通エントリの場
合、ステップＳ１２０８において、更新種別決定部１８
は、リンクインデックス７０を、そのエントリの名称と
エントリ名称７１が一致するという条件で検索する。そ
して、ステップＳ１２０９において、更新種別決定部１
８は、合致するレコードが存在するか否か調べる。存在
する場合には、ステップＳ１２１０に進み、存在しない
場合には、ステップＳ１２１３に進む。

【００７９】存在した場合、ステップＳ１２１０におい
て、更新種別決定部１８は、リンク先エントリが存在し
たと判断する。そして、ステップＳ１２１１において、
更新種別決定部１８は、スナップショット９を、合致し
たレコードのレコード番号７２とレコード番号６０が一
致するという条件で検索する。次に、ステップＳ１２１
２において、更新種別決定部１８は、合致したレコード
をスナップショット９から取得する。

【００８０】一方、ステップＳ１２０９の判断におい
て、合致するレコードが存在しなかった場合、ステップ
Ｓ１２１３において、更新種別決定部１８は、リンク先
エントリは存在しなかったと判断する。

【００８１】ここで、図１４に戻り、ステップＳ１１０
６〜Ｓ１１１３において、更新種別決定部１８は、更新
対象のディレクトリエントリが更新後に同期条件を満足
するか否かの判定を行なう。最初に、ステップＳ１１０
６及びＳ１１０７において、更新種別決定部１８は、デ
ィレクトリデータ１１への更新種別により処理を分岐す
る。即ち、更新種別が削除の場合には、削除された後デ
ィレクトリエントリは存在せず、同期条件を満足しない
のは自明であるため、ステップＳ１１１４に進み、更新
種別が変更の場合には、ステップＳ１１０８に進み、更
新種別が追加の場合には、ステップＳ１１１０に進む。

【００８２】また、更新種別が変更ならば、ステップＳ
１１０８において、更新種別決定部１８は、更新対象の
エントリの名称とエントリ名称６１が一致するという条
件でスナップショット９を検索し、合致するレコードの
エントリ内容６２を取得する。次に、ＳステップＳ１１
０９において、更新種別決定部１８は、ステップＳ１１
０８で取得したエントリ内容に、現在処理中の更新履歴
レコードの更新内容５６を反映させ、更新後のエントリ
内容を得る。即ち、図９に示したスナップショット９の
エントリ内容６２に、図８に示した取得済更新履歴テー
ブル５２の更新内容５６を入れる。

【００８３】さらに、更新種別が追加ならば、ステップ
Ｓ１１１０において、更新種別決定部１８は、更新後の
エントリ内容は、現在処理中の更新履歴レコードの更新
内容５６と同一であるとする。

【００８４】次に、ステップＳ１１１１において、更新
種別決定部１８は、フィルタリング規則テーブル６に登
録されたレコードを順に参照し、ベースエントリ名称９
１とスコープ９２で特定されたディレクトリツリー内に
前記ディレクトリエントリが存在し、かつ、ステップＳ
１１０９或いはステップＳ１１１０で取得した更新後の
エントリ内容がフィルタ条件９３を満たすか否か調べ
る。適合するフィルタリング規則が存在する場合には、
ステップＳ１１１２に進み、適合するフィルタリング規
則が存在しない場合には、更新後は同期条件を満足しな
いと判断し、ステップＳ１１１４に進む。

【００８５】適合するフィルタリング規則が存在する場
合、ステップＳ１１１２において、更新種別決定部１８
は、フィルタリング規則のエントリ種別９４を参照し、
値が０である場合は前記ディレクトリエントリは共通エ
ントリであると判断し、値が１である場合は固有エント
リであると判断する。その後、ステップＳ１１１３にお
いて、更新種別決定部１８は、更新後に前記ディレクト
リエントリとリンクするエントリが存在するか否かの確
認処理を行なう。リンク先のエントリの存在確認処理
は、図１５に示したとおりである。存在する場合、更新
後は同期条件を満足すると判断し、存在しない場合、更
新後は同期条件を満足しないと判断する。

【００８６】最後に、ステップＳ１１１４において、更
新種別決定部１８は、以上の処理の結果からアプリケー
ションデータ１３への更新種別を決定する。すなわち、
更新前に同期条件を満足せず、更新後に同期条件を満足
する状態へ移行した場合は更新種別は「追加」である。
更新前に同期条件を満足し、更新後に同期条件を満足し
ない状態へ移行した場合は更新種別は「削除」である。
更新前後共に同期条件を満足する場合は更新種別は「変
更」である。更新前後共に同期条件を満足しない場合は
アプリケーションデータ１３へは更新を行なわない。こ
のようにして、共有エントリと固有エントリの同期をと
り、同期条件を満たさない場合には、更新を行わないよ
うにすることにより、不整合が発生することを防止でき
る。

【００８７】次に、図１６〜図１８を用いて、本実施形
態によるディレクトリ同期方法における属性マッピング
処理の内容について説明する。属性マッピング処理は、
図１３に示したスキーマ処理の中のステップＳ１００２
における処理である。

【００８８】最初に、図１６を用いて、属性マッピング
処理の全体的な処理内容について説明する。最初に、ス
テップＳ１３０１及びＳ１３０２において、スキーマ変
換部４は、図１４のＳ１１１４で決定したアプリケーシ
ョンデータ１３に対する更新種別により処理を分岐す
る。

【００８９】まず、アプリケーションデータ１３に対す
る更新を行なわない場合は、何も行なう必要はないた
め、属性マッピング処理を終了する。更新種別が削除の
場合には、ステップＳ１３０３において、スキーマ変換
部４は、削除に関する属性マッピング処理を実行する。
削除に関する属性マッピング処理の詳細については、図
１７を用いて後述する。更新種別が追加及び変更の場合
には、ステップＳ１３０４において、スキーマ変換部４
は、追加，変更に関する属性マッピング処理を実行す
る。追加，変更に関する属性マッピング処理の詳細につ
いては、図１８を用いて後述する。

【００９０】次に、図１７を用いて、削除に関する属性
マッピング処理の処理内容について説明する。最初に、
ステップＳ１４０１において、スキーマ変換部４は、更
新対象のディレクトリエントリに適用するスキーマ変換
規則を決定する。そのために、図１４のステップＳ１１
０４で取得したエントリ種別により処理を分岐する。更
新対象のエントリが共通エントリである場合には、ステ
ップＳ１４０２に進み、更新対象のエントリが固有エン
トリである場合、ステップＳ１４０４に進む。

【００９１】更新対象のエントリが共通エントリである
場合、ステップＳ１４０２において、スキーマ変換部４
は、図１４のステップＳ１１０２で取得したエントリ内
容から、オブジェクトクラスを格納するobjectclass属
性を取り出す。例えば、図９に示した例では、スナップ
ショット９のエントリ内容６２から、情報例６３に示す
objectclass属性である「app1Person」を取り出す。次
に、ステップＳ１４０３において、スキーマ変換部４
は、図１５のＳ１２１２で取得したリンク先の固有エン
トリのエントリ内容からも、objectclass属性を取り出
す。

【００９２】また、更新対象のディレクトリエントリが
固有エントリである場合、ステップＳ１４０４におい
て、スキーマ変換部４は、図１４のＳ１１０２で取得し
たエントリ内容から、オブジェクトクラスを格納するob
jectclass属性を取り出す。次に、ステップＳ１４０５
において、スキーマ変換部４は、図１５のＳ１２０６で
取得したリンク先の共通エントリのエントリ内容から
も、objectclass属性を取り出す。

【００９３】次に、適用するスキーマ変換規則を決定す
る。まず、ステップＳ１４０６において、スキーマ変換
部４は、スキーマ変換規則テーブル７の先頭レコードを
参照し、共通エントリの対象クラス１０１が、ステップ
Ｓ１４０２、或いはＳ１４０５の処理で取得した共通エ
ントリのobjectclass属性に含まれ、かつ、固有エント
リの対象クラス１０３が、ステップＳ１４０３、或いは
Ｓ１４０４の処理で取得した固有エントリのobjectclas
s属性に含まれるか否か調べる。含まれる場合には、ス
テップＳ１４０８に進み、含まれない場合には、ステッ
プＳ１４０７に進み、ステップＳ１４０７において、ス
キーマ変換部４は、次の規則を参照し、同様の処理を繰
り返す。

【００９４】含まれる場合、ステップＳ１４０８におい
て、スキーマ変換部４は、そのスキーマ変換規則の識別
子格納属性名称１０５を取得する。次に、ステップＳ１
４０９において、スキーマ変換部４は、図１４のステッ
プＳ１１０４で取得したエントリ種別により、処理を分
岐する。即ち、エントリ種別が共通エントリの場合に
は、ステップＳ１４１０に進み、固有エントリの場合に
は、ステップＳ１４１１に進む。そして、ステップＳ１
４１０若しくは、ステップＳ１４１１において、固有エ
ントリに格納されているアプリケーションデータ１３内
の削除すべきエントリを一意に特定する識別子を取得す
る。

【００９５】更新対象のディレクトリエントリが共通エ
ントリである場合、ステップＳ１４１０において、スキ
ーマ変換部４は、図１５のステップＳ１２１２で取得し
たリンク先固有エントリのエントリ内容から、ステップ
Ｓ１４０８で取得した名称を持つ属性（アプリケーショ
ンデータ１３の識別子を格納する属性）を取り出す。例
えば、図５に示したように、スキーマ変換規則テーブル
７の識別子格納属性名称１０５が、情報例１０６に示す
ように、「uid」である場合、図９に示したスナップシ
ョット９のエントリ内容６２から、情報例６３に示す例
の場合には、ユーザＩＤ（uid）として、「98001」を取
り出す。

【００９６】また、ディレクトリエントリが固有エント
リである場合、ステップＳ１４１１において、スキーマ
変換部４は、図１４のステップＳ１１０２で取得した更
新対象エントリのエントリ内容から、ステップＳ１４０
８で取得した名称を持つ属性を取り出す。そして、ステ
ップＳ１４１２において、スキーマ変換部４は、ステッ
プＳ１４１０、或いはＳ１４１１で取得した識別子を格
納する属性が、アプリケーションデータ１３に対する更
新内容とする。

【００９７】次に、図１８を用いて、追加，変更に関す
る属性マッピング処理の処理内容について説明する。最
初に、ステップＳ１５０１において、スキーマ変換部４
は、更新対象のディレクトリエントリに適用するスキー
マ変換規則を決定する。そのために、図１４のステップ
Ｓ１１１２で取得したエントリ種別により処理を分岐す
る。更新対象のエントリが共通エントリである場合に
は、ステップＳ１５０２に進み、更新対象のエントリが
固有エントリである場合、ステップＳ１５０４に進む。

【００９８】更新対象のエントリが共通エントリである
場合、ステップＳ１５０２において、スキーマ変換部４
は、図１４のステップＳ１１０７で取得したエントリ内
容から、オブジェクトクラスを格納するobjectclass属
性を取り出す。次に、ステップＳ１５０３において、ス
キーマ変換部４は、図１５のＳ１２１２で取得したリン
ク先の固有エントリのエントリ内容からも、objectclas
s属性を取り出す。

【００９９】また、更新対象のディレクトリエントリが
固有エントリである場合、ステップＳ１５０４におい
て、スキーマ変換部４は、図１４のＳ１１１０で取得し
たエントリ内容から、オブジェクトクラスを格納するob
jectclass属性を取り出す。次に、ステップＳ１５０５
において、スキーマ変換部４は、図１５のＳ１２０６で
取得したリンク先の共通エントリのエントリ内容から
も、objectclass属性を取り出す。

【０１００】次に、適用するスキーマ変換規則を決定す
る。まず、ステップＳ１５０６において、スキーマ変換
部４は、スキーマ変換規則テーブル７の先頭レコードを
参照し、共通エントリの対象クラス１０１が、ステップ
Ｓ１５０２、或いはＳ１５０５の処理で取得した共通エ
ントリのobjectclass属性に含まれ、かつ、固有エント
リの対象クラス１０３が、ステップＳ１５０３、或いは
Ｓ１５０４の処理で取得した固有エントリのobjectclas
s属性に含まれるか否か調べる。含まれる場合には、ス
テップＳ１５０８に進み、含まれない場合には、ステッ
プＳ１５０７に進み、ステップＳ１５０７において、ス
キーマ変換部４は、次の規則を参照し、同様の処理を繰
り返す。

【０１０１】次に、ステップＳ１５０８において、スキ
ーマ変換部４は、Ｓ１５０６で決定したスキーマ変換規
則の共通エントリに対する属性変換規則１０２を参照
し、共通エントリのエントリ内容に含まれる属性名をア
プリケーションデータ１３の属性名に置換する。例え
ば、図５に示したように、属性変換規則（共通）１０２
として、情報例１０６に示すように、「cn,Name」とあ
る場合には、共通エントリの属性名「cn:一郎」を、ア
プリケーションデータの属性名「Name:ichiro」に置換
する。次に、ステップＳ１５０９において、スキーマ変
換部４は、属性名の置換がすべての属性について行われ
たか否かを判断し、行われていない場合には、ステップ
Ｓ１５１０において、スキーマ変換部４は、次の属性に
ついて、属性名の置換を行う。

【０１０２】属性名の置換が、共通エントリのエントリ
内容に含まれる全属性に対して行なわれると、ステップ
Ｓ１５１１において、スキーマ変換部４は、ステップＳ
１５０６で決定したスキーマ変換規則の固有エントリに
対する属性変換規則１０４を参照し、固有エントリのエ
ントリ内容に含まれる属性名をアプリケーションデータ
１３の属性名に置換する。次に、ステップＳ１５１２に
おいて、スキーマ変換部４は、属性名の置換がすべての
属性について行われたか否かを判断し、行われていない
場合には、ステップＳ１５１３において、スキーマ変換
部４は、次の属性について、属性名の置換を行う。

【０１０３】属性名の置換が、固有エントリのエントリ
内容に含まれる全属性に対して行なわれると、ステップ
Ｓ１５１４において、スキーマ変換部４は、ステップＳ
１５０８〜Ｓ１５１０までの処理により決定したアプリ
ケーションデータ１３の属性、及びステップＳ１５１１
〜Ｓ１５１３までの処理により決定したアプリケーショ
ンデータ１３の属性を結合することにより、アプリケー
ションデータ１３に対する更新内容を得る。

【０１０４】次に、図１９〜図２２を用いて、本実施形
態によるディレクトリ同期方法におけるスナップショッ
トの更新処理の内容について説明する。スナップショッ
トの更新処理は、図１３に示したスキーマ処理の中のス
テップＳ１００３における処理であり、スナップショッ
ト逐次更新部１７が行うものである。

【０１０５】図１９に示すように、ステップＳ１６０１
及びＳ１６０２において、スナップショット逐次更新部
１７は、現在処理中の更新履歴の更新種別により処理を
分岐する。即ち、追加の場合は、ステップＳ１６０３に
おいて追加処理を実行し、変更の場合は、ステップＳ１
６０４において変更処理を実行し、削除の場合は、ステ
ップＳ１６０５において削除処理を実行する。それぞれ
の処理の詳細については、図２０〜図２２を用いて説明
する。

【０１０６】最初に、図２０を用いて、スナップショッ
ト９のレコード追加処理の内容について説明する。ステ
ップＳ１７０１において、スナップショット逐次更新部
１７は、スナップショット９に新規レコードを登録す
る。この時、レコード番号６０には、他のレコードと重
複しない値を登録する。例えば、レコードを登録する毎
に１ずつ加算した値を割り当てるようにする。エントリ
名称６１には、更新対象のディレクトリエントリの名称
を登録する。例えば、エントリ名称６１には、図８に示
した取得済更新履歴テーブル５２の対象エントリ名称５
４の情報例５７の「UID=98001,OU=USR, OU=APP1, O=XY
Z, C=JP」を登録する。また、エントリ内容６２には、
図１４のステップＳ１１０９、或いはＳ１１１０の処理
により取得した更新後のエントリ内容を登録する。例え
ば、図８に示した取得済更新履歴テーブル５２の更新内
容５６の情報例５７である「objectclass:appPerson u
id:98001 appServerName:Server1」を登録する。

【０１０７】次に、ステップＳ１７０２において、スナ
ップショット逐次更新部１７は、ステップＳ１１１２の
処理により取得したエントリ種別により処理を分岐す
る。即ち、更新対象のディレクトリエントリが共通エン
トリの場合、リンクを格納する属性は持たないため、レ
コード追加処理を終了する。固有エントリの場合、ステ
ップＳ１７０３に進む。

【０１０８】そして、ステップＳ１７０３において、ス
ナップショット逐次更新部１７は、更新後のエントリ内
容を参照して、リンクを格納する属性が含まれるか否か
調べる。含まれる場合には、ステップＳ１７０４に進
み、含まれない場合には、レコード追加処理を終了す
る。

【０１０９】次に、含まれる場合、ステップＳ１７０４
において、スナップショット逐次更新部１７は、リンク
インデックス７０に、新規レコードを登録する。この
時、リンク先エントリ名称７１には、前記属性の値を登
録する。レコード番号７２は、Ｓ１７０１で登録したス
ナップショットの新規レコードのレコード番号６０と同
一の値を登録する。

【０１１０】次に、図２１を用いて、スナップショット
９のレコード変更処理の内容について説明する。最初
に、ステップＳ１８０１において、スナップショット逐
次更新部１７は、図１４のステップＳ１１０８の処理で
実行したスナップショット９の検索において、検索条件
に合致したレコードのエントリ内容６２を変更する。こ
の時、検索条件に合致したレコードのエントリ内容６２
を、図１４のＳ１１０９の処理により取得した更新後の
エントリ内容で上書きする。

【０１１１】次に、ステップＳ１８０２において、スナ
ップショット逐次更新部１７は、図１４のＳ１１１２の
処理により取得したエントリ種別により処理を分岐す
る。即ち、更新対象のディレクトリエントリが共通エン
トリの場合、リンクを格納する属性は持たないため、レ
コード変更処理を終了する。固有エントリの場合には、
ステップＳ１８０３に進む。

【０１１２】固有エントリの場合、ステップＳ１８０３
〜Ｓ１８０５において、スナップショット逐次更新部１
７は、変更履歴テーブル５２の現在処理中であるレコー
ドの更新内容５６を参照して、共通エントリに対するリ
ンクを格納する属性が更新されたか否か調べる。そし
て、更新種別によって処理が分岐し、リンクを格納する
属性の追加の場合には、ステップＳ１８０６に進み、リ
ンクを格納する属性の削除の場合には、ステップＳ１８
０７に進み、リンクを格納する属性の変更の場合には、
ステップＳ１８０８に進む。

【０１１３】リンクを格納する属性が追加された場合に
は、ステップＳ１８０６において、スナップショット逐
次更新部１７は、リンクインデックス７０に、新規レコ
ードを登録する。この時、リンク先エントリ名称７１に
は、前記属性の値を登録する。レコード番号７２は、ス
テップＳ１８０１の処理で変更したスナップショット９
のレコードのレコード番号６０と同一の値を登録する。

【０１１４】リンクを格納する属性が削除された場合に
は、ステップＳ１８０７において、スナップショット逐
次更新部１７は、リンクインデックス７０からレコード
を削除する。すなわち、まず、図１４のＳ１１０２の処
理により取得したエントリ内容６２からリンクを格納す
る属性を取り出す。次に、リンクインデックス７０を、
前記属性の値とエントリ名称７１が一致するという条件
で検索し、合致するレコードを削除する。

【０１１５】リンクを格納する属性が変更された場合に
は、ステップＳ１８０８において、スナップショット逐
次更新部１７は、リンクインデックス７０からレコード
を削除し、新規レコードを追加する。すなわち、まず、
図１４のステップＳ１１０２で取得したエントリ内容６
２からリンクを格納する属性の値を取り出す。次に、リ
ンクインデックス７０を、前記属性の値とエントリ名称
７１が一致するという条件で検索し、合致するレコード
を削除する。その後、新規レコードを登録する。この
時、エントリ名称７１には、図１４のステップＳ１１０
９の処理により取得した更新後のエントリ内容からリン
クを格納する属性を取り出し、その属性の値を登録す
る。レコード番号７２は、Ｓ１８０１で変更したスナッ
プショット９のレコードのレコード番号６０と同一の値
を登録する。

【０１１６】次に、図２２を用いて、スナップショット
９のレコード削除処理の内容について説明する。最初
に、ステップＳ１９０１において、スナップショット逐
次更新部１７は、図１４のステップＳ１１０４の処理に
より取得したエントリ種別により処理を分岐する。更新
対象のディレクトリエントリが共通エントリの場合に
は、リンクを格納する属性は持たないため、ステップＳ
１９０４に進む。また、固有エントリの場合には、ステ
ップＳ１９０２に進む。

【０１１７】固有エントリの場合には、ステップＳ１９
０２において、スナップショット逐次更新部１７は、図
１４のＳ１１０２の処理により取得したスナップショッ
ト９のエントリ内容６２に、図３のリンク４５を格納す
る属性が含まれるか否か調べる。含まれる場合には、ス
テップＳ１９０３に進み、含まれない場合には、ステッ
プＳ１９０４に進む。

【０１１８】リンクを格納する属性が含まれる場合に
は、ステップＳ１９０３において、スナップショット逐
次更新部１７は、リンクインデックス７０を、前記属性
の値とエントリ名称７１が一致するという条件で検索
し、合致するレコードを削除する。最後に、ステップＳ
１９０４において、スナップショット逐次更新部１７
は、図１４のステップＳ１１０２の処理により取得し
た、スナップショット９のレコードを削除する。

【０１１９】次に、図２３を用いて、本実施形態による
ディレクトリ同期方法におけるアプリケーションデータ
の更新処理の内容について説明する。アプリケーション
データの更新処理は、アプリケーションデータ更新部５
によって実行される。

【０１２０】最初に、ステップＳ２００１において、ア
プリケーションデータ更新部５は、同期内容テーブル１
０の先頭レコードを取得する。

【０１２１】次に、ステップＳ２００２において、アプ
リケーションデータ更新部５は、前記レコードの更新内
容８２に従って、アプリケーションデータ１３を更新す
る。

【０１２２】次に、ステップＳ２００３において、アプ
リケーションデータ更新部５は、すべての更新内容に処
理が実行されたか否かを判断し、実行されていない場合
には、ステップＳ２００４に進んで、次の同期内容レコ
ードを取り出し、ステップＳ２００１及びＳ２００２を
実行して、同期内容テーブル１０の全レコードに対して
実行する。全ての同期内容レコードについて処理が実行
されると、ステップＳ２００５において、アプリケーシ
ョンデータ更新部５は、同期内容レコード１０の全レコ
ードを削除する。

【０１２３】なお、以上の説明では、ディレクトリ同期
サーバ２を用いて、本実施形態によるディレクトリ同期
方法を実現しているが、ディレクトリサーバ１を用い
て、本実施形態によるディレクトリ同期方法を実現する
ようにしてもよいものである。そのためには、図１に示
した更新履歴取得部３，スキーマ変換部４，更新種別決
定部１８，スナップショット逐次更新部１７，アプリケ
ーションデータ更新部５や、各テーブル６，７，８、
９，１０を、ディレクトリサーバ１内に備えるようにす
ればよいものである。

【０１２４】以上説明したように、本実施形態によれ
ば、ディレクトリサーバが出力する更新履歴を定期的に
取得し、その更新履歴に基づき作成されるディレクトリ
データのスナップショットと更新履歴からアプリケーシ
ョンデータに対して行うべき更新内容を取得し、アプリ
ケーションデータを更新することで、従来はディレクト
リサーバの検索を要するためディレクトリエントリ数増
大に従って所要時間が増大したディレクトリ同期処理
を、ディレクトリエントリ数に関わらず一定の時間で実
行することが可能となる。即ち、従来は、更新時に全ス
ナップショットを作成していたので、ディレクトリエン
トリ数増大に従ってスナップショット作成時間が増大す
るのに対して、本実施形態においては、更新履歴を取得
する毎に、スナップショットを作成しているので、更新
時のスナップショット作成が不要となるため、ディレク
トリエントリ数が増大しても、更新所要時間が増大する
ことはないものである。

【０１２５】また、本実施形態によれば、ディレクトリ
サービスに対する更新を禁止する期間を無くしディレク
トリサービスの可用性を向上することが可能である。即
ち、従来は、スナップショットを取得している間はディ
レクトリサービスに対する更新を禁止しなければならな
いため、更新を禁止する期間を設ける必要があったのに
対して、本実施形態においては、更新履歴情報に基づい
て更新を行っており、更新の途中に新たな更新情報が追
加されたとしても、新たな更新情報について更新は次回
に行うため、更新を禁止する期間を設ける必要はないも
のである。

【０１２６】さらに、従来は同期処理を行う間隔を短く
したとしても、スナップショットを取得している間は必
ずディレクトリデータとアプリケーションデータが不整
合状態となったが、本実施形態によれば、更新履歴を取
得する間隔を短くすることにより、ディレクトリデータ
とアプリケーションデータの間に不整合が発生する期間
をより短くすることができる。即ち、図１４のステップ
Ｓ１１１４の判断で同期条件を満たさないこととなるた
め、同期条件を満たさない場合には、更新を行わないよ
うにすることにより、不整合が発生することを防止でき
る。

【０１２７】

【発明の効果】本発明によれば、ディレクトリサービス
に登録されるディレクトリエントリの数が増加した場合
も、ディレクトリサービスとアプリケーションの同期に
要する時間を一定に保つことができる。

【図面の簡単な説明】

【図１】本発明の一実施形態によるディレクトリ同期方
法を実行するディレクトリ同期システムのシステム構成
図である。

【図２】本発明の一実施形態によるディレクトリ同期方
法を実行するディレクトリシステムを構成するディレク
トリサーバ，アプリケーションサーバ及びディレクトリ
同期サーバのシステム構成について説明する。

【図３】本発明の一実施形態によるディレクトリ同期方
法に用いるディレクトリデータの論理構造の説明図であ
る。

【図４】本発明の一実施形態によるディレクトリ同期方
法に用いるフィルタリング規則テーブルのデータ構造の
説明図である。

【図５】本発明の一実施形態によるディレクトリ同期方
法に用いるスキーマ変換規則テーブルのデータ構造の説
明図である。

【図６】本発明の一実施形態によるディレクトリ同期方
法に用いるスキーマ変換テーブルの属性変換規則のデー
タ構造の説明図である。

【図７】本発明の一実施形態によるディレクトリ同期方
法に用いる更新履歴記憶領域のデータ構造の説明図であ
る。

【図８】本発明の一実施形態によるディレクトリ同期方
法に用いる更新履歴情報のデータ構造の説明図である。

【図９】本発明の一実施形態によるディレクトリ同期方
法に用いるスナップショットのデータ構造の説明図であ
る。

【図１０】本発明の一実施形態によるディレクトリ同期
方法に用いるリンクインデックスのデータ構造の説明図
である。

【図１１】本発明の一実施形態によるディレクトリ同期
方法に用いる同期内容テーブルのデータ構造の説明図で
ある。

【図１２】本発明の一実施形態によるディレクトリ同期
方法における更新履歴取得部の処理内容を示すフローチ
ャートである。

【図１３】本発明の一実施形態によるディレクトリ同期
方法におけるスキーマ変換部の処理内容を示すフローチ
ャートである。

【図１４】本発明の一実施形態によるディレクトリ同期
方法における更新種別決定部の処理内容を示すフローチ
ャートである。

【図１５】本発明の一実施形態によるディレクトリ同期
方法における更新種別決定部の処理内容を示すフローチ
ャートである。

【図１６】本発明の一実施形態によるディレクトリ同期
方法における属性マッピング処理の全体的な処理内容を
示すフローチャートである。

【図１７】本発明の一実施形態によるディレクトリ同期
方法における属性マッピング処理の中の削除時のマッピ
ング処理容を示すフローチャートである。

【図１８】本発明の一実施形態によるディレクトリ同期
方法における属性マッピング処理の中の追加，変更時の
マッピング処理内容を示すフローチャートである。

【図１９】本発明の一実施形態によるディレクトリ同期
方法におけるスナップショットの更新処理の全体的な処
理内容を示すフローチャートである。

【図２０】本発明の一実施形態によるディレクトリ同期
方法におけるスナップショットの更新処理の中の削除処
理の内容を示すフローチャートである。

【図２１】本発明の一実施形態によるディレクトリ同期
方法におけるスナップショットの更新処理の中の変更処
理の内容を示すフローチャートである。

【図２２】本発明の一実施形態によるディレクトリ同期
方法におけるスナップショットの更新処理の中の追加処
理の内容を示すフローチャートである。

【図２３】本発明の一実施形態によるディレクトリ同期
方法におけるアプリケーションデータの更新処理の全体
的な処理内容を示すフローチャートである。

【符号の説明】

１…ディレクトリサーバ ２…ディレクトリ同期サーバ ３…更新履歴取得部 ４…スキーマ変換部 ５…アプリケーションデータ更新部 ６…フィルタリング規則テーブル ７…スキーマ変換規則テーブル ８…更新履歴情報 ９…スナップショット １０…同期内容テーブル １１…ディレクトリデータ １２…アプリケーションサーバ １３…アプリケーションデータ １４，１５…ＤＢ １６…更新履歴記憶領域 １７…スナップショット逐次更新部 １８…更新種別決定部

───────────────────────────────────────────────────── フロントページの続き (72)発明者 平島 陽子 神奈川県川崎市麻生区王禅寺1099番地 株 式会社日立製作所システム開発研究所内 (72)発明者 中村 敏治 神奈川県横浜市戸塚区戸塚町5030番地 株 式会社日立製作所ソフトウェア事業部内 (72)発明者 武井 茂樹 神奈川県横浜市中区尾上町６丁目81番地 日立ソフトウェアエンジニアリング株式会 社内 Ｆターム(参考） 5B082 DD04 DD07 EA01 GA14 GB01

Claims (5)

【特許請求の範囲】
1. 【請求項１】ディレクトリサーバに記憶されたディレク
   トリデータと、このディレクトリサーバにネットワーク
   を介して接続された少なくとも１つ以上のアプリケーシ
   ョンサーバに記憶されたアプリケーションデータとの同
   期を行なうディレクトリ同期方法において、 Ａ）上記ディレクトリデータに対して行った更新履歴を
   定期的に取得し、 Ｂ）この取得した更新履歴を順に参照し、ディレクトリ
   データのスナップショットを逐次更新し、 Ｃ）更新履歴の内容と、スナップショットの情報に従
   い、上記アプリケーションサーバへの更新種別を決定
   し、 Ｄ）更新履歴の内容をアプリケーションサーバへの更新
   へ変換し、 Ｅ）このアプリケーションサーバへの更新内容を基にア
   プリケーションサーバの更新を実行することを特徴とす
   るディレクトリ同期方法。
2. 【請求項２】請求項１記載のディレクトリ同期方法にお
   いて、 上記アプリケーションサーバが管理する情報を、アプリ
   ケーションに依存しない共通情報と、アプリケーション
   固有の固有情報に分類し、それら２種類の情報を上記デ
   ィレクトリサーバ内の異なるエントリに格納し、かつ、
   それらのエントリ間にリンクを設定することを特徴とす
   るディレクトリ同期方法。
3. 【請求項３】請求項２記載のディレクトリ同期方法にお
   いて、 上記定期的に取得された更新履歴中の更新に関して、そ
   の更新をスナップショットに反映する前後で、その更新
   の対象となるユーザ情報を分割して格納している２エン
   トリが存在し、かつ、それらエントリ間にリンクが存在
   するか否かを調べ、 反映前は存在せず、反映後に存在する場合は、アプリケ
   ーションデータに対する更新種別を追加と決定し、 逆に反映前は存在し、反映後に存在しない場合は、アプ
   リケーションデータに対する更新種別を追加と決定し、 反映の前後共に存在する場合は、アプリケーションデー
   タに対する更新種別を変更と決定し、 反映の前後共に存在しない場合は、更新を行わないこと
   を特徴とするディレクトリ同期方法。
4. 【請求項４】請求項１記載のディレクトリ同期方法にお
   いて、 アプリケーションデータとの同期を要するディレクトリ
   データを選別するフィルタリング規則に適合しないディ
   レクトリデータに関してはディレクトリサーバ上に存在
   しないものと見なし、 このフィルタリング規則に適合するディレクトリデータ
   に関してのみ更新種別を決定することを特徴とするディ
   レクトリ同期方法。
5. 【請求項５】請求項１記載のディレクトリ同期方法にお
   いて、 アプリケーションデータに対する更新種別の削除に対し
   ては、スナップショットからアプリケーションデータの
   識別子を取得し、アプリケーションデータから削除すべ
   きユーザ情報を特定することを特徴とするディレクトリ
   同期方法。