(57)【特許請求の範囲】
【請求項１】
サーバ装置と通信するクライアント装置であって、  使用者の選択操作を受け付けると共に、当該選択操作を受けた状態において入力操作を更に受け付ける少なくとも１つの表示オブジェクトを含むページを画面に表示する表示部と、  表示した当該表示オブジェクトが使用者の前記入力操作を受けたことに応じて、前記サーバ装置に対し処理のリクエストを送信する送信部と、  当該処理のリクエストに応じて前記サーバ装置によって実行される処理の所要時間の見積もりを前記サーバ装置により前記クライアント装置に返信させるリクエストを、前記サーバ装置に送信し、前記所要時間の見積もりを、使用者の前記入力操作に先立って、当該表示オブジェクトが使用者から前記選択操作を受けたことに応じて前記サーバ装置から予め取得する取得部と、  表示した当該表示オブジェクトが使用者の前記選択操作を受けたことに応じて、取得した当該所要時間の見積もりを、当該表示オブジェクトに対応付けて出力する出力部と  を備え、  前記取得部は、何れかの表示オブジェクトが前記選択操作を受ける毎に、前記返信させるリクエストを順次格納する先入れ後出しキューと、前記キューから順次前記返信させるリクエストを取り出して前記サーバ装置に送信するキュー管理部とを有し、  前記キュー管理部は、ある表示オブジェクトについて既に取得した所要時間の見積もりが、より長い場合に、当該所要時間の見積もりがより短い場合と比較して、当該表示オブジェクトについての前記返信させるリクエストをより優先して、前記キューから取り出すクライアント装置。    
【請求項２】
クライアント装置をサーバ装置と通信させる方法であって、  前記クライアント装置に、使用者の選択操作を受け付けると共に、当該選択操作を受けた状態において入力操作を更に受け付ける少なくとも１つの表示オブジェクトを含むページを画面に表示させる表示ステップと、  前記クライアント装置に、表示した当該表示オブジェクトが使用者の前記入力操作を受けたことに応じて、前記サーバ装置に対し処理のリクエストを送信させる送信ステップと、  前記クライアント装置に、当該処理のリクエストに応じて前記サーバ装置によって実行される処理の所要時間の見積もりを前記サーバ装置により前記クライアント装置に返信させるリクエストを、前記サーバ装置に送信し、前記所要時間の見積もりを、使用者の前記入力操作に先立って、当該表示オブジェクトが使用者から前記選択操作を受けたことに応じて前記サーバ装置から予め取得させる取得ステップと、  前記クライアント装置に、表示した当該表示オブジェクトが使用者の前記選択操作を受けたことに応じて、取得した当該所要時間の見積もりを、当該表示オブジェクトに対応付けて出力させる出力ステップと  を備え、  前記取得ステップは、何れかの表示オブジェクトが前記選択操作を受ける毎に、前記返信させるリクエストを順次格納する先入れ後出しステップと、前記先入れ後出しステップから順次前記返信させるリクエストを取り出して前記サーバ装置に送信するキュー管理ステップとを有し、  前記キュー管理ステップは、ある表示オブジェクトについて既に取得した所要時間の見積もりが、より長い場合に、当該所要時間の見積もりがより短い場合と比較して、当該表示オブジェクトについての前記返信させるリクエストをより優先して、前記先入れ後出しステップから取り出す方法。    
【請求項３】
コンピュータを、サーバ装置と通信する請求項１に記載のクライアント装置として機能させるプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、クライアント装置がサーバ装置と通信する技術に関する。特に、本発明は、クライアント装置がサーバ装置に対し処理をリクエストする技術に関する。
【背景技術】
【０００２】
近年、例えばＪ２ＥＥ（Java 2 Enterprise Edition）などの普及によって、ウェブ・アプリケーションシステムが広く用いられるようになってきている（非特許文献１を参照。）。ウェブ・アプリケーションシステムは、同時に多数のクライアント装置からのリクエストを処理できるように設計されている場合が多い。しかしながら、同時に処理するリクエストが多すぎると、処理に時間がかかりすぎてしまう。この結果、クライアント装置の使用者の待ち時間を増加させたり、使用者の利便性を低下させたりしてしまう場合がある。
【非特許文献１】Ｊａｖａ  ＥＥ  ＆  Ｗｅｂ  サービスの説明。インターネット、ＵＲＬ「http://sdc.sun.co.jp/java/j2ee/index.html」、２００７年１１月２８日検索。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
これに対し、システムの開発に際しては、多数のリクエストを効率的に処理させるための様々な技術が用いられている。例えば、受信したリクエストを、キュー型のデータ領域に一時的に蓄える技術がその一例である。他の処理が終了するなどしてサーバ・コンピュータの負荷が低下した場合には、ウェブ・アプリケーションシステムはそのデータ領域から次のリクエストを取得して処理する。このような制御により、サーバ・コンピュータの負荷を適切な水準に維持して、処理の所要時間を短縮できる。
【０００４】
一方、受信するリクエストの中には、使用者にとって重要度が低いものが含まれる場合がある。その場合、使用者は、処理完了までの待ち時間が長すぎるならば、そのようなリクエストをそもそも送信したくないかも知れない。上記技術では、既に受信したリクエストを全て処理することを前提としているため、そのような不要なリクエストであっても、他の重要なリクエストと共に処理しようとしていた。
【０００５】
このように、これまでの技術では、既に受信したリクエストを全て処理することを前提としており、そもそもあまり必要でないリクエストの送信を抑制することはできない。例えば、使用者は、送信しようとしているリクエストがどの程度の負荷をサーバ装置に与えるか、あるいは、現在のサーバ装置の負荷などを予め知ることはできないので、そのリクエストを送信すべきか否かを判断できなかった。
【０００６】
そこで本発明は、上記の課題を解決することのできるクライアント装置、サーバ装置、方法およびプログラムを提供することを目的とする。この目的は特許請求の範囲における独立項に記載の特徴の組み合わせにより達成される。また従属項は本発明の更なる有利な具体例を規定する。
【課題を解決するための手段】
【０００７】
上記課題を解決するために、本発明の第１の形態においては、サーバ装置と通信するクライアント装置であって、使用者の選択操作を受け付けると共に、当該選択操作を受けた状態において入力操作を更に受け付ける少なくとも１つの表示オブジェクトを含むページを画面に表示する表示部と、表示した当該表示オブジェクトが使用者の前記入力操作を受けたことに応じて、前記サーバ装置に対し処理のリクエストを送信する送信部と、当該処理のリクエストに応じて前記サーバ装置によって実行される処理の所要時間の見積もりを、使用者の前記入力操作に先立って予め取得する取得部と、表示した当該表示オブジェクトが使用者の前記選択操作を受けたことに応じて、取得した当該所要時間の見積もりを、前記取得部が取得してから予め定められた基準時間が経過していないことを条件に当該表示オブジェクトに対応付けて出力し、前記取得部が取得してから前記基準時間が経過した場合には出力しない出力部とを備えるクライアント装置を提供する。また、当該クライアント装置としてコンピュータを機能させる方法およびプログラムを提供する。
【０００８】
また、本発明の第２の形態においては、クライアント装置と通信するサーバ装置であって、記憶装置と、前記クライアント装置からリクエストされた処理の所要時間を計測し、計測した当該処理の所要時間を、当該処理が属するグループの識別情報に対応付けて前記記憶装置に格納する計測部と、前記クライアント装置から、処理の所要時間の見積もりを返信するリクエストを受けたことに応じて、当該処理が属するグループの識別情報に対応する所要時間を前記記憶装置から読み出して、読み出した当該所要時間に基づく情報を前記クライアント装置に返信する返信部とを備えるサーバ装置を提供する。また、当該サーバ装置としてコンピュータを機能させる方法およびプログラムを提供する。
なお、上記の発明の概要は、本発明の必要な特徴の全てを列挙したものではなく、これらの特徴群のサブコンビネーションもまた、発明となりうる。
【発明を実施するための最良の形態】
【０００９】
以下、発明の実施の形態を通じて本発明を説明するが、以下の実施形態は特許請求の範囲にかかる発明を限定するものではなく、また実施形態の中で説明されている特徴の組み合わせの全てが発明の解決手段に必須であるとは限らない。
【００１０】
図１は、本実施形態に係る情報システム１０の全体構成を示す。情報システム１０は、サーバ装置１００と、複数のクライアント装置２００（例えばクライアント装置２００−１〜Ｎ）とを備える。サーバ装置１００は、基本的なハードウェアとして、例えばネットワーク・インターフェイス・カードなどの通信インターフェイス１０２と、例えばハードディスクドライブなどの記憶装置１０４とを有する。そして、サーバ装置１００は、記憶装置１０４から読み出したプログラムをＣＰＵにより実行することで、ウェブサーバ１０６として機能する。
【００１１】
クライアント装置２００−１は、基本的なハードウェアとして、例えばネットワーク・インターフェイス・カードなどの通信インターフェイス２０２と、例えばハードディスクドライブなどの記憶装置２０４と、例えば表示デバイス・入力デバイスなどのユーザインターフェイス２０８とを有する。そして、クライアント装置２００−１は、記憶装置２０４から読み出したプログラムをＣＰＵにより実行することで、ウェブブラウザ２０６として機能する。なお、クライアント装置２００−２〜Ｎのそれぞれはクライアント装置２００−１と略同一であるから、以降相違点を除き説明を省略する。
【００１２】
また、サーバ装置１００は、通信ネットワーク１５を介してクライアント装置２００−１〜Ｎのそれぞれに接続している。通信ネットワーク１５は、例えばインターネットなどの公衆の通信回線であってもよいし、例えば企業内ネットワークなどのプライベートな通信回線であってもよい。ウェブサーバ１０６は、この通信ネットワーク１５を介して、クライアント装置２００−１〜Ｎのそれぞれにおいて動作するウェブブラウザ２０６と通信する。具体的には、ウェブブラウザ２０６は、処理のリクエストをウェブサーバ１０６に対し送信する。ウェブサーバ１０６は、そのリクエストに応じた処理を実行して、その実行結果をレスポンスとしてウェブブラウザ２０６に返信する。
【００１３】
ウェブサーバ１０６が同時期に多数のウェブブラウザ２０６からリクエストを受信した場合においては、ウェブサーバ１０６における処理の時間がかかり過ぎてしまう場合がある。これに対し、本実施形態に係る情報システム１０においては、クライアント装置２００−１〜Ｎの使用者に対し、処理の所要時間の見積もりを予め通知することで、リクエストの送信の抑制を図る。その一例を図２に示す。
【００１４】
図２は、本実施形態に係るユーザインターフェイス２０８により表示される画面の一例を示す。（ａ）に、あるウェブページの一例を示す。このウェブページは、表示オブジェクトとして、「キーワードを入力して提出ボタンを押して下さい」という文字列、キーワードの入力欄、および、提出ボタンを含む。図２（ａ）の例では、入力欄には「ＡＢＣＤ」というキーワードが既に入力されている。この状態において、マウスなどの入力装置により提出ボタンがクリックされると、「ＡＢＣＤ」というキーワードがクライアント装置２００−１からサーバ装置１００へのリクエストに含めて送信される。これを受けてウェブサーバ１０６による処理が開始される。
【００１５】
図２（ｂ）は、そのウェブページの提出ボタンに、マウスなどのカーソルのフォーカスが当てられた状態を示す。提出ボタンにフォーカスが当てられると、ウェブブラウザ２０６は、その提出ボタンがクリックされたことに応じてウェブサーバ１０６により実行される処理の所要時間の見積もりを表示する。ここでは、例えばツールチップなどの中に、所要時間の見積もりを示すシンボル、具体的には時間を示す数値などが表示されている。
【００１６】
このように、使用者は提出ボタンを実際にクリックしなくても、その提出ボタンにフォーカスを当てることで、それをクリックしたならば処理に費やされるであろう所要時間を予め知ることができる。これにより、例えば重要でない処理の所要時間が長すぎる場合には、使用者の判断でリクエストそれ自体の送信を取り止めることが期待される。この結果、ウェブサーバ１０６は真に必要な処理のみを効率的に実行できる。以降、これを実現する構成について説明をすすめる。
【００１７】
図３は、本実施形態に係るウェブブラウザ２０６の機能構成をユーザインターフェイス２０８と併せて示す。ウェブブラウザ２０６は、受信部３００と、表示部３１０と、送信部３７０とを有する。受信部３００は、表示部３１０に表示するべきページを示すファイルをサーバ装置１００から受信する。このファイルは、例えば、既に送信部３７０により送信されたリクエストに対するレスポンスとしてサーバ装置１００から返信されるものである（１）。
【００１８】
具体的には、このファイルは、ページに含めて表示するべき少なくとも１つの表示オブジェクトを示す。表示オブジェクトは、例えば文字列または画像などの他、使用者の操作を受け付けるためのボタン、ハイパーリンクまたはプルダウンメニューなどであってよい。この表示オブジェクトは、使用者の選択操作を受け付けると共に、当該選択操作を受け付けた状態において入力操作を更に受け付ける。
【００１９】
選択操作とは、例えば、ポインティング・デバイスのカーソルをその表示オブジェクトに重ねてフォーカスを当てる操作である。これに代えて、選択操作とは、キーボードの方向キーやタブキーによってカーソルをその表示オブジェクトに合わせる操作であってよい。一方、入力操作とは、ポインティング・デバイスによりその表示オブジェクトをクリックする操作である。これに代えて、入力操作とは、キーボードのエンターキーを押下する操作であってよい。
【００２０】
一例として、これらの表示オブジェクトは、ＨＴＭＬ（Ｈｙｐｅｒｔｅｘｔ  Ｍａｒｋ−ｕｐ  Ｌａｎｇｕａｇｅ）などのページ記述言語、および、ＪａｖａＳｃｒｉｐｔなどのプログラム言語で定義されていてよい。なお、表示オブジェクトによっては、単にシンボルを表示するだけであって、使用者の操作を受け付けなくてよい。
【００２１】
表示部３１０は、受信したそのファイルに基づいて、少なくとも１つの表示オブジェクトを含むページを表示デバイス３２０の画面３２５に表示する。また、ウェブブラウザ２０６は、そのファイル中のプログラムを実行することにより制御システム３０として機能する。制御システム３０は、取得部３３０と、出力部３５０とを有する。取得部３３０は、送信部３７０が送信する処理のリクエストに応じてサーバ装置１００によって実行される処理の所要時間の見積もりを、使用者の入力操作に先立って予め取得する。
【００２２】
その一例として、取得部３３０は、所要時間の見積もりを、受信部３００により受信されたファイルに含めてサーバ装置１００から取得してよい。これに代えて、取得部３３０は、所要時間の見積もりをサーバ装置１００によりクライアント装置２００−１に返信させるリクエストを、送信部３７０に指示してサーバ装置１００に対し送信してよい（２）。これに対し、受信部３００は、サーバ装置１００から所要時間の見積もりを受信する（３）。取得部３３０は、このようにして所要時間の見積もりを取得して、出力部３５０に対し出力する。
【００２３】
所要時間の見積もりは、サーバ装置１００によって予め生成されたものであってよい。例えば、所要時間の見積もりは、既にサーバ装置１００により実行された処理について計測された所要時間の履歴に基づく統計的な量でよい。例えば、所要時間の見積もりは、既に実行された処理の所要時間の平均値であってよいし、所定期間内における処理の所要時間の中央値または最大値であってもよい。好ましくは、所要時間の見積もりは、新たに送信しようとしているリクエストに応じた処理と同種類の、過去の処理の所要時間に基づいて算出されてよい。
【００２４】
出力部３５０は、表示したその表示オブジェクトが使用者の選択操作を受けたことに応じて、その表示オブジェクトに対応付けて、取得したその所要時間の見積もりを出力する。例えば、出力部３５０は、その所要時間の見積もりを示す音声を音声デバイス３６０により出力させてよい。この場合、所要時間の長さは、例えば音の高さ、音の大きさまたは音色などに反映されてよい。これに代えて、出力部３５０は、表示したその表示オブジェクトに対応付けて、その表示オブジェクトについて取得した所要時間の見積もりを示すシンボルを画面３２５に表示してよい。
【００２５】
なお、所要時間の見積もりとは、必ずしも、所要時間それ自体を示す数値情報に限定されない。例えば、所要時間の見積もりとは、所要時間が所定の基準値よりも長いかまたは短いかを区別する情報であってもよい。また、所要時間の見積もりとは、サーバ装置１００の処理負荷の大きさを示す数値であってよい。一般に、処理負荷が大きければ所要時間が長くなることから、処理負荷の大きさは所要時間の見積もりを示すこととなるからである。
【００２６】
更に他の例として、出力部３５０は、その表示オブジェクトの色彩または形状を、その所要時間の見積もりを識別可能なように変更して、画面３２５に表示させることで、所要時間の見積もりを出力してよい。例えば、所要時間の長い表示オブジェクトを、赤などの目立ち易い色彩で着色してよい。また、画面３２５は、所要時間の長い表示オブジェクトに縁取りを付して表示してよい。形状の変更には、大きさの変更も含まれる。例えば、画面３２５は、所要時間の短い表示オブジェクトを他の表示オブジェクトと比較して大きく表示してもよい。
【００２７】
送信部３７０は、当該表示オブジェクトが使用者の入力操作を受けたことに応じて、サーバ装置１００に処理のリクエストを送信する（４）。これを受けて、クライアント装置２００においてはウェブブラウザ２０６の処理が開始される。処理の完了までには、予め通知されていた所要時間の見積もりと同程度の時間がかかることが予想される。
【００２８】
ここで、見積もりの精度を高めるためには、サーバ装置１００の状態変化に追従して所要時間の見積もりを変更することが好ましい。例えば、取得部３３０が定期的に所要時間をリクエストすれば、そのような状態変化に追従できる。また、取得部３３０は、選択操作を受けた表示オブジェクトのみについて、選択操作を受けたことを条件に所要時間の見積もりを取得すれば、最新の状態の所要時間を取得できる。
【００２９】
一方で、選択操作を受けた表示オブジェクトの全てについて所要時間をリクエストしようとすれば、使用者が選択操作を繰り返した結果、多数のリクエストが送信され、通信ネットワーク１５の負荷を必要以上に増加させてしまう。これに対し、取得部３３０は、ウェブページ中の全ての表示オブジェクトではなく予め定められた一部の表示オブジェクトのみについて、その表示オブジェクトが選択操作を受けたことを条件にリクエストを送信してもよい。
【００３０】
また、他の例として、取得部３３０は、キュー３３２およびキュー管理部３３５を有することで、そのような過剰なリクエストの送信を防止してよい。具体的には、キュー３３２は、先入れ後出しキューであり、何れかの表示オブジェクトが選択操作を受ける毎に、見積もりを返信させるリクエストを順次格納する。そして、キュー管理部３３５は、選択操作を受けたタイミングに関わらず、例えば定期的に、キューから順次そのリクエストを取り出してサーバ装置１００に送信する。これにより、選択操作を一時期に頻繁に受けすぎたことによる過剰なリクエストの送信を防止できる。
【００３１】
図４は、本実施形態に係るウェブサーバ１０６の機能構成を示す。ウェブサーバ１０６は、ＨＴＴＰサーバ４０と、アプリケーション・サーバ４５とを有する。ＨＴＴＰサーバ４０は、例えばＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）などに準拠したリクエストをクライアント装置２００−１〜Ｎから受信する。また、ＨＴＴＰサーバ４０は、そのリクエストに応じたアプリケーション・サーバ４５による処理の結果をレスポンスとしてクライアント装置２００−１〜Ｎに返信する。
【００３２】
アプリケーション・サーバ４５は、計測部４００と、サービス部４１０と、返信部４２０とを有する。計測部４００は、クライアント装置２００−１〜Ｎのそれぞれから処理のリクエストを受け付ける。ここでは例えばクライアント装置２００−１からリクエストを受け付けたことを前提に説明をすすめる。そして、サービス部４１０は、そのリクエストに応じて処理を実行する。具体例として、サービス部４１０は、たとえばウェブサービスなどを処理するためのアプリケーション・プログラムであってよく、一例としてそのプログラムはＪ２ＥＥによって開発されたものであってよい。処理の結果は、例えばＨＴＭＬのページなどのデータとして、レスポンスに含めてクライアント装置２００−１に返信される。
【００３３】
計測部４００は、リクエストされたその処理の所要時間を計測して、当該処理の所要時間を、当該処理の識別情報に対応付けて記憶装置１０４に格納する。所要時間の計算は、具体的には、サーブレットフィルタなどのような、処理の開始および／または終了時において仮想機械の機能により自動的に呼び出されるメソッドにより実現されてよい。一例として、処理の終了時刻から開始時刻を引き算すれば、処理の所要時間を算出できる。
【００３４】
さらに、計測部４００は、当該処理の所要時間を、当該処理の属するグループの識別情報に対応付けて記憶装置１０４に格納してもよい。その一例を図５に示す。
図５は、本実施形態に係る記憶装置１０４のデータ構造の具体例を示す。記憶装置１０４は、処理の識別情報を、その処理が属するグループの識別情報、その処理の回数の履歴、および、その処理の所要時間の合計に対応付けて記憶している。計測部４００は、新たに処理が完了する毎に、その処理の識別情報およびその処理の属するグループの識別情報に対応するレコードの、処理の回数をインクリメントする。また、計測部４００は、当該レコードの所要時間の合計に、当該新たな処理について計測した所要時間を加算する。
【００３５】
ここで、ある処理が属するグループは、例えば、その処理の性質に応じて定められていてよい。その処理の性質とは、例えば、主としてＣＰＵの処理力を集中的に使用するか、または、主としてファイル入出力の機能を集中的に使用するか、などである。これに代えて、ある処理が属するグループは、例えば、その処理を要求したクライアント装置２００の性能に応じて定められていてよい。サーバ装置１００の状態が同一であっても、クライアント装置２００の性能によって処理の完了までの使用者の待ち時間は異なる場合がある。このような場合には、処理の所要時間をクライアント装置２００の性能に基づいてグループ化することで、所要時間の精度を更に高めることができる。
【００３６】
更に他の例として、グループは、その処理を要求した使用者が属するグループを示してもよい。具体例として、グループの識別情報「３０４」は、高い利用料の支払などを条件に優遇された使用者のグループを示す。一方、グループの識別情報「３０２」は、優遇されていない使用者のグループを示す。サービス部４１０の機能によれば、使用者がどちらのグループに属するかによって、要求される処理の実行優先度を異ならせることができる。そのような場合には、処理の所要時間も使用者のグループに応じて大きく異なる場合がある。このような場合に備えて、記憶装置１０４は、処理を要求する使用者の属するグループごとに、所要時間の履歴を記憶してもよい。この場合には、返信部４２０は、使用者の属するグループの識別情報、および、要求される処理の識別情報の組に対応するレコードを記憶装置１０４から検索して、そのレコードに基づいて所要時間の見積もりを算出してよい。
【００３７】
図４の説明に戻る。返信部４２０は、クライアント装置２００−１〜Ｎから、処理の所要時間の見積もりを返信するリクエストを受け付ける。ここでは、クライアント装置２００−１からそのリクエストを受け付けたものとして説明をすすめる。そのリクエストを受けたことに応じて、返信部４２０は、当該処理の識別情報に対応する所要時間を記憶装置１０４から読み出して、読み出した当該所要時間に基づく情報を、そのリクエストに対するレスポンスとしてクライアント装置２００−１に返信する。当該所要時間に基づく情報とは、上述のように、例えば、所要時間の平均値などであってよい。
【００３８】
なお、返信部４２０は、所要時間の見積もりを、ウェブページに含めて返信させるべく、サービス部４１０に対し通知してよい。これにより、サービス部４１０は、処理結果などを示すレスポンスに含めて、その処理時間の見積もりを返信できる。
【００３９】
さらに、返信部４２０は、常にサーバ装置１００の状態変化に敏感に追従させるため、記憶装置１０４に記憶された所要時間を定期的にクリアしてもよい。また、返信部４２０は、記憶装置１０４の各レコードに最終更新時刻を対応付けて記憶させておき、その最終更新時刻から現在時刻までが所定期間よりも長い場合には、そのレコードを記憶装置１０４から削除してよい。
【００４０】
以上、図４および図５を参照して説明したように、ウェブサーバ１０６は、各処理の所要時間の情報をリアルタイムに順次更新しているので、所要時間の返信のリクエストを受けると最新の所要時間の情報を直ちに返信できる。これにより、クライアント装置２００−１〜Ｎの使用者はサーバ装置１００の状態を精度良く把握して、リクエスト送信の可否を適切に判断できる。
【００４１】
図６は、本実施形態に係るサーバ装置１００およびクライアント装置２００の処理の流れの第１例を示す。この第１例においては、各表示オブジェクトについての処理の所要時間の見積もりは、サーバ装置１００から定期的に取得される。そして、表示オブジェクトが選択操作を受けたことに応じて、その見積もりが出力される。
【００４２】
具体的には、まず、返信部４２０は、既に受けていたリクエストに応じて、例えばウェブページなどのデータを含むファイルをクライアント装置２００−１に対し送信する（Ｓ７００）。このファイルには、各表示オブジェクトに対応して、処理の所要時間の見積もりが対応付けて記録されていてよい。
【００４３】
受信部３００は、ウェブページなどのデータを含むそのファイルをサーバ装置１００から受信する（Ｓ７１０）。表示部３１０は、そのファイルに基づいて、そのウェブページを画面３２５に表示する（Ｓ７２０）。取得部３３０は、ページが表示されてから、または、前回に同様の判断をしてから、予め定められた期間が経過したかどうかを判断する（Ｓ７３０）。
【００４４】
当該期間が経過したことを条件に（Ｓ７３０：ＹＥＳ）、取得部３３０は、表示している予め定められた表示オブジェクトについて、当該表示オブジェクトが入力操作を受けたことに応じて実行される処理の所要時間の見積もりを、サーバ装置１００から取得する（Ｓ７４０）。具体的には、そのような見積もりを返信させる旨のリクエストを、取得部３３０がサーバ装置１００に対し送信してよい。これを受けて、返信部４２０は、所要時間の見積もりを記憶装置１０４から読み出して返信する（Ｓ７５０）。
【００４５】
次に、出力部３５０は、表示した何れかの表示オブジェクトが使用者の選択操作を受けたか否かを判断する（Ｓ７６０）。そのような選択操作を受けたことに応じて（Ｓ７６０：ＹＥＳ）、出力部３５０は、その表示オブジェクトに対応付けて、取得したその所要時間の見積もりを出力する（Ｓ７７０）。
【００４６】
出力の頻度が高くなって使用者の操作の妨げになることを防ぐため、操作から出力までにはある程度の遅延時間を設けることが望ましい。例えば、出力部３５０は、表示した当該表示オブジェクトが使用者の選択操作を受け始めてから、選択操作を受け続けたまま予め定められた継続時間が経過したことを条件に、取得した当該所要時間の見積もりを出力してよい。
【００４７】
次に、送信部３７０は、当該表示オブジェクトが使用者の入力操作を受けたかどうかを判断する（Ｓ７８０）。入力操作を受けていなければ（Ｓ７８０：ＮＯ）、クライアント装置２００−１はＳ７３０に処理を戻して、所定時間が経過したかどうかを判断する。一方、入力操作を受けたことに応じて（Ｓ７８０）、サーバ装置１００に処理のリクエストを送信する（Ｓ７９０）。
【００４８】
これを受けて、サーバ装置１００においてはウェブサーバ１０６の処理が開始される（Ｓ７９５）。また、クライアント装置２００においては計測部４００により処理の所要時間が計測される。この結果Ｓ７００に処理が戻り、次のページがサーバ装置１００からクライアント装置２００−１に送信される。
【００４９】
以上、この第１例によれば、所要時間の見積もりは選択操作の毎ではなく所定の時間間隔で取得されるので、選択操作を高頻度で受けたとしてもサーバ装置１００およびクライアント装置２００−１間の通信量を一定にすることができる。
【００５０】
図７は、本実施形態に係るサーバ装置１００およびクライアント装置２００の処理の流れの第２例を示す。この第２例においては、一律に所定の表示オブジェクト全てについて所要時間が取得されるのではなく、選択操作を受けた表示オブジェクトについてのみ、その選択操作を受けることを条件として、所要時間の見積もりが取得される。
【００５１】
具体的には、まず、返信部４２０は、既に受けていたリクエストに応じて、例えばウェブページなどのデータを含むファイルをクライアント装置２００−１に対し送信する（Ｓ８００）。受信部３００は、ウェブページなどのデータを含むそのファイルをサーバ装置１００から受信する（Ｓ８１０）。表示部３１０は、そのファイルに基づいて、そのウェブページを画面３２５に表示する（Ｓ８２０）。
【００５２】
次に、取得部３３０は、表示した何れかの表示オブジェクトが使用者の選択操作を受けたか否かを判断する（Ｓ８３０）。選択操作を受けたことを条件に（Ｓ８３０：ＹＥＳ）、キュー３３２は、その選択操作を受けた表示オブジェクトについて、その表示オブジェクトに対応するリクエストを格納する（Ｓ８４０）。このリクエストは、その表示オブジェクトが入力操作を受けたことに応じて実行される処理の所要時間の見積もりを返信させるためのリクエストである。格納されたリクエストは、例えば後述のＳ８７５において、選択操作とは非同期的に処理される。
【００５３】
次に、出力部３５０は、当該リクエストに応じて所要時間の見積もりが既に取得されたかどうかを判断する（Ｓ８５０）。既に取得されている場合には（Ｓ８５０：ＹＥＳ）、出力部３５０は、その所要時間の見積もりを出力する（Ｓ８６０）。但し、古すぎる情報の出力を防止するため、好ましくは、出力部３５０は、取得した当該所要時間の見積もりを、取得部３３０が取得してから予め定められた基準時間が経過していないことを条件に出力し、取得部３３０が取得してから基準時間が経過した場合には出力しない。
【００５４】
一方、まだ取得されていない場合、即ち、取得部３３０が所要時間の見積もりをサーバ装置１００から取得する処理を開始してから終了するまでの間は、出力部３５０は、取得部３３０が所要時間の見積もりを取得中である旨を出力する（Ｓ８７０）。
【００５５】
次に、キュー管理部３３５は、選択操作を受けたタイミングに関わらず、例えば定期的に、キューから順次そのリクエストを取り出してサーバ装置１００に送信する（Ｓ８７５）。リクエストを取り出す順序は、原則として、キュー３３２に格納された順序の逆順（ＬＩＦＯ：Ｌａｓｔ  Ｉｎ  Ｆｉｒｓｔ  Ｏｕｔ）であることが望ましい。但し、有用な情報を優先して取得するという観点から、順序を入れ替えてもよい。
【００５６】
例えば、キュー管理部３３５は、ある表示オブジェクトについて既に取得した所要時間の見積もりが、より長い場合に、当該所要時間の見積もりがより短い場合と比較して、当該表示オブジェクトについての当該返信させるリクエストをより優先して、キュー３３２から取り出してよい。これを実現するためには、キュー３３２が、各リクエストに対応付けて、前回にそれと同一のリクエストに応じて返信された所要時間を格納しておけばよい。このように制御することで、所要時間の見積もりが長いために使用者がその見積もり時間が短くなるのを待っており、その見積もり時間が注目を集めている状況においては、その所要時間の見積もりをより頻繁に更新できる。
【００５７】
次に、送信部３７０は、当該表示オブジェクトが使用者の入力操作を受けたかどうかを判断する（Ｓ８８５）。入力操作を受けていなければ（Ｓ８８５：ＮＯ）、クライアント装置２００−１はＳ８３０に処理を戻して、選択操作を受けたか否かを判断する。入力操作を受けたことに応じて（Ｓ８８５：ＹＥＳ）、送信部３７０は、サーバ装置１００に処理のリクエストを送信する（Ｓ８９０）。
【００５８】
これを受けて、サーバ装置１００においてはウェブサーバ１０６の処理が開始される（Ｓ８９５）。また、クライアント装置２００においては計測部４００により処理の所要時間が計測される。この結果Ｓ８００に処理が戻り、次のページがサーバ装置１００からクライアント装置２００−１に送信される。
【００５９】
以上、この第２例によれば、所要時間の見積もりは選択操作を受けた表示オブジェクトに限って取得されるので、サーバ装置１００およびクライアント装置２００−１間の通信量を低減できる。さらに、キュー３３２を用いることで、選択操作を頻繁に受けることによりリクエストが高頻度で送信されることを防ぐことができる。
【００６０】
図８は、本実施形態に係るサーバ装置１００またはクライアント装置２００−１として機能するコンピュータのハードウェア構成の一例を示す。コンピュータは、ホストコントローラ１０８２により相互に接続されるＣＰＵ１０００、ＲＡＭ１０２０、及びグラフィックコントローラ１０７５を有するＣＰＵ周辺部と、入出力コントローラ１０８４によりホストコントローラ１０８２に接続される通信インターフェイス１０３０、ハードディスクドライブ１０４０、及びＣＤ−ＲＯＭドライブ１０６０を有する入出力部と、入出力コントローラ１０８４に接続されるＲＯＭ１０１０、フレキシブルディスクドライブ１０５０、及び入出力チップ１０７０を有するレガシー入出力部とを備える。
【００６１】
ホストコントローラ１０８２は、ＲＡＭ１０２０と、高い転送レートでＲＡＭ１０２０をアクセスするＣＰＵ１０００及びグラフィックコントローラ１０７５とを接続する。ＣＰＵ１０００は、ＲＯＭ１０１０及びＲＡＭ１０２０に格納されたプログラムに基づいて動作し、各部の制御を行う。グラフィックコントローラ１０７５は、ＣＰＵ１０００等がＲＡＭ１０２０内に設けたフレームバッファ上に生成する画像データを取得し、表示デバイス３２０上に表示させる。これに代えて、グラフィックコントローラ１０７５は、ＣＰＵ１０００等が生成する画像データを格納するフレームバッファを、内部に含んでもよい。
【００６２】
入出力コントローラ１０８４は、ホストコントローラ１０８２と、比較的高速な入出力装置である通信インターフェイス１０３０、ハードディスクドライブ１０４０、及びＣＤ−ＲＯＭドライブ１０６０を接続する。通信インターフェイス１０３０は、例えば通信インターフェイス１０２または通信インターフェイス２０２などの一例であり、ネットワークを介して外部の装置と通信する。ハードディスクドライブ１０４０は、例えば記憶装置１０４または記憶装置２０４などの一例であり、コンピュータが使用するプログラム及びデータを格納する。ＣＤ−ＲＯＭドライブ１０６０は、ＣＤ−ＲＯＭ１０９５からプログラム又はデータを読み取り、ＲＡＭ１０２０又はハードディスクドライブ１０４０に提供する。
【００６３】
また、入出力コントローラ１０８４には、ＲＯＭ１０１０と、フレキシブルディスクドライブ１０５０や入出力チップ１０７０等の比較的低速な入出力装置とが接続される。ＲＯＭ１０１０は、コンピュータの起動時にＣＰＵ１０００が実行するブートプログラムや、コンピュータのハードウェアに依存するプログラム等を格納する。フレキシブルディスクドライブ１０５０は、フレキシブルディスク１０９０からプログラム又はデータを読み取り、入出力チップ１０７０を介してＲＡＭ１０２０またはハードディスクドライブ１０４０に提供する。入出力チップ１０７０は、例えば音声デバイス３６０に作用して音声を出力させる。また、入出力チップ１０７０は、フレキシブルディスク１０９０や、例えばパラレルポート、シリアルポート、キーボードポート、マウスポート等を介して各種の入力デバイス３４０を接続する。
【００６４】
コンピュータに提供されるプログラムは、フレキシブルディスク１０９０、ＣＤ−ＲＯＭ１０９５、又はＩＣカード等の記録媒体に格納されて利用者によって提供される。プログラムは、入出力チップ１０７０及び/又は入出力コントローラ１０８４を介して、記録媒体から読み出されコンピュータにインストールされて実行される。プログラムがコンピュータ等に働きかけて行わせる動作は、図１から図７において説明したサーバ装置１００またはクライアント装置２００−１における動作と同一であるから、説明を省略する。
【００６５】
以上に示したプログラムは、外部の記憶媒体に格納されてもよい。記憶媒体としては、フレキシブルディスク１０９０、ＣＤ−ＲＯＭ１０９５の他に、ＤＶＤやＰＤ等の光学記録媒体、ＭＤ等の光磁気記録媒体、テープ媒体、ＩＣカード等の半導体メモリ等を用いることができる。また、専用通信ネットワークやインターネットに接続されたサーバシステムに設けたハードディスク又はＲＡＭ等の記憶装置を記録媒体として使用し、ネットワークを介してプログラムをコンピュータに提供してもよい。
【００６６】
以上、本実施形態に係る情報システム１０によれば、クライアント装置２００の使用者は処理の所要時間を予め把握できるので、重要度の低い不要なリクエストの送信を控え、また、サーバ装置１００の処理負荷が高すぎる場合にはリクエストの送信を遅らせるなどの判断をすることができる。この結果、例えば反応が遅くて待ちきれずに、何度も同じリクエストを送信してしまうなど、負荷が増加した場合に生じる悪循環を未然に防止して、サーバ装置１００を効率的に動作させることができる。更に、本実施形態に係る技術は、多数の処理をサーバ装置１００により効率的に実行させるような既存技術の置き換えとしてのみではなく、そのような既存技術と組み合わせて使用することもできる。
【００６７】
以上、本発明を実施の形態を用いて説明したが、本発明の技術的範囲は上記実施の形態に記載の範囲には限定されない。上記実施の形態に、多様な変更または改良を加えることが可能であることが当業者に明らかである。例えば、所要時間の見積もりは、ウェブページとは別の画面に表示されてよい。一例として、例えばヒートマップなどのように、所要時間の見積もりを示す色パネルを、表示オブジェクトの配列順と同じ順序で配列した画面が表示されてもよい。その様な変更または改良を加えた形態も本発明の技術的範囲に含まれ得ることが、特許請求の範囲の記載から明らかである。
【図面の簡単な説明】
【００６８】
【図１】図１は、本実施形態に係る情報システム１０の全体構成を示す。
【図２】図２は、本実施形態に係るユーザインターフェイス２０８により表示される画面の一例を示す。
【図３】図３は、本実施形態に係るウェブブラウザ２０６の機能構成をユーザインターフェイス２０８と併せて示す。
【図４】図４は、本実施形態に係るウェブサーバ１０６の機能構成を示す。
【図５】図５は、本実施形態に係る記憶装置１０４のデータ構造の具体例を示す。
【図６】図６は、本実施形態に係るサーバ装置１００およびクライアント装置２００の処理の流れの第１例を示す。
【図７】図７は、本実施形態に係るサーバ装置１００およびクライアント装置２００の処理の流れの第２例を示す。
【図８】図８は、本実施形態に係るサーバ装置１００またはクライアント装置２００として機能するコンピュータのハードウェア構成の一例を示す。
【符号の説明】
【００６９】
１０  情報システム
１５  通信ネットワーク
３０  制御システム
４０  ＨＴＴＰサーバ
４５  アプリケーション・サーバ
１００  サーバ装置
１０２  通信インターフェイス
１０４  記憶装置
１０６  ウェブサーバ
２００  クライアント装置
２０２  通信インターフェイス
２０４  記憶装置
２０６  ウェブブラウザ
２０８  ユーザインターフェイス
３００  受信部
３１０  表示部
３２０  表示デバイス
３２５  画面
３３０  取得部
３３２  キュー
３３５  キュー管理部
３４０  入力デバイス
３５０  出力部
３６０  音声デバイス
３７０  送信部
４００  計測部
４１０  サービス部
４２０  返信部
【図１】
0005296373.tif 000002
【図２】
0005296373.tif 000003
【図３】
0005296373.tif 000004
【図４】
0005296373.tif 000005
【図５】
0005296373.tif 000006
【図６】
0005296373.tif 000007
【図７】
0005296373.tif 000008
【図８】
0005296373.tif 000009