JPH0546572A - 分散処理システム - Google Patents

Abstract

(57)【要約】 【目的】プログラムをアプリケーション本来の処理を行
なう部分とシステムの管理を行なう部分とに分離し、オ
ブジェクトの数が多くなったときにも効率よくシステム
の管理が可能なようにする。 【構成】計算機１２１〜１２３がネットワーク１１によ
り接続されている。各計算機のメモリ１６１〜１６２に
記憶されているアプリケーションプロセス２１１〜214
は、対応する管理プロセス２２１〜２２４によって管理
されている。また、アプリケーションプロセスに障害が
発生した場合には障害回復プロセス２３１〜234が障害
回復を行なう。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、大規模分散処理に適し
た分散処理システムに係り、特に、多数の計算機を接続
した複数のネットワークを含む分散処理システムに関す
る。

【０００２】

【従来の技術】最近分散処理が様々な分野で利用されて
いるが、効率のよい分散処理を実現するためには、各計
算機上のオブジェクトを効率的に管理，活用する必要が
ある。従来の分散システムでは、アプリケーションプロ
グラムの部分とシステム管理の部分が明確に区別されて
いないことが多く、プログラムのバージョンアップやテ
ストに多くの労力が必要であった。そこで近年、アプリ
ケーションプログラムを実行する部分をオブジェクトレ
ベル、その制御，管理を行なう部分をメタレベルとして
明確に区分したリフレクティブ・アーキテクチャを分散
処理システムに応用する研究が行なわれている。

【０００３】論文「オブジェクト指向分散オペレーティ
ングシステムＭｕｓｅにおけるオブジェクト管理機構」
（日本ソフトウェア科学会第５回論文集）にも、このよ
うなリフレクティブ・アーキテクチャが示されている。

【０００４】

【発明が解決しようとする課題】しかし、上記従来技術
は、メタレベルのオブジェクトが機能毎に別れており、
ある機能のオブジェクトがシステム全体で１箇所にしか
存在しないことがありえる。このため、広域に分散さ
れ、大量のハードウェア，ソフトウェアを有する場合に
は適していない。

【０００５】本発明の目的は、大規模分散処理システム
の多数のオブジェクトの効率的な管理を実現することの
出来る、分散処理システムを提供することにある。

【０００６】本発明の他の目的は、システムをオフライ
ンにすることなしに、アプリケーションプログラムやデ
ータをバージョンアップすることのできる分散処理シス
テムを提供することにある。

【０００７】本発明のさらに他の目的は、分散処理シス
テムで使用するアプリケーションプログラムを試験する
手段を提供することにある。

【０００８】

【課題を解決するための手段】上記目的を達成するため
に、多数あるオブジェクトの各々に、そのオブジェクト
を管理する管理オブジェクトを付加する。また、上記目
的を達成するため、管理オブジェクトがオブジェクトの
プログラムやデータを変更できるようにする。また、上
記目的を達成するため、管理オブジェクトが受信したメ
ッセージや送信したメッセージを記憶しておき、オブジ
ェクトを試験するときに記憶しておいたメッセージをオ
ブジェクトに対して送信することにより動作を試験す
る。

【０００９】

【作用】オブジェクトのプログラムやデータを変更する
必要が生じた場合、そのオブジェクトを管理している管
理オブジェクトに対して変更の要求を出す。管理オブジ
ェクトが要求に従ってオブジェクトを変更する。

【００１０】また、オブジェクトが送信するメッセージ
の宛先を知らないときにも、管理オブジェクトにそのメ
ッセージを送信すれば、管理オブジェクトがメッセージ
の内容より宛先の計算機とプロセス名を検索して目的の
プロセスにメッセージを転送する。

【００１１】また、オブジェクトに対して緊急を要する
メッセージを送信する場合には、その管理オブジェクト
に対してメッセージを送信すれば、管理オブジェクトが
目的のオブジェクトのメッセージキューの先頭に緊急メ
ッセージを挿入する。このことにより、その緊急メッセ
ージは目的のオブジェクトで最初に処理される。

