JPH10275126A - 負荷分散制御を行うクライアントサーバーシステム - Google Patents

Abstract

(57)【要約】 【課題】 同一の情報処理を行う問合せ応答型サーバー
が複数個存在するクライアントサーバーシステムにおい
て、問合せ応答型サーバーの全体の稼働率を上げるよう
にした「負荷分散制御を行うクライアントサーバーシス
テム」を提供する。 【解決手段】 同一の情報処理を行って処理結果を送信
する複数の問合せ応答型サーバーと、問合せリクエスト
を送信する複数のクライアントと、処理可能であって処
理優先順序が最も高い問合せ応答型サーバーに問合せリ
クエストの処理を依頼するコアーノード１と、を有し、
コアーノード１に、クライアントの問合せリクエストの
発生、処理、返信までの処理を管理する問合せリクエス
ト管理部４と、問合せリクエスト送信元のクライアント
を管理するリクエスト元クライアント管理部５と、問合
せリクエスト送信や処理結果送信のイベントを受信しそ
の処理を前記各管理部に振り分ける主制御部２と、を備
えた。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明はクライアントサーバ
ーシステムに係り、特に同一の情報処理を行う問合せ応
答型サーバーが複数個存在するクライアントサーバーシ
ステムにおいて、処理可能な問合せ応答型サーバーのう
ちで優先順序が最も高い問合せ応答型サーバーに問合せ
リクエストの処理をさせることにより、システム全体の
スループットを向上させた「負荷分散制御を行うクライ
アントサーバーシステム」に関する。

【０００２】

【従来の技術】従来のクライアントサーバシステムで
は、クライアントはサーバの所在を意識して直接サーバ
に対して接続をしていた。サーバーは、その処理装置
（プロセッサー）があるクライアントの要求の処理をし
ている間は、その処理装置は他の処理要求を行うことが
できなかった。このため、処理中にそのサーバーに送信
された処理要求は、サーバーが接続不能として処理を拒
否されたり、あるいは処理の待ち行列に入れられたりし
ていた。

【０００３】一方、クライアント側は、サーバーの負荷
の状態を知ることができないので、特定のサーバーに集
中的に処理の要求を送ることがあった。

【０００４】このため、従来のクライアントサーバシス
テムでは、同一処理を行うサーバーが複数個存在してい
ても、特定のサーバーに負荷が集中してしまって全体と
して効率良い情報処理ができないことがあった。

【０００５】なお、本明細書中において、上記所定の処
理要求（以下問合せリクエストという。）に応じて処理
をするサーバーを問合せ応答型サーバーということにす
る。

【０００６】また、従来のクライアントサーバーシステ
ムでは、クライアントが問合せリクエストを送信すると
きは、通信相手のサーバを特定して問合せリクエストを
送信していた。このことは、処理のための作業の煩雑化
と、ネットワーク環境の固定化を招いて不利不便であっ
た。

【０００７】すなわち、上述したように従来のクライア
ントサーバーシステムでは、ある問合せリクエストを送
信するときは、ユーザーは特定の位置にあるサーバーを
指定しなければならなかった。つまり、ユーザーはネッ
トワークがどのように構成されており、どのサーバーが
どのような処理を行うか、などを熟知していなければな
らなかった。また、前記ネットワークの構成等のネット
ワーク環境を熟知していたとしても、リクエスト文ある
いはそれを含むプログラムを作成するための作業が煩雑
であった。

【０００８】このサーバを特定することは、単純なリク
エスト文に限らず、クライアントサーバシステムを構築
するためのネットワークプログラミングにおいても同じ
であった。すなわち、従来は、クライアントサーバシス
テムを作動させるためのネットワークプログラム中でサ
ーバーの指定を行っていたので、ネットワーク環境に強
く依存していた。

【０００９】このため、従来のクライアントサーバシス
テムでは、サーバやアプリケーションソフトウェアの構
成を変えるときは、大幅なプログラムの見直しを強いら
れていた。

【００１０】このことは、サーバやクライアントの配置
を柔軟に変更したり、ソフトウェアのバージョンアップ
等をする必要がある現状では極めて不便であった。

【００１１】上記クライアントサーバシステムのリクエ
スト文の煩雑さを改善するために、最近は「エージェン
ト」という概念（規格、インターフェース）が提案され
ている。

【００１２】このエージェントは、ユーザーの「代理
人」として必要な手続をするもので、処理に必要な知識
を持つことを特徴としている。たとえば、エージェント
を有する切符の予約を行うネットワークでは、ユーザー
は特定のサーバを指定せずに、欲しい切符の条件のみを
入力し、エージェントはその要求に対応するサーバを検
索し、そのサーバにジョブ（切符の予約の処理）を転送
する。

【００１３】つまり、エージェントは、ユーザーの要求
を解釈し、ユーザーに代わって必要な問合せ応答型サー
バーを指定し、その問合せ応答型サーバーに要求を送信
し、処理後は処理結果をユーザーに返信するのである。

【００１４】「エージェント」によれば、ユーザーにと
って問合せ応答型サーバーを指定する繁雑な作業が軽減
される。

【００１５】

【発明が解決しようとする課題】しかしながら、上記
「エージェント」は、未だに実用的なシステムで実現さ
れておらず、単にデータや手続の転送の規格（インター
フェース）の概念として提案されているのみで、システ
ムの具体的手段としては確定的なものは実現されていな
い。

【００１６】また、この「エージェント」は、ユーザー
に代わってジョブ処理の依頼先、処理結果の報告先等の
情報を指定するが、相変わらずネットワーク環境に依存
していた。つまり、エージェントはユーザーに代わって
送信先のサーバーのアドレス等を指定するが、サーバー
がアドレスによって指定される点は変わらず、ネットワ
ークプログラムがアドレス情報等を多く含んでいた。

