(57)【要約】【課題】要求元にエラーを返さずに処理を継続するトランザクション処理方法、およびロールバックや再処理をプログラマブルにして柔軟性を持たせること。【解決手段】要求元端末からの第１サーバに対するリクエストを代理するリクエスト代理装置（１２）とリクエスト代理装置から端末要求情報を受信し記憶する要求情報管理装置（１３）とバックエンドサーバまたは他の外部デバイスへの第１サーバからの処理要求を代理し接続情報を管理する接続代理装置（１６）とで構成され、リクエスト代理装置は、サーバに障害を検知し、要求情報管理装置から端末要求情報を読出し第２サーバへ送信する。第２サーバは、端末要求情報を用いて要求元端末からのリクエストを構成するトランザクションの処理を継続し、バックエンドサーバまたは外部デバイスへの処理要求を接続代理装置へ送信する際に接続情報を用いてトランザクションの処理結果をリクエスト代理装置へ送信する。【選択図】図１
2008027189.tif 000002
【特許請求の範囲】
【請求項１】
要求元端末からのリクエストを処理する第１サーバに障害が発生した場合に、一または複数の第２サーバが前記第１サーバの処理を引き継ぐシステムであって、
前記要求元端末からの前記リクエストである端末要求情報を受信し、前記第１サーバに対して該リクエストを代理するリクエスト代理装置と、
前記リクエスト代理装置から前記端末要求情報を受信し、記憶する要求情報管理装置と、
前記第１サーバから外部処理装置への処理を中継し、前記第１サーバと前記外部処理装置との接続情報を管理する接続代理装置と、
を備え、
前記リクエスト代理装置は、前記第１サーバに障害が発生したことを検知したことに応じて、前記要求情報管理装置から前記端末要求情報を読出して前記第２サーバへ送信し、
前記第２サーバは、前記端末要求情報を用いて前記リクエストに対する処理を継続し、前記外部処理装置への処理を前記接続情報を用いて前記接続代理装置に送信し、前記リクエストの処理結果を前記リクエスト代理装置へ送信する、
ことを特徴とするシステム。
【請求項２】
前記要求情報管理装置は、前記リクエストに複数のトランザクションが含まれる場合に、トランザクションの単位で処理が完了した毎に該トランザクションの完了状況および復帰情報を前記第１サーバから受信する、請求項１に記載のシステム。
【請求項３】
前記第２サーバは、前記第１サーバの処理を引き継ぐ際に、処理途中のトランザクションのロールバックを行い、残りのトランザクションを完了する毎にその処理結果を前記リクエスト代理装置に送信し、
前記リクエスト代理装置は、前記リクエストに含まれるすべてのトランザクションが完了した際に、前記要求情報管理装置が記憶している前記端末要求情報を元に前記要求元端末に前記リクエストの処理結果を送信する、請求項２に記載のシステム。
【請求項４】
前記端末要求情報は、クッキーＩＤ、ＨＴＴＰリクエストに含まれるデータ、前記トランザクションの完了情報、ＨＴＴＰヘッダ情報、セションＩＤ、および前記トランザクションの復帰情報のうち少なくとも一つを含む、請求項２に記載のシステム。
【請求項５】
前記要求情報管理装置は、前記リクエストに対する処理が完了したことに応じて前記復帰情報を削除する、請求項４に記載のシステム。
【請求項６】
前記リクエスト代理装置、要求情報管理装置、および前記接続代理装置は、それぞれ二重化構成または冗長化構成をとることを含む、請求項１に記載のシステム。
【請求項７】
要求元端末からのリクエストを処理する第１サーバに障害が発生した場合に、一または複数の第２サーバが前記第１サーバの処理を引き継ぐ方法であって、
前記要求元端末と前記第１または第２サーバとの間を中継する一または複数の中継装置が、
前記要求元端末からの前記第１サーバへの前記リクエストを代理するステップと、
前記要求元端末からの前記リクエストに関する端末要求情報を受信し記憶するステップと、
前記第１サーバに対する前記リクエストを送信するステップと、
前記第１サーバから外部処理装置への処理要求が発生したことに応じて、前記第１サーバと前記外部処理装置との接続情報を管理し、該処理要求を代理するステップと、
前記第１サーバに障害が発生したことを検知するステップと、
前記障害を検知したことに応じて、前記端末要求情報を読出し、前記第２サーバへ送信するステップと、
前記第２サーバに、前記端末要求情報を用いて前記要求元端末からのリクエストに対する処理を継続させるステップと、
を含むことを特徴とする方法。
【請求項８】
要求元端末からのリクエストを処理する第１サーバに障害が発生した場合に、一または複数の第２サーバが前記第１サーバの処理を継続させるコンピュータ・プログラムであって、
前記要求元端末と前記第１または第２サーバとの間を中継する一または複数の中継装置に、
前記要求元端末からの前記第１サーバへの前記リクエストを代理するステップと、
前記要求元端末からの前記リクエストに関する端末要求情報を受信し記憶するステップと、
前記第１サーバに対する前記リクエストを送信するステップと、
前記第１サーバから外部処理装置への処理要求が発生したことに応じて、前記第１サーバと前記外部処理装置との接続情報を管理し、該処理要求を代理するステップと、
前記第１サーバに障害が発生したことを検知するステップと、
前記障害を検知したことに応じて、前記端末要求情報を読出し、前記第２サーバへ送信するステップと、
前記第２サーバに、前記端末要求情報を用いて前記要求元端末からのリクエストに対する処理を継続させるステップと、
を実行させる、コンピュータ・プログラム。
【請求項９】
要求元端末からのリクエストを処理する第１サーバの負荷に応じて一または複数の第２サーバに前記第１サーバの処理を分散させるシステムであって、
前記要求元端末からの前記リクエストである端末要求情報を受信し、前記第１サーバに対する該リクエストを代理し、前記第２サーバに処理の負荷を分散させるリクエスト代理装置と、
前記リクエスト代理装置から前記端末要求情報を受信し、記憶する要求情報管理装置と、
前記第１サーバと接続され外部処理装置への前記第１サーバからの処理要求を代理し、前記第１サーバと前記外部処理装置との接続情報を管理する接続代理装置と、
前記複数のサーバのトランザクション負荷を監視するトランザクションモニタ装置と、を備え、
前記トランザクションモニタ装置は、前記第１サーバに所定の過負荷が発生したことを検知し、
前記リクエスト代理装置は、前記過負荷の検知を受信したことに応じて、前記要求情報管理装置が記憶する前記端末要求情報を読出して前記第２サーバへ送信し、
前記第２サーバは、前記端末要求情報を用いて前記要求元端末からのリクエストに対する処理を継続し、前記外部処理装置への処理要求を前記接続代理装置へ送信する際に前記接続情報を用いて前記リクエストの処理結果を前記リクエスト代理装置へ送信する、
ことを特徴とするシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、トランザクションの引継ぎシステムに関する。更に詳しくは、複数ノード環境における障害時などの仕掛途中のトランザクションを自動継続するシステムおよびその方法に等に関する。
【背景技術】
【０００２】
近年、ネットワーク環境におけるクライアント・サーバシステムにおいて膨大なトランザクションを処理する信頼性の高いサーバの役割がますます重要になっている。このような環境におけるネットワークやサーバの障害は、業務アプリケーションによっては時として重大な社会問題をも引き起こす。このためサーバの障害からできるだけスムーズに復旧させるための様々な手法が考えられている。
【０００３】
例えば、特許文献１には、異なる装置で実行される互いに関連する二つの処理に関して、共に１回ずつの実行を保証したシステム、サーバ装置、クライアント装置、連携処理方法等が開示されている。この発明において、クライアント装置では、通信エラーを検出したら、サーバ装置に対して前回と同じ処理要求を再送し、サーバ装置では、完了した第１の処理と同じ識別情報の処理要求を再度受け取ったときは、第１の処理を実行せずにクライアント装置に対して第１の処理の完了通知を送信するようにしている。そのため、クライアント装置では、ネットワークの障害等により完了通知を受け取れなかった場合でも、処理要求を再送することで、第１の処理を重複させることなく完了通知を受け取り、第２の処理を実行することができる。この結果、第１の処理と第２の処理とが１回ずつ実行されることが保証されることが記載されている。
【０００４】
また別の例として、特許文献２には、トランザクションの内部キューを持つ現用系コンピュータが障害状態になった場合に、現用系に対するネットワーク・トランザクション・リクエストの処理の入出力パケットを監視（スニフィング）することによって待機系コンピュータへと透過的に切り替えるシステムおよび手段が開示されている。
【特許文献１】特開２００３−１６０４１号公報
【特許文献２】特開２００４−３２２２４号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
このようなシステムにおいては、サーバの障害発生から復旧時に仕掛中のトランザクション処理の再開が要求元（一般的にはクライアント装置）により気付かれることなく実行され（要求元に対しての透過性）、かつ要求元に対して重複した処理が発生しないことが必要である。
【０００６】
しかしながら、特許文献１に記載の方法では、クライアント装置でエラーを検出し、前回と同じ処理要求を再送しなければならず、要求元に対して必ずしも透過性を実現するものではない。また、特許文献２に記載の方法では、サーバの内部キューから取り出されたトランザクションがサーバプロセス上でユーザロジックによって処理されている途中で障害が発生したものに関しては処理をロールバック（取り消し）し、最初から再処理することになる。しかし、単純にロールバックさせて最初からやり直すだけで再処理できる場合以外には適用できない。
【０００７】
従って、本発明は上記課題を解決し、要求元にエラーを返さずに仕掛中の処理を継続するトランザクション処理方法を提供し、更に、ロールバックや再処理をプログラマブルにして、柔軟性のあるシステムおよびその方法等を提供することを目的とする。
【課題を解決するための手段】
【０００８】
本発明では以下の解決手段を備えたシステム、方法、およびプログラムを提供する。
【０００９】
本発明の第一の形態では、
要求元端末からのリクエストを処理する第１サーバに障害が発生した場合に、一または複数の第２サーバが前記第１サーバの処理を引き継ぐシステムであって、前記要求元端末からの前記リクエストである端末要求情報を受信し、前記第１サーバに対して該リクエストを代理するリクエスト代理装置と、前記リクエスト代理装置から前記端末要求情報を受信し、記憶する要求情報管理装置と、前記第１サーバから外部処理装置への処理を中継し、前記第１サーバと前記外部処理装置との接続情報を管理する接続代理装置と、
を備える。
【００１０】
このシステムでは、前記リクエスト代理装置は、前記第１サーバに障害が発生したことを検知し、前記要求情報管理装置から前記端末要求情報を読出し、前記第２サーバへ送信し、前記第２サーバは、前記端末要求情報を用いて前記要求元端末からのリクエストに対する処理を継続し、前記外部処理装置への処理要求を前記接続代理装置へ送信する際に前記接続情報を用いて前記リクエストの処理結果を前記リクエスト代理装置へ送信する、ことを特徴とする。
【００１１】
このような構成によれば、要求元の端末からのサーバに対するリクエストをリクエスト代理装置がプロキシとして代理中継し、この時、そのリクエストに関する要求元端末の情報（端末要求情報）を要求情報管理装置に記憶させておく。また、サーバが外部の接続機器（例えば、バックエンドのデータベースサーバやサーバ以外の外部デバイスなど）に処理を依頼する場合、その接続情報を管理する接続代理装置にサーバと外部処理装置の間を中継させる。
【００１２】
すなわち、リクエスト代理装置は、リクエストの代理中継とサーバの障害検知を主な役目とする。また、要求情報管理装置は、そのリクエストに関する様々な復旧に必要な情報を逐次サーバから得て記憶しておき、必要なときにリクエスト代理装置に送信する。更に、接続代理装置は、外部処理装置の接続情報（コネクション情報とも呼ぶ）を管理する。このようにすることで、リクエストを処理・継続するサーバを挟み込む形でリクエスト代理装置、要求情報管理装置と接続代理装置が要求元の情報および外部処理装置の状態を管理し、サーバの障害、復旧時の処理を効率よく分担して行うことができる。
【００１３】
更に、上記の発明の追加形態として、要求元のリクエストが複数のトランザクションで構成されている場合、トランザクション処理が完了した場合に、その完了状況とそのトランザクションを復帰するのに必要な復帰情報をサーバから逐次要求情報管理装置に送信し、要求情報管理装置にトランザクションとリクエストの同期管理を行なわせることができる。
【００１４】
本発明の別の形態では、
要求元端末からのリクエストを処理する第１サーバに障害が発生した場合に、一または複数の第２サーバが前記第１サーバの処理を引き継ぐ方法であって、前記要求元端末と前記第１または第２サーバとの間を中継する一または複数の中継装置が、前記要求元端末からの前記第１サーバへの前記リクエストを代理するステップと、前記要求元端末からの前記リクエストに関する端末要求情報を受信し、記憶するステップと、前記第１サーバに対する前記リクエストを送信するステップと、前記第１サーバから外部処理装置への処理要求が発生したことに応じて、前記第１サーバと前記外部処理装置との接続情報を管理し、該処理要求を代理するステップと、前記第１サーバに障害が発生したことを検知するステップと、前記障害を検知したことに応じて、前記端末要求情報を読出し、前記第２サーバへ送信するステップと、前記第２サーバに、前記端末要求情報を用いて前記要求元端末からのリクエストに対する処理を継続させるステップと、を含む方法を提供する。
【００１５】
このような構成によれば、ハードウェア構成をより柔軟にし、１または複数の中継装置において第一の発明の形態と同様な作用効果を奏する方法を提供することができる。
【００１６】
本発明の更に別の形態では、
要求元端末からのリクエストを処理する複数のサーバを含むサーバシステムにおいて、該複数のサーバの一つである第１サーバに障害が発生した場合に、一または複数の第２サーバが前記第１サーバの処理を継続させるコンピュータ・プログラムであって、前記要求元端末からの前記第１サーバへの前記リクエストを代理する１または複数の中継装置に、前記要求元端末からの該リクエストに関する端末要求情報を受信し、記憶するステップと、前記第１サーバに対する前記リクエストを送信するステップと、前記第１サーバから外部処理装置への処理要求が発生したことに応じて、前記第１サーバと前記外部処理装置との接続情報を管理し、該処理要求を代理するステップと、前記第１サーバに障害が発生したことを検知するステップと、前記障害を検知した際に、前記端末要求情報を読出し、前記第２サーバへ送信するステップと、前記第２サーバに、前記端末要求情報を用いて前記要求元端末からのリクエストに対する処理を継続させるステップと、を実行させる、ことを特徴とするコンピュータ・プログラムを提供する。
【００１７】
このような構成によれば、上記のシステムまたは方法で示された方法を一または複数の中継装置に機能させるコンピュータ・プログラムを提供できる。
【００１８】
また、本発明の応用形態として、
ネットワークに接続された要求元端末からのリクエストを処理する複数のサーバを含み、該複数のサーバの一つである第１サーバの負荷に応じて第２サーバに前記第１サーバの処理を分散させるシステムであって、前記要求元端末からの前記リクエストに関する端末要求情報を受信し、前記第１サーバに対する前記リクエストを代理し、前記第２サーバに処理の負荷を分散させるリクエスト代理装置と、前記リクエスト代理装置から前記端末要求情報を受信し、記憶する要求情報管理装置と、前記第１サーバと接続され外部処理装置への前記第１サーバからの処理要求を代理し、前記第１サーバと前記外部処理装置との接続情報を管理する接続代理装置と、前記複数のサーバのトランザクション負荷を監視するトランザクションモニタ装置とを備える。
【００１９】
このシステムでは、前記トランザクションモニタ装置は、前記第１サーバに所定の過負荷が発生したことを検知し、前記リクエスト代理装置は、前記過負荷の検知を受信したことに応じて、前記要求情報管理装置が記憶する前記端末要求情報を読出し前記第２サーバへ送信し、前記第２サーバは、前記端末要求情報を用いて前記要求元端末からのリクエストに対する処理を継続し、前記外部処理装置への処理要求を前記接続代理装置へ送信する際に前記接続情報を用いて前記リクエストの処理結果を前記リクエスト代理装置へ送信する、ことを特徴とする。
【００２０】
すなわち、この形態は単にサーバの障害復帰システムではなく、サーバの負荷（トランザクションの処理量）をトランザクションモニタ装置が監視することで過負荷となっているサーバを検知し、それをリクエスト代理装置に伝えることで過負荷となったサーバの処理を他の比較的負荷の少ないサーバへ分散させることができる。リクエスト代理装置や要求情報管理装置、接続代理装置にとっては、サーバの障害発生時と同様な処理を実行する。このシステムは、オートノミックなどの自立調整型のシステムと組み合わせてサーバの数（ノード数）をオン・デマンドに調整することができ柔軟なサーバシステムとすることも可能である。
【発明の効果】
【００２１】
本発明によれば、仕掛中のリクエストであっても処理を継続し正常に完了できるシステム等が提供できる。ここでは、要求元にエラーの発生を気付かせることなく正常処理が完了できるため、システムが提供するサービスの信用、信頼性を高く保つことができ、平常時のオーバヘッドが比較的低く、レスポンスへの影響を少なくすることが可能である。
【００２２】
更に、本発明の応用として、サーバの処理能力のキャパシティを自律調整するためにノード数（サーバ数）を増減させるオートノミック技術と組み合わせることで、容易に仕掛中の処理をすぐさま他のノードで引継ぎ、即時にノードを減少させることも可能である。
【発明を実施するための最良の形態】
【００２３】
以下、本発明の実施形態について図を参照しながら説明する。
【００２４】
図１は、本発明の第１の実施形態におけるサーバシステム１０の概略を示す図である。このサーバシステム１０では、要求元端末１１とその要求（リクエスト）を処理する第１サーバ１４（現行系サーバ）と障害発生時のバックアップ用サーバである第２サーバ１５（待機系サーバ）とを含む。この図では要求元端末１１は一つしか示していないが、当然複数の端末を含んでもよい。また、要求元端末１１からのリクエストを受けるサーバは第１サーバ１４と第２サーバ１５の二つを示しているが、点線で示すように第２サーバ１５は複数であってもよい。
【００２５】
本実施形態においては、要求元端末１１と第１サーバ１４、第２サーバ１５の間にリクエスト代理装置１２と要求情報管理装置１３を配置する。リクエスト代理装置１２と要求情報管理装置１３の機能については後述する。また、第１サーバ１４、第２サーバ１５と外部処理装置１７（バックエンドサーバ７もしくは外部デバイス８など）の間に接続代理装置１６を配置する。バックエンドサーバ７は、第１サーバ１４または第２サーバ１５の依頼を受け処理に必要なデータベースを格納したサーバであり、外部デバイス８は、バックエンドサーバ７のようなサーバでなく要求元から処理が必要な外部の任意の装置を指す。本サーバシステム１０の動作は図３以降で詳しく説明する。
【００２６】
なお、図１のシステムでは、リクエスト代理装置１２、要求情報管理装置１３、および接続代理装置１６は、それぞれ単一の装置としての構成を示してあるが、それぞれの装置の障害に備えて、更に各装置が多重構成（二重化構成、または冗長化構成）をとってもよい。
【００２７】
図２は、本発明の第２の実施形態におけるサーバシステム３０の概略を示す図である。このサーバシステム３０では、図１のリクエスト代理装置１２、要求情報管理装置１３、および接続代理装置１６を単一の中継装置１８の内部にまとめて構成したものである。リクエスト代理部１９，要求情報管理部２０、接続代理部２１が、図１の各装置にそれぞれ対応する。この構成では、必要なハードウェア構成は、図１のシステムと比べ小さくなるが、中継装置１８の障害対策が必要となる可能性は高まる。一方、図１のような分散システム構成のほうがハードウェア構成は多くなるが、その分、中継装置１８自体の障害リスクは小さくなる。しかしながら、以降の説明からわかるように、いずれの構成においてもこれらの中継装置（代理部）の処理は単純であり、オーバヘッドは比較的小さいものである。
【００２８】
図３は、本発明の第３の実施形態におけるサーバシステム４０の概略を示す図である。このシステムでは、サーバの処理能力のキャパシティを自律調整するためにノード数（サーバ数）を増減させるオートノミック技術と組み合わせることで、仕掛中の処理をすぐさま他のノード（サーバ）で引継ぎ、即時にノード（サーバ）を減少させることも可能である。すなわち、例えば、図２のシステムにおいて（図１の場合も同様である）トランザクションの負荷をモニタするトランザクションモニタ装置２５を追加することで、サーバの障害だけを管理するのではなく、サーバのトランザクション負荷を監視させるようにする。トランザクション量はあらかじめ所定の値を記憶しておき、トランザクションモニタ装置が判定するようにしてもよい。つまり、トランザクションモニタ装置２５は、あらかじめ各サーバの適正な負荷量を記憶しておき、あるサーバが適正な負荷を超えた（超えそうな）ことを検知すると、追加のサーバをシステムに加え全体の負荷を分散するように中継装置１８に通知する。そして、後に（例えば深夜などに）負荷が減少してサーバ数が逆に過剰になった場合には、トランザクションモニタ装置２５は、中継装置１８の各コンポーネント部に対して、過剰なサーバが障害に陥ったと認識させることで、その過剰なサーバを切り離すために図１、図２のシステムにおける処理がほとんどそのまま利用できる。すなわち、このトランザクションモニタ装置２５と、上述に説明したリクエスト代理部１９（リクエスト代理装置１２）、要求情報管理部２０（要求情報管理装置１３）、接続代理部２１（接続代理装置１６）と連携させることで、自立調整型のコンピュータ・システムを容易に構築できることになる。特に、従来のオートノミック技術では、サーバをシステムから切り離すときに、技術的困難と課題があるため、本発明の手法はきわめて有用である。
【００２９】
図４は、本発明の第１、第２の実施形態においてシステムが正常に動作している場合の処理の流れを示す図である。なお、図１と図２の実施形態においてはハードウェア構成が異なるのみで、基本的な処理は同様である。以降の説明では、図１のリクエスト代理装置１２と図２のリクエスト代理部１９を総称して、リクエスト代理コンポーネント４と呼ぶ。また同様に、要求情報管理装置１３と要求情報管理部２０を総称して、要求情報管理コンポーネント５と呼び、接続代理装置１６と接続代理部２１を総称して、接続代理コンポーネント６と呼ぶことにする。これらのコンポーネントは本発明の主要部を構成する。
【００３０】
以降、要求元端末１１上のアプリケーションとして、Ｗｅｂブラウザ３を例にとって具体的に説明する。また図３、図４では、ステップＳｎはデータの流れを表している。
【００３１】
［正常時の処理］
まず、Ｗｅｂブラウザ３からの要求情報が含まれたリクエスト（通常はＨＴＴＰリクエスト）が送信される（ステップＳ１）。次に、このリクエストに関連するクッキーＩＤやＨＴＴＰリクエストに含まれるデータ、Ｗｅｂブラウザ３が稼動する端末情報をリクエスト代理コンポーネント４から要求情報管理コンポーネント５へ送信し、要求情報管理コンポーネント５は自らの記憶部にこれらのデータを記憶する（ステップＳ２）。
【００３２】
そして、リクエスト代理コンポーネント４は、Ｗｅｂ／ＡＰサーバ１に対し、代理サーバ（Ｐｒｏｘｙサーバ）として、リクエストを送信する（ステップ３）。次に、Ｗｅｂ／ＡＰサーバ１は、バックエンドサーバ７や外部デバイス８のリクエストを接続代理コンポーネント６に依頼する（ステップＳ４）。更に、接続代理コンポーネント６は、この依頼に従い、バックエンドサーバ７や外部デバイス８への処理を代行する（ステップＳ５）。ここでの接続（セッション）は、接続代理コンポーネント６が、あらかじめバックエンドサーバ７および外部デバイス８と確立しておき、このセッションのコネクション情報を、接続代理コンポーネント６に備えた接続プールを用いて管理する。セッションは一度確立したらそのまま接続プールに保持される。こうすることでセッションの確立、終了にかかるオーバヘッドを最小にすることができる。
【００３３】
一つのリクエストに複数のトランザクションが含まれる場合、Ｗｅｂ／ＡＰサーバ１は、トランザクション単位で処理が完了する毎に要求情報管理コンポーネント５に完了状況を送付する。また、この際、復帰する際に必要な情報を合わせて送付する（ステップＳ６）。次に、Ｗｅｂ／ＡＰサーバ１は、トランザクションの処理結果をリクエスト代理コンポーネント４に戻す（ステップＳ７）。リクエスト代理コンポーネント４は、要求情報管理コンポーネント５が記憶しているＷｅｂブラウザ３に関する端末情報を元にＷｅｂブラウザ３にリクエスト単位に処理結果を戻す（ステップＳ８）。最後に、このリクエストが完了したことを要求情報管理コンポーネント５に伝達し、要求情報管理コンポーネント５は、記憶している復帰情報を削除する（ステップＳ９）。これらの一連の処理は、Ｗｅｂ／ＡＰサーバ上に設けられた専用のＡＰＩを持つサポート・ライブラリのモジュール群によって実現される。
【００３４】
図５は、本発明の第１、第２の実施形態においてシステムの異常発生時の処理の流れを示す図である。まず、Ｗｅｂブラウザ３から要求情報が含まれたリクエストが送信される（ステップＳ１）。次に、このリクエストに関連するクッキーＩＤやＨＴＴＰリクエストに含まれるデータ、Ｗｅｂブラウザ３が稼動する端末情報をリクエスト代理コンポーネント４から要求情報管理コンポーネント５へ送付し、要求情報管理コンポーネント５はこれらのデータを記憶する（ステップＳ２）。
【００３５】
そして、リクエスト代理コンポーネント４は、Ｗｅｂ／ＡＰサーバ１に対し、代理サーバ（Ｐｒｏｘｙサーバ）として、リクエストを送信する（ステップ３）。Ｗｅｂ／ＡＰサーバ１は、バックエンドサーバ７や外部デバイス８のリクエストを接続代理コンポーネント６に依頼する（ステップＳ４）。接続代理コンポーネント６は、依頼に従い、バックエンドサーバ７や外部デバイス８への処理を代行する（ステップＳ５）。ここで接続セッションは、接続代理コンポーネント６が、あらかじめバックエンドサーバ７および外部デバイス８と確立しておき、このセッションのコネクション情報を、接続代理コンポーネント６に備えた接続プールを用いて管理する。一つのリクエストに複数のトランザクションが含まれる場合、Ｗｅｂ／ＡＰサーバ１は、トランザクション単位で処理が完了する毎に要求情報管理コンポーネント５に完了状況を送付する。また、この際、復帰する際に必要な情報を合わせて送付する（ステップＳ６）。ここまでの処理（ステップＳ１〜Ｓ６）は、図３の正常時の処理と同じである。
【００３６】
［異常時の処理］
ここで、Ｗｅｂ／ＡＰサーバ１で障害が発生したとする（ステップＳ７）と、これをリクエスト代理コンポーネント４が検知する。障害発生検知後、リクエスト代理コンポーネント４は、要求情報管理コンポーネント５が記憶しているクッキー情報、ＨＴＴＰリクエストに含まれるデータ、トランザクション完了情報、復帰情報を読出し（ステップ８ａ）、そのリクエストをＷｅｂ／ＡＰサーバ２へ送信する（ステップ８ｂ）。
【００３７】
Ｗｅｂ／ＡＰサーバ２ではサポート・ライブラリ（処理の継続の処理モジュールの集まりであるＡＰＩライブラリ）を備え、このサポート・ライブラリにより必要なロールバック処理と残っているトランザクション処理を開始し、処理を継続する（ステップＳ９）。また、バックエンドサーバ７や外部デバイス８への要求を接続代理コンポーネント６へ依頼する際、Ｗｅｂ／ＡＰサーバ１で使用していた接続と同じものを使用し、バックエンドサーバ７や外部デバイス８のトランザクション処理を継続する（ステップＳ１０）。
【００３８】
Ｗｅｂ／ＡＰサーバ２は、トランザクションの処理結果をリクエスト代理コンポーネント４に戻す（ステップＳ１１）。リクエスト代理コンポーネント４は、要求情報管理コンポーネント５が記憶しているＷｅｂブラウザ３の端末情報を元にＷｅｂブラウザ３にリクエスト単位に処理結果を戻す（ステップＳ１２）。最後に、このリクエストが完了したことを要求情報管理コンポーネント５に伝達し、要求情報管理コンポーネント５は、記憶している復帰情報を削除する（ステップＳ１３）。
【００３９】
図６は、本発明の第１、第２の実施形態においてリクエスト代理コンポーネント４のサーバ障害検知後の処理の流れを示す図である。まず、ステップＳ３１においてＷｅｂ／ＡＰサーバの障害を検知する。検知する具体的方法についてはここでは特に問わない。次にステップＳ３２では、要求情報管理コンポーネント５から仕掛中のリクエスト情報を問い合わせる。そして、ステップＳ３３では、要求情報管理コンポーネント５から仕掛中のリクエストのパラメータ、復帰情報、接続プール情報を受け取る。更に、ステップＳ３４において、パラメータ、復帰情報、接続プール情報からリクエストをジェネレートし、ステップＳ３５で、ジェネレートしたリクエストを障害の発生していないＷｅｂ／ＡＰサーバ２上のサポート・ライブラリへ送信する。そしてサポート・ライブラリから結果を受け取り（ステップＳ３６）、受け取った結果をＷｅｂブラウザ３へ送り（ステップＳ３７）、要求情報管理コンポーネント５に復帰処理の完了を知らせる（ステップＳ３８）。これらのステップＳ３２〜Ｓ３８を、仕掛中のリクエスト全てに対して行う（ステップＳ３９）。
【００４０】
図７は、本発明の第１、第２の実施形態において要求情報管理コンポーネント５の復帰処理開始の流れを示す図である。ステップＳ４１において、リクエスト代理コンポーネント４から仕掛中リクエストの問い合わせを受けると、保管しているリクエストを検索し（ステップＳ４２）、リクエスト代理コンポーネント４へ仕掛中リクエストのパラメータ、復帰情報、接続プール情報を送る（ステップＳ４３）。これらの処理（ステップＳ４１〜Ｓ４３）を繰り返す。
【００４１】
図８は、本発明の第１、第２の実施形態において要求情報管理コンポーネント５の復帰処理完了の流れを示す図である。ステップＳ５１において、リクエスト代理コンポーネント４から復帰処理完了の通知を受け取ると、保管しているリクエストを検索し（ステップＳ５２）、該当するリクエストのステータスを正常完了にする（ステップＳ５３）。これらの処理（ステップＳ５１〜Ｓ５３）を繰り返す。
【００４２】
図９は、本発明の第１、第２の実施形態においてＷｅｂ／ＡＰサーバ２上のサポート・ライブラリの処理の流れを示す図である。ステップＳ６１において、リクエスト代理コンポーネントからジェネレートされたリクエストを受け取る。次に、受け取ったパラメータ情報からアプリケーション（ＡＰＰＬ）の初期化を行う（ステップＳ６２）。また、受け取った復帰情報からアプリケーションの仕掛中の処理を継続させる（ステップＳ６３）。更に、受け取った接続プール情報を元に接続代理コンポーネント上の接続プールから正常時と同じ接続情報を取得する（ステップＳ６４）。次に、Ｗｅｂ／ＡＰサーバ上のアプリケーションからバックエンドサーバ７、もしくは外部デバイス８への処理要求を受け取る（ステップＳ６５）。そして、接続代理コンポーネント６へ要求を送り（ステップＳ６６）、接続代理コンポーネント６から受け取った結果をアプリケーションに送る（ステップＳ６７）。最後に、処理結果をリクエスト代理コンポーネントへ送る（ステップＳ６８）。以上のステップ（Ｓ６１〜Ｓ６８）を繰り返す。
【００４３】
図１０は、本発明の第１、第２の実施形態において接続代理コンポーネント６の処理の流れを示す図である。まず、（Ｗｅｂ／ＡＰサーバ１またはＷｅｂ／ＡＰサーバ２から）サポート・ライブラリからの要求内容を受け取ると（ステップＳ７１）、（バックエンドサーバ７、もしくは外部デバイス８の）接続プールを使用して要求内容を送る（ステップＳ７２）。次にバックエンドサーバ、もしくは外部デバイス８から結果を受け取る（ステップＳ７３）。そして、サポート・ライブラリへ結果を送る（ステップＳ７４）。以上の処理（ステップＳ７１〜Ｓ７４）を繰り返す。
【００４４】
以上説明した、図１〜図１０の各装置またはコンポーネントの処理の特徴をまとめると以下のようになる。
１）処理の途中から再開できるため、ロールバックをしたくない、もしくは不可能な場合での障害復帰に効果がある。
２）このシステムは使用するための前提条件が必要でなく汎用的に利用できる。ＰｅｒｌなどのＣＧＩやｓｅｎｄｍａｉｌといったトランザクションの概念がないバックエンドサーバまたは外部デバイスにも適用可能である。
３）トランザクション管理を行う機能とユーザロジックを分離しているためユーザロジックの影響を受けない。
４）復帰処理の方法をシステム任せでなく、自由に設定できる。
５）ユーザに障害に気付かせないシステムが組める。
６）バックエンド、外部デバイスにＷｅｂ／ＡＰサーバの影響を与えない。
このような特徴を全て備えたシステムは従来にないものである。
【００４５】
図１１は、図１〜図１０で説明したサーバや各装置（各コンポーネントを含む）の典型的なハードウェア構成例として情報処理装置１００を示したものである。以下、この情報処理装置１００のハードウェア構成の１例を示す。情報処理装置１００は、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）１０１０、バスライン１００５、通信Ｉ／Ｆ１０４０、メインメモリ１０５０、ＢＩＯＳ（Ｂａｓｉｃ  Ｉｎｐｕｔ  Ｏｕｔｐｕｔ  Ｓｙｓｔｅｍ）１０６０、パラレルポート１０８０、ＵＳＢポート１０９０、グラフィック・コントローラ１０２０、ＶＲＡＭ１０２４、音声プロセッサ１０３０、Ｉ／Ｏコントローラ１０７０、並びにキーボードおよびマウス・アダプタ等１１００の入力手段を備える。Ｉ／Ｏコントローラ１０７０には、フレキシブル・ディスク（ＦＤ）ドライブ１０７２、ハード・ディスク１０７４、光ディスクドライブ１０７６、半導体メモリ１０７８、等の記憶手段を接続することができる。
【００４６】
音声プロセッサ１０３０には、増幅回路１０３２およびスピーカ１０３４が接続される。また、グラフィック・コントローラ１０２０には、表示装置１０２２が接続されている。
【００４７】
ＢＩＯＳ１０６０は、情報処理装置１００の起動時にＣＰＵ１０１０が実行するブートプログラムや、情報処理装置１００のハードウェアに依存するプログラム等を格納する。ＦＤ（フレキシブル・ディスク）ドライブ１０７２は、フレキシブル・ディスク１０７１からプログラムまたはデータを読み取り、Ｉ／Ｏコントローラ１０７０を介してメインメモリ１０５０またはハード・ディスク１０７４に提供する。
【００４８】
光ディスクドライブ１０７６としては、例えば、ＤＶＤ−ＲＯＭドライブ、ＣＤ−ＲＯＭドライブ、ＤＶＤ−ＲＡＭドライブ、ＣＤ−ＲＡＭドライブを使用することができる。この際は各ドライブに対応した光ディスク１０７７を使用する必要がある。光ディスクドライブ１０７６は光ディスク１０７７からプログラムまたはデータを読み取り、Ｉ／Ｏコントローラ１０７０を介してメインメモリ１０５０またはハード・ディスク１０７４に提供することもできる。
【００４９】
情報処理装置１００に提供されるコンピュータ・プログラムは、フレキシブル・ディスク１０７１、光ディスク１０７７、またはメモリーカード等の記録媒体に格納されて利用者によって提供される。このコンピュータ・プログラムは、Ｉ／Ｏコントローラ１０７０を介して、記録媒体から読み出され、または通信Ｉ／Ｆ１０４０を介してダウンロードされることによって、情報処理装置１００にインストールされ実行される。コンピュータ・プログラムが情報処理装置に働きかけて行わせる動作は、図１から図９において説明したサーバまたは各コンポーネント装置における動作と同一であるので省略する。
【００５０】
前述のコンピュータ・プログラムは、外部の記憶媒体に格納されてもよい。記憶媒体としてはフレキシブル・ディスク１０７１、光ディスク１０７７、またはメモリーカードの他に、ＭＤ等の光磁気記録媒体、テープ媒体を用いることができる。また、専用通信回線やインターネットに接続されたサーバシステムに設けたハード・ディスクまたは光ディスク・ライブラリ等の記憶装置を記録媒体として使用し、通信回線を介してコンピュータ・プログラムを情報処理装置１００に提供してもよい。
【００５１】
以上の例は、情報処理装置１００について主に説明したが、コンピュータに、情報処理装置で説明した機能を有するプログラムをインストールして、そのコンピュータを情報処理装置として動作させることにより上記で説明した情報処理装置と同様な機能を実現することができる。従って、本発明において一つの実施形態として説明した情報処理装置は、方法およびそのコンピュータ・プログラムによっても実現可能である。
【００５２】
本発明の装置は、ハードウェア、ソフトウェア、またはハードウェアおよびソフトウェアの組み合わせとして実現可能である。ハードウェアとソフトウェアの組み合わせによる実施では、所定のプログラムを有するコンピュータ・システムでの実施が典型的な例として挙げられる。かかる場合、該所定のプログラムが該コンピュータ・システムにロードされ実行されることにより、該プログラムは、コンピュータ・システムに本発明にかかる処理を実行させる。このプログラムは、任意の言語、コード、または表記によって表現可能な命令群から構成される。そのような命令群は、システムが特定の機能を直接実行すること、または（１）他の言語、コード、もしくは表記への変換、（２）他の媒体への複製、のいずれか一方もしくは双方が行われた後に、実行することを可能にするものである。もちろん、本発明は、そのようなプログラム自体のみならず、プログラムを記録した媒体を含むプログラム製品もその範囲に含むものである。本発明の機能を実行するためのプログラムは、フレキシブル・ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＤＶＤ、ハード・ディスク装置、ＲＯＭ、ＭＲＡＭ、ＲＡＭ等の任意のコンピュータ可読媒体に格納することができる。かかるプログラムは、コンピュータ可読媒体への格納のために、通信回線で接続する他のコンピュータ・システムからダウンロードしたり、他の媒体から複製したりすることができる。また、かかるプログラムは、圧縮し、または複数に分割して、単一または複数の記録媒体に格納することもできる。
【００５３】
以上、本発明を実施形態、および実施例を用いて説明したが、本発明の技術的範囲は上記実施形態に記載の範囲に限定されない。上記実施形態に、多様な変更または改良を加えることが可能である。また、そのような変更または改良を加えた形態も本発明の技術的範囲に含まれ得ることが、特許請求の範囲の記載から明らかである。
【図面の簡単な説明】
【００５４】
【図１】本発明の第１の実施形態におけるサーバシステム１０の概略を示す図である。
【図２】本発明の第２の実施形態におけるサーバシステム３０の概略を示す図である。
【図３】本発明の第３の実施形態におけるサーバシステム４０の概略を示す図である。
【図４】本発明の第１、第２の実施形態においてシステムが正常に動作している場合の処理の流れを示す図である。
【図５】本発明の第１、第２の実施形態においてシステムの異常発生時の処理の流れを示す図である。
【図６】本発明の第１、第２の実施形態においてリクエスト代理コンポーネント４のサーバ障害検知後の処理の流れを示す図である。
【図７】本発明の第１、第２の実施形態において要求情報管理コンポーネント５の復帰処理開始の流れを示す図である。
【図８】本発明の第１、第２の実施形態において要求情報管理コンポーネント５の処理の流れ（復帰処理完了）を示す図である。
【図９】本発明の第１、第２の実施形態においてＷｅｂ／ＡＰサーバ２上のサポート・ライブラリの処理の流れを示す図である。
【図１０】本発明の第１、第２の実施形態において接続代理コンポーネント６の処理の流れを示す図である。
【図１１】本発明のサーバ装置、各コンポーネント装置の典型的なハードウェア構成例として情報処理装置１００を示した図である。
【符号の説明】
【００５５】
１  Ｗｅｂ／ＡＰサーバ１
２  Ｗｅｂ／ＡＰサーバ２
３  Ｗｅｂブラウザ
４  リクエスト代理コンポーネント
５  要求情報管理コンポーネント
６  接続代理コンポーネント
７  バックエンドサーバ
８  外部デバイス
１０，２０，３０  サーバシステム
１１  要求元端末
１２  リクエスト代理装置
１３  要求情報管理装置
１４  第１サーバ
１５  第２サーバ
１６  接続代理装置
１８  中継装置
１７  外部処理装置
１９  リクエスト代理部
２０  要求情報管理部
２１  接続代理部
２５  トランザクションモニタ装置
１００  情報処理装置
【図１】
2008027189.tif 000003
【図２】
2008027189.tif 000004
【図３】
2008027189.tif 000005
【図４】
2008027189.tif 000006
【図５】
2008027189.tif 000007
【図６】
2008027189.tif 000008
【図７】
2008027189.tif 000009
【図８】
2008027189.tif 000010
【図９】
2008027189.tif 000011
【図１０】
2008027189.tif 000012
【図１１】
2008027189.tif 000013