JP2009151744A - 情報処理装置、情報処理方法およびプログラム - Google Patents

Abstract

【課題】単一の仮想マシン環境と同じ手法でＷｅｂアプリケーションの開発を行うことができる情報処理装置を提供する。
【解決手段】この情報処理装置は、複数の仮想マシンが動作する装置であり、各仮想マシンが、少なくとも１つのアプリケーションをアドレス情報と対応付けて管理情報として保持し、管理情報とクライアントから受信したリクエストに含まれるアドレス情報とからリクエストを処理するアプリケーションを判別するアプリケーション管理部２５を備える。複数の仮想マシンの１つは、さらに、他の仮想マシンの管理情報と識別情報とを対応付けて保持し、他の仮想マシン上で動作するアプリケーションのアドレス情報を含むリクエストを受信した場合に、管理情報および識別情報と受信したリクエストに含まれるアドレス情報とから仮想マシンを判別し、その仮想マシンへリクエストを転送するリクエスト転送部２６を備える。
【選択図】 図３

Description

本発明は、複数の仮想マシンが動作する環境において、単一の仮想マシンが動作する環境と同様にしてアプリケーション開発を行うことができる情報処理装置、情報処理方法およびそれを実現するための装置可読なプログラムに関する。

顧客ごとに最適なオフィス環境を提供するために、アプリケーションの追加により顧客ごとにカスタマイズ可能なシステムが検討されている。追加されるアプリケーションには、第３ベンダが開発するものも含まれるが、この追加により、システムの基本機能が損なわれるものであってはならない。ここで、第３ベンダとは、ハードウェアやＯＳ等、既存の環境に組み込むことで、新しい機能を提供するハードウェアまたはソフトウェア等を提供するベンダをいう。

アプリケーションを開発し、追加するにあたって、そのアプリケーションに対するリクエストを受けた場合、そのアプリケーションを実行するリソースへ適切にそのリクエストを振り分けなければならない。

アクセス状況や処理負荷に応じて、サーバに組み込まれたＣＰＵやメモリを制御して最適な処理性能を提供するキャパシティオンデマンドという技術がある。このキャパシティオンデマンドを容易にするために、Ｗｅｂサーバを遠隔かつ動的に構成する方法およびシステムが提案されている（例えば、特許文献１参照）。

この方法およびシステムでは、クライアントからのリクエストを処理するサーバ群１と、リソースを提供するサーバ群３と、サーバ群１のパフォーマンスとサーバ群３のパフォーマンスとが閾値に達しているかどうかを判定するサーバ２とからなり、サーバ群１またはサーバ群３のパフォーマンス状況に応じてサーバ群に対してサーバを追加または削除する。これにより、頑強かつ柔軟なＷｅｂサーバを実現している。この方法およびシステムでは、１つのサーバが他のサーバへ処理を適切に振り分けており、リソースの動的追加が可能である。

また、パーソナルコンピュータ（ＰＣ）にドライバを必要とすることなく、ＰＣの機種やＯＳに依存することなく、Ｗｅｂサービスを提供することが可能な画像形成装置が提案されている（例えば、特許文献２参照）。この画像形成装置は、複数のハードウェア資源ごとにＷｅｂサービスを提供するための手段を備え、リクエスト内のメッセージ交換プロトコルに従って記述されたメッセージに含まれるＷｅｂサービスを特定する情報に対応するＷｅｂサービス関数をコールすることにより、Ｗｅｂサービスを特定し、Ｗｅｂサービスに分配してレスポンスを提供している。この装置では、リクエストを解析し、適切な処理部へリクエストを振り分けている。

ＵＮＩＸ（登録商標）等のプロセスベースのオペレーティングシステム（ＯＳ）で、上記のアプリケーションの追加により顧客ごとにカスタマイズ可能なシステムを構築する場合、システムの堅牢性を向上させるために、適度な粒度でプロセスを分割するのが一般的である。ここで、堅牢性とは、プログラムにおいて、エラーや例外等に強く、簡単には暴走しないことをいう。

アプリケーションの開発言語としてＪａｖａ（登録商標）言語を用いる場合、単一のプロセス、すなわち単一の仮想マシン上で複数のアプリケーションを動作させることになる。この場合、細かい粒度でプロセスを分割するのは現実的ではない。しかしながら、仮想マシンを２つにし、少なくとも基本機能を実現するアプリケーションを一方の仮想マシン上で動作させ、第３ベンダが開発したアプリケーションをもう一方の仮想マシン上で動作させるように構成することで、システムの堅牢性を向上させることが可能となる。

特表２００５−５３９２９８号公報 特開２００７−１３５２３８号公報

上記特許文献１の技術は、サーバ資源の最適化であり、各サーバがハードウェア的に独立していることを前提とし、複数の仮想マシンが動作する装置に適用することはできない。

上記特許文献２の技術は、利用者の環境に依存することなく、Ｗｅｂサービスを提供するものであり、複数の仮想マシンが動作する環境において、各仮想マシン上で動作するアプリケーションにリクエストを適切に振り分けるものではない。

複数の仮想マシンが動作する環境でアプリケーション開発を行う場合に、１つのＨＴＴＰサーバですべての仮想マシンのＷｅｂアプリケーションを管理しようとすると、ＨＴＴＰサーバとＷｅｂアプリケーションとの間にプロセス間通信が必要となる。各Ｗｅｂアプリケーションにプロセス間通信の処理を加えることは、アプリケーション開発に大きな負担がかかり、その開発が困難なものとなる。これに対し、単一の仮想マシンが動作する環境では、単一のプロセス上で１つのＨＴＴＰサーバおよび複数のアプリケーションが動作するため、プロセス間通信は不要であり、このような問題は生じない。

そこで、Ｗｅｂアプリケーションにプロセス間通信の処理を加えることなく簡単にアプリケーション開発を行うことができ、複数の仮想マシンが動作する環境にその開発したアプリケーションを追加しても、クライアントから受信したリクエストを適切に各仮想マシン上で動作するアプリケーションに振り分けることができる装置の提供が望まれている。

本発明は、上記課題に鑑み、複数の仮想マシンが動作する情報処理装置であって、各前記仮想マシンが、少なくとも１つのアプリケーションをアドレス情報と対応付けて管理情報として保持し、前記管理情報とクライアントから受信したリクエストに含まれるアドレス情報とから、前記リクエストを処理するアプリケーションを判別するアプリケーション管理部を含み、前記複数の仮想マシンの１つが、さらに、他の前記仮想マシンの前記アプリケーション管理部が保持する前記管理情報と前記他の仮想マシンを識別するための識別情報とをそれぞれ対応付けて保持し、前記他の仮想マシン上で動作するアプリケーションのアドレス情報を含むリクエストを前記クライアントから受信した場合に、前記管理情報および前記識別情報と、受信した前記リクエストに含まれるアドレス情報とから、前記リクエストを受信すべき前記他の仮想マシンを判別し、前記他の仮想マシンへ前記リクエストを転送するリクエスト転送部を備える。

また、本発明は、複数の仮想マシンが動作する情報処理装置で実行される情報処理方法であって、各前記仮想マシンが、少なくとも１つのアプリケーションをアドレス情報と対応付けて管理情報として保持し、前記複数の仮想マシンの１つであるマスター仮想マシンが、さらに、他の仮想マシンであるワーカー仮想マシンが保持する前記管理情報と前記ワーカー仮想マシンを識別するための識別情報とをそれぞれ対応付けて保持し、前記ワーカー仮想マシン上で動作するアプリケーションのアドレス情報を含むリクエストを前記クライアントから受信した場合に、前記マスター仮想マシンが保持する前記管理情報および前記識別情報と、受信した前記リクエストに含まれるアドレス情報とから、前記リクエストを受信すべき前記ワーカー仮想マシンを判別し、前記ワーカー仮想マシンへ前記リクエストを転送するステップと、前記ワーカー仮想マシンにおいて、当該ワーカー仮想マシンが保持する前記管理情報とクライアントから受信したリクエストに含まれるアドレス情報とから、前記リクエストを処理するアプリケーションを判別するステップと、判別された前記アプリケーションを使用して前記リクエストを処理するステップと、処理結果を前記マスター仮想マシンへ送信するステップと、を含む。

また、本発明は、複数の仮想マシンが動作する情報処理装置により読み取り可能な、クライアントからのリクエストを処理するためのプログラムであって、各前記仮想マシンが、少なくとも１つのアプリケーションをアドレス情報と対応付けて管理情報として保持し、前記複数の仮想マシンの１つであるマスター仮想マシンが、さらに、他の仮想マシンであるワーカー仮想マシンが保持する前記管理情報と前記ワーカー仮想マシンを識別するための識別情報とをそれぞれ対応付けて保持していて、前記プログラムが、前記ワーカー仮想マシン上で動作するアプリケーションのアドレス情報を含むリクエストを前記クライアントから受信した場合に、前記マスター仮想マシンが保持する前記管理情報および前記識別情報と、受信した前記リクエストに含まれるアドレス情報とから、前記リクエストを受信すべき前記ワーカー仮想マシンを判別し、前記ワーカー仮想マシンへ前記リクエストを転送するステップと、前記ワーカー仮想マシンにおいて、当該ワーカー仮想マシンが保持する前記管理情報とクライアントから受信したリクエストに含まれるアドレス情報とから、前記リクエストを処理するアプリケーションを判別するステップと、判別された前記アプリケーションを使用して前記リクエストを処理するステップと、処理結果を前記マスター仮想マシンへ送信するステップと、を前記情報処理装置に実行させる。

