(57)【要約】      （修正有）【課題】グリッド・サービス・スケジューラ・アーキテクチャを提供する。【解決手段】ホストのコンピュータ・ネットワークにわたってクライアント要求を処理するシステム／方法を提供し、それには、ホスト内に持続的なコンテナを作成すること、コンテナ内にオブジェクトを作成すること、コンテナをグリッド・コンテナ配列にグループ化すること、単一グリッド・コンテナ配列内となるコンテナ内におけるオブジェクトを、グリッド・オブジェクト配列にグループ化すること、各グリッド・コンテナ配列用に１つのマイクロ・スケジューラを作成すること、クライアント要求のそれぞれを複数のタスクに分割すること、およびタスクのグループをマイクロ・スケジューラに割り当てることが含まれ、それにおいてはマイクロ・スケジューラが、個別のタスクをオブジェクトに割り当てる。【選択図】  図２
2004206712.tif 000002
【特許請求の範囲】
【請求項１】
クライアント要求を処理するためのコンピュータ・システムであって、
複数のグリッド・コンテナ配列に接続されるグリッド・サービス・スケジューラを有  し、それにおいて各グリッド・コンテナ配列は、
それぞれのコンテナがコンピュータ・ホスト内に常駐する複数の持続的なコンテナ
および、
前記コンテナの１つ内における１つのマイクロ・スケジューラ
を有し、それにおいて
前記コンテナのそれぞれは、複数のオブジェクトを含むものとし、
グリッド・コンテナ配列を構成するコンテナ内のオブジェクトは、グリッド・オブジ  ェクト配列を構成するものとし、
前記グリッド・サービス・スケジューラは、クライアント要求を複数のタスクに分割  し、かつ前記タスクのグループを各マイクロ・スケジューラに割り当てるものとし、    かつ、前記マイクロ・スケジューラのそれぞれは、前記グリッド・サービス・スケジ    ューラから受け取ったタスクのグループからの個別のタスクを、対応するグリッド・    オブジェクト配列内のオブジェクトに割り当てるものとする、システム。
【請求項２】
さらに、複数のグリッド・サービス・スケジューラおよびゲートウェイを有し、それにおいて各ゲートウェイは、異なるグリッド・サービス・スケジューラに接続されるものとする、請求項１記載のシステム。
【請求項３】
さらに前記ゲートウェイに接続されるポータルを有し、それにおいて前記ポータルは、前記クライアント要求を前記ゲートウェイに沿って前記グリッド・サービス・スケジューラに渡すものとする、請求項２記載のシステム。
【請求項４】
各コンテナ配列がローカル・エリア・ネットワーク内に常駐し、その結果、グリッド・コンテナ配列内のオブジェクト間の通信が、ローカル通信を構成するものとする、請求項１記載のシステム。
【請求項５】
前記グリッド・サービス・スケジューラが、前記クライアント要求をトランスペアレントな方法に従って分割し、その結果、クライアントが前記クライアント要求の分割に気付くことがないものとする、請求項１記載のシステム。
【請求項６】
前記コンテナがサービス・コンテナを構成し、それらが使用されて、複数のクライアント要求に及ぶ時間期間にわたって複数のクライアントからの複数のクライアント要求が処理されるものとする、請求項１記載のシステム。
【請求項７】
クライアント要求を処理するためのコンピュータ・システムであって、
複数のグリッド・コンテナ配列に接続されるグリッド・サービス・スケジューラを有  し、それにおいて各グリッド・コンテナ配列は、
それぞれのコンテナがコンピュータ・ホスト内に常駐する複数の持続的なコンテナ
および、
１つのマイクロ・スケジューラを有し、各グリッド・コンテナ配列内において、前記  マイクロ・スケジューラは、前記グリッド・コンテナ配列内のすべてのコンテナのうち  のもっとも高いパフォーマンスを有するコンテナ内に位相的に配置されているものとし、それにおいて、
前記コンテナのそれぞれは、複数のオブジェクトを含むものとし、
グリッド・コンテナ配列を構成するコンテナ内のオブジェクトは、グリッド・オブジェクト配列を構成するものとし、
前記グリッド・サービス・スケジューラは、クライアント要求を複数のタスクに分割し、かつ前記タスクのグループを各マイクロ・スケジューラに割り当てるものとし、かつ、前記マイクロ・スケジューラのそれぞれは、前記グリッド・サービス・スケジューラから受け取ったタスクのグループからの個別のタスクを、対応するグリッド・オブジェクト配列内のオブジェクトに割り当てるものとする、システム。
【請求項８】
さらに、それぞれが異なるグリッド・サービス・スケジューラに接続されるゲートウェイを有する、請求項７記載のシステム。
【請求項９】
さらに前記ゲートウェイに接続されるポータルを有し、それにおいて前記ポータルは、前記クライアント要求を前記ゲートウェイに沿って前記グリッド・サービス・スケジューラに渡すものとする、請求項８記載のシステム。
【請求項１０】
各コンテナ配列がローカル・エリア・ネットワーク内に常駐し、その結果、グリッド・コンテナ配列内のオブジェクト間の通信が、ローカル通信を構成するものとする、請求項７記載のシステム。
【請求項１１】
前記グリッド・サービス・スケジューラが、前記クライアント要求をトランスペアレントな方法に従って分割し、その結果、クライアントが前記クライアント要求の分割に気付くことがないものとする、請求項７記載のシステム。
【請求項１２】
前記コンテナが持続的なサービス・コンテナを構成し、それらが使用されて、複数のクライアント要求に及ぶ時間期間にわたって複数のクライアントの複数のクライアント要求が処理されるものとする、請求項７記載のシステム。
【請求項１３】
ホストのコンピュータ・ネットワークにわたってクライアント要求を処理する方法であって、
前記ホスト内に持続的なコンテナを作成し、
前記コンテナ内にオブジェクトを作成し、
前記コンテナをグリッド・コンテナ配列にグループ化し、
単一グリッド・コンテナ配列内となるコンテナ内におけるオブジェクトを、グリッド・オブジェクト配列にグループ化し、
各グリッド・コンテナ配列用に１つのマイクロ・スケジューラを作成し、
前記要求のそれぞれを複数のタスクに分割し、
かつ、
前記タスクのグループを前記マイクロ・スケジューラに割り当て、それにおいては前記マイクロ・スケジューラが、個別のタスクを前記オブジェクトに割り当てるものとする方法。
【請求項１４】
さらに、前記マイクロ・スケジューラに、前記マイクロ・スケジューラが完了したタスクのグループを返すときに追加のタスクのグループを割り当てることを含む、請求項１３記載の方法。
【請求項１５】
さらに、ゲートウェイを介して前記クライアント要求を複数のグリッド・サービス・スケジューラに渡すことを含む、請求項１３記載の方法。
【請求項１６】
各コンテナ配列がローカル・エリア・ネットワーク内に常駐し、その結果、グリッド・コンテナ配列内のオブジェクト間の通信が、ローカル通信を構成するものとする、請求項１３記載の方法。
【請求項１７】
前記分割がトランスペアレントな方法に従って実行され、その結果、クライアントが前記クライアント要求の分割に気付くことがないものとする、請求項１３記載の方法。
【請求項１８】
前記コンテナがサービス・コンテナを構成し、それらが使用されて、複数のクライアント要求に及ぶ時間期間にわたって複数のクライアントの複数のクライアント要求が処理されるものとする、請求項１３記載の方法。
【請求項１９】
ホストのコンピュータ・ネットワークにわたってクライアント要求を処理する方法であって、
前記ホスト内に持続的なコンテナを作成し、
前記コンテナ内にオブジェクトを作成し、
前記コンテナをグリッド・コンテナ配列にグループ化し、
単一グリッド・コンテナ配列内となるコンテナ内におけるオブジェクトを、グリッド・オブジェクト配列にグループ化し、
各グリッド・コンテナ配列用に１つのマイクロ・スケジューラを作成し、
前記マイクロ・スケジューラは、前記グリッド・コンテナ配列内のすべてのコンテナのうちのもっとも高いパフォーマンスを有するコンテナ内に位相的に配置されているものとし、
前記要求のそれぞれを複数のタスクに分割し、
かつ、
前記タスクのグループを前記マイクロ・スケジューラに割り当て、それにおいては前記マイクロ・スケジューラが、個別のタスクを前記オブジェクトに割り当てるものとする方法。
【請求項２０】
さらに、前記マイクロ・スケジューラに、前記マイクロ・スケジューラが完了したタスクのグループを返すときに追加のタスクのグループを割り当てることを含む、請求項１９記載の方法。
【請求項２１】
さらに、ゲートウェイを介して前記クライアント要求を複数のグリッド・サービス・スケジューラに渡すことを含む、請求項１９記載の方法。
【請求項２２】
各コンテナ配列がローカル・エリア・ネットワーク内に常駐し、その結果、グリッド・コンテナ配列内のオブジェクト間の通信が、ローカル通信を構成するものとする、請求項１９記載の方法。
【請求項２３】
前記分割がトランスペアレントな方法に従って実行され、その結果、クライアントが前記クライアント要求の分割に気付くことがないものとする、請求項１９記載の方法。
【請求項２４】
前記コンテナが持続的なサービス・コンテナを構成し、それらが使用されて、複数のクライアント要求に及ぶ時間期間にわたって複数のクライアントの複数のクライアント要求が処理されるものとする、請求項１９記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、概してコンピュータ・ネットワークにわたるプロセッシング要求に関し、より詳細に述べれば、グリッド・サービス・スケジューラを使用してクライアントの要求を多くのタスクに分割する改善されたシステムに関する。このシステムは、グリッド・オブジェクト配列内の複数のオブジェクトを介してタスクを実行するが、オブジェクトは、グリッド・コンテナ配列を構成するコンテナ内にあり、グリッド・コンテナ配列は、マイクロ・スケジューラによってコントロールされる。
【背景技術】
【０００２】
グリッド・コンピューティングは、クラスタ・コンピューティングの論理環境であると言うことができる。以下は、グリッド・アーキテクチャの実装に関する評価基準としてグローバス（Ｇｌｏｂｕｓ）ツールキット（米国イリノイ州シカゴを居所とするアルゴンヌ国立研究所（Ａｒｇｏｎｎｅ  Ｎａｔｉｏｎａｌ  Ｌａｂｏｒａｔｏｒｙ）から入手可能）を使用してこの概念の吟味を行っている。グローバス（Ｇｌｏｂｕｓ）ツールキットの考察において指摘しておかなければならないことは、このテクノロジが非常に速いレートで進化しており、それぞれのリリースごとに非常に重要な差を有することである。特に、グローバス（Ｇｌｏｂｕｓ）３．０アーキテクチャには、それがオープン・グリッド・サービス・アーキテクチャ（Ｏｐｅｎ  Ｇｒｉｄ  Ｓｅｒｖｉｃｅ  Ａｒｃｈｉｔｅｃｔｕｒｅ）（ＯＧＳＡ）標準に基づいているという事実に起因して、非常に大きな進歩がある。したがって、グローバス（Ｇｌｏｂｕｓ）について議論する場合には、議論の状況を設定するために正確なリリースを明示する必要がある。
【０００３】
一例として、オープン・グリッド・サービス・アーキテクチャの採用に先行するグローバス（Ｇｌｏｂｕｓ）２．０の実装について考える。グローバス（Ｇｌｏｂｕｓ）２．０アーキテクチャを考察すると、それがグリッドを『クラスタのクラスタ（ｃｌｕｓｔｅｒ  ｏｆ  ｃｌｕｓｔｅｒｓ）』として定義していることがすぐにわかる。この複合的な観点は、グローバス（Ｇｌｏｂｕｓ）プログラムの初期からの表現であり、グリッド・コンピューティングに使用されていた古い呼び方は『メタ‐コンピューティング』である。マルチ・クラスタ・アーキテクチャの複合的な性質を指している。『クラスタのクラスタ（ｃｌｕｓｔｅｒ  ｏｆ  ｃｌｕｓｔｅｒｓ）』の観点は、グローバス（Ｇｌｏｂｕｓ）プログラムの初期の目的と一貫性を持つ。すなわちそれは、単一のインフラストラクチャにおいて、地理的に分散した国立研究所内に配置されているいくつかのクラスタを統合することである。この観点はまた、グリッドのスケーラビリティを考慮したとき、多くの意味を有する。グリッドに対する個別のホストの追加は、まもなくマネージ不能なインフラストラクチャを招くことになり、分離してマネージされるグループにホストをグループ化することが１つの論理ステップになる。『クラスタのクラスタ（ｃｌｕｓｔｅｒ  ｏｆ  ｃｌｕｓｔｅｒｓ）』パラダイムは、２つの重ねられた階層構造を提供し、それがグリッドの管理を飛躍的に簡素化する。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかしながら、『クラスタのクラスタ（ｃｌｕｓｔｅｒ  ｏｆ  ｃｌｕｓｔｅｒｓ）』パラダイムの二つの限界は、すぐに明らかになった。第１に、このスキームは本質的に２段であった。つまり、２段の階層構造しかサポートし得ず、より深い階層構造をサポートするためにはオリジナルのフレームワークに対する拡張が必要であった。第２の限界は、グリッド全体にわたるスケジューリングのための中心ファシリティがなかったことである；すなわち、メタ‐スケジューラが存在しなかった。それぞれの個別のクラスタは、そのクラスタ内のタスクをスケジュールする権限を有するクラスタ・スケジューラを伴って構成されたが、グリッド全体にわたるタスクをスケジュールするためにグリッド・スケジューラ（または、メタ‐スケジューラ）が必要なことは、すぐに明らかになった。この種のスケジューラの設計における主要な困難は、グローバス（Ｇｌｏｂｕｓ）ツールキット（バージョン２．０もしくはそれ以前）においては、グリッドの世界とクラスタ・スケジューリングの世界の間に不連続性が存在していることである。より詳細に述べれば、１つのクラスタ内およびクラスタ間のタスク・スケジューリングに、異なるスケジューリング・テクノロジならびにプロトコルが使用されていた。以下に述べる本発明は、グリッドならびにクラスタ・ドメインの両方に関する統一されたタスク・スケジューリング・ドメインを提案し、したがって本発明は、非常に深い階層構造グリッドをシームレスにサポートすることができる。
【課題を解決するための手段】
【０００５】
本発明は、ホストのコンピュータ・ネットワークにわたってクライアント要求を処理する方法を提供し、それには、ホスト内に持続的なコンテナを作成すること、コンテナ内にオブジェクトを作成すること、コンテナをグリッド・コンテナ配列にグループ化すること、単一グリッド・コンテナ配列内となるコンテナ内におけるオブジェクトを、グリッド・オブジェクト配列にグループ化すること、各グリッド・コンテナ配列用に１つのマイクロ・スケジューラを作成すること、クライアント要求のそれぞれを複数のタスクに分割すること、およびタスクのグループをマイクロ・スケジューラに割り当てることが含まれ、それにおいてはマイクロ・スケジューラが、個別のタスクをオブジェクトに割り当てる。本発明は、マイクロ・スケジューラに、そのマイクロ・スケジューラが完了したタスクのグループを返すときに追加のタスクのグループを割り当てる。またこの方法に、ゲートウェイを介してクライアント要求を複数のグリッド・サービス・スケジューラに渡すことが含められるようにもできる。
【０００６】
また本発明は、クライアント要求を処理するためのコンピュータ・システムを提供する。このシステムは、グリッド・コンテナ配列に接続されるグリッド・サービス・スケジューラを含む。各グリッド・コンテナ配列は、それぞれが異なるコンピュータ・ホスト内に常駐する持続的なコンテナ（たとえば、サービス・コンテナ）、およびマイクロ・スケジューラを含んでいる。各コンテナは、多くのオブジェクトを含む。単一のグリッド・コンテナ配列を構成するコンテナ内のオブジェクトは、グリッド・オブジェクト配列を構成する。グリッド・サービス・スケジューラは、トランスペアレントに、クライアント要求を複数のタスクに分割し、タスクのグループを各マイクロ・スケジューラに割り当てる。マイクロ・スケジューラのそれぞれは、グリッド・サービス・スケジューラから受け取ったタスクのグループからの個別のタスクを、それらに対応するグリッド・オブジェクト配列内のオブジェクトに割り当てる。
【０００７】
このシステムは、追加のレベルのスケジューラ階層構造およびゲートウェイを含むことが可能であり、それぞれは異なるグリッド・サービス・スケジューラに接続される。ポータルがゲートウェイに接続されるが、このポータルは、ゲートウェイに沿ってクライアント要求をグリッド・サービス・スケジューラに渡す。
【発明の効果】
【０００８】
各コンテナ配列は、ローカル・エリア・ネットワーク内に常駐し、その結果、グリッド・コンテナ配列内のオブジェクト間の通信が、ローカル通信を構成する。グリッド・サービス・スケジューラは、クライアント要求をトランスペアレントな方法に従って分割し、その結果、クライアントがそのクライアント要求の分割に気付くことはない。これらのコンテナは、持続的なサービス・コンテナであり、それらが使用されて、複数のクライアント要求に及ぶ時間期間にわたって複数のクライアントの複数のクライアント要求が処理される。
【０００９】
本発明のより良好な理解は、以下の図面を参照した好ましい実施態様の詳細な説明から得られるであろう。
【発明を実施するための最良の形態】
【００１０】
すでに述べたが、１つのクラスタ内およびクラスタ間のタスク・スケジューリングに、異なるスケジューリング・テクノロジおよびプロトコルが使用されていた。本発明のトポロジ・アウェア・グリッド・サービス・スケジューラ（Ｔｏｐｏｌｏｇｙ  Ａｗａｒｅ  Ｇｒｉｄ  Ｓｅｒｖｉｃｅｓ  Ｓｃｈｅｄｕｌｅｒ）（ＴＡＧＳＳ）スケジューリング・アーキテクチャは、非常に深い階層構造グリッドをシームレスにサポートすることが可能なグリッドならびにクラスタ・ドメインの両方に関する統一されたタスク・スケジューリング・ドメインを提案する。
【００１１】
この開示は、グリッド用のメタ‐スケジューラの設計に関連付けされた課題を考察する。より詳細には、クラスタ環境とグリッド環境の差について論じ、さらに伝統的なクラスタ・スケジューリング・アーキテクチャがグリッド環境におけるメタ‐スケジューリングに適切でないことを論証する。このことは、サービス・ベースのアーキテクチャの導入が新しいグリッド・テクノロジを、伝統的なクラスタ・コンピューティングからさらに遠ざけることを考慮するとき、特に真となる。ここでは、これらの側面を論じつつ、サービス指向グリッド・アーキテクチャ用に設計されたトポロジ・アウェア・グリッド・サービス・スケジューラ（Ｔｏｐｏｌｏｇｙ  Ａｗａｒｅ  Ｇｒｉｄ  Ｓｅｒｖｉｃｅｓ  Ｓｃｈｅｄｕｌｅｒ）（ＴＡＧＳＳ）の発明的なアーキテクチャを紹介する。
【００１２】
このセクションにおいては、タスク・スケジューリング・インフラストラクチャの設計に影響を与えるクラスタ環境とグリッド環境の間における主な差を簡単に探る。トポロジの考察に関して言えば、第１の検討事項は、包括的なトポロジ・インフラストラクチャに関係する。通常、クラスタは一様なトポロジを有しており、言い換えるとコンピューティング・ホストは、一般に同一のタイプであり、多くの場合はまったく同一であり、大抵は共通ネットワークを介してすべてのホストに到達可能である。いくつかのケースにおいては、クラスタが高速ネットワークを備えていることがある。グリッドのリソースがワイド・エリア・ネットワークを介して到達可能となり得ることから、また各リソースが、ワイド・エリア・ネットワーク・リンクの特性に応じた程度の異なるサービスの品質を伴って到達可能となることから、明らかにこの環境は、平均的なグリッドとは異なる。ネットワーク速度における変化は、以下のセクションにおいて明らかになろうが、ＴＡＧＳＳの設計における主要な検討事項である。
【００１３】
サービス・スケジューリング対ジョブ・スケジューリングに関しては、ＯＧＳＡ標準において提案されているように、サービス・ベースのアーキテクチャへの最近の移行に関連してもう１つの重要な検討を行う必要がある。サービス・ベースのアーキテクチャは、ほとんどのクラスタ・スケジューリングによって使用されているジョブ・ベースのアーキテクチャと大きく異なる。一方、用語「ジョブ」によって意味されるところを慎重に定義する必要がある。ここでは、コンドル（Ｃｏｎｄｏｒ）（米国ウィスコンシン州マディソンを居所とするウィスコンシン‐マディソン大学（Ｕｎｉｖｅｒｓｉｔｙ  ｏｆ  Ｗｉｓｃｏｎｓｉｎ‐Ｍａｄｉｓｏｎ）から入手可能）、ＰＢＳ（米国カリフォルニア州マウンテンビューを居所とするベリディアン・システムズ（Ｖｅｒｉｄｉａｎ  Ｓｙｓｔｅｍｓ）から入手可能）、ＬＳＦ（米国カリフォルニア州マーカムオンタリオを居所とするプラットフォーム・コンピューティング（Ｐｌａｔｆｏｒｍ  Ｃｏｍｐｕｔｉｎｇ）から入手可能）、およびロード・レベラー（Ｌｏａｄ  Ｌｅｖｅｌｅｒ）（米国アーモンクを居所とするインターナショナル・ビジネス・マシーンズ・コーポレーション（Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｂｕｓｉｎｅｓｓ  Ｍａｃｈｉｎｅｓ  Ｃｏｒｐｏｒａｔｉｏｎ）から入手可能）といったクラスタ・コンピューティングに使用可能なほとんどのタスク・スケジューリング・ミドルウェアによって使用されてきたこの用語を使用する。これらのスケジューラのすべては、「ジョブ・スケジューラ」として知られている。次に、ジョブ・スケジューラとタスク・スケジューラの特性を比較する。
【００１４】
ジョブならびジョブ・スケジューリングに関しては、「ジョブ」が１ないしは複数のプロセスに関連付けされる。ジョブが「スケジュールされた」と言った場合には、１ないしは複数のプロセスがターゲット・ホスト内に作られたことを意味する。ジョブは、たとえば、コマンド行シンタクス、環境変数等のそのジョブが関連付けされるプロセスの作成に関連するパラメータに置き換えられて記述される。また、それが必要とする、ＣＰＵもしくはホストの数、ランタイム・ライブラリ等のリソースに従って記述される。ジョブのもう１つの興味ある側面は、データ通信モデル、すなわちジョブが入力および出力データとともに使用される方法である。入力データは、コマンド行内の引数および環境変数を使用して渡される；いずれの場合においても、サポートされている唯一のフォーマットは、テキストである。すなわち、入力データがテキスト文字列として渡されるが、当然のことながらそれは、入力データを完全に含むファイルを参照することができる。出力データも類似の方法で渡される；標準出力パイプから利用可能なテキスト出力となることもあるが、通常は出力データがファイルの形式になる。したがって、一般にはジョブが一連の入力ならびに出力ファイルと結合され、この理由から、ほとんどのクラスタ・スケジューラが、「ファイル・ステージング」関数を実装しており、それがジョブの実行に先行し、またジョブが出力ファイルのセットの取り出しを完了したことに応答して、ファイルをリモート・ホストに転送する。この定義は、「ジョブ」が「単一ワーク・ユニット」に関連付けされることを指定するが、それは、それが単一セットの入力パラメータを伴って（通常は単一のユーザに代わって）開始するプロセスからなること、および通常は出力が生成された後にジョブ・プロセスが実行を終了することによる。この理由から、ジョブに関連付けされるプロセスを「一過的」として記述することができる。ジョブの一過的特性は、そのプログラミング・モデルを「バッチ実行」に限定してきた。
【００１５】
サービス、サービス要求ならびに要求スケジューリングに関して言えば、「サービス」を一様に、より多くのプロセスの１つに関連付けすることができる。しかしながら、サービスに関連付けされるプロセスは、一般に「持続的」である。つまり、サービスは、与えられたタスクを実行した後においても実行を終了せず、むしろそれは、持続的な、「複数のワーク・ユニット」または「サービス要求」を実行することのできる、はるかにサーバに近いアプリケーションとなる。したがって「要求スケジューリング」アクティビティは、新しいプロセスの作成を伴わない。むしろ、「要求スケジューリング」は、何らかの管理ポリシーに従って複数のユーザから到来するサービス要求のキューイングからなり、その後、与えられた要求をより良好に実行することができる適切なサービス・インスタンスにその要求が「ルーティング」される。サービス・プロバイダの持続的性質は、「リアルタイム」プログラミング・モデルを可能にする。データ取り扱いの側面については、「サービス」が、ＷＳＤＬならびにＳＯＡＰ等の標準から導かれる、はるかに柔軟なインフラストラクチャを使用する。入力および出力パラメータは、いくつかのプロセッサ・アーキテクチャをサポートするポータブル・データ・オブジェクトとして記述することができる。
【００１６】
次に示す表は、上記の定義で論じた側面に従って「ジョブ」と「サービス要求」を比較したものである。
【００１７】
表１：ジョブおよびサービス要求の特徴
【表１】
2004206712.tif 000003
【００１８】
タスク・スケジューリングの細分性の重要性に関して、ＴＡＧＳＳアーキテクチャの説明に進む前に、ジョブとは逆に、より細分化された要求を使用することの主要な利点について最後に付言しておく。サービス要求がはるかに小さいワーク・ユニットであることから、コンピューティング・タスクの一部分だけをアプリケーションがアウトソーシングすることを可能にする。さらにこれは、アプリケーションのコードならびにデータのほとんどを、単一のホストまたは組織内に含ませることを可能にする。この特徴は、小さいコード・セグメントだけをアウトソーシング組織に転送すればよく、また標準サービス・アウトソーシング（基本算術ルーチン等）の場合には、コードの転送がまったく必要ないことから、アプリケーション・コードがプロプラエタリな性質を有するアプリケーションにおいては重要な要件となる。この特徴の別の重要な用途は、アプリケーションが大量のデータを扱う場合である。多くの場合には、アプリケーションがデータをマニュアル操作し、アウトソーシングされるオペレーションを厳密に必要とするデータだけを送信することが可能になる。これは、多くのアプリケーションがプロプラエタリ・コードを開示することに関して鋭敏であることを前提とするのであれば重要な考慮事項である。またこれは、不可欠なデータの送信のみを必要とする場合に得られる効率に関しての重要な考慮事項でもある。図１は、多くの場合には単一の組織内において走り、小規模の並列化可能なタスクのアウトソーシングだけを行うアプリケーションとなるクラスタを示している。図１においては、オブジェクト１２８が使用されて特定のタスクが実行される。オブジェクト１２８は、クラスタ１２５内に含められている。２つの組織１２０、１２１は、クラスタ１２５を通じ、クラスタ・スケジューラ１３２およびグリッド・ゲートウェイ１３０を使用することによってデータを処理する。これに対して本発明は、多数の異なる組織内において無制限数のノードを使用するグリッドを提供する。クラスタとグリッド・コンピューティングの間における違い、特にトポロジおよびタスク・スケジューリングに関する相違について論じてきたが、これにより、本発明のトポロジ・アウェア・グリッド・サービス・スケジューラ（Ｔｏｐｏｌｏｇｙ  Ａｗａｒｅ  Ｇｒｉｄ  Ｓｅｒｖｉｃｅｓ  Ｓｃｈｅｄｕｌｅｒ）（ＴＡＧＳＳ）のアーキテクチャを議論するために必要な背景が確立された。
【００１９】
本発明は、サービス指向アーキテクチャを提供する。したがって、リアルタイム・スケジューリング・シナリオの議論から開始するが、最初の検討事項は、「リアルタイム・スケジューリング」によって何が意味されるかについて正確に定義することである。上記のセクションにおいては、バッチ実行とは逆に、サービス・プロバイダがリアルタイム・プログラミングを提供できると述べた。ここではこれらの用語を、いくつかの「クライアント・プロセス」の「通信」モデルに関連して定義する。
【００２０】
ジョブ要求またはサービス要求は、クライアント・プロセスを実行するいずれかのクライアントによって開始される。バッチ・プログラミング・モデルにおいては、ジョブ要求のポスティングの後にクライアント・プロセスが「終了」する。またバッチ・プログラミング・モデルにおいては、通常、ジョブとクライアント・プロセスの間にアクティブな通信チャンネルが存在しない。リアルタイム・プログラミング・モデルにおいては、クライアント・プロセスが持続的なサービス・プロバイダとインタラクションを行うことができる。リアルタイム・インタラクションは、サービス要求スケジューラの設計を考慮する上で極めて重要である。特に、リアルタイム・インタラクションは、サービスが「ステートフル」となることを可能にし、言い換えるとサービスが、所定のクライアントのインタラクションに関連するデータを保持できる。状態を扱う機能は、最近になってウェブ・サービス・テクノロジに追加され、それがＯＧＳＡにおける主要な設計ポイントになっている。
【００２１】
ステートフル・モデルの利点を論ずるため、それがプログラミング・モデルにもたらす利点について考察する。サービス・プロバイダにおいてアクティブ状態の維持が可能なことから、クライアント・プロセスは、入力として以前の要求の結果の参照を使用するサービス要求を作成することができる。ここではこの機能を「サーバ側キャッシング」と呼び、ＴＡＧＳＳアーキテクチャが、どのようにしてこの機能を実装しているかについて、ＴＡＧＳＳプログラミング・インターフェースを紹介しつつ論ずることにする。
【００２２】
ＴＡＧＳＳプログラミング・モデルを紹介するためには、ＴＡＧＳＳジャバ・プログラミング・インターフェースを引き合いに出すと有用である。また、Ｃ等のネイティブ言語における拘束もあるが、サービスとジャバ・オブジェクトの間における強い類似から、ジャバＡＰＩは、この議論にとって好ましい。実際に、自動化されたツールを使用してジャバ・オブジェクト定義をＷＳＤＬサービス記述にマップすることが可能である。このセクションにおいては、サービス・ベースの定義に関するフレームワークを開示する。
【００２３】
コンテナ・サービスについては、ＴＡＧＳＳアーキテクチャの目的の１つが、単純なリアルタイム・プログラミング・モデルの提供である。ジャバにおいては、オブジェクトがジャバ仮想マシン、またはＪＶＭと呼ばれるランタイム環境内において実行される。サービスの類比に関して言えば、サービスが「コンテナ」内において実行される。ＴＡＧＳＳアーキテクチャは、この類比に倣い、「コンテナ・サービス」を定義する。コンテナ・サービスは、「オブジェクト作成」および「オブジェクト・メソッド起動」に関連するサービスを提供する。これらのコンセプトは、サービス・インスタンスの作成、およびサービス要求の取り扱いに関連する。
【００２４】
本発明は、コンテナ・サービス・ファクトリを提供する。サービスを定義する主要な側面の１つは、その作成および破棄の行われる方法である。ＯＧＳＡにおいては、サービス・インスタンスが「ファクトリ・インターフェース」内に実装される仕様に従って作成される。グリッドに関するモデルのプログラミングの提案における主要な問題は、このインターフェースをどのように働かせるかということになる。クライアント・プロセスがサービス要求をポスティングするためには、それをサービス・プロバイダ・インスタンスと結び付ける必要がある。サービス作成のタスクが、更新後のリソース利用測度の観察に関連して行われなければならないことから、ＴＡＧＳＳアーキテクチャは、コンテナ・サービスの作成において主要な役割を演じる「リソース・モニタリング・サービス」を定義する。このリソース・モニタリング・サービスは、「スケジューラ・サービス」と命名されている。スケジューラ・サービスは、ノードのプール内におけるリソースの利用を継続的にモニタし、そのノードのプール内におけるコンテナ・サービスの作成をコントロールする。
【００２５】
スケジューラ・サービスが、コンテナ・サービスを直接作成することはない。ＴＡＧＳＳアーキテクチャにおいては、スケジューラ・サービスが、図２に示されている次のプロセス／システムによって実装される。中心プロセスであるＴＡＧＳＳスケジューラ２００は、ノードのプール２１０（または「最小スケジューリング・ドメイン」）内におけるリソース利用測度を収集し、この最小スケジューリング・ドメイン内におけるコンテナ・サービスに関するすべての要求を処理する。「ＴＡＧＳＳスケジューラ２００」が所定の最小スケジューリング・ドメインに関して処理するインスタンスは１つだけである。
【００２６】
ＴＡＧＳＳエージェント２０５は、周期的なリソース利用測定を行い、それらの測度を、その特定の最小スケジューリング・ドメインのＴＡＧＳＳスケジューラ２００に対してレポートする。またＴＡＧＳＳエージェント２０５は、コンテナ・サービスのファクトリ・インターフェースの実装を受け持つ。コンテナ・サービスは、所定のクライアントに割り当てられるようにしてもよく、またサービス・ポリシーの質に従って、いくつかのクライアントによって共有されるようにしてもよい。これらの２つの可能性については、後述のシナリオの中で説明する。
【００２７】
図２に、排他的コンテナ・サービスに結びつけるときに、クライアント要求に応答してオンデマンドでどのように排他的コンテナ・サービスが作られるかについてのメッセージ・フロー（１〜６）を例示した。図２に示されているように、クライアント・プロセス２１５は、まずＴＡＧＳＳスケジューラ２００に対して要求を送り、コンテナを獲得する（１）。続いてＴＡＧＳＳスケジューラ２００は、ＴＡＧＳＳエージェント２０５に対してインストラクションを送り、コンテナを作成する（２）。ＴＡＧＳＳエージェント２０５は、新しいコンテナ２２０を生み出すことによって応答する（３）。ＴＡＧＳＳエージェント２０５は、その後、ＴＡＧＳＳスケジューラ２００にコンテナ参照を返す（４）。一方、ＴＡＧＳＳスケジューラ２００は、このコンテナ参照をクライアント・プロセス２１５に返す（５）。それによりクライアント・プロセス２１５が新しいコンテナ２２０と結び付く（６）。ここで気付くことができるが、クライアント・プロセス２１５は、ＴＡＧＳＳスケジューラ２００、およびコンテナ・サービスのインスタンス２２０とだけ直接的な通信を行っており、ＴＡＧＳＳエージェント２０５とはそれを行っていない。ＴＡＧＳＳエージェント２０５の存在は、それらがスケジューラ・サービスの統合された一部であることから、クライアント・プロセス２１５に対してトランスペアレントになる。
【００２８】
共有コンテナ・サービスに対する結び付きに関して言えば、前述したように、クライアント・プロセスがコンテナを共有することも可能である。このアプローチは、各グリッド・ホスト２１０内において作り出されるコンテナの数が抑えられるという利点を有している。異なるランタイム実行優先度を有する共有コンテナを使用して異なるレベルのサービスの質を提供することが可能である。特定のコンテナに対するクライアントのマッピングは、その後、管理ポリシーまたはサービス・レベル合意（ＳＬＡ）に従ってなされる。しかしながら、共有コンテナの展開は、包括的なセキュリティ・インフラストラクチャを要求する。本発明は、ジャバ・サーブレット環境に使用されているものに類似のフレームワークを使用して、共有コンテナに関する適切なセキュリティを提供することができる。
【００２９】
次に示すプログラミング例は、コンテナ・サービス２２０に対するクライアント・プロセス２１５の結び付けを例証している。このＴＡＧＳＳ  ＡＰＩの説明においては、この開示が与えた後の当業者であれば、共有および非共有コンテナの間の差を理解できることから、その区別が必要でないとしている。以下のコード・セグメントは、どのようにしてクライアントが単一のコンテナ・サービスに結び付くか（６）について例示している。図３に示されているように、スケジューラ・サービス２００は、「グリッド」オブジェクト（ｏｂｊ１〜ｏｂｊ８）を作成する。グリッド・オブジェクト（ｏｂｊ１〜ｏｂｊ８）が作成されると、クライアント・プロセス２１５が所定のスケジューラ・サービス２００に結び付けられる。ＴＡＧＳＳスケジューラ２００プロセスのネットワーク・アドレスおよびポート番号は、コンストラクタ引数として、グリッド・オブジェクト（ｏｂｊ１〜ｏｂｊ８）の作成時に渡される。オブジェクト（ｏｂｊ１〜ｏｂｊ８）が作成された後は、クライアント・プロセス２１５がそれを使用して、図２のＧｒｉｄ．ｇｅｔＣｏｎｔａｉｎｅｒ（）メソッド（１）を実行することによって多数のコンテナ・サービス３００〜３０１に結び付くことができる。
【００３０】
<コード・セグメント１：グリッド・プロバイダに対する接続>
Grid myGrid = newGrid("tagss_scheduler_hostname", tagss_scheduler_port);
GridContainer myContainer =myGridContainer.getContainer();
【００３１】
オブジェクト（ｏｂｊ１〜ｏｂｊ８）の作成について言えば、クライアント・プロセス２１５がコンテナ・サービス３００〜３０１に結び付くと、別のサービスを作成することが可能になる。ジャバＡＰＩ内においては、そのサービスがジャバ・オブジェクトによって表される。新しいオブジェクトの作成は、ＧｒｉｄＣｏｎｔａｉｎｅｒ．ｃｒｅａｔｅＯｂｊｅｃｔ（メソッド）を起動することによってなされる。このメソッドは、作成されるオブジェクトの完全な修飾名およびコンストラクタ・パラメータを必要とする。図３に示されているように、ＧｒｉｄＯｂｊｅｃｔＡｒｒａｙ（８）インストラクションは、ＴＡＧＳＳスケジューラ２００に対して８つのオブジェクトの作成を指示する。コンテナ３００および３０１のそれぞれの中に３つのオブジェクト（ｏｂｊ１〜ｏｂｊ３；ｏｂｊ４〜ｏｂｊ６）が作られ、２つのオブジェクト（ｏｂｊ７、ｏｂｊ８）がコンテナ３０２内に作られる。コンストラクタ・パラメータは、ジャバのＡｒｒａｙＬｉｓｔを使用してプログラミング環境から直接的に取得される。内部的にＴＡＧＳＳ  ＡＰＩは、ＡｒｒａｙＬｉｓｔ内に渡されるオブジェクト・シーケンスを所定のメソッドの適切なコンストラクタに整合させるために、ジャバｒｅｆｌｅｃｔｉｏｎクラスを使用することになる。
【００３２】
<コード・セグメント２：グリッド・オブジェクトの作成>
//myObjectClass型のGridObjectを作成する。
//コンストラクタはシグニチャ（整数、倍精度、文字列）を有する；
Integer arg1 = new Integer(123);
Double arg2 = new Double(1.23);
String arg3 = "hello"
ArrayList args = new ArrayList();
args.add(arg1);
args.add(arg2);
args.add(arg3);
GridObject myObject = 
myContainer.createObject("myObjectClass",args);
【００３３】
結果として得られるＧｒｉｄＯｂｊｅｃｔは、ユーザ定義クラス型にキャストすることができる。
【００３４】
ＧｒｉｄＯｂｊｅｃｔ内のメソッドの起動に関して言えば、ＧｒｉｄＯｂｊｅｃｔ内のメソッドの実行に必要なステップは、オブジェクトの作成におけるそれに類似である。メソッドの名前は、文字列として渡され、引数は、ＡｒｒａｙＬｉｓｔを使用して渡される。
【００３５】
<コード・セグメント３：グリッド・オブジェクトに関するメソッドの起動>
//myObjectがコード・セグメント2にあるとおりに作成されたと仮定
//シグニチャ（整数、倍精度、文字列）を有するメソッドの起動準備；
Integer arg1 = new Integer(123);
Double arg2 = new Double(1.23);
String arg3 = "hello"
ArrayList args = new ArrayList();
args.add(arg1);
args.add(arg2);
args.add(arg3);
MyReturnObjectClass myResult =(MyReturnObjectClass)
myObject.invoke("myMethod",args);
【００３６】
この場合においてもメソッドのシグニチャが、ジャバｒｅｆｌｅｃｔｉｏｎを使用する適切なメソッドに整合される。このメソッドの起動の結果は、新しいＧｒｉｄＯｂｊｅｃｔとして返される。戻り値は、メソッド起動の期待される型にキャストすることができる。現在のところ、返された結果に関してパラメータ変数を使用することはできない。
【００３７】
サーバ側キャッシングに関して言えば、ＴＡＧＳＳ  ＡＰＩは、ＧｒｉｄＯｂｊｅｃｔ．ｉｎｖｏｋｅ（）メソッドのバリアントを提供し、それが、前述したサーバ側キャッシング機能を実装する。ＧｒｉｄＯｂｊｅｃｔ．ｉｎｖｏｋｅＫｅｅｐ（）は、メソッドの起動の結果に対する参照だけを返すが、結果自体は、メソッドが起動されたコンテナ内に保持される。これらの結果は、ＧｒｉｄＯｂｊｅｃｔ．ｇｅｔＶａｌｕｅ（）メソッドを使用して、その後において取り出すことができる。次に示す例は、クライアントとサービス・プロバイダの間において転送を必要とするデータの量を最小化するために、どのようにすればアプリケーションがＧｒｉｄＯｂｊｅｃｔ．ｉｎｖｏｋｅＫｅｅｐ（）に対する呼び出しを連結できるかについて示している。下の例においては、イメージ画質向上アプリケーションが３つのフィルタのシーケンスをイメージに適用し、最終結果だけを取り出している。中間結果はクライアント・プロセスにまったく返されず、中間結果の全ラウンドトリップが節約される。このテクニックは、イメージ処理等の大きなデータを操作するアプリケーションにとって重要になる。
【００３８】
<コード・セグメント４：グリッド・オブジェクト内における持続状態の使用>
//myObjectClass型のGridObjectを作成する。
//コンストラクタはシグニチャ（整数、倍精度、文字列）を有する；
Integer arg1 = new Integer(123);
Double arg2 = new Double(1.23);
String arg3 = "hello"
ArrayList args = new ArrayList();
args.add(arg1);
args.add(arg2);
args.add(arg3);
GridObject myObject = 
myContainer.createObject("myObjectClass",args);
【００３９】
この場合においても、戻り値を任意のユーザ定義クラス型にキャストできることに注意が必要である。
【００４０】
より高いレベルの作成に関しては、上記の基本のプリミティブが、グリッド環境内における個別のオブジェクトを操作する非常に柔軟なインターフェースを提供する。しかしながら、ほとんどのグリッド・アプリケーションは、並列化可能なタスクを実行するために、より高いレベルの作成を要求する。ＴＡＧＳＳプログラミング・インターフェースは、並列オペレーション用により高いレベルのプリミティブのセットを提供する。一例とする実施態様においては、本発明が３つのより高いレベルのオペレーションを提供する：メッセージ・マルチキャスト、バリア強制メソッド起動、およびスキャッタ／ギャザのオペレーションである。これらの関数は、以下に説明するオブジェクト収集を操作するＴＡＧＳＳ内の追加のプリミティブによって提供される。
【００４１】
グリッド・コンテナ配列３０７は、コンテナ３００〜３０２の集合を表す。コンテナ配列は、コンテナと同一の関数セットを実装し、コンテナ配列内において起動されるメソッドは、コンテナ配列内の部分である各コンテナに対して適用される。コンテナ配列ファクトリ・インターフェースもまた、グリッド・オブジェクト（ｏｂｊ１〜ｏｂｊ８）によって表されるサービス・スケジューラによって実装される。コンテナ配列を作成するメソッドは、Ｇｒｉｄ．ｇｅｔＣｏｎｔａｉｎｅｒＡｒｒａｙ（）である。このメソッドは、希望のコンテナ数を示す整数を引数とする。返される実際のコンテナ数は、リソース不足の場合には、希望された数より少ないこともある。返される実際のコンテナ数は、ＧｒｉｄＣｏｎｔａｉｎｅｒＡｒｒａｙ．ｇｅｔＮｕｍｂｅｒＣｏｎｔａｉｎｅｒｓ（）を起動することによって獲得される。希望のコンテナ数の引数として値０（ゼロ）が渡された場合には、グリッド・スケジューラが、リソース利用状況に従って、かつクライアントの信用証明に従って利用可能な最大数のコンテナを返す。次に示す例は、ＣｏｎｔａｉｎｅｒＡｒｒａｙコンストラクタのシンタクスを例証している。
【００４２】
<コード・セグメント５：グリッド・コンテナ配列の作成>
GridContainerArray myContainerArray =Grid.getContainerArray(0);
int numberOfContainers =myContainerArray.getNumberContainers
【００４３】
すでに述べたように、グリッド・コンテナ配列３０７は、個別のコンテナに類似する機能セットを実装する。コンテナがグリッド・オブジェクト（ｏｂｊ１〜ｏｂｊ８）を作成するファクトリであるように、グリッド・コンテナ配列３０７は、グリッド・オブジェクト配列３０６の型のオブジェクトのファクトリである。グリッド・オブジェクト配列３０６を作成するメソッドは、ＧｒｉｄＣｏｎｔａｉｎｅｒＡｒｒａｙ．ｃｒｅａｔｅＯｂｊｅｃｔ（）である。このメソッドは、入力引数として、作成されることになるオブジェクト型の名前（クラス名）および起動されることになる各コンストラクタ呼び出しに関する引数を含むデータ構造を取る。引数リストは、同一のシグニチャを有していること、すなわち引数シーケンス内において同一の値を用いてインデクスされたそれぞれのオブジェクトが、同一のクラス型である必要がある。オブジェクト配列の作成用の引数リストの作成を容易にするために、ＴＡＧＳＳインターフェースは、ＧｒｉｄＤａｔａＳｅｔと呼ばれる補助データ構造を使用する。ＧｒｉｄＤａｔａＳｅｔは、マトリクスとしてビジュアル化可能であり、それにおいては、各行がオブジェクト配列内のコンストラクタまたはメソッドの起動に適用されることになる引数リストになる。したがって、ＧｒｉｄＤａｔａＳｅｔの各列は、同一データ型のオブジェクトを含んでいる必要がある。たとえば、次の例示は、シグニチャ「整数、倍精度、文字列」のコンストラクタを起動するためのＧｒｉｄＤａｔａＳｅｔを構築する方法を示している。
【００４４】
<コード・セグメント６：グリッド・データ・セットの作成>
//入力値がintArray、doubleArray、およびStringArray内にあると仮定する
GridDataSet myGridDataSet = newGridDataSet();
ArrayList singleRow = new ArrayList();
for( i = 0; i < inputSize; i++ )
{
singleRow.add(intArray[i]);
singleRow.add(doubleArray[i]);
singleRow.add(StringArray[i]);
myGridDataSet.addRow(singleRow);
singleRow.clear()
{
【００４５】
ここで注意する必要があるが、ＧｒｉｄＤａｔａＳｅｔ内の行の数がコンテナの数に等しくなる必要がないことは重要である。本発明は、コンテナの単なるサブセットとしてオブジェクトを構築し、図３に示されるように、１つのコンテナ内に複数のオブジェクト・インスタンスを作成することによって、コンテナの数より多いオブジェクトを作成する。より詳細に述べれば、図３は、３つのコンテナだけが利用可能な場合に、８つのオブジェクトを伴うＧｒｉｄＯｂｊｅｃｔＡｒｒａｙの作成を試みるクライアントを示している。クライアントは、それにもかかわらず利用可能なコンテナ内に複数のオブジェクトを作成することによって、８つのオブジェクトを伴うグリッド・オブジェクト配列３０６の作成に成功している。
【００４６】
オブジェクト配列３０６内においてメソッドを実行するとき、オブジェクト配列３０６は、コンテナ配列３０７に類似のセマンティクスを有している。オブジェクト配列３０６に指向されたメソッドの起動は、オブジェクト配列３０６の各オブジェクト・インスタンスにおけるメソッドの起動を結果としてもたらす。この複数のメソッドの起動の結果は、ＧｒｉｄＯｂｊｅｃｔＡｒｒａｙ内に返され、それにおいてはｉ番目の要素がＧｒｉｄＤａｔａＳｅｔのｉ番目の行を使用するメソッド起動の結果となる。次のコード・セグメントは、ＧｒｉｄＯｂｊｅｃｔＡｒｒａｙに関するメソッドの起動を例証している。
【００４７】
<コード・セグメント７：グリッド・オブジェクト配列に関するメソッドの起動>
//グリッド・オブジェクト配列を作成する
GridObjectArray myGridObjectArray = 
GridContainerArray.createObject(myGridDataSet);
//inputSet内に入力データをロードしたものと仮定する
GridDataSet inputSet = loadDataSet();
//グリッド配列に関するメソッドを起動する
GridObject[] resultArray = 
myGridObjectArray.invoke("methodName",inputSet, invokation_mode);
【００４８】
次に、引数ＴＡＧＳＳＩｎｖｏｃａｔｉｏｎＭｏｄｅを使用して指定される、グリッド・オブジェクト配列３０６内におけるメソッド起動の３つのモードを説明する。
【００４９】
最初のモードは、ＴＡＧＳＳ＿ＩＮＶＯＫＥ＿ＭＵＬＴＩＣＡＳＴである。この起動モデルは単一のパラメータ・リストを伴って使用され、残り２つのモードと異なりグリッド・データ・セットを伴わない。この起動モードでは、メソッドがグリッド・オブジェクト配列３０６のすべてのオブジェクト内において、単一のパラメータ・リスト内に含まれているまったく同一のパラメータのセットを伴って起動される。この起動モードが使用されて、同期メッセージがオブジェクトに送られる。
【００５０】
もう１つのモードは、ＴＡＧＳＳ＿ＩＮＶＯＫＥ＿ＥＡＣＨである。この起動モードは、ＧｒｉｄＤａｔａＳｅｔ内の各行が配列内の対応するオブジェクトに適用される必要があることを指定する。つまり、行０がオブジェクト０に適用され、行１がオブジェクト１に適用されるといった態様になる。このモードにおいては、ＧｒｉｄＤａｔａＳｅｔ内に指定されている行の数が配列内のオブジェクトの数と等しいか、それより小さくなる必要がある。このメソッド起動モードは、バリア強制メソッド起動用に使用される。
【００５１】
さらに別のモードは、ＴＡＧＳＳ＿ＩＮＶＯＫＥ＿ＡＮＹである。この起動モードは、ＧｒｉｄＤａｔａＳｅｔの行と、グリッド・オブジェクト配列３０６内のオブジェクトの間におけるマッピング要件を指定しない。このモードは、基礎をなすスケジューリング・インフラストラクチャに関する大きな柔軟性を提供する。たとえば、１０個のオブジェクトを伴うオブジェクト配列に、１，０００行のＧｒｉｄＤａｔａＳｅｔに関するメソッドの起動を指示することが可能である。いずれのオブジェクトがいずれの行に作用するかというマッピングについては、後述するように、ＴＡＧＳＳ内の基礎をなすスケジューリング・インフラストラクチャによってランタイム時に行われる。この起動方法は、スキャッタ／ギャザ・プログラミング・モデル内において使用される。上記の３つの起動モードは、ＴＡＧＳＳ内に次の３つの基本並列プログラミング・モデルを実装する：すなわち「メッセージ・マルチキャスト」、「バリア強制メソッド起動」および「スキャッタ／ギャザ」である。これら３つのプログラミング・モデルについては、以下に詳細を説明する。
【００５２】
メッセージ・マルチキャスト・モードは、単純に単一のメッセージをオブジェクトの集合に送るプログラミング・モデルである。ＴＡＧＳＳ  ＡＰＩは、単一の引数リストを取り、かつそれをグリッド・オブジェクト配列３０６内のすべてのオブジェクトに適用するメソッド起動関数を提供することによって、このモデルをサポートしている。
【００５３】
<コード・セグメント８：メッセージ・マルチキャスト・プログラミング・モデルの使用>
GridObject[] result =myGridObjectArray.invoke("methodName", argList,TAGSS_INVOKE_MULTICAST);
【００５４】
バリア強制並列メソッド起動は、拘束された方法に従って複数のオブジェクトがデータに作用することを必要とするいくつかの並列プログラミング・メソッドを実装するために使用することが可能なプログラミング・モデルである。オブジェクト４００〜４０３の間における拘束されたオペレーションを図４に示す。この種の起動においては、オブジェクトがすべて、特定のメソッドを完了した後でなければ次のメソッドを起動することができず、言い換えると各メソッドの実行を同期させる暗示的なバリアが存在する。たとえば、次に示すコード・セグメントは、直前の計算の結果を、シフト繰り上げ態様で配列内の各オブジェクトにリダイレクトするパイプラインを実装しており、バリア同期を使用して、各メソッド起動前に結果が完成することを保証している。
【００５５】
<コード・セグメント９：シフト‐結果‐バリア・パターンの実装>
//バリア同期の例
//入力がすでにGridDataSet内にロードされていると仮定する
//結果を右にシフトするパイプラインを使用する3つのメソッドを起動する
GridObject[] result =myGridObjectArray.invoke("first_stage", inputDataSet,TAGSS_INVOKE_EACH);
//結果を右にシフトする
GridObjecttemp = result[result.size();
//最後の要素を順次ラップアラウンドする
for (i = 0;i < result.size()-1;i++)
result[i+1] = result[i];
result[0] = temp;
//ラップアラウンド
//第2ステージを呼び出す
GridObject result2 =myGridObjectArray.invoke("second_stage", inputDataSet,TAGSS_INVOKE_EACH);
【００５６】
たとえば、４つのオブジェクトに関して上記のコードを実行すると、図４に示されている通信パターンが設定される。
【００５７】
スキャッタ／ギャザ・モデルは、ＴＡＧＳＳ＿ＩＮＶＯＫＥ＿ＡＮＹ起動モデルが指定されたときに使用される。この場合においては、ランタイム条件に従ってＧｒｉｄＤａｔａＳｅｔの行がグリッド・オブジェクトに割り当てられる。行のマッピングは、メソッド起動を完成する各オブジェクトのケイパビリティに従ってなされる。ランタイム・スケジューリングは、図５に示されているように、ＴＡＧＳＳクライアント・スケジューラ（またはマイクロ・スケジューラ）５００と呼ばれる、クライアント・アプリケーションに代わってランタイム時に作成されるビルトイン・スケジューリング・エージェントによって行われる。
【００５８】
マイクロ・スケジューラ５００は、小規模のマルチ‐スレッド・オブジェクトであり、グリッド・コンテナ配列３０７が作成されるときに「暗示的に」組み込まれる。各グリッド・コンテナ配列３０７は、独自のＴＡＧＳＳクライアント・スケジューラ５００のインスタンスを有している。ＴＡＧＳＳマイクロ・スケジューラ５００は、グリッド・オブジェクト配列３０６内のオブジェクト（ｏｂｊ１〜ｏｂｊ８）の間に行を散乱させ、その後、オブジェクト（ｏｂｊ１〜ｏｂｊ８）によるタスクの完了時に新しい行をスケジュールする。つまり、図５に示されているように、クライアント・プロセス２１５が、データ・セットを用いてグリッド・オブジェクト配列３０６を起動する（１１）。ＴＡＧＳＳスケジューラ２００は、そのデータ・セットを用いて特定のメソッドを起動する（１２）。ＴＡＧＳＳマイクロ・スケジューラ５００が、各種のオブジェクト（ｏｂｊ１〜ｏｂｊ８）に対してデータ・セットの行を起動し（１３）、そのそれぞれが、行の１つに関する特定のタスクを実行する。オブジェクトによるタスクの完了時に、ＴＡＧＳＳマイクロ・スケジューラ５００が、グリッド・オブジェクトを返す（１４）。
【００５９】
ＴＡＧＳＳクライアント・スケジューラ・オブジェクトの配置は、全体的なＴＡＧＳＳアーキテクチャを考慮して行われ、かつグリッド・トポロジに従い、ＴＡＧＳＳマイクロ・スケジューラ５００が多数のネットワーク・トラフィックならびにＩ／Ｏプロセッシングを生成することを考慮して行われる。ＴＡＧＳＳクライアント・スケジューラ５００を走らせるコンテナ３００は、メッセージ・マルチキャストならびにスキャッタ／ギャザ・モデルの両方における中心座標点である。ＴＡＧＳＳマイクロ・スケジューラ５００は、オブジェクト配列３０６内のすべてのオブジェクト（ｏｂｊ１〜ｏｂｊ８）と通信し、一定してメソッド起動に関する入力データを渡すだけでなく、完了時には出力データを収集する。
【００６０】
これらの条件は、クライアント・プロセス２１５がＴＡＧＳＳマイクロ・スケジューラ５００の配置に関して充分な選択力を持たないことを示している。つまりグリッド内の通常の構成がクライアント・プロセス２１５をネットワークのフリンジに配置し、そのネットワークの中心よりはるかに低速なネットワークを介して接続されることからそのようになる。
【００６１】
ＴＡＧＳＳマイクロ・スケジューラ５００に関する最良ロケーションを選択するために、ＴＡＧＳＳアーキテクチャは、最良パフォーマンス（そのグリッド・コンテナ配列内のほかのコンテナと比較した場合）を提供することになるコンテナ内にＴＡＧＳＳマイクロ・スケジューラ５００を配置する。コンテナの選択は、コンテナ配列３０７が作成された時点において利用可能なパフォーマンス測定（たとえば、プロセッシング速度、入力／出力キャパシティおよびボリューム等）に従ってなされる。慣例によりＴＡＧＳＳスケジューラ・サービス２００は、サービスのクライアントの減少順でコンテナの順序設定（ランク付け）を行い、０（ゼロ）によりインデクスされたコンテナがグリッド内の最良パフォーマンス・コンテナになる。グリッド・コンテナ配列３０７が作成されるとき、ＴＡＧＳＳマイクロ・スケジューラ５００は、コンテナ０（ゼロ）内に作成される。
【００６２】
バッチ起動に関して言えば、ランタイム・スケジューリング・プロセスは、バッチ起動をサポートする。つまり、クライアントが大規模な並列要求のポスティング後に終了することを希望した場合には、ＴＡＧＳＳアーキテクチャが、ＧｒｉｄＯｂｊｅｃｔ．ｉｎｖｏｋｅＡｓｙｎｃ（）メソッドにより利用可能となる非同期起動オプションを実装することによってその機能を提供する。このメソッドは、ＧｒｉｄＯｂｊｅｃｔに対する持続的参照である要求参照のＧｒｉｄＢａｔｃｈを返す。クライアント・プロセスは、この参照を持続的ストレージ内に保存し、その後の時点においてＧｒｉｄＯｂｊｅｃｔを取り出すことができる。クライアント・プロセスは、メソッドＧｒｉｄＢａｔｃｈ．ｐｅｅｋ（）を使用してＧｒｉｄＢａｔｃｈの完了に関するクエリを行うことが可能であり、これは、ＧｒｉｄＢａｔｃｈが完了したときに「真」を返し、その時点においては、ＧｒｉｄＢａｔｃｈ．ｇｅｔＲｅｓｕｌｔ（）メソッドを起動することによって結果を取り出すことができる。この処理に関するコード例を次に示す。
【００６３】
<コード・セグメント１１：並列起動の同期のためのＷａｉｔ  Ｃｏｎｄｉｔｉｏｎｓの使用>
//3つの大規模オペレーションを並列に実行し、その後すべてが完了するまで待機する
GridBatch batch1 =GridObjectArray1.invokeAsync("method1", dataSet1);
GridBatch batch2 =GridObjectArray2.invokeAsync("method2", dataSet2);
GridBatch batch3 =GridObjectArray3.invokeAsync("method3", dataSet3);
//バッチ1が完了したか否かをチェックする
Boolean isComplete = batch1.peek();
//バッチ1が完了するまで待機する
GridObject[] result = batch.waitOnComplete();
//バッチ2および3がともに完了するまで待機する
GridWaitCondition waitCondition = newGridWaitCondition(batch2);
waitCondition.add(batch3);
waitCondition.waitOnComplete();
【００６４】
本発明は、インタラクティブおよびオフラインのクライアント・プロセスの両方に適用することができる。前述したプログラミング・パラダイムは、インタラクティブ・クライアント・プロセスに限定されない。クライアント要求は、オフラインの提出も可能である。その場合、クライアント・プロセスを実行するコード自体がオフライン・ジョブ要求として送られる必要がある。クライアント・プロセスの実行は、その後、ジョブ・スケジューリング・パラダイムに従うことになる。クライアント・プロセスがスケジュールされ、起動された後は、そのスケジューリング・リソースを伴うリアルタイム・セッションが設定され、続いてスケジューリング・プロセスが、前述と同様にリアルタイムで作用する。
【００６５】
ＴＡＧＳＳアーキテクチャは、分散環境においても良好に作用する。最良のパフォーマンスのためには、類似した特徴を伴うノードが、単一のサービス・スケジューラによってコントロールされる「最小スケジューリング・ドメイン」内にグループ化される必要がある。最小スケジューリング・ドメインのサイズは、ＴＡＧＳＳマイクロ・スケジューラ５００を実行するノードのパフォーマンスに影響を与えることになる。
【００６６】
ＴＡＧＳＳアーキテクチャは、複数の最小スケジューリング・ドメインにわたってタスクを分散させる単純な方法を提供する。すでに述べたように、タスク・スケジューリングは、ＴＡＧＳＳマイクロ・スケジューラ５００、すなわち各グリッド・コンテナ配列３０７内の区別されたコンテナ内に作成される小規模のマルチ‐スレッド・オブジェクトによって行われる。最小スケジューリング・ドメインにわたってスケジュールを行うために、複数のグリッド・オブジェクト配列を使用して複合グリッド・オブジェクト配列３０６が構築される。その後、スケジューリング・タスクが、各グリッド・オブジェクト配列３０６内のＴＡＧＳＳクライアント・スケジューラの間において仕切られる。
【００６７】
この強力な特徴は、クライアント・プロセスにとってトランスペアレントである。ＴＡＧＳＳマイクロ・スケジューラ５００オブジェクトがＴＡＧＳＳインフラストラクチャによって暗示的に作成されたように、複数のオブジェクト間における作業負荷の分割についても、前述したオブジェクト作成およびメソッド起動のセマンティクスに従って暗示的に生じる。
【００６８】
複数オブジェクトの間にタスクを分散させるためにすべてのクライアント・アプリケーションが行わなければならないことは、複合グリッド・オブジェクトの構築だけである。これは、以下に示すようにメソッドＧｒｉｄ．ａｄｄ（）を使用することによって行われる。このメソッドは、グリッド・オブジェクトを、別のスケジューリング・ドメインのＴＡＧＳＳスケジューラ２００に結び付ける。たとえば、以下に示すコードならびに図６においては、『ゲートウェイ１』６００に結び付けられるグリッド・オブジェクト配列３０６が作成され、続いてそれがＧｒｉｄ．ａｄｄ（）メソッドを使用して『ゲートウェイ２』６０１に結び付けられる。第２のゲートウェイ６０１は、詳細を前述したグリッド・コンテナ配列３０７と実質的に類似のグリッド・コンテナ配列３０８に接続される。グリッド・コンテナ配列３０８は、異なるホスト２１１を使用し、かつコンテナ３０３〜３０５内のオブジェクトｏｂｊ９〜ｏｂｊ１６からなる、異なってはいるが類似のグリッド・オブジェクト配列３０７を含む。ホスト２１１は、ホスト２１０から地理的に分離することができる。しかしながら好ましくはホスト２１１を局部的なネットワーク内（たとえば、１つの組織内）に置き、ホスト２１０も同様に、それぞれの局部的なネットワーク内に置く。前述したように、各グリッド・コンテナ配列は、独自のＴＡＧＳＳマイクロ・スケジューラを必要とする。したがって、グリッド・コンテナ配列３０８は、ＴＡＧＳＳマイクロ・スケジューラ５０１を備える。グリッド・コンテナ配列３０７およびグリッド・コンテナ配列３０８は、複合グリッド・コンテナ配列６０８を構成し、それにはすべてのゲートウェイにおいて利用可能な最大数のコンテナが含まれる。図６は、グリッド・オブジェクト配列３０６およびグリッド・オブジェクト配列３０７から構成された、結果として得られる複合グリッド・オブジェクト配列６０７についても示している。複合グリッド・コンテナ配列６０８および複合グリッド・オブジェクト配列６０７は、実質的に異なるコンピューティング・ケイパビリティを有することもある複数のドメイン（たとえば、２１０および２１１）に及ぶ。ここで注意が必要であるが、複合グリッド・オブジェクト配列のセマンティクスまたはＡＰＩ内には差がなく、最小スケジューリング・ドメインを超えてそれが広がるという事実は、クライアント・プロセス２１５にとってトランスペアレントである。次に示すコーディング例は、０（ゼロ）個のコンテナを指定するメソッドＧｒｉｄ．ｇｅｔＣｏｎｔａｉｎｅｒＡｒｒａｙ（）を使用してグリッド・オブジェクト内のすべてのコンテナを求める要求を行う。
【００６９】
<コード・セグメント１２：複合グリッド・コンテナの使用>
//2つの異なるドメイン内のサービス・スケジューラに接続する
Grid grid1 = new Grid("gateway1",1234);
Grid1.add("gateway2", 1234);
//2つの異なるドメインからのコンテナを使用して大規模グリッド・コンテナ配列307を構築する
GridContainerArray bigContainerArray =grid1.getContainerArray(0);
//2つのドメインに及ぶオブジェクト配列を作成する
GridObjectArray bigObjectArray = 
bigContainerArray.createObject("objectType", inputArgs);
//オブジェクト配列に関するメソッドを起動する
GridObjectArray bigResult = 
bigObjectArray.invoke(methodName",methodArgs);
【００７０】
図６は、上記の例のマルチ・クラスタ環境において上記のコードを使用して作成されたオブジェクトを示している。図７は、ゲートウェイ６００、６０１の間の通信効率における補助を行うグリッド・ポータル７００を含んでいる。ここで注意する必要があるが、上記の例は２段スケジューリング階層構造を紹介している。サービス・スケジューラに対するプロキシとして作用し、複合グリッド・オブジェクト配列を構築する中間プロセスを採用する多段階層構造についても、本発明とともに利用可能である。たとえば図８は、グリッド・ポータルを含むアウトソーシング組織８００を示しており、複数のクライアント・プロセス２１５、２１６、複数のスケジューラ２００、２０１が、複数のグリッド・コンテナ配列３０７〜３０９にアクセスする別のグリッド・ポータル７００、７０２に接続されている。図８に示されているシステムにおいては、複合グリッド・コンテナ配列３０７〜３０９および複合グリッド・オブジェクト配列６０７が成長してアウトソーシング組織８００のコントロール下となるすべてのオブジェクトならびにコンテナを含む。
【００７１】
グリッド・ポータルは、いくつかの個別の最小サービス・ドメインからのコンテナを収めるように構成される。また、グリッド・ポータルがサービス・スケジューラ２００、２０１に対するトランスペアレントなプロキシであることから、本発明においては、任意数のグリッド・ポータルの連結が可能であり、その結果、深い階層構造がもたらされる。グリッド環境内においてどのようにＴＡＧＳＳアーキテクチャが展開されるかについての可能性のある構成はいくつか存在し、上記は、もっとも単純な構成の１つを示唆している。議論を単純化するために、ここで組織に関する２つの基本的な役割を考える：それをサービス・プロバイダまたはサービス・アウトソーサとすることができる。これにおける基本構成は、グリッド・ポータルが、インバウンドおよびアウトバウンドのサービス要求のすべてのフローを調整するべく構成されることを示唆する。これは、すべての要求を監査するインフラストラクチャを可能にする。アウトソーシング組織のグリッド・ポータルは、特定のグリッド証明書の下に実行され、それを伴ってサービス・プロバイダ組織のグリッド・ポータルからリソースを獲得する。
【００７２】
一実施態様においては、ＴＡＧＳＳプロセス：サービス・スケジューラ２００、２０１、およびグリッド・ポータル７００〜７０２が、システム管理者によって開始され、構成される。別の実装は、それらのプロセスを単一のクライアント（ユーザまたは組織）に代わってオンデマンドで開始する。たとえば図８においては、アウトソーシング組織が、ジョグ要求を（アプリケーション・コードとともに）、要求されたグリッド・ポータルならびにサービス・スケジューラを開始するアウトソーシング組織に対して提出することができる。このようにして、サービス・プロバイダ組織にＴＡＧＳＳアプリケーションがインストールされていない場合であってもアウトソーシング組織がリソースを獲得する。このアプローチを用いれば、まったく新しいＴＡＧＳＳプロセスのセットが単一のクライアント用に作成される。
【００７３】
ＴＡＧＳＳスケジューラは、前述したようにグローバス（Ｇｌｏｂｕｓ）２．０ツールキットを使用してグリッド環境内において展開することが可能である。グローバス（Ｇｌｏｂｕｓ）２．０ツールキットは、この開示の最初に述べたジョブ・ベースのアーキテクチャによって強く影響を受け、基本的にジョブ提出モデルのサポートしか行わない。しかしながら、前に述べたように、ジョブ提出モデルは、ＴＡＧＳＳソフトウエア・プロセスをジョブとして開始することができる。これらの『ジョブ』だけが『非常に長命』であり、一方それらは、いくつかのクライアントに代わってサービス要求のレベルにおいてタスクをスケジュールする。
【００７４】
言い換えると、本発明はクライアント要求を処理するためのコンピュータ・システムを提供する。このシステムは、グリッド・コンテナ配列に接続されるグリッド・サービス・スケジューラを含む。各グリッド・コンテナ配列は、それぞれが異なるコンピュータ・ホスト内に常駐する持続的なコンテナ（たとえば、サービス・コンテナ）、およびマイクロ・スケジューラを含んでいる。各コンテナは、多くのオブジェクトを含む。単一のグリッド・コンテナ配列を構成するコンテナ内のオブジェクトは、グリッド・オブジェクト配列を構成する。グリッド・サービス・スケジューラは、トランスペアレントに、クライアント要求を複数のタスクに分割し、タスクのグループを各マイクロ・スケジューラに割り当てる。マイクロ・スケジューラのそれぞれは、グリッド・サービス・スケジューラから受け取ったタスクのグループからの個別のタスクを、それらに対応するグリッド・オブジェクト配列内のオブジェクトに割り当てる。
【００７５】
このシステムは、追加のレベルのスケジューラ階層構造およびゲートウェイを含むことが可能であり、それぞれは異なるグリッド・サービス・スケジューラに接続される。ポータルがゲートウェイに接続され、このポータルが、ゲートウェイに沿ってクライアント要求をグリッド・サービス・スケジューラに渡す。
【００７６】
各コンテナ配列は、ローカル・エリア・ネットワーク内に常駐し、その結果、グリッド・コンテナ配列内のオブジェクト間の通信が、ローカル通信を構成する。グリッド・サービス・スケジューラは、クライアント要求をトランスペアレントな方法に従って分割し、その結果、クライアントがそのクライアント要求の分割に気付くことはない。これらのコンテナは、持続的なサービス・コンテナであり、それらが使用されて、複数のクライアント要求に及ぶ時間期間にわたって複数のクライアントの複数のクライアント要求が処理される。
【００７７】
また本発明は、ホストのコンピュータ・ネットワークにわたってクライアント要求を処理する方法を提供し、それには、ホスト内に持続的なコンテナを作成すること、コンテナ内にオブジェクトを作成すること、コンテナをグリッド・コンテナ配列にグループ化すること、単一グリッド・コンテナ配列内となるコンテナ内におけるオブジェクトを、グリッド・オブジェクト配列にグループ化すること、各グリッド・コンテナ配列用に１つのマイクロ・スケジューラを作成すること、クライアント要求のそれぞれを複数のタスクに分割すること、およびタスクのグループをマイクロ・スケジューラに割り当てることが含まれ、それにおいてマイクロ・スケジューラは、個別のタスクをオブジェクトに割り当てる。本発明は、マイクロ・スケジューラに、そのマイクロ・スケジューラが完了したタスクのグループを返すときに追加のタスクのグループを割り当てる。またこの方法に、ゲートウェイを介してクライアント要求を複数のグリッド・サービス・スケジューラに渡すことが含められるようにもできる。
【００７８】
このように上述の本発明は、グリッド・サービス・スケジューラを使用してクライアント要求を多くのタスクに分割する。このシステムは、前記タスクを、グリッド・オブジェクト配列内の複数のオブジェクトを介して実行するが、それらのオブジェクトは、１つのグリッド・コンテナ配列を構成するコンテナ内にあり、グリッド・コンテナ配列は、マイクロ・スケジューラによってコントロールされる。
【００７９】
本発明は、グリッドに関する要求レベル・スケジューリングの新しいアーキテクチャであるトポロジ・アウェア・グリッド・サービス・スケジューラ（Ｔｏｐｏｌｏｇｙ  Ａｗａｒｅ  Ｇｒｉｄ  Ｓｅｒｖｉｃｅｓ  Ｓｃｈｅｄｕｌｅｒ）（ＴＡＧＳＳ）を提供する。このアーキテクチャは、タスク・スケジューリング・インフラストラクチャが、多様なケイパビリティのコンピューティング・ホストならびにネットワークからなる多様なコンピューティング環境において動作するべく設計されることからトポロジ・アウェアである。この種の多様なコンピューティング環境は、グリッド・コンピューティングにおいては一般的であり、クラスタ・コンピューティングに通常に見られる一様な環境とは対照的である。つまり、クラスタ・コンピューティングにおいて使用されるスケジューリング・テクニックは、グリッド・コンピューティングに適していない。ＴＡＧＳＳのもう１つの重要な特徴は、それがサービス指向アーキテクチャを基礎としていることである。これは、クラスタ・スケジューリングがジョブ指向アーキテクチャを基礎としていることから、伝統的なクラスタ・スケジューリングと鋭く対立する。最近のオープン・グリッド・サービス・アーキテクチャ（Ｏｐｅｎ  Ｇｒｉｄ  Ｓｅｒｖｉｃｅ  Ａｒｃｈｉｔｅｃｔｕｒｅ）（ＯＧＳＡ）の紹介は、グリッド・コンピューティングの世界にサービス・ベースのアーキテクチャをもたらし、またそれとともにグリッド内におけるサービス要求のスケジューリングのタスクに関連する新しい課題をもたらしている。この開示は、これらの課題を論じており、それらをＴＡＧＳＳアーキテクチャにおける特徴に関連付けしている。
【００８０】
以上、本発明を好ましい実施態様に関して説明してきたが、当業者であれば付随する特許請求の範囲内ならびにその精神の中における修正を伴って本発明の実施が可能であることを認識されよう。
【図面の簡単な説明】
【００８１】
【図１】２つの異なる組織によって共有されるアーキテクチャを示した概略図である。
【図２】オンデマンドでコンテナを作成することができる本発明の機能を例示した概略図である。
【図３】各種のコンテナ内においてグリッド・オブジェクトが作成されることを例示した概略図である。
【図４】各種のオブジェクト間におけるインタラクションを示した概略図である。
【図５】本発明がどのようにしてグリッド・オブジェクト配列内のオブジェクトにタスクを転送するかについて例示した概略図である。
【図６】複合グリッド・コンテナ内の複数のクライアント・スケジューラを例示した概略図である。
【図７】複合グリッド・コンテナ内の複数のクライアント・スケジューラを例示した概略図である。
【図８】グリッド・ポータルを使用する階層スケジューリングを例示した概略図である。
【図９】グリッド・ポータルを使用する階層スケジューリングを例示した概略図である。
【図１０】グリッド内における本発明の展開を例示した概略図である。
【図１１】グリッド内における本発明の展開を例示した概略図である。
【符号の説明】
【００８２】
１２０  組織
１２１  組織
１２５  クラスタ
１２８  オブジェクト
１３０  グリッド・ゲートウェイ
１３２  クラスタ・スケジューラ
２００  ＴＡＧＳＳスケジューラ、サービス・スケジューラ、スケジューラ、スケジューラ・サービス
２０１  サービス・スケジューラ、スケジューラ
２０５  ＴＡＧＳＳエージェント
２１０  グリッド・ホスト、ノードのプール、ホスト
２１１  ホスト、異なるホスト
２１５  クライアント・プロセス
２１６  クライアント・プロセス
２２０  コンテナ、コンテナ・サービス
３００  コンテナ、コンテナ・サービス
３０１  コンテナ、コンテナ・サービス
３０２  コンテナ
３０３  コンテナ
３０４  コンテナ
３０５  コンテナ
３０６  オブジェクト配列、グリッド・オブジェクト配列
３０７  グリッド・コンテナ配列、コンテナ配列
３０８  グリッド・コンテナ配列
３０９  グリッド・コンテナ配列
４００  オブジェクト
４０１  オブジェクト
４０２  オブジェクト
４０３  オブジェクト
５００  ＴＡＧＳＳクライアント・スケジューラ、ＴＡＧＳＳマイクロ・スケジューラ、マイクロ・スケジューラ
５０１  ＴＡＧＳＳマイクロ・スケジューラ、ＴＡＧＳＳクライアント・スケジューラ
６００  ゲートウェイ、ゲートウェイ１
６０１  ゲートウェイ、ゲートウェイ２、第２のゲートウェイ
６０２  ゲートウェイ３
６０７  複合グリッド・オブジェクト配列
６０８  複合グリッド・コンテナ配列
７００  グリッド・ポータル
７０１  グリッド・ポータル
７０２  グリッド・ポータル
８００  アウトソーシング組織
【図１】
2004206712.tif 000004
【図２】
2004206712.tif 000005
【図３】
2004206712.tif 000006
【図４】
2004206712.tif 000007
【図５】
2004206712.tif 000008
【図６】
2004206712.tif 000009
【図７】
2004206712.tif 000010
【図８】
2004206712.tif 000011
【図９】
2004206712.tif 000012
【図１０】
2004206712.tif 000013
【図１１】
2004206712.tif 000014