Oracle Application Server Containers for J2EE JSPタグ・ライブラリおよびユーティリティ・リファレンス
10g(9.0.4)


Edge Side Includes用のJESIタグについて

このトピックでは、OC4Jが提供するJESI(Edge Side Includes for Java)タグ・ライブラリについて説明します。これらのタグは、Oracle Application Server Web Cacheで使用可能なEdge Side Includes(ESI)フレームワークの最上部で稼働して、JSPアプリケーションにESIキャッシング機能を提供します。

このトピックには、次の項目が含まれます。

Webキャッシングの概要と、OracleAS Web Cache、Oracle Application Server Java Object CacheおよびOC4J Web Object Cacheの説明は、「Webアプリケーションに対するOracleキャッシング・サポートのサマリー」を参照してください。


注意:

JESI仕様はまだファイナライズされていません。最新の実用バージョンに準拠するためにあらゆる作業が行われていますが、OC4J 9.0.4実装がJESI仕様の最終バージョンに完全に準拠することは保証できません。


Edge Side Includesテクノロジと処理の概要

JESIタグは、JSPページの動的コンテンツをキャッシュ可能なコンポーネントに分割します。その基礎となるのがEdge Side Includesアーキテクチャとマークアップ言語です。

JESIタグの使用は、特定のESIプロセッサやキャッシング・システムに依存しているわけではありませんが、Oracleユーザーの典型的な使用例では、OracleAS Web CacheとそのESIプロセッサを使用しています。

次の項では、Oracle JESIタグの基礎となっている基本テクノロジの一部に関するバックグラウンド情報について説明します。

この項で説明するのは、ESIアーキテクチャと言語の簡単な概要のみです。ESIテクノロジに関する追加情報は、次のWeb サイトを参照してください。

 http://www.esi.org
      

Edge Side Includesテクノロジ

この項では、ESIテクノロジの特性とESIのサロゲートの概念を紹介します。

ESIの概要

Edge Side Includesとは、XMLスタイルのマークアップ言語のことです。この言語を使用すると、Webサーバーから独立してネットワークの「Edge」で動的コンテンツのアセンブリを実行できます。また、この言語は、Webキャッシュやコンテンツ配信ネットワーク(CDN)など、現在使用可能なツールを活用して、ユーザーのパフォーマンスを向上させるために設計されています。

ESIには、中間処理を促進することによって、Webサーバーとアプリケーション・サーバーの負荷を軽減する手段が含まれています。サロゲートまたはリバース・プロキシと呼ばれるこの手段では、ESI言語を理解し、Webサーバーにかわって動作します。ESIコンテンツの目的は、Webサーバーを離れてから、ユーザーのブラウザに表示されるまでの間の処理を行うことにあります。サロゲートは、HTTPヘッダーを介してコマンド実行されます。 したがって、サロゲートをESIプロセッサと呼ぶことができます。また、Webキャッシュの機能の一部に含めることもできます。

ESIは、Webページの各動的部分を個別にキャッシュし、適切に切り離して取得できるパーシャル・ページのキャッシング方法論に近いと言えます。

ESIマークアップ・タグを使用すると、開発者は集計Webページを定義できます。また、必要に応じて、ESIプロセッサで取得およびアセンブルするキャッシュ可能コンポーネントを定義できます。集計ページは、ユーザーが指定したURLに関連付けられているリソースであり、アセンブリのコンテナと考えることができます。これには、ESIタグに指定されている取得およびアセンブリの指示が含まれます。


注意:

JESIユーザーはESIタグを直接使用する必要がありません(通常は使用しません)。JESIタグ・ハンドラは、JESIタグをESIタグに背後で変換します。


サロゲートについて

サロゲートは、ページ・コンテンツを所有するWebサーバーのかわりに動作するため、コンテンツ所有者は、サロゲートの動作を完全に制御できます。これにより、サロゲートを使用しない場合に比較して、大幅なパフォーマンスの向上が可能になります。

サロゲートでのキャッシング処理は、HTTPでのキャッシング処理に類似しています。どちらも、類似した斬新な妥当性チェック機能を基盤として使用しています。ただし、サロゲートには、その上に制御機能も備わっています。

ESIの主要機能

ESI言語のバージョン1.0には、次の主要な機能が含まれています。

図1 ESIインクルード・モデル

Text description of esiincl.gif follows.

図esiincl.gifの説明

OracleAS Web CacheとESIプロセッサ

この項では、OracleAS Web CacheとそのESIプロセッサを紹介します。 詳細は、『Oracle Application Server Web Cache管理者ガイド』を参照してください。

OracleAS Web Cacheの概要

Oracleでは、Webサイトのパフォーマンスの問題を抱えるE-Businessを支援するために、OracleAS Web Cacheを提供しています。 この製品は、コンテンツ対応のサーバー・アクセラレータ、つまりリバース・プロキシ・サーバーであり、Oracle Application Serverで稼働するWebサイトのパフォーマンス、拡張性および可用性を向上させます。

OracleAS Web Cacheでは、頻繁にアクセスするURLのページをメモリーに格納することによって、アプリケーションWebサーバー上でこれらのURLに対するリクエストを繰り返して処理する必要がなくなります。静的ドキュメントのみを処理するレガシー・プロキシ・サーバーとは異なり、OracleAS Web Cacheは、1つ以上のアプリケーションWebサーバーから、静的コンテンツと動的に生成されたコンテンツの両方をキャッシュします。キャッシュ・ヒットの数が増えるほど、レガシー・プロキシの場合に比較して、パフォーマンス強化が増大し、アプリケーション・サーバーへの負荷が減少します。

概念的には、OracleAS Web Cacheは、アプリケーションWebサーバーの前に位置しており、Webサーバーのコンテンツをキャッシュし、そのコンテンツをリクエストしているWebブラウザに送信します。Webサイトへのアクセス時に、Webブラウザは、HTTPプロトコルまたはHTTPSプロトコルのリクエストをOracleAS Web Cacheに送信します。その結果、このWeb Cacheは、アプリケーションWebサーバーに対する仮想サーバーとして動作します。リクエストされたコンテンツがすでに期限切れの場合、無効になっている場合、またはアクセスできない場合、OracleAS Web Cacheは、そのアプリケーションWebサーバーから新規コンテンツを取得します。

OracleAS Web Cacheの使用ステップ

次に、ブラウザとOracleAS Web Cacheとの典型的な相互作用のステップを示します。

  1. ブラウザが、企業のWebサイトにリクエストを送信します。

  2. このリクエストの結果、ドメイン・ネーム・システム(DNS)に対して、WebサイトのIPアドレスのリクエストが生成されます。

  3. DNSは、OracleAS Web CacheのIPアドレスを返します。

  4. ブラウザは、WebページのリクエストをOracleAS Web Cacheに送信します。

  5. リクエストされたコンテンツがキャッシュにある場合、OracleAS Web Cacheは、そのコンテンツをブラウザに直接送信します。 これは、キャッシュ・ヒットと呼ばれます。

  6. OracleAS Web Cacheにリクエストされたコンテンツがない場合、またはそのコンテンツが古くなったか失効している場合、Web Cacheは、そのリクエストをアプリケーションWebサーバーに渡します。 これは、キャッシュ・ミスと呼ばれます。

  7. アプリケーションWebサーバーは、OracleAS Web Cacheを介してコンテンツを送信します。

  8. OracleAS Web Cacheは、そのコンテンツをクライアントに送信し、そのページのコピーをキャッシュに作成します。


注意:

キャッシュに格納されたページは、失効化されるかまたは古くなった後の時点で削除されます。


OracleAS Web Cache ESIプロセッサ

OracleAS Web Cacheには、キャッシングでEdge Side Includesマークアップ言語の使用をサポートするESIプロセッサが組み込まれています。 (詳細は、「Edge Side Includesテクノロジ」を参照してください。)

