JP4732916B2 - 画面情報生成方法、画面情報生成システムおよび画面情報生成プログラム - Google Patents

Description

本発明は、端末に提供する画面情報を生成する技術に関する。

現在、インターネット上では、様々なＷｅｂページ（文書）が公開されている。例えば、特許文献１には、フレームと呼ばれる画面分割技術を用いてＷｅｂページに複数のコンテンツを表示させるフレーム分割プログラムが記載されている。しかしながら、フレームを用いた場合、画面を仕切る枠（フレーム）やスクロールバーが画面上に表示されてしまうため、デザイン的に見栄えが悪くなる場合がある。また、フレームを用いた場合、クライアントのＷｅｂブラウザは、１つのＷｅｂページを表示するためにフレーム数分のＨＴＭＬファイルを要求するため、ネットワーク上の負荷が増大する。

そこで、フレーム分割を行わずＭＶＣ（Model，View，Controller）モデルを用いてＷｅｂページを作成することが考えられる。ＭＶＣモデルでは、１つのView（画面）に対して、１つのModel（ビジネスロジック、アプリケーション）が対応する。そのため、１つのViewに複数のコンテンツを表示する場合は、複数のビジネスロジックを１つに統合したビジネスロジックを、View毎に作成する必要がある。

また、サーブレットＡＰＩを利用した技術として、例えばStrutsが存在する。Strutsは、Apache Software Licenseに基づいて公開されたオープンソースのソフトウェアであって、ＪＳＰ（Java Server Pages）からサーブレット（servlet）、ＪＳＰ、静的ページを呼び出すことができる。
特開２００４−２４６７６３

ＭＶＣモデルでは、前述の通り、１つのViewに複数のコンテンツを表示する場合は、複数のビジネスロジックを１つに統合したビジネスロジックをView毎に作成する必要がある。したがって、使用する画面の数が増えると、画面の数だけ新たなビジネスロジックが必要となり、システムの生産性および保守性の観点において、非効率的である。

また、サーブレットＡＰＩを利用した技術の場合、ＪＳＰはサーブレットなどを介して複数のビジネスロジックを呼び出すことができる。しかしながら、ＪＳＰがビジネスロジックを呼び出す際のリクエストは、クライアントから受け付けたリクエストと同じリクエストである。そのため、画面のレイアウトによっては、クライアントから受け付けたリクエストとは異なるパラメータでビジネスロジックを呼び出す必要がある場合については、考慮されていない。

本発明は上記事情に鑑みてなされたものであり、本発明の目的は、画面の生成と、画面を構成するビジネスロジックとを分離して作成して、ビジネスロジックの再利用を容易にすることにより、システムの生産性および保守性をより向上させることにある。

上記課題を解決するために、本発明は、例えば、情報処理装置が行う画面情報生成方法であって、前記情報処理装置は、端末から送信されたメインリクエストを受け付ける受け付けステップと、前記メインリクエストに基づいて、少なくとも１つのサブリクエストを生成するサブリクエスト生成ステップと、前記各サブリクエストを発行し、当該サブリクエストで要求するコンテンツを取得する取得ステップと、前記取得した各コンテンツを統合し、１つの画面情報を生成する画面情報生成ステップと、を行う。

また、本発明は、画面情報生成システムであって、端末から送信されたメインリクエストを受け付ける要求受付手段と、前記メインリクエストに基づいて、少なくとも１つのサブリクエストを生成するサブリクエスト生成手段と、前記各サブリクエストを発行し、当該サブリクエストで要求するコンテンツを取得する取得手段と、前記取得した各コンテンツを統合し、１つの画面情報を生成する画面情報生成手段と、を有する。

また、本発明は、情報処理装置が実行する画面情報生成プログラムであって、前記情報処理装置に、端末から送信されたメインリクエストを受け付ける受け付けステップと、前記メインリクエストに基づいて、少なくとも１つのサブリクエストを生成するサブリクエスト生成ステップと、前記各サブリクエストを発行し、当該サブリクエストで要求するコンテンツを取得する取得ステップと、前記取得した各コンテンツを統合し、１つの画面情報を生成する画面情報生成ステップと、を実行させる。