【００１７】このため、サーバやアプリケーションソフ
トウェアの配置替えを行うときは、エージェントあるい
はクライアントサーバーシステムを作動させるソフトウ
ェアプログラムを見直さなければならなかった。この作
業は時間と手間がかかるため、必然的にネットワーク環
境が固定化され、新規システム（クライアント、サー
バ）の参入や、既存システム（クライアント、サーバ）
の削除等に柔軟に対応することができなかった。

【００１８】そこで、本発明が解決しようとする課題
は、同一の情報処理を行う問合せ応答型サーバーが複数
個存在するクライアントサーバーシステムにおいて、問
合せ応答型サーバーの全体の稼働率を上げることによ
り、システム全体のスループットを向上させるようにし
た「負荷分散制御を行うクライアントサーバーシステ
ム」を提供することにある。

【００１９】また、本発明が解決しようとする他の課題
は、サーバやアプリケーション手段の配置替え等のネッ
トワーク環境の変化を許容する「負荷分散制御を行うク
ライアントサーバーシステム」を提供することにある。

【００２０】

【課題を解決するための手段】本願請求項１に係る負荷
分散制御を行うクライアントサーバーシステムは、問合
せリクエストを受信して同一の情報処理を行って処理結
果を送信する複数の問合せ応答型サーバーと、問合せリ
クエストを送信する複数のクライアントと、問合せリク
エストを受信してその処理を処理可能な問合せ応答型サ
ーバーのうちで処理の優先順序が最も高い問合せ応答型
サーバーに依頼しその処理結果を受信して問合せリクエ
スト送信元のクライアントに送信するコアーノードと、
を有する負荷分散制御を行うクライアントサーバーシス
テムにおいて、前記コアーノードは、前記クライアント
の問合せリクエストの発生、処理、返信までの処理を管
理する問合せリクエスト管理部と、問合せリクエスト送
信元のクライアントを管理するリクエスト元クライアン
ト管理部と、問合せリクエスト送信や処理結果送信のイ
ベントを受信しその処理を前記各管理部に振り分ける主
制御部と、を有していることを特徴とするものである。

【００２１】本願請求項２に係る負荷分散制御を行うク
ライアントサーバーシステムは、一定種類の問合せリク
エストを受信して一定種類の情報処理を行ってその処理
結果を送信する複数個のアプリケーション手段を複数種
類の情報処理について有する問合せ応答型サーバーと、
問合せ応答リクエストを送信する複数のクライアント
と、問合せリクエストを受信してその処理を行うアプリ
ケーション手段を有する問合せ応答型サーバーのうちの
処理の優先順序が最も高い問合せ応答型サーバーに処理
を依頼しその処理結果を受信して問合せリクエスト送信
元のクライアントに送信するコアーノードと、を有する
負荷分散制御を行うクライアントサーバーシステムにお
いて、前記コアーノードは、前記アプリケーション手段
を、情報処理の種類を識別するサービスＩＤと、個別の
アプリケーション手段に関する情報であるアプリケーシ
ョンインフォメーションと、によって管理するアプリケ
ーション手段管理部と、前記クライアントの問合せリク
エストの発生、処理、返信までを、リクエストＩＤによ
って管理する問合せリクエスト管理部と、問合せリクエ
スト送信元のクライアントを、リクエストＩＤごとに管
理するリクエスト元クライアント管理部と、問合せリク
エスト送信や処理結果送信のイベントを受信しその処理
を前記各管理部に振り分ける主制御部と、を有している
ことを特徴とするものである。

【００２２】本願請求項３に係る負荷分散制御を行うク
ライアントサーバーシステムは、前記請求項２のシステ
ムにおいて、前記アプリケーション手段管理部は、所定
の問合せリクエストとその問合せリクエストを処理する
アプリケーション手段間の交信を保持するためのチャネ
ルごとに、チャネル情報およびアプリケーションインフ
ォメーションを管理するアプリケーションインフォメー
ション管理手段と、クライアントサーバーシステム内の
アプリケーション手段を登録したアプリケーションマネ
ージメントテーブルを有し、前記アプリケーションイン
フォメーション管理手段を管理するアプリケーションマ
ネージメントテーブル管理手段と、を有していることを
特徴とするものである。

【００２３】本願請求項４に係る負荷分散制御を行うク
ライアントサーバーシステムは、前記請求項２のシステ
ムにおいて、前記問合せリクエスト管理部は、サービス
ＩＤごとに、情報処理を行う問合せ応答型サーバの情報
を管理し、問合せリクエストの問合せデータを保持する
リクエストキュー管理手段と、サービスＩＤごとに、前
記リクエストキュー管理手段を管理するリクエストキュ
ーマネージャー手段と、サービスＩＤごとに、問合せリ
クエストに対する応答を監視し、応答があった場合の応
答データの送信を管理するリプライウォッチャー手段
と、を有していることを特徴とするものである。

【００２４】本願請求項５に係る負荷分散制御を行うク
ライアントサーバーシステムは、前記請求項１または２
のシステムにおいて、前記コアーノードは、システム起
動時に所定のサーバの内部に、あるいは複数のサーバの
内部にその主制御部と各管理部を分散して生成されるこ
とを特徴とするものである。

【００２５】本願請求項６に係る負荷分散制御を行うク
ライアントサーバーシステムは、前記請求項１または２
のシステムにおいて、前記コアーノードは、外部のネッ
トワークからのリクエストに対して問合せ応答をするこ
とを特徴とするものである。

【００２６】本願請求項７に係る負荷分散制御を行うク
ライアントサーバーシステムは、前記請求項１または２
のシステムにおいて、前記問合せリクエスト管理部は、
リクエスト送信元アプリケーション手段と問合せ応答サ
ービスを行うアプリケーション手段との間のデータ変換
を行うコンバータ手段を有していることを特徴とするも
のである。

【００２７】

【発明の実施の形態】次に、本発明の実施形態について
添付の図面を参照して以下に説明する。最初に、理解容
易のために本発明による「負荷分散制御を行うクライア
ントサーバーシステム」の物理的なシステム構成例を示
して説明する。

