JPH0916534A

JPH0916534A - 分散型プロセス処理方法およびその装置

Info

Publication number: JPH0916534A
Application number: JP7164837A
Authority: JP
Inventors: Yushi Mochizuki; 祐志望月; Yukio Hirahara; 幸男平原; Toru Sano; 亨佐野; Susumu Handa; 享半田; Akinori Yamamoto; 章紀山本; Shinichi Yorozu; 伸一萬
Original assignee: N II C JOHO SYST KK; NEC Corp
Current assignee: N II C JOHO SYST KK; NEC Corp
Priority date: 1995-06-30
Filing date: 1995-06-30
Publication date: 1997-01-17

Abstract

(57)【要約】【目的】ネットワークで結合された均一あるいは不均
一に分散構成された計算機環境において、ユーザーの投
入ジョブをサーバに効率よく分散実行処理させる。【構成】ユーザーの投入ジョブに係るアプリケーショ
ンプログラムのプロセス流れに対して、クライアントと
サーバプロセス間に介在するエージェントプロセスを生
成する。エージェントは、計算機に関する静的性能と動
的な負荷状況の変動などハードウェア資源に関する情報
と、計算機環境内のプログラムモジュールと随伴するデ
ータなどソフトウェア資源に関する情報とに基づいて、
クライアントプロセスより依頼された目的ジョブをサー
バプロセスに分配し実行処理させる。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、ネットワークで結合さ
れた分散型の計算機環境において、ユーザーにより投入
されるアプリケーションプログラムのジョブを、環境内
のハードウェア資源、およびソフトウェア資源を有効か
つ効率よく利用して実行する、分散型プロセス処理方法
およびその装置に関するものである。

【０００２】

【従来の技術】高速大容量ネットワーク、縮小命令セッ
トＣＰＵ（ＲＩＳＣ）などの技術の急速な進歩により、
ＷＳ（ワークステーション）など安価な計算機資源をク
ラスター状に結合して分散型処理環境を構築し、アプリ
ケーションソフトウェアを、メッセージ通信を通じてク
ライアント／サーバ方式で実行する形態を取ることによ
り、価格性能比に優れたジョブ処理が可能になってきて
いる。こうした分散化の流れは、高性能専用機であるス
ーパーコンピュータの分野にも広まり、単一ベクトルＣ
ＰＵ型よりも、ベクトルＣＰＵを並列にして処理の分散
を図った高並列機や、ＲＩＳＣを数千に及ぶ規模にまで
並列分散した超並列機の方が主流になりつつあるが、分
散制御の基本はＷＳクラスターと同様にメッセージ通信
に基づくものが多い。

【０００３】メッセージ通信の特徴の１つは、均一構成
の場合はもちろん、マルチベンダによるＷＳ群をクラス
ターにする等の不均一構成の場合でも、個々のＷＳ上の
ＯＳの違いに拠らずに対応出来るポータビリティの良さ
である。最近では、メッセージ通信により、距離的に離
れたＷＳクラスター同士を結合したり、ＷＳクラスター
とスーパーコンピュータを結合して高次の分散環境を構
築する試みも成されつつある。

【０００４】メッセージ通信の手段としては、特に科学
技術計算の分野では米オークリッジ国立研のＰＶＭが使
われることが多い。メッセージ通信をアプリケーション
ソフトウェアに実装するには、元のプログラム構造をク
ライアント側とサーバ側に適にモジュール分割し、その
間で変数、もしくは配列領域をやり取りするように、通
信専用の外部ライブラリルーチンのコール文を挿入す
る。サーバプロセスを複数生成すれば、分散並列処理と
なる。この際、クライアント側とサーバ側で通信と処理
流れの手順をつじつまを合わせてコーディングしておく
必要がある。逆に言えば、メッセージ通信の変数、配列
並びが統一され、かつ機能が同一であれば、由来の異な
るモジュールを結合することも可能であり、共有ライブ
ラリ化されている、行列対角化などの数値処理用モジュ
ールなどを自アプリケーションの中で引用利用すること
もある。

【０００５】アプリケーションのあるプロセスからメッ
セージ通信のためのルーチンコールがあると、個々の機
種に固有のＯＳとは別に存在するデーモンと呼ばれるハ
ンドラーに制御が移り、ここから実際の通信パケットの
送出と受理が行われる。アプリケーション側から見る
と、ＯＳはデーモンから要求されたパケットを下位レベ
ルで処理するのみで、あらわには見えず、これが上述の
良好なポータビリティにつながっているのだが、黒子で
あるデーモンも、実は、単にアプリケーションにおける
クライアントプロセスとサーバプロセスの間でのメッセ
ージ通信を仲介しているだけにすぎない。

【０００６】従って、分散型環境として与えられた計算
機資源を有効利用出来るような高度なプロセス流れの組
立ては、煩雑ではあるがアプリケーション側で全て責任
を持ってコーディングし、実現をしなければならない。

【０００７】

【発明が解決しようとする課題】まず、分散型環境に含
まれるハードウェア資源に関連する問題点を挙げる。

【０００８】既に述べたように、従来のメッセージ通信
制御では、アプリケーション側からは機種の違いは見え
ない。しかし、例えば、あるジョブの実行のために、環
境内の全てのＷＳを並列化サーバプロセスのみに独占的
に従事させる場合でも、各ＷＳのＣＰＵの速度性能差に
ばらつきが在れば、クライアントプロセスが単純にサー
バプロセスのタスクリストを均等割りして発行すると、
最も低速なＷＳに律速されてしまうために高い処理効率
は得られない。

【０００９】これを避けるには、アプリケーションジョ
ブの実行前に、ＷＳの性能差をパラメータとしてクライ
アントプロセスに与え、それに応じてタスクの割り当て
方を変える対策が考えられるが、実際の運用環境では上
で仮定した独占的従事の条件下ではなく、複数のジョブ
が同時に投入されている非独占的な条件で、各ＷＳの負
荷状況は動的に変化しているため、事前の静的な割り当
てでは効果的な改善は望めない。この問題は、環境内の
ＷＳの数が増えるほど深刻化する。さらに、あるＷＳが
障害発生により実行中に使用不能となった場合、それが
認識され、さらに障害ＷＳが担当していたサーバプロセ
スがきちんと代替されて処理全体の整合性が保たれなけ
ればならないが、通常のメッセージ通信制御ではデーモ
ンにその機能が無いために、クライアントプロセスまで
も継続処理不能状態に陥ってしまい、目的のアプリケー
ションジョブそのものを異常終了させざるを得なくな
る。あるいは、逆に、実行中に障害から復旧したＷＳが
環境内にあっても、それをサーバ用に動的に有効利用す
ることは出来ない。

