JP6574479B2 - リバースプロキシサーバ内のサービス - Google Patents

Description

関連出願
本願は、２０１５年４月２５日に出願された、「リバースプロキシサーバ内のサービス」（SERVICES WITHIN REVERSE PROXY SERVERS）と題された米国非仮出願第１４／６９６，４３２号の利益および優先権を主張し、当該非仮出願は、２０１４年９月２４日に出願された、「モバイルセキュリティアクセスサーバ（MOBILE SECURITY ACCESS SERVER：ＭＳＡＳ）」と題された米国仮特許出願第６２／０５４，６１３号の利益および優先権を主張する。上述の特許出願の内容全体は、あらゆる目的のために、ここに引用により援用される。

背景
この開示は一般に、コンピュータネットワークを通してセキュリティを提供するためのシステム、方法、およびコンピュータ読取可能媒体に関する。より特定的には、この開示は、クライアント装置とバックエンドウェブアプリケーションおよびサービスとの間に実装されたプロキシサーバで、セキュリティサービスおよび他の機能性を提供するためのシステム、方法、およびコンピュータ読取可能媒体に関する。そのようなセキュリティサービスは、とりわけ、認証、認可、監査、シングルサインオン、セキュリティポリシー実施、キー管理および分散、安全な通信、安全なデータ格納、および安全なデータ共有を含み得る。

簡単な概要
ここに説明される局面は、コンピュータネットワーク間で送信されるメッセージを処理するためのさまざまな手法を提供する。いくつかの実施形態では、クライアント装置からの、バックエンドウェブサービス、アプリケーション、および他のウェブコンテンツに対する要求といったメッセージが、複数のコンピュータネットワーク間で送信されてもよい。物理的または論理的サブネットワーク内に実装されたプロキシサーバといった、１つ以上の中間装置またはアプリケーションが、通信エンドポイント間でメッセージを受信し、処理し、送信してもよい。いくつかの実施形態では、リバースプロキシサーバが、リバースプロキシサーバ内にレプリゼンテーショナル・ステート・トランスファー（Representational State Transfer：ＲＥＳＴ）サービスおよびＲＥＳＴリソースを動的に生成するように構成されてもよい。リバースプロキシサーバ内のＲＥＳＴサービスおよびＲＥＳＴリソースは、クライアント装置からの着信要求を扱ってバックエンドウェブサービスを呼び出してもよく、それにより、リバースプロキシサーバ上のさまざまなセキュリティポリシーの設計抽象化および／または実施を可能にする。

ここに説明されるある局面によれば、プロキシサーバは、プロキシサーバ内のＲＥＳＴウェブサービスによって公開された特定のリソースに対するウェブサービス要求を受信してもよい。プロキシサーバにおけるＲＥＳＴウェブサービス内の適切なリソースが呼び出されてもよく、次にバックエンドウェブサービスを呼び出してもよい。場合によっては、リバースプロキシサーバは、さまざまなバックエンドウェブサービスを仮想化して不明瞭にする一組のＲＥＳＴウェブサービスを公開してもよい。たとえば、リバースプロキシサーバは、信頼できないネットワーク上のクライアント装置が基盤のバックエンドウェブサービスを読み取らないように、または当該バックエンドウェブサービスについての知識を持たないように、仮想ユニフォームリソースロケータ（uniform resource locator：ＵＲＬ）のみを公開してもよい。

ここに説明される追加の局面によれば、クライアント装置から受信されたＲＥＳＴ要求のうちのいくつかまたはすべてを扱うために、ＲＥＳＴサービスおよびＲＥＳＴリソースがリバースプロキシサーバ内に生成されてもよい。これらのＲＥＳＴサービス／リソースは、リバースプロキシサーバ内でＲＥＳＴ要求を扱うように、および／またはバックエンドウェブサービスの対応する組を呼び出すように、動的に生成され構成されてもよい。ＲＥＳＴウェブサービス／リソースを動的に生成し管理するために、ＲＥＳＴインフラストラクチャおよび／またはＲＥＳＴアプリケーションエンジンが、リバースプロキシサーバ内に実装されてもよい。加えて、いくつかの実施形態では、リバースプロキシサーバ内のＲＥＳＴリソースは、バックエンドウェブサービスコールを生成して、さまざまなポリシーを実施するためのポリシー実施エンジンに提供してもよい。

この発明のさまざまな実施形態が実現され得る例示的な分散型システムのコンポーネントを示すブロック図である。 この発明の実施形態によって提供されるサービスをクラウドサービスとして提供し得るシステム環境のコンポーネントを示すブロック図である。 この発明の実施形態が実現され得る例示的なコンピュータシステムを示すブロック図である。 この発明の１つ以上の実施形態に従った、コンピューティング装置および／またはシステム間でメッセージを処理して送信するためのリバースプロキシサーバを含むコンピューティング環境の例を、高レベルで示すブロック図である。 この発明の１つ以上の実施形態に従った、コンピューティング装置および／またはシステム間でメッセージを処理して送信するためのリバースプロキシサーバを含むコンピューティング環境の例を、高レベルで示すブロック図である。 この発明の１つ以上の実施形態に従った、ＲＥＳＴ要求を受信して処理するためのリバースプロキシサーバを、高レベルで示す別のブロック図である。 この発明の１つ以上の実施形態に従った、クライアント装置からＲＥＳＴ要求を受信して処理し受信して処理し、バックエンドウェブサービスを判断して呼び出すプロセスを示すフローチャートの一部である。 この発明の１つ以上の実施形態に従った、クライアント装置からＲＥＳＴ要求を受信して処理し受信して処理し、バックエンドウェブサービスを判断して呼び出すプロセスを示すフローチャートの一部である。 この発明の１つ以上の実施形態に従った、ＲＥＳＴサービスおよびＲＥＳＴリソースを動的に生成するためのリバースプロキシサーバを、高レベルで示す別のブロック図である。 この発明の１つ以上の実施形態に従った、ＲＥＳＴサービスおよびＲＥＳＴリソースをリバースプロキシサーバ上に生成し、構築し、デプロイメントするためのプロセスを示すフローチャートである。 この発明の１つ以上の実施形態に従った、ポリシー実施エンジンを含むリバースプロキシサーバを、高レベルで示す別のブロック図である。 この発明の１つ以上の実施形態に従った、判断されたメッセージ処理ポリシーを使用してメッセージを処理して送信するためのプロセスを示すフローチャートである。

詳細な説明
以下の記載では、説明の目的のため、多くの特定の詳細が、この発明のさまざまな実施形態の完全な理解を提供するために述べられる。しかしながら、これらの特定の詳細のうちのいくつかがなくてもこの発明の実施形態は実践され得る、ということは、当業者には明らかであろう。他の例では、周知の構造および装置は、ブロック図の形で示される。

以下の記載は例示的な実施形態のみを提供しており、この開示の範囲、利用可能性、または構成を限定するよう意図されてはいない。むしろ、例示的な実施形態の以下の記載は、例示的な実施形態を実現するための実施可能な説明を当業者に提供するであろう。添付された請求項で述べられるようなこの発明の精神および範囲から逸脱することなく、要素の機能および配置においてさまざまな変更が行なわれてもよい、ということが理解されるべきである。

以下の記載では、実施形態の完全な理解を提供するために、特定の詳細が与えられる。しかしながら、これらの特定の詳細がなくても実施形態は実践され得る、ということは、当業者には理解されるであろう。たとえば、実施形態を必要以上に詳細に記して不明瞭にすることがないように、回路、システム、ネットワーク、プロセス、および他のコンポーネントは、ブロック図の形のコンポーネントとして示されてもよい。他の例では、実施形態を不明瞭にしないように、周知の回路、プロセス、アルゴリズム、構造、および手法は、不要な詳細なしで示されてもよい。

また、個々の実施形態は、フローチャート、フロー図、データフロー図、構造図、またはブロック図として示されるプロセスとして説明され得ることに留意されたい。フローチャートは動作を順次プロセスとして説明し得るものの、動作の多くは並行してまたは同時に行なうことが可能である。加えて、動作の順序は並べ替えられてもよい。プロセスは、その動作が完了すると終了するが、図に含まれない追加のステップを有していてもよい。プロセスは、方法、機能、手順、サブルーチン、サブプログラムなどに対応していてもよい。プロセスがある機能に対応している場合、その終了は、その機能が呼出し元の機能または主機能に戻ることに対応可能である。

「コンピュータ読取可能媒体」という用語は、命令および／またはデータを格納し、含み、または担持することができる、携帯型または固定式記憶装置、光学記憶装置、ならびにさまざまな他の媒体といった非一時的媒体を含むものの、それらに限定されない。コードセグメントまたはコンピュータ実行可能命令が、手順、機能、サブプログラム、プログラム、ルーチン、サブルーチン、モジュール、ソフトウェアパッケージ、クラス、もしくは、命令、データ構造またはプログラム文の任意の組合せを表わしてもよい。コードセグメントは、情報、データ、引数、パラメータ、またはメモリ内容を渡し、および／または受信することによって、別のコードセグメントまたはハードウェア回路に結合されてもよい。情報、引数、パラメータ、データなどは、メモリ共有、メッセージパッシング、トークンパッシング、ネットワーク送信などを含む任意の好適な手段を介して渡され、発送され、または送信されてもよい。

さらに、実施形態は、ハードウェア、ソフトウェア、ファームウェア、ミドルウェア、マイクロコード、ハードウェア記述言語、またはそれらの任意の組合せによって実現されてもよい。ソフトウェア、ファームウェア、ミドルウェアまたはマイクロコードで実現される場合、必要なタスクを行なうためのプログラムコードまたはコードセグメントが、マシン読取可能媒体に格納されてもよい。プロセッサが、必要なタスクを行なってもよい。

コンピュータネットワーク間で送信されるメッセージを処理するために、さまざまな手法（たとえば、方法、システム、１つ以上のプロセッサによって実行可能な複数の命令を格納する非一時的なコンピュータ読取可能記憶メモリ、など）がここに説明される。いくつかの実施形態では、クライアント装置からの、バックエンドウェブサービス、アプリケーション、および他のウェブコンテンツに対する要求といったメッセージが、複数のコンピュータネットワーク間で送信されてもよい。物理的または論理的サブネットワーク内に実装されたプロキシサーバといった、１つ以上の中間装置またはアプリケーションが、通信エンドポイント間でメッセージを受信し、処理し、送信してもよい。いくつかの実施形態では、リバースプロキシサーバが、リバースプロキシサーバ内にレプリゼンテーショナル・ステート・トランスファー（ＲＥＳＴ）サービスおよびＲＥＳＴリソースを動的に生成するように構成されてもよい。リバースプロキシサーバ内のＲＥＳＴサービスおよびＲＥＳＴリソースは、クライアント装置からの着信要求を扱ってバックエンドウェブサービスを呼び出してもよく、それにより、リバースプロキシサーバ上のさまざまなセキュリティポリシーの設計抽象化および／または実施を可能にする。

いくつかの実施形態では、プロキシサーバは、プロキシサーバ内のＲＥＳＴウェブサービスによって公開された特定のリソースに対するウェブサービス要求を受信してもよい。プロキシサーバにおけるＲＥＳＴウェブサービス内の適切なリソースが呼び出されてもよく、次にバックエンドウェブサービスを呼び出してもよい。場合によっては、リバースプロキシサーバは、さまざまなバックエンドウェブサービスを仮想化して不明瞭にする一組のＲＥＳＴウェブサービスを公開してもよい。たとえば、リバースプロキシサーバは、信頼できないネットワーク上のクライアント装置が基盤のバックエンドウェブサービスを読み取らないように、または当該バックエンドウェブサービスについての知識を持たないように、仮想ユニフォームリソースロケータ（ＵＲＬ）のみを公開してもよい。追加の局面によれば、クライアント装置から受信されたＲＥＳＴ要求のうちのいくつかまたはすべてを扱うために、ＲＥＳＴサービスおよびＲＥＳＴリソースがリバースプロキシサーバ内に生成されてもよい。これらのＲＥＳＴサービス／リソースは、リバースプロキシサーバ内でＲＥＳＴ要求を扱うように、および／またはバックエンドウェブサービスの対応する組を呼び出すように、動的に生成され構成されてもよい。ＲＥＳＴウェブサービス／リソースを動的に生成し管理するために、ＲＥＳＴインフラストラクチャおよび／またはＲＥＳＴアプリケーションエンジンが、リバースプロキシサーバ内に実装されてもよい。加えて、ある実施形態では、リバースプロキシサーバ内のＲＥＳＴリソースは、バックエンドウェブサービスコールを生成して、さまざまなポリシーを実施するためのポリシー実施エンジンに提供してもよい。

図１は、この発明のさまざまな実施形態が実現され得る例示的な分散型システムのコンポーネントを示すブロック図である。図示された実施形態では、分散型システム１００は１つ以上のクライアントコンピューティング装置１０２、１０４、１０６、および１０８を含み、それらは、１つ以上のネットワーク１１０を通して、ウェブブラウザ、専用クライアント（たとえば、オラクル・フォームズ（Oracle Forms））などのクライアントアプリケーションを実行し、動作させるように構成される。サーバ１１２は、ネットワーク１１０を介して、リモートクライアントコンピューティング装置１０２、１０４、１０６、および１０８と通信可能に結合されてもよい。

さまざまな実施形態では、サーバ１１２は、システムのコンポーネントのうちの１つ以上によって提供される１つ以上のサービスまたはソフトウェアアプリケーションを実行するように適合されてもよい。いくつかの実施形態では、これらのサービスは、ウェブベースのサービスまたはクラウドサービスとして、もしくはソフトウェア・アズ・ア・サービス（Software as a Service：ＳａａＳ）モデルの下で、クライアントコンピューティング装置１０２、１０４、１０６、および／または１０８のユーザに提供されてもよい。クライアントコンピューティング装置１０２、１０４、１０６、および／または１０８を動作させるユーザは次に、これらのコンポーネントによって提供されるサービスを利用するためにサーバ１１２とやりとりするために、１つ以上のクライアントアプリケーションを利用してもよい。

図に示す構成では、システム１００のソフトウェアコンポーネント１１８、１２０および１２２は、サーバ１１２上で実現されるとして図示されている。他の実施形態では、システム１００のコンポーネントおよび／またはこれらのコンポーネントによって提供されるサービスのうちの１つ以上も、クライアントコンピューティング装置１０２、１０４、１０６、および／または１０８のうちの１つ以上によって実現されてもよい。クライアントコンピューティング装置を動作させるユーザは次に、これらのコンポーネントによって提供されるサービスを使用するために、１つ以上のクライアントアプリケーションを利用してもよい。これらのコンポーネントは、ハードウェア、ファームウェア、ソフトウェア、またはそれらの組合せで実現されてもよい。分散型システム１００とは異なり得るさまざまな異なるシステム構成が可能であることが理解されるべきである。図に示す実施形態はこのため、実施形態システムを実現するための分散型システムの一例であり、限定的であるよう意図されてはいない。

クライアントコンピューティング装置１０２、１０４、１０６、および／または１０８は、携帯型ハンドヘルド装置（たとえば、ｉＰｈｏｎｅ（登録商標）、携帯電話、ｉＰａｄ（登録商標）、コンピューティングタブレット、携帯情報端末（ＰＤＡ））、またはウェアラブル装置（たとえば、グーグル・グラス（Google Glass）（登録商標）頭部装着型ディスプレイ）であってもよく、マイクロソフト・ウィンドウズ・モバイル（Microsoft Windows Mobile）（登録商標）などのソフトウェア、および／または、ｉＯＳ、ウィンドウズ（登録商標）フォン、アンドロイド（登録商標）、ブラックベリー（登録商標）１０、パームＯＳなどのさまざまなモバイルオペレーティングシステムを実行し、インターネット、電子メール、ショートメッセージサービス（short message service：ＳＭＳ）、ブラックベリー（登録商標）、または他の通信プロトコルに対応している。クライアントコンピューティング装置は、マイクロソフト・ウィンドウズ（登録商標）、アップル・マッキントッシュ（登録商標）、および／またはＬｉｎｕｘ（登録商標）オペレーティングシステムのさまざまなバージョンを実行するパーソナルコンピュータおよび／またはラップトップコンピュータを例として含む、汎用パーソナルコンピュータであり得る。クライアントコンピューティング装置は、たとえばグーグル・クロームＯＳなどのさまざまなＧＮＵ／Ｌｉｎｕｘオペレーティングシステムを何ら限定されることなく含む、商業的に入手可能なさまざまなＵＮＩＸ（登録商標）またはＵＮＩＸ様オペレーティングシステムのうちのいずれかを実行するワークステーションコンピュータであり得る。それに代えて、またはそれに加えて、クライアントコンピューティング装置１０２、１０４、１０６、および１０８は、ネットワーク１１０を通して通信可能である、シンクライアントコンピュータ、インターネット対応ゲーミングシステム（たとえば、Ｋｉｎｅｃｔ（登録商標）ジェスチャー入力装置を有する、または有さない、マイクロソフトＸｂｏｘゲーミングコンソール）、および／またはパーソナルメッセージング装置といった、任意の他の電子装置であってもよい。

例示的な分散型システム１００は４つのクライアントコンピューティング装置を有して図示されているが、任意の数のクライアントコンピューティング装置がサポートされてもよい。センサを有する装置などの他の装置が、サーバ１１２とやりとりしてもよい。

分散型システム１００におけるネットワーク１１０は、ＴＣＰ／ＩＰ（transmission control protocol/Internet protocol：伝送制御プロトコル／インターネットプロトコル）、ＳＮＡ（systems network architecture：システムネットワークアーキテクチャ）、ＩＰＸ（Internet packet exchange：インターネットパケット交換）、アップル・トーク（Apple Talk）などを何ら限定されることなく含む、商業的に入手可能なさまざまなプロトコルのうちのいずれかを使用してデータ通信をサポートできる、当業者にはよく知られた任意のタイプのネットワークであってもよい。単なる例として、ネットワーク１１０は、イーサネット（登録商標）、トークンリング（Token-Ring）などに基づくものといった、ローカルエリアネットワーク（local area network：ＬＡＮ）であり得る。ネットワーク１１０は、ワイドエリアネットワークおよびインターネットであり得る。それは、仮想プライベートネットワーク（virtual private network：ＶＰＮ）を何ら限定されることなく含む仮想ネットワーク、イントラネット、エクストラネット、公衆交換電話網（public switched telephone network：ＰＳＴＮ）、赤外線ネットワーク、無線ネットワーク（たとえば、電気電子技術者協会（the Institute of Electrical and Electronics：ＩＥＥＥ）８０２．１１プロトコルスイート、Bluetooth（登録商標）、および／または任意の他の無線プロトコルのうちのいずれかの下で動作するネットワーク）、ならびに／もしくは、これらのおよび／または他のネットワークの任意の組合せを含み得る。

サーバ１１２は、１つ以上の汎用コンピュータ、専用サーバコンピュータ（ＰＣ（パーソナルコンピュータ）サーバ、ＵＮＩＸ（登録商標）サーバ、ミッドレンジサーバ、メインフレームコンピュータ、ラックマウントサーバなどを例として含む）、サーバファーム、サーバクラスタ、もしくは任意の他の適切な構成および／または組合せで構成されてもよい。さまざまな実施形態では、サーバ１１２は、前述の開示で説明された１つ以上のサービスまたはソフトウェアアプリケーションを実行するように適合されてもよい。たとえば、サーバ１１２は、この開示の一実施形態に従った上述の処理を行なうためのサーバに対応していてもよい。

サーバ１１２は、上述のもののうちのいずれかを含むオペレーティングシステム、および商業的に入手可能な任意のサーバオペレーティングシステムを実行してもよい。サーバ１１２はまた、さまざまな追加のサーバアプリケーションおよび／または中間層アプリケーションのうちのいずれかを実行してもよく、ＨＴＴＰ（hypertext transport protocol：ハイパーテキスト伝送プロトコル）サーバ、ＦＴＰ（file transfer protocol：ファイル転送プロトコル）サーバ、ＣＧＩ（common gateway interface：コモンゲートウェイインターフェイス）サーバ、ＪＡＶＡ（登録商標）サーバ、データベースサーバなどを含む。例示的なデータベースサーバは、オラクル、マイクロソフト、サイベース（Sybase）、ＩＢＭ（International Business Machines：インターナショナル・ビジネス・マシーンズ）などから商業的に入手可能なものを何ら限定されることなく含む。

