ヘッダーをスキップ
Oracle® Coherence Oracle Coherence*Webユーザーズ・ガイド
リリース3.7.1
B65029-01
  ドキュメント・ライブラリへ移動
ライブラリ
製品リストへ移動
製品
目次へ移動
目次
索引へ移動
索引

前
 
次
 

2 WebLogic ServerでのCoherence*Webの使用方法


注意:

特に明記する場合を除き、この章ではOracle WebLogic Serverの11gリリース1のパッチ・セット3(10.3.4)以降について説明します。

この章では次の項について説明します。

Coherence*Webでは、セッション状態の持続および管理が実現されます。セッション・データの格納および管理にCoherenceキャッシュを使用するのは、セッション管理モジュールです。この章では、WebLogic Server上で実行しているアプリケーションから使用できるようにCoherence*Webを設定およびデプロイする方法について説明します。

Coherence*Webは、WebLogic Serverのメモリー内HTTP状態レプリケーション・サービスにかわるものです。次のいずれかの状況に該当する場合は、Coherence*Webの使用を検討してください。


3.7.1における新規項目:

session-cache-config.xmlファイルは、coherence-web-spi.warファイルからcoherence-web.jarファイルに移動しました。coherence-web.jarファイルは、coherence\libディレクトリにあります。

2.1 Coherence*Web SPIの概要

Coherence*Webサービス・プロバイダ・インタフェース(SPI)は、coherence-web-spi.warファイルで構成されています。coherence-web-spi.warで提供される機能を使用するには、Webアプリケーションに対してcoherence.jarクラスを使用可能にする必要があります。

Coherence*Webでは、次のデフォルト・キャッシュ構成が定義されています。

Coherence*Web SPIで使用されるCoherenceキャッシュ構成とサービスは、session-cache-config.xmlファイルで定義され、coherence-web.jarファイルにあります。session-cache-config.xmlファイルで定義されているデフォルト・キャッシュ構成とサービス構成により、大半のWebアプリケーションを実現します。

Coherence*Webには、セッションの同時アクセスを制御するためのセッション・ロック・モードがいくつかあります。Coherence*WebとCoherence*Web SPIの両方に、最後の書込みを優先するロックがデフォルトで採用されています。ロック・モードの詳細は、「セッション・ロック・モード」を参照してください。

Coherence*Web SPIは、単独ではロード・バランサをWebLogic Server層の前で実行する必要はありません。ただし、ロード・バランサによりパフォーマンスが向上します。同じセッションが同時に使用されロックが有効でない場合に必要です。デフォルトのロード・バランサでは、HTTPセッションのJVMアフィニティを適用しますが、他のロード・バランシング方法も使用できます。WebLogic Serverには、JVMセッションの持続性を維持するための様々なプロキシ・プラグインが付属しています。WebLogic Serverプロキシ・プラグインの構成に関するドキュメントは次のURLから入手できます。

http://download.oracle.com/docs/cd/E17904_01/web.1111/e13709/load_balancing.htm

2.2 Coherence*Webの構成とデプロイ: 主な手順

Coherence*Webにはデプロイ可能な共有ライブラリが付属しています。そのライブラリには、WebLogic ServerのHTTPセッション管理インタフェースへのネイティブ・プラグインが含まれます。次の手順は、WebLogic Server上で実行しているアプリケーションでCoherence*Webを使用するためにデプロイメントを準備する方法を示しています。

  1. Oracle Coherenceをファイル・システムにダウンロードします。「Oracle Coherenceのダウンロード」を参照してください。

  2. アプリケーションがCoherence*Web用に高度な構成を必要とする場合は、WARデプロイメントのweb.xmlファイルを変更します。Webアプリケーションに対して構成可能なパラメータについては、「Coherence*Webの構成」で説明します。すべてのCoherence*Webパラメータの詳細は、付録A「Coherence*Webコンテキスト・パラメータ」を参照してください。

  3. (オプション)WebLogicによって生成されるHTTPセッションCookieパラメータをweblogic.xmlまたはweblogic-application.xmlのファイルで構成します。「セッションCookieの構成」を参照してください。

  4. (テストの場合はオプション、本番の場合は強く推奨)WebLogic Serverを実行しているJVMとは別のJVMでキャッシュ・サーバー層を起動します。「キャッシュ・サーバーの起動」を参照してください。

  5. デプロイメント要件に基づいて適切なパッケージ化を決定し、そのパッケージ化手順に従います。WebLogic Serverのバージョンに応じて、「クラスタ・ノードの構成」を参照してください。

