複数のサービス構成要素に対応するアクションの実行を管理するためのコンピュータ・システム、並びにその方法及びコンピュータ・プログラム
【課題】サービス・プロセス間の依存関係を把握し、サービス・プロセスの効率的且つ安全な実行をする。
【解決手段】コンピュータ・システムは、構成要素についての情報を検出するディスカバリ部と、該構成要素の所定の属性及び該構成要素と他の構成要素との関係を示す１組のデータを保持するリポジトリと、前記サービス構成要素を対応するアクションの対象である１の構成要素に関連付ける関連付部と、第１のサービス構成要素に対応するアクションの実行中に第２のサービス構成要素に対応するアクションへのリクエストがあり且つ該第２のサービス構成要素に対応するアクションの対象である少なくとも１の構成要素が該第１のサービス構成要素に対応するアクションの対象である構成要素に含まれる場合、該第２のサービス構成要素に対応するアクションを実行することが許されるかどうかを判定する判定部とを含む。
【解決手段】コンピュータ・システムは、構成要素についての情報を検出するディスカバリ部と、該構成要素の所定の属性及び該構成要素と他の構成要素との関係を示す１組のデータを保持するリポジトリと、前記サービス構成要素を対応するアクションの対象である１の構成要素に関連付ける関連付部と、第１のサービス構成要素に対応するアクションの実行中に第２のサービス構成要素に対応するアクションへのリクエストがあり且つ該第２のサービス構成要素に対応するアクションの対象である少なくとも１の構成要素が該第１のサービス構成要素に対応するアクションの対象である構成要素に含まれる場合、該第２のサービス構成要素に対応するアクションを実行することが許されるかどうかを判定する判定部とを含む。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サービス構成要素に対応するアクションの実行を管理するためのコンピュータ・システム、並びにその方法及びコンピュータ・プログラムに関する。
【背景技術】
【０００２】
ＩＴＩＬ（Information Technology Infrastructure Library）（英国政府の商標）とは、ＩＴサービスマネジメントを実現するためのベストプラクティス（最も良い事例）を集めたものである。ＩＴＩＬの中心は、サービスサポート及びサービスデリバリーである。サービスサポートの１つとして構成管理がある。構成管理とは、ＩＴサービスマネジメントの管理対象である構成要素（configuration item、構成アイテムともいう、以下ＣＩと略す場合がある）を認識し、構成要素についての情報を維持及び更新し、確認し、並びに監査を行うプロセスである。構成要素は、構成管理の対象となる資源（リソース）である。構成要素は、ハードウェア及びソフトウェアを含むシステム資源だけでなく、ＩＴサービスの提供に必要な設備、ＩＴサービスの運営に関する規程書、作業手順書及び構成図などのドキュメント類、ハードウェア又はソフトウェアの保守作業などのサービス、プロセス、並びに人的資源なども含む。ＩＴＩＬのフレームワークでは、構成要素を管理するために、構成管理データベース（Configuration Management Database、以下ＣＭＤＢと略す場合がある）というデータベースを用いて一元的に管理することが推奨されている。ＣＭＤＢは、構成要素の少なくとも１つの所定の属性及び他の構成要素との関係を記録するデータベースである。ＣＭＤＢを実装することで備わる最も重要な能力は、構成要素についての情報を自動的に発見する能力（ディスカバリ、自動検出ともいう）及び自動的に更新する能力（トラッキングともいう）である。ＣＭＤＢでは、構成要素についての情報をＣＭＤＢに正確に反映させることが重要である。
【０００３】
インターナショナル・ビジネス・マシーンズ・コーポレーション（商標、以下ＩＢＭ）は、ＣＭＤＢの構築を支援し且つＣＭＤＢを基盤に運用プロセスを制御するソフトとして、「Tivoli Change and Configuration Management Database」（以下、Tivoli CCMDB）を提供している。Tivoli CCMDBにおけるディスカバリ及びトラッキングの詳細は、IBM Redbooks Deployment Guide Series: IBM Tivoli Change and Configuration Management Database Configuration Discovery and Tracking v1.1、第41〜64頁、2006年11月（下記非特許文献１）を参照されたい。Tivoli CCMDBでは、運用管理ソフトが、ディスカバリ及びトラッキングを実行するように実装されている。
【０００４】
Tivoli CCMDBでは、分散ネットワーク環境上の構成要素であるサーバ、クライアント、オペレーティング・システム（ＯＳ）、ミドルウェア（Web/AP/DBMS/LDAPなど）、パッケージ・ソフト、管理ツール、ネットワーク機器及びストレージ機器など300種類を識別し、さらに各構成要素についての情報、例えばコンピュータの構成についての情報、各コンピュータ上で動作するアプリケーションについての情報、各コンピュータに接続されているネットワーク接続ストレージ（ＮＡＳ）などの構成情報、ネットワークに直接接続されているストレージエリアネットワーク（ＳＡＮ）などの構成情報を自動的に発見し及び更新することができる。各構成要素についての情報の収集方法は管理対象によっても異なるが、基本的にはＣＭＤＢを管理するコンピュータ・システムがＳＳＨ（Secure SHell）などを用いて管理用のリモート・インタフェースに定期的にアクセスし、ＯＳ上の設定ファイル又は構成情報を読み取ったり、或いはＣＭＤＢを管理するコンピュータ・システムが設定確認コマンドを実行したりする。そのため、管理対象である構成要素にエージェント・プログラムを導入する必要はない。上記の様式にて発見され且つ更新された情報は、ＩＢＭが提唱する構成管理データベース用のデータ・モデル「Common Data Model」（以下、ＣＤＭ）に基づいて、2006年の時点において、31種類のセクション（Computer System、Database、Application、Processなどのカテゴリ）、636種類のクラス（データ・モデルの基本単位、１つ又は複数のセクションに属する）、2609種類の属性（データの属性情報、１つのクラスに属する）、7種類のインタフェース（使用頻度の高い属性のグループ、複数のセクションに属する）、57種類の関係（リレーションシップ）、及び49種類のデータタイプ（データの種別）に整理される。ＣＤＭの詳細は、IBM REDPAPER (DRAFT version) IBM Tivoli Common Data Model: Guide to Best Practices（IBM Form Number REDP-4389-00）、第2〜7頁、2007年11月（下記非特許文献２）を参照されたい。各構成要素及び該構成要素と他の構成要素との関係についての情報は、ＧＵＩの表示ツール、例えばＴＡＤＤＭコンソールに渡される。そして、各構成要素及び該構成要素と他の構成要素との関係が、個々のブロック及び該ブロック間のリンクを用いて視覚的に表示装置上に表示される。
【０００５】
【非特許文献１】IBM Redbooks Deployment Guide Series: IBM Tivoli Change and Configuration Management Database Configuration Discovery andTracking v1.1、第41〜64頁、2006年11月
【非特許文献２】IBM RED PAPER (DRAFT version) IBM Tivoli Common Data Model: Guide to Best Practices（IBM Form Number REDP-4389-00）、第2〜7頁、2007年11月
【発明の開示】
【発明が解決しようとする課題】
【０００６】
近年、例えばＩＴサービス管理及びビジネスサービス管理のようなサービス管理が注目を集めている。特に、ＩＴＩＬ準拠のサービス管理が注目を集めている。サービス管理では、サービスレベルを満足させるために、サービス・プロセスを効率的に且つ停滞することなく実行する必要がある。ＩＴＩＬ準拠のサービス管理では、サービス・プロセスは、ＣＭＤＢ上のＣＩ情報を参照するオペレーションをプロセス化した複数のタスクから構成される。よって、ＩＴＩＬ準拠のサービス管理では、サービスレベルを満足させるために、ＣＩ情報が十分な頻度で更新される必要がある。
しかし、現状では、アクティブ型のディスカバリ装置が、定期的なポーリングによって構成要素についての情報（以下、ＣＩの情報という）を取得し、次に属性及び関係更新部が、該取得したＣＩの情報に基づいて、ＣＩインスタンスの属性値又は関係値を更新する。そのために、ＣＩインスタンスの更新が行われるまで、それを参照するサービス・プロセスが停滞することになる。また、他のサービス・プロセスが実行されているかどうかはユーザによる判断で行うため、サービス・プロセスが競合し失敗する可能性もある。
従来は、このようにサービス・プロセス間の依存関係を把握することができず、サービス・プロセスの効率的且つ安全な実行をすることができなかった。
【課題を解決するための手段】
【０００７】
本発明は、サービス構成要素に対応するアクションの実行を管理するためのコンピュータ・システムを提供する。該コンピュータ・システムは、
構成要素それぞれについての情報を検出するディスカバリ部と、
構成要素毎に、該構成要素の少なくとも１つの所定の属性及び該構成要素と他の構成要素との関係を示す１組のデータを保持するリポジトリと、
上記サービス構成要素を、該サービス構成要素に対応するアクションの対象である少なくとも１の構成要素に関連付ける関連付部と、
第１のサービス構成要素に対応するアクションの実行中に第２のサービス構成要素に対応するアクションへのリクエストがあり且つ該第２のサービス構成要素に対応するアクションの対象である少なくとも１の構成要素が該第１のサービス構成要素に対応するアクションの対象である構成要素に含まれる場合、該第２のサービス構成要素に対応するアクションを実行することが許されるかどうかを判定する判定部と
を含む。
【０００８】
本発明の１つの実施形態では、上記サービス構成要素が、１又は複数のサービス・プロセス又は該サービス・プロセスに含まれる１又は複数のサービス・ステップである。
【０００９】
本発明の１つの実施形態では、上記判定部が、上記サービス構成要素に対応するアクションを実行することが許されるかどうかを判定するためのルールを定義するポリシーによって上記アクションを実行することが許されるかどうかを判定する。
【００１０】
本発明の１つの実施形態では、上記アクションを実行することが許されるかどうかを判定することをユーザに選択することを可能にするインタフェースを表示部に提示する提示部をさらに含む。
【００１１】
本発明の１つの実施形態では、上記判定部が、上記アクションを実行することが許される場合、上記第２のサービス構成要素に対応するアクションを実行させ、上記判定部が、上記アクションを実行することが許されない場合、上記第２のサービス構成要素に対応するアクションの実行を待機させる。
【００１２】
本発明の１つの実施形態では、上記第１のサービス構成要素に対応するアクションの対象である構成要素が上記第２のサービス構成要素に対応するアクションの対象である構成要素と重複しない場合、上記第２のサービス構成要素に対応するアクションを実行することを許す。
【００１３】
本発明の１つの実施形態では、上記ディスカバリ部が、上記第１又は第２のサービス構成要素に対応するアクションの終了後に、構成要素についての情報を検出する。
【００１４】
本発明の１つの実施形態では、上記ディスカバリ部が、上記第１又は第２のサービス構成要素に対応するアクションの終了後に、該終了したサービス構成要素に対応するアクションの対象である構成要素についての情報を検出する。
【００１５】
本発明の１つの実施形態では、上記ディスカバリ部が、上記第１又は第２のサービス構成要素に対応するアクションの終了後に、上記第１のサービス構成要素に対応するアクションの対象である少なくとも１の構成要素と上記第２のサービス構成要素に対応するアクションの対象である構成要素との重複範囲に含まれる構成要素についての情報を検出する。
【００１６】
本発明の１つの実施形態では、上記関連付けが、上記第１のサービス構成要素に対応するアクションの開始に応じて行われる。
【００１７】
本発明の１つの実施形態では、上記関連付部が、上記第１のサービス構成要素に対応するアクションの終了に応じて、上記関連付けを解除する。
【００１８】
本発明の１つの実施形態では、上記第２のサービス構成要素に対応するアクションの実行が待機している場合、上記判定部が、上記第１のサービス構成要素に対応するアクションの終了に応じて、上記第２のサービス構成要素に対応するアクションを実行することが許されるかどうかをさらに判定する。
【００１９】
本発明の１つの実施形態では、所定の属性及び構成要素と他の構成要素との関係を定義するデータ・モデルが、サービス構成要素のアクション・タイプと該サービス構成要素に対応するアクションの対象である構成要素の範囲とを含む。
【００２０】
本発明はまた、サービス構成要素に対応するアクションの実行を管理する方法を提供する。該方法は、コンピュータ・システムに下記ステップを実行させるステップを含む。該コンピュータ・システムは、構成要素それぞれについての情報を検出するディスカバリ部と、構成要素毎に、該構成要素の少なくとも１つの所定の属性及び該構成要素と他の構成要素との関係を示す１組のデータを保持するリポジトリとを含む。上記方法は、
上記検出された情報に基づいて、構成要素毎に、該構成要素の少なくとも１つの所定の属性及び該構成要素と他の構成要素との関係を示す１組のデータを作成し、該１組のデータをリポジトリに格納するステップと、
上記サービス構成要素を、該サービス構成要素に対応するアクションの対象である少なくとも１の構成要素に関連付けるステップと、
第１のサービス構成要素に対応するアクションの実行中に第２のサービス構成要素に対応するアクションへのリクエストがあり且つ該第２のサービス構成要素に対応するアクションの対象である少なくとも１の構成要素が該第１のサービス構成要素に対応するアクションの対象である構成要素に含まれる場合、該第２のサービス構成要素に対応するアクションを実行することが許されるかどうかを判定するステップと
を含む。
【００２１】
本発明の１つの実施形態では、上記サービス構成要素が、１又は複数のサービス・プロセス又は該サービス・プロセスに含まれる１又は複数のサービス・ステップである。
【００２２】
本発明の１つの実施形態では、上記判定するステップが、上記サービス構成要素に対応するアクションを実行することが許されるかどうかを判定するためのルールを定義するポリシーによって上記アクションを実行することが許されるかどうかを判定するステップを含む。
【００２３】
本発明の１つの実施形態では、上記判定するステップが、上記アクションを実行することが許されるかどうかを判定することをユーザに選択することを可能にするインタフェースを表示部に提示するステップを含む。
【００２４】
本発明の１つの実施形態では、上記コンピュータ・システムに下記ステップを実行させるステップをさらに含む。該ステップは、
上記アクションを実行することが許される場合、上記第２のサービス構成要素に対応するアクションを実行すること許すステップと、
上記アクションを実行することが許されない場合、上記第２のサービス構成要素に対応するアクションの実行を待機させるステップと
を含む。
【００２５】
本発明の１つの実施形態では、上記コンピュータ・システムに下記ステップを実行させるステップをさらに含む。該ステップは、上記第１のサービス構成要素に対応するアクションの対象である構成要素が上記第２のサービス構成要素に対応するアクションの対象である構成要素と重複しない場合、上記第２のサービス構成要素に対応するアクションを実行することを許すステップをさらに含む。
【００２６】
本発明の１つの実施形態では、上記コンピュータ・システムに下記ステップを実行させるステップをさらに含む。該ステップは、上記第１又は第２のサービス構成要素に対応するアクションの終了後に、構成要素についての情報を検出するステップを含む。
【００２７】
本発明の１つの実施形態では、上記コンピュータ・システムに下記ステップを実行させるステップをさらに含む。該ステップは、上記第１又は第２のサービス構成要素に対応するアクションの終了後に、該終了したサービス構成要素に対応するアクションの対象である構成要素についての情報を検出するステップを含む。
【００２８】
本発明の１つの実施形態では、上記コンピュータ・システムに下記ステップを実行させるステップをさらに含む。該ステップは、上記第１又は第２のサービス構成要素に対応するアクションの終了後に、上記第１のサービス構成要素に対応するアクションの対象である少なくとも１の構成要素と上記第２のサービス構成要素に対応するアクションの対象である構成要素との重複範囲に含まれる構成要素についての情報を検出するステップを含む。
【００２９】
本発明の１つの実施形態では、上記関連付けるステップが、上記第１のサービス構成要素に対応するアクションの開始に応じて行われる。
【００３０】
本発明の１つの実施形態では、上記コンピュータ・システムに下記ステップを実行させるステップをさらに含む。該ステップは、上記第１のサービス構成要素に対応するアクションの終了に応じて、上記関連付けを解除するステップを含む。
【００３１】
本発明の１つの実施形態では、上記コンピュータ・システムに下記ステップを実行させるステップをさらに含む。該ステップは、上記第２のサービス構成要素に対応するアクションの実行が待機している場合、上記第１のサービス構成要素に対応するアクションの終了に応じて、上記第２のサービス構成要素に対応するアクションを実行することが許されるかどうかを判定するステップを含む。
【００３２】
本発明はまた、構成要素それぞれについての情報を検出するディスカバリ部と、構成要素毎に、該構成要素の少なくとも１つの所定の属性及び該構成要素と他の構成要素との関係を示す１組のデータを保持するリポジトリとを含むコンピュータ・システムにおいて、サービス構成要素に対応するアクションの実行を管理する方法を提供する。該方法は、コンピュータ・システムに下記ステップを実行させるステップを含む。該ステップは、
上記サービス構成要素を、該サービス構成要素に対応するアクションの対象である少なくとも１の構成要素に関連付けるステップと、
第１のサービス構成要素に対応するアクションの実行中に第２のサービス構成要素に対応するアクションへのリクエストがあり且つ該第２のサービス構成要素に対応するアクションの対象である少なくとも１の構成要素が該第１のサービス構成要素に対応するアクションの対象である構成要素に含まれる場合、
該第２のサービス構成要素に対応するアクションを実行することが許されるかどうかを判定するステップと、
上記アクションを実行することが許される場合、上記第２のサービス構成要素に対応するアクションを実行させるステップと、
上記アクションを実行することが許されない場合、上記第２のサービス構成要素に対応するアクションの実行を待機させるステップと、
上記第１のサービス構成要素に対応するアクションの対象である構成要素が上記第２のサービス構成要素に対応するアクションの対象である構成要素と重複しない場合、上記第２のサービス構成要素に対応するアクションを実行することを許すステップと、
上記第１又は第２のサービス構成要素に対応するアクションの終了後に、構成要素についての情報を検出するステップと
を含む。
【００３３】
本発明はさらに、サービス構成要素に対応するアクションの実行を管理するコンピュータ・プログラムを提供する。該コンピュータ・プログラムは、コンピュータ・システムに、上記のいずれか一つに記載の方法の各ステップを実行させる。
【発明の効果】
【００３４】
本発明の実施形態によれば、サービス構成要素に対応するアクションはその開始時に実行中の他のサービス構成要素（例えば、サービス・プロセス、サービス・ステップ）についての情報を参照できるので、サービス構成要素に対応するアクションよって利用される構成要素の競合が発生しなくなる。また、対象ＣＩへのアクションによっては、サービス構成要素に対応するアクションの同時実行が可能となり、必ずしも待機する必要が無くなる。
【発明を実施するための最良の形態】
【００３５】
以下、ＣＭＤＢに関する基本的な用語を下記に説明する。
本発明の実施形態において、リポジトリは少なくとも１つの１組のデータを格納する。該１組のデータは、構成要素の少なくとも１つの所定の属性及び他の構成要素との関係を示すデータである。該１組のデータは例えば、ソフトウェア構成要素の少なくとも１つの所定の属性及び該ソフトウェア構成要素と他のソフトウェア構成要素又はハードウェア構成要素との関係を示すデータを含む。上記リポジトリは例えば、ＣＭＤＢである。構成要素、及び該構成要素と他の構成要素との関係は例えば、静的な（static）データのインスタンス又はＪａｖａ（サン・マイクロシステムズの商標）のクラスのインスタンスで実装されうる。上記リポジトリは、該１組のデータを保持するものであれば特に限定されないが、好ましい実施形態の１つはＣＭＤＢを記録するＣＭＤＢ記録部である。
・構成要素（ＣＩ）
ＣＩは、ＩＴサービスマネジメントの対象範囲に属する構成要素に対応するデータであり、ＩＴサービスマネジメントにおける管理対象の基本単位である。ＣＩは例えば、ハードウェア及びソフトウェアを含むシステム資源、ＩＴサービスの提供に必要な設備、ＩＴサービスの運営に関する規程書、作業手順書及び構成図などのドキュメント類、ハードウェア又はソフトウェアの保守作業などのサービス、プロセス、並びに人的資源などを含む。今後も様々なタイプのＣＩが、ＣＭＤＢで管理されるようになる。また、各ＣＩはデータ・モデルのインスタンスとしてＣＭＤＢ上で表現される。
・構成管理データベース（ＣＭＤＢ）
ＣＭＤＢは、情報システムの全コンポーネントに関する情報の統合された保管・管理を行うデータベースである。ＣＭＤＢは、各ＣＩの少なくとも１つの所定の属性及び他のＣＩとの関係を記録する。ＣＭＤＢは組織がコンポーネント間の関係を理解することを支援し、その構成を管理できるようにする。ＣＭＤＢはＩＴＩＬフレームワークの構成管理プロセスの中核となっている。ＣＭＤＢは、概念的にはデータベースであるが、物理的にはデータベース・システム、表計算ソフトのスプレッドシートの形態を取りうる。ＣＭＤＢを利用することによって、管理者はＣＩ間の関係を理解することが容易になる。
・構成要素インスタンス（ＣＩインスタンス）
ＣＩインスタンスは、ＣＩに対応するデータである。各ＣＩインスタンスは、データ・モデルのインスタンスとしてＣＭＤＢ上で表現される。インスタンスの例は、静的なデータのインスタンス又はＪａｖａ（サン・マイクロシステムズの商標）のクラスのインスタンスである。実装されたＪａｖａのクラスのインスタンスは、例えばJava Data Objects（ＪＤＯ）と呼ばれる、Ｊａｖａのクラスのインスタンスを永続化してハードディスクに保存する仕組みにより、ＣＭＤＢ内に格納される。よって、コンピュータ・システムの電源を一旦切っても、作成されたＪａｖａのクラスのインスタンスが消失することはなく、次に電源を投入したときに、記憶装置、例えばハードディスクから読み出され、メイン・メモリ上に展開されて、Ｊａｖａのプログラムによって変更或いは削除可能なＪａｖａのクラスのインスタンスとなる。以下では、ＣＩがインスタンスとしてＣＭＤＢ内に実装されるとして、説明を進める場合がある。
・データ・モデル
データ・モデルは、ＣＩを定義するためのスキーマであり、管理されるＣＩとそれらＣＩ間の関係の一貫した定義を提供する情報モデルである。具体的には、データ・モデルは、ＣＩの所定の属性及び他のＣＩ（製造装置、プロセスなど）との関係を定義する。データ・モデルの例として、ＩＢＭが提唱する構成管理データベース用のデータ・モデル「ＣＤＭ」がある。ＣＤＭの実装は例えば、Unified Modeling Language（ＵＭＬ）に基づいて行われる。
・属性（Attributes）
属性は、ＣＩを管理するに際して、個々のＣＩを特定し、ＣＩを説明する。属性として、下記のものを挙げることができるがこれらに限定されない。ＣＩの名前（ＣＩの一般名称、例えばサーバ、クライアント、ファイアウォール）、製品番号（ＩＤ）（ＣＩのある特定の実体を個別に識別するための番号であり、製造番号、シリアル番号など）、カテゴリ（ＣＩの分類、例えばハードウェア、ソフトウェア、ドキュメント）、タイプ（カテゴリでの分類をさらに詳述したＣＩの説明）、型番（供給者の命名したＣＩのモデル番号）、保証期間（ＣＩの供給者による保証期間）、バージョン番号（ＣＩのバージョン番号）、ロケーション（ＣＩが存在する場所、例えばＰＣの設置場所、ソフトウェアの書庫、媒体の保管場所、サービスを提供しているサイト）、所有責任者（ＣＩの管理責任者の名前）、責任開始日（所有責任者が、該ＣＩの責任者となった日付）、供給者（ＣＩの開発元又は提供元）、ライセンス（ライセンス番号、ライセンス数など）、提供日（ＣＩが組織に提供された日付）、受入日（ＣＩが組織に受け入れられた日付）、使用開始日（ＣＩが使用開始された日付）、ＣＩのステータス（現在のステータス、例えば稼働中、テスト中、故障中、或いは将来のステータス、例えば予定されているＣＩのステータス）、ＣＩインスタンスのステータス（ＣＩインスタンスの有効又は無効）。今後もＩＴサービスマネジメントで必要となる属性が、引き続き定義されていく。
・関係（Relation）
関係は、ＣＩ間の関係を表す。関係は、ＣＩと同様にデータ・モデルで定義されうる。関係の例として、Ｃｏｍｍｏｎ Ｄａｔａ Ｍｏｄｅｌ では、assigns、canConnect、canUse、connectAt、connects、controls、deployedOn、Located、Managed、Owned、provides、runAt、uses、usedByが挙げられる。今後もＩＴサービスマネジメントで必要となる関係が、引き続き定義されていく。
【００３６】
本発明の実施形態において、構成要素は、典型的に、ハードウェア構成要素及び／又はソフトウェア構成要素と、サービス構成要素とを含む。本発明の実施形態において、サービス構成要素に対応するアクションの実行を管理するためのコンピュータ・システムは、これら構成要素を含む単一又は複数のシステムを管理対象とする。該複数のシステムは、ネットワークによって有線又は無線接続されうる。
【００３７】
サービス構成要素とは、１つのサービス・プロセス、複数のサービス・プロセス、１つのサービス・ステップ及び複数のサービス・ステップから選択されるサービスである。サービス・プロセスは、少なくとも１のサービス・ステップを含む。
よって、本発明の実施形態において、第１のサービス構成要素は、１つのサービス・プロセス、複数のサービス・プロセス、１つのサービス・ステップ及び複数のサービス・ステップから選択されるサービス構成要素である。同様に、本発明の実施形態において、第２のサービス構成要素は、１つのサービス・プロセス、複数のサービス・プロセス、１つのサービス・ステップ及び複数のサービス・ステップから選択されるサービス構成要素である。
【００３８】
本発明の実施形態において「アクション」とは、サービス構成要素に対応するアクションの内容に従い、該アクションの対象である少なくとも１つの構成要素に対して行う処理をいう。
アクション・タイプとは、アクションの対象である構成要素に対して行う処理の種類である。アクション・タイプは例えば、新規、変更、削除、参照、検索などを含むが、これらに限定されない。新規とは例えば、アクションの対象である構成要素がデータベースの場合、該データベースにデータを追加する処理である。変更とは例えば、アクションの対象である構成要素がデータベースの場合、該データベース中のデータを更新する処理である。削除とは例えば、アクションの対象である構成要素がデータベースの場合、該データベース中のデータを削除する処理である。参照とは例えば、アクションの対象である構成要素がデータベースの場合、該データベース中のデータを参照する処理である。検索とは例えば、アクションの対象である構成要素がデータベースの場合、該データベースのデータ中のデータをクエリに従い検索する処理である。
アクション・タイプが新規、変更、削除の場合、アクションの対象である構成要素についての属性値が変化する。該変化する属性値が複数のサービス構成要素から共通で利用される場合、該複数のサービスを実行する順によって、該複数のサービス構成要素についての属性値に違いが生じうる。
一方、アクション・タイプが参照及び検索の場合、該構成要素についての属性値は変化しない。よって、該変化する属性値が複数のサービスから共通で利用される属性値であっても、該複数のサービスが実行される順によらず、該複数のサービスの実行結果は同じである。
【００３９】
本発明の実施形態において「サービス構成要素に対応するアクションの対象である」とは、サービス構成要素に対応するアクションの実行により影響を受ける構成要素を示す。なお、本発明の実施形態において、影響を受ける対象は、アクションの影響範囲によって特定されうる。該範囲は、データ・モデルに規定された範囲によって又はユーザによって対象ＣＩ属性に設定されうる。データ・モデルは、モデル・テーブル（下記図１Ａ、１０７を参照）に格納されうる。該範囲は例えば、ノードとの距離を示すレベル、ＣＩインスタンスのモデル名、関係を用いた式で表されるが、これらに限定されない。該範囲はまた、サービス構成要素に対応するアクションの対象範囲を特定するために使用されるポリシー（以下、対象範囲特定ポリシー）によって動的に決定されうる。
「ノードとの距離を示すレベル」の１つの態様として、サービス構成要素を親ノード（０ノード）として表した場合に、該サービス構成要素と１ノードの関係にあるサービス構成要素をレベル０、レベル１の構成要素と１ノードの関係にある構成要素をレベル１、レベル１の構成要素と１ノードの関係にある構成要素をレベル２、・・・、レベルｎの構成要素とｎノードの関係にある構成要素をレベルｎ＋１、と表す。
「ノードとの距離を示すレベル」の他の態様として、サービス構成要素をノードとして表した場合、サービス構成要素と関係のある構成要素をレベル０、レベル０の構成要素と関係のある構成要素をレベル１、レベル１の構成要素と関係のある構成要素をレベル２、・・・、レベルｎの構成要素と関係のある構成要素をレベルｎ＋１、と表す。例えば、ノードに対応するアクション構成要素についてデータベースを更新するアプリケーションとした場合、データベースに対応する構成要素はレベル０であり、該データベースがインストールされているＯＳはレベル１であり、該ＯＳがインストールされているコンピュータはレベル２である。上記関係は、例えば、runsOn and useなどの構成要素間の関係によっても特定されうる。
「ＣＩインスタンスのモデル名」とは、ＣＩインスタンスに定義される該インスタンスが、どのデータ・モデルを使用して作成されたかを示すモデル名である。代替的に、ＣＩインスタンスに定義される該インスタンスがどのＣＩのものであるかを特定するための「インスタンス名」を使用してもよい。
「関係を用いた式」とは例えば、runsOn and useなどの構成要素間の関係で表されるが、これらに限定されない。該例は、サービス構成要素に対応するアクション上で動いている構成要素（サービス構成要素を含む）に対応するアクションを使用している構成要素が、サービス構成要素に対応するアクションの実行により影響を受ける構成要素であることを示す。
「対象範囲特定ポリシー」は、サービス構成要素と関係のある構成要素を決めるために使用されうる。該対象範囲ポリシーは、構成要素、特にサービス構成要素、ソフトウェア構成要素、ハードウェア構成要素の属性及びこれら構成要素間の関係の少なくとも１以上の条件を用いて定義される。
【００４０】
本発明の実施形態において「実行可否を判定するためのルールを定義するポリシー」（以下、可否判定ポリシー）とは、複数のサービスによって共通する構成要素が利用される場合の動作ルールを定義したデータである。可否判定ポリシーは例えば、先行のサービス構成要素に対応するアクション（以下、先行プロセス）のアクション・タイプ及び後発のサービス構成要素に対応するアクション（以下、後発プロセス）のアクション・タイプに応じた後発プロセスの動作で表される。
【００４１】
本発明の実施形態において、ステータス制御部が可否判定ポリシーを使用して、サービス構成要素に対応するアクションの実行可否を判定しうる。ステータス制御部は、サービス・プロセスを管理するために、実行中のサービス構成要素についての対象ＣＩ属性を管理する。対象ＣＩ属性は、サービス・プロセスに対応するアクションの対象であるＣＩ（以下、サービス・プロセスの対象ＣＩに対するアクション・タイプ及び影響範囲）を表す。
【００４２】
以下、図面に従って、本発明の実施形態を説明する。本実施形態は、本発明の好適な態様を説明するためのものであり、本発明の範囲をここで示すものに限定する意図はないことを理解されたい。また、以下の図を通して、特に断らない限り、同一符号は、同一の対象を指す。
【００４３】
図１Ａは、ＣＩを管理するための、ＣＭＤＢを含む従来のコンピュータ・システム（１００）の例を示す。
図１Ａは、ＣＩの例として、サービスＡ及びサービスＢを記載する。
コンピュータ・システム（１００）は、ディスカバリ部（１０１）、ＣＩ同定部（１０２）、ＣＩインスタンス作成部（１０３）、属性及び関係更新部（１０４）及びＣＭＤＢ（１０５）を含む。ディスカバリ部、ＣＩ同定部、ＣＩインスタンス作成部、属性及び関係更新部及びＣＭＤＢは、単独のコンピュータ上に実装されていてもよく、或いは複数のコンピュータ上に分散して実装されていてもよい。コンピュータ・システム（１００）はさらに、ディスカバリ・テーブル（１０６）、モデル・テーブル（１０７）及び関係テーブル（１０８）を含む。これらテーブルは、単独のコンピュータ上に実装されていてもよく、或いは複数のコンピュータ上に分散して実装されていてもよい。
また、図１Ａは、ＴＡＤＤＭコンソールの画面（１０９）の例を示す。該画面は、ＣＩ及びＣＩ間の接続関係を示す。なお、該画面に表示されているＣＩ及びＣＩ間の接続関係は一例であり、コンピュータ・システム（１００）の管理対象であるＣＩ及びＣＩ間の接続関係全てを表示しているものではない。
コンピュータ・システム（１００）は、それ自身の管理対象である構成要素を管理する。コンピュータ・システム（１００）の管理対象は、該コンピュータ・システム（１００）がディスカバリしうる対象の構成要素である。
【００４４】
ディスカバリ部（１０１）は、ＣＭＤＢの管理対象であるＣＩについての情報の検出を実行する（ディスカバーともいう）。該ＣＩの一部が、ＴＡＤＤＭコンソールの画面（１０９）に表示されている。コンピュータ・システム（１００）は、複数のディスカバリ部（１０１）を有していてもよい。好ましくは、管理対象は、ネットワークを介して、コンピュータ・システムに接続されている。ネットワークは、有線接続であるか無線接続であるかを問わない。コンピュータ・システムの管理者は、検出の対象を任意に設定しうる。検出の範囲は例えば、ドメイン名、ＩＰアドレス、ＭＡＣアドレス、機器の識別子若しくはデータベース名又はこれらの組み合わせにより指定することができる。管理対象であるＣＩが例えば機器又はサービスである場合、該機器又はサービスについての情報が夫々検出される。検出された情報は、新たなＣＩについての情報、又は既存のＣＩの更新された属性若しくは関係の値でありうる。新たなＣＩとは、ディスカバリ部（１０１）によって検出され、ＣＭＤＢ（１０５）内に登録されていないＣＩである。既存のＣＩとは、該ＣＩのインスタンスがＣＭＤＢ（１０５）内に既に登録されているＣＩである。ディスカバリ部（１０１）は、ＣＩについての情報を、ディスカバリ・テーブル（１０６）内に格納されたディスカバリ・データ（例えばA-Discovery）（図２Ｂ、２０２）に従い検出する。どのディスカバリ・データを使用するかは、データ・モデル（図２Ｂ、２０１）内のディスカバリ方法に指定されている。ディスカバリ部（１０１）は、検出した、ＣＩについての情報をＣＩ同定部（１０２）に渡す。
【００４５】
ＣＩ同定部（１０２）は、上記ＣＩについての情報をディスカバリ部（１０１）から受け取り、そして検出結果の処理を行う。ＣＩ同定部（１０２）は、上記ＣＩについての情報が、新しいＣＩについての情報か、又は既存のＣＩの更新された属性若しくは関係の値かどうかを、ＣＭＤＢ（１０５）を参照して判定する。該判定は例えば、ＣＭＤＢに格納されたＣＩのインスタンス名を、上記ＣＩについての情報と比較して行われうる。上記ＣＩについての情報が新しいＣＩに関するものであることに応じて、ＣＩ同定部（１０２）は、該情報をＣＩインスタンス作成部（１０３）に渡す。一方、上記ＣＩについての情報が既存のＣＩの更新された属性若しくは関係の値であることに応じて、ＣＩ同定部（１０２）は、該情報を属性及び関係更新部（１０４）に渡す。
【００４６】
ＣＩインスタンス作成部（１０３）は、モデル・テーブル（１０７）に格納されたデータ・モデル（図２Ｂ、２０１）、及び関係テーブル（１０８）に格納された関係モデル（図２Ｂ、２０４）に従い、ＣＩについての情報から、該ＣＩの所定の属性及び他のＣＩとの関係を示す１組のデータを作成する。該１組のデータは例えば、静的なデータのインスタンス又はＪａｖａ（サン・マイクロシステムズの商標）のクラスのインスタンスで実装されうる。該１組のデータの例が、ＣＩインスタンスである。ＣＩインスタンスの例を図２Ｂ（２０３）に示す。上記１組のデータは、ＣＭＤＢ（１０５）内に格納される。なお、１組のデータは、ＣＩインスタンス内に属性及び関係を有していてもよく（図２Ｂ、２０３を参照）、或いはＣＩインスタンス内に属性を有し、それとは別に関係インスタンスとして別々にＣＭＤＢ（１０５）内に格納されていてもよい。後者の場合、ＣＩインスタンスは、関連する関係インスタンスを特定するためのリンク付けを有する。
【００４７】
属性及び関係更新部（１０４）は、ディスカバリ部（１０１）とともにトラッキングを実現する。属性及び関係更新部（１０４）は、ＣＩの更新された属性若しくは関係の値を、ＣＭＤＢ内に格納された該ＣＩのＣＩインスタンスに反映する。すなわち、該ＣＩのＣＩインスタンスの属性或いは関係の値を更新する。該更新は、該値をディスカバリ部（１０１）によって検出されたＣＩについての情報と置き換えることによって行われる。該置き換えは、ＣＩインスタンスの属性或いは関係の値のすべてをディスカバリ部（１０１）によって検出されたＣＩについての情報と置き換えてもよく、或いは異なる値のみを置き換えてもよい。
【００４８】
ＣＭＤＢ（１０５）は、ＣＩのＣＩインスタンス（図２Ｂ、２０３）を格納する。
【００４９】
ディスカバリ・テーブル（１０６）は、ディスカバリ・データ（図２Ｂ、２０２）を格納する。ディスカバリ・データは、ディスカバリ部（１０１）によってＣＩについての情報が検出される際に使用される。ディスカバリ・データ（図２Ｂ、２０２）は例えば、静的なデータのインスタンス又はＪａｖａ（サン・マイクロシステムズの商標）のクラスのインスタンスで実装されうる。ディスカバリ・データは、ディスカバリ・ポリシーとも呼ばれる。ディスカバリ・データ（図２Ｂ、２０２）は、ディスカバリ部（１０１）が検索する範囲、すなわちＣＩの検索範囲である収集対象（スコープ）、収集する属性、及び収集する関係を含む（図２Ｂ、２０２）。収集対象は例えば、サブネットＩＰアドレス、ＩＰアドレスの範囲、個々のＩＰアドレス、ＭＡＣアドレス、機器の識別子、ホストネーム若しくはデータベース名又はそれらの組み合わせを用いて指定されうる。別の態様として、収集対象を、コンピュータ・システム（１００）にネットワークを介して接続されたスケジュール管理データベース（図示せず）としてもよい。スケジュール管理データベースには例えば、機器を使用するプロセス管理に関するデータが格納されている。さらに別の態様として、収集対象を、バッチ処理定義ファイルを格納するデータベース（図示せず）としてもよい。収集対象がバッチ処理定義ファイルを格納するデータベースの場合、ディスカバリ部（１０１）は、バッチ処理定義ファイルの中身を読み込むことにより検出を行う。バッチ処理定義ファイルには、例えば機器をどの順に使用するかのデータが格納されている。
【００５０】
モデル・テーブル（１０７）は、データ・モデル（図２Ｂ、２０１）を格納する。データ・モデルは、ＣＩインスタンス作成部（１０３）によって該ＣＩの所定の属性及び他のＣＩとの関係を示す１組のデータが作成される際に使用される。
【００５１】
関係テーブル（１０８）は、関係モデル（図２Ｂ、２０４）を格納する。関係モデルは、ＣＩインスタンス作成部（１０３）によって該ＣＩの所定の属性及び他のＣＩとの関係を示す１組のデータが作成される際に使用される。
【００５２】
図１Ａは、ディスカバリ部（１０１）が、コンピュータ・システム（１００）とネットワークを介して接続された管理対象であるＣＩに関する情報を検出し、サービスＡ、及びサービスＢ並びにそれらサービスの関係についての情報を検出したことを示す。次に、ＣＩ同定部（１０２）は、該検出した情報が新しいＣＩについてのものかについてＣＭＤＢ（１０５）を参照して判断する。該判断に応じて、ＣＩインスタンス作成部（１０３）は、サービスＡのＣＩインスタンス及びサービスＢのＣＩインスタンス、並びにそれらサービスの関係（usedBy）のインスタンスを作成する。ＣＩインスタンス作成部（１０３）は、該作成した各インスタンスをＣＭＤＢ（１０５）内に格納する。図１Ａでは、サービスＢのＣＩインスタンスが、サービスＡのＣＩインスタンスとusedByの関係にあることを示す。
ディスカバリ部（１０１）は、検出したＣＩについての情報をもとに、データ・モデル（図２Ｂ、２０１）に従って、ＣＩ及びそれらＣＩ間の関係を作成し、ＣＭＤＢ（１０５）に登録する。ＣＭＤＢ（１０５）は、ＣＩの属性及び他のＣＩとの関係を格納する。従って、システム管理者は、ＣＭＤＢ（１０５）を用いて、ＣＩ間のリアルな依存関係を抽出することが可能である。
【００５３】
図１Ａでは、構成要素としてサービス構成要素であるサービスＡ及びサービスＢを例にして説明した。上記説明は、サービス構成要素をハードウェア構成要素及びその他の構成要素に置き換えた場合にも同様に適用される。
【００５４】
図１Ｂは、構成管理のためのツールの概要を示す。
構成管理のためのツールは、構成要素についての情報（以下、単に構成情報という場合がある）を自動収集する機能（ディスカバリ）、構成情報をグラフィカルに表示する機能（トポロジー）及び変更履歴、構成比較などの分析を行う機能（アナリティクス）を有する。例えば、ＴＡＤＤＭサーバは、情報システムについての構成情報を、ｓｓｈ、ＳＮＭＰ、ＷＭＩなどを使用して取得する。上記構成情報は例えば、各情報システムのオペレーティング・システムの種類又はその構成、アプリケーションの種類又はその構成値である。ＴＡＤＤＭサーバは、取得した情報を、ＣＭＤＢ内にＣＩインスタンスとして格納する。ＴＡＤＤＭサーバは、ＣＭＤＢに格納したＣＩインスタンス基づいて、管理者のコンピュータに構成情報、及び変更履歴情報を送る。管理者のコンピュータは、該情報を用いて、構成情報の表示及び変更履歴の表示を行う。
【００５５】
図２Ａは、ＣＩ（例えば、サービスＡ及びサービスＢ）のＣＩインスタンス、及びそれらサービスの関係（usedBy）インスタンスの作成を示す。
サービスＡのＣＩインスタンスは、ディスカバリ部（図１Ａ、１０１）によって検出されたサービスＡについての情報から、サービスＡのデータ・モデルを用いてＣＩインスタンス作成部（図１Ａ、１０３）によって作成される。同様に、サービスＢのＣＩインスタンスは、ディスカバリ部（図１Ａ、１０１）によって検出されたサービスＢについての情報から、サービスＢのデータ・モデルを用いてＣＩインスタンス作成部（図１Ａ、１０３）によって作成される。サービスＡ及びサービスＢの各データ・モデルは、モデル・テーブル（図１Ａ、１０７）に格納されている。ＣＩ同士の関係、すなわちサービスＡとサービスＢとの関係（usedBy）のインスタンスは、ディスカバリ部（図１Ａ、１０１）によって検出されたサービスＡについての情報から、関係モデルに従いＣＩインスタンス作成部（図１Ａ、１０３）によって作成される。関係モデルは、関係テーブル（図１Ａ、１０８）に格納されている。
また、サービスが例えばサービスＢ１、Ｂ２、Ｂ３である場合、サービスＢ１、Ｂ２、Ｂ３についての各情報がサービスＢのデータ・モデルを使用してインスタンス化されて、サービスＢ１のＣＩインスタンス、サービスＢ２のＣＩインスタンス、サービスＢ３のＣＩインスタンスが夫々作成される。サービスＢ１、Ｂ２、Ｂ３の各ＣＩインスタンスもまた、ＣＭＤＢ（１０５）内に格納される。
【００５６】
図２Ｂは、モデル・テーブル（図１Ａ、１０７）内に格納されたデータ・モデル（２０１）、ディスカバリ・テーブル（図１Ａ、１０６）内に格納されたディスカバリ・インスタンス（２０２）、ＣＭＤＢ（図１Ａ、１０５）内に格納された（サービスＡの）ＣＩインスタンス（２０３）及び関係テーブル（図１Ａ、１０８）内に格納された関係モデル（２０４）を示す。
【００５７】
データ・モデル（２０１）は、ＣＩを定義するためのスキーマである。データ・モデル（２０１）は例えば、どのＣＩのモデルかを示す「モデル名」、モデル名に指定されたＣＩが有する属性を示す「モデル属性」、モデル名に指定されたＣＩと他のＣＩがとりうる「関係」、及びモデル名に指定されたＣＩを検出するためのディスカバリ・インスタンスを特定する「ディスカバリ方法」の各記述を含む。モデル属性は、例えばＩＢＭが提唱する構成管理データベース用のデータ・モデル「ＣＤＭ」に規定された属性に従い規定されるが、これらに限定されない。ＣＤＭでは、2006年の時点において、2609種類の属性が規定されている。ＣＭＤＢの管理者は、データ・モデル（２０１）における属性を任意に指定しうる。関係は、例えば上記ＣＤＭに規定された関係に従い規定されるが、これらに限定されない。ＣＤＭでは、2006年の時点において、57種類の関係が規定されている。ディスカバリ方法は、ディスカバリ・インスタンス名で特定されうる。図２Ｂの場合、A-Discoveryである。
【００５８】
ディスカバリ・インスタンス（２０２）は、データ・モデル（２０１）のディスカバリ方法によって特定されるディスカバリ・インスタンスの「名前」、ディスカバリ部（図１Ａ、１０１）によって収集する管理対象（ＣＩ）の「収集対象（スコープ）」、ディスカバリ部（図１Ａ、１０１）によって収集する管理対象（ＣＩ）の「収集する属性」及び「収集する関係」、並びに該ディスカバリ・インスタンスがアクティブであるか或いはインアクティブであるかを示す「ステータス」の各記述を含む。
【００５９】
ＣＩインスタンス（２０３）は、該インスタンスがどのＣＩのものであるかを特定するための「インスタンス名」、該インスタンスが、どのデータ・モデルを使用して作成されたかを示す「モデル名」、データ・モデルによって特定された各属性の「属性値」、データ・モデルによって特定された各「関係」の記述（値）、インスタンスがアクティブであるか或いはインアクティブであるかを示す「ステータス」、及び該ＣＩインスタンスが作成された「作成日時」の各記述を含む。ＣＩインスタンスは好ましくは、ＣＩインスタンスに特有のＣＩインスタンス識別子をさらに含む。ＣＩインスタンス識別子は、当該ＣＩインスタンスを他のＣＩインスタンスと区別できるものであれば特に限定されないが、例えばホストネーム、シリアルナンバー若しくは一定の値である他の属性の組み合わせを使用しうる。図２ＢのＣＩインスタンス（２０３）は、サービスＡのＣＩインスタンスであること；データ・モデルＡを使用してインスタンス化されたこと；属性としてＳ、Ｔ及びＵを含み、これらが夫々値を有すること；関係として、Ｍによって使用されること（usedBy:M）、Ｅに接続されること（connectAt:E）、及びＨで実行すること（runAt:H）；ＣＩインスタンスがアクティブであること、並びに該ＣＩインスタンスの作成日時のデータを示す。
【００６０】
関係モデル（２０４）は、データ・モデル（２０１）によって特定される関係を定義するためのスキーマである。関係モデル（２０４）は、usedByなどの「関係名」、該関係の対象となるデータ・モデルを特定するための「対象となるデータ・モデル」、該関係の「説明」の各記述を含む。
【００６１】
図３Ａは、本発明の実施形態におけるサービス構成要素の例を示す。
（１つの）サービス構成要素は例えば、１つのサービス・プロセス（３０１）を１単位として、複数のサービス・プロセス（図示せず）を１単位として、１つのサービス・ステップ（３０２）を１単位として及び複数のサービス・ステップ（３０３）を１単位としてのいずれかである。
よって、本明細書において、サービス構成要素という場合、１つのサービス・プロセスそのものがサービス構成要素である態様、複数のサービス・プロセスがサービス構成要素である態様、１つのサービス・ステップそのものがサービス構成要素である態様、複数のサービス・ステップがサービス構成要素である態様を含む。
【００６２】
図３Ｂは、本発明の実施形態における、サービス構成要素の組み合わせの例を示す。
図３Ｂの３１１は、サービス構成要素として１つのサービス・プロセス（３１４）及びサービス構成要素として１つの別のサービス・プロセス（３１５）を示す。例えば、サービス構成要素（３１４）が第１のサービス構成要素であり、サービス構成要素（３１５）が第２のサービス構成要素である。或いは、サービス構成要素（３１５）が第１のサービス構成要素であり、サービス構成要素（３１４）が第２のサービス構成要素である。
図３Ｂの３１２は、サービス構成要素として１つのサービス・プロセス（３１６）及びサービス構成要素として上記サービス・プロセス（３１６）と異なるサービス・プロセス中の複数のサービス・ステップ（３１７）を示す。例えば、サービス構成要素（３１６）が第１のサービス構成要素であり、サービス構成要素（３１７）が第２のサービス構成要素である。或いは、サービス構成要素（３１７）が第１のサービス構成要素であり、サービス構成要素（３１６）が第２のサービス構成要素である。
図３Ｂの３１３は、サービス構成要素として１つのサービス・プロセス中の複数のサービス・ステップ（３１８）及びサービス構成要素として上記サービス・プロセスと異なる別のサービス・プロセス中の複数のサービス・ステップ（３１９）を示す。例えば、サービス構成要素（３１８）が第１のサービス構成要素であり、サービス構成要素（３１９）が第２のサービス構成要素である。或いは、サービス構成要素（３１９）が第１のサービス構成要素であり、サービス構成要素（３１８）が第２のサービス構成要素である。
上記は、サービス構成要素の組み合わせの一例であって、上記３つの態様（３１１、３１２、３１３）に限定されるものでない。
【００６３】
図３Ｃは、本発明の実施形態における、データ・モデル（３１１）、（サービスＡの）ＣＩインスタンス（３１３）及び関係モデル（３１４）を示す。
データ・モデル（３１１）は、モデル・テーブル（図１Ａ、１０７）内に格納される。ＣＩインスタンス（３１３）は、ＣＭＤＢ（図１Ａ、１０５）内に格納される。関係モデル（３１４）は、関係テーブル（図１Ａ、１０８）内に格納される。
本発明の実施形態におけるデータ・モデル（３１１）には、図２Ｂのデータデル（２０１）と比較して、属性「アクション・タイプ」及び属性「影響範囲」が追加されている。属性「アクション・タイプ」は例えば、新規、変更、削除、参照及び検索であるが、これらに限定されない。属性「影響範囲」は例えば、モデル名に指定されたＣＩからの距離を示すレベル、ＣＩインスタンスのモデル名、関係であるが、これらに限定されない。
同様に、本発明の実施形態におけるＣＩインスタンス（３１３）には、図２ＢのＣＩインスタンス（２０３）と比較して、属性「アクション・タイプ」及び属性「影響範囲」が追加されている。ＣＩインスタンス（３１３）の属性「アクション・タイプ」には、データ・モデル（３１１）で定義されたアクション・タイプのうちの少なくとも１つがインスタンス化されている。
本発明の実施形態では、図５の説明で述べるように、ステータス制御部がサービス・プロセスに対応するＣＩインスタンスをＣＭＤＢ内に動的に定義し、サービス・プロセスの対象先となるＣＩとの間に関係を定義するために、又はプロセス・エンジンがサービス・プロセスの対象先となるＣＩをポイントするパラメータをサービス・プロセス内に定義するために、図２Ｂで示されるディスカバリ・データが不要である。
【００６４】
図３Ｄ〜図３Ｈは、本発明の実施形態における、サービス構成要素に対応するアクションの対象範囲を特定するために使用されるポリシー（対象範囲特定ポリシー）の例を示す。
対象範囲特定ポリシーの条件例を以下に示す。
１．ＯＳ、次にミドルウェア、次にアプリケーションという垂直の依存関係を有する対象範囲特定ポリシーの例
・対象範囲特定ポリシーＡ：構成要素間が、「InstalledOn」の関係にあるもの
・対象範囲特定ポリシーＢ：対象範囲特定ポリシーＡ、且つ、対象である構成要素から１ノード（１段分）までのもの
２．ビジネス・アプリケーションを構成する複数のサーバ上の構成要素についての対象範囲特定ポリシーの例
・対象範囲特定ポリシーＣ：双方向の構成要素間で「UsedBy」の関連にあるもの
・対象範囲特定ポリシーＤ：対象範囲特定ポリシーＣの結果に対して、対象範囲特定ポリシーＡを適用したもの
３．その他
・任意の関係を有する構成要素のうち、ＣＩのタイプ属性が「ミドルウェア」のもの
【００６５】
条件の記述形式及び指定できる内容は、適切な実装方法により実現されうる。例えば、条件は、ＸＭＬ言語を用いて記述されうる。指定できる内容は例えば、属性及び関係を含む。
以下に、上記対象範囲特定ポリシーＡ乃至Ｄを用いて、構成要素と関係のある構成要素を抽出する例を示す。
【００６６】
図３Ｄは、本発明の実施態様である、対象範囲特定ポリシーを説明するために使用する、構成要素及び構成要素間の関係を示す。なお、図３Ｄでは、便宜的にソフトウェア構成要素を例としているが、該ソフトウェア構成要素をサービス構成要素又はハードウェア構成要素に置き換えることによって、同様に対象範囲特定ポリシーを説明することが可能である。
ＯＳ（オペレーティング・システム） Ａは、ＲＤＢＭＳ（リレーショナルデータベース管理システム）と「InstalledOn」の関係にある。ＲＤＢＭＳは、データベースと「InstalledOn」の関係にある。
ＯＳ Ｂは、Ａｐｐ（アプリケーション）サーバと「InstalledOn」の関係にある。Ａｐｐサーバは、Ｗｅｂアプリと「InstalledOn」の関係にある。
データベースは、Ｗｅｂアプリとお互いに「usedBy」の関係にある。
【００６７】
図３Ｅは、本発明の実施態様である、対象範囲特定ポリシーＡを用いた例を示す。
ＣＩとしてデータベースを指定し、且つ、対象範囲特定ポリシーＡを指定すると、「InstalledOn」の関係にあるＣＩがアクションの対象範囲である構成要素として特定される。結果として、データベース、ＲＤＢＭＳ及びＯＳのソフトウェア構成要素が特定される。
【００６８】
図３Ｆは、本発明の実施態様である、対象範囲特定ポリシーＢを用いた例を示す。
ＣＩとしてＷｅｂアプリを指定し、且つ、対象範囲特定ポリシーＢを指定すると、「InstalledOn」の関係にあるＣＩのうち、最初の１ノード分がアクションの対象範囲である構成要素として特定される。結果として、Ｗｅｂアプリ及びＡｐｐサーバのソフトウェア構成要素が特定される。
【００６９】
図３Ｇは、本発明の実施態様である、対象範囲特定ポリシーＣを用いた例を示す。ＣＩとしてデータベースを指定し、且つ、対象範囲特定ポリシーＣを指定すると、「usedBy」にある関係を双方向で有するソフトウェア構成要素が特定される。結果として、データベース及びＷｅｂアプリのソフトウェア構成要素が特定される。
【００７０】
図３Ｈは、本発明の実施態様である、対象範囲特定ポリシーＤを用いた例を示す。ＣＩとして、データベースを指定し、且つ、対象範囲特定ポリシーＤを指定すると、データベースとＷｅｂアプリがアクションの対象範囲である構成要素として特定され、さらにそれら対象範囲に「InstalledOn」の関係にあるＣＩがアクションの対象範囲である構成要素として特定される。結果として、データベース、ＲＤＢＭＳ、ＯＳ Ａ並びにＷｅｂアプリ、Ａｐｐサーバ及びＯＳ Ｂのソフトウェア構成要素が特定される。
【００７１】
図４は、従来のサービス・プロセス処理の例を示す。
サービス・プロセスＡは、サービス・プロセスＡへのリクエストを処理するためのプロセスである。サービス・プロセスＢは、サービス・プロセスＢへのリクエストを処理するためのプロセスである。ここで、サービス・プロセスＡ及びサービス・プロセスＢは、同じＣＩを参照するサービス・プロセスであるとする。
従来のサービス・プロセスの処理では、サービス・プロセスそれぞれの管理者が、サービス・プロセスＡ及びサービス・プロセスＢを定義し、そして定義したサービス・プロセスを記憶装置に格納する。
サービス・プロセスＡを実行するにあたり、サービス・プロセスＡの管理者は、サービス・プロセスＡへのリクエストを発行する。プロセス・エンジンは、該リクエストが到着（ステップ４０１）すると、上記記憶装置からサービス・プロセスＡを読み出し、サービス・プロセスＡを実行（ステップ４０２）する。サービス・プロセスＡの実行後、ディスカバリは、構成要素についての情報を取得する。属性及び関係更新部（図１Ａ、１０４）は、該取得したＣＩの情報に基づいて、ＣＭＤＢ内のＣＩインスタンスの属性値又は関係値を更新する（ステップ４０３）。
上記従来のサービス・プロセスの処理において、サービス・プロセスＡの実行中に、サービス・プロセスＢの管理者が、サービス・プロセスＡで参照するＣＩと同じＣＩを参照するサービス・プロセスＢへのリクエストを発行する場合に、次のような問題が生じるおそれがある。サービス・プロセスＢの管理者が、サービス・プロセスＡの存在に気付いた場合、サービス・プロセスＢの管理者は、それぞれのサービス・プロセスの内容によっては待機する必要がない場合であっても、サービス・プロセスの競合を回避するために、サービス・プロセスＡの実行が完了し、ＣＩ情報が更新されるまで、サービス・プロセスＢへのリクエストの発行を待機しなければならない。或いは、サービス・プロセスＢの管理者が、サービス・プロセスＡの存在に気付かない場合、サービス・プロセスＢがサービス・プロセスＡと同時に実行され、その結果としてサービス・プロセスＡ及びサービス・プロセスＢ間で競合が発生し、サービス・プロセスＡ、Ｂの両方、又はそのいずれかが失敗する可能性がある。
【００７２】
図５は、本発明の実施形態における、サービス構成要素に対応するアクションの実行管理の概略を示す。
サービス・プロセスＡ（５０１）のシステムの管理者又は管理者は、サービス・プロセスＡ（５０１）に対応するアクションの対象であるＣＩ（以下、サービス・プロセスＡの対象ＣＩ）に対するアクション・タイプ及び影響範囲を表す対象ＣＩ属性（５０７）を定義する。同様に、サービス・プロセスＢ（５０２）のシステムの管理者又は管理者は、サービス・プロセスＢ（５０２）に対応するアクションの対象であるＣＩ（以下、サービス・プロセスＢの対象ＣＩ）に対するアクション・タイプ及び影響範囲を表す対象ＣＩ属性（５０７）を定義する。
上記定義はそれぞれ、データ・モデル（図３Ｃ、３１１）の属性「アクション・タイプ」及び属性「影響範囲」に定義された情報を使用して、インスタンス化されうる。インスタンス化されたＣＩインスタンスは、図３Ｃに示されている（３１３）。代替的に、該定義は、上記データ・モデル（図３Ｃ、３１１）とは別途にサービス・プロセスの管理者によって定義され、記憶媒体、例えばＣＭＤＢ内に格納されていてもよい。
該対象ＣＩ属性（５０７）は、対象ＣＩへのアクション・タイプ及び対象ＣＩの影響範囲を含む。「アクション・タイプ」は例えば、新規、変更、削除、参照及び検索である。「影響範囲」は例えば、モデル名に指定されたＣＩからの距離を示すレベル、ＣＩインスタンスのモデル名、関係である。
対象ＣＩ属性（５０７）の実装例は、下記の通りである。
１．ステータス制御部（５０３）が、サービス・プロセスＡ及びＢ（５０１、５０２）に対応するＣＩインスタンス（５０５Ａ及び５０５Ｂ）を例えばＣＭＤＢ内に動的に定義する。そして、サービス・プロセスＡ（５０１）と該サービス・プロセスＡ（５０１）の対象ＣＩとの間に関係（５０６Ａ）を定義する。同様に、サービス・プロセスＢ（５０２）と該サービス・プロセスＢ（５０２）の対象ＣＩとの間に関係（５０６Ｂ）を定義する。代替的に、サービス・プロセスのシステム管理者又は管理者は、サービス・プロセスＡ又はＢ（５０１、５０２）の対象ＣＩをポイントするパラメータをサービス・プロセス（５０１、５０２）内にそれぞれ定義してもよい。
ステータス制御部（５０３）は、サービス・プロセス（５０１、５０２）間の依存関係の管理を行えるように、実行中の全サービス・プロセスの対象ＣＩ属性を管理する。
以下では、先行サービス・プロセスＡ（５０１）の実行中に、後発のサービス・プロセスＢ（５０２）へのリクエストが発生した場合を例に説明する。
サービス・プロセスＡ（５０１）及びサービス・プロセスＢ（５０２）は、ＣＭＤＢに定義されたそれぞれの対象ＣＩ属性（５０７）を有する。また、プロセス・エンジン（図示せず）は、サービス・プロセスＡ（５０１）の開始時に該サービス・プロセスＡ（５０１）についての対象ＣＩ属性（５０７）をステータス制御部（５０３）に提供している。サービスＢへのリクエストを受け、プロセス・エンジン（図示せず）は、後発サービス・プロセスＢ（５０２）の開始時に対象ＣＩ属性（５０７）をステータス制御部（５０３）に提供し、ステータス制御部（５０３）を介して、サービス・プロセスＡ（５０１）の対象ＣＩ属性（５０７）を参照する。
ステータス制御部（５０３）は、上記実行されたサービス・プロセスＢ（５０２）及びサービス・プロセスＡ（５０１）の対象ＣＩ属性（５０７）から、該実行されたサービス・プロセスＢ（５０２）の実行可否を判定する。該判定は、ステータス制御部（５０３）に定められた可否判定ポリシー（５１０）を利用して行われうる。可否判定ポリシーとは、複数のサービスによって共通する構成要素が利用される場合の動作ルールを定義したデータである。
また、上記判定はまた、プロセス・エンジン（図示せず）によって実行されたサービス・プロセスＢ（５０２）の管理者によって判定されてもよい。サービス・プロセスＢ（５０２）の管理者は、管理装置の表示装置上に表示されたサービス・プロセスＢ（５０２）のアクションの実行可否の選択を許すインタフェースを介して、アクションを実行させるか又はアクションを待機させるかを判断する。
ディスカバリ部（５０８）は、サービス・プロセスＡ及びＢ（５０１、５０２）の実行後にＣＩの情報を取得する。次に、属性及び関係更新部（図１Ａ、１０４）は、該取得したＣＩの情報に基づいて、ＣＩインスタンスの属性値又は関係値を更新する。
【００７３】
上記可否判定ポリシーの記述例を以下に示す。
１．process1(change) and process2(ANY) --> wait
（先行プロセス（変更）→後発プロセス（ＡＮＹ）を待機）
該例は、先行プロセス１のアクション・タイプが「変更」であるならば、後発プロセス２のアクション・タイプが何であっても、後発プロセス２は待機する、というポリシーである。
２．process1(ANY) and process2(delete、change) --> wait
（先行プロセス（ＡＮＹ）→後発プロセス（削除、変更）を待機）
該例は、先行プロセス１のアクション・タイプが何であっても、後発プロセス２のアクション・タイプが「削除」又は「変更」であるならば、後発プロセス２は待機する、というポリシーである。
３．process1(change、delete) and process2(ANY) --> wait
（先行プロセス（変更、削除）→後発プロセス（ＡＮＹ）を待機）
該例は、先行プロセス１のアクション・タイプが「変更」又は「削除」であるならば、後発プロセス２のアクション・タイプが何であっても、後発プロセス２は待機する、というポリシーである。
４．process1(ANY) and process2(delete) --> wait
（先行プロセス（ＡＮＹ）→後発プロセス（削除）を待機）
該例は、先行プロセス１のアクション・タイプが何であっても、後発プロセス２のアクション・タイプが「削除」であるならば、後発プロセス２は待機する、というポリシーである。
５．process1(search、refer) and process2(search、refer) --> go
（先行プロセス（検索、参照）→後発プロセス（検索、参照）を実行）
該例は、先行プロセス１のアクション・タイプが「検索」又は「参照」であり、後発プロセス２のアクション・タイプが「検索」又は「参照」であるならば、後発プロセス２は実行可能である、というポリシーである。先行及び後発の両プロセスのアクション・タイプが「検索」又は「参照」の場合、実行順番が入れ替わっても不整合は生じないので、後発プロセスが実行可能であると判定される。
６．process1(search、refer) and process2(change) --> wait
（先行プロセス（検索、参照）→後発プロセス（変更）を待機）
該例は、先行プロセス１のアクション・タイプが「検索」又は「参照」であっても、後発プロセス２のアクション・タイプが「変更」であるならば、後発プロセス２は待機する、というポリシーである。先行プロセスのアクション・タイプが「検索」又は「参照」の場合、後発プロセスで先に変更をおこなうと不整合が生じる可能性があるので、後発プロセスは待機であると判定される。
先行プロセスが複数ある場合、先行プロセスが完了する毎に判定が実行される。そして、適用される可否判定ポリシー全てによって後発プロセスが実行可能であると判定される場合のみ、後発プロセスが実行可能であると判定され、適用される可否判定ポリシーの少なくとも１つによって後発プロセスが待機させると判定される場合、後発プロセスは待機すると判定される。
【００７４】
図６は、本発明の実施形態における、サービス・プロセスの実行可否を決定する流れを示す。
以下では、先行サービス・プロセスＡ（６０２）の実行中に、後発のサービス・プロセスＢ（６０４）へのリクエストが発生した場合を例に説明する。
サービス・プロセスＡ及びＢ（６０２、６０４）それぞれの対象ＣＩ属性（６０１、６０３）は、サービス・プロセスＡ及びＢ（６０２、６０４）の開始時に、ステータス制御部（６０５）に提供される。サービス・プロセス（６０２、６０４）の実行可否は、ステータス制御部（６０５）又はサービス・プロセスＡ及びＢ（６０２、６０４）の各管理者が決定しうる。サービス・プロセスＡ及びＢ（６０２、６０４）の完了順が逆転した場合であっても、対象ＣＩ（６０７）の更新情報を一意に保てる場合、ステータス制御部（６０５）又はサービス・プロセスＡ及びＢ（６０２、６０４）の各管理者は、新規リクエストのサービス・プロセス（６０２、６０４）を実行可能と判定してもよい。
以下に、ステータス制御部が実行可否を判定する場合とサービス・プロセスの管理者側で実行可否を判定する場合について説明する。
Ａ．ステータス制御部が実行可否を判定する場合
ステータス制御部（６０５）は、先行サービス・プロセスＡ（６０２）の対象ＣＩ属性（６０１）に含まれる対象ＣＩの影響範囲に定義された対象ＣＩ（ＣＩ１、ＣＩ２及びＣＩ３）と、後発サービス・プロセスＢ（６０４）の対象ＣＩ属性（６０３）に含まれる対象ＣＩの影響範囲に定義された対象ＣＩ（ＣＩ３、ＣＩ４及びＣＩ６）とが重なっていない場合、後発サービス・プロセスＢ（６０４）は実行可能であると判定する。ステータス制御部（６０５）は、上記影響範囲に定義された対象ＣＩが重なっている場合、ステータス制御部（６０５）に定義された可否判定ポリシー（６０６）を使用して、後発サービス・プロセスＢ（６０４）の実行可否を判定する。可否判定ポリシー（６０６）は例えば、管理者によってステータス制御部（６０５）内に定義されうる。ステータス制御部（６０５）が、可否判定ポリシー（６０６）を使用して、後発サービス・プロセスＢ（６０４）の動作を決定する例は、以下の通りである。
１．process1(change) and process2(ANY) --> wait
（先行プロセス（変更）→後発プロセス（ＡＮＹ）を待機）
該例は、先行サービス・プロセスＡ（６０２）のアクション・タイプが「変更」であるならば、後発サービス・プロセスＢ（６０４）のアクション・タイプが何であっても、後発サービス・プロセスＢ（６０４）は待機する、というポリシーである。ステータス制御部（６０５）は、先行サービス・プロセスＡ（６０２）のアクション・タイプが「変更」である場合、後発サービス・プロセスＢ（６０４）を待機させる。
２．process1(ANY) and process2(delete、change) --> wait
（先行プロセス（ＡＮＹ）→後発プロセス（削除、変更）を待機）
該例は、先行サービス・プロセスＡ（６０２）のアクション・タイプが何であっても、後発サービス・プロセスＢ（６０４）のアクション・タイプが「削除」又は「変更」であるならば、後発サービス・プロセスＢ（６０４）は待機する、というポリシーである。ステータス制御部（６０５）は、後発サービス・プロセスＢ（６０４）のアクション・タイプが「削除」又は「変更」である場合、後発サービス・プロセスＢ（６０４）を待機させる。
３．process1(change、delete) and process2(ANY) --> wait
（先行プロセス（変更、削除）→後発プロセス（ＡＮＹ）を待機）
該例は、先行プロセス１のアクション・タイプが「変更」又は「削除」であるならば、後発プロセス２のアクション・タイプが何であっても、後発プロセス２は待機する、というポリシーである。ステータス制御部（６０５）は、後発サービス・プロセスＢ（６０４）のアクション・タイプが何であっても、後発サービス・プロセスＢ（６０４）を待機させる。
４．process1(ANY) and process2(delete) --> wait
（先行プロセス（ＡＮＹ）→後発プロセス（削除）を待機）
該例は、先行サービス・プロセスＡ（６０２）のアクション・タイプが何であっても、後発サービス・プロセスＢ（６０４）のアクション・タイプが「削除」であるならば、後発サービス・プロセスＢ（６０４）は待機する、というポリシーである。ステータス制御部（６０５）は、後発サービス・プロセスＢ（６０４）のアクション・タイプが「削除」である場合、後発サービス・プロセスＢ（６０４）を待機させる。
５．process1(search、refer) and process2(search、refer) --> go
（先行プロセス（検索、参照）→後発プロセス（検索、参照）を実行）
該例は、先行サービス・プロセスＡ（６０２）のアクション・タイプが「検索」又は「参照」であり、後発サービス・プロセスＢ（６０４）のアクション・タイプが「検索」又は「参照」であるならば、後発サービス・プロセスＢ（６０４）は実行可能である、というポリシーである。先行及び後発の両プロセスのアクション・タイプが「検索」又は「参照」の場合、実行順番が入れ替わっても不整合は生じないので、ステータス制御部（６０５）は、後発プロセスが実行可能であると判定する。
６．process1(search、refer) and process2(change) --> wait
（先行プロセス（検索、参照）→後発プロセス（変更）を待機）
該例は、先行サービス・プロセスＡ（６０２）のアクション・タイプが「検索」又は「参照」であっても、後発サービス・プロセスＢ（６０４）のアクション・タイプが「変更」であるならば、後発サービス・プロセスＢ（６０４）は待機する、というポリシーである。先行サービス・プロセスＡ（６０２）のアクション・タイプが「検索」又は「参照」の場合、後発サービス・プロセスＢ（６０４）で先に変更をおこなうと不整合が生じる可能性があるので、ステータス制御部（６０５）は、後発サービス・プロセスＢ（６０４）が待機であると判定する。
Ｂ．サービス・プロセス（６０２、６０４）の各管理者側が実行可否を判定する場合
ステータス制御部（６０５）の代わりに、サービス・プロセスＡ及びＢ（６０２、６０４）の各管理者がそれぞれ実行可否を判定する。該決定は例えば、プロセス・エンジンが、サービス・プロセスＡの管理者に対してサービス・プロセスＡ（６０２）の実行又は待機を指定することを許すポップアップウィンドウを表示し、該管理者から実行又は待機の入力を行わせることによって行う。同様に、プロセス・エンジンが、サービス・プロセスＢの管理者に対してサービス・プロセスＢ（６０４）の実行又は待機を指定することを許すポップアップウィンドウを表示し、該管理者から実行又は待機の入力を行わせることによって行う。サービス・プロセスＡ及びＢ（６０２、６０４）の各管理者側が実行可否を判定する例は、以下の通りである。
・先行プロセス（削除）→後発プロセス（ＡＮＹ）の実行必要性を判定する。
上記例は、先行サービス・プロセスＡ（６０２）のアクション・タイプが「削除」ならば、後発サービス・プロセスＢ（６０４）のアクション・タイプが何であっても、後発サービス・プロセスＢ（６０４）は実行必要性の判定を求める、という意味である。
・先行プロセス（新規）→後発プロセス（検索）で新規ＣＩを検索対象に含めるか判定する。
上記例は、先行サービス・プロセスＡ（６０２）のアクション・タイプが「新規」であり、後発サービス・プロセスＢ（６０４）のアクション・タイプが「検索」の場合、後発のサービス・プロセス（６０４）は新規ＣＩを検索対象に含めるかの判定を求める、という意味である。
なお、図６の例では、影響範囲をＣＩインスタンスのモデル名としたが、該影響範囲は、例えばノードとの距離を示すレベル又は関係を用いた式を使用して表してもよい。該影響範囲はまた、サービス構成要素に対応するアクションの対象範囲を特定するために使用されるポリシー（対象範囲特定ポリシー）によって動的に決定されうる。
影響範囲として、ノードとの距離を示すレベルを用いる場合において、先行のサービス・プロセス（６０２）の対象ＣＩ属性（６０１）に含まれる対象ＣＩの影響範囲に定義されたレベル以内の構成要素であるＣＩと、後発のサービス・プロセス（６０４）の対象ＣＩ属性（６０３）に含まれる対象ＣＩの影響範囲に定義されたレベル以内の構成要素が重なっていない場合、ステータス制御部（６０５）は、後発のサービス・プロセス（６０４）は実行可能であると判定する。上記影響範囲が重なっている場合、ステータス制御部（６０５）は、ステータス制御部（６０５）に定義された可否判定ポリシー（６０６）を使用して、後発のサービス・プロセス（６０４）の動作を判定する。
影響範囲として、関係を用いた式を用いる場合において、先行のサービス・プロセス（６０２）の対象ＣＩ属性（６０１）に含まれる対象ＣＩの影響範囲に定義された関係を用いた式から求められるＣＩと、後発のサービス・プロセス（６０４）の対象ＣＩ属性（６０３）に含まれる対象ＣＩの影響範囲に定義された関係を用いた式から求められるＣＩとが重なっていない場合は、ステータス制御部（６０５）は、後発のサービス・プロセス（６０４）は実行可能であると判定する。上記影響範囲が重なっている場合、ステータス制御部（６０５）は、ステータス制御部（６０５）に定義された可否判定ポリシー（６０６）を使用して、後発のサービス・プロセス（６０４）の動作を決定する。
【００７５】
図７Ａ〜図７Ｃは、本発明の実施形態における、サービス構成要素に対応するアクションの処理の流れを示す。
サービス構成要素に対応するアクションとして、サービス・プロセスＡ（７０２）及び実行中の他のサービス・プロセスがあるとする。ステータス制御部（７０４）は、他のサービス・プロセスの対象ＣＩ属性を保持している。対象ＣＩ属性は、対象ＣＩ属性へのアクション・タイプ及び対象ＣＩの影響範囲である（図５、５０７を参照）。
サービス・プロセスＡ（７０２）の管理者は、サービス・プロセスＡへのリクエスト（７０１）を発行する。プロセス・エンジン（図示せず）は、該リクエスト（７０１）を受信すると（ステップ７１０）、サービス・プロセスＡ（７０２）を開始する。プロセス・エンジン（図示せず）は、サービスの開始時に、サービス・プロセスＡ（７０２）内の対象ＣＩ属性をステータス制御部（７０４）に提供する（ステップ７１１）。ステータス制御部（７０４）は、サービス・プロセスＡ（７０２）内の対象ＣＩ属性及び実行中の他のサービス・プロセスの対象ＣＩ属性からサービス・プロセスＡ（７０２）の実行可否を判定し、プロセス・エンジンに通知する（ステップ７１２Ａ）。あるいは、ステータス制御部（７０４）は、実行中の他のサービス・プロセスの対象ＣＩ属性をサービス・プロセスＡ（７０２）の管理者に提供し、サービス・プロセスＡの実行可否を該管理者に判定させる（ステップ７１２Ｂ）。
【００７６】
図７Ｂは、上記判定において、サービス・プロセスＡ（７０２）が実行可能である場合を示す。
ステータス制御部（７０４）が、サービス・プロセスＡ（７０２）内のＣＩ（７０３）と該サービス・プロセスＡ（７０２）の対象ＣＩ（７０５）との間に関係（７０６）を作成する（ステップ７１３）。プロセス・エンジン（図示せず）が、サービス・プロセスＡ（７０２）を実行する（ステップ７１４）。上記サービス・プロセスＡ（７０２）の実行完了後、ステータス制御部（７０４）は、ディスカバリ部（７０７）に対して、ＣＩについての情報のディスカバリを要求する。ディスカバリの対象となるＣＩは、ディスカバリ部（７０７）の管理対象である全てのＣＩ、又は、実行を完了したサービス・プロセスＡに対応するアクションの対象であるＣＩ、又は、実行を完了したサービス・プロセスＡに対応するアクションの対象であるＣＩと他のサービス・プロセスに対応するアクションの対象であるＣＩとの重複範囲に含まれるＣＩである。後者ほど、ディスカバリに要する時間が少なくてすむ。上記要求を受けディスカバリ部（７０７）は、ＣＩの情報を取得する。属性及び関係更新部（図１Ａ、１０４）は、該取得したＣＩの情報に基づいて、ＣＩインスタンスの属性値又は関係値を更新する（ステップ７１５）。
該更新の完了は、ステータス制御部（７０４）に通知される。ここで、属性及び関係更新部（図１Ａ、１０４）は、サービス・プロセスＡ（７０２）内のＣＩ（７０３）と関係のある対象ＣＩ（７０５）の情報の更新及び更新完了の通知を優先して行い、サービス・プロセスＡ（７０２）内のＣＩ（７０３）と関係のない対象ＣＩ（７０５）の情報の更新及び更新完了の通知を、後述のステップ７１６以降に行ってもよい。ステータス制御部（７０４）がサービス・プロセスＡ（７０２）内のＣＩ（７０３）と対象ＣＩ（７０５）との間の関係（７０６）を削除する（ステップ７１６）。
ここで、さらに待ち状態のサービス・プロセス（７０８）があるとする。ステータス制御部（７０４）が、待ち状態のサービス・プロセス（７０８）の実行可否を判定していた場合、ステータス制御部（７０４）は、実行可否の再判定を行い、プロセス・エンジンに通知する。ステータス制御部（７０４）が、待ち状態のサービス・プロセス（７０８）の管理者に実行可否を判定させていた場合、待ち状態のサービス・プロセスに対応するアクションの実行可否の再判定を可能にするために、サービス・プロセスＡ（７０２）の終了をプロセス・エンジンに通知する（ステップ７１７）。該通知により、待ち状態のサービスプロセス（７０８）の管理者は、サービス・プロセスＡ（７０２）の終了を知ることができる。さらに、ステータス制御部（７０４）は、ＣＩ属性情報を待ち状態のサービス・プロセス（７０８）の管理者に提供する。
【００７７】
図７Ｃは、上記判定において、サービス・プロセスＡ（７０２）が待機である場合を示す。
先行の他のサービス・プロセスが終了すると、ステータス制御部（７０４）は、サービス・プロセスＡ（７０２）の管理者に実行可否を判定させていた場合、先行の他のサービス・プロセスの終了をプロセス・エンジン（図示せず）に通知する（ステップ７２０）。該通知により、サービス・プロセスＡ（７０２）の管理者は、他のサービス・プロセスの終了を知ることができる。ステータス制御部（７０４）は、該他のサービス・プロセスについての更新された対象ＣＩ属性を用いてサービス・プロセスＡ（７０２）の実行可否を再度判定する。ここで、サービス・プロセスＡ（７０２）以外にも待機しているサービス・プロセスがある場合、ステータス制御部（７０４）は、待機時間の長いサービス・プロセスの順に判定を行う（ステップ７２１）。代替的に、ステータス制御部（７０４）は、対象ＣＩ属性をサービス・プロセスＡ（７０２）の管理者に提供し、プロセス・エンジンは、実行可否をサービス・プロセスＡ（７０２）の管理者に判定させうる。該判定において、サービス・プロセスＡ（７０２）が待機である場合、プロセス・エンジンは、サービス・プロセスＡ（７０２）を待機させる。ステータス制御部（７０４）は、他に実行中であるサービス・プロセスの完了を待つ（上記図７Ｂの説明を参照されたい）。該判定において、サービス・プロセスＡ（７０２）が実行可能である場合、ステータス制御部（７０４）が、サービス・プロセスＡ（７０２）内のＣＩ（７０３）と該サービス・プロセスＡ（７０２）の対象ＣＩ（７０５）との間に関係（７０６）を作成する（ステップ７２２）。プロセス・エンジンが、サービス・プロセスＡ（７０２）を実行する（ステップ７２３）。上記サービス・プロセスＡ（７０２）の実行完了後、ステータス制御部（７０４）は、ディスカバリ部（７０７）に対してＣＩについての情報のディスカバリを要求する。ディスカバリの対象となるＣＩは、上記図７Ｂの説明で述べたとおりである。上記要求を受けディスカバリ部（７０７）は、ＣＩの情報を取得する（ステップ７２４）。属性及び関係更新部（図１Ａ、１０４）は、該取得したＣＩの情報に基づいて、ＣＩインスタンスの属性値又は関係値を更新する（ステップ７２４）。
該更新の完了はステータス制御部（７０４）に通知される。ここで、属性及び関係更新部（図１Ａ、１０４）は、サービス・プロセスＡ（７０２）内のＣＩ（７０３）と関係のある対象ＣＩ（７０５）の情報の更新及び更新完了の通知を優先して行い、サービス・プロセスＡ（７０２）内のＣＩ（７０３）と関係のない対象ＣＩ（７０５）の情報の更新及び更新完了の通知を、後述のステップ７２５以降に行ってもよい。さらに属性及び関係更新部（図１Ａ、１０４）は、サービス・プロセスＡ（７０２）内のＣＩ（７０３）と関係のある対象ＣＩ（７０５）のうち、待ち状態の他のサービス・プロセス（７０８）の影響範囲にも含まれるＣＩの情報の更新及び更新完了の通知を優先して行い、他のＣＩの情報の更新及び更新完了の通知を後述のステップ７２５以降に行ってもよい。サービス・プロセスＡ（７０２）内のＣＩ（７０３）と関係のある対象ＣＩ（７０５）のうち、待ち状態の他のサービス・プロセス（７０８）の影響範囲にも含まれるＣＩの情報は、ステータス制御部（７０４）によって上記要求に設定され、ディスカバリ部（７０７）は、該要求から該影響範囲のＣＩについての情報を取得する。ステータス制御部（７０４）がサービス・プロセスＡ内のＣＩ（７０３）と対象ＣＩ（７０５）との間の関係を削除する（ステップ７２５）。ステータス制御部（７０４）が、待ち状態のサービス・プロセス（７０８）の実行可否を判定していた場合、ステータス制御部（７０４）は、実行可否の再判定を行い、プロセス・エンジンに通知する。待ち状態のサービス・プロセス（７０８）の管理者に実行可否を判定させていた場合、ステータス制御部（７０４）が、待ち状態のサービス・プロセスに対応するアクションの実行可否の再判定を可能にするために、サービス・プロセスＡ（７０２）の終了をプロセス・エンジンに通知する（ステップ７２６）。該通知によって、待ち状態のサービス・プロセス（７０８）の管理者は、サービス・プロセスＡ（７０２）の終了を知ることができる。さらにステータス制御部（７０４）は、ＣＩ属性情報を待ち状態のサービス・プロセス（７０８）の管理者に提供する。
【００７８】
図８は、本発明の実施形態における、ソフトウェアの変更・リリース管理への適用例を示す。
ハードウェア１（８１０）上で、オペレーティング・システムであるＯＳ１（８１１）が動作している。ＯＳ１（８１１）上で、リレーショナルデータベース管理システム（ＲＤＢＭＳ）（８１２）が動作している。リレーショナルデータベース管理システム（８１２）上で、データベース１（８１３）及びデータベース２（８１４）が動作している。ハードウェア２（８１５）上で、オペレーティング・システムであるＯＳ２（８１６）が動作している。ＯＳ２（８１６）上で、Ｊ２ＥＥ（８１７）が動作している。Ｊ２ＥＥ（８１７）は、Ｊａｖａ処理環境を提供するプログラム群である。Ｊ２ＥＥ（８１７）上で、アプリケーション１（８１８）及びアプリケーション２（８１９）が動作している。上記ハードウェア１（８１０）、ＯＳ１（８１１）、リレーショナルデータベース管理システム（８１２）、データベース１（８１３）、データベース２（８１４）、ハードウェア２（８１５）、ＯＳ２（８１６）、Ｊ２ＥＥ（８１７）、アプリケーション１（８１８）及びアプリケーション２（８１９）それぞれは、ＣＭＤＢ内において各ＣＩインスタンスとして格納されている。
ハードウェア１（８１０）を表すＣＩとＯＳ１（８１１）を表すＣＩの関係は、ｒｕｎｓＯｎである。これは、ハードウェア１（８１０）上でＯＳ１（８１１）が動作していることを表す。ＯＳ１（８１１）を表すＣＩとリレーショナルデータベース管理システム（８１２）を表すＣＩの関係は、ｒｕｎｓＯｎである。これは、ＯＳ１（８１１）上でリレーショナルデータベース管理システム（８１２）が動作していることを表す。リレーショナルデータベース管理システム（８１２）を表すＣＩとデータベース１（８１３）を表すＣＩの関係は、ｒｕｎｓＯｎである。これは、リレーショナルデータベース管理システム（８１２）上でデータベース１（８１３）が動作していることを表す。リレーショナルデータベース管理システム（８１２）を表すＣＩとデータベース２（８１４）を表すＣＩの関係は、ｒｕｎｓＯｎである。これは、リレーショナルデータベース管理システム（８１２）上でデータベース２（８１４）が動作していることを表す。ハードウェア２（８１５）を表すＣＩとＯＳ２（８１６）を表すＣＩの関係は、ｒｕｎｓＯｎである。これは、ハードウェア２（８１５）上でＯＳ２（８１６）が動作していることを表す。ＯＳ２（８１６）を表すＣＩとＪ２ＥＥ（８１７）を表すＣＩの関係は、ｒｕｎｓＯｎである。これは、ＯＳ２（８１６）上でＪ２ＥＥ（８１７）が動作していることを表す。Ｊ２ＥＥ（８１７）を表すＣＩとアプリケーション１（８１８）を表すＣＩの関係は、ｒｕｎｓＯｎである。これは、Ｊ２ＥＥ（８１７）上でアプリケーション１（８１８）が動作していることを表す。Ｊ２ＥＥ（８１７）を表すＣＩとアプリケーション２（８１８）を表すＣＩの関係は、ｒｕｎｓＯｎである。これは、Ｊ２ＥＥ（８１７）上でアプリケーション２（８１９）が動作していることを表す。アプリケーション１（８１８）とデータベース２（８１４）の関係は、useである。これは、アプリケーション１（８１８）がデータベース２（８１４）を使用していることを表す。
【００７９】
サービス・プロセスＡ（８０１）は、ＯＳ１（８１１）の修正を適用するプロセスである。ＣＭＤＢには、サービス・プロセスＡ（８０１）自体のＣＩが格納されている。サービス・プロセスＡ（８０１）のＣＩインスタンスに、対象ＣＩ属性（８０２）が定義されている。対象ＣＩ属性（８０２）は、アクション・タイプが「変更」であり、影響範囲は「"ＯＳ１上で動いているもの（ｒｕｎｓＯｎ)"ａｎｄ"該当ＯＳ上のＣＩを使用しているもの(ｕｓｅ)"」である。ここで、該当ＯＳは、ＯＳ１である。
サービス・プロセスＢ（８０３）は、Ｊ２ＥＥのパラメータを変更するプロセスである。ＣＭＤＢには、サービス・プロセスＢ（８０３）自体のＣＩが格納されている。サービス・プロセスＢ（８０３）のＣＩインスタンスに、対象ＣＩ属性（８０４）が定義されている。対象ＣＩ属性（８０４）は、アクション・タイプが「変更」であり、影響範囲は「"Ｊ２ＥＥ上で動いているもの(ｒｕｎｓＯｎ)"ａｎｄ"該当ＯＳ上のＣＩを使用しているもの(ｕｓｅ)"」である。ここで、該当ＯＳは、ＯＳ２である。
【００８０】
以下、ＯＳ１（８１１）への修正適用プロセスであるサービス・プロセスＡ（８０１）の実行中に、Ｊ２ＥＥのパラメータ変更プロセスであるサービス・プロセスＢ（８０３）を実行する場合を例に説明する。ここで、ステータス制御部（８０５）の有する可否判定ポリシーは、先行のサービス・プロセスのアクション・タイプが「変更」であり、後続のサービス・プロセスのアクション・タイプが「変更」ならば、後続のサービス・プロセスは待機する旨であるとする。
プロセス・エンジンは、サービス・プロセスＡ（８０１）の開始時に、サービス・プロセスＡ（８０１）においてＯＳ１（８１１）が修正適用の対象であることを、ステータス制御部（８０５）に通知する（ステップ８２０）。ステータス制御部（８０５）は、他のサービス・プロセスによりＯＳ１（８１１）及びＯＳ１（８１１）と関連するＣＩが使用されていないため、サービス・プロセスＡ（８０１）が実行可能であることをプロセス・エンジンに通知する（ステップ８２１）。
ステータス制御部（８０５）は、サービス・プロセスＡ（８０１）自体のＣＩとＯＳ１（８１１）を表すＣＩとの間に関係を作成する。さらに、ステータス制御部（８０５）は、サービス・プロセスＡ（８０１）自体のＣＩに定義された影響範囲に従って、影響範囲の及ぶＣＩとサービス・プロセス（８０１）Ａ自体のＣＩとの間に関係を作成する。本例では、影響範囲が「"ＯＳ１上で動いているもの（ｒｕｎｓＯｎ）"且つ"該当ＯＳ上のＣＩを使用しているもの（ｕｓｅ）"」であるので、サービス・プロセス（８０１）Ａ自体のＣＩは、ＯＳ１（８１１）上で動いているＲＤＢＭＳを表すＣＩ（８１２）、データベース１を表すＣＩ（８１３）及びデータベース２を表すＣＩ（８１４）、ＯＳ上のＣＩを使用しているアプリケーション１を表すＣＩ（８１８）と関係を作成する（ステップ８２２）。
プロセス・エンジンは、サービス・プロセスＢ（８０３）の開始時に、サービス・プロセスＢ（８０３）においてＪ２ＥＥがパラメータ変更の対象であることを、ステータス制御部（８０５）に通知する（ステップ８２３）。
ここで、サービス・プロセスＢ（８０５）の影響範囲の及ぶＣＩであるアプリケーション１を表すＣＩ（８１８）は、サービス・プロセスＡ（８０１）に使用されている。また、ステータス制御部（８０５）の有するポリシーに従うと、アクション・タイプが「変更」であるサービス・プロセスの対象となっているＣＩに対しては、同時に変更を行うことはできない。そこで、ステータス制御部（８０５）は、サービス・プロセスＢ（８０３）が実行不可能であることをプロセス・エンジンに通知する。ここで、ステータス制御部（８０５）は、サービス・プロセスＢ（８０３）の実行可否をサービス・プロセスＢ（８０３）の管理者に判定をさせることも可能である（ステップ８２４）。
サービス・プロセスＡ（８０１）が完了すると、ステータス制御部（８０５）は、ディスカバリ部（８０６）に環境内のＣＩについてディスカバリすることをリクエストし、環境内の該ＣＩについての情報を取得する。ここで、ステータス制御部（８０５）は、待機中のサービス・プロセスがあれば、サービス・プロセスＡ（８０１）自体のＣＩと関係のあるＣＩ（８１１、８１２、８１３、８１４、８１８）についての情報の取得を高い優先度で、さらには待機中のサービス・プロセスが待機する原因になっているアプリケーション１を表すＣＩ（８１８）についての情報の取得をより高い優先度でリクエストする（ステップ８２５）。
ディスカバリの完了に伴い、ステータス制御部（８０５）は、サービス・プロセスＡ（８０１）とＣＩ間の関係を削除する（ステップ８２６）。
ステータス制御部（８０５）は、プロセスが実行可能になったことをプロセス・エンジンに通知する（ステップ８２７）。
【００８１】
図９は、本発明の実施形態における、システムの処理のフローチャートを示す。
各サービス構成要素に対応するアクションの管理者は、プロセス・エンジンに対して、サービスを実行するためのリクエストを発行する（ステップ９０１）。
ステータス制御部は、上記リクエストを受け、アクション・タイプ及び影響範囲をＣＭＤＢから取得する。代替的には、プロセス・エンジンが、管理者に対してアクション・タイプ及び影響範囲の入力を要求し、該要求によって入力されたアクション・タイプ及び影響範囲をステータス制御部に渡す。ステータス制御部は、サービス・プロセスの管理者から入力されたアクション・タイプ及び影響範囲をプロセス・エンジンから取得する。ステータス制御部は、サービス構成要素と該サービスのアクションの対象になる構成要素との間に関係を作成する。さらに、ステータス制御部は、上記影響範囲に従って、サービス構成要素と影響範囲の及ぶ構成要素との間に関係を作成する（ステップ９０２）。
ステータス制御部は、上記取得した影響範囲と実行中のサービスに対応するアクション構成要素に設定された影響範囲の重なりを判定する。該判定の結果、影響範囲に重なりがあればステップ９０４に進み、重なりがなければステップ９０５に進む（ステップ９０３）。
ステータス制御部は、上記取得したアクション・タイプ及び影響範囲と、実行中のサービスに対応するアクション構成要素に設定されたアクション・タイプ及び影響範囲からサービスの実行可否を判定する。該判定には、ステータス制御部に定義された可否判定ポリシーを用いる。またステータス制御部は、実行中のサービスに対応するアクション構成要素に設定されたアクション・タイプ及び影響範囲をサービスの管理者に提供し、該判定をサービスの管理者に委ねることもできる。該判定の結果、サービスが実行可能である場合、ステップ９０５に進み、サービスが実行不可である場合、ステップ９０６に進む（ステップ９０４）。
影響範囲に重なりがない場合又はサービスが実行可能であると判定された場合、プロセス・エンジンは、サービスを実行する（ステップ９０５）。サービス実行に伴い、サービス構成要素と関連する構成要素が関係付けられる。
サービスが実行不可であると判定された場合、プロセス・エンジンは、サービスを待機させる（ステップ９０６）。該待機は、上記実行中のサービスが終了するまで行われる。上記実行中のサービスの終了後、ステータス制御部は、ステップ９０３を再度実行する。
サービス終了後、ステータス制御部は、ディスカバリ部に対してディスカバリの要求を行う（ステップ９０７）。ディスカバリ部は、該要求を受け、環境内又は要求されたＣＩの情報を取得する。次に、属性及び関係更新部が、該取得したＣＩの情報に基づいて、ＣＩインスタンスの属性値又は関係値を更新する。属性及び関係更新部は、該更新が完了すると完了をステータス制御部に通知する。
ステータス制御部は、該通知を受け、サービス構成要素と関連する構成要素の関係を解除する（ステップ９０８）。
ステータス制御部は、待機中のサービスがあればサービスが終了したことをプロセス・エンジンに通知する（ステップ９０９）。
【００８２】
図１０は、本発明の実施形態における、コンピュータ・システムの例を示す。
コンピュータ・システム（１０００）は、図１Ａで示されるコンピュータ・システム（１００）と同様に、ディスカバリ部（１００１）、ＣＩ同定部（１００２）、ＣＩインスタンス作成部（１００３）、属性及び関係更新部（１００４）及びＣＭＤＢ（１００５）を含む。コンピュータ・システム（１０００）はさらに、ディスカバリ・テーブル（１００６）、モデル・テーブル（１００７）及び関係テーブル（１００８）を含む。
ステータス制御部（１００９）は、関連付部（１０１１）、判定部（１０１２）、提示部（１０１３）を含む。
関連付部（１０１１）は、サービス構成要素を、該サービス構成要素に対応するアクションの対象である１又は複数の構成要素に関連付ける。
判定部（１０１２）は、第１のサービス構成要素に対応するアクションの実行中に第２のサービス構成要素に対応するアクションへのリクエストがあり且つ該第１のサービス構成要素に対応するアクションの対象である少なくとも１の構成要素が該第２のサービス構成要素に対応するアクションの対象である構成要素に含まれる場合、該第２のサービス構成要素に対応するアクションを実行することが許されるかどうかを判定する。該判定部（１０１２）はまた、サービス構成要素に対応するアクションを実行することが許されるかどうかを判定するためのルールを定義するポリシーによってサービス構成要素に対応するアクションを実行することが許されるかどうかを判定する。
提示部（１０１３）は、サービス構成要素に対応するアクションの実行可否をユーザに選択することを許すインタフェースを表示部に提示する。
プロセス・エンジン（１０１０）は、サービス・プロセス又はサービス・ステップの実行をする。プロセス・エンジン（１０１０）は、サービス・プロセスの対象先となるＣＩをポイントするパラメータをサービス・プロセス内に定義する。
ステータス制御部（１００９）及び／又はプロセス・エンジン（１０１０）は、コンピュータ・システム（１０００）内に含まれていてもよく、又はコンピュータ・システム（１０００）にケーブルを介して接続されたコンピュータ・システム（図示せず）内に含まれていてもよい。
【００８３】
上記実施形態のコンピュータ・システムにおいて使用されるコンピュータは、ＣＰＵとメイン・メモリと含み、これらはバスに接続されている。ＣＰＵは好ましくは、３２ビット又は６４ビットのアーキテクチャに基づくものであり、例えば、インテル社のＸｅｏｎ（商標）シリーズ、Ｃｏｒｅ（商標）シリーズ、Ｐｅｎｔｉｕｍ（商標）シリーズ、Ｃｅｌｅｒｏｎ（商標）シリーズ、ＡＭＤ社のＰｈｅｎｏｍ（商標）シリーズ、Ａｔｈｌｏｎ（商標）シリーズなどを使用することができる。バスには、ディスプレイ・コントローラを介して、ＬＣＤモニタなどのディスプレイが接続される。ディスプレイは、コンピュータ・システムの管理のために、通信回線を介してネットワークに接続されたコンピュータについての情報と、そのコンピュータ上で動作中のソフトウェアについての情報を、適当なグラフィック・インターフェースで表示するために使用される。バスにはまた、ＩＤＥ又はＳＡＴＡコントローラを介して、ハードディスク又はシリコン・ディスクと、ＣＤ−ＲＯＭ、ＤＶＤ又はＢｌｕ−ｒａｙドライブが接続される。
【００８４】
ハードディスクには、オペレーティング・システム、Ｊ２ＥＥなどのＪａｖａ処理環境を提供するプログラム、ＣＭＤＢのための運用管理プログラム、その他のプログラム及びデータが、メイン・メモリにロード可能に記憶されている。運用管理プログラムは好ましくは、インターナショナル・ビジネス・マシーンズ・コーポレーションから提供されるＴＡＤＤＭ（Tivoli（商標）Application Dependency Discovery Manager）を含む。
【００８５】
ＣＤ−ＲＯＭ、ＤＶＤ又はＢＤドライブは、必要に応じて、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ又はＢＤからプログラムをハードディスクに追加導入するために使用される。バスには更に、キーボード・マウスコントローラを介して、キーボード及びマウスが接続されている。
【００８６】
通信インタフェースは、例えばイーサネット（商標）・プロトコルに従うものであり、通信コントローラを介してバスに接続され、コンピュータ及び通信回線を物理的に接続する役割を担い、コンピュータのオペレーティング・システムの通信機能のＴＣＰ／ＩＰ通信プロトコルに対して、ネットワーク・インターフェース層を提供する。尚、通信回線は、有線ＬＡＮ環境、或いは例えばＩＥＥＥ８０２．１１ａ／ｂ／ｇ／ｎなどの無線ＬＡＮ接続規格に基づく無線ＬＡＮ環境であってもよい。
【００８７】
なお、コンピュータ等のハードウェアを接続するためのネットワーク接続装置として使用できるものとして、上記のネットワーク・スイッチ以外に、これで尽きている訳ではないが、ルータ、ハードウェア管理コンソール等がある。要するに、ネットワーク運用管理用プログラムが導入されているコンピュータからの、所定のコマンドによる問い合わせに対して、それに接続されているコンピュータのＩＰアドレス、ＭＡＣアドレスなどの構成情報を返すことができる機能をもつものである。ネットワーク・スイッチ及びルータは、アドレス解決プロトコル（ＡＲＰ）のための、それに接続されているコンピュータのＩＰアドレス及び、それに対応するＭＡＣアドレスの対のリストを含むＡＲＰテーブルを含み、所定のコマンドによる問い合わせに対して、ＡＲＰテーブルの内容を返す機能をもつ。ハードウェア管理コンソールは、ＡＲＰテーブルよりも更に詳しい、コンピュータの構成情報を返すことができる。
【００８８】
コンピュータには、上述したハードウェア管理コンソールが接続されている。これは、コンピュータで、ＬＰＡＲ（仮想論理区画）により一台のコンピュータを複数の区画に論理分割し、その各々の区画で、ＶＭｗａｒｅにより、Ｗｉｎｄｏｗｓ（商標）、Ｌｉｎｕｘ（商標）などの異なるＯＳを走らせるようにする機能を有するものである。ハードウェア管理コンソールにシステム的に問い合わせすることにより、ＬＰＡＲ・ＶＭｗａｒｅで動作しているコンピュータの個々の論理区画での情報を、詳細に得ることができる。
【００８９】
以上、実施形態に基づき本発明を説明してきたが、本実施形態に記載されている内容は、本発明の一例であり、当業者なら、本発明の技術的範囲を逸脱することなく、さまざまな変形例に想到できることが、明らかであろう。例えば、ＣＭＤＢとそれに格納されたＣＩではなく、別の形式のデータベースとＣＩの形式を用いることもできる。また、Ｊａｖａ以外に、Ｃ＋＋、Ｃ＃など、ネットワーク管理機能をもつＡＰＩを呼び出すことのできる任意のコンピュータ開発環境を用いることができる。
【図面の簡単な説明】
【００９０】
【図１Ａ】ＣＩを管理するための、ＣＭＤＢを含む従来のコンピュータ・システムの例を示す。
【図１Ｂ】構成管理のためのツールの概要を示す。
【図２Ａ】サービスＡ及びサービスＢの各ＣＩインスタンス、及びそれらサービスの関係インスタンスの作成を示す。
【図２Ｂ】データ・モデル、ディスカバリ・インスタンス、ＣＩインスタンス、及び関係モデルを示す。
【図３Ａ】本発明の実施形態におけるサービス構成要素の例を示す。
【図３Ｂ】本発明の実施形態における、サービス構成要素の組み合わせの例を示す。
【図３Ｃ】本発明の実施形態における、データ・モデル、ディスカバリ・インスタンス、ＣＩインスタンス、及び関係モデルを示す。
【図３Ｄ】本発明の実施態様である、対象範囲特定ポリシーを説明するために使用する、構成要素及び該構成要素間の関係を示す。
【図３Ｅ】本発明の実施態様である、対象範囲特定ポリシーＡを用いた例を示す。
【図３Ｆ】本発明の実施態様である、対象範囲特定ポリシーＢを用いた例を示す。
【図３Ｇ】本発明の実施態様である、対象範囲特定ポリシーＣを用いた例を示す。
【図３Ｈ】本発明の実施態様である、対象範囲特定ポリシーＤを用いた例を示す。
【図４】従来のサービス・プロセス処理の例を示す。
【図５】本発明の実施形態における、サービス構成要素に対応するアクションの実行管理の概略を示す。
【図６】本発明の実施形態における、サービス・プロセスの実行可否を決定する流れを示す。
【図７Ａ】本発明の実施形態における、サービス構成要素に対応するアクションの処理の流れ（１／３）を示す。
【図７Ｂ】本発明の実施形態における、サービス構成要素に対応するアクションの処理の流れ（２／３）を示す。
【図７Ｃ】本発明の実施形態における、サービス構成要素に対応するアクションの処理の流れ（３／３）を示す。
【図８】本発明の実施形態における、ソフトウェアの変更・リリース管理への適用例を示す。
【図９】本発明の実施形態における、システムの処理のフローチャートを示す。
【図１０】本発明の実施形態における、コンピュータ・システムの例を示す。
【技術分野】
【０００１】
本発明は、サービス構成要素に対応するアクションの実行を管理するためのコンピュータ・システム、並びにその方法及びコンピュータ・プログラムに関する。
【背景技術】
【０００２】
ＩＴＩＬ（Information Technology Infrastructure Library）（英国政府の商標）とは、ＩＴサービスマネジメントを実現するためのベストプラクティス（最も良い事例）を集めたものである。ＩＴＩＬの中心は、サービスサポート及びサービスデリバリーである。サービスサポートの１つとして構成管理がある。構成管理とは、ＩＴサービスマネジメントの管理対象である構成要素（configuration item、構成アイテムともいう、以下ＣＩと略す場合がある）を認識し、構成要素についての情報を維持及び更新し、確認し、並びに監査を行うプロセスである。構成要素は、構成管理の対象となる資源（リソース）である。構成要素は、ハードウェア及びソフトウェアを含むシステム資源だけでなく、ＩＴサービスの提供に必要な設備、ＩＴサービスの運営に関する規程書、作業手順書及び構成図などのドキュメント類、ハードウェア又はソフトウェアの保守作業などのサービス、プロセス、並びに人的資源なども含む。ＩＴＩＬのフレームワークでは、構成要素を管理するために、構成管理データベース（Configuration Management Database、以下ＣＭＤＢと略す場合がある）というデータベースを用いて一元的に管理することが推奨されている。ＣＭＤＢは、構成要素の少なくとも１つの所定の属性及び他の構成要素との関係を記録するデータベースである。ＣＭＤＢを実装することで備わる最も重要な能力は、構成要素についての情報を自動的に発見する能力（ディスカバリ、自動検出ともいう）及び自動的に更新する能力（トラッキングともいう）である。ＣＭＤＢでは、構成要素についての情報をＣＭＤＢに正確に反映させることが重要である。
【０００３】
インターナショナル・ビジネス・マシーンズ・コーポレーション（商標、以下ＩＢＭ）は、ＣＭＤＢの構築を支援し且つＣＭＤＢを基盤に運用プロセスを制御するソフトとして、「Tivoli Change and Configuration Management Database」（以下、Tivoli CCMDB）を提供している。Tivoli CCMDBにおけるディスカバリ及びトラッキングの詳細は、IBM Redbooks Deployment Guide Series: IBM Tivoli Change and Configuration Management Database Configuration Discovery and Tracking v1.1、第41〜64頁、2006年11月（下記非特許文献１）を参照されたい。Tivoli CCMDBでは、運用管理ソフトが、ディスカバリ及びトラッキングを実行するように実装されている。
【０００４】
Tivoli CCMDBでは、分散ネットワーク環境上の構成要素であるサーバ、クライアント、オペレーティング・システム（ＯＳ）、ミドルウェア（Web/AP/DBMS/LDAPなど）、パッケージ・ソフト、管理ツール、ネットワーク機器及びストレージ機器など300種類を識別し、さらに各構成要素についての情報、例えばコンピュータの構成についての情報、各コンピュータ上で動作するアプリケーションについての情報、各コンピュータに接続されているネットワーク接続ストレージ（ＮＡＳ）などの構成情報、ネットワークに直接接続されているストレージエリアネットワーク（ＳＡＮ）などの構成情報を自動的に発見し及び更新することができる。各構成要素についての情報の収集方法は管理対象によっても異なるが、基本的にはＣＭＤＢを管理するコンピュータ・システムがＳＳＨ（Secure SHell）などを用いて管理用のリモート・インタフェースに定期的にアクセスし、ＯＳ上の設定ファイル又は構成情報を読み取ったり、或いはＣＭＤＢを管理するコンピュータ・システムが設定確認コマンドを実行したりする。そのため、管理対象である構成要素にエージェント・プログラムを導入する必要はない。上記の様式にて発見され且つ更新された情報は、ＩＢＭが提唱する構成管理データベース用のデータ・モデル「Common Data Model」（以下、ＣＤＭ）に基づいて、2006年の時点において、31種類のセクション（Computer System、Database、Application、Processなどのカテゴリ）、636種類のクラス（データ・モデルの基本単位、１つ又は複数のセクションに属する）、2609種類の属性（データの属性情報、１つのクラスに属する）、7種類のインタフェース（使用頻度の高い属性のグループ、複数のセクションに属する）、57種類の関係（リレーションシップ）、及び49種類のデータタイプ（データの種別）に整理される。ＣＤＭの詳細は、IBM REDPAPER (DRAFT version) IBM Tivoli Common Data Model: Guide to Best Practices（IBM Form Number REDP-4389-00）、第2〜7頁、2007年11月（下記非特許文献２）を参照されたい。各構成要素及び該構成要素と他の構成要素との関係についての情報は、ＧＵＩの表示ツール、例えばＴＡＤＤＭコンソールに渡される。そして、各構成要素及び該構成要素と他の構成要素との関係が、個々のブロック及び該ブロック間のリンクを用いて視覚的に表示装置上に表示される。
【０００５】
【非特許文献１】IBM Redbooks Deployment Guide Series: IBM Tivoli Change and Configuration Management Database Configuration Discovery andTracking v1.1、第41〜64頁、2006年11月
【非特許文献２】IBM RED PAPER (DRAFT version) IBM Tivoli Common Data Model: Guide to Best Practices（IBM Form Number REDP-4389-00）、第2〜7頁、2007年11月
【発明の開示】
【発明が解決しようとする課題】
【０００６】
近年、例えばＩＴサービス管理及びビジネスサービス管理のようなサービス管理が注目を集めている。特に、ＩＴＩＬ準拠のサービス管理が注目を集めている。サービス管理では、サービスレベルを満足させるために、サービス・プロセスを効率的に且つ停滞することなく実行する必要がある。ＩＴＩＬ準拠のサービス管理では、サービス・プロセスは、ＣＭＤＢ上のＣＩ情報を参照するオペレーションをプロセス化した複数のタスクから構成される。よって、ＩＴＩＬ準拠のサービス管理では、サービスレベルを満足させるために、ＣＩ情報が十分な頻度で更新される必要がある。
しかし、現状では、アクティブ型のディスカバリ装置が、定期的なポーリングによって構成要素についての情報（以下、ＣＩの情報という）を取得し、次に属性及び関係更新部が、該取得したＣＩの情報に基づいて、ＣＩインスタンスの属性値又は関係値を更新する。そのために、ＣＩインスタンスの更新が行われるまで、それを参照するサービス・プロセスが停滞することになる。また、他のサービス・プロセスが実行されているかどうかはユーザによる判断で行うため、サービス・プロセスが競合し失敗する可能性もある。
従来は、このようにサービス・プロセス間の依存関係を把握することができず、サービス・プロセスの効率的且つ安全な実行をすることができなかった。
【課題を解決するための手段】
【０００７】
本発明は、サービス構成要素に対応するアクションの実行を管理するためのコンピュータ・システムを提供する。該コンピュータ・システムは、
構成要素それぞれについての情報を検出するディスカバリ部と、
構成要素毎に、該構成要素の少なくとも１つの所定の属性及び該構成要素と他の構成要素との関係を示す１組のデータを保持するリポジトリと、
上記サービス構成要素を、該サービス構成要素に対応するアクションの対象である少なくとも１の構成要素に関連付ける関連付部と、
第１のサービス構成要素に対応するアクションの実行中に第２のサービス構成要素に対応するアクションへのリクエストがあり且つ該第２のサービス構成要素に対応するアクションの対象である少なくとも１の構成要素が該第１のサービス構成要素に対応するアクションの対象である構成要素に含まれる場合、該第２のサービス構成要素に対応するアクションを実行することが許されるかどうかを判定する判定部と
を含む。
【０００８】
本発明の１つの実施形態では、上記サービス構成要素が、１又は複数のサービス・プロセス又は該サービス・プロセスに含まれる１又は複数のサービス・ステップである。
【０００９】
本発明の１つの実施形態では、上記判定部が、上記サービス構成要素に対応するアクションを実行することが許されるかどうかを判定するためのルールを定義するポリシーによって上記アクションを実行することが許されるかどうかを判定する。
【００１０】
本発明の１つの実施形態では、上記アクションを実行することが許されるかどうかを判定することをユーザに選択することを可能にするインタフェースを表示部に提示する提示部をさらに含む。
【００１１】
本発明の１つの実施形態では、上記判定部が、上記アクションを実行することが許される場合、上記第２のサービス構成要素に対応するアクションを実行させ、上記判定部が、上記アクションを実行することが許されない場合、上記第２のサービス構成要素に対応するアクションの実行を待機させる。
【００１２】
本発明の１つの実施形態では、上記第１のサービス構成要素に対応するアクションの対象である構成要素が上記第２のサービス構成要素に対応するアクションの対象である構成要素と重複しない場合、上記第２のサービス構成要素に対応するアクションを実行することを許す。
【００１３】
本発明の１つの実施形態では、上記ディスカバリ部が、上記第１又は第２のサービス構成要素に対応するアクションの終了後に、構成要素についての情報を検出する。
【００１４】
本発明の１つの実施形態では、上記ディスカバリ部が、上記第１又は第２のサービス構成要素に対応するアクションの終了後に、該終了したサービス構成要素に対応するアクションの対象である構成要素についての情報を検出する。
【００１５】
本発明の１つの実施形態では、上記ディスカバリ部が、上記第１又は第２のサービス構成要素に対応するアクションの終了後に、上記第１のサービス構成要素に対応するアクションの対象である少なくとも１の構成要素と上記第２のサービス構成要素に対応するアクションの対象である構成要素との重複範囲に含まれる構成要素についての情報を検出する。
【００１６】
本発明の１つの実施形態では、上記関連付けが、上記第１のサービス構成要素に対応するアクションの開始に応じて行われる。
【００１７】
本発明の１つの実施形態では、上記関連付部が、上記第１のサービス構成要素に対応するアクションの終了に応じて、上記関連付けを解除する。
【００１８】
本発明の１つの実施形態では、上記第２のサービス構成要素に対応するアクションの実行が待機している場合、上記判定部が、上記第１のサービス構成要素に対応するアクションの終了に応じて、上記第２のサービス構成要素に対応するアクションを実行することが許されるかどうかをさらに判定する。
【００１９】
本発明の１つの実施形態では、所定の属性及び構成要素と他の構成要素との関係を定義するデータ・モデルが、サービス構成要素のアクション・タイプと該サービス構成要素に対応するアクションの対象である構成要素の範囲とを含む。
【００２０】
本発明はまた、サービス構成要素に対応するアクションの実行を管理する方法を提供する。該方法は、コンピュータ・システムに下記ステップを実行させるステップを含む。該コンピュータ・システムは、構成要素それぞれについての情報を検出するディスカバリ部と、構成要素毎に、該構成要素の少なくとも１つの所定の属性及び該構成要素と他の構成要素との関係を示す１組のデータを保持するリポジトリとを含む。上記方法は、
上記検出された情報に基づいて、構成要素毎に、該構成要素の少なくとも１つの所定の属性及び該構成要素と他の構成要素との関係を示す１組のデータを作成し、該１組のデータをリポジトリに格納するステップと、
上記サービス構成要素を、該サービス構成要素に対応するアクションの対象である少なくとも１の構成要素に関連付けるステップと、
第１のサービス構成要素に対応するアクションの実行中に第２のサービス構成要素に対応するアクションへのリクエストがあり且つ該第２のサービス構成要素に対応するアクションの対象である少なくとも１の構成要素が該第１のサービス構成要素に対応するアクションの対象である構成要素に含まれる場合、該第２のサービス構成要素に対応するアクションを実行することが許されるかどうかを判定するステップと
を含む。
【００２１】
本発明の１つの実施形態では、上記サービス構成要素が、１又は複数のサービス・プロセス又は該サービス・プロセスに含まれる１又は複数のサービス・ステップである。
【００２２】
本発明の１つの実施形態では、上記判定するステップが、上記サービス構成要素に対応するアクションを実行することが許されるかどうかを判定するためのルールを定義するポリシーによって上記アクションを実行することが許されるかどうかを判定するステップを含む。
【００２３】
本発明の１つの実施形態では、上記判定するステップが、上記アクションを実行することが許されるかどうかを判定することをユーザに選択することを可能にするインタフェースを表示部に提示するステップを含む。
【００２４】
本発明の１つの実施形態では、上記コンピュータ・システムに下記ステップを実行させるステップをさらに含む。該ステップは、
上記アクションを実行することが許される場合、上記第２のサービス構成要素に対応するアクションを実行すること許すステップと、
上記アクションを実行することが許されない場合、上記第２のサービス構成要素に対応するアクションの実行を待機させるステップと
を含む。
【００２５】
本発明の１つの実施形態では、上記コンピュータ・システムに下記ステップを実行させるステップをさらに含む。該ステップは、上記第１のサービス構成要素に対応するアクションの対象である構成要素が上記第２のサービス構成要素に対応するアクションの対象である構成要素と重複しない場合、上記第２のサービス構成要素に対応するアクションを実行することを許すステップをさらに含む。
【００２６】
本発明の１つの実施形態では、上記コンピュータ・システムに下記ステップを実行させるステップをさらに含む。該ステップは、上記第１又は第２のサービス構成要素に対応するアクションの終了後に、構成要素についての情報を検出するステップを含む。
【００２７】
本発明の１つの実施形態では、上記コンピュータ・システムに下記ステップを実行させるステップをさらに含む。該ステップは、上記第１又は第２のサービス構成要素に対応するアクションの終了後に、該終了したサービス構成要素に対応するアクションの対象である構成要素についての情報を検出するステップを含む。
【００２８】
本発明の１つの実施形態では、上記コンピュータ・システムに下記ステップを実行させるステップをさらに含む。該ステップは、上記第１又は第２のサービス構成要素に対応するアクションの終了後に、上記第１のサービス構成要素に対応するアクションの対象である少なくとも１の構成要素と上記第２のサービス構成要素に対応するアクションの対象である構成要素との重複範囲に含まれる構成要素についての情報を検出するステップを含む。
【００２９】
本発明の１つの実施形態では、上記関連付けるステップが、上記第１のサービス構成要素に対応するアクションの開始に応じて行われる。
【００３０】
本発明の１つの実施形態では、上記コンピュータ・システムに下記ステップを実行させるステップをさらに含む。該ステップは、上記第１のサービス構成要素に対応するアクションの終了に応じて、上記関連付けを解除するステップを含む。
【００３１】
本発明の１つの実施形態では、上記コンピュータ・システムに下記ステップを実行させるステップをさらに含む。該ステップは、上記第２のサービス構成要素に対応するアクションの実行が待機している場合、上記第１のサービス構成要素に対応するアクションの終了に応じて、上記第２のサービス構成要素に対応するアクションを実行することが許されるかどうかを判定するステップを含む。
【００３２】
本発明はまた、構成要素それぞれについての情報を検出するディスカバリ部と、構成要素毎に、該構成要素の少なくとも１つの所定の属性及び該構成要素と他の構成要素との関係を示す１組のデータを保持するリポジトリとを含むコンピュータ・システムにおいて、サービス構成要素に対応するアクションの実行を管理する方法を提供する。該方法は、コンピュータ・システムに下記ステップを実行させるステップを含む。該ステップは、
上記サービス構成要素を、該サービス構成要素に対応するアクションの対象である少なくとも１の構成要素に関連付けるステップと、
第１のサービス構成要素に対応するアクションの実行中に第２のサービス構成要素に対応するアクションへのリクエストがあり且つ該第２のサービス構成要素に対応するアクションの対象である少なくとも１の構成要素が該第１のサービス構成要素に対応するアクションの対象である構成要素に含まれる場合、
該第２のサービス構成要素に対応するアクションを実行することが許されるかどうかを判定するステップと、
上記アクションを実行することが許される場合、上記第２のサービス構成要素に対応するアクションを実行させるステップと、
上記アクションを実行することが許されない場合、上記第２のサービス構成要素に対応するアクションの実行を待機させるステップと、
上記第１のサービス構成要素に対応するアクションの対象である構成要素が上記第２のサービス構成要素に対応するアクションの対象である構成要素と重複しない場合、上記第２のサービス構成要素に対応するアクションを実行することを許すステップと、
上記第１又は第２のサービス構成要素に対応するアクションの終了後に、構成要素についての情報を検出するステップと
を含む。
【００３３】
本発明はさらに、サービス構成要素に対応するアクションの実行を管理するコンピュータ・プログラムを提供する。該コンピュータ・プログラムは、コンピュータ・システムに、上記のいずれか一つに記載の方法の各ステップを実行させる。
【発明の効果】
【００３４】
本発明の実施形態によれば、サービス構成要素に対応するアクションはその開始時に実行中の他のサービス構成要素（例えば、サービス・プロセス、サービス・ステップ）についての情報を参照できるので、サービス構成要素に対応するアクションよって利用される構成要素の競合が発生しなくなる。また、対象ＣＩへのアクションによっては、サービス構成要素に対応するアクションの同時実行が可能となり、必ずしも待機する必要が無くなる。
【発明を実施するための最良の形態】
【００３５】
以下、ＣＭＤＢに関する基本的な用語を下記に説明する。
本発明の実施形態において、リポジトリは少なくとも１つの１組のデータを格納する。該１組のデータは、構成要素の少なくとも１つの所定の属性及び他の構成要素との関係を示すデータである。該１組のデータは例えば、ソフトウェア構成要素の少なくとも１つの所定の属性及び該ソフトウェア構成要素と他のソフトウェア構成要素又はハードウェア構成要素との関係を示すデータを含む。上記リポジトリは例えば、ＣＭＤＢである。構成要素、及び該構成要素と他の構成要素との関係は例えば、静的な（static）データのインスタンス又はＪａｖａ（サン・マイクロシステムズの商標）のクラスのインスタンスで実装されうる。上記リポジトリは、該１組のデータを保持するものであれば特に限定されないが、好ましい実施形態の１つはＣＭＤＢを記録するＣＭＤＢ記録部である。
・構成要素（ＣＩ）
ＣＩは、ＩＴサービスマネジメントの対象範囲に属する構成要素に対応するデータであり、ＩＴサービスマネジメントにおける管理対象の基本単位である。ＣＩは例えば、ハードウェア及びソフトウェアを含むシステム資源、ＩＴサービスの提供に必要な設備、ＩＴサービスの運営に関する規程書、作業手順書及び構成図などのドキュメント類、ハードウェア又はソフトウェアの保守作業などのサービス、プロセス、並びに人的資源などを含む。今後も様々なタイプのＣＩが、ＣＭＤＢで管理されるようになる。また、各ＣＩはデータ・モデルのインスタンスとしてＣＭＤＢ上で表現される。
・構成管理データベース（ＣＭＤＢ）
ＣＭＤＢは、情報システムの全コンポーネントに関する情報の統合された保管・管理を行うデータベースである。ＣＭＤＢは、各ＣＩの少なくとも１つの所定の属性及び他のＣＩとの関係を記録する。ＣＭＤＢは組織がコンポーネント間の関係を理解することを支援し、その構成を管理できるようにする。ＣＭＤＢはＩＴＩＬフレームワークの構成管理プロセスの中核となっている。ＣＭＤＢは、概念的にはデータベースであるが、物理的にはデータベース・システム、表計算ソフトのスプレッドシートの形態を取りうる。ＣＭＤＢを利用することによって、管理者はＣＩ間の関係を理解することが容易になる。
・構成要素インスタンス（ＣＩインスタンス）
ＣＩインスタンスは、ＣＩに対応するデータである。各ＣＩインスタンスは、データ・モデルのインスタンスとしてＣＭＤＢ上で表現される。インスタンスの例は、静的なデータのインスタンス又はＪａｖａ（サン・マイクロシステムズの商標）のクラスのインスタンスである。実装されたＪａｖａのクラスのインスタンスは、例えばJava Data Objects（ＪＤＯ）と呼ばれる、Ｊａｖａのクラスのインスタンスを永続化してハードディスクに保存する仕組みにより、ＣＭＤＢ内に格納される。よって、コンピュータ・システムの電源を一旦切っても、作成されたＪａｖａのクラスのインスタンスが消失することはなく、次に電源を投入したときに、記憶装置、例えばハードディスクから読み出され、メイン・メモリ上に展開されて、Ｊａｖａのプログラムによって変更或いは削除可能なＪａｖａのクラスのインスタンスとなる。以下では、ＣＩがインスタンスとしてＣＭＤＢ内に実装されるとして、説明を進める場合がある。
・データ・モデル
データ・モデルは、ＣＩを定義するためのスキーマであり、管理されるＣＩとそれらＣＩ間の関係の一貫した定義を提供する情報モデルである。具体的には、データ・モデルは、ＣＩの所定の属性及び他のＣＩ（製造装置、プロセスなど）との関係を定義する。データ・モデルの例として、ＩＢＭが提唱する構成管理データベース用のデータ・モデル「ＣＤＭ」がある。ＣＤＭの実装は例えば、Unified Modeling Language（ＵＭＬ）に基づいて行われる。
・属性（Attributes）
属性は、ＣＩを管理するに際して、個々のＣＩを特定し、ＣＩを説明する。属性として、下記のものを挙げることができるがこれらに限定されない。ＣＩの名前（ＣＩの一般名称、例えばサーバ、クライアント、ファイアウォール）、製品番号（ＩＤ）（ＣＩのある特定の実体を個別に識別するための番号であり、製造番号、シリアル番号など）、カテゴリ（ＣＩの分類、例えばハードウェア、ソフトウェア、ドキュメント）、タイプ（カテゴリでの分類をさらに詳述したＣＩの説明）、型番（供給者の命名したＣＩのモデル番号）、保証期間（ＣＩの供給者による保証期間）、バージョン番号（ＣＩのバージョン番号）、ロケーション（ＣＩが存在する場所、例えばＰＣの設置場所、ソフトウェアの書庫、媒体の保管場所、サービスを提供しているサイト）、所有責任者（ＣＩの管理責任者の名前）、責任開始日（所有責任者が、該ＣＩの責任者となった日付）、供給者（ＣＩの開発元又は提供元）、ライセンス（ライセンス番号、ライセンス数など）、提供日（ＣＩが組織に提供された日付）、受入日（ＣＩが組織に受け入れられた日付）、使用開始日（ＣＩが使用開始された日付）、ＣＩのステータス（現在のステータス、例えば稼働中、テスト中、故障中、或いは将来のステータス、例えば予定されているＣＩのステータス）、ＣＩインスタンスのステータス（ＣＩインスタンスの有効又は無効）。今後もＩＴサービスマネジメントで必要となる属性が、引き続き定義されていく。
・関係（Relation）
関係は、ＣＩ間の関係を表す。関係は、ＣＩと同様にデータ・モデルで定義されうる。関係の例として、Ｃｏｍｍｏｎ Ｄａｔａ Ｍｏｄｅｌ では、assigns、canConnect、canUse、connectAt、connects、controls、deployedOn、Located、Managed、Owned、provides、runAt、uses、usedByが挙げられる。今後もＩＴサービスマネジメントで必要となる関係が、引き続き定義されていく。
【００３６】
本発明の実施形態において、構成要素は、典型的に、ハードウェア構成要素及び／又はソフトウェア構成要素と、サービス構成要素とを含む。本発明の実施形態において、サービス構成要素に対応するアクションの実行を管理するためのコンピュータ・システムは、これら構成要素を含む単一又は複数のシステムを管理対象とする。該複数のシステムは、ネットワークによって有線又は無線接続されうる。
【００３７】
サービス構成要素とは、１つのサービス・プロセス、複数のサービス・プロセス、１つのサービス・ステップ及び複数のサービス・ステップから選択されるサービスである。サービス・プロセスは、少なくとも１のサービス・ステップを含む。
よって、本発明の実施形態において、第１のサービス構成要素は、１つのサービス・プロセス、複数のサービス・プロセス、１つのサービス・ステップ及び複数のサービス・ステップから選択されるサービス構成要素である。同様に、本発明の実施形態において、第２のサービス構成要素は、１つのサービス・プロセス、複数のサービス・プロセス、１つのサービス・ステップ及び複数のサービス・ステップから選択されるサービス構成要素である。
【００３８】
本発明の実施形態において「アクション」とは、サービス構成要素に対応するアクションの内容に従い、該アクションの対象である少なくとも１つの構成要素に対して行う処理をいう。
アクション・タイプとは、アクションの対象である構成要素に対して行う処理の種類である。アクション・タイプは例えば、新規、変更、削除、参照、検索などを含むが、これらに限定されない。新規とは例えば、アクションの対象である構成要素がデータベースの場合、該データベースにデータを追加する処理である。変更とは例えば、アクションの対象である構成要素がデータベースの場合、該データベース中のデータを更新する処理である。削除とは例えば、アクションの対象である構成要素がデータベースの場合、該データベース中のデータを削除する処理である。参照とは例えば、アクションの対象である構成要素がデータベースの場合、該データベース中のデータを参照する処理である。検索とは例えば、アクションの対象である構成要素がデータベースの場合、該データベースのデータ中のデータをクエリに従い検索する処理である。
アクション・タイプが新規、変更、削除の場合、アクションの対象である構成要素についての属性値が変化する。該変化する属性値が複数のサービス構成要素から共通で利用される場合、該複数のサービスを実行する順によって、該複数のサービス構成要素についての属性値に違いが生じうる。
一方、アクション・タイプが参照及び検索の場合、該構成要素についての属性値は変化しない。よって、該変化する属性値が複数のサービスから共通で利用される属性値であっても、該複数のサービスが実行される順によらず、該複数のサービスの実行結果は同じである。
【００３９】
本発明の実施形態において「サービス構成要素に対応するアクションの対象である」とは、サービス構成要素に対応するアクションの実行により影響を受ける構成要素を示す。なお、本発明の実施形態において、影響を受ける対象は、アクションの影響範囲によって特定されうる。該範囲は、データ・モデルに規定された範囲によって又はユーザによって対象ＣＩ属性に設定されうる。データ・モデルは、モデル・テーブル（下記図１Ａ、１０７を参照）に格納されうる。該範囲は例えば、ノードとの距離を示すレベル、ＣＩインスタンスのモデル名、関係を用いた式で表されるが、これらに限定されない。該範囲はまた、サービス構成要素に対応するアクションの対象範囲を特定するために使用されるポリシー（以下、対象範囲特定ポリシー）によって動的に決定されうる。
「ノードとの距離を示すレベル」の１つの態様として、サービス構成要素を親ノード（０ノード）として表した場合に、該サービス構成要素と１ノードの関係にあるサービス構成要素をレベル０、レベル１の構成要素と１ノードの関係にある構成要素をレベル１、レベル１の構成要素と１ノードの関係にある構成要素をレベル２、・・・、レベルｎの構成要素とｎノードの関係にある構成要素をレベルｎ＋１、と表す。
「ノードとの距離を示すレベル」の他の態様として、サービス構成要素をノードとして表した場合、サービス構成要素と関係のある構成要素をレベル０、レベル０の構成要素と関係のある構成要素をレベル１、レベル１の構成要素と関係のある構成要素をレベル２、・・・、レベルｎの構成要素と関係のある構成要素をレベルｎ＋１、と表す。例えば、ノードに対応するアクション構成要素についてデータベースを更新するアプリケーションとした場合、データベースに対応する構成要素はレベル０であり、該データベースがインストールされているＯＳはレベル１であり、該ＯＳがインストールされているコンピュータはレベル２である。上記関係は、例えば、runsOn and useなどの構成要素間の関係によっても特定されうる。
「ＣＩインスタンスのモデル名」とは、ＣＩインスタンスに定義される該インスタンスが、どのデータ・モデルを使用して作成されたかを示すモデル名である。代替的に、ＣＩインスタンスに定義される該インスタンスがどのＣＩのものであるかを特定するための「インスタンス名」を使用してもよい。
「関係を用いた式」とは例えば、runsOn and useなどの構成要素間の関係で表されるが、これらに限定されない。該例は、サービス構成要素に対応するアクション上で動いている構成要素（サービス構成要素を含む）に対応するアクションを使用している構成要素が、サービス構成要素に対応するアクションの実行により影響を受ける構成要素であることを示す。
「対象範囲特定ポリシー」は、サービス構成要素と関係のある構成要素を決めるために使用されうる。該対象範囲ポリシーは、構成要素、特にサービス構成要素、ソフトウェア構成要素、ハードウェア構成要素の属性及びこれら構成要素間の関係の少なくとも１以上の条件を用いて定義される。
【００４０】
本発明の実施形態において「実行可否を判定するためのルールを定義するポリシー」（以下、可否判定ポリシー）とは、複数のサービスによって共通する構成要素が利用される場合の動作ルールを定義したデータである。可否判定ポリシーは例えば、先行のサービス構成要素に対応するアクション（以下、先行プロセス）のアクション・タイプ及び後発のサービス構成要素に対応するアクション（以下、後発プロセス）のアクション・タイプに応じた後発プロセスの動作で表される。
【００４１】
本発明の実施形態において、ステータス制御部が可否判定ポリシーを使用して、サービス構成要素に対応するアクションの実行可否を判定しうる。ステータス制御部は、サービス・プロセスを管理するために、実行中のサービス構成要素についての対象ＣＩ属性を管理する。対象ＣＩ属性は、サービス・プロセスに対応するアクションの対象であるＣＩ（以下、サービス・プロセスの対象ＣＩに対するアクション・タイプ及び影響範囲）を表す。
【００４２】
以下、図面に従って、本発明の実施形態を説明する。本実施形態は、本発明の好適な態様を説明するためのものであり、本発明の範囲をここで示すものに限定する意図はないことを理解されたい。また、以下の図を通して、特に断らない限り、同一符号は、同一の対象を指す。
【００４３】
図１Ａは、ＣＩを管理するための、ＣＭＤＢを含む従来のコンピュータ・システム（１００）の例を示す。
図１Ａは、ＣＩの例として、サービスＡ及びサービスＢを記載する。
コンピュータ・システム（１００）は、ディスカバリ部（１０１）、ＣＩ同定部（１０２）、ＣＩインスタンス作成部（１０３）、属性及び関係更新部（１０４）及びＣＭＤＢ（１０５）を含む。ディスカバリ部、ＣＩ同定部、ＣＩインスタンス作成部、属性及び関係更新部及びＣＭＤＢは、単独のコンピュータ上に実装されていてもよく、或いは複数のコンピュータ上に分散して実装されていてもよい。コンピュータ・システム（１００）はさらに、ディスカバリ・テーブル（１０６）、モデル・テーブル（１０７）及び関係テーブル（１０８）を含む。これらテーブルは、単独のコンピュータ上に実装されていてもよく、或いは複数のコンピュータ上に分散して実装されていてもよい。
また、図１Ａは、ＴＡＤＤＭコンソールの画面（１０９）の例を示す。該画面は、ＣＩ及びＣＩ間の接続関係を示す。なお、該画面に表示されているＣＩ及びＣＩ間の接続関係は一例であり、コンピュータ・システム（１００）の管理対象であるＣＩ及びＣＩ間の接続関係全てを表示しているものではない。
コンピュータ・システム（１００）は、それ自身の管理対象である構成要素を管理する。コンピュータ・システム（１００）の管理対象は、該コンピュータ・システム（１００）がディスカバリしうる対象の構成要素である。
【００４４】
ディスカバリ部（１０１）は、ＣＭＤＢの管理対象であるＣＩについての情報の検出を実行する（ディスカバーともいう）。該ＣＩの一部が、ＴＡＤＤＭコンソールの画面（１０９）に表示されている。コンピュータ・システム（１００）は、複数のディスカバリ部（１０１）を有していてもよい。好ましくは、管理対象は、ネットワークを介して、コンピュータ・システムに接続されている。ネットワークは、有線接続であるか無線接続であるかを問わない。コンピュータ・システムの管理者は、検出の対象を任意に設定しうる。検出の範囲は例えば、ドメイン名、ＩＰアドレス、ＭＡＣアドレス、機器の識別子若しくはデータベース名又はこれらの組み合わせにより指定することができる。管理対象であるＣＩが例えば機器又はサービスである場合、該機器又はサービスについての情報が夫々検出される。検出された情報は、新たなＣＩについての情報、又は既存のＣＩの更新された属性若しくは関係の値でありうる。新たなＣＩとは、ディスカバリ部（１０１）によって検出され、ＣＭＤＢ（１０５）内に登録されていないＣＩである。既存のＣＩとは、該ＣＩのインスタンスがＣＭＤＢ（１０５）内に既に登録されているＣＩである。ディスカバリ部（１０１）は、ＣＩについての情報を、ディスカバリ・テーブル（１０６）内に格納されたディスカバリ・データ（例えばA-Discovery）（図２Ｂ、２０２）に従い検出する。どのディスカバリ・データを使用するかは、データ・モデル（図２Ｂ、２０１）内のディスカバリ方法に指定されている。ディスカバリ部（１０１）は、検出した、ＣＩについての情報をＣＩ同定部（１０２）に渡す。
【００４５】
ＣＩ同定部（１０２）は、上記ＣＩについての情報をディスカバリ部（１０１）から受け取り、そして検出結果の処理を行う。ＣＩ同定部（１０２）は、上記ＣＩについての情報が、新しいＣＩについての情報か、又は既存のＣＩの更新された属性若しくは関係の値かどうかを、ＣＭＤＢ（１０５）を参照して判定する。該判定は例えば、ＣＭＤＢに格納されたＣＩのインスタンス名を、上記ＣＩについての情報と比較して行われうる。上記ＣＩについての情報が新しいＣＩに関するものであることに応じて、ＣＩ同定部（１０２）は、該情報をＣＩインスタンス作成部（１０３）に渡す。一方、上記ＣＩについての情報が既存のＣＩの更新された属性若しくは関係の値であることに応じて、ＣＩ同定部（１０２）は、該情報を属性及び関係更新部（１０４）に渡す。
【００４６】
ＣＩインスタンス作成部（１０３）は、モデル・テーブル（１０７）に格納されたデータ・モデル（図２Ｂ、２０１）、及び関係テーブル（１０８）に格納された関係モデル（図２Ｂ、２０４）に従い、ＣＩについての情報から、該ＣＩの所定の属性及び他のＣＩとの関係を示す１組のデータを作成する。該１組のデータは例えば、静的なデータのインスタンス又はＪａｖａ（サン・マイクロシステムズの商標）のクラスのインスタンスで実装されうる。該１組のデータの例が、ＣＩインスタンスである。ＣＩインスタンスの例を図２Ｂ（２０３）に示す。上記１組のデータは、ＣＭＤＢ（１０５）内に格納される。なお、１組のデータは、ＣＩインスタンス内に属性及び関係を有していてもよく（図２Ｂ、２０３を参照）、或いはＣＩインスタンス内に属性を有し、それとは別に関係インスタンスとして別々にＣＭＤＢ（１０５）内に格納されていてもよい。後者の場合、ＣＩインスタンスは、関連する関係インスタンスを特定するためのリンク付けを有する。
【００４７】
属性及び関係更新部（１０４）は、ディスカバリ部（１０１）とともにトラッキングを実現する。属性及び関係更新部（１０４）は、ＣＩの更新された属性若しくは関係の値を、ＣＭＤＢ内に格納された該ＣＩのＣＩインスタンスに反映する。すなわち、該ＣＩのＣＩインスタンスの属性或いは関係の値を更新する。該更新は、該値をディスカバリ部（１０１）によって検出されたＣＩについての情報と置き換えることによって行われる。該置き換えは、ＣＩインスタンスの属性或いは関係の値のすべてをディスカバリ部（１０１）によって検出されたＣＩについての情報と置き換えてもよく、或いは異なる値のみを置き換えてもよい。
【００４８】
ＣＭＤＢ（１０５）は、ＣＩのＣＩインスタンス（図２Ｂ、２０３）を格納する。
【００４９】
ディスカバリ・テーブル（１０６）は、ディスカバリ・データ（図２Ｂ、２０２）を格納する。ディスカバリ・データは、ディスカバリ部（１０１）によってＣＩについての情報が検出される際に使用される。ディスカバリ・データ（図２Ｂ、２０２）は例えば、静的なデータのインスタンス又はＪａｖａ（サン・マイクロシステムズの商標）のクラスのインスタンスで実装されうる。ディスカバリ・データは、ディスカバリ・ポリシーとも呼ばれる。ディスカバリ・データ（図２Ｂ、２０２）は、ディスカバリ部（１０１）が検索する範囲、すなわちＣＩの検索範囲である収集対象（スコープ）、収集する属性、及び収集する関係を含む（図２Ｂ、２０２）。収集対象は例えば、サブネットＩＰアドレス、ＩＰアドレスの範囲、個々のＩＰアドレス、ＭＡＣアドレス、機器の識別子、ホストネーム若しくはデータベース名又はそれらの組み合わせを用いて指定されうる。別の態様として、収集対象を、コンピュータ・システム（１００）にネットワークを介して接続されたスケジュール管理データベース（図示せず）としてもよい。スケジュール管理データベースには例えば、機器を使用するプロセス管理に関するデータが格納されている。さらに別の態様として、収集対象を、バッチ処理定義ファイルを格納するデータベース（図示せず）としてもよい。収集対象がバッチ処理定義ファイルを格納するデータベースの場合、ディスカバリ部（１０１）は、バッチ処理定義ファイルの中身を読み込むことにより検出を行う。バッチ処理定義ファイルには、例えば機器をどの順に使用するかのデータが格納されている。
【００５０】
モデル・テーブル（１０７）は、データ・モデル（図２Ｂ、２０１）を格納する。データ・モデルは、ＣＩインスタンス作成部（１０３）によって該ＣＩの所定の属性及び他のＣＩとの関係を示す１組のデータが作成される際に使用される。
【００５１】
関係テーブル（１０８）は、関係モデル（図２Ｂ、２０４）を格納する。関係モデルは、ＣＩインスタンス作成部（１０３）によって該ＣＩの所定の属性及び他のＣＩとの関係を示す１組のデータが作成される際に使用される。
【００５２】
図１Ａは、ディスカバリ部（１０１）が、コンピュータ・システム（１００）とネットワークを介して接続された管理対象であるＣＩに関する情報を検出し、サービスＡ、及びサービスＢ並びにそれらサービスの関係についての情報を検出したことを示す。次に、ＣＩ同定部（１０２）は、該検出した情報が新しいＣＩについてのものかについてＣＭＤＢ（１０５）を参照して判断する。該判断に応じて、ＣＩインスタンス作成部（１０３）は、サービスＡのＣＩインスタンス及びサービスＢのＣＩインスタンス、並びにそれらサービスの関係（usedBy）のインスタンスを作成する。ＣＩインスタンス作成部（１０３）は、該作成した各インスタンスをＣＭＤＢ（１０５）内に格納する。図１Ａでは、サービスＢのＣＩインスタンスが、サービスＡのＣＩインスタンスとusedByの関係にあることを示す。
ディスカバリ部（１０１）は、検出したＣＩについての情報をもとに、データ・モデル（図２Ｂ、２０１）に従って、ＣＩ及びそれらＣＩ間の関係を作成し、ＣＭＤＢ（１０５）に登録する。ＣＭＤＢ（１０５）は、ＣＩの属性及び他のＣＩとの関係を格納する。従って、システム管理者は、ＣＭＤＢ（１０５）を用いて、ＣＩ間のリアルな依存関係を抽出することが可能である。
【００５３】
図１Ａでは、構成要素としてサービス構成要素であるサービスＡ及びサービスＢを例にして説明した。上記説明は、サービス構成要素をハードウェア構成要素及びその他の構成要素に置き換えた場合にも同様に適用される。
【００５４】
図１Ｂは、構成管理のためのツールの概要を示す。
構成管理のためのツールは、構成要素についての情報（以下、単に構成情報という場合がある）を自動収集する機能（ディスカバリ）、構成情報をグラフィカルに表示する機能（トポロジー）及び変更履歴、構成比較などの分析を行う機能（アナリティクス）を有する。例えば、ＴＡＤＤＭサーバは、情報システムについての構成情報を、ｓｓｈ、ＳＮＭＰ、ＷＭＩなどを使用して取得する。上記構成情報は例えば、各情報システムのオペレーティング・システムの種類又はその構成、アプリケーションの種類又はその構成値である。ＴＡＤＤＭサーバは、取得した情報を、ＣＭＤＢ内にＣＩインスタンスとして格納する。ＴＡＤＤＭサーバは、ＣＭＤＢに格納したＣＩインスタンス基づいて、管理者のコンピュータに構成情報、及び変更履歴情報を送る。管理者のコンピュータは、該情報を用いて、構成情報の表示及び変更履歴の表示を行う。
【００５５】
図２Ａは、ＣＩ（例えば、サービスＡ及びサービスＢ）のＣＩインスタンス、及びそれらサービスの関係（usedBy）インスタンスの作成を示す。
サービスＡのＣＩインスタンスは、ディスカバリ部（図１Ａ、１０１）によって検出されたサービスＡについての情報から、サービスＡのデータ・モデルを用いてＣＩインスタンス作成部（図１Ａ、１０３）によって作成される。同様に、サービスＢのＣＩインスタンスは、ディスカバリ部（図１Ａ、１０１）によって検出されたサービスＢについての情報から、サービスＢのデータ・モデルを用いてＣＩインスタンス作成部（図１Ａ、１０３）によって作成される。サービスＡ及びサービスＢの各データ・モデルは、モデル・テーブル（図１Ａ、１０７）に格納されている。ＣＩ同士の関係、すなわちサービスＡとサービスＢとの関係（usedBy）のインスタンスは、ディスカバリ部（図１Ａ、１０１）によって検出されたサービスＡについての情報から、関係モデルに従いＣＩインスタンス作成部（図１Ａ、１０３）によって作成される。関係モデルは、関係テーブル（図１Ａ、１０８）に格納されている。
また、サービスが例えばサービスＢ１、Ｂ２、Ｂ３である場合、サービスＢ１、Ｂ２、Ｂ３についての各情報がサービスＢのデータ・モデルを使用してインスタンス化されて、サービスＢ１のＣＩインスタンス、サービスＢ２のＣＩインスタンス、サービスＢ３のＣＩインスタンスが夫々作成される。サービスＢ１、Ｂ２、Ｂ３の各ＣＩインスタンスもまた、ＣＭＤＢ（１０５）内に格納される。
【００５６】
図２Ｂは、モデル・テーブル（図１Ａ、１０７）内に格納されたデータ・モデル（２０１）、ディスカバリ・テーブル（図１Ａ、１０６）内に格納されたディスカバリ・インスタンス（２０２）、ＣＭＤＢ（図１Ａ、１０５）内に格納された（サービスＡの）ＣＩインスタンス（２０３）及び関係テーブル（図１Ａ、１０８）内に格納された関係モデル（２０４）を示す。
【００５７】
データ・モデル（２０１）は、ＣＩを定義するためのスキーマである。データ・モデル（２０１）は例えば、どのＣＩのモデルかを示す「モデル名」、モデル名に指定されたＣＩが有する属性を示す「モデル属性」、モデル名に指定されたＣＩと他のＣＩがとりうる「関係」、及びモデル名に指定されたＣＩを検出するためのディスカバリ・インスタンスを特定する「ディスカバリ方法」の各記述を含む。モデル属性は、例えばＩＢＭが提唱する構成管理データベース用のデータ・モデル「ＣＤＭ」に規定された属性に従い規定されるが、これらに限定されない。ＣＤＭでは、2006年の時点において、2609種類の属性が規定されている。ＣＭＤＢの管理者は、データ・モデル（２０１）における属性を任意に指定しうる。関係は、例えば上記ＣＤＭに規定された関係に従い規定されるが、これらに限定されない。ＣＤＭでは、2006年の時点において、57種類の関係が規定されている。ディスカバリ方法は、ディスカバリ・インスタンス名で特定されうる。図２Ｂの場合、A-Discoveryである。
【００５８】
ディスカバリ・インスタンス（２０２）は、データ・モデル（２０１）のディスカバリ方法によって特定されるディスカバリ・インスタンスの「名前」、ディスカバリ部（図１Ａ、１０１）によって収集する管理対象（ＣＩ）の「収集対象（スコープ）」、ディスカバリ部（図１Ａ、１０１）によって収集する管理対象（ＣＩ）の「収集する属性」及び「収集する関係」、並びに該ディスカバリ・インスタンスがアクティブであるか或いはインアクティブであるかを示す「ステータス」の各記述を含む。
【００５９】
ＣＩインスタンス（２０３）は、該インスタンスがどのＣＩのものであるかを特定するための「インスタンス名」、該インスタンスが、どのデータ・モデルを使用して作成されたかを示す「モデル名」、データ・モデルによって特定された各属性の「属性値」、データ・モデルによって特定された各「関係」の記述（値）、インスタンスがアクティブであるか或いはインアクティブであるかを示す「ステータス」、及び該ＣＩインスタンスが作成された「作成日時」の各記述を含む。ＣＩインスタンスは好ましくは、ＣＩインスタンスに特有のＣＩインスタンス識別子をさらに含む。ＣＩインスタンス識別子は、当該ＣＩインスタンスを他のＣＩインスタンスと区別できるものであれば特に限定されないが、例えばホストネーム、シリアルナンバー若しくは一定の値である他の属性の組み合わせを使用しうる。図２ＢのＣＩインスタンス（２０３）は、サービスＡのＣＩインスタンスであること；データ・モデルＡを使用してインスタンス化されたこと；属性としてＳ、Ｔ及びＵを含み、これらが夫々値を有すること；関係として、Ｍによって使用されること（usedBy:M）、Ｅに接続されること（connectAt:E）、及びＨで実行すること（runAt:H）；ＣＩインスタンスがアクティブであること、並びに該ＣＩインスタンスの作成日時のデータを示す。
【００６０】
関係モデル（２０４）は、データ・モデル（２０１）によって特定される関係を定義するためのスキーマである。関係モデル（２０４）は、usedByなどの「関係名」、該関係の対象となるデータ・モデルを特定するための「対象となるデータ・モデル」、該関係の「説明」の各記述を含む。
【００６１】
図３Ａは、本発明の実施形態におけるサービス構成要素の例を示す。
（１つの）サービス構成要素は例えば、１つのサービス・プロセス（３０１）を１単位として、複数のサービス・プロセス（図示せず）を１単位として、１つのサービス・ステップ（３０２）を１単位として及び複数のサービス・ステップ（３０３）を１単位としてのいずれかである。
よって、本明細書において、サービス構成要素という場合、１つのサービス・プロセスそのものがサービス構成要素である態様、複数のサービス・プロセスがサービス構成要素である態様、１つのサービス・ステップそのものがサービス構成要素である態様、複数のサービス・ステップがサービス構成要素である態様を含む。
【００６２】
図３Ｂは、本発明の実施形態における、サービス構成要素の組み合わせの例を示す。
図３Ｂの３１１は、サービス構成要素として１つのサービス・プロセス（３１４）及びサービス構成要素として１つの別のサービス・プロセス（３１５）を示す。例えば、サービス構成要素（３１４）が第１のサービス構成要素であり、サービス構成要素（３１５）が第２のサービス構成要素である。或いは、サービス構成要素（３１５）が第１のサービス構成要素であり、サービス構成要素（３１４）が第２のサービス構成要素である。
図３Ｂの３１２は、サービス構成要素として１つのサービス・プロセス（３１６）及びサービス構成要素として上記サービス・プロセス（３１６）と異なるサービス・プロセス中の複数のサービス・ステップ（３１７）を示す。例えば、サービス構成要素（３１６）が第１のサービス構成要素であり、サービス構成要素（３１７）が第２のサービス構成要素である。或いは、サービス構成要素（３１７）が第１のサービス構成要素であり、サービス構成要素（３１６）が第２のサービス構成要素である。
図３Ｂの３１３は、サービス構成要素として１つのサービス・プロセス中の複数のサービス・ステップ（３１８）及びサービス構成要素として上記サービス・プロセスと異なる別のサービス・プロセス中の複数のサービス・ステップ（３１９）を示す。例えば、サービス構成要素（３１８）が第１のサービス構成要素であり、サービス構成要素（３１９）が第２のサービス構成要素である。或いは、サービス構成要素（３１９）が第１のサービス構成要素であり、サービス構成要素（３１８）が第２のサービス構成要素である。
上記は、サービス構成要素の組み合わせの一例であって、上記３つの態様（３１１、３１２、３１３）に限定されるものでない。
【００６３】
図３Ｃは、本発明の実施形態における、データ・モデル（３１１）、（サービスＡの）ＣＩインスタンス（３１３）及び関係モデル（３１４）を示す。
データ・モデル（３１１）は、モデル・テーブル（図１Ａ、１０７）内に格納される。ＣＩインスタンス（３１３）は、ＣＭＤＢ（図１Ａ、１０５）内に格納される。関係モデル（３１４）は、関係テーブル（図１Ａ、１０８）内に格納される。
本発明の実施形態におけるデータ・モデル（３１１）には、図２Ｂのデータデル（２０１）と比較して、属性「アクション・タイプ」及び属性「影響範囲」が追加されている。属性「アクション・タイプ」は例えば、新規、変更、削除、参照及び検索であるが、これらに限定されない。属性「影響範囲」は例えば、モデル名に指定されたＣＩからの距離を示すレベル、ＣＩインスタンスのモデル名、関係であるが、これらに限定されない。
同様に、本発明の実施形態におけるＣＩインスタンス（３１３）には、図２ＢのＣＩインスタンス（２０３）と比較して、属性「アクション・タイプ」及び属性「影響範囲」が追加されている。ＣＩインスタンス（３１３）の属性「アクション・タイプ」には、データ・モデル（３１１）で定義されたアクション・タイプのうちの少なくとも１つがインスタンス化されている。
本発明の実施形態では、図５の説明で述べるように、ステータス制御部がサービス・プロセスに対応するＣＩインスタンスをＣＭＤＢ内に動的に定義し、サービス・プロセスの対象先となるＣＩとの間に関係を定義するために、又はプロセス・エンジンがサービス・プロセスの対象先となるＣＩをポイントするパラメータをサービス・プロセス内に定義するために、図２Ｂで示されるディスカバリ・データが不要である。
【００６４】
図３Ｄ〜図３Ｈは、本発明の実施形態における、サービス構成要素に対応するアクションの対象範囲を特定するために使用されるポリシー（対象範囲特定ポリシー）の例を示す。
対象範囲特定ポリシーの条件例を以下に示す。
１．ＯＳ、次にミドルウェア、次にアプリケーションという垂直の依存関係を有する対象範囲特定ポリシーの例
・対象範囲特定ポリシーＡ：構成要素間が、「InstalledOn」の関係にあるもの
・対象範囲特定ポリシーＢ：対象範囲特定ポリシーＡ、且つ、対象である構成要素から１ノード（１段分）までのもの
２．ビジネス・アプリケーションを構成する複数のサーバ上の構成要素についての対象範囲特定ポリシーの例
・対象範囲特定ポリシーＣ：双方向の構成要素間で「UsedBy」の関連にあるもの
・対象範囲特定ポリシーＤ：対象範囲特定ポリシーＣの結果に対して、対象範囲特定ポリシーＡを適用したもの
３．その他
・任意の関係を有する構成要素のうち、ＣＩのタイプ属性が「ミドルウェア」のもの
【００６５】
条件の記述形式及び指定できる内容は、適切な実装方法により実現されうる。例えば、条件は、ＸＭＬ言語を用いて記述されうる。指定できる内容は例えば、属性及び関係を含む。
以下に、上記対象範囲特定ポリシーＡ乃至Ｄを用いて、構成要素と関係のある構成要素を抽出する例を示す。
【００６６】
図３Ｄは、本発明の実施態様である、対象範囲特定ポリシーを説明するために使用する、構成要素及び構成要素間の関係を示す。なお、図３Ｄでは、便宜的にソフトウェア構成要素を例としているが、該ソフトウェア構成要素をサービス構成要素又はハードウェア構成要素に置き換えることによって、同様に対象範囲特定ポリシーを説明することが可能である。
ＯＳ（オペレーティング・システム） Ａは、ＲＤＢＭＳ（リレーショナルデータベース管理システム）と「InstalledOn」の関係にある。ＲＤＢＭＳは、データベースと「InstalledOn」の関係にある。
ＯＳ Ｂは、Ａｐｐ（アプリケーション）サーバと「InstalledOn」の関係にある。Ａｐｐサーバは、Ｗｅｂアプリと「InstalledOn」の関係にある。
データベースは、Ｗｅｂアプリとお互いに「usedBy」の関係にある。
【００６７】
図３Ｅは、本発明の実施態様である、対象範囲特定ポリシーＡを用いた例を示す。
ＣＩとしてデータベースを指定し、且つ、対象範囲特定ポリシーＡを指定すると、「InstalledOn」の関係にあるＣＩがアクションの対象範囲である構成要素として特定される。結果として、データベース、ＲＤＢＭＳ及びＯＳのソフトウェア構成要素が特定される。
【００６８】
図３Ｆは、本発明の実施態様である、対象範囲特定ポリシーＢを用いた例を示す。
ＣＩとしてＷｅｂアプリを指定し、且つ、対象範囲特定ポリシーＢを指定すると、「InstalledOn」の関係にあるＣＩのうち、最初の１ノード分がアクションの対象範囲である構成要素として特定される。結果として、Ｗｅｂアプリ及びＡｐｐサーバのソフトウェア構成要素が特定される。
【００６９】
図３Ｇは、本発明の実施態様である、対象範囲特定ポリシーＣを用いた例を示す。ＣＩとしてデータベースを指定し、且つ、対象範囲特定ポリシーＣを指定すると、「usedBy」にある関係を双方向で有するソフトウェア構成要素が特定される。結果として、データベース及びＷｅｂアプリのソフトウェア構成要素が特定される。
【００７０】
図３Ｈは、本発明の実施態様である、対象範囲特定ポリシーＤを用いた例を示す。ＣＩとして、データベースを指定し、且つ、対象範囲特定ポリシーＤを指定すると、データベースとＷｅｂアプリがアクションの対象範囲である構成要素として特定され、さらにそれら対象範囲に「InstalledOn」の関係にあるＣＩがアクションの対象範囲である構成要素として特定される。結果として、データベース、ＲＤＢＭＳ、ＯＳ Ａ並びにＷｅｂアプリ、Ａｐｐサーバ及びＯＳ Ｂのソフトウェア構成要素が特定される。
【００７１】
図４は、従来のサービス・プロセス処理の例を示す。
サービス・プロセスＡは、サービス・プロセスＡへのリクエストを処理するためのプロセスである。サービス・プロセスＢは、サービス・プロセスＢへのリクエストを処理するためのプロセスである。ここで、サービス・プロセスＡ及びサービス・プロセスＢは、同じＣＩを参照するサービス・プロセスであるとする。
従来のサービス・プロセスの処理では、サービス・プロセスそれぞれの管理者が、サービス・プロセスＡ及びサービス・プロセスＢを定義し、そして定義したサービス・プロセスを記憶装置に格納する。
サービス・プロセスＡを実行するにあたり、サービス・プロセスＡの管理者は、サービス・プロセスＡへのリクエストを発行する。プロセス・エンジンは、該リクエストが到着（ステップ４０１）すると、上記記憶装置からサービス・プロセスＡを読み出し、サービス・プロセスＡを実行（ステップ４０２）する。サービス・プロセスＡの実行後、ディスカバリは、構成要素についての情報を取得する。属性及び関係更新部（図１Ａ、１０４）は、該取得したＣＩの情報に基づいて、ＣＭＤＢ内のＣＩインスタンスの属性値又は関係値を更新する（ステップ４０３）。
上記従来のサービス・プロセスの処理において、サービス・プロセスＡの実行中に、サービス・プロセスＢの管理者が、サービス・プロセスＡで参照するＣＩと同じＣＩを参照するサービス・プロセスＢへのリクエストを発行する場合に、次のような問題が生じるおそれがある。サービス・プロセスＢの管理者が、サービス・プロセスＡの存在に気付いた場合、サービス・プロセスＢの管理者は、それぞれのサービス・プロセスの内容によっては待機する必要がない場合であっても、サービス・プロセスの競合を回避するために、サービス・プロセスＡの実行が完了し、ＣＩ情報が更新されるまで、サービス・プロセスＢへのリクエストの発行を待機しなければならない。或いは、サービス・プロセスＢの管理者が、サービス・プロセスＡの存在に気付かない場合、サービス・プロセスＢがサービス・プロセスＡと同時に実行され、その結果としてサービス・プロセスＡ及びサービス・プロセスＢ間で競合が発生し、サービス・プロセスＡ、Ｂの両方、又はそのいずれかが失敗する可能性がある。
【００７２】
図５は、本発明の実施形態における、サービス構成要素に対応するアクションの実行管理の概略を示す。
サービス・プロセスＡ（５０１）のシステムの管理者又は管理者は、サービス・プロセスＡ（５０１）に対応するアクションの対象であるＣＩ（以下、サービス・プロセスＡの対象ＣＩ）に対するアクション・タイプ及び影響範囲を表す対象ＣＩ属性（５０７）を定義する。同様に、サービス・プロセスＢ（５０２）のシステムの管理者又は管理者は、サービス・プロセスＢ（５０２）に対応するアクションの対象であるＣＩ（以下、サービス・プロセスＢの対象ＣＩ）に対するアクション・タイプ及び影響範囲を表す対象ＣＩ属性（５０７）を定義する。
上記定義はそれぞれ、データ・モデル（図３Ｃ、３１１）の属性「アクション・タイプ」及び属性「影響範囲」に定義された情報を使用して、インスタンス化されうる。インスタンス化されたＣＩインスタンスは、図３Ｃに示されている（３１３）。代替的に、該定義は、上記データ・モデル（図３Ｃ、３１１）とは別途にサービス・プロセスの管理者によって定義され、記憶媒体、例えばＣＭＤＢ内に格納されていてもよい。
該対象ＣＩ属性（５０７）は、対象ＣＩへのアクション・タイプ及び対象ＣＩの影響範囲を含む。「アクション・タイプ」は例えば、新規、変更、削除、参照及び検索である。「影響範囲」は例えば、モデル名に指定されたＣＩからの距離を示すレベル、ＣＩインスタンスのモデル名、関係である。
対象ＣＩ属性（５０７）の実装例は、下記の通りである。
１．ステータス制御部（５０３）が、サービス・プロセスＡ及びＢ（５０１、５０２）に対応するＣＩインスタンス（５０５Ａ及び５０５Ｂ）を例えばＣＭＤＢ内に動的に定義する。そして、サービス・プロセスＡ（５０１）と該サービス・プロセスＡ（５０１）の対象ＣＩとの間に関係（５０６Ａ）を定義する。同様に、サービス・プロセスＢ（５０２）と該サービス・プロセスＢ（５０２）の対象ＣＩとの間に関係（５０６Ｂ）を定義する。代替的に、サービス・プロセスのシステム管理者又は管理者は、サービス・プロセスＡ又はＢ（５０１、５０２）の対象ＣＩをポイントするパラメータをサービス・プロセス（５０１、５０２）内にそれぞれ定義してもよい。
ステータス制御部（５０３）は、サービス・プロセス（５０１、５０２）間の依存関係の管理を行えるように、実行中の全サービス・プロセスの対象ＣＩ属性を管理する。
以下では、先行サービス・プロセスＡ（５０１）の実行中に、後発のサービス・プロセスＢ（５０２）へのリクエストが発生した場合を例に説明する。
サービス・プロセスＡ（５０１）及びサービス・プロセスＢ（５０２）は、ＣＭＤＢに定義されたそれぞれの対象ＣＩ属性（５０７）を有する。また、プロセス・エンジン（図示せず）は、サービス・プロセスＡ（５０１）の開始時に該サービス・プロセスＡ（５０１）についての対象ＣＩ属性（５０７）をステータス制御部（５０３）に提供している。サービスＢへのリクエストを受け、プロセス・エンジン（図示せず）は、後発サービス・プロセスＢ（５０２）の開始時に対象ＣＩ属性（５０７）をステータス制御部（５０３）に提供し、ステータス制御部（５０３）を介して、サービス・プロセスＡ（５０１）の対象ＣＩ属性（５０７）を参照する。
ステータス制御部（５０３）は、上記実行されたサービス・プロセスＢ（５０２）及びサービス・プロセスＡ（５０１）の対象ＣＩ属性（５０７）から、該実行されたサービス・プロセスＢ（５０２）の実行可否を判定する。該判定は、ステータス制御部（５０３）に定められた可否判定ポリシー（５１０）を利用して行われうる。可否判定ポリシーとは、複数のサービスによって共通する構成要素が利用される場合の動作ルールを定義したデータである。
また、上記判定はまた、プロセス・エンジン（図示せず）によって実行されたサービス・プロセスＢ（５０２）の管理者によって判定されてもよい。サービス・プロセスＢ（５０２）の管理者は、管理装置の表示装置上に表示されたサービス・プロセスＢ（５０２）のアクションの実行可否の選択を許すインタフェースを介して、アクションを実行させるか又はアクションを待機させるかを判断する。
ディスカバリ部（５０８）は、サービス・プロセスＡ及びＢ（５０１、５０２）の実行後にＣＩの情報を取得する。次に、属性及び関係更新部（図１Ａ、１０４）は、該取得したＣＩの情報に基づいて、ＣＩインスタンスの属性値又は関係値を更新する。
【００７３】
上記可否判定ポリシーの記述例を以下に示す。
１．process1(change) and process2(ANY) --> wait
（先行プロセス（変更）→後発プロセス（ＡＮＹ）を待機）
該例は、先行プロセス１のアクション・タイプが「変更」であるならば、後発プロセス２のアクション・タイプが何であっても、後発プロセス２は待機する、というポリシーである。
２．process1(ANY) and process2(delete、change) --> wait
（先行プロセス（ＡＮＹ）→後発プロセス（削除、変更）を待機）
該例は、先行プロセス１のアクション・タイプが何であっても、後発プロセス２のアクション・タイプが「削除」又は「変更」であるならば、後発プロセス２は待機する、というポリシーである。
３．process1(change、delete) and process2(ANY) --> wait
（先行プロセス（変更、削除）→後発プロセス（ＡＮＹ）を待機）
該例は、先行プロセス１のアクション・タイプが「変更」又は「削除」であるならば、後発プロセス２のアクション・タイプが何であっても、後発プロセス２は待機する、というポリシーである。
４．process1(ANY) and process2(delete) --> wait
（先行プロセス（ＡＮＹ）→後発プロセス（削除）を待機）
該例は、先行プロセス１のアクション・タイプが何であっても、後発プロセス２のアクション・タイプが「削除」であるならば、後発プロセス２は待機する、というポリシーである。
５．process1(search、refer) and process2(search、refer) --> go
（先行プロセス（検索、参照）→後発プロセス（検索、参照）を実行）
該例は、先行プロセス１のアクション・タイプが「検索」又は「参照」であり、後発プロセス２のアクション・タイプが「検索」又は「参照」であるならば、後発プロセス２は実行可能である、というポリシーである。先行及び後発の両プロセスのアクション・タイプが「検索」又は「参照」の場合、実行順番が入れ替わっても不整合は生じないので、後発プロセスが実行可能であると判定される。
６．process1(search、refer) and process2(change) --> wait
（先行プロセス（検索、参照）→後発プロセス（変更）を待機）
該例は、先行プロセス１のアクション・タイプが「検索」又は「参照」であっても、後発プロセス２のアクション・タイプが「変更」であるならば、後発プロセス２は待機する、というポリシーである。先行プロセスのアクション・タイプが「検索」又は「参照」の場合、後発プロセスで先に変更をおこなうと不整合が生じる可能性があるので、後発プロセスは待機であると判定される。
先行プロセスが複数ある場合、先行プロセスが完了する毎に判定が実行される。そして、適用される可否判定ポリシー全てによって後発プロセスが実行可能であると判定される場合のみ、後発プロセスが実行可能であると判定され、適用される可否判定ポリシーの少なくとも１つによって後発プロセスが待機させると判定される場合、後発プロセスは待機すると判定される。
【００７４】
図６は、本発明の実施形態における、サービス・プロセスの実行可否を決定する流れを示す。
以下では、先行サービス・プロセスＡ（６０２）の実行中に、後発のサービス・プロセスＢ（６０４）へのリクエストが発生した場合を例に説明する。
サービス・プロセスＡ及びＢ（６０２、６０４）それぞれの対象ＣＩ属性（６０１、６０３）は、サービス・プロセスＡ及びＢ（６０２、６０４）の開始時に、ステータス制御部（６０５）に提供される。サービス・プロセス（６０２、６０４）の実行可否は、ステータス制御部（６０５）又はサービス・プロセスＡ及びＢ（６０２、６０４）の各管理者が決定しうる。サービス・プロセスＡ及びＢ（６０２、６０４）の完了順が逆転した場合であっても、対象ＣＩ（６０７）の更新情報を一意に保てる場合、ステータス制御部（６０５）又はサービス・プロセスＡ及びＢ（６０２、６０４）の各管理者は、新規リクエストのサービス・プロセス（６０２、６０４）を実行可能と判定してもよい。
以下に、ステータス制御部が実行可否を判定する場合とサービス・プロセスの管理者側で実行可否を判定する場合について説明する。
Ａ．ステータス制御部が実行可否を判定する場合
ステータス制御部（６０５）は、先行サービス・プロセスＡ（６０２）の対象ＣＩ属性（６０１）に含まれる対象ＣＩの影響範囲に定義された対象ＣＩ（ＣＩ１、ＣＩ２及びＣＩ３）と、後発サービス・プロセスＢ（６０４）の対象ＣＩ属性（６０３）に含まれる対象ＣＩの影響範囲に定義された対象ＣＩ（ＣＩ３、ＣＩ４及びＣＩ６）とが重なっていない場合、後発サービス・プロセスＢ（６０４）は実行可能であると判定する。ステータス制御部（６０５）は、上記影響範囲に定義された対象ＣＩが重なっている場合、ステータス制御部（６０５）に定義された可否判定ポリシー（６０６）を使用して、後発サービス・プロセスＢ（６０４）の実行可否を判定する。可否判定ポリシー（６０６）は例えば、管理者によってステータス制御部（６０５）内に定義されうる。ステータス制御部（６０５）が、可否判定ポリシー（６０６）を使用して、後発サービス・プロセスＢ（６０４）の動作を決定する例は、以下の通りである。
１．process1(change) and process2(ANY) --> wait
（先行プロセス（変更）→後発プロセス（ＡＮＹ）を待機）
該例は、先行サービス・プロセスＡ（６０２）のアクション・タイプが「変更」であるならば、後発サービス・プロセスＢ（６０４）のアクション・タイプが何であっても、後発サービス・プロセスＢ（６０４）は待機する、というポリシーである。ステータス制御部（６０５）は、先行サービス・プロセスＡ（６０２）のアクション・タイプが「変更」である場合、後発サービス・プロセスＢ（６０４）を待機させる。
２．process1(ANY) and process2(delete、change) --> wait
（先行プロセス（ＡＮＹ）→後発プロセス（削除、変更）を待機）
該例は、先行サービス・プロセスＡ（６０２）のアクション・タイプが何であっても、後発サービス・プロセスＢ（６０４）のアクション・タイプが「削除」又は「変更」であるならば、後発サービス・プロセスＢ（６０４）は待機する、というポリシーである。ステータス制御部（６０５）は、後発サービス・プロセスＢ（６０４）のアクション・タイプが「削除」又は「変更」である場合、後発サービス・プロセスＢ（６０４）を待機させる。
３．process1(change、delete) and process2(ANY) --> wait
（先行プロセス（変更、削除）→後発プロセス（ＡＮＹ）を待機）
該例は、先行プロセス１のアクション・タイプが「変更」又は「削除」であるならば、後発プロセス２のアクション・タイプが何であっても、後発プロセス２は待機する、というポリシーである。ステータス制御部（６０５）は、後発サービス・プロセスＢ（６０４）のアクション・タイプが何であっても、後発サービス・プロセスＢ（６０４）を待機させる。
４．process1(ANY) and process2(delete) --> wait
（先行プロセス（ＡＮＹ）→後発プロセス（削除）を待機）
該例は、先行サービス・プロセスＡ（６０２）のアクション・タイプが何であっても、後発サービス・プロセスＢ（６０４）のアクション・タイプが「削除」であるならば、後発サービス・プロセスＢ（６０４）は待機する、というポリシーである。ステータス制御部（６０５）は、後発サービス・プロセスＢ（６０４）のアクション・タイプが「削除」である場合、後発サービス・プロセスＢ（６０４）を待機させる。
５．process1(search、refer) and process2(search、refer) --> go
（先行プロセス（検索、参照）→後発プロセス（検索、参照）を実行）
該例は、先行サービス・プロセスＡ（６０２）のアクション・タイプが「検索」又は「参照」であり、後発サービス・プロセスＢ（６０４）のアクション・タイプが「検索」又は「参照」であるならば、後発サービス・プロセスＢ（６０４）は実行可能である、というポリシーである。先行及び後発の両プロセスのアクション・タイプが「検索」又は「参照」の場合、実行順番が入れ替わっても不整合は生じないので、ステータス制御部（６０５）は、後発プロセスが実行可能であると判定する。
６．process1(search、refer) and process2(change) --> wait
（先行プロセス（検索、参照）→後発プロセス（変更）を待機）
該例は、先行サービス・プロセスＡ（６０２）のアクション・タイプが「検索」又は「参照」であっても、後発サービス・プロセスＢ（６０４）のアクション・タイプが「変更」であるならば、後発サービス・プロセスＢ（６０４）は待機する、というポリシーである。先行サービス・プロセスＡ（６０２）のアクション・タイプが「検索」又は「参照」の場合、後発サービス・プロセスＢ（６０４）で先に変更をおこなうと不整合が生じる可能性があるので、ステータス制御部（６０５）は、後発サービス・プロセスＢ（６０４）が待機であると判定する。
Ｂ．サービス・プロセス（６０２、６０４）の各管理者側が実行可否を判定する場合
ステータス制御部（６０５）の代わりに、サービス・プロセスＡ及びＢ（６０２、６０４）の各管理者がそれぞれ実行可否を判定する。該決定は例えば、プロセス・エンジンが、サービス・プロセスＡの管理者に対してサービス・プロセスＡ（６０２）の実行又は待機を指定することを許すポップアップウィンドウを表示し、該管理者から実行又は待機の入力を行わせることによって行う。同様に、プロセス・エンジンが、サービス・プロセスＢの管理者に対してサービス・プロセスＢ（６０４）の実行又は待機を指定することを許すポップアップウィンドウを表示し、該管理者から実行又は待機の入力を行わせることによって行う。サービス・プロセスＡ及びＢ（６０２、６０４）の各管理者側が実行可否を判定する例は、以下の通りである。
・先行プロセス（削除）→後発プロセス（ＡＮＹ）の実行必要性を判定する。
上記例は、先行サービス・プロセスＡ（６０２）のアクション・タイプが「削除」ならば、後発サービス・プロセスＢ（６０４）のアクション・タイプが何であっても、後発サービス・プロセスＢ（６０４）は実行必要性の判定を求める、という意味である。
・先行プロセス（新規）→後発プロセス（検索）で新規ＣＩを検索対象に含めるか判定する。
上記例は、先行サービス・プロセスＡ（６０２）のアクション・タイプが「新規」であり、後発サービス・プロセスＢ（６０４）のアクション・タイプが「検索」の場合、後発のサービス・プロセス（６０４）は新規ＣＩを検索対象に含めるかの判定を求める、という意味である。
なお、図６の例では、影響範囲をＣＩインスタンスのモデル名としたが、該影響範囲は、例えばノードとの距離を示すレベル又は関係を用いた式を使用して表してもよい。該影響範囲はまた、サービス構成要素に対応するアクションの対象範囲を特定するために使用されるポリシー（対象範囲特定ポリシー）によって動的に決定されうる。
影響範囲として、ノードとの距離を示すレベルを用いる場合において、先行のサービス・プロセス（６０２）の対象ＣＩ属性（６０１）に含まれる対象ＣＩの影響範囲に定義されたレベル以内の構成要素であるＣＩと、後発のサービス・プロセス（６０４）の対象ＣＩ属性（６０３）に含まれる対象ＣＩの影響範囲に定義されたレベル以内の構成要素が重なっていない場合、ステータス制御部（６０５）は、後発のサービス・プロセス（６０４）は実行可能であると判定する。上記影響範囲が重なっている場合、ステータス制御部（６０５）は、ステータス制御部（６０５）に定義された可否判定ポリシー（６０６）を使用して、後発のサービス・プロセス（６０４）の動作を判定する。
影響範囲として、関係を用いた式を用いる場合において、先行のサービス・プロセス（６０２）の対象ＣＩ属性（６０１）に含まれる対象ＣＩの影響範囲に定義された関係を用いた式から求められるＣＩと、後発のサービス・プロセス（６０４）の対象ＣＩ属性（６０３）に含まれる対象ＣＩの影響範囲に定義された関係を用いた式から求められるＣＩとが重なっていない場合は、ステータス制御部（６０５）は、後発のサービス・プロセス（６０４）は実行可能であると判定する。上記影響範囲が重なっている場合、ステータス制御部（６０５）は、ステータス制御部（６０５）に定義された可否判定ポリシー（６０６）を使用して、後発のサービス・プロセス（６０４）の動作を決定する。
【００７５】
図７Ａ〜図７Ｃは、本発明の実施形態における、サービス構成要素に対応するアクションの処理の流れを示す。
サービス構成要素に対応するアクションとして、サービス・プロセスＡ（７０２）及び実行中の他のサービス・プロセスがあるとする。ステータス制御部（７０４）は、他のサービス・プロセスの対象ＣＩ属性を保持している。対象ＣＩ属性は、対象ＣＩ属性へのアクション・タイプ及び対象ＣＩの影響範囲である（図５、５０７を参照）。
サービス・プロセスＡ（７０２）の管理者は、サービス・プロセスＡへのリクエスト（７０１）を発行する。プロセス・エンジン（図示せず）は、該リクエスト（７０１）を受信すると（ステップ７１０）、サービス・プロセスＡ（７０２）を開始する。プロセス・エンジン（図示せず）は、サービスの開始時に、サービス・プロセスＡ（７０２）内の対象ＣＩ属性をステータス制御部（７０４）に提供する（ステップ７１１）。ステータス制御部（７０４）は、サービス・プロセスＡ（７０２）内の対象ＣＩ属性及び実行中の他のサービス・プロセスの対象ＣＩ属性からサービス・プロセスＡ（７０２）の実行可否を判定し、プロセス・エンジンに通知する（ステップ７１２Ａ）。あるいは、ステータス制御部（７０４）は、実行中の他のサービス・プロセスの対象ＣＩ属性をサービス・プロセスＡ（７０２）の管理者に提供し、サービス・プロセスＡの実行可否を該管理者に判定させる（ステップ７１２Ｂ）。
【００７６】
図７Ｂは、上記判定において、サービス・プロセスＡ（７０２）が実行可能である場合を示す。
ステータス制御部（７０４）が、サービス・プロセスＡ（７０２）内のＣＩ（７０３）と該サービス・プロセスＡ（７０２）の対象ＣＩ（７０５）との間に関係（７０６）を作成する（ステップ７１３）。プロセス・エンジン（図示せず）が、サービス・プロセスＡ（７０２）を実行する（ステップ７１４）。上記サービス・プロセスＡ（７０２）の実行完了後、ステータス制御部（７０４）は、ディスカバリ部（７０７）に対して、ＣＩについての情報のディスカバリを要求する。ディスカバリの対象となるＣＩは、ディスカバリ部（７０７）の管理対象である全てのＣＩ、又は、実行を完了したサービス・プロセスＡに対応するアクションの対象であるＣＩ、又は、実行を完了したサービス・プロセスＡに対応するアクションの対象であるＣＩと他のサービス・プロセスに対応するアクションの対象であるＣＩとの重複範囲に含まれるＣＩである。後者ほど、ディスカバリに要する時間が少なくてすむ。上記要求を受けディスカバリ部（７０７）は、ＣＩの情報を取得する。属性及び関係更新部（図１Ａ、１０４）は、該取得したＣＩの情報に基づいて、ＣＩインスタンスの属性値又は関係値を更新する（ステップ７１５）。
該更新の完了は、ステータス制御部（７０４）に通知される。ここで、属性及び関係更新部（図１Ａ、１０４）は、サービス・プロセスＡ（７０２）内のＣＩ（７０３）と関係のある対象ＣＩ（７０５）の情報の更新及び更新完了の通知を優先して行い、サービス・プロセスＡ（７０２）内のＣＩ（７０３）と関係のない対象ＣＩ（７０５）の情報の更新及び更新完了の通知を、後述のステップ７１６以降に行ってもよい。ステータス制御部（７０４）がサービス・プロセスＡ（７０２）内のＣＩ（７０３）と対象ＣＩ（７０５）との間の関係（７０６）を削除する（ステップ７１６）。
ここで、さらに待ち状態のサービス・プロセス（７０８）があるとする。ステータス制御部（７０４）が、待ち状態のサービス・プロセス（７０８）の実行可否を判定していた場合、ステータス制御部（７０４）は、実行可否の再判定を行い、プロセス・エンジンに通知する。ステータス制御部（７０４）が、待ち状態のサービス・プロセス（７０８）の管理者に実行可否を判定させていた場合、待ち状態のサービス・プロセスに対応するアクションの実行可否の再判定を可能にするために、サービス・プロセスＡ（７０２）の終了をプロセス・エンジンに通知する（ステップ７１７）。該通知により、待ち状態のサービスプロセス（７０８）の管理者は、サービス・プロセスＡ（７０２）の終了を知ることができる。さらに、ステータス制御部（７０４）は、ＣＩ属性情報を待ち状態のサービス・プロセス（７０８）の管理者に提供する。
【００７７】
図７Ｃは、上記判定において、サービス・プロセスＡ（７０２）が待機である場合を示す。
先行の他のサービス・プロセスが終了すると、ステータス制御部（７０４）は、サービス・プロセスＡ（７０２）の管理者に実行可否を判定させていた場合、先行の他のサービス・プロセスの終了をプロセス・エンジン（図示せず）に通知する（ステップ７２０）。該通知により、サービス・プロセスＡ（７０２）の管理者は、他のサービス・プロセスの終了を知ることができる。ステータス制御部（７０４）は、該他のサービス・プロセスについての更新された対象ＣＩ属性を用いてサービス・プロセスＡ（７０２）の実行可否を再度判定する。ここで、サービス・プロセスＡ（７０２）以外にも待機しているサービス・プロセスがある場合、ステータス制御部（７０４）は、待機時間の長いサービス・プロセスの順に判定を行う（ステップ７２１）。代替的に、ステータス制御部（７０４）は、対象ＣＩ属性をサービス・プロセスＡ（７０２）の管理者に提供し、プロセス・エンジンは、実行可否をサービス・プロセスＡ（７０２）の管理者に判定させうる。該判定において、サービス・プロセスＡ（７０２）が待機である場合、プロセス・エンジンは、サービス・プロセスＡ（７０２）を待機させる。ステータス制御部（７０４）は、他に実行中であるサービス・プロセスの完了を待つ（上記図７Ｂの説明を参照されたい）。該判定において、サービス・プロセスＡ（７０２）が実行可能である場合、ステータス制御部（７０４）が、サービス・プロセスＡ（７０２）内のＣＩ（７０３）と該サービス・プロセスＡ（７０２）の対象ＣＩ（７０５）との間に関係（７０６）を作成する（ステップ７２２）。プロセス・エンジンが、サービス・プロセスＡ（７０２）を実行する（ステップ７２３）。上記サービス・プロセスＡ（７０２）の実行完了後、ステータス制御部（７０４）は、ディスカバリ部（７０７）に対してＣＩについての情報のディスカバリを要求する。ディスカバリの対象となるＣＩは、上記図７Ｂの説明で述べたとおりである。上記要求を受けディスカバリ部（７０７）は、ＣＩの情報を取得する（ステップ７２４）。属性及び関係更新部（図１Ａ、１０４）は、該取得したＣＩの情報に基づいて、ＣＩインスタンスの属性値又は関係値を更新する（ステップ７２４）。
該更新の完了はステータス制御部（７０４）に通知される。ここで、属性及び関係更新部（図１Ａ、１０４）は、サービス・プロセスＡ（７０２）内のＣＩ（７０３）と関係のある対象ＣＩ（７０５）の情報の更新及び更新完了の通知を優先して行い、サービス・プロセスＡ（７０２）内のＣＩ（７０３）と関係のない対象ＣＩ（７０５）の情報の更新及び更新完了の通知を、後述のステップ７２５以降に行ってもよい。さらに属性及び関係更新部（図１Ａ、１０４）は、サービス・プロセスＡ（７０２）内のＣＩ（７０３）と関係のある対象ＣＩ（７０５）のうち、待ち状態の他のサービス・プロセス（７０８）の影響範囲にも含まれるＣＩの情報の更新及び更新完了の通知を優先して行い、他のＣＩの情報の更新及び更新完了の通知を後述のステップ７２５以降に行ってもよい。サービス・プロセスＡ（７０２）内のＣＩ（７０３）と関係のある対象ＣＩ（７０５）のうち、待ち状態の他のサービス・プロセス（７０８）の影響範囲にも含まれるＣＩの情報は、ステータス制御部（７０４）によって上記要求に設定され、ディスカバリ部（７０７）は、該要求から該影響範囲のＣＩについての情報を取得する。ステータス制御部（７０４）がサービス・プロセスＡ内のＣＩ（７０３）と対象ＣＩ（７０５）との間の関係を削除する（ステップ７２５）。ステータス制御部（７０４）が、待ち状態のサービス・プロセス（７０８）の実行可否を判定していた場合、ステータス制御部（７０４）は、実行可否の再判定を行い、プロセス・エンジンに通知する。待ち状態のサービス・プロセス（７０８）の管理者に実行可否を判定させていた場合、ステータス制御部（７０４）が、待ち状態のサービス・プロセスに対応するアクションの実行可否の再判定を可能にするために、サービス・プロセスＡ（７０２）の終了をプロセス・エンジンに通知する（ステップ７２６）。該通知によって、待ち状態のサービス・プロセス（７０８）の管理者は、サービス・プロセスＡ（７０２）の終了を知ることができる。さらにステータス制御部（７０４）は、ＣＩ属性情報を待ち状態のサービス・プロセス（７０８）の管理者に提供する。
【００７８】
図８は、本発明の実施形態における、ソフトウェアの変更・リリース管理への適用例を示す。
ハードウェア１（８１０）上で、オペレーティング・システムであるＯＳ１（８１１）が動作している。ＯＳ１（８１１）上で、リレーショナルデータベース管理システム（ＲＤＢＭＳ）（８１２）が動作している。リレーショナルデータベース管理システム（８１２）上で、データベース１（８１３）及びデータベース２（８１４）が動作している。ハードウェア２（８１５）上で、オペレーティング・システムであるＯＳ２（８１６）が動作している。ＯＳ２（８１６）上で、Ｊ２ＥＥ（８１７）が動作している。Ｊ２ＥＥ（８１７）は、Ｊａｖａ処理環境を提供するプログラム群である。Ｊ２ＥＥ（８１７）上で、アプリケーション１（８１８）及びアプリケーション２（８１９）が動作している。上記ハードウェア１（８１０）、ＯＳ１（８１１）、リレーショナルデータベース管理システム（８１２）、データベース１（８１３）、データベース２（８１４）、ハードウェア２（８１５）、ＯＳ２（８１６）、Ｊ２ＥＥ（８１７）、アプリケーション１（８１８）及びアプリケーション２（８１９）それぞれは、ＣＭＤＢ内において各ＣＩインスタンスとして格納されている。
ハードウェア１（８１０）を表すＣＩとＯＳ１（８１１）を表すＣＩの関係は、ｒｕｎｓＯｎである。これは、ハードウェア１（８１０）上でＯＳ１（８１１）が動作していることを表す。ＯＳ１（８１１）を表すＣＩとリレーショナルデータベース管理システム（８１２）を表すＣＩの関係は、ｒｕｎｓＯｎである。これは、ＯＳ１（８１１）上でリレーショナルデータベース管理システム（８１２）が動作していることを表す。リレーショナルデータベース管理システム（８１２）を表すＣＩとデータベース１（８１３）を表すＣＩの関係は、ｒｕｎｓＯｎである。これは、リレーショナルデータベース管理システム（８１２）上でデータベース１（８１３）が動作していることを表す。リレーショナルデータベース管理システム（８１２）を表すＣＩとデータベース２（８１４）を表すＣＩの関係は、ｒｕｎｓＯｎである。これは、リレーショナルデータベース管理システム（８１２）上でデータベース２（８１４）が動作していることを表す。ハードウェア２（８１５）を表すＣＩとＯＳ２（８１６）を表すＣＩの関係は、ｒｕｎｓＯｎである。これは、ハードウェア２（８１５）上でＯＳ２（８１６）が動作していることを表す。ＯＳ２（８１６）を表すＣＩとＪ２ＥＥ（８１７）を表すＣＩの関係は、ｒｕｎｓＯｎである。これは、ＯＳ２（８１６）上でＪ２ＥＥ（８１７）が動作していることを表す。Ｊ２ＥＥ（８１７）を表すＣＩとアプリケーション１（８１８）を表すＣＩの関係は、ｒｕｎｓＯｎである。これは、Ｊ２ＥＥ（８１７）上でアプリケーション１（８１８）が動作していることを表す。Ｊ２ＥＥ（８１７）を表すＣＩとアプリケーション２（８１８）を表すＣＩの関係は、ｒｕｎｓＯｎである。これは、Ｊ２ＥＥ（８１７）上でアプリケーション２（８１９）が動作していることを表す。アプリケーション１（８１８）とデータベース２（８１４）の関係は、useである。これは、アプリケーション１（８１８）がデータベース２（８１４）を使用していることを表す。
【００７９】
サービス・プロセスＡ（８０１）は、ＯＳ１（８１１）の修正を適用するプロセスである。ＣＭＤＢには、サービス・プロセスＡ（８０１）自体のＣＩが格納されている。サービス・プロセスＡ（８０１）のＣＩインスタンスに、対象ＣＩ属性（８０２）が定義されている。対象ＣＩ属性（８０２）は、アクション・タイプが「変更」であり、影響範囲は「"ＯＳ１上で動いているもの（ｒｕｎｓＯｎ)"ａｎｄ"該当ＯＳ上のＣＩを使用しているもの(ｕｓｅ)"」である。ここで、該当ＯＳは、ＯＳ１である。
サービス・プロセスＢ（８０３）は、Ｊ２ＥＥのパラメータを変更するプロセスである。ＣＭＤＢには、サービス・プロセスＢ（８０３）自体のＣＩが格納されている。サービス・プロセスＢ（８０３）のＣＩインスタンスに、対象ＣＩ属性（８０４）が定義されている。対象ＣＩ属性（８０４）は、アクション・タイプが「変更」であり、影響範囲は「"Ｊ２ＥＥ上で動いているもの(ｒｕｎｓＯｎ)"ａｎｄ"該当ＯＳ上のＣＩを使用しているもの(ｕｓｅ)"」である。ここで、該当ＯＳは、ＯＳ２である。
【００８０】
以下、ＯＳ１（８１１）への修正適用プロセスであるサービス・プロセスＡ（８０１）の実行中に、Ｊ２ＥＥのパラメータ変更プロセスであるサービス・プロセスＢ（８０３）を実行する場合を例に説明する。ここで、ステータス制御部（８０５）の有する可否判定ポリシーは、先行のサービス・プロセスのアクション・タイプが「変更」であり、後続のサービス・プロセスのアクション・タイプが「変更」ならば、後続のサービス・プロセスは待機する旨であるとする。
プロセス・エンジンは、サービス・プロセスＡ（８０１）の開始時に、サービス・プロセスＡ（８０１）においてＯＳ１（８１１）が修正適用の対象であることを、ステータス制御部（８０５）に通知する（ステップ８２０）。ステータス制御部（８０５）は、他のサービス・プロセスによりＯＳ１（８１１）及びＯＳ１（８１１）と関連するＣＩが使用されていないため、サービス・プロセスＡ（８０１）が実行可能であることをプロセス・エンジンに通知する（ステップ８２１）。
ステータス制御部（８０５）は、サービス・プロセスＡ（８０１）自体のＣＩとＯＳ１（８１１）を表すＣＩとの間に関係を作成する。さらに、ステータス制御部（８０５）は、サービス・プロセスＡ（８０１）自体のＣＩに定義された影響範囲に従って、影響範囲の及ぶＣＩとサービス・プロセス（８０１）Ａ自体のＣＩとの間に関係を作成する。本例では、影響範囲が「"ＯＳ１上で動いているもの（ｒｕｎｓＯｎ）"且つ"該当ＯＳ上のＣＩを使用しているもの（ｕｓｅ）"」であるので、サービス・プロセス（８０１）Ａ自体のＣＩは、ＯＳ１（８１１）上で動いているＲＤＢＭＳを表すＣＩ（８１２）、データベース１を表すＣＩ（８１３）及びデータベース２を表すＣＩ（８１４）、ＯＳ上のＣＩを使用しているアプリケーション１を表すＣＩ（８１８）と関係を作成する（ステップ８２２）。
プロセス・エンジンは、サービス・プロセスＢ（８０３）の開始時に、サービス・プロセスＢ（８０３）においてＪ２ＥＥがパラメータ変更の対象であることを、ステータス制御部（８０５）に通知する（ステップ８２３）。
ここで、サービス・プロセスＢ（８０５）の影響範囲の及ぶＣＩであるアプリケーション１を表すＣＩ（８１８）は、サービス・プロセスＡ（８０１）に使用されている。また、ステータス制御部（８０５）の有するポリシーに従うと、アクション・タイプが「変更」であるサービス・プロセスの対象となっているＣＩに対しては、同時に変更を行うことはできない。そこで、ステータス制御部（８０５）は、サービス・プロセスＢ（８０３）が実行不可能であることをプロセス・エンジンに通知する。ここで、ステータス制御部（８０５）は、サービス・プロセスＢ（８０３）の実行可否をサービス・プロセスＢ（８０３）の管理者に判定をさせることも可能である（ステップ８２４）。
サービス・プロセスＡ（８０１）が完了すると、ステータス制御部（８０５）は、ディスカバリ部（８０６）に環境内のＣＩについてディスカバリすることをリクエストし、環境内の該ＣＩについての情報を取得する。ここで、ステータス制御部（８０５）は、待機中のサービス・プロセスがあれば、サービス・プロセスＡ（８０１）自体のＣＩと関係のあるＣＩ（８１１、８１２、８１３、８１４、８１８）についての情報の取得を高い優先度で、さらには待機中のサービス・プロセスが待機する原因になっているアプリケーション１を表すＣＩ（８１８）についての情報の取得をより高い優先度でリクエストする（ステップ８２５）。
ディスカバリの完了に伴い、ステータス制御部（８０５）は、サービス・プロセスＡ（８０１）とＣＩ間の関係を削除する（ステップ８２６）。
ステータス制御部（８０５）は、プロセスが実行可能になったことをプロセス・エンジンに通知する（ステップ８２７）。
【００８１】
図９は、本発明の実施形態における、システムの処理のフローチャートを示す。
各サービス構成要素に対応するアクションの管理者は、プロセス・エンジンに対して、サービスを実行するためのリクエストを発行する（ステップ９０１）。
ステータス制御部は、上記リクエストを受け、アクション・タイプ及び影響範囲をＣＭＤＢから取得する。代替的には、プロセス・エンジンが、管理者に対してアクション・タイプ及び影響範囲の入力を要求し、該要求によって入力されたアクション・タイプ及び影響範囲をステータス制御部に渡す。ステータス制御部は、サービス・プロセスの管理者から入力されたアクション・タイプ及び影響範囲をプロセス・エンジンから取得する。ステータス制御部は、サービス構成要素と該サービスのアクションの対象になる構成要素との間に関係を作成する。さらに、ステータス制御部は、上記影響範囲に従って、サービス構成要素と影響範囲の及ぶ構成要素との間に関係を作成する（ステップ９０２）。
ステータス制御部は、上記取得した影響範囲と実行中のサービスに対応するアクション構成要素に設定された影響範囲の重なりを判定する。該判定の結果、影響範囲に重なりがあればステップ９０４に進み、重なりがなければステップ９０５に進む（ステップ９０３）。
ステータス制御部は、上記取得したアクション・タイプ及び影響範囲と、実行中のサービスに対応するアクション構成要素に設定されたアクション・タイプ及び影響範囲からサービスの実行可否を判定する。該判定には、ステータス制御部に定義された可否判定ポリシーを用いる。またステータス制御部は、実行中のサービスに対応するアクション構成要素に設定されたアクション・タイプ及び影響範囲をサービスの管理者に提供し、該判定をサービスの管理者に委ねることもできる。該判定の結果、サービスが実行可能である場合、ステップ９０５に進み、サービスが実行不可である場合、ステップ９０６に進む（ステップ９０４）。
影響範囲に重なりがない場合又はサービスが実行可能であると判定された場合、プロセス・エンジンは、サービスを実行する（ステップ９０５）。サービス実行に伴い、サービス構成要素と関連する構成要素が関係付けられる。
サービスが実行不可であると判定された場合、プロセス・エンジンは、サービスを待機させる（ステップ９０６）。該待機は、上記実行中のサービスが終了するまで行われる。上記実行中のサービスの終了後、ステータス制御部は、ステップ９０３を再度実行する。
サービス終了後、ステータス制御部は、ディスカバリ部に対してディスカバリの要求を行う（ステップ９０７）。ディスカバリ部は、該要求を受け、環境内又は要求されたＣＩの情報を取得する。次に、属性及び関係更新部が、該取得したＣＩの情報に基づいて、ＣＩインスタンスの属性値又は関係値を更新する。属性及び関係更新部は、該更新が完了すると完了をステータス制御部に通知する。
ステータス制御部は、該通知を受け、サービス構成要素と関連する構成要素の関係を解除する（ステップ９０８）。
ステータス制御部は、待機中のサービスがあればサービスが終了したことをプロセス・エンジンに通知する（ステップ９０９）。
【００８２】
図１０は、本発明の実施形態における、コンピュータ・システムの例を示す。
コンピュータ・システム（１０００）は、図１Ａで示されるコンピュータ・システム（１００）と同様に、ディスカバリ部（１００１）、ＣＩ同定部（１００２）、ＣＩインスタンス作成部（１００３）、属性及び関係更新部（１００４）及びＣＭＤＢ（１００５）を含む。コンピュータ・システム（１０００）はさらに、ディスカバリ・テーブル（１００６）、モデル・テーブル（１００７）及び関係テーブル（１００８）を含む。
ステータス制御部（１００９）は、関連付部（１０１１）、判定部（１０１２）、提示部（１０１３）を含む。
関連付部（１０１１）は、サービス構成要素を、該サービス構成要素に対応するアクションの対象である１又は複数の構成要素に関連付ける。
判定部（１０１２）は、第１のサービス構成要素に対応するアクションの実行中に第２のサービス構成要素に対応するアクションへのリクエストがあり且つ該第１のサービス構成要素に対応するアクションの対象である少なくとも１の構成要素が該第２のサービス構成要素に対応するアクションの対象である構成要素に含まれる場合、該第２のサービス構成要素に対応するアクションを実行することが許されるかどうかを判定する。該判定部（１０１２）はまた、サービス構成要素に対応するアクションを実行することが許されるかどうかを判定するためのルールを定義するポリシーによってサービス構成要素に対応するアクションを実行することが許されるかどうかを判定する。
提示部（１０１３）は、サービス構成要素に対応するアクションの実行可否をユーザに選択することを許すインタフェースを表示部に提示する。
プロセス・エンジン（１０１０）は、サービス・プロセス又はサービス・ステップの実行をする。プロセス・エンジン（１０１０）は、サービス・プロセスの対象先となるＣＩをポイントするパラメータをサービス・プロセス内に定義する。
ステータス制御部（１００９）及び／又はプロセス・エンジン（１０１０）は、コンピュータ・システム（１０００）内に含まれていてもよく、又はコンピュータ・システム（１０００）にケーブルを介して接続されたコンピュータ・システム（図示せず）内に含まれていてもよい。
【００８３】
上記実施形態のコンピュータ・システムにおいて使用されるコンピュータは、ＣＰＵとメイン・メモリと含み、これらはバスに接続されている。ＣＰＵは好ましくは、３２ビット又は６４ビットのアーキテクチャに基づくものであり、例えば、インテル社のＸｅｏｎ（商標）シリーズ、Ｃｏｒｅ（商標）シリーズ、Ｐｅｎｔｉｕｍ（商標）シリーズ、Ｃｅｌｅｒｏｎ（商標）シリーズ、ＡＭＤ社のＰｈｅｎｏｍ（商標）シリーズ、Ａｔｈｌｏｎ（商標）シリーズなどを使用することができる。バスには、ディスプレイ・コントローラを介して、ＬＣＤモニタなどのディスプレイが接続される。ディスプレイは、コンピュータ・システムの管理のために、通信回線を介してネットワークに接続されたコンピュータについての情報と、そのコンピュータ上で動作中のソフトウェアについての情報を、適当なグラフィック・インターフェースで表示するために使用される。バスにはまた、ＩＤＥ又はＳＡＴＡコントローラを介して、ハードディスク又はシリコン・ディスクと、ＣＤ−ＲＯＭ、ＤＶＤ又はＢｌｕ−ｒａｙドライブが接続される。
【００８４】
ハードディスクには、オペレーティング・システム、Ｊ２ＥＥなどのＪａｖａ処理環境を提供するプログラム、ＣＭＤＢのための運用管理プログラム、その他のプログラム及びデータが、メイン・メモリにロード可能に記憶されている。運用管理プログラムは好ましくは、インターナショナル・ビジネス・マシーンズ・コーポレーションから提供されるＴＡＤＤＭ（Tivoli（商標）Application Dependency Discovery Manager）を含む。
【００８５】
ＣＤ−ＲＯＭ、ＤＶＤ又はＢＤドライブは、必要に応じて、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ又はＢＤからプログラムをハードディスクに追加導入するために使用される。バスには更に、キーボード・マウスコントローラを介して、キーボード及びマウスが接続されている。
【００８６】
通信インタフェースは、例えばイーサネット（商標）・プロトコルに従うものであり、通信コントローラを介してバスに接続され、コンピュータ及び通信回線を物理的に接続する役割を担い、コンピュータのオペレーティング・システムの通信機能のＴＣＰ／ＩＰ通信プロトコルに対して、ネットワーク・インターフェース層を提供する。尚、通信回線は、有線ＬＡＮ環境、或いは例えばＩＥＥＥ８０２．１１ａ／ｂ／ｇ／ｎなどの無線ＬＡＮ接続規格に基づく無線ＬＡＮ環境であってもよい。
【００８７】
なお、コンピュータ等のハードウェアを接続するためのネットワーク接続装置として使用できるものとして、上記のネットワーク・スイッチ以外に、これで尽きている訳ではないが、ルータ、ハードウェア管理コンソール等がある。要するに、ネットワーク運用管理用プログラムが導入されているコンピュータからの、所定のコマンドによる問い合わせに対して、それに接続されているコンピュータのＩＰアドレス、ＭＡＣアドレスなどの構成情報を返すことができる機能をもつものである。ネットワーク・スイッチ及びルータは、アドレス解決プロトコル（ＡＲＰ）のための、それに接続されているコンピュータのＩＰアドレス及び、それに対応するＭＡＣアドレスの対のリストを含むＡＲＰテーブルを含み、所定のコマンドによる問い合わせに対して、ＡＲＰテーブルの内容を返す機能をもつ。ハードウェア管理コンソールは、ＡＲＰテーブルよりも更に詳しい、コンピュータの構成情報を返すことができる。
【００８８】
コンピュータには、上述したハードウェア管理コンソールが接続されている。これは、コンピュータで、ＬＰＡＲ（仮想論理区画）により一台のコンピュータを複数の区画に論理分割し、その各々の区画で、ＶＭｗａｒｅにより、Ｗｉｎｄｏｗｓ（商標）、Ｌｉｎｕｘ（商標）などの異なるＯＳを走らせるようにする機能を有するものである。ハードウェア管理コンソールにシステム的に問い合わせすることにより、ＬＰＡＲ・ＶＭｗａｒｅで動作しているコンピュータの個々の論理区画での情報を、詳細に得ることができる。
【００８９】
以上、実施形態に基づき本発明を説明してきたが、本実施形態に記載されている内容は、本発明の一例であり、当業者なら、本発明の技術的範囲を逸脱することなく、さまざまな変形例に想到できることが、明らかであろう。例えば、ＣＭＤＢとそれに格納されたＣＩではなく、別の形式のデータベースとＣＩの形式を用いることもできる。また、Ｊａｖａ以外に、Ｃ＋＋、Ｃ＃など、ネットワーク管理機能をもつＡＰＩを呼び出すことのできる任意のコンピュータ開発環境を用いることができる。
【図面の簡単な説明】
【００９０】
【図１Ａ】ＣＩを管理するための、ＣＭＤＢを含む従来のコンピュータ・システムの例を示す。
【図１Ｂ】構成管理のためのツールの概要を示す。
【図２Ａ】サービスＡ及びサービスＢの各ＣＩインスタンス、及びそれらサービスの関係インスタンスの作成を示す。
【図２Ｂ】データ・モデル、ディスカバリ・インスタンス、ＣＩインスタンス、及び関係モデルを示す。
【図３Ａ】本発明の実施形態におけるサービス構成要素の例を示す。
【図３Ｂ】本発明の実施形態における、サービス構成要素の組み合わせの例を示す。
【図３Ｃ】本発明の実施形態における、データ・モデル、ディスカバリ・インスタンス、ＣＩインスタンス、及び関係モデルを示す。
【図３Ｄ】本発明の実施態様である、対象範囲特定ポリシーを説明するために使用する、構成要素及び該構成要素間の関係を示す。
【図３Ｅ】本発明の実施態様である、対象範囲特定ポリシーＡを用いた例を示す。
【図３Ｆ】本発明の実施態様である、対象範囲特定ポリシーＢを用いた例を示す。
【図３Ｇ】本発明の実施態様である、対象範囲特定ポリシーＣを用いた例を示す。
【図３Ｈ】本発明の実施態様である、対象範囲特定ポリシーＤを用いた例を示す。
【図４】従来のサービス・プロセス処理の例を示す。
【図５】本発明の実施形態における、サービス構成要素に対応するアクションの実行管理の概略を示す。
【図６】本発明の実施形態における、サービス・プロセスの実行可否を決定する流れを示す。
【図７Ａ】本発明の実施形態における、サービス構成要素に対応するアクションの処理の流れ（１／３）を示す。
【図７Ｂ】本発明の実施形態における、サービス構成要素に対応するアクションの処理の流れ（２／３）を示す。
【図７Ｃ】本発明の実施形態における、サービス構成要素に対応するアクションの処理の流れ（３／３）を示す。
【図８】本発明の実施形態における、ソフトウェアの変更・リリース管理への適用例を示す。
【図９】本発明の実施形態における、システムの処理のフローチャートを示す。
【図１０】本発明の実施形態における、コンピュータ・システムの例を示す。
【特許請求の範囲】
【請求項１】
サービス構成要素に対応するアクションの実行を管理するためのコンピュータ・システムであって、
構成要素についての情報を検出するディスカバリ部と、
構成要素毎に、該構成要素の少なくとも１つの所定の属性及び該構成要素と他の構成要素との関係を示す１組のデータを保持するリポジトリと、
前記サービス構成要素を、該サービス構成要素に対応するアクションの対象である少なくとも１の構成要素に関連付ける関連付部と、
第１のサービス構成要素に対応するアクションの実行中に第２のサービス構成要素に対応するアクションへのリクエストがあり且つ該第２のサービス構成要素に対応するアクションの対象である少なくとも１の構成要素が該第１のサービス構成要素に対応するアクションの対象である構成要素に含まれる場合、該第２のサービス構成要素に対応するアクションを実行することが許されるかどうかを判定する判定部と
を含む、前記コンピュータ・システム。
【請求項２】
前記ディスカバリ部が、前記第１又は第２のサービス構成要素に対応するアクションの終了後に、構成要素についての情報を検出する、請求項１に記載のコンピュータ・システム。
【請求項３】
前記ディスカバリ部が、前記第１又は第２のサービス構成要素に対応するアクションの終了後に、該終了したサービス構成要素に対応するアクションの対象である構成要素についての情報を検出する、請求項２に記載のコンピュータ・システム。
【請求項４】
前記ディスカバリ部が、前記第１又は第２のサービス構成要素に対応するアクションの終了後に、前記第１のサービス構成要素に対応するアクションの対象である少なくとも１の構成要素と前記第２のサービス構成要素に対応するアクションの対象である構成要素との重複範囲に含まれる構成要素についての情報を検出する、請求項３に記載のコンピュータ・システム。
【請求項５】
前記サービス構成要素が、少なくとも１のサービス・プロセス又は該サービス・プロセスに含まれる少なくとも１のサービス・ステップである、請求項１に記載のコンピュータ・システム。
【請求項６】
前記判定部が、前記サービス構成要素に対応するアクションを実行することが許されるかどうかを判定するためのルールを定義するポリシーによって前記アクションを実行することが許されるかどうかを判定する、請求項１に記載のコンピュータ・システム。
【請求項７】
前記アクションを実行することが許されるかどうかを判定することをユーザに選択することを可能にするインタフェースを表示部に提示する提示部をさらに含む、請求項１に記載のコンピュータ・システム。
【請求項８】
前記判定部が、前記アクションを実行することが許される場合、前記第２のサービス構成要素に対応するアクションを実行させ、前記判定部が、前記アクションを実行することが許されない場合、前記第２のサービス構成要素に対応するアクションの実行を待機させる、請求項１に記載のコンピュータ・システム。
【請求項９】
前記第２のサービス構成要素に対応するアクションの実行が待機している場合、前記判定部が、前記第１のサービス構成要素に対応するアクションの終了に応じて、前記第２のサービス構成要素に対応するアクションを実行することが許されるかどうかをさらに判定する、請求項８に記載のコンピュータ・システム。
【請求項１０】
前記判定部が、前記第１のサービス構成要素に対応するアクションの対象である構成要素が前記第２のサービス構成要素に対応するアクションの対象である構成要素と重複しない場合、前記第２のサービス構成要素に対応するアクションを実行することを許す、請求項１に記載のコンピュータ・システム。
【請求項１１】
前記関連付けが、前記第１のサービス構成要素に対応するアクションの開始に応じて行われる、請求項１に記載のコンピュータ・システム。
【請求項１２】
前記関連付部が、前記第１のサービス構成要素に対応するアクションの終了に応じて、前記関連付けを解除する、請求項１１に記載のコンピュータ・システム。
【請求項１３】
所定の属性及び構成要素と他の構成要素との関係を定義するデータ・モデルが、サービス構成要素のアクション・タイプと該サービス構成要素に対応するアクションの対象である構成要素の範囲とを含む、請求項１に記載のコンピュータ・システム。
【請求項１４】
サービス構成要素に対応するアクションの実行を管理する方法であって、
構成要素についての情報を検出するステップと、
前記検出された情報に基づいて、構成要素毎に、該構成要素の少なくとも１つの所定の属性及び該構成要素と他の構成要素との関係を示す１組のデータを作成し、該１組のデータをリポジトリに格納するステップと、
前記サービス構成要素を、該サービス構成要素に対応するアクションの対象である少なくとも１の構成要素に関連付けるステップと、
第１のサービス構成要素に対応するアクションの実行中に第２のサービス構成要素に対応するアクションへのリクエストがあり且つ該第２のサービス構成要素に対応するアクションの対象である少なくとも１の構成要素が該第１のサービス構成要素に対応するアクションの対象である構成要素に含まれる場合、該第２のサービス構成要素に対応するアクションを実行することが許されるかどうかを判定するステップと
を含む、前記方法。
【請求項１５】
前記第１又は第２のサービス構成要素に対応するアクションの終了後に、構成要素についての情報を検出するステップをさらに含む、請求項１４に記載の方法。
【請求項１６】
前記第１又は第２のサービス構成要素に対応するアクションの終了後に、該終了したサービス構成要素に対応するアクションの対象である構成要素についての情報を検出するステップをさらに含む、請求項１５に記載の方法。
【請求項１７】
前記第１又は第２のサービス構成要素に対応するアクションの終了後に、前記第１のサービス構成要素に対応するアクションの対象である少なくとも１の構成要素と前記第２のサービス構成要素に対応するアクションの対象である構成要素との重複範囲に含まれる構成要素についての情報を検出するステップをさらに含む、請求項１６に記載の方法。
【請求項１８】
前記判定するステップが、前記サービス構成要素に対応するアクションを実行することが許されるかどうかを判定するためのルールを定義するポリシーによって前記アクションを実行することが許されるかどうかを判定するステップを含む、請求項１４に記載の方法。
【請求項１９】
前記アクションを実行することが許される場合、前記第２のサービス構成要素に対応するアクションを実行すること許すステップと、
前記アクションを実行することが許されない場合、前記第２のサービス構成要素に対応するアクションの実行を待機させるステップと
をさらに含む、請求項１４に記載の方法。
【請求項２０】
前記第１のサービス構成要素に対応するアクションの対象である構成要素が前記第２のサービス構成要素に対応するアクションの対象である構成要素と重複しない場合、前記第２のサービス構成要素に対応するアクションを実行することを許すステップをさらに含む、請求項１４に記載の方法。
【請求項２１】
前記関連付けるステップが、前記第１のサービス構成要素に対応するアクションの開始に応じて行われる、請求項１４に記載の方法。
【請求項２２】
前記第１のサービス構成要素に対応するアクションの終了に応じて、前記関連付けを解除するステップをさらに含む、請求項２１に記載の方法。
【請求項２３】
前記第２のサービス構成要素に対応するアクションの実行が待機している場合、前記第１のサービス構成要素に対応するアクションの終了に応じて、前記第２のサービス構成要素に対応するアクションを実行することが許されるかどうかをさらに判定するステップをさらに含む、請求項１４に記載の方法。
【請求項２４】
構成要素についての情報を検出するディスカバリ部と、構成要素毎に、該構成要素の少なくとも１つの所定の属性及び該構成要素と他の構成要素との関係を示す１組のデータを保持するリポジトリとを含むコンピュータ・システムにおいて、サービス構成要素に対応するアクションの実行を管理する方法であって、
前記サービス構成要素を、該サービス構成要素に対応するアクションの対象である少なくとも１の構成要素に関連付けるステップと、
第１のサービス構成要素に対応するアクションの実行中に第２のサービス構成要素に対応するアクションへのリクエストがあり且つ該第２のサービス構成要素に対応するアクションの対象である少なくとも１の構成要素が該第１のサービス構成要素に対応するアクションの対象である構成要素に含まれる場合、
該第２のサービス構成要素に対応するアクションを実行することが許されるかどうかを判定するステップと、
前記アクションを実行することが許される場合、前記第２のサービス構成要素に対応するアクションを実行させるステップと、
前記アクションを実行することが許されない場合、前記第２のサービス構成要素に対応するアクションの実行を待機させるステップと、
前記第１のサービス構成要素に対応するアクションの対象である構成要素が前記第２のサービス構成要素に対応するアクションの対象である構成要素と重複しない場合、前記第２のサービス構成要素に対応するアクションを実行することを許すステップと、
前記第１又は第２のサービス構成要素に対応するアクションの終了後に、構成要素についての情報を検出するステップと
を含む、前記方法。
【請求項２５】
サービス構成要素に対応するアクションの実行を管理するコンピュータ・プログラムであって、コンピュータ・システムに、請求項１４〜２４のいずれか一項に記載の方法の各ステップを実行させるコンピュータ・プログラム。
【請求項１】
サービス構成要素に対応するアクションの実行を管理するためのコンピュータ・システムであって、
構成要素についての情報を検出するディスカバリ部と、
構成要素毎に、該構成要素の少なくとも１つの所定の属性及び該構成要素と他の構成要素との関係を示す１組のデータを保持するリポジトリと、
前記サービス構成要素を、該サービス構成要素に対応するアクションの対象である少なくとも１の構成要素に関連付ける関連付部と、
第１のサービス構成要素に対応するアクションの実行中に第２のサービス構成要素に対応するアクションへのリクエストがあり且つ該第２のサービス構成要素に対応するアクションの対象である少なくとも１の構成要素が該第１のサービス構成要素に対応するアクションの対象である構成要素に含まれる場合、該第２のサービス構成要素に対応するアクションを実行することが許されるかどうかを判定する判定部と
を含む、前記コンピュータ・システム。
【請求項２】
前記ディスカバリ部が、前記第１又は第２のサービス構成要素に対応するアクションの終了後に、構成要素についての情報を検出する、請求項１に記載のコンピュータ・システム。
【請求項３】
前記ディスカバリ部が、前記第１又は第２のサービス構成要素に対応するアクションの終了後に、該終了したサービス構成要素に対応するアクションの対象である構成要素についての情報を検出する、請求項２に記載のコンピュータ・システム。
【請求項４】
前記ディスカバリ部が、前記第１又は第２のサービス構成要素に対応するアクションの終了後に、前記第１のサービス構成要素に対応するアクションの対象である少なくとも１の構成要素と前記第２のサービス構成要素に対応するアクションの対象である構成要素との重複範囲に含まれる構成要素についての情報を検出する、請求項３に記載のコンピュータ・システム。
【請求項５】
前記サービス構成要素が、少なくとも１のサービス・プロセス又は該サービス・プロセスに含まれる少なくとも１のサービス・ステップである、請求項１に記載のコンピュータ・システム。
【請求項６】
前記判定部が、前記サービス構成要素に対応するアクションを実行することが許されるかどうかを判定するためのルールを定義するポリシーによって前記アクションを実行することが許されるかどうかを判定する、請求項１に記載のコンピュータ・システム。
【請求項７】
前記アクションを実行することが許されるかどうかを判定することをユーザに選択することを可能にするインタフェースを表示部に提示する提示部をさらに含む、請求項１に記載のコンピュータ・システム。
【請求項８】
前記判定部が、前記アクションを実行することが許される場合、前記第２のサービス構成要素に対応するアクションを実行させ、前記判定部が、前記アクションを実行することが許されない場合、前記第２のサービス構成要素に対応するアクションの実行を待機させる、請求項１に記載のコンピュータ・システム。
【請求項９】
前記第２のサービス構成要素に対応するアクションの実行が待機している場合、前記判定部が、前記第１のサービス構成要素に対応するアクションの終了に応じて、前記第２のサービス構成要素に対応するアクションを実行することが許されるかどうかをさらに判定する、請求項８に記載のコンピュータ・システム。
【請求項１０】
前記判定部が、前記第１のサービス構成要素に対応するアクションの対象である構成要素が前記第２のサービス構成要素に対応するアクションの対象である構成要素と重複しない場合、前記第２のサービス構成要素に対応するアクションを実行することを許す、請求項１に記載のコンピュータ・システム。
【請求項１１】
前記関連付けが、前記第１のサービス構成要素に対応するアクションの開始に応じて行われる、請求項１に記載のコンピュータ・システム。
【請求項１２】
前記関連付部が、前記第１のサービス構成要素に対応するアクションの終了に応じて、前記関連付けを解除する、請求項１１に記載のコンピュータ・システム。
【請求項１３】
所定の属性及び構成要素と他の構成要素との関係を定義するデータ・モデルが、サービス構成要素のアクション・タイプと該サービス構成要素に対応するアクションの対象である構成要素の範囲とを含む、請求項１に記載のコンピュータ・システム。
【請求項１４】
サービス構成要素に対応するアクションの実行を管理する方法であって、
構成要素についての情報を検出するステップと、
前記検出された情報に基づいて、構成要素毎に、該構成要素の少なくとも１つの所定の属性及び該構成要素と他の構成要素との関係を示す１組のデータを作成し、該１組のデータをリポジトリに格納するステップと、
前記サービス構成要素を、該サービス構成要素に対応するアクションの対象である少なくとも１の構成要素に関連付けるステップと、
第１のサービス構成要素に対応するアクションの実行中に第２のサービス構成要素に対応するアクションへのリクエストがあり且つ該第２のサービス構成要素に対応するアクションの対象である少なくとも１の構成要素が該第１のサービス構成要素に対応するアクションの対象である構成要素に含まれる場合、該第２のサービス構成要素に対応するアクションを実行することが許されるかどうかを判定するステップと
を含む、前記方法。
【請求項１５】
前記第１又は第２のサービス構成要素に対応するアクションの終了後に、構成要素についての情報を検出するステップをさらに含む、請求項１４に記載の方法。
【請求項１６】
前記第１又は第２のサービス構成要素に対応するアクションの終了後に、該終了したサービス構成要素に対応するアクションの対象である構成要素についての情報を検出するステップをさらに含む、請求項１５に記載の方法。
【請求項１７】
前記第１又は第２のサービス構成要素に対応するアクションの終了後に、前記第１のサービス構成要素に対応するアクションの対象である少なくとも１の構成要素と前記第２のサービス構成要素に対応するアクションの対象である構成要素との重複範囲に含まれる構成要素についての情報を検出するステップをさらに含む、請求項１６に記載の方法。
【請求項１８】
前記判定するステップが、前記サービス構成要素に対応するアクションを実行することが許されるかどうかを判定するためのルールを定義するポリシーによって前記アクションを実行することが許されるかどうかを判定するステップを含む、請求項１４に記載の方法。
【請求項１９】
前記アクションを実行することが許される場合、前記第２のサービス構成要素に対応するアクションを実行すること許すステップと、
前記アクションを実行することが許されない場合、前記第２のサービス構成要素に対応するアクションの実行を待機させるステップと
をさらに含む、請求項１４に記載の方法。
【請求項２０】
前記第１のサービス構成要素に対応するアクションの対象である構成要素が前記第２のサービス構成要素に対応するアクションの対象である構成要素と重複しない場合、前記第２のサービス構成要素に対応するアクションを実行することを許すステップをさらに含む、請求項１４に記載の方法。
【請求項２１】
前記関連付けるステップが、前記第１のサービス構成要素に対応するアクションの開始に応じて行われる、請求項１４に記載の方法。
【請求項２２】
前記第１のサービス構成要素に対応するアクションの終了に応じて、前記関連付けを解除するステップをさらに含む、請求項２１に記載の方法。
【請求項２３】
前記第２のサービス構成要素に対応するアクションの実行が待機している場合、前記第１のサービス構成要素に対応するアクションの終了に応じて、前記第２のサービス構成要素に対応するアクションを実行することが許されるかどうかをさらに判定するステップをさらに含む、請求項１４に記載の方法。
【請求項２４】
構成要素についての情報を検出するディスカバリ部と、構成要素毎に、該構成要素の少なくとも１つの所定の属性及び該構成要素と他の構成要素との関係を示す１組のデータを保持するリポジトリとを含むコンピュータ・システムにおいて、サービス構成要素に対応するアクションの実行を管理する方法であって、
前記サービス構成要素を、該サービス構成要素に対応するアクションの対象である少なくとも１の構成要素に関連付けるステップと、
第１のサービス構成要素に対応するアクションの実行中に第２のサービス構成要素に対応するアクションへのリクエストがあり且つ該第２のサービス構成要素に対応するアクションの対象である少なくとも１の構成要素が該第１のサービス構成要素に対応するアクションの対象である構成要素に含まれる場合、
該第２のサービス構成要素に対応するアクションを実行することが許されるかどうかを判定するステップと、
前記アクションを実行することが許される場合、前記第２のサービス構成要素に対応するアクションを実行させるステップと、
前記アクションを実行することが許されない場合、前記第２のサービス構成要素に対応するアクションの実行を待機させるステップと、
前記第１のサービス構成要素に対応するアクションの対象である構成要素が前記第２のサービス構成要素に対応するアクションの対象である構成要素と重複しない場合、前記第２のサービス構成要素に対応するアクションを実行することを許すステップと、
前記第１又は第２のサービス構成要素に対応するアクションの終了後に、構成要素についての情報を検出するステップと
を含む、前記方法。
【請求項２５】
サービス構成要素に対応するアクションの実行を管理するコンピュータ・プログラムであって、コンピュータ・システムに、請求項１４〜２４のいずれか一項に記載の方法の各ステップを実行させるコンピュータ・プログラム。
【図１Ａ】
【図１Ｂ】
【図２Ａ】
【図２Ｂ】
【図３Ａ】
【図３Ｂ】
【図３Ｃ】
【図３Ｄ】
【図３Ｅ】
【図３Ｆ】
【図３Ｇ】
【図３Ｈ】
【図４】
【図５】
【図６】
【図７Ａ】
【図７Ｂ】
【図７Ｃ】
【図８】
【図９】
【図１０】
【図１Ｂ】
【図２Ａ】
【図２Ｂ】
【図３Ａ】
【図３Ｂ】
【図３Ｃ】
【図３Ｄ】
【図３Ｅ】
【図３Ｆ】
【図３Ｇ】
【図３Ｈ】
【図４】
【図５】
【図６】
【図７Ａ】
【図７Ｂ】
【図７Ｃ】
【図８】
【図９】
【図１０】
【公開番号】特開２０１０−５５２１１（Ｐ２０１０−５５２１１Ａ）
【公開日】平成２２年３月１１日（２０１０．３．１１）
【国際特許分類】
【出願番号】特願２００８−２１７２３４（Ｐ２００８−２１７２３４）
【出願日】平成２０年８月２６日（２００８．８．２６）
【出願人】（３９０００９５３１）インターナショナル・ビジネス・マシーンズ・コーポレーション (4,084)
【氏名又は名称原語表記】ＩＮＴＥＲＮＡＴＩＯＮＡＬ ＢＵＳＩＮＥＳＳ ＭＡＳＣＨＩＮＥＳ ＣＯＲＰＯＲＡＴＩＯＮ
【復代理人】
【識別番号】１０００８５５４５
【弁理士】
【氏名又は名称】松井 光夫
【復代理人】
【識別番号】１００１１８５９９
【弁理士】
【氏名又は名称】村上 博司
【Ｆターム（参考）】
【公開日】平成２２年３月１１日（２０１０．３．１１）
【国際特許分類】
【出願日】平成２０年８月２６日（２００８．８．２６）
【出願人】（３９０００９５３１）インターナショナル・ビジネス・マシーンズ・コーポレーション (4,084)
【氏名又は名称原語表記】ＩＮＴＥＲＮＡＴＩＯＮＡＬ ＢＵＳＩＮＥＳＳ ＭＡＳＣＨＩＮＥＳ ＣＯＲＰＯＲＡＴＩＯＮ
【復代理人】
【識別番号】１０００８５５４５
【弁理士】
【氏名又は名称】松井 光夫
【復代理人】
【識別番号】１００１１８５９９
【弁理士】
【氏名又は名称】村上 博司
【Ｆターム（参考）】
[ Back to top ]