JP4965460B2 - グリッド・ジョブに関するグリッド・プロバイダの選択を自動的に制御するための方法 - Google Patents

Description

本発明は、一般に、改良されたグリッド・コンピューティングに関し、特に、グリッド環境内の仮想ジョブ要求に関する自動入札（automated bidding）に関する。さらに詳細には、本発明は、グリッド・ジョブ（grid job）に関する入札要求（bidrequest）の作成、複数のグリッド・プロバイダ（grid provider）への入札要求の自動配布、およびグリッド・ジョブに関する勝利入札応答（winningbid response）を選択するためのグリッド・クライアント（grid client）による入札応答の分析に関する。

２つのコンピュータ・システム間で最初の接続が行われて以来、常に、接続を介して２つのコンピュータ・システム間でデータ、リソース、およびその他の情報を転送する新しい方法が発展し続けている。典型的なネットワーク・アーキテクチャでは、２つのコンピュータ・システムが接続を介してデータを交換しているときに、コンピュータ・システムの一方は、要求を送信するクライアントと見なされ、もう一方は、要求を処理し、結果を返すサーバと見なされる。要求が処理される速度を上げようとして、サーバ・システムは、サイズおよび速度の点で拡大し続けている。さらに、毎秒、複数の要求が到着するピーク時を処理しようとして、サーバ・システムはグループとしてまとめて結合される場合が多く、要求はグループ化されたサーバ間に配布される。クラスタ化、マルチシステム共用データ（シスプレックス）環境、およびエンタープライズ・システムなど、サーバをグループ化する複数の方法が発展してきた。サーバのクラスタの場合、１つのサーバは典型的には、着信要求および発信応答の配布を管理するよう指定される。他のサーバは典型的には、クライアントからの配布要求を処理するために並列に動作する。したがって、クラスタ内の複数のサーバのうちの１つは、サーバのクラスタがその要求を処理していることをクライアントが検出せずに、クライアント要求を処理することができる。

典型的には、複数のサーバまたはサーバ・グループは、Ｕｎｉｘ（登録商標）またはＵｎｉｘ（登録商標）の何らかの変形などの特定のネットワーク・プラットフォーム上で動作し、アプリケーションを実行するためのホスティング環境を提供する。各ネットワーク・プラットフォームは、データベース統合から、クラスタ化サービス、セキュリティ対作業負荷の管理、問題判別にわたる諸機能を提供することができる。各ネットワーク・プラットフォームは典型的には、種々の実現例、意味論的動作、およびアプリケーション・プログラミング・インターフェース（ＡＰＩ：application programming interface）を提供する。

しかし、処理能力を拡大するために単にサーバをまとめてグループ化することは、ネットワーク内の応答時間の効率を改善するための限られた方法である。したがって、次第に、社内ネットワーク内では、単にサーバをグループ化するのではなく、複数のサーバおよびサーバ・システム・グループが分散リソースとして編成されている。社内ネットワーク内および社内ネットワーク外のサーバ間で共同作業し、データを共用し、サイクルを共用し、その他の対話モードを改善するための努力が増大している。さらに、社内ネットワークからサービス・プロバイダ・ネットワークに重要ではない要素を外部委託するための努力が増大している。その上、同じ管理システムの対象にならないリソース間のリソース共用を調整するが、依然としてセキュリティ、ポリシー、支払、およびメンバシップの問題に対処しようとする動きが存在する。たとえば、個人のデスクトップ上のリソースは典型的には、社内サーバ・クラスタのリソースと同じ管理システムの対象にはならない。社内ネットワーク内でも、異なる管理グループが別個の管理システムを実現することができる。

異なるネットワーク・プラットフォーム上で動作し、異なる領域内に位置し、異なるセキュリティ・プロトコルを備え、それぞれが異なる管理システムによって制御される、サーバおよびその他のコンピューティング・システムからの使用可能リソースを非集中化することに関する問題によって、グリッド環境を操作するための公開規格を使用するグリッド技術の開発が行われてきた。グリッド環境は、動的で分散された仮想組織内の多様なリソースの共用および協調利用をサポートする。異なるポリシーおよび管理システムを備えた異なる組織によって操作される地理的に分散されたシステムからのある選択範囲のリソースがジョブ要求を処理するように編成されると、グリッド環境内に仮想組織が作成される。

グリッド環境の重要な適用例の１つは、エンタープライズ・コンピューティング環境を実現する複数の企業が外部グリッド・コンピューティング「ファーム（farm）」にアクセスできることである。グリッド・コンピューティング・ファームにジョブを送信することは、ジョブ実行を外部委託するための方法の１つである。グリッド・コンピューティング・ファームは、複数の顧客から受信したグリッド・ジョブを実行するためにアクセス可能なグリッド・リソースのグループを含むことができる。

現行のグリッド・コンピューティング・ファームの限界は、複数のグリッド・コンピューティング・ファームからの入札を達成するためのプロセスが時間がかかり、非効率的であることである。詳細には、グリッド・コンピューティング・ファームにジョブを送信する必要がある顧客は、典型的には、グリッド・ジョブを処理するために複数の使用可能なグリッド・ファーム・プロバイダの中から最も安価なグリッド・コンピューティング・ファームを希望することになる。しかし、複数の使用可能なグリッド・ファーム・プロバイダの中から最も競争力のある入札を決定するために、顧客は、それぞれのグリッド・コンピューティング・ファームの代表者と連絡を取り、必要なグリッド・リソースのタイプに関する説明を提供し、それぞれのグリッド・ファームの代表者から入札を受け取らなければならない。顧客がそれぞれのグリッド・コンピューティング・ファームの代表者と連絡を取り、入札プロセスを実行する必要があるということは、顧客ならびにグリッド・コンピューティング・ファーム・ベンダにとって非効率的なことである。

したがって、上記を考慮すると、グリッド・クライアントが単一の入札要求を作成し、複数のグリッド・ベンダに入札要求を自動的に配布し、勝利グリッド・ベンダを選択するために複数のグリッド・ベンダからの応答を分析するための方法、システム、およびプログラムを提供することは有利なことであろう。
米国特許出願第１１／０３４３０５号（２００５年１２月１日出願） 米国特許出願第１１／０３４３０３号（２００５年１２月１日出願） 米国特許出願第１１／０３１４８９号（２００５年１月６日出願）

上記を考慮すると、本発明は、一般に、自動グリッド・コンピューティングを可能にし、詳細には、グリッド環境内の仮想ジョブ要求に関する自動入札を可能にする。さらに詳細には、本発明は、グリッド・ジョブに関する入札要求の作成、複数のグリッド・プロバイダへの入札要求の自動配布、およびグリッド・ジョブに関する勝利入札応答を選択するためのグリッド・クライアントによる入札応答の分析に関する。

一実施形態によれば、グリッド・クライアントのユーザは、外部グリッド環境に提示する予定の特定のグリッド・ジョブに関する少なくとも１つの基準を入力する。グリッド・クライアントは、特定のグリッド・ジョブに関する基準を満たすように特定のグリッド・ジョブを処理するための可用性について照会すべき外部グリッド環境に関する少なくとも１つのグリッド・プロバイダを自動的に選択する。次に、グリッド・クライアントは、特定のグリッド・ジョブに関する入札要求内の基準を選択されたグリッド・プロバイダに自動的に配布する。グリッド・クライアントは、グリッド・プロバイダから受信した入札応答を保管し、入札要求に関する応答の返却のための期限に到達したことに応答して、グリッド・クライアントは受信応答の中から特定のグリッド・ジョブに関する勝利入札応答を選択する。次に、グリッド・クライアントは、グリッド・クライアント・システムからの特定のグリッド・ジョブを勝利入札応答を提示するグリッド・プロバイダに自動的に配布する。

照会すべきグリッド・プロバイダを選択する際に、グリッド・クライアントは、まず、特定のグリッド・ジョブが、グリッド提携契約（grid alliance agreement）に割り当てられたタイプのものであるかどうかを判断することができ、グリッド提携契約は、グリッド・クライアントが特定のタイプのグリッド・ジョブに関する単独プロバイダになることに同意する少なくとも１つのグリッド・プロバイダを指定する。特定のグリッド・ジョブに関するグリッド提携契約が所定の位置に存在する場合、グリッド・クライアントは、グリッド提携契約に指定されたグリッド・プロバイダのみを自動的に選択する。

入札要求を配布する際に、入札要求は、特定のグリッド・ジョブに関する基準およびＩＤと、グリッド・クライアント・システムに関するＩＤと、入札要求に応答を返すための期限とを含む。加えて、この基準は、パフォーマンス要件を含み、サービス・レベル契約と、ジョブ・コスト限界と、ジョブ時間制限と、キャパシティ・オンデマンド・リソース（capacity on demand resource）に関する資格と、ハードウェア・クラス・プラットフォーム要件と、ソフトウェア・クラス・プラットフォーム要件と、待ち時間要件と、データ・トランスポート要件と、データ・サイズと、完了要件と、セキュリティ要件と、リソース制限と、セルオフ・ポリシー（sell-offpolicy）も含むことができる。

加えて、入札要求を配布する際に、グリッド・クライアントは、まず、特定のグリッド・ジョブのサンプル縮図（sample microcosm）を作成することができ、このサンプル縮図は、特定のグリッド・ジョブの特定のパーセンテージを表している。次に、入札要求はサンプル縮図を含み、サンプル縮図を受信したグリッド・プロバイダは、特定のグリッド・ジョブを処理する際の見積もりパフォーマンスおよびコストを計算するためにサンプル縮図を処理する際の実際のパフォーマンスおよび実際のコストを計量するようにサンプル縮図を処理できるようになる。

勝利入札応答を選択する際に、グリッド・クライアントは、入札応答内の最低見積もりコストから特定のパーセンテージ以内の合計コストを含む第１の選択範囲の入札応答を決定することができ、次に、第１の選択範囲の入札応答の中から特定の応答を選択することができる。詳細には、グリッド・クライアントは、好ましいベンダが入札応答を返すかどうかを判断し、好ましいベンダの入札応答を勝利応答として選択することができる。さらに、グリッド・クライアントは、最高速ジョブ・ランタイムを見積もる入札応答を勝利応答として選択することができる。加えて、他の基準を使用して、グリッド・プロバイダによって返される複数の入札応答を分析し、その入札応答の中から勝利応答を選択することができる。

本発明の態様と思われる新規の特徴は特許請求の範囲に示されている。しかし、本発明そのもの、ならびにその好ましい使用態様、追加の目的および利点については、添付図面に併せて読んだときに、以下に示す例示的な一実施形態の詳細な説明を参照することにより、最も良く理解されるであろう。

次に図面、特に図１を参照すると、グリッド環境で実現可能であり、そこで本発明を実現可能であるコンピュータ・システムの一実施形態が描写されている。さらに説明するように、グリッド環境は、リソースを提供するように管理された複数のコンピュータ・システムを含む。加えて、さらに説明するように、本発明は、グリッド環境内で管理されるいくつかの異なるオペレーティング・システム下で動作する様々なコンピューティング・システム、モバイル・システム、および電子デバイスを含む、様々なコンピュータ・システム内で実行することができる。

一実施形態では、コンピュータ・システム１００は、コンピュータ・システム１００内で情報を伝達するためのバス１２２またはその他のデバイスと、情報を処理するためにバス１２２に結合されたプロセッサ１１２などの少なくとも１つの処理装置とを含む。バス１２２は、ブリッジおよびアダプタによって接続され、複数のバス・コントローラによってコンピュータ・システム１００内で制御される、短待ち時間のパスおよびより長い待ち時間のパスとを含むことができる。サーバ・システムとして実現される場合、コンピュータ・システム１００は、典型的には、ネットワーク・サービス能力を改善するように設計された複数のプロセッサを含む。

プロセッサ１１２は、通常動作中に、ランダム・アクセス・メモリ（ＲＡＭ：random access memory）１１４などの動的記憶装置および読み取り専用メモリ（ＲＯＭ：Read Only Memory）１１６などの静的記憶装置からアクセス可能なオペレーティング・システムおよびアプリケーション・ソフトウェアの制御下でデータを処理する、ＩＢＭのＰｏｗｅｒＰＣ（商標）プロセッサなどの汎用プロセッサにすることができる。オペレーティング・システムは、グラフィカル・ユーザ・インターフェース（ＧＵＩ：graphicaluser interface）をユーザに提供することができる。一実施形態では、アプリケーション・ソフトウェアは、プロセッサ１１２上で実行されたときに図１２、図１３、図１４の流れ図に描写された動作ならびに本明細書に記載されたその他の動作を実行する、機械で実行可能な命令を含む。代わって、本発明の諸ステップは、その諸ステップを実行するためのハードワイヤード・ロジックを含む特定のハードウェア・コンポーネントによって、またはプログラム式コンピュータ・コンポーネントとカスタム・ハードウェア・コンポーネントの任意の組み合わせによって実行することができる。

