JP3810577B2 - ディレクトリ同期方法 - Google Patents
ディレクトリ同期方法 Download PDFInfo
- Publication number
- JP3810577B2 JP3810577B2 JP08366099A JP8366099A JP3810577B2 JP 3810577 B2 JP3810577 B2 JP 3810577B2 JP 08366099 A JP08366099 A JP 08366099A JP 8366099 A JP8366099 A JP 8366099A JP 3810577 B2 JP3810577 B2 JP 3810577B2
- Authority
- JP
- Japan
- Prior art keywords
- update
- directory
- entry
- application
- data
- 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 - Fee Related
Links
Images
Description
【０００１】
【発明の属する技術分野】
本発明は、ディレクトリサービスに対する更新を、アプリケーションのデータベースに反映させるディレクトリ同期方法に関する。
【０００２】
【従来の技術】
ディレクトリサービスとは、電子メールの送信相手の姓名等から電子メールの宛先を検索できるサービスであり、電子メールシステムにおける電子的な電話帳機能として利用されている。
【０００３】
ディレクトリサービスに関する標準としては、ＣＣＩＴＴの勧告であるＸ．５００（ＩＳＯ９５９４）が挙げられる。Ｘ．５００は、ディレクトリサービスをクライアント−サーバ型の分散システム・アーキテクチャとして規定しており、クライアント−サーバ間の通信プロトコルとしてＯＳＩ（Open Systems Interconnection）の７レイヤ構造に従ったＤＡＰ（Directory Access 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」は、このフィルタリング規則テーブルが、「ユーザ(User)」のフィルタリングのテーブルであることを示している。また、例えば、ベースエントリ名称９１である「OU=PEOPLE,O=XYZ,C=JP」は、ベースエントリ名称が、国コード（C=Country Code）が日本(JP)で、会社名（組織名）(O=Orgnization)がＸＹＺ会社で、組織単位（OU=Organization Unit）が人事(PEOPLE)であることを示している。また、スコープ９２である「subtree」は、スコープがベースエントリ以下の全エントリ(Subtree)であることを示している。なお、スコープ９２としては、他に、「base」(ベースエントリのみ)、「onelevel」(ベースエントリの子エントリ)等がある。さらに、フィルタ条件９３である「(objectclass=inetOrgPerson)」は、OjbectClassの属性として、ＩＦＴＦで、人を表すものとして標準化されたものであることを示している。また、エントリ種別９４である「0」は、フィルタリング規則に適合するディレクトリエントリが、共通エントリ４２であることを示している。なお、エントリ種別９４である「1」の場合には、フィルタリング規則に適合するディレクトリエントリが固有エントリ４３であることを示している。
【００３５】
フィルタリング規則テーブル６には、同期処理を開始する前に、少なくとも、共通エントリを選別するフィルタリング規則と、固有エントリを選別するフィルタリング規則の２規則を登録しておく必要がある。
【００３６】
次に、図５を用いて、本実施形態によるディレクトリ同期方法に用いるスキーマ変換規則テーブル７のデータ構造について説明する。
スキーマ変換規則テーブル７は、ディレクトリデータ１１をアプリケーションデータ１３へ変換する際の変換規則を記憶するものである。スキーマ変換規則テーブル７は、配列構造をなし、スキーマ変換規則を複数格納可能である。
【００３７】
スキーマ変換規則テーブル７は、テーブル中のレコードを一意に識別する為の識別名の記憶領域１００と、スキーマ変換規則を適用する共通エントリ４２について、それが属するオブジェクトクラスの記憶領域１０１と、共通エントリの属性に関する属性変換規則の記憶領域１０２と、スキーマ変換規則を適用する固有エントリ４３について、それが属するオブジェクトクラスの記憶領域１０３と、固有エントリの属性に関する属性変換規則の記憶領域１０４と、アプリケーションデータ１３を一意に識別する値を格納する属性の名称の記憶領域１０５とから構成されている。
【００３８】
スキーマ変換規則テーブル７の情報例１０６に示すように、例えば、識別名１００である「mapUsr」は、このスキーマ変換規則テーブルが、「ユーザ(User)」用の変換規則テーブルであることを示している。また、対象クラス（共通）である「inetOrgPerson」は、スキーマ変換規則を適用する共通エントリ４２が属するオブジェクトクラスがＩＦＴＦで、人を表すものとして標準化されたものであることを示している。
【００３９】
ここで、図６を用いて、属性変換規則（共通）１０２及び属性変換規則（固有）１０４の構成について説明する。
属性変換規則１０２，１０４は、ディレクトリデータ１１の属性であるマッピング元属性の名称１０７と、前記属性に対応するアプリケーションデータ１３の属性であるマッピング先属性の名称１０８の組から成る。
例えば、図５に示した属性変換規則（共通）１０２である「cn,Name」は、ディレクトリデータ１１の属性であるマッピング元属性の名称「cn」が、この属性に対応するアプリケーションデータ１３の属性であるマッピング先属性の名称が「Name」であることを示しており、「sn,FamiliyName」ィレクトリデータ１１の属性であるマッピング元属性の名称「sn」が、この属性に対応するアプリケーションデータ１３の属性であるマッピング先属性の名称が「FamilyName」であることを示している。属性変換規則（固有）１０４も同様である。
【００４０】
また、対象クラス（固有）１０３である「app1Person」は、スキーマ変換規則を適用する固有エントリ４１が属するオブジェクトクラスが、図３に示したアプリケーション１（App1）であることを示している。さらに、識別子格納属性１０５である「uid」は、アプリケーションデータ１３を一意に識別する値を格納する属性の名称が「uid」であることを示している。
【００４１】
スキーマ変換規則は、アプリケーションが管理する情報の種類（ユーザ，組織，情報処理装置等）毎に必要であり、同期処理を開始する前に登録しておく必要がある。
【００４２】
次に、図７を用いて、本実施形態によるディレクトリ同期方法に用いる更新履歴記憶領域１６のデータ構造について説明する。
図１に示した更新履歴記憶領域１６は、ディレクトリサーバ１内のディレクトリデータ１１の更新履歴を記憶している。更新履歴記憶領域１６は、更新履歴テーブル１１０を記憶する。更新履歴テーブル１１０は、配列構造をなし、更新履歴の内容を複数格納可能である。
【００４３】
更新履歴テーブル１１０は、更新履歴番号の記憶領域１１１と、更新の対象となるエントリの名称の記憶領域１１２と、更新種別の記憶領域１１３と、更新内容の記憶領域１１４とから構成されている。
【００４４】
ここで、更新履歴番号１１１とは、各更新情報を一意に識別するための整数値であり、更新が処理された順番に１ずつ増加してゆくものである。例えば、更新履歴テーブル１１０の情報例１１５の中の更新履歴番号１１１である「１２４５」は、１２４５番目に更新された番号であることを示している。また、例えば、対象エントリ名称１１２である「UID=98001,OU=USR,OU=APP1,O=XYZ,C=JP」は、図３に示したように、国コード(C)が日本であり、組織名(O)がXYZ会社であり、単位がアプリケーション１(APP1)で、ユーザ(USR)であり、ユーザＩＤ(UID)が９８０００１のエントリを有することを示している。さらに、更新種別１１３である「add」は、更新の種別が追加(add)であることを示している。更新種別としては、他に、削除や変更がある。また、更新内容１１４である「objectclass:appPerson uid:98001 appServerName:Server1」は、オブジェクトクラス属性(objectclass)がappPersonで、ユーザーＩＤ(uid)が９８００１のアプリケーションデータは、サーバー名称(appServerName)がServer1というサーバが有していることを示している。
更新履歴テーブル１１０内のレコードは、更新履歴番号１１１の小さい順に並んでいる。
【００４５】
次に、図８を用いて、本実施形態によるディレクトリ同期方法に用いる更新履歴情報８のデータ構造について説明する。
更新履歴情報８は、ディレクトリ同期サーバ２が取得した更新履歴に関する情報を記憶するものである。
【００４６】
更新履歴情報８は、取得済みの更新履歴の内、最後に取得した更新履歴の更新履歴番号５１を記憶する更新履歴番号記憶領域５０と、各更新履歴の内容を記憶する取得済更新履歴テーブル５２とから構成されている。取得済更新履歴テーブル５２は配列構造をなし、更新情報を複数格納可能である。
【００４７】
取得済更新履歴テーブル５２は、更新履歴テーブル１１０と同様のデータ構造を持ち、更新履歴番号の記憶領域５３と、更新対象エントリの名称の記憶領域５４と、更新種別の記憶領域５５と、更新内容の記憶領域５６とから構成されている。取得済更新履歴テーブル５２の情報例５７は、図７に示した更新履歴テーブル１１０の情報例１１５と同様となる。取得済更新履歴テーブル５２内のレコードは、更新履歴番号５３の小さい順に並んでいる。
【００４８】
次に、図９を用いて、本実施形態によるディレクトリ同期方法に用いるスナップショット９のデータ構造について説明する。
スナップショット９は、配列構造をなし、エントリ情報を複数格納可能である。スナップショット９は、スナップショット逐次更新部１７が、同期処理中に更新履歴の情報を基に作成する。
【００４９】
スナップショット９は、レコード番号の記憶領域６０と、エントリ名称の記憶領域６１と、エントリ内容の記憶領域６２とから構成されている。
スナップショット９の情報例６３に示すように、レコード番号５である「５」は５番目のレコードであることを示している。また、エントリ名称６１である「UID=98001,OU=USR,OU=APP1,O=XYZ,C=JP」は、図６に示したエントリ名称１１２と同様である。エントリ内容６２である「pbjectclass:app1Person uid:98001 appl1ServerName:Server1 mail:suzuki@xyz.co.jp …… seeAlso:cn=一郎, sn=鈴木, ou=総務部, o=XYZ, c=jp」の中で、ユーザＩＤが９８００１である人のアプリケーション１のサーバー名やメールアドレスがエントリ内容であり、また、「seeAlso」は、リンクが張られていることを示している。リンク先には、鈴木一郎氏(cn=一郎,sn=鈴木)の所属（日本のＸＹＺ会社の総務部）があることを示している。
【００５０】
次に、図１０を用いて、本実施形態によるディレクトリ同期方法に用いるリンクインデックス７０のデータ構造について説明する。
リンクインデックス７０は、或る共通エントリへのリンクを持つ固有エントリの検索を高速化する為のものである。リンクインデックス７０は、配列構造をなし、インデックス情報を複数格納可能である。リンクインデックス７０は、スナップショット逐次更新部１７が、同期処理中に更新履歴の情報を基に作成する。
【００５１】
リンクインデックス７０は、エントリ名称の記憶領域７１と、そのエントリへリンクしているエントリのレコード番号の記憶領域７２とから構成されている。
リンクインデックス７０の情報例７３に示すように、エントリ名称である「CN=ichiro, SN=suzuki, OU=PEOPLE, O=XYZ, C=jp」は、固有エントリのエントリ名称を示している。
【００５２】
次に、図１１を用いて、本実施形態によるディレクトリ同期方法に用いる同期内容テーブル１０のデータ構造について説明する。
同期内容テーブル１０は、アプリケーションデータ１３に対する更新内容を記憶するものである。同期内容テーブル１０は、配列構造をなし、アプリケーションデータ１３に対する更新内容を複数格納可能である。
【００５３】
同期内容テーブル１０は、同期内容番号の記憶領域８０と、更新種別の記憶領域８１と、更新内容の記憶領域８２とから構成されている。
同期内容テーブル１０の情報例８３に示すように、例えば、更新種別８１である「add」は、更新内容が追加(add)であることを示している。更新種別としては、他に、変更や削除がある。更新内容８２である「table:USER userId:98001 name:ichirosuzuki serverName:Server1」は、サーバ名がServer1のユーザテーブル(USER)のユーザＩＤが９８００１に、ichirosuzukiの名前を追加することを示している。
【００５４】
次に、図１２〜図２３を用いて、本実施形態によるディレクトリ同期方法の動作について説明する。
最初に、図１２を用いて、本実施形態によるディレクトリ同期方法における更新履歴取得部３の処理内容について説明する。
【００５５】
更新履歴取得部３は、更新履歴の取得に関わる動作を定期的に実行する。
最初に、ステップＳ９０１において、更新履歴取得部３は、図８に示した更新履歴情報８の中の更新履歴番号記憶領域５０の取得済更新履歴番号５１を参照する。
【００５６】
次に、ステップＳ９０２において、更新履歴取得部３は、ディレクトリサーバ１が出力した更新履歴の内、ステップＳ９０１で取得した取得済更新履歴番号５１より大きい更新履歴番号を持つ更新履歴を全て取得する。例えば、取得済更新履歴番号５１が「１２４４」であったとすると、更新履歴番号が「１２４４」までの更新履歴が更新済みであるので、取得済更新履歴番号が「１２４５」以降の更新履歴（例えば、図７に示した更新履歴テーブル１１０の情報例１１５以降の更新履歴）を、更新履歴テーブル１１０から取得する。
【００５７】
そして、ステップＳ９０３において、更新履歴取得部３は、それら更新履歴の情報を、図８に示した取得済更新履歴テーブル５２に、情報例５７のように登録する。
最後に、ステップＳ９０４において、更新履歴取得部３は、ステップＳ９０２で取得した更新履歴の内、最後に取得した更新履歴の更新履歴番号を、更新履歴番号記憶領域５０の取得済更新履歴番号５１に登録する。
【００５８】
以上で、更新履歴取得部３の処理を終了して、ステップＳ９０５では、その後、スキーマ変換部４のスキーマ変換処理に移行する。スキーマ変換処理の詳細については、図１３を用いて説明する。
【００５９】
次に、図１３を用いて、本実施形態によるディレクトリ同期方法におけるスキーマ変換部４の処理内容について説明する。
最初に、ステップＳ１００１において、スキーマ変換部４は、図８に示した更新履歴情報８の中の取得済更新履歴テーブル５２の先頭レコードに登録されたディレクトリデータ１１に対する更新に関して、更新種別決定部１８の更新種別決定処理を実行する。更新種別決定処理の詳細については、図１４及び図１５を用いて後述する。
【００６０】
次に、ステップＳ１００２において、スキーマ変換部４は、アプリケーションデータ１３への更新内容を決定するため、属性マッピング処理を実行する。属性マッピング処理の詳細については、図１６〜図１８を用いて後述する。
【００６１】
次に、ステップＳ１００３において、スナップショット逐次更新部１７は、スナップショットの逐次更新処理を実行する。スナップショットの更新処理の詳細については、図１９〜図２２を用いて後述する。
【００６２】
次に、ステップＳ１００４において、スキーマ変換部４は、アプリケーションデータ１３に対する更新が不要と判断されたか否かを確認し、更新が不要ならば、ステップＳ１００６以降の処理へ移行し、更新が必要ならば、ステップＳ１００５を実行する。
【００６３】
更新が必要な場合には、ステップＳ１００５において、スキーマ変換部４は、図１１に示した同期内容テーブル１０に新規レコードを登録する。新規レコードの同期内容番号７０，更新種別７１及び更新内容７２には、それぞれ、現在処理中である取得済更新履歴テーブル５２のレコードの更新履歴番号５３，ステップＳ１００１で決定した更新種別及びステップＳ１００２で決定した更新内容を登録する。
【００６４】
次に、ステップＳ１００６において、スキーマ変換部４は、取得済更新履歴テーブル５２の全レコードに対して上述した処理を実行したか否かを判断する。実行していない場合には、ステップＳ１００７において、スキーマ変換部４は、取得済更新履歴テーブル５２から次履歴を取得し、ステップＳ１００１〜Ｓ１００５を繰り返し実行する。
【００６５】
また、全履歴の処理が終了すると、ステップＳ１００８において、スキーマ変換部４は、図８に示した取得済更新履歴テーブル５２を削除する。そして、スキーマ変換処理が終了すると、ステップＳ１００９において、アプリケーションデータ更新部５のアプリケーションデータ更新処理へ移行する。アプリケーションデータ更新処理の詳細については、図２３を用いて後述する。
【００６６】
ここで、図１４及び図１５を用いて、本実施形態によるディレクトリ同期方法における更新種別決定部１８の処理内容について説明する。
更新種別決定処理では、更新の対象となったディレクトリエントリが、更新が実行される前と更新が実行された後に関して、アプリケーションデータ１３への同期条件を満足するか否かを、スナップショット９を用いて調べ、その結果からアプリケーションデータ１３への更新種別を決定する。
ここで、「同期条件」とは、更新対象のエントリがフィルタリング規則テーブル６に登録されたフィルタリング規則のいずれかに適合し、かつ、そのエントリが共通エントリの場合は固有エントリとリンクしており、そのエントリが固有エントリの場合は共通エントリとリンクしているという条件のことである。
【００６７】
最初に、ステップＳ１１０１〜Ｓ１１０５において、更新種別決定部１８は、更新対象のディレクトリエントリが更新前に同期条件を満足していたか否かの判定を行なう。
即ち、ステップＳ１１０１において、更新種別決定部１８は、図８に示した取得済更新履歴テーブル５２の更新種別５５のデータにより、ディレクトリデータ１１に対する更新種別が追加か否かを確認する。追加の場合、追加される以前に更新対象のエントリは存在しておらず、同期条件を満足していなかったのは自明であるため、ステップＳ１１０６以降の処理に移行する。
【００６８】
追加以外の変更や削除の場合は、ステップＳ１１０２において、更新種別決定部１８は、図８に示した取得済更新履歴テーブル５２の対象エントリ名称５４と、図９に示したスナップショット９のエントリ名称６１が一致するという条件でスナップショット９を検索し、合致するレコードのスナップショット９のエントリ内容６２を取得する。これは、更新対象のエントリの更新前のエントリ内容である。
【００６９】
次に、ステップＳ１１０３において、更新種別決定部１８は、図４に示したフィルタリング規則テーブル６に登録されたレコードを順に参照し、ベースエントリ名称９１とスコープ９２で特定されたディレクトリツリー内に更新対象のエントリが存在し、かつ、ステップＳ１１０２で取得したエントリ内容がフィルタ条件９３を満たすか否か調べることで、適合するフィルタリング規則を検索する。例えば、図４に示したベースエントリ名称９１の情報例９５は、「OU=PEOPLE,O=XYZ,C=JP」であり、スコープ９２の情報例９５は、「subtree」であるので、図８に示した取得済更新履歴テーブル５２の対象エントリ名称５４の情報例５７では、更新対象のエントリが存在しないことになる。また、ベースエントリ名称９１が、「OU=APP1,O=XYZ,C=JP」であり、スコープ９２の情報例９５が、「subtree」であるならば、図８に示した取得済更新履歴テーブル５２の対象エントリ名称５４の情報例５７は、「UID=98001, OU=USR, OU=APP1, O=XYZ, C=JP」であるため、ベースエントリ以下のsubtreeにおいて更新対象のエントリが存在することになる。そして、ステップＳ１１０２で取得したエントリ内容６２がフィルタ条件を満たすかどうか調べる。
【００７０】
適合するフィルタリング規則が存在しない場合、更新種別決定部１８は、更新前は同期条件を満足しなかったと判断し、ステップＳ１１０６以降の処理に移行する。
また、適合するフィルタリング規則が存在した場合、更新種別決定部１８は、そのフィルタリング規則のエントリ種別９４を参照し、値が「０」である場合は前記ディレクトリエントリは共通エントリであると判断し、値が「１」である場合は固有エントリであると判断する。
【００７１】
次に、ステップＳ１１０５において、更新種別決定部１８は、更新対象のエントリとリンクするエントリが、更新前に存在したか否かの確認処理を行なう。存在した場合、更新前は同期条件を満足したと判断し、存在しなかった場合、更新前は同期条件を満足しなかったと判断する。
【００７２】
ここで、図１５を用いて、リンク先エントリの存在確認処理の内容について説明する。
リンク先エントリの存在確認処理は、更新対象のディレクトリエントリとリンクするエントリの存在確認をする処理であり、或る更新が実行される前の確認処理（図１４のステップＳ１１０５）と、実行された後の確認処理（図１４のステップＳ１１１３）がある。
【００７３】
最初に、ステップＳ１２０１において、更新種別決定部１８は、図１４のステップＳ１１０４或いはステップＳ１１１２の処理で取得したエントリ種別が共通エントリか固有エントリで処理を分岐する。固有エントリの場合は、ステップＳ１２０２に進み、共通エントリの場合には、ステップＳ１２０８に進む。
【００７４】
固有エントリの場合、ステップＳ１２０２において、更新種別決定部１８は、図１４のステップＳ１１０２の処理で取得した更新前のエントリ内容、或いはステップＳ１１０７〜Ｓ１１１０の処理で取得した更新後のエントリ内容が、リンクを格納する属性を含むか否かを調べる。リンクを格納する属性を含む場合とは、図９に示したスナップショット９のエントリ内容６２の中に、情報例６３に示すように、「seeAlso」の文を含む場合である。含む場合には、ステップＳ１２０３に進み、含まない場合には、ステップＳ１２０７に進む。
【００７５】
含む場合、ステップＳ１２０３において、更新種別決定部１８は、リンク先の共通エントリの存在確認のため、スナップショット９を、リンクを格納する属性の値とエントリ名称６１が一致するという条件で検索する。ここで、リンクを格納する属性の値とは、例えば、「sn=鈴木」である。
そして、ステップＳ１２０４において、更新種別決定部１８は、合致するレコードが存在するか否か調べる。存在する場合には、ステップＳ１２０５に進み、存在しない場合には、ステップＳ１２０７に進む。
【００７６】
存在した場合、ステップＳ１２０５において、更新種別決定部１８は、リンク先エントリが存在したと判断する。
次に、ステップＳ１２０６において、更新種別決定部１８は、合致したレコードを、スナップショット９から取得する。
【００７７】
ステップＳ１２０２の判断で、リンクが存在しない場合、また、ステップＳ１２０４の判断で、レコードが存在しない場合、ステップＳ１２０７において、更新種別決定部１８は、リンク先エントリはしないと判断する。
【００７８】
更新対象のエントリが共通エントリの場合、ステップＳ１２０８において、更新種別決定部１８は、リンクインデックス７０を、そのエントリの名称とエントリ名称７１が一致するという条件で検索する。
そして、ステップＳ１２０９において、更新種別決定部１８は、合致するレコードが存在するか否か調べる。存在する場合には、ステップＳ１２１０に進み、存在しない場合には、ステップＳ１２１３に進む。
【００７９】
存在した場合、ステップＳ１２１０において、更新種別決定部１８は、リンク先エントリが存在したと判断する。
そして、ステップＳ１２１１において、更新種別決定部１８は、スナップショット９を、合致したレコードのレコード番号７２とレコード番号６０が一致するという条件で検索する。
次に、ステップＳ１２１２において、更新種別決定部１８は、合致したレコードをスナップショット９から取得する。
【００８０】
一方、ステップＳ１２０９の判断において、合致するレコードが存在しなかった場合、ステップＳ１２１３において、更新種別決定部１８は、リンク先エントリは存在しなかったと判断する。
【００８１】
ここで、図１４に戻り、ステップＳ１１０６〜Ｓ１１１３において、更新種別決定部１８は、更新対象のディレクトリエントリが更新後に同期条件を満足するか否かの判定を行なう。
最初に、ステップＳ１１０６及びＳ１１０７において、更新種別決定部１８は、ディレクトリデータ１１への更新種別により処理を分岐する。即ち、更新種別が削除の場合には、削除された後ディレクトリエントリは存在せず、同期条件を満足しないのは自明であるため、ステップＳ１１１４に進み、更新種別が変更の場合には、ステップＳ１１０８に進み、更新種別が追加の場合には、ステップＳ１１１０に進む。
【００８２】
また、更新種別が変更ならば、ステップＳ１１０８において、更新種別決定部１８は、更新対象のエントリの名称とエントリ名称６１が一致するという条件でスナップショット９を検索し、合致するレコードのエントリ内容６２を取得する。
次に、ＳステップＳ１１０９において、更新種別決定部１８は、ステップＳ１１０８で取得したエントリ内容に、現在処理中の更新履歴レコードの更新内容５６を反映させ、更新後のエントリ内容を得る。即ち、図９に示したスナップショット９のエントリ内容６２に、図８に示した取得済更新履歴テーブル５２の更新内容５６を入れる。
【００８３】
さらに、更新種別が追加ならば、ステップＳ１１１０において、更新種別決定部１８は、更新後のエントリ内容は、現在処理中の更新履歴レコードの更新内容５６と同一であるとする。
【００８４】
次に、ステップＳ１１１１において、更新種別決定部１８は、フィルタリング規則テーブル６に登録されたレコードを順に参照し、ベースエントリ名称９１とスコープ９２で特定されたディレクトリツリー内に前記ディレクトリエントリが存在し、かつ、ステップＳ１１０９或いはステップＳ１１１０で取得した更新後のエントリ内容がフィルタ条件９３を満たすか否か調べる。適合するフィルタリング規則が存在する場合には、ステップＳ１１１２に進み、適合するフィルタリング規則が存在しない場合には、更新後は同期条件を満足しないと判断し、ステップＳ１１１４に進む。
【００８５】
適合するフィルタリング規則が存在する場合、ステップＳ１１１２において、更新種別決定部１８は、フィルタリング規則のエントリ種別９４を参照し、値が０である場合は前記ディレクトリエントリは共通エントリであると判断し、値が１である場合は固有エントリであると判断する。
その後、ステップＳ１１１３において、更新種別決定部１８は、更新後に前記ディレクトリエントリとリンクするエントリが存在するか否かの確認処理を行なう。リンク先のエントリの存在確認処理は、図１５に示したとおりである。存在する場合、更新後は同期条件を満足すると判断し、存在しない場合、更新後は同期条件を満足しないと判断する。
【００８６】
最後に、ステップＳ１１１４において、更新種別決定部１８は、以上の処理の結果からアプリケーションデータ１３への更新種別を決定する。すなわち、更新前に同期条件を満足せず、更新後に同期条件を満足する状態へ移行した場合は更新種別は「追加」である。更新前に同期条件を満足し、更新後に同期条件を満足しない状態へ移行した場合は更新種別は「削除」である。更新前後共に同期条件を満足する場合は更新種別は「変更」である。更新前後共に同期条件を満足しない場合はアプリケーションデータ１３へは更新を行なわない。このようにして、共有エントリと固有エントリの同期をとり、同期条件を満たさない場合には、更新を行わないようにすることにより、不整合が発生することを防止できる。
【００８７】
次に、図１６〜図１８を用いて、本実施形態によるディレクトリ同期方法における属性マッピング処理の内容について説明する。
属性マッピング処理は、図１３に示したスキーマ処理の中のステップＳ１００２における処理である。
【００８８】
最初に、図１６を用いて、属性マッピング処理の全体的な処理内容について説明する。
最初に、ステップＳ１３０１及びＳ１３０２において、スキーマ変換部４は、図１４のＳ１１１４で決定したアプリケーションデータ１３に対する更新種別により処理を分岐する。
【００８９】
まず、アプリケーションデータ１３に対する更新を行なわない場合は、何も行なう必要はないため、属性マッピング処理を終了する。
更新種別が削除の場合には、ステップＳ１３０３において、スキーマ変換部４は、削除に関する属性マッピング処理を実行する。削除に関する属性マッピング処理の詳細については、図１７を用いて後述する。
更新種別が追加及び変更の場合には、ステップＳ１３０４において、スキーマ変換部４は、追加，変更に関する属性マッピング処理を実行する。追加，変更に関する属性マッピング処理の詳細については、図１８を用いて後述する。
【００９０】
次に、図１７を用いて、削除に関する属性マッピング処理の処理内容について説明する。
最初に、ステップＳ１４０１において、スキーマ変換部４は、更新対象のディレクトリエントリに適用するスキーマ変換規則を決定する。そのために、図１４のステップＳ１１０４で取得したエントリ種別により処理を分岐する。更新対象のエントリが共通エントリである場合には、ステップＳ１４０２に進み、更新対象のエントリが固有エントリである場合、ステップＳ１４０４に進む。
【００９１】
更新対象のエントリが共通エントリである場合、ステップＳ１４０２において、スキーマ変換部４は、図１４のステップＳ１１０２で取得したエントリ内容から、オブジェクトクラスを格納するobjectclass属性を取り出す。例えば、図９に示した例では、スナップショット９のエントリ内容６２から、情報例６３に示すobjectclass属性である「app1Person」を取り出す。
次に、ステップＳ１４０３において、スキーマ変換部４は、図１５のＳ１２１２で取得したリンク先の固有エントリのエントリ内容からも、objectclass属性を取り出す。
【００９２】
また、更新対象のディレクトリエントリが固有エントリである場合、ステップＳ１４０４において、スキーマ変換部４は、図１４のＳ１１０２で取得したエントリ内容から、オブジェクトクラスを格納するobjectclass属性を取り出す。
次に、ステップＳ１４０５において、スキーマ変換部４は、図１５のＳ１２０６で取得したリンク先の共通エントリのエントリ内容からも、objectclass属性を取り出す。
【００９３】
次に、適用するスキーマ変換規則を決定する。まず、ステップＳ１４０６において、スキーマ変換部４は、スキーマ変換規則テーブル７の先頭レコードを参照し、共通エントリの対象クラス１０１が、ステップＳ１４０２、或いはＳ１４０５の処理で取得した共通エントリのobjectclass属性に含まれ、かつ、固有エントリの対象クラス１０３が、ステップＳ１４０３、或いはＳ１４０４の処理で取得した固有エントリのobjectclass属性に含まれるか否か調べる。含まれる場合には、ステップＳ１４０８に進み、含まれない場合には、ステップＳ１４０７に進み、ステップＳ１４０７において、スキーマ変換部４は、次の規則を参照し、同様の処理を繰り返す。
【００９４】
含まれる場合、ステップＳ１４０８において、スキーマ変換部４は、そのスキーマ変換規則の識別子格納属性名称１０５を取得する。
次に、ステップＳ１４０９において、スキーマ変換部４は、図１４のステップＳ１１０４で取得したエントリ種別により、処理を分岐する。即ち、エントリ種別が共通エントリの場合には、ステップＳ１４１０に進み、固有エントリの場合には、ステップＳ１４１１に進む。そして、ステップＳ１４１０若しくは、ステップＳ１４１１において、固有エントリに格納されているアプリケーションデータ１３内の削除すべきエントリを一意に特定する識別子を取得する。
【００９５】
更新対象のディレクトリエントリが共通エントリである場合、ステップＳ１４１０において、スキーマ変換部４は、図１５のステップＳ１２１２で取得したリンク先固有エントリのエントリ内容から、ステップＳ１４０８で取得した名称を持つ属性（アプリケーションデータ１３の識別子を格納する属性）を取り出す。例えば、図５に示したように、スキーマ変換規則テーブル７の識別子格納属性名称１０５が、情報例１０６に示すように、「uid」である場合、図９に示したスナップショット９のエントリ内容６２から、情報例６３に示す例の場合には、ユーザＩＤ（uid）として、「98001」を取り出す。
【００９６】
また、ディレクトリエントリが固有エントリである場合、ステップＳ１４１１において、スキーマ変換部４は、図１４のステップＳ１１０２で取得した更新対象エントリのエントリ内容から、ステップＳ１４０８で取得した名称を持つ属性を取り出す。
そして、ステップＳ１４１２において、スキーマ変換部４は、ステップＳ１４１０、或いはＳ１４１１で取得した識別子を格納する属性が、アプリケーションデータ１３に対する更新内容とする。
【００９７】
次に、図１８を用いて、追加，変更に関する属性マッピング処理の処理内容について説明する。
最初に、ステップＳ１５０１において、スキーマ変換部４は、更新対象のディレクトリエントリに適用するスキーマ変換規則を決定する。そのために、図１４のステップＳ１１１２で取得したエントリ種別により処理を分岐する。更新対象のエントリが共通エントリである場合には、ステップＳ１５０２に進み、更新対象のエントリが固有エントリである場合、ステップＳ１５０４に進む。
【００９８】
更新対象のエントリが共通エントリである場合、ステップＳ１５０２において、スキーマ変換部４は、図１４のステップＳ１１０７で取得したエントリ内容から、オブジェクトクラスを格納するobjectclass属性を取り出す。
次に、ステップＳ１５０３において、スキーマ変換部４は、図１５のＳ１２１２で取得したリンク先の固有エントリのエントリ内容からも、objectclass属性を取り出す。
【００９９】
また、更新対象のディレクトリエントリが固有エントリである場合、ステップＳ１５０４において、スキーマ変換部４は、図１４のＳ１１１０で取得したエントリ内容から、オブジェクトクラスを格納するobjectclass属性を取り出す。
次に、ステップＳ１５０５において、スキーマ変換部４は、図１５のＳ１２０６で取得したリンク先の共通エントリのエントリ内容からも、objectclass属性を取り出す。
【０１００】
次に、適用するスキーマ変換規則を決定する。まず、ステップＳ１５０６において、スキーマ変換部４は、スキーマ変換規則テーブル７の先頭レコードを参照し、共通エントリの対象クラス１０１が、ステップＳ１５０２、或いはＳ１５０５の処理で取得した共通エントリのobjectclass属性に含まれ、かつ、固有エントリの対象クラス１０３が、ステップＳ１５０３、或いはＳ１５０４の処理で取得した固有エントリのobjectclass属性に含まれるか否か調べる。含まれる場合には、ステップＳ１５０８に進み、含まれない場合には、ステップＳ１５０７に進み、ステップＳ１５０７において、スキーマ変換部４は、次の規則を参照し、同様の処理を繰り返す。
【０１０１】
次に、ステップＳ１５０８において、スキーマ変換部４は、Ｓ１５０６で決定したスキーマ変換規則の共通エントリに対する属性変換規則１０２を参照し、共通エントリのエントリ内容に含まれる属性名をアプリケーションデータ１３の属性名に置換する。
例えば、図５に示したように、属性変換規則（共通）１０２として、情報例１０６に示すように、「cn,Name」とある場合には、共通エントリの属性名「cn:一郎」を、アプリケーションデータの属性名「Name:ichiro」に置換する。
次に、ステップＳ１５０９において、スキーマ変換部４は、属性名の置換がすべての属性について行われたか否かを判断し、行われていない場合には、ステップＳ１５１０において、スキーマ変換部４は、次の属性について、属性名の置換を行う。
【０１０２】
属性名の置換が、共通エントリのエントリ内容に含まれる全属性に対して行なわれると、ステップＳ１５１１において、スキーマ変換部４は、ステップＳ１５０６で決定したスキーマ変換規則の固有エントリに対する属性変換規則１０４を参照し、固有エントリのエントリ内容に含まれる属性名をアプリケーションデータ１３の属性名に置換する。
次に、ステップＳ１５１２において、スキーマ変換部４は、属性名の置換がすべての属性について行われたか否かを判断し、行われていない場合には、ステップＳ１５１３において、スキーマ変換部４は、次の属性について、属性名の置換を行う。
【０１０３】
属性名の置換が、固有エントリのエントリ内容に含まれる全属性に対して行なわれると、ステップＳ１５１４において、スキーマ変換部４は、ステップＳ１５０８〜Ｓ１５１０までの処理により決定したアプリケーションデータ１３の属性、及びステップＳ１５１１〜Ｓ１５１３までの処理により決定したアプリケーションデータ１３の属性を結合することにより、アプリケーションデータ１３に対する更新内容を得る。
【０１０４】
次に、図１９〜図２２を用いて、本実施形態によるディレクトリ同期方法におけるスナップショットの更新処理の内容について説明する。
スナップショットの更新処理は、図１３に示したスキーマ処理の中のステップＳ１００３における処理であり、スナップショット逐次更新部１７が行うものである。
【０１０５】
図１９に示すように、ステップＳ１６０１及びＳ１６０２において、スナップショット逐次更新部１７は、現在処理中の更新履歴の更新種別により処理を分岐する。即ち、追加の場合は、ステップＳ１６０３において追加処理を実行し、変更の場合は、ステップＳ１６０４において変更処理を実行し、削除の場合は、ステップＳ１６０５において削除処理を実行する。それぞれの処理の詳細については、図２０〜図２２を用いて説明する。
【０１０６】
最初に、図２０を用いて、スナップショット９のレコード追加処理の内容について説明する。
ステップＳ１７０１において、スナップショット逐次更新部１７は、スナップショット９に新規レコードを登録する。この時、レコード番号６０には、他のレコードと重複しない値を登録する。例えば、レコードを登録する毎に１ずつ加算した値を割り当てるようにする。エントリ名称６１には、更新対象のディレクトリエントリの名称を登録する。例えば、エントリ名称６１には、図８に示した取得済更新履歴テーブル５２の対象エントリ名称５４の情報例５７の「UID=98001, OU=USR, OU=APP1, O=XYZ, C=JP」を登録する。また、エントリ内容６２には、図１４のステップＳ１１０９、或いはＳ１１１０の処理により取得した更新後のエントリ内容を登録する。例えば、図８に示した取得済更新履歴テーブル５２の更新内容５６の情報例５７である「objectclass:appPerson uid:98001 appServerName:Server1」を登録する。
【０１０７】
次に、ステップＳ１７０２において、スナップショット逐次更新部１７は、ステップＳ１１１２の処理により取得したエントリ種別により処理を分岐する。即ち、更新対象のディレクトリエントリが共通エントリの場合、リンクを格納する属性は持たないため、レコード追加処理を終了する。固有エントリの場合、ステップＳ１７０３に進む。
【０１０８】
そして、ステップＳ１７０３において、スナップショット逐次更新部１７は、更新後のエントリ内容を参照して、リンクを格納する属性が含まれるか否か調べる。含まれる場合には、ステップＳ１７０４に進み、含まれない場合には、レコード追加処理を終了する。
【０１０９】
次に、含まれる場合、ステップＳ１７０４において、スナップショット逐次更新部１７は、リンクインデックス７０に、新規レコードを登録する。この時、リンク先エントリ名称７１には、前記属性の値を登録する。レコード番号７２は、Ｓ１７０１で登録したスナップショットの新規レコードのレコード番号６０と同一の値を登録する。
【０１１０】
次に、図２１を用いて、スナップショット９のレコード変更処理の内容について説明する。
最初に、ステップＳ１８０１において、スナップショット逐次更新部１７は、図１４のステップＳ１１０８の処理で実行したスナップショット９の検索において、検索条件に合致したレコードのエントリ内容６２を変更する。この時、検索条件に合致したレコードのエントリ内容６２を、図１４のＳ１１０９の処理により取得した更新後のエントリ内容で上書きする。
【０１１１】
次に、ステップＳ１８０２において、スナップショット逐次更新部１７は、図１４のＳ１１１２の処理により取得したエントリ種別により処理を分岐する。即ち、更新対象のディレクトリエントリが共通エントリの場合、リンクを格納する属性は持たないため、レコード変更処理を終了する。固有エントリの場合には、ステップＳ１８０３に進む。
【０１１２】
固有エントリの場合、ステップＳ１８０３〜Ｓ１８０５において、スナップショット逐次更新部１７は、変更履歴テーブル５２の現在処理中であるレコードの更新内容５６を参照して、共通エントリに対するリンクを格納する属性が更新されたか否か調べる。そして、更新種別によって処理が分岐し、リンクを格納する属性の追加の場合には、ステップＳ１８０６に進み、リンクを格納する属性の削除の場合には、ステップＳ１８０７に進み、リンクを格納する属性の変更の場合には、ステップＳ１８０８に進む。
【０１１３】
リンクを格納する属性が追加された場合には、ステップＳ１８０６において、スナップショット逐次更新部１７は、リンクインデックス７０に、新規レコードを登録する。この時、リンク先エントリ名称７１には、前記属性の値を登録する。レコード番号７２は、ステップＳ１８０１の処理で変更したスナップショット９のレコードのレコード番号６０と同一の値を登録する。
【０１１４】
リンクを格納する属性が削除された場合には、ステップＳ１８０７において、スナップショット逐次更新部１７は、リンクインデックス７０からレコードを削除する。すなわち、まず、図１４のＳ１１０２の処理により取得したエントリ内容６２からリンクを格納する属性を取り出す。次に、リンクインデックス７０を、前記属性の値とエントリ名称７１が一致するという条件で検索し、合致するレコードを削除する。
【０１１５】
リンクを格納する属性が変更された場合には、ステップＳ１８０８において、スナップショット逐次更新部１７は、リンクインデックス７０からレコードを削除し、新規レコードを追加する。すなわち、まず、図１４のステップＳ１１０２で取得したエントリ内容６２からリンクを格納する属性の値を取り出す。次に、リンクインデックス７０を、前記属性の値とエントリ名称７１が一致するという条件で検索し、合致するレコードを削除する。その後、新規レコードを登録する。この時、エントリ名称７１には、図１４のステップＳ１１０９の処理により取得した更新後のエントリ内容からリンクを格納する属性を取り出し、その属性の値を登録する。レコード番号７２は、Ｓ１８０１で変更したスナップショット９のレコードのレコード番号６０と同一の値を登録する。
【０１１６】
次に、図２２を用いて、スナップショット９のレコード削除処理の内容について説明する。
最初に、ステップＳ１９０１において、スナップショット逐次更新部１７は、図１４のステップＳ１１０４の処理により取得したエントリ種別により処理を分岐する。更新対象のディレクトリエントリが共通エントリの場合には、リンクを格納する属性は持たないため、ステップＳ１９０４に進む。また、固有エントリの場合には、ステップＳ１９０２に進む。
【０１１７】
固有エントリの場合には、ステップＳ１９０２において、スナップショット逐次更新部１７は、図１４のＳ１１０２の処理により取得したスナップショット９のエントリ内容６２に、図３のリンク４５を格納する属性が含まれるか否か調べる。含まれる場合には、ステップＳ１９０３に進み、含まれない場合には、ステップＳ１９０４に進む。
【０１１８】
リンクを格納する属性が含まれる場合には、ステップＳ１９０３において、スナップショット逐次更新部１７は、リンクインデックス７０を、前記属性の値とエントリ名称７１が一致するという条件で検索し、合致するレコードを削除する。
最後に、ステップＳ１９０４において、スナップショット逐次更新部１７は、図１４のステップＳ１１０２の処理により取得した、スナップショット９のレコードを削除する。
【０１１９】
次に、図２３を用いて、本実施形態によるディレクトリ同期方法におけるアプリケーションデータの更新処理の内容について説明する。
アプリケーションデータの更新処理は、アプリケーションデータ更新部５によって実行される。
【０１２０】
最初に、ステップＳ２００１において、アプリケーションデータ更新部５は、同期内容テーブル１０の先頭レコードを取得する。
【０１２１】
次に、ステップＳ２００２において、アプリケーションデータ更新部５は、前記レコードの更新内容８２に従って、アプリケーションデータ１３を更新する。
【０１２２】
次に、ステップＳ２００３において、アプリケーションデータ更新部５は、すべての更新内容に処理が実行されたか否かを判断し、実行されていない場合には、ステップＳ２００４に進んで、次の同期内容レコードを取り出し、ステップＳ２００１及びＳ２００２を実行して、同期内容テーブル１０の全レコードに対して実行する。
全ての同期内容レコードについて処理が実行されると、ステップＳ２００５において、アプリケーションデータ更新部５は、同期内容レコード１０の全レコードを削除する。
【０１２３】
なお、以上の説明では、ディレクトリ同期サーバ２を用いて、本実施形態によるディレクトリ同期方法を実現しているが、ディレクトリサーバ１を用いて、本実施形態によるディレクトリ同期方法を実現するようにしてもよいものである。そのためには、図１に示した更新履歴取得部３，スキーマ変換部４，更新種別決定部１８，スナップショット逐次更新部１７，アプリケーションデータ更新部５や、各テーブル６，７，８、９，１０を、ディレクトリサーバ１内に備えるようにすればよいものである。
【０１２４】
以上説明したように、本実施形態によれば、ディレクトリサーバが出力する更新履歴を定期的に取得し、その更新履歴に基づき作成されるディレクトリデータのスナップショットと更新履歴からアプリケーションデータに対して行うべき更新内容を取得し、アプリケーションデータを更新することで、従来はディレクトリサーバの検索を要するためディレクトリエントリ数増大に従って所要時間が増大したディレクトリ同期処理を、ディレクトリエントリ数に関わらず一定の時間で実行することが可能となる。
即ち、従来は、更新時に全スナップショットを作成していたので、ディレクトリエントリ数増大に従ってスナップショット作成時間が増大するのに対して、本実施形態においては、更新履歴を取得する毎に、スナップショットを作成しているので、更新時のスナップショット作成が不要となるため、ディレクトリエントリ数が増大しても、更新所要時間が増大することはないものである。
【０１２５】
また、本実施形態によれば、ディレクトリサービスに対する更新を禁止する期間を無くしディレクトリサービスの可用性を向上することが可能である。
即ち、従来は、スナップショットを取得している間はディレクトリサービスに対する更新を禁止しなければならないため、更新を禁止する期間を設ける必要があったのに対して、本実施形態においては、更新履歴情報に基づいて更新を行っており、更新の途中に新たな更新情報が追加されたとしても、新たな更新情報について更新は次回に行うため、更新を禁止する期間を設ける必要はないものである。
【０１２６】
さらに、従来は同期処理を行う間隔を短くしたとしても、スナップショットを取得している間は必ずディレクトリデータとアプリケーションデータが不整合状態となったが、本実施形態によれば、更新履歴を取得する間隔を短くすることにより、ディレクトリデータとアプリケーションデータの間に不整合が発生する期間をより短くすることができる。
即ち、図１４のステップＳ１１１４の判断で同期条件を満たさないこととなるため、同期条件を満たさない場合には、更新を行わないようにすることにより、不整合が発生することを防止できる。
【０１２７】
【発明の効果】
本発明によれば、ディレクトリサービスに登録されるディレクトリエントリの数が増加した場合も、ディレクトリサービスとアプリケーションの同期に要する時間を一定に保つことができる。
【図面の簡単な説明】
【図１】本発明の一実施形態によるディレクトリ同期方法を実行するディレクトリ同期システムのシステム構成図である。
【図２】本発明の一実施形態によるディレクトリ同期方法を実行するディレクトリシステムを構成するディレクトリサーバ，アプリケーションサーバ及びディレクトリ同期サーバのシステム構成について説明する。
【図３】本発明の一実施形態によるディレクトリ同期方法に用いるディレクトリデータの論理構造の説明図である。
【図４】本発明の一実施形態によるディレクトリ同期方法に用いるフィルタリング規則テーブルのデータ構造の説明図である。
【図５】本発明の一実施形態によるディレクトリ同期方法に用いるスキーマ変換規則テーブルのデータ構造の説明図である。
【図６】本発明の一実施形態によるディレクトリ同期方法に用いるスキーマ変換テーブルの属性変換規則のデータ構造の説明図である。
【図７】本発明の一実施形態によるディレクトリ同期方法に用いる更新履歴記憶領域のデータ構造の説明図である。
【図８】本発明の一実施形態によるディレクトリ同期方法に用いる更新履歴情報のデータ構造の説明図である。
【図９】本発明の一実施形態によるディレクトリ同期方法に用いるスナップショットのデータ構造の説明図である。
【図１０】本発明の一実施形態によるディレクトリ同期方法に用いるリンクインデックスのデータ構造の説明図である。
【図１１】本発明の一実施形態によるディレクトリ同期方法に用いる同期内容テーブルのデータ構造の説明図である。
【図１２】本発明の一実施形態によるディレクトリ同期方法における更新履歴取得部の処理内容を示すフローチャートである。
【図１３】本発明の一実施形態によるディレクトリ同期方法におけるスキーマ変換部の処理内容を示すフローチャートである。
【図１４】本発明の一実施形態によるディレクトリ同期方法における更新種別決定部の処理内容を示すフローチャートである。
【図１５】本発明の一実施形態によるディレクトリ同期方法における更新種別決定部の処理内容を示すフローチャートである。
【図１６】本発明の一実施形態によるディレクトリ同期方法における属性マッピング処理の全体的な処理内容を示すフローチャートである。
【図１７】本発明の一実施形態によるディレクトリ同期方法における属性マッピング処理の中の削除時のマッピング処理容を示すフローチャートである。
【図１８】本発明の一実施形態によるディレクトリ同期方法における属性マッピング処理の中の追加，変更時のマッピング処理内容を示すフローチャートである。
【図１９】本発明の一実施形態によるディレクトリ同期方法におけるスナップショットの更新処理の全体的な処理内容を示すフローチャートである。
【図２０】本発明の一実施形態によるディレクトリ同期方法におけるスナップショットの更新処理の中の削除処理の内容を示すフローチャートである。
【図２１】本発明の一実施形態によるディレクトリ同期方法におけるスナップショットの更新処理の中の変更処理の内容を示すフローチャートである。
【図２２】本発明の一実施形態によるディレクトリ同期方法におけるスナップショットの更新処理の中の追加処理の内容を示すフローチャートである。
【図２３】本発明の一実施形態によるディレクトリ同期方法におけるアプリケーションデータの更新処理の全体的な処理内容を示すフローチャートである。
【符号の説明】
１…ディレクトリサーバ
２…ディレクトリ同期サーバ
３…更新履歴取得部
４…スキーマ変換部
５…アプリケーションデータ更新部
６…フィルタリング規則テーブル
７…スキーマ変換規則テーブル
８…更新履歴情報
９…スナップショット
１０…同期内容テーブル
１１…ディレクトリデータ
１２…アプリケーションサーバ
１３…アプリケーションデータ
１４，１５…ＤＢ
１６…更新履歴記憶領域
１７…スナップショット逐次更新部
１８…更新種別決定部
【発明の属する技術分野】
本発明は、ディレクトリサービスに対する更新を、アプリケーションのデータベースに反映させるディレクトリ同期方法に関する。
【０００２】
【従来の技術】
ディレクトリサービスとは、電子メールの送信相手の姓名等から電子メールの宛先を検索できるサービスであり、電子メールシステムにおける電子的な電話帳機能として利用されている。
【０００３】
ディレクトリサービスに関する標準としては、ＣＣＩＴＴの勧告であるＸ．５００（ＩＳＯ９５９４）が挙げられる。Ｘ．５００は、ディレクトリサービスをクライアント−サーバ型の分散システム・アーキテクチャとして規定しており、クライアント−サーバ間の通信プロトコルとしてＯＳＩ（Open Systems Interconnection）の７レイヤ構造に従ったＤＡＰ（Directory Access 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」は、このフィルタリング規則テーブルが、「ユーザ(User)」のフィルタリングのテーブルであることを示している。また、例えば、ベースエントリ名称９１である「OU=PEOPLE,O=XYZ,C=JP」は、ベースエントリ名称が、国コード（C=Country Code）が日本(JP)で、会社名（組織名）(O=Orgnization)がＸＹＺ会社で、組織単位（OU=Organization Unit）が人事(PEOPLE)であることを示している。また、スコープ９２である「subtree」は、スコープがベースエントリ以下の全エントリ(Subtree)であることを示している。なお、スコープ９２としては、他に、「base」(ベースエントリのみ)、「onelevel」(ベースエントリの子エントリ)等がある。さらに、フィルタ条件９３である「(objectclass=inetOrgPerson)」は、OjbectClassの属性として、ＩＦＴＦで、人を表すものとして標準化されたものであることを示している。また、エントリ種別９４である「0」は、フィルタリング規則に適合するディレクトリエントリが、共通エントリ４２であることを示している。なお、エントリ種別９４である「1」の場合には、フィルタリング規則に適合するディレクトリエントリが固有エントリ４３であることを示している。
【００３５】
フィルタリング規則テーブル６には、同期処理を開始する前に、少なくとも、共通エントリを選別するフィルタリング規則と、固有エントリを選別するフィルタリング規則の２規則を登録しておく必要がある。
【００３６】
次に、図５を用いて、本実施形態によるディレクトリ同期方法に用いるスキーマ変換規則テーブル７のデータ構造について説明する。
スキーマ変換規則テーブル７は、ディレクトリデータ１１をアプリケーションデータ１３へ変換する際の変換規則を記憶するものである。スキーマ変換規則テーブル７は、配列構造をなし、スキーマ変換規則を複数格納可能である。
【００３７】
スキーマ変換規則テーブル７は、テーブル中のレコードを一意に識別する為の識別名の記憶領域１００と、スキーマ変換規則を適用する共通エントリ４２について、それが属するオブジェクトクラスの記憶領域１０１と、共通エントリの属性に関する属性変換規則の記憶領域１０２と、スキーマ変換規則を適用する固有エントリ４３について、それが属するオブジェクトクラスの記憶領域１０３と、固有エントリの属性に関する属性変換規則の記憶領域１０４と、アプリケーションデータ１３を一意に識別する値を格納する属性の名称の記憶領域１０５とから構成されている。
【００３８】
スキーマ変換規則テーブル７の情報例１０６に示すように、例えば、識別名１００である「mapUsr」は、このスキーマ変換規則テーブルが、「ユーザ(User)」用の変換規則テーブルであることを示している。また、対象クラス（共通）である「inetOrgPerson」は、スキーマ変換規則を適用する共通エントリ４２が属するオブジェクトクラスがＩＦＴＦで、人を表すものとして標準化されたものであることを示している。
【００３９】
ここで、図６を用いて、属性変換規則（共通）１０２及び属性変換規則（固有）１０４の構成について説明する。
属性変換規則１０２，１０４は、ディレクトリデータ１１の属性であるマッピング元属性の名称１０７と、前記属性に対応するアプリケーションデータ１３の属性であるマッピング先属性の名称１０８の組から成る。
例えば、図５に示した属性変換規則（共通）１０２である「cn,Name」は、ディレクトリデータ１１の属性であるマッピング元属性の名称「cn」が、この属性に対応するアプリケーションデータ１３の属性であるマッピング先属性の名称が「Name」であることを示しており、「sn,FamiliyName」ィレクトリデータ１１の属性であるマッピング元属性の名称「sn」が、この属性に対応するアプリケーションデータ１３の属性であるマッピング先属性の名称が「FamilyName」であることを示している。属性変換規則（固有）１０４も同様である。
【００４０】
また、対象クラス（固有）１０３である「app1Person」は、スキーマ変換規則を適用する固有エントリ４１が属するオブジェクトクラスが、図３に示したアプリケーション１（App1）であることを示している。さらに、識別子格納属性１０５である「uid」は、アプリケーションデータ１３を一意に識別する値を格納する属性の名称が「uid」であることを示している。
【００４１】
スキーマ変換規則は、アプリケーションが管理する情報の種類（ユーザ，組織，情報処理装置等）毎に必要であり、同期処理を開始する前に登録しておく必要がある。
【００４２】
次に、図７を用いて、本実施形態によるディレクトリ同期方法に用いる更新履歴記憶領域１６のデータ構造について説明する。
図１に示した更新履歴記憶領域１６は、ディレクトリサーバ１内のディレクトリデータ１１の更新履歴を記憶している。更新履歴記憶領域１６は、更新履歴テーブル１１０を記憶する。更新履歴テーブル１１０は、配列構造をなし、更新履歴の内容を複数格納可能である。
【００４３】
更新履歴テーブル１１０は、更新履歴番号の記憶領域１１１と、更新の対象となるエントリの名称の記憶領域１１２と、更新種別の記憶領域１１３と、更新内容の記憶領域１１４とから構成されている。
【００４４】
ここで、更新履歴番号１１１とは、各更新情報を一意に識別するための整数値であり、更新が処理された順番に１ずつ増加してゆくものである。例えば、更新履歴テーブル１１０の情報例１１５の中の更新履歴番号１１１である「１２４５」は、１２４５番目に更新された番号であることを示している。また、例えば、対象エントリ名称１１２である「UID=98001,OU=USR,OU=APP1,O=XYZ,C=JP」は、図３に示したように、国コード(C)が日本であり、組織名(O)がXYZ会社であり、単位がアプリケーション１(APP1)で、ユーザ(USR)であり、ユーザＩＤ(UID)が９８０００１のエントリを有することを示している。さらに、更新種別１１３である「add」は、更新の種別が追加(add)であることを示している。更新種別としては、他に、削除や変更がある。また、更新内容１１４である「objectclass:appPerson uid:98001 appServerName:Server1」は、オブジェクトクラス属性(objectclass)がappPersonで、ユーザーＩＤ(uid)が９８００１のアプリケーションデータは、サーバー名称(appServerName)がServer1というサーバが有していることを示している。
更新履歴テーブル１１０内のレコードは、更新履歴番号１１１の小さい順に並んでいる。
【００４５】
次に、図８を用いて、本実施形態によるディレクトリ同期方法に用いる更新履歴情報８のデータ構造について説明する。
更新履歴情報８は、ディレクトリ同期サーバ２が取得した更新履歴に関する情報を記憶するものである。
【００４６】
更新履歴情報８は、取得済みの更新履歴の内、最後に取得した更新履歴の更新履歴番号５１を記憶する更新履歴番号記憶領域５０と、各更新履歴の内容を記憶する取得済更新履歴テーブル５２とから構成されている。取得済更新履歴テーブル５２は配列構造をなし、更新情報を複数格納可能である。
【００４７】
取得済更新履歴テーブル５２は、更新履歴テーブル１１０と同様のデータ構造を持ち、更新履歴番号の記憶領域５３と、更新対象エントリの名称の記憶領域５４と、更新種別の記憶領域５５と、更新内容の記憶領域５６とから構成されている。取得済更新履歴テーブル５２の情報例５７は、図７に示した更新履歴テーブル１１０の情報例１１５と同様となる。取得済更新履歴テーブル５２内のレコードは、更新履歴番号５３の小さい順に並んでいる。
【００４８】
次に、図９を用いて、本実施形態によるディレクトリ同期方法に用いるスナップショット９のデータ構造について説明する。
スナップショット９は、配列構造をなし、エントリ情報を複数格納可能である。スナップショット９は、スナップショット逐次更新部１７が、同期処理中に更新履歴の情報を基に作成する。
【００４９】
スナップショット９は、レコード番号の記憶領域６０と、エントリ名称の記憶領域６１と、エントリ内容の記憶領域６２とから構成されている。
スナップショット９の情報例６３に示すように、レコード番号５である「５」は５番目のレコードであることを示している。また、エントリ名称６１である「UID=98001,OU=USR,OU=APP1,O=XYZ,C=JP」は、図６に示したエントリ名称１１２と同様である。エントリ内容６２である「pbjectclass:app1Person uid:98001 appl1ServerName:Server1 mail:suzuki@xyz.co.jp …… seeAlso:cn=一郎, sn=鈴木, ou=総務部, o=XYZ, c=jp」の中で、ユーザＩＤが９８００１である人のアプリケーション１のサーバー名やメールアドレスがエントリ内容であり、また、「seeAlso」は、リンクが張られていることを示している。リンク先には、鈴木一郎氏(cn=一郎,sn=鈴木)の所属（日本のＸＹＺ会社の総務部）があることを示している。
【００５０】
次に、図１０を用いて、本実施形態によるディレクトリ同期方法に用いるリンクインデックス７０のデータ構造について説明する。
リンクインデックス７０は、或る共通エントリへのリンクを持つ固有エントリの検索を高速化する為のものである。リンクインデックス７０は、配列構造をなし、インデックス情報を複数格納可能である。リンクインデックス７０は、スナップショット逐次更新部１７が、同期処理中に更新履歴の情報を基に作成する。
【００５１】
リンクインデックス７０は、エントリ名称の記憶領域７１と、そのエントリへリンクしているエントリのレコード番号の記憶領域７２とから構成されている。
リンクインデックス７０の情報例７３に示すように、エントリ名称である「CN=ichiro, SN=suzuki, OU=PEOPLE, O=XYZ, C=jp」は、固有エントリのエントリ名称を示している。
【００５２】
次に、図１１を用いて、本実施形態によるディレクトリ同期方法に用いる同期内容テーブル１０のデータ構造について説明する。
同期内容テーブル１０は、アプリケーションデータ１３に対する更新内容を記憶するものである。同期内容テーブル１０は、配列構造をなし、アプリケーションデータ１３に対する更新内容を複数格納可能である。
【００５３】
同期内容テーブル１０は、同期内容番号の記憶領域８０と、更新種別の記憶領域８１と、更新内容の記憶領域８２とから構成されている。
同期内容テーブル１０の情報例８３に示すように、例えば、更新種別８１である「add」は、更新内容が追加(add)であることを示している。更新種別としては、他に、変更や削除がある。更新内容８２である「table:USER userId:98001 name:ichirosuzuki serverName:Server1」は、サーバ名がServer1のユーザテーブル(USER)のユーザＩＤが９８００１に、ichirosuzukiの名前を追加することを示している。
【００５４】
次に、図１２〜図２３を用いて、本実施形態によるディレクトリ同期方法の動作について説明する。
最初に、図１２を用いて、本実施形態によるディレクトリ同期方法における更新履歴取得部３の処理内容について説明する。
【００５５】
更新履歴取得部３は、更新履歴の取得に関わる動作を定期的に実行する。
最初に、ステップＳ９０１において、更新履歴取得部３は、図８に示した更新履歴情報８の中の更新履歴番号記憶領域５０の取得済更新履歴番号５１を参照する。
【００５６】
次に、ステップＳ９０２において、更新履歴取得部３は、ディレクトリサーバ１が出力した更新履歴の内、ステップＳ９０１で取得した取得済更新履歴番号５１より大きい更新履歴番号を持つ更新履歴を全て取得する。例えば、取得済更新履歴番号５１が「１２４４」であったとすると、更新履歴番号が「１２４４」までの更新履歴が更新済みであるので、取得済更新履歴番号が「１２４５」以降の更新履歴（例えば、図７に示した更新履歴テーブル１１０の情報例１１５以降の更新履歴）を、更新履歴テーブル１１０から取得する。
【００５７】
そして、ステップＳ９０３において、更新履歴取得部３は、それら更新履歴の情報を、図８に示した取得済更新履歴テーブル５２に、情報例５７のように登録する。
最後に、ステップＳ９０４において、更新履歴取得部３は、ステップＳ９０２で取得した更新履歴の内、最後に取得した更新履歴の更新履歴番号を、更新履歴番号記憶領域５０の取得済更新履歴番号５１に登録する。
【００５８】
以上で、更新履歴取得部３の処理を終了して、ステップＳ９０５では、その後、スキーマ変換部４のスキーマ変換処理に移行する。スキーマ変換処理の詳細については、図１３を用いて説明する。
【００５９】
次に、図１３を用いて、本実施形態によるディレクトリ同期方法におけるスキーマ変換部４の処理内容について説明する。
最初に、ステップＳ１００１において、スキーマ変換部４は、図８に示した更新履歴情報８の中の取得済更新履歴テーブル５２の先頭レコードに登録されたディレクトリデータ１１に対する更新に関して、更新種別決定部１８の更新種別決定処理を実行する。更新種別決定処理の詳細については、図１４及び図１５を用いて後述する。
【００６０】
次に、ステップＳ１００２において、スキーマ変換部４は、アプリケーションデータ１３への更新内容を決定するため、属性マッピング処理を実行する。属性マッピング処理の詳細については、図１６〜図１８を用いて後述する。
【００６１】
次に、ステップＳ１００３において、スナップショット逐次更新部１７は、スナップショットの逐次更新処理を実行する。スナップショットの更新処理の詳細については、図１９〜図２２を用いて後述する。
【００６２】
次に、ステップＳ１００４において、スキーマ変換部４は、アプリケーションデータ１３に対する更新が不要と判断されたか否かを確認し、更新が不要ならば、ステップＳ１００６以降の処理へ移行し、更新が必要ならば、ステップＳ１００５を実行する。
【００６３】
更新が必要な場合には、ステップＳ１００５において、スキーマ変換部４は、図１１に示した同期内容テーブル１０に新規レコードを登録する。新規レコードの同期内容番号７０，更新種別７１及び更新内容７２には、それぞれ、現在処理中である取得済更新履歴テーブル５２のレコードの更新履歴番号５３，ステップＳ１００１で決定した更新種別及びステップＳ１００２で決定した更新内容を登録する。
【００６４】
次に、ステップＳ１００６において、スキーマ変換部４は、取得済更新履歴テーブル５２の全レコードに対して上述した処理を実行したか否かを判断する。実行していない場合には、ステップＳ１００７において、スキーマ変換部４は、取得済更新履歴テーブル５２から次履歴を取得し、ステップＳ１００１〜Ｓ１００５を繰り返し実行する。
【００６５】
また、全履歴の処理が終了すると、ステップＳ１００８において、スキーマ変換部４は、図８に示した取得済更新履歴テーブル５２を削除する。そして、スキーマ変換処理が終了すると、ステップＳ１００９において、アプリケーションデータ更新部５のアプリケーションデータ更新処理へ移行する。アプリケーションデータ更新処理の詳細については、図２３を用いて後述する。
【００６６】
ここで、図１４及び図１５を用いて、本実施形態によるディレクトリ同期方法における更新種別決定部１８の処理内容について説明する。
更新種別決定処理では、更新の対象となったディレクトリエントリが、更新が実行される前と更新が実行された後に関して、アプリケーションデータ１３への同期条件を満足するか否かを、スナップショット９を用いて調べ、その結果からアプリケーションデータ１３への更新種別を決定する。
ここで、「同期条件」とは、更新対象のエントリがフィルタリング規則テーブル６に登録されたフィルタリング規則のいずれかに適合し、かつ、そのエントリが共通エントリの場合は固有エントリとリンクしており、そのエントリが固有エントリの場合は共通エントリとリンクしているという条件のことである。
【００６７】
最初に、ステップＳ１１０１〜Ｓ１１０５において、更新種別決定部１８は、更新対象のディレクトリエントリが更新前に同期条件を満足していたか否かの判定を行なう。
即ち、ステップＳ１１０１において、更新種別決定部１８は、図８に示した取得済更新履歴テーブル５２の更新種別５５のデータにより、ディレクトリデータ１１に対する更新種別が追加か否かを確認する。追加の場合、追加される以前に更新対象のエントリは存在しておらず、同期条件を満足していなかったのは自明であるため、ステップＳ１１０６以降の処理に移行する。
【００６８】
追加以外の変更や削除の場合は、ステップＳ１１０２において、更新種別決定部１８は、図８に示した取得済更新履歴テーブル５２の対象エントリ名称５４と、図９に示したスナップショット９のエントリ名称６１が一致するという条件でスナップショット９を検索し、合致するレコードのスナップショット９のエントリ内容６２を取得する。これは、更新対象のエントリの更新前のエントリ内容である。
【００６９】
次に、ステップＳ１１０３において、更新種別決定部１８は、図４に示したフィルタリング規則テーブル６に登録されたレコードを順に参照し、ベースエントリ名称９１とスコープ９２で特定されたディレクトリツリー内に更新対象のエントリが存在し、かつ、ステップＳ１１０２で取得したエントリ内容がフィルタ条件９３を満たすか否か調べることで、適合するフィルタリング規則を検索する。例えば、図４に示したベースエントリ名称９１の情報例９５は、「OU=PEOPLE,O=XYZ,C=JP」であり、スコープ９２の情報例９５は、「subtree」であるので、図８に示した取得済更新履歴テーブル５２の対象エントリ名称５４の情報例５７では、更新対象のエントリが存在しないことになる。また、ベースエントリ名称９１が、「OU=APP1,O=XYZ,C=JP」であり、スコープ９２の情報例９５が、「subtree」であるならば、図８に示した取得済更新履歴テーブル５２の対象エントリ名称５４の情報例５７は、「UID=98001, OU=USR, OU=APP1, O=XYZ, C=JP」であるため、ベースエントリ以下のsubtreeにおいて更新対象のエントリが存在することになる。そして、ステップＳ１１０２で取得したエントリ内容６２がフィルタ条件を満たすかどうか調べる。
【００７０】
適合するフィルタリング規則が存在しない場合、更新種別決定部１８は、更新前は同期条件を満足しなかったと判断し、ステップＳ１１０６以降の処理に移行する。
また、適合するフィルタリング規則が存在した場合、更新種別決定部１８は、そのフィルタリング規則のエントリ種別９４を参照し、値が「０」である場合は前記ディレクトリエントリは共通エントリであると判断し、値が「１」である場合は固有エントリであると判断する。
【００７１】
次に、ステップＳ１１０５において、更新種別決定部１８は、更新対象のエントリとリンクするエントリが、更新前に存在したか否かの確認処理を行なう。存在した場合、更新前は同期条件を満足したと判断し、存在しなかった場合、更新前は同期条件を満足しなかったと判断する。
【００７２】
ここで、図１５を用いて、リンク先エントリの存在確認処理の内容について説明する。
リンク先エントリの存在確認処理は、更新対象のディレクトリエントリとリンクするエントリの存在確認をする処理であり、或る更新が実行される前の確認処理（図１４のステップＳ１１０５）と、実行された後の確認処理（図１４のステップＳ１１１３）がある。
【００７３】
最初に、ステップＳ１２０１において、更新種別決定部１８は、図１４のステップＳ１１０４或いはステップＳ１１１２の処理で取得したエントリ種別が共通エントリか固有エントリで処理を分岐する。固有エントリの場合は、ステップＳ１２０２に進み、共通エントリの場合には、ステップＳ１２０８に進む。
【００７４】
固有エントリの場合、ステップＳ１２０２において、更新種別決定部１８は、図１４のステップＳ１１０２の処理で取得した更新前のエントリ内容、或いはステップＳ１１０７〜Ｓ１１１０の処理で取得した更新後のエントリ内容が、リンクを格納する属性を含むか否かを調べる。リンクを格納する属性を含む場合とは、図９に示したスナップショット９のエントリ内容６２の中に、情報例６３に示すように、「seeAlso」の文を含む場合である。含む場合には、ステップＳ１２０３に進み、含まない場合には、ステップＳ１２０７に進む。
【００７５】
含む場合、ステップＳ１２０３において、更新種別決定部１８は、リンク先の共通エントリの存在確認のため、スナップショット９を、リンクを格納する属性の値とエントリ名称６１が一致するという条件で検索する。ここで、リンクを格納する属性の値とは、例えば、「sn=鈴木」である。
そして、ステップＳ１２０４において、更新種別決定部１８は、合致するレコードが存在するか否か調べる。存在する場合には、ステップＳ１２０５に進み、存在しない場合には、ステップＳ１２０７に進む。
【００７６】
存在した場合、ステップＳ１２０５において、更新種別決定部１８は、リンク先エントリが存在したと判断する。
次に、ステップＳ１２０６において、更新種別決定部１８は、合致したレコードを、スナップショット９から取得する。
【００７７】
ステップＳ１２０２の判断で、リンクが存在しない場合、また、ステップＳ１２０４の判断で、レコードが存在しない場合、ステップＳ１２０７において、更新種別決定部１８は、リンク先エントリはしないと判断する。
【００７８】
更新対象のエントリが共通エントリの場合、ステップＳ１２０８において、更新種別決定部１８は、リンクインデックス７０を、そのエントリの名称とエントリ名称７１が一致するという条件で検索する。
そして、ステップＳ１２０９において、更新種別決定部１８は、合致するレコードが存在するか否か調べる。存在する場合には、ステップＳ１２１０に進み、存在しない場合には、ステップＳ１２１３に進む。
【００７９】
存在した場合、ステップＳ１２１０において、更新種別決定部１８は、リンク先エントリが存在したと判断する。
そして、ステップＳ１２１１において、更新種別決定部１８は、スナップショット９を、合致したレコードのレコード番号７２とレコード番号６０が一致するという条件で検索する。
次に、ステップＳ１２１２において、更新種別決定部１８は、合致したレコードをスナップショット９から取得する。
【００８０】
一方、ステップＳ１２０９の判断において、合致するレコードが存在しなかった場合、ステップＳ１２１３において、更新種別決定部１８は、リンク先エントリは存在しなかったと判断する。
【００８１】
ここで、図１４に戻り、ステップＳ１１０６〜Ｓ１１１３において、更新種別決定部１８は、更新対象のディレクトリエントリが更新後に同期条件を満足するか否かの判定を行なう。
最初に、ステップＳ１１０６及びＳ１１０７において、更新種別決定部１８は、ディレクトリデータ１１への更新種別により処理を分岐する。即ち、更新種別が削除の場合には、削除された後ディレクトリエントリは存在せず、同期条件を満足しないのは自明であるため、ステップＳ１１１４に進み、更新種別が変更の場合には、ステップＳ１１０８に進み、更新種別が追加の場合には、ステップＳ１１１０に進む。
【００８２】
また、更新種別が変更ならば、ステップＳ１１０８において、更新種別決定部１８は、更新対象のエントリの名称とエントリ名称６１が一致するという条件でスナップショット９を検索し、合致するレコードのエントリ内容６２を取得する。
次に、ＳステップＳ１１０９において、更新種別決定部１８は、ステップＳ１１０８で取得したエントリ内容に、現在処理中の更新履歴レコードの更新内容５６を反映させ、更新後のエントリ内容を得る。即ち、図９に示したスナップショット９のエントリ内容６２に、図８に示した取得済更新履歴テーブル５２の更新内容５６を入れる。
【００８３】
さらに、更新種別が追加ならば、ステップＳ１１１０において、更新種別決定部１８は、更新後のエントリ内容は、現在処理中の更新履歴レコードの更新内容５６と同一であるとする。
【００８４】
次に、ステップＳ１１１１において、更新種別決定部１８は、フィルタリング規則テーブル６に登録されたレコードを順に参照し、ベースエントリ名称９１とスコープ９２で特定されたディレクトリツリー内に前記ディレクトリエントリが存在し、かつ、ステップＳ１１０９或いはステップＳ１１１０で取得した更新後のエントリ内容がフィルタ条件９３を満たすか否か調べる。適合するフィルタリング規則が存在する場合には、ステップＳ１１１２に進み、適合するフィルタリング規則が存在しない場合には、更新後は同期条件を満足しないと判断し、ステップＳ１１１４に進む。
【００８５】
適合するフィルタリング規則が存在する場合、ステップＳ１１１２において、更新種別決定部１８は、フィルタリング規則のエントリ種別９４を参照し、値が０である場合は前記ディレクトリエントリは共通エントリであると判断し、値が１である場合は固有エントリであると判断する。
その後、ステップＳ１１１３において、更新種別決定部１８は、更新後に前記ディレクトリエントリとリンクするエントリが存在するか否かの確認処理を行なう。リンク先のエントリの存在確認処理は、図１５に示したとおりである。存在する場合、更新後は同期条件を満足すると判断し、存在しない場合、更新後は同期条件を満足しないと判断する。
【００８６】
最後に、ステップＳ１１１４において、更新種別決定部１８は、以上の処理の結果からアプリケーションデータ１３への更新種別を決定する。すなわち、更新前に同期条件を満足せず、更新後に同期条件を満足する状態へ移行した場合は更新種別は「追加」である。更新前に同期条件を満足し、更新後に同期条件を満足しない状態へ移行した場合は更新種別は「削除」である。更新前後共に同期条件を満足する場合は更新種別は「変更」である。更新前後共に同期条件を満足しない場合はアプリケーションデータ１３へは更新を行なわない。このようにして、共有エントリと固有エントリの同期をとり、同期条件を満たさない場合には、更新を行わないようにすることにより、不整合が発生することを防止できる。
【００８７】
次に、図１６〜図１８を用いて、本実施形態によるディレクトリ同期方法における属性マッピング処理の内容について説明する。
属性マッピング処理は、図１３に示したスキーマ処理の中のステップＳ１００２における処理である。
【００８８】
最初に、図１６を用いて、属性マッピング処理の全体的な処理内容について説明する。
最初に、ステップＳ１３０１及びＳ１３０２において、スキーマ変換部４は、図１４のＳ１１１４で決定したアプリケーションデータ１３に対する更新種別により処理を分岐する。
【００８９】
まず、アプリケーションデータ１３に対する更新を行なわない場合は、何も行なう必要はないため、属性マッピング処理を終了する。
更新種別が削除の場合には、ステップＳ１３０３において、スキーマ変換部４は、削除に関する属性マッピング処理を実行する。削除に関する属性マッピング処理の詳細については、図１７を用いて後述する。
更新種別が追加及び変更の場合には、ステップＳ１３０４において、スキーマ変換部４は、追加，変更に関する属性マッピング処理を実行する。追加，変更に関する属性マッピング処理の詳細については、図１８を用いて後述する。
【００９０】
次に、図１７を用いて、削除に関する属性マッピング処理の処理内容について説明する。
最初に、ステップＳ１４０１において、スキーマ変換部４は、更新対象のディレクトリエントリに適用するスキーマ変換規則を決定する。そのために、図１４のステップＳ１１０４で取得したエントリ種別により処理を分岐する。更新対象のエントリが共通エントリである場合には、ステップＳ１４０２に進み、更新対象のエントリが固有エントリである場合、ステップＳ１４０４に進む。
【００９１】
更新対象のエントリが共通エントリである場合、ステップＳ１４０２において、スキーマ変換部４は、図１４のステップＳ１１０２で取得したエントリ内容から、オブジェクトクラスを格納するobjectclass属性を取り出す。例えば、図９に示した例では、スナップショット９のエントリ内容６２から、情報例６３に示すobjectclass属性である「app1Person」を取り出す。
次に、ステップＳ１４０３において、スキーマ変換部４は、図１５のＳ１２１２で取得したリンク先の固有エントリのエントリ内容からも、objectclass属性を取り出す。
【００９２】
また、更新対象のディレクトリエントリが固有エントリである場合、ステップＳ１４０４において、スキーマ変換部４は、図１４のＳ１１０２で取得したエントリ内容から、オブジェクトクラスを格納するobjectclass属性を取り出す。
次に、ステップＳ１４０５において、スキーマ変換部４は、図１５のＳ１２０６で取得したリンク先の共通エントリのエントリ内容からも、objectclass属性を取り出す。
【００９３】
次に、適用するスキーマ変換規則を決定する。まず、ステップＳ１４０６において、スキーマ変換部４は、スキーマ変換規則テーブル７の先頭レコードを参照し、共通エントリの対象クラス１０１が、ステップＳ１４０２、或いはＳ１４０５の処理で取得した共通エントリのobjectclass属性に含まれ、かつ、固有エントリの対象クラス１０３が、ステップＳ１４０３、或いはＳ１４０４の処理で取得した固有エントリのobjectclass属性に含まれるか否か調べる。含まれる場合には、ステップＳ１４０８に進み、含まれない場合には、ステップＳ１４０７に進み、ステップＳ１４０７において、スキーマ変換部４は、次の規則を参照し、同様の処理を繰り返す。
【００９４】
含まれる場合、ステップＳ１４０８において、スキーマ変換部４は、そのスキーマ変換規則の識別子格納属性名称１０５を取得する。
次に、ステップＳ１４０９において、スキーマ変換部４は、図１４のステップＳ１１０４で取得したエントリ種別により、処理を分岐する。即ち、エントリ種別が共通エントリの場合には、ステップＳ１４１０に進み、固有エントリの場合には、ステップＳ１４１１に進む。そして、ステップＳ１４１０若しくは、ステップＳ１４１１において、固有エントリに格納されているアプリケーションデータ１３内の削除すべきエントリを一意に特定する識別子を取得する。
【００９５】
更新対象のディレクトリエントリが共通エントリである場合、ステップＳ１４１０において、スキーマ変換部４は、図１５のステップＳ１２１２で取得したリンク先固有エントリのエントリ内容から、ステップＳ１４０８で取得した名称を持つ属性（アプリケーションデータ１３の識別子を格納する属性）を取り出す。例えば、図５に示したように、スキーマ変換規則テーブル７の識別子格納属性名称１０５が、情報例１０６に示すように、「uid」である場合、図９に示したスナップショット９のエントリ内容６２から、情報例６３に示す例の場合には、ユーザＩＤ（uid）として、「98001」を取り出す。
【００９６】
また、ディレクトリエントリが固有エントリである場合、ステップＳ１４１１において、スキーマ変換部４は、図１４のステップＳ１１０２で取得した更新対象エントリのエントリ内容から、ステップＳ１４０８で取得した名称を持つ属性を取り出す。
そして、ステップＳ１４１２において、スキーマ変換部４は、ステップＳ１４１０、或いはＳ１４１１で取得した識別子を格納する属性が、アプリケーションデータ１３に対する更新内容とする。
【００９７】
次に、図１８を用いて、追加，変更に関する属性マッピング処理の処理内容について説明する。
最初に、ステップＳ１５０１において、スキーマ変換部４は、更新対象のディレクトリエントリに適用するスキーマ変換規則を決定する。そのために、図１４のステップＳ１１１２で取得したエントリ種別により処理を分岐する。更新対象のエントリが共通エントリである場合には、ステップＳ１５０２に進み、更新対象のエントリが固有エントリである場合、ステップＳ１５０４に進む。
【００９８】
更新対象のエントリが共通エントリである場合、ステップＳ１５０２において、スキーマ変換部４は、図１４のステップＳ１１０７で取得したエントリ内容から、オブジェクトクラスを格納するobjectclass属性を取り出す。
次に、ステップＳ１５０３において、スキーマ変換部４は、図１５のＳ１２１２で取得したリンク先の固有エントリのエントリ内容からも、objectclass属性を取り出す。
【００９９】
また、更新対象のディレクトリエントリが固有エントリである場合、ステップＳ１５０４において、スキーマ変換部４は、図１４のＳ１１１０で取得したエントリ内容から、オブジェクトクラスを格納するobjectclass属性を取り出す。
次に、ステップＳ１５０５において、スキーマ変換部４は、図１５のＳ１２０６で取得したリンク先の共通エントリのエントリ内容からも、objectclass属性を取り出す。
【０１００】
次に、適用するスキーマ変換規則を決定する。まず、ステップＳ１５０６において、スキーマ変換部４は、スキーマ変換規則テーブル７の先頭レコードを参照し、共通エントリの対象クラス１０１が、ステップＳ１５０２、或いはＳ１５０５の処理で取得した共通エントリのobjectclass属性に含まれ、かつ、固有エントリの対象クラス１０３が、ステップＳ１５０３、或いはＳ１５０４の処理で取得した固有エントリのobjectclass属性に含まれるか否か調べる。含まれる場合には、ステップＳ１５０８に進み、含まれない場合には、ステップＳ１５０７に進み、ステップＳ１５０７において、スキーマ変換部４は、次の規則を参照し、同様の処理を繰り返す。
【０１０１】
次に、ステップＳ１５０８において、スキーマ変換部４は、Ｓ１５０６で決定したスキーマ変換規則の共通エントリに対する属性変換規則１０２を参照し、共通エントリのエントリ内容に含まれる属性名をアプリケーションデータ１３の属性名に置換する。
例えば、図５に示したように、属性変換規則（共通）１０２として、情報例１０６に示すように、「cn,Name」とある場合には、共通エントリの属性名「cn:一郎」を、アプリケーションデータの属性名「Name:ichiro」に置換する。
次に、ステップＳ１５０９において、スキーマ変換部４は、属性名の置換がすべての属性について行われたか否かを判断し、行われていない場合には、ステップＳ１５１０において、スキーマ変換部４は、次の属性について、属性名の置換を行う。
【０１０２】
属性名の置換が、共通エントリのエントリ内容に含まれる全属性に対して行なわれると、ステップＳ１５１１において、スキーマ変換部４は、ステップＳ１５０６で決定したスキーマ変換規則の固有エントリに対する属性変換規則１０４を参照し、固有エントリのエントリ内容に含まれる属性名をアプリケーションデータ１３の属性名に置換する。
次に、ステップＳ１５１２において、スキーマ変換部４は、属性名の置換がすべての属性について行われたか否かを判断し、行われていない場合には、ステップＳ１５１３において、スキーマ変換部４は、次の属性について、属性名の置換を行う。
【０１０３】
属性名の置換が、固有エントリのエントリ内容に含まれる全属性に対して行なわれると、ステップＳ１５１４において、スキーマ変換部４は、ステップＳ１５０８〜Ｓ１５１０までの処理により決定したアプリケーションデータ１３の属性、及びステップＳ１５１１〜Ｓ１５１３までの処理により決定したアプリケーションデータ１３の属性を結合することにより、アプリケーションデータ１３に対する更新内容を得る。
【０１０４】
次に、図１９〜図２２を用いて、本実施形態によるディレクトリ同期方法におけるスナップショットの更新処理の内容について説明する。
スナップショットの更新処理は、図１３に示したスキーマ処理の中のステップＳ１００３における処理であり、スナップショット逐次更新部１７が行うものである。
【０１０５】
図１９に示すように、ステップＳ１６０１及びＳ１６０２において、スナップショット逐次更新部１７は、現在処理中の更新履歴の更新種別により処理を分岐する。即ち、追加の場合は、ステップＳ１６０３において追加処理を実行し、変更の場合は、ステップＳ１６０４において変更処理を実行し、削除の場合は、ステップＳ１６０５において削除処理を実行する。それぞれの処理の詳細については、図２０〜図２２を用いて説明する。
【０１０６】
最初に、図２０を用いて、スナップショット９のレコード追加処理の内容について説明する。
ステップＳ１７０１において、スナップショット逐次更新部１７は、スナップショット９に新規レコードを登録する。この時、レコード番号６０には、他のレコードと重複しない値を登録する。例えば、レコードを登録する毎に１ずつ加算した値を割り当てるようにする。エントリ名称６１には、更新対象のディレクトリエントリの名称を登録する。例えば、エントリ名称６１には、図８に示した取得済更新履歴テーブル５２の対象エントリ名称５４の情報例５７の「UID=98001, OU=USR, OU=APP1, O=XYZ, C=JP」を登録する。また、エントリ内容６２には、図１４のステップＳ１１０９、或いはＳ１１１０の処理により取得した更新後のエントリ内容を登録する。例えば、図８に示した取得済更新履歴テーブル５２の更新内容５６の情報例５７である「objectclass:appPerson uid:98001 appServerName:Server1」を登録する。
【０１０７】
次に、ステップＳ１７０２において、スナップショット逐次更新部１７は、ステップＳ１１１２の処理により取得したエントリ種別により処理を分岐する。即ち、更新対象のディレクトリエントリが共通エントリの場合、リンクを格納する属性は持たないため、レコード追加処理を終了する。固有エントリの場合、ステップＳ１７０３に進む。
【０１０８】
そして、ステップＳ１７０３において、スナップショット逐次更新部１７は、更新後のエントリ内容を参照して、リンクを格納する属性が含まれるか否か調べる。含まれる場合には、ステップＳ１７０４に進み、含まれない場合には、レコード追加処理を終了する。
【０１０９】
次に、含まれる場合、ステップＳ１７０４において、スナップショット逐次更新部１７は、リンクインデックス７０に、新規レコードを登録する。この時、リンク先エントリ名称７１には、前記属性の値を登録する。レコード番号７２は、Ｓ１７０１で登録したスナップショットの新規レコードのレコード番号６０と同一の値を登録する。
【０１１０】
次に、図２１を用いて、スナップショット９のレコード変更処理の内容について説明する。
最初に、ステップＳ１８０１において、スナップショット逐次更新部１７は、図１４のステップＳ１１０８の処理で実行したスナップショット９の検索において、検索条件に合致したレコードのエントリ内容６２を変更する。この時、検索条件に合致したレコードのエントリ内容６２を、図１４のＳ１１０９の処理により取得した更新後のエントリ内容で上書きする。
【０１１１】
次に、ステップＳ１８０２において、スナップショット逐次更新部１７は、図１４のＳ１１１２の処理により取得したエントリ種別により処理を分岐する。即ち、更新対象のディレクトリエントリが共通エントリの場合、リンクを格納する属性は持たないため、レコード変更処理を終了する。固有エントリの場合には、ステップＳ１８０３に進む。
【０１１２】
固有エントリの場合、ステップＳ１８０３〜Ｓ１８０５において、スナップショット逐次更新部１７は、変更履歴テーブル５２の現在処理中であるレコードの更新内容５６を参照して、共通エントリに対するリンクを格納する属性が更新されたか否か調べる。そして、更新種別によって処理が分岐し、リンクを格納する属性の追加の場合には、ステップＳ１８０６に進み、リンクを格納する属性の削除の場合には、ステップＳ１８０７に進み、リンクを格納する属性の変更の場合には、ステップＳ１８０８に進む。
【０１１３】
リンクを格納する属性が追加された場合には、ステップＳ１８０６において、スナップショット逐次更新部１７は、リンクインデックス７０に、新規レコードを登録する。この時、リンク先エントリ名称７１には、前記属性の値を登録する。レコード番号７２は、ステップＳ１８０１の処理で変更したスナップショット９のレコードのレコード番号６０と同一の値を登録する。
【０１１４】
リンクを格納する属性が削除された場合には、ステップＳ１８０７において、スナップショット逐次更新部１７は、リンクインデックス７０からレコードを削除する。すなわち、まず、図１４のＳ１１０２の処理により取得したエントリ内容６２からリンクを格納する属性を取り出す。次に、リンクインデックス７０を、前記属性の値とエントリ名称７１が一致するという条件で検索し、合致するレコードを削除する。
【０１１５】
リンクを格納する属性が変更された場合には、ステップＳ１８０８において、スナップショット逐次更新部１７は、リンクインデックス７０からレコードを削除し、新規レコードを追加する。すなわち、まず、図１４のステップＳ１１０２で取得したエントリ内容６２からリンクを格納する属性の値を取り出す。次に、リンクインデックス７０を、前記属性の値とエントリ名称７１が一致するという条件で検索し、合致するレコードを削除する。その後、新規レコードを登録する。この時、エントリ名称７１には、図１４のステップＳ１１０９の処理により取得した更新後のエントリ内容からリンクを格納する属性を取り出し、その属性の値を登録する。レコード番号７２は、Ｓ１８０１で変更したスナップショット９のレコードのレコード番号６０と同一の値を登録する。
【０１１６】
次に、図２２を用いて、スナップショット９のレコード削除処理の内容について説明する。
最初に、ステップＳ１９０１において、スナップショット逐次更新部１７は、図１４のステップＳ１１０４の処理により取得したエントリ種別により処理を分岐する。更新対象のディレクトリエントリが共通エントリの場合には、リンクを格納する属性は持たないため、ステップＳ１９０４に進む。また、固有エントリの場合には、ステップＳ１９０２に進む。
【０１１７】
固有エントリの場合には、ステップＳ１９０２において、スナップショット逐次更新部１７は、図１４のＳ１１０２の処理により取得したスナップショット９のエントリ内容６２に、図３のリンク４５を格納する属性が含まれるか否か調べる。含まれる場合には、ステップＳ１９０３に進み、含まれない場合には、ステップＳ１９０４に進む。
【０１１８】
リンクを格納する属性が含まれる場合には、ステップＳ１９０３において、スナップショット逐次更新部１７は、リンクインデックス７０を、前記属性の値とエントリ名称７１が一致するという条件で検索し、合致するレコードを削除する。
最後に、ステップＳ１９０４において、スナップショット逐次更新部１７は、図１４のステップＳ１１０２の処理により取得した、スナップショット９のレコードを削除する。
【０１１９】
次に、図２３を用いて、本実施形態によるディレクトリ同期方法におけるアプリケーションデータの更新処理の内容について説明する。
アプリケーションデータの更新処理は、アプリケーションデータ更新部５によって実行される。
【０１２０】
最初に、ステップＳ２００１において、アプリケーションデータ更新部５は、同期内容テーブル１０の先頭レコードを取得する。
【０１２１】
次に、ステップＳ２００２において、アプリケーションデータ更新部５は、前記レコードの更新内容８２に従って、アプリケーションデータ１３を更新する。
【０１２２】
次に、ステップＳ２００３において、アプリケーションデータ更新部５は、すべての更新内容に処理が実行されたか否かを判断し、実行されていない場合には、ステップＳ２００４に進んで、次の同期内容レコードを取り出し、ステップＳ２００１及びＳ２００２を実行して、同期内容テーブル１０の全レコードに対して実行する。
全ての同期内容レコードについて処理が実行されると、ステップＳ２００５において、アプリケーションデータ更新部５は、同期内容レコード１０の全レコードを削除する。
【０１２３】
なお、以上の説明では、ディレクトリ同期サーバ２を用いて、本実施形態によるディレクトリ同期方法を実現しているが、ディレクトリサーバ１を用いて、本実施形態によるディレクトリ同期方法を実現するようにしてもよいものである。そのためには、図１に示した更新履歴取得部３，スキーマ変換部４，更新種別決定部１８，スナップショット逐次更新部１７，アプリケーションデータ更新部５や、各テーブル６，７，８、９，１０を、ディレクトリサーバ１内に備えるようにすればよいものである。
【０１２４】
以上説明したように、本実施形態によれば、ディレクトリサーバが出力する更新履歴を定期的に取得し、その更新履歴に基づき作成されるディレクトリデータのスナップショットと更新履歴からアプリケーションデータに対して行うべき更新内容を取得し、アプリケーションデータを更新することで、従来はディレクトリサーバの検索を要するためディレクトリエントリ数増大に従って所要時間が増大したディレクトリ同期処理を、ディレクトリエントリ数に関わらず一定の時間で実行することが可能となる。
即ち、従来は、更新時に全スナップショットを作成していたので、ディレクトリエントリ数増大に従ってスナップショット作成時間が増大するのに対して、本実施形態においては、更新履歴を取得する毎に、スナップショットを作成しているので、更新時のスナップショット作成が不要となるため、ディレクトリエントリ数が増大しても、更新所要時間が増大することはないものである。
【０１２５】
また、本実施形態によれば、ディレクトリサービスに対する更新を禁止する期間を無くしディレクトリサービスの可用性を向上することが可能である。
即ち、従来は、スナップショットを取得している間はディレクトリサービスに対する更新を禁止しなければならないため、更新を禁止する期間を設ける必要があったのに対して、本実施形態においては、更新履歴情報に基づいて更新を行っており、更新の途中に新たな更新情報が追加されたとしても、新たな更新情報について更新は次回に行うため、更新を禁止する期間を設ける必要はないものである。
【０１２６】
さらに、従来は同期処理を行う間隔を短くしたとしても、スナップショットを取得している間は必ずディレクトリデータとアプリケーションデータが不整合状態となったが、本実施形態によれば、更新履歴を取得する間隔を短くすることにより、ディレクトリデータとアプリケーションデータの間に不整合が発生する期間をより短くすることができる。
即ち、図１４のステップＳ１１１４の判断で同期条件を満たさないこととなるため、同期条件を満たさない場合には、更新を行わないようにすることにより、不整合が発生することを防止できる。
【０１２７】
【発明の効果】
本発明によれば、ディレクトリサービスに登録されるディレクトリエントリの数が増加した場合も、ディレクトリサービスとアプリケーションの同期に要する時間を一定に保つことができる。
【図面の簡単な説明】
【図１】本発明の一実施形態によるディレクトリ同期方法を実行するディレクトリ同期システムのシステム構成図である。
【図２】本発明の一実施形態によるディレクトリ同期方法を実行するディレクトリシステムを構成するディレクトリサーバ，アプリケーションサーバ及びディレクトリ同期サーバのシステム構成について説明する。
【図３】本発明の一実施形態によるディレクトリ同期方法に用いるディレクトリデータの論理構造の説明図である。
【図４】本発明の一実施形態によるディレクトリ同期方法に用いるフィルタリング規則テーブルのデータ構造の説明図である。
【図５】本発明の一実施形態によるディレクトリ同期方法に用いるスキーマ変換規則テーブルのデータ構造の説明図である。
【図６】本発明の一実施形態によるディレクトリ同期方法に用いるスキーマ変換テーブルの属性変換規則のデータ構造の説明図である。
【図７】本発明の一実施形態によるディレクトリ同期方法に用いる更新履歴記憶領域のデータ構造の説明図である。
【図８】本発明の一実施形態によるディレクトリ同期方法に用いる更新履歴情報のデータ構造の説明図である。
【図９】本発明の一実施形態によるディレクトリ同期方法に用いるスナップショットのデータ構造の説明図である。
【図１０】本発明の一実施形態によるディレクトリ同期方法に用いるリンクインデックスのデータ構造の説明図である。
【図１１】本発明の一実施形態によるディレクトリ同期方法に用いる同期内容テーブルのデータ構造の説明図である。
【図１２】本発明の一実施形態によるディレクトリ同期方法における更新履歴取得部の処理内容を示すフローチャートである。
【図１３】本発明の一実施形態によるディレクトリ同期方法におけるスキーマ変換部の処理内容を示すフローチャートである。
【図１４】本発明の一実施形態によるディレクトリ同期方法における更新種別決定部の処理内容を示すフローチャートである。
【図１５】本発明の一実施形態によるディレクトリ同期方法における更新種別決定部の処理内容を示すフローチャートである。
【図１６】本発明の一実施形態によるディレクトリ同期方法における属性マッピング処理の全体的な処理内容を示すフローチャートである。
【図１７】本発明の一実施形態によるディレクトリ同期方法における属性マッピング処理の中の削除時のマッピング処理容を示すフローチャートである。
【図１８】本発明の一実施形態によるディレクトリ同期方法における属性マッピング処理の中の追加，変更時のマッピング処理内容を示すフローチャートである。
【図１９】本発明の一実施形態によるディレクトリ同期方法におけるスナップショットの更新処理の全体的な処理内容を示すフローチャートである。
【図２０】本発明の一実施形態によるディレクトリ同期方法におけるスナップショットの更新処理の中の削除処理の内容を示すフローチャートである。
【図２１】本発明の一実施形態によるディレクトリ同期方法におけるスナップショットの更新処理の中の変更処理の内容を示すフローチャートである。
【図２２】本発明の一実施形態によるディレクトリ同期方法におけるスナップショットの更新処理の中の追加処理の内容を示すフローチャートである。
【図２３】本発明の一実施形態によるディレクトリ同期方法におけるアプリケーションデータの更新処理の全体的な処理内容を示すフローチャートである。
【符号の説明】
１…ディレクトリサーバ
２…ディレクトリ同期サーバ
３…更新履歴取得部
４…スキーマ変換部
５…アプリケーションデータ更新部
６…フィルタリング規則テーブル
７…スキーマ変換規則テーブル
８…更新履歴情報
９…スナップショット
１０…同期内容テーブル
１１…ディレクトリデータ
１２…アプリケーションサーバ
１３…アプリケーションデータ
１４，１５…ＤＢ
１６…更新履歴記憶領域
１７…スナップショット逐次更新部
１８…更新種別決定部
Claims (5)
- ディレクトリサーバに記憶されたディレクトリデータと、このディレクトリサーバにネットワークを介して接続された少なくとも１つ以上のアプリケーションサーバに記憶されたアプリケーションデータとの同期を行なうディレクトリ同期方法において、
Ａ）上記ディレクトリデータに対して行った更新履歴を定期的に取得し、
Ｂ）この取得した更新履歴を順に参照し、ディレクトリデータのスナップショットを逐次更新し、
Ｃ）更新履歴の内容と、スナップショットの情報に従い、上記アプリケーションサーバへの更新種別を決定し、
Ｄ）更新履歴の内容をアプリケーションサーバへの更新へ変換し、
Ｅ）このアプリケーションサーバへの更新内容を基にアプリケーションサーバの更新を実行することを特徴とするディレクトリ同期方法。 - 請求項１記載のディレクトリ同期方法において、
上記アプリケーションサーバが管理する情報を、アプリケーションに依存しない共通情報と、アプリケーション固有の固有情報に分類し、それら２種類の情報を上記ディレクトリサーバ内の異なるエントリに格納し、かつ、それらのエントリ間にリンクを設定することを特徴とするディレクトリ同期方法。 - 請求項２記載のディレクトリ同期方法において、
上記定期的に取得された更新履歴中の更新に関して、その更新をスナップショットに反映する前後で、その更新の対象となるユーザ情報を分割して格納している２エントリが存在し、かつ、それらエントリ間にリンクが存在するか否かを調べ、
反映前は存在せず、反映後に存在する場合は、アプリケーションデータに対する更新種別を追加と決定し、
逆に反映前は存在し、反映後に存在しない場合は、アプリケーションデータに対する更新種別を追加と決定し、
反映の前後共に存在する場合は、アプリケーションデータに対する更新種別を変更と決定し、
反映の前後共に存在しない場合は、更新を行わないことを特徴とするディレクトリ同期方法。 - 請求項１記載のディレクトリ同期方法において、
アプリケーションデータとの同期を要するディレクトリデータを選別するフィルタリング規則に適合しないディレクトリデータに関してはディレクトリサーバ上に存在しないものと見なし、
このフィルタリング規則に適合するディレクトリデータに関してのみ更新種別を決定することを特徴とするディレクトリ同期方法。 - 請求項１記載のディレクトリ同期方法において、
アプリケーションデータに対する更新種別の削除に対しては、スナップショットからアプリケーションデータの識別子を取得し、アプリケーションデータから削除すべきユーザ情報を特定することを特徴とするディレクトリ同期方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP08366099A JP3810577B2 (ja) | 1999-03-26 | 1999-03-26 | ディレクトリ同期方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP08366099A JP3810577B2 (ja) | 1999-03-26 | 1999-03-26 | ディレクトリ同期方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2000276391A JP2000276391A (ja) | 2000-10-06 |
| JP3810577B2 true JP3810577B2 (ja) | 2006-08-16 |
Family
ID=13808620
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP08366099A Expired - Fee Related JP3810577B2 (ja) | 1999-03-26 | 1999-03-26 | ディレクトリ同期方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3810577B2 (ja) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107171825A (zh) * | 2017-04-11 | 2017-09-15 | 捷开通讯(深圳)有限公司 | 一种终端的重复日志过滤方法 |
Families Citing this family (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4325524B2 (ja) | 2004-09-29 | 2009-09-02 | 日本電気株式会社 | スイッチ装置とシステム並びにバックアップ及びリストア方法とプログラム |
| JP4699516B2 (ja) * | 2006-03-28 | 2011-06-15 | 富士通株式会社 | 名前空間複製プログラム、名前空間複製装置、名前空間複製方法 |
| JP2008040699A (ja) * | 2006-08-04 | 2008-02-21 | Fujitsu Ltd | Ｈｓｍ制御プログラム、ｈｓｍ制御装置、ｈｓｍ制御方法 |
| US8918380B2 (en) | 2009-07-09 | 2014-12-23 | Norsync Technology As | Methods, systems and devices for performing incremental updates of partial databases |
| JP5422364B2 (ja) * | 2009-12-17 | 2014-02-19 | 株式会社日立システムズ | ファイル管理システム |
| JP2012146083A (ja) * | 2011-01-11 | 2012-08-02 | Fujitsu Ltd | セッション管理システム、セッション管理装置、サーバ装置およびセッション管理方法 |
-
1999
- 1999-03-26 JP JP08366099A patent/JP3810577B2/ja not_active Expired - Fee Related
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107171825A (zh) * | 2017-04-11 | 2017-09-15 | 捷开通讯(深圳)有限公司 | 一种终端的重复日志过滤方法 |
| CN107171825B (zh) * | 2017-04-11 | 2020-09-25 | Tcl移动通信科技（宁波）有限公司 | 一种终端的重复日志过滤方法 |
Also Published As
| Publication number | Publication date |
|---|---|
| JP2000276391A (ja) | 2000-10-06 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US6374262B1 (en) | Relational database synchronization method and a recording medium storing a program therefore | |
| JP3396223B2 (ja) | ネットワーク・ディレクトリにおいてサブツリーを移動する方法ならびにその装置 | |
| US7516157B2 (en) | Relational directory | |
| US5884310A (en) | Distributed data integration method and system | |
| JP3792419B2 (ja) | ディレクトリデータ変換方法、ディレクトリデータ変換プログラムが記憶された記憶媒体、およびディレクトリ変換サーバ | |
| JP3984659B2 (ja) | 概要カタログ | |
| CN102239476B (zh) | 用于存储集群的共享名称空间 | |
| US6839704B2 (en) | Information storage, retrieval and delivery system and method operable with a computer network | |
| US5793970A (en) | Method and computer program product for converting message identification codes using a conversion map accesible via a data link | |
| US6363375B1 (en) | Classification tree based information retrieval scheme | |
| US6973463B2 (en) | Replication architecture for a directory server | |
| US20090327248A1 (en) | Method and apparatus for improving the integration between a search engine and one or more file servers | |
| US20100312750A1 (en) | System Of And Method For Transparent Management Of Data Objects In Containers Across Distributed Heterogenous Resources | |
| JP2001313639A (ja) | ネットワーク構成データ管理システム及び方法並びに記録媒体 | |
| JP2901081B2 (ja) | Ｏｓｉディレクトリの非葉エントリの名称変更方法 | |
| JP3810577B2 (ja) | ディレクトリ同期方法 | |
| US8516149B1 (en) | System for operating NFSv2 and NFSv3 clients with federated namespace | |
| JPH09134364A (ja) | 情報検索システム | |
| JP2002157158A (ja) | データベースシステムにおけるデータ管理方法 | |
| JP3300399B2 (ja) | 計算機システムおよびファイル管理方法 | |
| JP2002049637A (ja) | データベース管理方法及び装置並びに記録媒体 | |
| US6519610B1 (en) | Distributed reference links for a distributed directory server system | |
| US20030088615A1 (en) | Update resolution procedure for a directory server | |
| JP2858417B2 (ja) | 分散データベース管理方式 | |
| JP2001014328A (ja) | データベースシステムとそこで用いるディレクトリデータ構造 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20060427 |
|
| 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: 20060523 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20060524 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| LAPS | Cancellation because of no payment of annual fees |