いくつかの実現化例では、サーバ１１２は、クライアントコンピューティング装置１０２、１０４、１０６、および１０８のユーザから受信されたデータフィードおよび／またはイベント更新を分析して統合するための１つ以上のアプリケーションを含んでいてもよい。一例として、データフィードおよび／またはイベント更新は、センサデータアプリケーション、金融ティッカー、ネットワーク性能測定ツール（たとえば、ネットワーク監視およびトラフィック管理アプリケーション）、クリックストリーム分析ツール、自動車交通監視などに関連するリアルタイムイベントを含み得る、１つ以上の第三者情報源および連続データストリームから受信されたツイッター（登録商標）フィード、フェースブック（登録商標）更新またはリアルタイム更新を含んでいてもよいが、それらに限定されない。サーバ１１２はまた、クライアントコンピューティング装置１０２、１０４、１０６、および１０８の１つ以上の表示装置を介してデータフィードおよび／またはリアルタイムイベントを表示するための１つ以上のアプリケーションを含んでいてもよい。

分散型システム１００はまた、１つ以上のデータベース１１４および１１６を含んでいてもよい。データベース１１４および１１６は、さまざまな位置に存在していてもよい。例として、データベース１１４および１１６のうちの１つ以上は、サーバ１１２に対してローカルな（および／または、サーバ１１２内にある）非一時的記憶媒体上に存在していてもよい。それに代えて、データベース１１４および１１６は、サーバ１１２からリモートであってもよく、ネットワークベースの接続または専用接続を介してサーバ１１２と通信してもよい。一組の実施形態では、データベース１１４および１１６は、ストレージエリアネットワーク（storage-area network：ＳＡＮ）に存在していてもよい。同様に、サーバ１１２に帰する機能を行なうための任意の必要なファイルが適宜、サーバ１１２上にローカルに格納されてもよく、および／またはリモートに格納されてもよい。一組の実施形態では、データベース１１４および１１６は、ＳＱＬフォーマットのコマンドに応答してデータを格納し、更新し、検索するように適合された、オラクルによって提供されるデータベースなどのリレーショナルデータベースを含んでいてもよい。

図２は、この発明の実施形態によって提供されるサービスをクラウドサービスとして提供し得るシステム環境のコンポーネントを示すブロック図である。図示された実施形態では、システム環境２００は、クラウドサービスを提供するクラウドインフラストラクチャシステム２０２とやりとりするためにユーザによって使用され得る１つ以上のクライアントコンピューティング装置２０４、２０６、および２０８を含む。クライアントコンピューティング装置は、クラウドインフラストラクチャシステム２０２によって提供されるサービスを使用するためにクラウドインフラストラクチャシステム２０２とやりとりするためにクライアントコンピューティング装置のユーザによって使用され得る、ウェブブラウザ、専用クライアントアプリケーション（たとえば、オラクル・フォームズ）、または何らかの他のアプリケーションといったクライアントアプリケーションを動作させるように構成されてもよい。

図に示すクラウドインフラストラクチャシステム２０２は、図示されたもの以外のコンポーネントを有していてもよい、ということが理解されるべきである。また、図に示す実施形態は、この発明の一実施形態を取入れ得るクラウドインフラストラクチャシステムの単なる一例である。いくつかの他の実施形態では、クラウドインフラストラクチャシステム２０２は、図に示すものよりも多い、または少ないコンポーネントを有していてもよく、２つ以上のコンポーネントを組合せてもよく、もしくは、異なる構成または配置のコンポーネントを有していてもよい。

クライアントコンピューティング装置２０４、２０６、および２０８は、１０２、１０４、１０６、および１０８について上述したものと同様の装置であってもよい。

例示的なシステム環境２００は３つのクライアントコンピューティング装置を有して図示されているが、任意の数のクライアントコンピューティング装置がサポートされてもよい。センサを有する装置などの他の装置が、クラウドインフラストラクチャシステム２０２とやりとりしてもよい。

ネットワーク２１０は、クライアント２０４、２０６、および２０８とクラウドインフラストラクチャシステム２０２との間のデータの通信および交換を容易にしてもよい。各ネットワークは、ネットワーク１１０について上述したものを含む、商業的に入手可能なさまざまなプロトコルのうちのいずれかを使用してデータ通信をサポートできる、当業者にはよく知られた任意のタイプのネットワークであってもよい。

クラウドインフラストラクチャシステム２０２は、サーバ１１２について上述したものを含み得る１つ以上のコンピュータおよび／またはサーバを含んでいてもよい。

ある実施形態では、クラウドインフラストラクチャシステムによって提供されるサービスは、オンラインデータストレージおよびバックアップソリューション、ウェブベースの電子メールサービス、ホスト型オフィススイートおよび文書コラボレーションサービス、データベース処理、管理された技術サポートサービスといった、クラウドインフラストラクチャシステムのユーザにとってオンデマンドで利用可能にされる多数のサービスを含んでいてもよい。クラウドインフラストラクチャシステムによって提供されるサービスは、そのユーザの必要性を満たすために動的にスケール変更され得る。クラウドインフラストラクチャシステムによって提供されるサービスの特定のインスタンス化は、ここに「サービスインスタンス」と呼ばれる。一般に、クラウドサービスプロバイダのシステムから、インターネットなどの通信ネットワークを介してユーザに利用可能とされる任意のサービスは、「クラウドサービス」と呼ばれる。典型的には、パブリッククラウド環境では、クラウドサービスプロバイダのシステムを作り上げるサーバおよびシステムは、顧客自身の業務用サーバおよびシステムとは異なっている。たとえば、クラウドサービスプロバイダのシステムは、アプリケーションをホストしてもよく、ユーザは、インターネットなどの通信ネットワークを介してオンデマンドでアプリケーションをオーダーし、使用してもよい。

いくつかの例では、コンピュータネットワーククラウドインフラストラクチャにおけるサービスは、クラウドベンダーによってユーザに提供されるかまたは当該技術分野において他の態様で公知であるようなストレージ、ホスト型データベース、ホスト型ウェブサーバ、ソフトウェアアプリケーション、もしくは他のサービスへの、保護されたコンピュータネットワークアクセスを含んでいてもよい。たとえば、サービスは、インターネットを通した、クラウド上のリモートストレージへの、パスワードで保護されたアクセスを含み得る。別の例として、サービスは、ネットワーク化された開発者による私的使用のための、ウェブサービスベースのホスト型リレーショナルデータベースおよびスクリプト言語ミドルウェアエンジンを含み得る。別の例として、サービスは、クラウドベンダーのウェブサイト上でホストされる電子メールソフトウェアアプリケーションへのアクセスを含み得る。

ある実施形態では、クラウドインフラストラクチャシステム２０２は、セルフサービスで、サブスクリプションベースで、弾力的にスケーラブルで、信頼でき、高可用性で、かつ安全な態様で顧客に配信される、アプリケーション、ミドルウェアおよびデータベースサービス提供物一式を含んでいてもよい。そのようなクラウドインフラストラクチャシステムの一例は、本譲受人によって提供されるオラクル・パブリック・クラウド（Oracle Public Cloud）である。

さまざまな実施形態では、クラウドインフラストラクチャシステム２０２は、クラウドインフラストラクチャシステム２０２によって提供されるサービスに顧客のサブスクリプションを自動的にプロビジョニングし、管理し、追跡するように適合されてもよい。クラウドインフラストラクチャシステム２０２は、異なるデプロイメントモデルを介してクラウドサービスを提供してもよい。たとえば、サービスは、クラウドインフラストラクチャシステム２０２がクラウドサービスを販売する組織によって所有され（たとえば、オラクルによって所有され）、サービスが一般大衆または異なる産業企業にとって利用可能とされる、パブリッククラウドモデルの下で提供されてもよい。別の例として、サービスは、クラウドインフラストラクチャシステム２０２が単一の組織のためにのみ動作され、その組織内の１つ以上のエンティティのためのサービスを提供し得る、プライベートクラウドモデルの下で提供されてもよい。クラウドサービスはまた、クラウドインフラストラクチャシステム２０２、およびクラウドインフラストラクチャシステム２０２によって提供されるサービスが、関連するコミュニティにおけるいくつかの組織によって共有される、コミュニティクラウドモデルの下で提供されてもよい。クラウドサービスはまた、２つ以上の異なるモデルの組合せであるハイブリッドクラウドモデルの下で提供されてもよい。

いくつかの実施形態では、クラウドインフラストラクチャシステム２０２によって提供されるサービスは、ソフトウェア・アズ・ア・サービス（ＳａａＳ）カテゴリー、プラットフォーム・アズ・ア・サービス（Platform as a Service：ＰａａＳ）カテゴリー、インフラストラクチャ・アズ・ア・サービス（Infrastructure as a Service：ＩａａＳ）カテゴリー、または、ハイブリッドサービスを含むサービスの他のカテゴリーの下で提供される、１つ以上のサービスを含んでいてもよい。顧客は、クラウドインフラストラクチャシステム２０２によって提供される１つ以上のサービスを、サブスクリプションオーダーを介してオーダーしてもよい。クラウドインフラストラクチャシステム２０２は次に、顧客のサブスクリプションオーダーにおけるサービスを提供するために処理を行なう。

いくつかの実施形態では、クラウドインフラストラクチャシステム２０２によって提供されるサービスは、アプリケーションサービス、プラットフォームサービス、およびインフラストラクチャサービスを、何ら限定されることなく含んでいてもよい。いくつかの例では、アプリケーションサービスは、ＳａａＳプラットフォームを介して、クラウドインフラストラクチャシステムによって提供されてもよい。ＳａａＳプラットフォームは、ＳａａＳカテゴリーに該当するクラウドサービスを提供するように構成されてもよい。たとえば、ＳａａＳプラットフォームは、統合された開発およびデプロイメントプラットフォーム上にオンデマンドアプリケーション一式を構築し、配信するための能力を提供してもよい。ＳａａＳプラットフォームは、ＳａａＳサービスを提供するための基本ソフトウェアおよびインフラストラクチャを管理し、制御してもよい。ＳａａＳプラットフォームによって提供されるサービスを利用することにより、顧客は、クラウドインフラストラクチャシステム上で実行されるアプリケーションを利用できる。顧客は、顧客が別々のライセンスおよびサポートを購入する必要なく、アプリケーションサービスを取得できる。さまざまな異なるＳａａＳサービスが提供されてもよい。例は、大型組織のための販売実績管理、企業統合、およびビジネス柔軟性についてのソリューションを提供するサービスを、何ら限定されることなく含む。

いくつかの実施形態では、プラットフォームサービスは、ＰａａＳプラットフォームを介して、クラウドインフラストラクチャシステムによって提供されてもよい。ＰａａＳプラットフォームは、ＰａａＳカテゴリーに該当するクラウドサービスを提供するように構成されてもよい。プラットフォームサービスの例は、（オラクルなどの）組織が共有の共通アーキテクチャ上で既存のアプリケーションを統合できるようにするサービスと、プラットフォームによって提供される共有のサービスを活用する新しいアプリケーションを構築するための能力とを、何ら限定されることなく含んでいてもよい。ＰａａＳプラットフォームは、ＰａａＳサービスを提供するための基本ソフトウェアおよびインフラストラクチャを管理し、制御してもよい。顧客は、顧客が別々のライセンスおよびサポートを購入する必要なく、クラウドインフラストラクチャシステムによって提供されるＰａａＳサービスを取得できる。プラットフォームサービスの例は、オラクルＪａｖａ（登録商標）クラウドサービス（Java Cloud Service：ＪＣＳ）、オラクル・データベース・クラウド・サービス（Database Cloud Service：ＤＢＣＳ）などを、何ら限定されることなく含む。

ＰａａＳプラットフォームによって提供されるサービスを利用することにより、顧客は、クラウドインフラストラクチャシステムによってサポートされるプログラミング言語およびツールを採用するとともに、デプロイメントされたサービスを制御することができる。いくつかの実施形態では、クラウドインフラストラクチャシステムによって提供されるプラットフォームサービスは、データベースクラウドサービス、ミドルウェアクラウドサービス（たとえば、オラクル・フュージョン・ミドルウェア（Oracle Fusion Middleware）サービス）、およびＪａｖａクラウドサービスを含んでいてもよい。一実施形態では、データベースクラウドサービスは、組織がデータベースリソースをプールし、データベースクラウドの形をしたデータベース・アズ・ア・サービスを顧客に提供することを可能にする共有のサービスデプロイメントモデルをサポートしてもよい。ミドルウェアクラウドサービスは、顧客がさまざまなビジネスアプリケーションを開発してデプロイメントするためのプラットフォームを提供してもよく、Ｊａｖａクラウドサービスは、顧客がクラウドインフラストラクチャシステムにおいてＪａｖａアプリケーションをデプロイメントするためのプラットフォームを提供してもよい。

クラウドインフラストラクチャシステムにおいて、さまざまな異なるインフラストラクチャサービスが、ＩａａＳプラットフォームによって提供されてもよい。これらのインフラストラクチャサービスは、ＳａａＳプラットフォームおよびＰａａＳプラットフォームによって提供されるサービスを利用する顧客のための、ストレージ、ネットワーク、ならびに他の基礎的コンピューティングリソースなどの基本コンピューティングリソースの管理および制御を容易にする。

ある実施形態では、クラウドインフラストラクチャシステム２０２はまた、クラウドインフラストラクチャシステムの顧客にさまざまなサービスを提供するために使用されるリソースを提供するためのインフラストラクチャリソース２３０を含んでいてもよい。一実施形態では、インフラストラクチャリソース２３０は、ＰａａＳプラットフォームおよびＳａａＳプラットフォームによって提供されるサービスを実行するために、サーバ、ストレージ、およびネットワーキングリソースなどのハードウェアの予め統合され最適化された組合せを含んでいてもよい。

いくつかの実施形態では、クラウドインフラストラクチャシステム２０２におけるリソースは、複数のユーザによって共有され、要望ごとに動的に再割当てされてもよい。加えて、リソースは、異なる時間帯におけるユーザに割当てられてもよい。たとえば、クラウドインフラストラクチャシステム２３０は、第１の時間帯における第１の一組のユーザが、特定数の時間、クラウドインフラストラクチャシステムのリソースを利用することを可能にし、次に、異なる時間帯に位置する別の一組のユーザへの同じリソースの再割当てを可能にして、それによりリソースの利用を最大化してもよい。

ある実施形態では、クラウドインフラストラクチャシステム２０２の異なるコンポーネントまたはモジュールによって、およびクラウドインフラストラクチャシステム２０２によって提供されるサービスによって共有される、多くの内部共有サービス２３２が提供されてもよい。これらの内部共有サービスは、セキュリティおよびアイデンティティサービス、統合サービス、企業リポジトリサービス、企業マネージャサービス、ウィルススキャニングおよびホワイトリストサービス、高可用性、バックアップおよび復元サービス、クラウドサポートを可能にするためのサービス、電子メールサービス、通知サービス、ファイル転送サービスなどを、何ら限定されることなく含んでいてもよい。

ある実施形態では、クラウドインフラストラクチャシステム２０２は、クラウドインフラストラクチャシステムにおけるクラウドサービス（たとえば、ＳａａＳ、ＰａａＳ、およびＩａａＳサービス）の包括的管理を提供してもよい。一実施形態では、クラウド管理機能性は、クラウドインフラストラクチャシステム２０２によって受信された顧客のサブスクリプションをプロビジョニングし、管理し、追跡するための能力などを含んでいてもよい。

一実施形態では、図に示すように、クラウド管理機能性は、オーダー管理モジュール２２０、オーダーオーケストレーションモジュール２２２、オーダープロビジョニングモジュール２２４、オーダー管理および監視モジュール２２６、ならびにアイデンティティ管理モジュール２２８などの１つ以上のモジュールによって提供されてもよい。これらのモジュールは、汎用コンピュータ、専用サーバコンピュータ、サーバファーム、サーバクラスタ、もしくは任意の他の適切な構成および／または組合せであり得る、１つ以上のコンピュータおよび／またはサーバを含んでいてもよく、もしくはそれらを使用して提供されてもよい。

例示的な動作２３４では、クライアント装置２０４、２０６または２０８などのクライアント装置を使用する顧客は、クラウドインフラストラクチャシステム２０２によって提供される１つ以上のサービスを要求し、クラウドインフラストラクチャシステム２０２によって提供される１つ以上のサービスについてサブスクリプションオーダーを出すことにより、クラウドインフラストラクチャシステム２０２とやりとりしてもよい。ある実施形態では、顧客は、クラウドユーザインターフェイス（User Interface：ＵＩ）であるクラウドＵＩ２１２、クラウドＵＩ２１４および／またはクラウドＵＩ２１６にアクセスし、これらのＵＩを介してサブスクリプションオーダーを出してもよい。顧客がオーダーを出したことに応答してクラウドインフラストラクチャシステム２０２が受信したオーダー情報は、顧客と、顧客が申し込むつもりである、クラウドインフラストラクチャシステム２０２によって提供される１つ以上のサービスとを識別する情報を含んでいてもよい。

顧客によってオーダーが出された後で、オーダー情報がクラウドＵＩ２１２、２１４および／または２１６を介して受信される。

動作２３６で、オーダーがオーダーデータベース２１８に格納される。オーダーデータベース２１８は、クラウドインフラストラクチャシステム２１８によって動作され、他のシステム要素とともに動作される、いくつかのデータベースのうちの１つであり得る。

動作２３８で、オーダー情報はオーダー管理モジュール２２０に発送される。場合によっては、オーダー管理モジュール２２０は、オーダーを検証し、検証後にオーダーを予約するといった、オーダーに関連する請求および課金機能を行なうように構成されてもよい。

動作２４０で、オーダーに関する情報がオーダーオーケストレーションモジュール２２２に通信される。オーダーオーケストレーションモジュール２２２は、顧客によって出されたオーダーのためのサービスおよびリソースのプロビジョニングをオーケストレーションするために、オーダー情報を利用してもよい。場合によっては、オーダーオーケストレーションモジュール２２２は、オーダープロビジョニングモジュール２２４のサービスを使用して、申し込まれたサービスをサポートするようにリソースのプロビジョニングをオーケストレーションしてもよい。

ある実施形態では、オーダーオーケストレーションモジュール２２２は、各オーダーに関連付けられたビジネスプロセスの管理を可能にし、オーダーがプロビジョニングに進むべきか否かを判断するためにビジネス論理を適用する。動作２４２で、新規サブスクリプションのオーダーを受信すると、オーダーオーケストレーションモジュール２２２は、リソースを割当ててサブスクリプションオーダーを遂行するために必要とされるリソースを構成するようにという要求を、オーダープロビジョニングモジュール２２４に送信する。オーダープロビジョニングモジュール２２４は、顧客によってオーダーされたサービスのためのリソースの割当てを可能にする。オーダープロビジョニングモジュール２２４は、クラウドインフラストラクチャシステム２００によって提供されるクラウドサービスと、要求されたサービスを提供するためのリソースをプロビジョニングするために使用される物理的実装層との間の抽象化のレベルを提供する。オーダーオーケストレーションモジュール２２２はこのため、サービスおよびリソースが実際にオンザフライでプロビジョニングされるか否か、または予めプロビジョニングされて要求時にのみ割当てられるか否かといった実装詳細から切り離されてもよい。

動作２４４で、サービスおよびリソースが一旦プロビジョニングされると、提供されるサービスの通知が、クラウドインフラストラクチャシステム２０２のオーダープロビジョニングモジュール２２４によって、クライアント装置２０４、２０６および／または２０８上の顧客に送信されてもよい。