OracleAS Web Cache環境のWeb開発者は、自分のアプリケーションでESI言語を直接使用できます。ただし、JSP開発者の場合は、いくつかの理由から、ESI言語に対する便利なJSPインタフェースとして提供されているJESIタグ・ライブラリを使用します。 「JESIタグのメリット」を参照してください。

JESI機能の概要

次の項では、JESI機能とOracleによる実装について説明します。

次のWebサイトからJESIの提案仕様にアクセスできます。

 http://www.esi.org
      

JESIタグのメリット

OC4Jには、Webキャッシュ用のESIタグおよびEdge Side Includes機能に対する便利なインタフェースとして、JESIタグ・ライブラリが用意されています。開発者は、WebアプリケーションでESIタグを直接使用することもできますが、JESIタグを使用することでJSPページはさらに便利になります。次に、ESIタグを直接使用せずに、JESIタグを使用する主なメリットについて説明します。

OracleによるJESIタグ実装の概要

OracleがJESIを実装するレイヤーは、標準ESIフレームワークの最上部です。これは(OC4J 9.0.4の実装時点で)保留中のJESI標準であるJSR-128にも準拠しています。この標準は、Java Community Process(JCP)組織が後援しています。JCP組織とJSR-128のステータスの詳細は、次の場所を参照してください。

 http://www.jcp.org
 
      

JESIタグ・ライブラリは、標準実装であるため、次の点に注意してください。

Oracle JESIタグ・ライブラリは、次のタグをサポートします。

JSP開発者は、対応するESIタグ(esi:includeなど)ではなく、これらのタグ(JESI includeなど)を使用します。 このタグの有用性と利便性については、「JESIタグのメリット」で説明しています。


注意:

Oracle JESIタグ・ライブラリは、JSPカスタム・タグ・ライブラリの一般標準に従って実装されています。 標準JavaServer Pagesタグ・ライブラリのフレームワークの詳細は、『Oracle Application Server Containers for J2EE JavaServer Pages開発者ガイド』を参照してください。


JESIの使用モデル

集計ページとそのキャッシュ可能コンポーネントの定義にJESIタグを使用する方法には、次の2つのモデルがあります。

この項では、これら2つのモデルについて説明し、最後にJESI includeタグに関する特記事項を説明します。

control/includeモデル

JESIタグの使用方法に対するcontrol/includeアプローチは、モジュール化された方法です。この方法では、ほとんど(またはすべて)のキャッシュ可能コンテンツをインクルード・ページとして集計ページに表示します。この方法は、新規ページを開発する場合に特に便利です。このモデルは、次のように使用します。

各インクルード・ファイルは、個別のキャッシュ可能オブジェクトです(ただし、タグ設定によってキャッシングを無効化できます)。また、トップレベル・ページのコンテンツもすべて個別オブジェクトです。

状況によっては、両タグともオプションになります。 JESI includeタグを使用せずに、ページにJESI controlタグを指定できます。実際に、これが既存のページをJESI用に変換する簡単な方法です。 また、JESI includeタグを使用しているページに、必ずしもJESI controlタグを指定する必要はありません。 ESIプロセッサでは、JESI includeタグがあることを無差別に適宜通知します。 インクルード・ページにJESI controlタグは必要ありません。

トップレベル・ページまたはインクルード・ページがキャッシュ可能かどうかは、次のように判断されます。

タグ構文と例は、次の各項を参照してください。

template/fragmentモデル

template/fragmentアプローチでは、コンテンツが単一ページに含まれ、必要に応じてページを独立したキャッシュ可能なフラグメントに分割します。このモデルは、JESIで使用するために既存のページを変換し、特定の部分を独立したキャッシュ可能なコンポーネントに分割する場合に特に便利です。このモデルは、次のように使用します。

JESI templateタグとJESI fragmentタグは、必ず同時に使用します。 ページに個別のフラグメントが不要な場合は、JESI templateタグではなく、JESI controlタグを使用します。

各フラグメントは個別のキャッシュ可能オブジェクトです。フラグメント以外のテンプレート・レベルにあるコンテンツは、個別のキャッシュ可能オブジェクトです。 JESI includeタグでインクルードされるページも個別のキャッシュ可能オブジェクトです。キャッシュ可能かどうかは、次のように判断されます。


注意:

template/fragmentモデルは、すでにJESI controlタグを処理したレスポンスで使用できます。これは、たとえば集計レスポンスの条件付き生成に代替ページのいずれかのセットからのレスポンスを含めることができる場合には、必須になる可能性があります。 この場合、JSPコンテナは、controlタグの属性設定を使用し、templateタグの属性設定を無視しますが、必要に応じてfragmentタグを正しく囲むtemplateタグがあることに注意してください。 template/fragmentモデルでは、常に、templateタグの外側ではキャッシュ可能なコンテンツを使用できません。


テンプレートとフラグメントは、独立したキャッシュ可能オブジェクトであるため、ESIプロセッサで期限切れになる時点が異なる場合があります。キャッシュ・ミスの発生時、または期限切れオブジェクトがリクエストされたとき、ESIプロセッサは、Webサーバー(OracleASの場合はOC4J)に新しいコピーをリクエストします。

リクエストされたオブジェクトがJESIテンプレートの場合、JSPコンテナは、そのページ内のフラグメント以外のコードを実行します。JSPトランスレータは、生成した出力に、すべてのフラグメントをインクルードする場所を指定するESIマークアップも配置します。この時点では、JESIフラグメントに格納されているコードは実行されません。 次の図 2にこれを示します。

図2 テンプレートに対するJESIリクエスト

Text description of jesitreq.gif follows.

図jesitreq.gifの説明

フラグメントが期限切れになると、ESIプロセッサはWebサーバーに対して、その特定のフラグメントをリクエストします。フラグメントを実行するために、OC4J JSPコンテナは、テンプレート・コード(フラグメント以外のコード)に加えて、リクエスト対象のフラグメントのコードを実行します。テンプレート・コードを実行すると、フラグメントは変数の宣言や初期化などの特定の副次的効果に依存できます。

フラグメント・コードの出力は、レスポンスで返されます。テンプレート・コードの出力は廃棄されます。レスポンスを受信すると、ESIプロセッサは、フラグメントの更新済コピーをキャッシュします。 次の図 3にこれを示します。

図3 フラグメントに対するJESIリクエスト

Text description of jesifreq.gif follows.

図jesifreq.gifの説明


注意:

コストの高いテンプレート・コードの実行を不必要に繰り返すことを回避するために、JESI codeblockタグ内にコードを戦略的に配置してください。 各codeblockタグは、そのタグ内のコードをいつ実行するか(テンプレートがリクエストされるたびにか、フラグメントがリクエストされるたびにか、または常にか)に従って構成してください。


テンプレートとフラグメントに対してコード配置と期限切れのポリシーを選択するときは、この動作に注意してください。特に、テンプレート・コードはすべての更新リクエストで実行されるため、コストの高いコードを配置する場所には注意してください。 毎回実行する必要がない、またはcodeblockタグ内に適切に配置されていない場合は、コストのかかる計算をテンプレート・レベルに配置しないでください。または、コストのかかる計算は、できるだけ期限切れまでの期間が長いフラグメントに配置してください。

図 4に、フラグメントがリクエストされたときのみコード・ブロックを実行する1つのcodeblockタグの使用例を示します。この図では、リクエストはテンプレートに対するものであるため、コード・ブロックは実行されません。

図 5に、フラグメントがリクエストされたときのみコード・ブロックを実行する別のcodeblockタグの使用例を示します。ただし今回は、リクエストがフラグメントに対するものであるため、コード・ブロックが実行されます。

