ブラック・ボックスからエンタープライズへ 第1回: 管理、JMX 1.1スタイル

ページオプション JavaScript を要するドキュメントオプションは表示されません 原文はこちら

レベル: 中級

Sing Li (westmakaha@yahoo.com), Author, Wrox Press

2002年 9月 01日

Java Management Extension (JMX) についての3回にわたる連載の第1回である本稿では、Sing Liは、ネットワーク管理ソフトウェアの歴史と、それがつつましやかな初期の姿から今日の複雑で洗練されたエンタープライズ管理システムに進化するまでの経緯をたどります。また、このようなシステムに付きものの多くの一般的な問題の原因と、そうした問題を解決するためにJMXを活用する方法についても検討しています。

Java Management Extension (JMX) は、Javaプラットフォームに追加することにより、エンタープライズ・ネットワーク管理に関する長年の問題を解決する、スケーラブルで実装コストの低い、レガシー・システムとの互換性も持つ今注目の新しい技術です。Jakarta TomcatやJBossなどの人気のあるオープン・ソース・サーバーを含む現在のソフトウェア・サーバーでは、管理標準としていち早くJMXが採用されています。まずは、ネットワーク管理ソフトウェアの歴史と、その発展の経緯を見ることからJMXの解明を始めましょう。

ネットワーク管理の進化

初期のネットワーク・ブリッジ、プロトコル変換装置、およびルーターは、装置自体のシリアル・ポートに端末を直接接続するというのが典型的な構成であった単純な専用ハードウェア装置でした。構成コマンドは、通常、ポートを使用可能または使用不可にするか、デバイスによってサポートされているプロトコルの特性を変更するために使用しました。こうした「ブラック・ボックス」において設定可能なパラメーターの数は限られ、図1に示すように、シリアル端末のインターフェースは不可解で、熟練したネットワーク・オペレーターにしか理解できないものでした。

独自のネットワークの時代

ネットワークの規模が大きくなり、これらの「ブラック・ボックス」の数が増加するにつれて、こうした大量のネットワーク・デバイスについてアドレッシングを行い、制御するための何らかの方法が必要であることが明らかになりました。図2に示すように、これらのデバイスを管理するために、独立した「帯域外」の相互接続あるいは集線装置ネットワークを提供することを選択したベンダーもありました。

その他のベンダーは「帯域内」テクノロジーを使用しました。このテクノロジーでは、図3に示すように、アドレッシングおよび制御情報はこれらの「ブラック・ボックス」が稼動している同じネットワーク上に送信されます。

クライアント・ソフトウェア (管理コンソールと呼ばれます。この名前は端末コンソールとの類似性に由来しています) は、暗号のような端末スタイルのインターフェースから、ネットワーク上のアドレッシング可能な各デバイスを個別に構成することを可能にする、GUIが強化された構成ツールへと徐々に進化しました。その結果、初期のネットワーク管理システム (NMS) が誕生しました。この時期はおおむねベンダーごとに独自のネットワーク・プロトコルが中心で、初期のNMSでは、ベンダーのデバイスについてアドレッシング、制御、およびモニタリングを行うために独自のプロトコルが使用されました。

TCP/IPがネットワーキングの事実上の業界標準となる

TCP/IPネットワークの時代に入ります。具体化した初期のころのインターネットを通して、TCP/IPプロトコル一式が全世界的に接続されたネットワークの標準となりました。大企業では、個別に進化してきた、会社独自の異機種混合社内ネットワーク (その多くは全世界規模の異なるベンダーのものでした) の個々の島々を接続しつつ、それと同時に企業全体のすべてのデバイスを制御し続ける必要性が認識されました。

これに加えて、インフラストラクチャーを構築する企業では、その事業において保守を行うネットワーキング・ブラック・ボックスの数が増え続けていきました。この作業が、異なる地域にまたがる複数のネットワーク・オペレーション・センターに及ぶこともよくありました。このようなすべてのデバイスを1つの場所から集中的に管理、制御、モニターする必要が生じたのです。これら2つの大きな顧客グループからの切迫した要求が、初期のエンタープライズNMSの概念を産み出しました。