動作２４６で、顧客のサブスクリプションオーダーが、オーダー管理および監視モジュール２２６によって管理され、追跡されてもよい。場合によっては、オーダー管理および監視モジュール２２６は、使用されるストレージの量、転送されるデータの量、ユーザの数、システムアップタイムおよびシステムダウンタイムの量といった、サブスクリプションオーダーにおけるサービスについての使用統計を収集するように構成されてもよい。

ある実施形態では、クラウドインフラストラクチャシステム２００は、アイデンティティ管理モジュール２２８を含んでいてもよい。アイデンティティ管理モジュール２２８は、クラウドインフラストラクチャシステム２００においてアクセス管理および認証サービスなどのアイデンティティサービスを提供するように構成されてもよい。いくつかの実施形態では、アイデンティティ管理モジュール２２８は、クラウドインフラストラクチャシステム２０２によって提供されるサービスを利用したい顧客についての情報を制御してもよい。そのような情報は、そのような顧客のアイデンティティを認証する情報と、さまざまなシステムリソース（たとえば、ファイル、ディレクトリ、アプリケーション、通信ポート、メモリセグメントなど）に対してそれらの顧客がどのアクションを行なうことが認可されているかを記述する情報とを含み得る。アイデンティティ管理モジュール２２８はまた、各顧客についての記述的情報と、その記述的情報が誰によってどのようにアクセスされ、修正され得るかについての記述的情報との管理を含んでいてもよい。

図３は、この発明の実施形態が実現され得る例示的なコンピュータシステムを示すブロック図である。システム３００は、上述のコンピュータシステムのうちのいずれかを実現するために使用されてもよい。図に示すように、コンピュータシステム３００は、バスサブシステム３０２を介して多くの周辺サブシステムと通信する処理部３０４を含む。これらの周辺サブシステムは、処理加速部３０６と、Ｉ／Ｏサブシステム３０８と、記憶サブシステム３１８と、通信サブシステム３２４とを含んでいてもよい。記憶サブシステム３１８は、有形のコンピュータ読取可能記憶媒体３２２と、システムメモリ３１０とを含む。

バスサブシステム３０２は、コンピュータシステム３００のさまざまなコンポーネントおよびサブシステムを意図されるように互いに通信させるためのメカニズムを提供する。バスサブシステム３０２は単一のバスとして概略的に図示されているが、バスサブシステムの代替的な実施形態は複数のバスを利用してもよい。バスサブシステム３０２は、さまざまなバスアーキテクチャのうちのいずれかを使用するメモリバスまたはメモリコントローラ、周辺バス、およびローカルバスを含む、いくつかのタイプのバス構造のうちのいずれかであってもよい。たとえば、そのようなアーキテクチャは、ＩＥＥＥ Ｐ１３８６．１規格で製造されるメザニンバスとして実現可能な、産業標準アーキテクチャ（Industry Standard Architecture：ＩＳＡ）バス、マイクロチャネルアーキテクチャ（Micro Channel Architecture：ＭＣＡ）バス、強化ＩＳＡ（ＥＩＳＡ）バス、ビデオエレクトロニクス標準組織（Video Electronics Standards Association：ＶＥＳＡ）ローカルバス、および周辺コンポーネント相互接続（Peripheral Component Interconnect：ＰＣＩ）バスを含んでいてもよい。

１つ以上の集積回路（たとえば、従来のマイクロプロセッサまたはマイクロコントローラ）として実現され得る処理部３０４は、コンピュータシステム３００の動作を制御する。処理部３０４には、１つ以上のプロセッサが含まれていてもよい。これらのプロセッサは、シングルコアまたはマルチコアプロセッサを含んでいてもよい。ある実施形態では、処理部３０４は、各処理部にシングルまたはマルチコアプロセッサが含まれた、１つ以上の独立した処理部３３２および／または３３４として実現されてもよい。他の実施形態では、処理部３０４はまた、２つのデュアルコアプロセッサをシングルチップへと集積することによって形成されるクアッドコア処理部として実現されてもよい。

さまざまな実施形態では、処理部３０４は、プログラムコードに応答してさまざまなプログラムを実行でき、同時に実行される複数のプログラムまたはプロセスを維持できる。任意の所与の時間において、実行されるべきプログラムコードのうちのいくつかまたはすべては、プロセッサ３０４に、および／または記憶サブシステム３１８にあり得る。好適なプログラミングを通して、プロセッサ３０４は、上述のさまざまな機能性を提供できる。コンピュータシステム３００は加えて処理加速部３０６を含んでいてもよく、それは、デジタル信号プロセッサ（digital signal processor：ＤＳＰ）、専用プロセッサなどを含み得る。

Ｉ／Ｏサブシステム３０８は、ユーザインターフェイス入力装置と、ユーザインターフェイス出力装置とを含んでいてもよい。ユーザインターフェイス入力装置は、キーボード、マウスまたはトラックボールなどのポインティング装置、ディスプレイに組込まれたタッチパッドまたはタッチスクリーン、スクロールホイール、クリックホイール、ダイヤル、ボタン、スイッチ、キーパッド、音声コマンド認識システム付き音声入力装置、マイクロホン、および他のタイプの入力装置を含んでいてもよい。ユーザインターフェイス入力装置は、たとえば、ジェスチャーおよび口頭コマンドを使用したナチュラルユーザインターフェイスを通して、マイクロソフトＸｂｏｘ（登録商標）３６０ゲームコントローラなどの入力装置をユーザが制御し、それとやりとりすることを可能にする、マイクロソフトＫｉｎｅｃｔ（登録商標）運動センサなどの運動感知および／またはジェスチャー認識装置を含んでいてもよい。ユーザインターフェイス入力装置はまた、ユーザから目の活動（たとえば、写真撮影中および／またはメニュー選択中の「まばたき」）を検出し、アイジェスチャーを入力装置（たとえば、グーグル・グラス（登録商標））への入力として変換する、グーグル・グラス（登録商標）まばたき検出器などのアイジェスチャー認識装置を含んでいてもよい。加えて、ユーザインターフェイス入力装置は、ユーザが音声コマンドを通して音声認識システム（たとえば、Ｓｉｒｉ（登録商標）ナビゲータ）とやりとりできるようにする音声認識感知装置を含んでいてもよい。

ユーザインターフェイス入力装置はまた、３次元（３Ｄ）マウス、ジョイスティックまたはポインティングスティック、ゲームパッドおよびグラフィックタブレット、ならびに、スピーカ、デジタルカメラ、デジタルビデオカメラ、携帯型メディアプレイヤー、ウェブカメラ、画像スキャナ、指紋スキャナ、バーコードリーダ３Ｄスキャナ、３Ｄプリンタ、レーザー測距器、および視線追跡装置などの音声／視覚装置を、何ら限定されることなく含んでいてもよい。加えて、ユーザインターフェイス入力装置は、たとえば、コンピュータ断層撮影装置、磁気共鳴撮像装置、ポジトロン放出断層撮影装置、医療用超音波検査装置などの医療用撮像入力装置を含んでいてもよい。ユーザインターフェイス入力装置はまた、たとえば、ＭＩＤＩキーボード、デジタル楽器などの音声入力装置を含んでいてもよい。

ユーザインターフェイス出力装置は、表示サブシステム、表示灯、または、音声出力装置などの非視覚的ディスプレイを含んでいてもよい。表示サブシステムは、陰極線管（cathode ray tube：ＣＲＴ）、液晶ディスプレイ（liquid crystal display：ＬＣＤ）またはプラズマディスプレイを使用するものなどのフラットパネル装置、投影装置、タッチスクリーンなどであってもよい。一般に、「出力装置」という用語の使用は、コンピュータシステム３００からユーザまたは他のコンピュータに情報を出力するためのあらゆる可能なタイプの装置およびメカニズムを含むよう意図されている。たとえば、ユーザインターフェイス出力装置は、モニタ、プリンタ、スピーカ、ヘッドホン、自動車ナビゲーションシステム、プロッタ、音声出力装置、およびモデムといった、テキスト、グラフィックスおよび音声／映像情報を視覚的に伝えるさまざまな表示装置を、何ら限定されることなく含んでいてもよい。

コンピュータシステム３００は、現在システムメモリ３１０内に位置するとして図示されたソフトウェア要素を含む記憶サブシステム３１８を含んでいてもよい。システムメモリ３１０は、処理部３０４上でロード可能および実行可能なプログラム命令と、これらのプログラムの実行中に生成されたデータとを格納してもよい。

コンピュータシステム３００の構成およびタイプに依存して、システムメモリ３１０は揮発性（ランダムアクセスメモリ（random access memory：ＲＡＭ）など）であってもよく、および／または不揮発性（読出専用メモリ（read-only memory：ＲＯＭ）、フラッシュメモリなど）であってもよい。ＲＡＭは典型的には、処理部３０４に直ちにアクセス可能であり、および／または処理部３０４によって現在動作および実行中のデータおよび／またはプログラムモジュールを含む。いくつかの実現化例では、システムメモリ３１０は、スタティックランダムアクセスメモリ（static random access memory：ＳＲＡＭ）またはダイナミックランダムアクセスメモリ（dynamic random access memory：ＤＲＡＭ）などの複数の異なるタイプのメモリを含んでいてもよい。いくつかの実現化例では、起動中などにコンピュータシステム３００内の要素間で情報を転送するのに役立つ基本ルーチンを含む基本入力／出力システム（basic input/output system：ＢＩＯＳ）が、典型的にはＲＯＭに格納されていてもよい。限定のためではなく例として、システムメモリ３１０はまた、クライアントアプリケーション、ウェブブラウザ、中央層アプリケーション、リレーショナルデータベース管理システム（relational database management system：ＲＤＢＭＳ）などを含み得るアプリケーションプログラム３１２と、プログラムデータ３１４と、オペレーティングシステム３１６とを示す。例として、オペレーティングシステム３１６は、マイクロソフト・ウィンドウズ（登録商標）、アップル・マッキントッシュ（登録商標）、および／またはＬｉｎｕｘオペレーティングシステムのさまざまなバージョン、商業的に入手可能なさまざまなＵＮＩＸ（登録商標）またはＵＮＩＸ様オペレーティングシステム（さまざまなＧＮＵ／Ｌｉｎｕｘオペレーティングシステム、グーグル・クローム（登録商標）ＯＳなどを何ら限定されることなく含む）、および／または、ｉＯＳ、ウィンドウズ（登録商標）フォン、アンドロイド（登録商標）ＯＳ、ブラックベリー（登録商標）１０ＯＳ、パーム（登録商標）ＯＳオペレーティングシステムなどのモバイルオペレーティングシステムを含んでいてもよい。

記憶サブシステム３１８はまた、いくつかの実施形態の機能性を提供する基本プログラミングおよびデータ構造を格納するための有形のコンピュータ読取可能記憶媒体を提供してもよい。プロセッサによって実行されると上述の機能性を提供するソフトウェア（プログラム、コードモジュール、命令）が、記憶サブシステム３１８に格納されてもよい。これらのソフトウェアモジュールまたは命令は、処理部３０４によって実行されてもよい。記憶サブシステム３１８はまた、この発明に従って使用されるデータを格納するためのリポジトリを提供してもよい。

記憶サブシステム３００はまた、コンピュータ読取可能記憶媒体３２２にさらに接続され得るコンピュータ読取可能記憶媒体リーダ３２０を含んでいてもよい。システムメモリ３１０とともに、およびオプションでシステムメモリ３１０と組合わされて、コンピュータ読取可能記憶媒体３２２は、リモート、ローカル、固定および／またはリムーバブルの記憶装置に加えて、コンピュータ読取可能情報を一時的におよび／またはより永続的に含み、格納し、送信し、検索するための記憶媒体を包括的に表わしてもよい。

コードまたはコードの一部を含むコンピュータ読取可能記憶媒体３２２はまた、情報の格納および／または送信のためのあらゆる方法または技術で実現される揮発性および不揮発性でリムーバブルおよび非リムーバブルの媒体を含むがそれらに限定されない記憶媒体および通信媒体を含む、当該技術分野において公知であるかまたは使用されるあらゆる適切な媒体を含み得る。これは、ＲＡＭ、ＲＯＭ、電子的消去可能プログラマブルＲＯＭ（electronically erasable programmable ROM：ＥＥＰＲＯＭ）、フラッシュメモリまたは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（digital versatile disk：ＤＶＤ）または他の光学ストレージ、磁気カセット、磁気テープ、磁気ディスクストレージまたは他の磁気記憶装置、もしくは他の有形のコンピュータ読取可能媒体といった、非一時的で有形のコンピュータ読取可能記憶媒体を含み得る。これは、所望の情報を送信するために使用可能であり、コンピューティングシステム３００によってアクセスされ得るデータ信号、データ送信、または任意の他の媒体といった、非有形のコンピュータ読取可能媒体も含み得る。

例として、コンピュータ読取可能記憶媒体３２２は、非リムーバブルで不揮発性の磁気媒体から読出し、またはそれに書込むハードディスクドライブ、リムーバブルで不揮発性の磁気ディスクから読出し、またはそれに書込む磁気ディスクドライブ、ならびに、ＣＤ ＲＯＭ、ＤＶＤ、およびＢｌｕ−Ｒａｙ（登録商標）ディスク、または他の光学媒体といった、リムーバブルで不揮発性の光ディスクから読出し、またはそれに書込む光ディスクドライブを含んでいてもよい。コンピュータ読取可能記憶媒体３２２は、Ｚｉｐ（登録商標）ドライブ、フラッシュメモリカード、ユニバーサルシリアルバス（universal serial bus：ＵＳＢ）フラッシュドライブ、セキュアデジタル（secure digitalＳＤ）カード、ＤＶＤディスク、デジタルビデオテープなどを含んでいてもよいが、それらに限定されない。コンピュータ読取可能記憶媒体３２２はまた、フラッシュメモリベースのソリッドステートドライブ（solid-state drive：ＳＳＤ）、企業フラッシュドライブ、ソリッドステートＲＯＭといった、不揮発性メモリに基づいたＳＳＤ、ソリッドステートＲＡＭ、ダイナミックＲＡＭ、スタティックＲＡＭ、ＤＲＡＭベースのＳＳＤ、磁気抵抗ＲＡＭ（ＭＲＡＭ）ＳＳＤといった、揮発性メモリに基づいたＳＳＤ、および、ＤＲＡＭベースのＳＳＤとフラッシュメモリベースのＳＳＤとの組合せを使用するハイブリッドＳＳＤを含んでいてもよい。ディスクドライブおよびそれらの関連付けられたコンピュータ読取可能媒体は、コンピュータ読取可能命令、データ構造、プログラムモジュールおよび他のデータの不揮発性ストレージをコンピュータシステム３００に提供してもよい。

通信サブシステム３２４は、他のコンピュータシステムおよびネットワークへのインターフェイスを提供する。通信サブシステム３２４は、コンピュータシステム３００とは別のシステムからデータを受信し、別のシステムにデータを送信するためのインターフェイスとして機能する。たとえば、通信サブシステム３２４は、コンピュータシステム３００がインターネットを介して１つ以上の装置に接続できるようにしてもよい。いくつかの実施形態では、通信サブシステム３２４は、（たとえば、３Ｇ、４Ｇ、またはＥＤＧＥ（enhanced data rates for global evolution：エンハンスト・データレート・フォー・グローバル・エボリューション）、ＷｉＦｉ（ＩＥＥＥ８０２．１１ファミリー規格）、または他の移動通信技術、またはそれらの任意の組合せといった携帯電話技術、高度なデータネットワーク技術を使用した）無線音声および／またはデータネットワークにアクセスするための無線周波数（radio frequency：ＲＦ）トランシーバコンポーネント、全地球測位システム（global positioning system：ＧＰＳ）受信機コンポーネント、および／または他のコンポーネントを含み得る。いくつかの実施形態では、通信サブシステム３２４は、無線インターフェイスに加えて、またはその代わりに、有線ネットワーク接続（たとえば、イーサネット）を提供できる。

いくつかの実施形態では、通信サブシステム３２４はまた、コンピュータシステム３００を使用し得る１人以上のユーザのために、構造化および／または非構造化データフィード３２６、イベントストリーム３２８、イベント更新３３０などの形をした入力通信を受信してもよい。

例として、通信サブシステム３２４は、ツイッター（登録商標）フィード、フェースブック（登録商標）更新、リッチ・サイト・サマリー（Rich Site Summary：ＲＳＳ）フィードなどのウェブフィード、および／または１つ以上の第三者情報源からのリアルタイム更新といった、ソーシャルネットワークおよび／または他の通信サービスのユーザからのデータフィード３２６をリアルタイムで受信するように構成されてもよい。

加えて、通信サブシステム３２４はまた、リアルタイムイベントのイベントストリーム３２８および／またはイベント更新３３０を含み得る、明確な終わりがなく本質的に連続的または無限であり得る連続データストリームの形をしたデータを受信するように構成されてもよい。連続データを生成するアプリケーションの例は、たとえば、センサデータアプリケーション、金融ティッカー、ネットワーク性能測定ツール（たとえば、ネットワーク監視およびトラフィック管理アプリケーション）、クリックストリーム分析ツール、自動車交通監視などを含んでいてもよい。

通信サブシステム３２４はまた、構造化および／または非構造化データフィード３２６、イベントストリーム３２８、イベント更新３３０などを、コンピュータシステム３００に結合された１つ以上のストリーミングデータソースコンピュータと通信し得る１つ以上のデータベースに出力するように構成されてもよい。

コンピュータシステム３００は、ハンドヘルド携帯装置（たとえば、ｉＰｈｏｎｅ（登録商標）携帯電話、ｉＰａｄ（登録商標）コンピューティングタブレット、ＰＤＡ）、ウェアラブル装置（たとえば、グーグル・グラス（登録商標）頭部装着型ディスプレイ）、ＰＣ、ワークステーション、メインフレーム、キオスク、サーバラック、または任意の他のデータ処理システムを含む、さまざまなタイプのうちの１つであり得る。

コンピュータおよびネットワークの絶えず変化する性質により、図に示すコンピュータシステム３００の説明は、単に特定の一例として意図される。図に示すシステムよりも多い、または少ないコンポーネントを有する多くの他の構成が可能である。たとえば、カスタマイズされたハードウェアも使用されてもよく、および／または、特定の要素が、ハードウェア、ファームウェア、ソフトウェア（アプレットを含む）、または組合せで実現されてもよい。また、ネットワーク入力／出力装置などの他のコンピューティング装置への接続が採用されてもよい。ここに提供される開示および教示に基づいて、当業者であれば、さまざまな実施形態を実現するための他のやり方および／または方法を理解するであろう。

上に紹介されたように、この発明の実施形態は、コンピュータネットワーク間で送信されるメッセージを処理するための手法を提供する。より特定的には、物理的または論理的サブネットワーク内に実装されたプロキシサーバといった、中間ネットワーク装置またはアプリケーションが、通信エンドポイント間でメッセージを受信し、処理し、送信してもよい。いくつかの実施形態では、リバースプロキシサーバが、リバースプロキシサーバ内にレプリゼンテーショナル・ステート・トランスファー（ＲＥＳＴ）サービスおよびＲＥＳＴリソースを動的に生成するように構成されてもよい。リバースプロキシサーバ内のＲＥＳＴサービスおよびＲＥＳＴリソースは、クライアント装置からの着信要求を扱ってバックエンドウェブサービスを呼び出してもよく、それにより、リバースプロキシサーバ上のさまざまなセキュリティポリシーの設計抽象化および／または実施を可能にする。

