Coherenceアプリケーションのデプロイ

1 Coherenceアプリケーションのデプロイ

Coherenceはアプリケーション・サーバーのスタンドアロン・アプリケーションまたはJava EEアプリケーションとしてデプロイできます。汎用アプリケーション・サーバー・デプロイメントの手順のほかに、WebLogic Serverデプロイメントの個別の手順が提供されています。

この章の内容は次のとおりです。

スタンドアロンCoherenceアプリケーションのデプロイ
スタンドアロンCoherenceアプリケーションは1組の分散プロセスとしてデプロイされます。
DockerおよびKubernetesへのCoherenceアプリケーションのデプロイ
Oracle CoherenceアプリケーションはDockerコンテナとしてデプロイでき、Kubernetesを使用して調整できます。これらの業界トップの標準により、非常にスケーラブルで簡単に管理できる、最新のクラウドニュートラルなデプロイメント・ソリューションが提供されます。
CoherenceアプリケーションのWebLogic Serverへのデプロイ
WebLogic Serverには、WebLogic Serverドメイン内にCoherenceアプリケーションをデプロイして管理できる方法を標準化するCoherence統合機能が含まれています。
Coherenceアプリケーションのアプリケーション・サーバー(汎用)へのデプロイ
WebLogic Server以外のアプリケーション・サーバーにデプロイされるJava EEアプリケーションには、Coherenceをデプロイするための2つのオプション(アプリケーション・サーバー・ライブラリとして、またはJava EEモジュールの一部としてデプロイ)があります。
単一クラスタでの複数のアプリケーションの実行
Coherenceは、独自のCoherenceキャッシュとサーバーのセットを定義すれば、複数のアプリケーションが同一のクラスタを使用する共有環境にデプロイできます。

親トピック: 基本的な管理

スタンドアロンCoherenceアプリケーションのデプロイ

スタンドアロンCoherenceアプリケーションは1組の分散プロセスとしてデプロイされます。デプロイメントの場合、これらのプロセスをそのロールに基づいた層に論理的にグループ化すると有益な場合がありますが、これはデプロイメントの要件ではありません。最も一般的な層は、データ層、アプリケーション層、プロキシ層およびExtendクライアント層です。層により、共通のアーティファクト、パッケージ化およびスクリプトを定義して各層用に設定できるためデプロイメントが容易になります。

この項には次のトピックが含まれます:

親トピック: Coherenceアプリケーションのデプロイ

データ層のデプロイ

データ層はキャッシュ・オブジェクトを格納するキャッシュ・サーバーから構成されます。Coherenceアプリケーションでは、データ層に任意の数のキャッシュ・サーバーが必要な場合があります。キャッシュ・サーバーの数は、キャッシュに予想されるデータの量と、そのデータをバックアップしてサーバー障害後も存続させる必要があるかどうかに依存します。各キャッシュ・サーバーがCoherenceクラスタ・メンバーで独自のJVMプロセスで稼働し、複数のキャッシュ・サーバーを1つの物理サーバー上で連結できます。キャッシュ・サイズ計算の推奨事項およびハードウェアの推奨事項を参照してください。

キャッシュ・サーバーは、通常、com.tangosol.net.Coherenceクラスを使用して起動されます。このクラスには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.Coherence

(オペレーション・オーバーライド・ファイルを変更せずに)構成オーバーライドをシステム・プロパティとして含める場合、javaコマンドに対して-D引数として含めることができます。便利な方法としてCOHERENCE_HOME\bin\cache-serverスクリプトを再利用して適宜変更できます。

GARデプロイメント

Coherenceアプリケーション・アーティファクトは、グリッド・アーカイブ(GAR)としてパッケージ化してDefaultCacheServerクラスでデプロイできます。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

デフォルト名は引数として別の名前を指定することでオーバーライドできます。Oracle Coherenceでのアプリケーションの開発のDefaultCacheServerクラスの概要に関する項を参照してください。アプリケーション・スコープの詳細は、単一クラスタでの複数のアプリケーションの実行を参照してください。

親トピック: スタンドアロン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 -Dcoherence.distributed.localstorage=false -cp APPLICATION_HOME\config;APPLICATION_HOME\lib\myClasses.jar;COHERENCE_HOME\lib\coherence.jar com.MyApp

ノート:

キャッシュ・サーバーへのデプロイメントにGARが使用されている場合、キャッシュ・サービスはアプリケーション・スコープ名によって制限されます。クライアントは同じアプリケーション・スコープ名を使用する必要があります。それ以外の場合、クライアントはキャッシュ・サービスにアクセスできません。単一クラスタでの複数のアプリケーションの実行を参照してください。

親トピック: スタンドアロンCoherenceアプリケーションのデプロイ

Extendクライアント用プロキシ層のデプロイ

プロキシ層はExtendクライアントのリクエストを処理するプロキシ・サーバーから構成されます。プロキシ層では任意の数のプロキシ・サーバーが必要な場合があります。プロキシ・サーバーの数は、予想されるExtendクライアントの数および予想されるクライアントのリクエスト負荷に依存します。各プロキシ・サーバーがクラスタ・メンバーで独自のJVMプロセスを実行し、複数のプロキシ・サーバーを1つの物理サーバー上で連結できます。Oracle Coherenceリモート・クライアントの開発のExtendプロキシ・サービスの定義に関する項を参照してください。