このころの管理コンソール (クライアント) では、最新のグラフィック・ワークステーションと処理技術が使われ、多くの場合、ネットワーク網が図示されるだけでなく、管理対象デバイスがどこにあるかを対話的にたどれる地図が含まれていました。ネットワーク・オペレーション・センターのスタッフは、GUIネットワーク図の地図やノードをクリックすることにより、すべての任意のデバイスの状況をモニターし、その設定や構成を変更することができました。SNMP (簡易ネットワーク管理プロトコル -- TCP/IPネットワークの最上層のネットワーク管理のためにゼロから設計されたプロトコル) が、異機種混合ネットワークを管理するための事実上の業界標準としてより多く使用されるようになりました。当初SNMPに抵抗していた独自のネットワーキング・ハードウェアのベンダーも、実用面および経済面の両方の理由から、最終的にはこれを自社のネットワーキング・デバイスを管理する方法の選択肢の1つとして採用しました。

PCおよびLAN革命: エンタープライズ管理の拡張

TCP/IP革命とほぼ時期を同じくして、PCとLANを設置する形態のオフィスの人気が爆発しました。これにより、エンタープライズNMSに対し、新しい側面を加えるという必要性が生じました。すなわち、図4に示すように、PCワークステーション、プリンター、周辺機器、およびその他のLANデバイスの管理と制御です。

多くのベンダーは新たに獲得した可能性をマーケティングにおける利点として利用し、自社のエンタープライズ管理システム、EMS (「ネットワーク」という単語が強調されなくなったことに注意してください) を強く押し出していきました。主要ベンダーの商用EMSは、この時期に規模、複雑さの両方において成長しましたが、その一方で多くのベンダーの製品は、引き続き独自の大きなコード・ベースを維持し、すべての古いベンダー固有のシステムをサポートしました。現在のGUIベースの管理コンソール (クライアント) ソフトウェアは、次々に登場する多くのさまざまなデスクトップ・オペレーティング・システムへ繰り返し「移植」されて、より大きくなり、その基礎となるコード・ベースはより複雑になりました。SNMPプロトコルはその限界まで拡張され、当初はその設計の目的ではなかった新しいさまざまなデバイスもサポートするようになりました。管理対象となるネットワークのエンドポイントの数は管理可能なレベルを超えて増大し、ほぼすべての商用EMSにおいて、付加価値の付いたインテリジェントな管理支援が標準となりました。

インターネットおよびe-commerceの革命: EMSへの扱いやすいソフトウェア・サービスの追加

EMSにより管理されるエンドポイントの数が爆発的に増え続ける中で、インターネット革命がほとんどのEMSシステムとその設計者に衝撃を与えました。それまではばらばらだった大規模なネットワークが、突然インターネットを通して接続され、顧客たちはこの「ネットワークのネットワーク」を、なじみのあるそして気に入っていたユーザー・フレンドリーな管理コンソールで管理できるようになることを望みました (図5を参照)。

よりインテリジェントなネットワーク・デバイス、PC、および周辺機器が登場するにつれて、これらのエンドポイントの毎日の管理やモニターに関しても、さらなるインテリジェンスが求められるようになりました。さらに、インターネットを利用した商取引に対する要求が高まるにつれて、EMSによってサポートされるべき新しい種類のエンドポイント、インテリジェントなソフトウェア・サーバー / サービスが生まれました。

現在のEMSシステムでは、1企業内で個々のデータベース・サーバー、アプリケーション・サーバーおよびディスク・ファーム (新しく、高度にインテリジェントな帯域幅の広い適応型ディスク・ファームは、今ストレージ・エリア・ネットワーク、またはSANと呼ばれます) に、全世界的にアクセスして管理できるというのは珍しいことではありません。

管理対象ネットワークにおける分散インテリジェンスの必要性

