JP5941873B2 - Ｗｅｂサーバシステム、Ｗｅｂサーバ連携方法、及びプログラム - Google Patents

Description

本発明は、Ｗｅｂ−ＧＵＩの閲覧リクエストに応答する第１のＷｅｂサーバと、前記閲覧リクエストを前記第１のＷｅｂサーバに転送する第２のＷｅｂサーバとを連携させるＷｅｂサーバシステム、Ｗｅｂサーバ連携方法、及びプログラムに関する。

近時、ゲートウェイ装置におけるＨＴＴＰ(Hypertext Transfer Protocol)サーバの実装形態として、ネイティブ部分とＪａｖａ（登録商標）部分とに各々ＨＴＴＰサーバを持たせる構成が採用されている。その理由は、ベンダ毎に設計の異なるネイティブ部分と切り離してＪａｖａ部分からなる共通モジュールを設けるためである。この共通モジュールを用いてＷｅｂ−ＧＵＩ(Web Graphical User Interface)を表示させることにより、ゲートウェイ装置の機能を統一し、機能の共通化を目的とする追加開発を抑制してコストダウンを図ることができる（非特許文献１参照）。ある開発例では、既存のゲートウェイ装置の設計変更を最小限とするために、開発者は、ネイティブ部分のＨＴＴＰサーバが待ち受ける８０番ポートは変えず、８０番ポートで受信したＷｅｂ−ＧＵＩの閲覧リクエストをＪａｖａ部分のＨＴＴＰサーバにも受け渡すプロキシ動作を利用する。
なお、ネイティブ部分とは、装置のＯＳ(Operating System)に依存したコード（言語）で実装された機能を動作させる部分である。ＪａｖａはＯＳに依存しないコードの一例である。

"ホームゲートウェイなどへソフトウェア配信を行うホームICTプラットフォーム"、［online］、［平成25年4月18日検索］、インターネット〈URL：http://www.ntt.co.jp/RD/OFIS/active/2012pdf/hot/sw/01.html〉

しかしながら、上記従来技術において、Ｊａｖａ部分はネイティブ部分に比較して起動処理に時間を要する。プロキシ動作を利用する場合には通常、個々のサーバは独立して動作するが、上記のゲートウェイ装置では、ネイティブ部分が動作してその上でＪａｖａ部分が動作するので起動処理が遅くなる。そのため、起動処理時において、上記従来技術は、Ｊａｖａを用いない場合と比較して、Ｗｅｂ−ＧＵＩが表示されるまでの時間が長くなる。このようなＷｅｂ−ＧＵＩ表示の遅さは、ユーザビリティの低下や装置設置時における保守者作業の長時間化を招く。

また、上記従来技術において、Ｊａｖａ部分は、商用運用中にガベージコレクションの頻繁な発生やメモリ不足により動作停止などの不具合を起こす可能性が比較的高い。特に、個別バンドルにメモリ制限を課す場合には、各バンドルにおいてメモリリークにより動作停止を起こす可能性が高まる。

動作停止等の障害がＪａｖａ仮想マシン全体やＷｅｂ−ＧＵＩに起きてしまうと、Ｗｅｂ−ＧＵＩの画面で実現するサービスが停止するために深刻な影響が生じる。特に、Ｗｅｂ−ＧＵＩの画面で提供すべき、システム再起動やファームウェア更新に関する復旧案内の提供が不可能となると、障害からの復旧手段が失われることになる。
最悪の場合、ユーザは、ゲートウェイ装置の物理的な再起動を試みるか、それでも復旧が難しい場合にはゲートウェイ装置を良品と取り換える必要が生じていた。この問題は、仮にＪａｖａ部分に冗長化したＷｅｂ−ＧＵＩバンドルを複数準備したとしても、Ｊａｖａ部分の全体に障害が生じた場合には解決することができない。

上記事情に鑑み、本発明は、起動処理時や動作停止時などネイティブコードに依存しないコード（Ｊａｖａを含む）で実装された部分の機能が利用できない状況下におけるユーザのより速い応答を可能とするＷｅｂサーバシステム、Ｗｅｂサーバ連携方法、及びプログラムを提供することを目的としている。

本発明の一態様は、Ｗｅｂサーバシステムにおいて、ネイティブコードに依存しないコードで実装されたアプリケーションの処理によって、Ｗｅｂ−ＧＵＩの閲覧リクエストに応答する第１のＷｅｂサーバと、ネイティブコードで実装され、前記閲覧リクエストを受信し、当該閲覧リクエストを前記第１のＷｅｂサーバに転送する第２のＷｅｂサーバと、を備えるＷｅｂサーバシステムであって、前記アプリケーションの動作状態を監視する動作状態監視部と、前記動作状態監視部によって監視された前記アプリケーションの動作状態を記録する監視テーブルと、前記第２のＷｅｂサーバが前記閲覧リクエストを受信した場合には、前記監視テーブルを参照し、当該閲覧リクエストを処理するアプリケーションが動作していなければ、予め定められている不動作時対応処理を実行する不動作時対応部とを備える。