【００１０】つまり、従来技術ではメッセージ通信をハ
ンドルするデーモンは、分散環境内のハードウェア資源
の動的な変化に反応して、アプリケーションジョブの実
行が確実かつ最適に行われることを保証する手段を持っ
ていない。むろん、ＯＳは個々のＷＳに存在している
が、ネットワークを通じて統合的にジョブ実行を動的管
理する機能は有しておらず全く無力である。

【００１１】一方、アプリケーション側でハードウェア
環境の動的変化にきちんと対応するためには、システム
コールなどを用いて自らが環境情報を取得し、それに基
づいて複雑な最適制御を行うようにプログラム開発者が
コーディングしておかなくてはならないが、煩雑となる
他、分散環境の機種内訳が変わる度に修正が必要とな
り、保守性が悪化してしまう。別の方策としては、通常
行われるようにアプリケーションプログラムをクライア
ントモジュール部とサーバモジュール部に分けるだけで
はなく、これらから制御のみに専念する部分を全く別に
分離し、制御プロセスにクライアントプロセス、サーバ
プロセスの両方を管理させることも考えられる。しか
し、この方法を実現するには元のクライアント／サーバ
式のアプリケーションプログラムの大幅な修正が必要で
あり、しかも、それでもなお、管理部の構造は個々のア
プリケーションに依存して異なるので汎用性、一般性は
なく、抜本的な解決とはなり得ない。

【００１２】ハードウェア資源の動的な有効利用の困難
さは、ＷＳクラスターに限ったことではなく、メッセー
ジ通信制御による並列分散型のスーパーコンピュータに
おいてはより先鋭に表れる。例を挙げれば、ＣＰＵの数
が６４で、これを４つのジョブで公平に利用しようとす
る場合、各ジョブが共に６４ＣＰＵを共有して使うので
はなく、１６ＣＰＵずつにあらかじめ分割し、互いにＣ
ＰＵ使用が重ならないように運用されることが多い。最
初の３つのジョブが終了しても、まだ実行中の４つ目の
ジョブは、最後まで最初の１６ＣＰＵのまま走ることに
なる。次に投入されるべき５つ目のジョブが、６４ＣＰ
Ｕを全て使うことを要求していれば、４つ目が終るまで
実際の投入は待たなければらない。これを、アプリケー
ション側から改善しようとしても、既述のようにコーデ
ィングが煩雑であることは疑いなく、またＷＳクラスタ
ーへ移植する際には、改めて修正する必要があることも
言うまでもない。

【００１３】また、これまで述べてきたハードウェア資
源に関する従来技術の問題点が、ＷＳクラスター同士を
互いに接続したり、あるいはＷＳクラスターと並列スー
パーコンピュータを接続して構成されるより高次の分散
環境では、より一層顕在化するのは明らかである。

【００１４】次に、ソフトウェア資源の有効利用の観点
から従来技術の問題点を挙げる。まず最初に、計算機の
特性に応じた最適なプログラムモジュールの選択利用に
関してである。例えば、前述のように、スカラー実行の
ＷＳクラスターとベクトルＣＰＵを１つ持つスーパーコ
ンピュータを接続した分散処理環境での、変分法の求解
を要求するユーザージョブの実行において、アプリケー
ションプログラムが、変分に関わる行列要素の構築を並
列サーバプロセスとして行うことを考える。

【００１５】一般的に、同一の数値処理を行うにも、ス
カラー実行とベクトル実行では最適なアルゴリズムは異
なり、必然的にモジュールのコードも異なる。従って、
サーバプロセスでの行列要素の構築は、ＷＳではスカラ
ー用のモジュールで、スーパーコンピュータではベクト
ル用のモジュールで行われるべきである。しかし、現状
では、いずれかの一つのモジュールが妥協的に使われる
ことが多い。きちんと計算機の特性を活かすには、アプ
リケーションプログラムの開発者、もしくは維持管理者
が、運用計算機の構成を把握し、それに応じたモジュー
ルの指定、前述の速度差に応じた静的負荷分散の指示、
および必要なメッセージ通信などを明示的にコーディン
グすることになるが、移植性と保守性の悪さは明白であ
る。さらに、動的な環境変化に対応する制御手段までも
実装しようとすれば、その困難はいよいよ深刻である。

【００１６】続いて、バージョンの更新に関連して問題
点を指摘する。例として、格子点データを与えることに
より数値積分を実行するモジュールが、分散計算機環境
内に共有ライブラリの一つとして置かれ、様々なアプリ
ケーションプログラムにおいてメッセージ通信を通じ
て、サーバとして引用されている状況を考え、必要な数
値データに合わせて、当該積分モジュール内において読
み参照される数値補間用テーブルのファイル名を渡す必
要があるとする。

【００１７】さて、このライブラリモジュールのバージ
ョンが更新され、補間テーブルのファイルも合わせて更
新されると、モジュール／テーブル間の整合性に留意し
つつ、各アプリケーションに対して対応する変更を個別
に行う必要があり、保守上、煩雑なこの変更作業をバー
ジョン更新の度に繰り返さなければならない。アプリケ
ーションの開発者、維持管理者が複数である場合、ライ
ブラリの管理者がバージョンの更新を各人に通知し、各
々が変更を行うことになるが、周知徹底される保証はな
い。

【００１８】上記の２例で見たように、ソフトウェア資
源の有効利用という面でも従来技術には問題がある。ま
た、先に述べたように、ハードウェア資源の有効利用に
関連しても問題があり、これら両者を共に解決する手段
が必要である。

【００１９】

【課題を解決するための手段】上記課題を解決するた
め、本発明は、ネットワークで結合された均一もしくは
不均一に分散構成された計算機環境におけるプロセス処
理方法において、ユーザーの投入ジョブに係るアプリケ
ーションプログラムのプロセス流れに対して、個々の計
算機に関する静的な性能と動的な負荷状況の変動などハ
ードウェア資源に関する情報と、計算機環境内のプログ
ラムモジュールと随伴するデータなどソフトウェア資源
に関する情報とを把握する単数あるいは複数のエージェ
ントプロセスを生成し、生成された前記エージェントプ
ロセスがクライアントプロセスとサーバプロセス間に介
在し、ハードウェア資源に関する情報とソフトウェア資
源に関する情報に基づいて、クライアントプロセスより
指令された目的ジョブをサーバプロセスに実行処理させ
ることを特徴とする分散型プロセス処理方法である。