本発明では、画面の生成と、画面を構成するビジネスロジックとを分離して作成して、ビジネスロジックの再利用を容易にすることにより、システムの生産性および保守性をより向上させることができる。

以下、本発明の実施の形態について説明する。

図１は、本発明の一実施形態が適用されたＷｅｂシステムの全体構成図である。本実施形態のＷｅｂシステムは、少なくとも１つのクライアント１と、Ｗｅｂサーバ２と、アプリケーションサーバ３と、を有する。そして、各クライアント１とＷｅｂサーバ２とは、インターネットなどのネットワーク４により接続されている。

クライアント１のＷｅｂブラウザ１１は、ユーザの指示を受け付けてＷｅｂサーバ２から所望の情報を取得し、出力装置（不図示）に表示する。

Ｗｅｂサーバ２は、各クライアント１からの要求を受け付けて、クライアント１に提供する情報を動的に生成し、生成した情報をクライアント１に送信する。なお、本実施形態では、クライアント１に提供する情報は、Ｗｅｂページを表示するための情報（以下、「画面情報」）とする。画面情報は、ＨＴＭＬ（HyperText Markup Language）、ＸＭＬ（eXtensible Markup Language）などのマークアップ言語により記述されているが、本実施形態ではＨＴＭＬにより記述された画面情報を例として以下説明する。

図示するＷｅｂサーバ２は、要求受付部２１と、画面生成部２２と、少なくとも１つの情報生成ファイル２３と、キャッシュメモリ２４と、を有する。要求受付部２１は、クライアント１が送信した要求（以下、「メインリクエスト」）を受け付け、受け付けたメインリクエストを情報生成ファイル２３（または、画面生成部２２）に引き渡す。なお、要求受付部２１は、例えばサーブレット（servlet）であるものとする。

画面生成部２２は、クライアント１に提供する画面情報を動的に生成し、生成した画面情報をクライアント１に送信する。なお、本実施形態の画面生成部２２は、情報生成ファイル２３のプログラムを実行することにより、上記処理を実行するものとする。

情報生成ファイル２３は、例えば、ＪＳＰ（Java Server Pages）の技術を用いたＪＳＰファイルである。すなわち、情報生成ファイル２３は、ＨＴＭＬで記述された画面情報の中に、Ｊａｖａ（登録商標）プログラムが記述されたファイルである。画面生成部２２は、情報生成ファイル２３に記述されたＪａｖａ（登録商標）プログラムを実行することにより、画面情報（ＨＴＭＬファイル）を動的に生成し、クライアント１に送信する。また、本実施形態の情報生成ファイル２３では、ビジネスロジック３１にアクセスするためのサーブレット（不図示）を呼び出すことができるものとする。なお、情報生成ファイル２３は、メモリまたは外部記憶装置に記憶されている。キャッシュメモリ２４は、高速な記憶装置であって、アプリケーションサーバ３から取得したコンテンツが記憶される。

アプリケーションサーバ３は、複数のビジネスロジック３１を有する。各ビジネスロジック３１は、Ｗｅｂサーバ２ら送信された要求を受け付けて所定の業務処理を行い、処理結果をＷｅｂサーバ６に送信する。

上記説明した、クライアント１、Ｗｅｂサーバ２およびアプリケーションサーバ３は、いずれも、例えば図２に示すようなＣＰＵ９０１と、メモリ９０２と、ＨＤＤ等の外部記憶装置９０３と、キーボードやマウスなどの入力装置９０４と、ディスプレイやプリンタなどの出力装置９０５と、ネットワークと接続するための通信制御装置９０６と、を備えた汎用的なコンピュータシステムを用いることができる。このコンピュータシステムにおいて、ＣＰＵ９０１がメモリ９０２上にロードされた所定のプログラムを実行することにより、各装置の各機能が実現される。

例えば、クライアント１、Ｗｅｂサーバ２およびアプリケーションサーバ３の各機能は、クライアント１用のプログラムの場合はクライアント１のＣＰＵ９０１が、Ｗｅｂサーバ２用のプログラムの場合はＷｅｂサーバ２のＣＰＵ９０１が、そして、アプリケーションサーバ３用のプログラムの場合はアプリケーションサーバ３のＣＰＵ９０１が、それぞれ実行することにより実現される。なお、入力装置９０４および出力装置９０５については、各装置が必要に応じて備えるものとする。また、Ｗｅｂサーバ２およびアプリケーションサーバ３は、１つのコンピュータ装置内に設けることとしてもよい。

