JP2012068995A

JP2012068995A - 中継処理方法、中継処理装置及び中継処理プログラム

Info

Publication number: JP2012068995A
Application number: JP2010214382A
Authority: JP
Inventors: Kenji Oki; 憲二大木; Akihiko Matsuo; 昭彦松尾
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 2010-09-24
Filing date: 2010-09-24
Publication date: 2012-04-05

Abstract

【課題】サーバダウン時における処理の一貫性を図るとともに、処理の効率化を図る。
【解決手段】クライアントからのリクエストデータに応じてサーバから送信されるレスポンスデータのキャッシュを保持する際に、レスポンスデータに含まれるセッションＩＤと同一のセッションＩＤを含むリクエストデータを、一連のプロセスとして紐付ける情報を生成する。そして、一のリクエストデータを処理するサーバがダウンしている場合には、紐付ける情報を参照して（Ｓ７４，Ｓ７８）、一のリクエストデータと一連のプロセスに属するリクエストデータはキューに貯めるとともに（Ｓ８０）、リクエストデータに対応するキャッシュをクライアントに送信し（Ｓ８４）、一のリクエストデータと一連のプロセスに属さないリクエストデータは当該リクエストデータを処理するサーバに対して送信する（Ｓ８４）。
【選択図】図７

Description

本件は、中継処理方法、中継処理装置及び中継処理プログラムに関する。

最近では、従来において紙ベースで行っていた様々な業務や作業が、Ｗｅｂシステム上での業務や作業に移行してきている（特許文献１、２参照）。このように、Ｗｅｂシステムを活用することで作業効率の向上が可能である。しかしながら、Ｗｅｂシステムを用いる場合、システムに障害などが発生することで、サーバが提供するサービスを利用できなくなる場合がある。このような場合には、システムが復帰するまで利用者は作業を行うことができなくなるため、緊急措置として紙ベースでの作業が強いられる可能性がある。

特開２００７−２５９０５９号公報特開２００７−９６９１０号公報

これに対し、紙ベースでの作業を行うことなく、システムを利用した業務や作業を継続して利用するための方法としては、プロキシサーバなどが保持する過去のキャッシュを業務や作業に利用する方法が考えられる。しかしながら、単純にキャッシュを利用するだけでは、システムダウン時において、あるクライアントからのリクエストをサーバが処理しなかったにもかかわらず、それ以降のリクエストをシステム復旧後のサーバが処理してしまうことがある。この場合、システムの一貫性に矛盾が生じる可能性がある。また、キャッシュを利用する場合には、プロキシサーバがキューを用意してリクエストを貯めておき、システムの復旧後にリクエストを一括してサーバに送信する。しかるに、この方法では、種類に関わらず、リクエストをキューに格納してしまうため、ダウンしているサービスが復帰しない限りは永遠に全てのリクエストがキューに貯まりつづけることになる。それゆえに処理の全体効率が低下してしまい、十分な効果を得られないおそれがある。

そこで本件は上記の課題に鑑みてなされたものであり、サーバダウン時における処理の一貫性を図るとともに、処理の効率化を図ることが可能な中継処理方法、中継処理装置及び中継処理プログラムを提供することを目的とする。

本明細書に記載の中継処理方法は、クライアントおよび複数のサーバとネットワークを介して接続されたコンピュータが、クライアントからのリクエストデータに応じてサーバから送信されるレスポンスデータのキャッシュを保持する際に、前記レスポンスデータにセッションＩＤが含まれているか否かを判定するセッション判定工程と、前記レスポンスデータに前記セッションＩＤが含まれていた場合に、当該セッションＩＤと同一のセッションＩＤを含むリクエストデータを、一連のプロセスとして紐付ける情報を生成する情報生成工程と、一のリクエストデータを処理する第１のサーバがダウンしている場合に、クライアントから受信したリクエストデータについて、前記情報生成工程で生成された情報を参照して、前記一のリクエストデータと一連のプロセスに属するリクエストデータであるか判断し、一連のプロセスに属するリクエストデータである場合には、当該リクエストデータをキューに貯めるとともに、前記リクエストデータに対応するキャッシュを前記クライアントに送信し、前記一のリクエストデータと一連のプロセスに属さないリクエストデータである場合には、当該リクエストデータを処理する第２のサーバに対してリクエストデータを送信する中継処理工程と、を実行する中継処理方法である。

本明細書に記載の中継処理装置は、クライアントからのリクエストデータに応じてサーバから送信されるレスポンスデータのキャッシュを保持するキャッシュ保持部と、前記キャッシュ保持部が前記レスポンスデータのキャッシュを保持する際に、前記レスポンスデータにセッションＩＤが含まれているか否かを判定するセッション判定部と、前記レスポンスデータに前記セッションＩＤが含まれていた場合に、当該セッションＩＤと同一のセッションＩＤを含むリクエストデータを、一連のプロセスとして紐付ける情報を生成する情報生成部と、一のリクエストデータを処理する第１のサーバがダウンしている場合に、クライアントから受信したリクエストデータについて、前記情報生成部で生成された情報を参照して、前記一のリクエストデータと一連のプロセスに属するリクエストデータであるか判断し、一連のプロセスに属するリクエストデータである場合には、当該リクエストデータをキューに貯めるとともに、前記リクエストデータに対応するキャッシュを前記クライアントに送信し、前記一のリクエストデータと一連のプロセスに属さないリクエストデータである場合には、当該リクエストデータを処理する第２のサーバに対してリクエストデータを送信する中継処理部と、を備える中継処理装置である。