【００２８】図１に、本発明によるクライアントサーバ
ーシステムの物理的な構成例を示す。図１に示したクラ
イアントサーバーシステムは、３つのサーバー（ＳＶＲ
１〜ＳＶＲ３）と４つのクライアント（ＣＬ１〜ＣＬ
４）とからなる。なお、一般的な広い意味ではサーバー
とクライアントは要求と応答を行う「ソフトウェア」を
含むが、この明細書ではサーバーとクライアントは要求
と応答を行う「ハードウェア」を指すものとして使用す
る。

【００２９】図１のサーバーとクライアントは、それぞ
れサーバーとクライアントとして作動するためのアプリ
ケーション手段（図中において符号ＡＰを付し、四角枠
で囲って示す）を有しているとする。

【００３０】ここで、アプリケーション手段とは、情報
処理手段であって、特定の目的のために機能を特化させ
たものをいうものとする。アプリケーション手段は、固
定的にその処理をするようにしたハードウェアでもよい
が、好ましくは所定のアプリケーションソフトウェアで
制御され、ある時点で所定の処理をするコンピュータで
ある。

【００３１】ここで、クライアントとサーバーの他に
「アプリケーション手段」という概念を持ち込むのは、
クライアントもサーバーも物理的には類似のコンピュー
タからなるが、それぞれが「アプリケーションソフトウ
ェア」によって制御されて、クライアントとサーバーと
して機能する。これらの制御されてクライアントやサー
バーとして機能する装置が「アプリケーション手段」で
ある。このような「アプリケーション手段」の概念を持
ち込むことにより、同一コンピュータ内に複数の異なる
機能の「アプリケーション手段」が存在することができ
るようになる。

【００３２】また、上記アプリケーション手段はオブジ
ェクト（クラスオブジェクト）からなっていてもよい
が、アプリケーション手段自体は手続型プログラムによ
って制御された手段であって、本発明による負荷分散制
御を行うクライアントサーバーシステムとの間にインタ
ーフェースを有しているものでもよい。

【００３３】ここで、オブジェクトとは、ある属性によ
ってクラス分けし、データと手続とを一体化したもので
ある。オブジェクトは、以下の特徴を有している。 （１）同じ属性を有するオブジェクト（クラスオブジェ
クト）は、基本的に同じメソッド（所定の処理を行う手
段）を有している。 （２）あるクラスオブジェクトの属性やメソッドは、他
のクラスオブジェクトでも継承できる。 （３）他のオブジェクトにそのオブジェクトが有するメ
ソッドによる処理を依頼することができる。

【００３４】本明細書でいう「オブジェクト」は、上記
データと手続を一体化したソフトウェアと、オブジェク
トを実行するためのハードウェアとを含むものとする。

【００３５】本実施形態のシステムを構成する各処理手
段（上記サーバー、クライアントとして作動するアプリ
ケーション手段、あるいは後に詳しく説明するコアーノ
ードとその構成手段）は、「オブジェクト」からなる。
各処理手段を「オブジェクト」とすることにより、本発
明のシステムは、種々の処理に柔軟に対応できるように
なる。しかし、これは本発明をオブジェクト指向の枠組
みに限る意味ではない。つまり、オブジェクトと同一の
機能を通常の手続型プログラムによって制御されたコン
ピュータによって本発明を実現するようにしてもよい。

【００３６】さて、以上の用語の定義を用いて図１のシ
ステムについて説明する。図１の構成例では、サーバー
ＳＶＲ１は異なる２種類の情報処理（サービスＩＤ１０
０，２００）を行う問合せ応答型サーバーとコアノー
ド、サーバーＳＶＲ２は「サービスＩＤ１００」という
種類の情報処理を行う問合せ応答型サーバー、サーバー
ＳＶＲ３は「サービスＩＤ２００」という種類の情報処
理を行う問合せ応答型サーバー、サーバーＳＶＲ４は
「サービスＩＤ２００」という種類の情報処理を行う問
合せ応答型サーバー、をそれぞれ有している。サービス
ＩＤは、問合せ応答サービスを、その処理の内容、デー
タ種類等によって分類して数字等により特定する識別子
である。

【００３７】また、クライアントＣＬ１〜ＣＬ３はクラ
イアントとして作動するアプリケーション手段を有して
いる。クライアントＣＬ４は、外部のネットワークＮＥ
Ｔ１であるが、本システムにアクセスするためのクライ
アントとして作動するアプリケーション手段（図示せ
ず）を有していることは同じである。

【００３８】つまり、のクライアントサーバーシステム
は、「サービスＩＤ１００」という種類の情報処理を行
う２つの問合せ応答型サーバーと、「サービスＩＤ２０
０」という種類の情報処理を行う３つの問合せ応答型サ
ーバーと、１つのコアーノードと、問合せリクエストを
発する４つのクライアントを有しているのである。

【００３９】図１の各オブジェクトは、クライアントサ
ーバーシステム（符号ＩＤＰによって表わす）とのイン
ターフェイスを有している（図１中にＩＤＰ ＡＰＩと
記す）。

【００４０】本実施形態ではコアーノードはシステム起
動時に１個生成される。図１の例では、サーバーＳＶＲ
１に生成されているが、これは固定的なものではなく、
システムにより、起動時に適当なサーバーに生成されて
もよい。また、後述するコアーノードを構成するオブジ
ェクトが複数のサーバーに分散して生成されてもよい。
また、コアーノードが後に説明するサービスＩＤごとに
複数個生成されるようにしてもよい。この場合は、各コ
アーノードがサービスを担当するようにする。

【００４１】コアーノードに対して、各サーバーとクラ
イアントのオブジェクトは「コネクション」を有してい
る。ここで、コネクションとは、オブジェクト間で相手
方のオブジェクトに所定のメッセージを送るための経路
である。このメッセージは、相手方のオブジェクトに所
定のメソッドによる処理を依頼することができる。すな
わち、各オブジェクトは、「コネクション」により、他
のオブジェクトに所定の処理や情報送信を依頼すること
ができるのである。

