| Oracle Coherence Oracle Coherence*Webユーザーズ・ガイド リリース3.6.1 B61371-02 |
|
 前 |
 次 |
|
注意: 特に明記する場合を除き、この章ではWebLogic Server 11gリリース2(10.3.3)について説明します。 |
Coherence*Webでは、セッション状態の持続および管理が実現されます。セッション・データの格納および管理にCoherenceを使用するのは、セッション管理モジュールです。この章では、WebLogic Server上で実行しているアプリケーションから使用できるようにCoherence*Webを設定およびデプロイする方法について説明します。
Coherence*Webは、WebLogic Serverのメモリー内HTTP状態レプリケーション・サービスにかわるものです。次のいずれかの状況に該当する場合は、Coherence*Webの使用を検討してください。
アプリケーションで使用するHTTPセッション状態オブジェクトが大きい
HTTPセッション・オブジェクト・データの格納に起因するメモリー制約がある
HTTPセッション記憶域の負荷を既存のCoherenceクラスタに分散させる必要がある
セッション状態を複数のEARファイル間で共有する必要がある
Coherence*Webサービス・プロバイダ・インタフェース(SPI)は、coherence-web-spi.warファイルで構成されています。Coherence*Webの機能を有効にするには、SPIにcoherence.jarも必要です。
Coherence*Webでは、次のデフォルト・キャッシュ構成が定義されています。
WebLogic Server向けCoherence*Web SPIは、ローカル記憶域を無効にした状態で構成します。サーバーはリクエストの処理に使用され、データのホストには使用されません。これは、WebLogic Serverを実行しているJVMとは別に、Coherenceキャッシュ・サーバーを専用のJVMで実行する必要があることを意味します。
キャッシュ・サーバーがリクエストに応答するまでのタイムアウトは30秒です。キャッシュ・サーバーへのリクエストに対して30秒以内に応答が返らない場合は、com.tangosol.net.RequestTimeoutException例外がスローされます。
session-cache-config.xmlファイルには、Coherence*Web SPIで使用するCoherenceキャッシュの構成が含まれています。このファイルは、coherence-web-spi.warファイルのWEB-INF\classesディレクトリにあります。すべてのキャッシュの構成の変更は、session-cache-config.xmlに入力した後、coherence-web-spi.warファイルに再パッケージ化する必要があります。
Coherence*Webには、セッションの同時アクセスを制御するためのセッション・ロック・モードがいくつかあります。Coherence*WebとCoherence*Web SPIの両方に、オプティミスティック・ロックがデフォルトで採用されています。これにより、単一のJVMまたは複数のJVMにある複数のスレッドからセッションに同時アクセスできます。ただし、セッションを同時に変更できません。ロック・モードの詳細は、「セッション・ロック・モード」を参照してください。
Coherence*Web SPIは、単独ではロード・バランサをWebLogic Server層の前で実行する必要はありません。ただし、オプティミスティック以外のいずれかのロック・モードでスティッキー・セッション最適化を採用する場合は、ロード・バランサが必要です。デフォルトのロード・バランサでは、HTTPセッションのJVMアフィニティを適用しますが、他のロード・バランシング方法も使用できます。WebLogic Serverには、JVMセッションの持続性を維持するための様々なプロキシ・プラグインが付属しています。WebLogic Serverプロキシ・プラグインの構成に関するドキュメントは次のURLから入手できます。
http://download.oracle.com/docs/cd/E12840_01/wls/docs103/cluster/load_balancing.html#wp1026940
Coherence*Webにはデプロイ可能な共有ライブラリが付属しています。そのライブラリには、WebLogic ServerのHTTPセッション管理インタフェースへのネイティブ・プラグインが含まれます。次の手順は、WebLogic Server上で実行しているアプリケーションでCoherence*Webを使用するためにデプロイメントを準備する方法を示しています。
Oracle Coherenceをファイル・システムにダウンロードします。「Oracle Coherenceのダウンロード」を参照してください。
アプリケーションがCoherence*Web用に高度な構成を必要とする場合は、WARデプロイメントのweb.xmlファイルを変更します。Webアプリケーションに対して構成可能なパラメータについては、「Coherence*Webの構成」で説明します。Coherence*Webのすべてのパラメータについては、付録A「Coherence*Webコンテキスト・パラメータ」を参照してください。
(オプション)WebLogicによって生成されるHTTPセッションCookieパラメータをweblogic.xmlまたはweblogic-application.xmlで構成します。「セッションCookieの構成」を参照してください。
(テストの場合はオプション、本番の場合は強く推奨)WebLogic Serverを実行しているJVMとは別のJVMでキャッシュ・サーバー層を起動します。「キャッシュ・サーバーの起動」を参照してください。
デプロイメント要件に基づいて適切なパッケージ化を決定し、そのパッケージ化手順に従います。Weblogic Serverのバージョンに応じて、「クラスタ・ノードの構成(WebLogic Server 10.3.3以降)」または「クラスタ・ノードの構成(WebLogic Server 10.3.2以前)」を参照してください。
Coherence*Webをサポートしているすべてのファイルは、coherence-web-spi.warを含めて、Coherenceディストリビューションに付属しています。
デフォルトでは、WebLogic Server 10.3.3とともにCoherence 3.5がインストールされます。Weblogic Server 10.3.3を使用している場合は、サーバーとともにインストールされたcoherenceディレクトリの内容を、Coherence3.6ディストリビューションの内容と置き換える必要があります。Coherenceディレクトリのデフォルトの場所は、C:\Oracle\Middleware\coherence_3.5です。
WebLogic Server 10.3.2以前を使用している場合は、Coherenceディストリビューションをファイル・システムにダウンロードしてください。
Coherence*Web SPIにより、大半のWebアプリケーションに対応するデフォルト構成を実現します。表2-1に、Coherence*Webコンテキスト・パラメータの中でSPIバージョン用のデフォルトがSPI以外のバージョンとは異なるもののみを示します。すべてのCoherence*Webパラメータの詳細は、付録A「Coherence*Webコンテキスト・パラメータ」を参照してください。
コンテキスト・パラメータは、システム・プロパティとしてコマンドラインで構成することもできます。システム・プロパティは、コンテキスト・パラメータと同じ名前を持ちますが、ダッシュ(-)がピリオド(.)に置き換えられています。たとえば、coherence-enable-sessioncontextコンテキスト・パラメータの値をコマンドラインで宣言するには、次のように入力します。
-Dcoherence.enable.sessioncontext=true
システム・プロパティと、同等のコンテキスト・パラメータの両方が構成されている場合、システム・プロパティの値が使用されます。
表2-1 Coherence*Web SPIのコンテキスト・パラメータ
| パラメータ名 | 説明 |
|---|---|
|
|
Coherence*Webではこのパラメータの値を使用して、 アプリケーション名 + ! + Webモジュール名 ここで、application nameは たとえば、 このパラメータが構成されていない場合、Coherence*Webでは、かわりにクラス・ローダーの名前が使用されます。また、このパラメータが構成されておらず、 |
|
使用する その他の使用可能な値には、 デフォルトは、 |
|
|
この設定により、リーパーでは、(たとえば、分散キャッシュ・サービスによって)このノードに保存されるセッションは、期限切れをチェックする必要のあるセッションのみであると仮定できます。リーパーを実行していないノードでセッションの記憶域キャッシュを管理している場合は、この値を キャッシュ・サーバーを使用している場合は、「スプリット」モデルを選択し、全体をそのキャッシュ・サーバーで管理している独立した分散キャッシュ・サービスでセッションのオーバーフロー記憶域を実行します。セッションの記憶域キャッシュ自体は、全体をアプリケーション・サーバーJVMで管理している分散キャッシュ・サービスに残します。これによって、この「ローカル性を前提とした」機能を活用できます。 デフォルトは |
|
|
この値は、使用するオプションの 有効な値は次のとおりです。
デフォルトは、 |
|
|
このパラメータは、Coherence*WebのSPIバージョンにのみ使用できます。この値を グローバル・スコープ・コントローラが指定されていないかぎり、デフォルトで |
Coherence*Web SPIを実行すると、WebLogic ServerによってセッションCookieが生成および解析されます。ネイティブCoherence*WebセッションCookie構成パラメータはすべて無視されます。セッションCookieは、weblogic.xmlまたはweblogic-application.xmlのセッションCookieパラメータを使用して構成する必要があります。
表2-2に、weblogic.xmlまたはweblogic-application.xmlで構成できるWebLogic生成HTTPセッションCookieパラメータを示します。
この表で、更新可否は、サーバーの実行中にパラメータの値を変更できるかどうかを示します。N/Aは、対応するCoherence Cookieパラメータがないことを示します。
表2-2 HTTPセッションCookieパラメータ
| WebLogic生成セッションCookieパラメータ | 置き換えられるCoherence*Web Cookieパラメータ | 説明 |
|---|---|---|
|
|
|
Cookieファイルにあるセッション追跡Cookieを特定するコメントを指定します。 デフォルトは 更新可能? はい |
|
|
|
Cookieを有効にするドメインを指定します。たとえば、 このドメイン名では2つ以上の要素を指定する必要があります。 値を設定しない場合は、Cookieを発行したサーバーにデフォルトで設定されます。 詳細は、「Sun社のサーブレット仕様で デフォルトは 更新可能? はい |
|
|
|
セッションCookieの存続期間(秒)を設定します。この時間が経過したクライアントではセッションCookieが期限切れになります。Cookieの詳細は、「セッションとセッション持続性の使用」を参照してください。 デフォルト値は 更新可能? はい |
|
|
|
セッション追跡Cookieの名前を定義します。設定しない場合は、デフォルトで デフォルトは 更新可能? はい |
|
|
|
セッション追跡Cookieのパスを定義します。 値を指定しない場合は、デフォルトで デフォルトは 更新可能? はい |
|
|
|
HTTPS接続経由でのみCookieを返すようにブラウザに指示します。これによって、Cookie IDのセキュリティを保護できます。この設定は、HTTPSを使用するWebサイトでのみ使用してください。この機能が有効な場合は、HTTP経由のセッションCookieが機能しません。 この機能を使用する場合は、 WebLogic ServerによってセッションCookieが生成されます。 デフォルトは 更新可能? はい |
|
cookies-enabled |
|
セッションCookieの使用がデフォルトで有効になる、推奨の設定ですが、このプロパティを デフォルトは 更新可能? はい |
|
|
N/A |
HTTPセッションに対するデバッグ機能を有効にします。これは、 デフォルト値は 更新可能? はい |
|
|
N/A |
最新のサーブレット仕様では、パス パラメータのセッションIDをコンテナでエンコードする必要があります。Webサーバーの中には、パス・パラメータを適切に処理しないものがあります。そのような場合は、 WebLogic ServerによってHTTPレスポンスが生成されます。 デフォルト値は 更新可能? はい |
|
|
N/A |
WebLogic ServerによってHTTPレスポンスが生成されます。 デフォルト値は 更新可能? はい |
|
|
|
セッションIDのサイズを設定します。 最小値は8バイト、最大値は WAPアプリケーションを作成している場合、WAPプロトコルではCookieがサポートされないので、URLリライティングを使用する必要があります。また、WAPデバイスの中にはURL長を128文字(属性を含む)に制限しているものがあり、その場合はURLリライティングを使用して送信できるデータ量に制限があります。属性に使用できる領域を増やすには、この属性を使用して、WebLogic Serverでランダムに生成されるセッションIDのサイズを制限します。
デフォルトは52です。 更新可能? いいえ |
|
|
|
タイムアウトしたセッションおよび無効なセッションに対してハウスクリーニング・チェックを実行してから、古いセッションを削除してメモリーを解放するまでCoherence*Webが待機する時間(秒単位)を設定します。この要素を使用して、トラフィックが多いサイトで最適なパフォーマンスが得られるようにWebLogic Serverを調整します。 デフォルトは 更新可能? いいえ |
|
|
|
セッションをタイムアウトするまでCoherence*Webが待機する時間(秒単位)を設定します。 アクセスが多いサイトでは、セッションのタイムアウトを適切に設定することによってアプリケーションを調整できます。ブラウザ・クライアントにセッションを終了する機会を提供するとともに、ユーザーがサイトを離れたりその他の方法でセッションを破棄した場合に、サーバーを不要に拘束しないようにします。 この要素は、 デフォルトは 更新可能? いいえ |
|
|
|
HTTPリクエスト間のセッション・トラッキングを有効にします。 WebLogic ServerによってHTTPレスポンスが生成されます。 デフォルトは 更新可能? いいえ |
|
|
|
URLリライティングを有効化します。これにより、ブラウザでCookieが無効化されている場合にセッションIDがURLにエンコードされてセッション・トラッキングが提供されます。URLを書き込むときには http://www.jguru.com/faq/view.jsp?EID=1045 WebLogic ServerによってHTTPレスポンスが生成されます。 デフォルトは 更新可能? はい |
Coherenceデータ・ノード(キャッシュ・サーバーとも呼ぶ)は、キャッシュされるデータすべての格納と管理を担います。これは、専用のJVMであっても、WebLogic Serverインスタンス内で実行されてもかまいません。Coherenceデータ・クラスタ内の上位ノード(最初のノード)は起動に数秒間かかることがあります。下位のノードで必要な起動時間はわずかです。
最初にキャッシュ・サーバーを起動するのか、WebLogic Serverインスタンスを起動するのかは、採用しているサーバー・トポロジによります。
インプロセス・トポロジ(すべて記憶域を有効化したWebLogic Serverインスタンス)を使用している場合、最初にキャッシュ・サーバーを起動しても、WebLogic Serverインスタンスを起動してもかまいません。
アウトオブプロセス・トポロジ(記憶域を無効化したWebLogic ServerインスタンスとスタンドアロンCoherenceキャッシュ・サーバー)を使用している場合は、最初にキャッシュ・サーバーを起動し、次にWebLogic Serverインスタンスを起動します。これにより、Coherenceを使用するアプリケーションの起動時間が最短(ミリ秒単位)になります。Coherenceを使用する追加Webアプリケーションはどれも上位データ・メンバーにならず、そのため、それらがWebLogic Serverの起動に与える影響は最小限になります。
スタンドアロンCoherenceデータ・ノードを起動するには:
Coherenceデータ・ノードを起動するためのスクリプトを作成します。記憶域を有効化したキャッシュ・サーバーを起動するスクリプトの例を次に示します。この例では、Sun JVMの使用を前提としています。詳細は、『Oracle Coherence開発者ガイド』の「JVMのチューニング」を参照してください。
java -server -Xms512m -Xmx512m -cp <Coherence installation dir>/lib/coherence.jar:<Coherence installation dir>/lib/coherence-web-spi.war -Dtangosol.coherence.management.remote=true -Dtangosol.coherence.cacheconfig=WEB-INF/classes/cache_configuration_file-Dtangosol.coherence.session.localstorage=true com.tangosol.net.DefaultCacheServer
この例では、cache_configuration_fileはcoherence-cache-config.xmlファイル内のキャッシュ構成を意味します(注意: Coherence*Webのみを実行している場合、cache_configuration_fileはsession-cache-config.xmlです)。キャッシュ・サーバーに対して定義されているキャッシュ構成は、同じCoherenceクラスタで実行されているアプリケーション・サーバーに対して定義されている構成と同一である必要があります。
セッション管理のためにCoherence*Webを実行している場合、session-cache-config.xmlファイルに含まれるセッション構成をキャッシュ構成関連情報とマージする必要があります。同様に、キャッシュ構成とセッション構成は、WebLogic Serverとキャッシュ・サーバーとの間で一貫している必要があります。
前述の手順で説明したスクリプトを使用して、Coherenceデータ・ノードを1つ以上起動します。
記憶域を有効化したWebLogic Serverインスタンスまたは記憶域を無効化したWebLogic Serverインスタンスを起動するには:
デフォルトでは、Coherence*Webを使用可能なWebLogic Serverインスタンスは、記憶域を無効化した状態で起動します。
記憶域を有効化した状態でWebLogic Serverインスタンスを起動するには、サーバー起動コマンドにコマンド・ライン・プロパティの-Dtangosol.coherence.session.localstorage=trueを含めます。
コマンドラインからのWebLogic Serverの操作の詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverコマンド・リファレンス』のweblogic.Serverコマンドライン・リファレンスに関する項を参照してください。
Coherence*Webは、アプリケーション・サーバー・スコープ、EARスコープまたはWARスコープを設定できます。Coherenceクラスタと同様、Coherence*Webのスコープ設定は、クラスローダーの階層におけるcoherence.jarファイルの位置により異なります。各スコープの詳細は、「クラスタ・ノード分離」を参照してください。
WebLogic Server 10.3.3では、ActiveCacheと呼ばれる、アプリケーションとCoherenceキャッシュとの間の対話を容易にする様々な機能が用意されています。これらの機能の詳細は、ActiveCacheの使用方法ガイドを参照してください。アプリケーションでActiveCache機能を使用するには、active-cache.jarファイルもデプロイする必要があります。このファイルはWL_HOME/common/deployable-librariesディレクトリにあります。
次の各項では、Coherence*Webを実行するための様々なクラスタ・ノードの構成方法を説明します。
|
注意: アプリケーション・サーバー・スコープ設定クラスタ構成の使用は、慎重に検討する必要があります。アプリケーション間の相互作用が未知または予測不能な環境では使用しないでください。このような環境の例として、規則や命名基準の調整や実施が不十分な状態で互いに無関係に作成したアプリケーションを、複数のアプリケーション・チームでデプロイしている状況が考えられます。このような構成では、すべてのアプリケーションが同じクラスタに属することから、キャッシュやサービスなどの他の構成設定と名前空間どうしで競合が発生する可能性がきわめて高く、予期しない結果を生じる恐れがあります。 このような理由から、EARスコープ設定クラスタ・ノードによる構成およびWARスコープ設定クラスタ・ノードによる構成の使用を強くお薦めします。どのデプロイメント・トポロジを選択すればよいか不明な場合や、この警告にご自身のデプロイメントが該当している場合は、アプリケーション・サーバー・スコープ設定クラスタ・ノードによる構成は選択しないでください。 |
セッション管理のためにCoherenceクラスタにCoherence*Webを追加する手順は次のとおりです。
WebLogic Serverシステム・クラスパスを編集し、coherence.jarおよびWL_HOME/common/deployable-libraries/active-cache.jarファイルをシステム・クラスパスに含めます。active-cache.jarファイルは、システム・クラスパスのdeployable-librariesフォルダからのみ参照されるようにする必要があります。他の場所にはコピーしないでください。
WebLogic Server管理コンソールまたはコマンドラインを使用して、coherence-web-spi.warファイルを共有ライブラリとしてデプロイします。
WebアプリケーションでCoherence*Webを有効にします。
Coherence*Webを使用する予定のWebLogic Serverにデプロイした各WARファイルのweblogic.xmlに、例2-1に示すライブラリ参照コードを追加します。
(オプション)Coherenceクラスタ・プロパティを構成する必要がある場合、CoherenceClusterSystemResourceMBean MBeanを作成してServerMBean MBeanで参照します。
WebLogic Scripting Tool (WLST)を使用してMBeanを参照できます。ActiveCacheの使用方法ガイドのcreateServerScopedCoherenceSystemResourceに関する項を参照してください。
セッション管理のためにEARスコープ設定クラスタ・ノードでCoherence*Webを使用する手順は次のとおりです。
WebLogic Server管理コンソールまたはコマンドラインを使用して、アプリケーションがデプロイされるすべてのターゲット・サーバーにcoherence.jarファイル、active-cache.jarファイルおよびcoherence-web-spi.warファイルを共有ライブラリとしてデプロイします。
Oracle Fusion Middleware Oracle WebLogic Server管理コンソールのヘルプのJava EEライブラリのインストールに関する項を参照してください。
weblogic-application.xmlファイルのcoherence.jarファイル、active-cache.jarファイルおよびcoherence-web-spi.warファイルを参照します。このファイルをEARのMETA-INF/ディレクトリに格納します。
例2-2は、weblogic-application.xmlファイルのサンプルを示しています。
例2-2 weblogic-application.xmlで参照されるCoherence、Coherence Web SPIおよびActiveCache
<weblogic-application ... >
...
<library-ref>
<library-name>coherence</library-name>
</library-ref>
<library-ref>
<library-name>coherence-web-spi</library-name>
</library-ref>
<library-ref>
<library-name>active-cache</library-name>
</library-ref>
...
</weblogic-application>
(オプション)Coherenceクラスタ・プロパティを構成する必要がある場合は、CoherenceClusterSystemResourceMBean MBeanを作成し、weblogic.xmlファイルのcoherence-cluster-ref要素として参照します。この要素を使用すると、この要素によって、アプリケーションは、CoherenceClusterSystemResourceMBean属性で指定されたようにCoherenceクラスタに登録できます。詳細は、ActiveCacheの使用方法ガイドを参照してください。
例2-3に構成例を示します。この例のmyCoherenceCluster MBeanは、CoherenceClusterSystemResourceMBeanタイプです。
セッション管理のためにWARスコープ設定クラスタ・ノードでCoherence*Webを使用する手順は次のとおりです。
WebLogic Server管理コンソールまたはコマンドラインを使用して、アプリケーションがデプロイされるすべてのターゲット・サーバーにactive-cache.jarファイルおよびcoherence-web-spi.warファイルを共有ライブラリとしてデプロイします。Oracle Fusion Middleware Oracle WebLogic Server管理コンソール・ヘルプの「Java EEライブラリのインストール」を参照してください。
coherence.jarファイルをWARファイルのWEB-INF/libディレクトリにコピーします。
coherence-web-spi.warファイルを共有ライブラリとしてデプロイする場合、例2-4に示す行をWARファイルのWEB-INFディレクトリにあるweblogic.xmlファイルに追加することによって、共有ライブラリ参照を作成することも必要です。
active-cache.jarファイルを参照するためのmanifest.mfファイルを作成します。manifest.mfファイルを各WARファイルのMETA-INFディレクトリにコピーします。例2-5に、manifest.mfファイルのサンプルを示します。
(オプション)Coherenceクラスタ・プロパティを構成する必要がある場合は、CoherenceClusterSystemResourceMBean MBeanを作成し、それをweblogic.xmlまたはweblogic-ejb-jar.xmlファイルのcoherence-cluster-ref要素として参照します。詳細は、ActiveCacheの使用方法ガイドを参照してください。
例2-6に、weblogic.xmlファイルのWARスコープ設定クラスタ・ノードの構成例を示します。myCoherenceCluster MBeanは、CoherenceClusterSystemResourceMBeanタイプです。
WebLogic Server 10.3.2以前は、ActiveCacheをサポートしていません。
Coherenceクラスタ・ノードにはクラス・ローダーのスコープが設定されています。したがって、アプリケーションをパッケージ化する前に、Coherence*Webデプロイメントにある一意のCoherenceクラスタ・ノードの数を構成する必要があります。次の各項で、パッケージ化オプションと構成オプションについて説明します。
各オプションの詳細は、「クラスタ・ノード分離」を参照してください。
|
注意: アプリケーション・サーバー・スコープ設定クラスタ構成の使用は、慎重に検討する必要があります。アプリケーション間の相互作用が未知または予測不能な環境では使用しないでください。このような環境の例として、規則や命名基準の調整や実施が不十分な状態で互いに無関係に作成したアプリケーションを、複数のアプリケーション・チームでデプロイしている状況が考えられます。このような構成では、すべてのアプリケーションが同じクラスタに属することから、キャッシュやサービスなどの他の構成設定と名前空間どうしで競合が発生する可能性がきわめて高く、予期しない結果を生じる恐れがあります。 このような理由から、EARスコープ設定クラスタ・ノードによる構成およびWARスコープ設定クラスタ・ノードによる構成の使用を強くお薦めします。どのデプロイメント・トポロジを選択したらよいか不明な場合や、この警告に当てはまるデプロイメントを実行する場合は、アプリケーション・サーバー・スコープ設定クラスタ・ノードによる構成は選択しないでください。 |
セッション管理のためにCoherenceクラスタにCoherence*Webを追加する手順は次のとおりです。
WebLogic Serverごとにcoherence-web-spi.warファイルを共有ライブラリとしてデプロイします。
coherence.jarファイルを含めるようにWebLogic Serverのシステム・クラスパスを編集するか、このJARファイルを$DOMAIN_HOME/libディレクトリにコピーします。
WebアプリケーションでCoherence*Webを有効にします。
Coherence*Webを使用する予定のWebLogic Serverにデプロイした各WARファイルのweblogic.xmlファイルに、例2-7に示すライブラリ参照行を追加します。
セッション管理のためにEARスコープ設定クラスタ・ノードでCoherence*Webを使用する手順は次のとおりです。
WebLogic Server管理コンソールまたはコマンドラインを使用して、アプリケーションがデプロイされるすべてのターゲット・サーバーにcoherence.jarファイルおよびcoherence-web-spi.warファイルを共有ライブラリとしてデプロイします。詳細は、Oracle Fusion Middleware Oracle WebLogic Server管理コンソール・ヘルプの「Java EEライブラリのインストール」を参照してください。
weblogic-application.xmlファイルでcoherence.jarファイルとcoherence-web-spi.warファイルを参照します。このファイルをEARのMETA-INFディレクトリに格納します。
例2-8は、weblogic-application.xmlファイルを示しています。
セッション管理のためにWARスコープ設定クラスタ・ノードでCoherence*Webを使用する手順は次のとおりです。
WebLogic Server管理コンソールまたはコマンドラインを使用して、アプリケーションがデプロイされるすべてのターゲット・サーバーにcoherence-web-spi.warファイルを共有ライブラリとしてデプロイします。Oracle Fusion Middleware Oracle WebLogic Server管理コンソール・ヘルプの「Java EEライブラリのインストール」を参照してください。
coherence.jarファイルをWARファイルのWEB-INF/libディレクトリにコピーします。
coherence-web-spi.warファイルを共有ライブラリとしてデプロイする場合は、例2-9に示す行をWARファイルのWEB-INFディレクトリにあるweblogic.xmlファイルに追加することによって共有ライブラリ参照を作成します。
WebLogic ServerとCoherence*Webでは、セッション・スコープ設定とセッション・ライフサイクルは異なる方法で処理されます。これは、アプリケーションのシングル・サインオン(SSO)方針を実装するための意思決定に影響を与えることがあります。
デフォルトでは、WebLogic Serverは、指定クライアントに対してすべてのWebアプリケーションで同じセッションIDを使用し、セッションCookieパスを「/」に設定します。これは、WebLogic Serverデフォルトthin SSO実装の要件であり、デフォルトで有効に設定されます。「/」のパスを持つセッションCookieを生成することによって、クライアントはサーバーへのすべてのリクエストで同じセッションIDを返すようになります。WebLogic Serverでは、1つのセッションIDを複数のセッション・オブジェクトにマップできます。セッションIDが同一であっても(セッション共有が有効になっていないかぎり)、各Webアプリケーションは異なるセッション・オブジェクト・インスタンスを持つことになります。
対照的に、Coherence*Webでは、1つのセッションIDが1つのセッション・インスタンスにマップされます。したがって、アプリケーションでCoherence*Webが使用される場合、複数のセッション・インスタンスを同じIDにマップする動作は、デフォルトではレプリケートされません。セッションCookieはデフォルトでは「/」にマッブされるため、1つのCoherence*WebセッションがすべてのWebアプリケーションにわたって共有されます。Coherence*Webにおけるデフォルト構成では、すべてのセッション属性が1つのWebアプリケーションにスコープ設定されます。多くの場合、この単一セッションの方法は透過的です。すべてのWebアプリケーションにわたって1つのセッションを保持することの大きな相違はセッション無効化の影響です。Coherence*Webが有効になっているが、1つのWebアプリケーションでセッションを無効化した場合、そのセッション・インスタンスを使用するすべてのWebアプリケーションでそのセッションが無効化されます。Webアプリケーションでthin SSOが使用されていない場合、セッションCookieをWebアプリケーション・パスにスコープ設定することでこの問題を回避できます。
したがって、SSOに関しては次のオプションがあります。
WebLogicのセッション互換モードを有効にします。この構成は、coherence-session-weblogic-compatibility-modeパラメータで設定し、メモリー(単一サーバー、非レプリケート)、ファイル・システム持続性、JDBC持続性、Cookieベースのセッション持続性およびインメモリー・レプリケーション(クラスタ全体)といったすべてのネイティブWebLogic Serverセッション持続タイプをミラー化します。デフォルトでは、このモードが有効になります。詳細は、『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』に関するドキュメントでセッションとセッション持続性の使用に関する項を参照してください。
thin SSO機能を有効にします。クライアントは、すべてのWebアプリケーションにわたって単一セッションを使用します。したがって、セッション・ライフサイクルは、他のすべてのセッション持続タイプと一貫性がないものになります。
セッションCookieパスのスコープをWebアプリケーション・コンテキスト・パスに設定することによってthin SSO機能を無効化します。これにより、セッション・ライフサイクルは、他のすべてのセッション持続タイプと一貫したものになります。
Coherence*Webでthin SSOを有効化する利点は、Coherence*Webに対して同じCoherenceクラスタを使用するすべてのWebアプリケーションにわたって機能することです。CoherenceクラスタはWebLogic Serverクラスタから完全に独立しています。thin SSO機能は、WebLogic Serverセキュリティ・レイヤーでドメイン間の信頼関係を有効にすると、複数のドメインにわたって機能するようになります。
許可されていないCoherence TCMPクラスタ・メンバーによるHTTPセッション・キャッシュ・サーバーへのアクセスを防止するために、対称型暗号化フィルタまたは非対称型暗号化フィルタを構成できます。CoherenceにはJCAベースの2つの暗号化フィルタが同梱されており、クラスタ通信のプライバシや認証性の保護に使用できます。
対称型フィルタ: 対称型暗号化を使用してクラスタ通信を保護します。暗号化キーは、すべてのクラスタ・メンバーで認識される共有パスワードから生成されます。このフィルタは、小規模なデプロイメント、または共有パスワードの維持および保護が可能な場合に適しています。
PKCS暗号化フィルタ: 公開鍵暗号化(非対称型暗号化)を使用してクラスタ参加プロトコルを保護してから、より高速な対称型暗号化に切り替えてサービス・レベルのデータ転送を行います。対称型暗号化フィルタとは異なり、共有の秘密は永続化されません。対称型暗号化キーがクラスタの上位メンバーによってランダムに生成され、クラスタ参加プロトコルの一部として、認証されたクラスタ・メンバーにセキュアに転送されます。この暗号化フィルタは、共有の秘密を維持できないデプロイメントに適しています。
これらのフィルタの実装の詳細は、『Oracle Coherence開発者ガイド』のネットワーク・フィルタの使用方法に関する項を参照してください。
WebLogic ServerでColdFusionアプリケーションを実行している場合は、次の手順に従ってセッション管理のためにCoherence*Webを有効化してください。
ColdFusionインストーラで、ColdFusionのWARバージョンを作成します。
ColdFusion用にWebLogic Serverを構成するために提供されている手順に従います。
WebLogic Serverへの展開ディレクトリ・デプロイメント用のディレクトリにWARを抽出します。
展開されたColdFusion WARの/WEB-INFディレクトリにweblogic.xmlファイルを作成します。Coherence SPIを<library-ref>として指定します。
<?xml version="1.0"?>
<weblogic-web-app xmlns="http://www.bea.com/ns/weblogic/weblogic-web-app"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.bea.com/ns/weblogic/weblogic-web-app http://www.bea.com/ns/weblogic/weblogic-web-app/1.0/weblogic-web-app.xsd">
<library-ref>
<library-name>coherence-web-spi</library-name>
</library-ref>
</weblogic-web-app>
展開されたアプリケーションのWEB-INF/libディレクトリにcoherence.jarをコピーします。
cfusion.jarをWEB-INF/cfusion/libからWEB-INF/にコピーします。
WebLogic Serverインスタンスを起動します。Coherence*Web SPIをWebLogicにデプロイします。SPIは、Coherenceディストリビューションのcoherence\lib\coherence-web-spi.warにあります。
ColdFusionアプリケーションをWebLogic Serverインスタンスにデプロイします。
J2EEセッション管理を使用するようにColdFusion MXを構成します。
次のURLにあるColdFusion管理ページにアクセスします。
http://<host>:<port>/coldfusion-context-root/CFIDE/administrator.
「Server Sessions」の下にある「Memory Variables」を選択し、「Use J2EE session variables」チェック・ボックスを選択します。
展開したColdFusion WARの下にColdFusionアプリケーションを追加します。
アプリケーションには、sessionmanagement="Yes"と指定したApplication.cfmファイルが必要ですが、ColdFusion構成を使用してセッションを構成しないでください(そのようにしないと例外がスローされます)。Application.cfmには、次の行を含める必要があります。
<cfapplication sessionmanagement="Yes">