【００２０】また、本発明の第２の発明は、ネットワー
クで結合された均一もしくは不均一に分散構成された計
算機環境において使用され、クライアントとサーバとエ
ージェント管理システムより構成される分散型プロセス
処理装置であって、エージェント管理システムは、クラ
イアントよりユーザーの投入ジョブに係るタスクを受け
付ける受付部と、個々の計算機に関する静的な性能と動
的な負荷状況の変動などハードウェア資源に関する情報
と、計算機環境内のプログラムモジュールと随伴するデ
ータなどソフトウェア資源に関する情報を保持する資源
情報管理部と、前記受付部からの命令に基づいてエージ
ェントプロセスを生成、消去するエージェントプロセス
操作部とから構成され、エージェントプロセス操作部に
より生成されたエージェントプロセスは、クライアント
とサーバ間に介在し、資源情報管理部より得たハードウ
ェア資源に関する情報とソフトウェア資源に関する情報
とに基づいて前記目的ジョブをサーバに実行処理させる
ことを特徴とする分散型プロセス処理装置である。

【００２１】目的ジョブの終了後は、エージェントプロ
セスはエージェント管理システムにより消去される。

【００２２】クライアントプロセスとサーバプロセス間
に介在するためにプロセスとして生成、消去されるエー
ジェントモジュールは、ライブラリ化されてエージェン
ト管理システム内部に置かれている。

【００２３】

【実施例】以下に、本発明の一実施例を図面を参照して
説明する。

【００２４】本発明によれば、アプリケーションプログ
ラムにおける、クライアントプロセスとサーバプロセス
間でのメッセージ通信は、従来技術のように直接やり取
りされるのではなく、図１に示すように、エージェント
プロセスの中間介在によって間接的にやり取りされる。
アプリケーションの開発者、維持管理者が、エージェン
トを利用するコード変更の要点は、クライアント部とサ
ーバ部の各々のメッセージ通信の直接参照コールを、エ
ージェントを解した間接参照コールにすることである。
これらエージェント関係ルーチンのコール形式は、むろ
ん汎用性、一般性を持ち、各アプリケーションがライブ
ラリとして共通利用出来る。いずれにせよ、明記すべき
は、エージェントプロセスは、まさしく、クライアント
プロセスとサーバプロセスの間に入る代理人として振舞
うのであって、そのアプリケーションのプロセス全体を
上位から管理する形式にはなっていないということであ
る。

【００２５】図２に、本発明による計算機におけるエー
ジェント管理システムの階層の概念図を示す。図２よ
り、エージェントの管理システムはＯＳから見ればアプ
リケーションプログラムの１つに過ぎない。従って、不
均一構成の分散環境への実装にあたっても機種の違いを
強く意識することはない。

【００２６】エージェントプロセスを生成、消去等の管
理を行い、さらに資源情報を把握するエージェント管理
システムは、分散環境内の計算機に対して個別に置かれ
るか、適当にまとめられた計算機グループ毎に置かれ
る。図３に、エージェント管理システムの構成図を模式
的に示す。

【００２７】エージェント管理システムは、６つの構成
要素３．１〜３．６より成る。外側のメッセージ通信制
御部３．１は、クライアントプロセス、サーバプロセス
間の通信の他、当該管理システムの存在する計算機のＯ
Ｓ、および他の計算機上のエージェント管理システムと
の通信をハンドリングする。

【００２８】エージェント管理システムの内部は５つの
要素、クライアントからのエージェント使用の宣言やタ
スク依頼を受付ける部分（受付部）３．２、依頼された
タスクをプールしておく部分（タスクプール部）３．
３、ライブラリ部分３．４の中のエージェントプログラ
ムを起動して、プロセスとして生成・活性化する、ある
いは消去・不活性化するなどエージェントプロセスに対
する操作を行う部分（エージェント操作部）３．５、お
よび資源情報の取得・保持を行っている部分（資源情報
部）３．６から構成される。

【００２９】エージェント管理システムは、Ｃ言語等の
プログラム言語で記述されている。エージェントライブ
ラリ３．４はプロセスとして活性化されている部分と、
不活性の部分とを合わせ持つが、活性化された部分がジ
ョブ実行を仲介するエージェントプロセスとして機能す
る。エージェント管理システムのそれ以外の部分、３．
１〜３．３および３．５〜３．６は常にプロセスとして
活性な状態にある。

【００３０】エージェントプロセス操作部３．５による
ライブラリ３．４でのエージェントプロセスの生成・消
去のプロセス操作は、該当する標準的な関数の呼出しに
よってなされる。

【００３１】資源情報の取得・保持部３．６で取得・保
持されるハードウェア資源情報のテーブルについては、
図４に示すように、個々の計算機のＣＰＵ速度、あるい
はＣＰＵがスカラー型なのかベクトル型なのか、といっ
た静的な項目と、ロードアベレージに代表されるような
ＣＰＵ負荷の変動、利用可能メモリー空間や作業ファイ
ル量、そして障害の状況などの動的な項目に分けること
が出来る。静的な情報は、各計算機毎にファイル上にあ
らかじめ書いて設定しておけば、資源情報の取得・保持
部３．６によって読み込まれる。動的な環境情報は、資
源情報の取得・保持部３．６からの各ＯＳに対するシス
テムコールにより、適当な時間間隔を持って随時取得さ
れる。

【００３２】ソフトウェア資源の情報は、図５に示すよ
うに、プログラムとデータの機能と所在、相互参照のリ
ンク、および参照の履歴などに関する項目があり、静的
なハードウェア資源の情報と同様に、ファイル上に設定
され、そこから読み込まれる。ここで、プログラム情報
については、例えば、コンパイル時に取得することが出
来る。ライブラリを更新、ないしは新規に追加する場合
は、このソフトウェア情報のテーブルファイルのみを、
その旨に合わせて変更すればよく、個別のアプリケーシ
ョン側の変更は必要ではない。また、参照履歴について
は、エージェントの使用によって逐次更新される。

【００３３】図４のハードウェア資源情報のテーブル
と、図５のソフトウェア資源の情報テーブルの中身は、
ＣＰＵ速度のように各計算機毎の線形のエントリを持つ
もの、ネットワーク状況のように計算機間の行列型のエ
ントリを持つもの、プログラムとデータの参照関係のよ
うに不定型のエントリを持つものなど、複雑な内部構造
を有している。