次に、クライアント１の出力装置に表示される表示画面（Ｗｅｂページ）について説明する。なお、本実施形態の表示画面は、フレーム機能を用いて画面を複数のフレームで仕切ることなく、１つの画面内に複数のコンテンツが表示されるものとする。また、表示画面における各コンテンツの配置場所などのレイアウト情報は、情報生成ファイル２３に定義されているものとする。

図３は、表示画面の一例を示す図である。クライアント１のＷｅｂブラウザ１１は、Ｗｅｂサーバ２から受信した画面情報（ＨＴＭＬファイル）を解析し、図示するような表示画面を出力装置に出力する。なお、図示する表示画面は、デイトレーダーなどの個人投資家がネットワークを介して株式など売買するオンライントレードの画面例である。図示する表示画面は、メニュー５１、パーソナルメッセージ５２、マーケット情報５３、および新規公開株情報５４の４つのコンテンツから構成されるものとする。

パーソナルメッセージ５２、マーケット情報５３、および新規公開株情報５４は、クライアント１からの要求に応じて、後述する処理により動的に生成されるコンテンツである。メニュー５１は、あらかじめ定められた固定情報（静的コンテンツ）であって、情報生成ファイル２３に記述されているものとする。

次に、本実施形態のＷｅｂシステムの処理について説明する。

図４は、Ｗｅｂシステムの処理を模式的に示した図である。なお、図示する処理は、図３に示す表示画面を生成する場合を例として示したものである。

まず、クライアント１のＷｅｂブラウザ１１は、ユーザの指示を受け付けて、メインリクエストをＷｅｂサーバ２に送信する（Ｓ１１）。なお、メインリクエストには、ユーザＩＤが含まれているものとする。

Ｗｅｂサーバ２の要求受付部（サーブレット）２１は、メインリクエストを受信し、当該メインリクエストに含まれる情報を引数として、アプリケーションサーバ３のメインリクエスト用ビジネスロジック３１ａにアクセスする。そして、メインリクエスト用ビジネスロジック３１ａは、メインリクエストの情報に基づいて応答データを生成し、生成した応答データを要求受付部２１に送信する（Ｓ１２）。

なお、図示するメインリクエスト用ビジネスロジック３１ａは、応答データとして、メインリクエストに含まれるユーザＩＤが所有する口座情報をデータベース（不図示）から取得するものとする。また、口座情報は、ユーザの保有商品に関する情報（例えば、株式の銘柄、株数、ファンド名など）である。

そして、要求受付部２１は、メインリクエスト用ビジネスロジック３１ａから受信した応答データおよびメインリクエストに基づいて、所定の情報生成ファイル（ＪＳＰファイル）２３を特定する。そして、要求受付部２１は、特定した情報生成ファイル２３に、メインリクエストおよび応答データを引き渡す（Ｓ１３）。これにより、画面生成部２２は、指定された情報生成ファイル２３の中に記述されたプログラムを実行して、以下の処理を行う。すなわち、画面生成部２２は、情報生成ファイル２３を実行し、画面情報（ＨＴＭＬファイル）２３９を生成する。

まず、画面生成部２２は、メインリクエストおよび応答データを、メインリクエスト用のコンテキスト（以下、「コンテキスト（メイン）」）２３１に記憶する。コンテキストは、実行中のプログラムで用いる引数（パラメータ）、処理結果、ステータスなどを記憶するための領域である。

そして、画面生成部２２は、コンテキスト（メイン）２３１に記憶されたメインリクエストおよび応答データに基づいてサブリクエストを生成し、サブリクエスト用のコンテキスト（以下、「コンテキスト（サブ）」）２３２に記憶する（Ｓ１４）。サブリクエストは、クライアントからのメインリクエストと区別するための用語であって、サーバ内で発生するものである。なお、図示する例では図３に示す画面情報を生成するため、パーソナルメッセージを取得するためのサブリクエスト＃１と、マーケット情報を取得するためのサブリクエスト＃２と、新規公開株情報を取得するためのサブリクエスト＃３とを生成する。そして、各サブリクエストは、コンテキスト（メイン）２３１とは別のコンテキスト（サブ）２３２で、それぞれ実行される。

