(57)【要約】【課題】情報処理システムにおけるリソースを効率よく適切に管理する。【解決手段】情報処理システム１において、構成情報管理装置１００が管理対象装置１０１のリソースの識別子と管理対象リソースのリソースアドレスとを対応づけて記憶し、管理対象装置１０１が管理対象リソースからイベント通知を受信する際に用いられる宛先情報（構成情報管理装置１００のアドレス）を当該管理対象リソースの識別子と対応づけて記憶し、管理対象装置１０１が、構成情報管理装置１００に管理対象リソースのイベント通知を送信するに際しリソースの識別子及び現在（最新）のリソースアドレスを送信し、構成情報管理装置１００がイベント通知、リソースの識別子、及び現在のリソースアドレスを受信して、取得したリソースの識別子に対応づけて記憶しているリソースアドレスを、取得した現在のリソースアドレスに変更する。【選択図】図３
2009151560.tif 000002
【特許請求の範囲】
【請求項１】
第２の情報処理装置と通信可能に接続する第１の情報処理装置が、
管理対象である前記第２の情報処理装置のリソースの識別子と前記リソースを特定する情報であるリソースアドレスとを対応づけて記憶するステップと、
前記リソースからイベント通知を受信する際に用いられる宛先情報を当該リソースの識別子と対応づけて前記第２の情報処理装置に記憶させるステップと、  
前記リソースからのイベント通知の受信に際し、当該リソースの識別子と当該リソースに現在付与されているリソースアドレスとを取得するステップと、
取得した前記リソースの識別子に対応づけて記憶している前記リソースアドレスを、取得した前記現在のリソースアドレスに変更するステップと
を実行することを特徴とするリソースの管理方法。
【請求項２】
請求項１に記載のリソースの管理方法であって、
前記第１の情報処理装置が、前記記憶しているリソースアドレスに対応づけてそのリソースアドレスの有効／無効を示す情報を記憶するステップをさらに含むこと
を特徴とするリソースの管理方法。
【請求項３】
請求項１に記載のリソースの管理方法であって、
前記第１の情報処理装置が、前記第２の情報処理装置に対し、前記イベント通知を前記第１の情報処理装置に送信するか否かを決定する条件として、前記第１の情報処理装置が記憶している前記リソースアドレスと前記現在のリソースアドレスとが異なるという条件を前記宛先情報に対応づけて記憶させるステップをさらに含むこと
を特徴とするリソースの管理方法。
【請求項４】
請求項１に記載のリソースの管理方法であって、
前記リソースアドレスは、WS-Addressing仕様に基づいて記述されること
を特徴とするリソースの管理方法。
【請求項５】
通信可能に接続された複数の情報処理装置を含んで構成される情報処理システムにおける情報処理装置のリソースの管理方法であって、
第１の情報処理装置が、管理対象となる第２の情報処理装置のリソースの識別子と前記リソースを特定するリソースアドレスとを対応づけて記憶するステップと、
第２の情報処理装置が、前記リソースからイベント通知を受信する際に用いられる宛先情報を当該リソースの識別子と対応づけて記憶するステップと、  
前記第２の情報処理装置が、前記第１の情報処理装置に前記リソースについてのイベント通知を送信する際、当該リソースの識別子、及び当該リソースに現在付与されているリソースアドレスを送信するステップと、
前記第１の情報処理装置が、前記リソースからのイベント通知の受信に際し、前記イベント通知、前記リソースの識別子、及び前記現在のリソースアドレスを受信するステップと、
前記第１の情報処理装置が、取得した前記リソースの識別子に対応づけて記憶している前記リソースアドレスを、取得した前記現在のリソースアドレスに変更するステップと
を含むことを特徴とするリソースの管理方法。
【請求項６】
請求項５に記載のリソースの管理方法であって、
前記第２の情報処理装置が、前記リソースからイベント通知を受信する際に用いられる宛先情報を当該リソースの識別子と対応づけて記憶する前記ステップは、当該第２の情報処理装置で動作している標準管理エージェントの機能を利用して行われること
を特徴とするリソースの管理方法。
【請求項７】
請求項５に記載のリソースの管理方法であって、
前記第２の情報処理装置が、前記第１の情報処理装置に前記リソースについてのイベント通知を送信する際、当該リソースの識別子、及び当該リソースに現在付与されているリソースアドレスを送信する前記ステップは、当該第２の情報処理装置で動作している標準管理エージェントの機能を利用して行われること
を特徴とするリソースの管理方法。
【請求項８】
通信可能に接続された複数の情報処理装置を含んで構成される情報処理システムであって、
第１の情報処理装置が、管理対象となる第２の情報処理装置のリソースの識別子と前記リソースを特定する情報であるリソースアドレスとを対応づけて記憶する手段と、
第２の情報処理装置が、前記リソースからイベント通知を受信する際に用いられる宛先情報を当該リソースの識別子と対応づけて記憶する手段と、
前記第２の情報処理装置が、前記第１の情報処理装置に前記リソースについてのイベント通知を送信する際、当該リソースの識別子、及び当該リソースに現在付与されているリソースアドレスを送信する手段と、
前記第１の情報処理装置が、前記イベント通知、前記リソースの識別子、及び前記現在のリソースアドレスを受信する手段と、
前記第１の情報処理装置が、取得した前記リソースの識別子に対応づけて記憶している前記リソースアドレスを、取得した前記現在のリソースアドレスに変更する手段と
を備えることを特徴とする情報処理システム。
【請求項９】
請求項８に記載の情報処理システムにおける前記第１の情報処理装置の前記各手段を備えることを特徴とする情報処理装置。
【請求項１０】
請求項８に記載の情報処理システムにおける前記第２の情報処理装置の前記各手段を備えることを特徴とする情報処理装置。
【請求項１１】
第２の情報処理装置と通信可能に接続する第１の情報処理装置に、
管理対象である前記第２の情報処理装置のリソースの識別子と前記リソースを特定する情報であるリソースアドレスとを対応づけて記憶する機能と、
前記リソースからイベント通知を受信する際に用いられる宛先情報を当該リソースの識別子と対応づけて前記第２の情報処理装置に記憶させる機能と、
前記リソースからのイベント通知の受信に際し、当該リソースの識別子と当該リソースに現在付与されているリソースアドレスとを取得する機能と、
取得した前記リソースの識別子に対応づけて記憶している前記リソースアドレスを、取得した前記現在のリソースアドレスに変更する機能と
を実現するためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、情報処理システムにおける情報処理装置のリソースの管理方法に関し、とくに管理対象であるリソースを識別又は特定する情報が変化する場合でもリソースを効率よく適切に管理できるようにする技術に関する。
【背景技術】
【０００２】
昨今、企業等における情報処理システムは大規模化／複雑化しており、情報処理システムが保有するリソースを効率よく簡単に運用し管理することが求められている。また、管理対象となる情報処理装置の多様化／マルチベンダ化に伴い、情報処理システムの構成が変化した場合にこれらリソースを効率よく迅速に対応できることが求められている。
【０００３】
ところで、情報処理システムにおける情報処理装置、オペレーティングシステム、アプリケーションソフトウェアなどのリソースの管理に際しては、管理対象となるリソースを確実に識別し特定する必要があり、リソースを特定する情報（以下、リソースアドレスと称する。）を適切に管理する必要がある（例えば特許文献１を参照）。
【特許文献１】米国特許出願公開第20060136585号公報
【非特許文献１】CMDBf (CMDB Federation) 、[online]、[平成１９年１１月２２日検索]、インターネット＜URL:http://cmdbf.org/＞
【非特許文献２】Distributed Management Task Force, Inc.、”Common Information Model (CIM) Standards”、[online]、[平成１９年１１月２２日検索]、インターネット＜URL:http://www.dmtf.org/standards/CIM/＞
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかしながら、大規模化／複雑化した情報処理システムにおいてリソースアドレスを適切に管理することは必ずしも容易ではない。例えば管理対象装置が移設されるとＩＰアドレスやホスト名が変更されてしまうことがある。またＮＩＣ（Network Interface Card）が差し替えられればＭＡＣアドレスが変化する。また管理対象装置が仮想マシンであれば、いわゆるコールドマイグレーションが行われると管理対象装置のＭＡＣアドレス（仮想ＭＡＣアドレス）やＩＰアドレスが変化する。
【０００５】
従来、このようにリソースアドレスが変化する場合には、オペレータ等が手動でリソースアドレスの更新を行っており、大規模化／複雑化した情報処理システムにおいてはこのような更新作業により多大な運用負担が生じることとなる。
【０００６】
本発明はこのような事情に基づいてなされたもので、管理対象であるリソースを識別又は特定する情報が変化する場合でもリソースを効率よく適切に管理することが可能なリソースの管理方法、情報処理システム、情報処理装置、及びプログラムを提供することを目的とする。
【課題を解決するための手段】
【０００７】
上記課題を解決するための本発明のうちの主たる発明の一つは、リソースの管理方法であって、第２の情報処理装置と通信可能に接続する第１の情報処理装置が、管理対象である前記第２の情報処理装置のリソースの識別子と前記リソースを特定する情報であるリソースアドレスとを対応づけて記憶するステップと、前記リソースからイベント通知を受信する際に用いられる宛先情報を当該リソースの識別子と対応づけて前記第２の情報処理装置に記憶させるステップと、前記リソースからのイベント通知の受信に際し、当該リソースの識別子と当該リソースに現在付与されているリソースアドレスとを取得するステップと、取得した前記リソースの識別子に対応づけて記憶している前記リソースアドレスを、取得した前記現在のリソースアドレスに変更するステップとを実行することとする。
【発明の効果】
【０００８】
本発明によれば、管理対象であるリソースを識別又は特定する情報が変化する場合でもリソースを効率よく適切に管理することができる。
【発明を実施するための最良の形態】
【０００９】
以下、図面を参照しつつ実施の形態について詳細に説明する。
【００１０】
［実施例１］
図１に本発明の実施の形態として説明する情報処理システム１の構成を示している。同図に示すように、この情報処理システム１は、通信ネットワーク１０３を介して通信可能に接続された、構成情報管理装置１００（第１の情報処理装置）、構成情報管理装置１００の管理対象となる情報処理装置である一台以上の管理対象装置１０１（第２の情報処理装置）、及び構成情報管理装置１００が提供する情報を利用する情報処理装置である一台以上の利用装置１０２とを含んで構成されている。
【００１１】
構成情報管理装置１００は、管理対象装置１０１の構成管理に用いられる情報を管理対象装置１０１から収集する。構成情報管理装置１００は、収集した情報を用いて生成した情報（以下、構成情報と称する。）を利用装置１０２に提供する。構成情報管理装置１００は、管理対象装置１０１から収集した情報以外にも、管理対象装置１０１の管理に関する様々な情報を記憶し、それらを利用装置１０２に提供する。
【００１２】
図２に構成情報管理装置１００、管理対象装置１０１、及び利用装置１０２として用いられる情報処理装置（コンピュータ）のハードウェア構成の一例を示している。同図に示す情報処理装置２００は、ＣＰＵ２０１、主記憶装置２０２（メモリ）、ハードディスク等の補助記憶装置２０３、キーボードやマウスなどの入力装置２０４、ディスプレイやプリンタなどの出力装置２０５、ネットワーク１０３に接続するための通信インタフェースである通信制御装置２０６、及びこれらの装置を通信可能に接続するバス２０７を含んで構成されている。
【００１３】
なお、構成情報管理装置１００、管理対象装置１０１、及び利用装置１０２は、夫々図２に示す構成からなる情報処理装置２００を複数台用いて構成されていてもよい。
【００１４】
図３に構成情報管理装置１００によって実現される機能、及び構成情報管理装置１００が記憶しているデータを示している。同図に示す各機能は、構成情報管理装置１００のハードウェア、もしくは、ＣＰＵ２０１が主記憶装置２０２や補助記憶装置２０３に記憶されているプログラムを実行することにより実現される。
【００１５】
図３に示すように、構成情報管理装置１００は、リソースアドレス発見部３０１、リソースアドレス登録部３０２、リソース情報収集更新部３０３、リソースアドレス通知イベント登録部３０４、イベントメッセージ解析部３０５、リソースアクセス処理部３０６、リソースアドレス更新部３０７、イベント受信処理部３０８、クライアントアクセス処理部３０９等の機能を有している。また、構成情報管理装置１００は、管理エンドポイントテーブル３１０、リソース一覧テーブル３１１、リソースアドレス通知イベント条件テーブル３１２、リソース情報テーブル３１３、リソース間関連テーブル３１４を記憶している。
【００１６】
図４に構成情報管理装置１００の管理対象である管理対象装置１０１において実現される機能、及び管理対象装置１０１が記憶しているデータを示している。同図に示す各機能は、構成情報管理装置１００のハードウェア、もしくは、ＣＰＵ２０１が主記憶装置２０２や補助記憶装置２０３に記憶されているプログラムを実行することにより実現される。
【００１７】
同図に示すように、管理対象装置１０１では標準管理エージェント４０１が機能している。標準管理エージェント４０１は、管理対象となるリソース（以下、管理対象リソースと称する。）に関する情報の提供、情報の更新、情報の操作等の機能を、標準的な運用管理技術に従ったインタフェースを介して提供する。後述するように、構成情報管理装置１００は、各管理対象装置１０１で動作している標準管理エージェント４０１の標準管理インタフェースを利用して管理対象リソースに関する情報を収集する。上記運用管理技術の具体例としてＤＭＴＦ（Distributed Management Task Force）が標準化を行っているWS-ManagementやＣＩＭ（Common Information Model）がある。
【００１８】
管理対象装置１０１において、標準管理エージェント４０１は管理対象装置１０１で動作しているオペレーティングシステム４１１の機能を利用することにより管理対象リソースに関する様々な情報を取得する。例えば、管理対象装置１０１が図２に示すハードウェアで構成される場合、標準管理エージェント４０１は、管理対象装置１０１のハードウェア（ＣＰＵ２０１、主記憶装置２０２、補助記憶装置２０３、入力装置２０４、出力装置２０５、通信制御装置２０６、及びバス２０７）に関する情報、オペレーティングシステム４１１の管理下で実行されるプロセスに関する情報、オペレーティングシステム４１１に関する情報などをオペレーティングシステム４１１から取得する。
【００１９】
図４に示すように、標準管理エージェント４０１は、クライアントアクセス処理部４０３、オブジェクト管理部４０４、及び実リソースアクセス部４０５の各機能を有する。また、標準管理エージェント４０１は、管理オブジェクト定義情報４０６、管理オブジェクトインスタンス情報４０７を有する。同図に示す各機能は、管理対象装置１０１のハードウェア、もしくは、ＣＰＵ２０１が主記憶装置２０２や補助記憶装置２０３に記憶されているプログラムを実行することにより実現される。
【００２０】
標準管理エージェント４０１の機能のうちクライアントアクセス処理部４０３は、構成情報管理装置１００など、標準管理エージェント４０１の機能を利用するシステムとの間でメッセージの送受信を行う。このメッセージの送受信は標準プロトコルに準拠して行われる。
【００２１】
標準管理エージェント４０１の機能のうちオブジェクト管理部４０４は、管理対象リソースを表す管理オブジェクトに対する情報の参照、情報の更新、操作などの要求を、実際の管理対象リソースに対する要求として解釈して実リソースアクセス部４０５を呼び出す。実リソースアクセス部４０５は、実際の管理対象リソースとの接続機能を担い、実際の管理対象リソースから収集した情報を管理オブジェクトインスタンスとして応答する。
【００２２】
標準管理エージェント４０１が管理するデータのうち管理オブジェクト定義情報４０６は、管理対象リソースを表現するためのモデルに関する定義情報である。管理対象リソースは、標準管理モデルの定義に従った管理オブジェクトとして表現される。また管理オブジェクトインスタンス情報４０７には、管理オブジェクトインスタンスが保持される。
【００２３】
ところで、標準管理エージェント４０１は、以上に説明したようなオペレーティングシステム４１１と連携する構成以外にも、図５に示すようにＤＢＭＳ４１２(データベース管理システム)と連携し、ＤＢＭＳ４１２が管理しているリソースに関する情報を取得／管理する構成であってもよい。また、図６に示すように、アプリケーションサーバ４１３と連携し、アプリケーションサーバ４１３が管理しているリソースに関する情報を取得／管理する構成であってもよい。
【００２４】
管理対象装置１０１は必ずしも物理的な情報処理装置に限定される訳ではなく、例えば物理的な情報処理装置（物理マシン）で動作する仮想化環境（仮想マシンモニタ）によって実現される仮想的な情報処理装置（仮想マシン）であってもよい（図７を参照）。この場合、仮想化環境は、物理マシンのＣＰＵ、主記憶装置、補助記憶装置、入力装置、出力装置、通信制御装置などの物理的なハードウェアを、仮想的な装置として仮想マシンに提供する。
【００２５】
次に、構成情報管理装置１００の各機能の動作について具体的に説明する。まず構成情報管理装置１００が管理対象リソースのリソースアドレスを発見する処理について説明する。
【００２６】
ここでリソースアドレスとは、管理対象装置１０１のリソースの識別や特定を行うための情報である。例えば管理対象リソースが情報処理装置（コンピュータ）である場合には、リソースアドレスはホスト名、ＩＰアドレス、ＭＡＣアドレス、製造社名、モデル名、シリアル番号、システムＵＵＩＤ（Universally Unique Identifier）などを用いて構成される。また、管理対象リソースがオペレーティングシステムである場合には、リソースアドレスはオペレーティングシステムの名称及びバージョン情報と情報処理装置の識別子などを用いて構成される。また、管理対象リソースがアプリケーションソフトウェアである場合には、アプリケーションソフトウェアの名称、バージョン情報、ソフトウェアがインストールされている情報処理装置又はオペレーティングシステムの識別子などを用いて構成される。
【００２７】
構成情報管理装置１００が管理対象リソースのリソースアドレスを発見する方法としては、構成情報管理装置１００側から管理対象リソース側にリソースアドレスの取得要求を行うPull型、及び管理対象リソース側から構成情報管理装置１００側にリソースアドレスの送信を行うPush型が考えられる。Pull型の場合のリソースアドレスの収集タイミングとしては、定期的に収集する、又はユーザの要求に応じて収集するなどがある。またPush型の場合の収集タイミングとしては、定期的に収集（又は送信）する、又はリソースの生成時に収集（又は送信）するなどがある。
【００２８】
図９は構成情報管理装置１００のリソースアドレス発見部３０１が、上記Pull型の方法で管理対象リソースのリソースアドレスを発見する処理を説明するフローチャートである。なお、以下の説明において符号の前に付した文字「Ｓ」はステップを意味する。
【００２９】
同図に示すように、まずリソースアドレス発見部３０１が管理エンドポイントテーブル３１０から管理エンドポイントを取得する。管理エンドポイントは、構成情報管理装置１００が管理対象装置１０１上の標準管理エージェント４０１に対してリクエストを送信する宛先を示す情報である。図１５に管理エンドポイントテーブル３１０の一例を示す。標準管理エージェント４０１は管理エンドポイントを介して複数のリソースに関する管理機能を提供する。
【００３０】
管理エンドポイントはオペレータ等が管理エンドポイントテーブル３１０に手動で登録してもよいし、構成情報管理装置１００が標準管理エージェント４０１とＳＬＰ（Service Location Protocol）等のプロトコルを用いて通信することにより管理エンドポイントをプログラマティックに発見し自動登録するようにしてもよい。
【００３１】
次にリソースアドレス発見部３０１は、リソースアクセス処理部３０６を通じて標準管理エージェント４０１と通信し、管理エンドポイントテーブル３１０から取得した各管理エンドポイントに対応づけて標準管理エージェント４０１が管理しているリソースのリソースアドレス一覧を取得する（Ｓ９０１）。
【００３２】
このような仕組みを実現する技術としてWS-Addressingがある。WS-Addressingに基づくリソースアドレスは、管理エンドポイントを表すＵＲＬ（Uniform Resource Locator）と管理エンドポイント内で一意にリソースを識別する情報との組み合わせで表現される。なお、以下の説明において、リソースアドレスはWS-Addressingに基づくものとする。
【００３３】
図１６にWS-Addressingに基づくリソースアドレスの一例を示している。同図に示すように、リソースアドレス１６００は、管理エンドポイントを示すＵＲＬ１６０１、及び管理エンドポイント内でリソースを特定するための情報１６０２を含んでいる。標準管理エージェント４０１がWS-Managementに準拠している場合、リソースアドレス一覧は例えばWS-Managementで規定されるEnumerateオペレーションを利用して取得することができる。
【００３４】
次にリソースアドレス発見部３０１はリソースアドレス登録部３０２を呼び出し、Ｓ９０１で取得したリソースアドレスをリソース一覧テーブル３１１に登録する（Ｓ９０２）。
【００３５】
図１０は図９のＳ９０２においてリソースアドレス登録部３０２によって行われる処理を説明するフローチャートである。
【００３６】
まずリソースアドレス登録部３０２は、取得したリソースアドレスに一致するリソースアドレスをリソース一覧テーブル３１１から検索する（Ｓ１０００）。
【００３７】
図１７にリソース一覧テーブル３１１を例示している。同図において、リソース識別子１７０１は、構成情報管理装置１００が個々の管理対象リソースに対して一意に付与する識別情報である。符号１７０２は、リソースアドレスである。また符号１７０３は、後述するリソースアドレス通知イベント登録の有無を示す情報である。符号１７０４は、リソースアドレスの状態を示す情報である。この符号１７０４には、該当のリソースアドレスを用いて管理対象リソースにアクセス可能であれば”有効”が、そうでない場合は”無効”が登録される。
【００３８】
符号１７０４には、リソースアドレス通知イベント登録が”有”の場合にのみ内容が登録される。リソースアドレスが利用不可能な場合、通常は該当するレコードを削除するが、リソースアドレス通知イベント登録が”有”の場合はレコードを削除せず、符号１７０４に”無効”を登録してレコードは保持しておく。
【００３９】
次に、リソースアドレス登録部３０２は、Ｓ１０００の処理の結果、リソース一覧テーブル３１１に一致するリソースアドレスが存在するか否かを確認する（Ｓ１００１）。一致するリソースアドレスが存在する場合には（Ｓ１００１：ＹＥＳ）処理を終了する。
【００４０】
一方、一致するリソースアドレスが存在しなかった場合には（Ｓ１００１：ＮＯ）、以下の条件に合致するイベント通知登録情報の取得を入力されたリソースアドレスを宛先として要求する（Ｓ１００２）。  
条件１：イベント通知先アドレスに構成情報管理装置１００のイベントメッセージ受信エンドポイントが含まれている。  
条件２：イベント通知先アドレスにリソース識別子が含まれている。
【００４１】
ここでイベント通知登録情報について説明する。標準管理エージェント４０１に対し、ある特定の条件に合致する場合にある特定の宛先に通知メッセージを送信することを要求することをイベント通知登録（サブスクライブ）と呼ぶ。例えば、「管理対象リソースがオペレーティングシステム４１１である場合、オペレーティングシステム４１１の稼動状態が”停止”となった場合に構成情報管理装置１００に通知メッセージを送信させる」というイベント通知登録が考えられる。
【００４２】
標準管理エージェント４０１は、構成情報管理装置１００から受信したイベント通知登録をイベント通知登録情報（サブスクリプション）として保持して管理対象リソースを監視する。一般的なイベント通知登録情報には、イベント通知先アドレス、イベント通知登録対象リソースアドレス（サブスクライブ対象リソース）、及びイベント発火条件が含まれる。
【００４３】
図２９にイベント通知登録（サブスクライブ）リクエストメッセージの一例を示す。同図において、符号２９００は、イベント通知登録リクエストメッセージを示す。符号２９０１は、イベント通知登録対象リソース（サブスクライブ対象リソース）アドレスを示す情報である。符号２９０２は、イベント通知先アドレスを示す情報である。符号２９０３は、イベント発火条件を示す情報である。
【００４４】
図２９に示す例では、イベント通知登録対象リソース（サブスクライブ対象リソース）アドレスはＳＯＡＰメッセージ（SOAP : Simple Object Access Protocol）のヘッダ部分に存在しているが、ＳＯＡＰメッセージのボディ部分に存在していても良い。図３０はＳＯＡＰメッセージのボディ部分にイベント通知登録対象リソースを特定する情報が存在する場合におけるイベント通知登録リクエストメッセージの一例を示す図である。同図において、符号３００２がイベント通知登録対象リソースを特定する情報である。
【００４５】
標準管理エージェント４０１は、外部にイベント通知登録情報を提供する機能を有している。標準管理エージェント４０１がWS-ManagementとＣＩＭに準拠している場合、イベント通知登録情報はCIM_IndicationFilterインスタンス、CIM_IndicationHandlerインスタンス、CIM_IndicationSubscriptionインスタンスで表現され、これらはWS-Managementで規定されるGetオペレーションを利用して取得することができる。
【００４６】
図１０のＳ１００３では、リソースアドレス登録部３０２が上記条件に合致するイベント通知登録情報が発見されたか否かを確認している。イベント通知登録情報が発見されなかった場合には（Ｓ１００３：ＹＥＳ）、入力されたリソースアドレスに対してリソース識別子を付与し、リソース一覧テーブル３１１にリソース識別子、及び入力されたリソースアドレスを新規登録する（Ｓ１００４）。新規登録に際しリソースアドレス通知イベント登録１７０３の値は”無”、状態１７０４の値は”有効”として登録する。
【００４７】
一方、Ｓ１００３の結果、イベント通知登録情報が発見された場合には（Ｓ１００３：ＮＯ）、発見されたイベント通知登録情報からリソース識別子を取得する（Ｓ１００５）。そしてリソースアドレス登録部３０２は、Ｓ１００５で取得したリソース識別子、及び入力されたリソースアドレスを新たにリソース一覧テーブル３１１に登録する。このときリソースアドレス通知イベント登録１７０３の値は”有”、状態１７０４の値は”有効”として登録する（Ｓ１００６）。
【００４８】
次に構成情報管理装置１００は、以上のようにして発見／登録したリソースアドレスについて図１１に示すリソースアドレス通知イベント登録処理を行う。同図に示すように、まずリソースアドレス通知イベント登録部３０４が、処理対象となるリソース（以下、処理対象リソースと称する。）を決定する（Ｓ１１００）。
【００４９】
ここで処理対象リソースの決定方法としては、リソース一覧テーブル３１１に管理されている全てのリソースを対象とする方法、オペレータ等が手動で対象リソースを指定する方法などがある。
【００５０】
また、構成情報管理装置１００が事前に構成情報管理装置１００に設定しておいたポリシーに従ってリソース一覧テーブル３１１の中から対象とするリソースを選択するようにしてもよい。この場合には、例えば「管理対象リソースが仮想マシン上で動作するオペレーティングシステムである場合に処理対象とする」といった内容を上記ポリシーとして設定する。
【００５１】
管理対象リソースが仮想マシン上のオペレーティングシステムであるか否かの判別は、リソース情報テーブル３１３、リソース間関連テーブル３１４を参照して行う。例えばＣＩＭに準拠している場合、仮想マシンはCIM_ComputerSystemインスタンスとして表され、かつ、CIM_HostedDependencyインスタンス（関連）により、別のCIM_ComputerSystemインスタンスと関連付けられる。従って仮想マシン上のオペレーティングシステムであるか否かは、このようなCIM_ComputerSystemインスタンスとCIM_InstalledOSインスタンス（関連）によって関連付けられているCIM_OperatingSystemインスタンスであるか否かにより行うことができる。
【００５２】
次に、リソースアドレス通知イベント登録部３０４は、リソース一覧テーブル３１１からＳ１１００で決定した処理対象リソースのリソース識別子、及びリソースアドレスを取得する（Ｓ１１０１）。また、リソースアドレス通知イベント登録部３０４は、リソースアドレス通知イベント条件テーブル３１２から、処理対象リソースの種別（リソース種別１８０１）に応じたイベント条件１８０２を取得する（Ｓ１１０２）。
【００５３】
図１８にリソースアドレス通知イベント条件テーブル３１２の一例を示している。リソースアドレス通知イベント条件テーブル３１２には、リソース種別１８０１とイベント条件１８０２とが対応づけて登録されている。リソース種別１８０１にはリソースの種別を一意に識別できる情報が登録される。WS-ManagementやＣＩＭを用いる場合には、リソース種別を示す値として、リソース情報を表現するために用いるＸＭＬスキーマの名前空間名を利用し、例えばリソースの種別がオペレーティングシステムである場合、”http://schemas.dmtf.org/wbem/wsCIM/1/CIM-schema/2/CIM_OperatingSystem”という値を用いる。
【００５４】
イベント条件１８０２は、リソースアドレス通知イベントを送信させる条件を示す。例えばWS-ManagementやＣＩＭを用いる場合、オペレーティングシステムの起動を示す条件は、ＸＰａｔｈやＣＱＬ（CIM Query Language）を用いて、CIM_OperatingSystemインスタンスのEnabledStateプロパティの値が”Enabled”あるいは”Starting”であることを表現することにより指定する方法が考えられる。
【００５５】
次に、リソースアドレス通知イベント登録部３０４は、イベント通知登録リクエストメッセージを生成する（Ｓ１１０３）。この処理において、リソースアドレス通知イベント登録部３０４は、Ｓ１１０１で取得したリソース識別子、及び構成情報管理装置１００のイベントメッセージ受信エンドポイントを含むイベント通知先アドレスを生成する。
【００５６】
図１９にWS-Managementを用いる場合のイベント通知先アドレスの一例を示す。同図において、符号１９０１は、構成情報管理装置１００のイベントメッセージ受信エンドポイントである。符号１９０２は、Ｓ１１０１で取得したリソース識別子である。
【００５７】
次に、リソースアドレス通知イベント登録部３０４は、Ｓ１１０１で取得したリソースアドレスに対してＳ１１０３で生成したイベント通知登録リクエストメッセージを送信する（Ｓ１１０４）。例えばWS-Managementを用いる場合は、リソースアドレス通知イベント登録部３０４はSubscribeリクエストを送信する。この際の標準管理エージェント４０１に対するリクエスト送信処理、及び標準管理エージェント４０１からのレスポンス受信処理はリソースアクセス処理部３０６が実施する。
【００５８】
次に、管理対象装置１０１からのリソース情報の収集、及びリソース情報の更新について説明する。ここでリソース情報の収集方法としては、構成情報管理装置１００側から管理対象リソース側に対して情報収集要求を行うPull型と、管理対象リソース側から構成情報管理装置１００側に情報送信を行うPush型の大きく２通りが考えられる。Pull型の場合のリソース情報の収集タイミングとしては、定期的に収集する、又はユーザの要求に応じて収集するなどが考えられる。また、Push型の場合の収集タイミングとしては、定期的に収集（又は送信）する、値が変化した時に収集（又は送信）するなどが考えられる。
【００５９】
図１２は、Pull型の場合におけるリソース情報収集更新部３０３の処理を説明するフローチャートである。同図に示すように、まずリソース情報収集更新部３０３は、リソース一覧テーブル３１１から、リソース識別子、リソースアドレス、及びリソースアドレス通知イベント登録の値を取得する（Ｓ１２００）。
【００６０】
リソース情報収集更新部３０３は、Ｓ１２００で取得した各リソースアドレスに対してリソース情報取得リクエストを送信し、リソース情報を取得する（Ｓ１２０１）。例えばWS-Managementを用いる場合には、Getリクエストを送信する。標準管理エージェント４０１に対するリクエスト送信処理、標準管理エージェント４０１からのレスポンス受信処理は、リソースアクセス処理部３０６が実施する。
【００６１】
次に、リソース情報収集更新部３０３は、リソース情報を取得する際に使用したリソースアドレスに対応するリソースが不明か否かを確認する（Ｓ１２０２）。リソースが不明であった場合、その旨を示すエラーメッセージが標準管理エージェント４０１から応答される。
【００６２】
リソース情報収集更新部３０３は、Ｓ１２０２の結果、リソースが不明でなかった場合には（Ｓ１２０２：ＮＯ）、Ｓ１２００で取得したリソース識別子を用いてリソース情報テーブル３１３、又はリソース間関連テーブル３１４から該当するレコードを検索し、Ｓ１２０１で取得したリソース情報を更新する（Ｓ１２０３）。
【００６３】
図２０にリソース情報テーブル３１３の一例を示す。リソース情報テーブル３１３には、リソース識別子２００１、リソース種別２００２、及び詳細情報２００３が登録されている。
【００６４】
また、図２１にリソース間関連テーブル３１４の一例を示す。リソース間関連テーブル３１４には、リソース識別子２１０１、関連種別２１０２、関連元リソース識別子２１０３、及び関連先リソース識別子２１０４が登録されている。
【００６５】
関連種別２１０２としては、例えばＣＩＭで定義されているAssociationクラスで表される関連や、ベンダ独自の関連種別なども扱うことが考えられる。独自の関連種別としては、例えば管理対象サーバアプリケーションと管理対象クライアントアプリケーションとの関連を表す関連種別、管理対象サービスとサービスを構成する管理対象アプリケーションとの関連を表す関連種別、管理対象のアプリケーションとアプリケーションに関して発生したインシデント情報との関連を表す関連種別、管理対象リソースとそのリソースに関する変更履歴情報との関連を表す関連種別など、様々なオブジェクト間の関連を扱うことが考えられる。
【００６６】
次に、リソース情報収集更新部３０３は、Ｓ１２００で取得したリソースアドレス通知イベント登録の値を確認する（Ｓ１２０４）。Ｓ１２０４の結果、値が”有”であれば（Ｓ１２０４：ＹＥＳ）、リソース情報収集更新部３０３はＳ１２００で取得したリソース識別子を用いてリソース一覧テーブル３１１中の該当するレコードを検索し、状態１７０４に”有効”を登録する（Ｓ１２０５）。一方、Ｓ１２０４の結果、値が”無”であれば（Ｓ１２０４：ＮＯ）、リソース情報収集更新部３０３は、処理を終了する。
【００６７】
一方、Ｓ１２０２の結果、リソースが不明であった場合には（Ｓ１２０２：ＹＥＳ）、リソース情報収集更新部３０３は、Ｓ１２００で取得したリソースアドレス通知イベント登録の値を確認する（Ｓ１２０６）。リソース情報収集更新部３０３は、Ｓ１２０６の結果、値が”有”であれば（Ｓ１２０６：ＹＥＳ）、Ｓ１２００で取得したリソース識別子を用いてリソース一覧テーブル３１１中の該当するレコードを検索し、状態１７０４に”無効”を登録する（Ｓ１２０７）。一方、Ｓ１２０６の結果、値が”無”であれば（Ｓ１２０６：ＮＯ）、Ｓ１２００で取得したリソース識別子を用いて、リソース一覧テーブル３１１中の該当するレコードを検索し、レコードを削除する（Ｓ１２０８）。すなわち、リソースアドレス通知イベント登録の値が”無”である場合にのみ、リソース一覧テーブル３１１中の該当レコードが削除される。従って、リソースアドレス通知イベント登録の値が”有”である限りレコードはリソース一覧テーブル３１１に残存し、次回の検索（Ｓ１２００）の対象となる。
【００６８】
以上によりリソースアドレスの発見／登録、リソースアドレス通知イベント登録、リソース情報の収集／更新処理が完了する。
【００６９】
次に、リソースアドレスの発見／登録、及びリソースアドレス通知イベント登録処理が完了した以降のある時点において、図７に示した構成からなる仮想マシンについてマイグレーションが行われた場合、具体的には図８に示すように物理マシン７００上で動作する仮想化環境７０２上の仮想マシン７０１である管理対象装置１０１がコールドマイグレーションにより物理マシン７００上で動作する仮想化環境７０２上に移動する場合を想定し、リソースアドレス通知イベントメッセージが、構成情報管理装置１００に送信された場合に情報処理システム１において行われる処理について説明する。
【００７０】
仮想マシン７０１のマイグレーションに伴う仮想マシン７０１の停止、再起動に際しては、オペレーティングシステムも停止、再起動するため、仮想マシン７０１上で動作するオペレーティングシステム４１１に対してオペレーティングシステム４１１の再起動を条件としてリソースアドレス通知イベント登録を行っている場合には、リソースアドレス通知イベントメッセージが送信される。
【００７１】
また、構成情報管理装置１００のイベントメッセージ受信エンドポイント宛に送信されるイベントメッセージは、イベント受信処理部３０８が受信する。イベントメッセージ解析部３０５は、イベント受信処理部３０８からイベントメッセージを受け取ると処理を開始する。
【００７２】
図２２はリソースアドレス通知イベントメッセージの一例を示す図である。符号２２０１は、イベント通知先エンドポイントであり、図１１に示したリソースアドレス通知イベント登録処理において、イベント通知先アドレス内で指定した値である。また、符号２２０２は、前述のリソースアドレス通知イベント登録処理において、イベント通知先アドレス内で指定したリソース識別子である。これらの情報は、管理対象装置１０１のマイグレーションの前後を通して、管理対象装置１０１上の標準管理エージェント４０１によって、イベント通知登録情報（サブスクリプション）として保持されている。
【００７３】
符号２２０３は、イベント送信元リソースのリソースアドレスである。同図の場合、イベント送信元リソースアドレスは、ＳＯＡＰメッセージのヘッダ部分に存在しているが、ＳＯＡＰメッセージのボディ部分に存在していても良い。図３１はＳＯＡＰメッセージのボディ部分にイベント送信元リソースアドレスの情報が存在する場合におけるリソースアドレス通知イベントメッセージの一例である。同図において、符号３１０３がイベント送信元リソースアドレスの情報を示す。
【００７４】
次に、構成情報管理装置１００が管理対象装置１０１から送られてくるイベントメッセージを受信した場合にイベントメッセージ解析部３０５によって行われる処理について図１３に示すフローチャートとともに説明する。
【００７５】
まずイベントメッセージ解析部３０５は、イベントメッセージ中からリソース識別子を取得する（Ｓ１３００）。イベントメッセージ解析部３０５は、イベントメッセージ中にリソース識別子が存在するか否かを確認する（Ｓ１３０１）。リソース識別子が存在する場合には（Ｓ１３０１：ＹＥＳ）、Ｓ１３０２のリソースアドレス通知イベント処理に進む。リソース識別子が存在しない場合には（Ｓ１３０１：ＮＯ）、処理を終了する。
【００７６】
図１４は、リソースアドレス更新部３０７によって行われるリソースアドレス通知イベント処理（Ｓ１３０２）を説明するフローチャートである。
【００７７】
リソースアドレス更新部３０７は、Ｓ１３００で取得したリソース識別子に一致するレコードをリソース一覧テーブル３１１から検索し、検索したレコードのリソースアドレス（以下、イベント通知登録対象リソースアドレスと称する。）を取得する（Ｓ１４００）。  
次に、リソースアドレス更新部３０７は、イベントメッセージ中からイベント送信元リソースのリソースアドレスの取得処理を開始して（Ｓ１４０１）、リソースアドレス更新部３０７は、イベントメッセージ中にイベント通知の送信元のリソースのリソースアドレス（以下、イベント送信元リソースアドレスと称する。）が存在するか否かを確認する（Ｓ１４０２）。イベントメッセージ中にイベント送信元リソースアドレスが存在する場合には（Ｓ１４０２：ＹＥＳ）、Ｓ１４０３へ進む。イベントメッセージ中にイベント送信元リソースアドレスが存在しない場合には（Ｓ１４０２：ＮＯ）、処理を終了する。
【００７８】
リソースアドレス更新部３０７は、Ｓ１４００で取得したイベント通知登録対象リソースアドレスと、Ｓ１４０１で取得したイベント送信元リソースアドレス（現在のリソースアドレス）とを比較する（Ｓ１４０３）。比較の結果、イベント通知登録対象リソースアドレスとイベント送信元リソースアドレスの値が同じであれば（Ｓ１４０３：ＹＥＳ）、すなわち、イベント通知登録対象リソースアドレスを変更する必要がなければ処理を終了する。一方、イベント通知登録対象リソースアドレスとイベント送信元リソースアドレスの値が異なれば（Ｓ１４０３：ＮＯ）、Ｓ１４０４へ進む。
【００７９】
Ｓ１４０４では、リソースアドレス更新部３０７が、Ｓ１４００で検索したリソース一覧テーブル３１１の該当レコードのリソースアドレスをＳ１４０１で取得したイベント送信元リソースアドレスの値に変更し、また状態１７０４に”有効”を登録する。
【００８０】
リソース一覧テーブル３１１の各レコードのうち状態１７０４に”無効”が登録される場合として、コールドマイグレーションにより仮想マシンが停止した際、仮想マシン上の標準管理エージェント４０１も停止し、標準管理エージェント４０１が公開するリソースアドレスが利用不可能となっていた場合などがある。
【００８１】
以上により、リソースアドレス通知イベント受信に伴って行われる管理対象リソースのリソースアドレス更新処理が完了する。
【００８２】
ところで、イベント通知登録対象リソースアドレスとイベント送信元リソースアドレスとが異なる場合にのみ、管理対象装置１０１から構成情報管理装置１００にイベントメッセージが送信されるように、リソースアドレス通知イベント登録部３０４がイベント通知登録を行うようにしてもよい。この場合はＳ１４０２の判断の結果、イベント送信元リソースアドレスが存在すれば（Ｓ１４０２：ＹＥＳ）、Ｓ１４０３の判断をすることなくＳ１４０４に進むことになる。
【００８３】
図３２にイベント通知登録リクエストメッセージの一例を示す。同図において、符号３２０３で示すイベント発火条件には「イベント通知登録対象リソースアドレスとイベント送信元リソースアドレスとが異なる」という条件が含まれている。
【００８４】
［実施例２］
実施例１ではPull型のリソースアドレス発見方法を用いた例を示したが、本実施例ではPush型のリソースアドレス発見方法について説明する。
【００８５】
図２３はリソースアドレス発見部３０１の処理の一例を示すフローチャートである。同図において、まずリソースアドレス発見部３０１は、管理エンドポイントテーブル３１０から管理エンドポイント情報を取得する（Ｓ２３００）。
【００８６】
次に、リソースアドレス発見部３０１は、管理エンドポイントテーブル３１０から取得した各管理エンドポイントに対してインスタンス生成イベントの通知登録を行う（Ｓ２３０１）。例えば標準管理エージェント４０１がWS-Managementに準拠する場合には、Subscribeリクエストを送信する。実施例１と同様に、標準管理エージェント４０１に対するリクエスト送信処理、標準管理エージェント４０１からのレスポンスの受信処理は、リソースアクセス処理部３０６が実施する。
【００８７】
以上により標準管理エージェント４０１において新たに管理対象リソースのインスタンスが生成された場合には、構成情報管理装置１００に対してインスタンス生成イベントメッセージが送信されるようになる。
【００８８】
次に、構成情報管理装置１００がイベントメッセージを受信した場合に行われる処理について説明する。構成情報管理装置１００のイベントメッセージ受信エンドポイント宛に送信されるイベントメッセージをイベント受信処理部３０８が受信すると、イベントメッセージ解析部３０５はイベント受信処理部３０８からイベントメッセージを受け取る。
【００８９】
図２４は、Push型の場合のリソースアドレス発見処理を示すフローチャートである。このフローチャートは図１３で説明したイベントメッセージ解析処理にインスタンス生成イベント受信処理のために必要な処理を追加した構成になっている。同図におけるＳ２４００〜Ｓ２４０２の処理は、図１３のＳ１３００〜Ｓ１３０２と同様である。
【００９０】
Ｓ２４０３において、イベントメッセージ解析部３０５は、受信したイベントメッセージのイベント種別がインスタンス生成イベントであるか否かを判定する。Ｓ２４０３で判別したイベント種別がインスタンス生成イベントであれば（Ｓ２４０４：ＹＥＳ）、Ｓ２４０５へ進み、そうでなければ（Ｓ２４０４：ＮＯ）、処理を終了する。
【００９１】
図２５は、図２４のＳ２４０５で示すリソースアドレス発見処理（Push型）（2）を説明するフローチャートである。同図に示すように、リソースアドレス発見部３０１は、インスタンス生成イベントメッセージから、生成されたインスタンスのリソースアドレスを取得する（Ｓ２５００）。そしてリソースアドレス発見部３０１は、図１０に示したリソースアドレス登録処理を呼び出す（Ｓ２５０１）。
【００９２】
［実施例３］
実施例１ではPull型のリソース情報収集方法を用いた例を示したが、実施例３ではPush型リソース情報収集方法について説明する。
【００９３】
図２６はリソース情報収集更新部３０３の処理の一例を示すフローチャートである。同図において、まずリソース情報収集更新部３０３は、リソース一覧テーブル３１１からリソースアドレスを取得する（Ｓ２６００）。
【００９４】
次に、リソース情報収集更新部３０３は、イベント通知登録リクエストメッセージを生成する（Ｓ２６０１）。この処理において、リソース情報収集更新部３０３は、Ｓ２６００で取得したリソース識別子、及び構成情報管理装置１００のイベントメッセージ受信エンドポイントを含むイベント通知先アドレスを生成する。
【００９５】
リソース情報収集更新部３０３は、Ｓ２６００で取得した各リソースアドレスに対してインスタンス変更イベント通知登録を行う（Ｓ２６０２）。例えば標準管理エージェント４０１がWS-Managementに準拠する場合、Subscribeリクエストを送信する。実施例１と同様に、標準管理エージェント４０１に対するリクエスト送信処理、標準管理エージェント４０１からのレスポンス受信処理は、リソースアクセス処理部３０６が実施する。
【００９６】
以上により、標準管理エージェント４０１において、管理対象リソースに関する変更があった場合、構成情報管理装置に対してインスタンス変更イベントメッセージが送信される。
【００９７】
次に、構成情報管理装置１００がイベントメッセージを受信した場合に行われる処理について説明する。構成情報管理装置１００のイベントメッセージ受信エンドポイント宛に送信されるイベントメッセージをイベント受信処理部３０８が受信すると、イベントメッセージ解析部３０５は、イベント受信処理部３０８からイベントメッセージを受け取る。
【００９８】
図２７は、Push型の場合のイベントメッセージ解析処理を示すフローチャートである。このフローチャートは図１３で説明したイベントメッセージ解析処理にインスタンス変更イベントメッセージ受信処理のために必要な処理を追加した構成となっている。同図におけるＳ２７００〜Ｓ２７０２の処理は前述のＳ１３００〜Ｓ１３０２と同様である。
【００９９】
イベントメッセージ解析部３０５は、Ｓ２７０２の後、受信したイベントメッセージのイベント種別がインスタンス変更イベントであるか否かを判定する（Ｓ２７０３）。Ｓ２７０３で判別したイベント種別がインスタンス変更イベントであれば（Ｓ２７０４：ＹＥＳ）、Ｓ２７０５に進み、そうでなければ（Ｓ２７０４：ＮＯ）、処理を終了する。
【０１００】
図２８は、図２７のＳ２７０５で示すリソース情報収集更新処理（Push型）（2）を示すフローチャートである。まずリソース情報収集更新部３０３は、取得したインスタンス変更イベントメッセージからインスタンス情報を取得する（Ｓ２８００）。
【０１０１】
次に、リソース情報収集更新部３０３は、Ｓ２７００で取得したリソース識別子を用いてリソース情報テーブル３１３、又はリソース間関連テーブル３１４の該当するレコードを検索し、Ｓ２８００で取得したインスタンス情報を更新する（Ｓ２８０１）。
【０１０２】
リソース情報収集更新部３０３は、Ｓ２７００で取得したリソース識別子を用い、リソース一覧テーブル３１１から、リソースアドレス通知イベント登録の値を取得する（Ｓ２８０２）。
【０１０３】
リソース情報収集更新部３０３は、Ｓ２８０２で取得したリソースアドレス通知イベント登録の値を確認する（Ｓ２８０３）。ここで値が”有”であれば（Ｓ２８０３：ＹＥＳ）、Ｓ２７００で取得したリソース識別子を用いてリソース一覧テーブル３１１の該当するレコードを検索し、状態１７０４に”有効”を登録し（Ｓ２８０４）、値が”無”であれば（Ｓ２８０３：ＮＯ）処理を終了する。
【０１０４】
以上に説明した実施例１〜実施例３に示した構成によれば、管理対象であるリソースを識別又は特定する情報であるリソースアドレスが変化した場合でもリソースを効率よく適切に管理することができる。
【０１０５】
また、構成情報管理装置１００は、仮想マシンである管理対象装置１０１上で動作するオペレーティングシステム４１１を、仮想マシンのマイグレーションの前後を通して継続的に識別することができる。換言すれば、仮想マシンのマイグレーションにより、仮想マシン上で動作していたオペレーティングシステム４１１が提供していたリソースアドレスが変化したとしてもマイグレーション以前に管理していた管理対象リソースと同一のリソースであることを判別することができる。従って、構成情報管理装置１００は、構成情報管理装置１００の利用者に対し、継続的かつ一貫した情報を提供することができる。
【０１０６】
より具体的には、構成情報管理装置１００は、管理対象装置１０１の構成情報を収集・管理する場合に、管理対象装置１０１の情報が変化した場合でも、管理対象装置１０１上のリソースを別リソースと誤認識することなく正しく識別できる。このため、異なるネットワーク環境への移設、マイグレーション、共有ディスクからオペレーティングシステムを起動する際のブレードサーバの変更などが行われた場合でも、構成情報管理装置１００或いは利用装置１０２において、管理対象リソースに関してそれまで蓄えてきた既存の管理情報を修正することなく利用し続けることができる。
【０１０７】
また、以上に説明したように、本実施形態の構成情報管理装置１００は、管理対象リソースを一意に識別するリソース識別子を管理対象リソースに付与し、管理対象リソースの環境が変化した後、標準管理エージェント４０１のイベント通知に関する機能を利用して管理対象リソースからリソース識別子とこれに対応づけられている現在のリソースアドレスとを取得し、構成情報管理装置１００がリソース識別子に対応づけて記憶しているリソースアドレスを現在のリソースアドレスに変更する。
【０１０８】
より具体的には、構成情報管理装置１００は、標準管理エージェント４０１の機能を利用してイベント通知を受信するための情報とリソース識別子とを管理対象リソース側に記憶させ、標準管理エージェント４０１からのイベント通知の受信に際しリソース識別子と管理対象リソースに現在付与されているリソースアドレスとを取得し、リソース識別子に対応づけて記憶しているリソースアドレスを現在のリソースアドレスに変更する。
【０１０９】
このように、管理対象装置１０１へのリソース識別子の記憶や、管理対象リソースからのリソース識別子と現在付与されているリソースアドレスの取得は標準管理エージェント４０１の機能を用いて行われる。このため、本実施形態の情報処理システム１を実現するにあたり、特別なエージェントを管理対象装置１０１に用意する必要がなく、情報処理システム１が複雑化したり運用負担を増大させたりすることもなく、管理対象リソースの構成情報を効率よく管理することができる。
【０１１０】
ところで、標準管理エージェント４０１が、管理対象リソースに関する状態情報（プロパティ）に対する外部からの情報の設定（書込み）を許可している場合には、状態情報を用いて構成情報管理装置１００がリソース識別子を保持するようにすることも考えられる。
【０１１１】
しかしながら、セキュリティ上、標準管理エージェント４０１は外部からの情報書込みを許可されていないことが多く、このような方法を採用できないことも多い。また、複数の構成情報管理装置１００が同一の管理対象リソースにアクセスする情報処理システム１では、各構成情報管理装置１００に同一のプロパティを用いてリソース識別子を保持させることはできない。
【０１１２】
これに対し本実施形態の構成では、構成情報管理装置１００ごとに異なるイベント通知登録情報（サブスクリプション）を保持させることが可能であるのでセキュリティを確保しつつ各構成情報管理装置１００が独自にリソースの識別子を管理することができる。
【０１１３】
なお、以上の実施形態の説明は、本発明の理解を容易にするためのものであり、本発明を限定するものではない。本発明はその趣旨を逸脱することなく、変更、改良され得ると共に本発明にはその等価物が含まれることは勿論である。
【図面の簡単な説明】
【０１１４】
【図１】本発明の実施の形態として説明する情報処理システム１の構成を示す図である。
【図２】本発明の実施の形態として説明する構成情報管理装置１００、管理対象装置１０１、及び利用装置１０２として用いられる情報処理装置（コンピュータ）のハードウェア構成の一例を示す図である。
【図３】本発明の実施の形態として説明する構成情報管理装置１００によって実現される機能、及び構成情報管理装置１００が記憶しているデータである。
【図４】本発明の実施の形態として説明する管理対象装置１０１において実現される機能、及び管理対象装置１０１が記憶しているデータである。
【図５】本発明の実施の形態として説明する本発明の実施の形態として説明する管理対象装置１０１において実現される機能、及び管理対象装置１０１が記憶しているデータである。
【図６】本発明の実施の形態として説明する本発明の実施の形態として説明する管理対象装置１０１において実現される機能、及び管理対象装置１０１が記憶しているデータである。
【図７】本発明の実施の形態として説明する管理対象装置１０１が仮想マシンである場合における管理対象装置１０１の構成を示す図である。
【図８】本発明の実施の形態として説明する管理対象装置１０１（仮想マシン）のマイグレーションを示す図である。
【図９】本発明の実施の形態として説明するリソースアドレス発見部３０１の処理を示すフローチャートである。
【図１０】本発明の実施の形態として説明するリソースアドレス登録部３０２の処理を示すフローチャートである。
【図１１】本発明の実施の形態として説明するリソースアドレス通知イベント登録部の処理を示すフローチャートである。
【図１２】本発明の実施の形態として説明するリソース情報収集更新部３０３の処理（Pull型）を示すフローチャートである。
【図１３】本発明の実施の形態として説明するイベントメッセージ解析部３０５の処理を示すフローチャートである。
【図１４】本発明の実施の形態として説明するリソースアドレス更新部３０７の処理を示すフローチャートである。
【図１５】本発明の実施の形態として説明する管理エンドポイントテーブル３１０の一例である。
【図１６】本発明の実施の形態として説明するWS-Addressingに基づくリソースアドレスの一例である。
【図１７】本発明の実施の形態として説明するリソース一覧テーブル３１１の一例である。
【図１８】本発明の実施の形態として説明するリソースアドレス通知イベント条件テーブル３１２の一例である。
【図１９】本発明の実施の形態として説明するWS-Managementを用いる場合のイベント通知先アドレスの一例である。
【図２０】本発明の実施の形態として説明するリソース情報テーブル３１３の一例である。
【図２１】本発明の実施の形態として説明するリソース間関連テーブル３１４の一例である。
【図２２】本発明の実施の形態として説明するリソースアドレス通知イベントメッセージの一例である。
【図２３】本発明の実施の形態として説明するリソースアドレス発見部３０１の処理（Push型）の一例を示すフローチャートである。
【図２４】本発明の実施の形態として説明するイベントメッセージ解析処理を示すフローチャートである。
【図２５】本発明の実施の形態として説明するリソースアドレス発見処理（Push型）を説明するフローチャートである。
【図２６】本発明の実施の形態として説明するリソース情報収集更新部の処理（Push型）を示すフローチャートである。
【図２７】本発明の実施の形態として説明するイベントメッセージ解析部の処理を示すフローチャートである。
【図２８】本発明の実施の形態として説明するリソース情報収集更新部の処理（Push型）を示すフローチャートである。
【図２９】本発明の実施の形態として説明するイベント通知登録（サブスクライブ）リクエストメッセージの一例を示す図である。
【図３０】本発明の実施の形態として説明するイベント通知登録リクエストメッセージの一例を示す図である。
【図３１】本発明の実施の形態として説明するリソースアドレス通知イベントメッセージの一例を示す図である。
【図３２】本発明の実施の形態として説明するイベント通知登録リクエストメッセージの一例を示す図である。
【符号の説明】
【０１１５】
１  情報処理システム
１００  構成情報管理装置
１０１  管理対象装置
１０２  利用装置
３０１  リソースアドレス発見部
３０２  リソースアドレス登録部
３０３  リソース情報収集更新部
３０４  リソースアドレス通知イベント登録部
３０５  イベントメッセージ解析部
３０６  リソースアクセス処理部
３０７  リソースアドレス更新部
３０８  イベント受信処理部
３０９  クライアントアクセス処理部
３１０  管理エンドポイントテーブル
３１１  リソース一覧テーブル
３１２  リソースアドレス通知イベント条件テーブル
３１３  リソース情報テーブル
３１４  リソース間関連テーブル
４０１  標準管理エージェント
４１１  オペレーティングシステム
４０３  クライアントアクセス処理部
４０４  オブジェクト管理部
４０５  実リソースアクセス部
４０６  管理オブジェクト定義情報
４０７  管理オブジェクトインスタンス情報
７００  物理マシン
７０１  仮想マシン
７０２  仮想化環境
【図１】
2009151560.tif 000003
【図２】
2009151560.tif 000004
【図３】
2009151560.tif 000005
【図４】
2009151560.tif 000006
【図５】
2009151560.tif 000007
【図６】
2009151560.tif 000008
【図７】
2009151560.tif 000009
【図８】
2009151560.tif 000010
【図９】
2009151560.tif 000011
【図１０】
2009151560.tif 000012
【図１１】
2009151560.tif 000013
【図１２】
2009151560.tif 000014
【図１３】
2009151560.tif 000015
【図１４】
2009151560.tif 000016
【図１５】
2009151560.tif 000017
【図１６】
2009151560.tif 000018
【図１７】
2009151560.tif 000019
【図１８】
2009151560.tif 000020
【図１９】
2009151560.tif 000021
【図２０】
2009151560.tif 000022
【図２１】
2009151560.tif 000023
【図２２】
2009151560.tif 000024
【図２３】
2009151560.tif 000025
【図２４】
2009151560.tif 000026
【図２５】
2009151560.tif 000027
【図２６】
2009151560.tif 000028
【図２７】
2009151560.tif 000029
【図２８】
2009151560.tif 000030
【図２９】
2009151560.tif 000031
【図３０】
2009151560.tif 000032
【図３１】
2009151560.tif 000033
【図３２】
2009151560.tif 000034