JP2010218506A - 分散処理システム、コントロール・ユニット、及びクライアント - Google Patents

Abstract

【課題】システム制御機能をコントロール・ユニットとクライアントとで分散させて、制御機能による負荷集中を回避し、さらに、分散させて制御機能に関する設定もクライアントに割り当てることで、ユーザ側でシステム制御に関する設定を柔軟に行う。
【解決手段】ユーザから要求されたサービスの実行を要求するクライアントと、プロセッシング・エレメントと、クライアント及びプロセッシング・エレメントに接続されているコントロール・ユニットと、を備えた分散処理システムであって、コントロール・ユニットは分散処理システムを制御するための制御機能を有し、クライアントは、コントロール・ユニットの制御機能のうちの少なくとも１つの制御機能と同じ制御機能を有し、コントロール・ユニット及びクライアントの両方が有する制御機能の少なくとも１つについて、コントロール・ユニット及びクライアントの制御機能の少なくとも一方を選択して制御を実行する。
【選択図】図１

Description

本発明は、分散処理システム、コントロール・ユニット、及びクライアントに関するものである。

並列処理システムにおけるシステム制御では、与えられた処理を適当なタスクに分割し、分散している計算資源にタスクを割り当て、入出力を連携させてタスクのスケジューリングを行なう。さらには、実行時に取得した計算モジュールの動的状態をもとに、サブ処理の再配置や実行停止、再開などを行なう場合もある。

これらにより、負荷を分散させたり、あるいは消費電力の最適化を図ったりしながら、処理の効率化を実現する。このようなシステム制御機能を応用した並列処理システムとしては、例えば、特許文献１に提案されたシステムがある。並列処理システムにおいては、タスクのスケジューリング以外に、計算モジュールの登録・管理など多岐にわたる制御機能が必要となる。

特開２００２−７３６４号公報

従来の並列処理システムにおけるシステム制御機能の一つであるタスクのスケジューリングに関しては、スケジューラなどの専用機能がタスクのスケジューリングを行なっていた。システム全体の負荷分散と消費電力の低下を実現するために、スケジューラによる静的ないし動的なタスク割り当ては有効である。スケジューラを含むシステム制御機能を、単一のモジュールに割り当てるか、複数のモジュールに割り当てるかに関わらず、専用モジュールで実現するのが一般的である。

しかし、制御機能モジュール自身への負荷が集中した場合に、それらの制御機能自身を静的ないし動的に他のモジュールに再割り当てすることによって、負荷分散を実現することは困難であった。さらに、システム制御に関する設定はシステム制御モジュールで集中的に行なっており、ユーザ側で柔軟に行うことが困難であった。

本発明は、上記に鑑みてなされたものであって、システム制御機能モジュールであるコントロール・ユニットの全機能と同等の機能を発現できるクライアントを用意し、コントロール・ユニットの一部またはすべての機能を任意のタイミングで代替させ、システム制御の設定をクライアントで行うことのできるシステムを構築する。これにより、システム制御機能をコントロール・ユニットとクライアントとで分散させて、制御機能による負荷集中を回避し、さらに、制御機能に関する設定もクライアントに割り当てることで、ユーザ側でシステム制御に関する設定を柔軟に行うことを目的とする。

上述した課題を解決し、目的を達成するために、本発明に係る分散処理システムは、ユーザから要求されたサービスの実行を要求するクライアントと、プロセッシング・エレメントと、クライアント及びプロセッシング・エレメントに接続されているコントロール・ユニットと、を備えた分散処理システムであって、コントロール・ユニットは分散処理システムを制御するための制御機能を有し、クライアントは、コントロール・ユニットの制御機能のうちの少なくとも１つの制御機能と同じ制御機能を有し、コントロール・ユニット及びクライアントの両方が有する制御機能の少なくとも１つについて、コントロール・ユニット及びクライアントの制御機能の少なくとも一方を選択して制御を実行することを特徴としている。

本発明に係る分散処理システムでは、コントロール・ユニット及びクライアントの両方が有する制御機能の少なくとも１つについて、コントロール・ユニット及びクライアントのどちらかの制御機能を択一的に選択して制御を実行することが好ましい。

本発明に係る分散処理システムでは、コントロール・ユニット及びクライアントの両方が有する制御機能の少なくとも１つについて、コントロール・ユニット及びクライアントの両方の制御機能を用いて制御を実行することが好ましい。

本発明に係る分散処理システムでは、コントロール・ユニット及びクライアントの制御機能の選択は、あらかじめコントロール・ユニットに記憶された選択設定にしたがって、コントロール・ユニットが実行することが好ましい。

本発明に係る分散処理システムでは、コントロール・ユニット及びクライアントの制御機能の選択は、クライアントにサービスの実行を要求するユーザ又はそれ以外のユーザからの要求にしたがって、コントロール・ユニットが実行することが好ましい。

本発明に係る分散処理システムでは、コントロール・ユニットは、判断条件にしたがって、制御機能の選択の実行の承諾又は拒否を判断し、この判断結果に基づいて、制御機能の選択を実行することが好ましい。

本発明に係る分散処理システムでは、コントロール・ユニットは判断条件をあらかじめ記憶していることが好ましい。

本発明に係る分散処理システムでは、コントロール・ユニットは、クライアントにサービスの実行を要求するユーザ又はそれ以外のユーザからの要求にしたがって、判断条件を設定することが好ましい。

本発明に係る分散処理システムでは、コントロール・ユニットは、クライアントの制御機能が選択されている場合であっても、クライアントに制御コマンドを発行し、選択された制御機能に代えて、対応する自身の制御機能を強制的に選択することが好ましい。

本発明に係る分散処理システムでは、コントロール・ユニットは、クライアントの制御機能が選択されているか否かに関わらず、クライアントに制御コマンドを発行し、クライアントの制御機能を強制的に変更することが好ましい。

本発明に係る分散処理システムでは、コントロール・ユニットは、クライアントにサービスの実行を要求するユーザ又はそれ以外のユーザからの要求にしたがって、クライアントに制御コマンドを発行することが好ましい。

本発明に係る分散処理システムでは、コントロール・ユニットは、発行条件に従って自律的に、クライアントに制御コマンドを発行することが好ましい。

本発明に係る分散処理システムでは、クライアントは、クライアントの制御機能が選択されているか否かに関わらず、変更条件にしたがって、変更条件によって指定された制御機能を強制的に変更し、コントロール・ユニットに通知することが好ましい。

本発明に係る分散処理システムでは、変更条件は、クライアントの制御機能が選択されている場合に、コントロール・ユニットが設定すること、あるいは、あらかじめ記憶させておくことを含むことが好ましい。

本発明に係る分散処理システムでは、コントロール・ユニットは、クライアントからの通知があった場合に、通知にしたがって、自身の制御機能を再設定することが好ましい。

