(57)【要約】【課題】  分散オブジェクトシステムにおけるサーバの負荷を平準化する。【解決手段】  複数のサーバ２，３上に分散する同一処理を行うオブジェクト１１，１２に対してクライアント１３，１４が処理を要求し、その際、クライアントは要求された処理を実行可能なオブジェクトを有するサーバを名前サーバ２１の参照管理テーブル２２から検索し、検索されたサーバに処理を要求する。要求されたサーバ２の負荷・生存監視部１９は自サーバ２と他のサーバ３の負荷・生存監視部２０による負荷状態を検出し、自サーバの負荷が高いことが検出された場合は、他の負荷の高くないサーバが上記要求された処理を実行する。また、負荷の高いサーバは、参照管理テーブル２２において一時的に利用停止状態にされる。また、自サーバの負荷が高いことが検出された場合は、要求を出したクライアントに要求の再試行を促すエラー応答を送信する。【選択図】  図１
2005267547.tif 000002
【特許請求の範囲】
【請求項１】
複数のサーバ上に分散して存在し同一の処理を行う複数のオブジェクトに対してクライアントが処理を要求し、その際クライアントは、前記処理を実行可能なオブジェクトを有するサーバを名前サーバから検索し、検索されたサーバに処理を要求する分散オブジェクトシステムにおいて、
前記処理を要求されたサーバが自サーバと他のサーバの負荷状態を検出し、自サーバの負荷が高いことが検出された場合は、負荷の高くない他のサーバが前記要求された処理を実行することを特徴とする分散オブジェクトシステム。
【請求項２】
前記負荷の高いサーバは、前記名前サーバにおいて利用不可状態にされることを特徴とする請求項１記載の分散オブジェクトシステム。
【請求項３】
前記サーバは、自サーバの負荷が高いことが検出された場合は、前記要求を出したクライアントに前記要求の再試行を促すエラー応答を送信することを特徴とする請求項１又は２記載の分散オブジェクトシステム。
【請求項４】
前記クライアントは前記処理を要求する際、前記名前サーバから負荷の高くないサーバを検索し、検索されたサーバに要求することを特徴とする請求項１，２又は３記載の分散オブジェクトシステム。
【請求項５】
複数のサーバ上に分散して存在し同一の処理を行う複数のオブジェクトに対してクライアントが処理要求を行い、その際クライアントは、前記処理を実行可能なオブジェクトを有するサーバを名前サーバから取得し、取得したサーバに処理要求を行う分散オブジェクトシステムにおいて、
各サーバは障害が発生した他のサーバを検出し、検出したサーバは、その障害が発生したサーバを前記名前サーバから削除することを特徴とする分散オブジェクトシステム。
【請求項６】
複数のサーバ上に分散して存在し同一の処理を行うオブジェクトに対してクライアントが処理を要求し、その際、前記クライアントは、前記処理を実行可能なオブジェクトを有するサーバを名前サーバから検索し、検索されたサーバに処理を要求する分散オブジェクトシステムで用いられる前記サーバであって、
前記クライアントの要求に応じて処理を実行するオブジェクトと、
自サーバと他のサーバの負荷状態を検出する負荷状態検出手段と、
自サーバの負荷が高くないことが検出された場合は前記オブジェクトに処理の実行を指示し、処理結果を前記クライアントに送信し、自サーバの負荷が高いことが検出された場合は、その応答を前記クライアントに送信する制御手段とを備えたことを特徴とするサーバ。
【請求項７】
自サーバの負荷が高いことが検出された場合に前記クライアントに送信する前記応答は、前記クライアントに要求の再試行を促すエラー応答であることを特徴とする請求項６記載のサーバ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数のサーバ上に分散して存在する同一の処理を行うオブジェクトに対してクライアントが処理要求を行う分散オブジェクトシステム及びこのシステムで用いられるサーバに関するものである。
【背景技術】
【０００２】
従来より、分散オブジェクトシステムにおけるクライアントからサーバへの要求を動的に負荷分散するためにいろいろな方式が考えられてきた。例えば、クライアントがサーバの参照を取得する際にサーバの負荷も一緒に取得し、クライアント側で呼び出し先を決定する方式（例えば特許文献１）や、名前サーバで負荷情報も管理し、クライアントから参照の取得要求があった際に名前サーバで選択して返す方式（例えば特許文献２）や、サーバ側で負荷情報を管理し、サーバ側で呼び出し先を決定しクライアント側に通知する方式（例えば特許文献３）がある。
【特許文献１】特開２００２−２４１９０号公報
【特許文献２】特開２０００−４７８９０号公報
【特許文献３】特開２００３−２５６３９０号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
しかし、これらの従来技術には以下の問題点があった。
第１の問題点は、クライアント側も負荷分散に対応したシステムにする必要があるということであり、従来のクライアントをそのまま利用する場合や、クライアント台数が多い場合や、クライアントとして他社のシステムを利用する場合などは負荷分散に対応することが困難となっていた。その理由は、特許文献１ではクライアント側で負荷情報収集を選択する必要があり、特許文献３ではサーバ側で決定された呼び出し先を受信する必要があるためである。
【０００４】
第２の問題点は、サーバの参照を要求の度に取得する必要があり、名前サーバへの通信が多くなるということである。そのため名前サーバの負荷が高くなり、負荷分散の効果が半減してしまうことがあった。その理由は、特許文献１では参照を取得しないと負荷情報が得ることができず、特許文献２では参照の取得により負荷分散されるためである。
従って、本発明は上記の問題を解決し、分散オブジェクト環境において適正な動的負荷分散を行うことができる分散オブジェクトシステムを実現することを課題とする。
【課題を解決するための手段】
【０００５】
本発明による分散オブジェクトシステムは、複数のサーバ上に分散して存在し同一の処理を行う複数のオブジェクトに対してクライアントが処理を要求し、その際クライアントは、前記処理を実行可能なオブジェクトを有するサーバを名前サーバから検索し、検索されたサーバに処理を要求する分散オブジェクトシステムにおいて、前記処理を要求されたサーバが自サーバと他のサーバの負荷状態を検出し、自サーバの負荷が高いことが検出された場合は、負荷の高くない他のサーバが前記要求された処理を実行することを特徴とするものである。
【０００６】
また、本発明による分散オブジェクトシステムは、複数のサーバ上に分散して存在し同一の処理を行う複数のオブジェクトに対してクライアントが処理要求を行い、その際クライアントは、前記処理を実行可能なオブジェクトを有するサーバを名前サーバから取得し、取得したサーバに処理要求を行う分散オブジェクトシステムにおいて、各サーバは障害が発生した他のサーバを検出し、検出したサーバは、その障害が発生したサーバを前記名前サーバから削除することを特徴とするものである。
【０００７】
また、本発明によるサーバは、複数のサーバ上に分散して存在し同一の処理を行うオブジェクトに対してクライアントが処理を要求し、その際、前記クライアントは、前記処理を実行可能なオブジェクトを有するサーバを名前サーバから検索し、検索されたサーバに処理を要求する分散オブジェクトシステムで用いられる前記サーバであって、前記クライアントの要求に応じて処理を実行するオブジェクトと、自サーバと他のサーバの負荷状態を検出する負荷状態検出手段と、自サーバの負荷が高くないことが検出された場合は前記オブジェクトに処理の実行を指示し、処理結果を前記クライアントに送信し、自サーバの負荷が高いことが検出された場合は、その応答を前記クライアントに送信する制御手段とを備えたことを特徴とするものである。
【発明の効果】
【０００８】
本発明によれば、サーバの負荷を平準化し、分散オブジェクト環境における動的負荷分散を適正に行うことができる。
また、障害の発生したサーバをシステムから除去してクライアントから呼び出されないようにすることができる。
【発明を実施するための最良の形態】
【０００９】
以下、本発明の実施の形態を図面と共に説明する。
図１は本発明の実施の形態による分散オブジェクトシステムのブロック図である。
本システムは、ネットワーク１に接続されるコンピュータ２，３，４，５，６から構成される。
コンピュータ２，３は、サーバオブジェクト１１，１２を有するサーバコンピュータ（以下、サーバという）であり、コンピュータ４，５はクライアントアプリケーションプログラム（以下、クライアントという）１３，１４を有するクライアントコンピュータであり、コンピュータ６は名前サーバ２１をもつコンピュータである。
【００１０】
サーバ２，３は、同一の処理を行うサーバオブジェクト１１，１２と、クライアント１３，１４からの処理要求をサーバオブジェクト１１，１２に渡すと共に、サーバオブジェクト１１，１２からの応答を分散オブジェクト基盤であるＣＯＲＢＡ（Ｃommon Object Ｒequest Ｂroker Ａrchitecture）通信によりクライアント１３，１４に返すＯＲＢ（Object Ｒequest Ｂroker)７，８と、サーバオブジェクト１１，１２の処理結果を応答変換テーブル１７，１８に基づいて変換を行う応答変換部１５，１６と、サーバ２，３の負荷の状態及び互いの生存監視を行う負荷・生存監視部１９，２０とを備える。
【００１１】
コンピュータ４，５はサーバ２，３への要求を行うクライアント１３，１４と、クライアント１３，１４からの要求を受けてＣＯＲＢＡ通信を行うＯＲＢ９，１０とを備える。
コンピュータ６は、サーバオブジェクト１１，１２の位置情報を示す参照コード（以下、参照という）を格納する参照管理テーブル２２を含み、クライアント１３，１４からの参照の要求に応じて参照を渡す名前サーバ２１を備える。
【００１２】
本実施の形態は、クライアント１３，１４からの処理要求をサーバオブジェクト１１，１２で処理する分散オブジェクト環境において、サーバ２，３の負荷を監視し、負荷が高い場合には、クライアント側のアプリケーションやシステムを変更することなく、自動的に他のサーバに要求を送信する分散オブジェクトシステムである。また、サーバに障害が発生した場合にも、自動的に他のサーバに要求を送信するシステムである。
【００１３】
例えば、クライアント１３からサーバオブジェクト１１に要求がある場合、負荷・生存監視部１９によりサーバ２の負荷を監視し、負荷が高い場合は、名前サーバ２１内の参照管理テーブル２２の参照（サーバオブジェクト１１の位置情報を示すコード）を、指定された期間は利用できないようにする。また、サーバ２の負荷が高い場合は、応答変換部１５により、要求をクライアント１３が再試行を行うようなエラーに変換してクライアント１３に返す。これにより、従来のクライアントが一般的に備えているエラー時の再試行処理をそのまま利用することができ、従来のアプリケーションやシステムでも適用可能となる。
さらに、サーバ２に障害が発生した場合は、負荷・生存監視部１９と接続を確立しているサーバ３の負荷・生存監視部２０が障害を即座に検出し、名前サーバ２１の参照管理テーブル２２におけるサーバ２の参照を削除して、クライアントからアクセスできないようにする。
【００１４】
次に、図２のフローチャートを参照してクライアント側の動作について説明する。
図２において、クライアント１３がサーバ２のサーバオブジェクト１１に処理要求を出す場合、まず、位置情報を名前サーバ２１に問い合わせ、参照管理テーブル２２から参照を取得する（ステップＡ１）。クライアント１３はこの参照に基づいて要求を送信する（ステップＡ２）。この要求はクライアント側のＯＲＢ９で受信される（ステップＡ３）。ＯＲＢ９は、要求先のサーバオブジェクト１１が存在するサーバ２に対して要求をＣＯＲＢＡ通信用に変換して送信する（ステップＡ４）。その後、サーバ２から応答が戻ってくる（ステップＡ５）。この応答をクライアント１３に返す（ステップＡ６）。
【００１５】
クライアント１３は、この応答がサーバオブジェクト１１での処理に失敗したために再試行を行う必要があることを示す応答かを判別し（ステップＡ７）、そうであればステップＡ１に戻り、再度名前サーバ２１から参照を取得するための処理を行う。そうでなければ、次の処理があるかを確認し（ステップＡ８）、すべての処理が終了していれば終了とし、そうでなければステップＡ２に戻り、サーバ２へ次の要求を送信する。
以上の動作は、分散オブジェクト環境におけるクライアントの一般的な流れである。どの応答をもって再試行とするかはクライアントの作成者により異なるが、応答がエラーである場合の再試行も従来より一般的に実施されている。
【００１６】
次に、クライアントが名前サーバ２１から参照を取得する処理について図３のフローチャート及び図４の参照管理テーブル２２を参照して説明する。
図３において、クライアントから名前サーバ２１に参照を取得する要求が届くと（ステップＤ１）、図４の参照管理テーブル２２から要求された処理に対する現在位置を示す参照を取得する。この現在位置に相当するコンピュータのスキップカウンタが１以上だった場合は（ステップＤ２）スキップ対象となるため、スキップカウンタから１を減らし（ステップＤ３）、現在位置を次のコンピュータに進める（ステップＤ５）。その後、ステップＤ２に戻り、再度参照検索を行う。
【００１７】
ステップＤ２でスキップカウンタが０だった場合は（ステップＤ２）スキップ対象とならず、図４より現在位置のサーバ（コンピュータ２又は３）に相当する参照を検索する。もし現在位置に参照が存在しない場合は（ステップＤ４）、現在位置を次のサーバに進めて（ステップＤ５）、ステップＤ２に戻り再度参照検索を行う。ステップＤ４で参照が存在する場合は、その参照を取得し（ステップＤ６）、現在位置を次のサーバに進める（ステップＤ７）。その後、ステップＤ６で取得した参照をクライアントに渡す（ステップＤ８）。
【００１８】
次に、サーバ側の動作について図５のフローチャート及び図６の応答変換テーブル１７又は１８を参照して説明する。
図５において、サーバ２はまずネットワーク上の他のサーバ３の負荷・生存監視部２０等を検出し、それらとの接続を確立する（ステップＢ１）。その後、サーバオブジェクト１１を起動し、その参照を参照管理テーブル２２に登録する（ステップＢ２）。
クライアントからの要求をＯＲＢ７が受信すると（ステップＢ３）、負荷・生存監視部１９は、自サーバ２の負荷状態や、ステップＢ１で接続を確立した他のサーバ３の負荷・生存監視部２０からそのサーバの負荷状態をチェックする（ステップＢ４）。もし自サーバ２の負荷が許容量を超えており、他のサーバの負荷よりも高い場合は（ステップＢ５）、名前サーバ２１にスキップ通知を送信する（ステップＢ６）。名前サーバ２１はサーバ２のスキップカウンタの値を予め指定された値にする。次に負荷超過の応答を送信する（ステップＢ７）。
【００１９】
一方、ステップＢ５で負荷の許容量を超えていない場合、あるいは超えていても他のサーバより負荷が低い場合には、要求をサーバオブジェクト１１で処理し、応答を送信する（ステップＢ８）。この応答は応答変換部１５に渡され、図６の応答変換テーブルの受信応答に該当するものかをチェックされる（ステップＢ９）。該当する場合は、応答変換テーブルに従い応答を変換する（ステップＢ１０）。その後、応答をＯＲＢ７で受信し（ステップＢ１１）、クライアントに返す（ステップＢ１２）。そしてサーバ終了指示がない場合には（ステップＢ１３）、ステップＢ３に戻りクライアントからの要求待ちとなる。サーバ終了指示があれば、サーバ２の参照を参照管理テーブル２２から削除した後、サーバ２を停止させる（ステップＢ１４）。
【００２０】
次に、サーバに障害が発生した場合の動作について図７のフローチャートを参照して説明する。
図７において、サーバ２（コンピュータ２）が障害で停止すると（ステップＣ１）、このサーバ２の負荷・生存監視部１９と接続を確立しているサーバ３の負荷・生存監視部２０が接続の切断を検出する（ステップＣ２）。負荷・生存監視部２０は名前サーバ２１にサーバ２の参照を削除するように要求を送信する（ステップＣ３）。名前サーバ２１では、参照管理テーブル２２の現在位置がサーバ２となっているかをチェックし（ステップＣ４）、そうであれば現在位置を次のサーバに進める（ステップＣ５）。最後にサーバ２の参照をすべて削除する（ステップＣ６)。
【００２１】
次に、具体例を用いて説明する。
サーバ２内のサーバオブジェクト１１、及びサーバ３内のサーバオブジェクト１２で実行される処理Ａに対し、コンピュータ４内のクライアント１３と、コンピュータ５内のクライアント１４よりそれぞれＲ１，Ｒ２という要求があるとし、クライアントが再試行するのは、サーバ側からのコネクション切断が行われた場合とする。また、要求実行時はサーバ２の負荷が許容量を超えており、サーバ３は超えていないものとする。応答変換テーブル１７，１８は図６のようになっているものとし、参照管理テーブル２２はサーバオブジェクト１１，１２の起動時点では図４のようになっているものとする。また、負荷超過時のスキップカウンタの値は１とする。
【００２２】
まず、クライアント１３が処理Ａを行うために位置情報を名前サーバ２１に問い合わせる（ステップＡ１）。名前サーバ２１は、この位置情報を示す参照を取得する要求が届くと（ステップＤ１）と、要求された処理Ａに対する現在位置を図４に基づいて取得する。これがサーバ２であり、この現在位置に相当するサーバ２のスキップカウンタが０であるため、スキップ対象とならずサーバ２に相当する参照を図４より検索する。検索の結果、参照Ａ２が存在するため（ステップＤ４）、その参照Ａ２を取得し（ステップＤ６）、処理Ａの現在位置をサーバ３に進める（ステップＤ７）。その後、ステップＤ６で取得した参照Ａ２をクライアント１３に渡す（ステップＤ８）。
【００２３】
クライアント側に戻り、この参照Ａ２に基づいてサーバオブジェクト１１に対して処理要求Ｒ１を送信する（ステップＡ２）。この要求Ｒ１はクライアント１３のＯＲＢ９で受信される（ステップＡ３）。ＯＲＢ９は、要求先のサーバオブジェクト１１が存在するサーバ２に対し、ＣＯＲＢＡ通信用に要求を変換し送信する（ステップＡ４）。サーバ２は、クライアント１３からの要求をＯＲＢ７が受信すると（ステップＢ３）、負荷・生存監視部１９が自サーバの負荷状態や、接続を確立したサーバ３の負荷・生存監視部２０からのサーバ３の負荷状態をチェックする（ステップＢ４）。
【００２４】
サーバ２の負荷が許容量を超えているため（ステップＢ５）、名前サーバ２１にスキップ通知を送信し（ステップＢ６）、名前サーバ２１はサーバ２のスキップカウンタの値を１とする。次に、負荷超過の応答を送信する（ステップＢ７）。この応答は応答変換部１５に渡され、図６の応答変換テーブルの受信応答に該当するものかチェックされる（ステップＢ９）。負荷超過が存在するため、応答変換テーブルに従い応答を変換し、コネクション切断とする（ステップＢ１０）。その後、応答をＯＲＢ７で受信し（ステップＢ１１）、コネクション切断を行う(ステップＢ１２)。
【００２５】
クライアント１３のＯＲＢ９はコネクション切断を認識する（ステップＡ５）。この応答をクライアント１３に返す(ステップＡ６)。コネクション切断は再試行を行う応答であるため（ステップＡ７）、ステップＡ１に戻り、再度名前サーバ２１から参照を取得する処理を行う。名前サーバ２１は、この参照を取得する要求が届くと（ステップＤ１）、要求された処理Ａに対する現在位置を図４に基づいて取得する。
【００２６】
今度はこの現在位置がサーバ３であり、このサーバ３のスキップカウンタは０であるため、スキップ対象とならずサーバ３に相当する参照を図４から検索する。検索結果、参照Ａ３が存在するため（ステップＤ４）、その参照Ａ３を取得し（ステップＤ６）、処理Ａの現在位置を進め、再びサーバ２となる（ステップＤ７）。その後、ステップＤ６で取得した参照Ａ３をから１３に返す(ステップＤ８)。
【００２７】
クライアント１３は、この参照Ａ３が指し示すサーバオブジェクト１２に対し処理要求Ｒ１を送信する（ステップＡ２）。この要求Ｒ１はクライアント１３のＯＲＢ９で受信される（ステップＡ３）。ＯＲＢ９は、要求先のサーバオブジェクト１２が存在するサーバ３に対し、ＣＯＲＢＡ通信用に要求を変換して送信する（ステップＡ４）。サーバ３は、クライアント１３からの要求をＯＲＢ８が受信すると（ステップＢ３）、負荷・生存監視部２０は自サーバ３の負荷や接続を確立したサーバ２の負荷・生存監視部１９からサーバ２の負荷状態をチェックする（ステップＢ４）。
【００２８】
サーバ３の負荷は許容量を超えていないため（ステップＢ５）、要求Ｒ１をサーバオブジェクト１２で処理し、応答を送信する（ステップＢ８）。この応答は応答変換部１６に渡され、図６の応答変換テーブル１７（１８）の受信応答に該当するものかをチェックされるが、該当するものはないため変換は行わない（ステップＢ９）。その後、応答をＯＲＢ８で受信し（ステップＢ１１）、クライアント１３に返す（ステップＢ１２）。クライアント１３側のＯＲＢ９が応答を受信し（ステップＡ５）、この応答をクライアント１３に渡す（ステップＡ６）。この応答は正常に要求が終了した応答なので、以上で要求Ｒ１は完了となる。
【００２９】
次に、要求Ｒ２の流れについて説明する。まず、クライアント１４が処理Ａを行うために位置情報を名前サーバ２１に問い合わせる（ステップＡ１）。名前サーバ２１は、この参照を取得する要求が届くと（ステップＤ１）、要求された処理Ａに対する現在位置を図４から取得する。ここは現在はサーバ２となっている。この現在位置に相当するサーバ２のスキップカウンタが１となっているため（ステップＤ２）、スキップ対象となる。そのためスキップカウンタから１を減らし０とし（ステップＤ３）、現在位置を次のサーバ３に進める（ステップＤ５）。その後、再度要求された処理Ａに対する現在位置を図４から取得する。今度はここがサーバ３となっている。この現在位置に相当するサーバ３のスキップカウンタが０となっているため（ステップＤ２）、スキップ対象とならずサーバ３に相当する参照を図４より検索する。検索結果、参照Ａ３が存在するため（ステップＤ４）、その参照Ａ３を取得し（ステップＤ６）、処理Ａの現在位置をサーバ２に進める（ステップＤ７）。その後、ステップＤ６で取得した参照Ａ３を返す（ステップＤ８）。
【００３０】
クライアント１４は、この参照Ａ３が指し示すサーバオブジェクト１２に対して処理要求Ｒ２を送信する（ステップＡ２）。この要求Ｒ２はクライアント１４側のＯＲＢ１０で受信される（ステップＡ３）。ＯＲＢ１０は、要求先のサーバオブジェクト１２が存在するサーバ３に対し、ＣＯＲＢＡ通信用に要求を変換し送信する（ステップＡ４）。サーバ３は、クライアント１４からの要求をＯＲＢ８が受信すると（ステップＢ３）、負荷・生存監視部２０は自サーバ３の負荷状態や接続を確立したサーバ２の負荷・生存監視部１９からサーバ２の負荷状態をチェックする（ステップＢ４）。サーバ３の負荷状態が許容量を超えていないため（ステップＢ５）、要求Ｒ２をサーバオブジェクト１２で処理し、応答を送信する（ステップＢ８）。この応答は応答変換部１６に渡され、図６の応答変換テーブルの受信応答に該当するものかをチェックされるが、該当するものはないため変換は行わない（ステップＢ９）。その後、応答をＯＲＢ８で受信し（ステップＢ１１）、クライアント１４に渡す（ステップＢ１２）。この応答をクライアント１４側のＯＲＢ１０が受信し（ステップＡ５）、クライアント１４に返す(ステップＡ６)。この応答は正常に要求が終了した応答なので、これで要求Ｒ２は完了となる。
【００３１】
以上のように、本実施の形態においては、前記第１の問題点については、従来のクライアントに一般的に備えているエラー時の再試行処理を負荷超過時にもそのまま利用できるようにサーバ側で応答変換を行うようにすることにより解決した。また、前記第２の問題点については、負荷チェックはサーバ側で行ない、別サーバの選択に関しては名前サーバで行なうというように分けることにより、毎回行なわなくてはいけない負荷チェックは呼び出しの延長で行い、負荷が高いときのみ名前サーバへ別サーバの参照を要求するようにすることにより解決した。
【００３２】
従って、本実施の形態によれば、次の効果を得ることができる。
第１の効果は、サーバの負荷を平準化できることにある。その理由は、サーバの負荷が高くなった時点でクライアント側は負荷の高くない他のサーバの参照を取得し、そのサーバに処理要求を行うためである。
第２の効果は、クライアント側は何の変更を行なくても適用可能であることにある。その理由は、サーバの負荷が高い場合は、サーバ側で要求クライアントが再試行を行うようなエラーに変換してから返すことにより、従来のクライアントで一般的に兼ね備えているエラー時の再試行処理を利用することができるためである。
【００３３】
第３の効果は、サーバに障害が発生した場合にも対応できることにある。その理由は、サーバ間で接続を確立することにより、サーバの障害を他のサーバが即座に検出することができるようになり、クライアントから呼び出されないように障害サーバの参照を削除するためである。
第４の効果は、名前サーバへの通信を軽減できることにある。その理由は、クライアントからサーバに要求を送信する際に毎回名前サーバに参照を問い合わせるのではなく、要求を送信したサーバの負荷が高い場合にのみ、名前サーバに問い合わせを行い、他のサーバの参照を取得するためである。
【図面の簡単な説明】
【００３４】
【図１】本発明の実施の形態による分散オブジェクトシステムのブロック図である。
【図２】クライアントの動作を示すフローチャートである。
【図３】サーバが名前サーバから参照を取得する処理を示すフローチャートである。
【図４】参照管理テーブルの構成図である。
【図５】サーバの動作を示すフローチャートである。
【図６】応答変換テーブルの構成図である。
【図７】サーバに障害が発生した場合の動作を示すフローチャートである。
【符号の説明】
【００３５】
１    ネットワーク
２，３    サーバコンピュータ
４，５    クライアントコンピュータ
６    名前サーバコンピュータ
７，８，９，１０    ＯＲＢ
１１，１２    サーバオブジェクト
１３，１４    クライアントアプリケーション
１５，１６    応答変換部
１７，１８    応答変換テーブル
１９，２０    負荷・生存監視部
２１    名前サーバ
２２    参照管理テーブル
【図１】
2005267547.tif 000003
【図２】
2005267547.tif 000004
【図３】
2005267547.tif 000005
【図４】
2005267547.tif 000006
【図５】
2005267547.tif 000007
【図６】
2005267547.tif 000008
【図７】
2005267547.tif 000009