2.2.1 Oracle Coherenceのダウンロード

Coherence*Webで必要なすべてのファイルは、coherence-web-spi.warファイルを含めて、Coherenceディストリビューションに付属しています。

デフォルトでは、WebLogic Server 10.3.4とともにCoherence 3.6がインストールされますCoherenceディレクトリのデフォルトの場所は、C:\Oracle\Middleware\coherence_3.6です。WebLogic Server 10.3.4を使用している場合、Coherence 3.7をファイル・システムにダウンロードしてから保存できます。coherence-web-spi.warcoherence.jarなど、Coherence 3.7ディストリビューションにあるライブラリ・ファイルをアプリケーションで必ず参照してください。

同様に、WebLogic Server 10.3.3で作業する場合、Coherenceがcoherence_3.5ディレクトリにインストールされている場合があります。再び、Coherence 3.7をファイル・システムにダウンロードしてから保存できます。coherence-web-spi.warcoherence.jarなど、Coherence 3.7ディストリビューションにあるライブラリ・ファイルをアプリケーションで必ず参照してください。

WebLogic Server 10.3.2以前を使用している場合は、Coherenceディストリビューションをファイル・システムにダウンロードしてください。

必要なソフトウェア・パッチの適用

CoherenceとCoherence*Webで作業する前に、一部の旧リリースのWebLogic Serverではソフトウェア・パッチの適用が必要です。表2-1に、各種バージョンのWebLogic Serverとそれらの関連パッチを示します。

表2-1 WebLogic Serverの必要なソフトウェア・パッチ


WebLogic Server 9.2 MP1 WebLogic Server 9.2 MP3 WebLogic Server 10.3 WebLogic Server 11g(10.3.1以上)

WebLogic Smart Update

パッチID: 616G

パッチID: LP7B

パッチID: 6W2W

パッチは不要


Smart UpdateユーティリティをWebLogic Server管理コンソールで使用するか、My Oracle Supportにアクセスすると、パッチを入手できます。

Smart Updateを使用するには、WebLogic Server管理コンソールで指示を参照してください。本番環境では、Smart Updateの本番インストールに関する注意を確認してください。

My Oracle Supportを使用するには、My Oracle Support Webサイトに移動します。

https://support.oracle.com/

パッチ」タブを選択してから、「単純検索」リンクをクリックし、後続の画面で適切な値(「11399293」など)のパッチ番号か名前を検索します。表示された検索結果からパッチのzipファイルをダウンロードします。Coherenceパッチを適用する手順は、パッチのzipファイルに含まれるREADME.txtに記載されています。

2.2.2 Coherence*Webの構成

Coherence*Web SPIにより、大半のWebアプリケーションに対応するデフォルト構成を実現します。表2-2に、Coherence*Webコンテキスト・パラメータの中でSPIバージョン用のデフォルトがSPI以外のバージョンとは異なるもののみを示します。表2-3は、SPIで渡された互換モード・コンテキスト・パラメータを示しています。すべてのCoherence*Webパラメータの詳細は、付録A「Coherence*Webコンテキスト・パラメータ」を参照してください。

コンテキスト・パラメータは、システム・プロパティとしてコマンドラインで構成することもできます。システム・プロパティは、コンテキスト・パラメータと同じ名前を持ちますが、ダッシュ(-)がピリオド(.)に置き換えられています。たとえば、coherence-enable-sessioncontextコンテキスト・パラメータの値をコマンドラインで宣言するには、次のように入力します。