今の時代のEMSでは、インテリジェントな管理支援はすでに1つの選択肢ではなく、必要不可欠なものです。構成やトポロジーにおいて常に変化し続ける動的なネットワークに対応していく必要は不可欠です。さらに、新規の、そして将来のデバイスに適応し、これをサポートして行く能力も、絶対的な要件です。その上、この新しいEMSは、顧客が奮闘した進化の過程で大規模に投資してきたレガシー・デバイス、プロトコル、およびソフトウェアをもサポートし、協調して機能するものであり続けなければなりません。実際、既存のGUIベースの複雑なEMSクライアントを扱うためのトレーニングに多大の投資が行われてきたため、これらのツールのサポートが強く求められています。それと同時に、EMSの新しいユーザーは、リモート管理およびリモート・モニターを可能にする最新のWebベース管理インターフェースを求めています。

こうした新しいEMSシステムを利用することにより、引き続き旧式の「単純な」ネットワーキング・ブラック・ボックス上のポートを使用可能 / 使用不可にすることが可能であり、それと同じく簡単に以下のようなコマンドを発行することもできます。

次の24時間で95%のアップタイムを維持するために必要であれば、バックアップのアプリケーション・サーバー・クラスターおよびデータベース・サーバーに自動的に切り替える。壊滅的な障害発生時にポケットベル 808-555-1212でネットワーク・オペレーターに警告を出す。

言い換えると、標準的なアプリケーション・サービス・プロバイダー (ASP) 環境においてネットワーク障害が発生した際に、これを管理するためにインテリジェントな管理支援に頼ることも可能です。

ソフトウェア・アーキテクチャーおよびネットワーク・プロトコルにおけるどのような変更点が、インターネット時代においてこうした洗練されたネットワーク管理を実現したのでしょうか。実際、われわれが描いてきたEMSのシナリオは、まだまったくの「発展途上」のものです。JMXは、完全な下位互換性を持ち、既存およびレガシーEMSインフラストラクチャーをサポートしつつ、動的なネットワークの普遍的な管理の実現に向けての重要なステップとなります。

上に戻る

ネットワーク管理におけるJavaプラットフォームの活用

Javaプラットフォームには、プラットフォームおよびOS非依存、ネットワーキング、および動的適応性など、それがおのずと複雑なネットワーク管理ソリューションの実装の候補となるようなさまざまな特徴を備えています。

プラットフォームおよびOS非依存

Java言語はプラットフォームおよびOSに依存しないため、NMS開発者は、各OSとハードウェア・プラットフォームの組み合わせについて、それぞれのコード・ベースのバージョンを維持する必要がなくなります。その代わりに、1つのコード・ベースの下で、製品の機能を強化することに労力と努力を注ぎ込むことが可能です。

ネットワーキング

他のほとんどのプログラミング言語と異なり、ネットワーキングはJavaプラットフォームの中心となる部分の一つです。Javaのネットワーキングは、後から付け加えられたものでも、サード・パーティーのライブラリーでもないため、他のOS / ハードウェア・プラットフォームと協調して機能することが保証されています。多くの古いネットワーク管理製品は、プラットフォームとOSの組み合わせでも満たせない要件を実現するためや、目標とする安定度を達成するためにサード・パーティーのネットワーキング・ライブラリーに依存していたのが現実だったので、上に述べたJavaネットワーキングの特性は重要な意味を持ちます。

動的適応性

ネットワーク管理ソフトウェアは、容易にネットワーク経由でクラスを動的かつ安全にロードすることができます。例えば、JavaベースのEMSは、サポート・モジュールをネットワーク経由で「ロードする」だけでより新しいデバイスやサービスをサポートすることができ、ネットワーク管理インテリジェンスを実装するソフトウェア・モジュールは必要に応じて動的にアップグレードすることができます。

上に戻る

JMX: ネットワーク管理の仕様