例えば、サブリクエスト＃１の場合、コンテキスト（メイン）２３１の情報（口座情報 等）を参照し、ユーザが保有する商品の種類（株式、投資信託、債券など）毎に、当該商品に関する情報を要求することが考えられる。具体的には、「○○様へのお知らせ」として、保有商品が株式の場合は日経平均を要求するためのサブリクエストを生成し、保有商品が投資信託の場合は投信平均を要求するためのサブリクエストを生成することが考えられる。また、サブリクエスト＃２の場合、コンテキストメイン２３１の情報（口座情報 等）を参照し、ユーザが保有する商品の時価総額を要求することが考えられる。また、サブリクエスト＃３の場合、新規公開株の情報を要求することが考えられる。

そして、画面生成部２２は、生成したサブリクエスト各々を、当該サブリクエストに対応するサーブレット２８にそれぞれ送出する（Ｓ１５）。なお、サーブレット側では、サブリクエストがあたかもクライアント１から送出されたリクエストのように見える。

そして、各サーブレット２８は、アプリケーションサーバ３の対応するサブリクエスト用ビジネスロジック３１ｂにそれぞれアクセスする。各サブリクエスト用ビジネスロジック３１ｂは、受け付けたサブリクエストに基づいて、応答データとしてコンテンツを生成し、サーブレット２８に送出する。そして、画面生成部２２は、各サーブレット２８からコンテンツを受け付け、対応するコンテキスト（サブ）２３２に記憶する（Ｓ１７）。

サブリクエスト＃１に対する応答データとしては、例えば、日経平均または投信平均が記述されたパーソナルメッセージのコンテンツ＃１（ＨＴＭＬファイル）が生成される。また、サブリクエスト＃２に対する応答データとしては、例えば、保有商品の時価情報が記述されたマーケット情報のコンテンツ＃２が生成される。また、サブリクエスト＃３に対する応答データとしては、例えば、新規公開株の情報が記述されたコンテンツ＃３が生成される。

そして、画面生成部２２は、情報生成ファイル２３に定義されたレイアウト情報を参照し、各コンテキスト（サブ）２３２のコンテンツ（応答データ）を所定の位置に配置して、画面情報２３９を生成する（Ｓ１８）。すなわち、画面生成部２２は、情報生成ファイル２３のＪＳＰタグ部分に、取得したコンテンツを埋め込むことにより、ＪＳＰタグ部分をＨＴＭＬ形式のタグへと変換し、ＨＴＭＬのみで記述された画面情報（ＨＴＭＬファイル）２３９を動的に生成する。そして、画面生成部２２は、生成した画面情報２３９をクライアント１に送信する（Ｓ１９）。そして、クライアント１のＷｅｂブラウザ１１は、画面情報２３９のタグを解析し、図３に示すような表示画面を出力装置に表示する。

以上説明したように、本実施形態では、コンテキスト（メイン）２３１に基づいてサブリクエストを生成し、サーブレット２８にサブリクエストを発行する。そして、サブリクエストは、コンテキスト（メイン）２３１とは別のコンテキスト（サブ）２３２でそれぞれ実行される。これにより、本実施形態では、情報生成ファイル２３が各サーブレット２８を呼び出す際に、メインリクエストに対応する応答データ（ステータスを含む）の影響を受けることがない。したがって、メインリクエストや他のサブリクエストの処理により、意図しないステータス（attribute）の変更を回避することができる。

次に、画面生成部２２がサブリクエストを発行し、コンテンツを取得する処理（図４：Ｓ１５〜Ｓ１７）について、さらに詳しく説明する。

図５は、画面生成部２２が行うコンテンツ取得処理のフローチャートである。なお、図示する処理は、サブリクエスト毎にそれぞれ行われる。まず、画面生成部２２は、コンテキスト（サブ）２３２からサブリクエストを読み出す（Ｓ２１）。そして、画面生成部２２は、読み出したサブリクエストに対応するコンテンツがキャッシュメモリ２４に記憶されているか否かを判別する（Ｓ２２）。