本発明に係る分散処理システムでは、変更条件は、クライアントの制御機能が選択されてからの制限時間、サービス実行環境の状況、サービス実行負荷の状況、計算資源使用状況、サービスの実行状況のうちの少なくとも１つを含むことが好ましい。

本発明に係る分散処理システムでは、制御機能は、制御機能に必要な情報の公開又は非公開を択一的に選択する機能を含むことが好ましい。

本発明に係る分散処理システムでは、公開を制限できる情報はプロセッシング・エレメントの状態を含むことが好ましい。

本発明に係る分散処理システムでは、公開を制限できる情報はスケジューリングポリシーを含むことが好ましい。

本発明に係る分散処理システムでは、制御機能は、計算資源の確保・解放、処理経路の確立・解放、プロセッシング・エレメントの状態のモニタリング、処理のスケジューリング、スケジューリングについてのスケジューリングポリシーの選択、サービスのタスク分解、プロセッシング・エレメントの登録・解除、及び、経路情報の記憶のうちの少なくとも１つを含むことが好ましい。

本発明に係る分散処理システムでは、クライアントは、コントロール・ユニットのすべての制御機能と同じ制御機能を備えることが好ましい。

本発明に係る分散処理システムでは、コントロール・ユニットのすべての制御機能について、クライアントの制御機能のみを用いて制御を実行することが好ましい。

本発明に係る分散処理システムでは、コントロール・ユニットのすべての制御機能について、コントロール・ユニットの制御機能のみを用いて制御を実行することが好ましい。

本発明に係る分散処理システムは、別の態様においては、ユーザから要求されたサービスの実行を要求するクライアントと、クライアントに接続されたプロセッシング・エレメントと、を備えた分散処理システムであって、クライアントが有する制御機能のみによって制御されることを特徴としている。

本発明に係る分散処理システムは、さらに別の態様においては、ユーザからのサービス要求を受ける機能を備えたコントロール・ユニットと、コントロール・ユニットに接続されたプロセッシング・エレメントと、を備えた分散処理システムであって、コントロール・ユニットが有する制御機能のみによって制御されることを特徴としている。

本発明に係るコントロール・ユニットは、ユーザから要求されたサービスの実行を要求するクライアント、及び、プロセッシング・エレメントとともに分散処理システムを構成し、分散処理システムを制御する制御機能を有するコントロール・ユニットであって、コントロール・ユニット及びクライアントの両方が有する制御機能の少なくとも１つについて、制御の実行のために、コントロール・ユニット及びクライアントの制御機能の少なくとも一方を選択することを特徴としている。

本発明に係るクライアントは、分散処理システムを制御する制御機能を有するコントロール・ユニットに接続され、ユーザから要求されたサービスの実行を要求するクライアントであって、コントロール・ユニットの制御機能のうちの少なくとも１つの制御機能と同じ制御機能を有し、コントロール・ユニット及びクライアントの両方が有する制御機能の少なくとも１つについて、コントロール・ユニットによって選択された制御機能を用いた制御を実行することを特徴としている。

本発明に係る分散処理システム、コントロール・ユニット、及びクライアントは、システム制御機能をコントロール・ユニットとクライアントとで分散させて、制御機能による負荷集中を回避し、さらに、分散させて制御機能に関する設定もクライアントに割り当てることで、ユーザ側でシステム制御に関する設定を柔軟に行うことができる、という効果を奏する。

本発明の実施形態に係る分散処理システムの構成例を示す図である。 本発明の実施形態に係るアプリケーションの処理の流れを示すフローチャートである。 図２に示すサービスと、サービスを構成するタスクと、を対応させた表である。 実行遷移情報を構成する情報の例と、各構成情報のデータ例と、をそれぞれ示す表である。 図４に示す実行遷移情報の構成に対応したシステムのモデル例を示す図である。 本発明の実施形態に係る分散処理システムにおける制御機能の例を示す表である。 制御機能の第１の選択設定例を示す表である。 制御機能の第２の選択設定例を示す表である。 制御機能の第３の選択設定例を示す表である。 制御機能の第４の選択設定例を示す表である。 制御機能の第５の選択設定例を示す表である。 スケジューリングポリシー管理におけるポリシーＩＤとステータスの例を示す表である。 ＰＥ情報管理におけるＰＥ基本情報とステータスの例を示す表である。 すべての制御機能の選択設定がコントロール・ユニットとなっている例の処理の流れを示す図である。 一部の制御機能の選択設定がクライアント、残りの選択設定がコントロール・ユニットとなっている例の処理の流れを示す図である。 すべての制御機能の選択設定がクライアントとなっている例の処理の流れを示す図である。 制御コマンドによる強制選択変更の処理の流れを示すフローチャートである。 変更条件によるによる強制選択変更の流れを示すフローチャートである。

以下に、本発明に係る分散処理システム、コントロール・ユニット、及びクライアントの実施形態を図面に基づいて詳細に説明する。なお、以下の実施形態によりこの発明が限定されるものではない。

まず、本実施形態に係る処理モデルについて図１を参照して説明する。図１は、本実施形態に係る分散処理システムの構成例を示す図である。

図１に示すように、アプリケーション（サービス）の実行を要求するクライアント２１、システム全体の制御を行うコントロール・ユニット（以下、ＣＵと省略することがある）１１、および、計算モジュールであるプロセッシング・エレメント（以下、ＰＥと省略することがある）３１から３ｎから分散処理システムが構成される。クライアント２１は、ＰＥの一種であり、計算を行わせることも可能である。

ここで、ＰＥを識別するＩＤをＰＥＩＤと呼ぶ。ＰＥはタスクの処理に特化した機能を有しており、この機能を識別するＩＤを機能ＩＤと呼ぶ。

次に、アプリケーション実行例について図２を参照して説明する。図２は、アプリケーションの処理の流れを示すフローチャートである。この例では、ＪＰＥＧデコード処理を取り上げる。

ＪＰＥＧデコード処理は、図２に示すように、ＪＰＥＧファイル解析（ステップＳ１０１）、エントロピー複合化（ステップＳ１０２）、逆量子化（ステップＳ１０３）、ＩＤＣＴ（ステップＳ１０４）、アップサンプリング（ステップＳ１０５）、及び、色信号の変換（ステップＳ１０６）の６つの連続した処理に分割することが可能である。

ここで、ＪＰＥＧデコード処理のようにユーザが処理要求するアプリケーションをサービスと呼び、ＪＰＥＧデコード処理を構成するエントロピー復号化のようなサブ処理をタスクと呼ぶ。

サービス、タスクにはそれぞれの処理内容を識別するためにサービスＩＤおよびタスクＩＤが一意に割り当てられている。ＪＰＥＧデコード処理のサービスＩＤはＳＶ−８２３、ＪＰＥＧデコード処理を構成する各タスクのタスクＩＤをＴＫ−１０１からＴＫ−１０６とする。