本発明は、本発明によるプロセスを実行するようコンピュータ・システム１００をプログラミングするために使用される機械で実行可能な命令がそこに保管されている機械可読媒体上に含まれるコンピュータ・プログラム製品として提供することができる。本明細書で使用する「機械可読媒体」という用語は、実行のためにコンピュータ・システム１００のプロセッサ１１２またはその他のコンポーネントに命令を提供することに関与する任意の媒体を含む。このような媒体は、不揮発性媒体、揮発性媒体、および伝送媒体を含むがこれらに限定されない多くの形をとることができる。不揮発性媒体の一般的な形としては、たとえば、フロッピー（登録商標）・ディスク、フレキシブル・ディスク、ハード・ディスク、磁気テープまたは任意のその他の磁気媒体、コンパクト・ディスクＲＯＭ（ＣＤ−ＲＯＭ）または任意のその他の光学媒体、パンチ・カードまたはせん孔パターンを有する任意のその他の物理媒体、プログラマブルＲＯＭ（ＰＲＯＭ）、消去可能ＰＲＯＭ（ＥＰＲＯＭ）、電気的ＥＰＲＯＭ（ＥＥＰＲＯＭ）、フラッシュ・メモリ、任意のその他のメモリ・チップまたはカートリッジ、あるいはそこからコンピュータ・システム１００が読み取ることができ、命令を保管するために適している任意のその他の媒体を含む。この実施形態では、不揮発性媒体の一例は、描写されている通り、コンピュータ・システム１００の内部コンポーネントである大容量記憶装置１１８であるが、外部装置によって提供されることも理解されるであろう。揮発性媒体としては、ＲＡＭ１１４などの動的メモリを含む。伝送媒体としては、バス１２２を含むワイヤを含む、同軸ケーブル、銅線、または光ファイバを含む。また、伝送媒体は、無線または赤外線データ通信中に生成されるものなどの音波または光波の形をとることもできる。

その上、本発明はコンピュータ・プログラム製品としてダウンロードすることができ、そのプログラム命令は、バス１２２に結合された通信インターフェース１３２へのネットワーク・リンク１３４（たとえば、モデムまたはネットワーク接続）を介して搬送波またはその他の伝搬媒体に実現されたデータ信号として仮想リソース１６０などのリモート仮想リソースから要求側コンピュータ・システム１００に転送することができる。仮想リソース１６０は単一のシステムまたは複数のシステムからアクセス可能なリソースの仮想表現を含むことができ、複数のシステムのそれぞれは、独立プラットフォーム上で動作するリソースの個別セットと見なすことができるが、グリッド・マネージャによって１つの仮想リソースとして調整することができる。通信インターフェース１３２は、たとえば、ネットワーク１０２へのアクセスを可能にするローカル・エリア・ネットワーク（ＬＡＮ：local area network）、広域ネットワーク（ＷＡＮ：wide area network）、またはインターネット・サービス・プロバイダ（ＩＳＰ：InternetService Provider）に接続可能なネットワーク・リンク１３４への両方向データ通信結合を提供する。詳細には、ネットワーク・リンク１３４は、ネットワーク１０２などの１つまたは複数のネットワークへの有線または無線あるいはその両方のネットワーク通信を提供することができ、それにより、仮想リソース１６０などの仮想リソースの使用はグリッド環境１５０によって提供されるものとしてアクセス可能である。グリッド環境１５０は、ピアツーピア・ネットワークを含む複数タイプのネットワークの一部である場合もあれば、コンピュータ・システム１００などの単一コンピュータ・システムの一部である場合もある。

一例として、ネットワーク１０２は、相互に通信するために伝送制御プロトコル（ＴＣＰ：Transmission Control Protocol）およびインターネット・プロトコル（ＩＰ：Internet Protocol）などの特定のプロトコルを使用するネットワークおよびゲートウェイの全世界的な集合を指すことができる。ネットワーク１０２は、デジタル・データ・ストリームを運搬する電気信号、電磁信号、または光学信号を使用する。様々なネットワークを通る信号ならびにネットワーク・リンク１３４上および通信インターフェース１３２を通る信号は、コンピュータ・システム１００との間でデジタル・データを運搬し、情報を転送する搬送波の模範的な形である。代替タイプのネットワーク、ネットワークの組み合わせ、ネットワークのインフラストラクチャを実現できることが理解されるであろう。

サーバ・システムとして実現される場合、コンピュータ・システム１００は、典型的には、入出力コントローラに接続された複数の周辺装置相互接続（ＰＣＩ：peripheral component interconnect）バス・ブリッジを介してアクセス可能な複数の通信インターフェースを含む。このように、コンピュータ・システム１００は、複数のネットワーク・コンピュータへの接続を可能にする。

さらに、描写されていないが、複数レベルのバス１２２のうちの１つに結合された複数のコントローラ、アダプタ、および拡張スロットに接続されたコンピュータ・システム１００に複数の周辺コンポーネントおよび内部／外部装置を追加することができる。たとえば、ディスプレイ装置、オーディオ装置、キーボード、またはカーソル制御装置を周辺コンポーネントとして追加することができる。

当業者であれば、図１に描写されているハードウェアが様々になる可能性のあることが分かるであろう。さらに、当業者であれば、描写されている例が本発明に関するアーキテクチャ上の制限を意味しないものであることが分かるであろう。

次に図２に関連して説明すると、このブロック図は、グリッド環境内の一般的なタイプのコンポーネントの一実施形態を例示している。この例では、グリッド環境１５０のコンポーネントとしては、サーバ・クラスタ２２２、サーバ２２４、ワークステーションおよびデスクトップ２２６、データ記憶システム２２８、ならびにネットワーク２３０とのインターフェースを取るグリッド管理システム２４０とのインターフェースを取るクライアント・システム２００を含む。例示のため、グリッド環境１５０内のコンポーネントを接続するネットワークの位置およびタイプは描写されていない。しかし、グリッド環境１５０内のコンポーネントは、相互に重なっている複数タイプのネットワークによって実現可能なネットワーク・インフラストラクチャ・アーキテクチャの上に存在できることが理解されるであろう。ネットワーク・インフラストラクチャは、複数の大規模エンタープライズ・システムからピアツーピア・システム、さらに単一のコンピュータ・システムまでわたる可能性がある。さらに、グリッド環境１５０内のコンポーネントは単にグリッド環境内のコンポーネントのタイプの表現に過ぎないことが理解されるであろう。グリッド環境は、単一のコンピュータ・システム内に単純に包含される場合もあれば、複数のエンタープライズ・システムを包含する場合もある。加えて、グリッド環境１５０はグリッド・プロバイダによって提供することができ、グリッド環境１５０内のリソースの使用コストは、複数の計算基礎の例のうち、グリッド・ジョブが実行に要する時間の量または実際に使用されるリソースの量に基づいて計算できることが理解されるであろう。

グリッド環境１５０などのグリッド環境の主要目標は、仮想リソース１６０と見なされる複数の個別システムからのリソースの編成および配信である。クライアント・システム２００、サーバ・クラスタ２２２、サーバ２２４、ワークステーションおよびデスクトップ２２６、データ記憶システム２２８、ネットワーク２３０、ならびにグリッド管理システム２４０を形成するシステムは、異機種にすることができ、独立管理システムによって地域的に分散させることができるが、グリッド管理システム２４０によって使用可能になるグリッド・インフラストラクチャにより情報、リソース、およびサービスを交換できるようにすることができる。さらに、サーバ・クラスタ２２２、サーバ２２４、ワークステーションおよびデスクトップ２２６、データ記憶システム２２８、ならびにネットワーク２３０は、国中および大陸中に地理的に分散させるか、またはローカルで相互にアクセス可能なものにすることができる。

この例では、クライアント・システム２００はグリッド管理システム２４０とのインターフェースを取る。クライアント・システム２００は、グリッド管理システム２４０に要求を送信する任意のコンピューティング・システムを表すことができる。詳細には、クライアント・システム２００は、グリッド管理システム２４０に仮想ジョブ要求およびジョブを送信することができる。詳細には、仮想ジョブ要求は、さらに説明するように、提案要求（ＲＦＰ：request for proposal）の形で送信することができる。さらに、この実施形態のクライアント・システム２００は要求によってグリッド環境１５０にアクセスするものとして描写されているが、代替諸実施形態のクライアント・システム２００はグリッド環境１５０内で動作することもできる。さらに、クライアント・システム２００がグリッド管理システム２４０に仮想ジョブ要求およびジョブを提示する場合、クライアント・システム２００はグリッド・クライアントと呼ぶこともできる。

仮想リソース１６０内のシステムは並列に描写されているが、実際には、これらのシステムは、仮想リソース１６０内のいくつかのシステムがクライアント・システム２００にとってローカルなものになり、他のシステムが外部ネットワークへのアクセスを必要とするような、システム階層の一部になる可能性がある。さらに、仮想リソース１６０内に描写されているシステムはクライアント・システム２００内に物理的に包含できることは、留意すべき重要なことである。

グリッド管理システム２４０の機能の１つは、クライアント・システム２００からの仮想ジョブ要求およびジョブを管理し、仮想リソース１６０内の使用可能なコンピューティング・システムで特定のリソースを使用するために、ある選択範囲の仮想リソース１６０のコンピューティング・システムに対する各ジョブの配布を制御することである。しかし、クライアント・システム２００の観点から見ると、仮想リソース１６０は、仮想リソース１６０内のどのコンピューティング・システムが実際に要求を実行したかを区別せずに、要求を処理し、結果を返す。

グリッド環境１５０を実現するために、グリッド管理システム２４０はグリッド・サービスを促進する。グリッド・サービスは、オープン・グリッド・サービス・アーキテクチャ（ＯＧＳＡ：Open Grid Services Architecture）を含むがこれに限定されない複数のアーキテクチャに応じて設計することができる。詳細には、グリッド管理システム２４０は、グリッド・サービスによりリソースを共用することを特徴とする異機種ネットワーク環境内にコンピューティング・システムをリンクすることによりグリッドを作成する管理環境を指す。

一例では、ジョブを処理するためのパラメータを指定するＲＦＰとともにグリッド管理システム２４０が仮想ジョブ要求を受信したときに、グリッド・サービスが呼び出される。このグリッド・サービスは、仮想ジョブ要求に必要な合計作業負荷を決定し、必要な合計作業負荷を処理するための仮想リソース１６０のキャパシティを計算する入札コントローラである。次に入札コントローラは、仮想ジョブ要求に関するコストを計算し、必要な合計作業負荷を処理するためのグリッド環境１５０のキャパシティおよびその作業負荷を使用するためのコストに基づいて、仮想ジョブ要求によって指定されたジョブを実行するための入札を返す。

次に図３を参照すると、このブロック図は、グリッド環境で実現可能であるアーキテクチャの一例を例示している。描写されている通り、アーキテクチャ３００は複数層の機能を含む。さらに説明するように、本発明は、図２に記載されているグリッド環境などのグリッド環境で実現されるアーキテクチャ３００などのアーキテクチャの１つまたは複数の層で実現可能なプロセスである。アーキテクチャ３００は、グリッド環境で実現可能であり、そこで本発明を実現可能であるアーキテクチャの一例にすぎないことは、留意すべき重要なことである。さらに、１つのグリッド環境内で複数のアーキテクチャを実現可能であることは、留意すべき重要なことである。

アーキテクチャ３００の層内で、まず、物理および論理リソース層３３０は、グリッド内のシステムのリソースを編成する。物理リソースは、サーバ、記憶媒体、およびネットワークを含むが、これらに限定されない。論理リソースは、物理層を仮想化し、オペレーティング・システム、処理能力、メモリ、入出力処理、ファイル・システム、データベース・マネージャ、ディレクトリ、メモリ・マネージャ、およびその他のリソースなどの使用可能リソースに物理層を集約する。

次に、Ｗｅｂサービス層３２０は、グリッド・サービス３１０と物理および論理リソース３３０との間のインターフェースを提供する。Ｗｅｂサービス層３２０は、Ｗｅｂサービス記述言語（ＷＳＤＬ：Web Services Description Language）、シンプル・オブジェクト・アクセス・プロトコル（ＳＯＡＰ：SimpleObject Access Protocol）、およびインターネット・プロトコル（ＩＰ）またはその他のネットワーク・トランスポート層の上で実行される拡張可能マークアップ言語（ＸＭＬ：eXtensiblemark-up language）を含むがこれらに限定されないサービス・インターフェースを実現する。さらに、オープン・グリッド・サービス・インフラストラクチャ（ＯＧＳＩ：OpenGrid Services Infrastructure）規格３２２は、グリッドのリソースをモデル化するために必要な動的かつ管理しやすいＷｅｂサービスに関する機能を提供するようにＷｅｂサービス３２０を拡張することにより、現行のＷｅｂサービス３２０の上に構築される。詳細には、Ｗｅｂサービス３２０によりＯＧＳＩ規格３２２を実現することにより、ＯＧＳＡを使用して設計されたグリッド・サービス３１０は相互運用可能なものになる。代替諸実施形態では、Ｗｅｂサービス層３２０の上に他のインフラストラクチャまたは追加のインフラストラクチャを実現することができる。

グリッド・サービス層３１０は、グリッド管理システム２４０に関連して説明した諸機能を一緒に実行する複数のサービスを含む。たとえば、グリッド・サービス層３１０は、グリッド・サービスを作成する際に一様な規格が実現されるように、ＯＧＳＡを使用して設計されたグリッド・サービスを含むことができる。代わって、複数のアーキテクチャ下でグリッド・サービスを設計することができる。グリッド・サービスは、４つの主要機能にグループ化することができる。しかし、グリッド・サービスによって他の機能を実行できることが理解されるであろう。

第１に、リソース管理サービス３０２は物理および論理リソースの使用を管理する。リソースとしては、処理リソース、メモリ・リソース、および記憶リソースを含むことができるが、これらに限定されない。これらのリソースの管理は、ジョブのスケジューリング、ジョブの配布、およびジョブに関する結果の検索の管理を含む。リソース管理サービス３０２は、リソース負荷のバランスを取り、予期せぬ活動ピークを吸収するために、リソース負荷をモニターし、グリッドのあまり混雑していない部分にジョブを配布する。詳細には、グリッド内で好ましいパフォーマンス・レベルを維持するためにリソース管理サービス３０２がジョブを配布するように、ユーザは好ましいパフォーマンス・レベルを指定することができる。

