ウェブページ提供装置及びウェブページ提供方法
【課題】 部品ページを一つの完成ページにまとめてからクライアントに提供する場合に、部品ページ毎にキャッシュ可能とする。
【解決手段】 本装置（10）は、ウェブサーバ（20）とアプリケーションサーバ（30）及びデータベースサーバ（40）とから構成される。ビジネスロジック（31）により生成される部品ページ（110,120）は、部品ページ単位で、予め設定されたキャッシュポリシーに従い、メモリやハードディスクに記憶される。レイアウト制御部（22）は、リクエスト制御部（21）によってウェブブラウザ（2）からのリクエストが検出されると、部品ページのキャッシュが存在するか否かを確認する（S6）。レイアウト制御部（22）は、キャッシュされている部品ページを再利用して、単一のウェブページ（200）を生成する。これにより、ウェブサーバ（20）の処理負荷が軽減され、応答性が改善される。
【解決手段】 本装置（10）は、ウェブサーバ（20）とアプリケーションサーバ（30）及びデータベースサーバ（40）とから構成される。ビジネスロジック（31）により生成される部品ページ（110,120）は、部品ページ単位で、予め設定されたキャッシュポリシーに従い、メモリやハードディスクに記憶される。レイアウト制御部（22）は、リクエスト制御部（21）によってウェブブラウザ（2）からのリクエストが検出されると、部品ページのキャッシュが存在するか否かを確認する（S6）。レイアウト制御部（22）は、キャッシュされている部品ページを再利用して、単一のウェブページ（200）を生成する。これにより、ウェブサーバ（20）の処理負荷が軽減され、応答性が改善される。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ウェブページ提供装置及びウェブページ提供方法に関する。
【背景技術】
【０００２】
いわゆるインターネットとして知られているネットワークシステムでは、WWW（World Wide Web）と呼ばれる仕組みを用いて、WWWサーバから各WWWクライアントに対して、種々のウェブページ（WWWドキュメント）を提供させる。
【０００３】
ウェブページは、テキストや画像あるいは音声等のような複数種類のコンテンツを混在させて構成することができる。操作性または視認性を向上させる目的で、フレームと呼ばれる画面分割技術が使用される場合もある（特許文献１）。
【０００４】
フレーム技術では、例えば、画面を上下または左右に分割し、分割された各表示領域にそれぞれ異なるコンテンツを表示させることができる。しかし、フレーム技術には、例えば、画面遷移の途中でブックマークすることができない、一回のリクエストでフレーム数分のリクエストが発生する、ウェブブラウザに表示されるアドレス情報と実際の表示画面とが一致しない、セキュリティ上の信頼性に欠ける等の問題がある。
そこで、例えば、Apache Struts Framework (Struts )及びTilesとして知られているように、フレーム技術を用いずに同様の機能を提供するレイアウト技術も使用されている。
【特許文献１】特開２００４−２４６７６３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
上記の新たなレイアウト技術では、従来のフレーム技術の短所を解消しつつ同等の機能を提供することができるが、ウェブブラウザに提供される画面の一部のみをキャッシュすることができない。フレーム技術を用いれば、画面の一部をキャッシュ可能であるが、上述の通り、フレーム技術には多くの短所が存在するため、ウェブアプリケーションに使用するのは適切ではない。
【０００６】
WWWクライアントとWWWサーバとの間にプロキシサーバと呼ばれる中間サーバを設け、この中間サーバで一つの画面全体を丸ごとキャッシュすることは可能である。しかし、この場合は、画面の全体を単純にキャッシュするだけであり、その画面を構成する各部分毎にそれぞれキャッシュすることはできない。
【０００７】
そこで、本発明の一つの目的は、単一のウェブページとして提供される画面を部分的に記憶させて再利用することができるようにしたウェブページ提供装置及びウェブページ提供方法を提供することにある。本発明の更なる目的は、後述する実施形態の記載から明らかになるであろう。
【課題を解決するための手段】
【０００８】
上記課題を解決すべく、本発明の一つの観点に従うウェブページ提供装置は、少なくとも一つ以上のコンテンツデータを含むウェブページをそれぞれ生成する複数のウェブページ生成手段と、これら各ウェブページ生成手段により生成される各ウェブページの全部または一部を、予め設定された記憶条件に基づいて、記憶手段に記憶させる記憶制御手段と、各ウェブページ生成手段により生成された各ウェブページを所定のレイアウト情報に基づいてそれぞれ配置することにより、単一のウェブページを生成してウェブブラウザに提供するレイアウト制御手段と、ウェブブラウザから単一のウェブページへのリクエストを検出するリクエスト制御手段とを備える。そして、レイアウト制御手段は、リクエスト制御手段によってウェブブラウザからのリクエストが検出された場合は、記憶手段に記憶されている各ウェブページの少なくとも一部を再利用して、単一のウェブページを生成可能となっている。
【０００９】
コンテンツデータとしては、例えば、テキストデータ、静止画像データ、動画像データ、音声データ、楽曲データ等を挙げることができる。ウェブページは、例えば、HTML（HyperText Markup Language）、XML（eXtensible Markup Language）、JSP（Java Server Pages）、ASP（Active Server Pages）等を用いて生成することができる。例えば、JSPやASPでは、ウェブページ中に記述されたプログラムをWWWサーバ上で実行させて、その処理結果を表示させることができ、動的なウェブページを構成可能である。このように、ウェブページは、その内容が固定される静的なウェブページと、その内容が毎回変化し得る動的なウェブページとに大別することができる。
また、記憶手段としては、例えば、半導体メモリやハードディスクドライブ等のような書き換え可能な記憶デバイスを挙げることができる。記憶制御手段は、予め設定された記憶条件に従って、ウェブページの全部または一部を記憶手段に記憶させる。
【００１０】
リクエスト制御手段がウェブブラウザからのリクエストを検出すると、レイアウト制御手段は、所定のウェブページをそれぞれ取得する。レイアウト制御手段は、所定のレイアウト情報に基づいて、これら各ウェブページを所定位置に配置し、単一のウェブページにまとめる。
即ち、この単一のウェブページは、複数のウェブページを一つのページにまとめることで構成されており、一つのウェブページとして取り扱われるもので、各フレーム内にそれぞれ異なるウェブページを表示させるフレーム技術とは相違する。
【００１１】
レイアウト制御手段は、記憶手段に記憶されているウェブページの少なくとも一部を再利用して、単一のウェブページを生成することができる。これにより、単一ウェブページ（完成されたウェブページ）の各構成要素であるウェブページをそれぞれ新たに生成させる場合に比べて、処理負荷を低減することができ、ウェブブラウザへの応答性を改善することができる。
【００１２】
レイアウト制御手段は、リクエスト制御手段によってリクエストが検出された場合は、記憶手段に記憶されている各ウェブページのうち再利用可能なウェブページを記憶手段から取得し、この再利用可能なウェブページ以外の各ウェブページについては各ウェブページ生成手段によって新たに生成させる。これにより、ウェブページ生成手段を必要最低限に稼働させることができ、ウェブページ提供装置の処理負荷を軽減して、ウェブブラウザへの応答性を向上させることができる。
【００１３】
記憶制御手段は、各ウェブページ単位で、記憶手段に記憶させるか否かを制御することができる。あるいは、記憶制御手段は、各ウェブページの属性に基づいて、各ウェブページ毎に記憶手段に記憶させるか否かをそれぞれ制御することができる。
【００１４】
例えば、記憶制御手段は、ウェブブラウザからのリクエストの内容毎にそれぞれ生成される動的なウェブページを記憶手段に記憶させることができる。即ち、動的なウェブページを記憶手段に記憶させることにより、ウェブページ生成手段を改めて稼働させる必要がなく、効率的かつ速やかに単一のウェブページを生成させることができる。
【００１５】
記憶制御手段は、複数のユーザによって共有される共有ウェブページと、各ユーザによって個別に使用される個別ウェブページとに分けて、記憶手段に記憶させてもよい。例えば、複数のユーザに対して共通に使用されるウェブページは、共通ウェブページとして一時的に記憶させる。これに対し、各ユーザそれぞれによって内容の異なるウェブページは、個別ウェブページとして一時的に記憶させる。これにより、一時記憶可能な範囲が増大するため、より一層、ウェブページ提供装置の負荷軽減及び応答性の改善を図ることができる。
【００１６】
記憶制御手段は、各ウェブページ毎にそれぞれ異なるタイミングで、該各ウェブページを記憶手段に記憶させることもできる。異なるタイミングの例としては、予め設定された所定時間毎にウェブページを記憶させる場合、ウェブブラウザからのリクエストが発生したときにウェブページを記憶させる場合とを挙げることができる。このように、単一のウェブページを構成する各部分（個別のウェブページ）毎に、それぞれ異なる適切なタイミングで記憶手段に記憶させることができる。
【００１７】
本発明の他の観点に従うウェブページの提供方法は、ウェブブラウザからのリクエストを検出するステップと、リクエストが検出された場合は、所定のレイアウト情報に基づいて、必要なウェブページを特定するステップと、特定されたウェブページのうち記憶手段に記憶されているウェブページが存在するか否かを確認するステップと、記憶手段に記憶されているウェブページを取得するステップと、特定されたウェブページのうち記憶手段に記憶されていないウェブページを生成させるステップと、この生成されたウェブページ及び記憶手段から取得されたウェブページを所定のレイアウト情報に基づいてそれぞれ配置することにより、単一のウェブページを生成するステップと、この生成された単一のウェブページをウェブブラウザに送信するステップと、を含む。
【００１８】
さらに、記憶手段に記憶されていないウェブページを生成させるステップの次に、この生成されたウェブページを記憶手段に記憶させるステップを備えてもよい。
【００１９】
本発明の機能、手段、ステップの全部または一部は、例えば、マイクロコンピュータにより実行されるコンピュータプログラムとして構成可能な場合がある。そして、このコンピュータプログラムは、例えば、ハードディスク、光ディスク、半導体メモリ等の記憶媒体に固定して配布することができる。または、コンピュータプログラムをインターネット等の通信ネットワークを介して、配信することもできる。
【発明を実施するための最良の形態】
【００２０】
以下、図面に基づき、本発明の実施の形態を説明する。本実施形態のウェブページ提供装置（10）は、少なくとも一つ以上のコンテンツデータを含むウェブページ（110,120）をそれぞれ生成する複数のウェブページ生成手段（31）と、これら各ウェブページ生成手段（31）により生成される各ウェブページ（110,120）の全部または一部を、予め設定された記憶条件に基づいて、記憶手段（11,12）に記憶させる記憶制御手段（23）と、各ウェブページ生成手段（31）により生成された各ウェブページ（110,120）を所定のレイアウト情報（100）に基づいてそれぞれ配置することにより、単一のウェブページ（200）を生成してウェブブラウザ（2）に提供するレイアウト制御手段（22）と、ウェブブラウザ（2）から単一のウェブページ（200）へのリクエストを検出するリクエスト制御手段（21）とを備えている。
そして、レイアウト制御手段（22）は、リクエスト制御手段（21）によってウェブブラウザ（2）からのリクエストが検出された場合は、記憶手段（11,12）に記憶されている各ウェブページ（110,120）の少なくとも一部を再利用して、単一のウェブページ（200）を生成する。
【実施例１】
【００２１】
図１は、ウェブページ提供装置１０の全体構成を示すブロック図である。ウェブページ提供装置１０は、例えば、サーバのような情報配信用コンピュータとして構築することができる。この装置１０は、例えば、インターネット等のような通信ネットワークを介して、クライアント端末１と双方向通信可能に接続される。なお、図１では、一つのクライアント端末１のみを示すが、実際には複数のクライアント端末１と接続可能である。
【００２２】
本装置１０は、例えば、ウェブサーバ２０と、アプリケーションサーバ３０と、データベース（図中「DB」）サーバ４０とから三層構造で構成することができる。これら各サーバ２０，３０，４０は、単一のコンピュータ内にそれぞれ設けることもできるし、複数のコンピュータにそれぞれ分散させて設けることもできる。これら各サーバ２０，３０，４０は、例えば、CPU（Central Processing Unit）、ROM（Read Only Memory）、RAM（Random Access Memory）、ハードディスクドライブ、入出力インターフェース等のハードウェアウェア資源と、OS（Operating System）やデバイスドライバ等のソフトウェア資源とを適宜利用することができる。
【００２３】
ウェブサーバ２０は、クライアント端末１上で稼働するウェブブラウザ２との間でデータ交換を行う情報処理部である。ウェブサーバ２０は、例えば、リクエスト制御部２１と、レイアウト制御部２２と、キャッシュ制御部２３とを備えることができる。リクエスト制御部２１は、例えば、ウェブブラウザ２からのHTTP（Hypertext Transfer Protocol）リクエストを検出し、このリクエストに対するレスポンスを生成させる。より詳しくは、リクエスト制御部２１は、レイアウト制御部２２により生成された単一のウェブページに対するウェブブラウザ２からのリクエストを検出すると、内部的に複数のリクエストを発生させるようになっている。
【００２４】
レイアウト制御部２２は、タイル定義ファイルＦ１及びレイアウト定義ファイルＦ２に基づいて、複数のウェブページを単一のウェブページにまとめる。この単一のウェブページは、ウェブブラウザ２に提供される最終的な表示形態である。即ち、レイアウト制御部２２により生成される単一のウェブページは、複数のウェブページに由来するが、最終的に単一のウェブページとして構成され、一つのウェブページとして取り扱われる点で、フレーム技術による画面とは相違する。以下、単一のウェブページを完成ページ、その部品となる各ウェブページを部品ページと呼ぶ場合がある。また、レイアウト制御部２２は、キャッシュ定義ファイルを使用することにより、既に生成されてキャッシュされている部品ページを再利用して、完成ページを生成する。
【００２５】
キャッシュ制御部２３は、キャッシュメモリへ記憶させるデータを管理する。キャッシュ制御部２３は、後述のように、RAM等のメモリやハードディスクドライブ等をキャッシュデバイスとして利用することができる。キャッシュ制御部２３は、キャッシュ定義ファイルＦ３及びキャッシュ制御定義ファイルＦ４に基づいて、完成ページを構成する各部分ページ毎に、それぞれキャッシュを制御する。
【００２６】
アプリケーションサーバ３０は、複数のビジネスロジック３１をそれぞれ個別に稼働させるものである。ビジネスロジック３１とは、例えば、検索結果を返したり、入力されたデータに応じたページを作成するためのウェブアプリケーションプログラムである。
【００２７】
DBサーバ４０は、データベース４１を制御するためのものである。DBサーバ４０は、アプリケーションサーバ３０からの要求に応じてデータベース４１を検索し、その結果を返すようになっている。
【００２８】
図２は、本装置１０の全体動作等を示す説明図である。説明の便宜のため、完成ページ２００が、”menu”部品ページ１１０と、”body”部品ページ１２０と、”message”部品ページ１３０とから構成される場合を例に挙げる。このため、ビジネスロジック３１を、”body”部品ページ１２０を生成するためのビジネスロジック３１Ａと、”menu”部品ページ１１０を生成するためのビジネスロジック３１Ｂとに区別して示す。
【００２９】
ウェブブラウザ２は、ウェブサーバ２０にアクセスし、例えば、画面更新等のリクエストを送信する（Ｓ１）。リクエスト制御部２１は、ウェブブラウザ２からのリクエストを検出すると、ビジネスロジック３１Ａに対して、”body”部品ページ１２０の生成を指示する（Ｓ２）。ビジネスロジック３１Ａは、”body”部品ページ１２０を生成して出力する（Ｓ３）。ここで、”body”部品ページ１２０は、キャッシュ対象になっていないため、ビジネスロジック３１Ａには直ちに生成が指示される。
【００３０】
また、リクエスト制御部２１は、ウェブブラウザ２からのリクエストを受信すると、これをレイアウト制御部２２に通知し、タイル定義の実行を指示する（Ｓ４）。レイアウト制御部２２は、タイル定義ファイルＦ１を読出し、完成ページ２００を生成するためのレイアウト情報１００を選択する。
【００３１】
レイアウト情報１００には、各部品ページ１１０，１２０，１３０をどこに配置するかといった情報が含まれている。例えば、レイアウト情報１００には、部品ページ１１０を配置するための領域１０１と、部品ページ１２０を配置するための領域１０２と、部品ページ１３０を配置するための領域１０３とが設定されている。このレイアウト情報１００としては、具体的には、例えば、タイル定義ファイルＦ１及びレイアウト定義ファイルＦ２が該当する。
【００３２】
レイアウト制御部２２は、レイアウト情報１００を参照することにより、完成ページ２００を生成するために必要な各部品ページ１１０〜１３０を検出し、各部品ページ１１０〜１３０の取得を開始する。”body”部品ページ１２０がビジネスロジック３１Ａから出力された場合、レイアウト制御部２２は、部品ページ１２０を取得する（Ｓ５）。
【００３３】
一方、レイアウト制御部２２は、”menu”部品ページ１１０を取得するに際して、まず最初に、キャッシュ制御部２３にキャッシュデータの有無を確認する（Ｓ６）。レイアウト制御部２２は、キャッシュ定義ファイルＦ３を参照することにより、キャッシュ対象の部品データを特定することができる。
【００３４】
キャッシュ制御部２３は、レイアウト制御部２２からの問合せを受けると、キャッシュ定義ファイルＦ３を参照し、”menu”部品ページ１１０がキャッシュされているか否かを確認する。”menu”部品ページ１１０がキャッシュされている場合、レイアウト制御部２２は、そのキャッシュされている部品ページ１１０を取得する（Ｓ１０）。従って、ビジネスロジック３１Ｂは部品ページ１１０を生成する必要がなく、レイアウト制御部２２は、直ちに部品ページ１１０を取得することができる。
【００３５】
なお、例えば、LRU(Least Recently Used)等のキャッシュ管理アルゴリズムに従って、キャッシュデータは、定期的にまたは不定期に削除される。従って、キャッシュ対象の”menu”部品ページ１１０がキャッシュされていない場合もある。この場合、ビジネスロジック３１Ｂに”menu”部品ページ１１０の生成が指示され（Ｓ７）、ビジネスロジック３１Ｂは部品ページ１１０を新たに生成して出力する（Ｓ８）。キャッシュ制御部２３は、この新たに生成された部品ページ１１０をキャッシュする（Ｓ９）。
【００３６】
一方、レイアウト制御部２２は、例えば、定まったテキスト等のような、静的な部品ページ１３０を図示せぬ静的なファイル取得システムを介して取得する（Ｓ１１）。
【００３７】
このようにして、レイアウト制御部２２は、必要な全ての部品ページ１１０〜１３０をそれぞれ取得する。レイアウト情報１００に従って、各部品ページ１１０〜１３０を所定の位置にそれぞれ配置し、出力画面（完成ページ２００）を生成する（Ｓ１２）。
【００３８】
そして、生成された完成ページ２００は、通信ネットワークを介して、ウェブサーバ２０からウェブブラウザ２に送信される（Ｓ１３）。ウェブブラウザ２には、単一のウェブページとして構成された完成ページ２００が表示される。上述のように、この完成ページ２００は、複数の部品ページ１１０〜１３０に由来しており、複数種類のコンテンツデータが含まれている。従って、見かけ上は、フレームの枠を消したフレーム画面に類似するが、フレーム画面とは異なり、複数のウェブページから構成されているわけでない。
【００３９】
次に、各ファイルＦ１〜Ｆ４の一例をそれぞれ説明する。図３は、タイル定義ファイルＦ１を示す説明図である。タイル定義ファイルＦ１の概略を部分的に説明すると、タイル定義ファイルＦ１は、レイアウトを決定すべきレイアウト定義ファイルＦ２を特定する（Ｆ１１）。また、タイル定義ファイルＦ１には、完成されたページ２００のタイトルが指定される（Ｆ１２）。
【００４０】
さらに、タイル定義ファイルＦ１では、動的な部品ページを生成し表示させるためのURL（Uniform Resource Locator）を指定することができる（Ｆ１３）。動的な部品ページとして指定された場合、その部品ページを生成するビジネスロジック３１に対して内部的なリクエストが発行されることになる。また、タイル定義ファイルＦ１には、静的な部品ページを表示させるための指定も含まれている（Ｆ１４）。
【００４１】
図４は、レイアウト定義ファイルＦ２の説明図である。レイアウト定義ファイルＦ２では、例えば、表示させるコンテンツ名等を指定する（Ｆ２１）。また、レイアウト定義ファイルＦ２では、コンテンツ表示位置等を指定することができる。
【００４２】
図５は。キャッシュ定義ファイルＦ３を示す説明図である。キャッシュ定義ファイルＦ３では、キャッシュ対象の部品ページを少なくとも一つ以上指定できる。そして、キャッシュ対象として指定された部品ページ毎に、キャッシュ制御用のパラメータをそれぞれ設定することができる。
【００４３】
例えば、そのキャッシュ対象の部品ページが、複数のユーザによって共有されるものであるのか（キャッシュタイプ＝”global”）、個別のユーザにのみ使用されるものであるのか（キャッシュタイプ＝”session”）を指定することができる（Ｆ３１）。また、キャッシュ定義ファイルＦ３では、キャッシュデータを特定するためのキーとなるパラメータを複数設定することもできる（Ｆ３２）。さらに、キャッシュメモリを制御するためのキャッシュ制御定義ファイルＦ４を指定することもできる（Ｆ３３）。
【００４４】
図６は、キャッシュ制御定義ファイルＦ４を示す説明図である。キャッシュ制御定義ファイルＦ４では、例えば、キャッシュ制御システムの種類を指定する（Ｆ４１）。キャッシュ制御システムとしては、例えば、（１）キャッシュをメモリに保持、（２）キャッシュをハードディスクにファイルとして保持、（３）キャッシュをメモリに保持するが、メモリの空き容量が一定量以下になった場合は、ファイルとして保持等のように、キャッシュさせる記憶デバイスの使用方法を挙げることができる。
これに加えて、例えば、（４）キャッシュをファイルとして保持し、キャッシュファイルのサイズが一定量を超えた場合は、古いものから削除する等のように、キャッシュ領域の解放方法まで指定することもできる。
【００４５】
さらに、キャッシュ制御定義ファイルＦ４では、より詳細な設定を行うことができる（Ｆ４２）。設定項目としては、例えば、（１）キャッシュファイルを保存させるディレクトリ名、（２）ハードディスクに保存するキャッシュファイルの最大記憶量、（３）メモリに保存するキャッシュの最大記憶量、（４）ウェブサーバ２０を再起動したときにキャッシュを削除するか否か、等を挙げることができる。
【００４６】
次に、動作の概略は既に図２と共に述べたが、本装置１０による画面出力処理の概要を図７を参照して説明する。ウェブサーバ２０は、クライアント端末１からのリクエストを検出すると（S21：YES）、レイアウト（タイル定義ファイルＦ１及びレイアウト定義ファイルＦ２）を選択する（Ｓ２２）。
【００４７】
ウェブサーバ２０は、キャッシュ定義ファイルＦ３を参照し、選択されたレイアウトにキャッシュ対象の部品ページが含まれているか否かを判定する（Ｓ２３）。そのレイアウトにおいて、キャッシュ対象に指定されている部品ページが使用される場合（S23：YES）、ウェブサーバ２０は、その部品ページがキャッシュされているか否かを判定する（Ｓ２４）。ウェブサーバ２０は、その部品ページがキャッシュされている場合（S24：YES）、キャッシュされている部品ページをメモリ等から読出して取得する（Ｓ２５）。
【００４８】
これに対し、選択されたレイアウト内でキャッシュ対象の部品ページが使用されていない場合（S23：NO）、ウェブサーバ２０は、部品ページを新たに生成する必要があるか否かを判定する（Ｓ２６）。生成の必要ありと判定した場合（S26：YES）、ウェブサーバ２０は、ビジネスロジック３１に部品ページを生成させる（Ｓ２７）。
ウェブサーバ２０は、キャッシュ定義ファイルＦ３に基づいて、この生成された部品ページをキャッシュするか否かを判定する（Ｓ２８）。生成された部品ページをキャッシュする場合（S28：YES）、ウェブサーバ２０は、所定の記憶デバイスにその部品ページを記憶させてから（Ｓ２９）、その部品ページを完成ページを生成するために取得する（Ｓ３０）。
【００４９】
一方、キャッシュ対象の部品ページがキャッシュされていない場合（S24：NO）、即ちキャッシュミスが発生した場合は、ウェブサーバ２０は、ビジネスロジック３１に指示を出して、その部品ページを新たに生成させる（Ｓ２７）。そして、ウェブサーバ２０は、生成した部品ページをキャッシュさせて（S28：YES、Ｓ２９）、完成ページの作成に使用する（Ｓ３０）。
【００５０】
ウェブサーバ２０は、完成ページを作成するために必要な全ての部品ページを取得したか否かを判定する（Ｓ３１）。取得していない部品ページが存在する場合（S31：NO）、ウェブサーバ２０は、上述した処理を繰り返す（Ｓ２３〜Ｓ３０）。
【００５１】
必要な全ての部品ページを取得した場合（S31：YES）、ウェブサーバ２０は、完成ページを作成し（Ｓ３２）、これをクライアント端末１に送信する（Ｓ３３）。
【００５２】
図８は、キャッシュを生成する処理の概略を示すフローチャートである。ウェブサーバ２０は、ビジネスロジック３１によって生成された部品データを取得すると（Ｓ４１）、キャッシュ定義ファイルＦ３を参照し（Ｓ４２）、この部品ページがキャッシュ対象として指定されているか否かを判定する（Ｓ４３）。キャッシュ対象でなければ、本処理は終了する（S43：NO）。
【００５３】
キャッシュ対象に指定されている部品ページを取得した場合（S43：YES）、ウェブサーバ２０は、その部品ページが共有指定されているか否かを判定する（Ｓ４４）。共有指定とは、複数のユーザによって共通に使用される部品ページであることを示す。共有指定された部品ページの場合（S44：YES）、ウェブサーバ２０は、共有キャッシュとして記憶し（Ｓ４５）、キャッシュ管理テーブルＴ２を更新させる（Ｓ４６）。キャッシュ管理テーブルＴ２については後述する。
【００５４】
共有指定されていない部品ページを取得した場合（S44：NO）、即ち、各ユーザ毎にそれぞれ使用される部品ページの場合、ウェブサーバ２０は、どのユーザに適用される部品ページであるかを特定するための情報を取得する（Ｓ４７）。このユーザ特定情報として、本実施例では、クライアント端末１との間のセッションを識別するためのセッション識別情報（図中「セッションID」）を使用する。ウェブサーバ２０は、取得した部品ページとセッション識別情報とを対応付けて、所定の記憶デバイスに記憶させ（Ｓ４８）、キャッシュ管理テーブルＴ２を更新させる（Ｓ４９）。
【００５５】
図９は、各部品ページの属性に応じて、キャッシュ方法がそれぞれ異なる例を示す説明図である。上述のように、キャッシュ定義ファイルＦ３では、キャッシュ対象の部品ページを指定し、指定された部品ページ毎にキャッシュタイプ（図９中の「共有属性」）等を設定することができる。
【００５６】
部品ページは、例えば、動的部品ページと静的部品ページとに分類できる。動的部品ページとは、例えば、要求される度に生成され、その内容が毎回異なるものを意味し、静的部品ページとは、例えば、その内容が一定で変化しないものを意味する。
【００５７】
本実施例では、動的部品ページ及び静的部品ページのいずれをもキャッシュ可能であるが、動的部品ページをキャッシュしておけば、ビジネスロジック３１を実行させる必要がなくなり、サーバ負荷が軽減される。そこで、例えば、動的部品ページを優先的にキャッシュするように、キャッシュ定義ファイルＦ３及びキャッシュ制御定義ファイルＦ４を構成してもよい。例えば、動的部品ページを優先的にメモリに記憶させ、メモリの空き容量が少なくなった場合は、静的部品ページから先に消去する。あるいは、動的部品ページをメモリに保持させ、静的部品ページをハードディスクに保持させることにより、動的部品ページをより速やかに取得することができ、ウェブサーバ２０の応答性をより改善することもできる。
【００５８】
図１０は、キャッシュ管理テーブルＴ２等を示す説明図である。キャッシュ管理テーブルＴ２は、例えば、ページ識別情報（図中、「PID」）と、各部品ページの共有属性と、セッションIDと、部品ページが記憶されるデバイス名と、部品ページの記憶先アドレスと、部品ページの更新トリガとを、それぞれ対応付けることにより構成可能である。
【００５９】
ページ識別情報は、キャッシュされている各部品ページをそれぞれ識別するための情報であり、例えば複数のパラメータの値を組み合わせることにより、生成される。同一のページ名であっても、その表示内容や更新時期等によって、ページ識別情報の値はそれぞれ異なる。共有属性とは、既に述べたように、その部品ページが複数のユーザにより共有されるページであるか、それとも各ユーザにより個別に使用されるページであるかを区別する情報である。セッションIDは、その部品ページが各ユーザ毎に使用される場合に、どのユーザに対して使用されるのかを特定するための情報である。格納先デバイス名は、部品ページが記憶されているデバイスを特定するための情報である。
【００６０】
更新トリガとは、その部品ページをキャッシュするタイミングを指定するための情報である。更新トリガとしては、例えば、（１）所定時間毎、（２）その部品ページの更新が要求される毎、等を挙げることができる。即ち、例えば、その部品ページの表示内容等の特性に応じて、キャッシュを定期的にまたは不定期に更新させることができる。例えば、衛星画像を表示する部品ページの場合、その衛星画像を出力するビジネスロジック３１の更新時期に合わせて、キャッシュを更新させることができる。また、例えば、検索結果を表示する部品ページの場合、ユーザから検索が要求された場合に、キャッシュを更新させることができる。
【００６１】
図１０中の下側には、部品データをキャッシュするための複数種類の記憶デバイスが示されている。ここで例えば、一つの記憶デバイスはメモリ１１であり、他の一つの記憶デバイスはハードディスク１２である。
【００６２】
メモリ１１もハードディスク１２もいずれもランダムアクセス可能な記憶デバイスであるが、CPUからのアクセス性の観点では、メモリ１１の方がハードディスク１２よりも高速にアクセス可能である。一方、記憶容量の観点では、ハードディスク１２の方がメモリ１１よりも多くの部品ページを記憶可能である。
【００６３】
そこで、例えば、このような記憶デバイスの特徴に基づいて、より速やかなアクセスが要求される部品ページやアクセス頻度の高い部品ページはメモリ１１に記憶させ、それ以外の部品ページをハードディスク１２に記憶させることができる。また、例えば、アクセス頻度を監視し、アクセス頻度が所定値以上に達した部品ページはハードディスク１２からメモリ１１に移し替え、逆に、アクセス頻度が所定値以下に達した部品はメモリ１１からハードディスク１２に移動させることもできる。あるいは、アクセス頻度に代えて、最後に使用されてからの経過時間に基づいて、記憶デバイス１１，１２間を移動させるようにしてもよい。
【００６４】
本実施例は、上述のように構成されるので、以下の効果を奏する。本実施例では、完成ページを構成する各部品ページをそれぞれ個別にキャッシュ可能とし、キャッシュされた部品ページを再利用して完成ページを生成可能な構成とした。従って、クライアント端末１からリクエストされるたびに全ての部品ページをそれぞれ新たに生成し直す必要がなく、ウェブサーバ２０やアプリケーションサーバ３０等の処理負担をそれぞれ低減することができ、ウェブサーバ２０の応答性能を向上させることができる。
【００６５】
本実施例では、各部品ページ毎に、それぞれ共有属性を指定可能な構成とした。従って、キャッシュ可能な部品ページの範囲を広げることができ、これにより、一層の処理負担軽減と応答性の改善を図ることができる。つまり、本実施例では、ユーザ固有の情報を含む部品ページであっても、そのユーザを特定するための情報（セッションID）と対応付けて管理することにより、そのユーザ固有の部品ページをキャッシュして再利用できる構成を採用する。従って、キャッシュ可能な部品ページが増加し、再利用の可能性を高めて、より一層のサーバ負担の軽減及び応答性改善を図ることができる。
【００６６】
本実施例では、ウェブブラウザ２からのリクエストの内容毎にそれぞれ生成される動的な部品ページをキャッシュ可能な構成とした。従って、ビジネスロジック３１を稼働させて部品ページを作り直す手間がいらず、より一層サーバ負担を軽減し、応答性を改善することができる。
【００６７】
本実施例では、各部品ページ毎にそれぞれ異なるタイミングでキャッシュ可能な構成を採用した。従って、各部品ページの特徴に応じた適切なタイミングで、各部品ページをそれぞれキャッシュすることができる。
【実施例２】
【００６８】
図１１に基づいて、第２実施例を説明する。本実施例では、各部品ページのキャッシュを更新させる時期が到来したか否かを監視し、自動的にキャッシュデータを更新させるようにしている。
【００６９】
図１１は、本実施例のキャッシュ生成処理の概略を示すフローチャートである。ウェブサーバ２０は、キャッシュ定義ファイルＦ３を参照し（Ｓ５１）、キャッシュデータの更新時期が到来したか否かを判定する（Ｓ５２）
【００７０】
メモリ等にキャッシュされている部品ページの更新時期である場合（S52：YES）、ウェブサーバ２０は、その部品ページの最新のデータを取得する（Ｓ５３）。例えば、その部品ページが動的なページである場合、その部品ページを生成するビジネスロジック３１に内部的な指示を発行し、新たな部品ページを生成させる。
【００７１】
ウェブサーバ２０は、最新の部品ページを取得すると、この部品ページをメモリ等に記憶させ（Ｓ５４）、キャッシュ管理テーブルＴ２を更新させる（Ｓ５５）。ウェブサーバ２０は、キャッシュ定義ファイルＦ３に登録されている全ての部品ページについてキャッシュ更新を行ったか否かを判定する（Ｓ５６）。なお、その部品ページのキャッシュ更新時期が到来していない場合（S52：NO）、Ｓ５３〜Ｓ５５はスキップされ、Ｓ５６に移行する。
【００７２】
更新の是非を判定していない部品ページが残っている場合（S56：NO）、ウェブサーバ２０は、キャッシュ定義ファイルＦ３に登録されている次の部品ページに移動し（Ｓ５７）、上述したＳ５１〜Ｓ５６をそれぞれ繰り返す。そして、ウェブサーバ２０が、全ての部品ページについてキャッシュ更新の有無を判断し、更新が必要な部品データのキャッシュデータを更新させると（S56：YES）、本処理を終了する。
【００７３】
このように構成される本実施例でも、前記実施例と同様の効果を奏する。これに加えて、本実施例では、クライアントからのリクエストの有無を問わずに、部品ページのキャッシュデータを更新させるか否かを定期的に（または不定期に）判断し、自動的にキャッシュを更新させる構成とした。従って、本実施例では、例えば、クライアントからのリクエストを受信する前に、キャッシュデータを最新の状態を保持しておくことができ、リクエストに対して速やかに応答することができる。
【００７４】
また、本実施例の変形例として、ウェブサーバ２０の処理負荷を監視し、処理負荷が所定値以下の場合に、即ち、ウェブサーバ２０の負荷が軽い時間帯を利用して、キャッシュデータを自動的に更新させることもできる。また、例えば、各部品ページの属性（共有ページか否か、アクセス頻度の大小等）を考慮し、相対的に必要性の高い部品ページは定期的にキャッシュを更新し、相対的に必要性の低い部品ページはクライアントからのリクエストを待ってキャッシュを更新させることもできる。
【００７５】
なお、本発明は、上述した実施の形態に限定されない。当業者であれば、本発明の範囲内で、種々の追加や変更等を行うことができる。例えば、当業者であれば、前記各実施例を適宜組み合わせることができる。
【図面の簡単な説明】
【００７６】
【図１】本実施例によるウェブページ提供装置の全体構成を示すブロック図である。
【図２】ウェブページ提供装置の全体動作等を示す構成説明図である。
【図３】タイプ定義ファイルの一例を示す説明図である。
【図４】レイアウト定義ファイルの一例を示す説明図である。
【図５】キャッシュ定義ファイルの一例を示す説明図である。
【図６】キャッシュ制御定義ファイルの一例を示す説明図である。
【図７】完成されたページをクライアントに提供する処理を示すフローチャートである。
【図８】キャッシュ生成処理を示すフローチャートである。
【図９】キャッシュ定義ファイルとキャッシュ対象の種類との関係を示す説明図である。
【図１０】キャッシュ管理テーブル及びキャッシュに使用する記憶デバイスとの関係を示す説明図である。
【図１１】本発明の他の実施例によるキャッシュ生成処理を示すフローチャートである。
【符号の説明】
【００７７】
１…クライアント端末、２…ウェブブラウザ、１０…ウェブページ提供装置、１１…メモリ、１２…ハードディスク、２０…ウェブサーバ、２１…リクエスト制御部、２２…レイアウト制御部、２３…キャッシュ制御部、３０…アプリケーションサーバ、３１，３１Ａ，３１Ｂ…ビジネスロジック、４０…データベースサーバ、１００…レイアウト情報、１０１，１０２，１０３…部品ページの表示領域、１１０，１２０，１３０…部品ページ、２００…完成ページ、Ｆ１…タイル定義ファイル、Ｆ２…レイアウト定義ファイル、Ｆ３…キャッシュ定義ファイル、Ｆ４…キャッシュ制御定義ファイル、Ｔ２…キャッシュ管理テーブル
【技術分野】
【０００１】
本発明は、ウェブページ提供装置及びウェブページ提供方法に関する。
【背景技術】
【０００２】
いわゆるインターネットとして知られているネットワークシステムでは、WWW（World Wide Web）と呼ばれる仕組みを用いて、WWWサーバから各WWWクライアントに対して、種々のウェブページ（WWWドキュメント）を提供させる。
【０００３】
ウェブページは、テキストや画像あるいは音声等のような複数種類のコンテンツを混在させて構成することができる。操作性または視認性を向上させる目的で、フレームと呼ばれる画面分割技術が使用される場合もある（特許文献１）。
【０００４】
フレーム技術では、例えば、画面を上下または左右に分割し、分割された各表示領域にそれぞれ異なるコンテンツを表示させることができる。しかし、フレーム技術には、例えば、画面遷移の途中でブックマークすることができない、一回のリクエストでフレーム数分のリクエストが発生する、ウェブブラウザに表示されるアドレス情報と実際の表示画面とが一致しない、セキュリティ上の信頼性に欠ける等の問題がある。
そこで、例えば、Apache Struts Framework (Struts )及びTilesとして知られているように、フレーム技術を用いずに同様の機能を提供するレイアウト技術も使用されている。
【特許文献１】特開２００４−２４６７６３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
上記の新たなレイアウト技術では、従来のフレーム技術の短所を解消しつつ同等の機能を提供することができるが、ウェブブラウザに提供される画面の一部のみをキャッシュすることができない。フレーム技術を用いれば、画面の一部をキャッシュ可能であるが、上述の通り、フレーム技術には多くの短所が存在するため、ウェブアプリケーションに使用するのは適切ではない。
【０００６】
WWWクライアントとWWWサーバとの間にプロキシサーバと呼ばれる中間サーバを設け、この中間サーバで一つの画面全体を丸ごとキャッシュすることは可能である。しかし、この場合は、画面の全体を単純にキャッシュするだけであり、その画面を構成する各部分毎にそれぞれキャッシュすることはできない。
【０００７】
そこで、本発明の一つの目的は、単一のウェブページとして提供される画面を部分的に記憶させて再利用することができるようにしたウェブページ提供装置及びウェブページ提供方法を提供することにある。本発明の更なる目的は、後述する実施形態の記載から明らかになるであろう。
【課題を解決するための手段】
【０００８】
上記課題を解決すべく、本発明の一つの観点に従うウェブページ提供装置は、少なくとも一つ以上のコンテンツデータを含むウェブページをそれぞれ生成する複数のウェブページ生成手段と、これら各ウェブページ生成手段により生成される各ウェブページの全部または一部を、予め設定された記憶条件に基づいて、記憶手段に記憶させる記憶制御手段と、各ウェブページ生成手段により生成された各ウェブページを所定のレイアウト情報に基づいてそれぞれ配置することにより、単一のウェブページを生成してウェブブラウザに提供するレイアウト制御手段と、ウェブブラウザから単一のウェブページへのリクエストを検出するリクエスト制御手段とを備える。そして、レイアウト制御手段は、リクエスト制御手段によってウェブブラウザからのリクエストが検出された場合は、記憶手段に記憶されている各ウェブページの少なくとも一部を再利用して、単一のウェブページを生成可能となっている。
【０００９】
コンテンツデータとしては、例えば、テキストデータ、静止画像データ、動画像データ、音声データ、楽曲データ等を挙げることができる。ウェブページは、例えば、HTML（HyperText Markup Language）、XML（eXtensible Markup Language）、JSP（Java Server Pages）、ASP（Active Server Pages）等を用いて生成することができる。例えば、JSPやASPでは、ウェブページ中に記述されたプログラムをWWWサーバ上で実行させて、その処理結果を表示させることができ、動的なウェブページを構成可能である。このように、ウェブページは、その内容が固定される静的なウェブページと、その内容が毎回変化し得る動的なウェブページとに大別することができる。
また、記憶手段としては、例えば、半導体メモリやハードディスクドライブ等のような書き換え可能な記憶デバイスを挙げることができる。記憶制御手段は、予め設定された記憶条件に従って、ウェブページの全部または一部を記憶手段に記憶させる。
【００１０】
リクエスト制御手段がウェブブラウザからのリクエストを検出すると、レイアウト制御手段は、所定のウェブページをそれぞれ取得する。レイアウト制御手段は、所定のレイアウト情報に基づいて、これら各ウェブページを所定位置に配置し、単一のウェブページにまとめる。
即ち、この単一のウェブページは、複数のウェブページを一つのページにまとめることで構成されており、一つのウェブページとして取り扱われるもので、各フレーム内にそれぞれ異なるウェブページを表示させるフレーム技術とは相違する。
【００１１】
レイアウト制御手段は、記憶手段に記憶されているウェブページの少なくとも一部を再利用して、単一のウェブページを生成することができる。これにより、単一ウェブページ（完成されたウェブページ）の各構成要素であるウェブページをそれぞれ新たに生成させる場合に比べて、処理負荷を低減することができ、ウェブブラウザへの応答性を改善することができる。
【００１２】
レイアウト制御手段は、リクエスト制御手段によってリクエストが検出された場合は、記憶手段に記憶されている各ウェブページのうち再利用可能なウェブページを記憶手段から取得し、この再利用可能なウェブページ以外の各ウェブページについては各ウェブページ生成手段によって新たに生成させる。これにより、ウェブページ生成手段を必要最低限に稼働させることができ、ウェブページ提供装置の処理負荷を軽減して、ウェブブラウザへの応答性を向上させることができる。
【００１３】
記憶制御手段は、各ウェブページ単位で、記憶手段に記憶させるか否かを制御することができる。あるいは、記憶制御手段は、各ウェブページの属性に基づいて、各ウェブページ毎に記憶手段に記憶させるか否かをそれぞれ制御することができる。
【００１４】
例えば、記憶制御手段は、ウェブブラウザからのリクエストの内容毎にそれぞれ生成される動的なウェブページを記憶手段に記憶させることができる。即ち、動的なウェブページを記憶手段に記憶させることにより、ウェブページ生成手段を改めて稼働させる必要がなく、効率的かつ速やかに単一のウェブページを生成させることができる。
【００１５】
記憶制御手段は、複数のユーザによって共有される共有ウェブページと、各ユーザによって個別に使用される個別ウェブページとに分けて、記憶手段に記憶させてもよい。例えば、複数のユーザに対して共通に使用されるウェブページは、共通ウェブページとして一時的に記憶させる。これに対し、各ユーザそれぞれによって内容の異なるウェブページは、個別ウェブページとして一時的に記憶させる。これにより、一時記憶可能な範囲が増大するため、より一層、ウェブページ提供装置の負荷軽減及び応答性の改善を図ることができる。
【００１６】
記憶制御手段は、各ウェブページ毎にそれぞれ異なるタイミングで、該各ウェブページを記憶手段に記憶させることもできる。異なるタイミングの例としては、予め設定された所定時間毎にウェブページを記憶させる場合、ウェブブラウザからのリクエストが発生したときにウェブページを記憶させる場合とを挙げることができる。このように、単一のウェブページを構成する各部分（個別のウェブページ）毎に、それぞれ異なる適切なタイミングで記憶手段に記憶させることができる。
【００１７】
本発明の他の観点に従うウェブページの提供方法は、ウェブブラウザからのリクエストを検出するステップと、リクエストが検出された場合は、所定のレイアウト情報に基づいて、必要なウェブページを特定するステップと、特定されたウェブページのうち記憶手段に記憶されているウェブページが存在するか否かを確認するステップと、記憶手段に記憶されているウェブページを取得するステップと、特定されたウェブページのうち記憶手段に記憶されていないウェブページを生成させるステップと、この生成されたウェブページ及び記憶手段から取得されたウェブページを所定のレイアウト情報に基づいてそれぞれ配置することにより、単一のウェブページを生成するステップと、この生成された単一のウェブページをウェブブラウザに送信するステップと、を含む。
【００１８】
さらに、記憶手段に記憶されていないウェブページを生成させるステップの次に、この生成されたウェブページを記憶手段に記憶させるステップを備えてもよい。
【００１９】
本発明の機能、手段、ステップの全部または一部は、例えば、マイクロコンピュータにより実行されるコンピュータプログラムとして構成可能な場合がある。そして、このコンピュータプログラムは、例えば、ハードディスク、光ディスク、半導体メモリ等の記憶媒体に固定して配布することができる。または、コンピュータプログラムをインターネット等の通信ネットワークを介して、配信することもできる。
【発明を実施するための最良の形態】
【００２０】
以下、図面に基づき、本発明の実施の形態を説明する。本実施形態のウェブページ提供装置（10）は、少なくとも一つ以上のコンテンツデータを含むウェブページ（110,120）をそれぞれ生成する複数のウェブページ生成手段（31）と、これら各ウェブページ生成手段（31）により生成される各ウェブページ（110,120）の全部または一部を、予め設定された記憶条件に基づいて、記憶手段（11,12）に記憶させる記憶制御手段（23）と、各ウェブページ生成手段（31）により生成された各ウェブページ（110,120）を所定のレイアウト情報（100）に基づいてそれぞれ配置することにより、単一のウェブページ（200）を生成してウェブブラウザ（2）に提供するレイアウト制御手段（22）と、ウェブブラウザ（2）から単一のウェブページ（200）へのリクエストを検出するリクエスト制御手段（21）とを備えている。
そして、レイアウト制御手段（22）は、リクエスト制御手段（21）によってウェブブラウザ（2）からのリクエストが検出された場合は、記憶手段（11,12）に記憶されている各ウェブページ（110,120）の少なくとも一部を再利用して、単一のウェブページ（200）を生成する。
【実施例１】
【００２１】
図１は、ウェブページ提供装置１０の全体構成を示すブロック図である。ウェブページ提供装置１０は、例えば、サーバのような情報配信用コンピュータとして構築することができる。この装置１０は、例えば、インターネット等のような通信ネットワークを介して、クライアント端末１と双方向通信可能に接続される。なお、図１では、一つのクライアント端末１のみを示すが、実際には複数のクライアント端末１と接続可能である。
【００２２】
本装置１０は、例えば、ウェブサーバ２０と、アプリケーションサーバ３０と、データベース（図中「DB」）サーバ４０とから三層構造で構成することができる。これら各サーバ２０，３０，４０は、単一のコンピュータ内にそれぞれ設けることもできるし、複数のコンピュータにそれぞれ分散させて設けることもできる。これら各サーバ２０，３０，４０は、例えば、CPU（Central Processing Unit）、ROM（Read Only Memory）、RAM（Random Access Memory）、ハードディスクドライブ、入出力インターフェース等のハードウェアウェア資源と、OS（Operating System）やデバイスドライバ等のソフトウェア資源とを適宜利用することができる。
【００２３】
ウェブサーバ２０は、クライアント端末１上で稼働するウェブブラウザ２との間でデータ交換を行う情報処理部である。ウェブサーバ２０は、例えば、リクエスト制御部２１と、レイアウト制御部２２と、キャッシュ制御部２３とを備えることができる。リクエスト制御部２１は、例えば、ウェブブラウザ２からのHTTP（Hypertext Transfer Protocol）リクエストを検出し、このリクエストに対するレスポンスを生成させる。より詳しくは、リクエスト制御部２１は、レイアウト制御部２２により生成された単一のウェブページに対するウェブブラウザ２からのリクエストを検出すると、内部的に複数のリクエストを発生させるようになっている。
【００２４】
レイアウト制御部２２は、タイル定義ファイルＦ１及びレイアウト定義ファイルＦ２に基づいて、複数のウェブページを単一のウェブページにまとめる。この単一のウェブページは、ウェブブラウザ２に提供される最終的な表示形態である。即ち、レイアウト制御部２２により生成される単一のウェブページは、複数のウェブページに由来するが、最終的に単一のウェブページとして構成され、一つのウェブページとして取り扱われる点で、フレーム技術による画面とは相違する。以下、単一のウェブページを完成ページ、その部品となる各ウェブページを部品ページと呼ぶ場合がある。また、レイアウト制御部２２は、キャッシュ定義ファイルを使用することにより、既に生成されてキャッシュされている部品ページを再利用して、完成ページを生成する。
【００２５】
キャッシュ制御部２３は、キャッシュメモリへ記憶させるデータを管理する。キャッシュ制御部２３は、後述のように、RAM等のメモリやハードディスクドライブ等をキャッシュデバイスとして利用することができる。キャッシュ制御部２３は、キャッシュ定義ファイルＦ３及びキャッシュ制御定義ファイルＦ４に基づいて、完成ページを構成する各部分ページ毎に、それぞれキャッシュを制御する。
【００２６】
アプリケーションサーバ３０は、複数のビジネスロジック３１をそれぞれ個別に稼働させるものである。ビジネスロジック３１とは、例えば、検索結果を返したり、入力されたデータに応じたページを作成するためのウェブアプリケーションプログラムである。
【００２７】
DBサーバ４０は、データベース４１を制御するためのものである。DBサーバ４０は、アプリケーションサーバ３０からの要求に応じてデータベース４１を検索し、その結果を返すようになっている。
【００２８】
図２は、本装置１０の全体動作等を示す説明図である。説明の便宜のため、完成ページ２００が、”menu”部品ページ１１０と、”body”部品ページ１２０と、”message”部品ページ１３０とから構成される場合を例に挙げる。このため、ビジネスロジック３１を、”body”部品ページ１２０を生成するためのビジネスロジック３１Ａと、”menu”部品ページ１１０を生成するためのビジネスロジック３１Ｂとに区別して示す。
【００２９】
ウェブブラウザ２は、ウェブサーバ２０にアクセスし、例えば、画面更新等のリクエストを送信する（Ｓ１）。リクエスト制御部２１は、ウェブブラウザ２からのリクエストを検出すると、ビジネスロジック３１Ａに対して、”body”部品ページ１２０の生成を指示する（Ｓ２）。ビジネスロジック３１Ａは、”body”部品ページ１２０を生成して出力する（Ｓ３）。ここで、”body”部品ページ１２０は、キャッシュ対象になっていないため、ビジネスロジック３１Ａには直ちに生成が指示される。
【００３０】
また、リクエスト制御部２１は、ウェブブラウザ２からのリクエストを受信すると、これをレイアウト制御部２２に通知し、タイル定義の実行を指示する（Ｓ４）。レイアウト制御部２２は、タイル定義ファイルＦ１を読出し、完成ページ２００を生成するためのレイアウト情報１００を選択する。
【００３１】
レイアウト情報１００には、各部品ページ１１０，１２０，１３０をどこに配置するかといった情報が含まれている。例えば、レイアウト情報１００には、部品ページ１１０を配置するための領域１０１と、部品ページ１２０を配置するための領域１０２と、部品ページ１３０を配置するための領域１０３とが設定されている。このレイアウト情報１００としては、具体的には、例えば、タイル定義ファイルＦ１及びレイアウト定義ファイルＦ２が該当する。
【００３２】
レイアウト制御部２２は、レイアウト情報１００を参照することにより、完成ページ２００を生成するために必要な各部品ページ１１０〜１３０を検出し、各部品ページ１１０〜１３０の取得を開始する。”body”部品ページ１２０がビジネスロジック３１Ａから出力された場合、レイアウト制御部２２は、部品ページ１２０を取得する（Ｓ５）。
【００３３】
一方、レイアウト制御部２２は、”menu”部品ページ１１０を取得するに際して、まず最初に、キャッシュ制御部２３にキャッシュデータの有無を確認する（Ｓ６）。レイアウト制御部２２は、キャッシュ定義ファイルＦ３を参照することにより、キャッシュ対象の部品データを特定することができる。
【００３４】
キャッシュ制御部２３は、レイアウト制御部２２からの問合せを受けると、キャッシュ定義ファイルＦ３を参照し、”menu”部品ページ１１０がキャッシュされているか否かを確認する。”menu”部品ページ１１０がキャッシュされている場合、レイアウト制御部２２は、そのキャッシュされている部品ページ１１０を取得する（Ｓ１０）。従って、ビジネスロジック３１Ｂは部品ページ１１０を生成する必要がなく、レイアウト制御部２２は、直ちに部品ページ１１０を取得することができる。
【００３５】
なお、例えば、LRU(Least Recently Used)等のキャッシュ管理アルゴリズムに従って、キャッシュデータは、定期的にまたは不定期に削除される。従って、キャッシュ対象の”menu”部品ページ１１０がキャッシュされていない場合もある。この場合、ビジネスロジック３１Ｂに”menu”部品ページ１１０の生成が指示され（Ｓ７）、ビジネスロジック３１Ｂは部品ページ１１０を新たに生成して出力する（Ｓ８）。キャッシュ制御部２３は、この新たに生成された部品ページ１１０をキャッシュする（Ｓ９）。
【００３６】
一方、レイアウト制御部２２は、例えば、定まったテキスト等のような、静的な部品ページ１３０を図示せぬ静的なファイル取得システムを介して取得する（Ｓ１１）。
【００３７】
このようにして、レイアウト制御部２２は、必要な全ての部品ページ１１０〜１３０をそれぞれ取得する。レイアウト情報１００に従って、各部品ページ１１０〜１３０を所定の位置にそれぞれ配置し、出力画面（完成ページ２００）を生成する（Ｓ１２）。
【００３８】
そして、生成された完成ページ２００は、通信ネットワークを介して、ウェブサーバ２０からウェブブラウザ２に送信される（Ｓ１３）。ウェブブラウザ２には、単一のウェブページとして構成された完成ページ２００が表示される。上述のように、この完成ページ２００は、複数の部品ページ１１０〜１３０に由来しており、複数種類のコンテンツデータが含まれている。従って、見かけ上は、フレームの枠を消したフレーム画面に類似するが、フレーム画面とは異なり、複数のウェブページから構成されているわけでない。
【００３９】
次に、各ファイルＦ１〜Ｆ４の一例をそれぞれ説明する。図３は、タイル定義ファイルＦ１を示す説明図である。タイル定義ファイルＦ１の概略を部分的に説明すると、タイル定義ファイルＦ１は、レイアウトを決定すべきレイアウト定義ファイルＦ２を特定する（Ｆ１１）。また、タイル定義ファイルＦ１には、完成されたページ２００のタイトルが指定される（Ｆ１２）。
【００４０】
さらに、タイル定義ファイルＦ１では、動的な部品ページを生成し表示させるためのURL（Uniform Resource Locator）を指定することができる（Ｆ１３）。動的な部品ページとして指定された場合、その部品ページを生成するビジネスロジック３１に対して内部的なリクエストが発行されることになる。また、タイル定義ファイルＦ１には、静的な部品ページを表示させるための指定も含まれている（Ｆ１４）。
【００４１】
図４は、レイアウト定義ファイルＦ２の説明図である。レイアウト定義ファイルＦ２では、例えば、表示させるコンテンツ名等を指定する（Ｆ２１）。また、レイアウト定義ファイルＦ２では、コンテンツ表示位置等を指定することができる。
【００４２】
図５は。キャッシュ定義ファイルＦ３を示す説明図である。キャッシュ定義ファイルＦ３では、キャッシュ対象の部品ページを少なくとも一つ以上指定できる。そして、キャッシュ対象として指定された部品ページ毎に、キャッシュ制御用のパラメータをそれぞれ設定することができる。
【００４３】
例えば、そのキャッシュ対象の部品ページが、複数のユーザによって共有されるものであるのか（キャッシュタイプ＝”global”）、個別のユーザにのみ使用されるものであるのか（キャッシュタイプ＝”session”）を指定することができる（Ｆ３１）。また、キャッシュ定義ファイルＦ３では、キャッシュデータを特定するためのキーとなるパラメータを複数設定することもできる（Ｆ３２）。さらに、キャッシュメモリを制御するためのキャッシュ制御定義ファイルＦ４を指定することもできる（Ｆ３３）。
【００４４】
図６は、キャッシュ制御定義ファイルＦ４を示す説明図である。キャッシュ制御定義ファイルＦ４では、例えば、キャッシュ制御システムの種類を指定する（Ｆ４１）。キャッシュ制御システムとしては、例えば、（１）キャッシュをメモリに保持、（２）キャッシュをハードディスクにファイルとして保持、（３）キャッシュをメモリに保持するが、メモリの空き容量が一定量以下になった場合は、ファイルとして保持等のように、キャッシュさせる記憶デバイスの使用方法を挙げることができる。
これに加えて、例えば、（４）キャッシュをファイルとして保持し、キャッシュファイルのサイズが一定量を超えた場合は、古いものから削除する等のように、キャッシュ領域の解放方法まで指定することもできる。
【００４５】
さらに、キャッシュ制御定義ファイルＦ４では、より詳細な設定を行うことができる（Ｆ４２）。設定項目としては、例えば、（１）キャッシュファイルを保存させるディレクトリ名、（２）ハードディスクに保存するキャッシュファイルの最大記憶量、（３）メモリに保存するキャッシュの最大記憶量、（４）ウェブサーバ２０を再起動したときにキャッシュを削除するか否か、等を挙げることができる。
【００４６】
次に、動作の概略は既に図２と共に述べたが、本装置１０による画面出力処理の概要を図７を参照して説明する。ウェブサーバ２０は、クライアント端末１からのリクエストを検出すると（S21：YES）、レイアウト（タイル定義ファイルＦ１及びレイアウト定義ファイルＦ２）を選択する（Ｓ２２）。
【００４７】
ウェブサーバ２０は、キャッシュ定義ファイルＦ３を参照し、選択されたレイアウトにキャッシュ対象の部品ページが含まれているか否かを判定する（Ｓ２３）。そのレイアウトにおいて、キャッシュ対象に指定されている部品ページが使用される場合（S23：YES）、ウェブサーバ２０は、その部品ページがキャッシュされているか否かを判定する（Ｓ２４）。ウェブサーバ２０は、その部品ページがキャッシュされている場合（S24：YES）、キャッシュされている部品ページをメモリ等から読出して取得する（Ｓ２５）。
【００４８】
これに対し、選択されたレイアウト内でキャッシュ対象の部品ページが使用されていない場合（S23：NO）、ウェブサーバ２０は、部品ページを新たに生成する必要があるか否かを判定する（Ｓ２６）。生成の必要ありと判定した場合（S26：YES）、ウェブサーバ２０は、ビジネスロジック３１に部品ページを生成させる（Ｓ２７）。
ウェブサーバ２０は、キャッシュ定義ファイルＦ３に基づいて、この生成された部品ページをキャッシュするか否かを判定する（Ｓ２８）。生成された部品ページをキャッシュする場合（S28：YES）、ウェブサーバ２０は、所定の記憶デバイスにその部品ページを記憶させてから（Ｓ２９）、その部品ページを完成ページを生成するために取得する（Ｓ３０）。
【００４９】
一方、キャッシュ対象の部品ページがキャッシュされていない場合（S24：NO）、即ちキャッシュミスが発生した場合は、ウェブサーバ２０は、ビジネスロジック３１に指示を出して、その部品ページを新たに生成させる（Ｓ２７）。そして、ウェブサーバ２０は、生成した部品ページをキャッシュさせて（S28：YES、Ｓ２９）、完成ページの作成に使用する（Ｓ３０）。
【００５０】
ウェブサーバ２０は、完成ページを作成するために必要な全ての部品ページを取得したか否かを判定する（Ｓ３１）。取得していない部品ページが存在する場合（S31：NO）、ウェブサーバ２０は、上述した処理を繰り返す（Ｓ２３〜Ｓ３０）。
【００５１】
必要な全ての部品ページを取得した場合（S31：YES）、ウェブサーバ２０は、完成ページを作成し（Ｓ３２）、これをクライアント端末１に送信する（Ｓ３３）。
【００５２】
図８は、キャッシュを生成する処理の概略を示すフローチャートである。ウェブサーバ２０は、ビジネスロジック３１によって生成された部品データを取得すると（Ｓ４１）、キャッシュ定義ファイルＦ３を参照し（Ｓ４２）、この部品ページがキャッシュ対象として指定されているか否かを判定する（Ｓ４３）。キャッシュ対象でなければ、本処理は終了する（S43：NO）。
【００５３】
キャッシュ対象に指定されている部品ページを取得した場合（S43：YES）、ウェブサーバ２０は、その部品ページが共有指定されているか否かを判定する（Ｓ４４）。共有指定とは、複数のユーザによって共通に使用される部品ページであることを示す。共有指定された部品ページの場合（S44：YES）、ウェブサーバ２０は、共有キャッシュとして記憶し（Ｓ４５）、キャッシュ管理テーブルＴ２を更新させる（Ｓ４６）。キャッシュ管理テーブルＴ２については後述する。
【００５４】
共有指定されていない部品ページを取得した場合（S44：NO）、即ち、各ユーザ毎にそれぞれ使用される部品ページの場合、ウェブサーバ２０は、どのユーザに適用される部品ページであるかを特定するための情報を取得する（Ｓ４７）。このユーザ特定情報として、本実施例では、クライアント端末１との間のセッションを識別するためのセッション識別情報（図中「セッションID」）を使用する。ウェブサーバ２０は、取得した部品ページとセッション識別情報とを対応付けて、所定の記憶デバイスに記憶させ（Ｓ４８）、キャッシュ管理テーブルＴ２を更新させる（Ｓ４９）。
【００５５】
図９は、各部品ページの属性に応じて、キャッシュ方法がそれぞれ異なる例を示す説明図である。上述のように、キャッシュ定義ファイルＦ３では、キャッシュ対象の部品ページを指定し、指定された部品ページ毎にキャッシュタイプ（図９中の「共有属性」）等を設定することができる。
【００５６】
部品ページは、例えば、動的部品ページと静的部品ページとに分類できる。動的部品ページとは、例えば、要求される度に生成され、その内容が毎回異なるものを意味し、静的部品ページとは、例えば、その内容が一定で変化しないものを意味する。
【００５７】
本実施例では、動的部品ページ及び静的部品ページのいずれをもキャッシュ可能であるが、動的部品ページをキャッシュしておけば、ビジネスロジック３１を実行させる必要がなくなり、サーバ負荷が軽減される。そこで、例えば、動的部品ページを優先的にキャッシュするように、キャッシュ定義ファイルＦ３及びキャッシュ制御定義ファイルＦ４を構成してもよい。例えば、動的部品ページを優先的にメモリに記憶させ、メモリの空き容量が少なくなった場合は、静的部品ページから先に消去する。あるいは、動的部品ページをメモリに保持させ、静的部品ページをハードディスクに保持させることにより、動的部品ページをより速やかに取得することができ、ウェブサーバ２０の応答性をより改善することもできる。
【００５８】
図１０は、キャッシュ管理テーブルＴ２等を示す説明図である。キャッシュ管理テーブルＴ２は、例えば、ページ識別情報（図中、「PID」）と、各部品ページの共有属性と、セッションIDと、部品ページが記憶されるデバイス名と、部品ページの記憶先アドレスと、部品ページの更新トリガとを、それぞれ対応付けることにより構成可能である。
【００５９】
ページ識別情報は、キャッシュされている各部品ページをそれぞれ識別するための情報であり、例えば複数のパラメータの値を組み合わせることにより、生成される。同一のページ名であっても、その表示内容や更新時期等によって、ページ識別情報の値はそれぞれ異なる。共有属性とは、既に述べたように、その部品ページが複数のユーザにより共有されるページであるか、それとも各ユーザにより個別に使用されるページであるかを区別する情報である。セッションIDは、その部品ページが各ユーザ毎に使用される場合に、どのユーザに対して使用されるのかを特定するための情報である。格納先デバイス名は、部品ページが記憶されているデバイスを特定するための情報である。
【００６０】
更新トリガとは、その部品ページをキャッシュするタイミングを指定するための情報である。更新トリガとしては、例えば、（１）所定時間毎、（２）その部品ページの更新が要求される毎、等を挙げることができる。即ち、例えば、その部品ページの表示内容等の特性に応じて、キャッシュを定期的にまたは不定期に更新させることができる。例えば、衛星画像を表示する部品ページの場合、その衛星画像を出力するビジネスロジック３１の更新時期に合わせて、キャッシュを更新させることができる。また、例えば、検索結果を表示する部品ページの場合、ユーザから検索が要求された場合に、キャッシュを更新させることができる。
【００６１】
図１０中の下側には、部品データをキャッシュするための複数種類の記憶デバイスが示されている。ここで例えば、一つの記憶デバイスはメモリ１１であり、他の一つの記憶デバイスはハードディスク１２である。
【００６２】
メモリ１１もハードディスク１２もいずれもランダムアクセス可能な記憶デバイスであるが、CPUからのアクセス性の観点では、メモリ１１の方がハードディスク１２よりも高速にアクセス可能である。一方、記憶容量の観点では、ハードディスク１２の方がメモリ１１よりも多くの部品ページを記憶可能である。
【００６３】
そこで、例えば、このような記憶デバイスの特徴に基づいて、より速やかなアクセスが要求される部品ページやアクセス頻度の高い部品ページはメモリ１１に記憶させ、それ以外の部品ページをハードディスク１２に記憶させることができる。また、例えば、アクセス頻度を監視し、アクセス頻度が所定値以上に達した部品ページはハードディスク１２からメモリ１１に移し替え、逆に、アクセス頻度が所定値以下に達した部品はメモリ１１からハードディスク１２に移動させることもできる。あるいは、アクセス頻度に代えて、最後に使用されてからの経過時間に基づいて、記憶デバイス１１，１２間を移動させるようにしてもよい。
【００６４】
本実施例は、上述のように構成されるので、以下の効果を奏する。本実施例では、完成ページを構成する各部品ページをそれぞれ個別にキャッシュ可能とし、キャッシュされた部品ページを再利用して完成ページを生成可能な構成とした。従って、クライアント端末１からリクエストされるたびに全ての部品ページをそれぞれ新たに生成し直す必要がなく、ウェブサーバ２０やアプリケーションサーバ３０等の処理負担をそれぞれ低減することができ、ウェブサーバ２０の応答性能を向上させることができる。
【００６５】
本実施例では、各部品ページ毎に、それぞれ共有属性を指定可能な構成とした。従って、キャッシュ可能な部品ページの範囲を広げることができ、これにより、一層の処理負担軽減と応答性の改善を図ることができる。つまり、本実施例では、ユーザ固有の情報を含む部品ページであっても、そのユーザを特定するための情報（セッションID）と対応付けて管理することにより、そのユーザ固有の部品ページをキャッシュして再利用できる構成を採用する。従って、キャッシュ可能な部品ページが増加し、再利用の可能性を高めて、より一層のサーバ負担の軽減及び応答性改善を図ることができる。
【００６６】
本実施例では、ウェブブラウザ２からのリクエストの内容毎にそれぞれ生成される動的な部品ページをキャッシュ可能な構成とした。従って、ビジネスロジック３１を稼働させて部品ページを作り直す手間がいらず、より一層サーバ負担を軽減し、応答性を改善することができる。
【００６７】
本実施例では、各部品ページ毎にそれぞれ異なるタイミングでキャッシュ可能な構成を採用した。従って、各部品ページの特徴に応じた適切なタイミングで、各部品ページをそれぞれキャッシュすることができる。
【実施例２】
【００６８】
図１１に基づいて、第２実施例を説明する。本実施例では、各部品ページのキャッシュを更新させる時期が到来したか否かを監視し、自動的にキャッシュデータを更新させるようにしている。
【００６９】
図１１は、本実施例のキャッシュ生成処理の概略を示すフローチャートである。ウェブサーバ２０は、キャッシュ定義ファイルＦ３を参照し（Ｓ５１）、キャッシュデータの更新時期が到来したか否かを判定する（Ｓ５２）
【００７０】
メモリ等にキャッシュされている部品ページの更新時期である場合（S52：YES）、ウェブサーバ２０は、その部品ページの最新のデータを取得する（Ｓ５３）。例えば、その部品ページが動的なページである場合、その部品ページを生成するビジネスロジック３１に内部的な指示を発行し、新たな部品ページを生成させる。
【００７１】
ウェブサーバ２０は、最新の部品ページを取得すると、この部品ページをメモリ等に記憶させ（Ｓ５４）、キャッシュ管理テーブルＴ２を更新させる（Ｓ５５）。ウェブサーバ２０は、キャッシュ定義ファイルＦ３に登録されている全ての部品ページについてキャッシュ更新を行ったか否かを判定する（Ｓ５６）。なお、その部品ページのキャッシュ更新時期が到来していない場合（S52：NO）、Ｓ５３〜Ｓ５５はスキップされ、Ｓ５６に移行する。
【００７２】
更新の是非を判定していない部品ページが残っている場合（S56：NO）、ウェブサーバ２０は、キャッシュ定義ファイルＦ３に登録されている次の部品ページに移動し（Ｓ５７）、上述したＳ５１〜Ｓ５６をそれぞれ繰り返す。そして、ウェブサーバ２０が、全ての部品ページについてキャッシュ更新の有無を判断し、更新が必要な部品データのキャッシュデータを更新させると（S56：YES）、本処理を終了する。
【００７３】
このように構成される本実施例でも、前記実施例と同様の効果を奏する。これに加えて、本実施例では、クライアントからのリクエストの有無を問わずに、部品ページのキャッシュデータを更新させるか否かを定期的に（または不定期に）判断し、自動的にキャッシュを更新させる構成とした。従って、本実施例では、例えば、クライアントからのリクエストを受信する前に、キャッシュデータを最新の状態を保持しておくことができ、リクエストに対して速やかに応答することができる。
【００７４】
また、本実施例の変形例として、ウェブサーバ２０の処理負荷を監視し、処理負荷が所定値以下の場合に、即ち、ウェブサーバ２０の負荷が軽い時間帯を利用して、キャッシュデータを自動的に更新させることもできる。また、例えば、各部品ページの属性（共有ページか否か、アクセス頻度の大小等）を考慮し、相対的に必要性の高い部品ページは定期的にキャッシュを更新し、相対的に必要性の低い部品ページはクライアントからのリクエストを待ってキャッシュを更新させることもできる。
【００７５】
なお、本発明は、上述した実施の形態に限定されない。当業者であれば、本発明の範囲内で、種々の追加や変更等を行うことができる。例えば、当業者であれば、前記各実施例を適宜組み合わせることができる。
【図面の簡単な説明】
【００７６】
【図１】本実施例によるウェブページ提供装置の全体構成を示すブロック図である。
【図２】ウェブページ提供装置の全体動作等を示す構成説明図である。
【図３】タイプ定義ファイルの一例を示す説明図である。
【図４】レイアウト定義ファイルの一例を示す説明図である。
【図５】キャッシュ定義ファイルの一例を示す説明図である。
【図６】キャッシュ制御定義ファイルの一例を示す説明図である。
【図７】完成されたページをクライアントに提供する処理を示すフローチャートである。
【図８】キャッシュ生成処理を示すフローチャートである。
【図９】キャッシュ定義ファイルとキャッシュ対象の種類との関係を示す説明図である。
【図１０】キャッシュ管理テーブル及びキャッシュに使用する記憶デバイスとの関係を示す説明図である。
【図１１】本発明の他の実施例によるキャッシュ生成処理を示すフローチャートである。
【符号の説明】
【００７７】
１…クライアント端末、２…ウェブブラウザ、１０…ウェブページ提供装置、１１…メモリ、１２…ハードディスク、２０…ウェブサーバ、２１…リクエスト制御部、２２…レイアウト制御部、２３…キャッシュ制御部、３０…アプリケーションサーバ、３１，３１Ａ，３１Ｂ…ビジネスロジック、４０…データベースサーバ、１００…レイアウト情報、１０１，１０２，１０３…部品ページの表示領域、１１０，１２０，１３０…部品ページ、２００…完成ページ、Ｆ１…タイル定義ファイル、Ｆ２…レイアウト定義ファイル、Ｆ３…キャッシュ定義ファイル、Ｆ４…キャッシュ制御定義ファイル、Ｔ２…キャッシュ管理テーブル
【特許請求の範囲】
【請求項１】
少なくとも一つ以上のコンテンツデータを含むウェブページをそれぞれ生成する複数のウェブページ生成手段と、
これら各ウェブページ生成手段により生成される前記各ウェブページの全部または一部を、予め設定された記憶条件に基づいて、記憶手段に記憶させる記憶制御手段と、
前記各ウェブページ生成手段により生成された各ウェブページを所定のレイアウト情報に基づいてそれぞれ配置することにより、単一のウェブページを生成してウェブブラウザに提供するレイアウト制御手段と、
前記ウェブブラウザから前記単一のウェブページへのリクエストを検出するリクエスト制御手段とを備え、
前記レイアウト制御手段は、前記リクエスト制御手段によって前記ウェブブラウザからのリクエストが検出された場合は、前記記憶手段に記憶されている前記各ウェブページの少なくとも一部を再利用して、前記単一のウェブページを生成可能であるウェブページ提供装置。
【請求項２】
前記レイアウト制御手段は、前記リクエスト制御手段によって前記リクエストが検出された場合は、前記記憶手段に記憶されている前記各ウェブページのうち再利用可能なウェブページを前記記憶手段から取得し、この再利用可能なウェブページ以外の各ウェブページについては前記各ウェブページ生成手段によって新たに生成させる請求項１に記載のウェブページ提供装置。
【請求項３】
前記記憶制御手段は、前記各ウェブページ単位で、前記記憶手段に記憶させるか否かを制御する請求項１に記載のウェブページ提供装置。
【請求項４】
前記記憶制御手段は、前記各ウェブページの属性に基づいて、前記各ウェブページ毎に前記記憶手段に記憶させるか否かをそれぞれ制御する請求項１に記載のウェブページ提供装置。
【請求項５】
前記記憶制御手段は、前記ウェブブラウザからのリクエストの内容毎にそれぞれ生成される動的なウェブページを前記記憶手段に記憶させる請求項４に記載のウェブページ提供装置。
【請求項６】
前記記憶制御手段は、複数のユーザによって共有される共有ウェブページと、各ユーザによって個別に使用される個別ウェブページとに分けて、前記記憶手段に記憶させる請求項４に記載のウェブページ提供装置。
【請求項７】
前記記憶制御手段は、前記各ウェブページ毎にそれぞれ異なるタイミングで、該各ウェブページを前記記憶手段に記憶可能である請求項１に記載のウェブページ提供装置。
【請求項８】
ウェブブラウザからのリクエストを検出するステップと、
前記リクエストが検出された場合は、所定のレイアウト情報に基づいて、必要なウェブページを特定するステップと、
前記特定されたウェブページのうち記憶手段に記憶されているウェブページが存在するか否かを確認するステップと、
前記記憶手段に記憶されているウェブページを取得するステップと、
前記特定されたウェブページのうち前記記憶手段に記憶されていないウェブページを生成させるステップと、
この生成されたウェブページ及び前記記憶手段から取得されたウェブページを前記所定のレイアウト情報に基づいてそれぞれ配置することにより、単一のウェブページを生成するステップと、
この生成された単一のウェブページを前記ウェブブラウザに送信するステップと、
を含むウェブページ提供方法。
【請求項９】
前記記憶手段に記憶されていないウェブページを生成させるステップの次に、この生成されたウェブページを前記記憶手段に記憶させるステップを備えた請求項８に記載のウェブページ提供方法。
【請求項１０】
ウェブブラウザからのリクエストを検出する第１機能と、
少なくとも一つ以上のコンテンツデータを含むウェブページをそれぞれ生成する複数の第２機能と、
これら各第２機能により生成される前記各ウェブページの全部または一部を、予め設定された記憶条件に基づいて、キャッシュメモリに記憶させる第３機能と、
前記リクエストが検出された場合は、前記キャッシュメモリに記憶されているウェブページと前記第２機能により新たに生成されたウェブページとを、所定のレイアウト情報に基づいてそれぞれ配置することにより、単一のウェブページを生成する第４機能と、
この生成された単一のウェブページを前記ウェブブラウザに送信させる第５機能と、
をコンピュータ上にそれぞれ実現させるためのコンピュータプログラム。
【請求項１】
少なくとも一つ以上のコンテンツデータを含むウェブページをそれぞれ生成する複数のウェブページ生成手段と、
これら各ウェブページ生成手段により生成される前記各ウェブページの全部または一部を、予め設定された記憶条件に基づいて、記憶手段に記憶させる記憶制御手段と、
前記各ウェブページ生成手段により生成された各ウェブページを所定のレイアウト情報に基づいてそれぞれ配置することにより、単一のウェブページを生成してウェブブラウザに提供するレイアウト制御手段と、
前記ウェブブラウザから前記単一のウェブページへのリクエストを検出するリクエスト制御手段とを備え、
前記レイアウト制御手段は、前記リクエスト制御手段によって前記ウェブブラウザからのリクエストが検出された場合は、前記記憶手段に記憶されている前記各ウェブページの少なくとも一部を再利用して、前記単一のウェブページを生成可能であるウェブページ提供装置。
【請求項２】
前記レイアウト制御手段は、前記リクエスト制御手段によって前記リクエストが検出された場合は、前記記憶手段に記憶されている前記各ウェブページのうち再利用可能なウェブページを前記記憶手段から取得し、この再利用可能なウェブページ以外の各ウェブページについては前記各ウェブページ生成手段によって新たに生成させる請求項１に記載のウェブページ提供装置。
【請求項３】
前記記憶制御手段は、前記各ウェブページ単位で、前記記憶手段に記憶させるか否かを制御する請求項１に記載のウェブページ提供装置。
【請求項４】
前記記憶制御手段は、前記各ウェブページの属性に基づいて、前記各ウェブページ毎に前記記憶手段に記憶させるか否かをそれぞれ制御する請求項１に記載のウェブページ提供装置。
【請求項５】
前記記憶制御手段は、前記ウェブブラウザからのリクエストの内容毎にそれぞれ生成される動的なウェブページを前記記憶手段に記憶させる請求項４に記載のウェブページ提供装置。
【請求項６】
前記記憶制御手段は、複数のユーザによって共有される共有ウェブページと、各ユーザによって個別に使用される個別ウェブページとに分けて、前記記憶手段に記憶させる請求項４に記載のウェブページ提供装置。
【請求項７】
前記記憶制御手段は、前記各ウェブページ毎にそれぞれ異なるタイミングで、該各ウェブページを前記記憶手段に記憶可能である請求項１に記載のウェブページ提供装置。
【請求項８】
ウェブブラウザからのリクエストを検出するステップと、
前記リクエストが検出された場合は、所定のレイアウト情報に基づいて、必要なウェブページを特定するステップと、
前記特定されたウェブページのうち記憶手段に記憶されているウェブページが存在するか否かを確認するステップと、
前記記憶手段に記憶されているウェブページを取得するステップと、
前記特定されたウェブページのうち前記記憶手段に記憶されていないウェブページを生成させるステップと、
この生成されたウェブページ及び前記記憶手段から取得されたウェブページを前記所定のレイアウト情報に基づいてそれぞれ配置することにより、単一のウェブページを生成するステップと、
この生成された単一のウェブページを前記ウェブブラウザに送信するステップと、
を含むウェブページ提供方法。
【請求項９】
前記記憶手段に記憶されていないウェブページを生成させるステップの次に、この生成されたウェブページを前記記憶手段に記憶させるステップを備えた請求項８に記載のウェブページ提供方法。
【請求項１０】
ウェブブラウザからのリクエストを検出する第１機能と、
少なくとも一つ以上のコンテンツデータを含むウェブページをそれぞれ生成する複数の第２機能と、
これら各第２機能により生成される前記各ウェブページの全部または一部を、予め設定された記憶条件に基づいて、キャッシュメモリに記憶させる第３機能と、
前記リクエストが検出された場合は、前記キャッシュメモリに記憶されているウェブページと前記第２機能により新たに生成されたウェブページとを、所定のレイアウト情報に基づいてそれぞれ配置することにより、単一のウェブページを生成する第４機能と、
この生成された単一のウェブページを前記ウェブブラウザに送信させる第５機能と、
をコンピュータ上にそれぞれ実現させるためのコンピュータプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【公開番号】特開２００６−２２７６７１（Ｐ２００６−２２７６７１Ａ）
【公開日】平成１８年８月３１日（２００６．８．３１）
【国際特許分類】
【出願番号】特願２００５−３７１１８（Ｐ２００５−３７１１８）
【出願日】平成１７年２月１５日（２００５．２．１５）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＪＡＶＡ
【出願人】（０００１５５４６９）株式会社野村総合研究所 (1,067)
【Ｆターム（参考）】
【公開日】平成１８年８月３１日（２００６．８．３１）
【国際特許分類】
【出願日】平成１７年２月１５日（２００５．２．１５）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＪＡＶＡ
【出願人】（０００１５５４６９）株式会社野村総合研究所 (1,067)
【Ｆターム（参考）】
[ Back to top ]