本発明によれば、クライアントから受信したリクエストに含まれるアドレス情報と、管理情報および識別情報とから、このリクエストを処理すべき仮想マシンを判別し、当該仮想マシンへ前記リクエストを転送する。これにより、複数の仮想マシンが動作する環境にその開発したアプリケーションを追加しても、クライアントから受信したリクエストを適切に各仮想マシン上で動作するアプリケーションに振り分けることができる。

図１は、本発明の情報処理装置の一つの実施形態であるサーバ装置を含むネットワーク機器構成を例示した図である。図１では、サーバ装置１０と、クライアント装置１１とがネットワーク１２に接続され、互いに通信可能とされている。

クライアント装置１１は、ソフトウェアとしてＷｅｂブラウザを実装し、サーバ装置１０は、ソフトウェアとしてＷｅｂサーバを実装している。Ｗｅｂサーバは、Ｗｅｂブラウザから出されるリクエストを、インターネット等のネットワーク１２を介して受信し、Ｗｅｂアプリケーションにより処理し、その処理結果をＷｅｂブラウザへ送信する。

Ｗｅｂブラウザが、ユーザにより指定されたＵＲＬに対応する情報を取り寄せる場合、Ｗｅｂブラウザは、Ｗｅｂサーバに対し、リクエストとしてそのＵＲＬを送る。Ｗｅｂサーバは、そのＵＲＬを受け取り、ＵＲＬに含まれるパス名、すなわちファイル名あるいはディレクトリ名から、Ｗｅｂページを表示させるためのファイルを読み出し、そのファイルを処理結果として返す。

ＷｅｂブラウザとＷｅｂサーバとの間の通信は、ＨＴＴＰ等の通信プロトコルを使用して行われる。このＨＴＴＰを用いて通信を行うＷｅｂブラウザは、ＨＴＴＰクライアントと呼ばれ、Ｗｅｂサーバは、ＨＴＴＰサーバと呼ばれる。以下では、ＷｅｂブラウザをＨＴＴＰクライアント、ＷｅｂサーバをＨＴＴＰサーバと表記する。ＨＴＴＰサーバは、ＨＴＴＰクライアントからのリクエストを受信するために、互いを接続する接続口となる外部ポートを開く。この外部ポートは、一般にポート番号８０で、１つのみである。このため、ＨＴＴＰサーバとＨＴＴＰクライアントとの間の通信は、この１つの外部ポートのみを介して行われる。

このサーバ装置１０およびクライアント装置１１は、ＨＴＴＰサーバおよびＨＴＴＰクライアントを動作させるためのＣＰＵ、ＣＰＵが実行するためのプログラムを格納するメモリ、通信を行うためのネットワークボードやネットワークカードといった通信インタフェースを備えるＰＣや複合機等とすることができる。なお、図１では、クライアント装置１１として１つのＰＣのみが示されているが、２つ以上のクライアント装置１１がネットワーク１２に接続され、各クライアント装置１１からリクエストを送信することもできる。

次に、図１に示すサーバ装置１０に実装されるモジュールの構成を、図２を参照して詳細に説明する。このサーバ装置１０は、複数の仮想マシンを備えることができるが、図２では、３つの仮想マシンのみが示されている。ここで、仮想マシンとは、コンピュータのＣＰＵやメモリ等のリソースを、物理的構成によらず柔軟に分割したり統合して仮想化した上で、その仮想化したコンピュータを実行するソフトウェアである。また、仮想マシンは、Ｊａｖａ（登録商標）をプログラミング言語とするＪａｖａ（登録商標）仮想マシンとすることができる。なお、このＪａｖａ（登録商標）仮想マシンは、各ＯＳに実行ファイルとして存在し、実行後、クラスファイルを読み込み、クラス内のメソッドを呼び出し実行する。

サーバ装置１０は、３つの仮想マシンを同時に起動させることができ、このため、同時に異なる３つのＯＳを実行し、それらＯＳ上でそれぞれ、アプリケーションを動作させることができる。図２では、３つの仮想マシン２０、３０、４０がそれぞれ１つのＨＴＴＰサーバ２１、３１、４１を含み、仮想マシン２０が３つのＷｅｂアプリケーション２２ａ〜２２ｃ、仮想マシン３０が２つのＷｅｂアプリケーション３２ａ、３２ｂ、仮想マシン４０が２つのＷｅｂアプリケーション４２ａ、４２ｂを備えている。各仮想マシン上では、各ＨＴＴＰサーバおよび各Ｗｅｂアプリケーションを動作させることができる。なお、ＨＴＴＰサーバ２１、３１、４１は、同一のモジュールである。一方、Ｗｅｂアプリケーション２２ａ〜２２ｃ、３２ａ、３２ｂ、４２ａ、４２ｂは、互いに異なるモジュールである。

３つの仮想マシン２０、３０、４０は、１つのマスター仮想マシン２０と、それ以外のワーカー仮想マシン３０、４０とに分類される。マスター仮想マシン２０は、サーバ装置１０の外部から外部ポートを使用してリクエストを受信し、そのリクエストに含まれるＵＲＬ等のアドレス情報がワーカー仮想マシン３０のＷｅｂアプリケーションあるいはワーカー仮想マシン４０のＷｅｂアプリケーションを指し示すものである場合、そのリクエストの処理をそれらの仮想マシンに振り分ける。ワーカー仮想マシン３０、４０は、マスター仮想マシン２０から、サーバ装置１０の内部でのみ用いられる内部ポートを使用してリクエストを受け取り、そのリクエストに含まれるＵＲＬで指し示されるＷｅｂアプリケーションにより処理を実行し、処理結果をマスター仮想マシン２０へ返す。その後、マスター仮想マシン２０は、リクエストの送信元であるクライアント装置１１へ外部ポートを使用してその処理結果を送信する。

Ｊａｖａ（登録商標）では、サーブレットやＪＳＰ（登録商標）という形でＷｅｂアプリケーションを作り、このＷｅｂアプリケーションを、上記でいうＨＴＴＰサーバに対応するアプリケーションサーバを用いて実行する。ここで、サーブレットとは、サーバで実行するためのＪａｖａ（登録商標）プログラムで、ＪＳＰ（登録商標）とは、ＨＴＭＬにＪａｖａ（登録商標）プログラムを埋め込んだファイルである。アプリケーションサーバとしては、一例としてＴｏｍｃａｔ（登録商標）を用いることができ、さらに、Ｗｅｂアプリケーション用フレームワークとしてＳｔｒｕｔｓ（登録商標）を用いることができる。このフレームワークは、プログラムの枠組みを提供するライブラリであり、アプリケーションに必要なデータの入出力やエラー処理、画面遷移等の基本的なしくみを提供する。Ｊａｖａ（登録商標）アプリケーションを開発する基本ツールとしてＪ２ＳＥを用い、Ｗｅｂアプリケーションを作ることができる。作られたＷｅｂアプリケーションは、データベースに格納される。

作成されたＷｅｂアプリケーションを使用しての具体的な処理を説明すると、Ｊａｖａ（登録商標）仮想マシンであるＪ２ＳＥ上でアプリケーションサーバであるＴｏｍｃａｔ（登録商標）を稼動させ、Ｗｅｂアプリケーションを読み出し、そのＷｅｂアプリケーションを構成するサーブレットおよびＪＳＰ（登録商標）を実行してリクエストを処理し、処理結果をＨＴＴＰクライアントへ返すことができる。したがって、このＪ２ＳＥを仮想マシンとして、Ｔｏｍｃａｔ（登録商標）をＨＴＴＰサーバとして利用することができる。

このように、各仮想マシン上にＨＴＴＰサーバが存在するため、仮想マシンごとに独立して、Ｗｅｂアプリケーションの開発を行うことができる。また、複数の仮想マシンが動作する環境であっても、単一の仮想マシンが動作する環境と同様に、プロセス間通信の処理を加えることなく、簡単にＷｅｂアプリケーションの開発を行うことができ、これにより、Ｗｅｂアプリケーションの開発時の負荷が軽減し、Ｗｅｂアプリケーション開発効率を向上させることができる。

図３を参照して、マスター仮想マシン２０上で動作するＨＴＴＰサーバの構成について詳細に説明する。ＨＴＴＰサーバは、クライアント装置１１のＨＴＴＰクライアント１００から出されたリクエストを、ネットワーク１２を介して受信し、そのリクエストを解釈するリクエスト受信部２３と、Ｗｅｂアプリケーションによる処理結果をレスポンスとして組み立て、ネットワーク１２を介してクライアント装置１１のＨＴＴＰクライアントへ送信するレスポンス送信部２４と、複数のＷｅｂアプリケーションをそれぞれＵＲＬと対応付けて保持するアプリケーション管理部２５と、他のＨＴＴＰサーバに処理を振り分けるためにリクエストを転送するリクエスト転送部２６とを備える。

さらに、図３では、リクエストを一時的にメモリに保存し、要求に応じて取り出すリクエスト保存部２７と、複数のワーカーＨＴＴＰサーバへリクエストを転送する優先順位に関する優先度情報を保存する仮想マシン制御部２８とを備えている。