図4 テンプレートに対するリクエストでのJESI codeblockフラグメントの実行

Text description of jesicbt.gif follows.

図jesicbt.gifの説明

図5 フラグメントに対するリクエストでのJESI codeblockフラグメントの実行

Text description of jesicbf.gif follows.

図jesicbf.gifの説明

さらに、同一リクエスト時に、2つのフラグメントは実行されないことにも注意してください。たとえば、スクリプトレット変数の値を1つのフラグメントで宣言または設定して、別のフラグメントでその変数に依存したり値を設定したりすることは避けてください。 1つの変数が2つ以上のフラグメントで必要な場合は、テンプレート・コード(codeblockタグの内部など)で宣言および設定してください。同様に、1つのフラグメント内にリクエスト属性またはセッション属性を設定し、それを別のフラグメントで読み込むことは避けてください。 このような、グローバルなページ・ロジックは、テンプレート・レベルに配置してください。

最後に、あるページ内の異なるフラグメントは、失効化メッセージと期限切れ設定に応じて異なるタイミングでリフレッシュされることに注意してください。通常、適切にチューニングされたアプリケーションでは、ほとんどのフラグメントはESIキャッシュから提供されるため、頻繁に再生成する必要はありません。


注意:

OC4J 9.0.4の実装からは、JESIタグがJESI規則に従い、相互に適切にネストされている場合は、JESI templateタグ、JESI fragmentタグおよびJESI includeタグをjsp:includeタグとともに散在させることができます。 たとえば、あるページでJESI templateタグを使用したり、templateタグ内でjsp:includeタグを使用したり、インクルード・ページでJESI fragmentタグを使用できます。 上位レベルに他のtemplateタグがない場合、またレスポンス・バッファへのすべての出力がtemplateタグ内にある場合は、インクルード・ページ内でJESI templateタグも使用できます。


タグ構文と例は、次の各項を参照してください。

JESI includeおよびJSP includeについて

control/includeモデルとtemplate/fragmentモデルのどちらを使用する場合も、JESI include文については、次の点に注意してください。

キャッシュ内のオブジェクトの失効化

データベース内の関連データへの変更など、外部の状況によっては、キャッシュ内のオブジェクトを明示的に失効化する必要があります。また、あるページの実行によって、別のページに対応しているキャッシュ内のオブジェクトのデータが失効になる場合もあります。

このため、JESIには、JESI invalidateタグおよび関連するサブタグが用意されています。これらのタグを使用すると、次の適切な組合せに基づいてページを失効化できます。

失効化メッセージはXMLベースのフォーマットで、失効化する対象のURLを指定します。 このメッセージは、JESI invalidateタグの実行時にJSPコンテナで起動され、POSTメソッドによってHTTPを介してキャッシュ・サーバーにフォワードされます。次に、キャッシュ・サーバーが応答し、失効化レスポンスがHTTPを介して返信されます。

タグ構文と例は、「キャッシュ内のオブジェクトの失効化に使用するタグとサブタグの説明」を参照してください。

キャッシュ内のページのパーソナライズ

動的Webページには、個別のユーザーにあわせてカスタマイズされた情報が頻繁に表示されます。たとえば、「ようこそ」のページには、ユーザー名や特別な挨拶文、あるいはユーザーが所有している株式の現在の相場などが表示されます。

このようなカスタマイズされた出力の場合、Webページは、JESI personalizeタグによって提供されるCookie情報に依存します。このタグは、Cookieの置換を実行する必要のある状況をESIプロセッサに通知します。このタグがない場合は、Webページを複数のユーザーがESIレベルで共有できません。

タグ構文と例は、「ページのパーソナライズに使用するタグの説明」を参照してください。


注意:

このタグを、より多くの機能を持つOracleAS Personalizationタグ・ライブラリと混同しないでください。JESIによるパーソナライズは、キャッシュ内のページのプレースホルダを、ESIプロセッサがリクエスト時またはレスポンス時にCookieから送信される動的文字列に置換します。このプロセスによって、異なるユーザーが同じキャッシュ内のページを共有できます。バックエンドでデータ・マイニングを使用するOracleAS Personalizationのほうが、はるかに動的かつ包括的な機能です。この機能によって、ユーザー・アクティビティに応じて自動的に変化する出力が生成されます。


JESIフォールバックの実行

JESIタグを使用するページに対してESIプロセッサが使用可能でない場合(OracleAS Web Cacheがないシステムや、Web CacheまたはESIプロセッサがダウンしているシステムなど)、OC4J JSPコンテナは、ページを適切にアセンブルするためにステップ実行します。基本的にこのコンテナは、ページを正しく実行するために最も重要な機能を引き継ぎ、提供します。キャッシングは行われず、JESIタグ属性値のエラーチェックも行われません。

このような状況では、JSPコンテナは特定のJESIタグを次のように処理します。


注意:

この状況では、JESI include機能を使用する場合とは異なり、インクルード・ページに個別のレスポンス・オブジェクトはありません。


Oracle JESIタグの説明

次の項では、OC4Jが提供するJESIタグの構文と属性を説明し、使用例を示します。

JESIタグ・ライブラリについては、次の要件に注意してください。

taglibディレクティブ、予約済のタグ・ライブラリ・ディレクトリ、TLDファイルおよびuri値の意味の詳細は、『Oracle Application Server Containers for J2EE JavaServer Pages開発者ガイド』を参照してください。


注意:

  • このタグ構文では、接頭辞「jesi:」が使用されます。慣例的にこのように表記しますが、必須ではありません。 任意の接頭辞をtaglibディレクティブに指定できます。

  • このヘルプのタグ構文規則の詳細は、「タグ構文の表記と意味」を参照してください。


動的キャッシングに使用するタグの説明

次の項では、動的キャッシングでのJESIタグの使用方法およびその構文と属性を説明し、例を示します。

control/includeモデルおよびtemplate/fragmentモデルの概要は、「JESIの使用モデル」を参照してください。

JESI controlタグ

JESI controlタグは、control/include使用モデルでJSPページのキャッシュ動作を制御します。 JESI controlタグは、トップレベルのページまたは任意のインクルード・ページで使用できます。ただし、必須ではありません。 control/includeモデルでJESI controlタグがないページがキャッシュ可能かどうかは、ESIプロセッサの設定によって決まります。 (詳細は、「JESIの使用モデル」を参照してください。)

JESI controlタグの結果のアクションによって、HTTPレスポンス・ヘッダーが設定されるため、このタグは、ページ内の他のすべてのJESIタグまたはバッファ・フラッシュの前の、できるだけ先頭に近い位置に配置してください。

次の点に注意してください。

構文

 <jesi:control
              [ expiration = "value" ]
              [ maxRemovalDelay = "value" ]
              [ cache = "yes" | "no" | "no-remote" ]
              [ control = "uninterpreted_string" ] />      
属性


注意:

提案されているJESI仕様に準拠するために、これはOC4J 9.0.4より前の実装のデフォルト値である300から変更されました。



注意:


JESI includeタグ

JESI includeタグでは、標準のjsp:includeタグと同様に、インクルード・ページの出力をインクルード元のページの出力に動的に挿入できます。このタグは、ESIプロセッサにインクルード・ページの処理とアセンブルを指示することによってこの処理を行います。各インクルード・ページは、独立したキャッシュ可能オブジェクト(設定によっては、キャッシュ不可オブジェクト)です。

このタグは、次の使用例にあるcontrol/includeモデルまたはtemplate/fragmentモデルのいずれでも使用できます。

(詳細は、「JESIの使用モデル」を参照してください。)

また、JESI includeタグでインクルードされるページ内のJESI includeタグ、または標準のjsp:includeタグでインクルードされるページ内のJESI includeタグを使用して、JESI includeをネストできます。

