JP2006502465A - コンテンツ配信ネットワーク（ＣＤＮ）で使用するためのＪａｖａアプリケーションフレームワーク - Google Patents

Abstract

本発明によれば、開発者は、Ｗｅｂアプリケーションを、高度に分散化されたエッジレイヤーと集中化されたオリジンレイヤーとの２つレイヤーに分ける。代表的な実施形態においては、エッジレイヤーは、Ｗｅｂ層（３０４）、典型的には所定のＪａｖａベースアプリケーションのプレゼンテーションレイヤーを実行するサーブレットコンテナをサポートする。必要な場合、エッジレイヤーは、オリジンサーバ上で動作するコードと通信して所定のクエストに応答する。

Description

本発明は、一般に、コンテンツ配信ネットワークで使用されるアプリケーション展開モデルに関する。

企業は、インターネットを介して顧客やパートナー、供給業者にビジネスアプリケーションを拡張することによって、事業を拡大し、効率を向上させ、新しい収益源を実現することができる。信頼できる安全なＷｅｂプレゼンスを運用するためのオペレーション上の負担を軽減する一方法は、Ｗｅｂプレゼンスの全部又は一部を、コンテンツ配信ネットワーク（ＣＤＮ）などのサービスプロバイダへアウトソース（外注）することである。コンテンツ配信ネットワークは、コンテンツ（Ｗｅｂオブジェクト、ストリーミングメディア、ＨＴＭＬ、実行可能コードなど）をエンドユーザーに代わって配信することによって、Ｗｅｂサイトのオリジンサーバの作業負荷を軽減するためのコンテンツサーバ及び関連制御機構の集まりである。一般的に、コンテンツサーバは、インターネットの“エッジ”に配備される。良好に管理されたＣＤＮは、或るサイトの、Ｗｅｂページのコンテンツの一部又は全てを送ることによってこの目標を達成し、その顧客のインフラストラクチャに要するコストを削減すると同時に、エンドユーザーのそのサイトからのブラウジング経験を向上させる。動作時には、ＣＤＮは、リクエスト・ルーティングメカニズムを使用して、その顧客に電子的に近いＣＤＮエッジサーバを見つけ出し、ＣＤＮ宛てのリクエストを送る。ＣＤＮを使用するサイトは、ＣＤＮサービスプロバイダのアウトソースされたインフラストラクチャの拡張性、優れた性能、及び利用可能性から恩恵を得る。

また、コンテンツ配信で必要な作業をアウトソースしている企業等の多くは、事業サービスをマルチタイヤ（ｎ層）アプリケーションとして実施している。代表的なマルチタイヤ（ｎ層）アプリケーションの場合、ユーザーをアプリケーションへ接続するのに、ウェブベースの技術がアウター層（第１層、或いは、“プレゼンテーション”層）として使用され、残りの一層又は複数の層は、コアビジネスロジックを提供するミドルウエア、及び／或いは、そのアプリケーションを既存の企業情報システムに統合するミドルウエアを含む。Ｊａｖａ ２ Ｐｌａｔｆｏｒｍ、エンタープライズ Ｅｄｉｔｉｏｎ（Ｊ２ＥＥ（登録商標））は、この種のマルチタイヤの企業向けサービスを開発するコストと複雑さを軽減する技術の１つであり、また、関連するコンポーネントベースドモデルである。Ｊ２ＥＥのランタイム環境は、サービス構築に使用可能な数種類のアプリケーションコンポーネントを定義する。これらは、（ａ） 通常Ｗｅｂサーバで実行され、ＷｅｂクライアントからのＨＴＴＰリクエストに応答するコンポーネントであるＷｅｂ層コンポーネント（サーブレット、ＪＳＰページ、Ｊａｖａビーンズ、フィルタ、Ｗｅｂイベントリスナーなど）、及び（ｂ） ビジネスロジックを含み、管理された環境で実行されトランザクションのサポートを行うエンタープライズ層コンポーネント（エンタープライズ ＪａｖａＢｅａｎｓ（ＥＪＢ（登録商標））として開発されるセッションビーンズ、エンティティビーンズ、及びメッセージ駆動ビーンズなどが含まれる）。Ｊ２ＥＥアプリケーションコンポーネント用のランタイムサポートは、所謂“コンテナ”によって行われ、ＷｅｂコンテナがＷｅｂ層コンポーネントをサポートし、エンタープライズコンテナがエンタープライズ層コンポーネントをサポートする。

コンテナは、アプリケーションコンポーネントを実行し、ユーティリティサービスを提供する。Ｊ２ＥＥ準拠サーバは、アプリケーションコンポーネントに適合するための、配備、管理、及び実行各々のサポートを提供する。

インターネットのエッジでのアプリケーションの処理を可能にするため、この種のサーバサイドＪａｖａアプリケーション及びその他のＷｅｂサービスをコンテンツ配信ネットワークなどの分散型コンピューティング環境下で展開できるフレームワークを提供できることが望ましい。

本発明の目的は、インターネットコンテンツ配信ネットワーク（ＣＤＮ）などの地球規模で分散されたコンピュティングプラットフォームにアプリケーションを展開すると共にプラットフォームから実行できるようにする、エンタープライズアプリケーションのためのアプリケーション展開モデルを提供することである。

本発明のより具体的な目的は、Ｊａｖａベースアプリケーション及びＷｅｂサービスを分散コンピューティングプラットフォームに展開し、エンタープライズが多層分散アプリケーションモデルを利用できるようにするフレームワークを提供することである。

本発明の別の目的は、ＪａｖａベースのＷｅｂコンテナ又はエンタープライズコンテナ或いはその両方のサポートを可能にして、アプリケーション又はアプリケーションのコンポーネントがインターネットのエッジ上で実行できるようにする、コンテンツ配信ネットワークのための展開モデルを提供することである。

本発明のより一般的な目的は、エッジサーバにおいてアプリケーションコードを実行する能力を備えたコンテンツ配信ネットワークを提供することである。

本発明の具体的な目的は、Ｊａｖａサーバページ（ＪＳＰ）、サーブレット、ＪａｖａビーンズなどのＷｅｂ層コンポーネントの、エンドユーザに近いインターネットエッジ上での実行をサポートし、ネットワーク待ち時間、及びコストのかかるインフラストラクチャの過剰供給の必要性を無くすと共に、任務が重要なエンタープライズアプリケーションの性能と信頼性を改善するエッジアプリケーション展開モデルを提供することである。

好ましい実施形態では、本発明は、Ｊａｖａを使用可能エッジサーバを含むＣＤＮＪａｖａアプリケーションフレームワークの提供である。このフレームワークは、公知のＣＤＮ提供で使用されているものに類似したマッピング、負荷均一化及び管理システムを活用すると共に強化する。第１の様相では、本発明は、プレゼンテーション、即ち、ｎ層インターネットアプリケーションのプレゼンテーション層、即ちＷｅｂ層の提供と実行を可能にする。アプリケーションサーバのサーブレットコンテナ内で実行されるＪＳＰ、サーブレット、Ｊａｖａビーンズ及びカスタムタグは、エンドユーザに近いインターネットのエッジで実行される。別の実施形態では、Ｗｅｂ層に加え、アプリケーションのエンタープライズ層の少なくとも一部又は全てが所定のエッジサーバに配置され実行される。通常、エンタープライズ層は、アプリケーションのビジネスロジックを実施すると共にローカル即ち遠隔のデータベースをサポートするエンティティビーンズ、セッションビーンズ及びメッセージ駆動ビーンズを含む。

本発明の別の様相によれば、開発者は、Ｗｅｂアプリケーションを、高度に分散化されたエッジレイヤーと集中化されたオリジンレイヤーとの２つレイヤーに分割するのが好ましい。代表的な実施形態では、エッジレイヤーは、Ｗｅｂコンテナをサポートし、これにより、Ｊａｖａサーバページ（ＪＳＰ）、サーブレット、Ｊａｖａビーンズ、Ｊａｖａヘルパークラス及びタグライブラリなどの技術がサポートされる。エッジとオリジンとの間の通信には、ＲＭＩやＳＯＡＰなどの慣用の通信プロトコルを使用するのが好ましい。ＪＤＢＣなどの、ＨＴＴＰを介してトンネルさせることができる任意のプロトコルをサポートできる。

好ましくは、アプリケーションは、エッジサーバ上で、自身のＪａｖａ仮想マシン（ＪＶＭ）内の自身のアプリケーションサーバインスタンス内で動作される。好ましい実施形態では、コンテンツ配信ネットワークサービスプロバイダが、少なくとも１台のエッジサーバを有するＣＤＮを動作させ、このエッジサーバは、複数のアプリケーションサーバ／ＪＶＭインスタンスを含んでいる。各インスタンスは特定のＣＤＮカスタマと関連づけられている。複数のアプリケーションサーバインスタンスによるリソースの利用度がモニタされると共に、所定のリソース（メモリ、ＣＰＵ、ディスク、ネットワークＩ／Ｏなど）を過度に利用しているアプリケーションサーバプロセスは終了される。リソース管理に加え、各アプリケーションサーバ／ＪＶＭプロセス内で動作しているアプリケーションにセキュリティ上の拘束を加えるのが好ましい。これは、サンドボクシングと呼ばれる場合もある。これらの制約の例としては、ファイルシスムの読出／書込の制約、ソケットの開放と使用に関する制限、スレッドの開始、停止及び変更に関する制約、及びアプリケーションが所定のアプリケーションサーバクラスを読むのを阻止するコード制約が挙げられる。好ましくは、所定のアプリケーションは他のアプリケーションに属するコードを動作させたりロードすることができず、他のアプリケーションに属するデータをロードすることができず、ファイルシステムの上の任意のファイルを読んだり書いたりできず、ネイティブカーネルコールしたりネイティブコールを行うライブラリをロードしたりできない。

エッジにＷｅｂコンテナを提供することにより、本発明は、ｎ層インターネットアプリケーションのＷｅｂ層全体までオフロード（off-load）する能力を提供する。アプリケーションサーバのサーブレットコンテナ内で実行されているＷｅｂコンポーネントは、エンドユーザに近いインターネットのエッジ上で実行できる。

例示的な動作では、エンドユーザがＣＤＮエッジサーバに向けられるリクエストを行う。リクエストがＪａｖａ処理を要求し、その特定のアプリケーションについての最初のリクエストである場合、アプリケーションがオリジンから取り出され、アンパックされ、アプリケーションサーバにロードされる。アプリケーションのコンポーネント（Ｗｅｂアプリケーションアーカイブ即ち「ＷＡＲ」ファイルなど）がエッジサーバ上に既にキャッシュされている場合、応答を発生するために適切なサーブレット又はＪＳＰページが使用される。必要に応じて、エッジサーバは、アプリケーションの内、オリジン上で動作させる必要がある部分、例えば、中央データリソース或いは他のエッジ配置不可能（non-edgeable）サーブレットへのアクセスを必要とする部分についてはオリジンサイトに連絡を取る。ページの内、エッジからのサーヒスを最も良好に受けられる部分はエッジ処理され、オリジンで処理する必要がある部分はオリジンで処理され、結果はエッジサーバからエンドユーザに返送される。

アプリケーションのコンポーネントが必要に応じてエッジサーバに分配される。別の実施形態では、そのアプリケーション或はコンポーネントの予想される将来における必要性の予測に基づき、或は故障許容の目的から、アプリケーション、或はアプリケーションコンポーネントを事前配備しておくことが望ましい。従って、所定のアプリケーション或はそのコンポーネントが、エンドユーザーのリクエストがそのサーバで受信されたかどうかに関係なく、特定のエッジサーバへ配信され、初期化され、起動される。

以上、本発明に関係のある幾つかの特徴を概説した。しかし、これらの特徴は例示に過ぎないと解釈すべきである。以下に述べるように、開示された発明を異なる方法で適用するか、或いは発明を変更することによってその他多くの有利な結果が得られる。

本発明及びその利点は、添付の図面に関連して行われる以下の詳細な説明を参照することによってより完全に理解できる。

本発明は、以下に概説するような、インターネットＣＤＮアーキテクチャ及び機能性を強化するＪａｖａアプリケーションフレームワークに関するものである。なお、Ｊａｖａプログラミング規約及びＪ２ＥＥアーキテクチャの知識があるものと推定する。Ｊ２ＥＥについての追加の情報については、Ｓｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓから入手可能な、Ｊａｖａ ２ Ｐｌａｔｆｏｒｍ エンタープライズ Ｅｄｉｔｉｏｎ Ｓｐｅｃｉｆｉｃａｔｉｏｎ ｖ１．３ （２００１年７月）を参照。また、オンラインコピーは、ＵＲＬ：ｈｔｔｐ：／／ｊａｖａ．ｓｕｎ．ｃｏｍ／ｊ２ｅｅ／ｊ２ｅｅ−１ ３−ｆｒ−ｓｐｅｃ．ｐｄｆから入手可能である。