また、本発明の一態様においては、前記アプリケーションのリソース使用状態を監視するリソース監視部を更に備え、前記リソース監視部は、特定アプリケーションの使用リソースの状態値が閾値を超えた場合には、当該特定アプリケーションを前記動作状態監視部の監視対象とする。

また、本発明の一態様は、Ｗｅｂサーバ連携方法において、ネイティブコードに依存しないコードで実装されたアプリケーションの処理によって、Ｗｅｂ−ＧＵＩの閲覧リクエストに応答する第１のＷｅｂサーバと、ネイティブコードで実装され、前記閲覧リクエストを受信し、当該閲覧リクエストを前記第１のＷｅｂサーバに転送する第２のＷｅｂサーバとを連携させるＷｅｂサーバ連携方法であって、前記アプリケーションの動作状態を監視する動作状態監視段階と、前記動作状態監視段階にて監視された前記アプリケーションの動作状態を記録する記録段階と、前記第２のＷｅｂサーバが前記閲覧リクエストを受信した場合には、前記記録段階における記録内容を参照し、当該閲覧リクエストを処理するアプリケーションが動作していなければ、予め定められている不動作時対応処理を実行する不動作時対応段階とを備える。

また、本発明の一態様は、ネイティブコードに依存しないコードで実装されたアプリケーションの処理によって、Ｗｅｂ−ＧＵＩの閲覧リクエストに応答する第１のＷｅｂサーバと、ネイティブコードで実装され、前記閲覧リクエストを受信し、当該閲覧リクエストを前記第１のＷｅｂサーバに転送する第２のＷｅｂサーバと、を備えるＷｅｂサーバシステムとしてのコンピュータを、前記アプリケーションの動作状態を監視する動作状態監視部と、前記動作状態監視部によって監視された前記アプリケーションの動作状態を記録する監視テーブルと、前記第２のＷｅｂサーバが前記閲覧リクエストを受信した場合には、前記監視テーブルを参照し、当該閲覧リクエストを処理するアプリケーションが動作していなければ、予め定められている不動作時対応処理を実行する不動作時対応部として機能させるためのプログラムである。

本発明により、起動処理時や動作停止時などネイティブコードに依存しないコード（Ｊａｖａを含む）で実装された部分の機能が利用できない状況下におけるユーザのより速い応答を可能とすることができる。例えば、ネイティブコードに依存しないコード（Ｊａｖａを含む）で実装された部分の機能が利用できない状況下において、最低限必要とされる情報を提示する画面をより速くユーザに提供することが可能になる。

本発明の一実施形態に係るゲートウェイ装置の構成を示すブロック図である。 動作状態監視テーブルの具体例を示す図である。 起動処理時にゲートウェイ装置が動作状態監視テーブルを更新する処理の流れを示すフローチャートである。 起動処理完了後にゲートウェイ装置が動作状態監視テーブルを更新する処理の流れを示すフローチャートである。 リソース監視部が特定バンドルを動作状態監視部による監視対象に加えるための閾値を示したテーブルである。 Ｗｅｂ−ＧＵＩの閲覧リクエスト受信時におけるゲートウェイ装置の処理の流れを示すフローチャートである。

（１．ゲートウェイ装置の構成）
図１は、本実施形態に係るゲートウェイ装置１００（Ｗｅｂサーバシステム）の構成を示すブロック図である。ゲートウェイ装置１００は、ネイティブによって機能を実現するネイティブ部１００ａとＪａｖａによって機能を実現するＪａｖａ部１００ｂとを含む。ネイティブ部１００ａは、例えばＣ言語により実装される。Ｊａｖａは、ネイティブコードに依存しないコードの一例である。 ネイティブ部１００ａは、通信部１１０と、ＨＴＴＰサーバ１２０（第２のＷｅｂサーバ）と、リバースプロキシ部１２０ａ（不動作時対応部）と、動作状態監視部１５０と、動作状態監視テーブル１６０（監視テーブル）と、リソース監視部１７０とを備える。Ｊａｖａ部１００ｂは、ＨＴＴＰサーバ１３０（第１のＷｅｂサーバ）と、Ｗｅｂ−ＧＵＩバンドル（Ａ）１４０ａ，Ｗｅｂ−ＧＵＩバンドル（Ｂ）１４０ｂ，Ｗｅｂ−ＧＵＩバンドル（Ｃ）１４０ｃとを備える。