ここで、マスター仮想マシン２０上で動作するＨＴＴＰサーバ２１は、マスターＨＴＴＰサーバであり、ワーカー仮想マシン３０、４０上で動作するＨＴＴＰサーバ３１、４１は、ワーカーＨＴＴＰサーバである。これらのＨＴＴＰサーバ２１、３１、４１は、同一のモジュールであるが、それら自身が存在する仮想マシンがマスターであるか、ワーカーであるかにより、マスターＨＴＴＰサーバあるいはワーカーＨＴＴＰサーバのいずれかとして振る舞う。例えば、マスター仮想マシン２０は、基本機能を実現するためのＷｅｂアプリケーションを実装する仮想マシンとし、ワーカー仮想マシン３０、４０は、サーバ装置１０の管理者が機能を追加するために作成したＷｅｂアプリケーションを実装する仮想マシンや、第３ベンダが作成したＷｅｂアプリケーションを実装する仮想マシンとすることができる。

マスターＨＴＴＰサーバ２１は、サーバ装置１０外部の装置であるクライアント装置１１とネットワーク１２を介して通信を行うために外部ポートを開く。これにより、サーバ装置１０の外部、例えばクライアント装置１１から、この外部向けのポートに対してアクセスすることが可能となる。

一方、ワーカーＨＴＴＰサーバ３１、４１は、サーバ装置１０の内部で通信を行うために内部ポートを開く。この内部ポートは、マスターＨＴＴＰサーバ２１とワーカーＨＴＴＰサーバ３１、４１との間の通信を可能にするためのもので、内部送信・受信機能であるループバックを使用してアクセスすることができる。内部ポートは、サーバ装置１０内部のＨＴＴＰサーバ間通信でのみ使用されるため、サーバ装置１０外部からワーカーＨＴＴＰサーバ３１、４１へアクセスすることはできない。なお、ポート番号の重複は許されないので、外部ポートと内部ポートとは異なるポート番号が割り当てられる。外部ポートは、一般にポート番号８０であるため、内部ポートは、それ以外の、例えばポート番号８０８０、８０８１を割り当てることができる。

マスターＨＴＴＰサーバ２１およびワーカーＨＴＴＰサーバ３１、４１は、自身がマスターであるか、ワーカーであるかを知っている。しかしながら、マスター仮想マシン２０およびワーカー仮想マシン３０、４０上で動作するＷｅｂアプリケーション２２ａ〜２２ｃ、３２ａ、３２ｂ、４２ａ、４２ｂはいずれも、自身がマスターであるか、ワーカーであるかを知らない。これらは、自身がマスターか、ワーカーかを知っているＨＴＴＰサーバ２１、３１、４１により管理される。このため、Ｗｅｂアプリケーションをマスターであるか、ワーカーであるかを区別することなく開発することができる。

図４を参照して、マスター仮想マシン２０上のＷｅｂアプリケーションを、マスターＨＴＴＰサーバ２１に登録する場合の処理について説明する。Ｗｅｂアプリケーションを登録する場合、マスター仮想マシン２０に存在するＷｅｂアプリケーションは、マスター仮想マシン２０に存在するＨＴＴＰサーバ２１に対してＵＲＬの登録を行う。具体的には、Ｗｅｂアプリケーション２２ａが、ＨＴＴＰサーバ２１に対して、「url1」のＵＲＬ登録を要求すると（ステップＳ１１）、ＨＴＴＰサーバ２１に含まれるアプリケーション管理部２５が、このＵＲＬをＷｅｂアプリケーション２２ａと対応付けて記憶する（ステップＳ１２）。すなわち、そのＵＲＬを、Ｗｅｂアプリケーション２２ａを識別するアプリケーション名等と対応付けて対応テーブル等に記憶する。また、アプリケーション管理部２５は、ＵＲＬの記憶後、記憶が完了したことのレスポンスをＷｅｂアプリケーション２２ａへ返す（ステップＳ１３）。

一方、ＵＲＬの登録後、クライアント装置１１のＨＴＴＰクライアント１００から、「GET /url1 HTTP/1.1」のリクエストが送信されると（ステップＳ１４）、ＨＴＴＰサーバ２１のリクエスト受信部２３がこれを受け取り、リクエストを解釈する（ステップＳ１５）。ここでは、「url1にあるファイルを転送規格HTTP/1.1で取得する」と解釈する。そして、リクエスト受信部２３は、このリクエストをどのＷｅｂアプリケーションに振り分けるかを決定するため、アプリケーション管理部２５に引き渡す（ステップＳ１６）。

アプリケーション管理部２５は、対応テーブルを参照し、リクエスト受信部２３から受け付けたリクエストに含まれるＵＲＬに対応するＷｅｂアプリケーションを探索する（ステップＳ１７）。ここで、対応するＷｅｂアプリケーションが見つかった場合、アプリケーション管理部２５は、その対応するＷｅｂアプリケーション（Ｗｅｂアプリケーション２２ａ）に処理を依頼する（ステップＳ１８）。Ｗｅｂアプリケーション２２ａでは、依頼された処理を実行し（ステップＳ１９）、この処理結果をレスポンスとしてアプリケーション管理部２５へ送信する（ステップＳ２０）。

次いで、アプリケーション管理部２５が、Ｗｅｂアプリケーションから受け付けたレスポンスをレスポンス送信部２４へ送信し（ステップＳ２１）、レスポンス送信部２４は、そのレスポンスをＨＴＴＰクライアント１００へ送信する（ステップＳ２２）。図４では、見つかったことを示す「HTTP/1.1 200 OK」というメッセージが送信されている。「HTTP/1.1」は転送規格で、「200」は成功を意味するステータスコードである。これらのメッセージとともに、そのアドレスにあるＷｅｂページを表示させるためのファイルがＨＴＴＰクライアント１００へ送られ、クライアント装置１１の画面上にＷｅｂページが表示される。なお、図４では、Ｗｅｂアプリケーション２２ａの登録について説明したが、Ｗｅｂアプリケーション２２ｂ、２２ｃについても同様の処理が行われるものとする。

ステップＳ１７において、ＵＲＬに対応するＷｅｂアプリケーションが見つからない場合には、リソースが見つからない旨のエラーメッセージをレスポンスとして送信するものとする。以下、図５を参照して、ＵＲＬに対応するＷｅｂアプリケーションが見つからない場合の処理について説明する。なお、図５においてステップＳ３１〜Ｓ３６の処理については、上述したステップＳ１１〜Ｓ１６の処理と同様であるため、説明を省略する。

ステップＳ３７において、アプリケーション管理部２５は、対応テーブルを参照し、リクエスト受信部２３から渡されたＵＲＬ「foo」に対応するＷｅｂアプリケーションを探索する。ここで、対応するＷｅｂアプリケーションが見つからないと判定した場合、アプリケーション管理部２５は、図５に示したように、リソースが見つからない旨のエラーメッセージ「404 Not Found」を作成し、そのエラーメッセージをレスポンスとしてレスポンス送信部２４へ送信する（ステップＳ３８）。レスポンス送信部２４は、このエラーメッセージをＨＴＴＰクライアント１００へ送信する（ステップＳ３９）。ＨＴＴＰプロトコルにおいて、「404」は見つからなかったことを示すステータスコードである。これにより、クライアント装置１１を操作するユーザに、リソースが見つからないことを認識させることができる。

次に、図６を参照して、ワーカー仮想マシン３０上のＷｅｂアプリケーションをワーカーＨＴＴＰサーバ３１に登録する場合について説明する。ワーカー仮想マシン３０に存在するＷｅｂアプリケーション３２ａは、同じワーカー仮想マシン３０に存在するＨＴＴＰサーバ３１に対してＵＲＬの登録を行う。具体的には、Ｗｅｂアプリケーション３２ａが、ＨＴＴＰサーバ３１に対して「url2」のＵＲＬ登録を行うと（ステップＳ４１）、アプリケーション管理部３５は、このＵＲＬをＷｅｂアプリケーション３２ａと対応付け、対応テーブル等に記憶する（ステップＳ４２）。

ＵＲＬの登録後、ＨＴＴＰサーバ３１は、ＨＴＴＰサーバ３１自身が存在する仮想マシンの種別、すなわちマスターかワーカーかを判別する。この場合、ワーカーと判別し、マスターＨＴＴＰサーバ２１へリクエストを転送してもらうための依頼を行う（ステップＳ４３）。なお、ワーカーＨＴＴＰサーバ３１からは、登録を行ったＵＲＬと、外部ポートのポート名あるいは番号と、内部ポートのポート名あるいはポート番号とを含む情報が、振り分け依頼登録としてマスターＨＴＴＰサーバ２１に送信されるものとする。これは、異なるマシンで処理を実行する手続きを規定するリモートプロシージャコール（ＲＰＣ）を使用することにより実現することができる。このように、ＲＰＣを使用することでマスターＨＴＴＰサーバ２１へＷｅｂアプリケーションのＵＲＬを動的に登録することができるため、ワーカーＨＴＴＰサーバ３１、４１にＷｅｂアプリケーションを追加しても、マスターＨＴＴＰサーバ２１へ修正を加える必要がなくなる。これにより、Ｗｅｂアプリケーション開発時の負荷が軽減し、Ｗｅｂアプリケーション開発効率を向上させることができる。

マスターＨＴＴＰサーバ２１が備えるリクエスト転送部２６では、ワーカーＨＴＴＰサーバ３１からＵＲＬと、外部ポートのポート名あるいは番号と、内部ポートのポート名あるいはポート番号とを受け取ると、これらの情報をアプリケーション管理部２５に渡す（ステップＳ４４）。アプリケーション管理部２５は、リクエスト転送部２６から受け取った各情報を対応付け、対応テーブル等に記憶すると（ステップＳ４５）、リクエスト転送部２６を介して記憶が完了したことを通知するレスポンスをワーカー仮想マシン３０のアプリケーション管理部３５に送信する（ステップＳ４６、Ｓ４７）。