本明細書に記載の中継処理プログラムは、クライアントおよび複数のサーバとネットワークを介して接続されたコンピュータに、クライアントからのリクエストデータに応じてサーバから送信されるレスポンスデータのキャッシュを保持する際に、前記レスポンスデータにセッションＩＤが含まれているか否かを判定するセッション判定工程、前記レスポンスデータに前記セッションＩＤが含まれていた場合に、当該セッションＩＤと同一のセッションＩＤを含むリクエストデータを、一連のプロセスとして紐付ける情報を生成する情報生成工程、及び一のリクエストデータを処理する第１のサーバがダウンしている場合に、クライアントから受信したリクエストデータについて、前記情報生成工程で生成された情報を参照して、前記一のリクエストデータと一連のプロセスに属するリクエストデータであるか判断し、一連のプロセスに属するリクエストデータである場合には、当該リクエストデータをキューに貯めるとともに、前記リクエストデータに対応するキャッシュを前記クライアントに送信し、前記一のリクエストデータと一連のプロセスに属さないリクエストデータである場合には、当該リクエストデータを処理する第２のサーバに対してリクエストデータを送信する中継処理工程、を実行させる中継処理プログラムである。

本明細書に記載の中継処理方法、中継処理装置及び中継処理プログラムは、サーバダウン時における処理の一貫性を図るとともに、処理の効率化を図ることができるという効果を奏する。

一実施形態に係るＷｅｂ業務システムの構成を概略的に示す図である。プロキシサーバのハードウェア構成図である。プロキシサーバの機能ブロック図である。図４（ａ）は、キュー情報テーブルを示す図であり、図４（ｂ）は、プロセス情報テーブルを示す図であり、図４（ｃ）は、セッション情報テーブルを示す図である。プロセス生成処理を示すフローチャートである。プロセス追加処理を示すフローチャートである。サーバダウン時のプロセス判定処理を示すフローチャートである。サーバダウン後の待機リクエスト確認処理を示すフローチャートである。図９（ａ）〜図９（ｃ）は、図５のプロセス生成処理を説明するための図（その１）である。図１０（ａ）〜図１０（ｃ）は、図５のプロセス生成処理を説明するための図（その２）である。図１１（ａ）〜図１１（ｃ）は、図６のプロセス追加処理を説明するための図（その１）である。図１２（ａ）〜図１２（ｃ）は、図６のプロセス追加処理を説明するための図（その２）である。図１３（ａ）、図１３（ｂ）は、図７のサーバダウン時のプロセス判定処理を説明するための図（その１）である。図１４（ａ）、図１４（ｂ）は、図７のサーバダウン時のプロセス判定処理を説明するための図（その２）である。図１５（ａ）、図１５（ｂ）は、図７のサーバダウン時のプロセス判定処理を説明するための図（その３）である。図１６（ａ）〜図１６（ｄ）は、図７のサーバダウン時のプロセス判定処理を説明するための図（その４）である。サービス確認部の処理を示すフローチャートである。

以下、中継処理装置としてのプロキシサーバを含むＷｅｂ業務システムの一実施形態について、図１〜図１７に基づいて詳細に説明する。図１には、一実施形態にかかるＷｅｂ業務システム１００が模式的に示されている。この図１に示すように、Ｗｅｂ業務システム１００は、クライアント端末（以下、単にクライアントと呼ぶ）１０と、コンピュータ及び中継処理装置としてのプロキシサーバ２０と、複数のサーバ３０とを備える。なお、クライアント１０、プロキシサーバ２０、サーバ３０は、実際には、ネットワーク（例えば、インターネットやＬＡＮ（Local Area Network））上に配置されている。

クライアント１０は、業務を行うユーザが操作する端末である。クライアント１０からいずれかのサーバ３０への要求（リクエスト）は、ＷｅｂブラウザなどのＨＴＴＰクライアントソフトを用いて行われる。プロキシサーバ２０は、中継サーバソフトを用いてＨＴＴＰ通信をモニタリングし、クライアント１０からのリクエストの情報（リクエストデータ）を、適切なサーバ３０に対して送信する。

図２には、プロキシサーバ２０のハードウェア構成が示されている。この図２に示すように、プロキシサーバ２０は、ＣＰＵ９０、ＲＯＭ９２、ＲＡＭ９４、記憶部（ここではＨＤＤ（Hard Disk Drive））９６、入出力部９７等を備えている。これらプロキシサーバ２０の構成各部は、バス９８に接続されている。プロキシサーバ２０では、ＲＯＭ９２あるいはＨＤＤ９６に格納されているプログラム（中継処理プログラム）をＣＰＵ９０が実行することにより、図３の各部の機能が実現されている。

図３には、プロキシサーバ２０の機能ブロック図が示されている。この図３に示すように、プロキシサーバ２０は、リクエスト受信部４０、待機リクエスト確認部４２、セッション有無判定部４４、リクエスト送信部４６、キュー追加部４８、サービス確認部５０、としての機能を有する。また、プロキシサーバ２０は、レスポンス受信部５２、プロセス判定部５４、セッション判定部としてのセッション生成判定部５６、キャッシュ管理部５８、レスポンス送信部６０、プロセス生成部６２、プロセス追加部６４、セッション監視部６６、としての機能を有する。更に、プロキシサーバ２０は、図２のＨＤＤ９６に、図３に示すキュー情報テーブル８０、リクエスト情報テーブル８２、キャッシュ情報テーブル８４、プロセス情報テーブル８６、セッション情報テーブル８８を格納しており、各テーブルのデータは、上記各部により更新されたり、利用されたりする。

