(57)【要約】  複数のリソースを分散して管理し、管理する複数のリソースに関する情報であるリソース情報を通知する複数の機器と接続されることができる情報処理装置であって、複数のリソースのうち、所定のリソースを指定する指定情報を受け付ける指定情報受付部と、指定情報受付部により受け付けられた指定情報に基づいて、複数の機器のうち、指定情報により指定されるリソースを管理する機器を判定する判定部と、判定部により、指定情報により指定されるリソースを管理すると判定された機器に指定情報を通知する指定情報通知部と、すでに通知されたリソース情報に基づいて、複数のリソース情報間を関連付ける関連付け部と、関連付け部により関連付けられた複数のリソース情報間の関連に基づいて、リソース情報に対して所定の処理を実行するリソース情報処理部と  を備えた。
2010001482.tif 000002
【特許請求の範囲】
【請求項１】
複数のリソースを分散して管理し、管理する前記複数のリソースに関する情報であるリソース情報を通知する複数の機器と接続されることができる情報処理装置であって、
前記複数のリソースのうち、所定のリソースを指定する指定情報を受け付ける指定情報受付部と、
前記指定情報受付部により受け付けられた指定情報に基づいて、前記複数の機器のうち、前記指定情報により指定されるリソースを管理する機器を判定する判定部と、
前記判定部により、前記指定情報により指定されるリソースを管理すると判定された機器に前記指定情報を通知する指定情報通知部と、
すでに通知されたリソース情報に基づいて、複数のリソース情報間を関連付ける関連付け部と、
前記関連付け部により関連付けられた前記複数のリソース情報間の関連に基づいて、前記リソース情報に対して所定の処理を実行するリソース情報処理部と
を備える情報処理装置。
【請求項２】
請求項１に記載の情報処理装置において、
前記リソース情報処理部による前記所定の処理は、前記複数のリソース情報間の関連に基づき、リソース情報が関するリソースが同一である複数のリソース情報のうち、先行するリソース情報を通知し、後続するリソース情報を廃棄する処理であることを特徴とする情報処理装置。
【請求項３】
請求項１に記載の情報処理装置において、
前記リソース情報処理部による前記所定の処理は、前記複数のリソース情報間の関連に基づき、相互に関連を持つ複数の異なるリソース情報の内容を複合したリソース情報を作成する処理であることを特徴とする情報処理装置。
【請求項４】
請求項１に記載の情報処理装置において、
前記リソース情報処理部による前記所定の処理は、前記複数のリソース情報間の関連に基づき、相互に関連を持つ複数の異なるリソース情報のうち、先行するリソース情報の通知に伴い関連を持って通知されることが予測されている後続のリソース情報が関するリソースを管理する機器に対し、前記後続のリソース情報の通知を督促することを特徴とする情報処理装置。
【請求項５】
請求項１に記載の情報処理装置において、
前記判定部は、前記リソースと該リソースを管理する機器とが対応付けられた情報である機器情報に基づいて、前記指定情報により指定されるリソースを管理する機器を判定することを特徴とする情報処理装置。
【請求項６】
請求項１に記載の情報処理装置において、
前記関連付け部による、前記複数のリソース情報間の関連付けは、所定のリソース情報と該所定のリソース情報とは異なるリソース情報であって、両リソース情報が関するリソースのデータ構造上の距離が所定の範囲内であるようなものの組み合わせが所定の時間内に出現する頻度に基づいてなされることを特徴とする情報処理装置。
【請求項７】
請求項５記載の情報処理装置において、
前記機器情報は、前記複数のリソースの相互関係に関する階層構造を持つ情報であり、
前記判定部は、前記指定情報により指定されるリソースに対応する機器情報が無い場合、前記機器情報の階層構造により前記指定情報により指定されるリソースの親にあたるリソースを判断し、該親にあたるリソースを管理する機器の判定を継承して、該リソースを管理する機器の判定をすることを特徴とする情報処理装置。
【請求項８】
複数のリソースを分散して管理し、管理する前記複数のリソースに関する情報であるリソース情報を通知する複数の機器と接続されることができる情報処理装置における情報処理プログラムであって、
前記複数のリソースのうち、所定のリソースを指定する指定情報を受け付ける指定情報受付ステップと、
前記指定情報受付ステップにより受け付けられた指定情報に基づいて、前記複数の機器のうち、前記指定情報により指定されるリソースを管理する機器を判定する判定ステップと、
前記判定ステップにより、前記指定情報により指定されるリソースを管理すると判定された機器に前記指定情報を通知する指定情報通知ステップと、
すでに通知されたリソース情報に基づいて、複数のリソース情報間を関連付ける関連付けステップと、
前記関連付けステップにより関連付けられた前記複数のリソース情報間の関連に基づいて、前記リソース情報に対して所定の処理を実行するリソース情報処理ステップと
をコンピュータに実行させる情報処理プログラム。
【請求項９】
請求項８に記載の情報処理プログラムにおいて、
前記リソース情報処理ステップによる前記所定の処理は、前記複数のリソース情報間の関連に基づき、リソース情報が関するリソースが同一である複数のリソース情報のうち、先行するリソース情報を通知し、後続するリソース情報を廃棄する処理であることを特徴とする情報処理プログラム。
【請求項１０】
請求項８に記載の情報処理プログラムにおいて、
前記リソース情報処理ステップによる前記所定の処理は、前記複数のリソース情報間の関連に基づき、相互に関連を持つ複数の異なるリソース情報の内容を複合したリソース情報を作成する処理であることを特徴とする情報処理プログラム。
【請求項１１】
請求項８に記載の情報処理プログラムにおいて、
前記リソース情報処理ステップによる前記所定の処理は、前記複数のリソース情報間の関連に基づき、相互に関連を持つ複数の異なるリソース情報のうち、先行するリソース情報の通知に伴い関連を持って通知されることが予測されている後続のリソース情報が関するリソースを管理する機器に対し、前記後続のリソース情報の通知を督促することを特徴とする情報処理プログラム。
【請求項１２】
請求項８に記載の情報処理プログラムにおいて、
前記判定ステップは、前記リソースと該リソースを管理する機器とが対応付けられた情報である機器情報に基づいて、前記指定情報により指定されるリソースを管理する機器を判定することを特徴とする情報処理プログラム。
【請求項１３】
請求項８に記載の情報処理プログラムにおいて、
前記関連付けステップによる、前記複数のリソース情報間の関連付けは、所定のリソース情報と該所定のリソース情報とは異なるリソース情報であって、両リソース情報が関するリソースのデータ構造上の距離が所定の範囲内であるものの組み合わせが所定の時間内に出現する頻度に基づいてなされることを特徴とする情報処理プログラム。
【請求項１４】
請求項１２に記載の情報処理プログラムにおいて、
前記機器情報は、前記複数のリソースの相互関係に関する階層構造を持つ情報であり、
前記判定ステップは、前記指定情報により指定されるリソースに対応する機器情報が無い場合、前記機器情報の階層構造により前記指定情報により指定されるリソースの親にあたるリソースを判断し、該親にあたるリソースを管理する機器の判定を継承して、該リソースを管理する機器の判定をすることを特徴とする情報処理プログラム。
【請求項１５】
複数のリソースを分散して管理し、管理する前記複数のリソースに関する情報であるリソース情報を通知する複数の機器と接続されることができる情報処理装置における情報処理方法であって、
前記複数のリソースのうち、所定のリソースを指定する指定情報を受け付ける指定情報受付ステップと、
前記指定情報受付ステップにより受け付けられた指定情報に基づいて、前記複数の機器のうち、前記指定情報により指定されるリソースを管理する機器を判定する判定ステップと、
前記判定ステップにより、前記指定情報により指定されるリソースを管理すると判定された機器に前記指定情報を通知する指定情報通知ステップと、
すでに通知されたリソース情報に基づいて、複数のリソース情報間を関連付ける関連付けステップと、
前記関連付けステップにより関連付けられた前記複数のリソース情報間の関連に基づいて、前記リソース情報に対して所定の処理を実行するリソース情報処理ステップと
を備える情報処理方法。
【請求項１６】
請求項１５に記載の情報処理方法において、
前記リソース情報処理ステップによる前記所定の処理は、前記複数のリソース情報間の関連に基づき、リソース情報が関するリソースが同一である複数のリソース情報のうち、先行するリソース情報を通知し、後続するリソース情報を廃棄する処理であることを特徴とする情報処理方法。
【請求項１７】
請求項１５に記載の情報処理方法において、
前記リソース情報処理ステップによる前記所定の処理は、前記複数のリソース情報間の関連に基づき、相互に関連を持つ複数の異なるリソース情報の内容を複合したリソース情報を作成する処理であることを特徴とする情報処理方法。
【請求項１８】
請求項１５に記載の情報処理方法において、
前記リソース情報処理ステップによる前記所定の処理は、前記複数のリソース情報間の関連に基づき、相互に関連を持つ複数の異なるリソース情報のうち、先行するリソース情報の通知に伴い関連を持って通知されることが予測されている後続のリソース情報が関するリソースを管理する機器に対し、前記後続のリソース情報の通知を督促することを特徴とする情報処理方法。
【請求項１９】
請求項１５に記載の情報処理方法において、
前記判定ステップは、前記リソースと該リソースを管理する機器に関する情報である機器情報に基づいて、前記指定情報により指定されるリソースを管理する機器を判定することを特徴とする情報処理方法。
【請求項２０】
請求項１５に記載の情報処理方法において、
前記関連付けステップによる、前記複数のリソース情報間の関連付けは、所定のリソース情報と該所定のリソース情報とは異なるリソース情報であって、両リソース情報が関するリソースのデータ構造上の距離が所定の範囲内であるものの組み合わせが所定の時間内に出現する頻度に基づいてなされることを特徴とする情報処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報システムを構成する情報を統合管理するＦＣＭＤＢに関するものである。
【背景技術】
【０００２】
情報システムを構成するハードウェア及びソフトウェアに関する情報を管理する複数種類のデータベースを仮想統合することにより、システムを構成するリソースの情報（構成情報）を管理するデータベースとして、ＦＣＭＤＢシステム（Ｆｅｄｅｒａｔｅｄ  Ｃｏｎｆｉｇｕｒａｔｉｏｎ  Ｍａｎａｇｅｍｅｎｔ  Ｄａｔａｂａｓｅ  システム）が知られている。図１９に示すように、ＦＣＭＤＢシステムは、構成情報を保持する要素データベースであるＭＤＲ（Ｍａｎａｇｅｍｅｎｔ  Ｄａｔａ  Ｒｅｐｏｓｉｔｏｒｙ）とそれらを統合管理するデータベースＦＣＭＤＢで構成される。【０００３】
また、構成情報は、複数のＭＤＲに分散、重複して管理される。ＦＣＭＤＢは、ＭＤＲから情報の登録を受けて情報システム全体の構成情報を値もしくは情報の所在（ポインタ）で管理する。【０００４】
ＦＣＭＤＢでは、複数のＭＤＲから登録された情報を各項目について名寄せし、重複か否かを判定し、どの情報を主情報として保持するかを判断し、どのＭＤＲが主でありどのＭＤＲが副であるかのメタ情報を保持する。【０００５】
ＦＣＭＤＢシステムのクライアントは、図２０に示す、ｐｕｂ／ｓｕｂ（ｐｕｂｌｉｓｈ／ｓｕｂｓｃｒｉｂｅ）型の枠組みを用いて、ＦＣＭＤＢシステムから情報を読み出して利用する。クライアントは、Ｓｕｂｓｃｒｉｂｅｒとして監視対象の構成情報に対する監視の依頼を通達する（Ｓｕｂｓｃｒｉｐｔｉｏｎ、指定情報）。監視の時間的精度がＦＣＭＤＢ−ＭＤＲ間の情報更新頻度に影響されないよう管理元であるＭＤＲがＰｕｂｌｉｓｈｅｒとしてイベント発生に応じたＮｏｔｉｆｉｃａｔｉｏｎを発行する。ＦＣＭＤＢは、Ｂｒｏｋｅｒとしてクライアント（Ｓｕｂｓｃｒｉｂｅｒ）とＭＤＲ（Ｐｕｂｌｉｓｈｅｒ）とを仲介し、構成情報の監視依頼に応じたイベント発生に係わるメッセージを通知する（Ｎｏｔｉｆｉｃａｔｉｏｎ、リソース情報）。なお、ｐｕｂ／ｓｕｂ（ｐｕｂｌｉｓｈ／ｓｕｂｓｃｒｉｂｅ）型の枠組みにおいて、ＰｕｂｌｉｓｈｅｒとＳｕｂｓｃｒｉｂｅｒとを結びつける働きをするＢｒｏｋｅｒの役割の一部をＰｕｂｌｉｓｈｅｒやＳｕｂｓｃｒｉｂｅｒが行うことがあるが、ＦＣＭＤＢシステムにおいてもＰｕｂｌｉｓｈｅｒであるＭＤＲは、予め通達されたＳｕｂｓｃｒｉｐｔｉｏｎの内容に対応したＮｏｔｉｆｉｃａｔｉｏｎのみに絞り込んでメッセージを発行する。【０００６】
なお、本発明の関連ある従来技術として、複合Ｓｕｂｓｃｒｉｐｔｉｏｎを分配し、複数のＮｏｔｉｆｉｃａｔｉｏｎを複合させるためのロジックを登録する手法が開示されている（例えば、特許文献１参照）
【特許文献１】特開２００４−３４８６８０号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
しかしながら、Ｓｕｂｓｃｒｉｐｔｉｏｎは全てのＭＤＲへ通達されるため、監視依頼の対象である構成情報を保持しないＭＤＲや、監視依頼の対象である構成情報を保持しているが他のＭＤＲと重複しているためＦＣＭＤＢのポリシによりこのＭＤＲからの更新が受け付けられない場合など、Ｓｕｂｓｃｒｉｐｔｉｏｎの内容と無関係なＭＤＲにおいて、不要な構成情報の監視処理が生じる。【０００８】
また、複数のＭＤＲで分散、重複して情報を保持するため、一つのイベントの対象となる構成情報を保持する複数のＭＤＲから同一のＮｏｔｉｆｉｃａｔｉｏｎが発行されるため不要な通信が生じる。【０００９】
さらに、複数のイベント間に関連性がある場合であっても、ＭＤＲは自身が管理する構成情報に関するイベントに応じたＮｏｔｉｆｉｃａｔｉｏｎのみ、それぞれの監視状況に沿ったタイミングでＮｏｔｉｆｉｃａｔｉｏｎを発行するため、不要な通信が発生し、Ｓｕｂｓｃｒｉｂｅｒでは、受信した複数のＮｏｔｉｆｉｃａｔｉｏｎの関連性を迅速に利用できず、待ち時間が生じる。【００１０】
また、特許文献１の技術は、その適用の前提が本課題を満たすものではない。すなわち、特許文献１の技術において、Ｓｕｂｓｃｒｉｐｔｉｏｎは明示的に複合されているわけではなく、詳細なロジックが与えられていないため、上述したＳｕｂｓｃｒｉｐｔｉｏｎの通達やＮｏｔｉｆｉｃａｔｉｏｎの配布における監視対象のチェック処理に係わる負荷の増大、重複したＮｏｔｉｆｉｃａｔｉｏｎの配布による通信量の無駄に関する課題を解決することはできない。【００１１】
本発明は上述した問題を解決するためになされたものであり、Ｓｕｂｓｃｒｉｐｔｉｏｎの通達に伴う監視対象のチェック処理の負荷の軽減、Ｎｏｔｉｆｉｃａｔｉｏｎの配布に係る通信量の軽減と構成情報に関わる複数のイベント間の関連性を活用できる情報処理装置、情報処理プログラム、情報処理方法を提供することを目的とする。
【課題を解決するための手段】
【００１２】
上述した課題を解決するため、情報処理装置は、複数のリソースを分散して管理し、管理する複数のリソースに関する情報であるリソース情報を通知する複数の機器と接続されることができる装置であって、複数のリソースのうち、所定のリソースを指定する指定情報を受け付ける指定情報受付部と、指定情報受付部により受け付けられた指定情報に基づいて、複数の機器のうち、指定情報により指定されるリソースを管理する機器を判定する判定部と、判定部により、指定情報により指定されるリソースを管理すると判定された機器に指定情報を通知する指定情報通知部と、すでに通知されたリソース情報に基づいて、複数のリソース情報間を関連付ける関連付け部と、関連付け部により関連付けられた複数のリソース情報間の関連に基づいて、リソース情報に対して所定の処理を実行するリソース情報処理部とを備えるものである。【００１３】
また、上述した課題を解決するため、情報処理プログラムは、複数のリソースを分散して管理し、管理する複数のリソースに関する情報であるリソース情報を通知する複数の機器と接続されることができる情報処理装置におけるプログラムであって、複数のリソースのうち、所定のリソースを指定する指定情報を受け付ける指定情報受付ステップと、指定情報受付ステップにより受け付けられた指定情報に基づいて、複数の機器のうち、指定情報により指定されるリソースを管理する機器を判定する判定ステップと、判定ステップにより、指定情報により指定されるリソースを管理すると判定された機器に指定情報を通知する指定情報通知ステップと、すでに通知されたリソース情報に基づいて、複数のリソース情報間を関連付ける関連付けステップと、関連付けステップにより関連付けられた複数のリソース情報間の関連に基づいて、リソース情報に対して所定の処理を実行するリソース情報処理ステップとをコンピュータに実行させるものである。【００１４】
さらに、上述した課題を解決するため、情報処理方法は、複数のリソースを分散して管理し、管理する複数のリソースに関する情報であるリソース情報を通知する複数の機器と接続されることができる情報処理装置における方法であって、複数のリソースのうち、所定のリソースを指定する指定情報を受け付ける指定情報受付ステップと、指定情報受付ステップにより受け付けられた指定情報に基づいて、複数の機器のうち、指定情報により指定されるリソースを管理する機器を判定する判定ステップと、判定ステップにより、指定情報により指定されるリソースを管理すると判定された機器に指定情報を通知する指定情報通知ステップと、すでに通知されたリソース情報に基づいて、複数のリソース情報間を関連付ける関連付けステップと、関連付けステップにより関連付けられた複数のリソース情報間の関連に基づいて、リソース情報に対して所定の処理を実行するリソース情報処理ステップとを実行するものである。
【図面の簡単な説明】
【００１５】
【図１】実施の形態に係るＦＣＭＤＢシステムの構成の概略一例を示す図である。
【図２】実施の形態に係るＦＣＭＤＢシステムの機能の概要の一例を示す図である。
【図３】実施の形態に係る構成情報ＤＢの一例を示す図である。
【図４】実施の形態に係る構成情報のＸＭＬ形式の一例を示す図である。
【図５】実施の形態に係る登録元ＤＢの一例を示す図である。
【図６】実施の形態に係る登録可能種別ＤＢの一例を示す図である。
【図７】実施の形態に係るＳｕｂｓｃｒｉｐｔｉｏｎ分配記録ＤＢの一例を示す図である。
【図８】実施の形態に係るＮｏｔｉｆｉｃａｔｉｏｎ記録ＤＢの一例を示す図である。
【図９】実施の形態に係るＮｏｔｉｆｉｃａｔｉｏｎ関連性ＤＢの一例を示す図である。
【図１０】実施の形態に係るＮｏｔｉｆｉｃａｔｉｏｎ処理待ちＤＢの一例を示す図である。
【図１１】実施の形態に係る監視対象が構造の追加の場合に関するＳｕｂｓｃｒｉｐｔｉｏｎの分配処理の概要の一例を示す図である。
【図１２】実施の形態に係る監視対象の範囲がサブツリーの場合に関するＳｕｂｓｃｒｉｐｔｉｏｎの分配処理の概要の一例を示す図である。
【図１３】実施の形態に係るＳｕｂｓｃｒｉｐｔｉｏｎの分配処理におけるＳｕｂｓｃｒｉｐｔｉｏｎ分配判定部の処理一例を示すフローチャートである。
【図１４】実施の形態に係る関連性発見部の処理の一例（その１）を示すフローチャートである。
【図１５】実施の形態に係る関連性発見部の処理の一例（その２）を示すフローチャートである。
【図１６】実施の形態に係る関連性発見部の処理の一例（その３）を示すフローチャートである。
【図１７】実施の形態に係るＮｏｔｉｆｉｃａｔｉｏｎの廃棄、複合、および督促処理の概要の一例を示す図である。
【図１８】実施の形態に係るＮｏｔｉｆｉｃａｔｉｏｎ処理判定部の処理の一例を示すフローチャートである。
【図１９】ＦＣＭＤＢシステムに係る従来の機能概要を説明する図である。
【図２０】ｐｕｂ／ｓｕｂ（ｐｕｂｌｉｓｈ／ｓｕｂｓｃｒｉｂｅ）型の監視・通知に係る従来の処理概要を説明する図である。
【発明を実施するための最良の形態】
【００１６】
以下、本発明の実施の形態について図面を参照しつつ説明する。まず、図１に、本実施の形態に係わるＦＣＭＤＢシステムの構成の概略の一例を示す。【００１７】
本実施の形態では、情報システムのリソースの情報（情報システムを構成するハードウェアやソフトウェアに関する情報、以下：構成情報）を管理するＦＣＭＤＢシステム１００と管理情報を利用するクライアント１０とはネットワークを介して接続される。【００１８】
ＦＣＭＤＢシステム１００は、図示しない情報システムの構成情報を管理する複数種類のデータベースであるＭＤＲ＿Ａ３０（機器）、ＭＤＲ＿Ｂ４０（機器）等と、それらを仮想統合することにより情報システム全体の構成情報を管理するデータベースＦＣＭＤＢ２０（情報処理装置）を備える。なお、ＦＣＭＤＢは、ＦＣＭＤＢシステムにおいてＭＤＲと同様の役割を担う場合もある。【００１９】
また、本実施の形態では、本発明の情報処理装置、プログラム、方法をｐｕｂ／ｓｕｂ（ｐｕｂｌｉｓｈ／ｓｕｂｓｃｒｉｂｅ）型の枠組みを適用した情報処理装置、プログラム、方法について説明する。このとき、クライアント１０は、Ｓｕｂｓｃｒｉｂｅｒ、ＭＤＲ＿Ａ３０等はＰｕｂｌｉｓｈｅｒ、ＦＣＭＤＢ２０はＢｒｏｋｅｒとして振舞う。【００２０】
図２は、本実施の形態に係るＦＣＭＤＢ２０、ＭＤＲ＿Ａ３０、ＭＤＲ＿Ｂ４０、およびクライアントであるＳｕｂｓｃｒｉｂｅｒ１０を構成する機能ブロックの一例を示す図である。【００２１】
Ｓｕｂｓｃｒｉｂｅｒ１０は、監視依頼の通達を行うＳｕｂｓｃｒｉｐｔｉｏｎ（指定情報）通信部１１１、監視対象の変化に係る通知を受け付けるＮｏｔｉｆｉｃａｔｉｏｎ（リソース情報）受付部１１２を備える。【００２２】
ＦＣＭＤＢ２０は、構成情報ＤＢ２０１、登録元ＤＢ２０２、登録可能種別ＤＢ２０３、Ｓｕｂｓｃｒｉｐｔｉｏｎ分配記録ＤＢ２０４、Ｎｏｔｉｆｉｃａｔｉｏｎ記録ＤＢ２０５、Ｎｏｔｉｆｉｃａｔｉｏｎ関連性ＤＢ２０６、Ｎｏｔｉｆｉｃａｔｉｏｎ処理待ちＤＢ２０７、Ｓｕｂｓｃｒｉｐｔｉｏｎを受け付けるＳｕｂｓｃｒｉｐｔｉｏｎ受付部２１１（指定情報受付部）、Ｓｕｂｓｃｒｉｐｔｉｏｎの分配先を判定するＳｕｂｓｃｒｉｐｔｉｏｎ分配判定部２１２（判定部）、Ｓｕｂｓｃｒｉｐｔｉｏｎを分配するＳｕｂｓｃｒｉｐｔｉｏｎ分配通信部２１３（指定情報通知部）、Ｎｏｔｉｆｉｃａｔｉｏｎの配布を受け付けるＮｏｔｉｆｉｃａｔｉｏｎ受付部２１４、Ｎｏｔｉｆｉｃａｔｉｏｎに係る複合や廃棄の処理を判定するＮｏｔｉｆｉｃａｔｉｏｎ処理判定部２１５（リソース情報処理部）、Ｎｏｔｉｆｉｃａｔｉｏｎの配布を行うＮｏｔｉｆｉｃａｔｉｏｎ通信部２１６、Ｎｏｔｉｆｉｃａｔｉｏｎの配布を督促するＮｏｔｉｆｉｃａｔｉｏｎ督促部２１７、複数のＮｏｔｉｆｉｃａｔｉｏｎ間の関連性（複数のリソース情報間の関連）を定義、生成する関連性発見部２１８（関連付け部）、を備える。【００２３】
ＭＤＲ＿Ａ３０等は、Ｓｕｂｓｃｒｉｐｔｉｏｎを受け付けるＳｕｂｓｃｒｉｐｔｉｏｎ受付部３１１、Ｎｏｔｉｆｉｃａｔｉｏｎを配布するＮｏｔｉｆｉｃａｔｉｏｎ通信部３１２、Ｎｏｔｉｆｉｃａｔｉｏｎの督促を受け付けるＮｏｔｉｆｉｃａｔｉｏｎ督促受付部３１３を備える。【００２４】
以下、ＦＣＭＤＢ２０で保持する情報についてそれぞれ概要を示す。【００２５】
まず、情報システムの構成情報を管理する構成情報ＤＢ２０１の一例を図３に示す。構成情報は、管理対象であるリソースの種別（データクラス）、リソースの値（データＩＤ）、リソースの子要素、リソースの属性情報の組からなる。また、図４に構成情報をＸＭＬ形式で記載した一例を示す。【００２６】
次に、情報システムの管理対象であるリソースの管理元に関する情報である構成情報登録元メタ情報を管理する登録元ＤＢ２０２の一例を図５に示す。構成情報登録元メタ情報は、管理対象に係る複数の管理元を管理の優先度によって、主、副、従と区分し、管理対象毎に、リソースの種別の値（データＩＤ）、管理を主に行う登録元（主登録元）、管理を副として行う登録元（副登録元）、管理を従として行う登録元（従登録元）の組からなる。【００２７】
次に、リソースの種別毎の登録が可能な管理元を管理する登録可能種別ＤＢ２０３の一例を図６に示す。登録可能な管理元の情報は、管理対象であるリソース種別毎にリソースの種別（データクラス）、登録可能な管理元（可能登録元）の組からなる。【００２８】
次に、Ｓｕｂｓｃｒｉｐｔｉｏｎによる監視依頼の登録を分配した履歴を管理するＳｕｂｓｃｒｉｐｔｉｏｎ分配記録ＤＢ２０４の一例を図７に示す。Ｓｕｂｓｃｒｉｐｔｉｏｎの分配の記録は、ＳｕｂｓｃｒｉｐｔｉｏｎのＩＤ、Ｓｕｂｓｃｒｉｐｔｉｏｎの登録元、Ｓｕｂｓｃｒｉｐｔｉｏｎの分配先の組からなる。【００２９】
次に、受け付けたＮｏｔｉｆｉｃａｔｉｏｎを時系列に記録するＮｏｔｉｆｉｃａｔｉｏｎ記録ＤＢ２０５の一例を図８に示す。Ｎｏｔｉｆｉｃａｔｉｏｎの記録は、受け付けたＮｏｔｉｆｉｃａｔｉｏｎに対応するＳｕｂｓｃｒｉｐｔｉｏｎのＩＤ、Ｎｏｔｉｆｉｃａｔｉｏｎの内容、Ｎｏｔｉｆｉｃａｔｉｏｎの受け付け時刻の組からなる。【００３０】
次に、複数のＮｏｔｉｆｉｃａｔｉｏｎ間の関連性を管理するＮｏｔｉｆｉｃａｔｉｏｎ関連性ＤＢ２０６の一例を図９に示す。Ｎｏｔｉｆｉｃａｔｉｏｎの関連性の管理は、先行受け付けしたＮｏｔｉｆｉｃａｔｉｏｎ（以下、先行Ｎｏｔｉｆｉｃａｔｉｏｎ）に関連性のあるＮｏｔｉｆｉｃａｔｉｏｎ（以下、後続Ｎｏｔｉｆｉｃａｔｉｏｎ）を、廃棄するか、複合するかの処理と後続Ｎｏｔｉｆｉｃａｔｉｏｎを受信するまでの有効な時間により表される。Ｎｏｔｉｆｉｃａｔｉｏｎ関連性は、先行Ｎｏｔｉｆｉｃａｔｉｏｎ、後続Ｎｏｔｉｆｉｃａｔｉｏｎ、後続Ｎｏｔｉｆｉｃａｔｉｏｎに対する処理、後続Ｎｏｔｉｆｉｃａｔｉｏｎ受付までに有効な時間の組からなる。【００３１】
次に、後続Ｎｏｔｉｆｉｃａｔｉｏｎの処理待ちの状態を記録するＮｏｔｉｆｉｃａｔｉｏｎ処理待ちＤＢ２０７の一例を図１０に示す。Ｎｏｔｉｆｉｃａｔｉｏｎの処理待ちの状態とは、対象となるＳｕｂｓｃｒｉｐｔｉｏｎに係る先行Ｎｏｔｉｆｉｃａｔｉｏｎを受付けたとき、Ｎｏｔｉｆｉｃａｔｉｏｎ関連性ＤＢ２０６の管理情報から、関連する後続Ｎｏｔｉｆｉｃａｔｉｏｎが存在すると判断し、後続Ｎｏｔｉｆｉｃａｔｉｏｎの受け付けおよび後続Ｎｏｔｉｆｉｃａｔｉｏｎに対する処理を待っている状態である。Ｎｏｔｉｆｉｃａｔｉｏｎの処理待ちの状態の記録は、Ｎｏｔｉｆｉｃａｔｉｏｎに対応するＳｕｂｓｃｒｉｐｔｉｏｎのＩＤ、処理待ちをしている後続Ｎｏｔｉｆｉｃａｔｉｏｎ、後続のＮｏｔｉｆｉｃａｔｉｏｎに対する処理、後続Ｎｏｔｉｆｉｃａｔｉｏｎの処理待ち開始時刻、後続Ｎｏｔｉｆｉｃａｔｉｏｎ受付までに有効な待ち時間の組からなる。【００３２】
尚、これら各機能は、クライアント１０、ＦＣＭＤＢシステム１００に備えられた図示しないＣＰＵ、メモリ、ハードディスク等のハードウェア資源とソフトウェアとが協働することで実現される。【００３３】
次に、ＦＣＭＤＢ２０の動作の概要について説明する。【００３４】
ＦＣＭＤＢ２０は、Ｓｕｂｓｃｒｉｂｅｒ１０から監視依頼（Ｓｕｂｓｃｒｉｐｔｉｏｎ）を受け、その監視依頼の内容に基づき監視対象に係るＭＤＲを判定し、ＭＤＲに対しＳｕｂｓｃｒｉｐｔｉｏｎを分配する。また、ＦＣＭＤＢ２０は、Ｐｕｂｌｉｓｈｅｒである各ＭＤＲからのＮｏｔｉｆｉｃａｔｉｏｎを受け、Ｓｕｂｓｃｒｉｐｔｉｏｎの分配の記録、複数のＮｏｔｉｆｉｃａｔｉｏｎ間で発見される関連性、Ｎｏｔｉｆｉｃａｔｉｏｎの処理待ちの状況とＮｏｔｉｆｉｃａｔｉｏｎの内容を基に、Ｎｏｔｉｆｉｃａｔｉｏｎの廃棄、複合、および督促を行い、ＮｏｔｉｆｉｃａｔｉｏｎをＳｕｂｓｃｒｉｂｅｒへ配布する。また、ＦＣＭＤＢ２０は、上述のＮｏｔｉｆｉｃａｔｉｏｎの廃棄、複合および督促を実現するために、複数のＮｏｔｉｆｉｃａｔｉｏｎ間の関連性を発見する処理を任意のタイミングで行う。【００３５】
次に、Ｓｕｂｓｃｒｉｐｔｉｏｎの分配処理について説明する。【００３６】
Ｓｕｂｓｃｒｉｐｔｉｏｎの分配先は、監視対象が何かによって決定する。本実施の形態におけるＦＣＭＤＢ２０は、従来から各インスタンス（特定リソース）の管理がどのＭＤＲでなされているかの情報（登録元ＤＢ２０２、参照）を管理するが、本実施の形態ではさらに、ＦＣＭＤＢ２０は、各クラス（任意のリソース）についてどのＭＤＲが情報を持ちうるかの情報（登録可能種別ＤＢ２０３、参照）を管理する。【００３７】
これらの情報に基づき、監視対象が構造の追加である場合、ＦＣＭＤＢ２０は、登録可能種別ＤＢ２０３により監視対象が該当するクラスに関するＭＤＲを判断し、Ｓｕｂｓｃｒｉｐｔｉｏｎを分配する。【００３８】
また、監視対象が構造の削除の場合、ＦＣＭＤＢ２０は、登録元ＤＢ２０２により、監視対象のインスタンスに関係しているＭＤＲを判断し、Ｓｕｂｓｃｒｉｐｔｉｏｎを分配する。将来新たにＭＤＲが監視対象のインスタンスに関係するようになった場合、その都度そのようなＭＤＲに対してもＳｕｂｓｃｒｉｐｔｉｏｎを分配する。なお、ＭＤＲの決定の際、ＦＣＭＤＢ２０は、判定結果を主ＭＤＲのみか、副ＭＤＲも含むかについて、各クラスのメタ情報やＳｕｂｓｃｒｉｐｔｉｏｎのメタ情報として指定を可能にして参照する。【００３９】
また、監視対象が値の変更の場合、ＦＣＭＤＢ２０は、構造の削除の場合と同様にＳｕｂｓｃｒｉｐｔｉｏｎを分配する。【００４０】
さらに、監視対象の範囲が、サブツリー（例えば、特定のサーバＡについて、ＣＰＵもメモリもＨＤＤも、さらにそれら以下のリソースを監視する）の場合、ＦＣＭＤＢ２０は、サブツリー内の各要素について判断し、判断材料がない場合は親要素の判断を元にＳｕｂｓｃｒｉｐｔｉｏｎを分配する。【００４１】
次に、上述した監視対象が構造の追加の場合に関するＳｕｂｓｃｒｉｐｔｉｏｎの分配処理の概要の一例を図１１に示す。例えばＳｅｒｖｅｒ  ＡのＨＤＤ情報の追加登録を監視依頼するとき、Ｓｕｂｓｃｒｉｂｅｒ１０は、ＦＣＭＤＢ２０へＳｅｒｖｅｒ  ＡのＨＤＤ情報の追加登録監視のＳｕｂｓｃｒｉｐｔｉｏｎを発行する。ＦＣＭＤＢ２０は、登録可能種別ＤＢ２０３から、ＨＤＤ情報が登録可能であるのは、ＭＤＲ＿Ｂ４０だけであることを割り出し、ＭＤＲ＿Ｂ４０に対し、Ｓｅｒｖｅｒ  ＡのＨＤＤ情報の追加登録を見張るようＳｕｂｓｃｒｉｐｔｉｏｎを発行し、Ｓｕｂｓｃｒｉｐｔｉｏｎを分配したことを記録する。【００４２】
また、上述した監視対象の範囲がサブツリーの場合に関するＳｕｂｓｃｒｉｐｔｉｏｎの分配処理の概要の一例を図１２に示す。例えばＳｅｒｖｅｒ  Ａのサブツリーのリソースの変化の監視依頼をするとき、Ｓｕｂｓｃｒｉｂｅｒ１０は、ＦＣＭＤＢ２０へＳｅｒｖｅｒ  Ａのサブツリーのリソースの変化の監視依頼のＳｕｂｓｃｒｉｐｔｉｏｎを発行する。ＦＣＭＤＢ２０は、登録元ＤＢ２０２から、Ｓｅｒｖｅｒ  Ａに関する情報をＭＤＲ＿Ａ３０、ＭＤＲ＿Ｂ４０が持つことを割り出し、ＭＤＲ＿Ａ３０、ＭＭＤＲ＿Ｂ４０に対し、Ｓｅｒｖｅｒ  Ａのサブツリーのリソースの変化を見張るようＳｕｂｓｃｒｉｐｔｉｏｎを発行し、Ｓｕｂｓｃｒｉｐｔｉｏｎを分配したことを記録する。【００４３】
さらに、上述したＳｕｂｓｃｒｉｐｔｉｏｎの分配処理におけるＳｕｂｓｃｒｉｐｔｉｏｎ分配判定部２１２の処理の一例を図１３にフローチャートで示す。【００４４】
Ｓｕｂｓｃｒｉｐｔｉｏｎ受付部２１１は、Ｓｕｂｓｃｒｉｐｔｉｏｎ通信部１１１からのＳｕｂｓｃｒｉｐｔｉｏｎを受け付けるとＳｕｂｓｃｒｉｐｔｉｏｎ分配判定部２１２を起動する(指定情報受付ステップ)。【００４５】
Ｓｕｂｓｃｒｉｐｔｉｏｎ分配判定部２１２は、Ｓｕｂｓｃｒｉｐｔｉｏｎの内容から、監視対象の現象が構造の追加か否かの判定を行い（Ｓ１１）、監視対象の現象が構造の追加の場合（Ｓ１１、ＹＥＳ）、監視対象のリソースのクラスにより登録可能種別ＤＢ２０３を参照し、分配先ＭＤＲを求める（Ｓ１２、判定ステップ）。なお、登録可能種別ＤＢ２０３に該当する情報が無い場合は全ＭＤＲを分配先とする（判定ステップ）。【００４６】
次に、Ｓｕｂｓｃｒｉｐｔｉｏｎ分配判定部２１２は、Ｓｕｂｓｃｒｉｐｔｉｏｎ分配通信部２１３に対し、Ｓｕｂｓｃｒｉｐｔｉｏｎを分配した記録をＳｕｂｓｃｒｉｐｔｉｏｎ分配記録ＤＢ２０４へ追記すること（Ｓ１４）と、分配先ＭＤＲにＳｕｂｓｃｒｉｐｔｉｏｎを送ること（Ｓ１５、指定情報通知ステップ）を指示し、本フローは終了する。【００４７】
一方、監視対象の現象が構造の追加ではない場合（Ｓ１１、ＮＯ）、Ｓｕｂｓｃｒｉｐｔｉｏｎ分配判定部２１２は、監視対象のリソースにより登録元ＤＢ２０２を参照し、分配先ＭＤＲを求め（Ｓ１３、判定ステップ）、処理Ｓ１４へ進む。【００４８】
上述したＳｕｂｓｃｒｉｐｔｉｏｎの分配処理によれば、Ｓｕｂｓｃｒｉｐｔｉｏｎが通達されるＭＤＲが限定され、ＭＤＲの監視処理に係る負荷が軽減される。また、Ｎｏｔｉｆｉｃａｔｉｏｎ処理に係るＢｒｏｋｅｒの負荷も軽減される。【００４９】
次に、複数の監視対象の値の変化や構造の変化の間の関連性の定義や複数のＮｏｔｉｆｉｃａｔｉｏｎ間の関連性を発見する処理について説明する。【００５０】
本処理は、Ｎｏｔｉｆｉｃａｔｉｏｎの複合や廃棄、および督促処理より事前に任意のタイミングで行われる処理である。なお、本処理にむけて上述したＳｕｂｓｃｒｉｐｔｉｏｎの分配処理で示したＳｕｂｓｃｒｉｐｔｉｏｎを分配した記録がすでになされていること、また、Ｎｏｔｉｆｉｃａｔｉｏｎ中に対応するＳｕｂｓｃｒｉｐｔｉｏｎを特定する情報が含まれていることを前提とする。【００５１】
複数の監視対象の値の変化や構造の変化の間の関連性の定義とは、例えば、『「ＯＳインスタンスのランレベルが５になった」ということを示すＮｏｔｉｆｉｃａｔｉｏｎに対応し、５分以内に「サーバインスタンスの電源状態がＯＦＦになった」ということを示すＮｏｔｉｆｉｃａｔｉｏｎが続く』といった、先行するＮｏｔｉｆｉｃａｔｉｏｎが示すイベントに対し関連性を持つイベントを通知する後続のＮｏｔｉｆｉｃａｔｉｏｎであり、且つ、後続するＮｏｔｉｆｉｃａｔｉｏｎが一定時間内に存在することを規定するものである。【００５２】
また、複数のＮｏｔｉｆｉｃａｔｉｏｎ間の関連性の発見とは、発生したＮｏｔｉｆｉｃａｔｉｏｎを時系列に保持した履歴から、ＦＣＭＤＢシステムの構造上、データの構造上の距離が近い管理対象要素を履歴から抽出し、例えば、「要素ＡについてのＮｏｔｉｆｉｃａｔｉｏｎの後、ｎ分以内に要素ＢについてのＮｏｔｉｆｉｃａｔｉｏｎが発生する」というＮｏｔｉｆｉｃａｔｉｏｎの発現に関する仮説を立て、さらに履歴によりそのＮｏｔｉｆｉｃａｔｉｏｎの発現に関する仮説を検証する処理である。【００５３】
複数のＮｏｔｉｆｉｃａｔｉｏｎ間の関連性の発見の処理に係わる関連性発見部２１８の処理の一例を図１４、図１５と図１６にフローチャートで示す。【００５４】
関連性発見部２１８は、ＦＣＭＤＢシステム内の処理スケジューラやクライアントからの要求により、本フローを起動する。関連性発見部２１８は、Ｎｏｔｉｆｉｃａｔｉｏｎ記録ＤＢ２０５の先頭を示し（Ｓ４１）処理を開始する。【００５５】
関連性発見部２１８は、Ｎｏｔｉｆｉｃａｔｉｏｎの記録が、Ｎｏｔｉｆｉｃａｔｉｏｎ記録ＤＢ２０５の末尾か否かを判定し（Ｓ４２）、Ｎｏｔｉｆｉｃａｔｉｏｎの記録が末尾でない場合（Ｓ４２、ＮＯ）、Ｎｏｔｉｆｉｃａｔｉｏｎ記録ＤＢ２０５から、Ｎｏｔｉｆｉｃａｔｉｏｎを１つ取り出し、先行Ｎｏｔｉｆｉｃａｔｉｏｎ候補とし（Ｓ４３）、この先行Ｎｏｔｉｆｉｃａｔｉｏｎ候補以降のＮｏｔｉｆｉｃａｔｉｏｎを一定の時間枠内から取り出し、後続Ｎｏｔｉｆｉｃａｔｉｏｎ候補リストとする（Ｓ４４、関連付けステップ）。【００５６】
次に、関連性発見部２１８は、先行Ｎｏｔｉｆｉｃａｔｉｏｎ候補の監視対象である構成情報と「データ構造上の距離が一定範囲内」にある構成情報を算出し（Ｓ４５）、この「データ構造上の距離が一定範囲内」に該当しない構成要素を監視対象とするＮｏｔｉｆｉｃａｔｉｏｎを後続Ｎｏｔｉｆｉｃａｔｉｏｎ候補リストから削除する（Ｓ４６）。【００５７】
次に、関連性発見部２１８は、Ｎｏｔｉｆｉｃａｔｉｏｎ記録ＤＢ２０５のうち先行Ｎｏｔｉｆｉｃａｔｉｏｎ候補と同型のＮｏｔｉｆｉｃａｔｉｏｎを検出し、この同型のＮｏｔｉｆｉｃａｔｉｏｎに続く一定の時間枠内のＮｏｔｉｆｉｃａｔｉｏｎ群に、後続Ｎｏｔｉｆｉｃａｔｉｏｎ候補リスト内の各候補と同型のＮｏｔｉｆｉｃａｔｉｏｎが存在するか否か判定し、その存在割合（先行Ｎｏｔｉｆｉｃａｔｉｏｎ候補と同型のＮｏｔｉｆｉｃａｔｉｏｎの出現数を全体とし、それに対する後続Ｎｏｔｉｆｉｃａｔｉｏｎ候補と同型のＮｏｔｉｆｉｃａｔｉｏｎの出現の割合）を各後続Ｎｏｔｉｆｉｃａｔｉｏｎ候補に関して算出し記録する（Ｓ４７、関連付けステップ）。【００５８】
次に、関連性発見部２１８は、存在割合が一定以上の後続Ｎｏｔｉｆｉｃａｔｉｏｎ候補があるか否か判定し（Ｓ５０）、候補が存在する場合（Ｓ５０、ＹＥＳ）、存在割合が一定以上となった後続Ｎｏｔｉｆｉｃａｔｉｏｎ候補について、Ｎｏｔｉｆｉｃａｔｉｏｎ関連性知識として、先行Ｎｏｔｉｆｉｃａｔｉｏｎ候補、後続Ｎｏｔｉｆｉｃａｔｉｏｎ候補、時間枠、処理内容をＮｏｔｉｆｉｃａｔｉｏｎ関連性ＤＢ２０６へ追記し（Ｓ５１、関連付けステップ）、Ｎｏｔｉｆｉｃａｔｉｏｎ記録ＤＢ２０５の次を示し（Ｓ５２）、処理Ｓ４２へ戻る。一方、候補が存在しない場合（Ｓ５０、ＮＯ）、処理Ｓ５２の後、処理Ｓ４２に戻る。【００５９】
一方、Ｎｏｔｉｆｉｃａｔｉｏｎの記録が末尾であった場合（Ｓ４２、ＹＥＳ）、関連性発見部２１８は、Ｎｏｔｉｆｉｃａｔｉｏｎ記録ＤＢ２０５に充分なＮｏｔｉｆｉｃａｔｉｏｎ関連性知識情報が蓄積されているか否か判定し（Ｓ４８）、Ｎｏｔｉｆｉｃａｔｉｏｎ関連性知識情報が充分に蓄積されている場合（Ｓ４８、ＹＥＳ）、本フローは終了する。一方、Ｎｏｔｉｆｉｃａｔｉｏｎ関連性知識情報が充分に蓄積されていない場合（Ｓ４８、ＮＯ）、処理Ｓ４５で用いる「データ構造上の距離が一定範囲内」の「距離の一定範囲」を拡大し、処理Ｓ５０で用いる同型のＮｏｔｉｆｉｃａｔｉｏｎの存在割合に関する「存在割合の一定」の値を下げ（Ｓ４９）、処理Ｓ４１へ戻る。【００６０】
次に、Ｎｏｔｉｆｉｃａｔｉｏｎの廃棄、複合、および督促処理について説明する。【００６１】
本処理は、上述した監視対象の値の変化や構造の変化の間の関連性の定義、および発見したＮｏｔｉｆｉｃａｔｉｏｎ間の関連性に基づき実行する。なお、本処理の実行に際し、分配済みＳｕｂｓｃｒｉｐｔｉｏｎに対応した関連性が発現することを確認する。【００６２】
任意のＮｏｔｉｆｉｃａｔｉｏｎの後に同一要素に関して重複するＮｏｔｉｆｉｃａｔｉｏｎが続きそうな場合、ＦＣＭＤＢはＳｕｂｓｃｒｉｂｅｒにＮｏｔｉｆｉｃａｔｉｏｎを通知するとともにＮｏｔｉｆｉｃａｔｉｏｎの内容を記憶し、後続の重複するＮｏｔｉｆｉｃａｔｉｏｎを廃棄する。【００６３】
また、任意のＮｏｔｉｆｉｃａｔｉｏｎの後に同一サブツリー内でＮｏｔｉｆｉｃａｔｉｏｎが続きそうな場合、ＦＣＭＤＢはＰｕｂｌｉｓｈｅｒに後続のＮｏｔｉｆｉｃａｔｉｏｎを配布するよう督促し、後続のＮｏｔｉｆｉｃａｔｉｏｎを待ってからＮｏｔｉｆｉｃａｔｉｏｎの内容を複合しＳｕｂｓｃｒｉｂｅｒへ通知する。【００６４】
次に、本発明の実施の形態における、Ｎｏｔｉｆｉｃａｔｉｏｎの廃棄、複合、および督促処理の概要の一例を図１７に示す。図のように、ＭＤＲ＿Ｂ４０がＣＰＵの減少を感知したときＭＤＲ＿Ｂ４０はＣＰＵ減少についてＮｏｔｉｆｉｃａｔｉｏｎを配布する。Ｎｏｔｉｆｉｃａｔｉｏｎを受信したＦＣＭＤＢ２０は、Ｎｏｔｉｆｉｃａｔｉｏｎの関連性に基づき、ＭＤＲ＿Ａ３０からのＣＰＵ数の減少通知の廃棄の決定と、ＭＤＲ＿Ａ３０に対してメモリ情報についてのＮｏｔｉｆｉｃａｔｉｏｎの督促を行う。ＭＤＲ＿Ａ３０は、督促に応じメモリ量の変化を確認し、メモリ量の減少についてのＮｏｔｉｆｉｃａｔｉｏｎを配布する。ＦＣＭＤＢ２０は、ＣＰＵ数の減少とメモリ量の減少に係わる情報を複合し、１つのＮｏｔｉｆｉｃａｔｉｏｎをＳｕｂｓｃｒｉｂｅｒへ送る。【００６５】
さらに、上述したＮｏｔｉｆｉｃａｔｉｏｎの廃棄、複合、および督促処理に係わるＮｏｔｉｆｉｃａｔｉｏｎ処理判定部２１５の処理の一例を図１８にフローチャートで示す。【００６６】
Ｎｏｔｉｆｉｃａｔｉｏｎ受付部２１４は、ＭＤＲからＮｏｔｉｆｉｃａｔｉｏｎを受け付けるとＮｏｔｉｆｉｃａｔｉｏｎ処理判定部２１５の処理を起動する。【００６７】
Ｎｏｔｉｆｉｃａｔｉｏｎ処理判定部２１５は、Ｎｏｔｉｆｉｃａｔｉｏｎに記されたＮｏｔｉｆｉｃａｔｉｏｎと対応するＳｕｂｓｃｒｉｐｔｉｏｎ  ＩＤにより、Ｎｏｔｉｆｉｃａｔｉｏｎ処理待ちＤＢ２０７を参照し、処理待ち項目を求める（Ｓ２１）。【００６８】
Ｎｏｔｉｆｉｃａｔｉｏｎ処理判定部２１５は、処理待ち項目の有無を判定し（Ｓ２２）、処理待ち項目がない場合（Ｓ２２，ＮＯ）、処理Ｓ２６へ進み、処理待ち項目がある場合（Ｓ２２、ＹＥＳ）、Ｎｏｔｉｆｉｃａｔｉｏｎ処理待ちＤＢ２０７から該当する処理待ち項目を削除し（Ｓ２３）、処理待ち項目の処理が、廃棄か否かを判定し（Ｓ２４）、処理が廃棄でない場合（Ｓ２４、ＮＯ）、Ｎｏｔｉｆｉｃａｔｉｏｎを先行Ｎｏｔｉｆｉｃａｔｉｏｎと複合する（Ｓ２５、リソース情報処理ステップ）。一方、処理が廃棄の場合（Ｓ２４、ＹＥＳ）、本フローは終了する。【００６９】
次に、Ｎｏｔｉｆｉｃａｔｉｏｎ処理判定部２１５は、Ｎｏｔｉｆｉｃａｔｉｏｎの内容によりＮｏｔｉｆｉｃａｔｉｏｎ関連性ＤＢ２０６を参照し、後続Ｎｏｔｉｆｉｃａｔｉｏｎの候補を求める（Ｓ２６）。【００７０】
Ｎｏｔｉｆｉｃａｔｉｏｎ処理判定部２１５は、後続Ｎｏｔｉｆｉｃａｔｉｏｎの有無を判定し（Ｓ２７）、後続Ｎｏｔｉｆｉｃａｔｉｏｎがある場合（Ｓ２７、ＹＥＳ）、Ｎｏｔｉｆｉｃａｔｉｏｎ処理待ちＤＢ２０７に後続Ｎｏｔｉｆｉｃａｔｉｏｎの情報を追記する（Ｓ２８、リソース情報処理ステップ）。【００７１】
次に、Ｎｏｔｉｆｉｃａｔｉｏｎ処理判定部２１５は、後続Ｎｏｔｉｆｉｃａｔｉｏｎの処理が廃棄か否かを判定し（Ｓ２９）、処理が、廃棄でない場合（Ｓ２９、ＮＯ）、後続の処理は複合であるため、後続のＮｏｔｉｆｉｃａｔｉｏｎを督促するようＮｏｔｉｆｉｃａｔｉｏｎ督促部２１７に指示し（Ｓ３０、リソース情報処理ステップ）、本フローは終了する。【００７２】
一方、後続Ｎｏｔｉｆｉｃａｔｉｏｎがない場合（Ｓ２７、ＮＯ）、または後続Ｎｏｔｉｆｉｃａｔｉｏｎの処理が、廃棄の場合（Ｓ２９、ＹＥＳ）、Ｎｏｔｉｆｉｃａｔｉｏｎ処理判定部２１５は、Ｎｏｔｉｆｉｃａｔｉｏｎを送信するようＮｏｔｉｆｉｃａｔｉｏｎ通信部２１６に指示し（Ｓ３１、リソース情報処理ステップ）、本フローは終了する。【００７３】
なお、図示しない処理として処理Ｓ３０に従ってＮｏｔｉｆｉｃａｔｉｏｎ督促部２１７からの督促を受け付けたＭＤＲは、Ｎｏｔｉｆｉｃａｔｉｏｎに対応する監視対象であるリソースを確認し、Ｎｏｔｉｆｉｃａｔｉｏｎ通信部３１２を介し、ＮｏｔｉｆｉｃａｔｉｏｎをＮｏｔｉｆｉｃａｔｉｏｎ受付部２１４へ送付する。【００７４】
上述したＮｏｔｉｆｉｃａｔｉｏｎの廃棄処理によれば、重複したＮｏｔｉｆｉｃａｔｉｏｎの内容を削減し、Ｓｕｂｓｃｒｉｂｅｒの負荷を軽減することができる。また、上述したＮｏｔｉｆｉｃａｔｉｏｎの複合処理によれば、近接、または関連するＮｏｔｉｆｉｃａｔｉｏｎの内容は複数保持したまま、通信回数を削減できるため通信網への負担が軽減でき、また、Ｎｏｔｉｆｉｃａｔｉｏｎの関連性を把握できるため、Ｓｕｂｓｃｒｉｂｅｒによる高度な処理が可能となる。さらに、上述した督促処理によれば、充分な頻度で監視を行っていないＰｕｂｌｉｓｈｅｒであるＭＤＲやその背後のミドルウェアから、関連性のある後続のＮｏｔｉｆｉｃａｔｉｏｎの送付を意図的に引き出すことができ、Ｓｕｂｓｃｒｉｂｅｒによる処理も精密になる。【００７５】
本実施の形態によれば、Ｓｕｂｓｃｒｉｐｔｉｏｎの通達が監視対象に係る変化を管理しているＭＤＲに限定され、監視対象と無関係なＭＤＲにおいて従来発生していた監視対象の確認処理の負荷が軽減される。また、必要のないＮｏｔｉｆｉｃａｔｉｏｎが発行されないため、Ｎｏｔｉｆｉｃａｔｉｏｎを仲介するＢｒｏｋｅｒの負荷も軽減される。【００７６】
また、本実施の形態によれば、従来、同一イベントに対し、複数のＭＤＲから重複して複配布されたＮｏｔｉｆｉｃａｔｉｏｎに対し、重複した分を廃棄するため、Ｓｕｂｓｃｒｉｂｅｒの負荷を軽減することができる。【００７７】
さらに、本実施の形態によれば、近接、または関連するＮｏｔｉｆｉｃａｔｉｏｎの内容は複数保持したまま複合したＮｏｔｉｆｉｃａｔｉｏｎを配布するため、通信回数を削減できるため通信網への負担が軽減でき、また、Ｎｏｔｉｆｉｃａｔｉｏｎの内容が複合されるためイベント間の関連性が把握でき、Ｓｕｂｓｃｒｉｂｅｒによる高度な処理が可能となる。【００７８】
またさらに、本実施の形態によれば、充分な頻度で監視を行っていないＰｕｂｌｉｓｈｅｒであるＭＤＲやその背後のミドルウェアから、関連性のある後続のＮｏｔｉｆｉｃａｔｉｏｎの送付を意図的に引き出すことができ、Ｓｕｂｓｃｒｉｂｅｒによる処理も精密になる。【００７９】
本発明は、その要旨または主要な特徴から逸脱することなく、他の様々な形で実施することができる。そのため、前述の実施の形態は、あらゆる点で単なる例示に過ぎず、限定的に解釈してはならない。本発明の範囲は、特許請求の範囲によって示すものであって、明細書本文には、何ら拘束されない。更に、特許請求の範囲の均等範囲に属する全ての変形、様々な改良、代替および改質は、全て本発明の範囲内のものである。【００８０】
更に、情報処理装置を構成するコンピュータにおいて上述した各ステップを実行させるプログラムを、情報処理プログラムとして提供することができる。上述したプログラムは、コンピュータにより読取り可能な記録媒体に記憶させることによって、情報処理装置を構成するコンピュータに実行させることが可能となる。ここで、上記コンピュータにより読取り可能な記録媒体としては、ＲＯＭやＲＡＭ等のコンピュータに内部実装される内部記憶装置、ＣＤ−ＲＯＭやフレキシブルディスク、ＤＶＤディスク、光磁気ディスク、ＩＣカード等の可搬型記憶媒体や、コンピュータプログラムを保持するデータベース、或いは、他のコンピュータ並びにそのデータベースや、更に回線上の伝送媒体をも含むものである。
【産業上の利用可能性】
【００８１】
本発明によれば、Ｓｕｂｓｃｒｉｐｔｉｏｎの通達に伴う監視対象のチェック処理の負荷の軽減と、Ｎｏｔｉｆｉｃａｔｉｏｎの配布に係る通信量の軽減と、構成情報に関わる複数のイベント間の関連性を活用することができる。
【図１】
2010001482.tif 000003
【図２】
2010001482.tif 000004
【図３】
2010001482.tif 000005
【図４】
2010001482.tif 000006
【図５】
2010001482.tif 000007
【図６】
2010001482.tif 000008
【図７】
2010001482.tif 000009
【図８】
2010001482.tif 000010
【図９】
2010001482.tif 000011
【図１０】
2010001482.tif 000012
【図１１】
2010001482.tif 000013
【図１２】
2010001482.tif 000014
【図１３】
2010001482.tif 000015
【図１４】
2010001482.tif 000016
【図１５】
2010001482.tif 000017
【図１６】
2010001482.tif 000018
【図１７】
2010001482.tif 000019
【図１８】
2010001482.tif 000020
【図１９】
2010001482.tif 000021
【図２０】
2010001482.tif 000022
【手続補正書】
【提出日】平成22年12月28日(2010.12.28)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
複数のリソースを分散して管理し、管理する前記複数のリソースに関する情報であるリソース情報を通知する複数の機器と接続されることができる情報処理装置であって、
前記複数のリソースのうち、所定のリソースを指定する指定情報を受け付ける指定情報受付部と、
前記指定情報受付部により受け付けられた指定情報に基づいて、前記複数の機器のうち、前記指定情報により指定されるリソースを管理する機器を判定する判定部と、
前記判定部により、前記指定情報により指定されるリソースを管理すると判定された機器に前記指定情報を通知する指定情報通知部と、
すでに通知されたリソース情報に基づいて、複数のリソース情報間を関連付ける関連付け部と、
前記関連付け部により関連付けられた前記複数のリソース情報間の関連に基づいて、前記リソース情報に対して所定の処理を実行するリソース情報処理部と
を備える情報処理装置。
【請求項２】
請求項１に記載の情報処理装置において、
前記リソース情報処理部による前記所定の処理は、前記複数のリソース情報間の関連に基づき、リソース情報が関するリソースが同一である複数のリソース情報のうち、先行するリソース情報を通知し、後続するリソース情報を廃棄する処理であることを特徴とする情報処理装置。
【請求項３】
請求項１に記載の情報処理装置において、
前記リソース情報処理部による前記所定の処理は、前記複数のリソース情報間の関連に基づき、相互に関連を持つ複数の異なるリソース情報の内容を複合したリソース情報を作成する処理であることを特徴とする情報処理装置。
【請求項４】
請求項１に記載の情報処理装置において、
前記リソース情報処理部による前記所定の処理は、前記複数のリソース情報間の関連に基づき、相互に関連を持つ複数の異なるリソース情報のうち、先行するリソース情報の通知に伴い関連を持って通知されることが予測されている後続のリソース情報が関するリソースを管理する機器に対し、前記後続のリソース情報の通知を督促することを特徴とする情報処理装置。
【請求項５】
請求項１に記載の情報処理装置において、
前記判定部は、前記リソースと該リソースを管理する機器とが対応付けられた情報である機器情報に基づいて、前記指定情報により指定されるリソースを管理する機器を判定することを特徴とする情報処理装置。
【請求項６】
複数のリソースを分散して管理し、管理する前記複数のリソースに関する情報であるリソース情報を通知する複数の機器と接続されることができる情報処理装置における情報処理プログラムであって、
前記複数のリソースのうち、所定のリソースを指定する指定情報を受け付ける指定情報受付ステップと、
前記指定情報受付ステップにより受け付けられた指定情報に基づいて、前記複数の機器のうち、前記指定情報により指定されるリソースを管理する機器を判定する判定ステップと、
前記判定ステップにより、前記指定情報により指定されるリソースを管理すると判定された機器に前記指定情報を通知する指定情報通知ステップと、
すでに通知されたリソース情報に基づいて、複数のリソース情報間を関連付ける関連付けステップと、
前記関連付けステップにより関連付けられた前記複数のリソース情報間の関連に基づいて、前記リソース情報に対して所定の処理を実行するリソース情報処理ステップと
をコンピュータに実行させる情報処理プログラム。
【請求項７】
複数のリソースを分散して管理し、管理する前記複数のリソースに関する情報であるリソース情報を通知する複数の機器と接続されることができる情報処理装置における情報処理方法であって、
前記複数のリソースのうち、所定のリソースを指定する指定情報を受け付ける指定情報受付ステップと、
前記指定情報受付ステップにより受け付けられた指定情報に基づいて、前記複数の機器のうち、前記指定情報により指定されるリソースを管理する機器を判定する判定ステップと、
前記判定ステップにより、前記指定情報により指定されるリソースを管理すると判定された機器に前記指定情報を通知する指定情報通知ステップと、
すでに通知されたリソース情報に基づいて、複数のリソース情報間を関連付ける関連付けステップと、
前記関連付けステップにより関連付けられた前記複数のリソース情報間の関連に基づいて、前記リソース情報に対して所定の処理を実行するリソース情報処理ステップと
を備える情報処理方法。
【国際調査報告】
2010001482.tif 000023
2010001482.tif 000024
2010001482.tif 000025
2010001482.tif 000026