(57)【特許請求の範囲】
【請求項１】
１つのリモートプロシジャコールの要求に対応し、グループ化された複数のサーバを呼び出すリモートプロシジャコール処理方法において、
前記サーバグループの任意の１つにグループ構成の変更が通知され、その通知を受け取ったサーバが自らが保持している変更通番の値をインクリメントして自らの変更情報を変更し、一方リモートプロシジャコール要求元は、グループ化された各サーバへ送信するプロシジャの実行要求に、呼び出すサーバ毎に記憶している現在の変更情報を付加して送信し、
前記サーバの各々は前記実行要求の１つを受信すると、それに対応するプロシジャの実行を行なうと共に、実行要求に付加されている変更情報と自らの保持する変更情報を比較して不一致のときに、前記要求元に返送する応答メッセージに前記実行結果と共に変更フラグをセットし、
前記応答メッセージを受信した要求元は、前記変更フラグがセットされているとき、自分が呼び出すサーバグループのメンバを変更することを特徴とするリモートプロシジャコール処理方法。
【請求項２】
１つのリモートプロシジャコールの要求に対応し、グループ化された複数のサーバを呼び出すにあたり、前記サーバグループのメンバの中からリモートプロシジャコール要求元によって任意に選択した１つのサーバを代表して呼び出し、この呼び出された代表サーバは自らの処理を実行するとともに、前記要求元から要求された内容を複製して残りのメンバのサーバを呼び出すリモートプロシジャコール処理方法において、
前記サーバグループの任意の１つにグループ構成の変更が通知され、その通知を受け取り追加または削除する変更サーバの変更情報を保持しているサーバは、前記要求元から前記代表サーバへプロシジャの実行要求が出され、前記代表サーバから複製の要求内容を転送されたとき、そのプロシジャ実行による実行結果に前記変更情報を付加した応答メッセージを前記代表サーバに返送し、前記代表サーバは、自分が呼び出すサーバグループのメンバを前記変更情報に基づいて変更することを特徴とするリモートプロシジャコール処理方法。
【請求項３】
請求項１または２において、前記グループ構成の変更として、前記サーバグループに新規サーバを追加し、前記新規サーバの追加を検知したリモートプロシジャコールの各要求元が、このときまで処理要求先としていたサーバと前記新規サーバのいずれかを新たな処理要求先とするか選択し、プロシジャ実行側が行う処理を前記グループ内のサーバ間で分散させることを特徴とするリモートプロシジャコール処理方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、分散処理システムで用いられる通信処理技術、とりわけ依頼応答通信の１つであるリモートプロシジャコール（以下、ＲＰＣと略称）の処理技術に係わり、特に、サーバをグループした構成のシステムにおいて、サーバグループの構成を変更する方法に関する。
【０００２】
【従来の技術】
ＲＰＣは特にクライアント・サーバシステムにおける通信技術として定着し、クライアントからサーバへの１対１の依頼・応答通信を行なうものである。たとえば、複数の情報処理装置がネットワークを介して相互に接続された分散処理システムにおいて、ある処理装置内に存在するクライアントが、自分の処理装置内に存在するプロシジャ呼び出しと同じ手法によって他の処理装置内に存在するサーバー側が提供するプロシジャを呼び出し、その実行結果を受けとる。代表的なＲＰＣとしては、ＯＳＦ（Ｏｐｅｎ  Ｓｏｆｔｗａｒｅ  Ｆｏｕｎｄａｔｉｏｎ）のＤＣＥ（Ｄｉｓｔｒｉｂｕｔｅｄ  Ｃｏｍｐｕｔｉｎｇ  Ｅｎｖｉｒｏｎｍｅｎｔ）での採用例がある。以下では、この例をＤＣＥ／ＲＰＣと呼ぶ。
【０００３】
ＤＣＥ／ＲＰＣでは、ディレクトリ・サーバと呼ばれるアプリケーションサーバが、分散処理システム内に存在するすべてのアドレス情報を管理している。クライアントはこのディレクトリ・サーバに問い合わせて呼び出したいサーバのアドレス情報を取得し、ＲＰＣによりこのアドレス情報のサーバを呼び出す。ＤＣＥ／ＲＰＣでは、新しいサーバを分散処理システム内に追加する際に、まずディレクトリ・サーバに自分のアドレス情報を登録して、クライアントがサーバのアドレスを参照できるようにしている。
【０００４】
【発明が解決しようとする課題】
ＤＣＥ／ＲＰＣなど従来のＰＲＣ処理技術では、クライアントはディレクトリ・サーバを検索することでしか、新しいサーバの追加を検出できない。このため、同一処理を行なうサーバをグループ化して多重化サーバとし、クライアントがグループのすべてのサーバにアクセスするような場合（デュアル方式の多重化など）、オンラインでのサーバの追加が困難になる。
【０００５】
すなわち、オンラインでの追加には、すべてのクライアントが常時ディレクトリ・サーバを検索していることが必要で、ネットワークやディレクトリ・サーバ、さらにはクライアントの負荷が増大してしまうからである。この結果、ディレクトリ・サーバへのアクセススループットが低下すると、サーバグループへのＲＰＣの処理も遅くなる。
【０００６】
この場合、ディレクトリ・サーバの検索周期を長くして負荷の低減をはかると、タイミングによりあるクライアントは追加サーバを呼び出せ、別のサーバは呼び出せないというように、多重化サーバの構成が不整合となる。たとえば多重化ファイルや多重化データベースが不整合な場合、ＲＰＣ処理ひいてはシステムの信頼性が著しく低下する。
【０００７】
サーバの変更をブロードキャスト通信を用いて、即座にすべてのクライアントに伝達する方法が考えられる。このためには、クライアントが常にネットワークからの受信準備をしている必要があり、メモリやマシン負荷が増大する。一般に、クライアント・サーバシステムは、クライアント側に比較的処理能力の低い計算機が用いられることが多く、かかる計算機の負担が大きい。また、ブロードキャストによる送信は必ず受信されるという保証がなく、メッセージ抜けが発生したり、クライアントがサーバの変更情報を受信しない可能性がある。たとえば、クライアントが動作不能状態の場合に変更情報は反映されない。
【０００８】
本発明の目的は、従来技術の問題点に鑑み、複数のサーバによるサーバグループの構成の変更を、負荷を増大させることなくクライアント側が直ちに検知できるリモートプロシジャコール処理方法あるいは通信方法を提供することにある。
【０００９】
【課題を解決するための手段】
上記の目的は、１つのリモートプロシジャコールの要求に対応し、グループ化された複数のサーバを呼び出すリモートプロシジャコール処理方法において、前記サーバグループの構成の変更に際し、追加または削除する変更サーバの変更情報を、前記サーバグループに所属する任意のサーバが保持し、このサーバが各々のリモートプロシジャコール要求元から出された実行要求に対応する実行結果を要求元に返すときに、前記実行結果に前記変更情報を付加することにより達成される。
【００１０】
サーバグループの変更はグループの任意の１つに通知され、それを受け取ったサーバが前記変更情報を保持し、前記プロシジャの実行結果を応答メッセージとして前記要求元に返す際に前記変更情報を付加する。一方、前記要求元は自らが呼び出すサーバグループのメンバを前記変更情報に基づいて変更する。
【００１１】
前記要求元は、予め自らが呼び出すサーバグループのアドレス情報と現在の変更情報を保持していて、前記応答メッセージの変更情報と自分の保持する変更情報を比較し、相違するときに自らのグループ情報を変更する。
【００１２】
または、リモートプロシジャコール要求元はグループの各サーバに送信する要求メッセージに、各々のプロシジャ実行要求と、保持している現在の変更情報を付加し、それを受け取ったサーバが、プロシジャの実行結果を応答メッセージとして前記要求元に返す際に、自分の保持する変更情報と前記要求メッセージの変更情報が相違するとき、グループ構成変更フラグをセットする。前記要求元は応答メッセージに前記変更フラグがセットされているとき、自分が呼び出すサーバグループのメンバを変更する。
【００１３】
他の発明として、前記サーバグループのメンバの中からリモートプロシジャコール要求元によって任意に選択した１つのサーバを代表して呼び出し、この呼び出された代表サーバは自らの処理を実行するとともに、前記要求元から要求された内容を複製して残りのメンバのサーバを呼び出すリモートプロシジャコール処理方法において、前記グループ構成の変更の通知を受け取りその変更情報を保持しているサーバは、前記要求元から前記代表サーバへプロシジャの実行要求が出され、前記代表サーバから複製の要求内容を転送されたとき、そのプロシジャ実行による実行結果に前記変更情報を付加した応答メッセージを前記代表サーバに返送し、前記代表サーバは自らが呼び出すサーバグループのメンバを前記変更情報に基づいて変更することを特徴とする。
【００１４】
代表サーバは、メンバの変更を行なったとき、自らの保持する変更情報を更新し、この変更情報とグループ内の各サーバの実行結果を含む応答メッセージをリモートプロシジャコール要求元に送信する。要求元は、代表サーバからの応答メッセージの変更情報と自らの保持するそれを比較し、相違するときに自らのグループ情報を変更する。
【００１５】
上記において、前記サーバグループの任意の１つにグループ構成の変更が通知される前に、システム内のサーバのアドレスを管理するネームサーバに対し変更サーバのアドレスを登録または削除し、リモートプロシジャコール要求元あるいは前記代表サーバが前記変更情報を受け取ったときに、前記ネームサーバからアドレス情報を取得し、自らが呼び出すサーバグループのメンバを変更することを特徴とする。
【００１６】
このサーバグループのメンバを変更する際に、各サーバが具備するプロシジャの処理内容を識別するための識別子に基づいてグループ構成の制約をチエックし、前記メンバ変更の可否を判定する。たとえば、ある識別子のグループ内での追加または削除に制限がある場合、その制限を越える追加または削除を禁止する。
【００１７】
上記サーバは、プロシジャとして提供されるプログラムである。あるいは、実行要求に従い自らの処理を実行しその結果を要求元に返す、または結果は返さないプログラムである。
【００１８】
本発明の構成によれば、クライアントとサーバ間で行なわれるＲＰＣ処理に、サーバグループの構成変更を検知して、サーバの変更を自動的に行う機能を持たせているので、従来ユーザが行っていた、クライアントが呼び出し先サーバを変更するために必要な情報の収集処理や、この情報を全クライアントに反映するタイミングの制御といった処理を自動化できる。
【００１９】
これによれば、多重化サーバグループに既存のサーバと同機能をもつサーバを追加し、多重化サーバの多重度をオンラインで可変することができる。または、前記サーバグループに新規サーバを追加し、前記新規サーバの追加を検知した各々のリモートプロシジャ要求元が、このときまで処理要求先としていたサーバと前記新規サーバのいずれかを新たな処理要求先とするか選択し、プロシジャ実行側が行う処理を前記グループ内のサーバ間で負荷分散させることができる。あるいは、前記サーバグループに新バージョンの新規サーバを追加し、前記新規サーバの追加を検知した各々のリモートプロシジャ実行要求元が、このときまで処理要求先としていたサーバの代わりに前記新規サーバを処理要求先として切り替え、オンラインのバージョンアップを行なうことができる。
【００２０】
【発明の実施の形態】
以下、本発明の実施の形態を図面にしたがって詳細に説明する。実施例１は、サーバグループの変更を含むＲＰＣ処理、実施例２はサーバ側に変更処理を行なわせる代案、実施例３は間接マルチキャスト方式による代案を示す。また、実施例４はサーバグループの変更をＲＰＣに代えて依頼応答通信によって処理する例を示し、各図を通し原則として、同等の要素には同一の符号を付している。
【００２１】
〔実施例１〕
図１は、本発明の一実施例で、ＲＰＣを使用した分散システムの機能ブロック図を示す。処理装置２〜８は通信媒体１に接続されて、他の処理装置との間で通信を行う。通信媒体１としては、ＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）やＷＡＮ（Ｗｉｄｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）、あるいはＷｉｒｅｌｅｓｓ（無線）等の通信回線を用いる。バス型を例に示しているが、二重化バス型、一重ループ型、二重ループ型、リング型などの種々のネットワークを用いることができる。まず、ＲＰＣを使用した分散システムの構成について説明し、その後グループへの処理装置の追加を例にして、グループ構成の変更処理を説明する。
【００２２】
処理装置２はクライアントとＲＰＣ処理部を具備しており、ＲＰＣを用いて他の処理装置に対して処理の実行を要求する。処理装置３〜６はサーバとＲＰＣ処理部２０を具備しており、他の処理装置から要求された処理を実行し、その結果を要求元に返す。処理装置３〜５はグループ化されて多重化サーバ８０を構成している。
【００２３】
処理装置２のクライアント１５は、ユーザによって作成、あるいは利用されるユーザプログラム、アプリケーションプログラム等であり、処理のために必要な情報の参照を、他の処理装置に提供されているサーバのプロシジャに要求するものである。クライアント１５は、サーバのプロシジャの実行を要求する際、ＲＰＣ要求をＲＰＣ処理部１０に対して発行する。
【００２４】
ＲＰＣ処理部１０は、クライアント１５のＲＰＣ要求処理を代行する。ＲＰＣ処理部１０はクライアント１５から発行されたＲＰＣ要求を受け、他の処理装置に対し、サーバのプロシジャ実行要求をＲＰＣ要求メッセージとして送信し、自らが送信したＲＰＣ要求メッセージに対応するプロシジャ実行結果が付されたＲＰＣ応答メッセージを受信し、要求元のクライアント１５に返す機能を有する。
【００２５】
処理装置３は、ＲＰＣ処理部２０とサーバ２５とを具備しており、他の処理装置から要求された処理を実行し、その結果を要求元に返す。ＲＰＣ処理部２０は、他の処理装置から送信されたＲＰＣ要求メッセージを受信し、実行要求されたサーバのプロシジャを実行し、その実行結果を付したＲＰＣ応答メッセージを要求元の処理装置に対して送信する。
【００２６】
サーバ２５は、ＲＰＣ処理部２０からの要求に応じて自らを実行し、その実行結果をＲＰＣ処理部２０に返すプログラムであって、プロシジャの形で提供される。サーバ２５は、ユーザにより作成あるいは利用されるプログラムであって、クライアントの処理に必要な情報を提供するプログラムである。
【００２７】
システム内には、その目的や用途に応じた複数のサーバが種々に組み合わされて存在する。各々のサーバには、自身がどのような内容の処理を行うかを示す処理識別子が付与され、その処理内容が識別される。処理識別子としては、例えば、サーバが提供するプロシジャのプロシジャ名や、プロシジャを一意に識別するＩＤ番号などを用いる。図示のサーバ２５は、処理識別子がそれぞれ「ＱＳＯＲＴ」のサーバ４０１、「ＡＳＯＲＴ」のサーバ４０２及び「ＢＳＯＲＴ」のサーバ４０３が含まれている。
【００２８】
処理装置４〜６も、処理装置３と同様の構成であり、それぞれサーバ３５，４５，５５とＲＰＣ処理部３０，４０，５０を具備する。ＲＰＣ処理部３０、４０、５０は、ＲＰＣ処理部２０と同様の機能を有する。また、サーバ３５はサーバ２５と同様に、サーバ４１１〜４１３からなる。サーバ４５はサーバ４２１，４２２と、識別子が「ＣＳＯＲＴ」のサーバ４２３からなる。さらに、グループ外の処理装置６のサーバ５５には、サーバ４５と同じサーバ４３１，４３２及び４３３が含まれている。
【００２９】
処理装置７は、アドレス管理部６０を具備しており、システム内に存在するサーバを具備している処理装置３〜６のアドレスを管理している。アドレス管理部６０は、他の処理装置からの要求に応じて、アドレス情報の追加、削除あるいは参照処理を行い、処理結果を要求元に返す。
【００３０】
処理装置８は、グループ構成変更通知部７０を具備しており、ユーザからのコマンド入力等により、サーバグループの構成変更すなわちサーバグループ８０へのサーバの追加あるいは削除の要求を受けつけ、そのイベントをサーバグループ８０のサーバへ通知する。
【００３１】
本実施例では、サーバ２５，３５，４５からなるサーバグループ８０に対し、サーバ５５を追加する変更処理を例に、本発明のリモートプロシジャコール処理方式を説明する。サーバのグループ化には種々の手法があるが、本実施例では同一の処理識別子をもつサーバを１つのグループとして扱う。この場合、同一グループ内のすべてのサーバがまったく同じ処理を行う必要はなく、図１の例のように処理内容が異なっていてもよい。
【００３２】
次に、グループ化されたサーバへのＲＰＣ処理の概要について説明する。クライアント１５は、ＲＰＣ処理部１０を介し、サーバグループ８０にプロシジャの実行要求を送信する。ただし、ＲＰＣ処理部１０は、クライアント１５が発行したＲＰＣ要求の内容から、それを処理できるサーバグループとそれに属するサーバを判定し、そのサーバを具備する処理装置すべてに対してＲＰＣ要求メッセージを送信する。この判定は、クライアント１５がＲＰＣ処理部１０に対してＲＰＣ要求を発行した際、クライアント１５から渡された処理識別子を基に行う。
【００３３】
サーバグループ８０内の処理装置のうち、ＲＰＣ要求メッセージを受け取った各処理装置のＲＰＣ処理部は、要求された処理の実行可能なサーバを実行し、その実行結果をＲＰＣ応答メッセージとして要求元の処理装置２に送信する。要求元のＲＰＣ処理部１０は、ＲＰＣ要求メッセージを送信した各処理装置からのＲＰＣ応答メッセージを受信し、その中から予め決められた論理に基づいて１つのＲＰＣ応答メッセージを選択し、そこに含まれているサーバの実行結果をクライアント１５に返す。この選択に用いる論理としては、「ランダムに１つを選択する」、「応答内容を基に多数決論理に基づいて１つを選択する」、「最先着のものを選択する」などの論理を用いることができる。
【００３４】
次に、各処理装置間で伝送されるＲＰＣメッセージのフォーマットを説明する。図２は、サーバグループの構成変更を通知するＲＰＣメッセージのフォーマットを示す。サーバー変更通知ＲＰＣメッセージ１００は、グループ構成変更通知部７０から送信され、ＲＰＣ制御ヘッダ部１０１と変更サーバ処理識別子部１０３で構成される。ＲＰＣ制御ヘッダ１０１にはＲＰＣ要求メッセージ、ＲＰＣ応答メッセージの送受信に伴う処理の制御に必要な情報が格納される。その一部のエリアであるＲＰＣ要求内容識別子部１０２には、ＲＰＣで要求される処理内容を受信側のＲＰＣ処理部で識別できる処理識別子が格納される。また、送信先アドレス、送信元アドレス、送信通番、要求／応答の識別情報などが格納されるエリアも有している。変更サーバ処理識別子部１０３には、たとえばサーバグループ８０に追加されるサーバ５５の処理内容を表わす処理識別子が格納される。
【００３５】
図３は、ＲＰＣ要求メッセージのフォーマットを示す。ＲＰＣ要求メッセージ１１０は、ＲＰＣ処理部１０がクライアント１５のＲＰＣ要求に応じて送信するもので、ＲＰＣ制御ヘッダ部１０１とクライアントの要求データ部１１１から構成される。クライアント要求データ部１１１には、サーバを実行するためのサーバプロシジャの入出力引数が格納される。
【００３６】
図４は、ＲＰＣ応答メッセージのフォーマットを示している。ＲＰＣ応答メッセージ１２０は、ＲＰＣ処理部２０〜５０が自処理装置のサーバの実行結果をクライアントへ送信するもので、ＲＰＣ制御ヘッダ部１０１、サーバ実行結果データ部１２２と、グループ構成変更通番部１２１から構成される。サーバ実行結果データ部１２２にはサーバの実行結果が格納される。グループ構成変更通番部１２１は本実施例に特有なもので、サーバの追加などサーバグループの構成変更のたびにインクリメントされるグループ構成変更通番が格納される。
【００３７】
グループ構成変更通番（以下、変更通番と呼ぶ）は、サーバを具備する各処理装置が独立に管理している変更通番である。１つの処理装置内には、自身が具備するサーバが所属するグループ毎に、対応する１つの変更通番が保持される。サーバグループの変更履歴を管理するために、サーバの追加や削除など、構成変更の種類に対応した種類別の変更通番が用意されてもよい。本実施例では、サーバを追加または削除する通知ＲＰＣメッセージ１００を受信したとき、後述のようにこの変更通番がインクリメントされる。
【００３８】
一方、ＲＰＣ要求側は後述のように、予めＲＰＣ要求を発行する対象サーバグループの全サーバの変更通番を保持している。そして、ＲＰＣ応答メッセージ１２０を受信したとき、メッセージに格納された変更通番と保持している変更通番を比較し、変更通番の不一致によってサーバグループの変更を検知する。
【００３９】
以上、システム構成の概略とメッセージフォーマットを説明した。次に、本実施例のリモートプロシジャコールを実施するシステムの詳細な構成と、各部の処理について説明する。なお、処理装置１〜６が具備するＲＰＣ処理部、処理装置７が具備するアドレス管理部６０、処理装置８が具備するグループ構成変更通知部７０の順に説明する。
【００４０】
図５は、処理装置の詳細な構成を示す。図示の処理装置２は一例を示したもので、他の処理装置３〜８においても同様な構成としてよい。処理装置２はＲＰＣ処理部１０と共に、クライアント１５とサーバ１６の両方を具備している。ＲＰＣ処理部１０は、ＲＰＣクライアント処理部１１、ＲＰＣサーバ処理部１２、アドレス管理テーブル１３、グループ管理テーブル１４を具備している。アドレス管理テーブル１３は、各処理装置がサーバグループに属するサーバの情報を格納する。アドレス管理テーブル１３は、サーバの処理内容を表す処理識別子と、そのサーバを具備する処理装置のアドレスを格納する。
【００４１】
なお、処理装置がクライアント処理専用であれば、サーバ１６やＲＰＣサーバ処理部１２は不要となる。また、処理装置がサーバ処理専用の場合は、クライアント１５とＲＰＣクライアント処理部１１は不要であり、本実施例の場合にはアドレス管理テーブル１３も不要となる。
【００４２】
また、複数のＲＰＣ処理部を設けて、クライアントやサーバからのＲＰＣ処理を分担してもよい。この場合、他の処理装置からＲＰＣ要求メッセージを送出する際の宛先アドレスは、宛先サーバの処理を担当するＲＰＣ処理部のアドレス（例えば、この処理装置のアドレスとこのＲＰＣ処理部の受信ポート番号）としてもよい。
【００４３】
図６に、アドレス管理テーブルの構成を示す。処理識別子部１３１とアドレス部１３２とから構成され、各々に格納される情報は、ＲＰＣ処理部１０がアドレス管理部６０に要求して取得する。図示は図１における構成の一部を示し、少なくとも３台の処理装置のアドレス情報を格納している。すなわち、「ＱＳＯＲＴ」で識別されるサーバを有する処理装置が３台で、各アドレスは「１３３．１４４．８．１５９：８０８０」、「１３３．１４４．８．１６０：８０５２」及び「１３３．１４４．８．１６１：８０３１」で与えられている。また、「ＡＳＯＲＴ」で識別されるサーバを有する処理装置があり、そのアドレス「１３３．１４４．９．１２０：６１９８」が格納されている。アドレスには、図示のようにＩＰアドレスと受信ポート番号との組を用いている。
【００４４】
図７に、グループ管理テーブルの構成を示す。グループ管理テーブル１４は、各処理装置がサーバグループの構成情報を格納している。同図のように、処理識別子部１４１、アドレス部１４２及びグループ構成変更通番部１４３から構成され、これら３つの情報が一組になって使用される。処理識別子部１４１、アドレス部１４２には、アドレス管理テーブル１３と同様に、サーバの処理内容を表す処理識別子とその処理装置のアドレスが格納される。
【００４５】
グループ構成変更通番部１４３には、サーバグループの構成の変更を管理する変更通番が格納される。図７（ａ）は図１のグループ構成による一部を示したもので、「ＱＳＯＲＴ」で識別されるサーバを有する処理装置が３台あり、各々のグループ構成変更通番はそれぞれ、「２」、「３」、「５」である。また、「ＡＱＯＲＴ」で識別されるサーバを有する処理装置が少なくとも１台あり、そのグループ構成変更通番は「２」である。ここで、同じＱＳＯＲＴに対する変更通番の値「２」，「３」などは、当該アドレスに対応する処理装置での変更回数を反映している。
【００４６】
図８は、ＲＰＣクライアント処理部の処理を示すフローチャートである。ＲＰＣクライアント処理部１１は、クライアント１５からのＲＰＣ要求を代行して処理する。
【００４７】
まず、クライアント１５からＲＰＣ要求を受け付ける（Ｓ１０１）。このとき、ＲＰＣクライアント処理部１１には、クライアン１５から処理要求するサーバの処理識別子と、その処理に必要な引数が渡される。
【００４８】
次に、ＲＰＣ要求を実行できるサーバを具備する処理装置のアドレスを取得するため、アドレス管理テーブル１３を検索するが、この際、最初のＲＰＣ要求でアドレス管理テーブル１３に何も登録されていなかった場合（Ｓ１０２）、アドレス管理テーブル１３の初期化処理を行う（Ｓ１０３）。
【００４９】
図９は、初期化処理Ｓ１０３を示すフローチャートである。ＲＰＣクライアント処理部１１はアドレス管理部６０に対し、アドレス管理部６０に格納された、処理識別子に対応する全てのアドレスの参照を要求するＲＰＣ要求メッセージを送信し、応答メッセージに付されたアドレス情報を取得する（Ｓ１０３１）。このアドレス情報をアドレス管理テーブル１３に登録する（Ｓ１０３２）と共に、グループ管理テーブル１４にも同様にアドレスを登録し、それに対応するグループ構成変更通番に「０」を設定する（Ｓ１０３３）。
【００５０】
次に、ＲＰＣクライアント処理部１１は、アドレス管理テーブル１３を検索し、ＲＰＣ要求を実行できるサーバを具備するすべての処理装置のアドレスを取得すし（Ｓ１０４）、その処理装置の数をカウントする（Ｓ１０５）。この検索は、クライアント１５から渡された処理識別子をキーにして行われ、アドレステーブル１５から、クライアントから渡された処理識別子と同じ処理識別子をもつ全ての処理装置のアドレスを取得する。そして、サーバグループの１つのサーバへ要求メッセージを送信する（Ｓ１０６）。すなわち、ＰＲＣ要求メッセージ１１０のクライアント要求データ部１１１に、サーバ実行に必要な引数を書き込み、Ｓ１０４で取得したアドレスで与えられる処理装置を宛先に、このＲＰＣ要求メッセージ１１０を送信する。
【００５１】
ところで、Ｓ１０４でアドレスを検索した結果、複数の処理装置のアドレスを取得した場合は、取得したすべての処理装置に対してＲＰＣ要求メッセージ１１０を送信する必要がある。そこで、ＲＰＣ要求メッセージ１１０の送信後、メッセージ送信済みの処理装置の数をカウントし（Ｓ１０７）、そのカウント値と取得したサーバグループ内のサーバの数を比較する（Ｓ１１０）。比較の結果、カウント値の方が小さい場合は、Ｓ１０４の処理で取得したアドレスの中から、まだＲＰＣ要求メッセージ１１０を送信していないアドレスを選択し（Ｓ１１１）、ＲＰＣ要求メッセージ１１０を送信する。このように、Ｓ１０６からＳ１１１までの送信処理を繰り返すことによって、サーバグループに属しＲＰＣ要求の処理識別子に対応するすべてのサーバに、ＲＰＣ要求メッセージ１１０を送信する。
【００５２】
以上が、クライアントからのＲＰＣ要求の送信処理である。ＲＰＣ要求メッセージ１１０を送信すると、ＲＰＣ要求先のサーバから応答メッセージが返送されてくる。ＲＰＣクライアント処理部１１は、自らのＲＰＣ要求先のサーバからの応答メッセージの受信をチエックし（Ｓ１０８）、以下のように応答受信処理を行なう（Ｓ１０９）。
【００５３】
図１０に、応答受信処理（Ｓ１０９）のフローチャートを示す。ＲＰＣクライアント処理部１１は、応答メッセージ１２０を受信すると（Ｓ２０１）、応答メッセージ１２０（図４）からメッセージ送信元のアドレスと、ＲＰＣ要求内容識別子、グループ構成変更通番を取得する（Ｓ２０２）。そして、自己のグループ管理テーブル１４を検索し、応答メッセージに付されていたアドレス及びＲＰＣ要求内容識別子の両方とも一致するアドレス情報を検出し、そのアドレス情報の変更通番と応答メッセージ１２０による変更通番を比較する（Ｓ２０３）。
【００５４】
比較した結果、両者の値が同じ場合は、サーバグループに変更がなかったと判断し、応答受信処理を終了する。一方、応答メッセージ１２０による変更通番の値が大きい場合、つまりインクリメントされていた場合は、サーバグループに変更があったと判断し（Ｓ２０４）、応答メッセージ１２０によるグループ構成変更通番を、グループ管理テーブル１４のアドレス情報のグループ構成変更通番部１４３に格納する（Ｓ２０５）。
【００５５】
次に、ＲＰＣクライアント処理部１１はネットワーク１を経由し、処理装置７のアドレス管理部６０に、全てのサーバのアドレスを参照するＲＰＣ要求メッセージを送信し、応答メッセージに付されたアドレス情報を取得する（Ｓ２０６）。次に、取得したアドレス情報と自分のアドレス管理テーブル１３の内容を比較し、前者に残る差分を追加サーバのアドレスとして取得する（Ｓ２０７）。
【００５６】
ここで、アドレス管理部６０から取得したアドレス情報は、処理識別子とそれに対応するアドレスの組の集合である。アドレス管理テーブル１３も同様である。比較は両集合の構成要素である組単位に行ない、その差分を求める。グループ管理テーブル１４以外にアドレス管理テーブル１３を設けるのは、この差分処理を簡単にするためである。なお、サーバを削除する変更の場合は、自分のアドレス管理テーブル１３の側に残る差分情報が削除サーバのアドレスとなる。
【００５７】
次に、本実施例では、Ｓ２０７で取得した追加サーバを具備する処理装置のアドレス情報を、アドレス管理テーブル１３に追加する（Ｓ２０８）。さらに、同様にグループ管理テーブル１４にも追加し、このとき対応するグループ構成変更通番に初期値「０」を格納する（Ｓ２０９）。
【００５８】
以上が応答受信処理（Ｓ１０９）であるが、Ｓ１０４で複数のアドレスが取得された場合、ＲＰＣ要求メッセージは複数個送信されるため、応答メッセージも同じ数だけ返送されてくる。したがって、ＲＰＣクライアント処理部１１は、すべての応答メッセージを受信するまで、応答受信処理を繰り返し（Ｓ１１２）、複数の応答メッセージに付されたサーバ実行結果データ１２２の１つを選択し、クライアント１５に渡す（Ｓ１１３）。この選択は「ランダムに選択」、「先着で、１番最初に受信したもの」など、予め決められた論理に基づいて行われる。
【００５９】
次に、ＲＰＣサーバ処理部１２について説明する。ＲＰＣサーバ処理部１２はサーバ１６のＲＰＣ要求受付、および応答返送の代行処理を行うと共に、処理装置７のグループ構成変更通知部７０から、サーバグループ構成変更を通知するＲＰＣメッセージを受信し、サーバグループ構成の変更情報を保持する。
【００６０】
図１１は、ＲＰＣサーバ処理部の処理を示すフローチャートである。ＲＰＣサーバ処理部１２は、他の処理装置から送信されたＲＰＣ要求メッセージ１１０を受信すると（Ｓ３０１）、受信メッセージの要求内容を判定する（Ｓ３０２）。この判定は、サーバ変更通知ＲＰＣメッセージ１００の処理識別子部１０３を参照することで可能になる。
【００６１】
受信メッセージがサーバグループの構成変更を通知するメッセージ場合は、自処理装置のグループ管理テーブル１４におけるグループ構成変更通番部１４３の値をインクリメントする（Ｓ３０３）。これによって、ＲＰＣ処理部１０はサーバグループの構成変更の情報を保持する。そして、ＲＰＣ要求元であるグループ構成変更通知部７０に対し、グループ構成変更の情報を保持する処理の完了を知らせる応答を返す（Ｓ３０４）。
【００６２】
一方、ステップＳ３０２の判定において、受信した要求メッセージがＲＰＣ要求メッセージ１１０の場合、ＲＰＣサーバ処理部１２はサーバを実行する（Ｓ３０５）。すなわち、受信したＲＰＣ要求メッセージ１１０のクライアント要求データ部１１１からサーバの実行に必要な引数等を取得し、サーバ１６に渡すと共に、サーバ１６のプロシジャを実行する。処理装置内に同一処理識別子をもつサーバが複数ある場合には、ランダムに１つ選択して実行するものとする。
【００６３】
サーバ１６のプロシジャ実行後、ＲＰＣサーバ処理部１２はサーバ１６から実行結果を受け取り、ＲＰＣ応答メッセージ１２０のサーバ実行結果データ部１２２に格納する。また、グループ構成変更通番部１２１のエリアには、グループ管理テーブル１４のグループ構成変更通部１４３の値を格納する（Ｓ３０６）。このＲＰＣ応答メッセージ１２０を、ＲＰＣ要求元であるクライアントへ送信する（Ｓ３０７）。したがって、このＲＰＣ要求時までに、グループ管理テーブル１４の変更通番がインクリメントされていれば、この変更通番をＲＰＣ応答メッセージに格納して送信し、クライアントにサーバグループの変更を知らせることができる。
【００６４】
以上、処理装置２〜６が具備するＲＰＣ処理部の詳細について、クライアントとサーバの両方を備える図５の処理装置の構成で説明した。上記で、図１のシステム構成におけるＲＰＣ処理は、クライアント側は処理装置２、グループサーバ側は処理装置３〜５に読み代えることで理解できる。
【００６５】
次に、処理装置７が具備するアドレス管理部６０について詳細に説明する。処理装置７のＲＰＣ処理部は図示を省略している。アドレス管理部６０は、図１に示すシステム内のサーバのアドレスを一括管理しており、ある決められた範囲内（例えば１つのネットワークセグメント内）の処理装置が具備する全てのサーバの処理識別子とその処理装置のアドレスとの対応情報を、自身の管理テーブルに保持している。アドレス管理部６０は、他の処理装置からのＲＰＣ要求メッセージに応じて、上記情報の追加、削除あるいは参照処理を行い、応答メッセージにより要求元に返す。
【００６６】
図１２は、アドレス管理部の処理を示すフローチャートである。まず、ＲＰＣ処理要求を受信すると（Ｓ４０１）、その処理要求内容を判定し（Ｓ４０２）、サーバアドレスの追加、サーバアドレスの削除またはサーバアドレスの検索の何れかを処理する。
【００６７】
サーバの追加時には、他の処理装置の要求元、例えばあるクライアントがアドレス管理部６０に対して、追加サーバを具備する処理装置のアドレスと追加サーバの処理識別子を付したＲＰＣ要求メッセージを送信する。アドレス管理部６０は要求内容がサーバアドレスの追加と判定すると、処理装置７が具備する管理テーブルに、ＲＰＣ要求メッセージに付されていたアドレスと処理識別子を追加し（Ｓ４０３）、追加処理の成否を応答メッセージとして要求元に送信する（Ｓ４０４）。
【００６８】
アドレス管理部６０は同一の処理識別子をもつサーバを１つのサーバグループとして管理する。したがって、アドレスとサーバが属するサーバグループとを管理するため、アドレスと処理識別子を対応付けて追加する。
【００６９】
次に、サーバの削除時には、他の処理装置内の要求元が、削除するアドレスとサーバの処理識別子を付したＲＰＣ要求メッセージを送信する。アドレス管理部６０は削除要求であると判定すると（Ｓ４０２）、ＲＰＣ要求メッセージに付された処理識別子とアドレスの組みと同一のアドレス情報を、自身が具備するテーブルから削除し（Ｓ４０５）、削除処理の成否を応答メッセージとして要求元へ送信する（Ｓ４０６）。
【００７０】
次に、ある処理の実行可能なサーバを有する処理装置のアドレスを参照する際には、他の処理装置内の要求元がその処理の内容を示す処理識別子を付したＲＰＣ要求メッセージを、アドレス管理部６０に送信する。要求内容がアドレスの参照と判定されると（Ｓ４０２）、アドレス管理部６０が具備する管理テーブルを検索し、ＲＰＣ要求メッセージに付された処理識別子と同じ処理識別子に対応付けられたアドレスを取り出し（Ｓ４０７）、ＲＰＣ応答メッセージに付して要求元に送信する（Ｓ４０８）。
【００７１】
ステップＳ４０７の検索よって、複数のアドレスが取得された場合は１つのアドレスをランダムに選択してもよいし、すべてのアドレスをＲＰＣ応答メッセージに付して送信してもよい。
【００７２】
次に、処理装置８が具備するグループ構成変更通知部７０について説明する。処理装置８のＲＰＣ処理部は図示を省略している。グループ構成変更通知部７０は、ユーザからのコマンド入力等により指定のサーバグループの構成変更の要求を受け付ける。たとえば、コマンドによりサーバグループ８０の構成変更の要求が行なわれ、このコマンドの引数として、追加または削除されるサーバを具備する処理装置のアドレスや、サーバの処理識別子などの情報が、グループ構成変更通知部７０に与えられる。
【００７３】
グループ構成変更通知部７０は、このコマンドを受け付けると、処理装置７のアドレス管理部６０に対して、アドレスの変更を要求するＲＰＣ要求メッセージを送信する。たとえば、新規サーバを具備する処理装置のアドレスの追加を要求するＲＰＣ要求メッセージを送信し、アドレス管理部６０にアドレスを登録すると共に、サーバグループ構成変更を通知するＲＰＣメッセージを、指定のサーバグループ８０に送信する。サーバグループ８０に属する処理装置３〜５は、このサーバグループ構成変更を通知するＲＰＣメッセージを受信し、自身のアドレス管理テーブル１３及びグループ管理テーブル１４に、サーバグループ構成の変更情報を保持する。
【００７４】
図１３は、グループ構成変更通知部によるサーバ追加処理を示すフローチャートである。グループ構成変更通知部７０は、サーバグループへのサーバの追加要求を受け取ると（Ｓ５０１）、アドレス管理部６０に、追加対象となるサーバグループに属するサーバのアドレス参照を要求するＲＰＣ要求メッセージを送信し、アドレスを取得する（Ｓ５０２）。このとき、グループに属する任意の１つのサーバのアドレスを取得してもよいし、すべてのサーバのアドレスを取得してもよい。後者の場合、グループ構成変更通知部７０が任意の１つを選択する。
【００７５】
次に、グループ構成変更通知部７０は、追加サーバのアドレスの登録を要求するＲＰＣ要求メッセージをアドレス管理部６０に対して送信し、管理テーブルへのアドレス登録を依頼する（Ｓ５０３）。次に、ステップＳ５０２で取得したアドレスのサーバへ、サーバの追加を通知するＲＰＣメッセージ１００を送信し（Ｓ５０４）、そのサーバから追加情報を記憶する処理が完了したという応答を受信する（Ｓ５０５）。
【００７６】
以上によって、本発明のリモートプロシジャコール処理を実現する、本実施例の基本的な構成と動作が明らかになった。次に、具体的なリモートプロシジャコールについて、グループサーバに対して新規サーバを追加する処理の例を説明する。この処理の全体的な流れは、サーバグループに対してサーバの追加を通知する処理、各クライアント側処理装置における追加サーバの検知処理に大別でき、この２つに分けて説明する。
【００７７】
図１４は、図１のシステムのＲＰＣ処理部を詳細にした構成図で、新規サーバを追加する処理の流れを矢線で示している。また、図１５は、クライアント側とサーバ側の各々のグループ管理テーブルの具体的な格納内容を示す説明図である。さらに、図１６は、本実施例によって新規サーバを追加するときの全体的な処理を示すフローチャートである。これらの図を参照しながら、本実施例によるサーバの追加処理を説明する。
【００７８】
グループ構成変更通知部７０は、ユーザから、サーバグループ８０へのサーバ５５の追加を受付けると、新規サーバ５５を具備する処理装置６のアドレスをアドレス管理部６０へ登録する。また、グループ構成変更通知部７０は、アドレス管理部６０からサーバグループ８０内の任意の１つのサーバのアドレス、ここではサーバ４５のアドレスを取得し、そのアドレスであるＲＰＣサーバ処理部４２宛に、矢印２０１ａのようにサーバ追加の通知ＲＰＣメッセージ１００を送信する（Ｓ６０１）。
【００７９】
ＲＰＣサーバ処理部４２は、サーバ追加の通知ＲＰＣメッセージを受信すると、ＲＰＣサーバ処理部４２内にあるグループ管理テーブル４４のグループ構成変更通番を５⇒６にインクリメントし、グループ構成変更通知部７０に処理完了の応答メッセージを送信する（Ｓ６０２）。
【００８０】
次に、クライアント側の処理装置における追加サーバの検知処理について説明する。図１７に、クライアント側における追加サーバの検知処理のフローチャートを示す。
【００８１】
クライアント１５は、たとえば処理識別子「ＱＳＯＲＴ」を含むＲＰＣ要求メッセージ１１０をＲＰＣクライアント処理部１１に出す。ＲＰＣクライアント処理部１１は、アドレス管理テーブル１３を検索し、サーバグループ８０に属する「ＱＳＯＲＴ」の実行可能なサーバを具備する処理装置３，４，５のアドレスを取得し、矢印２０５ａ，ｂ，ｃのようにＲＰＣ要求メッセージを送信する（Ｓ７０１）。このとき、グループ管理テーブル１４の「ＱＳＯＲＴ」をもつ各アドレスに対応する変更通番は、図１５のように記憶されている。
【００８２】
ＲＰＣ要求メッセージを受信した処理装置３，４，５のＲＰＣサーバ処理部２２，３２，４２は、ＲＰＣ要求に応じて矢印２０６ａ，ｂ，ｃのようにサーバを実行し（Ｓ７０２）、サーバの実行結果を矢印２０７ａ，ｂ，ｃと取得する。また、グループ管理テーブル２４，３４，４４内の変更通番を矢印２０８ａ，ｂ，ｃのように取得し、実行結果と変更通番を格納したＲＰＣ応答メッセージを矢印２０９ａ，ｂ，ｃのように送信する（Ｓ７０３）。このとき、グループ管理テーブル２４，３４，４４の「ＱＳＯＲＴ」の変更通番は図１５の内容である。
【００８３】
ＲＰＣクライアント処理部１１は、処理装置３，４，５からのＲＰＣ応答メッセージを受信し（Ｓ７０４）、ＲＰＣ応答メッセージ内の変更通番とグループ管理テーブル１４内の変更通番を比較し、グループサーバの構成が変更されたか否かを判定する（Ｓ７０５）。この処理は、図１０の応答受信処理のステップＳ２０４に相当する。
【００８４】
ここでは、処理装置５が具備するＲＰＣサーバ処理部４２は、上記のようにサーバ追加の通知ＲＰＣメッセージを受信し、グループ管理テーブル４４の「ＱＳＯＲＴ」のグループ構成変更通番を５⇒６にインクリメントし、応答メッセージに付加して矢印２０９ｃのように送信している。従って、ＲＰＣクライアント処理部１１が、ＲＰＣ応答メッセージの変更通番と、自分のグループ管理テーブル１３の同一アドレスの変更通番を比較すると、新規サーバの追加が検知できる。
【００８５】
新規サーバの追加を検知したＲＰＣクライアント処理部１１は、アドレス管理部６０からすべてのサーバのアドレス情報を取得し、自分のアドレス管理テーブル１３のアドレス情報と比較し、差分として得られるサーバ５５のアドレス情報を、アドレス管理テーブル１３、グループ管理テーブル１４に追加する（Ｓ７０６）。次に、ＲＰＣクライアント処理部１１は、処理装置３，４，５の各々から受信したＲＰＣ応答メッセージの１つを選択し、クライアント１５にサーバの実行結果として渡す（Ｓ７０７）。
【００８６】
なお、上記ではグループ構成変更通知部７０が処理装置８によって具備される構成としているが、どの処理装置が具備していてもよい。例えば、処理装置６がグループ構成変更通知部７０を具備していてもよい。このとき、サーバ５５が自身の追加要求をグループ構成変更通知部７０へ通知し、グループ構成変更通知部７０へ追加処理要求を依頼するようにしてもよい。
【００８７】
また、図１１のステップＳ３０２の判定がサーバの追加要求の場合、指定のサーバグループに新規のサーバの追加の可否を判定してから、ステップＳ３０３で追加の処理をするようにしてもよい。
【００８８】
たとえば、図１のサーバグループ８０において、グループ８０内で多重化できないサーバがあり、その処理識別子が「ＣＳＯＲＴ」であるとする。この場合に、サーバ５５を追加すると、「ＣＳＯＲＴ」のサーバが多重化されてしまう。従って、ＲＰＣサーバ処理部４２は、ＲＰＣ通知メッセージ１００の追加サーバの処理識別子を受け取ると、グループ管理テーブル１４の処理識別子と対照し、「ＣＳＯＲＴ」サーバが多重化される場合には追加処理を中断する。あるいは、サーバグループが完全多重化の構成をとる場合は、グループ管理テーブル１４の処理識別子と対照し、追加するサーバの処理識別子が同一であるか判定し、同一でなければ追加不可の応答を返す。
【００８９】
このほかにも、追加処理が許されるユーザＩＤやプログラムＩＤや認証情報を予めＲＰＣサーバ処理部内に記憶しておき、ＲＰＣ通知メッセージに要求元のユーザＩＤ、プログラムＩＤまたは認証情報を付加して送信し、受信時にこれらの情報を比較して、追加の要否を判定するようにしてもよい。
【００９０】
以上、本実施例の構成によれば、ＲＰＣを用いて１つの要求に対応して複数のサーバを並列的に呼び出すクライアント側の計算機は、各々が独立して非同期的に、複数のリモートプロシジャが構成するグループの構成変化を検出し、グループ構成変更処理を行う。また、この検出のための情報は、通常時のＲＰＣ応答に付加されてクライアント側に伝達される。したがって、グループ構成変更に際して、これに伴う追加処理メッセージがネットワーク上に集中することがなく、ネットワークの負荷、構成変更に伴い追加されたリモートプロシジャ側の計算機あるいはリモートプロシジャのアドレスを管理するネームサーバ等の負荷を時間的に分散できる。特に、クライアント側計算機がグループ構成の変更の有無を常に監視している必要がなく、自らのＲＰＣ要求時に対する応答内容から変更を検知できるので、クライアント側計算機の変更処理に伴う負荷の増大は少ない。
【００９１】
また、本実施例によれば、リモートプロシジャ側が多重化サーバを構成し、クライアントが多重化サーバにアクセスしているときに、サーバ追加の前後で各サーバにアクセスするクライアント側計算機を同じにすることができ、グループ構成の変更を行なうことができるので、サーバの内部状態の整合性が保証され、多重化サーバの通信方式として有用である。さらに、サーバの多重度をオンラインに変化させることができる。
【００９２】
本実施例では、クライアント側はグループ内の全てのサーバに対してＲＰＣ要求を発行している。しかし、グループ内の一部のサーバにＲＰＣを発行するようにしてもよい。これによれば、クライアントが追加サーバを検知したとき、それまでＲＰＣを発行していた要求先のサーバに代えて追加サーバを用い、サーバグループ内で処理の負荷分散を図ることができる。あるいは、要求先の旧バージョンに代えて新バージョンの追加サーバを用い、サーバのバージョンアップをオンラインで行うこともできる。
【００９３】
また、サーバはプロシジャの形で提供されていなくてもよい。要求に対し自らの処理を実行し、その実行結果を依頼元に返すプログラムであってもよい。すなわち、実行結果を依頼元に返すタイミングが、必ずしも自らの処理の実行終了時である必要はなく、自らの処理の実行途中に何らかのデータを依頼元に返すプログラムであってもよい。さらに、サーバが処理要求に応じて実行するプログラムは、必ずしも処理結果を出力するものである必要はない。処理終了時あるいは処理開始時等に、サーバ側のＲＰＣ処理部が実行結果データ部にデータを何も格納しないで、ＲＰＣ応答メッセージを返すようにしてもよい。
【００９４】
さらに、本実施例では同一の処理識別子は同一の処理内容を表すものとして、図１のように多重化サーバのグループ構成を示したが、これに限られるものではない。ＲＰＣではサーバが保持するプロシジャの名前や処理内容に関わらず、異なる名前や処理を行なうプロシジャをもつサーバであっても、同一の処理識別子をもつことが可能である。このような識別子の付与を行なった場合、送信側はグループ内の各サーバが保持するプロシジャの内容を意識しないで送信メッセージを送ることができるので、送信側の負荷低減をはかれる等のメリットがある。
【００９５】
〔第２の実施例〕
本実施例はグループ構成の変更の有無の検出を、第１の実施例とは異なりサーバ側で行なう。すなわち、クライアントがサーバへＲＰＣを発行する際に、ＲＰＣ要求メッセージにクライアントが保持している変更通番を格納して送出し、サーバ側がその変更通番と、自処理装置のグループ管理テーブルに記憶している変更通番を比較して、グループ構成の変更の有無を検出する。以下、第１の実施例と異なる部分を中心に説明する。なお、システム構成は第１の実施例と同じであり、以下では図１４の構成を参照する。
【００９６】
図１８に、クライアント側の処理装置が送出するＲＰＣ要求メッセージのフォーマットを示す。第１の実施例におけるＲＰＣ要求メッセージ（図３）に、クライアントが保持している変更通番を格納する、グループ構成変更通番部１１２を追加している。
【００９７】
図１９に、サーバ側の処理装置がクライアント側へ実行結果を返すＲＰＣ応答メッセージのフォーマットを示す。第１の実施例のＲＰＣ応答メッセージ（図４）に、サーバグループにおける構成変更の有無を知らせる変更フラグ部１２３を追加している。
【００９８】
ＲＰＣクライアント処理部１１が行う処理について説明する。まず、第１の実施例による処理フロー（図８）のステップＳ１０６において、ＲＰＣクライアント処理部１１がサーバへＲＰＣ要求メッセージを発行する際に、要求先サーバのアドレスに対応する変更通番をグループ管理テーブル１４から取り出し、図１８（ｂ）のように、ＲＰＣ要求メッセージのグループ構成変更通番部１１２に格納する。
【００９９】
図２０は、本実施例によるＲＰＣクライアント処理部の応答受信処理のフローチャートである。ＲＰＣクライアント処理部１１は、サーバからＲＰＣ応答メッセージ１２０を受信すると（Ｓ８０１）、変更フラグ部１２３を調べ、サーバグループに追加があったか否かを判定する（Ｓ８０２）。追加フラグがセット（ＯＮ）されていれば、サーバグループ８０に変更があったと判断し、Ｓ８０３〜Ｓ８０７の処理を行う。ここで、ステップＳ８０３〜Ｓ８０７の処理は、第１の実施例の図１０に示したステップＳ２０５〜Ｓ２０９の処理と同様である。
【０１００】
次に、サーバー側のＲＰＣサーバ処理部が行う処理について説明する。図２１は、本実施例によるＲＰＣサーバ処理部の応答受信処理のフローチャートで、例えば処理装置５のＲＰＣサーバ処理部４２によって実行される。同図で、ステップＳ９０１〜Ｓ９０４は、第１の実施例（図１１）におけるＳ２０１〜Ｓ２０４と同様の処理となる。
【０１０１】
ステップＳ９０２の判定で、要求メッセージがサーバの変更でない場合、まずクライアントから要求されたサーバを実行する（Ｓ９０５）。そのサーバから実行結果を受け取ると、ＲＰＣ要求メッセージ１２０に付加されていた変更通番を取得し（Ｓ９０６）、自処理装置５のグループ管理テーブル４４に管理している変更通番と比較する（Ｓ９０７）。比較の結果、自分の変更通番の方が大きければ、図１９（ｂ）のようにＲＰＣ応答メッセージのサーバ追加フラグをＯＮにし（Ｓ９１０）、ＲＰＣ応答メッセージ１２０に自分の変更通番を付加して（Ｓ９１１）、サーバの実行結果と共にクライアント側の処理装置２へ返送する（Ｓ９１２）。
【０１０２】
一方、取得した変更通番が自分の変更通番以下であれば、ＲＰＣ応答メッセージのサーバ追加フラグをＯＦＦにし（Ｓ９０９）、ＲＰＣ応答メッセージ１２０に自分の変更通番を付加し（Ｓ９１１）、サーバの実行結果と共に要求元の処理装置へ返送する。
【０１０３】
この後、ＲＰＣクライアント処理部１１は、応答メッセージ１２０の追加フラグのＯＮ／ＯＦＦを判定し、ステップＳ８０３〜Ｓ８０７により、グループ管理テーブル１４とアドレス管理テーブル１３を更新する。
【０１０４】
なお、上記ではサーバ追加の例を説明したが、サーバ削除の場合はサーバ削除フラグを用意しそのＯＮ／ＯＦＦを判定する。あるいは、サーバの追加、削除に共用する変更フラグを用意し、ステップＳ９０７における比較の結果、取得したグループ構成変更通番が自分の保持する変更通番と相違する場合に、グループ構成に変更があると判定して、ステップＳ８０３〜Ｓ８０７の処理を行なうようにしてもよい。
【０１０５】
本実施例によれば、サーバグループ構成変更の有無の判定をサーバ側で行っているので、クライアントの処理が軽減できる。特に、不正なサーバの変更要求が連続するような場合に、クライアントのオーバーロードを回避できる。
【０１０６】
〔第３の実施例〕
次に、第３の実施例について説明する。第１、第２の実施例では、クライアントの処理装置がサーバグループのサーバを呼び出す際に、複数のサーバに対して直接ＲＰＣ要求メッセージを送信するマルチキャスト方式を用いていた。これに対し、本実施例では、クライアントの処理装置はサーバグループの任意のサーバに対してＲＰＣ要求メッセージを送信し、このメッセージを受信した処理装置が宛先であるサーバを実行するとともに、グループの残りのすべてのサーバに対してＲＰＣ要求メッセージを転送し、その転送メッセージを受信した各処理装置が自身のサーバを実行する、という間接マルチキャスト方式を用いる。
【０１０７】
図２２は、本実施例によるサーバ追加を説明するためのシステム構成図で、詳細は図１４と同様になる。図２３は、本実施例によるＲＰＣ要求メッセージと応答メッセージのフォーマットを示す。同図（ａ）のＲＰＣ要求メッセージでは、複製の転送による場合を区別するために、図３のＲＰＣ要求メッセージに、転送メッセージフラグ部１１３を追加している。また、同図（ｂ）の応答メッセージでは、変更フラグ部１２３を設け、グループ構成変更通番部１２１は削除している。
【０１０８】
次に、本実施例でのサーバ追加の処理を説明する。この処理の全体的な流れは、サーバグループに対してサーバの追加を通知する処理と、各々のクライアント側処理装置における追加サーバの検知処理に分けることができる。前者の処理は第１の実施例と同様であるので、以下では後者の処理のみを説明する。
【０１０９】
ＲＰＣクライアント処理部１１は、グループ内のマスタサーバとして予め設定されている任意の１つ、ここでは処理装置３のサーバ２５に対してＲＰＣ要求メッセージを送信する。なお、マスターとなる処理装置３のグループ管理テーブル２４には、グループ８０のすべてのサーバを呼び出せるように、そのアドレスと変更通番を管理している。
【０１１０】
クライアントからのＲＰＣ要求メッセージを受け取った処理装置３のＲＰＣサーバ処理部２２は、転送メッセージフラグがＯＦＦとなっていることから、転送メッセージでないと判断すると、グループ内の他のすべてのサーバ宛てに転送ＲＰＣ要求メッセージを送信し、送信された転送ＲＰＣ要求メッセージは、それぞれ処理装置４、５によって受信される。
【０１１１】
ＲＰＣ要求メッセージを受信した処理装置４，５内のＲＰＣサーバ処理部３２，４２は、ＲＰＣ要求に応じてサーバを実行し、サーバの実行結果を取得し、また、グループ管理テーブル２４，３４，４４内の変更通番を取得し、それらを格納したＲＰＣ応答メッセージを、転送ＲＰＣ要求メッセージを送出したＲＰＣサーバ処理部２２へ送信する。
【０１１２】
ＲＰＣサーバ処理部２２は、自分にグループ構成変更通知のあるときはグループ管理テーブル２４を更新する。また、処理装置４，５からのＲＰＣ応答メッセージ内の変更通番とグループ管理テーブル２４内の変更通番を比較し、グループ構成に変更が有るか否かを判定する。変更がある場合には、グループ管理テーブル２４を更新する。
【０１１３】
ＲＰＣサーバ処理部２０は、クライアントに自分のサーバ２５の処理結果と他の転送先サーバ３５，４５からの実行結果を送信する際、先にグループ管理テーブル２４を更新している場合は、変更フラグ部１２３に変更フラグをセット（ＯＮ）する。
【０１１４】
処理装置３からＲＰＣ応答メッセージを受信したＲＰＣクライアント処理部１１は、メッセージの変更フラグがＯＮであればサーバーグループ８０の構成に変更があると判断し、アドレス管理部６０からすべてのサーバのアドレスを取得し、アドレス管理テーブル１３のアドレスと比較する。その結果、差分となるサーバ５５のアドレスを、アドレス管理テーブル１３およびグループ管理テーブル１４に追加する。次に、ＲＰＣクライアント処理部１１は、ＲＰＣ応答メッセージ内の処理装置３，４，５のサーバ実行結果から１つを選択し、クライアント１５に渡す。なお、本実施例では、クライアント側にはグループ管理テーブルが不要となる。
【０１１５】
本実施例によれば、サーバグループにＲＰＣ要求を行なう場合に、グループ内で任意に選択した処理装置との間でのみ送受信が行なわれ、グループ内の他の処理装置の残りのすべてのサーバに対してＲＰＣ要求メッセージを転送して処理する間接マルチキャスト方式を用いるので、クライアントやネットワークの処理付加を低減できる。
【０１１６】
〔第４の実施例〕
次に、第４の実施例について説明する。第１、第２、第３の実施例では、クライアントとサーバとの通信方法としてＲＰＣを用いた。ＲＰＣは複数の情報処理装置がネットワークを介して相互に接続された分散処理システムにおいて、ある処理装置内に存在するクライアントが、自分の処理装置内に存在するプロシジャ呼び出しと同じ手法によって他の処理装置内に存在するサーバ側が提供するプロシジャを呼び出し、その実行結果を受け取る処理手続を行う依頼応答通信方法である。しかしながら、ＲＰＣは内部的には、（１）クライアントからサーバへの依頼メッセージの通信、（２）サーバからクライアントへの応答メッセージの通信を組合せ、その上で、（３）サーバ側の実行可能なプログラムはプロシジャの形で提供され、（４）クライアントが、自分の処理装置内に存在するプロシジャ呼び出しと同じ手法によって他の処理装置内に存在するサーバ側が提供するプロシジャを呼び出すことができるように処理することを特徴とした、依頼応答通信の１つの形態である。
【０１１７】
本発明の主旨は、クライアントとサーバ間の通信方法として、特にＲＰＣに限らなくとも、クライアントとサーバ間の通信方法が、前記リモートプロシジャコール要求／応答の代わりに、それぞれ少なくとも（１）クライアントからサーバへの実行依頼メッセージの通信、（２）サーバからクライアントへの応答メッセージの通信を組み合わせた依頼応答通信であれば適用可能である。
【０１１８】
第１、第２、第３のいずれの実施例においても、リモートプロシジャコール要求の代わりに依頼メッセージ、リモートプロシジャコール応答の代わりに応答メッセージを用いてもよい。この場合、第１、第２、第３の各実施例におけるシステム構成及び処理装置内の構成は、第４の実施例においても同様であり、処理内容についても同様でよい。また、ＲＰＣメッセージのフォーマットについても、ＲＰＣ制御ヘッダ部を依頼応答通信のための制御情報を含む、依頼応答通信制御ヘッダ部に変更するだけでよい。
【０１１９】
以上のように、本発明の主旨は、クライアントとサーバとの通信方法を特にＲＰＣに限らなくとも、クライアントとサーバとの通信方法が依頼応答通信であれば適用可能であり、ＲＰＣの場合と同様の効果を得ることができる。
【０１２０】
【発明の効果】
本発明によれば、クライアント側の計算機は動作中にサーバグループの構成変化を検知することができる。従って、システム管理者はアプリケーションシステムを稼働させながら、サーバグループにサーバを追加し、新たなサービスを追加したり、多重度を増やしたり、サーバのバージョンアップを行ったりすることができ、システムの拡張性、保守性、耐故障性を向上させることができる。また、アプリケーションシステムを稼働させながら、サーバグループからサーバを削除し、不要サーバを切り離すことができ、システムの縮小性、保守性を向上させることができる。
【０１２１】
また、グループの構成変化の検出情報は、ＲＰＣ応答または依頼応答に付加されて送受信されるので、変更に伴うネットワーク上の負荷集中を生じない。さらに、クライアント側計算機がグループ構成の変更の有無を常に監視している必要はなく、自らのＲＰＣ要求または依頼通信時に対する応答内容から変更を検知できるので、クライアント側計算機の変更処理に伴う負荷の増大はない。
【０１２２】
また、本発明によれば、リモートプロシジャ側が多重化サーバを構成している場合、サーバ追加の前後で各サーバにアクセスするクライアント側計算機を同じにすることができ、サーバの内部状態の整合性が保証されるので、多重化サーバの通信方式として有用である。
【図面の簡単な説明】
【図１】本発明のリモートプロシジャコール処理方式を適用するシステム構成の一例を示すブロック図。
【図２】一実施例によるサーバ変更通知ＲＰＣメッセージのフォーマット図。
【図３】一実施例によるＲＰＣ要求メッセージのフォーマット図。
【図４】一実施例によるＲＰＣ応答メッセージのフォーマット図。
【図５】クライアントとサーバを併設する処理装置の構成図。
【図６】アドレス管理テーブルの内容を示すフォーマット図。
【図７】グループ管理テーブルの内容を示すフォーマット図。
【図８】第１の実施例によるＲＰＣクライアント処理部の全体的な処理動作を示すフローチャート。
【図９】テーブル初期化処理の詳細を示すフローチャート。
【図１０】ＲＰＣクライアント処理部の応答受信処理を示すフローチャート。
【図１１】第１の実施例によるＲＰＣサーバ処理部の処理動作を示すフローチャート。
【図１２】アドレス管理部の処理動作を示すフローチャート。
【図１３】グループ構成変更通知部の処理動作を示すフローチャート。
【図１４】サーバ追加処理の流れを説明するシステム構成図。
【図１５】図１４のシステム構成において、各グループ管理テーブルの具体的な管理内容を示す説明図。
【図１６】サーバ側でのサーバ追加処理の流れを説明するフローチャート。
【図１７】クライアント側でのサーバ追加の検知処理を示すフローチャート。
【図１８】第２の実施例におけるＲＰＣ要求メッセージを示すフォーマット図。
【図１９】第２の実施例におけるＲＰＣ応答メッセージを示すフォーマット図。
【図２０】第２の実施例におけるＲＰＣクライアント処理部の応答受信処理の処理動作を示すフローチャート。
【図２１】第２の実施例におけるＲＰＣサーバ処理部の処理動作を示すフローチャート。
【図２２】第３の実施例における間接マルチキャスト方式の処理の流れを説明するシステム構成図。
【図２３】第３の実施例におけるＲＰＣ要求メッセージ及び応答メッセージを示すフォーマット図。
【符号の説明】
１…通信媒体（ネットワーク）、２〜８…処理装置（計算機）、１０，２０，３０，４３，５０…ＲＰＣ処理部、１１…ＲＰＣクライアント処理部、１２，２２，３２，４２，５２…ＲＰＣサーバ処理部、１３…アドレス管理テーブル、１４，２４，３４，４４，５４…グループ管理テーブル、１４３…グループ構成変更通番部、２５，３５，４５，５５，４０１，４０２，４０３，４１１，４１２，４１３，４２１，４２２，４２３，４３１，４３２，４３３…サーバ、６０…アドレス管理部、７０…グループ構成変更通知部、８０…サーバグループ、１００…サーバ変更通知ＲＰＣメッセージ、１０１…ＲＰＣ制御ヘッダ部、１０２…ＲＰＣ要求内容識別子部、１０３…変更サーバ処理識別子部、１１０…ＲＰＣ要求メッセージ、１１１…クライアント要求データ部、１２０…ＲＰＣ応答メッセージ、１２１…グループ構成変更通知部、１２２…サーバ実行結果データ部。
【図１】
0003592016.tif 000002
【図２】
0003592016.tif 000003
【図３】
0003592016.tif 000004
【図４】
0003592016.tif 000005
【図５】
0003592016.tif 000006
【図６】
0003592016.tif 000007
【図７】
0003592016.tif 000008
【図８】
0003592016.tif 000009
【図９】
0003592016.tif 000010
【図１０】
0003592016.tif 000011
【図１１】
0003592016.tif 000012
【図１２】
0003592016.tif 000013
【図１３】
0003592016.tif 000014
【図１４】
0003592016.tif 000015
【図１５】
0003592016.tif 000016
【図１６】
0003592016.tif 000017
【図１７】
0003592016.tif 000018
【図１８】
0003592016.tif 000019
【図１９】
0003592016.tif 000020
【図２０】
0003592016.tif 000021
【図２１】
0003592016.tif 000022
【図２２】
0003592016.tif 000023
【図２３】
0003592016.tif 000024