さまざまな実施形態では、プロキシサーバは、プロキシサーバ内のＲＥＳＴウェブサービスによって公開された特定のリソースに対するウェブサービス要求を受信してもよい。プロキシサーバにおけるＲＥＳＴウェブサービス内の適切なリソースが呼び出されてもよく、次にバックエンドウェブサービスを呼び出してもよい。場合によっては、リバースプロキシサーバは、さまざまなバックエンドウェブサービスを仮想化して不明瞭にする一組のＲＥＳＴウェブサービスを公開してもよい。たとえば、リバースプロキシサーバは、信頼できないネットワーク上のクライアント装置が基盤のバックエンドウェブサービスを読み取らないように、または当該バックエンドウェブサービスについての知識を持たないように、仮想ユニフォームリソースロケータ（ＵＲＬ）のみを公開してもよい。追加の局面によれば、クライアント装置から受信されたＲＥＳＴ要求のうちのいくつかまたはすべてを扱うために、ＲＥＳＴサービスおよびＲＥＳＴリソースがリバースプロキシサーバ内に生成されてもよい。これらのＲＥＳＴサービス／リソースは、リバースプロキシサーバ内でＲＥＳＴ要求を扱うように、および／またはバックエンドウェブサービスの対応する組を呼び出すように、動的に生成され構成されてもよい。ＲＥＳＴウェブサービス／リソースを動的に生成し管理するために、ＲＥＳＴインフラストラクチャおよび／またはＲＥＳＴアプリケーションエンジンが、リバースプロキシサーバ内に実装されてもよい。加えて、ある実施形態では、リバースプロキシサーバ内のＲＥＳＴリソースは、バックエンドウェブサービスコールを生成して、さまざまなポリシーを実施するためのポリシー実施エンジンに提供してもよい。

図４Ａおよび図４Ｂは、さまざまなコンピュータネットワークにおけるコンピューティング装置および／またはシステム間でメッセージを処理して送信するためのリバースプロキシサーバ４２０を含むコンピューティング環境４００ａおよび４００ｂのコンポーネントを示すブロック図である。この例に示すコンピューティング環境４００ａおよび４００ｂ（総称して４００）は、ウェブアプリケーションおよびウェブサービス４３０といったバックエンドコンピューティングリソースへのアクセスをさまざまなクライアント装置４１０に提供するように設計された高レベルコンピュータアーキテクチャに対応していてもよい。さまざまな実施形態では、コンピューティング環境４００は、小さく単純なコンピューティングシステムから、大きく非常に複雑なシステムに及ぶ場合があり、当該システムは、さまざまな組織のコンピューティング需要をサポートするために他のそのようなシステムと統合するように設計されたハードウェア、ソフトウェア、およびネットワークコンポーネントを含む。コンピューティング環境４００は、多層コンピュータアーキテクチャとして実現されてもよく、それはウェブベースの、および／またはクラウドベースの実装を含んでいてもよく、そこでは、さまざまなエンドポイント装置（たとえば、ユーザ装置４１０、ウェブサービスプロバイダ４３０など）が、１つ以上の中間層システムを介してやりとりする。加えて、コンピューティング環境４００に示す各コンポーネントは、ハードウェア、ソフトウェア、および／またはネットワークコンポーネントのさまざまな組合せを含む、個々のコンピュータシステムとして実装されてもよい。他の場合、コンピューティング環境４００に示す複数のコンポーネントは、組合わせたコンピュータシステム内で動作する論理的サブコンポーネント（たとえば、コンピュータ読取可能媒体上で具現化されたソフトウェアアプリケーションなど）として実装されてもよい。

図４Ａおよび図４Ｂに示すように、そのようなコンピューティング環境４００は、クライアント装置４１０が、１つ以上のコンピュータネットワーク４１５、１つ以上のファイアウォール４３５、リバースプロキシサーバ４２０、および／または他の中間ネットワーク装置を介して、１つ以上のバックエンドウェブサービス４３０に要求を送信し得る、クライアント−サーバシステムに対応していてもよい。ウェブサービス４３０は、簡易オブジェクトアクセスプロトコル（Simple Object Access protocol：ＳＯＡＰ）ウェブサービスまたはＡＰＩ、レプリゼンテーショナル・ステート・トランスファー（ＲＥＳＴ）ウェブサービスまたはＡＰＩ、および／または、ハイパーテキスト転送プロトコル（ＨＴＴＰ）またはＨＴＴＰセキュアプロトコルを介して公開されたウェブコンテンツを何ら限定されることなく含む、さまざまなシステム４３０によって公開された任意のアプリケーションプログラムインターフェイス（application programming interface：ＡＰＩ）、サービス、アプリケーション、および任意の他の情報資産を含んでいてもよい。そのような場合、リバースプロキシサーバ４２０は、クライアント装置４１０とバックエンドウェブサービス４３０との間にセキュリティ層を提供してもよい。たとえば、プロキシサーバ４２０は、バックエンドウェブサービス４３０のための中央アクセスポイントを、バックエンドウェブサービス４３０に関連付けられたさまざまなセキュリティおよび管理ポリシーのサービス仮想化および実施とともに提供してもよい。リバースプロキシサーバ４２０はまた、これらのサービス４３０を仮想化して不明瞭にしながら、バックエンドウェブサービス４３０を公開してもよい。たとえば、リバースプロキシサーバ４２０は、信頼できないネットワーク上のクライアント装置４１０が基盤のバックエンドウェブサービス４３０を読み取らないように、またはバックエンドウェブサービス４３０についての知識を持たないように、仮想ユニフォームリソースロケータ（ＵＲＬ）のみを公開してもよい。

それに加えて、またはそれに代えて、コンピューティング環境４００は、要求−応答を逆方向に処理して送信するためのクライアント−サーバシステムとして構成されてもよい。たとえば、いくつかの実施形態では、内部コンピュータネットワーク４６０内で動作する１つ以上のクライアント装置（図示せず）が、プロキシサーバ４２０およびファイアウォール４３５ａを超えて、さまざまな外部コンピュータシステムおよびネットワーク４８０上で動作するウェブサービスまたはアプリケーション（図示せず）に要求を送信してもよい。このため、サーバ４２０はここにリバースプロキシサーバ４２０と呼ばれるものの、それはフォワードプロキシサーバとしても作用してもよく、内部クライアント装置４４０と外部バックエンドウェブサービスまたはアプリケーションとの間にセキュリティ層を提供してもよい、ということが理解されるべきである。リバースプロキシの機能性（すなわちリバースプロキシモード）またはフォワードプロキシの機能性（すなわちフォワードプロキシーモード）のいずれかを行なう場合、リバースプロキシサーバ４２０は、ＳＯＡＰウェブサービス、ＲＥＳＴウェブサービス、ＨＴＴＰ／ＨＴＴＰＳウェブコンテンツなどへのネットワーク要求、およびそれらからの応答を扱ってもよい。プロキシサーバ４２０がフォワードプロキシサーバとして動作している場合、内部クライアント装置は、外部バックエンドウェブサービス／アプリケーションについてすでに知っているかもしれず、それらのバックエンドサービス／アプリケーションは、クライアント側に構成されたプロキシサーバ４２０から直接送信を受信するかもしれない。そのような場合、プロキシサーバ４２０は、任意のセキュリティまたは通信管理ポリシーを使用して、フォワードプロキシユニフォームリソース識別子（uniform resource identifier：ＵＲＩ）エンドポイントのためのセキュリティを提供してもよい。フォワードプロキシモードまたはリバースプロキシモードのいずれであっても、プロキシサーバ４２０は、Kerberos Kinitベースの認証、Kerberos Pkinitベースの認証、オープン・スタンダード・フォー・オーソライゼーション・プロトコル・バージョン２．０（open standard for authorization protocol version 2.0：ＯＡｕｔｈ２）ベースの認証、ＴＬＰベースの認証といったさまざまなセキュリティおよび認証特徴をサポートし、単純で保護されたＧＳＳＡＰＩネゴシエーションメカニズム（Simple and Protected GSSAPI Negotiation Mechanism：ＳＰＮＥＧＯ）トークン、ＷＩＮＤＯＷＳ（登録商標）ＮＴ ＬＡＮマネージャ（WINDOWS NT LAN Manager：ＮＴＬＭ）トークン、セキュリティアサーションマークアップ言語（Security Assertion Markup Language：ＳＡＭＬ）トークンなどを使用してバックエンドサービスのセッショントークンおよび／またはチャレンジベースの認証を作成する。

クライアント装置４１０は、図１〜３の例示的なコンピューティングシステムにおける上述のハードウェア、ソフトウェア、およびネットワーキングコンポーネントのうちのいくつかまたはすべてを含む、デスクトップまたはラップトップコンピュータ、モバイル装置、および他のさまざまなコンピューティング装置／システムを含んでいてもよい。いくつかの実施形態では、クライアント装置４１０は、バックエンドウェブサービス４３０からデータを要求して受信するように構成された１つ以上のクライアントソフトウェアアプリケーション（たとえばウェブブラウザ）を含んでいてもよい。クライアント装置４１０はまた、ネットワークインターフェイス、セキュリティおよび認証能力、ならびに、ライブコンテンツを受信してそれをユーザにリアルタイムで（またはほぼリアルタイムで）提供するコンテンツキャッシング能力を確立するために、必要なハードウェアおよびソフトウェアコンポーネントを含んでいてもよい。

通信ネットワーク４１５は、ここに説明されるコンピュータネットワークおよび他の通信ネットワークの任意の組合せを含んでいてもよい。たとえば、ネットワーク４１５は、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（wide area network：ＷＡＮ）（たとえばインターネット）、およびさまざまな無線通信ネットワークといった、ＴＣＰ／ＩＰ（伝送制御プロトコル／インターネットプロトコル）ネットワークを含んでいてもよい。加えて、通信ネットワーク４１５は、バックエンドウェブサービス４３０からクライアント装置４１０を分離する多くの異なる物理的および論理的ネットワークの組合せを表わしてもよい、ということが理解されるべきである。１つ以上のファイアウォール４３５に加えて、ウェブサーバ、認証サーバなどのさまざまなサーバ、および／または、ファイアウォール、ルータ、ゲートウェイ、ロードバランサなどの特殊なネットワーキングコンポーネントが、クライアント装置４１０とバックエンドウェブサービス４３０との通信を容易にしてもよい。

いくつかの実施形態では、リバースプロキシサーバ４２０は、隔てられたコンピュータシステム（たとえばプロキシコンピュータサーバ）として、または、図４Ｂに示すように、隔てられたＤＭＺ４７０内に特殊なハードウェア、ソフトウェア、およびネットワークコンポーネントを含む、コンピュータが複数のコンピューティングシステムの組合せとして実装されてもよい。それに代えて、またはそれに加えて、リバースプロキシサーバ４２０は、信頼できるネットワーク４６０内のネットワーク装置（たとえば、ウェブサーバまたはファイアウォール４３５ｂ）またはコンピュータサーバ内で実行されるプロキシサーバソフトウェアアプリケーションであってもよい。このため、リバースプロキシサーバ４２０は、図４Ａに示すように、内部コンピュータネットワーク４６０の物理的または論理的サブネットワーク４６５に存在していてもよい。いずれの場合も、リバースプロキシサーバ４２０は、信頼できる内部ネットワーク４６０上のクライアント／サーバと、信頼できない外部ネットワーク４８０上のクライアント／サーバとの間の仲介主体として作用してもよい。加えて、リバースプロキシサーバ４２０内のコンポーネント４２１〜４２３の各々（ならびに、図５、図７および図９を参照して説明される他のプロキシサーバコンポーネント）は、リバースプロキシサーバ４２０と通信するように構成された別個のコンピューティングシステムとして実装されてもよく、または、リバースプロキシサーバ４２０と同じコンピュータサーバ内に統合された論理的サブコンポーネントとして動作してもよい。いずれの場合も、各コンポーネント４２１〜４２３（ならびに、図５、図７および図９を参照して説明される他のプロキシサーバコンポーネント）は、ここに説明される手法を行なうために、特殊なハードウェア、ソフトウェア、ネットワーク、およびメモリサブシステムを使用して実装されてもよい。

この例では、リバースプロキシサーバ４２０は、クライアント装置４１０から通信ネットワーク４１５および／またはファイアウォール４３５ａを介してメッセージを受信するように構成されたメッセージハンドラ４２１を含む。いくつかの実施形態では、メッセージハンドラ４２１は、任意の外部ネットワークからバックエンドウェブサービス４３０へのすべてのＴＣＰ、ＵＤＰ、ＨＴＴＰ、およびＨＴＴＰＳトラフィックのためのエントリポイントであってもよい。メッセージハンドラ４２１はまた、バックエンドウェブサービス４３０から応答を受信し、その応答をクライアント装置４１０に送信するように構成されてもよい。いくつかの例では、メッセージハンドラ４２１は、１つ以上の特殊なハードウェア、ソフトウェア、およびネットワークコンポーネント、たとえばロードバランサ、キャッシュ、および／またはメッセージスロットラーを含んでいてもよい。

メッセージを受信して構文解析した後で、メッセージハンドラ４２１は、（たとえば、Ｊａｖａネーティブインターフェイス（Java Native Interface：ＪＮＩ）または．ＮＥＴプログラミングフレームワークなどを介して）メッセージを適切なウェブサービスフレームワークに送信してもよい。たとえば、リバースプロキシサーバ４２０で受信されたＳＯＡＰ要求は、ＳＯＡＰウェブサービスフレームワーク（図示せず）に送信されてもよく、一方、ＲＥＳＴ要求は、ＲＥＳＴウェブサービスフレームワーク（たとえば、ＲＥＳＴインフラストラクチャ４２２）に送信されてもよい。ウェブコンテンツ要求は、メッセージハンドラ４２１により、たとえば、要求を構文解析し、ＵＲＬ仮想化コンポーネントまたはサービスといったさまざまなコンポーネントに送信することによって同様に扱われてもよい。場合によっては、メッセージハンドラ４２１はまた、ＳＯＡＰからＲＥＳＴへの、およびＲＥＳＴからＳＯＡＰへの、ならびに、JavaScript（登録商標）オブジェクト表記法（JavaScript Object Notation：ＪＳＯＮ）からＸＭＬへの、またはＪＳＯＮからＳＯＡＰへの、およびその逆のメッセージ変換といったプロトコル変換を行なうように構成されてもよい。

プロキシサーバ４２０はまた、レプリゼンテーショナル・ステート・トランスファー（ＲＥＳＴ）インフラストラクチャ４２２と、１つ以上のＲＥＳＴウェブサービス（またはＲＥＳＴ ＡＰＩ）４２３とを含んでいてもよい。図４に示すように、ＲＥＳＴインフラストラクチャ４２２は、要求ハンドラ４２１から、ＲＥＳＴウェブサービスに対する要求を受信してもよい。以下により詳細に説明されるように、ＲＥＳＴインフラストラクチャ４２２は、ＲＥＳＴ要求を分析して処理してから、要求を扱うための適切なＲＥＳＴサービス４２３にそれらを発送してもよい。各ＲＥＳＴサービス４２３は、要求を扱い、要求に基づいて対応するバックエンドウェブサービス４３０を呼び出すように構成されたＲＥＳＴリソースを含んでいてもよい。加えて、いくつかの実施形態では、ＲＥＳＴインフラストラクチャ４２２は、要求を扱うためのＲＥＳＴサービス４２３および個々のＲＥＳＴリソースを動的に生成してもよい。

ＲＥＳＴインフラストラクチャ４２２は、ＲＥＳＴウェブサービス（ＲＥＳＴフルウェブサービス、ＲＥＳＴフルＡＰＩなどとも呼ばれる）を開発して実行するためのウェブサービスフレームワークを含んでいてもよい。いくつかの実施形態では、ＲＥＳＴインフラストラクチャ４２２は、ＪＡＸ−ＲＳ（Java API for RESTful Web Services）仕様の実装、たとえばＪＡＸ−ＲＳのＪＥＲＳＥＹリファレンス実装であってもよい。ＪＡＸ−ＲＳおよびＪＥＲＳＥＹウェブサービス／ＡＰＩインフラストラクチャに関して以下の多くの例が説明されるが、他の例では他のフレームワークおよび手法が使用されてもよい。たとえば、SCALA、BOWLING FINCH/FINAGLEフレームワークといった他のＲＥＳＴウェブフレームワーク／ＡＰＩサーバが、ＪＥＲＳＥＹおよびＪＡＸ−ＲＳの代わりに、またはそれらに加えて使用されてもよい。

さまざまな実施形態では、ＲＥＳＴインフラストラクチャ４２２は、（たとえば、ＪＥＲＳＥＹ ＪＡＶＡサーブレットコンテナ内に）ＲＥＳＴウェブサービスを実装するためのライブラリを含んでいてもよく、また、ＲＥＳＴリソースを識別するために予め定義されたクラスをスキャンするように構成されたアプリケーション（たとえば、ＪＥＲＳＥＹ ＪＡＶＡサーブレット）を提供してもよい。ＲＥＳＴインフラストラクチャ４２２はまた、ＲＥＳＴウェブサービス４２３および／または４３０と通信するためのクライアントライブラリを提供してもよい。クライアント装置から要求を受信すると、ＲＥＳＴインフラストラクチャ内のアプリケーション（たとえば、ＪＥＲＳＥＹ ＪＡＶＡサーブレット）は、着信ＨＴＴＰ要求を分析し、その要求に応答するために正しいリソースおよび方法を選択してもよい。あるタイプのウェブサービスとは異なり、ＲＥＳＴウェブサービスは、ＸＭＬまたは任意の他の特定のデータフォーマットで通信しなくてもよい。したがって、ＲＥＳＴインフラストラクチャ４２２は、ＸＭＬ、JavaScriptオブジェクト表記法（ＪＳＯＮ）、コンマ区切り形式（comma-separated values：ＣＳＶ）、またはさまざまな他のデータフォーマットでのデータの作成をサポートしてもよい。

図４Ａおよび図４Ｂに示すように、リバースプロキシサーバ４２０は、２つ以上のコンピュータネットワーク間、たとえば、ウェブサービス４３０を提供する信頼できる内部ネットワーク４６０と、信頼できないさまざまなクライアント装置４１０が内部ウェブサービス４３０にアクセスし得る信頼できない外部ネットワーク４８０（たとえばインターネット）との間の、中間ネットワーク装置内に実装されてもよい。図４Ａに示すように、リバースプロキシサーバ４２０は、内部コンピュータネットワーク４６０のためのセキュリティおよび通信管理の初期層を提供するために、内部コンピュータネットワーク４６０のサブネットワーク４６５内で動作してもよい。たとえば、安全な内部ネットワーク４６０は、複数のウェブサービスおよびアプリケーション４３０を、さまざまな他のサーバおよび／またはクライアント装置とともに含んでいてもよい。リバースプロキシサーバ４２０および／または追加のネットワークまたはコンピューティング装置は、同じ内部ネットワーク４６０の一部であってもよいが、１つ以上のゲートウェイ、ファイアウォール４３５ｂなどによって内部コンピュータネットワークから分離された、内部コンピュータネットワークの物理的サブネットワーク４６５内で動作してもよい。いくつかの例では、リバースプロキシサーバ４２０は、内部コンピュータネットワーク４６０の（物理的サブネットワークではなく）論理的サブネットワーク４６５内で実行されるプロキシサーバアプリケーションとして実装されてもよい。このため、リバースプロキシサーバ４２０は、内部コンピュータネットワーク４６０内のバックエンドウェブサービス４３０または他のコンピュータシステムのうちの１つ以上と同じコンピューティングシステム上に存在していてもよい。