JMXは、Javaプログラミング言語を使用してネットワーク管理を行うのための、拡張可能なアーキテクチャー、API、分散サービスのセットを記述する、仕様の集まりであり、業界規模の共同的な取り組みにより作られました。JMXでは、前述のように、ネットワーク管理のためにJavaプラットフォームの長所が活用されます。本稿執筆時点での最新の仕様は、Java Management Extension InstrumentationおよびAgent仕様v1.1です。

入手可能なJMXのセットには、仕様のセット、APIのドキュメンテーション、JMX仕様に準拠したリファレンス実装、および互換性テスト・スイートが含まれます。JMX 1.1仕様および詳細情報にアクセスするには、参考文献を参照してください。

JMXの目的は、JMXアーキテクチャー内のシステムを構成させるインターフェースのみを定義することであり、必要とされないのにもかかわらず実装やポリシーを指図することではありません。この考え方は、既存のネットワークおよびサービス管理テクノロジーに独自の既得権益を持つベンダーからの支持を獲得するために非常に重要です。また、この考え方により、設計において最大限の自由と柔軟性が約束される新しいJMXベースのアプリケーションが実現します -- 所定の実装やポリシーが将来のニーズに適さなくなるような事態が回避されます。このようにして、リファレンス実装では、指定されたインターフェースのセットはどのように満たされるかを示す1つの例のみが提供されていますが、これを達成する方法が推奨または提案されているわけではありません。

上に戻る

JMXのアーキテクチャーと運用モデル

JMXのアーキテクチャーと運用モデルは、以下の目的を達成することを目指しています。

• スケーラビリティー: 少数のデバイスやサービスの管理から、インターネット時代の企業が保有する数万にいたる管理可能なエンドポイントに適応できる能力
• 旧式との統合および互換性: JMXをサポートしていない旧式の管理対象エンドポイントだけでなく、既存のNMSまたはEMSソリューションと協調して機能する能力
• 低コストの実装: JMXの互換性は、大きな設計およびコーディングの作業を必要とすることなく、既存のソフトウェア製品およびデバイスに簡単に組み込むことが可能であること

JMXアーキテクチャーは3つのレベルで構成されており、その分割統治が可能な構造によりスケーラブルなネットワーク管理の複雑さが軽減されます。疎結合された3つのレベルについて図6 に図示します。3つのレベルとは以下のとおりです。

• インスツルメンテーション・レベル: このレベルでは、管理可能なエンドポイント (デバイス、ソフトウェア・サービスなど)は、JMXにより規定されるインターフェースを通してアクセス可能になります。これは、構成可能な属性、アクセス可能な動作、およびイベントを公開するJavaオブジェクトを作成することによって行われます。このようなオブジェクトはManagedBeans (略してMBeans) と呼ばれます。これらのオブジェクトを通して管理可能なエンドポイントは、仕様の中でJMX管理可能リソースと呼ばれています。非JMXのレガシー・デバイスおよびサーバー (SNMP互換デバイスまたはサブネットワークなど) は、Java MBeanラッパーを提供することによりJMX管理可能リソースへと簡単に「適応化させる」ことが可能です。このレベルのJMX管理可能リソースは、JMXアーキテクチャーの他のレベルのオブジェクトとは完全に独立して設計することができます。
• エージェント・レベル: このレベルでは、JMXエージェントの内部アーキテクチャーが公開されます。JMXエージェント は、標準化されたエージェント・サービスのセットをリモート管理コンポーネントに公開し、MBeanインターフェースを通してJMX管理可能リソースを直接制御するソフトウェア・コンポーネントです。実際、MBeansは、MBeansを動的にロード、アンロードできるMBeanサーバーを通して、JMXエージェント内で管理されます。MBeanサーバーにアクセスするためのインターフェースがJMXによって指定されています。ローカライズされたインテリジェント・モニターや自動応答などの大規模EMSシステムにおける付加価値は、JMXアーキテクチャーのこのレベルで実装可能です。このレベルのエージェントは、他のレベルのオブジェクトとは独立して設計可能です。エージェントは、コネクターまたはプロトコル・アダプターを通して管理アプリケーションと通信を行います。ただし、これらのコンポーネントの仕様化については今もまだ作業中の段階です。
• 分散サービス・レベル: このレベルにおいては、JMXマネージャーのコンポーネントを規定するインターフェースを指定することが目的です。JMXマネージャーは，エージェントまたはエージェントのグループにアクセスして、エージェントによって公開されているJMX管理可能リソースを管理することができます。基本的には、これはEMSアプリケーション開発者がプログラミングを行う対象となるインターフェースです。マネージャーのコンポーネントは、EMSアプリケーション、または複数のエージェントおよび関連リソースを管理する中間のインテリジェンス層などになることができます。