第２に、情報サービス３０４は、グリッド内のコンピューティング・システム間の情報転送および通信を管理する。複数の通信プロトコルを実現できるので、情報サービス３０４は、複数タイプの通信プロトコルを使用する複数のネットワーク全域の通信を管理する。

第３に、データ管理サービス３０６は、グリッド内のデータ転送および記憶を管理する。詳細には、データ管理サービス３０６は、データを必要とするジョブが実行されるグリッド内のノードにそのデータを移動することができる。グリッド・ファイル転送プロトコル（ＧｒｉｄＦＴＰ：Grid File Transfer Protocol）などの特定のタイプの転送プロトコルを実現することができる。

最後に、セキュリティ・サービス３０８は、グリッド内で動作するそれぞれのシステムの接続層のセキュリティに関するセキュリティ・プロトコルを適用する。セキュリティ・サービス３０８は、安全な伝送を提供するために、オープン・セキュア・ソケット層（ＳＳＬ：Secure Socket Layer）などのセキュリティ・プロトコルを実現することができる。さらに、ユーザが認証された後、そのユーザに関するグリッド内でアクションを実行するときにプロキシ証明書が作成され使用されるように、セキュリティ・サービス３０８はシングル・サインオン・メカニズムを提供することができる。

複数のサービスは、グリッド・コンピューティング・システムのいくつかの重要な機能を提供するように一緒に作用することができる。第１の例では、計算タスクがグリッド内に分散される。データ管理サービス３０６は、１つの計算タスクを、リソース管理サービス３０２によって分散され管理されるデータ・パケットからなる個別のグリッド・サービス要求に分割することができる。結果は、データ管理サービス３０６によって収集され統合される。第２の例では、グリッド内の複数のコンピューティング・システム全域の記憶リソースは、データ管理サービス３０６によって管理され、リソース管理サービス３０２によってモニターされる単一の仮想データ記憶システムと見なされる。

アプリケーション層３４０は、グリッド・サービス層３１０内で使用可能なグリッド・サービスのうちの１つまたは複数を使用するアプリケーションを含む。有利なことに、複数の異機種システムが対話し相互運用できるように、アプリケーションは、グリッド・サービス層３１０およびＷｅｂサービス３２０を介して物理および論理リソース３３０とのインターフェースを取る。

次に図４に関連して説明すると、本発明の方法、システム、およびプログラムにより、仮想ジョブ要求が受信され、入札の形で自動的に応答される、グリッド環境のブロック図が描写されている。描写されている通り、クライアント・システム２００はグリッド環境１５０に仮想ジョブ要求を送信する。グリッド環境１５０は、グリッド・スケジューラ４０４と、入札コントローラ４１２と、グリッド・リソース４０２とを論理的に含むことができる。グリッド・リソース４０２はグリッド環境１５０内の使用可能リソースを表し、グリッド・スケジューラ４０４はグリッド・リソース４０２へのジョブの配布を制御する。グリッド・リソース４０２、グリッド・スケジューラ４０４、および入札コントローラ４１２は、単一のネットワーク内に分散された複数のサーバ・システム間または複数のネットワーク間で実行できることが理解されるであろう。

入札コントローラ４１２は、仮想ジョブ要求の受信ならびに仮想ジョブ要求によって指定されたジョブの完了のための入札の生成を処理するものであり、グリッド環境１５０内のグリッド・サービスとして呼び出すことができる。代わって、仮想ジョブ要求は、グリッド環境１５０のトランスポート層またはその他のゲートキーピング機能から入札コントローラ４１２に渡すことができる。さらに、入札コントローラ４１２は、グリッド環境１５０の外部のシステム内で実行することができる。

図９に関連してさらに説明するように、一実施形態では、入札コントローラ４１２は作業負荷カルキュレータ・モジュール９０８を含む。作業負荷カルキュレータ・モジュール９０８は、各仮想ジョブ要求が必要とする見込みの作業負荷を決定し、必要な作業負荷を処理するためのグリッド環境１５０のキャパシティを計算する。必要な作業負荷を処理するためのグリッド環境１５０のキャパシティに基づいて、コスト・カルキュレータ９１４は、仮想ジョブ要求によって指定されたジョブを実行するためのコストを計算する。入札フォーマライザ（bid formalizer）９０６は、ジョブに必要なその他の要因を考慮し、クライアント・システム２００に入札応答を返す。加えて、入札フォーマライザ９０６は、クライアント・システム２００がグリッド環境１５０によって表されるグリッド・プロバイダに仮想ジョブ要求に関連する実際のジョブを提示した場合にグリッド・スケジューラ４０４によってアクセスするために、入札応答テーブル内に入札応答を保管する。

描写されている実施形態では、入札コントローラ４１２は仮想ジョブ要求の受信ならびにグリッド環境１５０内でジョブを処理するための入札の自動決定および返却を処理するものとして例示されているが、入札コントローラ４１２は複数のグリッド・クライアントからの仮想ジョブ要求の受信を処理することができ、複数のグリッド環境内でジョブを処理するために入札を返すことが理解されるであろう。

一実施形態では、グリッド環境１５０は、グリッド・ジョブを処理するために特定のグリッド・プロバイダにとって使用可能なリソースであるグリッド・リソース４０２を含む。加えて、グリッド・リソース４０２は、他のグリッド・プロバイダからアクセス可能であり、キャパシティ・オンデマンド（ＣＵＯＤ：capacity on demand）リソースであるリソースを含むことができる。

この説明全体を通して、グリッド・プロバイダはクライアント・システム２００から独立してグリッド環境内で独立グリッド処理を提供するエンティティを指すが、そのクライアント・システム２００がクライアント・システム２００を含むグリッド環境のグリッド・プロバイダにグリッド・ジョブを提示できることは、留意すべき重要なことである。加えて、グリッド・プロバイダはグリッド・ベンダとも呼ばれる場合がある。

次に図５を参照すると、クライアント・システムによってグリッド・プロバイダに提示されるジョブと、グリッド・プロバイダによって返されるジョブの結果のフロー・ダイアグラムが描写されている。例示されている通り、クライアント・システム２００はグリッド・プロバイダにジョブ５０２を提示する。詳細には、前に説明した通り、各グリッド・プロバイダは、ジョブがパフォーマンス要件を満たすためのグリッド・リソースを選択し、ジョブの進行状況をモニターし、パフォーマンス要件を満たすために必要である場合にグリッド・リソースを調整し、クライアント・システムへの結果の返却を管理することによりグリッド・ジョブの流れを管理するために、グリッド管理システム２４０などのグリッド管理システムを実現することができる。

この例では、グリッド・プロバイダ用のグリッド管理システムは、ジョブ５０２を受け取り、グリッド・スケジューラ４０４がジョブ５０２をスケジューリングして、それをグリッド・リソースにディスパッチできるまでジョブ５０２を保持する、ジョブ・キュー５０４を含む。詳細には、グリッド・スケジューラ４０４は、たとえば、特定のジョブについてグリッド・プロバイダによって行われた入札または特定のクライアント・システムから受信したジョブのためのジョブ・パフォーマンス要件に関する契約に基づいて、ジョブ５０２に関するパフォーマンス要件を含む入札５０８にアクセスする。グリッド・スケジューラ４０４は、ジョブ５０２を処理するために必要なグリッド・リソース、たとえば、サーバＡ ５１６、サーバＢ ５１８、およびサーバＮ ５２０にアクセスする。描写されていないが、グリッド・スケジューラ４０４は、グリッド・マネージャならびにグリッド・ジョブに必要なリソースを構築するグリッド管理システムのその他のコンポーネントにアクセスし、他のグリッド環境からのリソースにアクセスし、必要であれば、他のグリッド・プロバイダにグリッド・ジョブをセルオフすることができる。

この例では、グリッド・スケジューラ４０４は、サーバＡ ５１６、サーバＢ ５１８、およびサーバＮ ５２０にそれぞれ配布されるジョブ部分５１０、５１２、および５１４にジョブ５０２を分割する。ジョブ結果マネージャ（job results manager）５２８は、サーバＡ ５１６、サーバＢ ５１８、およびサーバＮ ５２０から結果５２２、５２４、および５２６をそれぞれ収集する。ジョブ結果マネージャ５２８は、完全な結果５３０をクライアント・システム２００に返す。加えて、ジョブ結果マネージャ５２８は、ジョブが完了したときにアカウンティング・マネージャ（accountingmanager）５３２を更新する。アカウンティング・マネージャ５３２は、ジョブ５０２によるサーバＡ ５１６、サーバＢ ５１８、およびサーバＮ ５２０の使用をモニターしてジョブ５０２の合計作業負荷とジョブ５０２の合計コストを計算する作業負荷マネージャ（描写されていない）と通信する。詳細には、入札５０８は、最大コスト、固定コスト、パフォーマンス要件が満たされない場合のスライド・コスト・スケール、ならびにその他の価格調整係数などのジョブ５０２の合計コストを制御する要因を指定することができる。

次に図６に関連して説明すると、クライアント定義アプリケーション・メトリックあたりの相対コストを計算するために複数のグリッド・プロバイダにグリッド・ジョブ縮図を提示するためのプロセスのフロー・ダイアグラムが描写されている。この例では、クライアント・システム２００は、グリッド・プロバイダに提示する必要のある大きいグリッド・ジョブのうちの小さい代表的なジョブである縮図にグリッド・ジョブを配分する。この例では、クライアント・システム２００は、グリッド・ジョブ縮図６０２およびグリッド・ジョブ縮図６１２をグリッド・プロバイダ６０４および６１４にそれぞれ提示する。図４に関連して説明した通り、一実施形態のクライアント・システム２００はすでにグリッド・ジョブ縮図に関するジョブ要求をグリッド・プロバイダ６０４および６１４に提示しているが、代替一実施形態のクライアント・システム２００は、たとえば、公開されたレートまたは口頭で合意したレートに基づく価格設定およびパフォーマンス予想とともに、グリッド・ジョブ縮図をグリッド・プロバイダ６０４および６１４に提示することができる。

グリッド・プロバイダ６０４および６１４のそれぞれは、図５でグリッド・ジョブを処理するグリッド・プロバイダに関連して説明したのと同じように、グリッド・ジョブ縮図６０２および６１２を処理し、結果６０６および６１６を返す。クライアント・システム２００は、グリッド・ジョブ縮図６０２および６１２のそれぞれに関する結果およびコストを検索し、クライアント定義アプリケーション・メトリックとグリッド・プロバイダ・メトリックとの比率に基づいて各グリッド・プロバイダに関する変換値を計算する。たとえば、グリッド・プロバイダ・メトリックは時間制料金であるが、クライアント定義アプリケーション・メトリックはデータベース・マージの数である場合が考えられる。変換値の計算に関する追加の例については、米国特許出願第１１／０３４３０５号に記載されている。

次に、クライアント・システム２００は、変換値によって調整された完全グリッド・ジョブに必要なクライアント定義アプリケーション・メトリック動作の数に応じて完全グリッド・ジョブに関する見積もりコストを計算し、各グリッド・プロバイダについて見積もられたコスト同士を比較し、費用効果が最も高いプロバイダを選択する。１つの利点によれば、各プロバイダに関する実際のパフォーマンスおよびコストをサンプリングし、そのコストをクライアント定義アプリケーション・メトリック・ベースに変換することにより、クライアント・システム２００は、１つの大きいグリッド・ジョブまたは複数の大きいグリッド・ジョブを送信する前に、クライアント定義アプリケーション・メトリック・ベースで、約束されたコスト・パフォーマンスではなく、実際のコスト・パフォーマンスを比較することができる。この例では、グリッド・ジョブ縮図６０２および６１２のそれぞれについて結果およびコストをサンプリングした後、クライアント・システム２００は、グリッド・ジョブ縮図６０２および６１２がその代表的なセットである完全グリッド・ジョブ６２０をグリッド・プロバイダ６０４に送信することを選択する。グリッド・プロバイダ６０４は、図５に関連して説明した通り、完全グリッド・ジョブ６２０を処理し、結果６２４をクライアント・システム２００に返す。

次に図７を参照すると、このブロック図は、グリッド・プロバイダへの自動入札要求および複数のグリッド・プロバイダからの入札応答の自動分析を制御するためのクライアント・システムに関するグリッド・クライアント・エージェントのコンポーネントを描写している。例示されている通り、クライアント・システム２００で実行されているかまたは複数のグリッド・クライアント・システムとのインターフェースを取るサーバで実行されているグリッド・クライアント・エージェント７００は、ＲＦＰの形のグリッド・ジョブに関する仮想ジョブ要求の形成と、グリッド・プロバイダへのＲＦＰの配布と、グリッド・プロバイダからＲＦＰへの入札応答の分析と、勝利グリッド・プロバイダへのグリッド・ジョブの配布とを管理する。

詳細には、グリッド・クライアント・エージェント７００は、ユーザが特定のグリッド・ジョブのためのＲＦＰに関する指定を入力するためのインターフェースを制御するＲＦＰ指定コントローラ７０８を含む。一実施形態のＲＦＰ指定コントローラ７０８は独立コントローラである。他の実施形態のＲＦＰ指定コントローラ７０８は、グリッド・クライアントのための既存のスケジューラに追加される。図８に関連して説明するように、ユーザは、１つのグリッド・ジョブについて複数のカテゴリの基準を入力することができる。ＲＦＰ指定コントローラ７０８は、グリッド・インターフェース・コントローラ７１２によりディスパッチするためにスケジューリングされたＲＦＰをＲＦＰ要求キュー７１８に保管する。