加えて、いくつかの実施形態では、リバースプロキシサーバ４２０は、信頼できる内部ネットワーク４６０と信頼できない外部ネットワーク４８０との間の非武装ゾーン（demilitarized zone：ＤＭＺ）ネットワーク４７０内で動作してもよい。図４Ｂに示すように、ＤＭＺネットワーク４７０は、専用のハードウェア、ソフトウェア、およびネットワークコンポーネントを有し、内部ネットワーク４６０および外部ネットワーク４８０双方から隔てられた、全く別個のコンピューティングシステムとして実装されてもよい。それに代えて、図４Ａに示すように、ＤＭＺは、信頼できる内部ネットワーク４６０の物理的または論理的サブネットワーク４６５として実装されてもよく、それにより、ＤＭＺは、クライアント装置４１０および／またはバックエンドウェブサービス４３０で提供されるエンドポイントセキュリティとは別の、セキュリティおよび通信管理の第１の層を提供する。いずれの場合も、ＤＭＺネットワークは、２つのファイアウォール４３５ａと４３５ｂとの間に実装されてもよく、もしくは、単一のファイアウォールを使用して、または、信頼できる内部ネットワーク４６０および信頼できない外部ネットワーク４１５双方からＤＭＺネットワーク４７０またはサブネットワーク４６５を物理的にまたは論理的に分離するネットワーク装置の他のさまざまな構成を使用して、実装されてもよい。リバースプロキシサーバ４２０など、ＤＭＺ内のすべてのコンピュータサーバおよび他の装置は、内部ネットワーク４６０内の装置のある特定の部分集合（たとえば、ウェブサービス４３０をホストする特定のサーバ）への限定された接続性を有していてもよい。そのような接続性は、特定のホスト、ポート、プロトコルなどに基づいて限定されてもよい。同様に、信頼できない任意の外部ネットワーク（たとえば、ネットワーク４１５およびクライアント装置４１０）と通信する際、限定された接続性のポリシーがＤＭＺ内の装置に対して実施されてもよい。ＤＭＺ内でリバースプロキシサーバ４２０を動作させることに加えて、ある実施形態では、ＤＭＺ内でバックエンドウェブサービス４３０のうちの１つ以上が動作してもよい。たとえば、外部システムからの攻撃をより受けやすいあるコンピュータサーバ／サービス（たとえば、ウェブサーバ、電子メールサーバ、ドメイン名システム（Domain Name System：ＤＮＳ）サーバなど）を、プロキシサーバ４２０とともにＤＭＺ内に移動させてもよい。

図５は、１つ以上の実施形態に従ったリバースプロキシサーバのある要素およびシステムを示すブロック図である。この例のリバースプロキシサーバ５２０はリバースプロキシ４２０に対応していてもよく、リバースプロキシサーバ５２０のさまざまなサブコンポーネント５２１〜５２３は、上述の対応するサブコンポーネント４２１〜４２３と同様または同一であってもよい。加えて、リバースプロキシサーバ５２０は、コンピューティング環境４００または他の同様の環境内で動作してもよく、クライアントコンピューティング装置とバックエンドウェブサービスとの間でメッセージを処理して送信するように構成されてもよい。したがって、リバースプロキシサーバ５２０は、図４Ａおよび図４Ｂを参照して上述されたハードウェア、ソフトウェア、およびネットワーキングコンポーネントならびに機能性のうちのいくつかまたはすべてを含んでいてもよい。

ＲＥＳＴインフラストラクチャ５２２は、ＲＥＳＴサービスおよびリソースを開発し、デプロイメントし、実行し、それらにアクセスするためのさまざまなコンポーネント（たとえば、アプリケーションおよびライブラリ）を有する１つ以上のＲＥＳＴウェブサービスフレームワークを含んでいてもよい。さまざまな実施形態では、ＲＥＳＴインフラストラクチャ５２２は、ＪＡＸ−ＲＳ仕様のＪＥＲＳＥＹ実装、および／または他のＲＥＳＴウェブサービスフレームワーク実装を含んでいてもよい。ＲＥＳＴインフラストラクチャ５２２は、ＲＥＳＴウェブサービスを実装するための１つ以上のライブラリ、ＲＥＳＴリソースを識別するために予め定義されたクラスをスキャンするためのアプリケーション、ＲＥＳＴウェブサービスと通信するためのクライアントライブラリなどを提供してもよい。

上述のように、要求ハンドラ５２１はＲＥＳＴ要求をＲＥＳＴインフラストラクチャ５２２に発送してもよく、ＲＥＳＴインフラストラクチャ５２２はそれらの要求を分析し処理してから、リバースプロキシサーバ５２０内の１つ以上のＲＥＳＴサービスにそれらを発送してもよい。この例では、ＲＥＳＴインフラストラクチャ５２２は、ＲＥＳＴスタック５２４と、静的ＲＥＳＴアプリケーション５２５（たとえば、構築時間中に生成されたＪＥＲＳＥＹアプリケーション）と、ＲＥＳＴプロバイダリソース５２６とを含む。以下により詳細に説明されるように、リバースプロキシサーバ５２０は、ＲＥＳＴスタック５２４を動的に（すなわち実行時間中に）初期化し、静的ＲＥＳＴアプリケーション５２５を登録してもよい。静的ＲＥＳＴアプリケーション５２５は、要求を扱うための適切なＲＥＳＴサービス５２３のルートリソースを識別することを担当し得るＲＥＳＴプロバイダリソース５２６に戻してもよい。

図５に示すように、ＲＥＳＴプロバイダリソース５２６は、リバースプロキシサーバ５２０内の任意のＲＥＳＴサービス５２３に要求を発送してもよい。この例では、要求はＲＥＳＴサービス５２３ｂに発送され、そのＲＥＳＴサービスにおけるルートリソース５２７によって受信されている。この例に示すように、ＲＥＳＴサービス５２３はリソース階層構造として設計され実装されてもよく、そこでは、ルートリソース５２７はサービス５２３内で最高レベルのリソースであり（たとえば、サービスの「／」パスにマッピングされる）、異なる要求を扱うであろうサブリソース５２８（または子リソース）を識別することを担当する。以下により詳細に説明されるように、ルートリソース５２７および／またはすべての子リソース５２８は双方とも、動的ＲＥＳＴリソース（たとえば、実行時間中に作成されたリソース）として作成されてもよい。加えて、この例では単純な２レベルの階層構造が示されているが、他の例では、多くの異なるレベル（たとえば、３レベル、４レベル、５レベルなど）の複雑な階層構造が実装されてもよい。

ここで図６Ａ〜図６Ｂ（総称して「図６」）を参照して、リバースプロキシサーバを介してＲＥＳＴウェブサービス要求を受信して処理するためのプロセスを示すフローチャートが示される。以下に説明されるように、このプロセスにおけるステップは、コンピューティング環境４００における１つ以上のコンポーネント、たとえば、リバースプロキシサーバ４２０（および／またはリバースプロキシサーバ５２０、７２０、および９２０）、ならびに、そこに実装されたさまざまなサブシステムおよびサブコンポーネントによって行なわれてもよい。加えて、いくつかの実施形態では、このプロセスにおけるあるステップは、クライアント装置４１０、バックエンドウェブサービス４３０内で、および／または他のさまざまな中間装置によって行なわれてもよい。メッセージを受信して分析すること、メッセージ処理ポリシーを選択すること、およびメッセージを処理することを含む、ここに説明される手法は、上述の特定のシステムおよびハードウェア実装に限定されなくてもよく、ハードウェア、ソフトウェア、およびネットワークコンポーネントの他の組合せを含む他のハードウェアおよびシステム環境内で行なわれてもよい、ということがさらに理解されるべきである。

ステップ６０１で、ウェブサービス要求が、リバースプロキシサーバ４２０といった中間コンピューティングシステムまたはアプリケーションによって受信されてもよい。上述のように、リバースプロキシサーバ４２０は、信頼できる内部ネットワーク４６０と１つ以上の信頼できない外部ネットワークとの間の中間サーバ装置および／またはアプリケーションとして実装されてもよい。したがって、リバースプロキシサーバ４２０は、クライアントエンドポイント（たとえば、クライアント装置４１０）によって送信され、サーバエンドポイント装置（たとえば、バックエンドウェブサービスおよび／またはアプリケーション４３０をホストするコンピュータサーバ）に向けられた、またはその逆のメッセージを遮ってもよい。

いくつかの実施形態では、内部ネットワーク４６０に出入りするすべてのネットワークトラフィックは、リバースプロキシサーバ４２０を通してルーティングされてもよい。他の場合、リバースプロキシサーバ４２０は、特定のタイプまたはプロトコルのネットワークメッセージ、たとえば、クライアント装置４１０からのＳＯＡＰ、ＲＥＳＴ、またはＵＲＬリソースに対するＨＴＴＰ要求、および、ＳＯＡＰ、ＲＥＳＴ、またはＵＲＬウェブサービス／アプリケーション４３０からクライアント装置に戻るＨＴＴＰ応答を遮るように構成されてもよい。したがって、ステップ６０１で受信されたウェブサービス要求は、たとえば、および何ら限定されることなく、ＴＣＰメッセージ、ＨＴＴＰまたはＨＴＴＰＳメッセージ、簡易メール転送プロトコル（Simple Mail Transport Protocol：ＳＭＴＰ）、ユーザデータグラムプロトコル（User Datagram Protocol：ＵＤＰ）メッセージ、および／またはＪａｖａメッセージサービス（Java Message Service：ＪＭＳ）メッセージであってもよい。場合によっては、ウェブサービス要求は、クライアント装置４１０からバックエンドウェブサービス４３０へのＳＯＡＰ、ＲＥＳＴ、またはウェブコンテンツ要求に対応していてもよく、もしくは、クライアント装置４１０からのＳＯＡＰ、ＲＥＳＴ、またはウェブコンテンツ要求に対するバックエンドウェブサービス４３０による応答に対応していてもよい。

ステップ６０２で、リバースプロキシサーバ４２０は、ステップ６０１で受信された要求を分析して、要求が、リバースプロキシサーバ４２０内のＲＥＳＴサービス４２３／５２３によって公開されたＲＥＳＴリソース５２８に向けられているか否かを判断してもよい。ここに使用されるように、プログラミングオブジェクトまたはデータオブジェクトといったリソースを「公開する」とは、リソースへのアクセスを提供するインターフェイスを提供することを指してもよい。たとえば、ウェブサービスおよびＡＰＩは、クライアントアプリケーションがオブジェクトにアクセスすることおよび／またはオブジェクトを操作することを可能にする方法および動作を提供することによって、リソースを公開してもよい。

上述のように、ステップ６０１で受信されたＲＥＳＴウェブサービス要求は、バックエンドウェブサービス４３０に向けられてもよい（および／または、最終的に発送されてもよい）。しかしながら、さまざまな実施形態では、クライアント装置４１０から受信されたＲＥＳＴ要求のうちのいくつかまたはすべてを扱うために、ＲＥＳＴサービスおよびリソースがリバースプロキシサーバ４２０内に生成されてもよい。たとえば、図４Ａおよび図４Ｂに示すように、ＲＥＳＴ要求を扱うために、一組のＲＥＳＴサービス４２３が、リバースプロキシサーバ４２０内に生成されてもよく、場合によっては対応する一組のバックエンドウェブサービス４３０を呼び出してもよい。このため、リバースプロキシサーバ４２０内の一組のＲＥＳＴサービス４２３／５２３は、バックエンドウェブサービス４３０によって公開された同じリソースのうちのいくつかまたはすべてを公開してもよい。場合によっては、リバースプロキシサーバ４２０内のこれらのＲＥＳＴサービス４２３は、「仮想サービス」と呼ばれてもよい。以下により詳細に説明されるように、これらのＲＥＳＴサービス４２３は、ちょうどバックエンドウェブサービス４３０に対応していてもいなくてもよい。たとえば、単一のＲＥＳＴサービス４２３が、複数の異なるバックエンドサービス４３０を呼び出すＲＥＳＴリソース５２８を公開してもよく、または逆に、複数の異なるＲＥＳＴサービス４２３が、同じバックエンドサービス４３０を呼び出してもよい。加えて、リバースプロキシサーバ４２０内のＲＥＳＴサービス４２３は、バックエンドウェブサービス４３０によってサポートされない新規のもしくは異なる動作または方法、パラメータ、データタイプなどのためのサポートを含んでいてもよく、その逆もまた同様である。

また、いくつかの実施形態では、あるＲＥＳＴウェブサービス４２３および／またはＲＥＳＴリソース５２７〜５２８は、リバースプロキシサーバ４２０内に動的に作成されてもよい。たとえば、リバースプロキシサーバ４２０内のＲＥＳＴインフラストラクチャ４２２（および／または５２２、７２２、ならびに９２２）および／または他のコンポーネントは、実行時間中にさまざまなＲＥＳＴサービスおよび／またはＲＥＳＴリソースを生成、削除、置換、または更新してもよい。そのような場合、たとえあるＲＥＳＴリソース５２８がある時間にリバースプロキシサーバ４２０上に存在しなかったとしても、それにもかかわらず、それらのリソースは依然として、同じ時間にリバースプロキシサーバ４２０によって公開されてもよい。たとえば、ＲＥＳＴウェブサービス４２３／５２３によって公開されたリソースのすべてを記述するために、ウェブアプリケーション記述言語（Web Application Description Language：ＷＡＤＬ）ファイルが生成されてもよい。たとえＲＥＳＴリソース５２８のうちのいくつかがまだ作成されていなかったとしても、ＷＡＤＬファイルは、どのＲＥＳＴリソース５２８がＲＥＳＴサービス４２３によって公開されるかを判断するために使用されてもよい。リバースプロキシサーバ４２０内でさまざまなＲＥＳＴサービス４２３／５２３およびＲＥＳＴリソース５２８を動的に生成し更新するための手法は、図７および図８を参照して以下により詳細に説明される。

ステップ６０２で要求がリバースプロキシサーバ４２０内のＲＥＳＴサービス４２３／５２３によって公開されたＲＥＳＴリソース５２８に向けられているか否かを判断するために、要求は、要求宛先ならびにメッセージヘッダおよび／または本文の関連部分を識別するために、構文解析され、分析されてもよい。たとえば、要求が、ＲＥＳＴサービス４２３のためのＷＡＤＬファイル（または他のウェブサービス記述データ）内のＲＥＳＴリソースに対応するＵＲＬに向けられたＨＴＴＰ要求である場合、要求ハンドラ４２１は、要求が、リバースプロキシサーバ４２０によって公開されたＲＥＳＴリソース５２８に向けられていると判断してもよい（６０２：はい）。それに代えて、要求が、無効の要求、ＳＯＡＰ要求、通常のウェブコンテンツに対する要求、または、リバースプロキシサーバ４２０を介してアクセス可能ではないＲＥＳＴリソースに向けられた要求である場合、要求ハンドラ４２１は、要求が、リバースプロキシサーバ４２０によって公開されたＲＥＳＴリソース５２８に向けられていないと判断してもよい（６０２：いいえ）。

ステップ６０３で、ステップ６０１で受信されたＲＥＳＴウェブサービス要求は、リバースプロキシサーバ４２０内のＲＥＳＴインフラストラクチャ４２２に発送されてもよい。たとえば、ステップ６０２でウェブサービス要求がリバースプロキシサーバ４２０によって公開されたＲＥＳＴリソースに対する要求であると判断した後で、要求ハンドラ４２１は、ＲＥＳＴインフラストラクチャ４２２内のＲＥＳＴスタック５２４に要求を発送してもよく、ＲＥＳＴスタック５２４は次に、静的ＲＥＳＴアプリケーション５２５に要求を発送してもよい。上述のように、いくつかの実施形態では、ＲＥＳＴスタック５２４はＪＡＸ−ＲＳスタックであってもよく、静的ＲＥＳＴアプリケーションは、構築時間中に生成されたＪＥＲＳＥＹアプリケーションであってもよい。場合によっては、リバースプロキシサーバ５２０内のコンポーネントは、ＪＡＸ−ＲＳスタック５２４を動的に初期化し、静的ＪＥＲＳＥＹアプリケーション５２５を登録するように構成されてもよい。

ステップ６０４で、リバースプロキシサーバ４２０（および／またはリバースプロキシサーバ５２０、７２０、ならびに９２０）内のさまざまなコンポーネントは、要求されたＲＥＳＴリソースが現在、リバースプロキシサーバ４２０上に存在するか否かを判断してもよい。上述のように、いくつかの実施形態では、ＲＥＳＴウェブサービス４２３は、リバースプロキシサーバ４２０内のＲＥＳＴインフラストラクチャ４２２（および／または５２２、７２２、ならびに９２２）および／または他のコンポーネントによって、動的に作成されてもよく、すなわち、実行時間中に生成されてもよい。したがって、ステップ６０４で、ＲＥＳＴインフラストラクチャ４２２および／またはＲＥＳＴサービス４２３は、要求されたＲＥＳＴリソースが現在、リバースプロキシサーバ４２０上に存在するか否かを判断してもよい。場合によっては、ＲＥＳＴ要求を受信すると（６０２：はい）、ＲＥＳＴスタック５２４（たとえばＪＡＸ−ＲＸスタック）は要求を受信し、静的ＲＥＳＴアプリケーション５２５（たとえばＪＥＲＳＥＹアプリケーション）を呼び出してもよく、静的ＲＥＳＴアプリケーション５２５は、登録されたＲＥＳＴプロバイダリソース５２６を呼び出してもよい。ＲＥＳＴプロバイダリソース５２６は、適切なＲＥＳＴサービス４２３に、および／または仮想ＲＥＳＴサービス４２３内の適切なＲＥＳＴリソース４２８に要求を委任してもよい。ＲＥＳＴプロバイダリソース５２６および／または呼び出されたＲＥＳＴサービスのルートリソース５２７が、要求されたリソースが以前に生成されたと判断した場合（６０４：はい）、要求は、ステップ６０６でＲＥＳＴサービス５２３のルートリソース５２７に発送され、次にステップ６０７で要求を扱うために適切なＲＥＳＴリソース５２８に発送されてもよい。いくつかの実施形態では、プロバイダリソース５２６は、要求のＵＲＩを使用して適切なＲＥＳＴルートリソース５２７を判断してもよく、ＲＥＳＴルートリソース５２７は、リソースの「／」パスにマッピングされてもよい。ＲＥＳＴルートリソース５２７は次に、要求を扱うために、サブリソースロケータを使用してリバースプロキシサーバ４２０内の実際のＲＥＳＴリソース５２８を突きとめてもよい。

それに代えて、ＲＥＳＴインフラストラクチャ５２６および／または呼び出されたＲＥＳＴサービス５２３内の１つ以上のコンポーネントが、要求されたＲＥＳＴリソースがまだ生成されていない（または、生成し直す必要がある）と判断した場合（６０４：いいえ）、ステップ６０５で、要求を扱うための要求された適切なＲＥＳＴリソースが生成されてもよい。リバースプロキシサーバ４２０内での仮想ＲＥＳＴウェブサービス４２３の生成については、図７〜８を参照して以下により詳細に説明される。ステップ６０５で要求を扱うための適切なＲＥＳＴリソースが生成された後で、要求は次に、ステップ６０６でＲＥＳＴサービス５２３のルートリソース５２７に発送され、次にステップ６０７で新たに作成されたＲＥＳＴリソース５２８に発送されてもよい。

ステップ６０８で、要求を扱う間に、たとえば、リバースプロキシサーバ４２０内でＲＥＳＴリソース５２８を実行する間に、１つ以上のバックエンドウェブサービスコールが判断されてもよい。いくつかの実施形態では、リソースが作成されると、ソフトウェアフックおよび／または他のカスタマイズされたソフトウェアコードが、ＲＥＳＴリソース５２８に挿入されてもよい。そのようなソフトウェアフックおよび／またはカスタマイズされたソフトウェアコードは、バックエンドＲＥＳＴサービス４３０およびリソース、ならびに、バックエンドウェブサービス４３０へのコールで送信され得る個々の動作（または方法）、パラメータ、および他のデータを識別してもよい。要求を扱うためにリバースプロキシサーバ４２０上のＲＥＳＴリソース５２８が呼び出されると、ソフトウェアフックおよび／またはカスタマイズされたソフトウェアコードが実行されてもよく、バックエンドウェブサービス４３０へのコールが生成されてもよい。

場合によっては、ステップ６０８で判断されたバックエンドウェブサービスコールは、リバースプロキシサーバ４２０上のＲＥＳＴリソース５２８によって扱われたＲＥＳＴ要求と同様または同一であってもよい。たとえば、以下により詳細に説明されるように、リバースプロキシサーバ４２０内のＲＥＳＴサービス４２３は、（たとえば、ウェブアプリケーション記述言語（ＷＡＤＬ）ファイルに基づいて）同じリソース定義を有し、方法、パラメータなどをサポートする、バックエンドＲＥＳＴサービス４３０のコピーとして作成されてもよい。そのような場合、リバースプロキシサーバ４２０上のＲＥＳＴリソース５２８は、対応するバックエンドＲＥＳＴウェブサービス４３０内で、同じＲＥＳＴリソースを呼び出し、パラメータおよび／または本文コンテンツなどを有する同じ方法をコールするように構成された、単純なソフトウェアフックを含んでいてもよい。

