(57)【要約】　【課題】　コンピューティング環境の様々なコンポーネント間で依存性情報を管理するための技法を提供する。　【解決手段】　コンピューティング環境のコンポーネントに関連した情報を取得する。次いで、取得した情報の少なくとも一部から、コンピューティング環境のコンポーネントの少なくとも一部に関連した１つ以上の関係の存在を判定する。１つ以上の関係の存在の判定は、コンピューティング環境の少なくとも１つのコンポーネントに関連した全ライフサイクル（例えば、展開、インストール、および実行時）を考慮に入れることができる。このように、コンピューティングシステムの様々なコンポーネント間で実行時依存性を管理するための技法が開示され、これは、個々のシステムをあるレベルで抽象化し、カスタマが認知するような、終端間サービスに関連したサービス／コンポーネントの依存性の計算を可能とする。【選択図】　図１
2004103015.tif 000002
【特許請求の範囲】
【請求項１】
コンピューティング環境において情報を管理するコンピュータを用いた方法であって、
　前記コンピューティング環境のコンポーネントに関連した情報を取得するステップと、
　前記取得した情報の少なくとも一部から、前記コンピューティング環境の前記コンポーネントの少なくとも一部に関連した１つ以上の関係の存在を判定するステップと、を具備し、前記１つ以上の関係の存在を判定するステップは、前記コンピューティング環境の少なくとも１つのコンポーネントに関連した全ライフサイクルを考慮に入れることができることを特徴とする、方法。
【請求項２】
前記コンピューティング環境は分散型コンピューティング環境から成ることを特徴とする、請求項１の方法。
【請求項３】
前記コンピューティング環境は自律型コンピューティング環境から成ることを特徴とする、請求項１の方法。
【請求項４】
前記コンピューティング環境の前記コンポーネントの少なくとも一部に関連した１つ以上の関係の存在を判定するステップは、更に、前記コンピューティング環境の少なくとも２つのコンポーネントに関連した異質性を考慮することができることを特徴とする、請求項１の方法。
【請求項５】
前記コンピューティング環境の前記コンポーネントの少なくとも一部に関連した１つ以上の関係の存在を判定するステップは、更に、前記コンピューティング環境に関連した１つ以上のドメインに及ぶ１つ以上のコンポーネントを考慮することができることを特徴とする、請求項１の方法。
【請求項６】
前記コンピューティング環境の前記コンポーネントの少なくとも一部に関連した１つ以上の関係の存在を判定するステップは、更に、機能カテゴリ分類、構造カテゴリ分類、および動作カテゴリ分類から成る形態でコンポーネント依存性を計算することを含むことを特徴とする、請求項１の方法。
【請求項７】
前記コンポーネント依存性の前記機能カテゴリ分類は、ノードのグラフとしてモデル化された機能要素を備え、１つ以上の第１のノードは、該１つ以上の第１のノードが依存する１つ以上の第２のノードにリンクされ、更に、前記１つ以上の第１のノードに依存する１つ以上の第３のノードにリンクされていることを特徴とする、請求項６の方法。
【請求項８】
前記ノードは前記コンピューティング環境におけるコンポーネントを表すことを特徴とする、請求項７の方法。
【請求項９】
前記コンポーネントは少なくとも１つの依存者および先行者として規定されることを特徴とする、請求項８の方法。
【請求項１０】
前記ノードのグラフはノード間のリンクを含み、前記リンクは依存性を表すことを特徴とする、請求項９の方法。
【請求項１１】
前記依存性は、依存者および先行者を含む１対１の関係であることを特徴とする、請求項１０の方法。
【請求項１２】
前記機能要素は、前記構造カテゴリ分類における構造要素とリンクされたものおよび相互参照されたものの１つである、請求項７の方法。
【請求項１３】
前記コンポーネント依存性の前記構造カテゴリ分類は、ノードのグラフとしてモデル化された構造要素を備え、１つ以上の第１のノードは、該１つ以上の第１のノードが依存する１つ以上の第２のノードにリンクされ、更に、前記１つ以上の第１のノードに依存する１つ以上の第３のノードにリンクされていることを特徴とする、請求項６の方法。
【請求項１４】
前記構造要素は、前記コンピューティング環境の前記コンポーネントの展開の側面を規定する情報を提供することを特徴とする、請求項１３の方法。
【請求項１５】
前記構造カテゴリ分類の前記構造要素に関する情報は、システム管理者およびオペレータの少なくとも一方によって、展開動作の間、１つ以上のレポジトリに格納されていることを特徴とする、請求項１４の方法。
【請求項１６】
前記構造要素に関する情報は、１つ以上のアプリケーションプログラミングインタフェースによって前記１つ以上のシステムレポジトリから利用可能になることを特徴とする、請求項１５の方法。
【請求項１７】
前記コンポーネント依存性の前記動作カテゴリ分類は、ノードのグラフとしてモデル化された動作要素を備え、１つ以上の第１のノードは、該１つ以上の第１のノードが依存する１つ以上の第２のノードにリンクされ、更に、前記１つ以上の第１のノードに依存する１つ以上の第３のノードにリンクされていることを特徴とする、請求項６の方法。
【請求項１８】
前記動作要素は、前記構造カテゴリ分類における構造要素とリンクされたものおよび相互参照されたものの１つである、請求項１７の方法。
【請求項１９】
前記動作カテゴリ分類は、前記構造カテゴリ分類および前記機能カテゴリ分類の少なくとも１つから計算されることを特徴とする、請求項６の方法。
【請求項２０】
前記コンポーネント依存性の前記カテゴリ分類は、グラフ表現として表されることを特徴とする、請求項６の方法。
【請求項２１】
前記グラフ表現のエッジの少なくとも一部は、追加の限定情報によって注釈が付けられていることを特徴とする、請求項２０の方法。
【請求項２２】
前記グラフ表現は、単一方向および双方向のうち一方であることを特徴とする、請求項２０の方法。
【請求項２３】
前記グラフ表現は、有向無周期性グラフおよび有向周期性グラフのうち一方であることを特徴とする、請求項２０の方法。
【請求項２４】
グラフ表現は、上方向、下方向、および横方向のうち１つで通過可能であることを特徴とする、請求項２０の方法。
【請求項２５】
グラフ表現によって表される前記依存性情報は、１つ以上のアプリケーションプログラミングインタフェースに従ってアクセス可能であることを特徴とする、請求項２０の方法。
【請求項２６】
前記カテゴリ分類のうち１つ以上は計算された後に永続的に格納されることを特徴とする、請求項６の方法。
【請求項２７】
前記カテゴリ分類のうち１つ以上は計算された後に永続的に格納されないことを特徴とする、請求項６の方法。
【請求項２８】
コンポーネントは、サービス、アプリケーション、ミドルウエア、ハードウエア、デバイスドライバ、オペレーティングシステム、および前記コンピューティング環境に関連したシステムのうち１つであることを特徴とする、請求項１の方法。
【請求項２９】
前記情報取得ステップは、更に、１つ以上の直接関与するシステムおよび１つ以上のプロキシシステムのうち少なくとも１つによって情報を得ることを含むことを特徴とする、請求項１の方法。
【請求項３０】
更に、前記１つ以上の関係の少なくとも一部に関連した変更の履歴を維持するステップを具備することを特徴とする、請求項１の方法。
【請求項３１】
コンピューティング環境において情報を管理するための装置であって、
　少なくとも１つのプロセッサであって、（ｉ）前記コンピューティング環境のコンポーネントに関連した情報を取得する、および（ｉｉ）前記取得した情報の少なくとも一部から、前記コンピューティング環境の前記コンポーネントの少なくとも一部に関連した１つ以上の関係の存在を判定する、ように動作し、前記１つ以上の関係の存在を判定することは、前記コンピューティング環境の少なくとも１つのコンポーネントに関連した全ライフサイクルを考慮に入れることができる、プロセッサと、
　前記少なくとも１つのプロセッサに結合され、前記１つ以上の判定された関係に関連した情報を格納するように動作するメモリと、
を具備することを特徴とする、装置。
【請求項３２】
前記コンピューティング環境は分散型コンピューティング環境から成ることを特徴とする、請求項３１の装置。
【請求項３３】
前記コンピューティング環境は自律型コンピューティング環境から成ることを特徴とする、請求項３１の装置。
【請求項３４】
前記少なくとも１つのプロセッサは、更に、前記格納された情報の少なくとも一部を検索するように動作することを特徴とする、請求項３１の装置。
【請求項３５】
前記コンピューティング環境の前記コンポーネントの少なくとも一部に関連した１つ以上の関係の存在を判定する動作は、更に、前記コンピューティング環境の少なくとも２つのコンポーネントに関連した異質性を考慮することができることを特徴とする、請求項３１の装置。
【請求項３６】
前記コンピューティング環境の前記コンポーネントの少なくとも一部に関連した１つ以上の関係の存在を判定する動作は、更に、前記コンピューティング環境に関連した１つ以上のドメインに及ぶ１つ以上のコンポーネントを考慮することができることを特徴とする、請求項３１の装置。
【請求項３７】
前記コンピューティング環境の前記コンポーネントの少なくとも一部に関連した１つ以上の関係の存在を判定する動作は、更に、機能カテゴリ分類、構造カテゴリ分類、および動作カテゴリ分類から成る形態でコンポーネント依存性を計算することを含むことを特徴とする、請求項３１の装置。
【請求項３８】
コンポーネントは、サービス、アプリケーション、ミドルウエア、ハードウエア、デバイスドライバ、オペレーティングシステム、および前記コンピューティング環境に関連したシステムのうち１つであることを特徴とする、請求項３１の装置。
【請求項３９】
前記情報取得動作は、更に、１つ以上の直接関与するシステムおよび１つ以上のプロキシシステムのうち少なくとも１つによって情報を得ることを含むことを特徴とする、請求項３１の装置。
【請求項４０】
前記少なくとも１つのプロセッサは、更に、前記１つ以上の関係の少なくとも一部に関連した変更の履歴を維持するように動作することを特徴とする、請求項３１の装置。
【請求項４１】
コンピューティング環境において情報を管理するための製造の物品であって、１つ以上のプログラムを含む機械読み取り可能媒体を具備し、前記プログラムは、実行された場合、
　前記コンピューティング環境のコンポーネントに関連した情報を取得するステップと、
　前記取得した情報の少なくとも一部から、前記コンピューティング環境の前記コンポーネントの少なくとも一部に関連した１つ以上の関係の存在を判定するステップと、を実施し、前記１つ以上の関係の存在を判定するステップは、前記コンピューティング環境の少なくとも１つのコンポーネントに関連した全ライフサイクルを考慮に入れることができることを特徴とする、物品。
【発明の詳細な説明】
【技術分野】
【０００１】
　本発明は、分散型コンピューティングシステムに関し、更に特定すれば、かかる分散型コンピューティングシステムの様々なコンポーネント間で依存性を管理するための方法および装置に関する。
【背景技術】
【０００２】
　分散型システムのコンポーネント間の従属性の識別および追跡は、統合化された故障管理のためにますます重要になってきている。アプリケーション、サービス、およびそれらのコンポーネントは、様々なサポートサービスに頼っており、これらのサービスはサービス提供業者に外部委託される場合がある。更に、新たに生まれているウエブを用いた（ワールドワイドウエブを用いた）ビジネスアーキテクチャによって、ウエブを用いたｅ−ビジネス（電子ビジネス）アプリケーションを実行時に構成することが可能となっている。
【０００３】
　「実行時」という言葉は、一般に、１本のソフトウエアがコンピュータのハードドライブ上の記憶装置に休止して単に存在しているのとは対照的に、１本のソフトウエアが実行されており、コンピュータシステムのメモリ内でアクティブである時間期間を指すことは理解されよう。このため、実行時にｅ−ビジネスアプリケーションを構成可能であるということは、システム／アプリケーションをダウンさせて再起動する必要なく、更に、アプリケーションを再コンパイルする必要なく、そうする機能を有するということである。従来、コンピュータプログラムのライフサイクルは、プログラムコードを書き、次いでコンパイルし（機械コードに翻訳し）、次いで実行する、というものであった。このため、上述の機能によって、数本のソフトウエアを組み合わせて１つの新しいアプリケーションを「実行中に」形成すること、すなわちアプリケーションをダウン／コンパイル／再起動する必要なく形成することが可能となる。
【０００４】
　しかしながら、結果として、あるサービスにおいて生じた故障が、カスタマに提供されている他のサービスに影響を与える。すなわち、サービスは、他のサービスに対する依存性を有する。依存性は、単一のシステム上の異なるサービスのコンポーネント間に存在し、更に、多数のシステムおよびドメインにまたがる１つのサービスのクライアントおよびサーバコンポーネント間にも存在する。ここで、他のサービスに依存するサービスを依存者と呼び、他のサービスに依存されるサービスを先行者と呼ぶ。
【０００５】
　多くの場合、１つのサービスが双方の役割を果たすことを注記しておくことは重要である（例えば、名前サービスは、多くのアプリケーションおよびサービスに必要とされるが、それ自体、オペレーティングシステムおよびネットワークプロトコルおよびインフラストラクチャ等、他のサービスの適切な機能に依存する）。更に、依存性の関係は推移的なものである。すなわち、所与のコンポーネントの依存者は、コンポーネント自体に加えて、コンポーネントの先行者（複数の先行者）を必要とする。
【０００６】
　依存性は、エンドユーザサービス、システムサービス、アプリケーション、およびそれらの論理的および物理的コンポーネント等、分散型システムの様々なコンポーネント間に存在する。しかしながら、サービス依存性は、今日のシステムにおいて明確にされず、このため、問題の確定、切り離し、および解決が、特に難しくなる。
【０００７】
　ソフトウエア開発（米国特許第４，７５１，６３５号および米国特許第５，９６０，１９６号等）、保守（米国特許第５，４９３，６８２号等）、およびソフトウエアパッケージング（米国特許第５，８３５，７７７号等）の分野における既存の技術は、プログラムパッケージの微小部分を形成する個々のソフトウエア要素およびモジュールを扱っており、ソフトウエアを構築してそれをソフトウエアプロダクトに抱き合わせで販売するために、プログラムソースコードの可用性を必要とする。ソースコードは、ソフトウエア開発者に利用可能であるが、サービスユーザには利用できない。本発明は、主に、すでにパッケージ化されているソフトウエアプロダクトに着目する。
【０００８】
　電気通信学会規格１３８７．２（「Ｐｏｒｔａｂｌｅ　Ｏｐｅｒａｔｉｎｇ　Ｓｙｓｔｅｍ　Ｉｎｔｅｒｆａｃｅ（ＰＯＳＩＸ）ｓｙｓｔｅｍ　ａｄｍｉｎｉｓｔｒａｔｉｏｎ，ｐａｒｔ２：Ｓｏｆｔｗａｒｅ　Ａｄｍｉｎｉｓｔｒａｔｉｏｎ」、ＩＥＥＥ、１９９５年）は、ソフトウエアの分配／展開／設置について述べている。ＩＥＥＥ規格が規定する機構は、新しいソフトウエアコンポーネント（インストールされる予定である）が既存のソフトウエアインストールと競合しないことを保証する。ＩＥＥＥ規格は、３種類の関係を識別する。すなわち、前提条件、前条件、同時条件であり、これらによって、かかるコンパチビリティのチェックが容易になる。これは、新しいソフトウエアをインストールする必要がある全てのシステムについて、個別に行われる。ＩＥＥＥ規格では、他のシステム上に存在するソフトウエアのインベントリは考慮されない。更に、ＩＥＥＥ規格は、インスタンス化したアプリケーションおよびサービスを扱っておらず、従って、実行時のコンポーネント間の依存性を求める手段については何も記述していない。
【０００９】
　Ｏｐｅｎ　Ｇｒｏｕｐ（Ｓｙｓｔｅｍｓ　Ｍａｎａｇｅｍｅｎｔ：Ｄｉｓｔｒｉｂｕｔｅｄ　Ｓｏｆｔｗａｒｅ　Ａｄｍｉｎｉｓｔｒａｔｉｏｎ，ＣＡＥ　Ｓｐｅｃｉｆｉｃａｔｉｏｎ　Ｃ７０１，Ｔｈｅ　Ｏｐｅｎ　Ｇｒｏｕｐ，１９９８年１月）は、ＩＥＥＥ１３８７．２を拡張し、特定のシステム上のソフトウエアインストールツールによって呼び出されるいくつかのコマンド（ｓｗｉｎｓｔａｌｌ、ｓｗｌｉｓｔ、ｓｗｍｏｄｉｆｙ等）を規定している。また、Ｏｐｅｎ　Ｇｒｏｕｐは、ソフトウエア定義ファイルフォーマットを規定して、上述のコマンドが必要とする情報が、そのコマンドが呼び出されるシステムから利用可能であることを確実とする。ＩＥＥＥ１３８７．２の欠点（すなわち、単一の切り離されたシステムに限定され、実行時のソフトウエア依存性を求める手段が無い）は、Ｏｐｅｎ　Ｇｒｏｕｐの仕様にも当てはまる。
【００１０】
　Ｃｕｒｒｅｎｔ　Ｏｐｅｒａｔｉｎｇ　Ｓｙｓｔｅｍ　Ｉｎｖｅｎｔｏｒｙの実施（ＩＢＭのＡＩＸ　Ｏｂｊｅｃｔ　Ｄａｔａ　Ｍａｎａｇｅｒ（ＯＤＭ）、ＬｉｎｕｘのＲｅｄ　Ｈａｔ　Ｐａｃｋａｇｅ　Ｍａｎａｇｅｒ（ＰＲＭ）、またはＭｉｃｒｏｓｏｆｔのＷｉｎｄｏｗｓ（登録商標）　Ｒｅｇｉｓｔｒｙ等）は、ＯｐｅｎＧｒｏｕｐの仕様およびＩＥＥＥ１３８７．２規格に従うか、または自社開発フォーマットのソフトウエアインベントリを記述する。このため、上述の制約は、かかるＣｕｒｒｅｎｔ　Ｏｐｅｒｅｔａｉｎｇ　Ｓｙｓｔｅｍ　Ｉｎｖｅｎｔｏｒｙの実施にも当てはまる。
【００１１】
　全プログラムパッケージの電子ソフトウエア分配（米国特許第６，００９，５２５号および米国特許第５，７２１，８２４号等）またはアップデート／修正／修理／パッチ（米国特許第５，９９９，７４０号、米国特許第５，８０５，８９１号、および米国特許第５，９５３，５３３号等）のための技法は、定義上、（一度に１つまたは多くの）物理的なソフトウエアパッケージの分配／展開／インストールに制限されており、アプリケーションの実行時段階を考慮しない。更に、それらは、一度に１つのシステムを扱っており、複数のシステムにまたがったアプリケーションおよびサービスの局面を考慮しない。
【００１２】
　また、既存のソフトウエア／ハードウエア構成（米国特許第５，８６７，７１４号等）における競合を求めるための技法も、単一のシステムに限定されており、実行時の局面を考慮しない。
【００１３】
　既存の研究（米国特許第５，９１７，８３１号等）は、多くの場合、イベントの相関関係の範囲内のものであり（例えば、Ｇｒｕｓｃｈｋｅ等の「Ｉｎｔｅｇａｔｅｄ　Ｅｖｅｎｔ　Ｍａｎａｇｅｍｅｎｔ：Ｅｖｅｎｔ　Ｃｏｒｒｅｌａｔｉｏｎ　Ｕｓｉｎｇ　Ｄｅｐｅｎｄｅｎｃｙ　Ｇｒａｐｈｓ」、ＤＳＯＭ　‘９８、１９９８年、およびＫａｔｋｅｒ等、「Ｆａｕｌｔ　Ｉｓｏｌａｔｉｏｎ　ａｎｄ　Ｅｖｅｎｔ　Ｃｏｒｒｅｌａｔｉｏｎ　ｆｏｒ　Ｉｎｔｇｒａｔｅｄ　Ｆａｕｌｔ　Ｍａｎａｇｅｍｅｎｔ」、ＩＭ　‘９７、１９９７年）、自社開発のフォーマットにおけるサービス依存性の識別および記述に焦点を当てているが、故障管理プロセスの異なるエンティティ間でどのように依存性情報が実際に交換される可能性があるかについては不明確なままである。外部委託されたアプリケーションの故障管理プロセスに関与する異なる関係者が、依存性追跡のために同一のツールセットを用いる可能性は低いので、依存性情報を規定し交換するためのオープンフォーマットを規定することが根本的に重要である。
【特許文献１】米国特許第４，７５１，６３５号
【特許文献２】米国特許第５，９６０，１９６号
【特許文献３】米国特許第５，４９３，６８２号
【特許文献４】米国特許第５，８３５，７７７号
【特許文献５】米国特許第６，００９，５２５号
【特許文献６】米国特許第５，７２１，８２４号
【特許文献７】米国特許第５，９９９，７４０号
【特許文献８】米国特許第５，８０５，８９１号
【特許文献９】米国特許第５，９５３，５３３号
【特許文献１０】米国特許第５，８６７，７１４号
【特許文献１１】米国特許第５，９１７，８３１号
【非特許文献１】電気通信学会規格１３８７．２（「Ｐｏｒｔａｂｌｅ　Ｏｐｅｒａｔｉｎｇ　Ｓｙｓｔｅｍ　Ｉｎｔｅｒｆａｃｅ（ＰＯＳＩＸ）ｓｙｓｔｅｍ　ａｄｍｉｎｉｓｔｒａｔｉｏｎ，ｐａｒｔ２：Ｓｏｆｔｗａｒｅ　Ａｄｍｉｎｉｓｔｒａｔｉｏｎ」、ＩＥＥＥ、１９９５年）
【非特許文献２】Ｏｐｅｎ　Ｇｒｏｕｐ（Ｓｙｓｔｅｍｓ　Ｍａｎａｇｅｍｅｎｔ：Ｄｉｓｔｒｉｂｕｔｅｄ　Ｓｏｆｔｗａｒｅ　Ａｄｍｉｎｉｓｔｒａｔｉｏｎ，ＣＡＥ　Ｓｐｅｃｉｆｉｃａｔｉｏｎ　Ｃ７０１，Ｔｈｅ　Ｏｐｅｎ　Ｇｒｏｕｐ，１９９８年１月
【非特許文献３】Ｇｒｕｓｃｈｋｅ等、「Ｉｎｔｅｇａｔｅｄ　Ｅｖｅｎｔ　Ｍａｎａｇｅｍｅｎｔ：Ｅｖｅｎｔ　Ｃｏｒｒｅｌａｔｉｏｎ　Ｕｓｉｎｇ　Ｄｅｐｅｎｄｅｎｃｙ　Ｇｒａｐｈｓ」、ＤＳＯＭ　‘９８、１９９８年
【非特許文献４】Ｋａｔｋｅｒ等、「Ｆａｕｌｔ　Ｉｓｏｌａｔｉｏｎ　ａｎｄ　Ｅｖｅｎｔ　Ｃｏｒｒｅｌａｔｉｏｎ　ｆｏｒ　Ｉｎｔｇｒａｔｅｄ　Ｆａｕｌｔ　Ｍａｎａｇｅｍｅｎｔ」、ＩＭ　‘９７、１９９７年
【発明の開示】
【発明が解決しようとする課題】
【００１４】
　要約すると、既存の技術において、ソフトウエアプロダクト間の関係を決定することに関するいくつかの技法が記述され実施されている。これらの既存の技法は、以下の欠点のうち１つ以上を有する。すなわち、
（ａ）ソフトウエアプロダクトのインストールおよび展開の段階のみに対処する。すなわち、設計および実行時の局面を取り入れようとしない。
（ｂ）多数のシステムにまたがる終端間のアプリケーションおよびサービスを扱わない。すなわち、単一の切り離されたシステムに常駐するソフトウエアの特徴を扱う。
（ｃ）ソフトウエアインベントリ情報は、自社開発のフォーマットにおいて記述されるので、様々な異種システム間でこの情報を共有することが極めて難しくなる。
【課題を解決するための手段】
【００１５】
　本発明は、コンピューティング環境の様々なコンポーネント間で、情報、特に依存性情報を管理するための技法を提供する。一例として、本発明の技法は、分散型コンピューティング環境に適用可能である。また、コンピューティング環境は、自律的なコンピューティング環境とすることができる。
【００１６】
　本発明の一態様では、コンピューティング環境において情報を管理するための技法は、以下のステップ／動作を具備する。コンピューティング環境のコンポーネントに関連した情報を取得する。次いで、取得した情報の少なくとも一部から、コンピューティング環境のコンポーネントの少なくとも一部に関連した１つ以上の関係が存在するか否かを判定する。本発明によれば、１つ以上の関係が存在するという判定は、コンピューティング環境の少なくとも１つのコンポーネントに関連した全ライフスタイル（例えば、展開、インストール、および実行時を含む）を考慮に入れることができる。一例として、コンポーネントは、サービス、アプリケーション、ミドルウエア、ハードウエア、デバイスドライバ、オペレーティングシステム、またはコンピューティング環境に関連したシステムとすることができる。しかしながら、「コンポーネント」という言葉は、これらの例に限定されるわけではない。
【００１７】
　更に、この技法は、コンピューティング環境の少なくとも２つのコンポーネントに関連した異質性、および、コンピューティング環境に関連した１つ以上のドメインにまたがる１つ以上のコンポーネントを考慮に入れることができる。
【００１８】
　好適な実施形態では、本発明の技法は、１つ以上の関係の存在を判定する際に、機能カテゴリ分類、構造カテゴリ分類、および動作カテゴリ分類を含む形態でコンポーネントの依存性を計算する。カテゴリ分類は、１つ以上の依存性モデルを含むことができる。
【００１９】
　このため、好都合なことに、本発明は、個別のシステムをあるレベルで抽象化し、カスタマが感知するような終端間のサービスに関連したサービス／アプリケーション依存性の計算を可能とする。
【００２０】
　既存の技術における上述の制約とは対照的に、本発明は、かかる欠点を克服するため、多数のシステムにまたがり、関与するシステム、アプリケーション、およびサービスの実行時挙動を反映する、より高いレベル（終端間のサービス／アプリケーション）のビューをカスタマに提供する。収集した依存性情報を、公開の拡張可能フォーマットで記述して、データ交換を容易にする。
【００２１】
　本発明のこれらおよび他の目的、特徴、および利点は、添付図面に関連付けて読むことができる以下の例示的な実施形態の詳細な説明から、明らかになろう。
【発明を実施するための最良の形態】
【００２２】
　本発明について、例示的な分散型コンピューティング環境という文脈の中で、以下に説明する。しかしながら、本発明は、かかる特定のコンピューティング環境に限定されないことは理解されよう。逆に、本発明は、より一般的に、問題を判定し、切り離し、解決するタスクを著しく容易にするために、依存性を管理する（例えば計算する、問い合わせる等）ことが望ましいコンピューティング環境であれば、どんなものにも適用可能である。
【００２３】
　本明細書中で用いる場合、考察の文脈に応じて、「システム」という言葉を用いて、コンピュータシステム、ソフトウエアシステム、および／またはそれらの何らかの組み合わせを指すことができる。また、「システム」という言葉を用いて、アプリケーションおよび／またはサービスを指すことができる。このため、「多数のシステム」という言葉は、いくつかのシステムの集合を指す。また、「コンポーネント」という言葉は、システム自体、または、システムの１つ以上の部分を指すことができる。
【００２４】
　上述のように、今日のシステムにおいてサービス依存性は明白になっておらず、このため、問題の判定、切り離し、および解決のタスクが特に難しくなっている。この問題を解決するには、異なるシステムおよびドメインにまたがるサービスおよびアプリケーション間の依存性を判定および計算する必要がある。すなわち、「グローバルな」サービス依存性モデルを確立し、結果として得られる有向グラフをシステムの管理者が上から下までおよび逆の順序で自由に見られるようにすることが必要である。かかる機構に対する必要性は、以下の２つの状況によって最も良く例示される。
【００２５】
　第１の状況は、通常インターネットまたはアプリケーションサービスプロバイダ（ＩＳＰ／ＡＳＰ）によって提供される、外部委託されたサービスの管理を扱う。外部委託されたサービスは、層化されたサービス階層となり、例えば、ＡＳＰのサービスはＩＳＰが提供するＩＰ接続性（インターネットプロトコル接続性）に依存し、一方、ＩＳＰは、電気通信事業者のワイドエリアネットワークに頼っている。全ての層において、サービスは、サービスアクセスポイント（ＳＡＰ）を介してアクセスされる。ＳＡＰは、異なる組織ドメイン間の境界を定めるものであり、サービスレベルアグリーメント（ＳＬＡ）を規定し観察する場所である。通常、これは、全ての層において、プロバイダが提示する特定のパラメータ集合を監視することによって行われる。上層サービスにおいて使用不能または性能劣化が起こった場合、サービス階層を上から下まで通り抜けて、問題の根本的な原因の識別をする必要がある。
【００２６】
　第２の状況は、「実行中に」行うことができない、従ってサービスおよびそれらのカスタマに影響を与える、定期的な保守タスクを扱う。例えば、ｅ−メールサーバをそれらのオペレーティングシステムの新しいレリースによって更新する、ネットワークデバイスを新しいファームウエアバージョンによって交換または更新する等である。あらゆる場合において、ネットワークおよびサーバ管理者は、保守によって、いくつの、更に具体的には、どのサービスおよびユーザが影響を受けるかを前もって判定することが重要である。このタスクを影響分析と呼ぶ。
【００２７】
　上述のタスクは、更に、以下のファクタによって悪化する。
【００２８】
　依存性モデルは、観察された問題の根本原因であり得るものを識別するための直接的な手段を提供する。システムの依存性グラフが明らかになれば、障害が起こったサービスからその先行者（同一のホストまたは異なるシステム上にコロケートしている）へとグラフを自由に見ることによって、どのエンティティが故障した可能性があるかが明らかとなる。グラフをそのルートへと（すなわち上方向に）横切ることによって、サービスの依存者、すなわち、このサービスが使用不能となった場合に故障する恐れのあるコンポーネントがわかる。以下の問題に対処する必要がある。
【００２９】
　（ａ）規模：多くの関与するシステム間の依存性の数を計算することができるが、これは極めて多い場合がある。技術上の観点から見ると、完全な、インスタンス化された依存性モデルを単一の場所に格納することは、多くの場合、望ましくない（時には不可能である）。プラットフォームデータベースにおいてインスタンス化したネットワークマップを維持する等、ネットワーク管理プラットフォームにおいて用いられる従来の機構は、関与する依存性の変化する数およびダイナミクスのため、依存性に適用することはできない。
【００３０】
　これらの２つの事実によって、アプリケーション、サービス、およびミドルウエア依存性モデルの展開のための「ネットワーク−管理−スタイル」の手法に従うことができなくなる。一例として、通常のサービス外部委託者のデータセンターは、極めて大量（数千）のウエブアプリケーションおよびデータベースサーバのホストとして働く。これは、例えばウエブアプリケーションおよびデータベースサーバの、非常に多くのプログラムインスタンスが同時に実行していることを意味する。依存性モデルを構築可能であるシステムは、管理プロセスに関与する複数のシステム間に依存性の格納および計算を分散させることによって、適切な拡張性を可能とする機構を提供しなければならない。
【００３１】
　（ｂ）ダイナミクス：ホストの下のアプリケーション（ウエブアプリケーションサーバ内で実行する）は、寿命が極めて短く、多くの場合、わずか数秒である。要求を受けると、ウエブアプリケーションのビジネス論理（通常、１つ以上のＪａｖａ（登録商標）　Ｓｅｒｖｌｅｔとして実施される）は、アプリケーションサーバのＳｅｒｖｌｅｔエンジンによってインスタンス化され、そのタスクを実行し、次いで、Ｓｅｒｖｌｅｔエンジンによって除去される。この結果、これらの動的エンティティ間の依存性を計算するためのシステムは、データの正確さとこのデータを検索するために発生した作業負荷との間のトレードオフに対処しなければならない。
【００３２】
　（ｃ）異質性：異質性は、３つの異なる特徴で生じる。第１に、カスタマに提供されるサービスには、大きな相違がある。第２に、サービスをカスタマに提供することに関与する様々な提供業者が存在し得る。最後に、サービスを実施する製品は、様々なベンダーから提供される可能性がある。依存性を計算するシステムは、特定のオペレーティングシステム、ネットワークプロトコル、ソフトウエアプロダクト、およびカスタマに提供されるサービスから独立した言語を提供しなければならない。
【００３３】
　（ｄ）手作業による依存性データの保守：サービス依存性モデルの獲得は、単一のホストシステムに限定しても、今日のシステムが適切な管理手段を提供していないので、それ自体が難題である。「手段」という言葉は、管理アプリケーションによってアクセス可能であるように、明確に定義された（時には標準化さえされている）インタフェースを介して、（管理された）リソースの管理特徴および機能を提示するプログラムコードを指すことは理解されよう。更に、管理されたリソースから利用可能であっても、依存性データは、今日の管理システムによって活用されない。代わりに、依存性情報は、特定の管理コンポーネントに手作業で入力されなければならないだけでなく、自社開発フォーマットで入力されなければならない。従って、依存性情報は、完全でなく、（誤りを起こしがちな手作業処理のため）時代遅れになっており、時には一貫性がない場合さえある。なぜなら、異なるオペレータがルールを別個に入力し、自動化した方法で一貫性についてルールベースをチェックする方法がないからである。
【００３４】
　（ｅ）依存性の分類：依存性の概念は、極めて粗いものであり、有用にするためには改良する必要がある。この例は、依存性の強さ（コンポーネントの先行者が故障した場合にそのコンポーネントが影響を受ける可能性および程度を示す）、重大さ（企業の目標および方針に関してこの依存性がどのくらい重要であるか）、形式化の程度（すなわち依存性を取得するのがどのくらい難しいか）、および他の多くのことである。依存性に属性を付加して、より適切にそれらを限定することができるようにする必要があり、従って、依存性表現にこれらの属性を反映させる必要がある。
【００３５】
　（ｆ）問題判定機構：全システムに格納されたローカルな依存性グラフを均一な依存性モデルに組み合わせるための更に別の機能が望まれる。更に、これらの機能は、管理アプリケーションが依存性モデルに対して問い合わせを発することができるＡＰＩ（アプリケーションプログラミングインタフェース）を提供しなければならない。これらの問い合わせは、特定のサービスが直接依存するエンティティを検索すること、または、副先行者を含むノード集合全体を再帰的に判定することを可能とする。管理アプリケーションによって受信されたノードのリストによって、特定の問題判定ルーチンを実行して、これらのサービスが動作中であるか否かを調べることができる。
【００３６】
　先の考察によって、サービスライフサイクルの異なる段階間でマッピングを行うことが重要であることが示される。
【００３７】
　（ａ）（抽象的な）サービスのカスタマへの提供。例えば、「ウエブホスティング」、「管理された記憶装置」、「ＩＰ接続性」、「管理されたデータベース」等である。
　（ｂ）サービスの実施。すなわち、例えば「ＩＢＭ　Ｕｎｉｖｅｒｓａｌ　Ｄａｔａｂａｓｅバージョン７．１」、「ＷｅｂＳｐｈｅｒｅ　Ａｐｐｌｉｃａｔｉｏｎ　Ｓｅｒｖｅｒバージョン３．２」のようなサービスを提供するためのプロダクト（複数のプロダクト）の使用。
　（ｃ）実施のインスタンス（複数のインスタンス）の実行。すなわち、プロセスまたはタスク、例えば「ｄｂ２　ｄａｅｍｏｎ」、「ｎｆｓ　ｄａｅｍｏｎ」。
【００３８】
　全ての段階において利用可能な情報を個別に得るタスクは実現可能であるが、３つの段階を均一な依存性モデルに組み合わせることは、難題であり、以前の研究では行われていない。更に、人による介入および依存性データの保守の必要性をなくしつつ、基礎的な環境の規模、ダイナミクス、および異質性の要求に対処する、効率的に計算可能な依存性モデルを確立する必要がある。
【００３９】
　図面に関連付けて以下に例示するが、本発明は、これらおよび他の必要性に応える。すなわち、本発明は、管理アプリケーションの代わりに分散型システムのコンポーネント間の実行時依存性（「依存性モデル」）を計算する機構を有する。本発明は、個々のコンピュータシステムの構成情報を検索するための機構を提供するか、またはかかるデータを機械可読フォーマットで提供する、コンピュータシステムから依存性情報を検索するための一般的かつ一貫した手法を提供する。
【００４０】
　上述のシステムの１つの利点は、個々のアプリケーション／サービスに手段を備える必要なく、これらのコンピュータシステムから大量のアプリケーション／サービス管理情報を取得可能なことである。しかしながら、かかるアプリケーション／サービスの手段が利用可能である場合、これを本発明によって用いることができる。
【００４１】
　本発明によって説明されるシステムの実行は、特定の（管理）アプリケーション（影響分析器、根本原因分析器等）、ネットワーク管理プラットフォーム（ＩＢＭ／Ｔｉｖｏｌｉ　ＮｅｔＶｉｅｗ、ＨＰ　ＯｐｅｎＶｉｅｗまたはＡｐｒｉｓｍａ　Ｓｐｅｃｔｒｕｍ）、または従来のネットワーク管理システムおよびプラットフォームに基づく管理アプリケーションのいずれかによって作動させることができる。
【００４２】
　本発明は、とりわけ、以下のための機構を提供する。
　（ａ）加入サービスの性能劣化および使用不能を観察する。
　（ｂ）依存性モデルの異なる層を上から下まで通り抜けることによって、問題の根本原因を突き止める（なぜなら、様々なサービスが他のサービス提供業者に外部委託されており、この（再帰的な）依存性モデルの横断はドメインの境界を横切るからである）。
　（ｃ）依存性モデルを下から上まで自由に見ることによって、サービスの使用不能の影響を分析する。
【００４３】
　本発明は、アプリケーションまたはサービスのライフサイクルの間に利用可能な依存性情報を組み合わせる（すなわち、アプリケーション／サービスの設計から展開、インストール、および実行時段階まで）。この情報は、以下のモデル内に維持される。
【００４４】
　（ａ）機能モデル：好適な実施形態では、機能モデルは、異なる一般サービス（データベースサービス、名前サービス、ウエブアプリケーションサービス、接続性サービス等）間の依存性を規定する。機能モデルは、特定のサービス内のクライアント／サーバ関係を記述しない。更に、機能モデルは、サービスを実施するためにどの具体的な製品を選択したかも、それらの実際の構成も、考慮しない。機能モデルは、他のモデル（以下で説明する）を結び付ける主要な制約を確立する。すなわち、別のモデルは、具体的なシステムインフラストラクチャに関して機能モデルにおいて規定される依存性を改良することができるが、サービスカテゴリ間に新たな依存性を導入してはならない。このモデルは、極めてコンパクトであり、一般的であり、好ましくは管理システム上に格納される。
【００４５】
　（ｂ）構造モデル：好適な実施形態では、構造モデルは、機能モデルにおいて規定されたサービスを実現するソフトウエアコンポーネントの詳細な記述を含む。構造モデルは、インストール／展開段階の間に捕捉された詳細事項を提供し、具体的なシステムのソフトウエアインベントリを考慮することによって機能モデルを補足する。構造モデルは、特定のシステム上でどのサービスをインストールおよび構成するか、ならびに、全てのサービスについて、システムがクライアントまたはサーバのどちらの役割で動作するかに関する情報を提供する。システムおよびサービスの数が潜在的に多いことによって、遠隔位置からこれらの依存性を追跡することは難しくなる。このため、管理されたリソースの近くで、または管理されたリソースにおいて、このモデルを格納することが望ましい。
【００４６】
　（ｃ）動作モデル：好適な実施形態では、ソフトウエアパッケージがインスタンス化され、サービスとアプリケーションとの間の結合が確立されると、依存性の動作モデルが生成される。このモデルおよび多数の関与するシステムの高度なダイナミクスのために、完全なモデルをインスタンス化し格納することができる程度が制限される。かかるモデルを規定し格納することは現実的でなく、むしろ、モデルは動的かつ段階的に計算しなければならない。従って、動作モデルは、「オンデマンド」で計算され、機能モデルおよび構造モデルに頼っている。
【００４７】
　予想されるように、大規模な分散型システムでは、依存性の量は極めて多く、それらのダイナミクスは極めて高度である。本発明の機構は、分散型システムに対するそれらの（リソースおよび帯域幅の使用という点での）影響を、できる限り小さく抑え、ユーザまでの性能に影響する可能性がある多くの構成オプションを与える。この例として、更新した依存性モデルを検索するための時間間隔、依存性を追跡しなければならないシステムの範囲、依存性モデルの深さ（直ちに影響を受けるサービスのみ、所与のサービスの推移的な終了、またはサービス階層全体）が挙げられる。
【００４８】
　本発明は、好ましくは、以下の依存性情報の特徴を利用する。
【００４９】
　（ａ）異なるサービス間の依存性を層化する。更に、それらの依存性グラフは有向であり無周期である。後者の表現は、ＤＮＳ（Ｄｏｍａｉｎ　Ｎａｍｅ　Ｓｙｓｔｅｍ）、ＮＦＳ（Ｎｅｔｗｏｒｋ　Ｆｉｌｅ　Ｓｙｓｔｅｍ）、ＤＦＳ（Ｄｉｓｔｒｉｂｕｔｅｄ　Ｆｉｌｅ　Ｓｙｓｔｅｍ）、ＮＩＳ（Ｎｅｔｗｏｒｋ　Ｉｎｆｏｒｍａｔｉｏｎ　Ｓｙｓｔｅｍ）等のＩＰに基づくネットワークサービスによる経験を反映しているが、いくつかのシステムにおいて相互依存性が生じる場合もあり得る。かかる相互依存性の異常な例は、ＤＮＳサーバが、ファイルシステムを搭載し、遠隔システムからＮＦＳを介してそのＤＮＳ構成を格納するというものである。かかる構成は技術的には実現可能であるが、システム設計の欠陥をもたらす。なぜなら、これによって、立ち上げが非決定論的である恐れがあり、従って回避しなければならない不安定なシステムとなるからである。周期的な依存性を発見する依存性チェックアプリケーションは、管理者に警告を発しなければならない。
【００５０】
　（ｂ）全ての依存性は、カスタマ／提供業者ドメインの境界において可視的であり、ＳＬＡによって明白になる。その結果、観察可能な依存性の数は有限である。
【００５１】
　（ｃ）依存性モデルによって、依存性連鎖をトップダウンで横断することが可能となる。
【００５２】
　（ｄ）異なるシステム間（システム間）の依存性は、同一サービスのクライアントおよびサーバの部分間の依存性として知覚される。サービスＡのクライアントが、異なるサービスＢを提供するサーバに要求を出すことは不可能である。
【００５３】
　本発明の１つの目的は、具体的なサービス／アプリケーション手段から最大の程度の独立性を達成するため、主にいくつかの周知の／明確に規定された場所（例えばシステムレポジトリ）から情報を検索することである。これを実現するため、本発明は、最小かつ十分な量の共通して利用可能な依存性情報を規定する。
【００５４】
　本発明は、依存性モデルを永続的に格納するための機能を具備するか、または、これを、本発明を用いる管理アプリケーションまたは別のサービスの自由裁量に委ねる。
【００５５】
　本発明は、依存性モデルの変化を検出し判定するための履歴の概念を有することができる。この場合、本発明は、依存性モデル内の変化について以前に登録されたソフトウエアコンポーネントに通知するための発行／加入インタフェースを提供する。本発明の別の可能な使用法は、依存性モデルの変化の検出を、管理アプリケーション（または変化管理サービス）の自由裁量に委ねて、依存性モデルの変化が生じたか否かを判定するために本発明に定期的に呼を発することである。
【００５６】
　本発明に従って成される上述の達成および本発明に関連した一般的な特徴を想定し、詳細な説明の残り部分では、図１ないし１８の状況においてかかる達成および特徴を実施するための技法を例示的に説明する。
【００５７】
　最初に図１を参照すると、ブロック図が、本発明の機構と相互作用して情報を生成可能なクライアント−サーバアプリケーションアーキテクチャの形態で電子商取引システムの一例を示す。図１のアーキテクチャについて、以下で説明して、かかるアーキテクチャが本発明の技法がない場合にトランザクションをどのように扱うことができるかを示す。
【００５８】
　図示するように、クライアントシステム１０５を用いて、例えばキーボードを介して要求を開始する。しかしながら、要求は、マウスクリック、音声コマンド、バーコード読み取り等のいずれかの従来の手段によって開始することも可能である。クライアントシステム１０５の例は、パーソナルコンピュータ、キオスク、データ入力端末、スキャナ、電話、ポケットベル、手持ち式または着用式デバイス、無線デバイス、パーソナルデジタルアシスタント、ネットワークによって動作可能となる時計等である。
【００５９】
　要求が定式化され、ネットワーク１１０を介してウエブアプリケーションサーバ１２０に送信された場合、１つ以上のネットワークアクセス１１５デバイスを通過することによって、要求がローカルに実行される。ネットワーク１１０および通信プロトコルの例は、ローカルエリアネットワーク（ＬＡＮ）を介したＴＣＰ／ＩＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ　Ｃｏｎｔｒｏｌ　Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ　Ｐｒｏｔｏｃｏｌ）転送によるソケットを用いた通信であり、これは、ルータ等のネットワークアクセス１１５デバイスによって接続され、多くの切り替え位置を含むワイドエリアネットワーク（ＷＡＮ）に切り替わって、サービス提供業者および最終的にウエブアプリケーションサーバ１２０へのバーチャル回路を生成する。ウエブアプリケーションサーバ１２０の例は、高性能パーソナルコンピュータ、ＲＩＳＣベースのＰｏｗｅｒＰＣ、ＵＮＩＸ（登録商標）ベースのワークステーション、ミニコンピュータ、またはメインフレームコンピュータであり、これらは、クライアントからの要求を受けて、その要求を適切なバックエンドデータベースサーバに適宜分配するソフトウエアを実行する。
【００６０】
　例示の目的のため、ここで、インターネットを用いて品物を購入するためにウエブブラウザ（クライアントシステム１０５上で動作している）内で開始する電子商取引トランザクションについて説明する。本発明の技法は、いかなる形態のトランザクションでも機能することができることは理解されよう。ウエブアプリケーションサーバの例は、ＷＥＢＳＰＨＥＲＥの商標でＩＢＭ社から入手可能なもの、ＷＥＢＬＯＧＩＣの商標でＢＥＡ　Ｓｙｓｔｅｍｓ社から入手可能なもの、またはＬＯＴＵＳ　ＤＯＭＩＮＯ　ＳＥＲＶＥＲの商標でＬｏｔｕｓ社から入手可能なものが含まれるが、これらに限定されるわけではない。
【００６１】
　例示のトランザクションにおいて、ウエブアプリケーションサーバ１２０のビジネスロジックは、入来する要求を処理し、クライアントシステム１０５の認証および／または識別を行う。いったん、ウエブアプリケーションサーバ１２０が実施するビジネスロジックが、クライアントがこの購入を続行可能であると判定すると、これは、ネットワーク１２３を介してデータベースサーバ１２５に対して別の要求を伝達して、インベントリを減らす。データベースサーバ１２５は、この要求を処理し、そのデータベース１３０にアクセスし、ウエブアプリケーションサーバ１２０への応答を準備する。データベースサーバの例は、ＳＱＬ／ＳＥＲＶＥＲまたはＴＲＡＮＳＡＣＴＩＯＮ　ＳＥＲＶＥＲの商標でＭｉｃｒｏｓｏｆｔ社によって販売されているもの、またはＤＢ２　ＵＮＩＶＥＲＳＡＬ　ＤＡＴＡＢＡＳＥ　ＳＥＲＶＥＲの商標でＩＢＭ社から販売されているものを含むが、これらに限定されるわけではない。
【００６２】
　ウエブアプリケーションサーバ１２０は、データベースサーバ１２５から応答を受け取り、これを、ネットワーク１１０を介してクライアントシステム１０５に戻す。次いで、クライアントシステム１０５は、この応答を処理して、これを表示するためにフォーマットし、トランザクションイニシエータが調べるためにこの応答を提示する。
【００６３】
　管理者１００は、サービス提供業者の場所に位置する、ビジネストランザクションを処理する様々なソフトウエアおよびハードウエアコンポーネントを観察し、それらが適正に機能しているか否かを判定する。データベース１３０において、テーブルスペースが壊れたり、データベース実行時システムが故障したりする等の使用不能１３５が起こった場合、管理者１００のタスクは、使用不能の原因を突き止め、問題を正し、システム全体が再び適正に機能しているか否か確認することである。本発明は、あらゆる形態の使用不能または性能劣化に対する動作を意図することは理解されよう。
【００６４】
　管理者１００は、ソフトウエアおよびハードウエアコンポーネントと、直接にまたは管理システムを介して対話する。この管理システムは、明確に規定された管理インタフェースにおいてソフトウエアおよびハードウエアコンポーネントが提示する管理情報（ステータスおよび健康データ等）を処理する。いずれの場合であっても、ハードウエアおよびソフトウエアコンポーネントは、管理者によって、別個のリソースとして認知され、特定のビジネス目的に供するシステム全体の一部として認知されるものではないことを注記しておくことは重要である。
【００６５】
　特に、１つのコンポーネントにおいて生じているエラーは、見つけることができない場合がある。なぜなら、管理者は、連続的に監視していないので、それらに気づくことがないからである。更に、本発明の技法を用いなければ、様々なコンポーネント間の相互依存性に関する明確な情報は、管理者に直接的に利用可能ではない。このため、連続的に監視されていないコンポーネント内のエラーは、その故障が被監視コンポーネントに伝搬するまで、見つからないままである可能性がある。
【００６６】
　上述のデータベース使用不能１３５の場合、管理者は、ウエブアプリケーションサーバ１２０が適正に機能していない場合に使用不能について最終的に気づくのみである場合がある（例えば、ウエブアプリケーションサーバは、データベースサーバ１２５に対する接続を再試行し続け、クライアントシステム１０５が送信した要求を完了することができないので、ウエブアプリケーションサーバに対する負荷が激増する）。このため、管理者１００は、最初に、ウエブアプリケーションサーバ１２０について調査し、次いで、ネットワーク１２３の接続性の問題があるか否か判定し、最終的に、データベースサーバ１２５が、データベース１３０における内部エラーに起因し得る問題に直面しているか否かを検証する。
【００６７】
　上述のクライアントサーバアプリケーションアーキテクチャは、ＩＢＭ社が「自律的」コンピューティング環境と呼ぶ新生のコンピューティング環境の先駆けと考えることができる。ＩＢＭ　Ｒｅｓｅｒｃｈ、２００１年１０月の、Ｐ．Ｈｏｒｎによる、「Ａｕｔｏｎｏｍｉｃ　Ｃｏｍｐｕｔｉｎｇ：ＩＢＭ’ｓ　Ｐｅｒｓｐｅｃｔｉｖｅ　ｏｎ　ｔｈｅ　Ｓｔａｔｅ　ｏｆ　Ｉｎｆｏｒｍａｔｉｏｎ　Ｔｅｃｈｎｏｌｏｇｙ」は、自律的コンピューティングを、人による介入を最小にした自己管理コンピューティングシステムに対する包括的かつ全体論的な取り組み方法として規定する。この開示は、引用により本願にも含まれるものとする。この語は、自覚も介入もせずに重要な機能を制御する身体の自律神経系に由来する。更に具体的には、自律的コンピューティングの目的の１つは、管理者１００が通常実行するタスクの一部または全てを自動化することである。そうするための動機は、以下の通りである。
【００６８】
　コンピューティングが進化すると、重複する接続、依存性、および相互作用するアプリケーションによって、いかなる人間が行い得るよりも速い管理的な意思決定および応答が必要となる。故障の根本原因を正確に指摘することは更に難しくなり、一方で、システム効率を向上させる方法を見出すことは、どんな人が解決を期待するよりも多くの変数を有する問題を発生させる。自律的コンピューティング環境の異なるシステム間の依存性を識別し追跡する問題は、以下のように特徴付けることができる。１つのシステムは多くのレベルで存在し得るので、自律的システムは、それ自身を制御するため、そのコンポーネント、現在のステータス、最終的な容量、および他のシステムとの接続全てについて、詳細な知識を必要とする。本発明を自律的コンピューティング環境において実行可能であることは、当業者には認められよう。
【００６９】
　ここで図２を参照すると、ブロック図は、本発明の一実施形態による、依存性管理を行うためのシステムを示す。更に具体的には、図２は、上述の問題に対処する依存性管理システムを示す。このシステムは、４つの層（アプリケーション層２００、サービス層２０５、ミドルウエア層２１０、およびリソース層２１５）、ならびに、管理者グラフィカルユーザインタフェース２８５を備え、このインタフェース２８５によって管理者１００はシステムと対話する。
【００７０】
　最下層は、リソース層２１５である。リソース層２１５は、被管理リソース２２０、リソース依存性レポジトリ２２５、およびレポジトリエージェント２３０を備える。被管理リソース２２０の例は、物理的および論理的ハードウエアコンポーネント（前者の例は、ハードディスク、ランダムアクセスメモリ、中央演算処理装置、ネットワークアダプタ、チャネルコントローラ等であり、後者の例は、ディスクパーティション、ファイルシステム等である）、ならびにソフトウエアコンポーネント（オペレーティングシステム、プリントスプーラーまたは名前サービスのようなシステムサービス、およびエンドユーザアプリケーション等）を含むが、これらに限定されるわけではない。
【００７１】
　リソース依存性レポジトリ２２５は、全ての被管理リソース２２０のハードウエアおよびソフトウエアコンポーネントのインベントリおよび依存性情報（すなわち被管理リソース２２０内のコンポーネント間の依存性）をリソースごとに含む。リソース依存性レポジトリ２２５は、個々の被管理リソース２２０の全てにコロケートするか、または、１つの場所に集中化して置くことができる。リソース依存性レポジトリ２２５は、レポジトリエージェント２３０を介して、問い合わせ、更新、変更することができる。レポジトリエージェント２３０は、リソース依存性レポジトリ２２５の情報をシステムの他のコンポーネントに利用可能とする。
【００７２】
　ミドルウエア層２１０は、プロトコルおよびオブジェクト要求ブローカ等の管理通信インフラストラクチャ２３５を備え、これによって、システムの異なるコンポーネントが（管理）情報を交換する。
【００７３】
　サービス層２０５は、政策、イベント、およびディレクトリ等の様々な一般管理サービス２５０を備え、これらは、様々な管理アプリケーションによって使用可能である。特に重要なサービスは、依存性サービス２４５であり、これは、被管理リソース２２０およびレポジトリエージェント２３０の双方から情報を検索し、この情報を処理して、リソース環境全体の終端間依存性モデルを確立する。このモデル（またはその部分）は、依存性サービス２４５の必要に応じて（例えば、より迅速な検索のためのキャッシュすること）終端間依存性レポジトリ２４０に格納される。依存性サービス２４５は、上述のシステムにおいて、終端間依存性レポジトリ２４０と直接対話する唯一のコンポーネントであることを注記しておく。
【００７４】
　アプリケーション層２００は、一般管理サービス２５０および／または依存性サービス２４５を用いる様々な管理アプリケーションを備える。かかる管理アプリケーションの例は、故障マネージャ２６０、トポロジ発生器２６５、影響分析器２７０、影響シミュレータ２７５、および根本原因分析器２８０を含むが、これらに限定されるわけではない。
【００７５】
　根本原因分析器２８０は、使用不能によって影響を受けるコンポーネントからその先行者に向けて、（依存性サービス２４５が提供する）依存性モデルを横断することに基づいて、使用不能の根本原因（すなわち、その使用不能を最初に引き起こしたコンポーネント）を決定する。根本原因分析器は、先に引用し、同時に出願された、「Ｍｅｔｈｏｄｓ　Ａｎｄ　Ａｐｐａｒａｔｕｓ　Ｆｏｒ　Ｒｏｏｔ　Ｃａｕｓｅ　Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ　ａｎｄ　Ｐｒｏｂｌｅｍ　Ｄｅｔｅｒｍｉｎａｔｉｏｎ　ｉｎ　Ｄｉｓｔｒｉｂｕｔｅｄ　Ｓｙｓｔｅｍｓ」と題する弁理士整理番号第ＹＯＲ９２００２００９６ＵＳ１が付された米国特許出願において開示された技法を採用することができる。しかしながら、他の根本原因分析技法も使用可能である。
【００７６】
　影響分析器２７０は、使用不能を経験しているコンポーネントからその依存者に向けて、（依存性サービス２４５が提供する）依存性モデルを横断することに基づいて、使用不能の影響（すなわち、使用不能によって影響を受ける可能性のあるコンポーネント）を決定する。影響分析器は、先に引用し、同時に出願された、「Ｍｅｔｈｏｄｓ　Ａｎｄ　Ａｐｐａｒａｔｕｓ　Ｆｏｒ　Ｉｍｐａｃｔ　Ａｎａｌｙｓｉｓ　ａｎｄ　Ｐｒｏｂｌｅｍ　Ｄｅｔｅｒｍｉｎａｔｉｏｎ　」と題する弁理士整理番号第ＳＯＭ９２００２０００４ＵＳ１が付された米国特許出願において開示された技法を採用することができる。しかしながら、他の影響分析技法も使用可能である。
【００７７】
　影響分析器２７０に基づいた影響シミュレータ２７５によって、管理者１００は、システム全体に対して特定のコンポーネントの使用不能が与える影響をシミュレートして、「ｗｈａｔ−ｉｆ」分析を実行することができる。これによって、適切なフェイルオーバ解決策を提供することができる。影響シミュレータは、先に引用し、同時に出願された、「Ｍｅｔｈｏｄｓ　Ａｎｄ　Ａｐｐａｒａｔｕｓ　Ｆｏｒ　Ｄｅｐｅｎｄｅｎｃｙ−ｂａｓｅｄ　Ｉｍｐａｃｔ　Ｓｉｍｕｌａｔｉｏｎ　ａｎｄ　Ｖｕｌｎｅｒａｂｉｌｉｔｙ　Ａｎａｌｙｓｉｓ」と題する弁理士整理番号第SOM９２００２０００５ＵＳ１が付された米国特許出願において開示された技法を採用することができる。しかしながら、他の影響シミュレーション技法も使用可能である。
【００７８】
　故障マネージャ２６０は、根本原因分析器２８０または影響分析器２７０のいずれかによって故障の候補として識別されたコンポーネントに対し、適切な「健全さのチェック」すなわちテストを実行する。すなわち、故障マネージャは、根本原因分析器２８０または影響分析器２７０の指示によって、かかるテストを実行し（すなわち、これらのモジュールに対するインタフェースとして機能し）、それに結果を報告することができる。しかしながら、根本原因分析器２８０または影響分析器２７０は、故障マネージャとは独立してそれら自身のテストを実行することも可能である。
【００７９】
　故障マネージャは、好ましくは、特定用途向けまたは特定リソース向けのツールの集合から成り、これによって、テストされているコンポーネントが適性に機能しているか否かを判定可能であることは理解されよう。このため、関連ツールによってコンポーネントをテストした後、故障マネージャは、そのコンポーネントが「機能している」か、または「機能していない」かを示すメッセージを戻すことができる。これらのツールは、自動化されているもの、および／または手作業によるものとすることができる。自動化の一例として、いわゆる「ピング」プログラムが、ネットワーク接続性をチェックする。対象の遠隔システムがピングに応答した場合、これはオンラインであり、そのネットワークプロトコルスタック（および全ての基礎にあるハードウエア、例えばネットワークアダプタ、ケーブル、中間ネットワークコンポーネント等）は機能している。遠隔システムが応答しない場合、少なくとも何かが不調であることがわかり、別のツール（複数のツール）（の集合）を用いて問題を決定することができる。このように、故障マネージャはピングプログラムを用いることができ、更に、分散型コンピューティング環境のコンポーネントをテストするために必要な他のツールを、いくつでも、またどんな種類のものでも、使用可能である（例えば、心拍検出、ステータス指示等）。
【００８０】
　トポロジ発生器２６５は、ウエブアプリケーション、データベースインスタンス、およびトランザクション等、大量の極めて動的なコンポーネントから成る分散型システムの全体的なトポロジ（の副集合）を確立する。トポロジ発生器２６５を用いる一例は、特定のクライアントシステム１０５の要求を満たすのに関与する分散型システムのコンポーネントを表示することである。依存性モデル（またはその部分）を、トポロジ発生器２６５の必要（例えば、より迅速な検索のためにキャッシュすること）に従って、トポロジデータベース２５５に格納する。トポロジ発生器２６５は、上述のシステムにおいて、トポロジデータベース２５５と直接対話する唯一のコンポーネントであることを注記しておく。トポロジ発生器は、先に引用し、同時に出願された、「Ｍｅｔｈｏｄｓ　Ａｎｄ　Ａｐｐａｒａｔｕｓ　Ｆｏｒ　Ｔｏｐｏｌｏｇｙ　Ｄｉｓｃｏｖｅｒｙ　ａｎｄ　Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ　ｏｆ　Ｄｉｓｔｒｉｂｕｔｅｄ　Ａｐｐｌｉｃａｔｉｏｎｓ　ａｎｄ　Ｓｅｒｖｉｃｅｓ」と題する弁理士整理番号第ＳＯＭ９２００２０００３ＵＳ１が付された米国特許出願において開示された技法を採用することができる。しかしながら、他のトポロジ発生技法も使用可能である。
【００８１】
　ここで図３を参照すると、図面に示され、ここで詳細に説明する、依存性管理を行うためのシステムの様々な機能コンポーネント／モジュールを実施するのに適切なコンピュータシステムの一般化ハードウエアアーキテクチャを例示するブロック図が示されている。依存性管理システムの個々のコンポーネント、すなわち、グラフィカルユーザインタフェース２８５、アプリケーション層２００、サービス層２０５、およびミドルウエア層２１０（図２）に関連したコンポーネントは、図３に示すようなアーキテクチャを有する１つ以上のコンピュータシステム上で実施可能であることは理解されよう。図２に示す他のコンポーネント、例えばリソース層２１５に関連したコンポーネントも、同様のコンピュータシステム上で実施可能である。
【００８２】
　図示のように、コンピュータシステムは、プロセッサ２９０、メモリ２９２、およびＩ／Ｏデバイス２９４に従って実施することができる。「プロセッサ」という言葉は、ここで用いる場合、例えば、ＣＰＵ（中央演算処理装置）および／または他の処理回路を含むもの等、あらゆる処理デバイスを含むことが意図されることは認められよう。「メモリ」という言葉は、ここで用いる場合、例えば、ＲＡＭ、ＲＯＭ、固定メモリデバイス（例えばハードドライブ）、着脱可能メモリデバイス（例えばディスケット）、フラッシュメモリ等、プロセッサまたはＣＰＵに関連したメモリを含むことを意図する。更に、「入力／出力デバイス」または「Ｉ／Ｏデバイス」という言葉は、ここで用いる場合、例えば、処理ユニットにデータを入力するための１つ以上の入力デバイス（例えばキーボード）、および／または、処理ユニットに関連した結果を提示するための１つ以上の出力デバイス（例えばＣＲＴディスプレイおよび／またはプリンタ）を含むことを意図する。
【００８３】
　また、「プロセッサ」という言葉は２つ以上の処理デバイスを指す場合があること、更に、１つの処理デバイスに関連した様々な要素を他の処理デバイスによって共有可能であることも理解されよう。
【００８４】
　従って、ここで述べるような本発明の方法論を実行するための命令またはコードを含むソフトウエアコンポーネントは、関連する１つ以上のメモリデバイス（例えばＲＯＭ、固定または着脱可能メモリ）に格納することができ、利用する準備が整った場合、部分的にまたは全体的に（例えばＲＡＭに）ロードし、ＣＰＵによって実行することができる。
【００８５】
　ここで図４を参照すると、ブロック図が、本発明の一実施形態によるサービスの機能依存性モデルを示す。更に具体的には、図４は、図１に示したもののような電子商取引システムにおける様々なコンポーネント間の機能アプリケーション依存性の図を示す。この機能依存性モデルは、分散型システムの機能コンポーネントおよびそれらの依存性の双方を表す。このため、このモデルは、ビジネスの観点から見ると微小と考えられる一般的なサービス間の依存性を規定する。これは、機能モデルが、ビジネスサービス内で発生する依存性とは関連しないことを意味する。かかる分解は、サービスを実施するために用いられている特定の製品の範囲において意味を成し、以下で、図５を参照して更に詳細に説明する。
【００８６】
　コンポーネント間の依存性は、矢印として示す。１つの矢印は、常に依存者から先行者を指し示す。機能コンポーネントは、（副）サービスであって、カスタマに終端間サービスを提供するためにサービス提供業者によって展開する必要がある。後者はサービスレベルアグリーメントにおいて規定されている。機能モデルは、終端間サービスの設計に焦点を当て、終端間サービスの技術的実現に関する詳細事項を抽象化する。この詳細事項とは、サービス提供のために用いられている製品、それらの位置（ローカルまたは遠隔システム）、提供業者のドメイン（すなわち、提供業者自身がそのサービスの一部をユーザに透過的な別のサービス提供業者に外部委託するか否か）等である。
【００８７】
　図示のように、ｅ−ビジネスアプリケーション３００サービスは、ビジネスロジックのホストとなるためにウエブアプリケーションサービス３０５に依存する。適正に機能するために、ウエブアプリケーションサービス３０５は、２つの更に別のサービスを必要とする。電子商取引ウエブサイトの静的コンテンツはウエブサービス３１０によって提供され、一方、バックエンドデータベースサービス３３０は、カスタマに提供されているｅ−ビジネスアプリケーション３００の動的コンテンツ（製品記述、ユーザおよび製造業者のデータ、ショッピングカート、ユーザのプロファイルおよび好み、支払い情報等）を格納する。ウエブサービス３１０は、それ自体、２つのサービス、すなわち、ホスト名をＩＰアドレスにマッピングするための名前サービス３１５、および、ネットワーク接続性のためのＩＰサービス３２０に依存する。
【００８８】
　依存性関係は推移的であること、すなわち、所与のコンポーネントの依存者は、コンポーネント自体に加えて、コンポーネントの先行者（複数の先行者）も必要とすることを思い出されよう。このため、ＩＰサービス３２０およびデータベースサービス３３０に加えて、全ての図示したサービスは、オペレーティングシステム（ＯＳ）３２５のサービスの存在を必要とする。簡潔さのため、ハードウエアコンポーネントに対するＯＳ３２５の依存性関係は図示しないが、それらは機能モデル内に存在している。
【００８９】
　ここで図５を参照すると、ブロック図は、本発明の一実施形態によるサービスの構造依存性モデルを示す。更に具体的には、図５は、図１に示したもののような電子商取引システムにおける様々なコンポーネント間の構造アプリケーション依存性の図を示す。
【００９０】
　この構造依存性モデルは、以下の方法で機能的モデル（図４）を拡張する。構造依存性モデルは、ビジネスサービスの実施を処理し、具体的な製品およびそれらの論理的（モジュール、コンポーネント）および物理的（ファイル、共有ライブラリ）アーキテクチャに焦点を当てる。構造依存性モデルは、ソフトウエアコンポーネントの詳細な説明すなわちシステムインベントリを捕捉する。システムインベントリは、通常、様々なシステムレポジトリ、または、例えば被管理リソース２２０の構成ファイルのような、明確に規定された場所に記録されている。
【００９１】
　構造モデルは単一のシステムのコンポーネントを処理するが、これは、他のシステムがホストとなるサービスおよびアプリケーションに対する参照を維持することができることを注記しておく。なぜなら、システム上に位置する構成ファイルがこの情報を含むことができるからである。システムレポジトリの例は、ＩＢＭ　ＡＩＸ　Ｏｂｊｅｃｔ　Ｄａｔａ　Ｍａｎａｇｅｒ（ＯＤＭ）、Ｌｉｎｕｘ　Ｒｅｄ　Ｈａｔ　Ｐａｃｋａｇｅ　Ｍａｎａｇｅｒ（ＲＰＭ）、またはＭｉｃｒｏｓｏｆｔ　Ｗｉｎｄｏｗｓ（登録商標）　Ｒｅｇｉｓｔｒｙを含むが、これらに限定されるわけではない。ソフトウエアコンポーネントに関する情報は、通常、ソフトウエアパッケージのインストールおよび展開の間に補足される。加えて、構造モデルは、矢印として示す様々なシステムコンポーネント間の依存性を含む。明確さのため、図５において、ビジネスサービスの名前は引用符を用いずに示すが、構造モデルの要素の名前は引用符を用いて示す。
【００９２】
　十分に承認されたドメイン名ｗｓｌａｂ８．ｗａｔｓｏｎ．ｉｂｍ．ｃｏｍ４００を有するシステムは、以下のコンポーネントのホストとして働く。ｅ−ビジネスアプリケーション（機能モデルにおいて規定されたビジネスサービス）。これは、ｓｔｏｒｅｆｒｏｎｔｓｅｒｖｌｅｔｓ４１０として実施され、後者はアプリケーションのビジネスロジックを内包する。ウエブアプリケーションサービスは、ＩＢＭ　ＷｅｂＳｐｈｅｒｅバージョン３．５　４１５によって実現され、ウエウサービスはＩＢＭ　ＨＴＴＰ　Ｓｅｒｖｅｒバージョン１．３．６　４２０によって実現される。ＩＰサービスは、デフォルトのＩＰプロトコルスタック４３０によって実施され、オペレーティングシステム（ＯＳ）は、Ｗｉｎ（ｄｏｗｓ）ＮＴバージョン４４２５である。
【００９３】
　十分に承認されたドメイン名ｒｓｌａｂ２．ｗａｔｓｏｎ．ｉｂｍ．ｃｏｍ４０５を有するシステムは、以下のコンポーネントのホストとして働く。（ＩＢＭ）ＤＢ２　Ｕｎｉｖｅｒｓａｌ　Ｄａｔａｂａｓｅ（ＵＤＢ）バージョン５．２　４３５によって実施されるデータベースサービス、および、ここでは（ＩＢＭ）Ａｄｖａｎｃｅｄ　Ｉｎｔｅｒａｃｔｉｖｅ　Ｅｘｃｅｃｕｔｉｖｅ（ＡＩＸ）バージョン４．３．３　４４０であるオペレーティングシステム。
【００９４】
　ここで図６を参照すると、ブロック図は、本発明の一実施形態による、機能、構造、および動作依存性モデルによって記述されるサービスライフサイクルを示す。更に具体的には、図６は、上述した機能モデル５００と構造モデル５１０との間の関係を示し、第３の依存性モデルすなわち動作モデル５２０を導入する。これらの３つのモデルによって、本発明は、それらの全ライフサイクルの間、すなわち、インストール段階から設置および展開段階、更に動作または実行時段階まで、サービスを追跡することができる。
【００９５】
　先に説明したように、機能モデル５００は、ビジネスサービスの設計に関し、従って、ビジネスシステムの設計時に捕捉される。いったん、機能モデル５００が記述するシステムが、インスタンス化または展開されると（ステップ５０５）、構造モデル５１０が確立される。構造モデル５１０の様々なコンポーネントがインスタンス化され（ステップ５１５）、それらの間の実行時の結合が確立されると、動作モデル５２０が生成される。動作モデルは、実行時に、先に説明したモデルの特徴を提示する。ここで、上述の概念を示すいくつかの状況を説明する。
【００９６】
　ウエブアプリケーションサーバ３０５は、ＩＢＭ　ＷｅｂＳｐｈｅｒｅ４１５によって実施される。後者の１つ以上のインスタンスを、ｗｅｂｓｐｈｅｒｅ−ｄａｅｍｏｎ５４５と呼ぶ。ここで、ウエブ（またはＷＷＷ）サービス３１０は、２つの製品、すなわちＡｐａｃｈｅ１．３．４　５２５およびＬｏｔｕｓ　Ｄｏｍｉｎｏ５３０によって実施される。これらの製品の実行中のインスタンスは、ｈｔｔｐ　ｄａｅｍｏｎｓ「ｈｔｔｐｄ」５５０として識別することができる。データベースサービス３３０は、２つの製品、すなわち、Ｏｒａｃｌｅ　ｖ７　５３５およびＤＢ２　ＵＤＢ４３５によって実施される。しかしながら、動作モデル５２０ではサーバプロセスは見えないので、Ｏｒａｃｌｅ　ｖ７　５３５のインスタンスはアクティブではない。これに対して、ＤＢ２　ＵＤＢ４３５の４つのインスタンスは実行中である。このことは、動作モデル５２０における４つのＤＢ２　ｄａｅｍｏｎ「ｄｂ２ｄ」５５５の存在からわかる。名前サーバ３１５は、ＢＩＮＤバージョン５．６　５４０によって実施される。ＢＩＮＤの実行中のインスタンスは、動作モデル５２０において、「ｎａｍｅｄ」５６０として観察することができる。
【００９７】
　依存性は、機能モデルから構造モデルおよび動作モデルへと伝搬することを注記しておく。これが必要である理由は、実行中のアプリケーションインスタンスからは、適正に機能するために、他のアプリケーションインスタンス（複数のインスタンス）のどれが必要であるかを判定することができないからである。
【００９８】
　一部のアプリケーションインスタンスは短命であるので、動作モデル５２０は高度に動的であり、潜在的に極めて大きい。機能および構造依存性モデルとは対照的に、動作モデル５２０は、レポジトリにもデータベースにも格納されないが、オンデマンドで、必要な程度に、計算される。
【００９９】
　ここで図７を参照すると、ブロック図は、本発明の一実施形態による、機能、構造、および動作依存性モデル間の関係を示す。更に具体的には、図７は、３つの依存性モデルに用いるデータテンプレートの詳細および、これらのモデルを結び付けるための手段を一例として示す。この例は、ライフサイクル中に名前サービスを記述するためのテンプレートおよびその関連する値を詳述する。
【０１００】
　機能モデル５００に用いられる機能テンプレート６０５は、「ｈｏｓｔＮａｍｅ」（サービスのホストとなるコンピュータシステムの一意の名前）、「ｓｅｒｖｉｃｅＮａｍｅ」（サービスの名前）、および「ｃｏｍｐｏｎｅｎｔＴｙｐｅ」「このサービスが担う役割、すなわちクライアントまたはサーバ」を含む。この情報によって、分散型の環境内で、サービスを一意に識別することができる。しかしながら、本発明の精神から逸脱することなく、記述データを含む更に別のフィールドを追加することも可能である（サービスの目的の記述、このサービスに加入しているカスタマ等）。最後に、「Ａｎｔｅｃｅｄｅｎｔ」フィールドは、適正に機能するためにこのサービスが必要とするサービス（複数のサービス）を含む。
【０１０１】
　構造モデル５１０に用いられる構造テンプレート６１０は、機能テンプレート６０５のフィールドを全て含み、これによって、機能モデル５００から構造モデル５１０への移動、またはその逆の移動を行うために、機能テンプレート６０５を構造テンプレート６１０にリンクさせることができる。更に、構造テンプレート６１０は、「ｃｏｍｐｏｎｅｎｔＮａｍｅ」（プロダクトコンポーネントの名前）、「ｉｄｅｎｔｉｆｉｅｒ」（コンポーネントを識別するための全体に渡って一意の名前）、「ｖｅｒｓｉｏｎ」、「ｒｅｌｅａｓｅ」、および「ｍｏｄｉｆｉｃａｔｉｏｎ」（例えば保守またはパッチ／修理レベル）の数、「ｉｎｓｔａｌｌＳｔａｔｅ」（コンポーネントのインストールがうまく完了したか否かを示す）、および「ｐｒｏｃｅｓｓＮａｍｅ」（このプロダクトコンポーネントを実行時に識別するプロセス（複数のプロセス）の名前）を含む。更に、「Ａｎｔｅｃｅｄｅｎｔ」フィールドは、このコンポーネントが動作可能となるために必要なコンポーネント（複数のコンポーネント）を列挙する。
【０１０２】
　動作モデル５２０に用いられる動作テンプレート６１５は、フィールド「ｈｏｓｔＮａｍｅ」（サービスのホストとなるコンピュータシステムの一意の名前）、「ｐｒｏｃｅｓｓＮａｍｅ」（プロダクトコンポーネントを実行時に識別するプロセス（複数のプロセス）の名前）を含む。これらの２つのフィールドは、構造モデル５１０から動作モデル５２０への移動、またはその逆の移動を行うために、構造テンプレート６１０を動作テンプレート６１５にリンクする。更に、動作テンプレート６１５は、フィールド「ｏｐｅｒＳｔａｔｅ」（プロセスの動作的状態、すなわち実行中、割り込みを受けた、ゾンビ等）、「ｐｏｒｔＮｕｍｂｅｒ」（アプリケーションをプロセスに接続することができるＴＣＰ／ＵＤＰポートの数）、および「ｉｎｓｔａｎｃｅＩＤ」（コンピュータシステムの範囲内で様々なアプリケーションインスタンスを識別する）を含む。
【０１０３】
　３つの依存性モデルは、異なる場所で格納および計算されて、最大の効率を達成する。機能モデル５００は、管理システム６２０、すなわち、管理者１００が分散型環境と対話する制御の中心点に集められて格納される。この選択の理由のいくつかは以下の通りである。図４および６の記載に見られるように、機能モデル５００は、可能なビジネスサービスの量が限られているので、きわめてコンパクトである。更に、機能モデルは、過度に頻繁な変更を受けない。機能モデルは、ビジネスサービスをカスタマに供給した時に規定され、このサービス提供期間が終了するまで不変のままである。管理者１００は機能モデル５００のセットアップおよび更新を担うので、これを管理システム６２０の近くに保持することは当然の選択である。
【０１０４】
　図５および６の記載に見られるように、構造モデル５１０は、対照的に、ソフトウエアコンポーネントの詳細な記述すなわちシステムインベントリを捕捉する。システムインベントリは、通常、様々なシステムレポジトリ、または、例えば被管理リソース２２０の構成ファイルのような明確に規定された場所に記録されている。この結果、これはサイズが大きく（システムレポジトリの内容は、数百キロバイトから数メガバイトの間になる傾向がある）、更に、頻繁に変更される。従って、システムの構造モデル５１０を被管理リソース２２０に保持すること自体が、モデルを更新するための通信オーバーヘッドを排除し、更に、全ての被管理リソース（２２０）の構造モデル５１０が１つの場所に集中化して格納されている場合に生じる恐れのある大量の記憶の必要も無くなる。
【０１０５】
　動作モデル５２０は、図６において、極めて動的であり、非常に大きいものとして記述した。なぜなら、これは、分散型環境のコンピュータシステム上に存在する全てのアプリケーションの潜在的に多数のインスタンスおよびそれらの間の依存性関係を扱うからである。インターネット／アプリケーション／記憶サービス提供業者および外部委託者の現在のデータセンタが、数千のコンピュータシステムから成り、各々が１００近くのアプリケーションおよびシステムサービスのホストとして働くと想定すれば、現在インスタンス化されているアプリケーションおよびそれらの依存性の全てを１つの動作モデルが含むことは、非現実的である場合がある。このため、現実的な手法は、オンデマンドで動作モデルの関連部分を計算することである（ステップ６２５）。これが依存性サービス２４５の目的であり、その機能を図８に詳述する。
【０１０６】
　ここで図８を参照すると、ブロック図は、本発明の一実施形態による、終端間依存性の計算に関与するコンポーネントを示す。更に具体的には、図８は、終端間依存性を問い合わせて計算するために用いられる様々なコンポーネント間のデータフローを示す。被管理リソース２２０は、それらのシステムインベントリ、構成ファイル、およびそれらの様々な依存性のＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ　Ｍａｒｋｕｐ　Ｌａｎｇｕａｇｅ）記述を提供可能であると仮定する。しかしながら、本発明に従って、いかなる記述フォーマットも使用可能であることを注記しておく。この情報をどのように取得するかについての詳細は、以下の通りである。
【０１０７】
　１つの直接的な方法は、システムおよびそのアプリケーションおよびサービス内に適切な手段を提供することである。この情報は、フラットＸＭＬファイル７４０において記述され、ウエブサーバ７２５を介してシステムの他のコンポーネントに利用可能である。
【０１０８】
　あるいは、依存性サービス２４５は、適切なサービス依存性情報を発生するために、システムレポジトリ７４５に格納された情報を利用する。この情報は、ウエブサーバ７３０を介してシステムの他のコンポーネントに利用可能である。　
【０１０９】
　第３に、被管理リソース２２０は、ＣＩＭプロバイダ７５０と呼ばれる手段エージェントによって、それらの情報を提示する。これは、Ｄｉｓｔｒｉｂｕｔｅｄ　Ｍａｎａｇｅｍｅｎｔ　Ｔａｓｋ　Ｆｏｒｃｅ（ＤＭＩＴＦ）によって提案されたように、ＣＩＭ　Ｏｂｊｅｃｔ　Ｍａｎａｇｅｒ（ＣＩＭＯＭ）７３５と対話する。次いで、ＣＩＭＯＭは、必要な情報を、対象のコンポーネントに提示する。
【０１１０】
　図８の中央に、サービスサーバ２０５の一部である様々な管理サービスが示されている。これらは、名前サービス７００、取引業者サービス７１０、イベントサービス７１５、および依存性サービス２４５である。依存性サービス２４５は、その管理システム、または通信プロトコル（例えばＪａｖａ（登録商標）　Ｒｅｍｏｔｅ　Ｍｅｔｈｏｄ　Ｉｎｖｏｃａｔｉｏｎ（ＲＭＩ））を用いてアプリケーション層２００に位置するいずれかの管理アプリケーションを介して管理者１００の問い合わせによってトリガされ、それらを処理し、結果を管理者１００に送り返す。依存性サービス２４５の主なタスクは、以下の通りである。
【０１１１】
　（ａ）管理システムまたはアプリケーション層２００に位置するいずれかの管理アプリケーションとの対話。管理システムは、依存性サービス２４５のアプリケーションプログラミングインタフェース（ＡＰＩ）に問い合わせを発する。
【０１１２】
　（ｂ）「ドリルダウン」方法を提示し、サービスの識別子を受け取ると、以下を戻す。
　　（ｉ）その直接の先行者の記述、すなわちサービスを表すノードの下の第１のレベル、または
　　（ｉｉ）サービスを表すノードの下のサブグラフ全体、
　　（ｉｉｉ）依存性グラフの任意のサブセット（所与のノードの下のレベルｍからｎ）。
【０１１３】
　（ｃ）サービスの依存性を対象として、同じ機能によって「ドリルアップ」方法を提供する。
【０１１４】
　（ｄ）非管理オブジェクトのクラスおよび特性のための情報を収集しフィルタに通すための追加の方法がある。
【０１１５】
　（ｅ）ｈｔｔｐ（ＨｙｐｅｒＴｅｘｔ　Ｔｒａｎｓｐｏｒｔ　Ｐｒｏｔｏｃｏｌ）上で問い合わせを発し、それに（管理者１００が規定したような）フィルタリングルールを適用することによって、被管理リソース２２０から依存性情報を取得する。
【０１１６】
　（ｆ）情報をデータ構造に組み合わせて、これをＸＭＬドキュメントとして管理システムに送り返す。
【０１１７】
　上述のように、完全に分散型の性質を有するため、本発明は、全ての関与するシステムに対する負荷をできる限り小さく抑えることを目指している。本発明は、被管理リソース２２０から管理システムを分離させ、時間のかかるフィルタおよび連結動作を依存性サービス２４５に内包し、これを様々なシステム上で再現することができる。従って、問い合わせ動作のための最高レベルの並列処理を達成することができる。なぜなら、依存性サービス２４５のインスタンスの選択は、管理システムによって柔軟に実行可能だからである。
【０１１８】
　別の重要な利点は、（極めて大きく高度に動的な）動作モデル５２０は、特定の場所に格納されるのではなく、オンデマンドで段階的に計算されるということである。構造モデル５１０の異なる部分は、被管理リソース２２０に格納される。従って、管理システムは、常に最も新しい情報を受信するが、なお、綿密なキャッシュ政策に従ってそれを自由に格納することができる。
【０１１９】
　ここで図９を参照すると、ブロック図は、本発明の一実施形態による依存性サービスのコンポーネントを示す。更に具体的には、図９は、依存性サービス２４５を実施するコンポーネントを示す。図示のように、情報提供業者８１０は、アプリケーション層２００の管理アプリケーションと対話する。情報提供業者８１０は、Ｊａｖａ（登録商標）　ＲＭＩを介して問い合わせ８４０を受信し、その結果をＸＭＬドキュメント８３５として送り返す。問い合わせ８４０は、基本情報（サービスおよびコンポーネントの記述または特定の属性の値の検索等）に関連付けたり、または、より複雑な問題（依存性モデルに対するドリルアップまたはドリルダウン動作等）を扱ったりすることができる。
【０１２０】
　リソースプロキシ８００は、リソースウエブサーバ７２５とインタフェースすることによって、被管理リソースのＸＭＬ記述８３０を取得する役割を担う。リソースプロキシ８００は、ｈｔｔｐを介して問い合わせをリソースウエブサーバ７２５に送ることによって、これを行う（ステップ８２７）。ＸＭＬ記述８３０を受け取ると、リソースプロキシ８００は、次いで、それらをパーズし、問い合わせ表現（選択およびフィルタリングルール）をそれらに適用し、結果を問い合わせリゾルバ８０５に転送する。
【０１２１】
　問い合わせリゾルバ８０５のタスクは、所与のホスト名について、どのリソースプロキシ８００が要求に応えることができ、この要求を適切なリソースプロキシ８００に転送することができるかを突き止めるためのマップを維持することである。
【０１２２】
　要素ＵＲＩリゾルバ８１５は、所与のホスト名について、ユニフォームリソースロケータ（ＵＲＩ）を構築し、更に、その結果を、呼び出し側へと返送する役割を担う。呼び出し側は、情報提供業者８１０または問い合わせリゾルバ８０５のいずれかである可能性がある。
【０１２３】
　ＸＭＬサブクラスリゾルバ８２０は、ヘルパモジュールであり、ＸＭＬＳスキーマ８２５内で規定されるタイプのシステムに従って特定のタイプの要素の位置を特定する役割を担う。この例は、タイプ「Ｓｅｒｖｉｃｅ」（ウエブアプリケーションサービス、ウエブサービス、または名前サービス等）を有するか、タイプ「Ｈｏｓｔ」（サービスおよび依存性が配置されたホスト）を有するか、またはタイプ「Ｄｅｐｅｎｄｅｎｃｙ」を有する、１つ以上のＸＭＬドキュメント内の全ての要素に対する問い合わせを行うことである。
【０１２４】
　ここで図１０を参照すると、フロー図が、本発明の一実施形態による、依存性サービス（例えば依存性サービス２４５）を呼び出してその結果を収集するための動作のステップを示す。この方法は、管理者１００か、または、図２に示すようなアプリケーション層２００の一部である管理アプリケーションのいずれかによって開始する。
【０１２５】
　この方法は、ブロック９００において開始し、以下のように進行する。最初に、通常は機能モデルから、ビジネスサービスを選択する（ステップ９０５）。なぜなら、管理者は、分散型システムが提供するビジネスサービスに関心があるからである。ビジネスサービスを選択すると、構造モデルに問い合わせて、ビジネスサービスの提供に関与するホストの選択を提供する。これは、分散型システムの全ホスト上に存在する構造モデルの位置を特定することか、または、（効率の目的のため）管理システムに格納された（周期的に更新される）サービス／ホストルックアップ表に問い合わせることのいずれかによって行うことができる。このルックアップ表は、分散型システムに存在するサービスとホストとの間のマッピングを含む。次いで、管理者は、自由裁量で、ホストを選択する（ステップ９１０）。
【０１２６】
　更に、管理者は、問い合わせを作成する（ステップ９１５）。問い合わせパラメータの例は、横断の方向（サービス依存者に向かって、またはその先行者に向かって）、横断の深さ（例えば直接の先行者／依存者のみ、可能な先行者／依存者の全て、すなわち動作モデルの完全な推移的な終了、動作モデルのｍ番目の層とｎ番目の層との間のみ等）、属性の存在またはそれらの値のいずれかに関連するフィルタリング基準を含むが、これらに限定されるわけではない。
【０１２７】
　サービスの選択（ステップ９０５）、ホストの選択（ステップ９１０）、および問い合わせを作成するためのオプションのステップの順序をここに定めるという事実によって、（既存の技術の「ホスト中心の」手法に対して）本発明の「サービス中心の」手法が強調される。しかしながら、本発明の精神および範囲から逸脱することなく、ステップ（ステップ９０５、９１０、および９１５）の順序を変更可能であることは、関連する分野の技術を有する者には認められよう。
【０１２８】
　かかる変更の例は、ユーザに、（例えばグラフィカルユーザインタフェースによって）任意の順序で選択プロセスの３つのステップを実行する選択肢を与えること、最初にホストを選択して次いで構造モデルに問い合わせることによってそのホスト上に存在するサービスを検索し、これによって選択のためのサービスの可能な候補を限定することである。
【０１２９】
　サービスおよびホストを選択し、問い合わせを作成した後、これらのパラメータによって、依存性サービスを呼び出す（ステップ９２０）。呼び出しのモードは、同期（すなわち依存性サービスによって結果が戻されるまで呼び出し側を阻止する）、または非同期（呼び出し側は計算の間に追加のタスクを実行可能である）のいずれかとすることが可能であることを注記しておく。
【０１３０】
　依存性サービスは、動作モデルの適切な部分を計算し、呼び出しのモードに応じて、結果を呼び出し側に返送するか、または呼び出し側に、結果が利用可能であることを通知する。次いで、呼び出し側は、結果を収集し（ステップ９２５）、それらを更に処理する。この方法は、ブロック９３０において終了する。
【０１３１】
　ここで図１１を参照すると、フロー図が、本発明の一実施形態に従って機能依存性モデルを生成および更新するための管理者のタスクを示す。これが必要であるのは、新しい（ビジネス）サービスを展開および提供する場合、または、既存のモデルに変更を行う場合、または、既存の（ビジネス）サービスを提供品から外す場合である。
【０１３２】
　この方法は、ブロック１０００において開始し、以下のように進行する。管理者または管理アプリケーションは、新しいビジネスサービスを追加するべきか、または既存のサービスを消去するかを評価する（ステップ１００５）。これが必要でない場合、方法は直接ブロック１０２５に進む。その他の場合、ステップ１０１０において、サービスおよびその記述を、図７に記載した機能モデルのテンプレート６０５に入力（またはテンプレート６０５から除去）する。
【０１３３】
　次いで、ステップ１０１５において、サービス依存性すなわちその先行者に関する関係性を、機能モデルのテンプレート６０５に追加（またはテンプレート６０５から除去）する必要がある。消去の場合、サービス依存者からの依存性は、除去されるサービスの先行者を指すように調整する必要があることを注記しておく。これは、先行者の依存性内に結果として起こる重複する記述についてのチェックを必要とする場合がある。最後に、管理システムのレポジトリに、更新した機能モデルを格納する（ステップ１０２０）。この方法は、ブロック１０２５において終了する。
【０１３４】
　ここで図１２を参照すると、フロー図が、本発明の一実施形態に従って、コンピュータシステム上でハードウエア／ソフトウエアコンポーネントをインストールまたは除去することによって構造依存性モデルを更新するステップを示す。これが必要になるのは、新しいコンポーネントをホスト上に展開およびインストールする場合、またはホストから既存のコンポーネントを除去する場合である。
【０１３５】
　この方法は、ブロック１１００において開始し、以下のように進行する。新しいハードウエアコンポーネントをインストール／除去すると、オペレーションシステムによって、それらの依存性の検証および調整を通常どおり実行し、このため、ここではこれ以上詳しくは説明しない。代わりに、以下の説明は、ソフトウエアコンポーネントを追加／除去するタスクに焦点を当てる。ソフトウエア分配およびインストールを実行する管理者または管理アプリケーションは、新しいソフトウエアコンポーネントを追加するべきか、または、既存のソフトウエアコンポーネントを消去するかを評価する（ステップ１１０５）。これが必要でない場合、方法は直接ブロック１１２５に進む。その他の場合、ステップ１１１０において、ソフトウエアコンポーネントの記述は、図７に記載した構造モデルのテンプレート６１０に入力（またはテンプレート６１０から除去）する。次いで、ステップ１１１５において、ソフトウエアコンポーネントの依存性、すなわちその先行者に関する関係を、構造モデルのテンプレート６１０に追加（またはテンプレート６１０から除去）する必要がある。
【０１３６】
　消去の場合、ソフトウエアコンポーネントの依存者からの依存性は、除去されるソフトウエアコンポーネントの先行者を指すように調整する必要があることを注記しておく。これは、先行者の依存性内に結果として起こる重複する記述についてのチェックを必要とする場合がある。最後に、ホストのリソース依存性レポジトリに、更新した構造モデルを格納する（ステップ１１２０）。この方法は、ブロック１１２５において終了する。
【０１３７】
　ここで図１３を参照すると、フロー図が、本発明の一実施形態に従って動作モデルの計算を担うシステムのステップを示す。この方法は、ブロック１２００において開始し、以下のように進行する。
【０１３８】
　動作依存性モデルの計算を実行するシステムは、常時、システムが実行されるホストの特定のポートにおいて要求がないかと監視している。これは、ブロック１２０５をそれ自身に接続するループによって示される。これは、いつでもアプリケーションによって呼び出すことができる、サービスを実施するサーバプロセス（「ｄａｅｍｏｎｓ」）について標準的な挙動である。
【０１３９】
　要求を受けると、システムは、要求から入力パラメータを抽出する（ステップ１２１０）。図１０の記載において述べたように、入力パラメータの例は、対象のサービスおよびホストの名前、横断の方向、横断の深さ、属性の存在またはそれらの値のいずれかに関連したフィルタリング基準を含むが、これらに限定されるわけではない。次いで、これらの入力パラメータを用いて、動作モデルの実際の計算を実行する（ステップ１２１５）。
【０１４０】
　計算の結果、すなわち動作モデルは、次いで、呼び出しの時に規定された呼び出しのモードに従って、呼び出しアプリケーションに送出される（ステップ１２２０）。このステップの後、システムが実行しているホストの割り当てられたリソースはいずれも、解放される（ステップ１２２５）。ホストリソースの例は、メモリ、ディスクスペース、またはＣＰＵレジスタを含むが、これらに限定されるわけではない。最後に、システムはその最初の段階に戻り、続けて入来する要求がないかと監視する（ステップ１２０５）。
【０１４１】
　ここで図１４を参照すると、フロー図が、本発明の一実施形態に従って、特定のホスト上に位置するサービスの直接の先行者を検索するステップを示す。この方法は、ブロック１３００において開始し、以下のように進行する。
【０１４２】
　最初に、目的とするサービスおよびホストの名前を取得する（ステップ１３０５）。これらのパラメータは、呼び出し管理アプリケーションによって提供され、管理者から直接、または管理コンソールに到着するイベントメッセージから取得される。次いで、サービス記述を含む要素を、特定のホストの構造モデルに配置する（ステップ１３１０）。
【０１４３】
　次いで、図７に記載するような、所与のサービスの構造テンプレート６１０の先行者特性の評価（ステップ１３１５）によって、このサービスがいずれかの先行者を有するか否かを明らかにする。先行者特性が空である場合、すなわち、その要素が先行者を有しない場合、サービス要素自体を動作モデルに追加する（ステップ１３２０）。呼び出し管理アプリケーションは、これを、サービスがそれ自体のみに依存すると解釈する。次いで、この方法は、直接ブロック１３４０に進む。
【０１４４】
　しかしながら、先行者特性が１つ以上の要素を含む場合、サービスは先行者を有する。このため、方法はブロック１３２５に進み、サービス要素を動作モデルに追加する。更に、依存性要素を動作モデルに追加する（ステップ１３３０）。依存性要素の範囲内で、構造テンプレート６１０の先行者特性の内容を依存性要素の直後の動作モデルにコピーすることによって、（１つ以上の）先行者要素のリストを追加する（ステップ１３３５）。かかる実施の典型的な例は、依存性要素をＸＭＬタグとして規定し、先行者のリストを追加し、次いでＸＭＬタグを閉じることである。この方法は、動作モデルの内容を呼び出し側に送出することによって、ブロック１３４０において終了する。
【０１４５】
　ここで図１５を参照すると、フロー図が、本発明の一実施形態に従って、指定されたホスト上に配置されたサービスの先行者を再帰的に検索するステップを示す。更に具体的には、図１５は、指定されたホスト上に配置されたサービスの全ての（すなわち直接または間接の）先行者を再帰的に検索する際の深さ優先戦略の使用を示す。例えば、クライアント／サーバ結合が別のシステムを指す場合、再帰的問い合わせは、システム境界をまたぎ、更には提供業者の境界をもまたぐ場合があることを注記しておく。
【０１４６】
　この方法は、ブロック１４００において開始し、以下のように進行する。最初に、目的とするサービスおよびホストの名前を取得する（ステップ１４０５）。これらのパラメータは、呼び出し管理アプリケーションまたはＡＰＩ機能によって提供され、管理者から直接、または管理コンソールに到着するイベントメッセージから取得される。
【０１４７】
　次いで、サービス記述を含む要素を、指定されたホストの構造モデルに配置し、サービスリストに入力する（ステップ１４１０）。このステップの完了後、サービスリストが空であるか否かを評価する（ステップ１４１５）。サービスリストが要素を含む場合、リストの第１の要素を選択し、モデルに追加し（ステップ１４２０）、リストから消去する。
【０１４８】
　図７に示したような、所与のサービスの構造テンプレート６１０の先行者特性の評価によって、このサービスが先行者を有するか否かが明らかになる。次いで、先行者特性に列挙された要素を、別個のリストすなわち先行者リストに移す（ステップ１４２５）。このリストは空である可能性がある。
【０１４９】
　次いで、この方法は直接ブロック１４３０に進み、先行者リストがいずれかの要素を含むか否かを評価する。先行者リストが空である（すなわちサービスが更に別の先行者を有しない）場合、方法はブロック１４１５に戻り、サービスリスト内に次のエントリがある場合、続いてこれを処理する。
【０１５０】
　しかしながら、先行者リストが１つ以上の要素を含む場合、サービスは先行者を有する。このため、方法はブロック１４３５に進み、先行者リストから先行者サービスを除去し、グラフ構造の深さ優先の横断を可能とするため、これをサービスリストの冒頭に挿入する。更に、動作モデルに、先行者（および実際の依存性を表すリンク）を追加する（ステップ１４４０）。方法のこの部分は、先行者リストが空になるまで実行される。リストが空になった場合、方法はブロック１４１５に進み、（最終的に拡張された）サービスリストの処理に進む。サービスリストが空になった場合、動作モデルの内容を呼び出し側に送出して、方法は終了する（ステップ１４４５）。
【０１５１】
　ここで図１６を参照すると、フロー図が、本発明の一実施形態による、指定されたホスト上に配置されたサービスの直接依存者を検索するステップを示す。この方法はブロック１５００において開始し、以下のように進行する。
【０１５２】
　最初に、目的とするサービスおよびホストの名前を取得する（ステップ１５０５）。これらのパラメータは、呼び出し管理アプリケーションによって提供され、管理者から直接、または管理コンソールに到着するイベントメッセージから取得される。次いで、サービス記述を含む要素を、指定されたホストの構造モデルに配置する（ステップ１５１０）。
【０１５３】
　次いで、先行者が目的のサービス要素である要素を全て検索し、このサービスが依存者を有するか否かを明らかにする。結果が空である場合（ステップ１５１５）、すなわち、要素が依存者を有しない場合、サービス要素自体を、動作モデルに追加する（ステップ１５２０）。呼び出し管理アプリケーションは、これを、サービスがそれ自体にのみ依存していると解釈する。次いで、方法は直接ブロック１５４０に進む。
【０１５４】
　しかしながら、先行者が目的のサービス要素である要素を全て検索した結果、１つ以上の要素が得られた場合、サービスは先行者を有する。このため、方法はブロック１５２５に進み、動作モデルにサービス要素を追加する。更に、動作モデルに依存性要素を追加する（ステップ１５３０）。依存性要素の範囲内で、依存性要素の直後に、動作モデルに（１つ以上の）依存者要素を追加する（ステップ１５３５）。かかる実施の典型的な例は、依存性要素をＸＭＬタグとして規定し、依存者のリストを追加し、次いでＸＭＬタグを閉じることである。方法は、動作モデルの内容を呼び出し側に送出して、ブロック１５４０において終了する。
【０１５５】
　ここで図１７を参照すると、フロー図が、本発明の一実施形態に従って、指定されたホスト上に配置されたサービスの依存者を再帰的に検索するステップを示す。更に具体的には、図１７は、指定されたホスト上に配置されたサービスの全ての（すなわち直接または間接の）依存者を再帰的に検索する際の深さ優先戦略の使用を示す。例えば、クライアント／サーバ結合が別のシステムを指す場合、再帰的問い合わせは、システム境界をまたぎ、更には提供業者の境界をもまたぐ場合があることを注記しておく。
【０１５６】
　この方法は、ブロック１６００において開始し、以下のように進行する。最初に、目的とするサービスおよびホストの名前を取得する（ステップ１６０５）。これらのパラメータは、呼び出し管理アプリケーションまたはＡＰＩ機能によって提供され、管理者から直接、または管理コンソールに到着するイベントメッセージから取得される。次いで、サービス記述を含む要素を、指定されたホストの構造モデルに配置し、サービスリストに入力する（ステップ１６１０）。
【０１５７】
　ステップ１６１０の完了後、サービスリストが空であるか否かを評価する（ステップ１６１５）。サービスリストが要素を含む場合、リストの最初の要素を選択し、モデルに追加し（ステップ１６２０）、リストから消去する。図７に示すようなサービスリストの現在の要素の存在について、全ての構造テンプレート６１０の先行者特性を評価することによって、このサービスが依存者を有するか否かが明らかになる。
【０１５８】
　次いで、先行者特性に対象のサービスが現れる要素のサービス名を、別個のリストすなわち依存者リストに移す（ステップ１６２５）。このリストは空である可能性がある。あるいは、構造テンプレート６１０が依存者特性を含む場合（すなわち、双方向リンクによって依存性を表す）、依存者特性の内容を依存者リストにコピーする。
【０１５９】
　次いで、方法は直接ブロック１６３０に進み、依存者リストが要素を含むか否かを評価する。依存者リストが空である（すなわち、サービスが更に別の依存者を有しない）場合、方法はブロック１６１５に戻り、サービスリスト内に次のエントリが存在する場合、続いてこれを処理する。
【０１６０】
　しかしながら、依存者リストが１つ以上の要素を含む場合、サービスは依存者を有する。このため、方法はブロック１６３５に進み、依存者リストから依存者サービスを除去し、グラフ構造の深さ優先の横断を可能とするため、これをサービスリストの冒頭に挿入する。更に、動作モデルに、依存者（および実際の依存性を表すリンク）を追加する（ステップ１６４０）。方法のこの部分は、依存者リストが空になるまで実行される。リストが空になった場合、方法はブロック１６１５に進み、（最終的に拡張された）サービスリストの処理に進む。サービスリストが空になった場合、動作モデルの内容を呼び出し側に送出して、方法は終了する（ステップ１６４５）。
【０１６１】
　ここで図１８を参照すると、本発明の一実施形態に従って、依存性サービスアプリケーションプログラミングインタフェース（ＡＰＩ）の例が示されている。このテーブルは、所与のサービスおよびホストの名前について適切な動作モデルの受信を発生、送出、および要求することができるベースＡＰＩを含む。ＡＰＩは、１つ以上のパラメータ（図示せず）を用いて、ＡＰＩが用いる（機能記述において指定される）特性を識別可能であることは、当業者には認められよう。
【０１６２】
　具体的には、「ｇｅｔＡｎｔｅｃｅｄｅｎｔｓ（ｐａｒａｍｅｔｅｒｓ）」ＡＰＩは、指定されたホスト上に配置されたサービスの直接の先行者を検索する。「ｇｅｔＡｎｔｅｃｅｄｅｎｔｓＲｅｃｕｒｓｉｖｅ（ｐａｒａｍｅｔｅｒｓ）」ＡＰＩは、再帰的「ドリルダウン」を実行する、すなわち、特定のホスト上に配置された所与のサービスの先行者を全て検索する。「ｇｅｔＤｅｐｅｎｄｅｎｔｓ（ｐａｒａｍｅｔｅｒｓ）」ＡＰＩは、特定のホスト上に配置された所与のサービスの直接の依存者を検索する。「ｇｅｔＤｅｐｅｎｄｅｎｔｓＲｅｃｕｒｓｉｖｅ（ｐａｒａｍｅｔｅｒｓ）」ＡＰＩは、再帰的「ドリルアップ」を実行する、すなわち、これは、特定のホスト上に配置された所与のサービスの依存者を全て検索する。「ｇｅｔＤｅｐｅｎｄｅｎｃｉｅｓ（ｐａｒａｍｅｔｅｒｓ）」ＡＰＩは、特定のサービスについて全ての再帰的依存性（すなわち、先行者および依存者の双方）のリストを生じる。
【０１６３】
　「ｇｅｔＴｒａｎｓａｃｔｉｏｎＤｅｐｅｎｄｅｎｃｉｅｓ（ｐａｒａｍｅｔｅｒｓ）」ＡＰＩは、特定のトランザクションに関与するハードウエアおよびソフトウエアコンポーネントおよびそれらの依存性のリストを検索する。「ｇｅｔＴｒａｎｓａｃｔｉｏｎＣｏｍｐｏｎｅｎｔｓ（ｐａｒａｍｅｔｅｒｓ）」ＡＰＩは、特定のトランザクションに関与するハードウエアおよびソフトウエアコンポーネントのリストを検索する。「ｇｅｔＨｏｓｔＤｅｐｅｎｄｅｎｃｉｅｓ（ｐａｒａｍｅｔｅｒｓ）」ＡＰＩは、特定のホスト上に配置された全サービスについて全ての再帰的依存性のリストを生じる。「ｇｅｔＨｏｓｔＣｏｍｐｏｎｅｎｔｓ（ｐａｒａｍｅｔｅｒｓ）」ＡＰＩは、特定のホスト上にインストールされたハードウエアおよびソフトウエアコンポーネントのリストを検索する。「ｇｅｔＥｘｔｅｒｎａｌＳｅｒｖｉｃｅＤｅｐｅｎｄｅｎｃｉｅｓ（ｐａｒａｍｅｔｅｒｓ）」ＡＰＩは、ドメイン境界を横切る、すなわち、別のサービス提供業者の制御のもとで、特定のサービスのための全ての再帰的依存性（すなわち先行者および依存者の双方）のリストを生じる。最後に、「ｇｅｔＲｅｆｅｒｅｎｃｉｎｇＤｅｐｅｎｄｅｎｃｉｅｓ（ｐａｒａｍｅｔｅｒｓ）」ＡＰＩは、ホスト上の所与のサービスについて、上方向および下方向の双方の依存性の参照を戻す。
【０１６４】
　本発明の例示的な実施形態について、添付図面を参照して説明したが、本発明は、それらの正確な実施形態に限定されるわけではなく、本発明の範囲および精神から逸脱することなく、当業者によって、様々な他の変更および修正を行い得ることは理解されよう。
【０１６５】
　まとめとして、本発明の構成に関して以下の事項を開示する。
【０１６６】
（１）コンピューティング環境において情報を管理するコンピュータを用いた方法であって、
　前記コンピューティング環境のコンポーネントに関連した情報を取得するステップと、
　前記取得した情報の少なくとも一部から、前記コンピューティング環境の前記コンポーネントの少なくとも一部に関連した１つ以上の関係の存在を判定するステップと、を具備し、前記１つ以上の関係の存在を判定するステップは、前記コンピューティング環境の少なくとも１つのコンポーネントに関連した全ライフサイクルを考慮に入れることができることを特徴とする、方法。
　（２）前記コンピューティング環境は分散型コンピューティング環境から成ることを特徴とする、（１）の方法。
　（３）前記コンピューティング環境は自律型コンピューティング環境から成ることを特徴とする、（１）の方法。
　（４）前記コンピューティング環境の前記コンポーネントの少なくとも一部に関連した１つ以上の関係の存在を判定するステップは、更に、前記コンピューティング環境の少なくとも２つのコンポーネントに関連した異質性を考慮することができることを特徴とする、（１）の方法。
　（５）前記コンピューティング環境の前記コンポーネントの少なくとも一部に関連した１つ以上の関係の存在を判定するステップは、更に、前記コンピューティング環境に関連した１つ以上のドメインに及ぶ１つ以上のコンポーネントを考慮することができることを特徴とする、（１）の方法。
　（６）前記コンピューティング環境の前記コンポーネントの少なくとも一部に関連した１つ以上の関係の存在を判定するステップは、更に、機能カテゴリ分類、構造カテゴリ分類、および動作カテゴリ分類から成る形態でコンポーネント依存性を計算することを含むことを特徴とする、（１）の方法。
　（７）前記コンポーネント依存性の前記機能カテゴリ分類は、ノードのグラフとしてモデル化された機能要素を備え、１つ以上の第１のノードは、該１つ以上の第１のノードが依存する１つ以上の第２のノードにリンクされ、更に、前記１つ以上の第１のノードに依存する１つ以上の第３のノードにリンクされていることを特徴とする、（６）の方法。
　（８）前記ノードは前記コンピューティング環境におけるコンポーネントを表すことを特徴とする、（７）の方法。
　（９）前記コンポーネントは少なくとも１つの依存者および先行者として規定されることを特徴とする、（８）の方法。
　（１０）前記ノードのグラフはノード間のリンクを含み、前記リンクは依存性を表すことを特徴とする、（９）の方法。
　（１１）前記依存性は、依存者および先行者を含む１対１の関係であることを特徴とする、（１０）の方法。
　（１２）前記機能要素は、前記構造カテゴリ分類における構造要素とリンクされたものおよび相互参照されたものの１つである、（７）の方法。
　（１３）前記コンポーネント依存性の前記構造カテゴリ分類は、ノードのグラフとしてモデル化された構造要素を備え、１つ以上の第１のノードは、該１つ以上の第１のノードが依存する１つ以上の第２のノードにリンクされ、更に、前記１つ以上の第１のノードに依存する１つ以上の第３のノードにリンクされていることを特徴とする、（６）の方法。
　　（１４）前記構造要素は、前記コンピューティング環境の前記コンポーネントの展開の側面を規定する情報を提供することを特徴とする、（１３）の方法。
　（１５）前記構造カテゴリ分類の前記構造要素に関する情報は、システム管理者およびオペレータの少なくとも一方によって、展開動作の間、１つ以上のレポジトリに格納されていることを特徴とする、（１４）の方法。
　（１６）前記構造要素に関する情報は、１つ以上のアプリケーションプログラミングインタフェースによって前記１つ以上のシステムレポジトリから利用可能になることを特徴とする、（１５）の方法。
　（１７）前記コンポーネント依存性の前記動作カテゴリ分類は、ノードのグラフとしてモデル化された動作要素を備え、１つ以上の第１のノードは、該１つ以上の第１のノードが依存する１つ以上の第２のノードにリンクされ、更に、前記１つ以上の第１のノードに依存する１つ以上の第３のノードにリンクされていることを特徴とする、（１６）の方法。
　（１８）前記動作要素は、前記構造カテゴリ分類における構造要素とリンクされたものおよび相互参照されたものの１つである、（１７）の方法。
　（１９）前記動作カテゴリ分類は、前記構造カテゴリ分類および前記機能カテゴリ分類の少なくとも１つから計算されることを特徴とする、（６）の方法。
　（２０）前記コンポーネント依存性の前記カテゴリ分類は、グラフ表現として表されることを特徴とする、（６）の方法。
　（２１）前記グラフ表現のエッジの少なくとも一部は、追加の限定情報によって注釈が付けられていることを特徴とする、（２０）の方法。
　（２２）前記グラフ表現は、単一方向および双方向のうち一方であることを特徴とする、（２０）の方法。
　（２３）前記グラフ表現は、有向無周期性グラフおよび有向周期性グラフのうち一方であることを特徴とする、（２０）の方法。
　（２４）グラフ表現は、上方向、下方向、および横方向のうち１つで通過可能であることを特徴とする、（２０）の方法。
　（２５）グラフ表現によって表される前記依存性情報は、１つ以上のアプリケーションプログラミングインタフェースに従ってアクセス可能であることを特徴とする、（２０）の方法。
　（２６）前記カテゴリ分類のうち１つ以上は計算された後に永続的に格納されることを特徴とする、（６）の方法。
　（２７）前記カテゴリ分類のうち１つ以上は計算された後に永続的に格納されないことを特徴とする、（６）の方法。
　（２８）コンポーネントは、サービス、アプリケーション、ミドルウエア、ハードウエア、デバイスドライバ、オペレーティングシステム、および前記コンピューティング環境に関連したシステムのうち１つであることを特徴とする、（１）の方法。
　（２９）前記情報取得ステップは、更に、１つ以上の直接関与するシステムおよび１つ以上のプロキシシステムのうち少なくとも１つによって情報を得ることを含むことを特徴とする、（１）の方法。
　（３０）更に、前記１つ以上の関係の少なくとも一部に関連した変更の履歴を維持するステップを具備することを特徴とする、（１）の方法。
　（３１）コンピューティング環境において情報を管理するための装置であって、
　少なくとも１つのプロセッサであって、（ｉ）前記コンピューティング環境のコンポーネントに関連した情報を取得する、および（ｉｉ）前記取得した情報の少なくとも一部から、前記コンピューティング環境の前記コンポーネントの少なくとも一部に関連した１つ以上の関係の存在を判定する、ように動作し、前記１つ以上の関係の存在を判定することは、前記コンピューティング環境の少なくとも１つのコンポーネントに関連した全ライフサイクルを考慮に入れることができる、プロセッサと、
　前記少なくとも１つのプロセッサに結合され、前記１つ以上の判定された関係に関連した情報を格納するように動作するメモリと、
を具備することを特徴とする、装置。
　（３２）前記コンピューティング環境は分散型コンピューティング環境から成ることを特徴とする、（３１）の装置。
　（３３）前記コンピューティング環境は自律型コンピューティング環境から成ることを特徴とする、（３１）の装置。
　（３４）前記少なくとも１つのプロセッサは、更に、前記格納された情報の少なくとも一部を検索するように動作することを特徴とする、（３１）の装置。
　（３５）前記コンピューティング環境の前記コンポーネントの少なくとも一部に関連した１つ以上の関係の存在を判定する動作は、更に、前記コンピューティング環境の少なくとも２つのコンポーネントに関連した異質性を考慮することができることを特徴とする、（３１）の装置。
　（３６）前記コンピューティング環境の前記コンポーネントの少なくとも一部に関連した１つ以上の関係の存在を判定する動作は、更に、前記コンピューティング環境に関連した１つ以上のドメインに及ぶ１つ以上のコンポーネントを考慮することができることを特徴とする、（３１）の装置。
　（３７）前記コンピューティング環境の前記コンポーネントの少なくとも一部に関連した１つ以上の関係の存在を判定する動作は、更に、機能カテゴリ分類、構造カテゴリ分類、および動作カテゴリ分類から成る形態でコンポーネント依存性を計算することを含むことを特徴とする、（３１）の装置。
　（３８）コンポーネントは、サービス、アプリケーション、ミドルウエア、ハードウエア、デバイスドライバ、オペレーティングシステム、および前記コンピューティング環境に関連したシステムのうち１つであることを特徴とする、（３１）の装置。
　（３９）前記情報取得動作は、更に、１つ以上の直接関与するシステムおよび１つ以上のプロキシシステムのうち少なくとも１つによって情報を得ることを含むことを特徴とする、（３１）の装置。
　（４０）前記少なくとも１つのプロセッサは、更に、前記１つ以上の関係の少なくとも一部に関連した変更の履歴を維持するように動作することを特徴とする、（３１）の装置。
　（４１）コンピューティング環境において情報を管理するための製造の物品であって、１つ以上のプログラムを含む機械読み取り可能媒体を具備し、前記プログラムは、実行された場合、
　前記コンピューティング環境のコンポーネントに関連した情報を取得するステップと、
　前記取得した情報の少なくとも一部から、前記コンピューティング環境の前記コンポーネントの少なくとも一部に関連した１つ以上の関係の存在を判定するステップと、を実施し、前記１つ以上の関係の存在を判定するステップは、前記コンピューティング環境の少なくとも１つのコンポーネントに関連した全ライフサイクルを考慮に入れることができることを特徴とする、物品。
【図面の簡単な説明】
【０１６７】
【図１】本発明の機構と相互作用して情報を生成することができるクライアント−サーバアプリケーションアーキテクチャの一例を示すブロック図である。
【図２】本発明の一実施形態による、依存性管理を行うためのシステムを例示するブロック図である。
【図３】本発明の一実施形態による、依存性管理を提供するためのシステムを実施するのに適切なコンピュータシステムの一般化ハードウエアアーキテクチャを例示するブロック図である。
【図４】本発明の一実施形態によるサービスの機能依存性モデルを例示するブロック図である。
【図５】本発明の一実施形態によるサービスの構造依存性モデルを例示するブロック図である。
【図６】本発明の一実施形態による、機能、構造、および動作依存性モデルによって記述されるサービスライフサイクルを例示するブロック図である。
【図７】本発明の一実施形態による、機能、構造、および動作依存性モデル間の関係を例示するブロック図である。
【図８】本発明の一実施形態による、終端間依存性を計算する際に関与するコンポーネントを例示するブロック図である。
【図９】本発明の一実施形態による、依存性サービスのコンポーネントを例示するブロック図である。
【図１０】本発明の一実施形態による、依存性サービスを呼び出すためのアクションのステップを例示するフロー図である。
【図１１】本発明の一実施形態による、機能依存性モデルを生成し更新するための管理者のタスクを例示するフロー図である。
【図１２】本発明の一実施形態による、コンピュータシステム上のハードウエア／ソフトウエアコンポーネントを設置または除去することによって構造依存性モデルを更新するステップを例示するフロー図である。
【図１３】本発明の一実施形態による、動作モデルの計算を担うシステムのステップを例示するフロー図である。
【図１４】本発明の一実施形態による、特定のホスト上に位置するサービスの直接先行者を検索するステップを例示するフロー図である。
【図１５】本発明の一実施形態による、特定のホスト上に位置するサービスの先行者を再帰的に検索するステップを例示するフロー図である。
【図１６】本発明の一実施形態による、特定のホスト上に位置するサービスの直接依存者を検索するステップを例示するフロー図である。
【図１７】本発明の一実施形態による、特定のホスト上に位置するサービスの依存者を再帰的に検索するステップを例示するフロー図である。
【図１８】本発明の一実施形態による、依存性サービスアプリケーションプログラミングインタフェースの例を示す。
【図１】
2004103015.tif 000003
【図２】
2004103015.tif 000004
【図３】
2004103015.tif 000005
【図４】
2004103015.tif 000006
【図５】
2004103015.tif 000007
【図６】
2004103015.tif 000008
【図７】
2004103015.tif 000009
【図８】
2004103015.tif 000010
【図９】
2004103015.tif 000011
【図１０】
2004103015.tif 000012
【図１１】
2004103015.tif 000013
【図１２】
2004103015.tif 000014
【図１３】
2004103015.tif 000015
【図１４】
2004103015.tif 000016
【図１５】
2004103015.tif 000017
【図１６】
2004103015.tif 000018
【図１７】
2004103015.tif 000019
【図１８】
2004103015.tif 000020