グリッド・インターフェース・コントローラ７１２は、ＲＦＰの配布と、入札応答の受信と、グリッド・ジョブの配布と、グリッド・ジョブ結果の受信とを管理する。詳細には、グリッド・インターフェース・コントローラ７１２によりグリッド・プロバイダに提示されたＲＦＰはＲＦＰ提示テーブル７１６に保管される。次に、グリッド・インターフェース・コントローラ７１２は、ＲＦＰ応答テーブル７１４内の入札応答の保管を管理する。

詳細には、グリッド・クライアント・エージェント７００は、ＲＦＰ要求キュー７１８内のＲＦＰをグリッド・プロバイダに提示すべき時期を決定し、特定のＲＦＰがグリッド・インターフェース・コントローラ７１２によって提示されるはずのグリッド・プロバイダを選択する、ＲＦＰ提示コントローラ７２２を含む。一実施形態のＲＦＰ提示コントローラ７２２は、特にＲＦＰがグリッド提携ベンダを指定するときに、特定のグリッド提携の一部として指定されたグリッド・ベンダを選択することができる。詳細には、ベンダ・レーティング７２０は、グリッド・プロバイダを選択するためのレーティング基準を指定し、グリッド提携契約に含まれるグリッド・ジョブのタイプを指定する。

詳細には、一例では、１つのグリッド・クライアントまたはグリッド・クライアント・グループは、グリッド提携の一部として１つまたは複数のグリッド・プロバイダに特定の特性セットを有するグリッド・ジョブを提示することに同意することができ、その場合、グリッド・クライアントは、特定のグリッド・プロバイダまたはグリッド・プロバイダ・グループがその特定の特性セットを有するグリッド・ジョブに関する単独プロバイダになることに同意するための割引価格を受信し、ベンダ・レーティング７２０はグリッド提携および特定の特性セットを示す。他の例では、ユーザがベンダ・レーティング７２０内の各グリッド・ベンダに対してレーティングを割り当てる場合もあれば、グリッド・クライアント・エージェント７００がベンダ・レーティング・サービスからのグリッド・ベンダ・レーティングにアクセスする場合もある。

加えて、グリッド・クライアント・エージェント７００は、図６に関連して説明した通り、１つのグリッド・ジョブの小さい部分を処理するための応答時間およびコストをサンプリングするために、ＲＦＰ提示コントローラ７２２がグリッド・プロバイダに提示するためのグリッド・ジョブ縮図の形成を制御するためのジョブ縮図コントローラ７０２を含む。一例では、ＲＦＰは、グリッド・プロバイダが実行し、入札と、グリッド・ジョブ縮図を実行した結果とを返すためのグリッド・ジョブ縮図を含むことができる。他の例では、ジョブ縮図コントローラ７０２は、まずグリッド・ジョブ縮図に関するＲＦＰの提示を要求し、次に複数のグリッド・プロバイダへのグリッド・ジョブ縮図の提示を要求する。

コスト比較器７１０は、グリッド・ジョブ縮図および完全グリッド・ジョブからの結果に基づいて、グリッド・ジョブについてクライアント実行ユニット・ベースで実際のコストを決定する。詳細には、図６に関連して説明した通り、クライアント定義メトリックとグリッド・プロバイダ・メトリックとの比率は、グリッド・ジョブ縮図または完全グリッド・ジョブを実行した結果に基づいて、特定のタイプのグリッド・ジョブについて計算される。一例では、あるグリッド・プロバイダが時間制料金に基づいてグリッド・ジョブのコストを計算し、他のグリッド・プロバイダが浮動小数点演算の数に基づいてグリッド・ジョブのコストを計算する場合に、コスト比較器７１０は、それぞれのグリッド・プロバイダ・メトリックと、データベース・マージの数など、共通クライアント定義メトリック・ベースとの比率を計算する。

応答アナライザ７０４は、グリッド・プロバイダから受信した応答を分析し、処理グリッド・プロバイダを選択する。一実施形態では、応答アナライザ７０４は、入札応答がすべてのまたは特定のＲＦＰ基準を満たしているかどうかについて入札応答を分析し、最良価格に必要な基準またはその他の基準を満たしている応答同士を比較する。他の実施形態では、同じタイプの前のグリッド・ジョブがすでにグリッド・プロバイダによって処理されている場合またはグリッド・ジョブ縮図が提示された場合に、応答アナライザ７０４は、応答アナライザ７０４がグリッド・ジョブを実行するための実際の見積もりコストとグリッド・プロバイダによって約束されたコストとを比較して勝利グリッド・プロバイダを選択できるように、まずグリッド・プロバイダに応じてクライアント定義メトリック・コストを計算するために、コスト比較器７１０を呼び出す。

加えて、応答アナライザ７０４は、グリッド・ジョブに関する再交渉基準を提案する例外またはコメントを資格付与入札応答が含む場合に、ＲＦＰ例外マネージャ７０６を起動することができる。詳細には、ＲＦＰ例外マネージャ７０６は、入札応答で返された例外およびコメントに応じてＲＦＰを調整することを選択するようユーザにプロンプトで指示することができる。さらに、ＲＦＰ例外マネージャ７０６は、グリッド・クライアントのための再交渉設定によって許可される場合に、例外またはコメントによりＲＦＰを自動的に調整することができる。

再交渉プロセス中に、ＲＦＰ例外マネージャ７０６は、ＲＦＰを調整するために使用された例外またはコメントを返した単一のグリッド・プロバイダに調整済みＲＦＰを提示する場合もあれば、元のグリッド・プロバイダのすべてに調整済みＲＦＰを提示する場合もある。加えて、再交渉プロセス中に、ＲＦＰ例外マネージャ７０６は、効果的な再交渉のために十分な時間を使用可能にするために元のＲＦＰ応答時間を延長する場合もある。

次に図８を参照すると、このブロック図は、グリッド・ジョブに関するＲＦＰ基準の入力のためのユーザ・インターフェースを描写している。例示のため、各タイプの基準について提供可能な情報のタイプが示されている。追加のタイプの基準をＲＦＰに含めることができ、それぞれの基準について追加の値を指定でき、各グリッド・プロバイダのモジュールが種々の方法で基準に対応できることが理解されるであろう。

例示されている通り、ユーザ・インターフェース８００は、ＲＦＰ８５０を作成するための仮想ジョブ要求に関する要件をユーザが入力するための複数の入力フィールドを提供する。描写されている例では、ユーザ・インターフェース８００は、グリッド・プロバイダにグリッド・ジョブを提示するためにユーザ要求に応答してＲＦＰ指定コントローラ７０８によって開かれたウィンドウである。他の例では、クライアント・ジョブ・スケジューラは、グリッド提示に向いているジョブが検出されたときに、ユーザ・インターフェース８００内のウィンドウを開くためにＲＦＰ指定コントローラ７０８を自動的に起動することができる。カーソル８４６の配置および選択により選択可能ボタン８４４をユーザが選択したときに、ユーザ・インターフェース８００内の入力は、ＲＦＰ要求キュー７１８内のグリッド・ジョブについて保管され維持される。

参照番号８０２に例示されている通り、ＲＦＰ８５０についてジョブ名を指定することができる。この例のジョブ名は、データベース更新を必要とするジョブを識別するための「ＤＢ＿ＵＰＤＡＴＥ＿ＢＡＳＥ」である。ジョブ名に加えてまたはジョブ名の代替物として、参照番号８０４に示されているジョブ番号またはその他の識別番号は、ユーザがＲＦＰを入力することにより指定するか、またはＲＦＰ指定コントローラ７０８により自動的に指定することができる。参照番号８０４に例示されている通り、グリッド・クライアントは、ＲＦＰ交渉プロセス中に特定のグリッド・ジョブへの共通参照を容易にするために、各グリッド・ジョブに固有の番号を関連付けることができる。この例では、「１０５」というジョブ番号がＲＦＰ８５０に関連付けられている。加えて、グリッド・プロバイダは、ＲＦＰおよび応答のジョブ番号を、グリッド・プロバイダがグリッド・クライアントから受信したグリッド・ジョブと突き合わせる。

参照番号８１０に例示されている通り、ＲＦＰ８５０についてキャパシティ・オンデマンド（ＣＵＯＤ）リソースを使用するための資格を指定することができる。この例では、ＣＵＯＤ資格は「ＮＯ」に設定されている。一実施形態のＣＵＯＤリソースは、使用可能であるが、現在、アクティブではないリソースである。ハードウェア・リソースとソフトウェア・リソースのいずれもキャパシティ・オンデマンド・リソースとして使用可能なものにすることができる。ライセンス・コストを支払って、「オンデマンド」リソースを起動することができる。そのグリッド・ジョブがＣＵＯＤリソースの資格がないとクライアントが指定した場合、グリッド・ベンダは、ＲＦＰへの応答を作成するときに、いずれの使用可能ＣＵＯＤ応答を含めることも回避することになる。あるグリッド・ジョブがＣＵＯＤリソースの資格があるとクライアントが指定した場合、各グリッド・ベンダは、追加のオンデマンド・リソースがそのグリッド・ジョブに必要と見なされる場合にその追加のオンデマンド・リソースとそのコストとを含む入札応答を作成することができる。さらに、入札応答でグリッド・ベンダは、これらのリソースの起動のためのコストを指定できるように、そのジョブがＣＵＯＤリソースを必要とするかどうかを指定することができる。最後に、他の例では、グリッド・クライアントが入札応答を分析するときに、グリッド・クライアントは、ＣＵＯＤリソースを提供しないグリッド・プロバイダからの応答をフィルタで除去することができる。

参照番号８２８に例示されている通り、グリッド・ジョブに関するジョブ時間制限をＲＦＰ８５０に指定することができる。詳細には、ユーザは、それまでにジョブを実行しなければならない時間制限を指定することができる。作業負荷計算モジュールがリソースとそのリソースのコストを決定する場合、時間制限を考慮することができる。たとえば、特定のジョブを１時間で実行するためのジョブ要求は、同じジョブを５時間で実行するためのジョブ要求よりコストがかかる可能性がある。

ジョブ時間制限のもう１つのパラメータは、典型的には基本コンピューティング環境で実行されるジョブについて、グリッドにジョブを提示しなければならない時間の量を含むことができる。詳細には、ほとんどのジョブは、基本環境で実行され、基本環境が混雑しているときに実行を中断し、再始動時に、中断したところからジョブを再開することができる。本発明の１つの利点によれば、その基本環境でジョブを中断し、グリッド環境に移動して再開し、あとで中断して基本環境に戻すことができる。したがって、ジョブ時間制限は、そのジョブが中断され、実行のために基本環境に戻される前に、そのジョブがグリッド環境で実行されなければならない時間の量を指定することができる。

参照番号８２２に例示されている通り、グリッド・ジョブについて許可されたリソースに関するリソース制限をＲＦＰ８５０に指定することができる。ジョブが要する時間単位でクライアントに請求するグリッド・プロバイダもあれば、ジョブが使用したリソース単位でクライアントに請求するグリッド・プロバイダもある。リソース使用量単位での請求を実現する場合、クライアントは好ましくは、提示のために考慮された各ジョブについてクライアントが支払を了解したリソースのタイプおよび量を指定することができる。

参照番号８１２および８１８に例示されている通り、実行要求期間および追加の完了基準をＲＦＰ８５０に指定することができる。この例では、６時間以内でのグリッド・ジョブの実行が要求され、いかなる追加の完了基準も指定されていない。しかし、追加の完了基準の例としては、ジョブが８時間以内に実行を完了しなければならないこと、８時間の実行時間後にジョブを中断しなければならないこと、１００００個の出力レコードが生成されたときにジョブが完了すること、または２回実行され、それぞれの実行から一致する結果が返された場合にジョブが完了することを含むことができる。

参照番号８２６に例示されている通り、グリッド・ジョブに関するグリッド提携要件をＲＦＰ８５０に指定することができる。詳細には、グリッド・クライアントは１つまたは複数のグリッド・プロバイダと戦略的提携を行うことができ、その場合、戦略的提携では、クライアントは特定の基準を満たすグリッド・ジョブについて提携しているグリッド・プロバイダのうちの１つを使用するだけである。グリッド・クライアントは、任意の必要なグリッド提携をＲＦＰに指定することができる。代わって、このジョブが、クライアントが同意した提携に関する基準を満たすものである場合、ＲＦＰ指定コントローラ７０８はグリッド提携要件をＲＦＰ８５０に自動的に記入することができ、クライアントはグリッド提携プロバイダにＲＦＰを提示することに限定される可能性がある。

グリッド提携の一例では、グリッド・プロバイダＡおよびＢはクライアントのための単独ソースになることに同意することができ、その場合、１０個またはそれ以上のジョブをグリッド・プロバイダＡおよびＢに提示すると、クライアントは割引価格方式の資格が与えられる。グリッド・クライアントのアプリケーションが１０個またはそれ以上のジョブを作成する場合、これらの１０個またはそれ以上のジョブに関するＲＦＰ提示は、グリッド・プロバイダＡおよびＢのみに限定される。

参照番号８０８に例示されている通り、グリッド・ジョブに関するジョブ・コスト限界をＲＦＰ８５０に指定することができる。たとえば、ユーザは、５０００ドルというジョブ・コスト限界をＲＦＰ８５０に指定する。詳細には、ジョブ・コスト限界としては、金銭的コスト、公式、または複数の条件付きコストを含むことができる。