インターネットコンテンツ配信ネットワーク（ＣＤＮ）を利用してディジタルコンテンツ（ＨＴＴＰコンテンツ、ストリーミングメディア、及びアプリケーションなど）を配信することは従来技術として知られている。ＣＤＮは、第三者コンテンツプロバイダに代わってコンテンツを効率的に配信するように配置された、地理的に分散されたコンテンツ配信ノード群のネットワークである。一般的に、ＣＤＮは、コンテンツ配信インフラストラクチャ、リクエスト・ルーティングメカニズム、及び分配インフラストラクチャの組合せてとして実施される。コンテンツ配信インフラストラクチャは、通常、リクエスト中のエンドユーザーへコンテンツを配信するための、戦略拠点（例えば、インターネットアクセスポイント、インターネットＰｏｉｎｔ ｏｆ Ｐｒｅｓｅｎｃｅなど）に配置された「代理」オリジンサーバのセットから成る。リクエスト・ルーティングメカニズムは、Ｗｅｂコンテンツ配信に対してはクライアントの応答時間を最小にし、またストリーミングメディア配信に対しては最高品質を提供できるように、コンテンツ配信インフラストラクチャの中のサーバをリクエスト中のクライアントに割当てる。分配インフラストラクチャは、コンテンツをオリジンサーバから代理サーバへ移すためのオンデマンド或いはプッシュ式メカニズム群から成る。効果的なＣＤＮの場合、アクセス頻度の高いコンテンツは、リクエストしているクライアントにとって最適な代理サーバから送信される。典型的なＣＤＮの場合、単一のサービスプロバイダが、リクエストルータ、代理サーバ、及びコンテンツディストリビュータを動作させる。更に、そのサービスプロバイダは、コンテンツの発行組織との間で事業関係を確立し、それらのオリジンサーバーサイトに代わって機能し、分散型配信システムを提供する。

図１に示すように、インターネットコンテンツ配信インフラストラクチャは、通常、リクエスト中のエンドユーザー１１９へコンテンツのコピーを配信するための、戦略拠点（例えば、インターネットアクセスポイントなど）に配置された一組の“代理”オリジンサーバ１０２を含む。代理オリジンサーバは、例えば、２０００年８月９日付の「ＨＴＴＰにおける代理サーバの条件（Ｒｅｑｕｉｒｅｍｅｎｔｓ ｆｏｒ Ｓｕｒｒｏｇａｔｅｓ ｉｎ ｔｈｅ ＨＴＴＰ）」と題するＩＥＴＦインターネットドラフトに定義されている。なお、このドラフトの内容を本明細書の一部を構成するものとしてここに援用する。リクエスト・ルーティングメカニズム１０４は、コンテンツ配信インフラストラクチャのサーバ１０２をリクエスト中のクライアントに割当てる。分配インフラストラクチャは、コンテンツをオリジンサーバから代理へ移すためのオンデマンド或いはプッシュ式メカニズムから成る。ＣＤＮサービスプロバイダ（ＣＤＮＳＰ）は、何組かの代理オリジンサーバをグループ或いは所謂“リージョン”として組織化できる。この形態の配置の場合、ＣＤＮリージョン１０６は、通常、一以上のコンテンツサーバの組を含み、ＬＡＮなどの共用バックエンドネットワークを共有し、かつインターネットアクセスポイント或いはその近くに設けられる。そのため、例えば、典型的なＣＤＮリージョンは、インターネットサービスプロバイダー（ＩＳＰ）のポイントオブプレゼンス（ＰｏＰ）１０８内に共存することができる。代表的なＣＤＮコンテンツサーバは、オペレーティングシステム（Ｌｉｎｕｘ、Ｗｉｎｄｏｗｓ ＮＴ、Ｗｉｎｄｏｗｓ ２０００など）を動作させ、かつＣＤＮアプリケーション及びコンテンツ配信ネットワークコンテンツ（ＨＴＴＰコンテンツ、ストリーミングメディア及びアプリケーションなど）に適したＲＡＭ及びディスク記憶装置を備えたＰｅｎｔｉｕｍベースのキャシュ装置である。この種のコンテンツサーバは、それらがインターネットの所謂アウターリーチ（外側末端）即ち「エッジ」、或いはその近くに配備されるため、「エッジ」サーバと呼ばれることがある。ＣＤＮには、通常、ネットワークとサーバの負荷を監視するネットワークエージェント１０９も含まれる。これらのネットワークエージェントは、通常、第三者データセンター或いはその他の場所に共存している。マップメーカ（Mapmaker）ソフトウエア１０７は、ネットワークエージェントから生成されるデータを受信し、ＩＰアドレス（クライアント側ローカルネームサーバーのＩＰアドレスなど）を動的にＣＤＮリージョンに対応付けするためのマップを定期的に作成する。

コンテンツは、例えば、参加コンテンツプロバイダーサーバで動作するコンテンツマイグレータ或いはリライトツール１０６を使用して、ＣＤＮから配信するために識別がなされる。ツール１０６は、ＣＤＮＳＰドメインを指示するため、埋め込みオブジェクトＵＲＬをリライトする。そのようなコンテンツへのリクエストは、「最良の」リージョンを識別し、次に、過負荷状態でなく、かつリクエストされたコンテンツをホストできる可能性が高い、該リージョン内のエッジサーバを識別するため、ＣＤＮＳＰ管理下のＤＮＳを通して処理される。コンテンツプロバイダ側マイグレーション（ツール１０６を使用）を使用する代わりに、参加コンテンツプロバイダは、単に、ＤＮＳディレクティブ（ＣＮＡＭＥなど）によってＣＤＮＳＰにドメイン全体（或いはサブドメイン全体）にサービスを行うことを指令する。いずれの場合にも、ＣＤＮＳＰは、ＣＤＮコンテンツサーバが、該ＣＤＮによってサービスされているオブジェクトに対するリクエストをどの様に取り扱うかを決めるため、オブジェクト専用メタデータを該ＣＤＮコンテンツサーバに供給する。本明細書で使用されているメタデータという語は、オブジェクト（コヒーレンス情報、オリジンサーバ識別情報、負荷バランス情報、顧客コード、その他制御コード、など）用の制御オプション及びパラメータのセットを意味し、これらの情報は、構成ファイル経由、ＨＴＴＰヘッダーで、或いはその他の方法で、ＣＤＮコンテンツサーバへ提供される。コンテンツプロバイダは、この方法でＣＤＮから送られるオブジェクトのＵｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ （ＵＲＬ）を変更する必要はない。例えば、エンドユーザーに、あるサイトへアクセスさせ、そのＵＲＬを選択させることによって、そのオブジェクトに対するリクエストが出されると、顧客のＤＮＳシステムは、（ＵＲＬ中の如何なるドメインに対しても）ネームクエリーをＣＤＮＳＰのＤＮＳリクエスト・ルーティングメカニズムに送る。エッジサーバが識別されると、ブラウザはオブジェクトリクエストをサーバに渡す、サーバは、構成ファイル或いはＨＴＴＰレスポンスヘッダーから供給されるメタデータを適用し。オブジェクトの取り扱い方法を決定する。

図１にも示されるように、ＣＤＮＳＰは、１台以上のサーバの組を含むメタデータ伝送システム１１６を操作して、メタデータをＣＤＮＳＰコンテンツサーバへ供給できるようにする。システム１１６は、少なくとも１台のコントロールサーバ１１８、及び１台以上のステージングサーバ１２０ａ―１２０ｎを含み、ステージングサーバの各々は、通常、ＨＴＴＰサーバ（Ａｐａｃｈｅなど）である。メタデータは、（例えば、セキュアなエクストラネットアプリケーションを使用する）ＣＤＮＳＰ或いはコンテンツプロバイダによって コントロールサーバ１１８へ供給され、そして定期的に、ステージングサーバ１２０ａ―１２０ｎへ配信される。ステージングサーバは、メタデータを、必要に応じて、ＣＤＮコンテンツサーバへ配信する。

図２は、ＣＤＮコンテンツエッジサーバの代表的なマシン構成を示す。通常、コンテンツサーバ２００は、オペレーティングシステムカーネル２０２、ファイルシステムキャシュ２０４、サーバマネージャソフトウエア２０６、ＴＣＰ接続マネージャ２０８、及びディスク記憶装置２１０を動作させるキャシング装置である。サーバマネージャソフトウエア２０６は、特に、ＣＤＮがサービス中のポピュラーなオブジェクト用の「ホット」オブジェクトキャシュ２１２を生成し管理する。該ソフトウエアは、リクエストルーティング、インリージョンロードバランシングなどの他のＣＤＮ関連機能も提供する。例えば、ＨＴＴＰキャシュとしての動作においては、コンテンツサーバ２００は、エンドユーザーのコンテンツに対するリクエストを受信し、リクエストされたオブジェクトがホットオブジェクトキャシュ或いはディスク記憶装置に在るかどうか判断し、（存在する場合）ＨＴＴＰ経由でリクエストされたオブジェクトを提供し、或いは、別のコンテンツサーバ或いはオリジンサーバへの接続を確立して、キャシュミスが生じた場合にリクエストされたオブジェクトの検索を試みる。通常、エッジサーバは、「プル」方式で作動し、キャシュへの最初のリクエストの際に初めにオブジェクトがプルされるが、オブジェクトが存在しないため、キャシュミスが生じる。

本発明は、Ｊａｖａ使用可能エッジサーバから成るＣＤＮ Ｊａｖａアプリケーションフレームワークの提案である。上記図２に示したようなエッジサーバ（マシン）には、アプリケーションサーバコードが含まれていると仮定する。よく知られている通り、アプリケーションサーバは、そこにアプリケーションを配備可能なソフトウエアプラットフォーム（ミドルウエアとも呼ばれる）である。アプリケーションサーバは、アプリケーションに対して有用なユーティリティサービスと機能群を提供する。現在、数種類のアプリケーションサーバ、Ｊａｖａベース（Ｊ２ＥＥ）、及びマイクロソフト．ＮＥＴ．がある。 Ｊａｖａは、勿論、プログラミング言語の一種でありプラットフォームの一種で、また、このプログラミング言語は、オブジェクト指向で、かつプラットフォーム非依存である。Ｊａｖａで書かれたアプリケーションは、Ｊａｖａバイトコードへ翻訳された後、そのコードは、Ｊａｖａ Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ （ＪＶＭ）上で実行される（によって解釈される）。本発明の望ましい実施形態の場合、ＣＤＮ内のエッジサーバには、Ｊａｖａアプリケーション或いはアプリケーションコンポーネントを、インターネットのエッジから実行可能にするためのＪａｖａアプリケーションサーバと付加的コードが設けられている。フレームワークは、図１に示すＣＤＮ（これは一例にすぎない）などの既知のＣＤＮ提案で使用されるマッピング、ロードバランシング及びマネジメントシステムを利用し強化する。第１実施形態の場合、アプリケーションサーバは、サーブレットコンテナ（Ａｐａｃｈｅ Ｔｏｍｃａｔなど）で、この場合、本発明は、ｎ層ＪａｖａベースアプリケーションのＷｅｂ層のオフロード及び実行を可能にする。ＪＳＰ、サーブレット、Ｊａｖａビーンズ及びカスタムタグは、アプリケーションサーバのサーブレットコンテナ内で実行されるものであるが、エンドユーザーの近いインターネットのエッジで実行される。Ｗｅｂ層は、通常、Ｊ２ＥＥサーバのフロントエンドである。別の実施形態の場合、Ｗｅｂ層のほかに、そのアプリケーションのエンタープライズ層の少なくとも一部或いは全部も配備され、或るエッジサーバ上で実行される。エンタープライズ即ち「ビジネス」層は、通常、アプリケーション専用ビスネスロジックをホストし、トランザクションマネージメント、コンカレンシーコントロール、セキュリティなどのシステムレベルのサービスを提供する。

本発明は、Ｊ２ＥＥ準拠アプリケーションをエッジ−オリジンサーバ環境で動作させることができ、有利である。特に、本発明のフレームワークは、アプリケーションをオリジンとＣＤＮとの間で分配することにより、分散コンピューティングプラットフォームを強化でき、好ましい。上記の通り、通常、アプリケーションには、Ｗｅｂ層の中にサーブレット、ＪＳＰ、フィルタ、タグライブラリ、及びＪａｖａビーンズ／ヘルパークラスが含まれ、また、エンタープライズ層にはエンタープライズビーンズが含まれる。エッジサーバのＷｅｂ層（Ｗｅｂコンテナ内など）及びオリジンサイトのエンタープライズ層（エンタープライズコンテナなど）の実行により、エンタープライズ層からＷｅｂ層が分離される様子が図３に示されている。本実施形態においては、アプリケーションのエッジ−イネーブルドバージョンは、通常、２つの協調アプリケーションであるエッジ側アプリケーション及びオリジン側アプリケーションを含む。Ｗｅｂ層のコンポーネントは、Ｗｅｂ Ａｒｃｈｉｖｅ （ＷＡＲ）としてパッケージされ、エンタープライズ層のコンポーネントは、エンタープライズ Ａｒｃｈｉｖｅ （ＥＡＲ）としてパッケージされる。上記の通り、これら２つのアプリケーションの生成には、通常、アプリケーションに関する知識に基づいた判断、つまり、どのプロセスをオリジンで、そしてどのプロセスをエッジで実行すべきかについての判断が要求される。