要求するコンテンツがキャッシュメモリ２４に記憶されていない場合（Ｓ２２：ＮＯ）、画面生成部２２は、図４で説明したように、対応するサーブレット２８にサブリクエストを送出し、コンテンツを要求する（Ｓ２３）。そして、画面生成部２２は、ビジネスロジックが生成したコンテンツを、サーブレット２８から取得する（Ｓ２４）。そして、画面生成部２２は、取得したコンテンツをコンテキスト（サブ）２３２に記憶する。また、画面生成部２２は、取得したコンテンツにユーザ固有情報が記述されている場合、当該ユーザ固有情報を所定の文字列（以下、「置換文字列」）に置換し、置換後のコンテンツをキャッシュメモリ２４に記憶する（Ｓ２５）。なお、ユーザ固有情報としては、セッション情報やユーザ属性情報などが考えられる。

一方、要求するコンテンツが、キャッシュメモリ２４に既に記憶されている場合（Ｓ２２：ＹＥＳ）、画面生成部２２は、キャッシュメモリ２４から当該コンテンツを取得する（Ｓ２６）。なお、キャッシュメモリ２４に記憶されているコンテンツは、前述の通りユーザ固有情報が置換文字列に置換されている。そのため、画面生成部２２は、キャッシュメモリ２４から取得したコンテンツに置換文字列が存在するか否かを判別し、置換文字列が存在する場合は当該置換文字列をユーザ固有情報に復元（置換）する。そして、画面生成部２２は、ユーザ固有情報を復元したコンテンツを、コンテキスト（サブ）２３２に記憶する（Ｓ２７）。なお、ユーザ固有情報は、メインリクエストとともにクライアント１から送信され、Ｗｅｂサーバ２のメモリなど記憶されるものとする。

以上説明したように、コンテンツのユーザ固有情報を所定の置換文字列に置換してキャッシュメモリ２４に記憶し、キャッシュメモリ２４に記憶されたコンテンツの置換文字列をユーザ固有情報に復元してコンテンツを再利用する。これにより、ビジネスロジックが同じコンテンツをその都度新たに生成する場合に比べて、処理負荷を低減させ、クライアント１への応答時間を短縮することができる。

例えば、図３に示す表示画面の場合、新規公開株情報のコンテンツ５４については、各ユーザに同じ内容の情報を提供する。このようなコンテンツについては、キャッシュメモリ２４にコンテンツを記憶しておくことで、より効果的に処理負荷を低減させ、クライアントへの応答時間を短縮することができる。

次に、画面生成部２２が画面情報２３９を生成する処理（図４：Ｓ１８）について、さらに詳しく説明する。

図６は、画面生成部２２が行う画面情報生成処理のフローチャートである。なお、画面生成部２２は、以下に説明するＳ３１からＳ３４の処理を、コンテキスト（サブ）毎にそれぞれ行うものとする。

画面生成部２２は、サブリクエストの処理結果を示すステータスが、正常か否かを判別する（Ｓ３１）。なお、ステータスは、コンテンツの取得に成功したか、または、コンテンツの取得に失敗したかなどのコンテンツの取得状況を示すものである。サーブレット２８から受け付けたステータスは、応答データの１つとしてコンテンツとともにコンテキスト（サブ）２３２に記憶される。

ステータスが正常の場合（Ｓ３１：ＹＥＳ）、画面生成部２２は、コンテキスト（サブ）２３２に記憶されたコンテンツに、所定の文字列が記述されているか否かを判別する（Ｓ３２）。所定の文字列としては、例えば、該当するデータが存在しないことを示す「保有株式がありません」、または、エラーメッセージの「申し訳ございません」などが考えられる。

ステータスがエラーの場合（Ｓ３１：ＮＯ）、または、所定の文字列を含む場合（Ｓ３２：ＹＥＳ）、画面生成部２２は、当該サブリクエストに対するコンテンツを、所定のコンテンツに差し替える（Ｓ３３）。