図6は、JMX 1.1によって指定されるインターフェースと、3つのレベルのJMXオブジェクトを示しています。オブジェクト指向設計とJavaプログラミング言語が活用されているため、JMXアーキテクチャーの各レベルは、高度にコンポーネント化されており、明確に定義されたインターフェースによって分離されています。これらの明確に定義されたインターフェースに準拠したコードを書くことにより、インスツルメンテーションおよびエージェントのロジックは、あらゆるJMX 1.1互換の実装において確実に機能します。インスツルメンテーション・レベルおよびエージェント・レベルは、JMX 1.1仕様において詳細に規定されていますが、分散サービス・レベルについては将来の仕様化の対象となっています (図6では、水平なグレーの点線と、その上の点線のボックスとして示しています)。SNMPおよびCIM / WBEMを含む既存のネットワーク管理標準に対する標準JMXインターフェースについては、他のグループによって並行して作業が進められています。

スタンダードMBeansとダイナミックMBeans

インスツルメンテーション・レベルの中心はMBeanインターフェースです。MBeanインターフェースは、属性へのアクセス方法、動作 (Javaプログラミング言語におけるメソッドと似ています) の起動方法、およびMBeanからのイベントの送信方法を指定します。MBeansには主に2つの種類があり、その詳細を 表1に示します。

ダイナミックMBeanの特別版: モデルMBeansとオープンMBeans

表2に示すように、ダイナミックMBeansには特殊な目的のための2つのサブタイプがあります。

図7は、デバイスおよびソフトウェア・サービスにインスツルメンテーションを追加するために、MBeanがどのように使用されるかを示したものです。対応するMBeanはデバイスまたはサービスのJMX内部の表現であることに注意してください。JMXエージェント内のMBeanサーバー (後述します) で登録されたすべてのMBeanには、リモートのNMSまたはその他のJMXアプリケーションに公開される管理インターフェース (属性、動作およびイベント) を用意することができます。ただし、デバイスまたはソフトウェア・サービスを装備するためにMBeansを追加する際は、管理するためにどの種類のJMXエージェントまたはNMSが使用されるかを考慮する必要はありません。

永続的MBeans

MBeansの中には、適切な動作を確実なものにするために永続的なサポートを必要とするものがあります。これらのMBeansは常にjavax.management.PersistentMBean インターフェースを実装しなければなりません。このインターフェースには、save() およびload() メソッドのみが含まれます。永続的MBeanの実装はbeanの構築時にMBeanの状態を永続化された値に基づいて初期化するために、load() メソッドを呼び出す責任があります。

上に戻る

JMXエージェントの内部

図7 は一般的なJMXエージェントの構造を表しています。MBeanサーバー、エージェント・サービスのセット、コネクターおよびプロトコル・アダプター、およびカスタムのエージェント・ロジックが、エージェント内の4つの主要コンポーネントであることに注意してください。

MBeanサーバー

MBeanサーバーは、エージェント内の中心コンポーネントです。すべてのMBeansは、リモート・アプリケーションからアクセスするには、MBeanサーバーで登録されている必要があります。登録されたMBeansは、MBeanサーバーと連携して機能する際に、ユニークなオブジェクト名でアドレッシングされます。リモートのマネージャー・アプリケーション (または分散サービス) は、その管理インターフェース(公開された属性、動作、およびイベント) を通してのみMBeanを発見、アクセスすることが可能です。