ただし、本発明のフレームワークは、エンタープライズ層を、オリジンのエンタープライズコンテナで動作させるものだけに限られない。図４に示すように、エンタープライズ層は、エッジサーバにも分散され、アプリケーションサーバ４００のＷｅｂ層でも実行される。本実施形態では、エンタープライズ層（例示のためのみ）は、セッションビーンズ４０２、エンティティビーンズ４０４及びメッセージ駆動ビーンズ４０６のように一以上のエンタープライズＪａｖａビーンズ（ＥＪＢ）エレメントを含む。エンタープライズ層をサポートするため、セッションビーンズをグローバルにコヒーレントな状態に保っておくことが望ましい。エンティティビーンズを使用し、読取専用データベースを（エッジサーバ位置で）複製すること、及び（ＳＯＡＰへのＪＤＢＣの使用などにより）エンタープライズデータベースへ透過トンネリングを行うことができる。

代表的な実施形態の場合、アプリケーションサーバはＩＢＭ ＷｅｂＳｐｈｅｒｅ ５．０アプリケーションサーバ（ＷＡＳ）である。ＩＢＭ ＷｅｂＳｐｈｅｒｅは、ＩＢＭから入手可能なＪＶＭ（Ｊａｖａ Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ）１．３．１を使用している。図３では、対照的に、Ｗｅｂ層は、Ｗｅｂｌコンテナ３００で実行される。この例のＷｅｂ層は、ＪＳＰページ３０２、サーブレット３０４、及びＪａｖａビーンズ３０６などのエレメントを含む。代表的Ｗｅｂコンテナは、Ａｐａｃｈｅ Ｔｏｍｃａｔサーブレットコンテナによって提供される。このコンテナは、Ｓｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓから入手可能な、ＪＤＫ １．３．１＿０４の中でＪＶＭを使用する。勿論、これらのコンポーネントは例示に過ぎず、限定を意味するものではない。Ｗｅｂコンテナ或はエンタープライズコンテナはＣＤＮエッジサーバで、多重インスタンス下で、また、以降に述べる通り、アプリケーションを分離した状態で実行することが望ましい。

特に、各アプリケーションは、ＪＶＭなどで実施される、サンドボクシングメカニズムを介して、隔離された環境で実行されることが望ましい。一般的に、サンドボクシングは、各アプリケーションサーバプロセスのリソース（ＣＰＵ、メモリー、ディスク、ネットワークＩ／Ｏなど）の利用度を監視することによって行われる。アプリケーションサーバプロセスがリソースを過度に利用していると、プロセスは終了され、新しいアプリケーションサーバが始動される。或るアプリケーションサーバが、過度のリソース利用が原因で、複数のリスタートを誘発すると、アプリケーションサーバは、次のリスタートを行うことが阻止される。ＣＤＮカスタマごとに別のアプリケーションサーバプロセスが使用されることが望ましい、何故ならば、これによって、或るカスタマのアプリケーションが別のカスタマのアプリケーションからリソースを盗むことを防止できるからである。これにより、アプリケーションサーバのリスタートも隔離される。さらに、各アプリケーションサーバプロセスは、その自身のサンドボックスドディレクトリ内で実行されることが望ましい。このディレクトリ外ではファイルの読み書きができない。これによって、或るカスタマのアプリケーションが別のカスタマのアプリケーションに干渉したり、或るカスタマのアプリケーションが別のカスタマのデータをアクセスしてしまうことを防止できる。リソースマネジメント及びサンドボクシングの詳細を以下に述べる。

図５は、エッジサーバアーキテクチャを示す。サーバ５００は、オペレーティングシステム（Ｌｉｎｕｘを改良したものなど）５０２を搭載した汎用ハードウエアで実行することが望ましい。Ｊａｖａスタックは、Ｊａｖａ Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ（ＪＶＭ）５０４、及び、望ましくはＪ２ＥＥ準拠アプリケーションサーバ５０６を含む。（図３に示されるような）Ｗｅｂ層コンポーネントに対して、アプリケーションサーバ５０６は、上記の通り、Ａｐａｃｈｅ Ｔｏｍｃａｔサーブレットコンテナによって実施される。（図４に示されるような）Ｗｅｂ層及びエンタープライズ層コンポーネントに対して、アプリケーションサーバ５０６は、ＩＢＭ ＷｅｂＳｐｈｅｒｅ Ａｐｐｌｉｃａｔｉｏｎ Ｓｅｒｖｅｒ（ＷＡＳ）によって実施される。勿論、これらの製品は例示に過ぎない。本発明に従い、フレームワーク（ＪＶＭが望ましい）は、アプリケーション５１０ａ―５１０ｎの各々に対して、アプリケーションサンドボックス５０８を生成し保守する。或るカスタマがアプリケーション５１０ａを実行する間に、別のカスタマはアプリケーション５１０ｂを実行できる。一般化すると、エッジサーバ５００は、複数の別々に実行可能なアプリケーションをサポートする。エッジサーバ５００は、キャシュ５１２を実装し、アプリケーションコンポーネントが使用される時期を制御するカスタマ構成データ５１４を保守する。サーバマネージャ５１６は、カスタマ構成データを使用して、キャシュをオーバレーし制御する。アプリケーションサンドボクシングは、アプリケーション同士が互いに害を加えたり、アプリケーションがサーバに害を与えたり、或いは、ほかのカスタマのコード及びデータにアクセスすることを防止する。上記の通り、サンドボクシングは、リソース割当を容易にし、サーバがＣＰＵ、ＲＡＭ、ディスク、帯域幅及びカーネルの使用を制御し監視できるようにする。これら及び他の機能を容易にするため、システムマネジメント５１８及びシステムセキュリティ５２０モジュールも設けられている。

図６は、エンドユーザークライアントブラウザ６００が、どのようにしてコンテンツ配信ネットワークエッジサーバー６０２及びオリジンサイト６０４と対話して、ネットワークのエッジにおいてアプリケーション（また、特に、それのＷｅｂ層コンポーネント）の実行を容易にしているかを示す。この例では、アプリケーションのＷｅｂ層のコンポーネントが、エッジサーバ上への配備と実行に使用可能であると仮定する。上記の通り、エッジサーバ６０２は、Ｊａｖａプロセッサ６０６、キャシュ６０８、及び構成データ６１０を備えている。オリジンサイト６０４は、Ｊａｖａアプリケーションサーバ６１２を実行し、データソース６１４を含む。プラットフォームを活用するため、企業は、インターネットＣＤＮサービスプロバイダへのインターネットドメイン名を示すＤＮＳエイリアス（ｃａｎｏｎｉｃａｌ ｎａｍｅ、即ちＣＮＡＭＥなど）を作成する。従って、カスタマのドメイン名（ｗｗｗ．ｓｉｔｅ．ｃｏｍなど）の検索は、エイリアスドメインのＩＰアドレスの検索になる。ＣＤＮＳＰのＤＮＳはこれらのクエリーに回答する責任があるので、ＣＤＮＳＰは、最適なエッジサーバ、この例では、エッジサーバ６０２のＩＰアドレスを返す。これがステップ（１）である。どのサーバがそのユーザーに回答するかについての判断は、ネットワークの混雑度、ネットワークの接近度合、サーバの負荷、及び帯域幅の利用度に基づく。ステップ（２）では、エッジサーバ６０２は、このリクエストに対して、このカスタマの構成データ６１０を適用し、リクエストに対してこのエッジサーバのローカルキャシュ６０８或はＪａｖａプロセッサ６０６を使用してサービスするべきか、リクエストを（トンネリングなどで）カスタマのオリジンサーバ６０４へ送るべきかを決定する。こうして、エッジサーバは、クライアントからリクエストを受信したとき、まず、そのリクエストを適切なカスタマ構成ファイルと組み合わせることが望ましい。カスタマ構成ファイルが、Ｊａｖａプロセッシングをそのリクエストに関連付ている場合、Ｊａｖａプロセッサ６０６が関与する。そのリクエストがサーブレット或はＪＳＰページならば、Ｊａｖａプロセッサ６０６は、そのリクエストを満たす。これがステップ（３）である。特に、ＷＡＲファイルがすでにエッジサーバ６０２に在るアプリケーションからリクエストを受信した場合、Ｊａｖａプロセッサ６０６は、適用可能な（例えば）サーブレット或いはＪＳＰページを使用して、リクエストへの応答を生成する。リクエストを適切にサーブレットにマップするために、標準配備記述子（ｗｅｂ．ｘｍｌなど）を使うことができる。これが、この特定のウェブアプリケーションを使う最初のリクエストである場合、アプリケーションコンポーネント（ＷＡＲファイルなど）が、オリジンサイト或いはＣＤＮステージングエリアから取り出される。最適化のために、最初のリクエストをオリジンサイトへトンネルして処理することができ、一方、エッジサーバは、以降のリクエストを取り扱うために非同期的にＷＡＲファイルを取り出す。サーブレットがデータリソースを必要とする場合、そのリソースをキャシュ６０８から取得できる。これがステップ（４）である。或いは、そのサーブレットが（恐らく、エッジ配置不可能な）別のサーブレットへリクエストを送る場合、エッジサーバ上のＪａｖａプロセッサ６０６は、オリジンサイトと連絡をとる。ステップ（５）に示される通り、エッジサーバとオリジンサーバとの間の通信は、ＲＭＩ、ＳＯＡＰ、或いはＨＴＴＰを介して明示的に行われる。ＲＭＩは、エッジアプリケーションがリモートオブジェクトを、ローカルオブジェクトのように使用することを可能にする。ＳＯＡＰは、リモートオブジェクトと通信するための、ＸＭＬベースのＲＰＣメカニズムを提供する。或いは、サーブレットが別のフォーマットのＨＴＴＰリクエストを介してデータを検索する。ＣＤＮサービスプロバイダは、ＸＭＬデータをクエリーするのに使用可能なクラスを提供するのが望ましい。検索されたデータは、キャシュ６０８にもキャシュされるので、以降のリクエストに関しては層間での待ち時間が無くなる。ステップ（６）に示されているように、エッジサーバ６０２は、リクエストの処理を完了し、クライアントへの応答を返す。実行済のサーブレットがメモリーに残り、そのエッジサーバへマップされる次のユーザーからのリクエストに対して準備されることが望ましい。

図７は、エッジでの処理を容易にするためのアプリケーションの開発と配備の一方法を示す。コンテンツ配信ネットワークのエッジサーバで実行するために設計されたアプリケーション（或いはそのコンポーネント）は、「エッジ配置可能（edge enabled）」アプリケーションと呼ばれることがある。図７に示すように、アプリケーション７００は、ソフトウエア開発フェーズを経て開発された後、例えば、スプリッタ或いはその他の開発ツールを実行して、２つの部分に分割される。例えば、エッジＷＡＲファイル７０２及びオリジンＷＡＲファイル７０４が生成される。例示的実施形態では、エッジ配置可能コンポーネント７０２が次に用意され、ＣＤＮエッジサーバ（群）７０６上に配置される、同時に、完全なアプリケーションが用意され、オリジンサイト７０８に配備される。本発明では、どのコンポーネントがエッジ配置可能で、どのコンポーネントが中央リソースに依存しているかを開発者が指定できる便利なツールが使用可能である。アプリケーション開発者はｎ層設計原則を用いてアプリケーションを作成することが望ましい。当然、アプリケーション開発プロセスでは、単体のオリジナルＷＡＲファイルの生成は不要である。何故ならば、エッジ及びオリジンコンポーネントは、最初から個別に設計し構築できるからである。

以下は、エッジにＷｅｂ層だけが位置する実施形態においてフレームワーク用アプリケーションをエッジ配置可能にする上での付加的ガイドラインである。この実施形態では、エンタープライズビーンズはオリジンで実行され、そしてエンタープライズビーンズに対してのコール（ホーム或いはリモートインタフェースの使用を含む）が、エッジに位置するフィルタ、サーブレット、ヘルパークラス、ビーンズに存在しないことが望ましい。データベースなどオリジンベースのシステムリソースに対してのダイレクトコールが、エッジに位置するサーブレット、ヘルパー、ビーンズには存在しないことが望ましい。ただし、このような場合、好ましくはＴｙｐｅ ３ ＪＤＢＣドライバを使用してデータベースの接続性を提供する。また、サーブレットコンテキストを必要とするフィルタ、サーブレット、ＪＳＰは、他のウェブアプリケーションのＳｅｒｖｌｅｔＣｏｎｔｅｘｔへアクセスしないことが望ましい。この実施形態では、Ｗｅｂアプリケーションは、状態を記憶するために、ＳｅｒｖｌｅｔＣｏｎｔｅｘｔ属性を使用できる。セキュリティ上の理由で、或る種のウェブコンポーネントはオリジンで実行することが必要になるであろう。ウェブアプリケーションについては、その配備記述子にそのウェブアプリケーションが「分配可能」であることを示すマークを付けるなど、Ｓｅｒｖｌｅｔ Ｓｐｅｃｉｆｉｃａｔｉｏｎ ２．３に記載されている「分配可能」規則を遵守することが望ましい。あるリクエストに応じて進められる実行シーケンスの中で、Ｗｅｂコンポーネントは、このリクエストに応じて全てオリジンで、或いは全てエッジで実行されることが望ましい。リクエストディスパッチング（ｉｎｃｌｕｄｅ／ｆｏｒｗａｒｄ）を使用しているウェブアプリケーションのエッジコンポーネントは、別のエッジウェブアプリケーションコンポーネントへのみディスパッチ可能であることが望ましい。オリジンコンポーネントについても同様である。ただし、ソース或はターゲット（ディスパッチされた）エッジコンポーネントは、オリジンと自由に連絡してデータを送信したり、データを検索したりできる。

