(57)【要約】【課題】ウェブアプリケーションが複数実行していても、ウェブアプリケーションからのデータ要求がどのユーザリクエストに基づくウェブアプリケーションからの要求であるのかを判定できる。【解決手段】リクエスト処理プログラムは、ウェブサーバ１に、クライアントから送信されたリクエストに含まれるアプリケーションの宛先ごとに紐付けられたアプリケーションの識別情報と、当該アプリケーションの実行単位情報とを対応付けて記憶部１２に記憶し、実行中のアプリケーションからデータ要求があった場合、データ要求があったアプリケーションの実行単位情報に対応するアプリケーションの識別情報を記憶部１２から検索し、該検索した結果、アプリケーションの識別情報が検索されると、検索されたアプリケーションの識別情報と紐づくリクエストに関わるデータ要求の制御を実行する処理を実行させる。【選択図】図８
2013003598.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータに、
クライアントから送信されたリクエストに含まれるアプリケーションの宛先ごとに紐付けられたアプリケーションの識別情報と、当該アプリケーションの実行単位情報とを対応付けて記憶部に記憶し、
実行中のアプリケーションからデータ要求があった場合、データ要求があったアプリケーションの実行単位情報に対応するアプリケーションの識別情報を前記記憶部から検索し、
該検索した結果、アプリケーションの識別情報が検索されると、検索されたアプリケーションの識別情報と紐づくリクエストに関わるデータ要求の制御を実行する
処理を実行させることを特徴とするリクエスト処理プログラム。
【請求項２】
前記コンピュータに、
前記検索する処理において、前記データ要求があったアプリケーションの実行単位情報をＯＳ（Operating  System）に問い合わせ、問い合わせた結果得られた実行単位情報に対応するアプリケーションの識別情報を前記記憶部から検索する
処理を実行させることを特徴とする請求項１に記載のリクエスト処理プログラム。
【請求項３】
前記コンピュータに、
新たなリクエストに含まれるアプリケーションの宛先に紐付けられたアプリケーションの識別情報が前記記憶部に記憶されていない場合、キューを用いて、当該リクエストに含まれるアプリケーションの起動開始から起動完了までの処理を待ち、
当該アプリケーションから起動完了が通知されると、当該アプリケーションの実行単位情報をＯＳに問い合わせ、問い合わせた結果得られた実行単位情報を当該アプリケーションの識別情報と対応付けて前記記憶部に記憶する
処理を実行させることを特徴とする請求項１または請求項２に記載のリクエスト処理プログラム。
【請求項４】
クライアントから送信されたリクエストに含まれるアプリケーションの宛先ごとに紐付けられたアプリケーションの識別情報と、当該アプリケーションの実行情報とを対応付けて記憶する記憶部と、
実行中のアプリケーションからのデータ要求があった場合、データ要求があったアプリケーションの実行情報に対応するアプリケーションの識別情報を前記記憶部から検索する検索部と、
前記検索部によってアプリケーションの識別情報が検索されると、検索されたアプリケーションの識別情報と紐づくリクエストに関わるデータ要求の制御を実行する実行部と
を有することを特徴とする情報処理装置。
【請求項５】
コンピュータが、
クライアントから送信されたリクエストに含まれるアプリケーションの宛先ごとに紐付けられたアプリケーションの識別情報と、当該アプリケーションの実行単位情報とを対応付けて記憶部に記憶し、
実行中のアプリケーションからデータ要求があった場合、データ要求があったアプリケーションの実行単位情報に対応するアプリケーションの識別情報を前記記憶部から検索し、
該検索した結果、アプリケーションの識別情報が検索されると、検索されたアプリケーションの識別情報と紐づくリクエストに関わるデータ要求の制御を実行する
ことを特徴とするリクエスト処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、リクエスト処理プログラムなどに関する。
【背景技術】
【０００２】
近年、インターネットを経由して必要な機能をサービスとして利用するＳａａＳ（Software  as  a  Service）と呼ばれる形態が普及しつつある。サービスとして利用される機能には、ウェブサービスとしてインターネットで提供されるアプリケーション（以降、「ウェブアプリケーション」という。）が含まれる。ウェブアプリケーションのほとんどは、ユーザからのリクエストについて、ＨＴＴＰ（Hyper  Text  Transfer  Protocol）プロトコルでデータをやりとりするので、ＵＲＬ（Uniform  Resource  Locator）を用いたデータのアクセス制御を必要とする。このため、ウェブアプリケーションは、盗聴やなりすましなどの安全性の面で利用が限られる場合がある。特に、企業の経営戦略に関するような企業秘密とされるデータには、たとえ暗号化してもインターネットに公開できない場合もある。
【０００３】
つまり、ＨＴＴＰプロトコルでデータをやりとりするウェブアプリケーションでは、データのアクセス制限をホスト（ドメイン）単位で指定できるが、データやファイル単位で指定できない。また、ＨＴＴＰプロトコルの下位レイヤのＯＳ（Operating  System）では、プロトコル単位のポートの開閉（ＨＴＴＰプロトコルのデータを通すか否か）を制御できるが、個別のデータやファイル単位でポートの開閉を制御できない。
【０００４】
ところで、ホストの例として通信元装置で実行しているアプリケーションを通信先装置で特定する技術がある。かかる技術では、通信先装置と通信を行う通信元装置が通信先装置に対する通信に関する通信元端末の情報を、汎用通信路を介して通信先装置に送信する。そして、通信元装置は、通信に関する通信元装置の情報と通信元装置上で通信を実行している通信元のアプリケーションの情報とを、汎用通信路以外の専用通信路を介して通信先装置に送信する。これにより、通信先装置は、通信末装置（ホスト）で実行しているアプリケーションを特定することができる。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】国際公開第２００８／０７５５８０号
【発明の概要】
【発明が解決しようとする課題】
【０００６】
ここで、ＨＴＴＰプロトコルでデータをやりとりするウェブアプリケーションが同一ホスト上で複数動作している場合がある。かかる場合に、ウェブアプリケーションからデータ要求を依頼された通信先装置では、データ要求がどのユーザリクエストに基づくウェブアプリケーションからの要求であるのかを判定できないという問題があった。
【０００７】
すなわち、データ要求を依頼された通信先装置は、空いているポート番号がホストのＯＳにより割り付けられたデータ要求のリクエストを受け取る。このため、データ要求のリクエストを受け取った通信先装置は、データ要求がどのユーザリクエストに基づくウェブアプリケーションからの要求であるのかを判定できない。
【０００８】
また、ホストで実行しているウェブアプリケーションを通信先装置で特定する技術であっても、ウェブアプリケーションがホストで複数動作している場合、通信先装置は、ホストで実行しているウェブアプリケーションを特定できるに留まる。すなわち、通信先装置は、ウェブアプリケーションからのデータ要求のリクエストを受け取った場合、データ要求がどのユーザリクエストに基づくウェブアプリケーションからの要求であるかを判定できない。
【０００９】
なお、上記課題は、ＨＴＴＰプロトコルでデータをやりとりするウェブアプリケーションに限らず、データのアクセス制限をホスト（ドメイン）単位でしか指定できないプロトコルでデータをやりとりするウェブアプリケーションでも同様に生ずる。
【００１０】
開示の技術は、ウェブアプリケーションが複数実行していても、ウェブアプリケーションからのデータ要求がどのユーザリクエストに基づくウェブアプリケーションからの要求であるのかを判定できることを目的とする。
【課題を解決するための手段】
【００１１】
１つの側面では、リクエスト処理プログラムは、コンピュータに、クライアントから送信されたリクエストに含まれるアプリケーションの宛先ごとに紐付けられたアプリケーションの識別情報と、当該アプリケーションの実行単位情報とを対応付けて記憶部に記憶し、実行中のアプリケーションからデータ要求があった場合、データ要求があったアプリケーションの実行単位情報に対応するアプリケーションの識別情報を前記記憶部から検索し、該検索の結果、アプリケーションの識別情報が検索されると、検索されたアプリケーションの識別情報と紐づくリクエストに関わるデータ要求の制御を実行する処理を実行させる。
【発明の効果】
【００１２】
本願の開示するリクエスト処理プログラムの一つの態様によれば、ウェブアプリケーションが複数実行していても、ウェブアプリケーションからのデータ要求がどのユーザリクエストに基づくウェブアプリケーションからの要求であるのかを判定できる。
【図面の簡単な説明】
【００１３】
【図１】図１は、実施例１に係るウェブサーバの構成を示す機能ブロック図である。
【図２】図２は、実施例２に係る中継サーバの構成を示す機能ブロック図である。
【図３】図３は、データ管理テーブルのデータ構造の一例を示す図である。
【図４】図４は、アプリ管理テーブルのデータ構造の一例を示す図である。
【図５】図５は、実施例２に係るウェブサーバの構成を示す機能ブロック図である。
【図６】図６は、アプリ管理テーブルのデータ構造の一例を示す図である。
【図７】図７は、中継サーバにおけるアプリ起動依頼の手順を示すフローチャートである。
【図８】図８は、ウェブサーバにおけるリクエスト処理の手順を示すフローチャートである。
【図９】図９は、中継サーバにおけるアプリ実行依頼の手順を示すフローチャートである。
【図１０】図１０は、中継サーバにおけるデータへのアクセス処理の手順を示すフローチャートである。
【図１１】図１１は、実施例２に係るリクエスト処理のうちアプリケーション起動処理のシーケンス図である。
【図１２】図１２は、実施例２に係るリクエスト処理のうちアプリケーション実行処理のシーケンス図である。
【図１３】図１３は、ウェブクライアントから中継サーバへのユーザリクエストの内容の一例を示す図である。
【図１４】図１４は、中継サーバからサンドボックスへのアプリ起動依頼の内容の一例を示す図である。
【図１５】図１５は、サンドボックスから中継サーバへの起動完了の内容の一例を示す図である。
【図１６】図１６は、中継サーバからサンドボックスへのアプリ実行依頼の内容の一例を示す図である。
【図１７】図１７は、ウェブアプリケーションから中継サーバへのデータ要求の内容の一例を示す図である。
【図１８】図１８は、中継サーバから社内記憶装置へのデータ要求の内容の一例を示す図である。
【図１９】図１９は、実施例３に係る中継サーバの構成を示す機能ブロック図である。
【図２０】図２０は、実施例３に係るリクエスト処理のうちアプリケーション起動処理のシーケンス図である。
【図２１】図２１は、実施例３に係るリクエスト処理のうちアプリケーション実行処理のシーケンス図である。
【図２２】図２２は、リクエスト処理プログラムを実行するコンピュータを示す図である。
【発明を実施するための形態】
【００１４】
以下に、本願の開示するリクエスト処理プログラム、リクエスト処理方法および情報処理装置の実施例を図面に基づいて詳細に説明する。なお、実施例によりこの発明が限定されるものではない。
【実施例１】
【００１５】
図１は、実施例１に係るウェブサーバの構成を示す機能ブロック図である。図１に示すように、ウェブサーバ１と接続する中継サーバ２は、ウェブサーバ１、ウェブクライアント３および社内記憶装置６と接続し、インターネット５を介して外部ウェブサーバ４と接続する。中継サーバ２がウェブサーバ１、ウェブクライアント３および社内記憶装置６とインターネット５を介さないで接続する形態は、例えば社内ＬＡＮ（Local  Area  Network）であったり、社内におけるイントラネットであったりする。
【００１６】
ウェブサーバ１は、ウェブサービスとしてインターネット５で提供されるウェブアプリケーションを実施するウェブサーバであって中継サーバ２の管理内のウェブサーバを意味する。中継サーバ２は、外部ウェブサーバ４またはウェブサーバ１と、ウェブクライアント３と、社内記憶装置６との間でデータを中継する。ウェブクライアント３は、ウェブサービスを利用するリクエストを中継サーバ２に送信する、例えばパーソナルコンピュータを示す。外部ウェブサーバ４は、ウェブサービスとしてウェブアプリケーションを実施し、中継サーバ２の管理外のウェブサーバを意味する。外部ウェブサーバ４は、例えば、ＳａａＳ（Software  as  a  Service）を取り入れたウェブサーバであったり、クラウド環境下のウェブサーバであったりする。このような外部ウェブサーバ４のウェブアプリケーションをダウンロードして実施できる環境であって中継サーバ２の管理内で整備された環境を、オンプレミス環境というものとする。これに対し、中継サーバ２の管理外にある外部ウェブサーバ４でウェブアプリケーションを実施できる環境を、オフプレミス環境というものとする。社内記憶装置６は、公開に制限があるデータや公開に制限がないデータを記憶する。例えば、公開に制限があるデータとは、社外秘データなどの機密データを指す。
【００１７】
ウェブサーバ１は、サンドボックス１１を含み、記憶部１２、検索部１３および実行部１４を有する。サンドボックス１１とは、外部ウェブサーバ４から受け取ったウェブアプリケーションを保護された領域で動作させることによってシステムが不正に操作されるのを防ぐセキュリティモデルのことを指す。起動されたウェブアプリケーションは保護された領域に入り、他のウェブアプリケーションやデータなどを操作できない状態にされて動作する。このため、サンドボックス１１上のウェブアプリケーションが暴走したりウイルスを動作させたりしようとしても、システムに影響が及ばないようにできる。
【００１８】
中継サーバ２は、例えば、社内記憶装置６に格納されるデータごとにデータの公開に制限がある旨のポリシーや公開に制限がない旨のポリシーを、データごとに記憶する。そして、中継サーバ２は、ウェブクライアント３からＨＴＴＰリクエストを受信すると、受信したＨＴＴＰリクエストに含まれるアクセス対象のデータについて、社内記憶装置６に記憶されたデータの公開ポリシーを参照する。そして、中継サーバ２は、ＨＴＴＰリクエストに含まれるアクセス対象のデータの公開に制限がある場合には、ＨＴＴＰリクエストをオンプレミス環境のウェブサーバ１に転送する。
【００１９】
ここで、ウェブサーバ１の記憶部１２は、ウェブクライアント３から送信されたＨＴＴＰリクエストに含まれるウェブアプリケーションの宛先ごとに紐付けられたウェブアプリケーションの識別情報と、当該ウェブアプリケーションの実行単位情報とを対応付けて記憶する。そして、ウェブサーバ１は、中継サーバ２からＨＴＴＰリクエストを受信し、受信したＨＴＴＰリクエストをサンドボックス１１に配置されたウェブアプリケーションを用いて実行する。
【００２０】
仮に、実行中のウェブアプリケーションからアクセス対象のデータについてデータ要求があったとする。すると、ウェブサーバ１の検索部１３は、データ要求があったウェブアプリケーションの実行単位情報に対応するウェブアプリケーションの識別情報を記憶部１２から検索する。
【００２１】
そして、ウェブサーバ１の実行部１４は、検索の結果、ウェブアプリケーションの識別情報が検索されると、検索されたウェブアプリケーションの識別情報と紐づく、ウェブクライアント３から送信されたＨＴＴＰリクエストに関わるデータ要求の制御を実行する。
【００２２】
そして、ウェブサーバ１は、アクセス対象のデータを、中継サーバ２を介して社内記憶装置６から取り込む。さらに、ウェブサーバ１は、取り込んだデータを用いてウェブアプリケーションをサンドボックス１１内で安全に実施し、公開に制限があるデータに対応する処理結果を、中継サーバ２を介してウェブクライアント３に通知することとなる。
【００２３】
一方、中継サーバ２は、ＨＴＴＰリクエストに含まれるアクセス対象のデータの公開に制限がない場合には、ＨＴＴＰリクエストをオフプレミス環境の外部ウェブサーバ４に転送する。そして、外部ウェブサーバ４は、ＨＴＴＰリクエストを受信し、受信したＨＴＴＰリクエストに応じて自装置内のウェブアプリケーションを実施すべく、アクセス対象のデータを、中継サーバ２を介して社内記憶装置６から取り込む。そして、外部ウェブサーバ４は、取り込んだデータを用いてウェブアプリケーションを実施し、公開に制限がないデータに対応する処理結果を、中継サーバ２を介してウェブクライアント３に通知することとなる。
【００２４】
このようにして、ウェブサーバ１は、オンプレミス環境において、実行中のウェブアプリケーションからアクセス対象のデータについてデータ要求があった場合、記憶部１２からウェブアプリケーションの実行単位情報に対応する識別情報を検索する。ここで、ウェブサーバ１は、ウェブアプリケーションの識別情報が検索されると、検索されたウェブアプリケーションの識別情報とウェブクライアント３からのＨＴＴＰリクエストとが紐づくこととなる。この結果、ウェブサーバ１は、サンドボックス１１にウェブアプリケーションが複数実行していても、ウェブアプリケーションからのデータ要求がどのＨＴＴＰリクエストに基づくウェブアプリケーションからの要求であるのかを判定できる。
【００２５】
また、中継サーバ２は、ＨＴＴＰリクエストに含まれるアクセス対象のデータの公開ポリシーに基づいて、オフプレミス環境およびオンプレミス環境のいずれのウェブサーバにＨＴＴＰリクエストを転送するかを選択的に決定できる。このため、中継サーバ２は、公開に制限がある、アクセス対象のデータについて、オンプレミス環境のウェブサーバ１にＨＴＴＰリクエストを転送できるので、当該アクセス対象のデータのオフプレミス環境への流出を防止できる。一方、中継サーバ２は、公開に制限がない、アクセス対象のデータについては、オフプレミス環境の外部ウェブサーバ４にＨＴＴＰリクエストを転送できるので、オフプレミス環境も合わせて使用しながら公開に制限があるデータの流出を防止できる。
【実施例２】
【００２６】
［実施例２に係る中継サーバの構成］
図２は、実施例２に係る中継サーバの構成を示す機能ブロック図である。図２に示すように、中継サーバ２Ａは、ウェブクライアント３、ウェブサーバ１Ａおよび社内記憶装置６と接続する。また、中継サーバ２Ａは、図示しないが、インターネット５を介して外部ウェブサーバ４と接続する。中継サーバ２Ａがウェブクライアント３、ウェブサーバ１Ａおよび社内記憶装置６とインターネット５を介さないで接続する形態は、例えば社内ＬＡＮ（Local  Area  Network）であったり、社内におけるイントラネットであったりする。
【００２７】
また、ウェブサーバ１Ａは、オンプレミス環境のウェブサーバであって中継サーバ２Ａの管理内のウェブサーバを意味する。また、外部ウェブサーバ４は、オフプレミス環境のウェブサーバであって中継サーバ２Ａの管理外のウェブサーバを意味する。外部ウェブサーバ４は、例えばクラウド環境のウェブサーバを指すものとする。社内記憶装置６は、オンプレミス環境およびオフプレミス環境のウェブアプリケーションで使用されるデータを記憶する。そして、社内記憶装置６には、例えば外部ウェブサーバ４に公開できない社外秘のデータおよび外部ウェブサーバ４に公開できる公開可能なデータを含む。なお、社内記憶装置６に、外部ウェブサーバ４にもウェブサーバ１Ａにも公開できないデータを含むものとしても良い。
【００２８】
中継サーバ２Ａは、制御部および記憶部を有する。なお、中継サーバ２Ａは、実施例１の中継サーバ２の一例である。制御部は、ＨＴＴＰリクエストを制御するリクエスト受付部２１、リクエスト解析部２２、振分部２３、アプリＩＤ登録部２４、リクエスト転送部２５、レスポンス受付部２６およびレスポンス解析部２７を有する。また、制御部は、ＵＲＬ書換部２８、アプリＩＤ付与部２９、データアクセス判定部３０およびレスポンス転送部３１を有する。また、制御部は、例えば、ＡＳＩＣ（Application  Specific  Integrated  Circuit）やＦＰＧＡ（Field  Programmable  Gate  Array）などの集積回路またはＣＰＵ（Central  Processing  Unit）やＭＰＵ（Micro  Processing  Unit）などの電子回路である。
【００２９】
記憶部は、データ管理テーブル４１およびアプリ管理テーブル４２を有する。記憶部は、例えば、ＲＡＭ（Random  Access  Memory）、フラッシュメモリ（flash  memory）などの半導体メモリ素子、または、ハードディスク、光ディスクなどの記憶装置である。
【００３０】
リクエスト受付部２１は、各種ＨＴＴＰリクエストを受け付け、受け付けたＨＴＴＰリクエストをリクエスト解析部２２に出力する。例えば、リクエスト受付部２１は、ユーザによってウェブクライアント３から送信されたＨＴＴＰリクエスト（以降、「ユーザリクエスト」という。）を受け付け、受け付けたユーザリクエストをリクエスト解析部２２に出力する。このユーザリクエストには、例えば、実行が依頼されるウェブアプリケーションのＵＲＬおよびアクセス対象のデータのＵＲＬが含まれる。
【００３１】
また、リクエスト受付部２１は、後にウェブサーバ１Ａ（サンドボックス１１）または外部ウェブサーバ４のウェブアプリケーションから送信される、ＨＴＴＰリクエストに基づく処理の実行に必要なデータのアクセス要求を示すリクエストを受け付ける。すなわち、ユーザリクエストがオンプレミス環境またはオフプレミス環境のウェブアプリケーションにより処理される場合、ウェブアプリケーションから実行に必要なデータを、中継サーバ２Ａを経由して間接的にアクセスさせる。この説明については後述する。
【００３２】
リクエスト解析部２２は、リクエスト受付部２１によって受け付けられたＨＴＴＰリクエストを解析する。
【００３３】
振分部２３は、リクエスト解析部２２によって解析されたユーザリクエストに含まれる、アクセス対象のデータの公開に係る公開ポリシーに基づいて、ユーザリクエストを振り分けるべきウェブアプリケーションを判断する。具体的には、振分部２３は、リクエスト解析部２２によって解析されたユーザリクエストに含まれるアクセス対象のデータについて後述するデータ管理テーブル４１に記憶された公開ポリシーを参照する。また、振分部２３は、参照した公開ポリシーが例えば社外秘でない場合には、ユーザリクエストを外部ウェブサーバ４のウェブアプリケーションに振り分けるものと判断する。そして、振分部２３は、外部ウェブサーバ４でウェブアプリケーションを実施すべく、外部ウェブサーバ４のウェブアプリケーションを送信先とするＨＴＴＰリクエストをリクエスト転送部２５に出力する。
【００３４】
また、振分部２３は、参照した公開ポリシーが例えば社外秘である場合には、ユーザリクエストをオンプレミス環境のウェブサーバ１Ａに振り分けるものと判断する。そして、振分部２３は、外部ウェブサーバ４からウェブアプリケーションをダウンロードし、ダウンロードしたウェブアプリケーションおよびユーザリクエストをアプリＩＤ登録部２４に出力する。
【００３５】
アプリＩＤ登録部２４は、ユーザリクエストに含まれるウェブアプリケーションのＵＲＬごとに紐付けられるウェブアプリケーションのアプリＩＤ（IDentification）を生成する。また、アプリＩＤ登録部２４は、生成したアプリＩＤおよび振分部２３によって参照されたアクセス対象のデータの識別番号を対応付けて、アプリ管理テーブル４２に登録する。そして、アプリＩＤ登録部２４は、ダウンロードしたウェブアプリケーションを起動させるべく、ウェブサーバ１Ａに対してウェブアプリケーションの起動を依頼するＨＴＴＰリクエストをリクエスト転送部２５に出力する。ＨＴＴＰリクエストには、ウェブアプリケーションのアプリＩＤが付与される。
【００３６】
なお、本実施例では、ウェブアプリケーションをコンパイルしたプログラムやクラスファイルなどを配置して、ウェブクライアント３からウェブアプリケーションを実行可能な状態にすることを「デプロイ」というものとする。すなわち、アプリＩＤ登録部２４がウェブサーバ１Ａに対してウェブアプリケーションの起動を依頼することによって、ウェブサーバ１Ａは当該ウェブアプリケーションをサンドボックス１１にデプロイする。
【００３７】
ここで、データ管理テーブル４１のデータ構造について、図３を参照しながら説明する。図３は、データ管理テーブル４１のデータ構造の一例を示す図である。図３に示すように、データ管理テーブル４１は、データＩＤ４１ａ、社外秘データＵＲＬ４１ｂおよびアプリ名４１ｃを対応付けて記憶する。データＩＤ４１ａは、データの識別番号を示す。社外秘データＵＲＬ４１ｂは、ウェブアプリケーションからのアクセスを許可するデータのうち社外秘データのＵＲＬを示す。すなわち、社外秘データＵＲＬ４１ｂは、社外での公開に制限があるデータのＵＲＬを示している。なお、データ管理テーブル４１は、あらかじめ作成されているものとする。
【００３８】
また、アプリ管理テーブル４２のデータ構造について、図４を参照しながら説明する。図４は、アプリ管理テーブル４２のデータ構造の一例を示す図である。図４に示すように、アプリ管理テーブル４２は、データＩＤ４２ａ、アプリＩＤ４２ｂおよびウェブアプリケーションデプロイ場所ＵＲＬ４２ｃを対応付けて記憶する。データＩＤ４２ａは、ウェブアプリケーションからアクセスするデータの識別番号を示し、データ管理テーブル４１のデータＩＤ４１ａと対応付けられる。アプリＩＤ４２ｂは、ユーザリクエストに含まれるウェブアプリケーションのＵＲＬごとに紐付けられる識別番号を示す。ウェブアプリケーションデプロイ場所ＵＲＬ４２ｃは、ユーザリクエストに含まれるウェブアプリケーションをデプロイする場所のＵＲＬ、すなわち、ここではウェブサーバ１ＡのＵＲＬを指す。なお、アプリ管理テーブル４２は、サービス提供元ウェブアプリケーションＵＲＬとして、ウェブアプリケーションのサービスを提供する外部ウェブサーバ４内のＵＲＬを記憶しても良い。
【００３９】
図２に戻って、リクエスト転送部２５は、各種ＨＴＴＰリクエストをウェブサーバ１Ａまたは外部ウェブサーバ４に転送する。例えば、リクエスト転送部２５は、振分部２３によってユーザリクエストがオンプレミス環境のウェブサーバ１Ａに振り分けられた場合には、ウェブアプリケーションの転送（ダウンロード）を依頼するＨＴＴＰリクエストを、外部ウェブサーバ４に転送する。また、リクエスト転送部２５は、ダウンロードしたウェブアプリケーションの起動を依頼するＨＴＴＰリクエストをウェブサーバ１Ａに送信する。このＨＴＴＰリクエストには、アプリＩＤ登録部２４によって生成されたウェブアプリケーションのアプリＩＤが含まれる。また、リクエスト転送部２５は、ウェブアプリケーションの実行を依頼するＨＴＴＰリクエストをウェブサーバ１Ａに送信する。
【００４０】
なお、リクエスト転送部２５は、振分部２３によってウェブアプリケーションへのＨＴＴＰリクエストが外部ウェブサーバ４に振り分けられた場合には、ウェブアプリケーションへのＨＴＴＰリクエストを、外部ウェブサーバ４に転送する。このとき、ＨＴＴＰリクエストに含まれるアクセス対象のデータのＵＲＬは、中継サーバ１Ａを経由して間接的にアクセスされるように書き換えられたＵＲＬであるものとする。このＵＲＬの書き換えは、例えば振分部２３によって行われる。
【００４１】
レスポンス受付部２６は、リクエスト転送部２５によって転送されたＨＴＴＰリクエストに対応するＨＴＴＰレスポンスを、転送先のウェブサーバ１Ａまたは外部ウェブサーバ４から受け付ける。例えば、レスポンス受付部２６は、ウェブアプリケーションの起動依頼に対応する起動完了通知のＨＴＴＰレスポンスを、ウェブサーバ１Ａから受け付ける。また、レスポンス受付部２６は、ウェブアプリケーションの実行依頼に対応する当該ウェブアプリケーションからのデータ要求のＨＴＴＰレスポンスを、ウェブサーバ１Ａから受け付ける。そして、レスポンス受付部２６は、受け付けたＨＴＴＰレスポンスをレスポンス解析部２７に出力する。
【００４２】
レスポンス解析部２７は、レスポンス受付部２６によって受け付けられたＨＴＴＰレスポンスを解析する。
【００４３】
ＵＲＬ書換部２８は、ウェブアプリケーションの起動完了通知が受け付けられた場合、ウェブアプリケーションで使用されるアクセス対象のデータのアクセス経路を、自装置を経由するように当該データのアクセス経路を書き換える。例えば、ＵＲＬ書換部２８は、ＨＴＴＰレスポンスに含まれるアプリＩＤおよびポート番号を取り出す。そして、ＵＲＬ書換部２８は、取り出したポート番号およびウェブサーバ１ＡのＵＲＬを用いてウェブアプリケーションのデプロイ場所ＵＲＬを再現し、再現したＵＲＬを、取得したアプリＩＤに対応付けてアプリ管理テーブル４２に更新する。そして、ＵＲＬ書換部２８は、ＨＴＴＰレスポンスから取り出したアプリＩＤが示すウェブアプリケーションで使用されるアクセス対象のデータのＵＲＬを、データ管理テーブル４１およびアプリ管理テーブル４２に基づいて取得する。そして、ＵＲＬ書換部２８は、取得したＵＲＬを中継サーバ１Ａを経由するように書き換える。すなわち、ＵＲＬ書換部２８は、アクセス対象のデータをウェブアプリケーションから直接的にアクセスさせないで、中継サーバ１Ａを経由させてウェブアプリケーションから間接的にアクセスさせるようにする。
【００４４】
アプリＩＤ付与部２９は、デプロイされたウェブアプリケーションを実行すべく、当該ウェブアプリケーションの実行を依頼するＨＴＴＰリクエストをリクエスト転送部２５に出力する。ＨＴＴＰリクエストには、実行ＵＲＬ書換部２８によって書き換えられたアクセス対象のデータのＵＲＬおよびＨＴＴＰレスポンスに含まれるアプリＩＤが付与される。
【００４５】
データアクセス判定部３０は、ウェブアプリケーションからデータ要求が受け付けられた場合、データ要求があったデータのアクセスを許可するか否かを判定する。例えば、データアクセス判定部３０は、レスポンス解析部２７によって解析されたＨＴＴＰレスポンスに含まれるアプリＩＤを基に、アプリ管理テーブル４２にデータＩＤが記憶されているか否かを判定する。そして、データアクセス判定部３０は、データＩＤが記憶されている場合には、データＩＤが示すアクセス対象のデータについて、データ管理テーブル４１に公開ポリシー（社外秘データＵＲＬ）が記憶されているか否かを判定する。そして、データアクセス判定部３０は、アクセス対象のデータについて、公開ポリシーが記憶されている場合には、アクセスを許可することが可能であると判定する。一方、データアクセス判定部３０は、アクセス対象のデータについて、公開ポリシーが記憶されていない場合には、不正なアクセスであると判断し、アクセスを許可しないものと判定する。
【００４６】
さらに、データアクセス判定部３０は、アクセス対象のデータのアクセスを許可することが可能であると判定する場合には、データ管理テーブル４１に基づいて、データ要求があったデータが一致するか否かを判定しても良い。例えば、データアクセス判定部３０は、データ管理テーブル４１に記憶された、データＩＤに対応する社外秘データＵＲＬを参照する。そして、データアクセス判定部３０は、参照した社外秘データＵＲＬがＨＴＴＰレスポンスに含まれたデータ要求があったデータのＵＲＬと一致するか否かを判定する。そして、データアクセス判定部３０は、一致する場合には、正常なアクセスであると判断し、アクセスを許可するものと判定する。一方、データアクセス判定部３０は、一致しない場合には、不正なアクセスであると判断し、アクセスを許可しないものと判定する。
【００４７】
レスポンス転送部３１は、各種ＨＴＴＰレスポンスを各ＨＴＴＰレスポンスに応じて転送する。例えば、レスポンス転送部３１は、データアクセス判定部３０によってアクセスを許可することが可能であると判定されたアクセス対象のデータについて、社内記憶装置６から読み出すべく、ＨＴＴＰレスポンスを社内記憶装置６に転送する。
【００４８】
［実施例２に係るウェブサーバの構成］
次に、実施例２に係るウェブサーバ１Ａの構成について、図５を参照して説明する。図５は、実施例２に係るウェブサーバの構成を示す機能ブロック図である。ウェブサーバ１Ａは、サンドボックス１１を含み、制御部および記憶部を有する。なお、ウェブサーバ１Ａは、実施例１のウェブサーバ１の一例である。
【００４９】
サンドボックス１１は、外部ウェブサーバ４からダウンロードされるウェブアプリケーションを、保護された領域で動作させることによってシステムが不正に操作されるのを防ぐセキュリティモデルである。中継サーバ２Ａから起動依頼（デプロイ）されるウェブアプリケーションは、保護された領域に入り、他のアプリケーションやデータなどを操作できない状態にされて動作する。このため、ウェブアプリケーションが暴走したりウイルスを動作させたりしようとしても、システムに影響が及ばないようにできる。
【００５０】
制御部は、ＨＴＴＰリクエストを制御するリクエスト受付部６１、アプリＩＤ登録有無判定部３２、リクエストキュー部３３、プロセスＩＤ解析部３４、アプリＩＤ検索部３５およびレスポンス転送部３６を有する。また、制御部は、例えば、ＡＳＩＣ（Application  Specific  Integrated  Circuit）やＦＰＧＡ（Field  Programmable  Gate  Array）などの集積回路またはＣＰＵ（Central  Processing  Unit）やＭＰＵ（Micro  Processing  Unit）などの電子回路である。なお、アプリＩＤ検索部３５は、実施例１の検索部１３の一例である。レスポンス転送部３６は、実施例１の実行部１４の一例である。
【００５１】
記憶部は、アプリ管理テーブル５１を有する。記憶部は、例えば、ＲＡＭ（Random  Access  Memory）、フラッシュメモリ（flash  memory）などの半導体メモリ素子、または、ハードディスク、光ディスクなどの記憶装置である。なお、アプリ管理テーブル５１は、実施例１の記憶部１２の一例である。
【００５２】
リクエスト受付部６１は、中継サーバ２Ａから各種ＨＴＴＰリクエストを受け付ける。例えば、リクエスト受付部６１は、ウェブアプリケーションの起動を依頼するＨＴＴＰリクエストを中継サーバ２Ａから受け付ける。また、リクエスト受付部６１は、ウェブアプリケーションの実行を依頼するＨＴＴＰリクエストを中継サーバ２Ａから受け付ける。双方のＨＴＴＰリクエストには、ウェブアプリケーションのアプリＩＤが含まれる。
【００５３】
アプリＩＤ登録有無判定部３２は、リクエスト受付部６１によって受け付けられたＨＴＴＰリクエストに含まれるアプリＩＤが後述するアプリ管理テーブル５１に登録されているか否かを判定する。そして、アプリＩＤ登録有無判定部３２は、アプリＩＤが登録されていないと判定された場合、ポート番号を割り当て、割り当てたポート番号とアプリＩＤとを対応付けてアプリ管理テーブル５１に格納する。割り当てられるポート番号は、例えば中継サーバ２ＡからＨＴＴＰリクエストが送信された際に用いられたポートの番号であり、ＯＳ（Operating  System）によって割り当てられる。アプリＩＤが登録されていないと判定される場合とは、ユーザリクエスト内のウェブアプリケーションに関し、ＨＴＴＰリクエストが最初に受け付けられた場合である。例えば、ウェブアプリケーションの起動依頼のＨＴＴＰリクエストが受け付けられた場合を指す。なお、アプリＩＤが登録されていると判定される場合とは、ユーザリクエスト内のウェブアプリケーションに関し、ＨＴＴＰリクエストが２回目以降の受け付けられた場合である。例えば、ウェブアプリケーションの実行依頼のＨＴＴＰリクエストが受け付けられた場合を指す。
【００５４】
また、アプリＩＤ登録有無判定部３２は、アプリＩＤが登録されていないと判定された場合、ＨＴＴＰリクエストに基づいて、リクエストキュー部３３に起動依頼のリクエストを出力する。これは、アプリＩＤに対応するウェブアプリケーションが起動されていないので、起動開始から起動完了までの間キューに保存された他のリクエストを待たせることにより、起動完了後に起動したウェブアプリケーションのプロセスＩＤを確実に取得するためである。また、アプリＩＤ登録有無判定部３２は、アプリＩＤが登録されていると判定された場合、既にアプリＩＤに対応するウェブアプリケーションが起動済みであるので、アプリ管理テーブル５１に記憶されたプロセスＩＤを取得する。そして、アプリＩＤ登録有無判定部３２は、サンドボックス１１のプロセスＩＤが示すプロセスに、ＨＴＴＰリクエストに基づく実行を依頼する。
【００５５】
ここで、アプリ管理テーブル５１のデータ構造について、図６を参照しながら説明する。図６は、アプリ管理テーブル５１のデータ構造の一例を示す図である。図６に示すように、アプリ管理テーブル５１は、アプリＩＤ５１ａ、ポート番号５１ｂおよびプロセスＩＤ５１ｃを対応付けて記憶する。アプリＩＤ５１ａは、ユーザリクエストに含まれるウェブアプリケーションのＵＲＬごとに紐付けられる識別番号を示す。ポート番号５１ｂは、サービスを特定する番号を示す。ここでは、ポート番号５１ｂは、例えばウェブアプリケーションのＵＲＬ毎にアプリＩＤ登録有無判定部３２によって割り当てられる。プロセスＩＤ５１ｃは、ウェブアプリケーションを起動したときに一意に割り当てられるプロセスの識別子である。プロセスＩＤ５１ｃは、ウェブアプリケーションの起動ごとにＯＳによって割り当てられる。つまり、同じウェブアプリケーションであっても複数起動されれば異なるプロセスＩＤが割り当てられる。
【００５６】
リクエストキュー部３３は、アプリＩＤ登録有無判定部３２から起動依頼のリクエストを受け取ると、受け取った起動依頼のリクエストをキューに保存する。そして、リクエストキュー部３３は、キューに保存した起動依頼のリクエストを処理する順番がくると、キューからこのリクエストを取り出す。そして、リクエストキュー部３３は、取り出したリクエストに基づいて、リクエストに含まれるアプリＩＤに対応するウェブアプリケーションの起動（デプロイ）をサンドボックス１１に依頼する。この結果、リクエストキュー部３３は、ウェブアプリケーションの起動開始から起動完了までの処理を待つこととなる。言い換えれば、リクエストキュー部３３は、起動中のウェブアプリケーションのアプリＩＤを管理している。
【００５７】
プロセスＩＤ解析部３４は、サンドボックス１１のウェブアプリケーションから起動完了通知またはデータ要求を取得すると、ＯＳに対して実行中のウェブアプリケーションのプロセスＩＤおよび送信元のポート番号を問い合わせる。つまり、ＯＳは、ウェブアプリケーションの実行中のプロセスＩＤを管理するとともに、リクエストやレスポンスを送信する際に用いられるポート番号を管理している。このため、プロセスＩＤ解析部３４は、取得した通知などを発行したウェブアプリケーションのプロセスＩＤをＯＳに対して問い合わせ、加えて、取得した通知などを送信する際に用いられるポート番号をＯＳに対して問い合わせる。ただし、ＯＳは、取得した通知などを送信する際に用いられるポート番号として、空いているポート番号を適当に割り当てる。
【００５８】
例えば、プロセスＩＤ解析部３４は、ウェブアプリケーションから起動完了通知を取得すると、取得した起動完了通知を出力したウェブアプリケーションのプロセスＩＤをＯＳに対して問い合わせる。そして、プロセスＩＤ解析部３４は、問い合わせたプロセスＩＤを、処理中管理されていたウェブアプリケーションのアプリＩＤと対応付けてアプリ管理テーブル５１に更新する。
【００５９】
また、プロセスＩＤ解析部３４は、ウェブアプリケーションからデータ要求を取得すると、取得したデータ要求を出力したウェブアプリケーションのプロセスＩＤを、ＯＳに対して問い合わせる。
【００６０】
また、プロセスＩＤ解析部３４は、レスポンスを送信する際に用いられる送信元のポート番号を、ＯＳに対して問い合わせる。そして、プロセスＩＤ解析部３４は、ＯＳに対して問い合わせた結果であるプロセスＩＤおよび送信元のポート番号をアプリＩＤ検索部３５に出力する。
【００６１】
アプリＩＤ検索部３５は、プロセスＩＤ解析部３４から出力されたプロセスＩＤを基に、当該プロセスＩＤに対応するウェブアプリケーションのアプリＩＤおよびポート番号をアプリ管理テーブル５１から検索する。例えば、アプリＩＤ検索部３５は、起動完了通知を出力したウェブアプリケーションのプロセスＩＤに対応するアプリＩＤおよびポート番号をアプリ管理テーブル５１から検索する。そして、アプリＩＤ検索部３５は、検索した結果、アプリＩＤが検索されると、検索されたアプリＩＤに対応するウェブアプリケーションの起動完了を通知するＨＴＴＰレスポンスをレスポンス転送部３６に出力する。ＨＴＴＰレスポンスには、アプリ管理テーブル５１から検索されたアプリＩＤおよびアプリ管理テーブル５１から検索されたポート番号が含まれる。
【００６２】
また、アプリＩＤ検索部３５は、データ要求を出力したウェブアプリケーションのプロセスＩＤに対応するアプリＩＤおよびポート番号をアプリ管理テーブル５１から検索する。そして、アプリＩＤ検索部３５は、検索した結果、アプリＩＤが検索されると、検索されたアプリＩＤに対応するウェブアプリケーションからのデータ要求を示すＨＴＴＰレスポンスをレスポンス転送部３６に出力する。ＨＴＴＰレスポンスには、アプリ管理テーブル５１から検索されたアプリＩＤが含まれる。すなわち、アプリＩＤ検索部３５は、アプリＩＤが検索されると、検索されたアプリＩＤと紐づいたユーザリクエストに関わるデータ要求であると判断できるので、このアプリＩＤを含んだＨＴＴＰレスポンスを出力する。なお、アプリＩＤ検索部３５は、検索した結果、ウェブアプリケーションのプロセスＩＤに対応するアプリＩＤが検索されない場合、アプリＩＤと紐づいたユーザリクエストに関わるデータ要求ではないので、当該データ要求を実行しない。
【００６３】
レスポンス転送部３６は、各種ＨＴＴＰレスポンスを各ＨＴＴＰレスポンスに応じて転送する。例えば、レスポンス転送部３６は、アプリＩＤに対応するウェブアプリケーションの起動完了を通知するＨＴＴＰレスポンスを、中継サーバ２Ａに対して転送する。また、レスポンス転送部３６は、アプリＩＤに対応するウェブアプリケーションからのデータ要求のＨＴＴＰレスポンスを、中継サーバ２Ａに対して転送する。このとき、レスポンス転送部３６は、ＯＳによって割り当てられた送信元のポート番号を用いて、アプリＩＤを含んだそれぞれのＨＴＴＰレスポンスを転送する。
【００６４】
これにより、ＯＳが送信元のポート番号として空いている番号を適当に割り当てても、レスポンス転送部３６は、ユーザリクエストに基づくウェブアプリケーションを示すアプリＩＤを含んでレスポンスを転送する。この結果、レスポンスを受け取った中継サーバ２Ａは、アプリＩＤによって、どのユーザリクエストに基づくウェブアプリケーションからのレスポンスであるのかを判定できる。
【００６５】
［実施例２に係る中継サーバにおけるアプリ起動依頼の手順］
次に、実施例２に係る中継サーバにおけるアプリ起動依頼の処理手順を、図７を参照して説明する。図７は、実施例２に係る中継サーバにおけるアプリ起動依頼の手順を示すフローチャートである。
【００６６】
まず、リクエスト受付部２１は、ウェブクライアント３からユーザリクエストを受け付けたか否かを判定する（ステップＳ１１）。ウェブクライアント３からユーザリクエストを受け付けていないと判定した場合（ステップＳ１１；Ｎｏ）、リクエスト受付部２１は、ウェブクライアント３からユーザリクエストを受信するまで、判定処理を繰り返す。
【００６７】
一方、ウェブクライアント３からユーザリクエストを受け付けたと判定した場合（ステップＳ１１；Ｙｅｓ）、振分部２３は、ユーザリクエストに含まれるアクセス対象のデータが社外秘データであるか否かを判定する（ステップＳ１２）。例えば、振分部２３は、ユーザリクエストに含まれるアクセス対象のデータのＵＲＬがデータ管理テーブル４１の社外秘データＵＲＬ４１ｂに記憶されているか否かを判定する。
【００６８】
アクセス対象のデータが社外秘データであると判定する場合（ステップＳ１２；Ｙｅｓ）、振分部２３は、ユーザリクエストに含まれるウェブアプリケーションの転送を依頼するＨＴＴＰリクエストをサービス提供元である外部ウェブサーバ４に転送する。そして、振分部２３は、サービス提供元である外部ウェブサーバ４からウェブアプリケーションをダウンロードする（ステップＳ１３）。
【００６９】
続いて、アプリＩＤ登録部２４は、ダウンロードしたウェブアプリケーションのＵＲＬ、すなわちユーザリクエストに含まれるウェブアプリケーションのＵＲＬに紐付けられるアプリＩＤを生成する。そして、アプリＩＤ登録部２４は、生成したアプリＩＤとアクセス対象のデータのデータＩＤとを対応付けてアプリ管理テーブル４２に登録する（ステップＳ１４）。
【００７０】
そして、アプリＩＤ登録部２４は、ホストのＵＲＬを書き換えて、ウェブアプリケーションの起動を依頼するＨＴＴＰリクエストをウェブサーバ１Ａに送信する（ステップＳ１５）。すなわち、アプリＩＤ登録部２４は、ダウンロードしたウェブアプリケーションを起動させるべく、ウェブサーバ１Ａに対してウェブアプリケーションの起動を依頼する。このとき、ＨＴＴＰリクエストには、生成されたウェブアプリケーションのアプリＩＤが付与される。そして、ウェブサーバ１Ａにおけるリクエスト処理に移行する。
【００７１】
なお、振分部２３がアクセス対象のデータが社外秘データでないと判定する場合（ステップＳ１２；Ｎｏ）には、例えば振分部２３がアクセス対象のデータのＵＲＬを、中継サーバ２Ａを経由するように書き換える（ステップＳ１６）。そして、振分部２３は、サービス提供元である外部ウェブサーバ４に対してウェブアプリケーションを送信先とするＨＴＴＰリクエストを送信し、処理を依頼する（ステップＳ１７）。その後、外部ウェブサーバ４のウェブアプリケーションからデータへのアクセス要求が送信されると、中継サーバ２Ａにおけるデータへのアクセス処理に移行する。
【００７２】
［実施例２に係るウェブサーバにおけるリクエスト処理の手順］
次に、実施例２に係るウェブサーバにおけるリクエスト処理の処理手順を、図８を参照して説明する。図８は、ウェブサーバにおけるリクエスト処理の手順を示すフローチャートである。
【００７３】
まず、リクエスト受付部６１は、ＨＴＴＰリクエストを受け付けたか否かを判定する（ステップＳ２１）。ＨＴＴＰリクエストを受け付けていないと判定した場合（ステップＳ２１；Ｎｏ）、リクエスト受付部６１は、ＨＴＴＰリクエストを受信するまで、判定処理を繰り返す。
【００７４】
一方、ＨＴＴＰリクエストを受け付けたと判定した場合（ステップＳ２１；Ｙｅｓ）、アプリＩＤ登録有無判定部３２は、受け付けられたＨＴＴＰリクエストに含まれるアプリＩＤがアプリ管理テーブル５１に登録済みであるか否かを判定する（ステップＳ２２）。アプリＩＤが登録済みでないと判定する場合（ステップＳ２２；Ｎｏ）、ここでは、受け付けたＨＴＴＰリクエストは、ウェブアプリケーションの起動を依頼するリクエストであったものとする。
【００７５】
すると、アプリＩＤ登録有無判定部３２は、ウェブアプリケーションの起動依頼のリクエストをリクエストキュー部３３に出力する。そして、リクエストキュー部３３は、取得した起動依頼のリクエストをキューに格納する（ステップＳ２３）。この結果、起動依頼のリクエストがキューイング状態となる。さらに、アプリＩＤ登録有無判定部３２は、ポート番号を割り当て、割り当てたポート番号とアプリＩＤとを対応付けてアプリ管理テーブル５１に格納する（ステップＳ２４）。
【００７６】
続いて、リクエストキュー部３３は、キューに保存した起動依頼のリクエストを処理する順番がくると、キューからこのリクエストを取り出し、リクエストに含まれるウェブアプリケーションの起動をサンドボックス１１に依頼する（ステップＳ２５）。この結果、リクエストキュー部３３は、ウェブアプリケーションの起動開始から起動完了までの間キューに保存された他の処理を待たせることとなる。言い換えれば、リクエストキュー部３３は、起動中のウェブアプリケーションをキューイング状態にし、起動中のウェブアプリケーションのアプリＩＤを管理する。
【００７７】
その後、プロセスＩＤ解析部３４は、サンドボックス１１のウェブアプリケーションから起動完了通知を取得する（ステップＳ２６）。そして、プロセスＩＤ解析部３４は、ＯＳに対して、起動完了通知を発行したウェブアプリケーションのプロセスＩＤを問い合わせる。そして、プロセスＩＤ解析部３４は、問い合わせた結果、取得したプロセスＩＤを起動中管理されているウェブアプリケーションのアプリＩＤと対応付けてアプリ管理テーブル５１に更新する（ステップＳ２７）。ここで、リクエストキュー部３３は、起動完了したウェブアプリケーションのキューイング状態を解放する。
【００７８】
そして、アプリＩＤ検索部３５は、ＯＳによって取得されたプロセスＩＤを基に、当該プロセスＩＤに対応するウェブアプリケーションのアプリＩＤおよびポート番号をアプリ管理テーブル５１から検索する。そして、レスポンス転送部３６は、アプリＩＤに対応するウェブアプリケーションの起動完了を通知するＨＴＴＰレスポンスを、中継サーバ２Ａに対して転送する（ステップＳ２８）。ＨＴＴＰレスポンスには、アプリＩＤとポート番号が含まれる。
【００７９】
一方、アプリＩＤが登録済みであると判定する場合（ステップＳ２２；Ｙｅｓ）、受け付けたＨＴＴＰリクエストは、ウェブアプリケーションの実行依頼のリクエストであったものとする。すると、アプリＩＤ登録有無判定部３２は、サンドボックス１１にウェブアプリケーションの実行を依頼する（ステップＳ２９）。例えば、アプリＩＤ登録有無判定部３２は、既にアプリＩＤに対応するウェブアプリケーションが起動済みであるので、アプリＩＤを基に、アプリ管理テーブル５１に記憶されたプロセスＩＤを取得する。そして、アプリＩＤ登録有無判定部３２は、取得したプロセスＩＤが示すプロセスに、ＨＴＴＰリクエストに基づいて実行を依頼する。
【００８０】
その後、プロセスＩＤ解析部３４は、ウェブアプリケーションから処理に必要なデータ要求のリクエストを取得する（ステップＳ３０）。そして、プロセスＩＤ解析部３４は、ＯＳに対して、データ要求のリクエストを送信したウェブアプリケーションのプロセスＩＤを問い合わせて、当該リクエストの送信元のプロセスＩＤを取得する（ステップＳ３１）。
【００８１】
そして、アプリＩＤ検索部３５は、ＯＳによって取得されたプロセスＩＤを基に、当該プロセスＩＤに対応するウェブアプリケーションのアプリＩＤおよびポート番号をアプリ管理テーブル５１から検索する（ステップＳ３２）。そして、レスポンス転送部３６は、データ要求リクエストにアプリＩＤを付与し、データ要求リクエストをＨＴＴＰレスポンスとして中継サーバ２Ａに対して転送する（ステップＳ３３）。ＨＴＴＰレスポンスには、アプリＩＤが含まれる。
【００８２】
［実施例２に係る中継サーバにおけるアプリ実行依頼の手順］
次に、実施例２に係る中継サーバにおけるアプリ実行依頼の処理手順を、図９を参照して説明する。図９は、中継サーバにおけるアプリ実行依頼の手順を示すフローチャートである。
【００８３】
ウェブサーバ１Ａから転送されたウェブアプリケーションの起動完了を通知するＨＴＴＰレスポンスを、レスポンス受付部２６が受け取る。すると、ＵＲＬ書換部２８が、デプロイしたウェブアプリケーションのＵＲＬをアプリ管理テーブル４２に更新する（ステップＳ４１）。例えば、ＵＲＬ書換部２８は、ＨＴＴＰレスポンスに含まれるアプリＩＤおよびポート番号を取り出す。そして、ＵＲＬ書換部２８は、取り出したポート番号およびウェブサーバ１ＡのＵＲＬを用いてウェブアプリケーションのデプロイ場所ＵＲＬを再現し、再現したＵＲＬを、取得したアプリＩＤに対応付けてアプリ管理テーブル４２に更新する。
【００８４】
続いて、ＵＲＬ書換部２８は、ウェブアプリケーションの実行を依頼するＨＴＴＰリクエストのアクセス対象のデータのＵＲＬを中継サーバ２Ａを経由するように書き換える（ステップＳ４２）。すなわち、ＵＲＬ書換部２８は、アクセス対象のデータをウェブアプリケーションから直接的にアクセスさせないで、中継サーバ２Ａを経由させてウェブアプリケーションから間接的にアクセスさせるようにする。
【００８５】
さらに、アプリＩＤ付与部２９は、ウェブアプリケーションの実行を依頼するＨＴＴＰリクエストに、ＨＴＴＰレスポンスに含まれるアプリＩＤを付与する（ステップＳ４３）。そして、リクエスト転送部２５は、ウェブアプリケーションの実行を依頼するＨＴＴＰリクエストをウェブサーバ１Ａに送信する（ステップＳ４４）。
【００８６】
［実施例２に係る中継サーバにおけるデータへのアクセス処理の手順］
次に、実施例２に係る中継サーバにおけるデータへのアクセス処理の処理手順を、図１０を参照して説明する。図１０は、中継サーバにおけるデータへのアクセス処理の手順を示すフローチャートである。
【００８７】
ウェブサーバ１Ａから転送されたデータ要求リクエストを示すＨＴＴＰレスポンスを、レスポンス受付部２６が受け取る。すると、データアクセス判定部３０は、データ要求リクエストがあったデータへのアクセスを許可しているか否かを判定する（ステップＳ５１）。例えば、データアクセス判定部３０は、ＨＴＴＰレスポンスに含まれるアプリＩＤを基に、アプリ管理テーブル４２にデータＩＤが記憶されているか否かを判定する。さらに、データアクセス判定部３０は、アプリ管理テーブル４２にデータＩＤが記憶されている場合には、データ管理テーブル４１に基づいて、データ要求があったデータが一致するか否かを判定する。
【００８８】
データへのアクセスを許可していると判定した場合（ステップＳ５１；Ｙｅｓ）、レスポンス転送部３１は、社内記憶装置６に記憶されたアクセス対象のデータである社外秘データにアクセスする（ステップＳ５２）。一方、データへのアクセスを許可していないと判定した場合（ステップＳ５１；Ｎｏ）、レスポンス転送部３１は、例えばウェブクライアント３へのメッセージ送信などによって許可されていないデータにアクセスしようとしたことを警告する（ステップＳ５３）。
【００８９】
［実施例２に係るリクエスト処理のうちアプリケーション起動処理のシーケンス図］
次に、実施例２に係るリクエスト処理のうちアプリケーション起動処理のシーケンスを、図１１を参照して説明する。図１１は、実施例２に係るリクエスト処理のうちアプリケーション起動処理のシーケンス図である。
【００９０】
まず、ウェブクライアント３が、ウェブアプリケーションおよびアクセス対象データを選択し、ウェブアプリケーションの実行依頼を示すＨＴＴＰリクエスト（ユーザリクエスト）を送信する（ステップＳ６１）。ウェブクライアント３から中継サーバ２Ａへのユーザリクエストの内容は、例えば図１３に示す内容となる。図１３に示すように、ＰＯＳＴメソッドを「/app1  HTTP/1.1」とする。ホスト名を中継サーバ２Ａ（gw.company.com）とする。ウェブアプリケーションのＵＲＬを外部ウェブサーバ４に配置されたもの（http://www.cloud.com/app1）とする。アクセス対象データのＵＲＬを社内記憶装置６に記憶されたもの（http://data.company.com/data1.xml）とする。このアクセス対象データのＵＲＬが、社外秘データとしてデータＩＤ（例えば「１」）と対応付けられてデータ管理テーブル４１に記憶されているものとする。
【００９１】
そして、中継サーバ２Ａは、ＨＴＴＰリクエストを受け取り、受け取ったＨＴＴＰリクエストに含まれるアクセス対象データについて、データ管理テーブル４１に基づいて、公開ポリシーを判定する（ステップＳ６２）。ここでは、アクセス対象データのＵＲＬ（http://data.company.com/data1.xml）がデータ管理テーブル４１に記憶されているので、公開ポリシーを社外秘であるものと判定する。
【００９２】
そして、中継サーバ２Ａは、アクセス対象データの公開ポリシーが社外秘であると判定したので、ＨＴＴＰリクエストをオンプレミス環境のウェブサーバ１Ａに振り分けるものと判断する。そして、中継サーバ２Ａは、外部ウェブサーバ４にウェブアプリケーション（http://www.cloud.com/app1）の転送依頼を送信し、外部ウェブサーバ４からウェブアプリケーションを取得（ダウンロード）する（ステップＳ６３）。そして、中継サーバ２Ａは、アクセス対象のデータのデータＩＤ「１」と関連付けて、ウェブアプリケーションのＵＲＬごとに紐付けられるアプリＩＤ（例えば「１」）をアプリ管理テーブル４２に登録する（ステップＳ６４）。
【００９３】
その後、中継サーバ２Ａは、取得（ダウンロード）したウェブアプリケーションをウェブサーバ１Ａのサンドボックス１１にデプロイすべく、ウェブアプリケーションの起動依頼のリクエストを送信する（ステップＳ６５）。中継サーバ２Ａからサンドボックス１１へのウェブアプリケーションの起動依頼のリクエストの内容は、例えば図１４に示す内容となる。図１４に示すように、ＰＯＳＴメソッドを「/app1  HTTP/1.1」とする。ホスト名をウェブサーバ１Ａ（www.company.com）とする。そして、アプリケーションＩＤとして、ウェブアプリケーションに紐付けられたアプリＩＤの「１」が付与される。
【００９４】
続いて、ウェブサーバ１Ａは、起動依頼のリクエストに含まれるアプリＩＤがアプリ管理テーブル５１に登録されているか否かを判定し、アプリＩＤが登録されていなければポート番号を割り当て、アプリＩＤと対応付けて格納する（ステップＳ６６）。ここでは、アプリＩＤ「１」がアプリ管理テーブル５１に記憶されていないので、ウェブサーバ１Ａは、ポート番号として、リクエストを送信された際に用いられたポートの番号（例えば「１１１１」）を割り当てる。そして、ウェブサーバ１Ａは、割り当てたポート番号「１１１１」とアプリＩＤ「１」とを対応付けてアプリ管理テーブル５１に格納する。
【００９５】
さらに、ウェブサーバ１Ａは、起動依頼のリクエストをキューに保存する（ステップＳ６７）。これは、起動開始から起動完了までの間キューに保存された他のリクエストを待たせることにより、起動完了後に起動したウェブアプリケーションのプロセスＩＤを確実に取得するためである。
【００９６】
そして、ウェブサーバ１Ａは、起動依頼のリクエストの順番がくると、リクエストに基づいて、アプリＩＤに対応するウェブアプリケーションの起動をサンドボックス１１に依頼する（ステップＳ６８）。起動するウェブアプリケーションは、中継サーバ２Ａによって取得（ダウンロード）されたウェブアプリケーションである。ここでは、サンドボックス１１は、取得（ダウンロード）されたウェブアプリケーション（「app1」）を「http://www.company.com:1111」にデプロイする。そして、サンドボックス１１のウェブアプリケーションは、完了結果を通知する（ステップＳ６９）。
【００９７】
通知された完了結果が正常であれば、ウェブサーバ１Ａは、ＯＳから、完了結果を通知したウェブアプリケーションのプロセスＩＤを取得する。ここでは、ウェブサーバ１Ａは、プロセスＩＤとして「１１」を取得する。そして、ウェブサーバ１Ａは、取得したプロセスＩＤ「１１」を、起動を完了したウェブアプリケーションのアプリＩＤ「１」と対応付けてアプリ管理テーブル５１に追加する（ステップＳ７０）。ここで、ウェブサーバ１Ａは、起動を完了したウェブアプリケーションのキューイング状態を解放する。
【００９８】
そして、ウェブサーバ１Ａは、アプリＩＤに対応するウェブアプリケーションの起動完了を中継サーバ２Ａに通知する（ステップＳ７１）。サンドボックス１１から中継サーバ２Ａへのウェブアプリケーションの起動完了のレスポンスの内容は、例えば図１５に示す内容となる。図１５に示すように、アプリケーションＩＤとして、ウェブアプリケーションに紐付けられたアプリＩＤの「１」が付与される。ポート番号として、アプリ管理テーブル５１に記憶されたポート番号であってアプリＩＤ（「１」）に対応付けられたポート番号の「１１１１」が付与される。
【００９９】
続いて、中継サーバ２Ａは、起動完了通知のレスポンスに含まれたアプリＩＤおよびポート番号を取り出し、取り出したポート番号およびウェブサーバ１ＡのＵＲＬを用いてウェブアプリケーションのデプロイ場所ＵＲＬを再現する。ここでは、取り出されたポート番号が「１１１１」であり、ウェブサーバ１ＡのＵＲＬが「www.company.com」であるので、ウェブアプリケーションのデプロイ場所ＵＲＬは、「www.company.com:1111」と再現される。そして、中継サーバ２Ａは、再現したデプロイ場所ＵＲＬを、取り出したアプリＩＤに対応付けてアプリ管理テーブル４２に登録する（ステップＳ７２）。
【０１００】
［実施例２に係るリクエスト処理のうちアプリケーション実行処理のシーケンス図］
次に、実施例２に係るリクエスト処理のうちアプリケーション実行処理のシーケンスを、図１２を参照して説明する。図１２は、実施例２に係るリクエスト処理のうちアプリケーション実行処理のシーケンス図である。なお、中継サーバ２Ａは、ウェブアプリケーションの起動完了通知のレスポンスを受信し、デプロイ場所ＵＲＬをアプリ管理テーブル４２に登録したものとする。
【０１０１】
続いて、中継サーバ２Ａは、ウェブアプリケーションで使用されるアクセス対象のデータのアクセス経路を、中継サーバ２Ａを経由するように当該データのＵＲＬを書き換える（ステップＳ７３）。その後、中継サーバ２Ａは、デプロイ先のウェブアプリケーションに実行を依頼するリクエストを送信する（ステップＳ７４）。リクエストには、起動完了通知のレスポンスに含まれるアプリＩＤ「１」が付与される。
【０１０２】
中継サーバ２Ａからサンドボックス１１へのウェブアプリケーションの実行依頼のリクエストの内容は、例えば図１６に示す内容となる。図１６に示すように、ＧＥＴメソッドを「/app1?data=・・・data1.xml  HTTP/1.1」とする。これは、アクセス対象データの書き換え後のＵＲＬである。すなわち、アクセス対象のデータの書き換え前のＵＲＬには、図１３に示すように、アクセス対象のデータである社外秘データのＵＲＬ（Ｕ０）が記載されている。つまり、社内記憶装置６（data:company.com）に記憶されたデ−タ（data1.xml）に直接的にアクセスされるようにクエリ文字列として記載されている。一方、図１６のアクセス対象のデータの書き換え後のＵＲＬには、アクセス対象のデータである社外秘データが、間接的にアクセスされるように記載されている。すなわち、社外秘データ（Ｕ２）が、中継サーバ（Ｕ１）を経由してからアクセスされるように書き換えられる。なお、ここでは、書き換え後のＵＲＬは、英数字以外の文字列などの記号を安全な形に変換するために、ＵＲＬエンコードされている。
【０１０３】
続いて、ウェブサーバ１Ａは、実行依頼のリクエストに含まれるアプリＩＤがアプリ管理テーブル５１に登録されているか否かを判定する（ステップＳ７５）。ここでは、アプリＩＤ「１」がアプリ管理テーブル５１に記憶されているので、アプリＩＤが登録されていると判定する。そして、ウェブサーバ１Ａは、アプリ管理テーブル５１に記憶されたプロセスＩＤに基づいて、アプリＩＤ「１」に対応するプロセスＩＤ「１１」を取得し、取得したプロセスＩＤが示すプロセスに、ウェブアプリケーションの実行を依頼する（ステップＳ７６）。
【０１０４】
その後、ウェブサーバ１Ａは、ウェブアプリケーションから、処理に必要なデータ要求を取得する（ステップＳ７７）。すると、ウェブサーバ１Ａは、ＯＳからデータ要求をしたウェブアプリケーションのプロセスＩＤを取得する。ここでは、ウェブサーバ１Ａは、プロセスＩＤとして「１１」を取得する。そして、ウェブサーバ１Ａは、取得したプロセスＩＤ「１１」を基に、アプリ管理テーブル５１からアプリＩＤを検索する（ステップＳ７８）。ここでは、アプリＩＤ「１」が検索される。
【０１０５】
そして、ウェブサーバ１Ａは、処理に必要なデータを依頼すべく、アプリＩＤに対応するウェブアプリケーションからのデータ要求のリクエストを中継サーバ２Ａに転送する（ステップＳ７９）。データ要求には、アプリＩＤが付与される。ウェブアプリケーションから中継サーバ２Ａへのデータ要求の内容は、例えば図１７に示す内容となる。図１７に示すように、ＧＥＴメソッドを「http://data.company.com/data1.xml  HTTP/1.1」とする。ホスト名を中継サーバ２Ａ（gw.company.com）とする。アプリケーションＩＤとして、ウェブアプリケーションに紐付けられたアプリＩＤの「１」が付与される。
【０１０６】
続いて、中継サーバ２Ａは、データ要求を取得すると、データ要求がされたデータ（http://data.company.com/data1.xml  HTTP/1.1）について、データへのアクセスを許可するか否かを判定する（ステップＳ８０）。例えば、中継サーバ２Ａは、データ管理テーブル４１にアプリＩＤに対応する公開ポリシーが記憶されているか否かを判定する。ここでは、中継サーバ２Ａは、データ管理テーブル４１にアプリＩＤ「１」に対応する公開ポリシーが記憶されているので、アクセスを許可することが可能であると判定する。さらに、中継サーバ２Ａは、データ管理テーブル４１に基づいて、データ要求がされたデータ（http://data.company.com/data1.xml  HTTP/1.1）が一致するか否かを判定する。ここでは、中継サーバ２Ａは、データ管理テーブル４１にアプリＩＤ「１」に対応する社外秘データＵＲＬとして、データ要求がされたデータが記憶されているので、正常なアクセスであると判断し、アクセスを許可するものと判定する。
【０１０７】
そして、中継サーバ２Ａは、アクセスを許可されたデータにアクセスする（ステップＳ８１）。中継サーバ２Ａから社内記憶装置６へのデータ要求の内容は、例えば図１８に示す内容となる。図１８に示すように、ＧＥＴメソッドを「/data1.xml  HTTP/1.1」とする。ホスト名を社内記憶装置６（data.company.com）とする。アプリケーションＩＤとして、ウェブアプリケーションに紐付けられたアプリＩＤの「１」が付与される。
【０１０８】
その後、中継サーバ２Ａは、社内記憶装置６からデータを取得し（ステップＳ８２）、取得したデータをウェブサーバ１Ａに送信する（ステップＳ８３）。さらに、中継サーバ２Ａは、ウェブサーバ１Ａから処理結果の通知を受け取ると（ステップＳ８４）、処理結果をウェブクライアント３に通知する（ステップＳ８５）。
【０１０９】
［実施例２の効果］
上記実施例２によれば、ウェブサーバ１Ａのアプリ管理テーブル５１は、ユーザリクエストに含まれるウェブアプリケーションのＵＲＬごとに紐付けられたアプリＩＤと、当該ウェブアプリケーションのプロセスＩＤとを対応付けて記憶する。そして、アプリＩＤ検索部３５は、実行中のウェブアプリケーションからデータ要求があった場合、データ要求があったウェブアプリケーションのプロセスＩＤに対応するウェブアプリケーションのアプリＩＤをアプリ管理テーブル５１から検索する。そして、レスポンス転送部３６は、ウェブアプリケーションのアプリＩＤが検索されると、検索されたウェブアプリケーションのアプリＩＤと紐づくユーザリクエストに関わるデータ要求を中継サーバ２Ａに送信する。
【０１１０】
かかる構成によれば、ウェブサーバ１Ａは、実行中のウェブアプリケーションのプロセスＩＤとの比較に、ユーザリクエストに含まれるウェブアプリケーションと紐付いたアプリＩＤの対応付けとして記憶したプロセスＩＤを用いる。このため、ウェブサーバ１Ａは、比較の結果プロセスＩＤが一致すれば、これに対応するアプリＩＤを検索できるので、検索できたアプリＩＤが示すウェブアプリケーションとユーザリクエストとが紐づくこととなる。したがって、ウェブサーバ１Ａは、ウェブアプリケーションが複数実行していても、ウェブアプリケーションからのデータ要求がどのユーザリクエストに基づくウェブアプリケーションからの要求であるのかを判定できる。この結果、中継サーバ２Ａは、不正なデータアクセスを防止できる。
【０１１１】
また、上記実施例２によれば、プロセスＩＤ解析部３４は、データ要求があったウェブアプリケーションのプロセスＩＤをＯＳに問い合わせ、問い合わせた結果得られたプロセスＩＤに対応するアプリＩＤをアプリ管理テーブル５１から検索する。かかる構成によれば、プロセスＩＤ解析部３４は、アプリ管理テーブル５１からのアプリＩＤの検索に、ＯＳによって管理されたプロセスＩＤを用いることにより、データ要求があったウェブアプリケーションと紐付いたアプリＩＤの有無を確実に判定できる。この結果、プロセスＩＤ解析部３４は、ウェブアプリケーションからのデータ要求がどのユーザリクエストに基づくウェブアプリケーションからの要求であるのかを容易に判定できる。
【０１１２】
また、上記実施例２によれば、アプリＩＤ登録有無判定部３２は、新たなリクエストに含まれるウェブアプリケーションのＵＲＬに紐付けられたウェブアプリケーションのアプリＩＤがアプリ管理テーブル５１に記憶されているか否かを判定する。そして、リクエストキュー部３３は、アプリＩＤが記憶されていない場合、キューを用いて、当該リクエストに含まれるウェブアプリケーションの起動開始から起動完了までの処理を待つ。そして、プロセスＩＤ解析部３４は、当該ウェブアプリケーションから起動完了が通知されると、当該ウェブアプリケーションのプロセスＩＤをＯＳに問い合わせる。そして、プロセスＩＤ解析部３４は、問い合わせた結果得られたプロセスＩＤを当該ウェブアプリケーションのアプリＩＤと対応付けてアプリ管理テーブル５１に記憶する。かかる構成によれば、リクエストキュー部３３は、新たなリクエストがあったときキューを用いるようにしたので、他のリクエストと処理が混在しないので、新たなリクエストに含まれるウェブアプリケーションのプロセスＩＤを確実に取得できる。この結果、新たなリクエストに含まれるウェブアプリケーションからその後データ要求があってもデータ要求がどのリクエストに基づくウェブアプリケーションからの要求であるのかを判定できる。
【０１１３】
また、上記実施例３によれば、レスポンス転送部３６は、アプリＩＤを付与したデータ要求を中継サーバ２Ａに送信するようにした。かかる構成によれば、レスポンス転送部３６は、アプリＩＤが示すウェブアプリケーションとユーザリクエストとが紐づいているので、中継サーバ２Ａに、データ要求がどのユーザリクエストに基づくウェブアプリケーションからの要求であるのかを示唆できる。
【実施例３】
【０１１４】
ところで、実施例１および実施例２では、ウェブサーバ１（１Ａ）と中継サーバ２（２Ａ）とが分離した場合を説明した。しかしながら、これに限定されず、ウェブサーバ１（１Ａ）と中継サーバ２（２Ａ）とが統合しても良い。そこで、実施例３では、ウェブサーバ１（１Ａ）と中継サーバ２（２Ａ）とが統合した場合の中継サーバ２Ｂについて説明する。
【０１１５】
［実施例３に係る中継サーバの構成］
図１９は、実施例３に係る中継サーバの構成を示す機能ブロック図である。なお、図２に示す中継サーバ２Ａおよび図５に示すウェブサーバ１Ａと同一の構成については同一符号を示すことで、その重複する構成および動作の説明については省略する。実施例２と実施例３とが異なるところは、中継サーバ２Ａのアプリ管理テーブル４２とウェブサーバ１Ａのアプリ管理テーブル５１とを統合したアプリ管理テーブル５１Ａとした点にある。
【０１１６】
［実施例３に係るリクエスト処理のうちアプリケーション起動処理のシーケンス図］
次に、実施例３に係るリクエスト処理のうちアプリケーション起動処理のシーケンスを、図２０を参照して説明する。図２０は、実施例３に係るリクエスト処理のうちアプリケーション起動処理のシーケンス図である。
【０１１７】
まず、ウェブクライアント３が、ウェブアプリケーションおよびアクセス対象データを選択し、ウェブアプリケーションの実行依頼を示すＨＴＴＰリクエスト（ユーザリクエスト）を送信する（ステップＳ９１）。ウェブクライアント３から中継サーバ２Ｂへのユーザリクエストの内容は、例えば、ＰＯＳＴメソッドを「/app1  HTTP/1.1」とする。ホスト名を中継サーバ２Ｂ（gw.company.com）とする。ウェブアプリケーションのＵＲＬを外部ウェブサーバ４に配置されたもの（http://www.cloud.com/app1）とする。アクセス対象データのＵＲＬを社内記憶装置６に記憶されたもの（http://data.company.com/data1.xml）とする。このアクセス対象データのＵＲＬが、社外秘データとしてデータＩＤ（例えば「１」）と対応付けられてデータ管理テーブル４１に記憶されているものとする。
【０１１８】
そして、中継サーバ２Ｂは、ＨＴＴＰリクエストを受け取り、受け取ったＨＴＴＰリクエストに含まれるアクセス対象データについて、データ管理テーブル４１に基づいて、公開ポリシーを判定する（ステップＳ９２）。ここでは、アクセス対象データのＵＲＬ（http://data.company.com/data1.xml）がデータ管理テーブル４１に記憶されているので、公開ポリシーを社外秘であるものと判定する。
【０１１９】
そして、中継サーバ２Ｂは、アクセス対象データの公開ポリシーが社外秘であると判定したので、ＨＴＴＰリクエストをオンプレミス環境の中継サーバ２Ｂに振り分けるものと判断する。そして、中継サーバ２Ｂは、外部ウェブサーバ４にウェブアプリケーション（http://www.cloud.com/app1）の転送依頼を送信し、外部ウェブサーバ４からウェブアプリケーションを取得（ダウンロード）する（ステップＳ９３）。
【０１２０】
そして、中継サーバ２Ｂは、ウェブアプリケーションのＵＲＬごとに紐付けられるアプリＩＤ（例えば「１」）を生成する。そして、中継サーバ２Ｂは、アプリＩＤがアプリ管理テーブル５１Ａに登録されているか否かを判定し、アプリＩＤが登録されていなければポート番号を割り当て、アプリＩＤとアクセス対象のデータＩＤと対応付けて格納する（ステップＳ９４）。ここでは、アプリＩＤ「１」がアプリ管理テーブル５１Ａに記憶されていないので、中継サーバ２Ｂは、ポート番号（例えば「１１１１」）を割り当てる。そして、ウェブサーバ１Ａは、割り当てたポート番号「１１１１」とアプリＩＤ「１」とデータＩＤ「１」とを対応付けてアプリ管理テーブル５１Ａに格納する。
【０１２１】
そして、中継サーバ２Ｂは、ウェブアプリケーションの起動依頼のリクエストをキューに保存する（ステップＳ９５）。これは、起動開始から起動完了までの間キューに保存された他のリクエストを待たせることにより、起動完了後に起動したウェブアプリケーションのプロセスＩＤを確実に取得するためである。
【０１２２】
そして、中継サーバ２Ｂは、ウェブアプリケーションの起動依頼のリクエストの順番がくると、リクエストに基づいて、アプリＩＤに対応するウェブアプリケーションの起動をサンドボックス１１に依頼する（ステップＳ９６）。起動するウェブアプリケーションは、中継サーバ２Ｂによって取得（ダウンロード）されたウェブアプリケーションである。ここでは、サンドボックス１１は、取得（ダウンロード）されたウェブアプリケーション（「app1」）を「http://www.company.com:1111」にデプロイする。そして、サンドボックス１１のウェブアプリケーションは、完了結果を通知する（ステップＳ９７）。
【０１２３】
通知された完了結果が正常であれば、中継サーバ２Ｂは、ＯＳから、完了結果を通知したウェブアプリケーションのプロセスＩＤを取得する。ここでは、中継サーバ２Ｂは、プロセスＩＤとして「１１」を取得する。そして、中継サーバ２Ｂは、取得したプロセスＩＤ「１１」を、起動を完了したウェブアプリケーションのアプリＩＤ「１」と対応付けてアプリ管理テーブル５１Ａに追加する（ステップＳ９８）。ここで、中継サーバ２Ｂは、起動を完了したウェブアプリケーションのキューイング状態を解放する。
【０１２４】
そして、中継サーバ２Ｂは、ウェブアプリケーションをデプロイしたデプロイ場所ＵＲＬをアプリＩＤに対応付けてアプリ管理テーブル５１Ａに登録する（ステップＳ９９）。ここでは、アプリ管理テーブル５１ＡのアプリＩＤ「１」に対応付けてウェブアプリケーションデプロイ場所ＵＲＬ「www.company.com:1111」が登録される。
【０１２５】
［実施例３に係るリクエスト処理のうちアプリケーション実行処理のシーケンス図］
次に、実施例３に係るリクエスト処理のうちアプリケーション実行処理のシーケンスを、図２１を参照して説明する。図２１は、実施例３に係るリクエスト処理のうちアプリケーション実行処理のシーケンス図である。なお、中継サーバ２Ｂは、ウェブアプリケーションの起動完了通知を取得し、デプロイ場所ＵＲＬをアプリ管理テーブル５１Ａに登録したものとする。
【０１２６】
続いて、中継サーバ２Ｂは、ウェブアプリケーションで使用されるアクセス対象のデータのアクセス経路を、中継サーバ２Ｂを経由するように当該データのＵＲＬを書き換える（ステップＳ１００）。
【０１２７】
続いて、中継サーバ２Ｂは、アプリＩＤがアプリ管理テーブル５１Ａに登録されているか否かを判定する（ステップＳ１０１）。ここでは、アプリＩＤ「１」がアプリ管理テーブル５１Ａに記憶されているので、アプリＩＤが登録されていると判定する。そして、中継サーバ２Ｂは、アプリ管理テーブル５１Ａに記憶されたプロセスＩＤに基づいて、アプリＩＤ「１」に対応するプロセスＩＤ「１１」を取得し、取得したプロセスＩＤが示すプロセスに、ウェブアプリケーションの実行を依頼する（ステップＳ１０２）。
【０１２８】
その後、中継サーバ２Ｂは、ウェブアプリケーションから、処理に必要なデータ要求を取得する（ステップＳ１０３）。すると、中継サーバ２Ｂは、ＯＳからデータ要求をしたウェブアプリケーションのプロセスＩＤを取得する。ここでは、中継サーバ２Ｂは、プロセスＩＤとして「１１」を取得する。そして、中継サーバ２Ｂは、取得したプロセスＩＤ「１１」を基に、アプリ管理テーブル５１ＡからアプリＩＤを検索する（ステップＳ１０４）。ここでは、アプリＩＤ「１」が検索される。
【０１２９】
続いて、中継サーバ２Ｂは、データ要求がされたデータ（http://data.company.com/data1.xml  HTTP/1.1）について、データへのアクセスを許可するか否かを判定する（ステップＳ１０５）。例えば、中継サーバ２Ｂは、データ管理テーブル４１にアプリＩＤに対応する公開ポリシーが記憶されているか否かを判定する。ここでは、中継サーバ２Ｂは、データ管理テーブル４１にアプリＩＤ「１」に対応する公開ポリシーが記憶されているので、アクセスを許可することが可能であると判定する。さらに、中継サーバ２Ｂは、データ管理テーブル４１に基づいて、データ要求がされたデータ（http://data.company.com/data1.xml  HTTP/1.1）が一致するか否かを判定する。ここでは、中継サーバ２Ｂは、データ管理テーブル４１にアプリＩＤ「１」に対応する社外秘データＵＲＬとして、データ要求がされたデータが記憶されているので、正常なアクセスであると判断し、アクセスを許可するものと判定する。
【０１３０】
そして、中継サーバ２Ｂは、アクセスを許可されたデータにアクセスする（ステップＳ１０６）。中継サーバ２Ｂから社内記憶装置６へのデータ要求の内容は、例えば、ＧＥＴメソッドを「/data1.xml  HTTP/1.1」とする。ホスト名を社内記憶装置６（data.company.com）とする。アプリケーションＩＤとして、ウェブアプリケーションに紐付けられたアプリＩＤの「１」が付与される。
【０１３１】
その後、中継サーバ２Ｂは、社内記憶装置６からデータを取得し（ステップＳ１０７）、取得したデータを用いた処理結果をウェブクライアント３に通知する（ステップＳ１０８）。
【０１３２】
［実施例３の効果］
上記実施例３によれば、中継サーバ２Ｂのアプリ管理テーブル５１Ａは、ユーザリクエストに含まれるウェブアプリケーションのＵＲＬごとに紐付けられたアプリＩＤと、当該ウェブアプリケーションのプロセスＩＤとを対応付けて記憶する。そして、アプリＩＤ検索部３５は、実行中のウェブアプリケーションからデータ要求があった場合、データ要求があったウェブアプリケーションのプロセスＩＤに対応するウェブアプリケーションのアプリＩＤをアプリ管理テーブル５１Ａから検索する。そして、レスポンス転送部３１は、ウェブアプリケーションのアプリＩＤが検索されると、検索されたウェブアプリケーションのアプリＩＤと紐づくユーザリクエストに関わるデータ要求を社内記憶装置６に送信する。
【０１３３】
かかる構成によれば、中継サーバ２Ｂは、実行中のウェブアプリケーションのプロセスＩＤとの比較に、ユーザリクエストに含まれるウェブアプリケーションと紐付いたアプリＩＤの対応付けとして記憶したプロセスＩＤを用いる。このため、中継サーバ２Ｂは、比較の結果プロセスＩＤが一致すれば、これに対応するアプリＩＤを検索できるので、検索できたアプリＩＤが示すウェブアプリケーションとユーザリクエストとが紐づくこととなる。したがって、中継サーバ２Ｂは、ウェブアプリケーションが複数実行していても、ウェブアプリケーションからのデータ要求がどのユーザリクエストに基づくウェブアプリケーションからの要求であるのかを判定できる。この結果、中継サーバ２Ｂは、不正なデータアクセスを防止できる。
【０１３４】
また、上記実施例３によれば、データアクセス判定部３０は、アプリＩＤを基にアプリ管理テーブル４２にデータＩＤが記憶されているか否かを判定する。そして、データアクセス判定部３０は、データＩＤが記憶されている場合には、データＩＤを基にデータ管理テーブル４１に社外秘データＵＲＬが記憶されているか否かを判定する。さらに、データアクセス判定部３０は、社外秘データＵＲＬが記憶されている場合には、当該社外秘データＵＲＬが、データ要求があったデータのＵＲＬと一致しているか否かを判定する。そして、データアクセス判定部３０は、一致していると判定した場合、レスポンス転送部３１を介して、データ要求を社内記憶装置６に転送する。かかる構成によれば、データアクセス判定部３０は、アプリＩＤから紐づく社外秘データＵＲＬがデータ要求があったデータＵＲＬと一致している場合に、データ要求を社内記憶装置６に転送することとしたので、データ単位で不正なデータアクセスを防止できる。
【０１３５】
なお、外部ウェブサーバ４は、例えばクラウド環境のウェブサーバを指すものとして説明した。しかしながら、外部ウェブサーバ４は、ウェブサービスを提供可能なウェブサーバであればこれに限定されるものではない。
【０１３６】
また、オンプレミス環境とは、社内で整備された環境であって外部ウェブサーバ４のアプリケーションをダウンロードして実施できる環境を意味するものとして説明した。しかしながら、オンプレミス環境とは、外部ウェブサーバ４のアプリケーションをダウンロードして実施できる環境であればこれに限定されるものではない。
【０１３７】
また、中継サーバ２Ａがウェブクライアント３、ウェブサーバ１Ａおよび社内記憶装置６とインターネットを介さないで接続する形態は、例えば社内ＬＡＮ（Local  Area  Network）であったり、社内におけるイントラネットであったりするものとして説明した。しかしながら、この接続形態は、データのアクセス制限をホスト（ドメイン）単位でしか指定できないＨＴＴＰプロトコルであればこれらに限定されるものではない。
【０１３８】
また、上記実施例では、ＨＴＴＰプロトコルでデータをやりとりする場合を説明した。しかしながら、ＨＴＴＰプロトコルでデータをやりとりする場合に限定されず、データのアクセス制限をホスト（ドメイン）単位でしか指定できないようなプロトコルでデータをやりとりする場合であっても良い。
【０１３９】
また、レスポンス転送部３６は、ＯＳによって割り当てられた送信元のポート番号を用いて、ＨＴＴＰレスポンスを中継サーバ２Ａに転送するものとして説明した。しかしながら、レスポンス転送部３６は、これに限定されず、アプリ管理テーブル５１に記憶されたポート番号を用いて、ＨＴＴＰレスポンスを中継サーバ２Ａに転送しても良い。アプリ管理テーブル５１に記憶されたポート番号が例えば中継サーバ２ＡからＨＴＴＰリクエストが送信された際に用いられたポートの番号であるとする。この場合、レスポンス転送部３６は、中継サーバ２Ａにレスポンスを返すときに、中継サーバ２Ａからのリクエストで用いられたポート番号と同一のものを用いることができる。この結果、レスポンスを受け取る中継サーバ２Ａは、アプリＩＤのみならずポート番号からも、どのユーザリクエストに基づくウェブアプリケーションからのレスポンスであるのかを判定できる。
【０１４０】
また、データ管理テーブル４１は、ウェブサーバ１Ａからウェブクライアント３に送信されるデータごとに、公開ポリシーとして、社外での公開に制限がある社外秘データを記憶するものとして説明した。しかしながら、データ管理テーブル４１は、ウェブサーバ１Ａからウェブクライアント３に送信されるデータごとに、公開ポリシーとして、社外秘データと、社外および社内での公開に制限がある機密データとを含んで記憶するものとしても良い。この場合、振分部２３は、さらに、ウェブクライアント３から送信されたＨＴＴＰリクエストに含まれるアクセス対象のデータについてデータ管理テーブル４１に記憶された公開ポリシーを参照する。そして、振分部２３は、当該データについて社外および社内でも公開しない場合または公開ポリシーがない場合には、ＨＴＴＰリクエストの転送を無効とするようにすれば良い。
【０１４１】
［プログラムなど］
なお、ウェブサーバ１Ａは、既知のパーソナルコンピュータ、ワークステーションなどの情報処理装置に、上記したアプリＩＤ登録有無判定部３２、リクエストキュー部３３などの各機能を搭載することによって実現することができる。また、中継サーバ２Ａは、既知のパーソナルコンピュータ、ワークステーションなどの情報処理装置に、上記した振分部２３、アプリＩＤ登録部２４、アプリ付与部２９などの各機能を搭載することによって実現することができる。
【０１４２】
また、図示した各装置の各構成要素は、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的態様は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。例えば、リクエストキュー部３３とプロセスＩＤ解析部３４とを１個の部として統合しても良い。一方、アプリＩＤ検索部３５を、起動完了通知を取得した場合にアプリＩＤを検索する第１の検索部とデータ要求を取得した場合にアプリＩＤを検索する第２の検索部とに分散しても良い。また、アプリ管理テーブル５１などの記憶部をウェブサーバ１Ａの外部装置としてネットワーク経由で接続するようにしても良い。
【０１４３】
また、上記実施例で説明した各種の処理は、あらかじめ用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータで実行することによって実現することができる。そこで、以下では、図２２を用いて、図５に示したウェブサーバ１Ａの制御部と同様の機能を有するリクエスト処理プログラムを実行するコンピュータの一例を説明する。なお、ウェブサーバ１Ａの制御部は、ＨＴＴＰリクエストを制御するリクエスト受付部６１、アプリＩＤ登録有無判定部３２、リクエストキュー部３３、プロセスＩＤ解析部３４、アプリＩＤ検索部３５およびレスポンス転送部３６に対応する。
【０１４４】
図２２は、リクエスト処理プログラムを実行するコンピュータを示す図である。図２２に示すように、コンピュータ１０００は、ＲＡＭ１０１０と、ネットワークインタフェース装置１０２０と、ＨＤＤ１０３０と、ＣＰＵ１０４０、媒体読取装置１０５０およびバス１０６０とを有する。ＲＡＭ１０１０、ネットワークインタフェース装置１０２０、ＨＤＤ１０３０、ＣＰＵ１０４０、媒体読取装置１０５０は、バス１０６０によって接続されている。
【０１４５】
そして、ＨＤＤ１０３０には、図５に示した制御部と同様の機能を有するリクエスト処理プログラム１０３１が記憶される。また、ＨＤＤ１０３０には、図５に示したアプリ管理テーブル５１に対応するリクエスト処理関連情報１０３２が記憶される。
【０１４６】
そして、ＣＰＵ１０４０がリクエスト処理プログラム１０３１をＨＤＤ１０３０から読み出してＲＡＭ１０１０に展開することにより、リクエスト処理プログラム１０３１は、リクエスト処理プロセス１０１１として機能するようになる。そして、リクエスト処理プロセス１０１１は、リクエスト処理関連情報１０３２から読み出した情報などを適宜ＲＡＭ１０１０上の自身に割り当てられた領域に展開し、この展開したデータなどに基づいて各種データ処理を実行する。
【０１４７】
媒体読取装置１０５０は、リクエスト処理プログラム１０３１がＨＤＤ１０３０に格納されていない場合であってもリクエスト処理プログラム１０３１を記憶する媒体などからリクエスト処理プログラム１０３１を読み取る。媒体読取装置１０５０には、例えばＣＤ−ＲＯＭや光ディスク装置がある。また、ネットワークインタフェース装置１０２０は、外部装置とネットワーク経由で接続する装置であり、有線、無線に対応するものである。
【０１４８】
なお、上記のリクエスト処理プログラム１０３１は、必ずしもＨＤＤ１０３０に格納されている必要はなく、ＣＤ−ＲＯＭなどの媒体読取装置１０５０に記憶されたこのプログラムを、コンピュータ１０００が読み出して実行するようにしてもよい。また、公衆回線、インターネット、ＬＡＮ、ＷＡＮ（Wide  Area  Network）などを介してコンピュータ１０００に接続される他のコンピュータ（またはサーバ）などにこのプログラムを記憶させておいても良い。この場合には、コンピュータ１０００がネットワークインタフェース装置１０２０を介してこれらからプログラムを読み出して実行する。
【０１４９】
以上の実施例１〜３を含む実施形態に関し、さらに以下の付記を開示する。
【０１５０】
（付記１）コンピュータに、
クライアントから送信されたリクエストに含まれるアプリケーションの宛先ごとに紐付けられたアプリケーションの識別情報と、当該アプリケーションの実行単位情報とを対応付けて記憶部に記憶し、
実行中のアプリケーションからデータ要求があった場合、データ要求があったアプリケーションの実行単位情報に対応するアプリケーションの識別情報を前記記憶部から検索し、
該検索した結果、アプリケーションの識別情報が検索されると、検索されたアプリケーションの識別情報と紐づくリクエストに関わるデータ要求の制御を実行する
処理を実行させることを特徴とするリクエスト処理プログラム。
【０１５１】
（付記２）前記コンピュータに、
前記検索する処理において、前記データ要求があったアプリケーションの実行単位情報をＯＳ（Operating  System）に問い合わせ、問い合わせた結果得られた実行単位情報に対応するアプリケーションの識別情報を前記記憶部から検索する
処理を実行させることを特徴とする付記１に記載のリクエスト処理プログラム。
【０１５２】
（付記３）前記コンピュータに、
新たなリクエストに含まれるアプリケーションの宛先に紐付けられたアプリケーションの識別情報が前記記憶部に記憶されていない場合、キューを用いて、当該リクエストに含まれるアプリケーションの起動開始から起動完了までの処理を待ち、
当該アプリケーションから起動完了が通知されると、当該アプリケーションの実行単位情報をＯＳに問い合わせ、問い合わせた結果得られた実行単位情報を当該アプリケーションの識別情報と対応付けて前記記憶部に記憶する
処理を実行させることを特徴とする付記１または付記２に記載のリクエスト処理プログラム。
【０１５３】
（付記４）前記コンピュータに、
該記憶部に記憶する処理において、クライアントから送信されたリクエストを中継する中継サーバから当該リクエストに含まれるアプリケーションの宛先ごとに紐付けられたアプリケーションの識別情報を取得し、取得したアプリケーションの識別情報と、当該アプリケーションの実行単位情報とを対応付けて前記記憶部に記憶し、
該データ要求の制御を実行する処理において、前記記憶部から検索されたアプリケーションの識別情報を付与したデータ要求を、前記中継サーバに送信する処理を実行させることを特徴とする付記１から付記３のいずれか１つに記載のリクエスト処理プログラム。
【０１５４】
（付記５）前記コンピュータに、
該データ要求の制御を実行する処理において、該データ要求によりアクセスするデータが前記記憶部から検索されたアプリケーションの識別情報と紐づくリクエストに含まれるアクセス対象のデータと一致するか否かを判定し、一致すると判定した場合に、該データ要求を、データが格納される記憶装置に送信する処理を実行させることを特徴とする付記１から付記３のいずれか１つに記載のリクエスト処理プログラム。
【０１５５】
（付記６）クライアントから送信されたリクエストに含まれるアプリケーションの宛先ごとに紐付けられたアプリケーションの識別情報と、当該アプリケーションの実行情報とを対応付けて記憶する記憶部と、
実行中のアプリケーションからのデータ要求があった場合、データ要求があったアプリケーションの実行情報に対応するアプリケーションの識別情報を前記記憶部から検索する検索部と、
前記検索部によってアプリケーションの識別情報が検索されると、検索されたアプリケーションの識別情報と紐づくリクエストに関わるデータ要求の制御を実行する実行部と
を有することを特徴とする情報処理装置。
【０１５６】
（付記７）コンピュータが、
クライアントから送信されたリクエストに含まれるアプリケーションの宛先ごとに紐付けられたアプリケーションの識別情報と、当該アプリケーションの実行単位情報とを対応付けて記憶部に記憶し、
実行中のアプリケーションからデータ要求があった場合、データ要求があったアプリケーションの実行単位情報に対応するアプリケーションの識別情報を前記記憶部から検索し、
該検索した結果、アプリケーションの識別情報が検索されると、検索されたアプリケーションの識別情報と紐づくリクエストに関わるデータ要求の制御を実行する
ことを特徴とするリクエスト処理方法。
【符号の説明】
【０１５７】
１、１Ａ  ウェブサーバ
２、２Ａ  中継サーバ
３  ウェブクライアント
４  外部ウェブサーバ
５  インターネット
６  社内記憶装置
１１  サンドボックス
１２  記憶部
１３  検索部
１４  実行部
２１、３１  リクエスト受付部
２２  リクエスト解析部
２３  振分部
２４  アプリＩＤ登録部
２５  リクエスト転送部
２６  レスポンス受付部
２７  レスポンス解析部
２８  ＵＲＬ書換部
２９  アプリＩＤ付与部
３０  データアクセス判定部
３２  アプリＩＤ登録有無判定部
３３  リクエストキュー部
３４  プロセスＩＤ解析部
３５  アプリＩＤ検索部
３６  レスポンス転送部
６１  リクエスト受付部
４１  データ管理テーブル
４２、５１、５１Ａ  アプリ管理テーブル
【図１】
2013003598.tif 000003
【図２】
2013003598.tif 000004
【図３】
2013003598.tif 000005
【図４】
2013003598.tif 000006
【図５】
2013003598.tif 000007
【図６】
2013003598.tif 000008
【図７】
2013003598.tif 000009
【図８】
2013003598.tif 000010
【図９】
2013003598.tif 000011
【図１０】
2013003598.tif 000012
【図１１】
2013003598.tif 000013
【図１２】
2013003598.tif 000014
【図１３】
2013003598.tif 000015
【図１４】
2013003598.tif 000016
【図１５】
2013003598.tif 000017
【図１６】
2013003598.tif 000018
【図１７】
2013003598.tif 000019
【図１８】
2013003598.tif 000020
【図１９】
2013003598.tif 000021
【図２０】
2013003598.tif 000022
【図２１】
2013003598.tif 000023
【図２２】
2013003598.tif 000024