プロキシ・サーバーは、通常、com.tangosol.net.Coherenceクラスを使用して起動されます。このクラスにはmainメソッドが含まれ、コマンド行から起動されます。Oracle Coherenceでのアプリケーションの開発のキャッシュ・サーバーの起動に関する項を参照してください。この点において、プロキシ・サーバーとキャッシュ・サーバーに違いはありません。ただし、キャッシュ・サーバーはデータを格納するように構成されますが、プロキシ・サーバーはデータを格納するように構成されません。

次のアプリケーション・アーティファクトは、プロキシとともにデプロイされることがあります。

オペレーション・オーバーライド構成ファイル、キャッシュ構成ファイルおよびPOFユーザー・タイプ構成ファイルなどの構成ファイル
POFシリアライザおよびドメイン・オブジェクト。ExtendクライアントがC++または.NETを使用して実装されている場合、オブジェクトのJavaバージョンも特定のユース・ケース用にデプロイする必要があります。
問合せ、エントリ・プロセッサ、エントリ・アグリゲータなどのデータ・グリッド処理実装
イベント処理実装

アプリケーション・アーティファクトをプロキシ層にパッケージ化する方法に制限はありません。ただし、アーティファクトはサーバーのクラスパスにあり、すべての構成ファイルがcoherence.jarライブラリの前にある必要があります。それ以外の場合、coherence.jarライブラリにあるデフォルトの構成ファイルがロードされます。次の例では、単一のプロキシ・サーバーがAPPLICATION_HOME\configディレクトリにある構成ファイルを使用して起動し、APPLICATION_HOME\lib\myClassesライブラリにある実装クラスを使用します。

java -server -Xms512m -Xmx512m -Dcoherence.distributed.localstorage=false -cp APPLICATION_HOME\config;APPLICATION_HOME\lib\myClasses.jar;COHERENCE_HOME\lib\coherence.jar com.tangosol.net.Coherence

GARデプロイメント

次の例では、プロキシ・サーバーを起動してMyGar.garファイルにパッケージ化されているアプリケーション・アーティファクトを使用します。デフォルト名(MyGAR)はアプリケーション名として使用され、クラスタ上のアプリケーションの有効範囲を提供します。

java -server -Xms512m -Xmx512m -Dcoherence.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

デフォルト名は引数として別の名前を指定することでオーバーライドできます。Oracle Coherenceでのアプリケーションの開発のキャッシュ・サーバーの起動に関する項を参照してください。アプリケーション・スコープの詳細は、単一クラスタでの複数のアプリケーションの実行を参照してください。

親トピック: スタンドアロンCoherenceアプリケーションのデプロイ

Extendクライアントのデプロイ

ExtendクライアントはJava、C++または.NETアプリケーションとして実装されます。また、RESTクライアントAPIを提供する任意のクライアント・テクノロジでCoherenceクラスタにキャッシング・サービスを使用できます。ExtendクライアントはCoherenceキャッシュを使用するアプリケーションですが、Coherenceクラスタのメンバーではありません。Oracle Coherenceリモート・クライアントの開発のExtendクライアントの構成を参照してください。

次のCoherenceアーティファクトは、Extendクライアントとともにデプロイされることがあります。

オペレーション・オーバーライド構成ファイル、キャッシュ構成ファイルおよびPOFユーザー・タイプ構成ファイルなどの構成ファイル
POFシリアライザおよびドメイン・オブジェクト
問合せ、エントリ・プロセッサ、エントリ・アグリゲータなどのデータ・グリッド処理実装
イベント処理実装

親トピック: スタンドアロンCoherenceアプリケーションのデプロイ

DockerおよびKubernetesでのCoherenceアプリケーションのデプロイ

Oracle CoherenceアプリケーションはDockerコンテナとしてデプロイでき、Kubernetesを使用して調整できます。これらの業界トップの標準により、非常にスケーラブルで簡単に管理できる、最新のクラウドニュートラルなデプロイメント・ソリューションが提供されます。

OracleによりCoherence Kubernetes OperatorがGitHubにリリースされました。operatorはCoherence固有のKubernetesコントローラで、Kubernetesでのコンテナ化されたCoherenceアプリケーションの実行と管理を容易にします。operatorはHelmまたはkubectlを使用してインストールされ、ロギング用にELK (Elasticsearch、LogstashおよびKibana)、監視用にPrometheusおよびGrafanaとの統合機能が提供されます。operatorには、開始に役立つドキュメントおよびサンプルが含まれます。GitHub上のcoherence-kubernetes-operatorプロジェクトを参照してください。

Dockerベースのアプリケーションを構築およびデプロイする方法の詳細は、Coherence Kubernetes Operatorのドキュメントを参照してください。

親トピック: Coherenceアプリケーションのデプロイ

CoherenceアプリケーションのWebLogic Serverへのデプロイ