クライアント２１がサービスとしてＪＰＥＧデコード処理の実行を要求すると、コントロール・ユニット１１は、たとえば図３に示すサービス―タスク対応表に従って、ＴＫ−１０１からＴＫ−１０６タスクの列に分解する。図３は、図２に示すサービスと、サービスを構成するタスクと、を対応させた表である。

タスクは、実行可能な各ＰＥに割り当てられる。ＰＥ間の経路は一意にその入出力が定められており、入出力のペアに経路のＩＤとしてパスＩＤが決められる。コントロール・ユニット１１はこの処理経路の構成に関する情報（実行遷移情報）を生成する。実行遷移情報の例を図４に示す。図４は、実行遷移情報を構成する情報の例と、各構成情報のデータ例と、をそれぞれ示す表である。

実行遷移情報は、例えば、実行するサービスのＩＤを含むＩＤ情報とサービス処理のための経路情報とから構成されており、さらにＰＥセクションとパスセクションで構成されている。ＰＥセクションは機能を提供するＰＥのＰＥＩＤと機能ＩＤを含み、パスセクションはデータ送信側（ソース）およびデータ受信側（デスティネーション）のＰＥＩＤおよびそれらのＰＥ間の経路のＩＤ（パスＩＤ）を含む。

例えば、図４に示す実行遷移情報に従って、ＪＰＥＧデコードを行う処理経路を図５のように構成できる。図５は、図４に示す実行遷移情報の構成に対応したシステムのモデル例を示す図である。
その後、処理に必要な計算資源の割り当てと処理経路の確立を行う。

つづいて、本実施形態に係る分散処理システムにおける制御機能について説明する。
まず、制御機能の種類について図６を参照して説明する。図６は、本実施形態の分散処理システムにおける制御機能の例を示す表である。図６では、制御機能ＩＤと、対応する制御機能と、を示している。

本システムの制御機能として、例えば、図６のように制御機能ＩＤＣＦ−０１からＣＦ−１２と対応付けられる１２種の制御機能が挙げられる。
以下に各制御機能について説明する。

ＣＦ−０１に対応する「実行遷移情報キャッシュ」は、実行遷移情報をローカルにキャッシュしておく機能である。

ＣＦ−０２に対応する「サービス―タスク列分解」は、サービスを一つ以上の連続したタスクの列に対応づける機能である。

ＣＦ−０３に対応する「スケジューリング（実行遷移情報生成）」は、サービス処理に必要なタスクを実行できる機能を持つ最適なＰＥをスケジューリングポリシーに則って選択し、それらの実行順序と入出力関係を決定する機能である。

ＣＦ−０４に対応する「スケジューリングポリシー管理」は、実行遷移情報を生成する指針であるスケジューリングポリシーの公開を含む情報の管理を行う機能である。

ＣＦ−０５に対応する「ＰＥ状態モニタリング」は、ＰＥの実行状態特に実行時の動的情報を取得する機能である。

ＣＦ−０６に対応する「ＰＥ情報管理」は、ＰＥの仕様などを含む静的情報の公開を含む情報の管理を行う機能である。

ＣＦ−０７に対応する「計算資源確保要求」は、実行遷移情報に従って、タスクを実行するために必要な計算資源となるＰＥのメモリなどを確保するようにＰＥに要求する機能である。

ＣＦ−０８に対応する「処理経路確立要求」は、実行遷移情報に従って、ＰＥとＰＥ間およびＰＥとクライアント間の処理経路を確立するように要求する機能である。

ＣＦ−０９に対応する「計算資源解放要求」は、サービス処理の終了後に、使用した計算資源を、他のサービス処理に使用できるように解放するよう要求する機能である。

ＣＦ−１０に対応する「処理経路解放要求」は、サービス処理の終了後に、使用した処理経路を、解放するように要求する機能である。

ＣＦ−１１に対応する「ＰＥ登録」は、ＰＥの起動時などにＣＵに接続されているＰＥの機能などを登録する機能である。

ＣＦ−１２に対応する「ＰＥ登録解除」は、登録されているＰＥの情報を消去または無効とし登録を解除する機能である。

つづいて、制御機能の選択設定について、図７から図１１を参照して説明する。
本実施形態の分散処理システムでは、クライアント２１もＣＵ１１と同等の制御機能を発現させることができる。すなわち、クライアント２１は、ＣＵ１１が備える制御機能をすべて備えている。したがって、クライアントとＣＵのどちらか一方ないしは両方が各制御機能をＣＵ管理下で選択することによって、制御機能の分担を行うことができる。以下の説明では、制御機能の選択設定を模式的に図７から図１１に示すような表形式で図示するが、実施形態はこれに限定されるものではない。

また、本発明の分散処理システムは、本実施形態のように、ＣＵ１１が備える制御機能をクライアント２１がすべて備える場合に限定されることなく、ＣＵ１１が備える制御機能の少なくとも１つをクライアントが備える場合に適用できる。

図７は、制御機能の第１の選択設定例を示す表である。図７から図１１において、ＣＬはクライアント２１、ＣＵはコントロール・ユニット１１にそれぞれ対応し、制御機能の選択を丸印によって示している。

第１の選択設定例では、全制御機能の選択設定はＣＵとなっており、すべてのシステム制御をコントロール・ユニット１１が行う。

ＣＵは、制御機能の選択設定の一部または全部をＣＬとすることが可能である。例えば、図８に示すように、ＣＦ−０１からＣＦ−１０の選択設定をＣＬに移動することができる。図８は、制御機能の第２の選択設定例を示す表である。

これに対して、図９に示すように、ＣＦ−０１からＣＦ−０６の選択設定をＣＬに移動することもできる。図９は、制御機能の第３の選択設定例を示す表である。

図１０は、制御機能の第４の選択設定例を示す表である。
第４の選択設定例では、すべての制御機能の選択設定をＣＬとしている。

上述の第１から第４の選択設定例では、制御機能はクライアント２１かＣＵ１１に対して択一的に選択していたが、一部の機能に関して、クライアント２１とＣＵ１１の双方とも選択してもよい。
例えば、図１１に示すように、ＰＥ状態モニタリング（ＣＦ−０５）についてはクライアント２１とＣＵ１１の双方からＰＥをモニタし情報を取得しても構わない。ここで、図１１は、制御機能の第５の選択設定例を示す表である。

なお、ＣＦ−０４（スケジューリングポリシー管理）、ＣＦ−０６（ＰＥ情報管理）のように制御機能に必要な情報公開を含む情報管理機能については適切な制御機能（ここではＣＦ−０３、ＣＦ−０５に該当）と組み合わせて使用することが好ましいが、クライアント２１でＣＦ−０４（スケジューリングポリシー管理）を実行し、ＣＵ１１がＣＦ−０３（スケジューリング）を実行するというように、クライアント２１とＣＵ１１でＣＦ−０３とＣＦ−０４を分担してもよい。ＰＥ情報管理についても、クライアント２１とＣＵ１１でＣＦ−０５とＣＦ−０６を分担することができる。ただし、場合によっては、制御機能に必要な情報をクライアント２１とＣＵ１１の間でやり取りする必要がある。