実行シーケンスは、通常、リクエストに対しての応答に関与するフィルタ、サーブレット、及びＪＳＰから構成されるが、オリジンへの接続（ＨｔｔｐＵＲＬＣｏｎｎｅｃｔｉｏｎなど）を介して使用される外部リソースを含まないことが望ましい。同一のリクエストと応答引数は、実行されるフィルタによって共用され、また、この実行シーケンスを形成するために互いに含む、或は送信するサーブレット及びＪＳＰによって共用されることが望ましい。この定義は動的である、何故ならば、サーブレットは、エッジ側及びオリジン側の実行シーケンスに矛盾なしに含めることができるからである。

アプリケーションの中の妥当な実行リクエスト、及びこれらの実行シーケンスに従わせるリクエスト群についての知識があれば、開発者はアプリケーションをエッジ配置可能にすることができる。ある実施形態においては、このプロセスには、コンポーネントがオリジン専用、エッジ専用、或は両用であるかを識別することが含まれる。オリジン専用コンポーネントは、オリジンでのみ、望ましくは変更せずに実行可能である。エッジ専用コンポーネントは、エッジでのみ実行できる。両用の指定は、オリジン専用サーブレットへの実行パス上、及び全てのサーブレットがエッジ配置可能である実行パス上に存在し得るサーブレットに対して適用される。この場合、サーブレットは、オリジンにも、エッジにもインストールされる必要がある。この両用のカテゴリーは、エッジ及びオリジンに於いて類似の機能を提供するサーブレットにも適用される。いくつかのコンポーネントは、エッジ及びオリジンコンポーネントに分割しておくことが最良である。

リクエストのセット及び対応する実行シーケンスを構築するには、配備記述子（ｗｅｂ．ｘｍｌ）を使用して、それらに対応するサーブレットマッピング値及びＵＲＬパターンを取得できる。これらエッジ及びオリジンコンポーネントに分割すべきコンポーネントに対して、同じタイプのエッジ側コンポーネント及び一以上のオリジン側サーブレットを生成することが望ましい。これは、オリジン側の機能を除いてエッジ側コンポーネントを生成すること、及びオリジン側システムコールにサーブレットファサードを使用することによって行うことができる。エッジ、オリジン両方で必要とされるコンポーネントは両方とマークし、残りのコンポーネントはエッジとマークする。

次に、エッジディスパッチャが構築される。エッジディスパッタヤは、エッジにおけるウェブコンポーネントへの単一エントリポイントである。このディスパッチャサーブレットは、入力リクエストを調べて、それをオリジンへプロキシするが、エッジのサーブレット／ＪＳＰヘ送るかを決定する。事前にエッジ配置可能とされたコンポーネント（即ち、ディスパッチャを有しない）が既に単一エントリポイントを持っていれば、ディスパッチャ機能をこのエントリポイント自身へ組み込むことができる。このコンポーネントを構築するには、各リクエストセット及び対応する実行シーケンスを考える。実行シーケンスがオリジン専用とマークされたコンポーネントを含んでいる場合、対応するリクエストは、オリジンへプロキシされなければならない（また、エッジにあるフィルタは、これらのリクエストを無視するように構成されなければならない）。そのようにしないと、リクエストは、エッジで満たされ、エッジディスパチャは、リクエストを実行シーケンス中の最初のエッジ側サーブレット或はＪＳＰへ送る。

更に、アプリケーションをエッジ配置可能にするには、ｗｅｂ．ｘｍｌ配備記述子の配備情報を一部、特に、サーブレットマッピイング値とフィルタマッピング値を変更して、全てのリクエストがエッジディスパッチャを介して送られることを確実にする必要がある。さらに、フィルタは、オリジンへプロキシされるリクエストに対して２回（例えば、最初にエッジで、次にオリジンで）適用しないことが望ましい。或いは、エッジフィルタとオリジンフィルタを設定することもできる。ウェブアプリケーションは、それの配備記述子に「分配可能」とマークする必要性を含め、Ｓｅｒｖｌｅｔ Ｓｐｅｃｉｆｉｃａｔｉｏｎ ２．３掲載の「分配可能」規則を遵守する必要がある。配備記述子の中の配備に関する情報（特に、サーブレットマッピング値及びフィルタマッピング値）を変更して、全てのリクエストがエッジディスパッチャを介して送られること、及びフィルタが正しく適用されることを確実にする必要がある。

通常、エッジディスパッチャは、リクエストを受信し、それの取扱い方法を決定する。一例に過ぎないが、図８に示すように、リクエストはエッジコンポーネント８０２によって、エッジで完全に処理される。或いは、ディスパッチャ８００は、プロキシとして働き、リクエストをオリジン８０４へ送信する。そして、オリジンがエンタープライズビーンズ８０６などのオリジンプロセスをコールし、このビーンズがプロキシに応答を返し、プロキシがクライアントへ応答を返す。分割シナリオにおいては、ディスパッチャ８００は、リクエストを、エッジ側コンポーネント８１０へ送信する。エッジコンポーネント８１０がオリジン側スプリットコンポーネント８１２と通信し、このコンポーネントがビーンズ８０６などのオリジンプロセスをコールする。応答は、エッジ側コンポーネント８１０を介して返される。

上記アプローチでは、エッジ（プロキシ）のサーブレット／ＪＳＰは、引数を配列して、オリジン（ブローカ）のサーブレットへ送信すると、オリジンが引数を渡し、必要な方法の呼出しを行う。次に、ブローカは、戻り値を配列し、これをプロキシへ返す。ブローカは、オリジン側の機能をエッジへエクスポートし、該機能のファサードとして働く。特に、エッジサーブレット／ＪＳＰとエンタープライズビーンと間の全ての通信は、オリジンのサーブレットファサード経由が望ましい。この設計の代案は、エッジとオリジンにおける全てのサーブレットファサードとの間を媒介する単一のオリジン側サーブレットを設けることである。これが、エッジ−オリジン間リクエスト用の単一のエントリポイントを提供する。オリジンディスパッチャは、そうしなければオリジンに存在するであろう、全てのサーブレットファサードの全機能をそれ自体で提供できる。

以下、本発明のフレームワークへ統合するための、Ｊａｖａアプリケーションサーバへの変更、特にそのサーブレットコンテナコンポーネントへの変更について説明する。このアプリケーションサーバは、エッジサーバで実行されるが、これは、上記の通り、汎用的なハードウエアとオペレーティングシステムを搭載したマシンである。図９に示すように、望ましいアーキテクチャがアウトオブアーキテクチャ経由で実施され、エッジサーバプロセス９００及び複数のＪａｖａアプリケーションサーバプロセス９０２ａ―９０２ｎを含む。コンテンツ配信ネットワーク内のエッジノードに、図８に示したように、それぞれがアプリケーションサーバインスタンスを含む複数の子プロセスを産み出すことができる、単一のエッジサーバアプリケーションを有することが望ましい。各子プロセスは、Ｊａｖａ Ｅｄｇｅ Ｓｅｒｖｉｃｅｓ ＡＰＩ （ＪＥＳＡＰＩ）用に構成されることが望ましい。これは、本発明によれば、Ｊａｖａアプリケーションサーバ用の統合フレームワークである。一般的に、ＪＥＳＡＰＩは、エッジサーバマネージャプロセスをアプリケーションサーバインスタンスにインタフェースし、各種の管理機能を容易にする、即ち、ＷＡＲ及びＥＡＲファイルの始動、停止、再ロード、各種アプリケーションサーバインスタンスの状態の監視、アプリケーションサーバインスタンスによるリソースの利用度の監視、各インスタンスからのデータの収集、プラットフォーム使用についてのレポート作成、請求書発行を行うことを容易にする。図９に示すように、ＨＴＴＰ／ＨＴＴＰＳリクエストは、まず、エッジサーバプロセス９００に接続する。エッジサーバプロセス９００は、そのリクエストを、カスタマ構成データからのメタデータ構成に指定されていることが望ましい、コンテキストパスへマップする。エッジサーバプロセス９００は、次に、ファイルシステム上の関連ウェブアプリケーションアーライブ（ＷＡＲ）を取り出し、アンパックして、アーカイブをインストールする。最後に、エッジサーバプロセスは、リクエストがアプリケーションサーバインスタンスによって取り扱われるように変更を行い、ソケットを使用してこれをプロキシする。さらに、エッジサーバプロセス９００は、各ＪＥＳＡＰＩアプリケーションサーバ子インスタンスとの双方向通信を用いて、制御データ及びリソース利用度などの情報を転送することが望ましい。

図１０は、Ｊａｖａアプリケーションサーバインスタンスを示す。Ｊａｖａアプリケーションサーバ子プロセス１０００には、このアプリケーションサーバのコアロジック１００２を含んでおり、ＪＥＳＡＰＩサポート１００４に対して有効にされている。アプリケーションラッパー（ｗｒａｐｐｅｒ）１００６のプロセスコンポーネントは、このアプリケーションサーバ専用である。これの目的は、プロセスの各種コンポーネントを統合し編成することである。ＪＶＭ／ＪＤＫ１００８は、変更がない場合、慣用のものである。ＪＶＭ内の外部共用オブジェクトは、アプリケーションサーバプロセス１００２で行われるシステムコールをインターセプトし、以下に詳しく述べる通り、リソースの利用度を監視し、セキュリティアクセスチェックを実行する。ＪＥＳＡＰＩ１００４は、一組のＪａｖａクラス及びネイティブライブラリを含み、また、Ｊａｖａアプリケーションサーバプロセス１００２用のコア統合フレームワークを定義することが望ましい。ＪＥＳＡＰＩは、アプリケーションサーバプロセス１００２に依存して与えられたｊｅｓａｐｉＢａｓｅアブストラクトクラスを拡張するカスタムＪＥＳＡＰＩ実施単独オブジェクトを提供することが望ましいが、これに限定されるものではない。

アプリケーションラッパー１００６は、アプリケーションサーバプロセス１００２用のブートロジックとしての機能を果たす。本ラッパー１００６は、アプリケーションサーバのタイプに合わせてカスタマイズされ、該プロセスの全ての種類のコンポーネントを接続する“ｇｌｕｅ”コードとしての役割を果たす。ラッパーコンポーネント１００６は、変化するであろうアプリケーションタイプ専用のＪＥＳＡＰＩインプリメンテーションシングルトンを提供する。特に、ラッパー１００６は、ＪＥＳＡＰＩ１００４を初期化し、アプリケーションサーバプロセス１００２の必要な全てのランタイム構成を実行する。サーバを起動し、サーバがリクエストを処理する準備ができた時点でこれをＪＥＳＡＰＩに知らせる。これはアプリケーションへのエントリポイントなので、ラッパーは、ＪＥＳＡＰＩとアプリケーションサーバを、エッジサーバプロセス（図９のエレメント９００）（引数、Ｊａｖａシステムプロパティなどの形態）によって供給されたデータで初期化する必要がある。このデータには、例えば、アプリケーションサーバインスタンスｉｄ（ＪＥＳＡＰＩが使用する）及び、ＨＴＴＰ接続時にサーブレットコンテナを取り付けるのに必要なソケットポートが含まれる。アプリケーションラッパー１００６は、ＨＴＴＰソケット接続だけをアクセプトするようにエッジサーバを構成することが望ましい。ある例示的実施形態では、アプリケーションサーバプロセスは、ローカルループバックホスト宛て接続、及びエッジサーバプロセスによって指定されるポートでの接続をアクセプトする必要がある。さらに、アプリケーションラッパーは、プロトコル操作及びロギングなどの統合に必要とする全てのハンドラーを提供しアプリケーションサーバに登録する。アプリケーションラッパーは、各アプリケーションサーバのログイベント（サーバ及びウェブアプリケーションごと）を受信し、これをＪＥＳＡＰＩへ回送することが望ましい。アプリケーションサーバによって提供されるログ取扱ＡＰＩは、ログメッセージを発行した同じスレッド内でそのハンドラーを起動することが望ましく、またこのスレッドはこのメッセージをＪＥＳＡＰＩへ送る。アプリケーションサーバログメッセージは、アプリケーションラッパーログハンドラ−経由でＪＥＳＡＰＩへ転送されるので、ファイルロギングは、アプリケーションサーバ内で無効にできる。アプリケーションサーバからのほかの標準データストリームは、同じように、アプリケーションラッパー経由でＪＥＳＡＰＩへ転送される。