エージェント・サービス

エージェントは、MBeanサーバー内の登録されたMBeanに対して操作するために、カスタムのエージェント・ロジックによる使用が可能なエージェント・サービスのセットも提供します。これらのサービスは、JMX 1.1に準拠するために必要です。したがって、すべてのエージェントはこれを提供しなければなりません。おもしろいことに、これらのサービスはMBeans自体の形式で実装可能です。サービスをMBeanの形式で実装すると以下のような利点があります。

• サービスの操作は、マネージャー・コンポーネントまたはEMSを通してリモートからアクセス可能です。
• サービス自体については、EMSによってリモートから管理可能で、リモートのマネージャー・アプリケーションからアクセスできます。
• サービスのロジックの更新は、MBeanをダウンロードすることによりランタイムに動的に実行可能です。

表3にJMX 1.1仕様で定義されているエージェント・サービスのセットを示します。

付加価値の付けられたエージェント・ロジック

付加価値の付けられたエージェント・ロジックとは、通常われわれが記述するコードです。カスタム・エージェント・ロジックは、このエージェントで登録されたJMX管理可能リソースを管理するローカライズ済みインテリジェンスを提供します。例えば、冗長なアプリケーション・サーバーのクラスターが2つある場合、登録されたサーバーのMBeans上で動作することにより、ロード・レベルをモニターし、受信した要求を別のクラスターに動的にリダイレクトするカスタムのエージェントを作成することができます。多くの場合、NMSのベンダーはカスタム・ロジックも提供しています。分散サービスの仕様が確定したら、特定のカスタム・エージェント・ロジックが、カスタムのリモートJMXマネージャー・コンポーネントと協調して機能し、より高度なネットワーク管理機能を提供することはすぐにできます。

コネクターとプロトコル・アダプター

エージェントは、分散サービス、NMS、またはその他の管理アプリケーションと直接通信を行うわけではありません。その代わりに、コネクターとプロトコル・アダプターが使用されます。このアーキテクチャーは、J2EEコネクター・アーキテクチャーと一致しています (参考文献 を参照)。プロトコル・アダプターは、HTTPやSNMPなどの標準化されたプロトコルを通して、エージェントが管理するリソースへのアクセスを提供するソフトウェア・コンポーネントです。

コネクターは、エージェントおよび / またはエージェントにおける管理対象リソースにリモート・インターフェースを提供する、特殊ソフトウェア・コンポーネントです (通常はCORBAやRMIなどのリモート・プロシージャー・コール・テクノロジーを利用して (多くの場合セキュリティーのためにSSLを通して) これを行います)。エージェントが、アクティブなコネクターやプロトコルを複数保持している場合、複数の異機種のアプリケーションまたはNMSが同時に管理対象リソースにアクセスすることがあります。既存の確立されたNMSに対する後方互換性を提供するために、プロトコル・アダプターを使用することができます。例えば、common information model / Web-based enterprise management (CIM / WEBM) アダプターを、この標準をサポートするNMSについて作成することができます。あるいは、telecommunications management network (TMN) プロトコル・アダプターを作成して、JMXエージェントによって管理される電気通信リソース上での運用、管理、および保守 (OAM) を可能にすることもできます。JMXコネクターおよびプロトコル・アダプターの明確な仕様は、並行して作業が進められている仕様化の対象になっています (参考文献を参照)。

上に戻る

アプリケーションにおけるJMX 1.1サポートの増加

JMXアーキテクチャーは、インスツルメンテーション・レベルおよびエージェント・レベルのみが完全に定義されているだけですが、Javaベースのエンタープライズ・テクノロジーの開発者の間ではすでに幅広い支持を得ています。

J2EE 1.4とJMX

