(57)【要約】【課題】Ｗｅｂサービスを提供するサーバ装置の束縛時間を短くし、より早く次のリクエストを受け付け可能な状態に移行させる。【解決手段】Ｗｅｂサービス担当ＡＰサーバ２００は、クライアント端末１００からのリクエストを受け付けるリクエスト受付部２０１と、リクエストに応じた処理の手順を外部装置にて呼び出させるための処理をＲＭＩサービス担当ＡＰサーバ３００に対して要求する処理要求部２０４とを備える。【選択図】図２
2011002909.tif 000002
【特許請求の範囲】
【請求項１】
Ｗｅｂサービスを提供するサーバ装置であって、
クライアント端末からのリクエストを受け付けるリクエスト受付手段と、
前記リクエストに応じた処理の手順を外部装置にて呼び出させるための処理を他のサーバ装置に対して要求する要求手段とを有することを特徴とするサーバ装置。
【請求項２】
前記リクエスト受付手段は、前記要求手段により前記他のサーバに対して処理を要求した後、更に他のリクエストを受け付けることが可能であることを特徴とする請求項１に記載のサーバ装置。
【請求項３】
前記リクエスト受付手段による前記リクエストの受け付けに応じて、前記クライアント端末に対して前記リクエストを受け付けた旨を返信する返信手段を更に有することを特徴とする請求項１又は２に記載のサーバ装置。
【請求項４】
テキストデータの前記リクエストをバイナリデータの前記リクエストに変換する変換手段を更に有し、
前記要求手段は、バイナリデータの前記リクエストを前記他のサーバ装置に対して送信することにより、前記リクエストに応じた処理の手順を前記外部装置にて呼び出させるための処理を前記他のサーバ装置に対して要求することを特徴とする請求項１乃至３の何れか１項に記載のサーバ装置。
【請求項５】
Ｗｅｂサーバを提供する第１のサーバ装置と第２のサーバ装置とが通信可能に接続され、前記第２のサーバ装置と第３のサーバ装置とが通信可能に接続された情報処理システムであって、
前記第１のサーバ装置は、
クライアント端末からのリクエストを受け付けるリクエスト受付手段と、
前記リクエストに応じた処理の手順を前記第３のサーバ装置にて呼び出させるための処理を前記第２のサーバ装置に対して要求する要求手段とを有し、
前記第２のサーバ装置は、
前記要求手段からの要求を受け付ける要求受付手段と、
前記要求受付手段により受け付けた要求に応じて、前記リクエストに応じた処理の手順を前記第３のサーバ装置にて呼び出させる手順呼出し手段とを有し、
前記第３のサーバ装置は、
前記手順呼出し手段によって呼び出された手順で前記リクエストに応じた処理を実行する処理実行手段を有することを特徴とする情報処理システム。
【請求項６】
前記第３のサーバ装置は、
前記リクエストに応じた処理の進捗状況を管理する管理手段を更に有することを特徴とする請求項５に記載の情報処理システム。
【請求項７】
Ｗｅｂサービスを提供するサーバ装置の制御方法であって、
クライアント端末からのリクエストを受け付けるリクエスト受付ステップと、
前記リクエストに応じた処理の手順を外部装置にて呼び出させるための処理を他のサーバ装置に対して要求する要求ステップとを含むことを特徴とするサーバ装置の制御方法。
【請求項８】
Ｗｅｂサービスを提供するサーバ装置の制御方法をコンピュータに実行させるためのプログラムであって、
クライアント端末からのリクエストを受け付けるリクエスト受付ステップと、
前記リクエストに応じた処理の手順を外部装置にて呼び出させるための処理を他のサーバ装置に対して要求する要求ステップとをコンピュータに実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、Ｗｅｂサービスを提供するサーバ装置に適用可能な技術に関するものである。
【背景技術】
【０００２】
Ｗｅｂサービスでは、クライアント／サーバ間ではＳＯＡＰ（Simple Object Access Protocol）が使われ、ＸＭＬ（Xtensible Markup Language）による汎用性の高い通信が可能となっている。なお、ここでいうＷｅｂサービスとは、ｈｔｔｐ上でＳＯＡＰを使ってＸＭＬをやりとりすることにより、分散したアプリケーション同士が緩やかに連携して協働する仕組みである。また、ＳＯＡＰとは、他のコンピュータにあるデータやサービスを呼び出すためのプロトコルで、ＸＭＬでメッセージの交換がなされる。ＳＯＡＰを用いると、異なる環境のコンピュータ間でも通信が可能となる。
【０００３】
先ず、Ｗｅｂサービスを提供するサーバでは、クライアントからＸＭＬデータで処理のリクエストを受信すると、テキストデータであるＸＭＬデータのリクエストをバイナリデータのリクエストに変換するデシリアライズという処理が実行される。そして、Ｗｅｂサービスを提供するサーバは、バイナリデータに変換されたリクエストに基づいて、当該リクエストに応じた処理のメソッドを例えばＤＢサーバに呼び出させる処理を行う。
【先行技術文献】
【非特許文献】
【０００４】
【非特許文献１】Ｈｏｗ Ｔｏ 情報：所要時間の長いタスクの実行依頼／ポーリング方法、インターネット＜URL:http://www.microsoft.com/japan/msdn/enterprise/pag/scalenetthowto08.aspx＞
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、このようなＷｅｂサービスにおいては、大規模処理を実行させるとＷｅｂサービスを提供するサーバ側の束縛時間が長くなり、そのサーバが次のリクエストを受け付け可能な状態となるまでに多大な時間を要するという課題がある。
【０００６】
また、クライアント側から投げられたリクエストに対してサーバ側で大規模処理が発生すると、クライアント側では処理が終わるまで何も操作できなくなってしまう。この場合、クライアント側では、サーバが処理待ち状態なのか、サーバの処理がフリーズしているのか把握することができない。
【０００７】
例えば非特許文献１には、サーバが作業を完了するまでの間、クライアントの画面上に動画を見せるような技術が開示されている。
【０００８】
しかしながら、非特許文献１に開示される技術においても、サーバ側で大規模処理が発生すると、クライアント側が操作可能な状態に移行するまで相当の時間を要してしまうことに変わりない。
【０００９】
そこで、本発明の目的は、Ｗｅｂサービスを提供するサーバ装置の束縛時間を短くし、より早く次のリクエストを受け付け可能な状態に移行させることにある。
【００１０】
また、本発明の他の目的は、クライアント端末をより早く操作可能な状態に移行させることにある。
【課題を解決するための手段】
【００１１】
本発明のサーバ装置は、Ｗｅｂサービスを提供するサーバ装置であって、クライアント端末からのリクエストを受け付けるリクエスト受付手段と、前記リクエストに応じた処理の手順を外部装置にて呼び出させるための処理を他のサーバ装置に対して要求する要求手段とを有することを特徴とする。
本発明の情報処理システムは、Ｗｅｂサーバを提供する第１のサーバ装置と第２のサーバ装置とが通信可能に接続され、前記第２のサーバ装置と第３のサーバ装置とが通信可能に接続された情報処理システムであって、前記第１のサーバ装置は、クライアント端末からのリクエストを受け付けるリクエスト受付手段と、前記リクエストに応じた処理の手順を前記第３のサーバ装置にて呼び出させるための処理を前記第２のサーバ装置に対して要求する要求手段とを有し、前記第２のサーバ装置は、前記要求手段からの要求を受け付ける要求受付手段と、前記要求受付手段により受け付けた要求に応じて、前記リクエストに応じた処理の手順を前記第３のサーバ装置にて呼び出させる手順呼出し手段とを有し、前記第３のサーバ装置は、前記手順呼出し手段によって呼び出された手順で前記リクエストに応じた処理を実行する処理実行手段を有することを特徴とする。
本発明のサーバ装置の制御方法は、Ｗｅｂサービスを提供するサーバ装置の制御方法であって、クライアント端末からのリクエストを受け付けるリクエスト受付ステップと、前記リクエストに応じた処理の手順を外部装置にて呼び出させるための処理を他のサーバ装置に対して要求する要求ステップとを含むことを特徴とする。
本発明のプログラムは、Ｗｅｂサービスを提供するサーバ装置の制御方法をコンピュータに実行させるためのプログラムであって、クライアント端末からのリクエストを受け付けるリクエスト受付ステップと、前記リクエストに応じた処理の手順を外部装置にて呼び出させるための処理を他のサーバ装置に対して要求する要求ステップとをコンピュータに実行させることを特徴とする。
【発明の効果】
【００１２】
本発明において、Ｗｅｂサービスを提供するサーバ装置は、受け付けたリクエストに応じた処理の手順を外部装置にて呼び出させるための処理を他のサーバ装置に対して要求するように構成している。従って、本発明によれば、Ｗｅｂサービスを提供するサーバ装置の束縛時間を短くし、より早く次のリクエストを受け付け可能な状態に移行させることが可能となる。
【００１３】
また本発明の他の特徴によれば、リクエストの受け付けに応じて、クライアント端末に対してリクエストを受け付けた旨を返信するように構成している。このように迅速にクライアント端末に対して通知を行うことで、本発明によれば、クライアント端末をより早く操作可能な状態に移行させることが可能となる。
【図面の簡単な説明】
【００１４】
【図１】本発明の実施形態に係る情報処理システムの構成を示す図である。
【図２】Ｗｅｂサービス担当ＡＰサーバ及びＲＭＩサービス担当ＡＰサーバの主要な機能構成を示すブロック図である。
【図３】クライアント端末、Ｗｅｂサービス担当ＡＰサーバ、ＲＭＩサービス担当ＡＰサーバ及びＤＢサーバのハードウェア構成を示すブロック図である。
【図４】本発明の実施形態に係る情報処理システムの動作の流れを示すシーケンスチャートである。
【図５】ＤＢサーバ内で管理されるセッションＩＤ管理テーブルの構成を模式的に示す図である。
【図６】クライアント端末がＤＢサーバから処理カウント項目及び処理ＭＡＸカウント項目に登録される情報を取得し、ディスプレイ上に表示させた例を示す図である。
【発明を実施するための形態】
【００１５】
以下、本発明を適用した好適な実施形態を、添付図面を参照しながら詳細に説明する。
【００１６】
図１は、本発明の実施形態に係る情報処理システムの構成を示す図である。図１において、クライアント端末１００とＷｅｂサービス担当ＡＰサーバ２００とはインターネットなどのネットワークを介して接続される。Ｗｅｂサービス担当ＡＰサーバ２００とＲＭＩサービス担当ＡＰサーバ３００とはＬＡＮによって接続され、更にＲＭＩサービス担当ＡＰサーバ３００とＤＢサーバ４００とがＬＡＮによって接続される。
【００１７】
クライアント端末１００は、ユーザが操作するＰＣである。クライアント端末１００は、ユーザの操作に応じて、Ｗｅｂサービス担当ＡＰサーバ２００、ＲＭＩサービス担当ＡＰサーバ３００及びＤＢサーバ４００から構成されるコンピュータシステムに対して、データ検索要求やデータ登録要求等のリクエストを発行する。なお、Ｗｅｂサービス担当ＡＰサーバ２００は、Ｗｅｂサービスを提供するためのサーバである。ＲＭＩサービス担当ＡＰサーバ３００は、ＲＭＩサービスを提供するためのサーバである。ＤＢサーバ４００は、データベース（ＤＢ）に対するデータ登録やデータ検索等の処理を行う。ここでいうＲＭＩとは、Remote Method Invocationの略称であり、ネットワークで繋がった先のコンピュータのメソッドを呼び出すことができる技術である。
【００１８】
クライアント端末１００とＷｅｂサービス担当ＡＰサーバ２００間では、ＳＯＡＰ（Simple Object Access Protocol）によるＸＭＬデータでの通信が行われる。従って、クライアント端末１００では、例えばＤＢ登録対象のオブジェクト（バイナリデータ）をＸＭＬデータ（テキストデータ）に変換するシリアライズを実行してリクエストを生成し、Ｗｅｂサービス担当ＡＰサーバ２００に対して送信する。
【００１９】
Ｗｅｂサービス担当ＡＰサーバ２００は、クライアント端末１００からリクエストであるＸＭＬデータを受信すると、リクエストを受信した旨の通知をクライアント端末１００に対して返信する。また、Ｗｅｂサービス担当ＡＰサーバ２００は、受信したＸＭＬデータをバイナリデータに変換するデシリアライズを実行した後、後段のＲＭＩサービス担当ＡＰサーバ３００に対して、リクエストに応じたメソッド（手順）をＤＢサーバ４００にて呼び出させるための処理を要求する。この要求を行った時点でＷｅｂサービス担当ＡＰサーバ２００は、今回のリクエストに対する処理から解放され、次のリクエストを受け付けることが可能となる。
【００２０】
ＲＭＩサービス担当ＡＰサーバ２００は、Ｗｅｂサービス担当ＡＰサーバ２００からの要求を受け付けると、リクエストに応じた処理のメソッドを後段のＤＢサーバ４００に呼び出させる。ＤＢサーバ４００は、呼び出したメソッドで処理（データ登録処理やデータ検索処理等）を実行する。
【００２１】
Ｗｅｂサービス担当ＡＰサーバ２００からＲＭＩサービス担当ＡＰサーバ３００に対して処理の要求を行う際には、バイナリデータで通信が行われる。ＸＭＬデータで通信を行うよりもバイナリデータで通信を行った方が通信データ量が少なくて済むため、Ｗｅｂサービス担当ＡＰサーバ２００、ＲＭＩサービス担当ＡＰサーバ３００間における通信コストを抑えることができる。
【００２２】
図２は、Ｗｅｂサービス担当ＡＰサーバ２００及びＲＭＩサービス担当ＡＰサーバ３００の主要な機能構成を示すブロック図である。
【００２３】
図２に示すように、Ｗｅｂサービス担当ＡＰサーバ２００は、その機能的な構成として、リクエスト受付部２０１、返信部２０２、デシリアライズ部２０３及び処理要求受付部２０４を備える。また、ＲＭＩサービス担当ＡＰサーバ３００は、その機能的な構成として、処理実行部３０１を備える。
【００２４】
リクエスト受付部２０１は、ＸＭＬで記述されたデータ検索要求やデータ登録要求等のリクエストをクライアント端末１００から受け付ける。
【００２５】
返信部２０２は、リクエスト受付部２０１がクライアント端末１００からリクエストを受け付けると、リクエストを受け付けた旨の通知をクライアント端末１００に対して返信する。
【００２６】
デシリアライズ部２０３は、リクエスト受付部２０１によって受け付けたリクエストであるＸＭＬデータをバイナリデータに変換する。
【００２７】
処理要求部２０４は、リクエストに応じた処理のメソッドをＤＢサーバ４００にて呼び出させるための処理をＲＭＩサービス担当サーバ３００に対して要求する。ここでの要求は、デシリアライズ部２０３によってバイナリデータに変換されたリクエストによって行われる。例えば、リクエスト受付部２０１によって受け付けたリクエストがＤＢサーバ４００へのデータ登録であれば、処理要求部２０４は、バイナリデータの当該リクエストをＲＭＩサービス担当ＡＰサーバ３００に送信することにより、対象データの登録処理を実行させるためのメソッドをＤＢサーバ４００に呼び出させることを要求する。また、リクエスト受付部２０１によって受け付けたリクエストがＤＢサーバ４００のデータ検索であれば、処理要求部２０４は、バイナリデータの当該リクエストをＲＭＩサービス担当ＡＰサーバ３００に送信することにより、検索条件に合致するデータを検索させるためのメソッドをＤＢサーバ４００に呼び出させることを要求する。
【００２８】
処理実行部３０１は、処理要求部２０４からの要求に応じたメソッドをＤＢサーバ４００において呼び出させる処理を実行する。
【００２９】
図３は、クライアント端末１００、Ｗｅｂサービス担当ＡＰサーバ２００、ＲＭＩサービス担当ＡＰサーバ３００及びＤＢサーバ４００のハードウェア構成を示すブロック図である。
【００３０】
ＣＰＵ１００１は、システムバスに接続される各デバイスやコントローラを統括的に制御する。ＲＯＭ１００３又はＨＤ（ハードディスク）１００９には、ＣＰＵ１００１の制御プログラムであるＢＩＯＳ（Basic Input / Output System）やオペレーティングシステムプログラム、クライアント端末１００、Ｗｅｂサービス担当ＡＰサーバ２００、ＲＭＩサービス担当ＡＰサーバ３００及びＤＢサーバ４００が実行する例えば図４に示す処理のプログラム等が記憶されている。
【００３１】
なお、図３の例では、ＨＤ１００９は、クライアント端末１００、Ｗｅｂサービス担当ＡＰサーバ２００、ＲＭＩサービス担当ＡＰサーバ３００及びＤＢサーバ４００の内部に配置された構成としているが、他の実施形態としてＨＤ１００９に相当する構成が、クライアント端末１００、Ｗｅｂサービス担当ＡＰサーバ２００、ＲＭＩサービス担当ＡＰサーバ３００及びＤＢサーバ４００の外部に配置された構成としてもよい。また、本実施形態に係る例えば図４に示す処理を行うためのプログラムは、フレキシブルディスク（ＦＤ）やＣＤ−ＲＯＭ等、コンピュータ読み取り可能な記録媒体に記録され、それらの記録媒体から供給される構成としてもよいし、インターネット等の通信媒体を介して供給される構成としてもよい。
【００３２】
ＲＡＭ１００２は、ＣＰＵ１００１の主メモリ、ワークエリア等として機能する。ＣＰＵ１００１は、処理の実行に際して必要なプログラム等をＲＡＭ１００２にロードして、プログラムを実行することで各種動作を実現するものである。
【００３３】
ＨＤ１００９やＦＤ１００８は、外部メモリとして機能する。ＣＰＵ１００１は、処理の実行に際して必要なプログラム等をＲＡＭ１００２にロードして、プログラムを実行することで各種動作を実現するものである。
【００３４】
ディスクコントローラ１００７は、ＨＤ１００９やＦＤ１００８等の外部メモリへのアクセスを制御する。通信Ｉ／Ｆコントローラ１００６は、インターネットやＬＡＮと接続し、例えばＴＣＰ／ＩＰによって外部との通信を制御するものである。
【００３５】
ディスプレイコントローラ１０１０は、ディスプレイ１０１１における画像表示を制御する。
【００３６】
ＫＢコントローラ１００４は、ＫＢ（キーボード）１００５からの操作入力を受け付け、ＣＰＵ１００１に対して送信する。なお、図示していないが、ＫＢ１００５の他に、マウス等のポインティングデバイスもユーザの操作手段として本実施形態に係るクライアント端末１００、Ｗｅｂサービス担当ＡＰサーバ２００、ＲＭＩサービス担当ＡＰサーバ３００及びＤＢサーバ４００に適用可能である。
【００３７】
なお、図２に示すＷｅｂサービス担当ＡＰサーバ２００のリクエスト受付部２０１、返信部２０２、デシリアライズ部２０３及び処理要求部２０４、並びに、ＲＭＩサービス担当ＡＰサーバ３００の処理実行部３０１は、例えばＨＤ１００９内に記憶され、必要に応じてＲＡＭ１００２にロードされるプログラム及びそれを実行するＣＰＵ１００１によって実現される構成である。
【００３８】
図４は、本実施形態に係る情報処理システムの動作の流れを示すシーケンスチャートである。以下、図４を参照しながら、本実施形態に係る情報処理システムの動作について説明する。
【００３９】
先ず、クライアント端末１００は、データ登録要求やデータ検索要求等のリクエストをＷｅｂサービス担当ＡＰサーバ２００に対して発行（送信）する（ステップＳ４０１）。
【００４０】
Ｗｅｂサービス担当ＡＰサーバ２００のリクエスト受付部２０１は、クライアント端末１００から発行されたリクエストを受け付ける（ステップＳ４０２）。
【００４１】
続いて、Ｗｅｂサービス担当ＡＰサーバ２００の返信部２０２は、リクエストを受け付けた旨の通知をクライアント端末１００に返信する（ステップＳ４０３）。
【００４２】
クライアント端末１００は、返信部２０２からの通知を受信する（ステップＳ４０４）。これにより、クライアント端末１００は操作可能な状態に移行する。
【００４３】
Ｗｅｂサービス担当ＡＰサーバ２００のデシリアライズ部２０３は、リクエスト受付部２０１が受け付けたＸＭＬデータのリクエストをバイナリデータに変換する（ステップＳ４０５）。
【００４４】
続いて、Ｗｅｂサービス担当ＡＰサーバ２００の処理要求部２０４は、リクエストに応じた処理のメソッドをＤＢサーバ３００にて呼び出させるための処理をＲＭＩサービス担当ＡＰサーバ３００に対して要求する（ステップＳ４０６）。
【００４５】
ＲＭＩサービス担当ＡＰサーバ３００の処理実行部３０１は、処理要求部２０４からの要求を受け付け（ステップＳ４０７）、当該要求に応じたメソッドをＤＢサーバ４００に呼び出させる（ステップＳ４０８）。例えば、データ検索が要求された場合には、データ検索のためのメソッドをＤＢサーバ４００に呼び出させ、データ登録が要求された場合には、データ登録のためのメソッドをＤＢサーバ４００に呼び出させる。
【００４６】
ＤＢサーバ４００は、呼び出したメソッドによる処理を実行する（ステップＳ４０９）。例えば、データ検索のためのメソッドを呼び出した場合には、呼び出したメソッドによってデータ検索を行い、データ登録のためのメソッドを呼び出した場合には、呼び出したメソッドによってデータ登録を行う。
【００４７】
図５は、ＤＢサーバ４００内で管理されるセッションＩＤ管理テーブルの構成を模式的に示す図である。このセッションＩＤ管理テーブルは、ＤＢサーバ４００のＲＡＭ１００２又はＨＤ１００９内に格納されるものである。
【００４８】
セッションＩＤは、クライアント端末１００がＷｅｂサービスにログインする毎に付与されるＩＤである。図５の例では、４つのセッションＩＤが登録され、セッションＩＤ毎に処理メッセージ項目、処理カウント項目、処理ＭＡＸカウント項目及びステータス項目が管理される。
【００４９】
処理メッセージ項目には、現在の処理状況を示すメッセージが登録され、例えばデータ検索中やデータ登録中等が登録される。
【００５０】
処理カウント項目には、現時点での処理数が登録される。例えば発行したリクエストがデータ登録であり、登録される全てのデータ件数が１０００件あり、現時点でそのうちの５００件が登録されているのであれば"５００"という情報がここに登録される。
【００５１】
処理ＭＡＸカウント項目には、全ての処理数が登録される。例えば上述した例であると、登録される全てのデータ件数１０００件を示す"１０００"という情報がここに登録される。
【００５２】
ステータス項目には、現在の処理状況を示すフラグが登録される。例えば、処理前であれば"０"、処理中であれば"１"、処理後であれば"２"、処理中止であれば"９"がここに登録される。
【００５３】
なお、一度のログインで複数のリクエストが発行されることもある。この場合、一つのセッションＩＤに対応付けて、処理カウント項目には複数のリクエスト分の現時点の処理数が登録され、処理ＭＡＸカウント項目には複数のリクエスト分の全ての処理数が登録されることになる。また、複数のリクエストのうち、データ検索のリクエストに応じた処理が現在実行されていれば、処理メッセージ項目にはデータ検索中が登録される。さらに、複数のリクエストに応じた処理が処理前であれば"０"、処理中であれば"１"、処理後であれば"２"、処理中止であれば"９"がステータス項目に登録される。
【００５４】
上述したセッションＩＤ管理テーブルにおける処理メッセージ項目、処理カウント項目及びステータス項目の登録情報は、処理の進捗に応じて逐次更新される。即ち、セッションＩＤ管理テーブルにおいては、各セッションＩＤに対応付けて処理の進捗状況が管理される。
【００５５】
クライアント端末１００は、Ｗｅｂサービス担当ＡＰサーバ２００及びＲＩＭサービス担当ＡＰサーバ３００、又は、Ｗｅｂサービス担当ＡＰサーバ２００のみを介してＤＢサーバ４００に非同期でアクセスし、対象とするセッションＩＤ、所望の項目を指定することにより、該当するセッションＩＤにおける処理の進捗状況を取得することができる。
【００５６】
図６は、クライアント端末１００がＤＢサーバ４００から処理カウント項目及び処理ＭＡＸカウント項目に登録される情報を取得し、ディスプレイ１０１１上に表示させた例を示す図である。ここでは、クライアント端末１００がＤＢサーバ４００から例えば図５のセッションＩＤ管理テーブルの最上段のレコードに登録されるセッションＩＤの処理カウント項目及び処理ＭＡＸカウント項目に登録される情報を取得した場合について説明する。
【００５７】
取得される情報は、処理カウント項目に登録される"５０"、処理ＭＡＸカウント項目に登録される"１００"であるため、現在の進捗状況は全体の処理数のうちの５０％が処理済みである。従って、図６に示すように、５０％の文字情報の表示とともに、プログレスバーを全体の半分だけ伸ばして表示させ、現在の進捗状況が５０％であることを視覚的に認識しやすいインタフェースが表示される。
【００５８】
以上のように、本実施形態においては、クライアント端末１００から非同期で進捗状況を取得、表示することが可能となる。これにより、ユーザは進捗状況を適宜確認することができ、また、途中で処理をキャンセルすることも可能となる。
【００５９】
このように本実施形態においては、セッションＩＤ管理テーブルをＤＢサーバ４００内で保持するように構成している。ところで、負荷分散等の理由によりＡＰサーバが情報処理システムに増設され、クライアント端末１００のＤＢサーバ４００へのアクセス経路が増設されたＡＰサーバを経由するように変更される場合がある。このような場合、元のアクセス経路上のＡＰサーバ内にセッションＩＤ管理テーブルを備えていた場合、クライアント端末１００は、既に付与されたセッションＩＤに対応する進捗状況を、上記経路変更を契機に取得することができなくなってしまう。これに対し、本実施形態においては、最終的なアクセスポイントであるＤＢサーバ４００にセッションＩＤ管理テーブルを配置した構成としているため、ＡＰサーバの増設等に伴うアクセス経路の変更があった場合でも、既に付与されたセッションＩＤに対応する進捗状況を確実にクライアント端末１００が取得することができる。
【００６０】
なお、図５では、セッションＩＤ毎に進捗情報を管理した状態を示しているが、処理毎に付与されるトランザクションＩＤ毎に進捗情報を管理してもよい。
【００６１】
以上のように、本実施形態において、Ｗｅｂサービス担当ＡＰサーバ２００は、受け付けたリクエストに応じた処理のメソッドをＤＢサーバ４００にて呼び出させるための処理をＲＭＩサービス担当サーバ３００に対して要求するように構成している。従って、Ｗｅｂサービス担当ＡＰサーバ２００の束縛時間を短くし、より早く次のリクエストを受け付け可能な状態に移行させることが可能となる。
【００６２】
また本実施形態において、Ｗｅｂサービス担当ＡＰサーバ２００は、リクエストの受け付けに応じてクライアント端末１００に対してリクエストを受け付けた旨を返信するように構成している。このように迅速にクライアント端末１００に対して通知を行うことで、クライアント端末１００をより早く操作可能な状態に移行させることが可能となる。
【００６３】
本発明の他の実施形態として、ステップＳ４０３とステップＳ４０５の処理順序を入れ替えてもよい。即ち、Ｗｅｂサービス担当ＡＰサーバ２００は、ＸＭＬデータのリクエストをバイナリデータのリクエストに変換した後、リクエストを受け付けた旨の通知をクライアント端末１００に対して行ってもよい。このようにすることで、クライアント端末１００がリクエストに係る通知を受け取った時点には、Ｗｅｂサービス担当ＡＰサーバ２００は確実に解放された状態となり、その後のクライアント端末１００からのリクエストは全て受け付けることが可能となる。
【００６４】
更に、本発明の他の実施形態として、上記実施形態ではクライアント端末１００から送信されるＸＭＬデータをＷｅｂサービス担当ＡＰサーバ２００がバイナリデータに変換してＲＭＩサービス担当ＡＰサーバ３００に渡すという処理を行ったが、本実施形態では、バイナリデータに変換せずにＲＭＩサービス担当ＡＰサーバ３００に渡すという処理を行う。
【００６５】
デシリアライズ処理は、処理コストがかかるため、大規模なデシリアライズ処理が発生すると、サーバの負荷が高まってしまう。特に、Ｗｅｂサービス担当ＡＰサーバ２００は、クライアントからのリクエストを受け付ける役目を果たすため、できるだけ負荷を高めたくないという要求もある。
【００６６】
そこで、クライアント端末１００から送信されるＸＭＬデータのリクエストのデータ量が多い場合、Ｗｅｂサービス担当ＡＰサーバ２００ではバイナリデータに変換せずにＲＭＩサービス担当ＡＰサーバ３００にＸＭＬデータを渡し、ＲＭＩサービス担当ＡＰサーバ３００側でバイナリデータに変換するようにする。ここで、データ量の多いリクエストとは、ひとつのリクエストで、多くのレコード登録の処理を行う場合などが挙げられる。
【００６７】
このような処理をするために、Ｗｅｂサービス担当ＡＰサーバ２００には処理判断基準情報がＲＯＭ１００３又はＨＤ１００９に記憶されている。また、ＲＭＩサービス担当ＡＰサーバ３００は、Ｗｅｂサービス担当ＡＰサーバ２００が備えるのと同様のデシリアライズ部２０３を備えている。
【００６８】
リクエスト受付部２０１は、クライアント端末１００からＸＭＬデータを受信すると、処理判断基準情報を読み出して、受信したＸＭＬデータがこの基準に特定されたサイズを超えていれば、ＸＭＬデータをバイナリデータに変換せずにＲＭＩサービス担当ＡＰサーバ３００に送信する。ＸＭＬデータを受信したＲＭＩサービス担当ＡＰサーバ３００は、まずデシリアライズ部でＸＭＬデータをバイナリデータのリクエストに変換し、続いて、リクエストに応じた処理のメソッドを処理実行部３０１がＤＢサーバ４００に呼び出させる。
【符号の説明】
【００６９】
１００：クライアント端末
２００：Ｗｅｂサービス担当ＡＰサーバ
２０１：リクエスト受付部
２０２：返信部
２０３：デシリアライズ部
２０４：処理要求部
３００：ＲＭＩサービス担当ＡＰサーバ
３０１：処理実行部
４００：ＤＢサーバ
【図１】
2011002909.tif 000003
【図２】
2011002909.tif 000004
【図３】
2011002909.tif 000005
【図４】
2011002909.tif 000006
【図５】
2011002909.tif 000007
【図６】
2011002909.tif 000008