ヘッダーをスキップ
Oracle® Fusion Middleware Oracle WebLogic Server JMXによる管理の容易なアプリケーションの開発
11gリリース1 (10.3.6)
B55538-05
  ドキュメント・ライブラリへ移動
ライブラリ		 製品リストへ移動
製品		 目次へ移動
目次
前
前 		 次
次		  

3 管理の容易なアプリケーションの設計

JMX設計パターンとデプロイメント・オプションを使用することで、アプリケーションの管理をより容易にすることができます。以下の節では、管理が容易なアプリケーションを設計するためのOracleのベスト・プラクティスについて説明します。最後の節「その他の設計の考慮事項」では、Oracleの推奨方法にかわる方法を示すとともに、その他の設計の考慮事項について説明します。

Oracleのベスト・プラクティスの利点

Oracleが推奨する設計パターンは、Javaクラスのインストゥルメンテーションが以下の条件を満たすことを前提としています。

標準MBeanの使用

JMXでは様々な設計パターンが定義されていますが、その中でも、最も簡単に記述できる標準MBeanを使用することをお薦めします。標準MBeanを使用する最も単純な設計パターンでは、以下のことを行います。

  1. 公開する管理プロパティと管理操作のインタフェースを作成します。

  2. インタフェースをJavaクラスに実装します。

  3. 実行時MBeanサーバーのjavax.management.MBeanServerConnection.createMBean()メソッドを呼び出して、管理インタフェースをこのメソッドのパラメータで渡すことによって、WebLogic Server実行時MBeanサーバーでMBeanを作成および登録します。

    createMBean()メソッドを呼び出すと、実行時MBeanサーバーは、インタフェースを内部参照し、実装を見つけ、インタフェースと実装をMBeanとして登録します。

この設計パターンでは、管理インタフェースとその実装は、MBeanサーバーがインタフェースを内部参照できるように、厳格なネーミング・ルールに準拠していなければなりません。この命名要件を回避するには、Javaクラスをjavax.management.StandardMBeanの拡張にします。http://download.oracle.com/javase/6/docs/api/javax/management/StandardMBean.htmlにあるJava SE 6.0 API仕様の「StandardMBean」を参照してください。

WebLogic Server実行時BeanサーバーへのカスタムMBeanの登録

JVMには、複数のMBeanサーバーが存在できます。設計上、ここで決定しなけれならないのは、どのMBeanサーバーを使用してカスタムMBeanを登録するかということです。

カスタムMBeanは、WebLogic Server実行時MBeanサーバーに登録することをお薦めします(各WebLogic Serverインスタンスには、実行時MBeanサーバーの独自のインスタンスが含まれます。『Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発』のMBeanサーバーに関する項を参照してください。)WebLogic Server 10.3.3以降では、WebLogic実行時MBeanサーバーはJVMのプラットフォームMBeanサーバーです。「JVMプラットフォームMBeanサーバーへのMBeanの登録」を参照してください。

その場合、次のことに留意してください。

WebLogic Server実行時MBeanサーバーは、そのjavax.management.MBeanServerインタフェースをJNDIツリーに登録します。『Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発』の実行時MBeanサーバーへのローカル接続に関する項を参照してください。

ドメイン実行時MBeanサーバーへのカスタムMBeanの登録

管理対象サーバーにある他のMBeansで実行を呼び出す集約タイプMBeansを登録する必要がある場合は、MBeansをドメイン実行時MBeanサーバーに登録します。

WebLogic Serverドメイン実行時MBeanサーバーは、そのjavax.management.MBeanServerインタフェースをJNDIツリーに登録します。『Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発』のドメインの実行時MBeanサーバーへのローカル接続に関する項を参照してください。

ApplicationLifecycleListenerを使用したアプリケーションMBeanの登録

EJB、Webアプリケーションのサーブレット、またはデプロイされているその他のモジュール用のMBeanを作成し、そのMBeanをアプリケーションのデプロイと同時に使用できるようにする場合、デプロイメント・サービスからの通知をリスニングします。アプリケーションをデプロイ(およびデプロイ済みのアプリケーションが存在するサーバーを起動)するときに、WebLogic Serverデプロイメント・サービスはデプロイメント・プロセスの特定の段階で通知を送信します。アプリケーションがデプロイされたことを示す通知を受信したら、MBeanを作成および登録できます。

ApplicationLifecycleListenerでデプロイメント通知をリスニングするには、以下の2つの手順を行います。

  1. weblogic.application.ApplicationLifecycleListenerの拡張クラスを作成します。次に、MBeanを作成してMBeanサーバーに登録するためのApplicationLifecycleListener.postStartメソッドを実装します。このクラスは、デプロイメント・サービスからのpostStart通知の受信後にpostStart()メソッドを呼び出します。『WebLogic Serverアプリケーションの開発』のアプリケーション・ライフサイクル・イベントのプログラミングに関する項を参照してください。

  2. weblogic-application.xmlデプロイメント記述子で、作成したクラスをアプリケーション・リスナー・クラスとして登録します。

独自のWebLogic Serverクラスとデプロイメント記述子を使用せずにアプリケーションMBeanを登録する場合は、「JDKクラスのみを使用したアプリケーションMBeanの登録」を参照してください。

アプリケーションのアンデプロイ時のアプリケーションMBeanの登録解除

MBeanの作成方法に関係なく、アプリケーションがアンデプロイされたことを伝えるデプロイメント通知を受信したときにMBeanの登録を解除することをお薦めします。このようにしない場合、メモリー・リークが発生する可能性があります。

ApplicationLifecycleListenerの拡張クラスを作成する場合、ApplicationLifecycleListener.preStopメソッドを実装してMBeanの登録を解除できます。preStopメソッドの実装については、「MBeanの登録」を参照してください。