【００１２】また、管理オブジェクトは、オブジェクト
が送受信したメッセージの内容を記録しておく。オブジ
ェクトが何らかの障害で異常終了した場合には、記録さ
れているメッセージの内容より、異常終了した時点での
状態を調査し、その状態から処理を再開する。

【００１３】また、オブジェクトのプログラムを新しく
作成したときに、管理オブジェクトが記録されているメ
ッセージと同じメッセージをそのオブジェクトに送信す
ることにより、プログラムの正当性をテストすることが
できる。

【００１４】

【実施例】以下、本発明の実施例を、図面により詳細に
説明する。

【００１５】図１は、本発明の分散システムの全体構成
図である。

【００１６】図１では、計算機１２１〜１２３がネット
ワーク１１により接続されている。各計算機は、プロセ
ッサ１４１〜１４２，ネットワークアダプター１５１〜
152，ディスク１７１〜１７２，メモリ１６１〜１６２
を持ち、それらはバス１３１〜１３２により接続されて
いる。メモリには、オペレーティングシステム２４１〜
２４２，アプリケーションプロセス２１１〜２１４，管
理プロセス２２１〜２２４，障害回復プロセス２３１〜
２３４の各種情報が記憶されている。

【００１７】プロセスやオペレーティングシステムは、
プログラムとデータを持っており、プロセッサがそのプ
ログラムを実行して、データを処理していく。オペレー
ティングシステムのプログラムは、主にプロセスへのメ
モリ割当て、ネットワークアダプターやディスクの制
御、実行プロセスの切り替えを行なう。アプリケーショ
ンプロセスは請求の範囲で述べたオブジェクトに対応す
るものであり、そのプログラムは、本来、システムが目
的としている処理を実行する。一方、管理プロセスや障
害回復プロセスは請求の範囲で述べた管理オブジェクト
である。管理プロセスのプログラムは、アプリケーショ
ンプロセスの管理を行なう。障害回復プロセスには、ア
プリケーションプロセスが何らかの障害で異常終了した
ときに、そのプロセスを再び立ち上げ、処理を続行させ
るプログラムが入っている。

【００１８】図２は図１のアプリケーションプロセス２
１１の構成を示している。ただし、他のアプリケーショ
ンプロセス２１２〜２１４や管理プロセス２２１〜２２
４，障害回復プロセス２３１〜２３４も同様の構成から
なる。

【００１９】図２において、アプリケーションプロセス
２１１は、レジスタ退避領域３１１，プログラム３２１
〜３２３，データ領域３３１，メッセージキュー３４１
を持つ。プロセッサは、プロセスのプログラム３２１〜
３２３を実行して、データ領域３３１のデータを処理し
ていく。このとき、プロセッサは一つのプロセスのプロ
グラムを実行し終えてから、次のプロセスのプログラム
に移るのではなく、あるプロセスのプログラムを一定時
間実行した場合や、あるプロセスのプログラムが処理時
間の長い入出力を起動した場合には、例えプログラムの
途中であっても他のプロセスのプログラムに実行を切り
替える。この実行途中の状態を保存するためにレジスタ
退避領域３１１が必要である。すなわちプログラムの実
行を中断する前にプロセッサのプログラムカウンタＰ
Ｃ，スタックポインタＳＰ，汎用レジスタＲ０〜Ｒ３の
内容を退避しておけば、再びそれらの内容をプロセッサ
に設定することにより、中断したところから処理を再開
することができる。メッセージキュー３４１はプロセス
間の通信に用いられる。

【００２０】図３はプロセス間のメッセージ通信の方法
を示している。図３において２１１はアプリケーション
プロセス、２２１は管理プロセス、３１１〜３１２はレ
ジスタ退避領域、３２１〜３２５はプログラム、３３１
〜３３２はデータ領域、341〜３４２はメッセージキュ
ー、２４１はオペレーティングシステム、３５１〜３５
３はプログラム、４１１はシステムコール、４２１はメ
モリライト、４９１はメッセージ受信である。

