WebLogic JMS のコンフィグレーションと管理
|
 |
 |
|
以下の節では、WebLogic JMS のさまざまな概念と機能を簡単に紹介し、それらと他のアプリケーション コンポーネントおよび WebLogic Server との連携の仕組みについて説明します。
この章は、Java のプログラミングおよび JMS 1.1 の概念と機能に精通している読者を対象としています。
JMS の WebLogic Server 実装は、WebLogic Server プラットフォームに緊密に統合されたエンタープライズ クラスのメッセージング システムです。WebLogic JMS は、JMS 1.1 仕様を完全にサポートし、標準 JMS API を超えるさまざまな WebLogic JMS 拡張機能を提供します。
エンタープライズ メッセージング システムを使用すると、アプリケーションどうしがメッセージを交換することによって通信できます。メッセージとは、異なるアプリケーション間の通信を調整するために必要な情報が含まれている、要求、レポート、およびイベントです。メッセージで提供される抽象化の階層により、送り先システムについての詳細情報をアプリケーション コードから切り離すことができます。
Java Message Service (JMS) は、業界メッセージング プロバイダによって実装されるエンタープライズ メッセージング システムにアクセスするための標準 API です。具体的な JMS の特長は以下のとおりです。
WebLogic JMS は、プロデューサ アプリケーションからメッセージを受信し、そのメッセージをコンシューマ アプリケーションに配信します。WebLogic Server での JMS API プログラミングの詳細については、『WebLogic JMS プログラマーズ ガイド』を参照してください。
次の図は、WebLogic JMS のアーキテクチャを示しています。
WebLogic JMS アーキテクチャの主要コンポーネントは以下のとおりです。
weblogic-jmsmd.xsd スキーマに準拠する XML ドキュメントによって定義されます。
一般に、WebLogic Server ドメイン コンフィグレーション ファイル (config.xml) には、ドメインに必要なコンフィグレーション情報が記述されています。このコンフィグレーション情報をさらに分類すると、環境関連の情報とアプリケーション関連の情報に分けられます。環境関連の情報には、JMS サーバの ID と定義、JDBC データ ソース、WebLogic 永続ストア、サーバ ネットワーク アドレスなどがあります。通常、これらのシステム リソースは、ドメインごとにユニークです。
これらのシステム リソースのコンフィグレーションと管理を行うのは、WebLogic 管理者です。WebLogic 管理者は、組織のシステム管理者または MIS 部門からこの情報を受け取ります。これらの管理タスクを実行するために、管理者は WebLogic Administration Console、WebLogic Scripting Tool (WLST) などのコマンドライン ツール、またはプログラムによる管理用の JMX API を使用できます。
ドメイン環境に依存しないアプリケーション関連の定義の例としては、さまざまな J2EE アプリケーション コンポーネント コンフィグレーション (EAR、WAR、JAR、RAR の各ファイル、JMS および JDBC モジュールなど) があります。アプリケーション コンポーネントは、アプリケーション開発チームによって開発およびパッケージ化され、さらにプログラム (コンパイル済み Java コード) とそのコンフィグレーション情報 (記述子とも呼ばれ、そのほとんどは XML ファイルとして格納される) を持つ場合があります。ただし、JMS および JDBC モジュールの場合、コンパイル済み Java コードは含まれません。あらかじめパッケージ化されたこれらのアプリケーションは、WebLogic Server 管理者によって WebLogic ドメインにデプロイされます。
WebLogic Server には、Administration Console や weblogic.Deployer コマンドライン ユーティリティなど、アプリケーションをデプロイするためのツールが用意されています。アプリケーションをデプロイするプロセスによって、アプリケーション コンポーネントと環境固有のリソース定義がリンクされます。たとえば、特定のアプリケーション コンポーネントをホストするサーバ インスタンス (対象指定) や、JMS メッセージを保持する WebLogic 永続ストアなどです。
最初のデプロイメントの完了後は、デプロイされたアプリケーションに対する管理者の権限は限定されます。たとえば、管理者はアプリケーションの適切なライフサイクルの保持 (デプロイ、アンデプロイ、再デプロイ、削除など) とパラメータの調整 (クライアントのニーズに合わせてアプリケーションのインスタンス数を増減するなど) しか行うことができません。ライフサイクルとチューニング以外の変更は、アプリケーション開発チームによって行われます。
WebLogic Server 9.0 以降では、JMS コンフィグレーション (送り先、接続ファクトリ、テンプレートなど) は WebLogic ドメインの外部のモジュール記述子ファイルに格納されます。これらのファイルは、weblogic-jmsmd.xsd スキーマに準拠する XML ドキュメントで定義されます。JMS モジュールには、JMS サーバ定義は含まれません。これらの定義は、引き続き WebLogic ドメイン コンフィグレーション ファイルに格納されます。
JMS リソースは、旧リリースの場合と同様の方法で管理するシステム モジュールか、またはアプリケーション モジュールとして作成し、管理します。JMS アプリケーション モジュールは、J2EE モジュールの WebLogic 固有の拡張機能であり、J2EE アプリケーションと共に (パッケージ化されたリソースとして)、またはグローバルに使用可能なスタンドアロン モジュールとしてデプロイできます。
JMS リソースのモジュール形式のデプロイメントでは、エンタープライズ アプリケーション ファイル (EAR ファイルなど) またはスタンドアロン JMS モジュールを開いたり、JMS を手動で再コンフィグレーションしたりすることなく、アプリケーションと必要な JMS コンフィグレーションを、ある環境から別の環境に (たとえば、テスト環境からプロダクション環境に) 移行できます。
JMS サーバは、それらの対象として指定された JMS モジュール内の JMS キューおよびトピック リソースの管理コンテナとして機能する、環境関連のコンフィグレーション エンティティです。JMS サーバの最も重要な役割は、JMS サーバの送り先が受信するすべての永続メッセージに使用される永続ストアに関する情報を管理し、また、JMS サーバの送り先で作成される恒久サブスクライバの状態を管理することです。また、対象送り先のコンテナとして、JMS サーバに対して加えられたコンフィグレーションの変更または実行時の変更をすべての送り先に対して有効にできます。
旧リリースと同じように、JMS サーバはドメインの config.xml ファイルに保持され、クラスタ内のさまざまな WebLogic Server インスタンスで複数の JMS サーバをコンフィグレーションできます (独自の名前が付けられている場合)。クライアント アプリケーションでは、JNDI ツリーまたは java:/comp/env ネーミング コンテキストを使用して接続ファクトリをルックアップし、接続を作成して JMS サーバとの通信を確立します。各 JMS サーバでは、すべての対象モジュールの送り先に対するリクエストが処理されます。JMS サーバによって処理されない送り先に対するリクエストは、適切なサーバ インスタンスに転送されます。
WebLogic Server 9.0 以降では、JMS サーバの動作が一部の点で 9.0 より前のリリースと異なります。
JMS サーバのコンフィグレーションの詳細については、「JMS サーバのコンフィグレーション」を参照してください。
Administration Console、WebLogic Scripting Tool (WLST)、または WebLogic Management Extension (JMX) ユーティリティを使用して JMS モジュールを作成する場合、WebLogic Server は、ドメイン ディレクトリの config\jms サブディレクトリに JMS モジュール ファイルを作成し、そのモジュールの参照を、ドメインの config.xml ファイルに JMSSystemResource 要素として追加します。この参照には、JMS システム モジュール ファイルへのパス、およびこのモジュールがデプロイされるサーバとクラスタのリストが含まれます。JMS モジュールは、weblogic-jmsmd.xsd スキーマに準拠します (「JMS スキーマ」を参照)。
このようにコンフィグレーションする JMS モジュールは、システム モジュールと見なされます。JMS システム モジュールは管理者が所有し、いつでもリソースを削除、変更、または追加できます。システム モジュールは、ドメインにコンフィグレーションされたサーバおよびクラスタの対象指定に対して全面的に利用できます。つまり、同じ対象にデプロイされているすべてのアプリケーションおよびクライアント アプリケーションで利用できます。システム モジュールには、JMX から JMSSystemResourceMBean としてアクセスできます。JMS システム モジュールの命名規約は、MyJMSModule-jms.xml です。
図 2-2 に、ドメインの config.xml ファイルに記述される JMS システム モジュールと、対応する config\jms ディレクトリ内のモジュールを示します。
図 2-2 config.xml から JMS システム モジュールへの参照
JMS システム モジュールまたは JMS アプリケーション モジュールの一部として、以下の基本コンフィグレーション リソースが定義されます。
また、以下の高度なクラスタ化されたコンフィグレーション リソースも、JMS システム モジュールまたは JMS アプリケーション モジュールの一部として定義されます。
これ以外のすべての JMS 環境関連リソースは、ドメイン コンフィグレーション リソースとして管理者がコンフィグレーションする必要があります。これには、以下のものが含まれます。
JMS システム モジュールのコンフィグレーションの詳細については、「JMS システム リソースのコンフィグレーション」を参照してください。
JMS コンフィグレーション リソースは、標準の J2EE 記述子ベースのモジュールと同様に、デプロイ可能なアプリケーション モジュールとしても管理できます。JMS アプリケーション モジュールは、J2EE アプリケーションと共にパッケージ化されたモジュールとして (この場合、モジュール内のリソースは同梱されたアプリケーションでのみ利用可能 (アプリケーション スコープなど)、またはそのモジュール内のリソースへのグローバル アクセスを提供するスタンドアロン モジュールとしてデプロイできます。
アプリケーション モジュールは、通常アプリケーション開発者によって作成およびパッケージ化され、WebLogic 管理者によってデプロイ、管理、およびチューニングされます。「ドメイン コンフィグレーション : 環境関連リソースとアプリケーション関連リソース」で説明したように、JMS アプリケーション モジュールにはコンパイル済みの Java プログラムがパッケージの一部として含まれていないので、管理者またはアプリケーション開発者は必要に応じた形で JMS リソースを作成したり管理したりできます。
JMS アプリケーション モジュールの詳細については、「JMS アプリケーション モジュールのデプロイメントのコンフィグレーション」を参照してください。
JMS アプリケーション モジュールは、スタンドアロン モジュールとしてデプロイできます。この場合、アプリケーション モジュールはデプロイメント プロセス中に対象指定されたサーバまたはクラスタで使用できます。この方法でデプロイされる JMS リソースは、weblogic.Deployer ユーティリティまたは Administration Console で再コンフィグレーションできますが、JMX または WLST では使用できません。しかし、WebLogic Server プラグインに付属の基本的な JSR-88 デプロイメント ツールでは、API の WebLogic Server 拡張を使用せずにスタンドアロン JMS モジュールを使用でき、J2EE アプリケーションやモジュールを WebLogic Server にコンフィグレーション、デプロイ、および再デプロイできます。
WebLogic Server のデプロイメントの詳細については、「WebLogic Server デプロイメントについて」を参照してください。スタンドアロン JMS モジュールのデプロイメントの準備については、「スタンドアロン JMS モジュールのデプロイ」を参照してください。
JMS アプリケーション モジュールは、パッケージ化されたモジュールとして J2EE エンタープライズ アプリケーション アーカイブ (EAR) に組み込むことができます。パッケージ化されたモジュールは、EAR ファイルまたは展開された EAR ディレクトリにバンドルされ、weblogic-application.xml 記述子内で参照されます。パッケージ化されたモジュールは、エンタープライズ アプリケーションと一緒にデプロイされ、そのリソースは同梱アプリケーションでのみ使用できます。パッケージ化したモジュールを使用することにより、アプリケーションは必要なリソースを常に使用でき、アプリケーションを新しい環境に移行する処理が簡素化されます。パッケージ化された JMS モジュールのデプロイメントの準備については、「エンタープライズ アプリケーションにパッケージ化された JMS モジュールのデプロイメント」を参照してください。
JMS リソースのモジュラー コンフィグレーション モデルのサポートとして、WebLogic JMS オブジェクトのスキーマ、weblogic-jmsmd.xsd (jmsmd は JMS モジュール記述子) が用意されています。JMS リソース モジュール (記述子) を作成する際は、モジュールをこのスキーマに準拠させる必要があります。IDE や他のツールでは、このスキーマに基づいて JMS リソース モジュールを検証できます。
weblogic-jmsmd.xsd スキーマは、http://www.bea.com/ns/weblogic/91/weblogic-jmsmd.xsd からオンラインで入手できます。
WebLogic JMS のコンフィグレーションと管理を理解するための鍵は、JMS リソースの作成者と作成方法によってリソースをデプロイおよび変更する方法が決まるということです。JMS モジュールは、WebLogic の管理者とプログラマがコンフィグレーションできます。
システム モジュールとは対照的に、デプロイされた JMS アプリケーション モジュールの所有者は、モジュールをデプロイした管理者ではなく、モジュールを作成およびパッケージ化した開発者となります。したがって、デプロイしたリソースに対しては、管理者の制御が及ぶ範囲がより制限されます。アプリケーション モジュールをデプロイする場合、管理者はモジュールで指定されたリソース プロパティの変更はできますが、リソースの追加や削除はできません。他の J2EE モジュールのように、アプリケーション モジュールのデプロイメント コンフィグレーションの変更はモジュールのデプロイメント プランに格納され、元のモジュール自体は変更されません。
表 2-1 に、JMS モジュールのタイプとそれぞれのコンフィグレーションおよび変更方法を示します。
JMS アプリケーション モジュールのデプロイメントの準備については、「JMS アプリケーション モジュールのデプロイメントのコンフィグレーション」と『WebLogic Server 9.1 アプリケーションのデプロイメント』の「アプリケーションおよびモジュールのデプロイ」を参照してください。
JMS Interop モジュールは、特殊なタイプの JMS システム リソース モジュールです。このモジュールは、このリリースのための JMS コンフィグレーション アップグレードの結果として、および旧リリースから WebLogic JMX MBean API を使用することによって作成および管理されます。
JMS Interop モジュールは、以下に示すように、JMS システム リソース モジュールとはさまざまな点で異なります。
interop-jms.xml で、このファイルはドメインの config\jms ディレクトリに存在する。JMSInteropModuleMBean。これは DomainMBean の子 MBean で、ドメイン内の他の子 MBean と同じように DomainMBean からルックアップできます。JMS Interop モジュールには、メッセージの順序単位や送り先割り当てなどの、WebLogic Server 9.0 以降の機能の多くも実装できます。ただし、WebLogic Server 9.0 以降の機能のうち以下の機能は実装できません。
注意 : JMS interop モジュールで WebLogic Server 9.0 以降の機能を使用すると、WebLogic Server 9.0 より前のバージョンの JMX クライアントとの互換性が損なわれる場合があります。
WebLogic 永続ストアは、永続性を必要とするすべてのサブシステムとサービスに対し、組み込みの高性能なストレージの仕組みを提供します。たとえば、永続ストアは、永続 JMS メッセージを格納したり、ストア アンド フォワード機能を使用して、メッセージを一時的に格納してから送信したりできます。ドメインの各 WebLogic Server インスタンスには、コンフィグレーションが不要で、システムのデフォルト ストレージを使用する複数のサブシステムで同時に使用できるデフォルトの永続ストアがあります。なお、JMS 実装に合わせて専用のファイル ベース ストアまたは JDB データベース対応ストアを作成することもできます。詳細については、『WebLogic Server 環境のコンフィグレーション』の「WebLogic 永続ストアの使い方」を参照してください。
SAF サービスを使用すると、複数の WebLogic Server インスタンスに分散されているアプリケーション間でメッセージを確実に配信できます。たとえば、SAF サービスを利用すると、ローカルの WebLogic Server インスタンス上で動作するアプリケーション、またはローカルの WebLogic Server インスタンスに接続するアプリケーションは、リモート サーバ上の送り先にメッセージを確実に配信できます。ネットワークの問題やシステム障害が原因で、メッセージの送信時に送り先が使用不能になっている場合、メッセージはローカルのサーバ インスタンスに保存されて、リモートの送り先が使用可能になった時点で転送されます。
JMS モジュールは、SAF サービスを利用して、ローカルの JMS メッセージ プロデューサがリモートの JMS キューまたはトピックにメッセージを確実に送信できるようにします。詳細については、『WebLogic ストア アンド フォワードのコンフィグレーションと管理』の「ストア アンド フォワード サービスについて」を参照してください。
WebLogic Server パス サービスは、分散キュー メンバーまたはストア アンド フォワード パスにメッセージを固定することによってメッセージ グループとメッセージング リソースの間のマッピングを格納するための永続マップです。パス サービスの詳細については、「WebLogic パス サービスの使用」を参照してください。
メッセージング ブリッジを使用すると、2 つのメッセージング製品間の転送メカニズムをコンフィグレーションすることで、WebLogic JMS の異なる実装間、または WebLogic JMS と別のメッセージング製品間の相互運用性を実現できます。メッセージング ブリッジ インスタンス、およびブリッジのソースおよび対象送り先は、ドメインの config.xml ファイルに保持されます。詳細については、『WebLogic メッセージング ブリッジのコンフィグレーションと管理』の「メッセージング ブリッジについて」を参照してください。
WebLogic JMS は、JMS 1.1 仕様によって指定されている標準 JMS API を超えるさまざまな WebLogic JMS 拡張機能を提供します。また、WebLogic Server プラットフォームに緊密に統合されているため、高度なセキュリティで保護された J2EE アプリケーションを構築し、それらを WebLogic Server コンソールで容易にモニタおよび管理できます。XA トランザクションが完全にサポートされているだけでなく、クラスタ機能とサービス移行機能による高い可用性を特長としています。加えて、他のバージョンの WebLogic Server やサードパーティのメッセージ プロバイダとのシームレスな相互運用性も提供されます。
以下の節では、WebLogic JMS のユニークかつ強力な機能について概説します。
注意 : この節では、Weblogic Server 9.0 より前のリリースの付加価値機能のみを取り上げます。WebLogic Server 9.0 以降で導入された機能の一覧については、「このリリースでの JMS の新機能と変更点」を参照してください。
WebLogic JMS のアーキテクチャでは、クラスタ内のあらゆるサーバから JMS 送り先へのクラスタワイドで透過的なアクセスをサポートすることで、複数の JMS サーバのクラスタ化が実装されます。WebLogic Server は、クラスタ全体への JMS の送り先と接続ファクトリの配布をサポートするようになりました。ただし、JMS トピックおよびキューが、クラスタ内の WebLogic Server インスタンスによって管理される点は変わりません。
WebLogic JMS のクラスタ化のコンフィグレーションについては、「WebLogic JMS クラスタ化のコンフィグレーション」を参照してください。WebLogic Server のクラスタ化の詳細については、『WebLogic Server クラスタ ユーザーズ ガイド』を参照してください。
|
|
|