つづいて、制御機能に必要な情報について、図１２、図１３を参照して説明する。
制御機能の一部にはその機能を発現するために必要な情報がある。ＣＵ１１が制御機能の選択設定をクライアント２１とした場合は、それらの情報を公開する必要がある。そのとき、ＣＵ１１はそれらの情報の一部またはすべての公開を制限することができる。その他、制御機能に必要な情報の公開を含む管理機能も制御機能として組み込む。
以下、上述のＣＦ−０４（スケジューリングポリシー管理）、ＣＦ−０６（ＰＥ情報管理）を例に挙げて説明する。

図１２は、スケジューリングポリシー管理におけるポリシーＩＤとステータスの例を示す表である。
制御機能ＣＦ−０３のスケジューリングを行うためには、スケジューリングの指針となるスケジューリングポリシーを選択する必要がある。ＣＦ−０４はシステムに登録されているスケジューリングポリシーのリストを公開するなどスケジューリングポリシーの管理機能を示している。

この例では、
（ａ）消費電力を最適化し低消費電力で実行できる処理経路を構築するポリシー
（ｂ）処理性能を最大化するポリシー
（ｃ）ＰＥ間の通信性能を最大化しネットワーク距離を最適化するポリシー
（ｄ）プライバシーを保護するポリシー
の４つのポリシーが提供される。（ａ）、（ｂ）、（ｃ）、（ｄ）の各ポリシーは、ＰＬ−１０（消費電力最適化）、ＰＬ−１１（処理性能最適化）、ＰＬ−１２（ネットワーク距離最適化）、ＰＬ−１３（プライバシー優先）のＩＤでそれぞれ識別できる。

このときに、ＣＵ１１は、システム全体が過負荷となるのを回避する目的で、クライアント２１が処理性能を最大化するポリシーＰＬ−１１を使って処理経路を構築するのを制限するために、ＰＬ−１１のステータスを使用不可とする。一方、ＣＵ１１は、その他３つのポリシーについては使用可能として情報を提供する（図１２）。

図１３は、ＰＥ情報管理におけるＰＥ基本情報とステータスの例を示す表である。
上述のスケジューリングポリシー管理と同様に、ＣＦ−０３のスケジューリングを行うときに処理経路に組み込むＰＥの情報をモニタリングする必要がある。ＣＦ−０６に対応するＰＥ情報管理の情報として、スケジューリングに必要なＰＥの情報を、例えば、クライアント２１に選択設定を移す前のＰＥの情報として図１３のような表形式で提供する。

図１３に示すＰＥの情報には、ＰＥＩＤ、機能ＩＤ、ＰＥのアーキテクチャ、残メモリ容量、過去の平均負荷、接続アドレスなどが含まれる。さらに、使用権限のステータスが含まれる。このとき経路への組み込みを制限したいＰＥのステータスを使用不可として指示できる。ＣＦ−０６は、これらのＰＥに関する情報を管理する機能である。

なお、ＰＥ情報管理の情報は、図１３に示す情報に限定されることはなく、さらに、提供の形態は図１３のような表形式に限定されない。

また、制御機能ＣＦ−０５のＰＥ状態のモニタリングを実現するためにもこれらの情報（各ＰＥのＩＤや接続アドレス）が必要となる場合もある。この場合、モニタリングを制限したいＰＥは公開不可とし、リストそのものを提供しないという制限を可能とするとよい。
例えば、一定以上使用料を払っているユーザが使用するクライアント２１にだけ高性能なＰＥを公開する場合である。

さらに、使用不可のＰＥはモニタリング可能とし、処理経路への組み込みは不可とするとよい。また、公開不可のＰＥはモニタリングも処理経路への組み込みも不可とすることが好ましい。

次に、本実施形態の分散処理システムによる処理の流れについて、図１４から図１６に示す例を挙げて説明する。図１４から図１６において、「クライアント」はクライアント２１を、「コントロール・ユニット」はコントロール・ユニット１１を、「ＰＥ」はＰＥ３１からＰＥ３ｎのうちの対応するＰＥを、それぞれ示す。

図１４は、すべての制御機能の選択設定がＣＵ１１となっている例の処理の流れを示す図である。この例の制御機能の選択設定は、図７の選択設定に対応している。

ステップＳ１０００では、クライアント２１はＣＵ１１にサービスの実行を要求する。例えば要求するサービスを特定する方法として、サービスＩＤを送信する。

ステップＳ１０１０では、ＣＵ１１は以前に使用した実行遷移情報を格納したキャッシュから該当するサービスに対応するエントリを検索する。キャッシュにヒットした場合は、ステップＳ１０４０に進む。

ステップＳ１０２０では、キャッシュにヒットしなければ、図３に示すようなサービスとタスクの対応を格納したデータベースにアクセスし、ステップＳ１０３０では、サービスをタスク列に分解する。

ステップＳ１０４０では、ＣＵ１１は定期的にＰＥの状態をモニタリングし、動的情報として処理負荷やメモリの使用率を把握する。このほかに、ＣＵ１１は、静的情報としてＰＥのシステム構成情報を取得している。便宜上、ＰＥの状態モニタリングはＳ１０３０とＳ１０５０の間に設けているが、ＣＵ１１は任意のタイミングでＰＥの状態をモニタリングできる。

ステップＳ１０５０では、ＰＥの状態を勘案しながら、スケジューリングポリシーを使用して実行遷移情報を生成する。

ステップＳ１０６０では、生成した実行遷移情報をキャッシュに保存する。

ステップＳ１０７０では、ステップＳ１０６０の後、処理経路を構成する各ＰＥに対して、計算資源確保の要求を送信すると同時に実行遷移情報を送信する。各ＰＥはデータ処理に必要な計算資源としてメモリなどを確保する。なお、実行遷移情報自体を計算資源確保の要求として取り扱ってもよい。以降、要求などの制御信号を制御に必要な情報と区別して記述するが、それらを同一視しても構わない。

クライアント２１もＰＥの一種としてデータ処理機能を提供することも可能だが、この例では、説明の簡略化のため、クライアント２１はデータ処理を行わず、ＪＰＥＧ処理における画像データの入出力処理のみを行うものとして、計算資源確保の要求を省略している。

ステップＳ１０８０、Ｓ１０９０では、処理経路を構成する各ＰＥおよびクライアント２１に対して処理経路確立をそれぞれ要求する。各ＰＥおよびクライアント２１は処理経路上隣接するＰＥとの処理経路を確立する。

ステップＳ１１００では、クライアント２１とＰＥを接続する処理経路が確立すると、ＣＵ１１がクライアント２１に処理開始要求を送信する。

ステップＳ１１１０、Ｓ１１２０では、クライアント２１およびＰＥはサービスの実行に必要な処理を行なう。具体的には、クライアントから入力されたデータをＰＥが処理し、処理経路に沿って次のＰＥに出力する。最後のＰＥまでデータの処理と伝達を繰り返し、最後にクライアントが処理結果を受け取る。ただし、実施形態によっては、クライアントのデータ入出力は必須ではなく、データの入出力も他のＰＥに実行させる実施形態も考えられる。

