JP2005539320A - 自己管理分散計算システムを構築する方法、コンピュータ・プログラム、およびデータ処理システム（自己管理計算処理システム） - Google Patents

Abstract

【課題】「自律的要素」からなる自己管理分散計算処理システムを構築する方法、コンピュータ・プログラム、およびデータ処理システムを提供すること。
【解決手段】「自律的要素」からなる自己管理分散計算処理システムを構築する方法、コンピュータ・プログラム、およびデータ処理システムが開示される。自律的要素はサービス・セットを提供し、それを他の自律的要素に提供することができる。自律的要素間の関連には、そのようなサービスの提供および消費が含まれる。これらの関連は、それが、システムの各部分が実装され、または配置されるときではなく、システムの動作中に確立され得るという意味で、「遅延バインド」される。これらの関連は、関連が、時間の経過にとともに開始し、終了し、変化し得るという意味で、動的である。これらの関連は、その関連を確立する要素間の相互通信のプロセスによってそこに到達するという意味で、折衝されるものである。

Description

本発明は、一般に、改良型のデータ処理システムに関し、詳細には、ハードウェアおよびソフトウェア・コンポーネントを管理する方法および装置に関する。より詳細には、本発明は、機能要件を達成するためにハードウェアおよびソフトウェア・コンポーネントを自動的に識別し、自己管理する方法および装置に関する。

現代の計算処理技術は、限りなく複雑で、絶え間なく変化する環境を生み出している。１つのそのような環境がインターネットであり、これを「インターネットワーク」ともいう。インターネットは、データ転送、および送信側ネットワークのプロトコルから受信側ネットワークによって使用されるプロトコルへメッセージの変換を処理するゲートウェイによって相互に結合された、おそらく異種のコンピュータ・ネットワークの集合である。大文字で始まるとき、「インターネット」という用語は、ＴＣＰ／ＩＰプロトコル・スイートを使用するネットワークおよびゲートウェイの集まりをいう。現在、インターネットを介してデータを転送する際に最も一般に用いられる方法は、単に「Ｗｅｂ（ウェブ）」とも呼ばれる、ワールド・ワイド・ウェブ環境を用いるものである。ファイル転送プロトコル（ＦＴＰ）やゴーファ（Gopher）といった、情報を転送する他のインターネット・リソースも存在するが、Ｗｅｂほどの人気を得ていない。Ｗｅｂ環境では、サーバおよびクライアントは、様々なデータ・ファイル（例えばテキスト、静止画像、音声、動画など）の転送を処理する公知のプロトコルである、ハイパーテキスト転送プロトコル（ＨＴＴＰ）を用いてデータ・トランザクションを行う。様々なデータ・ファイル中の情報は、標準ページ記述言語であるハイパーテキスト・マークアップ言語（ＨＴＭＬ）によってユーザへの提示のためにフォーマットされる。また、インターネットは、ブラウザを用いてユーザにアプリケーションを転送するのにも広く使用される。しばしば、ユーザは、インターネットを介してソフトウェア・パッケージをサーチし、それを入手することがある。

他の種類の複雑なネットワーク・データ処理システムには、大企業での作業を円滑に行わせるために作成されたものが含まれる。多くの場合、これらのネットワークは、世界中の様々な場所にある諸地域にまたがることがある。また、これらの複雑なネットワークは、業務を行うための仮想製品ネットワークの一部としてインターネットを使用することもある。これらのネットワークは、そのネットワーク内で使用されるソフトウェアを管理し、更新する必要によりさらに複雑になる。

ソフトウェアが発展してますます「自律的」になるにつれて、ハードウェアおよびソフトウェアを管理する作業は、管理者によって行われるのではなく、ますます、コンピュータ自体によって行われるようになる。コンピュータ・システムを管理する現在の機構は、コンピュータ・システムが自己構成、自己最適化、自己防御、および自己修復を行う「自律的」プロセスに向かいつつある。例えば、多くのオペレーティング・システムおよびソフトウェア・パッケージは、ユーザ指定要件に基づいて特定のソフトウェア・コンポーネントを自動的に探す。これらのインストールおよび更新機構は、しばしば、更新または必要とされるコンポーネントが存在するかどうか調べるために事前に選択された場所でインターネットに接続する。更新などのコンポーネントが存在する場合、ユーザにメッセージが提示され、そこでユーザにそのコンポーネントをダウンロードし、インストールすべきかどうか尋ねる。そのようなシステムの一例がオープンソースのＤｅｂｉａｎ ＧＮＵ／Ｌｉｎｕｘ（デビアン・グヌー／リナックス）オペレーティング・システムの一部であるパケット管理プログラム「ｄｓｅｌｅｃｔ」である。いくつかのウイルス検査プログラムはバックグラウンドで（Ｕｎｉｘ（Ｒ）用語を用いるために「デーモン」プロセスとして）走り、ウイルスを自動的に検出し、それらを除去し、損傷を修復することができる。
ElmasriおよびNavathe、「データベース・システムの基本（Fundamentalsof Database Systems）」、第3版、アディソン・ウェスレイ（Addison Wesley）、（2000）、41〜66頁

「自律的」計算処理に向けての次のステップには、ユーザ介入を必要とせずに必要なハードウェアおよびソフトウェア・コンポーネントを識別し、インストールし、管理することが伴う。したがって、当分野では、ハードウェアおよびソフトウェア・コンポーネントを識別し、インストールし、構成し、管理するより自動化されたプロセスが求められている。

本発明は、「自律的要素」からなる自己管理分散計算処理システムを構築する方法、コンピュータ・プログラム、データ処理システムを対象とする。自律的要素は、サービス・セットを提供し、それを他の自律的要素に提供することができる。自律的要素間の関連には、そのようなサービスの提供および消費が含まれる。これらの関連は、それが、システムの各部分が実装され、または展開されるときではなく、システムの動作中に確立され得るという意味で、「遅延バインド」される。これらの関連は、関連が、時間の経過にとともに開始し、終了し、変化し得るという意味で、動的である。これらの関連は、その関連を確立する要素間の相互通信のプロセスによってそこに到達するという意味で、折衝（negotiated）されるものである。制約条件および基本設定を含むポリシーが自律的要素に対して指定され得る。自律的要素によって確立される任意の関連は、その自律的要素のポリシーと整合性が取れなければならない。関連の過程で、自律的要素は、その挙動をそのポリシーと整合するように調整しようと試みなければならない。

本発明の新規の特徴であると考えられる特性は、添付の特許請求の範囲に記載されている。しかしながら、本発明自体、ならびにその好ましい使用形態、さらなる目的および利点は、以下の例示的実施形態の詳細な説明を添付の図面と併せて読めば、最もよく理解されるであろう。