参照番号８３２に例示されている通り、ソフトウェア・プラットフォーム・クラス指定をＲＦＰ８５０に含めることができる。詳細には、グリッド・ジョブは、実行すべき特定のソフトウェアを必要とする場合もあれば、必要としない場合もある。グリッド・ジョブが実行すべき特定のソフトウェアを必要とする場合、参照番号８３２に例示されている通り、そのソフトウェア・プラットフォーム・クラスまたは特定のソフトウェア名がＲＦＰに含まれる。一例では、それぞれのソフトウェア・プラットフォーム・クラスに標準的な参照名または番号を割り当てることができる。たとえば、特定のソフトウェア・プラットフォーム・クラスに参照番号「７」を割り当てることができる。

一例のグリッド・ジョブは数学問題を解決しようとしており、その場合、必要な計算機能を有するものであれば、どのソフトウェアでも使用することができ、したがって、ソフトウェア・プラットフォーム・クラス指定はまったく必要ではない。しかし、他の例のグリッド・ジョブは特定のソフトウェア環境用に作成され最適化された複雑な並列データベース照会であり、その場合、そのグリッド・ジョブに関するＲＦＰは、ソフトウェア・プラットフォーム・クラス指定子に特定のソフトウェア環境を指定する。

参照番号８３０に例示されている通り、ハードウェア・プラットフォーム・クラス指定をＲＦＰ８５０に含めることができる。詳細には、グリッド・ジョブは、実行すべき特定のハードウェア・プラットフォームを必要とする場合もあれば、必要としない場合もある。グリッド・ジョブが実行すべき特定のハードウェア・プラットフォームを必要とする場合、参照番号８３０に例示されている通り、特定のハードウェア・プラットフォーム・クラスまたは特定のハードウェア・プラットフォーム名がＲＦＰに含まれる。一例では、それぞれのハードウェア・プラットフォーム・クラスに標準的な参照名または番号を割り当てることができる。たとえば、特定のハードウェア・プラットフォーム・クラスに参照番号「５」を割り当てることができる。

一例のグリッド・ジョブは数学問題を解決しようとしており、その場合、計算機能を含むソフトウェアをサポートするものであれば、どのハードウェア・プラットフォームでも使用することができ、したがって、ハードウェア・プラットフォーム・クラス指定はまったく必要ではない。しかし、他の例のグリッド・ジョブは、特定のハードウェア環境用に作成され最適化された複雑な並列データベース照会である。たとえば、特定の問題報告解決方式「ＡＰＡＲ１Ｙ７７２２２」が適用され、１０個のＩＢＭ Ｐｏｗｅｒ４プロセッサ・パーティション上で実行されるＤＢ２ＥＥＥ用に複雑なデータベース照会を最適化することができ、したがって、ＲＦＰは、「ＡＰＡＲ１Ｙ７７２２２付きＤＢ２ＥＥＥ」というソフトウェア・プラットフォーム・クラスと、「１０個のＩＢＭ Ｐｏｗｅｒ４プロセッサ・パーティション」というハードウェア・プラットフォーム・クラス、あるいはこれらのソフトウェアおよびハードウェア・プラットフォーム・クラスを表す参照番号を指定することになるであろう。

参照番号８１６に例示されている通り、グリッド・ジョブに関するデータ・アクセスおよびトランスポート・メカニズムをＲＦＰ８５０に指定することができる。詳細には、多くのグリッド・ジョブは、グリッド・プロバイダがグリッド・ジョブを実行するために、そのグリッド・ジョブに付随しなければならないデータを必要とすることになる。一例のクライアント・システムは、ファイル転送プロトコル（ＦＴＰ：file transfer protocol）へのグリッド・プロトコル拡張を含むＧｒｉｄＦＴＰなどのツールを使用して実行すべきジョブとともにグリッド・プロバイダにデータを提示する。他の例のグリッド・プロバイダは、セキュア・ソケット層（ＳＳＬ）などの安全なデータ通信チャネルを使用して、ネットワーク・アクセス可能記憶媒体にあるデータにアクセスする。いずれにしても、グリッド・クライアントによって選択されたアクセス方法に関連する追加のコストをグリッド・ベンダが計算できるように、ＲＦＰはデータ・アクセスまたはトランスポート・メカニズムを指定する。たとえば、参照番号８１６では、ＲＦＰ８５０について指定されたデータ・トランスポートは「ｇｒｉｄＦＴＰ」である。

参照番号８３６に例示されている通り、グリッド・ジョブに必要なデータに関するデータ・サイズをＲＦＰ８５０に指定することができる。たとえば、参照番号８３６に指定されたデータ・サイズは４２０００バイトのデータである。詳細には、データ・サイズはデータ・アクセスに必要な時間の量に影響を及ぼすので、データ・サイズはグリッド・プロバイダによる入札に影響を及ぼす。加えて、データの量が多くなるほど、グリッド・プロバイダがグリッド・ジョブを処理するときに、必要な記憶空間、処理能力、およびネットワーク帯域幅が増加する。

参照番号８２０に例示されている通り、グリッド・ジョブのためのハードウェア、ソフトウェア、およびデータ・トランスポートに関するセキュリティ要件をＲＦＰ８５０に指定することができる。詳細には、グリッド・ジョブによっては、信頼できる安全な環境で実行しなければならないものもある。この例で指定されているセキュリティ要件は、データ・トランスポートのための「安全なデータ・チャネル」である。描写されていない他の例では、グリッド・セキュリティ・インターフェース（ＧＳＩ：Grid Security Interface）およびＷｅｂサービス・セキュリティ（ＷＳセキュリティ）を含むがこれらに限定されないデータ保護ツールを指定することができ、トラステッド・コンピューティング・ベース（ＴＣＢ：TrustedComputing Base）およびＣ２準拠（Ｃ２セキュリティは安全なシステムのための米国国立セキュリティ機関の基準である）を含むがこれらに限定されないプラットフォーム・セキュリティ要件を指定することができる。

参照番号８１４に例示されている通り、グリッド・ジョブの待ち時間要件をＲＦＰ８５０に指定することができる。一例では、待ち時間要件は、グリッド・ジョブの結果をユーザ・インターフェースに返すために許可される時間の量を指定する。たとえば、グリッド・ジョブは、ユーザ・インターフェースに対する１秒未満（sub-second）の応答を予想して、エンド・ユーザとの対話を必要とする可能性がある。

参照番号８０６に例示されている通り、グリッド・ジョブについてサービス・レベル契約をＲＦＰ８５０に指定することができる。詳細には、グリッド・ジョブに関するグリッド・クライアントのサービス品質（ＱＯＳ：quality of service）予想はサービス・レベル契約（ＳＬＡ）に文書化される。今後理解されるように、ＳＬＡは、あるグリッド・クライアントのすべてのグリッド・ジョブについて、または特定のタイプのあるグリッド・クライアントのすべてのグリッド・ジョブについて、一般的なサービス予想を指定することができる。一例では、グリッド・クライアントはすべてのサービス予想をＳＬＡ内に公式化する。他の実施形態では、グリッド・ベンダはサービス予想のうちの一部または全部をＳＬＡ内に指定することもできる。さらに、１つのグリッド・プロバイダまたはグリッド・プロバイダ・グループは、特定のグリッド・クライアントまたはグリッド・クライアント・グループによって提示されたグリッド・ジョブに関するＳＬＡに同意することもできる。この例では、ＲＦＰ８５０は、参照番号８０６に示されている通り、指定のＳＬＡを含んでいない。しかし、代替諸実施形態では、ＳＬＡがＲＦＰ８５０に添付されるかあるいは文書番号またはその他の書式名で参照される場合もある。

参照番号８３８に例示されている通り、あるジョブに関する見積もりランタイムをＲＦＰ８５０に指定することができる。詳細には、グリッド・クライアントは、参照番号８３８に示されている通り、ＲＦＰ８５０に指定された同じジョブまたは同様のジョブの前の実行に基づいて、見積もりジョブ・ランタイムの見積もりを立てている可能性がある。グリッド・クライアントがジョブ・ランタイムの見積もりを立てていない場合でも、グリッド・ベンダがグリッド・ジョブに関する作業負荷予想をより正確に見積もることができるように、予想ジョブ・ランタイムを指定することができる。

参照番号８３４に例示されている通り、グリッド・ジョブに関するセルオフ・ポリシーをＲＦＰ８５０に指定することができる。詳細には、「セルオフ」ポリシーは、グリッド・ジョブを勝利グリッド・ベンダが他のグリッド・ベンダに売却できるかどうかを示す。この例では、参照番号８３４に描写されている通り、「セルオフ」は許可されていない。

参照番号８４０に例示されている通り、ＲＦＰに応答するためのＲＦＰ応答時間をＲＦＰ８５０に指定することができる。詳細には、グリッド・クライアントは、グリッド・プロバイダがＲＦＰに入札応答を返すための期限を指定することができる。この期限は、交渉および再提示のための追加時間を含む場合もあれば、より差し迫ったジョブに関する迅速なスポット市場価格を必要とする場合もある。この例では、参照番号８４０に描写されている通り、ＲＦＰ応答時間は２時間以内である。応答時間は、特定の時間制限、公式、または条件付き時間制限で指定できることが理解されるであろう。

参照番号８２４に例示されている通り、特定のグリッド・ジョブに関するジョブ優先順位をＲＦＰ８５０に指定することができる。詳細には、複数のジョブを同時に提示することをグリッド・クライアントが計画している場合、ユーザは各グリッド・ジョブについてジョブ優先順位を指定することができる。ジョブ優先順位は、各グリッド・ジョブの優先順位を示すことになるであろう。グリッド・リソースが不十分であるか、あるいはジョブ優先順位がジョブ・パフォーマンスに影響するようなその他の条件が発生した場合に、グリッド・ジョブを実行するための順序を決定するために、グリッド・プロバイダは、参照番号８２４に示されている通り、「１」というジョブ優先順位などのジョブ優先順位標識を使用することができる。

参照番号８４２に例示されている通り、ＲＦＰ８５０は、ここで「縮図Ａ」と呼ばれているサンプル・ジョブを含むことができる。サンプル・ジョブを含むＲＦＰ８５０を受信したグリッド・プロバイダは、サンプル・ジョブに関する実際の作業負荷要件、実際のコスト、ならびにグリッド・ジョブを処理する際のグリッド環境の実際のパフォーマンスを決定するために、グリッド環境でグリッド・ジョブを実行し、結果を検索することを決定することができる。一例では、サンプル・ジョブが表す合計のうちの見積もりパーセンテージに基づいて、グリッド・プロバイダが合計作業負荷、コスト、およびパフォーマンスを見積もることができるように、サンプル・ジョブは、ＲＦＰ８５０によって記載されたグリッド・ジョブのサイズと比較してサンプル・ジョブのサイズも示すことができる。

次に図９に関連して説明すると、本発明の方法、システム、およびプログラムによる入札コントローラの一実施形態のブロック図が描写されている。描写されている通り、入札コントローラ４１２はジョブ要求パーサ９１０を含む。ＲＦＰパーサ９１０は、ＲＦＰの形でそれぞれの仮想ジョブ要求を受信し、処理を実行できるまでそのＲＦＰをキューに入れて保持することができる。加えて、ＲＦＰパーサ９１０は、ユーザによって仮想ジョブ要求に指定された値を、作業負荷計算に使用するために指定された単位に変換することができる。

入札コントローラ４１２は、グリッド・プロバイダのグリッド環境内で使用可能な各リソースのリストを含むリソース・データベース９１２にアクセスすることができる。詳細には、各リソース・リストごとに、リソース・データベース９１２は、リソースのタイプ、どのクライアントがそのリソースにアクセスできるか、リソース・パフォーマンス指定、およびリソース・プラットフォーム特性をさらに指定することができる。加えて、リソース・データベース９１２は、グリッド環境の外部からグリッド・プロバイダのグリッド環境にとって使用可能なリソースのリストを含むこともできる。

使用可能なリソース・セレクタ９０４は、使用可能なリソース・データベース９１２をフィルタリングして、ＲＦＰによって要求された通り、どのリソースが使用可能であるかならびにＲＦＰによって要求された通り、十分なリソースが使用可能であるかどうかを判断することができる。代わって、リソース・セレクタ９０４は、グリッド・プロバイダに関する使用可能リソースを管理する管理モジュールに照会することができる。

詳細には、リソース・セレクタ９０４は、ＲＦＰに指定されたグリッド・ハードウェア・プラットフォームに必要なリソースが使用可能であるかどうかを判断する。指定のグリッド・ハードウェア・プラットフォームが使用可能ではない場合、リソース・セレクタ９０４は、ＲＦＰがセルオフを許可するかどうかを判断する。ＲＦＰがセルオフを許可する場合、リソース・セレクタ９０４は、他のグリッド・ベンダからのハードウェア・プラットフォームにアクセスするためのグリッド・ジョブのセルオフにより、グリッド・ベンダがその他のＲＦＰ基準を満たすことができるかどうかを判断し続ける。ＲＦＰがセルオフを許可しない場合、リソース・セレクタ９０４はそのＲＦＰについて入札なし（no bid）を返すことができる。