ステップＳ１１３０では、クライアント２１は処理が完了するとＣＵ１１に通知する。

ステップＳ１１４０、Ｓ１１５０では、ＣＵ１１は処理経路の解放を各ＰＥおよびクライアント２１にそれぞれ要求する。

ステップＳ１１６０では、同様にＣＵ１１は計算資源の解放を各ＰＥに要求する。

ステップＳ１１７０では、ＣＵ１１はサービス実行完了をクライアント２１に送信し、サービスの実行を終了する。

図１５は、一部の制御機能の選択設定がクライアント２１、残りの選択設定がＣＵ１１となっている例の処理の流れを示す図である。

ステップＳ２０００では、クライアント２１は制御機能の選択設定をＣＵ１１に要求する。

ステップＳ２０１０では、ＣＵ１１はクライアント２１での実行が可能な制御機能を選択設定した情報をクライアント２１に送信する。例えば、図６のＣＦ−０１からＣＦ−１０の制御機能をクライアント２１で実行可能、または許可できる、と判断し、図８の情報を送信する。これと同時に制御機能に必要な関連情報のリストを送信する。

ステップＳ２０１１では、クライアント２１は制御機能および必要な関連情報を選択し、制御機能の選択設定を必要に応じて書き換える。

ステップＳ２０２０では、選択設定完了をＣＵ１１に通知し、制御機能および関連情報の選択結果を送信する。例えばＣＦ−０１からＣＦ−０６までの制御機能を選択し、図９の情報をＣＵ１１に返送する。それらに必要な関連情報の選択結果として、たとえばスケジューリングポリシーＰＬ−１０を選択したことを通知する。実際にはＰＬ−１０とＰＬ−１３を同時に選択するなど複合的な設定を選択し通知することもある。

ステップＳ２０２１では、ＣＵ１１は選択結果が判断条件を満たしているかどうかを判断する。使用不可の機能や情報を選択していたり、あるいは組み合わせ不可の設定を選択したりしている場合など、判断条件を満たしていない場合は選択設定を拒否する。判断条件を満たしている場合は選択設定を承諾する。判断条件は機器の製造時などにあらかじめ組み込んでおくことも可能であるし、ユーザの要求などを通じて実行時にＣＵ１１に設定することも可能である。ユーザはサービス実行要求を発行したユーザである必要はない。

ステップＳ２０３０では、ＣＵ１１は選択結果の判断結果をクライアント２１に通知する。ステップＳ２０３１では、必要に応じてスケジューラなどの関連情報を送信する。スケジューラは例えばプログラムモジュールやハードウェアの配線情報として提供される。

選択設定が承諾された場合は、クライアント２１はＣＦ−０１からＣＦ−０６の制御機能をＣＵ１１に代わり実行する。ステップＳ２０４０では、まず、ユーザが要求するサービスに対して実行遷移情報を生成するために、キャッシュしている実行遷移情報にアクセスする。キャッシュにヒットした場合はステップＳ２０７０に進む。

これに対して、キャッシュをミスした場合は、ステップＳ２０５０において、サービスを連続したタスク列と対応付けるデータベースにアクセスし、ステップＳ２０６０において、対応するタスク列を得る。

ステップＳ２０７０では、クライアント２１はＣＵ１１から得たＰＥの基本情報をもとに、ＰＥの状態を定期的に状態をモニタリングしている。便宜上、ＰＥの状態モニタリングはＳ２０６０とＳ２０８０の間に設けているが、クライアント２１は任意のタイミングでＰＥの状態をモニタリングできる。

ステップＳ２０８０では、クライアント２１は、タスク列の実行に必要なＰＥについて、モニタリングで得たＰＥの状態、スケジューリングポリシーによって実行遷移情報を生成する。

ステップＳ２０９０では、クライアント２１は、生成した実行遷移情報をキャッシュに保存する。

ステップＳ２１００では、クライアント２１は、生成した実行遷移情報とともにサービス実行要求をＣＵ１１に送信する。

ステップＳ２１１０では、ＣＵ１１は、受信した実行遷移情報をもとに必要なＰＥに対して、メモリなど計算資源の確保を要求し、同時に実行遷移情報を送信する。ここで、クライアント２１もＰＥの一種としてデータ処理機能を提供することも可能だが、この例では、説明の簡略化のためクライアント２１はデータ処理を行わず、ＪＰＥＧ処理における画像データの入出力処理のみを行うものとして、計算資源確保の要求を省略する。

ステップＳ２１２０、Ｓ２１３０では、ＣＵ１１は、各ＰＥおよびクライアント２１に対して、処理経路上の隣接するＰＥおよびクライアント２１との処理経路の確立をそれぞれ要求する

ステップＳ２１４０では、処理経路が確立すると、ＣＵ１１はクライアント２１に対して処理の開始を要求する。

ステップＳ２１５０、Ｓ２１６０では、クライアント２１および各ＰＥは入出力処理およびデータ処理を行う。具体的には、クライアント２１から入力されたデータをＰＥが処理し、処理経路に沿って次のＰＥに出力する。最後のＰＥまでデータの処理と伝達を繰り返し、最後にクライアント２１が処理結果を受け取る。ただし、実施形態によっては、クライアント２１のデータ入出力は必須ではなく、データの入出力も他のＰＥに実行させる実施形態も考えられる。

ステップＳ２１７０では、処理が完了すると、クライアント２１はＣＵ１１に完了を通知する。

ステップＳ２１８０、Ｓ２１９０では、ＣＵ１１は、処理経路の解放を各ＰＥとクライアント２１にそれぞれ要求する。

ステップＳ２２００では、計算資源の解放を各ＰＥに要求する。

最後に、ステップＳ２２１０では、ＣＵ１１は、サービスの実行完了をクライアント２１に送信する。

本例では、クライアント２１が要求するシステム制御の選択設定は、製造時などにあらかじめ組み込んでおくことも可能であるし、ユーザの要求などを通じて実行時にクライアント２１を通じて要求することも可能である。ユーザはサービス実行要求を発行したユーザである必要はない。

あるいは、クライアント２１とＣＵ１１で固定された選択設定を使用するなど、使用する選択設定が予め分かっている場合には、Ｓ２０００からＳ２０３１までのステップを省略することができる。

あるいは図１４のＳ１０００の前に、図１５のＳ２０００からＳ２０３１までのステップを挿入し、クライアント２１から選択設定要求をした上で全制御機能をＣＵ１１に実行させてもよい。

図１６は、すべての制御機能の選択設定がクライアント２１となっている例の処理の流れを示す図である。この例の制御機能の選択設定は、図１０の選択設定に対応している。

ステップＳ３０００では、クライアント２１は制御機能の選択設定をＣＵ１１に要求する。

