| Oracle® Fusion Middleware Oracle WebLogic Server JMS のコンフィグレーションと管理 11g リリース 1 (10.3.1) B55547-01 |
|
 戻る |
 次へ |
| Oracle® Fusion Middleware Oracle WebLogic Server JMS のコンフィグレーションと管理 11g リリース 1 (10.3.1) B55547-01 |
|
戻る |
次へ |
以下の節では、WebLogic JMS のさまざまな概念と機能を簡単に紹介し、それらと他のアプリケーション コンポーネントおよび WebLogic Server との連携の仕組みについて説明します。
この章は、Java のプログラミングおよび JMS 1.1 の概念と機能に精通している読者を対象としています。
JMS の WebLogic Server 実装は、WebLogic Server プラットフォームに緊密に統合されたエンタープライズ クラスのメッセージング システムです。JMS 1.1 仕様 (http://java.sun.com/products/jms/docs.html で入手可能) を完全にサポートし、標準 JMS API より高度な WebLogic JMS 拡張も多数用意されています。
エンタープライズ メッセージング システムを使用すると、アプリケーションどうしがメッセージを交換することによって通信できます。メッセージとは、異なるアプリケーション間の通信を調整するために必要な情報が含まれている、要求、レポート、およびイベントです。メッセージで提供される抽象化の階層により、送り先システムについての詳細情報をアプリケーション コードから切り離すことができます。
Java Message Service (JMS) は、業界メッセージング プロバイダによって実装されるエンタープライズ メッセージング システムにアクセスするための標準 API です。具体的な JMS の特長は以下のとおりです。
メッセージング システムを共有する Java アプリケーション同士でメッセージを交換できる
メッセージを作成、送信、および受信するための標準インタフェースによりアプリケーションの開発が容易になる
WebLogic JMS は、プロデューサ アプリケーションからメッセージを受信し、そのメッセージをコンシューマ アプリケーションに配信します。WebLogic Server での JMS API のプログラミングの詳細については、『Oracle Fusion Middleware Oracle WebLogic Server JMS プログラマーズ ガイド』を参照してください。
図 2-1 に WebLogic JMS のアーキテクチャを示します。
図 2-1 では、A1 および B1 が接続ファクトリ、B2 がキューです。
WebLogic JMS アーキテクチャの主要コンポーネントは以下のとおりです。
JMS サーバは、その JMS サーバの対象として指定された JMS モジュール内の JMS キューおよびトピック リソースの管理コンテナとして機能する、環境関連のコンフィグレーション エンティティ。JMS サーバの最も重要な役割は、JMS サーバの送り先が受信するすべての永続メッセージに使用される永続ストアに関する情報を管理し、また、JMS サーバの送り先で作成される恒久サブスクライバの状態を管理することです。ドメインごとに 1 つまたは複数の JMS サーバをコンフィグレーションでき、1 つの JMS サーバでは 1 つまたは複数の JMS モジュールを管理できます。詳細については、「JMS サーバの概要」を参照してください。
スタンドアロンのキューおよびトピック送り先、分散送り先、接続ファクトリなどのコンフィグレーション リソースを含み、weblogic-jms.xsd スキーマに準拠する XML ドキュメントによって定義される JMS モジュール。詳細については、「JMS コンフィグレーション リソースとは」を参照してください。
クライアント JMS アプリケーション。送り先へのメッセージを生成するか、または送り先からのメッセージを消費します。
JNDI (Java Naming and Directory Interface)。サーバ ルックアップ機能を提供します。
WebLogic 永続ストレージ (サーバ インスタンスのデフォルト ストア、ユーザ定義のファイル ストア、または JDBC でアクセス可能なユーザ定義ストア)。永続メッセージ データを保持します。
一般に、WebLogic Server ドメイン コンフィグレーション ファイル (config.xml) には、ドメインに必要なコンフィグレーション情報が記述されています。このコンフィグレーション情報をさらに分類すると、環境関連の情報とアプリケーション関連の情報に分けられます。環境関連の情報には、JMS サーバの ID と定義、JDBC データ ソース、WebLogic 永続ストア、サーバ ネットワーク アドレスなどがあります。通常、これらのシステム リソースは、ドメインごとにユニークです。
これらのシステム リソースのコンフィグレーションと管理を行うのは、WebLogic 管理者です。WebLogic 管理者は、組織のシステム管理者または MIS 部門からこの情報を受け取ります。これらのタスクを実行するために、管理者は WebLogic Administration Console、WebLogic Scripting Tool (WLST) などのさまざまなコマンドライン ツール、またはプログラムによる管理用の JMX API を使用できます。
ドメイン環境に依存しないアプリケーション関連の定義の例としては、さまざまな Java EE アプリケーション コンポーネント コンフィグレーション (EAR、WAR、JAR、RAR の各ファイル、JMS および JDBC モジュールなど) があります。アプリケーション コンポーネントは、アプリケーション開発チームによって開発およびパッケージ化され、さらにプログラム (コンパイル済み Java コード) とそのコンフィグレーション情報 (記述子とも呼ばれ、そのほとんどは XML ファイルとして格納される) を持つ場合があります。ただし、JMS および JDBC モジュールの場合、コンパイル済み Java コードは含まれません。あらかじめパッケージ化されたこれらのアプリケーションは、WebLogic Server 管理者によって WebLogic ドメインにデプロイされます。
アプリケーションをデプロイするプロセスによって、アプリケーション コンポーネントと環境固有のリソース定義がリンクされます。たとえば、特定のアプリケーション コンポーネントをホストするサーバ インスタンス (対象指定) や、JMS メッセージを保持する WebLogic 永続ストアなどです。
最初のデプロイメントの完了後は、デプロイされたアプリケーションに対する管理者の権限は限定されます。たとえば、管理者はアプリケーションの適切なライフ サイクルの保持 (デプロイ、アンデプロイ、再デプロイ、削除など) とパラメータの調整 (クライアントのニーズに合わせてアプリケーションのインスタンス数を増減するなど) しか行うことができません。ライフ サイクルとチューニング以外の変更は、アプリケーション開発チームによって行われます。
WebLogic Server 9.0 以降では、JMS コンフィグレーション リソース (送り先、接続ファクトリなど) は、WebLogic ドメインの外部にモジュール記述子ファイルとして格納されます。これらのファイルは、weblogic-jms.xsd スキーマに準拠する XML ドキュメントによって定義されます。JMS モジュールには JMS サーバの定義は含まれません。「JMS サーバの概要」で説明するように、JMS サーバの定義は WebLogic ドメインのコンフィグレーション ファイルに格納されます。
JMS リソースは、旧リリースの場合と同様の方法で管理するシステム モジュールか、またはアプリケーション モジュールとして作成し、管理します。JMS アプリケーション モジュールは、Java EE モジュールの WebLogic 固有の拡張機能であり、Java EE アプリケーションと共に (パッケージ化されたリソースとして)、またはグローバルに使用可能なスタンドアロン モジュールとしてデプロイできます。「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 サーバの下にネストされない。しかし、JMS サーバと送り先の間の「下位対象」関係も保持されています。これは、JMS モジュール内のスタンドアロンの各送り先リソースが常に単一の JMS サーバの対象になるからです。このように、JMS サーバは依然として永続メッセージ、恒久サブスクライバ、メッセージ ページング、およびその対象送り先の割り当て (オプション) を管理します。ドメイン内の各 JMS サーバに、複数の JMS モジュールを対象指定できます。
JMS サーバは、サーバ インスタンス内の複数のサブシステムとサービスで使用できるデフォルト永続ストアをサポートする (「永続ストア」を参照)。
[Use the Default Store] オプションを有効化することで、JMS サーバはホスト サーバのデフォルト ファイル ストア内に永続メッセージを格納できる。旧リリースでは、ストアがコンフィグレーションされていない場合、永続メッセージは非永続メッセージに自動的に格下げされました。ただし、[Use the Default Store] オプションを無効化した場合、永続メッセージは非永続になります。
非推奨の JMS ストア (JMS ファイル ストアと JMS JDBC ストア) に代わって、JMS サーバはユーザ定義の WebLogic ファイル ストアまたは JDBC ストアをサポートする。これらのストアは、従来の JMS ストアに比べて高いパフォーマンスと多くの機能を備えています (下位互換性を保持するため、従来の JMS ストアもサポートされています)。
JMS サーバは、進化したメッセージ ページング メカニズムをサポートする。メッセージ ページングの詳細については、『Oracle Fusion Middleware Oracle WebLogic Server パフォーマンス チューニング ガイド』を参照してください。
専用のページング ストアのコンフィグレーションは不要になった。ページングされるメッセージは、ユーザのファイル システム (ユーザ定義のディレクトリか、それが指定されていない場合はデフォルト ページング ディレクトリ) に格納されます。
メッセージの一時ページングは常に有効化され、[メッセージ バッファ サイズ] オプションの値によって制御される。待ち状態ではない、ページングされないメッセージの合計サイズがこの値に達した場合、JMS サーバはメッセージをページング ディレクトリにページングすることによってメモリ使用量を減らそうとします。
1 つの JMS サーバによってホストされるすべての送り先でのメッセージの生成および消費処理を休止できる。これは、JMX でプログラムによって行うか、または Administration Console から行います。詳細については、「送り先でのメッセージ処理の制御」を参照してください。
JMS サーバは、WebLogic Server を再起動せずにアンデプロイおよび再デプロイできる。
JMS サーバのコンフィグレーションの詳細については、「JMS サーバのコンフィグレーション」を参照してください。
JMS モジュールは、ドメイン環境から独立したアプリケーション関連の定義です。JMS リソースは、システム モジュールとして、またはアプリケーション モジュールとして作成および管理します。JMS システム モジュールは、通常、Administration Console または WebLogic Scripting Tool (WLST) を使用してコンフィグレーションされ、ドメインの config.xml ファイル内にそのモジュールへの参照が追加されます。JMS アプリケーション モジュールは、Java EE モジュールの WebLogic 固有の拡張機能であり、Java EE アプリケーションと共に (パッケージ化されたリソースとして)、またはグローバルに使用可能なスタンドアロン モジュールとしてデプロイできます。
システム モジュールとアプリケーション モジュールは、主に所有権に関して異なります。システム モジュールは WebLogic 管理者によって所有および変更され、すべてのアプリケーションで利用可能です。アプリケーション モジュールは、この JMS リソース モジュールをアプリケーションの EAR ファイルにパッケージ化する WebLogic 開発者によって所有および変更されます。
JMS リソースのモジュール形式のデプロイメントでは、エンタープライズ アプリケーション ファイル (EAR ファイルなど) またはスタンドアロン JMS モジュールを開いたり、JMS を手動で広範囲に再コンフィグレーションしたりすることなく、アプリケーションと必要な JMS コンフィグレーションを、ある環境から別の環境に (たとえば、テスト環境からプロダクション環境に) 移行できます。
以下の節では、さまざまなタイプの JMS モジュールとそこに含められるリソースについて説明します。
WebLogic 管理者は、通常、Administration Console または WebLogic Scripting Tool (WLST) を使用して、(対象) JMS モジュールの作成とデプロイ、およびモジュールのコンフィグレーション リソース (キュー、トピック、接続ファクトリなど) のコンフィグレーションを行います。
このようにコンフィグレーションする JMS モジュールは、システム モジュールと見なされます。JMS システム モジュールは管理者が所有し、管理者はいつでもリソースを削除、変更、または追加できます。システム モジュールは、ドメインにコンフィグレーションされたサーバおよびクラスタの対象指定に対して全面的に利用できます。つまり、同じ対象にデプロイされているすべてのアプリケーションおよびクライアント アプリケーションで利用できます。
JMS システム モジュールを作成する場合、ドメイン ディレクトリの config\jms サブディレクトリに JMS モジュール ファイルが作成され、ドメインの config.xml ファイルに JMSSystemResource 要素としてそのモジュールへの参照が追加されます。この参照には、JMS システム モジュール ファイルへのパス、およびこのモジュールがデプロイされるサーバとクラスタのリストが含まれます。
JMS モジュールは、weblogic-jms.xsd スキーマに準拠します (「JMS スキーマ」を参照)。システム モジュールは、JMX (WebLogic Management Extension) ユーティリティからも JMSSystemResourceMBean としてアクセス可能です。JMS システム モジュールの命名規約は、MyJMSModule-jms.xml です。
図 2-2 に、ドメインの config.xml ファイルに記述される JMS システム モジュールと、対応する config\jms ディレクトリ内のモジュールの例を示します。
JMS システム モジュールのコンフィグレーションの詳細については、「基本 JMS システム リソースのコンフィグレーション」を参照してください。
JMS コンフィグレーション リソースは、標準の Java EE 記述子ベースのモジュールと同様に、デプロイ可能なアプリケーション モジュールとしても管理できます。JMS アプリケーション モジュールは、Java EE アプリケーションと共にパッケージ化されたモジュールとして (この場合、モジュール内のリソースは同梱されたアプリケーションでのみ利用可能 (アプリケーション スコープなど))、またはそのモジュール内のリソースへのグローバル アクセスを提供するスタンドアロン モジュールとしてデプロイできます。
通常、アプリケーション開発者が、エンタープライズ レベルの IDE または XML 記述子ファイルの編集に対応した開発ツールでアプリケーション モジュールを作成し、それらの JMS モジュールをアプリケーションの一部としてパッケージ化して、デプロイ、管理、およびチューニングのためにアプリケーションを WebLogic 管理者に渡します。
「ドメイン コンフィグレーション : 環境関連リソースとアプリケーション関連リソース」で説明したように、JMS アプリケーション モジュールにはコンパイル済みの Java プログラムがパッケージの一部として含まれていないので、管理者またはアプリケーション開発者は必要に応じた形で JMS リソースを作成したり管理したりできます。
JMS アプリケーション モジュールのコンフィグレーションについては、「JMS アプリケーション モジュールのデプロイメントのコンフィグレーション」を参照してください。
WebLogic JMS のコンフィグレーションと管理を理解するための鍵は、JMS リソースの作成者と作成方法によってリソースをデプロイおよび変更する方法が決まるということです。JMS モジュールは、WebLogic の管理者とプログラマがコンフィグレーションできます。
システム モジュールとは対照的に、デプロイされた JMS アプリケーション モジュールの所有者は、モジュールをデプロイした管理者ではなく、モジュールを作成およびパッケージ化した開発者となります。したがって、デプロイしたリソースに対しては、管理者の制御が及ぶ範囲がより制限されます。アプリケーション モジュールをデプロイする場合、管理者はモジュールで指定されたリソース プロパティの変更はできますが、リソースの追加や削除はできません。他の Java EE モジュールのように、アプリケーション モジュールのデプロイメント コンフィグレーションの変更はモジュールのデプロイメント プランに格納され、元のモジュール自体は変更されません。
表 2-1 に、JMS モジュールの種類と、それらがどのようにコンフィグレーションおよび変更されるかを示します。
表 2-1 JMS モジュール タイプとコンフィグレーションおよび管理オプション
| モジュールの種類 | 作成手段 | モジュールの動的追加/削除 | JMX で変更 (リモート) | デプロイメント チューニング プランによる変更 (非リモート) | Admin Console による変更 | スコープ | デフォルト サブ モジュール対象指定 |
|---|---|---|---|---|---|---|---|
|
システム |
Admin Console または WLST |
可 |
可 |
不可 |
可 - JMX から |
グローバルおよびローカル |
不可 |
|
アプリケーション |
IDE または XML エディタ |
不可 - 再デプロイが必要 |
不可 |
可 - デプロイメント プランから |
可 - デプロイメント プランから |
グローバル、ローカル、およびアプリケーション |
可 |
JMS アプリケーション モジュールのデプロイメントの準備については、「JMS アプリケーション モジュールのデプロイメントのコンフィグレーション」と『Oracle Fusion Middleware Oracle WebLogic Server アプリケーションのデプロイメント』の「weblogic.deployer によるアプリケーションおよびモジュールのデプロイ」を参照してください。
システム モジュールまたはアプリケーション モジュールの一部として、以下の基本コンフィグレーション リソースが定義されます。
キューおよびトピック送り先 (「キューおよびトピック送り先のコンフィグレーション」を参照)。
接続ファクトリ (「接続ファクトリのコンフィグレーション」を参照)。
テンプレート (「JMS テンプレートのコンフィグレーション」を参照)。
送り先キー (「送り先キーのコンフィグレーション」を参照)。
割り当て (「割り当てのコンフィグレーション」を参照)。
分散送り先 (「分散送り先リソースのコンフィグレーション」を参照)。
外部サーバ (「外部サーバ リソースからサード パーティ JMS プロバイダへのアクセスのコンフィグレーション」を参照)。
JMS ストア アンド フォワード (SAF) コンフィグレーション項目 (「JMS ストア アンド フォワード (SAF)」を参照)。
これ以外のすべての JMS 環境関連リソースは、ドメイン コンフィグレーション リソースとして管理者がコンフィグレーションする必要があります。これには、以下のものが含まれます。
JMS サーバ (必須)。「JMS サーバの概要」を参照してください。
ストア アンド フォワード エージェント (省略可能)。「JMS ストア アンド フォワード (SAF)」を参照してください。
パス サービス (省略可能)。「パス サービス」を参照してください。
メッセージング ブリッジ (省略可能)。「メッセージング ブリッジ」を参照してください。
永続ストア (省略可能)。「永続ストア」を参照してください。
JMS システム モジュールのコンフィグレーションの詳細については、「基本 JMS システム リソースのコンフィグレーション」を参照してください。
JMS リソースのモジュラー コンフィグレーション モデルのサポートとして、WebLogic JMS オブジェクトのスキーマ、weblogic-jms.xsd が用意されています。JMS リソース モジュール (記述子) を作成する際は、モジュールをこのスキーマに準拠させる必要があります。IDE や他のツールでは、このスキーマに基づいて JMS リソース モジュールを検証できます。
weblogic-jms.xsd スキーマは、http://xmlns.oracle.com/weblogic/weblogic-jms/1.0/weblogic-jms.xsd からオンラインで入手できます。
JMS Interop モジュールは、特殊なタイプの JMS システム リソース モジュールです。このモジュールは、このリリースのための JMS コンフィグレーション アップグレードの結果として、および旧リリースから WebLogic JMX MBean API を使用することによって作成および管理されます。
JMS Interop モジュールは、以下に示すように、JMS システム リソース モジュールとはさまざまな点で異なります。
JMS モジュール記述子の名前は常に interop-jms.xml で、このファイルはドメインの config\jms ディレクトリに存在する。
他の JMS システム リソース モジュールの所有者が主に管理者であるのに対し、Interop モジュールはシステムによって所有される。
Interop モジュールは、ドメインのどこでも対象指定される。
JMS Interop モジュールに存在する JMS リソースは、非推奨の JMX (MBean) API を使用してアクセスおよび管理できる。
JMS Interop モジュールの MBean は、JMSInteropModuleMBean。これは DomainMBean の子 MBean で、ドメイン内の他の子 MBean と同じように DomainMBean からルックアップできます。
JMS Interop モジュールには、メッセージの順序単位や送り先割り当てなどの、WebLogic Server 9.0 以降の機能の多くも実装できます。ただし、WebLogic Server 9.0 以降の機能のうち以下の機能は実装できません。
共通分散送り先リソース
JMS ストア アンド フォワード リソース
|
注意 : JMS Interop モジュールで現在のリリースの新しい機能を使用すると、WebLogic Server 9.0 より前のバージョンの JMX クライアントとの互換性が損なわれる場合があります。 |
以下の環境関連のリソースは、JMS サーバおよび JMS モジュールにアクセス可能となるように、管理者によってドメイン コンフィグレーション リソースとしてコンフィグレーションされる必要があります。
WebLogic 永続ストアは、永続性を必要とするすべてのサブシステムとサービスに対し、組み込みの高性能なストレージの仕組みを提供します。たとえば、永続 JMS メッセージを格納したり、ストア アンド フォワード機能を使用して、メッセージを一時的に格納してから送信したりできます。ドメインの各 WebLogic Server インスタンスには、コンフィグレーションが不要で、システムのデフォルト ストレージを使用する複数のサブシステムで同時に使用できるデフォルトの永続ストアがあります。なお、JMS 実装に合わせて専用のファイル ベース ストアまたは JDBC データベース対応ストアを作成することもできます。JMS の永続ストアのコンフィグレーションの詳細については、『Oracle Fusion Middleware Oracle WebLogic Server サーバ環境のコンフィグレーション』の「WebLogic 永続ストアの使い方」を参照してください。
SAF サービスを使用すると、複数の WebLogic Server インスタンスに分散されているアプリケーション間でメッセージを確実に配信できます。たとえば、SAF サービスを利用すると、ローカルの WebLogic Server インスタンス上で動作するアプリケーション、またはローカルの WebLogic Server インスタンスに接続するアプリケーションは、リモート サーバ上の送り先にメッセージを確実に配信できます。ネットワークの問題やシステム障害が原因で、メッセージの送信時に送り先が使用不能になっている場合、メッセージはローカルのサーバ インスタンスに保存されて、リモートの送り先が使用可能になった時点で転送されます。
JMS モジュールは、SAF サービスを利用して、ローカルの JMS メッセージ プロデューサがリモートの JMS キューまたはトピックにメッセージを確実に送信できるようにします。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server ストア アンド フォワードのコンフィグレーションと管理』の「JMS メッセージに対する SAF のコンフィグレーション」を参照してください。
WebLogic Server パス サービスは、分散キュー メンバーまたはストア アンド フォワード パスにメッセージを固定することによってメッセージ グループとメッセージング リソースの間のマッピングを格納するための永続マップです。パス サービスのコンフィグレーションの詳細については、「WebLogic パス サービスの使用」を参照してください。
メッセージング ブリッジを使用すると、2 つのメッセージング製品間の転送メカニズムをコンフィグレーションすることで、WebLogic JMS の異なる実装間、または WebLogic JMS と別のメッセージング製品間の相互運用性を実現できます。メッセージング ブリッジ インスタンス、およびブリッジのソースおよび対象送り先インスタンスは、ドメインの config.xml ファイルに保持されます。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server メッセージング ブリッジのコンフィグレーションと管理』の「メッセージング ブリッジについて」を参照してください。