【００３４】ここで、並列化されていないジョブを単一
実行する場合を例に取り、エージェントを使うジョブ実
行のプロセス流れを、エージェント管理システム内部の
動作も含め、図６を用いて詳細に説明する。ここでは、
メッセージ通信のハンドリング部は省略する。

【００３５】最初に、クライアントプロセス６．１がエ
ージェント管理システム内の受付け部６．２にエージェ
ント使用の宣言６．１０を行うと、受付部６．２からの
要求６．１１に応じてエージェントプロセス操作部６．
３によりエージェント生成メッセージ６．１２が発せら
れ、エージェントライブラリを元に、当該クライアント
プロセスを認識するエージェントプロセス６．４が生成
される。

【００３６】次に、クライアントプロセス６．１はタス
クを、数値データの他に、処理の手続きやサーバに関す
る情報などを文字列のスクリプトとして記述し、タスク
６．１３をエージェント側受付部６．２に依頼する。依
頼されたタスクは、エージェント側受付部６．２からの
依頼タスクのセット要求６．１４によりタスクプール部
６．５にセットされる。

【００３７】次に、エージェントプロセス６．４は、タ
スクプール部６．５から、依頼タスクの取得要求６．１
５、取得要求６．１５の返答６．１６によりタスクを読
み出し、その内訳に基づいて、ハードウェア・ソフトウ
ェア資源情報の管理部６．６から必要な情報を資源情報
の取得要求６．１７と、その返答６．１８により得る。
そして、エージェントプロセス６．４は、それらの資源
を最適に利用出来るようにサーバを選択し、サーバプロ
セスの起動・生成要求６．１９を発し、それによりサー
バプロセス６．７を起動・生成させる。続いてエージェ
ントプロセス６．４は、タスクの数値データをサーバプ
ロセス６．７に送り（６．２０）、サーバプロセス６．
７に実際の処理を行わせ、実行結果をエージェントプロ
セス６．４に戻させる（６．２１）。

【００３８】エージェントプロセス６．４は、実行結果
が正常であれば、タスクプール部６．５に依頼タスクが
正常終了したことを記し（６．２２）、サーバプロセス
消去要求（メッセージ）６．２３を発することによりサ
ーバプロセス６．７を消去する。

【００３９】続いて、エージェントプロセス６．４は依
頼タスクの実行が正常に終了された結果をクライアント
プロセス６．１に返送する（６．２４）。

【００４０】クライアントプロセス６．１はエージェン
トプロセス６．４からの結果を受け取り、最後に受付部
６．２にエージェント使用の停止を宣言する（６．２
５）と、受付部６．２からのサーバプロセスの消去要求
６．２６に基づき、エージェントプロセス操作部６．３
がエージェントプロセス消去要求メッセージ６．２７を
発しエージェントプロセス６．４は消去される。また、
受付部６．２からの実行済タスクの消去要求メッセージ
６．２８によりタスクプール部６．５から依頼タスクの
内容も消去される。なお、どのサーバが選択されたかを
履歴として保持したい場合は、サーバプロセスの正常終
了が確立した時点で、エージェントプロセス６．４が資
源情報部６．６へ書き込みの要求を出せばよい。

【００４１】並列実行、すなわち、サーバプロセスが複
数となる場合は、それに応じてエージェントプロセスも
複数生成されると共に、それらの調停を担う上位エージ
ェントが１つ生成され、動的な負荷分散が行われながら
処理が行われる。上位エージェントも、図３のエージェ
ントプロセスとして活性化され得る部分を持つライブラ
リ部３．４に含まれる。

【００４２】並列実行に係るプロセスを、計算機数を２
として図７に例示的に示す。計算機１の上にあるクライ
アントプロセス７．１は、同じく計算機１上のエージェ
ント管理システム７．２に並列実行の旨を宣言すると、
この宣言が計算機２の管理システム７．３にも伝えら
れ、計算機１の上にエージェントプロセス７．４が、計
算機２の上にエージェントプロセス７．５が生成され、
合わせて上位エージェント７．６が計算機１の上に生成
される。次に、クライアントプロセス７．１から計算機
１のエージェント管理システム７．２へ使用するサーバ
モジュールがスクリプトにより指定されると、エージェ
ントプロセス７．４がサーバプロセス７．７を、計算機
２のエージェントプロセス７．５がサーバプロセス７．
８を生成する。そこで、クライアントプロセス７．１が
並列タスクの制御のリストをエージェント管理システム
７．２に渡すと実行が開始される。このリストはエージ
ェント管理システム７．２内のタスクプール部に置かれ
るが、アクセスはエージェントプロセス７．４と７．５
の上位エージェントプロセスである７．６のみが許され
る。上位エージェントプロセス７．６は、制御リストの
全体の長さを適当な周期幅を持って繰り返しブロックに
分割する。このブロックが、さらに計算機の負荷状況に
応じて分けられるが、これはエージェントプロセスの
７．４と７．５が上位エージェントプロセス７．６に要
求を出すことで行われる。要求を出された上位エージェ
ントプロセス７．６は、エージェント管理システム７．
２内のハードウェア資源のテーブルから、計算機１の負
荷状況を、計算機２のエージェント管理システム７．３
から同様に計算機２の負荷状況を得て、それらに応じて
ブロックを分割して、エージェントプロセス７．４と
７．５に割当てる。計算機１のエージェントプロセス
７．４はサーバプロセス７．７に、計算機２のエージェ
ントプロセス７．５はサーバプロセス７．８に割当てら
れたタスクを送って実際に処理を行わせる。これら一連
の割当て／処理を、並列タスク制御リストが尽きるまで
繰り返す。

【００４３】並列サーバプロセス間で必要な通信もエー
ジェントプロセスが介在する。すなわち、メッセージは
計算機１上のサーバプロセス７．７→計算機１上のエー
ジェントプロセス７．４→計算機２上のエージェントプ
ロセス７．５→計算機２上のサーバプロセス７．８へ、
またその逆方向へと、エージェントプロセスを介して伝
えられる。並列処理が正常に終了すれば、計算機１上の
サーバプロセス７．７はエージェントプロセス７．４
に、計算機２上のサーバプロセス７．８はエージェント
プロセス７．５によって消去され、さらに続けてクライ
アントプロセス７．１からの停止宣言により計算機１上
のエージェント管理システム７．２はエージェントプロ
セス７．４を、計算機２上のエージェント管理システム
７．３はエージェントプロセス７．５を消去する。