リクエスト受信部４０は、クライアント１０から送信されるサーバ３０に対するリクエストデータを受信する。待機リクエスト確認部４２は、あるサーバ３０（サービス）がダウンしたときに、キュー情報テーブル８０に含まれている待機リクエストと、クライアント１０から送信されてきたリクエストが同一プロセスに属するかどうかを判定する。また、待機リクエスト確認部４２は、同一プロセスに属すると判定した場合に、そのリクエストをリクエスト送信部４６を介してサーバに送ることなく、キュー情報テーブル８０に格納する。

セッション有無判定部４４は、リクエストデータのヘッダにセッションＩＤがあるか否かを判定する。リクエスト送信部４６は、リクエストデータに応じた処理を行うのに適したサーバ３０に対して、リクエストデータを送信する。また、リクエスト送信部４６は、送信したリクエストデータを、リクエスト情報テーブル８２に格納する。キュー追加部４８は、リクエストのキュー（待機リクエスト）をキュー情報テーブル８０に追加する。サービス確認部５０は、サービス復帰（サーバがダウンした後の復帰）の有無を確認する。

レスポンス受信部５２は、リクエストに応じてサーバ３０において処理された結果（レスポンス）を、サーバ３０から受信する。プロセス判定部５４は、リクエストデータを、リクエスト情報テーブル８２から読み出し、当該リクエストデータと、プロセス情報テーブル８６等とを照らし合わせる。そして、プロセス判定部５４は、プロセス情報テーブル８６等を参照して、リクエストが正常動作時に登録しておいたプロセスの一部であるか否かを判定する。そして、プロセス判定部５４は、リクエストがプロセスの一部であった場合には、当該リクエストをキュー追加部４８を介してキュー情報テーブル８０に格納しておく。セッション生成判定部５６は、レスポンスデータにセッションＩＤ、すなわちセッション生成指示があったかどうかを判定する。具体的には、レスポンスデータのプロトコルとしては、ＨＴＴＰが用いられている。したがって、図９（ａ）に示すように、レスポンスデータにおいて、サーバ３０がSet-Cookieヘッダを発行しており、かつその名前がJSESSIONIDであった場合に、セッション生成判定部５６が、セッション生成指示があったと判定する。

キャッシュ管理部５８は、サーバ３０から受信したレスポンスデータをキャッシュ情報テーブル８４に格納する。また、キャッシュ管理部５８は、プロセス判定部５４においてキュー情報テーブル８０に格納したリクエストに対応するキャッシュを、レスポンス送信部６０を介して、クライアント１０に対して送信する。レスポンス送信部６０は、サーバ３０から受信したレスポンスデータや、キャッシュなどをクライアント１０に対して送信する。

プロセス生成部６２は、一連のリクエストのシーケンス（繋がり）をプロセス情報及びセッション情報として、プロセス情報テーブル８６及びセッション情報テーブル８８に記憶する。プロセス追加部６４は、一連のリクエストのシーケンスの継続要求をプロセス情報テーブル８６やセッション情報テーブル８８に反映させる。セッション監視部６６は、セッション情報テーブル８８に格納されている有効期限付きのセッション情報を、有効期限経過後に削除する。

キュー情報テーブル８０は、一例として図４（ａ）に示すように、待機リクエストの情報として、キューＩＤと、対応プロセスＩＤと、対応シーケンス番号と、ＨＴＴＰリクエストの項目を有する。なお、キュー情報テーブル８０の各項目の詳細については後述する。図３に戻り、リクエスト情報テーブル８２は、リクエスト情報を格納しておくテーブルである。キャッシュ情報テーブル８４は、キャッシュを格納するテーブルである。

プロセス情報テーブル８６は、一連のプロセスとして紐付ける情報を格納するテーブルであり、図４（ｂ）に示すように、プロセスＩＤ、シーケンス番号、ＨＴＴＰリクエストの項目を含んでいる。セッション情報テーブル８８は、図４（ｃ）に示すように、セッションＩＤ、プロセスＩＤ、シーケンス番号、有効期限の項目を含んでいる。なお、プロセス情報テーブル８６とセッション情報テーブル８８の各項目の詳細については後述する。

次に、プロキシサーバ２０における処理について、図５〜図８のフローチャートに沿って、その他図面を適宜参照しつつ詳細に説明する。図５〜図８の処理のうち、図５、図６の処理は、サーバ３０がダウンしていないときに行われる処理であり、図７、図８は、いずれかのサーバがダウンしたときに行われる処理である。

（プロセス生成処理）
まず、図５に基づいて、サーバ３０がダウンしていないときに行われるプロセス生成処理について説明する。図５の処理では、ステップＳ１０において、レスポンス受信部５２が、サーバ３０からのレスポンスを待機する。次いで、ステップＳ１２では、レスポンス受信部５２が、タイムアウトか否かを判断する。ここでの判断が肯定される場合とは、サーバ３０がダウンしている場合を意味する。このため、ステップＳ１２の判断が肯定された場合には、後述するプロセス判定処理に移行する。一方、ステップＳ１２の判断が否定された場合には、ステップＳ１４に移行する。