ステップＳ３０１０では、ＣＵ１１はクライアント２１での実行が可能な制御機能を選択設定した情報をクライアント２１に送信する。本例ではすべての制御機能をクライアント２１で実行可能と判断し、図１０の情報を送信する。ＣＵ１１は、選択設定した情報の送信と同時に、制御機能に必要な関連情報のリストを送信する。

ステップＳ３０１１では、クライアント２１は制御機能および必要な関連情報を選択し、制御機能の選択設定を必要に応じて書き換える。本例では、選択設定の変更はしないので、書き換える必要はない。

ステップＳ３０２０では、クライアント２１は、選択設定完了をＣＵ１１に通知し、制御機能および関連情報の選択結果を送信する。使用できるすべての制御機能を選択し、図１０の情報をＣＵ１１に返送する。

ステップＳ３０２１では、ＣＵ１１は選択結果が判断条件を満たしているかどうかを判断する。判断条件は機器の製造時などにあらかじめ組み込んでおくことも可能であるし、ユーザの要求などを通じて実行時にＣＵ１１に設定することも可能である。ユーザはサービス実行要求を発行したユーザである必要はない。

ＣＵ１１は、ステップＳ３０３０では選択結果の判断結果をクライアント２１に通知し、ステップＳ３０３１では必要に応じてスケジューラなどの関連情報を送信する。スケジューラは例えばプログラムモジュールやハードウェアの配線情報として提供される。

選択設定が承諾された場合は、クライアント２１はすべての制御機能をＣＵ１１に代わり実行する。ステップＳ３０４０では、まず、ユーザが要求するサービスに対して実行遷移情報を生成するために、キャッシュしている実行遷移情報にアクセスする。キャッシュにヒットした場合はステップＳ３０７０に進む。

ステップＳ３０４０でキャッシュをミスした場合は、ステップＳ３０５０においてサービスを連続したタスク列と対応付けるデータベースにアクセスし、ステップＳ３０６０において対応するタスク列を得る。

ステップＳ３０７０では、クライアント２１は、ＣＵ１１から得たＰＥの基本情報をもとに、ＰＥの状態を定期的に状態をモニタリングしている。便宜上、ＰＥの状態モニタリングはＳ３０６０とＳ３０８０の間に設けているが、クライアント２１は任意のタイミングでＰＥの状態をモニタリングできる。

ステップＳ３０８０では、クライアント２１は、タスク列の実行に必要なＰＥについて、モニタリングで得たＰＥの状態、スケジューリングポリシーによって実行遷移情報を生成する。

ステップＳ３０９０では、クライアント２１は、生成した実行遷移情報をキャッシュに保存する。

ステップＳ３１００では、クライアント２１は、生成した実行遷移情報に従って、処理経路を構成する各ＰＥに対してメモリなどの計算資源確保を要求する。

ステップＳ３１１０では、クライアント２１は、生成した実行遷移情報に従って、処理経路を構成する各ＰＥに対して処理経路の確立を要求する。このとき、クライアント２１は、自分自身に対しては要求する必要はないが、ＰＥとの経路確立を行う。

ステップＳ３１２０、Ｓ３１３０では、クライアント２１および各ＰＥで、サービス実行のための入出力処理およびデータ処理をそれぞれ行う。具体的には、クライアント２１から入力されたデータをＰＥが処理し、処理経路に沿って次のＰＥに出力する。最後のＰＥまでデータの処理と伝達を繰り返し、最後にクライアント２１が処理結果を受け取る。ただし、実施形態によっては、クライアント２１のデータ入出力は必須ではなく、データの入出力も他のＰＥに実行させる実施形態も考えられる。

ステップＳ３１４０では、処理終了後に、クライアント２１は、各ＰＥに対して処理経路の解放を要求する。このとき、クライアント２１は、自分自身とＰＥとの処理経路の解放も行う。

さらに、ステップＳ３１５０では、計算資源の解放を各ＰＥに要求する。クライアント２１は自分自身でサービスの実行を要求したため、サービスの実行完了をどこかに通知する必要はなく、サービスの実行を完了する。

本例では、クライアント２１が要求するシステム制御の選択設定は、製造時などにあらかじめ組み込んでおくことも可能であるし、ユーザの要求などを通じて実行時にクライアント２１を通じて要求することも可能である。ユーザはサービス実行要求を発行したユーザである必要はない。

あるいは、クライアント２１とＣＵ１１で固定された選択設定を使用するなど、使用する選択設定が予め分かっている場合には、Ｓ３０００からＳ３０３１までのステップを省略することができる。

次に、制御機能の強制選択変更について、図１７、図１８を参照して説明する。
コントロール・ユニット１１は、システム全体を効率的に秩序立てて管理するために、必要に応じてクライアント２１に対して強制的に選択設定を変更することができる。

強制選択変更とは、
（Ａ）クライアント２１から制御機能を取り戻すこと、及び、
（Ｂ）クライアント２１に強制的に制御機能を持たせること、
を含む。

強制選択変更の方法は、
（１）ＣＵ１１から制御コマンドを発行して選択設定を変更する方法と、
（２）変更条件を設定し、この変更条件を満たしたときに選択設定を変更する方法と、がある。

制御コマンドの発行は、ユーザからの要求による場合と、発行条件を満たしたときに自律的に発行する場合と、がある。発行条件は、例えば、ＣＵ１１の処理負荷が大きい場合に、制御機能を強制的に分散させたいときに、「ＣＵ１１の処理負荷が６０％を超えた時にはＣＦ−０７からＣＦ−１０までの制御機能の選択設定を強制的にクライアント２１へ移す」などと設定する。ユーザはサービス実行要求を発行したユーザである必要はない。

ただし、使用時にクライアント２１の処理負荷や過去の強制選択変更の履歴などから複合的に判断することが好ましい。

変更条件は、機器の製造時などに予め組み込んでおくことも可能であるし、ユーザの要求などを通じてＣＵ１１が実行時に設定することも可能である。ユーザはサービス実行要求を発行したユーザである必要はない。変更条件としては、以下の例が挙げられる。
（１）クライアント２１の制御機能が選択されてからの制限時間
（２）サービス実行環境の状況。例えば、停電などによる実行時の電源電圧低下などによるものである。
（３）サービス実行負荷の状況。例えば、ＣＰＵの負荷などによるものである。
（４）計算資源使用状況。例えば、メモリの使用残量などによるものである。
（５）サービス実行状況。例えば、サービスの実行が終わったら、などの状況である。

コントロール・ユニット１１は、上記変更条件（１）から（５）により、ＣＵ１１に制御機能を返させる、または追加することができる。

ここで、上記いずれの場合においても、変更条件によるクライアント２１からの強制選択変更と、ＣＵ１１からの変更条件の変更あるいは制御コマンドと、が互いに競合した場合は、ＣＵ１１からの指示を優先とし、ＣＵ１１が常にシステム制御における優位を保てるようにしておくことが好ましい。