下記の通り、アプリケーションサーバプロセス１００２は、Ｊ２ＥＥのセキュリティポリシーを使用してウェブアプリケーションの機能及びコード自身を制限することが望ましい。サーバコードは、セキュリティループホールを避けるため、可能な限りロックしておくことが望ましい、また、ＪＥＳＡＰＩ実装シングルトン及びアプリケーションラッパーの一部である全てのクラスは、サーバクラスと同じ保護を有していることが望ましい。さらに、プロセス全体（サーバ及びウェブアプリケーションロジックを含む）に対して適切なセキュリティ制限が課されていることが望ましい。

標準Ｊ２ＥＥのセキュリティ許可によって提供される機能のほかに、付加的な制限をアプリケーション（“ｗｅｂａｐｐｓ”と呼ぶこともある）に課すべきである。ウェブアプリケーションが、スレッド及びスレッドグループの生成或は変更をしないようにしておくことが望ましい。ウェブアプリケーションが、非システムスレッドで動作する場合、アプリケーションサーバプロセスは、セキュリティ許可にアドレスする方法を提供する。ウェブアプリケーションがＪＮＤＩ及びファイル読取専用操作をベースパス（アンパック形式のＷＡＲファイルディレクトリルート）から、反復的に実行できるようにしておくことも必要である。アプリケーションサーバは、ウェブアプリケーションのためのセキュリティ許可を、ランタイム（実行時）に動的に、生成することが望ましい。

種々のカスタマからのウェブアプリケーションは、同じサーバで実行可能なことが望ましいので、サーブレットコンテナを構成可能にしておき、あるコンテキスト内のウェブアプリケーションが、別のコンテキストのＳｅｒｖｌｅｔＣｏｎｔｅｘｔインスタンスをアクセスすることを許可したり、不許可にしたりし、サーブレットがＳｅｒｖｌｅｔＣｏｎｔｅｘｔ．ｇｅｔＣｏｎｔｅｘｔ（）をコールしようとしたときに、そのウェブアプリケーションの構成に依っては、ヌルが返されるようにすることが望ましい。この操作は、インストール時に、ウェブアプリケーションごとに指定されるのが好ましい。追加されるセキュリティレベルとして、外部共用オブジェクトは、アプリケーションサーバプロセスで出されるシステムコールをトラップし、以下に述べるようにして、アクセス制御チェックを行うことが望ましい。

アプリケーションサーバ内の特定のウェブアプリケーションに対するＨＴＴＰリクエストを送るのに先立ち、エッジサーバプロセス（図９のエレメント９００）は、（必要ならば）関連ＷＡＲをファイルシステム上のベースディレクトリへアンパックする役割、及びウェブアプリケーションコンポーネントをアプリケーションサーバへインストールする役割を持っている。エッジサーバプロセスは、アプリケーションサーバプロセスに通知し、ＪＥＳＡＰＩを使用してウェブアプリケーションをインストールして無効にし、ウェブアプリケーションの構成をランタイムに供給する。エッジサーバプロセスは、アプリケーションサーバのインスタンスごとにインストールされるコンテキストを管理する役割も持っている。エッジサーバプロセスが、アプリケーションサーバに対して、ウェブアプリケーションをインストールするようリクエストすると、エッジサーバプロセスは、制御リクエストをＪＥＳＡＰＩへ送信し、ウェブアプリケーションのコンテキストパス、そのベースディレクトリパス、及び、そのウェブアプリケーションが、ＳｅｒｖｌｅｔＣｏｎｔｅｘｔ．ｇｅｔＣｏｎｔｅｘｕ（）を使用するなど、ほかのサーブレットコンテクストへアクセスできるかどうかを決定するフラグを供給する。ＪＥＳＡＰＩ実装シングルトンは、次に、このリクエストを、アプリケーションサーバにあるウェブアプリケーションの動的インストレーションメカニズムを起動することなどによって処理する。ウェブアプリケーションがインストールされた後、エッジサーバプロセスは、それに対してのリクエストを、アプリケーションサーバへ送信する。エッジサーバプロセスが、特定のウェブアプリケーションを無効にできる状態にあれば、エッジサーバプロセスは、そのウェブアプリケーションインスタンスへのリクエストの送信を停止し、ウェブアプリケーションをアンインストールする制御リクエストを、それのコンテキストパスでウェブアプリケーションを識別するＪＥＳＡＰＩへ送信する。

ホットスワッピングによってウェブアプリケーションの改訂をサポートするには、エッジサーバプロセスが、そのアプリケーションサーバ内でウェブアプリケーションのインストレーション、無効化、及びレギュラリクエストに使用される、人為的なコンテキストパスを生成することが望ましい。コンテキストパスは、コンテキストｉｄ、ホスト名を含む、ウェブアプリケーションインスタンスを識別する各種の値のハッシュ、オリジナルコンテキストパス、ＷＡＲコンテンツ、及び改訂番号からなることが望ましい。新バージョンのアプリケーション（バージョン１．１など）が発行され、かつ古いアプリケーションバージョン（バージョン１．０など）も有効な場合、新アプリケーションバージョンは（オリジナルバージョンとして）同じプロセスに置かれ、新リクエストは新しいアプリケーションバージョンに向けられる。古いアプリケーションに対してのリクエストが尽きると、そのアプリケーションバージョンは終了され、所定のクリーンアップが実行される。これは必須ではいが、同じカスタマの両バージョンが共に同じプロセスで動作することが望ましい。この「ホットスワッピング技術」が図１１に示されている。

明示的なウェブアプリケーションインストレーションでは、エッジサーバプロセスは、ウェブアプリケーションのインストールコマンドをＪＥＳＡＰＩへ送信し、正常応答を待ってから、そのウェブアプリケーションに関連したＨＴＴＰリクエストをアプリケーションサーバへ送信する。エッジサーバプロセスが、未だインストールされていないウエブアプリケーションに対してのリクエストに直面したため、明示的インストールリクエストが生じた場合、明示的インストール工程のために、その最初のリクエストの処理に余分な待ち時間が必要になる。或いは、ウェブアプリケーションの暗黙的インストールを実行するによって、未だインストールされていないウェブアプリケーションに対する最初のリクエストが招く遅れを最小にすることができる。その代わりに、エッジサーバプロセスは、リクエストを、指定されたウェブアプリケーションをインストールし、かつそのウェブアプリケーションにオリジナルリクエストを処理させる、事前にインストールされたアプリケーションサーバ内のＪＥＳＡＰＩ ｗｅｂａｐｐ（ＪＥＳＡＰＩ起動時に）へ送信する。これは、エッジサーバプロセスとアプリケーションサーバプロセスとの間の単一パスで達成される。これは、エッジサーバプロセスが、オリジナルのＨＴＴＰリクエストを変更し、追加データをＪＥＳＡＰＩウェブアプリケーションへ渡し、これによりアプリケーションをインストールし、リクエストを実行させることによって達成される。

望ましいリクエスト処理オペレーションが図１２に示されている。ＪＥＳＡＰＩは、アプリケーションサーバに、各リクエストを処理するために個別スレッドの割当てを要求することが望ましい。同じスレッドが、そのリクエストを処理する全てのＪＥＳＡＰＩコールを行うことが望ましい。エッジサーバプロセスがリクエストを受信し、必要に応じて、対応するｗｅｂａｐｐをアプリケーションサーバへインストールを行った後であるが、リクエストをｗｅｂａｐｐコンテキストに送る前に、エッジサーバプロセスは、アプリケーションサーバとＪＥＳＡＰＩ サーブレットフィルタによって正しく処理されるように、ＨＴＴＰリクエストを変更する。詳細には、エッジサーバプロセスは、リクエストのＵＲＩを変更し、人為的なコンテキストパス（これでアプリケーションサーバはこのリクエストを、すでにインストールされている固有コンテキストインスタンスへ、正しくマップできる）を含める。エッジサーバプロセスも、リクエストの取扱い方法に関する追加データをＪＥＳＡＰＩサーブレットフィルタに供給する種々のＪＥＳＡＰＩ内部ヘッダーを挿入する。

図１３は、複数のアプリケーションサーバインスタンスが、望ましくは、エッジサーバを使用するＣＤＮカスタマごとに設けられた実装例である。従って、カスタマごとのＪＶＭインスタンスごとに１つのアプリケーションサーバが設けられていることが望ましいが、これに限定されない。この例では、エッジサーバ１３００は、Ｌｉｎｕｘカーネルなどのオペレーティングシステム１３０２を持つマシンである。エッジサーバマネージャプロセス１３０４は、子Ｊａｖａアプリケーションサーバインスタンス１３０６ａ−１３０６ｎと、望ましくは、ＴＣＰソケットを経由し共用メモリ１３０８を使用して、通信する。各Ｊａｖａアプリケーションサーバインスタンスは、それ自身のＪＶＭ１３１０の上で動作する。従って、この実施では、カスタマごとに１つのアプリケーションサーバ／ＪＶＭインスタンスがあることが望ましく、このアプリケーションサーバ／ＪＶＭインスタンスは、エッジサーバマネージャからのプロセスから動作する。子アプリケーションサーバプロセスは、エッジサーバマネージャから分岐された後、それぞれはＪａｖａマネージャサブシステム１３１２によって緊密に監視され、制御される。エッジサーバマネージャは、ローカルＴＣＰソケット上でのアプリケーションサーバ処理を要求するクライアントリクエストを子アプリケーションサーバプロセスへ送信する。子アプリケーションサーバプロセスは、リクエストを処理し、同じ接続で応答を送信する。さらに、リソース利用負荷が、共用メモリセグメント１３０８を通して、各アプリケーションサーバプロセスから、Ｊａｖａマネージャサブシステム１３１２へレポートされる。マネージャサブシステム１３１２は、各子アプリケーションサーバプロセスのリソースの利用度を緊密に監視し、リソースを使い過ぎているアプリケーションサーバを強制終了する。

特に、各子アプリケーションサーバプロセスで消費されるリソースが、望ましくは、各アプリケーションサーバプロセスによって起動時にロードされる共用オブジェクトコンポーネントによって監視される。これらには、Ｊａｖａ Ｅｄｇｅ Ｓｅｒｖｉｃｅｓ ＡＰＩ （ＪＥＳＡＰＩ）共用オブジェクト１３１４、及びインターセプト共用オブジェクト１３１６が含まれる。ＪＥＳＡＰＩ共用オブジェクト１３１４は、特定のＪＥＳＡＰＩ Ｊａｖａネイティブコールを実装し、共用メモリセグメント１３０８を介してＪａｖａマネージャサブシステム１３１２と通信する役割を持つ。 インターセプト共用オブジェクト１３１６は、“ｏｐｅｎ”、“ｃｌｏｓｅ”、“ｇｅｔｈｏｓｔｂｙｎａｍｅ”などの各種「インターセプト」システムコールをロードする。マネージャサブシステム１３１２は、システムコールをインターセプトすることによって、アプリケーションサーバが行おうと意図した“実”システムコールを行う前に、一部のコールへのアクセスを防止したり、中間的な計算を行ったり、統計をとったりできる。インターセプト共用オブジェクトは、任意のリソースの利用度をＪＥＳＡＰＩ共用オブジェクトへレポートすると、ＪＥＳＡＰＩ共用オブジェクトは、共用メモリセグメントを介してＪａｖａマネージャサブシステムへそれをレポートする。

各アプリケーションサーバプロセスについて、以下の種類のリソースが監視される。メモリ−ＪＶＭのインターナルＪａｖａヒープ（即ち、アプリケーションサーバが割当てるＪａｖａオブジェクト用のメモリ管理が行われるヒープ、及びアプリケーションサーバ内で動作するｗｅｂａｐｐｓ）；ＣＰＵ−各リクエストがアプリケーションサーバ内でアクティブであった期間に、リクエストのために消費されたＣＰＵ時間；ディスク−アプリケーションサーバが実行するディスク操作で、クライアントリクエストの結果として行われたディスク操作（ＪＥＳＡＰＩ共用オブジェクトも、ディスクの読取りが、ディスク、バッファキャシュいずれで行われたかをチェックし、この結果、フリッツを正しくリクエストにアトリビュートできる）を含む；ネットワーク−各アプリケーションサーバプロセスがｉｎｃｌｕｄｅＵＲＬの「取出し」のために開くソケットの数。Ｊａｖａマネージャサブシステム１３１２は、リソースの利用度に基づいた一組のポリシーなどを通して、リソース管理を実行する。従って、例えば、Ｊａｖａマネージャは、以下の方法で以下のリソースを使い過ぎている子アプリケーションサーバプロセスを強制終了する；メモリ−アプリケーションサーバのＪａｖａヒープが、カスタマメタデータに設定されている構成可能量より多くのメモリを使用していると、それは強制終了される；暴走リクエスト−暴走リクエストは、「不当に」長い時間（構成可能な数）に亘り処理が続いているリクエストであり、アプリケーションサーバが起こした暴走が構成可能数に達すると、そのアプリケーションサーバが強制終了される；オープンソケット−アプリケーションサーバが開いたソケット（クローズされたことがないソケット）の数が構成可能なリミットに達した場合、アプリケーションサーブレットが強制終了される。リソースの利用率を制限することによって、どのアプリケーションサーバインスタンスも、そのサーバのリソースを独占使用してしまわないことが保証される、