ステップＳ１４に移行した場合、レスポンス受信部５２が、サーバ３０からのレスポンスが有ったか否かを判断する。ここでの判断が否定された場合には、ステップＳ１２に戻る。一方、サーバ３０からのレスポンスがあり、ステップＳ１４の判断が肯定された場合には、ステップＳ１６に移行する。なお、ステップＳ１２、Ｓ１４が繰り返し行われている間は、タイムアウトになるまで、又はレスポンス受信部５２がレスポンスを受信するまで、待機している。

次いで、ステップＳ１４の判断が肯定されてステップＳ１６に移行すると、レスポンス受信部５２は、ＨＴＴＰレスポンスを受け取る。次いで、ステップＳ１８では、レスポンス受信部５２が、レスポンスコードが正常か否かを判断する。ここで、レスポンスコードが異常な場合とは、図１３（ａ）のレスポンスに示すように、レスポンスコードが例えば「503」である場合などである。レスポンスコード「503」は、サーバ３０に高負荷がかかっているなど、サーバ３０が適切にサービスを提供できないことを意味している。ステップＳ１８の判断が否定された場合には、後述するプロセス判定処理（図７）に移行する。一方、ステップＳ１８の判断が肯定された場合には、ステップＳ２０に移行する。

ステップＳ２０に移行すると、セッション生成判定部５６が、レスポンスヘッダからセッションＩＤを取得する。具体的には、セッション生成判定部５６は、図９（ａ）に示すようなレスポンスヘッダの中からセッションＩＤ、すなわち、セッション生成指示を読み取る。ここでは、セッション生成判定部５６は、セッションＩＤとして、「JSESSIONID＝」の右側の文字列「abcde」を読み取ることになる。

次いで、ステップＳ２２では、セッション生成判定部５６が、セッションＩＤがあったか否かを判断する。ここでの判断が否定された場合（セッションＩＤが無かった場合）には、ステップＳ３２に移行するが、判断が肯定された場合（セッションＩＤがあった場合）には、ステップＳ２４に移行する。

ステップＳ２４に移行した場合、プロセス生成部６２は、プロセス情報テーブル８６において、シーケンス番号が１かつＵＲＬ（図９（ａ）のリクエスト参照）が同一のプロセス（一連のプロセス）の有無を確認する。そして、ステップＳ２６では、シーケンス番号が１かつＵＲＬが同じプロセスがあったか否かを判断する。ここでの判断が肯定された場合には、ステップＳ３０に移行するが、ここでの判断が否定された場合には、ステップＳ２８に移行する。なお、ここでの判断が肯定される場合とは、既に今回のレスポンスと同じプロセスが、プロセス情報テーブル８６に登録されている場合を意味する。

ステップＳ２６の判断が否定されてステップＳ２８に移行した場合、すなわち、同じプロセスが登録されていない場合には、プロセス生成部６２が、ＨＴＴＰリクエストを、一意のプロセスＩＤ、シーケンス番号＝１とともにプロセス情報テーブル８６に格納する。この状態が、図９（ｂ）に示されている。図９（ｂ）では、一意のプロセスＩＤとして、「１」が用いられている。

上記のようにしてステップＳ２８の処理が終了すると、ステップＳ３０に移行する。なお、上述のようにステップＳ３０の処理は、ステップＳ２６が否定された場合にも行われるようになっている。すなわち、ステップＳ３０には、現在のリクエストと一連のプロセスに関する情報がプロセス情報テーブル８６に入っている状態にあるときに、移行するようになっている。

ステップＳ３０では、プロセス生成部６２が、プロセスＩＤと、セッションＩＤと、適当な有効期限をセッション情報テーブル８８に格納する。図９（ｃ）には、ステップＳ２８において図９（ｂ）のプロセス情報テーブル８６が作成された場合に、セッション情報テーブル８８に格納されるデータ（セッション情報）の例が示されている。ここで、有効期限としては、装置内で設定することが可能であり、例えば、１０秒後などとすることができる。

なお、ステップＳ２６においてプロセスが存在していたと判断される場合（判断が肯定された場合）の例が、図１０（ａ）〜図１０（ｄ）に示されている。これらの図のうち、図１０（ａ）は、本例におけるリクエスト及びレスポンスの一例を示している。また、本例におけるプロセス情報テーブル８６の例が、図１０（ｂ）に示されている。図１０（ａ）、図１０（ｂ）に示すように、プロセス情報テーブル８６には、シーケンス番号が１で、図１０（ａ）のリクエストのＵＲＬ「GET http://example.com/first.jsp」と同一のＨＴＴＰリクエストのプロセスが存在している。したがって、この場合には、ステップＳ２６の判断が肯定されて、ステップＳ３０に移行する。ステップＳ３０では、図１０（ｃ）に示すように、プロセス生成部６２が、プロセスＩＤ「１」と、レスポンスヘッダに基づくセッションＩＤ「fghij」と、適当な有効期限をセッション情報テーブル８８に格納することとなる。

図５の説明に戻り、次のステップＳ３２では、キャッシュ管理部５８が、レスポンスコードに基づいてキャッシュ情報テーブル８４にレスポンスのキャッシュを格納する。次いで、ステップＳ３４では、レスポンス送信部６０が、レスポンスデータ（レスポンス内容）をクライアント１０に対して送信し、図５の全処理を終了する。

