(57)【特許請求の範囲】
【請求項１】
ディレクトリデータ変換サーバがディレクトリデータの内容を少なくとも１つのアプリケーションデータへ反映させるためのディレクトリデータ変換方法であって、
前記ディレクトリ変換サーバは、
前記ディレクトリデータの内容を反映させようとしているアプリケーションデータに対応付けられた、前記ディレクトリデータより所定のディレクトリエントリのデータを抽出するためのフィルタリング規則を、少なくとも１つ記憶するフィルタリング規則記憶手段と、前記フィルタリング規則記憶手段に記憶されたフィルタリング規則に対応付けられた、当該フィルタリング規則により抽出されたディレクトリエントリのデータを、前記ディレクトリデータのスキーマに基づいたデータから前記アプリケーションデータのスキーマに基づいたデータへ変換するためのスキーマ変換規則を記憶するスキーマ変換規則記憶手段と、を備え、
前記フィルタリング規則記憶手段に記憶されたフィルタリング規則にしたがい、前記ディレクトリデータよりディレクトリエントリのデータを抽出する第１のステップと、
前記スキーマ変換規則記憶手段に記憶された、前記ディレクトリエントリのデータを抽出するのに用いたフィルタリング規則に対応付けられたスキーマ変換規則にしたがい、前記抽出したディレクトリエントリのデータをスキーマ変換する第２のステップと、
前記スキーマ変換したディレクトリエントリのデータを、前記ディレクトリデータの内容を反映させようとしているアプリケーションデータに反映させる第３のステップと、を行うこと
を特徴とするディレクトリデータ変換方法。
【請求項２】
請求項１記載のディレクトリデータ変換方法であって、
前記ディレクトリ変換サーバは、
前記ディレクトリデータに対して行われた変更操作の内容を変更履歴として蓄積する第４のステップを更に行い、
前記第１のステップにおいて、前記フィルタリング規則によって特定されるディレクトリエントリのデータを前記変更履歴より抽出し、
前記第２のステップにおいて、前記抽出したディレクトリエントリのデータを、当該データを抽出するのに用いたフィルタリング規則に対応付けられているスキーマ変換規則にしたがい、スキーマ変換し、そして、
前記第３のステップにおいて、前記スキーマ変換されたディレクトリエントリのデータを、前記変更履歴の変更操作の種別にしたがい、前記ディレクトリデータの内容を反映させようとしているアプリケーションデータに反映させること
を特徴とするディレクトリデータ変換方法。
【請求項３】
請求項２記載のディレクトリデータ変換方法であって、
前記ディレクトリ変換サーバは、
前記第１のステップにおいて、前記フィルタリング規則記憶手段から前記変更履歴に示されている変更操作の対象ディレクトリエントリのデータを特定するフィルタリング規則を検出し、前記変更履歴に、前記検出したフィルタリング規則に対応付けられているスキーマ変換規則の識別情報を対応付け、
前記第２のステップにおいて、前記スキーマ変換規則記憶手段から前記変更履歴に対応付けられたスキーマ変換規則の識別情報により特定されるスキーマ変換規則を取り出し、前記取り出したスキーマ変換規則にしたがって、前記変更履歴に示されている変更操作の対象ディレクトリエントリのデータをスキーマ変換すること
を特徴とするディレクトリデータ変換方法。
【請求項４】
請求項３記載のディレクトリデータ変換方法であって、
前記変更履歴に示された変更操作の内容がディレクトリエントリの追加である場合、前記変更操作の対象ディレクトリエントリのデータは追加されたディレクトリエントリのデータであり、
前記変更履歴に示された変更操作の内容がディレクトリエントリの削除である場合、前記変更操作の対象ディレクトリエントリのデータは削除されたディレクトリエントリのデータである
ことを特徴とするディレクトリデータ変換方法。
【請求項５】
請求項３記載のディレクトリデータ変換方法であって、
前記ディレクトリ変換サーバは、
前記変更履歴に示された変更操作の内容がディレクトリエントリのエントリ名変更である場合に、前記変更履歴より、変更操作の内容がエントリ名変更前のディレクトリエントリの削除を示す第１の変更履歴と、変更操作の内容がエントリ名変更後のディレクトリエントリの追加を示す第２の変更履歴とを作成する第５のステップを更に行い、
前記第１のステップにおいて、前記フィルタリング規則記憶手段から前記第１の変更履歴に示されている削除対象ディレクトリエントリのデータを特定する第１のフィルタリング規則、および、前記第２の変更履歴に示されている追加対象ディレクトリエントリのデータを特定する第２のフィルタリング規則を検出し、前記第１の変更履歴に、前記検出した第１のフィルタリング規則に対応付けられているスキーマ変換規則の識別情報を対応付けるとともに、前記第２の変更履歴に、前記検出した第２のフィルタリング規則に対応付けられているスキーマ変換規則の識別情報を対応付け、
前記第２のステップにおいて、前記スキーマ変換規則記憶手段から前記第１の変更履歴に対応付けられたスキーマ変換規則の識別情報により特定される第１のスキーマ変換規則を取り出すとともに、前記第２の変更履歴に対応付けられたスキーマ変換規則の識別情報により特定される第２のスキーマ変換規則を取り出し、前記取り出した第１のスキーマ変換規則にしたがって、前記第１の変更履歴に示されている削除対象ディレクトリエントリのデータをスキーマ変換するとともに、前記取り出した第２のスキーマ変換規則にしたがって、前記第２の変更履歴に示されている追加対象ディレクトリエントリのデータをスキーマ変換すること
を特徴とするディレクトリデータ変換方法。
【請求項６】
請求項３記載のディレクトリデータ変換方法であって、
前記ディレクトリ変換サーバは、
前記変更履歴に示された変更操作の内容がディレクトリエントリのデータ変更である場合に、前記変更履歴より、変更操作の内容がデータ変更前のディレクトリエントリの削除を示す第１の変更履歴と、変更操作の内容がデータ変更後のディレクトリエントリの追加を示す第２の変更履歴とを作成する第５のステップを更に行い、
前記第１のステップにおいて、前記フィルタリング規則記憶手段から前記第１の変更履歴に示されている削除対象ディレクトリエントリのデータを特定する第１のフィルタリング規則、および、前記第２の変更履歴に示されている追加対象ディレクトリエントリのデータを特定する第２のフィルタリング規則を検出し、前記第１の変更履歴に、前記検出した第１のフィルタリング規則に対応付けられているスキーマ変換規則の識別情報を対応付けるとともに、前記第２の変更履歴に、前記検出した第２のフィルタリング規則に対応付けられているスキーマ変換規則の識別情報を対応付け、
前記第２のステップにおいて、前記スキーマ変換規則記憶手段から前記第１の変更履歴に対応付けられたスキーマ変換規則の識別情報により特定される第１のスキーマ変換規則を取り出すとともに、前記第２の変更履歴に対応付けられたスキーマ変換規則の識別情報により特定される第２のスキーマ変換規則を取り出し、前記取り出した第１のスキーマ変換規則にしたがって、前記第１の変更履歴に示されている削除対象ディレクトリエントリのデータをスキーマ変換するとともに、前記取り出した第２のスキーマ変換規則にしたがって、前記第２の変更履歴に示されている追加対象ディレクトリエントリのデータをスキーマ変換すること
を特徴とするディレクトリデータ変換方法。
【請求項７】
ディレクトリデータの内容を少なくとも１つのアプリケーションデータへ反映させるためのディレクトリデータ変換プログラムを記憶した記憶媒体であって、
前記ディレクトリデータ変換プログラムは、情報処理装置に、請求項１、２、３、４、５または６のいずれか一項に記載のディレクトリデータ変換方法の各ステップを実行させること
を特徴とするディレクトリデータ変換プログラムが記憶された記憶媒体。
【請求項８】
ディレクトリデータの内容を少なくとも１つのアプリケーションデータへ反映させるためのディレクトリデータ変換サーバであって、
前記ディレクトリデータの内容を反映させようとしているアプリケーションデータに対応付けられた、前記ディレクトリデータより所定のディレクトリエントリのデータを抽出するためのフィルタリング規則を、少なくとも１つ記憶するフィルタリング規則記憶手段と、
前記フィルタリング規則記憶手段に記憶されたフィルタリング規則に対応付けられた、当該フィルタリング規則により抽出されたディレクトリエントリのデータを、ディレクトリデータのスキーマに基づいたデータからアプリケーションデータのスキーマに基づいたデータへ変換するためのスキーマ変換規則を記憶するスキーマ変換規則記憶手段と、
前記フィルタリング規則記憶手段に記憶されたフィルタリング規則にしたがい、前記ディレクトリデータよりディレクトリエントリのデータを抽出するフィルタリング手段と、
前記スキーマ変換記憶手段に記憶された、前記ディレクトリエントリのデータを抽出するのに用いたフィルタリング規則に対応付けられたスキーマ変換規則にしたがい、前記抽出したディレクトリエントリのデータをスキーマ変換するスキーマ変換手段と、
前記スキーマ変換したディレクトリエントリのデータを、前記ディレクトリデータの内容を反映させようとしているアプリケーションデータに反映させるアプリケーションデータ更新手段と、を備える
ことを特徴とするディレクトリデータ変換サーバ。
【請求項９】
請求項８記載のディレクトリデータ変換サーバと、ディレクトリデータを管理するディレクトリサーバと、アプリケーションデータを管理するアプリケーションサーバとでなるディレクトリサービスシステム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、企業情報の一元管理を可能にするディレクトリサービスに関し、特に、独自のデータベースを持つ複数のアプリケーション各々に、ディレクトリサービスの内容を反映させることが可能なディレクトリデータ変換技術に関する。
【０００２】
【従来の技術】
今日の企業内情報システムでは、ネットワークＯＳやメールシステムなどの独立したシステムが複数混在することが一般的である。このようなＯＡ環境下において、ユーザは、個々のシステムを利用するために、ログイン名やパスワードやメールアドレスなどのシステム固有のユーザ情報を必要とする。このため、システム管理者は、ユーザの増減に際し、それぞれのシステムにユーザ情報を登録・削除する必要があり、負担が大きい。
【０００３】
また、通常、企業内情報システムは、比較的小規模な部署単位で構築されることが多い。しかしながら、部署ごとに独立した企業内情報システムが構築されると、部署間の人の移動に伴う手続きやメールの交換を円滑に行うことができない。このため、全社的に統一された大規模・広域な企業内情報システムの構築が望まれている。
【０００４】
このような状況下において、複数の異種システムで用いられるユーザ情報、機器・資源の情報を一元的に管理することができるサービスとして、また、全社的な企業内情報システムの基盤として、ディレクトリサービスが注目されている。
【０００５】
ディレクトリサービスに関する標準としては、ＣＣＩＴＴの勧告であるＸ．５００が挙げられる。Ｘ．５００は、ディレクトリサービスをクライアント−サーバ型の分散システム・アーキテクチャとして規定し、クライアント−サーバ間のディレクトリ・アクセス・プロトコルとしてＤＡＰ（Directory Access Protocl）を定めている。
【０００６】
Ｘ．５００準拠のディレクトリサービスは、木構造（ディレクトリ・ツリー）として階層管理されたデータモデルを有する。木の枝葉に相当する個所にはディレクトリエントリが配置される。各々のエントリは、同一の親エントリを持つエントリ間で一意に識別される相対識別名（ＲＤＮ：Relative Distinguished Name）を持ち、また、木構造の根（ルート）からの経路を示すＲＤＮの列である識別名（ＤＮ：Distinguished Name）により一意に識別される。各々のエントリは、ユーザのメールアドレスに加え、姓名、電話番号、FAX番号、写真など、様々な情報を属性として記憶することが可能である。
【０００７】
また、エントリは、必ず１つ以上のオブジェクトクラスに属する。ここで、オブジェクトクラスは、当該クラスに必ず存在する必須の属性および存在してもよい任意の属性の集合を定義する。このオブジェクトクラス定義と木構造の定義とをあわせ、ディレクトリスキーマあるいは単にスキーマと呼んでいる。
【０００８】
インターネットに関する標準化団体であるＩＥＴＦ（Internet Engineering Task Force）は、ＴＣＰ／ＩＰスタック上で動作するＬＤＡＰ（Light Weight Directory Access Protocol）（RFC2251）をディレクトリ・アクセスの標準プロトコルとしている。ＬＤＡＰは、ＯＳＩスタック上で動作するＤＡＰに比べて軽量であることが利点である。
【０００９】
上述したように、管理負荷軽減のためディレクトリサービスによる企業情報の一元管理が注目される一方で、これまでに部署単位で導入されたアプリケーション（企業内情報システム）の多くは独自のデータベースを持ち、アプリケーション固有の形式でユーザや組織に関する企業情報を管理している（以下、アプリケーションが管理するこれらの企業情報をアプリケーションデータと呼ぶ）。したがって、一企業内には、ディレクトリサービスによるデータベースを含め、異なるスキーマを持つデータベースが複数存在することとなり、一元管理を困難にしている。
【００１０】
こうした問題を解決する方法として、以下の二つの方法が考えられている。
【００１１】
第１の方法は、各アプリケーションが必要とするデータの全てをディレクトリサービスが管理し、各アプリケーションがディレクトリ・アクセス・プロトコルをサポートし、ディレクトリデータを参照する方法である。
【００１２】
第２の方法は、第１の方法と同様に、各アプリケーションが必要とするデータの全てをディレクトリサービスが管理するが、当該ディレクトリデータをアプリケーション固有のデータへ変換して、当該アプリケーション固有のデータベースへ反映させる方法である。アプリケーションは、従来通り固有のデータベースを参照する。
【００１３】
上記第１の方法では、プログラムの構造、開発力などの問題からディレクトリ・アクセス・プロトコルのサポートが現実的に不可能なアプリケーションもあるため、アプリケーションによってはディレクトリデータを参照することができない事態も考えられる。また、当該方法では、ディレクトリデータを直接参照することになるので、ディレクトリサービスが起動中でなければアプリケーションを利用することができない。
【００１４】
一方、上記第２の方法によれば、上記第１の方法のような問題はなく、企業情報の一元管理が実現できる。
【００１５】
上記第２の方法にしたがい、ディレクトリデータを他方のディレクトリデータあるいは特定アプリケーションの固有データベースに反映させ、ディレクトリデータ間あるいはディレクトリデータと特定アプリケーションの固有データベースとの間で同期をとる方法が、これまでに多数提案されている。ディレクトリデータ間で同期をとる方法としては、特開平６−１３９１２６号公報に記載の技術がある。
【００１６】
【発明が解決しようとする課題】
ところで、上記第２の方法にしたがい、ディレクトリデータ間あるいはディレクトリデータと特定アプリケーションの固有データベースとの間で同期をとる従来の方法では、一つのオブジェクトクラスに対する変換規則は一つであり、その規則に基づいて当該クラスに属する全エントリが変換される。このため、ディレクトリ・ツリーの一部分を選択的に他のデータベースに反映させることができないという問題がある。また、同一ディレクトリに存在する同一クラスのエントリに対しては、同一のスキーマ変換しか行えないという問題もある。
【００１７】
しかしながら、実際には、上述したように、部署単位に導入されたアプリケーション（企業内情報システム）の多くは独自のデータベースを持つ。通常、異なるデータベース同士では、対象とするオブジェクトやオブジェクトを抽象化するスキーマ定義が異なる。このため、企業全体の情報を管理するディレクトリデータから、任意の事業所の情報のみを抽出し、事業所単位で運用されているアプリケーションの情報に反映させたい、あるいは、ディレクトリが管理するユーザ情報をアプリケーションのユーザ情報にスキーマ変換する際に、当該ユーザの役職によって対応付けるアプリケーション側のスキーマを変えたいなどのニーズがある。上記従来のディレクトリデータ間あるいはディレクトリデータと特定アプリケーションの固有データベースとの間で同期をとる方法では、このようなニーズに応えることができない。
【００１８】
本発明は、上記事情に鑑みてなされたものであり、本発明の主な目的は、アプリケーションのデータベース毎に、対象とするオブジェクトやオブジェクトを抽象化するスキーマが異なる場合であっても、ディレクトリデータの内容をアプリケーションのデータベースに各々反映させることを可能にすることにある。
【００１９】
【課題を解決するための手段】
上記課題を解決するために、本発明は、ディレクトリデータの内容を少なくとも１つのアプリケーションデータへ反映させるためのディレクトリデータ変換方法であって、
前記ディレクトリデータの内容を反映させようとしているアプリケーションデータに対応付けられた少なくとも１つのフィルタリング規則によって特定されるディレクトリエントリのデータを抽出する第１のステップと、
前記抽出したディレクトリエントリのデータを、当該データを抽出するのに用いたフィルタリング規則に対応付けられた、ディレクトリデータのスキーマに基づいたデータをアプリケーションデータのスキーマに基づいたデータへ変換するためのスキーマ変換規則にしたがい、スキーマ変換する第２のステップと、
前記スキーマ変換されたエントリのデータを、前記ディレクトリデータの内容を反映させようとしているアプリケーションデータに反映させる第３のステップと、
を有することを特徴とする。
【００２０】
本発明では、ディレクトリデータの内容をあるアプリケーションデータへ反映させる場合、先ず、当該アプリケーションが対象とするディレクトリエントリのデータが、当該アプリケーションに対応付けられたフィルタリング規則によって抽出される。次いで、抽出されたディレクトリエントリのデータが、当該データを抽出するのに用いたフィルタリング規則に対応付けられたスキーマ変換規則にしたがい、スキーマ変換されて、当該アプリケーションデータに反映される。
【００２１】
したがって、本発明によれば、アプリケーションデータ毎に対象とするディレクトリエントリやスキーマが異なる場合であっても、ディレクトリデータの内容をアプリケーションデータ各々に反映させることができる。
【００２２】
また、たとえば、１つのアプリケーションデータに複数のフィルタリング規則を割り当てておき、当該複数のフィルタリング規則各々に異なるスキーマ変換規則を割り当てておくことで、当該アプリケーションデータに反映させるディレクトリデータの内容を、前記複数のフィルタリング規則各々により抽出されるディレクトリエントリのデータ毎に、異なるスキーマに変換することができる。
【００２３】
【発明の実施の形態】
以下に、本発明の１実施形態について説明する。
【００２４】
図１は、本発明の１実施形態が適用されたディレクトリサービスシステムの機能構成図である。
【００２５】
ここで、符号１は、全社的な企業内情報システムの基盤として構築されたディレクトリサービスを行うディレクトリサーバである。ディレクトリデータを保持するディレクトリデータ・データベース（ＤＢ）１１と、ディレクトリデータ・データベース（ＤＢ）１１に格納されたディレクトリデータにしたがい、全社的な企業内情報を一元管理するディレクトリサービス部１２とからなる。
【００２６】
符号２ａ、２ｂは、事業所や部署などの単位毎に企業内情報システムとして構築されたアプリケーションサービスを行うアプリケーションサーバである。アプリケーションデータを保持するアプリケーションデータ・データベース（ＤＢ）２１と、アプリケーションデータ・データベース（ＤＢ）２１に格納されたアプリケーションデータにしたがい、当該アプリケーションが対象とする事業所あるいは部署などの単位毎に企業内情報を一元管理するアプリケーションサービス部２２とからなる。
【００２７】
なお、図１では、２つのアプリケーションサーバを示しているが、当然のことながらこの数に限定されるものではない。
【００２８】
符号３は、ディレクトリサーバ１が備えるディレクトリデータの内容を、アプリケーションサーバ２ａ、２ｂが備えるアプリケーションデータへ各々反映させるディレクトリデータ変換サーバである。変更履歴取得部３１と、フィルタリング規則テーブル３２と、変更履歴フィルタリング部３３と、スキーマ変換規則テーブル３４と、変換規則決定部３５と、スキーマ変換部３６と、データベース（ＤＢ）更新部３７とからなる。
【００２９】
変更履歴取得部３１は、ディレクトリサービス部１２により行われたディレクトリデータの変更履歴を取得する。フィルタリング規則テーブル３２は、アプリケーションサーバ２ａ、２ｂ各々が備えるアプリケーションデータのいずれかあるいはその両方に対応付けられた、所定のディレクトリエントリのデータを抽出するためのフィルタリング規則を、少なくとも１つ格納する。変更履歴フィルタリング部３３は、フィルタリング規則テーブル３２に格納されたフィルタリング規則にしたがい、変更履歴取得部３１で取得した変更履歴から所定のディレクトリエントリに対する変更履歴を抽出する。スキーマ変換規則テーブル３４は、ディレクトリデータのスキーマをアプリケーションデータのスキーマに変換するためのスキーマ変換規則を格納する。変換規則決定部３５は、変更履歴フィルタリング部３３で変更履歴を抽出するのに用いたフィルタリング規則にしたがい、当該フィルタリング規則により抽出された変更履歴に含まれるディレクトリエントリのデータをスキーマ変換するのに用いるスキーマ変換規則を決定する。スキーマ変換部３６は、変換規則決定部３５で決定されたスキーマ変換規則にしたがい、変更履歴フィルタリング部３３で抽出した変更履歴に含まれるディレクトリエントリのデータをスキーマ変換する。ＤＢ更新部３７は、スキーマ変換部３６にてスキーマ変換されたディレクトリエントリのデータを、変更履歴フィルタリング部３３にて当該ディレクトリエントリのデータを含む変更履歴を抽出するのに用いたフィルタリング規則に対応付けられているアプリケーションデータに、当該変更履歴に示された変更操作の種別にしたがって反映させる。
【００３０】
次に、このようなディレクトリサービスシステムを実現するためのハードウエア構成について説明する。
【００３１】
図２は、図１に示すディレクトリサービスシステムを実現するためのハードウエア構成の一例を示した図である。
【００３２】
図２において、情報処理装置４はディレクトリサーバ１として機能する。情報処理装置４は、メモリ４１と、ＣＰＵ４２と、磁気ディスク４３と、磁気ディスク４３へのアクセスを制御するディスクコントローラ４４と、ＬＡＮ１００を介して他の情報処理装置と通信を行うためのＬＡＮコントローラ４５とを有する。
【００３３】
磁気ディスク４３には、オペレーティングシステム（ＯＳ）４８やディレクトリサーバプログラム４７が格納されている。ＣＰＵ４２は、磁気ディスク４３に格納されたＯＳ４８をディスクコントローラ４４によりメモリ４１上にロードして実行し、その後、磁気ディスク４３に格納されたアプリケーションサーバプログラム４７をディスクコントローラ４４によりメモリ４１上にロードし、実行することで、図１に示すディレクトリサービス部１２をプロセスとして実現する。また、磁気ディスク４３にはディレクトリデータ４６が格納されており、磁気ディスク４３は、図１に示すディレクトリデータＤＢ１１としても機能する。
【００３４】
情報処理装置５はアプリケーションサーバ２として機能する。情報処理装置５は、メモリ５１と、ＣＰＵ５２と、磁気ディスク５３と、磁気ディスク５３へのアクセスを制御するディスクコントローラ５４と、ＬＡＮ１００を介して他の情報処理装置と通信を行うためのＬＡＮコントローラ５５とを有する。
【００３５】
磁気ディスク５３には、オペレーティングシステム（ＯＳ）５８やアプリケーションサーバプログラム５７が格納されている。ＣＰＵ５２は、磁気ディスク５３に格納されたＯＳ５８をディスクコントローラ５４によりメモリ５１上にロードして実行し、その後、磁気ディスク５３に格納されたアプリケーションサーバプログラム５７をディスクコントローラ５４によりメモリ５１上にロードし、実行することで、図１に示すアプリケーションサービス部２２をプロセスとして実現する。また、磁気ディスク５３にはアプリケーションデータ５６が格納されており、磁気ディスク５３は、図１に示すアプリケーションデータＤＢ２１としても機能する。
【００３６】
情報処理装置６はディレクトリデータ変換サーバ３として機能する。情報処理装置６は、メモリ６１と、ＣＰＵ６２と、磁気ディスク６３と、磁気ディスク６３へのアクセスを制御するディスクコントローラ６４と、ＬＡＮ１００を介して他の情報処理装置と通信を行うためのＬＡＮコントローラ６５とを有する。
【００３７】
磁気ディスク６３には、オペレーティングシステム（ＯＳ）７４やディレクトリデータ変換プログラム６８が格納されている。ここで、ディレクトリデータ変換プログラム６８は、変更履歴取得プログラム６９と、変更履歴フィルタリングプログラム７０と、変換規則決定プログラム７１と、スキーマ変換プログラム７２と、ＤＢ更新プログラム７３とからなる。ＣＰＵ６２は、磁気ディスク６３に格納されたＯＳ７４をディスクコントローラ６４によりメモリ６１上にロードして実行し、その後、磁気ディスク６３に格納された変更履歴取得プログラム６９、変更履歴フィルタリングプログラム７０、変換規則決定プログラム７１、スキーマ変換プログラム７２およびＤＢ更新プログラム７３を実行することで、各々、図１に示す変更履歴取得部３１、変更履歴フィルタリング部３３、変換規則決定部３５、スキーマ変換部３６およびＤＢ更新部３７を、プロセスとして実現する。また、磁気ディスク６３にはフィルタリング規則ファイル６６およびスキーマ変換ファイル６７が格納されており、磁気ディスク５３は、図１に示すフィルタリング規則テーブル３２およびスキーマ変換規則テーブル３４としても機能する。
【００３８】
次に、このような構成を有するディレクトリサービスシステムの概略動作について説明する。
【００３９】
図３は、図１に示すディレクトリサービスシステムの概略動作を説明するための図である。
【００４０】
ここで、全社ディレクトリデータ５００は全社員のデータであり、ディレクトリデータＤＢ１１に格納されているディレクトリデータに相当する。上述したように、ディレクトリデータは、木構造（ディレクトリ・ツリー）として階層管理されている。そして、木の枝葉に相当する個所にはディレクトリエントリが配置される。各々のエントリは、同一の親エントリを持つエントリ間で一意に識別される相対識別名（ＲＤＮ：Relative Distinguished Name）を持ち、また、木構造の根（ルート）からの経路を示すＲＤＮの列である識別名（ＤＮ：Distinguished Name）により一意に識別される。
【００４１】
図３に示す例でいえば、全社ディレクトリデータ５００は、会社hitachiを表すエントリ５０６を基点として、各エントリが木構造で階層管理されている。エントリ５０１は、会社hitachiのＡ工場を表すエントリである。Ａ工場のディレクトリデータ５０３は、エントリ５０１を基点として、各エントリが木構造で階層管理されている。全社ディレクトリデータ５００の最下層にある各エントリは、会社hitachで働く社員を表すエントリである。これらのエントリは、社員の職種を示す属性を有する。図３では、エントリ５０４は、社員甲を表すエントリであり、職種＝設計という属性を持っている。エントリ５０５は、社員乙を表すエントリであり、職種＝営業という属性を持っている。
【００４２】
さて、図３において、エントリ５０４、５０５の属性に変更が加えられたとする。ここで、図１において、アプリケーションサーバ２ａはＡ工場の設計部門の情報を管理しており、アプリケーション２ｂはＡ工場の営業部門の情報を管理しているとする。この場合、アプリケーションサーバ２ａが備えるアプリケーションデータにはエントリ５０４のデータを反映させ、アプリケーションサーバ２ｂが備えるアプリケーションデータには、エントリ５０５のデータを反映させる必要がある。
【００４３】
そこで、本実施形態では、変更履歴フィルタリング部３３により、アプリケーションサーバ２ａが備えるアプリケーションデータに反映させるべきエントリのデータを抽出するためのフィルタリング規則にしたがい、変更履歴取得部３１によりディレクトリサーバ１から取得した変更履歴から、エントリ５０４のデータを抽出する。次に、スキーマ変換部３６において、抽出したエントリ５０４のデータを、変換規則決定部３５にて決定された、前記フィルタリング規則に対応付けられたスキーマ変換規則にしたがってスキーマ変換する。次いで、ＤＢ更新部３７により、スキーマ変換されたエントリ５０４のデータをアプリケーションサーバ２ａが備えるアプリケーションデータ（図３の設計用アプリケーション５１０に相当）に反映させる。
【００４４】
また、同様に、変更履歴フィルタリング部３３により、アプリケーションサーバ２ｂが備えるアプリケーションデータに反映させるべきエントリのデータを抽出するためのフィルタリング規則にしたがい、変更履歴取得部３１によりディレクトリサーバ１から取得した変更履歴から、エントリ５０５のデータを抽出する。次に、スキーマ変換部３６において、抽出したエントリ５０５のデータを、変換規則決定部３５にて決定された、前記フィルタリング規則に対応付けられたスキーマ変換規則にしたがってスキーマ変換する。次いで、ＤＢ更新部３７により、スキーマ変換されたエントリ５０５のデータをアプリケーションサーバ２ｂが備えるアプリケーションデータに反映させる。
【００４５】
このようにすることで、変更が加えられたエントリ５０４のデータは、アプリケーションサーバ２ａが備えるアプリケーションデータにのみ反映され、アプリケーションサーバ２ｂが備えるアプリケーションデータには反映されない。また、エントリ５０５のデータは、アプリケーションサーバ２ｂが備えるアプリケーションデータにのみ反映され、アプリケーションサーバ２ａが備えるアプリケーションデータには反映されない。
【００４６】
なお、フィルタリング規則やスキーマ変換規則は、ディレクトリサービスの管理者が作成し、ディレクトリデータ変換サーバのフィルタリング規則テーブル３２やスキーマ変換規則テーブル３４に予め格納しておくようにする。
【００４７】
次に、ディレクトリサーバ１において、ディレクトリサービス部１２がディレクトリデータＤＢ１１に対して行う変更操作の内容について説明する。
【００４８】
図４は、ディレクトリサービス部１２がディレクトリデータに対して行う変更操作の一覧を示している。
【００４９】
図示するように、ディレクトリサービス部１２がディレクトリデータに対して行う変更操作としては、ディレクトリエントリの追加、削除、エントリ属性変更、およびＤＮ変更がある。ディレクトリエントリのエントリ属性変更は、さらに、属性値の追加、削除および置換に分類される。ディレクトリサービス部１２は、ディレクトリデータに対して変更操作を行う度に、その変更内容を変更履歴としてディレクトリデータＤＢ１１に記録する。
【００５０】
図５は、ディレクトリサービス部１２がディレクトリデータに対して変更操作を行う度に作成し、ディレクトリデータＤＢ１１に記録する変更履歴の内容を示す図である。
【００５１】
図示するように、変更履歴７００は、変更操作種別７０１、対象エントリＤＮ７０２、対象エントリ属性７０３、変更内容詳細７０４、新ＲＤＮ７０５、および、新上位ＤＮ７０６からなる。
【００５２】
変更操作種別７０１には、ディレクトリサービス部１２がディレクトリデータに対して行った変更操作の種類を示すデータが格納される。具体的には、変更操作が「エントリ追加」の場合は「ａｄｄ」、「エントリ削除」の場合は「ｄｅｌｅｔｅ」、「エントリ属性値変更」の場合は「ｍｏｄｉｆｙ」、「ＤＮ変更」の場合は「ｒｅｎａｍｅ」の文字列データが格納される。
【００５３】
対象エントリＤＮ７０２には、ディレクトリサービス部１２がディレクトリデータに対して行った、変更操作種別７１に示す変更操作の対象エントリのＤＮを表す文字列データが格納される。
【００５４】
対象エントリ属性７０３には、対象エントリＤＮ７０２が示す対象エントリが持つ変更操作前の属性が格納される。
【００５５】
図６は、対象エントリ属性７０３に格納される内容を示す図である。
【００５６】
図示するように、対象エントリ属性７０３は、属性名７１１と０以上の属性値７１２の組が、対象エントリＤＮ７０２が示す対象エントリが有する属性毎に設けられて構成される。属性名７１１には、変更操作の対象となった属性名を示すデータが格納される。属性値７１２には、属性名７１１により特定される属性の変更操作前の属性値を示すデータが格納される。
【００５７】
図５に戻って説明を続ける。
【００５８】
変更内容詳細７０４には、変更された属性の具体的な値が格納される。変更内容詳細７０４は、変更操作が「エントリ追加」、「エントリ属性変更」、あるいは「ＤＮ変更」の場合にのみ存在する。
【００５９】
図７は、変更操作が「エントリ属性変更」あるいは「ＤＮ変更」である場合における変更内容詳細７０４の内容を示す図である。
【００６０】
図示するように、この場合の変更内容詳細７０４は、属性変更操作種別７２１と変更対象属性名７２２と０個以上の属性値７２３の組が、対象エントリＤＮ７０２が示す対象エントリが有する属性毎に設けられて構成される。変更対象属性名７２２には、変更操作の対象となった属性名を示すデータが格納される。属性変更操作種別７２１には、属性変更操作の種類を示すデータが格納される。具体的には、変更操作が「属性値追加」の場合は「ａｄｄ」、「属性値削除」の場合は「ｄｅｌｅｔｅ」、そして、「属性値変更」の場合は「ｒｅｐｌａｃｅ」の文字列データが格納される。属性値７２３には、変更操作が「属性値追加」の場合は追加対象となる属性値、「属性値削除」の場合は削除対象となる属性値、そして、「属性値置換」の場合は、置換後の属性値を示すデータが格納される。
【００６１】
図８は、変更操作が「エントリ追加」である場合における変更内容詳細７０４の内容を示す図である。
【００６２】
図示するように、この場合の変更内容詳細７０４は、属性名７３１と０個以上の属性値７３２の組が、追加するエントリが有する属性毎に設けられて構成される。属性名７３１には、追加するエントリが有する属性名を示すデータが格納される。属性値７３２には、属性名７３１により特定される属性名の属性値を示すデータが格納される。
【００６３】
図５に戻って説明を続ける。
【００６４】
新ＲＤＮ７０５には、変更操作種別７０１に格納されたデータが「ＤＮ変更」、すなわち「ｒｅｎａｍｅ」の文字列データである場合に、変更対象エントリの変更後のＲＤＮを示すデータが格納される。
【００６５】
新上位ＤＮ７０６には、変更操作種別７０１に格納されたデータが「ＤＮ変更」、すなわち「ｒｅｎａｍｅ」の文字列データである場合に、変更対象エントリの親エントリのＤＮを示すデータが格納される。
【００６６】
ここで、上述した図３に示す例において、社員甲を表すエントリ５０４の属性に変更を加えた場合に作成される変更履歴を図９に示す。図示するように、変更操作種別７０１には「エントリ属性値変更」を示す「ｍｏｄｉｆｙ」が格納され、対象エントリＤＮ７０２にはエントリ５０４のＤＮ「甲」が格納され、対象エントリ属性７０３にはエントリ５０４の変更前の属性が格納され、変更内容詳細にはエントリ５０４の変更後の属性が格納される。この場合、変更操作が「エントリ属性値変更」であるので、新ＲＤＮ７０５および新上位ＤＮ７０６は存在しない。
【００６７】
次に、フィルタリング規則テーブル３２に記憶されるフィルタリング規則について説明する。
【００６８】
図１０は、フィルタリング規則テーブル３２に記憶されるフィルタリング規則の内容を示す図である。
【００６９】
図示するように、フィルタリング規則テーブル３２は、アプリケーションサーバ２ａ、２ｂが備えるアプリケーションデータ毎に、少なくとも１つのフィルタリング規則８００を格納している。
【００７０】
フィルタリング規則８００は、アプリケーションＩＤ８０１、Ｂａｓｅｄｎ８０２、Ｓｃｏｐｅ８０３、Ｆｉｌｔｅｒ８０４、および、変換規則ＩＤ８０５からなる。
【００７１】
アプリケーションＩＤ８０１は、当該フィルタリング規則８００により抽出されるエントリのデータを反映させるべきアプリケーションデータを特定するための識別情報である。
【００７２】
Ｂａｓｅｄｎ８０２およびＳｃｏｐｅ８０３は、アプリケーションＩＤ８０１へ反映すべきエントリのデータの、木構造で管理されたディレクトリデータにおける位置を指定する。Ｂａｓｅｄｎ８０２には対象範囲の基点エントリのＤＮを示すデータが格納され、Ｓｃｏｐｅ８０３には、Ｂａｓｅｄｎ８０２により特定される基点エントリからの範囲を示す文字列データが格納される。
【００７３】
図１１にＳｃｏｐｅ８０３がとり得る値と意味を示す。Ｓｃｏｐｅ８０３は、「ｂａｓｅ」、「ｏｎｅｌｅｖｅｌ」および「ｓｕｂｔｒｅｅ」の３種類の値をとり得る。ｂａｓｅは基点エントリのみ、ｏｎｅｌｅｖｅは基点の子エントリのみ、そして、ｓｕｂｔｒｅｅは、基点以下の全エントリが対象であることを意味する。
【００７４】
Ｆｉｌｔｅｒ８０４は、対象エントリの属性値が満たすべき条件を示す。属性名と当該属性名により特定される属性のとるべき値からなる条件式あるいは複数の条件式の論理和、論理積あるいは否定の組み合せでなる。
【００７５】
変換規則ＩＤ８０５は、Ｂａｓｅｄｎ８０２、Ｓｃｏｐｅ８０３およびＦｉｌｔｅｒ８０４を全て満たす変更履歴に対して適用すべきスキーマ変換規則を示す変換規則の識別子である。
【００７６】
ここで、上述した図３に示す例において、社員甲を表すエントリ５０４に対して行われた変更をアプリケーションサーバ２ａのアプリケーションデータに反映させるためのフィルタリング規則の一例を図１２に示す。図示するように、アプリケーションＩＤ８０１には、アプリケーションサーバ２ａのアプリケーションデータのＩＤ「２ａ」が格納され、Ｂａｓｅｄｎ８０２には、アプリケーションサーバ２ａのアプリケーションデータに反映させる全社ディレクトリデータ５００の範囲をＡ工場のディレクトリデータ５０３に限定するため、Ａ工場を表すツリーの基点エントリのＤＮ「o=hitachi,ou=A工場」が格納され、Ｓｃｏｐｅ８０３には、Ｂａｓｅｄｎ８０２に格納された基点エントリ以下の全エントリが対象であることを示す「ｓｕｂｔｒｅｅ」が格納され、Ｆｉｌｔｅｒ８０４には、Ａ工場のディレクトリデータ５０３に含まれる各エントリのうち、設計担当者の社員のみを対象とするために、属性名と属性値からなる条件式「職種＝設計」が格納され、変換規則ＩＤ８０５には適用すべきスキーマ変換規則のＩＤ「Design User」が格納される。
【００７７】
このフィルタリング規則によれば、上述した図３に示す例において、社員甲を表すエントリ５０４および社員乙を表すエントリ５０５の属性に変更が加えられて、変更履歴が各々作成された場合、変更履歴フィルタリング部３３において、「職種＝設計」という属性を有するエントリ５０４に対する変更履歴のみが抽出されることとなり、「職種＝営業」という属性を有するエントリ５０５に対する変更履歴は抽出されない。
【００７８】
次に、スキーマ変換規則テーブル３４に記憶されるスキーマ変換規則について説明する。
【００７９】
図１３は、スキーマ変換規則テーブル３４に記憶されるスキーマ変換規則の内容を示す図である。
【００８０】
図示するように、スキーマ変換規則テーブル３４は、少なくとも１つのスキーマ変換規則９００を格納している。
【００８１】
スキーマ変換規則９００は、ディレクトリサーバ１が行うディレクトリサービスのスキーマに基づいたディレクトリデータデータを、アプリケーションサーバ２ａあるいはアプリケーションサーバ２ｂが行うアプリケーションサービスのスキーマに基づいたアプリケーションデータへ変換する規則である。図示するように、スキーマ変換規則を識別するための変換規則ＩＤ９０１（図１０に示す変換規則ＩＤ８０５と同じ）と、反映すべきアプリケーションデータのスキーマを構成する属性毎に、ディレクトリエントリの属性値から当該属性値の値を生成する規則である属性変換規則９０２とでなる。
【００８２】
図１４は、属性変換規則９０２を説明するための図である。
【００８３】
属性変換規則９０２は、上述したように、任意のスキーマに基づく属性値を入力として、異なるスキーマに基づく属性値を生成するための規則であり、図１４（ａ）に示すように、属性名９１２と属性値生成規則９２２とでなる組を一つ以上備えて構成される。たとえば、図１４（ｂ）において、スキーマＡに基づくデータは、図１４（ａ）に示す属性変換規則９０２により、スキーマＢに基づくデータへ変換される。
【００８４】
ここで、上述した図３に示す例において、社員甲を表すエントリ５０４に対して行われた変更をアプリケーションサーバ２ａのアプリケーションデータに反映させるためのスキーマ変換規則の一例を図１５に示す。図示するように、変換規則ＩＤ９０２には、エントリ５０４に対して行われた変更をアプリケーションサーバ２ａのアプリケーションデータに反映させるためのスキーマ変換規則のＩＤ「Design User」（図１２に示す変換規則ＩＤ８０５と同じ）が格納され、属性変換規則９０２には、図１４に示すような、エントリ５０４のデータをアプリケーションサーバ２ａのアプリケーションデータに反映させるためのスキーマ変換規則が格納される。
【００８５】
次に、本実施形態のディレクトリサービスシステムにおけるディレクトリデータ変換サーバ３の動作の詳細について説明する。
【００８６】
図１６は、ディレクトリデータ変換サーバ３の動作を説明するためのフロー図である。
【００８７】
先ず、変更履歴取得部３１は、ディレクトリサーバ１にアクセスし、いまだ取得していない変更履歴７００が存在するか否かを問い合わせる（ステップＳ１１０１）。いまだ取得していない変更履歴７００が存在する場合は、いまだ取得していない変更履歴７００であって、作成時期が最も古い変更履歴７００を、ディレクトリサーバ１から取得し、変更履歴フィルタリング部３３へ渡す（ステップＳ１１０２）。一方、いまだ取得していない変更履歴７００が存在しない場合は、ステップＳ１１０１に戻り、一定時間経過後、ディレクトリサーバ１に再度アクセスし、いまだ取得していない変更履歴７００が存在するか否かを問い合わせる。
【００８８】
変更履歴フィルタリング部３３は、変更履歴取得部３１より変更履歴７００を受け取ると、フィルタリング規則テーブル３２に格納されたフィルタリング規則８００各々について、変更履歴７００がフィルタリング規則８００に規定された条件を満たしているか否かを調べ、変更履歴７００が条件を満たしているフィルタリング規則８００を検出する。そして、検出したフィルタリング規則８００に規定されているアプリケーションＩＤ８０１と変換規則ＩＤ８０５の組でなるＩＤリストを作成し、これを変更履歴７００とともに変換規則決定部３５へ渡す（ステップＳ１１０３）。
【００８９】
図１７に、変更履歴フィルタリング部３３で作成されるＩＤリストの一例を示す。この例では、変更履歴取得部３１より受け取った変更履歴７００が、フィルタリング規則テーブル３２に格納された１つのフィルタリング規則８００に規定された条件を満たしていることを示している。なお、変更履歴取得部３１より受け取った変更履歴７００が、フィルタリング規則テーブル３２に格納されたいずれのフィルタリング規則８００に規定された条件も満たしていない場合、ＩＤリストは空欄となる。
【００９０】
次に、変換規則決定部部３５は、変更履歴フィルタリング３３より変更履歴７００とＩＤリストを受け取ると、ＩＤリストの中身を確認し、空欄であるか否かを確認する（ステップＳ１１０４）。空欄である場合は、受け取った変更履歴７００がフィルタリング規則テーブル３２に格納されたいずれのフィルタリング規則８００に規定された条件も満たしていないことを意味するので、この場合、受け取った変更履歴７００およびＩＤリストを破棄してステップＳ１１０１に戻る。一方、空欄でない場合は、ＩＤリストに記述された変換規則ＩＤ８０５により特定されるスキーマ変換規則９００をスキーマ変換規則テーブル３４より取得し、これに前記変換規則ＩＤ８０５と組となるアプリケーションＩＤ８０１を付して、変更履歴７００とともにスキーマ変換部３６へ渡す（ステップＳ１１０５）。
【００９１】
次に、スキーマ変換部３６は、変換規則決定部３５より受け取った変更履歴７００に含まれるエントリのデータを、同じく変換規則決定部３５より受け取ったスキーマ変換規則９００にしたがい、スキーマ変換する。なお、複数のスキーマ変換規則９００を受け取っている場合は、複数のスキーマ変換規則９００各々にしたがって、変更履歴７００に含まれるエントリのデータをスキーマ変換する。そして、変換結果に、当該変換に用いたスキーマ変換規則９００に付されているアプリケーションＩＤ８０５を付して、ＤＢ更新部３７に渡す（ステップＳ１１０６）。
【００９２】
次に、ＤＢ更新部３７は、スキーマ変換部３６より受け取ったスキーマ変換結果を、変更履歴７００に示された変更操作の種別にしたがって、当該結果に付されたアプリケーションＩＤ８０５により特定されるアプリケーションデータに反映させ、当該アプリケーションデータを更新する（ステップＳ１１０７）。
【００９３】
具体的には、変更操作の種別が「エントリ追加」の場合は、追加対象エントリのデータに対するスキーマ変換結果をアプリケーションデータに追加するように更新する。「エントリ削除」の場合は、削除対象エントリのデータに対するスキーマ変換結果をアプリケーションデータから削除するように更新する。「エントリ属性値変更」の場合は、アプリケーションデータから属性値変更前の対象エントリのデータに対するスキーマ変換結果を削除し、アプリケーションデータに属性値変更後の対象エントリのデータに対するスキーマ変換結果を追加するように更新する。「ＤＮ変更」の場合は、アプリケーションデータから変更前のＤＮにより特定されるエントリのデータを削除し、アプリケーションデータに変更後のＤＮにより特定されるエントリのデータを追加するように更新する。
【００９４】
なお、たとえば、図２において、アプリケーションサーバプログラム５７がＬＤＡＰディレクトリサーバプログラムである場合、スキーマ変換後の変更履歴７００よりＬＤＡＰ更新要求を生成する。アプリケーションサーバプログラム５７がＳＱＬ（Structured Query Language）サーバプログラムである場合、スキーマ変換後の変更履歴７００からＳＱＬを生成する。
【００９５】
次に、図１６に示すステップＳ１１０３での処理（履歴情報フィルタリング処理）の詳細について説明する。
【００９６】
図１８は、図１６に示すステップＳ１１０３での処理（履歴情報フィルタリング処理）を説明するためのフロー図である。
【００９７】
変更履歴フィルタリング部３３は、先ず、変更履歴取得部３１より受け取った変更履歴７００の変更操作種別７０１が、「エントリ追加」を示す「ａｄｄ」であるか否かを確認する（ステップＳ１２０１）。「ａｄｄ」である場合は、当該変更履歴７００に対して後述のＡＤＤフィルタリングを行う（Ｓ１２０２）。
【００９８】
変更操作種別７０１が「ａｄｄ」でない場合は、当該変更操作種別７０１が、「エントリ削除」を示す「ｄｅｌｅｔｅ」であるか否かを確認する（ステップＳ１２０３）。「ｄｅｌｅｔｅ」である場合は、当該変更履歴７００に対して後述のＤＥＬフィルタリングを行う（ステップＳ１２０４）。
【００９９】
変更操作種別７０１が「ｄｅｌｅｔｅ」でない場合は、当該変更操作種別７０１が、「エントリ変更」を示す「ｍｏｄｉｆｙ」であるか否かを確認する（ステップＳ１２０５）。「ｍｏｄｉｆｙ」である場合は、当該変更履歴７００に対して後述のＭＯＤフィルタリングを行う（ステップＳ１２０６）。
【０１００】
変更操作種別７０１が「ｍｏｄｉｆｙ」でない場合は、当該変更操作種別７０１は「ＤＮ変更」を示す「ｒｅｎａｍｅ」であるとみなし、当該変更履歴７００に対して、後述のＲＥＮＡＭＥフィルタリングを行う（ステップＳ１２０７）。
【０１０１】
次に、図１８に示すステップＳ１２０２での処理（ＡＤＤフィルタリング処理）の詳細について説明する。
【０１０２】
図１９は、図１８に示すステップＳ１２０２での処理（ＡＤＤフィルタリング処理）を説明するためのフロー図である。
【０１０３】
変更履歴フィルタリング部３３は、先ず、変更履歴７００より対象エントリＤＮ７０２および変更内容詳細７０４を取り出して、図２０に示すような、追加されたエントリの情報（追加エントリ情報）を作成する（ステップＳ１３０１）。
【０１０４】
次に、作成した追加エントリ情報に対して後述するエントリ情報フィルタリングを行い、変更履歴７００が条件を満たしているフィルタリング規則８００を検出する（ステップＳ１３０２）。そして、検出したフィルタリング規則８００に記述されているアプリケーションＩＤ８０１および変換規則ＩＤ８０５の組からなるＩＤリストを作成し（フィルタリング規則８００が検出されなかった場合、ＩＤリストは空欄となる）、これを変更履歴７００とともに変換規則決定部３５に渡す（ステップＳ１３０３）。
【０１０５】
次に、図１８に示すステップＳ１２０４での処理（ＤＥＬフィルタリング処理）の詳細について説明する。
【０１０６】
図２１は、図１８に示すステップＳ１２０４での処理（ＤＥＬフィルタリング処理）を説明するためのフロー図である。
【０１０７】
変更履歴フィルタリング部３３は、先ず、変更履歴７００より対象エントリＤＮ７０２および対象エントリ属性７０３を取り出して、図２２に示すような、削除されたエントリの情報（削除エントリ情報）を作成する（ステップＳ１４０１）。
【０１０８】
次に、作成した削除エントリ情報に対して後述するエントリ情報フィルタリングを行い、変更履歴７００が条件を満たしているフィルタリング規則８００を検出する（ステップＳ１４０２）。そして、検出したフィルタリング規則８００に記述されているアプリケーションＩＤ８０１および変換規則ＩＤ８０５の組からなるＩＤリストを作成し（フィルタリング規則８００が検出されなかった場合、ＩＤリストは空欄となる）、これを変更履歴７００とともに変換規則決定部３５に渡す（ステップＳ１４０３）。
【０１０９】
次に、図１８に示すステップＳ１２０６での処理（ＭＯＤフィルタリング処理）の詳細について説明する。
【０１１０】
図２３は、図１８に示すステップＳ１２０６での処理（ＭＯＤフィルタリング処理）を説明するためのフロー図である。
【０１１１】
変更履歴フィルタリング部３３は、先ず、変更履歴７００より対象エントリＤＮ７０２および対象エントリ属性７０３を取り出して、図２４に示すような、変更されたエントリの属性変更前の情報（属性変更前エントリ情報）を作成する（ステップＳ１５０１）。次に、作成した属性変更前エントリ情報に対して後述するエントリ情報フィルタリングを行い、変更履歴７００が条件を満たしているフィルタリング規則８００を検出する（ステップＳ１５０２）。そして、検出したフィルタリング規則８００に記述されているアプリケーションＩＤ８０１および変換規則ＩＤ８０５の組からなるＩＤリスト（ＩＤリスト▲１▼とする）を作成する（ステップＳ１５０３）。
【０１１２】
次に、変更履歴フィルタリング部３３は、変更履歴７００より対象エントリＤＮ７０２および変更内容詳細７０４を取り出して、図２５に示すような、変更されたエントリの属性変更後の情報（属性変更後エントリ情報）を作成する（ステップＳ１５０４）。次に、作成した属性変更後エントリ情報に対して後述するエントリ情報フィルタリングを行い、変更履歴７００が条件を満たしているフィルタリング規則８００を検出する（ステップＳ１５０５）。そして、検出したフィルタリング規則８００に記述されているアプリケーションＩＤ８０１および変換規則ＩＤ８０５の組からなるＩＤリスト（ＩＤリスト▲２▼とする）を作成する（ステップＳ１５０６）。
【０１１３】
次に、変更履歴フィルタリング部３３は、作成したＩＤリスト▲１▼とＩＤリスト▲２▼とを比較し（ステップＳ１５０７、１５０８）、両者が同一である場合は、ＩＤリスト▲１▼を変更履歴７００とともに変換規則決定部３５に渡す（ステップＳ１５０９）。
【０１１４】
一方、両者が同一でない場合は、属性変更前の対象エントリのデータに用いるスキーマ変換規則と、属性変更後の対象エントリのデータに用いるスキーマ変換規則とが異なることを意味する。なお、スキーマ変換規則の変更は、たとえば、フィルタリング規則８００のＦｉｌｔｅｒ８０４に記述された判定条件に用いられる属性値が変更された場合に発生し得る。
【０１１５】
この場合は、「属性値変更」操作の変更履歴７００より、属性値変更前の対象エントリを削除することを意味する「エントリ削除」操作の変更履歴（変更履歴▲１▼とする）と、属性値変更後の対象エントリを追加することを意味する「エントリ追加」操作の変更履歴（変更履歴▲２▼とする）とを作成し（ステップＳ１５１０）、変更履歴▲１▼にはＩＤリスト▲１▼を付し、変更履歴▲２▼にはＩＤリスト▲２▼を付して、変換規則決定部３５に渡す（ステップＳ１５１１）。
【０１１６】
ここで、「属性値変更」操作の変更履歴７００より「エントリ削除」操作の変更履歴▲１▼と、「エントリ追加」操作の変更履歴▲２▼とを作成する処理（変更履歴分割処理とする）について説明する。図２６は、図２３に示すステップＳ１５１０での変更履歴分割処理を説明するための図である。
【０１１７】
図示するように、変更履歴▲１▼は、変更履歴７００の変更操作種別７０１を「ｍｏｄｉｆｙ」から「ｄｅｌｅｔｅ」に変更することで作成される。変更履歴▲２▼は、変更履歴７００の変更操作種別７０１を「ｍｏｄｉｆｙ」から「ａｄｄ」に変更するとともに、変更内容詳細７０４を、上述した図７に示す形式（属性値変更の場合）から図８に示す形式（エントリ追加の場合）に変更することで作成される。なお、この場合、図８に示す変更内容詳細７０４の属性名７０３には属性変更後の属性名が記入され、属性値７１２には、属性変更後の属性値が記入されることになる。
【０１１８】
次に、図１８に示すステップＳ１２０７での処理（ＲＥＮＡＭＥフィルタリング処理）の詳細について説明する。
【０１１９】
図２７は、図１８に示すステップＳ１２０７での処理（ＲＥＮＡＭＥフィルタリング処理）を説明するためのフロー図である。
【０１２０】
変更履歴フィルタリング部３３は、先ず、変更履歴７００より対象エントリＤＮ７０２および対象エントリ属性７０３を取り出して、図２８に示すような、対象となるエントリのＤＮ変更前の情報（ＤＮ変更前エントリ情報）を作成する（ステップＳ１６０１）。次に、作成したＤＮ変更前エントリ情報に対して後述するエントリ情報フィルタリングを行い、変更履歴７００が条件を満たしているフィルタリング規則８００を検出する（ステップＳ１６０２）。そして、検出したフィルタリング規則８００に記述されているアプリケーションＩＤ８０１および変換規則ＩＤ８０５の組からなるＩＤリスト（ＩＤリスト▲３▼とする）を作成する（ステップＳ１６０３）。
【０１２１】
次に、変更履歴フィルタリング部３３は、変更履歴７００より新ＲＤＮ７０５、新上位ＤＮ７０６および変更内容詳細７０４を取り出して、図２９に示すような、対象となるエントリのＤＮ変更後の情報（ＤＮ変更後エントリ情報）を作成する（ステップＳ１６０４）。次に、作成したＤＮ変更後エントリ情報に対して後述するエントリ情報フィルタリングを行い、変更履歴７００が条件を満たしているフィルタリング規則８００を検出する（ステップＳ１６０５）。そして、検出したフィルタリング規則８００に記述されているアプリケーションＩＤ８０１および変換規則ＩＤ８０５の組からなるＩＤリスト（ＩＤリスト▲４▼とする）を作成する（ステップＳ１６０６）。
【０１２２】
次に、変更履歴フィルタリング部３３は、作成したＩＤリスト▲３▼とＩＤリスト▲４▼とを比較し（ステップＳ１６０７、１６０８）、両者が同一である場合は、ＩＤリスト▲３▼を変更履歴７００とともに変換規則決定部３５に渡す（ステップＳ１６０９）。
【０１２３】
一方、両者が同一でない場合は、ＤＮ変更前の対象エントリのデータに用いるスキーマ変換規則と、ＤＮ変更後の対象エントリのデータに用いるスキーマ変換規則とが異なることを意味する。
【０１２４】
この場合は、「ＤＮ変更」操作の変更履歴７００より、ＤＮ変更前の対象エントリを削除することを意味する「エントリ削除」操作の変更履歴（変更履歴▲３▼とする）と、ＤＮ変更後の対象エントリを追加することを意味する「エントリ追加」操作の変更履歴（変更履歴▲４▼とする）とを作成し（ステップＳ１６１０）、変更履歴▲３▼にはＩＤリスト▲３▼を付し、変更履歴▲４▼にはＩＤリスト▲４▼を付して、変換規則決定部３５に渡す（ステップＳ１６１１）。
【０１２５】
ここで、「ＤＮ変更」操作の変更履歴７００より「エントリ削除」操作の変更履歴▲３▼と、「エントリ追加」操作の変更履歴▲４▼とを作成する処理（変更履歴分割処理とする）について説明する。図３０は、図２７に示すステップＳ１６１０での変更履歴分割処理を説明するための図である。
【０１２６】
図示するように、変更履歴▲３▼は、変更履歴７００の変更操作種別７０１を「ｒｅｎａｍｅ」から「ｄｅｌｅｔｅ」に変更することで作成される。変更履歴▲４▼は、変更履歴７００の変更操作種別７０１を「ｒｅｎａｍｅ」から「ａｄｄ」に変更するとともに、対象エントリＤＮ７０２を新ＲＤＮ７０５および上位ＤＮ７０６より特定される新ＤＮに変更して、変更履歴７００より新ＲＤＮ７０５および上位ＤＮ７０６を削除し、さらに、変更内容詳細７０４を、上述した図７に示す形式（ＤＮ変更の場合）から図８に示す形式（エントリ追加の場合）に変更することで作成される。なお、この場合、図８に示す変更内容詳細７０４の属性名７０３にはＤＮ変更後のエントリの属性名が記入され、属性値７１２には、ＤＮ変更後のエントリの属性値が記入されることになる。
【０１２７】
次に、図１９、図２１、図２３および図２７に示す各フローでのエントリ情報フィルタリング処理の詳細について説明する。
【０１２８】
図３１は、図１９、図２１、図２３および図２７に示す各フローでのエントリ情報フィルタリング処理を説明するためのフロー図である。
【０１２９】
変更履歴フィルタリング部３３は、先ず、フィルタリング規則テーブル３２より未取得のフィルタリング規則８００を１つ取得する（ステップＳ２１０１）。この際、既に、フィルタリング規則テーブル３２より全てのフィルタリング規則８００を取得済みの場合は、処理を終了する（ステップＳ２１０２）。
【０１３０】
次に、変更履歴フィルタリング部３３は、フィルタリング規則８００を取得すると、変更履歴の対象エントリＤＮ７０２に記述されたＤＮが、取得したフィルタリング規則８００のＢａｓｅｄｎ８０２およびＳｃｏｐｅ８０３が定めるエントリの範囲内に存在するか否かを調べる（ステップＳ２１０３）。存在しない場合は、ステップ２１０１に戻って、フィルタリング規則テーブル３２より未取得のフィルタリング規則８００を１つ取得する。
【０１３１】
一方、存在する場合は、変更履歴に記述された属性のデータがフィルタリング規則８００のＦｉｌｔｅｒ８０４が定める条件を満足しているか否かを調べる（ステップＳ２１０５）。ここで、変更履歴に記述された属性のデータとは、変更操作種別７０１が「エントリ追加」操作の場合は変更内容詳細７０４に記述された属性のデータが相当し、「エントリ削除」操作の場合は対象エントリ属性７０３に記述された属性のデータが相当する。なお、変更履歴の変更操作種別７０１が「属性値変更」あるいは「ＤＮ変更」操作の場合は、上述したように、変更履歴分割処理により、「エントリ追加」および「エントリ削除」操作の変更履歴に分割されるので、エントリ情報フィルタリング処理の対象となる変更履歴は、「エントリ追加」あるいは「エントリ削除」のいずれかに限定される。
【０１３２】
上記のステップＳ２１０５において、変更履歴に記述された属性のデータがフィルタリング規則８００のＦｉｌｔｅｒ８０４が定める条件を満足している場合は、このフィルタリング規則８００に記述されているアプリケーションＩＤ８０１および変換規則ＩＤ８０５を組としてＩＤリストへ追加し、その後、ステップＳ２１０１に戻る。一方、満足していない場合は、直ちにステップＳ２１０１に戻る。
【０１３３】
以上、本発明の１実施形態について説明した。
【０１３４】
本実施形態では、ディレクトリデータについて、任意のアプリケーションデータに反映させたいエントリをフィルタリング規則によって指定することで、任意のエントリを選択的に任意のアプリケーションに反映させることができる。また、指定したエントリまたはエントリの集合に対して任意のスキーマ変換規則を割り当てることで、エントリまたはエントリの集合毎に異なる規則でスキーマ変換を行うことができる。したがって、本実施形態によれば、ディレクトリデータとアプリケーションデータの対象オブジェクトやスキーマが異なる場合でも、ディレクトリデータおよびアプリケーションデータ間の同期が可能となる。
【０１３５】
また、あるエントリを複数のフィルタリング規則で指定させ、これにより複数のスキーマ変換規則を割り当てることで、企業全体の情報を格納するディレクトリツリー全体に対し、全社的標準スキーマ変換規則を適用し、各部門の情報を格納するサブツリーに対し、全社的標準スキーマ変換規則に加えて部門独自のスキーマ変換規則を適用するといった処理が可能になる。これにより、スキーマ変換規則の管理負荷を分散させることが可能になる。
【０１３６】
なお、本発明は上記の実施形態に限定されるものではなく、その要旨の範囲内で数々の変形が可能である。
【０１３７】
たとえば、図２に示す本実施形態のハードウエア構成例では、ディレクトリサーバ１、アプリケーションサーバ２およびディレクトリデータ変換サーバ３が、各々、別個の情報処理装置上で実現されている場合を示しているが、これに限定されるものではない。たとえば、ディレクトリサーバ１として機能する情報処理装置４の磁気ディスク４３にディレクトリデータ変換プログラム６８、フィルタリング規則ファイル６６およびスキーマ変換規則ファイル６７を格納させ、ＣＰＵ４２にディレクトリデータ変換プログラム６８を実行させることで、情報処理装置４がディレクトリサーバ１兼ディレクトリデータ変換サーバ３として機能するようにしてもよい。あるいは、アプリケーションサーバ２として機能する情報処理装置５の磁気ディスク５３にディレクトリデータ変換プログラム６８、フィルタリング規則ファイル６６およびスキーマ変換規則ファイル６７を格納させ、ＣＰＵ５２にディレクトリデータ変換プログラム６８を実行させることで、情報処理装置５がアプリケーションサーバ２兼ディレクトリデータ変換サーバ３として機能するようにしてもよい。さらには、１つの情報処理装置が、ディレクトリサーバ１兼アプリケーションサーバ２兼ディレクトリデータ変換サーバ３として機能するようにしてもよい。
【０１３８】
また、上記の実施形態において、変更履歴取得部３１は、変更履歴を古いものから順に１つづつ取得するようにしているが、プログラム実行の効率化のため複数の変更履歴をまとめて取得するようにしてもよい。
【０１３９】
さらに、上記の実施形態では、ディレクトリデータに対して加えられた変更をアプリケーションデータに反映させる場合（変更履歴による差分更新）を例にとり説明したが、本発明はディレクトリデータ自体をアプリケーションデータへ変換する際にも利用可能である。
【０１４０】
【発明の効果】
以上説明したように、本発明によれば、ディレクトリデータの任意のエントリを選択的にアプリケーションデータへ反映させることができる。
【図面の簡単な説明】
【図１】本発明の１実施形態が適用されたディレクトリサービスシステムの機能構成図である。
【図２】図１に示すディレクトリサービスシステムを実現するためのハードウエア構成の一例を示した図である。
【図３】図１に示すディレクトリサービスシステムの概略動作を説明するための図である。
【図４】ディレクトリサービス部１２がディレクトリデータに対して行う変更操作の一覧を示す図である。
【図５】ディレクトリサービス部１２がディレクトリデータに対して変更操作を行う度に作成し、ディレクトリデータＤＢ１１に記録する変更履歴の内容を示す図である。
【図６】図５の対象エントリ属性７０３に格納される内容を示す図である。
【図７】変更操作が「エントリ属性変更」あるいは「ＤＮ変更」である場合における図５の変更内容詳細７０４の内容を示す図である。
【図８】変更操作が「エントリ追加」である場合における図５の変更内容詳細７０４の内容を示す図である。
【図９】図３において、社員甲を表すエントリ５０４の属性に変更を加えた場合に作成される変更履歴を示す図である。
【図１０】フィルタリング規則テーブル３２に記憶されるフィルタリング規則の内容を示す図である。
【図１１】図１０のＳｃｏｐｅ８０３がとり得る値と意味を示す図である。
【図１２】図３において、社員甲を表すエントリ５０４に対して行われた変更をアプリケーションサーバ２ａのアプリケーションデータに反映させるためのフィルタリング規則の一例を示す図である。
【図１３】スキーマ変換規則テーブル３４に記憶されるスキーマ変換規則の内容を示す図である。
【図１４】図１３の属性変換規則９０２を説明するための図である。
【図１５】図３において、社員甲を表すエントリ５０４に対して行われた変更をアプリケーションサーバ２ａのアプリケーションデータに反映させるためのスキーマ変換規則の一例を示す図である。
【図１６】ディレクトリデータ変換サーバ３の動作を説明するためのフロー図である。
【図１７】変更履歴フィルタリング部３３にて作成されるＩＤリストの一例を示す図である。
【図１８】図１６に示すステップＳ１１０３での処理（履歴情報フィルタリング処理）を説明するためのフロー図である。
【図１９】図１８に示すステップＳ１２０２での処理（ＡＤＤフィルタリング処理）を説明するためのフロー図である。
【図２０】図１９に示すフローにて作成される追加エントリ情報を示す図である。
【図２１】図１８に示すステップＳ１２０４での処理（ＤＥＬフィルタリング処理）を説明するためのフロー図である。
【図２２】図２１に示すフローにて作成される削除エントリ情報を示す図である。
【図２３】図１８に示すステップＳ１２０６での処理（ＭＯＤフィルタリング処理）を説明するためのフロー図である。
【図２４】図２３に示すフローにて作成される属性変更前エントリ情報を示す図である。
【図２５】図２３に示すフローにて作成される属性変更後エントリ情報を示す図である。
【図２６】図２３に示すステップＳ１５１０での変更履歴分割処理を説明するための図である。
【図２７】図１８に示すステップＳ１２０７での処理（ＲＥＮＡＭＥフィルタリング処理）を説明するためのフロー図である。
【図２８】図２７に示すフローにて作成されるＤＮ変更前エントリ情報を示す図である。
【図２９】図２７に示すフローにて作成されるＤＮ変更後エントリ情報を示す図である。
【図３０】図２７に示すステップＳ１６１０での変更履歴分割処理を説明するための図である。
【図３１】図１９、図２１、図２３および図２７に示す各フローでのエントリ情報フィルタリング処理を説明するためのフロー図である。
【符号の説明】
１  ディレクトリサーバ
２ａ，２ｂ  アプリケーションサーバ
３  ディレクトリデータ変換サーバ
４〜６  情報処理装置
１１  ディレクトリデータＤＢ
１２  ディレクトリサービス部
２１  アプリケーションデータＤＢ
２２  アプリケーションサービス部
３１  変更履歴取得部
３２  フィルタリング規則テーブル
３３  変更履歴フィルタリング部
３４  スキーマ変換規則テーブル
３５  変換規則決定部
３６  スキーマ変換部
３７  ＤＢ更新部
４１、５１、６１  メモリ
４２、５２、６２  ＣＰＵ
４３、５３、６３  磁気ディスク
４４、５４、６４  ディスクコントローラ
４５、５５、６５  ＬＡＮコントローラ
４８、５８、６８  ＯＳ
４６  ディレクトリデータ
４７  ディレクトリサーバプログラム
５６  アプリケーションデータ
５７  アプリケーションサーバプログラム
６６  フィルタリング規則ファイル
６７  スキーマ変換規則ファイル
６８  ディレクトリデータ変換プログラム
６９  変更履歴取得プログラム
７０  変更履歴フィルタリングプログラム
７１  変換規則決定プログラム
７２  スキーマ変換プログラム
７３  ＤＢ更新プログラム
１００  ＬＡＮ
【図１】
0003792419.tif 000002
【図２】
0003792419.tif 000003
【図３】
0003792419.tif 000004
【図４】
0003792419.tif 000005
【図５】
0003792419.tif 000006
【図６】
0003792419.tif 000007
【図７】
0003792419.tif 000008
【図８】
0003792419.tif 000009
【図９】
0003792419.tif 000010
【図１０】
0003792419.tif 000011
【図１１】
0003792419.tif 000012
【図１２】
0003792419.tif 000013
【図１３】
0003792419.tif 000014
【図１４】
0003792419.tif 000015
【図１５】
0003792419.tif 000016
【図１６】
0003792419.tif 000017
【図１７】
0003792419.tif 000018
【図１８】
0003792419.tif 000019
【図１９】
0003792419.tif 000020
【図２０】
0003792419.tif 000021
【図２１】
0003792419.tif 000022
【図２２】
0003792419.tif 000023
【図２３】
0003792419.tif 000024
【図２４】
0003792419.tif 000025
【図２５】
0003792419.tif 000026
【図２６】
0003792419.tif 000027
【図２７】
0003792419.tif 000028
【図２８】
0003792419.tif 000029
【図２９】
0003792419.tif 000030
【図３０】
0003792419.tif 000031
【図３１】
0003792419.tif 000032