【００４２】上記構成により、図１のクライアントサー
バーシステムでは、以下のように問合せリクエストと処
理結果が処理される。

【００４３】クライアントが処理を要求する問合せリク
エストを発すると、その問合せリクエストは最初にコア
ーノードに送られる。コアーノードは、要求されている
処理の種類、すなわちサービスＩＤを判別し、そのサー
ビスＩＤの問合せ応答型サーバーを検索し、処理可能な
問合せ応答型サーバーのうちで処理の優先順序が最も高
い問合せ応答型サーバーに処理を依頼する。処理後、問
合せ応答型サーバーは、処理結果をコアーノードに送
る。コアーノードは、その処理結果の問合せリクエスト
送信元のクライアントを検索し、処理結果をそのクライ
アントに送信する。

【００４４】これにより、この実施形態のクライアント
サーバーシステムでは、問合せリクエストは常に処理が
可能で処理の優先順序が高い問合せ応答型サーバーによ
って処理される。これによって特定の問合せ応答型サー
バーへの処理の集中が防止され、問合せ応答型サーバー
全体の稼働率が向上し、システム全体のスループットが
向上する。

【００４５】ここで注目すべきことは、本発明によれ
ば、各サーバは、特定の物理的な装置として認識される
のではなく、サービスＩＤとして認識されることであ
る。

【００４６】すなわち、後に説明するように、本発明で
は、システムに接続される問合せ応答型サーバは、その
提供できる情報や、提供できる情報処理の内容を予めコ
アーノードにサービスＩＤとして登録しておき、これに
対してクライアントはコアーノードに所定のサービスＩ
Ｄを指定して問合せリクエストを発し、コアーノードは
そのサービスＩＤを提供する問合せ応答型サーバを検索
して問合せリクエストを転送するのである。

【００４７】このようにサーバをサービスＩＤとして認
識することにより、物理的なサーバの配置替え等に対し
ては、コアーノードの登録内容を変化させることのみに
より、対応できるようになるのである。

【００４８】次に、本発明の中心部分であるコアーノー
ドの構成について以下に説明する。図２は、コアーノー
ドのクラスオブジェクトの構造を示している。図２にお
いて、各オブジェクトは４角形の線で囲み、上段にオブ
ジェクト名、中段に属性、下段にそのオブジェクトのメ
ソッドを記している。

【００４９】図２に示すように、全体を符号１で示すコ
アーノードは、主制御部２と、アプリケーション手段管
理部３と、問合せリクエスト管理部４と、リクエスト元
クライアント管理部５とを有している。

【００５０】アプリケーション手段管理部３は、アプリ
ケーションインフォメーション管理手段３ａと、アプリ
ケーションマネージメントテーブル管理手段３ｂとから
なる。

【００５１】アプリケーションインフォメーション管理
手段３ａは、所定の問合せリクエストとその問合せリク
エストを処理するアプリケーション手段との交信を維持
するチャネルごとに、そのチャネル情報と、アプリケー
ション手段に関する情報とを管理する手段である。チャ
ネルは、所定の問合せリクエストに対して所定の問合せ
応答型サーバ（アプリケーション手段）が情報の処理を
行うが、その情報の流れの交信口である。アプリケーシ
ョンインフォメーション管理手段３ａは、チャネルごと
にサービスを提供するアプリケーション手段の情報（ア
プリケーション手段の所在等）や、その他のチャネル情
報（たとえば、チャネル識別子等）を管理するのであ
る。

【００５２】アプリケーションマネージメントテーブル
管理手段３ｂは、全システムで１個存在し、アプリケー
ションマネージメントテーブルを有し、前記アプリケー
ションインフォメーション管理手段３ａを管理する。な
おここで、オブジェクト間の「管理」とは、たとえば、
アプリケーションマネージメントテーブル管理手段３ｂ
は、アプリケーションインフォメーション管理手段３ａ
に依頼し、所定のアプリケーション手段の情報を検索さ
せ、回答を得る等の制御を行うことをいう。オブジェク
ト間の「管理」については以下に同じとする。

【００５３】アプリケーションマネージメントテーブル
とは、本発明によるクライアントサーバーシステムに接
続される各アプリケーション手段の情報（アプリケーシ
ョン情報）を登録したテーブルをいう。ここで、アプリ
ケーションマネージメントテーブルに登録するアプリケ
ーション情報は、各アプリケーション手段を特定する情
報、ここでは問合せ応答サービスの内容を特定するサー
ビスＩＤ、アプリケーション手段の所在、ＩＤ等であ
る。

【００５４】問合せリクエスト管理部４は、リプライウ
ォッチャー手段４ａと、リクエストキュー管理手段４ｂ
と、リクエストキューマネージャー手段４ｃとからな
る。なお、コンバータ手段４ｄは、別の実施形態で追加
される。コンバータ手段４ｄを有する実施形態について
は後にさらに説明する。

【００５５】リプライウォッチャー手段４ａは、問合せ
リクエストＩＤごとに存在し、応答待ちのアプリケーシ
ョン手段の情報を登録し、応答を監視し、応答があった
場合にはその応答データを送信する手段である。問合せ
リクエストＩＤは、問合せリクエストを特定するために
リクエストごとに付された識別子である。

【００５６】リクエストキュー管理手段４ｂは、問合せ
応答サービスＩＤごとに存在し、対応する問合せ応答サ
ービスを行う問合せ応答型サーバの情報を管理し、問合
せリクエストの問合せデータを保持する。

【００５７】すなわち、リクエストキュー管理手段４ｂ
は、問合せリクエストがあった場合に、対応するサービ
スＩＤの問合せ応答型サーバをサーチし、問合せデータ
（問合せを行ったアプリケーション手段の情報や、処理
をしてもらう元のデータ）を転送し、応答があるまで前
記問合せリクエストを登録しておくものである。

