(57)【要約】本願発明の代表的な実施形態は、過去の分散プログラミングネットワークコンポーネントヒストリーに基づき、信頼性バランシングを実行するための方法およびシステムを提供する。その過去の分散プログラミングネットワークコンポーネントヒストリーは、これらの資源の有用性および信頼性を改善する目的で、コンピューティング資源およびそれらのプロセシングコンポーネントをバランスさせる。即ち、サービスの要求を受けるステップと、要求されたサービスに関連するオブジェクトインスタンスを確認するステップと、オブジェクトインスタンスとサービスとの間の依存性を確認するデータについて質問するステップと、確認されたオブジェクトインスタンスに関連する信頼性メトリックについて質問するステップと、信頼性メトリックに基づき何れのオブジェクトインスタンスがサービスを実行し得るかを決定するステップとを備える。
2004521411.tif 000002
【特許請求の範囲】
【請求項１】
分散プログラミングネットワークにおいて信頼性バランシングを実施するための方法であって、
サービスの要求を受けるステップと、
前記要求されたサービスに関連する少なくともひとつのオブジェクトインスタンスを確認するステップと、
前記少なくともひとつのオブジェクトインスタンスと前記要求されたサービスとの間の依存性を確認するデータについて質問するステップと、
前記確認された少なくともひとつのオブジェクトインスタンスに関連する少なくともひとつの信頼性メトリックについて質問するステップと、
少なくともひとつの信頼性メトリックに基づき何れのオブジェクトインスタンスが最も確かに前記サービスを実行し得るかを決定するステップと
を備えた方法。
【請求項２】
何れのオブジェクトインスタンスがより確かに前記サービスを実行し得るかを決定することは、また、前記少なくともひとつのオブジェクトインスタンスと前記要求されたサービスとの間の依存性に基づくことを特徴とする請求項１に記載された方法。
【請求項３】
何れのオブジェクトインスタンスがより確かに前記サービスを実行し得るかを決定することは、また、前記分散プログラミングネットワークの信頼性ポリシーに基づくことを特徴とする請求項１に記載された方法。
【請求項４】
前記少なくともひとつの信頼性メトリックに基づき何れのオブジェクトインスタンスが最も確かに前記サービスを実行し得るかの前記決定に基づき、前記サービスの要求を少なくともひとつのオブジェクトインスタンスとマッチングさせることを更に具備することを特徴とする請求項１に記載された方法。
【請求項５】
前記サービスの要求をマッチングさせるステップは、少なくともひとつのヒストリー、および前記分散プログラミングネットワークに含まれるオブジェクトインスタンスに関する将来のサービス要求の統計学上の予測に対応する少なくともひとつの信頼性メトリックを評価することを含むことを特徴とする請求項４に記載された方法。
【請求項６】
オペレーティング分散プログラミングネットワークにおける信頼性バランシングを実施するために構成されたシステムであって、
コントロールファブリックを介して互いに結合された複数のオブジェクトインスタンスから要求されたサービスに関連する少なくともひとつのオブジェクトインスタンスを確認すると共に、前記確認された少なくともひとつのオブジェクトインスタンスに関連する少なくともひとつの信頼性メトリックについて質問し、且つ何れのオブジェクトが前記サービスの要求を最も確かに実行し得るかについて決定するように構成されたオブジェクトレゾルバと、
前記オブジェクトレゾルバと結合され、前記少なくともひとつのオブジェクトインスタンスと前記要求されたサービスとの間の依存性を確認するデータを提供するように構成された依存性マネージャと、
少なくともひとつのオブジェクトインスタンスに関する前記少なくともひとつの信頼性メトリックを発生する少なくともひとつのオブジェクトメータと
を具備するシステム。
【請求項７】
前記オブジェクトレゾルバは、前記分散プログラミングネットワーク特有の信頼性ポリシーへのアクセス権を有するコストエバリュエータを含むことを特徴とする請求項６に記載されたシステム。
【請求項８】
前記分散プログラミングネットワーク内のオブジェクトおよびオブジェクトインスタンスに対応する累積信頼メトリックを供給するために有効性メトリックアクロスパワー(across power)およびシステム故障を保持するように構成されたことを特徴とする請求項６に記載されたシステム。
【請求項９】
動的信頼性バランシングを提供するために前記分散プログラミングネットワークの継続的モニタリングを実施することを特徴とする請求項６に記載されたシステム。
【請求項１０】
サービスの要求とオブジェクトとの間のマッチングを実施して、前記要求されたサービスを供給するための少なくともひとつのオブジェクトインスタンスの有用性を評価することにより前記サービスの要求を実行することを特徴とする請求項６に記載されたシステム。
【請求項１１】
前記オブジェクトインスタンスの有用性は、故障までの平均時間および修復までの平均時間に基づき算出されることを特徴とする請求項１０に記載されたシステム。
【請求項１２】
前記オブジェクトインスタンスの有用性は、故障までの平均時間と修復までの平均時間との和により、前記故障までの平均時間を除算したものとして算出されることを特徴とする請求項１０に記載されたシステム。
【請求項１３】
前記故障までの平均時間は、初期の瞬間から次の故障イベントまでの時間間隔であることを特徴とする請求項１２に記載されたシステム。
【請求項１４】
前記故障までの平均時間は、システムサービス信頼性を統計学的に数量化したものであることを特徴とする請求項１３に記載されたシステム。
【請求項１５】
前記故障までの平均時間は、故障から回復し且つサービスの実施を回復させるための時間であることを特徴とする請求項１２に記載されたシステム。
【請求項１６】
サービスの実施は、前記要求されたサービスを供給するために協調して動作するオブジェクトが特定の前記要求されたサービスを指定されたように提供したときに達成されることを特徴とする請求項１５に記載されたシステム。
【請求項１７】
前記修復までの平均時間は、サービスの中断を統計学的に数量化したものであることを特徴とする請求項１２に記載されたシステム。
【請求項１８】
前記オブジェクトレゾルバは、少なくともひとつのオブジェクトインスタンスまたはオブジェクトインスタンスのグループの動作に関するリアルタイムデータを評価することを特徴とする請求項６に記載されたシステム。
【請求項１９】
前記分散プログラミングネットワークの特性を変えることに基づきサービス要求ルーティングの適応を可能とすることを特徴とする請求項１８に記載されたシステム。
【請求項２０】
適応はリアルタイムに実施されることを特徴とする請求項１９に記載されたシステム。
【請求項２１】
前記サービスの要求は、前記分散されたオブジェクトの１または２以上の中から要求された使用するものを捜し又は有する、アプリケーションまたは分散プログラミングネットワークオブジェクトから生じることを特徴とする請求項６に記載されたシステム。
【請求項２２】
サービスの要求はクライアントから生じ、前記クライアントは、そのクライアントによって期待される信頼性のレベルを示す少なくともひとつの信頼性の制約を発生し又は割り当てられることを特徴とする請求項６に記載されたシステム。
【請求項２３】
前記オブジェクトレゾルバは、前記クライアントにより供給される少なくともひとつの信頼性の制約を満たす、特定オブジェクトおよびそのオブジェクトのインスタンスを示すレファレンス確認データを返すサービスであることを特徴とする請求項６に記載されたシステム。
【請求項２４】
前記オブジェクトレゾルバは、リファレンス確認データを返すサービスであり、前記リファレンス確認データは、前記サービスの要求において供給される少なくともひとつの信頼性の制約を満たす、特定オブジェクトおよびそのオブジェクトのインスタンスを含むことを特徴とする請求項６に記載されたシステム。
【請求項２５】
前記依存性マネージャは、前記分散プログラミングネットワークに含まれる分散オブジェクト間の、トポロジーおよび依存性に関して受容性のあるサービスであることを特徴とする請求項６に記載されたシステム。
【請求項２６】
前記オブジェクトレゾルバは、全分散プログラミングネットワークの要求を満たす最適なオブジェクトへの問い合わせを発生することを特徴とする請求項６に記載されたシステム。
【請求項２７】
前記全分散プログラミングネットワークの要件は、少なくともひとつの信頼性ポリシーを有することを特徴とする請求項２６に記載されたシステム。
【請求項２８】
前記データ確認依存性は、オブジェクトインスタンスが依存していることの一覧を有することを特徴とする請求項６に記載されたシステム。
【請求項２９】
前記少なくともひとつのオブジェクトメーターは、時間について累積的な少なくともひとつの信頼性メトリックを発生することを特徴とする請求項６に記載されたシステム。
【請求項３０】
前記少なくともひとつの信頼性メトリックは、サービス滞在時間を含みまたは該サービス滞在時間に基づくことを特徴とする請求項６に記載されたシステム。
【請求項３１】
前記少なくともひとつの信頼性メトリックは、サービス実施時間を含みまたは該サービス実施時間に基づくことを特徴とする請求項６に記載されたシステム。
【請求項３２】
前記少なくともひとつの信頼性メトリックは、開始時間を含みまたは該開始時間に基づくことを特徴とする請求項６に記載されたシステム。
【請求項３３】
分散プログラミングネットワークにおける欠陥耐性を改善する欠陥耐性サブシステムであって、
少なくともひとつのオブジェクトインスタンスと要求されたサービスとの間の依存性を確認するデータを供給するために構成された依存性マネージャを含む分散プログラミングネットワーク内でオブジェクトグループマネージメントを実行するように構成されたレプリケーションマネージャと、
前記レプリケーションマネージャからの質問を受け且つ該質問に応答し、前記少なくともひとつのフォールトディテクタの管理下で前記分散プログラミングネットワーク内のオブジェクトおよびオブジェクトインスタンスのステータスをモニタするように構成されると共に、前記分散プログラミングネットワーク内の少なくともひとつのオブジェクトに関する前記少なくともひとつの信頼性メトリックを発生するように構成された少なくともひとつのフォールトディテクタと、
前記レプリケーションマネージャおよび少なくともひとつのフォールトディテクタに接続され、かつ前記少なくともひとつのフォールトディテクタからのこのような欠陥の検出を示すデータを受け取ることに続いて、オブジェクトまたはオブジェクトインスタンス故障の前記レプリケーションマネージャに通知することにより前記少なくともひとつの欠陥ディテクタのための故障通知ハブとして動作するように構成されたフォールト通知部と、
複数のオブジェクトインスタンスから要求されたサービスに関連する少なくともひとつのオブジェクトを確認すると共に、前記確認された少なくともひとつのオブジェクトインスタンスに関する少なくともひとつの信頼性メトリックを質問し、かつ何れのオブジェクトインスタンスが最も確かに前記サービスの要求を実施するかについて決定するように構成された適応プレイサーと、
を備えた欠陥耐性サブシステム。
【請求項３４】
前記オブジェクトレゾルバは、前記分散プログラミングネットワーク特有の信頼性ポリシーにアクセスする権利を有するコストエバリュエータを備えたことを特徴とする請求項３３に記載された欠陥耐性サブシステム。
【請求項３５】
前記サービスの要求は、クライアントから生じ、そのクライアントは、そのクライアントにより期待される信頼性のレベルを示す少なくともひとつの信頼性の制約を発生し又は割り当てられることを特徴とする請求項３３に記載された欠陥耐性サブシステム。
【請求項３６】
前記オブジェクトレゾルバは、前記クライアントにより供給された前記少なくともひとつの信頼性の制約を満たす、特定オブジェクトおよびそのオブジェクトのインスタンスを含むリファレンス確認データを返すサービスであることを特徴とする請求項３５に記載された欠陥耐性サブシステム。
【請求項３７】
前記依存性マネージャは、前記分散プログラミングネットワークに含まれる分散オブジェクトインスタンス間の前記トポロジーおよび依存性に関して受容性を有するサービスであることを特徴とする請求項３５に記載された欠陥耐性サブシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、分散プログラミングネットワークにおける信頼性バランシングに関する。更に詳しくは、本発明は、過去の分散プログラミングネットワーク及び／又は分散プログラミングネットワークコンポーネントヒストリーに基づく分散プログラミングネットワークにおける信頼性バランシングに関する。
【背景技術】
【０００２】
デスクトップ上の低コストのコンピュータパワーよりも先にコンピューティングすることがセンタのロジカルなエリアにおいて組織化された。これらのセンタがまだ存在しているにもかかわらず、大小の企業は、彼らが企業において最も効率良く操作できる場所や、デスクトップワークステーション、ローカルエリアネットワークサーバ、地域サーバ、ウェブサーバおよび他のサーバのいくつかを複合した所に、多くの時間をかけてアプリケーション及びデータを分散させている。分散プログラミングネットワークモデルにおいて、コンピューティングは、コンピュータで処理中のコンピュータプログラミングおよびデータが１台よりも多くのコンピュータに、通常、ネットワーク上に分配された場合に、“分散された(distributed)”と言われる。
【０００３】
クライアントサーバコンピューティングは、単純に、クライアントマシンまたはアプリケーションがユーザに或る能力を提供し、そしてクライアントマシンやアプリケーションにサービスを提供する他のマシンやアプリケーションから他の事柄を要求するという考えである。
今日、主要なソフトウェアメーカは、分散コンピューティングのオブジェクト指向の展望を推し進めている。Ｊａｖａ（登録商標）を用いた分散パブリッシング環境や、企業が分散アプリケーションを作り出すことを手助けする他の製品のように、ＷＷＷ(World Wide Web)が、分散コンピューティングに向けてトレンドを加速させている。分散ソフトウェアモデルもまた、大容量または使命重大な(mission critical)システムのための、拡張性があって高度に有用なシステムを提供するのに向いている。
【０００４】
ＣＯＲＢＡ(Common Object Request Architecture)は、ネットワークにおける分散プログラムオブジェクトを作成し、分散し、そして管理するためのアーキテクチャであり、仕様規格である。これにより、異なる場所で異なるベンダーにより開発された複数のプログラムが、“インターフェイスブローカ(interface broker)”を通じてネットワークにおいて通信することを可能とする。ＩＳＯ(International Organization for Standardization)は、ＣＯＲＢＡを分散オブジェクト（これはネットワークコンポーネントとしても知られている）として公認している。
【０００５】
ＣＯＲＢＡにおける本質的な概念は、ＯＲＢ(Object Request Broker)である。異なるコンピュータ上でクライアントおよびサーバのネットワークにおけるＯＲＢの支援は、クライアントプログラム（それ自体オブジェクトであってもよい）が、その物理的ロケーションまたはその装置に関わりなく、サーバプログラムまたはオブジェクトからサービスを要求できることを意味する。ＣＯＲＢＡにおいて、ＯＲＢは、分散オブジェクトまたはコンポーネントからのクライアントのサービス（例えば、まとまりのあるソフトウェア機能の集まり、その機能は共に複数のクライアントに対しサーバのような能力を呈する；サービスは、例えばそのクライアントによって遠く離れて実施可能であってもよい）に対する要求と要求達成との間で“ブローカ(broker)”として動作する。このように、ネットワークコンポーネントは、稼動しているときにお互いを見つけてインタフェース情報を交換することができる。ＯＲＢ間で要求または応答を行うため、ＧＩＯＰ(General Inter-ORB Protocol)、およびインターネットにはそのＩＩＯＰ(Internet Inter-ORB Protocol)が使用される。ＩＩＯＰは、ＧＩＯＰの要求および応答を、各コンピュータにおけるインターネットのＴＣＰ(Transmission Control Protocol)レイヤに移す(map)。
【０００６】
どのようなフレームワークまたはアーキテクチャが分散プログラミングで使用されているかに関係なく、オブジェクト指向のプログラミングにおける最初のステップは、操作すべきシステムで利用されている全てのオブジェクトを確認し、そしてそれらが互いにどのように関連づけられているかを確認することであり、これは大抵の場合データモデリングとして知られている実践である。一旦オブジェクトが確認されると、このオブジェクトの確認は、オブジェクトのクラスとして一般化され、それが含むデータのタイプおよびそのデータを操作できるいくつかのロジックシーケンスが定義される。クラスの真のインスタンス(real instance of class)は、“オブジェクト”、又はある環境においては“クラスのインスタンス”と呼ばれる。負荷バランシングおよび信頼性バランシング（この明細書で説明される）、同一オブジェクトの複数インスタンスが、分散プログラミングネットワーク内の種々の点で動作する。
【０００７】
大規模分散プログラミングシステムを管理するための二つの主要な挑戦がある。ひとつは、分散プログラミングネットワークサービスに対する要求が高い場合に性能をハイレベルに維持することである。この挑戦は、しばしば“負荷バランシング”として引用され、そして、通常よりも多くのクライアントの要求に対し、有限の分散プログラミングネットワーク資源（分散プログラミングネットワークサービスに関連した資源）の配分をバランスさせることを要求する。多くの場合、大規模な分散プログラミングネットワークは、そのサービスを受けるクライアントにサービスを提供する。この負荷要求の統計学上のバランシングは、一般に観測されており、良く研究された現象である。
【０００８】
他方の主要な挑戦は、これらの大規模分散プログラミングネットワークの継続的な動作を維持することである。この挑戦は、“信頼性バランシング(reliability balancing)”として引用される。大規模システムが、欠陥、即ちサービスエラーの原因をより抱えやすくなることはよく知られた重要事項である。加えて、より大きなシステムでは、欠陥は、そのサービスの顧客に対してより重大な影響を与えやすい。例えば、もしサービスが１つよりも多くのオブジェクトを利用またはアクセスする資源を必要とすれば、それら複数のオブジェクト中の１つに存在する故障がシステムの故障をもたらし得る。
【０００９】
従来、大規模分散プログラミングネットワークの負荷バランスの問題を解決するための多くのアプローチがある。そのどれもが完璧ではないように見える一方、それらは、その利益を論証するには有効である。しかしながら、分散プログラミングネットワークの信頼性を提供することの挑戦、即ち分散プログラミングネットワークマネージメントの働きを維持することは、決して速くはないにしても発達し切っている。大規模分散プログラミングネットワーク信頼性を提供するための従来方法および分散プログラミングネットワークが変化している。多くの主要な技術が存在する。
【００１０】
大規模分散プログラミングネットワーク信頼性を提供するための最も一般的な技術は、エンティティー(entity)、またはオブジェクトインスタンスのリダンダンシー(object instance redundancy)に依存している。この技術は、またしばしば“レプリケーション(replication)”として引用され、そして、オブジェクトまたはオブジェクトのグループの主要なインスタンスがフェイルしたときに１又は２以上の代わりのインスタンスが主要なインスタンスが切り離されたサービスを再開できることを期待して、同一のオブジェクトまたはオブジェクトのグループに代わるインスタンスを提供することにより、大きく重大なシステムにおけるコンポーネントの故障に対する或る程度の防御を提供する。
【００１１】
Ｎ−バージョンプログラミングと呼ばれるもう一つの共有技術は、同時的に実施する同一サービス（またはオブジェクト）の３つまたはそれ以上の異なるバージョン（装置）を頼みとするものである。これらの動作は、並列装置のそれぞれが、例えば他方対して一方が先行することのない同一のシーケンシングを通じて論理的に稼動するように、或るロックステップ制御(rock-step control)メカニズムを通じて制御される。適切な時間上の点で、３つまたはそれ以上のインスタンスの各出力が投じられる。その期待するところは、３つの全てのインスタンスが、それらが提供する如何なる計算作業(computational task)についても同一の結果を報告すべきことにあり、故に不一致のないことが確認される。インスタンスに故障が存在するときには、この技術は、３つの異なる装置が恐らくは同一のエラーを有していないはずであるという推定を頼りにしており；故に他の２つのインスタンスの多数出力が正当な出力とされ、そして処理のチェーンにおける次のオブジェクトに伝達される。この技術は、ライフサポート(life-support)、ミッションクリティカル(mission critical)、航空宇宙産業、航空産業でしばしば用いられている。これらのタイプのシステムを構築することは、文字通り、少なくとも３回別々にシステムが開発されるのと同様に、明らかに相当に高額である。この技術は、また、しばしばＴＭＲ(triple modular redundancy)と呼ばれる。
【００１２】
信頼性マネージメントを提供するために従来から一般に実施されているエンテティリダンダンシー／レプリケーション方法および他のアプローチは、分散プログラミングネットワークにおける高い有用性を維持することを手助けすることにおいて大きな成功を収めたが、その一方で、それらはある限界を有している。例えば、それらは、欠陥に対する防御における戦略を管理する方法においては概ね静的である。このことは、それらがシステムにおける故障に多くの時間を振り向けることができないことを意味している。それらは、どのコンポーネントがレプリケートされ且つどこにレプリケートされるのかを調整するために人間の介入または制御を必要とする。さらに、シダンダンシー／レプリケーションは、システム故障に対して防御するためには高価な方法であり、そして、もしコンポーネントの全てのインスタンスが同様の問題に苦しめられれば、完全には成功しないおそれがある。
【発明の開示】
【課題を解決するための手段】
【００１３】
本発明は、分散プログラミングネットワークにおいて信頼性バランシングを実施するための方法であって、サービスの要求を受けるステップと、前記要求されたサービスに関連する少なくともひとつのオブジェクトインスタンスを確認するステップと、前記少なくともひとつのオブジェクトインスタンスと前記要求されたサービスとの間の依存性を確認するデータについて質問するステップと、前記確認された少なくともひとつのオブジェクトインスタンスに関連する少なくともひとつの信頼性メトリックについて質問するステップと、少なくともひとつの信頼性メトリックに基づき何れのオブジェクトインスタンスが最も確かに前記サービスを実行し得るかを決定するステップとを備える。
【発明を実施するための最良の形態】
【００１４】
本発明の代表的な実施形態は、添付の図面を用いて本発明の以下の詳細な説明を考慮することで容易に吟味され且つ理解され、各図面において同一の番号が付された要素は同一のものである。
図１は、本発明の代表的な実施形態に係る分散プログラミングネットワークおよび適応信頼性バランシングシステムを示す。
図２は、故障グループを表す図式的な関係のグループを図示し、この故障グループは、図１に示されたコストエバリュエータにより全体の信頼性量のために評価される。
図３は、自己の信頼性見積もりと共に５つのサービスの表現を示す。
図４は、本発明の代表的な実施形態に係る信頼性バランシング方法を示す。
図５は、本発明の典型的な実施形態に係る欠陥耐性サブシステム(fault tolerance subsystem)を示す。
【００１５】
一般に理解されている静的または非適応的な信頼性バランシングアプローチのひとつの結果として、大規模分散プログラミングネットワークは、分散プログラミングネットワークが性能検証(commission)されるまで、即ち稼動するまで、多くの場合、信頼性特性、例えば、分散プログラミングネットワークに特有の問題を示すことができない。加えて、分散プログラミングネットワークおよび分散プログラミングネットワークコンポーネントは、拡大使用のためにしばしば経時的に変化し、性能の低下及び／又は環境的な変化をもたらす。
【００１６】
さらに、分散プログラミングネットワークおよび分散プログラミングネットワークコンポーネントは、しばしば老化の仕方が異なる。例えば、分散プログラミングネットワークまたは分散プログラミングネットワークコンポーネント内のソフトウェアに関しては、ソフトウェアは、分散プログラミングネットワークが引き渡された後に、特定のアプリケーションにアップグレードまたはカスタマイズされることがある。同じことが、特殊化されたハードウェアコンポーネント、および、避けられない(induced)長時間の使用あるいは関係する偶発的事故によるダメージの結果として置き換えられたポスト性能検証(post-commissioning)であるコンポーネントに対しても当てはまる。性能検証に続く分散プログラミングネットワークの構成を変える原因とは関係なく、分散ネットワークおよび分散プログラミングネットワークコンポーネントが変わることが認識されるべきであり、性能検証の時またはその前に信頼性特性がテストされた分散プログラミングネットワークとは異なる分散プログラミングネットワークの構成を生じる結果となる。
【００１７】
加えて、信頼できるように立案された分散プログラミングネットワークは、長い故障時間、即ち定義によれば故障が起こるまでの時間を有する。この関係の結果のひとつとして、分散プログラミングおよび分散プログラミングネットワークコンポーネントのメーカ(manufacturers)は、しばしば、分散プログラミングネットワークおよび／または分散プログラミングネットワークコンポーネントの信頼性を特徴づけること、および分散プログラミングネットワークおよび／または分散プログラミングネットワークコンポーネントにおける故障を解決するためのソリューションを提供することにおいて、時間と経験が不足している。
【００１８】
さらに、分散プログラミングネットワークは、しばしば、移動するコンポーネント（即ち、クライアントはその移動に気づくことなくひとつのＣＰＵまたはマシンから他に移動するソフトウェアコンポーネント；この移動はコンポーネントによって提供されるサービスのパフォーマンスおよび／または信頼性特性を変え得る）を有する。このような移動するコンポーネントの利用は、分散プログラミングネットワークのダイナミクス(dynamics)および有用性の絶え間なく変化する展望を作り出す。
【００１９】
従って、本発明の実施形態に係る方法およびシステムは、計量(metering)および計時(timing)コンポーネントの集まりを利用し、このコンポーネントは、稼動中の分散プログラミングネットワークの適合性があり且つ動的な調整を可能とするためのフィードバックを提供する。これらの方法およびシステムは、分散プログラミングネットワークが、パワーおよび分散プログラミングネットワーク故障にわたる有用性メトリックを維持し、分散プログラミングネットワークに含まれるソフトウェアおよび／またはハードウェア資源の累積的な信頼性メトリックを提供することを可能とするメカニズムを提供する。本発明の代表的な実施形態は、分散プログラミングネットワークの継続的なモニタリングを提供し、動的な信頼性バランシングを提供する。
【００２０】
本発明の代表的な実施形態に係るシステムおよび方法によって提供されるユーティリティの一つのエリアは、サービスの配達または提供のための最良の有用性状態を保証する改善されたチャンスが存在するようなサービスの消費者とそれらサービスとを知的に結びつけるための能力に関する。サービスの有用性(availability)は、さまざまな方法で算出される。例えば、サービスの有用性は、平均故障時間(MTTF；Mean Time To Failure)を、ＭＴＴＦと平均修復時間(MTTR；Mean Time To Repair)の和で除算したものとして算出できる（即ち、有用性＝ＭＴＴＦ／（ＭＴＴＦ＋ＭＴＴＲ））。
【００２１】
ＭＴＴＦは、初期の瞬間から次の故障までの時間である。ＭＴＴＦ値は、サービス信頼性の統計的数量化である。ＭＴＴＦは、故障から回復してサービスの実施を回復するための時間である。サービスの実施は、モジュール（例えば、協調して動作する１又は２以上のコンポーネント）または他の特定のレファレンスグラニュアリティ(reference granularity)が動作し、指定されたようにサービスを提供するときに成し遂げられる。ＭＴＴＲ値は、サービスの中断の統計的数量化であり、それは、モジュール（または他の特定のレファレンス粒）の振る舞いが、その特定の振る舞いから外れた時間である。
【００２２】
代表的な実施形態によれば、方法および／またはシステムは、“ライブ(live)”または“リアルタイム(real-time)”のデータを利用する。一つの結果として、代表的な実施形態に係るシステムおよび方法は、リアルタイムまたはリアルタイムに近い方法で分散プログラミングネットワークの特性を変えることへの適合を可能とする。このような能力は、極めて長い時間の間の稼動が期待される分散プログラミングネットワークにおける有用性保証の信用を著しく改善する。
【００２３】
本発明の代表的な実施形態によれば、適合性のある信頼性バランシングは、互いに信頼性の目標が一致しまたは超えるような分散プログラミングネットワークにおいて、クライアントとサーバソフトウェアコンポーネントとの組み合わせに備えるために分散されたクライアントサーバ分散プログラミングネットワーク環境において実施される。この適合性のある信頼性バランシングを提供するために立案されたシステムおよび方法は、分散プログラミングネットワークの現在の構成と分散プログラミングネットワークにおける過去のコンポーネントとの両方が与えられる最も適切な方法で、分散プログラミングネットワークにおいて適合的に信頼性をバランスさせる能力を提供する。このようなシステムおよび方法は、ヒストリー(history)、および分散プログラミングネットワークおよび／または分散プログラミングネットワークサービスに関する将来の要求の統計学的予測に基づく信頼性バランシングを実行するための適合的な計測と共に、バランシング技術を利用する。
【００２４】
蓄積されたデータは、システムを構成するコンポーネントのパフォーマンスのヒストリカルな見通しである。この情報は、将来のパフォーマンスに関する予測的な仮定を提供しようとする場合に使用できる。例えば、コンポーネントに対するＭＴＴＲは、比較的変化しないように思われる。なぜなら、それは、新たなコンポーネントインスタンスを作り出し且つサービスのためにそれを初期化することに関連した時間に対応するからである。結果として、時間を超えて(over time)、任意の特定コンポーネントに対するＭＴＴＲの平均は、一般に、そのコンポーネントの将来の故障に対する修復期間の予測における使用に対しては相当に確かな数である。一方、ＭＴＴＦは、予測性(predictable)は少なく、より確率論的(stochastic)である。結果として、システムの有用性は、潜在的に動的なＭＴＴＦの結果として変化する。
【００２５】
分散プログラミングネットワークにおける他のコンポーネントは、しばしば分散プログラミングネットワークにおける他のコンポーネントの参加を頼りにしているので、全ての又は参加しているコンポーネントの相当数の蓄積された評価は、分散プログラミングネットワークの信頼性を理解するために必要とされる。結果として、本発明の実施形態に係るシステムおよび方法は、場所(location)、時間(time)、依存性(dependency)、および／または特定の分散プログラミングネットワークに関する信頼性(reliability)を収集する。それから、このデータは、コスト評価の発見的方法(cost evaluation heuristics)により分析される。これら発見的方法のファンクションの出力は、有限の複数の選択が存在する分散プログラミングネットワークにおける要求を扱うために、分散されたコンポーネントの最適のおよび／または最も望ましい選択を提供する。
ユーザが定義したメリットファンクションは、ユーザが定義した制約に基づく“最良の適合”を選択するのに適用できる。このようなユーザが定義したメリットファンクションページ：１０は、ガイダンスのためのファンクションへの入力として目標または制約に基づくパラメータを受け取ることができる。
【００２６】
図１は、本発明の代表的な実施形態に係る分散プログラミングネットワーク１００および適応性のある信頼性バランシングシステムを図示する。図１に示されるように、主要な４つの関係要素：クライアント(client)１１０、オブジェクトレゾルバ(object resolver)１２０、依存性マネージャ(dependency manager)１３０、分散オブジェクトインスタンス(distributed object instances)１４０およびオブジェクトメータ(object meters)１５０がある。
図１は、クライアント１１０がタイプ“Ａ”のサーバを使用することを望むという事実を図示している。分散されたオブジェクトインスタンス１４０の集まりは、例えばコントロールファブリック（例えばローカルエリアネットワーク）１６０を介して接続され、３つのこのようなタイプ“Ａ”オブジェクトインスタンス１４１，１４３，１４５、およびひとつのタイプ“Ｂ”オブジェクトインスタンス１４７を提供する。図１は、このシナリオの物理的境界を示すものではない。コントロールファブリック１６０は、例えば、独立に動作しているコンポーネント間で、通信を実施し及び／又はパスを制御するハードウェア、ソフトウェアを備えている。そして、そのコンポーネントは、例えばＣＯＲＢＡフレームワークのＩＩＯＰのような分散プログラミングネットワークにおいて、これらの分散プログラミングネットワークコンポーネント（例えばオブジェクトインスタンス１４０）の冗長の間の通信を考慮する。従って、タイプ“Ａ”オブジェクトインスタンス１４１，１４３，１４５は、１又は２以上のモジュールに含まれ、または、１又は２以上のプロセッシングコンポーネント、例えば１つのシャーシ(chassis)における１又は２以上のカード、１つのシャーシにおける１又は２以上のコンピュータ、１つのコンピュータにける１又は２以上の処理等に配置することができる。
【００２７】
クライアント１１０は、例えば、アプリケーションであり、または潜在的に分散されたオブジェクトであり、それは、１又は２以上の分散オブジェクトインスタンス１４０の一つに関連した１又は２以上のサービスの要求された使用のものを捜し又は有するものである。例えば、クライアント１１０は、アプリケーションであり、それはタイプＡ分散オブジェクトインスタンス１４１，１４３，１４５および／またはタイプＢ分散オブジェクトインスタンス１４７において実行されたファンクションまたは方法を呼び出す。本発明の実施形態において、クライアント１１０は、クライアント１１０（図３を参照して後述するように）が期待する信頼性のレベルを示す少なくとも一つの信頼性制約(reliability constraint)を発生し又は割り付けられている。
【００２８】
オブジェクトレゾルバ１２０は、例えば、特定オブジェクトを含むオブジェクトインスタンスと、クライアント１１０によって供給される所望の信頼性制約に適合するオブジェクトのインスタンスとを返すサービスである。依存性マネージャ１３０は、オブジェクト、サービス、またはトポロジーおよび分散オブジェクトインスタンス１４０の間の依存性に関して受容性のあるプロセスである。例えば、依存性マネージャ１３０は、同一のプロセッサまたはプロセッサのセット等を超えて、分散オブジェクトインスタンス１４１および１４３が、同一のコンピュータ上で動作しているか、異なるコンピュータ上で動作しているかを知る。
【００２９】
分散オブジェクトインスタンス１４０は、１又は２以上のクライアント１１０に対するサービスを提供するために使用されるコンポーネントである。分散されたオブジェクトは、オブジェクトとして考えられるが、ネットワーク遠隔機構を通じて、クライアント、例えばクライアント１１０、から遠く離れて（即ち同一のプロセッサ上で稼動せずに）呼び出すことができるという事実によって特徴づけられる。各オブジェクトインスタンス１４０は、プロパティまたは“メータ(meters)”の集まりを備える。これらメータ１５０は、時間に関して累積的である。即ち、コンテンツは、永続的な耐久性のあるストレージ(storage)に保存され、そしてオブジェクトインスタンス１４０が開始される各時間に復元される。
【００３０】
クライアント１１０は、クライアントによって要求された有用性に対する全要求に適合する最良のオブジェクトインスタンスへのレファレンスを得るため、オブジェクトレゾルバ１２０と協議する。オブジェクトレゾルバ１２０は、クライアントに求められたベストマッチを見つけ出すことを試みるため、クライアントに代わってエージェント(agent)またはブローカ(broker)として動作する。もし、このオブジェクトレゾルバが要求を実行できなければ、この実行しだいで、このオブジェクトレゾルバは指示をその結果に返すか、または、おそらく、要求されたパラメータに合致したものを除いてクローゼットマッチ(closet match)を返す。
【００３１】
全ネットワークポリシーは、信頼性ポリシーを含み、例えばオブジェクトレゾルバ１２０に含まれるコストエバリュエータ１２５におけるＸＭＬ(extensible markup language)を通じて断定的に特定される。コストエバリュエータ１２５は、また、オブジェクトインスタンス１４０間の依存性、クライアント１１０の依存性および可能なタイプＡインスタンスの集まりを確認するため、依存性マネージャ１３０を利用する。
【００３２】
分散プログラミングネットワークにおけるオブジェクトまたはサービス間の依存性を確認し且つ理解するための能力は、依存性マネージャ１３０が、故障グループ、即ちサービスのオブジェクトのグループに関する情報を提供することを可能にし、そこでは、構成要素であるオブジェクトまたはサービスのひとつの故障が障害(fault)につながる。その情報は、動的に、または、いくつかの前の断定的な情報（例えば、他の分散プログラミングネットワークコンポーネント、分散プログラミングネットワーク外のコンポーネント、ユーザ管理者、等により決定される）を通じて収集される。この情報は、管理された図表(graph)によって表される。後述のように、この依存性情報は、コストエバリュエータ１２５が、グループの有用性を比較することを可能にする。より大きなグループ（例えば、サービス／オブジェクトおよび／それらの依存したサービス／オブジェクト）は、より低い有用性の格付けを有するようである；故に、それらは、最も高い有用性の測定が必要とされるときに、クライアントとサーバとの間の競争(match)の候補にはなりそうにない。
【００３３】
この依存性情報は、各オブジェクト又はオブジェクトインスタンスが依存していることの一覧を備える。このような一覧は、例えば、図表によって表すことができる。一つの実施例においては、全ての依存性はその一覧で表現される。他の実施例においては、ソフトウェアオブジェクトとクライアントサービスとの間の依存性のみが表現されるのに必要であり；よって、ハードウェアおよび通信依存性は捕獲される必要がない。図２に図示するように、全分散プログラミングが一覧に記入されると、管理された図表の群が結果として生じる。
【００３４】
図２に示すように、群２００（即ち図式的関係２１０）は、図１に図示されたコストエバリュエータ１２５によってそれらの全信頼性の各付けのために評価される故障グループ２１０を表す。各グループ２１０における各オブジェクト／サービス２２０の影響は、簡素化の目的のために等しく取り扱われる；しかしながら、また重み付けされた影響がさらに正確なモデルに適用されることも予測可能である。結果として、本発明の実施形態に係る一つの実施形態において、依存性情報は、グループ２１０のさまざまなオブジェクト／サービスの重要性を示す重み付けされた影響データ(weighted influence data)を含む。これらの故障グループは、概念上、サービス（上述）として考えることができる。
【００３５】
オブジェクトインスタンス１４０間の依存性を確認するデータを受け取った後、コストエバリュエータ１２５は、オブジェクトインスタンスのそれぞれ、例えば１４１，１４３，１４５（さらなる詳細は後述）に関連し、且つクライアントとオブジェクトとの間で滞留しているセッションを実行するためのオブジェクトインスタンスの有用な選択間の例えば相対的コストを決定するのに必要なデータを収集するためにメータ１５０によって提供されるメトリックを評価する。コストエバリュエータ１２５は、それから、信頼性および他のポリシーを適用し、そして“最も適したもの(best fit)”を選択する。
もし、クライアント１１０が、たまたま、コストエバリュエータ１２５に注入されたポリシーに依存して同一のオブジェクトインスタンス１４１，１４３上で動作している場合、信頼性の全体評価が各インスタンス１４１またはインスタンス１４３よりも高いスコアを有しているときにオブジェクトインスタンス１４５に対してレファレンスを返すことがより望ましい。
【００３６】
この評価により提供される情報を用いることなく、従来のシステムは、どのインスタンスを返すかを決定するためにパフォーマンスバランシングまたは負荷バランシングを単に使用した。これとは対照的に、本発明の実施形態に係るシステムおよび方法は、分散プログラミングネットワークの全体の有用性に関するオブジェクト信頼性の影響が、従来の負荷バランシング技術を通じた性能の最適化と同様に意義深く重要であるという理解に基づいている。
【００３７】
本発明の代表的な実施形態は、部分的には、メータ１５０によって供給されるような信頼性メトリックの継続的蓄積が、信頼性または有用性の決定において役立つという認識に基づいている。この認識のひとつの結果として、さまざまなタイプのデータが、特定ネットワーク全体の有用性のライフタイムの見通しを効果的に計測するために利用される。このデータを収集するため、このシステムおよび方法は、信頼できる方法で時間を超えてデータを収集し、蓄積し、そして固持するための能力を有する。分散プログラミングネットワークの全ライフタイムまたは重要なライフ期間にわたるサービス実行情報の蓄積は、分散プログラミングネットワーク全体の有用性の評定について責任を負う発見的方法に対する意味のある且つより正確な入力を提供する。
【００３８】
個々の分散された各オブジェクトのために収集され且つ蓄積された信頼性メトリックデータのタイプは、例えば、滞在時間（即ち特定サービスが動作していた時間量）、サービス実行時間（即ち特定サービスがファンクショナル（例えばそのファンクションを確かに提供できる）である時間量、そして開始時間（即ち、特定のサービスが、サービスを提供できるようになるための“コールドブート”からスタートするのに要する時間の量；簡略化の目的のため、このメトリックは分散プログラミングネットワークのライフタイムにわたるランニングアベレージ）を含む。加えて、累積するシステム時間は、分散プログラミングネットワークシステム全体が動作している全体時間を示すために記録される。
【００３９】
これらの累積された測定結果を記録することにより、各サービスの信頼性のより正確な理解が提供される。なぜなら、理想的に任意の個々のサービス信頼性が高く、故にＭＴＴＦが理想的に低く、全てのサービスの発生、スタートアップ、またはシステムリセットの後にそれらのカウンタを“リセット”することは大事ではないからである。逆に、これらデータタイプの長期間の累積メトリックによって提供される情報に重要な価値がある。
オブジェクトおよびサービスに蓄積された信頼性メトリックは、オブジェクトレゾルバ１２０におけるコストエバリュエータ１２５に戻される。これは、どのような多くの方法、例えば、サービスの新たな使用に対する要求に基づくオンデマンドで信頼性メトリックを回収(retrieving)するような多くの方法によっても実行できる。
【００４０】
クライアント１１０がサービスの使用を要求した場合、オブジェクトレゾルバ１２０は最初に、サービス、例えばオブジェクトインスタンス１４１，１４３，１４５に対応するサービス、に有用な要求されたタイプの全インスタンスの集まりを確認する。オブジェクトレゾルバ１２０は、例示されたオブジェクトまたはサービスの全てのディレクトリを備えるか又はアクセスすると推定される。一旦候補インスタンスの集まりが確認されると、依存性マネージャ１３０は、オブジェクトとサービスとの間の依存性を確認するデータを確認するために参照される。オブジェクトレゾルバ１２０は、それから質問し、または別に、各インスタンスから信頼性メトリックを順番に回収し、パフォーマンスの改善のために同じ質問から既に訪れたオブジェクトをキャッシング(caching)する。
【００４１】
一旦、信頼性メトリックの全てが収集されると、次のステップで、過去のパフォーマンスが与えられたこのグループ全体の信頼性を確認するための計算を実行する。
要求されたサービスを実行するグループのそれぞれの将来のコスト、例えば費やされた資源の量を計算した後、コストエバリュエータ１２５は、それから、グループのそれぞれを他と比較し、そして格付け(ranking)を行う。この各付けは、コストエバリュエータ１２５に導入された信頼性評価ポリシーに基づく。
【００４２】
例として、図３は、５つのサービス３１０，３２０，３３０，３４０，３５０を図示し、それぞれは、それら自身の信頼性各付けＲ１−Ｒ５を有しており、その各付けは故障グループ３００の一部である。これら信頼性各付けのそれぞれは、ＭＴＴＦに換算して特定される。それらの信頼性は、１／ＭＴＴＦとして特定される。メータ１５０（図１に示される）によって提供されたオブジェクトメトリックは、同様に有用性の良好な評価を提供する。そのオブジェクトメトリックカウンタから導き出された有用性は、単純に（滞在時間）−（サービス実行時間）である。ＭＴＴＲは、スタートアップタイムのローリングアベレージオブジェクトメトリック(rolling average object metric)であり、それは、コールドスタートからサービス可能となるまでに要する時間の総量を表す。
【００４３】
分散プログラミングネットワークの有用性は、概念上、所要時間に対するサービス実行の比率として定量化でき、例えば、有用性は、統計学上、ＭＴＴＦ／（ＭＴＴＦ＋ＭＴＴＲ）として定量化される。それから、グループ有用性は次のようである：
【００４４】
【数１】
2004521411.tif 000003
【００４５】
ここで、αｊは、グループにおける各サービスの有用性を表す。コストエバリュエータ１２５は、各グループに対してこのファンクションを実行し、そしてコストエバリュエータ１２５において特定された信頼性ポリシー（例えば、ポリシーおよび基準）に基づき、最も適切なグループを選択する。例えば、ひとつのポリシーは、特定の信頼性の目標に最も近い信頼性値を有するオブジェクトのグループが、最善のまたは最も信頼できるオブジェクトのグループに対立するものとして常に選ばれる。
【００４６】
図４は、上述した信頼性バランシングの方法を図示している。図４に示されるように、その方法は、ステップ４００で開始して制御がステップ４１０に進む。ステップ４１０では、サービスに対するクライアントの要求が、分散プログラミングネットワークに受け取られる。それから、制御はステップ４２０に進み、そこで、オブジェクトレゾルバが、要求されたサービスに関連するオブジェクトインスタンスを確認する。それから、制御がステップ４３０に進み、そこで、オブジェクトレゾルバが、オブジェクトインスタンスとサービスとの間の依存性を確認するデータについて依存性マネージャに質問する。それから、制御がステップ４４０に進み、そこで、オブジェクトレゾルバは、その関連した信頼性メトリックについて各オブジェクト／サービスに質問する。一旦、各故障グループまたはセットについてのメトリックが回収されると、有用性を評価する次のステップが検討される。それから、制御がステップ４５０に進み、そこでは、信頼性メトリック、依存性、およびコストエバリュエータに含まれ又はアクセスされた信頼性ポリシーに基づき、何れのオブジェクトインスタンスまたはオブジェクトインスタンスのグループが、最も確かにクライアントのサービス要求を実行するかについて決定される。それから、制御がステップ４６０に進み、そこで、この決定は他の分散プログラミングネットワークコンポーネントによって使用され、図５を参照して後述するように、それは、クライアントサービス要求を、選択されたオブジェクトまたはオブジェクトのグループとマッチ(match)させる。それから、制御がステップ４７０に進み、そこで、その方法が終了する。
【００４７】
本発明の実施形態に係る方法およびシステムは、例えば、ＣＯＲＢＡに基づく通信サービスシステムアーキテクチャにおいて実施される。
ＣＯＲＢＡを使用したホステッドサービス(hosted service)を提供するシステムのための或る分散プログラミングネットワークアーキテクチャの一つの利益は、サービスのクライアントが、資源同一のプロセス、同一のホスト、エンベデッドカード、またはネットワークを介して接続された他のマシンにおいて稼動しているかどうかを知らず、また注意も払わないということである。このモデルはそれらの特色を完全に抽出している。このアーキテクチャのひとつの結果は、分散プログラミングネットワークによって提供される全てのサービスおよび資源が通信プロトコル（例えば、ＧＩＯＰに基づく）を通じて緩やかに結合されているので、これらのサービスのクライアント、資源およびＣＯＲＢＡオブジェクトがどのハードウェアと通信しているのかの情報を持たないということである。
【００４８】
本発明の実施形態に係る方法およびシステムは、分散されたオブジェクトモデルに係る分散プログラミングネットワークにおいて使用できる。ＣＯＲＢＡにオブジェクトを配置するための全ての標準的なメカニズムは、このような分散プログラミングネットワークアーキテクチャに適合する。加えて、分散プログラミングネットワークアーキテクチャは、パフォーマンスおよび信頼性の拡張の手助けとなるいくつかの特定ファンクションを実行するためのファンクショナリティ(functionality)を広げることができる。このような分散プログラミングネットワークアーキテクチャには、例えば２つのオブジェクトロケータ(object locators)が存在し、例えば一つは、標準のＩＮＳ(Interoperable Naming Service)であり、もう一つは、図１に図示されるオブジェクトレゾルバ１２０のようなシステム特有のオブジェクトレゾルバである。オブジェクトレゾルバ１２０は、分散プログラミングネットワークにおける信頼性およびパフォーマンスポリシーに基づき自動オブジェクトレファレンスレゾリューション(automatic object reference resolution)を提供するというそのタスクを実行するため、他のコンポーネントと協調してＩＮＳを使用できる。
【００４９】
ＩＮＳは、サービスネーム(service names)をオブジェクトレファレンス(object reference)にマッピング(mapping)するための保管場所を提供する。それは、クライアントが、その特定の場所の情報を要求することなく、ネームでサービスの場所を突き止めることを容易にすることができる。このアーキテクチャを用いて、クライアントは、単純にＩＮＳに質問し、そしてインボケーション(invocation)のために使用できるオブジェクトレファレンスを返す。オブジェクトレファレンスツリーの群(forest of object reference trees)がＩＮＳに置かれ、その例が図２に示される。結果として、依存性マネージャ１３０がＩＮＳを含み、またはＩＮＳに含まれることが理解される。
【００５０】
ＣＯＲＢＡモデルにおける欠陥耐性(fault tolerance)を含むのに必要とされる変化の殆どは、ＩＩＯＰプロトコルに拡張し、新たなＣＯＲＢＡオブジェクトサービスを加えることである。上述したコンポーネントは、それらを分散されたプロセッシングネットワーク内で欠陥耐性サブシステム５００として実施することにより、このような欠陥耐性システムに組み込まれる。結果として、上記の確認されたコンポーネントおよび方法の実施は、ＣＯＲＢＡ欠陥耐性のインフラストラクチャ(infrastructure)をさらに独立的にするネットワークアーキテクチャに組み込まれる。
【００５１】
図５に示されるように、このような欠陥耐性サブシステム５００は、レプリケーションマネージャ５１０、フォールトノティファイア(fault notifier)５２０、少なくとも一つのフォールトディテクタ(fault detector)５３０およびアダプティブプレイサ(adaptive placer)５４０を備え、それはシステム特有のコンポーネントである。このような欠陥耐性サブシステム５００は、さまざまなサービス、例えばレプリケーションマネージャ５１０（例えば欠陥耐性インフラストラクチャにおける管理上のファンクションの殆ど、およびこのサービスのクライアントによって定義された欠陥耐性ドメインのためのプロパティおよびオブジェクトグループマネージメントを実行すること）、アダプティブプレイサ５４０（例えば、パフォーマンスおよび信頼性ポリシーに基づくオブジェクトレファレンスを作ること）、フォールトノティファイア５２０（例えば、フォールトディテクタおよび／またはこのサービスに登録された消費者にイベントをフィルタリングし且つ伝えるための欠陥通知ハブとして動作すること）、フォールトディテクタ５３０（例えば、レプリケーションマネージャから質問を受け取り、それらの管理下にあるオブジェクトの健康状態をモニタすること）を含む。レプリケーションマネージャ５１０は、欠陥耐性インフラストラクチャの働き者である。
【００５２】
本発明の実施形態に係る欠陥耐性の分散プログラミングネットワークに基づくシステムには、ホスティングサービス(hosting service)に対する複数の候補が存在する。アダプティブプレイサ５４０は、これらの適当な候補を、パフォーマンスおよび信頼性属性(reliability attribute)を有する重み付けされた図表、例えば図1に図示されるオブジェクトメータ１５０によって提供されるメトリック、として具体化する。アダプティブプレイサ５４０は、クライアント、例えば図1に図示されるクライアントに対するアクセスポイントであり、システム特有の特徴と協調してより高い抽出レベルを提供する。アダプティブプレイサ５４０は、各オブジェクトインスタンスの場所を含むデータを生成する。それから、オブジェクトインスタンスまたはオブジェクトグループパフォーマンス（即ちロードバランシング）および信頼性（即ち、信頼性バランシング）係数に基づくクライアントの要求を実行するためのオブジェクトインスタンスを決定するのは、アダプティブプレイサ５４０におけるコストエバリュエーション発見的方法（図２に図示されるオブジェクトレゾルバにおけるコストエバリュエータ１２５に含まれ、それぞれは図５に図示されるアダプティブスペイサ５４０に含まれる）である。
【００５３】
フォールトノティファイア５２０は、1又は２以上のフォールトディテクタ５３０に対するハブとして動作する。フォールトノティファイア５２０は、レプリケーションマネージャ５１０に送る前にフォールトディテクタの通知を収集し、かつ登録された“フォールトアナライザ”をチェックするために使用される。そして、フォールトノティファイア５２０は、アダプティブプレイサ５４０に信頼性メトリックを提供する。
【００５４】
フォールトディテクタ５３０は、単純に、オブジェクトサービスであり、このオブジェクトサービスは、レプリケーションマネージャ５１０により認識されたオブジェクトグループに登録されたオブジェクトの故障を確認するための過酷な努力をしてフレームワークに広がる。フォールトディテクタは、任意のサイズの分散プログラミングネットワークを受け入れるためにヒエラルキー法でスケール(scale)できる。フォールトディテクタ５３０は、図1に図示されるオブジェクトメータ１５０を含んでも良く、これに含まれても良く、またはこれを実行してもよい。
【００５５】
本発明は、上述した特定の実施形態のアウトラインに関連づけて述べられ、多くの代替、修正および変形は当業者に明らかである。従って、上述したように、本発明の代表的な実施形態は例証であって、これに限定されるものではない。本発明の精神および意図から始めることなく、さまざまな変更が可能である。
【図面の簡単な説明】
【００５６】
【図１】本発明の代表的な実施形態に係る分散プログラミングネットワークおよび適応信頼性バランシングシステムを示す図である。
【図２】故障グループを表す図式的な関係のグループを示す図である。
【図３】自己の信頼性見積もりと共に５つのサービスの表現を示す図である。
【図４】本発明の代表的な実施形態に係る信頼性バランシング方法を示すフロー図である。
【図５】本発明の代表的な実施形態に係る欠陥耐性サブシステムを示す図である。
【符号の説明】
【００５７】
１１０  クライアント
１２０  オブジェクトレゾルバ
１２５  コストエバリュエータ
１３０  依存性マネージャ
１４０  分散オブジェクトインスタンス
１５０  オブジェクトメータ
２１０  故障グループ
２２０  オブジェクトサービス
５００  欠陥耐性サブシステム
５１０  レプリケーションマネージャ
５２０  フォールトノティファイア
５３０  フォールトディテクタ
５４０  アダプティブプレイサ
【図１】
2004521411.tif 000004
【図２】
2004521411.tif 000005
【図３】
2004521411.tif 000006
【図４】
2004521411.tif 000007
【図５】
2004521411.tif 000008
【国際公開パンフレット】
2004521411.tif 000009
2004521411.tif 000010
2004521411.tif 000011
2004521411.tif 000012
2004521411.tif 000013
2004521411.tif 000014
2004521411.tif 000015
2004521411.tif 000016
2004521411.tif 000017
2004521411.tif 000018
2004521411.tif 000019
2004521411.tif 000020
2004521411.tif 000021
2004521411.tif 000022
2004521411.tif 000023
2004521411.tif 000024
2004521411.tif 000025
2004521411.tif 000026
2004521411.tif 000027
2004521411.tif 000028
2004521411.tif 000029
2004521411.tif 000030
2004521411.tif 000031
2004521411.tif 000032
2004521411.tif 000033
2004521411.tif 000034
2004521411.tif 000035
2004521411.tif 000036
2004521411.tif 000037
2004521411.tif 000038
2004521411.tif 000039
2004521411.tif 000040
2004521411.tif 000041
2004521411.tif 000042
【国際公開パンフレット（コレクトバージョン）】
2004521411.tif 000043
2004521411.tif 000044
【国際調査報告】
2004521411.tif 000045
2004521411.tif 000046
2004521411.tif 000047