次に図を参照すると、図１には、本発明が実施され得るデータ処理システムのネットワークの絵図が示されている。ネットワーク・データ処理システム１００は、本発明が実施され得るコンピュータのネットワークである。ネットワーク・データ処理システム１００はネットワーク１０２を含み、それは、ネットワーク・データ処理システム１００内で相互に接続された様々な装置およびコンピュータの間の通信リンクを提供するのに使用される媒体である。ネットワーク１０２は、有線、無線通信リンクや、光ファイバ・ケーブルなどの接続を含み得る。

図示の例では、サーバ１０４は、記憶装置１０６と共にネットワーク１０２に接続される。また、クライアント１０８、１１０、１１２もネットワーク１０２に接続される。これらのクライアント１０８、１１０、１１２は、例えば、パーソナル・コンピュータやネットワーク・コンピュータとすることができる。図示の例では、サーバ１０４は、クライアント１０８〜１１２に、ブート・ファイル、オペレーティング・システム・イメージ、アプリケーションなどのデータを提供する。クライアント１０８、１１０、１１２はサーバ１０４に対するクライアントである。ネットワーク・データ処理システム１００は、図示しない他のサーバ、クライアント、他のデバイスを含み得る。図示の例では、ネットワーク・データ処理システム１００は、伝送制御プロトコル／インターネット・プロトコル（ＴＣＰ／ＩＰ）プロトコル・スイートを使用して相互にやりとりするネットワークおよびゲートウェイの世界規模の集まりを表すネットワーク１０２を含むインターネットである。インターネットの中心には、データおよびメッセージを経路指定する何千もの商用、政府機関、教育機関などのコンピュータ・システムからなる、主要ノードまたはホスト・コンピュータ間の高速データ通信回線のバックボーンがある。当然ながら、ネットワーク・データ処理システム１００は、例えば、イントラネット、ローカル・エリア・ネットワーク（ＬＡＮ）、広域ネットワーク（ＷＡＮ）など、いくつかの異なる種類のネットワークとして実施することもできる。図１は一例を示すためのものであり、本発明をアーキテクチャ的に限定するものではない。

図２を参照すると、本発明の好ましい実施形態による、図１のサーバ１０４などのサーバとして実施され得るデータ処理システムの構成図が示されている。データ処理システム２００は、システム・バス２０６に接続された複数のプロセッサ２０２、２０４を含む対照型マルチプロセッサ（ＳＭＰ）システムとすることができる。代替として、シングル・プロセッサ・システムを用いることもできる。システム・バス２０６には、メモリ・コントローラ／キャッシュ２０８も接続され、それがローカル・メモリ２０９へのインターフェイスを提供する。入出力バス・ブリッジ２１０はシステム・バス２０６に接続され、入出力バス２１２へのインターフェイスを提供する。メモリ・コントローラ／キャッシュ２０８および入出力バス・ブリッジ２１０は、図示ように統合され得る。

入出力バス２１２に接続された周辺装置相互接続（ＰＣＩ）バス・ブリッジ２１４は、ＰＣＩローカル・バス２１６へのインターフェイスを提供する。ＰＣＩローカル・バス２１６にはいくつかのモデムが接続され得る。典型的なＰＣＩバス実装形態は、４つのＰＣＩ拡張スロットまたはアドイン・コネクタをサポートする。図１のクライアント１０８〜１１２への通信リンクは、アドイン・ボードによってＰＣＩローカル・バス２１６に接続されたモデム２１８およびネットワーク・アダプタ２２０を介して提供され得る。

追加のＰＣＩバス・ブリッジ２２２、２２４は、追加のＰＣＩローカル・バス２２６、２２８のためのインターフェイスを提供し、そこから追加のモデムまたはネットワーク・アダプタをサポートすることができる。このようにして、データ処理システム２００は、複数のネットワーク・コンピュータへの接続を可能にする。図示のように入出力バス２１２には、直接または間接に、メモリマップ・グラフィック・アダプタ２３０およびハード・ディスク２３２も接続され得る。

図２に示すハードウェアは多様であることを当分野の技術者は理解するであろう。例えば、図示のハードウェアに加えて、またはその代わりに、光ディスク・ドライブなど他の周辺装置を使用することもできる。図示の例は、本発明に関するアーキテクチャ上の限定を示唆するためのものではない。

図２に示すデータ処理システムは、例えば、拡張対話式エグゼクティブ（ＡＩＸ）オペレーティング・システムまたはＬｉｎｕｘオペレーティング・システムを走らせる、米国ニューヨーク州アーモンク（Armonk, New York）所在のインターナショナル・ビジネス・マシーンズ社の製品、ＩＢＭ ｅＳｅｒｖｅｒ ｐＳｅｒｉｅｓシステムとすることができる。

次に図３を参照すると、本発明が実施され得るデータ処理システムを示す構成図が示されている。データ処理システム３００は、クライアント・コンピュータの一例である。データ処理システム３００は、周辺装置相互接続（ＰＣＩ）ローカル・バス・アーキテクチャを用いる。図示の例はＰＣＩバスを用いるが、アクセラレーテッド・グラフィックス・ポート（ＡＧＰ）や産業標準アーキテクチャ（ＩＳＡ）など他のバス・アーキテクチャも使用され得る。プロセッサ３０２およびメイン・メモリ３０４はＰＣＩブリッジ３０８を介してＰＣＩローカル・バス３０６に接続される。ＰＣＩブリッジ３０８は、プロセッサ３０２のための統合されたメモリ・コントローラおよびキャッシュ・メモリも含み得る。直接コンポーネント接続によって、またはアドイン・ボードを介して、ＰＣＩローカル・バス３０６への追加接続を行うこともできる。図示の例では、ローカル・エリア・ネットワーク（ＬＡＮ）アダプタ３１０、ＳＣＳＩホスト・バス・アダプタ３１２、および拡張バス・インターフェイス３１４は、直接コンポーネント接続によってＰＣＩローカル・バス３０６に接続される。それとは対照的に、オーディオ・アダプタ３１６、グラフィックス・アダプタ３１８、およびオーディオ／ビデオ・アダプタ３１９は、拡張スロットに挿入されたアドイン・ボードによってＰＣＩローカル・バス３０６に接続される。拡張バス・インターフェイス３１４は、キーボードおよびマウス・アダプタ３２０、モデム３２２、および追加メモリ３２４のための接続を提供する。小型コンピュータ・システム・インターフェイス（ＳＣＳＩ）ホスト・バス・アダプタ３１２は、ハード・ディスク・ドライブ３２６、テープ・ドライブ３２８、およびＣＤ−ＲＯＭドライブ３３０のための接続を提供する。典型的なＰＣＩローカル・バス実装形態は、３つまたは４つのＰＣＩ拡張スロットまたはアドイン・コネクタをサポートする。