【００５８】リクエストキューマネージャー手段４ｃ
は、問合せ応答のサービスＩＤごとに存在し、前記リク
エストキュー管理手段４ｂを管理する。

【００５９】リクエスト元クライアント管理部５は、リ
クエストＩＤごとに問合せリクエスト送信元のクライア
ントを管理する。

【００６０】以上が本実施形態の各構成手段の説明であ
ったが、次ぎに問合せ応答サービスにおける各構成手段
の作用について以下に説明する。以下の説明では図２に
示した情報分配応答システムの構成を参照することによ
り、構成手段間の関係がより明らかとなる。

【００６１】最初に、本発明の情報分配応答システムを
構成するには、システムにコンピュータを接続しなけれ
ばならない。本発明の構成に沿ってより正確に言うなら
ば、システムにアプリケーション手段を接続しなければ
ならない。このアプリケーション手段の接続の処理の流
れを図３に示す。なお、図３のフローチャートにおい
て、各処理ステップの処理を行う処理手段を括弧を付し
て示す。

【００６２】図３に示すように、本発明のクライアント
サーバーシステムにアプリケーション手段を接続するに
は、接続を要求するコンピュータがコアーノード１の主
制御部２にアプリケーション手段の接続を要求するイベ
ントを送信する（ステップＳ１００）。

【００６３】この接続要求のイベントを受けた主制御部
２は、アプリケーション手段接続受付用チャネルにアプ
リケーション手段を接続するためのイベントを発生する
（ステップＳ１１０）。このイベントは、次のように処
理される。

【００６４】まず、接続を要求するアプリケーション手
段について、新たなアプリケーションインフォメーショ
ン管理手段３ａが作成され、チャネル情報やそのアプリ
ケーション手段に関する情報等が登録される（ステップ
Ｓ１２０）。

【００６５】次に、この新たなアプリケーション手段
は、アプリケーションマネージメントテーブルに登録さ
れる（ステップＳ１３０）。

【００６６】以上の処理でアプリケーション手段がシス
テムに接続されるが、問合せ応答型サーバーは、サーバ
として宣言し、問合せリクエスト管理部４に検索をして
もらうための登録をしなければならない。サーバ宣言の
処理の流れを図４に示す。なお、図４のフローチャート
において、各処理ステップの処理を行う処理手段を括弧
を付して示す。

【００６７】図４に示すように、サーバー宣言をする問
合せ応答型サーバは、サーバー宣言の要求をコアーノー
ド１の主制御部２に送信する（ステップＳ２００）。

【００６８】主制御部２は上記サーバ宣言のイベントを
受け、アプリケーションマネージメントテーブル管理手
段３ｂにメッセージを送り、アプリケーションマネージ
メントテーブル管理手段３ｂによりその問合せ応答型サ
ーバーについてのアプリケーションインフォメーション
管理手段３ａを作成し、サービスＩＤ、サーバー特定情
報をアプリケーションマネージメントテーブルに登録す
る（ステップＳ２１０）。

【００６９】次に、問合せリクエスト管理部４に問合せ
応答型サーバの登録を行う。まず、アプリケーションイ
ンフォメーション管理手段３ａが、同一の問合せ応答サ
ービスＩＤを有するリクエストキューマネージャー手段
４ｃが存在するか否かを検索する（ステップＳ２２
０）。同一の問合せ応答サービスＩＤのリクエストキュ
ーマネージャー手段４ｃがなければ、新たに作成する。

【００７０】次に、アプリケーションインフォメーショ
ン管理手段３ａは、前記ステップＳ２２０により検索あ
るいは作成されたリクエストキューマネージャー手段４
ｃに、サーバ宣言を行っている問合せ応答型サーバの情
報を登録する（ステップＳ２３０）。

【００７１】最後に、上記リクエストキューマネージャ
ー手段４ｃは、対応するリクエストキュー管理手段４ｂ
を取得し、サーバ宣言をしているサーバを処理可能な問
合せ応答型サーバ（ノード）として登録する（ステップ
Ｓ２４０）。ここで、「取得」とは、所定のオブジェク
トを検索し、コネクションを介して種々のメッセージを
送れる状態にすることをいうものとする。

【００７２】以上がサーバ宣言とその処理についての説
明であったが、このようにアプリケーション手段が接続
され、問合せ応答型サーバとして作動するアプリケーシ
ョン手段が登録されたクライアントサーバーシステム
は、以下に説明するように問合せ応答を行う。以下、こ
の問合せ応答の流れを説明する。

【００７３】問合せ応答には、クライアントから問合せ
応答型サーバへの問合せリクエストの送信と、問合せ応
答型サーバからクライアントへの処理結果の送信とがあ
る。これらの送信は、すべてコアーノード１を介して行
われる。

【００７４】図５に、クライアントから問合せ応答型サ
ーバへの問合せリクエストの送信の流れを示す。なお、
図５のフローチャートにおいて、各処理ステップの処理
を行う処理手段を括弧を付して示す。

【００７５】問合せリクエストは、クライアントから発
せられ、図５の最初に示すように、コアーノード１の主
制御部２に問合せのイベントとして入力される（ステッ
プＳ３００）。

【００７６】上記問合せのイベントを受けた主制御部２
は、チャネルごとにアプリケーションインフォメーショ
ン管理手段３ａを生成する（ステップＳ３１０）。

【００７７】次に、上記ステップＳ３１０によって生成
されたアプリケーションインフォメーション管理手段３
ａは、問合せリクエストに対応する問合せ応答サービス
ＩＤのリクエストキューマネージャー手段４ｃを取得す
る（ステップＳ３２０）。

