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

部品番号: B10319-01


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

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

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

OracleAS Web Cache、Oracle Application Server Java Object CacheおよびOC4J Web Object Cacheの説明を含むWebキャッシュの概要は、「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サーバーから離れたネットワークの端点で動的コンテンツのアセンブリを実行できます。また、この言語は、Webキャッシュやコンテンツ配信ネットワーク(CDN)などの使用可能なツールを活用して、ユーザーのパフォーマンスを向上させるように設計されています。

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

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

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


注意:

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


サロゲートの詳細

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

サロゲートでのキャッシュ・プロセスでは、HTTPでのキャッシュ・プロセスに類似した動作が行われます。どちらも、類似した鮮度および検証メカニズムを基盤として使用しています。ただし、サロゲートには、その上に制御メカニズムも備わっています。

ESIの主要機能

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

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

esiincl.gifのテキスト説明が続きます。

図esiincl.gifのテキスト説明

OracleAS Web CacheおよびESIプロセッサ

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

OracleAS Web Cacheの概要

Oracleでは、E-BusinessにおけるWebサイト・パフォーマンスの問題の管理を支援するために、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に送信します。すると、OracleAS 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環境の開発者は、アプリケーションでESI言語を直接使用できます。ただし、JSP開発者の場合は、様々な理由から、ESI言語に対する便利なJSPインタフェースとして提供されているJESIタグ・ライブラリを使用します。「JESIタグのメリット」を参照してください。

JESI機能の概要

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

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

 http://www.esi.org
      

JESIタグのメリット

OC4Jでは、JESIタグ・ライブラリを、ESIタグとWebキャッシュに関するEdge Side Includes機能への便利なインタフェースとして提供しています。開発者は、WebアプリケーションでESIタグを直接使用できますが、JSPページではJESIタグを使用したほうが便利です。次に、ESIタグを直接使用せずに、JESIタグを使用する主なメリットについて説明します。

Oracleで実装されるJESIタグの概要

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

 http://www.jcp.org
 
      

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

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

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


注意:

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


JESIの使用モデル

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

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

control/includeモデル

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

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

状況によっては、どちらのタグもオプションになります。ページには、JESI controlタグを、JESI includeタグなしで指定できます。実際に、これが既存のページを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プロセッサは、起点サーバー(Oracle Application Serverの場合はOC4J)に新しいコピーをリクエストします。

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

図2 JESIテンプレート・リクエスト

jesitreq.gifのテキスト説明が続きます。

図jesitreq.gifのテキスト説明

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

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

図3 JESIフラグメント・リクエスト

jesifreq.gifのテキスト説明が続きます。

図jesifreq.gifの説明


注意:

コストのかかるテンプレート・コードの実行が不必要に反復されないように、コードはJESI codeblockタグ内に戦略的に配置してください。各codeblockタグは、中のコードを実行する必要のあるタイミング(テンプレートのリクエスト時、フラグメントのリクエスト時または常時)に従って構成します。


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

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

図5に、codeblockタグのもう1つの使用例を示します。この例でも、コード・ブロックはフラグメントのリクエスト時にのみ実行されます。ただし、この図では、リクエストはフラグメントに関するものであるため、コード・ブロックが実行されます。

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

jesicbt.gifのテキスト説明が続きます。

図jesicbt.gifの説明

図5 フラグメント・リクエストによるJESI codeblockフラグメントの実行

jesicbf.gifのテキスト説明が続きます。

図jesicbf.gifの説明

また、同一リクエスト時に、2つのフラグメントは実行されないことに注意してください。たとえば、スクリプトレット変数の値を1つのフラグメントで宣言または設定して、別のフラグメントでその変数または設定値に依存することは避けてください。1つの変数が複数のフラグメントで必要な場合は、テンプレート・コード(可能であれば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およびJSP Includesに関する注意

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 Containers for J2EE Support for 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タグを介してインクルードされるページにJESI includeタグを使用する方法と、標準jsp: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は、ユーザーのIDを表します。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を(メイン・ページのURLにcopyParamおよびp2を設定した結果として)取得します。

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

例5: paramタグを使用したcontrol/include

次に、インクルード・ページ・リクエストに新規パラメータとしてランタイム値を追加するJESI paramタグの使用例を示します。メイン・ページには、パラメータ設定p1=v1を使用して次のようなURLからアクセスすると想定します。

 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モデルでは、JESI templateタグ内のJESI templateの開始タグと終了タグの間で、1つ以上のJESI fragmentタグを使用します。(「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タグは1つのコード・ブロックを囲み、その実行のタイミングを次のように指定します。

または

または

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

フラグメントがリクエストされるたびにテンプレートを実行することが重要ですが(フラグメントが変数宣言や初期化のようなテンプレート・コードの副次効果に依存できるようにするため)、フラグメントに重要でないコード・ブロックも存在する場合があります。このようなコード・ブロックを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のsystem-jazn-data.xmlファイル内でOracleAS Web Cacheの「invalidator」アカウント用に<user>要素を指定すると、パスワードをクリア・テキストで指定するかわりに、password属性に特殊構文を使用してsystem-jazn-data.xml内の情報を参照できます。パスワードは、system-jazn-data.xmlでは曖昧化された形式で指定されます。次のusernameおよびpassword属性の説明を参照してください。system-jazn-data.xmlファイルの詳細は、Oracle Containers for J2EEセキュリティ・ガイドを参照してください。


注意:

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


属性

JESI構成ファイル

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

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


注意:

下位互換性を維持するために、現在は<jesi-config>および<invalidation>のかわりに廃止予定の要素<ojsp-config>および<web-cache>をそれぞれ使用できます。新規要素は、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タグにusernamepasswordおよび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のsystem-jazn-data.xmlファイルにOracleAS Web Cacheの「invalidator」アカウント用の<user>要素が含まれている場合は、特殊な右矢印構文でダッシュ(-)と右山カッコ(>)に続けてinvalidatorアカウント名を指定して、JESI構成ファイルにそのアカウント名を使用し、system-jazn-data.xmlからパスワードを取得できます。次の「例2: system-jazn-data.xmlからパスワードを取得する構成ファイル」を参照してください。

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

次の例に、URLとログイン情報の設定用に、urlusernameおよび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: system-jazn-data.xmlからパスワードを取得する構成ファイル

次の例では、クリア・テキストを使用してパスワードを指定するかわりに、特殊な->構文を使用してsystem-jazn-data.xmlファイルから曖昧化されていないパスワードを取得します。この例では、system-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タグのサブタグ)のJESI cookieサブタグを1つ以上使用します。この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タグのサブタグ)のJESI headerサブタグを1つ以上使用します。このヘッダー情報は、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プロセッサに指示し、ページのカスタマイズを許可します。

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

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

構文

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


注意:

廃止予定の「value」形式のdefault属性は、下位互換性のために使用できます。valueからdefaultへの変更は、JESIの提案仕様に準拠するために行われました。valueは将来のリリースではサポート外になると思われます。


属性

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

次に、JESI personalizeタグの使用例を示します。

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

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

このCookie値の置換をESIプロセッサで処理することによって、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は、次のとおりであると想定します。

 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の例と同様に、ESIプロセッサはSurrogate-Controlレスポンス・ヘッダーにより警告されます。no-storeディレクティブが生成された理由は、JESI templateタグにcache="no"の設定があるためです。

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


注意:

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