なお、前述のように、ステップＳ２２の判断が否定された場合にも、ステップＳ３２、Ｓ３４の処理が行われる。すなわち、ステップＳ２２においてセッションＩＤが無かったと判断された場合には、ステップＳ２４〜Ｓ３０におけるプロセス情報テーブル８６やセッション情報テーブル８８にデータを格納する処理が省略され、キャッシュの格納及びレスポンス内容のクライアント１０への送信処理が行われることになる。

（プロセス追加処理）
次に、図６に基づいて、サーバ３０がダウンしていないときに行われるプロセス追加処理について説明する。なお、ここでは、プロセス情報テーブル８６が、図９（ｂ）の状態にあり、セッション情報テーブル８８が、図９（ｃ）の状態にあるものとして、以下説明する。

図６のプロセス追加処理においては、まず、ステップＳ４０において、セッション有無判定部４４が、リクエストヘッダからセッションＩＤを取得する。ここでは、セッション有無判定部４４が、例えば、図１１（ａ）に示すように、リクエストヘッダの「JSESSIONID=」の右側に記述されている文字列「abcde」をセッションＩＤとして取得したものとする。次いで、ステップＳ４２では、セッション有無判定部４４が、セッション情報テーブル８８からセッションＩＤに相当する情報の有無を確認する。なお、図９（ｃ）の場合には、セッション情報テーブル８８に、ステップＳ４０で取得したセッションＩＤ「abcde」が存在していることになる。

次いで、ステップＳ４４では、セッション有無判定部４４が、ステップＳ４２の結果、セッションＩＤに相当する情報が有ったか否かを判断する。ここでの判断が否定された場合、すなわちセッションＩＤに相当する情報がセッション情報テーブル８８に無かった場合には、ステップＳ５８に移行する。ステップＳ５８では、リクエスト送信部４６が、指定されたサーバ３０へリクエストを送信する。なお、この場合には、後述するステップＳ４６〜Ｓ５６の処理を実行しないので、プロセス情報テーブル８６やセッション情報テーブル８８の更新は一切行われない。

一方、ステップＳ４４の判断が肯定された場合、すなわち、セッションＩＤに相当する情報が、セッション情報テーブル８８に存在していた場合には、ステップＳ４６に移行する。ステップＳ４６では、プロセス追加部６４が、セッション情報テーブル８８内のセッション情報のプロセスＩＤ、及び最大のシーケンス番号（ここでは、図９（ｃ）のシーケンス番号の最大値１）に相当するプロセス情報をプロセス情報テーブル８６から取得する。

次いで、ステップＳ４８では、プロセス追加部６４が、取得したプロセス情報のリクエストＵＲＬ（ここでは、「GET http://example.com/first.jsp」）と、要求されたリクエストＵＲＬ（ここでは、図１１（ａ）から導き出される「GET http://example.com/second.jsp」）が同一かを確認する。

次いで、ステップＳ５０では、プロセス追加部６４が、ステップＳ４８の確認の結果、取得したプロセス情報のリクエストＵＲＬと要求されたリクエストＵＲＬが同一であったか否かを判断する。すなわち、今回のリクエストにおいて、プロセスの継続要求が出されているか否かを判断する。図１１（ａ）の場合、ＵＲＬが同一ではなく、判断が否定されるので、ステップＳ５２に移行する。一方、ここでの判断が肯定された場合には、ステップＳ５６に移行する

ステップＳ５２に移行した場合には、プロセス追加部６４が、プロセス情報テーブル８６内の該当する一連のプロセス情報（シーケンス番号１〜最大）を新規の一意プロセスＩＤとともにコピーして格納する。そして、ステップＳ５４では、プロセス追加部６４が、プロセス情報テーブル８６にプロセスＩＤ、最大シーケンス番号に１を加算した番号、リクエスト内容を追加する。具体的には、図１１（ｂ）に示すように、プロセスＩＤ「１」、シーケンス番号「２」、ＨＴＴＰリクエスト「GET http://example.com/second.jsp」が追加される。

次いで、ステップＳ５６では、プロセス追加部６４が、セッション情報テーブル８８に、セッションＩＤ、プロセスＩＤ、最大シーケンス番号に１を加算した番号、有効期限を追加する。具体的には、図１１（ｃ）に示すように、セッションＩＤ「abcde」、プロセスＩＤ「１」、シーケンス番号「２」、及び適当な有効期限が追加される。なお、前述のようにステップＳ５０の判断が肯定された場合にも、ステップＳ５６の処理が行われる。この場合には、ステップＳ５２、Ｓ５４の処理を行わないので、プロセス情報テーブル８６が更新されずに、セッション情報テーブル８８のみが更新されることになる。そして、ステップＳ５８では、リクエスト送信部４６が、指定されたサーバ３０へリクエストを送信する。