図７は、コンテンツの差し替えを模式的に示した図である。図７（ａ）は、正常な応答データ７２がコンテキスト（サブ＃２）７１に記憶されている場合（Ｓ３１：ＹＥＳかつＳ３２：ＮＯ）を示したものである。この場合、応答データであるマーケット情報のコンテンツ７２が、表示画面の所定の位置７３に埋め込まれる。

図７（ｂ）は、不正常な応答データ７５がコンテキスト（サブ＃２）７４に記憶されている場合（Ｓ３１：ＮＯまたはＳ３２：ＹＥＳ）を示したものである。この場合、図示するような不正常な応答データ７５を、あらかじめ定められた所定のコンテンツに差し替え、表示画面の所定の位置７６に埋め込む。なお、差し替え用のコンテンツは、表示画面全体のデザイン上、違和感がないコンテンツをあらかじめ用意しておくものとする。図示する例では、マーケット情報の替わりに、新サービスの案内を示すコンテンツ７６に差し替える。

不正常な応答データを別のコンテンツに差し替えることにより、不正常な応答データをそのまま埋め込むことにより発生する表示画面のデザイン上の問題（違和感、画面の破壊など）を回避することができる。また、画面生成部２２がこのようなコンテンツの差し替えを行うため、ビジネスロジック側では不正常な応答データの場合の処理を考慮する必要がなく、応答データとして共通のエラーメッセージやエラー画面を返すことができる。

そして、正常な応答データの場合（Ｓ３２：ＮＯ）、画面生成部２２は、あらかじめ定められた編集ルール（ポリシー）に基づいてコンテキスト（サブ）２３２に記憶されたコンテンツを編集する（Ｓ３４）。例えば、コンテンツ自身もＨＴＭＬファイルである。そのため、各コンテンツをマージして１つの画面情報（ＨＴＭＬファイル）を生成すると、＜ｂｏｄｙ＞タグまたは＜ｈｔｍｌ＞タグなどが重複する場合がある。そのため、画面生成部２２は、コンテンツの埋め込み先に応じて、コンテンツから＜ｂｏｄｙ＞タグ及び＜ｈｔｍｌ＞タグなどの不要なタグを削除する。また、あらかじめ定められた編集ルールの条件に合致する場合は、コンテンツに記述された所定の文字列から所定の文字列までの範囲のみを抽出し、他の部分については削除することが考えられる。

全てのコンテキスト（サブ）２３２の応答データについてＳ３１からＳ３４の処理を行った後、画面生成部２２は、情報生成ファイル２３に定義されたレイアウト情報を参照して、編集後の各コンテンツを情報生成ファイル２３の所定の箇所に埋め込み、各コンテンツを統合した画面情報（ＨＴＭＬファイル）２３９を生成する（Ｓ３５）。

以上、本発明の一実施形態を説明した。

本実施形態では、コンテキスト（メイン）に記憶されたインリクエストおよびメインリクエストの応答データに基づいてサブリクエストを生成し、サーブレット２８にサブリクエストを発行する。そして、サブリクエストは、コンテキスト（サブ）でそれぞれ実行される。これにより、情報生成ファイル２３が各サーブレット２８を呼び出す際に、メインリクエストの応答データ（ステータスを含む）の影響を受けることがない。したがって、メインリクエストの処理により、意図しないステータス（attribute）の変更を回避することができる。また、各サーブレット２８を呼び出す際に、メインリクエストとは異なるサブリクエストを発行することができる。

また、本実施形態では、画面生成部２２が行う画面情報の生成と、ビジネスロジックとを分離して作成することができる。これにより、ビジネスロジックの再利用を容易にし、システムの生産性および保守性をより向上させることができる。すなわち、ビジネスロジックは、画面情報を構成するコンテンツ単位（最小単位）に作成すればよく、ＭＶＣモデルのように各ビジネスロジックを統合したビジネスロジックを作成する必要がない。

また、本実施形態では、コンテンツのユーザ固有情報を所定の置換文字列に置換してキャッシュメモリ２４に記憶し、キャッシュメモリ２４に記憶されたコンテンツの置換文字列をユーザ固有情報に復元してコンテンツを再利用する。これにより、ビジネスロジックが同じコンテンツをその都度新たに生成する場合に比べて、処理負荷を低減させ、クライアント１への応答時間を短縮することができる。