オペレーティング・システムはプロセッサ３０２上で走り、図３のデータ処理システム３００内の様々なコンポーネントを調整し、その制御を実現するのに使用される。オペレーティング・システムは、マイクロソフト社から入手可能なＷｉｎｄｏｗｓ（Ｒ）ＸＰなど、市販のオペレーティング・システムとすることができる。Ｊａｖａ（Ｒ）などのオブジェクト指向プログラミング・システムは、オペレーティング・システムと共に走り、データ処理システム３００上で実行されるＪａｖａ（Ｒ）プログラムまたはアプリケーションからオペレーティング・システムへの呼び出しを提供することができる。「Ｊａｖａ（Ｒ）」はサン・マイクロシステムズ社の商標である。オペレーティング・システム、オブジェクト指向オペレーティング・システム、およびアプリケーションまたはプログラムの命令は、ハード・ディスク・ドライブ３２６などの記憶装置上に位置し、プロセッサ３０２による実行のためにメイン・メモリ３０４にロードされ得る。

図３のハードウェアは実装形態に応じて変化し得ることを当分野の技術者は理解するであろう。図３に示すハードウェアに加えて、またはその代わりに、フラッシュ読取り専用メモリ（ＲＯＭ）、同等の不揮発性メモリ、光ディスク・ドライブなど、その他の内蔵ハードウェアまたは周辺装置を使用することもできる。また、本発明のプロセスはマルチプロセッサ・データ処理システムにも適用され得る。

別の例として、データ処理システム３００は、何らかの種類のネットワーク通信インターフェイスを利用せずにブート可能なように構成された独立型システムとすることもできる。別の例として、データ処理システム３００は、オペレーティング・システム・ファイルまたはユーザ生成データあるいはその両方を格納する不揮発性メモリを提供するためにＲＯＭまたはフラッシュＲＯＭあるいはその両方を用いて構成された、携帯情報端末（ＰＤＡ）装置とすることもできる。

図３に示す例および前述の例は、アーキテクチャ上の限定を示唆するものではない。例えば、データ処理システム３００は、ＰＤＡの形を取る以外に、ノート型コンピュータやハンドヘルド・コンピュータとすることもできる。データ処理システム３００は、キオスクやＷｅｂアプライアンスとすることもできる。

本発明は、自己管理分散計算処理システムを構築する方法および装置を対象とするものである。そのような計算処理システム（例えばデータベース、記憶システム、Ｗｅｂサーバ、ファイル・サーバなど）を構成するハードウェアおよびソフトウェア・コンポーネントは、「自律的要素」と呼ばれる自己管理コンポーネントである。自律的要素は従来の計算処理機能（データベースなど）を付加的自己管理機能と結合する。図４は、本発明の好ましい実施形態による自律的要素を示す図である。図４に示す好ましい実施形態によれば、自律的要素４００は、管理ユニット４０２および機能ユニット４０４を含む。管理ユニットと機能ユニットの間の分離は、単に概念的なものにすぎず、自律的要素が、図４に示すように明確に別個のユニットに分離される必要はないことを当分野の技術者は理解するであろう。

管理ユニット４０２は、自律的要素４００の自己管理機能を扱う。特に、管理ユニット４０２は、監視／制御インターフェイス４１４で示すように、自律的要素４００での目標セットに従って機能ユニット４０４を調整し、管理するためのものである。また、管理ユニット４０２は、アクセス制御インターフェイス４１６で示すように、機能ユニット４０４へのアクセスを、機能ユニット４０４を使用する許可を持つ他のシステム・コンポーネント（他の自律的要素など）に制限するためのものでもある。管理ユニット４０２は、（入力チャネル４０６や出力チャネル４０８を介するなどして）他の自律的要素との関連を確立し、維持するためのものでもある。

機能ユニット４０４は、自律的要素４００の意図された機能に応じて、他のシステム・コンポーネントによって（入力チャネル４１０を介するなどして）提供されるサービスを消費し、（出力チャネル４１２を介するなどして）他のシステム・コンポーネントにサービスを提供する。例えば、自律的データベース要素は、データベース・サービスを提供し、自律的記憶要素は記憶サービスを提供する。自律的要素４００などの自律的要素は、ソフトウェア・コンポーネントとすることも、ハードウェア・コンポーネントとすることも、両者の何らかの組み合わせとすることもできることに留意すべきである。自律的計算処理の１つの目標は、所与の機能の基礎となる実装形態間の厳格な区別を行わずに、抽象化の機能レベルで計算処理サービスを提供することである。

自律的要素は、（それ自体自律的要素であり得る）他のコンポーネントにサービスを提供し、または他のコンポーネントからサービスを受け取り、あるいはその両方を行うことによって動作する。自律的要素がそのように協働するためには、自律的要素が、必要とされる機能を提供するその他のコンポーネントを探し出し、それらとの関連を確立するための機構を必要とする。図５は、本発明の好ましい実施形態に従って構築されたそのような機構を示す図である。

自律的要素である「要求側コンポーネント」５００は、その機能を達成するために別のコンポーネントのサービスを必要とする。好ましい実施形態では、そのような機能は、規則および目標のポリシーの観点から定義され得る。ポリシー・サーバ・コンポーネント５０２は、計算処理システム中の他の自律的要素のためのポリシーを定める自律的要素である。図５で、ポリシー・サーバ・コンポーネント５０２は、要求側コンポーネント５００が従うための規則および目標のポリシーを定め、このポリシーを要求側コンポーネント５００に伝える。ネットワーク通信の状況では、例えば、必要とされる暗号による保護の標準をポリシーに含まれる規則とし、所望のサービス品質（ＱｏＳ）をポリシーの目標とすることができる。

要求側コンポーネント５００の指定されたポリシーを推進するために、要求側コンポーネント５００は、さらに別のコンポーネントからのサービス（例えば、データの暗号化）を必要とする。そのようなサービスを獲得するために、要求側コンポーネント５００は、別の自律的要素であるディレクトリ・コンポーネント５０４に照会する。ディレクトリ・コンポーネント５０４は、好ましくは、必要とされる機能を提供するコンポーネントに機能要件をマップする一種のデータベースである。ディレクトリ・サービスでのデータベース・スキーマの一例を図７に示す。

好ましい実施形態では、ディレクトリ・コンポーネント５０４は、ＷＳＤＬ（Ｗｅｂサービス記述言語）などの標準化ディレクトリ・サービス方式、およびプログラムが特定のサービスを提供する実体を探し出し、それらのサービスとどのようにしてやりとりし、トランザクションを実行するか自動的に判定するＵＤＤＩ（汎用的な記述、発見および統合）などのシステムを使用して、ディレクトリ・サービスを提供することができる。ＷＳＤＬは、インターナショナル・ビジネス・マシーンズ社、アリバ社、マイクロソフト社などの企業の代表者らによって作成された、ワールドワイド・ウェブ・コンソーシアムが検討中の規格案である。ＵＤＤＩバージョン３は、Ｗｅｂサービス・アプリケーションおよびサービスに使用されている現在の仕様である。ＵＤＤＩに対する将来の策定および変更は、ＯＡＳＩＳ（構造化情報標準推進機構）が取り扱う。