続けて、リソース・セレクタ９０４は、ＲＦＰに指定されたグリッド・ソフトウェア・プラットフォームに必要なリソースが使用可能であるかどうかを判断する。ソフトウェア・プラットフォームが使用可能である場合、リソース・セレクタ９０４は、グリッド・ベンダがその他のＲＦＰ基準を満たすことができるかどうかを判断し続ける。そうではなく、ＲＦＰに指定されたグリッド・ソフトウェア・プラットフォームが使用可能ではない場合、リソース・セレクタ９０４は、その他のグリッド環境またはオンデマンド・ソフトウェア・リソース・プロバイダが使用可能であるかどうかをチェックして、ＲＦＰによって許可される場合にそのソフトウェア・プラットフォームを提供するか、またはそのＲＦＰについて入札なしを返すことができる。

また、リソース・セレクタ９０４は、必要なセキュリティを備えたデータ・サイズについて必要なデータ・アクセスまたはトランスポート・メカニズムに使用可能な十分なリソースが存在するかどうかも判断する。必要な帯域幅について十分なリソースが存在しない場合、リソース・セレクタ９０４は、ＲＦＰによって許可される場合に必要な帯域幅があるかどうか他のグリッドをチェックするか、または入札なしを返すことができる。

必要なハードウェア・プラットフォーム、ソフトウェア・プラットフォーム、およびデータ・アクセスのための使用可能リソースに基づいて、次に作業負荷カルキュレータは入札要求に関する負荷率を計算する。合計作業負荷カルキュレータ９０８は、仮想ジョブ要求によって指定されたジョブに必要な合計作業負荷を計算することができる。詳細には、合計作業負荷カルキュレータ９０８は、あるＲＦＰに関する合計リソース要件および時間要件を決定することができる。図１０に関連してさらに説明するように、合計リソース要件は、たとえば、ジョブの完了に必要なハードウェア、ソフトウェア、またはネットワーク・リソースの総量を指定することができる。合計時間要件は、たとえば、グリッド環境内でジョブを実行するために使用可能な時間、ジョブに必要なデータにアクセスするために使用可能な時間、およびグリッド環境からクライアント・システムにジョブの結果を返すために使用可能な時間を指定することができる。加えて、合計作業負荷カルキュレータ９０８は、仮想ジョブ要求に指定された追加の値から合計作業負荷を記述するその他のパラメータを決定することができる。

キャパシティ・カルキュレータ９０２は、仮想ジョブ要求に必要な合計作業負荷と仮想ジョブ要求に使用可能なリソースとを比較し、仮想ジョブ要求によって指定されたジョブを処理するためのグリッド環境のキャパシティを決定する。詳細には、キャパシティ・カルキュレータ９０２は、グリッド環境がリソースおよび待ち時間要件を満たすことができるかどうかを判断することができる。グリッド環境内で仮想ジョブ要求のリソースおよび待ち時間要件を満たすことができる場合、キャパシティ・カルキュレータ９０２は、作業負荷要件に関するコストを決定するためにコスト・カルキュレータが使用できる合計作業負荷係数を決定する。また、作業負荷係数は、ジョブに使用可能な見積もりパフォーマンスを示すこともできる。

コスト・カルキュレータ９１４は、ＲＦＰに指定されたコスト限界によって制限されるように、作業負荷係数に基づいて合計コストを計算する。加えて、合計コストは、ＲＦＰに指定された特殊価格設定の影響を受け、オフピーク時間の使用に使用可能であり、あるいはグリッド提携の一部として合意される。一例では、米国特許出願第１１／０３１４８９号にはコスト・カルキュレータ９１４が記載されている。

入札フォーマライザ９０６は、作業負荷係数、コストを検索し、ＲＦＰとグリッド・プロバイダの可用性に関する追加の比較を実行して、グリッド・クライアントへの入札応答を公式化する。場合によっては、グリッド環境が仮想ジョブ要求の特定の要件を満たすことができないが、ある選択範囲の仮想ジョブ要求要件を満たすことができると思われる場合、使用可能な見積もりパフォーマンスは、仮想ジョブ要求要件からの偏差を示す可能性がある。たとえば、ＲＦＰがＣＵＯＤ資格を許可しないが、ＣＵＯＤリソースの使用により、グリッド・ベンダがグリッド・ジョブに関するその他のパフォーマンス要件を満たすことができると思われる場合、入札応答は、ＣＵＯＤ要件に対する例外を含むことができる。他の例では、ＲＦＰがコスト計算によって満たされない価格制限を指定する場合、入札応答は価格制限に対する例外を含むことができる。

加えて、入札コントローラ４１２は、ＲＦＰへのサンプル添付として受信したグリッド縮図のパフォーマンスを制御するサンプル・コントローラ９２０を含むことができる。図６に関連して前に説明した通り、クライアントがグリッド・プロバイダの相対コストを比較できるように、グリッド・プロバイダは、グリッド縮図を処理し、結果をクライアントに返すことができる。他の利点によれば、サンプル・コントローラ９２０は、図５に関連して説明した通り、ＲＦＰとともに受信したサンプル・グリッド縮図を処理し、実際の作業負荷使用法をリソース・セレクタ９０４に、実際の作業負荷を作業負荷カルキュレータ９０８およびキャパシティ・カルキュレータ９０２に、実際のコストをコスト・カルキュレータ９１４に転送する。全グリッド・ジョブの特定のパーセンテージを表すグリッド・ジョブのサンプルの処理による実際のリソース使用量に基づいて、リソース・セレクタ９０４は全グリッド・ジョブに関する使用可能リソースを選択し、作業負荷カルキュレータ９０８およびキャパシティ・カルキュレータ９０２は全グリッド・ジョブに関する負荷率を計算し、コスト・カルキュレータ９１４は、グリッド・ジョブのサンプルについて測定された実際のメトリックを使用して、全グリッド・ジョブに関する合計コストを計算する。

次に図１０に関連して説明すると、本発明の方法、システム、およびプログラムにより仮想ジョブ要求に基づいてリソース・セレクタおよび作業負荷カルキュレータ内で実行される計算の例示的な一例が描写されている。描写されている通り、受信ＲＦＰ１０００は、仮想ジョブ要求に関連するグリッド・ジョブを完了するためのパフォーマンス要件を指定するために指定された複数の基準を含む。参照番号１０３０に示されているテーブルは、受信ＲＦＰ１０００内の値に基づいてリソース・セレクタ９０４および作業負荷カルキュレータ９０８が実行可能な計算を記述する複数の項目を含む。以下の説明では作業負荷カルキュレータ９０８によって実行される諸ステップを広く参照するが、作業負荷カルキュレータ内のサブカルキュレータは記載されている計算および評価のうちの１つまたは複数を実際に実行できることは留意すべき重要なことである。さらに、受信ＲＦＰ１０００内に描写されている値は、要求されたジョブの実行に関連する作業負荷およびコストを入札コントローラ４１２が自動的に決定できるようにするために仮想ジョブ要求内に含めることができるタイプの値の例証となることが理解されるであろう。加えて、参照番号１０３０に示されているテーブル内に描写されている諸機能は、リソース・セレクタ９０４および作業負荷カルキュレータ９０８によって実行可能なタイプの機能を示す例示的な例にすぎないことが理解されるであろう。

参照番号１００２に例示されている通り、たとえば、ジョブの完了のための合計時間またはそれまでにジョブを完了しなければならない特定の時刻を示す「ジョブ時間制限」を指定することができる。作業負荷カルキュレータは、「ジョブ時間制限」を使用して、グリッド環境が「ジョブ時間制限」に指定された時間内にジョブを実行するために必要なキャパシティを、必要なリソースの量およびタイプの形で備えているかどうかを判断することができる。詳細には、テーブル１０３０に示されている通り、作業負荷カルキュレータはまずグリッド環境内でジョブを実行するために必要な合計時間（ＴＩＭＥｔｏｔａｌ）を見積もり、次に参照番号１００２に指定された「ジョブ時間制限」とその見積もり合計時間とを比較することができる。グリッド環境内でジョブを実行するために必要な合計時間を見積もる際に、まず、必要な合計作業負荷（ＷＯＲＫＬＯＡＤｔｏｔａｌ）を計算することができる。次に、ジョブを実行するために必要な合計時間を計算するために、必要な合計作業負荷を、作業負荷を処理するために使用可能な合計リソース（ＲＥＳＯＵＲＣＥｔｏｔａｌ）で割ることができる。ジョブの実行のために必要な合計時間が「ジョブ時間制限」より長いかまたはそれに等しい場合、「ジョブ時間制限」内にジョブを処理できないことを示すエラーが返される。キャパシティ・オンデマンド・リソースを使用できるかどうかまたはグリッド環境内のリソース制限が課されているかどうかなど、受信ＲＦＰ１０００内のその他の設定によって使用可能な合計リソースが拘束される可能性があることは留意すべき重要なことである。

参照番号１００４に描写されている通り、ジョブを実行するためにグリッド環境にとって使用可能なＣＵＯＤリソースにアクセスできるかどうかを示す「キャパシティ・オンデマンド（ＣＵＯＤ）資格」を指定することができる。さらに、ＣＵＯＤ資格は、ジョブを実行する資格のあるＣＵＯＤリソースの制限およびタイプを指定することができる。現行グリッド・キャパシティがジョブを実行するために十分ではないと作業負荷カルキュレータが判断した場合、仮想ジョブ要求に使用可能なリソースを決定する際に、作業負荷カルキュレータは「ＣＵＯＤ資格」をチェックすることができる。一例では、参照番号１０３２に描写されている通り、ジョブを実行するためにより多くのリソースが必要であると作業負荷カルキュレータが判断した場合、作業負荷カルキュレータは、ＣＵＯＤ資格が「ＹＥＳ」に設定されているかどうかを確認し、そうである場合、ジョブを実行するための合計使用可能リソース（ＲＥＳＯＵＲＣＥｔｏｔａｌ）を計算するためにグリッド・リソース（ＲＥＳＯＵＲＣＥｂａｓｅ）に使用可能ＣＵＯＤリソース（ＲＥＳＯＵＲＣＥｃｕｏｄ）を追加する。

参照番号１００６に例示されている通り、「リソース制限」は、ジョブを実行するために使用できる使用可能リソースに制限があるかどうかを指定することができる。作業負荷カルキュレータは、ジョブを処理するために使用可能な合計リソースを設定するために「リソース制限」値をチェックすることができる。詳細には、参照番号１０３４に描写されている通り、「リソース制限」が設定されている場合、使用可能な合計リソース（ＲＥＳＯＵＲＣＥｔｏｔａｌ）は「リソース制限」に設定される。

参照番号１００８に例示されている通り、ジョブを完了するための追加の要件を示す「ジョブ完了要件」値を指定することができる。たとえば、ジョブがデータベースに関するものであり、ジョブの完了がクライアント・システムに転送された新しいデータマート（data mart）の形の出力を必要とする場合、「ジョブ完了要件」は、データマートをクライアント・システムに返すために必要な時間を指定することができる。したがって、参照番号１０３６に例示されている通り、作業負荷カルキュレータは、グリッド環境内でジョブそのものを完了するために計算された時間（ＴＩＭＥｊｏｂ）に加えて、ジョブを完了するために必要な合計時間（ＴＩＭＥｔｏｔａｌ）を指定するために、追加の時間要件、記憶要件、処理要件、およびネットワーク帯域幅要件からなる「ジョブ完了要件」（ＴＩＭＥｃｏｍｐｌｅｔｅ）を使用することができる。さらに、作業負荷カルキュレータは、ジョブの完了に必要な合計時間が時間制限より長い場合、エラーを返すことができる。

参照番号１０１０に描写されている通り、「ソフトウェア・プラットフォーム・クラス」は、ジョブのソフトウェア・プラットフォーム・クラスを指定することができる。一例では、定義された番号によりソフトウェア・プラットフォーム・クラスを指定することができる。たとえば、対話式ソフトウェア・クラスをＳＷ２として指定することができ、Ｗｅｂホスティング・アプリケーションをＳＷ３として指定することができる。一般に、作業負荷カルキュレータは、指定のソフトウェア・プラットフォーム・クラスを使用して、ジョブの見込みアプリケーション特性を決定することができる。より具体的には、参照番号１０４０に描写されている通り、リソース・セレクタおよび作業負荷カルキュレータは、定義されたソフトウェア・プラットフォーム・クラスを使用して、グリッド環境がそのソフトウェア・クラスをサポートするためのハードウェアを有するかどうかを判断することができる。詳細には、様々なハードウェア・プラットフォームはソフトウェア・プラットフォーム・タイプへの適性が様々になるので、ジョブがバッチ式であるか対話式であるかを作業負荷カルキュレータが判断することは重要なことである。たとえば、ｚＳｅｒｉｅｓプロセッサは対話式ジョブの場合により効率的である可能性があり、ｐＳｅｒｉｅｓプロセッサはＷｅｂホスティング・アプリケーションの場合により効率的である可能性がある。（ｚＳｅｒｉｅｓおよびｐＳｅｒｉｅｓは、インターナショナル・ビジネス・マシーンズ社の登録商標である。）

参照番号１０１２に例示されている通り、「ハードウェア・プラットフォーム・クラス」は、ジョブのハードウェア・プラットフォーム・クラスを指定することができる。一例では、定義された番号によりハードウェア・プラットフォーム・クラスを指定することができる。一般に、作業負荷カルキュレータは、ハードウェア・プラットフォーム・クラス値を使用して、どのグリッド・ハードウェアがジョブに使用可能であるかならびにジョブに必要なハードウェア・タイプのスループット特性を決定することができる。より具体的には、参照番号１０４２に描写されている通り、リソース・セレクタおよび作業負荷カルキュレータは、定義されたハードウェア・プラットフォーム・クラスを使用して、好ましいハードウェア・プラットフォーム・クラスがグリッド環境で使用可能であるかどうかを判断することができる。ハードウェア・プラットフォーム・クラスが参照番号１０１２に指定されていない場合、作業負荷計算モジュールは、その他の指定のジョブ特性に基づいて最も効率的なハードウェア・クラスを選択しようと試みる可能性がある。たとえば、データベース・アプリケーションがジョブについて実行され、そのグリッドがデータベース・アプリケーションを実行する事前構成ｐＳｅｒｉｅｓ６５０ノードを含む場合、ｐＳｅｒｉｅｓ６５０ノードは好ましいハードウェアになるであろう。

