10g（10.1.3.1.0）
B31854-01
 目次 |
 索引 |
| Oracle Containers for J2EE JSPタグ・ライブラリおよびユーティリティ・リファレンス 10g（10.1.3.1.0） B31854-01 |
|
この章では、OC4Jが提供するEdge Side Includes for Java（JESI）タグ・ライブラリについて説明します。これらのタグは、Oracle Web Cacheで使用可能なEdge Side Includes（ESI）フレームワークの上で稼働して、JSPアプリケーションにESIキャッシング機能を提供します。
この章には、次の項目が含まれます。
Oracle Web Cache、Oracle Application Server Java Object CacheおよびOC4J Web Object Cacheの説明を含むWebキャッシングの概要は、「Webアプリケーションに対するOracleキャッシング・サポートのサマリー」を参照してください。
JESIタグは、JSPページの動的コンテンツをキャッシュ可能なコンポーネントに分割します。その基礎となるのがEdge Side Includesのアーキテクチャとマークアップ言語です。
JESIタグの使用は、特定のESIプロセッサやキャッシング・システムに依存しているわけではありませんが、通常、Oracleユーザーは、Oracle 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ページを定義できます。また、HTTPクライアントで表示するために、必要に応じて、ESIプロセッサで取得およびアセンブルするキャッシュ可能コンポーネントを定義できます。集約ページは、ユーザーが指定したURLに関連付けられているリソースですが、これはアセンブリ用のコンテナと考えることができます。これには、ESIタグを使用して指定された取得用とアセンブリ用の命令が含まれます。
サロゲートは、ページ・コンテンツを所有するWebサーバーのかわりに動作するため、コンテンツ所有者は、サロゲートの動作を完全に制御できます。これにより、サロゲートを使用しない場合に比較して、大幅なパフォーマンスの向上が可能になります。
サロゲートでのキャッシング処理は、HTTPでのキャッシング処理に類似しています。どちらも、類似した鮮明な妥当性チェック機能を基盤として使用しています。ただし、サロゲートには、その上に制御機能も備わっています。
ESI言語のバージョン1.0には、次の主要な機能が含まれています。
ESIプロセッサは、ネットワークから取得された動的コンテンツのフラグメントを、集約ページにアセンブルして、ユーザーに出力します。各フラグメントには、独自のメタデータがあり、そのフラグメントのキャッシング動作を制御できます。次の図6-1を参照してください。
ESIは、HTTPのリクエスト属性に基づく変数の使用をサポートしています。ESI文では、処理時に変数を使用することも、その変数を処理済のマークアップに直接出力することもできます。
ESIでは、ページの処理方法の判断に、条件付きロジックのブール比較を使用できます。
一部のESIタグは、デフォルト・リソースまたは代替リソース（あるいはその両方）の指定をサポートしています。代替リソースには、プライマリ・リソースが検出できなかった場合の代替Webページなどがあります。
この項では、Oracle Web CacheとそのESIプロセッサを紹介します。詳細は、『Oracle Application Server Web Cache管理者ガイド』を参照してください。
Oracleでは、Webサイトのパフォーマンスの問題を抱えるE-Businessを支援するために、Oracle Web Cacheを提供しています。この製品は、コンテンツ対応のサーバー・アクセラレータ、つまりリバース・プロキシ・サーバーであり、Oracle Application Server上で稼働するWebサイトのパフォーマンス、スケーラビリティおよび可用性を向上させます。
Oracle Web Cacheでは、頻繁にアクセスされるURLのページをメモリーに格納することによって、Webアプリケーション・サーバー上でこれらのURLに対するリクエストを繰り返して処理する必要がなくなります。静的ドキュメントのみを処理するレガシー・プロキシ・サーバーとは異なり、Oracle Web Cacheは、1つ以上のWebアプリケーション・サーバーからの静的コンテンツと動的に生成されたコンテンツの両方をキャッシュします。キャッシュ・ヒットの数が増えるため、レガシー・プロキシよりもパフォーマンスが強化され、アプリケーション・サーバーへの負荷が減少します。
概念的には、Oracle Web Cacheは、Webアプリケーション・サーバーの手前に位置しており、Webサーバーのコンテンツをキャッシュし、そのコンテンツをリクエストしているWebブラウザに送信します。Webサイトへのアクセス時に、Webブラウザは、HTTPプロトコルまたはHTTPSプロトコルのリクエストをOracle Web Cacheに送信します。すると、Oracle Web CacheがWebアプリケーション・サーバーに対する仮想サーバーとして動作します。リクエストされたコンテンツがすでに期限切れの場合、無効になった場合またはアクセスできない場合、Oracle Web Cacheは、そのWebアプリケーション・サーバーから新しいコンテンツを取得します。
次に、ブラウザとOracle Web Cacheとの典型的な対話のステップを示します。
Oracle Web Cacheには、キャッシングにおけるEdge Side Includesマークアップ言語の使用をサポートするESIプロセッサが組み込まれています。（詳細は、「Edge Side Includesテクノロジ」を参照してください。）
Oracle Web Cache環境のWeb開発者は、アプリケーションでESI言語を直接使用できます。ただし、JSP開発者の場合は、様々な理由から、ESI言語に対する便利なJSPインタフェースとして提供されているJESIタグ・ライブラリを使用します。「JESIタグのメリット」を参照してください。
次の各項では、JESI機能とOracleによる実装について説明します。
次のWebサイトからJESIの提案仕様にアクセスできます。
http://www.esi.org
OC4Jでは、JESIタグ・ライブラリを、ESIタグとWebキャッシングに関するEdge Side Includes機能への便利なインタフェースとして提供しています。開発者は、WebアプリケーションでESIタグを直接使用できますが、JSPページではJESIタグを使用したほうが便利です。次に、ESIタグを直接使用せずに、JESIタグを使用する主なメリットについて説明します。
JESIタグは、メタデータ情報（キャッシュ内のページの期限切れなど）の指定、必要に応じたページの明示的な無効化、およびCookie情報を使用したページのパーソナライズなどに使用する便利な構文とタグ属性をサポートしています。
JESIタグ・ライブラリでは、アプリケーション・レベルの構成ファイルを使用して、特定の環境に適したデプロイ時パラメータとアプリケーションのデフォルト設定を簡単に指定できます。このようにして、多様なニーズを持つ様々な環境にデプロイし、アプリケーション・コードを変更せずに、適切なデフォルトを設定できます。たとえば、このような構成ファイルを使用して、無効化リクエストに対して、キャッシュ・サーバーのURL、ユーザー名およびパスワードを事前に設定できます。
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タグ・ライブラリは、次のタグをサポートします。
control、JESI include、JESI param、JESI template、JESI fragmentおよびJESI codeblock
invalidate（およびサブタグ）
personalize
JSP開発者は、対応するESIタグ（esi:includeなど）ではなく、これらのタグ（JESI includeなど）を使用します。このタグの有用性と利便性については、「JESIタグのメリット」で説明しています。
JESIタグを使用して、集約ページとそのキャッシュ可能コンポーネントを定義する方法には、次の2つのモデルがあります。
この項では、これら2つのモデルについて説明し、最後にJESI includeタグに関する特記事項を説明します。
JESIタグをcontrol/include方式で使用する方法は、モジュール化された方法です。この方法では、通常、ほとんど（またはすべて）のキャッシュ可能コンテンツをインクルード・ページとして集約ページに表示します。この方法は、新規ページを開発する場合に特に便利です。このモデルは、次のように使用します。
controlタグをトップレベルのページで使用し、必要に応じて、インクルード・コンテンツ以外のコンテンツにキャッシング・パラメータを設定します。
includeタグを使用して、動的コンテンツをインクルードします。
controlタグを各インクルード・ページ内で使用し、必要に応じて、これらのページにキャッシング・パラメータを設定します。
各インクルード・ファイルは、個別のキャッシュ可能オブジェクトです（ただし、タグ設定によってキャッシングを無効にできます）。また、トップレベルのページのコンテンツもすべて個別オブジェクトです。
状況によっては、両タグともオプションになります。ページには、JESI controlタグを、JESI includeタグなしで指定できます。実際に、これが既存のページを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タグの属性設定またはデフォルトの属性値（使用可能な場合）によって決まります。
controlタグがある場合、キャッシュ可能かどうかは属性設定またはデフォルトの属性値（使用可能な場合）によって決まります。
controlタグがない場合、キャッシュ可能かどうかは、ESIプロセッサの設定によって決まります。
テンプレートとフラグメントは、独立したキャッシュ可能オブジェクトであるため、ESIプロセッサで期限切れになる時点が異なる場合があります。キャッシュ・ミスの発生時、または期限切れオブジェクトがリクエストされた時、ESIプロセッサは、オリジナル・サーバー（Oracle Application Serverの場合はOC4J）に新しいコピーをリクエストします。
リクエストされたオブジェクトがJESIテンプレートの場合、JSPコンテナはフラグメント以外のページのコードを実行します。JSPトランスレータは、生成した出力に、フラグメントをインクルードする場所を指定するESIマークアップを配置します。この時点では、JESIフラグメントに格納されているコードは実行されません。この後の図6-2で説明します。
フラグメントが期限切れになると、ESIプロセッサはオリジナル・サーバーに対して、その特定のフラグメントをリクエストします。フラグメントを実行するために、OC4J JSPコンテナは、テンプレート・コード（フラグメント以外のコード）に加えて、リクエスト対象のフラグメントのコードを実行します。テンプレート・コードの実行により、フラグメントは変数の宣言や初期化など、特定の副次効果に依存可能になります。
フラグメント・コードの出力はレスポンスで戻され、テンプレート・コードの出力は破棄されます。レスポンスを受信すると、ESIプロセッサはフラグメントの更新済コピーをキャッシュします。この後の図6-3で説明します。
テンプレートとフラグメントのコード位置と期限切れのポリシーを選択する際には、この動作に注意してください。特に、テンプレート・コードは更新リクエストのたびに実行されるため、コストのかかるコードを配置する位置に注意します。コストのかかる計算は、毎回実行が必要な場合またはcodeblockタグ内に適切に配置されている場合を除いて、テンプレート・レベルに配置しないでください。それ以外の場合、コストのかかる計算は、できるだけ期限切れ期間が長いフラグメントに配置します。
図6-4に、codeblockタグの使用例を示します。この例では、コード・ブロックはフラグメントのリクエスト時にのみ実行されます。この図では、リクエストはテンプレートに関するものであるため、コード・ブロックは実行されません。
図6-5に、codeblockタグのもう1つの使用例を示します。この例でも、コード・ブロックはフラグメントのリクエスト時にのみ実行されます。ただし、この図では、リクエストはフラグメントに関するものであるため、コード・ブロックが実行されます。
同一リクエスト時に、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タグ内）にコードを配置することを検討する必要があります。
jsp:include標準アクション・タグは、flush属性の値がfalseに設定されているかぎり、template/fragmentモデルと一緒に使用できます。JESIテンプレート・タグのボディでコードを実行しているとき、自動フラッシュは使用できません。 この制限は、JESI templateタグまたはfragmentタグにネストされているjsp:includeタグと、JESI templateタグのあるページを含むタグに適用されます。
次に例を示します。
<jsp:include page="templ.jsp" flush="true">
このJSPコードは、templ.jspに次の内容が含まれているとランタイム・エラーになります。
<jesi:template> <jesi:fragment> ... </jesi:fragment> </jesi:template>
同様に、次のコードもランタイム・エラーになります。
<jesi:template> <jesi:fragment> ... </jesi:fragment> <jsp:include page=morefragments.jsp" flush="true"> </jesi:template>
JSPページ・バッファが一杯になると、flush属性がtrueに設定されていなくても、コンテンツの自動フラッシュが発生することがあります。このため、JESI template/fragmentモデルをjsp:includeアクションと混在させないようにするか、制限事項に特に注意することをお薦めします。
データベース内の関連データへの変更など、外部の状況によっては、キャッシュ内のオブジェクトを明示的に無効化する必要があります。また、あるページの実行によって、別のページに対応しているキャッシュ内のオブジェクトのデータが無効化される場合もあります。
このため、JESIには、JESI invalidateタグと関連サブタグが用意されています。これらのタグを使用すると、次の適切な組合せに基づいてページを無効化できます。
無効化メッセージはXMLベースのフォーマットで、無効化する対象のURLを指定します。このメッセージは、JESI invalidateタグの実行時にJSPコンテナで起動され、POSTメソッドによってHTTPを介してキャッシュ・サーバーに転送されます。次に、キャッシュ・サーバーが応答し、無効化レスポンスがHTTPを介して返信されます。
タグ構文と例は、「キャッシュ内のオブジェクトの無効化に使用するタグとサブタグの説明」を参照してください。
動的Webページには、個別のユーザーにあわせてカスタマイズされた情報が頻繁に表示されます。たとえば、「ようこそ」のページには、ユーザー名や特別な挨拶文、あるいはユーザーが所有している株式の現在の相場などが表示されます。
このようなカスタマイズされた出力の場合、Webページは、JESI personalizeタグによって提供されるCookie情報に依存します。このタグは、Cookie置換を実行する必要があることをESIプロセッサに通知します。このタグがない場合は、Webページを複数のユーザーがESIレベルで共有できません。
タグ構文と例は、「ページのパーソナライズに使用するタグの説明」を参照してください。
|
注意 このタグを、さらに多くの機能を含むOracle Application Server Personalizationタグ・ライブラリと混同しないでください。JESIパーソナライズでは、ESIプロセッサが、キャッシュ内のページのプレースホルダを、リクエストまたはレスポンスで送信されたCookieに基づく動的な文字列で置換します。このプロセスにより、様々なユーザーが同じキャッシュ内のページを共有できます。OracleAS Personalizationは、バックエンドのデータ・マイニングを使用するため、さらに動的でより広範囲に対応します。これは、ユーザーのアクティビティに応じて自動的に変化する出力を生成します。詳細は、第10章「パーソナライズ・タグ」を参照してください。 |
JESIタグを使用するページに使用可能なESIプロセッサがない場合（Oracle Web CacheがインストールされていないシステムやWeb CacheまたはそのESIプロセッサが障害を起こしているシステムなど）は、OC4JのJSPコンテナがそのページを適切にアセンブルします。実質的には、最も重要な機能を引き継いで提供し、ページを適切に実行します。キャッシングは発生せず、JESIタグ属性値のエラー・チェックも実行されません。
これらの状況では、JSPコンテナは特定のJESIタグを次のように処理します。
controlタグを無視します。
includeタグをjsp:includeタグであるかのように実行し、関連するJESI paramタグをjsp:paramタグであるかのように実行します。JESI includeタグ内でネストしているスクリプトレット・コードも実行されることに注意してください。templateおよびfragmentタグが適切にネストしているかどうかをチェックしますが、それ以外はこれらのタグを無視して、単一のリクエストですべてのタグ・ボディを実行します。
codeblockタグ内のコードを無条件で実行します。
invalidationタグとすべてのサブタグを無視します。
personalizeタグについては、Cookieが存在していた場合は、レスポンス・ボディにCookie値を挿入します。以前にCookieが存在せず、personalizeタグにデフォルト値が指定されている場合、JSPコンテナはレスポンス・ボディにデフォルト値を挿入します。以前にCookieが存在せず、デフォルト値が指定されていない場合、personalizeタグは効果がありません。
次の各項では、OC4Jが提供するJESIタグの構文と属性を説明し、使用例を示します。
JESIタグ・ライブラリを使用する場合は、次の要件に注意してください。
ojsputil.jarファイルに含まれています。このファイルは、予約済のタグ・ライブラリ・ディレクトリにあります。このファイルがインストール済で、クラスパスに存在していることを確認してください。
jesitaglib.tldが、アプリケーションで使用可能である必要があります。また、ライブラリを使用するJSPページには、適切なtaglibディレクティブが存在する必要があります。Oracle Application Serverインストールでは、TLDはojsputil.jarファイルに配置されます。jesitaglib.tldのuri値は次のとおりです。
http://xmlns.oracle.com/j2ee/jsp/tld/ojsp/jesitaglib.tld
taglibディレクティブ、予約済のタグ・ライブラリ・ディレクトリ、TLDファイルおよびuri値の内容の詳細は、『Oracle 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タグを持つページなど）は、独立したレスポンスとなることに注意してください。
templateタグを検出しており、同じレスポンスの生成中にJESI controlタグを検出すると、controlタグは無視されます。
controlタグを含むページがリクエスト・パラメータに依存する場合は、リクエストの問合せ文字列に応じてページの異なるバージョンをキャッシュする必要があるかどうかを検討してください。異なるリクエスト・パラメータ値が多すぎるため、キャッシュ内のページのバージョンが多くなりすぎることが予想される場合は、そのページをまったくキャッシュしない選択もできます（つまり、cache="no"を設定します）。
<jesi:control [ expiration = "value" ] [ maxRemovalDelay = "value" ] [ cache = "yes" | "no" | "no-remote" ] [ control = "uninterpreted_string" ] />
expiration: キャッシュ内のオブジェクトの存続期間を秒単位で指定します。デフォルトは86400（24時間）です。 maxRemovalDelay: 期限が切れたキャッシュ内のオブジェクトを、ESIプロセッサで引き続き格納できる最大時間（秒単位）を指定します。デフォルトは0（ゼロ）で、即時に削除されます。
cache: タグに対応するレスポンスがキャッシュ可能かどうかを指定します。「yes」（デフォルト）に設定すると、キャッシュ可能になります。キャッシングを無効化するには、cacheを「no」に設定します。また、リモートESIプロセッサやコンテンツ配信ネットワーク上ではなく、最も近いキャッシュへのキャッシングのみを有効にするには、「no-remote」に設定します。ページをキャッシュ不可にするのは、たとえば、JESI includeタグをcopyParam="yes"に設定して使用している場合です。次の「JESI includeタグ」を参照してください。
control: この属性の値は、JESI controlタグの処理中に作成されたSurrogate-Controlレスポンス・ヘッダーを変更せずに追加されます。Oracle 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タグを介してインクルードされるページにJESI includeタグを使用する方法と、標準jsp: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 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: インクルード・ページがリクエスト・パラメータを使用する場合は、この属性を「true」に設定すると、集計ページのHTTPリクエスト文字列からインクルード・ページにパラメータとその値をコピーできます。デフォルト値は「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は、カスタマの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]%>" /> <% } } %>
次に、リクエスト・パラメータを含む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タグがないかぎり、キャッシュ可能です。
次に、インクルード・ページ・リクエストに新規パラメータとしてランタイム値を追加する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>
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タグがなく、この項で説明する他の関連する制限に従っていれば、標準jsp:includeタグを介してインクルードされるページにJESI templateタグを配置できます。ただし、JESI templateタグ、JESI fragmentタグおよびjsp:includeタグを混在させるときは注意してください。具体的には、jsp:includeのflush属性をtrueに設定することができません。また、JSPバッファが一杯になった場合の自動フラッシュも使用できません。その他の使用方法の詳細は、「JESIとJSP Includesに関する注意」を参照してください。
controlタグを検出しており、同じレスポンスの生成中にJESI templateタグを検出すると、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モデルでは、JESI templateタグ内のJESI templateの開始タグと終了タグの間で、1つ以上のJESI fragmentタグを使用します。（詳細は、「JESIの使用モデル」を参照してください。）JESI fragmentタグはそれぞれ、必要に応じて、JSPページの個別のフラグメントのキャッシング動作を定義します。各フラグメントは独立したキャッシュ可能オブジェクトです。
特定のフラグメントがESI機能によって集約レスポンスにインクルードするためにリクエストされると、ESIプロセッサはそのフラグメントのみを取得します。
JESI fragmentタグには、JESI controlタグおよびJESI templateタグの場合と同じ使用方法で同じ属性を指定します。
次の点に注意してください。
fragmentタグごとに、独自のキャッシング指示をESIプロセッサに指定します。キャッシュ可能かどうかは、指定した属性設定またはデフォルト値（使用可能な場合）によって決まります。JESI templateタグの設定は、フラグメントには影響を与えません。
fragmentタグを別のJESI fragmentタグにネストすることはできません。
templateタグとfragmentタグ（使用可能な場合）が必要な場合に、キャッシング指示をESIプロセッサに移譲できません。キャッシュ可能かどうかは、常に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タグは1つのコード・ブロックを囲み、その実行のタイミングを次のように指定します。
または
または
このタグを使用しないと、リクエストごと（各テンプレート・リクエストと任意のフラグメントに対する各リクエスト）にすべてのテンプレート・コードが実行されますが、フラグメント・リクエストの場合はテンプレート出力が破棄されます。
フラグメントがリクエストされるたびにテンプレートを実行することが重要ですが（フラグメントが変数宣言や初期化のようなテンプレート・コードの副次効果に依存できるようにするため）、フラグメントに重要でないコード・ブロックも存在する場合があります。この種のコード・ブロックを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ファイル内でOracle Web Cacheの「invalidator」アカウント用に<user>要素を指定すると、パスワードをクリア・テキストで指定するかわりに、password属性に特殊構文を使用してjazn-data.xml内の情報を参照できます。パスワードは、jazn-data.xmlでは不明瞭化された形式で指定されます。次のusernameおよびpassword属性の説明を参照してください。jazn-data.xmlファイルの詳細は、『Oracle Containers for J2EEセキュリティ・ガイド』を参照してください。
url: キャッシュ・サーバーのURLを指定します。この属性を省略すると、ユーザー名、パスワードとともにURLをJESI構成ファイルに指定する必要があります。
username: 無効化のためにキャッシュ・サーバーにログインするユーザー名を指定します。Oracle Web Cacheでは、通常、「invalidator」ユーザー名が必要です。この属性を省略すると、パスワード、URLとともにユーザー名をJESI構成ファイルに指定する必要があります。OC4Jのjazn-data.xmlファイルにOracle Web Cacheの「invalidator」アカウント用の<user>要素が含まれている場合は、そのアカウント名をusername値に次のように使用できます。
username="invalidator"
password: 無効化を実行するためにキャッシュ・サーバーにログインするためのパスワードを指定します。この属性を省略すると、ユーザー名、URLとともにパスワードをJESI構成ファイルに指定する必要があります。OC4Jのjazn-data.xmlファイルにOracle Web Cacheの「invalidator」アカウント用の<user>要素が含まれている場合は、次のように特殊な右矢印構文でダッシュ（-）と右山カッコ（>）に続けてinvalidatorアカウント名を指定して、そのファイルから不明瞭化されていないパスワードを取得できます。
password="->invalidator"
config: アプリケーション相対位置またはページ相対位置を使用して、JESI構成ファイルを指定します。この構成ファイルを使用すると、対応するタグ属性を使用せずに、キャッシュ・サーバーのURL、無効化の基準となるユーザー名およびパスワードを指定できます。次の点に注意してください。
config属性に指定するかわりに、デフォルトの場所にある構成ファイルを使用できます。「JESI構成ファイル」を参照してください。
username、passwordおよびurlをすべて指定すると、構成ファイルは参照されません。
output: 必要に応じて、キャッシュ・サーバーから無効化レスポンスを受信する出力デバイスを設定します。現在サポートされている設定は、ユーザーのWebブラウザにメッセージを表示するためにWebキャッシュ・レスポンスをHTML形式でラップする「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属性設定が（3つすべて）指定されている場合は、その値が使用されます。invalidateタグにusername、passwordおよびurlを指定せずにconfig属性に構成ファイルを指定すると、指定した構成ファイルからの値が使用されます。
invalidateタグにusername、password、urlおよびconfigを指定しないと、JSPコンテナはデフォルトの構成ファイルを使用します。最初に、コンテナは/WEB-INF/jesi.xmlファイルを検索し、見つかった場合はそのファイルからの設定を使用します。ファイルが見つからない場合は/WEB-INF/config.xmlを検索し、見つかった場合はそのファイルからの設定を使用します。OC4Jのjazn-data.xmlファイルにOracle Web Cacheの「invalidator」アカウント用の<user>要素が含まれている場合は、特殊な右矢印構文でダッシュ（-）と右山カッコ（>）に続けてinvalidatorアカウント名を指定して、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にOracle 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タグのサブタグ）のJESI cookieサブタグを1つ以上使用します。この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タグのサブタグ）のJESI headerサブタグを1つ以上使用します。このヘッダー情報は、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プロセッサに指示して、ページのカスタマイズを許可します。
このタグには、Cookie名と値を含むESIプレースホルダをレスポンス・ボディに挿入する効果があります。name属性に指定したCookieがリクエスト内で見つかり、null以外の値が指定されている場合は、その値が使用されます。リクエスト内でCookieが見つからないか、null値が指定されていても、default属性に値が指定されている場合は、新規Cookieが作成され、defaultの値が使用されます。以前にCookie値が存在せず、default値が指定されていない場合、このタグは効果がありません。
personalizeタグには、ボディはありません。
<jesi:personalize name = "cookie_name" [ default = "default_value" ] />
name（必須）: ページのパーソナライズに使用する値を持つCookieの名前を指定します。
default: Cookieが見つからない場合、またはnull値が指定されている場合のオプションのデフォルト値です。
次に、JESI personalizeタグの使用例を示します。
<jesi:personalize name="user_id" default="guest" />
生成されたESIタグによって、ESIプロセッサは必要な情報を検出できます。この場合、プロセッサは、user_idという名前のCookieを検索し、その値を取得します。このCookieが見つからない場合は、デフォルト値の「guest」を使用します。
このCookie値の置換をESIプロセッサで処理することによって、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 © 2002, 2006 Oracle Corporation. All Rights Reserved. |
|