通信部１１０は、ＷＡＮ側のネットワークおよびＬＡＮ側のネットワークと接続可能となっており、両ネットワークを相互に接続する。通信部１１０は、ＨＴＴＰクライアントと通信する。ＨＴＴＰサーバ１２０は、通信部１１０を介して、ＨＴＴＰクライアントからＷｅｂ−ＧＵＩの閲覧リクエスト（ＨＴＴＰリクエスト）を受信する。リバースプロキシ部１２０ａは、ＨＴＴＰサーバ１２０が受信した閲覧リクエストを適宜ＨＴＴＰサーバ１３０に転送する。ＨＴＴＰサーバ１２０は、例えば８０番ポートでＷｅｂ−ＧＵＩの閲覧リクエストを待ち受け、受信した閲覧リクエストをリバースプロキシ部１２０ａが例えば８０８０番ポートのＨＴＴＰサーバ１３０に転送する。ＨＴＴＰサーバ１２０は、８０番ポートを利用して、Ｗｅｂ−ＧＵＩの閲覧リクエストの待ち受け以外にも、例えばＷＡＮ側にある保守用のサーバからゲートウェイ装置１００のＧＵＩ等を遠隔にて確認する遠隔保守システム用にも利用されている。

リバースプロキシ部１２０ａ（不動作時対応部）は、ＨＴＴＰサーバ１２０がＷｅｂ−ＧＵＩの閲覧リクエストを受信した場合には、動作状態監視テーブル１６０を参照し、受信した閲覧リクエストを処理するＷｅｂ−ＧＵＩバンドルが動作していなければ、所定の不動作時対応処理を実行する。
なお、図１においては、リバースプロキシ部１２０ａは、ＨＴＴＰサーバ１２０に包含された構成としたが、リバースプロキシ部１２０ａは、ＨＴＴＰサーバ１２０に包含されず、ＨＴＴＰクライアントからのリクエストを一元的に受信し、ＨＴＴＰクライアント側のリクエストＵＲＬに応じて、該当するＨＴＴＰサーバに転送を振り分けるような構成としてもよい。
Ｗｅｂ−ＧＵＩバンドル（Ａ）１４０ａ，Ｗｅｂ−ＧＵＩバンドル（Ｂ）１４０ｂ，Ｗｅｂ−ＧＵＩバンドル（Ｃ）１４０ｃは、ネイティブコードに依存しないコードであるＪａｖａのアプリケーションである。各Ｗｅｂ−ＧＵＩバンドルは、Ｗｅｂ−ＧＵＩの閲覧リクエストを分担して処理する。具体的には、ＨＴＴＰサーバ１３０がＷｅｂ−ＧＵＩの閲覧リクエストを受信すると、閲覧リクエストに対応するＷｅｂ−ＧＵＩバンドルの処理により適切なＷｅｂ−ＧＵＩの画面データを送出する。閲覧リクエストの一例としては、ゲートウェイ装置１００の保守に関する内容のものがある。なお、Ｗｅｂ−ＧＵＩバンドルを設ける数は任意としてよい。

動作状態監視部１５０は、Ｗｅｂ−ＧＵＩバンドル（Ａ）１４０ａ，Ｗｅｂ−ＧＵＩバンドル（Ｂ）１４０ｂ，Ｗｅｂ−ＧＵＩバンドル（Ｃ）１４０ｃの各動作状態を監視する。動作状態監視テーブル１６０には、動作状態監視部１５０によって監視された各Ｗｅｂ−ＧＵＩバンドルの動作状態が記録される。各Ｗｅｂ−ＧＵＩバンドルの動作状態は、「休眠中」、「動作中」、「動作停止中」のいずれかである。リソース監視部１７０は、各Ｗｅｂ−ＧＵＩバンドルがＣＰＵやメモリ等のリソースを使用する、リソース使用状態を監視する。リソース監視部１７０は、各Ｗｅｂ−ＧＵＩバンドルの使用リソースの状態値が所定の閾値を超えた場合には、動作状態監視テーブル１６０を書き換えて、そのＷｅｂ−ＧＵＩバンドルを動作状態監視部１５０による監視対象とする。

（２．動作状態監視テーブルの更新）
図２は、動作状態監視テーブル１６０の具体例を示す図である。図２では、Ｗｅｂ−ＧＵＩバンドル（Ａ）１４０ａ，Ｗｅｂ−ＧＵＩバンドル（Ｂ）１４０ｂ，Ｗｅｂ−ＧＵＩバンドル（Ｃ）１４０ｃの各々に対して、対応するＷｅｂ−ＧＵＩの閲覧リクエスト、動作状態監視部１５０による動作状態監視の対象か否か、タイムアウト時間、動作状態の監視結果が示されている。

