次の図は単純なシナリオで、ノードが 2 つあり、ノードごとに アプリケーション・サーバーが 1 台配置されているクラスター構成を示したものです。 この図が表しているのは、エンタープライズ Bean のワークロード管理の例で、 2 つのエンタープライズ Bean を持つ Java 2 Platform Enterprise Edition (J2EE) アプリケーションを含んでいます。
この場合、各クライアント要求はエンタープライズ Bean クライアントから ORB および WLM プラグインを経由して EJB1 に送付されます。 これがエンタープライズ Bean インスタンス間で交互に行われます。 どちらの EJB1 インスタンスもクラスターで活動状態になっていますが、2 つとも一意ではなく、 作業はクライアントの介入なしに両インスタンス間でやり取りされます。 要求を共有する機能はスケーラビリティーに役立ちますが、通常 のトランザクションの実行中に各エンティティーにロードされた同一のデータを 安全に管理し、その後データベースに複製データを戻すには暗黙の限界と制約が存在します。 エンタープライズ Bean コンテナー、リレーショナル・リソース・アダプター、およびその他の WebSphere コンポーネントに用意されている不可視機能により、データ破壊の可能性はなくなりますが、 これらの機能性によりシステムのパフォーマンスを確実に低下させます。 ワークロードによってはこのパフォーマンス・コストが比較的高くなり、 これを回避できるアプリケーション・スタイルが複数存在します。
Extended Deployment サーバーおよびデータベース・サーバーでは、複数の エンティティー Bean インスタンスで同一のデータを共有するための機能が実行されます。 区画化機能 (WPF) の目標の 1 つは、クラスターの単一のエンドポイントで特定のインスタンス向けの データをすべて処理し、これらのセマンティクスを実施できるように WebSphere および データベース・サーバーの負荷を軽減して、システム全体のスケーラビリティーとスループットを 大幅に向上させることです。 現時点で、WebSphere Application Server および Extended Deployment のエンティティー Bean 開発者が使用できるのは、オプション A の排他的アクセスが許可されていないため、オプション B および C のみです。
Related concepts
EJB ワークロードの区画化