(57)【要約】【課題】フラグメント・キャッシングに関する方法、システム、装置、およびコンピュータ・プログラム製品を提供すること。【解決手段】メッセージが、キャッシュ管理ユニットを含むコンピューティング・デバイスで受信された後に、メッセージのメッセージ本体内のフラグメントが、キャッシングされる。キャッシュ管理ユニットでのそのフラグメントに関する後続要求が、キャッシュ・ヒットをもたらす。キャッシュ管理ユニットは、コンピューティング・デバイスがネットワーク全体に配置されるクライアント、サーバ、またはハブのどれとして働くかに無関係に、フラグメント・キャッシング動作をサポートして同等に動作する。言い換えると、このフラグメント・キャッシング技法は、ネットワーク全体を通じて均一である。キャッシュＩＤ規則が、起点サーバからのフラグメントに付随し、キャッシュＩＤ規則によって、フラグメントの一意のキャッシュＩＤを形成する方法が記述され、ダイナミック・コンテンツを、起点サーバから離れてキャッシングできるようになる。【特許請求の範囲】
【請求項１】
ネットワーク内のデータ処理システムでオブジェクトを処理する方法であって、
コンピューティング・デバイスで第１メッセージを受信するステップと、
前記第１メッセージのメッセージ・ヘッダが、前記第１メッセージがフラグメントに関連することを示すことを判定するステップと
を含む方法。
【請求項２】
前記第１メッセージのメッセージ・ヘッダが、前記フラグメントがキャッシュ可能であることを示すことを判定するステップ
をさらに含む、請求項１に記載の方法。
【請求項３】
前記コンピューティング・デバイス内のキャッシュ管理ユニットによって維持されるキャッシュに前記第１メッセージからのフラグメントを保管するステップであって、前記キャッシュ管理ユニットが、前記コンピューティング・デバイスがネットワーク全体に配置されたクライアント、サーバ、またはハブのどれとして働くかにかかわらずに、フラグメント・キャッシング動作をサポートして同等に動作する、ステップ
をさらに含む、請求項１または請求項２に記載の方法。
【請求項４】
前記コンピューティング・デバイスで第２メッセージを受信するステップであって、前記第２メッセージが、前記フラグメントに関する要求を含む、ステップと、
前記第２メッセージの受信に応答して前記キャッシュを検索するステップと、
前記キャッシュの検索に応答して前記キャッシュから前記フラグメントを取り出すステップと、
前記第２メッセージをその宛先アドレスに送信せずに、前記第２メッセージの発信元に第３メッセージで前記フラグメントを送信するステップと
をさらに含む、請求項３に記載の方法。
【請求項５】
前記フラグメントが次レベル・フラグメントへのリンクを含むトップレベル・フラグメントであるかどうかを判定するステップと、
前記フラグメントが次レベル・フラグメントへのリンクを含むトップレベル・フラグメントであるとの判定に応答して、前記次レベル・フラグメントを取り出すステップと、
前記トップレベル・フラグメントと前記次レベル・フラグメントとを組み立てられたフラグメントに組み合わせるステップと
をさらに含む、請求項１に記載の方法。
【請求項６】
前記第１メッセージから依存識別子の組を取り出すステップであって、依存識別子が、前記フラグメントを発したサーバによって生成される、ステップと、
前記フラグメントのソース識別子に関連する依存識別子の組を保管するステップと
をさらに含む、請求項１ないし３のいずれか一項に記載の方法。
【請求項７】
無効化要求メッセージを受信するステップと、
前記無効化要求メッセージから依存識別子を取り出すステップと、
前記依存識別子に関連するフラグメントの組を判定するステップと、
前記依存識別子に関連するフラグメントの前記組の前記判定に応答して、前記キャッシュからフラグメントの前記組を消去するステップと
をさらに含む、請求項６に記載の方法。
【請求項８】
前記第１メッセージからフラグメント・キャッシング規則の組を取り出すステップであって、フラグメント・キャッシング規則が、前記フラグメントのキャッシュ識別子を生成する形を決定する、ステップと、
フラグメント・キャッシング規則に従って前記フラグメントのキャッシュ識別子を生成するステップと
をさらに含む、請求項１ないし３のいずれか一項に記載の方法。
【請求項９】
前記フラグメントの前記生成されたキャッシュ識別子を使用して前記保管動作を実行するステップ
をさらに含む、請求項８に記載の方法。
【請求項１０】
前記第１メッセージが、前記フラグメントのソース識別子を含み、前記方法が、さらに、
前記フラグメントを含む応答メッセージを生成するステップと、
第１メッセージがフラグメントに関連することを示すメッセージ・ヘッダを前記応答メッセージに挿入するステップと
を含む、請求項１に記載の方法。
【請求項１１】
前記フラグメントがキャッシュ可能であることを示すメッセージ・ヘッダを前記応答メッセージに挿入するステップ
をさらに含む、請求項１０に記載の方法。
【請求項１２】
ネットワーク内のデータ処理システムでオブジェクトを処理する装置であって、
コンピューティング・デバイスで第１メッセージを受信する手段と、
前記第１メッセージのメッセージ・ヘッダが、前記第１メッセージがフラグメントに関連することを示すことを判定する手段と
を含む装置。
【請求項１３】
前記第１メッセージのメッセージ・ヘッダが、前記フラグメントがキャッシュ可能であることを示すことを判定する手段
をさらに含む、請求項１２に記載の装置。
【請求項１４】
前記コンピューティング・デバイス内のキャッシュ管理ユニットによって維持されるキャッシュに前記第１メッセージからのフラグメントを保管する手段であって、前記キャッシュ管理ユニットが、前記コンピューティング・デバイスがネットワーク全体に配置されたクライアント、サーバ、またはハブのどれとして働くかにかかわらずに、フラグメント・キャッシング動作をサポートして同等に動作する、手段
をさらに含む、請求項１２または請求項１３に記載の装置。
【請求項１５】
前記コンピューティング・デバイスで第２メッセージを受信する手段であって、前記第２メッセージが、前記フラグメントに関する要求を含む、手段と、
前記第２メッセージの受信に応答して前記キャッシュを検索する手段と、
前記キャッシュの検索に応答して前記キャッシュから前記フラグメントを取り出す手段と、
前記第２メッセージをその宛先アドレスに送信せずに、前記第２メッセージの発信元に第３メッセージで前記フラグメントを送信する手段と
をさらに含む、請求項１４に記載の装置。
【請求項１６】
前記フラグメントが次レベル・フラグメントへのリンクを含むトップレベル・フラグメントであるかどうかを判定する手段と、
前記フラグメントが次レベル・フラグメントへのリンクを含むトップレベル・フラグメントであるとの判定に応答して、前記次レベル・フラグメントを取り出す手段と、
前記トップレベル・フラグメントと前記次レベル・フラグメントとを組み立てられたフラグメントに組み合わせる手段と
をさらに含む、請求項１２に記載の装置。
【請求項１７】
前記第１メッセージから依存識別子の組を取り出す手段であって、依存識別子が、前記フラグメントを発したサーバによって生成される、手段と、
前記フラグメントのソース識別子に関連する依存識別子の組を保管する手段と
をさらに含む、請求項１２ないし１４のいずれか一項に記載の装置。
【請求項１８】
無効化要求メッセージを受信する手段と、
前記無効化要求メッセージから依存識別子を取り出す手段と、
前記依存識別子に関連するフラグメントの組を判定する手段と、
前記依存識別子に関連するフラグメントの前記組の前記判定に応答して、前記キャッシュからフラグメントの前記組を消去する手段と
をさらに含む、請求項１７に記載の装置。
【請求項１９】
前記第１メッセージからフラグメント・キャッシング規則の組を取り出す手段であって、フラグメント・キャッシング規則が、前記フラグメントのキャッシュ識別子を生成する形を決定する、手段と、
フラグメント・キャッシング規則に従って前記フラグメントのキャッシュ識別子を生成する手段と
をさらに含む、請求項１２ないし１４のいずれかに記載の装置。
【請求項２０】
前記フラグメントの前記生成されたキャッシュ識別子を使用して前記保管動作を実行する手段
をさらに含む、請求項１９に記載の装置。
【請求項２１】
前記要求メッセージが、前記フラグメントのソース識別子を含み、前記装置が、さらに、
前記フラグメントを含む応答メッセージを生成する手段と、
第１メッセージがフラグメントに関連することを示すメッセージ・ヘッダを前記応答メッセージに挿入する手段と
を含む、請求項１２に記載の装置。
【請求項２２】
前記フラグメントがキャッシュ可能であることを示すメッセージ・ヘッダを前記応答メッセージに挿入する手段
をさらに含む、請求項２１に記載の装置。
【請求項２３】
オブジェクトを処理するためにネットワーク内のデータ処理システムで使用される、コンピュータ可読媒体内のコンピュータ・プログラム製品であって、請求項１ないし１１のいずれか一項に記載の方法を実行する命令を含む、コンピュータ・プログラム製品。
【請求項２４】
ネットワークで送信されるメッセージを定義する、コンピューティング・デバイスによって使用されるデータ構造であって、
前記メッセージが要求メッセージまたは応答メッセージであることのインジケータと、
前記メッセージがフラグメント・サポート式キャッシュ管理ユニットによって処理されることを示すキーワード、および前記メッセージが処理される形を示す１つまたは複数のフラグメント・ヘッダ・ディレクティブを含むフラグメント・ヘッダと
を含むデータ構造。
【請求項２５】
応答メッセージ内のフラグメントをフラグメント・サポート式キャッシュ管理ユニットによって維持されるキャッシュから消去するのに起点サーバによって使用される依存識別子の組を示す、前記応答メッセージに挿入されるフラグメント・ヘッダ・ディレクティブ
をさらに含む、請求項２４に記載のデータ構造。
【請求項２６】
応答メッセージ内のフラグメントを一意に識別するキャッシュ識別子を形成するのに使用されるフラグメント・キャッシング規則の組を示す、前記応答メッセージに挿入されるフラグメント・ヘッダ・ディレクティブ
をさらに含む、請求項２４に記載のデータ構造。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、改良されたデータ処理システムに関し、具体的には改良されたネットワーク・リソース割振りを有するデータ処理システムに関する。さらに具体的には、本発明は、コンピュータ・ネットワーク内でのデータ・オブジェクトのキャッシングの方法およびシステムを提供する。
【背景技術】
【０００２】
インターネットを介して送信されるデータの量は、インターネットのユーザ数の増加の速度またはこれらのユーザのトランザクションの数の増加の速度を超えて増加し続けている。この増加の重要な要因が、ワールド・ワイド・ウェブ・サイト自体の性質の変化である。ワールド・ワイド・ウェブの初期段階では、ウェブ・ページが、主に、テキスト、イメージ、および他のサイトへのリンクなどの静的コンテンツからなっていた。ウェブ・サイトとのユーザの対話の範囲は、ＨＴＭＬページおよびその要素のダウンロードであった。コンテンツが、通常は誰がページを要求したかに無関係であったので、ウェブ・サーバが多数のユーザをサポートすることは、比較的単純であった。しかし、現在の傾向は、ウェブ・サイトのコンテンツおよび外見が、特定のユーザおよび／またはユーザ入力に応答して変化する対話型ウェブ・サイトに向かっている。これは、オンラインの製品選択および購入をサポートするｅ−ｃｏｍｍｅｒｃｅサイトについて特にそうである。そのようなサイトは、以前のウェブ・サイトから、より多くのダイナミック・コンテンツによって区別される。これのよく知られた例が、多数のインターネット・ビジネス・サイトで提供される「オンライン・カタログ」である。購入を行うためにサイトにログ・オンした各顧客が、カタログをブラウズし、数千個の製品に関する詳細情報を閲覧する機会を有する。外見上、ウェブ・サーバによって、買物客ごとに独自のウェブ・ページを維持し、更新しなければならない。インターネット・ユーザは、そのようなカスタマイズ可能な対話型ウェブ・サイトの便宜を享受し、顧客の期待は、疑いもなく、ウェブ・ページ内のダイナミック・コンテンツの将来の使用の起動力を提供する。
【０００３】
インターネット・ウェブ・ページでのダイナミック・コンテンツの使用の発展によって、ウェブ・サイトの運営者に関するロジスティック問題が生じる。現在のｅ−ｃｏｍｍｅｒｃｅサイトは、極端に高い「ブラウズ対購入比率」という特徴がある。ショッピング・サイトの場合に、通常の比率は、各常設のビジネス・レコードを更新するインタラクション（「トランザクション」）に対して、常設のビジネス・レコードを更新しないのは（「要求」または「照会」）６０インタラクションであり、製品のブラウズが要求の例であり、購入がトランザクションの例である。ダイナミック・コンテンツの普及の増加の影響は、トランザクションの数が予測可能で管理可能な速度で増加するが、要求の数が爆発的に増えることである。ダイナミック・コンテンツを含むウェブ・ページのユーザ対話性の高さに、トランザクションあたりの要求の数の多さの責任がある。これらのウェブ・ページ内のダイナミック・コンテンツは、通常は、ユーザがこれらのウェブ・ページの１つのブラウズを要求するたびに生成される。これによって、単一のセッション中に用意され、ユーザに伝えられなければならないかなりの量のコンテンツがもたらされる。
【０００４】
ユーザの期待のために、サイト・プロバイダは、要求に応答して迅速にダイナミック・ウェブ・コンテンツを提供せざるをえない。潜在的な顧客が、ウェブ・サイトが遅すぎると感じる場合に、その顧客は、そのサイトを訪問しなくなり、取引が失われる結果になる可能性がある。しかし、インターネット・トラフィックの量そのものが、ｅ−ｂｕｓｉｎｅｓｓに過度の財政的重荷を課す可能性がある。潜在的な顧客による情報の要求の増加をｅ−ｂｕｓｉｎｅｓｓが満足する最も単純な形は、より多くのコンピュータ、ストレージ、および帯域幅を追加することによって、サーバ側ハードウェアを増補することである。この解決策は、極端に高価で非効率的になる可能性がある。
【０００５】
最もコスト効率のよい手法は、キャッシングすなわち、性能を強化するためにディジタル・コンピュータで一般的に使用される技法である。コンピュータでデータ保管に使用される主メモリは、通常は、プロセッサよりはるかに低速である。データ・アクセス中により低速のメモリに対処するために、習慣的に、ウェイト・ステートが、プロセッサの通常の命令タイミングに追加される。プロセッサが、必ず主メモリからのデータにアクセスする必要がある場合には、その性能が、かなり低下する。キャッシングでは、主メモリ・アクセス・ボトルネックを克服するために、「キャッシュ」と称する少量だが極端に高速のメモリ・バッファを使用して、「データ局所性」と称する統計的特徴の利点を取り込む。データ局所性は、連続するデータ・アクセスにメモリの同一の一般的領域が含まれるという一般的傾向を指す。これを、時々、データ・アクセスの８０％がメモリの同一の２０％に対するものであるので、「８０／２０」の法則と称する。
【０００６】
下の例で、ウェブ関連ではないが、キャッシング全般の利益を示す。２つの大きい数字の配列をかけるコンピュータ・プログラムがあり、そのプログラムをより速く実行できるようにコンピュータを修正する方法を検討したいと仮定する。最も単純な修正は、プロセッサの速度を高めることであるが、これには限界がある。プログラムの各個々の乗算演算が、プロセッサがメモリから２つのオペランドをフェッチし、積を計算し、結果をメモリにライト・バックすることを必要とする。より高いプロセッサ速度では、計算に必要な時間がより少ないので、制限要因は、プロセッサがメモリと相互作用するのに必要な時間になる。より高速のメモリを使用することができるが、コンピュータのメモリのすべてに関する大量の極端に高速のメモリの使用は、非実用的であり、高価過ぎる。幸いなことに、行列乗算プログラムは、２つの入力配列のそれぞれの要素が、メモリのある範囲内の連続するアドレスを占めるので、高いデータ局所性を示す。したがって、大量の極端に高速のメモリを使用するのではなく、少量の極端に高速のメモリを、キャッシュとして使用することができる。プログラムの開始時に、主メモリからの入力配列が、キャッシュ・バッファに転送される。プログラムの実行中に、プロセッサが、キャッシュからオペランドをフェッチし、対応する結果をキャッシュにライト・バックする。データ・アクセスで高速キャッシュが使用されるので、プロセッサは、主メモリを使用する場合よりはるかに高速にこのプログラムを実行することができる。実際に、キャッシュを使用することによって、主メモリ全体をアップグレードした場合と同等に、はるかに低いコストで速度改善がもたらされる。キャッシュ・システムが、データ局所性の仮定が正当化される情況でのみ有益であり、プロセッサが頻繁にデータのためにキャッシュの外にアクセスしなければならない場合に、キャッシュの速度の長所が失われることに留意されたい。
【０００７】
データ・キャッシュの使用に関連するもう１つの問題が、「キャッシュ・コヒーレンシ」である。上で説明したように、データは、通常は、より高速のアクセスを可能にするためにキャッシュにコピーされる。キャッシュ内の各データは、主メモリ内の元のバージョンと同一のコピーである。コンピュータ内のあるアプリケーションが、別のアプリケーションがキャッシュ内のコピーにアクセスする間に主メモリ内の変数にアクセスする場合に、問題が発生する可能性がある。変数のいずれかのバージョンが、他方と独立に変更される場合に、キャッシュが、コヒーレンシを失い、潜在的に有害な結果が生じる。たとえば、変数が、クリティカル・オペレーティング・システム・データへのポインタである場合に、致命的エラーが発生する可能性がある。これを避けるために、キャッシュの状態を監視しなければならない。キャッシュ内のデータが修正される時に、主メモリ内の「古い」コピーを、更新されるまで一時的に無効化する。したがって、キャッシュを装備したシステムの重要な態様は、キャッシュ・コヒーレンシを維持する処理である。
【０００８】
これらの周知の問題および利益に鑑みて、キャッシュは、いわゆるコンテンツ・デリバリ・ネットワーク（Content Delivery Network、ＣＤＮ）を含む、インターネット内またはプライベート・ネットワーク内のさまざまな位置にあるデータ処理システム内で実施されてきた。ウェブ・トラフィックは、キャッシングによく適することがわかっている。ｅ−ｃｏｍｍｅｒｃｅインターネット・トラフィックの大部分は、ユーザからサーバではなくサーバからユーザに送信されるデータからなる。ほとんどの場合に、ユーザは、ウェブ・サイトに情報を要求し、ユーザは、比較的まれにウェブ・サイトに情報を送信する。たとえば、ユーザは、頻繁に、ウェブ・ページを要求し、比較的まれに、ウェブ・サイトに保管される、個人情報またはトランザクション情報をサブミットする。したがって、データ・トラフィックの大部分は、よいキャッシュ・コヒーレンシ特性を示す。さらに、データ・トラフィックの大部分は、よいデータ局所性特性を示す。というのは、ユーザが、異なるウェブ・サイトに移動する前に、しばらくの間、単一のウェブ・サイトのコンテンツをブラウズし、再度ブラウズする傾向があるからである。さらに、多くのユーザは、同一の情報を要求する傾向があり、これをデータベースから繰り返して検索するよりも、ある点で情報をキャッシングすることがより効果的である。さらに、ほとんどのウェブ・アプリケーションは、データがどれほど最新であるかに関するある程度の遊びを許容することができる。たとえば、製品価格が変更される時に、その変更が有効になるまでに数分の遅延を有することを許容可能とすることができ、すなわち、キャッシュ・コヒーレンシの完全性を緩和することができ、キャッシングがさらに貴重になる。
【０００９】
ウェブ・コンテンツのキャッシングの利益を、以下の説明であまねく示すことができる。クライアント・ブラウザからの各要求は、ファイヤウォール、ルータ、ならびに、中間サーバ、プレゼンテーション・サーバ（たとえば、静的コンテンツの読取、ダイナミック・ページの構築）、アプリケーション・サーバ（たとえば、ページのデータの検索、更新の実行）、およびバックエンド・サーバ（たとえば、データベース、サービス、およびレガシ・アプリケーション）などのさまざまなタイプのサーバなど、インターネット全体に配置された複数のデータ処理システムを通って流れることができる。これらの処理ステージのそれぞれが、関連するコストおよび性能の考慮事項を有する。
【００１０】
キャッシングが全く行われない場合に、すべての要求が、プレゼンテーション・サーバを通って流れ、このプレゼンテーション・サーバによって、ダイナミック・コンテンツを必要としない要求を満足することができる。残念ながら、多くの要求によって、ダイナミック・コンテンツ・ページのデータの更新または入手のために、アプリケーション・サーバおよびバックエンド・サーバにも処理が要求される。
【００１１】
しかし、要求は、満足されるのに必要なだけ伝搬する必要があり、特にアプリケーション・プロバイダのサイト内でのキャッシュの使用によって、性能を高めることができる。たとえば、中間サーバでのキャッシングによって、要求の大多数を満足することができ、その結果、少数の要求だけが、プレゼンテーション・サーバまで伝搬される。プレゼンテーション・サーバでのキャッシングによって、プレゼンテーション・サーバに達する要求の一部を処理することができ、その結果、ごく少数の要求だけが、アプリケーション・サーバに伝搬される。アプリケーション・サーバは、通常はトランザクショナルなので、アプリケーション・サーバ内では、制限されたキャッシングを達成することができる。しかし、総合的に、アプリケーション・プロバイダのサイト内でのキャッシュの適度な使用によって、かなりのコスト節約を達成することができる。
【００１２】
キャッシングの利益があれば、上で述べたサーバおよび他のハードウェアへの大規模な投資なしで、キャッシング技法を使用することによってダイナミック・ウェブ・コンテンツを含むウェブ・サイトの応答性を改善することができる。しかし、キャッシングの適当性に関する重要な考慮事項が、ウェブ・コンテンツが変更される頻度である。一般に、キャッシュの実装は、アクセス・レートが高くなるにつれ、また、更新レートが低くなるにつれて、適するようになる。具体的には、ウェブ・コンテンツのキャッシングは、ユーザがウェブ・サイトから静的コンテンツを頻繁に検索し、ウェブ・サイトで保管されるデータを送信する頻度が低い時に、適するようになる。しかし、ウェブ・サイトに、かなりの量のダイナミック・コンテンツが含まれる場合には、そのウェブ・サイトは、本来、そのコンテンツを頻繁に変更するように構成される。この場合に、そのウェブ・サイト内のキャッシュの更新レートが、非常に高くなり、これによって、ウェブ・サイトのコンテンツをキャッシングする試みの長所が帳消しになる。
【００１３】
会社内のダイナミック・コンテンツを効果的にキャッシングするさまざまな解決策が、提案されるか、実施されるか、その両方を行われてきた。ウェブ・アプリケーション・サーバ内でウェブ・コンテンツをキャッシングするこれらの技法によって、スループットおよび応答時間に関する性能が大幅に改善された。
【００１４】
ｅ−ｂｕｓｉｎｅｓｓウェブ・サイト内でのダイナミック・コンテンツのキャッシングの大きい利益を得た後に、ネットワーク自体全体での連携キャッシング、いわゆる「分散キャッシング」を実施することが有利になるはずである。というのは、ユーザの近くでのコンテンツのキャッシングによって、応答時間または待ち時間に関する遥かに大きい利益を得ることができるからである。しかし、周知のキャッシングの問題を、分散キャッシング解決策について検討しなければならない。キャッシュの無差別の配置および実施によって、コスト効率が悪い形で性能が改善される場合がある。キャッシュの有効性を決定する重要な問題に、キャッシュ・サイズ、キャッシュ・ヒット・パス長、キャッシュ・コンテンツを維持するのに必要な作業量、およびデータ要求元とデータの位置の間の距離が含まれる。
【００１５】
キャッシュ・サイズに関して、メモリおよびディスク空間は、サイズが増え続けているが、その限度を考慮する必要がなくなるほどに大きくなることは、絶対にない。言い換えると、分散キャッシング技術では、大量のメモリおよびディスク空間がキャッシュに使用可能であると仮定してはならず、小さいキャッシュの必要が、一般に、大きいキャッシュの必要より好ましい。さらに、メモリおよびディスクの帯域幅は、そのサイズの増加より低い速度で改善されており、ますます大量になるデータをキャッシングする試みは、最終的に帯域幅の考慮事項によって制限される。
【００１６】
キャッシュ・ヒット・パス長に関して、分散キャッシング解決策に、簡単に展開できるが、キャッシュ・ヒットのスループットが非常に高くなるように最小限の処理でキャッシュ・ヒットを判定できる軽量ランタイム・アプリケーションが含まれることが好ましい。分散キャッシング・アプリケーションの所望の形態を、エンドユーザに近いデータを「キャッシング」する分散アプリケーションの他の形と混同してはならない。言い換えると、インターネット全体でのアプリケーションの諸部分およびそれに関連するデータの分配の多数の形の１つから利益を得る他の形のアプリケーションがある。たとえば、アプリケーションおよびそれに関連するデータベース全体を、異なる位置で複製することができ、展開する企業が、必要に応じて、データベースを同期化し、アプリケーションを維持することができる。他の場合に、アプリケーションおよびそれに関連するデータの読取専用表示部分を、プラグイン、Ｊａｖａ（Ｒ）Ｓｃｒｉｐｔ（商標）、または類似する機構を使用してクライアントベース・ブラウザに分散すると同時に、ビジネス・ロジックを保護されたホスト・サイトで保つことができる。
【００１７】
キャッシュ・コンテンツの維持に必要な作業量に関して、サービスする企業内でのキャッシングによって、要求ごとに行われる作業が減るので、スループットまたはコストのいずれかすなわち、毎分処理される要求の数または必要なサーバ・ハードウェアの量が改善される。サービスする企業内で、キャッシュは、企業の入口点の近くに配置されることが好ましい。というのは、企業内のシステムによる処理の量が減り、これによって改善が高まるからである。たとえば、ディスパッチャの近くでのキャッシングは、アプリケーション・サーバ内のキャッシングよりはるかに有効になる可能性がある。サービスする企業内でのキャッシングによって、待ち時間が多少改善されるが、サービスする企業内での待ち時間は、通常はインターネットでの待ち時間よりはるかに短いので、この改善は通常は副次的である。サービスする企業の外部での堅牢な分散キャッシング技法に関する考慮事項は、これおよび他の問題と絡み合っている。
【００１８】
データ要求元とデータの位置の間の距離に関して、インターネットでのユーザに可視の待ち時間は、ユーザとコンテンツの間の距離に左右される。この距離は、物理的距離ではなく、ルーティング・ホップの数によって測定される。コンテンツが、インターネット・サービス・プロバイダ（ＩＳＰ）などのインターネットの「境界」でキャッシングされる時に、ユーザに可視の待ち時間が、かなり減る。マルチメディア・ファイルなどの大きいコンテンツについて、帯域幅要件も、かなり減らすことができる。堅牢な分散キャッシング解決策では、ユーザの近くでデータをキャッシングすることを試みなければならない。
【００１９】
ユーザは、地理的に分散しているので、ユーザの近くでのコンテンツのキャッシングは、コンテンツが、インターネット全体のＩＳＰおよびエクスチェンジ・ポイント（exchange point）の複数のキャッシュで複製されることを意味する。一般に、これによって、キャッシング機構がコンテンツのセキュリティおよびコンテンツを更新する形すなわちキャッシュ・コヒーレンシに対して有する制御が減る可能性がある。サービスする企業内のキャッシング機構が、表向きは単一の組織の制御の下にあるという事実に対して、サービスする企業内のコヒーレントなキャッシュを比較的簡単に維持することができる。しかし、サービスする企業の内部と外部の両方でキャッシュを維持することによって、キャッシュ・コヒーレンシを維持するのに必要な問題および作業量がかなり増える。公衆インターネット以外のより制御されたネットワーク環境内でキャッシュ空間が貸し出され、維持されるコンテンツ配布ベンダ、たとえばＣＤＮが使用される場合に、セキュリティおよびコヒーレンシの考慮事項を最小にすることができるが、そのような解決策によって、公衆インターネットを介するオープンな標準規格の使用を介して得られる長所の一部が事実上帳消しにされる。
【００２０】
分散キャッシング技法が、ある程度企業境界に関して実施可能であり、かつ、整合された形でインターネット全体で実施可能であることが好ましい。さらに、キャッシュは、たとえばクライアント・ブラウザ内などのエンド・ユーザの近く、サービスする企業のディスパッチャの近く、ウェブ・アプリケーション・サーバ内、またはこの間のどこかなど、必要と判定される可能性があるさまざまな重要な位置で展開可能でなければならない。さらに、この技法は、異なる組織がローカル・システム要件に従って分散キャッシング仕様の異なる実施形態を構築できるように、仕様を厳守しなければならない。
【００２１】
潜在的に堅牢な分散キャッシング解決策に関する問題は、フラグメント（fragment）としてウェブ・コンテンツをオーサリングしパブリッシュする傾向によって複雑化している。コンテンツの一部が、フラグメントに配置され、ウェブ・ページまたは他の文書などのより大きいコンテンツ・エンティティが、フラグメントから構成されるが、コンテンツ・エンティティを、単一のフラグメントから構成することもできる。フラグメントは、別々に保管され、必要な時により大きいコンテンツ・エンティティに組み立てられる。
【００２２】
これらのランタイムの利益は、フラグメントの維持および使用の他の態様での複雑化によって相殺される。フラグメントに、異なる寿命を割り当てることができ、これによって、一貫性のある無効化機構が必要になる。さらに、フラグメントを使用して、コンテンツの静的部分をコンテンツのダイナミック部分から分離でき、その結果、静的コンテンツを効果的にキャッシングできるようになるが、上で述べたように、ダイナミック・コンテンツのキャッシング関連する問題に直面する。最も重要な事に、フラグメント組立は、企業境界の内部の位置に制限されてきた。
【非特許文献１】「HTML 4.01 Specification」、W3CRecommendation、1999年12月24日
【非特許文献２】「Hypertext Transport Protocol --HTTP/1.1」、Request for Comments 2616 (RFC 2616)
【非特許文献３】「HTTP State Management Mechanism」、RFC2109、Internet Engineering Task Force、1997年2月
【発明の開示】
【発明が解決しようとする課題】
【００２３】
したがって、フラグメントおよび他のオブジェクトのキャッシングをサポートする堅牢な分散キャッシング技法を有することが有利である。さらに、必要と思われるときに企業境界により多くまたは少ない程度で、ネットワーク全体のキャッシュ・サイトにフラグメント組立を共存させ、これによって、サービスする企業の処理負荷を減らし、所望される時に分散コンピューティングの追加の利益を達成することが、特に有利である。さらに、フラグメントをインターネット全体を通じて一意に識別できる、すなわち、分散キャッシュがコヒーレントに維持されるようにする、一貫性のあるネーミング技法を有することが有利である。
【００２４】
堅牢な分散キャッシング解決策のさらなる考慮事項として、潜在的な解決策では、既存のプログラミング・モデルの問題を考慮しなければならない。たとえば、既存のウェブ・アプリケーション・サーバのプログラミング・モデルを、分散キャッシング技法と共に動作する新しいプログラミング・モデルに置換することを必要とする分散キャッシング技法を提案することができる。分散キャッシング技法の実装が、さまざまなプログラミング・モデルに対処し、これによって、プログラミング・モデルの偏重を避けることが好ましい。
【００２５】
分散キャッシング技法の実施形態によって、キャッシュ位置に最小限に関係するインターネット全体を通じて標準的な形での軽量プロセスによって維持可能な減少したフラグメント・キャッシュ・サイズがもたらされることが有利である。さらに、分散キャッシング技法が既存のプログラミング・モデルおよびインターネット標準規格との互換性を有し、分散キャッシング技法の実装が、分散キャッシング技法を実施しない他のシステムとの相互運用性を有することが特に有利である。
【課題を解決するための手段】
【００２６】
本発明の第１の態様によれば、ネットワーク内のデータ処理システムでオブジェクトを処理する方法であって、コンピューティング・デバイスで第１メッセージを受信するステップと、前記第１メッセージのメッセージ・ヘッダが、前記第１メッセージがフラグメントに関連することを示すことを判定するステップとを含む方法が提供される。
【００２７】
本発明の第２の態様によれば、ネットワーク内のデータ処理システムでオブジェクトを処理する装置であって、コンピューティング・デバイスで第１メッセージを受信する手段と、前記第１メッセージのメッセージ・ヘッダが、前記第１メッセージがフラグメントに関連することを示すことを判定する手段とを含む装置が提供される。
【００２８】
本発明の第３の態様によれば、オブジェクトを処理する、ネットワーク内のデータ処理システムで使用される、コンピュータ可読媒体内のコンピュータ・プログラム製品であって、コンピューティング・デバイスで第１メッセージを受信する命令と、前記第１メッセージのメッセージ・ヘッダが、前記第１メッセージがフラグメントに関連することを示すことを判定する命令とを含むコンピュータ・プログラム製品が提供される。
【００２９】
第１メッセージのメッセージ・ヘッダが、第１メッセージのメッセージ本体部分がフラグメントであることを示すことも判定することが好ましい。
【００３０】
第１メッセージからのフラグメントが、コンピューティング・デバイス内のキャッシュ管理ユニットによって管理されるキャッシュに保管され、キャッシュ管理ユニットが、コンピューティング・デバイスがネットワーク全体に配置されたクライアント、サーバ、またはハブのどれとして働く場合でも、フラグメント・キャッシング動作をサポートして同等に機能することが好ましい。
【００３１】
第１メッセージのメッセージ・ヘッダが、フラグメントがキャッシュ可能であることを示すことも判定することが好ましい。この場合に、任意選択として、第１メッセージが、フラグメントがフラグメント非サポート式キャッシュ管理ユニット（non-fragment-supporting cache management unit）にキャッシュ不能であることの表示と、フラグメントがフラグメント・サポート式キャッシュ管理ユニット（fragment-supportingcache management unit）にキャッシュ可能であることの表示を有する。たとえば、第１メッセージが、フラグメント非サポート式キャッシュ管理ユニットに関するｎｏ−ｃａｃｈｅディレクティブと、フラグメント・サポート式キャッシュ管理ユニットに関するフラグメントをキャッシングするディレクティブを伴うＨＴＴＰ  Ｃａｃｈｅ−Ｃｏｎｔｒｏｌヘッダを有する。
【００３２】
第２メッセージが、コンピューティング・デバイスで受信され、第２メッセージに、フラグメントに関する要求が含まれる場合に、キャッシュが検索され、フラグメントがキャッシュから取り出されることが好ましい。このフラグメントは、次いで宛先アドレスに第２メッセージを送信することなく、第２メッセージの発信元に第３メッセージで送信される。
【００３３】
任意選択として、第２メッセージに、第３メッセージを返す前のコンピューティング・デバイスでのページ組立動作が不要であることを示す情報が含まれる。
【００３４】
任意選択として、第２メッセージは、フラグメント・サポート式キャッシュ管理ユニットを有する第２コンピューティング・デバイスによって第３メッセージが受信されることを示すディレクティブを有するメッセージ・ヘッダを有する。
【００３５】
ページ組立動作が、第３メッセージを送信する前にコンピューティング・デバイスで実行されることが好ましい。
【００３６】
ページ組立動作が、コンピューティング・デバイスで実行されて、組み立てられたフラグメントが形成されることが好ましい。たとえば、フラグメントが、次レベル・フラグメントへのリンクを含むトップレベル・フラグメントであるかどうかが判定される。次に、フラグメントが、次レベル・フラグメントへのリンクを含むトップレベル・フラグメントであることの判定に応答して、次レベル・フラグメントが、取り出される。最後に、トップレベル・フラグメントおよび次レベル・フラグメントが、組み立てられたフラグメントに組み合わされる。
【００３７】
任意選択として、次レベル・フラグメントのコンテンツが、トップレベル・フラグメントのコンテンツに組み込まれる。さらに、トップレベル・フラグメントのプロパティ値および次レベル・フラグメントのプロパティ値から、組み立てられたフラグメントについてプロパティ値を生成することができる。組み立てられたフラグメントのヘッダ値またはディレクティブも、トップレベル・フラグメントのヘッダ値またはディレクティブおよび次レベル・フラグメントのヘッダ値またはディレクティブから計算することができる。
【００３８】
組み立てられたフラグメントを含む第４メッセージが生成され、第４メッセージが、ＨＴＴＰ（ハイパーテキスト転送プロトコル）応答メッセージであることが好ましい。
【００３９】
トップレベル・フラグメントおよび次レベルフラグメントの最短満了時刻が判定され、第４メッセージの「Ｅｘｐｉｒｅｓ（満了）」ヘッダに最短満了時刻がセットされることが好ましい。
【００４０】
代替案では、トップレベル・フラグメントおよび次レベルフラグメントの最小の最大経過時間が判定され、第４メッセージの「Ｃａｃｈｅ−Ｃｏｎｔｒｏｌ：ｍａｘ−ａｇｅ（キャッシュ制御：最大年齢）」ディレクティブに、最小の最大経過時間がセットされる。
【００４１】
任意選択として、トップレベル・フラグメントおよび次レベルフラグメントのコンテンツ長値の合計が、計算され、第４メッセージの「Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ（コンテンツ長）」ヘッダに、コンテンツ長値の合計がセットされる。
【００４２】
任意選択として、トップレベル・フラグメントおよび次レベルフラグメントの最終修正時刻が判定され、第４メッセージの「Ｌａｓｔ−Ｍｏｄｉｆｉｅｄ（最終修正）」ヘッダに、最終修正時刻がセットされる。
【００４３】
任意選択として、依存識別子の組が、第１メッセージから取り出され、依存識別子は、フラグメントを編成したサーバによって生成され、依存識別子の組は、フラグメントのソース識別子に関連して保管される。この場合に、任意選択として、無効化要求メッセージを取り出すことができ、このメッセージから、依存識別子が取り出される。これによって、依存識別子に関連するフラグメントの組を判定できるようになり、その結果、判定された組フラグメントをキャッシュから消去することができる。
【００４４】
フラグメント・キャッシング規則の組が、第１メッセージから判定され、フラグメントのキャッシュ識別子が、フラグメント・キャッシング規則に従って生成されることが好ましい。この場合に、たとえば、キャッシュ識別子を使用して、フラグメントを一意に識別することができる。さらに、フラグメントの生成されたキャッシュ識別子を使用して、保管動作を実行することができる。
【００４５】
任意選択として、少なくとも、フラグメントに関連するＵＲＩ（UniformResource Identifier）のパス部分が、基本キャッシュ識別子を形成するために入手され、フラグメント・キャッシング規則が基本キャッシュ識別子に適用されて、フラグメントのキャッシュ識別子が形成され、フラグメント・キャッシング規則に、基本キャッシュ識別子に付加される名前／値対を入手するのに使用される照会パラメータ名またはクッキー名あるいはその両方の組が含まれる。
【００４６】
本発明の第４の態様によれば、ネットワーク内のデータ処理システムでオブジェクトを処理する方法であって、サーバで要求メッセージを受信するステップであって、前記要求メッセージが、フラグメントに関するソース識別子を含む、前記受信するステップと、前記フラグメントを含む応答メッセージを生成するステップと、前記要求メッセージがフラグメントに関連することを示すメッセージ・ヘッダを前記応答メッセージに挿入するステップとを含む方法が提供される。
【００４７】
本発明の第５の態様によれば、ネットワーク内のデータ処理システムでオブジェクトを処理する装置であって、サーバで要求メッセージを受信する手段であって、前記要求メッセージが、フラグメントのソース識別子を含む、前記手段と、前記フラグメントを含む応答メッセージを生成する手段と、前記要求メッセージがフラグメントに関連することを示すメッセージ・ヘッダを前記応答メッセージに挿入する手段とを含む装置が提供される。
【００４８】
本発明の第６の態様によれば、オブジェクトを処理するためにネットワーク内のデータ処理システムで使用されるコンピュータ可読媒体内のコンピュータ・プログラム製品であって、サーバで要求メッセージを受信する命令であって、前記要求メッセージが、フラグメントのソース識別子を含む、前記命令と、前記フラグメントを含む応答メッセージを生成する命令と、前記第１メッセージがフラグメントに関連することを示すメッセージ・ヘッダを前記応答メッセージに挿入する命令とを含むコンピュータ・プログラム製品が提供される。
【００４９】
応答メッセージのメッセージ本体部分がフラグメントであることを示すメッセージ・ヘッダが、応答メッセージに挿入され、メッセージヘッダが、応答メッセージのメッセージ本体部分がフラグメントであることを示すことが好ましい。
【００５０】
フラグメントがキャッシュ可能であることを示すメッセージ・ヘッダが、応答メッセージに挿入されることが好ましい。
【００５１】
フラグメントが、フラグメント非サポート式キャッシュ管理ユニットにキャッシュ不能であることを示すメッセージ・ヘッダと、フラグメントが、フラグメント・サポート式キャッシュ管理ユニットにキャッシュ可能であることの表示が、応答メッセージに挿入されることが好ましい。
【００５２】
本発明の第７の態様によれば、ネットワークで送信されるメッセージを定義する際にコンピューティング・デバイスで使用されるデータ構造であって、メッセージが要求メッセージまたは応答メッセージであることのインジケータと、メッセージが、フラグメント・サポート式キャッシュ管理ユニットによって処理されるものであることを示すキーワードおよびメッセージが処理される形を示す１つまたは複数のフラグメント・ヘッダ・ディレクティブを含むフラグメント・ヘッダとを含むデータ構造が提供される。
【００５３】
フラグメント・サポート式キャッシュ管理ユニットが、コンピューティング・デバイス内に配置され、コンピューティング・デバイスがネットワーク全体に配置されたクライアント、サーバ、またはハブのどれとして働くかに無関係に、フラグメント・キャッシング動作をサポートして同等に動作することが好ましい。
【００５４】
請求項のデータ構造が、要求メッセージを処理したコンピューティング・デバイスがフラグメント・サポート式キャッシュ管理ユニットを有することを示す、要求メッセージに含めるためのフラグメント・ヘッダ・ディレクティブも有することが好ましい。
【００５５】
データ構造が、フラグメント・サポート式キャッシュ管理ユニットによって維持されるキャッシュから応答メッセージ内のフラグメントを消去するために起点サーバによって使用される依存識別子の組を示す、応答メッセージに含めるためのフラグメント・ヘッダ・ディレクティブを有することが好ましい。
【００５６】
データ構造が、応答メッセージ内のフラグメントを一意に識別するキャッシュ識別子を構成するのに使用されるフラグメント・キャッシング規則の組を示す、応答メッセージに含めるためのフラグメント・ヘッダ・ディレクティブを有することが好ましい。
【００５７】
任意選択として、要求メッセージまたは応答メッセージは、ＨＴＴＰ（ハイパーテキスト転送プロトコル）要求メッセージまたはＨＴＴＰ応答メッセージである。
【００５８】
本発明の第８の態様によれば、コンテンツ・オブジェクトを定義する際にコンピューティング・デバイスによって使用されるデータ構造であって、マークアップ言語要素の区切り文字の組と、マークアップ言語要素がフラグメントへのリンクであることを示すキーワードと、フラグメントのソース識別子であって、ソース識別子が、フラグメントを取り出すためにフラグメント・サポート式キャッシュ管理ユニットによって使用される、ソース識別子とを含むデータ構造が提供される。
【００５９】
フラグメント・サポート式キャッシュ管理ユニットが、コンピューティング・デバイス内に配置され、コンピューティング・デバイスがネットワーク全体に配置されるクライアント、サーバ、またはハブのどれとして働くかに無関係に、フラグメント・キャッシング動作をサポートして同等に動作することが好ましい。
【００６０】
データ構造が、フラグメントの代替ソース識別子を有し、フラグメント・サポート式キャッシュ管理ユニットが、代替ソース識別子を使用してフラグメントを取り出せることが好ましい。
【００６１】
データ構造が、ソース識別子に付加される照会パラメータの組を有することが好ましい。
【００６２】
マークアップ言語が、ＳＧＭＬ（標準汎用印刷指定言語）であることが好ましい。マークアップ言語要素が、ＨＴＭＬ（ハイパーテキスト・マークアップ言語）との互換性を有することが好ましい。
【００６３】
フラグメント・キャッシングの方法、システム、装置、およびコンピュータ・プログラム製品が、提示される。メッセージが、キャッシュ管理ユニットを含むコンピューティング・デバイスで受信された後に、そのメッセージのメッセージ本体のフラグメントが、キャッシングされる。キャッシュ管理ユニットでのフラグメントに関する後続の要求が、キャッシュ・ヒットをもたらす。キャッシュ管理ユニットは、コンピューティング・デバイスがネットワーク全体に配置されるクライアント、サーバ、またはハブのどれとして働くかに無関係にフラグメント・キャッシング動作をサポートして同等に動作する。言い換えると、このフラグメント・キャッシング技法は、ネットワーク全体を通じて一様である。
【００６４】
ＦＲＡＧＭＥＮＴヘッダは、ＨＴＴＰなどのネットワーク・プロトコル内で使用するために定義され、このヘッダによって、メタデータが、フラグメントの処理およびキャッシングに関連するさまざまな目的のためにフラグメントに関連付けられる。キャッシュＩＤ規則に、起点サーバからのフラグメントが付随し、キャッシュＩＤ規則によって、ダイナミック・コンテンツを起点サーバから離れてキャッシングできるように、フラグメントの一意のキャッシュＩＤを形成する方法が記述される。キャッシュＩＤは、フラグメントのＵＲＩ（Uniform Resource Identifier）に基づくものとすることができるが、キャッシュＩＤを、照会パラメータまたはクッキーあるいはその両方に基づくものとすることもできる。キャッシュＩＤまたはフラグメントのＵＲＩと異なるものとすることができる依存ＩＤを、フラグメントに関連付けることができ、その結果、サーバが、フラグメントをキャッシュから消去する無効化動作を開始できるようになる。ＦＲＡＧＭＥＮＴＬＩＮＫタグが、ページ組立またはページ・レンダリング中に挿入されるインクルードされるフラグメントのページ内での位置を指定するのに使用される。
【００６５】
本発明を、添付図面に示された本発明の好ましい実施形態に関して、例としてのみ説明する。
【発明を実施するための最良の形態】
【００６６】
本発明は、分散フラグメント・キャッシング技法を対象とする。一般に、本発明の好ましい実施形態を含むかこれに関連することができる装置には、広範囲のデータ処理技術が含まれる。したがって、本発明の好ましい実施形態を詳細に説明する前に、背景として、分散データ処理システム内のハードウェア構成要素およびソフトウェア構成要素の通常の編成を説明する。
【００６７】
図面に関して、図１に、本発明の好ましい実施形態のいくつかの態様をそれぞれが実施できるデータ処理システムの通常のネットワークを示す。分散データ処理システム１００に、ネットワーク１０１が含まれ、このネットワーク１０１は、分散データ処理システム１００内で一緒に接続されるさまざまな装置およびコンピュータの間の通信リンクを提供するのに使用することができる媒体である。ネットワーク１０１には、ワイヤまたは光ファイバ・ケーブルなどの永久的接続、あるいは電話通信または無線通信を介して行われる一時的接続を含めることができる。図示の例では、サーバ１０２およびサーバ１０３が、記憶装置１０４と共にネットワーク１０１に接続される。さらに、クライアント１０５から１０７も、ネットワーク１０１に接続される。クライアント１０５から１０７およびサーバ１０２から１０３は、メインフレーム、パーソナル・コンピュータ、携帯情報端末（ＰＤＡ）などのさまざまなコンピューティング・デバイスによって表すことができる。分散データ処理システム１００に、図示されていない、追加のサーバ、クライアント、ルータ、他の装置、およびピアツーピア・アーキテクチャを含めることができる。図１に示された分散データ処理システムが、さまざまなピアツーピア・サブネットおよびピアツーピア・サービスを完全にサポートできることが企図されていることに留意されたい。
【００６８】
図示の例では、分散データ処理システム１００に、インターネットを含めることができ、ここで、ネットワーク１０１は、Lightweight Directory Access Protocol（ＬＤＡＰ）、伝送制御プロトコル／インターネット・プロトコル（ＴＣＰ／ＩＰ）、ハイパーテキスト転送プロトコル（ＨＴＴＰ）、WirelessApplication Protocol（ＷＡＰ）などのさまざまなプロトコルを使用して互いに通信するネットワークおよびゲートウェイの全世界の集合を表す。もちろん、分散データ処理システム１００に、たとえばイントラネット、ローカル・エリア・ネットワーク（ＬＡＮ）、無線ＬＡＮ、または広域ネットワーク（ＷＡＮ）などの複数の異なるタイプのネットワークを含めることもできる。たとえば、、サーバ１０２によって、クライアント１０９および無線通信リンクを組み込まれたネットワーク１１０が直接にサポートされる。ネットワーク対応の電話機１１１が、無線リンク１１２を介してネットワーク１１０に接続され、ＰＤＡ１１３が、無線リンク１１４を介してネットワーク１１０に接続される。電話機１１１およびＰＤＡ１１３によって、Ｂｌｕｅｔｏｏｔｈ（商標）無線技術などの適当な技術を使用して、それら自体の間で無線リンク１１５を介して直接にデータを転送して、いわゆるパーソナル・エリア・ネットワーク（ＰＡＮ）またはパーソナル・アドホック・ネットワークを作成することもできる。類似する形で、ＰＤＡ１１３によって、無線通信リンク１１６を介してＰＤＡ１０７にデータを転送することができる。
【００６９】
本発明の好ましい実施形態は、さまざまなハードウェア・プラットフォームで実施することができ、図１は、異機種コンピューティング環境の例であることを意図されたものであって、本発明に関するアーキテクチャ制限として意図されたものではない。後続の例で、サーバタイプの機能性と比較してクライアント・タイプの機能性に具体的に言及することに留意されたい。しかし、周知のように、ハブまたは、ピアツーピア・ネットワーク内のコンピューティング・デバイスすなわちピアなどの一部のコンピューティング・デバイスは、クライアント・タイプの機能性とサーバ・タイプの機能性の両方を示す。本発明の好ましい実施形態は、必要に応じて、クライアント、サーバ、ピア、またはハブで実施することができる。
【００７０】
図２に関して、図に、本発明の好ましい実施形態を実施できる、図１に示されたものなどのデータ処理システムの通常のコンピュータ・アーキテクチャが示されている。データ処理システム１２０に、内部システム・バス１２３に接続された１つまたは複数の中央処理装置（ＣＰＵ）１２２が含まれ、内部システム・バス１２３によって、ランダム・アクセス・メモリ（ＲＡＭ）１２４、読取専用メモリ１２６、および入出力アダプタ１２８が相互接続され、入出力アダプタ１２８によって、プリンタ１３０、ディスク装置１３２、またはオーディオ出力システムなどの図示されていない他の装置がサポートされる。システム・バス１２３によって、通信アダプタ１３４も接続され、通信アダプタ１３４によって、通信リンク１３６へのアクセスが提供される。ユーザ・インターフェース・アダプタ１４８によって、キーボード１４０、マウス１４２、あるいはタッチ・スクリーン、スタイラス、またはマイクロフォンなどの図示されない他の装置が接続される。ディスプレイ・アダプタ１４４によって、システム・バス１２３がディスプレイ１４６に接続される。
【００７１】
当業者は、図２のハードウェアを、システム実施形態に応じて変更できることを諒解するであろう。たとえば、このシステムは、Ｉｎｔｅｌ（登録商標）Ｐｅｎｔｉｕｍ（Ｒ）（登録商標）ベースのプロセッサ、ディジタル信号プロセッサなどの１つまたは複数のプロセッサと、１つまたは複数のタイプの揮発性メモリおよび不揮発性メモリを有することができる。他の周辺装置を、図２に示されたハードウェアに加えてまたはこれの代わりに使用することができる。言い換えると、当業者は、ウェブ対応またはネットワーク対応の電話機および機能満載のデスクトップ・ワークステーションに、ある類似する構成要素またはアーキテクチャを見つけることが期待される。図示の例は、本発明の好ましい実施形態に関するアーキテクチャ的制限を暗示することを意図されたものではない。
【００７２】
さまざまなハードウェア・プラットフォームで実施できることのほかに、本発明の好ましい実施形態は、さまざまなソフトウェア環境で実施することができる。通常のオペレーティング・システムを使用して、各データ処理システム内のプログラム実行を制御することができる。たとえば、ある装置によって、Ｌｉｎｕｘ（登録商標）オペレーティング・システムを動作させることができ、別の装置に、単純なＪａｖａ（Ｒ）（登録商標）ランタイム環境を含めることができる。代表的なコンピュータ・プラットフォームに、ブラウザを含めることができ、ブラウザは、グラフィック・ファイル、ワード・プロセッシング・ファイル、Extensible Markup Language（ＸＭＬ）、ハイパーテキスト・マークアップ言語（ＨＴＭＬ）、HandheldDevice Markup Language（ＨＤＭＬ）、Wireless Markup Language（ＷＭＬ）などのさまざまなフォーマットおよびエンコーディングのファイル、文書、オブジェクト、または他のデータ項目にアクセスするための周知のソフトウェア・アプリケーションである。これらのオブジェクトは、通常は、UniformResource Identifier（ＵＲＩ）を使用してアドレッシングされる。ＵＲＩの組に、Uniform Resource Locator（ＵＲＬ）およびUniformResource Name（ＵＲＮ）が含まれる。
【００７３】
図３に関して、図に、キャッシュを分散データ処理システム全体で実施できる、図１に示されたものなどの通常の分散データ処理システムが示されている。分散データ処理システム１５０に、コンテンツの要求を生成する要求元エンティティ１５２が含まれる。要求元エンティティ１５２は、さまざまな個人顧客または機関顧客にサービスするＩＳＰあるいは要求されるコンテンツをさまざまな目的に使用する企業とすることができる。データ、たとえば要求が、要求元エンティティ（使用するエンティティ）から、応答するエンティティ（サービスするエンティティ、たとえば起点サーバ）に向かって移動する時に、そのデータを、「上流に」移動すると言う。データ、たとえば応答が、応答するエンティティから受信するエンティティに向かって移動する時に、そのデータを、「下流に」移動すると言う。
【００７４】
クライアント・ブラウザ１５４からの要求が、ディスパッチャ１５６によってルーティングされ、ディスパッチャ１５６によって、インターネットを介してインターネット・エクスチェンジ・ポイント１６０で要求を転送する前に要求を満足する試みで、中間サーバ１５８の組を介して要求が均等に分配される。各ブラウザ１５４によって、ローカル・キャッシュを維持することができ、各サーバ１５８によって、順方向プロキシ・キャッシング機構がサポートされる。インターネット・エクスチェンジ・ポイント１６０には、中間サーバ１６２および１６４も含まれ、中間サーバ１６２および１６４のそれぞれによって、キャッシュを維持することができる。ブラウザ１５４でのまたは中間サーバ１５８、１６０、１６２、および１６４でのキャッシュの実施に関するさまざまな考慮事項に、応答時間の改善または帯域幅の削減あるいはその両方が含まれる。
【００７５】
次に、要求が、インターネット・エクスチェンジ・ポイント１６０からサービスする企業１６８のディスパッチャ１６６にルーティングされる。ディスパッチャ１６６によって、中間サーバ１７０を介して着信要求が均等に分配され、中間サーバ１７０によって、ディスパッチャ１７２への要求の転送の前に、要求を満足することが試みられ、各中間サーバ１７０は、逆方向プロキシ・キャッシング機構をサポートする。満足されない要求は、ディスパッチャ１７２によって、ウェブ・アプリケーション・サーバ１７４にまたがって均等に分配され、ウェブ・アプリケーション・サーバ１７４は、データベース１７６にアクセスするデータベース・サービスまたは他のアプリケーションとあいまって、要求を最終的に満足することができる。中間サーバ１７０でのまたはウェブ・アプリケーション・サーバ１７４でのキャッシュの実施に関するさまざまな考慮事項に、スループットの改善またはコストの削減あるいはこの両方が含まれる。
【００７６】
応答は、反対の方向で、サービスする企業からクライアント・デバイスにルーティングされる。類似する中間サーバを、使用する企業内、インターネット全体、またはサービスする企業内で展開できることに留意されたい。クライアントから離れる、要求が通る各連続するステージが、知覚される応答時間に追加されることにも留意されたい。
【００７７】
本発明の好ましい実施形態は、上で説明したように、さまざまなハードウェア・プラットフォームおよびソフトウェア・プラットフォームで実施することができる。しかし、具体的に言うと、本発明の好ましい実施形態は、分散フラグメント・キャッシング技法を対象とする。本発明の好ましい実施形態を詳細に説明する前に、静的ウェブ・コンテンツおよびダイナミック・ウェブ・コンテンツ全般に関する背景情報を提供する。
【００７８】
静的なテキストおよびグラフィック・コンテンツを含むウェブ・ページのフォーマットは、通常は、ＨＴＭＬなどのマークアップ言語を使用して指定される。マークアップは、ページがインターネット・ブラウザによって読み取られる時に単語およびイメージの表示を制御する特殊なコードまたはタグからなる。しかし、Ｊａｖａ（Ｒ）Ｓｅｒｖｅｒ  Ｐａｇｅ（ＪＳＰ）およびサーブレットが、ダイナミック・コンテンツを含むウェブ・ページにより適する。
【００７９】
基本的に、ＪＳＰは、ページを含む応答を生成するためにページに関する要求を処理する方法を記述した組込み指示を有するマークアップ言語文書である。この記述では、単一の文書内で、静的テンプレート・コンテンツが、Ｊａｖａ（Ｒ）コードとして実装されたダイナミック・アクションと混合される。ＪＳＰを使用すると、サーバ側スクリプトレットとしてページにＪａｖａ（Ｒ）コードをインライン展開することもできる。言い換えると、Ｊａｖａ（Ｒ）タグが、ウェブ・ページで指定され、ウェブ・サーバで実行されて、ウェブ・ページが、それを要求したユーザに送信される前に修正される。この手法は、プログラミング・ロジックが比較的少ない時に適する。マークアップ言語文書内に些細な量を超えるプログラミング・ロジックを有することによって、ＪＳＰの優位点すなわち、文書に関連するビジネス・ロジックから文書のプレゼンテーションを分離することが失われる。過度な量のコードをマークアップ言語文書に直接にインライン展開しないようにするために、ＪＳＰによって、単純なＪＳＰタグを使用してランタイムにアクセスできるＪａｖａ（Ｒ）Ｂｅａｎｓにビジネス・ロジックを分離する能力が使用可能にされる。
【００８０】
具体的に言うと、ＪＳＰでは、マークアップ風のタグおよびＪａｖａ（Ｒ）プログラミング言語で記述されたスクリプトレットを使用して、ページのコンテンツの一部またはすべてを生成するロジックをカプセル化する。アプリケーション・ロジックは、Ｊａｖａ（Ｒ）Ｂｅａｎコンポーネントなどの、そのページからタグおよびスクリプトレットによってアクセスされるサーバベースのリソースに常駐させることができる。マークアップ言語タグを使用することによって、たとえばＨＴＭＬページ・ビルダ／エディタなどのツールによっても操作できる便利な形での有用な機能性の、マークアップ言語文書内でのカプセル化が可能になる。ビジネス・ロジックをプレゼンテーションから分離することによって、再利用可能なコンポーネントベースの設計がサポートされる。ＪＳＰによって、ウェブ・ページ作成者が、静的ＨＴＭＬテンプレートにダイナミック・コンテンツ・モジュールを挿入できるようになり、したがって、ウェブ・コンテンツの作成が単純化される。ＪＳＰは、Ｓｕｎ社のJava（Ｒ）Enterprise Edition（Ｊ２ＥＥ）プログラミング・モデルに一体化された部分である。
【００８１】
下で説明する本発明の好ましい実施形態の例で、ＪＳＰを使用できることに留意されたい。しかし、Ｍｉｃｒｏｓｏｆｔ社のActive Server Page（ＡＳＰ）などの他のタイプのサーバ・ページも、使用することができる。
【００８２】
製品表示ＪＳＰによって、製品に関するデータが表される。特定の製品、たとえばレンチに関する要求によって、ＪＳＰならびに製品ｉｄが、照会パラメータとして識別される。製品ｉｄパラメータを用いるそのＪＳＰの実行によって、ＨＴＭＬのページが出力される。その製品の基礎になるデータが変更される時、たとえばレンチが値上げされる時に、そのページを無効化しなければならない。これを行うために、データを表す依存ＩＤをページに関連付けることによって、ページとデータの間に依存性を確立しなければならない。
【００８３】
粒度は、効果的なキャッシング戦略に重要な、ウェブ・ページの特性である。ウェブ・ページのコンテンツは、複数の構成要素からなり、この構成要素の中に、頻繁に変更されるものと比較的静的なものがある場合がある。ウェブ・ページの粒度は、コンテンツの一部である「フラグメント」に関して説明することができる。フラグメントは、ＪＳＰファイルに関するＨＴＴＰ要求を満足することを含めて、さまざまな形で作成することができる。上の例では、製品表示ページが、単一のフラグメント・ページである。
【００８４】
図４に関して、ブロック図に、フラグメントからなるウェブ・ページが示されている。この例では、フラグメント粒度によって、一部のフラグメントが揮発性であり、ある時間的基礎で更新されることがわかっている場合であっても、ページの諸部分をキャッシングできることが示されている。言い換えると、さまざまなタイプのウェブ・コンテンツが、キャッシングから異なる度合の利益を得る。
【００８５】
製品表示ウェブ・ページに、ダイナミック・コンテンツ・フラグメント２００が含まれる。トップレベル・フラグメントは、Java（Ｒ）Server Page（ＪＳＰ）２０４であり、これには、５つの子フラグメント２０６から２１４が含まれる。フラグメント２０８および２１２は、キャッシングされる。子フラグメントが、図のタイムラインによって示されるように、基礎になるデータの変更の割合の昇順で左から右に配置されていることに留意されたい。
【００８６】
製品ＵＲＩ２０６は、製品のGraphics Interchange Format（ＧＩＦまたは．ｇｉｆ）イメージ・ファイルへのUniformResource Identifier（ＵＲＩ）リンクである。フォーマットされたテーブルによって、詳細な製品記述２０８を保持することができる。パーソナライズされた挨拶２１０を表示するフラグメントによって、買物客の名前を使用することができる。この挨拶は、しばしば、たとえばユーザごとに変更されるが、所与の買物客の名前が同一のユーザによるセッションの過程で再利用されるので、キャッシングすることが役に立つ可能性がある。
【００８７】
ＪＳＰ２１２によって、省略されたショッピング・カートが作成される。ショッピング・カートＪＳＰ２１２によって、データを表示するＨＴＭＬテーブルを作成することができる。このコンテンツは、買物客が自分のカートに何かを追加するたびに更新されなければならないので、パーソナライズされた挨拶２１０より頻繁に変更される。それでも、ショッピング・カートが、買物客に返されるすべてのページに表示される場合に、カートを表示するたびに同一のデータを取り出すよりも、ＪＳＰ２１２をキャッシングすることがより効率的である。ＪＳＰ２０４に、株式ウォッチ・リストを表示するウェブ・ページに表示される宣伝２１４も含めることができる。宣伝は、ページが要求されるたびに変更されるので、更新レートは、キャッシングから利益を得るには高すぎる。
【００８８】
図１から４に、本発明の好ましい実施形態の説明の背景文脈として、さまざまな分散データ処理システムおよびダイナミック・コンテンツの例を示した。上で述べたように、効率的にフラグメントをキャッシングすることは、困難になる可能性がある。本発明の好ましい実施形態は、ダイナミック・フラグメントおよびパーソナライズされたフラグメントすなわちダイナミック・コンテンツのキャッシングに関連する問題を克服することに特に注意して、フラグメントを効率的にキャッシングするためにＨＴＭＬおよびＨＴＴＰに対する拡張を使用する技法を対象とする。
【００８９】
下で示す例で、ＨＴＴＰ／１．１およびＨＴＭＬ  ４．１など、プロトコルの特定の仕様に言及することに留意されたい。しかし、当業者は、本発明の好ましい実施形態によって要求されるものと同等の特徴および機能性の最小限の組を備える他のプロトコルも使用できることを、諒解するであろう。
【００９０】
用語法
「静的フラグメント」は、照会パラメータまたはクッキーを使用せずに入手できるフラグメントと定義される。静的フラグメントは、そのＵＲＩだけから参照され、キャッシングされ、またはフェッチされ、あるいはこの組合せによって入手することができる。
【００９１】
「ダイナミック・フラグメント」は、要求元によって供給されるパラメータまたはクッキーに基づくサーバでの計算の結果として生成されるフラグメントである。ダイナミック・フラグメントの例を、スポーツ・イベントの結果とすることができる。ダイナミック・フラグメントは、サイトに固有の、ユーザによって要求されたデータのサブセットからなるという特徴を有する。
【００９２】
「パーソナライズされたフラグメント」も、要求元のパラメータまたはクッキーに基づく計算の結果として生成される。パーソナライズされたフラグメントは、そのコンテンツがユーザに依存するという点で、ダイナミック・フラグメントの特殊な例である。パーソナライズされたフラグメントは、たとえばアカウント番号など、不揮発性とするか、たとえばショッピング・バスケットなど、揮発性とすることができる。フラグメントの定義および管理において、ダイナミック・フラグメントおよびパーソナライズされたフラグメントによって、同等の問題が提示され、したがって、用語「ダイナミック」および「パーソナライズされた」は、交換可能に使用される。
【００９３】
「トップレベル・フラグメント」は、他のフラグメントに組み込まれるのではなく、それ自体に他のフラグメントを組み込むことができるフラグメントである。
【００９４】
「ページ・アセンブラ」は、フラグメントからページを構成するプログラムである。フラグメントの収集およびページの構成の処理を、「ページ組立」と呼ぶ。追加のフラグメントをフェッチし、文書に組み立てなければならないかどうかを判定するためにフラグメントを検査する処理を、本明細書では、文字どおりの構文解析が実行されない場合であっても、「構文解析」と呼ぶ。たとえば、フラグメントにメタ情報が付随し、このメタ情報によって、組立のためにフェッチされなければならない追加フラグメントの名前が指定され、追加フラグメントを挿入しなければならない正確な位置が指定される場合があり、追加フラグメントに関するそのようなフラグメントの検査は、必ずしも計算機科学の形式的な構文解析ではない。
【００９５】
ＦＲＡＧＭＥＮＴＬＩＮＫタグの定義
図５に関して、本発明の好ましい実施形態による、ＦＲＡＧＭＥＮＴＬＩＮＫタグの形式的な標準汎用印刷指定言語（ＳＧＭＬ）定義が示されている。ＦＲＡＧＭＥＮＴＬＩＮＫタグは、ページ組立中またはページ・レンダリング中に、文書に挿入されるフラグメントの位置を指定するのに使用される。新しいオブジェクトが、親文書の一部として構文解析され、新しいオブジェクトに、それ自体のＦＲＡＧＭＥＮＴＬＩＮＫタグを含めることができる。ＦＲＡＧＭＥＮＴＬＩＮＫタグの属性の定義を、下で説明する。
【００９６】
（マークアップ言語で、通常は、角括弧（「＜」および「＞」）が、区切り文字として使用されることに留意されたい。この文書のマークアップ言語バージョンでの潜在的なフォーマッティング問題または電子解釈問題を避けるために、大括弧（「｛」および「｝」）を、この文書全体で置換区切り文字として使用する。もう１つのフォーマッティングの注記として、長いテキスト文字列のいくつかの例が、この文書ではテキストの複数の行を占める。当業者は、この文書で行の境界をまたぐように見えるものであっても、単一行のテキストとして示されることを意図されたテキストを判定することができるであろう。）
【００９７】
ｓｒｃ＝ＵＲＩ
ＳＲＣ属性によって、文書に挿入されるフラグメントのソース位置が指定され、ＳＲＣ属性は、フラグメントの入手に関するソース識別子として働く。ＵＲＩが、相対ＵＲＩである場合には、絶対ＵＲＩは、親のパスおよび関連するＢＡＳＥタグから得られる。単一の共通フラグメントが２つの異なるページに含まれる場合に、これによって混乱が生じる可能性があることに留意されたい。作成者は、フラグメントＵＲＩに関して絶対パス名だけをコーディングすることが推奨される。ＵＲＩのプロトコル部分によって、「クッキー」を指定することができるが、この場合に、挿入されるテキストの値は、名前を指定されたクッキーから取られる。
【００９８】
ａｌｔ＝ｓｔｒｉｎｇ
ＡＬＴ属性によって、ＳＲＣ属性からのＵＲＩをフェッチできない場合に置換される代替ＨＴＭＬテキストが指定される。ＡＬＴ属性が指定されず、ＳＲＣ属性のフラグメントをフェッチできない場合には、フラグメントはフェッチされない。
【００９９】
ｐａｒｍｓ＝％ｐａｒｍｌｉｓｔ
ＰＡＲＭＳ属性によって、スペースによって区切られた名前のリストが指定される。各名前は、親フラグメントのＵＲＩに存在する可能性がある照会パラメータに対応する。ＰＡＲＭＳ属性が指定される時には、ＳＲＣ属性で指定されたＵＲＩが、不完全とみなされる。ＳＲＣ属性を完成するために、ＰＡＲＭＳ属性で名前を指定された照会パラメータのそれぞれの値を、親文書からフェッチし、これを使用して名前／値対を作成しなければならない。この名前／値対は、ＳＲＣ属性のＵＲＩに、それを完成させるために、照会パラメータとして付加される。名前を指定されたパラメータが親ＵＲＩに存在しない場合には、そのパラメータは、フラグメントのＵＲＩに付加されない。各パラメータは、ＰＡＲＭＳ属性に現れるのと同一の順序でＳＲＣ属性のＵＲＩに付加されなければならない。
【０１００】
ｆｏｒｅａｃｈ＝ｑｕｏｔｅｄ−ｓｔｒｉｎｇ
ＦＯＲＥＡＣＨ属性によって、引用符で囲まれた文字列が指定される。引用符で囲まれた文字列の値は、クッキーの名前であることが好ましく、このクッキーの値は、スペースによって区切られた名前／値対のリストであり、名前および値は、等号（「＝」）または他のタイプの同等の区切り文字によって区切られる。クッキーに含まれる名前／値対ごとに、そのＳＲＣ属性が、名前／値対を照会パラメータとして追加されたＵＲＩである、新しいＦＲＡＧＭＥＮＴＬＩＮＫタグが生成される。これによって、たとえばユーザの株式ウォッチリストなど、１つの照会パラメータの値だけが異なる複数のＦＲＡＧＭＥＮＴＬＩＮＫタグを自動的に生成する速記法がもたらされる。
【０１０１】
言い換えると、ＦＯＲＥＡＣＨ属性によって、フラグメントへの単一リンクの、複数のフラグメントへの複数のリンクの組への拡張が提供される。各名前／値対は、拡張パラメータ名および拡張パラメータ値の対になる。
【０１０２】
ｓｈｏｗｌｉｎｋ＝（ｎｏ｜ｃｏｍｍｅｎｔ｜ＣＤＡＴＡ）
ＳＨＯＷＬＩＮＫ属性によって、インクルードされるフラグメント・データをラップするのに使用されるタグの名前が指定される。「ｎｏ」と指定される場合に、データは、ラップするタグに含まれない。「ｃｏｍｍｅｎｔ」と指定される場合に、ＦＲＡＧＭＥＮＴＬＩＮＫタグが、ＨＴＭＬコメントとして書き直される。他の値が指定される場合に、ＦＲＡＧＭＥＮＴＬＩＮＫタグが、指定されたタグとして書き直される。ＣＤＡＴＡが有効なタグであることを検証する検査は行われず、したがって、フラグメントを正確にどのように示すかの判断は、ページ作成者に委ねられる。ＳＨＯＷＬＩＮＫ属性が省略された場合には、ラッピングは行われない。
【０１０３】
ｉｄ＝ＩＤ
ＩＤ属性が指定される場合に、その識別子値が、www.w3c.orgでWorldWide Web Consortium（Ｗ３Ｃ）から入手可能な、参照によって本明細書に組み込まれる「HTML 4.01 Specification」、W3CRecommendation、1999年12月24日に従って、このフラグメントを表す結果のＤＯＭ要素内のフラグメントに一意の名前として割り当てられる。
【０１０４】
ｃｌａｓｓ＝ＣＤＡＴＡ
ＣＬＡＳＳ属性が指定される場合に、これによって、ＨＴＭＬ仕様に従って、このフラグメントを表すＤＯＭ要素にクラス名またはクラス名の組が割り当てられる。
【０１０５】
ページが組み立てられる時に、ページ・アセンブラによって、指定されたフラグメントがフェッチされ、親オブジェクトに挿入される。ＳＨＯＷＬＩＮＫ属性を使用して、挿入されるデータをタグまたはＨＴＭＬコメントの内部にラップできるようにすることができる。入れ子になったフラグメントが提供されるが、フラグメントを、それ自体を直接にまたは間接的に含めることはできない。フラグメント空間内のすべてのフラグメントの入れ子構造は、有向非循環グラフ（ＤＡＧ）を形成しなければならない。付随するＨＴＴＰ応答ヘッダのすべてが、文書の一部とみなされず、文書に挿入される前に除去されなければならない。キャッシュでは、他の文書と同様に、これらのヘッダを保存しなければならない。代替フラグメントＵＲＩを指定することができる。ＡＬＴ属性によって指定されるフラグメントは、ＳＲＣフラグメントをフェッチできない場合にフェッチされ、挿入される。ＳＲＣ属性のフラグメントもＡＬＴ属性のフラグメントもフェッチできない場合には、ＦＲＡＧＭＥＮＴＬＩＮＫタグが起点文書に含まれなかったかのようにレンダリングを継続することができる。
【０１０６】
ダイナミック・フラグメントまたはパーソナライズされたフラグメントの使用に伴う問題は、それらをフェッチするのに使用されるＵＲＩを、親ページが存在する環境またはコンテキストから計算しなければならないことである。言い換えると、ＵＲＩは、親文書に付随する照会パラメータから動的に作成される必要がある場合があり、ＰＡＲＭＳ属性によってこの特徴がサポートされる。ＰＡＲＭＳ属性は、フラグメントをフェッチする時に使用される、親文書からの照会パラメータの名前のリストからなる。名前／値対が、ＰＡＲＭＳ属性で名前を指定されるパラメータごとに形成され、ＦＲＡＧＭＥＮＴＬＩＮＫタグのＳＲＣ属性で指定されるＵＲＩに照会パラメータとして（おそらくは追加して）付加される。これらの名前／値対は、ＰＡＲＭＳ属性に現れるのと同一の順序で付加されなければならない。さらに、親に関連するクッキーが、フラグメントの正しいフェッチまたは計算に必要になる場合がある。親文書に付随するすべてのクッキーを、フラグメントに関する要求と共に供給しなければならない。
【０１０７】
しばしば、たとえば株式ウォッチリストの使用で、照会パラメータの値だけが異なる多数のＦＲＡＧＭＥＮＴＬＩＮＫタグが必要になる。ＦＯＲＥＡＣＨ属性を、ページのコーディングを単純化する速記法として使用して、フラグメントを送信する時の帯域幅要件を減らし、キャッシュ内のフラグメントのサイズを減らすことができる。たとえば、次のようなＦＲＡＧＭＥＮＴＬＩＮＫタグが作成されると仮定し
{fragmentlink
src="http://www.acmeInvest.com/stockQuote.jsp"
alt="Error occurredtrying to find stockQuote.jsp"
foreach="issues" /}
次のようなクッキーがあると仮定する。
Cookie:issues="stock=IBM stock=CSCO stock=DELL"
【０１０８】
これによって、ＦＲＡＧＭＥＮＴＬＩＮＫタグが一連のＦＲＡＧＭＥＮＴＬＩＮＫタグに展開され、これによって、下記の新たに生成されるＦＲＡＧＭＥＮＴＬＩＮＫタグのそれぞれが評価される。
{fragmentlink
src="http://www.acmeInvest.com/stockQuote.jsp?stock=IBM"
alt="An error occurred trying to findstockQuote.jsp" /}
{fragmentlinksrc="http://www.acmeInvest.com/stockQuote.jsp?stock=CSCO"
alt="An error occurred trying to findstockQuote.jsp" /}
{fragmentlinksrc="http://www.acmeInvest.com/stockQuote.jsp?stock=DELL"
alt="An error occurred trying to findstockQuote.jsp" /}
【０１０９】
しばしば、フラグメントのテキストが、小さく、クッキーの値として含めることができ、ページ組立中のかなりの性能利益がもたらされる。これを指定するために、キーワードＣＯＯＫＩＥをＵＲＩのプロトコルに配置する。たとえば、
{fragmentlinksrc="cookie://cookiename" /}
【０１１０】
ＦＲＡＧＭＥＮＴヘッダの定義
図６に関して、本発明の好ましい実施形態によるＦＲＡＧＭＥＮＴヘッダの形式的な定義が示されている。本発明の実施形態では、新規のＨＴＴＰヘッダおよび既存の「Ｃａｃｈｅ−Ｃｏｎｔｒｏｌ」ヘッダに対する拡張を使用することができる。ＦＲＡＧＭＥＮＴヘッダは、参照によって本明細書に組み込まれる、www.ietf.orgでInternet Engineering Task Forceから入手可能な、ＨＴＴＰ仕様、「HypertextTransport Protocol -- HTTP/1.1」、Request for Comments 2616 (RFC 2616)、InternetEngineering Task Force、June 1999に対応する。
【０１１１】
フラグメントとしてのオブジェクトに関連するすべての情報が、ＦＲＡＧＭＥＮＴと称するヘッダにカプセル化される。このヘッダは、クライアント、サーバ、または中間キャッシュが、ページ組立能力を有するかどうかを識別するのに使用される。このヘッダによって、フラグメントのキャッシュ識別子（ＵＲＩの照会パラメータおよびオブジェクトに付随するクッキーに基づく）を形成する規則も指定される。さらに、このヘッダによって、ホストによって開始される無効化をサポートする、基礎となるデータに対するオブジェクトの依存関係が指定される。ＦＲＡＧＭＥＮＴヘッダは、「Ｃａｃｈｅ−Ｃｏｎｔｒｏｌ：ｆｒａｇｍｅｎｔｒｕｌｅｓ」ディレクティブが有効である場合に限って使用されなければならない。ＦＲＡＧＭＥＮＴヘッダの完全な構文を、図６に示す。ＦＲＡＧＭＥＮＴヘッダの属性の定義を、下で説明する。
【０１１２】
ｃｏｎｔａｉｎｓ−ｆｒａｇｍｅｎｔｓ：この属性によって、ページ・アセンブラが使用できるフラグメント・ディレクティブが応答の本体に含まれることが指定される。
【０１１３】
ｓｕｐｐｏｒｔｓ−ｆｒａｇｍｅｎｔｓ：この属性によって、起点要求元またはデータ・ストリーム内のキャッシュのいずれかがページ組立をサポートすることが指定される。このディレクティブは、ページ組立を完全にサポートするキャッシュまたはクライアントが挿入することができる。
【０１１４】
ｄｅｐｅｎｄｅｎｃｉｅｓ：この属性によって、応答の本体が依存する依存名のリストが指定される。
【０１１５】
ｃａｃｈｅｉｄ：この属性によって、オブジェクトのキャッシュＩＤの形成に使用される規則のリストが指定される。規則が「ＵＲＩ」として指定される場合に、応答のフルＵＲＩが、キャッシュＩＤとして使用される。キャッシュＩＤが規則として指定される場合に、下で詳細に説明するように、規則が要求ＵＲＩに適用されて、キャッシュＩＤが形成される。
【０１１６】
本発明の好ましい実施形態では、フラグメントのキャッシング規則は、キャッシュがページ組立をサポートする場合に、他のタイプのオブジェクトと異なる。したがって、「Ｃａｃｈｅ−Ｃｏｎｔｒｏｌ」ヘッダが、フラグメント・キャッシング規則が適用されることを示すように拡張される。これは、拡張によってｎｏ−ｃａｃｈｅディレクティブをオーバーライドすることによって行われる。「ｆｒａｇｍｅｎｔｒｕｌｅｓ」と称する新しいｃａｃｈｅ−ｒｅｑｕｅｓｔ−ｄｉｒｅｃｔｉｖｅが、ＨＴＴＰ／１．１仕様のセクション１４．９．６で指定される「Ｃａｃｈｅ−Ｃｏｎｔｒｏｌ」ｇｅｎｅｒａｌ−ｈｅａｄｅｒフィールドに対する拡張として実施される。この拡張の意図は、フラグメント組立をサポートするキャッシュでのｎｏ−ｃａｃｈｅディレクティブの挙動を修正することである。フラグメント組立をサポートしないキャッシュは、「ｆｒａｇｍｅｎｔｒｕｌｅｓ」ディレクティブを無視するが、これはＨＴＴＰ／１．０およびＨＴＴＰ／１．１での基本的なデフォルト挙動である。フラグメント組立をサポートするキャッシュは、「ｆｒａｇｍｅｎｔｒｕｌｅｓ」ディレクティブが付随する時に「ｎｏ−ｃａｃｈｅ」ディレクティブ（および存在するすべての「Ｐｒａｇｍａ：ｎｏ−ｃａｃｈｅ」ヘッダ）を無視し、応答に付随する他のヘッダに従ってキャッシング規則を適用する。「Ｃａｃｈｅ−Ｃｏｎｔｒｏｌ」ヘッダの例を示す。
Cache-Control: no-cache,fragmentrules
【０１１７】
ページ組立の機能および責任の識別
本発明の好ましい実施形態によって、フラグメント包含を定義できるという利益がもたらされ、その結果、ブラウザ・キャッシュを含むフラグメントが存在することのできるすべてのキャッシュを含む、ページ作成者からブラウザ・レンダリングまでのイベントのチェーン内のどの点でもページ組立を実施することが可能になる。ページ組立を実行できるソフトウェア・エンティティが、組立点（assembly point）として定義される。
【０１１８】
この特徴によって、下記の可能なシナリオが提示される。
１．ページを提供するＨＴＴＰサーバよりブラウザに近い組立点がない。この場合に、サーバは、それ自体で組立を行い、完全に組み立てられたページを提供しなければならない。
２．起点サーバのためにページ組立を実行できるある種のプロキシがある。このプロキシは、サイトの組立ポイントになることができる。起点サーバは、このプロキシにフラグメントを供給することができ、どのページも組み立てる必要がない。
３．ユーザのブラウザが、ページ組立を実行することができる。この場合に、ネットワーク・キャッシュまたはサーバがページ組立を行う必要はない。
【０１１９】
フラグメントを提供する方法すなわち、完全に組み立てるか組み立てないかを決定するために、サーバおよびキャッシュは、上流エージェントの少なくとも１つが組立点として従事しているかどうかを判定できなければならない。本発明の好ましい実施形態では、ＨＴＴＰ要求ヘッダを使用し、サーバの組立ポイントとして従事する能力を有するエージェントが、それがフラグメントを受け入れることができ、完全なページを受信する必要がないことを示すのにヘッダを使用できるようにする。ＦＲＡＧＭＥＮＴヘッダの「ｓｕｐｐｏｒｔｓ−ｆｒａｇｍｅｎｔｓ」ディレクティブは、クライアントまたはキャッシュが、それが組立点であることを下流キャッシュに示すために挿入することができる。「ｓｕｐｐｏｒｔｓ−ｆｒａｇｍｅｎｔｓ」ディレクティブの例を示す。
fragment:supports-fragments
【０１２０】
プロセッサがページ組立をサポートするのでというだけで、そのプロセッサがサーバから受信するすべてのオブジェクトに対してページ組立を行わなければならないことは暗示されない。サーバから受信するすべての文書を構文解析し、それの組立を試みることは、リソースの浪費と潜在的な問題のソースの両方である。したがって、サーバは、オブジェクトが提供される前に、そのオブジェクトを組み立てる必要があることを示さなければならない。キャッシュまたはブラウザでのページ組立を必要とするサーバによって、ＦＲＡＧＭＥＮＴＳヘッダの「ｃｏｎｔａｉｎｓ−ｆｒａｇｍｅｎｔｓ」ディレクティブが挿入されなければならない。「ｃｏｎｔａｉｎｓ−ｆｒａｇｍｅｎｔｓ」ディレクティブの例を示す。
fragment:Contains-Fragments
【０１２１】
ブラウザ・キャッシュを含むほとんどの現在のＨＴＴＰキャッシュでは、照会パラメータを有するすべてのオブジェクトが、キャッシュ可能でないと仮定される。ＨＴＴＰ／１．１では、キャッシング能力を拡張し、一般化して、キャッシュが、成功裡にフェッチしたすべてのオブジェクトをキャッシングできるようにする。しかし、ＨＴＴＰ  １．１キャッシュでも、しばしば、ダイナミック・オブジェクトのキャッシングはリソースの不十分な使用という仮定に基づいて、ダイナミックと思われるオブジェクトをキャッシングしないように構成される。この仮定が無効な状況の例が、パーソナライズされたデータの場合である。パーソナライズされたページは、照会パラメータまたはクッキーをページに関連付けることによって作成され、これによって、ページが、より一般的なページの特定のパーソナライズされたインスタンスとして識別される。ページがパーソナライズされるという事実によって、そのページが固有にキャッシュ不能になるわけではない。ページがキャッシュ不能になるのは、そのページが基づくデータが非常に揮発性である場合に限られる。これは、特定の企業のウェブ・コンテンツだけをキャッシングする企業サーバで特にそうである。
【０１２２】
そのようなページのキャッシングに対して通常与えられる議論は、そのようなページの再利用の発生が、キャッシュ内のスペースを正当化するには低すぎると言うことである。この議論は、複数の理由から不十分である。
１．最初の作成からブラウザでの最終的なレンダリングまでの文書のコストは、名目上は文書のサイズの関数のみである。文書が何らかの形で「ダイナミック」である場合に、コストの大半は、最初の場所での文書の作成にある。したがって、非常にわずかな再利用であっても、サーバでのかなりのコスト節約をもたらすことができる。
２．キャッシュの容量は、かなり増加し、非常に高い速度で増加し続けている。
３．フラグメント技術の採用によって、同一のＨＴＭＬコンテンツの冗長なインスタンスを削除することによって、キャッシングされるデータの量を実際に減らすことができる。
【０１２３】
フラグメントの導入によって、特にページ・アセンブラがキャッシュの内側で構成される場合に、キャッシュ・ポリシの指定が非常に複雑になる可能性がある。ページの各フラグメントが、異なるキャッシュ・ポリシを必要とする可能性がある。本発明の好ましい実施形態では、ＨＴＴＰ応答ヘッダを使用して、従来技術で使用可能なものに対してキャッシング・ポリシの粒度を増やす。
【０１２４】
実施されるページ・アセンブラに通信されなければならない、キャッシングに影響する２つの要因すなわち、（１）フラグメントの寿命および（２）オブジェクトの明示的なサーバ開始無効化（server-initiated invalidation）がある。サーバ開始無効化がない場合に、他のオブジェクトに関するキャッシュ内のオブジェクトの寿命を指定する同一の機構を、フラグメントに適用することができる。フラグメントを明示的にはサポートしないキャッシュでフラグメントがキャッシングされないようにすることが重要である場合には、ディレクティブ「ｎｏ−ｃａｃｈｅ」および「ｆｒａｇｍｅｎｔｒｕｌｅｓ」を有する「Ｃａｃｈｅ−Ｃｏｎｔｒｏｌ」ヘッダを、応答に含めなければならない。「ｎｏ−ｃａｃｈｅ」ディレクティブによって、実施しないキャッシュによるフラグメントのキャッシングが防止され、「ｆｒａｇｍｅｎｔｒｕｌｅｓ」ディレクティブによって、実施するキャッシュが「ｎｏ−ｃａｃｈｅ」ディレクティブをオーバーライドできるようになる。
【０１２５】
サーバ開始無効化
サーバ開始無効化をサポートするキャッシュに、サーバからの明示的制御を介して、フラグメントを無効化しなければならないことを知らせることができる。サーバ開始無効化を認識しないかサポートしない既存の古いキャッシュとの互換性を維持するために、そのようなサーバによって無効化されたフラグメントに、ＨＴＴＰ／１．１の「Ｃａｃｈｅ−Ｃｏｎｔｒｏｌ」ヘッダおよびディレクティブ「ｎｏ−ｃａｃｈｅ」を与えなければならない。キャッシュが「ｎｏ−ｃａｃｈｅ」ディレクティブをオーバーライドし、フラグメントによって指定される規則を適用することが望まれる場合に、これらのフラグメントに、拡張ディレクティブ「ｆｒａｇｍｅｎｔｒｕｌｅｓ」を与えなければならない。本発明の好ましい実施形態のフラグメント・キャッシング技法を実施するキャッシュは、ＨＴＴＰ／１．１仕様に記載のＨＴＴＰ／１．１キャッシュ可能性規則による機能性も実施しなければならない。
【０１２６】
サーバによって無効化されるフラグメントが、データの複数のソースに依存する場合があり、複数のフラグメントが、同一のデータに依存する場合がある。キャッシュに単一の無効化オーダーを送信することによって、共通のデータに基づいてすべてのフラグメントを突き止めることによって複数のフラグメントを無効化できることが、非常に望ましい。これを効率的に行うために、サーバによって、１つまたは複数の無効化ＩＤがフラグメントに割り当てられる。実施するキャッシュによって、キャッシングされた項目への副インデクシングを提供するのに無効化ＩＤが使用される。サーバ開始無効化オーダーが到着する時に、無効化ＩＤの下でインデクシングされるすべてのキャッシングされた項目が、無効化される。無効化ＩＤは、ＦＲＡＧＭＥＮＴヘッダの「ｄｅｐｅｎｄｅｎｃｉｅｓ」ディレクティブを介して指定される。「ｄｅｐｅｎｄｅｎｃｉｅｓ」ディレクティブの例を示す。
fragment:dependencies="dep1 dep2"
【０１２７】
実施するサーバによって、サービスするホストがオブジェクトを明示的に無効化することを示すのに、「ｄｅｐｅｎｄｅｎｃｉｅｓ」ディレクティブが使用される。ＨＴＴＰ／１．１仕様で定義される通常のエージングおよびキャッシュ可能性は、このディレクティブによって影響されず、したがって、まれに無効化されるオブジェクトを、サーバ開始無効化なしにキャッシュから除去することができる。「ｄｅｐｅｎｄｅｎｃｉｅｓ」ヘッダが指定される場合に、キャッシュは、すべての「ｃａｃｈｅ−ｃｏｎｔｒｏｌ：ｎｏ−ｃａｃｈｅ」ヘッダを無視することができる。
【０１２８】
無効化ＩＤ、ＵＲＩ、およびキャッシュＩＤは、別々の役割を有する。これらのそれぞれを指定する別々の機構を設けることによって、解決が困難になる可能性があるアプリケーション設計の無用な衝突を避ける。
【０１２９】
ダイナミック・フラグメント・キャッシュ識別子
オブジェクトを、そのＵＲＩと異なる識別子の下でキャッシングすることが可能である。ＵＲＩ自体の内容に基づいて、キャッシュＩＤが形成される正確な形に制約を設けることも可能である。これは、ダイナミック・オブジェクトについて、ＵＲＩが、しばしば、一意のキャッシュＩＤの一部として使用してはならない照会パラメータを用いて形成されるからである。これらのパラメータが、キャッシングの前にＵＲＩから除去されない場合に、誤ったキャッシュ・ミスが発生する可能性があり、同一のオブジェクトの複数のコピーが複数のＩｄの下で保管される結果になる。
【０１３０】
この問題を避けるために、キャッシュＩＤを形成する規則の組を、ＵＲＩをキャッシュＩＤとして直接に使用することができないダイナミック・オブジェクトの応答ヘッダで配送しなければならない。各規則に、照会パラメータ名およびクッキー名のリストが含まれる。従来技術では、クッキーが、キャッシュＩＤの一部として使用されるのではなく、多くのアプリケーションで、要求を他の要求から一意にする情報が、クッキーの内部のデータである。したがって、クッキーの値を、キャッシュＩＤの一部として指定することができる。キャッシュＩＤの一部として使用されるクッキーのすべてが、名前／値対の形になっていなければならない。
【０１３１】
言い換えると、ＣＡＣＨＥＩＤディレクティブは、１つまたは複数のｒｕｌｅｓｅｔからなる。ｒｕｌｅｓｅｔは、１つまたは複数の規則からなる。規則は、文字列のリストからなり、各文字列は、要求ＵＲＩからの照会パラメータの名前または付随するクッキーの名前である。ＣＡＣＨＥＩＤディレクティブの例を示す。
fragment: cacheid="(p1 [p2], c4) (p3, c4 [c5]) URI"
【０１３２】
このディレクティブは、３つの規則すなわち、（ｐ１［ｐ２］，ｃ４）、（ｐ３，ｃ４［ｃ５］）、およびＵＲＩからなる。規則の「ｐ＿」項は、照会パラメータのパラメータであり、「ｃ＿」項は、クッキーのクッキー名である。
【０１３３】
キャッシュＩＤを作成するために、キャッシュは、フラグメントのＵＲＩのパス名部分から開始する。次に、ｒｕｌｅｌｉｓｔ内の各規則の適用を試みる。ｒｕｌｅｌｉｓｔ内のすべての規則を適用できる場合には、このアクションからの文字列が、キャッシュＩＤとして使用される。ｒｕｌｅｌｉｓｔ内の規則のいくつかを適用できない場合には、ｒｕｌｅｌｉｓｔがスキップされ、次のｒｕｌｅｌｉｓｔが適用され、以下同様である。任意選択でないすべての規則を適用できるｒｕｌｅｌｉｓｔが存在しない場合には、そのオブジェクトはキャッシングされない。そうでない場合には、成功裡に適用された最初のｒｕｌｅｓｅｔが、キャッシュＩＤの形成に使用される。
【０１３４】
角型括弧（「［」および「］」）で囲まれた規則は、可能な場合に適用されなければならない任意選択の規則であるが、任意選択規則の失敗は、ｒｕｌｅｌｉｓｔの失敗にはつながらない。オブジェクトにＣＡＣＨＥＩＤディレクティブが付随しない場合には、そのオブジェクトは、照会パラメータを含むそのフルＵＲＩの下でキャッシングされる。
【０１３５】
規則を適用するために、キャッシュによって、まず、起点ＵＲＩからすべての照会パラメータを除去することによって、基本キャッシュＩＤが形成される。ｐａｒｍｒｕｌｅを適用するために、キャッシュによって、ｐａｒｍｎａｍｅで指定された名前を有する照会パラメータが探される。その名前が存在する場合には、起点ＵＲＩからの対応する名前／値対が、基本キャッシュＩＤに付加されて、新しい基本キャッシュＩＤが形成される。この処理は、すべての規則が成功裡に適用されるまで継続される。任意選択でない規則を適用できない場合には、基本キャッシュＩＤが、その元々の状態に復元され、次のｒｕｌｅｌｉｓｔが適用される。ｃｏｏｋｉｅｒｕｌｅを適用するために、キャッシュによって、ｃｏｏｋｉｅｎａｍｅパラメータで指定された名前を有する名前／値対の形のクッキーが探される。それが存在する場合には、名前／値対を基本キャッシュＩＤに付加して、新しい基本キャッシュＩＤを形成する。この処理は、すべての規則が成功裡に適用されるまで継続される。任意選択でない規則を適用できない場合には、基本キャッシュＩＤが、その元々の状態に復元され、次のｒｕｌｅｌｉｓｔが適用される。ｒｕｌｅｌｉｓｔが文字列「ＵＲＩ」からなる場合には、応答のＵＲＩ全体が、キャッシュＩＤとして使用される。上で述べた例では、２つのｒｕｌｅｌｉｓｔの両方を成功裡に適用できない場合に、要求のＵＲＩ全体が使用される。
【０１３６】
オブジェクトに関する要求がキャッシュに到着する時に、キャッシュすなわちキャッシュ管理ユニットまたはキャッシュのメインテナ（ｍａｉｎｔａｉｎｅｒ）によって、まず、オブジェクトがそのフルＵＲＩの下でキャッシングされるかどうかが検査される。そうである場合には、オブジェクトが返されるが、そうでない場合には、基本キャッシュＩＤが、フラグメントのＵＲＩのパス部分から形成され、ルックアップがもう一度実行される。オブジェクトが見つからない場合には、キャッシュに関連する規則テーブルから、基本キャッシュＩＤが検索される。基本キャッシュＩＤが、キャッシュの規則テーブルに登録されている場合には、そのＵＲＩの規則が、上で説明したように適用される。ｒｕｌｅｌｉｓｔが成功裡に適用される場合に、オブジェクトが、新しいキャッシュＩＤの下でもう一度探される。これが見つからない場合には、キャッシュは、これをミスとみなし、要求をサーバに向かって転送するが、見つかる場合には、そのオブジェクトが要求元に返される。
【０１３７】
上で示した例を継続して、オブジェクトのフルＵＲＩが、
http://foo.bar.com/buyme?p1=parm1&p3=parm3
であり、応答が、名前「ｃ４」と値「ｃｏｏｋｉｅ４」を有する付随するクッキーを有すると仮定する。この場合に、キャッシュＩＤは、第１の規則すなわち「（ｐ１［ｐ２］，ｃ４）」が適用されるので、次の形になる。
http://foo.bar.com/buyme/p1=parm1/c4=cookie4
【０１３８】
複数のキャッシュを介するページ組立
図７から１３に関して、オブジェクト取出しパスに沿ったフラグメント・サポート式エージェントおよびフラグメント非サポート式エージェントの組が、本発明の好ましい実施形態のフラグメント・キャッシング技法をさまざまな処理環境で成功裡に実施できる形の議論の基礎として示されている。
【０１３９】
クライアント・ブラウザとサーバの間のパスに沿って複数のキャッシュがある時に、キャッシュの一部がページ組立のサポートを主張し、キャッシュの一部がページ組立のサポートを主張しない場合に、複雑な状況が生じる可能性がある。この問題は、イメージまたはマルチメディアなどの他のタイプの組込みオブジェクトについて生じるのではない。というのは、キャッシュおよびブラウザが、必ずこれらのオブジェクトを独立の関連しないオブジェクトとして扱うからである。ブラウザでのレンダリングの後でも、起点オブジェクトは、ブラウザのキャッシュ内で別個である。しかし、ページに、トップレベル・フラグメント「ｐ」および子フラグメント「ｃ」が含まれる場合に、「ｐ」のＵＲＩを使用する、オブジェクトに関する要求によって、ブラウザから始まり、宛先サーバで終わるエージェントのチェーンでのページ組立のサポートのレベルに応じて、フラグメント「ｐ」または完全に構成されたページ「Ｐ」のいずれかが返される可能性がある。
【０１４０】
図７から１３に、異なる機能を有するエージェントのさまざまな構成と、本発明の好ましい実施形態がこれらを処理する形を示す。各図で、第１のキャッシュ、キャッシュ１および第２のキャッシュ、キャッシュ２が、クライアント・ブラウザとサーバの間の位置を占める。この例では、「ｆ」によって、フラグメントをサポートするエージェントが示され、「ｎｆ」によって、フラグメントをサポートしないエージェントが指定され、「ｐ」によって、親フラグメントが指定され、「ｃ」によって、子フラグメントが指定され、「Ｐ（ｐ，ｃ）」によって、子フラグメント「ｃ」を親フラグメント「ｐ」に組み込むことによって構成されるページが指定される。
【０１４１】
図７に、最も単純な場合を示す。この例では、サーバが、フラグメントをサポートし、２つのキャッシュおよびブラウザは、フラグメントをサポートしてもしなくてもよい。子フラグメント「ｃ」を含むトップレベル・フラグメント「ｐ」がある。サーバは、「ｐ」および「ｃ」を別々に保管するが、これらが関連することを知っている。「ｐ」に関する特定の要求に関して、ブラウザとサーバの間のエージェント（任意の数のレベルの）がフラグメントをサポートする場合に、別々のフラグメントが返され、そうでない場合に、サーバは、フラグメントを組み立て、完全に組み立てられたページを返す。
【０１４２】
図８を参照すると、ブラウザはフラグメントをサポートするが、キャッシュ１およびキャッシュ２はサポートしない。ブラウザがｐ（およびｐの組立を試みた後にｃ）を要求した後に、各エージェントが、「ｐ」および「ｃ」のコピーをキャッシングしている。サーバは、ブラウザがフラグメントをサポートすることをブラウザが示したので、別々のフラグメントを返す。しかし、キャッシュ１およびキャッシュ２は、特にこのフラグメントがブラウザによって別々に要求されたので、２つの独立のＨＴＴＰオブジェクトをキャッシングしているかのように動作し、それでも、ブラウザおよびサーバは、「ｐ」および「ｃ」のコピーが関連することを知っている。ブラウザは、これらを、別々にキャッシングするが、必要な時に構成する。
【０１４３】
図９を参照すると、ブラウザは、フラグメントをサポートしないが、キャッシュ１およびキャッシュ２は、フラグメントをサポートする。この場合に、サーバは、キャッシュ２がフラグメント・サポートを示したので、別々のフラグメントを返す。キャッシュ２は、キャッシュ１がフラグメント・サポートを示したので、別々のフラグメントを返す。キャッシュ１は、ブラウザがフラグメント・サポートを示さなかったので、ブラウザに返す前に、「ｐ」フラグメントおよび「ｃ」フラグメントから最終的なページ「Ｐ（ｐ，ｃ）」を構成した。
【０１４４】
図１０を参照すると、ブラウザおよびキャッシュ２はフラグメントをサポートしないが、キャッシュ１はフラグメントをサポートする。サーバは、キャッシュ１がフラグメント・サポートを示し、その表示がＨＴＴＰヘッダ内でキャッシュ２を介して運ばれたので、別々のフラグメントを返した。キャッシュ２は、２つの独立のＨＴＴＰオブジェクトをキャッシングしているかのように働くが、ブラウザ、キャッシュ１、およびサーバは、別々のフラグメントが関連することを知っている。キャッシュ２は、フラグメントが別々に保管され、それらが関連することを知らないので、別々のフラグメントを渡した。キャッシュ１は、ブラウザがフラグメント・サポートを示さなかったので、フラグメント「ｐ」および「ｃ」を返す前に、これらから最終的なページ「Ｐ（ｐ，ｃ）」を構成した。
【０１４５】
図１１を参照すると、ブラウザおよびキャッシュ１は、フラグメントをサポートしないが、キャッシュ２はフラグメントをサポートする。サーバは、キャッシュ２がフラグメント・サポートを示したので、別々のフラグメントを返した。キャッシュ２は、ブラウザおよびキャッシュ１がフラグメント・サポートを示さなかったので、キャッシュ１に渡す前に、フラグメント「ｐ」および「ｃ」から最終的なページ「Ｐ（ｐ，ｃ）」を構成した。キャッシュ１およびブラウザは、構成されたフラグメントを、単一のＨＴＴＰオブジェクトすなわち最終的なページ「Ｐ（ｐ，ｃ）」として保管する。
【０１４６】
図１２を参照すると、単一のブラウザが、２つのブラウザ、ブラウザ１およびブラウザ２に置換されている。ブラウザ２が、親フラグメント「ｐ」にマッピングされるページを要求する。キャッシュ１は、ブラウザ２によって発行された「ｓｕｐｐｏｒｔｓ−ｆｒａｇｍｅｎｔｓ」ヘッダを担持する要求をキャッシュ２に転送する。キャッシュ２は、フラグメント「ｃ」のフラグメント・リンクと共にフラグメント「ｐ」をキャッシュ１に返し、キャッシュ１は、それをブラウザ２に返す。ブラウザ２は、フラグメント「ｐ」を構文解析し、子フラグメント「ｃ」の要求を発行する。
【０１４７】
潜在的な問題が生じるのは、フラグメント処理用にセット・アップされていないブラウザ１が、ページの要求を発行する場合である。ブラウザ１は、ブラウザ２によって発行されたものと同一のＵＲＩを含む要求を発行し、このＵＲＩは、フラグメント「ｐ」のキャッシュＩＤと一致する。キャッシュ１が、ｐフラグメントをキャッシングしている場合に、キャッシュ１は、フラグメント「ｃ」のＦＲＡＧＭＥＮＴＬＩＮＫタグを含むキャッシングされたフラグメントをブラウザ１に送信する。ブラウザ１は、ＦＲＡＧＭＥＮＴＬＩＮＫタグを理解しないので、これを無視し、これによって、不完全なページがレンダリングされることになる。
【０１４８】
この状況によって、フラグメントをサポートするエージェントと、フラグメントをサポートしないもう１つのエージェントの両方が、フラグメントをサポートしないキャッシュに接続される、図１３に全般的に示されたネットワーク内の構成が一般化される。ブラウザ２が、フラグメント「ｐ」を要求する場合に、フラグメントをサポートするキャッシュ１は、フラグメント「ｐ」および「ｃ」を受信し、それらを組み立て、その後、キャッシュ１は、ページ「Ｐ（ｐ，ｃ）」をブラウザ２に配信する。ブラウザ１からのキャッシュ１を介するフラグメント「ｐ」の後続の要求によって、組み立てられないページの配信がもたらされる可能性がある。
【０１４９】
この潜在的な問題を管理するために、ページ組立をサポートするサーバからのすべてのトップレベル・フラグメントによって、たとえば「Ｃａｃｈｅ−Ｃｏｎｔｒｏｌ：ｎｏ−ｃａｃｈｅ  ｆｒａｇｍｅｎｔｒｕｌｅｓ」を使用して、トップレベル・フラグメントをキャッシュ不能としてマークしなければならない。ページ組立をサポートするキャッシュは、このディレクティブの「ｆｒａｇｍｅｎｔｒｕｌｅｓ」を認識し、これによって、「ｎｏ−ｃａｃｈｅ」ディレクティブがオーバーライドされ、正しい挙動がオブジェクトに適用される。この状況を管理するために、トップレベル・フラグメントだけをキャッシュ不能としてマークしなければならないことに留意されたい。これは、ページ全体のＵＲＩがトップレベル・フラグメントのＵＲＩと同一なので生じる可能性がある曖昧さに起因する。すなわち、このＵＲＩによって、２つの異なるオブジェクトを参照することができる。組み込まれるフラグメントは、絶対に複数の形で存在せず、その結果、この曖昧さは、組み込まれるフラグメントについては発生しない。
【０１５０】
不適切なキャッシングの防止に関する考慮事項
真上で注記したように、ページ組立をサポートするサーバからのすべてのトップレベル・フラグメントは、キャッシュ不能としてトップレベル・フラグメントをマークしなければならない。これによって、フラグメントをサポートしないキャッシュが、他のフラグメントを含むトップレベル・フラグメントのキャッシングを試みるという潜在的な問題が防止されるが、これが試みられた場合には、図１３からわかるように、トップレベル・フラグメントに、フラグメント・サポート式キャッシュを含まないブラウザからのパスに沿ってアクセスでき、これによって、ＦＲＡＧＭＥＮＴＬＩＮＫタグによって指定されるコンテンツではなくＦＲＡＧＭＥＮＴＬＩＮＫタグを有するページが誤ってレンダリングされる。
【０１５１】
さらに、フラグメントをサポートしないキャッシュによって、通常は、キャッシュ・インデックス／キーとしてオブジェクトに関連するＵＲＩまたはＵＲＩパスが使用され、このオブジェクトが、キャッシュは知らないが、フラグメントである可能性がある。オブジェクトがフラグメントなので、フラグメントをサポートしないキャッシュ内のキャッシュＩＤとしてＵＲＩまたはＵＲＩパスだけを使用することが不適切になる可能性があり、フラグメント・サポート式キャッシュでは、キャッシュＩＤが、オブジェクトすなわちフラグメントに関連するフラグメント・キャッシング規則に従って形成される。言い換えると、フラグメントをサポートしないキャッシュは、すべてのキャッシングされるオブジェクトに関するそのキャッシュＩＤアルゴリズムに従ってキャッシュ・インデックスを定式化し続けるが、本発明の好ましい実施形態の技法では、フラグメント・キャッシング規則が使用されて、キャッシュ内のフラグメントの配置に関するキャッシュ・インデックスを生成する前に、キャッシュ可能フラグメントのキャッシュＩＤが形成されることが意図されている。したがって、フラグメントをサポートしないキャッシュは、おそらくは、そのオブジェクトを返すことができるが、これは、実際には、キャッシュ・ヒットの結果としての応答内のフラグメントである。さまざまなタイプの不正確さまたはレンダリング・エラーが、下流で発生する可能性がある。そのようなエラーを避けるために、不適切な時にはキャッシングを防がなければならない。
【０１５２】
一般に、フラグメント非サポート式キャッシュでのキャッシングは、「Ｃａｃｈｅ−Ｃｏｎｔｒｏｌ：ｎｏ−ｃａｃｈｅ  ｆｒａｇｍｅｎｔｒｕｌｅｓ」ヘッダを含めることと、「Ｐｒａｇｍａ：ｎｏ−ｃａｃｈｅ」ヘッダを含めることによって防ぐことができる。第２のヘッダによって、ＨＴＴＰ／１．１をサポートしないキャッシュに、フラグメントをキャッシュしないように指示するが、フラグメントをサポートするキャッシュは、ＨＴＴＰ／１．１もサポートする。上で短く注記したように、図１３に関して、第１のヘッダの「ｎｏ−ｃａｃｈｅ」ディレクティブによって、ＨＴＴＰ／１．１をサポートするがフラグメントをサポートしないキャッシュに、フラグメントをキャッシュしないことが指示され、「ｆｒａｇｍｅｎｔｒｕｌｅｓ」ディレクティブによって、フラグメントをサポートするキャッシュに、フラグメント・キャッシング規則の下でフラグメントをキャッシングしなければならないことが指示される。
【０１５３】
効率的なキャッシングに関する考慮事項
複数のユーザにまたがって共用される、製品記述または株式相場などのフラグメントについて、ブラウザとウェブ・アプリケーション・サーバの間のほとんどまたはすべてのキャッシュでのキャッシングを可能にすることが、最も効率的である。フラグメントは、各キャッシュが他のキャッシュにファン・アウトするツリー構造に沿って分散されるとみなすことができる。特定のフラグメントに関する第１要求によって、ユーザとウェブ・アプリケーション・サーバの間のパスに沿ってキャッシュが移植される。他のユーザによる同一フラグメントに関する後続要求によって、これらのキャッシュ内のフラグメントが見つかり、ウェブ・アプリケーション・サーバまでゆく必要がなくなる可能性がある。
【０１５４】
株式ウォッチリストなど、たとえばパーソナライズされたフラグメントであるユーザ固有のフラグメントについて、同一フラグメントに関する後続要求だけが、同一のパスに沿ったものになるので、エンド・ユーザに最も近いフラグメント・サポート式キャッシュでのみキャッシングを許可することが、最も効率的である。そうでなければ、これらのユーザ固有フラグメントに関する後続要求が、ユーザにより近いキャッシュによって満足されるのでその後続要求が絶対に中間キャッシュによって見られない場合であっても、中間キャッシュにユーザ固有フラグメントが充てんされ、これによって、共用フラグメントが中間キャッシュから消去される。
【０１５５】
「ｐｒｉｖａｔｅ」ディレクティブを有するＨＴＴＰ「Ｃａｃｈｅ−Ｃｏｎｔｒｏｌ」ヘッダは、以前に、ページのこの同一のユーザ固有特性を指定するのに使用され、その結果、ブラウザ・キャッシュだけがこれらをキャッシングするようになる。これと同一のヘッダが、本発明の好ましい実施形態によって、フラグメント・サポート式キャッシュに、ユーザに最も近いフラグメント・サポート式キャッシュ内でコンテンツをキャッシングするように指示するのに使用される。ユーザ固有フラグメントに「Ｃａｃｈｅ−Ｃｏｎｔｒｏｌ：ｐｒｉｖａｔｅ」を含めることが、最適の性能最適化であることに留意されたい。
【０１５６】
複合文書に関する考慮事項
フラグメント組立のためにフラグメントをフェッチする時には、ＨＴＴＰ要求を形成しなければならない。この応答のヘッダのほとんどを、トップレベル・フラグメントの応答ヘッダから継承することができる。しかし、一部の応答ヘッダによって、フェッチされる特定のオブジェクトが参照され、親フラグメントからこれらを継承する時には、注意が必要である。同様に、ほとんどの応答ヘッダを、破棄することができ、トップレベル・フラグメントに付随する応答ヘッダを、クライアントに応答を返す時に使用することができる。やはり、一部の応答ヘッダは、個々のオブジェクトに固有であり、文書全体の状態に影響する場合がある。
【０１５７】
このセクションでは、フラグメント組立でのＨＴＴＰ要求／応答ヘッダの処理に関する問題を論ずる。用語「下流伝搬」は、組込みオブジェクトに関する要求による、親またはトップレベル・フラグメントからの要求ヘッダの継承を指すのに使用される。用語「上流伝搬」は、組込みオブジェクトから親またはトップレベル・フラグメントへの応答ヘッダの解決を指すのに使用される。
【０１５８】
クッキーに関する複合文書に関する特殊な問題の１つが、ページ組立中に、元々の「ｓｅｔ−ｃｏｏｋｉｅ」応答ヘッダが使用不能になることである。結果のクッキー要求ヘッダだけが、クライアントから使用可能である。具体的に言うと、実際の「ｐａｔｈ」値、「ｄｏｍａｉｎ」値、および「ｅｘｐｉｒｅｓ」値のどれもが、使用不能である。入れ子のより浅いレベルのフラグメントによって、要求に伴うクッキーに課せられる制約を満たさない別のフラグメントが組み込まれる場合に、そのクッキーを子フラグメントに渡すことは、正しくない。元々の情報すべてが存在するのではないので、一般に、クッキーを渡すことが正しいかどうかを判定することは不可能である。同様に、入れ子になったフラグメントが、付随する「ｓｅｔ−ｃｏｏｋｉｅ」ヘッダを有する場合がある。そのクッキーの実際の値が、そのフラグメントのキャッシュＩＤの計算に必要になる可能性がある。さらに、クッキーの値が、入れ子のより深いレベルのフラグメントのフェッチに必要になる場合がある。しかし、そのような情報は、推論することができる。クッキーの「ｅｘｐｉｒｅｓ」部分が、まだ有効になっていないと仮定することができる。既に有効である場合には、クッキーは、要求に存在しない。ドメインが、要求内のドメインのある部分であると仮定することができ、パスが、要求内のパスのある部分であると仮定することができる。
【０１５９】
通常、ブラウザは、クッキーに対する制約を検査し、要求がその制約を満足しない場合には、そのクッキーは要求ヘッダに含まれない。しかし、ページを組み立てるキャッシュでは、付随するクッキーを有する文書に含まれるＦＲＡＧＭＥＮＴＬＩＮＫタグによって、元のクッキーの制約を満足しないＵＲＩが参照されることがありえる。ＦＲＡＧＭＥＮＴＬＩＮＫタグで参照されるオブジェクトは、親のクッキーが正しく評価されることを必要とするので、クッキーを、入れ子の浅いレベルのフラグメントから入れ子の深いレベルのフラグメントに伝搬させなければならない。ページ・アセンブラが、クッキーに対する制約を侵害する不正な形でクッキーを渡さないことを保証するためのガイドラインは、入れ子になったフラグメントのＵＲＩのパスおよびドメインが、トップレベル・フラグメントのパスおよびドメインの最も保守的な部分であることである。言い換えると、入れ子になたフラグメントのＵＲＩのドメインは、その親のドメインと一致するかそのスーパーセットでなければならず、ＵＲＩのパス部分は、その親のパスと一致するかそのスーパーセットでなければならない。これを、「クッキーの下流伝搬」と呼ぶことができる。
【０１６０】
対照的に、下記によって「クッキーの上流伝搬」が説明される。フラグメントがホストからフェッチされる時に、応答に「ｓｅｔ−ｃｏｏｋｉｅ」ヘッダが含まれることがありえる。このクッキー自体は、新たに返されるフラグメント内の入れ子のより深いレベルのフラグメントの正しい評価に必要である場合がある。したがって、ページ・アセンブラは、「ｓｅｔ−ｃｏｏｋｉｅ」ヘッダを、入れ子のより深いレベルのフラグメントのフェッチにおいて、「ｃｏｏｋｉｅ」ヘッダに変換しなければならない。この新しいクッキーは、少なくとも２つの理由すなわち、（１）サーバでの入れ子のより深いレベルのフラグメントの評価、および（２）最近にフェッチされたフラグメントまたはより深い入れ子になったフラグメントのキャッシュＩＤの生成に必要になる場合がある。クッキーがキャッシュＩＤ生成に必要な場合には、新しいクッキーを、組み立てられたページと共に要求元に送り返す必要がある。これは、そのクッキーが、そのページの次の要求に付随しなければならないから、または、キャッシングされたフラグメントを参照するページについて、サーバからのフェッチを試みる前に要求からキャッシュＩＤを計算するためである。
【０１６１】
入れ子になったフラグメントに関する要求の「ｓｅｔ−ｃｏｏｋｉｅ」ヘッダのクッキーを「ｃｏｏｋｉｅ」ヘッダに変換することによって、ユーザの代わりにクッキーを暗黙の内に受け入れる動作が構成される。この状況を扱うガイドラインには、（１）トップ・レベル・フラグメントが、既にその名前のクッキーを有しなければならず、（２）フラグメントのパスおよびドメインが、トップレベル・フラグメントのパスおよびドメインの最も保守的な部分に従わなければならないことが含まれる。
【０１６２】
これらの制約が満たされる場合に、新しい「ｓｅｔ−ｃｏｏｋｉｅ」ヘッダの効果は、単純に、既存のクッキーの値を変更することになる。アプリケーションの観点からは、これが、単純に、トップレベル・フラグメントに「ダミー」クッキーを付随させる必要が生じる可能性があることを意味する。これらの「ダミー」クッキーは、入れ子になったフラグメントのフェッチの処理中に、およびそのフラグメントの「ｓｅｔ−ｃｏｏｋｉｅ」ヘッダがユーザに伝搬される時に、値を更新される。
【０１６３】
複合文書に関するクッキー以外のもう１つの特別な考慮事項に、「ｉｆ−ｍｏｄｉｆｉｅｄ−ｓｉｎｃｅ」ヘッダが含まれる。「ｉｆ−ｍｏｄｉｆｉｅｄ−ｓｉｎｃｅ」ヘッダは、要求元によって、指定される日時以降にオブジェクトが変更されている場合に限ってオブジェクトを返さなければならないことを指定するのに使用される。オブジェクトが、その時以降に修正されていない場合には、オブジェクトが「新鮮」であると考えられ、通常はＨＴＴＰ  ３０４「Ｎｏｔ  Ｍｏｄｉｆｉｅｄ」応答がサーバから返され、これによって、より大きい応答本体を配送するのに必要な帯域幅が節約される。
【０１６４】
複合文書では、コンポーネントの一部が「新鮮」であるが他のコンポーネントが「古い」場合があり、他のコンポーネントの状況が、不確定である場合がある。コンポーネントのどれかを「新鮮」と判定できない場合には、文書全体を、完全な応答として返さなければならない（ＨＴＴＰ  ２００）。すべてのコンポーネントが「新鮮」と判定される場合には、ＨＴＴＰ  ３０４応答を返すことができる。しかし、フラグメントが新鮮であるかどうかを判定するために、コンポーネントのＨＴＴＰ応答コードに注意しながらページ組立を実行する必要がある場合がある。あるコンポーネントが「新鮮」である場合で、そのコンポーネントが葉ノードでない場合に、そのコンポーネントの内容が、入れ子になったコンポーネントを見つけ、フェッチするために必要である。
【０１６５】
したがって、ＨＴＴＰ  ３０４応答を返すキャッシュへの要求によって、ページ組立を継続できるようにするために、フラグメントのテキストも返さなければならない。たとえばキャッシュ・ミスの結果などのサーバへの要求は、「ｉｆ−ｍｏｄｉｆｉｅｄ−ｓｉｎｃｅ」ヘッダなしで発行しなければならない。というのは、そうでなければ、ページ組立を継続するのにフラグメントのテキストが必要である時に、サーバがＨＴＴＰ  ３０４応答を返す可能性があるからである。言い換えると、ＨＴＴＰ  ３０４応答によってクライアントへの無効な応答がもたらされる可能性があるので、複合文書に関する「ｉｆ−ｍｏｄｉｆｉｅｄ−ｓｉｎｃｅ」ヘッダを下流に伝搬させることはできない。
【０１６６】
複合文書に関するもう１つの特別な考慮事項は、「ｉｆ−ｍｏｄｉｆｉｅｄ−ｓｉｎｃｅ」ヘッダに関連する問題に似ているが、「ｌａｓｔ−ｍｏｄｉｆｉｅｄ」ヘッダに関する。ページ・アセンブラは、どのフラグメントが「ｌａｓｔ−ｍｏｄｉｆｉｅｄ」ヘッダを返したかを理解し、その結果を、構成されたページの最新の日付を有する１つの組み合わされた「ｌａｓｔ−ｍｏｄｉｆｉｅｄ」ヘッダにマージしなければならない。フラグメントのいずれかが「ｌａｓｔ−ｍｏｄｉｆｉｅｄ」ヘッダを返さない場合には、組み立てられたページ全体が、「ｌａｓｔ−ｍｏｄｉｆｉｅｄ」ヘッダを返さないことが必要である。これが重要であるのは、「ｌａｓｔ−ｍｏｄｉｆｉｅｄ」ヘッダがローカル・キャッシュのファイルと同一であることが通知される場合に、ブラウザが内容を無視するからである。
【０１６７】
たとえば、１つのダイナミック・コンテンツ（「ｌａｓｔ−ｍｏｄｉｆｉｅｄ」ヘッダなし）と「ｌａｓｔ−ｍｏｄｉｆｉｅｄ」ヘッダ付きの１つの静的コンテンツ（ＨＴＭＬからの）を含むページを検討されたい。このページを静的ページの「ｌａｓｔ−ｍｏｄｉｆｉｅｄ」ヘッダ付きで返した場合に、同一のページへの後続要求が、ブラウザによって無視され、ブラウザ・キャッシュからの古いページが表示される。言い換えると、すべてのフラグメントに「ｌａｓｔ−ｍｏｄｉｆｉｅｄ」ヘッダが含まれる場合に、それを上流に伝搬させ、すべての構成フラグメントの最も最近の修正時刻を反映するように調整しなければならない。フラグメントのいずれかに「ｌａｓｔ−ｍｏｄｉｆｉｅｄ」ヘッダが欠けている場合には、「ｌａｓｔ−ｍｏｄｉｆｉｅｄ」ヘッダを返してはならない。
【０１６８】
プログラミング・モデルに関する考慮事項
本発明の好ましい実施形態によって、分散フラグメント・キャッシングの技法が説明される。しかし、すべてのウェブ・アプリケーション・サーバ・プログラミングによってこれを使用して、たとえば中間のサーバおよびブラウザに、キャッシング機能を委譲できるようにするために、できる限り中立であることが意図されている。本発明の好ましい実施形態では、やはりプログラミング・モデル中立である、ＨＴＭＬに対する拡張すなわちＦＲＡＧＭＥＮＴＬＩＮＫタグと、ＨＴＴＰに対する拡張すなわち新しいフラグメント・キャッシング・ヘッダが使用される。
【０１６９】
フラグメントをプログラミングする時に、ウェブ・アプリケーション開発者は、下記の２タイプの情報を指定しなければならない。
１．インクルード機構。これによって、どのフラグメントを含めるかと、別のフラグメントのどこに含めるかが指定される。ページ上の位置が重要なので、これは、コード、たとえばＪＳＰテンプレートまたはサーブレットクラスに組み込まれなければならない。
２．キャッシング制御メタデータ。これによって、たとえばタイム・リミットなど、フラグメントの条件が指定される。この情報は、コードに組み込むか、たとえばＪＳＰファイル名またはサーブレット・クラスなど、テンプレート名に関連付けることによって別々に指定することができる。
【０１７０】
本発明の好ましい実施形態を実施するのにＪ２ＥＥプログラミング・モデルが使用される場合に、この２つの特徴を、下記の機構によってサポートすることができる。
１．インクルード機構に関して、Ｊ２ＥＥプログラミング・モデルは、既に、たとえば「ｊｓｐ：ｉｎｃｌｕｄｅ」タグまたは「ＲｅｑｕｅｓｔＤｉｓｐａｔｃｈｅｒ．ｉｎｃｌｕｄｅ」メソッドなど、インクルードされるフラグメントを指定するための、ウェブ・アプリケーション・サーバ内のインクルード構造を有する。適当な時に、Ｊ２ＥＥランタイムを修正して、Ｊ２ＥＥインクルード構造をＦＲＡＧＭＥＮＴＬＩＮＫタグに書き直すことができる。
２．キャッシング制御情報を、システム管理コンソールから指定することができ、コードに組み込むのではなく、各フラグメントのテンプレート／クラスに関連付けることができる。ウェブ・アプリケーション・サーバによって、この情報を適当なヘッダに挿入することができる。この手法は、この情報をコードに入れることに対して、下記の長所を有する。
Ａ．これによって、コードに焼き込まれるのでプログラマをかかわらせるのではなく、管理コンソールを介して動的に変更を行えるようになる。
Ｂ．これによって、Ｊ２ＥＥプログラミング・モデルに新しい機構が組み込まれなくなる。
【０１７１】
Ｊ２ＥＥインクルード構造のＦＲＡＧＭＥＮＴＬＩＮＫタグへの書き直しは、下記の考慮事項を必要とする。照会パラメータに関するＪ２ＥＥセマンティクスでは、すべての照会パラメータが親フラグメントから子フラグメントに再帰的に渡されることが要求される。Ｊ２ＥＥウェブ・アプリケーション・サーバが、ＦＲＡＧＭＥＮＴＬＩＮＫタグを生成する時に、ＳＲＣ属性を、親の照会パラメータを付加されたＪ２ＥＥインクルードのＵＲＩにしなければならない。非Ｊ２ＥＥウェブ・アプリケーション・サーバは、そのプログラミング・モデルと整合するＳＲＣ属性を生成する。この形で、アプリケーション・コードが見る要求がどちらの場合でも同一になるので、代理が存在するか否かに無関係に、同一のセマンティクスが発生する。ＦＲＡＧＭＥＮＴＬＩＮＫタグは、たとえばＡＬＴ、ＦＯＲＥＡＣＨ、ＳＨＯＷＬＩＮＫ、ＩＤ、およびＣＬＡＳＳなど、対応する「ｊｓｐ：ｉｎｃｌｕｄｅ」属性を有しない複数の属性を有する。Ｊ２ＥＥ環境で使用されるために、これらの特徴は、「ｊｓｐ：ｉｎｃｌｕｄｅ」に対する拡張を必要とする。
【０１７２】
異なるウェブ・アプリケーション・サーバが、入れ子になったフラグメントをインクルードする、類似するが異なる機構を有する他のプログラミング・モデル（たとえばＡＳＰ）をサポートすることができる。これらのプログラミング・モデルのそれぞれについて、ウェブ・アプリケーション・サーバは、そのプログラミング・モデルの規則と整合するＦＲＡＧＭＥＮＴＬＩＮＫタグを生成しなければならない。
【０１７３】
無効化に関する考慮事項
キャッシュを最新状態に保つために、内容がもはや有効でなくなった時に、項目を無効化するか上書きする必要がある。無効化は、時間に基づくか、外部イベントによってトリガされるかのいずれかとすることができる。時間は、キャッシュ内の最大寿命、たとえば１０分以内か、絶対時刻、たとえば２００１年２月５日正午までのいずれかとすることができる。最大寿命は、標準ＨＴＴＰ「Ｃａｃｈｅ−Ｃｏｎｔｒｏｌ」ヘッダとＨＴＴＰ「ｍａｘ−ａｇｅ」ディレクティブを使用して指定される。絶対時刻は、標準ＨＴＴＰ「Ｅｘｐｉｒｅｓ」ヘッダを使用して指定される。
【０１７４】
例として、製品の説明を古くなるのに１０分までとすることが許容可能であろう。これは、「Ｃａｃｈｅ−Ｃｏｎｔｒｏｌ：ｍａｘ−ａｇｅ＝６００」として指定され、これは、このフラグメントが６００秒までキャッシュに留まることを意味する。もう１つの例として、セールを、２００１年１２月２４日月曜日東部標準時午後１１時００分まで続けることができる。これは、「Ｅｘｐｉｒｅｓ＝Ｍｏｎ，  ２４  Ｄｅｃ  ２００１  ２３：００：００  ＥＳＴ」として指定される。どちらの場合でも、フラグメントを、新しいフラグメントための余地を作るために、キャッシュの置換アルゴリズムによってキャッシュから除去することができる。
【０１７５】
イベントによってトリガされる無効化について、アプリケーション・サーバによって、無効化が開始される。アプリケーション・サーバは、データベース・トリガ、更新するＨＴＴＰ要求によって呼び出されるアプリケーション・プログラミング・インターフェース（ＡＰＩ）、またはコンテンツが古くなったことを判定する他の機構を使用することができる。
【０１７６】
本発明の好ましい実施形態の技法は、さまざまな無効化技法に対して開かれている。同様に、フラグメント・サポート式キャッシュに無効化メッセージを送信するのにアプリケーション・サーバによって使用されるプロトコルは、本発明の好ましい実施形態の技法によって指定されない。
【０１７７】
フラグメントの依存性は、フラグメントを作成するのに使用された基礎になるデータの識別子である。依存性の例として、複数のページによって、同一の基礎になるユーザ・プロファイルが使用されるが、そのユーザ・プロファイルの異なるサブセットが使用されるので、またはそれらが異なる形でフォーマットされるので、異なるフラグメントが使用される場合がある。アプリケーションは、ユーザ・プロファイルと、それを使用するフラグメントのすべてとの間のマッピングを判定し、ユーザ・プロファイルが変更された時に、必ずこれらのキャッシュＩＤを構築することができる。しかし、このマッピングを、各依存性のソースであるフラグメントのそれぞれの中で突き止めさせることが、よりよいソフトウェア・エンジニアリングである。これによって、アプリケーションが、ユーザ・プロファイルに関連するユーザＩＤを使用して単純に無効化でき、キャッシュに、そのユーザＩＤに依存するすべてのフラグメントを無効化させることができるようになる。ユーザ・プロファイルを使用する新しいフラグメントが追加されるか、ユーザ・プロファイルを使用するフラグメントが除去される時には、依存性が、そのフラグメントにローカルであり、アプリケーションの無効化機構は変更されない。たとえば、この依存性を、下記の形で特定のユーザ・プロファイルについて宣言することができる。
Fragment:dependencies="http://www.acmeStore.com_userID=@($*!%"
【０１７８】
複数の依存性は、スペースによって区切られたリストとして指定される。依存性は、大文字小文字の区別がある。フラグメント・サポート式キャッシュを用いると、これらの依存性に基づいて無効化を行えるようになる。
【０１７９】
キャッシュ項目を無効化するための上書き手法を使用するためには、新しヘッダ情報は不要である。フラグメント・サポート式キャッシュは、新しいキャッシュ項目を追加できるようにするプロトコルを必要とする。上で述べた無効化プロトコルと同様に、この上書きプロトコルは、本発明の好ましい実施形態の教示によって指定されない。
【０１８０】
セキュリティ問題に関する考慮点
潜在的なセキュリティ要件が、フラグメントをサポートするキャッシュによって尊重されなければならない。ユーザが、ブラウザのようなアプリケーションを操作し、ＵＲＩをクリックする時に、ユーザは、使用されるＵＲＩまたはユーザのクッキーで供給されるすべての情報が、アプリケーションのセキュリティ・ポリシに従って扱われるものとしてアプリケーション設計者を信頼する。ＦＲＡＧＭＥＮＴＬＩＮＫタグを用いて、アプリケーション設計者は、この情報の正しい使用の責任の一部をキャッシュに委譲する。本発明の好ましい実施形態に従って実施されるキャッシュによって、ＦＲＡＧＭＥＮＴＬＩＮＫタグをその親以外のドメインにリンクできないという規則が実施されなければならない。
【０１８１】
他のフラグメントを含むページは、最終的に、完全に展開されたページに組み立てられ、これは、ブラウザとアプリケーション・サーバの間のパスに沿ったどの場所でも行われる可能性がある。セキュリティを保証するために、アプリケーション設計者は、次の規則を厳守しなければならない：フラグメントにＨＴＴＰＳを必要とする別のフラグメントが含まれる場合に、そのフラグメントはＨＴＴＰＳを必要とする。この規則は、再帰的に適用されなければならず、その結果、トップレベル・フラグメントまでのすべてに伝搬される。この規則によって、保護されたフラグメントが、保護されないフラグメントの内部で見られることがなくなる。
【０１８２】
ＨＴＴＰＳ要求に関して、「ｓｕｐｐｏｒｔｓ−ｆｒａｇｍｅｎｔｓ」ディレクティブを含むＦＲＡＧＭＥＮＴヘッダは、キャッシュがＨＴＴＰＳセッションを終了できる場合に限って含まれなければならない。そうでなければ、ＨＴＴＰＳセッションを処理するためにＦＲＡＧＭＥＮＴＬＩＮＫを見ることができない。ＨＴＴＰＳを終了させないキャッシュは、それでも、ＨＴＴＰ要求のフラグメントをサポートすることができる。
【０１８３】
フラグメント・サポート式キャッシュに関するキャッシュ管理ユニットの説明
図１４に関して、ブロック図によって、本発明の好ましい実施形態によるコンピューティング・デバイス内のフラグメント・サポート式キャッシュのキャッシュ管理ユニットを示す。コンピューティング・デバイス６００は、クライアント、サーバ、またはおそらくはクライアント機能とサーバ機能の両方を有するものとすることができるが、コンピューティング・デバイス６００には、フラグメント・サポート式キャッシュ管理ユニット６０２が含まれ、このキャッシュ管理ユニット６０２には、コンピューティング・デバイス６００の代わりにオブジェクトをキャッシングする機能性が含まれる。たとえば、キャッシュ管理ユニット６０２は、他のキャッシュ対応デバイスの間のデータ・パス上の中間キャッシュとして働くことができ、他の場合に、キャッシュ管理ユニット６０２は、エンドユーザの代わりにクライアント・デバイス内のオブジェクトをキャッシングすることができる。
【０１８４】
フラグメント・サポート式キャッシュ管理ユニット６０２に、オブジェクトを保管／キャッシングするオブジェクト・データベース６０４が含まれ、オブジェクト・データベース６０４に、オブジェクトに関連するメタデータおよびオブジェクトと共に受信されたネットワーク・ヘッダを含めることができる。フラグメント・サポート式キャッシュ管理ユニット６０２には、キャッシュ管理動作に関連する情報を保管するデータベースも含まれ、このデータベースは、ここで言及するが、下で図１５から１７に関して詳細に説明する。ｒｕｌｅｌｉｓｔデータベース６０６に、ＵＲＩパス６０８およびそれに関連するｒｕｌｅｌｉｓｔ６１０が保管される。キャッシュＩＤデータベース６１２に、キャッシュＩＤ６１４およびそれに関連するキャッシュ・インデックス６１６が保管される。依存性データベース６１８に、依存ＩＤとキャッシュＩＤの間のマッピングが保管される。複数のキャッシュＩＤを、単一の依存性に関連付けることができ、複数の依存性を、単一のキャッシュＩＤに関連付けることができる。
【０１８５】
フラグメント・サポート式キャッシュのキャッシュ管理ユニット内の処理の一部の説明
図１５に関して、流れ図によって、本発明の好ましい実施形態による、フラグメントを含む応答メッセージを処理する時にフラグメント・サポート式キャッシュ管理ユニットによって使用することができる処理を示す。言い換えると、図１５には、応答メッセージ内のオブジェクトをフラグメント・サポート式キャッシュで処理するかキャッシングするかその両方を行わなければならないかどうかと、その方法を判定するのに使用することができる処理が示されている。
【０１８６】
この処理は、図１４に示されたものなどの、フラグメント・サポート式キャッシュ管理ユニットを含むコンピューティング・デバイスによって、ＨＴＴＰ応答メッセージなどの応答メッセージが受信される時に開始される（ステップ６００２）。その後、キャッシュ管理ユニットが、メッセージ本体または応答メッセージ内のペイロード部分を、フラグメントまたは非フラグメントのどちらとして処理しなければならないかに関する判定を行う（ステップ６００４）。
【０１８７】
応答メッセージを、非フラグメントを含むものとして処理しなければならない場合に、非フラグメント・オブジェクトを、このコンピューティング・デバイスでキャッシングしなければならず、キャッシングできるか否か、すなわち、キャッシュ管理ユニットによってキャッシングするか否かに関する判定を（ステップ６００６）、既存のＨＴＴＰ１．１規則を使用して行う。たとえば、非フラグメント・オブジェクトを含む応答メッセージが、それをキャッシングしてはならないことの表示を有する場合がある、すなわち、ＨＴＴＰ応答メッセージ内で、「Ｃａｃｈｅ−Ｃｏｎｔｒｏｌ」ヘッダが「ｎｏ−ｃａｃｈｅ」ディレクティブを有する場合がある。オブジェクトをキャッシングしなければならず、それをキャッシングすることが可能である場合には、そのオブジェクトが、キャッシュ管理ユニットによって適当に保管される（ステップ６００８）。どちらの場合でも、そのオブジェクトに関するキャッシング動作が完了し、この処理は、分岐して、応答メッセージに関する他の動作を完了する。
【０１８８】
応答メッセージを、フラグメントを含むものとして処理しなければならない場合に、フラグメントがキャッシュ可能であるかどうかに関する判定を行う（ステップ６０１０）。そうでない場合には、この処理は、分岐して、応答メッセージに関する他の動作を完了する。フラグメントがキャッシュ可能である場合には、この特定のフラグメントをこの特定のコンピューティング・デバイスのキャッシュにキャッシングしなければならないかどうかに関する判定を行う（ステップ６０１２）。そうでない場合には、この処理は、分岐して、応答メッセージに関する他の動作を完了する。現在処理されつつあるフラグメントを、現在のコンピューティング・デバイスでキャッシングしなければならない場合には、そのフラグメントが、キャッシュ管理ユニットによってコンピューティング・デバイスのキャッシュに保管される（ステップ６０１４）。
【０１８９】
フラグメントがキャッシングされたか、現在のコンピューティング・デバイスでキャッシングされないと判定されたか、キャッシュ不能と判定された場合のどれであっても、次に、応答メッセージを転送する前に、フラグメントについてページ組立が必要であるかどうかに関する判定を行う（ステップ６０１６）。ページ組立が必要である場合には、ページ組立を実行する（ステップ６０１８）。どちらの場合でも、応答メッセージからのフラグメント・オブジェクトまたは非フラグメント・オブジェクトが、現在のコンピューティング・デバイスのキャッシュ管理ユニットによって完全に処理されており、応答メッセージが、必要な場合に修正され、その宛先に向かって転送され（ステップ６０２０）、これによってこの処理が完了する。
【０１９０】
図１６に関して、流れ図ステップによって、メッセージ本体にフラグメント・オブジェクトが含まれるか否かを判定する好ましい方法を示す。図１６は、図１５のステップ６００４と置換することができるステップを表す。好ましい実施形態では、受信された応答メッセージに、ペイロードまたはメッセージ本体をフラグメントとして識別するメッセージ／プロトコル・ヘッダが含まれるか否かが判定される（ステップ６０２２）。具体的に言うと、図６に示されているように、ＦＲＡＧＭＥＮＴヘッダをＨＴＴＰメッセージ内に配置して、メッセージのペイロードにフラグメント・オブジェクトが含まれることを示すことができる。
【０１９１】
図１７に関して、流れ図ステップによって、フラグメント・オブジェクトがキャッシュ可能であるか否かを判定するより具体的な方法を示す。図１７は、図１５のステップ６０１０と置換することができるステップを表す。この実施形態では、受信した応答メッセージに、フラグメントをキャッシュ可能として識別するキャッシュ制御用のプロトコル・ヘッダのディレクティブが含まれるか否かが判定される（ステップ６０２４）。
【０１９２】
図１８に関して、流れ図ステップによって、フラグメント・オブジェクトがキャッシュ可能であるか否かを判定する好ましい方法を示す。図１７に類似する形で、図１８は、図１５のステップ６０１０と置換することができるステップを表す。好ましい実施形態では、受信した応答メッセージが、フラグメント・サポート式キャッシュでキャッシュ可能として、およびフラグメント非サポート式キャッシュでキャッシュ不能としてフラグメントを識別するメッセージ／プロトコル・ヘッダのディレクティブを有するか否かが判定される（ステップ６０２６）。具体的には、上で説明したように、「Ｃａｃｈｅ−Ｃｏｎｔｒｏｌ」ヘッダを、ＨＴＴＰメッセージに含めることができ、オブジェクトのキャッシングを防ぐために「Ｃａｃｈｅ−Ｃｏｎｔｒｏｌ」ヘッダに「ｎｏ−ｃａｃｈｅ」ディレクティブを配置することが、標準的な実践であり、本発明の好ましい実施形態では、フラグメント非サポート式キャッシュについてこの実践が維持されるが、「Ｃａｃｈｅ−Ｃｏｎｔｒｏｌ」ヘッダの使用を拡張することよって、メッセージ内のフラグメントがフラグメント・キャッシング規則に従ってキャッシュ可能であることを示す「ｆｒａｇｍｅｎｔｒｕｌｅｓ」ディレクティブが含まれる。
【０１９３】
図１９に関して、流れ図によって、フラグメント・オブジェクトを特定のコンピューティング・デバイスのキャッシュでキャッシングしなければならないか否かを判定する方法を示す。図１９には、図１５のステップ６０１２および６０１４と置換することができる処理が示されており、この処理が呼び出される時に、応答メッセージにキャッシュ・フラグメントが含まれることが既に判定されている。
【０１９４】
この処理は、下流デバイスがフラグメント・サポート式キャッシュを有するか否かを判定することによって開始される（ステップ６０２８）。下流デバイスは、現在のコンピューティング・デバイスが応答メッセージを転送するコンピューティング・デバイスである。下流デバイスが、フラグメント・サポート式キャッシュを有しない場合には、現在のコンピューティングのキャッシュ管理ユニットが、現在処理されつつあるフラグメント・オブジェクトをキャッシングし（ステップ６０３０）、処理が完了する。
【０１９５】
下流デバイスが、フラグメント・サポート式キャッシュを有する場合には、現在処理されつつあるフラグメント・オブジェクトを、宛先ユーザ／クライアント・デバイスに最も近いフラグメント・サポート式キャッシュでのみキャッシングしなければならないか否かに関する判定を行う（ステップ６０３２）。そうでない場合には、現在のフラグメント・オブジェクトを、現在のコンピューティング・デバイスでもキャッシングすることができ、この処理は、ステップ６０３０に分岐して、そのフラグメントをキャッシングする。しかし、フラグメントを、宛先ユーザ／クライアント・デバイスに最も近いフラグメント・サポート式キャッシュでのみキャッシングしなければならない場合には、現在のコンピューティング・デバイスは、そのフラグメントをキャッシングせず、処理が完了する。
【０１９６】
図２０に関して、流れ図ステップによって、下流デバイスがフラグメント・サポート式キャッシュを有するか否かを判定する好ましい方法を示す。図２０は、図１９のステップ６０２８と置換することができるステップを表す。図１９および図２０に、応答メッセージを受信した後に開始される処理が示されており、応答メッセージは、現在のコンピューティング・デバイスによる要求メッセージの以前の受信および転送の結果として受信されるものである。したがって、キャッシュ管理ユニットによって、応答メッセージが受信される時に、前に受信された要求メッセージに関する何らかの形の状態情報が維持されている。
【０１９７】
下流デバイスがフラグメント・サポート式キャッシュを有するか否かの判定に関して、好ましい実施形態では、前に受信した要求メッセージに、フラグメントがサポートされることを示すディレクティブを有するメッセージ／プロトコル・ヘッダが含まれたか否かを判定する（ステップ６０３４）。具体的に言うと、図６からわかるように、ＦＲＡＧＭＥＮＴヘッダをＨＴＴＰメッセージに配置することができ、ＦＲＡＧＭＥＮＴヘッダに、「ｓｕｐｐｏｒｔｓ−ｆｒａｇｍｅｎｔｓ」ディレクティブを含めることができる。
【０１９８】
図２１に関して、流れ図ステップによって、現在処理されつつあるフラグメント・オブジェクトを、宛先ユーザ／クライアント・デバイスに最も近いフラグメント・サポート式キャッシュでのみキャッシングしなければならないか否かを判定する、より具体的な方法を示す。図２１は、図１９のステップ６０３２と置換することができるステップを表す。この実施形態では、現在のコンピューティング・デバイスによって現在処理されつつある応答メッセージが、この応答メッセージのフラグメントを宛先ユーザ／デバイスに最も近いフラグメント・サポート式キャッシュでのみキャッシングしなければならないことを示す起点サーバからのディレクティブを含むメッセージ／プロトコル・ヘッダを有する。
【０１９９】
図２２に関して、流れ図ステップによって、現在処理されつつあるフラグメント・オブジェクトを、宛先ユーザ／クライアント・デバイスに最も近いフラグメント・サポート式キャッシュでのみキャッシングしなければならないかどうかを判定する、好ましい方法を示す。図２１に類似する形で、図２２は、図１９のステップ６０３２と置換することができるステップを表す。好ましい実施形態では、現在のコンピューティング・デバイスによって現在処理されつつある応答メッセージが、応答メッセージ内のフラグメントを宛先ユーザ／デバイスに最も近いフラグメント・サポート式キャッシュでのみキャッシングしなければならないことをフラグメント・サポート式キャッシュに示す起点サーバからの「ｐｒｉｖａｔｅ」ディレクティブを含むＨＴＴＰ「Ｃａｃｈｅ−Ｃｏｎｔｒｏｌ」メッセージ／プロトコル・ヘッダを有する。
【０２００】
図２３に関して、流れ図によって、現在のコンピューティング・デバイスから応答メッセージを返す前にページ組立が必要であるか否かを判定する方法を示す。図２３は、図１５のステップ６０１６および６０１８と置換することができる処理を示し、この処理が呼び出される時には、応答メッセージからのフラグメントが、必要な場合には既にキャッシングされている。
【０２０１】
この処理は、たとえば図１９のステップ６０２８に類似する形で、下流デバイスがフラグメント・サポート式キャッシュを有するか否かを判定することによって開始される（ステップ６０４０）。下流デバイスが、フラグメント・サポート式キャッシュを有する場合には、ページ組立は不要であり、この処理は完了する。下流デバイスがフラグメント・サポート式キャッシュを有しない場合には、現在処理されつつあるフラグメントが、別のフラグメントへのリンクを有するか否かを判定する（ステップ６０４２）。そうでない場合には、ページ組立は不要であり、この処理は完了する。別のフラグメントへのリンクが現在のフラグメントに存在する場合には、ページ組立を実行し（ステップ６０４４）、処理が完了する。
【０２０２】
図２４に関して、流れ図ステップによって、現在処理されつつあるフラグメント・オブジェクトが、別のフラグメントへのリンクを有するか否かを判定する、より具体的な方法を示す。図２４は、図２３のステップ６０４２と置換することができるステップを表す。この実施形態では、現在のフラグメントが、インクルードされるフラグメントのソース識別子またはソース位置を示すタグ付き要素を含むマークアップ言語要素を有するかどうかに関する判定が行われる（ステップ６０４６）。具体的に言うと、図５に示されているように、ＦＲＡＧＭＥＮＴＬＩＮＫ要素をＨＴＭＬオブジェクトの本体に配置して、別のフラグメントへのリンクを示すことができる。ＨＴＴＰ仕様では、ソース識別子を、「Ｒｅｑｕｅｓｔ−ＵＲＩ」と称し、これは、要求に適用されるリソースを識別する識別子である。
【０２０３】
図２５に関して、流れ図ステップによって、現在処理されつつあるフラグメント・オブジェクトが、別のフラグメントへのリンクを有するか否かを判定する、代替の方法を示す。図２４に類似する形で、図２５は、図２３のステップ６０４２と置換することができるステップを表す。この代替実施形態では、現在処理されつつある応答メッセージに、応答メッセージのメッセージ本体内のフラグメントすなわち現在処理されつつあるフラグメントが別のフラグメントへのリンクを有することを示すディレクティブを伴うメッセージ／プロトコル・ヘッダが含まれるかどうかの判定が行われる（ステップ６０４８）。これは、フラグメントからＦＲＡＧＭＥＮＴＬＩＮＫをスキャンすることによって判定することができる。しかし、応答ヘッダを使用してこれを示し、不要なスキャンを回避することが、はるかに効率的である。具体的に言うと、図６に示されているように、ＦＲＡＧＭＥＮＴヘッダをＨＴＴＰメッセージ内に配置することができ、そのＦＲＡＧＭＥＮＴヘッダに、「ｃｏｎｔａｉｎｓ−ｆｒａｇｍｅｎｔｓ」ディレクティブを含めることができる。このディレクティブを用いると、現在のコンピューティング・デバイスのキャッシュ管理ユニットが、現在のフラグメントのスキャンに先立って、ＦＲＡＧＭＥＮＴＬＩＮＫ要素を検索できるようになる。
【０２０４】
図２６に関して、流れ図によって、ページ組立を実行する処理を示す。図２６は、図１５のステップ６０１８または図２３のステップ６０４４と置換することができるステップを表す。この処理は、現在のフラグメントにインクルードされるリンクされたフラグメントのソース識別子、たとえばＵＲＩを応答メッセージから得ることによって開始される。次に、ソース識別子を使用して、リンクされたフラグメントを取り出す（ステップ６０５２）。取り出されたフラグメントおよび応答メッセージからの現在のフラグメントを組み合わせて、組み立てられたページすなわち新しいフラグメントを形成し（ステップ６０５４）、処理が完了する。
【０２０５】
フラグメントのコンテンツの組合せは、フラグメントのコンテンツ・タイプに関するエンコーディング規則に依存する。たとえば、マークアップ言語の各要素を、フラグメントとみなすことができ、親要素の区切りタグ内にタグ付き要素を挿入することによって、子要素を親要素に組み込むことができる。しかし、フラグメントの組合せは、下で詳細に説明するように、フラグメントのヘッダおよびプロパティ値を組み合わせる形の考慮も必要とする。
【０２０６】
図２７に関して、流れ図によって、任意選択としてフラグメント・リンクを複数のフラグメント・リンクに展開する処理を示す。図２６に戻って、現在のフラグメントに、複数のフラグメント・リンクが含まれる場合に、ステップ６０５０および６０５２を、複数のリンクされたフラグメントを取り出すのに必要な回数だけ繰り返すことができ、それらのフラグメントのすべてを組み合わせて単一の組み立てられたページを形成することができる。対照的に、図２７には、組み立てられたページを形成するために組み合わされる複数のフラグメントへの参照を含めるために単一のフラグメント・リンクをコンパクトに表すことができる処理が示されている。
【０２０７】
この処理は、応答メッセージからの現在のフラグメント内のフラグメント・リンクによって、これを複数のフラグメント・リンクに展開しなければならないことが示されるか否かの判定から始まる（ステップ６０６２）。そうでない場合には、処理が完了し、そうである場合には、フラグメント・リンクに関連する情報を使用して、フラグメント・リンクを複数のフラグメント・リンクの組に展開する（ステップ６０６４）。
【０２０８】
次に、複数のフラグメント・リンクをループで処理する。複数のフラグメント・リンクの組の次のフラグメント・リンクを入手し（ステップ６０６６）、そのフラグメント・リンクのソース識別子を入手する（ステップ６０６８）。識別されたフラグメントを、そのソース識別子を使用して取り出す（ステップ６０７０）。複数のフラグメント・リンクの組に別のフラグメント・リンクがあるかどうかに関する判定を行い（ステップ６０７２）、そうである場合には、処理はステップ６０６６に分岐して、別のフラグメント・リンクを処理する。残りのフラグメント・リンクがない場合すなわち、すべてのフラグメントが取り出されている場合には、取り出されたフラグメントのすべてを、元々の応答メッセージからのフラグメントと組み合わせ（ステップ６０７４）、処理が完了する。
【０２０９】
図２８に関して、流れ図ステップによって、応答メッセージからの現在のフラグメントのフラグメント・リンクが、これを複数のフラグメント・リンクに展開しなければならないことを示すか否かを判定する好ましい方法を示す。図２８は、図２７のステップ６０６２と置換することができるステップを表す。好ましい実施形態では、応答メッセージからのフラグメント内のフラグメント・リンクのマークアップ言語タグ付き要素に、フラグメント・リンクを展開しなければならないことを示す属性が含まれるか否かの判定が行われる（ステップ６０７６）。具体的に言うと、図５に示されているように、ＦＲＡＧＭＥＮＴＬＩＮＫがＦＯＲＥＡＣＨ属性を有することができる。
【０２１０】
図２９に関して、流れ図によって、フラグメント・リンクに関連する情報に従ってフラグメント・リンクを複数のフラグメント・リンクに展開する処理を示す。図２９は、図２７のステップ６０６４と置換することができる一連のステップを表す。
【０２１１】
この処理は、フラグメント・リンクに含まれるマークアップ言語タグ付き要素からクッキー名を得ることによって開始される（ステップ６０７８）。図５に示されているように、ＦＯＲＥＡＣＨ属性によって、クッキーの名前として解釈される文字列を供給することができる。クッキーの値を取り出す（ステップ６０８０）。クッキーの値は、名前／値対のリストを表す文字列であり、これがループで処理される。クッキー値から次の名前／値対を取り出し（ステップ６０８２）、たとえば照会パラメータとして名前／値対を使用して、名前／値対を使用することによってフラグメント・リンクを生成する（ステップ６０８４）。クッキー値に別の名前／値対があるかどうかに関する判定を行い（ステップ６０８６）、そうである場合には、この処理はステップ６０８２に分岐して、別の名前／値対を処理する。たとえば、名前／値対ごとにＦＲＡＧＭＥＮＴＬＩＮＫ要素を生成することができ、これによって、元のＦＲＡＧＭＥＮＴＬＩＮＫ要素が、元のＦＲＡＧＭＥＮＴＬＩＮＫ要素と置換される複数のＦＲＡＧＭＥＮＴＬＩＮＫ要素の組に展開される。残りの名前／値対がない場合には、処理が完了する。
【０２１２】
図３０に関して、流れ図によって、フラグメントのソース識別子を使用するフラグメントの取出しの処理を示す。図３０は、図２６のステップ６０５２および図２７のステップ６０７０と置換することができる処理を表し、図３０の処理は、フラグメントのソース識別子が既に判定された後に開始される。
【０２１３】
この処理は、現在のコンピューティング・デバイスのローカル・キャッシュ内でソース識別子とのキャッシュ・ヒットがあるか否かの判定から始まる（ステップ６０９２）。そうである場合には、キャッシュからフラグメントを取り出すことができ（ステップ６０９４）、取り出されたフラグメントを、呼出し側ルーチンに返す（ステップ６０９６）。取り出されたフラグメントに、フラグメント・リンクが含まれる場合には、この処理はステップ６０９２にループ・バックして、フラグメント・リンクによって識別されるフラグメントを取り出し（ステップ６０９８）、これによって、すべての子フラグメントを取り出すためにこの処理が継続される。
【０２１４】
ステップ６０９２で、ローカル・キャッシュ内でソース識別子に関するキャッシュ・ミスがあった場合には、要求メッセージを、生成し（ステップ６１００）、宛先識別子としてソース識別子を使用して送信する（ステップ６１０２）。図６に関して説明したように、現在のコンピューティング・デバイスにフラグメント・サポート式キャッシュ管理ユニットが含まれるので、要求メッセージに、「ｓｕｐｐｏｒｔｓ−ｆｒａｇｍｅｎｔｓ」ディレクティブが含まれる。キャッシュ管理ユニットは、要求メッセージに対する応答を待つ（ステップ６１０４）。要求のためにスレッドが作成され、このスレッドが、コンピューティング・デバイスが他の動作を実行している間に、応答を待ってスリープすることが好ましい。
【０２１５】
応答メッセージが受信された後に、応答メッセージのメッセージ本体内のフラグメントを取り出し（ステップ６１０６）、キャッシングする（ステップ６１０８）。上で述べたように、取り出されたフラグメントが、呼出し側ルーチンに返され、取り出されたフラグメントにフラグメント・リンクが含まれる場合には、この処理は、ステップ６０９２にループ・バックして、フラグメント・リンクによって識別されるフラグメントを取り出し、これによって、すべての子フラグメントを取り出すためにこの処理が継続される。そうでない場合には、フラグメント取出の処理が完了する。
【０２１６】
図３１に関して、流れ図によって、フラグメントがフラグメント・サポート式キャッシュ管理ユニット内でキャッシングされる時に実行される処理の一部を示す。図３１は、図１５のステップ６０１４および図１９のステップ６０３０と置換される処理を表し、図３１の処理は、現在のコンピューティング・デバイスで応答メッセージでフラグメントが既に受け取られた後に開始される。
【０２１７】
この処理は、応答メッセージ内のＵＲＩなどのフラグメントに関連するソース識別子を取り出す（ステップ６１１２）ことと、応答メッセージ内にｒｕｌｅｌｉｓｔが存在する場合に、フラグメントに関連するｒｕｌｅｌｉｓｔを取り出すこと（ステップ６１１４）によって開始される。後に、処理されつつある要求に関するキャッシュ・ヒットを行うことを試みる時に使用するために、ｒｕｌｅｌｉｓｔを、ＵＲＩパスに関連するｒｕｌｅｌｉｓｔデータベースに保管する（ステップ６１１６）。ｒｕｌｅｌｉｓｔは、応答メッセージ内のフラグメントをキャッシングするためのキャッシュＩＤの生成をガイドするのに使用される（ステップ６１１８）。
【０２１８】
次に、キャッシュＩＤを使用して、キャッシュ・インデックスを生成するが（ステップ６１２０）、キャッシュ・インデックスは、応答メッセージからのフラグメントが保管される、フラグメント・ストレージすなわちキャッシュ・メモリ内の位置を決定するのに使用される。キャッシュ・インデックスは、キャッシュＩＤをハッシュ・アルゴリズムにかけることによって作成することができる。フラグメントに付随するキャッシュＩＤ規則の使用の技法を厳守する形でキャッシュＩＤが生成された後に、キャッシュ管理ユニットの各実施形態が、キャッシュ・インデックスの計算にそれ自体のアルゴリズムを使用できるという点で、本発明の好ましい実施形態の技法は、柔軟である。
【０２１９】
フラグメントを、他の必要な情報またはメタデータと共にキャッシュに保管する（ステップ６１２２）が、この情報またはメタデータには、フラグメントに付随するＨＴＴＰ応答メッセージ内のヘッダまたは同等の情報が含まれ、次に、新たに生成されたキャッシュＩＤを、キャッシュ・インデックスに関連して保管する（ステップ６１２４）。代替案では、キャッシュ・インデックスを、必要な時に必ず計算することができ、キャッシュ・インデックスを保管する必要をなくすことができる。もう１つの代替案として、キャッシュＩＤを、なんらかのタイプのストレージ・インデックスまたはデータベース識別子として直接に使用することができ、別々のキャッシュ・インデックスを計算する必要をなくすことができる。
【０２２０】
応答メッセージ内のフラグメントに関連する依存性がある場合には、依存性を取り出し（ステップ６１２６）、フラグメントのキャッシュＩＤに関連して保管する（ステップ６１２８）。
【０２２１】
図３２に関して、流れ図によって、フラグメントがキャッシュ管理ユニットを含むコンピューティング・デバイスでキャッシングされる場合に、そのフラグメントを入手するためにフラグメント・サポート式キャッシュ管理ユニットによって使用することができる処理を示す。言い換えると、図３２には、たとえば要求メッセージの検査に応答して、フラグメント・サポート式キャッシュでキャッシュ・ヒットを生成できるかどうかを判定するのに使用することができる処理が示されている。
【０２２２】
この処理は、要求に関連するソース識別子、たとえばＵＲＩパスを取り出すことによって開始される（ステップ６１３２）。次に、ｒｕｌｅｌｉｓｔデータベースを検索して、ＵＲＩパスについてｒｕｌｅｌｉｓｔデータベース内にキャッシュＩＤ  ｒｕｌｅｌｉｓｔが存在するかどうかを判定する（ステップ６１３４）。ＵＲＩパスに関連するｒｕｌｅｌｉｓｔがない場合には、キャッシュ・ミス表示を返し（ステップ６１３６）、処理が完了する。
【０２２３】
ＵＲＩパスに関連するｒｕｌｅｌｉｓｔが存在する場合に、キャッシュＩＤを生成できるすなわち、少なくとも１つの規則を成功裡に評価するのに必要なすべての情報が存在すると仮定して、ｒｕｌｅｌｉｓｔ内の規則を使用して、キャッシュＩＤを作成する（ステップ６１３８）。キャッシュＩＤがフラグメントの保管に前に使用されたかどうか、すなわち、キャッシュ・ヒットがあるかどうかの判定を行う（ステップ６１４０）。そうでない場合には、キャッシュ・ミス表示を返し、処理が完了する。
【０２２４】
キャッシュ・ヒットがある場合には、キャッシュＩＤに関連するキャッシュ・インデックスを取り出し（ステップ６１４２）、これによって、キャッシュ・インデックスを使用する適当なフラグメントの後続の取出（ステップ６１４４）が可能になる。次に、フラグメントを要求元に返し（ステップ６１４６）、処理が完了する。
【０２２５】
図３３に関して、流れ図によって、複数のフラグメントに関連するヘッダ値およびプロパティ値を組み合わせる処理を示す。図３３は、図２６のステップ６０５４または図２７のステップ６０７４と置換することができる処理を表す。組み合わされるフラグメントのそれぞれは、応答メッセージで受信されたものであれ、コンピューティング・デバイスのキャッシュから取り出されたものであれ、応答メッセージで各フラグメントと共に受信されたプロトコル・ヘッダの関連する組を有する。ヘッダおよびプロパティの値が、各ヘッダまたはプロパティの単一のディレクティブ／値に組み合わされる。
【０２２６】
この処理は、組み合わされるすべてのフラグメントの次のヘッダ・タイプのヘッダ値を得ることによって開始される（ステップ６１５２）。適当な組合せ機能を、これらのヘッダ値にすべてに適用し（ステップ６１５４）、組み合わされたヘッダ値を、組み立てられたページまたはフラグメントについてセットするか、これに関連付ける（ステップ６１５６）。処理すべき別のヘッダタイプがあるか否かに関する判定を行い（ステップ６１５８）、そうである場合には、この処理はステップ６１５２に分岐して、別のヘッダ・タイプを処理する。
【０２２７】
ヘッダのすべてを処理した後に、この処理では、組み合わされるすべてのフラグメントの次のプロパティ・タイプのプロパティ値を取り出す（ステップ６１６０）。これらのプロパティ値のすべてに、適当な組合せ機能を適用し（ステップ６１６２）、組み合わされたプロパティ値を、組み立てられたページまたはフラグメントについてセットするか、これに関連付ける（ステップ６１６４）。処理すべき別のプロパティ・タイプがあるか否かに関する判定を行い（ステップ６１６６）、そうである場合には、この処理はステップ６１６０に分岐して、別のプロパティ・タイプを処理し、そうでない場合には、処理が完了する。
【０２２８】
図３４に関して、流れ図によって、ヘッダ・タイプおよびプロパティ値の、一連の組合せ機能を表すステップの組を示す。図３４は、図３３のステップ６１５４または６１６２で使用することができる組合せ機能を表し、図示の組合せ機能は、キャッシュ管理ユニットに存在することができる組合せ機能の完全なリストとして意図されてはいない。
【０２２９】
この処理は、ＨＴＴＰ「Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ」フィールドが組み合わされるか否かを判定することによって開始される（ステップ６１６８）。そうでない場合には、次のステップをスキップし、そうである場合には、組み合わされた「Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ」フィールドの値は、すべての「Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ」フィールドの合計である（ステップ６１７０）。
【０２３０】
この処理は、ＨＴＴＰ「Ｌａｓｔ−Ｍｏｄｉｆｉｅｄ」フィールドが組み合わされるか否かを判定することによって継続される（ステップ６１７２）。そうでない場合には、次のステップをスキップし、そうである場合には、組み合わされた「Ｌａｓｔ−Ｍｏｄｉｆｉｅｄ」フィールドの値は、すべての「Ｌａｓｔ−Ｍｏｄｉｆｉｅｄ」フィールドのうちで最新のものである（ステップ６１７４）。
【０２３１】
この処理は、満了時刻値が組み合わされるか否かを判定することによって継続される（ステップ６１７６）。そうでない場合には、次のステップをスキップし、そうである場合には、組み合わされた満了時刻値を、下記の考慮事項に従ってセットする（ステップ６１７８）。フラグメントの時刻に基づいて無効化される応答ヘッダと、組み立てられたページの応答ヘッダの間の関係は、フラグメントをサポートするキャッシュによって尊重されなければならない。この組立処理では、組み立てられたページの無効化時刻を、下記の形で判定する。第１に、絶対時刻である「Ｅｘｐｉｒｅｓ」ヘッダ、相対時刻である「ｍａｘ−ａｇｅ」ディレクティブを有する「Ｃａｃｈｅ−Ｃｏｎｔｒｏｌ」ヘッダ、および各フラグメントの「Ｄａｔｅ」ヘッダから、トップレベル・フラグメントおよびすべての再帰的に含まれるフラグメントを含む、すべてのフラグメントの最短の同等の時間間隔が計算される。これは、「Ｄａｔｅ」ヘッダ値を使用して、絶対時刻をデルタ時刻に変換することによって行われる。この値を「ｍｉｎｉｍｕｍＲｅｌａｔｉｖｅＴｉｍｅ」と称する。第２に、組み立てられたページの「Ｅｘｐｉｒｅｓ」ヘッダの値に、「Ｄａｔｅ」ヘッダの値と計算されたｍｉｎｉｍｕｍＲｅｌａｔｉｖｅＴｉｍｅ値の合計をセットする。これは、ＨＴＴＰ／１．１「Ｃａｃｈｅ−Ｃｏｎｔｒｏｌ」ヘッダをサポートしないキャッシュのために必要である。第３に、組み立てられたページの「ｍａｘ−ａｇｅ」ディレクティブに、計算されたｍｉｎｉｍｕｍＲｅｌａｔｉｖｅＴｉｍｅ値をセットする。というのは、ＨＴＴＰ／１．１仕様によって、「Ｅｘｐｉｒｅｓ」ヘッダがより制限的である場合に、「Ｅｘｐｉｒｅｓ」ヘッダが「ｍａｘ−ａｇｅ」ディレクティブによってオーバーライドされることが指定されているからである。これは、ＨＴＴＰ／１．１をサポートするキャッシュのために必要である。
【０２３２】
この処理の最後のステップでは、ｃｏｎｔｅｎｔ−ｅｎｃｏｄｉｎｇタイプに適当な値をセットする（ステップ６１８０）。第１の代替案では、ＨＴＴＰ／１．１仕様に従って、新しいエンコーディングがクライアントに受入可能であることが既知の場合に、組み合わされるヘッダの１つに「ｎｏ−ｔｒａｎｓｆｏｒｍ」キャッシュ制御ディレクティブがないならば、キャッシュでｃｏｎｔｅｎｔ−ｅｎｃｏｄｉｎｇを変更することができる。第２の代替案では、インクルードされるフラグメントのｃｏｎｔｅｎｔ−ｅｎｃｏｄｉｎｇを、トップレベル・フラグメントと同一になるように変更する。
【０２３３】
図３５に関して、流れ図によって、要求メッセージを処理する時にフラグメント・サポート式キャッシュ管理ユニットによって使用することができる処理を示す。応答メッセージの処理を示す図１５と対照的に、図３５には、要求メッセージの処理に関連するステップの一部が示されている。
【０２３４】
この処理は、要求メッセージを受信することによって開始され（ステップ６１９２）、その後、要求メッセージからソース識別子を取り出す（ステップ６１９４）。ソース識別子は、識別されたオブジェクトまたはフラグメントをローカル・キャッシュから得る、すなわちキャッシュ・ヒットが発生した場合、または要求によってオブジェクトまたはフラグメントを取り出す、すなわちキャッシュ・ミスが発生した場合のいずれかに使用される（ステップ６１９６）。キャッシュ・ヒットまたはキャッシュ・ミスに関連する処理は、図３０に関して上で説明した。どちらの場合でも、ページ組立が必要な場合には、それが実行され（ステップ６１９８）るが、ページ組立に関連する処理は、上で図３３に関して説明した。その後、受信した要求メッセージに関する応答メッセージを返し（ステップ６２００）、これによって処理を完了する。
【０２３５】
図３６に関して、流れ図によって、本発明の好ましい実施形態に従って無効化メッセージを処理する時にフラグメント・サポート式キャッシュ管理ユニットによって使用することができる処理を示す。上で注記したように、本発明の好ましい実施形態の技法は、特定の無効化アルゴリズムを要求せず、図３６に示された処理は、依存ＩＤの使用の１例にすぎない。
【０２３６】
この処理は、コンピューティング・デバイスで、コンピューティング・デバイスでキャッシングできるフラグメントをパブリッシュまたはサービスした起点サーバから、無効化要求メッセージを受信することによって開始される（ステップ６２０２）。この要求には、依存ＩＤのリストが含まれる。起点サーバが、衝突する依存性を生成しないことが仮定される。少なくともドメイン名を含むアプリケーションＩＤによる依存性の修飾によって、グローバルに一意な依存性を維持できることが仮定される。通常は、アプリケーションＩＤをインバリデータ（ｉｎｖａｌｉｄａｔｏｒ）に関連付け、その結果、インバリデータがそれ自体の内容だけを無効化できるようにするために、認証が必要である。
【０２３７】
次に、依存性データベースの依存性のいずれかが、受信されたメッセージ内の１つまたは複数の依存性と一致するかどうかに関する判定を行い（ステップ６２１０）、そうである場合には、一致する依存性（１つまたは複数）に関連するキャッシュＩＤのリストを取り出す（ステップ６２１２）。次に、キャッシュＩＤを使用して、関連するフラグメントをキャッシュから消去する（ステップ６２１４）。必要または適当である場合に、関連するｒｕｌｅｌｉｓｔおよび依存性も消去することができる。
【０２３８】
任意選択の応答を、無効化要求メッセージの発信元に返すことができる（ステップ６２１６）。依存性の一致がない場合には、この処理はステップ６２１６に分岐する。どの場合でも、処理が完了する。
【０２３９】
フラグメント・サポート式キャッシュのキャッシュ管理ユニットの間の調整のいくつかの例
図３７に関して、ブロック図によって、一部のキャッシュでフラグメント組立が実行される時を示すための、ウェブ・アプリケーション・サーバとクライアントの間でのデータフローの一部を示す。クライアント・デバイス７００に、フラグメント非サポート式キャッシュ管理ユニット７０２が含まれ、このフラグメント非サポート式キャッシュ管理ユニット７０２によって、ページの要求が生成され、その要求が中間サーバ７０４に送信される。クライアント・デバイスは知らないが、要求されたページに、実際には親フラグメントと、子フラグメントへのリンクとが含まれる。中間サーバ７０４によって、要求が受信されるが、キャッシュ管理ユニット７０６は、フラグメントをサポートせず、要求されたページのキャッシングされたバージョンを有しない。
【０２４０】
要求は、中間サーバ７０８に転送され、中間サーバ７０８には、フラグメント・サポート式キャッシュ管理ユニット７１０が含まれる。中間サーバ７０８は、要求されたページのキャッシングされたバージョンを有しておらず、中間サーバ７０８は、要求メッセージを中間サーバ７１２に送信する前に、要求メッセージに「Ｆｒａｇｍｅｎｔ：ｓｕｐｐｏｒｔｓ−ｆｒａｇｍｅｎｔｓ」ヘッダを追加し、中間サーバ７１２には、フラグメント非サポート式キャッシュ管理ユニット７１４が含まれる。中間サーバ７１２は、要求されたページのキャッシングされたバージョンを有しておらず、要求メッセージをウェブ・アプリケーション・サーバ７１６に送信／転送し、ウェブ・アプリケーション・サーバ７１６には、フラグメント・サポート式キャッシュ管理ユニット７１８が含まれる。
【０２４１】
「Ｆｒａｇｍｅｎｔ：ｓｕｐｐｏｒｔｓ−ｆｒａｇｍｅｎｔｓ」ヘッダを含む着信要求メッセージから、ウェブ・アプリケーション・サーバ７１６は、下流コンピューティング・デバイスが、ページ・アセンブラとして働くことができるフラグメント・サポート式キャッシュ管理ユニットを有すると判定することができる。したがって、応答で完全に組み立てられたページを返すのではなく、ウェブ・アプリケーション・サーバ７１６は、ＦＲＡＧＭＥＮＴＬＩＮＫ子フラグメントを含む親フラグメントを有する応答を返す。中間サーバ７１２は、フラグメントをサポートせず、したがって、単にこの応答を転送する。
【０２４２】
フラグメント・サポート式キャッシュ管理ユニット７１０は、それがエンドユーザまたはクライアントに最も近いフラグメント・サポート式キャッシュであることを認識し、元の要求には「Ｆｒａｇｍｅｎｔ：ｓｕｐｐｏｒｔｓ−ｆｒａｇｍｅｎｔｓ」ヘッダが含まれておらず、したがって、フラグメント・サポート式キャッシュ管理ユニット７１０は、この応答を返す前に、ページ組立を実行しなければならないと判定する。ページ組立処理中に、フラグメント・サポート式キャッシュ管理ユニット７１０は、親フラグメントにリンクされた子フラグメントを要求し、受信し、この子フラグメントおよび親フラグメントが、単一の組み立てられたページに組み合わされ、組み立てられたページが、クライアント・デバイスに返される。中間サーバ７０４によって、この応答がクライアント・デバイス７００に返され、クライアント・デバイス７００によって、組み立てられたページがエンドユーザに提示される。中間サーバ７０４およびクライアント・デバイス７００の両方によって、組み立てられたページがキャッシングされない。というのは、この応答が、「ｎｏ−ｃａｃｈｅ」ディレクティブを用いてマークされ、これによって、これらのデバイスが組み立てられたページをキャッシングしなくなるからである。中間サーバ７０８は、親フラグメントと子フラグメントの両方をキャッシングする。
【０２４３】
図３８に関して、ブロック図によって、エンドユーザまたはクライアント・デバイスに最も近いキャッシュでフラグメントをキャッシングするようにデバイスの組に指示することができる形を示すための、ウェブ・アプリケーション・サーバとクライアントの間でのデータフローの一部を示す。クライアント・デバイス７２０に、フラグメント非サポート式キャッシュ管理ユニット７２２が含まれ、これによって、オブジェクトに関する要求が生成され、その要求が中間サーバ７２４に送信される。クライアント・デバイスは知らないが、要求されたオブジェクトは、実際にはフラグメントである。中間サーバ７２４によって、要求が受信されるが、キャッシュ管理ユニット７２６は、フラグメントをサポートするが、要求されたフラグメントのキャッシングされたバージョンを有しておらず、キャッシュ管理ユニット７２６によって、要求に「Ｆｒａｇｍｅｎｔ：ｓｕｐｐｏｒｔｓ−ｆｒａｇｍｅｎｔｓ」ヘッダが追加され、その要求が宛先サーバに転送される。
【０２４４】
中間サーバ７２８によって、要求が受信されるが、キャッシュ管理ユニット７３０は、要求されたフラグメントのキャッシングされたバージョンを有しておらず、フラグメント・サポート式キャッシュ管理ユニット７３０によって、「Ｆｒａｇｍｅｎｔ：ｓｕｐｐｏｒｔｓ−ｆｒａｇｍｅｎｔｓ」ヘッダが要求メッセージに含まれることが保証され、その要求が、宛先サーバに転送される。中間サーバ７３２には、キャッシュ管理ユニット７３４が含まれるが、キャッシュ管理ユニット７３４は、フラグメントをサポートせず、要求されたオブジェクトのキャッシングされたバージョンを有しておらず、要求を転送する。
【０２４５】
「Ｆｒａｇｍｅｎｔ：ｓｕｐｐｏｒｔｓ−ｆｒａｇｍｅｎｔｓ」ヘッダを含む着信要求メッセージから、ウェブ・アプリケーション・サーバ７３６は、下流コンピューティング・デバイスが、フラグメント・サポート式キャッシュ管理ユニットを有すると判定することができる。したがって、ウェブ・アプリケーション・サーバ７３６は、フラグメントを含む応答を返すことが適当であると判定することができる。しかし、ウェブ・アプリケーション・サーバ７３６は、応答メッセージに「Ｃａｃｈｅ−Ｃｏｎｔｒｏｌ：ｐｒｉｖａｔｅ」ヘッダを用いてマークし、これによって、応答内のフラグメントの、エンドユーザまたはクライアント・デバイスに最も近いフラグメント・サポート式キャッシュだけによるキャッシングがもたらされ、キャッシュ管理ユニット７３８は、応答のフラグメントをキャッシングしない。
【０２４６】
中間サーバ７３２は、フラグメントをサポートしない。キャッシュ管理ユニット７３４は、「ｐｒｉｖａｔｅ」ディレクティブを認識し、したがって、フラグメントをキャッシングせず、中間サーバ７３２は、応答を単に転送する。対照的に、キャッシュ管理ユニット７３０は、フラグメントをサポートするが、元々の要求が「Ｆｒａｇｍｅｎｔ：ｓｕｐｐｏｒｔｓ−ｆｒａｇｍｅｎｔ」ヘッダを用いてマークされており、下流デバイスが、エンドユーザまたはクライアント・デバイスにより近いところでフラグメントをキャッシングできることを認識する。したがって、キャッシュ管理ユニット７３０は、応答のフラグメントをキャッシングしないようにという指示として「ｐｒｉｖａｔｅ」ディレクティブを解釈する。
【０２４７】
キャッシュ管理ユニット７２６も、フラグメントをサポートするが、元々の要求が「Ｆｒａｇｍｅｎｔ：ｓｕｐｐｏｒｔｓ−ｆｒａｇｍｅｎｔ」を用いてマークされておらず、下流デバイスが、エンドユーザまたはクライアント・デバイスにより近いところでフラグメントをキャッシングできないことを認識する。したがって、キャッシュ管理ユニット７２６は、応答のフラグメントをキャッシングするように指示するものとして「ｐｒｉｖａｔｅ」ディレクティブを解釈する。中間サーバ７２４によって、応答がクライアント・デバイス７２０に転送され、キャッシュ管理ユニット７２２は、フラグメントをサポートせず、したがって、フラグメントをキャッシングしないように指示するものとして「ｐｒｉｖａｔｅ」ディレクティブを解釈する。
【０２４８】
役割固有コンテンツまたはカテゴリ固有コンテンツのキャッシングをサポートするのに使用されるフラグメント・サポート式キャッシュの例
図３９から４２に関して、データフロー図によって、動的な役割固有またはカテゴリ固有のコンテンツのキャッシングを本発明の好ましい実施形態に従って達成できることを示すために、クライアント、中間フラグメント・サポート式キャッシュ、またはサーバ内で行われる処理ステップの一部を示す。特定の機関との関連または機関での役割に基づいてユーザのグループに固有になるように、一部のウェブ・コンテンツを分類することができる。たとえば、企業は、その製品に関する価格設定データベースの第１のバージョンを第１の会社に公開し、その製品に関する価格設定データベースの第２のバージョンを第２の会社に公開することができる。たとえば、第２の会社は、企業の製品の大量購入に関してかなりの数量割引を得ることができる。
【０２４９】
第１の会社の第１従業員が、企業のウェブ・サイトを訪れる時に、この従業員は、第１の会社に関する価格設定情報を示すウェブ・ページを受信しなければならない。この価格設定情報は、比較的頻繁に変更される可能性があり、したがって、この価格設定情報は、静的コンテンツと比較してキャッシングが困難である。第２の会社の従業員がこの企業のウェブ・サイトを訪れる時には、この従業員は、第２の会社に関する価格設定情報を示すウェブ・ページを受信しなければならない。
【０２５０】
本発明の好ましい実施形態では、異なる顧客会社の従業員のために生成されるウェブ・ページをキャッシングし、同一の会社の他の従業員から使用可能にすることができる。第１の会社の第２の従業員が、企業のウェブ・サイトを訪れる時に、この従業員は、同一の会社の第１の従業員のためにキャッシングされたウェブ・ページを受信することができる。言い換えると、企業のコンテンツが、異なる機関すなわち、異なる顧客会社による使用のために分類されている。
【０２５１】
第２の例を使用すると、会社は、人的資源情報を含むウェブ・サイトを有することができるが、その情報の一部を、会社の管理職レベルの従業員だけが見るように制限しなければならない。しかし、管理レベル情報がダイナミック・コンテンツであっても、その情報を見る管理者ごとに管理レベル情報の複数のコピーをキャッシングする必要があってはならない。本発明の好ましい実施形態によれば、たとえば管理職対非管理職などの役割固有コンテンツをキャッシングすることができ、組織内のユーザの役割を使用して、キャッシングされたコンテンツのどの組をユーザに返すかの判定を支援することができる。
【０２５２】
これらの例を、カテゴリ区別を使用する全般的な形で説明することができる。コンテンツのカテゴリという概念は、コンテンツにアクセスしているユーザに適用できる特性に基づいて、ユーザの役割、機関のエンティティなどに適用することができる。図３９から４２に、本発明の好ましい実施形態を使用して、カテゴリ固有コンテンツをキャッシングできる形の一般的な例を示す。
【０２５３】
図３９を参照すると、たとえばブラウザなどのクライアント・アプリケーションによって、ページ要求が生成され（ステップ８０２）、これがアプリケーション・サーバに送信される（ステップ８０４）。中間のフラグメント・サポート式キャッシュは、要求されたページのコピーを有しておらず、したがって、キャッシングされたコピーを返すことができない。アプリケーション・サーバによって、要求されたページが、ユーザのあるカテゴリによる表示に制限されていることが判定されるが、アプリケーション・サーバによって、ユーザの制限されたカテゴリのメンバとして要求者を識別するのに必要なクッキーがこの要求に付随しないことが検出される（ステップ８０６）。サーバによって、認証チャレンジ・ページが生成され（ステップ８０８）、クライアントに送信される（ステップ８１０）が、この認証チャレンジ・ページは、キャッシュ不能としてマークされ、したがって、中間キャッシュはこれをキャッシングすることができない。
【０２５４】
クライアントによって、認証チャレンジ・ページが受信され、ユーザに提示され（ステップ８１２）、ユーザは、ユーザＩＤおよびパスワードを供給し（ステップ８１４）、これがサーバに送り返される（ステップ８１６）。サーバによって、ユーザの情報が認証され（ステップ８１８）、識別されたユーザが属するユーザ・カテゴリを判定するのにユーザＩＤが使用される（ステップ８２０）。管理役割など、ユーザ・カテゴリを判定した後に、サーバによって、判定されたユーザ・カテゴリの識別を可能にする情報を含むカテゴリ・クッキーが生成される（ステップ８２２）。最初に要求されたページも生成され（ステップ８２４）、そのページおよびカテゴリ・クッキーが、クライアントに送信される（ステップ８２６）。
【０２５５】
この時点までに、中間キャッシュは、コンテンツを一切キャッシングしていない。しかし、現在返されつつあるページは、フラグメント・サポート式キャッシング規則に従ってキャッシュ可能としてマークされており、したがって、中間キャッシュは、そのページの識別子を使用してページを保管し（ステップ８２８）、そのページに付随するカテゴリ・クッキー、およびクライアントへの応答メッセージに付随するフラグメント・キャッシング規則でその中間キャッシュが使用されるように指示されるのに適当な他のすべての情報を保管する。クライアントは、要求したページを受信した後に、それをユーザに提示し（ステップ８３０）、付随するカテゴリ・クッキーが、クライアント・アプリケーションによってそのクッキー・キャッシュに保管される（ステップ８３２）。
【０２５６】
図４０を参照して、前に発行されたカテゴリ・クッキーを更新する例を示す。クライアント・アプリケーションによって、図３９に示されたページ要求に類似する、たとえば同一ドメインからのページ要求が生成される（ステップ８４２）。しかし、ユーザは、ユーザのカテゴリを変更させるアクションを実行した。たとえば、ユーザは、従業員のあるグループの管理者としてのユーザの役割に関してページを表示したが、財務責任者としてのユーザの役割に関するページを見ることを決定することができる。このユーザは、前に認証されているので、サーバは、別の認証処理を実行してはならない。しかし、サーバは、このユーザの新しいカテゴリ・クッキーを発行しなければならない。
【０２５７】
ページ要求が、付随するカテゴリ・クッキーと共にサーバに送信される（ステップ８４４）。中間キャッシュは、要求されたページを有しておらず、したがって、キャッシュ・ミスを有する。サーバによって、新しいカテゴリ・クッキー値を必要とする動作がクライアントによって要求されたことが判定され（ステップ８４６）、新しいカテゴリ・クッキーが発行される（ステップ８４８）。要求されたページも生成され（ステップ８５０）、要求されたページおよび新たに発行されたカテゴリ・クッキーが返される（ステップ８５２）。中間キャッシュによって、新しいクッキー値に従ってページが保管される（ステップ８５４）。クライアントによって、要求されたページが受信され、提示され（ステップ８５６）、新しいクッキー値が、クライアント側のクッキー・キャッシュに保管される（ステップ８５８）。この形で、カテゴリ・クッキーが更新される時に、中間キャッシュが更新される。
【０２５８】
図４１を参照すると、同一のカテゴリ・クッキーの使用の継続によってもキャッシュ・ミスがもたらされる形の例が示されている。クライアント・アプリケーションによって、ページ要求が、生成され（ステップ８６２）、付随するカテゴリ・クッキーと共にサーバに送信される（ステップ８６４）。中間キャッシュは、要求されたページを有しておらず、したがって、キャッシュ・ミスを有する。サーバは、カテゴリ・クッキーの値を使用して、コンテンツのタイプを動的に判定し、適当なページを生成し（ステップ８６６）、生成されたページおよび変更されないカテゴリ・クッキーが返される（ステップ８６８）。中間キャッシュは、ページを保管し（ステップ８７０）、このページをクライアントに転送する。クライアントは、要求されたページを受信し、提示し（ステップ８７２）、カテゴリ・クッキーが変更されていないので、クライアントは、クッキー・キャッシュのカテゴリ・クッキーを上書きするものとして示されていない。
【０２５９】
本発明の好ましい実施形態によれば、ステップ８２８、８５４、および８７０で、中間キャッシュが、サーバによって応答メッセージに配置されたフラグメントキャッシング規則に従って、応答メッセージからのページのコピーを保管した。本発明の好ましい実施形態を用いると、ページに関連するＵＲＩだけがキャッシングに使用される場合に同一として識別される可能性がある類似するページの２つの異なるバージョンを区別するのに、キャッシュＩＤ動作でクッキーを使用できるようになる。より重要なことに、ページをカテゴリ・クッキーに関連してキャッシングでき、カテゴリ・クッキーを、その後、キャッシュ・ルックアップ処理に使用できるようになり、これによって、図４２に示されているように、アサートされたカテゴリ・クッキーでの類似性に基づいて、キャッシュ・ヒットを確立できるようになる。
【０２６０】
図４２を参照すると、２人の異なるユーザによる同一のカテゴリ・クッキーの使用によって、異なるユーザによる単一ページのアクセスにまたがるキャッシュ・ヒットがもたらされる形の例が示されている。この例では、異なるユーザが、図４１に示された前の例の第１ユーザと同一のページにアクセスしている。しかし、第２ユーザは、第１ユーザと同一のユーザのカテゴリに属する。言い換えると、２人のユーザを、ユーザの同一のカテゴリに属する、または同一の役割が割り当てられていると記述することができる。たとえば、この２人のユーザは、２人のユーザが属する部署の管理者に合わせて特に調整されたダイナミック・コンテンツを含む、管理者用の会社メモを見る管理者とすることができる。管理者ごとにメモを生成し、キャッシングするのではなく、メモは、前に管理者の役割に関連付けられている。第１の管理者がメモにアクセスした後に、そのメモがキャッシングされ、同一カテゴリの他の管理者によるそのメモの取出の後続の試みが、キャッシュ・ヒットをもたらす。異なるカテゴリの他の管理者によるそのメモへのアクセスの後続の試みは、キャッシュ・ミスをもたらす。というのは、メモの２つの異なるバージョンが同一のＵＲＩに関連する場合であっても、後続の管理者が、異なるカテゴリ・クッキーを有するからである。
【０２６１】
クライアント・アプリケーションによって、ページ要求が生成され（ステップ８８２）、このページ要求が、第２ユーザに属する付随するカテゴリ・クッキーと共にサーバに送信される（ステップ８８４）。この場合に、中間キャッシュは、要求内のＵＲＩパスおよび関連するカテゴリ・クッキーによって識別される要求されたページのコピーを有し、したがって、キャッシュ・ヒットを有する（ステップ８８６）。中間キャッシュは、要求をサーバに転送せずに即座に要求されたページを返すことができ（ステップ８８８）、クライアントは、要求されたページを受信し、第２ユーザに提示する（ステップ８９０）。
【０２６２】
この形で、中間キャッシュによって、同一のフラグメントの複数のバージョンを実際に保管することができ、フラグメントの適当なバージョンが、ユーザのアサートされたカテゴリ・クッキーに基づいてユーザに返される、すなわち、カテゴリ・クッキーだけによって、そうでなければ類似するフラグメントの異なるバージョンの間での選択が決定される。フラグメントを区別するためのクッキーの使用のさらなる例を、特に買物客グループのカテゴリに関して下で提供する。
【０２６３】
単一メッセージ内の複数フラグメントの処理の効率向上
図４３に関して、流れ図によって、複数のフラグメントを単一の要求メッセージ内で指定でき、後に処理できるようにする処理を示す。図４３に示された処理は、図２７に示された処理と共に、または、特に複数のフラグメントを単一のフラグメントに組み合わせる前の、複数のフラグメントを得る必要がある処理と共に使用することができる。
【０２６４】
応答メッセージまたはキャッシュからフラグメントを得た後に、この処理は、「ｃｏｎｔａｉｎｓ−ｆｒａｇｍｅｎｔｓ」ディレクティブを検査して、それが葉フラグメントであるか、他のフラグメントを含むかを調べることによって開始される。他のフラグメントが含まれる場合に、元のフラグメントを構文解析して、含まれるフラグメントを見つける。
【０２６５】
すべての次レベル・フラグメントのソース識別子を収集した後に、単一のバッチ要求が生成される（ステップ９０４）。このバッチ要求に、フラグメントを得る際に使用されるバッチ・サーバ側プログラムすなわちサーブレットを含めることができる。このバッチ要求には、次レベル・フラグメントのソース識別子、たとえばＵＲＩのすべてが含まれる。ローカル・キャッシュが、これらの次レベル・フラグメントのすべてのキャッシュ・ヒットについて検査済みであり、次レベル・フラグメントのキャッシュ・ヒットがある場合に、そのフラグメントがバッチ要求に含まれないと仮定する。
【０２６６】
次に、バッチ要求メッセージが、サーバに送信され（ステップ９０６）、キャッシュ管理ユニットは、マルチパートＭＩＭＥ（Ｍｕｌｔｉｐｕｒｐｏｓｅ  Ｉｎｔｅｒｎｅｔ  Ｍａｉｌ  Ｅｘｔｅｎｓｉｏｎ）応答を受信するのを待つ（ステップ９０８）。要求についてスレッドを作成し、コンピューティング・デバイスが他の動作を実行している間に、そのスレッドが応答を待ってスリープすることが好ましい。
【０２６７】
応答を受信した後に、キャッシュ管理ユニットは、応答内の各フラグメントをステップ・スルーする。次のフラグメントを、マルチパート応答メッセージから取り出し（ステップ９１０）、キャッシングする（ステップ９１２）。マルチパート応答メッセージに処理すべきフラグメントがまだあるか否かに関する判定を行い（ステップ９１４）、そうである場合には、この処理は、ステップ９１０に分岐して、もう１つのフラグメントを処理する。そうでない場合には、新たに受信されたフラグメントを構文解析または検査して、これらのフラグメントに次レベル・フラグメントへのリンクが含まれるか否かを判定し（ステップ９１６）、そうである場合には、この処理は、ステップ９０２に分岐して、必要な場合にバッチ要求でさらにフラグメントを要求する。そうでない場合には、新たに受信したフラグメントを、ページ組立動作で組み合わせ（ステップ９１８）、処理が完了する。
【０２６８】
図４４に関して、流れ図によって、単一の要求メッセージを中間キャッシュ管理ユニットで受信し、後に処理できるようにする処理を示す。図４４に示された処理は、図３５に示された処理と共に、または要求メッセージを中間キャッシュで処理する他の処理と共に使用することができる。
【０２６９】
この処理は、バッチ要求が中間フラグメント・サポート式キャッシュで受信される時に開始される（ステップ９２２）。バッチ要求内のソース識別子の組が、ループで処理される。要求されたフラグメントの１つに関する次のソース識別子を、要求メッセージから取り出し（ステップ９２４）、ローカル・キャッシュでキャッシュ・ヒットがあるか否かに関する判定を行う（ステップ９２６）。キャッシュ・ヒットがない場合には、次のステップをスキップすることができ、キャッシュ・ヒットがある場合には、ソース識別子を、バッチ要求メッセージから除去することができる（ステップ９２８）。バッチ要求メッセージに処理すべきソース識別子がまだあるか否かに関する判定を行い（ステップ９３０）、そうである場合には、この処理はステップ９２４に分岐して、別のソース識別子を処理する。
【０２７０】
要求されたフラグメントのすべてがローカル・キャッシュ内で見つかったか否かに関する判定を行う（ステップ９３２）。そうである場合には、バッチ要求を転送する必要はなく、この処理は、応答メッセージの準備に分岐する。少なくとも１つのキャッシュ・ミスがある場合に、ソース識別子（１つまたは複数）を除去された修正されたバッチ要求を、サーバに転送する（ステップ９３４）。代替案では、単一の残りのソース識別子がある場合に、バッチ要求を通常の要求メッセージに変更することができる。キャッシュ管理ユニットは、マルチパートＭＩＭＥ応答の受信を待つ（ステップ９３６）が、要求についてスレッドが作成され、コンピューティング・デバイスが他の動作を実行している間に、スレッドが応答を待ってスリープすることが好ましい。
【０２７１】
応答を受信した後に、キャッシュ管理ユニットは、応答の各フラグメントをステップ・スルーする。次のフラグメントをマルチパート応答メッセージから取り出し（ステップ９３８）、ローカル・キャッシュにそのフラグメントをキャッシングすることが適当であると仮定して、そのフラグメントをキャッシングするし（ステップ９４０）。マルチパート応答メッセージに処理すべきフラグメントがまだあるか否かに関する判定を行い（ステップ９４２）、そうである場合には、この処理は、ステップ９３８に分岐して、別のフラグメントを処理する。新たに受信されたフラグメントが、これらのフラグメントに次レベル・フラグメントへのリンクが含まれるか否かに関する判定のために構文解析も検査もされないと仮定する。というのは、この処理が、元々のバッチ要求を生成したキャッシュ管理ユニットで実行されると仮定することができるからである。代替案では、この処理を、図４３で説明したものに類似する形で現在のキャッシュ管理ユニットで実行することができる。どの場合でも、マルチパートＭＩＭＥ応答が、元々のバッチ要求で受信されたソース識別子に対応するフラグメントを用いて生成され（ステップ９４４）、マルチパートＭＩＭＥ応答を返し（ステップ９４６）、これによって処理が完了する。
【０２７２】
図４５に関して、流れ図によって、複数のフラグメントに関するバッチ要求メッセージを処理するウェブ・アプリケーション・サーバでの処理を示す。図４５に示された処理は、フラグメント要求を満足できないフラグメント・サポート式キャッシュ管理ユニットを有する複数のコンピューティング・デバイス（すなわち、複数のデバイスがキャッシュ・ミスを有することができる）を通ってバッチ要求メッセージが流れた後で実行することができる。
【０２７３】
処理は、サーバでバッチ要求を受信することによって開始され（ステップ９５２）、このバッチ要求には、順番に処理される複数のフラグメント要求が含まれる。次のフラグメント要求が、バッチ要求メッセージから取り出され（ステップ９５４）、実行され（ステップ９５６）、この実行には、多分フラグメントの生成が含まれ、その後に、フラグメントを、任意選択として送信のためにフォーマットするかタグをつける必要がある場合がある（ステップ９５８）が、フラグメントが前にサーバでキャッシングされている場合がある。バッチ要求メッセージに別のフラグメント要求があるか否かに関する判定を行い（ステップ９６０）、そうである場合には、この処理は、別のフラグメント要求を処理するために分岐する。そうでない場合には、すべての要求されたフラグメントを有するマルチパートＭＩＭＥ応答メッセージを生成し（ステップ９６２）、応答メッセージを返し、これによって処理が完了する。
【０２７４】
キャッシュ・サイズ削減の例
図４６から４９に関して、本発明の好ましい実施形態を用いて達成できる有利なキャッシュ・サイズ削減を示す例の組を示す。特定の応用例で何がフラグメントを構成するかを選択する判断基準の１つが、あるコンテンツが異なるページにまたがって共用される頻度である。あるコンテンツが、激しく共用される場合に、それをフラグメントにすることによって、多数のページで繰り返すのではなく、フラグメントを１回だけキャッシングすることができるので、キャッシュのサイズを大きく考慮に入れることができる。したがって、フラグメントによって、キャッシュ・サイズを減らすための多数のページにまたがる圧縮の１形態がもたらされる。この圧縮の長所は、たとえば固定されたヒット率のキャッシュ・サイズの減少などのコスト削減、たとえば固定サイズ・キャッシュのヒット率の増加などの性能向上、またはこれらの組合せと見なすことができる。図４６から４９に、本発明の好ましい実施形態のさまざまな使用のシナリオと、同等の従来技術のシナリオと比較した、達成できるキャッシュ・サイズの削減を示す。
【０２７５】
図４６を参照すると、共用されるサイドバー（ｓｉｄｅｂａｒ）のシナリオが示されている。各ページに、サイドバー部分と他のページ部分が含まれ、従来技術によれば、各ページが、フラグメントをサポートしないキャッシュ内で、すべての従属オブジェクトを有する完全なページとして保管される。本発明の好ましい実施形態を用いると、各ページが、サイドバー・フラグメントと残りのページ・フラグメントを含むように構成され、これらのフラグメントのすべてが、フラグメントをサポートするキャッシュに保管される。明白なように、本発明の好ましい実施形態では、サイドバー・フラグメントが、１回だけ保管される。言い換えると、特定のサイトのすべてのページが、同一のサイドバー・フラグメントを共用する。サイドバーが各ページの２０％である場合に、すべてのページからこれを因数分解することによって、サイドバーが複製されないので、約２０％だけキャッシュ・サイズを減らすことができる。
【０２７６】
図４７を参照すると、買物客グループのシナリオが示されている。製品説明ページが、買物客グループごとに異なる価格を有するが、製品説明の残りは、買物客グループと独立である。従来技術によれば、製品および買い物客グループの組合せごとに製品ページがあり、これらの製品ページのそれぞれが、潜在的に、フラグメントをサポートしないキャッシュにキャッシングされる可能性がある。対照的に、本発明の好ましい実施形態によるフラグメントをサポートするキャッシュは、製品グループ組合せの価格データ・フラグメントと、製品記述フラグメントだけを保管する必要があり、ページ全体の組合せのすべてを保管する必要はない。
【０２７７】
潜在的な保管スペース節約は、次のように近似することができる。各価格が１００Ｂ（ｓ１）であり、製品説明の残りが１０ｋＢ（ｓ２）である。１００００個の製品（ｐ）と５つの買物客グループ（ｇ）がある。完全に展開されたページを保管する場合に、潜在的に、全体で（１００００×５）＝５００００（ｐ＊ｇ）個の項目があり、項目のサイズは約１０ｋＢである（ｓ２は、ｓ１＋ｓ２とほぼ等しい）、これは、合計約５０００００ｋＢ（ｐ＊ｇ＊ｓ２）のサイズを有する。その代わりに、製品説明の残りと別々のフラグメントに価格を保管する場合には、キャッシュ内にそれぞれ１０ｋＢ（ｓ２）の１００００（ｐ）個の製品フラグメントがあり、これは１０００００ｋＢ（ｐ＊ｓ２）のサイズを有し、さらに、それぞれ１００Ｂ（ｓ１）の１００００×５＝５００００（ｐ＊ｇ）の価格があり、これは５０００ｋＢのサイズを有する。フラグメントの総計は、この合計すなわち１０５０００ｋＢである。これは、フラグメントをサポートするキャッシュを実施した後のキャッシュ・サイズのほぼ５倍のサイズ削減である。
【０２７８】
図４８を参照すると、パーソナライゼーションのシナリオが示されている。製品説明ページに、パーソナライズされたセクションが含まれ、１００００個の製品（ｐ）と１０００００人のユーザ（ｕ）がある。従来技術によれば、完全に展開されたページを保管する場合に、キャッシュ内に潜在的に合計１００００×１０００００＝１０００００００００（ｕ＊ｐ）個の項目がある。
【０２７９】
対照的に、本発明の好ましい実施形態に従って実施されるフラグメント・サポート式キャッシュでは、ページを別々のフラグメントとして保管することができる。この場合に、キャッシュ内には、合計１００００＋１０００００＝１１００００（ｕ＋ｐ）個の項目だけがあり、各項目はより小さい。これは、約２００００倍のサイズ削減である。
【０２８０】
同一の例を続けると、ＳＲＣ属性によって、クッキー、たとえばｓｒｃ＝”ｃｏｏｋｉｅ：／／｛ｃｏｏｋｉｅ  ｎａｍｅ｝”またはＵＲＩ照会パラメータ、たとえばｓｒｃ＝”ｐａｒｍ：／／｛ｐａｒｍ  ｎａｍｅ｝”が識別されるＦＲＡＧＭＥＮＴＬＩＮＫタグを使用して、そのクッキーまたは照会パラメータの値を置換することができる。このシナリオでは、パーソナライゼーションが、クッキー値にするのに十分に小さい場合に、この変数置換を使用して、ウェブ・アプリケーション・サーバにパーソナライゼーション・フラグメントを要求し、それをキャッシングするオーバーヘッドを除去することができる。たとえば、「Ｈｅｌｌｏ，  Ｊｏｈｎ  Ｓｍｉｔｈ．    Ｗｅｌｃｏｍｅ  ｔｏ  ｏｕｒ  ｓｔｏｒｅ！！！」などの挨拶を、名前が「ｕｓｅｒＮａｍｅ」であり、値が「Ｊｏｈｎ  Ｓｍｉｔｈ」であるクッキーを用いて、下記のＨＴＭＬステートメントで実行することができる。
Hello, {fragmentlinksrc="cookie://userName"}.Welcome to our store!!!
【０２８１】
図４９を参照すると、株式ウォッチリストのシナリオが示されており、株式ウォッチリストは、多数のウェブ・ポータルで使用可能である。ページに、株式相場のパーソナライズされたリストが含まれる。このシナリオは、ユーザ固有情報が、インクルードされるフラグメントではなくトップレベル・フラグメントに関連することを除いて、パーソナライゼーションのシナリオに似ている。各ユーザは、株の別々のリストを有するが、各株は、多数のユーザ・リストによって共用される。１０００００人のユーザ（ｕ）と１０００個の株（ｓ）がある。各ユーザ記述は、１ｋＢ（ｓ１）であり、各株式相場は、１００Ｂ（ｓ２）である。ユーザは、平均１０個の株をリスト内に有する（ｌ）。完全に展開されたページを保管する場合に、キャッシュ・サイズは、１０００００＊１ｋＢ＝１０００００ＫＢ（ｕ＊ｓ１）と、１０００００＊１０＊１００Ｂ＝１０００００ｋＢ（ｕ＊ｌ＊ｓ２）の合計すなわち、総計２０００００ｋＢになる。そうではなく、個々の株式相場を別々のフラグメントとして保管する場合には、キャッシュ・サイズは、ユーザ固有フラグメントについて１０００００×１ｋＢ＝１０００００ｋＢ（ｕ＊ｓ１）と、株式相場フラグメントの１０００＊１００Ｂ＝１００ｋＢ（ｓ＊ｓ２）、合計１００１００ＫＢになる。これは、株式相場が複製されないので、約２倍のサイズ削減である。
【０２８２】
株式ウォッチリストのシナリオを、フラグメントのＦＯＲＥＡＣＨ機能を使用してさらに改善することができる。この場合には、すべてのユーザ固有フラグメントが除去される。これも、図４９に示されている。ＦＯＲＥＡＣＨ機能によって、「＝」によって区切られた名前／値対のスペースで区切られたリストを値に持つクッキーが指定される。名前／値対のそれぞれについて、ＵＲＩ照会パラメータとして名前／値対を追加されたフラグメントが生成される。このシナリオでは、「ｓｔｏｃｋｓ」という名前のクッキーが、たとえば「ｓｙｍｂｏｌ＝ＩＢＭ  ｓｙｍｂｏｌ＝ＣＳＣＯ  ｓｙｍｂｏｌ＝ＤＥＬＬ」など、値として株式シンボル・パラメータのリストを有する。これによって、クッキーの株式シンボルごとに１つの、３つのフラグメントが生成される。キャッシュのサイズは、単一のユーザ固有でないテンプレート・フラグメントの１ｋＢ（ｓ１）と、株式相場フラグメントの１００ｋＢ（ｓ＊ｓ２）、合計１０１ｋＢである。これは、ユーザ固有株式リスト・フラグメントが単一の株式リスト・フラグメントに置換されるので、約１０００倍のサイズ削減である。
【０２８３】
本発明の好ましい実施形態によって、キャッシュ内容を維持するのに必要な作業の量も減る。特定の応用例で何がフラグメントを構成するかを選択する判断基準の１つが、コンテンツの諸部分が変更される頻度である。コンテンツが、手動で毎回公開するには高すぎる頻度で変更される時には、アプリケーションによって、通常は、コンテンツを生成するためにデータベースにアクセスするテンプレート、たとえばＪＳＰ、ならびにデータベースが変更されるかタイム・リミットが満了する時にコンテンツを自動的に無効化する機構が使用される。このダイナミック・コンテンツ手法によって、人手がループから外され、頻繁な更新が可能になる。
【０２８４】
現在、ほとんどのキャッシュが、通常はダイナミック・コンテンツが示されるので、照会パラメータを有する要求をキャッシングしない。しかし、ダイナミック・コンテンツは、キャッシングのよい候補であることがしばしばである。コンテンツは、ある速度で変化する（たとえば、価格が週ごとに変更される場合があり、ミューチュアル・ファンドが毎日変更され、株価が数分ごとに変化する）が、変更の間に多数のキャッシュ・ヒットがあり、キャッシングが、しばしばかなりの性能向上を提供する可能性がある。
【０２８５】
コンテンツがすばやく変更され得る時に、各変更によって引き起こされる作業を減らすことが重要になる。ページをフラグメントに分割することによって、コンテンツの増分生成が可能になる。変更が発生する時に、これらのページのみのこれらの部分だけが、直接に影響を受けて、もう一度生成されなければならない。あるコンテンツがすばやく変化する場合に、それを別々のフラグメントにすることができる。
【０２８６】
図４６のサイドバーのシナリオをもう一度参照すると、サイドバーに、たとえばニュースの見出しなど、数分ごとに変更されるコンテンツが含まれる。完全に展開されたページが保管される場合に、サイドバーが変更される時に、すべてのページをもう一度生成し、置換しなければならない。そうではなく、サイドバーが別々のフラグメントである場合には、サイドバーが変更される時に、１つのフラグメントだけを生成し、置換すればよい。
【０２８７】
図４７の買物客グループのシナリオをもう一度参照すると、買物客グループの価格は、買物客グループ内の販売量に基づいて、毎分変更される可能性がある。完全に展開されたページが保管される場合に、５００００ページのすべてを、毎分生成しなければならない。これは、毎分５０００００ｋＢのキャッシュの生成および置換を引き起こす。その代わりに、価格を別々のフラグメントとして保管する場合には、５００００個のフラグメントが生成され、置換されるが、５０００ｋＢのキャッシュだけが、生成され、置換される。これは、必要な帯域幅の１００倍の削減である。製品説明の価格以外の態様が変更される場合には、５ページではなく、１つのフラグメントだけを生成し、置換する必要がある。これは、帯域幅の５倍の削減である。
【０２８８】
図４８のパーソナライゼーションのシナリオをもう一度参照すると、製品が、数分ごとに変更される可能性があり、ユーザ固有のパーソナライゼーションが、毎日変更される可能性がある。展開されたページをキャッシングする場合に、各製品の変更によって、その製品に関する１０００００ページのすべてが生成され、置換され、各パーソナライゼーションの変更によって、そのユーザに関する１００００ページのすべてが生成され、置換される。その代わりに、製品説明およびパーソナライゼーションが、別々のフラグメントに保管される場合には、各製品の変更が、１つのフラグメントだけの生成および置換を引き起こし（１０００００倍の改善）、各パーソナライゼーションの変更が、１つのフラグメントだけの生成および置換を引き起こす（１００００倍の改善）。
【０２８９】
図４９の株式ウォッチリストのシナリオをもう一度参照すると、株価は、２０秒ごとに変化する可能性がある。展開されたページがキャッシュに保管される場合には、１０００００個のユーザ・ページのすべて（１０００００ｋＢ）を、２０秒ごとに生成しなければならない。その代わりに、株式を別々のフラグメントとして保管する場合には、１０００個の株式フラグメントだけ（１００ｋＢ）を、２０秒ごとに生成し、置換しなければならない。これは、帯域幅の１０００倍以上の改善である。単一のユーザの株式ウォッチリストが修正される、たとえば、ユーザが、ウォッチリストに株式を追加するか削除する場合に、どちらの場合でも、１つのフラグメントだけを生成し、置換する必要がある。
【０２９０】
フラグメント・キャッシュ識別子の生成および使用の例
上で説明したように、各フラグメントをキャッシングする方法を指示するキャッシング情報が、そのフラグメントに関連する。静的コンテンツの場合に、キャッシング情報は、各フラグメントに関連する。ダイナミック・コンテンツは、テンプレートまたはプログラム（ＪＳＰ、ＣＧＩなど）によって生成され、キャッシング情報は、このテンプレートに関連する。これは、一定の情報とすることができ、その結果、テンプレートによって生成されるすべてのフラグメントが、同一の値を有するようになる。その代わりに、テンプレートが、キャッシング情報を決定するコードを有することができ、その結果、キャッシング情報が、あるアルゴリズムに基づいて、生成されるフラグメントごとに異なるものになる。どちらの場合でも、特定のフラグメントは、一定の値を有する。
【０２９１】
フラグメントは、コンテンツの別の部分と組み合わせるために区切られた、コンテンツの部分として定義することができる。標準化されたフラグメント命名技法が、本発明の好ましい実施形態で使用される。この技法では、上で形式的に説明した技法に従ってキャッシュＩＤが生成される。このセクションでは、下でさらに一連の例を介してキャッシュＩＤの使用を説明するが、キャッシュＩＤの形成および決定の短い要約を、まず示す。
【０２９２】
キャッシュでは、ある形でキャッシュＩＤを使用してフラグメントが保管される。キャッシュＩＤに、キャッシュを使用するすべてのアプリケーションの間で一意になるのに十分な情報が含まれなければならない。たとえば、製品ＩＤだけでは、別の店の製品ＩＤまたは完全に別のものと衝突する可能性がある。フラグメントのＵＲＩパスによって、通常は、少なくとも部分的にこれと同一の名前スコーピング問題に対処しなければならないので、フラグメントのキャッシュＩＤの一部としてＵＲＩパスを含めることが便利である。
【０２９３】
キャッシュＩＤの情報内容によって、下記の例に示されているように、フラグメントがどれほど幅広く共用されるかが決定される。
（Ａ）ユーザＩＤがキャッシュＩＤに含まれる場合に、そのフラグメントは、そのユーザだけのために使用される。
（Ｂ）買物客グループＩＤがキャッシュＩＤに含まれる場合に、そのフラグメントは、その買物客グループのすべてのメンバの間で共用される。
（Ｃ）ユーザＩＤおよび買い物客グループＩＤの両方がキャッシュＩＤに含まれない場合に、そのフラグメントは、すべてのユーザの間で共用される。
【０２９４】
ウェブ・アプリケーション開発者は、フラグメントのキャッシュＩＤに何が含まれるかを指示するＣＡＣＨＥＩＤディレクティブを有するフラグメントのＨＴＴＰ  ＦＲＡＧＭＥＮＴヘッダ内の規則によって、キャッシュＩＤの情報内容を指定することができる。規則を用いると、ＵＲＩ照会パラメータまたはクッキーをＵＲＩパスに付加できるようになり、あるいは、フルＵＲＩ（照会パラメータを含む）が可能になる。規則の不在は、キャッシングなしを意味しない。複数の規則が使用される時には、規則が、出現順で試行される。働く最初の規則によって、キャッシュＩＤが決定される。どの規則も働かない場合には、フラグメントはキャッシングされない。照会パラメータまたはクッキーがキャッシュＩＤに含まれる時に、これを、次のように、必須または任意選択のいずれかとすることができる。
（Ａ）親の要求に存在しない必須照会パラメータによって、規則が失敗になる。
（Ｂ）親の要求または結果に存在しない必須クッキーによって、規則が失敗になる。
（Ｃ）存在しない任意選択の照会パラメータまたはクッキーは、キャッシュＩＤに含まれない。
【０２９５】
キャッシュＩＤは、なんらかの標準規格で大文字小文字を区別しないと宣言された部分以外は、大文字小文字の区別がある。ＨＴＴＰ仕様では、ＵＲＩのプロトコルおよびホスト名が、大文字小文字の区別がないが、ＵＲＩの残りは、照会パラメータ名を含めて大文字小文字の区別があるとされている。仕様書、「HTTP State Management Mechanism」、RFC 2109、Internet Engineering TaskForce、1997年2月によれば、クッキー名は、大文字小文字の区別がない。キャッシュ実施形態では、これらの大文字小文字の区別がない部分を、大文字小文字のどちらかに均一に変換することによって、簡単にこれを実施することができる。本発明の好ましい実施形態のフラグメント・キャッシング技法では、照会パラメータ値およびクッキー値を大文字小文字の区別があるものとすることが好ましい。
【０２９６】
図５０から５７に関して、一連の図を使用して、本発明の好ましい実施形態の教示によって、フラグメントの保管および処理のために一意のキャッシュ識別子が構成され、使用される形を示す。
【０２９７】
図５０を参照すると、あるサイトのすべての親フラグメントに、同一のサイドバー子フラグメントが含まれる。親フラグメントは、このシナリオでは、すべての親に同一のサイドバー・フラグメントが含まれること以外は指定されず、したがって、子フラグメントだけが問題になる。子フラグメントは、そのＵＲＩによって論理的に修飾される。これは静的コンテンツなので、キャッシュＩＤはフルＵＲＩである。キャッシュＩＤ規則は次の通りである。
Fragment:cacheid="URI"
【０２９８】
言い換えると、キャッシュＩＤは、すべての照会パラメータを含むフルＵＲＩである。キャッシュＩＤの例を示す。
http://www.acmeStore.com/sidebar.html
【０２９９】
図５１を参照すると、製品説明ページに、組込みフラグメントまたは子フラグメントが含まれない、すなわち、このページは、唯一のフラグメントである。これは、ｐｒｏｄｕｃｔＩＤによって論理的に修飾される。ページＵＲＩは、ｐｒｏｄｕｃｔＩＤ照会パラメータを有する。ページ要求は、ログオン中にウェブ・アプリケーション・サーバによって作成される暗号化されたｕｓｅｒＩＤクッキーを有する。ｕｓｅｒＩＤクッキーによって、ユーザ固有状態（ショッピング・カート、ユーザ・プロファイルなど）をユーザに関連付けられるようになる。ｕｓｅｒＩＤは、照会パラメータではなくクッキーとして使用される。というのは、これがほとんどすべての要求で使用される可能性があり、ウェブ・アプリケーション開発者がすべてのリンクにこれを置くことが、単調で退屈になるからである。製品ページの単一のキャッシュＩＤ規則では、キャッシュＩＤとして、ｐｒｏｄｕｃｔＩＤ照会パラメータを含むフルＵＲＩが使用され、その結果、正しい修飾を用いてキャッシングできるようになる。この単一フラグメント・ページについて、キャッシュＩＤをそのＵＲＩとすることができる。キャッシュＩＤ規則を示す。
Fragment:cacheid="URI"
【０３００】
言い換えると、キャッシュＩＤは、すべての照会パラメータを含むフルＵＲＩである。キャッシュＩＤの例を示す。
http://www.acmeStore.com/productDesc.jsp?productID=AT13394
【０３０１】
このトップレベル・フラグメントのキャッシュＩＤを指定するもう１つの形は、ＵＲＩ照会パラメータである、商人によって使用される製品ＩＤ、たとえばＡＴ１３３９４と、一意性を保証する一定のＵＲＩパス、たとえばｈｔｔｐ：／／ｗｗｗ．ａｃｍｅＳｔｏｒｅ．ｃｏｍ／ｐｒｏｄｕｃｔＤｅｓｃである。この場合に、キャッシュＩＤ規則は次のようになる。
Fragment:cacheid="(productId)"
【０３０２】
言い換えると、キャッシュＩＤは、下記の部分を一緒に連結したものである。
（Ａ）ＵＲＩパス
（Ｂ）ｐｒｏｄｕｃｔＩＤ照会パラメータの名前および値
【０３０３】
規則に角型括弧がないことによって、ｐｒｏｄｕｃｔＩＤパラメータが存在しなければならないことが示される。これが存在しないと、規則が失敗し、フラグメントがキャッシングされなくなる。キャッシュＩＤの例を示す。
http://www.acmeStore.com/productDesc.jsp_productID=AT13394
【０３０４】
やはり、ウェブ・アプリケーション設計者が、正確なフォーマットではなく、キャッシュＩＤの情報内容だけを指定することに留意されたい。キャッシュ実施形態では、指定された情報内容をキャッシュＩＤにエンコードする、それ自体の形を選択することができる。上の例では、区切り文字として下線文字（「＿」）を用いる単純な連結が使用されている。ウェブ・アプリケーション開発者は、このエンコーディングを知る必要がない。
【０３０５】
図５２を参照すると、製品説明のシナリオの拡張が示されている。価格が、ユーザが属する買物客グループによって決定されるが、製品説明の残りは、買物客グループと独立である。親製品説明フラグメントに、子価格フラグメントが含まれる。親は、ｐｒｏｄｕｃｔＩＤによって論理的に修飾される。子は、ｐｒｏｄｕｃｔＩＤおよびｇｒｏｕｐＩＤによって論理的に修飾される。ページＵＲＩは、ｐｒｏｄｕｃｔＩＤ照会パラメータを有する。ページ要求は、暗号化されたｕｓｅｒＩＤクッキーおよびｇｒｏｕｐＩＤクッキーを有する。ｇｒｏｕｐＩＤクッキーは、ログオン中にユーザ・プロファイルに基づいてウェブ・アプリケーションによって作成される。ｇｒｏｕｐＩＤは、ほとんどすべての要求で使用される可能性があり、ウェブ・アプリケーション開発者がすべてのリンクにこれを置くことが、単調で退屈になるので、照会パラメータではなくクッキーにされる。
【０３０６】
価格は、親によってインクルードされる別々の子フラグメントにしなければならない。親フラグメントに関する単一のキャッシュＩＤ規則は、製品表示のシナリオと同一である。子フラグメントに関する単一のキャッシュＩＤ規則では、ｐｒｏｄｕｃｔＩＤ照会パラメータおよびｇｒｏｕｐＩＤクッキーと共にＵＲＩパスを使用し、その結果、正しい修飾を用いてキャッシングできるようになる。フラグメントは、同一の買物客グループに属するすべてのユーザではなく単一のユーザによってのみ使用可能であり、これによって、はるかに大きいキャッシュおよびキャッシュを更新された状態に保つより多くの作業がもたらされるので、キャッシュＩＤにユーザＩＤが含まれないことに留意されたい。キャッシュＩＤ規則は、次のようになる。
Fragment:cacheid="(productID, [groupID])"
【０３０７】
言い換えると、キャッシュＩＤは、下記の部分を一緒に連結したものになる。
（Ａ）ＵＲＩパス
（Ｂ）ｐｒｏｄｕｃｔＩＤ照会パラメータの名前および値
（Ｃ）要求に存在する場合に、ｇｒｏｕｐＩＤクッキーの名前および値
【０３０８】
コンマによって、ＵＲＩ照会パラメータがクッキーから分離される。規則の角型括弧によって、クッキーが任意選択であることが示される。このクッキーが存在しない場合に、規則はそれでも成功し、キャッシュＩＤに、クッキーの名前／値対が含まれなくなる。これによって、商人が、非グループ価格ならびにグループごとの価格を有することが可能になる。キャッシュＩＤの例を示す。
http://www.acmeStore.com/productDesc.jsp_productID=AT13394_groupID=* @#!
【０３０９】
図５３を参照すると、買物客グループ・シナリオの拡張が示されている。複数の商人のサポートが追加されており、たとえば、アプリケーション・サービス・プロバイダ（ＡＳＰ）が、同一のウェブ・アプリケーション・サーバで複数の言語を使用する複数の商人をサポートする。親製品説明フラグメントに、やはり子価格フラグメントが含まれる。親は、ｐｒｏｄｕｃｔＩＤ、ｍｅｒｃｈａｎｔＩＤ、およびｌａｎｇｕａｇｅＩＤによって論理的に修飾される。子は、ｐｒｏｄｕｃｔＩＤ、ｇｒｏｕｐＩＤ、ｌａｎｇｕａｇｅＩＤ、およびｍｅｒｃｈａｎｔＩＤによって論理的に修飾される。ページＵＲＩは、ｐｒｏｄｕｃｔＩＤ照会パラメータおよびｍｅｒｃｈａｎｔＩＤ照会パラメータを有する。要求は、ｕｓｅｒＩＤクッキー、ｇｒｏｕｐＩＤクッキー、およびｌａｎｇｕａｇｅＩＤクッキーを有する。ｌａｎｇｕａｇｅＩＤクッキーは、ログオン中にユーザ・プロファイルに基づいてウェブ・アプリケーションによって作成される。ｌａｎｇｕａｇｅＩＤは、すべての要求で使用され、ウェブ・アプリケーション開発者がすべてのリンクにこれを置くことが、単調で退屈になるので、照会パラメータではなくクッキーにされる。
【０３１０】
親フラグメントの単一のキャッシュＩＤ規則では、ｐｒｏｄｕｃｔＩＤおよびｍｅｒｃｈａｎｔＩＤ照会パラメータ、ならびにｌａｎｇｕａｇｅＩＤクッキーと共にＵＲＩパスを使用し、したがって、正しい修飾を用いてキャッシングできるようになる。親キャッシュＩＤ規則は、次のようになる。
Fragment:cacheid="(productID merchantID, [languageID])"
【０３１１】
言い換えると、キャッシュＩＤは、下記の部分を一緒に連結したものになる。
（Ａ）ＵＲＩパス
（Ｂ）ｐｒｏｄｕｃｔＩＤ照会パラメータの名前および値
（Ｃ）ｍｅｒｃｈａｎｔＩＤ照会パラメータの名前および値
（Ｄ）要求に存在する場合に、ｌａｎｇｕａｇｅＩＤクッキーの名前および値
【０３１２】
親キャッシュＩＤの例を示す。
http://www.acmeMall.com/productDesc.jsp_productID=ATl3394_merchantID=MyStore_languageID=eng
【０３１３】
子フラグメントの単一のキャッシュＩＤ規則では、ｐｒｏｄｕｃｔＩＤおよびｍｅｒｃｈａｎｔＩＤ照会パラメータならびにｇｒｏｕｐＩＤおよび任意選択のｌａｎｇｕａｇｅＩＤクッキーと共にＵＲＩを使用し、したがって、正しい修飾を用いてキャッシングすることができる。キャッシュＩＤ規則は、次のようになる。
Fragment:cacheid="(productID merchantID,[groupID] [languageID])"
【０３１４】
言い換えると、キャッシュＩＤは、下記の部分を一緒に連結したものになる。
（Ａ）ＵＲＩパス
（Ｂ）ｐｒｏｄｕｃｔＩＤ照会パラメータの名前および値
（Ｃ）ｍｅｒｃｈａｎｔＩＤ照会パラメータの名前および値
（Ｄ）要求に存在する場合に、ｇｒｏｕｐＩＤクッキーの名前および値
（Ｅ）要求に存在する場合に、ｌａｎｇｕａｇｅＩＤクッキーの名前および値
キャッシュＩＤの例を示す。
http://www.acmeMall.com/productDesc.jsp_productID=AT13394_merchantID=MyStore_groupID=*@#!_languageID=eng
【０３１５】
図５４を参照すると、ＡＳＰおよび複数言語のシナリオの拡張が示されている。製品を識別する複数の形のサポートが追加されている。親製品説明フラグメントに、子価格フラグメントが含まれる。親は、製品（これを指定する２つの形がある）、ｌａｎｇｕａｇｅＩＤ、およびｍｅｒｃｈａｎｔＩＤによって論理的に修飾される。子は、製品、ｇｒｏｕｐＩＤ、ｌａｎｇｕａｇｅＩＤ、およびｍｅｒｃｈａｎｔＩＤによって論理的に修飾される。製品は、ｐｒｏｄｕｃｔＩＤ照会パラメータによって、またはｐａｒｔＮｕｍｂｅｒ照会パラメータおよびｓｕｐｐｌｉｅｒＮｕｍｂｅｒ照会パラメータによってのいずれかで識別される。要求は、ｕｓｅｒＩＤクッキー、ｇｒｏｕｐＩＤクッキー、およびｌａｎｇｕａｇｅＩＤクッキーを有する。親フラグメントは、下記のように指定される２つの規則を必要とする。
Fragment: cacheid=
"(productIDmerchantID, [languageID])
(partNumbersupplierNumber merchantID, [languageID])"
【０３１６】
第１の規則が試行される。それに成功した場合には、それによってキャッシュＩＤが決定される。失敗の場合には、第２の規則が試行される。第２の規則が成功の場合には、それによってキャッシュＩＤが決定される。失敗の場合には、フラグメントはキャッシングされない。第１の規則は、キャッシュＩＤが下記の部分を一緒に連結したものであることを意味する。
（Ａ）ＵＲＩパス
（Ｂ）ｐｒｏｄｕｃｔＩＤ照会パラメータの名前および値
（Ｃ）ｍｅｒｃｈａｎｔＩＤ照会パラメータの名前および値
（Ｄ）要求に存在する場合に、ｌａｎｇｕａｇｅＩＤクッキーの名前および値
第１の規則のキャッシュＩＤの例を示す
http://www.acmeStore.com/productDesc.jsp_productID=AT13394_merchantID=MyStore_languageID=eng
【０３１７】
第２の規則は、キャッシュＩＤが下記の部分を一緒に連結したものであることを意味する。
（Ａ）ＵＲＩパス
（Ｂ）ｐａｒｔＮｕｍｂｅｒ照会パラメータの名前および値
（Ｃ）ｓｕｐｐｌｉｅｒＮｕｍｂｅｒ照会パラメータの名前および値
（Ｄ）ｍｅｒｃｈａｎｔＩＤ照会パラメータの名前および値
（Ｅ）要求に存在する場合に、ｌａｎｇｕａｇｅＩＤクッキーの名前および値
【０３１８】
第２の規則のキャッシュＩＤの例を示す
http://www.acmeStore.com/productDesc.jsp_partNumber=22984Z_supplierNumber=339001_merchantID=MyStore_languageID=eng
【０３１９】
子フラグメントは、下記のように指定される２つの規則を必要とする
Fragment: cacheid=
"(productIDmerchantID, [groupID] [languageID])
(partNumbersupplierNumber merchantID, [groupID] [languageID])"
【０３２０】
第１の規則が試行される。それに成功した場合には、それによってキャッシュＩＤが決定される。失敗の場合には、第２の規則が試行される。第２の規則が成功の場合には、それによってキャッシュＩＤが決定される。失敗の場合には、フラグメントはキャッシングされない。第１の規則は、キャッシュＩＤが下記の部分を一緒に連結したものであることを意味する。
（Ａ）ＵＲＩパス
（Ｂ）ｐｒｏｄｕｃｔＩＤ照会パラメータの名前および値
（Ｃ）ｍｅｒｃｈａｎｔＩＤ照会パラメータの名前および値
（Ｄ）要求に存在する場合に、ｇｒｏｕｐＩＤクッキーの名前および値
（Ｅ）要求に存在する場合に、ｌａｎｇｕａｇｅＩＤクッキーの名前および値
【０３２１】
第１の規則のキャッシュＩＤの例を示す。
http://www.acmeStore.com/productDesc.jsp_productID=AT13394_merchantID=MyStore_groupID=*@#!_languageID=eng
【０３２２】
第２の規則は、キャッシュＩＤが下記の部分を一緒に連結したものであることを意味する。
（Ａ）ＵＲＩパス
（Ｂ）ｐａｒｔＮｕｍｂｅｒ照会パラメータの名前および値
（Ｃ）ｓｕｐｐｌｉｅｒＮｕｍｂｅｒ照会パラメータの名前および値
（Ｄ）ｍｅｒｃｈａｎｔＩＤ照会パラメータの名前および値
（Ｅ）ｇｒｏｕｐＩＤクッキーの名前および値
（Ｆ）ｌａｎｇｕａｇｅＩＤクッキーの名前および値
【０３２３】
第２の規則のキャッシュＩＤの例を示す。
http://www.acmeStore.com/productDesc.jsp_partNumber=22984Z_supplierNumber=339001_merchantID=MyStore_groupID=*@#!_language=eng
【０３２４】
図５５を参照すると、製品説明シナリオの、パーソナライゼーションを使用する拡張が示されている。親製品説明フラグメントに、子パーソナライゼーション・フラグメントが含まれる。親フラグメントは、ｐｒｏｄｕｃｔＩＤによって論理的に修飾される。子フラグメントは、ｕｓｅｒＩＤによって論理的に修飾される。ページＵＲＩは、ｐｒｏｄｕｃｔＩＤ照会パラメータを有する。要求は、ｕｓｅｒＩＤクッキーを有する。
【０３２５】
親キャッシュＩＤに、ｐｒｏｄｕｃｔＩＤ照会パラメータが含まれる。親フラグメントのキャッシュＩＤ規則は、下記の２つの事例のいずれかになる。
Fragment:cacheid="URI"
【０３２６】
言い換えると、このキャッシュＩＤは、すべての照会パラメータを有するフルＵＲＩである。もう１つの潜在的な規則は、次のようになる。
Fragment:cacheid="(productId)"
【０３２７】
言い換えると、このキャッシュＩＤは、下記の部分を一緒に連結したものになる。
（Ａ）ＵＲＩパス
（Ｂ）ｐｒｏｄｕｃｔＩＤ照会パラメータの名前および値
【０３２８】
このページに関する要求に、ｕｓｅｒＩＤクッキーが含まれるが、フラグメントが製品固有であってユーザ固有ではないので、両方のフラグメントのキャッシュＩＤにｕｓｅｒＩＤが含まれないことに留意されたい。含まれる場合には、このフラグメントが、そのユーザだけによってアクセス可能になり、より大きいキャッシュとキャッシュを更新された状態に保つより多くの作業がもたらされる。キャッシュＩＤの例を示す。
http://www.acmeStore.com/productDesc.jsp_productID=AT13394
【０３２９】
子パーソナライゼーション・フラグメントのキャッシュＩＤには、ｕｓｅｒＩＤクッキーが含まれる。子フラグメントのキャッシュＩＤを示す。
Fragment:cacheid="(, userId)"
【０３３０】
言い換えると、キャッシュＩＤは、下記の部分を一緒に連結したものになる。
（Ａ）ＵＲＩパス
（Ｂ）ｕｓｅｒＩＤクッキーの名前および値
キャッシュＩＤの例を示す。
http://www.acmeStore.com/personalization.jsp_userID=@($*!%
【０３３１】
このパーソナライゼーションの例では、パーソナライゼーション・フラグメントを、たとえば「Ｃａｃｈｅ−Ｃｏｎｔｒｏｌ：ｐｒｉｖａｔｅ」を使用して、プライベート・データとしてマークしなければならない。
【０３３２】
図５６を参照すると、単一のポータル・ページの親株式ウォッチリスト・フラグメントに、複数の子株式相場フラグメントが含まれる。親フラグメントには、単純なパーソナライゼーションとして、ユーザの名前が含まれる。親は、ｕｓｅｒＩＤによって論理的に修飾される、すなわち、株式シンボルのリストは、ユーザ固有である。ユーザ名は、ｕｓｅｒＩＤによって論理的に修飾される。各子は、株式シンボルによって論理的に修飾される、すなわち、株の値は、ユーザ固有でない。ページＵＲＩに、照会パラメータは含まれない。要求は、ｕｓｅｒＩＤクッキーを有する。
【０３３３】
トップレベル・フラグメントに、株式相場の要求されるユーザ固有リストが含まれる。トップレベル・フラグメントのＵＲＩに、照会パラメータは含まれない。トップレベル・フラグメントのキャッシュＩＤに、ｕｓｅｒＩＤという名前の暗号化されたクッキーが含まれる。キャッシュＩＤ規則は、次のようになる。
Fragment:cacheid="(, userId)"
【０３３４】
言い換えると、キャッシュＩＤは、下記の部分を一緒に連結したものになる。
（Ａ）ＵＲＩパス
（Ｂ）ｕｓｅｒＩＤクッキーの名前および値
【０３３５】
キャッシュＩＤの例を示す
http://www.acmeInvest.com/stockList.jsp_userID=@($*!%
【０３３６】
株式相場フラグメントのそれぞれについて、キャッシュＩＤに、「シンボル」パラメータが含まれる。キャッシュＩＤ規則は、フルＵＲＩか、ＵＲＩパスにｓｔｏｃｋＳｙｍｂｏｌ照会パラメータを加えたものになる。
Fragment:cacheid="(stockSymbol)"
【０３３７】
言い換えると、キャッシュＩＤは、下記の部分を一緒に連結したものになる。
（Ａ）ＵＲＩパス
（Ｂ）シンボル照会パラメータの名前および値
【０３３８】
キャッシュＩＤの例を示す
http://www.acmeInvest.com/stockQuote.jsp_stockSymbol=IBM
【０３３９】
このシナリオを修正して、ＦＯＲＥＡＣＨ機能を使用することができ、株式相場フラグメントは変更されないが、親フラグメントを非常に最適化することができる。静的トップレベル・フラグメントが１つだけある。ｓｔｏｃｋＳｙｍｂｏｌｓクッキーが使用され、その値は、ユーザに関する株式シンボルの、空白によって区切られたリストである。すべてのユーザについて、非常に静的な１つの親フラグメントだけがあり、この親フラグメントに、そのＦＯＲＥＡＣＨ属性によってｓｔｏｃｋＳｙｍｂｏｌｓクッキーの名前が指定されるＦＲＡＧＭＥＮＴＬＩＮＫタグが含まれる。これによって、株式シンボルが照会パラメータとして追加されたＦＯＲＥＡＣＨ属性を含むＦＲＡＧＭＥＮＴＬＩＮＫのＳＲＣと同一のＳＲＣ属性を有する株式シンボルごとの単純なＦＲＡＧＭＥＮＴＬＩＮＫタグが動的に生成される。この親フラグメントは、すべてのユーザについて同一なので、そのＵＲＩをキャッシュＩＤとして使用し、照会パラメータがない、下記のような単一のキャッシュ規則による正しい修飾を用いてキャッシングすることができる。
Fragment: cacheid="URI"
【０３４０】
ｓｔｏｃｋＳｙｍｂｏｌｓクッキーに、親フラグメントに関するすべてのユーザ固有情報が含まれ、ｓｔｏｃｋＳｙｍｂｏｌｓクッキーは、ページ要求と共に移動し、したがって、親の論理ｕｓｅｒＩＤ修飾を満足する。
【０３４１】
ユーザの名前を値として有するｕｓｅｒＮａｍｅクッキーが、ＳＲＣ属性によってuserNameクッキーが識別される単純なパーソナライゼーションのためにＦＲＡＧＭＥＮＴＬＩＮＫタグで使用される。このフラグメントは、ｕｓｅｒＮａｍｅクッキーから簡単に生成できるので、キャッシングされない。ｕｓｅｒＮａｍｅクッキーには、このフラグメントに関するすべてのユーザ関連情報が含まれ、ｕｓｅｒＮａｍｅクッキーは、ページ要求と共に移動し、したがって、親の論理ｕｓｅｒＩＤ修飾を満足する。子フラグメントの単一のキャッシュＩＤ規則では、キャッシュＩＤについてそのＵＲＩを使用し、その結果、次のように正しい修飾を用いてキャッシングできるようになる。
Fragment:cacheid="URI"
【０３４２】
この株式ウォッチリストのシナリオでは、ＦＯＲＥＡＣＨ機能が使用されない時に、トップレベル株式ウォッチリスト・フラグメントが、たとえば「Ｃａｃｈｅ−Ｃｏｎｔｒｏｌ：ｐｒｉｖａｔｅ」を使用して、プライベートとマークされる。ＦＯＲＥＡＣＨ機能が使用される時には、共用されるトップレベル・フラグメントが１つだけあり、したがって、これはプライベートとマークされない。
【０３４３】
図５７を参照し、この例によって、ｍｙＹａｈｏｏ！などのパーソナライズされたポータル・ページに似たシナリオを示す。第１レベル・ポータル・フラグメントに、株式、天気、スポーツなど、それぞれに複数の葉項目フラグメントが含まれる複数の中間レベル・トピック・フラグメントが含まれる。親フラグメントには、ユーザの名前も含まれる。トップレベル・ポータル・フラグメントは、ｕｓｅｒＩＤによって論理的に修飾される、すなわち、トピックのリストは、ユーザ固有である。ユーザ名は、ｕｓｅｒＩＤによって論理的に修飾される。中間レベル・トピック・フラグメントは、ｔｏｐｉｃＩＤおよびｕｓｅｒＩＤによって論理的に修飾される、すなわち、トピック内の項目のリストは、ユーザ固有である。葉項目フラグメントは、ｉｔｅｍＩＤによって論理的に修飾される、すなわち、項目の値は、ユーザ固有でない。ページＵＲＩに、照会パラメータは含まれない。ページ要求は、ｕｓｅｒＩＤクッキーを有する。ＦＯＲＥＡＣＨ機能の使用を介して、親フラグメントを非常に最適化することができる。
【０３４４】
ＦＯＲＥＡＣＨ機能を使用すると、ユーザに関するｔｏｐｉｃＩＤの空白で区切られたリストを値として有するｔｏｐｉｃｓクッキー（ログオン中にユーザ・プロファイルに基づいて作成される）が、使用される。すべてのユーザについて、非常に静的であり、ｔｏｐｉｃｓクッキーの名前を指定するＦＯＲＥＡＣＨ属性を有するＦＲＡＧＭＥＮＴＬＩＮＫタグを含む親フラグメントが、１つだけある。これによって、ｔｏｐｉｃＩＤごとに単純なＦＲＡＧＭＥＮＴＬＩＮＫが動的に生成され、そのＳＲＣ属性は、ｔｏｐｉｃＩＤを照会パラメータとして付加されたＦＯＲＥＡＣＨ属性を含むＦＲＡＧＭＥＮＴＬＩＮＫのＳＲＣと同一である。この親フラグメントは、すべてのユーザについて同一なので、下記のように照会パラメータを有しない、キャッシュＩＤとしてＵＲＩを使用する単一のキャッシュ規則を有する正しい修飾によってキャッシングすることができる。
Fragment:cacheid="URI"
【０３４５】
ｔｏｐｉｃｓクッキーに、親フラグメントのユーザ固有情報のすべてが含まれ、ｔｏｐｉｃｓクッキーは、ページ要求と共に移動し、したがって、親の論理ｕｓｅｒＩＤ修飾を満足する。ユーザの名前である値を有するｕｓｅｒＮａｍｅクッキーが、ｕｓｅｒＮａｍｅクッキーを識別するＳＲＣ属性を有する単純なパーソナライゼーションのＦＲＡＧＭＥＮＴＬＩＮＫで使用される。このフラグメントは、ｕｓｅｒＮａｍｅクッキーから簡単に生成できるので、キャッシングされない。ｕｓｅｒＮａｍｅクッキーに、このフラグメントのユーザ固有情報のすべてが含まれ、ｕｓｅｒＮａｍｅクッキーは、ページ要求と共に移動し、したがって、親の論理ｕｓｅｒＩＤ修飾を満足する。
【０３４６】
トピックごとに、トピック・フラグメントがある。ＦＯＲＥＡＣＨ機能のゆえに、トピック・フラグメントのそれぞれを、非常に最適化することができる。トピックごとに、ユーザおよびトピックのｉｔｅｍＩＤの空白で区切られたリストを値として有するクッキー（ログオン中にユーザ・プロファイルに基づいて作成される）が使用される。トピックごとに、非常に静的であり、そのトピックの対応するクッキーの名前を指定するＦＯＲＥＡＣＨ属性を有するＦＲＡＧＭＥＮＴＬＩＮＫを含む、すべてのユーザに関するトピック・フラグメントが１つだけある。これによって、ｉｔｅｍＩＤを照会パラメータとして追加された（ｔｏｐｉｃＩＤ照会パラメータは既にある）ＦＯＲＥＡＣＨ属性を含むＦＲＡＧＭＥＮＴＬＩＮＫのＳＲＣであるＳＲＣ属性を有するｉｔｅｍＩＤごとの単純なＦＲＡＧＭＥＮＴＬＩＮＫが動的に生成される。各トピック・フラグメントは、すべてのユーザについて同一なので、キャッシュＩＤとしてそのＵＲＩを使用し、照会パラメータとしてｔｏｐｉｃＩＤを有する、単一のキャッシュ規則による正しい修飾を用いてキャッシングすることができる。ｔｏｐｉｃｓクッキーに、トピック・フラグメントのユーザ固有情報のすべてが含まれ、ｔｏｐｉｃｓクッキーは、ページ要求と共に移動し、したがって、親の論理ｕｓｅｒＩＤ修飾を満足する。
【０３４７】
項目フラグメントごとのＵＲＩに、照会パラメータとしてｔｏｐｉｃＩＤおよびｉｔｅｍＩＤが含まれる。項目フラグメントごとの単一のキャッシュＩＤ規則では、キャッシュＩＤにそのＵＲＩが使用され、したがって、正しい修飾によってキャッシングすることができる。
【０３４８】
ＦＲＡＧＭＥＮＴＬＩＮＫタグの指定の例
図５０のサイドバーの例をもう一度参照すると、下記のように、単一のＦＲＡＧＭＥＮＴＬＩＮＫが、ページ内で、サイドバーの代わりに、サイドバーが望まれるのと同一の位置に配置される。
{fragmentlink
src="http://www.acmeStore.com/sidebar.html"}
【０３４９】
図５２の買物客グループの例をもう一度参照すると、下記のように、価格が配置される位置に単一のＦＲＡＧＭＥＮＴＬＩＮＫが配置される。
{fragmentlink
src="http://www.acmeStore.com/productPrice.jsp")
【０３５０】
特定の価格フラグメントについて構成されるＵＲＩは、次のようになる。
http://www.acmeStore.com/productPrice.jsp?productID=AT13394
【０３５１】
フラグメントに関する要求に、親の照会パラメータすなわち「ｐｒｏｄｕｃｔＩｄ」と、クッキーすなわち「ｇｒｏｕｐＩｄ」のすべてが含まれ、その結果、これらが、アプリケーション・サーバでのｐｒｏｄｕｃｔＰｒｉｃｅ．ｊｓｐの実行中に使用可能になる。
【０３５２】
図５５のパーソナライゼーションの例をもう一度参照すると、下記のように、トップレベル・フラグメントに、パーソナライゼーション・フラグメントが望まれる位置に配置されたＦＲＡＧＭＥＮＴＬＩＮＫが含まれる。
{fragmentlink
src="http://www.acmeStore.com/personalization.jsp"}
【０３５３】
特定のユーザ固有パーソナライゼーション・フラグメントに関して構成されるＵＲＩは、次のようになる。
http://www.acmeStore.com/personalization.jsp?productID=AT13394
【０３５４】
フラグメントに関する要求に、親の照会パラメータ（すなわち、「ｐｒｏｄｕｃｔＩｄ」）およびクッキー（すなわち、「ｕｓｅｒＩｄ」）のすべてが含まれる。ｐｅｒｓｏｎａｌｉｚａｔｉｏｎ．ｊｓｐの実行中に、「ｕｓｅｒＩｄ」クッキーは使用されるが、「ｐｒｏｄｕｃｔＩｄ」照会パラメータは無視される。
【０３５５】
図５６の株式ウォッチリストの例をもう一度参照すると、トップレベル・フラグメントに、ユーザが求める株式相場の数に依存する可変個数のＦＲＡＧＭＥＮＴＬＩＮＫタグが含まれる。各ＦＲＡＧＭＥＮＴＬＩＮＫタグは、株式相場がある場所に配置される。各ＦＲＡＧＭＥＮＴＬＩＮＫタグは、次のようになる。
{fragmentlink
src="http://www.acmeInvest.com/stockQuote.jsp?symbol=IBM"}
【０３５６】
特定の株式相場フラグメントについて構成されるＵＲＩは、次のようになる。
http://www.acmeInvest.com/stockQuote.jsp?symbol=IBM
【０３５７】
このシナリオを、ＦＯＲＥＡＣＨ機能を使用するように修正することができ、可変個数のＦＲＡＧＭＥＮＴＬＩＮＫタグが、株式シンボル・パラメータの空白で区切られたリストを値として有するクッキー（ｓｔｏｃｋｓ）の名前を指定するＦＯＲＥＡＣＨ属性を有する単一のＦＲＡＧＭＥＮＴＬＩＮＫタグに置換される。
{fragmentlink
src="http://www.acmeInvest.com/stockQuote.jsp"
foreach="stocks"}
【０３５８】
「ｓｔｏｃｋｓ」という名前のクッキーの値が、
symbol=IBM symbol=CSCOsymbol=DELL
である場合には、これが、下記のＦＲＡＧＭＥＮＴＬＩＮＫタグの組と同等になる。
{fragmentlink
src="http://www.acmeInvest.com/stockQuote.jsp?symbol=IBM"}
{fragmentlink
src="http://www.acmeInvest.com/stockQuote.jsp?symbol=CSCO"}
{fragmentlink
src="http://www.acmeInvest.com/stockQuote.jsp?symbol=DELL"}
【０３５９】
図５７のフル・ポータルの例をもう一度参照すると、ＦＯＲＥＡＣＨ機能を、すべてのユーザによって共用される単一の静的なトップレベル・フラグメントについて使用することができる。トップレベル・フラグメントのｕｓｅｒＮａｍｅは、ユーザの名前を含むｕｓｅｒＮａｍｅクッキーを識別する下記のＦＲＡＧＭＥＮＴＬＩＮＫを使用して含まれる。
{fragmentlinksrc="cookie://userName"}
【０３６０】
トップレベル・フラグメントは、トピックのユーザのリストを含むｔｏｐｉｃｓクッキーを識別するＦＯＲＥＡＣＨ属性を有するＦＲＡＧＭＥＮＴＬＩＮＫタグも有する。
{fragmentlink
src="http://www.acmePortal.com/portalPage.jsp"
foreach="topics"}
【０３６１】
このクッキーには、ｔｏｐｉｃＩＤのリストが含まれる。値が
topic=stockstopic=weather topic=tv
であるｔｏｐｉｃｓクッキーについて、上のＦＯＲＥＡＣＨ属性を含むＦＲＡＧＭＥＮＴＬＩＮＫによって、下記の単純なＦＲＡＧＭＥＮＴＬＩＮＫが生成される。
{fragmentlink
src="http://www.acmePortal.com/portalPage.jsp?topic=stocks"}
{fragmentlink
src="http://www.acmePortal.com/portalPage.jsp?topic=weather"}
{fragmentlink
src="http://www.acmePortal.com/portalPage.jsp?topic=tv"}
【０３６２】
動的に生成されるＳＲＣ属性のそれぞれによって、特定のトピックを処理するフラグメントが突き止められる。
【０３６３】
ウェブ・アプリケーション・サーバでの「ｐｏｒｔａｌＰａｇｅ．ｊｓｐ」の実施形態は、照会パラメータに基づいてフラグメントを呼び出すディスパッチャとして働く。どのパラメータも、トップレベル・フラグメントを返さない。「ｔｏｐｉｃ＝ｓｔｏｃｋｓ」照会パラメータによって、株式トピック・フラグメントが返される。例として株式トピック・フラグメントを使用し、やはりＦＯＲＥＡＣＨ機能を使用すると、株式トピック・フラグメントには、そのトピックに関する株式シンボルのユーザのリストを含む、ｓｔｏｃｋｓクッキーを識別するＦＯＲＥＡＣＨ属性を有するＦＲＡＧＭＥＮＴＬＩＮＫが含まれる。
{fragmentlink
src="http://www.stockQuotes.com/stockQuote.jsp"
foreach="stocks"}
これの例示的な使用は、ｓｔｏｃｋｓクッキーの株式シンボルごとに１行を有するテーブルの行の生成である。値が
symbol=IBM symbol=DELLsymbol=CSCO
である「ｓｔｏｃｋｓ」クッキーについて、ＦＯＲＥＡＣＨ属性を含む上のＦＲＡＧＭＥＮＴＬＩＮＫによって、下記のＦＲＡＧＭＥＮＴＬＩＮＫが動的に生成される。
{fragmentlink
src="http://www.stockQuotes.com/stockQuote.jsp?symbol=IBM"}
{fragmentlink
src="http://www.stockQuotes.com/stockQuote.jsp?symbol=DELL"}
{fragmentlink
src="http://www.stockQuotes.com/stockQuote.jsp?symbol=CSCO"}
【０３６４】
親フラグメントから子フラグメントへのデータ渡しの例
フラグメントは、できる限り自己完結型でなければならない。これには、２つの理由がある。第１の理由は、よいソフトウェア工学によって、ソフトウェア・モジュールをできる限り独立にしなければならないことが命令されることである。モジュールの間のコントラクトの数および複雑さを、最小限にし、その結果、あるモジュールの変更が、ローカルに保たれ、他のモジュールに伝搬しないようにしなければならない。たとえば、アプリケーションが、親モジュールでデータを取得し、このデータを子モジュールに渡し、子モジュールによってフォーマットする場合がある。これが行われる時に、データが何であり、それをどのようにして渡すかを記述するコントラクトが存在しなければならない。子モジュールが必要とするデータの変更は、両方のモジュールの変更を必要とする。その代わりに、子モジュールがそれ自体のデータを得るならば、変更がローカルに保たれる。モジュールをデータを入手する方法と独立にすること、またはデータを得るコードを複数のモジュールで同一にすることのいずれかの必要がある場合には、別々のデータ・ビーンおよび対応するコントラクトを使用して、この要件のいずれかを達成することができる。しかし、親モジュールと子モジュールの間に別のコントラクトを追加することによって、何も達成されずに複雑さだけが追加される。
【０３６５】
フラグメントをできる限り自己完結型にしなければならない第２の理由は、キャッシングを効率的にすることであり、フラグメントを生成するコードを、自己完結型にしなければならない。上の例では、親モジュールが、子モジュールのためのデータのすべてを得て、子に渡す場合に、子自体は、フォーマッティングだけを行う。モジュールの間にこの依存性があると、子モジュールが必要とするデータが古くなった場合に、親と子の両方が、無効化され、もう一度生成されなければならない。この依存性によって、別々のフラグメントのキャッシングが、はるかに効率的でなくなる。複数の親によって共用されるフラグメントによって、上の問題の両方が複雑になる。
【０３６６】
ＪＳＰプログラミング・モデルを用いると、要求属性またはセッション状態を介してＪＳＰの間でデータを渡せるようになる。入れ子になったフラグメントについて、要求属性機構は機能しない。というのは、親ＪＳＰおよび子ＪＳＰを、アプリケーション・サーバへの異なる要求で取り出すことができるからである。また、セッション状態機構は、親と子を異なるセッションで実行できる場合に、機能しない可能性がある。その代わりに、渡されなければならない情報のすべてで、ＵＲＩ照会パラメータまたはクッキーを使用しなければならない。要求属性を使用して親から子に渡された複雑なデータ構造であっても、それを直列化し、ＦＲＡＧＭＥＮＴＬＩＮＫタグのＳＲＣ属性にＵＲＩの照会パラメータとして含めることによって、渡すことができる。
【０３６７】
フラグメントが、それ自体のデータを得る時であっても、フラグメントの間である制御データを渡す必要がある。上の例をもう一度参照すると、サイドバーのシナリオで、トップレベル・フラグメントからサイドバーにデータが渡されない。買物客グループのシナリオでは、トップレベル製品説明フラグメントが、製品ＩＤを知る必要があり、子グループ製品固有価格が、製品ＩＤと買物客グループＩＤの両方を必要とする。製品ＩＤは、外部要求によって供給される。買物客グループＩＤは、ユーザＩＤを使用してアプリケーションによって生成され、この両方のＩＤが、ログオン時に生成される。製品ＩＤと買物客グループＩＤの両方を、製品説明フラグメントを介して価格フラグメントに渡さなければならない。すべてのＵＲＩ照会パラメータおよびクッキーが、子フラグメントに自動的に渡される。
【０３６８】
パーソナライゼーションのシナリオでは、トップレベル製品説明フラグメントが、製品ＩＤを知ることを必要とし、子パーソナライゼーション・フラグメントが、ユーザＩＤを知ることを必要とする。このパラメータの両方が、外部要求によって供給され、したがって、ユーザＩＤは、製品説明フラグメントを介してパーソナライゼーション・フラグメントに渡されなければならない。これは、「ｕｓｅｒＩｄ」という名前のクッキーを子フラグメントに渡すことによって行われる。
【０３６９】
株式ウォッチリストのシナリオでは、トップレベル株式ウォッチリスト・フラグメントが、ユーザＩＤクッキーを知ることを必要とし、子株式相場フラグメントのそれぞれが、株式シンボルを知ることを必要とする。株式シンボルおよびそれを含むＦＲＡＧＭＥＮＴＬＩＮＫタグが、トップレベル株式ウォッチリスト・フラグメントの一部として生成される。株式シンボルが、株式相場フラグメントに渡されなければならない。これは、ＦＲＡＧＭＥＮＴＬＩＮＫのＳＲＣ属性のＵＲＩの照会パラメータとして株式シンボルを置くことによって行われる。
【０３７０】
ＦＲＡＧＭＥＮＴＬＩＮＫタグおよびＦＲＡＧＭＥＮＴヘッダの例
表１から３に関して、ＨＴＭＬステートメントおよびＨＴＴＰステートメントの組を、上で述べたサイドバーの例について示す。このシナリオの両方のフラグメントが、静的である。親トップレベル・フラグメントは、「ｊｓｐ：ｉｎｃｌｕｄｅ」を使用して別のフラグメントを含み、キャッシュ制御情報を親フラグメントに関連付ける必要があるので、ＪＳＰになる。子サイドバー・フラグメントも、キャッシング制御情報を関連付ける必要があるのでＪＳＰになるが、ＪＳＰタグは一切含まれない。
【０３７１】
表１に、サイドバー・フラグメントを含むトップレベル・フラグメントのＨＴＭＬステートメントを含むＪＳＰを示す。
【０３７２】
【表１】
2005513640.tif 000002
【０３７３】
表２に、トップレベル・フラグメントについてウェブ・アプリケーション・サーバによって生成されるＨＴＴＰ出力を示す。
【０３７４】
【表２】
2005513640.tif 000003
【０３７５】
表３に、サイドバー・フラグメントについてウェブ・アプリケーション・サーバによって生成されるＨＴＴＰ出力を示す。
【０３７６】
【表３】
2005513640.tif 000004
【０３７７】
表４から７に関して、上で説明した買物客グループの例について、ＨＴＭＬステートメントおよびＨＴＴＰステートメントの組を示す。このシナリオの両方のフラグメントが、ダイナミックである。ＪＳＰが、製品グループ固有価格フラグメントを含むトップレベル・フラグメントに使用される。子フラグメントも、適当な価格を入手するビジネス・アプリケーション・ロジックが含まれるので、ＪＳＰである。
【０３７８】
表４に、子フラグメントを含むトップレベル製品説明フラグメントのＨＴＭＬステートメントを含むＪＳＰを示す。
【０３７９】
【表４】
2005513640.tif 000005
【０３８０】
表５に、製品説明フラグメントについてウェブ・アプリケーション・サーバによって生成されるＨＴＴＰ出力を示す。
【０３８１】
【表５】
2005513640.tif 000006
【０３８２】
表６に、子製品グループ固有価格フラグメントのＨＴＭＬステートメントを含むＪＳＰを示す。
【０３８３】
【表６】
2005513640.tif 000007
【０３８４】
表７に、製品グループ固有価格フラグメントについてウェブ・アプリケーション・サーバによって生成されるＨＴＴＰ出力を示す。
【０３８５】
【表７】
2005513640.tif 000008
【０３８６】
表８から１１に関して、上で述べたパーソナライゼーションの例について、ＨＴＭＬステートメントおよびＨＴＴＰステートメントの組を示す。このシナリオの両方のフラグメントが、ダイナミックである。トップレベル製品フラグメントを生成するＪＳＰに、単一のユーザ固有パーソナライゼーション・フラグメントが含まれる。子フラグメントも、ユーザに関する適当なパーソナライゼーション・データを得るビジネス・アプリケーション・ロジックが含まれるので、ＪＳＰである。
【０３８７】
表８に、子フラグメントを含むトップレベル製品説明フラグメントのＨＴＭＬステートメントを含むＪＳＰを示す。
【０３８８】
【表８】
2005513640.tif 000009
【０３８９】
表９に、製品説明フラグメントについてウェブ・アプリケーション・サーバによって生成されるＨＴＴＰ出力を示す。
【０３９０】
【表９】
2005513640.tif 000010
【０３９１】
表１０に、子ユーザ固有フラグメントのＨＴＭＬステートメントを含むＪＳＰを示す。
【０３９２】
【表１０】
2005513640.tif 000011
【０３９３】
表１１に、子フラグメントについてウェブ・アプリケーション・サーバによって生成されるＨＴＴＰ出力を示す。
【０３９４】
【表１１】
2005513640.tif 000012
【０３９５】
表１２から１７に関して、上で述べた株式ウォッチリストの例について、ＨＴＭＬステートメントおよびＨＴＴＰステートメントの組を示す。このシナリオのフラグメントの両方が、ダイナミックである。
【０３９６】
表１２に、複数の株式相場フラグメントを含むトップレベル株式ウォッチリスト・フラグメントを生成するＪＳＰを示す。「ｊｓｐｅｘｔ：ｃｏｏｋｉｅ」タグによって、「ｕｓｅｒＮａｍｅ」という名前のクッキーに含まれるユーザ名が表示される。この例では、可変個数の「ＲｅｑｕｅｓｔＤｉｓｐａｔｃｈｅｒ．ｉｎｃｌｕｄｅ」メソッド呼出しが動的に生成され、そのそれぞれによって、出力のＦＲＡＧＭＥＮＴＬＩＮＫタグが生成される。
【０３９７】
【表１２】
2005513640.tif 000013
【０３９８】
表１３に、株式ウォッチリスト・フラグメントについてウェブ・アプリケーション・サーバによって生成されるＨＴＴＰ出力を示す。
【０３９９】
【表１３】
2005513640.tif 000014
【０４００】
表１４に、ＦＯＲＥＡＣＨ属性が組み込まれるトップレベル株式ウォッチリスト・フラグメントを生成するＪＳＰを示す。
【０４０１】
【表１４】
2005513640.tif 000015
【０４０２】
表１５に、ＦＯＲＥＡＣＨ属性を組み込まれたトップレベル株式ウォッチリスト・フラグメントについてウェブ・アプリケーション・サーバによって生成されるＨＴＴＰ出力を示す。
【０４０３】
【表１５】
2005513640.tif 000016
【０４０４】
表１６に、個々の株式相場を生成するＪＳＰを示す。
【０４０５】
【表１６】
2005513640.tif 000017
【０４０６】
表１７に、シンボル照会パラメータ「ＩＢＭ」についてウェブ・アプリケーション・サーバによって生成されるＨＴＴＰ出力を示す。
【０４０７】
【表１７】
2005513640.tif 000018
【０４０８】
結論
本発明の好ましい実施形態の利益は、上で提供した本発明の好ましい実施形態の詳細な説明に鑑みて明白である。ネットワークを介してコンピューティング・デバイスに展開することができるフラグメント・キャッシング技法は、キャッシュ管理ユニット内で実施でき、キャッシュ管理ユニットによって分散フラグメント・キャッシング機構がもたらされる。
【０４０９】
ＨＴＴＰなどのネットワーク・プロトコル内で使用されるＦＲＡＧＭＥＮＴヘッダが定義され、ヘッダによって、フラグメントの処理およびキャッシングに関連するさまざまな目的のために、メタデータがフラグメントに関連付けられる。たとえば、ヘッダは、クライアント、サーバ、または他の中間キャッシュのいずれかがページ組立能力を有するかどうかの識別に使用される。ヘッダによって、フラグメントのキャッシュ識別子を形成するキャッシュＩＤ規則も指定され、この規則は、フラグメントのＵＲＩ、または、ＵＲＩパスならびに要求に付随するＵＲＩからの照会パラメータおよびクッキーのある組合せに基づくものとすることができる。さらに、ヘッダによって、ホストによって開始される無効化をサポートして、フラグメントの依存性関係を指定することができる。
【０４１０】
ＦＲＡＧＭＥＮＴＬＩＮＫタグは、ページ組立中またはページ・レンダリング中に挿入されるインクルードされるフラグメントに関するページ内の位置を指定するのに使用される。ＦＲＡＧＭＥＮＴＬＩＮＫタグは、リンクされたフラグメントをキャッシュ内で見つけること、またはサーバからそれを取り出すことのいずれかに十分な情報を含むように定義されている。キャッシュＩＤ規則が、フラグメントがキャッシュに保管される時と、キャッシュ内でフラグメントを見つけるために要求からのソース識別子を処理する時の両方に使用される。キャッシュ内でフラグメントを見つけるために、フラグメントのＵＲＩパスに関連するキャッシュＩＤ規則が、キャッシュＩＤを判定するのに使用される。この規則によって、キャッシュＩＤ形成の標準実施形態を強制するコンピュータ・プログラムを展開する必要なしに、フラグメントのキャッシュＩＤを形成する際の高い度合の柔軟性が可能になる。複数のキャッシュＩＤ規則を使用することができる。キャッシュＩＤ規則を用いると、キャッシュＩＤを、フラグメントのフルＵＲＩまたはＵＲＩと照会パラメータまたはクッキーの組合せにすることができるようになる。この方式を用いると、同一のＦＲＡＧＭＥＮＴＬＩＮＫによって、親フラグメントの照会パラメータおよびクッキーに依存して異なるフラグメントを突き止めることができるようになり、たとえば、製品説明ページの要求のユーザＩＤクッキーを使用して、パーソナライゼーション・フラグメントのキャッシュＩＤを形成することができる。
【０４１１】
本発明の好ましい実施形態を、完全に機能するデータ処理システムに関して説明したが、本発明の好ましい実施形態に関連する処理の一部を、配布の実行に実際に使用される信号担持媒体の特定のタイプに無関係に、コンピュータ可読媒体内の命令の形またはさまざまな他の形で配布できることを、当業者が諒解するであろうことに留意することが重要である。コンピュータ可読媒体の例に、ＥＰＲＯＭ、ＲＯＭ、テープ、紙、フロッピ・ディスク、ハード・ディスク・ドライブ、ＲＡＭ、およびＣＤ−ＲＯＭなどの媒体と、ディジタル通信リンクおよびアナログ通信リンクなどの伝送型媒体が含まれる。
【図面の簡単な説明】
【０４１２】
【図１】本発明の好ましい実施形態を実施できる通常の分散データ処理システムを示す図である。
【図２】本発明の好ましい実施形態を実施できるデータ処理システム内で使用することができる通常のコンピュータ・アーキテクチャを示す図である。
【図３】キャッシュを分散データ処理システム全体で実施できる通常の分散データ処理システムを示す図である。
【図４】フラグメントからなる通常のウェブ・ページを示す図である。
【図５】本発明の好ましい実施形態による、ＦＲＡＧＭＥＮＴＬＩＮＫタグの形式的な標準汎用印刷指定言語（ＳＧＭＬ）定義を示す図である。
【図６】本発明の好ましい実施形態によるＦＲＡＧＭＥＮＴヘッダの形式的な定義を示す図である。
【図７】オブジェクト取出しパスに沿ったフラグメント・サポート式エージェントおよびフラグメント非サポート式エージェントの組を示す図である。
【図８】オブジェクト取出しパスに沿ったフラグメント・サポート式エージェントおよびフラグメント非サポート式エージェントの組を示す図である。
【図９】オブジェクト取出しパスに沿ったフラグメント・サポート式エージェントおよびフラグメント非サポート式エージェントの組を示す図である。
【図１０】オブジェクト取出しパスに沿ったフラグメント・サポート式エージェントおよびフラグメント非サポート式エージェントの組を示す図である。
【図１１】オブジェクト取出しパスに沿ったフラグメント・サポート式エージェントおよびフラグメント非サポート式エージェントの組を示す図である。
【図１２】オブジェクト取出しパスに沿ったフラグメント・サポート式エージェントおよびフラグメント非サポート式エージェントの組を示す図である。
【図１３】オブジェクト取出しパスに沿ったフラグメント・サポート式エージェントおよびフラグメント非サポート式エージェントの組を示す図である。
【図１４】コンピューティング・デバイス内のフラグメント・サポート式キャッシュのキャッシュ管理ユニットを示す図である。
【図１５】フラグメントを含む応答メッセージを処理する時にフラグメント・サポート式キャッシュ管理ユニットによって使用することができる処理を示す流れ図である。
【図１６】メッセージ本体にフラグメント・オブジェクトが含まれるか否かを判定する好ましい方法を示す流れ図ステップである。
【図１７】フラグメント・オブジェクトがキャッシュ可能であるか否かを判定するより具体的な方法を示す流れ図ステップである。
【図１８】フラグメント・オブジェクトがキャッシュ可能であるか否かを判定す好ましい方法を示す流れ図ステップである。
【図１９】フラグメント・オブジェクトを特定のコンピューティング・デバイスでキャッシングしなければならないか否かを判定する方法を示す流れ図である。
【図２０】下流デバイスがフラグメント・サポート式キャッシュを有するか否かを判定する好ましい方法を示す流れ図ステップである。
【図２１】現在処理されつつあるフラグメント・オブジェクトを、宛先ユーザ／クライアント・デバイスに最も近いフラグメント・サポート式キャッシュでのみキャッシングしなければならないか否かを判定する、より具体的な方法を示す流れ図ステップである。
【図２２】現在処理されつつあるフラグメント・オブジェクトを、宛先ユーザ／クライアント・デバイスに最も近いフラグメント・サポート式キャッシュでのみキャッシングしなければならないかどうかを判定する、好ましい方法を示す流れ図ステップである。
【図２３】現在のコンピューティング・デバイスから応答メッセージを返す前にページ組立が必要であるか否かを判定する方法を示す流れ図である。
【図２４】現在処理されつつあるフラグメント・オブジェクトが、別のフラグメントへのリンクを有するか否かを判定する、より具体的な方法を示す流れ図ステップである。
【図２５】現在処理されつつあるフラグメント・オブジェクトが、別のフラグメントへのリンクを有するか否かを判定する、代替の方法を示す流れ図ステップである。
【図２６】ページ組立を実行する処理を示す流れ図である。
【図２７】任意選択としてフラグメント・リンクを複数のフラグメント・リンクに展開する処理を示す流れ図である。
【図２８】応答メッセージからの現在のフラグメントのフラグメント・リンクが、これを複数のフラグメント・リンクに展開しなければならないことを示すか否かを判定する好ましい方法を示す流れ図ステップである。
【図２９】フラグメント・リンクに関連する情報に従ってフラグメント・リンクを複数のフラグメント・リンクに展開する処理を示す流れ図である。
【図３０】フラグメントのソース識別子を使用するフラグメントの取出しの処理を示す流れ図である。
【図３１】フラグメントがフラグメント・サポート式キャッシュ管理ユニット内でキャッシングされる時に実行される処理の一部を示す流れ図である。
【図３２】フラグメントがキャッシュ管理ユニットを含むコンピューティング・デバイスでキャッシングされる場合に、そのフラグメントを入手するためにフラグメント・サポート式キャッシュ管理ユニットによって使用することができる処理を示す流れ図である。
【図３３】複数のフラグメントに関連するヘッダ値およびプロパティ値を組み合わせる処理を示す流れ図である。
【図３４】ヘッダ・タイプおよびプロパティ値の、一連の組合せ機能を表すステップの組を示す流れ図である。
【図３５】要求メッセージを処理する時にフラグメント・サポート式キャッシュ管理ユニットによって使用することができる処理を示す流れ図である。
【図３６】本発明の好ましい実施形態の実施形態に従って無効化メッセージを処理する時にフラグメント・サポート式キャッシュ管理ユニットによって使用することができる処理を示す流れ図である。
【図３７】一部のキャッシュでフラグメント組立が実行される時を示すための、ウェブ・アプリケーション・サーバとクライアントの間でのデータフローの一部を示すブロック図である。
【図３８】エンドユーザまたはクライアント・デバイスに最も近いキャッシュでフラグメントをキャッシングするようにデバイスの組に指示することができる形を示すための、ウェブ・アプリケーション・サーバとクライアントの間でのデータフローの一部を示すブロック図である。
【図３９】動的な役割固有またはカテゴリ固有のコンテンツのキャッシングを本発明の好ましい実施形態を使用して達成できることを示すための、クライアント、中間フラグメント・サポート式キャッシュ、またはサーバ内で行われる処理ステップの一部を示すデータフロー図である。
【図４０】動的な役割固有またはカテゴリ固有のコンテンツのキャッシングを本発明の好ましい実施形態を使用して達成できることを示すための、クライアント、中間フラグメント・サポート式キャッシュ、またはサーバ内で行われる処理ステップの一部を示すデータフロー図である。
【図４１】動的な役割固有またはカテゴリ固有のコンテンツのキャッシングを本発明の好ましい実施形態を使用して達成できることを示すための、クライアント、中間フラグメント・サポート式キャッシュ、またはサーバ内で行われる処理ステップの一部を示すデータフロー図である。
【図４２】動的な役割固有またはカテゴリ固有のコンテンツのキャッシングを本発明の好ましい実施形態を使用して達成できることを示すための、クライアント、中間フラグメント・サポート式キャッシュ、またはサーバ内で行われる処理ステップの一部を示すデータフロー図である。
【図４３】複数のフラグメントを単一の要求メッセージ内で指定でき、後に処理できるようにする処理を示す流れ図である。
【図４４】単一の要求メッセージを中間キャッシュ管理ユニットで受信し、後に処理できるようにする処理を示す流れ図である。
【図４５】複数のフラグメントに関するバッチ要求メッセージを処理するウェブ・アプリケーション・サーバでの処理を示す流れ図である。
【図４６】本発明の好ましい実施形態に従って達成できる有利なキャッシュ・サイズ削減を示す例の１つを示す図である。
【図４７】本発明の好ましい実施形態に従って達成できる有利なキャッシュ・サイズ削減を示す例の１つを示す図である。
【図４８】本発明の好ましい実施形態に従って達成できる有利なキャッシュ・サイズ削減を示す例の１つを示す図である。
【図４９】本発明の好ましい実施形態に従って達成できる有利なキャッシュ・サイズ削減を示す例の１つを示す図である。
【図５０】本発明の好ましい実施形態の教示によって、フラグメントの保管および処理のために一意のキャッシュ識別子が構成され、使用される形を示す図の１つである。
【図５１】本発明の好ましい実施形態の教示によって、フラグメントの保管および処理のために一意のキャッシュ識別子が構成され、使用される形を示す図の１つである。
【図５２】本発明の好ましい実施形態の教示によって、フラグメントの保管および処理のために一意のキャッシュ識別子が構成され、使用される形を示す図の１つである。
【図５３】本発明の好ましい実施形態の教示によって、フラグメントの保管および処理のために一意のキャッシュ識別子が構成され、使用される形を示す図の１つである。
【図５４】本発明の好ましい実施形態の教示によって、フラグメントの保管および処理のために一意のキャッシュ識別子が構成され、使用される形を示す図の１つである。
【図５５】本発明の好ましい実施形態の教示によって、フラグメントの保管および処理のために一意のキャッシュ識別子が構成され、使用される形を示す図の１つである。
【図５６】本発明の好ましい実施形態の教示によって、フラグメントの保管および処理のために一意のキャッシュ識別子が構成され、使用される形を示す図の１つである。
【図５７】本発明の好ましい実施形態の教示によって、フラグメントの保管および処理のために一意のキャッシュ識別子が構成され、使用される形を示す図の１つである。
【図１】
2005513640.tif 000019
【図２】
2005513640.tif 000020
【図３】
2005513640.tif 000021
【図４】
2005513640.tif 000022
【図５】
2005513640.tif 000023
【図６】
2005513640.tif 000024
【図７】
2005513640.tif 000025
【図８】
2005513640.tif 000026
【図９】
2005513640.tif 000027
【図１０】
2005513640.tif 000028
【図１１】
2005513640.tif 000029
【図１２】
2005513640.tif 000030
【図１３】
2005513640.tif 000031
【図１４】
2005513640.tif 000032
【図１５】
2005513640.tif 000033
【図１６】
2005513640.tif 000034
【図１７】
2005513640.tif 000035
【図１８】
2005513640.tif 000036
【図１９】
2005513640.tif 000037
【図２０】
2005513640.tif 000038
【図２１】
2005513640.tif 000039
【図２２】
2005513640.tif 000040
【図２３】
2005513640.tif 000041
【図２４】
2005513640.tif 000042
【図２５】
2005513640.tif 000043
【図２６】
2005513640.tif 000044
【図２７】
2005513640.tif 000045
【図２８】
2005513640.tif 000046
【図２９】
2005513640.tif 000047
【図３０】
2005513640.tif 000048
【図３１】
2005513640.tif 000049
【図３２】
2005513640.tif 000050
【図３３】
2005513640.tif 000051
【図３４】
2005513640.tif 000052
【図３５】
2005513640.tif 000053
【図３６】
2005513640.tif 000054
【図３７】
2005513640.tif 000055
【図３８】
2005513640.tif 000056
【図３９】
2005513640.tif 000057
【図４０】
2005513640.tif 000058
【図４１】
2005513640.tif 000059
【図４２】
2005513640.tif 000060
【図４３】
2005513640.tif 000061
【図４４】
2005513640.tif 000062
【図４５】
2005513640.tif 000063
【図４６】
2005513640.tif 000064
【図４７】
2005513640.tif 000065
【図４８】
2005513640.tif 000066
【図４９】
2005513640.tif 000067
【図５０】
2005513640.tif 000068
【図５１】
2005513640.tif 000069
【図５２】
2005513640.tif 000070
【図５３】
2005513640.tif 000071
【図５４】
2005513640.tif 000072
【図５５】
2005513640.tif 000073
【図５６】
2005513640.tif 000074
【図５７】
2005513640.tif 000075
【手続補正書】
【提出日】平成16年1月28日(2004.1.28)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
ネットワーク内のデータ処理システムでオブジェクトを処理する方法であって、
コンピューティング・デバイスで第１メッセージを受信するステップと、
前記第１メッセージのメッセージ・ヘッダが、前記第１メッセージがフラグメントに関連することを示すことを判定するステップと
前記第１メッセージのメッセージ・ヘッダが、前記フラグメントがキャッシュ可能であることを示すことを判定するステップ
を含む方法。
【請求項２】
前記コンピューティング・デバイス内のキャッシュ管理ユニットによって維持されるキャッシュに前記第１メッセージからのフラグメントを保管するステップであって、前記キャッシュ管理ユニットが、前記コンピューティング・デバイスがネットワーク全体に配置されたクライアント、サーバ、またはハブのどれとして働くかにかかわらずに、フラグメント・キャッシング動作をサポートして同等に動作する、ステップ
をさらに含む、請求項１に記載の方法。
【請求項３】
前記コンピューティング・デバイスで第２メッセージを受信するステップであって、前記第２メッセージが、前記フラグメントに関する要求を含む、ステップと、
前記第２メッセージの受信に応答して前記キャッシュを検索するステップと、
前記キャッシュの検索に応答して前記キャッシュから前記フラグメントを取り出すステップと、
前記第２メッセージをその宛先アドレスに送信せずに、前記第２メッセージの発信元に第３メッセージで前記フラグメントを送信するステップと
をさらに含む、請求項２に記載の方法。
【請求項４】
前記フラグメントが次レベル・フラグメントへのリンクを含むトップレベル・フラグメントであるかどうかを判定するステップと、
前記フラグメントが次レベル・フラグメントへのリンクを含むトップレベル・フラグメントであるとの判定に応答して、前記次レベル・フラグメントを取り出すステップと、
前記トップレベル・フラグメントと前記次レベル・フラグメントとを組み立てられたフラグメントに組み合わせるステップと
をさらに含む、請求項１に記載の方法。
【請求項５】
前記第１メッセージから依存識別子の組を取り出すステップであって、依存識別子が、前記フラグメントを発したサーバによって生成される、ステップと、
前記フラグメントのソース識別子に関連する依存識別子の組を保管するステップと
をさらに含む、請求項１または２のいずれか一項に記載の方法。
【請求項６】
無効化要求メッセージを受信するステップと、
前記無効化要求メッセージから依存識別子を取り出すステップと、
前記依存識別子に関連するフラグメントの組を判定するステップと、
前記依存識別子に関連するフラグメントの前記組の前記判定に応答して、前記キャッシュからフラグメントの前記組を消去するステップと
をさらに含む、請求項５に記載の方法。
【請求項７】
前記第１メッセージからフラグメント・キャッシング規則の組を取り出すステップであって、フラグメント・キャッシング規則が、前記フラグメントのキャッシュ識別子を生成する形を決定する、ステップと、
フラグメント・キャッシング規則に従って前記フラグメントのキャッシュ識別子を生成するステップと
をさらに含む、請求項１または２のいずれか一項に記載の方法。
【請求項８】
前記フラグメントの前記生成されたキャッシュ識別子を使用して前記保管動作を実行するステップ
をさらに含む、請求項７に記載の方法。
【請求項９】
前記第１メッセージが、前記フラグメントのソース識別子を含み、前記方法が、さらに、
前記フラグメントを含む応答メッセージを生成するステップと、
第１メッセージがフラグメントに関連することを示すメッセージ・ヘッダを前記応答メッセージに挿入するステップと
を含む、請求項１に記載の方法。
【請求項１０】
前記フラグメントがキャッシュ可能であることを示すメッセージ・ヘッダを前記応答メッセージに挿入するステップ
をさらに含む、請求項９に記載の方法。
【請求項１１】
ネットワーク内のデータ処理システムでオブジェクトを処理するコンピューティング・デバイスであって、
コンピューティング・デバイスで第１メッセージを受信する手段と、
前記第１メッセージのメッセージ・ヘッダが、前記第１メッセージがフラグメントに関連することを示すことを判定する手段と、
前記第１メッセージのメッセージ・ヘッダから、前記フラグメントがキャッシュ可能であるか否かを示すことを判定する手段と
を含むコンピューティング・デバイス。
【請求項１２】
キャッシュ管理ユニットによって維持されるキャッシュに前記第１メッセージからのフラグメントを保管する手段であって、前記キャッシュ管理ユニットが、前記コンピューティング・デバイスがネットワーク全体に配置されたクライアント、サーバ、またはハブのどれとして働くかにかかわらずに、フラグメント・キャッシング動作をサポートして同等に動作する、手段
をさらに含む、請求項１１に記載のコンピューティング・デバイス。
【請求項１３】
第２メッセージを受信する手段であって、前記第２メッセージが、前記フラグメントに関する要求を含む、手段と、
前記第２メッセージの受信に応答して前記キャッシュを検索する手段と、
前記キャッシュの検索に応答して前記キャッシュから前記フラグメントを取り出す手段と、
前記第２メッセージをその宛先アドレスに送信せずに、前記第２メッセージの発信元に第３メッセージで前記フラグメントを送信する手段と
をさらに含む、請求項１２に記載のコンピューティング・デバイス。
【請求項１４】
前記フラグメントが次レベル・フラグメントへのリンクを含むトップレベル・フラグメントであるかどうかを判定する手段と、
前記フラグメントが次レベル・フラグメントへのリンクを含むトップレベル・フラグメントであるとの判定に応答して、前記次レベル・フラグメントを取り出す手段と、
前記トップレベル・フラグメントと前記次レベル・フラグメントとを組み立てられたフラグメントに組み合わせる手段と
をさらに含む、請求項１１に記載のコンピューティング・デバイス。
【請求項１５】
前記第１メッセージから依存識別子の組を取り出す手段であって、依存識別子が、前記フラグメントを発したサーバによって生成される、手段と、
前記フラグメントのソース識別子に関連する依存識別子の組を保管する手段と
をさらに含む、請求項１１または１２のいずれか一項に記載のコンピューティング・デバイス。
【請求項１６】
無効化要求メッセージを受信する手段と、
前記無効化要求メッセージから依存識別子を取り出す手段と、
前記依存識別子に関連するフラグメントの組を判定する手段と、
前記依存識別子に関連するフラグメントの前記組の前記判定に応答して、前記キャッシュからフラグメントの前記組を消去する手段と
をさらに含む、請求項１５に記載のコンピューティング・デバイス。
【請求項１７】
前記第１メッセージからフラグメント・キャッシング規則の組を取り出す手段であって、フラグメント・キャッシング規則が、前記フラグメントのキャッシュ識別子を生成する形を決定する、手段と、
フラグメント・キャッシング規則に従って前記フラグメントのキャッシュ識別子を生成する手段と
をさらに含む、請求項１１または１２のいずれかに記載のコンピューティング・デバイス。
【請求項１８】
前記フラグメントの前記生成されたキャッシュ識別子を使用して前記保管動作を実行する手段
をさらに含む、請求項１７に記載のコンピューティング・デバイス。
【請求項１９】
前記要求メッセージが、前記フラグメントのソース識別子を含み、前記装置が、さらに、
前記フラグメントを含む応答メッセージを生成する手段と、
第１メッセージがフラグメントに関連することを示すメッセージ・ヘッダを前記応答メッセージに挿入する手段と
を含む、請求項１１に記載のコンピューティング・デバイス。
【請求項２０】
前記フラグメントがキャッシュ可能であることを示すメッセージ・ヘッダを前記応答メッセージに挿入する手段
をさらに含む、請求項１９に記載のコンピューティング・デバイス。
【請求項２１】
オブジェクトを処理するためにネットワーク内のデータ処理システムで使用される、コンピュータ可読媒体内のコンピュータ・プログラム製品であって、請求項１ないし１０のいずれか一項に記載の方法を実行する命令を含む、コンピュータ・プログラム製品。
【請求項２２】
ネットワーク内のデータ処理システムでオブジェクトを処理する方法であって、
サーバで要求メッセージを受信するステップであって、前記要求メッセージが、フラグメントのソース識別子を含む、受信するステップと、
前記フラグメントを含む応答メッセージを生成するステップと、
第１メッセージがフラグメントに関連することを示すメッセージ・ヘッダを前記応答メッセージに挿入するステップと、
前記フラグメントがキャッシュ可能であるか否かを示すメッセージ・ヘッダを前記応答メッセージに挿入するステップと
を含む方法。
【請求項２３】
ネットワーク内のデータ処理システムでオブジェクトを処理するコンピューティング・デバイスであって、
要求メッセージを受信する手段であって、前記要求メッセージが、フラグメントのソース識別子を含む、受信する手段と、
前記フラグメントを含む応答メッセージを生成する手段と、
第１メッセージがフラグメントに関連することを示すメッセージ・ヘッダを前記応答メッセージに挿入する手段と、
前記フラグメントがキャッシュ可能であるか否かを示すメッセージ・ヘッダを前記応答メッセージに挿入する手段と
を含むコンピューティング・デバイス。
【請求項２４】
オブジェクトを処理するためにネットワーク内のデータ処理システムで使用される、コンピュータ可読媒体内のコンピュータ・プログラム製品であって、請求項２２に記載の方法を実行する命令を含む、コンピュータ・プログラム製品。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、改良されたデータ処理システムに関し、具体的には改良されたネットワーク・リソース割振りを有するデータ処理システムに関する。さらに具体的には、本発明は、コンピュータ・ネットワーク内でのデータ・オブジェクトのキャッシングの方法およびシステムを提供する。
【背景技術】
【０００２】
インターネットを介して送信されるデータの量は、インターネットのユーザ数の増加の速度またはこれらのユーザのトランザクションの数の増加の速度を超えて増加し続けている。この増加の重要な要因が、ワールド・ワイド・ウェブ・サイト自体の性質の変化である。ワールド・ワイド・ウェブの初期段階では、ウェブ・ページが、主に、テキスト、イメージ、および他のサイトへのリンクなどの静的コンテンツからなっていた。ウェブ・サイトとのユーザの対話の範囲は、ＨＴＭＬページおよびその要素のダウンロードであった。コンテンツが、通常は誰がページを要求したかに無関係であったので、ウェブ・サーバが多数のユーザをサポートすることは、比較的単純であった。しかし、現在の傾向は、ウェブ・サイトのコンテンツおよび外見が、特定のユーザおよび／またはユーザ入力に応答して変化する対話型ウェブ・サイトに向かっている。これは、オンラインの製品選択および購入をサポートするｅ−ｃｏｍｍｅｒｃｅサイトについて特にそうである。そのようなサイトは、以前のウェブ・サイトから、より多くのダイナミック・コンテンツによって区別される。これのよく知られた例が、多数のインターネット・ビジネス・サイトで提供される「オンライン・カタログ」である。購入を行うためにサイトにログ・オンした各顧客が、カタログをブラウズし、数千個の製品に関する詳細情報を閲覧する機会を有する。外見上、ウェブ・サーバによって、買物客ごとに独自のウェブ・ページを維持し、更新しなければならない。インターネット・ユーザは、そのようなカスタマイズ可能な対話型ウェブ・サイトの便宜を享受し、顧客の期待は、疑いもなく、ウェブ・ページ内のダイナミック・コンテンツの将来の使用の起動力を提供する。
【０００３】
インターネット・ウェブ・ページでのダイナミック・コンテンツの使用の発展によって、ウェブ・サイトの運営者に関するロジスティック問題が生じる。現在のｅ−ｃｏｍｍｅｒｃｅサイトは、極端に高い「ブラウズ対購入比率」という特徴がある。ショッピング・サイトの場合に、通常の比率は、各常設のビジネス・レコードを更新するインタラクション（「トランザクション」）に対して、常設のビジネス・レコードを更新しないのは（「要求」または「照会」）６０インタラクションであり、製品のブラウズが要求の例であり、購入がトランザクションの例である。ダイナミック・コンテンツの普及の増加の影響は、トランザクションの数が予測可能で管理可能な速度で増加するが、要求の数が爆発的に増えることである。ダイナミック・コンテンツを含むウェブ・ページのユーザ対話性の高さに、トランザクションあたりの要求の数の多さの責任がある。これらのウェブ・ページ内のダイナミック・コンテンツは、通常は、ユーザがこれらのウェブ・ページの１つのブラウズを要求するたびに生成される。これによって、単一のセッション中に用意され、ユーザに伝えられなければならないかなりの量のコンテンツがもたらされる。
【０００４】
ユーザの期待のために、サイト・プロバイダは、要求に応答して迅速にダイナミック・ウェブ・コンテンツを提供せざるをえない。潜在的な顧客が、ウェブ・サイトが遅すぎると感じる場合に、その顧客は、そのサイトを訪問しなくなり、取引が失われる結果になる可能性がある。しかし、インターネット・トラフィックの量そのものが、ｅ−ｂｕｓｉｎｅｓｓに過度の財政的重荷を課す可能性がある。潜在的な顧客による情報の要求の増加をｅ−ｂｕｓｉｎｅｓｓが満足する最も単純な形は、より多くのコンピュータ、ストレージ、および帯域幅を追加することによって、サーバ側ハードウェアを増補することである。この解決策は、極端に高価で非効率的になる可能性がある。
【０００５】
最もコスト効率のよい手法は、キャッシングすなわち、性能を強化するためにディジタル・コンピュータで一般的に使用される技法である。コンピュータでデータ保管に使用される主メモリは、通常は、プロセッサよりはるかに低速である。データ・アクセス中により低速のメモリに対処するために、習慣的に、ウェイト・ステートが、プロセッサの通常の命令タイミングに追加される。プロセッサが、必ず主メモリからのデータにアクセスする必要がある場合には、その性能が、かなり低下する。キャッシングでは、主メモリ・アクセス・ボトルネックを克服するために、「キャッシュ」と称する少量だが極端に高速のメモリ・バッファを使用して、「データ局所性」と称する統計的特徴の利点を取り込む。データ局所性は、連続するデータ・アクセスにメモリの同一の一般的領域が含まれるという一般的傾向を指す。これを、時々、データ・アクセスの８０％がメモリの同一の２０％に対するものであるので、「８０／２０」の法則と称する。
【０００６】
下の例で、ウェブ関連ではないが、キャッシング全般の利益を示す。２つの大きい数字の配列をかけるコンピュータ・プログラムがあり、そのプログラムをより速く実行できるようにコンピュータを修正する方法を検討したいと仮定する。最も単純な修正は、プロセッサの速度を高めることであるが、これには限界がある。プログラムの各個々の乗算演算が、プロセッサがメモリから２つのオペランドをフェッチし、積を計算し、結果をメモリにライト・バックすることを必要とする。より高いプロセッサ速度では、計算に必要な時間がより少ないので、制限要因は、プロセッサがメモリと相互作用するのに必要な時間になる。より高速のメモリを使用することができるが、コンピュータのメモリのすべてに関する大量の極端に高速のメモリの使用は、非実用的であり、高価過ぎる。幸いなことに、行列乗算プログラムは、２つの入力配列のそれぞれの要素が、メモリのある範囲内の連続するアドレスを占めるので、高いデータ局所性を示す。したがって、大量の極端に高速のメモリを使用するのではなく、少量の極端に高速のメモリを、キャッシュとして使用することができる。プログラムの開始時に、主メモリからの入力配列が、キャッシュ・バッファに転送される。プログラムの実行中に、プロセッサが、キャッシュからオペランドをフェッチし、対応する結果をキャッシュにライト・バックする。データ・アクセスで高速キャッシュが使用されるので、プロセッサは、主メモリを使用する場合よりはるかに高速にこのプログラムを実行することができる。実際に、キャッシュを使用することによって、主メモリ全体をアップグレードした場合と同等に、はるかに低いコストで速度改善がもたらされる。キャッシュ・システムが、データ局所性の仮定が正当化される情況でのみ有益であり、プロセッサが頻繁にデータのためにキャッシュの外にアクセスしなければならない場合に、キャッシュの速度の長所が失われることに留意されたい。
【０００７】
データ・キャッシュの使用に関連するもう１つの問題が、「キャッシュ・コヒーレンシ」である。上で説明したように、データは、通常は、より高速のアクセスを可能にするためにキャッシュにコピーされる。キャッシュ内の各データは、主メモリ内の元のバージョンと同一のコピーである。コンピュータ内のあるアプリケーションが、別のアプリケーションがキャッシュ内のコピーにアクセスする間に主メモリ内の変数にアクセスする場合に、問題が発生する可能性がある。変数のいずれかのバージョンが、他方と独立に変更される場合に、キャッシュが、コヒーレンシを失い、潜在的に有害な結果が生じる。たとえば、変数が、クリティカル・オペレーティング・システム・データへのポインタである場合に、致命的エラーが発生する可能性がある。これを避けるために、キャッシュの状態を監視しなければならない。キャッシュ内のデータが修正される時に、主メモリ内の「古い」コピーを、更新されるまで一時的に無効化する。したがって、キャッシュを装備したシステムの重要な態様は、キャッシュ・コヒーレンシを維持する処理である。
【０００８】
これらの周知の問題および利益に鑑みて、キャッシュは、いわゆるコンテンツ・デリバリ・ネットワーク（Content Delivery Network、ＣＤＮ）を含む、インターネット内またはプライベート・ネットワーク内のさまざまな位置にあるデータ処理システム内で実施されてきた。ウェブ・トラフィックは、キャッシングによく適することがわかっている。ｅ−ｃｏｍｍｅｒｃｅインターネット・トラフィックの大部分は、ユーザからサーバではなくサーバからユーザに送信されるデータからなる。ほとんどの場合に、ユーザは、ウェブ・サイトに情報を要求し、ユーザは、比較的まれにウェブ・サイトに情報を送信する。たとえば、ユーザは、頻繁に、ウェブ・ページを要求し、比較的まれに、ウェブ・サイトに保管される、個人情報またはトランザクション情報をサブミットする。したがって、データ・トラフィックの大部分は、よいキャッシュ・コヒーレンシ特性を示す。さらに、データ・トラフィックの大部分は、よいデータ局所性特性を示す。というのは、ユーザが、異なるウェブ・サイトに移動する前に、しばらくの間、単一のウェブ・サイトのコンテンツをブラウズし、再度ブラウズする傾向があるからである。さらに、多くのユーザは、同一の情報を要求する傾向があり、これをデータベースから繰り返して検索するよりも、ある点で情報をキャッシングすることがより効果的である。さらに、ほとんどのウェブ・アプリケーションは、データがどれほど最新であるかに関するある程度の遊びを許容することができる。たとえば、製品価格が変更される時に、その変更が有効になるまでに数分の遅延を有することを許容可能とすることができ、すなわち、キャッシュ・コヒーレンシの完全性を緩和することができ、キャッシングがさらに貴重になる。
【０００９】
ウェブ・コンテンツのキャッシングの利益を、以下の説明であまねく示すことができる。クライアント・ブラウザからの各要求は、ファイヤウォール、ルータ、ならびに、中間サーバ、プレゼンテーション・サーバ（たとえば、静的コンテンツの読取、ダイナミック・ページの構築）、アプリケーション・サーバ（たとえば、ページのデータの検索、更新の実行）、およびバックエンド・サーバ（たとえば、データベース、サービス、およびレガシ・アプリケーション）などのさまざまなタイプのサーバなど、インターネット全体に配置された複数のデータ処理システムを通って流れることができる。これらの処理ステージのそれぞれが、関連するコストおよび性能の考慮事項を有する。
【００１０】
キャッシングが全く行われない場合に、すべての要求が、プレゼンテーション・サーバを通って流れ、このプレゼンテーション・サーバによって、ダイナミック・コンテンツを必要としない要求を満足することができる。残念ながら、多くの要求によって、ダイナミック・コンテンツ・ページのデータの更新または入手のために、アプリケーション・サーバおよびバックエンド・サーバにも処理が要求される。
【００１１】
しかし、要求は、満足されるのに必要なだけ伝搬する必要があり、特にアプリケーション・プロバイダのサイト内でのキャッシュの使用によって、性能を高めることができる。たとえば、中間サーバでのキャッシングによって、要求の大多数を満足することができ、その結果、少数の要求だけが、プレゼンテーション・サーバまで伝搬される。プレゼンテーション・サーバでのキャッシングによって、プレゼンテーション・サーバに達する要求の一部を処理することができ、その結果、ごく少数の要求だけが、アプリケーション・サーバに伝搬される。アプリケーション・サーバは、通常はトランザクショナルなので、アプリケーション・サーバ内では、制限されたキャッシングを達成することができる。しかし、総合的に、アプリケーション・プロバイダのサイト内でのキャッシュの適度な使用によって、かなりのコスト節約を達成することができる。
【００１２】
キャッシングの利益があれば、上で述べたサーバおよび他のハードウェアへの大規模な投資なしで、キャッシング技法を使用することによってダイナミック・ウェブ・コンテンツを含むウェブ・サイトの応答性を改善することができる。しかし、キャッシングの適当性に関する重要な考慮事項が、ウェブ・コンテンツが変更される頻度である。一般に、キャッシュの実装は、アクセス・レートが高くなるにつれ、また、更新レートが低くなるにつれて、適するようになる。具体的には、ウェブ・コンテンツのキャッシングは、ユーザがウェブ・サイトから静的コンテンツを頻繁に検索し、ウェブ・サイトで保管されるデータを送信する頻度が低い時に、適するようになる。しかし、ウェブ・サイトに、かなりの量のダイナミック・コンテンツが含まれる場合には、そのウェブ・サイトは、本来、そのコンテンツを頻繁に変更するように構成される。この場合に、そのウェブ・サイト内のキャッシュの更新レートが、非常に高くなり、これによって、ウェブ・サイトのコンテンツをキャッシングする試みの長所が帳消しになる。
【００１３】
会社内のダイナミック・コンテンツを効果的にキャッシングするさまざまな解決策が、提案されるか、実施されるか、その両方を行われてきた。ウェブ・アプリケーション・サーバ内でウェブ・コンテンツをキャッシングするこれらの技法によって、スループットおよび応答時間に関する性能が大幅に改善された。
【００１４】
ｅ−ｂｕｓｉｎｅｓｓウェブ・サイト内でのダイナミック・コンテンツのキャッシングの大きい利益を得た後に、ネットワーク自体全体での連携キャッシング、いわゆる「分散キャッシング」を実施することが有利になるはずである。というのは、ユーザの近くでのコンテンツのキャッシングによって、応答時間または待ち時間に関する遥かに大きい利益を得ることができるからである。しかし、周知のキャッシングの問題を、分散キャッシング解決策について検討しなければならない。キャッシュの無差別の配置および実施によって、コスト効率が悪い形で性能が改善される場合がある。キャッシュの有効性を決定する重要な問題に、キャッシュ・サイズ、キャッシュ・ヒット・パス長、キャッシュ・コンテンツを維持するのに必要な作業量、およびデータ要求元とデータの位置の間の距離が含まれる。
【００１５】
キャッシュ・サイズに関して、メモリおよびディスク空間は、サイズが増え続けているが、その限度を考慮する必要がなくなるほどに大きくなることは、絶対にない。言い換えると、分散キャッシング技術では、大量のメモリおよびディスク空間がキャッシュに使用可能であると仮定してはならず、小さいキャッシュの必要が、一般に、大きいキャッシュの必要より好ましい。さらに、メモリおよびディスクの帯域幅は、そのサイズの増加より低い速度で改善されており、ますます大量になるデータをキャッシングする試みは、最終的に帯域幅の考慮事項によって制限される。
【００１６】
キャッシュ・ヒット・パス長に関して、分散キャッシング解決策に、簡単に展開できるが、キャッシュ・ヒットのスループットが非常に高くなるように最小限の処理でキャッシュ・ヒットを判定できる軽量ランタイム・アプリケーションが含まれることが好ましい。分散キャッシング・アプリケーションの所望の形態を、エンドユーザに近いデータを「キャッシング」する分散アプリケーションの他の形と混同してはならない。言い換えると、インターネット全体でのアプリケーションの諸部分およびそれに関連するデータの分配の多数の形の１つから利益を得る他の形のアプリケーションがある。たとえば、アプリケーションおよびそれに関連するデータベース全体を、異なる位置で複製することができ、展開する企業が、必要に応じて、データベースを同期化し、アプリケーションを維持することができる。他の場合に、アプリケーションおよびそれに関連するデータの読取専用表示部分を、プラグイン、Ｊａｖａ（Ｒ）Ｓｃｒｉｐｔ（商標）、または類似する機構を使用してクライアントベース・ブラウザに分散すると同時に、ビジネス・ロジックを保護されたホスト・サイトで保つことができる。
【００１７】
キャッシュ・コンテンツの維持に必要な作業量に関して、サービスする企業内でのキャッシングによって、要求ごとに行われる作業が減るので、スループットまたはコストのいずれかすなわち、毎分処理される要求の数または必要なサーバ・ハードウェアの量が改善される。サービスする企業内で、キャッシュは、企業の入口点の近くに配置されることが好ましい。というのは、企業内のシステムによる処理の量が減り、これによって改善が高まるからである。たとえば、ディスパッチャの近くでのキャッシングは、アプリケーション・サーバ内のキャッシングよりはるかに有効になる可能性がある。サービスする企業内でのキャッシングによって、待ち時間が多少改善されるが、サービスする企業内での待ち時間は、通常はインターネットでの待ち時間よりはるかに短いので、この改善は通常は副次的である。サービスする企業の外部での堅牢な分散キャッシング技法に関する考慮事項は、これおよび他の問題と絡み合っている。
【００１８】
データ要求元とデータの位置の間の距離に関して、インターネットでのユーザに可視の待ち時間は、ユーザとコンテンツの間の距離に左右される。この距離は、物理的距離ではなく、ルーティング・ホップの数によって測定される。コンテンツが、インターネット・サービス・プロバイダ（ＩＳＰ）などのインターネットの「境界」でキャッシングされる時に、ユーザに可視の待ち時間が、かなり減る。マルチメディア・ファイルなどの大きいコンテンツについて、帯域幅要件も、かなり減らすことができる。堅牢な分散キャッシング解決策では、ユーザの近くでデータをキャッシングすることを試みなければならない。
【００１９】
ユーザは、地理的に分散しているので、ユーザの近くでのコンテンツのキャッシングは、コンテンツが、インターネット全体のＩＳＰおよびエクスチェンジ・ポイント（exchange point）の複数のキャッシュで複製されることを意味する。一般に、これによって、キャッシング機構がコンテンツのセキュリティおよびコンテンツを更新する形すなわちキャッシュ・コヒーレンシに対して有する制御が減る可能性がある。サービスする企業内のキャッシング機構が、表向きは単一の組織の制御の下にあるという事実に対して、サービスする企業内のコヒーレントなキャッシュを比較的簡単に維持することができる。しかし、サービスする企業の内部と外部の両方でキャッシュを維持することによって、キャッシュ・コヒーレンシを維持するのに必要な問題および作業量がかなり増える。公衆インターネット以外のより制御されたネットワーク環境内でキャッシュ空間が貸し出され、維持されるコンテンツ配布ベンダ、たとえばＣＤＮが使用される場合に、セキュリティおよびコヒーレンシの考慮事項を最小にすることができるが、そのような解決策によって、公衆インターネットを介するオープンな標準規格の使用を介して得られる長所の一部が事実上帳消しにされる。
【００２０】
分散キャッシング技法が、ある程度企業境界に関して実施可能であり、かつ、整合された形でインターネット全体で実施可能であることが好ましい。さらに、キャッシュは、たとえばクライアント・ブラウザ内などのエンド・ユーザの近く、サービスする企業のディスパッチャの近く、ウェブ・アプリケーション・サーバ内、またはこの間のどこかなど、必要と判定される可能性があるさまざまな重要な位置で展開可能でなければならない。さらに、この技法は、異なる組織がローカル・システム要件に従って分散キャッシング仕様の異なる実施形態を構築できるように、仕様を厳守しなければならない。
【００２１】
潜在的に堅牢な分散キャッシング解決策に関する問題は、フラグメント（fragment）としてウェブ・コンテンツをオーサリングしパブリッシュする傾向によって複雑化している。コンテンツの一部が、フラグメントに配置され、ウェブ・ページまたは他の文書などのより大きいコンテンツ・エンティティが、フラグメントから構成されるが、コンテンツ・エンティティを、単一のフラグメントから構成することもできる。フラグメントは、別々に保管され、必要な時により大きいコンテンツ・エンティティに組み立てられる。
【００２２】
これらのランタイムの利益は、フラグメントの維持および使用の他の態様での複雑化によって相殺される。フラグメントに、異なる寿命を割り当てることができ、これによって、一貫性のある無効化機構が必要になる。さらに、フラグメントを使用して、コンテンツの静的部分をコンテンツのダイナミック部分から分離でき、その結果、静的コンテンツを効果的にキャッシングできるようになるが、上で述べたように、ダイナミック・コンテンツのキャッシング関連する問題に直面する。最も重要な事に、フラグメント組立は、企業境界の内部の位置に制限されてきた。
【非特許文献１】「HTML 4.01 Specification」、W3CRecommendation、1999年12月24日
【非特許文献２】「Hypertext Transport Protocol --HTTP/1.1」、Request for Comments 2616 (RFC 2616)
【非特許文献３】「HTTP State Management Mechanism」、RFC2109、Internet Engineering Task Force、1997年2月
【発明の開示】
【発明が解決しようとする課題】
【００２３】
したがって、フラグメントおよび他のオブジェクトのキャッシングをサポートする堅牢な分散キャッシング技法を有することが有利である。さらに、必要と思われるときに企業境界により多くまたは少ない程度で、ネットワーク全体のキャッシュ・サイトにフラグメント組立を共存させ、これによって、サービスする企業の処理負荷を減らし、所望される時に分散コンピューティングの追加の利益を達成することが、特に有利である。さらに、フラグメントをインターネット全体を通じて一意に識別できる、すなわち、分散キャッシュがコヒーレントに維持されるようにする、一貫性のあるネーミング技法を有することが有利である。
【００２４】
堅牢な分散キャッシング解決策のさらなる考慮事項として、潜在的な解決策では、既存のプログラミング・モデルの問題を考慮しなければならない。たとえば、既存のウェブ・アプリケーション・サーバのプログラミング・モデルを、分散キャッシング技法と共に動作する新しいプログラミング・モデルに置換することを必要とする分散キャッシング技法を提案することができる。分散キャッシング技法の実装が、さまざまなプログラミング・モデルに対処し、これによって、プログラミング・モデルの偏重を避けることが好ましい。
【００２５】
分散キャッシング技法の実施形態によって、キャッシュ位置に最小限に関係するインターネット全体を通じて標準的な形での軽量プロセスによって維持可能な減少したフラグメント・キャッシュ・サイズがもたらされることが有利である。さらに、分散キャッシング技法が既存のプログラミング・モデルおよびインターネット標準規格との互換性を有し、分散キャッシング技法の実装が、分散キャッシング技法を実施しない他のシステムとの相互運用性を有することが特に有利である。
【課題を解決するための手段】
【００２６】
本発明の第１の態様によれば、ネットワーク内のデータ処理装置でオブジェクトを処理する方法であって、コンピューティング・デバイスで第１メッセージを受信するステップと、前記第１メッセージ内のメッセージ・ヘッダが、前記第１メッセージがフラグメントに関連することを示すことを判定するステップと、前記第１メッセージ内のメッセージ・ヘッダから、前記フラグメントがキャッシュ可能であるか否かを判定するステップとを含む方法が提供される。
【００２７】
本発明の第２の態様によれば、さらに、キャッシュ管理ユニットによって維持されるキャッシュに前記第１メッセージからのフラグメントを保管する手段であって、前記キャッシュ管理ユニットが、ネットワーク全体に配置されたクライアント、サーバ、またはハブのどれとして働くかにかかわらずに、フラグメント・キャッシング動作をサポートして同等に動作する、手段を含む、請求項１１のコンピューティング・デバイスが提供される。
【００２８】
本発明の第３の態様によれば、オブジェクトを処理する、ネットワーク内のデータ処理システムで使用される、コンピュータ可読媒体内のコンピュータ・プログラム製品であって、第１メッセージ内のメッセージ・ヘッダが、前記第１メッセージがフラグメントに関連することを示すことの判定時に前記第１メッセージを受信する命令と、前記第１メッセージ内のメッセージ・ヘッダから前記フラグメントがキャッシュ可能であるか否かを判定することとを含む、コンピュータ・プログラム製品が提供される。
【００２９】
たとえば、第１メッセージが、フラグメントがフラグメント非サポート式キャッシュ管理ユニットにキャッシュ不能であることの表示と、フラグメントがフラグメント・サポート式キャッシュ管理ユニットにキャッシュ可能であることの表示を有する。たとえば、第１メッセージが、フラグメント非サポート式キャッシュ管理ユニットに関するｎｏ−ｃａｃｈｅディレクティブと、フラグメント・サポート式キャッシュ管理ユニットに関するフラグメントをキャッシングするディレクティブとを有するＨＴＴＰ  Ｃａｃｈｅ−Ｃｏｎｔｒｏｌヘッダを有する。
【００３０】
第１メッセージのメッセージ・ヘッダが、第１メッセージのメッセージ本体部分がフラグメントであることを示すことも判定することが好ましい。
【００３１】
第１メッセージからのフラグメントが、コンピューティング・デバイス内のキャッシュ管理ユニットによって管理されるキャッシュに保管され、キャッシュ管理ユニットが、コンピューティング・デバイスがネットワーク全体に配置されたクライアント、サーバ、またはハブのどれとして働く場合でも、フラグメント・キャッシング動作をサポートして同等に機能することが好ましい。
【００３２】
第１メッセージのメッセージ・ヘッダが、フラグメントがキャッシュ可能であることを示すことも判定することが好ましい。この場合に、任意選択として、第１メッセージが、フラグメントがフラグメント非サポート式キャッシュ管理ユニット（non-fragment-supporting cache management unit）にキャッシュ不能であることの表示と、フラグメントがフラグメント・サポート式キャッシュ管理ユニット（fragment-supportingcache management unit）にキャッシュ可能であることの表示を有する。たとえば、第１メッセージが、フラグメント非サポート式キャッシュ管理ユニットに関するｎｏ−ｃａｃｈｅディレクティブと、フラグメント・サポート式キャッシュ管理ユニットに関するフラグメントをキャッシングするディレクティブを伴うＨＴＴＰ  Ｃａｃｈｅ−Ｃｏｎｔｒｏｌヘッダを有する。
【００３３】
第２メッセージが、コンピューティング・デバイスで受信され、第２メッセージに、フラグメントに関する要求が含まれる場合に、キャッシュが検索され、フラグメントがキャッシュから取り出されることが好ましい。このフラグメントは、次いで宛先アドレスに第２メッセージを送信することなく、第２メッセージの発信元に第３メッセージで送信される。
【００３４】
任意選択として、第２メッセージに、第３メッセージを返す前のコンピューティング・デバイスでのページ組立動作が不要であることを示す情報が含まれる。
【００３５】
任意選択として、第２メッセージは、フラグメント・サポート式キャッシュ管理ユニットを有する第２コンピューティング・デバイスによって第３メッセージが受信されることを示すディレクティブを有するメッセージ・ヘッダを有する。
【００３６】
ページ組立動作が、第３メッセージを送信する前にコンピューティング・デバイスで実行されることが好ましい。
【００３７】
ページ組立動作が、コンピューティング・デバイスで実行されて、組み立てられたフラグメントが形成されることが好ましい。たとえば、フラグメントが、次レベル・フラグメントへのリンクを含むトップレベル・フラグメントであるかどうかが判定される。次に、フラグメントが、次レベル・フラグメントへのリンクを含むトップレベル・フラグメントであることの判定に応答して、次レベル・フラグメントが、取り出される。最後に、トップレベル・フラグメントおよび次レベル・フラグメントが、組み立てられたフラグメントに組み合わされる。
【００３８】
任意選択として、次レベル・フラグメントのコンテンツが、トップレベル・フラグメントのコンテンツに組み込まれる。さらに、トップレベル・フラグメントのプロパティ値および次レベル・フラグメントのプロパティ値から、組み立てられたフラグメントについてプロパティ値を生成することができる。組み立てられたフラグメントのヘッダ値またはディレクティブも、トップレベル・フラグメントのヘッダ値またはディレクティブおよび次レベル・フラグメントのヘッダ値またはディレクティブから計算することができる。
【００３９】
組み立てられたフラグメントを含む第４メッセージが生成され、第４メッセージが、ＨＴＴＰ（ハイパーテキスト転送プロトコル）応答メッセージであることが好ましい。
【００４０】
トップレベル・フラグメントおよび次レベルフラグメントの最短満了時刻が判定され、第４メッセージの「Ｅｘｐｉｒｅｓ（満了）」ヘッダに最短満了時刻がセットされることが好ましい。
【００４１】
代替案では、トップレベル・フラグメントおよび次レベルフラグメントの最小の最大経過時間が判定され、第４メッセージの「Ｃａｃｈｅ−Ｃｏｎｔｒｏｌ：ｍａｘ−ａｇｅ（キャッシュ制御：最大年齢）」ディレクティブに、最小の最大経過時間がセットされる。
【００４２】
任意選択として、トップレベル・フラグメントおよび次レベルフラグメントのコンテンツ長値の合計が、計算され、第４メッセージの「Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ（コンテンツ長）」ヘッダに、コンテンツ長値の合計がセットされる。
【００４３】
任意選択として、トップレベル・フラグメントおよび次レベルフラグメントの最終修正時刻が判定され、第４メッセージの「Ｌａｓｔ−Ｍｏｄｉｆｉｅｄ（最終修正）」ヘッダに、最終修正時刻がセットされる。
【００４４】
任意選択として、依存識別子の組が、第１メッセージから取り出され、依存識別子は、フラグメントを編成したサーバによって生成され、依存識別子の組は、フラグメントのソース識別子に関連して保管される。この場合に、任意選択として、無効化要求メッセージを取り出すことができ、このメッセージから、依存識別子が取り出される。これによって、依存識別子に関連するフラグメントの組を判定できるようになり、その結果、判定された組フラグメントをキャッシュから消去することができる。
【００４５】
フラグメント・キャッシング規則の組が、第１メッセージから判定され、フラグメントのキャッシュ識別子が、フラグメント・キャッシング規則に従って生成されることが好ましい。この場合に、たとえば、キャッシュ識別子を使用して、フラグメントを一意に識別することができる。さらに、フラグメントの生成されたキャッシュ識別子を使用して、保管動作を実行することができる。
【００４６】
任意選択として、少なくとも、フラグメントに関連するＵＲＩ（UniformResource Identifier）のパス部分が、基本キャッシュ識別子を形成するために入手され、フラグメント・キャッシング規則が基本キャッシュ識別子に適用されて、フラグメントのキャッシュ識別子が形成され、フラグメント・キャッシング規則に、基本キャッシュ識別子に付加される名前／値対を入手するのに使用される照会パラメータ名またはクッキー名あるいはその両方の組が含まれる。
【００４７】
本発明の第４の態様によれば、ネットワーク内のデータ処理システムでオブジェクトを処理する方法であって、サーバで要求メッセージを受信するステップであって、前記要求メッセージが、フラグメントに関するソース識別子を含む、前記受信するステップと、前記フラグメントを含む応答メッセージを生成するステップと、前記要求メッセージがフラグメントに関連することを示すメッセージ・ヘッダを前記応答メッセージに挿入するステップとを含む方法が提供される。
【００４８】
本発明の第５の態様によれば、ネットワーク内のデータ処理システムでオブジェクトを処理する装置であって、サーバで要求メッセージを受信する手段であって、前記要求メッセージが、フラグメントのソース識別子を含む、前記手段と、前記フラグメントを含む応答メッセージを生成する手段と、前記要求メッセージがフラグメントに関連すること、およびフラグメントがキャッシュ可能か否かを示すメッセージ・ヘッダを前記応答メッセージに挿入する手段とを含む装置が提供される。
【００４９】
本発明の第６の態様によれば、オブジェクトを処理するためにネットワーク内のデータ処理システムで使用されるコンピュータ可読媒体内のコンピュータ・プログラム製品であって、サーバで要求メッセージを受信する命令であって、前記要求メッセージが、フラグメントのソース識別子を含む、前記命令と、前記フラグメントを含む応答メッセージを生成する命令と、前記第１メッセージがフラグメントに関連すること、およびフラグメントがキャッシュ可能か否かを示すメッセージ・ヘッダを前記応答メッセージに挿入する命令とを含むコンピュータ・プログラム製品が提供される。
【００５０】
応答メッセージのメッセージ本体部分がフラグメントであることを示すメッセージ・ヘッダが、応答メッセージに挿入され、メッセージヘッダが、応答メッセージのメッセージ本体部分がフラグメントであることを示すことが好ましい。
【００５１】
フラグメントが、フラグメント非サポート式キャッシュ管理ユニットにキャッシュ不能であることを示すメッセージ・ヘッダと、フラグメントが、フラグメント・サポート式キャッシュ管理ユニットにキャッシュ可能であることの表示が、応答メッセージに挿入されることが好ましい。
【００５２】
本発明の第７の態様によれば、ネットワークで送信されるメッセージを定義する際にコンピューティング・デバイスで使用されるデータ構造であって、メッセージが要求メッセージまたは応答メッセージであることのインジケータと、メッセージが、フラグメント・サポート式キャッシュ管理ユニットによって処理されるものであることを示すキーワードおよびメッセージが処理される形を示す１つまたは複数のフラグメント・ヘッダ・ディレクティブを含むフラグメント・ヘッダとを含むデータ構造が提供される。
【００５３】
フラグメント・サポート式キャッシュ管理ユニットが、コンピューティング・デバイス内に配置され、コンピューティング・デバイスがネットワーク全体に配置されたクライアント、サーバ、またはハブのどれとして働くかに無関係に、フラグメント・キャッシング動作をサポートして同等に動作することが好ましい。
【００５４】
請求項のデータ構造が、要求メッセージを処理したコンピューティング・デバイスがフラグメント・サポート式キャッシュ管理ユニットを有することを示す、要求メッセージに含めるためのフラグメント・ヘッダ・ディレクティブも有することが好ましい。
【００５５】
データ構造が、フラグメント・サポート式キャッシュ管理ユニットによって維持されるキャッシュから応答メッセージ内のフラグメントを消去するために起点サーバによって使用される依存識別子の組を示す、応答メッセージに含めるためのフラグメント・ヘッダ・ディレクティブを有することが好ましい。
【００５６】
データ構造が、応答メッセージ内のフラグメントを一意に識別するキャッシュ識別子を構成するのに使用されるフラグメント・キャッシング規則の組を示す、応答メッセージに含めるためのフラグメント・ヘッダ・ディレクティブを有することが好ましい。
【００５７】
任意選択として、要求メッセージまたは応答メッセージは、ＨＴＴＰ（ハイパーテキスト転送プロトコル）要求メッセージまたはＨＴＴＰ応答メッセージである。
【００５８】
本発明の第８の態様によれば、コンテンツ・オブジェクトを定義する際にコンピューティング・デバイスによって使用されるデータ構造であって、マークアップ言語要素の区切り文字の組と、マークアップ言語要素がフラグメントへのリンクであることを示すキーワードと、フラグメントのソース識別子であって、ソース識別子が、フラグメントを取り出すためにフラグメント・サポート式キャッシュ管理ユニットによって使用される、ソース識別子とを含むデータ構造が提供される。
【００５９】
フラグメント・サポート式キャッシュ管理ユニットが、コンピューティング・デバイス内に配置され、コンピューティング・デバイスがネットワーク全体に配置されるクライアント、サーバ、またはハブのどれとして働くかに無関係に、フラグメント・キャッシング動作をサポートして同等に動作することが好ましい。
【００６０】
データ構造が、フラグメントの代替ソース識別子を有し、フラグメント・サポート式キャッシュ管理ユニットが、代替ソース識別子を使用してフラグメントを取り出せることが好ましい。
【００６１】
データ構造が、ソース識別子に付加される照会パラメータの組を有することが好ましい。
【００６２】
マークアップ言語が、ＳＧＭＬ（標準汎用印刷指定言語）であることが好ましい。マークアップ言語要素が、ＨＴＭＬ（ハイパーテキスト・マークアップ言語）との互換性を有することが好ましい。
【００６３】
フラグメント・キャッシングの方法、システム、装置、およびコンピュータ・プログラム製品が、提示される。メッセージが、キャッシュ管理ユニットを含むコンピューティング・デバイスで受信された後に、そのメッセージのメッセージ本体のフラグメントが、キャッシングされる。キャッシュ管理ユニットでのフラグメントに関する後続の要求が、キャッシュ・ヒットをもたらす。キャッシュ管理ユニットは、コンピューティング・デバイスがネットワーク全体に配置されるクライアント、サーバ、またはハブのどれとして働くかに無関係にフラグメント・キャッシング動作をサポートして同等に動作する。言い換えると、このフラグメント・キャッシング技法は、ネットワーク全体を通じて一様である。
【００６４】
ＦＲＡＧＭＥＮＴヘッダは、ＨＴＴＰなどのネットワーク・プロトコル内で使用するために定義され、このヘッダによって、メタデータが、フラグメントの処理およびキャッシングに関連するさまざまな目的のためにフラグメントに関連付けられる。キャッシュＩＤ規則に、起点サーバからのフラグメントが付随し、キャッシュＩＤ規則によって、ダイナミック・コンテンツを起点サーバから離れてキャッシングできるように、フラグメントの一意のキャッシュＩＤを形成する方法が記述される。キャッシュＩＤは、フラグメントのＵＲＩ（Uniform Resource Identifier）に基づくものとすることができるが、キャッシュＩＤを、照会パラメータまたはクッキーあるいはその両方に基づくものとすることもできる。キャッシュＩＤまたはフラグメントのＵＲＩと異なるものとすることができる依存ＩＤを、フラグメントに関連付けることができ、その結果、サーバが、フラグメントをキャッシュから消去する無効化動作を開始できるようになる。ＦＲＡＧＭＥＮＴＬＩＮＫタグが、ページ組立またはページ・レンダリング中に挿入されるインクルードされるフラグメントのページ内での位置を指定するのに使用される。
【００６５】
本発明を、添付図面に示された本発明の好ましい実施形態に関して、例としてのみ説明する。
【発明を実施するための最良の形態】
【００６６】
本発明は、分散フラグメント・キャッシング技法を対象とする。一般に、本発明の好ましい実施形態を含むかこれに関連することができる装置には、広範囲のデータ処理技術が含まれる。したがって、本発明の好ましい実施形態を詳細に説明する前に、背景として、分散データ処理システム内のハードウェア構成要素およびソフトウェア構成要素の通常の編成を説明する。
【００６７】
図面に関して、図１に、本発明の好ましい実施形態のいくつかの態様をそれぞれが実施できるデータ処理システムの通常のネットワークを示す。分散データ処理システム１００に、ネットワーク１０１が含まれ、このネットワーク１０１は、分散データ処理システム１００内で一緒に接続されるさまざまな装置およびコンピュータの間の通信リンクを提供するのに使用することができる媒体である。ネットワーク１０１には、ワイヤまたは光ファイバ・ケーブルなどの永久的接続、あるいは電話通信または無線通信を介して行われる一時的接続を含めることができる。図示の例では、サーバ１０２およびサーバ１０３が、記憶装置１０４と共にネットワーク１０１に接続される。さらに、クライアント１０５から１０７も、ネットワーク１０１に接続される。クライアント１０５から１０７およびサーバ１０２から１０３は、メインフレーム、パーソナル・コンピュータ、携帯情報端末（ＰＤＡ）などのさまざまなコンピューティング・デバイスによって表すことができる。分散データ処理システム１００に、図示されていない、追加のサーバ、クライアント、ルータ、他の装置、およびピアツーピア・アーキテクチャを含めることができる。図１に示された分散データ処理システムが、さまざまなピアツーピア・サブネットおよびピアツーピア・サービスを完全にサポートできることが企図されていることに留意されたい。
【００６８】
図示の例では、分散データ処理システム１００に、インターネットを含めることができ、ここで、ネットワーク１０１は、Lightweight Directory Access Protocol（ＬＤＡＰ）、伝送制御プロトコル／インターネット・プロトコル（ＴＣＰ／ＩＰ）、ハイパーテキスト転送プロトコル（ＨＴＴＰ）、WirelessApplication Protocol（ＷＡＰ）などのさまざまなプロトコルを使用して互いに通信するネットワークおよびゲートウェイの全世界の集合を表す。もちろん、分散データ処理システム１００に、たとえばイントラネット、ローカル・エリア・ネットワーク（ＬＡＮ）、無線ＬＡＮ、または広域ネットワーク（ＷＡＮ）などの複数の異なるタイプのネットワークを含めることもできる。たとえば、、サーバ１０２によって、クライアント１０９および無線通信リンクを組み込まれたネットワーク１１０が直接にサポートされる。ネットワーク対応の電話機１１１が、無線リンク１１２を介してネットワーク１１０に接続され、ＰＤＡ１１３が、無線リンク１１４を介してネットワーク１１０に接続される。電話機１１１およびＰＤＡ１１３によって、Ｂｌｕｅｔｏｏｔｈ（商標）無線技術などの適当な技術を使用して、それら自体の間で無線リンク１１５を介して直接にデータを転送して、いわゆるパーソナル・エリア・ネットワーク（ＰＡＮ）またはパーソナル・アドホック・ネットワークを作成することもできる。類似する形で、ＰＤＡ１１３によって、無線通信リンク１１６を介してＰＤＡ１０７にデータを転送することができる。
【００６９】
本発明の好ましい実施形態は、さまざまなハードウェア・プラットフォームで実施することができ、図１は、異機種コンピューティング環境の例であることを意図されたものであって、本発明に関するアーキテクチャ制限として意図されたものではない。後続の例で、サーバタイプの機能性と比較してクライアント・タイプの機能性に具体的に言及することに留意されたい。しかし、周知のように、ハブまたは、ピアツーピア・ネットワーク内のコンピューティング・デバイスすなわちピアなどの一部のコンピューティング・デバイスは、クライアント・タイプの機能性とサーバ・タイプの機能性の両方を示す。本発明の好ましい実施形態は、必要に応じて、クライアント、サーバ、ピア、またはハブで実施することができる。
【００７０】
図２に関して、図に、本発明の好ましい実施形態を実施できる、図１に示されたものなどのデータ処理システムの通常のコンピュータ・アーキテクチャが示されている。データ処理システム１２０に、内部システム・バス１２３に接続された１つまたは複数の中央処理装置（ＣＰＵ）１２２が含まれ、内部システム・バス１２３によって、ランダム・アクセス・メモリ（ＲＡＭ）１２４、読取専用メモリ１２６、および入出力アダプタ１２８が相互接続され、入出力アダプタ１２８によって、プリンタ１３０、ディスク装置１３２、またはオーディオ出力システムなどの図示されていない他の装置がサポートされる。システム・バス１２３によって、通信アダプタ１３４も接続され、通信アダプタ１３４によって、通信リンク１３６へのアクセスが提供される。ユーザ・インターフェース・アダプタ１４８によって、キーボード１４０、マウス１４２、あるいはタッチ・スクリーン、スタイラス、またはマイクロフォンなどの図示されない他の装置が接続される。ディスプレイ・アダプタ１４４によって、システム・バス１２３がディスプレイ１４６に接続される。
【００７１】
当業者は、図２のハードウェアを、システム実施形態に応じて変更できることを諒解するであろう。たとえば、このシステムは、Ｉｎｔｅｌ（登録商標）Ｐｅｎｔｉｕｍ（Ｒ）（登録商標）ベースのプロセッサ、ディジタル信号プロセッサなどの１つまたは複数のプロセッサと、１つまたは複数のタイプの揮発性メモリおよび不揮発性メモリを有することができる。他の周辺装置を、図２に示されたハードウェアに加えてまたはこれの代わりに使用することができる。言い換えると、当業者は、ウェブ対応またはネットワーク対応の電話機および機能満載のデスクトップ・ワークステーションに、ある類似する構成要素またはアーキテクチャを見つけることが期待される。図示の例は、本発明の好ましい実施形態に関するアーキテクチャ的制限を暗示することを意図されたものではない。
【００７２】
さまざまなハードウェア・プラットフォームで実施できることのほかに、本発明の好ましい実施形態は、さまざまなソフトウェア環境で実施することができる。通常のオペレーティング・システムを使用して、各データ処理システム内のプログラム実行を制御することができる。たとえば、ある装置によって、Ｌｉｎｕｘ（登録商標）オペレーティング・システムを動作させることができ、別の装置に、単純なＪａｖａ（Ｒ）（登録商標）ランタイム環境を含めることができる。代表的なコンピュータ・プラットフォームに、ブラウザを含めることができ、ブラウザは、グラフィック・ファイル、ワード・プロセッシング・ファイル、Extensible Markup Language（ＸＭＬ）、ハイパーテキスト・マークアップ言語（ＨＴＭＬ）、HandheldDevice Markup Language（ＨＤＭＬ）、Wireless Markup Language（ＷＭＬ）などのさまざまなフォーマットおよびエンコーディングのファイル、文書、オブジェクト、または他のデータ項目にアクセスするための周知のソフトウェア・アプリケーションである。これらのオブジェクトは、通常は、UniformResource Identifier（ＵＲＩ）を使用してアドレッシングされる。ＵＲＩの組に、Uniform Resource Locator（ＵＲＬ）およびUniformResource Name（ＵＲＮ）が含まれる。
【００７３】
図３に関して、図に、キャッシュを分散データ処理システム全体で実施できる、図１に示されたものなどの通常の分散データ処理システムが示されている。分散データ処理システム１５０に、コンテンツの要求を生成する要求元エンティティ１５２が含まれる。要求元エンティティ１５２は、さまざまな個人顧客または機関顧客にサービスするＩＳＰあるいは要求されるコンテンツをさまざまな目的に使用する企業とすることができる。データ、たとえば要求が、要求元エンティティ（使用するエンティティ）から、応答するエンティティ（サービスするエンティティ、たとえば起点サーバ）に向かって移動する時に、そのデータを、「上流に」移動すると言う。データ、たとえば応答が、応答するエンティティから受信するエンティティに向かって移動する時に、そのデータを、「下流に」移動すると言う。
【００７４】
クライアント・ブラウザ１５４からの要求が、ディスパッチャ１５６によってルーティングされ、ディスパッチャ１５６によって、インターネットを介してインターネット・エクスチェンジ・ポイント１６０で要求を転送する前に要求を満足する試みで、中間サーバ１５８の組を介して要求が均等に分配される。各ブラウザ１５４によって、ローカル・キャッシュを維持することができ、各サーバ１５８によって、順方向プロキシ・キャッシング機構がサポートされる。インターネット・エクスチェンジ・ポイント１６０には、中間サーバ１６２および１６４も含まれ、中間サーバ１６２および１６４のそれぞれによって、キャッシュを維持することができる。ブラウザ１５４でのまたは中間サーバ１５８、１６０、１６２、および１６４でのキャッシュの実施に関するさまざまな考慮事項に、応答時間の改善または帯域幅の削減あるいはその両方が含まれる。
【００７５】
次に、要求が、インターネット・エクスチェンジ・ポイント１６０からサービスする企業１６８のディスパッチャ１６６にルーティングされる。ディスパッチャ１６６によって、中間サーバ１７０を介して着信要求が均等に分配され、中間サーバ１７０によって、ディスパッチャ１７２への要求の転送の前に、要求を満足することが試みられ、各中間サーバ１７０は、逆方向プロキシ・キャッシング機構をサポートする。満足されない要求は、ディスパッチャ１７２によって、ウェブ・アプリケーション・サーバ１７４にまたがって均等に分配され、ウェブ・アプリケーション・サーバ１７４は、データベース１７６にアクセスするデータベース・サービスまたは他のアプリケーションとあいまって、要求を最終的に満足することができる。中間サーバ１７０でのまたはウェブ・アプリケーション・サーバ１７４でのキャッシュの実施に関するさまざまな考慮事項に、スループットの改善またはコストの削減あるいはこの両方が含まれる。
【００７６】
応答は、反対の方向で、サービスする企業からクライアント・デバイスにルーティングされる。類似する中間サーバを、使用する企業内、インターネット全体、またはサービスする企業内で展開できることに留意されたい。クライアントから離れる、要求が通る各連続するステージが、知覚される応答時間に追加されることにも留意されたい。
【００７７】
本発明の好ましい実施形態は、上で説明したように、さまざまなハードウェア・プラットフォームおよびソフトウェア・プラットフォームで実施することができる。しかし、具体的に言うと、本発明の好ましい実施形態は、分散フラグメント・キャッシング技法を対象とする。本発明の好ましい実施形態を詳細に説明する前に、静的ウェブ・コンテンツおよびダイナミック・ウェブ・コンテンツ全般に関する背景情報を提供する。
【００７８】
静的なテキストおよびグラフィック・コンテンツを含むウェブ・ページのフォーマットは、通常は、ＨＴＭＬなどのマークアップ言語を使用して指定される。マークアップは、ページがインターネット・ブラウザによって読み取られる時に単語およびイメージの表示を制御する特殊なコードまたはタグからなる。しかし、Ｊａｖａ（Ｒ）Ｓｅｒｖｅｒ  Ｐａｇｅ（ＪＳＰ）およびサーブレットが、ダイナミック・コンテンツを含むウェブ・ページにより適する。
【００７９】
基本的に、ＪＳＰは、ページを含む応答を生成するためにページに関する要求を処理する方法を記述した組込み指示を有するマークアップ言語文書である。この記述では、単一の文書内で、静的テンプレート・コンテンツが、Ｊａｖａ（Ｒ）コードとして実装されたダイナミック・アクションと混合される。ＪＳＰを使用すると、サーバ側スクリプトレットとしてページにＪａｖａ（Ｒ）コードをインライン展開することもできる。言い換えると、Ｊａｖａ（Ｒ）タグが、ウェブ・ページで指定され、ウェブ・サーバで実行されて、ウェブ・ページが、それを要求したユーザに送信される前に修正される。この手法は、プログラミング・ロジックが比較的少ない時に適する。マークアップ言語文書内に些細な量を超えるプログラミング・ロジックを有することによって、ＪＳＰの優位点すなわち、文書に関連するビジネス・ロジックから文書のプレゼンテーションを分離することが失われる。過度な量のコードをマークアップ言語文書に直接にインライン展開しないようにするために、ＪＳＰによって、単純なＪＳＰタグを使用してランタイムにアクセスできるＪａｖａ（Ｒ）Ｂｅａｎｓにビジネス・ロジックを分離する能力が使用可能にされる。
【００８０】
具体的に言うと、ＪＳＰでは、マークアップ風のタグおよびＪａｖａ（Ｒ）プログラミング言語で記述されたスクリプトレットを使用して、ページのコンテンツの一部またはすべてを生成するロジックをカプセル化する。アプリケーション・ロジックは、Ｊａｖａ（Ｒ）Ｂｅａｎコンポーネントなどの、そのページからタグおよびスクリプトレットによってアクセスされるサーバベースのリソースに常駐させることができる。マークアップ言語タグを使用することによって、たとえばＨＴＭＬページ・ビルダ／エディタなどのツールによっても操作できる便利な形での有用な機能性の、マークアップ言語文書内でのカプセル化が可能になる。ビジネス・ロジックをプレゼンテーションから分離することによって、再利用可能なコンポーネントベースの設計がサポートされる。ＪＳＰによって、ウェブ・ページ作成者が、静的ＨＴＭＬテンプレートにダイナミック・コンテンツ・モジュールを挿入できるようになり、したがって、ウェブ・コンテンツの作成が単純化される。ＪＳＰは、Ｓｕｎ社のJava（Ｒ）Enterprise Edition（Ｊ２ＥＥ）プログラミング・モデルに一体化された部分である。
【００８１】
下で説明する本発明の好ましい実施形態の例で、ＪＳＰを使用できることに留意されたい。しかし、Ｍｉｃｒｏｓｏｆｔ社のActive Server Page（ＡＳＰ）などの他のタイプのサーバ・ページも、使用することができる。
【００８２】
製品表示ＪＳＰによって、製品に関するデータが表される。特定の製品、たとえばレンチに関する要求によって、ＪＳＰならびに製品ｉｄが、照会パラメータとして識別される。製品ｉｄパラメータを用いるそのＪＳＰの実行によって、ＨＴＭＬのページが出力される。その製品の基礎になるデータが変更される時、たとえばレンチが値上げされる時に、そのページを無効化しなければならない。これを行うために、データを表す依存ＩＤをページに関連付けることによって、ページとデータの間に依存性を確立しなければならない。
【００８３】
粒度は、効果的なキャッシング戦略に重要な、ウェブ・ページの特性である。ウェブ・ページのコンテンツは、複数の構成要素からなり、この構成要素の中に、頻繁に変更されるものと比較的静的なものがある場合がある。ウェブ・ページの粒度は、コンテンツの一部である「フラグメント」に関して説明することができる。フラグメントは、ＪＳＰファイルに関するＨＴＴＰ要求を満足することを含めて、さまざまな形で作成することができる。上の例では、製品表示ページが、単一のフラグメント・ページである。
【００８４】
図４に関して、ブロック図に、フラグメントからなるウェブ・ページが示されている。この例では、フラグメント粒度によって、一部のフラグメントが揮発性であり、ある時間的基礎で更新されることがわかっている場合であっても、ページの諸部分をキャッシングできることが示されている。言い換えると、さまざまなタイプのウェブ・コンテンツが、キャッシングから異なる度合の利益を得る。
【００８５】
製品表示ウェブ・ページに、ダイナミック・コンテンツ・フラグメント２００が含まれる。トップレベル・フラグメントは、Java（Ｒ）Server Page（ＪＳＰ）２０４であり、これには、５つの子フラグメント２０６から２１４が含まれる。フラグメント２０８および２１２は、キャッシングされる。子フラグメントが、図のタイムラインによって示されるように、基礎になるデータの変更の割合の昇順で左から右に配置されていることに留意されたい。
【００８６】
製品ＵＲＩ２０６は、製品のGraphics Interchange Format（ＧＩＦまたは．ｇｉｆ）イメージ・ファイルへのUniformResource Identifier（ＵＲＩ）リンクである。フォーマットされたテーブルによって、詳細な製品記述２０８を保持することができる。パーソナライズされた挨拶２１０を表示するフラグメントによって、買物客の名前を使用することができる。この挨拶は、しばしば、たとえばユーザごとに変更されるが、所与の買物客の名前が同一のユーザによるセッションの過程で再利用されるので、キャッシングすることが役に立つ可能性がある。
【００８７】
ＪＳＰ２１２によって、省略されたショッピング・カートが作成される。ショッピング・カートＪＳＰ２１２によって、データを表示するＨＴＭＬテーブルを作成することができる。このコンテンツは、買物客が自分のカートに何かを追加するたびに更新されなければならないので、パーソナライズされた挨拶２１０より頻繁に変更される。それでも、ショッピング・カートが、買物客に返されるすべてのページに表示される場合に、カートを表示するたびに同一のデータを取り出すよりも、ＪＳＰ２１２をキャッシングすることがより効率的である。ＪＳＰ２０４に、株式ウォッチ・リストを表示するウェブ・ページに表示される宣伝２１４も含めることができる。宣伝は、ページが要求されるたびに変更されるので、更新レートは、キャッシングから利益を得るには高すぎる。
【００８８】
図１から４に、本発明の好ましい実施形態の説明の背景文脈として、さまざまな分散データ処理システムおよびダイナミック・コンテンツの例を示した。上で述べたように、効率的にフラグメントをキャッシングすることは、困難になる可能性がある。本発明の好ましい実施形態は、ダイナミック・フラグメントおよびパーソナライズされたフラグメントすなわちダイナミック・コンテンツのキャッシングに関連する問題を克服することに特に注意して、フラグメントを効率的にキャッシングするためにＨＴＭＬおよびＨＴＴＰに対する拡張を使用する技法を対象とする。
【００８９】
下で示す例で、ＨＴＴＰ／１．１およびＨＴＭＬ  ４．１など、プロトコルの特定の仕様に言及することに留意されたい。しかし、当業者は、本発明の好ましい実施形態によって要求されるものと同等の特徴および機能性の最小限の組を備える他のプロトコルも使用できることを、諒解するであろう。
【００９０】
用語法
「静的フラグメント」は、照会パラメータまたはクッキーを使用せずに入手できるフラグメントと定義される。静的フラグメントは、そのＵＲＩだけから参照され、キャッシングされ、またはフェッチされ、あるいはこの組合せによって入手することができる。
【００９１】
「ダイナミック・フラグメント」は、要求元によって供給されるパラメータまたはクッキーに基づくサーバでの計算の結果として生成されるフラグメントである。ダイナミック・フラグメントの例を、スポーツ・イベントの結果とすることができる。ダイナミック・フラグメントは、サイトに固有の、ユーザによって要求されたデータのサブセットからなるという特徴を有する。
【００９２】
「パーソナライズされたフラグメント」も、要求元のパラメータまたはクッキーに基づく計算の結果として生成される。パーソナライズされたフラグメントは、そのコンテンツがユーザに依存するという点で、ダイナミック・フラグメントの特殊な例である。パーソナライズされたフラグメントは、たとえばアカウント番号など、不揮発性とするか、たとえばショッピング・バスケットなど、揮発性とすることができる。フラグメントの定義および管理において、ダイナミック・フラグメントおよびパーソナライズされたフラグメントによって、同等の問題が提示され、したがって、用語「ダイナミック」および「パーソナライズされた」は、交換可能に使用される。
【００９３】
「トップレベル・フラグメント」は、他のフラグメントに組み込まれるのではなく、それ自体に他のフラグメントを組み込むことができるフラグメントである。
【００９４】
「ページ・アセンブラ」は、フラグメントからページを構成するプログラムである。フラグメントの収集およびページの構成の処理を、「ページ組立」と呼ぶ。追加のフラグメントをフェッチし、文書に組み立てなければならないかどうかを判定するためにフラグメントを検査する処理を、本明細書では、文字どおりの構文解析が実行されない場合であっても、「構文解析」と呼ぶ。たとえば、フラグメントにメタ情報が付随し、このメタ情報によって、組立のためにフェッチされなければならない追加フラグメントの名前が指定され、追加フラグメントを挿入しなければならない正確な位置が指定される場合があり、追加フラグメントに関するそのようなフラグメントの検査は、必ずしも計算機科学の形式的な構文解析ではない。
【００９５】
ＦＲＡＧＭＥＮＴＬＩＮＫタグの定義
図５に関して、本発明の好ましい実施形態による、ＦＲＡＧＭＥＮＴＬＩＮＫタグの形式的な標準汎用印刷指定言語（ＳＧＭＬ）定義が示されている。ＦＲＡＧＭＥＮＴＬＩＮＫタグは、ページ組立中またはページ・レンダリング中に、文書に挿入されるフラグメントの位置を指定するのに使用される。新しいオブジェクトが、親文書の一部として構文解析され、新しいオブジェクトに、それ自体のＦＲＡＧＭＥＮＴＬＩＮＫタグを含めることができる。ＦＲＡＧＭＥＮＴＬＩＮＫタグの属性の定義を、下で説明する。
【００９６】
（マークアップ言語で、通常は、角括弧（「＜」および「＞」）が、区切り文字として使用されることに留意されたい。この文書のマークアップ言語バージョンでの潜在的なフォーマッティング問題または電子解釈問題を避けるために、大括弧（「｛」および「｝」）を、この文書全体で置換区切り文字として使用する。もう１つのフォーマッティングの注記として、長いテキスト文字列のいくつかの例が、この文書ではテキストの複数の行を占める。当業者は、この文書で行の境界をまたぐように見えるものであっても、単一行のテキストとして示されることを意図されたテキストを判定することができるであろう。）
【００９７】
ｓｒｃ＝ＵＲＩ
ＳＲＣ属性によって、文書に挿入されるフラグメントのソース位置が指定され、ＳＲＣ属性は、フラグメントの入手に関するソース識別子として働く。ＵＲＩが、相対ＵＲＩである場合には、絶対ＵＲＩは、親のパスおよび関連するＢＡＳＥタグから得られる。単一の共通フラグメントが２つの異なるページに含まれる場合に、これによって混乱が生じる可能性があることに留意されたい。作成者は、フラグメントＵＲＩに関して絶対パス名だけをコーディングすることが推奨される。ＵＲＩのプロトコル部分によって、「クッキー」を指定することができるが、この場合に、挿入されるテキストの値は、名前を指定されたクッキーから取られる。
【００９８】
ａｌｔ＝ｓｔｒｉｎｇ
ＡＬＴ属性によって、ＳＲＣ属性からのＵＲＩをフェッチできない場合に置換される代替ＨＴＭＬテキストが指定される。ＡＬＴ属性が指定されず、ＳＲＣ属性のフラグメントをフェッチできない場合には、フラグメントはフェッチされない。
【００９９】
ｐａｒｍｓ＝％ｐａｒｍｌｉｓｔ
ＰＡＲＭＳ属性によって、スペースによって区切られた名前のリストが指定される。各名前は、親フラグメントのＵＲＩに存在する可能性がある照会パラメータに対応する。ＰＡＲＭＳ属性が指定される時には、ＳＲＣ属性で指定されたＵＲＩが、不完全とみなされる。ＳＲＣ属性を完成するために、ＰＡＲＭＳ属性で名前を指定された照会パラメータのそれぞれの値を、親文書からフェッチし、これを使用して名前／値対を作成しなければならない。この名前／値対は、ＳＲＣ属性のＵＲＩに、それを完成させるために、照会パラメータとして付加される。名前を指定されたパラメータが親ＵＲＩに存在しない場合には、そのパラメータは、フラグメントのＵＲＩに付加されない。各パラメータは、ＰＡＲＭＳ属性に現れるのと同一の順序でＳＲＣ属性のＵＲＩに付加されなければならない。
【０１００】
ｆｏｒｅａｃｈ＝ｑｕｏｔｅｄ−ｓｔｒｉｎｇ
ＦＯＲＥＡＣＨ属性によって、引用符で囲まれた文字列が指定される。引用符で囲まれた文字列の値は、クッキーの名前であることが好ましく、このクッキーの値は、スペースによって区切られた名前／値対のリストであり、名前および値は、等号（「＝」）または他のタイプの同等の区切り文字によって区切られる。クッキーに含まれる名前／値対ごとに、そのＳＲＣ属性が、名前／値対を照会パラメータとして追加されたＵＲＩである、新しいＦＲＡＧＭＥＮＴＬＩＮＫタグが生成される。これによって、たとえばユーザの株式ウォッチリストなど、１つの照会パラメータの値だけが異なる複数のＦＲＡＧＭＥＮＴＬＩＮＫタグを自動的に生成する速記法がもたらされる。
【０１０１】
言い換えると、ＦＯＲＥＡＣＨ属性によって、フラグメントへの単一リンクの、複数のフラグメントへの複数のリンクの組への拡張が提供される。各名前／値対は、拡張パラメータ名および拡張パラメータ値の対になる。
【０１０２】
ｓｈｏｗｌｉｎｋ＝（ｎｏ｜ｃｏｍｍｅｎｔ｜ＣＤＡＴＡ）
ＳＨＯＷＬＩＮＫ属性によって、インクルードされるフラグメント・データをラップするのに使用されるタグの名前が指定される。「ｎｏ」と指定される場合に、データは、ラップするタグに含まれない。「ｃｏｍｍｅｎｔ」と指定される場合に、ＦＲＡＧＭＥＮＴＬＩＮＫタグが、ＨＴＭＬコメントとして書き直される。他の値が指定される場合に、ＦＲＡＧＭＥＮＴＬＩＮＫタグが、指定されたタグとして書き直される。ＣＤＡＴＡが有効なタグであることを検証する検査は行われず、したがって、フラグメントを正確にどのように示すかの判断は、ページ作成者に委ねられる。ＳＨＯＷＬＩＮＫ属性が省略された場合には、ラッピングは行われない。
【０１０３】
ｉｄ＝ＩＤ
ＩＤ属性が指定される場合に、その識別子値が、www.w3c.orgでWorldWide Web Consortium（Ｗ３Ｃ）から入手可能な、参照によって本明細書に組み込まれる「HTML 4.01 Specification」、W3CRecommendation、1999年12月24日に従って、このフラグメントを表す結果のＤＯＭ要素内のフラグメントに一意の名前として割り当てられる。
【０１０４】
ｃｌａｓｓ＝ＣＤＡＴＡ
ＣＬＡＳＳ属性が指定される場合に、これによって、ＨＴＭＬ仕様に従って、このフラグメントを表すＤＯＭ要素にクラス名またはクラス名の組が割り当てられる。
【０１０５】
ページが組み立てられる時に、ページ・アセンブラによって、指定されたフラグメントがフェッチされ、親オブジェクトに挿入される。ＳＨＯＷＬＩＮＫ属性を使用して、挿入されるデータをタグまたはＨＴＭＬコメントの内部にラップできるようにすることができる。入れ子になったフラグメントが提供されるが、フラグメントを、それ自体を直接にまたは間接的に含めることはできない。フラグメント空間内のすべてのフラグメントの入れ子構造は、有向非循環グラフ（ＤＡＧ）を形成しなければならない。付随するＨＴＴＰ応答ヘッダのすべてが、文書の一部とみなされず、文書に挿入される前に除去されなければならない。キャッシュでは、他の文書と同様に、これらのヘッダを保存しなければならない。代替フラグメントＵＲＩを指定することができる。ＡＬＴ属性によって指定されるフラグメントは、ＳＲＣフラグメントをフェッチできない場合にフェッチされ、挿入される。ＳＲＣ属性のフラグメントもＡＬＴ属性のフラグメントもフェッチできない場合には、ＦＲＡＧＭＥＮＴＬＩＮＫタグが起点文書に含まれなかったかのようにレンダリングを継続することができる。
【０１０６】
ダイナミック・フラグメントまたはパーソナライズされたフラグメントの使用に伴う問題は、それらをフェッチするのに使用されるＵＲＩを、親ページが存在する環境またはコンテキストから計算しなければならないことである。言い換えると、ＵＲＩは、親文書に付随する照会パラメータから動的に作成される必要がある場合があり、ＰＡＲＭＳ属性によってこの特徴がサポートされる。ＰＡＲＭＳ属性は、フラグメントをフェッチする時に使用される、親文書からの照会パラメータの名前のリストからなる。名前／値対が、ＰＡＲＭＳ属性で名前を指定されるパラメータごとに形成され、ＦＲＡＧＭＥＮＴＬＩＮＫタグのＳＲＣ属性で指定されるＵＲＩに照会パラメータとして（おそらくは追加して）付加される。これらの名前／値対は、ＰＡＲＭＳ属性に現れるのと同一の順序で付加されなければならない。さらに、親に関連するクッキーが、フラグメントの正しいフェッチまたは計算に必要になる場合がある。親文書に付随するすべてのクッキーを、フラグメントに関する要求と共に供給しなければならない。
【０１０７】
しばしば、たとえば株式ウォッチリストの使用で、照会パラメータの値だけが異なる多数のＦＲＡＧＭＥＮＴＬＩＮＫタグが必要になる。ＦＯＲＥＡＣＨ属性を、ページのコーディングを単純化する速記法として使用して、フラグメントを送信する時の帯域幅要件を減らし、キャッシュ内のフラグメントのサイズを減らすことができる。たとえば、次のようなＦＲＡＧＭＥＮＴＬＩＮＫタグが作成されると仮定し
{fragmentlink
src="http://www.acmeInvest.com/stockQuote.jsp"
alt="Error occurredtrying to find stockQuote.jsp"
foreach="issues" /}
次のようなクッキーがあると仮定する。
Cookie:issues="stock=IBM stock=CSCO stock=DELL"
【０１０８】
これによって、ＦＲＡＧＭＥＮＴＬＩＮＫタグが一連のＦＲＡＧＭＥＮＴＬＩＮＫタグに展開され、これによって、下記の新たに生成されるＦＲＡＧＭＥＮＴＬＩＮＫタグのそれぞれが評価される。
{fragmentlink
src="http://www.acmeInvest.com/stockQuote.jsp?stock=IBM"
alt="An error occurred trying to findstockQuote.jsp" /}
{fragmentlinksrc="http://www.acmeInvest.com/stockQuote.jsp?stock=CSCO"
alt="An error occurred trying to findstockQuote.jsp" /}
{fragmentlinksrc="http://www.acmeInvest.com/stockQuote.jsp?stock=DELL"
alt="An error occurred trying to findstockQuote.jsp" /}
【０１０９】
しばしば、フラグメントのテキストが、小さく、クッキーの値として含めることができ、ページ組立中のかなりの性能利益がもたらされる。これを指定するために、キーワードＣＯＯＫＩＥをＵＲＩのプロトコルに配置する。たとえば、
{fragmentlinksrc="cookie://cookiename" /}
【０１１０】
ＦＲＡＧＭＥＮＴヘッダの定義
図６に関して、本発明の好ましい実施形態によるＦＲＡＧＭＥＮＴヘッダの形式的な定義が示されている。本発明の実施形態では、新規のＨＴＴＰヘッダおよび既存の「Ｃａｃｈｅ−Ｃｏｎｔｒｏｌ」ヘッダに対する拡張を使用することができる。ＦＲＡＧＭＥＮＴヘッダは、参照によって本明細書に組み込まれる、www.ietf.orgでInternet Engineering Task Forceから入手可能な、ＨＴＴＰ仕様、「HypertextTransport Protocol -- HTTP/1.1」、Request for Comments 2616 (RFC 2616)、InternetEngineering Task Force、June 1999に対応する。
【０１１１】
フラグメントとしてのオブジェクトに関連するすべての情報が、ＦＲＡＧＭＥＮＴと称するヘッダにカプセル化される。このヘッダは、クライアント、サーバ、または中間キャッシュが、ページ組立能力を有するかどうかを識別するのに使用される。このヘッダによって、フラグメントのキャッシュ識別子（ＵＲＩの照会パラメータおよびオブジェクトに付随するクッキーに基づく）を形成する規則も指定される。さらに、このヘッダによって、ホストによって開始される無効化をサポートする、基礎となるデータに対するオブジェクトの依存関係が指定される。ＦＲＡＧＭＥＮＴヘッダは、「Ｃａｃｈｅ−Ｃｏｎｔｒｏｌ：ｆｒａｇｍｅｎｔｒｕｌｅｓ」ディレクティブが有効である場合に限って使用されなければならない。ＦＲＡＧＭＥＮＴヘッダの完全な構文を、図６に示す。ＦＲＡＧＭＥＮＴヘッダの属性の定義を、下で説明する。
【０１１２】
ｃｏｎｔａｉｎｓ−ｆｒａｇｍｅｎｔｓ：この属性によって、ページ・アセンブラが使用できるフラグメント・ディレクティブが応答の本体に含まれることが指定される。
【０１１３】
ｓｕｐｐｏｒｔｓ−ｆｒａｇｍｅｎｔｓ：この属性によって、起点要求元またはデータ・ストリーム内のキャッシュのいずれかがページ組立をサポートすることが指定される。このディレクティブは、ページ組立を完全にサポートするキャッシュまたはクライアントが挿入することができる。
【０１１４】
ｄｅｐｅｎｄｅｎｃｉｅｓ：この属性によって、応答の本体が依存する依存名のリストが指定される。
【０１１５】
ｃａｃｈｅｉｄ：この属性によって、オブジェクトのキャッシュＩＤの形成に使用される規則のリストが指定される。規則が「ＵＲＩ」として指定される場合に、応答のフルＵＲＩが、キャッシュＩＤとして使用される。キャッシュＩＤが規則として指定される場合に、下で詳細に説明するように、規則が要求ＵＲＩに適用されて、キャッシュＩＤが形成される。
【０１１６】
本発明の好ましい実施形態では、フラグメントのキャッシング規則は、キャッシュがページ組立をサポートする場合に、他のタイプのオブジェクトと異なる。したがって、「Ｃａｃｈｅ−Ｃｏｎｔｒｏｌ」ヘッダが、フラグメント・キャッシング規則が適用されることを示すように拡張される。これは、拡張によってｎｏ−ｃａｃｈｅディレクティブをオーバーライドすることによって行われる。「ｆｒａｇｍｅｎｔｒｕｌｅｓ」と称する新しいｃａｃｈｅ−ｒｅｑｕｅｓｔ−ｄｉｒｅｃｔｉｖｅが、ＨＴＴＰ／１．１仕様のセクション１４．９．６で指定される「Ｃａｃｈｅ−Ｃｏｎｔｒｏｌ」ｇｅｎｅｒａｌ−ｈｅａｄｅｒフィールドに対する拡張として実施される。この拡張の意図は、フラグメント組立をサポートするキャッシュでのｎｏ−ｃａｃｈｅディレクティブの挙動を修正することである。フラグメント組立をサポートしないキャッシュは、「ｆｒａｇｍｅｎｔｒｕｌｅｓ」ディレクティブを無視するが、これはＨＴＴＰ／１．０およびＨＴＴＰ／１．１での基本的なデフォルト挙動である。フラグメント組立をサポートするキャッシュは、「ｆｒａｇｍｅｎｔｒｕｌｅｓ」ディレクティブが付随する時に「ｎｏ−ｃａｃｈｅ」ディレクティブ（および存在するすべての「Ｐｒａｇｍａ：ｎｏ−ｃａｃｈｅ」ヘッダ）を無視し、応答に付随する他のヘッダに従ってキャッシング規則を適用する。「Ｃａｃｈｅ−Ｃｏｎｔｒｏｌ」ヘッダの例を示す。
Cache-Control: no-cache,fragmentrules
【０１１７】
ページ組立の機能および責任の識別
本発明の好ましい実施形態によって、フラグメント包含を定義できるという利益がもたらされ、その結果、ブラウザ・キャッシュを含むフラグメントが存在することのできるすべてのキャッシュを含む、ページ作成者からブラウザ・レンダリングまでのイベントのチェーン内のどの点でもページ組立を実施することが可能になる。ページ組立を実行できるソフトウェア・エンティティが、組立点（assembly point）として定義される。
【０１１８】
この特徴によって、下記の可能なシナリオが提示される。
１．ページを提供するＨＴＴＰサーバよりブラウザに近い組立点がない。この場合に、サーバは、それ自体で組立を行い、完全に組み立てられたページを提供しなければならない。
２．起点サーバのためにページ組立を実行できるある種のプロキシがある。このプロキシは、サイトの組立ポイントになることができる。起点サーバは、このプロキシにフラグメントを供給することができ、どのページも組み立てる必要がない。
３．ユーザのブラウザが、ページ組立を実行することができる。この場合に、ネットワーク・キャッシュまたはサーバがページ組立を行う必要はない。
【０１１９】
フラグメントを提供する方法すなわち、完全に組み立てるか組み立てないかを決定するために、サーバおよびキャッシュは、上流エージェントの少なくとも１つが組立点として従事しているかどうかを判定できなければならない。本発明の好ましい実施形態では、ＨＴＴＰ要求ヘッダを使用し、サーバの組立ポイントとして従事する能力を有するエージェントが、それがフラグメントを受け入れることができ、完全なページを受信する必要がないことを示すのにヘッダを使用できるようにする。ＦＲＡＧＭＥＮＴヘッダの「ｓｕｐｐｏｒｔｓ−ｆｒａｇｍｅｎｔｓ」ディレクティブは、クライアントまたはキャッシュが、それが組立点であることを下流キャッシュに示すために挿入することができる。「ｓｕｐｐｏｒｔｓ−ｆｒａｇｍｅｎｔｓ」ディレクティブの例を示す。
fragment:supports-fragments
【０１２０】
プロセッサがページ組立をサポートするのでというだけで、そのプロセッサがサーバから受信するすべてのオブジェクトに対してページ組立を行わなければならないことは暗示されない。サーバから受信するすべての文書を構文解析し、それの組立を試みることは、リソースの浪費と潜在的な問題のソースの両方である。したがって、サーバは、オブジェクトが提供される前に、そのオブジェクトを組み立てる必要があることを示さなければならない。キャッシュまたはブラウザでのページ組立を必要とするサーバによって、ＦＲＡＧＭＥＮＴＳヘッダの「ｃｏｎｔａｉｎｓ−ｆｒａｇｍｅｎｔｓ」ディレクティブが挿入されなければならない。「ｃｏｎｔａｉｎｓ−ｆｒａｇｍｅｎｔｓ」ディレクティブの例を示す。
fragment:Contains-Fragments
【０１２１】
ブラウザ・キャッシュを含むほとんどの現在のＨＴＴＰキャッシュでは、照会パラメータを有するすべてのオブジェクトが、キャッシュ可能でないと仮定される。ＨＴＴＰ／１．１では、キャッシング能力を拡張し、一般化して、キャッシュが、成功裡にフェッチしたすべてのオブジェクトをキャッシングできるようにする。しかし、ＨＴＴＰ  １．１キャッシュでも、しばしば、ダイナミック・オブジェクトのキャッシングはリソースの不十分な使用という仮定に基づいて、ダイナミックと思われるオブジェクトをキャッシングしないように構成される。この仮定が無効な状況の例が、パーソナライズされたデータの場合である。パーソナライズされたページは、照会パラメータまたはクッキーをページに関連付けることによって作成され、これによって、ページが、より一般的なページの特定のパーソナライズされたインスタンスとして識別される。ページがパーソナライズされるという事実によって、そのページが固有にキャッシュ不能になるわけではない。ページがキャッシュ不能になるのは、そのページが基づくデータが非常に揮発性である場合に限られる。これは、特定の企業のウェブ・コンテンツだけをキャッシングする企業サーバで特にそうである。
【０１２２】
そのようなページのキャッシングに対して通常与えられる議論は、そのようなページの再利用の発生が、キャッシュ内のスペースを正当化するには低すぎると言うことである。この議論は、複数の理由から不十分である。
１．最初の作成からブラウザでの最終的なレンダリングまでの文書のコストは、名目上は文書のサイズの関数のみである。文書が何らかの形で「ダイナミック」である場合に、コストの大半は、最初の場所での文書の作成にある。したがって、非常にわずかな再利用であっても、サーバでのかなりのコスト節約をもたらすことができる。
２．キャッシュの容量は、かなり増加し、非常に高い速度で増加し続けている。
３．フラグメント技術の採用によって、同一のＨＴＭＬコンテンツの冗長なインスタンスを削除することによって、キャッシングされるデータの量を実際に減らすことができる。
【０１２３】
フラグメントの導入によって、特にページ・アセンブラがキャッシュの内側で構成される場合に、キャッシュ・ポリシの指定が非常に複雑になる可能性がある。ページの各フラグメントが、異なるキャッシュ・ポリシを必要とする可能性がある。本発明の好ましい実施形態では、ＨＴＴＰ応答ヘッダを使用して、従来技術で使用可能なものに対してキャッシング・ポリシの粒度を増やす。
【０１２４】
実施されるページ・アセンブラに通信されなければならない、キャッシングに影響する２つの要因すなわち、（１）フラグメントの寿命および（２）オブジェクトの明示的なサーバ開始無効化（server-initiated invalidation）がある。サーバ開始無効化がない場合に、他のオブジェクトに関するキャッシュ内のオブジェクトの寿命を指定する同一の機構を、フラグメントに適用することができる。フラグメントを明示的にはサポートしないキャッシュでフラグメントがキャッシングされないようにすることが重要である場合には、ディレクティブ「ｎｏ−ｃａｃｈｅ」および「ｆｒａｇｍｅｎｔｒｕｌｅｓ」を有する「Ｃａｃｈｅ−Ｃｏｎｔｒｏｌ」ヘッダを、応答に含めなければならない。「ｎｏ−ｃａｃｈｅ」ディレクティブによって、実施しないキャッシュによるフラグメントのキャッシングが防止され、「ｆｒａｇｍｅｎｔｒｕｌｅｓ」ディレクティブによって、実施するキャッシュが「ｎｏ−ｃａｃｈｅ」ディレクティブをオーバーライドできるようになる。
【０１２５】
サーバ開始無効化
サーバ開始無効化をサポートするキャッシュに、サーバからの明示的制御を介して、フラグメントを無効化しなければならないことを知らせることができる。サーバ開始無効化を認識しないかサポートしない既存の古いキャッシュとの互換性を維持するために、そのようなサーバによって無効化されたフラグメントに、ＨＴＴＰ／１．１の「Ｃａｃｈｅ−Ｃｏｎｔｒｏｌ」ヘッダおよびディレクティブ「ｎｏ−ｃａｃｈｅ」を与えなければならない。キャッシュが「ｎｏ−ｃａｃｈｅ」ディレクティブをオーバーライドし、フラグメントによって指定される規則を適用することが望まれる場合に、これらのフラグメントに、拡張ディレクティブ「ｆｒａｇｍｅｎｔｒｕｌｅｓ」を与えなければならない。本発明の好ましい実施形態のフラグメント・キャッシング技法を実施するキャッシュは、ＨＴＴＰ／１．１仕様に記載のＨＴＴＰ／１．１キャッシュ可能性規則による機能性も実施しなければならない。
【０１２６】
サーバによって無効化されるフラグメントが、データの複数のソースに依存する場合があり、複数のフラグメントが、同一のデータに依存する場合がある。キャッシュに単一の無効化オーダーを送信することによって、共通のデータに基づいてすべてのフラグメントを突き止めることによって複数のフラグメントを無効化できることが、非常に望ましい。これを効率的に行うために、サーバによって、１つまたは複数の無効化ＩＤがフラグメントに割り当てられる。実施するキャッシュによって、キャッシングされた項目への副インデクシングを提供するのに無効化ＩＤが使用される。サーバ開始無効化オーダーが到着する時に、無効化ＩＤの下でインデクシングされるすべてのキャッシングされた項目が、無効化される。無効化ＩＤは、ＦＲＡＧＭＥＮＴヘッダの「ｄｅｐｅｎｄｅｎｃｉｅｓ」ディレクティブを介して指定される。「ｄｅｐｅｎｄｅｎｃｉｅｓ」ディレクティブの例を示す。
fragment:dependencies="dep1 dep2"
【０１２７】
実施するサーバによって、サービスするホストがオブジェクトを明示的に無効化することを示すのに、「ｄｅｐｅｎｄｅｎｃｉｅｓ」ディレクティブが使用される。ＨＴＴＰ／１．１仕様で定義される通常のエージングおよびキャッシュ可能性は、このディレクティブによって影響されず、したがって、まれに無効化されるオブジェクトを、サーバ開始無効化なしにキャッシュから除去することができる。「ｄｅｐｅｎｄｅｎｃｉｅｓ」ヘッダが指定される場合に、キャッシュは、すべての「ｃａｃｈｅ−ｃｏｎｔｒｏｌ：ｎｏ−ｃａｃｈｅ」ヘッダを無視することができる。
【０１２８】
無効化ＩＤ、ＵＲＩ、およびキャッシュＩＤは、別々の役割を有する。これらのそれぞれを指定する別々の機構を設けることによって、解決が困難になる可能性があるアプリケーション設計の無用な衝突を避ける。
【０１２９】
ダイナミック・フラグメント・キャッシュ識別子
オブジェクトを、そのＵＲＩと異なる識別子の下でキャッシングすることが可能である。ＵＲＩ自体の内容に基づいて、キャッシュＩＤが形成される正確な形に制約を設けることも可能である。これは、ダイナミック・オブジェクトについて、ＵＲＩが、しばしば、一意のキャッシュＩＤの一部として使用してはならない照会パラメータを用いて形成されるからである。これらのパラメータが、キャッシングの前にＵＲＩから除去されない場合に、誤ったキャッシュ・ミスが発生する可能性があり、同一のオブジェクトの複数のコピーが複数のＩｄの下で保管される結果になる。
【０１３０】
この問題を避けるために、キャッシュＩＤを形成する規則の組を、ＵＲＩをキャッシュＩＤとして直接に使用することができないダイナミック・オブジェクトの応答ヘッダで配送しなければならない。各規則に、照会パラメータ名およびクッキー名のリストが含まれる。従来技術では、クッキーが、キャッシュＩＤの一部として使用されるのではなく、多くのアプリケーションで、要求を他の要求から一意にする情報が、クッキーの内部のデータである。したがって、クッキーの値を、キャッシュＩＤの一部として指定することができる。キャッシュＩＤの一部として使用されるクッキーのすべてが、名前／値対の形になっていなければならない。
【０１３１】
言い換えると、ＣＡＣＨＥＩＤディレクティブは、１つまたは複数のｒｕｌｅｓｅｔからなる。ｒｕｌｅｓｅｔは、１つまたは複数の規則からなる。規則は、文字列のリストからなり、各文字列は、要求ＵＲＩからの照会パラメータの名前または付随するクッキーの名前である。ＣＡＣＨＥＩＤディレクティブの例を示す。
fragment: cacheid="(p1 [p2], c4) (p3, c4 [c5]) URI"
【０１３２】
このディレクティブは、３つの規則すなわち、（ｐ１［ｐ２］，ｃ４）、（ｐ３，ｃ４［ｃ５］）、およびＵＲＩからなる。規則の「ｐ＿」項は、照会パラメータのパラメータであり、「ｃ＿」項は、クッキーのクッキー名である。
【０１３３】
キャッシュＩＤを作成するために、キャッシュは、フラグメントのＵＲＩのパス名部分から開始する。次に、ｒｕｌｅｌｉｓｔ内の各規則の適用を試みる。ｒｕｌｅｌｉｓｔ内のすべての規則を適用できる場合には、このアクションからの文字列が、キャッシュＩＤとして使用される。ｒｕｌｅｌｉｓｔ内の規則のいくつかを適用できない場合には、ｒｕｌｅｌｉｓｔがスキップされ、次のｒｕｌｅｌｉｓｔが適用され、以下同様である。任意選択でないすべての規則を適用できるｒｕｌｅｌｉｓｔが存在しない場合には、そのオブジェクトはキャッシングされない。そうでない場合には、成功裡に適用された最初のｒｕｌｅｓｅｔが、キャッシュＩＤの形成に使用される。
【０１３４】
角型括弧（「［」および「］」）で囲まれた規則は、可能な場合に適用されなければならない任意選択の規則であるが、任意選択規則の失敗は、ｒｕｌｅｌｉｓｔの失敗にはつながらない。オブジェクトにＣＡＣＨＥＩＤディレクティブが付随しない場合には、そのオブジェクトは、照会パラメータを含むそのフルＵＲＩの下でキャッシングされる。
【０１３５】
規則を適用するために、キャッシュによって、まず、起点ＵＲＩからすべての照会パラメータを除去することによって、基本キャッシュＩＤが形成される。ｐａｒｍｒｕｌｅを適用するために、キャッシュによって、ｐａｒｍｎａｍｅで指定された名前を有する照会パラメータが探される。その名前が存在する場合には、起点ＵＲＩからの対応する名前／値対が、基本キャッシュＩＤに付加されて、新しい基本キャッシュＩＤが形成される。この処理は、すべての規則が成功裡に適用されるまで継続される。任意選択でない規則を適用できない場合には、基本キャッシュＩＤが、その元々の状態に復元され、次のｒｕｌｅｌｉｓｔが適用される。ｃｏｏｋｉｅｒｕｌｅを適用するために、キャッシュによって、ｃｏｏｋｉｅｎａｍｅパラメータで指定された名前を有する名前／値対の形のクッキーが探される。それが存在する場合には、名前／値対を基本キャッシュＩＤに付加して、新しい基本キャッシュＩＤを形成する。この処理は、すべての規則が成功裡に適用されるまで継続される。任意選択でない規則を適用できない場合には、基本キャッシュＩＤが、その元々の状態に復元され、次のｒｕｌｅｌｉｓｔが適用される。ｒｕｌｅｌｉｓｔが文字列「ＵＲＩ」からなる場合には、応答のＵＲＩ全体が、キャッシュＩＤとして使用される。上で述べた例では、２つのｒｕｌｅｌｉｓｔの両方を成功裡に適用できない場合に、要求のＵＲＩ全体が使用される。
【０１３６】
オブジェクトに関する要求がキャッシュに到着する時に、キャッシュすなわちキャッシュ管理ユニットまたはキャッシュのメインテナ（ｍａｉｎｔａｉｎｅｒ）によって、まず、オブジェクトがそのフルＵＲＩの下でキャッシングされるかどうかが検査される。そうである場合には、オブジェクトが返されるが、そうでない場合には、基本キャッシュＩＤが、フラグメントのＵＲＩのパス部分から形成され、ルックアップがもう一度実行される。オブジェクトが見つからない場合には、キャッシュに関連する規則テーブルから、基本キャッシュＩＤが検索される。基本キャッシュＩＤが、キャッシュの規則テーブルに登録されている場合には、そのＵＲＩの規則が、上で説明したように適用される。ｒｕｌｅｌｉｓｔが成功裡に適用される場合に、オブジェクトが、新しいキャッシュＩＤの下でもう一度探される。これが見つからない場合には、キャッシュは、これをミスとみなし、要求をサーバに向かって転送するが、見つかる場合には、そのオブジェクトが要求元に返される。
【０１３７】
上で示した例を継続して、オブジェクトのフルＵＲＩが、
http://foo.bar.com/buyme?p1=parm1&p3=parm3
であり、応答が、名前「ｃ４」と値「ｃｏｏｋｉｅ４」を有する付随するクッキーを有すると仮定する。この場合に、キャッシュＩＤは、第１の規則すなわち「（ｐ１［ｐ２］，ｃ４）」が適用されるので、次の形になる。
http://foo.bar.com/buyme/p1=parm1/c4=cookie4
【０１３８】
複数のキャッシュを介するページ組立
図７から１３に関して、オブジェクト取出しパスに沿ったフラグメント・サポート式エージェントおよびフラグメント非サポート式エージェントの組が、本発明の好ましい実施形態のフラグメント・キャッシング技法をさまざまな処理環境で成功裡に実施できる形の議論の基礎として示されている。
【０１３９】
クライアント・ブラウザとサーバの間のパスに沿って複数のキャッシュがある時に、キャッシュの一部がページ組立のサポートを主張し、キャッシュの一部がページ組立のサポートを主張しない場合に、複雑な状況が生じる可能性がある。この問題は、イメージまたはマルチメディアなどの他のタイプの組込みオブジェクトについて生じるのではない。というのは、キャッシュおよびブラウザが、必ずこれらのオブジェクトを独立の関連しないオブジェクトとして扱うからである。ブラウザでのレンダリングの後でも、起点オブジェクトは、ブラウザのキャッシュ内で別個である。しかし、ページに、トップレベル・フラグメント「ｐ」および子フラグメント「ｃ」が含まれる場合に、「ｐ」のＵＲＩを使用する、オブジェクトに関する要求によって、ブラウザから始まり、宛先サーバで終わるエージェントのチェーンでのページ組立のサポートのレベルに応じて、フラグメント「ｐ」または完全に構成されたページ「Ｐ」のいずれかが返される可能性がある。
【０１４０】
図７から１３に、異なる機能を有するエージェントのさまざまな構成と、本発明の好ましい実施形態がこれらを処理する形を示す。各図で、第１のキャッシュ、キャッシュ１および第２のキャッシュ、キャッシュ２が、クライアント・ブラウザとサーバの間の位置を占める。この例では、「ｆ」によって、フラグメントをサポートするエージェントが示され、「ｎｆ」によって、フラグメントをサポートしないエージェントが指定され、「ｐ」によって、親フラグメントが指定され、「ｃ」によって、子フラグメントが指定され、「Ｐ（ｐ，ｃ）」によって、子フラグメント「ｃ」を親フラグメント「ｐ」に組み込むことによって構成されるページが指定される。
【０１４１】
図７に、最も単純な場合を示す。この例では、サーバが、フラグメントをサポートし、２つのキャッシュおよびブラウザは、フラグメントをサポートしてもしなくてもよい。子フラグメント「ｃ」を含むトップレベル・フラグメント「ｐ」がある。サーバは、「ｐ」および「ｃ」を別々に保管するが、これらが関連することを知っている。「ｐ」に関する特定の要求に関して、ブラウザとサーバの間のエージェント（任意の数のレベルの）がフラグメントをサポートする場合に、別々のフラグメントが返され、そうでない場合に、サーバは、フラグメントを組み立て、完全に組み立てられたページを返す。
【０１４２】
図８を参照すると、ブラウザはフラグメントをサポートするが、キャッシュ１およびキャッシュ２はサポートしない。ブラウザがｐ（およびｐの組立を試みた後にｃ）を要求した後に、各エージェントが、「ｐ」および「ｃ」のコピーをキャッシングしている。サーバは、ブラウザがフラグメントをサポートすることをブラウザが示したので、別々のフラグメントを返す。しかし、キャッシュ１およびキャッシュ２は、特にこのフラグメントがブラウザによって別々に要求されたので、２つの独立のＨＴＴＰオブジェクトをキャッシングしているかのように動作し、それでも、ブラウザおよびサーバは、「ｐ」および「ｃ」のコピーが関連することを知っている。ブラウザは、これらを、別々にキャッシングするが、必要な時に構成する。
【０１４３】
図９を参照すると、ブラウザは、フラグメントをサポートしないが、キャッシュ１およびキャッシュ２は、フラグメントをサポートする。この場合に、サーバは、キャッシュ２がフラグメント・サポートを示したので、別々のフラグメントを返す。キャッシュ２は、キャッシュ１がフラグメント・サポートを示したので、別々のフラグメントを返す。キャッシュ１は、ブラウザがフラグメント・サポートを示さなかったので、ブラウザに返す前に、「ｐ」フラグメントおよび「ｃ」フラグメントから最終的なページ「Ｐ（ｐ，ｃ）」を構成した。
【０１４４】
図１０を参照すると、ブラウザおよびキャッシュ２はフラグメントをサポートしないが、キャッシュ１はフラグメントをサポートする。サーバは、キャッシュ１がフラグメント・サポートを示し、その表示がＨＴＴＰヘッダ内でキャッシュ２を介して運ばれたので、別々のフラグメントを返した。キャッシュ２は、２つの独立のＨＴＴＰオブジェクトをキャッシングしているかのように働くが、ブラウザ、キャッシュ１、およびサーバは、別々のフラグメントが関連することを知っている。キャッシュ２は、フラグメントが別々に保管され、それらが関連することを知らないので、別々のフラグメントを渡した。キャッシュ１は、ブラウザがフラグメント・サポートを示さなかったので、フラグメント「ｐ」および「ｃ」を返す前に、これらから最終的なページ「Ｐ（ｐ，ｃ）」を構成した。
【０１４５】
図１１を参照すると、ブラウザおよびキャッシュ１は、フラグメントをサポートしないが、キャッシュ２はフラグメントをサポートする。サーバは、キャッシュ２がフラグメント・サポートを示したので、別々のフラグメントを返した。キャッシュ２は、ブラウザおよびキャッシュ１がフラグメント・サポートを示さなかったので、キャッシュ１に渡す前に、フラグメント「ｐ」および「ｃ」から最終的なページ「Ｐ（ｐ，ｃ）」を構成した。キャッシュ１およびブラウザは、構成されたフラグメントを、単一のＨＴＴＰオブジェクトすなわち最終的なページ「Ｐ（ｐ，ｃ）」として保管する。
【０１４６】
図１２を参照すると、単一のブラウザが、２つのブラウザ、ブラウザ１およびブラウザ２に置換されている。ブラウザ２が、親フラグメント「ｐ」にマッピングされるページを要求する。キャッシュ１は、ブラウザ２によって発行された「ｓｕｐｐｏｒｔｓ−ｆｒａｇｍｅｎｔｓ」ヘッダを担持する要求をキャッシュ２に転送する。キャッシュ２は、フラグメント「ｃ」のフラグメント・リンクと共にフラグメント「ｐ」をキャッシュ１に返し、キャッシュ１は、それをブラウザ２に返す。ブラウザ２は、フラグメント「ｐ」を構文解析し、子フラグメント「ｃ」の要求を発行する。
【０１４７】
潜在的な問題が生じるのは、フラグメント処理用にセット・アップされていないブラウザ１が、ページの要求を発行する場合である。ブラウザ１は、ブラウザ２によって発行されたものと同一のＵＲＩを含む要求を発行し、このＵＲＩは、フラグメント「ｐ」のキャッシュＩＤと一致する。キャッシュ１が、ｐフラグメントをキャッシングしている場合に、キャッシュ１は、フラグメント「ｃ」のＦＲＡＧＭＥＮＴＬＩＮＫタグを含むキャッシングされたフラグメントをブラウザ１に送信する。ブラウザ１は、ＦＲＡＧＭＥＮＴＬＩＮＫタグを理解しないので、これを無視し、これによって、不完全なページがレンダリングされることになる。
【０１４８】
この状況によって、フラグメントをサポートするエージェントと、フラグメントをサポートしないもう１つのエージェントの両方が、フラグメントをサポートしないキャッシュに接続される、図１３に全般的に示されたネットワーク内の構成が一般化される。ブラウザ２が、フラグメント「ｐ」を要求する場合に、フラグメントをサポートするキャッシュ１は、フラグメント「ｐ」および「ｃ」を受信し、それらを組み立て、その後、キャッシュ１は、ページ「Ｐ（ｐ，ｃ）」をブラウザ２に配信する。ブラウザ１からのキャッシュ１を介するフラグメント「ｐ」の後続の要求によって、組み立てられないページの配信がもたらされる可能性がある。
【０１４９】
この潜在的な問題を管理するために、ページ組立をサポートするサーバからのすべてのトップレベル・フラグメントによって、たとえば「Ｃａｃｈｅ−Ｃｏｎｔｒｏｌ：ｎｏ−ｃａｃｈｅ  ｆｒａｇｍｅｎｔｒｕｌｅｓ」を使用して、トップレベル・フラグメントをキャッシュ不能としてマークしなければならない。ページ組立をサポートするキャッシュは、このディレクティブの「ｆｒａｇｍｅｎｔｒｕｌｅｓ」を認識し、これによって、「ｎｏ−ｃａｃｈｅ」ディレクティブがオーバーライドされ、正しい挙動がオブジェクトに適用される。この状況を管理するために、トップレベル・フラグメントだけをキャッシュ不能としてマークしなければならないことに留意されたい。これは、ページ全体のＵＲＩがトップレベル・フラグメントのＵＲＩと同一なので生じる可能性がある曖昧さに起因する。すなわち、このＵＲＩによって、２つの異なるオブジェクトを参照することができる。組み込まれるフラグメントは、絶対に複数の形で存在せず、その結果、この曖昧さは、組み込まれるフラグメントについては発生しない。
【０１５０】
不適切なキャッシングの防止に関する考慮事項
真上で注記したように、ページ組立をサポートするサーバからのすべてのトップレベル・フラグメントは、キャッシュ不能としてトップレベル・フラグメントをマークしなければならない。これによって、フラグメントをサポートしないキャッシュが、他のフラグメントを含むトップレベル・フラグメントのキャッシングを試みるという潜在的な問題が防止されるが、これが試みられた場合には、図１３からわかるように、トップレベル・フラグメントに、フラグメント・サポート式キャッシュを含まないブラウザからのパスに沿ってアクセスでき、これによって、ＦＲＡＧＭＥＮＴＬＩＮＫタグによって指定されるコンテンツではなくＦＲＡＧＭＥＮＴＬＩＮＫタグを有するページが誤ってレンダリングされる。
【０１５１】
さらに、フラグメントをサポートしないキャッシュによって、通常は、キャッシュ・インデックス／キーとしてオブジェクトに関連するＵＲＩまたはＵＲＩパスが使用され、このオブジェクトが、キャッシュは知らないが、フラグメントである可能性がある。オブジェクトがフラグメントなので、フラグメントをサポートしないキャッシュ内のキャッシュＩＤとしてＵＲＩまたはＵＲＩパスだけを使用することが不適切になる可能性があり、フラグメント・サポート式キャッシュでは、キャッシュＩＤが、オブジェクトすなわちフラグメントに関連するフラグメント・キャッシング規則に従って形成される。言い換えると、フラグメントをサポートしないキャッシュは、すべてのキャッシングされるオブジェクトに関するそのキャッシュＩＤアルゴリズムに従ってキャッシュ・インデックスを定式化し続けるが、本発明の好ましい実施形態の技法では、フラグメント・キャッシング規則が使用されて、キャッシュ内のフラグメントの配置に関するキャッシュ・インデックスを生成する前に、キャッシュ可能フラグメントのキャッシュＩＤが形成されることが意図されている。したがって、フラグメントをサポートしないキャッシュは、おそらくは、そのオブジェクトを返すことができるが、これは、実際には、キャッシュ・ヒットの結果としての応答内のフラグメントである。さまざまなタイプの不正確さまたはレンダリング・エラーが、下流で発生する可能性がある。そのようなエラーを避けるために、不適切な時にはキャッシングを防がなければならない。
【０１５２】
一般に、フラグメント非サポート式キャッシュでのキャッシングは、「Ｃａｃｈｅ−Ｃｏｎｔｒｏｌ：ｎｏ−ｃａｃｈｅ  ｆｒａｇｍｅｎｔｒｕｌｅｓ」ヘッダを含めることと、「Ｐｒａｇｍａ：ｎｏ−ｃａｃｈｅ」ヘッダを含めることによって防ぐことができる。第２のヘッダによって、ＨＴＴＰ／１．１をサポートしないキャッシュに、フラグメントをキャッシュしないように指示するが、フラグメントをサポートするキャッシュは、ＨＴＴＰ／１．１もサポートする。上で短く注記したように、図１３に関して、第１のヘッダの「ｎｏ−ｃａｃｈｅ」ディレクティブによって、ＨＴＴＰ／１．１をサポートするがフラグメントをサポートしないキャッシュに、フラグメントをキャッシュしないことが指示され、「ｆｒａｇｍｅｎｔｒｕｌｅｓ」ディレクティブによって、フラグメントをサポートするキャッシュに、フラグメント・キャッシング規則の下でフラグメントをキャッシングしなければならないことが指示される。
【０１５３】
効率的なキャッシングに関する考慮事項
複数のユーザにまたがって共用される、製品記述または株式相場などのフラグメントについて、ブラウザとウェブ・アプリケーション・サーバの間のほとんどまたはすべてのキャッシュでのキャッシングを可能にすることが、最も効率的である。フラグメントは、各キャッシュが他のキャッシュにファン・アウトするツリー構造に沿って分散されるとみなすことができる。特定のフラグメントに関する第１要求によって、ユーザとウェブ・アプリケーション・サーバの間のパスに沿ってキャッシュが移植される。他のユーザによる同一フラグメントに関する後続要求によって、これらのキャッシュ内のフラグメントが見つかり、ウェブ・アプリケーション・サーバまでゆく必要がなくなる可能性がある。
【０１５４】
株式ウォッチリストなど、たとえばパーソナライズされたフラグメントであるユーザ固有のフラグメントについて、同一フラグメントに関する後続要求だけが、同一のパスに沿ったものになるので、エンド・ユーザに最も近いフラグメント・サポート式キャッシュでのみキャッシングを許可することが、最も効率的である。そうでなければ、これらのユーザ固有フラグメントに関する後続要求が、ユーザにより近いキャッシュによって満足されるのでその後続要求が絶対に中間キャッシュによって見られない場合であっても、中間キャッシュにユーザ固有フラグメントが充てんされ、これによって、共用フラグメントが中間キャッシュから消去される。
【０１５５】
「ｐｒｉｖａｔｅ」ディレクティブを有するＨＴＴＰ「Ｃａｃｈｅ−Ｃｏｎｔｒｏｌ」ヘッダは、以前に、ページのこの同一のユーザ固有特性を指定するのに使用され、その結果、ブラウザ・キャッシュだけがこれらをキャッシングするようになる。これと同一のヘッダが、本発明の好ましい実施形態によって、フラグメント・サポート式キャッシュに、ユーザに最も近いフラグメント・サポート式キャッシュ内でコンテンツをキャッシングするように指示するのに使用される。ユーザ固有フラグメントに「Ｃａｃｈｅ−Ｃｏｎｔｒｏｌ：ｐｒｉｖａｔｅ」を含めることが、最適の性能最適化であることに留意されたい。
【０１５６】
複合文書に関する考慮事項
フラグメント組立のためにフラグメントをフェッチする時には、ＨＴＴＰ要求を形成しなければならない。この応答のヘッダのほとんどを、トップレベル・フラグメントの応答ヘッダから継承することができる。しかし、一部の応答ヘッダによって、フェッチされる特定のオブジェクトが参照され、親フラグメントからこれらを継承する時には、注意が必要である。同様に、ほとんどの応答ヘッダを、破棄することができ、トップレベル・フラグメントに付随する応答ヘッダを、クライアントに応答を返す時に使用することができる。やはり、一部の応答ヘッダは、個々のオブジェクトに固有であり、文書全体の状態に影響する場合がある。
【０１５７】
このセクションでは、フラグメント組立でのＨＴＴＰ要求／応答ヘッダの処理に関する問題を論ずる。用語「下流伝搬」は、組込みオブジェクトに関する要求による、親またはトップレベル・フラグメントからの要求ヘッダの継承を指すのに使用される。用語「上流伝搬」は、組込みオブジェクトから親またはトップレベル・フラグメントへの応答ヘッダの解決を指すのに使用される。
【０１５８】
クッキーに関する複合文書に関する特殊な問題の１つが、ページ組立中に、元々の「ｓｅｔ−ｃｏｏｋｉｅ」応答ヘッダが使用不能になることである。結果のクッキー要求ヘッダだけが、クライアントから使用可能である。具体的に言うと、実際の「ｐａｔｈ」値、「ｄｏｍａｉｎ」値、および「ｅｘｐｉｒｅｓ」値のどれもが、使用不能である。入れ子のより浅いレベルのフラグメントによって、要求に伴うクッキーに課せられる制約を満たさない別のフラグメントが組み込まれる場合に、そのクッキーを子フラグメントに渡すことは、正しくない。元々の情報すべてが存在するのではないので、一般に、クッキーを渡すことが正しいかどうかを判定することは不可能である。同様に、入れ子になったフラグメントが、付随する「ｓｅｔ−ｃｏｏｋｉｅ」ヘッダを有する場合がある。そのクッキーの実際の値が、そのフラグメントのキャッシュＩＤの計算に必要になる可能性がある。さらに、クッキーの値が、入れ子のより深いレベルのフラグメントのフェッチに必要になる場合がある。しかし、そのような情報は、推論することができる。クッキーの「ｅｘｐｉｒｅｓ」部分が、まだ有効になっていないと仮定することができる。既に有効である場合には、クッキーは、要求に存在しない。ドメインが、要求内のドメインのある部分であると仮定することができ、パスが、要求内のパスのある部分であると仮定することができる。
【０１５９】
通常、ブラウザは、クッキーに対する制約を検査し、要求がその制約を満足しない場合には、そのクッキーは要求ヘッダに含まれない。しかし、ページを組み立てるキャッシュでは、付随するクッキーを有する文書に含まれるＦＲＡＧＭＥＮＴＬＩＮＫタグによって、元のクッキーの制約を満足しないＵＲＩが参照されることがありえる。ＦＲＡＧＭＥＮＴＬＩＮＫタグで参照されるオブジェクトは、親のクッキーが正しく評価されることを必要とするので、クッキーを、入れ子の浅いレベルのフラグメントから入れ子の深いレベルのフラグメントに伝搬させなければならない。ページ・アセンブラが、クッキーに対する制約を侵害する不正な形でクッキーを渡さないことを保証するためのガイドラインは、入れ子になったフラグメントのＵＲＩのパスおよびドメインが、トップレベル・フラグメントのパスおよびドメインの最も保守的な部分であることである。言い換えると、入れ子になたフラグメントのＵＲＩのドメインは、その親のドメインと一致するかそのスーパーセットでなければならず、ＵＲＩのパス部分は、その親のパスと一致するかそのスーパーセットでなければならない。これを、「クッキーの下流伝搬」と呼ぶことができる。
【０１６０】
対照的に、下記によって「クッキーの上流伝搬」が説明される。フラグメントがホストからフェッチされる時に、応答に「ｓｅｔ−ｃｏｏｋｉｅ」ヘッダが含まれることがありえる。このクッキー自体は、新たに返されるフラグメント内の入れ子のより深いレベルのフラグメントの正しい評価に必要である場合がある。したがって、ページ・アセンブラは、「ｓｅｔ−ｃｏｏｋｉｅ」ヘッダを、入れ子のより深いレベルのフラグメントのフェッチにおいて、「ｃｏｏｋｉｅ」ヘッダに変換しなければならない。この新しいクッキーは、少なくとも２つの理由すなわち、（１）サーバでの入れ子のより深いレベルのフラグメントの評価、および（２）最近にフェッチされたフラグメントまたはより深い入れ子になったフラグメントのキャッシュＩＤの生成に必要になる場合がある。クッキーがキャッシュＩＤ生成に必要な場合には、新しいクッキーを、組み立てられたページと共に要求元に送り返す必要がある。これは、そのクッキーが、そのページの次の要求に付随しなければならないから、または、キャッシングされたフラグメントを参照するページについて、サーバからのフェッチを試みる前に要求からキャッシュＩＤを計算するためである。
【０１６１】
入れ子になったフラグメントに関する要求の「ｓｅｔ−ｃｏｏｋｉｅ」ヘッダのクッキーを「ｃｏｏｋｉｅ」ヘッダに変換することによって、ユーザの代わりにクッキーを暗黙の内に受け入れる動作が構成される。この状況を扱うガイドラインには、（１）トップ・レベル・フラグメントが、既にその名前のクッキーを有しなければならず、（２）フラグメントのパスおよびドメインが、トップレベル・フラグメントのパスおよびドメインの最も保守的な部分に従わなければならないことが含まれる。
【０１６２】
これらの制約が満たされる場合に、新しい「ｓｅｔ−ｃｏｏｋｉｅ」ヘッダの効果は、単純に、既存のクッキーの値を変更することになる。アプリケーションの観点からは、これが、単純に、トップレベル・フラグメントに「ダミー」クッキーを付随させる必要が生じる可能性があることを意味する。これらの「ダミー」クッキーは、入れ子になったフラグメントのフェッチの処理中に、およびそのフラグメントの「ｓｅｔ−ｃｏｏｋｉｅ」ヘッダがユーザに伝搬される時に、値を更新される。
【０１６３】
複合文書に関するクッキー以外のもう１つの特別な考慮事項に、「ｉｆ−ｍｏｄｉｆｉｅｄ−ｓｉｎｃｅ」ヘッダが含まれる。「ｉｆ−ｍｏｄｉｆｉｅｄ−ｓｉｎｃｅ」ヘッダは、要求元によって、指定される日時以降にオブジェクトが変更されている場合に限ってオブジェクトを返さなければならないことを指定するのに使用される。オブジェクトが、その時以降に修正されていない場合には、オブジェクトが「新鮮」であると考えられ、通常はＨＴＴＰ  ３０４「Ｎｏｔ  Ｍｏｄｉｆｉｅｄ」応答がサーバから返され、これによって、より大きい応答本体を配送するのに必要な帯域幅が節約される。
【０１６４】
複合文書では、コンポーネントの一部が「新鮮」であるが他のコンポーネントが「古い」場合があり、他のコンポーネントの状況が、不確定である場合がある。コンポーネントのどれかを「新鮮」と判定できない場合には、文書全体を、完全な応答として返さなければならない（ＨＴＴＰ  ２００）。すべてのコンポーネントが「新鮮」と判定される場合には、ＨＴＴＰ  ３０４応答を返すことができる。しかし、フラグメントが新鮮であるかどうかを判定するために、コンポーネントのＨＴＴＰ応答コードに注意しながらページ組立を実行する必要がある場合がある。あるコンポーネントが「新鮮」である場合で、そのコンポーネントが葉ノードでない場合に、そのコンポーネントの内容が、入れ子になったコンポーネントを見つけ、フェッチするために必要である。
【０１６５】
したがって、ＨＴＴＰ  ３０４応答を返すキャッシュへの要求によって、ページ組立を継続できるようにするために、フラグメントのテキストも返さなければならない。たとえばキャッシュ・ミスの結果などのサーバへの要求は、「ｉｆ−ｍｏｄｉｆｉｅｄ−ｓｉｎｃｅ」ヘッダなしで発行しなければならない。というのは、そうでなければ、ページ組立を継続するのにフラグメントのテキストが必要である時に、サーバがＨＴＴＰ  ３０４応答を返す可能性があるからである。言い換えると、ＨＴＴＰ  ３０４応答によってクライアントへの無効な応答がもたらされる可能性があるので、複合文書に関する「ｉｆ−ｍｏｄｉｆｉｅｄ−ｓｉｎｃｅ」ヘッダを下流に伝搬させることはできない。
【０１６６】
複合文書に関するもう１つの特別な考慮事項は、「ｉｆ−ｍｏｄｉｆｉｅｄ−ｓｉｎｃｅ」ヘッダに関連する問題に似ているが、「ｌａｓｔ−ｍｏｄｉｆｉｅｄ」ヘッダに関する。ページ・アセンブラは、どのフラグメントが「ｌａｓｔ−ｍｏｄｉｆｉｅｄ」ヘッダを返したかを理解し、その結果を、構成されたページの最新の日付を有する１つの組み合わされた「ｌａｓｔ−ｍｏｄｉｆｉｅｄ」ヘッダにマージしなければならない。フラグメントのいずれかが「ｌａｓｔ−ｍｏｄｉｆｉｅｄ」ヘッダを返さない場合には、組み立てられたページ全体が、「ｌａｓｔ−ｍｏｄｉｆｉｅｄ」ヘッダを返さないことが必要である。これが重要であるのは、「ｌａｓｔ−ｍｏｄｉｆｉｅｄ」ヘッダがローカル・キャッシュのファイルと同一であることが通知される場合に、ブラウザが内容を無視するからである。
【０１６７】
たとえば、１つのダイナミック・コンテンツ（「ｌａｓｔ−ｍｏｄｉｆｉｅｄ」ヘッダなし）と「ｌａｓｔ−ｍｏｄｉｆｉｅｄ」ヘッダ付きの１つの静的コンテンツ（ＨＴＭＬからの）を含むページを検討されたい。このページを静的ページの「ｌａｓｔ−ｍｏｄｉｆｉｅｄ」ヘッダ付きで返した場合に、同一のページへの後続要求が、ブラウザによって無視され、ブラウザ・キャッシュからの古いページが表示される。言い換えると、すべてのフラグメントに「ｌａｓｔ−ｍｏｄｉｆｉｅｄ」ヘッダが含まれる場合に、それを上流に伝搬させ、すべての構成フラグメントの最も最近の修正時刻を反映するように調整しなければならない。フラグメントのいずれかに「ｌａｓｔ−ｍｏｄｉｆｉｅｄ」ヘッダが欠けている場合には、「ｌａｓｔ−ｍｏｄｉｆｉｅｄ」ヘッダを返してはならない。
【０１６８】
プログラミング・モデルに関する考慮事項
本発明の好ましい実施形態によって、分散フラグメント・キャッシングの技法が説明される。しかし、すべてのウェブ・アプリケーション・サーバ・プログラミングによってこれを使用して、たとえば中間のサーバおよびブラウザに、キャッシング機能を委譲できるようにするために、できる限り中立であることが意図されている。本発明の好ましい実施形態では、やはりプログラミング・モデル中立である、ＨＴＭＬに対する拡張すなわちＦＲＡＧＭＥＮＴＬＩＮＫタグと、ＨＴＴＰに対する拡張すなわち新しいフラグメント・キャッシング・ヘッダが使用される。
【０１６９】
フラグメントをプログラミングする時に、ウェブ・アプリケーション開発者は、下記の２タイプの情報を指定しなければならない。
１．インクルード機構。これによって、どのフラグメントを含めるかと、別のフラグメントのどこに含めるかが指定される。ページ上の位置が重要なので、これは、コード、たとえばＪＳＰテンプレートまたはサーブレットクラスに組み込まれなければならない。
２．キャッシング制御メタデータ。これによって、たとえばタイム・リミットなど、フラグメントの条件が指定される。この情報は、コードに組み込むか、たとえばＪＳＰファイル名またはサーブレット・クラスなど、テンプレート名に関連付けることによって別々に指定することができる。
【０１７０】
本発明の好ましい実施形態を実施するのにＪ２ＥＥプログラミング・モデルが使用される場合に、この２つの特徴を、下記の機構によってサポートすることができる。
１．インクルード機構に関して、Ｊ２ＥＥプログラミング・モデルは、既に、たとえば「ｊｓｐ：ｉｎｃｌｕｄｅ」タグまたは「ＲｅｑｕｅｓｔＤｉｓｐａｔｃｈｅｒ．ｉｎｃｌｕｄｅ」メソッドなど、インクルードされるフラグメントを指定するための、ウェブ・アプリケーション・サーバ内のインクルード構造を有する。適当な時に、Ｊ２ＥＥランタイムを修正して、Ｊ２ＥＥインクルード構造をＦＲＡＧＭＥＮＴＬＩＮＫタグに書き直すことができる。
２．キャッシング制御情報を、システム管理コンソールから指定することができ、コードに組み込むのではなく、各フラグメントのテンプレート／クラスに関連付けることができる。ウェブ・アプリケーション・サーバによって、この情報を適当なヘッダに挿入することができる。この手法は、この情報をコードに入れることに対して、下記の長所を有する。
Ａ．これによって、コードに焼き込まれるのでプログラマをかかわらせるのではなく、管理コンソールを介して動的に変更を行えるようになる。
Ｂ．これによって、Ｊ２ＥＥプログラミング・モデルに新しい機構が組み込まれなくなる。
【０１７１】
Ｊ２ＥＥインクルード構造のＦＲＡＧＭＥＮＴＬＩＮＫタグへの書き直しは、下記の考慮事項を必要とする。照会パラメータに関するＪ２ＥＥセマンティクスでは、すべての照会パラメータが親フラグメントから子フラグメントに再帰的に渡されることが要求される。Ｊ２ＥＥウェブ・アプリケーション・サーバが、ＦＲＡＧＭＥＮＴＬＩＮＫタグを生成する時に、ＳＲＣ属性を、親の照会パラメータを付加されたＪ２ＥＥインクルードのＵＲＩにしなければならない。非Ｊ２ＥＥウェブ・アプリケーション・サーバは、そのプログラミング・モデルと整合するＳＲＣ属性を生成する。この形で、アプリケーション・コードが見る要求がどちらの場合でも同一になるので、代理が存在するか否かに無関係に、同一のセマンティクスが発生する。ＦＲＡＧＭＥＮＴＬＩＮＫタグは、たとえばＡＬＴ、ＦＯＲＥＡＣＨ、ＳＨＯＷＬＩＮＫ、ＩＤ、およびＣＬＡＳＳなど、対応する「ｊｓｐ：ｉｎｃｌｕｄｅ」属性を有しない複数の属性を有する。Ｊ２ＥＥ環境で使用されるために、これらの特徴は、「ｊｓｐ：ｉｎｃｌｕｄｅ」に対する拡張を必要とする。
【０１７２】
異なるウェブ・アプリケーション・サーバが、入れ子になったフラグメントをインクルードする、類似するが異なる機構を有する他のプログラミング・モデル（たとえばＡＳＰ）をサポートすることができる。これらのプログラミング・モデルのそれぞれについて、ウェブ・アプリケーション・サーバは、そのプログラミング・モデルの規則と整合するＦＲＡＧＭＥＮＴＬＩＮＫタグを生成しなければならない。
【０１７３】
無効化に関する考慮事項
キャッシュを最新状態に保つために、内容がもはや有効でなくなった時に、項目を無効化するか上書きする必要がある。無効化は、時間に基づくか、外部イベントによってトリガされるかのいずれかとすることができる。時間は、キャッシュ内の最大寿命、たとえば１０分以内か、絶対時刻、たとえば２００１年２月５日正午までのいずれかとすることができる。最大寿命は、標準ＨＴＴＰ「Ｃａｃｈｅ−Ｃｏｎｔｒｏｌ」ヘッダとＨＴＴＰ「ｍａｘ−ａｇｅ」ディレクティブを使用して指定される。絶対時刻は、標準ＨＴＴＰ「Ｅｘｐｉｒｅｓ」ヘッダを使用して指定される。
【０１７４】
例として、製品の説明を古くなるのに１０分までとすることが許容可能であろう。これは、「Ｃａｃｈｅ−Ｃｏｎｔｒｏｌ：ｍａｘ−ａｇｅ＝６００」として指定され、これは、このフラグメントが６００秒までキャッシュに留まることを意味する。もう１つの例として、セールを、２００１年１２月２４日月曜日東部標準時午後１１時００分まで続けることができる。これは、「Ｅｘｐｉｒｅｓ＝Ｍｏｎ，  ２４  Ｄｅｃ  ２００１  ２３：００：００  ＥＳＴ」として指定される。どちらの場合でも、フラグメントを、新しいフラグメントための余地を作るために、キャッシュの置換アルゴリズムによってキャッシュから除去することができる。
【０１７５】
イベントによってトリガされる無効化について、アプリケーション・サーバによって、無効化が開始される。アプリケーション・サーバは、データベース・トリガ、更新するＨＴＴＰ要求によって呼び出されるアプリケーション・プログラミング・インターフェース（ＡＰＩ）、またはコンテンツが古くなったことを判定する他の機構を使用することができる。
【０１７６】
本発明の好ましい実施形態の技法は、さまざまな無効化技法に対して開かれている。同様に、フラグメント・サポート式キャッシュに無効化メッセージを送信するのにアプリケーション・サーバによって使用されるプロトコルは、本発明の好ましい実施形態の技法によって指定されない。
【０１７７】
フラグメントの依存性は、フラグメントを作成するのに使用された基礎になるデータの識別子である。依存性の例として、複数のページによって、同一の基礎になるユーザ・プロファイルが使用されるが、そのユーザ・プロファイルの異なるサブセットが使用されるので、またはそれらが異なる形でフォーマットされるので、異なるフラグメントが使用される場合がある。アプリケーションは、ユーザ・プロファイルと、それを使用するフラグメントのすべてとの間のマッピングを判定し、ユーザ・プロファイルが変更された時に、必ずこれらのキャッシュＩＤを構築することができる。しかし、このマッピングを、各依存性のソースであるフラグメントのそれぞれの中で突き止めさせることが、よりよいソフトウェア・エンジニアリングである。これによって、アプリケーションが、ユーザ・プロファイルに関連するユーザＩＤを使用して単純に無効化でき、キャッシュに、そのユーザＩＤに依存するすべてのフラグメントを無効化させることができるようになる。ユーザ・プロファイルを使用する新しいフラグメントが追加されるか、ユーザ・プロファイルを使用するフラグメントが除去される時には、依存性が、そのフラグメントにローカルであり、アプリケーションの無効化機構は変更されない。たとえば、この依存性を、下記の形で特定のユーザ・プロファイルについて宣言することができる。
Fragment:dependencies="http://www.acmeStore.com_userID=@($*!%"
【０１７８】
複数の依存性は、スペースによって区切られたリストとして指定される。依存性は、大文字小文字の区別がある。フラグメント・サポート式キャッシュを用いると、これらの依存性に基づいて無効化を行えるようになる。
【０１７９】
キャッシュ項目を無効化するための上書き手法を使用するためには、新しヘッダ情報は不要である。フラグメント・サポート式キャッシュは、新しいキャッシュ項目を追加できるようにするプロトコルを必要とする。上で述べた無効化プロトコルと同様に、この上書きプロトコルは、本発明の好ましい実施形態の教示によって指定されない。
【０１８０】
セキュリティ問題に関する考慮点
潜在的なセキュリティ要件が、フラグメントをサポートするキャッシュによって尊重されなければならない。ユーザが、ブラウザのようなアプリケーションを操作し、ＵＲＩをクリックする時に、ユーザは、使用されるＵＲＩまたはユーザのクッキーで供給されるすべての情報が、アプリケーションのセキュリティ・ポリシに従って扱われるものとしてアプリケーション設計者を信頼する。ＦＲＡＧＭＥＮＴＬＩＮＫタグを用いて、アプリケーション設計者は、この情報の正しい使用の責任の一部をキャッシュに委譲する。本発明の好ましい実施形態に従って実施されるキャッシュによって、ＦＲＡＧＭＥＮＴＬＩＮＫタグをその親以外のドメインにリンクできないという規則が実施されなければならない。
【０１８１】
他のフラグメントを含むページは、最終的に、完全に展開されたページに組み立てられ、これは、ブラウザとアプリケーション・サーバの間のパスに沿ったどの場所でも行われる可能性がある。セキュリティを保証するために、アプリケーション設計者は、次の規則を厳守しなければならない：フラグメントにＨＴＴＰＳを必要とする別のフラグメントが含まれる場合に、そのフラグメントはＨＴＴＰＳを必要とする。この規則は、再帰的に適用されなければならず、その結果、トップレベル・フラグメントまでのすべてに伝搬される。この規則によって、保護されたフラグメントが、保護されないフラグメントの内部で見られることがなくなる。
【０１８２】
ＨＴＴＰＳ要求に関して、「ｓｕｐｐｏｒｔｓ−ｆｒａｇｍｅｎｔｓ」ディレクティブを含むＦＲＡＧＭＥＮＴヘッダは、キャッシュがＨＴＴＰＳセッションを終了できる場合に限って含まれなければならない。そうでなければ、ＨＴＴＰＳセッションを処理するためにＦＲＡＧＭＥＮＴＬＩＮＫを見ることができない。ＨＴＴＰＳを終了させないキャッシュは、それでも、ＨＴＴＰ要求のフラグメントをサポートすることができる。
【０１８３】
フラグメント・サポート式キャッシュに関するキャッシュ管理ユニットの説明
図１４に関して、ブロック図によって、本発明の好ましい実施形態によるコンピューティング・デバイス内のフラグメント・サポート式キャッシュのキャッシュ管理ユニットを示す。コンピューティング・デバイス６００は、クライアント、サーバ、またはおそらくはクライアント機能とサーバ機能の両方を有するものとすることができるが、コンピューティング・デバイス６００には、フラグメント・サポート式キャッシュ管理ユニット６０２が含まれ、このキャッシュ管理ユニット６０２には、コンピューティング・デバイス６００の代わりにオブジェクトをキャッシングする機能性が含まれる。たとえば、キャッシュ管理ユニット６０２は、他のキャッシュ対応デバイスの間のデータ・パス上の中間キャッシュとして働くことができ、他の場合に、キャッシュ管理ユニット６０２は、エンドユーザの代わりにクライアント・デバイス内のオブジェクトをキャッシングすることができる。
【０１８４】
フラグメント・サポート式キャッシュ管理ユニット６０２に、オブジェクトを保管／キャッシングするオブジェクト・データベース６０４が含まれ、オブジェクト・データベース６０４に、オブジェクトに関連するメタデータおよびオブジェクトと共に受信されたネットワーク・ヘッダを含めることができる。フラグメント・サポート式キャッシュ管理ユニット６０２には、キャッシュ管理動作に関連する情報を保管するデータベースも含まれ、このデータベースは、ここで言及するが、下で図１５から１７に関して詳細に説明する。ｒｕｌｅｌｉｓｔデータベース６０６に、ＵＲＩパス６０８およびそれに関連するｒｕｌｅｌｉｓｔ６１０が保管される。キャッシュＩＤデータベース６１２に、キャッシュＩＤ６１４およびそれに関連するキャッシュ・インデックス６１６が保管される。依存性データベース６１８に、依存ＩＤとキャッシュＩＤの間のマッピングが保管される。複数のキャッシュＩＤを、単一の依存性に関連付けることができ、複数の依存性を、単一のキャッシュＩＤに関連付けることができる。
【０１８５】
フラグメント・サポート式キャッシュのキャッシュ管理ユニット内の処理の一部の説明
図１５に関して、流れ図によって、本発明の好ましい実施形態による、フラグメントを含む応答メッセージを処理する時にフラグメント・サポート式キャッシュ管理ユニットによって使用することができる処理を示す。言い換えると、図１５には、応答メッセージ内のオブジェクトをフラグメント・サポート式キャッシュで処理するかキャッシングするかその両方を行わなければならないかどうかと、その方法を判定するのに使用することができる処理が示されている。
【０１８６】
この処理は、図１４に示されたものなどの、フラグメント・サポート式キャッシュ管理ユニットを含むコンピューティング・デバイスによって、ＨＴＴＰ応答メッセージなどの応答メッセージが受信される時に開始される（ステップ６００２）。その後、キャッシュ管理ユニットが、メッセージ本体または応答メッセージ内のペイロード部分を、フラグメントまたは非フラグメントのどちらとして処理しなければならないかに関する判定を行う（ステップ６００４）。
【０１８７】
応答メッセージを、非フラグメントを含むものとして処理しなければならない場合に、非フラグメント・オブジェクトを、このコンピューティング・デバイスでキャッシングしなければならず、キャッシングできるか否か、すなわち、キャッシュ管理ユニットによってキャッシングするか否かに関する判定を（ステップ６００６）、既存のＨＴＴＰ１．１規則を使用して行う。たとえば、非フラグメント・オブジェクトを含む応答メッセージが、それをキャッシングしてはならないことの表示を有する場合がある、すなわち、ＨＴＴＰ応答メッセージ内で、「Ｃａｃｈｅ−Ｃｏｎｔｒｏｌ」ヘッダが「ｎｏ−ｃａｃｈｅ」ディレクティブを有する場合がある。オブジェクトをキャッシングしなければならず、それをキャッシングすることが可能である場合には、そのオブジェクトが、キャッシュ管理ユニットによって適当に保管される（ステップ６００８）。どちらの場合でも、そのオブジェクトに関するキャッシング動作が完了し、この処理は、分岐して、応答メッセージに関する他の動作を完了する。
【０１８８】
応答メッセージを、フラグメントを含むものとして処理しなければならない場合に、フラグメントがキャッシュ可能であるかどうかに関する判定を行う（ステップ６０１０）。そうでない場合には、この処理は、分岐して、応答メッセージに関する他の動作を完了する。フラグメントがキャッシュ可能である場合には、この特定のフラグメントをこの特定のコンピューティング・デバイスのキャッシュにキャッシングしなければならないかどうかに関する判定を行う（ステップ６０１２）。そうでない場合には、この処理は、分岐して、応答メッセージに関する他の動作を完了する。現在処理されつつあるフラグメントを、現在のコンピューティング・デバイスでキャッシングしなければならない場合には、そのフラグメントが、キャッシュ管理ユニットによってコンピューティング・デバイスのキャッシュに保管される（ステップ６０１４）。
【０１８９】
フラグメントがキャッシングされたか、現在のコンピューティング・デバイスでキャッシングされないと判定されたか、キャッシュ不能と判定された場合のどれであっても、次に、応答メッセージを転送する前に、フラグメントについてページ組立が必要であるかどうかに関する判定を行う（ステップ６０１６）。ページ組立が必要である場合には、ページ組立を実行する（ステップ６０１８）。どちらの場合でも、応答メッセージからのフラグメント・オブジェクトまたは非フラグメント・オブジェクトが、現在のコンピューティング・デバイスのキャッシュ管理ユニットによって完全に処理されており、応答メッセージが、必要な場合に修正され、その宛先に向かって転送され（ステップ６０２０）、これによってこの処理が完了する。
【０１９０】
図１６に関して、流れ図ステップによって、メッセージ本体にフラグメント・オブジェクトが含まれるか否かを判定する好ましい方法を示す。図１６は、図１５のステップ６００４と置換することができるステップを表す。好ましい実施形態では、受信された応答メッセージに、ペイロードまたはメッセージ本体をフラグメントとして識別するメッセージ／プロトコル・ヘッダが含まれるか否かが判定される（ステップ６０２２）。具体的に言うと、図６に示されているように、ＦＲＡＧＭＥＮＴヘッダをＨＴＴＰメッセージ内に配置して、メッセージのペイロードにフラグメント・オブジェクトが含まれることを示すことができる。
【０１９１】
図１７に関して、流れ図ステップによって、フラグメント・オブジェクトがキャッシュ可能であるか否かを判定するより具体的な方法を示す。図１７は、図１５のステップ６０１０と置換することができるステップを表す。この実施形態では、受信した応答メッセージに、フラグメントをキャッシュ可能として識別するキャッシュ制御用のプロトコル・ヘッダのディレクティブが含まれるか否かが判定される（ステップ６０２４）。
【０１９２】
図１８に関して、流れ図ステップによって、フラグメント・オブジェクトがキャッシュ可能であるか否かを判定する好ましい方法を示す。図１７に類似する形で、図１８は、図１５のステップ６０１０と置換することができるステップを表す。好ましい実施形態では、受信した応答メッセージが、フラグメント・サポート式キャッシュでキャッシュ可能として、およびフラグメント非サポート式キャッシュでキャッシュ不能としてフラグメントを識別するメッセージ／プロトコル・ヘッダのディレクティブを有するか否かが判定される（ステップ６０２６）。具体的には、上で説明したように、「Ｃａｃｈｅ−Ｃｏｎｔｒｏｌ」ヘッダを、ＨＴＴＰメッセージに含めることができ、オブジェクトのキャッシングを防ぐために「Ｃａｃｈｅ−Ｃｏｎｔｒｏｌ」ヘッダに「ｎｏ−ｃａｃｈｅ」ディレクティブを配置することが、標準的な実践であり、本発明の好ましい実施形態では、フラグメント非サポート式キャッシュについてこの実践が維持されるが、「Ｃａｃｈｅ−Ｃｏｎｔｒｏｌ」ヘッダの使用を拡張することよって、メッセージ内のフラグメントがフラグメント・キャッシング規則に従ってキャッシュ可能であることを示す「ｆｒａｇｍｅｎｔｒｕｌｅｓ」ディレクティブが含まれる。
【０１９３】
図１９に関して、流れ図によって、フラグメント・オブジェクトを特定のコンピューティング・デバイスのキャッシュでキャッシングしなければならないか否かを判定する方法を示す。図１９には、図１５のステップ６０１２および６０１４と置換することができる処理が示されており、この処理が呼び出される時に、応答メッセージにキャッシュ・フラグメントが含まれることが既に判定されている。
【０１９４】
この処理は、下流デバイスがフラグメント・サポート式キャッシュを有するか否かを判定することによって開始される（ステップ６０２８）。下流デバイスは、現在のコンピューティング・デバイスが応答メッセージを転送するコンピューティング・デバイスである。下流デバイスが、フラグメント・サポート式キャッシュを有しない場合には、現在のコンピューティングのキャッシュ管理ユニットが、現在処理されつつあるフラグメント・オブジェクトをキャッシングし（ステップ６０３０）、処理が完了する。
【０１９５】
下流デバイスが、フラグメント・サポート式キャッシュを有する場合には、現在処理されつつあるフラグメント・オブジェクトを、宛先ユーザ／クライアント・デバイスに最も近いフラグメント・サポート式キャッシュでのみキャッシングしなければならないか否かに関する判定を行う（ステップ６０３２）。そうでない場合には、現在のフラグメント・オブジェクトを、現在のコンピューティング・デバイスでもキャッシングすることができ、この処理は、ステップ６０３０に分岐して、そのフラグメントをキャッシングする。しかし、フラグメントを、宛先ユーザ／クライアント・デバイスに最も近いフラグメント・サポート式キャッシュでのみキャッシングしなければならない場合には、現在のコンピューティング・デバイスは、そのフラグメントをキャッシングせず、処理が完了する。
【０１９６】
図２０に関して、流れ図ステップによって、下流デバイスがフラグメント・サポート式キャッシュを有するか否かを判定する好ましい方法を示す。図２０は、図１９のステップ６０２８と置換することができるステップを表す。図１９および図２０に、応答メッセージを受信した後に開始される処理が示されており、応答メッセージは、現在のコンピューティング・デバイスによる要求メッセージの以前の受信および転送の結果として受信されるものである。したがって、キャッシュ管理ユニットによって、応答メッセージが受信される時に、前に受信された要求メッセージに関する何らかの形の状態情報が維持されている。
【０１９７】
下流デバイスがフラグメント・サポート式キャッシュを有するか否かの判定に関して、好ましい実施形態では、前に受信した要求メッセージに、フラグメントがサポートされることを示すディレクティブを有するメッセージ／プロトコル・ヘッダが含まれたか否かを判定する（ステップ６０３４）。具体的に言うと、図６からわかるように、ＦＲＡＧＭＥＮＴヘッダをＨＴＴＰメッセージに配置することができ、ＦＲＡＧＭＥＮＴヘッダに、「ｓｕｐｐｏｒｔｓ−ｆｒａｇｍｅｎｔｓ」ディレクティブを含めることができる。
【０１９８】
図２１に関して、流れ図ステップによって、現在処理されつつあるフラグメント・オブジェクトを、宛先ユーザ／クライアント・デバイスに最も近いフラグメント・サポート式キャッシュでのみキャッシングしなければならないか否かを判定する、より具体的な方法を示す。図２１は、図１９のステップ６０３２と置換することができるステップを表す。この実施形態では、現在のコンピューティング・デバイスによって現在処理されつつある応答メッセージが、この応答メッセージのフラグメントを宛先ユーザ／デバイスに最も近いフラグメント・サポート式キャッシュでのみキャッシングしなければならないことを示す起点サーバからのディレクティブを含むメッセージ／プロトコル・ヘッダを有する。
【０１９９】
図２２に関して、流れ図ステップによって、現在処理されつつあるフラグメント・オブジェクトを、宛先ユーザ／クライアント・デバイスに最も近いフラグメント・サポート式キャッシュでのみキャッシングしなければならないかどうかを判定する、好ましい方法を示す。図２１に類似する形で、図２２は、図１９のステップ６０３２と置換することができるステップを表す。好ましい実施形態では、現在のコンピューティング・デバイスによって現在処理されつつある応答メッセージが、応答メッセージ内のフラグメントを宛先ユーザ／デバイスに最も近いフラグメント・サポート式キャッシュでのみキャッシングしなければならないことをフラグメント・サポート式キャッシュに示す起点サーバからの「ｐｒｉｖａｔｅ」ディレクティブを含むＨＴＴＰ「Ｃａｃｈｅ−Ｃｏｎｔｒｏｌ」メッセージ／プロトコル・ヘッダを有する。
【０２００】
図２３に関して、流れ図によって、現在のコンピューティング・デバイスから応答メッセージを返す前にページ組立が必要であるか否かを判定する方法を示す。図２３は、図１５のステップ６０１６および６０１８と置換することができる処理を示し、この処理が呼び出される時には、応答メッセージからのフラグメントが、必要な場合には既にキャッシングされている。
【０２０１】
この処理は、たとえば図１９のステップ６０２８に類似する形で、下流デバイスがフラグメント・サポート式キャッシュを有するか否かを判定することによって開始される（ステップ６０４０）。下流デバイスが、フラグメント・サポート式キャッシュを有する場合には、ページ組立は不要であり、この処理は完了する。下流デバイスがフラグメント・サポート式キャッシュを有しない場合には、現在処理されつつあるフラグメントが、別のフラグメントへのリンクを有するか否かを判定する（ステップ６０４２）。そうでない場合には、ページ組立は不要であり、この処理は完了する。別のフラグメントへのリンクが現在のフラグメントに存在する場合には、ページ組立を実行し（ステップ６０４４）、処理が完了する。
【０２０２】
図２４に関して、流れ図ステップによって、現在処理されつつあるフラグメント・オブジェクトが、別のフラグメントへのリンクを有するか否かを判定する、より具体的な方法を示す。図２４は、図２３のステップ６０４２と置換することができるステップを表す。この実施形態では、現在のフラグメントが、インクルードされるフラグメントのソース識別子またはソース位置を示すタグ付き要素を含むマークアップ言語要素を有するかどうかに関する判定が行われる（ステップ６０４６）。具体的に言うと、図５に示されているように、ＦＲＡＧＭＥＮＴＬＩＮＫ要素をＨＴＭＬオブジェクトの本体に配置して、別のフラグメントへのリンクを示すことができる。ＨＴＴＰ仕様では、ソース識別子を、「Ｒｅｑｕｅｓｔ−ＵＲＩ」と称し、これは、要求に適用されるリソースを識別する識別子である。
【０２０３】
図２５に関して、流れ図ステップによって、現在処理されつつあるフラグメント・オブジェクトが、別のフラグメントへのリンクを有するか否かを判定する、代替の方法を示す。図２４に類似する形で、図２５は、図２３のステップ６０４２と置換することができるステップを表す。この代替実施形態では、現在処理されつつある応答メッセージに、応答メッセージのメッセージ本体内のフラグメントすなわち現在処理されつつあるフラグメントが別のフラグメントへのリンクを有することを示すディレクティブを伴うメッセージ／プロトコル・ヘッダが含まれるかどうかの判定が行われる（ステップ６０４８）。これは、フラグメントからＦＲＡＧＭＥＮＴＬＩＮＫをスキャンすることによって判定することができる。しかし、応答ヘッダを使用してこれを示し、不要なスキャンを回避することが、はるかに効率的である。具体的に言うと、図６に示されているように、ＦＲＡＧＭＥＮＴヘッダをＨＴＴＰメッセージ内に配置することができ、そのＦＲＡＧＭＥＮＴヘッダに、「ｃｏｎｔａｉｎｓ−ｆｒａｇｍｅｎｔｓ」ディレクティブを含めることができる。このディレクティブを用いると、現在のコンピューティング・デバイスのキャッシュ管理ユニットが、現在のフラグメントのスキャンに先立って、ＦＲＡＧＭＥＮＴＬＩＮＫ要素を検索できるようになる。
【０２０４】
図２６に関して、流れ図によって、ページ組立を実行する処理を示す。図２６は、図１５のステップ６０１８または図２３のステップ６０４４と置換することができるステップを表す。この処理は、現在のフラグメントにインクルードされるリンクされたフラグメントのソース識別子、たとえばＵＲＩを応答メッセージから得ることによって開始される。次に、ソース識別子を使用して、リンクされたフラグメントを取り出す（ステップ６０５２）。取り出されたフラグメントおよび応答メッセージからの現在のフラグメントを組み合わせて、組み立てられたページすなわち新しいフラグメントを形成し（ステップ６０５４）、処理が完了する。
【０２０５】
フラグメントのコンテンツの組合せは、フラグメントのコンテンツ・タイプに関するエンコーディング規則に依存する。たとえば、マークアップ言語の各要素を、フラグメントとみなすことができ、親要素の区切りタグ内にタグ付き要素を挿入することによって、子要素を親要素に組み込むことができる。しかし、フラグメントの組合せは、下で詳細に説明するように、フラグメントのヘッダおよびプロパティ値を組み合わせる形の考慮も必要とする。
【０２０６】
図２７に関して、流れ図によって、任意選択としてフラグメント・リンクを複数のフラグメント・リンクに展開する処理を示す。図２６に戻って、現在のフラグメントに、複数のフラグメント・リンクが含まれる場合に、ステップ６０５０および６０５２を、複数のリンクされたフラグメントを取り出すのに必要な回数だけ繰り返すことができ、それらのフラグメントのすべてを組み合わせて単一の組み立てられたページを形成することができる。対照的に、図２７には、組み立てられたページを形成するために組み合わされる複数のフラグメントへの参照を含めるために単一のフラグメント・リンクをコンパクトに表すことができる処理が示されている。
【０２０７】
この処理は、応答メッセージからの現在のフラグメント内のフラグメント・リンクによって、これを複数のフラグメント・リンクに展開しなければならないことが示されるか否かの判定から始まる（ステップ６０６２）。そうでない場合には、処理が完了し、そうである場合には、フラグメント・リンクに関連する情報を使用して、フラグメント・リンクを複数のフラグメント・リンクの組に展開する（ステップ６０６４）。
【０２０８】
次に、複数のフラグメント・リンクをループで処理する。複数のフラグメント・リンクの組の次のフラグメント・リンクを入手し（ステップ６０６６）、そのフラグメント・リンクのソース識別子を入手する（ステップ６０６８）。識別されたフラグメントを、そのソース識別子を使用して取り出す（ステップ６０７０）。複数のフラグメント・リンクの組に別のフラグメント・リンクがあるかどうかに関する判定を行い（ステップ６０７２）、そうである場合には、処理はステップ６０６６に分岐して、別のフラグメント・リンクを処理する。残りのフラグメント・リンクがない場合すなわち、すべてのフラグメントが取り出されている場合には、取り出されたフラグメントのすべてを、元々の応答メッセージからのフラグメントと組み合わせ（ステップ６０７４）、処理が完了する。
【０２０９】
図２８に関して、流れ図ステップによって、応答メッセージからの現在のフラグメントのフラグメント・リンクが、これを複数のフラグメント・リンクに展開しなければならないことを示すか否かを判定する好ましい方法を示す。図２８は、図２７のステップ６０６２と置換することができるステップを表す。好ましい実施形態では、応答メッセージからのフラグメント内のフラグメント・リンクのマークアップ言語タグ付き要素に、フラグメント・リンクを展開しなければならないことを示す属性が含まれるか否かの判定が行われる（ステップ６０７６）。具体的に言うと、図５に示されているように、ＦＲＡＧＭＥＮＴＬＩＮＫがＦＯＲＥＡＣＨ属性を有することができる。
【０２１０】
図２９に関して、流れ図によって、フラグメント・リンクに関連する情報に従ってフラグメント・リンクを複数のフラグメント・リンクに展開する処理を示す。図２９は、図２７のステップ６０６４と置換することができる一連のステップを表す。
【０２１１】
この処理は、フラグメント・リンクに含まれるマークアップ言語タグ付き要素からクッキー名を得ることによって開始される（ステップ６０７８）。図５に示されているように、ＦＯＲＥＡＣＨ属性によって、クッキーの名前として解釈される文字列を供給することができる。クッキーの値を取り出す（ステップ６０８０）。クッキーの値は、名前／値対のリストを表す文字列であり、これがループで処理される。クッキー値から次の名前／値対を取り出し（ステップ６０８２）、たとえば照会パラメータとして名前／値対を使用して、名前／値対を使用することによってフラグメント・リンクを生成する（ステップ６０８４）。クッキー値に別の名前／値対があるかどうかに関する判定を行い（ステップ６０８６）、そうである場合には、この処理はステップ６０８２に分岐して、別の名前／値対を処理する。たとえば、名前／値対ごとにＦＲＡＧＭＥＮＴＬＩＮＫ要素を生成することができ、これによって、元のＦＲＡＧＭＥＮＴＬＩＮＫ要素が、元のＦＲＡＧＭＥＮＴＬＩＮＫ要素と置換される複数のＦＲＡＧＭＥＮＴＬＩＮＫ要素の組に展開される。残りの名前／値対がない場合には、処理が完了する。
【０２１２】
図３０に関して、流れ図によって、フラグメントのソース識別子を使用するフラグメントの取出しの処理を示す。図３０は、図２６のステップ６０５２および図２７のステップ６０７０と置換することができる処理を表し、図３０の処理は、フラグメントのソース識別子が既に判定された後に開始される。
【０２１３】
この処理は、現在のコンピューティング・デバイスのローカル・キャッシュ内でソース識別子とのキャッシュ・ヒットがあるか否かの判定から始まる（ステップ６０９２）。そうである場合には、キャッシュからフラグメントを取り出すことができ（ステップ６０９４）、取り出されたフラグメントを、呼出し側ルーチンに返す（ステップ６０９６）。取り出されたフラグメントに、フラグメント・リンクが含まれる場合には、この処理はステップ６０９２にループ・バックして、フラグメント・リンクによって識別されるフラグメントを取り出し（ステップ６０９８）、これによって、すべての子フラグメントを取り出すためにこの処理が継続される。
【０２１４】
ステップ６０９２で、ローカル・キャッシュ内でソース識別子に関するキャッシュ・ミスがあった場合には、要求メッセージを、生成し（ステップ６１００）、宛先識別子としてソース識別子を使用して送信する（ステップ６１０２）。図６に関して説明したように、現在のコンピューティング・デバイスにフラグメント・サポート式キャッシュ管理ユニットが含まれるので、要求メッセージに、「ｓｕｐｐｏｒｔｓ−ｆｒａｇｍｅｎｔｓ」ディレクティブが含まれる。キャッシュ管理ユニットは、要求メッセージに対する応答を待つ（ステップ６１０４）。要求のためにスレッドが作成され、このスレッドが、コンピューティング・デバイスが他の動作を実行している間に、応答を待ってスリープすることが好ましい。
【０２１５】
応答メッセージが受信された後に、応答メッセージのメッセージ本体内のフラグメントを取り出し（ステップ６１０６）、キャッシングする（ステップ６１０８）。上で述べたように、取り出されたフラグメントが、呼出し側ルーチンに返され、取り出されたフラグメントにフラグメント・リンクが含まれる場合には、この処理は、ステップ６０９２にループ・バックして、フラグメント・リンクによって識別されるフラグメントを取り出し、これによって、すべての子フラグメントを取り出すためにこの処理が継続される。そうでない場合には、フラグメント取出の処理が完了する。
【０２１６】
図３１に関して、流れ図によって、フラグメントがフラグメント・サポート式キャッシュ管理ユニット内でキャッシングされる時に実行される処理の一部を示す。図３１は、図１５のステップ６０１４および図１９のステップ６０３０と置換される処理を表し、図３１の処理は、現在のコンピューティング・デバイスで応答メッセージでフラグメントが既に受け取られた後に開始される。
【０２１７】
この処理は、応答メッセージ内のＵＲＩなどのフラグメントに関連するソース識別子を取り出す（ステップ６１１２）ことと、応答メッセージ内にｒｕｌｅｌｉｓｔが存在する場合に、フラグメントに関連するｒｕｌｅｌｉｓｔを取り出すこと（ステップ６１１４）によって開始される。後に、処理されつつある要求に関するキャッシュ・ヒットを行うことを試みる時に使用するために、ｒｕｌｅｌｉｓｔを、ＵＲＩパスに関連するｒｕｌｅｌｉｓｔデータベースに保管する（ステップ６１１６）。ｒｕｌｅｌｉｓｔは、応答メッセージ内のフラグメントをキャッシングするためのキャッシュＩＤの生成をガイドするのに使用される（ステップ６１１８）。
【０２１８】
次に、キャッシュＩＤを使用して、キャッシュ・インデックスを生成するが（ステップ６１２０）、キャッシュ・インデックスは、応答メッセージからのフラグメントが保管される、フラグメント・ストレージすなわちキャッシュ・メモリ内の位置を決定するのに使用される。キャッシュ・インデックスは、キャッシュＩＤをハッシュ・アルゴリズムにかけることによって作成することができる。フラグメントに付随するキャッシュＩＤ規則の使用の技法を厳守する形でキャッシュＩＤが生成された後に、キャッシュ管理ユニットの各実施形態が、キャッシュ・インデックスの計算にそれ自体のアルゴリズムを使用できるという点で、本発明の好ましい実施形態の技法は、柔軟である。
【０２１９】
フラグメントを、他の必要な情報またはメタデータと共にキャッシュに保管する（ステップ６１２２）が、この情報またはメタデータには、フラグメントに付随するＨＴＴＰ応答メッセージ内のヘッダまたは同等の情報が含まれ、次に、新たに生成されたキャッシュＩＤを、キャッシュ・インデックスに関連して保管する（ステップ６１２４）。代替案では、キャッシュ・インデックスを、必要な時に必ず計算することができ、キャッシュ・インデックスを保管する必要をなくすことができる。もう１つの代替案として、キャッシュＩＤを、なんらかのタイプのストレージ・インデックスまたはデータベース識別子として直接に使用することができ、別々のキャッシュ・インデックスを計算する必要をなくすことができる。
【０２２０】
応答メッセージ内のフラグメントに関連する依存性がある場合には、依存性を取り出し（ステップ６１２６）、フラグメントのキャッシュＩＤに関連して保管する（ステップ６１２８）。
【０２２１】
図３２に関して、流れ図によって、フラグメントがキャッシュ管理ユニットを含むコンピューティング・デバイスでキャッシングされる場合に、そのフラグメントを入手するためにフラグメント・サポート式キャッシュ管理ユニットによって使用することができる処理を示す。言い換えると、図３２には、たとえば要求メッセージの検査に応答して、フラグメント・サポート式キャッシュでキャッシュ・ヒットを生成できるかどうかを判定するのに使用することができる処理が示されている。
【０２２２】
この処理は、要求に関連するソース識別子、たとえばＵＲＩパスを取り出すことによって開始される（ステップ６１３２）。次に、ｒｕｌｅｌｉｓｔデータベースを検索して、ＵＲＩパスについてｒｕｌｅｌｉｓｔデータベース内にキャッシュＩＤ  ｒｕｌｅｌｉｓｔが存在するかどうかを判定する（ステップ６１３４）。ＵＲＩパスに関連するｒｕｌｅｌｉｓｔがない場合には、キャッシュ・ミス表示を返し（ステップ６１３６）、処理が完了する。
【０２２３】
ＵＲＩパスに関連するｒｕｌｅｌｉｓｔが存在する場合に、キャッシュＩＤを生成できるすなわち、少なくとも１つの規則を成功裡に評価するのに必要なすべての情報が存在すると仮定して、ｒｕｌｅｌｉｓｔ内の規則を使用して、キャッシュＩＤを作成する（ステップ６１３８）。キャッシュＩＤがフラグメントの保管に前に使用されたかどうか、すなわち、キャッシュ・ヒットがあるかどうかの判定を行う（ステップ６１４０）。そうでない場合には、キャッシュ・ミス表示を返し、処理が完了する。
【０２２４】
キャッシュ・ヒットがある場合には、キャッシュＩＤに関連するキャッシュ・インデックスを取り出し（ステップ６１４２）、これによって、キャッシュ・インデックスを使用する適当なフラグメントの後続の取出（ステップ６１４４）が可能になる。次に、フラグメントを要求元に返し（ステップ６１４６）、処理が完了する。
【０２２５】
図３３に関して、流れ図によって、複数のフラグメントに関連するヘッダ値およびプロパティ値を組み合わせる処理を示す。図３３は、図２６のステップ６０５４または図２７のステップ６０７４と置換することができる処理を表す。組み合わされるフラグメントのそれぞれは、応答メッセージで受信されたものであれ、コンピューティング・デバイスのキャッシュから取り出されたものであれ、応答メッセージで各フラグメントと共に受信されたプロトコル・ヘッダの関連する組を有する。ヘッダおよびプロパティの値が、各ヘッダまたはプロパティの単一のディレクティブ／値に組み合わされる。
【０２２６】
この処理は、組み合わされるすべてのフラグメントの次のヘッダ・タイプのヘッダ値を得ることによって開始される（ステップ６１５２）。適当な組合せ機能を、これらのヘッダ値にすべてに適用し（ステップ６１５４）、組み合わされたヘッダ値を、組み立てられたページまたはフラグメントについてセットするか、これに関連付ける（ステップ６１５６）。処理すべき別のヘッダタイプがあるか否かに関する判定を行い（ステップ６１５８）、そうである場合には、この処理はステップ６１５２に分岐して、別のヘッダ・タイプを処理する。
【０２２７】
ヘッダのすべてを処理した後に、この処理では、組み合わされるすべてのフラグメントの次のプロパティ・タイプのプロパティ値を取り出す（ステップ６１６０）。これらのプロパティ値のすべてに、適当な組合せ機能を適用し（ステップ６１６２）、組み合わされたプロパティ値を、組み立てられたページまたはフラグメントについてセットするか、これに関連付ける（ステップ６１６４）。処理すべき別のプロパティ・タイプがあるか否かに関する判定を行い（ステップ６１６６）、そうである場合には、この処理はステップ６１６０に分岐して、別のプロパティ・タイプを処理し、そうでない場合には、処理が完了する。
【０２２８】
図３４に関して、流れ図によって、ヘッダ・タイプおよびプロパティ値の、一連の組合せ機能を表すステップの組を示す。図３４は、図３３のステップ６１５４または６１６２で使用することができる組合せ機能を表し、図示の組合せ機能は、キャッシュ管理ユニットに存在することができる組合せ機能の完全なリストとして意図されてはいない。
【０２２９】
この処理は、ＨＴＴＰ「Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ」フィールドが組み合わされるか否かを判定することによって開始される（ステップ６１６８）。そうでない場合には、次のステップをスキップし、そうである場合には、組み合わされた「Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ」フィールドの値は、すべての「Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ」フィールドの合計である（ステップ６１７０）。
【０２３０】
この処理は、ＨＴＴＰ「Ｌａｓｔ−Ｍｏｄｉｆｉｅｄ」フィールドが組み合わされるか否かを判定することによって継続される（ステップ６１７２）。そうでない場合には、次のステップをスキップし、そうである場合には、組み合わされた「Ｌａｓｔ−Ｍｏｄｉｆｉｅｄ」フィールドの値は、すべての「Ｌａｓｔ−Ｍｏｄｉｆｉｅｄ」フィールドのうちで最新のものである（ステップ６１７４）。
【０２３１】
この処理は、満了時刻値が組み合わされるか否かを判定することによって継続される（ステップ６１７６）。そうでない場合には、次のステップをスキップし、そうである場合には、組み合わされた満了時刻値を、下記の考慮事項に従ってセットする（ステップ６１７８）。フラグメントの時刻に基づいて無効化される応答ヘッダと、組み立てられたページの応答ヘッダの間の関係は、フラグメントをサポートするキャッシュによって尊重されなければならない。この組立処理では、組み立てられたページの無効化時刻を、下記の形で判定する。第１に、絶対時刻である「Ｅｘｐｉｒｅｓ」ヘッダ、相対時刻である「ｍａｘ−ａｇｅ」ディレクティブを有する「Ｃａｃｈｅ−Ｃｏｎｔｒｏｌ」ヘッダ、および各フラグメントの「Ｄａｔｅ」ヘッダから、トップレベル・フラグメントおよびすべての再帰的に含まれるフラグメントを含む、すべてのフラグメントの最短の同等の時間間隔が計算される。これは、「Ｄａｔｅ」ヘッダ値を使用して、絶対時刻をデルタ時刻に変換することによって行われる。この値を「ｍｉｎｉｍｕｍＲｅｌａｔｉｖｅＴｉｍｅ」と称する。第２に、組み立てられたページの「Ｅｘｐｉｒｅｓ」ヘッダの値に、「Ｄａｔｅ」ヘッダの値と計算されたｍｉｎｉｍｕｍＲｅｌａｔｉｖｅＴｉｍｅ値の合計をセットする。これは、ＨＴＴＰ／１．１「Ｃａｃｈｅ−Ｃｏｎｔｒｏｌ」ヘッダをサポートしないキャッシュのために必要である。第３に、組み立てられたページの「ｍａｘ−ａｇｅ」ディレクティブに、計算されたｍｉｎｉｍｕｍＲｅｌａｔｉｖｅＴｉｍｅ値をセットする。というのは、ＨＴＴＰ／１．１仕様によって、「Ｅｘｐｉｒｅｓ」ヘッダがより制限的である場合に、「Ｅｘｐｉｒｅｓ」ヘッダが「ｍａｘ−ａｇｅ」ディレクティブによってオーバーライドされることが指定されているからである。これは、ＨＴＴＰ／１．１をサポートするキャッシュのために必要である。
【０２３２】
この処理の最後のステップでは、ｃｏｎｔｅｎｔ−ｅｎｃｏｄｉｎｇタイプに適当な値をセットする（ステップ６１８０）。第１の代替案では、ＨＴＴＰ／１．１仕様に従って、新しいエンコーディングがクライアントに受入可能であることが既知の場合に、組み合わされるヘッダの１つに「ｎｏ−ｔｒａｎｓｆｏｒｍ」キャッシュ制御ディレクティブがないならば、キャッシュでｃｏｎｔｅｎｔ−ｅｎｃｏｄｉｎｇを変更することができる。第２の代替案では、インクルードされるフラグメントのｃｏｎｔｅｎｔ−ｅｎｃｏｄｉｎｇを、トップレベル・フラグメントと同一になるように変更する。
【０２３３】
図３５に関して、流れ図によって、要求メッセージを処理する時にフラグメント・サポート式キャッシュ管理ユニットによって使用することができる処理を示す。応答メッセージの処理を示す図１５と対照的に、図３５には、要求メッセージの処理に関連するステップの一部が示されている。
【０２３４】
この処理は、要求メッセージを受信することによって開始され（ステップ６１９２）、その後、要求メッセージからソース識別子を取り出す（ステップ６１９４）。ソース識別子は、識別されたオブジェクトまたはフラグメントをローカル・キャッシュから得る、すなわちキャッシュ・ヒットが発生した場合、または要求によってオブジェクトまたはフラグメントを取り出す、すなわちキャッシュ・ミスが発生した場合のいずれかに使用される（ステップ６１９６）。キャッシュ・ヒットまたはキャッシュ・ミスに関連する処理は、図３０に関して上で説明した。どちらの場合でも、ページ組立が必要な場合には、それが実行され（ステップ６１９８）るが、ページ組立に関連する処理は、上で図３３に関して説明した。その後、受信した要求メッセージに関する応答メッセージを返し（ステップ６２００）、これによって処理を完了する。
【０２３５】
図３６に関して、流れ図によって、本発明の好ましい実施形態に従って無効化メッセージを処理する時にフラグメント・サポート式キャッシュ管理ユニットによって使用することができる処理を示す。上で注記したように、本発明の好ましい実施形態の技法は、特定の無効化アルゴリズムを要求せず、図３６に示された処理は、依存ＩＤの使用の１例にすぎない。
【０２３６】
この処理は、コンピューティング・デバイスで、コンピューティング・デバイスでキャッシングできるフラグメントをパブリッシュまたはサービスした起点サーバから、無効化要求メッセージを受信することによって開始される（ステップ６２０２）。この要求には、依存ＩＤのリストが含まれる。起点サーバが、衝突する依存性を生成しないことが仮定される。少なくともドメイン名を含むアプリケーションＩＤによる依存性の修飾によって、グローバルに一意な依存性を維持できることが仮定される。通常は、アプリケーションＩＤをインバリデータ（ｉｎｖａｌｉｄａｔｏｒ）に関連付け、その結果、インバリデータがそれ自体の内容だけを無効化できるようにするために、認証が必要である。
【０２３７】
次に、依存性データベースの依存性のいずれかが、受信されたメッセージ内の１つまたは複数の依存性と一致するかどうかに関する判定を行い（ステップ６２１０）、そうである場合には、一致する依存性（１つまたは複数）に関連するキャッシュＩＤのリストを取り出す（ステップ６２１２）。次に、キャッシュＩＤを使用して、関連するフラグメントをキャッシュから消去する（ステップ６２１４）。必要または適当である場合に、関連するｒｕｌｅｌｉｓｔおよび依存性も消去することができる。
【０２３８】
任意選択の応答を、無効化要求メッセージの発信元に返すことができる（ステップ６２１６）。依存性の一致がない場合には、この処理はステップ６２１６に分岐する。どの場合でも、処理が完了する。
【０２３９】
フラグメント・サポート式キャッシュのキャッシュ管理ユニットの間の調整のいくつかの例
図３７に関して、ブロック図によって、一部のキャッシュでフラグメント組立が実行される時を示すための、ウェブ・アプリケーション・サーバとクライアントの間でのデータフローの一部を示す。クライアント・デバイス７００に、フラグメント非サポート式キャッシュ管理ユニット７０２が含まれ、このフラグメント非サポート式キャッシュ管理ユニット７０２によって、ページの要求が生成され、その要求が中間サーバ７０４に送信される。クライアント・デバイスは知らないが、要求されたページに、実際には親フラグメントと、子フラグメントへのリンクとが含まれる。中間サーバ７０４によって、要求が受信されるが、キャッシュ管理ユニット７０６は、フラグメントをサポートせず、要求されたページのキャッシングされたバージョンを有しない。
【０２４０】
要求は、中間サーバ７０８に転送され、中間サーバ７０８には、フラグメント・サポート式キャッシュ管理ユニット７１０が含まれる。中間サーバ７０８は、要求されたページのキャッシングされたバージョンを有しておらず、中間サーバ７０８は、要求メッセージを中間サーバ７１２に送信する前に、要求メッセージに「Ｆｒａｇｍｅｎｔ：ｓｕｐｐｏｒｔｓ−ｆｒａｇｍｅｎｔｓ」ヘッダを追加し、中間サーバ７１２には、フラグメント非サポート式キャッシュ管理ユニット７１４が含まれる。中間サーバ７１２は、要求されたページのキャッシングされたバージョンを有しておらず、要求メッセージをウェブ・アプリケーション・サーバ７１６に送信／転送し、ウェブ・アプリケーション・サーバ７１６には、フラグメント・サポート式キャッシュ管理ユニット７１８が含まれる。
【０２４１】
「Ｆｒａｇｍｅｎｔ：ｓｕｐｐｏｒｔｓ−ｆｒａｇｍｅｎｔｓ」ヘッダを含む着信要求メッセージから、ウェブ・アプリケーション・サーバ７１６は、下流コンピューティング・デバイスが、ページ・アセンブラとして働くことができるフラグメント・サポート式キャッシュ管理ユニットを有すると判定することができる。したがって、応答で完全に組み立てられたページを返すのではなく、ウェブ・アプリケーション・サーバ７１６は、ＦＲＡＧＭＥＮＴＬＩＮＫ子フラグメントを含む親フラグメントを有する応答を返す。中間サーバ７１２は、フラグメントをサポートせず、したがって、単にこの応答を転送する。
【０２４２】
フラグメント・サポート式キャッシュ管理ユニット７１０は、それがエンドユーザまたはクライアントに最も近いフラグメント・サポート式キャッシュであることを認識し、元の要求には「Ｆｒａｇｍｅｎｔ：ｓｕｐｐｏｒｔｓ−ｆｒａｇｍｅｎｔｓ」ヘッダが含まれておらず、したがって、フラグメント・サポート式キャッシュ管理ユニット７１０は、この応答を返す前に、ページ組立を実行しなければならないと判定する。ページ組立処理中に、フラグメント・サポート式キャッシュ管理ユニット７１０は、親フラグメントにリンクされた子フラグメントを要求し、受信し、この子フラグメントおよび親フラグメントが、単一の組み立てられたページに組み合わされ、組み立てられたページが、クライアント・デバイスに返される。中間サーバ７０４によって、この応答がクライアント・デバイス７００に返され、クライアント・デバイス７００によって、組み立てられたページがエンドユーザに提示される。中間サーバ７０４およびクライアント・デバイス７００の両方によって、組み立てられたページがキャッシングされない。というのは、この応答が、「ｎｏ−ｃａｃｈｅ」ディレクティブを用いてマークされ、これによって、これらのデバイスが組み立てられたページをキャッシングしなくなるからである。中間サーバ７０８は、親フラグメントと子フラグメントの両方をキャッシングする。
【０２４３】
図３８に関して、ブロック図によって、エンドユーザまたはクライアント・デバイスに最も近いキャッシュでフラグメントをキャッシングするようにデバイスの組に指示することができる形を示すための、ウェブ・アプリケーション・サーバとクライアントの間でのデータフローの一部を示す。クライアント・デバイス７２０に、フラグメント非サポート式キャッシュ管理ユニット７２２が含まれ、これによって、オブジェクトに関する要求が生成され、その要求が中間サーバ７２４に送信される。クライアント・デバイスは知らないが、要求されたオブジェクトは、実際にはフラグメントである。中間サーバ７２４によって、要求が受信されるが、キャッシュ管理ユニット７２６は、フラグメントをサポートするが、要求されたフラグメントのキャッシングされたバージョンを有しておらず、キャッシュ管理ユニット７２６によって、要求に「Ｆｒａｇｍｅｎｔ：ｓｕｐｐｏｒｔｓ−ｆｒａｇｍｅｎｔｓ」ヘッダが追加され、その要求が宛先サーバに転送される。
【０２４４】
中間サーバ７２８によって、要求が受信されるが、キャッシュ管理ユニット７３０は、要求されたフラグメントのキャッシングされたバージョンを有しておらず、フラグメント・サポート式キャッシュ管理ユニット７３０によって、「Ｆｒａｇｍｅｎｔ：ｓｕｐｐｏｒｔｓ−ｆｒａｇｍｅｎｔｓ」ヘッダが要求メッセージに含まれることが保証され、その要求が、宛先サーバに転送される。中間サーバ７３２には、キャッシュ管理ユニット７３４が含まれるが、キャッシュ管理ユニット７３４は、フラグメントをサポートせず、要求されたオブジェクトのキャッシングされたバージョンを有しておらず、要求を転送する。
【０２４５】
「Ｆｒａｇｍｅｎｔ：ｓｕｐｐｏｒｔｓ−ｆｒａｇｍｅｎｔｓ」ヘッダを含む着信要求メッセージから、ウェブ・アプリケーション・サーバ７３６は、下流コンピューティング・デバイスが、フラグメント・サポート式キャッシュ管理ユニットを有すると判定することができる。したがって、ウェブ・アプリケーション・サーバ７３６は、フラグメントを含む応答を返すことが適当であると判定することができる。しかし、ウェブ・アプリケーション・サーバ７３６は、応答メッセージに「Ｃａｃｈｅ−Ｃｏｎｔｒｏｌ：ｐｒｉｖａｔｅ」ヘッダを用いてマークし、これによって、応答内のフラグメントの、エンドユーザまたはクライアント・デバイスに最も近いフラグメント・サポート式キャッシュだけによるキャッシングがもたらされ、キャッシュ管理ユニット７３８は、応答のフラグメントをキャッシングしない。
【０２４６】
中間サーバ７３２は、フラグメントをサポートしない。キャッシュ管理ユニット７３４は、「ｐｒｉｖａｔｅ」ディレクティブを認識し、したがって、フラグメントをキャッシングせず、中間サーバ７３２は、応答を単に転送する。対照的に、キャッシュ管理ユニット７３０は、フラグメントをサポートするが、元々の要求が「Ｆｒａｇｍｅｎｔ：ｓｕｐｐｏｒｔｓ−ｆｒａｇｍｅｎｔ」ヘッダを用いてマークされており、下流デバイスが、エンドユーザまたはクライアント・デバイスにより近いところでフラグメントをキャッシングできることを認識する。したがって、キャッシュ管理ユニット７３０は、応答のフラグメントをキャッシングしないようにという指示として「ｐｒｉｖａｔｅ」ディレクティブを解釈する。
【０２４７】
キャッシュ管理ユニット７２６も、フラグメントをサポートするが、元々の要求が「Ｆｒａｇｍｅｎｔ：ｓｕｐｐｏｒｔｓ−ｆｒａｇｍｅｎｔ」を用いてマークされておらず、下流デバイスが、エンドユーザまたはクライアント・デバイスにより近いところでフラグメントをキャッシングできないことを認識する。したがって、キャッシュ管理ユニット７２６は、応答のフラグメントをキャッシングするように指示するものとして「ｐｒｉｖａｔｅ」ディレクティブを解釈する。中間サーバ７２４によって、応答がクライアント・デバイス７２０に転送され、キャッシュ管理ユニット７２２は、フラグメントをサポートせず、したがって、フラグメントをキャッシングしないように指示するものとして「ｐｒｉｖａｔｅ」ディレクティブを解釈する。
【０２４８】
役割固有コンテンツまたはカテゴリ固有コンテンツのキャッシングをサポートするのに使用されるフラグメント・サポート式キャッシュの例
図３９から４２に関して、データフロー図によって、動的な役割固有またはカテゴリ固有のコンテンツのキャッシングを本発明の好ましい実施形態に従って達成できることを示すために、クライアント、中間フラグメント・サポート式キャッシュ、またはサーバ内で行われる処理ステップの一部を示す。特定の機関との関連または機関での役割に基づいてユーザのグループに固有になるように、一部のウェブ・コンテンツを分類することができる。たとえば、企業は、その製品に関する価格設定データベースの第１のバージョンを第１の会社に公開し、その製品に関する価格設定データベースの第２のバージョンを第２の会社に公開することができる。たとえば、第２の会社は、企業の製品の大量購入に関してかなりの数量割引を得ることができる。
【０２４９】
第１の会社の第１従業員が、企業のウェブ・サイトを訪れる時に、この従業員は、第１の会社に関する価格設定情報を示すウェブ・ページを受信しなければならない。この価格設定情報は、比較的頻繁に変更される可能性があり、したがって、この価格設定情報は、静的コンテンツと比較してキャッシングが困難である。第２の会社の従業員がこの企業のウェブ・サイトを訪れる時には、この従業員は、第２の会社に関する価格設定情報を示すウェブ・ページを受信しなければならない。
【０２５０】
本発明の好ましい実施形態では、異なる顧客会社の従業員のために生成されるウェブ・ページをキャッシングし、同一の会社の他の従業員から使用可能にすることができる。第１の会社の第２の従業員が、企業のウェブ・サイトを訪れる時に、この従業員は、同一の会社の第１の従業員のためにキャッシングされたウェブ・ページを受信することができる。言い換えると、企業のコンテンツが、異なる機関すなわち、異なる顧客会社による使用のために分類されている。
【０２５１】
第２の例を使用すると、会社は、人的資源情報を含むウェブ・サイトを有することができるが、その情報の一部を、会社の管理職レベルの従業員だけが見るように制限しなければならない。しかし、管理レベル情報がダイナミック・コンテンツであっても、その情報を見る管理者ごとに管理レベル情報の複数のコピーをキャッシングする必要があってはならない。本発明の好ましい実施形態によれば、たとえば管理職対非管理職などの役割固有コンテンツをキャッシングすることができ、組織内のユーザの役割を使用して、キャッシングされたコンテンツのどの組をユーザに返すかの判定を支援することができる。
【０２５２】
これらの例を、カテゴリ区別を使用する全般的な形で説明することができる。コンテンツのカテゴリという概念は、コンテンツにアクセスしているユーザに適用できる特性に基づいて、ユーザの役割、機関のエンティティなどに適用することができる。図３９から４２に、本発明の好ましい実施形態を使用して、カテゴリ固有コンテンツをキャッシングできる形の一般的な例を示す。
【０２５３】
図３９を参照すると、たとえばブラウザなどのクライアント・アプリケーションによって、ページ要求が生成され（ステップ８０２）、これがアプリケーション・サーバに送信される（ステップ８０４）。中間のフラグメント・サポート式キャッシュは、要求されたページのコピーを有しておらず、したがって、キャッシングされたコピーを返すことができない。アプリケーション・サーバによって、要求されたページが、ユーザのあるカテゴリによる表示に制限されていることが判定されるが、アプリケーション・サーバによって、ユーザの制限されたカテゴリのメンバとして要求者を識別するのに必要なクッキーがこの要求に付随しないことが検出される（ステップ８０６）。サーバによって、認証チャレンジ・ページが生成され（ステップ８０８）、クライアントに送信される（ステップ８１０）が、この認証チャレンジ・ページは、キャッシュ不能としてマークされ、したがって、中間キャッシュはこれをキャッシングすることができない。
【０２５４】
クライアントによって、認証チャレンジ・ページが受信され、ユーザに提示され（ステップ８１２）、ユーザは、ユーザＩＤおよびパスワードを供給し（ステップ８１４）、これがサーバに送り返される（ステップ８１６）。サーバによって、ユーザの情報が認証され（ステップ８１８）、識別されたユーザが属するユーザ・カテゴリを判定するのにユーザＩＤが使用される（ステップ８２０）。管理役割など、ユーザ・カテゴリを判定した後に、サーバによって、判定されたユーザ・カテゴリの識別を可能にする情報を含むカテゴリ・クッキーが生成される（ステップ８２２）。最初に要求されたページも生成され（ステップ８２４）、そのページおよびカテゴリ・クッキーが、クライアントに送信される（ステップ８２６）。
【０２５５】
この時点までに、中間キャッシュは、コンテンツを一切キャッシングしていない。しかし、現在返されつつあるページは、フラグメント・サポート式キャッシング規則に従ってキャッシュ可能としてマークされており、したがって、中間キャッシュは、そのページの識別子を使用してページを保管し（ステップ８２８）、そのページに付随するカテゴリ・クッキー、およびクライアントへの応答メッセージに付随するフラグメント・キャッシング規則でその中間キャッシュが使用されるように指示されるのに適当な他のすべての情報を保管する。クライアントは、要求したページを受信した後に、それをユーザに提示し（ステップ８３０）、付随するカテゴリ・クッキーが、クライアント・アプリケーションによってそのクッキー・キャッシュに保管される（ステップ８３２）。
【０２５６】
図４０を参照して、前に発行されたカテゴリ・クッキーを更新する例を示す。クライアント・アプリケーションによって、図３９に示されたページ要求に類似する、たとえば同一ドメインからのページ要求が生成される（ステップ８４２）。しかし、ユーザは、ユーザのカテゴリを変更させるアクションを実行した。たとえば、ユーザは、従業員のあるグループの管理者としてのユーザの役割に関してページを表示したが、財務責任者としてのユーザの役割に関するページを見ることを決定することができる。このユーザは、前に認証されているので、サーバは、別の認証処理を実行してはならない。しかし、サーバは、このユーザの新しいカテゴリ・クッキーを発行しなければならない。
【０２５７】
ページ要求が、付随するカテゴリ・クッキーと共にサーバに送信される（ステップ８４４）。中間キャッシュは、要求されたページを有しておらず、したがって、キャッシュ・ミスを有する。サーバによって、新しいカテゴリ・クッキー値を必要とする動作がクライアントによって要求されたことが判定され（ステップ８４６）、新しいカテゴリ・クッキーが発行される（ステップ８４８）。要求されたページも生成され（ステップ８５０）、要求されたページおよび新たに発行されたカテゴリ・クッキーが返される（ステップ８５２）。中間キャッシュによって、新しいクッキー値に従ってページが保管される（ステップ８５４）。クライアントによって、要求されたページが受信され、提示され（ステップ８５６）、新しいクッキー値が、クライアント側のクッキー・キャッシュに保管される（ステップ８５８）。この形で、カテゴリ・クッキーが更新される時に、中間キャッシュが更新される。
【０２５８】
図４１を参照すると、同一のカテゴリ・クッキーの使用の継続によってもキャッシュ・ミスがもたらされる形の例が示されている。クライアント・アプリケーションによって、ページ要求が、生成され（ステップ８６２）、付随するカテゴリ・クッキーと共にサーバに送信される（ステップ８６４）。中間キャッシュは、要求されたページを有しておらず、したがって、キャッシュ・ミスを有する。サーバは、カテゴリ・クッキーの値を使用して、コンテンツのタイプを動的に判定し、適当なページを生成し（ステップ８６６）、生成されたページおよび変更されないカテゴリ・クッキーが返される（ステップ８６８）。中間キャッシュは、ページを保管し（ステップ８７０）、このページをクライアントに転送する。クライアントは、要求されたページを受信し、提示し（ステップ８７２）、カテゴリ・クッキーが変更されていないので、クライアントは、クッキー・キャッシュのカテゴリ・クッキーを上書きするものとして示されていない。
【０２５９】
本発明の好ましい実施形態によれば、ステップ８２８、８５４、および８７０で、中間キャッシュが、サーバによって応答メッセージに配置されたフラグメントキャッシング規則に従って、応答メッセージからのページのコピーを保管した。本発明の好ましい実施形態を用いると、ページに関連するＵＲＩだけがキャッシングに使用される場合に同一として識別される可能性がある類似するページの２つの異なるバージョンを区別するのに、キャッシュＩＤ動作でクッキーを使用できるようになる。より重要なことに、ページをカテゴリ・クッキーに関連してキャッシングでき、カテゴリ・クッキーを、その後、キャッシュ・ルックアップ処理に使用できるようになり、これによって、図４２に示されているように、アサートされたカテゴリ・クッキーでの類似性に基づいて、キャッシュ・ヒットを確立できるようになる。
【０２６０】
図４２を参照すると、２人の異なるユーザによる同一のカテゴリ・クッキーの使用によって、異なるユーザによる単一ページのアクセスにまたがるキャッシュ・ヒットがもたらされる形の例が示されている。この例では、異なるユーザが、図４１に示された前の例の第１ユーザと同一のページにアクセスしている。しかし、第２ユーザは、第１ユーザと同一のユーザのカテゴリに属する。言い換えると、２人のユーザを、ユーザの同一のカテゴリに属する、または同一の役割が割り当てられていると記述することができる。たとえば、この２人のユーザは、２人のユーザが属する部署の管理者に合わせて特に調整されたダイナミック・コンテンツを含む、管理者用の会社メモを見る管理者とすることができる。管理者ごとにメモを生成し、キャッシングするのではなく、メモは、前に管理者の役割に関連付けられている。第１の管理者がメモにアクセスした後に、そのメモがキャッシングされ、同一カテゴリの他の管理者によるそのメモの取出の後続の試みが、キャッシュ・ヒットをもたらす。異なるカテゴリの他の管理者によるそのメモへのアクセスの後続の試みは、キャッシュ・ミスをもたらす。というのは、メモの２つの異なるバージョンが同一のＵＲＩに関連する場合であっても、後続の管理者が、異なるカテゴリ・クッキーを有するからである。
【０２６１】
クライアント・アプリケーションによって、ページ要求が生成され（ステップ８８２）、このページ要求が、第２ユーザに属する付随するカテゴリ・クッキーと共にサーバに送信される（ステップ８８４）。この場合に、中間キャッシュは、要求内のＵＲＩパスおよび関連するカテゴリ・クッキーによって識別される要求されたページのコピーを有し、したがって、キャッシュ・ヒットを有する（ステップ８８６）。中間キャッシュは、要求をサーバに転送せずに即座に要求されたページを返すことができ（ステップ８８８）、クライアントは、要求されたページを受信し、第２ユーザに提示する（ステップ８９０）。
【０２６２】
この形で、中間キャッシュによって、同一のフラグメントの複数のバージョンを実際に保管することができ、フラグメントの適当なバージョンが、ユーザのアサートされたカテゴリ・クッキーに基づいてユーザに返される、すなわち、カテゴリ・クッキーだけによって、そうでなければ類似するフラグメントの異なるバージョンの間での選択が決定される。フラグメントを区別するためのクッキーの使用のさらなる例を、特に買物客グループのカテゴリに関して下で提供する。
【０２６３】
単一メッセージ内の複数フラグメントの処理の効率向上
図４３に関して、流れ図によって、複数のフラグメントを単一の要求メッセージ内で指定でき、後に処理できるようにする処理を示す。図４３に示された処理は、図２７に示された処理と共に、または、特に複数のフラグメントを単一のフラグメントに組み合わせる前の、複数のフラグメントを得る必要がある処理と共に使用することができる。
【０２６４】
応答メッセージまたはキャッシュからフラグメントを得た後に、この処理は、「ｃｏｎｔａｉｎｓ−ｆｒａｇｍｅｎｔｓ」ディレクティブを検査して、それが葉フラグメントであるか、他のフラグメントを含むかを調べることによって開始される。他のフラグメントが含まれる場合に、元のフラグメントを構文解析して、含まれるフラグメントを見つける。
【０２６５】
すべての次レベル・フラグメントのソース識別子を収集した後に、単一のバッチ要求が生成される（ステップ９０４）。このバッチ要求に、フラグメントを得る際に使用されるバッチ・サーバ側プログラムすなわちサーブレットを含めることができる。このバッチ要求には、次レベル・フラグメントのソース識別子、たとえばＵＲＩのすべてが含まれる。ローカル・キャッシュが、これらの次レベル・フラグメントのすべてのキャッシュ・ヒットについて検査済みであり、次レベル・フラグメントのキャッシュ・ヒットがある場合に、そのフラグメントがバッチ要求に含まれないと仮定する。
【０２６６】
次に、バッチ要求メッセージが、サーバに送信され（ステップ９０６）、キャッシュ管理ユニットは、マルチパートＭＩＭＥ（Ｍｕｌｔｉｐｕｒｐｏｓｅ  Ｉｎｔｅｒｎｅｔ  Ｍａｉｌ  Ｅｘｔｅｎｓｉｏｎ）応答を受信するのを待つ（ステップ９０８）。要求についてスレッドを作成し、コンピューティング・デバイスが他の動作を実行している間に、そのスレッドが応答を待ってスリープすることが好ましい。
【０２６７】
応答を受信した後に、キャッシュ管理ユニットは、応答内の各フラグメントをステップ・スルーする。次のフラグメントを、マルチパート応答メッセージから取り出し（ステップ９１０）、キャッシングする（ステップ９１２）。マルチパート応答メッセージに処理すべきフラグメントがまだあるか否かに関する判定を行い（ステップ９１４）、そうである場合には、この処理は、ステップ９１０に分岐して、もう１つのフラグメントを処理する。そうでない場合には、新たに受信されたフラグメントを構文解析または検査して、これらのフラグメントに次レベル・フラグメントへのリンクが含まれるか否かを判定し（ステップ９１６）、そうである場合には、この処理は、ステップ９０２に分岐して、必要な場合にバッチ要求でさらにフラグメントを要求する。そうでない場合には、新たに受信したフラグメントを、ページ組立動作で組み合わせ（ステップ９１８）、処理が完了する。
【０２６８】
図４４に関して、流れ図によって、単一の要求メッセージを中間キャッシュ管理ユニットで受信し、後に処理できるようにする処理を示す。図４４に示された処理は、図３５に示された処理と共に、または要求メッセージを中間キャッシュで処理する他の処理と共に使用することができる。
【０２６９】
この処理は、バッチ要求が中間フラグメント・サポート式キャッシュで受信される時に開始される（ステップ９２２）。バッチ要求内のソース識別子の組が、ループで処理される。要求されたフラグメントの１つに関する次のソース識別子を、要求メッセージから取り出し（ステップ９２４）、ローカル・キャッシュでキャッシュ・ヒットがあるか否かに関する判定を行う（ステップ９２６）。キャッシュ・ヒットがない場合には、次のステップをスキップすることができ、キャッシュ・ヒットがある場合には、ソース識別子を、バッチ要求メッセージから除去することができる（ステップ９２８）。バッチ要求メッセージに処理すべきソース識別子がまだあるか否かに関する判定を行い（ステップ９３０）、そうである場合には、この処理はステップ９２４に分岐して、別のソース識別子を処理する。
【０２７０】
要求されたフラグメントのすべてがローカル・キャッシュ内で見つかったか否かに関する判定を行う（ステップ９３２）。そうである場合には、バッチ要求を転送する必要はなく、この処理は、応答メッセージの準備に分岐する。少なくとも１つのキャッシュ・ミスがある場合に、ソース識別子（１つまたは複数）を除去された修正されたバッチ要求を、サーバに転送する（ステップ９３４）。代替案では、単一の残りのソース識別子がある場合に、バッチ要求を通常の要求メッセージに変更することができる。キャッシュ管理ユニットは、マルチパートＭＩＭＥ応答の受信を待つ（ステップ９３６）が、要求についてスレッドが作成され、コンピューティング・デバイスが他の動作を実行している間に、スレッドが応答を待ってスリープすることが好ましい。
【０２７１】
応答を受信した後に、キャッシュ管理ユニットは、応答の各フラグメントをステップ・スルーする。次のフラグメントをマルチパート応答メッセージから取り出し（ステップ９３８）、ローカル・キャッシュにそのフラグメントをキャッシングすることが適当であると仮定して、そのフラグメントをキャッシングするし（ステップ９４０）。マルチパート応答メッセージに処理すべきフラグメントがまだあるか否かに関する判定を行い（ステップ９４２）、そうである場合には、この処理は、ステップ９３８に分岐して、別のフラグメントを処理する。新たに受信されたフラグメントが、これらのフラグメントに次レベル・フラグメントへのリンクが含まれるか否かに関する判定のために構文解析も検査もされないと仮定する。というのは、この処理が、元々のバッチ要求を生成したキャッシュ管理ユニットで実行されると仮定することができるからである。代替案では、この処理を、図４３で説明したものに類似する形で現在のキャッシュ管理ユニットで実行することができる。どの場合でも、マルチパートＭＩＭＥ応答が、元々のバッチ要求で受信されたソース識別子に対応するフラグメントを用いて生成され（ステップ９４４）、マルチパートＭＩＭＥ応答を返し（ステップ９４６）、これによって処理が完了する。
【０２７２】
図４５に関して、流れ図によって、複数のフラグメントに関するバッチ要求メッセージを処理するウェブ・アプリケーション・サーバでの処理を示す。図４５に示された処理は、フラグメント要求を満足できないフラグメント・サポート式キャッシュ管理ユニットを有する複数のコンピューティング・デバイス（すなわち、複数のデバイスがキャッシュ・ミスを有することができる）を通ってバッチ要求メッセージが流れた後で実行することができる。
【０２７３】
処理は、サーバでバッチ要求を受信することによって開始され（ステップ９５２）、このバッチ要求には、順番に処理される複数のフラグメント要求が含まれる。次のフラグメント要求が、バッチ要求メッセージから取り出され（ステップ９５４）、実行され（ステップ９５６）、この実行には、多分フラグメントの生成が含まれ、その後に、フラグメントを、任意選択として送信のためにフォーマットするかタグをつける必要がある場合がある（ステップ９５８）が、フラグメントが前にサーバでキャッシングされている場合がある。バッチ要求メッセージに別のフラグメント要求があるか否かに関する判定を行い（ステップ９６０）、そうである場合には、この処理は、別のフラグメント要求を処理するために分岐する。そうでない場合には、すべての要求されたフラグメントを有するマルチパートＭＩＭＥ応答メッセージを生成し（ステップ９６２）、応答メッセージを返し、これによって処理が完了する。
【０２７４】
キャッシュ・サイズ削減の例
図４６から４９に関して、本発明の好ましい実施形態を用いて達成できる有利なキャッシュ・サイズ削減を示す例の組を示す。特定の応用例で何がフラグメントを構成するかを選択する判断基準の１つが、あるコンテンツが異なるページにまたがって共用される頻度である。あるコンテンツが、激しく共用される場合に、それをフラグメントにすることによって、多数のページで繰り返すのではなく、フラグメントを１回だけキャッシングすることができるので、キャッシュのサイズを大きく考慮に入れることができる。したがって、フラグメントによって、キャッシュ・サイズを減らすための多数のページにまたがる圧縮の１形態がもたらされる。この圧縮の長所は、たとえば固定されたヒット率のキャッシュ・サイズの減少などのコスト削減、たとえば固定サイズ・キャッシュのヒット率の増加などの性能向上、またはこれらの組合せと見なすことができる。図４６から４９に、本発明の好ましい実施形態のさまざまな使用のシナリオと、同等の従来技術のシナリオと比較した、達成できるキャッシュ・サイズの削減を示す。
【０２７５】
図４６を参照すると、共用されるサイドバー（ｓｉｄｅｂａｒ）のシナリオが示されている。各ページに、サイドバー部分と他のページ部分が含まれ、従来技術によれば、各ページが、フラグメントをサポートしないキャッシュ内で、すべての従属オブジェクトを有する完全なページとして保管される。本発明の好ましい実施形態を用いると、各ページが、サイドバー・フラグメントと残りのページ・フラグメントを含むように構成され、これらのフラグメントのすべてが、フラグメントをサポートするキャッシュに保管される。明白なように、本発明の好ましい実施形態では、サイドバー・フラグメントが、１回だけ保管される。言い換えると、特定のサイトのすべてのページが、同一のサイドバー・フラグメントを共用する。サイドバーが各ページの２０％である場合に、すべてのページからこれを因数分解することによって、サイドバーが複製されないので、約２０％だけキャッシュ・サイズを減らすことができる。
【０２７６】
図４７を参照すると、買物客グループのシナリオが示されている。製品説明ページが、買物客グループごとに異なる価格を有するが、製品説明の残りは、買物客グループと独立である。従来技術によれば、製品および買い物客グループの組合せごとに製品ページがあり、これらの製品ページのそれぞれが、潜在的に、フラグメントをサポートしないキャッシュにキャッシングされる可能性がある。対照的に、本発明の好ましい実施形態によるフラグメントをサポートするキャッシュは、製品グループ組合せの価格データ・フラグメントと、製品記述フラグメントだけを保管する必要があり、ページ全体の組合せのすべてを保管する必要はない。
【０２７７】
潜在的な保管スペース節約は、次のように近似することができる。各価格が１００Ｂ（ｓ１）であり、製品説明の残りが１０ｋＢ（ｓ２）である。１００００個の製品（ｐ）と５つの買物客グループ（ｇ）がある。完全に展開されたページを保管する場合に、潜在的に、全体で（１００００×５）＝５００００（ｐ＊ｇ）個の項目があり、項目のサイズは約１０ｋＢである（ｓ２は、ｓ１＋ｓ２とほぼ等しい）、これは、合計約５０００００ｋＢ（ｐ＊ｇ＊ｓ２）のサイズを有する。その代わりに、製品説明の残りと別々のフラグメントに価格を保管する場合には、キャッシュ内にそれぞれ１０ｋＢ（ｓ２）の１００００（ｐ）個の製品フラグメントがあり、これは１０００００ｋＢ（ｐ＊ｓ２）のサイズを有し、さらに、それぞれ１００Ｂ（ｓ１）の１００００×５＝５００００（ｐ＊ｇ）の価格があり、これは５０００ｋＢのサイズを有する。フラグメントの総計は、この合計すなわち１０５０００ｋＢである。これは、フラグメントをサポートするキャッシュを実施した後のキャッシュ・サイズのほぼ５倍のサイズ削減である。
【０２７８】
図４８を参照すると、パーソナライゼーションのシナリオが示されている。製品説明ページに、パーソナライズされたセクションが含まれ、１００００個の製品（ｐ）と１０００００人のユーザ（ｕ）がある。従来技術によれば、完全に展開されたページを保管する場合に、キャッシュ内に潜在的に合計１００００×１０００００＝１０００００００００（ｕ＊ｐ）個の項目がある。
【０２７９】
対照的に、本発明の好ましい実施形態に従って実施されるフラグメント・サポート式キャッシュでは、ページを別々のフラグメントとして保管することができる。この場合に、キャッシュ内には、合計１００００＋１０００００＝１１００００（ｕ＋ｐ）個の項目だけがあり、各項目はより小さい。これは、約２００００倍のサイズ削減である。
【０２８０】
同一の例を続けると、ＳＲＣ属性によって、クッキー、たとえばｓｒｃ＝”ｃｏｏｋｉｅ：／／｛ｃｏｏｋｉｅ  ｎａｍｅ｝”またはＵＲＩ照会パラメータ、たとえばｓｒｃ＝”ｐａｒｍ：／／｛ｐａｒｍ  ｎａｍｅ｝”が識別されるＦＲＡＧＭＥＮＴＬＩＮＫタグを使用して、そのクッキーまたは照会パラメータの値を置換することができる。このシナリオでは、パーソナライゼーションが、クッキー値にするのに十分に小さい場合に、この変数置換を使用して、ウェブ・アプリケーション・サーバにパーソナライゼーション・フラグメントを要求し、それをキャッシングするオーバーヘッドを除去することができる。たとえば、「Ｈｅｌｌｏ，  Ｊｏｈｎ  Ｓｍｉｔｈ．    Ｗｅｌｃｏｍｅ  ｔｏ  ｏｕｒ  ｓｔｏｒｅ！！！」などの挨拶を、名前が「ｕｓｅｒＮａｍｅ」であり、値が「Ｊｏｈｎ  Ｓｍｉｔｈ」であるクッキーを用いて、下記のＨＴＭＬステートメントで実行することができる。
Hello, {fragmentlinksrc="cookie://userName"}.Welcome to our store!!!
【０２８１】
図４９を参照すると、株式ウォッチリストのシナリオが示されており、株式ウォッチリストは、多数のウェブ・ポータルで使用可能である。ページに、株式相場のパーソナライズされたリストが含まれる。このシナリオは、ユーザ固有情報が、インクルードされるフラグメントではなくトップレベル・フラグメントに関連することを除いて、パーソナライゼーションのシナリオに似ている。各ユーザは、株の別々のリストを有するが、各株は、多数のユーザ・リストによって共用される。１０００００人のユーザ（ｕ）と１０００個の株（ｓ）がある。各ユーザ記述は、１ｋＢ（ｓ１）であり、各株式相場は、１００Ｂ（ｓ２）である。ユーザは、平均１０個の株をリスト内に有する（ｌ）。完全に展開されたページを保管する場合に、キャッシュ・サイズは、１０００００＊１ｋＢ＝１０００００ＫＢ（ｕ＊ｓ１）と、１０００００＊１０＊１００Ｂ＝１０００００ｋＢ（ｕ＊ｌ＊ｓ２）の合計すなわち、総計２０００００ｋＢになる。そうではなく、個々の株式相場を別々のフラグメントとして保管する場合には、キャッシュ・サイズは、ユーザ固有フラグメントについて１０００００×１ｋＢ＝１０００００ｋＢ（ｕ＊ｓ１）と、株式相場フラグメントの１０００＊１００Ｂ＝１００ｋＢ（ｓ＊ｓ２）、合計１００１００ＫＢになる。これは、株式相場が複製されないので、約２倍のサイズ削減である。
【０２８２】
株式ウォッチリストのシナリオを、フラグメントのＦＯＲＥＡＣＨ機能を使用してさらに改善することができる。この場合には、すべてのユーザ固有フラグメントが除去される。これも、図４９に示されている。ＦＯＲＥＡＣＨ機能によって、「＝」によって区切られた名前／値対のスペースで区切られたリストを値に持つクッキーが指定される。名前／値対のそれぞれについて、ＵＲＩ照会パラメータとして名前／値対を追加されたフラグメントが生成される。このシナリオでは、「ｓｔｏｃｋｓ」という名前のクッキーが、たとえば「ｓｙｍｂｏｌ＝ＩＢＭ  ｓｙｍｂｏｌ＝ＣＳＣＯ  ｓｙｍｂｏｌ＝ＤＥＬＬ」など、値として株式シンボル・パラメータのリストを有する。これによって、クッキーの株式シンボルごとに１つの、３つのフラグメントが生成される。キャッシュのサイズは、単一のユーザ固有でないテンプレート・フラグメントの１ｋＢ（ｓ１）と、株式相場フラグメントの１００ｋＢ（ｓ＊ｓ２）、合計１０１ｋＢである。これは、ユーザ固有株式リスト・フラグメントが単一の株式リスト・フラグメントに置換されるので、約１０００倍のサイズ削減である。
【０２８３】
本発明の好ましい実施形態によって、キャッシュ内容を維持するのに必要な作業の量も減る。特定の応用例で何がフラグメントを構成するかを選択する判断基準の１つが、コンテンツの諸部分が変更される頻度である。コンテンツが、手動で毎回公開するには高すぎる頻度で変更される時には、アプリケーションによって、通常は、コンテンツを生成するためにデータベースにアクセスするテンプレート、たとえばＪＳＰ、ならびにデータベースが変更されるかタイム・リミットが満了する時にコンテンツを自動的に無効化する機構が使用される。このダイナミック・コンテンツ手法によって、人手がループから外され、頻繁な更新が可能になる。
【０２８４】
現在、ほとんどのキャッシュが、通常はダイナミック・コンテンツが示されるので、照会パラメータを有する要求をキャッシングしない。しかし、ダイナミック・コンテンツは、キャッシングのよい候補であることがしばしばである。コンテンツは、ある速度で変化する（たとえば、価格が週ごとに変更される場合があり、ミューチュアル・ファンドが毎日変更され、株価が数分ごとに変化する）が、変更の間に多数のキャッシュ・ヒットがあり、キャッシングが、しばしばかなりの性能向上を提供する可能性がある。
【０２８５】
コンテンツがすばやく変更され得る時に、各変更によって引き起こされる作業を減らすことが重要になる。ページをフラグメントに分割することによって、コンテンツの増分生成が可能になる。変更が発生する時に、これらのページのみのこれらの部分だけが、直接に影響を受けて、もう一度生成されなければならない。あるコンテンツがすばやく変化する場合に、それを別々のフラグメントにすることができる。
【０２８６】
図４６のサイドバーのシナリオをもう一度参照すると、サイドバーに、たとえばニュースの見出しなど、数分ごとに変更されるコンテンツが含まれる。完全に展開されたページが保管される場合に、サイドバーが変更される時に、すべてのページをもう一度生成し、置換しなければならない。そうではなく、サイドバーが別々のフラグメントである場合には、サイドバーが変更される時に、１つのフラグメントだけを生成し、置換すればよい。
【０２８７】
図４７の買物客グループのシナリオをもう一度参照すると、買物客グループの価格は、買物客グループ内の販売量に基づいて、毎分変更される可能性がある。完全に展開されたページが保管される場合に、５００００ページのすべてを、毎分生成しなければならない。これは、毎分５０００００ｋＢのキャッシュの生成および置換を引き起こす。その代わりに、価格を別々のフラグメントとして保管する場合には、５００００個のフラグメントが生成され、置換されるが、５０００ｋＢのキャッシュだけが、生成され、置換される。これは、必要な帯域幅の１００倍の削減である。製品説明の価格以外の態様が変更される場合には、５ページではなく、１つのフラグメントだけを生成し、置換する必要がある。これは、帯域幅の５倍の削減である。
【０２８８】
図４８のパーソナライゼーションのシナリオをもう一度参照すると、製品が、数分ごとに変更される可能性があり、ユーザ固有のパーソナライゼーションが、毎日変更される可能性がある。展開されたページをキャッシングする場合に、各製品の変更によって、その製品に関する１０００００ページのすべてが生成され、置換され、各パーソナライゼーションの変更によって、そのユーザに関する１００００ページのすべてが生成され、置換される。その代わりに、製品説明およびパーソナライゼーションが、別々のフラグメントに保管される場合には、各製品の変更が、１つのフラグメントだけの生成および置換を引き起こし（１０００００倍の改善）、各パーソナライゼーションの変更が、１つのフラグメントだけの生成および置換を引き起こす（１００００倍の改善）。
【０２８９】
図４９の株式ウォッチリストのシナリオをもう一度参照すると、株価は、２０秒ごとに変化する可能性がある。展開されたページがキャッシュに保管される場合には、１０００００個のユーザ・ページのすべて（１０００００ｋＢ）を、２０秒ごとに生成しなければならない。その代わりに、株式を別々のフラグメントとして保管する場合には、１０００個の株式フラグメントだけ（１００ｋＢ）を、２０秒ごとに生成し、置換しなければならない。これは、帯域幅の１０００倍以上の改善である。単一のユーザの株式ウォッチリストが修正される、たとえば、ユーザが、ウォッチリストに株式を追加するか削除する場合に、どちらの場合でも、１つのフラグメントだけを生成し、置換する必要がある。
【０２９０】
フラグメント・キャッシュ識別子の生成および使用の例
上で説明したように、各フラグメントをキャッシングする方法を指示するキャッシング情報が、そのフラグメントに関連する。静的コンテンツの場合に、キャッシング情報は、各フラグメントに関連する。ダイナミック・コンテンツは、テンプレートまたはプログラム（ＪＳＰ、ＣＧＩなど）によって生成され、キャッシング情報は、このテンプレートに関連する。これは、一定の情報とすることができ、その結果、テンプレートによって生成されるすべてのフラグメントが、同一の値を有するようになる。その代わりに、テンプレートが、キャッシング情報を決定するコードを有することができ、その結果、キャッシング情報が、あるアルゴリズムに基づいて、生成されるフラグメントごとに異なるものになる。どちらの場合でも、特定のフラグメントは、一定の値を有する。
【０２９１】
フラグメントは、コンテンツの別の部分と組み合わせるために区切られた、コンテンツの部分として定義することができる。標準化されたフラグメント命名技法が、本発明の好ましい実施形態で使用される。この技法では、上で形式的に説明した技法に従ってキャッシュＩＤが生成される。このセクションでは、下でさらに一連の例を介してキャッシュＩＤの使用を説明するが、キャッシュＩＤの形成および決定の短い要約を、まず示す。
【０２９２】
キャッシュでは、ある形でキャッシュＩＤを使用してフラグメントが保管される。キャッシュＩＤに、キャッシュを使用するすべてのアプリケーションの間で一意になるのに十分な情報が含まれなければならない。たとえば、製品ＩＤだけでは、別の店の製品ＩＤまたは完全に別のものと衝突する可能性がある。フラグメントのＵＲＩパスによって、通常は、少なくとも部分的にこれと同一の名前スコーピング問題に対処しなければならないので、フラグメントのキャッシュＩＤの一部としてＵＲＩパスを含めることが便利である。
【０２９３】
キャッシュＩＤの情報内容によって、下記の例に示されているように、フラグメントがどれほど幅広く共用されるかが決定される。
（Ａ）ユーザＩＤがキャッシュＩＤに含まれる場合に、そのフラグメントは、そのユーザだけのために使用される。
（Ｂ）買物客グループＩＤがキャッシュＩＤに含まれる場合に、そのフラグメントは、その買物客グループのすべてのメンバの間で共用される。
（Ｃ）ユーザＩＤおよび買い物客グループＩＤの両方がキャッシュＩＤに含まれない場合に、そのフラグメントは、すべてのユーザの間で共用される。
【０２９４】
ウェブ・アプリケーション開発者は、フラグメントのキャッシュＩＤに何が含まれるかを指示するＣＡＣＨＥＩＤディレクティブを有するフラグメントのＨＴＴＰ  ＦＲＡＧＭＥＮＴヘッダ内の規則によって、キャッシュＩＤの情報内容を指定することができる。規則を用いると、ＵＲＩ照会パラメータまたはクッキーをＵＲＩパスに付加できるようになり、あるいは、フルＵＲＩ（照会パラメータを含む）が可能になる。規則の不在は、キャッシングなしを意味しない。複数の規則が使用される時には、規則が、出現順で試行される。働く最初の規則によって、キャッシュＩＤが決定される。どの規則も働かない場合には、フラグメントはキャッシングされない。照会パラメータまたはクッキーがキャッシュＩＤに含まれる時に、これを、次のように、必須または任意選択のいずれかとすることができる。
（Ａ）親の要求に存在しない必須照会パラメータによって、規則が失敗になる。
（Ｂ）親の要求または結果に存在しない必須クッキーによって、規則が失敗になる。
（Ｃ）存在しない任意選択の照会パラメータまたはクッキーは、キャッシュＩＤに含まれない。
【０２９５】
キャッシュＩＤは、なんらかの標準規格で大文字小文字を区別しないと宣言された部分以外は、大文字小文字の区別がある。ＨＴＴＰ仕様では、ＵＲＩのプロトコルおよびホスト名が、大文字小文字の区別がないが、ＵＲＩの残りは、照会パラメータ名を含めて大文字小文字の区別があるとされている。仕様書、「HTTP State Management Mechanism」、RFC 2109、Internet Engineering TaskForce、1997年2月によれば、クッキー名は、大文字小文字の区別がない。キャッシュ実施形態では、これらの大文字小文字の区別がない部分を、大文字小文字のどちらかに均一に変換することによって、簡単にこれを実施することができる。本発明の好ましい実施形態のフラグメント・キャッシング技法では、照会パラメータ値およびクッキー値を大文字小文字の区別があるものとすることが好ましい。
【０２９６】
図５０から５７に関して、一連の図を使用して、本発明の好ましい実施形態の教示によって、フラグメントの保管および処理のために一意のキャッシュ識別子が構成され、使用される形を示す。
【０２９７】
図５０を参照すると、あるサイトのすべての親フラグメントに、同一のサイドバー子フラグメントが含まれる。親フラグメントは、このシナリオでは、すべての親に同一のサイドバー・フラグメントが含まれること以外は指定されず、したがって、子フラグメントだけが問題になる。子フラグメントは、そのＵＲＩによって論理的に修飾される。これは静的コンテンツなので、キャッシュＩＤはフルＵＲＩである。キャッシュＩＤ規則は次の通りである。
Fragment:cacheid="URI"
【０２９８】
言い換えると、キャッシュＩＤは、すべての照会パラメータを含むフルＵＲＩである。キャッシュＩＤの例を示す。
http://www.acmeStore.com/sidebar.html
【０２９９】
図５１を参照すると、製品説明ページに、組込みフラグメントまたは子フラグメントが含まれない、すなわち、このページは、唯一のフラグメントである。これは、ｐｒｏｄｕｃｔＩＤによって論理的に修飾される。ページＵＲＩは、ｐｒｏｄｕｃｔＩＤ照会パラメータを有する。ページ要求は、ログオン中にウェブ・アプリケーション・サーバによって作成される暗号化されたｕｓｅｒＩＤクッキーを有する。ｕｓｅｒＩＤクッキーによって、ユーザ固有状態（ショッピング・カート、ユーザ・プロファイルなど）をユーザに関連付けられるようになる。ｕｓｅｒＩＤは、照会パラメータではなくクッキーとして使用される。というのは、これがほとんどすべての要求で使用される可能性があり、ウェブ・アプリケーション開発者がすべてのリンクにこれを置くことが、単調で退屈になるからである。製品ページの単一のキャッシュＩＤ規則では、キャッシュＩＤとして、ｐｒｏｄｕｃｔＩＤ照会パラメータを含むフルＵＲＩが使用され、その結果、正しい修飾を用いてキャッシングできるようになる。この単一フラグメント・ページについて、キャッシュＩＤをそのＵＲＩとすることができる。キャッシュＩＤ規則を示す。
Fragment:cacheid="URI"
【０３００】
言い換えると、キャッシュＩＤは、すべての照会パラメータを含むフルＵＲＩである。キャッシュＩＤの例を示す。
http://www.acmeStore.com/productDesc.jsp?productID=AT13394
【０３０１】
このトップレベル・フラグメントのキャッシュＩＤを指定するもう１つの形は、ＵＲＩ照会パラメータである、商人によって使用される製品ＩＤ、たとえばＡＴ１３３９４と、一意性を保証する一定のＵＲＩパス、たとえばｈｔｔｐ：／／ｗｗｗ．ａｃｍｅＳｔｏｒｅ．ｃｏｍ／ｐｒｏｄｕｃｔＤｅｓｃである。この場合に、キャッシュＩＤ規則は次のようになる。
Fragment:cacheid="(productId)"
【０３０２】
言い換えると、キャッシュＩＤは、下記の部分を一緒に連結したものである。
（Ａ）ＵＲＩパス
（Ｂ）ｐｒｏｄｕｃｔＩＤ照会パラメータの名前および値
【０３０３】
規則に角型括弧がないことによって、ｐｒｏｄｕｃｔＩＤパラメータが存在しなければならないことが示される。これが存在しないと、規則が失敗し、フラグメントがキャッシングされなくなる。キャッシュＩＤの例を示す。
http://www.acmeStore.com/productDesc.jsp_productID=AT13394
【０３０４】
やはり、ウェブ・アプリケーション設計者が、正確なフォーマットではなく、キャッシュＩＤの情報内容だけを指定することに留意されたい。キャッシュ実施形態では、指定された情報内容をキャッシュＩＤにエンコードする、それ自体の形を選択することができる。上の例では、区切り文字として下線文字（「＿」）を用いる単純な連結が使用されている。ウェブ・アプリケーション開発者は、このエンコーディングを知る必要がない。
【０３０５】
図５２を参照すると、製品説明のシナリオの拡張が示されている。価格が、ユーザが属する買物客グループによって決定されるが、製品説明の残りは、買物客グループと独立である。親製品説明フラグメントに、子価格フラグメントが含まれる。親は、ｐｒｏｄｕｃｔＩＤによって論理的に修飾される。子は、ｐｒｏｄｕｃｔＩＤおよびｇｒｏｕｐＩＤによって論理的に修飾される。ページＵＲＩは、ｐｒｏｄｕｃｔＩＤ照会パラメータを有する。ページ要求は、暗号化されたｕｓｅｒＩＤクッキーおよびｇｒｏｕｐＩＤクッキーを有する。ｇｒｏｕｐＩＤクッキーは、ログオン中にユーザ・プロファイルに基づいてウェブ・アプリケーションによって作成される。ｇｒｏｕｐＩＤは、ほとんどすべての要求で使用される可能性があり、ウェブ・アプリケーション開発者がすべてのリンクにこれを置くことが、単調で退屈になるので、照会パラメータではなくクッキーにされる。
【０３０６】
価格は、親によってインクルードされる別々の子フラグメントにしなければならない。親フラグメントに関する単一のキャッシュＩＤ規則は、製品表示のシナリオと同一である。子フラグメントに関する単一のキャッシュＩＤ規則では、ｐｒｏｄｕｃｔＩＤ照会パラメータおよびｇｒｏｕｐＩＤクッキーと共にＵＲＩパスを使用し、その結果、正しい修飾を用いてキャッシングできるようになる。フラグメントは、同一の買物客グループに属するすべてのユーザではなく単一のユーザによってのみ使用可能であり、これによって、はるかに大きいキャッシュおよびキャッシュを更新された状態に保つより多くの作業がもたらされるので、キャッシュＩＤにユーザＩＤが含まれないことに留意されたい。キャッシュＩＤ規則は、次のようになる。
Fragment:cacheid="(productID, [groupID])"
【０３０７】
言い換えると、キャッシュＩＤは、下記の部分を一緒に連結したものになる。
（Ａ）ＵＲＩパス
（Ｂ）ｐｒｏｄｕｃｔＩＤ照会パラメータの名前および値
（Ｃ）要求に存在する場合に、ｇｒｏｕｐＩＤクッキーの名前および値
【０３０８】
コンマによって、ＵＲＩ照会パラメータがクッキーから分離される。規則の角型括弧によって、クッキーが任意選択であることが示される。このクッキーが存在しない場合に、規則はそれでも成功し、キャッシュＩＤに、クッキーの名前／値対が含まれなくなる。これによって、商人が、非グループ価格ならびにグループごとの価格を有することが可能になる。キャッシュＩＤの例を示す。
http://www.acmeStore.com/productDesc.jsp_productID=AT13394_groupID=* @#!
【０３０９】
図５３を参照すると、買物客グループ・シナリオの拡張が示されている。複数の商人のサポートが追加されており、たとえば、アプリケーション・サービス・プロバイダ（ＡＳＰ）が、同一のウェブ・アプリケーション・サーバで複数の言語を使用する複数の商人をサポートする。親製品説明フラグメントに、やはり子価格フラグメントが含まれる。親は、ｐｒｏｄｕｃｔＩＤ、ｍｅｒｃｈａｎｔＩＤ、およびｌａｎｇｕａｇｅＩＤによって論理的に修飾される。子は、ｐｒｏｄｕｃｔＩＤ、ｇｒｏｕｐＩＤ、ｌａｎｇｕａｇｅＩＤ、およびｍｅｒｃｈａｎｔＩＤによって論理的に修飾される。ページＵＲＩは、ｐｒｏｄｕｃｔＩＤ照会パラメータおよびｍｅｒｃｈａｎｔＩＤ照会パラメータを有する。要求は、ｕｓｅｒＩＤクッキー、ｇｒｏｕｐＩＤクッキー、およびｌａｎｇｕａｇｅＩＤクッキーを有する。ｌａｎｇｕａｇｅＩＤクッキーは、ログオン中にユーザ・プロファイルに基づいてウェブ・アプリケーションによって作成される。ｌａｎｇｕａｇｅＩＤは、すべての要求で使用され、ウェブ・アプリケーション開発者がすべてのリンクにこれを置くことが、単調で退屈になるので、照会パラメータではなくクッキーにされる。
【０３１０】
親フラグメントの単一のキャッシュＩＤ規則では、ｐｒｏｄｕｃｔＩＤおよびｍｅｒｃｈａｎｔＩＤ照会パラメータ、ならびにｌａｎｇｕａｇｅＩＤクッキーと共にＵＲＩパスを使用し、したがって、正しい修飾を用いてキャッシングできるようになる。親キャッシュＩＤ規則は、次のようになる。
Fragment:cacheid="(productID merchantID, [languageID])"
【０３１１】
言い換えると、キャッシュＩＤは、下記の部分を一緒に連結したものになる。
（Ａ）ＵＲＩパス
（Ｂ）ｐｒｏｄｕｃｔＩＤ照会パラメータの名前および値
（Ｃ）ｍｅｒｃｈａｎｔＩＤ照会パラメータの名前および値
（Ｄ）要求に存在する場合に、ｌａｎｇｕａｇｅＩＤクッキーの名前および値
【０３１２】
親キャッシュＩＤの例を示す。
http://www.acmeMall.com/productDesc.jsp_productID=ATl3394_merchantID=MyStore_languageID=eng
【０３１３】
子フラグメントの単一のキャッシュＩＤ規則では、ｐｒｏｄｕｃｔＩＤおよびｍｅｒｃｈａｎｔＩＤ照会パラメータならびにｇｒｏｕｐＩＤおよび任意選択のｌａｎｇｕａｇｅＩＤクッキーと共にＵＲＩを使用し、したがって、正しい修飾を用いてキャッシングすることができる。キャッシュＩＤ規則は、次のようになる。
Fragment: cacheid="(productIDmerchantID,[groupID] [languageID])"
【０３１４】
言い換えると、キャッシュＩＤは、下記の部分を一緒に連結したものになる。
（Ａ）ＵＲＩパス
（Ｂ）ｐｒｏｄｕｃｔＩＤ照会パラメータの名前および値
（Ｃ）ｍｅｒｃｈａｎｔＩＤ照会パラメータの名前および値
（Ｄ）要求に存在する場合に、ｇｒｏｕｐＩＤクッキーの名前および値
（Ｅ）要求に存在する場合に、ｌａｎｇｕａｇｅＩＤクッキーの名前および値
キャッシュＩＤの例を示す。
http://www.acmeMall.com/productDesc.jsp_productID=AT13394_merchantID=MyStore_groupID=*@#!_languageID=eng
【０３１５】
図５４を参照すると、ＡＳＰおよび複数言語のシナリオの拡張が示されている。製品を識別する複数の形のサポートが追加されている。親製品説明フラグメントに、子価格フラグメントが含まれる。親は、製品（これを指定する２つの形がある）、ｌａｎｇｕａｇｅＩＤ、およびｍｅｒｃｈａｎｔＩＤによって論理的に修飾される。子は、製品、ｇｒｏｕｐＩＤ、ｌａｎｇｕａｇｅＩＤ、およびｍｅｒｃｈａｎｔＩＤによって論理的に修飾される。製品は、ｐｒｏｄｕｃｔＩＤ照会パラメータによって、またはｐａｒｔＮｕｍｂｅｒ照会パラメータおよびｓｕｐｐｌｉｅｒＮｕｍｂｅｒ照会パラメータによってのいずれかで識別される。要求は、ｕｓｅｒＩＤクッキー、ｇｒｏｕｐＩＤクッキー、およびｌａｎｇｕａｇｅＩＤクッキーを有する。親フラグメントは、下記のように指定される２つの規則を必要とする。
Fragment: cacheid=
"(productID merchantID, [languageID])
(partNumbersupplierNumber merchantID, [languageID])"
【０３１６】
第１の規則が試行される。それに成功した場合には、それによってキャッシュＩＤが決定される。失敗の場合には、第２の規則が試行される。第２の規則が成功の場合には、それによってキャッシュＩＤが決定される。失敗の場合には、フラグメントはキャッシングされない。第１の規則は、キャッシュＩＤが下記の部分を一緒に連結したものであることを意味する。
（Ａ）ＵＲＩパス
（Ｂ）ｐｒｏｄｕｃｔＩＤ照会パラメータの名前および値
（Ｃ）ｍｅｒｃｈａｎｔＩＤ照会パラメータの名前および値
（Ｄ）要求に存在する場合に、ｌａｎｇｕａｇｅＩＤクッキーの名前および値
第１の規則のキャッシュＩＤの例を示す
http://www.acmeStore.com/productDesc.jsp_productID=AT13394_merchantID=MyStore_languageID=eng
【０３１７】
第２の規則は、キャッシュＩＤが下記の部分を一緒に連結したものであることを意味する。
（Ａ）ＵＲＩパス
（Ｂ）ｐａｒｔＮｕｍｂｅｒ照会パラメータの名前および値
（Ｃ）ｓｕｐｐｌｉｅｒＮｕｍｂｅｒ照会パラメータの名前および値
（Ｄ）ｍｅｒｃｈａｎｔＩＤ照会パラメータの名前および値
（Ｅ）要求に存在する場合に、ｌａｎｇｕａｇｅＩＤクッキーの名前および値
【０３１８】
第２の規則のキャッシュＩＤの例を示す
http://www.acmeStore.com/productDesc.jsp_partNumber=22984Z_supplierNumber=339001_merchantID=MyStore_languageID=eng
【０３１９】
子フラグメントは、下記のように指定される２つの規則を必要とする
Fragment: cacheid=
"(productIDmerchantID, [groupID] [languageID])
(partNumbersupplierNumber merchantID, [groupID] [languageID])"
【０３２０】
第１の規則が試行される。それに成功した場合には、それによってキャッシュＩＤが決定される。失敗の場合には、第２の規則が試行される。第２の規則が成功の場合には、それによってキャッシュＩＤが決定される。失敗の場合には、フラグメントはキャッシングされない。第１の規則は、キャッシュＩＤが下記の部分を一緒に連結したものであることを意味する。
（Ａ）ＵＲＩパス
（Ｂ）ｐｒｏｄｕｃｔＩＤ照会パラメータの名前および値
（Ｃ）ｍｅｒｃｈａｎｔＩＤ照会パラメータの名前および値
（Ｄ）要求に存在する場合に、ｇｒｏｕｐＩＤクッキーの名前および値
（Ｅ）要求に存在する場合に、ｌａｎｇｕａｇｅＩＤクッキーの名前および値
【０３２１】
第１の規則のキャッシュＩＤの例を示す。
http://www.acmeStore.com/productDesc.jsp_productID=AT13394_merchantID=MyStore_groupID=*@#!_languageID=eng
【０３２２】
第２の規則は、キャッシュＩＤが下記の部分を一緒に連結したものであることを意味する。
（Ａ）ＵＲＩパス
（Ｂ）ｐａｒｔＮｕｍｂｅｒ照会パラメータの名前および値
（Ｃ）ｓｕｐｐｌｉｅｒＮｕｍｂｅｒ照会パラメータの名前および値
（Ｄ）ｍｅｒｃｈａｎｔＩＤ照会パラメータの名前および値
（Ｅ）ｇｒｏｕｐＩＤクッキーの名前および値
（Ｆ）ｌａｎｇｕａｇｅＩＤクッキーの名前および値
【０３２３】
第２の規則のキャッシュＩＤの例を示す。
http://www.acmeStore.com/productDesc.jsp_partNumber=22984Z_supplierNumber=339001_merchantID=MyStore_groupID=*@#!_language=eng
【０３２４】
図５５を参照すると、製品説明シナリオの、パーソナライゼーションを使用する拡張が示されている。親製品説明フラグメントに、子パーソナライゼーション・フラグメントが含まれる。親フラグメントは、ｐｒｏｄｕｃｔＩＤによって論理的に修飾される。子フラグメントは、ｕｓｅｒＩＤによって論理的に修飾される。ページＵＲＩは、ｐｒｏｄｕｃｔＩＤ照会パラメータを有する。要求は、ｕｓｅｒＩＤクッキーを有する。
【０３２５】
親キャッシュＩＤに、ｐｒｏｄｕｃｔＩＤ照会パラメータが含まれる。親フラグメントのキャッシュＩＤ規則は、下記の２つの事例のいずれかになる。
Fragment:cacheid="URI"
【０３２６】
言い換えると、このキャッシュＩＤは、すべての照会パラメータを有するフルＵＲＩである。もう１つの潜在的な規則は、次のようになる。
Fragment:cacheid="(productId)"
【０３２７】
言い換えると、このキャッシュＩＤは、下記の部分を一緒に連結したものになる。
（Ａ）ＵＲＩパス
（Ｂ）ｐｒｏｄｕｃｔＩＤ照会パラメータの名前および値
【０３２８】
このページに関する要求に、ｕｓｅｒＩＤクッキーが含まれるが、フラグメントが製品固有であってユーザ固有ではないので、両方のフラグメントのキャッシュＩＤにｕｓｅｒＩＤが含まれないことに留意されたい。含まれる場合には、このフラグメントが、そのユーザだけによってアクセス可能になり、より大きいキャッシュとキャッシュを更新された状態に保つより多くの作業がもたらされる。キャッシュＩＤの例を示す。
http://www.acmeStore.com/productDesc.jsp_productID=AT13394
【０３２９】
子パーソナライゼーション・フラグメントのキャッシュＩＤには、ｕｓｅｒＩＤクッキーが含まれる。子フラグメントのキャッシュＩＤを示す。
Fragment:cacheid="(, userId)"
【０３３０】
言い換えると、キャッシュＩＤは、下記の部分を一緒に連結したものになる。
（Ａ）ＵＲＩパス
（Ｂ）ｕｓｅｒＩＤクッキーの名前および値
キャッシュＩＤの例を示す。
http://www.acmeStore.com/personalization.jsp_userID=@($*!%
【０３３１】
このパーソナライゼーションの例では、パーソナライゼーション・フラグメントを、たとえば「Ｃａｃｈｅ−Ｃｏｎｔｒｏｌ：ｐｒｉｖａｔｅ」を使用して、プライベート・データとしてマークしなければならない。
【０３３２】
図５６を参照すると、単一のポータル・ページの親株式ウォッチリスト・フラグメントに、複数の子株式相場フラグメントが含まれる。親フラグメントには、単純なパーソナライゼーションとして、ユーザの名前が含まれる。親は、ｕｓｅｒＩＤによって論理的に修飾される、すなわち、株式シンボルのリストは、ユーザ固有である。ユーザ名は、ｕｓｅｒＩＤによって論理的に修飾される。各子は、株式シンボルによって論理的に修飾される、すなわち、株の値は、ユーザ固有でない。ページＵＲＩに、照会パラメータは含まれない。要求は、ｕｓｅｒＩＤクッキーを有する。
【０３３３】
トップレベル・フラグメントに、株式相場の要求されるユーザ固有リストが含まれる。トップレベル・フラグメントのＵＲＩに、照会パラメータは含まれない。トップレベル・フラグメントのキャッシュＩＤに、ｕｓｅｒＩＤという名前の暗号化されたクッキーが含まれる。キャッシュＩＤ規則は、次のようになる。
Fragment:cacheid="(, userId)"
【０３３４】
言い換えると、キャッシュＩＤは、下記の部分を一緒に連結したものになる。
（Ａ）ＵＲＩパス
（Ｂ）ｕｓｅｒＩＤクッキーの名前および値
【０３３５】
キャッシュＩＤの例を示す
http://www.acmeInvest.com/stockList.jsp_userID=@($*!%
【０３３６】
株式相場フラグメントのそれぞれについて、キャッシュＩＤに、「シンボル」パラメータが含まれる。キャッシュＩＤ規則は、フルＵＲＩか、ＵＲＩパスにｓｔｏｃｋＳｙｍｂｏｌ照会パラメータを加えたものになる。
Fragment:cacheid="(stockSymbol)"
【０３３７】
言い換えると、キャッシュＩＤは、下記の部分を一緒に連結したものになる。
（Ａ）ＵＲＩパス
（Ｂ）シンボル照会パラメータの名前および値
【０３３８】
キャッシュＩＤの例を示す
http://www.acmeInvest.com/stockQuote.jsp_stockSymbol=IBM
【０３３９】
このシナリオを修正して、ＦＯＲＥＡＣＨ機能を使用することができ、株式相場フラグメントは変更されないが、親フラグメントを非常に最適化することができる。静的トップレベル・フラグメントが１つだけある。ｓｔｏｃｋＳｙｍｂｏｌｓクッキーが使用され、その値は、ユーザに関する株式シンボルの、空白によって区切られたリストである。すべてのユーザについて、非常に静的な１つの親フラグメントだけがあり、この親フラグメントに、そのＦＯＲＥＡＣＨ属性によってｓｔｏｃｋＳｙｍｂｏｌｓクッキーの名前が指定されるＦＲＡＧＭＥＮＴＬＩＮＫタグが含まれる。これによって、株式シンボルが照会パラメータとして追加されたＦＯＲＥＡＣＨ属性を含むＦＲＡＧＭＥＮＴＬＩＮＫのＳＲＣと同一のＳＲＣ属性を有する株式シンボルごとの単純なＦＲＡＧＭＥＮＴＬＩＮＫタグが動的に生成される。この親フラグメントは、すべてのユーザについて同一なので、そのＵＲＩをキャッシュＩＤとして使用し、照会パラメータがない、下記のような単一のキャッシュ規則による正しい修飾を用いてキャッシングすることができる。
Fragment:cacheid="URI"
【０３４０】
ｓｔｏｃｋＳｙｍｂｏｌｓクッキーに、親フラグメントに関するすべてのユーザ固有情報が含まれ、ｓｔｏｃｋＳｙｍｂｏｌｓクッキーは、ページ要求と共に移動し、したがって、親の論理ｕｓｅｒＩＤ修飾を満足する。
【０３４１】
ユーザの名前を値として有するｕｓｅｒＮａｍｅクッキーが、ＳＲＣ属性によってuserNameクッキーが識別される単純なパーソナライゼーションのためにＦＲＡＧＭＥＮＴＬＩＮＫタグで使用される。このフラグメントは、ｕｓｅｒＮａｍｅクッキーから簡単に生成できるので、キャッシングされない。ｕｓｅｒＮａｍｅクッキーには、このフラグメントに関するすべてのユーザ関連情報が含まれ、ｕｓｅｒＮａｍｅクッキーは、ページ要求と共に移動し、したがって、親の論理ｕｓｅｒＩＤ修飾を満足する。子フラグメントの単一のキャッシュＩＤ規則では、キャッシュＩＤについてそのＵＲＩを使用し、その結果、次のように正しい修飾を用いてキャッシングできるようになる。
Fragment:cacheid="URI"
【０３４２】
この株式ウォッチリストのシナリオでは、ＦＯＲＥＡＣＨ機能が使用されない時に、トップレベル株式ウォッチリスト・フラグメントが、たとえば「Ｃａｃｈｅ−Ｃｏｎｔｒｏｌ：ｐｒｉｖａｔｅ」を使用して、プライベートとマークされる。ＦＯＲＥＡＣＨ機能が使用される時には、共用されるトップレベル・フラグメントが１つだけあり、したがって、これはプライベートとマークされない。
【０３４３】
図５７を参照し、この例によって、ｍｙＹａｈｏｏ！などのパーソナライズされたポータル・ページに似たシナリオを示す。第１レベル・ポータル・フラグメントに、株式、天気、スポーツなど、それぞれに複数の葉項目フラグメントが含まれる複数の中間レベル・トピック・フラグメントが含まれる。親フラグメントには、ユーザの名前も含まれる。トップレベル・ポータル・フラグメントは、ｕｓｅｒＩＤによって論理的に修飾される、すなわち、トピックのリストは、ユーザ固有である。ユーザ名は、ｕｓｅｒＩＤによって論理的に修飾される。中間レベル・トピック・フラグメントは、ｔｏｐｉｃＩＤおよびｕｓｅｒＩＤによって論理的に修飾される、すなわち、トピック内の項目のリストは、ユーザ固有である。葉項目フラグメントは、ｉｔｅｍＩＤによって論理的に修飾される、すなわち、項目の値は、ユーザ固有でない。ページＵＲＩに、照会パラメータは含まれない。ページ要求は、ｕｓｅｒＩＤクッキーを有する。ＦＯＲＥＡＣＨ機能の使用を介して、親フラグメントを非常に最適化することができる。
【０３４４】
ＦＯＲＥＡＣＨ機能を使用すると、ユーザに関するｔｏｐｉｃＩＤの空白で区切られたリストを値として有するｔｏｐｉｃｓクッキー（ログオン中にユーザ・プロファイルに基づいて作成される）が、使用される。すべてのユーザについて、非常に静的であり、ｔｏｐｉｃｓクッキーの名前を指定するＦＯＲＥＡＣＨ属性を有するＦＲＡＧＭＥＮＴＬＩＮＫタグを含む親フラグメントが、１つだけある。これによって、ｔｏｐｉｃＩＤごとに単純なＦＲＡＧＭＥＮＴＬＩＮＫが動的に生成され、そのＳＲＣ属性は、ｔｏｐｉｃＩＤを照会パラメータとして付加されたＦＯＲＥＡＣＨ属性を含むＦＲＡＧＭＥＮＴＬＩＮＫのＳＲＣと同一である。この親フラグメントは、すべてのユーザについて同一なので、下記のように照会パラメータを有しない、キャッシュＩＤとしてＵＲＩを使用する単一のキャッシュ規則を有する正しい修飾によってキャッシングすることができる。
Fragment:cacheid="URI"
【０３４５】
ｔｏｐｉｃｓクッキーに、親フラグメントのユーザ固有情報のすべてが含まれ、ｔｏｐｉｃｓクッキーは、ページ要求と共に移動し、したがって、親の論理ｕｓｅｒＩＤ修飾を満足する。ユーザの名前である値を有するｕｓｅｒＮａｍｅクッキーが、ｕｓｅｒＮａｍｅクッキーを識別するＳＲＣ属性を有する単純なパーソナライゼーションのＦＲＡＧＭＥＮＴＬＩＮＫで使用される。このフラグメントは、ｕｓｅｒＮａｍｅクッキーから簡単に生成できるので、キャッシングされない。ｕｓｅｒＮａｍｅクッキーに、このフラグメントのユーザ固有情報のすべてが含まれ、ｕｓｅｒＮａｍｅクッキーは、ページ要求と共に移動し、したがって、親の論理ｕｓｅｒＩＤ修飾を満足する。
【０３４６】
トピックごとに、トピック・フラグメントがある。ＦＯＲＥＡＣＨ機能のゆえに、トピック・フラグメントのそれぞれを、非常に最適化することができる。トピックごとに、ユーザおよびトピックのｉｔｅｍＩＤの空白で区切られたリストを値として有するクッキー（ログオン中にユーザ・プロファイルに基づいて作成される）が使用される。トピックごとに、非常に静的であり、そのトピックの対応するクッキーの名前を指定するＦＯＲＥＡＣＨ属性を有するＦＲＡＧＭＥＮＴＬＩＮＫを含む、すべてのユーザに関するトピック・フラグメントが１つだけある。これによって、ｉｔｅｍＩＤを照会パラメータとして追加された（ｔｏｐｉｃＩＤ照会パラメータは既にある）ＦＯＲＥＡＣＨ属性を含むＦＲＡＧＭＥＮＴＬＩＮＫのＳＲＣであるＳＲＣ属性を有するｉｔｅｍＩＤごとの単純なＦＲＡＧＭＥＮＴＬＩＮＫが動的に生成される。各トピック・フラグメントは、すべてのユーザについて同一なので、キャッシュＩＤとしてそのＵＲＩを使用し、照会パラメータとしてｔｏｐｉｃＩＤを有する、単一のキャッシュ規則による正しい修飾を用いてキャッシングすることができる。ｔｏｐｉｃｓクッキーに、トピック・フラグメントのユーザ固有情報のすべてが含まれ、ｔｏｐｉｃｓクッキーは、ページ要求と共に移動し、したがって、親の論理ｕｓｅｒＩＤ修飾を満足する。
【０３４７】
項目フラグメントごとのＵＲＩに、照会パラメータとしてｔｏｐｉｃＩＤおよびｉｔｅｍＩＤが含まれる。項目フラグメントごとの単一のキャッシュＩＤ規則では、キャッシュＩＤにそのＵＲＩが使用され、したがって、正しい修飾によってキャッシングすることができる。
【０３４８】
ＦＲＡＧＭＥＮＴＬＩＮＫタグの指定の例
図５０のサイドバーの例をもう一度参照すると、下記のように、単一のＦＲＡＧＭＥＮＴＬＩＮＫが、ページ内で、サイドバーの代わりに、サイドバーが望まれるのと同一の位置に配置される。
{fragmentlink
src="http://www.acmeStore.com/sidebar.html"}
【０３４９】
図５２の買物客グループの例をもう一度参照すると、下記のように、価格が配置される位置に単一のＦＲＡＧＭＥＮＴＬＩＮＫが配置される。
{fragmentlink
src="http://www.acmeStore.com/productPrice.jsp")
【０３５０】
特定の価格フラグメントについて構成されるＵＲＩは、次のようになる。
http://www.acmeStore.com/productPrice.jsp?productID=AT13394
【０３５１】
フラグメントに関する要求に、親の照会パラメータすなわち「ｐｒｏｄｕｃｔＩｄ」と、クッキーすなわち「ｇｒｏｕｐＩｄ」のすべてが含まれ、その結果、これらが、アプリケーション・サーバでのｐｒｏｄｕｃｔＰｒｉｃｅ．ｊｓｐの実行中に使用可能になる。
【０３５２】
図５５のパーソナライゼーションの例をもう一度参照すると、下記のように、トップレベル・フラグメントに、パーソナライゼーション・フラグメントが望まれる位置に配置されたＦＲＡＧＭＥＮＴＬＩＮＫが含まれる。
{fragmentlink
src="http://www.acmeStore.com/personalization.jsp"}
【０３５３】
特定のユーザ固有パーソナライゼーション・フラグメントに関して構成されるＵＲＩは、次のようになる。
http://www.acmeStore.com/personalization.jsp?productID=AT13394
【０３５４】
フラグメントに関する要求に、親の照会パラメータ（すなわち、「ｐｒｏｄｕｃｔＩｄ」）およびクッキー（すなわち、「ｕｓｅｒＩｄ」）のすべてが含まれる。ｐｅｒｓｏｎａｌｉｚａｔｉｏｎ．ｊｓｐの実行中に、「ｕｓｅｒＩｄ」クッキーは使用されるが、「ｐｒｏｄｕｃｔＩｄ」照会パラメータは無視される。
【０３５５】
図５６の株式ウォッチリストの例をもう一度参照すると、トップレベル・フラグメントに、ユーザが求める株式相場の数に依存する可変個数のＦＲＡＧＭＥＮＴＬＩＮＫタグが含まれる。各ＦＲＡＧＭＥＮＴＬＩＮＫタグは、株式相場がある場所に配置される。各ＦＲＡＧＭＥＮＴＬＩＮＫタグは、次のようになる。
{fragmentlink
src="http://www.acmeInvest.com/stockQuote.jsp?symbol=IBM"}
【０３５６】
特定の株式相場フラグメントについて構成されるＵＲＩは、次のようになる。
http://www.acmeInvest.com/stockQuote.jsp?symbol=IBM
【０３５７】
このシナリオを、ＦＯＲＥＡＣＨ機能を使用するように修正することができ、可変個数のＦＲＡＧＭＥＮＴＬＩＮＫタグが、株式シンボル・パラメータの空白で区切られたリストを値として有するクッキー（ｓｔｏｃｋｓ）の名前を指定するＦＯＲＥＡＣＨ属性を有する単一のＦＲＡＧＭＥＮＴＬＩＮＫタグに置換される。
{fragmentlink
src="http://www.acmeInvest.com/stockQuote.jsp"
foreach="stocks"}
【０３５８】
「ｓｔｏｃｋｓ」という名前のクッキーの値が、
symbol=IBM symbol=CSCOsymbol=DELL
である場合には、これが、下記のＦＲＡＧＭＥＮＴＬＩＮＫタグの組と同等になる。
{fragmentlink
src="http://www.acmeInvest.com/stockQuote.jsp?symbol=IBM"}
{fragmentlink
src="http://www.acmeInvest.com/stockQuote.jsp?symbol=CSCO"}
{fragmentlink
src="http://www.acmeInvest.com/stockQuote.jsp?symbol=DELL"}
【０３５９】
図５７のフル・ポータルの例をもう一度参照すると、ＦＯＲＥＡＣＨ機能を、すべてのユーザによって共用される単一の静的なトップレベル・フラグメントについて使用することができる。トップレベル・フラグメントのｕｓｅｒＮａｍｅは、ユーザの名前を含むｕｓｅｒＮａｍｅクッキーを識別する下記のＦＲＡＧＭＥＮＴＬＩＮＫを使用して含まれる。
{fragmentlinksrc="cookie://userName"}
【０３６０】
トップレベル・フラグメントは、トピックのユーザのリストを含むｔｏｐｉｃｓクッキーを識別するＦＯＲＥＡＣＨ属性を有するＦＲＡＧＭＥＮＴＬＩＮＫタグも有する。
{fragmentlink
src="http://www.acmePortal.com/portalPage.jsp"
foreach="topics"}
【０３６１】
このクッキーには、ｔｏｐｉｃＩＤのリストが含まれる。値が
topic=stockstopic=weather topic=tv
であるｔｏｐｉｃｓクッキーについて、上のＦＯＲＥＡＣＨ属性を含むＦＲＡＧＭＥＮＴＬＩＮＫによって、下記の単純なＦＲＡＧＭＥＮＴＬＩＮＫが生成される。
{fragmentlink
src="http://www.acmePortal.com/portalPage.jsp?topic=stocks"}
{fragmentlink
src="http://www.acmePortal.com/portalPage.jsp?topic=weather"}
{fragmentlink
src="http://www.acmePortal.com/portalPage.jsp?topic=tv"}
【０３６２】
動的に生成されるＳＲＣ属性のそれぞれによって、特定のトピックを処理するフラグメントが突き止められる。
【０３６３】
ウェブ・アプリケーション・サーバでの「ｐｏｒｔａｌＰａｇｅ．ｊｓｐ」の実施形態は、照会パラメータに基づいてフラグメントを呼び出すディスパッチャとして働く。どのパラメータも、トップレベル・フラグメントを返さない。「ｔｏｐｉｃ＝ｓｔｏｃｋｓ」照会パラメータによって、株式トピック・フラグメントが返される。例として株式トピック・フラグメントを使用し、やはりＦＯＲＥＡＣＨ機能を使用すると、株式トピック・フラグメントには、そのトピックに関する株式シンボルのユーザのリストを含む、ｓｔｏｃｋｓクッキーを識別するＦＯＲＥＡＣＨ属性を有するＦＲＡＧＭＥＮＴＬＩＮＫが含まれる。
{fragmentlink
src="http://www.stockQuotes.com/stockQuote.jsp"
foreach="stocks"}
これの例示的な使用は、ｓｔｏｃｋｓクッキーの株式シンボルごとに１行を有するテーブルの行の生成である。値が
symbol=IBM symbol=DELLsymbol=CSCO
である「ｓｔｏｃｋｓ」クッキーについて、ＦＯＲＥＡＣＨ属性を含む上のＦＲＡＧＭＥＮＴＬＩＮＫによって、下記のＦＲＡＧＭＥＮＴＬＩＮＫが動的に生成される。
{fragmentlink
src="http://www.stockQuotes.com/stockQuote.jsp?symbol=IBM"}
{fragmentlink
src="http://www.stockQuotes.com/stockQuote.jsp?symbol=DELL"}
{fragmentlink
src="http://www.stockQuotes.com/stockQuote.jsp?symbol=CSCO"}
【０３６４】
親フラグメントから子フラグメントへのデータ渡しの例
フラグメントは、できる限り自己完結型でなければならない。これには、２つの理由がある。第１の理由は、よいソフトウェア工学によって、ソフトウェア・モジュールをできる限り独立にしなければならないことが命令されることである。モジュールの間のコントラクトの数および複雑さを、最小限にし、その結果、あるモジュールの変更が、ローカルに保たれ、他のモジュールに伝搬しないようにしなければならない。たとえば、アプリケーションが、親モジュールでデータを取得し、このデータを子モジュールに渡し、子モジュールによってフォーマットする場合がある。これが行われる時に、データが何であり、それをどのようにして渡すかを記述するコントラクトが存在しなければならない。子モジュールが必要とするデータの変更は、両方のモジュールの変更を必要とする。その代わりに、子モジュールがそれ自体のデータを得るならば、変更がローカルに保たれる。モジュールをデータを入手する方法と独立にすること、またはデータを得るコードを複数のモジュールで同一にすることのいずれかの必要がある場合には、別々のデータ・ビーンおよび対応するコントラクトを使用して、この要件のいずれかを達成することができる。しかし、親モジュールと子モジュールの間に別のコントラクトを追加することによって、何も達成されずに複雑さだけが追加される。
【０３６５】
フラグメントをできる限り自己完結型にしなければならない第２の理由は、キャッシングを効率的にすることであり、フラグメントを生成するコードを、自己完結型にしなければならない。上の例では、親モジュールが、子モジュールのためのデータのすべてを得て、子に渡す場合に、子自体は、フォーマッティングだけを行う。モジュールの間にこの依存性があると、子モジュールが必要とするデータが古くなった場合に、親と子の両方が、無効化され、もう一度生成されなければならない。この依存性によって、別々のフラグメントのキャッシングが、はるかに効率的でなくなる。複数の親によって共用されるフラグメントによって、上の問題の両方が複雑になる。
【０３６６】
ＪＳＰプログラミング・モデルを用いると、要求属性またはセッション状態を介してＪＳＰの間でデータを渡せるようになる。入れ子になったフラグメントについて、要求属性機構は機能しない。というのは、親ＪＳＰおよび子ＪＳＰを、アプリケーション・サーバへの異なる要求で取り出すことができるからである。また、セッション状態機構は、親と子を異なるセッションで実行できる場合に、機能しない可能性がある。その代わりに、渡されなければならない情報のすべてで、ＵＲＩ照会パラメータまたはクッキーを使用しなければならない。要求属性を使用して親から子に渡された複雑なデータ構造であっても、それを直列化し、ＦＲＡＧＭＥＮＴＬＩＮＫタグのＳＲＣ属性にＵＲＩの照会パラメータとして含めることによって、渡すことができる。
【０３６７】
フラグメントが、それ自体のデータを得る時であっても、フラグメントの間である制御データを渡す必要がある。上の例をもう一度参照すると、サイドバーのシナリオで、トップレベル・フラグメントからサイドバーにデータが渡されない。買物客グループのシナリオでは、トップレベル製品説明フラグメントが、製品ＩＤを知る必要があり、子グループ製品固有価格が、製品ＩＤと買物客グループＩＤの両方を必要とする。製品ＩＤは、外部要求によって供給される。買物客グループＩＤは、ユーザＩＤを使用してアプリケーションによって生成され、この両方のＩＤが、ログオン時に生成される。製品ＩＤと買物客グループＩＤの両方を、製品説明フラグメントを介して価格フラグメントに渡さなければならない。すべてのＵＲＩ照会パラメータおよびクッキーが、子フラグメントに自動的に渡される。
【０３６８】
パーソナライゼーションのシナリオでは、トップレベル製品説明フラグメントが、製品ＩＤを知ることを必要とし、子パーソナライゼーション・フラグメントが、ユーザＩＤを知ることを必要とする。このパラメータの両方が、外部要求によって供給され、したがって、ユーザＩＤは、製品説明フラグメントを介してパーソナライゼーション・フラグメントに渡されなければならない。これは、「ｕｓｅｒＩｄ」という名前のクッキーを子フラグメントに渡すことによって行われる。
【０３６９】
株式ウォッチリストのシナリオでは、トップレベル株式ウォッチリスト・フラグメントが、ユーザＩＤクッキーを知ることを必要とし、子株式相場フラグメントのそれぞれが、株式シンボルを知ることを必要とする。株式シンボルおよびそれを含むＦＲＡＧＭＥＮＴＬＩＮＫタグが、トップレベル株式ウォッチリスト・フラグメントの一部として生成される。株式シンボルが、株式相場フラグメントに渡されなければならない。これは、ＦＲＡＧＭＥＮＴＬＩＮＫのＳＲＣ属性のＵＲＩの照会パラメータとして株式シンボルを置くことによって行われる。
【０３７０】
ＦＲＡＧＭＥＮＴＬＩＮＫタグおよびＦＲＡＧＭＥＮＴヘッダの例
表１から３に関して、ＨＴＭＬステートメントおよびＨＴＴＰステートメントの組を、上で述べたサイドバーの例について示す。このシナリオの両方のフラグメントが、静的である。親トップレベル・フラグメントは、「ｊｓｐ：ｉｎｃｌｕｄｅ」を使用して別のフラグメントを含み、キャッシュ制御情報を親フラグメントに関連付ける必要があるので、ＪＳＰになる。子サイドバー・フラグメントも、キャッシング制御情報を関連付ける必要があるのでＪＳＰになるが、ＪＳＰタグは一切含まれない。
【０３７１】
表１に、サイドバー・フラグメントを含むトップレベル・フラグメントのＨＴＭＬステートメントを含むＪＳＰを示す。
【０３７２】
【表１】
2005513640.tif 000076
【０３７３】
表２に、トップレベル・フラグメントについてウェブ・アプリケーション・サーバによって生成されるＨＴＴＰ出力を示す。
【０３７４】
【表２】
2005513640.tif 000077
【０３７５】
表３に、サイドバー・フラグメントについてウェブ・アプリケーション・サーバによって生成されるＨＴＴＰ出力を示す。
【０３７６】
【表３】
2005513640.tif 000078
【０３７７】
表４から７に関して、上で説明した買物客グループの例について、ＨＴＭＬステートメントおよびＨＴＴＰステートメントの組を示す。このシナリオの両方のフラグメントが、ダイナミックである。ＪＳＰが、製品グループ固有価格フラグメントを含むトップレベル・フラグメントに使用される。子フラグメントも、適当な価格を入手するビジネス・アプリケーション・ロジックが含まれるので、ＪＳＰである。
【０３７８】
表４に、子フラグメントを含むトップレベル製品説明フラグメントのＨＴＭＬステートメントを含むＪＳＰを示す。
【０３７９】
【表４】
2005513640.tif 000079
【０３８０】
表５に、製品説明フラグメントについてウェブ・アプリケーション・サーバによって生成されるＨＴＴＰ出力を示す。
【０３８１】
【表５】
2005513640.tif 000080
【０３８２】
表６に、子製品グループ固有価格フラグメントのＨＴＭＬステートメントを含むＪＳＰを示す。
【０３８３】
【表６】
2005513640.tif 000081
【０３８４】
表７に、製品グループ固有価格フラグメントについてウェブ・アプリケーション・サーバによって生成されるＨＴＴＰ出力を示す。
【０３８５】
【表７】
2005513640.tif 000082
【０３８６】
表８から１１に関して、上で述べたパーソナライゼーションの例について、ＨＴＭＬステートメントおよびＨＴＴＰステートメントの組を示す。このシナリオの両方のフラグメントが、ダイナミックである。トップレベル製品フラグメントを生成するＪＳＰに、単一のユーザ固有パーソナライゼーション・フラグメントが含まれる。子フラグメントも、ユーザに関する適当なパーソナライゼーション・データを得るビジネス・アプリケーション・ロジックが含まれるので、ＪＳＰである。
【０３８７】
表８に、子フラグメントを含むトップレベル製品説明フラグメントのＨＴＭＬステートメントを含むＪＳＰを示す。
【０３８８】
【表８】
2005513640.tif 000083
【０３８９】
表９に、製品説明フラグメントについてウェブ・アプリケーション・サーバによって生成されるＨＴＴＰ出力を示す。
【０３９０】
【表９】
2005513640.tif 000084
【０３９１】
表１０に、子ユーザ固有フラグメントのＨＴＭＬステートメントを含むＪＳＰを示す。
【０３９２】
【表１０】
2005513640.tif 000085
【０３９３】
表１１に、子フラグメントについてウェブ・アプリケーション・サーバによって生成されるＨＴＴＰ出力を示す。
【０３９４】
【表１１】
2005513640.tif 000086
【０３９５】
表１２から１７に関して、上で述べた株式ウォッチリストの例について、ＨＴＭＬステートメントおよびＨＴＴＰステートメントの組を示す。このシナリオのフラグメントの両方が、ダイナミックである。
【０３９６】
表１２に、複数の株式相場フラグメントを含むトップレベル株式ウォッチリスト・フラグメントを生成するＪＳＰを示す。「ｊｓｐｅｘｔ：ｃｏｏｋｉｅ」タグによって、「ｕｓｅｒＮａｍｅ」という名前のクッキーに含まれるユーザ名が表示される。この例では、可変個数の「ＲｅｑｕｅｓｔＤｉｓｐａｔｃｈｅｒ．ｉｎｃｌｕｄｅ」メソッド呼出しが動的に生成され、そのそれぞれによって、出力のＦＲＡＧＭＥＮＴＬＩＮＫタグが生成される。
【０３９７】
【表１２】
2005513640.tif 000087
【０３９８】
表１３に、株式ウォッチリスト・フラグメントについてウェブ・アプリケーション・サーバによって生成されるＨＴＴＰ出力を示す。
【０３９９】
【表１３】
2005513640.tif 000088
【０４００】
表１４に、ＦＯＲＥＡＣＨ属性が組み込まれるトップレベル株式ウォッチリスト・フラグメントを生成するＪＳＰを示す。
【０４０１】
【表１４】
2005513640.tif 000089
【０４０２】
表１５に、ＦＯＲＥＡＣＨ属性を組み込まれたトップレベル株式ウォッチリスト・フラグメントについてウェブ・アプリケーション・サーバによって生成されるＨＴＴＰ出力を示す。
【０４０３】
【表１５】
2005513640.tif 000090
【０４０４】
表１６に、個々の株式相場を生成するＪＳＰを示す。
【０４０５】
【表１６】
2005513640.tif 000091
【０４０６】
表１７に、シンボル照会パラメータ「ＩＢＭ」についてウェブ・アプリケーション・サーバによって生成されるＨＴＴＰ出力を示す。
【０４０７】
【表１７】
2005513640.tif 000092
【０４０８】
結論
本発明の好ましい実施形態の利益は、上で提供した本発明の好ましい実施形態の詳細な説明に鑑みて明白である。ネットワークを介してコンピューティング・デバイスに展開することができるフラグメント・キャッシング技法は、キャッシュ管理ユニット内で実施でき、キャッシュ管理ユニットによって分散フラグメント・キャッシング機構がもたらされる。
【０４０９】
ＨＴＴＰなどのネットワーク・プロトコル内で使用されるＦＲＡＧＭＥＮＴヘッダが定義され、ヘッダによって、フラグメントの処理およびキャッシングに関連するさまざまな目的のために、メタデータがフラグメントに関連付けられる。たとえば、ヘッダは、クライアント、サーバ、または他の中間キャッシュのいずれかがページ組立能力を有するかどうかの識別に使用される。ヘッダによって、フラグメントのキャッシュ識別子を形成するキャッシュＩＤ規則も指定され、この規則は、フラグメントのＵＲＩ、または、ＵＲＩパスならびに要求に付随するＵＲＩからの照会パラメータおよびクッキーのある組合せに基づくものとすることができる。さらに、ヘッダによって、ホストによって開始される無効化をサポートして、フラグメントの依存性関係を指定することができる。
【０４１０】
ＦＲＡＧＭＥＮＴＬＩＮＫタグは、ページ組立中またはページ・レンダリング中に挿入されるインクルードされるフラグメントに関するページ内の位置を指定するのに使用される。ＦＲＡＧＭＥＮＴＬＩＮＫタグは、リンクされたフラグメントをキャッシュ内で見つけること、またはサーバからそれを取り出すことのいずれかに十分な情報を含むように定義されている。キャッシュＩＤ規則が、フラグメントがキャッシュに保管される時と、キャッシュ内でフラグメントを見つけるために要求からのソース識別子を処理する時の両方に使用される。キャッシュ内でフラグメントを見つけるために、フラグメントのＵＲＩパスに関連するキャッシュＩＤ規則が、キャッシュＩＤを判定するのに使用される。この規則によって、キャッシュＩＤ形成の標準実施形態を強制するコンピュータ・プログラムを展開する必要なしに、フラグメントのキャッシュＩＤを形成する際の高い度合の柔軟性が可能になる。複数のキャッシュＩＤ規則を使用することができる。キャッシュＩＤ規則を用いると、キャッシュＩＤを、フラグメントのフルＵＲＩまたはＵＲＩと照会パラメータまたはクッキーの組合せにすることができるようになる。この方式を用いると、同一のＦＲＡＧＭＥＮＴＬＩＮＫによって、親フラグメントの照会パラメータおよびクッキーに依存して異なるフラグメントを突き止めることができるようになり、たとえば、製品説明ページの要求のユーザＩＤクッキーを使用して、パーソナライゼーション・フラグメントのキャッシュＩＤを形成することができる。
【０４１１】
本発明の好ましい実施形態を、完全に機能するデータ処理システムに関して説明したが、本発明の好ましい実施形態に関連する処理の一部を、配布の実行に実際に使用される信号担持媒体の特定のタイプに無関係に、コンピュータ可読媒体内の命令の形またはさまざまな他の形で配布できることを、当業者が諒解するであろうことに留意することが重要である。コンピュータ可読媒体の例に、ＥＰＲＯＭ、ＲＯＭ、テープ、紙、フロッピ・ディスク、ハード・ディスク・ドライブ、ＲＡＭ、およびＣＤ−ＲＯＭなどの媒体と、ディジタル通信リンクおよびアナログ通信リンクなどの伝送型媒体が含まれる。
【図面の簡単な説明】
【０４１２】
【図１】本発明の好ましい実施形態を実施できる通常の分散データ処理システムを示す図である。
【図２】本発明の好ましい実施形態を実施できるデータ処理システム内で使用することができる通常のコンピュータ・アーキテクチャを示す図である。
【図３】キャッシュを分散データ処理システム全体で実施できる通常の分散データ処理システムを示す図である。
【図４】フラグメントからなる通常のウェブ・ページを示す図である。
【図５】本発明の好ましい実施形態による、ＦＲＡＧＭＥＮＴＬＩＮＫタグの形式的な標準汎用印刷指定言語（ＳＧＭＬ）定義を示す図である。
【図６】本発明の好ましい実施形態によるＦＲＡＧＭＥＮＴヘッダの形式的な定義を示す図である。
【図７】オブジェクト取出しパスに沿ったフラグメント・サポート式エージェントおよびフラグメント非サポート式エージェントの組を示す図である。
【図８】オブジェクト取出しパスに沿ったフラグメント・サポート式エージェントおよびフラグメント非サポート式エージェントの組を示す図である。
【図９】オブジェクト取出しパスに沿ったフラグメント・サポート式エージェントおよびフラグメント非サポート式エージェントの組を示す図である。
【図１０】オブジェクト取出しパスに沿ったフラグメント・サポート式エージェントおよびフラグメント非サポート式エージェントの組を示す図である。
【図１１】オブジェクト取出しパスに沿ったフラグメント・サポート式エージェントおよびフラグメント非サポート式エージェントの組を示す図である。
【図１２】オブジェクト取出しパスに沿ったフラグメント・サポート式エージェントおよびフラグメント非サポート式エージェントの組を示す図である。
【図１３】オブジェクト取出しパスに沿ったフラグメント・サポート式エージェントおよびフラグメント非サポート式エージェントの組を示す図である。
【図１４】コンピューティング・デバイス内のフラグメント・サポート式キャッシュのキャッシュ管理ユニットを示す図である。
【図１５】フラグメントを含む応答メッセージを処理する時にフラグメント・サポート式キャッシュ管理ユニットによって使用することができる処理を示す流れ図である。
【図１６】メッセージ本体にフラグメント・オブジェクトが含まれるか否かを判定する好ましい方法を示す流れ図ステップである。
【図１７】フラグメント・オブジェクトがキャッシュ可能であるか否かを判定するより具体的な方法を示す流れ図ステップである。
【図１８】フラグメント・オブジェクトがキャッシュ可能であるか否かを判定す好ましい方法を示す流れ図ステップである。
【図１９】フラグメント・オブジェクトを特定のコンピューティング・デバイスでキャッシングしなければならないか否かを判定する方法を示す流れ図である。
【図２０】下流デバイスがフラグメント・サポート式キャッシュを有するか否かを判定する好ましい方法を示す流れ図ステップである。
【図２１】現在処理されつつあるフラグメント・オブジェクトを、宛先ユーザ／クライアント・デバイスに最も近いフラグメント・サポート式キャッシュでのみキャッシングしなければならないか否かを判定する、より具体的な方法を示す流れ図ステップである。
【図２２】現在処理されつつあるフラグメント・オブジェクトを、宛先ユーザ／クライアント・デバイスに最も近いフラグメント・サポート式キャッシュでのみキャッシングしなければならないかどうかを判定する、好ましい方法を示す流れ図ステップである。
【図２３】現在のコンピューティング・デバイスから応答メッセージを返す前にページ組立が必要であるか否かを判定する方法を示す流れ図である。
【図２４】現在処理されつつあるフラグメント・オブジェクトが、別のフラグメントへのリンクを有するか否かを判定する、より具体的な方法を示す流れ図ステップである。
【図２５】現在処理されつつあるフラグメント・オブジェクトが、別のフラグメントへのリンクを有するか否かを判定する、代替の方法を示す流れ図ステップである。
【図２６】ページ組立を実行する処理を示す流れ図である。
【図２７】任意選択としてフラグメント・リンクを複数のフラグメント・リンクに展開する処理を示す流れ図である。
【図２８】応答メッセージからの現在のフラグメントのフラグメント・リンクが、これを複数のフラグメント・リンクに展開しなければならないことを示すか否かを判定する好ましい方法を示す流れ図ステップである。
【図２９】フラグメント・リンクに関連する情報に従ってフラグメント・リンクを複数のフラグメント・リンクに展開する処理を示す流れ図である。
【図３０】フラグメントのソース識別子を使用するフラグメントの取出しの処理を示す流れ図である。
【図３１】フラグメントがフラグメント・サポート式キャッシュ管理ユニット内でキャッシングされる時に実行される処理の一部を示す流れ図である。
【図３２】フラグメントがキャッシュ管理ユニットを含むコンピューティング・デバイスでキャッシングされる場合に、そのフラグメントを入手するためにフラグメント・サポート式キャッシュ管理ユニットによって使用することができる処理を示す流れ図である。
【図３３】複数のフラグメントに関連するヘッダ値およびプロパティ値を組み合わせる処理を示す流れ図である。
【図３４】ヘッダ・タイプおよびプロパティ値の、一連の組合せ機能を表すステップの組を示す流れ図である。
【図３５】要求メッセージを処理する時にフラグメント・サポート式キャッシュ管理ユニットによって使用することができる処理を示す流れ図である。
【図３６】本発明の好ましい実施形態の実施形態に従って無効化メッセージを処理する時にフラグメント・サポート式キャッシュ管理ユニットによって使用することができる処理を示す流れ図である。
【図３７】一部のキャッシュでフラグメント組立が実行される時を示すための、ウェブ・アプリケーション・サーバとクライアントの間でのデータフローの一部を示すブロック図である。
【図３８】エンドユーザまたはクライアント・デバイスに最も近いキャッシュでフラグメントをキャッシングするようにデバイスの組に指示することができる形を示すための、ウェブ・アプリケーション・サーバとクライアントの間でのデータフローの一部を示すブロック図である。
【図３９】動的な役割固有またはカテゴリ固有のコンテンツのキャッシングを本発明の好ましい実施形態を使用して達成できることを示すための、クライアント、中間フラグメント・サポート式キャッシュ、またはサーバ内で行われる処理ステップの一部を示すデータフロー図である。
【図４０】動的な役割固有またはカテゴリ固有のコンテンツのキャッシングを本発明の好ましい実施形態を使用して達成できることを示すための、クライアント、中間フラグメント・サポート式キャッシュ、またはサーバ内で行われる処理ステップの一部を示すデータフロー図である。
【図４１】動的な役割固有またはカテゴリ固有のコンテンツのキャッシングを本発明の好ましい実施形態を使用して達成できることを示すための、クライアント、中間フラグメント・サポート式キャッシュ、またはサーバ内で行われる処理ステップの一部を示すデータフロー図である。
【図４２】動的な役割固有またはカテゴリ固有のコンテンツのキャッシングを本発明の好ましい実施形態を使用して達成できることを示すための、クライアント、中間フラグメント・サポート式キャッシュ、またはサーバ内で行われる処理ステップの一部を示すデータフロー図である。
【図４３】複数のフラグメントを単一の要求メッセージ内で指定でき、後に処理できるようにする処理を示す流れ図である。
【図４４】単一の要求メッセージを中間キャッシュ管理ユニットで受信し、後に処理できるようにする処理を示す流れ図である。
【図４５】複数のフラグメントに関するバッチ要求メッセージを処理するウェブ・アプリケーション・サーバでの処理を示す流れ図である。
【図４６】本発明の好ましい実施形態に従って達成できる有利なキャッシュ・サイズ削減を示す例の１つを示す図である。
【図４７】本発明の好ましい実施形態に従って達成できる有利なキャッシュ・サイズ削減を示す例の１つを示す図である。
【図４８】本発明の好ましい実施形態に従って達成できる有利なキャッシュ・サイズ削減を示す例の１つを示す図である。
【図４９】本発明の好ましい実施形態に従って達成できる有利なキャッシュ・サイズ削減を示す例の１つを示す図である。
【図５０】本発明の好ましい実施形態の教示によって、フラグメントの保管および処理のために一意のキャッシュ識別子が構成され、使用される形を示す図の１つである。
【図５１】本発明の好ましい実施形態の教示によって、フラグメントの保管および処理のために一意のキャッシュ識別子が構成され、使用される形を示す図の１つである。
【図５２】本発明の好ましい実施形態の教示によって、フラグメントの保管および処理のために一意のキャッシュ識別子が構成され、使用される形を示す図の１つである。
【図５３】本発明の好ましい実施形態の教示によって、フラグメントの保管および処理のために一意のキャッシュ識別子が構成され、使用される形を示す図の１つである。
【図５４】本発明の好ましい実施形態の教示によって、フラグメントの保管および処理のために一意のキャッシュ識別子が構成され、使用される形を示す図の１つである。
【図５５】本発明の好ましい実施形態の教示によって、フラグメントの保管および処理のために一意のキャッシュ識別子が構成され、使用される形を示す図の１つである。
【図５６】本発明の好ましい実施形態の教示によって、フラグメントの保管および処理のために一意のキャッシュ識別子が構成され、使用される形を示す図の１つである。
【図５７】本発明の好ましい実施形態の教示によって、フラグメントの保管および処理のために一意のキャッシュ識別子が構成され、使用される形を示す図の１つである。
【国際調査報告】
2005513640.tif 000093
2005513640.tif 000094