(57)【特許請求の範囲】
【請求項１】
同一のセグメントに接続され処理を行う複数のサーバ、前記セグメントに接続され該サーバへの処理要求を中継する複数の代理サーバ、サーバ状態通知手段を有するサーバと通信可能な状態管理用サーバ、および該代理サーバと該状態管理用サーバとのそれぞれと通信可能なクライアント装置を有し、該クライアント装置が閲覧手段より送られてくる代表アドレスに基づき各サーバの負荷状況に応じて処理要求の相手となるサーバおよび処理要求を中継する代理サーバを選択するサーバ選択システムであって、
少なくとも１つの前記サーバが、前記セグメント上に出力された全てのパケットのうち前記サーバまたは前記代理サーバを宛先としたパケットを収集し、該サーバおよび該代理サーバ宛ての単位時間当たりのパケット数を示す負荷情報をサーバ状態管理手段に通知する前記サーバ状態通知手段を有し、
前記状態管理用サーバが、前記サーバ状態通知手段が通知した各サーバおよび該代理サーバの負荷情報を取得し、同じ機能を提供するサーバ群を統合した代表名に対応付けられた複数の前記サーバそれぞれと複数の前記代理サーバそれぞれとの負荷情報を前記クライアント装置に送信する前記サーバ状態管理手段を有し、
前記クライアント装置は、
前記サーバ状態管理手段から代表名に対応付けられた複数の前記サーバそれぞれと複数の前記代理サーバそれぞれとの負荷情報を取得し、代表名に対応付けられた該サーバそれぞれと該代理サーバそれぞれとに対応付けて、取得した負荷情報をサーバ状態管理テーブルに登録するサーバ状態受信手段と、
代表名を指定したサーバ選択要求を受け取ると、前記サーバ状態管理テーブルを参照し、該サーバ選択要求で指定された代表名に対応付けられたサーバに設定された負荷情報に基づいて該サーバの負荷を判断し、負荷の少ないサーバを出力先サーバとして選択し、該出力先サーバを指定した代理サーバ選択要求を受け取ると、前記サーバと該サーバへの処理要求を中継する１つ以上の代理サーバとの対応関係が予め登録された代理サーバ管理データベースを参照し、該代理サーバ選択要求で指定された出力先サーバに対応する代理サーバを取得し、前記サーバ状態管理テーブルを参照し、取得した代理サーバのうち負荷の少ない代理サーバを中継先代理サーバとして選択する要求分散処理手段と、
前記閲覧手段から代表名を指定した処理要求を受け取ると、該閲覧手段との間でコネクションを確立して該閲覧手段のローカルの代理サーバとして機能し、前記要求分散処理手段に対して代表名を指定したサーバ選択要求を出力し、前記要求分散処理手段から選択された前記出力先サーバを受け取ると、前記要求分散処理手段が選択した前記出力先サーバを指定した代理サーバ選択要求を前記要求分散処理手段に対して出力し、前記要求分散処理手段から選択された前記中継先代理サーバを受け取ると、前記閲覧手段から出された前記処理要求を、前記要求分散処理手段が選択した該中継先代理サーバ経由で前記要求分散処理手段が選択した該出力先サーバに対して出力する要求中継手段とを有する、
ことを特徴とするサーバ選択システム。
【請求項２】
前記サーバ状態管理手段は、複数の前記サーバそれぞれの処理速度を示す数値を、前記クライアント装置に送信し、
前記クライアント装置の前記サーバ状態受信手段は、複数の前記サーバそれぞれに対応付けて処理速度を示す数値を前記サーバ状態管理テーブルに登録し、
前記要求分散処理手段は、前記サーバの負荷情報で示される単位時間当たりのパケット数を、処理速度を示す数値で除算した値が最も小さくなるサーバを、負荷の少ないサーバと判断することを特徴とする請求項１記載のサーバ選択システム。
【請求項３】
前記サーバ状態管理手段は、負荷情報配信要求を受け取った際に、前記負荷情報配信要求を出力した前記クライアント装置に対して負荷情報を配布し、
前記サーバ状態受信手段は、前記サーバ選択要求を受け取った際に前記サーバ状態管理手段に前記負荷情報配信要求を出力することで、前記サーバ状態管理手段から複数の前記サーバおよび複数の前記代理サーバそれぞれの負荷情報を取得することを特徴とする請求項１記載のサーバ選択システム。
【請求項４】
前記サーバ状態管理手段は、前記クライアント装置に対して一定時間毎に負荷情報を配信することを特徴とする請求項１記載のサーバ選択システム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明はサーバ選択システムに関し、特にＷＷＷシステムをクライアント−サーバシステムと同様に使用するためのサーバ選択システムに関する。
【０００２】
【従来の技術】
インターネットの発達に伴い、ほとんどのコンピュータにＷＷＷ(World Wide Web)ブラウザと呼ばれる閲覧ソフトが導入されつつある。しかも、現在のＷＷＷシステムは、その主目的であるＨＴＭＬ(Hyper Text Markup language)文書の取り出しとその内容の表示機能が特に充実している。そこで、イントラネットのように、インターネットの技術を企業内の情報システムに取り入れ、情報の共有や業務支援に活用することが行われてきている。また、従来のクライアント−サーバシステムと同等の機能を、ＷＷＷシステムの技術で構築することも試みられている。ところが、ＷＷＷシステムは、従来のクライアント−サーバシステムに比べ、機能不足な点が多い。そのため、個々の目的に応じて、以下のような対応が行われている。
【０００３】
第１に情報の集中に関する問題がある。インターネットでは、ＨＴＴＰ(Hyper Text Transfer Protocol)の下位プロトコルとしてＴＣＰ(Transmission Control Protocol) ／ＩＰ(Internet Protocol) を使用している。このプロトコルでは、通信相手の宛先情報としてのＩＰアドレスを使用する。この環境で通信量が集中するＷＷＷサーバの負荷分散を行う装置として、１つのＩＰアドレスをもつＴＣＰ／ＩＰプロトコルのパケットを複数のＷＷＷサーバの計算機に分散させる装置（負荷分散装置）がある。例えば、ルータやスイッチング装置などである。
【０００４】
また、インターネットで一般的に使用されている相手システムを特定する名前［ＤＮＳ(Domain Name System)名］とＩＰアドレスのマッピング機構の機能を応用することもできる。例えば、１つのＤＮＳ名に複数のＩＰアドレスを割り付け、ＤＮＳへのＤＮＳ名からＩＰアドレスのマッピング要求がある毎にラウンドロビン方式で、マッピングするＩＰアドレスを分散使用する方法（以下、「ＤＮＳ負荷分散」という）がある。
【０００５】
第２に、通信の継続性に関する問題がある。現状のＷＷＷシステムの通信は、ＨＴＴＰというプロトコルで実現されている。このプロトコルでは、ＷＷＷブラウザとＷＷＷサーバとの間は、ＷＷＷブラウザからの１回の要求に対するＷＷＷサーバからの１回の応答で１つの通信が完結する。すなわち、通信間の継続性がない。よって、ＷＷＷブラウザとＷＷＷサーバの間でのセション管理型の通信機能は、一般的なＷＷＷブラウザとＷＷＷサーバとでは提供されない。このため、ＷＷＷサーバまたはＷＷＷサーバ上のサービス提供プログラムでセション管理機能を独自に提供するものがある。これらは、ＷＷＷサーバまたはミドルウェアとして提供される製品であり、その製品固有の機能としてセション管理機能を提供している。これらの機能は、何らかの方法により、サーバ側で決定したセション情報をＷＷＷブラウザとの間で受け渡すことで実現されている。セション情報の受け渡し方法としては、Cookieを使用するもの、ＷＷＷブラウザ画像上には表示されないデータとして応答のＨＴＭＬ文書内に埋め込むもの、次回要求のアドレス情報に付加するものなどがある。なお、「Cookie」とは、インターネット上のＷＷＷサーバからクライアント側に情報ファイルを送り、保存しておくための機能である。
【０００６】
このように、個々に発生した問題に応じて、それを補う新たな技術が投入されている。
【０００７】
【発明が解決しようとする課題】
しかし、従来のＷＷＷシステムでは、抜本的な機能改善は行われていなかった。そのため、以下のような問題がある。
【０００８】
まず、従来技術で説明した第１の問題に関する従来の対処方法では、負荷分散装置自体に負荷が集中するという問題に関しては解決されていない。しかも、負荷分散装置の故障に対する防御が弱い等の問題もある。また、負荷分散装置を用いた方式では、ＴＣＰ／ＩＰの各通信毎に実際にどのＷＷＷサーバと通信されるかが不確定である（各通信毎に因果関係がない）ため、ＴＣＰ／ＩＰを下位プロトコルとして使用するＨＴＴＰ上のユーザデータを使用したセション管理のように、一定の範囲の通信を同一ＷＷＷサーバとの間で行うのが困難である点に問題がある。
【０００９】
また、ＤＮＳ負荷分散は、一般的に、ＩＰアドレスの使用者側（例えば、ＷＷＷブラウザが動作している計算機）が一回、ＤＮＳ名をＩＰアドレスにマッピングした後は、そのマッピング結果を使用者側に保持して長期間使用するため、タイムリな負荷分散にならないという問題点がある。
【００１０】
従来技術で説明した第２の問題に関する従来の対処方法では、セキュリティ上の問題（Ｃｏｏｋｉｅ方式）、ＨＴＭＬ文書の作成規則が制約される問題（ＨＴＭＬ文書埋め込み方式）がある。さらに、いずれの方式においても、ＷＷＷサーバまたはＷＷＷブラウザの機能の拡張が必要である。ところが、ＷＷＷサーバやＷＷＷブラウザの機能を拡張するには、それぞれの製品毎に対応しなければならず、煩雑な作業が必要である。
【００１１】
このように、ＷＷＷシステムを用いて、既存のクライアント−サーバシステムと同様の処理を行うには不足した機能が多数あり、それらの対処が不十分だった。本発明はこのような点に鑑みてなされたものであり、ＷＷＷシステム上で、適切な負荷分散を行うことができるサーバ選択システムを提供することを目的とする。
【００１７】
【課題を解決するための手段】
上記課題を解決するために、処理を行う複数のサーバと、処理要求を行うクライアント装置とを有し、該クライアント装置が各サーバの負荷状況に応じて処理要求の相手となるサーバを選択するサーバ選択システムであって、少なくとも１つの前記サーバが、管理対象のサーバに対して出された処理要求を収集し、該管理対象のサーバの負荷情報をサーバ状態管理手段に通知するサーバ状態通知手段を有し、少なくとも１つの前記サーバが、前記サーバ状態通知手段が通知した各サーバの処理情報を取得し、複数のサーバの負荷状態を記憶する前記サーバ状態管理手段を有し、前記クライアント装置は、前記サーバ状態管理手段から各サーバの負荷情報を取得すると共にサーバ選択要求を受け取った際、取得した負荷情報に基づいて要求の出力先サーバを選択する要求分散処理手段、及び閲覧手段から処理要求を受け取ると、該閲覧手段との間でコネクションを確立して該閲覧手段のローカルの代理サーバとして機能し、前記要求分散処理手段に対してサーバ選択要求を出力し、前記要求分散処理手段が選択した前記出力先サーバに対して、前記処理要求を出力する要求中継手段を有することを特徴とするサーバ選択システムが提供される。
【００１８】
このようなサーバ選択システムによれば、要求分散処理手段がサーバ状態管理手段からサーバの負荷情報を取得し、処理要求が出力された際には、クライアント装置内の要求分散処理手段によって負荷の少ないサーバが特定されるため、ネットワーク上のどこにも処理を集中させることなく適切な負荷分散を行うことができる。
【００２９】
【発明の実施の形態】
以下、本発明の実施の形態を図面を参照して説明する。
図１は、本発明の負荷分散システムの原理構成図である。処理機能を提供するサーバ（機能提供用のプログラムを実行することにより実現される処理機能）１ａ，２ａがサーバ装置（処理機能の提供を行う計算機）１，２内に導入されている。各サーバ１ａ，２ａは、同様の機能を提供している。サーバ装置１，２は、個別のＬＡＮ(Local Area Network)１０，２０に接続されている。各ＬＡＮ１０，２０には、サーバ状態通知手段３ａ，４ａを有するサーバ装置３，４が設けられている。サーバ状態通知手段３ａ，４ａは、管理対象として特定されたサーバ１ａ，２ａに対して出された処理要求を収集する。
【００３０】
サーバ状態管理手段５ａを有するサーバ装置５は、広域ネットワーク３０を介してＬＡＮ１０，２０に接続されている。サーバ状態管理手段５ａは、サーバ状態通知手段３ａ，４ａが収集したサーバ１ａ，２ａの処理量を取得し、複数のサーバ１ａ，２ａの負荷状態を管理する。
【００３１】
クライアント装置６は、広域ネットワーク３０を介してサーバ装置５に接続されている。クライアント装置６は、要求分散処理手段６ａ、及び要求中継手段６ｂを有している。要求分散処理手段６ａは、サーバ状態管理手段５ａから複数のサーバ１ａ，２ａの負荷情報を取得し、サーバ選択要求を受け取ると、負荷情報に基づいて要求の出力先を決定する。要求中継手段６ｂは、処理要求を受け取ると、要求分散処理手段６ａに対してサーバ選択要求を出力し、要求分散処理手段６ａが決定したサーバに対して、処理要求を出力する。
【００３２】
このような負荷分散システムによれば、サーバ１ａ，２ａに対して出された処理要求をサーバ状態通知手段３ａ、４ａが収集する。収集された処理要求は、サーバ状態管理手段５ａが取得し、クライアント装置の要求分散処理手段６ａに提供する。
【００３３】
そして、クライアント装置６より処理要求が出力されると、その処理要求は要求中継手段６ｂで中継される。要求中継手段６ｂは、要求分散処理手段６ａに対してサーバ選択要求を出す。要求分散処理手段６ａは、サーバ状態管理手段５ａから取得したサーバ１ａ，２ａの負荷情報を元に、負荷の少ないサーバを決定し、要求中継手段６ｂへ返す。要求中継手段６ｂは、要求分散処理手段６ａが決定したサーバに対して処理要求を出力する。
【００３４】
このようにしてクライアント装置６より出された処理要求を、複数のサーバ１ａ，２ａの中の負荷の少ない方へ割り振ることができる。このとき、負荷分散処理を各クライアント装置６内で行うため、何らかの処理（例えば、負荷分散処理等）がネットワーク上のどこかに集中するようなことがない。
【００３５】
上記本発明は、ＷＷＷシステムに容易に適用することができる。すなわち、処理要求を出力するＷＷＷブラウザと処理を提供するＷＷＷサーバとの機能を変更せずに、有効な負荷分散が可能である。その場合、要求分散処理手段６ａと要求中継手段６ｂとの機能は、ＬＡＮ環境運用時のＨＴＴＰでの代理サーバの技術を使用して実現する。
【００３６】
本来代理サーバは、インターネット上の１つの独立した計算機上で動作し、複数のＷＷＷブラウザからの要求を、複数のＷＷＷサーバに中継する機能を有している。また、一度中継したＷＷＷサーバからの静的なファイル（ＨＴＭＬなど）をキャッシュしておき、同一資源への要求はキャッシュした資源を返信する機能を有する。さらに、代理サーバの一部には、セキュリティ機能を有するものもある。
【００３７】
一方、ＷＷＷブラウザには、一般的に代理サーバの使用の有無の指定と、使用する場合の代理サーバのＤＮＳ名（またはＩＰアドレス）が指定できる。ＷＷＷブラウザは、ＷＷＷサーバへの要求時、代理サーバ経由が指定されている場合、その代理サーバとの間でＴＣＰ／ＩＰのコネクションを確立して要求を送信する。この要求のＨＴＴＰプロトコル情報としてＷＷＷサーバのアドレス情報を付加する。このとき、ＷＷＷサーバへ直接コネクションを接続することはない。また、ＴＣＰ／ＩＰプロトコルには、同一マシン上の通信相手プログラムと他のマシン上の通信相手プログラムを区別しないという特性がある。
【００３８】
そこで、一般的な機能を有するＷＷＷブラウザと同一のマシン上に、代理サーバ（以下、「ローカル代理サーバ」という）を動作させることで、本発明の負荷分散システムをＷＷＷシステムに適用する。また、ローカル代理サーバを用いれば、ＷＷＷブラウザとＷＷＷサーバとの間で、継続したセション管理も可能となるなど、従来のクライアント−サーバ型のシステムと同様の様々な機能を提供することができる。
【００３９】
以下に、ローカル代理サーバを用いて、クライアント−サーバ型と同等の機能をＷＷＷシステムで構築するための実施の形態について説明する。
図２は、本発明の実施の形態におけるシステム構成図である。ＷＷＷブラウザ１１０とローカル代理サーバ１２０とが実行されているクライアント装置１００は、ＬＡＮ４０を介して、代理サーバ２１０が実行されているサーバ装置２００に接続されている。サーバ装置２００は、インターネット５０を介して、ＷＷＷサーバ３１０が実行されているサーバ装置３００に接続されている。ここで、クライアント装置１００のＤＮＳ名を「own.a.co.jp 」とし、代理サーバ２１０が機能するサーバ装置２００のＤＮＳ名を「proxy.a.co.jp 」とし、ＷＷＷサーバ３１０の機能するサーバ装置３００のＤＮＳ名を「host.a.co.jp」とする。
【００４０】
ＷＷＷブラウザ１１０には全てのＷＷＷサーバ３１０の代理サーバとして、自身の計算機上のローカル代理サーバ１２０を指定する（代理サーバアドレスを「own.a.co.jp 」とする）。これにより、ＷＷＷブラウザ１１０は全ての要求をローカル代理サーバ１２０に要求することになる。
【００４１】
ローカル代理サーバ１２０には、ＨＴＴＰ通信中継部が設けられており、自身の実行されているクライアント装置１００から提供される情報により、各要求を実際のＷＷＷサーバまたは代理サーバに送信する。これにより、基本的な通信機能が実現される。
【００４２】
この方式により、既存のＷＷＷブラウザとＷＷＷサーバとの機能を変更することなく、本発明に必要な機能が実現される。まず、効率的に負荷分散を行うための処理を以下に説明する。
【００４３】
図３は、負荷分散のための構成を示す図である。負荷分散処理のために、ローカル代理サーバ１２０にはＨＴＴＰ通信中継部１２１、負荷依存要求分散処理部１２２、及びサーバ状態受信部１２３が設けられている。ＨＴＴＰ通信中継部１２１は、各要求を実際のＷＷＷサーバ、または代理サーバに送信する。負荷依存要求分散処理部１２２は、サーバ状態受信部１２３から各サーバの稼働状況に関する情報を受け取り、ＷＷＷブラウザ１１０からの要求に応じて、要求された処理を提供しているＷＷＷサーバの中で負荷の少ないものを特定する。サーバ状態受信部１２３は、サーバ状態管理部５１０から、ネットワークに接続されているサーバの稼働状況を受け取り、負荷依存要求分散処理部１２２に渡す。
【００４４】
ＷＷＷサーバ３１０が動作しているサーバ装置３００と同一のＩＰセグメントに接続されたサーバ装置４００には、サーバ状態通知部４１０が設けられている。サーバ状態通知部４１０は、状態監視対象のＷＷＷサーバ３１０のアドレス（ＴＣＰ／ＩＰでは、ＩＰアドレスとポート番号の対）を認識している。例えば、サーバ装置３００のＩＰアドレスが「Ａ」、ＷＷＷサーバ３１０のポート番号が「８０」であり、サーバ装置４００のＩＰアドレスが「Ｂ」、サーバ状態通知部４１０のポート番号が「１００１」である場合、ＷＷＷサーバ３１０に対する処理要求のパケットには、ＩＰアドレス「Ａ」、ポート番号「８０」の情報が付加されている。このパケットは、サーバ装置３００と同一ＩＰセグメントに接続された全ての装置に入力される。そして、ＷＷＷサーバ３１０は、ＩＰアドレスとポート番号により、自分宛の要求であることを認識する。同時に、サーバ状態通知部４１０は、ＷＷＷサーバ３１０宛の要求であることを認識する。そして、ＷＷＷサーバ３１０へのＩＰパケット数を計測し（単位時間あたりのパケット数で検出）、ＷＷＷサーバ３１０への負荷を認識する。
【００４５】
さらに、サーバ状態通知部４１０は、ＷＷＷサーバ３１０の負荷状態を一定時間間隔の統計情報として、サーバ装置５００のサーバ状態管理部５１０へ通知する。また、ＷＷＷサーバ３１０の状態の変化（起動→停止／停止→起動）を認識した時点で、ＷＷＷサーバ３１０の動作状態の情報を、サーバ状態通知部５１０に通知する。これにより、ＷＷＷサーバ３１０の負荷状態を通知することによる通信路上の負荷の増加を最小限に抑えることができる。
【００４６】
サーバ状態管理部５１０は、登録されたサーバ状態受信部１２３に、ＷＷＷシステム上のＷＷＷサーバ３１０の状態を通知する。サーバ状態管理部５１０への各サーバ状態受信部１２３の登録は、ＷＷＷブラウザ１１０起動時に、１回のみ、サーバ状態受信部１２３からのＨＴＴＰ要求（要求データの内容は、予め規定しておく）をサーバ状態管理部５１０へ送信することで実施する。
【００４７】
ここで、サーバ状態管理部５１０からサーバ状態受信部１２３への状態の通知には、以下のいずれかの手段を取ることができる。
１つめは、ＷＷＷサーバの状態の遷移を認識した時点で、各サーバ状態受信部へ通知する方式である。ＷＷＷサーバの状態の遷移は、サーバ状態通知部からの状態通知をもって認識する。この場合のサーバ状態の通知は、サーバ状態管理部５１０から主導的にサーバ状態受信部にコネクションを確立して、状態を通知する。
【００４８】
図４は、状態遷移発生を契機とする状態の通知方式を示す図である。サーバ状態通知部４１０は、任意のタイミングでＷＷＷサーバの状態をサーバ状態管理部５１０に通知する（Ｓ１）。すると、サーバ状態管理部５１０は、登録されているクライアント装置１００，６００，７００の各サーバ状態受信部１２３，６２３，７２３へ、サーバの状態を通知する。
【００４９】
２つめは、ＷＷＷブラウザからの要求の発生毎に、ＨＴＴＰ通信中継部からの指示により、サーバ状態受信部１２３から主導的にサーバ状態管理部５１０へ状態の獲得要求を出すことで実現する方式である。
【００５０】
図５は、ＷＷＷブラウザからの要求を契機に状態を通知する方式を示す図である。ＷＷＷブラウザ１１０からＷＷＷサーバへの要求があると（Ｓ１１）、ＨＴＴＰ通信中継部１２１が、どのサーバへ要求を出すべきかの問い合わせを負荷依存要求分散処理部１２２に対して行う（Ｓ１２）。すると、負荷依存要求分散処理部１２２が、サーバ状態受信部１２３に対して、サーバ状態の更新を依頼する（Ｓ１３）。サーバ状態受信部１２３は、サーバ状態管理部５１０に、サーバ状態の通知を要求する（Ｓ１４）。サーバ状態管理部５１０は、要求のあったサーバ状態受信部１２３に最新のサーバ状態を通知する（Ｓ１５）。サーバ状態受信部１２３は、最新の状態を負荷依存要求分散処理部１２２に通知する（Ｓ１６）。負荷依存要求分散処理部１２２は、最新のサーバ状態により負荷の最も少ないサーバを選択して、ＨＴＴＰ通信中継部１２１に通知する（Ｓ１７）。ＨＴＴＰ通信中継部１２１は、負荷依存要求分散処理部１２２から通知されたＷＷＷサーバに要求を送信する（Ｓ１８）。
【００５１】
３つめは、一定時間間隔で、サーバ状態管理部５１０から主導的にサーバ状態受信部１２３へ通知する方式である。
ここで、負荷分散のためには、同じ処理機能を提供するサーバが複数存在する必要がある。このように、複数のサーバで同じ機能を提供する場合には、それらのＷＷＷサーバを統合したアドレス（ＤＮＳ名：代表ＤＮＳ名）が用いられる。このとき、サーバ状態管理部５１０からサーバ状態受信部１２３へ、実在の全てのＷＷＷサーバの情報を負荷情報と共に通知する方式と、サーバ状態管理部５１０がＷＷＷブラウザ毎に要求を処理すべきＷＷＷサーバを特定し、サーバ状態管理部５１０からサーバ状態受信部１２３へ、各ＷＷＷブラウザの要求を処理すべきＷＷＷサーバのアドレスを通知する方式とのいずれかを採用することができる。前者の場合、負荷依存要求分散処理部１２２がサーバの負荷と動作状況を判断し、処理要求を出力すべきＷＷＷサーバを決定する。これにより、ＷＷＷシステム全体としての負荷分散を実現する。後者の場合、サーバ状態管理部５１０が主導的に、ＷＷＷシステム全体の負荷を制御するため、負荷分散の一元管理ができる。以下の説明では、前者の例を用いる。
【００５２】
なお、負荷分散処理により実際の処理を行わせるＷＷＷサーバが決定したら、ＷＷＷブラウザ１１０の要求するアドレスの変換処理を行う必要がある。以下に、アドレス変換方式について説明する。
【００５３】
図６は、負荷依存要求分散処理部におけるアドレス変換方式を説明する図である。この例では、代表ＤＮＳ名「host.a.co.jp」に対して、実際には３つのＷＷＷサーバ３０１，３０２，３０３が処理を行っている。これらＷＷＷサーバ３０１〜３０３のＤＮＳ名は、それぞれ「host1.a.co.jp 」「host2.a.co.jp 」「host3.a.co.jp 」である。
【００５４】
サーバ状態受信部１２３は、サーバ状態管理部５１０から受け取った情報をサーバ状態管理テーブル１２３ａにより管理している。負荷依存要求分散処理部１２２は、サーバ状態受信部１２３を介して、サーバ状態管理テーブル１２３ａを参照することができる。サーバ状態管理テーブル１２３ａには、「代表ＤＮＳ」、「実ＤＮＳ」、「負荷」、「比率」、及び「状態」の欄が設けられている。「代表ＤＮＳ」には、負荷分散を行うべきＷＷＷサーバ群の代表ＤＮＳ名が登録されている。「実ＤＮＳ」には、対応する代表ＤＮＳに含まれる実際のＷＷＷサーバの個々のＤＮＳ名が登録されている。「負荷」には、対応するＷＷＷサーバの単位時間あたりの負荷が設定されている。「比率」には、あるＷＷＷサーバの処理速度を基準として、対応するＷＷＷサーバの処理速度を相対的に示している。この例では、「host1.a.co.jp 」に対応するＷＷＷサーバ３０１の処理速度は基準の２倍であり、「host2.a.co.jp 」に対応するＷＷＷサーバ３０２の処理速度は基準値と同等であり、「host3.a.co.jp 」に対応するＷＷＷサーバ３０３の処理速度は基準の２倍である。「状態」には、対応するＷＷＷサーバの状態が「稼働」か「停止」かで示されている。
【００５５】
この例では、ＷＷＷサーバ３０１は稼働中であり、負荷が「２０」である。また、ＷＷＷサーバ３０２は稼働中であり、負荷が「１５」である。さらに、ＷＷＷサーバ３０３は停止しており、負荷が「０」である。
【００５６】
この状態で、ＷＷＷブラウザ１１０から代表ＤＮＳ「host.a.co.jp」を指定した処理要求が出力されると、そのＤＮＳ名がＨＴＴＰ通信中継部１２１から負荷依存要求分散処理部１２２に送られる。負荷依存要求分散処理部１２２は、サーバ状態管理テーブル１２３ａを参照して、稼働中のＷＷＷサーバの中で相対処理量が少ないものを特定する。ここで、相対処理量は、「負荷」の値を、「比率」の値で除算することで求められる。図６の例では、稼働中のＷＷＷサーバは、「host1.a.co.jp 」と「host2.a.co.jp 」との２つである。これらの相対処理量を求めると、「host1.a.co.jp 」については「２０÷２＝１０」となり、「host2.a.co.jp 」については「１５÷１＝１５」となる。これにより、「host1.a.co.jp 」の方が処理余力があると判断する。そして、負荷依存要求分散処理部１２２は、ＷＷＷブラウザ１１０からの処理要求を、ＤＮＳ名が「host1.a.co.jp 」であるＷＷＷサーバ３０２に処理させることを決定する。
【００５７】
ＨＴＴＰ通信中継部１２１は、ＷＷＷブラウザ１１０が出力した代表ＤＮＳ名「host.a.co.jp」を負荷依存要求分散処理部１２２が決定した実ＤＮＳ名「host1.a.co.jp 」に変換し、処理要求をネットワーク上に出力する。すると、実ＤＮＳ名「host1.a.co.jp 」に基づいて、処理要求がＷＷＷサーバ３０１に渡され、所望の処理が行われる。
【００５８】
以上のようにして、負荷分散を効率的に行うことが可能となる。なお、サーバ装置５００（図３に示す）に対して命令を入力することにより、各サーバの状態を任意に変更することも可能である。ＷＷＷサーバの保守作業の際に、サーバ状態管理部５１０におけるそのＷＷＷサーバの状態を「停止」に固定しておけば、保守作業中のＷＷＷサーバに対して処理要求が出力されることがなくなり、保守点検作業が容易となる。
【００５９】
図７は、サーバ状態管理部へ任意の状態を指示するための構成を示す図である。システム管理者による端末装置５０１の操作、またはシステムプログラムからの要求により、コマンドプログラム５２０に状態変更コマンドが投入される（Ｓ２１）。コマンドプログラム５２０は、サーバ状態管理部５１０に状態遷移の通知を行う（Ｓ２２）。この通知は、サーバ状態通知部４１０（図３に示す）がサーバ状態管理部５１０へ通知するものと同様である。ただし、コマンドプログラム５２０からの設定の内容は、設定解除の指令があるまで固定される。設定解除の指令は、端末装置５０１の操作、またはシステムプログラムからの要求により、コマンドプログラム５２０に投入される。サーバ状態管理部５１０は、サーバ状態受信部１２３に、サーバの状態を通知する（Ｓ２３）。サーバ状態受信部１２３は、サーバ状態管理部５１０からの通知に応じてサーバ状態管理テーブルの状態を変更する。図の例では、「host2.a.co.jp 」のＷＷＷサーバの状態が「停止」に変更されている。このとき同時に、「負荷」が「０」に変更され、「比率」が「３」に変更されている。
【００６０】
このように、任意のＷＷＷサーバの状態を変更することで、特定のサーバの負荷を軽減したり、保守作業中のＷＷＷサーバへの要求が出力されないようにすることができる。
【００６１】
ところで、ＨＴＴＰは、１つの要求に対する１つの応答で処理が完結する一問一答型のプロトコルである。このようなプロトコルを用い、また、ＷＷＷブラウザとＷＷＷサーバとの機能拡張をすることなく、継続的なセションを管理の通信を実現する方式を以下に説明する。
【００６２】
図８は、継続的なセション管理を実現するための構成を示す図である。セション管理を実現するために、ローカル代理サーバ１２０内にセション管理部１２４が設けられている。また、ＷＷＷサーバ３１０が実行されているサーバ装置３００にもセション管理部３２０が設けられている。ここで、サーバ装置３００内のセション管理部３２０をマスターとし、ローカル代理サーバ１２０内のセション管理部１２４をスレーブとする。
【００６３】
ＨＴＴＰ通信中継部１２１は、セション管理対象資源データベース１２１ａを有している。スレーブのセション管理部１２４は、クライアントセション情報と要求の対象資源のＵＲＬとの対を登録するためのクライアント管理データベース１２４ａを有している。マスターのセション管理部３２０は、セション情報データベース３２１を有している。
【００６４】
セション管理対象資源データベース１２１ａには、セション管理を行うべきサーバ側のプログラム名が登録されている。この例では、「SESSSTART 」で示されたプログラム名「http://www.host.a.co.jp/cgi-bin/start 」が、セション管理を開始させるためのプログラム名である。また、「SESSEND 」で示されたプログラム名「http://www.host.a.co.jp/cgi-bin/end 」が、セション管理を終了するためのプログラム名である。
【００６５】
クライアント管理データベース１２４ａには、クライアントセション情報とＵＲＬとの対が格納される。セション情報データベース３２１には、クライアントセション情報とサーバセション情報との対が格納される。
【００６６】
また、サーバ装置３００では、サービス提供プログラム３３０が各種サービスを提供している。この例では、ＷＷＷブラウザからの要求毎にＣＧＩ(Common Gateway Interface)というインタフェースでＷＷＷサーバから起動されるプログラムの形式であるものとする。その他にも、一般的に普及している他のインタフェースを用いることができる。例えば、Netscape社のＮＳＡＰＩやMicrosoft 社のＩＳＡＰＩ等がある。
【００６７】
ここで、ＷＷＷブラウザ１１０からＨＴＴＰ通信中継部１２１へ、セション管理対象資源データベース１２１ａに設定された特定のＷＷＷサーバの特定の資源への要求（セション管理開始要求）が通知された場合、以下のような処理を行う。
ここで、特定のＷＷＷサーバの特定の資源への要求は、ＵＲＬ(Uniform Resource Locator)で指定される。ＵＲＬは、ＨＴＴＰで資源を特定するために使用する資源毎のアドレス情報であり、ＤＮＳ名とＷＷＷサーバ上の資源名で構成される。
【００６８】
図９は、セション管理を開始する際の処理手順を示すフローチャートの前半である。この処理をステップ番号に沿って説明する。
［Ｓ３１］ＷＷＷブラウザ１１０がセション管理開始要求プログラム（http://www.host.a.co.jp/cgi-bin/start ）に対する要求を出す。
［Ｓ３２］ＨＴＴＰ通信中継部１２１が、セション管理対象資源データベース１２１ａを参照することにより、セション管理を開始すべきことを認識し、セション管理部１２４にクライアントセション情報の採番依頼を出力する。
［Ｓ３３］セション管理部１２４が、クライアントセション情報を採番する。ここで、クライアントセション情報とは、要求を出力したＷＷＷブラウザを特定するために用いられる識別番号である。このクライアントセション情報を用いることで、複数のＷＷＷブラウザが同時に個別のセション管理の通信を行っても、それぞれの通信を区別することができる。
［Ｓ３４］セション管理部１２４が、クライアントセション情報とＵＲＬとの対をクライアントセション管理データベース１２４ａに登録する。
［Ｓ３５］ＨＴＴＰ通信中継部１２１が、クライアントセション情報とＵＲＬとを、要求のＨＴＴＰのヘッダ情報に付加する。
［Ｓ３６］ＨＴＴＰ通信中継部１２１が、要求の宛先をセション管理部３２０に変更し、その要求を送信する。
［Ｓ３７］ＷＷＷサーバ３１０が、要求をセション管理部３２０に受け渡す。
［Ｓ３８］セション管理部３２０が、サーバセション情報を採番する。
［Ｓ３９］セション管理部３２０が、クライアントセション情報とサーバセション情報との対（この対をセションＩＤとする）を、セション情報データベース３２１に登録する。ここで、サーバセション情報とは、複数のＷＷＷブラウザとの間で確立したセションを区別するための識別番号である。
［Ｓ４０］セション管理部３２０が、セションＩＤをＨＴＴＰヘッダに付加する。
［Ｓ４１］セション管理部３２０が、ＨＴＴＰヘッダのＵＲＬを元の宛先ＵＲＬに復元し、サービス提供プログラム３３０へ渡す。この際、セションＩＤをＣＧＩ上のデータとしてサービス提供プログラム３３０に通知する。サービス提供プログラム３３０は、このセションＩＤの付加により、以降、同一のセションＩＤが付加された要求は、同一のＷＷＷブラウザからの同一のセション内の要求であることを認識できる。
［Ｓ４２］サービス提供プログラム３３０が処理を実施し、応答をセション管理部３２０へ返却する。
【００６９】
図１０は、セション管理を開始する際の処理手順を示すフローチャートの後半である。
［Ｓ４３］セション管理部３２０が、セションＩＤからクライアントセション情報を取り出す。
［Ｓ４４］セション管理部３２０が、クライアントセション情報をＨＴＴＰヘッダに付加し（ＣＧＩインタフェースで設定可能）、ＷＷＷサーバ３１０に応答を送信する。
［Ｓ４５］ＷＷＷサーバ３１０が、応答をＷＷＷブラウザ１１０に送信する。
［Ｓ４６］ＨＴＴＰ通信中継部１２１が、ＷＷＷサーバ３１０からの応答を受信し、ＨＴＴＰの応答のヘッダ情報にクライアントセション情報が付加されているか否かを確認する。クライアントセション情報が付加されていた場合、その情報をセション管理部１２４に渡す。
［Ｓ４７］セション管理部１２４が、クライアントセション管理データベース１２４ａを参照し、セションの有効性を検証する。このセションの有効性の検証は、ＷＷＷサーバ３１０からの応答が返されるまでに、ＷＷＷブラウザ１１０から要求の中止指令が入力される場合があるため、その中止処理の有無を検査するものである。
【００７０】
すなわち、セション管理の処理をＷＷＷサーバへ要求し、その応答が返されるまでの間にＷＷＷブラウザ１１０からセションコネクション切断の指令が入力されると、セション管理部１２４が、クライアント管理データベース１２４ａ内の対応する情報を削除する。これにより、クライアント装置１００側ではコネクションが切断されたことになる。ただし、その後ＷＷＷサーバ３１０から以前に要求した処理の応答が返される場合がある。そこで、応答を受け取ったＨＴＴＰ通信中継部１２１は、その応答に該当するクライアントセション情報の有無をセション管理部１２４に問い合わせることで、そのセションの有効性を検証するのでる。
［Ｓ４８］ＨＴＴＰ通信中継部１２１が、セション管理部１２４によるセションの有効性の検証結果が、有効であったか否かを判断する。有効であればステップＳ５０に進み、有効でなければステップＳ４９に進む。
［Ｓ４９］ＨＴＴＰ通信中継部１２１が、セション管理部３２０へ異常を通知し、処理を終了する。すなわち、セションの有効性の検証結果が無効であれば、コネクションが切断されていると認識し、その旨のセション管理部３２０側へ渡すことで、セション管理部３２０側においても、該当するセションのセションＩＤをセション情報データベース３２１から削除できる。
［Ｓ５０］ＨＴＴＰ通信中継部１２１が、ＷＷＷブラウザ１１０へ応答内容を渡す。
［Ｓ５１］ＷＷＷブラウザ１１０が、応答を受信し処理が終了する。
【００７１】
以上が、ＷＷＷブラウザがセション管理開始要求を出力した際の処理である。これにより、ＷＷＷサーバ３１０とＷＷＷブラウザ１１０との間で継続したセションコネクションが確立する。以降のＷＷＷブラウザ１１０からの要求のうち、クライアントセション管理データベース１２４ａにセションが登録されている資源への要求には、登録されているクライアントセション情報を要求に付加して送信する。これにより、セション管理装置３２０では，セション管理データベース３２１の情報から、同一セションの要求であることを認識できる。
【００７２】
以下に、確立されたセション中の処理要求をＷＷＷブラウザ１１０が出力した際の処理手順を説明する。
図１１は、管理されているセション上での要求の処理手順を示すフローチャートの前半である。
［Ｓ６１］ＷＷＷブラウザ１１０が、同一セション中の要求（セションが確立されているＷＷＷサーバに対する要求）を出力する。
［Ｓ６２］ＨＴＴＰ通信中継部１２１が、要求の対象資源のＵＲＬがすでに確立されたセションのものかをセション管理部１２４に問い合わせる。
［Ｓ６３］セション管理部１２４が、要求対象資源のＵＲＬのＩＰアドレスを含むクライアントセション情報を、クライアントセション管理データベースから検索し、登録されているクライアントセション情報をＨＴＴＰ通信中継部１２１へ返却する。
［Ｓ６４］ＨＴＴＰ通信中継部１２１が、セション中と認識し、クライアントセション情報とＵＲＬとを要求のＨＴＴＰヘッダ情報に付加し、要求の宛先をセション管理部３２０に変更して、ＨＴＴＰの要求を送信する。
［Ｓ６５］ＷＷＷサーバ３１０が、要求をセション管理部３２０へ渡す。
［Ｓ６６］セション管理部３２０が、ＨＴＴＰヘッダのクライアントセション情報を認識し、そのクライアントセション情報を含むセションＩＤをセション情報データベース３２１から検索する。
［Ｓ６７］セション管理部３２０が、セションＩＤをＨＴＴＰヘッダに付加する。
［Ｓ６８］セション管理部３２０が、ＨＴＴＰヘッダに付加されている要求対象資源のＵＲＬをＨＴＴＰ要求の宛先ＵＲＬに復元し、ＨＴＴＰ要求をサービス提供プログラム３３０に渡す。
［Ｓ６９］サービス提供プログラム３３０が、要求された処理を実行し、応答をセション管理部３２０に返す。このとき、ＨＴＴＰヘッダに付加されるセションＩＤと、独自に管理しているセションＩＤの一致により、先に確立したセション上の処理要求であることを認識する。また、応答のＨＴＴＰヘッダには、要求のセションＩＤを含める。
【００７３】
図１２は、管理されているセション上での要求の処理手順を示すフローチャートの後半である。
［Ｓ７０］セション管理部３２０が、セションＩＤからクライアントセション情報を取り出す。
［Ｓ７１］セション管理部３２０が、クライアントセション情報をＨＴＴＰヘッダに付加し、ＷＷＷブラウザ１１０への応答を出力する。
［Ｓ７２］ＷＷＷサーバ３１０が、応答をＷＷＷブラウザ１１０に送信する。
［Ｓ７３］ＨＴＴＰ通信中継部１２１が、ＨＴＴＰヘッダからクライアントセション情報を取り出す。
［Ｓ７４］セション管理部１２４が、クライアントセション管理データベース１２４ａからセションの有効性を検証する。
［Ｓ７５］ＨＴＴＰ通信中継部１２１は、セションは有効か否かを判断する。有効であればステップＳ７７に進み、有効でなければステップＳ７６に進む。
［Ｓ７６］ＨＴＴＰ通信中継部１２１が、セション管理部３２０へ異常を通知し、処理を終了する。
［Ｓ７７］ＨＴＴＰ通信中継部１２１が、ＷＷＷブラウザ１１０に応答を送信する。
［Ｓ７８］ＷＷＷブラウザ１１０が応答を受信し、処理が終了する。
【００７４】
以上が、確立されたセション上での処理である。次に、セション管理を終了する際の手順を説明する。セションの切断は、ＨＴＴＰ通信中継部１２１のセション管理対象資源データベース１２１ａに指定された特定の資源への要求（セション管理終了要求）を受信した場合にＨＴＴＰ通信中継部１２１により行われる。
【００７５】
図１３は、セション管理を終了する際の処理手順を示すフローチャートの前半である。
［Ｓ８１］ＷＷＷブラウザ１１０が、セション管理終了要求を出力する。すなわち、プログラム名「http://www.host.a.co.jp/cgi-bin/end 」を指定した処理要求を出力する。
［Ｓ８２］ＨＴＴＰ通信中継部１２１が、要求対象資源のＵＲＬがすでに確立されたセションのものかをセション管理部１２４に問い合わせる。
［Ｓ８３］セション管理部１２４が、要求対象資源のＵＲＬのＩＰアドレスを含むクライアントセション情報を検索し、登録されているクライアントセション情報を返却する。
［Ｓ８４］ＨＴＴＰ通信中継部１２１が、セションが確立されていると認識し、クライアントセション情報とＵＲＬとを要求のＨＴＴＰヘッダ情報に付加し、要求の宛先をセション管理部３２０に変更して、送信する。
［Ｓ８５］ＷＷＷサーバ３１０が、要求をセション管理部３２０へ渡す。
［Ｓ８６］セション管理部３２０が、ＨＴＴＰヘッダのクライアントセション情報を認識し、セション情報データベース３２１から対象のセションＩＤを削除する。
［Ｓ８７］セション管理部３２０が、ＨＴＴＰ通信中継部１２１に応答を送信する。
［Ｓ８８］セション管理部３２０が、サービス提供プログラム３３０にセション管理の終了を通知する。
［Ｓ８９］サービス提供プログラム３３０が、セションの終了を認識する。サーピス提供プログラム３３０は、これにより独自に管埋しているセションＩＤを破棄する。
【００７６】
図１４は、セション管理を終了する際の処理手順を示すフローチャートの後半である。
［Ｓ９０］ＷＷＷサーバ３１０が、応答をＷＷＷブラウザ１１０に送信する。
［Ｓ９１］ＨＴＴＰ通信中継部１２１が、ＨＴＴＰヘッダからクライアントセション情報を取り出す。
［Ｓ９２］ＨＴＴＰ通信中継部１２１が、セション管理部１２４にセション情報の破棄を依頼する。
［Ｓ９３］セション管理部１２４が、該当するセション情報を破棄する。
［Ｓ９４］ＨＴＴＰ通信中継部１２１が、ＷＷＷブラウザ１１０に応答を送信する。
［Ｓ９５］ＷＷＷブラウザ１１０が応答を受信し、処理が終了する。
【００７７】
このようにして、セション切断処理が行われる。
以上のような処理をクライアント装置とサーバ装置間で行うことにより、従来のクライアント−サーバシステムと同様の処理を、ＨＴＴＰのプロトコル上で実現できる。従って、全世界に普及しているＷＷＷブラウザとＷＷＷサーバとが一般的に有している機能を使用して、継続したセションコネクションが可能となる。
【００７８】
ところで、従来のＷＷＷブラウザでは、要求を出力するＷＷＷサーバに応じて、要求を中継する代理サーバを使い分けることができなかった。そこで、クライアント装置１００のローカル代理サーバ１２０によって、ＷＷＷサーバ毎に個別の代理サーバを設定することもできる。その例を以下に示す。
【００７９】
図１５は、複数の代理サーバを管理するための構成を示す図である。この例では、別々のサーバ装置２００，２００ａ内に代理サーバ２１０，２１０ａが設けられている。また、サーバ装置３００，３００ａ内には、それぞれ個別のＷＷＷサーバ３１０，３１０ａが設けられている。
【００８０】
さらに、複数の代理サーバ２１０，２１０ａを管理するために、ローカル代理サーバ１２０内に代理サーバアドレス管理部１２５が設けられている。代理サーバアドレス管理部１２５は、代理サーバアドレス管理データベース１２５ａを有している。代理サーバアドレス管理データベース１２５ａは、ＷＷＷブラウザ１１０が要求を出力するＷＷＷサーバ３１０，３１０ａのＤＮＳ名に対応して、そのＷＷＷサーバへの要求を中継すべき代理サーバ２１０，２１０ａのＤＮＳ名が登録されている。この例では、ＤＮＳ名が「host.a.co.jp」のＷＷＷサーバ３１０への要求は、ＤＮＳ名が「proxy.a.co.jp 」の代理サーバ２１０が中継し、ＤＮＳ名が「host1.a.co.jp 」のＷＷＷサーバ３１０ａへの要求は、ＤＮＳ名が「proxy1.a.co.jp」の代理サーバ２１０ａが中継するように設定されている。
【００８１】
また、ＷＷＷブラウザ１１０では、代理サーバの指定として、クライアント装置１００自身のＤＮＳ名（「own.a.co.jp 」）を指定している。
ＨＴＴＰ通信中継部１２１は、ＷＷＷブラウザ１１０からの要求を受信する毎に、その要求の対象資源のＵＲＬから、宛先のＷＷＷサーバのアドレス（ＤＮＳ名またはＩＰアドレス）を取り出す。そして、取り出した宛先に対応する代理サーバを、代理サーバアドレス管理部１２５に問い合わせる。代理サーバアドレス管理部１２５は、与えられた宛先のアドレスの対応する代理サーバのアドレスを、代理サーバアドレス管理データベース１２５ａから検索して、ＨＴＴＰ通信中継部１２１に返却する。ＨＴＴＰ通信中継部１２１は、代理サーバアドレス管理部１２５が送り返してきた代理サーバのアドレスを指定して、要求を出力する。
【００８２】
これにより、ＷＷＷサーバに応じた代理サーバの使い分けが可能となる。なお、代理サーバアドレス管理データベース１２５ａの設定は、ＷＷＷブラウザ１１０等からユーザが手動で設定することもできるが、ＷＷＷシステム上の任意の計算機上の代理サーバアドレス配布部から配布される情報に基づいて、動的に内容を変更することもできる。
【００８３】
図１６は、代理サーバの指定を動的に変更するための構成を示す図である。図に示すように、ＬＡＮ４０には複数のクライアント装置１００，６００が接続されている。それぞれのクライアント装置１００，６００のローカル代理サーバ１２０，６２０内に代理サーバアドレス管理部１２５，６２５が設けられており、代理サーバアドレス管理部１２５，６２５が代理サーバアドレス管理データベース１２５ａ，６２５ａを有している。
【００８４】
ＬＡＮ４０には、サーバ装置８００が接続されている。サーバ装置８００には、代理サーバアドレス配布部８１０が設けられている。代理サーバアドレス配布部８１０は、サーバ装置８００での命令の実行により、指定されたＷＷＷブラウザの動作するクライアント装置１００，６００上の代理サーバアドレス管理部１２５，６２５に対して、代理サーバアドレス情報を配布する。配布のためのプロトコルには、ＨＴＴＰを使用する。
【００８５】
代理サーバアドレス管理部１２５，６２５は、ＨＴＴＰ上の代理サーバアドレス配布部８１０からの代理サーバアドレス情報の配布メッセージを受信するため、特定のＴＣＰ／ＩＰのポート番号でＴＣＰ／ＩＰコネクションの確立を、絶えず受け付け待ちの状態とする。代理サーバアドレス配布部８１０からの配布メッセージを受信した代理サーバアドレス管理部１２５，６２５は、その配布メッセージに含まれる代理サーバアドレス情報を代理サーバアドレス管理データベース１２５ａ，６２５ａに反映させる。
【００８６】
これにより、企業内のＬＡＮなどで多数のクライアント装置が接続されている場合に、各クライアント装置内の代理サーバの指定に関する設定を、代理サーバアドレス配布部８１０から変更することができる。その結果、システム管理者の作業量が減少する。この効果は、ネットワークが大規模になるほど大きくなる。
【００８７】
また、使用中の代理サーバが故障した場合には、即座に別の代理サーバを設定し、各ＷＷＷブラウザに対して、新たに設定した代理サーバを指定させることができる。すなわち、タイムリーな代理サーバの変更が可能である。
【００８８】
さらに、各クライアント装置内での代理サーバの指定は、代理サーバアドレス管理部が管理しており、その内容を代理サーバアドレス配布部８１０から変更することができるため、ＬＡＮ内に複数の種類のＷＷＷブラウザが混在しており、ＷＷＷブラウザ毎に代理サーバのアドレス設定方法が異なる場合においても、代理サーバアドレス配布部８１０により一括して設定の変更が可能である。
【００８９】
ところで、複数の代理サーバが存在し、あるＷＷＷサーバに対する要求を、どの代理サーバを介してでも送信できる場合、代理サーバ間での負荷分散を行うこともできる。そこで、図３に示したようなＷＷＷサーバの負荷分散処理機能を用いて、代理サーバの負荷分散を行うことが考えられる。
【００９０】
図１７は、代理サーバの負荷分散機能を示す図である。この図に示す構成要素は、図３及び図１５において同じ符号を付して説明した通りの機能に加え、以下のような機能を更に有している。
【００９１】
サーバ状態通知部４１０は、ＷＷＷサーバ３１０の状態だけでなく代理サーバ２１０，２１０ａの状態も、サーバ状態管理部５１０へ通知する。サーバ状態管理部５１０は、サーバ状態通知部４１０から送られた各サーバの状態を、クライアント装置１００のサーバ状態受信部１２３へ通知する。サーバ状態受信部１２３は、代理サーバ２１０，２１０ａの状態を含めて、サーバ状態管理テーブル１２３ａに登録する。代理サーバアドレス管理部１２５は、代理サーバアドレス管理データベース１２５ａにおいて、１つのＷＷＷサーバのＤＮＳ名に対して、複数の代理サーバのＤＮＳ名を対応付けることができる。ＨＴＴＰ通信中継部１２１は、ＷＷＷブラウザ１１０からの特定のＷＷＷサーバに対する要求を受け取ると、代理サーバアドレス管理部１２５に対し、指定されたＷＷＷサーバに対応する代理サーバのＤＮＳ名を要求する。このとき、該当する代理サーバが複数存在する場合には、代理サーバアドレス管理部１２５が負荷依存要求分散処理部１２２に対し、最も負荷の少ない代理サーバの検出を依頼する。負荷依存要求分散処理部１２２は、ＨＴＴＰ通信中継部１２１の依頼に応じ、負荷の少ない代理サーバをサーバ状態管理テーブル１２３ａから検出し、代理サーバアドレス管理部１２５へ返す。代理サーバアドレス管理部１２５は、負荷依存要求分散処理部１２２が選んだ代理サーバのＤＮＳ名をＨＴＴＰ通信中継部１２１へ返す。ＨＴＴＰ通信中継部１２１は、返されたＤＮＳ名の代理サーバへ要求を出力する。
【００９２】
このような代理サーバの負荷分散処理は、ＷＷＷサーバの負荷分散と同時に行うことができる。その処理の詳細を以下に説明する。
図１８は、ＷＷＷサーバと代理サーバとの負荷分散を同時に行うための処理手順を示すフローチャートの前半である。このフローチャートをステップ番号に沿って説明する。
［Ｓ１０１］ＨＴＴＰ通信中継部１２１が、負荷依存要求分散処理部１２２へ、要求ＵＲＬのＷＷＷサーバのＤＮＳ名から最適なＷＷＷサーバの選択を依頼する。
［Ｓ１０２］負荷依存要求分散処理部１２２が、ＨＴＴＰ通信中継部１２１からのＷＷＷサーバ選択依頼におけるＷＷＷサーバのＤＮＳ名から、そのＤＮＳ名に対応した最適なＷＷＷサーバをサーバ状態管理テーブル１２３ａより検索する。［Ｓ１０３］負荷依存要求分散処理部１２２が、目的とする稼働状態のＷＷＷサーバがあったかどうかを判断し、該当するＷＷＷサーバがあればステップＳ１０５に進み、なければステップＳ１０４に進む。
［Ｓ１０４］ＨＴＴＰ通信中継部１２１が、ＷＷＷサーバ異常のエラー応答を作成し、ＷＷＷブラウザ１１０に返信する。
［Ｓ１０５］ＨＴＴＰ通信中継部１２１が、負荷依存要求分散処理部１２２から通知されたＷＷＷサーバへの要求に、元の要求の宛先を変更する。
［Ｓ１０６］ＨＴＴＰ通信中継部１２１が、代理サーバアドレス管理部１２５に、ＷＷＷサーバへの要求で使用する代理サーバの選択を依頼する。
［Ｓ１０７］代理サーバアドレス管理部１２５が、ＨＴＴＰ通信中継部１２１からの代理サーバアドレス選択依頼におけるＷＷＷサーバのＤＮＳ名から、使用可能な代理サーバのアドレスを選択する。
【００９３】
図１９は、ＷＷＷサーバと代理サーバとの負荷分散を同時に行うための処理手順を示すフローチャートの後半である。
［Ｓ１０８］代理サーバアドレス管理部は、使用可能な代理サーバが検出されたか否かを判断する。検出された場合にはステップＳ１１１に進み、検出されなかった場合にはステップＳ１０９に進む。
［Ｓ１０９］代理サーバアドレス管理部１２５が、使用可能な代理サーバがないことをＨＴＴＰ通信中継部１２１に返信する。
［Ｓ１１０］ＨＴＴＰ通信中継部１２１が、ＷＷＷサーバ異常のエラー応答を作成し、ＷＷＷブラウザ１１０に返信する。
［Ｓ１１１］代理サーバアドレス管理部１２５が、負荷依存要求分散処理部１２２に代理サーバ群のＤＮＳ名を渡し、その中から負荷／状態が最適な代理サーバの選択を依頼する。
［Ｓ１１２］負荷依存要求分散処理部１２２が、代理サーバアドレス管理部１２５からの代理サーバ選択依頼の代理サーバ群のＤＮＳ名から、最適な代理サーバをサーバ状態管理テーブル１２３ａより検索し、検出した代理サーバのＤＮＳ名を代理サーバアドレス管理部１２５へ返却する。
［Ｓ１１３］代理サーバアドレス管理部１２５が、負荷依存要求分散処理部１２２から返却された代理サーバのＤＮＳ名を、ＨＴＴＰ通信中継部１２１に返却する。
［Ｓ１１４］ＨＴＴＰ通信中継部１２１が、代理サーバアドレス管理部１２５から返却された代理サーバのＤＮＳ名を使用して、代理サーバ経由の通信を行う。
【００９４】
このようにして、ＷＷＷサーバと代理サーバとの負荷分散を同時に行うことができる。
さらに、上記のようなローカル代理サーバを用いれば、通信される文書などの文字コードの判別を確実に行うこともできる。
【００９５】
インターネットなどのＷＷＷサーバで使用する文字コードは、統一されていない。すなわち、あるＷＷＷサーバではＥＵＣ(Extended Unix Code)が用いられ、別のＷＷＷサーバではShift-JIS が用いられる場合がある。従来は、このような文字コードの違いを自動認識によって判別していた。ところが、自動認識機能では、ある程度以上のデータ量がなければコード系を認識することができなかった。そのため、大きな文書を受け取った場合には、文字コードの判別が可能であったが、単純な命令文に含まれる文字のコードを判別するのは困難であった。そこで、ローカル代理サーバに属性管理機能を設けることで、文字コードの管理を行う例を以下に示す。
【００９６】
図２０は、文字コードの管理を行うための構成を示す図である。文字コードを管理するために、ＨＴＴＰ通信中継部１２１はコード変換部１２１ａを有している。コード変換部１２１ａは、ＷＷＷブラウザ１１０のコード系を認識しており、ＷＷＷサーバから受信した情報の文字コードを、ＷＷＷブラウザ１１０が対応している文字コードに変換したり、ＷＷＷサーバへ送信すべき情報をＷＷＷサーバのコード系に応じて変換する。
【００９７】
また、ローカル代理サーバ１２０内に、属性管理部１２６が設けられている。属性管理部１２６は、サーバ属性管理データベース１２６ａを有している。サーバ属性管理データベース１２６ａには、ＷＷＷサーバのＤＮＳ名に対応付けて、サーバ属性が登録されている。サーバ属性は、ここでは、そのサーバで使用しているコード系である。図の例では、ＤＮＳ名が「host1.a.co.jp 」サーバ装置３００ａで動作するＷＷＷサーバ３１０ａのコード系は「ＥＵＣ」であり、ＤＮＳ名が「host2.a.co.jp 」のサーバ装置３００ｂで動作するＷＷＷサーバ３１０ｂのコード系は「Shift-JIS 」である。
【００９８】
このようなシステムにおいて、ＷＷＷブラウザ１１０からＷＷＷサーバへの要求があると、ＨＴＴＰ通信中継部１２１は、要求先のＷＷＷサーバの属性を属性管理部１２６に問い合わせる。属性管理部１２６は、サーバ属性管理データベース１２６ａを参照し、要求先のＷＷＷサーバのＤＮＳ名から、そのＷＷＷサーバの属性を検出し、検出した属性をＨＴＴＰ通信中継部１２１に返す。ＨＴＴＰ通信中継部１２１では、コード変換部１２１ａにより、ＷＷＷブラウザ１１０の出力した情報のコードを、送信すべきＷＷＷサーバの属性に応じたコードに変換し、そのＷＷＷサーバに向けて送信する。
【００９９】
また、ＷＷＷサーバから情報を受け取った際にも同様に、ローカル代理サーバ１２０は、ＷＷＷサーバのＤＮＳ名からコード系を識別し、ＷＷＷブラウザ１１０の属性に応じたコードに変換してＷＷＷブラウザ１１０に渡す。
【０１００】
このようにして、情報の大小に関係なく、正しい文字コードへ変換することが可能となる。
なお、上記ＨＴＴＰ通信中継部は、中継した通信の履歴情報を保存しておくことができる。これにより、何らかの通信異常が派生した場合、その発生原因を明確にできる。すなわち、従来のＷＷＷシステムではＷＷＷサーバからの応答がＷＷＷブラウザに正しく通知されたか否かの確認手段がなかった。一方、既存のクライアント−サーバ型のシステムでは、サーバからの応答のクライアントへの到達の確認が必要な場合が多い。また、実際の運用時に応答の到達確認が不要であっても、エラー等の発生時には、情報の到達の有無によりエラーの発生原因を解析できる場合が多い。そこで、本発明のローカル代理サーバを用いれば、中継した通信の履歴情報を保存しておくことで、ＷＷＷサーバからの情報の到達の有無を確認し、トラブル発生時の解析作業に役立てることができる。
【０１０１】
なお、上記の処理機能は、コンピュータによって実現することができる。その場合、ローカル代理サーバ、サーバ状態通知部、サーバ状態管理部、セション管理部（マスター、スレーブ）、及び代理サーバアドレス配布部が有すべき機能の処理内容は、コンピュータで読み取り可能な記録媒体に記録されたプログラムに記述されており、このプログラムをコンピュータで実行することにより、上記処理がコンピュータで実現される。コンピュータで読み取り可能な記録媒体としては、磁気記録装置や半導体メモリ等がある。市場を流通させる場合には、ＣＤ−ＲＯＭ(Compact Disk Read Only Memory) やフロッピーディスク等の可搬型記録媒体にプログラムを格納して流通させたり、ネットワークを介して接続されたコンピュータの記憶装置に格納しておき、ネットワークを通じて他のコンピュータに転送することもできる。コンピュータで実行する際には、コンピュータ内のハードディスク装置等にプログラムを格納しておき、メインメモリにロードして実行する。
【０１０２】
【発明の効果】
以上説明したように本発明の負荷分散システムでは、要求分散処理手段がサーバ状態管理手段からサーバの負荷情報を取得し、処理要求が出力された際には、クライアント装置内の要求分散処理手段によって負荷の少ないサーバが特定されるため、ネットワーク上のどこにも処理を集中させることなく適切な負荷分散を行うことができる。
【図面の簡単な説明】
【図１】本発明の原理構成図である。
【図２】本発明の実施の形態におけるシステム構成図である。
【図３】負荷分散のための構成を示す図である。
【図４】状態遷移発生を契機とする状態の通知方式を示す図である。
【図５】ＷＷＷブラウザからの要求を契機に状態を通知する方式を示す図である。
【図６】負荷依存要求分散処理部におけるアドレス変換方式を説明する図である。
【図７】サーバ状態管理部へ任意の状態を指示するための構成を示す図である。
【図８】継続的なセション管理を実現するための構成を示す図である。
【図９】セション管理を開始する際の処理手順を示すフローチャートの前半である。
【図１０】セション管理を開始する際の処理手順を示すフローチャートの後半である。
【図１１】管理されているセション上での要求の処理手順を示すフローチャートの前半である。
【図１２】管理されているセション上での要求の処理手順を示すフローチャートの後半である。
【図１３】セション管理を終了する際の処理手順を示すフローチャートの前半である。
【図１４】セション管理を終了する際の処理手順を示すフローチャートの後半である。
【図１５】複数の代理サーバを管理するための構成を示す図である。
【図１６】代理サーバの指定を動的に変更するための構成を示す図である。
【図１７】代理サーバの負荷分散機能を示す図である。
【図１８】ＷＷＷサーバと代理サーバとの負荷分散を同時に行うための処理手順を示すフローチャートの前半である。
【図１９】ＷＷＷサーバと代理サーバとの負荷分散を同時に行うための処理手順を示すフローチャートの後半である。
【図２０】文字コードの管理を行うための構成を示す図である。
【符号の説明】
１，２，３，４，５  サーバ装置
１ａ，２ａ  サーバ
３ａ，４ａ  サーバ状態通知手段
５ａ  サーバ状態管理手段
６  クライアント装置
６ａ  要求分散処理手段
６ｂ  要求中継手段
【図１】
0003966598.tif 000002
【図２】
0003966598.tif 000003
【図３】
0003966598.tif 000004
【図４】
0003966598.tif 000005
【図５】
0003966598.tif 000006
【図６】
0003966598.tif 000007
【図７】
0003966598.tif 000008
【図８】
0003966598.tif 000009
【図９】
0003966598.tif 000010
【図１０】
0003966598.tif 000011
【図１１】
0003966598.tif 000012
【図１２】
0003966598.tif 000013
【図１３】
0003966598.tif 000014
【図１４】
0003966598.tif 000015
【図１５】
0003966598.tif 000016
【図１６】
0003966598.tif 000017
【図１７】
0003966598.tif 000018
【図１８】
0003966598.tif 000019
【図１９】
0003966598.tif 000020
【図２０】
0003966598.tif 000021