(57)【要約】【課題】表示する画面の内容に相関関係がある複数の画面を有するＨＴＴＰサーバに対するプロキシ処理において、一方の表示内容の修正が他方の画面の表示内容に影響を与えるページが存在する場合であってもキャッシュを利用して高速化を図る。【解決手段】Ｗｅｂ−ＧＵＩバンドル２２が提供する画面間の依存関係を記載した依存関係テーブル１３と、Ｗｅｂ−ＧＵＩバンドル２２に対して設定変更する場合に指定するＵＲＬを記載した設定変更ＵＲＬテーブル１５を保持し、リクエストによって要求されたＵＲＬが設定変更ＵＲＬテーブル１５に記載されているときは、要求されたＵＲＬと依存関係のあるキャッシュ情報を無効にする。また、パラメータと画面とを関連付けた変更パラメータ関連画面テーブル１７を備え、パラメータ変更通知部１６から変更されたパラメータの情報を受け取り、変更されたパラメータに関連する画面を特定してキャッシュ情報を無効にする。【選択図】図１
2014182553.tif 000002
【特許請求の範囲】
【請求項１】
パラメータの設定値の変更により表示する内容が変更される画面データを有するサーバとクライアント端末との間の通信を中継するプロキシ装置であって、
前記サーバから取得した画面データを保持するキャッシュ記憶手段と、
前記クライアント端末から要求を受信し、当該要求の対象である画面データが前記キャッシュ記憶手段で保持されている場合は前記キャッシュ記憶手段から前記画面データを読み出して前記クライアント端末へ返却し、前記画面データが前記キャッシュ記憶手段に保持されていない場合は前記サーバに前記画面データの取得を要求し、前記要求がパラメータの設定値を変更する要求である場合は当該要求を前記サーバへ送信するとともに、前記キャッシュ記憶手段が保持する画面データのうち前記パラメータに関連する画面データを無効とするプロキシ手段と、
を有することを特徴とするプロキシ装置。
【請求項２】
前記サーバが有する画面データ間の依存関係を記載した依存関係テーブルと、
前記パラメータの設定値を変更する要求の一覧を記載した設定変更要求テーブルと、を有し、
前記プロキシ手段は、前記クライアント端末から受信した要求が前記設定変更要求テーブルに記載されている要求に該当する場合は、前記依存関係テーブルを参照して前記要求と依存関係のある画面データを特定し、前記キャッシュ記憶手段が保持する画面データのうち前記要求と依存関係のある画面データを無効とすることを特徴とする請求項１記載のプロキシ装置。
【請求項３】
パラメータと当該パラメータに関連のある画面データを記載したパラメータ関連画面テーブルを有し、
前記プロキシ装置は、前記サーバにおいてパラメータが変更されたときに、前記サーバから変更されたパラメータの情報を受信し、前記パラメータ関連画面テーブルを参照して前記パラメータと関連のある画面データを特定し、前記キャッシュ記憶手段が保持する画面データのうち前記パラメータと関連のある画面データを無効とすることを特徴とする請求項１記載のプロキシ装置。
【請求項４】
前記プロキシ手段は、前記キャッシュ記憶手段が保持する画面データを無効とした後、対応する画面データを前記サーバから取得して前記キャッシュ記憶手段に保持させることを特徴とする請求項１ないし３のいずれかに記載のプロキシ装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サーバとクライアント間で通信を中継して高速化を図る技術に関する。
【背景技術】
【０００２】
これまで、ＨＧＷ（ホームゲートウェイ）のＷｅｂ−ＧＵＩ（設定画面）は、ＨＧＷベンダ各社がそれぞれの実装に応じて作成していた。この画面を表示するために用意されたサーバをＨＴＴＰサーバ（Ｎａｔｉｖｅ）とする。共通のＷｅｂ−ＧＵＩをＪａｖａアプリケーション（バンドル）として作成し、各社のＨＧＷに搭載することで機能の統一とコストダウンを図ることができる。この際にＪａｖａが画面表示の際に利用するＨＴＴＰサーバをＨＴＴＰサーバ（Ｊａｖａ）とする。
【０００３】
通常ＨＴＴＰサーバ側で待ち受けを行う場合には８０番ポートを利用することが一般的である。ＨＴＴＰサーバ（Ｊａｖａ）機能で待ち受けする場合にも８０番ポートを利用することが望まれるが、従来から利用しているＨＧＷベンダ各社が実装していたＨＴＴＰサーバ（Ｎａｔｉｖｅ）は画面表示のみならず内線番号簡易払い出し機能等のからも利用されており、８０番ポートはＨＴＴＰサーバ（Ｎａｔｉｖｅ）側で待ち受けをすることが必須である。ゆえにＪａｖａ側は別のポート、例えば８８８８番ポート等で待ち受けをすることとなる。上記に加え、Ｊａｖａが表示するＧＵＩ画面はお客様の保守・設定サポートサービスのために準備された遠隔保守システムからの接続性を担保する必要があるが、既存の遠隔保守システムはセキュリティの観点より８０番で待ち受けしているポート以外の通信を遮断しているため、Ｊａｖａ側に８８８８番ポートを割り当てた場合には遠隔保守システムからの接続性を担保することができない。
【０００４】
そこで、ＨＧＷにリバースプロキシ機能を搭載し、ＨＴＴＰサーバ（Ｊａｖａ）向けの通信を全て一度８０番ポートでの待ち受けとし、ＨＧＷ内部機能が改めて別のポートで待ち受けているＨＴＴＰサーバ（Ｊａｖａ）に処理をプロキシすることで、上記２つの問題を解決している。
【０００５】
リバースプロキシは、クライアントからのリクエストを終端した後に、リバースプロキシ自体をクライアントとして新たなリクエストを再生成する。リクエストの度に上記の処理をすると時間がかかるので、キャッシュを用いてリクエストに対して返答する手法が取られる。例えば、特許文献１では、クライアントとサーバの間にプロキシシステムを配置し、プロキシシステムがサーバのデータを事前にキャッシュしておくことで高速化を図っている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００９−１８７４６６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかしながら、設定情報を変更するページを多く持ち、かつあるページの設定内容が別のページの表示に影響を与える場合は、キャッシュされたページと実際の設定情報とが一致しない可能性がある。図９に、ＨＧＷが有する設定画面の構成の例を示す。同図に示す例では、ＴＯＰ画面以下に基本設定、電話設定、詳細設定を行うページがあり、詳細設定の下に、ＤＮＳ設定、静的ＮＡＴ設定を行うページがある。静的ＮＡＴ設定ページでは、設定された静的ＮＡＴのエントリの一覧が表示されており、各エントリの横に編集ボタンが配置され、編集ボタンを押下することで、エントリ編集ページに遷移し、静的ＮＡＴの設定を編集することができる。エントリ編集ページでエントリの設定を変更した場合には、静的ＮＡＴ設定ページのエントリの情報も変更される。そのため、エントリ編集ページでエントリの編集後に静的ＮＡＴ設定ページに戻ると静的ＮＡＴ設定ページにも反映されるべきであるが、静的ＮＡＴ設定ページのキャッシュは反映されずに古い情報のままとなってしまう。
【０００８】
上記の問題に対応するため、リバースプロキシでキャッシュを利用しない方法も考えられるが、ＨＧＷにとってリバースプロキシの処理は重く、クライアントに対する返答が遅くなってしまう。
【０００９】
本発明は、上記に鑑みてなされたものであり、表示する画面の内容に相関関係がある複数の画面を有するＨＴＴＰサーバに対するプロキシ処理において、一方の表示内容の修正が他方の画面の表示内容に影響を与えるページが存在する場合であってもキャッシュを利用して高速化を図ることを目的とする。
【課題を解決するための手段】
【００１０】
第１の本発明に係るプロキシ装置は、パラメータの設定値の変更により表示する内容が変更される画面データを有するサーバとクライアント端末との間の通信を中継するプロキシ装置であって、前記サーバから取得した画面データを保持するキャッシュ記憶手段と、前記クライアント端末から要求を受信し、当該要求の対象である画面データが前記キャッシュ記憶手段で保持されている場合は前記キャッシュ記憶手段から前記画面データを読み出して前記クライアント端末へ返却し、前記画面データが前記キャッシュ記憶手段に保持されていない場合は前記サーバに前記画面データの取得を要求し、前記要求がパラメータの設定値を変更する要求である場合は当該要求を前記サーバへ送信するとともに、前記キャッシュ記憶手段が保持する画面データのうち前記パラメータに関連する画面データを無効とするプロキシ手段と、を有することを特徴とする。
【００１１】
上記プロキシ装置において、前記サーバが有する画面データ間の依存関係を記載した依存関係テーブルと、前記パラメータの設定値を変更する要求の一覧を記載した設定変更要求テーブルと、を有し、前記プロキシ手段は、前記クライアント端末から受信した要求が前記設定変更要求テーブルに記載されている要求に該当する場合は、前記依存関係テーブルを参照して前記要求と依存関係のある画面データを特定し、前記キャッシュ記憶手段が保持する画面データのうち前記要求と依存関係のある画面データを無効とすることを特徴とする。
【００１２】
上記プロキシ装置において、パラメータと当該パラメータに関連のある画面データを記載したパラメータ関連画面テーブルを有し、前記プロキシ装置は、前記サーバにおいてパラメータが変更されたときに、前記サーバから変更されたパラメータの情報を受信し、前記パラメータ関連画面テーブルを参照して前記パラメータと関連のある画面データを特定し、前記キャッシュ記憶手段が保持する画面データのうち前記パラメータと関連のある画面データを無効とすることを特徴とする。
【００１３】
上記プロキシ装置において、前記プロキシ手段は、前記キャッシュ記憶手段が保持する画面データを無効とした後、対応する画面データを前記サーバから取得して前記キャッシュ記憶手段に保持させることを特徴とする。
【発明の効果】
【００１４】
本発明によれば、表示する画面の内容に相関関係がある複数の画面を有するＨＴＴＰサーバに対するプロキシ処理において、一方の表示内容の修正が他方の画面の表示内容に影響を与えるページが存在する場合であってもキャッシュを利用して高速化を図ることができる。
【図面の簡単な説明】
【００１５】
【図１】第１の実施の形態におけるＨＧＷの構成を示す機能ブロック図である。
【図２】依存関係テーブルの例を示す図である。
【図３】キャッシュテーブルの例を示す図である。
【図４】設定変更ＵＲＬテーブルの例を示す図である。
【図５】クライアントからリクエストを受信したときのリバースプロキシの処理の流れを示す図である。
【図６】第２の実施の形態におけるＨＧＷの構成を示す機能ブロック図である。
【図７】変更パラメータ関連画面テーブルの例を示す図である。
【図８】ＨＧＷが有する設定画面の構成の例を示す。
【発明を実施するための形態】
【００１６】
以下、本発明の実施の形態について図面を用いて説明する。
【００１７】
［第１の実施の形態］
図１は、第１の実施の形態におけるＨＧＷの構成を示す機能ブロック図である。
【００１８】
図１に示すＨＧＷ１は、ＨＧＷ１のＯＳ上のネイティブ環境１０で動作する、ＨＴＴＰサーバ１１、リバースプロキシ１２、依存関係テーブル１３、キャッシュテーブル１４、および設定変更ＵＲＬテーブル１５と、ＨＧＷ１の仮想実行環境２０で動作するＨＴＴＰサーバ２１、Ｗｅｂ−ＧＵＩバンドル２２を備える。ＨＧＷ１が備える各部は、演算処理装置、記憶装置等を備えたコンピュータにより構成して、各部の処理がプログラムによって実行されるものとしてもよい。このプログラムはＨＧＷ１が備える記憶装置に記憶されており、磁気ディスク、光ディスク、半導体メモリ等の記録媒体に記録することも、ネットワークを通して提供することも可能である。
【００１９】
リバースプロキシ１２は、ＬＡＮ側インタフェースからユーザによる設定画面のリクエストの要求を受け付け、ＷＡＮ側インタフェースから遠隔保守者による遠隔保守機能の利用画面のリクエストなどを受け付ける。受信したリクエストが仮想実行環境２０上のＨＴＴＰサーバ２１に対するものである場合は、下記のような処理を行い受信したリクエストをＨＴＴＰサーバ２１へ転送する。
【００２０】
上記リバースプロキシ１２は、受信したリクエストで要求されたデータがキャッシュテーブル１４に存在し、かつ、そのデータの有効期限が切れていなければ、キャッシュテーブル１４から対応するデータを取得してリクエストの要求元であるクライアントへ送信する。要求されたデータがキャッシュテーブル１４に存在しないか、そのデータの有効期限が切れていれば、リバースプロキシ１２は、ＨＴＴＰサーバ２１に対してリクエストを送信する。
【００２１】
また、リバースプロキシ１２は、ＨＴＴＰサーバ２１に対して送信するリクエストがパラメータの設定値を変更するものである場合、そのリクエストをＨＴＴＰサーバ２１へ送信するとともに、キャッシュテーブル１４から関連するキャッシュ情報を削除あるいは有効期限切れとして無効にする。このキャッシュ情報を無効にする処理を含むリバースプロキシの処理の詳細については後述する。
【００２２】
依存関係テーブル１３は、Ｗｅｂ−ＧＵＩバンドル２２が提供する画面間の依存関係を記載したテーブルである。例えば、画面Ｂにおいて設定される値が画面Ａに表示されている場合、画面Ａは画面Ｂとの間で依存関係がある。図９に示した構成では、静的ＮＡＴ設定ページにはエントリ編集ページで更新されるパラメータの設定値を表示しているので、静的ＮＡＴ設定ページはエントリ編集ページとの間で依存関係がある。図２に、依存関係テーブル１３の例を示す。図２の例では、index2.html で表示される画面は、index1.html, index4.html との間で依存関係がある。
【００２３】
キャッシュテーブル１４は、ＨＴＴＰサーバ２１から取得したデータに有効期限を設定してキャッシュ情報として保持する。図３に、キャッシュテーブル１４の例を示す。
【００２４】
設定変更ＵＲＬテーブル１５は、Ｗｅｂ−ＧＵＩバンドル２２に対して設定変更する場合に指定するＵＲＬの一覧を記載する。図４に、設定変更ＵＲＬテーブル１５の例を示す。設定変更ＵＲＬテーブル１５には設定変更ＵＲＬを正規表現で記載しておき、その正規表現にマッチするリクエストを受信した場合に、設定変更されると判定する。リバースプロキシ１２は、受信したリクエストで要求されるＵＲＬが設定変更ＵＲＬテーブル１５に記載されているＵＲＬに該当する場合は、依存関係テーブル１３を参照し、設定変更のリクエストが発生した画面とその画面と依存関係のある画面のキャッシュ情報を無効にする。
【００２５】
ＨＴＴＰサーバ２１は、仮想実行環境２０上で動作し、ネイティブ環境１０上で動作するＨＴＴＰサーバ１１とは異なるポート（図１では８８８８番）でリクエストを待ち受ける。
【００２６】
Ｗｅｂ−ＧＵＩバンドル２２は、ＨＧＷ１のパラメータの設定値を変更する設定画面を提供する仮想実行環境２０上で動作するソフトウェアモジュールである。Ｗｅｂ−ＧＵＩを仮想実行環境２０上で動作するソフトウェアモジュールとして作成することで、ハードウェアの異なる各社のＨＧＷでも動作させることができる。なお、設定画面は、複数の階層で構成されており、下の階層で変更されるパラメータの設定値が上の階層でパラメータの一覧などとして表示される。
【００２７】
次に、本実施の形態におけるリバースプロキシの動作について説明する。
【００２８】
図５は、クライアントからリクエストを受信したときのリバースプロキシ１２の処理の流れを示すフローチャートである。
【００２９】
リバースプロキシ１２がリクエストを受信すると、設定変更ＵＲＬテーブル１５を確認し（ステップＳ１１）、リクエストによって要求されたＵＲＬが設定変更のためのリクエストであるか否かを判定する（ステップＳ１２）。
【００３０】
設定変更のためのリクエストである場合（ステップＳ１２のＹＥＳ）、依存関係テーブル１３を確認して、リクエストされたＵＲＬと依存関係のあるキャッシュ情報を有効期限切れとする（ステップＳ１３）。
【００３１】
そして、ＨＴＴＰサーバ２１にリクエストを送信して、ＨＴＴＰサーバ２１からの応答結果をクライアントに送信する（ステップＳ１４）。
【００３２】
さらに、ステップＳ１３で有効期限切れとしたキュッシュ情報について、ＨＴＴＰサーバ２１にアクセスしてデータを取得し、有効期限を含むキャッシュ情報を更新する（ステップＳ１５）。このとき、有効期限切れの他のキャッシュ情報が存在する場合は、そのキャッシュ情報についてもＨＴＴＰサーバ２１からデータを取得してキャッシュ情報を更新してもよい。
【００３３】
一方、設定変更のためのリクエストではない場合（ステップＳ１２のＮＯ）、キャッシュテーブル１４を確認し（ステップＳ１６）、リクエストされたＵＲＬに対応するキャッシュ情報が存在し、かつ、有効期限内であるか否か判定する（ステップＳ１７）。
【００３４】
キャッシュ情報が存在する場合（ステップＳ１７のＹＥＳ）、キャッシュ情報をキャッシュテーブル１４から取得してクライアントに応答する（ステップＳ１８）。
【００３５】
キャッシュ情報が存在しない場合（ステップＳ１７のＹＥＳ）、ＨＴＴＰサーバ２１にリクエストを送信して、ＨＴＴＰサーバ２１からの応答結果をクライアントに送信する（ステップＳ１９）。
【００３６】
以上説明したように、本実施の形態によれば、Ｗｅｂ−ＧＵＩバンドル２２が提供する画面間の依存関係を記載した依存関係テーブル１３と、Ｗｅｂ−ＧＵＩバンドル２２に対して設定変更する場合に指定するＵＲＬを記載した設定変更ＵＲＬテーブル１５を保持し、リバースプロキシ１２がリクエストを受信したときに、リクエストによって要求されたＵＲＬが設定変更ＵＲＬテーブル１５に記載されているときは、要求されたＵＲＬと依存関係のあるキャッシュ情報を無効にすることにより、依存関係のない画面については引き続きキャッシュによる高速化を適用しつつ、依存関係のある画面についてはリバースプロキシの動作を行い設定変更が反映された画面を表示することができる。
【００３７】
設定変更された画面と依存関係のある画面のキャッシュ情報を無効にした後、キャッシュ情報を無効にした画面のデータをＨＴＴＰサーバ２１から取得し、改めてキャッシュしておくことにより、依存関係のある画面へのアクセスにおいてもキャッシュによる高速化を適用できる。
【００３８】
なお、高速化を進める観点から、リバースプロキシ１２は、起動時にＷｅｂ−ＧＵＩバンドル２２が提供する全ての画面を取得し、キャッシュ情報として保持するとよい。ただし、この場合に、外部要因（対向サーバ等）によりＨＧＷ１の内部の設定が動的に変化するような場合には一定時間を経過した後に設定が確定してからキャッシュ情報を取得する等の留意が必要である。
【００３９】
［第２の実施の形態］
図６は、第２の実施の形態におけるＨＧＷの構成を示す機能ブロック図である。同図に示すＨＧＷ１は、第１の実施の形態のＨＧＷとは、依存関係テーブル１３及び設定変更ＵＲＬテーブル１５を備えずに、パラメータ変更通知部１６、変更パラメータ関連画面テーブル１７を備える点で異なる。
【００４０】
パラメータ変更通知部１６は、Ｗｅｂ−ＧＵＩバンドル２２を介してパラメータの設定値が変更された場合に、変更されたパラメータの情報をリバースプロキシ１２へ通知する。
【００４１】
変更パラメータ関連画面テーブル１７は、上記設定変更されたパラメータとそのパラメータに関連する画面の関連情報を保持する。パラメータに関連する画面とは、そのパラメータの設定値を表示する画面である。図７に、変更パラメータ関連画面テーブル１７の例を示す。
【００４２】
第２の実施の形態におけるリバースプロキシ１２は、パラメータ変更通知部１６から変更されたパラメータの情報を受け取り、変更パラメータ関連画面テーブル１７を参照して、変更されたパラメータに関連する画面を特定し、関連する画面のキャッシュ情報を消去あるいは有効期限切れとする。
【００４３】
次に、本実施の形態におけるリバースプロキシの動作について図６を用いて説明する。
【００４４】
クライアントから仮想実行環境２０上のＨＴＴＰサーバ２１に対するリクエストを受信すると（ステップＳ２１）、リバースプロキシは下記のような処理を行い、ＨＴＴＰサーバ（Ｊａｖａ）２１に転送する。
【００４５】
その際にリバースプロキシ１２は、リクエストされたＵＲＬに対応するキャッシュ情報がキャッシュテーブル１４に存在するか否か確認する（ステップＳ２２）。
【００４６】
リクエストされたＵＲＬに対応するキャッシュ情報がキャッシュテーブル１４に存在し、有効期限内の場合は、リバースプロキシ２１は、キャッシュテーブル１４から対応するキャッシュ情報を取得してクライアントに応答する（ステップＳ２３−１）。
【００４７】
一方、リクエストされたＵＲＬに対応するキャッシュ情報がキャッシュテーブル１４に存在しないか、有効期限切れの場合は、リバースプロキシ２１は、リクエストをＨＴＴＰサーバ２１へ送信し（ステップＳ２３−２）、ＨＴＴＰサーバ２１から返却されたデータをクライアントへ送信する。
【００４８】
このとき、Ｗｅｂ−ＧＵＩバンドル２２でパラメータの設定値が変更された場合、リバースプロシキ１２は、パラメータ変更通知部１６から変更があったパラメータの情報を受信する（ステップＳ２４）。
【００４９】
そして、リバースプロキシ１２は、変更パラメータ関連画面テーブル１７を参照し（ステップＳ２５）、変更されたパラメータと依存関係のある画面のキャッシュ情報について有効期限切れとする（ステップＳ２６）。
【００５０】
また、第１の実施の形態と同様に、有効期限切れとしたキュッシュ情報について、ＨＴＴＰサーバ２１にアクセスしてデータを取得し、有効期限を含むキャッシュ情報を更新する。
【００５１】
以上説明したように、本実施の形態によれば、パラメータの設定値が変更された場合にリバースプロキシ１２へ通知するパラメータ変更通知部１６と、パラメータとそのパラメータに関連する画面を保持する変更パラメータ関連画面テーブル１７を備え、リバースプロキシ１２が、パラメータ変更通知部１６から変更されたパラメータの情報を受け取ったときに、変更パラメータ関連画面テーブル１７を参照し、変更されたパラメータに関連する画面を特定し、関連する画面のキャッシュ情報を無効にすることにより、変更されたパラメータに関連しない画面については引き続きキャッシュによる高速化を適用しつつ、変更されたパラメータに関連する画面についてはリバースプロキシの動作を行い設定変更が反映された画面を表示することができる。
【００５２】
ここではＨＧＷ１上で動作するＨＴＴＰサーバ２１に対するプロキシ処理について説明したが、本発明は一般的なＨＴＴＰサーバに対するプロキシ処理についても適用できる。
【符号の説明】
【００５３】
１…ＨＧＷ
１０…ネイティブ環境
１１…ＨＴＴＰサーバ
１２…リバースプロキシ
１３…依存関係テーブル
１４…キャッシュテーブル
１５…設定変更ＵＲＬテーブル
１６…パラメータ変更通知部
１７…変更パラメータ関連画面テーブル
２０…仮想実行環境
２１…ＨＴＴＰサーバ
２２…ＧＵＩバンドル
【図１】
2014182553.tif 000003
【図２】
2014182553.tif 000004
【図３】
2014182553.tif 000005
【図４】
2014182553.tif 000006
【図５】
2014182553.tif 000007
【図６】
2014182553.tif 000008
【図７】
2014182553.tif 000009
【図８】
2014182553.tif 000010