WebLogic JMS の管理

Administration Console は、JMS を含む WebLogic Server の機能を有効化、コンフィグレーション、およびモニタするためのインタフェースを備えています。Administration Console を起動する手順については、『管理者ガイド』の「dministration Console の起動と使い方」を参照してください。

以下の節では、WebLogic JMS のコンフィグレーションおよびモニタについて概説します。

Administration Console を使用して、以下のコンフィグレーション属性を定義します。

WebLogic JMS では、一部のコンフィグレーション属性に対して、デフォルト値が用意されていますが、それ以外のすべての属性に対しては値を指定する必要があります。コンフィグレーション属性に対して無効な値を指定した場合や、デフォルト値が存在しない属性に対して値を指定しなかった場合は、再起動時に JMS が起動されません。製品には、JMS のサンプルコンフィグレーションが用意されています。

以前のリリースから移行する場合、コンフィグレーション情報は自動的に変換されます (既存のアプリケーションの移植を参照)。

注意: コンフィグレーションチェックリストにあるチェックリストでは、各種 JMS 機能をサポートするための必須属性やオプション属性を確認できます。

WebLogic Server のクラスタはより強力で、より信頼性のあるアプリケーションプラットフォームを提供するためのサーバ群です。クラスタはそのクライアントにとって単一のサーバに見えますが、実際には、一体で機能するサーバ群です。クラスタは、単一のサーバを超える下記の 3 つの重要な機能を提供します。

クラスタ化されたサービスは、クラスタ内の複数のサーバで利用できる API またはインタフェースです。

注意: JMS クライアントは、WebLogic Server が異なるドメインに存在する場合でも、ユニークな WebLogic Server 名に依存してクラスタにアクセスします。そのため、JMS クライアントがアクセスするすべての WebLogic Server にはユニークなサーバ名を付ける必要があります。

複数の接続ファクトリをコンフィグレーションし、対象を使用してそれらを WebLogic Server に割り当てることで、クラスタ内のあらゆるサーバから送り先へのクラスタワイドで透過的なアクセスを確立できます。ただし、複数の WebLogic Server に正常にデプロイするには、各接続ファクトリの名前がユニークであることが必要です。管理者は、クラスタ内のさまざまなノード上の複数の JMS サーバにユニークな名前が付けられているかぎり、それらの JMS サーバをコンフィグレーションして JMS 送り先を割り当てることができます。

アプリケーションでは、Java Naming and Directory Interface (JNDI) を使用して接続ファクトリをルックアップし、JMS サーバとの通信を確立するための接続を作成します。各 JMS サーバでは、複数の送り先に対するリクエストが処理されます。JMS サーバで処理されない送り先へのリクエストは、適切な WebLogic Server に転送されます。

以下のガイドラインは、単一の WebLogic ドメイン環境またはマルチドメイン環境におけるクラスタ環境で機能するように WebLogic JMS をコンフィグレーションする場合にのみ適用されます。

WebLogic JMS 管理者は、クラスタ内の単一の分散送り先セットの一部として複数の送り先をコンフィグレーションすることもできます。プロデューサとコンシューマは、その分散送り先に対して送受信することができます。クラスタ内のサーバ 1 台に障害が発生した場合、WebLogic JMS では、分散送り先セット内の可能な物理的送り先全体にわたって負荷が分散されます。詳細については、『管理者ガイド』の「分散送り先のコンフィグレーション」を参照してください。

WebLogic JMS は、クラスタ環境用の WebLogic Server コアに実装されている移行フレームワークを利用します。これにより、WebLogic JMS は、移行リクエストに適切に応答し、JMS サーバを正しい順序でオンラインまたはオフラインにすることができます。これには、スケジューリングされた移行だけでなく、WebLogic Server の障害への対応としての移行も含まれます。詳細については、JMS 移行可能対象のコンフィグレーションを参照してください。

クラスタ環境で WebLogic JMS を使用するには、以下の作業が必要です。

WebLogic 7.0 のクラスタ環境の一部である WebLogic JMS の実装では、JMS は、単一の WebLogic Server に障害が発生した場合、単一の分散送り先セットの一部として複数の物理的送り先 (キューとトピック) をコンフィグレーションすることで、サービスを継続します。さらに、移行可能サービスの機能を実装すると、JMS のような固定された「1 回限りの」サービスによって、クラスタ内にある依存するアプリケーションに対してシングルポイント障害が発生しなくなります。