つづいて、図１７を参照して、制御コマンドによる強制選択変更の流れについて説明する。図１７は、制御コマンドによる強制選択変更の処理の流れを示すフローチャートである。

ステップＳ４０００では、ＣＵ１１はユーザから制御機能の強制選択要求を受信したかどうか確認する。ユーザはサービス実行要求を発行したユーザである必要はない。ＣＵ１１が強制選択要求を受信したら（ステップＳ４０００でＹＥＳ）、ステップＳ４０２０へ進む。

ＣＵ１１が強制選択要求を受信していない場合（ステップＳ４０００でＮＯ）、ＣＵ１１は、ステップＳ４０１０において、強制選択要求の発行条件を満たしているかどうかを判断する。発行条件を満たしていないと判断した場合（ステップＳ４０１０でＮＯ）は、ステップＳ４０００へ戻る。Ｓ４０００とＳ４０１０の順序は任意であって優先順位を示すものではない。なお、ＣＵ１１は他の機能を実行しながら並行してＳ４０００およびＳ４０１０の判断ができるものとする。

ユーザから制御機能の強制選択要求を受信した場合（ステップＳ４０００でＹＥＳ）、または、強制選択要求の発行条件を満たしている場合（ステップＳ４０１０でＹＥＳ）、ステップＳ４０２０において、ＣＵ１１は、クライアント２１に強制選択要求を発行する。

強制選択要求として、例えばすべての制御機能をＣＵ１１に取り戻したい場合は、ＣＵ１１は、図７の選択設定を強制選択要求に付随する情報としてクライアント２１に送信する。

ステップＳ４０３０では、送信された強制選択要求に対して、クライアント２１は強制的に選択設定を書き換える。

ステップＳ４０４０では、さらに必要に応じて、クライアント２１は、最新の関連情報をＣＵ１１に送信する。

ＣＵ１１は、ステップＳ４０５０では関連情報を変更し、ステップＳ４０５１では、関連情報の変更完了をクライアント２１に通知する。

その後、ステップＳ４０６０において、クライアント２１は、選択設定変更が完了したことをＣＵ１１に通知する。

ステップＳ４０７０では、ＣＵ１１は制御機能の選択設定を変更する。

最後に、ステップＳ４０８０では、ＣＵ１１は、クライアント２１に選択設定変更の完了を通知する。

つづいて、図１８を参照しつつ、変更条件による強制選択変更について説明する。図１８は、変更条件による強制選択変更の流れを示すフローチャートである。

ステップＳ５０００では、ＣＵ１１は変更条件の設定要求をクライアント２１に送信する。

これに対して、ステップＳ５０１０では、クライアント２１は変更条件を設定し記憶しておく。

その後、ステップＳ５０２０では、クライアント２１は、変更条件の設定が完了したことをＣＵ１１に通知する。

ステップＳ５０３０では、クライアント２１は変更条件を満たしているかどうか判断する。満たしていないと判断した場合（ステップＳ５０３０でＮＯ）、満たすまで選択設定を維持する。なお、クライアント２１は他の機能を実行しながら並行してＳ５０３０の判断ができるものとする。

クライアント２１は、変更条件を満たしたと判断した場合（ステップＳ５０３０でＹＥＳ）は、ステップＳ５０４０において、変更する制御機能の関連情報があれば、ＣＵ１１に送信する。

関連情報を受信したＣＵ１１は、ステップＳ５０５０では、関連情報を変更し、ステップＳ５０５１では、関連情報の変更の完了をクライアント２１に通知する。

クライアント２１は、関連情報の変更完了の通知を受け取ったら、ステップＳ５０５２においてクライアント２１側の選択設定を変更する。

その後、クライアント２１は、ステップＳ５０６０において、変更した選択設定をＣＵ１１に送信する。

ステップＳ５０７０では、選択設定を受信したＣＵ１１は、選択設定を変更する。

変更が完了したら、コントロール・ユニット１１は、ステップＳ５０８０において、完了をクライアント２１に通知する。

なお、クライアント２１を構成する機器の製造時などにあらかじめ変更条件を組み込むことも可能である。その場合はステップＳ５０００からステップＳ５０２０は不要である。

以下に、本実施形態の変形例について説明する。
上述の実施形態の分散処理システムは、コントロール・ユニット１１と、クライアント２１と、プロセッシング・エレメント３１から３ｎと、を備えていたが、これに代えて、
（１）ユーザから要求されたサービスの実行を要求するクライアントと、
（２）（１）のクライアントに接続されたプロセッシング・エレメントと、
で構成するとともに、（１）のクライアントが有する制御機能のみによって制御するようにしてもよい。

また、
（ａ）ユーザからのサービス要求を受ける機能を備えたコントロール・ユニットと、
（ｂ）（ａ）のコントロール・ユニットに接続されたプロセッシング・エレメントと、
で構成するとともに、（ａ）のコントロール・ユニットが有する制御機能のみによって制御するようにもできる。
このシステムでは、ＣＵにサービス要求を受け付ける機能を持たせることによって、クライアントがなくてもシステムを構成できる。

以上の実施形態又は変形例に係る分散処理システム、コントロール・ユニット、及び、クライアントにおいては、クライアント側に制御機能を委譲し、ＰＥの接続情報などの制御情報をＣＵから引き継ぐことで処理を行うことができる。

これにより、ＣＵの負荷を下げながら、独自にアプリケーションを実行することが可能となる。例えば、従来はＣＵが計算資源確保や経路確立をする場合にはそれらが完了した時点で、ＣＵからクライアントに完了通知を出さなければならなかったが、本発明ではクライアント２１がそれらを行うため完了通知は必要ない。

さらに、クライアント２１に対してＰＥの接続情報の開示範囲や適用可能なスケジューリングポリシーを制限すれば、複数のクライアント２１をセキュリティ上のルールを適用しながら協調して運用させることが可能である。

以上のように、本発明に係る分散処理システム、コントロール・ユニット、及びクライアントは、制御機能の負荷がコントロール・ユニットに集中しやすい分散処理システムに有用である。

１１ コントロール・ユニット（ＣＵ）
２１ クライアント（ＣＬ）
３１、３２、．．．、３ｎ プロセッシング・エレメント（ＰＥ）

Claims (27)

1. ユーザから要求されたサービスの実行を要求するクライアントと、
   プロセッシング・エレメントと、
   前記クライアント及び前記プロセッシング・エレメントに接続されているコントロール・ユニットと、
   を備えた分散処理システムであって、
   前記コントロール・ユニットは前記分散処理システムを制御するための制御機能を有し、
   前記クライアントは、前記コントロール・ユニットの制御機能のうちの少なくとも１つの制御機能と同じ制御機能を有し、
   前記コントロール・ユニット及び前記クライアントの両方が有する制御機能の少なくとも１つについて、前記コントロール・ユニット及び前記クライアントの制御機能の少なくとも一方を選択して制御を実行することを特徴とする分散処理システム。