ディレクトリ・コンポーネント５０４は、要求側コンポーネント５００に、要求側コンポーネント５００が必要とされるコンポーネント５０６のサービスを利用できるようにする情報を提供する。そのような情報には、必要とされるコンポーネント５０６とやりとりできるようにする（ネットワーク・アドレスなどの）アドレスや、要求側コンポーネント５００が必要とされるコンポーネント５０６にバインドし、それを利用できるようにするダウンロード可能コードまたはダウンロード可能コードへのアドレスや、要求側コンポーネント５００が必要とされるコンポーネント５０６のサービスを利用できるようにする他の任意の適当な情報が含まれ得る。

ディレクトリ・コンポーネント５０４などのディレクトリ・サービスのためのデータベース・スキーマの一例を、実体関連（ＥＲ）図の形で図７に示す。データベース・モデル化へのＥＲ（実体関連）手法はデータベースの概念的設計のための意味を提供する。ＥＲ手法を用いると、データベース情報は、実体、実体の属性、および実体間の関連で表され、以下の定義が適用される。各定義に対応するモデル化の意味を図６に示す。図６は、ＥＲ図に関するさらなる材料を含み、参照により本明細書に組み込まれる、ElmasriおよびNavathe、「データベース・システムの基本（Fundamentals of Database Systems）」、第3版、アディソン・ウェスレイ（AddisonWesley）、（2000）、41〜66頁から転用したものである。

実体：実体とはそれに関する情報が収集される基本オブジェクトである。例えば、企業の人員に関する情報を含むデータベースでは、実体を「従業員」とすることができる。ＥＲモデルでは、実体は囲み線で表される。実体は、その別のエンティティに対する依存性に関連して、弱いまたは強いと呼ぶことができる。強い実体は、別のエンティティへの依存性を示さない。すなわち、その存在は別の実体の存在を必要としない。図６に示すように、強い実体は、単一の影なし囲み線で表される。弱い実体は、その存在を別の実体から派生させる。例えば、作業時間スケジュールが、それが従業員に関連付けられている場合にのみ存在し得る場合には、実体「作業時間スケジュール」は、その存在を実体「従業員」から派生させる。図６に示すように、弱い実体は、同心の二重囲み線で表される。

属性：属性とは、実体に記述性を与えるラベルである（名前、色など）。２種類の属性が存在する。キー属性は、実体の出現を区別する。例えば、米国では、社会保障番号は、個人を区別するキー属性である。記述子属性は、単に、実体出現を記述するだけである（性別、体重など）。図６に示すようにＥＲモデルでは、属性は、それが付随する実体（囲み線）に結合された長円形で表される。

場合によっては、属性は複数の値を持ち得る。例えば、会社を表す実体は、多値属性「場所」を持ち得る。その会社が複数の場所を持つ場合、その属性「場所」は複数の値を持つことになる。多値属性は、図６に示すように、同心の二重長円形で表される。複数のグループ化された属性から１つの複合属性が形成されることもある。複合属性は、図６に示すように、木構造で表される。派生属性とは、データベースに明示的に格納される必要がなく、実体のその他の属性から計算し、あるいは派生させることのできる属性である。派生属性は、図６に示すように破線の長円形で表される。

関連：関連とは、実体出現間に示される接続性である。関連は、１対１とすることも、１対多とすることも、多対多とすることもでき、実体による関連への関与は任意選択とすることも必須とすることもできる。例えば、企業の人員に関する情報を含むデータベースでは、従業員実体出現間の関係「〜と結婚している」は、（１人の従業員が多くとも１人の配偶者を持つとされる場合）１対１である。さらに、この関係への関与は、未婚の従業員も存在し得るため、任意選択である。第２の例として、企業ポリシーで、あらゆる従業員が厳密に１人の管理者を持つと規定している場合、従業員実体出現間の関連「〜によって管理されている」は多対１であり（多数の従業員が同じ管理者を持ち得る）、必須である（あらゆる従業員が管理者を持たねばならない）。

図６に示すように、ＥＲモデルでは、関連はひし形で表される。関連は複数の実体を伴い得る。関連での基数比（１対１、１対多など）は、文字「１」および「Ｎ」を用いて１：１または１：Ｎの基数比を示すことにより、または図６に示すような明示的構造的制約条件の使用により表される。一実体のすべてのインスタンスがその関連に関与するとき、その実体の囲み線は、二重線でその関連のひし形に接続される。そうでない場合、図６のように、その実体と関連を単線で接続する。場合によっては、関連が、実際には、その間連中の実体の１つを識別し、または定義することもある。それらの識別する関連は、やはり図６に示す、同心の二重ひし形で表される。

次に図７を見ると、本発明の好ましい実施形態による、ディレクトリ・サービスのためのデータベース・スキーマの一例が示されている。図７に示す例示的スキーマは、単に、例示的性格のものにすぎず、本発明の範囲をどんな特定のデータベース構造に限定するためのものでもないことに留意すべきである。図７は、単に、本発明の好ましい実施形態によるディレクトリ・サービス・データベースの可能な内容および編成を示すためのものにすぎない。

コンポーネント実体７００は、計算処理システム中の個々の自律的要素を表す。各コンポーネント（７００）は、いくつかのサービス（サービス実体７０４）を提供する（「〜を提供する」関連７０２）。しかしながら、コンポーネントが所望のサービスを提供するためには、そのコンポーネントは、用法実体７０６で表される特定の方法で「使用」されなければならず、それがこの３者関連「〜を提供する」７０２への第３の関与者を形成する。用法実体７０６は、当該のコンポーネントのサービスを利用するための指示を表す。これらの指示には、ソフトウェアベースの自律的要素の場合にはそのコンポーネントの実行可能コード、そのコンポーネントとやりとりするためのアドレス、または自律的要素が当該のコンポーネントと関連を結ぶことができるようにする他の任意の情報が含まれ得る。

図７で説明するスキーマなどのデータベース・スキーマは、リレーショナル、オブジェクト指向、オブジェクト・リレーショナル、または演繹的データベース管理システムといったデータベース管理システムを用いて実施され得る。また、本発明の好ましい実施形態内では、当分野で利用可能な他のデータ記憶パラダイムも可能である。

図８〜９に、本発明の好ましい実施形態による別の自律的要素のサービスを利用する自律的要素の一例を示す。図８を見ると、様々な自律的要素を含む計算処理システム８００が示されている。１つのそのような自律的要素であるＷｅｂサーバ要素８０２は、Ｗｅｂページを保持するための記憶空間を必要とする。記憶サービスを利用するために、Ｗｅｂサーバ要素８０２は、計算処理システム８００中の利用可能な自律的要素のサービスすべてを登録しているディレクトリ・コンポーネント８０４に照会する。