さまざまな他の場合、ステップ６０８で判断されたバックエンドウェブサービスコールは、リバースプロキシサーバ４２０上のＲＥＳＴリソース５２８によって最初に扱われたＲＥＳＴ要求とは異なっていてもよい。そのような場合、リバースプロキシサーバ４２０によってクライアント装置４１０に公開されたＲＥＳＴサービス４２３／５２３およびリソース５２８は、バックエンドＲＥＳＴサービス４３０によって公開されたＲＥＳＴリソースに全く対応していなくてもよい。たとえば、図４Ａおよび図４Ｂを簡潔に参照して、仮想ＲＥＳＴサービス４２３ａおよびその対応するバックエンドＲＥＳＴサービス４３０ａは、場合によっては同様に実装されてもよく（たとえば、同様の（または同じ）ＷＡＤＬファイルを有する、同じリソースを含む、同じ方法、パラメータ、データタイプをサポートするなど）、一方、他の場合、仮想ＲＥＳＴサービス４２３および対応するバックエンドサービス４３０は、かなり異なって実装されてもよい。例示すると、ステップ６０１でクライアント装置４１０から受信されたＲＥＳＴ要求は、ＲＥＳＴリソース５２８へのＵＲＬパス、ＨＴＴＰ方法、１つ以上のＵＲＬパラメータおよび／または追加のパラメータ、もしくはメッセージヘッダまたは本文内のデータを含んでいてもよい。しかしながら、メッセージを扱うためにＲＥＳＴリソース５２８が実行されると、それは、異なるＵＲＬパス（たとえば、異なるサブリソースパスまたはリソース名）、異なるＨＴＴＰ方法、異なるＵＲＬパラメータ、および／または異なるヘッダまたは本文データを有するバックエンドウェブサービスコールを生成してもよい。加えて、いくつかの実施形態では、バックエンドウェブサービス４３０はＲＥＳＴサービスでなくてもよく、ＳＯＡＰサービス、ＵＲＬ、もしくは他のタイプのウェブサービス、ウェブアプリケーション、またはウェブコンテンツであってもよい。そのような場合、リバースプロキシサーバ４２０内のＲＥＳＴリソース５２８は、ＳＯＡＰおよびＵＲＬコールを生成するように、および／または、さまざまな異なるタイプのバックエンドウェブサービス、アプリケーション、ウェブコンテンツなどを呼び出すように構成されてもよい。このため、クライアント装置４１０は、リバースプロキシサーバ４２０内のＲＥＳＴサービス４２３／５２３によって公開されたＲＥＳＴリソース５２８についての知識のみを有するかもしれず、基盤のバックエンドウェブサービス４３０の設計または構造についての認識をまったく持たないかもしれない。いくつかの実施形態では、仮想ＲＥＳＴサービス４２３およびそれらの対応するバックエンドサービス４３０のための異なるウェブサービス／リソース設計および実装の使用は、たとえば、信頼できないクライアント装置４１０からバックエンドサービス４３０の根本的設計を不明瞭にするために、ならびに、バックエンドウェブサービス４３０間のより容易な統合、互換性、およびスケーラビリティを提供するために、有利であり得る。

ステップ６０９で、バックエンドウェブサービスコールが生成された後で、リバースプロキシサーバ４２０は、バックエンドウェブサービスコールに関連付けられたさまざまなセキュリティポリシー（および／または他の通信管理ポリシー）を実施してもよい。次に、ステップ６１０で、信頼できる内部ネットワーク４６０内の１つ以上のバックエンドウェブサービス４３０を呼び出すために、コールがリバースプロキシサーバ４２０内で実行されてもよい。図９〜１０を参照してより詳細に説明されるように、リバースプロキシサーバ４２０内のＲＥＳＴリソース４２８は、バックエンドウェブサービスコールを、コールを処理してさまざまなポリシーを実施し得るポリシー実施エンジン９６０に提供してもよい。ある実施形態では、セキュリティポリシー（および／または他の通信管理ポリシー）は、クライアント４１０からバックエンドウェブサービス４３０に送信されてクライアント４１０に戻る要求−応答のエンドツーエンド処理フロー内のさまざまな異なる添付点（たとえば、OnRequest、OnInvoke、OnResponse、MessageTransformation、OnErrorなど）で実施されてもよい。

図７は、１つ以上の実施形態に従ったリバースプロキシサーバのある要素およびシステムを示すブロック図である。この例のリバースプロキシサーバ７２０はリバースプロキシ４２０および／またはリバースプロキシサーバ５２０に対応していてもよく、リバースプロキシサーバ７２０のさまざまなサブコンポーネント７２２〜７２３は、上述の対応するサブコンポーネントと同様または同一であってもよい。加えて、リバースプロキシサーバ５２０は、コンピューティング環境４００または他の同様の環境内で動作してもよく、クライアントコンピューティング装置とバックエンドウェブサービスとの間でメッセージを処理して送信するように構成されてもよい。したがって、リバースプロキシサーバ７２０は、図４Ａ〜図４Ｂおよび／または図５を参照して上述されたハードウェア、ソフトウェア、およびネットワーキングコンポーネントならびに機能性のうちのいくつかまたはすべてを含んでいてもよい。

図７に示すあるコンポーネントは、リバースプロキシサーバ７２０内にＲＥＳＴウェブサービス７２３を生成するように構成されてもよい。上述のように、いくつかの実施形態では、ＲＥＳＴサービス７２３は、ＲＥＳＴサービス７２３に含まれるかまたはＲＥＳＴサービス７２３によって公開されたＲＥＳＴリソース７２８とともに、リバースプロキシサーバ７２０内に動的に作成されてもよい。そのような実施形態では、リバースプロキシサーバ７２０内のＲＥＳＴインフラストラクチャ７２２、ＲＥＳＴアプリケーションエンジン７４０、ゲートウェイ管理システム７５０、および／または他のコンポーネントは、実行時間中にリバースプロキシサーバ内でさまざまなＲＥＳＴサービス７２３および／またはＲＥＳＴリソース７２８を生成、削除、置換、または更新するように構成されてもよい。

この例では、ＲＥＳＴインフラストラクチャ７２２は、ＲＥＳＴスタック７２４と、静的ＲＥＳＴアプリケーション７２５（たとえば、構築時間中に生成されたＪＥＲＳＥＹアプリケーション）と、ＲＥＳＴプロバイダリソース７２６とを含む。リバースプロキシサーバ７２０は、実行時間中にＲＥＳＴスタック７２４を動的に初期化してもよく、静的ＲＥＳＴアプリケーション７２５を登録してもよく、静的ＲＥＳＴアプリケーション７２５は、ＲＥＳＴプロバイダリソース７２６に戻してもよい。ＲＥＳＴアプリケーション７２５および／またはプロバイダリソース７２６は、リバースプロキシサーバ７２０によって公開されたどのＲＥＳＴサービス７２３およびリソース７２８がリバースプロキシサーバ７２上に生成されたかを判断するように構成されてもよい。この例では、ＲＥＳＴアプリケーション７２５は、たとえば、クライアント装置４１０からのＲＥＳＴ要求を扱うために、ＲＥＳＴウェブサービス７２３またはＲＥＳＴリソース７２８をいつ作成すべきかを判断してもよい。ＲＥＳＴアプリケーション７２５は次に、ＲＥＳＴアプリケーションエンジン７４０に、新規のＲＥＳＴサービス７２３および／またはリソース７２８を生成するよう命令してもよい。

図７は、リバースプロキシサーバ７２０内のＲＥＳＴアプリケーションエンジン７４０と、リバースプロキシサーバ７２０と通信するように構成された（たとえば内部ネットワーク４６０内の）ゲートウェイ管理サーバ７５０とを含む。ＲＥＳＴアプリケーションエンジン７４０は、リバースプロキシサーバ７２０内にＲＥＳＴサービス７２３および／またはリソース７２８を生成するように構成された１つ以上のソフトウェアツールまたはプラットフォームを含んでいてもよい。以下に説明されるように、ＲＥＳＴアプリケーションエンジン７４０は、たとえば、ゲートウェイ管理サーバ７５０から受信されたＷＡＤＬファイルを介して、ＲＥＳＴサービスおよび／またはリソース記述データを受信してもよい。ＲＥＳＴアプリケーションエンジン７４０は次に、リバースプロキシサーバ７２０内にＲＥＳＴサービス７２３およびリソース７２８を生成し、構築し、デプロイメントしてもよい。

ここで図８を参照して、リバースプロキシサーバ内にＲＥＳＴサービスおよび／またはリソースを動的に生成するためのプロセスを示すフローチャートが示される。以下に説明されるように、このプロセスにおけるステップは、上述の１つ以上のコンポーネント、たとえば、リバースプロキシサーバ４２０（および／またはリバースプロキシサーバ５２０、７２０、および９２０）、ＲＥＳＴアプリケーションエンジン７４０、ゲートウェイ管理サーバ７５０、および／または、そこに実装されたさまざまなサブシステムおよびサブコンポーネントによって行なわれてもよい。加えて、いくつかの実施形態では、このプロセスにおけるあるステップは、クライアント装置４１０、バックエンドウェブサービス４３０内で、および／または他のさまざまな中間装置によって行なわれてもよい。ウェブサービス記述データを送受信すること、ならびに、ＲＥＳＴサービスおよびリソースを動的に生成することを含む、ここに説明される手法は、上述の特定のシステムおよびハードウェア実装に限定されなくてもよく、ハードウェア、ソフトウェア、およびネットワークコンポーネントの他の組合せを含む他のハードウェアおよびシステム環境内で行なわれてもよい、ということがさらに理解されるべきである。

上述のように、ステップ８０１〜８０４は、プロキシサーバ内にＲＥＳＴサービスおよびリソースを動的に生成するためのプロセスに関して行なわれてもよい。たとえば、ＲＥＳＴサービス７２３およびＲＥＳＴリソース７２８は、構築時間中ではなく実行時間中に、リバースプロキシサーバ７２０内に作成されてもよい。ＲＥＳＴサービスまたはリソースの動的な生成は、実行時間中にリバースプロキシサーバ７２０によって受信されたさまざまな情報に基づいて起動され（またはトリガされ）てもよい。たとえば、要求されたＲＥＳＴリソースがまだリバースプロキシサーバ７２０内に作成されていない場合、クライアント装置４１０から受信されたＲＥＳＴ要求が、リバースプロキシサーバ７２０内での動的なＲＥＳＴサービス／リソース生成プロセスを起動してもよい。別の例として、リバースプロキシサーバ７２０におけるＲＥＳＴサービス７２３をバックエンドウェブサービス７３０と同期させるために、新規のバックエンドウェブサービス７３０のデプロイメント、または既存のバックエンドウェブサービス７３０への修正が、リバースプロキシサーバ７２０内での動的なＲＥＳＴサービス／リソース生成プロセスを起動してもよい。

ステップ８０１で、１つ以上のバックエンドウェブサービス７３０を記述する（および／または定義する）データが、リバースプロキシサーバ７２０内で受信されてもよい。いくつかの実施形態では、ステップ８０１で受信された記述データは、バックエンドウェブサービス７３０および／または信頼できるゲートウェイ管理サーバ７５０によって生成された１つ以上のウェブアプリケーション記述言語（ＷＡＤＬ）ファイルを含んでいてもよい。ＲＥＳＴサービス７３０のためのＷＡＤＬファイルは、リソースＵＲＬ、サポートされた方法、パラメータ、データタイプなどを含む、ＲＥＳＴサービスによって公開されたリソースのすべてを記述してもよい。上述のように、バックエンドウェブサービス７３０は、ＲＥＳＴウェブリソース７３０、ならびに、他のタイプのウェブサービス７３０、たとえばＳＯＡＰウェブサービス、および他のタイプのバックエンドウェブサービス、アプリケーション、ウェブコンテンツなどを含んでいてもよい。このため、ＳＯＡＰウェブサービス７３０については、ＷＡＤＬの代わりにウェブサービス記述言語（Web Service Description Language：ＷＳＤＬ）が使用されてもよく、他の例では、バックエンドウェブサービス７３０のタイプに依存して、さまざまな他のデータフォーマットが使用されてもよい。

受信された記述データのタイプまたはフォーマットにかかわらず、データは、バックエンドウェブリソース７３０の構造およびサポートされた動作を判断するために受信側装置によって構文解析され得るマシン読取可能フォーマットで送信されてもよい。いくつかの実施形態では、記述データ（たとえばＷＡＤＬファイル）は、個々のバックエンドウェブサービス７３０によって生成され、ゲートウェイ管理サーバ７５０に提供され、次にＲＥＳＴアプリケーションエンジン７４０に送信されてもよい。たとえば、ゲートウェイ管理サーバ７５０は、新規のバックエンドウェブサービス７３０のデプロイメント、または既存のバックエンドウェブサービス７３０への修正に応答して、更新された記述データをＲＥＳＴアプリケーションエンジン７４０に自動的に送信してもよい。他の場合、ＲＥＳＴアプリケーションエンジン７４０は、周期的に、またはリバースプロキシサーバ７２０内でイベントが起こるのに応答して、ゲートウェイ管理サーバ７５０から（またはバックエンドウェブサービス７３０から直接）記述データを検索してもよい。

ステップ８０２〜８０４で、リバースプロキシサーバ７２０内のＲＥＳＴアプリケーションエンジン７４０および／または他のコンポーネントは、リバースプロキシサーバ７２０内にＲＥＳＴサービス７２３および／またはＲＥＳＴリソース７２８を生成し、構築し、デプロイメントしてもよい。この例では、ステップ８０２で、ＲＥＳＴアプリケーションエンジン７４０は、バックエンドウェブサービス７３０によって公開されたリソースに基づいて、ＲＥＳＴサービス記述データを修正および／またはカスタマイズしてもよい。ステップ８０３で、ＲＥＳＴアプリケーションエンジン７４０は、ステップ８０２で修正／カスタマイズされたＲＥＳＴサービス記述データを使用して、リバースプロキシサーバ７２０内に１つ以上のダミーｒｅｓｔリソースを作成してもよい。最後に、ステップ８０４で、ＲＥＳＴアプリケーションエンジン７４０および／またはＲＥＳＴインフラストラクチャ７２２は、ステップ８０３で生成されたＲＥＳＴサービス７２３および／またはリソース７２８を、リバースプロキシサーバ７２０内にデプロイメントしてもよい。

いくつかの実施形態では、ＲＥＳＴサービスを生成し、構築するステップは、たとえば、ＲＥＳＴアプリケーションエンジン７４０および／またはＲＥＳＴインフラストラクチャ７２２によって、リバースプロキシサーバ７２０内で行なわれてもよい。しかしながら、他の例では、ＲＥＳＴサービス７２３およびＲＥＳＴリソース７２８は、リバースプロキシサーバ７２０から遠隔で（たとえば内部ネットワーク４６０内に）設計され、生成され、および／または構築されてから、リバースプロキシサーバ７２０に提供され、リバースプロキシサーバ７２０上にデプロイメントされてもよい。

ＲＥＳＴリソース７２８への修正および／またはカスタマイゼーションは、１つ以上のバックエンドウェブサービス７３０を呼び出すためにダミーＲＥＳＴリソースに挿入されたソフトウェアフックおよび／または他のカスタマイズされたソフトウェアコードの形をとってもよい。そのようなソフトウェア修正／カスタマイゼーションは、たとえば、バックエンドＲＥＳＴサービス７３０およびリソース、ならびに、バックエンドウェブサービス７３０へのコールで送信され得る個々の動作（または方法）、パラメータ、および他のデータを識別してもよい。ＲＥＳＴリソース７２８がリバースプロキシサーバ７２０上に構築され、デプロイメントされた後で、バックエンドウェブサービス７３０を呼び出すために、ソフトウェアフックおよび／またはカスタマイズされたソフトウェアコードが実行されてもよい。上述のように、場合によっては、ステップ８０３でＲＥＳＴリソース７２８に挿入されたソフトウェアコードは、対応するバックエンドＲＥＳＴウェブサービス７３０内で、同じＲＥＳＴリソースを呼び出し、パラメータおよび／または本文コンテンツなどを有する同じ方法をコールするように構成された、単純なソフトウェアフックを含んでいてもよい。他の場合、ステップ８０３で修正／カスタマイズされたコードは、異なるＵＲＬパス（たとえば、異なるサブリソースパスまたはリソース名）、異なるＨＴＴＰ方法、異なるＵＲＬパラメータ、および／または異なるヘッダまたは本文データを使用して、１つ以上の異なるバックエンドウェブサービス７３０を呼び出すように設計されてもよい。加えて、上述のように、バックエンドウェブサービス７３０はＲＥＳＴサービスでなくてもよく、ＳＯＡＰサービス、ＵＲＬ、もしくは他のタイプのウェブサービス、ウェブアプリケーション、またはウェブコンテンツであってもよい。そのような場合、ステップ８０３におけるソフトウェアカスタマイゼーション／修正は、ＳＯＡＰおよびＵＲＬコールを生成するための、および／または、さまざまな異なるタイプのバックエンドウェブサービス、アプリケーション、ウェブコンテンツなどを呼び出すためのカスタムコードを含んでいてもよい。

ステップ８０４でリバースプロキシサーバ７２０内にＲＥＳＴリソース７２８をデプロイメントする場合、各リソース７２８は、リソース７２８のＵＲＬに従って、ＲＥＳＴサービス７２３内に階層的にデプロイメントされてもよい。上述のように、ＲＥＳＴサービスは、サービス７２３内で最高レベルのリソースであり（たとえば、サービスの「／」パスにマッピングされる）、異なる要求を扱うであろうサブリソース７２８（または子リソース）を識別することを担当するルートリソースを有していてもよい。

図９は、ポリシー実施エンジン９６０を含むリバースプロキシサーバ９２０の要素およびシステムを示すブロック図である。この例のリバースプロキシサーバ９２０はリバースプロキシ４２０（および／または５２０ならびに７２０）に対応していてもよく、リバースプロキシサーバ９２０のさまざまなサブコンポーネント９２１〜９２３は、上述の対応するサブコンポーネントと同様または同一であってもよい。加えて、リバースプロキシサーバ９２０は、コンピューティング環境４００または他の同様の環境内で動作してもよく、クライアントコンピューティング装置とバックエンドウェブサービスとの間でメッセージを処理して送信するように構成されてもよい。したがって、リバースプロキシサーバ９２０は、図４Ａ〜図４Ｂ、図５、および／または図７を参照して上述されたハードウェア、ソフトウェア、およびネットワーキングコンポーネントならびに機能性のうちのいくつかまたはすべてを含んでいてもよい。

要求ハンドラ９２１、ＲＥＳＴ実装９２２、およびＲＥＳＴサービス９２３に加えて、この例は、リバースプロキシサーバ９２０内のポリシー実施エンジン９６０を示す。この例では、ＲＥＳＴサービス９２３およびそれらのそれぞれのＲＥＳＴリソース４２８は、呼び出されるべき任意のバックエンドウェブサービスコールをポリシー実施エンジン９６０に提供してもよい。ポリシー実施エンジン９６０は、バックエンドウェブサービスコールを処理し、バックエンドウェブサービス９３０を呼び出す前および／または後にさまざまなセキュリティポリシーおよび他の通信管理ポリシーを実施してもよい。