【００４４】（実施例１）次に本発明を用いた場合の具
体的動作例について、まず、エージェントの導入に伴う
アプリケーションプログラムの変更を例として説明す
る。例題として、（１）式に示される連立１次方程式の
求解ジョブを取る。この例は、また、計算機の特徴の違
いに応じたソフトウェアの選択に関するエージェントの
機能についての述解も兼ねる。

【００４５】

【数１】

【００４６】図８、図９は、連立一次方程式の求解にお
ける従来技術によるプロセス流れを記した擬コードであ
る。図８はクライアントでのプロセス流れを、図９はサ
ーバでのプロセス流れを示している。クライアントプロ
セスでは、入力データである左辺の行列要素｛Ａ_ij｝と
右辺のベクトル要素｛ｂ_i｝を最初にセットする。解ベ
クトル要素｛ｘ_i｝は、これらセットされた要素データ
をメッセージ通信で送ってサーバプロセスで求められ
る。このサーバプロセスは、ＷＳのようなスカラー型、
あるいはスーパーコンピュータのようなベクトル型かに
よって異なるモジュール、Ｌ_SとＬ_Vで実行される。速
度は、もちろんベクトル版Ｌ_Vの方が高速であり、与え
られた分散型計算機環境でベクトルＣＰＵの計算機が利
用出来るなら、こちらが使われるべきである。

【００４７】この要請を実現するために、煩雑とはなる
が、図８よりわかるように、サーバへの求解メッセージ
送信の前にクライアント自らが分散型環境の情報を取得
し、利用可能な計算機に応じて、タスク依頼のための送
信、および結果の受信のための識別子を設定するように
コードされている。

【００４８】さて、クライアントからサーバへ
｛Ａ_ij｝、｛ｂ_i｝のメッセージが送信されると、図９
に示すようにＬ_S、Ｌ_Vいずれかのサーバプロセスが、
クライアント送信時の識別子に応じてそれを受信し、式
（１）の求解処理を行い、あらかじめクライアントから
与えられた識別子を付けて、解データ｛ｘ_i｝をメッセ
ージとして返送する。そして、クライアントは、サーバ
からその求解結果を受信する。以上が従来技術によるプ
ロセス流れである。

【００４９】一方、図１０、図１１、図１２は本発明に
よるエージェントを用いる場合のプロセス流れである。
図１０はクライアントでのプロセス流れを、図１１はエ
ージェントでのプロセス流れを、図１２はサーバでのプ
ロセス流れを示している。図１０において、｛Ａ_ij｝と
｛ｂ_i｝の要素を最初にセットするところは従来の図８
と同じである。しかし、その下で、本発明によれば環境
情報と識別子に関する部分が元のクライアントコードか
らは省かれていること、メッセージ送受信のコールが全
く異なっていることに注意されたい。さて、クライアン
トプロセスがエージェント管理システムにエージェント
プロセスの使用を宣言すると、当該クライアントを認識
するエージェントプロセスが生成される。続いて、クラ
イアントは、エージェントプロセス側に、入力要素｛Ａ
_ij｝、｛ｂ_i｝の配列領域、さらに合わせて、連立１次
方程式の求解である旨の宣言、求解用モジュールＬ_Sと
Ｌ_Vの情報、およびモジュール選択の基準をメッセージ
として送信する。これで、エージェントプロセスに実行
の流れが移る。要素データ以外の項は、クライアントが
エージェントに対して、依頼するタスクの特徴、および
その処理方針をスクリプトとして与えることに対応して
いる。

【００５０】エージェントは、図１１に示すように、図
５の環境情報の中の利用可能計算機のリスト、および与
えられた選択基準を元に、Ｌ_S、Ｌ_Vのいずれかのサー
バモジュールを選び、識別子を適に設定し、実際の求解
のために、入力要素｛Ａ_ij｝、｛ｂ_i｝のメッセージを
サーバに送る。この例の場合、モジュール選択の基準は
実行速度であるので、ベクトル機が使えれば、与えられ
た候補２つの中からＬ_Vが選ばれる。この候補挙げに係
る論理流れを図１３に示す。

【００５１】サーバは、図１２に示すようにエージェン
トからの入力要素の受信後、式（１）を解き、その後、
解要素｛ｘ_i｝のメッセージをエージェントに返送す
る。そして、エージェントは解を受取り、今度はクライ
アントにそれを送る。

【００５２】以上で、エージェントプロセスの主たる役
目は終わりで、制御は再びクライアント側に戻り、最後
に管理システムに役目終了を通知することで、エージェ
ントプロセスは消去される。この例で分かるように、エ
ージェントの介在により、クライアントとサーバの間に
直接の参照関係は無くなる。識別子によるサーバへのメ
ッセージルーティングはエージェントによって成され
る。

【００５３】上の段落で行ったエージェント導入のメリ
ットを明確に示すために、元々のアプリケーション開発
者が作成したベクトル実行用のサーバモジュールＬ_Vよ
り高速な、第３者が開発したベクトル実行用のライブラ
リモジュールＬ_Tを使用する例を挙げる。

【００５４】Ｌ_Tを利用するためには、従来技術では、
当該アプリケーションの開発者、維持管理者がコードに
修正を加える必要があるが、本発明のようにエージェン
ト管理システムを用いていればその必要はない。代わり
に、分散環境の維持管理者が、元のＬ_Tのメッセージ通
信周りのみをエージェント管理用に適に修正し、Ｌ_Tの
特性に関する情報を図５のソフトウェア資源のテーブル
に加えておけばよい。それにより、図１１、図１３での
サーバモジュールの候補にＬ_Tが自動的に含まれるの
で、当該アプリケーション実行時に、ベクトルＣＰＵ機
が使えるならば、きちんと最速のＬ_Tが参照される。こ
の際、図５のテーブル中のＬ_Tについての参照履歴が更
新される。他のモジュール、例えば、超並列機用のモジ
ュールＬ_Pなどをライブラリに新たに加えることを考え
れば自明だが、この例はエージェント管理の導入によっ
てもたらされる保守性の良さを示している。なお、自開
発のサーバモジュールＬ_S，Ｌ_Vの使用に固執する場合
は、その旨を強制条件として、クライアントがエージェ
ントに渡すべきスクリプトに明記しておくことになる。
逆に、連立１次方程式の求解の旨だけを記し、モジュー
ルの指定を一切しないで済ますことも出来る。