ただし、自動フェイルオーバは現在 WebLogic JMS でサポートされていません。手動フェイルオーバの実行の詳細については、WebLogic Server の障害からの回復を参照してください。

WebLogic JMS は「1 回限りの」サービスなので、クラスタ内のすべての WebLogic Server のインスタンスに対してアクティブというわけではありません。代わりに、データの一貫性を保持するためにクラスタ内の単一サーバに「固定」されます。固定されたサービスにより、クラスタ内にある依存するアプリケーションに対してシングルポイント障害が発生しないように、移行できる対象リスト内のあらゆるサーバをコンフィグレーションして、1 回だけサービスを移行するようにできます。

WebLogic JMS では、Administration Console の説明にあるとおり、移行フレームワークを活用して、管理者が JMS サーバに対する移行できる対象を指定できます。いったん適切にコンフィグレーションすると、JMS サーバとその送り先すべてを別の WebLogic Server へ移行することができます。

これにより、WebLogic JMS は、移行リクエストに適切に応答し、JMS サーバを正しい順序でオンラインまたはオフラインにすることができます。移行には、スケジューリング済み移行のほかに、クラスタ内の WebLogic Server の障害に応答して発生する移行が含まれます。

移行できる対象の定義の詳細については、『WebLogic Server クラスタユーザーズガイド』の「固定サービスの移行」を参照してください。

WebLogic のクラスタ環境の一部として実装する場合、WebLogic JMS では weblogic.cluster.Migratable インタフェースが実装され、これによって JMS サービスがアクティブ化リクエストおよび非アクティブ化リクエストに応答できるようになります。

表3-1 WebLogic JMS の移行手順

移行状況	起こること
初期化	JMS サーバの初期化には、あらゆるコンフィグレーション情報またはデプロイメント情報の処理、および適切なオブジェクトの作成などの作業が含まれる。この時点では、送り先および JMS リソースは利用できない。さらに、永続ストレージの完全性を低下させる可能性があるので、永続ストレージはオープンされていない。JMS サーバでは、初期化とアクティベーションの間で発生するコンフィグレーションの変更を処理する準備ができている。
アクティベーション	JMS サーバがアクティブになると、永続ストレージがオープンし、必要なあらゆる回復が実行され、ストレージの内容と現在のコンフィグレーションとの整合性がとられ、アプリケーションから送り先にアクセスできるようになる。さらに、アクティベーションが完了すると、コンフィグレーションされたあらゆるサーバセッションプールの処理が開始される。
非アクティベーション	JMS サーバが非アクティブ化されると、サーバセッションプールの処理がすべて停止され、すべての送り先が利用不可となり、永続ストレージがフラッシュおよびクローズされ、送り先がパージされ、JMS サーバのすべてのオブジェクトが削除される。

クラスタ環境で WebLogic JMS を移行可能なサービスとするには、以下の作業が必要です。

Weblogic JMS 永続ストレージは、JMS サーバとともに移行できません。したがって、JMS サーバを移行した後にほかの物理マシンから永続ストレージへのアクセスを必要とするアプリケーションでは、次のように代替のソリューションを実装する必要があります。

WebLogic Server の障害の回復手順については、『管理者ガイド』の「JMS の管理」を参照してください。

以下の節では、WebLogic JMS で利用できる管理パフォーマンスチューニング機能を実装することによって、アプリケーションを最大限に活用する方法について説明します。

JMS サーバ、接続、セッション、送り先、恒久サブスクライバ、メッセージプロデューサ、メッセージコンシューマ、サーバセッションプールなどの JMS オブジェクトに関する統計が提供されます。Administration Console を使用して JMS 統計をモニタできます。

サーバの実行中は、JMS 統計は増え続けます。サーバを再起動するときにのみ、統計をリセットできます。

WebLogic JMS のコンフィグレーションとモニタの詳細については、『管理者ガイド』の「JMS の管理」を参照してください。

WebLogic JMS をコンフィグレーションしたら、アプリケーションで JMS API を使用してメッセージの送受信ができるようになります。詳細については、WebLogic JMS アプリケーションの開発を参照してください。

WebLogic Server の障害からの回復手順、手動フェイルオーバの実行手順、およびプログラミングの考慮事項については、『管理者ガイド』の「JMS の管理」を参照してください。