WebLogic Serverには、WebLogic Serverドメイン内にCoherenceアプリケーションをデプロイして管理できる方法を標準化するCoherence統合機能が含まれています。この統合機能により、管理者は使い慣れたWebLogic Serverコンポーネントとインフラストラクチャ(Java EEスタイルのパッケージ化とデプロイメント、リモート・サーバー管理、サーバー・クラスタ、WebLogic Scripting Tool (WLST)自動化やWebLogicリモート・コンソールからの構成など)を使用して分散Coherence環境の設定ができます。

この項には次のトピックが含まれます:

親トピック: Coherenceアプリケーションのデプロイ

WebLogic Server Coherence統合機能の概要

CoherenceはWebLogic Serverと統合されます。統合により、Coherenceクラスタ・メンバーのライフサイクルを、管理対象サーバーのライフサイクルに合せ、つまり、サーバーJVMの開始と終了に合せてCoherenceクラスタ・メンバーを開始および終了することになります。クラスタの最初のメンバーがクラスタ・サービスを開始し、シニア・メンバーになります。統合の詳細は、Oracle WebLogic Serverクラスタの管理のCoherenceクラスタの構成と管理を参照してください。

その他のJava EEモジュールと同様に、Coherenceは、グリッド・アーカイブ(GAR)という独自のアプリケーション・モジュールをサポートします。GARには、Coherenceアプリケーションのアーティファクトが格納され、デプロイメント・ディスクリプタが含まれています。GARは、その他のJava EEモジュールと同じ方法でデプロイおよびアンデプロイするため、クラスタ・サービス・ライフタイムから分離されます。Coherenceアプリケーションは、サービスの名前空間ごと、およびクラス・ローダーごとに分離されます。

Coherenceは、通常、Weblogic Serverドメイン内への機能的分離を提供する層に設定されます。最も一般的な層は、データをキャッシングするためのデータ層およびキャッシュされたデータを使用するためのアプリケーション層です。プロキシ・サーバー層およびExtendクライアント層は、Coherence*Extendを使用する際に設定する必要があります。HTTPセッション層は、Coherence*Webを使用する際に設定する必要があります。Oracle Coherence*WebでのHTTPセッション・マネージメントの管理のWebLogic ServerでのCoherence*Webの使用方法を参照してください。

Coherenceクラスタに関連付けられたWebLogic管理対象サーバーは、管理対象Coherenceサーバーと呼ばれます。各層内の管理対象Coherenceサーバーは個別に管理することもできますが、通常はそれぞれのWebLogicサーバー・クラスタに関連付けられます。GARは、データ層サーバーおよびプロキシ層サーバーごとにデプロイする必要があります。その後で、同一のGARは1つのEAR内にパッケージ化し、それぞれのアプリケーションおよびExtendクライアント層サーバーにデプロイします。クライアント層とは別の専用の記憶域層を使用することが、最適なパフォーマンスを実現するためのベスト・プラクティスになります。

親トピック: CoherenceアプリケーションのWebLogic Serverへのデプロイ

WebLogic Server用のCoherenceアプリケーションのパッケージ化

Coherenceアプリケーションは、GARモジュールとしてデプロイメントするためにパッケージ化する必要があります。GARモジュールは、Coherenceアプリケーションから成るアーティファクトを含み、特定のディレクトリ構造を保持します。GARは、アーカイブ化解除されたディレクトリとして残すことも、.gar拡張子を付けてアーカイブ化することもできます。GARは、スタンドアロン・モジュールとしてデプロイするか、EAR内にデプロイします。EARは複数のGARモジュールを含むことができません。

この項には次のトピックが含まれます:

親トピック: CoherenceアプリケーションのWebLogic Serverへのデプロイ

Coherence GARモジュールの構築

Coherence GARモジュールを構築するには:

次のGARディレクトリ構造を作成します。
```
/
/lib/
/META-INF/
```
Coherenceキャッシュ構成ファイルと、POF構成ファイル(必要な場合)をGAR内のディレクトリに追加します。たとえば:
```
/
/lib/
/META-INF/coherence-cache-config.xml
/META-INF/pof-config.xml
```
ノート:

構成ファイルは、GARのルート・ディレクトリに格納しないでください。構成ファイルがルート・ディレクトリに格納されている場合は、ここに示したデフォルト名は使用しません。そのかわりに、これらの構成ファイルはシステム・クラスパス内に格納されたcoherence.jarファイルからロードされます。
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>
```
ノート:
- 構成ファイルは、GARにローカルにコピーするかわりに、ネットワーク上に格納してURLで参照できます。
- キャッシュ構成ファイルは実行時にクラスタ・キャッシュ構成ファイルでオーバーライドできます。Oracle WebLogic Serverクラスタの管理のキャッシュ構成ファイルのオーバーライドを参照してください。
- キャッシュ構成ファイルは実行時にJNDIプロパティを使用してオーバーライドすることもできます。Oracle WebLogic Server Oracle Coherenceアプリケーションの開発のJNDIの使用による構成のオーバーライドを参照してください。
すべてのCoherenceアプリケーションのJavaクラス(エントリ・プロセッサ、アグリゲータ、フィルタなど)を該当パッケージ構造内のルート・ディレクトリに配置します。
すべてのライブラリ依存性を/libディレクトリに格納します。
ルート・ディレクトリからJavaのjarコマンドを使用して、.gar拡張子を付けてアーカイブを圧縮します。たとえば:
```
jar cvf MyApp.gar *
```

親トピック: WebLogic Server用のCoherenceアプリケーションのパッケージ化

GARモジュールのEARモジュール内へのパッケージ化

GARモジュールは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>

親トピック: WebLogic Server用のCoherenceアプリケーションのパッケージ化

Coherence用のWebLogic Serverドメイン・トポロジの設定

この項には次のトピックが含まれます:

親トピック: CoherenceアプリケーションのWebLogic Serverへのデプロイ

ドメイン・トポロジの設定のガイドライン

CoherenceはWebLogic Serverドメインの各種ドメイン・トポロジをサポートすることで、様々なレベルのパフォーマンス、スケーラビリティおよび使いやすさを実現します。たとえば、開発時には単一の管理対象Coherenceサーバー・インスタンスを、キャッシュ・サーバーとしても、キャッシュ・クライアントとしても使用できます。単一サーバー・トポロジは、設定と使用が容易ですが、最適なパフォーマンスまたはスケーラビリティを提供しません。本番の場合、Coherenceは、通常、WebLogic Serverクラスタを使用して設定します。1つのWebLogic Serverクラスタが、Coherenceデータ層として使用され、1つ以上のキャッシュ・サーバーをホストします。Coherenceアプリケーション層には別のWebLogic Serverクラスタが使用され、1つ以上のキャッシュ・クライアントをホストします。そして、(必要な場合) 1つ以上の管理対象Coherenceプロキシ・サーバーをホストするCoherenceプロキシ層、および拡張クライアントをホストするCoherence拡張クライアント層には、さらに別のWebLogic Serverクラスタが使用されます。階層型トポロジのアプローチにより、最適なスケーラビリティとパフォーマンスが提供されます。ドメイン・トポロジは、常にアプリケーションの要件に基づいている必要があります。

Coherence用のドメイン・トポロジを作成する際には、次のガイドラインを使用してください。

ドメインは、通常、単一のCoherenceクラスタを含んでいます。
1つのCoherenceクラスタには、複数のWebLogic Serverクラスタを関連付けることができます。
Coherenceクラスタに関連付けられた管理対象サーバーは、管理対象Coherenceサーバーとみなされ、Coherenceクラスタ・メンバーと同じになります。
別の管理対象Coherenceサーバー・インスタンス(可能ならば別のWebLogic Serverクラスタ)を使用して、Coherenceのキャッシュ・サーバーとクライアントを分離します。
WebLogic Serverドメイン内で管理されるCoherenceメンバーは、スタンドアロンのJVMメンバーで構成される外部のCoherenceクラスタに参加してはいけません。スタンドアロンのJVMクラスタ・メンバーを、WebLogic Serverドメイン内で管理することはできません。

親トピック: Coherence用のWebLogic Serverドメイン・トポロジの設定

Coherenceクラスタの作成

WebLogicリモート・コンソールを使用して、Coherenceクラスタを作成するには:

「ツリーの編集」で、「環境」、「Coherenceクラスタ」の順に移動します。
「新規」をクリックします。
Coherenceクラスタの名前を入力して、「作成」をクリックします。
新しいCoherenceクラスタが「Coherenceクラスタ」ノードの下に表示されます。必要に応じて、このページでアプリケーションに追加の変更を加えます。構成オプションの詳細は、Oracle WebLogicリモート・コンソール・オンライン・ヘルプのCoherenceクラスタの構成に関する項を参照してください。
「保存」をクリックします。
変更をコミットします。

親トピック: Coherence用のWebLogic Serverドメイン・トポロジの設定

Coherenceデプロイメント層の作成

WebLogic ServerドメインでCoherenceを設定する際に優先されるアプローチでは、Coherenceキャッシュ・サーバー、クライアントおよびプロキシを、同じCoherenceクラスタに関連付けられた異なる層に分割します。一般に、各層は管理対象Coherenceサーバーの独自のWebLogic Serverクラスタに関連付けられます。ただし、1つの層が複数のスタンドアロン管理対象Coherenceサーバーから構成されていることもあります。前者のアプローチを使用すると、Coherenceの管理とスケールは最も簡単になります。これは、管理対象CoherenceサーバーはWebLogic ServerクラスタのCoherence設定を継承してデプロイメントできるためです。この項の手順を使用して、データ層、アプリケーション層およびプロキシ層に個別のWebLogic Serverクラスタを作成します。Oracle WebLogic Serverクラスタの管理のCoherenceクラスタの構成と管理を参照してください。

WebLogicリモート・コンソールを使用してCoherenceデプロイメント層を作成するには:

WebLogic Serverクラスタを作成します。
1. 「ツリーの編集」で、「環境」、「クラスタ」の順に移動します。
2. 「新規」をクリックします。
3. クラスタの名前を入力します。
4. 「作成」をクリックします。
作成したWebLogic Serverクラスタで、「詳細」タブ、「Coherence」サブタブに移動します。
「Coherenceクラスタ・システム・リソース」ドロップダウン・リストから、Coherenceクラスタを選択します。
作成するデプロイメント層のタイプに応じて、「ローカル記憶域有効」オプションを有効または無効にします。
- データ層の場合: 「ローカル記憶域有効」を有効にします。この層に割り当てられた管理対象Coherenceサーバーは、記憶域が有効なCoherenceメンバー(キャッシュ・サーバー)です。
- アプリケーション層の場合: 「ローカル記憶域有効」を無効にします。この層に割り当てられた管理対象Coherenceサーバーは、記憶域が無効なCoherenceメンバー(キャッシュ・クライアント)です。
- プロキシ層の場合: 「ローカル記憶域有効」を無効にします。この層に割り当てられた管理対象Coherenceサーバーは、記憶域が無効なCoherenceメンバーです。
- Extendクライアント層: 「ローカル記憶域有効」を無効にします。この層に割り当てられた管理対象Coherenceサーバーは、記憶域が無効なCoherenceメンバーです。
「保存」をクリックします。
ステップ1から5を繰り返して、トポロジに必要なその他のデプロイメント層タイプを作成します。
変更をコミットします。

親トピック: Coherence用のWebLogic Serverドメイン・トポロジの設定

Coherenceデプロイメント層用の管理対象Coherenceサーバーの作成

Coherenceクラスタに関連付けられた管理対象サーバーは、Coherenceクラスタのメンバーになり、管理対象Coherenceサーバーと呼ばれます。この項の手順を使用して、管理対象サーバーを作成し、そのサーバーをWebLogic Serverクラスタに関連付けます。このクラスタは、Coherenceデプロイメント層として構成します。管理対象サーバーは、WebLogic ServerクラスタからCoherence設定を自動的に継承します。同様に、既存の管理対象CoherenceサーバーもWebLogic Serverクラスタに関連付けできます。

WebLogicリモート・コンソールを使用してCoherenceデプロイメント層用管理対象サーバーを作成するには:

「ツリーの編集」で、「環境」、「サーバー」の順に移動します。
「新規」をクリックします。
新しいサーバーの名前を入力します。
オプション: 設定を既存のサーバーから新しいサーバーにコピーする場合は、「別のサーバーから設定をコピー」ドロップダウン・リストからサーバーを選択します。

サーバーの設定のみがコピーされます。チャネルなどの子はコピーされません。WebLogic Server REST APIでサポートされていない設定もコピーされません。
「作成」をクリックします。
作成した管理対象サーバーで、「クラスタ」ドロップダウン・リストから、Coherenceデプロイメント層として機能するクラスタを選択します。
「保存」をクリックします。
ステップ1から7を繰り返して、残りのデプロイメント層に管理対象Coherenceサーバーを追加します。
変更をコミットします。

親トピック: Coherence用のWebLogic Serverドメイン・トポロジの設定

CoherenceアプリケーションのWebLogic Serverドメインへのデプロイ

この項には次のトピックが含まれます:

親トピック: CoherenceアプリケーションのWebLogic Serverへのデプロイ

WebLogic Serverドメイン・デプロイメントの概要

各Coherenceデプロイメント層には、Coherenceアプリケーション・モジュールを含める必要があります。アプリケーション・モジュールのデプロイで、GARのキャッシュ構成ファイルに定義されたサービスが開始します。WebLogic Server用のCoherenceアプリケーションのパッケージ化を参照してください。

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クラスタの管理のキャッシュ構成ファイルのオーバーライドに関する項を参照してください。

親トピック: CoherenceアプリケーションのWebLogic Serverドメインへのデプロイ

データ層GARのデプロイ

WebLogicリモート・コンソールを使用してデータ層にGARをデプロイするには:

「ツリーの編集」で、「デプロイメント」、「アプリケーション・デプロイメント」の順に移動します。
「新規」を選択します。
アプリケーションの名前を入力します。通常、これはGARファイルの名前と同じです。
「ターゲット」フィールドから、データ層を表すクラスタを「選択済」の下に移動します。
GARを管理サーバーに認識させます。次のいずれかのオプションを選択します。
- アプリケーションがファイル・システム上にあり、管理サーバーへのアップロードが必要な場合は、「アップロード」を有効にします。次に、「ソース」の横にある「ファイルの選択」をクリックして、システム上のアプリケーションの場所を参照します。
- アプリケーションがすでに管理サーバーのファイル・システムにある場合は、「アップロード」を無効にします。次に、「ソース・パス」に、アプリケーションへのファイル・パスを入力します。
「デプロイメント時」ドロップダウン・リストから、「アプリケーションの起動」を選択します。
「作成」をクリックします。
新しいGARが「アプリケーション・デプロイメント」ノードの下に表示されます。必要に応じて、このページでアプリケーションに追加の変更を加えます。
変更を保存してコミットします。

親トピック: CoherenceアプリケーションのWebLogic Serverドメインへのデプロイ

アプリケーション層EARのデプロイ

WebLogicリモート・コンソールを使用してアプリケーション層にEARをデプロイするには:

「ツリーの編集」で、「デプロイメント」、「アプリケーション・デプロイメント」の順に移動します。
「新規」を選択します。
アプリケーションの名前を入力します。通常、これはEARファイルの名前と同じです。
「ターゲット」フィールドから、アプリケーション層を表すクラスタを「選択済」の下に移動します。
EARを管理サーバーに認識させます。次のいずれかのオプションを選択します。
- アプリケーションがファイル・システム上にあり、管理サーバーへのアップロードが必要な場合は、「アップロード」を有効にします。次に、「ソース」の横にある「ファイルの選択」をクリックして、システム上のアプリケーションの場所を参照します。
- アプリケーションがすでに管理サーバーのファイル・システムにある場合は、「アップロード」を無効にします。次に、「ソース・パス」に、アプリケーションへのファイル・パスを入力します。
「デプロイメント時」ドロップダウン・リストから、「アプリケーションの起動」を選択します。
「作成」をクリックします。
新しいEARが「アプリケーション・デプロイメント」ノードの下に表示されます。必要に応じて、このページでアプリケーションに追加の変更を加えます。
変更を保存してコミットします。

親トピック: CoherenceアプリケーションのWebLogic Serverドメインへのデプロイ

プロキシ層GARのデプロイ

WebLogicリモート・コンソールを使用してGARをプロキシ層にデプロイするには:

「ツリーの編集」で、「デプロイメント」、「アプリケーション・デプロイメント」の順に移動します。
「新規」を選択します。
アプリケーションの名前を入力します。通常、これはGARファイルの名前と同じです。
「ターゲット」フィールドから、プロキシ層を表すクラスタを「選択済」の下に移動します。
GARを管理サーバーに認識させます。次のいずれかのオプションを選択します。
- アプリケーションがファイル・システム上にあり、管理サーバーへのアップロードが必要な場合は、「アップロード」を有効にします。次に、「ソース」の横にある「ファイルの選択」をクリックして、システム上のアプリケーションの場所を参照します。
- アプリケーションがすでに管理サーバーのファイル・システムにある場合は、「アップロード」を無効にします。次に、「ソース・パス」に、アプリケーションへのファイル・パスを入力します。
「デプロイメント時」ドロップダウン・リストから、「アプリケーションの起動」を選択します。
「作成」をクリックします。
新しいGARが「アプリケーション・デプロイメント」ノードの下に表示されます。必要に応じて、このページでアプリケーションに追加の変更を加えます。
変更を保存してコミットします。

親トピック: CoherenceアプリケーションのWebLogic Serverドメインへのデプロイ

基本的なCoherence管理タスクの実行

管理者は、WebLogic Serverツールを使用して、WebLogicドメイン内のCoherence環境を管理します。これらのツールを使用すると、クラスタやクラスタ・メンバーの管理タスクが簡単になります。この項では、WebLogicリモート・コンソールを使用して基本的な管理タスクを実行する方法の概要について説明します。Oracle WebLogicリモート・コンソール・オンライン・ヘルプのCoherenceの構成に関する項を参照してください。多くの作業は、WebLogic Scripting Tool (WLST)を使用して実行することもできます。WebLogic Scripting Toolの理解のWebLogic Scripting Toolの使用を参照してください。

表1-1 WebLogicリモート・コンソールでの基本的な管理タスク

目的	移動...
Coherenceクラスタの作成	ツリーの編集: 環境: Coherenceクラスタ。
クラスタ・メンバーの追加または削除、またはCoherenceクラスタからのWebLogic Serverクラスタの追加または削除	ツリーの編集: 環境: Coherenceクラスタ: myCoherenceCluster: メンバー(タブ)。
Coherenceクラスタのユニキャスト設定またはマルチキャスト設定の構成	ツリーの編集: 環境: Coherenceクラスタ: myCoherenceCluster: 一般(タブ)。ユニキャストを選択した場合、デフォルトのウェル・ノウン・アドレス構成は、ウェル・ノウン・アドレス・ノードを使用してオーバーライドできます。
Coherenceクラスタを構成するためのカスタム構成ファイルの使用	ツリーの編集: 環境: Coherenceクラスタ: myCoherenceCluster: 一般(タブ)。「構成のインポート」をクリックし、管理サーバー上でローカルに存在する必要があるクラスタ構成ファイルのファイルの場所を入力します。
クラスタ・メンバーへのキャッシュ構成ファイルのインポート、およびGARにデプロイしたキャッシュ構成ファイルのオーバライド	ツリーの編集: 環境: Coherenceクラスタ: myCoherenceCluster: 「Coherenceキャッシュ構成」ノード。
ロギングの構成	ツリーの編集: 環境: Coherenceクラスタ: myCoherenceCluster: ロギング(タブ)。
Coherenceクラスタへの管理対象サーバーの割当て	ツリーの編集: 環境: サーバー: myManagedServer: 詳細(タブ): Coherence(サブタブ)。
Coherenceクラスタ・メンバーのプロパティの構成	ツリーの編集: 環境: サーバー: myManagedServer: 詳細(タブ): Coherence(サブタブ)。
WebLogic ServerクラスタとCoherenceクラスタとの関連付け、およびクラスタの管理対象Coherenceサーバーの記憶域の有効化または無効化	ツリーの編集: 環境: クラスタ: myCluster: Coherence(タブ)。
Coherenceクラスタに関連付けられたWebLogic Serverクラスタへの管理対象サーバーの割当て	ツリーの編集: 環境: サーバー: myManagedServer: 一般(タブ)。

親トピック: CoherenceアプリケーションのWebLogic Serverへのデプロイ

Coherenceアプリケーションのアプリケーション・サーバー(汎用)へのデプロイ

WebLogic Server以外のアプリケーション・サーバーにデプロイされるJava EEアプリケーションには、Coherenceをデプロイするための2つのオプション(アプリケーション・サーバー・ライブラリとして、またはJava EEモジュールの一部としてデプロイ)があります。

Coherenceクラスタのメンバーにはクラス・ローダーのスコープが設定されています。そのため、オプションの選択によってデプロイメント・シナリオが異なります。Coherenceがアプリケーション・サーバー・ライブラリとしてデプロイされている場合、すべてのモジュールは単一のクラスタ・メンバーを共有します。その一方で、Coherenceがモジュールの一部としてデプロイされている場合、Java EEモジュールは、そのモジュール自体がクラスタ・メンバーになります。どちらのオプションにも利点と前提条件があり、一般的にクラスタ・メンバーが他のモジュールから分離されている程度とリソース利用率とのバランスが取られます。

ノート:

Coherence*Webデプロイメントについては、Oracle Coherence*WebでのHTTPセッション・マネージメントの管理の他のアプリケーション・サーバーにおけるCoherence*Webの使用方法を参照してください。

この項には次のトピックが含まれます:

親トピック: Coherenceアプリケーションのデプロイ

アプリケーション・サーバー・ライブラリとしてのCoherenceのデプロイ

Coherenceをアプリケーション・サーバー・ライブラリとしてデプロイできます。このデプロイメント・シナリオでは、アプリケーション・サーバーの起動クラスパスをCOHERENCE_HOME/lib/coherence.jarライブラリが含まれるように変更します。また、キャッシュに配置するオブジェクトはすべて、サーバーのクラスパスで使用できる必要があります。ライブラリをサーバーのクラスパスに追加する手順は、アプリケーション・サーバーのベンダーのドキュメントを参照してください。

このシナリオでは、サーバーのコンテナにデプロイされたすべてのアプリケーションで1つのクラスタ・メンバーを共有するようになります。このシナリオでは、Coherenceクラスの1つのコピーのみがJVMにロードされるため、リソース使用率が最小限に抑えられます。単一クラスタでの複数のアプリケーションの実行を参照してください。

親トピック: Coherenceアプリケーションのアプリケーション・サーバー(汎用)へのデプロイ

Java EEモジュール内へのCoherenceのデプロイ

CoherenceをEARファイルまたはWARファイル内にデプロイできます。一般に、このデプロイメント・スタイルは、アプリケーション・サーバーの実行時環境に変更を加える必要がなく、クラスタ・メンバーはEARまたはWARのどちらかに分離されているため、優先的に選択されます。

この項には次のトピックが含まれます:

親トピック: Coherenceアプリケーションのアプリケーション・サーバー(汎用)へのデプロイ

EAR内へのCoherenceのデプロイ

CoherenceをEARの一部としてデプロイできます。このデプロイメント・シナリオでは、EAR内のすべてのWebアプリケーションで1つのクラスタ・メンバーを共有することになります。EARごとにCoherenceクラスのコピーが1つのみロードされるため、リソース使用率は中程度になります。ただし、クラスタ・メンバーによる、いずれか1つのモジュールの使用が、すべてのWebアプリケーションに影響を与える可能性があります。単一クラスタでの複数のアプリケーションの実行を参照してください。

Coherenceをエンタープライズ・アプリケーション内にデプロイするには:

coherence.jarライブラリを、エンタープライズ・アプリケーションのディレクトリ構造内の任意の場所にコピーします。
テキスト・エディタを使用して、META-INF/application.xmlデプロイメント・ディスクリプタを開きます。
アプリケーション・ディレクトリの最上位に対する相対パスおよびCoherenceライブラリの名前が含まれる<java>要素を追加します。たとえば:
```
<application>
   <display-name>MyApp</display-name>
   <module>
      <java>coherence.jar</java>
   </module>
   ...