-Dcoherence.enable.sessioncontext=true

システム・プロパティと、同等のコンテキスト・パラメータの両方が構成されている場合、システム・プロパティの値が使用されます。

表2-2 SPIによって構成されるCoherence*Webコンテキスト・パラメータ

パラメータ名 説明

coherence-application-name

Coherence*Webではこのパラメータの値を使用して、ApplicationScopeControllerインタフェースを使用して属性のスコープを設定するアプリケーションの名前を判別します。このパラメータの値は、次の形式で指定する必要があります。

アプリケーション名 + ! + Webモジュール名

application nameApplicationScopeControllerインタフェースを使用するアプリケーションの名前であり、Web module nameはそれが記述されているWebモジュールの名前です。

たとえば、test.earというEARファイルと、このEARファイル内で定義されたapp1というWebモジュールがある場合、coherence-application-nameパラメータのデフォルト値はtest!app1となります。

このパラメータが構成されていない場合、Coherence*Webでは、かわりにクラス・ローダーの名前が使用されます。また、このパラメータが構成されておらず、ApplicationScopeControllerインタフェースが構成されている場合、アプリケーション名が構成されていなかったことを示す警告が記録されます。詳細は、「セッション属性スコープ設定」を参照してください。

coherence-reaperdaemon-assume-locality

この設定により、セッション・リーパーでは、(たとえば、分散キャッシュ・サービスによって)このノードに保存されるセッションは、このノードで期限切れのチェックが必要なセッションのみであると仮定できます。

デフォルトは、falseです。

coherence-scopecontroller-class

この値は、オプションのcom.tangosol.coherence.servlet.HttpSessionCollection$AttributeScopeControllerインタフェース実装のクラス名を指定します。

有効な値は次のとおりです。

  • com.tangosol.coherence.servlet.AbstractHttpSessionCollection$ApplicationScopeController(デフォルト)

  • com.tangosol.coherence.servlet.AbstractHttpSessionCollection$GlobalScopeController

Coherence*Web SPIで設定するデフォルトはcom.tangosol.coherence.servlet.AbstractHttpSessionCollection$ApplicationScopeControllerです。


表2-3は、Coherence*Web SPIで具体的に渡されたcoherence-session-weblogic-compatibility-modeコンテキスト・パラメータを示しています。

表2-3 Coherence*Web SPIによって渡されるコンテキスト・パラメータ

パラメータ名 説明

coherence-session-weblogic-compatibility-mode

このパラメータは、Coherence*WebのSPIバージョンによって渡されます。この値をtrueに設定した場合、各Webアプリケーションで、単一のセッションID(Cookieのパスを「/」に設定)が、固有のCoherence*Webセッション・インスタンスにマップされます。falseに設定した場合は、標準の動作が適用されます。つまり、単一のセッションIDが、WebLogic ServerのCoherence*Web SPIを使用して単一のセッション・インスタンスにマップされます。WebLogicにおけるその他のすべてのセッション持続メカニズムでは、各Webアプリケーションで単一のセッションIDを使用して、様々なセッション・インスタンスを参照します。

グローバル・スコープ・コントローラが指定されていないかぎり、このパラメータではデフォルトでtrueに設定されます。コントローラが指定されていると、パラメータのデフォルト値はfalseになります。


表2-4は、coherence-factory-classコンテキスト・パラメータを示しています。デフォルト値はCoherence*Web SPIで設定されますが、変更しないでください。

表2-4 変更してはいけないコンテキスト・パラメータ値

パラメータ名 説明

coherence-factory-class

SessionHelper.Factoryファクトリ・クラスを実装するクラスの完全修飾クラス名。Coherence*Web SPIにより、デフォルト値はweblogic.servlet.internal.session.WebLogicSPIFactoryに設定されます。この値は変更しないでください。


2.2.3 セッションCookieの構成