インクルード・ページがキャッシュ可能かどうかは、次のように判断されます。

構文

 <jesi:include page = "uri"
             [ alt = "alternate_uri" ]
             [ ignoreError = "true" | "false" ]
             [ flush = "true" | "false" ]
             [ copyParam = "true" | "false" ] >
 
 ...optional jesi:param tags, related scriptlets... 
 </jesi:include>
 
      


注意:

  • 標準のjsp:includeタグおよびそのオプションのjsp:paramサブタグと同様に、JESI includeタグ内にネストされたJESI paramタグを使用して、インクルード元ページ(JESI includeタグのあるページ)に送信される新しいパラメータを指定できます。 タグ構文は、「JESI paramタグ」を参照してください。 また、JESI includeタグ・ボディには、追加されたパラメータの評価で使用されるスクリプトレット・コードが含まれることがあります。 ただし、スクリプトレット・コードからの出力、および一般にJESI includeタグ・ボディからの出力は、破棄されます。

  • 場合によっては、JESI includeタグはjsp:includeタグと異なる動作をします。 これは、JESI includeタグにより、インクルード・ページに対して別々のリクエスト・オブジェクトおよびレスポンス・オブジェクトが生成されるためです。 JESI includeタグは、たとえばインクルード元ページがリクエスト属性を設定し、インクルード・ページがこの属性をリクエスト・オブジェクトから読み取る場合には適していません。

  • 下位互換性を保つために、copyparam属性の推奨されない、copyparamフォームが受け入れられます。 copyparamからcopyParamへの変更は、提案されているJESI仕様に準拠するために行われました。 copyparamは将来サポートされなくなる可能性があります。


属性

JESI paramタグ

JESI paramタグは、JESI includeタグのオプションのサブタグです。 これらのタグは、標準のjsp:includeタグとjsp:paramタグが連動するのと同じように連動します。

1つ以上のJESI paramサブタグを使用して追加の問合せパラメータをJESI includeタグのターゲット・ページに渡すことができます。 この処理は、JESI includeタグのpage URIでパラメータを指定する別の方法よりも簡単です。 両方のメカニズムを使用する場合、paramタグからのパラメータは、includeタグのpage URIからのパラメータの後に追加されます。 includeタグのcopyParam="yes"設定を使用して元のリクエストからコピーされるパラメータは、JESI paramタグからのパラメータの後に追加されます。

サンプルは、「例5: paramタグでのcontrol/include」を参照してください。


注意:

パラメータ名と値は、インクルード元ページ(JESI includeタグとparamタグのあるページ)が生成される際に評価されます。その後、インクルード元ページがESIプロセッサにキャッシュされた場合は、パラメータの名前と値がインクルード・ページに渡され、インクルード元ページが再生成されるまで変更されません。 (これは、copyParam="true"設定でリクエストからコピーされるリクエスト・パラメータの扱いと同様です。)


構文

 <jesi:include page = "uri" ... >
    <jesi:param name="param_name"
          value="param_value" />
    ...
 </jesi:include>      
属性

例: control/includeモデル

この項では、control/includeモデルでのJESIタグの使用例を示します。

例1: control/include

次の例では、デフォルトのキャッシュ設定を使用します。JESI controlタグは不要です。 JESI includeタグは、代替ファイルを指定しません。したがって、「ファイルが見つかりません。」というエラーが発生すると処理は停止します。 flush属性は、使用できますが、無視されます。

 <%@ taglib uri="http://xmlns.oracle.com/j2ee/jsp/tld/ojsp/jesitaglib.tld"
            prefix="jesi" %>
 <html>
 <body>
 <jesi:include page="stocks.jsp" flush="true" />
 <p>
 <hr>
 <jesi:include page="/weather.jsp" flush="true" />
 <p>
 <hr>
 <jesi:include page="../sales.jsp" flush="true" />
 </body>
 </html>      
例2: control/include

この例では、JESI controlタグを使用し、maxRemovalDelayおよびexpirationに対して、デフォルト以外のキャッシュ設定を指定します。さらに、ページのキャッシングを明示的に有効にします。ただし、デフォルトですでに有効になっています。 最初のJESI includeタグは、ESIプロセッサがorder.jspを取得できない場合の代替ページを指定し、どのページも取得できない場合でも処理が続行されることを指定します。 第2のJESI includeタグは、代替ページを指定しません。したがって、ページを取得できない場合、処理は停止します。

 <%@ taglib uri="http://xmlns.oracle.com/j2ee/jsp/tld/ojsp/jesitaglib.tld"
            prefix="jesi" %>
 
 <jesi:control maxRemovalDelay="1000" expiration="300" cache="yes"/>
 <jesi:include page="order.jsp" alt="alt.jsp" ignoreError="true"/>
 <jesi:include page="commit.jsp" />      
例3: control/include

この例は、条件付きの出力を含む集計ページの例です。Cookieは、カスタマの識別情報を表します。Cookieが見つからない場合は、一般的な製品情報を含む一般的な「ようこそ」ページが表示されます。Cookieが見つかった場合は、ユーザー・プロファイルに基づいて製品リストが表示されます。 このリストは、JESI include文を使用してページに表示されます。

JESI controlタグは、maxRemovalDelayおよびexpirationに対してデフォルト以外の値も設定し、そのページのキャッシングを明示的に有効化します。

 <%@ taglib uri="http://xmlns.oracle.com/j2ee/jsp/tld/ojsp/jesitaglib.tld"
            prefix="jesi" %>
 
 <jesi:control maxRemovalDelay="1000" expiration="300" cache="yes"/>
 <%
   String customerId=CookieUtil.getCookieValue(request,"customerid");
 
   if (customerId==null) {
 
     // some unknown customer
 %>
     <jesi:include page="genericwelcome.jsp" />
 <%
   }
   else {
 
     // a known customer; trying to retrieve recommended products from profiling
 
     String recommendedProductsDescPages[]=
                ProfileUtil.getRecommendedProductsDescURL(customerId);
 
     for (int i=0; i < recommendedProductsDescPages.length; i++) {
 %>
     <jesi:include page="<%=recommendedProductsDescPages[i]%>" />
 <%
     }
   }
 %>      
例4: control/include

次に、リクエスト・パラメータを含むJESI include文の使用例を示します。メイン・ページには、次のURLからアクセスすると想定します。

 http://host:port/application1/main.jsp?p2=abc
 
      

メイン・ページは、パラメータ設定p2=abcを取得します。ページは次のとおりです。

 <%@ taglib uri="http://xmlns.oracle.com/j2ee/jsp/tld/ojsp/jesitaglib.tld"
            prefix="jesi" %>
 <html>
 <jesi:control cache="no" />
 <jesi:include page="a.jsp?p1=v1" />
 <h3>hello ...</h3>
 <jesi:include page="b.jsp" />
 <h3>world ...</h3>
 <jesi:include page="c.jsp?p1=v2" copyParam="true" />
 </html>
 
      

a.jspページは、パラメータ設定p1=v1を取得します。 c.jspページは、設定p1=v2に加えて設定p2=abcを(copyParam、およびメイン・ページのURLにp2を設定した結果として)取得します。

さらに、トップレベル・ページは、cache="no"の設定によって、キャッシュ不可です。 実際には、このようにインクルード元ページがキャッシュ不可の場合のみ、JESI includeタグでcopyParam設定を使用することに注意してください。これはリクエスト属性がリクエストのたびに変わるためです。 また、このcache="no"設定は、インクルード・ページには効果がないことにも注意してください。インクルード・ページは、デフォルトでキャッシュ可能な状態です。 つまり、それぞれのインクルード・ページ自体に、cache="no"設定を含むJESI controlタグがないかぎり、キャッシュ可能です。