【００２１】図３では、管理プロセス２２１がアプリケ
ーションプロセス２１１にメッセージを送っている。送
り手側のプロセスはプログラム３２４の中でシステムコ
ールmsgsndを実行する。すると、プロセッサの実行がオ
ペレーティングシステムの中のmsgsndのプログラム３５
３に移る。このプログラムの中では、まず、通信先が同
一の計算機に存在するか判断する。同一計算機に存在す
る場合には、通信相手のプロセスのメッセージキュー３
４１にメッセージを書き込む４２１。同一計算機に存在
しない場合は、図４で述べる。一方、受け手側のプロセ
スは、プログラムの中でmsgrcvを実行しメッセージキュ
ーに入っているメッセージを読み出す４９１。

【００２２】図４は、異なる計算機に存在するプロセス
に対してメッセージを送信する方法を示している。図４
において、１１はネットワーク、１２１〜１２３は計算
機、１３１〜１３２はバス、１４１〜１４２はプロセッ
サ、１５１〜１５２はネットワークアダプター、１６１
〜１６２はメモリ、１７１〜１７２はディスク、211〜
２１３はアプリケーションプロセス、２２１〜２２３は
管理プロセス、２４１〜２４２はオペレーティングシス
テム、３５３〜３５４はプログラム、４１１はシステム
コール、４２４はメモリライト、６１はネットワークア
ダプター起動、６２は割り込み、６３はネットワーク通
信である。

【００２３】図３は同一の計算機上のプロセスに対する
メッセージ通信方法であったが、異なる計算機に存在す
るプロセスに対して通信を行なうこともできる。プロセ
ス２２１がシステムコール４１１を発してオペレーティ
ングシステム２４１にメッセージ通信を依頼するところ
までは、図３と同様である。しかし、オペレーティング
システムは、メッセージが異なる計算機のプロセスに対
するものであると判断すると、ネットワークアダプター
１５１に通信要求を出す。ネットワークアダプター１５
１は、ネットワーク１１を通して目的の計算機のネット
ワークアダプター１５２にメッセージを転送する。ネッ
トワークアダプター１５２は、メッセージを受信すると
割り込み６２によりオペレーティングシステム２４２の
プログラム３５４を起動する。このプログラムの中で受
信されたメッセージを目的のプロセス２２３のメッセー
ジキューに入れる。

【００２４】図５は図３及び図４のメッセージ通信の略
記法を示している。２１１がアプリケーションプロセ
ス、２２１が管理プロセス、４４１がメッセージ通信で
ある。以後、プロセス間のメッセージ通信はこのように
単なる矢印で表現することにする。

【００２５】図６は、アプリケーションプロセス間の通
信方法を示している。２１１と212がアプリケーション
プロセス、２２１と２２２がそれぞれの管理プロセス、
171はディスク、５２はプロセスデータベースである。
アプリケーションプロセス間の通信は、直接相手のメッ
セージキューにメッセージを送るのではなく、まず、自
分の管理プロセス２２２にメッセージを送る４４２。メ
ッセージを受けた管理プロセス２２２は通信先のアプリ
ケーションプロセス２１１がどの計算機に存在するか判
断し、その管理プロセス２２１にメッセージを転送する
４４３。最後に管理プロセス２２１がアプリケーション
プロセス２１１にメッセージを送信する４４１。メッセ
ージの宛先を指定する方法には２通りある。一つは計算
機名とプロセス名を両方指定する方法である。この場合
は、２２２の管理プロセスが指定された計算機の指定さ
れたプロセスに対してメッセージを送信する。もう一つ
の方法は、プロセス名のみを指定する方法である。この
場合は、管理プロセスがディスク１７１上のプロセスデ
ータベース５２を使用してメッセージを送信する計算機
を決定する。プロセスデータベースは、プロセス名とそ
のプロセスが存在する計算機の名前の対応が保存されて
いるデータベースである。