図２の例では、Ｗｅｂ−ＧＵＩバンドル（Ａ）１４０ａとＷｅｂ−ＧＵＩバンドル（Ｂ）１４０ｂとが動作状態監視部１５０による動作状態の監視対象となっている。図２の例では、Ｗｅｂ−ＧＵＩバンドル（Ｃ）１４０ｃは動作状態監視部１５０による動作状態の監視対象となっていない。図２の例では、動作状態監視部１５０が動作状態の監視を実行するときに各Ｗｅｂ−ＧＵＩバンドルからの回答を待ち受ける限界時間となるタイムアウト時間はいずれも５分である。図２の例では、動作状態監視部１５０によって動作状態の監視が実行された結果、Ｗｅｂ−ＧＵＩバンドル（Ａ）１４０ａは「休眠中」であり、Ｗｅｂ−ＧＵＩバンドル（Ｂ）１４０ｂは「動作停止中」である。

図３は、ゲートウェイ装置１００が起動処理時に動作状態監視テーブル１６０を更新する処理の流れを示すフローチャートである。図３を参照しながら、起動処理時にゲートウェイ装置１００が動作状態監視テーブル１６０を最新の状態に更新する処理の流れを説明する。
まず、ゲートウェイ装置１００が起動処理を開始する（ステップＳ３１）。ネイティブ部１００ａは、Ｊａｖａ部１００ｂより先に起動処理を完了する。ゲートウェイ装置１００は、ネイティブ部１００ａの起動処理が完了した時点において、以下の処理を実行する。この時点において、動作状態監視テーブル１６０に記録された動作状態は、デフォルト状態として、全てのＷｅｂ−ＧＵＩバンドルについて「休眠中」である。「休眠中」は、各Ｗｅｂ−ＧＵＩバンドルが起動処理を始めてから応答処理を始めるまでの初期状態を表している。

次に、動作状態監視部１５０は、動作状態監視テーブル１６０に記録された動作状態が「休眠中」のＷｅｂ−ＧＵＩバンドルに対してポーリング動作を実施する（ステップＳ３２）。
次に、動作状態監視部１５０は、Ｓ３２のポーリング動作に対して所定のタイムアウト時間内に応答したＷｅｂ−ＧＵＩバンドルの動作状態を「動作中」とするように、動作状態監視テーブル１６０を書き換える（ステップＳ３３）。

次に、動作状態監視部１５０は、動作状態監視テーブル１６０を参照して、全てのＷｅｂ−ＧＵＩバンドルの動作状態が「動作中」になっているか否かを判定する（ステップＳ３４）。ステップＳ３４における判定の結果、全てのＷｅｂ−ＧＵＩバンドルの動作状態が「動作中」になっていなければ、ゲートウェイ装置１００はステップＳ３２に戻って処理を繰り返す。ステップＳ３４における判定の結果、全てのＷｅｂ−ＧＵＩバンドルの動作状態が「動作中」になっていれば、ゲートウェイ装置１００は処理を終了する。

なお、上記の説明（ステップＳ３３）にて、動作状態監視部１５０は、ポーリング動作に対する各Ｗｅｂ−ＧＵＩバンドルの応答に基づいて、そのＷｅｂ−ＧＵＩバンドルの動作状態を「休眠中」から「動作中」に更新する。しかし、動作状態監視部１５０は、ポーリング動作に対する応答ではなく、各Ｗｅｂ−ＧＵＩバンドルが有するｗａｔｃｈ ｄｏｇ機能の通知に基づいて、そのＷｅｂ−ＧＵＩバンドルの動作状態を「休眠中」から「動作中」に更新してもよい。

図４は、ゲートウェイ装置１００が起動処理完了後に動作状態監視テーブル１６０を更新する処理の流れを示すフローチャートである。図４を参照しながら、ゲートウェイ装置１００が起動処理完了後に動作状態監視テーブル１６０を最新の状態に更新する処理の流れを説明する。

まず、リソース監視部１７０は、Ｗｅｂ−ＧＵＩバンドル（Ａ）１４０ａ，Ｗｅｂ−ＧＵＩバンドル（Ｂ）１４０ｂ，Ｗｅｂ−ＧＵＩバンドル（Ｃ）１４０ｃのリソース使用状態を監視する（ステップＳ４１）。監視対象となるリソースは、ＣＰＵの負荷とヒープメモリの使用量である。ＣＰＵの負荷については時間的な変動量が大きいので、複数回（例えば１０回）の測定を行ってその平均値を求める。