図８で、記憶要素８０６は、Ｗｅｂサーバ要素８０２が利用可能な記憶空間を持つ。ディレクトリ・コンポーネント８０４は、この空間の利用可能性を反映し、Ｗｅｂサーバ要素８０２の記憶ニーズに記憶コンポーネント８０６を使用するための指示をＷｅｂサーバ要素８０２に返す。図９で、Ｗｅｂサーバ要素８０２は、ディレクトリ・コンポーネント８０４によって提供された指示に従って記憶要素８０６との関連を結んでいるものとして示されている。

記憶要素８０６との関連を結ぶ際に、Ｗｅｂサーバ要素８０２は、好ましい実施形態では、記憶要素８０６およびＷｅｂサーバ要素８０２のポリシーに従ってその関連の条件を折衝する。そのような条件は、利用される個々のサービスに応じて変化することを当分野の技術者は理解するであろう。しかしながら、一般に、関連の条件は、２つの自律的要素間の相互のやりとりで導出される。このやりとりは、好ましい実施形態では、ＸＭＬ（拡張可能なマークアップ言語）、ＸＭＬスキーマ、または機械可読構造化情報を交換するための他の何らかの言語といったデータ交換言語を用いて行われ得る。

一般に、２つの自律的要素間の関連の条件は、属性／値対で表現することができ、ポリシーは、許容値および推奨値に限界を設定する規則および目標、ならびにどちら側にも強い要件がない場合に適用され得るデフォルト値を提供することができる。図１０は、本発明の好ましい実施形態による、２つの自律的要素間の関連の条件がポリシーによってどのように規定され得るかを示すＥＲ図である。

関連中の自律的要素の１つに関して、その関連の条件（例えば、ネットワーク接続でのサービス品質など）が条件実体１０００によって表される。各条件（１０００）は、条件種類実体１００４および「〜という種類を持つ」関連１００２によって表される種類を持つ。例えば、サービス品質を表す条件の場合、その条件の種類は「サービス品質」である。条件の種類は、この例ではその「名前」によって識別される（名前属性１００６）。各折衝条件（１０００）は、その関連の合意された条件と整合する複数の値（値属性１０１４）を持ち得る。例えば、２つの自律的要素は、折衝を介して、２つの異なるデータ転送速度が許容されることに合意し得る。そのような場合、「データ転送速度」条件は、異なる速度を表す２つの異なる値を持つことになる。

個々の自律的要素のポリシーにおいて、各条件の種類（１０１４）は、必須制約条件（必須制約条件属性１００８）、推奨値（推奨値属性１０１０）、デフォルト値（デフォルト値属性１０１２）、またはそれら３つの属性の何らかの組み合わせを持ち得る。任意選択で、各値設定は、それに関連付けられた、その値設定の相対的望ましさを表すスカラ・ユーティリティを持ち得る。各可能な値設定からこのユーティリティへのマッピングは、ユーティリティ関数と呼ばれる（ユーティリティ関数１０１６）。必須制約条件（１００８）は、当該の自律的要素のポリシーに従って当該の特定の種類の条件が保持し得る、（１つまたは複数の）値に対する不可侵の制約条件を表す。推奨値（１０１０）は、当該の自律的要素のポリシーに従って特定の種類の条件が保持すべき好ましい値または値の範囲を表すが、これらの推奨値は要件ではない（すなわち、折衝可能である）。デフォルト値（１０１２）は、ある関連の相手側（自律的要素）がその条件に関する基本設定を示さないときに入力され得る、個々の条件での「既定」値を表す。デフォルト値は、折衝プロセスにおいて、関連の重要性の低い詳細が最終的に決定されるようにする。ユーティリティ関数は、自律的要素が最初に構成され、または配置されるときに確立される固定の関連とすることもでき、自律的要素の配置中またはその後の任意の時点において人間がそれを入力することもでき、自律的要素が、値設定案を用いたサービスの受け取りまたは提供の影響を評価するのに用いることのできるモデルから動的に計算することもできる。

図１１は、本発明の好ましい実施形態による、要素の一方の観点から見た、２つの自律的要素間の関連の条件を折衝するプロセスを示す流れ図である。２つの要素間の関連を規定する条件の提案が相手側の要素に提示される（ブロック１１００）。相手側の自律的要素から応答が受け取られる（ブロック１１０２）。その応答が最初の提案の受諾であった場合（ブロック１１０４：Ｙｅｓ）、合意された条件に従ってその関連を開始することを指示する肯定応答が相手側の自律的要素に送られる（ブロック１１０６）。

応答が受諾でなかった場合（ブロック１１０４：Ｎｏ）、その応答が、実際には、提案した前の条件セットと異なる条件を提供する対案であるかどうかが判定される（ブロック１１０８）。応答が対案ではなかった場合（ブロック１１０８：Ｎｏ）、折衝は失敗しており、プロセスが終了する。応答が対案であった場合（ブロック１１０８：Ｙｅｓ）、その対案の条件がポリシーの要件を満たす（すなわち、任意の必須制約条件に適合する）かどうかが判定される（ブロック１１１０）。それらの条件がポリシー要件を満たさない場合（ブロック１１１０：Ｎｏ）、ポリシー要件に適合する新しい対案を生成する試みがなされる（ブロック１１１２）。その試みに成功した場合（ブロック１１１４：Ｙｅｓ）、その対案が相手側の自律的コンポーネントに提示され、プロセスはブロック１１０２に回帰して次の応答を受け取る。その試みが成功しなかった場合（ブロック１１１４：Ｎｏ）、プロセスは失敗で終了する。

しかしながら、ブロック１１０２で受け取った対案が要件を満たした場合（ブロック１１１０：Ｙｅｓ）、改善された条件（すなわち、推奨値により適合する条件）を求めるべきかどうか判定するためにポリシーが照会される（ブロック１１１８）。そうである場合（ブロック１１１８：Ｙｅｓ）、より望ましい条件を有する新しい対案を生成する試みがなされる（ブロック１１２０）。例えば、ユーティリティ関数が使用されている場合、より高いユーティリティを持つ新しい対案を生成する試みがなされるはずである。この試みに成功した場合、その対案が相手側の自律的要素に送られ（ブロック１１１６）、プロセスはブロック１１０２に回帰して次の応答を受け取る。新しい対案を形成する試みに成功せず（ブロック１１２２：Ｎｏ）、または改善された条件を求めるべきではないと判定された（ブロック１１１８）場合、相手側の要素の条件の受諾が相手側の自律的要素に送られる（ブロック１１２４）。