なお、プロセス情報テーブル８６及びセッション情報テーブル８８が、図１０（ｂ）、図１０（ｃ）のような場合にも、上記と同様の処理が行われる。すなわち、図１２（ａ）に示すようなリクエストがあった場合、セッション有無判定部４４は、セッションＩＤ「fghij」を取得するとともに（ステップＳ４０）、セッション情報テーブル８８（図１０（ｃ）参照）にセッションＩＤ「fghij」が存在していると判断する（ステップＳ４２、ステップＳ４４（肯定））。そして、プロセス追加部６４は、プロセス情報テーブル８６からプロセス情報を取得し（ステップＳ４６）、プロセス情報に含まれるリクエストＵＲＬ「GET http://example.com/first.jsp」と、図１２（ａ）のリクエストにおいて要求されたリクエストＵＲＬ「GET http://example.com/new.jsp」とが同一か否かを確認する（ステップＳ４８）。この確認により、同一でないことが確認されると（ステップＳ５０（否定））、プロセス追加部６４は、プロセス情報テーブル８６内の該当する一連のプロセス情報を新規の一意プロセスＩＤとともにコピーして格納する（ステップＳ５２、図１２（ｂ）のプロセスＩＤ「２」、シーケンス番号「１」参照）。更に、プロセス追加部６４は、プロセス情報テーブル８６に、プロセスＩＤ「２」、最大シーケンス番号に１を加算した番号（すなわち、「２」）、リクエスト内容「GET http://example.com/second.jsp」を追加するとともに（ステップＳ５４）、セッション情報テーブル８８に、セッションＩＤ、プロセスＩＤ、最大シーケンス番号に１を加算した番号、有効期限を追加する（図１２（ｃ）の最下段参照）。そして、リクエスト送信部４６が、指定されたサーバ３０へリクエストを送信する。

以上のような処理を経ることで、図１１（ｂ）、図１１（ｃ）や、図１２（ｂ）、図１２（ｃ）のように、各テーブルが更新（プロセスが追加）されるようになっている。

（サーバダウン時のプロセス判定処理）
次に、図５のステップＳ１２の判断が肯定された場合、又はステップＳ１８の判断が否定された場合、すなわち、サーバがダウン（サービスダウン）したときに実行されるプロセス判定処理について、図７に沿って説明する。なお、ここでは、説明の便宜上、プロセス情報テーブル８６及びセッション情報テーブル８８は、図１２（ｂ）、図１２（ｃ）の状態にあるものとして説明する。

図７のステップＳ７０では、プロセス判定部５４が、リクエスト送信時点において、セッション情報テーブル８８にセッション情報としてリクエストの情報が追加されていたかを確認する。次いで、ステップＳ７２では、プロセス判定部５４が、該当するリクエスト情報が有ったか否かを判断する。この場合において、例えば、図１３（ａ）のようなリクエスト（セッション開始後の先頭のリクエスト）があった場合には、リクエストにセッションＩＤが含まれていないので、ステップＳ７２の判断は否定される。なお、レスポンスとして図１３（ａ）のようなレスポンスがサーバ３０側から送信されてきた場合（レスポンスコード「503」の場合）には、サーバにエラーが発生していることを意味する。

ステップＳ７２の判断が否定されて、ステップＳ７４に移行すると、プロセス判定部５４が、プロセス情報テーブル８６からシーケンス番号が１かつＵＲＬが同一のプロセスの有無を確認する。次いで、ステップＳ７６では、プロセス判定部５４が、上記のようなプロセスが存在していたか否かを判断する。この場合、図１２（ｂ）に示すように、シーケンス番号が１、ＵＲＬが「GET http://example.com/first.jsp」であるプロセスが存在している。したがって、ここでの判断は肯定され、ステップＳ８０に移行する。

ステップＳ８０に移行すると、キュー追加部４８が、新規キューＩＤ（例えば、「１」）を生成して、リクエストのプロセスＩＤ、シーケンス番号を、ＨＴＴＰリクエストとともにキュー情報テーブル８０へ格納する。このときのキュー情報テーブル８０の状態が、図１３（ｂ）に示されている。なお、ここでの処理では、ステップＳ７６の判断が肯定された場合、すなわち、リクエストが一連のプロセスの先頭であった場合にのみ、ステップＳ８０においてキューが追加されることになる。

次いで、ステップＳ８２では、キャッシュ管理部５８が、ＨＴＴＰリクエストに該当するキャッシュをキャッシュ情報テーブル８４内において検索する。次いで、ステップＳ８４では、レスポンス送信部６０が、検索したキャッシュをレスポンス内容として、クライアント１０へ送信する。このようにすることで、クライアント１０では、キャッシュ情報テーブル８４に格納されていた、正常にサーバ３０が動作していた際のレスポンスキャッシュを利用することができる。これにより、クライアント１０の利用者は、サーバがダウンしている場合にも、当該キャッシュを用いて、処理を継続的に行うことが可能である。

一方、例えば、図１４（ａ）のようなリクエスト（セッション開始後、２番目以降のリクエスト）があった場合には、ステップＳ７０に移行する。このステップＳ７０では、セッションＩＤ「abcde」のセッション情報が、セッション情報テーブル８８に格納されているか否かを確認する。この場合、セッションＩＤ「abcde」は、図１２（ｃ）に示すように、セッション情報テーブル８８に存在しているので、ステップＳ７２の判断は肯定され、ステップＳ７８に移行する。そして、ステップＳ７８では、プロセス判定部５４が、セッション情報に対応するプロセスＩＤとシーケンス番号を取得する。ここでは、図１２（ｃ）のセッション情報テーブル８８から、リクエスト情報のアドレス「GET http://example.com/second.jsp」に対応する、プロセスＩＤ「１」とシーケンス番号「２」が取得される。そして、ステップＳ７８の処理が終了した後は、ステップＳ８０に移行する。

ステップＳ８０では、ステップＳ７８で取得した、プロセスＩＤとシーケンス番号について、新規キューＩＤ（ここでは、「２」）を生成して、キュー情報テーブル８０に追加する（図１４（ｂ）参照）。