次に、リソース監視部１７０は、リソース使用状態の状態値が所定の閾値より悪化したＷｅｂ−ＧＵＩバンドルを動作状態監視部１５０による監視対象に加える（ステップＳ４２）。具体的には、リソース監視部１７０は、リソース使用状態の状態値が所定の閾値を超えたＷｅｂ−ＧＵＩバンドルを動作状態監視部１５０による監視対象とするように動作状態監視テーブル１６０を書き換える。

図５は、リソース監視部１７０が特定バンドルを動作状態監視部１５０による監視対象に加えるための閾値を示したテーブルである。図５に示されるように、リソース監視部１７０は、監視対象リソースのＣＰＵについては、負荷状態を示す状態値の測定を１０回実施する（ステップＳ４１参照）。リソース監視部１７０は、１０回測定の平均値において９５％以上の負荷がかかっていれば、そのＷｅｂ−ＧＵＩバンドルを動作状態監視部１５０による監視対象に加える。また、図５に示されるように、リソース監視部１７０は、監視対象リソースのヒープメモリについては、測定を１回実施する（ステップＳ４１参照）。測定の結果、リソース監視部１７０は、ヒープメモリの使用量（状態値）が４０ＭＢ以上であれば、そのＷｅｂ−ＧＵＩバンドルを動作状態監視部１５０による監視対象に加える。

図４に戻って、動作状態監視部１５０は、動作状態監視テーブル１６０を参照して、監視対象（図２参照）としているＷｅｂ−ＧＵＩバンドルの動作状態を確認する（ステップＳ４３）。例として、Ｗｅｂ−ＧＵＩバンドル（Ａ）１４０ａとＷｅｂ−ＧＵＩバンドル（Ｂ）１４０ｂとが動作状態監視部１５０による動作状態の監視対象となっていれば、動作状態監視部１５０は、各Ｗｅｂ−ＧＵＩバンドルに対応するＷｅｂ−ＧＵＩの閲覧リクエスト（例えば「http://xxx.setup/8080/aaa/*」）をＨＴＴＰサーバ１３０に送信する。動作状態監視部１５０は、Ｗｅｂ−ＧＵＩバンドル（Ａ）１４０ａやＷｅｂ−ＧＵＩバンドル（Ｂ）１４０ｂから所定のタイムアウト時間内にＷｅｂ−ＧＵＩの応答が返ってきたか否かを確認する。

Ｗｅｂ−ＧＵＩバンドルからの応答が所定のタイムアウト時間内に帰ってきたならば（ステップＳ４４においてＹｅｓ）、動作状態監視部１５０は、そのＷｅｂ−ＧＵＩバンドルの動作状態を「動作中」とするように動作状態監視テーブル１６０を更新する（Ｓ４５）。他方、Ｗｅｂ−ＧＵＩバンドルからの応答が所定のタイムアウト時間内に帰ってこなかったならば（ステップＳ４４においてＮｏ）、動作状態監視部１５０は、そのＷｅｂ−ＧＵＩバンドルの動作状態を「動作停止中」とするように動作状態監視テーブル１６０を更新する（ステップＳ４６）。なお、「動作停止中」とは、動作状態監視部１５０による動作状態の監視の結果、応答が得られなかった場合である。「動作停止中」とは、Ｗｅｂ−ＧＵＩバンドルが一時停止している場合の他、Ｗｅｂ−ＧＵＩバンドルが故障している場合を含む。

次に、動作状態監視部１５０は、全ての監視対象のＷｅｂ−ＧＵＩバンドルについて動作状態の確認を実行したかを判定する（ステップＳ４７）。ステップＳ４７における判定の結果、全ての監視対象のＷｅｂ−ＧＵＩバンドルについて動作状態の確認を実行していなければ、動作状態監視部１５０は、未確認の監視対象のＷｅｂ−ＧＵＩバンドルについて、ステップＳ４３以降の処理を繰り返す。他方、ステップＳ４７における判定の結果、全ての監視対象のＷｅｂ−ＧＵＩバンドルについて動作状態の確認を実行していれば、動作状態監視部１５０は処理を終了する。

ゲートウェイ装置１００は、ステップＳ４１〜Ｓ４７の各処理を一定時間ごとに繰り返す。ゲートウェイ装置１００は、ステップＳ４１〜Ｓ４７の各処理を、Ｗｅｂ−ＧＵＩの閲覧リクエスト受信の有無や頻度とは無関係かつ独立に実行する。ゲートウェイ装置１００は、内部処理やバックグラウンド処理として、ステップＳ４１〜Ｓ４７の各処理を繰り返すことにより、リソースの使用状態やＷｅｂ−ＧＵＩバンドルの動作状態が変化したときに、その変化を動作状態監視テーブル１６０により速く反映できる。従って、ゲートウェイ装置１００は、いずれのタイミングでＷｅｂ−ＧＵＩの閲覧リクエストを受信したとしても、予め最新の状態に更新された動作状態監視テーブル１６０の記録内容に基づいて、その後の処理を選択することが可能となる。なお、ゲートウェイ装置１００は、ステップＳ４１〜Ｓ４７の各処理を繰り返し実行するためにタイマーを用いてもよい。

