(57)【要約】【課題】  Webサーバと機能サーバ（Webコンテナ）間のタイマに関する連携基盤が確立されておらず、キューイングの時間も含めたリアルタイムで強制力のあるタイマ制御ができていなかった。【解決手段】  WebサーバとWebコンテナがタイマに関してリアルタイムな連携を行う基盤を整える。その処理内容は、Webサーバ側でタイムアウトを検知した場合、速やかにその旨をWebコンテナ側に通知し、リクエストの破棄を行い、処理に失敗した旨をWebサーバ経由でクライアントに通知する。すなわち、webサーバとWebコンテナでのタイムアウトについての役割（処理）分担に本発明の特徴がある。【選択図】  図３
2008003645.tif 000002
【特許請求の範囲】
【請求項１】
クライアント端末とｗｅｂサーバと機能サーバが互いに接続されたシステムを用いたタイマ連携によるリクエスト制御方法において、
前記クライアント端末から前記ｗｅｂサーバに対して、処理要求を含むリクエスト情報を送信し、
前記ｗｅｂサーバが、前記リクエスト情報を受信し、受信されたリクエスト情報を前記機能サーバに送信し、
前記機能サーバが、送信された前記リクエスト情報に対応する情報処理を実行し、
前記ｗｅｂサーバが、前記リクエスト情報に対応する前記機能サーバの処理応答について、予め定められた時間外になっても前記処理応答がなされていないことを検知し、検知された内容を前記機能サーバに送信し、
前記機能サーバは、前記情報処理の進捗状況が所定の条件を満たしているか否かを判定し、満たしている場合には前記リクエスト情報を無効化し、当該無効化を実行した旨を示す情報を前記クライアント端末に送信することを特徴とするタイマ連携によるリクエスト制御方法。
【請求項２】
請求項１に記載のタイマ連携によるリクエスト制御方法において、
前記機能サーバは、前記リクエスト情報のキューイング中もしくは対応する情報処理中に、前記検知された内容を受信した場合、前記所定の条件を満たすと判定することを特徴とするタイマ連携によるリクエスト制御方法。
【請求項３】
請求項２に記載のタイマ連携によるリクエスト制御方法において、
前記機能サーバは、前記情報処理中に、前記検知された内容を受信した場合、当該情報処理のトランザクションをロールバックしてから前記リクエスト情報に対する無効化処理を実行することを特徴とするタイマ連携によるタイマ連携によるリクエスト制御方法。
【請求項４】
請求項２または３に記載のタイマ連携によるリクエスト制御方法において、
前記機能サーバは、前記リクエスト情報のキューイング中および対応する情報処理中のいずれでもない場合には、該当リクエストが正常終了した旨の通知を前記クライアント端末に送信することを特徴とするタイマ連携によるリクエスト制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、クライアントから送信されるリクエスト（情報）に応じた処理を行うサーバ、これらのシステム（いわゆるクライアントサーバシステム）およびこれらを用いた制御方法に関する。より詳細には、いわゆるWebサーバと所定の機能を実行する機能サーバとを連携し、Webサーバで受付けられたリクエストに対する制御を実行する技術に関する。その中でも特に、リクエストに対するレスポンス（処理）に対する応答を、障害の発生などのために、所定の条件（一定時間内等）でできないことを検知した場合の通知に関する。なお、機能サーバとしては、いわゆるＪ２ＥＥサーバが含まれる（Ｊ２ＥＥはサンマイクロシステムズ社の商標）。
【背景技術】
【０００２】
従来、クライアントサーバシステムにおいて、クライアントのリクエストに基づいた処理を実行中のサーバ内で発生した障害を検知するものとして、特許文献１がある。
【０００３】
特許文献１においては、クライアントサーバシステムにおいて、レスポンスを低下させることなく、複数のクライアントからのリクエストを処理することを可能とすることを目的としている。特許文献１においては、この目的を達成するために以下の構成を取っている。サービススレッド２３ａは、クライアント２１ａからのリクエスト２８を受信すると、要求された処理のタイムアウト時間と自分のスレッドＩＤをタイムアウト表２５に書込む。そして、リクエスト２８の処理を終了すると、タイムアウト表２５内のタイムアウト時間及びスレッドＩＤを消去する。監視スレッド２４は、定期的にタイムアウト表２５からタイムアウト時間を読み出して、現在の時刻と比較することにより、設定されたタイムアウト時間までに処理を終了していないサービススレッドを検出する。タイムアウトしたサービススレッドを発見した場合には、当該サービススレッドを強制的に終了させて、クライアント２１にエラーを通知する。
【０００４】
【特許文献１】特開平8-263325号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら、特許文献１においては、従来はそもそもWebサーバと機能サーバが連携してリクエストを受付け、応答することは記載されていなかった。このことにも伴い、Webサーバと機能サーバ（Webコンテナ）間のタイマに関する連携基盤が確立されておらず、キューイングの時間も含めたリアルタイムで強制力のあるタイマ制御ができていなかった。そのため、Webサーバ側でタイムアウトしたにも関わらずWebコンテナ側で処理が仕掛かってしまい正常終了する、という事象が処理遅延発生時には多く見られた。この事象が発生すると、具体的には、（１）Webサーバでタイムアウトが発生した場合、クライアントではサーバ側の処理が正常終了したかどうかを把握する術がないため、クライアントは再度サーバにアクセスして処理結果を確認する必要が出てきてしまう。（２）クライアントが処理結果を確認するために再度サーバにアクセスした際に、サーバ側で仕掛中の処理が完了していない可能性があり、その処理が完了するまでの間クライアントは処理の結果を確認することができない。
が問題として挙げられる。
【課題を解決するための手段】
【０００６】
WebサーバとWebコンテナがタイマに関してリアルタイムな連携を行う基盤を整える。その処理内容は、Webサーバ側でタイムアウトを検知した場合、速やかにその旨をWebコンテナ側に通知し、リクエストの破棄を行い、処理に失敗した旨をWebサーバ経由でクライアントに通知する。すなわち、webサーバとWebコンテナでのタイムアウトについての役割（処理）分担にその特徴がある。
【０００７】
そして、Ｗｅｂサーバからタイムアウトを通知し、これをＷｅｂコンテナが受信した際の、当該Ｗｅｂコンテナでの該当リクエストに対する処理状況に応じて、Ｗｅｂコンテナ（もしくはＷｅｂサーバ）の対応処理を変更することも本発明に含まれる。例えば、該当リクエストのキューイング中もしくは業務処理中に、タイムアウト（を超過したことを示す情報）を受信した場合、リクエストの破棄処理（無効化処理）を行い、Ｗｅｂサーバ経由で破棄されたことを示す情報をクライアントに送信する。この際、業務処理中に受信した場合は、当該業務処理のトランザクションをロールバックしてからリクエストを破棄してもよい。なお、破棄されたことを示す情報は、ｗｅｂコンテナからクライアント端末に直接送信してもよい。
【０００８】
また、ここで、該当リクエストのキューイング中および業務処理中のいずれでもない場合に通知を受信した場合には、該当リクエストが正常終了した旨の通知を出力する。この通知も、ｗｅｂサーバを経由してクライアント端末に送信してもよい（これには、ｗｅｂサーバに送信し、ｗｅｂサーバがクライアント端末にその通知の形式などを変更して送信することも含み、破棄を示す通知の場合も同じ）し、直接クライアント端末に送信してもよい。
【０００９】
これによって、（１）の課題については、Webサーバでタイムアウトを検知した場合はWebコンテナ側でリクエストを破棄するため、処理結果が不明ではなく失敗している、という確実な情報をクライアントに返すことができ、状況は改善される。また、（２）の課題については、WebサーバとWebコンテナでリクエストのステータスについて同期が取れているため、クライアントが処理の失敗を認識して再度リクエストを送信した場合においても、サーバ側で処理が仕掛中のために待たされるような事象はなくなるため、状況は改善される。
【００１０】
本発明には、以下の態様も含まれる。なお、ここでは、リクエスト制御方法として表現されているが、各構成要件（クライアント端末、ｗｅｂサーバ、機能サーバ）を含むシステムおよびこれら各構成要件も本発明に含まれる。
【００１１】
クライアント端末とｗｅｂサーバと機能サーバが互いに接続されたシステムを用いたタイマ連携によるリクエスト制御方法において、前記クライアント端末から前記ｗｅｂサーバに対して、処理要求を含むリクエスト情報を送信し、前記ｗｅｂサーバが、前記リクエスト情報を受信し、受信されたリクエスト情報を前記機能サーバに送信し、前記機能サーバが、送信された前記リクエスト情報に対応する情報処理を実行し、前記ｗｅｂサーバが、前記リクエスト情報に対応する前記機能サーバの処理応答について、予め定められた時間外になっても前記処理応答がなされていないことを検知し、検知された内容を前記機能サーバに送信し、前記機能サーバは、前記情報処理の進捗状況が所定の条件を満たしているか否かを判定し、満たしている場合には前記リクエスト情報を無効化し、当該無効化を実行した旨を示す情報を前記クライアント端末に送信することを特徴とするタイマ連携によるリクエスト制御方法。また、このタイマ連携によるリクエスト制御方法において、前記機能サーバは、前記リクエスト情報のキューイング中もしくは対応する情報処理中に、前記検知された内容を受信した場合、前記所定の条件を満たすと判定することを特徴とするタイマ連携によるリクエスト制御方法。
【００１２】
また、このタイマ連携によるリクエスト制御方法において、前記機能サーバは、前記情報処理中に、前記検知された内容を受信した場合、当該情報処理のトランザクションをロールバックしてから前記リクエスト情報に対する無効化処理を実行することを特徴とするタイマ連携によるリクエスト制御方法。また、これらのタイマ連携によるリクエスト制御方法において、前記機能サーバは、前記リクエスト情報のキューイング中および対応する情報処理中のいずれでもない場合には、該当リクエストが正常終了した旨の通知を前記クライアント端末に送信することを特徴とするタイマ連携によるリクエスト制御方法。
【発明の効果】
【００１３】
WebサーバとWebコンテナのタイマ連携によって、従来技術では不可能であったキューイング中のリクエストの破棄が可能となる。これによって、従来遅延発生時に頻発していた「Webサーバがタイムアウトをクライアント端末に返すが、サーバ側で処理が仕掛かって正常に完了している」という不整合の発生確率を低減することが可能となる。
【発明を実施するための最良の形態】
【００１４】
以下、本発明の実施の形態を詳細に説明する。
【００１５】
図１は、本発明をオンラインシステムの一般的な端末取引に適用した場合の処理手順の実施の形態を示すフローチャートであり、図２は、本発明に関わるサーバ装置の概要を示したブロック図である。
【００１６】
まず、図２のブロック図に基づいて全体の構成を示す。
クライアント端末10は、一般のエンドユーザが所有する携帯電話端末やPC端末を表している。クライアント端末が処理の起点となって、様々な処理の要求（リクエスト）をサーバに対して送信することが、最初のアクションとなる。
【００１７】
Webサーバ12は、クライアント端末10から受信したリクエストについて、（１）（既存）リクエストのURLより該当するWebコンテナ14上のアプリケーションに対して振分けを行う、（２）（既存）リクエストをリクエスト管理テーブル20に登録し、個々のリクエスト単位でタイマ監視を行う、（３）（新規）タイマ監視で閾値を超過したリクエストについてはWebコンテナ14に対してリクエストの破棄を要求するの役割を持つ。上記（１）（２）は既存のWebサーバが有する機能であり、（３）が本明細書にて提案するWebサーバの新機能に該当する。
【００１８】
Webコンテナ14では、Webサーバより振り分けられたリクエストを受信して、実際の業務処理を行う。Webサーバとのタイマ値の連携により、従来機能ではなし得なかった「Webサーバ側でのタイムアウト時のWebコンテナにおけるリクエストの破棄」が実現可能となる。
【００１９】
なお、上述した各装置は、いわゆるコンピュータであり、それぞれプログラムや情報を格納する記憶装置、メモリ、制御装置（ＣＰＵ）を有し、メモリに展開されたプログラムに従って制御装置が処理を実行する。
【００２０】
次に、図１のフローチャートに基づいて、図１、図２及び図３の各部の動作（すなわち、上述した処理の内容）を説明する。
図１において、クライアント端末10はリクエストをサーバに対して送信する（ステップ100）。すなわち、要求する処理内容を特定する情報を含むリクエストを送信する。
【００２１】
サーバ側では、まずWebサーバ12がこのリクエストを受信する（ステップ102）。次に、Webサーバ１２は、リクエスト管理テーブル20に受信したリクエストに関する情報（クライアントにユニークな情報（IPアドレス、端末機種名など）22、クライアントが要求したURL24、リクエストのタイマ監視開始時刻26及びリクエストのタイマ監視の閾値28）を登録する。そして、リクエストごとに個別にタイマ監視を開始する（ステップ104）。すなわち、ここで内蔵したタイマに起動をかけ、リクエスト管理テーブルのユニークな情報と対応付けてタイマの値を検知する。そして、この値とテーブルに格納された閾値を比較して、閾値を超過していないか判断する。
【００２２】
そして、リクエストをWebコンテナ14へ送信する（ステップ106）。
【００２３】
また、Webサーバ12は、ステップ１０４で開始されたタイマの閾値を超過するかどうか継続的に監視する（ステップ108）。ここでは、リクエストに対する応答（処理）が実行されたことを示す情報を受信するまでステップ１０８を実行してもよい。また、応答（処理）が実行されたことを示す情報を受信した場合に閾値内であれば、ＮＯと判断してステップ１３６に進んでもよい。この処理内容は、ステップ１０４と同様の処理を行ってもよい。
【００２４】
閾値を超過したと判断した場合は、タイマの閾値を超えた旨をWebコンテナへ通知する（ステップ110）。タイマの閾値を超えることなくWebコンテナ側で処理が完了した場合（完了通知の受信などで判定）、処理が正常終了した旨及び処理結果をWebコンテナより受信して、クライアントに対して同情報を送信する（ステップ136）。
【００２５】
＜Webサーバの挙動＞
まずWebサーバがタイマの閾値を超えた旨をWebコンテナへ通知する（ステップ110）。この際、リクエストに対する破棄を要求する情報を、Webコンテナ１４に送信する。そしてWebコンテナ１４から応答が送信された場合、これを受信する。Webコンテナから「リクエストの破棄に成功した」旨の通知（情報）を受信した（ステップ134）後、その旨を示す情報を、クライアント端末にレスポンスとして送信する。具体的には、例えばクライアントからのリクエストが口座振込処理であった場合、「振込処理に失敗しました。再度やり直してください」等のメッセージを含む情報を送信する。
【００２６】
＜Webコンテナの挙動＞
WebコンテナはWebサーバからリクエストを受信した（ステップ112）後、実行スレッドの空きの有無を確認する（ステップ114）。
【００２７】
ここでスレッドに空きがあった場合、リクエストをスレッドに移行して業務処理（トランザクション）を開始する（ステップ120）。スレッドに空きがなかった場合はリクエストを実行待ちキュー（既存）にキューイングし（ステップ116）、スレッドに空きが出た時点でスレッドに移行する（ステップ120）。
【００２８】
キューイングされている間、Webコンテナは常にWebサーバからのタイムアウト検知の通知を受信できる状態を維持している（ステップ118）。タイムアウトの通知を受信した場合、即座にリクエストの破棄を行い（ステップ126）、リクエストが破棄された旨をWebサーバへ通知する（ステップ128）。タイムアウトの通知を受信しなかった場合は、スレッドの空きを待って空きが出た時点でスレッドに移行する（ステップ120）。
【００２９】
リクエストがスレッドに移行すると、Webコンテナはトランザクションを開始する（ステップ120）。トランザクションの仕掛中（トランザクションが開始した後終了するまでの間）についても、Webコンテナは常にWebサーバからのタイムアウト検知の通知を受信できる状態を維持している（ステップ122）。トランザクション仕掛中にタイムアウトの通知を受信した場合、まずトランザクションのロールバックを行い（ステップ124）、リクエストを破棄し（ステップ126）、リクエストの破棄に成功した旨をWebサーバへ通知する（ステップ128）。トランザクション仕掛中にタイムアウトの通知を受信しなかった場合、トランザクションをコミットし（ステップ130）、リクエストが正常終了した旨をWebサーバへ通知する（ステップ132）。
【図面の簡単な説明】
【００３０】
【図１】本発明の処理手順の実施の形態を示すフローチャートである。
【図２】本発明を適用する前の既存技術の処理手順の形態を示すフローチャートである。
【図３】本発明に関わるサーバ装置のブロック図である。
【符号の説明】
【００３１】
10  クライアント端末
12  Webサーバ
14  Webコンテナ
20  リクエスト管理テーブル
【図１】
2008003645.tif 000003
【図２】
2008003645.tif 000004
【図３】
2008003645.tif 000005