上記のリソース管理のほかに、Ｊａｖａ Ｓｅｃｕｒｉｔｙ Ｍａｎａｇｅｒフレームワークは、各アプリケーションサーバプロセスで動作するウェブアプリケーションにセキュリティ上の制約を課すことによって、サンドボクシングを行う。この制約は、セキュリティポリシーファイルと Ｊａｖａ Ｓｅｃｕｒｉｔｙ Ｍａｎａｇｅｒ実装の組合せによって行われることが望ましい。以下の制約が、Ｊａｖａウェブアプリケーションに課されることが望ましい。ファイルシステム−カスタマウェブアプリケーションは、ファイルシステムに対して読出し書込みができない（但し、スタティックｈｔｍｌなどそれら自身のＷＡＲファイル内のファイルは読める）；ソケット−カスタマウェブアプリケーションはＪａｖａソケットをオーブンできない；スレッド−カスタマウエブアプリケーションは、Ｊａｖａスレッドの始動／停止／変更を行うことができない；コード−カスタマウェブアプリケーションは、ＪＥＳＡＰＩ或はアプリケーションサーバクラスを読むことができない。ソケットの場合、カスタマｗｅｂａｐｐは、ＨｔｔｐＵＲＬＣｏｎｎｅｃｔｉｏｎ Ｊａｖａクラスを通して組込ファイルを取出すことができることが好ましい。このクラスは、ＪＥＳＡＰＩコードによってインターセプトされ、かつ、ｉｎｃｌｕｄｅを強制的にエッジサーバマネージャプロセス（そして、オープン接続の数を監視する）だけを通して行わせる。更に、フレームワークによって、カスタマに生のＪａｖａソケットのオープンすることを許容することが望ましい。この理由は、前述のインターセプト共用オブジェクトは、全てのソケットＡＰＩコールをインターセプトし、そのアプリケーションサーバプロセスによって行われた接続数を監視するからである。インターセプトオブジェクトは、次に、ＨＴＴＰ ＣＯＮＮＥＣＴ方法を使用して、エッジサーバマネージャプロセスへ接続する。次に、エッジサーバマネージャプロセスは、所望のホストへのソケットをオープンする。

上記の、リソース管理、サンドボクシング、及びセキュリティ機能は。単なる例示に過ぎない。ユーザーＩＤによるリソース管理など、ほかの手法も使用できる。そのような場合、各アプリケーションサーバプロセスが起動した後、ｓｅｔｕｉｄが実行され、固有ユーザーＩＤへのプロセスが設定される。一旦、この固有ＵＩＤに設定されると、リソース管理用のほかのオペレーティングシステムカーネル機能が使用可能になる。これらには、総スレッドの限度、ファイルシステム割当て、ソケットフィルタ、などがある。更に、このアプローチは、アプリケーションサーバプロセスをファイルシステムのサブセットに制限し、サブセット以外では読取り、書込みを不可するための、その他のシステムコール（“ｃｈｒｏｏｔ”など）の使用を可能にする。

当業者であれば分かるように、ＪＥＳＡＰＩインタフェースは、アプリケーションサーバを変更しないでもサポートできるように、例えば、上記の様に設計できることである。或いは、アプリケーションサーバのベンダーは、アプリケーションサーバの機能を、そのアプリケーションサーバがＣＤＮサーバプロバイダのエッジサーバプラットフォームで動作するように変更ができる、この場合、そのエッジサーバで動作可能にするには、サーブレットコンテナへ変更を加える必要がある。従って、例えば、可能な場合には、既存のサーブレットコンテナコンポーネントの新しいサブクラスを、（必要に応じて）生成し、次に、変更を加えて、エッジサーバマネージャにインタフェースさせる必要がある。いずれの場合も、エッジサーバマネージャは、エッジサーバ自身との間でクライアントリクエストへインタフェースすることが望ましい。

エッジ配置可能（ｅｎａｂｌｅｄ）アプリケーションフレームワークに関する他の様相を以下に記述し、いくつかの例についても示す。

カスタマ構成
エッジサーバは、クライアントからのリクエストを受信した場合、最初に、そのリクエストを適切なカスタマ構成ファイルと組み合わせることが望ましい。構成ファイルは、例えば、図１に示した、ＣＤＮメタデータ伝送システムなどの、便利なメカニズムを介してエッジサーバへ配信できる。勿論、エッジサーバへカスタマ構成データを供給するための任意の技術が使用可能である。カスタマ構成が、Ｊａｖａプロセッシングをリクエストに関連づける場合、既述の通り、Ｊａｖａプロセッサが関与する。

Ｗｅｂコンテナ
上記の通り、ＷＡＲファイルがすでにエッジサーバに存在する場合、Ｊａｖａプロセッサは、適用可能なサーブレット或はＪＳＰページ（Ｗｅｂ層処理用）を使用して、リクエストへの応答を生成する。標準配備記述子を使用し、そのリクエストをサーブレットへ正しくマップすることが望ましい。Ｊａｖａアプリケーションが、現時点で、エッジサーバに存在しない場合、オリジンサイト或は何らかの他のソースから検索される。この検索プロセスは、かなりの待ち時間の原因になるので、アプリケーションの検索は非同期的に行われ、一方、初期リクエストは、同時に、オリジンサーバへトンネルされる。処理の終わったリクエストの出力は、ユーザーへ返される。実行済サーブレットは、次のユーザーのためにメモリに残っていることが望ましい。

ネットワーク及びリソースの管理
サーブレットは、不適切な量のリソースを消費するプロセスがでないように管理することが望ましい。正しいリソース監視及びロードバランシングによって、同時に動作している別のアプリケーションに影響を与えるアプリケーションが存在しないことが保証される。Ｊａｖａアプリケーションは、ネットワークを介してコンテンツのリクエストを行える。リクエストは、ＨＴＴＰ及びＨＴＴＰＳプロトコルを通して行うことが望ましい。その他のＪａｖａリソースのリモート呼び出しも、ＨＴＴＰを通して行うことが望ましい。

オリジンサイトの役割
オリジンサーバは、特に、Ｗｅｂ層だけがエッジネットワーク上に配備される場合、エッジアプリケーションの重要な部分を占める。更に、一部のサーブレットは、集中化リソースへのアクセスに依存しているため、全てのリクエストをエッジサーバで処理することはできない。こうした場合、オリジンサイトは、エッジ配置不可リクエストを実行する役割、及びエッジ配備アプリケーションによって出される可能性があるリモートコールに応答する役割を持つ。

以下は、こうした状況でのオリジンサーバの代表的な役割である；エッジ層からのＲＭＩリクエストへ応答すること、静的及び動的コンテンツからのＨＴＴＰリクエストに応答すること、必要に応じて、エッジサーバの動作を制御するＨｏｓｔ Ｒｅｓｐｏｎｓｅ Ｈｅａｄｅｒ （ＨＲＨ）を設定すること、エッジサーバによってリクエストがなされたとき、ＷＡＲファイルを送ること、及びエッジ層のＪＤＢＣリクエストに応答すること。

エッジからオリジンへの通信
エッジサーバのサーブレットとオリジンサイトとの間の通信は、下記の通り、ＨＴＴＰ或はＨＴＴＰＳプロトコルを介して生じることが望ましい。Ｒｅｍｏｔｅ Ｍｅｔｈｏｄ Ｉｎｖｏｃａｔｉｏｎ （ＲＭＩ）通信は、ＨＴＴＰを介してトンネルされる；ＳＯＡＰメッセージは、ＨＴＴＰ或はＨＴＴＰＳを介して交換される；ＪＤＢＣは、ＨＴＴＰ／ＨＴＴＰＳを介してトンネルされる；リレーショナルデータベースクエリへの応答は、ＸＭＬ（エッジサーバが結果をキヤシュし、それらを以降のリクエストで再利用し、層間での待ち時間を最小にすることを可能にする）形式でエンコードされる；通信がエッジからオリジンであるか、オリジンからエッジであるかに関係なく、サーブレット制御方法（ＲｅｑｕｅｓｔＤｉｓｐａｔｃｈｅｒ．ｉｎｃｌｕｄｅ（）及びＲｅｑｕｅｓｔＤｏｓｐａｔｃｈｅｒ．ｆｏｒｗａｒｄ（）など）がサポートされることが望ましい；そして、メッセージがＨＴＴＰ或はＨＴＴＰＳで伝送される場合には、カスタム通信ソリューションがサポートされる。図１４は、これらの技術の解説である。

アプリケーションがスケーラブルで、かつ、エッジに存在することの利点が確実に得られるようにするには、エッジとオリジンの間で送信されるバイト数及びコール数を最小にすべきである。これは、例えば、データをエッジにキャシュすること、及び、データアクセスファサードを使用することによって達成できる（データベースに複数のコールを行う代わりに行う（この場合、エッジ配置可能サーブレットを使用してエッジ配置不可サーブレットをコールし、それに代わってデータベースコールを行う））。

アプリケーションのステージングと配備
Ｊ２ＥＥアプリケーションは、モジュラー形式で、かつ、特定の構造を有することが勧められる。フレームワークは、多くのＪ２ＥＥアプリケーションが分離されて構造化されていることによる恩恵が得られる。以下は、アプリケーションアーキテクト（設計者）がフレームワークの持つ利点を利用できる種々のアプローチの要約である。

純粋なエッジ配置可能サーブレット
サーブレットは、正しい応答を生成するのに必要な全ての情報をリクエストが含んでいる場合に、エッジ配置可能と見做すことができる。

目標とする応答
コンテンツターゲット情報（ユーザーの国籍、州、市、帯域幅、など）を使用するサーブレットも、全てをエッジから配信することが可能である。アプリケーションプログラミングインタフェース（ＡＰＩ）が、コンテンツターゲット情報へアクセスするために提供され、アプリケーションは、この情報を利用して応答をカスタマイズすることができる。このサーブレットは、ＡＰＩを使用して、エンドユーザーに関する情報を取得する。

データのＸＭＬとしてのキャシュ
フレームワークによって、アプリケーションはデータをＸＭＬとして容易にキャシュ及びアクセスすることが可能になる。ＸＭＬは、データの生成、格納、アクセスのための便利なプラットフォームに寛容な（agnostic）手段である。

多くのデータベースは、格納されているレコードからＸＭＬを作り出すための直接的な手段を提供する。ＸＭＬコンテンツをエッジにキャシュしておくことによって、データ検索に伴う待ち時間が短くなる。エッジサーバは、キャシュされているＸＭＬファイルの簡単な構文解析及び操作を可能にする、ＪＡＸＰ及びＸＭＬクエリークラスを含むことが望ましい。更に、アプリケーションは、Ｗｅｂアプリケーションの中でＸＳＬＴ処理を使用して、オリジン或はキャシュから検索されるＸＭＬデータを変換し、呈示することができる。

ＸＭＬＷｅｂサービスの使用
Ｗｅｂサービスアーキテクチャは、アプリケーションが、標準ＸＭＬ及びインターネットプロトコルを使用して、他のアプリケーションからデータ及びロジックへアクセスする方法を定義する。Ｗｅｂサービスは、エッジサーバが通信するのに使用する簡単なメカニズムを提供する。エッジサーバは、オリジン或は第三者サイトで動作するサービスとのＳＯＡＰ通信を可能にするのに必要なＪａｖａクラスを含むことが望ましい。

エッジサーバからのＪＤＢＣの使用
ＪＤＢＣコールがオリジンへトンネルされることが望ましい。層間での待ち時間を最小にし、かつ、キャシングの恩恵を受けるため、ＪＤＢＣコールへの応答をキャシュし、種々のリクエストの間で共用することができる。

エッジサーバからのＲＭＩの使用
ＲＭＩは、エッジサーバとオリジンとの間のオブジェクト間の通信に使用できる。エッジ配置可能アプリケーションは、リモートに位置するオブジェクトメソッドを、そのオブジェクトがローカルに位置していたかのように、コールできる。メソッドの呼出しは、キャシュされることが望ましい。

共用のシナリオ
以下の共用パターンは、分散Ｊａｖａプラットフォームで動作するＪ２ＥＥアプリケーションを設計し、開発するときに使用できる。多くの種類のデザインパターンが可能であるが、ここでの記述は、より共用性が高いいくつかのパターン、それらの利点、及び適用性が最も高い状況に重点を置いている。

純粋のエッジリクエストの処理
記述
リクエストは、正確な応答を生成するのに必要な全ての情報を含む。
リクエストに含まれる情報は、ＨＴＴＰヘッダー（Ｃｏｏｋｉｅ、Ｒｅｆｅｒｅｒ、その他）、クエリーストリング、或は、ＨＴＴＰ ＰＯＳＴ本体（フォームフィールドデータ、アップロードされたデータ、その他）などで、エッジアプリケーションが応答を生成するのに十分である。

シナリオ
・ＨＴＭＬフォームの検証−ユーザーが作成したＨＴＭフォームは、処理の前に検証が必要になる場合が多い。クレジットカード番号、Ｅメールアドレス、電話番号など、フィールドのフォーマットが正確かどうがチェックしなければならない。
・言語のカスタマイズ−応答内のテキストは、リクエスタが「Ａｃｃｅｐｔ−Ｌａｎｇｕａｇｅ」ヘッダーに望ましいものとして供給した言語に設定される。