（３．Ｗｅｂ−ＧＵＩの閲覧リクエスト受信時の動作）
図６は、Ｗｅｂ−ＧＵＩの閲覧リクエスト受信時におけるゲートウェイ装置１００の処理の流れを示すフローチャートである。Ｗｅｂ−ＧＵＩの閲覧リクエスト受信に先立って、図３及び図４の各処理が実行されているものとする。なお、図３及び図４の各処理が実行されている最中にＷｅｂ−ＧＵＩの閲覧リクエストを受信した時にも、ゲートウェイ装置１００は図６の各処理を実行する。

まず、ゲートウェイ装置１００のＨＴＴＰサーバ１２０は、通信部１１０が通信するＨＴＴＰクライアントからＷｅｂ−ＧＵＩの閲覧リクエストを受信する（ステップＳ６１）。
次に、リバースプロキシ部１２０ａは、動作状態監視テーブル１６０を参照することにより、Ｗｅｂ−ＧＵＩの閲覧リクエストに対応付けられるＷｅｂ−ＧＵＩバンドルの動作状態を確認する（ステップＳ６２）。ＨＴＴＰサーバ１２０が受信したＷｅｂ−ＧＵＩの閲覧リクエストに対応付けられるＷｅｂ−ＧＵＩバンドルは、その閲覧リクエストを処理対象とするＷｅｂ−ＧＵＩバンドルである。Ｗｅｂ−ＧＵＩの閲覧リクエストについては、そのＵＲＬ(Uniform Resource Locator)の構造によって応答処理が担当されるべきＷｅｂ−ＧＵＩバンドルが決まっている。図２の例では、閲覧リクエスト「http://xxx.setup/8080/bbb/*」の応答処理を担当すべきＷｅｂ−ＧＵＩバンドルは、Ｗｅｂ−ＧＵＩバンドル（Ｂ）１４０ｂである。

次に、リバースプロキシ部１２０ａは、動作状態監視テーブル１６０の参照により、確認対象のＷｅｂ−ＧＵＩバンドルの動作状態が「休眠中」であるか否かを判定する（ステップＳ６３）。ステップＳ６３における判定の結果、確認対象のＷｅｂ−ＧＵＩバンドルの動作状態が「休眠中」であればステップＳ６４の処理に進む。他方、ステップＳ６３における判定の結果、確認対象のＷｅｂ−ＧＵＩバンドルの動作状態が「休眠中」でなければステップＳ６５の処理に進む。

ステップＳ６４においては、リバースプロキシ部１２０ａは、ＨＴＴＰサーバ１２０が受信したＷｅｂ−ＧＵＩの閲覧リクエストを、所定の「起動時送出用画面」の閲覧リクエスト（例えば「http://xxx.setup/80/shoki.html」）に変換して、ネイティブ部１００ａのＨＴＴＰサーバ１２０に送信する。ＨＴＴＰサーバ１２０は、「起動時送出用画面」の応答データを保有している。ＨＴＴＰサーバ１２０は、「起動時送出用画面」の応答データを送信することにより、リバースプロキシ部１２０ａに対して応答する。「起動時送出用画面」には、現在Ｗｅｂ−ＧＵＩバンドルが起動処理の途中であることを案内するメッセージ、ファームウェアのバージョン情報が含まれている。
「起動時送出用画面」の表示により、ＨＴＴＰクライアントのユーザは、閲覧を希望するＷｅｂ−ＧＵＩの処理モジュールは未だ起動処理中であることを確認する。

他方、リバースプロキシ部１２０ａは、動作状態監視テーブル１６０の参照により、確認対象のＷｅｂ−ＧＵＩバンドルの動作状態が「動作中」であるか否かを判定する（ステップＳ６５）。ステップＳ６５における判定の結果、確認対象のＷｅｂ−ＧＵＩバンドルの動作状態が「動作中」であればステップＳ６６の処理に進む。他方、ステップＳ６５における判定の結果、確認対象のＷｅｂ−ＧＵＩバンドルの動作状態が「動作中」でなければステップＳ６７の処理に進む。

