| Oracle® Fusion Middleware Oracle WebLogic Server JMX による管理の容易なアプリケーションの開発 11g リリース 1 (10.3.1) B55538-01 |
|
 戻る |
 次へ |
| Oracle® Fusion Middleware Oracle WebLogic Server JMX による管理の容易なアプリケーションの開発 11g リリース 1 (10.3.1) B55538-01 |
|
戻る |
次へ |
JMX 設計パターンとデプロイメント オプションを使用することで、アプリケーションの管理をより容易にすることができます。以下の節では、管理が容易なアプリケーションを設計するための Oracle のベスト プラクティスについて説明します。最後の節「その他の設計の考慮事項」では、Oracle の推奨方法に代わる方法を示すとともに、その他の設計の考慮事項について説明します。
Oracle が推奨する設計パターンは、Java クラスのインスツルメンテーションが以下の条件を満たすことを前提としています。
できるだけ少ないシステム リソースを使用し、管理機能がビジネス機能に干渉しない。
可能な限りビジネス コードから分離する。
ビジネス コードと一緒にデプロイされ、そのライフサイクルを共有する。開発者は、運用スタッフが余計な手順を実行しなくてもアプリケーションを管理できるようにする必要があります。
JMX ではさまざまな設計パターンが定義されていますが、その中でも、最も簡単に記述できる標準 MBean を使用することをお勧めします。標準 MBean を使用する最も単純な設計パターンでは、以下のことを行います。
エクスポーズする管理プロパティと管理オペレーションのインタフェースを作成します。
インタフェースを Java クラスに実装します。
実行時 MBean サーバの javax.management.MBeanServerConnection.createMBean() メソッドを呼び出して、管理インタフェースをこのメソッドのパラメータで渡すことによって、WebLogic Server 実行時 MBean サーバで MBean を作成および登録します。
createMBean() メソッドを呼び出すと、実行時 MBean サーバは、インタフェースを内部参照し、実装を見つけ、インタフェースと実装を MBean として登録します。
この設計パターンでは、管理インタフェースとその実装は、MBean サーバがインタフェースを内部参照できるように、厳格な命名規約に準拠していなければなりません。この命名要件を回避するには、Java クラスを javax.management.StandardMBean の拡張にします。http://java.sun.com/javase/6/docs/api/javax/management/StandardMBean.html にある J2SE 6.0 API 仕様の「StandardMBean」を参照してください。
JVM には、複数の MBean サーバが存在できます。設計上、ここで決定しなけれならないのは、どの MBean サーバを使用してカスタム MBean を登録するかということです。
カスタム MBean は、WebLogic Server 実行時 MBean サーバに登録することをお勧めします (各 WebLogic Server インスタンスには、実行時 MBean サーバの独自のインスタンスが含まれます。『Oracle Fusion Middleware Oracle WebLogic Server JMX によるカスタム管理ユーティリティの開発』の「MBean サーバ」を参照してください。)その場合、以下のことに留意してください。
MBean は WebLogic Server MBean と同じ MBean サーバに存在する。リモート JMX クライアントは、アプリケーションの MBean と WebLogic Server MBean をモニタするための接続を 1 つだけ維持する必要があります。
JMX クライアントがカスタム MBean と WebLogic Server MBean にアクセスするには、WebLogic Server セキュリティ フレームワークを通して認証と認可を受けなければならない。
WebLogic Server 実行時 MBean サーバは、その javax.management.MBeanServer インタフェースを JNDI ツリーに登録します。『Oracle Fusion Middleware Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発』の「実行時 MBean サーバへのローカル接続の作成」を参照してください。
JDK 1.5 から、JVM (ローカル プロセス) 内のプロセスはプラットフォーム MBean サーバをインスタンス化できるようになりました。この MBean サーバは JDK によって提供され、JVM 自体をモニタするための MBean を備えています。
ローカル プロセスでこの MBean サーバにカスタム MBean を登録できますが、カスタム MBean は、WebLogic Server セキュリティ フレームワークで保護されず、JMX クライアントは複数の MBean サーバに接続してアプリケーションの MBean および WebLogic Server MBean をモニタする必要があります。JMX クライアントが単一の MBean サーバを介してカスタム MBean、WebLogic Server MBean、および JVM プラットフォーム MBean をモニタできるようにする必要がある場合、実行時 MBean サーバを JVM プラットフォーム MBean サーバとしてコンフィグレーションできます。「JVM プラットフォーム MBean サーバへの MBean の登録」を参照してください。
管理対象サーバにある他の MBeans で実行を呼び出す集約タイプ MBeans を登録する必要がある場合は、MBeans をドメイン実行時 MBean サーバに登録します。
WebLogic Server ドメイン実行時 MBean サーバは、その javax.management.MBeanServer インタフェースを JNDI ツリーに登録します。『Oracle Fusion Middleware Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発』の「実行時 MBean サーバへのローカル接続の作成」を参照してください。
EJB、Web アプリケーションのサーブレット、またはデプロイされているその他のモジュール用の MBean を作成し、その MBean をアプリケーションのデプロイと同時に使用できるようにする場合、デプロイメント サービスからの通知をリスンします。アプリケーションをデプロイ (およびデプロイ済みのアプリケーションが存在するサーバを起動) するときに、WebLogic Server デプロイメント サービスはデプロイメント プロセスの特定の段階で通知を送信します。アプリケーションがデプロイされたことを示す通知を受信したら、MBean を作成および登録できます。
ApplicationLifecycleListener でデプロイメント通知をリスンするには、以下の 2 つの手順を行います。
weblogic.application.ApplicationLifecycleListener の拡張クラスを作成します。次に、MBean を作成して MBean サーバに登録するための ApplicationLifecycleListener.postStart メソッドを実装します。このクラスは、デプロイメント サービスからの postStart 通知の受信後に postStart() メソッドを呼び出します。『WebLogic Server アプリケーションの開発』の「アプリケーション ライフサイクル イベントのプログラミング」を参照してください。
weblogic-application.xml デプロイメント記述子で、作成したクラスをアプリケーション リスナ クラスとして登録します。
独自の WebLogic Server クラスとデプロイメント記述子を使用せずにアプリケーション MBean を登録する場合は、「JDK クラスのみを使用したアプリケーション MBean の登録」を参照してください。
MBean の作成方法に関係なく、アプリケーションがアンデプロイされたことを伝えるデプロイメント通知を受信したときに MBean の登録を解除することをお勧めします。このようにしない場合、メモリ リークが発生する可能性があります。
ApplicationLifecycleListener の拡張クラスを作成する場合、ApplicationLifecycleListener.preStop メソッドを実装して MBean の登録を解除できます。preStop メソッドの実装については、「MBean の登録」を参照してください。
任意のタイプの EJB (セッション、エンティティ、メッセージ駆動型) またはサーブレットの管理属性と管理オペレーションをエクスポーズする場合、管理属性と管理オペレーションを独立した委託クラスに実装して、EJB またはサーブレット実装クラスがビジネス ロジックだけで構成され、そのビジネス インタフェースがビジネス ロジックだけを表すようにすることをお勧めします。「図 3-1」を参照してください。
図 3-1 では、EJB のビジネス メソッドは、そのデータを委託クラスにプッシュします。たとえば、特定のビジネス メソッドが呼び出されるたびに、そのメソッドは委託クラスのカウンタを増分し、MBean インタフェースはカウンタ値を属性としてエクスポーズします。この方法の例については、MedRec サンプル サーバを参照してください。
このようにビジネス ロジックを管理ロジックから分離した場合、特に委託クラスのカウンタが頻繁に増分されるような条件では、ロジックを同じクラスに組み込んだ場合より効率が悪くなる可能性があります。しかし、実際には、ほとんどの JVM はメソッド呼び出しを最適化することによって効率の低下をごくわずかなものにとどめます。
使用するアプリケーションでこのわずかな違いを許容できない場合、EJB のビジネス クラスに管理値を組み込み、JMX クライアントからの要求時に委託クラスがその値を取得できるようにします。
リモート JMX クライアントがカスタム MBean にアクセスする場合、MBean 属性のデータ型とオペレーションが返すデータ型を javax.management.openmbean.OpenType に定義したデータ型に制限することをお勧めします。すべての JVM はこれらの基本型にアクセスできます。http://java.sun.com/javase/6/docs/api/javax/management/openmbean/OpenType.html にある J2SE 6.0 API 仕様の「OpenType」を参照してください。
MBean がその他のデータ型をエクスポーズする場合、それらのデータ型はシリアライズ可能でなければならず、リモート JMX クライアントのクラス パスにそれらのデータ型が存在しなければなりません。
MBean は、通知を送信するたびにメモリとネットワーク リソースを使用します。MBean 属性の値が頻繁に変更される場合、このようなメモリとリソースの利用は望ましくありません。
属性が変更されるたびに通知を送信するように MBean をコンフィグレーションする代わりに、モニタ MBean を使用してカスタム MBean を定期的にポーリングすることによって、属性が変更されたかどうかを調べることをお勧めします。モニタ MBean をコンフィグレーションすると、属性が特定の方法で変更された場合、または特定のしきい値に達した場合にのみ通知を送信できます。
詳細については、『Oracle Fusion Middleware Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発』の「ベスト プラクティス : 直接的なリスンとモニタ」を参照してださい。
管理が容易なアプリケーションを設計する場合には、Oracle のベスト プラクティスに加えて、以下の考慮事項にも留意してください。
JMX クライアントが単一の MBean サーバを介してカスタム MBean、WebLogic Server MBean、および JVM プラットフォーム MBean をモニタできるようにする必要がある場合、実行時 MBean サーバを JVM プラットフォーム MBean サーバとしてコンフィグレーションできます。その場合、以下のことに留意してください。
ローカル アプリケーションは、java.lang.management.ManagementFactory.getPlatformMBeanServer() が返す MBeanServer インタフェースを介してすべての MBean にアクセスできます。
|
注意 : このローカル アクセスでは、認可されたユーザのみが WebLogic Server MBean にアクセスできるようにする WebLogic Server のセキュリティ チェックがありません。JVM 内で実行されているすべてのアプリケーションが、実行時 MBean サーバまたは JDK プラットフォーム MBean サーバの任意の WebLogic Server MBean にアクセスできます。JVM 内で実行されているアプリケーションを制御または信頼できない場合は、このコンフィグレーションを使用しないでください。 |
リモート JMX クライアントがカスタム MBean、JMX MBean、および WebLogic Server MBean にアクセスできるようにする場合、以下のコンフィグレーションを検討してください。
WebLogic Server 実行時 MBean サーバをプラットフォーム MBean サーバとしてコンフィグレーションする。
プラットフォーム MBean サーバへのリモート アクセスを有効にしない。
プラットフォーム MBean サーバへのリモート アクセスは、標準の JDK 1.6 セキュリティ機能によってのみ保護される (http://java.sun.com/javase/6/docs/technotes/guides/management/agent.html を参照)。WebLogic Server 実行時 MBean サーバをプラットフォーム MBean サーバとしてコンフィグレーションした場合、プラットフォーム MBean サーバへのリモート アクセスを有効にすると WebLogic Server MBean へのアクセス パスが作成されます。このアクセス パスは、WebLogic Server セキュリティ フレームワークでは保護されません。
リモート JMX クライアントは、実行時 MBean サーバに接続することによって JVM MBean にアクセスする。
WebLogic 実行時 MBean サーバを JDK プラットフォーム MBean サーバとしてコンフィグレーションするには、WebLogic JMXMBean PlatformMBeanServerEnabled 属性を true に設定して、ドメイン内のサーバを再起動します。『Oracle Fusion Middleware Oracle WebLogic Server MBean リファレンス』の「JMXMBean」を参照してください。
MBean がその親アプリケーションのライフサイクルを共有するようにするための最も簡単な方法は、Oracle の ApplicationLifecycleListener を使用することです。独自の WebLogic Server クラスとデプロイメント記述子要素を使用せずにサーブレットまたは EJB を管理する場合、以下のことを実行します。
サーブレットの場合、サーブレットが特定のメソッドを呼び出すとき、またはサーブレット自身がインスタンス化されるときに MBean を作成および登録する javax.servlet.Filter をコンフィグレーションします。http://java.sun.com/javaee/5/docs/api/javax/servlet/Filter.html にある Java EE 5.0 API 仕様の「フィルタ」を参照してください。
EJB の場合、MBean を作成および登録するための javax.ejb.EntityBean.ejbActivate() メソッドを実装します。そのインスタンスが単一の MBean インスタンスを共有するセッション EJB の場合、存在しない場合にのみ MBean を作成および登録するロジックを組み込みます。http://java.sun.com/javaee/5/docs/api/javax/ejb/EntityBean.html にある Java EE 5.0 API 仕様の「EntityBean」を参照してください。
ビジネス オブジェクトごとに 1 つの管理対象オブジェクトを設計する場合、管理オブジェクトとビジネス オブジェクトの関係についての要件は存在しません。1 つの管理オブジェクトが複数のビジネス オブジェクトからの情報を集約することも、反対に 1 つのビジネス オブジェクトからの情報を複数の管理対象オブジェクトに分割することもできます。
たとえば、サーブレットが複数のヘルパー クラスを使用し、1 つの MBean でサーブレットを表す場合、各ヘルパー クラスはその管理データを 1 つの MBean 実装クラスにプッシュする必要があります。
選択する構成は、複雑な管理アーキテクチャの維持の難しさとは対照的に、システム管理者または運用スタッフに提供する MBean の数によって決まります。
管理クラスをアプリケーションの APP-INF ディレクトリにパッケージ化した場合、アプリケーションの他のすべてのクラスがそれらにアクセスできます。管理クラスをモジュールのアーカイブ ファイルにパッケージ化した場合、それらにアクセスできるのはモジュールだけです。
たとえば、あるアプリケーションに複数の Web アプリケーションが含まれており、それぞれに EJB1 というセッション EJB のコピーが存在するとします。1 つの MBean ですべてのアプリケーションのセッション EJB のコピーに関する情報を収集する場合、MBean のクラスを APP-INF ディレクトリにパッケージ化する必要があります。Web アプリケーションの EJB のコピーがそれぞれ MBean のコピーを保持するように設定する場合、MBean のクラスを EJB の JAR ファイルにパッケージ化します。クラスを EJB の JAR にパッケージ化した場合、JAR を Web アプリケーションにコピーするときに MBean クラスを各 Web アプリケーションに配布します。
MBean を WebLogic Server 実行時 MBean サーバに登録する場合、アクセスは、WebLogic Server セキュリティ フレームワークを使用して認証および認可されたユーザのみに制限するだけでなく、ロールおよびポリシーを作成することによってさらに制限できます。セキュリティ グループなどのセキュリティ ロールによって、ユーザに ID が付与されます。ただしグループとは違い、ロールのメンバシップは実行時に評価される条件群に基づいて動作できます。セキュリティ ポリシーは、リソースにアクセス可能なユーザ、グループ、またはロールを指定する、別の一連の実行時条件です。
ロールおよびポリシーを使ったカスタム MBean の保護には、次の制約があります。
MBean のオブジェクト名に「Type=value」キー プロパティが含まれている必要がある。
ロールおよびポリシーを XACML 2.0 ドキュメントに記述し、WebLogic Scripting Tool を使用してそのデータをレルムに追加する必要がある。
XACML ドキュメントで認可ポリシーを記述する場合、セキュリティ レルムでは、WebLogic Server XACML 認可プロバイダ、または weblogic.management.security.authorization.PolicyStoreMBean インタフェースを実装する別の特定のプロバイダを使用する必要がある。
XACML ドキュメントでロールの割り当てを記述する場合、セキュリティ レルムでは、WebLogic Server XACML ロール マッピング プロバイダ、または weblogic.management.security.authorization.PolicyStoreMBean インタフェースを実装する別の特定のプロバイダを使用する必要がある。
XACML ロールおよびポリシーの作成とレルムへの追加の詳細については、『Oracle Fusion Middleware Oracle WebLogic Server ロールおよびポリシーによるリソースの保護』の「XACML ドキュメントによる WebLogic リソースの保護」を参照してください。