【００２６】図７は、アプリケーションプロセスのプロ
グラムを変更する方法を示している。図７において１２
１は計算機、１４１はプロセッサ、１５１はネットワー
クアダプター、１７１はディスク、１６１はメモリ、２
１１はアプリケーションプロセス、２１５は新しいアプ
リケーションプロセス、２２１は管理プロセス、241は
オペレーティングシステム、４３１はプロセス生成、４
１２はシステムコール、４４４はメッセージ通信、４６
１はディスクリードである。

【００２７】新しい機能の追加やプログラムのデバッグ
のため、アプリケーションプロセスのプログラムを変更
する必要が生じることがある。新しいプログラムはディ
スク１７１に記憶されているとする。変更要求のメッセ
ージ４４４が管理プロセス２２１に送信されることによ
り変更が開始される。管理プロセス２２１は、変更要求
のメッセージを受信すると、新しいアプリケーションプ
ロセス２１５を生成する４３１。次に管理プロセスはシ
ステムコールによりオペレーティングシステムにディス
クリードの要求を出す４１２。オペレーティングシステ
ムは、要求に従い、ディスク１７１に記憶されている新
しいプログラムをプロセス２１５に読み込む。以後、管
理プロセスは２１１のアプリケーションプロセス宛に来
ていたメッセージを２１５の新しいアプリケーションプ
ロセスの方に送るようにし、２１１のアプリケーション
プロセスを消去する。

【００２８】図８はアプリケーションプロセスが保持し
ているデータを変更する手段を示している。図８におい
て２１１はアプリケーションプロセス、２２１は管理プ
ロセス、３１１〜３１２はレジスタ退避領域、３２１〜
３２６はプログラム、３３１〜３３２はデータ領域、３
４１〜３４２はメッセージキュー、２４１はオペレーテ
ィングシステム、３５１〜３５３はプログラム、４５３
はメッセージ通信、４９３はメッセージ受信、４１３は
システムコール、４２２はメモリライトである。

【００２９】図７に於けるプログラムの変更と同様に、
アプリケーションプロセスのデータ変更が必要なことが
ある。データの変更もプログラムの変更の時と同様に管
理プロセスがデータ変更要求のメッセージ４５３を受け
付けることにより開始される。しかし、データの変更は
プログラムの変更と異なりプロセスを新たに生成するこ
とはしない。管理プロセスのプログラム３２６は、msgr
cv４９３によりメッセージキュー３４２中のメッセージ
を読みだすとptraceシステムコール４１３を発生する。
ptraceは別のプロセスに対して各種制御を行なうシステ
ムコールであり、別プロセスのデータ変更も可能であ
る。オペレーティングシステム２４１のプログラム３５
２にptraceの処理が記述されている。システムコール４
１３によりプロセッサの実行対象がこのプログラムに遷
移する。このプログラム中でアプリケーションプロセス
２１１のデータ３３１を変更する４２２。

【００３０】図９は緊急メッセージ通信の方法を示して
いる。図９において２１１はアプリケーションプロセ
ス、２２１は管理プロセス、３１１〜３１２はレジスタ
退避領域、３２１〜３２７はプログラム、３３１〜３３
２はデータ領域、３４１〜342はメッセージキュー、２
４１はオペレーティングシステム、３５１〜３５３はプ
ログラム、４１４はシステムコール、４２３はメモリラ
イトである。

【００３１】メッセージの中には他のメッセージに優先
して処理してもらいたいものが存在する。メッセージ中
に緊急であることを記述しておくことにより緊急メッセ
ージとして処理される。緊急メッセージの送信はem_msg
snd システムコールにより行なわれる。このシステムコ
ールを実行したときには、図３のmsgsndとは異なるオペ
レーティングシステムのプログラム３５１が起動され
る。このプログラムは宛先のプロセス２１１のメッセー
ジキュー３４１に既にメッセージが溜まっている場合に
も、その先頭に新しいメッセージを挿入する。