ステップＳ６６においては、リバースプロキシ部１２０ａは、ＨＴＴＰサーバ１２０が受信したＷｅｂ−ＧＵＩの閲覧リクエストをＪａｖａ部１００ｂのＨＴＴＰサーバ１３０に転送する。この場合、閲覧リクエストに対して応答処理が担当されるべきＷｅｂ−ＧＵＩバンドルは動作中であることが確認されている。したがって、ＨＴＴＰサーバ１２０が受信したＷｅｂ−ＧＵＩの閲覧リクエスト（例えば「http://xxx.setup/8080/aaa/*」）をそのままＨＴＴＰサーバ１３０に転送する。これにより、閲覧リクエストに対して適切なＷｅｂ−ＧＵＩの画面データが送出される。

ステップＳ６７においては、確認対象のＷｅｂ−ＧＵＩバンドルの動作状態は「休眠中」ではなく（ステップＳ６３においてＮｏ）、「動作中」でもない（ステップＳ６５においてＮｏ）。したがって、確認対象のＷｅｂ−ＧＵＩバンドルの動作状態は「動作停止中」である。ステップＳ６７において、リバースプロキシ部１２０ａは、ＨＴＴＰサーバ１２０が受信したＷｅｂ−ＧＵＩの閲覧リクエストを、所定の「緊急時送出用画面」の閲覧リクエスト（例えば「http://xxx.setup/80/kinkyu.html」）に変換する。リバースプロキシ部１２０ａは、変換後の「緊急時送出用画面」の閲覧リクエストをネイティブ部１００ａのＨＴＴＰサーバ１２０に送信する。ＨＴＴＰサーバ１２０は、「緊急時送出用画面」の応答データを保有している。ＨＴＴＰサーバ１２０は、「緊急時送出用画面」の応答データを送信することにより、リバースプロキシ部１２０ａに対して応答する。「緊急時送出用画面」には、現在Ｗｅｂ−ＧＵＩバンドルが動作停止していることを案内するメッセージ、ファームウェアのバージョン情報、ゲートウェイ装置１００のシステム再起動やファームウェア更新に関する復旧案内情報が含まれている。復旧案内情報の例としては、システム再起動のために押されるべきゲートウェイ装置１００のリセットボタンの位置を示す情報や更新ファームウェアのダウンロード先を示すＵＲＬがある。「緊急時送出用画面」の表示により、ＨＴＴＰクライアントのユーザは、復旧に必要な情報を確認する。

上記のゲートウェイ装置１００によれば、起動処理時のネイティブコードに依存しないコード（Ｊａｖａを含む）で実装された部分の機能が利用できない状況下において、ユーザは、起動処理の完了を待機してから再度Ｗｅｂ−ＧＵＩの閲覧リクエストを送信すべきことをより速く確認することができる。また、上記のゲートウェイ装置１００によれば、動作停止時のネイティブコードに依存しないコード（Ｊａｖａを含む）で実装された部分の機能が利用できない状況下において、ユーザは、閲覧を希望するＷｅｂ−ＧＵＩの処理モジュールの動作停止状態から復旧するためには画面の案内に従ったシステム再起動やファームウェア更新などの対処が必要となることをより速く確認することができる。これにより、ユーザは、起動処理時や動作停止時などネイティブコードに依存しないコード（Ｊａｖａを含む）で実装された部分の機能が利用できない状況下における応答速度を向上させることが可能となる。

なお、閲覧リクエストを処理するＷｅｂ−ＧＵＩバンドルが不動作時、つまり「休眠中」「動作停止中」に実行される、予め定められている不動作時対応処理の内容は、「起動時送出用画面」の表示や「緊急時送出用画面」の表示に限られない。例えば、ゲートウェイ装置１００が、Ｗｅｂ−ＧＵＩの閲覧リクエストを処理すべきＷｅｂ−ＧＵＩバンドルの動作状態が「動作停止中」であることを確認した時には、自動的に自機を再起動処理するようにしてもよい。この場合には、再起動処理する前に、ゲートウェイ装置１００のユーザから再起動処理の許可の入力指示を受け付ける構成とすることが好ましい。また、ゲートウェイ装置１００が、Ｗｅｂ−ＧＵＩの閲覧リクエストを処理すべきＷｅｂ−ＧＵＩバンドルの動作状態が「休眠中」「動作停止中」であることを確認した時には、各々の状態に応じた種類の警報音を鳴らしたり、ゲートウェイ装置１００に接続された他の端末機器を通じて、「休眠中」「動作停止中」であることやその対策をユーザに情報提供したりしてもよい。

また、上記の説明において、動作状態監視部１５０は、Ｊａｖａアプリケーションであるバンドル〔Ｗｅｂ−ＧＵＩバンドル（Ａ）１４０ａ，Ｗｅｂ−ＧＵＩバンドル（Ｂ）１４０ｂ，Ｗｅｂ−ＧＵＩバンドル（Ｃ）１４０ｃ〕の動作状態を監視するものとしたが、動作状態監視部１５０が動作状態を監視するアプリケーションは、Ｊａｖａのバンドルに限定されるものではない。Ｗｅｂ−ＧＵＩの閲覧リクエストに応答する処理は、Ｊａｖａ以外のネイティブコードに依存しないコードのアプリケーションによっても実現可能である。Ｊａｖａ以外のネイティブコードに依存しないコードのアプリケーションによって、Ｗｅｂ−ＧＵＩの閲覧リクエストに応答する処理を実現する場合には、動作状態監視部１５０は、上記アプリケーションの動作状態を監視するものとすればよい。