【００５５】サーバモジュールがファイルを扱う場合で
も、本発明のエージェント管理システムを用いれば同様
のメリットが得られる。前出の数値積分のライブラリモ
ジュールの例を再び取り上げる。積分を行うこのモジュ
ールＬ_Xを使うには、クライアント側から、当該モジュ
ール内で読み参照される補間テーブルファイルのファイ
ル名を、使用時に格子点のデータと共に与えるのだが、
それはバージョン毎に異なるために、従来技術ではバー
ジョンアップに対する保守は煩雑である。一方、本発明
のエージェントに依る場合には、クライアント側は格子
点の数値データとスクリプトを渡すだけでよい。図５の
ソフトウェア資源の情報テーブルには、プログラムと随
伴するデータに関する相互参照のリンクが在るので、エ
ージェントプロセスは、バージョンに応じたファイル名
をサーバモジュールＬ_Xに通知し、正しく処理が行われ
る。

【００５６】（実施例２）次に、ネットワークで結合さ
れたＷＳクラスターから成る分散型計算機環境におい
て、（２）式に示す超行列の積和演算を並列サーバプロ
セスで処理するジョブ例を取りあげ、負荷分散につい
て、本発明のエージェントがいかに機能するかを述べ
る。

【００５７】

【数２】

【００５８】上式に係るタスク制御リストとしては２添
字の組｛ｉ，ｊ｝よりも４添字の組｛ｐ，ｑ，ｒ，ｓ｝
の方がはるかに長く、また、｛Ｃ_pqrs｝と｛Ｄ_pqrs｝は
一時的な作業データ要素であって、後で参照されないの
で、４添字の組｛ｐ，ｑ，ｒ，ｓ｝をタスクの制御パラ
メータとして並列サーバプロセスが駆動される。サーバ
プロセス間での通信は、この例では発生しない。
｛Ｂ_ij｝要素は、各サーバプロセスにおいては不完全生
成されることになるので、最終的に正しい値を得るに
は、（３）式に示すように、並列プロセスの終了後、サ
ーバ数について和を取る必要がある。なお、ＷＳの総台
数はＭ個、並列サーバプロセスとエージェントプロセス
の数もＭ個、サーバモジュール名はＬ_Qとする。

【００５９】

【数３】

【００６０】図１４、図１５、図１６、図１７は、本発
明によるエージェントを用いた超行列積和の並列実行の
流れを擬コードで示している。図１４はクライアントで
のプロセス流れを、図１５は下位エージェントでのプロ
セス流れを、図１６は上位エージェントでのプロセス流
れを、図１７はサーバでのプロセス流れを示している。

【００６１】クライアントはまず、エージェント管理シ
ステムに並列処理の使用を宣言する。これにより、Ｍ個
のサーバプロセスに応じてＭ個のエージェントプロセス
が生成され、これらＭ個のエージェントプロセスに対し
て１つの上位エージェントもクライアントプロセスのあ
るＷＳ上に生成される。

【００６２】次に、サーバプロセスで共通の立ち上げ用
の初期数値データと、Ｌ_Qを記述したスクリプトをエー
ジェント側に渡す。すると、管理すべきサーバプロセス
がモジュールＬ_Qに係ることが決まり、初期データが正
しく送られる。そして、Ｌ_Qサーバプロセスは、この受
信を持って｛Ｂ_ij｝の配列領域をゼロ化し、積和処理の
実行に備える。そこで、４添字の組｛ｐ，ｑ，ｒ，ｓ｝
に関する並列タスクの制御リストをエージェント管理シ
ステムに渡すと、上位エージェントプロセス、並列エー
ジェントプロセスの介在による並列処理が開始される。
この、制御リストはタスクプール部にセットされる。こ
こで、リストが個別に添字の値を持つ必要はなく、ある
規則に従い、パックして多次元性を１次元に簡約、つま
り単純な長さで定義しておき、サーバプロセスでの実際
の処理開始時に復元すればよい。

【００６３】次に、動的負荷分散を図るための、上位エ
ージェントプロセスにおけるロジックの一例について述
べる。注意すべきは、上位エージェントによってタスク
制御リストの全長さＳ_tot.が一度にサーバ数Ｍで分割さ
れるのではなく、周期幅を持って繰り返し分割されるこ
とである。図１８に、分割情報を含む並列タスクのテー
ブル構造を示す。最初の分割周期の長さをＳ_ini.とす
る。Ｓ_ini.は、初期値としてクライアントプロセス側か
ら、エージェント管理システム側にタスクリストを渡す
際に与える。さて、第１回目の各エージェントプロセス
／サーバプロセスに対する割当ては次のように行われ
る。

【００６４】エージェントプロセスは、サーバプロセス
を生成し終わると、上位エージェントに対してタスクの
割当てを要求する。上位エージェントは、一番最初に要
求が到着した時から初期待ち時間Ｑ_ini.だけ待ち、その
間に要求を出して揃ったエージェントに対して、負荷に
応じたタスクブロックの割当てを行う。ここで、既に各
ＷＳには負荷のバラツキがあり、これによりサーバプロ
セスの生成に要する時間もまちまちとなるので、揃うエ
ージェントプロセスの数Ｎ₁はＭとは限らない。初期待
ち時間Ｑ_ini.も、クライアント側から、最初の分割周期
の長さＳ_ini.と共に渡す。各ＷＳでの負荷の違いの考慮
は、以下のように行われる。

【００６５】あるエージェントが存在するＷＳのロード
アベレージ値の最大値（静的）を

【００６６】

【外１】

【００６７】、この第１回目の割当て時のロードアベレ
ージ値（動的）を

【００６８】

【外２】

【００６９】とすると、利用可能度

【００７０】

【外３】

【００７１】は（４）式で与えられる。

【００７２】

【数４】

【００７３】一方、そのＷＳの速度を

【００７４】

【外４】

【００７５】とすると、割当て時の利用可能な速度

【００７６】

【外５】

【００７７】は（５）式のように表される。

【００７８】

【数５】

【００７９】得られた

【００８０】

【外６】

【００８１】よりＷＳ群から成る分散環境の計算能力Ｐ
₁は、（６）式と表せる。

【００８２】

【数６】

【００８３】従って、第１回目で、エージェントαが得
るタスクブロックの割当て

【００８４】

【外７】

【００８５】は（７）式となる。

【００８６】

【数７】