EJBおよびサーブレットから委託クラスへの管理ロジックの配置

任意のタイプのEJB (セッション、エンティティ、メッセージドリブン)またはサーブレットの管理属性と管理操作を公開する場合、管理属性と管理操作を独立した委託クラスに実装して、EJBまたはサーブレット実装クラスがビジネス・ロジックだけで構成され、そのビジネス・インタフェースがビジネス・ロジックだけを表すようにすることをお薦めします。「図3-1」を参照してください。

図3-1 管理プロパティおよび操作の委託クラスへの配置

図3-1の説明が続きます
「図3-1 理プロパティおよび操作の委託クラスへの配置」の説明

図3-1では、EJBのビジネス・メソッドは、そのデータを委託クラスにプッシュします。たとえば、特定のビジネス・メソッドが呼び出されるたびに、そのメソッドは委託クラスのカウンタを増分し、MBeanインタフェースはカウンタ値を属性として公開します。この方法の例については、MedRecサンプル・サーバーを参照してください。

このようにビジネス・ロジックを管理ロジックから分離した場合、特に委託クラスのカウンタが頻繁に増分されるような条件では、ロジックを同じクラスに組み込んだ場合より効率が悪くなる可能性があります。しかし、実際には、ほとんどのJVMはメソッド呼出しを最適化することによって効率の低下をごくわずかなものにとどめます。

使用するアプリケーションでこのわずかな違いを許容できない場合、EJBのビジネス・クラスに管理値を組み込み、JMXクライアントからの要求時に委託クラスがその値を取得できるようにします。

オープンMBeanデータ型の使用

リモートJMXクライアントがカスタムMBeanにアクセスする場合、MBean属性のデータ型と操作が返すデータ型をjavax.management.openmbean.OpenTypeに定義したデータ型に制限することをお薦めします。すべてのJVMはこれらのベース・タイプにアクセスできます。http://download.oracle.com/javase/6/docs/api/javax/management/openmbean/OpenType.htmlにあるJava SE 6.0 API仕様の「OpenType」を参照してください。

MBeanがその他のデータ型を公開する場合、それらのデータ型はシリアライズ可能でなければならず、リモートJMXクライアントのクラス・パスにそれらのデータ型が存在しなければなりません。

必要時のみの通知の送信

MBeanは、通知を送信するたびにメモリーとネットワーク・リソースを使用します。MBean属性の値が頻繁に変更される場合、このようなメモリーとリソースの利用は望ましくありません。

属性が変更されるたびに通知を送信するようにMBeanを構成するかわりに、モニターMBeanを使用してカスタムMBeanを定期的にポーリングすることによって、属性が変更されたかどうかを調べることをお薦めします。モニターMBeanを構成すると、属性が特定の方法で変更された場合、または特定のしきい値に達した場合にのみ通知を送信できます。

詳細は、『Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発』の直接的なリスニングとモニターのベスト・プラクティスに関する項を参照してください。

その他の設計の考慮事項

管理が容易なアプリケーションを設計する場合には、Oracleのベスト・プラクティスに加えて、以下の考慮事項にも留意してください。

JVMプラットフォームMBeanサーバーへのMBeanの登録

WebLogic Serverのこのリリースは、WebLogic実行時MBeanサーバーはJVMのプラットフォームMBeanサーバーです。したがって、JMXクライアントは1つのMBeanサーバーを介して、カスタムMBean、WebLogic Server MBean、およびJVMのプラットフォームMXBeanをモニターすることができます。その場合、次のことに留意してください。

  • ローカル・アプリケーションは、java.lang.management.ManagementFactory.getPlatformMBeanServer()が返すMBeanServerインタフェースを介してすべてのMBeanにアクセスできます。

  • リモートJMXクライアントがカスタムMBean、プラットフォームMXBean、およびWebLogic Server MBeanにアクセスできるようにする場合、次の構成を検討してください。

    • デフォルトでは、WebLogic Server実行時MBeanサーバーはプラットフォームMBeanサーバーとして構成されます。

    • プラットフォームMBeanサーバーへのリモート・アクセスを有効にしません。

    • リモートJMXクライアントは、実行時MBeanサーバーに接続することによってプラットフォームMXBeanにアクセスします。

詳細は、『Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発』のプラットフォームMBeanサーバーの使用に関する項を参照してください。

JDKクラスのみを使用したアプリケーションMBeanの登録

MBeanがその親アプリケーションのライフサイクルを共有するようにするための最も簡単な方法は、OracleのApplicationLifecycleListenerを使用することです。独自のWebLogic Serverクラスとデプロイメント記述子要素を使用せずにサーブレットまたはEJBを管理する場合、以下のことを実行します。

  • サーブレットの場合、サーブレットが特定のメソッドを呼び出すとき、またはサーブレット自身がインスタンス化されるときにMBeanを作成および登録するjavax.servlet.Filterを構成します。http://download.oracle.com/javaee/5/api/javax/servlet/Filter.htmlにあるJava EE 5.0 API仕様の「Filter」を参照してください。

  • EJBの場合、MBeanを作成および登録するためのjavax.ejb.EntityBean.ejbActivate()メソッドを実装します。そのインスタンスが単一のMBeanインスタンスを共有するセッションEJBの場合、存在しない場合にのみMBeanを作成および登録するロジックを組み込みます。http://download.oracle.com/javaee/5/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の保護

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 WebLogic Serverロールおよびポリシーによるリソースの保護』のXACMLドキュメントによるWebLogicリソースの保護に関する項を参照してください。

  前
前 		 次
次
  ドキュメント・ライブラリへ移動
ライブラリ		 製品リストへ移動
製品		 目次へ移動
目次