一方、アプリケーション管理部３５では、リクエスト転送部２６から記憶が完了したことを通知するレスポンスを受け付けると、このレスポンスをＷｅｂアプリケーション３２ａに返すことで（ステップＳ４８）、登録処理が完了する。なお、図６では、Ｗｅｂアプリケーション３２ａの登録について説明したが、Ｗｅｂアプリケーション３２ｂについても同様の処理が行われるものとする。また、図６では、ワーカー仮想マシン３０について説明したが、ワーカー仮想マシン４０の場合でも同様の処理が行われるものとする。

一方、ＵＲＬの登録後に、クライアント装置１１のＨＴＴＰクライアント１００から、「GET /url2 HTTP/1.1」がリクエストとして送信されると（ステップＳ４９）、ＨＴＴＰサーバ２１のリクエスト受信部２３がこれを受け取り、そのリクエストを解釈する（ステップＳ５０）。この場合、「url2にあるファイルを転送規格HTTP/1.1で取得する」と解釈する。リクエスト受信部２３は、受け付けたリクエストをアプリケーション管理部２５へ渡すと（ステップＳ５１）、アプリケーション管理部２５は、対応テーブルを参照し、このリクエストに含まれたＵＲＬに対応するＷｅｂアプリケーション３２ａを探索する（ステップＳ５２）。

ここで、リクエストに含まれたＵＲＬ“url2”がＷｅｂアプリケーション３２ａに対応するものとすると、Ｗｅｂアプリケーション３２ａはワーカー仮想マシン３０上で動作するアプリケーションであるため、マスター仮想マシン２０上では見つからない。そのため、アプリケーション管理部２５は、リクエスト転送部２６に対し、ワーカー仮想マシン３０上で動作するワーカーＨＴＴＰサーバ３１へ転送するように、リクエストの転送依頼をする（ステップＳ５３）。リクエスト転送部２６では、リクエストの転送依頼を受け付けると、転送先となるワーカー仮想マシン３０の内部ポートのポート番号に対してリクエストを転送する（ステップＳ５４）。

このように、マスターＨＴＴＰサーバ２１は、ワーカーＨＴＴＰサーバ３１、４１へＨＴＴＰを用いてリクエストを転送する。この場合、ワーカーＨＴＴＰサーバ３１、４１は、一般的なＷｅｂブラウザからのリクエストを受けた場合と同じとなるため、ワーカーＨＴＴＰサーバ３１、４１のリクエスト処理に手を加える必要はない。また、マスターＨＴＴＰサーバ２１は、情報処理装置の外部と通信を行うために外部ポートを使用し、ワーカーＨＴＴＰサーバ３１、４１は、マスターＨＴＴＰサーバ２１と通信を行うために内部ポートと自身を識別するループバックアドレスとを使用して、リクエストを受信し、リクエストに対する処理結果を送信する。これにより、サーバ装置１０の外部からワーカーＨＴＴＰサーバ３１、４１への直接的なアクセスを防止することができるため、セキュリティ面を考慮しなければならないのはマスターＨＴＴＰサーバ２１のみでよく、装置全体として保守・管理の負担を軽減させることができる。

リクエスト転送部２６から送信されたリクエストは、ワーカー仮想マシン３０上で動作するワーカーＨＴＴＰサーバ３１のリクエスト受信部３３で解釈が行われた後（ステップＳ５５）、アプリケーション管理部３５へ渡される（ステップＳ５６）。アプリケーション管理部３５は、対応テーブルを参照し、リクエスト受信部３３から受け付けたリクエストに含まれるＵＲＬに対応するＷｅｂアプリケーションを探索する（ステップＳ５７）。この場合、ワーカー仮想マシン３０上で動作するＷｅｂアプリケーション３２ａ、３２ｂの中にそのＵＲＬに対応するＷｅｂアプリケーション３２ａが含まれているため、アプリケーション管理部３５は、Ｗｅｂアプリケーション３２ａに処理を依頼する（ステップＳ５８）。Ｗｅｂアプリケーション３２ａは依頼された処理を実行し（ステップＳ５９）、この処理結果をレスポンスとしてアプリケーション管理部３５へ送信する（ステップＳ６０）。アプリケーション管理部３５は、Ｗｅｂアプリケーション３２ａから受け付けたレスポンスをレスポンス送信部３４へ送信すると（ステップＳ６１）、レスポンス送信部３４は、そのレスポンスをマスター仮想マシン２０のリクエスト転送部２６に送信する（ステップＳ６２）。

一方、リクエスト転送部２６では、レスポンス送信部３４からレスポンスを受け付けると、このレスポンスをアプリケーション管理部２５に送信する（ステップＳ６３）。続いて、アプリケーション管理部２５は、リクエスト転送部２６から受け付けたレスポンスをレスポンス送信部２４に送信すると（ステップＳ６４）、レスポンス送信部２４は、そのレスポンスをＨＴＴＰクライアント１００へ送信する（ステップＳ６５）。

このように、マスターＨＴＴＰサーバ２１では、ワーカーＨＴＴＰサーバ各々が有するＷｅｂアプリケーションのＵＲＬと、当該ワーカーＨＴＴＰサーバの外部・内部ポートに関する情報とを対応付けた対応テーブルを用いて、ＨＴＴＰクライアント１００から受信したリクエストに含まれるＵＲＬ（アドレス情報）に対応する仮想マシンを判別し、当該仮想マシンへ前記リクエストを転送する。

次に、各ワーカー仮想マシンのＷｅｂアプリケーションが、同一のＵＲＬに対応付けられた場合の動作について説明する。まず、各ワーカー仮想マシンのＷｅｂアプリケーションに、同一のＵＲＬが設定されることになる背景について説明する。

Ｊａｖａ（登録商標）を用いてＷｅｂアプリケーションを作成する場合、上述したようにＳｔｒｕｔｓ（登録商標）等のフレームワークを利用することが一般的に行われている。フレームワークには商用又はオープンソースのものなど多種存在するが、その仕様によっては、ＵＲＬに含まれたディレクトリ指定部分に関わらず、当該ＵＲＬで指定されるファイルの拡張子部分に基づいて、Ｗｅｂアプリケーションが処理を行うものがある。このような仕様のフレームワークを用いた場合、Ｗｅｂアプリケーションの夫々が同一の拡張子について処理を行うよう規定されていると、各Ｗｅｂアプリケーションは実質同一のＵＲＬ、即ちファイル拡張子に対応付けられることになる。以下では、複数のＷｅｂアプリケーションが同一のＵＲＬに対応付けられた場合の処理について説明する。

図７を参照して、Ｗｅｂアプリケーション３２ａ、４２ａをワーカーＨＴＴＰサーバ３１、４１に登録する場合の処理について説明する。なお、図７では、Ｗｅｂアプリケーション３２ａ、４２ａについて説明するが、Ｗｅｂアプリケーション３２ｂ、４２ｂについても同様の処理が行われるものとする。また、図７において、ワーカー仮想マシン３０及びワーカー仮想マシン４０が有するＷｅｂアプリケーションの夫々は、同一のＵＲＬ、つまり同一のファイル拡張子に対応付けられているものとする。