Coherence*Web SPIを使用すると、WebLogic ServerによってセッションCookieが生成および解析されます。この場合、ネイティブCoherence*WebセッションCookie構成パラメータはすべて無視されます。セッションCookieを構成するには、WebLogicによって生成されるHTTPセッションCookieパラメータをweblogic.xmlまたはweblogic-application.xmlのファイルで使用します。これらのパラメータについては、表2-5を参照してください。

この表で「更新可能?」は、サーバー実行中にパラメータ値が変更可能かどうかを示します。「該当なし」は、対応するCoherenceセッションCookieパラメータがないことを示します。

表2-5 WebLogicによって生成されるHTTPセッションのCookieパラメータ

セッションCookieパラメータ 置き換えられるCoherence*Web Cookieパラメータ 説明

cookie-comment

該当なし

Cookieファイルにあるセッション追跡Cookieを特定するコメントを指定します。

デフォルトはnullです。

更新可能?はい

cookie-domain

coherence-session-cookie-domain

Cookieを有効にするドメインを指定します。たとえば、cookie-domain.mydomain.comに設定した場合は、*.mydomain.comドメインにあるすべてのサーバーにCookieが返されます。

このドメイン名では2つ以上の要素を指定する必要があります。*.com*.netと指定した名前は無効です。

値を設定しない場合は、Cookieを発行したサーバーにデフォルトで設定されます。

詳細は、サーブレット仕様で「Cookie.setDomain()」を参照してください。

デフォルトはnullです。

更新可能?はい

cookie-max-age-secs

coherence-session-max-age

セッションCookieの存続期間(秒)を設定します。この時間が経過したクライアントではセッションCookieが期限切れになります。Cookieの詳細は、『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』でセッションとセッション持続性の使用方法に関する項を参照してください。

デフォルト値は-1(無制限)です。

更新可能?はい

cookie-name

coherence-session-cookie-name

セッション・トラッキングのCookie名を定義します。設定しない場合は、デフォルトでJSESSIONIDに設定されます。これは、アプリケーションに固有の名前に設定できます。

デフォルトはJSESSIONIDです。

更新可能?はい

cookie-path

coherence-session-cookie-path

セッション・トラッキングのCookieパスを定義します。

値を指定しない場合は、デフォルトで「/」(スラッシュ)に設定され、WebLogic Serverで指定するすべてのURLにブラウザからCookieが送信されます。このパスによる対応範囲を狭くすることで、ブラウザからのCookie送信先となるリクエストURLを制限できます。

デフォルトはnullです。

更新可能?はい

cookie-secure

coherence-session-cookie-secure

HTTPS接続経由でのみCookieを返すことができることをブラウザに指示します。これによって、Cookie IDが保護されます。この設定は、HTTPSを使用するWebサイトでのみ使用してください。この機能が有効な場合、HTTP経由で送信されるセッションCookieは機能しません。

この機能を使用する場合は、url-rewriting-enabled要素を無効にしてください。

WebLogic ServerによってセッションCookieが生成されます。

デフォルトは、falseです。

更新可能?はい

cookies-enabled

coherence-session-cookies-enabled

セッションCookieの使用がデフォルトで有効になり、これをお薦めしますが、このプロパティをfalseに設定してCookieを無効にすることもできます。テスト時はこのオプションを無効にしてもかまいません。

デフォルトはtrueです。

更新可能?はい

debug-enabled

該当なし

HTTPセッションに対するデバッグ機能を有効にします。これは、HttpSessionDebugロギングおよびWebLogic Serverトレース・ログ出力を有効にすることによってサポートされます。

デフォルト値は、falseです。

更新可能?はい

encode-session-id-in-query-params

該当なし

最新のサーブレット仕様でパス・パラメータのセッションIDをコンテナでエンコードする必要がある場合、trueに設定します。Webサーバーの中には、パス・パラメータを適切に処理しないものがあります。そのような場合は、encode-session-id-in-query-params要素をtrueに設定する必要があります。

WebLogic ServerによってHTTPレスポンスが生成されます。

デフォルト値は、falseです。

更新可能?はい

http-proxy-caching-of-cookies