2002年8月18日に提案されたJ2EE v1.4の最終案 (参考文献を参照) では、JMXベースのインスツルメンテーションが、どのようにしてJ2EE Webコンテナー (JSP / サーブレット・エンジン)、EJBコンテナー、およびアプリケーション・クライアント・コンテナーの標準部分になるかについて詳しく書かれています。J2EEベースのサーバーが広く配置され、管理の容易性が決定的な要件となりつつあるため、これは自然な展開です。(数百もの配置済みサーバーがある大きなサイトでの、手動または随時の構成、管理、およびモニターがほとんど不可能になっていることは想像に難くありません。)

これまでは、商用のサーバー製品が、製品を既存のNMS製品と互換性のあるものにする独自の手段や特別に追加したな機能を通して管理の容易性をサポートしてきました。J2EE v1.4の仕様においてJMXが管理基盤として標準化されることで、さまざまなベンダーのサーバー製品が、一般的にNMSと互換性を持つ (そしてNMSで管理できる) ようになります。

実装のケース・スタディー: Apache Jakarta Tomcat 4.1.x

J2EE v1.4仕様にのっとり、Tomcat 4.1.xの最新のベータ版ではすでにJMXインスツルメンテーションが統合されています。ダウンロード・サイトについては、参考文献 のセクションを参照してください。Tomcatインスツルメンテーションのほとんどは、構成コンポーネントに集中しています。これはTomcatのCatalinaエンジン内のランタイム・オブジェクトに対応します。構成コンポーネント (<Engine>、<Host>、<Server>、<Service>、<Connector>、<Context>、および <Realm>) は、以前はconf ディレクトリー内のserver.xml およびweb.xml ファイルを通してのみ変更可能でしたが、今はJMX MBean実装を通してすべて装備されています。

org.apache.catalina.mbeans パッケージを調べる (ソース・コード・ディストリビューションまたはAPI Javadocのいずれかにあります) と、これらのTomcat構成コンポーネントを公開するすべてのJMXインスツルメンテーションMBeanクラスが含まれているのがわかります。<Context> コンポーネントを装備するorg.apache.catalina.mbeans.StandardContextMBeanが含まれる例もあれば、org.apache.catalina.mbeans.MemoryUserDatabaseMBean は<MemoryUserdatabase> コンポーネントを装備しています。実際のソース・コードを調べると、Tomcat 4のインスツルメンテーションはJMX実装によって提供されるモデルMBeanテンプレートを拡張して利用していることがわかります。

現在、Tomcat 4.1.xでは、SunのリファレンスJMX実装ではなく、オープン・ソースのライセンスで公開されているJMX実装であるMX4J JMX実装が使用されています。ただし、どちらの実装も完全にJMX 1.1と互換性があります。MX4Jの最新バージョンへのリンクを見つけるには、参考文献 を参照してください。

Tomcatインスツルメンテーションによる拡張の直接の利点は、WebベースのGUI管理アプリケーションが簡単に作成できることです。Tomcat 4.1.xは、admin と呼ばれるそのようなアプリケーションを提供します。アプリケーション自体は、Strutsアプリケーション・フレームワークおよびJSPテクノロジーを利用して作成されます。これは、ローカルのJMXエージェントのMBeanサーバーを経由して、すべての構成コンポーネント (server.xmlで定義されるものと同じ) にアクセスします。Tomcatの場合、JMXエージェントは、org.apache.catalina.mbeans.ServerLifeCycleListener クラスにより作成されます。これは、Tomcatの起動およびシャットダウン時に呼び出されるLifeCycleListener です。

このJMXベースのadmin ユーティリティーを使用するには、まず、Tomcatディストリビューションのconf ディレクトリー下にあるtomcat-users.xml ファイルを編集する必要があります。必ずTomcatユーザーにadminの役割を追加してください。

<user username="tomcat" password="tomcat" roles="tomcat,admin"/>

これは、<MemoryUserdatabase> コンポーネントがランタイム中にアクセスを認証するために使用するファイルで、ユーザーはユーティリティーを実行するためにadminの役割を持っている必要があります。次に、Tomcat 4.1.xを開始します。

ブラウザーを開いてURLを入力します。

http://localhost:8080/admin/