参照番号１０１４に描写されている通り、「データ・アクセスおよびトランスポート・メカニズム」値は、ジョブに必要なデータの移動またはそのデータへのアクセスを指定することができる。リソース・セレクタおよび作業負荷カルキュレータは、データ・サイズとともに「データ・アクセスおよびトランスポート・メカニズム」値を使用して、必要なデータの移動またはデータへのアクセスに関連する時間およびリソースを決定することができる。たとえば、参照番号１０４４に描写されている通り、ＲＦＰは、グリッド・マネージャがＧｒｉｄＦＴＰアプリケーションを使用してクライアントからデータを獲得することを「データ・アクセスおよびトランスポート・メカニズム」に指定することができる。次にリソース・セレクタおよび作業負荷カルキュレータは、データ・サイズおよびハードウェア・スループットに併せてアプリケーション転送速度を考慮に入れて、ＧｒｉｄＦＴＰアプリケーションを使用してクライアントからデータを獲得するために必要な時間およびリソースを評価する。

参照番号１０１６に例示されている通り、ジョブに関する「データ・サイズ」を指定することができる。リソース・セレクタおよび作業負荷カルキュレータは、参照番号１０４４に描写されている例で説明した通り、参照番号１０１４に指定されたデータ・アクセスに必要なリソースおよび時間を計算する際にデータ・サイズを使用することができる。一例では、「データ・サイズ」についていかなる値も指定されていない場合、作業負荷カルキュレータは、ジョブの実行のためにいかなるデータ転送も必要ではないと想定することができる。

参照番号１０１８に描写されている通り、ジョブに関するパフォーマンスおよび待ち時間要件を示す「パフォーマンスおよび待ち時間要件」を指定することができる。参照番号１０４８に描写されている通り、作業負荷カルキュレータは、他の値とともに「パフォーマンスおよび待ち時間要件」を使用して、ジョブに必要なリソース・コミットメントを決定することができる。たとえば、特定のパフォーマンス要件を持たないジョブは、量および相対パワーの点で、１秒未満のユーザへの応答を必要とする対話式ジョブより、必要とするリソースが少ない可能性がある。他の例では、参照番号６１８に待ち時間値が指定されている場合、グリッド環境内で使用可能なハードウェア・プラットフォームの指定とその待ち時間値が比較される。より具体的には、スタンダード・パフォーマンス・エヴァリュエーション・コーポレーション整数（ＳＰＥＣｉｎｔ：Standard Performance Evaluation Corporation Integer）またはＳＰＥＣ浮動小数点（ＳＰＥＣｆｐ）などの業界標準とその待ち時間を比較することができ、あるいはハードウェア・プラットフォーム・クラスまたはジョブ完了限界などのその他の結合ＲＦＰ提示データに基づいて計算を行うことができるであろう。

加えて、参照番号１０２０に描写されている通り、リソース・セレクタおよび作業負荷カルキュレータが、参照番号１０５０に描写されている通り、ジョブに関する要件を満たすためにグリッド環境外のリソースの使用を考慮できるかどうかを示すために、「グリッド・セルオフ」標識を指定することができる。一例では、単一のグリッド・リソース・ベンダがデータ・セキュリティおよびジョブ結果の責任を負うことをクライアントが希望する場合、そのクライアントはグリッド・セルオフを使用可能にしない可能性もある。

次に図１１に関連して説明すると、このブロック図は、ＲＦＰに応答してグリッド・プロバイダによって生成されたＲＦＰ応答を例示している。例示されている通り、自動ＲＦＰ応答１１００は、ＲＦＰによって記述されたグリッド・ジョブを処理するためのグリッド・プロバイダの能力および契約の表示を含む。詳細には、参照番号１１０２に例示されている通り、ＲＦＰ応答１１００は応答側グリッド・プロバイダの名前を含み、この例では応答側は「ＩＢＭグリッド」である。加えて、参照番号１１０４に例示されている通り、ＲＦＰ応答１１００は、ＲＦＰに指定されているジョブ番号を含む。次に、参照番号１１０６に描写されている通り、ＲＦＰ応答１１００は、４．６時間という見積もりランタイムを含み、参照番号１１０８には４６００ドルという見積もりジョブ・コストを含む。さらに、グリッド・プロバイダは、参照番号１１１０に例示されている通り、ＲＦＰ応答１１００に関する有効期限日時を指定することができる。

加えて、前に説明した通り、ＲＦＰ応答はＲＦＰ基準の例外を含むことができる。この例では、参照番号１１１２に例示されている通り、ＲＦＰ応答１１００は、待ち時間限界（ＬＡＴＥＮＣＹＬＩＭＩＴ）より長い実際の待ち時間（ＬＡＴＡＮＣＹＡＣＴＵＡＬ）という例外を含む。さらに、ＲＦＰ応答１１００は、参照番号１１１４に例示されている通り、グリッド・クライアントが再交渉プロセス中にＲＦＰを調整するための追加の交渉ポイントおよび勧告を示すコメントを含む。

１つの利点によれば、入札フォーマライザ９０６は、グリッド・プロバイダがＲＦＰに応答するために必要な最小限の情報のみを含むＲＦＰ応答１１００などの入札応答を公式化することができる。詳細には、ＲＦＰの各基準に対する応答を含む必要性を入札フォーマライザ９０６が回避することは有利なことである。さらに、詳細には、グリッド・プロバイダから要求されたデータ・フローを削減し、グリッド・クライアントへのデータ・フローを最小限にするために、入札フォーマライザ９０６がＲＦＰ応答１１００内の情報を最小限にすることは有利なことである。応答最小化の一例では、セルオフが許可されないことをＲＦＰが指定する場合、ＲＦＰ応答は、グリッド・プロバイダがグリッド・ジョブをセルオフしないことを示す必要はないが、ＲＦＰ応答は、グリッド・ジョブに関するパフォーマンスを高めるためまたはコストを減らすための１つの方法として、セルオフを必要とする例外またはセルオフ資格を使用可能にするコメント提案を含むことができる。

ユーザがＲＦＰとともにグリッド・ジョブのサンプルを含めるときに、応答内の価格およびパフォーマンスを計算するためにグリッド・プロバイダが実際にそのサンプルを実行したかどうかあるいは価格およびパフォーマンスが見積もりに基づくものであるかどうかをＲＦＰへの応答が示す必要がある可能性があることは、留意すべき重要なことである。加えて、ユーザがグリッド・ジョブのサンプルを含めるときに、グリッド・プロバイダがサンプル結果を含む応答を返す可能性があることは、留意すべき重要なことである。

次に図１２を参照すると、グリッド環境でＲＦＰ要求に対する応答を管理するためのプロセスおよびプログラムの高レベル論理流れ図が例示されている。描写されている通り、グリッド・プロバイダ用の入札コントローラによって実行されるプロセスはブロック１２００から始まり、その後、ブロック１２０２に移行する。ブロック１２０２は、ＲＦＰが受信されたかどうかに関する入札コントローラによる判断を描写している。ＲＦＰが受信されていない場合、プロセスはブロック１２０２を繰り返す。仮想ＲＦＰが受信された場合、プロセスはブロック１２０４に移行する。

ブロック１２０４は、そのジョブが前に提示されたジョブの繰り返しであるかどうかに関する入札コントローラによる判断を描写している。そのジョブが前に提示されたジョブの繰り返しである場合、プロセスはブロック１２０６に移行する。ブロック１２０６は、ジョブ作業負荷について前に決定された価格に基づいてジョブ作業負荷の現行価格を返すことを描写しており、プロセスは終了する。代わって、ブロック１２０４で、そのジョブが前に提示されたジョブの繰り返しではない場合、プロセスはブロック１２３２に移行する。

ブロック１２３２は、縮図などのジョブ・サンプルがＲＦＰとともに含まれているかどうかの判断を描写している。ジョブ・サンプルが含まれている場合、プロセスはブロック１２３４に移行する。ブロック１２３４は、ジョブ・サンプルを実行するためにグリッド・スケジューラにジョブ・サンプルを渡すことを描写している。次に、ブロック１２３６は、ジョブ・サンプルに関する計量済み結果が使用可能であるかどうかの判断を描写している。ジョブ・サンプルに関する計量済み結果が使用可能になると、プロセスはブロック１２０８に移行する。詳細には、計量済み結果は、グリッド・プロバイダに関するグリッド環境内のジョブ・サンプルの実際の作業負荷、実際のコスト、および実際のパフォーマンスを含むことができる。詳細には、サンプルが全グリッド・ジョブのうちのあるパーセンテージを表す場合、計量済み結果は、グリッド・ジョブのサンプルを処理した実際の計量済み結果に基づいてコストおよびパフォーマンスを計算するために、プロセスの残りのステップ中にアクセスされる。

ブロック１２０８は、必要なグリッド・ハードウェア・プラットフォームが使用可能であるかどうかに関する入札コントローラによる判断を描写している。必要なグリッド・ハードウェア・プラットフォームが使用可能である場合、プロセスはブロック１２１４に移行する。そうではなく、必要なグリッド・ハードウェア・プラットフォームが使用可能ではない場合、プロセスはブロック１２１０に移行する。ブロック１２１０は、セルオフが許可されているかどうかに関する入札コントローラによる判断を描写している。セルオフが許可されていない場合、プロセスはブロック１２１２に移行する。ブロック１２１２は、入札コントローラが入札なしを返すことを描写しており、プロセスは終了する。詳細には、入札なしは、グリッド・プロバイダ、ジョブ番号、および非許容標識（non-acceptable indicator）を識別することができる。代わって、ブロック１２１０でセルオフが許可されている場合、プロセスはブロック１２１４に移行する。

ブロック１２１４は、必要なグリッド・ソフトウェア・プラットフォームが使用可能であるかどうかに関する入札コントローラによる判断を描写している。必要なソフトウェア・プラットフォームが使用可能ではない場合、プロセスはブロック１２１６に移行する。ブロック１２１６は、入札コントローラがソフトウェア・プラットフォームの可用性について残りのグリッド・プロバイダをチェックするかまたは入札なしを返すことを描写しており、プロセスは終了する。一例では、入札コントローラは、ＲＦＰがセルオフを許可する場合のみ、ソフトウェア・プラットフォームの可用性について残りのグリッド・プロバイダをチェックすることができる。そうではなく、ブロック１２１４で必要なグリッド・ソフトウェア・プラットフォームが使用可能である場合、プロセスはブロック１２１８に移行する。

ブロック１２１８は、指定のデータ・サイズについて必要な記憶帯域幅が使用可能であるかどうかに関する入札コントローラによる判断を描写している。必要な帯域幅が使用可能ではない場合、プロセスはブロック１２１６に移行する。必要な帯域幅が使用可能である場合、プロセスはブロック１２２０に移行する。

ブロック１２２０は、入札コントローラがＲＦＰ作業負荷制約を作業負荷計算モジュールに送信することを描写している。一例では、ＲＦＰ作業負荷制約としては、ＣＵＯＤ資格、ジョブ時間制限、ジョブ・リソース制限、必要なパフォーマンス、必要な待ち時間、データ・サイズ、および必要なデータ・トランスポートを含む。次に、ブロック１２２２は、作業負荷計算モジュールから負荷率が受信されたかどうかに関する入札コントローラによる判断を描写している。負荷率がまだ受信されていない場合、プロセスはブロック１２２２を繰り返す。負荷率が受信されると、プロセスはブロック１２２４に移行する。詳細には、負荷率は、リソース使用量を見積もるためにグリッド・プロバイダが使用するメトリック単位に応じて、あるジョブに必要なリソースの量、グリッド・リソースが使用される期間、グリッド・リソースによって実行するために必要とされる計算のタイプ、ならびに、あるグリッド・ジョブがグリッド・リソースについて有することになる負荷のその他の標識を含むことができる。詳細には、グリッド・プロバイダは、１時間あたりの使用量、グリッド・ジョブ専用のリソース、データ・アクセス、およびグリッド・ジョブのその他の要件を考慮に入れた、負荷率を計算するためのカスタム公式を定義することができる。

ブロック１２２４は、入札コントローラがＲＦＰ価格設定制約および負荷率をコスト計算モジュールに送信することを描写している。一例では、ＲＦＰ価格設定制約は、コスト限界、特殊価格設定、およびグリッド提携を含む。ブロック１２２６は、コスト計算が受信されたかどうかに関する入札コントローラによる判断を描写している。コスト計算がまだ受信されていない場合、プロセスはブロック１２２６を繰り返す。コスト計算が受信されている場合、プロセスはブロック１２２８に移行する。詳細には、コスト計算モジュールは、グリッド提携またはバルク・グリッド・ジョブ提示に関する特殊価格設定によって調整された通り、負荷率に関するコストを計算する。詳細には、グリッド・プロバイダは、コスト計算モジュールが、時刻、グリッド・ジョブのタイプ、グリッド・クライアントのアイデンティティ、およびコストに影響を及ぼすその他の要因に基づいて、特定の負荷率に関するコストを調整できるようにするコスト・メトリックを維持することができる。

