(57)【特許請求の範囲】
【請求項１】
分散コンピュータ・ネットワークに含まれる異種サーバ装置内の資源を管理するためのシステムであって、前記各サーバ装置内の資源が、マルチメディア・コンテンツ（以下、「メディア・コンテンツ」と表記）を永続的に格納するためのディスク資源と、前記メディア・コンテンツをクライアントに供給するためのメモリ資源、ＣＰＵ資源及びネットワーク資源を含むグループから選択される１つまたは複数のサービス資源とを含み、
ａ）前記各サーバ装置ごとに設けられたローカル資源プール及びグローバル資源プールを備え、
前記ローカル資源プールは、メディア・コンテンツのストリーミング・サービス（以下、「メディア・サービス」と表記）を提供するためのローカルに管理されるディスク資源及びサービス資源から成り、前記グローバル資源プールは、メディア・サービスを提供するためのリモートに管理されるディスク資源及びサービス資源から成り、前記メディア・サービスの各々は、これに関連し且つ当該各サーバ装置のサービス単位データベース内に格納される一のサービス単位を有し、当該サービス単位は、当該各メディア・サービスを提供するための当該各サーバ装置からのディスク資源及びサービス資源の割振りコミットメントを表す資源エンベロープと、関連するサービス・シグニチャとを有し、当該サービス・シグニチャは、当該各サービス単位を使用することができるメディア・サービスの権利、特権及び特性を表すメタデータを含み、
ｂ）前記各サーバ装置ごとに設けられ、クライアント要求を受け取り、当該各サーバ装置が要求されたメディア・サービスを提供するかどうかを決定するための管理装置を備え、
前記管理装置は、前記要求されたメディア・サービスに関連し且つ前記サービス単位データベース内に格納されている前記サービス単位にアクセスし、当該サービス単位の前記サービス・シグニチャに含まれる前記メタデータに従って当該各サーバ装置が前記要求されたメディア・サービスを提供するかどうかを決定する、システム。
【請求項２】
前記各サーバ装置が、前記サービス・シグニチャを実施するための手段を備える、請求項１に記載のシステム。
【請求項３】
前記ローカル資源プール及び前記グローバル資源プールにおけるディスク資源及びサービス資源の割振りが、前記各サーバ装置のローカル管理者によって決定される、請求項１に記載のシステム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、全般的には分散コンピュータ・システムでの資源管理のための技法に関し、具体的には、マルチメディア・コンテンツの配布用の将来のインターネット・ユーティリティ環境でメディア・サービスを供給するための資源管理のためのシステムに関する。
【０００２】
【従来の技術】
次世代のインターネットは、サービス品質（ＱｏＳ）、高い帯域幅の接続性（たとえば、ｖＢＮＳ（ｖｅｒｙ−ｈｉｇｈ−ｐｅｒｆｏｒｍａｎｃｅ  Ｂａｃｋｂｏｎｅ  Ｎｅｔｗｏｒｋ  Ｓｅｒｖｉｃｅ））、差別化サービス（ｄｉｆｆ−ｓｅｒｖ）、独自のアドレッシング（たとえばＩＰｖ６）を提供する能力を介して、将来のアプリケーションに、広範囲に分散した資源にまたがって資源を活用する機会を与える。アプリケーションにとって、この技術の融合によって、仮想近接すなわち、広範囲に分散した資源のアプリケーションに対する論理的及び外見的な近接という概念が導入される。アプリケーションがこれらの資源を効率的に利用するためには、数百万のそのようなアプリケーションによってこれらの資源に対して提示される、結果的な調整されないアプリケーション負荷を分散する機構が必要である。しかし、インターネットにまたがって広範囲に分散したメディア・サーバ間の資源管理という作業は、まだ十分に理解されておらず、文献では緊急の問題として認識されている。
【０００３】
それと同時に、新たなコンピュータ・ユーティリティの組が予想されている。この新しいサービス・ユーティリティの例は、たとえば、インターネット・テレビジョン及びインターネット・ラジオなどの概念である。サービス・ユーティリティの性質は、分散チャネルのエンジニアリングを中心とする。電話網などの従来の分散チャネルでは、分散の制御が、資源のオーバーエンジニアリングと統計的多重化を介して達成される。現在まで、複数の理由から、インターネット上での資源のオーバーエンジニアリングは行われなかった。その理由は、主に、高負荷での媒体特性（たとえばバースト性及び予測不能性）と、エンドツーエンド資源のオーバーエンジニアリングを可能にする中央管理の欠如である。仮想近接の出現に伴って、エンドツーエンド資源の統計的オーバーエンジニアリングが望ましい新しいパラダイムが可能になる。
【０００４】
広範囲に分散したコンテンツ及び資源の使用可能性の向上を活用するという作業は、次世代のインターネット、たとえばＩｎｔｅｒｎｅｔ２の急増に伴って非常に重要になる。ＱｏＳ駆動資源管理の分野で、多数の出版物及び特許が存在する。作業の大半は、米国特許第５３８８０９７号明細書及び米国特許第５５８１７０３号明細書に記載のようにネットワークに焦点を合わせるか、Ｄａｖｉｄ  Ｋ．Ｙ．  Ｙａｕ及びＳｉｍｏｎ  Ｓ．  Ｌａｍ著の文献「Ａｎ  Ａｒｃｈｉｔｅｃｔｕｒｅ  Ｔｏｗａｒｄｓ  Ｅｆｆｉｃｉｅｎｔ  ＯＳ  Ｓｕｐｐｏｒｔ  ｆｏｒ  Ｄｉｓｔｒｉｂｕｔｅｄ  Ｍｕｌｔｉｍｅｄｉａ」、Ｐｒｏｃｅｅｄｉｎｇｓ  ｏｆ  ＩＳ＆Ｔ／ＳＰＩＥ  Ｍｕｌｔｉｍｅｄｉａ  Ｃｏｍｐｕｔｉｎｇ  ａｎｄ  Ｎｅｔｗｏｒｋｉｎｇ  Ｃｏｎｆｅｒｅｎｃｅ  ’９６、米国カリフォルニア州サンノゼ、１９９６年１月に記載のようにオペレーティング・システムに焦点を合わせたもののいずれかである。インターネットでのマルチメディア・サービスの急増に伴って、ＩＰネットワークが単純な最善努力配送サービスを提供することができたが、ＩＰプロトコルが、マルチメディア・ストリーミング、仮想現実感アプリケーション、分散スーパーコンピューティングなどの新しいリアルタイム・アプリケーションと共に使用するのに適さないことがすぐに理解された。その結果、ＲＳＶＰ（Ｒｅｓｏｕｒｃｅ  Ｒｅｓｅｒｖａｔｉｏｎ  Ｓｅｔｕｐ  Ｐｒｏｔｏｃｏｌ）（たとえば、Ｉａｎ  Ｆｏｓｔｅｒ及びＣａｒｌ  Ｋｅｓｓｅｌｍａｎ編、「Ｔｈｅ  Ｇｒｉｄ：  Ｂｌｕｅｐｒｉｎｔ  ｆｏｒ  ａ  Ｎｅｗ  Ｃｏｍｐｕｔｉｎｇ  Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ」、第１９章、第３７９〜５０３ページ、Ｍｏｒｇａｎ  Ｋａｕｆｆｍａｎ  Ｐｕｂｌｉｓｈｅｒｓ刊、１９９９年を参照されたい）、ＲＴＰ（Ｒｅａｌ  Ｔｉｍｅ  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ）、ＲＴＣＰ（Ｒｅａｌ  Ｔｉｍｅ  Ｔｒａｎｓｐｏｒｔ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）及び他のプロトコルなどの新しいネットワーク・プロトコルが、開発され（たとえば、Ｗｉｌｌｉａｍ  Ｓｔａｌｌｉｎｇｓ著、「Ｈｉｇｈ−Ｓｐｅｅｄ  Ｎｅｔｗｏｒｋｓ：  ＴＣＰ／ＩＰ  ａｎｄ  ＡＴＭ  Ｄｅｓｉｇｎ  Ｐｒｉｎｃｉｐｌｅｓ」、Ｐｒｅｎｔｉｃｅ  Ｈａｌｌ刊、１９９７年及びＩ．  Ｂｕｓｓｅ、Ｂ．  Ｄｅｆｆｎｅｒ及びＨ．  Ｓｃｈｕｌｚｒｉｎｎｅ著、「Ｄｙｎａｍｉｃ  ＱｏＳ  Ｃｏｎｔｒｏｌ  ｏｆ  Ｍｕｌｔｉｍｅｄｉａ  Ａｐｐｌｉｃａｔｉｏｎｓ  ｂａｓｅｄ  ｏｎ  ＲＴＰ」、Ｃｏｍｐｕｔｅｒ  Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ刊、１９９６年１月を参照されたい）、アプリケーションが、帯域幅及び待ち時間などのネットワークＱｏＳパラメータを要求し、ネゴシエートできるようになった。現在のインターネットでのこれらのプロトコルの展開は、成功してはいない。というのは、第１に、すべての非ＲＳＶＰルータ及びサーバのシステム・ソフトウェアをグレードアップする必要があるからであり、第２に、ＲＳＶＰが現在のインターネットで展開されたとしても、非常に限られた帯域幅とコンピューティング資源が、リアルタイム・アプリケーションの成功裡の展開にとって未だにボトルネックになっているからである。現在のイ���ターネットは、バックボーン上で作成され、比較的障害の少ないＴ３（４５メガビット毎秒）での国際通信が可能である。グラフィック・ページと、ストリーミング・オーディオ及びストリーミング・ビデオのアプリケーションの急増が、これらの資源を非常にすばやく枯渇させた。さらに悪いことに、ユーザ人口の増加率が、新規作成されるネットワーク資源よりかなり高い。
【０００５】
米国の全国科学基金（Ｎａｔｉｏｎａｌ  Ｓｃｉｅｎｃｅ  Ｆｏｕｎｄａｔｉｏｎ）及びＭＣＩ  Ｃｏｒｐｏｒａｔｉｏｎは、インターネット・コミュニティの新しい必要に応えて、ｖＢＮＳ（ｖｅｒｙ−ｈｉｇｈ−ｐｅｒｆｏｒｍａｎｃｅ  Ｂａｃｋｂｏｎｅ  Ｎｅｔｗｏｒｋ  Ｓｅｒｖｉｃｅ）と称する新しいネットワークを作成した。この全国ネットワークは、大学主導のＩｎｔｅｒｎｅｔ  ２と称する基金と、連邦調査機関によるＮｅｗ  Ｇｅｎｅｒａｔｉｏｎ  Ｉｎｔｅｒｎｅｔと称する基金の２つの基金のためのバックボーンも提供する。ｖＢＮＳでは、接続された機関の大半が、６２２メガビット毎秒で走行することができる（ＯＣ１２）。西暦２０００年までに、ｖＢＮＳは、２．４ギガビット毎秒（２４００メガビット毎秒）で動作すると期待される。
【０００６】
ｖＢＮＳシステムは、ＲＳＶＰプロトコルを活用して、Ｒｅｓｅｒｖｅｄ  Ｂａｎｄｗｉｄｔｈ  Ｓｅｒｖｉｃｅすなわち、帯域幅コミットメントを有するサービスと、伝統的な最善努力ＩＰサービスという２つの別個のクラスのサービスをサポートする（たとえば、ＵＲＬ  ｈｔｔｐ：／／ｗｗｗ．ｖｂｎｓ．ｎｅｔ／ｐｒｅｓｅｎｔａｔｉｏｎｓ／ｐａｐｅｒｓ／ＱｏＳＤｅｖ／ｉｅｅｅｑｏｓ．ｈｔｍで提供される、Ｃｈｕｃｋ  Ｓｏｎｇ、Ｌａｕｒａ  Ｃｕｎｎｉｎｇｈａｍ及びＲｉｃｋ  Ｗｉｌｄｅｒ著、「Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ  Ｄｅｖｅｌｏｐｍｅｎｔ  ｉｎ  ｔｈｅ  ｖＢＮＳ」、ＭＣＩ  Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ  Ｃｏｒｐｏｒａｔｉｏｎを参照されたい）。それでも、ｖＢＮＳのネットワーク層の資源管理は、オペレーティング・システム層から分離され、記憶装置及びコンピューティング資源などのエンド資源のアプリケーションの必要及び使用可能性から分離されて行われる。
【０００７】
リモート外科手術（ｒｅｍｏｔｅ  ｓｕｒｇｅｒｙ）、ロボティックス（ｒｏｂｏｔｉｃｓ）、遠隔計測（ｔｅｌｅ−ｉｎｓｔｒｕｍｅｎｔａｔｉｏｎ）、自動化危機応答（ａｕｔｏｍａｔｅｄ  ｃｒｉｓｉｓ  ｒｅｓｐｏｎｓｅ）、衛星データのディジタル・ライブラリ、マルチメディアをサポートするウェブ・サイトを介する遠距離学習（ｄｉｓｔａｎｃｅ  ｌｅａｒｎｉｎｇ）、機能強化されたオーディオ及びビデオなどの新しい種類の高性能アプリケーションが現れつつある。しかし、そのような高性能アプリケーションとその連続的なメディア・フローに順応するためには、ネットワーク容量の増加または予約では不十分である。これらの新しいアプリケーションは、エンドツーエンドの資源予約及び許可制御と、その後の、（ａ）エンドシステムでの資源スケジューリング（たとえばＣＰＵ、ディスクなど）と、（ｂ）ネットワーク内のパケット・スケジューリング及びフロー制御と、（ｃ）配送されるエンドツーエンド・サービス品質の監視などの、分散機能の調整が必要である。サービス品質が、エンドシステム装置、通信サブシステム及びネットワークを含めて、システム全体で構成可能であり、予測可能であり、維持可能であることが必須である。さらに、分散システム・アーキテクチャのすべてのエンドツーエンド要素が、所望のアプリケーション・レベルの挙動を達成するために、調和して機能しなければならない。
【０００８】
現在までに、エンドツーエンド・サービス品質サポートの開発にかなりの労力が注がれた。その中には、ＩＢＭ社のＥｕｒｏｐｅａｎ  Ｎｅｔｗｏｒｋｉｎｇ  ＣｅｎｔｅｒのＨｅｉＰｒｏｊｅｃｔで開発された、Ｖｏｌｇ，  Ｃ．、Ｗｏｌｆ，  Ｌ．、Ｈｅｒｒｔｗｉｃｈ，  Ｒ．及びＨ．  Ｗｉｔｔｉｇによる参考文献「ＨｅｉＲＡＴ  −  Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ  Ｍａｎａｇｅｍｅｎｔ  ｆｏｒ  Ｄｉｓｔｒｉｂｕｔｅｄ  Ｍｕｌｔｉｍｅｄｉａ  Ｓｙｓｔｅｍｓ」、Ｍｕｌｔｉｍｅｄｉａ  Ｓｙｓｔｅｍｓ  Ｊｏｕｒｎａｌ、１９９６年に記載のＨｅｉｄｅｌｂｅｒｇ  ＱｏＳ  Ｍｏｄｅｌと、Ｃａｍｐｂｅｌｌ，  Ａ．Ｔ．、Ｌａｚａｒ，  Ａ．Ａ．、Ｓｃｈｕｌｚｉｎｎｅ，  Ｈ．及びＲ．  Ｓｔａｄｌｅｒによる参考文献「Ｂｕｉｌｄｉｎｇ  Ｏｐｅｎ  Ｐｒｏｇｒａｍｍａｂｌｅ  Ｍｕｌｔｉｍｅｄｉａ  Ｎｅｔｗｏｒｋｓ」、Ｃｏｍｐｕｔｅｒ  Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ  Ｊｏｕｒｎａｌ、Ｖｏｌ．  ２１、Ｎｏ．  ８、第７５８〜７７０ページ、１９９８年６月に記載のものなどの、Ｃｏｌｕｍｂｉａ  ＵｎｉｖｅｒｓｉｔｙのＣＯＭＥＴグループで開発されたＥｘｔｅｎｄｅｄ  Ｉｎｔｅｇｒａｔｅｄ  Ｒｅｆｅｒｅｎｃｅ  Ｍｏｄｅｌ（ＸＲＭ）と、Ｎａｈｒｓｔｅｄｔ  Ｋ．及びＪ．  Ｓｍｉｔｈによる参考文献「Ｄｅｓｉｇｎ，  Ｉｍｐｌｅｍｅｎｔａｔｉｏｎ  ａｎｄ  Ｅｘｐｅｒｉｅｎｃｅｓ  ｏｆ  ｔｈｅ  ＯＭＥＧＡ  Ｅｎｄ−Ｐｏｉｎｔ  Ａｒｃｈｉｔｅｃｔｕｒｅ」、Ｔｅｃｈｎｉｃａｌ  Ｒｅｐｏｒｔ（ＭＳ−ＣＩＳ−９５−２２）、Ｕｎｉｖｅｒｓｉｔｙ  ｏｆ  Ｐｅｎｎｓｙｌｖａｎｉａ、１９９５年５月に記載のものなどの、Ｕｎｉｖｅｒｓｉｔｙ  ｏｆ  Ｐｅｎｎｓｙｌｖａｎｉａの学際研究として開発されたＯＭＥＧＡエンドポイント・アーキテクチャと、Ｂｅｒｎｅｔ  Ｙ他による参考文献「Ａ  Ｆｒａｍｅｗｏｒｋ  ｆｏｒ  Ｅｎｄ−ｔｏ−Ｅｎｄ  ＱｏＳ  Ｃｏｍｂｉｎｉｎｇ  ＲＳＶＰ／Ｉｎｔｓｅｒｖ  ａｎｄ  Ｄｉｆｆｅｒｅｎｔｉａｔｅｄ  Ｓｅｒｖｉｃｅｓ」、Ｉｎｔｅｒｎｅｔ  Ｄｒａｆｔ、ＩＥＴＦ、１９９８年３月に記載のものなどのＩｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ（ＩＥＴＦ）の寄稿論文であるｉｎ−ｓｅｒｖアーキテクチャと、Ａｎｄｒｅｗ  Ｔ  Ｃａｍｐｂｅｌｌによる参考文献「Ａ  Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ  Ａｒｃｈｉｔｅｃｔｕｒｅ」、ＰｈＤ  ｔｈｅｓｉｓ、Ｌａｎｃａｓｔｅｒ  Ｕｎｉｖｅｒｓｉｔｙ、１９９６年１月に記載のものなどのエンドツーエンドＱｏＳ要件を扱う統合フレームワークを表す、Ａ．  Ｃａｍｐｂｅｌｌによって開発されたＱｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ  Ａｒｃｈｉｔｅｃｔｕｒｅ  ＱｏＳ−Ａがある。上述のＱｏＳ論文を分析したもう１つの参考文献が、Ａｕｒｒｅｃｏｅｃｈｅａ，  Ｃ．、Ｃａｍｐｂｅｌｌ，  Ａ．Ｔ．及びＬ．  Ｈａｕｗによる「Ａ  Ｓｕｒｖｅｙ  ｏｆ  ＱｏＳ  Ａｒｃｈｉｔｅｃｔｕｒｅｓ」、ＡＣＭ／Ｓｐｒｉｎｇｅｒ  Ｖｅｒｌａｇ、Ｍｕｌｔｉｍｅｄｉａ  Ｓｙｓｔｅｍｓ  Ｊｏｕｒｎａｌ、Ｓｐｅｃｉａｌ  Ｉｓｓｕｅ  ｏｎ  ＱｏＳ  Ａｒｃｈｉｔｅｃｔｕｒｅ、Ｖｏｌ．  ６、Ｎｏ．  ３、第１３８〜１５１ページ、１９９８年５月である。
【０００９】
かなりの作業がＳＲＩ  Ｉｎｔｅｒｎａｔｉｏｎａｌ社によって行われ、参考文献「ＥＲＤＯＳ  ＱｏＳ  Ａｒｃｈｉｔｅｃｔｕｒｅ」、Ｔｅｃｈｎｉｃａｌ  Ｒｅｐｏｒｔ、ＳＲＩ  Ｉｎｔｅｒｎａｔｉｏｎａｌ、１９９８年５月に記載のものなどの分散システムの適応エンドツーエンド・スケーラブル資源管理を可能にする、Ｅｎｄ−ｔｏ−Ｅｎｄ  Ｒｅｓｏｕｒｃｅ  Ｍａｎａｇｅｍｅｎｔ  ｏｆ  Ｄｉｓｔｒｉｂｕｔｅｄ  Ｓｙｓｔｅｍｓ（ＥＲＤｏＳ）が開発された。拡張可能なＲｅｓｏｕｒｃｅ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ  Ｌａｎｇｕａｇｅ（ＲＳＬ）と資源管理アーキテクチャが、Ｇｌｏｂｕｓメタコンピューティング・ツールキット内で実施され、Ｃｚａｊｋｏｗｓｋｉ，  Ｋ．他著、「Ａ  Ｒｅｓｏｕｒｃｅ  Ｍａｎａｇｅｍｅｎｔ  Ａｒｃｈｉｔｅｃｔｕｒｅ  ｆｏｒ  Ｍｅｔａｃｏｍｐｕｔｉｎｇ  Ｓｙｓｔｅｍｓ」、Ｐｒｏｃ．  ＩＰＰＳ／ＳＰＤＰ  ’９８  Ｗｏｒｋｓｈｏｐ  ｏｎ  Ｊｏｂ  Ｓｃｈｅｄｕｌｉｎｇ  Ｓｔｒａｔｅｇｉｅｓ  ｆｏｒ  Ｐａｒａｌｌｅｌ  Ｐｒｏｃｅｓｓｉｎｇ、１９９８年及びＦｏｓｔｅｒ，  Ｉ．、Ｋｅｓｓｅｌｍａｎ，  Ｃ．著、「Ｔｈｅ  Ｇｌｏｂｕｓ  Ｐｒｏｄｕｃｔ：  Ａ  Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ」、Ｐｒｏｃ．  ＩＰＰＳ／ＳＰＤＰ  ’９８  Ｈｅｔｅｒｏｇｅｎｅｏｕｓ  Ｃｏｍｐｕｔｉｎｇ  Ｗｏｒｋｓｈｏｐ、第４〜１８ページ、１９９８年に記載のものなどのさまざまな異なる資源管理戦略の実施に使用されている。
【００１０】
上述の参考文献に記載されたアーキテクチャは、資源予約とエンドツーエンド資源の管理を対象とするが、これらは、一般に、遅延とエラーに関する境界を提供し帯域幅需要を満たす単一の均等に地理的に制限されたネットワーク・サブシステムと、実行時ＱｏＳ保証を提供することのできるオペレーティング・システムを前提とする。しかし、次世代インターネットは、単にネットワークのネットワークではなく、まず分散システムのシステムとみなさなければならない。このパラダイムでは、通信資源だけではなく、コンピューティング・サーバ及び記憶サーバが、多数のユーザの間で共用される。
【００１１】
したがって、上述のアーキテクチャは、個々のコンテンツ及びコンピューティング資源に関する要求活動に応じた全体的なシステム資源の調整された管理を提供しない。これは、特定のサービスに事前に割り当てられた資源を扱う。その結果、サービス品質は、確立された限界を超えるそのようなサービスに関する要求の量の増大に応答して、低下するに違いない。上述のアーキテクチャは、アプリケーションによって要求された際のＱｏＳの提供に焦点を合わせているので、特定のサービスに関するユーザ要求の間の共通性に起因する、資源の可能な集約を利用しない。
【００１２】
たとえば、特定のマルチメディア・コンテンツの使用履歴の共通性、たとえば短い時間間隔内の要求のバースト、要求の起点アドレスの近接性などを判定することが望ましい。さらに、上で述べたアーキテクチャでは、個々のクライアントに関するサービスのコストを計算する目的の、個々のサービスならびに関連するサービスのグループの資源消費の動的な監視及び記録が可能ではない。
【００１３】
したがって、次世代インターネットの力を活用する広範囲に分散された資源のための資源管理機構を提供し、さらに、資源の動的ポーリング、再割当及び解放についてすべてのシステム資源の調整を可能にして、結果としてアプリケーションによって要求されるＱｏＳを提供するシステムを提供することが、非常に望ましい。
【００１４】
資源管理に対する以前の手法は、集中システムであれ分散システムであれ、オペレーティング・システム内での個々の資源の独立の最適化に焦点を合わせたものである。分散システムのための手法は、独立の資源管理のためのより高水準のモデルを提供したが、複数の資源の調整が欠けている。たとえば、ＲＳＶＰは、マルチメディア・アプリケーションによって要求された時のエンドツーエンド資源予約を提供するが、ＣＰＵまたはディスクなどの資源にまたがる調整及び共同割振りという概念が欠けている。
【００１５】
【発明が解決しようとする課題】
したがって、単一資源の単一ノード資源管理から、複数資源の複数ノード資源管理に移動する新規の資源管理システムを提供することが非常に望ましい。
【００１６】
【課題を解決するための手段】
本発明の目的は、メディア・サービスのためのユーティリティ・モデルをサポートし、次世代インターネット上での仮想近接を考慮に入れる、分散ネットワークでの資源管理のためのシステムを提供することである。インターネット・マルチメディア・ユーティリティ・モデルでは、メディア・サービスは、保証が行われ、満足される限り、供給当事者の位置が購読当事者に無関係になる形で、支払購読者集団に対して供給される。
【００１７】
本発明のもう１つの目的は、インターネット・メディア・ユーティリティ・モデルを駆動し、促進することのできる、異種サーバにまたがる資源管理のための機構、具体的には、ネットワーク全体にばらまかれた分散メディア・サーバが供給する資源に対する仮想近接を活用することのできる、インターネット・メディア・ユーティリティ環境でメディア・サーバを管理し、展開し、構成するための機構を提供することである。
【００１８】
本発明のもう１つの目的は、単一資源の単一ノード資源管理から複数資源の複数ノード資源管理に移動することによって、資源管理に対する新規の手法を実施することである。この資源管理に対する新規の手法は、単一資源利用度の最適化から資源の組の統計的エンジニアリングに移動する。本発明は、資源管理（すなわち、通常は低水準の機能性）を高水準サービス管理（すなわち、アプリケーション・レベルの機能性）と統合するための手段を実施する。
【００１９】
本発明は、インターネット・マルチメディア・ユーティリティを支払購読者に供給するための、分散サーバにまたがるマルチメディア資源管理に対するサービス指向の手法に関する。具体的に言うと、広範囲に分散したメディア・サーバにまたがるサービス及び資源の統合管理のためのシステムが提供される。このシステムには、「サービス単位」と称する同種サービス指向資源単位に関する異種メディア・サーバの構成が含まれ、サービス単位は、特定のメディア・サービスをオンデマンドで供給できるようにするための特定のサーバからの資源割振りコミットメントを表すのに使用される。好ましい実施例では、サービス単位は、その要素がメモリ資源、ディスク資源、ネットワーク資源及びＣＰＵ資源の資源割振りを表す割振りベクトルに関して表現される。サービス単位は、メディア・サービスの供給のために必要なクリティカルな資源の組に対するいくつかの判断基準に従うバインドされた組を表す生成された資源エンベロープを用いるメディア・サービスの供給のために必要な資源要件のエンベロープを表す。したがって、異なるサービス単位が、各サービスに関連し、同一のサービス単位定義は、おそらく同一のメディア・サービスをサポートする異なるサーバにまたがる異なる資源エンベロープをもたらす。そのような資源エンベロープ・プロファイルは、時間変動または一定とすることができる。本発明のシステムは、さらに、あらゆるメディア・サービスに関するそのような資源エンベロープの生成及び適合のための機構を提供する。
【００２０】
本発明によれば、サーバは、メタ資源（「資源を提供する資源」）と呼ばれるが、これは、サービスの観点を指し、メモリ、ＣＰＵ、帯域幅などの低水準資源に対する従来の言及を指さない。メタ資源がメディア・サービスを供給する能力（たとえば必要なソフトウェア）を、サービス単位がそのようなサービスを購読当事者に供給することへのコミットメントであるという概念と共に、ケイパビリティと称する。
【００２１】
メタ資源が自律的であることを可能にすることも、本発明の目的である。したがって、本発明の原理によれば、メタ資源に対するアプリケーション・レベルのアクセス制御を提供することによって、メタ資源の自律性が保存される。この目的のために、各サービス単位は、「サービス・シグニチャ」と称するメタデータと関連し、サービス・シグニチャは、たとえば資源管理に関してメタ資源にヒントを配布することによって、メタ資源のサービス・コミットメントをカストマイズするために実施される。たとえば、サービス単位を使用して、特定のサービス単位のアクセス権及び特性を定義することができる。同様に、サービス・シグニチャによって、異なる負荷でのこのメタ資源の種類の下でこのサービス単位の資源エンベロープを更新するのに使用される実行時補償戦略を推奨することができる。したがって、サービス・シグニチャは、本発明によってサービス管理と資源管理を統合できるようにする方法の１つである。
【００２２】
有利なことに、本発明によって、任意のメディア・サーバが、オープンで統制されていないインターネット・ユーティリティ環境に参加し、価値のある位置を提供できるようになる。この目的のために、本発明のシステムは、異種サーバにまたがる資源管理の異種性を除去する。すなわち、本発明によれば、メタ資源が、リモート管理オーソリティまたはリモート管理実体に反応するが、その資源の自律制御を維持することができる。したがって、本発明は、オーソリティに対するサービス単位に関するメタ資源の構成（すなわち、サービス指向の約束またはコミットメント）を可能にし、それと同時に、これらのコミットメントの実現が、メタ資源に委ねられる。
【００２３】
さらに、本発明によれば、メタ資源は、異なる独立の資源プールとして、すなわち、ローカル管理下でメディア・サービスを提供するためにメタ資源によって実施されるローカル資源プールと、リモート管理下でメディア・サービスを提供するためにメタ資源によって実施されるグローバル資源プールとして区分し、管理することができる。これらの資源プールの管理は、サービス単位の種類と数に関して使用可能にされ、したがって、メタ資源の管理者が、そのようなメタ資源がリモート管理者に提供する価値を拡張することができる。そのような管理は、予想される収入または他のコスト測定基準などの判断基準に基づくものとすることができる。これは、個々のメタ資源が、それらの資源プールの管理とサービス単位及びサービス・ケイパビリティの選択によるサービス要求の獲得に対するさまざまな度合の貪欲さの資格を与えられることをもたらす。
【００２４】
本発明は、インターネット・ユーティリティの領域及びそのマルチメディア・サービスへの新規で有用な形の応用に対処するのに使用される。たとえばインターネット・テレビジョン及びインターネット・ラジオを含む、遠距離学習、仮想現実感、エンターテイメント・サービスなどにわたる応用分野を有する新たなインターネット・ユーティリティの組が予想されるので、サービス・ユーティリティの性質は、分散チャネルのエンジニアリングを中心とする。電話網などの従来の分散チャネルでは、分散の制御が、資源のオーバーエンジニアリングと統計的多重化を介して達成される。仮想近接の出現に伴って、本発明は、エンドツーエンド資源の統計的オーバーエンジニアリングを可能で望ましいものにすると同時に、メタ資源の急増を促進しながらメタ資源のための新しい収入参加モデルを提供する。
【００２５】
【発明の実施の形態】
図１は、メディア・サービスが支払購読者集団に供給される、インターネット・メディア・ユーティリティ環境モデルまたはグローバル・メタシステム１００を示す図である。本発明によれば、以下で詳細に説明するように、たとえば供給側のサーバ（１０２、１０４、１０６、１０８）などのメタ資源の位置は、適当な資源管理技法を実施することによって保証が行われ、満足される限り、たとえばクライアント（１１２）及び（１１４）などの購読当事者に無関係である。本発明は、仮想近接に起因して、広域ネットワークからのばらまかれた資源の効率的な管理によって資源が豊富に見える次世代インターネットに有用であり、適する。
【００２６】
資源管理では、それぞれが資源管理に対する異なる手法を有する広範囲に分散した異種システムを扱わなければならないので、本発明の技法では、サーバ間の異種性に対処する機構として、共通サービス・モデルの知識を活用する。この目的のために、本発明は、プラットホーム独立の形でのサーバ内の資源の構成及び管理を容易にする。本明細書で詳細に説明するリモート・オーソリティ（２００）によって提供されるグローバル・メタシステムのリモート管理が、たとえばサーバ（１０２）及び（１０４）などの異種サーバを、それらの間で選択する時に同一の基礎に基づいて比較できることが本質的であり、望ましい。この目的のために、本発明では、サービス単位に関して定義されるメタ資源（たとえばサーバ）の能力を有するサービス単位（１５０）構造を実施する。
【００２７】
具体的に言うと、図２からわかるように、サービス単位（１５０）は、割振りベクトルすなわち資源エンベロープ（１５１）に関して表現され、資源エンベロープ（１５１）の要素は、メモリ（１６２）、ディスク入出力（１６３）、ネットワーク帯域幅（１６４）及びＣＰＵ資源（１６１）の資源割振りを表す。本明細書で詳細に説明するように、サービス単位割振りベクトルを、本明細書では、メディア・サービスを供給する必要に応じて「資源エンベロープ」と称する。資源エンベロープは、メディア・サービスの供給に関連するクリティカルな資源要件に対する判断基準に従うバインドされた組を表す。さらに、リモート・オーソリティは、関連する資源エンベロープの特性に関する「サービス・シグニチャ（１５２）」またはメタデータ構造を維持する。一般に、サービス・シグニチャには、サービス管理メタデータ（１６６）ならびに資源管理メタデータ（１７６）が含まれる。そのようなサービス・シグニチャが、資源管理に対する統合されたサービス指向管理手法のカストマイズに使用されることが、本発明の１態様である。具体的に言うと、サービス・シグニチャによって、その特定のサービス単位を使用することができるサービスのアクセス権、特権及び特性などに関する情報、ヒント及び推奨が記述される。たとえば、サービス単位を使用して、特定のサービス単位のアクセス権（１６７）及びコスト（１６９）の特性を定義することができる。サービス・シグニチャは、資源管理に関してメタ資源にヒントを配布するのにも使用される。たとえば、サービス・シグニチャは、おそらく異なる負荷で所与のメタ資源の種類について供給されるサービス単位の資源エンベロープの更新に使用される実行時補償戦略（１７８）の推奨に使用することができる。すなわち、本明細書で詳細に説明するように、本発明のシステムは、メディア・サービスの供給中に見つかった実際の資源要件と、サービス単位に関連する資源プロファイルの間の差を保証するための手段を提供する。サービス単位によって計画された資源エンベロープが、サービス・オブジェクトの供給に必要な資源要件を誤って推測する可能性がある。サービス・シグニチャ（１５２）は、本発明がサービス管理と資源管理の統合を可能にする方法の１つである。
【００２８】
本発明によれば、リモート・オーソリティ（２００）は、同種サービス指向資源単位すなわちサービス単位に関して異種メタ資源を構成するための機構を実施する。具体的に言うと、サービス単位は、特定のメディア・サービスをオンデマンドで供給できるようにするための、参加サーバからの資源割振りコミットメントを表すために使用される。異なるサービス単位が、各サービスに関連し、それと同一のサービス単位の定義が、同一のメディア・サービスをサポートする異なるメタ資源にまたがる異なる資源エンベロープをもたらす場合がある。そのような資源エンベロープ・プロファイルは、本明細書で詳細に説明するように、時間変動または一定とすることができる。そのような資源エンベロープをすべてのメディア・サービスについて生成し、適合させることが、本発明の１態様である。
【００２９】
本明細書で詳細に説明するように、本発明は、メタ資源内の資源の共同割振りを可能にするための機構として、サービス・ビンの構造を実施する。サービス・ビンの生成は、サービスを供給するための総合的な資源要件に対する性能エンベロープを提供することを目的とする。資源エンベロープの生成は、メタ資源側でまたはリモート当事者によってのいずれかで行うことができることに留意されたい。どちらの場合も、さまざまな資源の性能エンベロープを生成するための技法は、当技術分野で既知である。たとえば、管理者は、資源エンベロープを生成するために、アプリケーションに対して典型的なコンテンツのテスト集を適用することによって、ビン仕様を生成することができる。エンベロープは、たとえばワースト・ケースまたは第７０百分位数とすることのできる、長期資源割振りを定義することが目的である。ワースト・ケース割振りを使用しない場合には、資源割振り要件に対する相違をオンデマンドで補償するための技法が存在する。具体的に言うと、本発明では、共用オーバーフロー・プールを使用して、そのような資源をオンデマンドで分配する。偏差のランキングを使用して、たとえばそのような偏差を意外に早く破棄するために、このオーバーフロー・プールの使用をさらに最適化することができる。偏差のランキングを作成して、補償ビンがそのような偏差を意外に早く破棄できるようにすることができる。
【００３０】
一般に、特定のサービスの資源エンベロープの生成は、以下のステップからなる。第１に、サービス・オブジェクトの初期セットを、使用の頻度または類似性などの判断条件に従って選択する。第２に、資源プロファイルを、サービス・オブジェクトの供給に関連するクリティカルな資源のそれぞれについて取得する。第３に、資源プロファイルを、Ｋ個の固定された持続時間区間に平滑化する。第４に、各区間について、資源要件エンベロープを計算する。格納された連続メディアについてそのような平滑化された性能エンベロープを生成する既知の方法が存在することを、技量を有する熟練者は諒解するであろう。たとえば、格納されたＭＰＥＧコンテンツのストリーミングに基づくインターネット・テレビジョン・モデルの場合、多くともＫ個のセグメントからなるプロファイルを取り出すための既知の方法が存在する。第５に、エンベロープの特性に関するメタデータの抽出と、代表的なサービス・オブジェクトに対する適合である。たとえば、８０％百分位数を使用して、約８０％のピークがメタデータに対して識別される第２層エンベロープを生成することができる。最後に、資源エンベロープとメタデータを、サービス単位データベースに格納する。
【００３１】
図３及び４は、例として、本質的に所与のサービス、たとえばストリーミング・ビデオの供給の、資源使用対時間のプロットである、時間変動の資源エンベロープ（１５１）プロファイル（図３）のテスト生成を示す図である。図３からわかるように、ある方法では、メモリ資源の変動２０２が判定されるが、メモリ資源の変動２０２は、図３では、時刻Ｔの使用レベル「ｂ」（たとえば２Ｍバイト）から時刻Ｔ１の使用レベル「ｅ」（たとえば６Ｍバイト）に増加する。同様に、線２０４からわかるように、同一のサービスの帯域幅資源は、時刻Ｔの使用レベル「ａ」から時刻Ｔ１の使用レベル「ｄ」に減少する。ＣＰＵ性能変動は、ＴからＴ１までの時間区間にわたってレベル「ｃ」で一定として示されている。それぞれの暗い線２１２、２１４及び２１６は、時間方向のその資源の平均値または統計値を表すが、ワースト・ケース・レベルを表すものとして定義することもできる。図３に示された時間変動資源エンベロープに対応する表（１５２）を、図４に示す。
【００３２】
異なるメタ資源が、特定の必要及び要求にあわせるために同一のサービス単位についてわずかに異なる資源エンベロープを有する場合があることが理解される。さらに、サービス単位データベース（図示せず）によって、特定のサービス単位の資源エンベロープのキャッシュ記憶、記憶及び更新が可能になる。
【００３３】
図１に戻ると、メタ資源すなわちサーバの概念がさらに図示されており、これは、たとえば異種メディア単位ストリーミング能力を表すことのできる、ケイパビリティに関して表されている。たとえばサーバ１０６などの各サーバは、たとえばマルチメディア・オブジェクトなどの永続的コンテンツを維持するための記憶ビン（１１６）と、たとえばクライアントへのマルチメディア・コンテンツのストリーミングのための、サービス資源を維持するための記憶ビン（１１８）とを含むものとして論理的に区分することができる。各サーバは、さらに、ローカル記憶ケイパビリティ及びローカル・サービス・ケイパビリティ（１１６ａ、１１８ａ）と、グローバル記憶ケイパビリティ及びグローバル・サービス・ケイパビリティ（１１６ｂ、１１８ｂ）を含むものとして論理的に区分することができる。たとえば、図１のサーバの記憶ビン（１１６）には、たとえばディジタル・ビデオ・ストリーミング・サービスを提供するためにローカル資源にバインドされたローカル記憶オブジェクトＳ１が示されている。各ケイパビリティは、ローカル管理またはグローバル管理に割り当てることができ、たとえば、リモート・オーソリティ（２００）のリモート管理者が、グローバル・ケイパビリティを管理し、ローカル・ケイパビリティが、メタ資源の管理者によって管理される。メタ資源の管理では、ある比率のグローバル・ケイパビリティ（たとえば１００−ｘ％）とローカル・ケイパビリティ（たとえばｘ％）が割り振られることを理解されたい。
【００３４】
図１及び図５からわかるように、メタ資源の容量は、サービス単位（１５０）（資源エンベロープ（１５１）とメタデータを含むサービス・シグニチャ（１５２）とを含む）と、ローカル記憶ケイパビリティ（１１６ａ）及びローカル・サービス・ケイパビリティ（１１８ａ）を含むローカル・プール（１２４）と、グローバル記憶ケイパビリティ（１１６ｂ）及びグローバル・サービス・ケイパビリティ（１１８ｂ）を含むグローバル・プール（１２６）とに関して測定される。サービス単位ごとに、サービス・ビンを関連付けることができ、このサービス・ビンは、たとえばメモリ、ＣＰＵ、帯域幅などの異なる資源ケイパビリティ・タプルごとに１つのスロット（たとえば１２０）を有する。ケイパビリティのほかに、メタ資源は、各コンテンツに使用される記憶ビンを管理する。各メタ資源は、ローカルまたはグローバルのコンテンツを割り当てられる。グローバル・コンテンツは、本明細書と共通の譲受人が所有する同時出願の米国特許出願第            号明細書（ＹＯ９９９−２４２）に記載の技法に従って得ることができる。複製されたコンテンツは、グローバルに維持される。ローカル・コンテンツを、オリジナル・コンテンツと称する。ストリーミング接続は、記憶ビンをサービス・ビンにバインドすることによって形成され、そのバインディングは、サービス品質で評価される。サービス・ビンは、そのような解決でコンテンツをストリーミングするのに必要な資源要件に関連する。各コンテンツは、バインディングの評価を容易にするのに使用される資源エンベロープ（１５１）に関連する。
【００３５】
本発明の資源管理システムは、そのようなインターネット・メディア・ユーティリティ・モデルを任意のメディア・サーバに対してオープンする。具体的に言うと、本発明のシステムは、任意のメディア・サーバが、オープンで統制されていないインターネット・ユーティリティ環境に参加でき、価値のある位置を提供できるようにする。この目的のために、本発明は、サービス単位の使用を介して、異種サーバ間の資源管理の異種性を除去することを意図する。
【００３６】
そのような資源管理の管理は、中間物に委譲することができる。具体的に言うと、ネットワーク全体にばらまかれたメディア・サーバによって提供される資源が、購読者集団またはその一部の特性及び必要に合わせることができるようにする機構を提供する。したがって、本発明と所有者が共通する関連特許米国特許出願第            号明細書（ＹＯ９９９−２４１）に記載のキャパシティ・シェーピング（capacity shaping）機構に従って、本発明は、リモート・オーソリティが、たとえば特定のサーバの必要ではなくそのようなサーバの集合的必要などの判断基準に基づいて、サーバにまたがるサービス単位の管理を駆動できるようにする。本発明と所有者が共通する関連特許米国特許出願第            号明細書（ＹＯ９９９−２４０）で提供される開示に従って、リモート・オーソリティに、分散コンピュータ・ネットワーク内のクライアントとサーバの間の中間制御装置として機能するサービス・コントロール・プレーン（Service Control Plane、ＳＣＰ）を含めることができる。
【００３７】
メタ資源がリモート・オーソリティにとって有用であることが望ましいので、メタ資源は、（１）自律的であり、（２）信頼され、（３）構成可能であり、（４）リモート管理に対して価値のある位置を提供できる。メタ資源が自律的なままであるのは、そうでなければ、リモート・オーソリティの制御へのメタ資源の引渡が、メタ資源の急増を阻止するからである。本発明は、サービス単位、サービス・シグニチャ及び独立なグローバル資源管理とローカル資源管理という３つの概念を介してこの自律性を配布する。したがって、技量を有する熟練者は、サービス・コミットメントと資源予約の間の相違と、メタ資源への自律性の拡張に対する役割を諒解するであろう。
【００３８】
同様に、技量を有する熟練者は、メタ資源がリモート・オーソリティによって信頼される必要があり、リモート・オーソリティがメタ資源によって信頼される必要があることを諒解するであろう。メタ資源にアクセスする時のセキュリティは、コンテンツ購読者にとって重要である。異なる当事者間の信頼を実施するための機構が必要である。現在の最良の実施によれば、ＲＳＡなどの鍵交換機構を使用して、資源提供業者とハンドシェークし、資源提供業者を認証することができる。このような機構は、他の当事者にも適用可能である。アクセスされるコンテンツに関するセキュリティは、さらに、コンテンツ提供業者にとって重要である。したがって、コンテンツに対する著作権及び他の形式の知的財産保護の実施が必要である。技量を有する熟練者は、これが認知された必要であり、異なるレベルの信頼を有する当事者間の著作権実施を容易にするための手段を展開できることを諒解するであろう。具体的に言うと、ディジタル透かし技法を、サービス・オブジェクトの著作権の安全保護に使用することができる。
【００３９】
メタ資源が、たとえばＳＣＰなどのリモート・オーソリティ（２００）（図１）に価値のある位置を提供するためには、メタ資源は、ＳＣＰに反応しなければならないが、その資源の自律制御を維持しなければならないことが意図されている。この目的のために、本発明は、ＳＣＰに対する、サービス単位（すなわちサービス指向の約束またはコミットメント）に関するメタ資源の構成を可能にすると同時に、これらのコミットメントの実現は、メタ資源に委ねられる。前に図１に関して述べたように、メタ資源は、ローカルに管理することができ、各メタ資源は、コンテンツ提供業者にサービスを提供するために永続的コンテンツを保持するローカル仮想メディア・サーバと、フレームワークのより幅広い必要を満たすためのサービスを提供するためにコンテンツを複製することのできる、ＳＣＰが管理するグローバル仮想メディア・サーバという２つの仮想メディア・サーバに区分される。この目的のために、好ましい実施例では、メタ資源が、別々の管理を有する、２つの異なる独立の資源プールに区分される。一方では、ローカル資源プールは、ローカル・メタ資源管理によって割り振られるメディア・サービスを提供するためにメタ資源によって実施される。その一方で、グローバル資源プールは、リモート管理オーソリティによって割り振られるメディア・サービスを提供するためにメタ資源によって実施される。
【００４０】
図６は、たとえば資源ｓ１（５０１）、ｍ１（５０２）、ｃ１（５０３）及びｂ１（５０４）を消費するなど、ＭＰＥＧ−１コンテンツのストリーミングを示す図である。ＭＰＥＧ−２でコード化されたものなどのもう１つの種類のコンテンツのストリーミングは、資源ｓ２（５１１）、ｍ２（５１２）、ｃ２（５１３）及びｂ２（５１４）を必要とする可能性がある。したがって、さまざまなクラスのアプリケーションによる資源の消費の測定の便利な手段として、資源の特性は、記憶ビンｓ及びサービス・ビンｒ（ｍ、ｃ、ｂ）として表すことができる。その結果、資源は、サービス供給のためのケイパビリティを表す、記憶ビン及びサービス・ビンの組として見ることができる。すべてのアプリケーションが同一ではないので、コンテンツに関する最悪資源限界を得る必要があり、さまざまなサーバに関する異なるクラスのアプリケーションの実験的測定が必要になる。しかし、この手法を用いると、さまざまなクラスのアプリケーションによる異種サーバ資源の便利な正規化及び予約が可能になる。
【００４１】
前に述べたように、システム管理者は、資源全体をローカル及びグローバルとして構成する。管理者は、各サーバのローカル資源対グローバル資源の比率を確立し、これらの資源の負荷制限に関する方針を確立する責任を負う。区画をグローバル記憶域として構成した後に、グローバル資源管理が、この資源の制御を引き継ぐ。したがって、グローバル記憶ビンは、ＳＣＰによって提供されるグローバル資源管理によってのみ予約することができる区画を表す。関連する方針に応じて、システム管理者またはサーバ（５００）自体が、ＳＣＰ管理からの解放を要求することによって、グローバル資源をすべてまたは部分的に再請求することができることに留意されたい。図６に示されたネイティブ予約管理プロセス（５２０）は、資源消費を監視し、サーバが新しい要求を進んで受け入れるかどうかを判定する責任を負う。ネイティブ・プロセスは、グローバル・コンテンツに関するアプリケーション要求とローカル・コンテンツに関するアプリケーション要求を区別する場合があることを理解されたい。さらに、グローバル複製の配置の要求は、許可制御に関するメタ資源の自律性を支配する内部メタ資源方針による制御に従って、拒否されるか受け入れられる可能性があり、たとえば、そのような方針の１つが、グローバル資源に関連する収入を最大にすることを試み、したがって、高いコストまたは低い収入を有すると期待される複製を拒絶する可能性がある。そのような方針は、ＳＣＰによって監視される要求統計に依存することもできる。
【００４２】
図７は、システム管理者が、すべてのサーバ資源を、一方はローカル、もう一方はグローバルの２つの区画に構成した例のシナリオを示す図である。図７に示された例のシナリオからわかるように、２つのストリーミング・アプリケーションが、過渡的なコンテンツ複製を共用し、１つのグローバル記憶ビンｓ２（６０２）と２つのサービス・ビンｒ２（６０３）及びｒ３（６０４）を消費するが、一方のアプリケーションは、サーバ記憶ビンｓ１（６０１）に含まれる永続的なコンテンツ複製を消費する。したがって、消費される全グローバル記憶資源は、ｓ２に等しく、全グローバル・サービス資源は、ビンｒ２及びｒ３の合計である。
【００４３】
図５に戻ると、本発明に従って規定されるメタ資源での、サービス・ビン及び記憶ビンの例の使用とグローバル・ビン及びローカル・ビンの使用が示されている。前に述べたように、サービス単位は、対応するメディア・サービスを供給するためのメタ資源によるサービス指向資源コミットメントを表す。同様に、サービス単位は、グローバル、ローカルまたはその両方としてコミットすることができる。一方で、ローカル・サービス単位は、メタ資源があるサービス・オブジェクト（それらの資源を介して供給される）への資源（サービス単位に関連する）のバインディングを決定する場合の特定のメタ資源によるサービスの単位に関するコミットメントを指示するのに使用される。その一方で、グローバル・サービス単位は、あるサービス・オブジェクトへのメタ資源のバインディングが、メタ資源にとって外部の存在によって後程決定される場合の特定のメタ資源によるサービスの単位のコミットメントを指示するのに使用される。メタ資源には、ローカルに使用可能（Ｌ）、グローバルに使用可能（Ｇ）または両方（Ｌ、Ｇ）としてのマッピングを有する、サービス・オブジェクトｃ１、．．、ｃ４のリスト（１４０）を含めることができる。
【００４４】
ケイパビリティ・バンク（１３０）で示される、メタ資源によって供給されるサービスの種類（すなわちケイパビリティ）ごとに、複数のサービス単位が事前に割り振られる。したがって、図５からわかるように、１０個のサービス単位「Ａ」を、ローカル・プールにコミットすることができ、５つのサービス単位「Ａ」を、グローバル・プールにコミットすることができる。事前割振りは、グローバル・プールとローカル・プールの両方について独立に行われることが好ましい。メタ資源の管理では、予想される収入または入手可能性などの判断基準に従って、この数（本明細書ではケイパビリティの容量と呼称する）を定義する。たとえば、メタ資源は、メタ資源管理による決定に従って、０％から１００％までグローバル（すなわち、グローバル・メタシステムを用いて共用可能）とすることができる。メタ資源内の端数のサービス単位に関連する資源は、オーバーフロー・プール（図示せず）と称する第３のプールに割り振ることができることに留意されたい。すなわち、サービス供給の要件または必要に従ってグローバル及びローカルの両方のサービス・ビンを割り振った後に、残りの資源がある場合がある。これらの残りの資源は、図８に示されたオーバーフロー・プール（７３３）として管理される。したがって、オーバーフロー・プールには、サービス・ビン供給のために予約されておらず、したがって、必要とみなされた時にメタ資源（サーバ）によって自由に割り振ることのできる資源が含まれる。たとえば、オーバーフロー・プールは、実行時資源補償を提供するのに必要な資源を供給するのに使用することができる。
【００４５】
これらの３つの異なるプールのすべてが、独立に管理されることが、本発明の１態様である。本発明は、サービス単位の種類及び数に関するこれらの資源プールの管理を可能にする。したがって、メタ資源の管理は、需要に合わせてこれらの資源プールを再構成することによって、そのようなメタ資源がリモート・オーソリティに提供する価値を拡張することができる。そのような管理は、期待される収入または他の何らかのコスト測定基準などの判断基準に基づくものとすることができる。個々のメタ資源が、需要及び収入の期待に合わせて資源プール及びケイパビリティを構成することによって、サービス要求の獲得に対するさまざまな度合の貪欲さの資格を与えられることが、本発明のもう１つの態様である。さらに、メタ資源のそのような管理をリモートから行うことができることが、本発明の１態様である。具体的に言うと、グローバル、ローカル及びオーバーフローの間のケイパビリティの比率を、たとえばリモート・オーソリティの必要に基づいて、動的に設定することができる。
【００４６】
メタ資源上のメディア・サービスは、ケイパビリティに関してモデル化される。本明細書では、ケイパビリティは、たとえばストリームｆを入力としてとり、ストリームに対して変換を適用し、ストリームｆ’を出力する、メディア・フロー処理機能を指すのに使用される。そのような機能の例には、メディア・フィルタ、エンコーダ、デコーダ、トランスコーダ、マルチプレクサ、デマルチプレクサ、フレーム・カウンタ、オブジェクト・デテクタ、フロー暗号化、コンテンツ・ベース・フィルタリング、コンテンツ翻訳などが含まれるが、これに制限されない。そのようなケイパビリティを、メタ資源にダウンロードすることができることを理解されたい。しかし、メタ資源は、一部の資源管理特性（たとえば所望の地理的位置での所望の帯域幅）で所望のトレードオフを提供することができるが、必要なサービス管理特性（たとえば所望のケイパビリティの存在）が欠けている場合がある。したがって、本発明によれば、メタ資源は、そのケイパビリティの一部をリモート・ケイパビリティ・バンクに要求し、ダウンロードすることができる。
【００４７】
この目的のために、サービス挿入ポイント・メタ資源にケイパビリティをダウンロードするための機構を提供する。オーソリティ（たとえばリモート管理オーソリティ）を使用して、分散メタ資源の集合を介するケイパビリティの正しい配置と、そのような配置を行うことのできる位置を、たとえば帯域幅、地理、利用度に関する費用便益分析などのセット判断基準に基づいて決定することができる。その代わりにまたはそれに加えて、ケイパビリティの配置は、そのようなケイパビリティの配置をリモート管理によって割り当てさせるのではなく、オークションにかけることができる。最後に、メタ資源が、たとえばリモート管理の必要に合わせるためなど、その資源とケイパビリティの構成及び管理に関する推奨を受け取れるようにする機構を提供する。
【００４８】
ケイパビリティ及びサービス単位に対するアクセス制御を介して、資源提供業者は、ケイパビリティのダウンロードならびにその資源の管理及びサービス単位への構成を、許可または拒否することができるようになる。
【００４９】
図８は、メタ資源側でのサービス単位資源管理の構成要素を示す図である。サービス単位シグナリング・アダプタ（７００）は、メタ資源が、サービス単位に関する供給要求（７０５）を受け取れるようにする。サービス単位シグナリング・アダプタ（７００）を用いると、メタ資源が、サービス単位、供給要求、サービス・シグニチャ及び資源エンベロープに関して外部の当事者と通信できるようになる。サービス単位シグナリング・アダプタ（７００）を用いると、リモート中間コントローラが、このメタ資源内の資源管理とインターフェースできるようになる。サービス単位データベース（７１０）は、サービス単位管理モジュール（ＳＵＭＭ）（７２０）に、特定のサービス単位に関連する資源エンベロープを供給する。サービス単位管理モジュール（７２０）は、個々の資源要求へのサービス単位の変換を調整し、サービス単位マッパ（７３０）とインターフェースして、調整された要求を配置し、１つまたは複数の資源にまたがる資源割振りについて更新する。具体的に言うと、サービス単位マッパ（７３０）への調整されたサービスは、サービス・ビン仕様を受け取り、補償されたサービス単位の資源エンベロープに基づいて、個々の資源割振りを生成する。オペレーティング・システム・インターフェースは、ＣＰＵ（７６１）、メモリ（７６２）、ネットワーク帯域幅（７６３）、ディスク帯域幅及びディスク記憶域（７６４）などの個々の資源へのアクセスを提供する。サービス単位マッパ（７３０）は、さらに、個々の資源管理インターフェースへのインターフェースを提供する。実行時補償ユニット（７３５）は、資源エンベロープに対して必要な調整を計算する。サービス単位管理モジュール（７２０）は、個々の資源要件ではなく、アプリケーション・レベル単位に関する資源の管理を可能にする。したがって、資源は、アプリケーション要件に関して割り振られ、固定された資源利用度に対してではなく、ローカル及びグローバルのコスト測定基準に対して最適化される。ＳＵＭＭを用いると、実行時調節の実施を、サービス単位エンベロープに対して行えるようになり、サービス単位加重関数に対する実行時調節が可能になる。
【００５０】
要求をサービスするほかに、リモート・オーソリティは、特定のサービス単位の定義（すなわちエンベロープ及びシグニチャ）をメタ資源に対してプッシュ（すなわち更新）することができることを理解されたい。明らかに、これは、新規サービスが導入される時に必要である。というのは、そうでなければ、各サービス単位を各サーバで手動でロードする必要が生じるからである。資源エンベロープをメタ資源にプッシュする場合には、メタ資源は、新しい資源エンベロープを用いてそのサービス単位データベース（７１０）を更新する。技量を有する熟練者は、新しいサービス・オブジェクトが導入され、サービス・オブジェクトの作成者によって資源エンベロープが推奨されている時に、そのような動作が望ましいことを諒解するであろう。供給要求がメタ資源にディスパッチされる場合には、サービス単位管理モジュール（ＳＵＭＭ）は、使用可能な資源に対して、その供給要求をメタ資源によってスケジューリングできるかどうかを判定する。サービス・シグニチャがメタ資源にプッシュされる場合には、ＳＵＭＭは、将来の更新の処理中に、対応するサービス・シグニチャを更新する。複数のサービス単位に関する予約が、メタ資源に対して要求される場合には、ＳＵＭＭは、計画された資源に対して、その予約をスケジューリングできるかどうかを判定する。
【００５１】
さらに補償に関して、サービス単位によって計画された資源エンベロープで、サービス・オブジェクトを供給するのに必要な資源要件が誤って推定される可能性が存在するので、資源予約例外の監視を可能にするために、既存のインターフェースがサーバ・オペレーティング・システムによって提供される。資源管理フィードバック・モジュール（７４０）は、これらの例外を受け取り、実行時補償ユニット（７３５）に転送し、実行時補償ユニット（７３５）は、サービス単位ヒューリスティックス・データベースで提供されるヒューリスティックスを使用して、結果の資源エンベロープに対する逸脱を計算する。具体的に言うと、資源管理フィードバック・モジュール（７４０）は、サービス単位に対する個々の資源モニタの関連付けを維持し、実行時中にサービス単位に関する資源エンベロープの補償のトリガをかける、ソフトウェア・ハンドラである。サービス単位が割り振られた後に、個々の資源モニタが、始動され、共通のサービス単位に関連付けられる。割振り例外または予測された使用過多または使用過小の状態（サービス単位の資源エンベロープによって予測されたものに対する）の場合に、例外が、これらの個々の資源モニタのうちの１つまたは複数によって発火される可能性がある。たとえば、帯域幅が低いと予測される場合に、ネットワーク入出力モニタ（図示せず）は、そのような状態を資源管理フィードバック・モジュールに知らせ、資源管理フィードバック・モジュールは、追加の帯域幅を割り当てる必要があるかどうかを判定する。そのような判断を行うために、資源管理フィードバック・モジュール（７４０）は、ヒューリスティックスまたは方針に頼ることができる。サービス単位ヒューリスティックス・データベース（７２５）には、ファースト・クラス・オブジェクトとしてサービス単位を操作する方法に関する規則が含まれる。たとえば、このデータベースは、いくつかのサービス単位について、そのうちの２つを同時に割り振ることが、２倍の資源を割り振ることを実際に意味するが、他のサービス単位については、たとえば１．４倍の資源のワースト・ケース境界を意味することを知っているか、学習する。このデータベースには、さらに、資源調節に対する限界、資源調節の周期性、資源調節の相対優先順位など、適応資源管理の熟練者に既知のデータが含まれる。
【００５２】
補償が必要とみなされる場合には、１つまたは複数の資源に適用される可能性がある信号が、実行時資源補償ユニット（７３５）に送られる。具体的に言うと、実行時資源補償ユニットは、フィードバック・モジュールからの刺激とヒューリスティックス・データベースからの知識に対して動作する。実行時補償ユニットは、調節または補償を実施し、調節の順序を決定する。実行時補償ユニットは、デッドロックを防止し、オーバーフロー・プール（７３３）を管理し、オーバーフロー・プール（７３３）は、実行時補償をサポートするために補償ユニットとインターフェースする。逸脱が補償を必要とする場合には、補償推奨が、ＳＵＭＭに転送され、ＳＵＭＭは、まず、サービス単位マッパ（７３０）への資源エンベロープ更新の要求を行い、その後、将来の同様の問題を防ぐために、対応するエンベロープをサービス単位データベース内で更新する必要があるかどうかを判定する。技量を有する熟練者は、負荷の異常が異常な資源割振りを必要とする可能性があり、これが平均供給要求の要件を大幅に超える可能性があるので、サービス単位データベースの更新が必ずしも有利でないことを諒解するであろう。
【００５３】
図９は、供給要求（８００）を処理するための処理を詳細に示す流れ図である。図９からわかるように、シグナリング・アダプタは、供給要求を受け取り、そのような要求のすべてをＳＵＭＭに転送し、ＳＵＭＭは、資源エンベロープを取り出し、更新するために、サービス単位データベースにインターフェースする（８０５）。ステップ（８１０）で、特定の要求されたサービスのサービス単位シグニチャが、特定のサーバの資源と比較される。具体的に言うと、要求がメタ資源に到着した時に、その要求をサービスできるかどうか、すなわち、メタ資源が、能力を有し、資源を有し、必要なケイパビリティを有する意志を持ち、必要なケイパビリティを有するかどうかを判定する必要がある。これらの判断のすべてが、サービス単位によって抽象化される。したがって、ステップ（８１５）で、メタ資源内のサービス単位が存在し、サーバがそのような単位を供給する能力を有する、すなわち、必要な資源が存在するかどうかに関する判定を行う。サービス単位の存在が、サーバが要求を進んで受け入れるかどうかを判定する能力をもたらす。サービス単位が存在しない場合には、要求は失敗し、この処理は、要求を満たさずに終了する。サービス単位が存在する場合には、ステップ（８２０）で、メタ資源が要求を進んで受け入れるかどうか、すなわち、たとえば価格、現在のサービス単位の利用度及びアクセス制御などの判断条件を検討した時に、サーバがメディア・サービスを進んで提供するかどうかに関する判定を行う。具体的に言うと、要求がメタ資源に到着した後に、メタ資源は、その要求をサービスルか否かを決定しなければならない。そのような判断は、資源内のメタデータによってサポートされる。たとえば、メタ資源（すなわちサーバ）は、要求が、要求されたサービス・ビンまたは記憶ビンを使用するための正しいアクセス制御（許可）に関連するかどうかを判定する。他の判断基準は、価格またはコストの許容性である。たとえば、要求は、たとえば４．００ドルまでのコストを上限とすることができ、メタ資源は、３．００ドルでサービスを進んで提供する。要求が許容されない場合には、ステップ（８２５）で処理が終了し、そうでない場合には継続される。ステップ（８３５）で、資源エンベロープ調整が行われ、ステップ（８４０）で、調整されたサービス単位が割り振られる。たとえば、サービス要求は、めいめいの資源のサービス単位（Ｘ、Ｙ、Ｚ）資源単位を要求することができ、現在サービスされている。第２の要求が、（Ｘ、Ｙ、Ｚ）を要求する。調整ステップ（８３５）では、ヒューリスティックス・データベース・テーブル索引が実行され、サーバ（メタ資源）のクラスに対して、結果の資源割振りの形（ｆ（Ｘ）、ｇ（Ｙ）、ｈ（Ｚ））に関する判定が行われる。資源が決定された後に、余分の資源をオーバーフロー・プールに転送することができる（たとえば、この要求の供給に関連する持続時間の間）。これも、ステップ（８４０）中に達成される。その後、ステップ（８５０）で、資源モニタが、供給するメタ資源（サーバ）のオペレーティング・システムによって呼び出されて、ステップ（８５５）に示されるようにクライアントに供給される、要求されたサービスの供給に実際に使用される資源が監視される。サービスの供給の後に、この処理は、ステップ（８６０）で終了し、ステップ（８６５）で、次の要求を処理するためにリターンする。通常、ＳＵＭＭ（図８）は、すべての比較と判定を、特定の要求に関連する対応する資源エンベロープに基づいて行い、その後、サービス単位の調整と割振りを要求する。しかし、特定のサービス単位に関連するさまざまな資源の間の調整は、サービス単位マッパ（７３０）によって実現される。調整された資源管理モジュールであるサービス単位マッパは、メタ資源上で見つかるオペレーティング・システムが提供する資源管理インターフェース（７５０）とインターフェースする。
【００５４】
図１０は、図９のステップ（８５０）で呼び出されるリアルタイム資源モニタ・プロセスを詳細に示す流れ図である。通常、この機能性は、ほとんどのコンピュータ・オペレーティング・システムの標準機能である。たとえば、監視できる資源には、仮想メモリ及びページ・ヒット、ストリーム入出力及びバッファ管理、ＣＰＵ及びＣＰＵ負荷スケジューリング及び優先順位処理など（図８参照）が含まれる。図１０からわかるように、ステップ（８７５）で、たとえばストリームに必要な入出力バッファ数（たとえば１ＭＢ）及び帯域幅など、要件逸脱が推定される。
【００５５】
録画されたビデオ及び生ビデオの最適平滑化などの技法を用いると、これらの値を信頼性のある形で推定でき、アンダーフローまたはオーバーフローの状態を判定できるようになる。資源モニタである資源管理インターフェース（７５０）が最初のトリガの際に反応しない場合があるので、監視される入力データは、従来のオペレーティング・システムの性質に起因して平滑化される可能性がある。たとえば、指数平滑化プログラムを使用することができる。さらに、傾向査定も実行することができる。特定の資源のそれぞれに関連するクリティカルな閾値（ヒューリスティックス・データベースに格納されるはずである）を使用して、逸脱が統計的に有意であり、したがって、例外の生成をもたらすかどうかを判定することができる（ステップ８８０）。たとえば、０．０００１の逸脱の訂正は、有意な逸脱ではない。その後、ステップ（８８０）で、例外が検出されたかどうかを判定する。例外が検出されなかった場合には、この処理はステップ（８９０）でリターンする。例外が検出された場合には、本明細書に記載の形で、ステップ（８８５）に示されているように、資源割振りが補償される。そうでない場合には、この処理はステップ（８９０）でリターンする。
【図面の簡単な説明】
【図１】インターネット・メディア・ユーティリティ環境を示す図である。
【図２】サービス・シグニチャ及び資源エンベロープを含むサービス単位構造を示す図である。
【図３】サービス単位の資源エンベロープ部分生成の概念を示す図である。
【図４】サービス単位の資源エンベロープ部分生成の概念を示す図である。
【図５】本発明によるメタ資源内のサービス単位、サービス・ビン、記憶ビン、グローバル・プール、ローカル・プール、資源エンベロープ及びサービス・シグニチャの間の関係を示す図である。
【図６】本発明による、メタ資源上の個々の資源の割振りと、サービス・ビン及び記憶ビンに対する関係を示す図である。
【図７】本発明で規定される、メタ資源内の、サービス・ビン及び記憶ビンの使用と、グローバル・ビン及びローカル・ビンの使用を、例を介して示す図である。
【図８】本発明で規定される、メタ資源でのサービス単位資源管理モジュールの構成要素アーキテクチャを示す図である。
【図９】サービス単位資源管理モジュールによるサービス要求を処理するための方法を示す流れ図である。
【図１０】サービス単位資源管理モジュールによるサービス要求を処理するための方法を示す流れ図である。
【符号の説明】
１５０  サービス単位
１５１  資源エンベロープ
１５２  サービス・シグニチャ
１６１  ＣＰＵ資源
１６２  メモリ
１６３  ディスク入出力
１６４  ネットワーク帯域幅
１６６  サービス管理メタデータ
１６７  アクセス権
１６９  コスト
１７６  資源管理メタデータ
１７８  実行時補償戦略
【図１】
0003566626.tif 000002
【図２】
0003566626.tif 000003
【図３】
0003566626.tif 000004
【図４】
0003566626.tif 000005
【図５】
0003566626.tif 000006
【図６】
0003566626.tif 000007
【図７】
0003566626.tif 000008
【図８】
0003566626.tif 000009
【図９】
0003566626.tif 000010
【図１０】
0003566626.tif 000011