</application>
```
キャッシュに配置するオブジェクトすべてを前述の方法でアプリケーションに追加します。
ディスクリプタを保存して閉じます。
アプリケーションをパッケージ化してデプロイします。

親トピック: Java EEモジュール内へのCoherenceのデプロイ

WAR内へのCoherenceのデプロイ

CoherenceをWebアプリケーションの一部としてデプロイできます。このデプロイメント・シナリオでは、それぞれのWebアプリケーションが固有のクラスタ・メンバーを持ち、他のすべてのWebアプリケーションから分離されるようになります。このシナリオでは、Coherenceを含むWebアプリケーションがデプロイされる数と同じ数のCoherenceクラスのコピーがロードされるため、リソースを最も大量に使用します。このシナリオは、1つのアプリケーション・サーバーに数個のWebアプリケーションのみをデプロイする場合に適しています。

CoherenceをWebアプリケーション内にデプロイするには:

WebアプリケーションのWEB-INF/libディレクトリにcoherence.jarライブラリをコピーします。
キャッシュに配置するすべてのオブジェクトが、WEB-INF/libディレクトリまたはWEB-INF/classesディレクトリに配置されていることを確認します。
アプリケーションをパッケージ化してデプロイします。

親トピック: Java EEモジュール内へのCoherenceのデプロイ

単一クラスタでの複数のアプリケーションの実行

Coherenceは、独自の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内のアプリケーションのスコープ設定

WebLogic Serverにデプロイするときには、デプロイされた複数のCoherenceアプリケーション(GAR)が、サービスの名前空間ごと、およびデフォルトのClassLoaderごとにWebLogic Server内で分離されるため、スコープ名の構成は必要ありません。ただし、スコープ名はGAR間でキャッシュを共有するために構成することもできます。キャッシュ構成ファイルでのスコープの直接構成は、通常、上級ユーザー・ケースで実行されます。

ノート:

複数のGARを同じスコープ名でデプロイする場合、すべてのGARで同一の構成ファイルを使用する必要があります。そうでない場合、デプロイは失敗します。

デプロイメント名は、GARのデプロイ時にデフォルトのスコープ名として使用されます。デプロイメント名がデプロイ中に指定されない場合、アーティファクト名がデプロイメント名として使用されます。たとえば、MyApp.garモジュールの場合、デフォルトのデプロイメント名はMyAppです。EARにパッケージ化されたGARの場合、デプロイメント名はweblogic-application.xmlファイルのGARに指定されたモジュール名です。

親トピック: 単一クラスタでの複数のアプリケーションの実行

Java EE環境(汎用)内のアプリケーションのスコープ設定

アプリケーション・サーバー・ライブラリまたはEARの一部としてCoherenceをデプロイすると、複数のアプリケーションが単一のクラスタ・メンバー(1つのJVM)として同一のクラスタを使用できます。このようなデプロイメント・シナリオでは、複数のアプリケーションが、単一のcoherence-cache-config.xmlファイルで構成された1つのCoherenceのキャッシュとサービスのセットを使用することを選択できます。このタイプのデプロイメントは、アプリケーションのデプロイメントが調整された制御環境においてのみお薦めします(また、その場合にのみ実用的になります)。キャッシュ間、サービス間およびその他の構成設定間で衝突する可能性が高く、想定外の結果を招くことがあります。さらに、Coherenceノードの1つのアプリケーションの使用が、すべてのアプリケーションに影響を及ぼす可能性もあります。

別の方法として、各アプリケーションに独自のキャッシュ構成ファイルを含めるようにします。この構成ファイルでは、そのアプリケーションに固有のキャッシュとサービスを定義します。この構成は、キャッシュ構成ファイル内の<scope-name>要素を使用して指定したスコープ名で分離されます。同様に、アプリケーションは、その他のアプリケーションが必要とするときにはキャッシュとサービスの共有を明示的に許可できます。このシナリオでは、それぞれが1つのアプリケーションに関連する複数のConfigurableCacheFactoryインスタンスが、1つのJVMに含まれていることを想定しています。

この項には次のトピックが含まれます:

親トピック: 単一クラスタでの複数のアプリケーションの実行

Java EE環境内のアプリケーションの分離

次の例では、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ディレクトリ内にあります)に含まれていることを確認します。これにより、アプリケーションは実行時に構成ファイルをロードして使用できるようになります。

親トピック: Java EE環境(汎用)内のアプリケーションのスコープ設定

Java EE環境内のアプリケーション・データの共有

各アプリケーションは、それらのキャッシュとサービスへのアクセスを許可することで、データを共有できます。次の例では、Webアプリケーション(trade.war)が別のアプリケーション(accounts.war)のキャッシュとサービスにアクセスできるようにする手順を示します。

<?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>
   ...

<?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);

親トピック: Java EE環境(汎用)内のアプリケーションのスコープ設定

スタンドアロン環境内のアプリケーションのスコープ設定

単一のCoherenceクラスタを使用するスタンドアロン・アプリケーションには独自のキャッシュ構成ファイルを含めることができますが、これらの構成は単一のConfigurableCacheFactoryに結合されます。ConfigurableCacheFactoryとDefaultCacheServerの間には1対1の関係があるため、単一のクラスタ・ノード内でアプリケーションのスコープを設定できません。そのかわりに、DefaultCacheServerの1つ以上のインスタンスはキャッシュ構成ごとに開始される必要があり、各キャッシュ構成にスコープ名を含める必要があります。

次の例では、2つのアプリケーション(tradeおよび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>trade</scope-name>
      </defaults>
   ...

DefaultCacheServerインスタンスを開始します。このインスタンスは、trade-cache-config.xmlキャッシュ構成ファイルをロードします。

<?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>

親トピック: 単一クラスタでの複数のアプリケーションの実行