【００３２】図１０はメッセージ送信時のロギング方法
を示している。図１０において、１２１は計算機、１４
１はプロセッサ、１５１はネットワークアダプター、17
1はディスク、１６１はメモリ、２１１はアプリケーシ
ョンプロセス、２２１は管理プロセス、２４１はオペレ
ーティングシステム、４１５はシステムコール445〜４
４６はメッセージ、４７１はディスクライトである。

【００３３】後で述べるアプリケーションプログラムの
テストやアプリケーションプロセスの障害回復を行なう
ため、アプリケーションプロセスが送受信したメッセー
ジは、ディスクにそのログが記録される。図１０は、メ
ッセージを送信した場合を示している。図６で説明した
とおり、アプリケーションプロセス２１１が送信するメ
ッセージは一度、管理オブジェクト２２１に入力される
（４４５）。管理オブジェクトは、そのメッセージを目
的のプロセスに対して送信した後（４４６）、システム
コール４１５によりディスクライトの要求をオペレーテ
ィングシステム２４１に出す。オペレーティングシステ
ムは、その要求に従って管理プロセスが受信したメッセ
ージの内容をディスクに書き込む（４７１）。

【００３４】図１１はメッセージ受信時のロギング方法
を示している。図１１において、１２１は計算機、１４
１はプロセッサ、１５１はネットワークアダプター、17
1ディスク、１６１はメモリ、２１１はアプリケーショ
ンプロセス、２２１は管理プロセス、２４１はオペレー
ティングシステム、４１６はシステムコール４４７〜４
４８はメッセージ、４７２はディスクライトである。

【００３５】図６で説明したとおり、アプリケーション
プロセス２１１に対して送信されたメッセージは一度、
管理オブジェクト２２１に入力される(４４７)。管理オ
ブジェクトは、そのメッセージを自分が管理しているア
プリケーションプロセスに送信した後(４４８)、システ
ムコール４１６によりディスクライトの要求をオペレー
ティングシステム２４１に出す。オペレーティングシス
テムは、その要求に従って管理プロセスが受信したメッ
セージの内容をディスクに書き込む（４７２）。

【００３６】図１２は、図１０と図１１で記録した送受
信メッセージを利用したアプリケーションプログラムの
テスト方法を示している。図１２において、１２１は計
算機、１４１はプロセッサ、１５１はネットワークアダ
プター、１７１はディスク、１６１はメモリ、２１１は
アプリケーションプロセス、２２１は管理プロセス、２
４１はオペレーティングシステム、４１７〜４１８はシ
ステムコール、４４９〜４５０はメッセージ、４６２〜
４６３はディスクリードである。

【００３７】一般に、作成したプログラムの正当性を検
査するのは大変である。ここでは、ディスクに記録され
ている送受信メッセージのログを用いてプログラムをテ
ストする。すなわち、記録されている受信メッセージと
同じメッセージをアプリケーションプロセスに対して送
信し、その結果としてアプリケーションが送信したメッ
セージを記録されているメッセージと比較する。それら
が同一ならばプログラムは正常であり、異なっていれば
プログラムに誤りがある。図１２では、まず、管理プロ
セス２２１がシステムコール４１７によりディスク１７
１に記録されているアプリケーションプロセス２１１の
受信メッセージログを読みだす要求をオペレーティング
システム２４１に対して出す。この要求に従ってオペレ
ーティングシステムがディスクリード４６２を行なう。
ディスクリードが終了すると、管理プロセス２２１は、
読みだされた受信メッセージと全く同じメッセージをア
プリケーションプロセス２１１に送信する（４４９）。
アプリケーションプロセスは、受信したメッセージによ
り、内部で計算を行ない、その結果を管理プロセス２２
１に対して送信する（４５０）。管理プロセス２２１
は、再びディスクリードのシステムコール４１８を実行
し、今度はアプリケーションプロセス２１１の送信メッ
セージのログを読み込んでくる（４６３）。受信された
メッセージとディスクから読んだメッセージを比較して
アプリケーションプロセスのプログラムの正当性をテス
トする。