【００８７】｛ｐ，ｑ，ｒ，ｓ｝の部分割当てタスクブ
ロックを得たエージェントプロセスは、それを自分の受
持ちのＬ_Qサーバプロセスにメッセージ送信する。サー
バは、それに従い、対応する部分の｛Ｃ_pqrs ^ij｝と｛Ｄ
_pqrs｝をセットし、｛Ｂ_ij｝に積和寄与を加算する。こ
こで、２組添字の｛ｉ，ｊ｝に関しては可能な全てが尽
くされる。サーバは与えられたタスクが完了すると、そ
れを示すフラグをエージェントに返送する。これでエー
ジェントプロセスに制御が戻る。受信したフラグが正常
であるならば、エージェントプロセスは、それをエージ
ェント管理システムに通知する。これにより、図１８の
テーブルに、割当てタスクブロックの正常終了と担当エ
ージェントのサインが記される。これが、あるエージェ
ントプロセスにおけるループの一単位である。

【００８８】次に第２回目のタスク割当てだが、第１回
目の処理中にも負荷は動的に変動しているので、各サー
バプロセスで処理に要した経過時間

【００８９】

【外８】

【００９０】にはバラツキがあるはずで、一番最初に第
２回目のタスクの割当て要求を出すタイミングもまちま
ちである。従って、待ち時間内に揃い、割当てをもらえ
るエージェントのＮ₂は、必ずしも前回のＮ₁と同じで
はない。第１回目での経過時間のバラツキの程度は、１
つの計量として、第２回目で揃ったＮ₂に対する平均ε
₁（（８）式に示す）から、（９）式で示される分散σ
₁を求めて判断することができる。

【００９１】

【数８】

【００９２】待ち時間に間に合わなかったならば、その
エージェントプロセス、およびサーバプロセスは次の回
まで待機することになる。第３回目以降の割当ても同様
である。

【００９３】次に、上位エージェントプロセスによる周
期幅と待ち時間の変更・最適化のロジックについてであ
る。まず、周期に関しては、１つの目安は経過時間の分
散の変化（σ_(I+1)−σ₁）である。これが、正ならば
分散は大きくなる方向であるから、周期を短くして各ノ
ードの経過時間を減らす。逆に負であれば、通信頻度を
より減らすように伸ばす。伸縮は、Ｓ_ini.に適当なスケ
ール因子を逐次掛けて行う。待ち時間Ｑ_ini.に関して
は、揃うエージェントの数の変化が目安になる。ここ
で、集合数の変化（Ｎ_(I+1)−Ｎ_I）が負ならば伸ばす
必要があるのは言うまでもない。もちろん、エージェン
トの総数ＭとＮ_Iの関係も参考にする。Ｑ_ini.に対して
も同様に、変更・最適化のためのスケーリングを行う。

【００９４】上記の一連のプロセス流れが、タスクブロ
ックの長さがゼロ、すなわちリストが尽くされるまで繰
り返される。ゼロの割り当てタスクは、そのＬ_Qサーバ
で成すべき積和処理の完了を意味する。つまり、長さゼ
ロのタスクブロックをサーバプロセスが受け取ると、エ
ージェントプロセス側に結果の送信希望のフラグが返送
され、エージェント側は、飛び出し後、サーバから不完
全生成された｛Ｂ_ij｝要素の受信を待つこととなる。こ
うして、各エージェントプロセスは個々の受持ちサーバ
プロセスから不完全生成｛Ｂ_ij｝を受け取ることが出
来、続けて、これらをクライアントプロセス側に転送す
れば、エージェントの役目は終わる。後は、クライアン
トが、それらループを使って受信し、全受信完了後、式
（３）に従って次々に足し合わせれば、完全な｛Ｂ_ij｝
を得て、エージェント管理の完了を告げる。

【００９５】エージェントを用いた式（２）の超行列積
和の並列サーバプロセス実行中に、あるサーバプロセス
を実行しているＷＳが障害により使用不能となっても、
本発明によれば、図１８のタスクテーブルには担当した
エージェントのサインが記されているので、容易にリカ
バリの手続きを取り、確実に目的ジョブを行うことが出
来る。障害の発生は、そのＷＳ上のエージェント管理シ
ステムからの通信が途絶えることで検出される。そし
て、リカバリには、障害ＷＳに任されていたタスクを集
め、他の生きているエージェントプロセスで再実行を行
えばよい。タイミングとしては、障害発生が起きたすぐ
後の割り当て要求時、もしくは一通りタスクリストを終
えてから、いずれでも可能である。障害による台数の
（Ｍ−１）への減少は、むろんクライアント側にも通知
される。一方、障害を受けていたＷＳが途中で復旧し、
その上のエージェント管理システムが立ち上がれば、再
度サーバとして利用が可能となる。この場合も、障害そ
のものによって失われたタスクは適に再実行される。ま
た、実行中に、（Ｍ＋１）台目のＷＳを新たに追加して
も、同様にエージェント管理システムが、新たなエージ
ェントプロセスを生成するので、そのＷＳを取り込んで
利用することが出来る。

【００９６】これまで述べてきた例から、本発明によれ
ば、エージェント管理システムを有するため、上記のＷ
ＳクラスターにベクトルＣＰＵのスーパーコンピュータ
をさらに結合した分散型環境でも同様に、式（２）の超
行列積和を、動的な負荷分散を行いつつ並列実行するこ
とが容易であることがわかる。そのためには、ベクトル
実行で部分的な積和処理を行うモジュールＬ_Rを用意
し、図５のソフトウェア資源テーブルにその情報を加
え、クライアントでのエージェント呼び出しのスクリプ
トを適に変更するだけでよい。

【００９７】

【発明の効果】以上示したように、本発明によればエー
ジェント制御を分散型計算機環境に導入することによ
り、環境内のハードウェア資源とソフトウェア資源を有
効かつ効率よく利用して、ユーザーの投入したアプリケ
ーションジョブを最適実行することが可能である。アプ
リケーションの開発者、維持管理者にとって、エージェ
ント制御の導入に伴う修正は少なくて済む。また、環境
内の資源の開発者、維持管理者に対しても良好な保守性
をもたらす。さらに、マルチベンダにより提供されるモ
ジュールの使用費用が、そのコール回数や総ＣＰＵ時間
に応じて加算されるような運用形態に対しても対応が容
易である。

【図面の簡単な説明】

【図１】本発明によるエージェントを用いたメッセージ
通信の関係図である。

【図２】本発明による計算機におけるエージェント管理
システムの階層を表す概念図である。

【図３】本発明によるエージェント管理システムの構成
要素の模式図である。

【図４】本発明による分散型計算環境内のハードウェア
資源に関する情報の内容を示す図である。

【図５】本発明による分散型計算環境内のソフトウェア
資源に関する情報の内容を示す図である。

【図６】本発明による、エージェントを用いた非並列化
ジョブの実行におけるプロセス流れを示す図である。