ブロック１２２８は、コスト計算がＲＦＰに指定されたコスト限界以下であるかどうかに関する入札コントローラによる判断を描写している。コスト計算が限界以下ではない場合、プロセスはブロック１２３０に移行する。ブロック１２３０は、入札コントローラがＲＦＰがセルオフを許可する場合に他のグリッドをチェックするかまたは入札なしを返すことを描写しており、プロセスは終了する。代わって、ブロック１２２８でコスト計算が限界以下である場合、プロセスはブロック１２３２に移行する。

ブロック１２３２は、コスト計算が見積もり以下であるかどうかに関する入札コントローラによる判断を描写している。コスト計算が見積もり以下ではない場合、プロセスはブロック１２３４に移行する。ブロック１２３４は、入札コントローラが価格によってＲＦＰに応答することを描写しており、プロセスは終了する。代わって、ブロック１２３２でコスト計算が見積もり以下である場合、プロセスはブロック１２３６に移行する。ブロック１２３６は、入札コントローラが価格と、コスト限界を達成するためのＲＦＰの調整を提案するコメントまたはグリッド・プロバイダがコスト限界を満たすことができるようにするＲＦＰの例外によってＲＦＰに応答することを描写しており、プロセスは終了する。

次に図１３を参照すると、この高レベル論理流れ図は、本発明の方法、システム、およびプログラムにより、グリッド・プロバイダへのＲＦＰの提示を制御し、入札応答を処理するためのプロセスおよびプログラムを描写している。例示されている通り、グリッド・クライアント・エージェントによって実行されるプロセスはブロック１３００から始まり、その後、ブロック１３０１に移行する。ブロック１３０１は、グリッド・ジョブＲＦＰを完了し保管することを描写しており、プロセスはブロック１３０２に移行する。詳細には、前に説明した通り、ＲＦＰ指定コントローラは、ジョブがグリッド提示に関連するコストに関する資格を付与したことに応答して、ユーザがＲＦＰを完了し保管するよう誘発することができる。

次に、ブロック１３０２は、ローカル実行のためにジョブをスケジューリングすることを描写している。その後、ブロック１３０４は、外部グリッド・プロバイダにジョブを提示すべきかどうかの判断を例示している。外部グリッド・プロバイダにジョブを提示すべきではないという判断が行われた場合、プロセスはブロック１３０６に移行する。ブロック１３０６は、ローカル・グリッドまたはリソース・セット内でジョブを実行することを描写しており、プロセスは終了する。

ブロック１３０４に戻り、外部グリッド・プロバイダにジョブを提示すべきであるという判断が行われた場合、プロセスはブロック１３０８に移行する。ブロック１３０８は、ジョブがグリッド提携に関連しているかどうかの判断を例示している。ジョブがグリッド提携に関連している場合、プロセスはブロック１３１２に移行する。ブロック１３１２は、グリッド提携パートナにＲＦＰを提示することを描写しており、プロセスはブロック１３１４に移行する。そうではなく、ブロック１３０８でジョブがグリッド提携に関連していない場合、プロセスはブロック１３１０に移行する。ブロック１３１０は、ＲＦＰに指定されたかまたはグリッド・プロバイダ・レーティングに基づいて選択された選択済みグリッド・ベンダにＲＦＰを提示することを描写しており、プロセスはブロック１３１４に移行する。

ブロック１３１４は、ＲＦＰ応答が期限前に受信されているかどうかの判断を描写している。ＲＦＰ応答が期限前に受信されていない場合、プロセスはブロック１３１６に移行する。ブロック１３１６は、受信した応答の欠如について管理者に警告することを例示しており、プロセスは終了する。そうではなく、ブロック１３１４でＲＦＰ応答が期限前に受信されている場合、プロセスはブロック１３１８に移行する。

ブロック１３１８は、提示基準が応答で満足されているかどうかの判断を描写している。提示基準が応答で満足されていない場合、プロセスはブロック１３１６に移行し、提示基準と応答との不一致について管理者に警告し、プロセスは終了する。代わって、ＲＦＰ例外マネージャは、応答に含まれる例外またはコメントにより、ＲＦＰについてグリッド・プロバイダと再交渉しようと試みることもできる。そうではなく、ブロック１３１８で提示基準が応答で満足されている場合、プロセスはブロック１３２０に移行する。

ブロック１３２０は、提示基準が満足されている複数の応答が使用可能であるかどうかの判断を描写している。複数の応答が使用可能ではない場合、プロセスはブロック１３２２に移行する。ブロック１３２２は、提示基準が満足されている応答とともに単一のグリッド・プロバイダにジョブを提示することを描写しており、プロセスは終了する。複数の応答が使用可能である場合、プロセスはブロック１３２４に移行する。ブロック１３２４は、図１４に関連して説明するように、分析のために複数の使用可能な応答をグリッド・アナライザに提示することを描写しており、プロセスは終了する。

次に図１４に関連して説明すると、入札を分析するためのプロセスおよびプログラムの高レベル論理流れ図が描写されている。描写されている通り、グリッド・クライアント用の応答アナライザによって実行されるプロセスはブロック１４００から始まり、その後、ブロック１４０２に移行する。ブロック１４０２は、ジョブＸについて複数のグリッドＲＦＰ応答が受信されているかどうかの判断を描写している。複数の応答が受信されていない場合、プロセスはブロック１４０２を繰り返す。複数の応答が受信されている場合、プロセスはブロック１４０４に移行する。詳細には、一例では、図１４によって記載されたプロセスは、提示基準を満たす複数のＲＦＰ応答が受信されていると図１３のプロセスが判断したことによって呼び出される。

ブロック１４０４は、応答に例外が存在するかどうかの判断を描写している。例外が存在しない場合、プロセスはブロック１４１２に移行する。例外が存在する場合、プロセスはブロック１４０６に移行する。ブロック１４０６は、ＲＦＰ例外マネージャに例外を提示することを描写している。次に、ブロック１４０８は、例外が解決されているかどうかの判断を描写している。例外が解決されている場合、プロセスはブロック１４１２に移行する。例外が解決されていない場合、プロセスはブロック１４１３に移行する。ブロック１４１３は、管理者に警告し、例外を含むＲＦＰ応答の資格を剥奪することを描写しており、プロセスは終了する。

ブロック１４１２は、応答価格設定を分析することを描写している。次に、ブロック１４１４は、低コスト入札より２５％以上高いすべてのＲＦＰ応答を除外することを描写しており、プロセスはブロック１４１６に移行する。２５％というパーセンテージおよび適格応答の数を削減するために使用されるその他のパーセンテージは例にすぎず、グリッド・クライアントごとに様々になる可能性があることが理解されるであろう。

ブロック１４１６は、複数のＲＦＰ応答が残っているかどうかの判断を描写している。複数の応答が残っていない場合、プロセスはブロック１４２０に移行する。ブロック１４２０は、好ましいベンダを勝利応答として処理することを描写しており、プロセスはブロック１４３２に移行する。ブロック１４３２は、勝利応答を有するグリッド・プロバイダにジョブを提示することを描写しており、プロセスは終了する。そうではなく、ブロック１４１６で複数のＲＦＰ応答が残っている場合、プロセスはブロック１４１８に移行する。ブロック１４１８は、好ましいベンダが残っているかどうかの判断を描写している。好ましいベンダが残っている場合、プロセスはブロック１４２０に移行する。好ましいベンダが残っていない場合、プロセスはブロック１４２２に移行する。

ブロック１４２２は、低コスト入札から１４％以内の応答を選択することを描写している。次に、ブロック１４２４は、複数の応答が残っているかどうかの判断を描写している。複数の応答が残っていない場合、プロセスはブロック１４２６に移行する。ブロック１４２６は、低コスト応答を勝利入札として処理することを描写しており、プロセスはブロック１４３２に移行する。そうではなく、ブロック１４２４で複数の応答が残っている場合、プロセスはブロック１４２８に移行する。ブロック１４２８は見積もりジョブ・ランタイムを分析することを描写している。次に、ブロック１４３０は、最高速ランタイム応答を勝利入札として処理することを描写しており、プロセスはブロック１４３２に移行する。勝利応答を選択するために、コストおよびランタイムに加えて、入札応答に含まれるその他の要因を考慮し使用できることが理解されるであろう

好ましい一実施形態に関連して本発明を詳細に示し説明してきたが、当業者であれば、本発明の精神および範囲を逸脱せずに、形式および詳細の様々な変更が可能であることが理解されるであろう。

グリッド環境で実現可能であり、そこで本発明を実現可能であるコンピュータ・システムの一実施形態を描写する図である。 グリッド環境内の一般的なタイプのコンポーネントの一実施形態を例示するブロック図である。 グリッド環境で実現可能であるアーキテクチャの一例を描写するブロック図である。 仮想ジョブ要求が受信され、入札の形で自動的に応答される、グリッド環境を描写するブロック図である。 クライアント・システムによってグリッド・プロバイダに提示されるジョブと、グリッド・プロバイダによって返されるジョブの結果とを描写するフロー・ダイアグラムである。 クライアント定義アプリケーション・メトリックあたりの相対コストを計算するために複数のグリッド・プロバイダにグリッド・ジョブ縮図を提示するためのプロセスを描写するフロー・ダイアグラムである。 グリッド・プロバイダへの自動入札要求および複数のグリッド・プロバイダからの入札応答の自動分析を制御するためのクライアント・システムに関するグリッド・クライアント・エージェントのコンポーネントを描写するブロック図である。 グリッド・ジョブに関するＲＦＰ基準の入力のためのユーザ・インターフェースを描写するブロック図である。 グリッド・プロバイダ用の入札コントローラの一実施形態を描写するブロック図である。 仮想ジョブ要求に基づいてリソース・セレクタおよび作業負荷カルキュレータ内で実行される計算を描写する例示的な一例である。 ＲＦＰに応答してグリッド・プロバイダによって生成されたＲＦＰ応答を例示するブロック図である。 グリッド環境でＲＦＰ要求に対する応答を管理するためのプロセスおよびプログラムを例示する高レベル論理流れ図である。 グリッド・プロバイダへのＲＦＰの提示を制御し、入札応答を処理するためのプロセスおよびプログラムを例示する高レベル論理流れ図である。 グリッド・クライアント・システムで複数のグリッド・プロバイダから受信した入札を分析するためのプロセスおよびプログラムを例示する高レベル論理流れ図である。

Claims (1)

1. コンピュータの処理により、グリッド・ジョブに関するグリッド・プロバイダの選択を自動的に制御するためのコンピュータで実行される方法において、
   前記コンピュータの処理により、グリッド・クライアント・システムのユーザがグリッド環境に提示する予定の特定のグリッド・ジョブに関する、パフォーマンス要件を含む少なくとも１つの基準を入力したことに応答して、前記特定のグリッド・ジョブのタイプが前記グリッド提携契約に割り当てられた、時間制料金及び浮動小数点演算の数を含む、特定のタイプに一致するかどうかを判断し、その際、前記グリッド提携契約が前記特定のグリッド・ジョブの前記タイプを単独で提示することに前記グリッド・クライアントが同意する少なくとも１つの提携グリッド・プロバイダを含むようにし、前記特定のグリッド・ジョブが前記グリッド提携契約に割り当てられた前記特定のタイプに一致するタイプのものであることを検出したことに応答して、照会すべき前記少なくとも１つの提携グリッド・プロバイダのみを自動的に選択することによって、前記少なくとも１つの基準を満たすように前記特定のグリッド・ジョブを処理するための可用性について照会すべき前記外部グリッド環境の少なくとも１つのグリッド・プロバイダを選択するステップと、
   前記コンピュータの処理により、前記特定のグリッド・ジョブに関する入札要求内の前記少なくとも１つの基準を前記少なくとも１つのグリッド・プロバイダに自動的に配布するステップと、
   前記コンピュータの処理により、前記少なくとも１つのグリッド・プロバイダから受信した少なくとも１つの入札応答を保管するステップと、
   前記コンピュータの処理により、前記入札要求に関する応答の返却のための期限に到達したことに応答して、前記グリッド・クライアント・システムで、前記特定のグリッド・ジョブに関する勝利入札応答を選択するために前記少なくとも１つの入札応答を処理するステップと、
   前記コンピュータの処理により、前記グリッド・クライアント・システムからの前記特定のグリッド・ジョブを前記勝利入札応答を提示する特定のグリッド・プロバイダに自動的に配布するステップを含み、
   前記特定のグリッド・ジョブに関する入札要求内の前記少なくとも１つの基準を前記少なくとも１つのグリッド・プロバイダに自動的に配布する前記ステップが、
   前記入札要求内の前記少なくとも１つの基準を配布するステップであって、前記入札要求が、前記少なくとも１つの基準と、前記特定のグリッド・ジョブに関するＩＤと、前記グリッド・クライアント・システムに関するＩＤと、前記入札要求に応答を返すための期限とを含み、前記少なくとも１つの基準が前記特定のグリッド・ジョブを完了するためのパフォーマンス要件を含むステップをさらに含み、
   前記入札要求に関する応答の返却のための期限に到達したことに応答して、前記グリッド・クライアント・システムで、前記特定のグリッド・ジョブに関する勝利入札応答を選択するために前記少なくとも１つの入札応答を処理する前記ステップが、
   前記少なくとも１つの入札応答が複数のグリッド・プロバイダからの複数の入札応答をさらに含むことに応答して、前記複数の入札応答の中から最高速ジョブ・ランタイムを有する特定の入札応答を前記勝利入札応答として選択するステップをさらに含む、
   方法。

Images