コンテナー・サーバーの自動始動のための WebSphere Application Server アプリケーションの構成

WebSphere® Application Server 環境内のコンテナー・サーバーは、eXtreme Scale XML ファイルを組み込んだモジュールが開始されると自動的に開始されます。

始める前に

WebSphere Application Server および WebSphere eXtreme Scale をインストールする必要があります。さらに、WebSphere Application Server 管理コンソールにアクセスできなければなりません。

このタスクについて

Java Platform, Enterprise Edition アプリケーションのクラス・ローダー規則は複雑であるため、Java EE サーバー内で共有データ・グリッドを使用しているときは、ロード元クラスが非常に複雑になります。 A Java EE アプリケーションは通常、単一のエンタープライズ・アーカイブ (EAR) ファイルです。EAR ファイルには、1 つ以上のデプロイされた Enterprise JavaBeans (EJB) モジュールまたは Web アーカイブ (WAR) モジュールが含まれます。

WebSphere eXtreme Scale は各モジュールの開始を監視し、eXtreme Scale XML ファイルを検査します。 カタログ・サービスが、XML ファイルによるモジュールの開始を検出すると、アプリケーション・サーバーはコンテナー・サーバー Java 仮想マシン (JVM) として登録されます。 コンテナー・サーバーをカタログ・サービスに登録することにより、異なるデータ・グリッドに同じアプリケーションをデプロイできますが、カタログ・サービスで単一データ・グリッドとして使用されます。 カタログ・サービスは、セル、グリッド、または動的グリッドとの関連はありません。必要に応じて、単一のデータ・グリッドを複数のセルに分散させることができます。

手順

  1. META-INF フォルダーに eXtreme Scale XML ファイルが含まれるモジュールを持つように EAR ファイルをパッケージ化します。 WebSphere eXtreme Scale は、EJB および WEB モジュールが開始されると、これらのモジュールの META-INF フォルダーで objectGrid.xml および objectGridDeployment.xml ファイルの存在を検出します。 objectGrid.xml ファイルのみが検出されると、JVM はクライアントと見なされます。その他の場合は、この JVM が objectGridDeployment.xml ファイルで定義されているデータ・グリッドのコンテナーであると見なされます。

    これらの XML ファイルの正しい名前を使用しなければなりません。 ファイル名には大/小文字の区別があります。 これらのファイルが存在しないと、コンテナーは開始されません。 断片が配置されることを示すメッセージは systemout.log ファイルで確認することができます。 eXtreme Scale を使用する EJB モジュールまたは WAR モジュールの META-INF ディレクトリーに eXtreme Scale XML ファイルがなければなりません。

    eXtreme Scale XML ファイルには以下のものがあります。 ランタイムはこれらのファイルを検出し、カタログ・サービスに連絡して、別のコンテナーを使用してこの eXtreme Scale の断片をホストできることを通知します。
    ヒント: アプリケーションにエンティティーがあり、1 つのコンテナー・サーバーを使用する計画であれば、デプロイメント記述子 XML ファイルの中の minSyncReplicas 値を 0 に設定します。そうしないと、別のサーバーが minSyncReplica ポリシーを満たしはじめるまで配置を行えないため、 SystemOut.log ファイル内に以下のメッセージのいずれかが記録される可能性があります。
    CWPRJ1005E: Error resolving entity association. Entity=entity_name,
    association=association_name.
    (エンティティー関連の解決中にエラーが発生しました。
    エンティティー=entity_name、関連=association_name)
    CWOBJ3013E: The EntityMetadata repository is not available.  Timeout
    threshold reached when trying to register the entity: entity_name.
    (EntityMetadata リポジトリーを使用できません。
    エンティティー entity_name の登録試行中にタイムアウトしきい値に到達しました)
  2. アプリケーションをデプロイして開始します。

    モジュールが開始されると、コンテナーが自動的に開始されます。 カタログ・サービスが開始され、できるだけ速やかに区画のプライマリーおよびレプリカ (断片) が配置されます。 配置を遅らせるように環境を構成していない限り、この配置は直ちに行われます。詳しくは、配置の制御を参照してください。

次のタスク

コンテナーと同じセル内にあるアプリケーションは、ObjectGridManager.connect(null, null) メソッドを使用してこれらのデータ・グリッドに接続した後、getObjectGrid(ccc, "object grid name") メソッドを呼び出すことができます。 connect または getObjectGrid メソッドはコンテナーが断片の配置を完了するまでブロックされることがありますが、このブロックはデータ・グリッドが開始されるときだけ問題となります。

ClassLoader

eXtreme Scale に格納されたプラグインまたはオブジェクトは、特定のクラス・ローダーにロードされます。 ロードされたオブジェクトは、同じ EAR 内の 2 つの EJB モジュールに含めることができます。これらのオブジェクトは同じですが、別の ClassLoader を使用してロードされています。アプリケーション A が、サーバーに対してローカルなマップに Person オブジェクトを保管した場合、アプリケーション B がこのオブジェクトを読み取ろうとすると、ClassCastException を受け取ります。この例外は、アプリケーション B が Person オブジェクトを別のクラス・ローダーにロードしたために発生します。

この問題を解決する方法の 1 つは、eXtreme Scale に格納された必要なプラグインおよびオブジェクトをルート・モジュールが含むようにすることです。 eXtreme Scale を使用する各モジュールは、ルート・モジュール内でクラスを参照する必要があります。 もう 1 つの解決方法は、これらの共有オブジェクトを、モジュールとアプリケーションの両方が共有する共通クラス・ローダー上のユーティリティー JAR ファイル内に配置することです。 オブジェクトは、WebSphere クラスまたは lib/ext ディレクトリーにも配置できますが、この配置ではデプロイメントが複雑になります。

EAR ファイル内の EJB モジュールは通常、同じ ClassLoader を共有するため、この問題の影響を受けません。 各 WAR モジュールには独自の ClassLoader があり、この問題の影響を受けます。

データ・グリッド・クライアントのみに接続

catalog.services.cluster プロパティーがセル、ノード、またはサーバー・カスタム・プロパティーで定義されている場合は、EAR ファイル内のすべてのモジュールが ObjectGridManager.connect (ServerFactory.getServerProperties().getCatalogServiceBootstrap(), null, null) メソッドを呼び出して ClientClusterContext を取得できます。このモジュールはまた ObjectGridManager.getObjectGrid(ccc, "grid name") メソッドを呼び出して、データ・グリッドの参照を取得できます。アプリケーション・オブジェクトがマップに格納されている場合は、それらのオブジェクトが共通の ClassLoader に存在することを確認してください。

Java クライアントまたはセル外のクライアントは、カタログ・サービスのブートストラップ IIOP ポートと接続できます。WebSphere Application Server の中で、デプロイメント・マネージャーは、デフォルトでカタログ・サービスをホストします。そして、クライアントは、ClientClusterContext と指定されたデータ・グリッドを取得できます。

エンティティー・マネージャー

エンティティー・マネージャーを使用すると、タプルはアプリケーション・オブジェクトではなくマップに保管され、クラス・ローダーが少なくなるという問題が発生します。ただし、プラグインが問題になることがあります。 また、エンティティー (ObjectGridManager.connect("host:port[,host:port], null, objectGridOverride) または ObjectGridManager.connect(null, objectGridOverride)) が定義されているデータ・グリッドに接続するときは、クライアント・オーバーライド ObjectGrid 記述子 XML ファイルが常に必要となることにも注意してください。