実装
フォームの検証
この例では、エッジ配置可能サーブレットは、ローカルクラスのライブラリを使用してリクエストを処理し応答を返す。サーブレットは、関連するメソッドを用いて、次のフォーム画面を提供する前に、提供したデータの正確性を検証する。
言語のカスタマイズ
サーブレットは、関連するヘッダーの存在をテストして、適切なバージョンのＨＴＭＬにて応答する。

目標とする応答
記述
応答は、エンドユーザーの居在地或は接続性など、コンテンツターゲット情報によって決定される。
シナリオ
・ローカライズされたページをもつ、オンライン配信サイト
・現地の天気情報をもつオンラインポータル
・市場セグメントデータを使用してカスタマイズされたフロントページを提供するショッピングサイト
実装
コンテンツ対象情報へアクセスするためにアプリケーションプログラミングインタフェース（ＡＰＩ）が提供される。アプリケーションはこれを使用して、応答をカスタマイズできる。サーブレットは、ＡＰＩを使用して、エンドユーザーについての情報を取得する。

簡単なバイナリデータのキャシング
記述
ＸＭＬデータ、トンネルされたＪＤＢＣ応答、ＳＯＡＰ応答などのＨＴＴＰ応答は、リクエストをエッジサーバを介して行うだけでキャシュされることが望ましい。ＨＴＴＰ応答のキャシングは、同じリソースが、１つ以上のサーブレットによって複数回使用されている場合に特に有用である。ＡＰＩによって、アプリケーションは、コンテンツの新鮮さが維持されていることを確認できる。
シナリオ
・オリジンのデータベースに格納されているユーザーの好み−エッジ上のこれら属性にアクセスすることによって待ち時間が減少する。
・オリジンのデータベースに格納されているショッピングカート−ユーザーが行うリクエストの多くは、ショッピングカートの内容の更新を行わない。キャシュされたショッピングカートのコピーをエッジにキープしておき、ユーザーがアイテムを一つ追加するか削除するときにのみ、内容を更新すると便利である。
実装
ユーザーの好み
ユーザーの好みは、データベースからプロパティを検索するサーブレットへリクエストを送ることによって、オリジンから検索できる。このファイルは、ハッシュ、ＸＭＬなどであることができる。
同じＵＲＬに対する後続リクエストは、キャシュから提供される。

ショッピングカートオブジェクト
或いは、エッジ配置可能アプリケーションは、ＨＴＴＰ ＳＯＡＰ ＲＰＣコールを使用して、オリジンによってカスタマの状態を保守する。オリジンは、ウェブサービスとしてショッピングカートに作用する全てのメソッドを提供できる。ＨＴＴＰ ＳＯＡＰ ＲＰＣコールは、必要時に、ショッピングカートの状態を更新するが、殆どの時間、ショッピングカートは読出しのみで、更新はなされない。バージョン番号が同じ、全ての後続コールは、キャシュされたショッピングカートを返す。

応答はキヤシュされているので、そのＵＲＬへの後続リクエストは、同じｃａｒｔ＿ｉｄであれば、同じ応答がもたらされる。ユーザーが、ショッピングカートのコンテンツを変更するトランザクションを生成すると、カートのバージョン番号は増加される。バージョンの更新がなされた後、それ以降のリクエストは、オリジンへのコールをもたらす。現在のカートバージョン番号は、クッキー、或はその他のユーザー専用プロパティオブジェクトに格納できる。

ＸＭＬデータのキャシング及び使用
記述
アプリケーションは、大量のデータにアクセスすることが必要になる場合が多い。ＸＭＬは、大量のデータを生成、格納、アクセスするための便利なプラットホームに寛容な方法である。多くのデータベースは、格納されているレコードからＸＭＬを生成する直接的な方法を提供する。ＸＭＬコンテンツをエッジにキャシュしておくことによって、データ検索に伴う待ち時間が短くなる。

シナリオ
・カタログデータをネットワークのエッジにキャシュする方法−多くのオンラインストアの場合、カタログの更新の発生が稀かであるか、その更新が直ぐ有効になることは重要でない。彼らが大きな恩恵をうけるのは、データベースを、ユーザーの近くで動作するサーブレットで使用できることである。

実装
最も単純なシナリオは、単に必要データに対するＨＴＴＰリクエストを行う（必要な場合、クエリーパラメータを渡す）というものである。データをリクエストするプロセスがそれをキャシュするのに十分であることが望ましい。オブジェクトの新鮮さをコントロールするには、サーバのＨＴＴＰヘッダー、或はリクエストのＴＴＬパラメータを使って、データをどれだけ長くキャシュしておけるかを指定する。或いは、データのバージョン番号を使って、データが変化したとサーブレットが判断したときに、キャシュミスを強制できる。このデータにアクセスするには、ＸＭＬパーサ（構文解析）が使用できる。代案は、ＸＭＬクエリー実装を使って、関連したレコードだけをキャシュされたＸＭＬから検索することである。コンテンツプロバイダが、必要と判断した場合、キャシュされているカタログを無効化することができる。この無効化は、例えば、管理されたＳＯＡＰ無効化サービスへ接続するなど、によって、プログラム的にも起こり得る。

エッジサーバからのＪＤＢＣの使用
記述
エッジからのＪＤＢＣクエリーを管理するための種々のアプローチがある。あるパターンは、コモンＳＱＬクエリーの結果をキャシュすることによって機能する。別のパターンは、大きいデータセットのキャシュは行うが、アプリケーションは関連データだけしか読出すことができない。これらのパターンを使用することによって、データベースの負荷は軽減され、層間での通信によって生じる待ち時間は最小になる。
シナリオ
・データベース駆動のカタログサイト

実装
ＪＤＢＣの実装
サービスプロバイダは、ＪＤＢＣドライバの実装を設けることも望ましい。これによって、エッジサーバは、オリジンと通信を行い、データベースがローカルに動作していたかのように、クエリーを出すことが可能になる。この実装でも、クエリーの結果をキャシュすることが望ましい。コンテンツの新鮮度の保守は、所定の新鮮度メカニズムを、サービスされた結果に対して設定する、コンテンツのコール時に存続時間（ＴＴＬ）を特定する、或いはバージョニング方式を使用することによって行われる。ＪＤＢＣドライバは、ＳＯＡＰコールを行うことが好ましい。これにより、エッジサーバが応答をキャシュし、再利用できるようになる。

Ｒｅｓｕｌｔ Ｓｅｔｓの実装
ＪＤＢＣのコールの必要性を最小限にするための１つの技術は、ＲｅｓｕｌｔｓＳｅｔｓＯｂｊｅｃｔを使用することである。このアプローチでは、データバースのコンテンツをもつ単一の大きいオブジェクトを生成する。これは、別のリクエストがこの拡張済セットからの結果を使用するであろうという予測の上に行われる。別のサーブレットが同じリクエストを出した場合、同じオブジェクトが返される。Ｒｅｓｕｌｔ−ｓｅｔキャシングのクラスを使って、検索済データを横断しアクセスできる。

リモートウェブサービスの使用
記述
第三者提供サービスを利用することは、他社の能力を利用し、かつ、アプリケーションの複雑性を最小限にする上で役に立つ。
シナリオ
・株価追跡機能を提供する個人化ポータル
・組込み気象情報（コンテンツターゲットデータに基づく居住地）
実装

気象情報
標準ＳＯＡＰクライアントの実装が使用できる。
キャシュコヒーレンスオブジェクトによるデータ同期
記述
アプリケーションが、互いに矛盾のない状態にあることが必要な、複数のキャシュ可能アイテムを使用している場合、各アイテムをオリジンと同期させる代わりに、単一のオブジェクトは、そのコンテンツのバージョンＩＤを保持するコヒーレンスメカニズムとして機能できる。
シナリオ
アプリケーションは、キャシュされたイメージ及びこれらイメージの説明を含むテキストファイルを使用する。
実装
所定のプロパティをもつコヒーレンスオブジェクトが定義される。この小さいオブジェクトは、オリジンへトンネルされるか、比較的短い時間キャシュされ、次に、コンテンツが使用される前に検討される。その結果、データは長い時間キャシュしておくことができるが、コンテンツプロバイダは、依然、コンテンツの新鮮度の支配権を維持している。

リモートオブジェクトでのＲＭＩの使用法
記述
ＲＭＩは、エッジサーバとオリジンの間のオブジェクト間通信に使用できる。エッジ配置可能アプリケーションは、リモートに位置するオブジェクトメソッドを、オブジェクトがローカルにあったかのようにコールできる。これによって、アプリケーションはオリジン及びエッジの固有能力及び適宜利用することが可能になる。

適用性
このアプローチが最適といえるのは、使用中のオブジェクトがオリジンに密接に関連しており、キャシングの恩恵が得られない場合である。そのオブジェクト自身をキャシュすることが可能で、一部のメソッドだけが、オリジンの使用を必要としている場合には、次に述べる、Ｏｐｔｉｍｉｚｅｄ ＲＭＩメカニズムを使うことを考える。
シナリオ
ドライバに運転の方向を提供するウェブサイトは、正確な経路を計算するために、オリジンを使用する必要がある、しかしながら、エッジ配置可能サーブレットは、ローカルオブジェクトを加工し、コードを（プログラム）大幅に変更しなくでもよいようにすることが望ましい。
実装
標準ＲＭＩ呼出しが使用される。オブジェクトは、インスタンスが生成されると、ローカルで動作しているかのように、シームレスに働く。このメソッドは、潜在的に、層間のトラフィックを増やし、サーバのパフォーマンス低下を招く。この例では、ＣＤＮがＪＮＤＩを有しない場合には、ＣＤＮサービスプロバイダ専用ＪＮＤＩクライアントが使用される；或いは、オリジンのサーブレットへのリクエストの生成され、これにより、インスタンスが生成されたオブジェクトを表すＲＭＩスタッブの返送がなされる。

最適化されたＲＭＩ／オブジェクトのキャシング
記述
ＲＭＩオブジェクトを使用することの欠点の１つは、データのアクセス、或はメソッドコールでオリジンとの通信が必要になることである。このパターンは、ローカルに呼び出せるメソッドをこのようにして呼び出し可能にする。
適用性
このパターンは、頻繁に使用されるオブジェクトのメソッドが、オリジンでは実際には実行する必要がない状況に対して適用される。
シナリオ
・エッジで実行可能な、複数のメソッドコールを送る、ショッピングカートオブジェクトの実装である（ただし、このオブジェクト自身はオリジンで保守する必要があるが）。
実装
エッジ配置可能オブジェクトは、リモートオブジェクトのクラスをサブクラス化することによって生成される。オリジンで実行することが必要なメソッドは、リモートオブジェクトのＲＭＩ表現を使用するため無効にされる。リモートメソッドが実行された後、エッジオブジェクトの状態は、オリジンと同期される。ローカルメソッドが実行されると、これらは、直接、オブジェクトのローカル表現を用いて機能する。例えば、ｇｅｔｔｅｒなど、読込専用メソッドは、層間のトラフィックを生成することはない。

このシナリオは、リモートでの処理が要求されるこれらのメソッドが、ＲＭＩを介して、同一オブジェクトについて、オリジンによって行われたことを示している。ローカルに実行可能なメソッドは、オブジェクトのキャシュされた表現で実行される。

本発明は、Ｊａｖａベースのウェブアプリケーションを、インターネットのエッジ、エンドユーザーの近くで実行し、幾つかの利点を提供できる能力を配信する。このウェブアプリケーションは、パフォーマンスを最大にするのに必要なだけの台数のサーバによってサービスを受ける。新しいサーバは、企業の支出なしに、トラフィックの増加を基にして自動的に割当てられる。アプリケーションをオリジンから分散ネットワークへオフロードすることによって、単独の拠点での障害を無くすことができる。更に、エッジサーバを監視すること、冗長性のビルトイン、及びユーザーを瞬時に最適なサーバへマップする能力によって、ＣＤＮサービスプロバイダは、ネットワークの混雑をバイパスし、ハードウエアの障害を克服することができる。アプリケーション処理を単一オリジンからエッジの多数のサーバへオフロードすることによって、著しいパフォーマンス増加がもたらされる。各ユーザーを、最適、或は、望ましいサーバへマップすることによって、ＣＤＮサービスプロバイダは、インターネットのボトルネックを避けて、待ち時間を劇的に短くすることができる。サーバをオンデマンドに割当てる能力があるため、処理能力、或は帯域幅の不足は起こらない。オリジンサイトで動作するのに必要な、アプリケーションサーバの数を減らすことによって、ＣＤＮサービスプロバイダは、ハードウエア及びソフトウエアの保守及び管理に伴う複雑さを軽減できる。

エッジ配置可能ＣＤＮアプリケーションとして実装され、配備されるアプリケーションコンポーネントのタイプについての制限はない。上記の例に加えて、代表的なアプリケーションとして、限定するものではないが、製品コンフィグレータ、ディーラロケータ、コンテストエンジン、コンテンツトランスコーダ、コンテンツジェネレータ、サーチアグリゲータ、フィナンシャルカルキュレータ、レジストレーションエンジン、及びその他多数が含まれる。