該当なし

falseに設定すると、プロキシ・キャッシュにCookieがキャッシュされていないことを示す「Cache-control: no-cache=set-cookie」というヘッダーおよびレスポンスがWebLogic Serverによって追加されます。

WebLogic ServerによってHTTPレスポンスが生成されます。

デフォルト値はtrueです。

更新可能?はい

id-length

coherence-session-id-length

セッションIDのサイズを設定します。

最小値は8バイト、最大値はInteger.MAX_VALUEです。

Wireless Application Protocol(WAP)アプリケーションを作成している場合、WAPプロトコルではCookieがサポートされないので、URLリライティングを使用する必要があります。また、WAPデバイスの中にはURL長を128文字(属性を含む)に制限しているものがあり、その場合はURLリライティングを使用して送信できるデータの量に制限があります。属性に使用できる領域を増やすには、この属性を使用して、WebLogic Serverでランダムに生成されるセッションIDのサイズを制限します。

WAPEnabled属性を設定することで、長さを52文字固定に制限し、特殊文字の使用を禁止することもできます。詳細は、WebLogic Server用のWebアプリケーションの開発時に「URLリライティングとワイヤレス・アクセス・プロトコル」を参照してください。

デフォルトは52です。

更新可能?いいえ

invalidation-interval-secs

該当なし

タイムアウトしたセッションおよび無効なセッションに対してチェックを実行してから古いセッションを削除してメモリーを解放するまで、Coherence*Webが待機する時間(秒単位)を設定します。この要素を使用して、トラフィックが多いサイトで最適なパフォーマンスが得られるようにWebLogic Serverを調整します。

デフォルトは60です。

更新可能?いいえ

timeout-secs

該当なし

セッションをタイムアウトするまでCoherence*Webが待機する時間(秒単位)を設定します。

アクセスが多いサイトでは、セッションのタイムアウトを適切に設定することによってアプリケーションを調整できます。ブラウザ・クライアントにセッションを終了する機会を提供するとともに、ユーザーがサイトを離れたりその他の方法でセッションを破棄した場合に、サーバーを不要に拘束しないようにします。

この要素は、web.xmlsession-timeout要素(分単位で定義)によってオーバーライドできます。

デフォルトは3600秒です。

更新可能?いいえ

tracking-enabled

該当なし

HTTPリクエスト間のセッション・トラッキングを有効にします。

WebLogic ServerによってHTTPレスポンスが生成されます。

デフォルトはtrueです。

更新可能?いいえ

url-rewriting-enabled

coherence-session-urlencode-enabled

URLリライティングを有効化します。これにより、ブラウザでCookieが無効化されている場合にセッションIDがURLにエンコードされてセッション・トラッキングが提供されます。URLを書き込むときにはencodeURLまたはencodeRedirectedURLのメソッドが使用されます。詳細は、次を参照してください。

http://www.jguru.com/faq/view.jsp?EID=1045

WebLogic ServerによってHTTPレスポンスが生成されます。

デフォルトはtrueです。

更新可能?はい


2.2.4 キャッシュ・サーバーの起動

Coherenceキャッシュ・サーバー(データ・ノードとも呼ぶ)は、キャッシュされるデータすべての格納と管理を担います。これは、専用のJVMであっても、WebLogic Serverインスタンス内で実行されてもかまいません。Coherenceデータ・クラスタ内の上位ノード(最初のノード)は起動に数秒間かかることがあります。下位のノードで必要な起動時間はわずかです。