例5: paramタグでのcontrol/include

この例は、JESI paramタグを使用してランタイム値を新しいパラメータとしてインクルード・ページ・リクエストに追加する方法を示しています。 メイン・ページは次のようなURLでアクセスされ、パラメータ設定p1=v1を受け取ります。

 http://host:port/application/main.jsp?p1=v1
 
      

ページは次のとおりです。

 <jesi:control cache="yes" />
 <jesi:include page="a.jsp" >
    <% String v2 = null;
       if(request.getParameter("p1").equals("v1")
           v2 = "v1 set";
       else
           v2 = "v2 unset";
    %>
    <jesi:param name="p2" value="<%=v2%>" />
 </jesi:include>      

JESI templateタグ

template/fragmentの使用モデルで、テンプレートのコンテンツ(フラグメント以外)のキャッシング動作を指定するには、JESI templateタグを使用します。 (詳細は、「JESIの使用モデル」を参照してください。)対応するHTTPヘッダーは、ESI仕様に基づいて設定されます。 フラグメント以外のコンテンツは、ここではテンプレート・コンテンツと呼び、JESI fragmentタグで除外される各フラグメントのコンテンツは、別のキャッシュ可能オブジェクトです。


重要:

すべてのレスポンス出力は、template開始タグと終了タグの間に生成される必要があります。 JESI template開始タグは、できるだけページの先頭近くに配置してください。 このタグは、ページ内のどのJESI fragmentタグまたはバッファ・フラッシュよりも前にある必要があります。また、テキスト、HTMLマークアップ、改行、空白などの他の可視出力コンテンツよりも前にある必要があります。 JESI template終了タグは、すべてのJESI fragmentタグおよびその他の可視出力コンテンツの後の、ページ内のできるだけ後方に配置する必要があります。


JESI templateタグは、必ずJESI fragmentタグとともに使用します。 個別のフラグメントが不要な場合は、JESI templateタグではなく、JESI controlタグを使用します。

次の点に注意してください。


注意:

この状況では、templateタグは完全には無視されません。 JESI controlタグも使用するページでtemplate/fragmentモデルが使用されている場合(この状況は、templateタグのあるページが動的にインクルードされる場合に発生することがあり、通常は条件付きです)、JSPコンテナは、必要に応じて任意のfragmentタグを正しく囲むtemplateタグがあるという事実に注目します。


JESI templateタグには、JESI controlタグの場合と同じ使用方法で同じ属性を指定します。

構文

 <jesi:template
              [ expiration = "value" ]
              [ maxRemovalDelay = "value" ]
              [ cache = "yes" | "no" | "no-remote" ]
              [ control = "uninterpreted_string" ] >
 
 ...page content, jesi:fragment tags, optional jesi:include tags, optional
jesi:codeblock tags.. 
 </jesi:template>      
属性

属性の説明は、「JESI controlタグ」を参照してください。

JESI fragmentタグ

template/fragmentモデルでは、1つ以上のJESI fragmentタグを、JESI templateタグ内、つまりJESI templateの開始タグと終了タグ間で使用します。 (詳細は、「JESIの使用モデル」を参照してください。) 各JESI fragmentタグは、必要に応じて、JSPページの個別のフラグメントのキャッシング動作を定義します。各フラグメントは独立したキャッシュ可能オブジェクトです。

特定のフラグメントがESIメカニズムによって集計レスポンスへのインクルードをリクエストされると、ESIプロセッサは、そのフラグメントのみを取得します。

JESI fragmentタグには、JESI controlタグおよびJESI templateタグの場合と同じ使用方法で同じ属性を指定します。

次の点に注意してください。

構文

 <jesi:fragment
              [ expiration = "value" ]
              [ maxRemovalDelay = "value" ]
              [ cache = "yes" | "no" | "no-remote" ]
              [ control = "uninterpreted_string" ] >
 
 ...JSP code fragment...
 
 </jesi:fragment>      
属性

属性の説明は、「JESI controlタグ」を参照してください。

JESI codeblockタグ

template/fragmentモデルでは、必要に応じてフラグメント以外のテンプレート・コード内で1つ以上のJESI codeblockタグを使用して、特定のコードのブロックの条件付き実行を指定できます。 各codeblockタグは、コード・ブロックを囲み、そのブロックをいつ実行する必要があるかを指定します。

または

または

このタグを使用しないと、すべてのテンプレート・コードがすべてのリクエスト(テンプレートの各リクエストとフラグメントの各リクエスト)で実行されますが、フラグメントのリクエストの場合、テンプレート出力は廃棄されます。

フラグメントがリクエストされるたびにテンプレートを実行して、フラグメントが変数の宣言や初期化などのテンプレート・コードの副次的効果に依存できるようにすることが重要ですが、フラグメントに必要でないコード・ブロックがある場合があります。 テンプレートがリクエストされた場合にのみブロックを実行するように指定して、このようなコード・ブロックをcodeblockタグに配置できます。

または、すべてのフラグメントに必要な可能性があり、テンプレート自体には必要でないテンプレート・コードのブロックがある場合があります。 フラグメントがリクエストされた場合にのみブロックを実行するように指定して、このようなコード・ブロックをcodeblockタグに配置できます。


注意:

JESI codeblockタグ内では可視出力を生成しないことをお薦めします。これにより、テンプレートのリクエストとフラグメントのリクエスト間の実行の違いによる予期しない動作を回避できます。 execute="template"(またはalways)を指定してテンプレートがリクエストされた場合は、おそらく意図されているように、コードが実行され、コンテンツが出力されます。 ただし、execute="fragment"(またはalways)が指定され、リクエストがフラグメントに対するものである場合、フラグメントがリクエストされた場合に常にそうであるように、コードは実行されますが、テンプレートの出力全体が抑制されます。 「template/fragmentモデル」図 3を参照してください。


構文

 <jesi:template ... >
 ...
    <jesi:codeblock execute = "template" | "fragment" | "always" >       ...request-dependent JSP content...
    </jesi:codeblock> ...
 </jesi:template>      
属性

例: template/fragmentモデル

この項では、template/fragmentモデルでのJESIタグの使用例を示します。

例1: template/fragment

この例は、JESI templateタグとJESI fragmentタグの一般的な使用例です。 タグにはexpiration属性のみが設定されているため、他のすべての設定はデフォルトに従います。 cache属性の設定はデフォルトで「yes」になるため、テンプレートと3つのフラグメントがすべてキャッシュされます。

テンプレート・コンテンツ(フラグメント以外)には、JESI templateタグに基づいて、3600秒の期限切れ時間が使用されています。この期限切れの設定は、フラグメント以外のすべてのHTMLブロックに適用されます。JSPコード・ブロック#1は期限切れ設定60で、JSPコード・ブロック#2はデフォルトの期限切れ設定で、JSPコード・ブロック#3は期限切れ設定600でそれぞれキャッシュされます。

 <%@ taglib uri="http://xmlns.oracle.com/j2ee/jsp/tld/ojsp/jesitaglib.tld"
            prefix="jesi" %>
 <jesi:template expiration="3600">
 ...HTML block #1...
    <jesi:fragment expiration="60">
    ...JSP code block #1...
    </jesi:fragment>
 ...HTML block #2...
    <jesi:fragment>
    ...JSP code block #2...
    </jesi:fragment>
 ...HTML block #3...
   <jesi:fragment expiration="600">
    ...JSP code block #3...
    </jesi:fragment>
 ...HTML block #4...
 </jesi:template>       
例2: template/fragment

この例では、フラグメント内でJESI includeタグを使用します。次に、このページのキャッシュ可能オブジェクトを示します。

 <%@ taglib uri="http://xmlns.oracle.com/j2ee/jsp/tld/ojsp/jesitaglib.tld"
            prefix="jesi" %>
 <jesi:template expiration="3600">
 ...HTML block #1...
    <jesi:fragment expiration="60">
    ...JSP code block #1...
    <jesi:include page="stocks.jsp" />
    </jesi:fragment>
 ...HTML block #2...
    <jesi:fragment>
    ...JSP code block #2...
    <jesi:include page="/weather.jsp" />
    </jesi:fragment>
 ...HTML block #3...
    <jesi:fragment expiration="600">
    ...JSP code block #3...
    <jesi:include page="../sales.jsp" />
    </jesi:fragment>
 ...HTML block #4...
 </jesi:template>      
例3: codeblockのあるtemplate/fragmentモデル

これは、template/fragmentモデルでのcodeblockタグの使用方法に関する概念的な例です。この場合、パフォーマンスを改善するには、データベースに接続するコードはコード・ブロックに配置されるため、不必要に再実行されることはありません。

 <%@ taglib uri="http://xmlns.oracle.com/j2ee/jsp/tld/ojsp/jesitaglib.tld"
            prefix="jesi" %>
 <jesi:template>
 Welcome to the Frequent Flyer Home page!
 <jesi:codeblock execute="fragment" >
   /* Open a database connection and store it in the variable dbConn. */
 </jesi:codeblock>
 BEST DEALS
 <jesi:fragment expiration="600" maxRemovalDelay="180">
 ...in Air Travel
 /* Select the three cheapest USA domestic round-trip fares, using the database
connection stored in dbConn. */
 </jesi:fragment>
 
 <jesi:fragment expiration="600" maxRemovalDelay="180">
 ...in Accommodations
 /* select the three best hotel deals, using the database connection stored in
dbConn. */
 </jesi:fragment>
 
 Click here to access your current Mileage account <...>
 </jesi:template>      

キャッシュ内のオブジェクトの失効化に使用するタグとサブタグの説明

ESIプロセッサでキャッシュ内のオブジェクトを明示的に失効させるには、JESI invalidateタグと、必要に応じて、次のサブタグを使用します。

次の項では、これらのタグの構文、JESI構成ファイル(ユーザー名、パスワード、および失効化のためにログインするURLの指定に使用できます)およびいくつかの例を示します。

概要は、「キャッシュ内のオブジェクトの失効化」を参照してください。

JESI invalidateタグ

JESI invalidateタグをそのJESI objectサブタグとともに使用すると、1つ以上のキャッシュ内のオブジェクトを明示的に失効させることができます。

サブタグは、次のように使用します。

構文

 <jesi:invalidate
              [ url = "url"
                username = "user_name"
                password = "password" ]
              [ config = "configfilename" ]
              [ output = "browser" ] >
 
      

必須サブタグ(「JESI objectサブタグ」を参照)

              <jesi:object ... >
 
      

JESI objectのオプションのサブタグ(「JESI cookieサブタグ」を参照)

                    <jesi:cookie ... />
 
      

JESI objectのオプションのサブタグ(「JESI headerサブタグ」を参照)

                    <jesi:header ... />
 
              </jesi:object>
 
 </jesi:invalidate>
 
      

ユーザー、パスワードおよびURLのすべてを、それぞれ個別の属性を使用して指定するか、config属性で参照されている、またはデフォルトの場所にある構成ファイルに指定します。 デフォルトの場所は、/WEB-INF/jesi.xml、または下位互換性を維持するための/WEB-INF/config.xmlです。 ファイルの詳細は、「JESI構成ファイル」を参照してください。ユーザー名、パスワードおよびURLが構成ファイルおよび属性設定で指定されている場合は、属性設定が優先されます。

OC4J jazn-data.xmlファイルでOracleAS Web Cacheのinvalidatorアカウントに<user>要素を指定した場合は、password属性で特殊な構文を使用して、クリア・テキストでパスワードを指定するかわりにjazn-data.xmlで情報を参照できます。 パスワードは、曖昧化形式でjazn-data.xmlに指定されています。 次のusername属性とpassword属性の説明を参照してください。 jazn-data.xmlファイルの詳細は、『Oracle Application Server Containers for J2EEセキュリティ・ガイド』を参照してください。


注意:

invalidateタグ内で複数のobjectタグを使用することは可能です。


属性

JESI構成ファイル

提案されているJESI仕様では、構成ファイルの使用がサポートされます。現在は、失効化のユーザー名、パスワードおよびURLを指定するには構成ファイルのみを使用できます。 (または、各JESI invalidateタグの属性でユーザー名、パスワードおよびURLを指定できます。 「JESI invalidateタグ」を参照してください。

JESI構成ファイルには、<jesi-config>トップレベル要素、その下の<invalidation>サブ要素および<invalidation>要素の下の<username><password><url>のサブ要素が必要です。


注意:

下位互換性を保つために、推奨されない要素<ojsp-config>および<web-cache>は、現在それぞれ<jesi-config>および<invalidation>のかわりに受け入れられます。新規要素は、提案されているJESI仕様に準拠するためにあります。 <ojsp-config>および<web-cache>は将来のリリースでサポートされなくなる可能性があります。


現在の実装では、2つの可能なデフォルト・ファイルがあります。または、アプリケーション内の任意の場所にファイルを配置し、その名前と場所をinvalidateタグのconfig属性にアプリケーション相対位置またはページ相対位置で指定できます。

OC4J 9.0.4実装では、優先されるデフォルト・ファイルは、提案されているJESI仕様に準拠している/WEB-INF/jesi.xmlです。 下位互換性を保つために、以前のデフォルト・ファイルである/WEB-INF/config.xmlもサポートされています。

次の手順は、失効化のユーザー名、パスワードおよびURLを取得するために使用されます。

  1. JESI invalidateタグでusername属性、password属性およびurl属性(3つすべて)が指定されている場合は、それらの値が使用されます。


注意:

invalidateタグでこれらの属性の3つすべてではなく1つまたは2つが指定されている場合は、例外が発生します。例外は、属性値の1つ以上が空の文字列またはNULLの場合にも発生します。


  1. invalidateタグにusernamepasswordおよびurlを指定せず、config属性で構成ファイルを指定している場合は、指定された構成ファイルの値が使用されます。

  2. invalidateタグでusernamepasswordurlおよびconfigが指定されていない場合、JSPコンテナはデフォルトの構成ファイルの使用を試みます。 最初に、コンテナは/WEB-INF/jesi.xmlを検索し、見つかった場合はそのファイルの設定を使用します。 そのファイルが見つからない場合、コンテナは/WEB-INF/config.xmlを検索し、見つかった場合はそのファイルの設定を使用します。


注意:

invalidateタグでユーザー名、パスワードおよびURLが指定されていない場合は、次のいずれかの条件で例外がスローされます。

  • 任意の時点で、3つの属性のいずれかが指定されていない構成ファイルが見つかった場合

  • 構成ファイルが見つからない場合


OC4J jazn-data.xmlファイルにOracleAS Web Cacheのinvalidatorアカウントの<user>要素が含まれている場合は、JESI構成ファイルでそのアカウント名を使用し、ダッシュ(-)と右山カッコ(>)の後に失効化アカウント名を付けた特殊な右矢印構文を使用して、パスワードをjazn-data.xmlから取得できます。 後述の「例2: jazn-data.xmlからパスワードを取得する構成ファイル」を参照してください。

例1: パスワードがクリア・テキストの構成ファイル

次の例では、URLとログイン情報の設定用に、url属性、username属性およびpassword属性のかわりに使用する構成ファイルを示します。

 <?xml version="1.0" ?>
 <jesi-config>
   <invalidation>
       <url>http://yourhost.yourcompany.com:4001</url>
       <username>invalidator</username>
       <password>invpwd</password>
   </invalidation>
 </jesi-config>      
例2: jazn-data.xmlからパスワードを取得する構成ファイル

次の例では、クリア・テキストを使用してパスワードを指定するかわりに、特殊な->構文を使用してjazn-data.xmlファイルから曖昧化されていないパスワードを取得します。 この例では、jazn-data.xmlにOracleAS Web Cacheのinvalidatorアカウントの<user>要素が含まれていることを想定します。

 <?xml version="1.0" ?>
 <jesi-config>
   <invalidation>
       <url>http://yourhost.yourcompany.com:4001</url>
       <username>invalidator</username>
       <password>->invalidator</password>
   </invalidation>
 </jesi-config>      

JESI objectサブタグ

完全なURIまたはURI接頭辞に基づいて、失効させるキャッシュ内のオブジェクトを指定するには、JESI invalidateタグの必須サブタグJESI objectを使用します。 必要に応じて、JESI cookieサブタグまたはJESI headerサブタグ(またはその両方)を使用し、CookieまたはHTTPヘッダー情報に基づいて失効化の追加基準を指定します。

uri属性の設定に、完全なURIまたはURI接頭辞のいずれかを指定します。 このフィールドが完全なURIまたは接頭辞として解析されるかどうかは、prefix属性の設定によって決まります。

構文

 <jesi:object uri = "uri_or_uriprefix"
            [ maxRemovalDelay = "value" ]
            [ prefix = "yes" | "no" ] >
 
      

オプションのサブタグ(「JESI cookieサブタグ」を参照)

                    <jesi:cookie ... />
 
      

オプションのサブタグ(「JESI headerサブタグ」を参照)

                    <jesi:header ... />
 
 </jesi:object>
 
      

次に、どちらのサブタグも使用しない場合の構文を示します。

 <jesi:object uri = "uri_or_uriprefix"
            [ maxRemovalDelay = "value" ]
            [ prefix = "yes" | "no"] />
 
      


注意:

  • invalidateタグ内で複数のobjectタグを使用することは可能です。

  • objectタグ内で複数のcookieタグまたはheaderタグを使用することは可能です。


属性

JESI cookieサブタグ

失効化の追加基準としてCookie情報を使用する場合は、JESI objectタグ(JESI invalidateタグのサブタグ)の1つ以上のJESI cookieサブタグを使用します。 このCookie情報は、JESI objectタグでのURIまたはURI接頭辞の設定に加えて使用されます。JESI headerタグに加えて使用される場合もあります。 cookieタグは、Cookie情報に基づいて、複数のキャッシュ・バージョンを持つオブジェクトを失効させる場合に役立ちます。

cookieタグにボディはありません。

構文

 <jesi:cookie name = "cookie_name"
            [ value = "cookie_value" ] />
 
      


注意:

  • objectタグ内で複数のcookieタグを使用することは可能です。

  • 他のほとんどのJESIタグ属性とは異なり、value属性にはNULLまたは空の文字列値を指定できます。


属性

使用する各cookieサブタグについて、失効させるオブジェクトのリクエストURLには、name属性設定およびvalue属性設定(指定されている場合)と一致するCookieが必要です。

JESI headerサブタグ

失効化の追加基準としてHTTP/1.1ヘッダー情報を使用する場合は、JESI objectタグ(JESI invalidateタグのサブタグ)の1つ以上のJESI headerサブタグを使用します。 このヘッダー情報は、JESI objectタグでのURIまたはURI接頭辞の設定に加えて使用されます。JESI cookieタグに加えて使用される場合もあります。 headerタグは、ヘッダー情報に基づいて、複数のキャッシュ・バージョンを持つオブジェクトを失効させる場合に役立ちます。

headerタグにボディはありません。

構文

 <jesi:header name = "header_name"
              value = "header_value" />
 
      


注意:

objectタグ内で複数のheaderタグを使用することは可能です。


属性

使用する各headerサブタグについて、失効させるオブジェクトのリクエストURLに、name属性設定およびvalue属性設定と一致するヘッダーが必要です。

例: ページの失効化

この項では、JESI invalidateタグ、そのサブタグJESI objectおよびJESI objectタグのJESI cookieサブタグを使用したページの失効化の例を示します。

例1: ページの失効化

この例では、完全なURIによって指定された、ESIプロセッサ内のシングル・オブジェクトを失効化します。 (デフォルトでは、objectタグのuri属性は、URI接頭辞ではなく、完全なURIを指定します。) JESI invalidateタグは、キャッシュ・サーバーのURL、および失効化アカウントのユーザー名とパスワードも指定します。また、キャッシュ・サーバーからの失効化レスポンスをユーザーのブラウザに表示する必要があることも指定します。

 ...
 <jesi:invalidate url="http://yourhost.yourcompany.com:4001"
                  username="invalidator" password="invpwd"
                  output="browser">
      <jesi:object uri="/images/logo.gif"/>
 </jesi:invalidate>
 ...      
例2: ページの失効化

この例は、直前の「例1: ページの失効化」と同じです。ただし、構成ファイルを使用してキャッシュ・サーバーURLとログイン情報を指定します。

 ...
 <jesi:invalidate config="/myconfig.xml" output="browser">
      <jesi:object uri="/images/logo.gif"/>
 </jesi:invalidate>
 ...
 
      

JESI invalidateタグでは、構成ファイルのアプリケーション相対位置を指定します。 たとえば、myconfig.xmlには、次のようなコンテンツがあります。

 <?xml version="1.0" ?>
 <jesi-config>
   <invalidation>
       <url>http://yourhost.yourcompany.com:4001</url>
       <username>invalidator</username>
       <password>invpwd</password>
   </invalidation>
 </jesi-config>      
例3: ページの失効化

この例では、URI接頭辞「/」に従って、ESIプロセッサ内の全オブジェクトを失効させます。この例では、ブラウザでの失効化レスポンスの表示は指定していません。したがって、このレスポンスはまったく表示されません。

 ...
 <jesi:invalidate url="http://yourhost.yourcompany.com:4001"
                  username="invalidator" password="invpwd">
      <jesi:object uri="/" prefix="yes"/>
 </jesi:invalidate>
 ...      
例4: ページの失効化

この例では、シングル・オブジェクトを失効化します。ただし、このオブジェクトは最大30分(1800秒)間は有効状態を維持できます。

 ...
 <jesi:invalidate url="http://yourhost.yourcompany.com:4001"
                  username="invalidator" password="invpwd">
      <jesi:object uri="/images/logo.gif" maxRemovalDelay="1800"/>
 </jesi:invalidate>
 ...      
例5: ページの失効化

この例では、「例1: ページの失効化」と同じオブジェクトに失効化を指定します。ただし、リクエストURLに値customerを持つuser_typeという名前のCookieがある場合のみ、そのオブジェクトを失効させることを指定します。

 ...
 <jesi:invalidate url="http://yourhost.yourcompany.com:4001"
                  username="invalidator" password="invpwd">
      <jesi:object uri="/images/logo.gif">
           <jesi:cookie name="user_type" value="customer"/>
      </jesi:object>
 </jesi:invalidate>
 ...      

ページのパーソナライズに使用するタグの説明

同じキャッシュ内のページが複数のユーザー間で共有されている状態で、ページのカスタマイズを許可するには、そのページによるCookie情報とセッション情報への依存性をESIプロセッサに通知する必要があります。たとえば、Cookie値の置換は、Webサーバーではなく、ESIプロセッサで発生します。

JESI personalizeタグ

JESI personalizeタグを使用すると、キャッシュ内のページを提供する前に現在のリクエストのCookie値を置換するようESIプロセッサに指示するで、ページをカスタマイズできます。

このタグの効果は、ESIプレースホルダをCookie名および値とともにレスポンス・ボディに挿入することです。 name属性で指定されたCookieがリクエスト内にあり、NULL以外の値が指定されている場合は、その値が使用されます。 Cookieがリクエストにないか、NULL値であっても、値がdefault属性で指定されている場合は、新しいCookieが作成され、default値が使用されます。 Cookieが以前に存在せず、default値が指定されていない場合、タグを使用しても効果はありません。

personalizeタグにボディはありません。

構文

 <jesi:personalize name = "cookie_name"
                 [ default = "default_value" ] />
 
      


注意:

下位互換性を保つために、default属性の推奨されない「value」フォームが受け入れられます。 valueからdefaultへの変更は、提案されているJESI仕様に準拠するために行われました。 valueは将来のリリースでサポートされなくなる可能性があります。


属性

例: ページのパーソナライズ

次の例は、JESI personalizeタグの使用方法を示しています。

 <jesi:personalize name="user_id" default="guest" />
 
      

生成されたESIタグによって、ESIプロセッサは必要な情報を検出できます。 この場合、プロセッサは、user_idという名前のCookieを検索し、その値を取得します。 このCookieが見つからない場合は、デフォルト値の「guest」を使用します。

ESIプロセッサでのこのCookie値置換の処理により、ESIプロセッサは、アプリケーション・サーバーを関与させずに単一のキャッシュされたコピーから複数のカスタマイズされたページを処理できます。

JESIタグの処理とJESIとESI間での変換

JESIタグ・ハンドラ・クラスは、OC4JのJESIタグ・ライブラリの一部として提供され、JSP機能からESI機能へのブリッジの役を果たします。タグ・ハンドラでは、JESIタグからのESIタグの生成、失効化に対するHTTPリクエストの生成、HTTPレスポンス・ヘッダーの設定などをします。ただし、この変換は、JESIタグとESIタグの間またはJESIタグ属性とESIタグ属性の間の単純な1対1のマッピングとはかぎりません。

例: JESIとESI間でのインクルード・ページの変換

JESIとESI間での変換の例として、次のJSPコードを示します。

 <p>BEGIN</p>
 <jesi:control cache="no"/>
 <jesi:include page="stocks.jsp" flush="true" />
 <p>
 <hr>
 <jesi:include page="/weather.jsp" copyParam="true" flush="true" />
 <p>
 <hr>
 <jesi:include page="../sales.jsp?tax=local" copyParam="true" flush="true" />
 <p>END</p>
 
      

このJSPコードは、次のURLを含むページの一部と想定します。

 http://host:port/application1/top.jsp
 
      

さらに次のリクエストを想定します。

 http://host:port/application1/top.jsp?city=Washington_DC
 
      

この場合、JESI includeタグ・ハンドラは、次のレスポンスのように、ESIマークアップを生成します。

レスポンス・ヘッダーは、次のとおりです。

 Surrogate-Control: content="ESI/1.0",max-age=86400+0,no-store
 
      

レスポンス・ボディは、次のとおりです。

 <p>BEGIN</p>
 <esi:include src="/application1/stocks.jsp"/>
 
 <p>
 <hr>
 <esi:include src="/weather.jsp?city=Washington_DC"/>
 
 <p>
 <hr>
 <esi:include src="/sales.jsp?tax=local&city=Washington_DC"/>
 
 <p>END</p>
 
      

このレスポンスは、クライアントに配信される前に、ESIプロセッサによって読み込まれます。 Surrogate-Controlヘッダーは、ESIプロセッサに対して、レスポンス・ボディにESIマークアップが含まれていることを警告します。したがって、キャッシング機能では、ESIタグのレスポンス・ボディ内を検索します。 また、Surrogate-Controlヘッダーは、cache="no"属性設定に従ってキャッシュ・ディレクティブをno-storeに設定します。期限切れと最大遅延間隔はこのケースに影響しません。

3つの各esi:includeタグに対して、ESIプロセッサは、指定されたURLに追加リクエストを作成します。各レスポンスは、トップレベルのページにインクルードされ、そのページがアセンブルされた後でのみ、クライアントに配信されます。クライアントが受信するレスポンスは1つですが、キャッシュでは、そのレスポンスを取得するために4つのリクエストが最初に作成されます。 この操作は、オーバーヘッドが大きいように見えますが、weather.jspなどのように、他の多数のリクエストによって同じインクルード・ページが使用される場合は、全体の効率が向上します。これらのページは、ESIプロセッサ上で個別にキャッシュされるため、これらのページに対するリクエストは不要です。

例: JESIとESI間でのテンプレートとフラグメントの変換

従業員が企業イントラネット・サイトに接続する場合を想定します。すべてのレスポンスに存在する少数の機能を除いて、そのページのコンテンツは動的です。特に、株式チャートとその企業に関する最新のビジネス見出しを表示するフッターは常に存在しています。このビジネス見出しは外部のビジネス・ニュース・サイトから取得されます。戻すページのすべてに同じ情報が含まれている必要があり、取得にはコストがかかるため、このフッターはESIプロセッサ上でキャッシュするほうが効率的です。

ページ・レスポンスの残りの部分は動的で、毎回わずかに異なる方法で株式のフラグメントが取り込まれます。ページの再書込みを回避するために、フッターにJESIフラグメントのマークを、それを囲んでいるページにJESIテンプレートのマークを付けることができます。

チャリティ・キャンペーンの期間中、主催者が目標金額と現在の寄付金額を示す棒グラフを、すべての企業ページの一部として表示すると想定します。この情報は、特別のデータベース・テーブルに格納されており、毎日2回更新されています。この棒グラフは、JESIフラグメントの追加として適切な候補です。 JESI templateタグをページの最上部に追加し、JESI fragmentタグを使用して、個別エンティティとしてキャッシュするフラグメントを囲みます。

企業ページへのURLは、次のURLと想定します。

 http://www.bigcorp.com/employee_page.jsp
 
      

さらに、そのページを次のように変更したと想定します。

 <%@ taglib uri="http://xmlns.oracle.com/j2ee/jsp/tld/ojsp/jesitaglib.tld"
            prefix="jesi" %>
 <jesi:template cache="no" >
 
 <p>BEGIN</p>
 ... some dynamic page content...  <jesi:fragment>
 This_is_the_body_of_Charity_Chart  </jesi:fragment>
 ... some more dynamic content...  <jesi:fragment>
 This_is_the_body_of_Business_Footer  </jesi:fragment>
 </jesi:template>
 <p>END</p>
 
      

ページのリクエスト時に、次のHTTPレスポンスが生成されます。

レスポンス・ヘッダーは、次のとおりです。

 Surrogate-Control: content="ESI/1.0",max-age=86400+0,no-store
 
      

レスポンス・ボディは、次のとおりです。

 <p>BEGIN</p>
 ... some dynamic page content...  <esi:include src="/employee_page.jsp?__esi_fragment=1"/>
 ... some more dynamic content...  <esi:include src="/employee_page.jsp?__esi_fragment=2"/>
 <p>END</p>
 
      

「例: JESIとESI間でのインクルード・ページの変換」に示したJESI includeの例と同様に、Surrogate-Controlレスポンス・ヘッダーはESIプロセッサに対して警告を通知します。 no-storeディレクティブが生成された理由は、JESI templateタグにcache="no"の設定があるためです。

ESIプロセッサは、2つのリクエストを追加作成し、2つのフラグメントをフェッチしてキャッシュします。その後で、合成されたページが従業員に戻されます。従業員がそのページで再度作業をすると、動的コンテンツが新規に生成されます。ただし、チャートとフッターはキャッシュから提供されます。


注意:

Surrogate-Controlヘッダーは、ESIプロセッサによって使用され、クライアントへの最終レスポンスには表示されません。


 

Copyright © 1997, 2004, Oracle. All rights reserved.