【００３８】図１３は、アプリケーションプロセスにな
んらかの障害が発生し、そのプロセスが異常終了したと
きの送受信メッセージのログの例を示している。図１３
において５１はログファイル、５１１,５１３,５１５は
メッセージ受信ログ、５１２，５１４は応答メッセージ
の送信ログを表している。

【００３９】図１０及び図１１で説明したとおり、アプ
リケーションプロセスが送受信したメッセージはそのロ
グがディスク１７１に記録されている。このログを利用
することにより、アプリケーションプロセスがなんらか
の障害により異常終了したときにも、そのアプリケーシ
ョンプロセスを再生成し、処理を続行することができ
る。図１３は、このような障害が発生した場合のログの
例を示している。ログファイル５１は、図１０や図１１
中のディスク１７１にあり、メッセージのログが記録さ
れている。多くのアプリケーションプロセスはメッセー
ジを受信し、そのメッセージの内容に従った処理を行な
い、その結果をメッセージとして送信する。すなわち、
メッセージのログではメッセージの受信と送信が対とな
っている。図１３では５１１がメッセージ１を受信した
記録であり、５１２はそのメッセージに対する応答の送
信となっている。同様に５１３と５１４も対となってい
る。しかし、メッセージ５１５に対する応答は送信され
る前にアプリケーションプログラムに障害が発生したた
め、そのログは記録されていない。

【００４０】図１４は、図１３のようなログを残してア
プリケーションプロセスが異常終了したときの障害回復
方法を示している。図１４において、１２１は計算機、
141はプロセッサ、１５１はネットワークアダプター、
１７１はディスク、１６１はメモリ、２１６はアプリケ
ーションプロセス、２２１は管理プロセス、２３１は障
害回復プロセス、２４１はオペレーティングシステム、
４１９はシステムコール、４４９〜４５０はメッセー
ジ、４６２〜４６３はディスクリードである。

【００４１】障害回復プロセス２３１は、アプリケーシ
ョンプロセスの動作を定期的に監視しており、アプリケ
ーションプロセスの異常終了はこのプロセスにより発見
される。異常終了を発見した障害回復プロセス２３１
は、まず、ディスク上のログを調査する。そのためにシ
ステムコール４１９を行ないディスクリード４６４をオ
ペレーティングシステム２４１に依頼する。ディスクリ
ードが終了すると最後に記録されているログが何であっ
たかを調べ、何の処理中に異常終了が発生したかを特定
する。図１３の例ではメッセージ３の受信５１５が最後
のログとなっているのでメッセージ３に対する処理の最
中に異常終了が発生したことがわかる。そこで、障害回
復プロセス２３１は、異常終了したアプリケーションプ
ロセスと同じプロセスを生成し４３２、最後のログ５１
５と同じ内容のメッセージをそのアプリケーションプロ
セスに再送する４５２。以後は通常の動作に戻る。障害
回復の間に管理プロセス２２１が受信したアプリケーシ
ョンプロセス宛のメッセージ４５１は、管理プロセスが
メッセージキューに蓄えておき、障害回復終了後、新し
いアプリケーションプロセス２１６に送信する。

【００４２】

【発明の効果】本発明によれば、プログラムをアプリケ
ーション本来の処理を行なう部分とシステムの管理を行
なう部分とに明確に分離することができる。また、オブ
ジェクトと管理オブジェクトが１対１に対応しているの
で、オブジェクトの数が多くなったときにも効率よくシ
ステムの管理が可能である。

【図面の簡単な説明】

【図１】本発明の分散システムの全体構成図である。

【図２】プロセスの構成を示した図である。

【図３】プロセス間のメッセージ通信の方法を示した図
である。

【図４】異なる計算機に存在するプロセスに対して、メ
ッセージを送信する方法を示した図である。

【図５】図３のメッセージ通信の略記法を示した図であ
る。

【図６】アプリケーションプロセス間の通信方法を示し
た図である。

【図７】アプリケーションプロセスのプログラムを変更
する方法を示した図である。

【図８】アプリケーションプロセスが保持しているデー
タを変更する手段を示した図である。