【００７８】上記ステップＳ３２０によって取得された
リクエストキューマネージャー手段４ｃは、同一問合せ
応答サービスＩＤのリクエストキュー管理手段４ｂを取
得する（ステップＳ３３０）。リクエストキューマネー
ジャー手段５ｃは、取得したリクエストキュー管理手段
４ｂに問合せリクエストに関する情報（問合せデータ、
あるいは問合せ元アプリケーション手段等の情報）を渡
す（ステップＳ３４０）。

【００７９】上記リクエストキュー管理手段４ｂは、上
記問合せリクエストに関する情報をそのリクエストキュ
ー、つまり問合せリクエストの待ち行列に登録する（ス
テップＳ３５０）。

【００８０】次に、リクエストキュー管理手段４ｂはリ
プライウォッチャー手段４ａを取得し、これに問合せリ
クエスト元のクライアントを応答待ちアプリケーション
手段として登録する（ステップＳ３６０）。

【００８１】上記ステップＳ３６０で取得されたリプラ
イウォッチャー手段４ａは、その問合せリクエストに対
して応答待ちタイマを設定し、応答を監視する（ステッ
プＳ３７０）。

【００８２】次に、リクエストキュー管理手段４ｂは、
所定の優先順位に従って問合せ応答サービスを行う問合
せ応答型サーバ（ノード）をサーチし、処理が可能であ
って処理の優先順序が最も高い問合せ応答型サーバのア
プリケーションインフォメーション管理手段３ａを取得
する（ステップＳ３８０）。

【００８３】次に、上記アプリケーションインフォメー
ション管理手段３ａが、上記処理可能であって処理の優
先順序が最も高い問合せ応答型サーバに対し、問合せデ
ータを送信する（ステップＳ３９０）。これにより、問
合せリクエストと問合せデータが所定の問合せ応答型サ
ーバで処理されることになる。

【００８４】以上がクライアントから問合せ応答型サー
バへの問合せリクエストの送信であるが、ステップＳ３
８０，Ｓ３９０においてリクエストキュー管理手段４ｂ
が処理可能であって処理の優先順序が最も高い問合せ応
答型サーバを検索して、それに問合せデータを送信する
処理により、本発明のクライアントサーバーシステムは
負荷分散を行うことができる。

【００８５】次に、問合せ応答処理後の問合せ応答型サ
ーバからクライアントへの処理結果の送信について説明
する。

【００８６】図６に問合せ応答型サーバからクライアン
トへの応答の送信の流れを示す。図６のフローチャート
において、図５と同様に各処理ステップの処理を行う処
理手段を括弧を付して示す。

【００８７】処理結果の送信のイベントは、処理を行っ
た問合せ応答型サーバから送信され、図６の最初に示す
ように、コアーノード１の主制御部２に入力される（ス
テップＳ４００）。

【００８８】上記応答送信のイベントを受けた主制御部
２は、応答をする問合せ応答型サーバに対応するアプリ
ケーションインフォメーション管理手段３ａを取得する
（ステップＳ４１０）。

【００８９】次に、上記ステップＳ４１０によって取得
されたアプリケーションインフォメーション管理手段３
ａは、対応する問合せ応答サービスＩＤのリクエストキ
ューマネージャー手段４ｃを取得する（ステップＳ４２
０）。

【００９０】上記ステップＳ４２０によって取得された
リクエストキューマネージャー手段４ｃは、同一問合せ
応答サービスＩＤのリクエストキュー管理手段４ｂを取
得する（ステップＳ４３０）。

【００９１】上記ステップＳ４３０によって取得された
リクエストキュー管理手段４ｂは、問合せを行った問合
せリクエストをそのリクエストキューから削除する（ス
テップＳ４４０）。

【００９２】次に、リプライウォッチャー手段４ａは、
問合せリクエスト元のアプリケーション手段（クライア
ント）に関するデータを応答待ちアプリケーション手段
のデータから削除する（ステップＳ４５０）。

【００９３】以上のステップＳ４２０〜Ｓ４５０の処理
により、問合せリクエスト管理部５から問合せリクエス
トが削除される。

【００９４】次に、リプライウォッチャー手段４ａは、
アプリケーションマネージメントテーブル管理手段３ｂ
にアクセスし、アプリケーションマネージメントテーブ
ル管理手段３ｂを取得する（ステップＳ４６０）。

【００９５】アプリケーションマネージメントテーブル
管理手段３ｂは、問合せ応答型サーバの情報から、対応
するアプリケーションインフォメーション管理手段３ａ
を取得し、このアプリケーションインフォメーション管
理手段３ａとリクエスト元クライアント管理部５によ
り、リプライウォッチャー手段４ａはリクエスト元のク
ライアントの情報を得ることができる（ステップＳ４７
０）。

【００９６】最後に、リプライウォッチャー手段４ａ
は、上記のように得られたリクエスト元クライアントに
処理結果を送信する（ステップＳ４８０）。

【００９７】以上が、問合せ応答サービスにおける問合
せリクエストの送信と処理結果の返信に関するコアーノ
ード１の処理の流れである。

【００９８】以上の説明から明らかなように、本発明に
よるクライアントサーバーシステムは、コアーノード１
がクライアントとサーバーの交信を仲介し、クライアン
トから処理要求を受け取ると、その処理を行うことがで
きる問合せ応答型サーバーをサーチし、その時点で処理
が可能であって処理優先順序が最も高い問合せ応答型サ
ーバーに処理を依頼する。これにより、同一処理を行う
複数の問合せ応答型サーバーを有するクライアントサー
バーシステムにおいて、特定の問合せ応答型サーバーに
処理が集中するのが防止され、各問合せ応答型サーバー
が平均的に処理を行うことにより、全体として効率よい
処理を行うクライアントサーバーシステムを得ることが
できる。

【００９９】また、本発明のクライアントサーバーシス
テムによれば、ユーザーがある問合せリクエストを発す
るときは、自分の欲しいサービスを指定するだけで、コ
アーノード１がそのリクエストを処理可能なサーバーを
サーチし、処理を依頼しかつ処理結果を返送してくれ
る。これにより、ネットワーク環境についての知識がな
いユーザーでも簡単に問合せ応答サービスを受けること
ができる。また、サーバーのアドレスを指定する煩雑さ
や、アドレスの指定の誤りによるトラブル等を避けるこ
とができる。