ポリシー実施エンジン９６０は、リバースプロキシサーバ９２０内でセキュリティポリシーおよび他の通信管理ポリシーを実現するように構成されたさまざまなセキュリティシステムまたはコンポーネントを含んでいてもよい。この例では、ポリシー実施エンジン９６０は、メッセージスロットリングシステム９６１と、認証および認可システム９６２と、キー管理システム９６３と、トークン仲介システム９６４とを含む。ポリシー実施エンジン９６０内のこれらのシステムおよびセキュリティコンポーネントは、クライアント装置４１０からのメッセージを認証する、セキュリティトークン仲介を提供する、ＡＰＩキー管理を行なう、きめの細かい認可および／またはデータ改訂を行なう、機密性および完全性をサポートする、リスクベースの認証を行なう、モバイルクライアント装置４１０のための装置ベースのセキュリティを行なう、非武装ゾーン（ＤＭＺ）脅威保護をサポートする、プロトコルおよびペイロード仲介を行なう、などといったことをしてもよい。たとえば、認証／認可システム９６２は、サービス妨害（Denial of Service：ＤｏＳ）攻撃を防止し、不正な形式のメッセージを検出してフィルタリングし、ＳＱＬ、ＪａｖａＳｃｒｉｐｔ、および／またはＸＰａｔｈ／ＸＱｕｅｒｙインジェクション攻撃を検出して防止し、悪意のあるコンテンツから保護するためにメッセージ確認を行なう（たとえば、メッセージ添付物内のウィルスを検出する、ＸＭＬおよびＪＳＯＮデータ構造を確認する、形状およびクエリパラメータを確認するなど）ためのサブシステムを含んでいてもよい。トークン仲介システム９６４は、特定されたクライアント装置４１０とバックエンドウェブサービス９３０との間で認証トークンを変換するように構成されてもよい。セキュリティシステム９６１〜９６４はまた、たとえば、複数のバックエンドＡＰＩまたはサービスを集め、自動仲介または合成を行なうことによって、動作のオーケストレーションおよび除去をサポートしてもよい。

加えて、この例では、ポリシー実施エンジン９６０は、メッセージ処理ポリシー９６５のデータストアを含む。メッセージ処理ポリシーは、ＸＭＬ、JavaScript、または他のタイプの実行可能ソフトウェアコンポーネントといったさまざまな形のコンピュータ読取可能媒体に格納されてもよい。以下により詳細に説明されるように、メッセージ処理ポリシー９６５は、リバースプロキシサーバ９２０内でセキュリティポリシーおよび他の通信管理ポリシーを実施するために使用されてもよい。データストア９６５は、個々のメッセージのためのエンドツーエンド処理フロー中のさまざまな段階で検索され、個々のメッセージに適用され得る、個々のメッセージ処理ポリシーを含んでいてもよい。メッセージ処理ポリシーデータストア９６５は、この例に示すようにリバースプロキシサーバ９２０に存在していてもよく、もしくは、信頼できる内部コンピュータネットワーク４６０のバックエンドサーバ、または安全な第三者サーバなどの内部に存在していてもよい。

ここで図１０を参照して、メッセージ処理ポリシーを判断し、ＲＥＳＴ要求および他のバックエンドウェブサービスコールといったメッセージを処理するためのプロセスを示すフローチャートが示される。以下に説明されるように、メッセージ処理ポリシーの判断および実施は、リバースプロキシサーバ９２０（および／または４２０、５２０、ならびに７２）における１つ以上のコンポーネントによって、そこに実装されたさまざまなサブシステムおよびサブコンポーネントとともに行なわれてもよい。加えて、いくつかの実施形態では、このプロセスにおけるあるステップは、クライアント装置４１０、バックエンドウェブサービス９３０内で、および／または他のさまざまな中間装置によって行なわれてもよい。エンドツーエンドメッセージ処理フローを監視すること、メッセージ処理ポリシーを判断すること、およびメッセージ処理ポリシーを実施することを含む、ここに説明される手法は、上述の特定のシステムおよびハードウェア実装に限定されなくてもよく、ハードウェア、ソフトウェア、およびネットワークコンポーネントの他の組合せを含む他のハードウェアおよびシステム環境内で行なわれてもよい、ということがさらに理解されるべきである。

ステップ１００１で、ポリシー実施エンジン９６０は、ＲＥＳＴサービス９２３から受信されたメッセージを分析して、メッセージの宛先バックエンドサービス９３０、およびメッセージを起動したクライアント装置４１０を判断してもよい。メッセージの宛先は、ＲＥＳＴサービス９２３によって生成されたバックエンドウェブサービスコール（たとえば、ＲＥＳＴ要求、ＳＯＡＰ要求、またはウェブコンテンツ要求）を構文解析し、分析することによって判断されてもよい。たとえば、ＲＥＳＴまたはＳＯＡＰ要求のユニフォームリソース識別子（ＵＲＩ）、もしくは、ウェブサービスまたはアプリケーションの識別子、および／またはメッセージ本文内の動作識別子が、内部ネットワーク４６０によって提供されるバックエンドウェブサービス／アプリケーション９３０またはウェブコンテンツに対応していてもよい。この例では、プロキシサーバ９２０は、メッセージヘッダおよびコンテンツに基づいて、メッセージは内部ネットワーク４６０内のウェブサービス９３０をホストする特定のコンピュータサーバに向けられていると判断してもよい。ソースＩＰアドレスまたはホスト名識別子といった、メッセージの送信元を識別するメッセージ内の情報も、メッセージの意図された宛先を判断するために使用されてもよい。メッセージの意図された宛先を判断することに加え、プロキシサーバ４２０は、メッセージを起動したクライアント装置４１０を判断してもよい。

ステップ１００２で、ポリシー実施エンジン９６０は、バックエンドウェブサービス９３０に送信されるべきメッセージのための予め定められた処理フローにおける現在点を判断してもよい。メッセージ処理フローとは、プロキシサーバ９２０によるクライアント装置４１０からのメッセージの受信で始まり、プロキシサーバ９２０によるクライアント装置４１０への応答の送信で終わる、プロキシサーバ９２０によって実行されるべきエンドツーエンドメッセージ処理フローを指してもよい。以下に説明されるように、メッセージのための予め定められた処理フローにおける現在点を判断することは、メッセージに関連付けられたポリシーモデルを識別し、処理モデル内の現在の処理位置を判断することを含んでいてもよい。

いくつかの実施形態では、メッセージのための予め定められたメッセージ処理フローは、ポリシーモデルによって定義されてもよい。ポリシーモデルは、メッセージのエンドツーエンドメッセージ処理フロー中のさまざまな点でメッセージを処理するためにポリシー実施エンジン９６０によって適用され得る一組のポリシー（たとえば、セキュリティポリシー、通信管理ポリシーなど）を定義するデータを含んでいてもよい。メッセージのエンドツーエンド処理フローを定義するポリシーモデル、および個々のメッセージ処理ポリシーは双方とも、ＸＭＬ、JavaScript、または他のタイプの実行可能ソフトウェアコンポーネントといったさまざまな形のコンピュータ読取可能媒体であってもよい。ポリシーモデルおよび／またはメッセージ処理ポリシーは、ポリシー実施エンジン９６０内に、たとえばデータストア９６５に、または内部ネットワーク４６０内の他のところに格納されてもよい。

上述のように、ポリシーモデルは、ポリシー実施エンジン９６０がメッセージのエンドツーエンド処理フローにおけるさまざまな点でメッセージに適用し得る一組のメッセージ処理ポリシーを定義してもよい。いくつかの実施形態では、ステップ１００２で、ポリシー実施エンジン９６０は、ＲＥＳＴサービス９２３から受信されたメッセージの特性に依存して、異なるポリシーモデルを適用してもよい。たとえば、ポリシー実施エンジン９６０によって検索され適用される特定のポリシーモデルは、メッセージの意図された宛先、および／または、要求を起動したクライアント装置４１０に依存していてもよい。加えて、ポリシー実施エンジン９６０によって検索され適用されるポリシーモデルは、メッセージを送信するために使用されるネットワークプロトコル、および／または、メッセージの要求タイプまたはクライアントタイプに依存していてもよい。たとえば、ＲＥＳＴ要求、ＳＯＡＰ要求、ウェブコンテンツ（ＵＲＬ）要求などのために、異なるポリシーモデルが使用されてもよい。

いくつかの例では、ポリシーモデルは、ＸＭＬまたは他のマシン読取可能フォーマットで実装されてもよい。ポリシーモデルは、処理フロー内のさまざまな点（「アサーション」とも呼ばれ得る）のタグまたは識別子、および、処理点／アサーションの各々についての１つ以上のポリシー識別子を含んでいてもよい。たとえば、ポリシーモデルは、要求が受信されると行なわれるべきポリシー（「on-request」タグ内）、メッセージ変換を行なうポリシー（「message-transformation」タグ内）、および、バックエンドウェブサービスが呼び出されると行なわれるべきポリシー（「on-invoke」タグ内）を識別してもよい。

いくつかの実施形態では、ポリシー実施エンジン９６０は、サービスレベル（またはＵＲＬレベル）で、および／または動作レベル（または方法レベル）でポリシーを適用してもよい。したがって、バックエンドウェブサービス９３０を呼び出す場合、ポリシー実施エンジン９６０はまず、動作（ＳＯＡＰについて）または方法（ＲＥＳＴおよびＵＲＬについて）を判断してから、ポリシーモデル内で識別されたポリシーを実施できるようになっていてもよい。

ＲＥＳＴサービス９２３から受信されたメッセージに関連付けられたポリシーモデル（または処理フローを定義する他のデータ）を識別した後で、ポリシー実施エンジン９６０は、ポリシーまたは処理フローに従って、メッセージ処理における現在点を判断してもよい。メッセージ処理フローにおける現在点は、メッセージ自体の特性によって、および、メッセージの以前の処理に関する以前に格納されたデータに基づいて判断されてもよい。上述のように、予め定められた処理フローは、クライアント装置４１０による最初の要求から、クライアント装置４１０に返送された応答までの、メッセージのためのエンドツーエンド処理を適用してもよい。したがって、メッセージが、クライアント装置４１０からの最初の要求であるか、クライアント装置からの追加データ（たとえば、要求に関する認証クレデンシャルまたは追加データ）の送信であるか、バックエンドウェブサービス９３０からの応答であるか、もしくは、バックエンドサーバまたは装置からの追加データ（たとえば、シングルサインオンまたはトークン翻訳サービスからのデータ）の送信であるかを判断することは、ポリシー実施エンジン９６０が、エンドツーエンドメッセージ処理フロー内のメッセージ処理の現在点を判断することを可能にし得る。加えて、ポリシー実施エンジン９６０は、ポリシー実施エンジン９６０がメッセージに適用すべき次のメッセージ処理ポリシーを判断するために、以前のメッセージ変換、サービスの呼び出し、遭遇した処理エラーの結果といった、メッセージまたは他の関連するメッセージに対して行なわれた以前の処理に関連するデータを格納してもよい。

以下の段落は、メッセージ処理ポリシーが適用され得る、ポリシーモデルまたは他のメッセージ処理フロー内の可能な点（「アサーション」とも呼ばれ得る）のいくつかの例を含む。これらの例は単なる例示であり、網羅的なリストでなくてもよい、ということが理解されるべきである。また、ここに説明されるアサーション名（たとえば、OnRequest、OnInvoke、OnResponse、OnError、MessageTransformationなど）、ならびに、アサーションおよびポリシーに使用されるＸＭＬ構造およびタグ名は、さまざまな他の実施形態において変更されてもよい。

ステップ１００２でポリシーモデルまたは他の予め定められたメッセージ処理フロー内の現在点を判断する第１の例は、受信されたメッセージが外部コンピュータネットワークにおけるクライアント装置４１０からの要求に対応していると判断することを含んでいてもよい。メッセージのエンドツーエンド処理フローの初めにあるこの点は、「OnRequest」アサーションなどと呼ばれてもよい。以下により詳細に説明されるように、OnRequestアサーションは、仮想サービス、プロキシサービス、および／またはウェブアプリケーションを安全にするために適用され得るポリシーへの参照を含んでいてもよい。たとえば、OnRequestアサーションは、外部クライアント装置４１０から受信された新規のウェブサービス／アプリケーション／コンテンツ要求のためにポリシー実施エンジン９６０が実施すべきセキュリティポリシーを表わすＵＲＩまたは他の識別子を含んでいてもよい。OnRequestアサーションはまた、他のポリシーを参照してもよく、および／または、他のアサーションを含んでいてもよい。場合によっては、OnRequestアサーションは、リバースプロキシモードでのみ動作してもよく、すなわち、外部クライアント装置４１０からの内部ウェブサービス９３０に対する要求のみを扱ってもよい。

ステップ１００２で起こり得る現在のメッセージ処理点の別の判断は、クライアント装置４１０から要求を受信した後で、プロキシサーバ９２０はバックエンドウェブアプリケーションまたはウェブサービス９３０に要求を送信すべきであると判断することを含んでいてもよい。メッセージのエンドツーエンド処理フロー内のこの点は、「OnInvoke」アサーションなどと呼ばれてもよい。OnRequestアサーションと同様に、いくつかの実施形態では、OnInvokeアサーションは、内部ネットワーク４６０内のバックエンドウェブサービス／アプリケーション９３０を呼び出すために最初の要求がクライアント装置４１０から受信されたリバースプロキシ使用事例にのみ当てはまり得る。OnInvokeアサーションは、エンドツーエンド処理フローにおけるこの点でポリシー実施エンジン９６０が実施すべきポリシーを表わすＵＲＩまたは他の識別子を含んでいてもよい。たとえば、複数のＸＭＬ「ポリシーＵＲＩ」ＸＭＬ要素を使用することによって、複数のポリシー識別子（または参照）がOnInvokeアサーション内に含まれてもよい。加えて、OnInvokeアサーションは、クライアントのリソースパターンを使用することから、クライアント詳細を一意的に識別してもよい。OnInvokeアサーションに使用されるクライアントタイプ（たとえば、ＲＥＳＴクライアント、ＳＯＡＰクライアント、ＵＲＬ／ウェブクライアントなど）は、OnInvokeアサーション内に構成された値に基づいて、実行時間にポリシー実施エンジン９６０によって判断されてもよい。OnInvokeアサーションはまた、他のポリシーを参照してもよく、および／または、他のアサーションを含んでいてもよい。

現在のメッセージ処理点を判断する別の例は、クライアント装置４１０から要求を受信した後で、およびバックエンドウェブサービス４３０を呼び出した後で、プロキシサーバ９２０はクライアント装置４１０に応答を送信すべきであると判断することを含んでいてもよい。メッセージのエンドツーエンド処理フロー内のこの点は、「OnResponse」アサーションなどと呼ばれてもよい。OnRequestおよびOnInvokeアサーションと同様に、いくつかの実施形態では、OnResponseアサーションは、内部ネットワーク４６０内のバックエンドウェブサービス９３０を呼び出すために最初の要求がクライアント装置４１０から受信されたリバースプロキシ使用事例にのみ当てはまり得る。OnResponseアサーションは、エンドツーエンド処理フローにおけるこの点でポリシー実施エンジン９６０が実施すべきポリシーを表わすＵＲＩまたは他の識別子を含んでいてもよい。複数のポリシー識別子（または参照）がOnResponse内に含まれてもよく、OnResponseアサーションはまた、他のポリシーを参照してもよく、および／または、他のアサーションを含んでいてもよい。

現在のメッセージ処理点を判断する別の例は、エンドツーエンド処理フロー中のいずれかの点で、プロキシサーバ９２０はあるメッセージタイプから別のメッセージタイプにメッセージを変換すべきであると判断することを含んでいてもよい。メッセージのエンドツーエンド処理フロー内のこの点は、「MessageTransformation」アサーションなどと呼ばれてもよい。たとえば、プロキシサーバ９２０は、第１のメッセージタイプ（たとえばＲＥＳＴ要求）を有するメッセージを受信し、メッセージを分析して、メッセージは、第２のメッセージタイプ（たとえばバックＳＯＡＰサービス）のみを受け入れるバックエンドサービスまたはアプリケーションに向けられていると判断してもよい。そのような判断の後で、ポリシー実施エンジン９６０は、メッセージに対して適切なMessageTransformationアサーションを実行してから、変換されたメッセージを意図された宛先に送信してもよい。ポリシー実施エンジン９６０によってサポートされ得る変換ポリシーの例は、ＸＭＬからJavaScriptオブジェクト表記法（ＪＳＯＮ）へのポリシー、およびＪＳＯＮからＸＭＬへのポリシー、ＸＭＬからＳＯＡＰへのポリシー、およびＳＯＡＰからＸＭＬへのポリシー、ならびに、ＪＳＯＮからＳＯＡＰへのポリシー、およびＳＯＡＰからＪＳＯＮへのポリシーを、何ら限定されることなく含んでいてもよい。他の周知の媒体タイプ間の変換が、さまざまな実施形態においてサポートされてもよい。ポリシー実施エンジン９６０は、バックエンドサービス仮想化の際に適切な変換ポリシーを自動的に添付してもよく、変換は、プロキシサーバ９２０に、またはコンピューティング環境における他のところにインストールされた１つ以上の翻訳フレームワークを使用して行なわれてもよい。

現在のメッセージ処理点を判断するさらに別の例は、メッセージのためのエンドツーエンド処理フロー中のいずれかの点でエラーが起こったと判断することを含んでいてもよい。メッセージのエンドツーエンド処理フロー内のこの点は、「OnError」アサーションなどと呼ばれてもよい。メッセージのためのOnErrorアサーションをトリガしている（たとえば、メッセージに関連付けられたOnErrorアサーションで識別された１つ以上のポリシーの実行をトリガしている）エラーは、リバースプロキシサーバ９２０によって行なわれた処理内で起こったエラー、および／または、バックエンドコンピュータサーバまたは装置からリバースプロキシサーバ９２０によって受信されたエラーであってもよい。たとえば、リバースプロキシサーバ９２０は、認可サービス、トークン翻訳サービス、またはバックエンドウェブサービス９３０といったメッセージの処理フロー中に呼び出されたバックエンドコンピュータサーバからエラー表示を受信してもよい。加えて、リバースプロキシサーバ９２０は、メッセージ処理タスクを行ないながら、メッセージを構文解析または確認する際のエラー、もしくはメッセージ変換ポリシーを実行する際のエラー、といったエラーを識別または生成してもよい。このため、特定のメッセージ処理ポリシーが適用され得る処理フロー内の点（「アサーション」とも呼ばれる）の以前の例のうちのいくつかとは異なり、OnErrorアサーションは条件付きであってもよい。すなわち、メッセージのエンドツーエンド処理フロー中、ポリシー実施エンジン９６０は、処理中に起こり得るエラーの数およびタイプに依存して、OnErrorアサーションからポリシーを１回、複数回、適用してもよく、または全く適用しなくてもよい。

ステップ１００３で、ステップ５０１で受信されたメッセージを処理するための１つ以上の特定のポリシーが、ポリシー実施エンジン９６０によって判断されてもよい。上述のように、リバースプロキシサーバ９２０によって選択され、メッセージに適用される特定のポリシーは、セキュリティポリシーおよび任意の他のタイプの通信管理ポリシーを含んでいてもよい。たとえば、および何ら限定されることなく、そのようなポリシーは、とりわけ、認証、認可、監査、シングルサインオン、セキュリティポリシー実施、キー管理および分散、安全な通信、安全なデータ格納、および安全なデータ共有に関連する機能を行なってもよい。

ステップ１００３で、ポリシー実施エンジン９６０によって、まず、メッセージに関連付けられたエンドツーエンド処理フロー（たとえばポリシーモデル）を検索し、次に、ステップ１００２で判断されたエンドツーエンド処理フロー内の現在点（たとえばアサーション）を使用して、エンドツーエンドフローにおける現在点でメッセージに適用されるであろう特定のポリシーを識別することにより、ポリシーが選択されてもよい。たとえば、メッセージが、クライアント装置４１０からのバックエンドウェブサービス４３０に対する要求である場合、ポリシー実施エンジン９６０は、メッセージのためのエンドツーエンド処理フローを支配するポリシーモデルの「on-request」タグ内で識別された任意のポリシーを検索してもよい。

