BeenThere サンプルの技術情報


ソース・コードの場所
コーディング・メモのレビュー


ソース・コードの場所

BeenThere アプリケーションのソース・コードは、profile_root/samples/src/BeenThere ディレクトリーにあります。 ここで、<profile_root> は、デプロイメント・マネージャー・プロファイルの完全修飾パスです。

z/OS カスタマー: サンプル・アプリケーションは z/OS プラットフォームでは 構築されないため、サンプルのソース・コード・ツリーは z/OS プラットフォームでは提供されません。



コーディング・メモのレビュー

概説

BeenThere アプリケーションは、IBM WebSphere Application Server Network Deployment Edition のワークロード管理 (WLM) 機能を デモンストレーションします。BeenThere アプリケーションには、BeenThere サーブレットおよび BeenThere ステートレス・セッション・エンタープライズ Bean が 含まれています。BeenThere サーブレットは、HTTP 要求がディスパッチされた先のクラスター内の アプリケーション・サーバーをデモンストレーションします。BeenThere エンタープライズ Bean は、 エンタープライズ Bean 要求がディスパッチされた先のクラスター内のアプリケーション・サーバーを デモンストレーションします。BeenThere エンタープライズ Bean は、BeenThere サーブレットによって起動されます。

BeenThere サーブレットは、以下の情報を表示します。


さらに、BeenThere サーブレットは以下のアクションを実行することができます。


環境

次の図に、Web コンテナーおよび EJB コンテナー・ワークロード管理のデモンストレーションに使用されるサンプル環境を示します。



図 1   サンプル環境


この環境内のマシンには、次のものがあります。



構成には、MyWebCluster と MyEJBCluster という 2 つのサーバー・クラスターが含まれています。サーバー・クラスターは、 アプリケーション・サーバーのグループからなります。メンバーであるサーバーの 1 つで障害が起こると、 要求はそのクラスターの別メンバーに送られます。サンプルのクラスターは、それぞれ 2 つのクラスター・メンバーで 構成されています。クラスター MyWebCluster はクラスター・メンバー WebServer1 および WebServer2 で、 クラスター MyEJBCluster はクラスター・メンバー EJBServer1 および EJBServer2 で構成されています。

このように構成された環境は、一例であり、BeenThere アプリケーションが どのように実行されるのかを示すためにのみ使用されるものです。実稼働環境では、 注意深くリソース・キャパシティー・プランニングを行い、予想されるクライアント要求負荷に基づいて、 決まった台数のマシン全体でいくつのアプリケーション・サーバーのメンバーを作成するべきかを判断する必要があります。

ワークロード管理

WebSphere Application Server Network Deployment Edition は、HTTP 要求および EJB 要求のワークロード管理 (WLM) を提供します。

Web コンテナー・ワークロード管理

HTTP 要求のワークロード管理は、Web server plug-in によって処理されます。

図 1 の構成を見ると分かるように、web マシンが IBM HTTP Server を実行していて、 それが HTTP 要求をアプリケーション・サーバー WebServer1 および WebServer2 のそれぞれに ディスパッチします。これらのアプリケーション・サーバーは MyWebCluster クラスターのメンバーであり、BeenThere サーブレットを 実行しています。これらのアプリケーション・サーバーは、それぞれ、app1 および app2 マシン上で 構成されています。さらに、IBM HTTP Server プラグインが、WebServer1 の WLM ウェイトが 2 で、WebServer2 の WLM ウェイトが 3 であるように構成されています。 ウェイトは、構成された値で開始し、要求がサービスを受けるたびに 1 ずつ減らされるカウンターと考えることができます。要求は、 ラウンドロビン処理を使用して、現在のウェイト・カウンター値が 0 より大きいアプリケーション・サーバーにディスパッチされます。 値が 0 のアプリケーション・サーバーはスキップされます。すべてのウェイト・カウンターが 0 になるまで減らされると、 すべてのアプリケーション・サーバーのウェイト・カウンターがそれぞれの構成値にリセットされ、ディスパッチ処理は最初からもう一度始まります。

EJB コンテナー・ワークロード管理

EJB 要求のワークロード管理は、WebSphere Application Server 内の WLM コントローラーによって内部的に処理されます。