2. 前記コントロール・ユニット及び前記クライアントの両方が有する制御機能の少なくとも１つについて、前記コントロール・ユニット及び前記クライアントのどちらかの制御機能を択一的に選択して制御を実行することを特徴とする請求項１に記載の分散処理システム。
3. 前記コントロール・ユニット及び前記クライアントの両方が有する制御機能の少なくとも１つについて、前記コントロール・ユニット及び前記クライアントの両方の制御機能を用いて制御を実行することを特徴とする請求項１又は請求項２に記載の分散処理システム。
4. 前記コントロール・ユニット及び前記クライアントの制御機能の選択は、あらかじめ前記コントロール・ユニットに記憶された選択設定にしたがって、前記コントロール・ユニットが実行することを特徴とする請求項１から請求項３のいずれか１項に記載の分散処理システム。
5. 前記コントロール・ユニット及び前記クライアントの制御機能の選択は、前記クライアントにサービスの実行を要求するユーザ又はそれ以外のユーザからの要求にしたがって、前記コントロール・ユニットが実行することを特徴とする請求項１から請求項４のいずれか１項に記載の分散処理システム。
6. 前記コントロール・ユニットは、判断条件にしたがって、前記制御機能の選択の実行の承諾又は拒否を判断し、この判断結果に基づいて、前記制御機能の選択を実行することを特徴とする請求項１から請求項５のいずれか１項に記載の分散処理システム。
7. 前記コントロール・ユニットは前記判断条件をあらかじめ記憶している請求項６に記載の分散処理システム。
8. 前記コントロール・ユニットは、前記クライアントにサービスの実行を要求するユーザ又はそれ以外のユーザからの要求にしたがって、前記判断条件を設定する請求項６又は請求項７に記載の分散処理システム。
9. 前記コントロール・ユニットは、前記クライアントの制御機能が選択されている場合であっても、前記クライアントに制御コマンドを発行し、前記選択された制御機能に代えて、対応する自身の制御機能を強制的に選択することを特徴とする請求項１から請求項８のいずれか１項に記載の分散処理システム。
10. 前記コントロール・ユニットは、前記クライアントの制御機能が選択されているか否かに関わらず、前記クライアントに制御コマンドを発行し、前記クライアントの制御機能を強制的に変更することを特徴とする請求項１から請求項９のいずれか１項に記載の分散処理システム。
11. 前記コントロール・ユニットは、前記クライアントにサービスの実行を要求するユーザ又はそれ以外のユーザからの要求にしたがって、前記クライアントに前記制御コマンドを発行することを特徴とする請求項９又は請求項１０に記載の分散処理システム。
12. 前記コントロール・ユニットは、発行条件に従って自律的に、前記クライアントに前記制御コマンドを発行することを特徴とする請求項９又は請求項１０に記載の分散処理システム。
13. 前記クライアントは、前記クライアントの制御機能が選択されているか否かに関わらず、変更条件にしたがって、前記変更条件によって指定された制御機能を強制的に変更し、前記コントロール・ユニットに通知することを特徴とする請求項１から請求項８のいずれか１項に記載の分散処理システム。
14. 前記変更条件は、前記クライアントの制御機能が選択されている場合に、前記コントロール・ユニットが設定すること、あるいは、あらかじめ記憶させておくことを含むことを特徴とする請求項１３に記載の分散処理システム。
15. 前記コントロール・ユニットは、前記クライアントからの前記通知があった場合に、前記通知にしたがって、自身の制御機能を再設定することを特徴とする請求項１３又は請求項１４に記載の分散処理システム。
16. 前記変更条件は、前記クライアントの制御機能が選択されてからの制限時間、サービス実行環境の状況、サービス実行負荷の状況、計算資源使用状況、サービスの実行状況のうちの少なくとも１つを含むことを特徴とする請求項１３又は請求項１４に記載の分散処理システム。
17. 前記制御機能は、前記制御機能に必要な情報の公開又は非公開を択一的に選択する機能を含むことを特徴とする請求項１から請求項１６のいずれか１項に記載の分散処理システム。
18. 前記公開を制限できる情報は前記プロセッシング・エレメントの状態を含むことを特徴とする請求項１７に記載の分散処理システム。
19. 前記公開を制限できる情報はスケジューリングポリシーを含むことを特徴とする請求項１７又は請求項１８に記載の分散処理システム。
20. 前記制御機能は、計算資源の確保・解放、処理経路の確立・解放、前記プロセッシング・エレメントの状態のモニタリング、処理のスケジューリング、前記スケジューリングについてのスケジューリングポリシーの選択、前記サービスのタスク分解、前記プロセッシング・エレメントの登録・解除、及び、経路情報の記憶のうちの少なくとも１つを含むことを特徴とする請求項１から請求項１９のいずれか１項に記載の分散処理システム。
21. 前記クライアントは、前記コントロール・ユニットのすべての制御機能と同じ制御機能を備えることを特徴とする請求項１から請求項２０のいずれか１項に記載の分散処理システム。
22. 前記コントロール・ユニットのすべての制御機能について、前記クライアントの制御機能のみを用いて制御を実行することを特徴とする請求項２１に記載の分散処理システム。
23. 前記コントロール・ユニットのすべての制御機能について、前記コントロール・ユニットの制御機能のみを用いて制御を実行することを特徴とする請求項２１に記載の分散処理システム。
24. ユーザから要求されたサービスの実行を要求するクライアントと、
    前記クライアントに接続されたプロセッシング・エレメントと、
    を備えた分散処理システムであって、
    前記分散処理システムは、前記クライアントが有する制御機能のみによって制御されることを特徴とする分散処理システム。
25. ユーザからのサービス要求を受ける機能を備えたコントロール・ユニットと、
    前記コントロール・ユニットに接続されたプロセッシング・エレメントと、
    を備えた分散処理システムであって、
    前記分散処理システムは、前記コントロール・ユニットが有する制御機能のみによって制御されることを特徴とする分散処理システム。
26. ユーザから要求されたサービスの実行を要求するクライアント、及び、プロセッシング・エレメントとともに分散処理システムを構成し、前記分散処理システムを制御する制御機能を有するコントロール・ユニットであって、
    前記コントロール・ユニット及び前記クライアントの両方が有する制御機能の少なくとも１つについて、制御の実行のために、前記コントロール・ユニット及び前記クライアントの制御機能の少なくとも一方を選択することを特徴とするコントロール・ユニット。
27. 分散処理システムを制御する制御機能を有するコントロール・ユニットに接続され、ユーザから要求されたサービスの実行を要求するクライアントであって、
    前記コントロール・ユニットの制御機能のうちの少なくとも１つの制御機能と同じ制御機能を有し、
    前記コントロール・ユニット及び前記クライアントの両方が有する制御機能の少なくとも１つについて、前記コントロール・ユニットによって選択された制御機能を用いた制御を実行することを特徴とするクライアント。

Images