ステップ１００４で、ポリシー実施エンジン９６０は、ステップ１００３で選択されたポリシーを使用してメッセージを処理してもよい。上述のように、ポリシー実施エンジン９６０は、メッセージのための予め定められたエンドツーエンド処理フローからＵＲＩまたは他のポリシー識別子を識別することによって、メッセージに適用されるべき適切なポリシーを判断してもよい。いくつかの実施形態では、ポリシーモデルは、エンドツーエンド処理フローにおける現在点に対応するアサーションに依存して、適用されるべきポリシーのためのポリシーＵＲＩ（または他の識別子）を含んでいてもよい。そのようなポリシーＵＲＩは、ポリシーの格納位置を参照してもよい。他の例では、ポリシー識別子はＵＲＩとして表わされなくてもよく、ＡＰＩまたはサービス識別子、機能名、方法名、および／または動作名などといった他の識別データを含んでいてもよい。いずれにせよ、ポリシー識別子は、メッセージ処理ポリシーのための格納位置または他のアクセス情報を識別してもよい。ポリシー自体は、ＸＭＬ、JavaScript、または他のタイプの実行可能ソフトウェアコンポーネントといったさまざまな形のコンピュータ読取可能媒体に格納されてもよい。

メッセージ処理ポリシーは、コンピューティング環境内のさまざまな異なるサーバまたは装置に位置する、データベースおよび／またはファイルベースの記憶システムといったデータストアに格納されてもよい。たとえば、比較的不変であるかもしれず、安全なデータを有さない、メッセージ変換ポリシー、メッセージスロットリングポリシー、ロードバランシングポリシー、および他のポリシー、といったあるポリシーは、プロキシサーバ９２０内に（たとえば、メッセージ処理ポリシーデータストア９６５内に）局所的に格納されてもよい。しばしば変わり得る、または安全なデータを含み得る、ユーザ認証／認可ポリシー、および他のポリシー、といった他のポリシーは、信頼できる内部コンピュータネットワーク４６０の安全なサーバまたは記憶システム内に格納されてもよい。他の場合、あるポリシーは、外部ネットワークにおける安全な第三者サーバまたはクライアント装置４１０上に格納されてもよい。ポリシー実施エンジン９６０は、ステップ１００４でこれらのさまざまな位置のいずれかからポリシーを検索し、適用するように構成されてもよい。

ステップ１００４でさまざまなセキュリティポリシーおよび／または他の通信管理ポリシーを使用してメッセージを処理した後で、ステップ１００５で、リバースプロキシサーバ９２０は、処理されたメッセージをその意図された宛先に送信してもよい。上述のように、意図された宛先は、ステップ１００１でメッセージヘッダおよび／またはメッセージ本文の一部を構文解析し、分析することによって判断されてもよい。バックエンドウェブサービス９３０への要求といったメッセージの意図された宛先は、内部ネットワーク４６０内にあってもよい。それに代えて、外部ウェブサービスまたはアプリケーションへの要求、もしくはクライアント装置４１０への応答または他の送信といったメッセージの意図された宛先は、外部ネットワーク内にあってもよい。

上述のように、プロキシサーバ９２０内でメッセージを処理するための特定のポリシーの選択および適用は、そのメッセージのための予め定められたエンドツーエンド処理フローによって、エンドツーエンドフロー内のメッセージのための現在の処理点の判断とともに判断されてもよい。上に紹介されたポリシーモデルは、ポリシー実施エンジン９６０がメッセージのエンドツーエンド処理フローにおけるさまざまな点でメッセージに適用し得る一組のメッセージ処理ポリシーを定義してもよい。いくつかの実施形態では、エンドツーエンド処理フローを定義するためのポリシーモデルおよび他の手法は、一組のポリシーテンプレートを使用して作成されてもよい。そのようなテンプレートは特定のアサーションに対応していてもよく、ポリシーモデルエンドツーエンド処理フローを作成するために使用されてもよい。たとえば、１つ以上のアサーションテンプレートがコピーされてもよく、適切なポリシーＵＲＩが各テンプレートコピーに挿入されてもよい。カスタマイズされたテンプレートは次に、エンドツーエンド処理フロー中に実行され得るポリシーを定義するために、適切なポリシーモデルに追加されてもよい。

エンドツーエンド処理フロー中に実行されるべきアサーションおよびポリシーを定義することに加えて、ポリシー実施エンジン９６０によって実施されたポリシーモデル（および予め定められたエンドツーエンド処理フローの他の形）は、あるポリシーが行なわれ得る、または行なわれない条件も定義してもよい。いくつかの実施形態では、ポリシーモデルは、ポリシーモデルで参照されるポリシーの各々を行なうための条件を実現するための一組の論理命令を含んでいてもよい。たとえば、ポリシーモデルは、あるポリシーが、あるメッセージタイプ（たとえば、ＳＯＡＰ、ＲＥＳＴ、またはＵＲＬメッセージ）については実行されるべきであるものの、他のメッセージタイプについては実行されるべきではないことをプロキシサーバ９２０に命令する条件を含んでいてもよい。加えて、上述のように、ポリシーモデルは、場合によっては、サービス／アプリケーションレベルで、および／または動作／方法レベルでポリシーを選択的に適用してもよく、このため、特定のポリシーの適用は、呼び出されているバックエンドウェブサービス９３０にだけでなく、サービス９３０内でコールされている特定の動作または方法にも依存していてもよい。さまざまな追加の実施形態では、いくつかのポリシーモデルは、あるポリシーが、あるユーザについては実行されるべきであるものの、他のユーザについては実行されるべきではないこと、あるクライアント装置タイプについては実行されるべきであるものの、他のクライアント装置タイプについては実行されるべきではないこと、あるバックエンドウェブサービス／アプリケーションについては実行されるべきであるものの、他のバックエンドウェブサービス／アプリケーションについては実行されるべきではないこと、および／またはメッセージに関連する任意の他の特性をポリシー実施エンジン９６０に命令する条件を含んでいてもよい。

上述の例が示すように、ここに説明されたさまざまな実施形態は、異なるセキュリティポリシーおよび他の通信管理ポリシーが、ＤＭＺもしくは他の論理的または物理的サブネットワーク内で、メッセージのエンドツーエンド処理フロー全体にわたるさまざまな異なる処理点で適用され得る、動的ポリシーモデルをサポートしてもよい。この動的ポリシーモデルフレームワークは、悪意のある外部コンピューティングシステムからの攻撃を防止するための追加のセキュリティを構築し実現するために使用されてもよく、ラストマイルセキュリティインフラストラクチャ内（たとえば、バックエンドウェブサービス／アプリケーション４３０内）では可能ではなかったかもしれない、または好ましくなかったかもしれない、追加のタイプのセキュリティポリシーを実現してもよい。加えて、ここに説明された動的ポリシーモデルを使用して、トークン翻訳および／またはシングルサインオンアクセス制御システムといった、頑強な認証および認可システムが実現されてもよい。たとえば、クライアント装置４１０は、ユーザ名／パスワードまたは他のユーザクレデンシャルを介して認証してもよく、予め定められたエンドツーエンド処理フローは、異なるタイプのさまざまな異なるアクセストークン（たとえば、Kerberosトークン、ＳＰＮＥＧＯトークン、ユーザ名トークン、ＮＴＬＭトークン、ＳＡＭＬトークンなど）を検索または生成するために、内部ネットワーク４６０内の信頼できる認証／認可サービスからのトークン検索および確認を行なうプロキシサーバ４２０内で実行されてもよい。したがって、ユーザが一組の有効なクレデンシャルを提供し、順調に認証および認可された後で、プロキシサーバ４２０内のさまざまなポリシーモデルを使用して、ユーザが次にアクセスするさまざまな異なるバックエンドウェブサービス／アプリケーション４３０のための対応するトークンタイプを検索または生成することによって、シングルサインオンアクセス制御システムを実現してもよい。

本願の一実施形態によれば、処理部と通信部とを含むシステムが提供される。そのようなシステムは、この発明の原理を実行するために、ハードウェア、ソフトウェア、またはハードウェアとソフトウェアとの組合わせによって実現されてもよい。処理部および通信部は、図３に示すコンポーネントといった上述のコンポーネントによって実現されてもよい、ということが当業者には理解される。一方、処理部および通信部は、上述されたようなこの発明の原理を実現するために、組合わされてもよく、またはサブユニットへと分離されてもよい、ということが当業者には理解される。したがって、ここでの説明は、ここに説明された機能部の任意の可能な組合せまたは分離またはさらなる定義をサポートしてもよい。

上述の実施形態の例では、処理部および通信部は、以下の動作を行なうために協働することができ、動作は、外部コンピュータネットワークにおけるクライアント装置からウェブサービス要求を受信する動作を含み、システムは、外部コンピュータネットワークとは別の内部コンピュータネットワークのサブネットワーク内で動作するように構成されており、動作はさらに、ウェブサービス要求内の第１のリソースを識別する動作と、第１のリソースがシステム内の第１のレプリゼンテーショナル・ステート・トランスファー（ＲＥＳＴ）ウェブサービスによって公開されると判断する動作と、システム内の第１のＲＥＳＴウェブサービスを呼び出す動作と、システム内の第１のＲＥＳＴウェブサービスの実行中、内部コンピュータネットワークにおけるコンピュータサーバ内の第２のウェブサービスを呼び出す動作とを含む。

別の例では、処理部および通信部は、以下の動作を行なうことにより、ＲＥＳＴウェブサービスを呼び出すように協働することができ、動作は、第１のＲＥＳＴウェブサービスによって公開された第１のリソースが、処理部に関連付けられたメモリ内に存在しないと判断する動作と、第１のリソースをメモリ内に生成する動作とを含み、第１のリソースは、ウェブサービス要求がクライアント装置から受信された後に生成される。

別の例では、処理部および通信部は、以下の動作をさらに行なうように協働することができ、動作は、内部コンピュータネットワークにおけるコンピュータサーバ内の第２のウェブサービスによって提供される一組のリソースを記述するウェブアプリケーション記述言語（ＷＡＤＬ）ファイルにアクセスする動作と、第２のウェブサービスによって提供される一組のリソースのＷＡＤＬファイルにおける記述を使用して、第１のＲＥＳＴウェブサービスにおいて１つ以上のリソースを生成する動作とを含む。

さらに別の例では、処理部および通信部は、以下の動作を行なうことにより、システム内の第１のＲＥＳＴウェブサービスにおいてリソースを生成するように協働することができ、動作は、ＷＡＤＬファイル内の１つ以上のリソース記述を修正する動作と、修正されたリソース記述に基づいて１つ以上のＲＥＳＴリソースを作成する動作と、ＲＥＳＴリソースの各々をシステム内の第１のＲＥＳＴウェブサービスにデプロイメントする動作とを含む。

前述の説明では、例示のために、方法は特定の順序で説明された。代替的な実施形態では、方法は、説明されたものとは異なる順序で行なわれてもよい、ということが理解されるべきである。上述の方法はハードウェアコンポーネントによって行なわれてもよく、もしくは、汎用または専用プロセッサ、もしくは命令でプログラミングされた論理回路といったマシンに方法を行なわせるために使用され得るマシン実行可能命令のシーケンスで具現化されてもよい、ということも理解されるべきである。これらのマシン実行可能命令は、１つ以上のマシン読取可能媒体またはメモリ装置、たとえば、ＣＤ−ＲＯＭまたは他のタイプの光ディスク、フロッピーディスケット、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気カードまたは光カード、フラッシュメモリ、もしくは、電子命令を格納するのに好適である他のタイプのマシン読取可能媒体またはメモリ装置上に格納されてもよい。それに代えて、方法は、ハードウェアとソフトウェアとの組合わせによって行なわれてもよい。

この発明の例示的で現在好ましい実施形態がここに詳細に説明されてきたが、発明の概念は他のやり方でさまざまに具現化され採用されてもよいこと、および、添付された請求項は、先行技術によって限定される場合を除き、そのような変更を含むと解釈されるよう意図されていることが理解されるべきである。

Claims (11)

1. コンピュータネットワーク間でウェブサービス要求を送信する方法であって、前記方法は、
   内部コンピュータネットワークと通信しているプロキシサーバで、前記内部コンピュータネットワークとは別の外部コンピュータネットワークにおけるクライアント装置からのウェブサービス要求を受信するステップと、
   前記ウェブサービス要求内の第１のリソースを識別するステップと、
   前記第１のリソースが前記プロキシサーバ内の第１のレプリゼンテーショナル・ステート・トランスファー（ＲＥＳＴ）ウェブサービスによって公開されると判断するステップと、
   前記プロキシサーバ内の前記第１のＲＥＳＴウェブサービスを呼び出すステップと、
   前記プロキシサーバ内の前記第１のＲＥＳＴウェブサービスの実行中、前記内部コンピュータネットワークにおけるコンピュータサーバ内の第２のウェブサービスを呼び出すステップとを含み、
   前記プロキシサーバ内の前記第１のＲＥＳＴウェブサービスを呼び出すステップは、
   前記第１のＲＥＳＴウェブサービスによって公開された前記第１のリソースが前記プロキシサーバ内に存在しないと判断するステップと、
   前記第１のリソースを前記プロキシサーバ内に生成するステップとを含み、前記第１のリソースは、前記ウェブサービス要求が前記クライアント装置から受信された後に生成される、方法。
2. コンピュータネットワーク間でウェブサービス要求を送信する方法であって、前記方法は、
   内部コンピュータネットワークと通信しているプロキシサーバで、前記内部コンピュータネットワークとは別の外部コンピュータネットワークにおけるクライアント装置からのウェブサービス要求を受信するステップと、
   前記ウェブサービス要求内の第１のリソースを識別するステップと、
   前記第１のリソースが前記プロキシサーバ内の第１のレプリゼンテーショナル・ステート・トランスファー（ＲＥＳＴ）ウェブサービスによって公開されると判断するステップと、
   前記プロキシサーバ内の前記第１のＲＥＳＴウェブサービスを呼び出すステップと、
   前記内部コンピュータネットワークにおけるコンピュータサーバ内の第２のウェブサービスによって提供される一組のリソースを記述するウェブアプリケーション記述言語（ＷＡＤＬ）ファイルにアクセスするステップと、
   前記第２のウェブサービスによって提供される前記一組のリソースの前記ＷＡＤＬファイルにおける記述を使用して、前記プロキシサーバ内の前記第１のＲＥＳＴウェブサービスにおいて１つ以上のリソースを生成するステップと、
   前記プロキシサーバ内の前記第１のＲＥＳＴウェブサービスの実行中、前記内部コンピュータネットワークにおける前記コンピュータサーバ内の前記第２のウェブサービスを呼び出すステップとを含む、方法。
3. 前記プロキシサーバ内の前記第１のＲＥＳＴウェブサービスにおいて前記リソースを生成するステップは、
   前記ＷＡＤＬファイル内の１つ以上のリソース記述を修正するステップと、
   修正された前記リソース記述に基づいて１つ以上のＲＥＳＴリソースを作成するステップと、
   前記ＲＥＳＴリソースの各々を前記プロキシサーバ内の前記第１のＲＥＳＴウェブサービスにデプロイメントするステップとを含む、請求項２に記載の方法。
4. 前記第２のウェブサービスは、前記内部コンピュータネットワークにおける前記コンピュータサーバ内のＲＥＳＴウェブサービスである、請求項１〜３のいずれか１項に記載の方法。
5. 前記プロキシサーバ内の前記第１のＲＥＳＴウェブサービスは、第２のＲＥＳＴウェブサービスを呼び出すように構成された少なくとも１つのリソースを含み、かつ、前記内部コンピュータネットワークにおける異なるコンピュータサーバによって公開された第３のＲＥＳＴウェブサービスを呼び出すように構成された少なくとも１つのリソースを含む、複数のリソースを公開する、請求項４に記載の方法。
6. 第２のＲＥＳＴウェブサービスは複数のリソースを公開し、前記プロキシサーバ内の前記第１のＲＥＳＴウェブサービスは、前記第２のＲＥＳＴウェブサービスによって公開された前記複数のリソースの部分集合を公開する、請求項４に記載の方法。
7. 前記第２のウェブサービスは、前記内部コンピュータネットワークにおける前記コンピュータサーバ内の簡易オブジェクトアクセスプロトコル（ＳＯＡＰ）ウェブサービスである、請求項１または２に記載の方法。
8. 前記プロキシサーバ内の前記ウェブサービス要求のための予め定められた処理フローにおける現在点を判断するステップと、
   前記ウェブサービス要求のための前記予め定められた処理フローにおける判断された前記現在点に基づいて、１つ以上のセキュリティポリシーを検索するステップと、
   前記セキュリティポリシーに従って前記ウェブサービス要求を処理するステップとをさらに含み、
   前記ウェブサービス要求は、前記内部コンピュータネットワークにおける前記コンピュータサーバによって公開された前記第２のウェブサービスを呼び出す前に処理される、請求項１〜７のいずれか１項に記載の方法。
9. システムであって、
   １つ以上のプロセッサを含む処理部と、
   前記処理部と結合され、前記処理部によって読取可能であるメモリとを含み、前記メモリは、前記処理部によって実行されると前記処理部に以下のステップを行なわせる一組の命令を格納しており、前記以下のステップは、
   外部コンピュータネットワークにおけるクライアント装置からウェブサービス要求を受信するステップを含み、前記システムは、前記外部コンピュータネットワークとは別の内部コンピュータネットワークのサブネットワーク内で動作するように構成されており、前記以下のステップはさらに、
   前記ウェブサービス要求内の第１のリソースを識別するステップと、
   前記第１のリソースが前記システム内の第１のレプリゼンテーショナル・ステート・トランスファー（ＲＥＳＴ）ウェブサービスによって公開されると判断するステップと、
   前記システム内の前記第１のＲＥＳＴウェブサービスを呼び出すステップと、
   前記システム内の前記第１のＲＥＳＴウェブサービスの実行中、前記内部コンピュータネットワークにおけるコンピュータサーバ内の第２のウェブサービスを呼び出すステップとを含み、
   前記システム内の前記第１のＲＥＳＴウェブサービスを呼び出すステップは、
   前記第１のＲＥＳＴウェブサービスによって公開された前記第１のリソースが前記システムの前記メモリ内に存在しないと判断するステップと、
   前記第１のリソースを前記システムの前記メモリ内に生成するステップとを含み、前記第１のリソースは、前記ウェブサービス要求が前記クライアント装置から受信された後に生成される、システム。
10. システムであって、
    １つ以上のプロセッサを含む処理部と、
    前記処理部と結合され、前記処理部によって読取可能であるメモリとを含み、前記メモリは、前記処理部によって実行されると前記処理部に以下のステップを行なわせる一組の命令を格納しており、前記以下のステップは、
    外部コンピュータネットワークにおけるクライアント装置からウェブサービス要求を受信するステップを含み、前記システムは、前記外部コンピュータネットワークとは別の内部コンピュータネットワークのサブネットワーク内で動作するように構成されており、前記以下のステップはさらに、
    前記ウェブサービス要求内の第１のリソースを識別するステップと、
    前記第１のリソースが前記システム内の第１のレプリゼンテーショナル・ステート・トランスファー（ＲＥＳＴ）ウェブサービスによって公開されると判断するステップと、
    前記システム内の前記第１のＲＥＳＴウェブサービスを呼び出すステップと、
    前記内部コンピュータネットワークにおけるコンピュータサーバ内の第２のウェブサービスによって提供される一組のリソースを記述するウェブアプリケーション記述言語（ＷＡＤＬ）ファイルにアクセスするステップと、
    前記第２のウェブサービスによって提供される前記一組のリソースの前記ＷＡＤＬファイルにおける記述を使用して、前記システム内の前記第１のＲＥＳＴウェブサービスにおいて１つ以上のリソースを生成するステップと、
    前記システム内の前記第１のＲＥＳＴウェブサービスの実行中、前記内部コンピュータネットワークにおける前記コンピュータサーバ内の前記第２のウェブサービスを呼び出すステップとを含む、システム。
11. 請求項１〜８のいずれかに記載の方法をコンピュータに実行させるためのプログラム。

Images