なお、図１５（ａ）、図１５（ｂ）に示すように、セッション情報テーブル８８に格納されているにもかかわらず、プロセス情報テーブル８６に格納されていない情報（図１５（ｂ）のセッションＩＤ「fghij」）がある場合がある。このような場合に、図１６（ａ）に示すようなリクエスト（セッション開始後、２番目以降のリクエストであり、セッションＩＤが「fghij」であるリクエスト）及びレスポンスがあったとする。かかる場合には、図５の処理を経て、セッション情報テーブル８８には、図１６（ｃ）に示す最下段の情報が追加されることになるが（図５のステップＳ３０）、プロセス情報テーブル８６には、図１６（ｂ）と図１５（ａ）とを比較すると分かるように、情報は追加されない。このような場合でも、本実施形態では、図７のステップＳ７８において、セッション情報テーブル８８（図１５（ｂ））を参照するようにしている。したがって、キュー情報テーブル８０には、図１６（ｄ）に示すような適切な情報を格納することが可能となっている（図７のステップＳ８０）。

（サーバダウン後（サーバダウン中）の待機リクエスト確認処理）
次に、図８に基づいて、サーバダウン後（サーバダウン中）の待機リクエスト確認処理について説明する。

図８の処理は、リクエスト受信部４０が、クライアント１０からリクエストを受信した時点から開始される。まず、図８のステップＳ９０では、待機リクエスト確認部４２が、キュー情報テーブル８０にキュー（待機リクエスト）があるかを確認する。次いで、ステップＳ９２では、待機リクエスト確認部４２が、キューが有ったか否かを判断する。ここでの判断が否定された場合には、図６のフローチャート（セッション有無判定部４４の処理）へ移行する。一方、ここでの判断が肯定された場合には、ステップＳ９４に移行する。

ステップＳ９４に移行すると、待機リクエスト確認部４２が、キュー情報テーブル８０に格納されている情報（待機リクエスト）のプロセスＩＤ、シーケンス番号に１を加算した番号に一致する情報を、プロセス情報テーブル８６から取得する。

次いで、ステップＳ９６では、待機リクエスト確認部４２が、取得したプロセスのＨＴＴＰリクエストと送信予定のＨＴＴＰリクエストが同一か否かを判断する。ここでの判断が否定された場合には、図６のセッション有無判定部４４の処理へ移行する。一方、ここでの判断が肯定された場合には、ステップＳ９８に移行する。

ステップＳ９８に移行した場合、キュー追加部４８が、先に取得した待機プロセス情報と同一のキューＩＤを用いて、送信予定のＨＴＴＰリクエストをキュー情報テーブル８０に格納する。

次いで、ステップＳ１００では、キュー追加部４８が、キューに情報テーブル８０に格納した旨のメッセージを作成して、レスポンス送信部６０へ当該メッセージの送信依頼を出す。

図１７には、サービス確認部５０の処理がフローチャートにて示されている。この図１７に示すように、サービス確認部５０は、ステップＳ１０２において、キュー情報テーブル８０の先頭のリクエストに対応するサーバ（サービス）が復活したか否かを確認する。この確認においては、サービス確認部５０は、例えば、先頭のリクエストを定期的にダウンしているサーバ３０に送信する。そして、当該リクエストに対する正常なレスポンスが返ってきた場合に、サービス確認部５０は、ダウンしていたサーバ（サービス）が復活したと、判定するこの場合、ステップＳ１０２の判断が肯定されることになる。そして、ステップＳ１０４に移行すると、サービス確認部５０は、キュー情報テーブル８０に残っている同一プロセスＩＤのリクエストをサーバに対して一括送信する。これにより、サーバがダウンから復帰した際に、当該復帰したサーバで行うことができる処理を即座に実行することが可能となる。

なお、これまでの説明から分かるように、リクエスト送信部４６、キュー追加部４８及びキャッシュ管理部５８が、中継処理部として機能している。また、キャッシュ管理部５８及びキャッシュ情報テーブル８４が、キャッシュ保持部として機能している。また、プロセス生成部６２及びプロセス追加部８４が、情報生成部として機能している。

以上、詳細に説明したように、本実施形態によると、プロキシサーバ２０では、クライアント１０からのリクエストデータに応じてサーバ３０から送信されるレスポンスデータのキャッシュを保持する際に、前記レスポンスデータにセッションＩＤが含まれているか否かを判定し（ステップＳ２２）、レスポンスデータに含まれるセッションＩＤと同一のセッションＩＤを含むリクエストデータを、一連のプロセスとして紐付ける情報（プロセス情報テーブル８６，セッション情報テーブル８８）を生成する（ステップＳ５４、Ｓ５６）そして、一のリクエストデータを処理するサーバ（第１のサーバ）がダウンしている場合に、テーブル８６，８８を参照して、一のリクエストデータと一連のプロセスに属するリクエストデータはキューに格納し（ステップＳ８０）、一連のプロセスに属さないリクエストデータは当該リクエストデータを処理するサーバ（第２のサーバ）に対して送信する（ステップＳ８２）。これにより、本実施形態では、処理するサーバがダウンしているリクエストのみを、キューに格納するので、処理の全体効率を向上することが可能である。