第２の好ましい実施形態では、折衝はより非対称な形を取り得る。この非対称な折衝では、一方の側だけが提案を生成し、相手側はそれを受諾し、または拒絶する。より詳細には、第１者は、折衝の各段階において１つまたは複数の提案を行うことも、その折衝を終了することもできる。第２者は、提案すべてを拒絶することも、提案のうちの多くとも１つを受諾することも、折衝の終了を望むと知らせることもできる。折衝は、一方の側またはその相手側が明示的にそれを終了するまで続く。第２者が提案を受諾した場合でさえも、第１者は、次の段階で、そのうちの１つが第２者にとってもより望ましいものであると判明することを願って、第１者にとってより有益な新しい提案セットを提案することができる。折衝が終了すると、最後に受諾された提案が合意とみなされる。受諾された提案がなかった場合、両者は、合意に達することに失敗している。

自己管理の重要な態様は、計算処理システムで発生し得る障害を検出し、処理し得ることである。障害の自己管理を可能にするために、本発明に様々な障害耐性方式を組み込むことができる。計算処理システムでの障害は、１つまたは複数のコンポーネントでの誤動作の結果であり得る。例えば、ディスク・ドライブが物理的に壊れ、記憶要素を動作不能にすることがある。別の障害の原因が能動的攻撃である。能動的攻撃では、１つまたは複数のコンポーネントが標的とされ、妨害される。これは、コンピュータ・ウイルス、ネットワーク攻撃（サービス拒否攻撃など）、セキュリティ違反などの結果であり得る。真に自律的な計算処理システムは、リアルタイムで自動的に障害を検出、処理できるはずである。

図１２〜１５に、本発明の好ましい実施形態による、自律的計算処理システムでの障害検出および処理の一例を示す。図１２〜１５に示す障害耐性技術は、単に、本発明の好ましい実施形態での障害検出および処理の一例にすぎず、限定を意図したものではないことを理解することは重要である。

図１２は、いくつかの自律的要素を含む計算処理システム１２００を示す図である。データベース要素１２０２は、データベース・サービスを提供し、記憶要素１２０６および冗長記憶要素１２０４の記憶サービスを利用する。図に示すように、記憶要素１２０６は、動作不能になっている。データベース要素１２０２は、記憶要素１２０６との通信を維持し、図１３に示すように、記憶要素１２０６の誤動作を検出し、その記憶要素１２０６との関連を終了する。

図１３で、記憶要素１２０６との関連を終了したことに応答して、データベース要素１２０２は、計算処理システム１２００中の他の記憶サービスを探し出すためにディレクトリ要素１３００に照会する。ディレクトリ要素１３００は、データベース要素１２０２に、記憶要素１３０２が利用可能であることを指示する。ディレクトリ要素１３００が記憶要素１３０２を利用可能な記憶要素として識別したことに応答して、データベース要素１２０２は、図１４に示すように、記憶要素１３０２との関連を結ぶ。

起こり得る任意の将来の障害に備えて冗長なサービスを回復するために、データベース要素１２０２は、図１４に示すように、記憶要素１２０４から記憶要素１３０２に状態情報をコピーする。データベース要素１２０２からの状態情報が記憶要素１３０２にコピーされると、記憶要素１３０２は、次に、図１５に示すように、動作不能な記憶要素１２０６の代わりに機能する。

図１６は、本発明の好ましい実施形態による、障害または危殆化からの回復プロセスを表す流れ図である。攻撃または誤動作による、計算処理システム中の１つまたは複数のコンポーネントの危殆化が検出された場合（ブロック１６００）、それによって潜在的に危殆化されたサービスが識別される（ブロック１６０２）。次いで、それらのサービスが終了される（ブロック１６０４）。影響を受けるサービスを危殆化されやすくする任意の特定の脆弱性が識別され得た場合、そのような脆弱性が診断される（ブロック１６０６）。計算処理システムの危殆化状態を修正する措置の計画が策定される（ブロック１６０８）。そのような修正計画の例には、セキュリティ対策を増大させること、冗長度またはエラー訂正のレベルを上げることなどが含まれる。次いで、その計画が実行されて、危殆化された要素が再供給され、サービスが復元される（ブロック１６１０）。危殆化されたサービスのいずれかがステートフルである（すなわち状態情報を必要とする）場合（ブロック１６１２：Ｙｅｓ）、再供給されたサービスにその状態情報が復元される（ブロック１６１４）。いずれの場合も、プロセスは、最終的に、任意の今後の障害に備えてブロック１６００に回帰する。

以上、本発明を完全に機能するデータ処理システムの状況で説明してきたが、本発明のプロセスは、命令などの機能記述的材料のコンピュータ可読媒体の形、および他の様々な形で配布することが可能であり、その配布を実行するのに実際に使用される信号搬送媒体の個々の種類を問わず本発明が等しく適用可能であることを、当分野の技術者が理解するであろうことに留意することは重要である。コンピュータ可読媒体の例には、フロッピー（Ｒ）・ディスク、ハード・ディスク・ドライブ、ＲＡＭ、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭなどの記録可能型媒体と、例えば無線周波数や光波伝送といった伝送形態を用いたディジタルおよびアナログ通信リンク、有線または無線通信リンクなどの伝送型媒体が含まれる。コンピュータ可読媒体は、個々のデータ処理システムでの実際の使用のために復号化される符号化形式の形を取り得る。機能記述的材料は、マシンに機能を付与する情報である。機能記述的材料には、それだけに限らないが、コンピュータ・プログラム、命令、規則、事実、計算可能関数の定義、オブジェクト、データ構造が含まれる。

本発明の記述は、図示と説明のために提示したものであり、網羅的であることも、開示の形の発明に限定することも意図していない。多くの改変形態および変形形態が当分野の技術者には明らかであろう。実施形態は、本発明の原理、実際の用途を最も適切に説明するためと同時に、当分野の技術者が、企図される個々の用途に適するような様々な改変を伴う様々な実施形態のために本発明を理解することができるように選択、記述したものである。

本出願では、セットとは、ゼロ以上のものであると定義される。複数とは、１つまたは複数のものであると定義される。セットまたは複数のサブセットとは、ゼロ以上の物を含み、そのうちのすべてが元のセットまたは複数から取られたものであるセットであると定義される。

本発明が実施され得るネットワークで接続されたデータ処理システムを示す図である。 図１のネットワークで接続されたデータ処理システム内のサーバ・システムを示す構成図である。 図１のネットワークで接続されたデータ処理システム内のクライアント・システムを示す構成図である。 本発明の好ましい実施形態による自律的要素を示す図である。 本発明の好ましい実施形態による自律的要素間のサービス提供関連を確立する機構を示す図である。 本明細書で使用するＥＲ（実体関連図）中のシンボルの凡例を示す図である。 本発明の好ましい実施形態によるディレクトリ・サービスでのデータベース・スキーマの一例を示す図である。 本発明の好ましい実施形態による別の自律的要素のサービスを利用する自律的要素の一例を示す図である。 本発明の好ましい実施形態による別の自律的要素のサービスを利用する自律的要素の一例を示す図である。 本発明の好ましい実施形態による、２つの自律的要素間の関連の条件がポリシーによってどのように規定され得るかを示すＥＲ図である。 本発明の好ましい実施形態による、要素の一方の観点から見た２つの自律的要素間の関連の条件を折衝するプロセスを示す流れ図である。 本発明の好ましい実施形態による、自律的計算処理システムにおける障害検出および処理の一例を示す図である。 本発明の好ましい実施形態による、自律的計算処理システムにおける障害検出および処理の一例を示す図である。 本発明の好ましい実施形態による、自律的計算処理システムにおける障害検出および処理の一例を示す図である。 本発明の好ましい実施形態による、自律的計算処理システムにおける障害検出および処理の一例を示す図である。 本発明の好ましい実施形態による、障害または危殆化からの回復のプロセスを示す流れ図である。