以上、この発明の実施形態について図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計も含まれる。なお、当然ながら、上述した実施の形態および複数の変形例は、その内容が相反しない範囲で組み合わせることができる。また、上述した実施の形態および変形例では、各部の構造などを具体的に説明したが、その構造などは本願発明を満足する範囲で各種に変更することができる。

１００…ゲートウェイ装置；Ｗｅｂサーバシステム， １００ａ…ネイティブ部， １００ｂ…Ｊａｖａ部， １１０…通信部， １２０…ＨＴＴＰサーバ；第２のＷｅｂサーバ， １２０ａ…リバースプロキシ部；不動作時対応部， １３０…ＨＴＴＰサーバ；第１のＷｅｂサーバ， １４０ａ…Ｗｅｂ−ＧＵＩバンドル（Ａ）；アプリケーション， １４０ｂ…Ｗｅｂ−ＧＵＩバンドル（Ｂ）；アプリケーション， １４０ｃ…Ｗｅｂ−ＧＵＩバンドル（Ｃ）；アプリケーション， １５０…動作状態監視部， １６０…動作状態監視テーブル；監視テーブル， １７０…リソース監視部

Claims (4)

1. ネイティブコードに依存しないコードで実装されたアプリケーションの処理によって、Ｗｅｂ−ＧＵＩの閲覧リクエストに応答する第１のＷｅｂサーバと、ネイティブコードで実装され、前記閲覧リクエストを受信し、当該閲覧リクエストを前記第１のＷｅｂサーバに転送する第２のＷｅｂサーバと、を備えるＷｅｂサーバシステムであって、
   前記アプリケーションの動作状態を監視する動作状態監視部と、
   前記動作状態監視部によって監視された前記アプリケーションの動作状態を記録する監視テーブルと、
   前記第２のＷｅｂサーバが前記閲覧リクエストを受信した場合には、前記監視テーブルを参照し、当該閲覧リクエストを処理するアプリケーションが動作していなければ、予め定められている不動作時対応処理を実行する不動作時対応部とを備えることを特徴とするＷｅｂサーバシステム。
2. 前記アプリケーションのリソース使用状態を監視するリソース監視部を更に備え、
   前記リソース監視部は、特定アプリケーションの使用リソースの状態値が閾値を超えた場合には、当該特定アプリケーションを前記動作状態監視部の監視対象とすることを特徴とする請求項１に記載のＷｅｂサーバシステム。
3. ネイティブコードに依存しないコードで実装されたアプリケーションの処理によって、Ｗｅｂ−ＧＵＩの閲覧リクエストに応答する第１のＷｅｂサーバと、ネイティブコードで実装され、前記閲覧リクエストを受信し、当該閲覧リクエストを前記第１のＷｅｂサーバに転送する第２のＷｅｂサーバとを連携させるＷｅｂサーバ連携方法であって、
   前記アプリケーションの動作状態を監視する動作状態監視段階と、
   前記動作状態監視段階にて監視された前記アプリケーションの動作状態を記録する記録段階と、
   前記第２のＷｅｂサーバが前記閲覧リクエストを受信した場合には、前記記録段階における記録内容を参照し、当該閲覧リクエストを処理するアプリケーションが動作していなければ、予め定められている不動作時対応処理を実行する不動作時対応段階とを備えるＷｅｂサーバ連携方法。
4. ネイティブコードに依存しないコードで実装されたアプリケーションの処理によって、Ｗｅｂ−ＧＵＩの閲覧リクエストに応答する第１のＷｅｂサーバと、ネイティブコードで実装され、前記閲覧リクエストを受信し、当該閲覧リクエストを前記第１のＷｅｂサーバに転送する第２のＷｅｂサーバと、を備えるＷｅｂサーバシステムとしてのコンピュータを、
   前記アプリケーションの動作状態を監視する動作状態監視部と、
   前記動作状態監視部によって監視された前記アプリケーションの動作状態を記録する監視テーブルと、
   前記第２のＷｅｂサーバが前記閲覧リクエストを受信した場合には、前記監視テーブルを参照し、当該閲覧リクエストを処理するアプリケーションが動作していなければ、予め定められている不動作時対応処理を実行する不動作時対応部として機能させるためのプログラム。

Images