【図７】本発明による、計算機数が２の場合のエージェ
ント使用による並列実行におけるプロセスの関係を示す
模式図である。

【図８】従来のクライアント／サーバ方式により連立１
次方程式を求解する場合の、クライアントでのプロセス
流れを擬コードで表した図である。

【図９】従来のクライアント／サーバ方式により連立１
次方程式を求解する場合の、サーバでのプロセス流れを
擬コードで表した図である。

【図１０】本発明によりエージェントを用いて連立１次
方程式を求解する実施例の、クライアントでのプロセス
流れを擬コードで表した図である。

【図１１】本発明によりエージェントを用いて連立１次
方程式を求解する実施例の、エージェントでのプロセス
流れを擬コードで表した図である。

【図１２】本発明によりエージェントを用いて連立１次
方程式を求解する実施例の、サーバでのプロセス流れを
擬コードで表した図である。

【図１３】本発明によるエージェントにおけるモジュー
ル候補の蓄積を例示した図である。

【図１４】本発明によりエージェントを用いて超行列の
積和処理を並列に行う実施例のクライアントでのプロセ
ス流れを擬コードで表した図である。

【図１５】本発明によりエージェントを用いて超行列の
積和処理を並列に行う実施例のエージェントでのプロセ
ス流れを擬コードで表した図である。

【図１６】本発明によりエージェントを用いて超行列の
積和処理を並列に行う実施例の上位エージェントでのプ
ロセス流れを擬コードで表した図である。

【図１７】本発明によりエージェントを用いて超行列の
積和処理を並列に行う実施例のサーバでのプロセス流れ
を擬コードで表した図である。

【図１８】本発明によるエージェント管理システムに設
定される並列タスクリストに関するテーブルの構成要素
の模式図である。

【符号の説明】

３．１メッセージ通信の制御部分３．２クライアントからのエージェントの使用宣言や
タスク依頼を受付ける部分３．３依頼されたタスクをプールする部分３．４エージェントプロセスとして活性化され得る部
分を持つライブラリ部分３．５エージェントプロセスを操作する部分３．６分散環境内の資源情報を取得・保持する部分６．１クライアントプロセス６．２エージェント管理システムにおけるエージェン
ト使用・タスク依頼の受付け部（プロセス）６．３エージェントプロセスの操作部（プロセス）６．４生成されたエージェントプロセス６．５依頼タスクのプール部（プロセス）６．６資源情報の管理部（プロセス）６．７サーバプロセス６．１０６．１から６．２へのエージェント使用の宣
言（メッセージ）６．１１６．２から６．３へのエージェントプロセス
６．４の生成要求６．１２６．３から６．４へのエージェントプロセス
生成操作６．１３６．１から６．２へのタスク（メッセージ）６．１４６．２から６．５への依頼タスクのセット要
求６．１５６．４から６．５への依頼タスクの取得要求６．１６６．５から６．４への６．１５に対する返答６．１７６．４から６．６への資源情報の取得要求６．１８６．６から６．４への６．１７に対する返答６．１９６．４から６．７のサーバプロセス生成要求
（メッセージ）６．２０６．４から６．７への実行に必要な数値デー
タの転送（メッセージ）６．２１６．７から６．４への実行結果の返送（メッ
セージ）６．２２６．４から６．５への正常終了の通知６．２３６．４からサーバプロセス６．７の消去要求
（メッセージ）６．２４６．４から６．１への結果の転送（メッセー
ジ）６．２５６．１から６．２へのエージェント使用停止
の宣言（メッセージ）６．２６６．２から６．３へのエージェントプロセス
６．４の消去要求６．２７６．３から６．４へのエージェントプロセス
消去操作６．２８６．２から６．５への実行済タスクの消去要
求７．１計算機１上のクライアントプロセス７．２計算機１上のエージェント管理システム７．３計算機２上のエージェント管理システム７．４計算機１上のエージェントプロセス７．５計算機２上のエージェントプロセス７．６７．４と７．５エージェントプロセスに対する
計算機１上の上位エージェントプロセス７．７７．４により生成される計算機１上のサーバプ
ロセス７．８７．５により生成される計算機２上のサーバプ
ロセス

───────────────────────────────────────────────────── フロントページの続き (72)発明者佐野亨東京都港区芝五丁目７番１号日本電気株式会社内 (72)発明者半田享東京都港区海岸三丁目９番15号株式会社エヌイーシー情報システムズ内 (72)発明者山本章紀東京都港区海岸三丁目９番15号株式会社エヌイーシー情報システムズ内 (72)発明者萬伸一東京都港区芝五丁目７番１号日本電気株式会社内

Claims

【特許請求の範囲】

【請求項１】ネットワークで結合された均一もしくは不
均一に分散構成された計算機環境におけるプロセス処理
方法において、ユーザーの投入ジョブに係るアプリケー
ションプログラムのプロセス流れに対して、個々の前記
計算機に関する静的な性能と動的な負荷状況の変動など
ハードウェア資源に関する情報と、前記計算機環境内の
プログラムモジュールと随伴するデータなどソフトウェ
ア資源に関する情報とを把握する単数あるいは複数のエ
ージェントプロセスを生成し、生成された前記エージェ
ントプロセスがクライアントプロセスとサーバプロセス
間に介在し、前記ハードウェア資源に関する情報と前記
ソフトウェア資源に関する情報に基づいて、前記クライ
アントプロセスより指令された前記目的ジョブを前記サ
ーバプロセスに実行処理させることを特徴とする分散型
プロセス処理方法。
【請求項２】ネットワークで結合された均一もしくは不
均一に分散構成された計算機環境において使用され、ク
ライアントとサーバとエージェント管理システムより構
成される分散型プロセス処理装置であって、前記エージェント管理システムは、前記クライアントよ
りユーザーの投入ジョブに係るタスクを受け付ける受付
部と、個々の前記計算機に関する静的な性能と動的な負
荷状況の変動などハードウェア資源に関する情報と、前
記計算機環境内のプログラムモジュールと随伴するデー
タなどソフトウェア資源に関する情報を保持する資源情
報管理部と、前記受付部からの命令に基づいてエージェ
ントプロセスを生成、消去するエージェントプロセス操
作部とから構成され、前記エージェントプロセス操作部により生成されたエー
ジェントプロセスは、前記クライアントと前記サーバ間
に介在し、前記資源情報管理部より得た前記ハードウェ
ア資源に関する情報と前記ソフトウェア資源に関する情
報とに基づいて前記目的ジョブを前記サーバに実行処理
させることを特徴とする分散型プロセス処理装置。