(57)【要約】【課題】コンピューティング環境内の少なくとも１つのサブジェクト構成要素の状態（例えば、サービス停止）の根本原因を判定する技法を提供すること。【解決手段】この技法は以下のステップ／オペレーションを含む。まず、少なくとも１つのサブジェクト構成要素が依存するコンピューティング環境内の１つまたは複数の構成要素（例えばアンテシーデント）を識別する。識別は、前記コンピューティング環境の構成要素の少なくとも一部に関連する１つまたは複数の関係の存在を表すモデルの少なくとも一部を走査することを含み、走査は、コンピューティング環境の構成要素の少なくとも１つの構成要素に関連する全ライフサイクル（例えば、配置、インストール、および実行時を含む）を反映することができる。次いで、識別した１つまたは複数の構成要素に従って１つまたは複数の手順を実施し、識別した１つまたは複数の構成要素それぞれに関連する状態ステータスを判定する。例えば、本発明の技法は分散コンピューティング環境に適用することができる。コンピューティング環境は自律型コンピューティング環境でもよい。
2005538459.tif 000002
【特許請求の範囲】
【請求項１】
コンピューティング環境内の複数の構成要素のうち少なくとも１つのサブジェクト構成要素の状態の根本原因を判定するコンピュータ・ベースの方法であって、
前記サブジェクト構成要素が依存する他の１つまたは複数の構成要素を識別するステップであって、前記識別するステップが、前記他の１つまたは複数の構成要素に関連する１つまたは複数の関係の存在を表すモデルの少なくとも一部を走査するサブステップを含み、前記走査するサブステップが、前記サブジェクト構成要素に関連する全ライフサイクルを把握するサブステップを含む、ステップと、
前記１つまたは複数の識別した構成要素に応じて１つまたは複数の手順を実施し、前記１つまたは複数の識別した構成要素それぞれに関連する状態ステータスを判定するステップとを含む方法。
【請求項２】
前記コンピューティング環境が分散コンピューティング環境を含む請求項１に記載の方法。
【請求項３】
前記コンピューティング環境が自律型コンピューティング環境を含む請求項１に記載の方法。
【請求項４】
前記識別するステップが、前記サブジェクト構成要素が直接依存する１つまたは複数の構成要素を識別する請求項１に記載の方法。
【請求項５】
前記識別するステップが、前記サブジェクト構成要素が依存する完全な１群の構成要素を識別する請求項１に記載の方法。
【請求項６】
前記実施するステップが、前記複数の手順を段階的に実施するステップをさらに含む請求項１に記載の方法。
【請求項７】
前記実施するステップが、前記複数の手順を組み合わせて実施するステップをさらに含む請求項１に記載の方法。
【請求項８】
前記モデルが、機能分類、構造分類、および動作分類を含む形である請求項１に記載の方法。
【請求項９】
前記識別するステップが、少なくとも１つの入力基準に基づいて前記モデルの前記動作分類を計算し、前記動作分類を走査して、前記少なくとも１つのサブジェクト構成要素が依存するコンピューティング環境内の前記１つまたは複数の構成要素を識別する請求項８に記載の方法。
【請求項１０】
前記少なくとも１つの入力基準が、前記少なくとも１つのサブジェクト構成要素の名前、前記少なくとも１つのサブジェクト構成要素に関連するホスト、前記走査の方向、前記走査の深さ、前記走査の経路、および少なくとも１つのフィルタリング基準のうち少なくとも１つを含む請求項９に記載の方法。
【請求項１１】
前記実施するステップの前記手順が、構成要素検査手順、構成要素エクササイジング手順、構成要素ハートビート検出手順、および構成要素ステータス表示手順のうち少なくとも１つを含む請求項１に記載の方法。
【請求項１２】
前記サブジェクト構成要素の前記状態が、障害発生、障害なし、性能低下のうちの１つである請求項１に記載の方法。
【請求項１３】
前記構成要素が、前記コンピューティング環境に関連するサービス、アプリケーション、ミドルウェア、ハードウェア、デバイス・ドライバ、オペレーティング・システム、およびシステムのうちの１つである請求項１に記載の方法。
【請求項１４】
前記根本原因判定方法が、複数のサブジェクト構成要素についてほぼ同時に実施される請求項１に記載の方法。
【請求項１５】
前記根本原因判定方法の結果の少なくとも一部が、永続的に格納されるか、または永続的に格納されないかの一方である請求項１に記載の方法。
【請求項１６】
前記根本原因判定方法に関連する結果の履歴を維持するステップをさらに含む請求項１に記載の方法。
【請求項１７】
前記履歴の少なくとも一部が、最も可能性の高い根本原因を識別するのに使用される請求項１６に記載の方法。
【請求項１８】
コンピューティング環境内の複数の構成要素のうち少なくとも１つのサブジェクト構成要素の状態の根本原因を判定する装置であって、
（ｉ）前記少なくとも１つのサブジェクト構成要素が依存する他の１つまたは複数の構成要素を識別することであって、前記識別が、前記１つまたは複数の構成要素に関連する１つまたは複数の関係の存在を表すモデルの少なくとも一部を走査することを含み、前記走査が、前記サブジェクト構成要素に関連する全ライフサイクルを反映することができること、および（ｉｉ）前記１つまたは複数の識別した構成要素に従って１つまたは複数の手順を実施させ、前記１つまたは複数の識別した構成要素それぞれに関連する状態ステータスを判定することを行うように動作可能な少なくとも１つのプロセッサと、
前記少なくとも１つのプロセッサに結合され、前記識別するオペレーションおよび実施するオペレーションに関連する結果の少なくとも一部を格納するように動作可能なメモリとを備える装置。
【請求項１９】
前記コンピューティング環境が分散コンピューティング環境を含む請求項１８に記載の装置。
【請求項２０】
前記コンピューティング環境が自律型コンピューティング環境を含む請求項１８に記載の装置。
【請求項２１】
前記識別するオペレーションが、前記少なくとも１つのサブジェクト構成要素が直接依存する１つまたは複数の構成要素を識別する請求項１８に記載の装置。
【請求項２２】
前記識別するオペレーションが、前記少なくとも１つのサブジェクト構成要素が依存する完全な１組の構成要素を識別する請求項１８に記載の装置。
【請求項２３】
前記実施するオペレーションが、前記複数の手順を段階的に実施させることをさらに含む請求項１８に記載の装置。
【請求項２４】
前記実施するオペレーションが、前記複数の手順を組み合わせて実施させることをさらに含む請求項１８に記載の装置。
【請求項２５】
前記モデルが、機能分類、構造分類、および動作分類を含む形である請求項１８に記載の装置。
【請求項２６】
前記識別するオペレーションが、少なくとも１つの入力基準に基づいて前記モデルの前記動作分類を計算し、前記動作分類を走査して、前記少なくとも１つのサブジェクト構成要素が依存するコンピューティング環境内の前記１つまたは複数の構成要素を識別することをさらに含む請求項２５に記載の装置。
【請求項２７】
前記少なくとも１つの入力基準が、前記少なくとも１つのサブジェクト構成要素の名前、前記少なくとも１つのサブジェクト構成要素に関連するホスト、前記走査の方向、前記走査の深さ、前記走査の経路、および少なくとも１つのフィルタリング基準のうち少なくとも１つを含む請求項２６に記載の装置。
【請求項２８】
前記実施するオペレーションの前記１つまたは複数の手順が、構成要素検査手順、構成要素エクササイジング手順、構成要素ハートビート検出手順、および構成要素ステータス表示手順のうち少なくとも１つを含む請求項１８に記載の装置。
【請求項２９】
前記少なくとも１つのサブジェクト構成要素の前記状態が、障害発生、障害なし、性能低下のうちの１つである請求項１８に記載の装置。
【請求項３０】
構成要素が、前記コンピューティング環境に関連するサービス、アプリケーション、ミドルウェア、ハードウェア、デバイス・ドライバ、オペレーティング・システム、およびシステムのうちの１つである請求項１８に記載の装置。
【請求項３１】
根本原因判定が、前記少なくとも１つのプロセッサにより複数のサブジェクト構成要素についてほぼ同時に実施される請求項１８に記載の装置。
【請求項３２】
前記根本原因判定の結果の少なくとも一部が、前記少なくとも１つのプロセッサにより永続的に格納されるか、または永続的に格納されないかの一方である請求項１８に記載の装置。
【請求項３３】
前記少なくとも１つのプロセッサがさらに、前記根本原因判定方法に関連する結果の履歴を維持するように動作可能である請求項１８に記載の装置。
【請求項３４】
前記履歴の少なくとも一部が、最も可能性の高い根本原因を識別するのに使用される請求項３３に記載の装置。
【請求項３５】
コンピューティング環境内の複数の構成要素のうち少なくとも１つのサブジェクト構成要素の状態の根本原因を判定するコンピュータ・プログラムであって、
コンピュータに、
前記サブジェクト構成要素が依存する前記コンピューティング環境内の他の１つまたは複数の構成要素を識別するステップであって、前記識別するステップが、前記他の１つまたは複数の構成要素に関連する１つまたは複数の関係の存在を表すモデルの少なくとも一部を走査するステップを含み、前記走査するステップが、前記サブジェクト構成要素に関連する全ライフサイクルを反映することができるステップと、
前記１つまたは複数の識別した構成要素に従って１つまたは複数の手順を実施し、前記１つまたは複数の識別した構成要素それぞれに関連する状態ステータスを判定するステップと
を実行させるコンピュータ・プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は分散コンピューティング・システムに関し、より詳細には、そのようなコンピューティング・システムの様々な構成要素間の依存関係に基づいてサービス停止の根本原因を分析および判断する方法および装置に関する。
【背景技術】
【０００２】
本願は、「Methods And Apparatus For ManagingDependencies in Distributed Systems」という名称の整理番号YOR920020097US1、「Methods AndApparatus For Topology Discovery and Representation of Distributed Applicationsand Services」という名称の整理番号SOM920020003US1、「Methods And Apparatus For ImpactAnalysis and Problem Determination」という名称の整理番号SOM920020004US1、および「Methods AndApparatus For Dependency-based Impact Simulation and Vulnerability Analysis」という名称の整理番号SOM920020005US1とそれぞれ識別される、同時に出願した米国特許出願に関連する。
【０００３】
分散システムの構成要素間の依存関係の識別および追跡は、統合型障害管理にとってますます重要になっている。アプリケーション、サービス、およびその構成要素は、サービス・プロバイダにアウトソーシングされる可能性のある様々な支援サービスに依拠する。さらに、台頭しつつあるウェブ・ベースの（ワールド・ワイド・ウェブ・ベースの）ビジネス・アーキテクチャは、ウェブブラウザ・ベースのｅ−ビジネス（電子ビジネス）アプリケーションを実行時に構成することを可能にする。
【０００４】
「実行時」という用語は一般に、１つのソフトウェアが、休止中であり、かつコンピュータのハード・ドライブ上のストレージ内に単に位置するのではなく、実行中であり、コンピュータ・システムのメモリ内でアクティブである時間枠を指すことを理解されたい。したがって、実行時にｅ−ビジネス・アプリケーションを構成できることは、システム／アプリケーションを停止して再始動する必要なしに、かつアプリケーションを再コンパイルする必要なしにそのようにできる能力を有することを意味する。伝統的に、コンピュータ・プログラムのライフサイクルは、プログラム・コードを書く−＞コンパイルする（マシン・コードに変換する）−＞実行するというものである。したがって、上記の能力を用いて、いくつかのソフトウェアを集めて、「オンザフライ」で、すなわちアプリケーションを停止／コンパイル／再始動する必要なしに、新しいアプリケーションを形成することができる。
【０００５】
しかし、その結果、あるサービスで発生する障害が、顧客に提供される他のサービスに影響を及ぼす。すなわち、あるサービスは他のサービスに対して依存関係を有する。依存関係は、単一システム上の異なるサービスの構成要素間に、さらには複数のシステムおよびドメインにわたるサービスのクライアント／サーバ構成要素間に存在する。本明細書では、他のサービスに依存するサービスをディペンデント(dependent)と呼び、他のサービスがそれに依存するサービスをアンテシーデント(antecedent)と呼ぶ。
【０００６】
サービスはしばしばどちらの役割も果たすことに留意されたい（例えば、名前サービスは多くのアプリケーションおよびサービスによって必要とされるが、名前サービスは自体は、オペレーティング・システムやネットワーク・プロトコル／インフラストラクチャなどの他のサービスの適切な機能に依存する）。さらに、依存関係は推移的である。すなわち所与の構成要素のディペンデントは、構成要素自体に加えて、構成要素のアンテシーデントを必要とする。
【０００７】
依存関係は、エンド・ユーザ・サービス、システム・サービス、アプリケーション、その論理／物理構成要素などの分散システムの様々な構成要素間に存在する。しかし、サービス依存関係は今日のシステムでは明示的にされず、したがって問題の判定、分離、解決の作業が特に困難となる。
【０００８】
ソフトウェア開発の分野の既存の技術（米国特許第４７５１６３５号および米国特許第５９６０１９６号など）、保守の分野の既存の技術（米国特許第５４９３６８２号など）、およびソフトウェア・パッケージングの分野の既存の技術（５８３５７７７号など）は、プログラム・パッケージのアトミック部分を形成し、ソフトウェアを構築してそれをソフトウェア製品に組み込むためにプログラム・ソース・コードの可用性を必要とする個々のソフトウェア要素およびモジュールに対処する。ソース・コードはソフトウェア開発者には利用可能であるが、サービス・ユーザには利用可能ではない。本発明は主に、既にパッケージ化されたソフトウェア製品に焦点を当てる。
【０００９】
The Institute of Electrical andElectronics Engineers Standard 1387.2（題名「ポータブル・オペレーティング・システム・インターフェース（ＰＯＳＩＸ）システム管理、第２部：ソフトウェア管理(PortableOperating System Interface (POSIX) system administration, part 2: SoftwareAdministration)、IEEE、1995年」）は、ソフトウェア配布／配置／インストールに対処する。このＩＥＥＥ標準は、（インストールされることになる）新しいソフトウェア構成要素が既存のソフトウェア・インストールと競合しないように保証する機構を定義する。このＩＥＥＥ標準は、このような互換性チェックを容易にする前提条件、排他条件、相互必要条件という３種類の関係を識別する。これは、新しいソフトウェアをインストールする必要のあるあらゆるシステムについて個々に行われる。このＩＥＥＥ標準では、他のシステム上に存在するソフトウェア・インベントリは考慮されない。さらに、このＩＥＥＥ標準は、インスタンス化されたアプリケーションおよびサービスに対処せず、したがって、構成要素間の依存関係を実行時に判定するどんな手段も表さない。
【００１０】
Open Group（システム管理：分散ソフトウェア管理(SystemManagement: Distributed Software Administration)、CAE Specification C701、TheOpen Group、1998年1月）は、特定のシステム上のソフトウェア・インストール・ツールによって起動されるいくつかのコマンド（swinstall,swlist, swmodifyなど）を定義することによってＩＥＥＥ１３８７．２を拡張する。Open Groupはまた、ソフトウェア定義ファイル・フォーマットも定義して、前述のコマンドによって必要とされる情報が、コマンドが起動されるシステムから利用可能となるように保証する。ＩＥＥＥ１３８７．２の欠点（すなわち、単一の分離システムに限定されること、実行時にソフトウェア依存関係を判定する手段がないこと）はOpenGroupの仕様にも当てはまる。
【００１１】
現行のオペレーティング・システム・インベントリ実装（IBM AIX ObjectData Manager (ODM)、Linux Red Hat Package Manager (RPM)、Microsoft Windows（Ｒ）Registryなど）は、OpenGroup仕様とＩＥＥＥ１３８７．２標準のどちらかに追従し、またはソフトウェア・インベントリをメーカ独自のフォーマットで記述する。したがって、前述の制限は、このような現行のオペレーティング・システム・インベントリ実装にも当てはまる。
【００１２】
プログラム・パッケージ全体の電子的ソフトウェア配布のための技法（米国特許第６００９５２５号、米国特許第５７２１８２４号など）、または更新／補正／修正／パッチの電子的ソフトウェア配布のための技法（米国特許第５９９９７４０号、米国特許第５８０５８９１号、米国特許第５９５３５３３号など）は、定義により、物理的ソフトウェア・パッケージの（１度に１つまたは多数の）配布／配置／インストールに制限され、アプリケーションの実行時段階を考慮に入れない。加えて、それらは１度に１つのシステムを処理し、アプリケーションおよびサービスのシステム間の側面を考慮に入れない。
【００１３】
既存のソフトウェア／ハードウェア構成での競合を判定する技法（米国特許第５８６７７１４号など）も単一システムに限定され、実行時の側面を考慮に入れない。
【００１４】
既存の研究（米国特許第５９１７８３１号など）は、しばしばイベント相関（例えば、Gruschke等、「統合イベント管理：依存関係グラフを用いたイベント相関(IntegratedEvent Management: Event Correlation Using Dependency Graphs)」、DSOM '98、1998年およびKatker等、「FaultIsolation and Event Correlation for Integrated Fault Management（統合型障害管理のための障害分離およびイベント相関）」、IM'97、1997年参照）の範囲内であり、メーカ独自のフォーマットでのサービス依存関係を識別および記述することに焦点を当てており、依存関係情報を障害管理プロセスの様々なエンティティ間で実際にどのように交換することができるか不透明なままである。アウトソーシングされたアプリケーションの障害管理プロセスに関する異なるパーティが依存関係を追跡するのに同一のツールセットを使用する可能性は低いので、依存関係情報を指定および交換するオープン・フォーマットを定義することが根本的に重要である。
【００１５】
さらに、既存の技法の制限を考えると、障害管理プロセスが関係する分散システムの構成要素に関連する異機種性のために、システム障害（例えばサービス停止）の根本原因を判定することが極めて難しい。
【００１６】
まとめると、ソフトウェア製品間の関係の判定に関するいくつかの技法が既存の技術で説明され実施されている。こうした既存の技法は、以下の欠点のうち１つまたは複数を受ける。
（ａ）ソフトウェア製品のインストール段階および配置段階だけしか対処しない。すなわち、設計および実行時の側面を取り込もうとしない。
（ｂ）複数のシステムにわたるエンドツーエンドのアプリケーションおよびサービスに対処しない。すなわち、分離したシステム上に常駐する単一のソフトウェアの特性に対処しない。
（ｃ）ソフトウェア・インベントリ情報がメーカ独自のフォーマットで記述され、それにより、様々な異機種システム間でこの情報を共有することが極めて難しくなる。
（ｄ）サービス停止の根本原因を効率的に特定しない。
【特許文献１】米国特許出願「Methods And Apparatus ForManaging Dependencies in Distributed Systems」、整理番号YOR920020097US1
【特許文献２】米国特許出願「Methods And Apparatus ForTopology Discovery and Representation of Distributed Applications and Services」、整理番号SOM920020003US1
【特許文献３】米国特許出願「Methods And Apparatus ForImpact Analysis and Problem Determination」、整理番号SOM920020004US1
【特許文献４】米国特許出願「Methods And Apparatus ForDependency-based Impact Simulation and Vulnerability Analysis」、整理番号SOM920020005US1
【特許文献５】米国特許第４７５１６３５号
【特許文献６】米国特許第５９６０１９６号
【特許文献７】米国特許第５４９３６８２号
【特許文献８】米国特許第５８３５７７７号
【特許文献９】米国特許第６００９５２５号
【特許文献１０】米国特許第５７２１８２４号
【特許文献１１】米国特許第５９９９７４０号
【特許文献１２】米国特許第５８０５８９１号
【特許文献１３】米国特許第５９５３５３３号
【特許文献１４】米国特許第５８６７７１４号
【特許文献１５】米国特許第５９１７８３１号
【非特許文献１】The Institute of Electrical andElectronics Engineers Standard 1387.2（題名「ポータブル・オペレーティング・システム・インターフェース（ＰＯＳＩＸ）システム管理、第２部：ソフトウェア管理(PortableOperating System Interface (POSIX) system administration, part 2: SoftwareAdministration)、IEEE、1995」）
【非特許文献２】Open Group（システム管理：分散ソフトウェア管理(SystemManagement: Distributed Software Administration)、CAE Specification C701、TheOpen Group、1998年1月）
【非特許文献３】Gruschke等、「統合イベント管理：依存関係グラフを用いたイベント相関(IntegratedEvent Management: Event Correlation Using Dependency Graphs)」、DSOM '98、1998年
【非特許文献４】Katker等、「Fault Isolation and EventCorrelation for Integrated Fault Management（統合型障害管理のための障害分離およびイベント相関）」、IM '97、1997年
【非特許文献５】ピー・ホーン(P. Horn)、「自律型コンピューティング：情報技術の現状に関するＩＢＭの展望(AutonomicComputing: IBM's Perspective on the State of Information Technology)」、ＩＢＭリサーチ(IBMResearch)、2001年10月
【発明の開示】
【発明が解決しようとする課題】
【００１７】
本発明は、構成要素障害の根本原因を特定し、コンピューティング環境に従って適切な問題判定手順を実施する技法を提供する。例えば、本発明の技法は分散コンピューティング環境に適用することができる。コンピューティング環境は自律型コンピューティング環境でもよい。
【課題を解決するための手段】
【００１８】
例えば、本発明の一態様では、コンピューティング環境内の少なくとも１つのサブジェクト構成要素の状態（サービス停止）の根本原因を判定するコンピュータ・ベースの技法が、以下のステップ／オペレーションを含む。まず、少なくとも１つのサブジェクト構成要素が依存するコンピューティング環境（例えばアンテシーデント）内の１つまたは複数の構成要素を識別する。識別には、コンピューティング環境の構成要素の少なくとも一部に関連する１つまたは複数の関係の存在を表すモデルの少なくとも一部を走査することが含まれ、この走査により、コンピューティング環境の少なくとも１つの構成要素に関連する全ライフサイクル（例えば、配置、インストール、および実行時を含む）を反映することができる。
【００１９】
次いで、識別した１つまたは複数の構成要素に従って１つまたは複数の手順を実施し、識別した１つまたは複数の構成要素に関連する状態ステータスを判定する。この手順は、段階的に、または組み合わせて実施することができ、例えば、プロセス検査、エクササイジング、ハートビート、およびステータス・インジケータを含むことができる。
【００２０】
例えば、構成要素は、コンピューティング環境に関連するサービス、アプリケーション、ミドルウェア、ハードウェア、デバイス・ドライバ、オペレーティング・システム、またはシステムでよい。しかし、「構成要素」という用語は、こうした例に限定されない。
【００２１】
本発明の上記およびその他の目的、特徴、および利点は、添付の図面と共に読むべき以下の本発明の例示的実施形態の詳細な説明から明らかとなるであろう。
【発明を実施するための最良の形態】
【００２２】
以下では、例示的分散コンピューティング環境の状況で本発明を説明する。しかし、本発明はそのような特定のコンピューティング環境に限定されないことを理解されたい。むしろ、本発明は、より一般的には、問題の判定、分離、および解決の作業を著しく容易にするために依存関係を管理（例えば計算、照会など）することが望ましいどんなコンピューティング環境にも適用可能である。
【００２３】
本明細書では、議論の状況に応じて、「システム」という用語を、コンピュータ・システム、ソフトウェア・システム、またはそれらの何らかの組合せを指すのに用いることがある。「システム」という用語はまた、アプリケーションまたはサービスあるいはその両方を指すのに用いることもある。したがって、「複数のシステム」という語句はいくつかのシステムの集合を指す。さらに、「構成要素」という用語は、システム自体、またはシステムの１つまたは複数の部分を指すことがある。
【００２４】
前述のように、今日のシステムではサービス依存関係は明示的にされず、したがって問題の判定、分離、および解決の作業が特に難しくなる。この問題を解決するには、異なるシステムおよびドメインにわたるサービスおよびアプリケーション間の依存関係の判定および計算、すなわち「グローバル」サービス依存関係モデルを確立し、得られる有向グラフの上端（上流端）から下端（下流端）まで、および逆の順序でシステム管理者がナビゲートすることを可能とすることが必要となる。このような機構の必要性は、以下の２つのシナリオで最も良く示される。
【００２５】
第１のシナリオは、通常はインターネット／アプリケーション・サービス・プロバイダ（ＩＳＰ／ＡＳＰ）によって提供されるアウトソーシング・サービスの管理を扱う。アウトソーシング・サービスにより、例えばＡＳＰのサービスがＩＳＰによって提供されるＩＰ接続性（インターネット・プロトコル接続性）に依存し、ＩＳＰは、遠隔通信キャリアの広域ネットワークに依拠するという階層化サービス階層が得られる。どの層でも、サービスはサービス・アクセス・ポイント（ＳＡＰ）を介してアクセスされる。ＳＡＰは、異なる組織ドメイン間の境界を区切り、サービス・レベル・アグリーメント（ＳＬＡ）が定義され観測される場所である。通常、このことは、あらゆる層で、プロバイダによって公開される１組の特定のパラメータを監視することによって行われる。上層サービスが停止または性能低下した場合、サービス階層を上端から下端まで走査して、問題の根本原因を特定することが必要である。
【００２６】
第２のシナリオは、「オンザフライ」で行うことができず、したがってサービスおよびその顧客に影響を及ぼす通常の保守作業を扱う。例えば、Ｅメール・サーバをそのオペレーティング・システムの新しいリリースで更新すること、ネットワークを新しいファームウェア・バージョンで交換またはアップグレードすることなどである。すべての場合に、保守によってどれほどのサービスおよびユーザが影響を受けるか、より具体的にはどのサービスおよびユーザが影響を受けるかをネットワーク／サーバ管理者があらかじめ判断することが重要である。この作業を影響分析と呼ぶ。
【００２７】
上述の作業は、次の要因によってさらに悪化する。
【００２８】
依存関係モデルは、観測される問題の可能性のある根本原因を特定する直接的な手段を提供する。システムに関する依存関係グラフが既知である場合、損なわれたサービスから（同一ホスト上に配置された、または異なるシステム上の）そのアンテシーデントに向かってグラフをナビゲートすることにより、どのエンティティに障害が発生した可能性があるかが明らかになる。グラフをそのルートに向かって（すなわち上向きに）走査することにより、サービスのディペンデント、すなわちこのサービスが停止した場合に障害が発生する可能性のある構成要素が得られる。以下の問題に対処する必要がある。
【００２９】
（ａ）スケール：多数の関係するシステム間の依存関係の数を計算することができるが、それは非常に大きくなる可能性がある。技術的観点からは、往々にして、完全なインスタンス化された依存関係モデルを単一の場所に格納することは望ましくない（不可能なこともある）。したがって、インスタンス化されたネットワーク・マップをプラットフォーム・データベース内に維持することなど、ネットワーク管理プラットフォームで使用される従来の機構は、関係する依存関係の純然たる数およびダイナミクスのために、依存関係に適用することができない。
【００３０】
こうした２つのことにより、アプリケーション、サービス、およびミドルウェア依存関係モデルの配置のための「ネットワーク管理スタイル」手法に追従することが抑制される。一例を挙げると、サービス・サウトソーサの典型的なデータ・センタは、膨大な量の（数千の）ウェブ・アプリケーションおよびデータベース・サーバをホストする。これにより、例えばウェブ・アプリケーションおよびデータベース・サーバの膨大な数の同時に動作するプログラム・インスタンスが示唆される。依存関係モデルを構築することができるシステムは、管理プロセスに関係する各システムにわたっておよび依存関係の記憶および計算を分散させることにより、適切なスケーラビリティを可能にする機能を提供すべきである。
【００３１】
（ｂ）ダイナミクス：（ウェブ・アプリケーション・サーバ内で動作する）ホスト・アプリケーションは、しばしばわずか数秒の非常に短い存続時間を有する。要求の受信時に、ウェブ・アプリケーションのビジネス論理（通常は１つまたは複数のJavaサーブレットとして実装される）が、アプリケーション・サーバのサーブレット・エンジンによってインスタンス化され、その作業を実施し、次いでサーブレット・エンジンによって除去される。したがって、こうした動的エンティティ間の依存関係を計算するシステムは、データの正確さと、このデータを取り出すために生成されるワークロードとの間の兼ね合いに対処すべきである。
【００３２】
（ｃ）異機種性：異機種性は３つの異なる形で現れる。第１に、顧客に提供されるサービスが大きく異なる。第２に、サービスを顧客に提供することに関係する様々なプロバイダが存在する可能性がある。最後に、サービスを実施する製品が様々なベンダに由来する可能性がある。依存関係を計算するシステムは、特定のオペレーティング・システム、ネットワーク・プロトコル、ソフトウェア製品、および顧客に提供されるサービスとは無関係の言語を提供すべきである。
【００３３】
（ｄ）依存関係データの手動保守：今日のシステムは通常、適切な管理インスツルメンテーションを提供しないので、サービス依存関係モデルの取得は、単一ホスト・システムに限定されていても、それ自体が難題である。「インスツルメンテーション」という用語は、（管理される）資源の管理特徴および機能を明確な（さらには標準化されることもある）インターフェースを介して公開し、その結果管理アプリケーションによってそれにアクセスすることができるプログラム・コードを指すことを理解されたい。さらに、管理される資源から利用可能となった場合であっても、依存関係データは今日の管理システムでは利用されない。それどころか、依存関係情報は特定の管理構成要素に手動で入力しなければならないだけでなく、メーカ独自のフォーマットで入力しなければならない。したがって、依存関係情報は不完全で古いものであり（手動処理は誤りがちなため）、さらには、異なるオペレータが規則を独立に入力し、整合性について規則ベースを自動的にチェックする方法がないので、矛盾することがある。
【００３４】
（ｅ）依存関係の分類：依存関係の概念は非常に大ざっぱであり、有用なものとするために精錬する必要がある。このことについての例は、依存関係の強さ（構成要素のアンテシーデントに障害が発生した場合に構成要素が影響を受ける尤度および程度を示す）、重要度（企業の目標およびポリシーに関してこの依存関係がどれほど重要であるか）、公式度（依存関係を得ることがどれほど難しいか）、およびその他多数である。依存関係に属性を加えて、依存関係をより適切に修飾することを可能にする必要があり、したがって、こうした属性を依存関係の表現に反映させる必要がある。
【００３５】
（ｆ）問題判定機能：システムごとに格納された局所的依存関係グラフを統一依存関係モデルとして組み合わせる別の機構が望まれる。加えて、こうした機構は、管理アプリケーションが依存関係モデルに対して照会を発行することを可能にするＡＰＩ（アプリケーション・プログラミング・インターフェース）を提供すべきである。こうした照会は、特定のサービスが直接依存するエンティティを取り出すため、または副アンテシーデントを含む１組のノード全体を反復的に決定することが許される。管理アプリケーションが受信するノードのリストにより、特定の問題判定ルーチンを実施して、これらのサービスが動作可能かどうかをチェックすることが可能となる。
【００３６】
上記の議論は、サービス・ライフサイクルの以下の３つの異なる段階の間のマッピングを確立することが重要であることを示している。
（ａ）顧客に提供される（抽象）サービス、例えば「ウェブ・ホスティング」、「管理ストレージ」、「ＩＰ接続性」、「管理データベース」など
（ｂ）サービスの実装、すなわちサービスを提供するのに使用される製品、例えば「IBMUniversal Database version 7.1」、「WebSphere Application Server version 3.2」
（ｃ）実装の実行インスタンス、すなわちプロセスまたはタスク、例えば「db2デーモン」、「nfsデーモン」
【００３７】
単一ステージごとに入手可能な情報を個々に得る作業は実行可能であるが、３つの段階を統一依存関係モデルとして組み合わせることは難題であり、以前の研究では行われていない。加えて、依存関係データの人間による対話および保守の必要をなくすと共に、基礎となる環境のスケール、ダイナミクス、および異機種性の要件に対処する、効率的に計算可能な依存関係モデルを確立することが求められている。
【００３８】
以下で各図の状況で示すように、本発明は上記およびその他の必要に対処する。すなわち、本発明は、管理アプリケーションの代わりに、分散システムの構成要素間の実行時依存関係（「依存関係モデル」）を計算する機能を有する。本発明は、個々のコンピュータ・システム構成情報を取り出す機構を提供し、またはそのようなデータを機械可読フォーマットで提供するコンピュータ・システムから依存関係情報を取り出す、汎用かつ統一された手法を提供する。
【００３９】
前述のシステムの１つの利点は、個々のアプリケーション／サービスを備える必要なしに、こうしたコンピュータ・システムから大量のアプリケーション／サービス管理情報を得ることができることである。しかし、このようなアプリケーション／サービス・インスツルメンテーションが利用可能である場合、それを本発明で使用することができる。
【００４０】
本発明で説明するシステムの実行は、特定の（管理）アプリケーション（インパクト・アナライザ、根本原因アナライザなど）、ネットワーク管理プラットフォーム（IBM/Tivoli NetView、HP OpenView、Aprisma Spectrumなど）、または従来のネットワーク管理システム／プラットフォームに基づく管理アプリケーションによって起動することができる。
【００４１】
本発明はとりわけ、
（ａ）性能低下および加入サービスの停止を観測し、
（ｂ）依存関係モデルの様々な層を上端から下端まで走査することによって問題の根本原因を追跡し（様々なサービスが他のサービス・プロバイダにアウトソーシングされている可能性があるので、依存関係モデルのこの（反復的）走査はドメイン境界を横断する）、
（ｃ）依存関係モデルを下端から上端までナビゲートすることにより、サービス停止の影響を分析する機能を提供する。
【００４２】
本発明は、アプリケーションまたはサービスのライフサイクル（すなわち、アプリケーション／サービスの設計段階から配置、インストール、および実行時段階まで）中に利用可能な依存関係情報を組み合わせる。この情報は、以下のモデル内に保たれる。
【００４３】
（ａ）機能モデル：好ましい実装では、機能モデルは、異なる汎用サービス（データベース・サービス、名前サービス、ウェブ・アプリケーション・サービス、接続性サービスなど）間の依存関係を定義する。機能モデルは、特定のサービス内のクライアント／サーバ関係を記述しない。加えて、機能モデルは、サービスを実装するのに実際のどの製品が選ばれたかも、その実際の構成も考慮に入れない。機能モデルは、他のモデル（以下で説明する）がバインドされる主な制約を確立する。すなわち、別のモデルが、実際のシステム・インフラストラクチャに関して機能モデルで定義された依存関係を改良することができるが、サービス・カテゴリ間に新しい依存関係を導入すべきではない。このモデルは非常にコンパクトで汎用的であり、好ましくは管理システム上に格納される。
【００４４】
（ｂ）構造モデル：好ましい実装では、構造モデルは、機能モデルで定義されるサービスを実現するソフトウェア構成要素の詳細な記述を含む。構造モデルは、インストール／配置段階中に取り込まれた詳細を提供し、実際のシステムのソフトウェア・インベントリを考慮に入れることによって機能モデルを補足する。構造モデルは、特定のシステム上にどのサービスがインストールされ構成されているかについて情報と、サービスごとにシステムがクライアントの役割で動作するか、それともサーバの役割で動作するかについての情報を提供する。潜在的に多数のシステムおよびサービスにより、こうした依存関係を遠隔地から追跡することが難しくなる。したがって、管理される資源の近くに、または管理される資源のところにこのモデルを格納することが望ましい。
【００４５】
（ｃ）動作モデル：好ましい実装では、ソフトウェア・パッケージがインスタンス化され、サービスとアプリケーションの間のバインディングが確立されるとき、依存関係の動作モデルが作成される。このモデルの高程度のダイナミクスと、多数の関係するシステムにより、完全なモデルをインスタンス化して格納することができる範囲に関して制限が課される。このようなモデルを定義して格納することは現実的ではなく、むしろモデルを動的かつ段階的に計算しなければならない。したがって動作モデルは「オンデマンド」で計算され、機能モデルおよび構造モデルに依拠する。
【００４６】
予想すべきであるが、依存関係の量およびそのダイナミクスは、大規模分散システムでは極めて高い。本発明の機能は、分散システムに対するそのインパクトを（資源および帯域幅の使用量の点で）可能な限り小さく保ち、ユーザに対して性能に影響を及ぼす可能性のある多くの構成オプションとして残す。この例は、更新後依存関係モデルを取り出す時間間隔、依存関係を追跡すべきシステムの範囲、依存関係モデルの深さである（直ちに影響を受けるサービス、所与のサービスに関するトランシティブ・クロージャ、全サービス階層）
【００４７】
好ましくは、本発明は、以下の依存関係情報の特徴を利用する。
【００４８】
（ａ）異なるサービス間の依存関係が階層化される。さらに、その依存関係グラフが配向され、非周期である。後者の表現はまた、DNS (Domain Name System)、NFS (Network File System)、DFS (DistributedFile System)、NIS (Network Information System)などのＩＰベースのネットワーク・サービスを伴う体験を反映するが、相互依存関係が一部のシステムで生じる場合がある。このような相互依存関係についての異常な例は、リモート・システムからＮＦＳを介してＤＮＳ構成が格納されるファイル・システムをマウントするＤＮＳサーバである。このような構成は技術的に実現可能であるが、これにより、ブートストラッピングが非確定的である可能性のある不安定なシステムとなるのでシステム設計での欠陥を反映し、したがって回避すべきであるからである。循環依存関係を発見する依存関係チェック・アプリケーションが管理者に警告を発すべきである。
【００４９】
（ｂ）あらゆる依存関係が顧客／プロバイダ・ドメイン境界で可視であり、ＳＬＡによって明示的にされる。これは、観測可能な依存関係の数が有限であることに追従する。
【００５０】
（ｃ）依存関係モデルにより、依存関係チェーンのトップダウン走査が可能となる。
【００５１】
（ｄ）異なるシステム間（「システム間(inter-system)」）の依存関係が、同一サービスのクライアント部分とサーバ部分の間の依存関係として認識される。サービスＡに関するクライアントが、異なるサービスＢを提供するサーバに対して要求を発行することは不可能である。
【００５２】
本発明の一目標は、実際のサービス／アプリケーション・インスツルメンテーションからの最大限の独立を達成するために、主にいくつかの既知の／明確な場所（例えばシステム・リポジトリ）から情報を取り出すことである。これを達成するために、本発明は、最小かつ十分な量の共通に利用可能な依存関係情報を定義する。
【００５３】
本発明は、依存関係モデルを永続的に格納する機構を含み、あるいはこれを管理アプリケーションまたは本発明を使用する別のサービスの裁量に任せる。
【００５４】
本発明は、依存関係モデルの変化を検出および判定するために、履歴の概念を有するように使用可能にされる。この場合、本発明は、依存関係モデル内の変化について以前に登録したソフトウェア構成要素に通知する発行／加入インターフェースを提供する。本発明の別の可能な使用法は、依存関係モデルの変化の検出を管理アプリケーション（または変更管理サービス）の裁量に任せ、依存関係モデルの変化が発生したかどうかを判定するために、本発明に対する周期的な呼を発行することである。
【００５５】
さらに、本明細書の以下で示すように、本発明は、サービス停止の根本原因を特定し、適切な問題判定手順を実施する技法を提供する。サービス停止の根本原因の発見は、サービス依存関係グラフを上端から下端まで走査して、問題を受けた候補サービスを識別し、次いでそれを問題のサービスに伝播することを含む。停止または低下が観測されたサービスからそのアンテシーデントへのこの走査により、特定のサービスが直接依存するエンティティが取り出され、または適切に機能するのにこのサービスが必要とする副アンテシーデントを含む完全なノードのセットが反復的に選択される。根本原因アナライザが受信するノードのリストにより、第２ステップで、こうしたサービスが動作するかどうかを特定の問題判定ルーチンがチェックすることが可能となる。こうした問題判定手順は、サービスが適切に機能しているか否かを判定することを含む。問題判定手順は、以下のいずれかで実施することができる。
【００５６】
（ｉ）段階的、すなわち単一サービスが返されるごとに機能テストが実施される。
（ｉｉ）組合せ、すなわち、アンテシーデント・サービスの全リスト（または動作モデルのサブセット）がまず得られ、それらのすべてについて問題判定手順が同時に実施される。こうしたテストを実施する順序は、サービス間の依存関係の強さから計算される優先順位値で決定することができ、優先順位値は、そのような依存関係に関連する重みとして表される。
【００５７】
前述のように、サービスが適切に機能しているかどうかを判定するために、問題判定手順を使用することができる。分散サービス／アプリケーションのための問題判定手順の例には、限定はしないが以下を含めることができる。
【００５８】
（ｉ）プロセス検査：サービスを実施するソフトウェア・アプリケーションについて、それらが適切に機能しているかどうかを判定する１つの方法は、そのプロセス（デーモン）が実行中かどうかを検証することである。このことは、オペレーティング・システムのプロセス・テーブル（またはタスク・リスト）を検査することによって非介入式に行うことができ、アプリケーションのどんなインスツルメンテーションも必要としない。アプリケーションのプロセスが実行中である場合、アプリケーションは正常な状態とみなされる。
【００５９】
（ｉｉ）アプリケーションをエクササイズすることは、アプリケーションが完全に動作するかどうか、すなわち実行し、そのビジネス機能を実施するかどうかを判定する割込み式の（かつより厳密な）方式である。「エクササイザ」は、アプリケーションを非常に完全な方式でエクササイズして、アプリケーションが実際に活動状態にあり、その機能を適時に送達することができるかどうかを判定する、アプリケーションの外部から起動されるトランザクションまたはコマンドである。アプリケーションの機能自体がエクササイズされる。ネットワーキングでの類推は、時間スタンプされたＩＰ（インターネット・プロトコル）パケットを資源に送信するＩＣＭＰ（インターネット制御メッセージ・プロトコル）「ping」コマンドを介して接続性をテストすることである。こうしたパケットは、資源によって返され、したがって、システムが、資源が活動状態であるかどうかを判定し、ラウンド・トリップ遅延を測定することが可能となる。
【００６０】
（ｉｉｉ）ハートビートにより、アプリケーションが活動状態であり良好であることをアプリケーションが実証することが可能となる。アプリケーションは、イベントを自動的かつ反復的に生成することにより、アプリケーションが健全な動作状態にあることを定期的に通知する。ハートビートをリスンするシステムは、タイムアウト期間がハートビート・イベント間で満了する場合、アプリケーションが正しく機能できないことを認識しなければならない。
【００６１】
（ｉｖ）ステータス・インジケータは、サービスを実施するアプリケーションの現ステータスを反映するアプリケーションの特定の管理変数である。１つまたは複数のステータス変数の照会により、サービスのヘルス全体が示される。しかし、この手法は、この情報を外部に公開することによってアプリケーションが適切に備えられることを必要とする。
【００６２】
さらに、本発明の根本原因判定方法は、１つまたは複数のサブジェクト構成要素についてほぼ同時に（例えば、１度に１構成要素、または複数の構成要素を並列に）実施することができる。本発明の根本原因判定方法の結果の少なくとも一部は、永続的に格納することができるが、そのような結果が永続的に格納されないことがある。さらに、本発明の根本原因判定方法に関連する結果の履歴を維持することができる。その後で根本原因を判定するステップのシーケンスを決定するために、このような履歴を使用してヒューリスティックスを導出することができる。例えば、最も一般的な停止のランキングを履歴から確立することができ、根本原因分析が次回起動されるとき、過去に最も障害が発生した構成要素が最初にチェックされる。
【００６３】
本発明および本発明に関連する一般的機能に従って上記が実現されるとして、詳細な説明の残りの部分で、図１から１６の状況でそのような実現および機能を実施する技法の例示的説明を与える。
【００６４】
まず図１を参照すると、本発明の機能が対話して情報を生成することのできるクライアント・サーバ・アプリケーション・アーキテクチャの形の電子商取引システムの一例を示すブロック図が示されている。本発明の技法がない場合にこのようなアーキテクチャがどのようにトランザクションを処理することができるかを示すために、以下で図１のアーキテクチャを説明する。
【００６５】
図示するように、クライアント・システム１０５を使用して、例えばキーボードを介して要求を開始する。しかし、要求は、マウス・クリック、音声コマンド、バー・コード読取りなどのどんな従来型手段でも開始することができる。クライアント・システム１０５の例は、パーソナル・コンピュータ、キオスク、データ・エントリ端末、スキャナ、電話、ページャ、ハンドヘルド／ウェアラブル装置、ワイヤレス装置、携帯情報端末、ネットワーク動作可能な腕時計などである。
【００６６】
要求はローカルに作用を受け、そこで要求が記述され、ネットワーク１１０を介して、かつ１つまたは多数のネットワーク・アクセス１１５装置を通過することにより、ウェブ・アプリケーション・サーバ１２０に転送される。ネットワーク１１０および通信プロトコルの一例は、サービス・プロバイダへの、最終的にはウェブ・アプリケーション・サーバ１２０への仮想回路を作成する多数の切換え位置を含む広域ネットワーク（ＷＡＮ）に、ルータや交換機などのネットワーク・アクセス１１５装置によって接続されるローカル・エリア・ネットワーク（ＬＡＮ）を介するＴＣＰ／ＩＰ（伝送制御プロトコル／インターネット・プロトコル）トランスポート上に乗るソケット・ベースの通信である。ウェブ・アプリケーション・サーバ１２０の例は、クライアントからの要求をフィールディングし、その要求を適切なバックエンド・データベース・サーバに適時配布するソフトウェアを実行するハイエンド・パーソナル・コンピュータ、ＲＩＳＣベースのＰｏｗｅｒＰＣ、ＵＮＩＸベースのワークステーション、ミニコンピュータ、またはメインフレーム・コンピュータである。
【００６７】
例示のために、インターネットを使用して商品を購入するために（クライアント・システム１０５上で動作する）ウェブ・ブラウザ内で開始される電子商取引取引をこれから説明する。本発明の技法は、どんな形態の取引でも機能することを理解されたい。ウェブ・アプリケーション・サーバの例には、限定はしないが、IBM CorporationからWEBSPHEREの商標の下で入手可能なもの、BEA Systems, Inc.からWEBLOGICの商標の下で入手可能なもの、またはLotusからLOTUSDOMINO SERVERの商標の下で入手可能なものが含まれる。
【００６８】
例示的取引では、ウェブ・アプリケーション・サーバ１２０のビジネス論理が、着信要求を処理し、クライアント・システム１０５の認証または識別あるいはその両方を提供する。クライアントが購入に進むことができるとウェブ・アプリケーション・サーバ１２０によって実装されたビジネス論理が判定すると、ウェブ・アプリケーション・サーバ１２０は、インベントリを減分するように、ネットワーク１２３を介してデータベース・サーバ１２５に別の要求を通信する。データベース・サーバ１２５は、要求を処理し、そのデータベース１３０にアクセスし、ウェブ・アプリケーション・サーバ１２０に対する応答を準備する。データベース・サーバの例には、限定はしないが、MicrosoftによってSQL/SERVERまたはTRANSACTION SERVERの商標の下で販売されているものや、IBMCorporationによってDB2 UNIVERSAL DATABASE SERVERの商標の下で販売されているものが含まれる。
【００６９】
ウェブ・アプリケーション・サーバ１２０は、データベース・サーバ１２５から応答を受信し、ネットワーク１１０を介してそれをクライアント・システム１０５に返す。次いでクライアント・システム１０５は、応答を処理してそれを表示用にフォーマットし、取引開始側が検討するように応答を提示する。
【００７０】
管理者１００は、サービス・プロバイダのサイトに位置する、ビジネス・トランザクションが処理される様々なソフトウェア構成要素およびハードウェア構成要素を観測し、それらが適切に機能しているかどうかを判定する。テーブル空間が破壊されたり、データベース実行時システムに障害が発生するなど、データベース１３０で停止１３５が発生した場合、管理者１００の仕事は、停止の原因の位置を突き止め、問題を正し、全システムが再び適切に機能しているかどうかを検証する。本発明はどんな形態の停止または性能低下でも動作するように意図されることを理解されたい。
【００７１】
管理者１００は、直接的に、またはソフトウェア構成要素およびハードウェア構成要素によって明確な管理インターフェースで公開される管理情報（ステータスやヘルス・データなど）を処理する管理システムを介して、ソフトウェア構成要素およびハードウェア構成要素と対話する。どちらの場合でも、ハードウェア構成要素およびソフトウェア構成要素が管理者によって分離した資源として認識され、特定のビジネス目的を処理するシステム全体の一部ではないことに留意されたい。
【００７２】
具体的には、管理者が、連続的監視が欠如しているために１つの構成要素で発生するエラーに気付かないためにエラーに留意しない可能性がある。加えて、本発明の技法がない場合、様々な構成要素間の相互依存関係に関する明示的情報が、管理者にとって直接的に入手不能である。したがって、継続的に監視されない構成要素内のエラーに、監視される構成要素に障害が伝播するまで留意しない可能性がある。
【００７３】
前述のデータベースが停止１３５した場合、管理者は、ウェブ・アプリケーション・サーバ１２０がもはや適切に機能していない（例えば、ウェブ・アプリケーション・サーバがデータベース・サーバ１２５に連続的に接続しようと試みるので、ウェブ・アプリケーション・サーバ上の負荷が劇的に増加し、クライアント・システム１０５が送信した要求を完了することができない）場合にしか停止に気付かない。したがって、管理者１００はまず、ウェブ・アプリケーション・サーバ１２０を検査し、次いでネットワーク１２３の接続性の問題が存在するかどうかを判定し、最後に、データベース・サーバ１２５がデータベース１３０の内部エラーに起因する問題を受けているかどうかを検証する。
【００７４】
前述のクライアント・サーバ・アプリケーション・アーキテクチャは、IBMCorporationが「自律型」コンピューティング環境と呼ぶ、台頭しつつあるコンピューティング環境の先触れとみなすことができる。ピー・ホーン(P.Horn)、「自律型コンピューティング：情報技術の現状に関するＩＢＭの展望(Autonomic Computing: IBM's Perspective onthe State of Information Technology)」、ＩＢＭリサーチ(IBM Research)、2001年10月（この開示は参照により本明細書に組み込まれる）は、自律型コンピューティングを、人間の介入が最小限である自己管理型コンピューティング・システムに対する包括的かつ全体観的手法と定義している。この用語は、意識または関与なしに主な機能を制御する人体の自律神経系に由来するものである。より具体的には、自律型コンピューティングの目標の１つは、通常は管理者１００が実施する作業の一部またはすべてを自動化することである。そのようにする動機付けは以下のようなものである。
【００７５】
コンピューティングが進化するにつれて、重複する接続、依存関係、および対話するアプリケーションは、どんな人間が送達できるよりも高速な管理意思決定および応答を求める。障害の根本原因を特定することがより難しくなると共に、システム効率を向上する方法を発見することは、どんな人間が解決することを望むことができるよりも多くの変数を有する問題を生み出す。自律型コンピューティング環境の異なるシステム間の依存関係を特定および追跡する問題は、以下のように特徴付けることができる。システムは多数のレベルで存在することができるので、自律型システムは、それ自体を管理するのに、その構成要素、現ステータス、最大容量、および他のシステムとのすべての接続の詳細な知識を必要とする。本発明を自律型コンピューティング環境で実施できることを当業者は理解されよう。
【００７６】
次に図２を参照すると、本発明の一実施形態による依存関係管理を実現するシステムがブロック図によって示されている。より具体的には、図２は、前述の問題に対処する依存関係管理システムを示す。このシステムは、４つの層（アプリケーション層２００、サービス層２０５、ミドルウェア層２１０、および資源層２１５）と、管理者１００がシステムと対話する管理者グラフィカル・ユーザ・インターフェース２８５とを有する。
【００７７】
最下層は資源層２１５である。資源層２１５は、管理資源２２０、資源依存関係リポジトリ２２５、およびリポジトリ・エージェント２３０を有する。管理資源２２０の例には、限定はしないが、物理／論理ハードウェア構成要素（前者の例はハード・ディスク、ランダム・アクセス・メモリ、中央演算処理装置、ネットワーク・アダプタ、チャネル・コントローラなどであり、後者の例はディスク・パーティション、ファイル・システムなどである）、ソフトウェア構成要素（オペレーティング・システム、プリント・スプーラや名前サービスなどのシステム・サービス、エンド・ユーザ・アプリケーションなど）が含まれる。
【００７８】
資源依存関係リポジトリ２２５は、管理されるあらゆる資源２２０のハードウェア／ソフトウェア構成要素のインベントリと、資源ごとの依存関係情報（すなわち、管理資源２２０内の構成要素間の依存関係）とを含む。資源依存関係リポジトリ２２５は、個々の管理資源２２０と共に配置することができ、または中央位置に常駐することができる。資源依存関係リポジトリ２２５は、リポジトリ・エージェント２３０を介して照会、更新、および修正することができる。リポジトリ・エージェント２３０は、資源依存関係リポジトリ２２５の情報をシステムの他の構成要素から利用可能にする。
【００７９】
ミドルウェア層２１０は、システムの様々な構成要素がそれによって（管理）情報を交換することができるプロトコルおよびオブジェクト要求ブローカなどの管理通信インフラストラクチャ２３５を含む。
【００８０】
サービス層２０５は、様々な管理アプリケーションによって使用することができるポリシー、イベント、ディレクトリなどの様々な汎用管理サービス２５０を含む。特に重要なサービスが依存関係サービス２４５であり、依存関係サービス２４５は、管理資源２２０とリポジトリ・エージェント２３０の両方から情報を取り出し、この情報を処理して、資源環境全体のエンドツーエンド依存関係モデルを確立する。このモデル（またはその部分）は、依存関係サービス２４５の必要（例えばより高速な検索のためのキャッシング）に従ってエンドツーエンド依存関係リポジトリ２４０に格納される。依存関係サービス２４５は、エンドツーエンド依存関係リポジトリ２４０と直接対話する記載のシステム内の唯一の構成要素であることに留意されたい。
【００８１】
上記で参照し、同時に出願した「Methods And Apparatus ForManaging Dependencies in Distributed Systems」という名称の整理番号YOR920020097US1で識別される米国特許出願で開示される技法に従って前述の依存関係モデルおよびその部分を生成することができることを理解されたい。その一部の例示的詳細を本明細書の以下で与える。しかし、他のモデル生成技法も利用することができる。
【００８２】
アプリケーション層２００は、汎用管理サービス２５０または依存関係サービス２４５あるいはその両方を使用する様々な管理アプリケーションを含む。そのような管理アプリケーションの例には、限定はしないが、障害マネージャ２６０、トポロジ・ジェネレータ２６５、インパクト・アナライザ２７０、インパクト・シミュレータ２７５、および根本原因アナライザ２８０が含まれる。
【００８３】
本明細書でさらに説明するが、根本原因アナライザ２８０は、（依存関係サービス２４５によって提供される）依存関係モデルの、停止によって影響を受ける構成要素からそのアンテシーデントへの走査に基づいて、停止根本原因（すなわち、最初に停止を引き起こした構成要素）を判定する。
【００８４】
インパクト・アナライザ２７０は、（依存関係サービス２４５によって提供される）依存関係モデルの、停止を受ける構成要素からそのディペンデントへの走査に基づいて、停止のインパクト（すなわち、停止によって影響を受ける可能性の高い構成要素）を判定する。インパクト・アナライザは、上記で参照し、同時に出願した「Methods And Apparatus For Impact Analysis and Problem Determination」という名称の整理番号SOM920020004US1で識別される米国特許出願で開示される技法を利用することができる。しかし他のインパクト分析技法も利用することができる。
【００８５】
インパクト・シミュレータ２７５は、インパクト・アナライザ２７０に基づいて、管理者１００が、システム全体に対する特定の構成要素の停止の効果をシミュレーションすることによって「what-if」分析を実施することを可能にする。これにより、適切なフェイルオーバ解決策を用意することが可能となる。インパクト・シミュレータは、上記で参照し、同時に出願した「MethodsAnd Apparatus For Dependency-based Impact Simulation and Vulnerability Analysis」という名称の整理番号SOM920020005US1で識別される米国特許出願で開示される技法を利用することができる。しかし、他のインパクト・シミュレーション技法も利用することができる。
【００８６】
障害マネージャ２６０は、根本原因アナライザ２８０またはインパクト・アナライザ２７０によって障害の候補として識別された構成要素に対する適切な「正常性チェック」またはテストを実施する。すなわち、障害マネージャは、根本原因アナライザ２８０またはインパクト・アナライザ２７０の方向にそのようなテストを実施することができ（すなわち、それらのモジュールに対するインターフェースとして働き）、結果をそれに対してレポートする。しかし、根本原因アナライザ２８０またはインパクト・アナライザ２７０は、障害マネージャとは無関係にそれ自体のテストを実施することができる。
【００８７】
障害マネージャは、テスト中の構成要素が適切に機能しているか否かについて判定を行うことを可能にするアプリケーション特有または資源特有のツールの集合からなることが好ましいことを理解されたい。したがって、関連ツールで構成要素をテストした後、障害マネージャは、構成要素が「機能している」か、それとも「機能していない」かを示すメッセージを返すことができる。こうしたツールは自動化することができ、または手動でよく、あるいはその両方でよい。自動化の一例として、いわゆる「ping」プログラムがネットワーク接続性をチェックする。サブジェクト・リモート・システムがpingに応答する場合、サブジェクト・リモート・システムはオンライン状態であり、そのネットワーク・プロトコル・スタック（およびすべての下にあるハードウェア、例えばネットワーク・アダプタ、ケーブル、中間ネットワーク構成要素など）が機能している。リモート・システムが応答しない場合、少なくとも何かに障害があることがわかり、別の（１組の）ツールを利用して問題を判定することができる。したがって、障害マネージャは、pingプログラム、ならびに分散コンピューティング環境の構成要素をテストするのに必要なその他の任意の数および任意のタイプのツール（例えばハートビート検出、ステータス表示など）を利用することができる。
【００８８】
トポロジ・ジェネレータ２６５は、ウェブ・アプリケーション、データベース・インスタンス、トランザクションなどの多数の非常に動的な構成要素を含む分散システムの全トポロジ（のサブセット）を確立する。トポロジ・ジェネレータ２６５の使用の一例は、特定のクライアント・システム１０５の要求を実行する際に関係する分散システムの構成要素を表示することである。依存関係モデル（またはその部分）が、トポロジ・ジェネレータ２６５の必要（例えば、より高速な検索のためのキャッシング）に従ってトポロジ・データベース２５５に格納される。トポロジ・ジェネレータ２６５は、トポロジ・データベース２５５と直接対話する記載のシステムでの唯一の構成要素であることに留意されたい。トポロジ・ジェネレータは、上記で参照し、同時に出願した「Methods And Apparatus For Topology Discovery and Representation ofDistributed Applications and Services」という名称の整理番号SOM920020003US1で識別される米国特許出願で開示される技法を利用することができる。しかし、その他のトポロジ生成技法も利用することができる。
【００８９】
次に図３を参照すると、図に示し、本明細書で詳細に説明する依存関係管理を提供するシステムの様々な機能構成要素／モジュールを実装するのに適したコンピュータ・システムの一般化ハードウェア・アーキテクチャを示すブロック図が示されている。依存関係管理システムの個々の構成要素、すなわちグラフィカル・ユーザ・インターフェース２８５、アプリケーション層２００、サービス層２０５、およびミドルウェア層２１０（図２）に関連する構成要素を、図３に示すアーキテクチャを有する１つまたは複数のコンピュータ・システム上に実装できることを理解されたい。図２に示す他の構成要素、例えば資源層２１５に関連する構成要素も同様のコンピュータ・システム上に実装することができる。
【００９０】
図示するように、プロセッサ２９０、メモリ２９２、およびＩ／Ｏ装置２９４に従ってコンピュータ・システムを実装することができる。本明細書で使用する「プロセッサ」という用語は、例えばＣＰＵ（中央演算処理装置）またはその他の処理回路あるいはその両方を含むものなど、どんな処理装置も含むように意図されることを理解されたい。本明細書で使用する「メモリ」という用語は、例えばＲＡＭ、ＲＯＭ、固定メモリ装置（例えばハード・ドライブ）、取外し可能メモリ装置（例えばディスケット）、フラッシュ・メモリなどの、プロセッサまたはＣＰＵに関連するメモリを含むように意図される。加えて、本明細書で使用する「入出力装置」または「Ｉ／Ｏ装置」という用語は、例えば、データを処理装置に入力する１つまたは複数の入力装置（例えばキーボード）、または処理装置に関連する結果を提示する１つまたは複数の出力装置（例えばＣＲＴディスプレイまたはプリンタあるいはその両方）を含むように意図される。
【００９１】
「プロセッサ」という用語は複数の処理装置と、他の処理装置によって共用することができる処理装置に関連する様々な要素とを指すことができることも理解されたい。
【００９２】
したがって、本明細書で説明する、本発明の方法を実施する命令またはコードを含むソフトウェア構成要素を、関連するメモリ装置（例えばＲＯＭ、固定メモリ、または取外し可能メモリ）のうち１つまたは複数に格納し、使用する準備が出来たとき、（例えばＲＡＭ内に）一部または全部をロードし、ＣＰＵで実行することができる。
【００９３】
次に図４を参照すると、本発明の一実施形態によるサービスの機能依存関係モデルがブロック図によって示されている。より具体的には、図４は、図１に示すようなものなどの電子商取引システム内の様々な構成要素間の機能アプリケーション依存関係グラフを示す。この機能依存関係モデルは、分散システムの機能構成要素とその依存関係を共に表す。したがって、このモデルは、ビジネスの観点からはアトミックとみなされる汎用サービス間の依存関係を定義する。これは、機能モデルはビジネス・サービス内で生じる依存関係とは無関係であることを示唆している。このような分解は、サービスを実施するのに使用される特定の製品の範囲内で意味をなし、図５を参照しながらより詳細に議論する。
【００９４】
構成要素間の依存関係を矢印として示す。矢印は常にディペンデントからアンテシーデントに向く。機能構成要素は、顧客にエンドツーエンド・サービスを提供するのにサービス・プロバイダが配置する必要がある（副）サービスである。エンドツーエンド・サービスは、サービス・レベル・アグリーメントで定義される。機能モデルはエンドツーエンド・サービスの設計に焦点を当て、サービス提供のために使用される製品、その位置（ローカル・システムまたはリモート・システム）、プロバイダ・ドメイン（すなわち、プロバイダ自体がそのサービスの一部を顧客に透過的な別のサービス・プロバイダにアウトソーシングしているかどうか）などのエンドツーエンド・サービスの技術的実現の詳細から抽象化する。
【００９５】
図示するように、ｅ−ビジネス・アプリケーション３００サービスは、ビジネス論理をホストするウェブ・アプリケーション・サービス３０５に依存する。適切に機能するためには、ウェブ・アプリケーション・サービス３０５は２つの別のサービスを必要とする。電子商取引ウェブサイトの静的コンテンツはウェブ・サービス３１０によって提供され、バックエンド・データベース・サービス３３０は、顧客に提供されるｅ−ビジネス・アプリケーション３００の動的コンテンツ（製品の説明、ユーザ／製造業者データ、ショッピング・カート、ユーザ・プロファイル／プリファレンス、支払情報など）を格納する。ウェブ・サービス３１０はそれ自体、２つのサービス、すなわちホスト名をＩＰアドレスにマッピングする名前サービス３１５と、ネットワーク接続性のためのＩＰサービス３２０とに依存する。
【００９６】
依存関係が推移的であること、すなわち所与の構成要素のディペンデントが、構成要素自体に加えて構成要素のアンテシーデントも必要とすることを想起されたい。したがって、ＩＰサービス３２０およびデータベース・サービス３３０に加えて、図示するサービスはすべて、オペレーティング・システム（ＯＳ）３２５サービスの存在を必要とする。図が見やすいように、ハードウェア構成要素上のＯＳ３２５の依存関係を図示していないが、それは機能モデル内に存在する。
【００９７】
次に図５を参照すると、本発明の一実施形態によるサービスの構造依存関係モデルがブロック図によって示されている。より具体的には、図５は、図１に示すようなものなどの電子商取引システム内の様々な構成要素間の構造アプリケーション依存関係グラフを示す。
【００９８】
この機能依存関係モデルは、機能モデル（図４）を以下のように拡張する。構造依存関係モデルは、ビジネス・サービスの実装を扱い、実際の製品およびその論理（モジュール、構成要素）ならびに物理的（ファイル、共用ライブラリ）アーキテクチャに焦点が当てられる。構造依存関係モデルは、ソフトウェア構成要素の詳細な説明、すなわちシステム・インベントリを取り込む。システム・インベントリは通常、様々なシステム・リポジトリまたは明確な場所、例えば管理資源２２０の構成ファイルに記録される。
【００９９】
機能モデルは単一システムの構成要素を扱うが、他のシステムによってホストされるサービスおよびアプリケーションに対する参照を維持することができる。システム上に位置する構成ファイルはこの情報を含むことができるからである。システム・リポジトリの例には、限定はしないが、IBM AIX Object Data Manager (ODM)、Linux Red Hat Package Manager(RPM)、またはMicrosoft Windows Registryが含まれる。ソフトウェア構成要素に関する情報は通常、ソフトウェア・パッケージのインストールおよび配置中に取り込まれる。加えて、構造モデルは、矢印で示される様々なシステム構成要素間の依存関係を含む。図が見やすいように、図５ではビジネス・サービスの名前を引用符なしで書き、構造モデルの要素の名前を引用符付きで書いた。
【０１００】
完全修飾ドメイン名wslab8.watson.ibm.com 400は、以下の構成要素をホストする。ストアフロント・サーブレット４１０として実装されるｅ−ビジネス・アプリケーション（機能モデルで定義されるビジネス・サービス）。ストアフロント・サーブレット４１０は、アプリケーションのビジネス論理をカプセル化する。ウェブ・アプリケーション・サービスは、IBMWebSphere version 3.5 415によって実装され、ウェブ・サービスはIBM HTTP Server version 1.3.6 420によって実現される。ＩＰサービスはデフォルトＩＰプロトコル・スタック４３０によって実装され、オペレーティング・システム（ＯＳ）はWin(dows)NT version 4 425である。
【０１０１】
完全修飾ドメイン名rslab2.watson.ibm.com 405は、以下の構成要素をホストする。(IBM)DB2 Universal Database (UDB) version 5.2 435によって実装されるデータベース・サービス、およびオペレーティング・システム（この場合は(IBM)Advanced Interactive Executive (AIX) version 4.3.3 440）。
【０１０２】
次に図６を参照すると、本発明の一実施形態による機能／構造／動作依存関係モデルによって対処されるサービス・ライフサイクルがブロック図によって示されている。より具体的には、図６は、前述の機能モデル５００と構造モデル５１０の間の関係を示し、第３の依存関係モデルである動作モデル５２０を導入する。こうした３つのモデルにより、本発明がサービスの全ライフサイクルの間、すなわち設計段階からインストール／配置段階、動作／実行時段階までサービスを追跡することが可能となる。
【０１０３】
前述のように、機能モデル５００は、ビジネス・サービスの設計に関係し、したがってビジネス・システムの設計時に取り込まれる。機能モデル５００によって記述されるシステムがインスタンス化および配置（ステップ５０５）された後、構造モデル５１０が確立される。構造モデル５１０の様々な構成要素がインスタンス化されたとき（ステップ５１５）、およびそれらの間の実行時バインディングが確立されたときに動作モデル５２０が作成される。動作モデルは、先に述べたモデルの実行時の特性を表す。次に、前述の概念を例示するいくつかのシナリオを説明する。
【０１０４】
ウェブ・アプリケーション・サービス３０５がIBM WebSphere 415によって実装される。IBMWebSphere 415の１つまたは複数のインスタンスはwebsphereデーモン５４５と呼ばれる。ここで、ウェブ（またはＷＷＷ）サービス３１０が２つの製品、すなわちApache1.3.4 525およびLotus Domino 530によって実装される。これらの製品の実行インスタンスはhttpデーモン「httpd」５５０として識別することができる。データベース・サービス３３０は、２つの製品、すなわちOraclev7 535およびDB2 UDB 435によって実装される。しかし、サーバ・プロセスが動作モデル５２０で可視であるので、Oracle v7 535のインスタンスはアクティブではない。対照的に、動作モデル５２０中のDB2デーモン「db2d」５５５の存在からわかるように、DB2UDB 435の４つのインスタンスは実行中である。名前サービス３１５はBIND version 5.6 540によって実装される。ＢＩＮＤの実行インスタンスは、動作モデル５２０中の「named」５６０として観測することができる。
【０１０５】
依存関係は機能から構造および動作モデルに伝播することに留意されたい。実行アプリケーション・インスタンスが適切に機能するように要求する他のアプリケーション・インスタンスがどれかを実行アプリケーション・インスタンスから判定することは不可能であるので、これは必要である。
【０１０６】
一部のアプリケーション・インスタンスが短命であるため、動作モデル５２０は非常に動的であり、潜在的に非常に大規模である。機能／構造依存関係モデルとは対照的に、動作モデル５２０はリポジトリまたはデータベースに格納されず、オンデマンドで必要な範囲で計算される。
【０１０７】
次に図７を参照すると、本発明の一実施形態による機能／構造／動作依存関係モデル間の関係がブロック図によって示されている。より具体的には、図７は、３つの依存関係モデルに対して使用されるデータ・テンプレートの詳細と、こうしたモデルを実施例によって結びつける手段とを示す。この実施例は、名前サービスのライフサイクル中に名前サービスを記述するためにテンプレートおよびその関連する値を詳述する。
【０１０８】
機能モデル５００に対して使用される機能テンプレート６０５は、「hostName」（サービスをホストするコンピュータ・システムの固有名）、「serviceName」（サービスの名前）、および「componentType」（このサービスが果たす役割、すなわちクライアントまたはサーバ）を含む。この情報を用いて、分散環境内でサービスを一意的に識別することができる。しかし、本発明の精神から逸脱することなく、記述データ（サービスの目的の説明、このサービスに加入する顧客など）を含む別のフィールドを追加することができる。最後に、「Antecedent」フィールドは、このサービスが適切に機能するのに必要なサービスを含む。
【０１０９】
構造モデル５１０に対して使用される構造テンプレート６１０は、機能テンプレート６０５のすべてのフィールドを含む。このフィールドにより、機能モデル５００から構造モデル５１０に、および構造モデル５１０から機能モデル５００にナビゲートするために、機能テンプレート６０５を機能テンプレート６１０とリンクすることが可能となる。加えて、テンプレート６１０は、「componentName」（製品構成要素の名前）、「identifier」（構成要素を識別する大域的に固有の名前）、「version」、「release」、および「modification」（例えばメンテナンスまたはパッチ／修正レベル）番号、「installState」（構成要素が首尾よく完全にインストールされたかどうかを示す）、および「processName」（実行時のこの製品の構成要素を識別するプロセス名）を含む。さらに「Antecedent」フィールドは、この構成要素が動作可能になるのに必要な構成要素をリストする。
【０１１０】
動作モデル５２０に対して使用される動作テンプレート６１５は、フィールド「hostName」（サービスをホストするコンピュータ・システムの固有名）および「processName」（実行時の製品構成要素を識別するプロセス名）を含む。こうした２つのフィールドは、構造モデル５１０から動作モデル５２０に、および動作モデル５２０から構造モデル５１０にナビゲートするために、構造テンプレート６１０を動作テンプレート６１５とリンクする。加えて、動作テンプレート６１５は、フィールド「operState」（プロセスの動作状態、すなわち実行中、中断、ゾンビなど）、「portNumber」（アプリケーションがそれによってプロセスに接続することができるＴＣＰ／ＵＤＰポート番号）、および「instanceID」（コンピュータ・システムの範囲内の様々なアプリケーション・インスタンスを識別する）を含む。
【０１１１】
３つの依存関係モデルは、最大の効率を達成するために異なる場所で格納および計算される。機能モデル５００は、管理システム６２０、すなわち管理者１００がそれによって分散環境と対話する中央制御点で収集および格納される。この選択の理由のいくつかは以下のようなものである。図４および図６の説明からわかるように、機能モデル５００は、可能なビジネス・サービスの量が限定されるので非常にコンパクトである。加えて、機能モデルは過度に頻繁な変更を受けない。機能モデルは、ビジネス・サービスが顧客に提供されるときに定義され、サービス提供期間が終了するまで不変である。管理者１００は機能モデル５００をセットアップおよび更新する任を担うので、機能モデル５００を管理システム６２０の近くに保つのは自然な選択である。
【０１１２】
図５および図６の説明で述べたように、対照的に構造モデル５１０は、ソフトウェア構成要素の詳細な説明、すなわちシステム・インベントリを取り込む。システム・インベントリは通常、様々なシステム・リポジトリまたは明確な場所、例えば管理資源２２０の構成ファイルに記録される。したがって、構造モデル５１０はサイズが大きく（システム・リポジトリの内容は数百キロバイトから最大数メガバイトになる傾向がある）、かつ頻繁な変更を受ける。したがって、管理資源２２０でシステムの構造モデル５１０を維持すること自体により、モデルを更新する通信オーバヘッドと、すべての管理資源（２２０）の構造モデル５１０が中央位置に格納された場合に生じる大量の記憶域の必要とが共に解消される。
【０１１３】
動作モデル５２０は潜在的に、分散環境のコンピュータ・システム上に存在するあらゆるアプリケーションの複数のインスタンスとそれらの間の依存関係をカバーするので、図６では動作モデル５２０を非常に動的であり、非常に大型であるものとして説明した。インターネット／アプリケーション／ストレージ・サービス・プロバイダおよびアウトソーサの現在のデータ・センタが１００近くのアプリケーションおよびシステム・サービスをそれぞれホストする数千のコンピュータ・システムからなることを考えると、現在インスタンス化されるアプリケーションとその依存関係すべてを含む動作モデルは現実的ではない。したがって、現実的な手法は、動作モデルの関連する部分をオンデマンドで計算することである（ステップ６２５）。これは依存関係サービス２４５の目的である。
【０１１４】
次に図８を参照すると、本発明の一実施形態による、動的情報技術（ＩＴ）サービス依存関係に基づいてサービス停止の根本原因を分析および計算することに関係する構成要素がブロック図に示されている。より具体的には、図８は、そのような根本原因を分析および計算するのに使用される様々な構成要素間のデータ・フローを示す。管理資源２２０は、そのシステム・インベントリ、構成ファイル、およびその様々な依存関係のXML(Extensible Markup Language)記述を提供できると仮定する。しかし、本発明に従ってどんなデータ記述フォーマットも使用できることに留意されたい。この情報をどのように取得することができるかに関する詳細を以下に示す。
【０１１５】
直接的な一方法は、システムおよびそのアプリケーションおよびサービス内に適切なインスツルメンテーションを提供することである。この情報は、フラットＸＭＬファイル７４０内に記述され、ウェブ・サーバ７２５を介してシステムの他の構成要素から利用可能にされる。
【０１１６】
あるいは、依存関係サービス２４５は、適切なサービス依存関係情報を生成するためにシステム・リポジトリ７４５に格納された情報を利用する。この情報は、ウェブ・サーバ７３０を介してシステムの他の構成要素から利用可能にされる。
【０１１７】
第３に、管理資源２２０は、ＣＩＭ（Common Information Model、これは標準化管理フレームワークである）プロバイダ７５０と呼ばれるインスツルメンテーション・エージェントによってその情報を公開する。ＣＩＭプロバイダ７５０は、DistributedManagement Task Force (DMTF)によって提案されるようにＣＩＭオブジェクト・マネージャ（ＣＩＭＯＭ）７３５と対話する。次いでＣＩＭＯＭは、必要な情報を関与する構成要素に公開する。
【０１１８】
図８の中央には、サービス層２０５の一部である様々な管理サービスが示されている。これらは、名前サービス７００、トレーダ・サービス７１０、イベント・サービス７１５、および依存関係サービス２４５である。依存関係サービス２４５は、通信プロトコル（例えばJavaリモート・メソッド呼出し（ＲＭＩ）を使用するアプリケーション層２００に位置する根本原因アナライザ２８０、その管理システム、または任意の管理アプリケーションを介する管理者１００の照会によって起動され、それらを処理し、結果を根本原因アナライザ２８０に送り戻し、根本原因アナライザ２８０は、その結果を後の処理のために管理者１００に転送する。依存関係サービス２４５の主な役割は以下の通りである。
（ａ）アプリケーション層２００に位置する管理システムまたは任意の管理アプリケーションと対話する。管理システムは、依存関係サービス（２４５）のアプリケーション・プログラミング・インターフェース（ＡＰＩ）に照会を発行する。
（ｂ）「ドリルダウン」メソッドを公開する。ドリルダウン・メソッドは、サービスの識別子を受信した際に、
（ｉ）その直接のアンテシーデントの記述、すなわちサービスを表すノードの下の第１レベル、
（ｉｉ）サービスを表すノードの下のサブグラフ全体、または
（ｉｉｉ）依存関係グラフの任意のサブセット（所与のノードの下のレベルｍからｎ）を返す。
（ｃ）サービスのディペンデントを対象とする、同じ機構を有する「ドリルアップ」メソッドを提供する。
（ｄ）管理オブジェクトのクラスおよびプロパティについての情報を収集およびフィルタする追加のメソッドが存在する。
（ｅ）http（ハイパーテキスト・トランスポート・プロトコル）を介して照会を発行し、それに（管理者１００によって指定される）フィルタリング規則を適用することにより、管理資源２２０から依存関係情報を得る。
（ｆ）この情報を、管理システムにＸＭＬ文書として送り戻されるデータ構造と組み合わせる。
【０１１９】
前述のように、本発明の完全に分散型の性質により、本発明は、起動されるあらゆるシステムを可能な限り低く維持することを目標とする。本発明は、管理資源２２０から管理システムを分離し、依存関係サービス２４５での時間のかかるフィルタ／結合操作をカプセル化し、それを様々なシステム上に複写することができる。したがって、依存関係サービス２４５のインスタンスの選択を管理システムによってフレキシブルに行うことができるので、照会操作について最大レベルの並列処理を達成することが可能である。
【０１２０】
別の重要な利点は、（非常に大規模かつ非常に動的な）動作モデル５２０が特定の場所に格納されず、段階的にオンデマンドで計算されることである。構造モデル５１０の異なる部分が管理資源２２０で格納される。したがって管理システムは常に最新の情報を受信するが、それでもなお、綿密なキャシング・ポリシーに従って自由にそれを格納する。
【０１２１】
次に図９を参照すると、本発明の一実施形態による根本原因アナライザの構成要素がブロック図によって示されている。図示するように、根本原因相関器８７０は、根本原因分析プロセス全体のフロー・コーディネータとして機能し、問題が観測され、または報告されたサービス名およびホスト名を与える管理者１００からサービス問題レポート８８０を受け取る。根本原因相関器８７０は、問題のあるサービスが依存する基本サービスのリストを得るために依存関係サービス２４５と対話する。基本サービスの例はドメイン名サービス、ＩＰ接続性サービスなどである。
【０１２２】
依存関係サービス２４５の役割は、ｅ−コマース環境が様々な管理ドメイン８００にまたがっている場合であっても、問題のサービスのアンテシーデントを見つけることである。複数のドメインを扱うために、依存関係サービス２４５の様々な（カスケード式）インスタンスが共に働くことができる。図９では、ｅ−コマース環境が点線の長方形で示されている。通常、このような環境は、最終的にそれ自体の依存関係データベース８１０および依存関係サービス２４５をそれぞれ有する１つまたは複数の管理ドメインを含む。依存関係サービス２４５は、根本原因相関器８７０にアンテシーデントの名前および識別子を返し、次いで根本原因相関器８７０は別の問題判定手順を開始して、１つまたは複数のアンテシーデントが障害を受けているかどうかを検証する。これは、いくつかの手法を介して実施することができ、そのいくつかを以下で示す。
【０１２３】
第１の手法は、イベント・モニタ８２０によって提供されるイベント監視／配布機能の存在を仮定する。このようなイベント・モニタの例には、限定はしないが、HP OpenView Event ServiceやTivoli Enterprise Consoleが含まれる。イベント・モニタ８２０は、e-commerce環境内の資源に関係するイベント／警報を受け取り、イベント・データベース８３０に関連するものを転送する。一部のイベントは情報的な性質のものであり、またはドメイン管理サービスによって自動的に修正されるエラーに関係する。これらは通常は取り除かれ、イベント・データベース８３０には転送されない。実際には、イベント・モニタ８２０は、各管理ドメインごとに１つの複数のイベント・モニタの階層型構成から構成することができる。
【０１２４】
イベント・サービス相関器８４０の主な機能は、所与のサービスまたは資源に対して、その資源またはサービスに関連する顕著な警報のリストを提供することである。イベント・サービス相関器８４０は、イベント・モニタ８２０と対話して、後の検索のためにイベントをイベント・データベース８３０に格納することによってそれを行う。依存関係サービス２４５によって返されるサービスが疑われる根本原因の１つであるとき、根本原因相関器８７０は、イベント・サービス相関器８４０を使用して、疑われるサービスまたは資源について報告された可能性のあるイベントのリストを取得することにより、これがそうである尤度を推定する。望ましくないイベント、例えばバッファ・オーバーフローが存在する場合、この資源が根本原因である尤度は高い。
【０１２５】
根本原因相関器８７０はまた、ドメイン内にある１組の可能な根本原因を得るために、各管理ドメインについての依存関係サービス２４５と対話する。依存関係サービス２４５はドメイン依存関係データ８１０と対話する。ドメイン依存関係データ８１０は、配置中に構築され、ｅコマース・セットアップの動作段階中に周期的に更新される。
【０１２６】
第２の手法は、ステータス・モニタ８６０からサービスまたは資源の現ステータスを得ることである。ステータス・モニタ８６０は、サービスと直接対話し、サービスが適切に機能しているか否か（例えば、障害発生、障害なし、性能低下）を検証する。上述のように、システムが（図２のシステムと同様に）障害マネージャを組み込む場合、ステータス・モニタは、根本原因アナライザと障害マネージャの間のインターフェースとして働くことができ、それによって、他の利点の中でもとりわけ、根本原因アナライザがどんな特定のテスト手順とも無関係にされる。したがってステータス・モニタ８６０は、根本原因相関器８７０が問題のサービスのヘルスを判定する単一の接点として働くことができる。
【０１２７】
一般には、外部障害マネージャが常に利用可能であると仮定することはできない。しかし、サービスのステータスを判定する機能は根本原因アナライザにとって重要であるので、この機能は存在しなければならず、ステータス・モニタ８６０によって提供される。ステータス・モニタ８６０は、障害マネージャによって提供される機能を拡張することができる。したがって、外部障害マネージャは以下のいずれかを提供することができる。
（ａ）必要なすべての機能（すなわち、ステータス・マネージャは障害マネージャによって実施される機能を「ラップ」し、根本原因相関器８７０が予期するものにインターフェースを適応させる）。
（ｂ）機能の一部だけ（例えば、ネットワーク接続性のテストだけで、アプリケーションおよびミドルウェア・ステータス検証は行わない）、すなわち必要な機能をステータス・モニタによって提供しなければならない。または
（ｃ）機能なし。存在しないか、またはプログラマティック・インターフェースを介してその機能を他の構成要素に提供しない。したがって、人間のユーザがＧＵＩ（グラフィカル・ユーザ・インターフェース）を介して障害マネージャと対話する間、プログラム（相関器８７０など）はそれを使用することができない。
【０１２８】
障害マネージャは、完全に異なるインターフェースを有するシステム管理ツールのルーズな集合を指すことを意味することにも留意されたい。したがってステータス・モニタは、統一インターフェース下でこうした様々なツールを統合する働きをする。すなわち、ステータス・モニタは、ステータスに関してあらゆるものをテスト可能であると予期する根本原因相関器と、この必要な機能の０パーセントから１００パーセントの間で提供することができる障害マネージャとの間の何らかの不整合を調節するように動作することが好ましい。
【０１２９】
したがって根本原因相関器８７０は、サービスが適切に機能しているか、それとも問題を受けているかを判定する２つの方法を有する。すなわち、相関器は、サービスに関する問題イベント・レポートを求めてイベント・サービス相関器８４０に照会することができ、またはステータス・モニタ８６０からサービスのステータスを直接ルックアップすることができる。根本原因相関器８７０は、サービスのヘルスを判定する少なくとも２つの手段のどれを選ぶか自由である。さらに、根本原因相関器８７０は、イベント・サービス相関器８４０とステータス・モニタ８６０の両方から情報を得ることを選ぶこともできる。
【０１３０】
根本原因が、可能性のある最小のサービスおよび資源のセットまで狭められた後、根本原因相関器８７０は、この情報８９０を管理者１００に返す。
【０１３１】
次に図１０を参照すると、本発明の一実施形態による、依存関係サービスを起動し、動作モデルに関する根本原因分析を実施するステップが流れ図によって示されている。より具体的には、図１０は、依存関係サービス（例えば依存関係サービス２４５）を起動し、その結果を収集し、それに対して根本原因分析を適用する方法を示す。この方法は、管理者１００、あるいは図２で説明したアプリケーション層２００の一部である管理アプリケーションによって開始される。
【０１３２】
この方法はブロック９００で開始し、次のように進む。まず、管理者は分散システムで提供されるビジネス・サービスに関心があるので、ビジネス・サービスを通常は機能モデルから選択する（ステップ９０５）。ビジネス・サービスの選択時に、ビジネス・サービスの提供に関係するホストの選択肢を提供するように構造モデルに照会する。このことは、分散システム上のホストごとに存在する構造モデルの位置を突き止めることにより、または（効率のために）分散システム内に存在するサービスとホストの間のマッピングを含む、管理システムに格納される（周期的に更新される）サービス／ホスト・ルックアップ・テーブルに照会することによって行うことができる。次いで、管理者は自分の裁量でホストを選択する（ステップ９１０）。
【０１３３】
加えて、管理者は照会を構成する（ステップ９１５）。照会パラメータの例には、限定はしないが、（サービス・ディペンデントまたはそのアンテシーデントに向かう）走査方向、走査の深さ（例えば、直接のアンテシーデント／ディペンデントだけ、可能性のある全アンテシーデント／ディペンデント、すなわち動作モデルの完全なトランシティブ・クロージャ、動作モデルのｍ番目の層とｎ番目の層の間だけ）、属性の存在またはその値に関するフィルタリング基準が含まれる。
【０１３４】
サービスを選択するステップ（ステップ９０５）、ホストを選択するステップ（ステップ９１０）、および照会を構成するオプションを選択するステップの順序をここで規定したことは、（既存記述の「ホスト中心」手法に対して）本発明の「サービス中心」手法を強調するものである。しかし、本発明の精神および範囲から逸脱することなく、ステップ（ステップ９０５、９１０、および９１５）の順序の変更を行えることを関連技術分野の技術者は理解されよう。
【０１３５】
このような変更の例は、（グラフィカル・ユーザ・インターフェースによって）任意の順序で選択プロセスの３つのステップを実施する選択肢をユーザに提供すること、まずホストの選択を可能にし、次いで構造モデルに照会することによってホスト上に存在するサービスをルックアップし、それによって選択に関する可能性のあるサービス候補を制限することである。
【０１３６】
照会のサービスおよびホストの選択および構成の後、これらのパラメータで依存関係サービスを起動する（ステップ９２０）。呼出しのモードは同期式（すなわち、結果が依存関係サービスに返されるまで起動側をブロックすること）または非同期式（すなわち、計算中に起動側が追加のタスクを実施することを可能にすること）でよいことに留意されたい。
【０１３７】
依存関係サービスは、動作モデルの適切な部分を計算し、呼出しのモードに応じて、起動側に結果を送り戻し、または結果が利用可能であることを起動側に通知する。次いで、起動側は結果を収集し、それに対して根本原因分析および適切な問題判定手順を適用する（ステップ９２５）。この方法はブロック９３０で終了する。
【０１３８】
次に図１１を参照すると、本発明の一実施形態による、機能依存関係モデルを作成および更新する管理者の作業が流れ図によって示されている。これは、新しい（ビジネス）サービスが配置および提供された場合、または既存のモデルに変更が適用された場合、または既存の（ビジネス）サービスが提供から取り去られた場合に必要である。
【０１３９】
この方法はブロック１０００で開始し、以下のように進む。管理者または管理アプリケーションが、新しいビジネス・サービスを追加すべきか、または既存のサービスを削除すべきかどうかを評価する（ステップ１００５）。これが不要である場合、この方法はブロック１０２５に直接進む。そうでない場合、ステップ１０１０では、サービスおよびその説明を、図７で説明した機能モデルのテンプレート６０５に入力する（またはテンプレート６０５から削除する）。
【０１４０】
次いで、ステップ１０１５では、サービス依存関係、すなわちそのアンテシーデントに関するその関係を、機能モデルのテンプレート６０５に追加する（またはテンプレート６０５から削除する）必要がある。削除の場合、サービス・ディペンデントからの依存関係を、削除すべきサービスのアンテシーデントを指すように調節する必要がある。このことは、アンテシーデントの依存関係内の偶発的な重複する記述をチェックすることを含むことができる。最後に、更新後機能モデルを管理システムのリポジトリに格納する（ステップ１０２０）。この方法はブロック１０２５で終了する。
【０１４１】
次に図１２を参照すると、本発明の一実施形態による、コンピュータ・システム上にハードウェア／ソフトウェア構成要素をインストールまたは除去することによって構造依存関係モデルを更新するステップが流れ図によって示されている。これは、新しい構成要素がホスト上に配置およびインストールされた場合、または既存の構成要素がホストから除去された場合に必要である。
【０１４２】
この方法はブロック１１００で始まり、以下のように進む。新しいハードウェア構成要素がインストール／除去された場合、その依存関係の検証および調節が通常はオペレーション・システムによって実施され、したがってここではさらに説明しない。その代わりに、以下の説明では、ソフトウェア構成要素を追加／除去する作業に焦点を当てる。管理者、またはソフトウェア配布／インストールを実施する管理アプリケーションが、新しいソフトウェア構成要素を追加すべきか、または既存のソフトウェア構成要素を削除すべきかどうかを評価する（ステップ１１０５）。これが不要である場合、この方法はブロック１１２５に直接進む。そうでない場合、ステップ１１１０では、ソフトウェア構成要素の説明を、図７で説明した機能モデルのテンプレート６１０に入力する（またはテンプレート６１０から削除する）。次いで、ステップ１１１５では、ソフトウェア構成要素の依存関係、すなわちそのアンテシーデントに関するその関係を、機能モデルのテンプレート６１０に追加する（またはテンプレート６１０から削除する）必要がある。
【０１４３】
削除の場合、ソフトウェア構成要素のディペンデントからの依存関係を、削除すべきソフトウェア構成要素のアンテシーデントを指すように調節する必要がある。このことは、アンテシーデントの依存関係内の偶発的な重複する記述をチェックすることを含むことができる。最後に、更新後機能モデルをホストの資源依存関係リポジトリに格納する（ステップ１１２０）。この方法はブロック１１２５で終了する。
【０１４４】
次に図１３を参照すると、本発明の一実施形態による動作モデルに関する根本原因分析の性能が流れ図によって示されている。この方法はブロック１２００で開始し、以下のように進む。動作依存関係モデルに関する根本原因分析を実施するシステムが、システムを実行中のホストの特定のポートで要求を連続的にリスンしており、このことを、ステップ１２０５をそれ自体と接続するループで示す。これは、アプリケーションによっていつでも起動することができるサービスを実施するサーバ・プロセスに関する標準的挙動（「デーモン」）である。
【０１４５】
要求の受信時に、システムは、要求から入力パラメータを抽出する（ステップ１２１０）。図１０の説明で述べたように、入力パラメータの例には、限定はしないが、当該のサービス名およびホスト名、走査の方向、走査の深さ、属性の存在またはその値に関するフィルタリング基準が含まれる。次いでこうした入力パラメータを使用して動作モデルの計算を起動する。動作モデルの計算はステップ１２１５で起動される。
【０１４６】
加えて、計算すなわち動作モデルの結果を収集する。次いで、動作モデルに関して根本原因分析を実施する（ステップ１２２０）。呼出し時に指定された呼出しのモードに従って、根本原因分析の結果を起動側アプリケーションに返す（ステップ１２２５）。このステップの後、システムを実行中のホストの割り当てられた任意の資源が解放される（ステップ１２３０）。ホスト資源の例には、限定はしないが、メモリ、ディスク・スペース、またはＣＰＵレジスタが含まれる。最後に、システムはその最初のステージに戻り、後続の着信要求をリスンする（ステップ１２０５に戻る）。
【０１４７】
次に図１４を参照すると、本発明の一実施形態によるサービスのアンテシーデントに関する根本原因分析の性能が流れ図によって示されている。この方法はブロック１３００で開始し、次のように進む。
【０１４８】
まず、対象のサービスおよびホストの名前を得る（ステップ１３０５）。こうしたパラメータが起動側管理アプリケーションによって提供され、起動側管理アプリケーションは、管理者から直接に、または管理コンソールに到達したイベント・メッセージからこうしたパラメータを得る。加えて、アンテシーデントのステータスによる探索基準を指定する。これは、システムが問題（「欠陥」）に直面しているサービスを返すべきか、それとも良好に動作しているサービスを返すべきかを示す。通常、管理アプリケーションは、前者すなわち欠陥のあるサービスに関心がある。さらに、探索経路を指定する。管理アプリケーションは、サービスの直接のアンテシーデント（探索経路長＝１）、サービスが直接（または間接的に）依存する全サービス（探索経路長＝反復的）、またはアンテシーデントの最低レベルすなわちサービスが依存するベース・サービス（探索経路長＝最大）に関心がある可能性がある。
【０１４９】
次いで、パラメータ「Service Name」、「Host Name」、「Antecedentstatus」、「search path」により、依存関係サービスによって動作モデルの計算を実施する（ステップ１３１０）。次にステップ１３１５では、結果すなわちアンテシーデント・サービス要素のリスト（「CandidateList」）を依存関係サービスから得る。
【０１５０】
候補サービス要素のリストが空になるまで（１３２０）以下のステップを実施する。
【０１５１】
候補リストの第１サービス要素を選択し（ステップ１３２５）、適切に機能しているかどうかチェックする（ステップ１３３０）。このステータス・チェック手順のステップを図１５で詳細に説明する。当該のサービス要素が適切に機能している場合（status=「OK」）、それを作動サービス要素のリスト、すなわち「ＯＫ」リストに追加する（ステップ１３３５）。しかし、サービス要素が問題を受けていることが判明した場合、それを「欠陥」リストに追加する（ステップ１３４０）。最後に、当該のサービス要素を候補サービス要素リストから除去し（ステップ１３４５）、この方法はブロック・ステップ１３２０に戻る。
【０１５２】
候補サービス要素のリストが空である場合、この方法はステップ１３５０に直接進み、作動サービス要素のリストまたは欠陥サービス要素のリストを起動側に返す。結果の内容は、起動側がステップ１３０５で作動サービスを求めているのか、それとも欠陥サービスを求めているのかに依存する。この方法はブロック１３５５で終了する。
【０１５３】
次に図１５を参照すると、本発明の一実施形態によるサービスのステータスを判定するステップが流れ図によって示されている。より具体的には、図１５は、図９に示す根本原因相関器８７０とイベント・サービス相関器８４０およびステータス・モニタ８６０との対話を示す。この方法はブロック１４００で始まり、以下のように進む。
【０１５４】
まず、対象のサービス要素の名前を得る（ステップ１４０５）。根本原因相関器８７０によって行うことのできる単一サービス要素のステータスのチェックという観点から、この問題判定手順を説明する。この手順は問題のサービスごとに反復されることを理解されたい。この手順は図１４のステップ１３３０で実施されることをさらに理解されたい。
【０１５５】
さらに、ステップ１４０５に関して、対象のサービス要素の名前が起動側管理アプリケーションによって提供され、起動側管理アプリケーションは、管理者から直接に、または管理コンソールに到達したイベント・メッセージからこうしたパラメータを得る。
【０１５６】
次いで、根本原因相関器８７０は、問題のサービスに関するイベントの存在に関してイベント・サービス相関器８４０に照会する（ステップ１４１０）。こうしたイベントは、このサービスに伴う何らかの問題が観測されたかどうかを示す。これが事実である場合、サービス要素に「欠陥」とフラグを付け（ステップ１４１５）、結果を起動側に返す（ステップ１４３０）。
【０１５７】
ステップ１４１０でこのサービスについて障害イベントが発生していない場合、サービスのステータスを判定するために別の作業を実施することが必要である。このことを、サービスのステータスに関してステータス・モニタ８６０に照会することによって行う（ステップ１４２０）。ステータス・モニタ８６０の作業は、サービスのステータスがどのように判定されるかにかかわらず、分散システム内のあらゆるサービスについての状況情報に対する一様なインターフェースを提供する。
【０１５８】
前述のように、サービスのステータスを判定する４つの例示的方法は、（ｉ）プロセス検査、（ｉｉ）エクササイザ、（ｉｉｉ）ハートビート、および（ｉｖ）ステータス・インジケータを含むことができる。ステータス・モニタ８６０に対する照会（ステップ１４２０）により、当該のサービスが適切に機能している（ステータス＝「ＯＫ」）が得られた場合、サービスを表すサービス要素に「ＯＫ」とフラグを付ける（ステップ１４２５）。いずれの場合も、結果を起動側に返す（ステップ１４３０）。この方法はブロック１４３５で終了する。
【０１５９】
次に図１６を参照すると、本発明の一実施形態による根本原因アナライザ・アプリケーション・プログラミング・インターフェース（ＡＰＩ）の例が示されている。この表は、所与のサービス名およびホスト名についての適切な動作モデルの受信を生成、送信、および要求することができるベースＡＰＩを含む。ＡＰＩは１つまたは複数のパラメータ（図示せず）を使用してＡＰＩが使用する（機能説明で指定される）特性を識別できることを当業者は理解されよう。
【０１６０】
具体的には、「getDirectAntecedents(parameters)」ＡＰＩが、特定のホスト上に位置するサービスの直接のアンテシーデントを、その現ステータスの如何にかかわらず取り出す。「getAntecedentsRecursive(parameters)」ＡＰＩは反復的「ドリルダウン」を実施する。すなわち、「getAntecedentsRecursive(parameters)」ＡＰＩは、特定のホスト上に位置する所与のサービスのすべてのアンテシーデントを（その現ステータスの如何にかかわらず）取り出す。したがって、「getAntecedentsRecursive(parameters)」ＡＰＩは依存関係階層内の所与のサービス「より下に」あるすべてのサービスを返す。「getLowestAntecedents(parameters)」ＡＰＩは、特定のホスト上に位置するサービスの最低のアンテシーデントを取り出す。このメソッドにより、それ自体はアンテシーデントを有さない（すなわち所与のサービスの依存関係階層の最下層にある）サービスが得られる。
【０１６１】
「getWorkingDirectAntecedents(parameters)」ＡＰＩは、特定のホスト上に位置するサービスの、ステータス「up」を有する直接のアンテシーデントを取り出す。「getWorkingAntecedentsRecursive(parameters)」ＡＰＩは反復的「ドリルダウン」を実施する。すなわち、「getWorkingAntecedentsRecursive(parameters)」ＡＰＩは、特定のホスト上に位置する所与のサービスの、ステータス「up」を有するすべてのアンテシーデントを取り出す。したがって、「getWorkingAntecedentsRecursive(parameters)」ＡＰＩは、依存関係階層内の所与のサービス「より下に」あるすべての作動サービスを返す。「getWorkingLowestAntecedents(parameters)」ＡＰＩは、特定のホスト上に位置するサービスの、ステータス「up」を有する最低のアンテシーデントを取り出す。このメソッドにより、それ自体はアンテシーデントを有さない（すなわち所与のサービスの依存関係階層の最下層にある）サービスが得られる。
【０１６２】
「getDefectiveDirectAntecedents(parameters)」ＡＰＩは、特定のホスト上に位置するサービスの、ステータス「down」を有する直接のアンテシーデントを取り出す。「getDefectiveAntecedentsRecursive(parameters)」ＡＰＩは反復的「ドリルダウン」を実施する。すなわち、「getDefectiveAntecedentsRecursive(parameters)」ＡＰＩは、特定のホスト上に位置する所与のサービスの、ステータス「down」を有するすべてのアンテシーデントを取り出す。したがって、「getDefectiveAntecedentsRecursive(parameters)」ＡＰＩは、依存関係階層内の所与のサービス「より下に」あるすべての障害サービスを返す。「getDefectiveLowestAntecedents(parameters)」ＡＰＩは、特定のホスト上に位置するサービスの、ステータス「down」を有する最低のアンテシーデントを取り出す。このメソッドにより、それ自体はアンテシーデントを有さない（すなわち所与のサービスの依存関係階層の最下層にある）サービスが得られる。このＡＰＩは、何らかの「基本」サービス（例えばネットワーク接続性サービス）に障害が発生したかどうかを「中間」サービス（名前サービスなど）のステータスを検証する必要なしにユーザまたは管理アプリケーションが直ちに判定したい場合に特に有用である。
【０１６３】
本明細書で添付の図面を参照しながら本発明の例示的実施形態を説明したが、本発明がこのような厳密な実施形態に限定されず、本発明の範囲および精神から逸脱することなく当業者が様々な他の変更および修正を行えることを理解されたい。
【図面の簡単な説明】
【０１６４】
【図１】本発明の機能がそれと対話して情報を生成することができるクライアント・サーバ・アプリケーション・アーキテクチャの一例を示すブロック図である。
【図２】本発明の一実施形態による依存関係管理を実現するシステムを示すブロック図である。
【図３】本発明の一実施形態による依存関係管理を実現するシステムを実装するのにコンピュータ・システムの一般化ハードウェア・アーキテクチャを示すブロック図である。
【図４】本発明の一実施形態によるサービスの機能依存関係モデルを示すブロック図である。
【図５】本発明の一実施形態によるサービスの構造依存関係モデルを示すブロック図である。
【図６】本発明の一実施形態による機能／構造／動作依存関係モデルによって対処されるサービス・ライフサイクルを示すブロック図である。
【図７】本発明の一実施形態による機能／構造／動作依存関係モデル間の関係を示すブロック図である。
【図８】本発明の一実施形態によるサービス停止の根本原因を分析および計算することに関係する構成要素を示すブロック図である。
【図９】本発明の一実施形態による根本原因アナライザの構成要素を示すブロック図である。
【図１０】本発明の一実施形態による、依存関係サービスを起動し、動作モデルに関する根本原因分析を実施するステップを示す流れ図である。
【図１１】本発明の一実施形態による、機能依存関係モデルを作成および更新する管理者の作業を示す流れ図である。
【図１２】本発明の一実施形態による、コンピュータ・システム上にハードウェア／ソフトウェア構成要素をインストールまたは除去することによって構造依存関係モデルを更新するステップを示す流れ図である。
【図１３】本発明の一実施形態による動作モデルに関する根本原因分析の性能を示す流れ図である。
【図１４】本発明の一実施形態によるサービスのアンテシーデントに関する根本原因分析の性能を示す流れ図である。
【図１５】本発明の一実施形態によるサービスのステータスを判定するステップを示す流れ図である。
【図１６】本発明の一実施形態による根本原因アナライザ・アプリケーション・プログラミング・インターフェースの例を示す図である。
【図１】
2005538459.tif 000003
【図２】
2005538459.tif 000004
【図３】
2005538459.tif 000005
【図４】
2005538459.tif 000006
【図５】
2005538459.tif 000007
【図６】
2005538459.tif 000008
【図７】
2005538459.tif 000009
【図８】
2005538459.tif 000010
【図９】
2005538459.tif 000011
【図１０】
2005538459.tif 000012
【図１１】
2005538459.tif 000013
【図１２】
2005538459.tif 000014
【図１３】
2005538459.tif 000015
【図１４】
2005538459.tif 000016
【図１５】
2005538459.tif 000017
【図１６】
2005538459.tif 000018
【国際調査報告】
2005538459.tif 000019
2005538459.tif 000020
2005538459.tif 000021