当業者であれば、多くの変形が本発明の範囲内にあることを認識できる。従って、例えば、特定のエッジサーバは、第一種のアプリケーションサーバインスタンス（例えば、Ｔｏｍｃａｔサーブレットコンテナ）及び２番目の、別の種類のアプリケーションサーバインスタンス（例えば、ＩＢＭ ＷｅｂＳｈｅｒｅ Ａｐｐｌｉｃａｔｉｏｎ Ｓｅｒｖｅｒ）を実行できる。すでに述べたように、通常、複数のサービスプロバイダカスタマによるサーバを使用し易くするため、特定のアプリケーションサーバの複数のインスタンスが１つのエッジサーバで使用される。勿論、Ａｐａｃｈｅ Ｔｏｍｃａｔ以外の他のウェブコンテナを使用して、Ｗｅｂ層を実装でき、また、ＩＢＭ ＷｅｂＳｈｅｒｅ Ａｐｐｌｉｃａｔｉｏｎ Ｓｅｒｖｅｒ）以外の他のエンタープライズコンテナを使用して、エンタープライズコンテナを実装できる。特定のアプリケーションは、エッジ及びオリジナル両方で実行されるコンポーネントを有していなければならないという条件はない。実際に、あるアプリケーションは、エッジ配置可能アプリケーションとして完全にスタンドアロン方式で実行される。また、アプリケーションコンポーネントが、ＷＡＲ或はＥＡＲファイルとしてパッケージされるという条件もない。何故なら、そのアプリケーションコンポーネントをエッジへ配備するために任意の便利なメカニズムを使用出来るからである。アプリケーションコンポーネントが特定のエッジサーバでのクライアントリクエストに応答してのみロードされるという条件はない。実際、多くの場合、予想される将来におけるそのアプリケーション或はコンポーネントの必要性に基づいて、或は、故障許容の目的のためにアプリケーション、或はコンポーネントを事前配備しておくことが望ましい。そのため、エンドユーザーのリクエストがそのサーバで受信されたかどうかに関係なく、アプリケーション或はコンポーネントは、ある特定のエッジサーバへ配信され、初期化され、起動される。また、アプリケーションコンポーネントの、全て或は一部がＪ２ＥＥ準拠であること、しかも、主題の全てがＪａｖａで実装されること、という条件はない。確かに、本発明は、Ｊａｖａ及びＪ２ＥＥを超えて拡張可能でもある。とりわけ、本発明の概念は、（例えば、Ｍｉｃｒｏｓｏｆｔ．ＮＥＴ、Ａｐａｃｈｅで動作するＭｏｄ ｐｅｒｌ、Ｚｏｐｅなど）コンテンツ配信ネットワークなどの分散コンピューティング環境へ配備可能な、あらゆるプラットフォーム非依存のアプリケーションサーバプログラミング環境で実施できるものである。

ＣＤＮサービスプロバイダは、企業のファイアウォール内でアプリケーションのテスト及びデバッグを行う能力を提供することができる。テスト用サーバは、ＣＤＮエッジサーバシミュレータで、これは、アプリケーション開発の間、及び、アプリケーションがそのプラットフォームのランタイム環境で動作することを検証するテストの間、使用可能である。

準備されたエッジ配置可能アプリケーションを配備するために、コンテンツプロバイダは、そのアプリケーションを（例えば、ＦＴＰを使用して）、ＣＤＮステージングネットワークへ公開することが望ましい。ステージングネットワークは、ステージングサーバのセットで、ＣＤＮエッジサーバ或はその他のセットになる。これにより、企業の品質管理担当がアプリケーションのテストを遂行できるステージング環境が作り出される。アプリケーションは、テストが成功であれば、望ましくはセキュアなウェブインタフェースを介して、公開すること。図１５は、このプロセスを示し、サービスプロバイダポータルを利用している。カスタマは、プログラミング的に、アプリケーションをアップロードし、配備し、そして提供できる。エッジへの配備は、自動的に行われることが望ましい。エッジに配置可能なアプリケーション或はそれらのコンポーネントは、ＣＤＮコンテンツ蓄積ネットワーク或はその他の第三者サーバからも配備できる。既に述べたように、アプリケーションコンポーネントも、事前に特定のエッジサーバ或はサーバリージョンへ取り込んでおき、起動時の待ち時間を短くすることもできる。しかしながら、一般的な場合、エッジアプリケーションコンポーネントは、事前配備はされず、エンドユーザーは、ある特定のエッジサーバへマップされている。そのエンドユーザーリクエストが、次に、設定フェーズに生成された構成パラメータを整合すると、そのエンドユーザーがマップされているエッジサーバは、対応するＪａｖａアプリケーションのロードを試みる。Ｊａｖａアプリケーションがキャシュに無い場合、ステージングネットワーク、或はコンテンツ蓄積ネットワーク、或はその他のサーバから検索される。アプリケーションは、次のリクエストのために、そのサーブレットコンテナに常駐させておくことが望ましい。使用しないアプリケーションは、Ｗｅｂコンテナからは削除し、キャシュにはそのまま格納しておくことが望ましい。あるアプリケーションが無効化されるか、或はそのアプリケーションが、長時間に亘ってアクセスされた場合、アプリケーションはディスクキャシュから削除される。Ｗｅｂアプリケーションを、無許可のアクセスから保護するには、エッジサーバだけが、アプリケーションをステージングネットワーク、或はその他のコンテンツ蓄積ネットワークから検索できることが望ましい。
以上、発明について説明してきたが、特許請求の範囲は添付の通りである。

本発明を実施できる既知のコンテンツ配信ネットワークのブロック図である。 ＣＤＮエッジサーバについての典型的なマシン構成を示す。 Ｗｅｂ層をエッジサーバに実施した本発明の第１実施形態を示す。 Ｗｅｂ層とエンタープライズ層をエッジサーバに実施した本発明の第２実施形態を示す。 一以上のエッジ配置可能アプリケーションの実行に使用するための本発明の代表的なエッジサーバを示す。 本発明によるエッジ配置可能アプリケーションのための共通リクエスト／応答データフローを示す。 本発明で使用するためのエッジアプリケーションを開発するための一技術を示す。 エッジサーバのディスパッチャコンポーネントがクライアントリクエストを受けた時の例示的通信データフローを示す。 本発明による例示的ハイレベルアウトオブプロセスリクエストの処理フローを示す。 本発明の実施形態による例示的Ｊａｖａアプリケーションサーバの処理を示す。 クライアントリクエストの処理を中断することなくアプリケーションサーバのアプリケーションをバージョンアップする、本発明の特徴による方法を示す。 図９の例示的実施形態についての代表的なリクエスト処理を示す。 図９の例示的実施形態についての代表的なリクエスト処理を示す。 複数のＣＤＮカスタマのために複数のＪａｖａアプリケーションサーバインスタンスを同時に実行する典型的なエッジサーバを示す。 アプリケーションサーバコンテナを備えたエッジサーバとオリジンサーバとの間での通信が一以上の通信プロトコルで行われるＣＤＮを示す。 ＣＤＮサービスプロパイダのセキュアカスタマポータルを利用した代表的なアプリケーション提供方法及びシステムを示す。

Claims (14)

1. 分散コンピューティング環境で実行可能な所定のアプリケーションに対するリクエストを処理するための方法であって、１台以上のオリジンサーバから処理をオフロードするためにエッジサーバ群が分散コンピューティング環境に配備され、該所定のアプリケーションは少なくとも第一コンポーネントと第二コンポーネントとを有し、前記方法は、
   所定のエッジサーバにおけるリクエストの受信に応答して、そのリクエストが所定のアプリケーションに対する最初のリクエストかどうかを判定するステップと、
   リクエストが所定のアプリケーションに対する最初のリクエストである場合、第一コンポーネントを検索するステップと、
   第一コンポーネントをインストールした後、或はリクエストが所定のアプリケーションに対する最初のリクエストでない場合は、第一コンポーネントを実行するステップと、
   必要に応じてオリジンサーバと通信して第二コンポーネントを実行するステップと、
   第一コンポーネント及び、必要に応じて第二コンポーネントの実行結果に基づいてリクエストに対する応答を生成するステップと
   を含む方法。
2. 所定のアプリケーションは、Ｗｅｂアプリケーションであり、第一コンポーネントは、サーブレット、Ｊａｖａサーバページ（ＪＳＰ）、Ｊａｖａビーンズ、及びタグライブラリを含むコンポーネント群から選択されたＷｅｂ層コンポーネントである、請求項１に記載の方法。
3. 第二コンポーネントは、セッションビーンズ、エンティティビーンズ、及びメッセージ駆動ビーンズを含むコンポーネント群から選択されたコンポーネントを含むエンタープライズ層コンポーネントである、請求項３に記載の方法。
4. 第一コンポーネントは、オリジンサーバ、ＣＤＮステージングサーバ、及びＣＤＮコンテンツ蓄積サーバの中から選択されたサーバから検索される、請求項１に記載の方法。
5. 第一コンポーネントをエッジサーバへ取り出しながら、第一コンポーネントをオリジンサーバで実行してリクエストに対する応答を容易にするステップを更に含む、請求項１に記載の方法。
6. 分散コンピューティング環境で実行可能なＪａｖａベースのアプリケーション群に対するリクエストを処理するための方法であって、オリジンサーバ群からの処理をオフロードするためにエッジサーバ群が分散コンピューティング環境へ配備され、各Ｊａｖａベースアプリケーションは、少なくとも第一コンポーネントを有し、前記方法は、
   少なくとも第一及び第二のＪａｖａアプリケーションの第一コンポーネントを、所定のアプリケーションサーバコードを有する所定のエッジサーバへ配備するステップと、
   所定のエッジサーバにおけるリクエストの受信に応答して、第一及び第二のＪａｖａアプリケーションの第一コンポーネントを所定のアプリケーションサーバコードに実行させ、リクエストに対する応答を生成するステップと
   を含む方法。
7. 第一及び第二のＪａｖａアプリケーションは、単一のアプリケーションの異種バージョンであり、前記方法は、更に、第一のＪａｖａアプリケーションがリクエストを処理している間に、リクエストを処理するために第二のＪａｖａアプリケーションをローディングし、実行を開始するステップを含む、請求項６に記載の方法。
8. 所定のエッジサーバでのリクエストの受信に先立ち、Ｊａｖａアプリケーションの第一コンポーネントが実行のために事前配備され、ロードされる、請求項６に記載の方法。
9. プロセッサ、仮想マシン、及びプラットフォーム非依存のアプリケーションサーバコードを有する、コンテンツ配信ネットワークで使用する装置の改良であって、
   各々がプラットフォーム非依存のアプリケーションサーバコードによって実行が可能な一以上のプラットフォーム非依存のコードコンポーネント群と、
   各々が所定のプラットフォーム非依存のコードコンポーネントを実行可能な一以上のアプリケーションサーバコードインスタンス群を例示するためのエッジサーバプロセスと、
   エッジサーバプロセスをアプリケーションサーバコードインスタンス及びその上で実行される所定のプラットフォーム非依存のコードコンポーネントへインタフェースするためのアプリケーションプログラミングインタフェース（ＡＰＩ）と、
   アプリケーション処理リクエストに応答し、所定のプラットフォーム非依存のコードコンポーネントを使用してリクエストを取り扱うためにＡＰＩを初期化し、アプリケーションサーバコードインスタンスを起動するためのラッパープロセスと
   を含む改良。
10. アプリケーションサーバコードインスタンスを監視し、前記の監視に応答して、所定のリソースを過度に使おうとしているアプリケーションサーバインスタンスに関しての所定のアクションを呼び出すコードを更に含む、請求項９に記載の装置。
11. 所定のアプリケーションサーバ−インスタンスで動作する所定のプラットフォーム非依存のコードコンポーネントが、他のプラットフォーム非依存のコードコンポーネントに関しての所定のアクションを行うことを防止するためのコードを含む、請求項９に記載の装置。
12. 所定のプラットフォーム非依存のコードコンポーネントは、Ｗｅｂ層コンポーネントであり、アプリケーションサーバコードインスタンスは、サーブレットコンテナである、請求項９に記載の装置。
13. 所定のプラットフォーム非依存のコードコンポーネントは、エンタープライズ層コンポーネントであり、アプリケーションサーバコードインスタンスは、アプリケーションサーバである、請求項９に記載の装置。
14. コンテンツ配信ネットワーク（ＣＤＮ）で動作するアプリケーションを実行する方法であって、コンテンツ配信ネットワークは、分散化されたエッジサーバ群、及びクライアントのリクエストをエッジサーバへマップするためのリクエストルーティングメカニズムを含み、各アプリケーションは、少なくともプラットフォーム非依存のコードコンポーネントを含み、前記方法は、
    アプリケーション群の各アプリケーションのためにプラットフォーム非依存のコードコンポーネントをコンテンツ配信ネットワーク内の所定のエッジサーバへ、必要に応じて配備するステップと、
    各エッジサーバへマップされるリクエストに応答して、対応するエッジサーバで動作するアプリケーションサーバコードに、プラットフォーム非依存のコードコンポーネントを実行させて、リクエストに対する応答を生成するステップと
    を含む方法。

Images