Claims (42)

1. 計算処理環境において少なくとも１つのコンポーネントを管理するコンピュータベースの方法であって、
   データ処理システム中の第１のコンポーネントによって必要とされる特定の機能を識別する段階と、
   前記特定の機能を提供するように適合された少なくとも１つの別のコンポーネントに関するディレクトリ中の情報を探し出す段階と、
   前記第１のコンポーネントおよび前記少なくとも１つの別のコンポーネントが動作するための条件を調整する段階と、および
   前記第１のコンポーネントに前記特定の機能を提供するために、前記少なくとも１つの別のコンポーネントとバインドして前記少なくとも１つの別のコンポーネントとの関連を形成する段階
   を含む方法。
2. 前記少なくとも１つの別のコンポーネントが、ハードウェア・コンポーネントおよびソフトウェア・コンポーネントの少なくとも１つを含む、請求項１に記載の方法。
3. 前記情報が、前記少なくとも１つの別のコンポーネントの少なくとも１つのアドレス、前記少なくとも１つの別のコンポーネントの用法指示、および前記少なくとも１つの別のコンポーネントのプログラム・コードの少なくとも１つを含む、請求項１に記載の方法。
4. 前記ディレクトリが前記データ処理システム中のコンポーネントを形成する、請求項１に記載の方法。
5. 前記少なくとも１つの別のコンポーネントとバインドする段階が、前記第１のコンポーネントと前記少なくとも１つの別のコンポーネントの間の通信を開始する段階を含む、請求項１に記載の方法。
6. 前記少なくとも１つの別のコンポーネントとバインドする段階が、前記少なくとも１つの別のコンポーネントを配置する段階を含む、請求項１に記載の方法。
7. 条件を調整する段階が、
   条件案セットを受け取る段階、
   前記条件案セットを検討して、前記条件案セットが所定のポリシーに適合するかどうか判定する段階、および
   前記条件案セットが前記所定のポリシーに違反することに応答して、前記所定のポリシーに適合する第２の条件案セットを送る段階
   を含む、請求項１に記載の方法。
8. 条件を調整する段階が、
   条件案セットを受け取る段階、
   前記条件案セットを検討して、前記条件案セットが所定のポリシーでの推奨値を反映しているかどうか判定する段階、および
   前記条件案セットが前記所定のポリシーでの前記推奨値を反映していないことに応答して、前記所定のポリシーでの前記推奨値をよりよく反映する第２の条件案セットを送る段階
   を含む、請求項１に記載の方法。
9. 条件を調整する段階が、
   条件案セットを受け取る段階、
   所定のポリシーを考慮して前記条件案セットを検討する段階、および
   前記条件案セットが前記所定のポリシーでの推奨値および要件を反映していないことに応答して、前記条件案セットの拒絶を指示するメッセージを送る段階
   を含む、請求項１に記載の方法。
10. 条件を調整する段階が、
    複数の条件案セットを受け取る段階、
    所定のポリシーを考慮して前記複数の条件案セットを検討する段階、および
    前記所定のポリシーに基づいて選択された前記複数の条件案セットのサブセットの受諾を指示するメッセージを送る段階
    を含む、請求項１に記載の方法。
11. 前記少なくとも１つの別のコンポーネントでの障害を検出する段階、
    前記障害を検出したことに応答して、前記少なくとも１つの別のコンポーネントとの前記関連を終了する段階、および
    前記少なくとも１つの別のコンポーネントとの前記関連を終了したことに応答して、少なくとも１つの置き換えコンポーネントとバインドする段階
    をさらに含む、請求項１に記載の方法。
12. 前記障害が誤動作である、請求項１１に記載の方法。
13. 前記障害が、前記少なくとも１つの別のコンポーネントに対する攻撃である、請求項１１に記載の方法。
14. 前記少なくとも１つの別のコンポーネントに関連付けられた状態情報と一致する状態情報を維持する少なくとも１つの冗長コンポーネントとバインドする段階、
    前記少なくとも１つの別のコンポーネントとの前記関連を終了したことに応答して、前記少なくとも１つの冗長コンポーネントから前記少なくとも１つの置き換えコンポーネントに前記状態情報を復元する段階
    をさらに含む、請求項１１に記載の方法。
15. コンポーネントを管理するためのプログラムであって、該プログラムがコンピュータに
    データ処理システム中の第１のコンポーネントによって必要とされる特定の機能を識別する機能、
    前記特定の機能を提供するように適合された少なくとも１つの別のコンポーネントに関するディレクトリ中の情報を探し出す機能、
    前記第１のコンポーネントおよび前記少なくとも１つの別のコンポーネントが動作するための条件を調整する機能、および
    前記第１のコンポーネントに前記特定の機能を提供するために、前記少なくとも１つの別のコンポーネントとバインドして前記少なくとも１つの別のコンポーネントとの関連を形成する機能
    を実現させるコンピュータ・プログラム。
16. 前記少なくとも１つの別のコンポーネントが、ハードウェア・コンポーネントおよびソフトウェア・コンポーネントの少なくとも１つを含む、請求項１５に記載のコンピュータ・プログラム。
17. 前記情報が、前記少なくとも１つの別のコンポーネントのアドレス、前記少なくとも１つの別のコンポーネントの用法指示、および前記少なくとも１つの別のコンポーネントのプログラム・コードの少なくとも１つを含む、請求項１５に記載のコンピュータ・プログラム。
18. 前記ディレクトリが前記データ処理システム中のコンポーネントを形成する、請求項１５に記載のコンピュータ・プログラム。
19. 前記少なくとも１つの別のコンポーネントとバインドする機能が、前記第１のコンポーネントと前記少なくとも１つの別のコンポーネントの間の通信を開始する機能を含む、請求項１５に記載のコンピュータ・プログラム。
20. 前記少なくとも１つの別のコンポーネントとバインドする機能が、前記少なくとも１つの別のコンポーネントを配置する機能を含む、請求項１５に記載のコンピュータ・プログラム。
21. 条件を調整する機能が、
    条件案セットを受け取る機能、
    前記条件案セットを検討して、前記条件案セットが所定のポリシーに適合するかどうか判定する機能、および
    前記条件案セットが前記所定のポリシーに違反することに応答して、前記所定のポリシーに適合する第２の条件案セットを送る機能
    を含む、請求項１５に記載のコンピュータ・プログラム。