また、本実施形態では、不正常な応答データを別のコンテンツに差し替えることにより、不正常な応答データをそのまま埋め込むことにより発生する表示画面のデザイン上の問題（違和感、画面の破壊など）を回避することができる。また、画面生成部２２がこのようなコンテンツの差し替えを行うため、ビジネスロジック側では不正常な応答データの場合の処理を考慮する必要がなく、応答データとして共通のエラーメッセージやエラー画面を返すことができる。また、本実施形態では、正常な応答データであっても、あらかじめ定められた編集ルールに従ってコンテンツの編集を行う。これにより、サブリクエストに対するコンテンツの再利用を促進し、より汎用的なビジネスロジックを作成することができる。

また、本実施形態では、フレーム機能を用いることなく、１つの画面（Ｗｅｂページ）で複数のコンテンツを表示する。これにより、フレームを用いた場合に、クライアント１側でフレーム数分のコンテンツ（ＨＴＭＬファイル）を要求し、ネットワーク上の負荷が増大することを回避することができる。また、クライアント１がフレーム数分のコンテンツをＷｅｂサーバ２に要求するたびに発生するユーザ認証処理の回数を低減することができる。また、フレームやスクロールバーが画面上に表示されないため、デザイン的に見栄えの良い（より統一感のある）画面を生成することができる。

なお、本発明は上記の実施形態に限定されるものではなく、その要旨の範囲内で数々の変形が可能である。例えば、上記実施形態では、Ｗｅｂサーバ２の画面生成部２２は、コンテキスト（メイン）２３１に記憶されたメインリクエストおよび応答データに基づいてサブリクエストを生成することとした。しかしながら、本発明はこれに限定されず、画面生成部２２は、コンテキスト（メイン）２３１に記憶された情報だけでなく、コンテキスト（サブ）２３２に記憶されたサブリクエストおよび応答データに基づいて、サブリクエストを生成することとしてもよい。図４に示す場合、画面生成部２２は、サブリクエスト＃２を、コンテキスト（メイン）２３１の情報およびコンテキスト（サブ＃１）の情報に基づいて生成することが考えられる。また、画面生成部２２は、サブリクエスト＃２を、コンテキスト（サブ＃１）の情報にのみ基づいて生成することとしてもよい。

本発明の一実施形態が適用されたＷｅｂシステムの全体構成を示す図である。 各装置のハードウェア構成例を示す図である。 表示画面の一例を示す図である。 Ｗｅｂシステムの処理を模式的に示す図である。 コンテンツ取得処理のフローチャートである。 コンテンツ編集処理のフローチャートである。 コンテンツの差し替え処理を模式的に示す図である。

符号の説明

１：クライアント、１１：Ｗｅｂブラウザ、２：Ｗｅｂサーバ、２１：要求受付部、２２：画面生成部、２３：情報生成ファイル、２４：キャッシュメモリ、３：アプリケーションサーバ、３１：ビジネスロジック

Claims (3)

1. 情報処理装置が行う画面情報生成方法であって、
   前記情報処理装置は、
   端末から送信されたメインリクエストを受け付ける受け付けステップと、
   前記メインリクエストに含まれる第１の情報を用いて、第２の情報を含む当該メインリクエストの応答データを取得する応答データ取得ステップと、
   前記第２の情報に基づいて、複数のサブリクエストを生成するサブリクエスト生成ステップと、
   前記各サブリクエストを発行し、各サブリクエストで要求するコンテンツをそれぞれ取得する取得ステップと、
   前記取得した各コンテンツを統合し、１つの画面情報を生成する画面情報生成ステップと、を行い、
   前記サブリクエスト生成ステップは、前記メインリクエスト、当該メインリクエストに対する応答データ、生成済みのサブリクエスト、および、当該生成済みのサブリクエストに対する応答データの少なくとも１つに基づいて、サブリクエストを生成し、
   前記取得ステップで前記コンテンツの取得に失敗した場合、前記画面情報生成ステップは、取得に失敗したコンテンツを所定のコンテンツに差し替えて画面情報を生成し、
   前記情報処理装置は、前記取得したコンテンツを記憶する記憶部を有し、
   前記取得ステップは、
   前記サブリクエストを発行する際に、当該サブリクエストで要求するコンテンツが前記記憶部に記憶されているか否かを判別し、
   前記コンテンツが前記記憶部に記憶されていない場合は、前記サブリクエストを発行して前記コンテンツを取得し、当該コンテンツからユーザ固有情報を削除して前記記憶部に記憶し、
   前記コンテンツが前記記憶部に記憶されている場合は、前記記憶部からコンテンツを取得し、当該コンテンツにユーザ固有情報を付加すること
   を特徴とする画面情報生成方法。