【０１００】さらに、本発明によれば、システムに接続
されているアプリケーション手段は、主にアプリケーシ
ョン手段管理部３によって集中的に管理されている。こ
のアプリケーション手段管理部３に管理されている情報
は、問合せ応答サービスのための処理手段とは独立して
おり、また、変更も簡単である。このため、新たな問合
せ応答型サーバーを接続するときや、既に接続している
問合せ応答型サーバーを変更するときは、アプリケーシ
ョン手段管理部３と問合せリクエスト管理部４の一部の
変更を行うのみで対応することができる。これは、ネッ
トワーク環境を変更する際にシステム内の多数のアプリ
ケーション手段のプログラムを見直さざるをえない負担
に比べ、ネットワーク環境の変更の負担を大幅に軽減で
き、ネットワーク環境の変更に柔軟に対応可能なクライ
アントサーバーシステムを得ることができる。

【０１０１】次に、上記実施形態の変形例（他の実施形
態）について以下に説明する。

【０１０２】上記実施形態では、複数の問合せ応答サー
ビス（図１のサービスＩＤ１００，２００参照）を有す
るクライアントサーバーシステムについて説明した。し
かし、もっと単純に１種類の問合せ応答サービスを行う
複数のサーバーを有するシステムに本発明を適用可能で
あることは説明するまでもない。特に、１種類の問合せ
応答サービスに機能を限定する場合は、コアーノードに
処理可能な問合せ応答型サーバーの情報を持たせ、問合
せリクエストに対して処理可能であって処理優先順序が
最も高い問合せ応答型サーバーを検索して処理依頼する
ようにしてよい。この場合は、アプリケーション手段管
理部、問合せリクエスト管理部の構成を統合して単純化
することができる。本願請求項１に記載した「負荷分散
制御を行うクライアントサーバーシステム」は、上記１
種類の問合せ応答サービスに機能を限定したクライアン
トサーバーシステムに対応する。

【０１０３】また、上記実施形態では、サービスＩＤは
提供するサービスの内容とデータの種類とによって分類
したものを前提に説明した。すなわち、問合せリクエス
トは、データの種類、たとえばテキストデータとか、特
定のアプリケーションソフトウェア（ＯＳ、ワードプロ
セッサ、表計算、データベース等）による特定種類のデ
ータ等までを特定したサービスＩＤを指定していた。

【０１０４】この場合、問合せ応答サービスを行うサー
バーは、クライアントが要求するデータ種類を出力可能
なサーバーに限定される。

【０１０５】しかし、本発明によれば、図２に示すコン
バータ手段４ｄを設けることにより、上記アプリケーシ
ョンソフトウェア間の相違を吸収することもできる。

【０１０６】この場合、サービスＩＤは単にサービス内
容によって分類されたものからなり、クライアントは、
取得したい情報の内容とデータ種類をサービスＩＤによ
って指定してリクエストを発する。コンバータ手段４ｄ
は、サーバが提供するデータをクライアントが欲するデ
ータ形式に変換し、リプライウォッチャー手段４ａによ
って変換後のデータをクライアントに返送する。

【０１０７】このようにすることにより、他のアプリケ
ーションソフトウェアで処理したデータをも利用でき、
ＯＳに対して依存度が低く、かつ、効率が高いクライア
ントサーバーシステムを得ることができる。

【０１０８】なお、上記実施形態の説明では、コアーノ
ードの主制御部に送られるイベントは、いずれもクライ
アントから送られたものであった。しかし、図１に示し
たように、本発明のクライアントサーバーシステムは、
他のネットワークからのイベントも処理することができ
る。

【０１０９】これにより、本発明のクライアントサーバ
ーシステムは、単一のネットワークのみによって構成さ
れるものではなく、ネットワークとネットワークが複合
的にクライアントサーバーシステムを構成し、一つのネ
ットワークのノードから他のネットワークの情報を取得
することができるようになる。

【０１１０】すなわち、本発明のクライアントサーバー
システムは、上記複数のネットワークを取り込んだ複合
的なクライアントサーバーシステムである場合をも含む
ものである。

【０１１１】

【発明の効果】以上の説明から明らかなように、本発明
のクライアントサーバーシステムによれば、コアーノー
ドがクライアントとサーバーの交信を仲介し、問合せリ
クエストに対してそれを処理可能な問合せ応答型サーバ
ーをサーチし、処理可能であって処理の優先順序が最も
高い問合せ応答型サーバーに処理を依頼する。これによ
り、同一処理を行う問合せ応答型サーバーが複数個存在
するクライアントサーバーシステムにおいて、問合せ応
答型サーバーの負荷が平均的に分散され、特定のサーバ
ーに処理が集中することが防止され、全体として効率の
よい処理を行うクライアントサーバーシステムを得るこ
とができる。

【０１１２】また、本発明によるクライアントサーバー
システムによれば、コアーノードによって問合せ応答型
サーバをサービスＩＤによって把握し、各クライアント
やサーバーのネットワークプログラムをネットワーク環
境から独立させている。このため、サーバの配置替えや
拡張等のネットワーク環境の変化に対してはコアーノー
ドのプログラムの見直しのみによって対応することがで
きる。これにより、本発明によれば、従来のネットワー
ク環境の変化に対応するためのプログラム見直し作業を
大幅に軽減することができる。

【０１１３】また、ユーザがデータを取得する際にも、
自分の欲しいデータやサービスを指定するだけで、クラ
イアントサーバーシステムから欲する情報を得られる。
これにより、ネットワーク環境についての深い知識を有
しないユーザーでも簡単に使用することができるクライ
アントサーバーシステムを得ることができる。