22. 条件を調整する機能が、
    条件案セットを受け取る機能、
    前記条件案セットを検討して、前記条件案セットが所定のポリシーでの推奨値を反映しているかどうか判定する機能、および
    前記条件案セットが前記所定のポリシーでの前記推奨値を反映していないことに応答して、前記所定のポリシーでの前記推奨値をよりよく反映する第２の条件案セットを送る機能
    を含む、請求項１５に記載のコンピュータ・プログラム。
23. 条件を調整する機能が、
    条件案セットを受け取る機能、
    所定のポリシーを考慮して前記条件案セットを検討する機能、および
    前記条件案セットが前記所定のポリシーでの推奨値および要件を反映していないことに応答して、前記条件案セットの拒絶を指示するメッセージを送る機能
    を含む、請求項１５に記載のコンピュータ・プログラム。
24. 条件を調整する機能が、
    複数の条件案セットを受け取る機能、
    所定のポリシーを考慮して前記複数の条件案セットを検討する機能、および
    前記所定のポリシーに基づいて選択された前記複数の条件案セットのサブセットの受諾を指示するメッセージを送る機能
    を含む、請求項１５に記載のコンピュータ・プログラム。
25. 前記少なくとも１つの別のコンポーネントでの障害を検出する機能、
    前記障害を検出したことに応答して、前記少なくとも１つの別のコンポーネントとの前記関連を終了する機能、および
    前記少なくとも１つの別のコンポーネントとの前記関連を終了したことに応答して、少なくとも１つの置き換えコンポーネントとバインドする機能
    をさらに含む、請求項１５に記載のコンピュータ・プログラム。
26. 前記障害が誤動作である、請求項２５に記載のコンピュータ・プログラム。
27. 前記障害が、前記少なくとも１つの別のコンポーネントに対する攻撃である、請求項２５に記載のコンピュータ・プログラム。
28. 前記少なくとも１つの別のコンポーネントに関連付けられた状態情報と一致する状態情報を維持する少なくとも１つの冗長コンポーネントとバインドする機能、
    前記少なくとも１つの別のコンポーネントとの前記関連を終了したことに応答して、前記少なくとも１つの冗長コンポーネントから前記少なくとも１つの置き換えコンポーネントに前記状態情報を復元する機能
    をさらに含む、請求項２５に記載のコンピュータ・プログラム。
29. データ処理システム中の第１のコンポーネントによって必要とされる特定の機能を識別する手段と、
    前記特定の機能を提供するように適合された少なくとも１つの別のコンポーネントに関するディレクトリ中の情報を探し出す手段と、
    前記第１のコンポーネントおよび前記少なくとも１つの別のコンポーネントが動作するための条件を調整する手段と、
    前記第１のコンポーネントに前記特定の機能を提供するために、前記少なくとも１つの別のコンポーネントとバインドして前記少なくとも１つの別のコンポーネントとの関連を形成する手段と
    を含むデータ処理システム。
30. 前記少なくとも１つの別のコンポーネントが、ハードウェア・コンポーネントおよびソフトウェア・コンポーネントの少なくとも１つを含む、請求項２９に記載のデータ処理システム。
31. 前記情報が、前記少なくとも１つの別のコンポーネントのアドレス、前記少なくとも１つの別のコンポーネントの用法指示、および前記少なくとも１つの別のコンポーネントのプログラム・コードの少なくとも１つを含む、請求項２９に記載のデータ処理システム。
32. 前記ディレクトリが前記データ処理システム中のコンポーネントを形成する、請求項２９に記載のデータ処理システム。
33. 前記少なくとも１つの別のコンポーネントとバインドする手段が、前記第１のコンポーネントと前記少なくとも１つの別のコンポーネントの間の通信を開始する手段を含む、請求項２９に記載のデータ処理システム。
34. 前記少なくとも１つの別のコンポーネントとバインドする手段が、前記少なくとも１つの別のコンポーネントを配置する手段を含む、請求項２９に記載のデータ処理システム。
35. 条件を調整する手段が、
    条件案セットを受け取る手段、
    前記条件案セットを検討して、前記条件案セットが所定のポリシーに適合するかどうか判定する手段、および
    前記条件案セットが前記所定のポリシーに違反することに応答して、前記所定のポリシーに適合する第２の条件案セットを送る手段
    を含む、請求項２９に記載のデータ処理システム。
36. 条件を調整する手段が、
    条件案セットを受け取る手段、
    前記条件案セットを検討して、前記条件案セットが所定のポリシーでの推奨値を反映しているかどうか判定する手段、および
    前記条件案セットが前記所定のポリシーでの前記推奨値を反映していないことに応答して、前記所定のポリシーでの前記推奨値をよりよく反映する第２の条件案セットを送る手段
    を含む、請求項２９に記載のデータ処理システム。
37. 条件を調整する手段が、
    条件案セットを受け取る手段、
    所定のポリシーを考慮して前記条件案セットを検討する手段、および
    前記条件案セットが前記所定のポリシーでの推奨値および要件を反映していないことに応答して、前記条件案セットの拒絶を指示するメッセージを送る手段
    を含む、請求項２９に記載のデータ処理システム。
38. 条件を調整する手段が、
    複数の条件案セットを受け取る手段、
    所定のポリシーを考慮して前記複数の条件案セットを検討する手段、および
    前記所定のポリシーに基づいて選択された前記複数の条件案セットのサブセットの受諾を指示するメッセージを送る手段
    を含む、請求項２９に記載のデータ処理システム。
39. 前記少なくとも１つの別のコンポーネントでの障害を検出する手段と、
    前記障害を検出したことに応答して、前記少なくとも１つの別のコンポーネントとの前記関連を終了する手段と、
    前記少なくとも１つの別のコンポーネントとの前記関連を終了したことに応答して、少なくとも１つの置き換えコンポーネントとバインドする手段と
    をさらに含む、請求項２９に記載のデータ処理システム。
40. 前記障害が誤動作である、請求項３９に記載のデータ処理システム。
41. 前記障害が、前記少なくとも１つの別のコンポーネントに対する攻撃である、請求項３９に記載のデータ処理システム。
42. 前記少なくとも１つの別のコンポーネントに関連付けられた状態情報と一致する状態情報を維持する少なくとも１つの冗長コンポーネントとバインドする手段と、
    前記少なくとも１つの別のコンポーネントとの前記関連を終了したことに応答して、前記少なくとも１つの冗長コンポーネントから前記少なくとも１つの置き換えコンポーネントに前記状態情報を復元する手段と
    をさらに含む、請求項３９に記載のデータ処理システム。

Images