まず、Ｗｅｂアプリケーション３２ａがＨＴＴＰサーバ３１に対し、ＵＲＬの登録を行うと（ステップＳ７１）、上述したように、アプリケーション管理部３５が、このＵＲＬとアプリケーション３２ａを対応付け、対応テーブル等に記憶する（ステップＳ７２）。なお、図７では、登録を行うＵＲＬを「/*.cgi」（アスタリスクは、任意の文字列）とした例を示しているが、これに限定されないものとする。

ＵＲＬの登録後、ＨＴＴＰサーバ３１は、ＨＴＴＰサーバ３１自身が存在する仮想マシンの種別、すなわちマスターかワーカーかを判別する。この場合、ワーカーと判別し、マスターＨＴＴＰサーバ２１へリクエストを転送してもらうための依頼を行う（ステップＳ７３）。

また、Ｗｅｂアプリケーション４２ａがＨＴＴＰサーバ４１に対し、Ｗｅｂアプリケーション３２ａと同じＵＲＬ（/*.cgi）の登録を行うと（ステップＳ７４）、アプリケーション管理部４５は、Ｗｅｂアプリケーション３２ａと同様に、このＵＲＬとＷｅｂアプリケーション４２ａとを対応付け、対応テーブル等に記憶する（ステップＳ７５）。ＵＲＬの登録後、ＨＴＴＰサーバ４１は、ＨＴＴＰサーバ４１自身が存在する仮想マシンの種別、すなわちマスターかワーカーかを判別する。この場合、ワーカーと判別し、マスターＨＴＴＰサーバ２１へリクエストを転送してもらうための依頼を行う（ステップＳ７６）。

一方、マスターＨＴＴＰサーバ２１が備えるリクエスト転送部２６では、ワーカーＨＴＴＰサーバ３１、４１からＵＲＬと、外部ポートのポート名あるいは番号と、内部ポートのポート名あるいはポート番号とを受け取ると、これらの情報をアプリケーション管理部２５に渡す（ステップＳ７７、Ｓ７８）。アプリケーション管理部２５は、リクエスト転送部２６から受け取ったワーカーＨＴＴＰサーバ３１、４１についての各情報を夫々対応付け、対応テーブル等に記憶すると（ステップＳ７９、Ｓ８０）、記憶が完了したことを通知するレスポンスをリクエスト転送部２６に送信する（ステップＳ８１、Ｓ８２）。リクエスト転送部２６は、アプリケーション管理部２５からレスポンスを受け付けると、ワーカー仮想マシン３０、４０のアプリケーション管理部３５、４５の夫々に対し、当該レスポンスを夫々送信する（ステップＳ８３、Ｓ８４）。一方、アプリケーション管理部３５、４５の夫々では、リクエスト転送部２６から記憶が完了したことを通知するレスポンスを受け付けると、このレスポンスをＷｅｂアプリケーション３２ａ、４２ａに夫々返すことで（ステップＳ８５、Ｓ８６）、登録処理が完了する。

なお、マスターＨＴＴＰサーバ２１では、リクエストを振り分けるために、ワーカーＨＴＴＰサーバ３１、４１からＵＲＬを受け取り、記憶するが、この場合、同じＵＲＬである。しかしながら、ワーカーＨＴＴＰサーバ３１が開いた内部ポートのポート番号は８０８０で、ワーカーＨＴＴＰサーバ４１が開いた内部ポートのポート番号は８０８１と異なり、この内部ポートのポート番号により判別することができるため、複数のアプリケーションについて同一のＵＲＬを登録することができる。これにより、各ワーカーＨＴＴＰサーバ３１、４１のＷｅｂアプリケーション開発者は、アプリケーション開発の際、他のワーカーＨＴＴＰサーバを有するＷｅｂアプリケーションとＵＲＬが重複しているかを意識する必要がなくなる。したがって、ワーカーＨＴＴＰサーバ間でＷｅｂアプリケーションのＵＲＬを調整する必要がないため、アプリケーション開発時の負荷を軽減し、アプリケーション開発効率を向上させることができる。

一方、ＵＲＬ登録後に、クライアント装置１１のＨＴＴＰクライアント１００から、「GET /url/app2.cgi HTTP/1.1」のリクエストが送信されると（ステップＳ８７）、ＨＴＴＰサーバ２１のリクエスト受信部２３がこれを受け取り、このリクエストを解釈する（ステップＳ８８）。この場合、「ディレクトリ名urlのディレクトリにあるファイル名app2.cgiというファイルを転送規格HTTP/1.1で取得する」と解釈する。

リクエスト受信部２３は、ＨＴＴＰクライアント１００から受け付けたリクエストをアプリケーション管理部２５へ渡す（ステップＳ８９）。アプリケーション管理部２５は、リクエスト受信部２３からリクエストを受け取ると、対応テーブルを参照し、このリクエストに含まれたＵＲＬに対応するＷｅｂアプリケーションを探索する（ステップＳ９０）。この場合、ＵＲＬに対応するＷｅｂアプリケーションはワーカー仮想マシン３０またはワーカー仮想マシン４０上で動作するアプリケーションであるため、マスター仮想マシン２０上では見つからない。そのため、アプリケーション管理部２５は、リクエスト転送部２６に対し、ワーカー仮想マシン３０上で動作するワーカーＨＴＴＰサーバ３１またはワーカーＨＴＴＰサーバ４１へリクエストを転送するよう依頼する（ステップＳ９１）。

ここで、２つのＷｅｂアプリケーション３２ａ、４２ａが登録したＵＲＬが同じであることから、リクエスト転送部２６は、２つのワーカー仮想マシン３０、４０のどちらかへリクエストを転送する（ステップＳ９２）。この場合、後に残りの仮想マシンへリクエストを再送する可能性があるため、リクエスト転送部２６は、受け付けたリクエストをリクエスト保存部２７に送信することで（ステップＳ９３）、当該リクエスト保存部２７にリクエストを一時的に保存する。

ステップＳ９２において、リクエスト転送部２６は、例えば、Ｗｅｂアプリケーションがアプリケーション管理部２５に予め登録しておいた各ワーカー仮想マシン（Ｗｅｂアプリケーション）への転送順序や、予め登録しておいた各ワーカー仮想マシン（Ｗｅｂアプリケーション）の優先順位を示す優先度情報等に従ってリクエストを転送する。ワーカー仮想マシン３０上で動作するＷｅｂアプリケーション３２ａが先に登録あるいは優先順位が高い場合、リクエスト転送部２６は、ワーカー仮想マシン３０が開いた内部ポートのポート番号に対してリクエストを転送する。

ワーカー仮想マシン３０上で動作するワーカーＨＴＴＰサーバ３１のリクエスト受信部３３では、マスター仮想マシン２０から転送されたリクエストを受信すると、このリクエストをリクエスト受信部２３と同様に解釈する（ステップＳ９４）。そして、リクエスト受信部３３は、このリクエストをどのＷｅｂアプリケーションに振り分けるかを決定するため、アプリケーション管理部３５に引き渡す（ステップＳ９５）。

アプリケーション管理部３５は、対応テーブルを参照し、リクエスト受信部３３から受け付けたリクエストに含まれるＵＲＬに対応するＷｅｂアプリケーションを探索する（ステップＳ９６）。ここで、リクエストされたファイル“app2.cgi”が、Ｗｅｂアプリケーション３２ａに対応するものとすると、アプリケーション管理部３５は、ワーカー仮想マシン３０上で動作するＷｅｂアプリケーション３２ａ、３２ｂの中に、そのＵＲＬに対応するＷｅｂアプリケーション３２ａが含まれていると判定し、Ｗｅｂアプリケーション３２ａに処理を依頼する（ステップＳ９７）。Ｗｅｂアプリケーション３２ａでは、依頼された処理を実行し（ステップＳ９８）、この処理結果をレスポンスとして、成功を示すステータスコード「200」とともにアプリケーション管理部３５へ送信する（ステップＳ９９）。アプリケーション管理部３５では、Ｗｅｂアプリケーション３２ａからレスポンスを受け付けると、レスポンス送信部３４へ送信し（ステップＳ１００）、レスポンス送信部３４では、アプリケーション管理部３５から送信されたレスポンスを、マスター仮想マシン２０のリクエスト転送部２６へ送信する（ステップＳ１０１）。

一方、リクエスト転送部２６では、ステップＳ９２で転送したリクエストに対するレスポンスを受け付けると、このレスポンスに含まれるステータスコードが予め設定された特別な値、例えば「900」であるか否かを判定する（ステップＳ１０２）。ステータスコードが特別な値でない場合、リクエスト転送部２６は、アプリケーション管理部２５を介してレスポンスをレスポンス送信部２４に送信する（ステップＳ１０３、Ｓ１０４）。次いで、レスポンス送信部２４は、アプリケーション管理部２５から受け付けたレスポンスを、ＨＴＴＰクライアント１００へ送信する（ステップＳ１０５）。

上記の特別な値は、ＨＴＴＰプロトコルでのステータスコードとして設定されていない値であればいかなる値であってもよく、例えば、上記のように「900」とすることができる。なお、この「900」というステータスコードは、リクエストが転送されたワーカー仮想マシンにおいて、対応するＷｅｂアプリケーションが見つからない場合に送信されるよう予め設定されているものとする。

上記の優先順位は、優先度情報としてユーザにより予め設定され、マスター仮想マシン２０上で動作するマスターＨＴＴＰサーバ２１に含まれる仮想マシン制御部２８が保持する。例えば、ワーカー仮想マシン３０に対し、優先度１、ワーカー仮想マシン４０に対し、優先度２として設定することができる。この優先度情報は、サーバ装置１０の起動時に設定され、また、実行時に動的に変更することができる。

この優先度情報を使用した処理について説明すると、マスターＨＴＴＰサーバ２１のリクエスト転送部２６は、仮想マシン制御部２８からマスター仮想マシン２０の優先度情報を取得し、リクエストを転送していない仮想マシンの中で最も優先度が高いものを選択してリクエストを転送する。その後、予め設定された特別な値のステータスコード、上記でいう「900」を受け取った場合、次の優先度の仮想マシンを選択し、リクエストを転送する。特別な値のステータスコードを受け取らなかった場合は、次の優先度の仮想マシンは選択されず、最も高い優先度の仮想マシン上で動作する、ＵＲＬに対応したＷｅｂアプリケーションにより処理を実行し、処理結果がリクエスト転送部２６へ送信される。

上記においてリクエストを再送する可能性がありうることを説明した。しかしながら、サーバ装置１０内で利用可能な高速メモリ（ＲＡＭ）には上限があり、リクエストをすべてこのＲＡＭに保持することができない場合がある。そこで、ＲＡＭに保持するサイズの上限を設け、リクエストのサイズが上限を超える場合には、リクエスト保存部２７は、その他のＨＤＤ等の記憶媒体に一時的に保存することができる。これにより、ＲＡＭのメモリサイズに制約がある場合でも、代わりとなる代替記憶媒体を利用することで、リクエストを再送することができる。

アプリケーション管理部２５に登録されたＵＲＬが同一で、リクエストを先に振り分けたワーカー仮想マシン３０上に対応するＷｅｂアプリケーションが存在する場合、図７に示した処理となる。しかしながら、先に振り分けたワーカー仮想マシン３０上に対応するＷｅｂアプリケーションが存在しない場合、図７と同様の処理にはならない。そこで、この場合の処理の流れを、図８を参照して説明する。

まず、クライアント装置１１のＨＴＴＰクライアント１００から、「GET /url/app3.cgi HTTP/1.1」のリクエストが送信されると（ステップＳ１１１）、ＨＴＴＰサーバ２１のリクエスト受信部２３がこれを受け取り、そのリクエストを解釈する（ステップＳ１１２）。この場合、「ディレクトリ名urlのディレクトリにあるファイル名app3.cgiというファイルを転送規格HTTP/1.1で取得する」と解釈する。なお、リクエストされたファイル“app3.cgi”は、Ｗｅｂアプリケーション４２ａを指定するものとする。

リクエスト受信部２３は、リクエストを解釈した後、受け取ったリクエストをアプリケーション管理部２５へ渡す（ステップＳ１１３）。アプリケーション管理部２５は、リクエスト受信部２３からリクエストを受け取ると、対応テーブルを参照し、このリクエストに含まれたＵＲＬに対応するＷｅｂアプリケーションを探索する（ステップＳ１１４）。この場合、ＵＲＬに対応するＷｅｂアプリケーションはワーカー仮想マシン３０またはワーカー仮想マシン４０上で動作するアプリケーションであるため、マスター仮想マシン２０上では見つからない。そのため、アプリケーション管理部２５は、リクエスト転送部２６に対し、ワーカー仮想マシン３０上で動作するワーカーＨＴＴＰサーバ３１またはワーカーＨＴＴＰサーバ４１へリクエストを転送するよう依頼する（ステップＳ１１５）。

リクエスト転送部２６は、アプリケーション管理部２５から転送の依頼を受け付けると、ワーカー仮想マシン３０又は４０が開いた内部ポートのポート番号に対してリクエストを転送する（ステップＳ１１６）。この場合もアプリケーション管理部２５に登録されたＵＲＬが同じであることから、リクエスト転送部２６は、予め設定された優先順位等に基づいて２つのワーカー仮想マシン３０、４０のどちらかへリクエストを転送する。また、後に残りの仮想マシンへリクエストを再送する可能性があるため、リクエスト転送部２６は、受け付けたリクエストをリクエスト保存部２７に送信することで（ステップＳ１１７）、このリクエストをリクエスト保存部２７に一時的に保存する。

ステップＳ１１６において、ワーカー仮想マシン３０の優先順位がワーカー仮想マシン４０よりも上位であった場合、リクエスト転送部２６は、まず、ワーカー仮想マシン３０の内部ポートのポート番号に対してリクエストを転送する。ワーカー仮想マシン３０では、ワーカーＨＴＴＰサーバ３１のリクエスト受信部３３がリクエストを受け付けると、リクエスト受信部２３と同様に解釈した後（ステップＳ１１８）、このリクエストをどのＷｅｂアプリケーションに振り分けるかを決定するため、アプリケーション管理部３５に引き渡す（ステップＳ１１９）。

アプリケーション管理部３５は、対応テーブルを参照し、リクエスト受信部３３から受け付けたリクエストに含まれるＵＲＬに対応するＷｅｂアプリケーションを探索する（ステップＳ１２０）。しかしながら、ワーカー仮想マシン３０上で動作するＷｅｂアプリケーション３２ａ、３２ｂの中には、リクエストされたＵＲＬに対応するＷｅｂアプリケーションは含まれていない。そこで、アプリケーション管理部３５は、Ｗｅｂアプリケーション３２ａを介し、他のワーカー仮想マシン４０にリクエストされたＵＲＬに対応するＷｅｂアプリケーションが存在するか否かを、ＲＰＣ（ＶＭ間通信）を使用して問い合わせる（ステップＳ１２１、Ｓ１２２）。なお、ここではＷｅｂアプリケーション３２ａを介して問い合わせを行う態様としたが、これに限らず、ワーカー仮想マシン３０上で動作する他のＷｅｂアプリケーション（３２ｂ）を介して問い合わせを行う態様としてもよい。

一方、問い合わせを受け付けたワーカー仮想マシン４０のＷｅｂアプリケーション４２ａ（４２ｂ）では、リクエストされたＵＲＬに対応するＷｅｂアプリケーションが自身に該当するか否かを判定する（ステップＳ１２３）。ここで、自己のＷｅｂアプリケーションがリクエストされたＵＲＬに該当すると判定した場合、該当するＷｅｂアプリケーション４２ａは、当該ＵＲＬに該当することを指示したレスポンス（ＴＲＵＥ）を、問い合わせを行ったＷｅｂアプリケーション３２ａに通知する（ステップＳ１２４）。なお、図８の場合、Ｗｅｂアプリケーション４２ｂはリクエストされたＵＲＬに対応しないが、この場合、Ｗｅｂアプリケーション４２ｂからはＵＲＬに該当しないことを指示するレスポンス（ＦＡＬＳＥ）が通知されるものとする。このように、リクエストが転送されたワーカーＨＴＴＰサーバのアプリケーション管理部は、他のワーカーＨＴＴＰサーバが対応するアプリケーションを有するか否かを調査するアプリケーション調査部として機能する。

Ｗｅｂアプリケーション３２ａでは、他のワーカー仮想マシン４０（Ｗｅｂアプリケーション４２ａ）から、レスポンス（ＴＲＵＥ）を受け取ると（ステップＳ１２３）、リクエストされたＵＲＬに該当するＷｅｂアプリケーションが他のワーカー仮想マシンに存在すること示したレスポンスをアプリケーション管理部３５に返す（ステップＳ１２５）。アプリケーション管理部３５では、Ｗｅｂアプリケーション３２ａからレスポンスを受け付けると、このレスポンスをレスポンス送信部３４に送信する（ステップＳ１２６）。レスポンス送信部３４は、アプリケーション管理部３５から受け付けたレスポンス（ＴＲＵＥ）に応じて、予め設定された特別な値のステータスコード（900 Forward Other）を、マスター仮想マシン２０のリクエスト転送部２６に送信する（ステップＳ１２７）。

リクエスト転送部２６は、ワーカー仮想マシン３０からステータスコードを受け付けると、このステータスコードが他のワーカー仮想マシンに存在することを示す特別な値、即ち、「900」であるか否かを判定する（ステップＳ１２８）。ここで、リクエスト転送部２６は、ステータスコードが他のワーカー仮想マシンに存在することを示す特別な値であると判定すると、リクエスト保存部２７に保持されたリクエストを読み込み（ステップＳ１２９）、次の優先順位のワーカー仮想マシン（ワーカー仮想マシン４０）に対し、読み込んだリクエストを転送する（ステップＳ１３０）。このように、マスターＨＴＴＰサーバ２１のリクエスト転送部２６は、リクエストを転送したワーカーＨＴＴＰサーバから、他のワーカーＨＴＴＰサーバが対応するアプリケーションを有しているとのレスポンスを受信した場合にのみ、次の優先順位のワーカーＨＴＴＰサーバへリクエストを転送する。

一方、ワーカー仮想マシン４０では、リクエスト受信部４３がリクエストを受信すると、リクエスト受信部２３と同様に当該リクエストを解釈する（ステップＳ１３１）。次いで、リクエスト受信部４３は、このリクエストをどのＷｅｂアプリケーションに振り分けるかを決定するため、アプリケーション管理部４５に引き渡す（ステップＳ１３２）。アプリケーション管理部４５は、対応テーブルを参照し、リクエスト受信部４３から受け付けたリクエストに含まれるＵＲＬに対応するＷｅｂアプリケーションを探索する（ステップＳ１３３）。ここで、Ｗｅｂアプリケーション４２ａは、リクエストされた“app3.cgi”に対応するため、アプリケーション管理部４５は、対応するＷｅｂアプリケーションがあると判断し、Ｗｅｂアプリケーション４２ａへ処理を依頼する（ステップＳ１３４）。

Ｗｅｂアプリケーション４２ａでは、依頼された処理を実行すると（ステップＳ１３５）、この処理結果とともに、リクエストに対する処理が成功した旨のステータスコード「200」をレスポンスとしてアプリケーション管理部４５へ返す（ステップＳ１３６）。アプリケーション管理部４５では、Ｗｅｂアプリケーション４２ａからレスポンスを受け付けると、このレスポンスをレスポンス送信部４４へ送信する（ステップＳ１３７）。また、レスポンス送信部４４は、アプリケーション管理部４５からレスポンスを受け付けると、このレスポンスをマスター仮想マシン２０のリクエスト転送部２６へ送信する（ステップＳ１３８）。

一方、マスター仮想マシン２０のリクエスト転送部２６では、ステップＳ１２９で転送したリクエストに対するレスポンスを受け付けると、このレスポンスに含まれるステータスコードが他のワーカー仮想マシンに存在することを示す特別な値、即ち「900」であるか否かを判定する（ステップＳ１３９）。ステータスコードが特別な値でない場合（本処理では「200」）、リクエスト転送部２６は、受け付けたレスポンスを、アプリケーション管理部２５を介してレスポンス送信部２４に送信する（ステップＳ１４０、Ｓ１４１）。次いで、レスポンス送信部２４は、アプリケーション管理部２５から受け付けたレスポンスをＨＴＴＰクライアント１００に送信する（ステップＳ１４２）。

なお、リクエストされたＷｅｂアプリケーションがいずれの仮想マシンにも存在しないような場合も想定される。そこで、図９を参照して、クライアント装置１１のＨＴＴＰクライアント１００から送信されたリクエスト（GET /url/app4.cgi HTTP/1.1）が、各仮想マシンのいずれのＷｅｂアプリケーションにも対応しない場合の処理の流れについて説明する。なお、リクエストで指定される“app4.cgi”は、Ｗｅｂアプリケーション２２ａ〜２２ｃ、３２ａ、３２ｂ、４２ａ、４２ｂの何れにも対応しないものとする。

クライアント装置１１のＨＴＴＰクライアント１００から、「GET /url/app4.cgi HTTP/1.1」を含んだリクエストが送信されると（ステップＳ１５１）、上記と同様に、マスター仮想マシン２０のリクエスト受信部２３は、そのリクエストを受信し、その内容を解釈する（ステップＳ１５２）。そして、リクエスト受信部２３は、このリクエストをどのＷｅｂアプリケーションに振り分けるかを決定するため、アプリケーション管理部２５に引き渡す（ステップＳ１５３）。

アプリケーション管理部２５は、対応テーブルを参照し、リクエスト受信部２３から受け付けたリクエストに含まれるＵＲＬに対応するＷｅｂアプリケーションを探索する（ステップＳ１５４）。この場合、ＵＲＬに対応するＷｅｂアプリケーションはマスター仮想マシン２０上では見つからない。そのため、アプリケーション管理部２５は、リクエスト転送部２６に対し、ワーカー仮想マシン３０上で動作するワーカーＨＴＴＰサーバ３１またはワーカーＨＴＴＰサーバ４１へリクエストを転送するよう依頼する（ステップＳ１５５）。

リクエスト転送部２６は、アプリケーション管理部２５から転送の依頼を受け付けると、ワーカー仮想マシン３０又は４０が開いた内部ポートのポート番号に対してリクエストを転送する（ステップＳ１５６）。この場合もアプリケーション管理部２５に登録されたＵＲＬが同じであることから、リクエスト転送部２６は、予め設定された優先順位等に基づいて２つのワーカー仮想マシン３０、４０のどちらかへリクエストを転送する。また、後に残りの仮想マシンへリクエストを再送する可能性があるため、リクエスト転送部２６は、受け付けたリクエストをリクエスト保存部２７に送信することで（ステップＳ１５７）、このリクエストをリクエスト保存部２７に一時的に保存する。

ステップＳ１５６において、ワーカー仮想マシン３０の優先順位がワーカー仮想マシン４０よりも上位であった場合、リクエスト転送部２６は、まず、ワーカー仮想マシン３０の内部ポートのポート番号に対してリクエストを転送する。ワーカー仮想マシン３０では、ワーカーＨＴＴＰサーバ３１のリクエスト受信部３３がリクエストを受け付けると、リクエスト受信部２３と同様に解釈した後（ステップＳ１５８）、このリクエストをどのＷｅｂアプリケーションに振り分けるかを決定するため、アプリケーション管理部３５に引き渡す（ステップＳ１５９）。

アプリケーション管理部３５は、対応テーブルを参照し、リクエスト受信部３３から受け付けたリクエストに含まれるＵＲＬに対応するＷｅｂアプリケーションを探索する（ステップＳ１６０）。しかしながら、ワーカー仮想マシン３０上で動作するＷｅｂアプリケーション３２ａ、３２ｂの中には、リクエストされたＵＲＬに対応するＷｅｂアプリケーションは含まれていない。そこで、アプリケーション管理部３５は、Ｗｅｂアプリケーション３２ａを介し、他のワーカー仮想マシン４０にリクエストされたＵＲＬに対応するＷｅｂアプリケーションが存在するか否かを、ＲＰＣ（ＶＭ間通信）を使用して問い合わせる（ステップＳ１６１、Ｓ１６２）。なお、ここではＷｅｂアプリケーション３２ａを介して問い合わせを行う態様としたが、これに限らず、ワーカー仮想マシン３０上で動作する他のＷｅｂアプリケーション（３２ｂ）を介して問い合わせを行う態様としてもよい。

一方、問い合わせを受け付けたワーカー仮想マシン４０のＷｅｂアプリケーション４２ａ（４２ｂ）では、リクエストされたＵＲＬに対応するＷｅｂアプリケーションが自身に該当するか否かを判定する（ステップＳ１６３）。なお、本処理の場合、リクエストされたＵＲＬに該当するＷｅｂアプリケーションは存在しないため、Ｗｅｂアプリケーション４２ａ（４２ｂ）は、リクエストされたＵＲＬに該当しないことを指示するレスポンス（ＦＡＬＳＥ）を、問い合わせを行ったＷｅｂアプリケーション３２ａに通知する（ステップＳ１６４）。

Ｗｅｂアプリケーション３２ａでは、問い合わせを行ったワーカー仮想マシン４０の全てのＷｅｂアプリケーション（４２ａ、４２ｂ）からレスポンス（ＦＡＬＳＥ）の通知を受けると、リクエストされたＵＲＬに対応するＷｅｂアプリケーションが存在しないことを示したレスポンスをアプリケーション管理部３５に返す（ステップＳ１６５）。アプリケーション管理部３５では、Ｗｅｂアプリケーション３２ａからレスポンスを受け付けると、このレスポンスをレスポンス送信部３４に送信する（ステップＳ１６６）。レスポンス送信部３４は、アプリケーション管理部３５から受け付けたレスポンス（ＦＡＬＳＥ）に応じて、ＨＴＴＰプロトコルにて存在不明を表すステータスコード「404」を、マスター仮想マシン２０のリクエスト転送部２６にリクエスト転送部２６に送信する（ステップＳ１６７）。

リクエスト転送部２６は、ワーカー仮想マシン３０からステータスコードを受け付けると、このステータスコードが他のワーカー仮想マシンに存在することを示す特別な値、即ち、「900」であるか否かを判定する（ステップＳ１６８）。ステータスコードが特別な値でない場合（本処理では「404」）、リクエスト転送部２６は、受け付けたレスポンスを、アプリケーション管理部２５を介してレスポンス送信部２４に送信する（ステップＳ１６９、Ｓ１７０）。次いで、レスポンス送信部２４は、受け付けたレスポンスをＨＴＴＰクライアント１００に送信する（ステップＳ１７１）。

このように、マスターＨＴＴＰサーバ２１のリクエスト転送部２６は、リクエストを転送したワーカーＨＴＴＰサーバから、当該リクエストに対応するアプリケーションを有していないとのレスポンスを受信した場合、次の優先順位のワーカーＨＴＴＰサーバへリクエストを転送せず、対応するアプリケーションが存在しない旨のレスポンスをクライアントへ送信する。これにより、他の仮想マシンへ無駄にリクエストを転送することを防止することができ、Ｗｅｂブラウザへの応答を速くすることができる。

以上のように、本実施形態によれば、マスターＨＴＴＰサーバ２１では、対応テーブルと、ＨＴＴＰクライアント１００から受信したリクエストに含まれるＵＲＬ（アドレス情報）とに基づいて、このリクエストを処理すべき仮想マシンを判別し、当該仮想マシンへ前記リクエストを転送する。これにより、複数の仮想マシンが動作する環境にその開発したＷｅｂアプリケーションを追加しても、ＨＴＴＰクライアント１００から受信したリクエストを適切に各仮想マシン上で動作するアプリケーションに振り分けることができる。

また、クライアント側では、ＨＴＴＰサーバにアクセスするのみで、複数のワーカーＨＴＴＰサーバが提供するＷｅｂアプリケーションによるサービスを利用することができる。したがって、クライアントは、複数のＨＴＴＰサーバが動作していることを意識することなくサービスを利用することができる。

これまで本発明を上述した実施の形態をもって説明してきたが、本発明は上述した実施の形態に限定されるものではなく、他の実施の形態、追加、変更、削除など、当業者が想到することができる範囲内で変更することができ、いずれの態様においても本発明の作用・効果を奏する限り、本発明の範囲に含まれるものである。

したがって、上記の処理をプログラムとして構成し、サーバ装置にそのプログラムを実行させることにより実現することもできる。これは、コンピュータ可読なプログラムとして、そのプログラムを格納したＣＤ−ＲＯＭやメモリカード等の記録媒体として提供することもできる。

本発明の情報処理装置の一実施形態としてサーバ装置を含むネットワーク機器の構成例を示した図である。 情報処理装置のモジュール構成を示した図である。 ＨＴＴＰサーバの構成を示した図である。 マスターＨＴＴＰサーバへのＷｅｂアプリケーションの登録およびリクエスト処理の流れを示したシーケンス図である。 マスター仮想マシン上に対応するＷｅｂアプリケーションが見つからない場合の処理の流れを示したシーケンス図である。 ワーカーＨＴＴＰサーバへのＷｅｂアプリケーションの登録およびリクエスト処理の流れを示したシーケンス図である。 同一ＵＲＬのＷｅｂアプリケーションを登録する処理およびリクエスト処理の流れを示したシーケンス図である。 第１のワーカー仮想マシン上に対応するＷｅｂアプリケーションが見つからず、第２のワーカー仮想マシン上に対応するＷｅｂアプリケーションが見つかった場合のリクエスト処理の流れを示したシーケンス図である。 いずれの仮想マシン上にも、対応するＷｅｂアプリケーションが存在しない場合のリクエスト処理の流れを示したシーケンス図である。

符号の説明

１０ サーバ装置
１１ クライアント装置
１２ ネットワーク
２０、３０、４０ 仮想マシン
２１、３１、４１ ＨＴＴＰサーバ
２２ａ、２２ｂ、２２ｃ、３２ａ、３２ｂ、４２ａ、４２ｂ Ｗｅｂアプリケーション
２３、３３、４３ リクエスト受信部
２４、３４、４４ レスポンス送信部
２５、３５、４５ アプリケーション管理部
２６ リクエスト転送部
２７ リクエスト保存部
２８ 仮想マシン制御部

Claims (17)

1. 複数の仮想マシンが動作する情報処理装置であって、
   各前記仮想マシンが、少なくとも１つのアプリケーションをアドレス情報と対応付けて管理情報として保持し、前記管理情報とクライアントから受信したリクエストに含まれるアドレス情報とから、前記リクエストを処理するアプリケーションを判別するアプリケーション管理部を含み、
   前記複数の仮想マシンの１つが、さらに、他の前記仮想マシンの前記アプリケーション管理部が保持する前記管理情報と前記他の仮想マシンを識別するための識別情報とをそれぞれ対応付けて保持し、前記他の仮想マシン上で動作するアプリケーションのアドレス情報を含むリクエストを前記クライアントから受信した場合に、前記管理情報および前記識別情報と、受信した前記リクエストに含まれるアドレス情報とから、前記リクエストを受信すべき前記他の仮想マシンを判別し、前記他の仮想マシンへ前記リクエストを転送するリクエスト転送部を備える情報処理装置。
2. 前記仮想マシンは、前記仮想マシン上で動作するＨＴＴＰサーバと、前記少なくとも１つのアプリケーションとを含み、
   前記ＨＴＴＰサーバが、前記アプリケーション管理部と、前記リクエストを受信し、前記リクエストから前記アドレス情報を抽出するリクエスト受信部と、前記アプリケーション管理部により判別された前記アプリケーションによる処理結果をレスポンスとして送信するリクエスト送信部とを含み、
   前記複数の仮想マシンの１つに含まれるＨＴＴＰサーバが、前記リクエストを転送する前記リクエスト転送部をさらに備えるマスターＨＴＴＰサーバとされ、前記他の仮想マシンに含まれるＨＴＴＰサーバが、転送された前記リクエストを処理し、処理結果を送信するワーカーＨＴＴＰサーバとされる請求項１に記載の情報処理装置。
3. 前記マスターＨＴＴＰサーバは、前記ワーカーＨＴＴＰサーバへＨＴＴＰを用いて前記リクエストを転送する請求項２に記載の情報処理装置。
4. 前記マスターＨＴＴＰサーバは、前記情報処理装置の外部と通信を行うために外部ポートを使用し、前記ワーカーＨＴＴＰサーバは、前記情報処理装置の内部で前記マスターＨＴＴＰサーバと通信を行うために内部ポートと、前記情報処理装置自身を識別するループバックアドレスとを使用して、前記リクエストを受信し、前記リクエストに対する処理結果を送信する請求項３に記載の情報処理装置。
5. 前記ワーカーＨＴＴＰサーバは、リモートプロシージャコールを使用して、前記マスターＨＴＴＰサーバの前記リクエスト転送部に登録すべきアプリケーションのＵＲＬをアドレス情報として取得させ、前記マスターＨＴＴＰサーバの前記アプリケーション管理部に前記ＵＲＬを前記アプリケーションと対応付けて管理情報として保持させる、請求項２〜４のいずれか１項に記載の情報処理装置。
6. 前記マスターＨＴＴＰサーバの前記リクエスト転送部は、複数の前記ワーカーＨＴＴＰサーバから同一の前記ＵＲＬを取得し、前記同一のＵＲＬを前記管理情報として保持する請求項５に記載の情報処理装置。
7. 前記マスターＨＴＴＰサーバは、前記クライアントから受信した前記リクエストを保存するリクエスト保存部と、複数の前記ワーカーＨＴＴＰサーバへリクエストを転送する優先順位に関する優先度情報を保存する仮想マシン制御部とをさらに含む請求項６に記載の情報処理装置。
8. 前記マスターＨＴＴＰサーバの前記リクエスト転送部は、前記リクエストを転送した前記ワーカーＨＴＴＰサーバから、他の前記ワーカーＨＴＴＰサーバが対応するアプリケーションを有しているとのレスポンスを受信した場合にのみ、次の優先順位の前記ワーカーＨＴＴＰサーバへ前記リクエストを転送し、前記対応するアプリケーションを有していないとのレスポンスを受信した場合には、前記次の優先順位の前記ワーカーＨＴＴＰサーバへ前記リクエストを転送せず、前記対応するアプリケーションが存在しない旨のレスポンスを前記クライアントへ送信し、
   前記リクエストが転送された前記ワーカーＨＴＴＰサーバは、前記他のワーカーＨＴＴＰサーバが前記対応するアプリケーションを有するか否かを調査するアプリケーション調査部を含み、前記アプリケーション調査部が、前記他のワーカーＨＴＴＰサーバが前記対応するアプリケーションを有することを検出した場合には、前記対応するアプリケーションが存在する旨のレスポンスを送信し、検出しない場合には、前記対応するアプリケーションが存在しない旨のレスポンスを送信する請求項７に記載の情報処理装置。
9. 複数の仮想マシンが動作する情報処理装置で実行される情報処理方法であって、
   各前記仮想マシンが、少なくとも１つのアプリケーションをアドレス情報と対応付けて管理情報として保持し、前記複数の仮想マシンの１つであるマスター仮想マシンが、さらに、他の仮想マシンであるワーカー仮想マシンが保持する前記管理情報と前記ワーカー仮想マシンを識別するための識別情報とをそれぞれ対応付けて保持し、
   前記ワーカー仮想マシン上で動作するアプリケーションのアドレス情報を含むリクエストを前記クライアントから受信した場合に、前記マスター仮想マシンが保持する前記管理情報および前記識別情報と、受信した前記リクエストに含まれるアドレス情報とから、前記リクエストを受信すべき前記ワーカー仮想マシンを判別し、前記ワーカー仮想マシンへ前記リクエストを転送するステップと、
   前記ワーカー仮想マシンにおいて、当該ワーカー仮想マシンが保持する前記管理情報とクライアントから受信したリクエストに含まれるアドレス情報とから、前記リクエストを処理するアプリケーションを判別するステップと、
   判別された前記アプリケーションを使用して前記リクエストを処理するステップと、
   処理結果を前記マスター仮想マシンへ送信するステップと、
   を含む情報処理方法。
10. 前記転送するステップでは、前記マスター仮想マシンから前記ワーカー仮想マシンへＨＴＴＰを用いて前記リクエストを転送する請求項９に記載の情報処理方法。
11. 前記ワーカー仮想マシンがリモートプロシージャコールを使用して前記マスター仮想マシンに登録すべきアプリケーションのＵＲＬをアドレス情報として取得するステップと、
    前記マスター仮想マシンが前記ＵＲＬを前記アプリケーションと対応付けて管理情報として保持するステップとを含む請求項９または１０に記載の情報処理方法。
12. 前記マスター仮想マシンが複数の前記ワーカー仮想マシンから同一の前記ＵＲＬを取得し、前記同一のＵＲＬを前記管理情報として保持するステップをさらに含む請求項１１に記載の情報処理方法。
13. 前記転送するステップでは、前記マスター仮想マシンから最も高い優先順位の前記ワーカー仮想マシンへ前記リクエストを転送する請求項１２に記載の情報処理方法。
14. 前記転送するステップでは、前記マスター仮想マシンが前記リクエストを転送した前記ワーカー仮想マシンから他の前記ワーカー仮想マシンが対応するアプリケーションを有しているとのレスポンスを受信した場合にのみ、次の優先順位のワーカー仮想マシンへ前記リクエストを転送する請求項１３に記載の情報処理方法。
15. 前記他のワーカー仮想マシンが前記対応するアプリケーションを有していないとのレスポンスを受信した場合には、前記次の優先順位の前記ワーカー仮想マシンへ前記リクエストを転送せず、前記対応するアプリケーションが存在しない旨のレスポンスを前記クライアントへ送信するステップをさらに含む請求項１４に記載の情報処理方法。
16. 前記他のワーカー仮想マシンが前記対応するアプリケーションを有するか否かを調査するステップと、前記他のワーカー仮想マシンが前記対応するアプリケーションを有することを検出した場合には、前記対応するアプリケーションが存在する旨のレスポンスを送信するステップと、検出しない場合には、前記対応するアプリケーションが存在しない旨のレスポンスを送信するステップとを含む請求項９に記載の情報処理方法。
17. 複数の仮想マシンが動作する情報処理装置により読み取り可能な、クライアントからのリクエストを処理するためのプログラムであって、
    各前記仮想マシンが、少なくとも１つのアプリケーションをアドレス情報と対応付けて管理情報として保持し、前記複数の仮想マシンの１つであるマスター仮想マシンが、さらに、他の仮想マシンであるワーカー仮想マシンが保持する前記管理情報と前記ワーカー仮想マシンを識別するための識別情報とをそれぞれ対応付けて保持していて、
    前記プログラムが、
    前記ワーカー仮想マシン上で動作するアプリケーションのアドレス情報を含むリクエストを前記クライアントから受信した場合に、前記マスター仮想マシンが保持する前記管理情報および前記識別情報と、受信した前記リクエストに含まれるアドレス情報とから、前記リクエストを受信すべき前記ワーカー仮想マシンを判別し、前記ワーカー仮想マシンへ前記リクエストを転送するステップと、
    前記ワーカー仮想マシンにおいて、当該ワーカー仮想マシンが保持する前記管理情報とクライアントから受信したリクエストに含まれるアドレス情報とから、前記リクエストを処理するアプリケーションを判別するステップと、
    判別された前記アプリケーションを使用して前記リクエストを処理するステップと、
    処理結果を前記マスター仮想マシンへ送信するステップと、
    を前記情報処理装置に実行させるプログラム。

Images