図 1 の構成で示されているように、MyEJBCluster クラスターが、 アプリケーション・サーバー・メンバー EJBServer1 および EJBServer2 からなると定義されていて、 これらのメンバーが BeenThere ステートレス・セッション・エンタープライズ Bean 実行を担当します。BeenThere サーブレットが この エンタープライズ Bean を呼び出して、この エンタープライズ Bean の実行場所であるアプリケーション・サーバーに 関する実行情報を入手します。これらのサーバーは、それぞれ 1 および 3 のウェイト値で構成されています。

z/OS プラットフォームでは、ウェイト値は HTTP 要求のバランスを取るために使用されますが、Internet Inter-ORB Protocol (IIOP) 要求のバランスを取るためには使用されません。

WebSphere 管理アプリケーション・プログラミング・インターフェース

BeenThere アプリケーションは、WebSphere Application Server 内の管理アプリケーション・プログラミング・インターフェースを 使用します。これらのインターフェースを用いて、アプリケーションは、ランタイムおよび環境構成情報にアクセスできます。


AdminService

アプリケーション・サーバー属性情報を取得するための サーバー・サイド・インターフェースと、標準の JMX MBean 管理機能を 実行する能力を提供します。

AdminClient

リモート AdminService オブジェクトへのクライアント・サイド・インターフェースを提供します。AdminClient クラスは、 サポートされている Java Management Extensions (JMX) コネクターのうちの 1 つを介して、リモート AdminService オブジェクトへのプロキシーを提供します。

ConfigService

構成データをローカルまたはリモートで照会または変更するためのインターフェースを提供し、 アプリケーション・サーバー構成文書の場所と内容を管理します。

WebSphere Application Server 管理インターフェースを使用するときにアプリケーションが持つ能力と柔軟性を示すため、BeenThere アプリケーションは、これらすべてのインターフェースを以下のように利用します。


AdminService

AdminService インターフェースは、BeenThere サーブレットと エンタープライズ Bean の両方によって、 それらが実行している場所であるアプリケーション・サーバーのノード名、アプリケーション・サーバー名、 およびプロセス ID を取得するために使用されます。以下のコード・セグメントは、サーバー属性情報の取得方法を示します。


// Get the WebSphere AdminService.
AdminService adminService = AdminServiceFactory.getAdminService();

// Get the WebSphere Admin Local Server MBean instance.
ObjectName localServer = adminService.getLocalServer();

// Get the Node name.
nodeName = (String) adminService.getAttribute(localServer, "nodeName");

// Get the Application Server name.
serverName = (String) adminService.getAttribute(localServer, "name");

// Get the Application Server Process Id.
serverPid = (String) adminService.getAttribute(localServer, "pid");

AdminClient

AdminClient インターフェースは、BeenThere エンタープライズ Bean を実行している クラスターの全アプリケーション・サーバー・メンバーについてクラスター・メンバーのウェイト値を 検索するために、デプロイメント・マネージャー・プロセスに接続するのに使用されます。以下のコード・セグメントは、AdminClient インターフェースのインスタンスの取得方法を示します。


// Get the WebSphere AdminService.
AdminService adminService = AdminServiceFactory.getAdminService();

// Get the AdminClient instance for the Deployment Manager.
adminClient = adminService.getDeploymentManagerAdminClient();

ConfigService

ConfigService インターフェースは、WebSphere Application Server cell.xml 構成文書を読み取って BeenThere アプリケーション が WebSphere Application Server Base Edition または Network Deployment Edition 環境で実行しているかどうかを 判定するために使用されます。以下のコード・セグメントは、アプリケーションが実行している環境の判別方法を示します。


// Create a new WebSphere Management Session.
Session session = new Session();

// Get the WebSphere ConfigService instance
// for the application server executing this servlet.
ConfigService configService = ConfigServiceFactory.getConfigService();
if (configService != null)
{
  // Read the cell.xml document.
  ObjectName cellObj = ConfigServiceHelper.createObjectName(null, "Cell");
  ObjectName[] cellObjs = configService.queryConfigObjects(session, null, cellObj, null);

  if (cellObjs.length != 0)
  {
    cellObj = cellObjs[0];
    String cellName = (String) configService.getAttribute(session, cellObj, "name");
    String cellType = (String) configService.getAttribute(session, cellObj, "cellType");
    if (cellType.equals("DISTRIBUTED"))
    {
      websphereND = true;
    }
  }

  // Release the Session.
  configService.discard(session);

Network Deployment 環境が検出された場合、Bean クラスター・メンバーのウェイトを表示するというオプション が使用可能にされ表示されます。このオプションは、このタイプの環境でのみ有効であるためです。それ以外の場合、 このオプションは選択可能オプションとして表示されません。