2. 画面情報生成システムであって、
   端末から送信されたメインリクエストを受け付ける要求受付手段と、
   前記メインリクエストに含まれる第１の情報を用いて、第２の情報を含む当該メインリクエストの応答データを取得し、前記第２の情報に基づいて、複数のサブリクエストを生成するサブリクエスト生成手段と、
   前記各サブリクエストを発行し、各サブリクエストで要求するコンテンツをそれぞれ取得する取得手段と、
   前記取得した各コンテンツを統合し、１つの画面情報を生成する画面情報生成手段と、
   前記取得したコンテンツを記憶する記憶手段とを有し、
   前記サブリクエスト生成手段は、前記メインリクエスト、当該メインリクエストに対する応答データ、生成済みのサブリクエスト、および、当該生成済みのサブリクエストに対する応答データの少なくとも１つに基づいて、サブリクエストを生成し、
   前記取得手段が前記コンテンツの取得に失敗した場合、前記画面情報生成手段は、取得に失敗したコンテンツを所定のコンテンツに差し替えて画面情報を生成し、
   前記取得手段は、
   前記サブリクエストを発行する際に、当該サブリクエストで要求するコンテンツが前記記憶手段に記憶されているか否かを判別し、
   前記コンテンツが前記記憶手段に記憶されていない場合は、前記サブリクエストを発行して前記コンテンツを取得し、当該コンテンツからユーザ固有情報を削除して前記記憶手段に記憶し、
   前記コンテンツが前記記憶手段に記憶されている場合は、前記記憶手段からコンテンツを取得し、当該コンテンツにユーザ固有情報を付加すること
   を特徴とする画面情報生成システム。
3. 情報処理装置が実行する画面情報生成プログラムであって、
   前記情報処理装置に、
   端末から送信されたメインリクエストを受け付ける受け付けステップと、
   前記メインリクエストに含まれる第１の情報を用いて、第２の情報を含む当該メインリクエストの応答データを取得する応答データ取得ステップと、
   前記第２の情報に基づいて、複数のサブリクエストを生成するサブリクエスト生成ステップと、
   前記各サブリクエストを発行し、各サブリクエストで要求するコンテンツをそれぞれ取得する取得ステップと、
   前記取得した各コンテンツを統合し、１つの画面情報を生成する画面情報生成ステップと、を実行させ、
   前記サブリクエスト生成ステップは、前記メインリクエスト、当該メインリクエストに対する応答データ、生成済みのサブリクエスト、および、当該生成済みのサブリクエストに対する応答データの少なくとも１つに基づいて、サブリクエストを生成し、
   前記取得ステップで前記コンテンツの取得に失敗した場合、前記画面情報生成ステップは、取得に失敗したコンテンツを所定のコンテンツに差し替えて画面情報を生成し、
   前記情報処理装置は、前記取得したコンテンツを記憶する記憶部を有し、
   前記取得ステップは、
   前記サブリクエストを発行する際に、当該サブリクエストで要求するコンテンツが前記記憶部に記憶されているか否かを判別し、
   前記コンテンツが前記記憶部に記憶されていない場合は、前記サブリクエストを発行して前記コンテンツを取得し、当該コンテンツからユーザ固有情報を削除して前記記憶部に記憶し、
   前記コンテンツが前記記憶部に記憶されている場合は、前記記憶部からコンテンツを取得し、当該コンテンツにユーザ固有情報を付加すること
   を特徴とする画面情報生成プログラム。

Images