ヘッダーをスキップ

Oracle Application Server Containers for J2EE JSPタグ・ライブラリおよびユーティリティ・リファレンス
10gリリース2(10.1.2)
B15621-02
目次
目次
索引
索引

戻る 次へ

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


重要

JESIタグを使用しているページでは、ESIタグを直接使用しないでください。  


サロゲートについて

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

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

ESIの主要機能

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

Oracle Application Server Web CacheとESIプロセッサ

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

Oracle Application Server 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に送信します。すると、OracleAS Web CacheがWebアプリケーション・サーバーに対する仮想サーバーとして動作します。リクエストされたコンテンツがすでに期限切れの場合、無効になった場合またはアクセスできない場合、OracleAS Web Cacheは、そのWebアプリケーション・サーバーから新しいコンテンツを取得します。

Oracle Application Server 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は、そのコンテンツをクライアントに送信し、そのページのコピーをキャッシュに作成します。


    注意

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


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

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

OracleがJESIを実装するレイヤーは、標準ESIフレームワークの最上部です。Java Community Process(JCP)組織の支援による(OC4J 10.1.2実装時点で)保留中の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 Application Server Containers for J2EE JavaServer Pages開発者ガイド』を参照してください。 


JESIの使用モデル

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

この項では、これら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タグを介してインクルードされるページも、個別のキャッシュ可能オブジェクトです。キャッシュ可能かどうかは、次のように決定されます。

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

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

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


画像の説明

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

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

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


画像の説明


注意

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


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

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

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

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


画像の説明

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


画像の説明

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

最後に、ページの様々なフラグメントがリフレッシュされる時点は、無効化メッセージと期限切れの設定によって異なることに注意してください。通常、適切にチューニングされたアプリケーションでは、ほとんどのフラグメントはESIキャッシュから提供され、再生成が必要になることはまれです。


注意

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レベルで共有できません。

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

JESIフォールバックの実行

JESIタグを使用するページに使用可能なESIプロセッサがない場合(OracleAS Web CacheがインストールされていないシステムやWeb CacheまたはそのESIプロセッサが障害を起こしているシステムなど)は、OC4JのJSPコンテナがそのページを適切にアセンブルします。実質的には、最も重要な機能を引き継いで提供し、ページを適切に実行します。キャッシングは発生せず、JESIタグ属性値のエラー・チェックも実行されません。

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

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 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タグを使用します。

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

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モデル」図6-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タグを使用します。次に、このページのキャッシュ可能オブジェクトを示します。

例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>サブ要素が必要です。


注意

下位互換性を維持するために、現在は<jesi-config>および<invalidation>のかわりに廃止予定の要素<ojsp-config>および<web-cache>をそれぞれ使用できます。新規要素は、JESIの提案仕様に準拠することを目的としています。<ojsp-config>および<web-cache>は、将来のリリースでサポート外になると思われます。 


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

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

無効化対象のユーザー名、パスワードおよびURLの取得には、次の優先順位が使用されます。

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


    注意

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


  2. invalidateタグにusernamepasswordおよびurlを指定せずにconfig属性に構成ファイルを指定すると、指定した構成ファイルからの値が使用されます。

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


    注意

    次の場合には、invalidateタグにユーザー名、パスワードおよびURLを指定しないと、例外が発生します。

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

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

OC4Jのjazn-data.xmlファイルにOracleAS Web Cacheの「invalidator」アカウント用の<user>要素が含まれている場合は、特殊な右矢印構文でダッシュ(-)と右山カッコ(>)に続けてinvalidatorアカウント名を指定して、JESI構成ファイルにそのアカウント名を使用し、jazn-data.xmlファイルからパスワードを取得できます。次の「例2: 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: 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タグのサブタグ)の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は将来のリリースではサポート外になると思われます。

  • OC4Jでは、ESI仕様に準拠するために、指定されたdefault(またはvalue)設定は一重引用符で自動的に囲まれます。OC4J 9.0.4より前の実装では、設定の一部として一重引用符を含める必要がありました。

属性

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

次に、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は、次の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プロセッサによって使用され、クライアントへの最終レスポンスには表示されません。 



戻る 次へ
Oracle
Copyright © 2005 Oracle Corporation.

All Rights Reserved.
目次
目次
索引
索引