レベル: 初級 Dan Jemiolo (danjemiolo@us.ibm.com), Advisory Software Engineer, IBM
2006年 12月 12日 Apache Muse 2.0 を使用して、インスタンス数が数百から数千に及ぶリソース・タイプ用の WS-DistributedManagement (WSDM) インターフェースを作成する方法について説明します。本文では、最初に Java™ Platform, Enterprise Edition (Java EE) アプリケーション・リソース (どのアプリケーション・サーバー上でも非常に数が多くなる可能性があります) を表現するための WSDM インターフェースの作成方法について説明します。次に、「Factory」リソースの作成方法について説明します。このリソースは、Web アプリケーション・リソースがサーバー上にインストールされているものとして作成します。最後に、WSDM エンドポイントがそのホストに負荷をかけないよう、多数のリソースをサポートするために必要な占有スペースを最小化する方法について説明します。
多くの IT 環境において、WSDM を用いて管理対象となるリソースの数は非常に多く、それぞれに Java オブジェクト・セットを作成してしまうと、ホスト・マシンのパフォーマンスに悪影響を及ぼします。また、WSDM インターフェースがアドレッシング・データとリソース・データを効率的に保持しない場合、すぐに管理対象のリソース数の増大と同じ程度に占有スペースを大きくしていくことになります。
これら両方の問題を引き起こす例として、Java EE アプリケーション・サーバーのコンポーネント用に WSDM インターフェースを作成する場合が挙げられます。通常このような製品は、Web アプリケーション、Enterprise Java Beans (EJB)、JDBC™ データ・ソース、およびその他多くのコンポーネントをホストします。本文では、分かりやすく説明するために、これらのコンポーネントのうち、Java EE Web アプリケーションのみに焦点を当てて説明します。その後で、説明したその作業を他のリソース・タイプに対しても繰り返し行ってメモリー内の占有スペースを低く保つ方法について説明します。
本文は、中級レベルのスキルと経験を有する Java プログラマーを対象としています。また、WS-ResourceFramework (WSRF) および WSDM 標準で定義されている概念および XML スキーマについても、しっかりと理解しておく必要があります。さらに、Apache Muse 2.0 ディストリビューションに付属の入門チュートリアルを試し、サンプル・アプリケーションを正しく実行出来るようにしておく必要があります。
ソリューションの設計
この作業の目的を達成するために、Java EE Web アプリケーション用の WSDM インターフェースを設計する際、次の2 つの前提が必要となります。
- Web アプリケーション・リソースのプロパティーおよびオペレーションの実装はステートレスです。つまりコードは、Web アプリケーションにおいて特定のインスタンスに関連するいかなるデータも保持しません。
- Web アプリケーションにおいて特定のインスタンスへのリクエストを送信するのに必要なデータはすべて、リクエスト中の WS-Addressing ヘッダーに入っています。
これらの前提に従って設計するならば、比較的少数のオブジェクトで多数のリソースを処理する実装コードを作成することが可能になります。コードがステートレスであるため、その (オブジェクトの) インスタンスは常に同じです。これは1 つのオブジェクトをすべての Web アプリケーション・リソースで再利用できることを意味します。複数のエンドポイント参照 (EPR) を 1 つのオブジェクトにマッピングし、そのオブジェクトがすべての要求を処理できるようにすることでこの仕組みは完成します。ここでは、新しい Web アプリケーションがサーバーにインストールされるたび、EPR からオブジェクトへのマッピングを作成することを唯一のジョブとする、単独のリソースを作成する方法について説明します。
Apache Muse を使用したソリューションの作成
Apache Muse プロジェクトは、WSDM の実装、および WSDM インターフェースの開発が簡単になるコード生成ツールを提供します。Web アプリケーション用の WSDM インターフェースを設計して、それを WSDL 文書に記述したら、Muse の WSDL2Java ツールを使用してスケルトン実装を作成することができます。そこで、WSDM インターフェースのテストに使用できるサンプルの実装コードをいくつか紹介します。最後に、Muse の下位 API をいくつか使用して複数の EPR を 1 つの org.apache.muse.core.Resource オブジェクトにマッピングし、リソース・インスタンスごとに 1 つの org.apache.muse.core.Resource オブジェクトを準備しなくてすむようにします。
コード生成
まず、WSDL2Java を使用してコードを生成しましょう。時間の都合で、既に 2 つの WSDL 文書を作成してあります。1 つは Java EE Web アプリケーション・リソース用で、もう 1 つは「Factory」リソース用です。また、Muse デプロイメント記述子 muse.xml が提供されています。これを使用すると、2 つのリソース・タイプ用のコードを同時に生成することができます。これらのファイルをすべてダウンロードして、任意のディレクトリーに抽出してから、次のように入力して Muse の WSDL2Java ツールを実行します。
Java EE アプリケーション・リソース用の実装コードは、com.ibm.management.j2ee.application というパッケージの JavaSource ディレクトリー下にあります。Factoryリソース・コードは、com.ibm.management.j2ee.factory というパッケージに入っています。WebContent ディレクトリーに入っている WSDL および XML の内容は変更する必要がありません。
実装コード
Java EE アプリケーション・リソース・コード中には、アプリケーションの機能や属性を表現し、必要に応じて操作を行う JMX MBean を検索するコードが記述されます。アプリケーション・サーバーは内部にインストールされているすべてのコンポーネント用に MBean を作成するので、検索プロセスは極めて分かりやすくなっています。MBean により、プロパティーの取得または設定を行って、アプリケーションに対する操作を呼び出すことができます。このように、個々のアプリケーションの状態はすべて、コードではなく、WSDM インターフェースをホスティングしているアプリケーション・サーバー内に保管されるため、求められていたステートレスな実装が実現します。
リスト 1 のコードをコピーして実装ファイル com.ibm.management.j2ee.application.ApplicationCapability に貼り付けることができます。getter、setter、および操作の各メソッドが getObjectNameFromRequest() メソッドを使用して適切なアプリケーションを表す MBean の名前を取得する点に注意してください。この名前を使用して、適切な MBean オブジェクトを検索し、操作することができます。実装には特定のアプリケーションに関連するステートが含まれず、すべてが MBean API によって処理されます。
リスト 1. 実装コード
public class ApplicationCapability
extends AbstractWsResourceCapability implements IApplicationCapability
{
private static final QName OBJECT_NAME_PARAM =
new QName("http://ibm.com/management/j2ee", "ObjectName", "j2ee");
private static final QName[] _PROPERTIES = new QName[]{
new QName(NAMESPACE_URI, "StartTime", PREFIX)
};
public QName[] getPropertyNames()
{
return _PROPERTIES;
}
//
// The J2EE management system provides an EJB that we can use to
// lookup the MBeans for each component in the server
//
private Management managementEJB = null;
//
// Utility method for getting the MBean name by reading the
// WS-Addressing reference parameters
//
protected ObjectName getObjectNameFromRequest()
{
MessageHeaders wsa = getEnvironment().getAddressingContext();
EndpointReference epr = wsa.getToAddress();
String param = epr.getPropertyString(OBJECT_NAME_PARAM);
return new ObjectName(param);
}
//
// Muse's standard initialization method for Capability classes
//
public void initialize()
throws SoapFault
{
super.initialize();
//
// find the EJB that is used to invoke MBeans by name
//
try
{
Context context = new InitialContext();
Object ejb = context.lookup("java:comp/env/ejb/mgmt/MEJB");
ManagementHome home =
(ManagementHome)PortableRemoteObject.narrow(ejb, ManagementHome.class);
managementEJB = home.create();
}
catch (Throwable error)
{
throw new RuntimeException(error.getMessage(), error);
}
}
//
// The remaining code contains the generated methods with their
// complete implementations
//
public Date getStartTime()
{
ObjectName objName = getObjectNameFromRequest();
Long timeInMS = (Long)managementEJB.getAttribute(objName, "startTime");
return new Date(timeInMS.longValue());
}
public void start()
{
ObjectName objectName = getObjectNameFromRequest();
managementEJB.invoke(objectName, "start", null, null);
}
public void stop()
{
ObjectName objectName = getObjectNameFromRequest();
managementEJB.invoke(objectName, "stop", null, null);
}
}
|
Factoryリソースは、新しい Web アプリケーションの作成されたときに、処理を行います。Web サービス・インターフェースとしては、新しい EPR からリソースへのマッピングを作成する以外の機能は必要ないため、機能は非常に限定されています。このリソースの実装コードは初期化ルーチンのみで、次の 2 つのタスクを実行します。
- Java EE アプリケーションに対する 1 つのリソース・オブジェクトを作成します。
- サーバーでアプリケーションに対するすべての MBean を検索し、それぞれに対して EPR からリソースへのマッピングを作成します。
リスト 2 のコードをコピーして実装ファイル com.ibm.management.j2ee.factory.FactoryCapability に貼り付けることができます。このコードは、Java EE アプリケーション・リソースの 1 つのインスタンスを作成してから、検出された MBean ごとに固有の EPR を作成してリソース・オブジェクトにマッピングします。これにより、Muse リクエスト・ルーターは、受け取ったリクエストを実装コードにディスパッチする前にその妥当性を確認することができます。実際のリソース・インスタンスごとに 1 つの EPR オブジェクトを作成しても、占有スペース全体はわずかしか増えません。本当に大容量の占有スペースを占めるのは、リソース・オブジェクト自体 (およびその機能)を作成した場合です。
リスト 2. コードによる 1 つのインスタンスの作成、および固有の EPR の作成とマッピング
public class FactoryCapability
extends AbstractCapability implements IFactoryCapability
{
private static final QName OBJECT_NAME_PARAM =
new QName("http://ibm.com/management/j2ee", "ObjectName", "j2ee");
public void initialize()
throws SoapFault
{
super.initialize();
//
// find the context path for the J2EE application resource type
//
ResourceManager manager = getEnvironment().getResourceManager();
String contextPath = manager.getResourceContextPath(ApplicationCapability.class);
//
// create one instance of the application ws-resource
//
Resource singletonResource = manager.createResource(contextPath);
singletonResource.initialize();
EndpointReference singletonEPR = singletonResource.getEndpointReference();
//
// find all of the MBeans for J2EE applications installed on our server
//
Set applications = null;
try
{
ObjectName pattern = new ObjectName("*:j2eeType=J2EEDeployedObject,*");
applications = getManagementEJB().queryNames(pattern, null);
}
catch (Throwable error)
{
throw new RuntimeException(error.getMessage(), error);
}
//
// for every MBean we find for a J2EE application, create an EPR
// with the J2EE object name as the reference parameter; then,
// map that EPR to the Resource object above
//
Iterator i = applications.iterator();
while (i.hasNext())
{
ObjectName objectName = (ObjectName)i.next();
EndpointReference epr = new EndpointReference(singletonEPR);
epr.addParameter(OBJECT_NAME_PARAM, objectName);
manager.addResource(epr, singletonResource);
}
}
}
|
このコードは、初期化時にすべての EPR からリソースへのマッピングを作成します。つまりサーバーの始動時に、インストールされているアプリケーションのみが管理対象となります。このコードは、サーバーでアプリケーションがインストール (およびアンインストール) されたときに認識できるように Java EE の MBeanServer API を listen することによって、より動的にマッピングを作成 (および破棄) するように変更できます。それを行っても、複数の EPR をステートレス・リソース・オブジェクトの 1 つのインスタンスにマッピングして、状態の保守をサーバーの Mbean に代行させるという、このコードの主要な目的は変わりません。
実装の拡張
この実装コードは、アプリケーション・サーバーの他の Java EE コンポーネントを処理できるように簡単に拡張することができます。以下のことを実行するだけです。
- 希望のインターフェースを使用して新しい WSDL を追加します
- WSDL2Java を再び実行します
- 同じ実装のアイデアを使用して Java ソース・ファイルに記述します
その他のタイプのリソースを作成するためにファクトリー・リソースを変更する場合は、コードの次の行にあるストリング・リテラルを変更するだけですみます。
ObjectName pattern = new ObjectName("*:j2eeType=J2EEDeployedObject,*"
|
太字ストリングは、一度に複数の MBeans を検索することができる単純なパターンです。J2EEDeployedObject を J2EEServer に変更すると、現在実行中のすべてのサーバー・インスタンスを取得することができます。すべての有効な Java EE タイプ名のリストは、この Java EE 継承ダイアグラムに記載されています。
このパターンを使用することにより、muse.xml で定義されたすべてのリソース・タイプに 1 つのリソース・オブジェクトと、リソース・インスタンスごとに 1 つの EPR オブジェクトのみを作成することになります。EPR オブジェクトのサイズは小さいため、占有スペースを節約することができます。管理する実際のリソースに大きな負荷をかけることなく、
その他多くの Java EE コンポーネントをこの Muse ベースの WSDM インターフェースに追加することが可能です。
まとめ
本文では、Apache Muse API を使用して、通常の Muse ベース・アプリケーションが必要とするよりも少ないメモリー内の占有スペースで、多数の Web サービス・リソースを管理する方法について説明しました。この例は Java EE 管理に特有のものですが、その概念は他の IT リソースで再利用することができます。Factoryリソースと EPR のマッピング方法は共通であり、MBean API の使用を他の製品の管理しやすい他の API に置き換えることができます。この設計パターンは、Apache Muse を使用して WSDM インターフェイスを作成する際、新しい管理レイヤーを追加することによって管理対象システムに悪影響を及ぼすことがないよう、再利用することができます。占有スペースが小さいことはすべてのシナリオにおいて重要とは限りませんが、それが重要となる場合には十分な柔軟性を発揮する Muse API が役立ちます。
ダウンロード | 内容 | ファイル名 | サイズ | ダウンロード形式 |
|---|
| 本文のサンプル WSDL ファイル | apache-muse-factory-xml.zip | 17KB | HTTP |
|---|
参考文献 学ぶために
製品や技術を入手するために
議論するために
著者について  | 
| | Dan Jemiolo は、ノースカロライナ州リサーチ・トライアングル・パークにある IBM Autonomic Computing チームの Advisory Software Engineer です。彼は Apache Muse 2.0 の設計および開発を指揮し、現在も引き続きこのプロジェクトに取り組んでいます。また、Dan は WS-RF TC に WS-ResourceMetadata 仕様のエディターとして参加しており、Web サービス標準の採用を促進する IBM の戦略に携わっています。彼はわずか 2 年前に、Rensselaer Polytechnic Institute で Computer Science を専攻し理学修士の学位を取得した後、IBM に入社しました。 |
記事の評価
| 