【図９】緊急メッセージ通信の方法を示した図である。

【図１０】メッセージ送信時のロギング方法を示した図
である。

【図１１】メッセージ受信時のロギング方法を示した図
である。

【図１２】記録した送受信メッセージを利用したアプリ
ケーションプログラムのテスト方法を示した図である。

【図１３】アプリケーションプロセスになんらかの障害
が発生し、そのプロセスが異常終了したときの送受信メ
ッセージのログの例を示した図である。

【図１４】アプリケーションプロセスが異常終了したと
きの障害回復手段を示した図である。

【符号の説明】

１１…ネットワーク、１２１〜１２３…計算機、１３１
〜１３２…バス、141〜１４２…プロセッサ、１５１〜
１５２…ネットワークアダプター、１６１〜１６２…メ
モリ、１７１〜１７２…ディスク、２１１〜２１６…ア
プリケーションプロセス、２２１〜２２４…管理プロセ
ス、２３１〜２３４…障害回復プロセス、２４１〜２４
２…オペレーティングシステム、３１１〜３１２…レジ
スタ退避領域、３２１〜３２７…プロセスのプログラ
ム、３３１〜３３２…データ領域、３４１〜３４２…メ
ッセージキュー、３５１〜３５３…オペレーティングシ
ステムのプログラム、４１１〜４１６…システムコー
ル、４２１〜４２３…メモリライト、４３１〜４３２…
プロセス生成、４４１〜４５３…メッセージ通信、４６
１〜４６５…ディスクリード、４７１〜４７２…ディス
クライト、４９１〜４９３…メッセージ受信、５１…ロ
グファイル、５１１〜５１５…ログ。

フロントページの続き (72)発明者 斉藤 雅彦 茨城県日立市久慈町4026番地 株式会社日 立製作所日立研究所内 (72)発明者 小林 芳樹 茨城県日立市久慈町4026番地 株式会社日 立製作所日立研究所内

Claims (8)

【特許請求の範囲】
1. 【請求項１】複数のオブジェクト間でメッセージを交信
   して処理を進める分散処理環境において、該オブジェク
   トを管理する管理オブジェクトを該オブジェクトに対応
   して１つ以上設けたことを特徴とする分散処理システ
   ム。
2. 【請求項２】請求項１において、上記管理オブジェクト
   が対応する上記オブジェクトのプログラムまたはデータ
   を変更する手段を設けたことを特徴とする分散処理シス
   テム。
3. 【請求項３】請求項１において、上記オブジェクトが送
   信するメッセージの宛先が不明の時に対応する上記管理
   メタオブジェクトが宛先を決定する手段を設けたことを
   特徴とする分散処理システム。
4. 【請求項４】請求項１において、上記オブジェクトに、
   上記オブジェクトが受信したメッセージが入る待ち行列
   を設け、上記オブジェクトに対応する上記管理オブジェ
   クトが、上記待ち行列中のメッセージを操作する手段を
   設けたことを特徴とする分散処理システム。
5. 【請求項５】請求項１において、上記オブジェクトが受
   信したメッセージ及び送信したメッセージを記憶する手
   段を、対応する上記管理オブジェクトに設けたことを特
   徴とする分散処理システム。
6. 【請求項６】請求項５において、上記管理オブジェクト
   が記憶している受信メッセージを対応する上記オブジェ
   クトに送信する手段を上記管理オブジェクトに設けたこ
   とを特徴とする分散処理システム。
7. 【請求項７】請求項６において、上記管理オブジェクト
   が記憶している受信メッセージを対応する上記オブジェ
   クトに送信したことにより、上記オブジェクトが送信す
   るメッセージを上記管理オブジェクトが記憶している送
   信メッセージと比較する手段を設けたことを特徴とする
   分散処理システム。
8. 【請求項８】請求項５において、上記オブジェクトが障
   害により中断したときに、対応する上記管理メタオブジ
   ェクトが記憶しているメッセージの情報により、上記オ
   ブジェクトの処理を継続することを特徴とする分散処理
   システム。