最初にキャッシュ・サーバーを起動するのか、WebLogic Serverインスタンスを起動するのかは、採用しているサーバー・トポロジによります。

  • インプロセス・トポロジ(すべて記憶域を有効化したWebLogic Serverインスタンス)を使用している場合、最初にキャッシュ・サーバーを起動しても、WebLogic Serverインスタンスを起動してもかまいません。

  • アウトオブプロセス・トポロジ(記憶域を無効化したWebLogic ServerインスタンスとスタンドアロンCoherenceキャッシュ・サーバー)を使用している場合は、最初にキャッシュ・サーバーを起動し、次にWebLogic Serverインスタンスを起動します。これにより、Coherenceを使用するアプリケーションの起動時間が最短(ミリ秒単位)になります。Coherenceを使用する追加Webアプリケーションはどれも上位データ・メンバーにならず、そのため、それらがWebLogic Serverの起動に与える影響は最小限になります。

    このトポロジでキャッシュ・サーバーを最初に起動しないと、Coherenceでは次のようなエラー・メッセージにより応答します。

    No storage-enabled nodes exist for service ... 
    

2.2.4.1 スタンドアロンCoherenceデータ・ノードの起動方法

スタンドアロンCoherenceデータ・ノードを起動するには、次の手順を実行します。

  1. Coherenceデータ・ノードを起動するためのスクリプトを作成します。記憶域を有効化したキャッシュ・サーバーを起動するスクリプトの簡単な例を次に示します。この例では、Sun JVMの使用を前提としています。詳細は、『Oracle Coherence開発者ガイド』の「JVMのチューニング」を参照してください。

    java -server -Xms512m -Xmx512m 
    -cp <Coherence installation dir>/lib/coherence-web.jar:<Coherence installation dir>/lib/coherence.jar -Dtangosol.coherence.management.remote=true 
    -Dtangosol.coherence.cacheconfig=cache_configuration_file 
    -Dtangosol.coherence.session.localstorage=true com.tangosol.net.DefaultCacheServer
    

    クラスパスのcoherence-web.jarcoherence.jarを含める必要があります。cache_configuration_fileは、ファイル・システムにおけるキャッシュ構成ファイルへの絶対パスを示します。Coherence*Webの場合、これはsession-cache-config.xmlファイルになります。キャッシュ・サーバーに対して定義されているキャッシュ構成は、同じCoherenceクラスタで実行されているアプリケーション・サーバーに対して定義されているキャッシュ構成と一致する必要があります。

    さらに別なCoherenceキャッシュがCoherence*Webで実行している場合、session-cache-config.xmlファイルに格納されているセッション構成とキャッシュ構成情報(一般的にcoherence-cache-config.xmlファイルで定義)をマージする必要があります。キャッシュ構成とセッション構成は、WebLogic ServerとCoherenceキャッシュ・サーバーとの間で一貫している必要があります。

    これらのファイルをマージする方法の詳細は、『Oracle Coherence統合ガイド』でCoherenceキャッシュとセッション情報のマージに関する項を参照してください。

  2. 前述の手順で説明したスクリプトを使用して、Coherenceデータ・ノードを1つ以上起動します。

2.2.4.2 記憶域を有効化したWebLogic Serverインスタンスまたは記憶域を無効化したWebLogic Serverインスタンスの起動方法

デフォルトでは、Coherence*Webを使用可能なWebLogic Serverインスタンスは、記憶域を無効化した状態で起動します。記憶域を有効化した状態でWebLogic Serverインスタンスを起動する手順は次のとおりです。

  1. Coherenceデータ・ノードを起動するためのスクリプトを作成します。これは、前項で説明されているスクリプトと同様にできます。

  2. -Dtangosol.coherence.session.localstorage=trueのコマンドライン・プロパティをサーバー起動コマンドに含め、ローカル記憶域を有効にします

コマンドラインからのWebLogic Serverの操作の詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverコマンド・リファレンス』のweblogic.Serverコマンドライン・リファレンスに関する項を参照してください。

2.2.5 クラスタ・ノードの構成

Coherence*Webで行うセッション管理は、アプリケーション・サーバー・スコープEARスコープまたはWARスコープを設定できます。Coherenceクラスタと同様、Coherence*Webのスコープ設定は、クラスローダーの階層におけるcoherence.jarファイルの位置により異なります。各スコープの詳細は、「クラスタ・ノード分離」を参照してください。

