この章では、Coherenceをスタンドアロン・アプリケーションとしてデプロイする手順と、Java EEアプリケーションとしてデプロイする手順について説明します。WebLogic Serverに固有の手順についても説明しています。
この章には次の項が含まれます:
スタンドアロンCoherenceアプリケーションは、異なるロールを実行する分散プロセスから構成されます。デプロイメントの場合、これらのプロセスをそのロールに基づいた層に論理的にグループ化すると有益な場合がありますが、これはデプロイメントの要件ではありません。最も一般的な層は、データ層、アプリケーション層、プロキシ層およびExtendクライアント層です。層により、共通のアーティファクト、パッケージ化およびスクリプトを定義して各層用に設定できるためデプロイメントが容易になります。
この項の内容は次のとおりです。
データ層はキャッシュ・オブジェクトを格納するキャッシュ・サーバーから構成されます。Coherenceアプリケーションでは、データ層に任意の数のキャッシュ・サーバーが必要な場合があります。キャッシュ・サーバーの数は、キャッシュに予想されるデータの量と、そのデータをバックアップしてサーバー障害後も存続させる必要があるかどうかに依存します。各キャッシュ・サーバーがCoherenceクラスタ・メンバーで独自のJVMプロセスで稼働し、複数のキャッシュ・サーバーを1つの物理サーバー上で連結できます。アプリケーション用キャッシュ・サーバーの数の計画の詳細は、「キャッシュ・サイズ計算の推奨事項」および「ハードウェアの推奨事項」を参照してください。
キャッシュ・サーバーは、通常、com.tangosol.net.DefaultCacheServer
クラスを使用して起動されます。このクラスにはmain
メソッドが含まれ、コマンド行から起動されます。キャッシュ・サーバーの起動の詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。
次のアプリケーション・アーティファクトは、キャッシュ・サーバーでデプロイされることがあります。
オペレーション・オーバーライド構成ファイル、キャッシュ構成ファイルおよびPOFユーザー・タイプ構成ファイルなどの構成ファイル。
POFシリアライザおよびドメイン・オブジェクト
問合せ、エントリ・プロセッサ、エントリ・アグリゲータなどのデータ・グリッド処理実装。
イベント処理実装。
データ・ソースからオブジェクトをキャッシュする際のキャッシュ・ストアおよびローダー実装。
アプリケーション・アーティファクトをデータ層にパッケージ化する方法に制限はありません。ただし、アーティファクトはサーバーのクラスパスにあり、すべての構成ファイルがcoherence.jar
ライブラリの前にある必要があります(デフォルトの名前を使用している場合)。それ以外の場合、coherence.jar
ライブラリにあるデフォルトの構成ファイルがロードされます。次の例では、単一のキャッシュ・サーバーがAPPLICATION_HOME
\config
ディレクトリにある構成ファイルを使用して起動し、APPLICATION_HOME
\lib\myClasses
ライブラリにある実装クラスを使用します。
java -server -Xms4g -Xmx4g -cp APPLICATION_HOME
\config;APPLICATION_HOME\lib\myClasses.jar;COHERENCE_HOME\lib\coherence.jar com.tangosol.net.DefaultCacheServer
(オペレーション・オーバーライド・ファイルを変更せずに)構成オーバーライドをシステム・プロパティとして含める場合、java
コマンドに対して-D
引数として含めることができます。便利な方法としてCOHERENCE_HOME
\bin\cache-server
スクリプトを再利用して適宜変更できます。
GARデプロイメント
Coherenceアプリケーション・アーティファクトは、グリッド・アーカイブ(GAR)としてパッケージ化してDefaultCacheServer
クラスでデプロイできます。GARは特定のディレクトリ構造に準拠し、アプリケーション・ディスクリプタを含みます。GARパッケージ化の詳細は、「Coherence GARモジュールの構築」を参照してください。手順はWebLogicサーバー・デプロイメントの一部として含まれていますが、DefaultCacheServer
クラスでデプロイ中のGARにも適用できます。
次の例では、キャッシュ・サーバーを起動してMyGar.gar
ファイルにパッケージ化されているアプリケーション・アーティファクトを使用します。デフォルト名(MyGAR
)はアプリケーション名として使用され、クラスタ上のアプリケーションの有効範囲を提供します。
java -server -Xms4g -Xmx4g -cp APPLICATION_HOME
\config;COHERENCE_HOME\lib\coherence.jar com.tangosol.net.DefaultCacheServer D:\example\MyGAR.gar
デフォルト名は引数として別の名前を指定することでオーバーライドできます。有効なDefaultCacheServer
引数の詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。アプリケーション・スコープの詳細は、「単一クラスタでの複数のアプリケーションの実行」を参照してください。
アプリケーション層は、キャッシュ操作を実行する任意の数のクライアントから構成されます。キャッシュ操作には、キャッシュへのオブジェクトのロード、キャッシュされたオブジェクトの使用、キャッシュされたデータの処理およびキャッシュ保守の実行などがあります。クライアントはCoherenceクラスタ・メンバーですが、データの格納は行いません。
次のアプリケーション・アーティファクトは、クライアントとともにデプロイされることがあります。
オペレーション・オーバーライド構成ファイル、キャッシュ構成ファイルおよびPOFユーザー・タイプ構成ファイルなどの構成ファイル。
POFシリアライザおよびドメイン・オブジェクト
問合せ、エントリ・プロセッサ、エントリ・アグリゲータなどのデータ・グリッド処理実装。
イベント処理実装。
データ・ソースからオブジェクトをキャッシュする際のキャッシュ・ストアおよびローダー実装。
アプリケーション・アーティファクトをアプリケーション層にパッケージ化する方法に制限はありません。クライアントでは、そのアプリケーションのクラスパスにCOHERENCE_HOME
/lib/coherence.jar
ライブラリを含める必要があります。Coherence構成ファイルは、クラスパスに含まれcoherence.jar
ライブラリの前にある必要があります(デフォルトの名前を使用している場合)。それ以外の場合、coherence.jar
ライブラリにあるデフォルトの構成ファイルがロードされます。次の例では、クライアントがAPPLICATION_HOME
\config
ディレクトリにある構成ファイルを使用して起動し、APPLICATION_HOME
\lib\myClasses
ライブラリにある実装クラスを使用します。
java -cp APPLICATION_HOME\config;APPLICATION_HOME\lib\myClasses.jar;COHERENCE_HOME\lib\coherence.jar com.MyApp
(オペレーション・オーバーライド・ファイルを変更せずに)システム・プロパティの構成オーバーライドを含める場合、java
コマンドに対して-D
引数として含めることができます。たとえば、クライアントへの格納を無効にするには、tangosol.coherence.distributed.localstorage
システム・プロパティを次のように使用できます。
java -Dtangosol.coherence.distributed.localstorage=false -cp APPLICATION_HOME\config;APPLICATION_HOME\lib\myClasses.jar;COHERENCE_HOME\lib\coherence.jar com.MyApp
注意: キャッシュ・サーバーへのデプロイメントにGARが使用されている場合、キャッシュ・サービスはアプリケーション・スコープ名によって制限されます。クライアントは同じアプリケーション・スコープ名を使用する必要があります。それ以外の場合、クライアントはキャッシュ・サービスにアクセスできません。アプリケーション・スコープの指定の詳細は、「単一クラスタでの複数のアプリケーションの実行」を参照してください。 |
プロキシ層はExtendクライアントのリクエストを処理するプロキシ・サーバーから構成されます。プロキシ層では任意の数のプロキシ・サーバーが必要な場合があります。プロキシ・サーバーの数は、予想されるExtendクライアントの数および予想されるクライアントのリクエスト負荷に依存します。各プロキシ・サーバーがクラスタ・メンバーで独自のJVMプロセスを実行し、複数のプロキシ・サーバーを1つの物理サーバー上で連結できます。Extendクライアントの詳細およびプロキシの設定の詳細は、『Oracle Coherenceリモート・クライアントの開発』を参照してください。
プロキシ・サーバーは、通常、com.tangosol.net.DefaultCacheServer
クラスを使用して起動されます。このクラスにはmain
メソッドが含まれ、コマンド行から起動されます。キャッシュ・サーバーの起動の詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。プロキシ・サーバーとキャッシュ・サーバーとの違いは、プロキシ・サーバーはデータを格納しない点と、Extendクライアントのリクエストを処理するプロキシ・サービスをホストしないという点です。
次のアプリケーション・アーティファクトは、プロキシとともにデプロイされることがあります。
オペレーション・オーバーライド構成ファイル、キャッシュ構成ファイルおよびPOFユーザー・タイプ構成ファイルなどの構成ファイル。
POFシリアライザおよびドメイン・オブジェクト。ExtendクライアントがC++または.NETを使用して実装されている場合、オブジェクトのJavaバージョンも特定のユース・ケース用にデプロイする必要があります。
問合せ、エントリ・プロセッサ、エントリ・アグリゲータなどのデータ・グリッド処理実装。
イベント処理実装。
データ・ソースからオブジェクトをキャッシュする際のキャッシュ・ストアおよびローダー実装。
アプリケーション・アーティファクトをプロキシ層にパッケージ化する方法に制限はありません。ただし、アーティファクトはサーバーのクラスパスにあり、すべての構成ファイルがcoherence.jar
ライブラリの前にある必要があります。それ以外の場合、coherence.jar
ライブラリにあるデフォルトの構成ファイルがロードされます。次の例では、単一のプロキシ・サーバーがAPPLICATION_HOME
\config
ディレクトリにある構成ファイルを使用して起動し、APPLICATION_HOME
\lib\myClasses
ライブラリにある実装クラスを使用します。
java -server -Xms512m -Xmx512m -Dtangosol.coherence.distributed.localstorage=false -cp APPLICATION_HOME
\config;APPLICATION_HOME\lib\myClasses.jar;COHERENCE_HOME\lib\coherence.jar com.tangosol.net.DefaultCacheServer
GARデプロイメント
Coherenceアプリケーション・アーティファクトは、グリッド・アーカイブ(GAR)としてパッケージ化してDefaultCacheServer
クラスでデプロイできます。GARは特定のディレクトリ構造に準拠し、アプリケーション・ディスクリプタを含みます。GARパッケージ化の詳細は、「Coherence GARモジュールの構築」を参照してください。手順はWebLogicサーバー・デプロイメントの一部として含まれていますが、DefaultCacheServer
クラスでデプロイ中のGARにも適用できます。
次の例では、プロキシ・サーバーを起動してMyGar.gar
ファイルにパッケージ化されているアプリケーション・アーティファクトを使用します。デフォルト名(MyGAR
)はアプリケーション名として使用され、クラスタ上のアプリケーションの有効範囲を提供します。
java -server -Xms512m -Xmx512m -Dtangosol.coherence.distributed.localstorage=false -cp APPLICATION_HOME
\config;APPLICATION_HOME\lib\myClasses.jar;COHERENCE_HOME\lib\coherence.jar com.tangosol.net.DefaultCacheServer D:\example\MyGAR.gar
デフォルト名は引数として別の名前を指定することでオーバーライドできます。有効なDefaultCacheServer
引数の詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。アプリケーション・スコープの詳細は、「単一クラスタでの複数のアプリケーションの実行」を参照してください。
ExtendクライアントはJava、C++または.NETアプリケーションとして実装されます。また、RESTクライアントAPIを提供する任意のクライアント・テクノロジでCoherenceクラスタにキャッシング・サービスを使用できます。ExtendクライアントはCoherenceキャッシュを使用するアプリケーションですが、Coherenceクラスタのメンバーではありません。これらのクライアントに固有のデプロイメントの詳細は、『Oracle Coherenceリモート・クライアントの開発』を参照してください。
次のCoherenceアーティファクトは、Extendクライアントとともにデプロイされることがあります。
オペレーション・オーバーライド構成ファイル、キャッシュ構成ファイルおよびPOFユーザー・タイプ構成ファイルなどの構成ファイル。
POFシリアライザおよびドメイン・オブジェクト。
問合せ、エントリ・プロセッサ、エントリ・アグリゲータなどのデータ・グリッド処理実装。
イベント処理実装。
WebLogic Serverには、WebLogic Serverドメイン内にCoherenceアプリケーションをデプロイして管理できる方法を標準化するCoherence統合機能が含まれています。この統合機能により、管理者は使い慣れたWebLogic Serverコンポーネントとインフラストラクチャ(Java EEスタイルのパッケージ化とデプロイメント、リモート・サーバー管理、サーバー・クラスタ、WebLogic Scripting Tool (WLST)自動化や管理コンソールからの構成など)を使用して分散Coherence環境の設定ができます。
この項で説明する手順は、WebLogicサーバーについてある程度の知識があることを想定しています。また、WebLogicサーバー・ドメインが作成済であることを想定しています。すべての手順の説明では、WebLogic Server管理コンソールを使用します。WebLogic Server管理コンソールの使用の詳細は、Oracle WebLogic Server管理コンソール・ヘルプを参照してください。Coherenceクラスタの構成および管理の詳細は、『Oracle WebLogic Serverクラスタの管理』を参照してください。
この項の内容は次のとおりです。
CoherenceはWebLogic Serverと統合されます。統合により、Coherenceクラスタ・メンバーのライフサイクルを、管理対象サーバーのライフサイクルに合せ、つまり、サーバーJVMの開始と終了に合せてCoherenceクラスタ・メンバーを開始および終了することになります。クラスタの最初のメンバーがクラスタ・サービスを開始し、シニア・メンバーになります。
その他のJava EEモジュールと同様に、Coherenceは、グリッド・アーカイブ(GAR)という独自のアプリケーション・モジュールをサポートします。GARには、Coherenceアプリケーションのアーティファクトが格納され、デプロイメント・ディスクリプタが含まれています。GARは、その他のJava EEモジュールと同じ方法でデプロイおよびアンデプロイするため、クラスタ・サービス・ライフタイムから分離されます。Coherenceアプリケーションは、サービスの名前空間ごと、およびクラス・ローダーごとに分離されます。
Coherenceは、通常、Weblogic Serverドメイン内への機能的分離を提供する層に設定されます。最も一般的な層は、データをキャッシングするためのデータ層およびキャッシュされたデータを使用するためのアプリケーション層です。プロキシ・サーバー層およびExtendクライアント層は、Coherence*Extendを使用する際に設定する必要があります。HTTPセッション層は、Coherence*Webを使用する際に設定する必要があります。Coherence*WebのデプロイおよびHTTPセッション・データの管理の手順は、『Oracle Coherence*WebでのHTTPセッション・マネージメントの管理』を参照してください。
Coherenceクラスタに関連付けられたWebLogic管理対象サーバーは、管理対象Coherenceサーバーと呼ばれます。各層内の管理対象Coherenceサーバーは個別に管理することもできますが、通常はそれぞれのWebLogicサーバー・クラスタに関連付けられます。GARは、データ層サーバーおよびプロキシ層サーバーごとにデプロイする必要があります。その後で、同一のGARは1つのEAR内にパッケージ化し、それぞれのアプリケーションおよびExtendクライアント層サーバーにデプロイします。クライアント層とは別の専用の記憶域層を使用することが、最適なパフォーマンスを実現するためのベスト・プラクティスになります。
Coherenceアプリケーションは、GARモジュールとしてデプロイメントするためにパッケージ化する必要があります。GARモジュールは、Coherenceアプリケーションから成るアーティファクトを含み、特定のディレクトリ構造を保持します。GARは、アーカイブ化解除されたディレクトリとして残すことも、.gar
拡張子を付けてアーカイブ化することもできます。GARは、スタンドアロン・モジュールとしてデプロイするか、EAR内にデプロイします。
Coherence GARモジュールを構築する手順は、次のとおりです。
次のGARディレクトリ構造を作成します。
/ /lib/ /META-INF/
Coherenceキャッシュ構成ファイルと、POF構成ファイル(必要な場合)をGAR内のディレクトリに追加します。例:
/ /lib/ /META-INF/coherence-cache-config.xml /META-INF/pof-config.xml
注意: 構成ファイルは、GARのルート・ディレクトリに格納しないでください。構成ファイルがルート・ディレクトリに格納されている場合は、ここに示したデフォルト名は使用しません。そのかわりに、これらの構成ファイルはシステム・クラスパス内に格納された |
coherence-application.xml
デプロイメント・ディスクリプタ・ファイルを作成して、このファイルを/META-INF
ディレクトリに保存します。Coherence GARには、META-INF
ディレクトリ内にあるcoherence-application.xml
デプロイメント・ディスクリプタが含まれている必要があります。デプロイメント・ディスクリプタが存在することで、有効なGARが示されます。
/ /lib/ /META-INF/coherence-application.xml /META-INF/coherence-cache-config.xml /META-INF/pof-config.xml
coherence-application.xml
ファイルを編集して、手順2で追加した構成ファイルの場所を指定します。例:
<?xml version="1.0"?> <coherence-application> xmlns="http://xmnls.oracle.com/coherence/coherence-application"> <cache-configuration-ref>META-INF/coherence-cache-config.xml </cache-configuration-ref> <pof-configuration-ref>META-INF/pof-config.xml</pof-configuration-ref> </coherence-application>
注意:
|
すべてのCoherenceアプリケーションのJavaクラス(エントリ・プロセッサ、アグリゲータ、フィルタなど)を該当パッケージ構造内のルート・ディレクトリに配置します。
すべてのライブラリ依存性を/lib
ディレクトリに格納します。
ルート・ディレクトリからJavaのjar
コマンドを使用して、.gar
拡張子を付けてアーカイブを圧縮します。例:
jar cvf MyApp.gar *
GARモジュールはEARモジュール内にパッケージ化して、他のモジュールから参照できるようにする必要があります。EARモジュールの作成方法の詳細は、『Oracle WebLogic Serverアプリケーションの開発』を参照してください。
GARモジュールをEARモジュール内に含める手順は、次のとおりです。
EARのルート・ディレクトリにGARと、Coherenceを使用するすべてのアプリケーション・モジュール(WAR、EJBなど)をコピーします。
META-INF/weblogic-application.xml
ディスクリプタを編集し、<module>
要素を使用してGARへの参照を含めます。参照は、EARがデプロイされたときにGARがデプロイされるために必要です。例:
<?xml version = '1.0'> <weblogic-application xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.bea.com/ns/weblogic/weblogic-application http://www.bea.com/ns/weblogic/weblogic-application/1.0/ weblogic-application.xsd" xmlns="http://www.bea.com/ns/weblogic/weblogic-application"> <module> <name>MyAppGAR</name> <type>GAR</type> <path>MyApp.gar</path> </module> </weblogic-application>
CoherenceはWebLogic Serverドメインの各種ドメイン・トポロジをサポートすることで、様々なレベルのパフォーマンス、スケーラビリティおよび使いやすさを実現します。たとえば、開発時には単一の管理対象Coherenceサーバー・インスタンスを、キャッシュ・サーバーとしても、キャッシュ・クライアントとしても使用できます。単一サーバー・トポロジは設定と使用が簡単になりますが、最適なパフォーマンスとスケーラビリティは得られません。本番の場合、Coherenceは、通常、WebLogic Serverクラスタを使用して設定します。あるWebLogic Serverクラスタは、Coherenceデータ層として使用して1つ以上のキャッシュ・サーバーをホストします。また、別のWebLogic Serverクラスタは、Coherenceアプリケーション層として使用して1つ以上のキャッシュ・クライアントをホストします。さらに、必要な場合は、別のWebLogic ServerクラスタをCoherenceプロキシ層に使用して、1つ以上の管理対象Coherenceプロキシ・サーバーとExtendクライアントをホストするCoherence Extendクライアント層をホストします。層化されたトポロジにより、最適なスケーラビリティとパフォーマンスが得られます。ドメイン・トポロジは、常にアプリケーションの要件に基づいている必要があります。
Coherence用のドメイン・トポロジを作成する際には、次のガイドラインを使用してください。
ドメインは、通常、単一のCoherenceクラスタを含んでいます。
複数のWebLogic Serverクラスタは、1つのCoherenceクラスタに関連付けできます。
Coherenceクラスタに関連付けられた管理対象サーバーは、管理対象Coherenceサーバーとみなされ、Coherenceクラスタ・メンバーと同じになります。
別の管理対象Coherenceサーバー・インスタンス(可能ならば別のWebLogic Serverクラスタ)を使用して、Coherenceのキャッシュ・サーバーとクライアントを分離します。
WebLogic Serverドメイン内で管理されるCoherenceメンバーは、スタンドアロンのJVMメンバーで構成される外部のCoherenceクラスタに参加してはいけません。スタンドアロンのJVMクラスタ・メンバーは、WebLogic Serverドメイン内で管理対象にはできません。
WebLogic Serverコンソールを使用して、Coherenceクラスタを作成するには:
コンソールのホーム・ページの「環境」セクションで、「Coherenceクラスタ」をクリックします。
「Coherenceクラスタのサマリー」ページで、「新規」をクリックします。
「Coherenceクラスタ構成の作成」ページで、クラスタの名前を「名前」フィールドに入力します。
「次へ」をクリックして、手順6に進みます。
または
「カスタム・クラスタ構成ファイルの使用」チェック・ボックスをクリックして選択します。WebLogic Server MBeansは、通常のユース・ケースに十分な操作設定のサブセットを公開します。ただし、操作設定の完全な制御が必要になる高度なユース・ケースの場合は、クラスタ構成ファイル(tangosol-coherence-override.xml
ファイルなど)を使用できます。「次へ」をクリックします。クラスタ操作設定の使用方法の詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。
注意: 外部クラスタ構成ファイルの使用は、提供されたMBeanを介して使用できない操作設定の場合にのみお薦めします。つまり、同じ操作設定を外部クラスタ構成ファイルとMBean経由の両方で構成することは避けてください。 |
Coherenceクラスタ構成ファイルの作成画面から、管理サーバーに格納されたクラスタ構成ファイルのパスと名前を「ファイル・パス」フィールドに入力します。「次へ」をクリックして、手順7に進みます。
「Coherenceクラスタのアドレス指定」セクションからデフォルトのクラスタリング・モード(ユニキャスト)をそのまま使用して、必要に応じてポートを変更します。マルチキャストを使用するには、ドロップダウン・リストを使用して「マルチキャスト」を選択し、クラスタ用の一意のマルチキャスト・アドレスとポートを指定します。「次へ」をクリックします。
ユニキャストが使用されている場合、クラスタはCoherenceクラスタ(マシン当たり1つ)の管理対象Coherenceサーバー・インスタンスに基づいて自動的にウェル・ノウン・アドレス(WKA)のリストを作成します。メンバーまたはポートの数を変更する場合は、管理コンソールを使用してクラスタ定義を編集し、独自のWKAリストを定義できます。アドレスは、localhost
ではなくホスト上の実際のIPアドレスを使用して入力する必要があります。それ以外の場合は管理対象Coherenceサーバーは他のクラスタ・メンバーに参加できなくなります。WKAの詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。
Coherenceクラスタ・メンバー・セクションで、Coherenceクラスタに加える管理対象CoherenceサーバーまたはWebLogic Serverクラスタをクリックして選択します。管理対象サーバーやWebLogicクラスタがまだ定義されていない場合は、このセクションを省略します。
「終了」をクリックします。「Coherenceクラスタの概要」画面が表示され、「Coherenceクラスタ」表にクラスタが一覧表示されます。
WLSドメインにCoherenceを設定する際に優先されるアプローチでは、Coherenceキャッシュのサーバー、クライアントおよびプロキシを、同一のCoherenceクラスタに関連付けられた別々の層に分割します。一般に、各層は管理対象Coherenceサーバーの独自のWebLogic Serverクラスタに関連付けられます。ただし、1つの層が複数のスタンドアロン管理対象Coherenceサーバーから構成されていることもあります。前者のアプローチを使用すると、Coherenceの管理とスケールは最も簡単になります。これは、管理対象CoherenceサーバーはWebLogic ServerクラスタのCoherence設定を継承してデプロイメントできるためです。この項の手順を使用して、データ層、アプリケーション層およびプロキシ層に個別のWebLogic Serverクラスタを作成します。WebLogic Serverクラスタ作成の詳細な手順は、Oracle WebLogic Serverのクラスタ管理を参照してください。
Coherenceデプロイメント層を作成するには:
コンソールのホーム・ページの「環境」セクションで、「クラスタ」をクリックします。
「クラスタの概要」ページから、「新規」をクリックして「クラスタ」を選択します。
「新しいクラスタの作成」ページから、「名前」フィールドを使用してWebLogic Serverクラスタの名前を入力します。
デフォルトのメッセージングング・モード(ユニキャスト)をそのまま使用して、必要に応じてブロードキャスト・チャネルを変更します。または、ドロップダウン・リストから「マルチキャスト」を選択して、個別のマルチキャスト・アドレスとポートを必要に応じて指定します。
「OK」をクリックします。「クラスタのサマリー」画面が表示され、「クラスタ」表にクラスタが一覧表示されます。
「クラスタ」表で、構成するクラスタをクリックします。
「Coherence」タブで、「Coherenceクラスタ」ドロップダウン・リストを使用して、このWebLogic Serverクラスタに関連付けるCoherenceクラスタを選択します。「保存」をクリックします。デフォルトでは、このWebLogic Serverクラスタに割り当てた管理対象Coherenceサーバーは、記憶域が有効なCoherenceメンバー(キャッシュ・サーバー)になります。これについては、「ローカル記憶域有効」フィールドに示されます。
手順1から6を繰り返して、アプリケーション層に使用する別のWebLogic Serverクラスタを作成します。「Coherence」タブで、「Coherenceクラスタ」ドロップダウン・リストを使用して、このWebLogic Serverクラスタに関連付けるCoherenceクラスタを選択します。
「ローカル記憶域有効」チェック・ボックスをクリックしてチェック・マークを外し、アプリケーション層の記憶域を無効にします。このWebLogic Serverクラスタに割り当てた管理対象Coherenceサーバーは、記憶域が無効なCoherenceメンバー(キャッシュ・ファクトリ・クライアント)になります。「保存」をクリックします。
(該当する場合)手順1から6を繰り返して、プロキシ層に使用する別のWebLogic Serverクラスタを作成します。「Coherence」タブで、「Coherenceクラスタ」ドロップダウン・リストを使用して、このWebLogic Serverクラスタに関連付けるCoherenceクラスタを選択します。
「ローカル記憶域有効」チェック・ボックスをクリックしてチェック・マークを外し、プロキシ層の記憶域を無効にします。このWebLogic Serverクラスタに割り当てた管理対象Coherenceサーバーは、記憶域が無効なCoherenceメンバーになります。「保存」をクリックします。
(該当する場合)手順1から6を繰り返して、Extendクライアント層に使用する別のWebLogic Serverクラスタを作成します。「Coherence」タブで、「Coherenceクラスタ」ドロップダウン・リストを使用して、このWebLogic Serverクラスタに関連付けるCoherenceクラスタを選択します。
「ローカル記憶域有効」チェック・ボックスをクリックしてチェック・マークを外し、プロキシ層の記憶域を無効にします。このWebLogic Serverクラスタに割り当てた管理対象Coherenceサーバーは、記憶域が無効なCoherenceメンバーになります。「保存」をクリックします。
Coherenceクラスタに関連付けられた管理対象サーバーは、Coherenceクラスタのメンバーになり、管理対象Coherenceサーバーと呼ばれます。この項の手順を使用して、管理対象サーバーを作成し、そのサーバーをWebLogic Serverクラスタに関連付けます。このクラスタは、Coherenceデプロイメント層として構成します。管理対象サーバーは、WebLogic ServerクラスタからCoherence設定を自動的に継承します。同様に、既存の管理対象CoherenceサーバーもWebLogic Serverクラスタに関連付けできます。管理対象サーバーの作成手順および構成手順の詳細は、Oracle WebLogic Server管理コンソール・ヘルプを参照してください。
Coherenceデプロイメント層用の管理対象サーバーを作成するには:
コンソールのホーム・ページの「環境」セクションで、「サーバー」をクリックします。
「新規」をクリックして、新しい管理対象サーバーを作成します。
「新しいサーバーの作成」ページで、サーバーのプロパティを必要に応じて入力します。
「はい」オプションをクリックして、既存のクラスタにサーバーを追加し、ドロップダウン・リストを使用してCoherence層として構成するWebLogic Serverクラスタを選択します。管理対象サーバーは、WebLogic ServerクラスタからCoherence設定を継承します。
「終了」をクリックします。「サーバーのサマリー」ページが表示され、新しいサーバーが一覧表示されます。
ここまでの手順を繰り返して、追加の管理対象サーバーを必要に応じて作成します。
「制御」タブをクリックし、サーバーを選択してから「起動」をクリックします。サーバーの起動の詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverサーバーの起動と停止の管理』を参照してください。
各Coherenceデプロイメント層には、Coherenceアプリケーション・モジュールを含める必要があります。アプリケーション・モジュールのデプロイで、GARのキャッシュ構成ファイルに定義されたサービスが開始します。Coherenceアプリケーションをパッケージ化する方法の詳細は、「WebLogic Server用のCoherenceアプリケーションのパッケージ化」を参照してください。コンソールを使用してアプリケーションをデプロイする方法の詳細は、WebLogic Server管理コンソール・ヘルプを参照してください。
Coherenceモジュールは、次のようにデプロイします。
データ層(キャッシュ・サーバー): スタンドアロンのGARをデータ層の各管理対象Coherenceサーバーにデプロイします。データ層がWebLogic Serverクラスタとして設定されている場合、GARがクラスタにデプロイされ、WebLogicデプロイメント・インフラストラクチャで各管理対象Coherenceサーバーにモジュールがコピーされます。
アプリケーション層(キャッシュ・クライアント): GARおよびクライアント実装(WebアプリケーションやEJBなど)を格納するEARをクラスタ内の各管理対象Coherenceサーバーにデプロイします。アプリケーション層がWebLogic Serverクラスタとして設定されている場合、EARがクラスタにデプロイされ、WebLogicデプロイメント・インフラストラクチャで各管理対象Coherenceサーバーにモジュールがコピーされます。
プロキシ層(プロキシ・サーバー): スタンドアロンのGARをプロキシ層の各管理対象Coherenceサーバーにデプロイします。プロキシ層がWebLogic Serverクラスタとして設定されている場合、GARがクラスタにデプロイされ、WebLogicデプロイメント・インフラストラクチャで各管理対象Coherenceサーバーにモジュールがコピーされます。
注意: プロキシ層の管理対象Coherenceサーバーには、キャッシュ構成ファイルにプロキシ・サービスの定義が含まれている必要があります。同じGARを各層にデプロイしてから、クラスタレベル・キャッシュ構成ファイルを使用してプロキシ層サーバーのみのキャッシュ構成ファイルをオーバーライドできます。クラスタレベル・キャッシュの指定の詳細は、『Oracle WebLogic Serverクラスタの管理』を参照してください。 |
Extendクライアント層(Extendクライアント) – GARおよびExtendクライアント実装を含むEARが、Extendクライアントをホストする各管理対象サーバーにデプロイされます。Extendクライアント層がWebLogic Serverクラスタとして設定されている場合、EARがクラスタにデプロイされ、WebLogicデプロイメント・インフラストラクチャで各管理対象サーバーにモジュールがコピーされます。
注意: Extend層の管理対象サーバーには、キャッシュ構成ファイルにリモート・キャッシュ・サービスの定義が含まれている必要があります。同じGARを各層にデプロイしてから、クラスタレベル・キャッシュ構成ファイルを使用してExtend層サーバーのみのキャッシュ構成ファイルをオーバーライドできます。クラスタレベル・キャッシュの指定の詳細は、『Oracle WebLogic Serverクラスタの管理』を参照してください。 |
データ層GARのデプロイ
データ層にGARをデプロイするには:
コンソールのホーム・ページの「デプロイ済みリソース」セクションで、「デプロイメント」をクリックします。
「インストール」をクリックします。
「アプリケーション・インストール・アシスタント」ページで、デプロイするGARを見つけて選択します。「次へ」をクリックします。
GARのデプロイ先になるデータ層(WebLogic Serverクラスタまたはスタンドアロンの管理対象Coherenceサーバー)を選択します。「次へ」をクリックします。
「送信元」のアクセシビリティ設定を編集し、各ターゲットにモジュールをコピーするオプションを選択します。「終了」をクリックします。「デプロイメントのサマリー」ページが表示され、「デプロイメント」表にGARが一覧表示されます。
デプロイメントの一覧からGARのチェック・ボックスを選択して、「開始」をクリックします。
アプリケーション層EARのデプロイ
アプリケーション層にEARをデプロイするには:
コンソールのホーム・ページの「デプロイ済みリソース」セクションで、「デプロイメント」をクリックします。
「インストール」をクリックします。
「アプリケーション・インストール・アシスタント」ページで、デプロイするEARを見つけて選択します。「次へ」をクリックします。
デフォルトのターゲット・スタイルをそのまま使用して、「次へ」をクリックします。
EARのデプロイ先になるアプリケーション層(WebLogic Serverクラスタまたはスタンドアロンの管理対象Coherenceサーバー)を選択します。「次へ」をクリックします。
「送信元」のアクセシビリティ設定を編集し、各ターゲットにモジュールをコピーするオプションを選択します。「終了」をクリックします。「デプロイメントのサマリー」ページが表示され、「デプロイメント」表にEARが一覧表示されます。
デプロイメントの一覧からEARのチェック・ボックスを選択して、「開始」をクリックします。
プロキシ層GARのデプロイ
プロキシ層にGARをデプロイするには:
コンソールのホーム・ページの「デプロイ済みリソース」セクションで、「デプロイメント」をクリックします。
「インストール」をクリックします。
「アプリケーション・インストール・アシスタント」ページで、デプロイするGARを見つけて選択します。「次へ」をクリックします。
GARのデプロイ先になるプロキシ層(WebLogic Serverクラスタまたはスタンドアロンの管理対象Coherenceサーバー)を選択します。「次へ」をクリックします。
「送信元」のアクセシビリティ設定を編集し、各ターゲットにモジュールをコピーするオプションを選択します。「終了」をクリックします。「デプロイメントのサマリー」ページが表示され、「デプロイメント」表にGARが一覧表示されます。
デプロイメントの一覧からGARのチェック・ボックスを選択して、「開始」をクリックします。
管理者は、WebLogic Serverツールを使用して、WebLogicドメイン内のCoherence環境を管理します。これらのツールを使用すると、クラスタやクラスタ・メンバーの管理タスクが簡単になります。この項では、基本的な管理タスクを実行するために、管理コンソール・ツールを使用する方法の概要について説明します。これらのタスクを完了する方法の詳細は、Oracle WebLogic Server管理コンソール・ヘルプを参照してください。WebLogic Scripting Tool (WLST)の使用の詳細は、『WebLogic Scripting Toolの理解』を参照してください。
表1-1 管理コンソールでの基本的な管理タスク
目的 | 使用対象 |
---|---|
Coherenceクラスタの作成 |
「Coherenceクラスタ」ページ |
クラスタ・メンバーの追加または削除、またはCoherenceクラスタからのWebLogic Serverクラスタの追加または削除 |
Coherenceクラスタの「設定」ページにある「メンバー」タブ。 |
Coherenceクラスタのユニキャスト設定またはマルチキャスト設定の構成 |
Coherenceクラスタの「設定」ページにある「一般」タブ。ユニキャストを選択した場合、デフォルトのウェル・ノウン・アドレス構成は、「Well Knownアドレス」タブを使用してオーバーライドできます。 |
Coherenceクラスタを構成するためのカスタム構成ファイルの使用 |
Coherenceクラスタの「設定」ページにある「一般」タブ |
クラスタ・メンバーへのキャッシュ構成ファイルのインポート、およびGARにデプロイしたキャッシュ構成ファイルのオーバライド |
Coherenceクラスタの「設定」ページにある「構成」タブ |
ロギングの構成 |
Coherenceクラスタの「設定」ページにある「ロギング」タブ |
Coherenceクラスタへの管理対象サーバーの割当て |
管理対象サーバーの「設定」ページにある「Coherence」タブ |
Coherenceクラスタ・メンバーのプロパティの構成 |
管理対象サーバーの「設定」ページにある「Coherence」タブ |
WebLogic ServerクラスタとCoherenceクラスタとの関連付け、およびクラスタの管理対象Coherenceサーバーの記憶域の有効化または無効化 |
WebLogic Serverクラスタの「設定」ページにある「Coherence」タブ |
Coherenceクラスタに関連付けられたWebLogic Serverクラスタへの管理対象サーバーの割当て |
管理対象サーバーの「設定」ページにある「一般」タブ |
WebLogic Server以外のアプリケーション・サーバーにデプロイされるJava EEアプリケーションには、Coherenceをデプロイするための2つのオプション(アプリケーション・サーバー・ライブラリとして、またはJava EEモジュールの一部としてデプロイ)があります。Coherenceクラスタのメンバーにはクラス・ローダーのスコープが設定されています。そのため、オプションの選択によってデプロイメント・シナリオが異なります。Coherenceがアプリケーション・サーバー・ライブラリとしてデプロイされている場合、すべてのモジュールは単一のクラスタ・メンバーを共有します。その一方で、Coherenceがモジュールの一部としてデプロイされている場合、Java EEモジュールは、そのモジュール自体がクラスタ・メンバーになります。どちらのオプションにも利点と前提条件があり、一般的にクラスタ・メンバーが他のモジュールから分離されている程度とリソース利用率とのバランスが取られます。
注意: Coherence*WebのデプロイおよびHTTPセッション・データのクラスタリングの手順は、『Oracle Coherence*WebでのHTTPセッション・マネージメントの管理』を参照してください。 |
Coherenceをアプリケーション・サーバー・ライブラリとしてデプロイできます。このデプロイメント・シナリオでは、アプリケーション・サーバーの起動クラスパスをCOHERENCE_HOME
/lib/coherence.jar
ライブラリが含まれるように変更します。また、キャッシュに配置するオブジェクトはすべて、サーバーのクラスパスで使用できる必要があります。ライブラリをサーバーのクラスパスに追加する手順は、アプリケーション・サーバーのベンダーのドキュメントを参照してください。
このシナリオでは、サーバーのコンテナにデプロイされたすべてのアプリケーションで1つのクラスタ・メンバーを共有するようになります。このシナリオでは、Coherenceクラスの1つのコピーのみがJVMにロードされるため、リソース使用率が最小限に抑えられます。このデプロイメント・スタイルを選択したときに、Coherenceアプリケーションを相互に分離する手順の詳細は、「単一クラスタでの複数のアプリケーションの実行」を参照してください。
CoherenceをEARファイルまたはWARファイル内にデプロイできます。一般に、このデプロイメント・スタイルは、アプリケーション・サーバーの実行時環境に変更を加える必要がなく、クラスタ・メンバーはEARまたはWARのどちらかに分離されているため、優先的に選択されます。
CoherenceをEARの一部としてデプロイできます。このデプロイメント・シナリオでは、EAR内のすべてのWebアプリケーションで1つのクラスタ・メンバーを共有することになります。EARごとにCoherenceクラスのコピーが1つのみロードされるため、リソース使用率は中程度になります。ただし、クラスタ・メンバーによる、いずれか1つのモジュールの使用が、すべてのWebアプリケーションに影響を与える可能性があります。Coherenceアプリケーションを相互に分離する手順の詳細は、「単一クラスタでの複数のアプリケーションの実行」を参照してください。
Coherenceをエンタープライズ・アプリケーション内にデプロイする手順は次のとおりです。
coherence.jar
ライブラリを、エンタープライズ・アプリケーションのディレクトリ構造内の任意の場所にコピーします。
テキスト・エディタを使用して、META-INF/application.xml
デプロイメント・ディスクリプタを開きます。
アプリケーション・ディレクトリの最上位に対する相対パスおよびCoherenceライブラリの名前が含まれる<java>
要素を追加します。例:
<application> <display-name>MyApp</display-name> <module> <java>coherence.jar</java> </module> ... </application>
キャッシュに配置するオブジェクトすべてを前述の方法でアプリケーションに追加します。
ディスクリプタを保存して閉じます。
アプリケーションをパッケージ化してデプロイします。
CoherenceをWebアプリケーションの一部としてデプロイできます。このデプロイメント・シナリオでは、それぞれのWebアプリケーションが固有のクラスタ・メンバーを持ち、他のすべてのWebアプリケーションから分離されるようになります。このシナリオでは、Coherenceを含むWebアプリケーションがデプロイされる数と同じ数のCoherenceクラスのコピーがロードされるため、リソースを最も大量に使用します。このシナリオは、1つのアプリケーション・サーバーに数個のWebアプリケーションのみをデプロイする場合に適しています。
CoherenceをWebアプリケーション内にデプロイする手順は次のとおりです。
WebアプリケーションのWEB-INF/lib
ディレクトリにcoherence.jar
ライブラリをコピーします。
キャッシュに配置するすべてのオブジェクトが、WEB-INF/lib
ディレクトリまたはWEB-INF/classes
ディレクトリに配置されていることを確認します。
アプリケーションをパッケージ化してデプロイします。
Coherenceは、独自のCoherenceキャッシュとサーバーのセットを定義すれば、複数のアプリケーションが同一のクラスタを使用する共有環境にデプロイできます。このようなシナリオの場合、各アプリケーションは、スコープ名を含む独自のキャッシュ構成ファイルを使用します。このスコープ名によって、アプリケーション間でキャッシュとサービスを共有できるようにするかどうかを制御します。
この項には、次のトピックが含まれます:
<scope-name>
要素を使用して、キャッシュ構成ファイル内でキャッシュとサービスを一意に特定するサービスの名前空間を指定します。これが指定されていると、すべてのキャッシュとサービスは分離され、同一クラスタで実行する他のアプリケーションからは使用できなくなります。
次の例では、accounts
というスコープ名を構成します。これにより、その構成に基づいて作成されたConfigurableCacheFactory
インスタンスでインスタンス化されるすべてのサービスは、接頭辞としてaccounts
を使用するようになります。スコープ名は、キャッシュ・ファクトリ・インスタンスの属性であり、キャッシュ・ファクトリのインスタンスにのみ影響します。
注意: この接頭辞は、サービス名にのみ使用します。キャッシュ名には使用しません。 |
<?xml version='1.0'?> <cache-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://xmlns.oracle.com/coherence/coherence-cache-config" xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-cache-config coherence-cache-config.xsd"> <defaults> <scope-name>accounts</scope-name> </defaults> <caching-scheme-mapping> ...
WebLogic Serverにデプロイするときには、デプロイされた複数のCoherenceアプリケーション(GAR)が、サービスの名前空間ごと、およびデフォルトのClassLoaderごとにWebLogic Server内で分離されるため、スコープ名の構成は必要ありません。ただし、スコープ名はGAR間でキャッシュを共有するために構成することもできます。キャッシュ構成ファイルでのスコープの直接構成は、通常、上級ユーザー・ケースで実行されます。
デプロイメント名は、GARのデプロイ時にデフォルトのスコープ名として使用されます。デプロイメント名がデプロイ中に指定されない場合、アーティファクト名がデプロイメント名として使用されます。たとえば、MyApp.gar
モジュールの場合、デフォルトのデプロイメント名はMyApp
です。EARにパッケージ化されたGARの場合、デプロイメント名はweblogic-application.xml
ファイルのGARに指定されたモジュール名です。
アプリケーション・サーバー・ライブラリまたはEARの一部としてCoherenceをデプロイすると、複数のアプリケーションが単一のクラスタ・メンバー(1つのJVM)として同一のクラスタを使用できます。このようなデプロイメント・シナリオでは、複数のアプリケーションが、単一のcoherence-cache-config.xml
ファイルで構成された1つのCoherenceのキャッシュとサービスのセットを使用することを選択できます。このタイプのデプロイメントは、アプリケーションのデプロイメントが調整された制御環境においてのみお薦めします(また、その場合にのみ実用的になります)。キャッシュ間、サービス間およびその他の構成設定間で衝突する可能性が高く、想定外の結果を招くことがあります。さらに、Coherenceノードの1つのアプリケーションの使用が、すべてのアプリケーションに影響を及ぼす可能性もあります。
別の方法として、各アプリケーションに独自のキャッシュ構成ファイルを含めるようにします。この構成ファイルでは、そのアプリケーションに固有のキャッシュとサービスを定義します。この構成は、キャッシュ構成ファイル内の<scope-name>
要素を使用して指定したスコープ名で分離されます。同様に、アプリケーションは、その他のアプリケーションが必要とするときにはキャッシュとサービスの共有を明示的に許可できます。このシナリオでは、それぞれが1つのアプリケーションに関連する複数のConfigurableCacheFactory
インスタンスが、1つのJVMに含まれていることを想定しています。
次の例では、2つのWebアプリケーション(trade.war
およびaccounts.war
)を分離するために必要な手順を示します。これにより、それぞれのアプリケーションのキャッシュとサービスを相互に使用しないようにします。
tradeアプリケーション用のキャッシュ構成ファイル(たとえば、trade-cache-config.xml
)を作成します。この構成ファイルでは、trade
というスコープ名を定義し、そのアプリケーション用のすべてのキャッシュ・スキーム定義を含めます。
<?xml version='1.0'?> <cache-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://xmlns.oracle.com/coherence/coherence-cache-config" xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-cache-config coherence-cache-config.xsd"> <defaults> <scope-name>trade</scope-name> </defaults> ...
accountsアプリケーション用のキャッシュ構成ファイル(たとえば、accounts-cache-config.xml
)を作成します。この構成ファイルでは、accounts
というスコープ名を定義し、そのアプリケーション用のすべてのキャッシュ・スキーム定義を含めます。
<?xml version='1.0'?> <cache-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://xmlns.oracle.com/coherence/coherence-cache-config" xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-cache-config coherence-cache-config.xsd"> <defaults> <scope-name>accounts</scope-name> </defaults> ...
各キャッシュ構成ファイルが、それぞれのWARファイル(通常は、WEB-INF/classes
ディレクトリ内にあります)に含まれていることを確認します。これにより、アプリケーションは実行時に構成ファイルをロードして使用できるようになります。
各アプリケーションは、それらのキャッシュとサービスへのアクセスを許可することで、データを共有できます。次の例では、Webアプリケーション(trade.war
)が別のアプリケーション(accounts.war
)のキャッシュとサービスにアクセスできるようにする手順を示します。
tradeアプリケーション用のキャッシュ構成ファイル(たとえば、trade-cache-config.xml
)を作成します。この構成ファイルでは、trade
というスコープ名を定義し、そのアプリケーション用のすべてのキャッシュ・スキーム定義を含めます。
<?xml version='1.0'?> <cache-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://xmlns.oracle.com/coherence/coherence-cache-config" xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-cache-config coherence-cache-config.xsd"> <defaults> <scope-name>trade</scope-name> </defaults> ...
accountsアプリケーション用のキャッシュ構成ファイル(たとえば、accounts-cache-config.xml
)を作成します。この構成ファイルでは、accounts
というスコープ名を定義し、そのアプリケーション用のすべてのキャッシュ・スキーム定義を含めます。
<?xml version='1.0'?> <cache-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://xmlns.oracle.com/coherence/coherence-cache-config" xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-cache-config coherence-cache-config.xsd"> <defaults> <scope-name>accounts</scope-name> </defaults> ...
各キャッシュ構成ファイルが、それぞれのWARファイル(通常は、WEB-INF/classes
ディレクトリ内にあります)に含まれていることを確認します。これにより、アプリケーションは実行時に構成ファイルをロードして使用できるようになります。
tradeアプリケーションには、accountsアプリケーションのキャッシュとサービスにアクセスするためのaccounts-cache-config.xml
ファイルも含める必要があります。
これにより、tradeアプリケーションは、accountsアプリケーション用のキャッシュ・ファクトリを作成するために、次のパターンを使用できるようになります。
ClassLoader loader = ... CacheFactoryBuilder builder = CacheFactory.getCacheFactoryBuilder(); ConfigurableCacheFactory tradesCcf = builder.getConfigurableCacheFactory(tradesUri, loader); ConfigurableCacheFactory accountsCcf = builder.getConfigurableCacheFactory(accountsUri, loader);
単一のCoherenceクラスタを使用するスタンドアロン・アプリケーションには独自のキャッシュ構成ファイルを含めることができますが、これらの構成は単一のConfigurableCacheFactory
に結合されます。ConfigurableCacheFactory
とDefaultCacheServer
の間には1対1の関係があるため、単一のクラスタ・ノード内でアプリケーションのスコープを設定できません。そのかわりに、DefaultCacheServer
の1つ以上のインスタンスはキャッシュ構成ごとに開始される必要があり、各キャッシュ構成にスコープ名を含める必要があります。
次の例では、2つのアプリケーション(tradeおよびaccounts)を分離します。これにより、それぞれのアプリケーションが相互のキャッシュとサービスを使用しないようにします。
tradeアプリケーション用のキャッシュ構成ファイル(たとえば、trade-cache-config.xml
)を作成します。この構成ファイルでは、trade
というスコープ名を定義し、そのアプリケーション用のすべてのキャッシュ・スキーム定義を含めます。
<?xml version='1.0'?> <cache-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://xmlns.oracle.com/coherence/coherence-cache-config" xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-cache-config coherence-cache-config.xsd"> <defaults> <scope-name>trade</scope-name> </defaults> ...
DefaultCacheServer
インスタンスを開始します。このインスタンスは、trade-cache-config.xml
キャッシュ構成ファイルをロードします。
accountsアプリケーション用のキャッシュ構成ファイル(たとえば、accounts-cache-config.xml
)を作成します。この構成ファイルでは、accounts
というスコープ名を定義し、そのアプリケーション用のすべてのキャッシュ・スキーム定義を含めます。
<?xml version='1.0'?> <cache-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://xmlns.oracle.com/coherence/coherence-cache-config" xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-cache-config coherence-cache-config.xsd"> <defaults> <scope-name>accounts</scope-name> </defaults> ...
DefaultCacheServer
インスタンスを開始します。このインスタンスは、accounts-cache-config.xml
キャッシュ構成ファイルをロードします。
注意: アプリケーション間でデータを共有する場合、それらのアプリケーションは同一のキャッシュ構成ファイルを使用する必要があります。Coherenceでは、同一のスコープ名を指定する複数のキャッシュ構成の使用をサポートしていません。 |
com.tangosol.net.ScopeResolver
インタフェースを使用すると、コンテナとアプリケーションが実行時に特定のConfigurableCacheFactory
のスコープ名を変更して、アプリケーション間の分離を強制(または無効化)できるようになります。ScopeResolver
インタフェースを実装し、必要に応じてカスタム機能に追加します。
カスタム・スコープ・リゾルバを有効にするには、<cache-factory-builder-config>
ノード内の<scope-resolver>
要素を使用して、実装クラスの完全修飾名をオペレーション・オーバライド・ファイルに定義する必要があります。例:
<?xml version='1.0'?> <coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config" xsi:schemaLocation="http://xmlns.oracle.com/coherence/ coherence-operational-config coherence-operational-config.xsd"> <cache-factory-builder-config> <scope-resolver> <class-name>package.MyScopeResolver</class-name> </scope-resolver> </cache-factory-builder-config> <coherence>
<instance>
要素で、<class-factory-name>
要素および<method-name>
要素を指定することもできます。前者の要素は、ScopeResolver
インスタンスを作成するファクトリ・クラスを使用します。後者の要素は、オブジェクトをインスタンス化するファクトリ・クラスに対して静的なファクトリ・メソッドを指定します。次の例では、MyScopeResolverFactory
クラスのgetResolver
メソッドを使用して、カスタム・スコープ・リゾルバのインスタンスを取得しています。
<?xml version='1.0'?> <coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config" xsi:schemaLocation="http://xmlns.oracle.com/coherence/ coherence-operational-config coherence-operational-config.xsd"> <cache-factory-builder-config> <scope-resolver> <class-factory-name>package.MyScopeReolverFactory</class-factory-name> <method-name>getResolver</method-name> </scope-resolver> </cache-factory-builder-config> <coherence>
実装に必要な初期化パラメータはすべて、<init-params>
要素を使用して指定できます。次の例では、isDeployed
パラメータにtrue
を設定しています。
<?xml version='1.0'?> <coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config" xsi:schemaLocation="http://xmlns.oracle.com/coherence/ coherence-operational-config coherence-operational-config.xsd"> <cache-factory-builder-config> <scope-resolver> <class-name>package.MyScopeResolver</class-name> <init-params> <init-param> <param-name>isDeployed</param-name> <param-value>true</param-value> </init-param> </init-params> </scope-resolver> </cache-factory-builder-config> <coherence>