また、本実施形態では、キューにリクエストデータを貯めたときに、当該リクエストに対応するレスポンスデータのキャッシュをクライアントに送信する。したがって、サーバがダウンしているときにも、キャッシュを用いて処理を行うことができる。この場合、クライアントでは、一連のプロセスに属するリクエスト（ダウンしたサーバに係るリクエスト）については、全て、キャッシュを用いた処理とすることができるので、処理の一貫性を維持することができる。また本実施形態では、サーバ（第１のサーバ）がダウンから復帰した場合に、キューに貯めておいたリクエストデータを、復帰したサーバ（第１のサーバ）に対して送信する（ステップＳ１０４）。したがって、サーバ復帰後において、一連のプロセスに属するリクエストを復帰後のサーバを用いて処理することが可能である。

なお、上記プロキシサーバ２０の処理機能は、コンピュータによって実現することができる。その場合、処理装置が有すべき機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。

プログラムを流通させる場合には、例えば、そのプログラムが記録されたＤＶＤ（Digital Versatile Disc）、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）などの可搬型記録媒体の形態で販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。

プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送されるごとに、逐次、受け取ったプログラムに従った処理を実行することもできる。

上述した実施形態は本発明の好適な実施の例である。但し、これに限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変形実施可能である。

１０クライアント
２０プロキシサーバ（コンピュータ、中継処理装置）
３０サーバ
４６リクエスト送信部（中継処理部の一部）
４８キュー追加部（中継処理部の一部）
５６セッション有無判定部（セッション判定部）
５８キャッシュ管理部（キャッシュ保持部の一部、中継処理部の一部）
６２プロセス生成部（情報生成部の一部）
６４プロセス追加部（情報生成部の一部）
８４キャッシュ情報テーブル（キャッシュ保持部の一部）

Claims

クライアントおよび複数のサーバとネットワークを介して接続されたコンピュータが、
クライアントからのリクエストデータに応じてサーバから送信されるレスポンスデータのキャッシュを保持する際に、前記レスポンスデータにセッションＩＤが含まれているか否かを判定するセッション判定工程と、
前記レスポンスデータに前記セッションＩＤが含まれていた場合に、当該セッションＩＤと同一のセッションＩＤを含むリクエストデータを、一連のプロセスとして紐付ける情報を生成する情報生成工程と、
一のリクエストデータを処理する第１のサーバがダウンしている場合に、クライアントから受信したリクエストデータについて、前記情報生成工程で生成された情報を参照して、前記一のリクエストデータと一連のプロセスに属するリクエストデータであるか判断し、一連のプロセスに属するリクエストデータである場合には、当該リクエストデータをキューに貯めるとともに、前記リクエストデータに対応するキャッシュを前記クライアントに送信し、前記一のリクエストデータと一連のプロセスに属さないリクエストデータである場合には、当該リクエストデータを処理する第２のサーバに対してリクエストデータを送信する中継処理工程と、を実行する中継処理方法。
前記第１のサーバがダウンから復帰した場合に、前記キューに貯めておいたリクエストデータを、当該第１のサーバに対して送信する送信工程を、前記コンピュータが更に実行することを特徴とする請求項１に記載の中継処理方法。
クライアントからのリクエストデータに応じてサーバから送信されるレスポンスデータのキャッシュを保持するキャッシュ保持部と、
前記キャッシュ保持部が前記レスポンスデータのキャッシュを保持する際に、前記レスポンスデータにセッションＩＤが含まれているか否かを判定するセッション判定部と、
前記レスポンスデータに前記セッションＩＤが含まれていた場合に、当該セッションＩＤと同一のセッションＩＤを含むリクエストデータを、一連のプロセスとして紐付ける情報を生成する情報生成部と、
一のリクエストデータを処理する第１のサーバがダウンしている場合に、クライアントから受信したリクエストデータについて、前記情報生成部で生成された情報を参照して、前記一のリクエストデータと一連のプロセスに属するリクエストデータであるか判断し、一連のプロセスに属するリクエストデータである場合には、当該リクエストデータをキューに貯めるとともに、前記リクエストデータに対応するキャッシュを前記クライアントに送信し、前記一のリクエストデータと一連のプロセスに属さないリクエストデータである場合には、当該リクエストデータを処理する第２のサーバに対してリクエストデータを送信する中継処理部と、を備える中継処理装置。
クライアントおよび複数のサーバとネットワークを介して接続されたコンピュータに、
クライアントからのリクエストデータに応じてサーバから送信されるレスポンスデータのキャッシュを保持する際に、前記レスポンスデータにセッションＩＤが含まれているか否かを判定するセッション判定工程、
前記レスポンスデータに前記セッションＩＤが含まれていた場合に、当該セッションＩＤと同一のセッションＩＤを含むリクエストデータを、一連のプロセスとして紐付ける情報を生成する情報生成工程、及び
一のリクエストデータを処理する第１のサーバがダウンしている場合に、クライアントから受信したリクエストデータについて、前記情報生成工程で生成された情報を参照して、前記一のリクエストデータと一連のプロセスに属するリクエストデータであるか判断し、一連のプロセスに属するリクエストデータである場合には、当該リクエストデータをキューに貯めるとともに、前記リクエストデータに対応するキャッシュを前記クライアントに送信し、前記一のリクエストデータと一連のプロセスに属さないリクエストデータである場合には、当該リクエストデータを処理する第２のサーバに対してリクエストデータを送信する中継処理工程、を実行させる中継処理プログラム。