WebLogic Serverリリース10.3.3以降では、ActiveCacheと呼ばれる機能が用意されています。これによって、アプリケーションとCoherenceキャッシュとの間の対話が容易にできます。これらの機能の詳細は、ActiveCacheの使用方法ガイドを参照してください。

一部の旧リリースのWebLogic Server(リリース10.3.1以前など)では、CoherenceとCoherence*Webを使用するには、ソフトウェア・パッチが必要です。ご使用のリリースのWebLogic Serverでパッチが必要かどうかを調べるには、「必要なソフトウェア・パッチの適用」を参照してください。

次の各項では、Coherence*Webを実行するための様々なクラスタ・ノードの構成方法を説明します。


注意:

アプリケーション・サーバー・スコープ設定クラスタ構成の使用は、慎重に検討する必要があります。アプリケーション間の相互作用が未知または予測不能な環境では使用しないでください。

このような環境の例として、規則や命名基準の調整や実施が不十分な状態で互いに無関係に作成したアプリケーションを、複数のアプリケーション・チームでデプロイしている状況が考えられます。このような構成では、すべてのアプリケーションが同じクラスタに属することから、キャッシュやサービスなどの他の構成設定と名前空間どうしで競合が発生する可能性がきわめて高く、予期しない結果を生じる恐れがあります。

このような理由から、EARスコープ設定クラスタ・ノードによる構成およびWARスコープ設定クラスタ・ノードによる構成の使用を強くお薦めします。どのデプロイメント・トポロジを選択すればよいか不明な場合や、この警告にご自身のデプロイメントが該当している場合は、アプリケーション・サーバー・スコープ設定クラスタ・ノードによる構成は選択しないでください


2.2.5.1 アプリケーション・サーバー・スコープ設定クラスタ・ノードの構成

セッション管理のためにCoherenceクラスタにCoherence*Webを追加する場合は、次の手順に従ってください。

  1. coherence.jarファイルを含めるようにWebLogic Serverのシステム・クラスパスを編集するか、JARファイルを$DOMAIN_HOME/libディレクトリにコピーします。

  2. WebLogic Server管理コンソールまたはコマンドラインを使用して、coherence-web-spi.warファイルを共有ライブラリとしてデプロイします。

  3. WebアプリケーションでCoherence*Webを有効にします。

    Coherence*Webを使用する予定のWebLogic Serverにデプロイした各WARファイルのweblogic.xmlに、例2-1に示すライブラリ参照コードを追加します。

    例2-1 WARファイルのライブラリ参照

    <weblogic-web-app>
      ...
        <library-ref>
          <library-name>coherence-web-spi</library-name>
        </library-ref>
      ...
    </weblogic-web-app>
    

2.2.5.2 EARスコープ設定クラスタ・ノードの構成

EARスコープ設定クラスタ・ノードでセッション管理のためにCoherence*Webを使用する際、アプリケーションをWebLogic Server 10.3.2以前で実行する場合、次の手順に従ってください。

  1. WebLogic Server管理コンソールまたはコマンドラインを使用して、アプリケーションがデプロイされるすべてのターゲット・サーバーにcoherence.jarファイルおよびcoherence-web-spi.warファイルを共有ライブラリとしてデプロイします。詳細は、Oracle Fusion Middleware Oracle WebLogic Server管理コンソール・ヘルプの「Java EEライブラリのインストール」を参照してください。

    coherence.jarをWebLogic Server管理コンソールでデプロイする際にエラーが発生した場合、WLSTコマンドを使用できます。詳細は、Oracle Fusion Middleware Oracle WebLogic Server管理コンソール・オンライン・ヘルプを参照してください。

  2. weblogic-application.xmlファイルでcoherence.jarファイルを参照します。このファイルをEARのMETA-INFディレクトリに格納します。

    例2-2は、weblogic-application.xmlファイルを示しています。

    例2-2 weblogic-application.xmlで参照されるCoherence JAR

    <weblogic-application ...>
    ...
          <library-ref>
               <library-name>coherence</library-name>
          </library-ref>
    ...
    </weblogic-application>
    
  3. weblogic.xmlファイルでcoherence-web-spi.warファイルを参照します。

    例2-3は、weblogic.xmlファイルを示しています。

    例2-3 weblogic.xmlで参照されるCoherence Web SPI WAR

    <weblogic-web-app>
    ...
          <library-ref>
               <library-name>coherence-web-spi</library-name>
         </library-ref>
    ...
    </weblogic-web-app>
    