【図面の簡単な説明】

【図１】本発明による「負荷分散制御を行うクライアン
トサーバーシステム」の物理的な構成例を示したブロッ
ク図。

【図２】本発明のクライアントサーバーシステムのコア
ーノードの構成を示したブロック図。

【図３】本発明のクライアントサーバーシステムへのア
プリケーション手段の接続の処理を示したフローチャー
ト。

【図４】本発明のクライアントサーバーシステムにおけ
るサーバ宣言の処理を示したフローチャート。

【図５】本発明のクライアントサーバーシステムにおけ
るクライアントから問合せ応答型サーバへの問合せリク
エストの送信の流れを示したフローチャート。

【図６】本発明のクライアントサーバーシステムにおけ
る問合せ応答型サーバからクライアントへの処理結果の
送信の流れを示したフローチャート。

【符号の説明】

１ コアーノード ２ 主制御部 ３ アプリケーション手段管理部 ３ａ アプリケーションインフォメーション管理手段 ３ｂ アプリケーションマネージメントテーブル管理手
段 ４ 問合せリクエスト管理部 ４ａ リプライウォッチャー手段 ４ｂ リクエストキュー管理手段 ４ｃ リクエストキューマネージャー手段 ５ リクエスト元クライアント管理部

Claims (7)

【特許請求の範囲】
1. 【請求項１】問合せリクエストを受信して同一の情報処
   理を行って処理結果を送信する複数の問合せ応答型サー
   バーと、問合せリクエストを送信する複数のクライアン
   トと、問合せリクエストを受信してその処理を処理可能
   な問合せ応答型サーバーのうちで処理の優先順序が最も
   高い問合せ応答型サーバーに依頼しその処理結果を受信
   して問合せリクエスト送信元のクライアントに送信する
   コアーノードと、を有する負荷分散制御を行うクライア
   ントサーバーシステムにおいて、 前記コアーノードは、 前記クライアントの問合せリクエストの発生、処理、返
   信までの処理を管理する問合せリクエスト管理部と、 問合せリクエスト送信元のクライアントを管理するリク
   エスト元クライアント管理部と、 問合せリクエスト送信や処理結果送信のイベントを受信
   しその処理を前記各管理部に振り分ける主制御部と、を
   有していることを特徴とする負荷分散制御を行うクライ
   アントサーバーシステム。
2. 【請求項２】一定種類の問合せリクエストを受信して一
   定種類の情報処理を行ってその処理結果を送信する複数
   個のアプリケーション手段を複数種類の情報処理につい
   て有する問合せ応答型サーバーと、問合せ応答リクエス
   トを送信する複数のクライアントと、問合せリクエスト
   を受信してその処理を行うアプリケーション手段を有す
   る問合せ応答型サーバーのうちの処理の優先順序が最も
   高い問合せ応答型サーバーに処理を依頼しその処理結果
   を受信して問合せリクエスト送信元のクライアントに送
   信するコアーノードと、を有する負荷分散制御を行うク
   ライアントサーバーシステムにおいて、 前記コアーノードは、 前記アプリケーション手段を、情報処理の種類を識別す
   るサービスＩＤと、個別のアプリケーション手段に関す
   る情報であるアプリケーションインフォメーションと、
   によって管理するアプリケーション手段管理部と、 前記クライアントの問合せリクエストの発生、処理、返
   信までを、リクエストＩＤによって管理する問合せリク
   エスト管理部と、 問合せリクエスト送信元のクライアントを、リクエスト
   ＩＤごとに管理するリクエスト元クライアント管理部
   と、 問合せリクエスト送信や処理結果送信のイベントを受信
   しその処理を前記各管理部に振り分ける主制御部と、を
   有していることを特徴とする負荷分散制御を行うクライ
   アントサーバーシステム。
3. 【請求項３】前記アプリケーション手段管理部は、 所定の問合せリクエストとその問合せリクエストを処理
   するアプリケーション手段間の交信を保持するためのチ
   ャネルごとに、チャネル情報およびアプリケーションイ
   ンフォメーションを管理するアプリケーションインフォ
   メーション管理手段と、 クライアントサーバーシステム内のアプリケーション手
   段を登録したアプリケーションマネージメントテーブル
   を有し、前記アプリケーションインフォメーション管理
   手段を管理するアプリケーションマネージメントテーブ
   ル管理手段と、を有していることを特徴とする請求項２
   記載の負荷分散制御を行うクライアントサーバーシステ
   ム。
4. 【請求項４】前記問合せリクエスト管理部は、 サービスＩＤごとに、情報処理を行う問合せ応答型サー
   バの情報を管理し、問合せリクエストの問合せデータを
   保持するリクエストキュー管理手段と、 サービスＩＤごとに、前記リクエストキュー管理手段を
   管理するリクエストキューマネージャー手段と、 サービスＩＤごとに、問合せリクエストに対する応答を
   監視し、応答があった場合の応答データの送信を管理す
   るリプライウォッチャー手段と、を有していることを特
   徴とする請求項２記載の負荷分散制御を行うクライアン
   トサーバーシステム。
5. 【請求項５】前記コアーノードは、システム起動時に所
   定のサーバの内部に、あるいは複数のサーバの内部にそ
   の主制御部と各管理部を分散して生成されることを特徴
   とする請求項１または２に記載の負荷分散制御を行うク
   ライアントサーバーシステム。
6. 【請求項６】前記コアーノードは、外部のネットワーク
   からのリクエストに対して問合せ応答をすることを特徴
   とする請求項１または２に記載の負荷分散制御を行うク
   ライアントサーバーシステム。
7. 【請求項７】前記問合せリクエスト管理部は、 リクエスト送信元アプリケーション手段と問合せ応答サ
   ービスを行うアプリケーション手段との間のデータ変換
   を行うコンバータ手段を有していることを特徴とする請
   求項１または２に記載の負荷分散制御を行うクライアン
   トサーバーシステム。