ログイン・ページで以下のように入力します。

Username: tomcatPassword: tomcat

次に、admin ユーティリティーを調べ、JMX MBeanがCatalina構成コンポーネントの値のリアルタイム表示と変更をどのようにして有効にしているかをみましょう。例えば図8は、<Context> 構成コンポーネントの属性の構成ページを示しています。

もちろん、Tomcatのインスツルメンテーションは、admin Webベース・アプリケーションだけでなく、他のエージェントおよびEMSによる管理も可能にします。

上に戻る

結論

JMXは、スケーラビリティー、低い実装コスト、および既存のテクノロジーとの互換性という設計の目的を、Javaプラットフォームと慎重な設計を活用して達成しています。次回は、リファレンスJMX 1.1コードを使用して作業を進め、独自のスタンダードMBeanとダイナミックMBeanを実装し、迅速なインスツルメンテーションのために必要なモデルMBeanを活用し、JMXエージェントを使用して実験を行います。

参考文献

• 最新のJMX仕様、リファレンス実装、および互換性テスト・スイートをダウンロードしてください。
  
  
• 完全にオープン・ソースなJMX 1.1の実装、そしてJakarta Tomcatによって使用されている現在のJMXについては、MX4J プロジェクトをチェックしてください。
  
  
• SNMPの詳細については、インターネット・エンジニアリング・タスク・フォースのRequest For Comments 1157 文書を 確認してください。
  
  
• CIM / WEBMの詳細情報および最新の開発状況については、分散管理タスク・フォースのWebサイトを参照してください。
  
  
• JMX 1.1インスツルメンテーションを含むTomcat 4.1.xサーバーの最新バージョンは、Jakartaプロジェクト よりダウンロード可能です。ソース・コード・ディストリビューションも入手可能です。
  
  
• JMX分散サービス、プロトコル・アダプター、およびコネクターの仕様に関する進行中の作業については、JSR 160 JMX Remoting 1.2、JSR 146 WEBM Services、およびJSR 70 IIOP Protocol Adapter for JMX を参照してください。
  
  
• JMXは、J2EEコネクター・アーキテクチャーと似たエージェント・コネクター / アダプター・アーキテクチャーを特徴としています。
  
  
• J2EE 1.4は、JMXが完全に装備されたコンテナーを特徴としています。新たに誕生したJ2EE 1.4仕様 の最新バージョンをダウンロードしてください。
  
  
• IBMのTivoli ソフトウェアは、JMX互換の実装で、alphaWorksから入手可能なTMX4J を含む、広範囲にわたるさまざまな既存および新規のネットワーク管理標準をサポートする安全なエンタープライズ管理ソリューションを特徴としています。
  
  
• Tivoliソフトウェアおよびセキュリティー製品に関するテクニカル情報については、最新のdeveloperWorks 製品サイトTivoli Developer Domain Lite をぜひ参照してください。
  
  
• developerWorks のJava technologyゾーン には、数百ものJavaテクノロジー関連の参考文献があります。
  

著者について

		Sing LiはWrox Pressから出版されている多数の本の著者で、Professional Apache Tomcat 、Early Adopter JXTA 、Professional Jini などを執筆しています。技術雑誌に頻繁に寄稿しており、P2P発展に関する熱心なエバンジェリスト（伝道者）でもあります。コンサルタント兼ライターであるSingの連絡先はwestmakaha@yahoo.comです。

記事の評価

サイト改善のため、ご意見をお寄せください。こちらのフォームからお願いいたします。 この情報はお客様が目的を達成するうえで役に立ちましたか？ はい いいえ わからない   お気軽にご意見・ご感想をお寄せください。   この記事は役に立ちましたか？ 1 2 3 4 5 不充分・不完全である 大変素晴らしい

この記事を共有する del.icio.us newsing FC2ブックマーク Choix！ ニフティクリップ Yahoo!ブックマーク MM/memo CZブックマーク livedoorクリップ はてなブックマーク Buzzurl（バザール）

上に戻る