Oracle Application Server Containers for J2EE JSPタグ・ライブラリおよびユーティリティ・リファレンス 10g(9.0.4) |
|
このトピックでは、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仕様の最終バージョンに完全に準拠することは保証できません。 |
JESIタグは、JSPページの動的コンテンツをキャッシュ可能なコンポーネントに分割します。その基礎となるのがEdge Side Includesアーキテクチャとマークアップ言語です。
JESIタグの使用は、特定のESIプロセッサやキャッシング・システムに依存しているわけではありませんが、Oracleユーザーの典型的な使用例では、OracleAS Web CacheとそのESIプロセッサを使用しています。
次の項では、Oracle JESIタグの基礎となっている基本テクノロジの一部に関するバックグラウンド情報について説明します。
この項で説明するのは、ESIアーキテクチャと言語の簡単な概要のみです。ESIテクノロジに関する追加情報は、次のWeb サイトを参照してください。
http://www.esi.org
この項では、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タグに指定されている取得およびアセンブリの指示が含まれます。
サロゲートは、ページ・コンテンツを所有するWebサーバーのかわりに動作するため、コンテンツ所有者は、サロゲートの動作を完全に制御できます。これにより、サロゲートを使用しない場合に比較して、大幅なパフォーマンスの向上が可能になります。
サロゲートでのキャッシング処理は、HTTPでのキャッシング処理に類似しています。どちらも、類似した斬新な妥当性チェック機能を基盤として使用しています。ただし、サロゲートには、その上に制御機能も備わっています。
ESI言語のバージョン1.0には、次の主要な機能が含まれています。
ESIプロセッサは、ネットワークから取得された動的コンテンツのフラグメントを、集計ページにアセンブルして、ユーザーに出力します。各フラグメントには、独自のメタデータがあり、そのフラグメントのキャッシング動作を制御できます。 次の図 1を参照してください。
ESIは、HTTPのリクエスト属性に基づく変数の使用をサポートしています。ESI文では、処理時に変数を使用することも、その変数を処理済のマークアップに直接出力することもできます。
ESIでは、ページの処理方法の判断に、条件付きロジックのブール比較を使用できます。
一部のESIタグは、デフォルト・リソースまたは代替リソース(あるいはその両方)の指定をサポートしています。代替リソースには、プライマリ・リソースが検出できなかった場合の代替Webページなどがあります。
この項では、OracleAS Web CacheとそのESIプロセッサを紹介します。 詳細は、『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に送信します。その結果、このWeb Cacheは、アプリケーションWebサーバーに対する仮想サーバーとして動作します。リクエストされたコンテンツがすでに期限切れの場合、無効になっている場合、またはアクセスできない場合、OracleAS Web Cacheは、そのアプリケーションWebサーバーから新規コンテンツを取得します。
次に、ブラウザとOracleAS Web Cacheとの典型的な相互作用のステップを示します。
OracleAS Web Cacheには、キャッシングでEdge Side Includesマークアップ言語の使用をサポートするESIプロセッサが組み込まれています。 (詳細は、「Edge Side Includesテクノロジ」を参照してください。)
OracleAS Web Cache環境のWeb開発者は、自分のアプリケーションでESI言語を直接使用できます。ただし、JSP開発者の場合は、いくつかの理由から、ESI言語に対する便利なJSPインタフェースとして提供されているJESIタグ・ライブラリを使用します。 「JESIタグのメリット」を参照してください。
次の項では、JESI機能とOracleによる実装について説明します。
次のWebサイトからJESIの提案仕様にアクセスできます。
http://www.esi.org
OC4Jには、Webキャッシュ用のESIタグおよびEdge Side Includes機能に対する便利なインタフェースとして、JESIタグ・ライブラリが用意されています。開発者は、WebアプリケーションでESIタグを直接使用することもできますが、JESIタグを使用することでJSPページはさらに便利になります。次に、ESIタグを直接使用せずに、JESIタグを使用する主なメリットについて説明します。
JESIタグは、メタデータ情報(キャッシュ内のページの期限切れなど)の指定、必要に応じたページの明示的な失効化、およびCookie情報を使用したページのパーソナライズなどに使用する便利な構文とタグ属性をサポートしています。
JESIタグ・ライブラリでは、アプリケーション・レベルの構成ファイルを使用して、特定の環境に適したデプロイ時パラメータとアプリケーションのデフォルト設定を簡単に指定できます。このようにして、多様なニーズを持つ様々な環境にデプロイし、アプリケーション・コードを変更せずに、適切なデフォルトを設定できます。たとえば、このような構成ファイルを使用して、失効化リクエストに対して、キャッシュ・サーバーのURL、ユーザー名およびパスワードを事前に設定できます。
OracleがJESIを実装するレイヤーは、標準ESIフレームワークの最上部です。これは(OC4J 9.0.4の実装時点で)保留中のJESI標準であるJSR-128にも準拠しています。この標準は、Java Community Process(JCP)組織が後援しています。JCP組織とJSR-128のステータスの詳細は、次の場所を参照してください。
http://www.jcp.org
JESIタグ・ライブラリは、標準実装であるため、次の点に注意してください。
Oracle JESIタグ・ライブラリは、次のタグをサポートします。
control
、JESI include
、JESI param
、JESI template
、JESI fragment
およびJESI codeblock
invalidate
(およびサブタグ)
personalize
JSP開発者は、対応するESIタグ(esi:include
など)ではなく、これらのタグ(JESI include
など)を使用します。 このタグの有用性と利便性については、「JESIタグのメリット」で説明しています。
注意:
Oracle JESIタグ・ライブラリは、JSPカスタム・タグ・ライブラリの一般標準に従って実装されています。 標準JavaServer Pagesタグ・ライブラリのフレームワークの詳細は、『Oracle Application Server Containers for J2EE JavaServer Pages開発者ガイド』を参照してください。 |
集計ページとそのキャッシュ可能コンポーネントの定義にJESIタグを使用する方法には、次の2つのモデルがあります。
この項では、これら2つのモデルについて説明し、最後にJESI include
タグに関する特記事項を説明します。
JESIタグの使用方法に対するcontrol/includeアプローチは、モジュール化された方法です。この方法では、ほとんど(またはすべて)のキャッシュ可能コンテンツをインクルード・ページとして集計ページに表示します。この方法は、新規ページを開発する場合に特に便利です。このモデルは、次のように使用します。
control
タグをトップレベルのページで使用し、必要に応じて、インクルード・コンテンツ以外のコンテンツにキャッシング・パラメータを設定します。
include
タグを使用して、動的コンテンツをインクルードします。
control
タグを各インクルード・ページ内で使用し、必要に応じて、これらのページにキャッシング・パラメータを設定します。
各インクルード・ファイルは、個別のキャッシュ可能オブジェクトです(ただし、タグ設定によってキャッシングを無効化できます)。また、トップレベル・ページのコンテンツもすべて個別オブジェクトです。
状況によっては、両タグともオプションになります。 JESI include
タグを使用せずに、ページにJESI control
タグを指定できます。実際に、これが既存のページをJESI用に変換する簡単な方法です。 また、JESI include
タグを使用しているページに、必ずしもJESI control
タグを指定する必要はありません。 ESIプロセッサでは、JESI include
タグがあることを無差別に適宜通知します。 インクルード・ページにJESI control
タグは必要ありません。
トップレベル・ページまたはインクルード・ページがキャッシュ可能かどうかは、次のように判断されます。
control
タグがある場合、キャッシュ可能かどうかは、属性設定またはデフォルト属性値によって適宜決まります。
control
タグがない場合、キャッシュ可能かどうかは、ESIプロセッサの設定によって決まります。
control
タグは、インクルード・ページには影響を与えません。
タグ構文と例は、次の各項を参照してください。
template/fragmentアプローチでは、コンテンツが単一ページに含まれ、必要に応じてページを独立したキャッシュ可能なフラグメントに分割します。このモデルは、JESIで使用するために既存のページを変換し、特定の部分を独立したキャッシュ可能なコンポーネントに分割する場合に特に便利です。このモデルは、次のように使用します。
template
タグを使用して、すべての可視コンテンツの集計を囲みます。このタグはフラグメント以外のコンテンツにキャッシング・パラメータを設定します。 template
タグの外側では可視コンテンツを使用しないでください。
template
開始タグと終了タグの間にJESI fragment
タグを使用します。
include
タグも、テンプレート・レベルまたはフラグメント・レベルのいずれかで必要に応じて使用できます。
codeblock
タグを使用して、コードのブロックの条件付き実行を指定できます。
JESI template
タグとJESI fragment
タグは、必ず同時に使用します。 ページに個別のフラグメントが不要な場合は、JESI template
タグではなく、JESI control
タグを使用します。
各フラグメントは個別のキャッシュ可能オブジェクトです。フラグメント以外のテンプレート・レベルにあるコンテンツは、個別のキャッシュ可能オブジェクトです。 JESI include
タグでインクルードされるページも個別のキャッシュ可能オブジェクトです。キャッシュ可能かどうかは、次のように判断されます。
template
タグ属性の設定またはデフォルト属性値によって適宜決まります。
fragment
タグの属性設定またはデフォルト属性値によって適宜決まります。
テンプレートとフラグメントは、独立したキャッシュ可能オブジェクトであるため、ESIプロセッサで期限切れになる時点が異なる場合があります。キャッシュ・ミスの発生時、または期限切れオブジェクトがリクエストされたとき、ESIプロセッサは、Webサーバー(OracleASの場合はOC4J)に新しいコピーをリクエストします。
リクエストされたオブジェクトがJESIテンプレートの場合、JSPコンテナは、そのページ内のフラグメント以外のコードを実行します。JSPトランスレータは、生成した出力に、すべてのフラグメントをインクルードする場所を指定するESIマークアップも配置します。この時点では、JESIフラグメントに格納されているコードは実行されません。 次の図 2にこれを示します。
フラグメントが期限切れになると、ESIプロセッサはWebサーバーに対して、その特定のフラグメントをリクエストします。フラグメントを実行するために、OC4J JSPコンテナは、テンプレート・コード(フラグメント以外のコード)に加えて、リクエスト対象のフラグメントのコードを実行します。テンプレート・コードを実行すると、フラグメントは変数の宣言や初期化などの特定の副次的効果に依存できます。
フラグメント・コードの出力は、レスポンスで返されます。テンプレート・コードの出力は廃棄されます。レスポンスを受信すると、ESIプロセッサは、フラグメントの更新済コピーをキャッシュします。 次の図 3にこれを示します。
注意: コストの高いテンプレート・コードの実行を不必要に繰り返すことを回避するために、JESI |
テンプレートとフラグメントに対してコード配置と期限切れのポリシーを選択するときは、この動作に注意してください。特に、テンプレート・コードはすべての更新リクエストで実行されるため、コストの高いコードを配置する場所には注意してください。 毎回実行する必要がない、またはcodeblock
タグ内に適切に配置されていない場合は、コストのかかる計算をテンプレート・レベルに配置しないでください。または、コストのかかる計算は、できるだけ期限切れまでの期間が長いフラグメントに配置してください。
図 4に、フラグメントがリクエストされたときのみコード・ブロックを実行する1つのcodeblock
タグの使用例を示します。この図では、リクエストはテンプレートに対するものであるため、コード・ブロックは実行されません。
図 5に、フラグメントがリクエストされたときのみコード・ブロックを実行する別のcodeblock
タグの使用例を示します。ただし今回は、リクエストがフラグメントに対するものであるため、コード・ブロックが実行されます。
さらに、同一リクエスト時に、2つのフラグメントは実行されないことにも注意してください。たとえば、スクリプトレット変数の値を1つのフラグメントで宣言または設定して、別のフラグメントでその変数に依存したり値を設定したりすることは避けてください。 1つの変数が2つ以上のフラグメントで必要な場合は、テンプレート・コード(codeblock
タグの内部など)で宣言および設定してください。同様に、1つのフラグメント内にリクエスト属性またはセッション属性を設定し、それを別のフラグメントで読み込むことは避けてください。 このような、グローバルなページ・ロジックは、テンプレート・レベルに配置してください。
最後に、あるページ内の異なるフラグメントは、失効化メッセージと期限切れ設定に応じて異なるタイミングでリフレッシュされることに注意してください。通常、適切にチューニングされたアプリケーションでは、ほとんどのフラグメントはESIキャッシュから提供されるため、頻繁に再生成する必要はありません。
タグ構文と例は、次の各項を参照してください。
control/includeモデルとtemplate/fragmentモデルのどちらを使用する場合も、JESI include
文については、次の点に注意してください。
include
文を含むページをインクルードしたJESI include
文、またはJESI fragment
文で定義されたフラグメント内のJESI include
文として、サポートされています。
2番目のケースでは、たとえばESIプロセッサが次の手順を実行します。
include
タグと標準のjsp:include
タグは概念的には似ていますが、キャッシング用にJSPページを変換するときに、JESI includeタグをjsp:include
タグのかわりに使用できない場合があります。 ESIプロセッサでは、別々のHTTPリクエストを使用するため、HTTPのリクエストまたはレスポンス・オブジェクトをあるページとJESI include
タグでインクルードされたページとの間で渡すことができません。 インクルード・ページのコードがインクルード元ページのリクエストまたはレスポンス・オブジェクトにアクセスする必要がある場合、開発者は、JESI template/fragmentモデルを使用して、JESI include
タグではなく、JESI fragment
タグ(集計ページのJESI template
タグ内)にコードを配置することを検討する必要があります。
データベース内の関連データへの変更など、外部の状況によっては、キャッシュ内のオブジェクトを明示的に失効化する必要があります。また、あるページの実行によって、別のページに対応しているキャッシュ内のオブジェクトのデータが失効になる場合もあります。
このため、JESIには、JESI invalidate
タグおよび関連するサブタグが用意されています。これらのタグを使用すると、次の適切な組合せに基づいてページを失効化できます。
失効化メッセージはXMLベースのフォーマットで、失効化する対象のURLを指定します。 このメッセージは、JESI invalidate
タグの実行時にJSPコンテナで起動され、POST
メソッドによってHTTPを介してキャッシュ・サーバーにフォワードされます。次に、キャッシュ・サーバーが応答し、失効化レスポンスがHTTPを介して返信されます。
タグ構文と例は、「キャッシュ内のオブジェクトの失効化に使用するタグとサブタグの説明」を参照してください。
動的Webページには、個別のユーザーにあわせてカスタマイズされた情報が頻繁に表示されます。たとえば、「ようこそ」のページには、ユーザー名や特別な挨拶文、あるいはユーザーが所有している株式の現在の相場などが表示されます。
このようなカスタマイズされた出力の場合、Webページは、JESI personalize
タグによって提供されるCookie情報に依存します。このタグは、Cookieの置換を実行する必要のある状況をESIプロセッサに通知します。このタグがない場合は、Webページを複数のユーザーがESIレベルで共有できません。
タグ構文と例は、「ページのパーソナライズに使用するタグの説明」を参照してください。
JESIタグを使用するページに対してESIプロセッサが使用可能でない場合(OracleAS Web Cacheがないシステムや、Web CacheまたはESIプロセッサがダウンしているシステムなど)、OC4J JSPコンテナは、ページを適切にアセンブルするためにステップ実行します。基本的にこのコンテナは、ページを正しく実行するために最も重要な機能を引き継ぎ、提供します。キャッシングは行われず、JESIタグ属性値のエラーチェックも行われません。
このような状況では、JSPコンテナは特定のJESIタグを次のように処理します。
control
タグを無視します。
include
タグを、jsp:include
タグであるとして実行し、関連付けられているJESI param
タグを、jsp:param
タグであるとして実行します。 JESI include
タグ内にネストされたスクリプトレット・コードも実行されることに注意してください。
template
タグおよびfragment
タグでネストが適切かどうかをチェックしますが、それ以外のタグでは無視し、1回のリクエストですべてのタグ・ボディを実行します。
codeblock
タグ内のすべてのコードを無条件に実行します。
invalidation
タグとすべてのサブタグを無視します。
personalize
タグに対しては、Cookieが以前に存在していた場合はCookie値をレスポンス・ボディに挿入します。 Cookieが以前に存在せず、デフォルト値がpersonalize
タグで指定されている場合、JSPコンテナは、デフォルト値をレスポンス・ボディに挿入します。 Cookieが以前に存在せず、デフォルト値が指定されていない場合、personalize
タグを使用しても効果はありません。
次の項では、OC4Jが提供するJESIタグの構文と属性を説明し、使用例を示します。
JESIタグ・ライブラリについては、次の要件に注意してください。
ojsputil.jar
ファイルに含まれています。このファイルは、予約済のタグ・ライブラリ・ディレクトリに置かれています。このファイルがインストール済で、クラスパスに存在していることを確認してください。
jesitaglib.tld
が、アプリケーションで使用可能になっている必要があります。また、ライブラリを使用するJSPページには、適切なtaglib
ディレクティブが存在する必要があります。 OracleASのインストールでは、TLDはojsputil.jar
ファイルにあります。 jesitaglib.tld
のuri
値は次のとおりです。
http://xmlns.oracle.com/j2ee/jsp/tld/ojsp/jesitaglib.tld
taglib
ディレクティブ、予約済のタグ・ライブラリ・ディレクトリ、TLDファイルおよびuri
値の意味の詳細は、『Oracle Application Server Containers for J2EE JavaServer Pages開発者ガイド』を参照してください。
注意:
|
次の項では、動的キャッシングでのJESIタグの使用方法およびその構文と属性を説明し、例を示します。
control/includeモデルおよびtemplate/fragmentモデルの概要は、「JESIの使用モデル」を参照してください。
JESI control
タグは、control/include使用モデルでJSPページのキャッシュ動作を制御します。 JESI control
タグは、トップレベルのページまたは任意のインクルード・ページで使用できます。ただし、必須ではありません。 control/includeモデルでJESI control
タグがないページがキャッシュ可能かどうかは、ESIプロセッサの設定によって決まります。 (詳細は、「JESIの使用モデル」を参照してください。)
JESI control
タグの結果のアクションによって、HTTPレスポンス・ヘッダーが設定されるため、このタグは、ページ内の他のすべてのJESIタグまたはバッファ・フラッシュの前の、できるだけ先頭に近い位置に配置してください。
次の点に注意してください。
control
タグのすべての属性はオプションです。設定なしでタグを使用した場合、デフォルトでは、レスポンスがキャッシュ可能かどうかには24時間の期限切れ設定があり、期限切れのオブジェクトは即時に削除されます。
control
タグを使用しないでください。
include
タグがあるページ)のJESI control
タグは、インクルード・ページには影響を与えません。 必要に応じて、各インクルード・ページでJESI control
タグを使用してください。
control
タグが検出された場合は、最初のタグのみ処理されます。残りのタグは無視されます。 JESI include
タグでインクルードされるページ(このようなページには固有のJESI control
タグがある場合があります)では、別々のレスポンスが生成されることに注意してください。
control
タグが検出された場合、そのJSPコンテナですでにJESI template
タグが検出されていると、control
タグが無視されます。
control
タグを含むページがリクエスト・パラメータに依存している場合は、リクエスト問合せ文字列に応じて、ページの別のバージョンをキャッシュする必要があるかどうかを検討してください。 異なるリクエスト・パラメータ値が多すぎるため、キャッシュ内のページのバージョンが多くなりすぎることが予想される場合は、そのページをまったくキャッシュしないことも選択できます(cache="no"
を設定します)。
<jesi:control [ expiration = "value" ] [ maxRemovalDelay = "value" ] [ cache = "yes" | "no" | "no-remote" ] [ control = "uninterpreted_string" ] />
maxRemovalDelay
: キャッシュ内の期限が切れたオブジェクトを、ESIプロセッサで引き続き格納できる最大時間(秒単位)を指定します。デフォルトは0(ゼロ)で、即時に削除されます。
cache
: タグに対応するレスポンスがキャッシュ可能かどうかを指定します。 「yes
」設定(デフォルト)では、キャッシングが有効になります。 キャッシングを無効化するには、cache
を「no
」に設定します。また、リモートESIプロセッサやコンテンツ配信ネットワーク上ではなく、最も近いキャッシュ内のキャッシングのみを有効にするには、「no-remote
」に設定します。
ページをキャッシュ不可にするのは、たとえば、copyParam="yes"
を指定したJESI include
タグを使用している場合です。 次の「JESI includeタグ」を参照してください。
control
: この属性の値は、JESI control
タグの処理中に作成されたSurrogate-Control
レスポンス・ヘッダーを変更せずに追加されます。OracleAS Web Cache ESIプロセッサはこの属性を使用しませんが、アプリケーションに別のESIプロセッサを使用していて、独自の追加情報をヘッダーに渡す必要がある場合に役立ちます。
注意:
|
JESI include
タグでは、標準のjsp:include
タグと同様に、インクルード・ページの出力をインクルード元のページの出力に動的に挿入できます。このタグは、ESIプロセッサにインクルード・ページの処理とアセンブルを指示することによってこの処理を行います。各インクルード・ページは、独立したキャッシュ可能オブジェクト(設定によっては、キャッシュ不可オブジェクト)です。
このタグは、次の使用例にあるcontrol/includeモデルまたはtemplate/fragmentモデルのいずれでも使用できます。
control
タグなしで、またはJESI template
タグとfragment
タグなしで独立して使用
control
タグの後に使用
fragment
タグ内、またはJESI template
タグ内ではあるがフラグメントの外で使用
(詳細は、「JESIの使用モデル」を参照してください。)
また、JESI include
タグでインクルードされるページ内のJESI include
タグ、または標準のjsp:include
タグでインクルードされるページ内のJESI include
タグを使用して、JESI includeをネストできます。
インクルード・ページがキャッシュ可能かどうかは、次のように判断されます。
control
タグがある場合、キャッシュ可能かどうかは、属性設定またはデフォルト属性値によって適宜決まります。
control
タグがない場合、キャッシュ可能かどうかは、ESIプロセッサの設定によって決まります。
<jesi:include page = "uri" [ alt = "alternate_uri" ] [ ignoreError = "true" | "false" ] [ flush = "true" | "false" ] [ copyParam = "true" | "false" ] > ...optional jesi:param tags, related scriptlets... </jesi:include>
注意:
|
page
(必須): ページ相対位置またはアプリケーション相対位置のいずれかを使用して、インクルード対象のJSPページのURIを指定します。 (ページ相対位置とアプリケーション相対位置の構文については、『Oracle Application Server Containers for J2EE JavaServer Pages開発者ガイド』を参照してください。) 完全な「http://...
」または「https://...
」のURLもサポートされています。
URIでは、必要に応じて、インクルード・ページに渡す追加の問合せパラメータと値を指定できますが、この目的にはJESI param
サブタグを使用することをお薦めします。 「JESI paramタグ」を参照してください。
alt
: page
属性に指定されたページが見つからない場合に、インクルード対象となる代替ページのURIを指定します。 構文は、page
属性の構文と同じです。
ignoreError
: 「true
」に設定すると、インクルード・ページにアクセスできない場合でも(page
ページでもalt
ページでもない場合)、インクルード元ページの処理を続行できます。 デフォルトは「false
」です。
flush
: この属性は無視されます。ただし、jsp:include
構文からの移行を容易にするためにサポートされています。
copyParam
: インクルード・ページがリクエスト・パラメータを使用する場合、インクルード元ページのHTTPリクエスト文字列からインクルード・ページにパラメータとその値をコピーするには、この属性を「true
」に設定します。 デフォルト値は「false
」です。
リクエスト・パラメータがインクルード・ページに必要で、copyParam="true"
の場合は、パラメータ設定に従って、インクルード元ページをキャッシュしない(JESI control
、JESI template
またはJESI fragment
のタグにcache="no"
を設定)か、インクルード元ページの複数バージョンをキャッシュするかのいずれかを実行する必要があります。
たとえば、次のような使用例は避けてください。
<jesi:control cache="yes"/> ... <jesi:include page="arf.jsp" copyParam="true" />
その理由は、このインクルード元ページのコピーがキャッシュから提供される場合、またこの後続のリクエストのパラメータが元のリクエストのパラメータと異なる場合に、そのページがサーバー上で実行されないか、または新しいパラメータがarf.jsp
に適切にコピーされない可能性があるためです。 この結果、クライアントには不適切なパラメータから生成されたarf.jsp
が提供されることになります。
ただし、この使用例は、次のような特定の状況では、問題となりません。
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 page = "uri" ... > <jesi:param name="param_name" value="param_value" /> ... </jesi:include>
この項では、control/includeモデルでのJESIタグの使用例を示します。
次の例では、デフォルトのキャッシュ設定を使用します。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>
この例では、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" />
この例は、条件付きの出力を含む集計ページの例です。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]%>" /> <% } } %>
次に、リクエスト・パラメータを含む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
タグがないかぎり、キャッシュ可能です。
この例は、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>
template/fragmentの使用モデルで、テンプレートのコンテンツ(フラグメント以外)のキャッシング動作を指定するには、JESI template
タグを使用します。 (詳細は、「JESIの使用モデル」を参照してください。)対応するHTTPヘッダーは、ESI仕様に基づいて設定されます。 フラグメント以外のコンテンツは、ここではテンプレート・コンテンツと呼び、JESI fragment
タグで除外される各フラグメントのコンテンツは、別のキャッシュ可能オブジェクトです。
JESI template
タグは、必ずJESI fragment
タグとともに使用します。 個別のフラグメントが不要な場合は、JESI template
タグではなく、JESI control
タグを使用します。
次の点に注意してください。
template
タグのすべての属性はオプションです。設定なしでタグを使用した場合、デフォルトでは、レスポンスがキャッシュ可能かどうかには24時間の期限切れ設定があり、期限切れのオブジェクトは即時に削除されます。
template
タグが必要であり、テンプレート・コンテンツがキャッシュが可能かどうかは、template
タグの属性設定またはデフォルト値によって適宜決まります。 同様に、各フラグメントはJESI fragment
タグで除外される必要があり、各フラグメントがキャッシュ可能かどうかは、fragment
タグの属性設定またはデフォルト値によって決まります。
template
タグを使用しないでください。 また、追加のJESI template
タグを、jsp:include
機能によって同じレスポンス・オブジェクトにインクルードされているぺージに使用しないでください。いずれの場合も、例外が発生します。
template
タグがなく、この項で説明したその他の関連制限事項に従っているかぎり、OC4J 9.0.4の実装からは、標準のjsp:include
タグでインクルードされるページ内にJESI template
タグを配置できます。
template
タグが検出された場合、そのJSPコンテナですでにJESI control
タグが検出されていると、template
タグの属性が無視され、キャッシングはcontrol
タグに従います。
template
タグがキャッシュ可能かどうかの設定は、各フラグメントには影響を与えません。フラグメントには独自の設定(またはデフォルト値)があります。
template
タグにcache="no"
を設定)か、テンプレート・コンテンツの別のバージョンをキャッシュするかのいずれかを、パラメータ値に従って実行する必要があります。異なるバージョンのフラグメントも、パラメータ値に従ってキャッシュされます。
フラグメントのバックグラウンドでは、JESI include
タグによってインクルードされたページと同様に、追加リクエストが関係しています。 リクエスト・パラメータ(設定されている場合)は、常にテンプレートからフラグメントに渡されます。これは、copyParam="true"
が設定されたJESI include
タグの機能と同じです。 (この種の問題については、「JESI includeタグ」でも説明しています。)
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タグ」を参照してください。
template/fragmentモデルでは、1つ以上のJESI fragment
タグを、JESI template
タグ内、つまりJESI template
の開始タグと終了タグ間で使用します。 (詳細は、「JESIの使用モデル」を参照してください。) 各JESI fragment
タグは、必要に応じて、JSPページの個別のフラグメントのキャッシング動作を定義します。各フラグメントは独立したキャッシュ可能オブジェクトです。
特定のフラグメントがESIメカニズムによって集計レスポンスへのインクルードをリクエストされると、ESIプロセッサは、そのフラグメントのみを取得します。
JESI fragment
タグには、JESI control
タグおよびJESI template
タグの場合と同じ使用方法で同じ属性を指定します。
次の点に注意してください。
fragment
タグごとに、独自のキャッシング指示をESIプロセッサに指定します。キャッシュ可能かどうかは、指定された属性設定またはデフォルト値によって適宜決まります。 JESI template
タグの設定は、フラグメントには影響を与えません。
fragment
タグは、別のJESI fragment
タグ内にネストできません。
template
タグ、および該当する場合はfragment
タグが必要になります。 キャッシュ可能かどうかは、常にtemplate
タグまたはfragment
タグの属性設定またはデフォルト値によって決まります。
jsp:include
タグでインクルードされるページ内にJESI fragment
タグを配置できます。 JESI fragment
タグを囲むJESI template
タグは、同じインクルード・ページ、またはjsp:include
文を含むページのような上位レベル・ページに存在できます。
<jesi:fragment [ expiration = "value" ] [ maxRemovalDelay = "value" ] [ cache = "yes" | "no" | "no-remote" ] [ control = "uninterpreted_string" ] > ...JSP code fragment... </jesi:fragment>
属性の説明は、「JESI controlタグ」を参照してください。
template/fragmentモデルでは、必要に応じてフラグメント以外のテンプレート・コード内で1つ以上のJESI codeblock
タグを使用して、特定のコードのブロックの条件付き実行を指定できます。 各codeblock
タグは、コード・ブロックを囲み、そのブロックをいつ実行する必要があるかを指定します。
または
または
このタグを使用しないと、すべてのテンプレート・コードがすべてのリクエスト(テンプレートの各リクエストとフラグメントの各リクエスト)で実行されますが、フラグメントのリクエストの場合、テンプレート出力は廃棄されます。
フラグメントがリクエストされるたびにテンプレートを実行して、フラグメントが変数の宣言や初期化などのテンプレート・コードの副次的効果に依存できるようにすることが重要ですが、フラグメントに必要でないコード・ブロックがある場合があります。 テンプレートがリクエストされた場合にのみブロックを実行するように指定して、このようなコード・ブロックをcodeblock
タグに配置できます。
または、すべてのフラグメントに必要な可能性があり、テンプレート自体には必要でないテンプレート・コードのブロックがある場合があります。 フラグメントがリクエストされた場合にのみブロックを実行するように指定して、このようなコード・ブロックをcodeblock
タグに配置できます。
注意: JESI |
<jesi:template ... > ... <jesi:codeblock execute = "template" | "fragment" | "always" > ...request-dependent JSP content... </jesi:codeblock> ... </jesi:template>
execute
(必須): テンプレートがリクエストされた場合にのみコード・ブロックを実行するには、値「template
」を指定します。 フラグメントがリクエストされた場合にのみコード・ブロックを実行するには、値「fragment
」を指定します。 「always
」を設定すると、ページのすべてのリクエストでコード・ブロックが実行され、codeblock
タグをまったく使用しない場合と同等になります。
この項では、template/fragmentモデルでのJESIタグの使用例を示します。
この例は、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>
この例では、フラグメント内で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>
これは、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 object
サブタグとともに使用すると、1つ以上のキャッシュ内のオブジェクトを明示的に失効させることができます。
サブタグは、次のように使用します。
object
サブタグを使用します。
object
タグのJESI cookie
サブタグまたはJESI header
サブタグ(またはその両方)を使用し、CookieまたはHTTPヘッダー情報に基づいて、失効化対象の追加基準を指定します。
<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セキュリティ・ガイド』を参照してください。
url
: キャッシュ・サーバーのURLを指定します。この属性を省略する場合は、URL、およびユーザー名とパスワードをJESI構成ファイルに指定する必要があります。
username
: キャッシュ・サーバーにログインして失効させるユーザー名を指定します。 OracleAS Web Cacheは、通常はinvalidatorというユーザー名を必要とします。この属性を省略する場合は、ユーザー名、およびパスワードとURLをJESI構成ファイルに指定する必要があります。
OC4J jazn-data.xml
ファイルにOracleAS Web Cacheのinvalidatorアカウントの<user>
要素が含まれている場合は、username
値に次のようなアカウント名を使用できます。
username="invalidator"
password
: キャッシュ・サーバーにログインして失効化を実行するためのパスワードを指定します。この属性を省略する場合は、パスワード、およびユーザー名とURLをJESI構成ファイルに指定する必要があります。
OC4J jazn-data.xml
ファイルにOracleAS Web Cacheのinvalidatorアカウントの<user>
要素が含まれている場合は、ダッシュ(-
)と右山カッコ(>
)の後に失効するアカウント名を付けた、次のような特殊な右矢印構文を使用して、曖昧化されていないパスワードをそのファイルから取得できます。
password="->invalidator"
config
: アプリケーション相対位置またはページ相対位置を使用して、JESI構成ファイルを指定します。この構成ファイルを使用すると、対応するタグ属性を使用せずに、キャッシュ・サーバーのURL、失効化のユーザー名およびパスワードを指定できます。次の点に注意してください。
config
属性で構成ファイルを指定するかわりに、デフォルトの場所にある構成ファイルを指定できます。 「JESI構成ファイル」を参照してください。
username
、password
およびurl
がすべてタグ属性で指定されている場合、構成ファイルは確認されません。
output
: 必要に応じて、キャッシュ・サーバーから失効化レスポンスを受信する出力デバイスを設定します。 現在サポートされている設定は、ユーザーのWebブラウザにメッセージを表示するためのHTML形式でWebキャッシュ・レスポンスをラップするbrowser
のみです。このパラメータを設定しないと、失効化レスポンスはまったく表示されません。
提案されているJESI仕様では、構成ファイルの使用がサポートされます。現在は、失効化のユーザー名、パスワードおよびURLを指定するには構成ファイルのみを使用できます。 (または、各JESI invalidate
タグの属性でユーザー名、パスワードおよびURLを指定できます。 「JESI invalidateタグ」を参照してください。
JESI構成ファイルには、<jesi-config>
トップレベル要素、その下の<invalidation>
サブ要素および<invalidation>
要素の下の<username>
、<password>
、<url>
のサブ要素が必要です。
注意: 下位互換性を保つために、推奨されない要素 |
現在の実装では、2つの可能なデフォルト・ファイルがあります。または、アプリケーション内の任意の場所にファイルを配置し、その名前と場所をinvalidate
タグのconfig
属性にアプリケーション相対位置またはページ相対位置で指定できます。
OC4J 9.0.4実装では、優先されるデフォルト・ファイルは、提案されているJESI仕様に準拠している/WEB-INF/jesi.xml
です。 下位互換性を保つために、以前のデフォルト・ファイルである/WEB-INF/config.xml
もサポートされています。
次の手順は、失効化のユーザー名、パスワードおよびURLを取得するために使用されます。
invalidate
タグにusername
、password
およびurl
を指定せず、config
属性で構成ファイルを指定している場合は、指定された構成ファイルの値が使用されます。
invalidate
タグでusername
、password
、url
およびconfig
が指定されていない場合、JSPコンテナはデフォルトの構成ファイルの使用を試みます。 最初に、コンテナは/WEB-INF/jesi.xml
を検索し、見つかった場合はそのファイルの設定を使用します。 そのファイルが見つからない場合、コンテナは/WEB-INF/config.xml
を検索し、見つかった場合はそのファイルの設定を使用します。
OC4J jazn-data.xml
ファイルにOracleAS Web Cacheのinvalidatorアカウントの<user>
要素が含まれている場合は、JESI構成ファイルでそのアカウント名を使用し、ダッシュ(-
)と右山カッコ(>
)の後に失効化アカウント名を付けた特殊な右矢印構文を使用して、パスワードをjazn-data.xml
から取得できます。 後述の「例2: jazn-data.xmlからパスワードを取得する構成ファイル」を参照してください。
次の例では、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>
次の例では、クリア・テキストを使用してパスワードを指定するかわりに、特殊な->
構文を使用して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>
完全な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"] />
uri
(必須): 失効させるキャッシュ内のオブジェクトに対応するページの完全なURI(prefix="no"
の場合)、または場所に応じて複数ページのオブジェクトの失効化を指定するURI接頭辞(prefix="yes"
の場合)のいずれかを指定します。
接頭辞を指定すると、そのディレクトリに属しているページのキャッシュ内のオブジェクトがすべて失効化されます。 たとえば「/abc/def
」という接頭辞を設定した場合は、対応するディレクトリとサブディレクトリにあるすべてのページについて、キャッシュ内のオブジェクトが失効します。
prefix
: uri
属性をURI接頭辞としてのみ解析する場合は、「yes
」に設定します。 uri
値を完全なURIとして解析する場合は、デフォルト設定の「no
」を使用します。
maxRemovalDelay
: キャッシュ内のオブジェクトが失効してからそれが削除される(したがってESIプロセッサによって提供できなくなる)までの最大遅延を秒単位で指定します。この遅延のデフォルトは0(ゼロ)で、即時に削除されます。
失効化の追加基準として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" ] />
使用する各cookie
サブタグについて、失効させるオブジェクトのリクエストURLには、name
属性設定およびvalue
属性設定(指定されている場合)と一致するCookieが必要です。
失効化の追加基準として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" />
使用する各header
サブタグについて、失効させるオブジェクトのリクエストURLに、name
属性設定およびvalue
属性設定と一致するヘッダーが必要です。
この項では、JESI invalidate
タグ、そのサブタグJESI object
およびJESI object
タグのJESI cookie
サブタグを使用したページの失効化の例を示します。
この例では、完全な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> ...
この例は、直前の「例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>
この例では、URI接頭辞「/
」に従って、ESIプロセッサ内の全オブジェクトを失効させます。この例では、ブラウザでの失効化レスポンスの表示は指定していません。したがって、このレスポンスはまったく表示されません。
... <jesi:invalidate url="http://yourhost.yourcompany.com:4001" username="invalidator" password="invpwd"> <jesi:object uri="/" prefix="yes"/> </jesi:invalidate> ...
この例では、シングル・オブジェクトを失効化します。ただし、このオブジェクトは最大30分(1800秒)間は有効状態を維持できます。
... <jesi:invalidate url="http://yourhost.yourcompany.com:4001" username="invalidator" password="invpwd"> <jesi:object uri="/images/logo.gif" maxRemovalDelay="1800"/> </jesi:invalidate> ...
この例では、「例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
タグを使用すると、キャッシュ内のページを提供する前に現在のリクエストのCookie値を置換するようESIプロセッサに指示するで、ページをカスタマイズできます。
このタグの効果は、ESIプレースホルダをCookie名および値とともにレスポンス・ボディに挿入することです。 name
属性で指定されたCookieがリクエスト内にあり、NULL以外の値が指定されている場合は、その値が使用されます。 Cookieがリクエストにないか、NULL値であっても、値がdefault
属性で指定されている場合は、新しいCookieが作成され、default
値が使用されます。 Cookieが以前に存在せず、default
値が指定されていない場合、タグを使用しても効果はありません。
personalize
タグにボディはありません。
<jesi:personalize name = "cookie_name" [ default = "default_value" ] />
注意: 下位互換性を保つために、 |
次の例は、JESI personalize
タグの使用方法を示しています。
<jesi:personalize name="user_id" default="guest" />
生成されたESIタグによって、ESIプロセッサは必要な情報を検出できます。 この場合、プロセッサは、user_id
という名前のCookieを検索し、その値を取得します。 このCookieが見つからない場合は、デフォルト値の「guest
」を使用します。
ESIプロセッサでのこのCookie値置換の処理により、ESIプロセッサは、アプリケーション・サーバーを関与させずに単一のキャッシュされたコピーから複数のカスタマイズされたページを処理できます。
JESIタグ・ハンドラ・クラスは、OC4JのJESIタグ・ライブラリの一部として提供され、JSP機能からESI機能へのブリッジの役を果たします。タグ・ハンドラでは、JESIタグからのESIタグの生成、失効化に対するHTTPリクエストの生成、HTTPレスポンス・ヘッダーの設定などをします。ただし、この変換は、JESIタグとESIタグの間またはJESIタグ属性とESIタグ属性の間の単純な1対1のマッピングとはかぎりません。
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プロセッサ上で個別にキャッシュされるため、これらのページに対するリクエストは不要です。
従業員が企業イントラネット・サイトに接続する場合を想定します。すべてのレスポンスに存在する少数の機能を除いて、そのページのコンテンツは動的です。特に、株式チャートとその企業に関する最新のビジネス見出しを表示するフッターは常に存在しています。このビジネス見出しは外部のビジネス・ニュース・サイトから取得されます。戻すページのすべてに同じ情報が含まれている必要があり、取得にはコストがかかるため、このフッターは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つのフラグメントをフェッチしてキャッシュします。その後で、合成されたページが従業員に戻されます。従業員がそのページで再度作業をすると、動的コンテンツが新規に生成されます。ただし、チャートとフッターはキャッシュから提供されます。
Copyright © 1997, 2004, Oracle. All rights reserved.