2.2.5.3 WARスコープ設定クラスタ・ノードの構成

セッション管理のためにWARスコープ設定クラスタ・ノードでCoherence*Webを使用する場合は、次の手順に従ってください。

  1. WebLogic Server管理コンソールまたはコマンドラインを使用して、アプリケーションがデプロイされるすべてのターゲット・サーバーにcoherence-web-spi.warファイルを共有ライブラリとしてデプロイします。Oracle Fusion Middleware Oracle WebLogic Server管理コンソール・ヘルプの「Java EEライブラリのインストール」を参照してください。

  2. coherence.jarファイルをアプリケーションに追加します。次のいずれかの方法でこれをできます。

    • Coherenceを使用する各モジュールのmanifest.mfファイルでオプション・パッケージとしてcoherence.jarファイルをインポートします。例2-4は、manifest.mfファイルを示しています。

      表 2-4 Coherence JARファイルを参照するマニフェスト・ファイル

      Manifest-Version: 1.0
      Extension-List: coherence
      coherence-Extension-Name: coherence
      
    • coherence.jarファイルをWARファイルのWEB-INF/libディレクトリにコピーします。

  3. coherence-web-spi.warファイルを共有ライブラリとしてデプロイする場合、例2-5に示す行をWARファイルのWEB-INFディレクトリにあるweblogic.xmlファイルに追加することによって、共有ライブラリ参照を作成することも必要です。

    例2-5 Webアプリケーションのライブラリ参照

    <weblogic-web-app ... >
         ...
          <library-ref>
               <library-name>coherence-web-spi</library-name>
         </library-ref>
         ...
    <weblogic-web-app>
    

2.3 セッションCookieパスのスコープ設定

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に関しては次のオプションがあります。

Coherence*Webでthin SSOを有効化する利点は、Coherence*Webに対して同じCoherenceクラスタを使用するすべてのWebアプリケーションにわたって機能することです。CoherenceクラスタはWebLogic Serverクラスタから完全に独立しています。thin SSO機能は、WebLogic Serverセキュリティ・レイヤーでドメイン間の信頼関係を有効にすると、複数のドメインにわたって機能するようになります。

2.4 その他のアプリケーション・サーバーとのCoherence*Webセッションの共有

1つのクラスタ内でCoherence*WebをWebLogic Serverとその他のアプリケーション・サーバーで実行している場合、WebLogic Serverで作成したセッションCookieは、他のサーバー上のCoherence*Webでは正しくデコードされません。これは、WebLogic Serverによって、Coherence*Webに格納されているセッションIDには含まれていないセッション・アフィニティ接尾辞が追加されるためです。Coherence*WebでセッションをCoherenceキャッシュから取得できるようにするには、他のアプリケーション・サーバーでは、WebLogicセッション・アフィニティ接尾辞をセッションCookie値から削除する必要があります。

WebLogicセッション・アフィニティ接尾辞をセッションCookie値から削除するには、他のアプリケーション・サーバーで使用されているweb.xmlファイルでcoherence-session-affinity-tokenコンテキスト・パラメータを追加します。例2-6に示すように、パラメータ値を感嘆符(!)に設定します。他のアプリケーション・サーバーによって処理される際、セッション・アフィニティ接尾辞がセッションCookieから削除されます。

表2-6 セッション・アフィニティ接尾辞の削除

...
<context-param>
  <param-name>coherence-session-affinity-token</param-name>
  <param-value>!</param-value>
</context-param>
...

coherence-session-affinity-tokenコンテキスト・パラメータの詳細は、付録A「Coherence*Webコンテキスト・パラメータ」を参照してください。