| Oracle® Fusion Middleware Oracle WebLogic Server JMSの構成と管理 11gリリース1 (10.3.6) B61636-04 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle WebLogic Server JMSの構成と管理 11gリリース1 (10.3.6) B61636-04 |
|
前 |
次 |
この章では、WebLogic JMSの基本的な概念と機能を簡単に紹介し、それらと他のアプリケーション・コンポーネントおよびWebLogic Serverとの連携の仕組みについて説明します。
この章は、JavaのプログラミングおよびJMS 1.1の概念と機能に精通している読者を対象としています。
JMSのWebLogic Server実装は、WebLogic Serverプラットフォームに緊密に統合されたエンタープライズ・クラスのメッセージング・システムです。JMS 1.1仕様(http://www.oracle.com/technetwork/java/jms/index.htmlで入手可能)を完全にサポートし、標準JMS APIより高度なWebLogic JMS拡張も多数用意されています。
エンタープライズ・メッセージング・システムを使用すると、アプリケーション同士がメッセージを交換することによって非同期的に通信できます。メッセージとは、異なるアプリケーション間の通信を調整するために必要な情報が含まれている、リクエスト、レポート、およびイベントです。メッセージで提供される抽象化の階層により、宛先システムについての詳細情報をアプリケーション・コードから切り離すことができます。
Java Message Service (JMS)は、業界メッセージング・プロバイダによって実装されるエンタープライズ・メッセージング・システムにアクセスするための標準APIです。具体的なJMSの特長は以下のとおりです。
メッセージング・システムを共有するJavaアプリケーション同士でメッセージを交換できます
メッセージを作成、送信、および受信するための標準インタフェースによりアプリケーションの開発が容易になります
WebLogic JMSは、プロデューサ・アプリケーションからメッセージを受信し、そのメッセージをコンシューマ・アプリケーションに配信します。WebLogic ServerでのJMS APIのプログラミングの詳細は、『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管理コンソール、WebLogic Scripting Tool (WLST)などの様々なコマンド・ライン・ツール、またはプログラムによる管理用のJMX APIを使用できます。
ドメイン環境に依存しないアプリケーション関連の定義の例としては、様々なJava EEアプリケーション・コンポーネント構成(EAR、WAR、JAR、RARの各ファイル、JMSおよびJDBCモジュールなど)があります。アプリケーション・コンポーネントは、アプリケーション開発チームによって開発およびパッケージ化され、さらにプログラム(コンパイル済みJavaコード)とその構成情報(記述子とも呼ばれ、そのほとんどはXMLファイルとして格納される)を持つ場合があります。ただし、JMSおよびJDBCモジュールの場合、コンパイル済みJavaコードは含まれません。あらかじめパッケージ化されたこれらのアプリケーションは、WebLogic Server管理者によってWebLogicドメインにデプロイされます。
アプリケーションをデプロイするプロセスによって、アプリケーション・コンポーネントと環境固有のリソース定義がリンクされます。たとえば、特定のアプリケーション・コンポーネントをホストするサーバー・インスタンス(ターゲット指定)や、JMSメッセージを保持するWebLogic永続ストアなどです。
最初のデプロイメントの完了後は、デプロイされたアプリケーションに対する管理者の権限は限定されます。たとえば、管理者はアプリケーションの適切なライフ・サイクルの保持(デプロイ、アンデプロイ、再デプロイ、削除など)とパラメータの調整(クライアントのニーズに合わせてアプリケーションのインスタンス数を増減するなど)しか行うことができません。ライフ・サイクルとチューニング以外の変更は、アプリケーション開発チームによって行われます。
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サーバーによって処理されない宛先に対するリクエストは、適切なサーバー・インスタンスに転送されます。
現在のリリースのJMSサーバーでは、JMSサーバーの動作が一部の点で9.xより前のリリースと異なります。
宛先リソースはJMSモジュールの中にカプセル化されるので、構成ファイルでJMSサーバーの下にネストされません。しかし、JMSサーバーと宛先の間の「下位ターゲット」関係も保持されています。これは、JMSモジュール内のスタンドアロンの各宛先リソースが常に単一のJMSサーバーのターゲットになるからです。このように、JMSサーバーは依然として永続メッセージ、恒久サブスクライバ、メッセージ・ページング、およびそのターゲット宛先の割当て(オプション)を管理します。ドメイン内の各JMSサーバーに、複数のJMSモジュールをターゲット指定できます。
JMSサーバーは、サーバー・インスタンス内の複数のサブシステムとサービスで使用できるデフォルト永続ストアをサポートします(「永続ストア」を参照)。
「デフォルト・ストアを使用する」オプションを有効化することで、JMSサーバーはホスト・サーバーのデフォルト・ファイル・ストア内に永続メッセージを格納できます。旧リリースでは、ストアが構成されていない場合、永続メッセージは非永続メッセージに自動的に格下げされました。ただし、「Use the Default Store」オプションを無効化した場合、永続メッセージは非永続になります。
非推奨のJMSストア(JMSファイル・ストアとJMS JDBCストア)にかわって、JMSサーバーはユーザー定義のWebLogicファイル・ストアまたはJDBCストアをサポートします。これらのストアは、従来のJMSストアに比べて高いパフォーマンスと多くの機能を備えています(下位互換性を保持するため、従来のJMSストアもサポートされています)。
JMSサーバーは、進化したメッセージ・ページング・メカニズムをサポートします。メッセージ・ページングの詳細は、『Oracle WebLogic Serverパフォーマンスおよびチューニング』を参照してください。
専用のページング・ストアの構成は不要になりました。ページングされるメッセージは、ユーザーのファイル・システム(ユーザー定義のディレクトリか、それが指定されていない場合はデフォルト・ページング・ディレクトリ)に格納されます。
メッセージの一時ページングは常に有効化され、「メッセージ・バッファ・サイズ」オプションの値によって制御されます。待ち状態ではない、ページングされないメッセージの合計サイズがこの値に達した場合、JMSサーバーはメッセージをページング・ディレクトリにページングすることによってメモリー使用量を減らそうとします。
1つのJMSサーバーによってホストされるすべての宛先でのメッセージの生成および消費処理を休止できます。これは、JMXでプログラムによって行うか、または管理コンソールから行います。詳細については、「宛先でのメッセージ処理の制御」を参照してください。
JMSサーバーは、WebLogic Serverを再起動せずにアンデプロイおよび再デプロイできます。
オフライン状態の共通分散トピック・メンバーにパブリッシュされた非永続メッセージは保存され、メンバーが再びオンラインになると使用可能になります。
9.0より前のリリースでは、JMSサーバーに永続ストアを構成していない場合や、永続ストアは定義されているが分散トピック(DT)メンバーにstoredEnabled=falseが設定されている場合、非永続メッセージは破棄され、DTメンバーが再びオンラインになっても使用可能になりません。アプリケーションがこれらのメッセージの破棄に依存している場合は、サーバーの配信タイムアウト値を非常に低い値に設定することで、同様の動作を実現できます。これにより、オフラインDTメンバーが再びオンラインになるまでにメッセージを無視できます。WebLogic Serverリリース10.3.4.0以上で開発された新しいアプリケーションの場合、メッセージ・コンシューマとしてメッセージ・ドリブンBean (MDB)を設定し、パーティション化された分散トピックを使用することで、同様の機能を実現できます。『Oracle WebLogic Server JMSのプログラミング』の高度なPub/Subアプリケーションの開発に関する項を参照してください。
JMSサーバーの構成の詳細は、「JMSサーバーの構成」を参照してください。
JMSモジュールは、ドメイン環境から独立したアプリケーション関連の定義です。システム・モジュールまたはアプリケーション・モジュールのいずれかとして、JMSリソースを作成して管理できます。JMSシステム・モジュールは、通常、管理コンソールまたはWebLogic Scripting Tool (WLST)を使用して構成され、ドメインのconfig.xmlファイル内にそのモジュールへの参照が追加されます。JMSアプリケーション・モジュールは、Java EEモジュールのWebLogic固有の拡張機能であり、Java EEアプリケーションと共に(パッケージ化されたリソースとして)、またはグローバルに使用可能なスタンドアロン・モジュールとしてデプロイできます。
システム・モジュールとアプリケーション・モジュールは、主に所有権に関して異なります。システム・モジュールはWebLogic管理者によって所有および変更され、すべてのアプリケーションで利用可能です。アプリケーション・モジュールは、このJMSリソース・モジュールをアプリケーションのEARファイルにパッケージ化するWebLogic開発者によって所有および変更されます。
JMSリソースのモジュール形式のデプロイメントでは、エンタープライズ・アプリケーション・ファイル(EARファイルなど)またはスタンドアロンJMSモジュールを開いたり、JMSを手動で広範囲に再構成したりすることなく、アプリケーションと必要なJMS構成を、ある環境から別の環境に(たとえば、テスト環境から本番環境に)移行できます。
以下の節では、様々なタイプのJMSモジュールとそこに含められるリソースについて説明します。
WebLogic管理者は、通常、管理コンソールまたは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アプリケーション・モジュールの構成については、第5章「JMSアプリケーション・モジュールのデプロイメントの構成」を参照してください。
WebLogic JMS構成および管理を理解する上で鍵となることは、JMSリソースの作成者およびJMSリソースの作成方法が、リソースのデプロイと変更の方法を決定するという点にあります。JMSモジュールは、WebLogicの管理者とプログラマが構成できます。
システム・モジュールとは対照的に、デプロイされたアプリケーション・モジュールの所有者は、モジュールをデプロイした管理者ではなく、モジュールを作成およびパッケージ化した開発者となります。これにより、デプロイされたリソースに対して管理者の制御が及ぶ範囲がより制限されます。アプリケーション・モジュールをデプロイする場合、管理者はモジュールで指定されたリソース・プロパティの変更はできますが、リソースの追加や削除はできません。他のJava EEモジュールのように、アプリケーション・モジュールのデプロイメント構成の変更はモジュールのデプロイメント・プランに格納され、元のモジュール自体は変更されません。
表2-1に、JMSモジュールの種類と、それらがどのように構成および変更されるかを示します。
表2-1 JMSモジュール・タイプと構成および管理オプション
| モジュールの種類 | 作成手段 | モジュールの動的追加/削除 | JMXで変更(リモート) | デプロイメント・チューニング・プランによる変更(非リモート) | 管理コンソールによる変更 | スコープ指定 | デフォルト・サブ・モジュール・ターゲット指定 |
|---|---|---|---|---|---|---|---|
|
システム |
管理コンソールまたはWLST |
はい |
はい |
いいえ |
はい - JMXから |
グローバルおよびローカル |
いいえ |
|
アプリケーション |
IDEまたはXMLエディタ |
いいえ - 再デプロイが必要 |
いいえ |
はい - デプロイメント・プランから |
はい - デプロイメント・プランから |
グローバル、ローカル、およびアプリケーション |
はい |
JMSアプリケーション・モジュールのデプロイメントの準備については、第5章「JMSアプリケーション・モジュールのデプロイメントの構成」と『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.2/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.x以降の機能の多くも実装できます。ただし、WebLogic Server 9.x以降の機能のうち次の機能は実装できません。
共通分散宛先リソース
JMSストア・アンド・フォワード・リソース
|
注意: JMS Interopモジュールで現在のリリースの新しい機能を使用すると、WebLogic Server 9.xより前のバージョンのJMXクライアントとの互換性が損なわれる場合があります。 |
以下の環境関連のリソースは、JMSサーバーおよびJMSモジュールにアクセス可能となるように、管理者によってドメイン構成リソースとして構成される必要があります。
WebLogic永続ストアは、永続性を必要とするすべてのサブシステムとサービスに対し、組込みの高性能なストレージの仕組みを提供します。たとえば、永続JMSメッセージを格納したり、ストア・アンド・フォワード機能を使用して、メッセージを一時的に格納してから送信したりできます。ドメインの各WebLogic Serverインスタンスには、構成が不要で、システムのデフォルト・ストレージを使用する複数のサブシステムで同時に使用できるデフォルトの永続ストアがあります。なお、JMS実装に合せて専用のファイル・ベース・ストアまたはJDBCデータベース対応ストアを作成することもできます。JMSの永続ストアの構成の詳細は、『Oracle WebLogic Serverサーバー環境の構成』の「WebLogic永続ストアの使い方」を参照してください。
SAFサービスを使用すると、複数のWebLogic Serverインスタンスに分散されているアプリケーション間でメッセージを確実に配信できます。たとえば、SAFサービスを利用すると、ローカルのWebLogic Serverインスタンス上で動作するアプリケーション、またはローカルのWebLogic Serverインスタンスに接続するアプリケーションは、リモート・サーバー上の宛先にメッセージを確実に配信できます。ネットワークの問題やシステム障害が原因で、メッセージの送信時に宛先が使用不能になっている場合、メッセージはローカルのサーバー・インスタンスに保存されて、リモートの宛先が使用可能になった時点で転送されます。
JMSモジュールは、SAFサービスを利用して、ローカルのJMSメッセージ・プロデューサがリモートのJMSキューまたはトピックにメッセージを確実に送信できるようにします。詳細は、『Oracle WebLogic Serverストア・アンド・フォワードの構成と管理』の「JMSメッセージに対するSAFの構成」を参照してください。
WebLogic Serverパス・サービスは、分散キュー・メンバーまたはストア・アンド・フォワード・パスにメッセージを固定することによってメッセージ・グループとメッセージング・リソースの間のマッピングを格納するための永続マップです。パス・サービスの構成の詳細は、「WebLogicパス・サービスの使用」を参照してください。
メッセージング・ブリッジを使用すると、2つのメッセージング製品間の転送メカニズムを構成することで、WebLogic JMSの異なる実装間、またはWebLogic JMSと別のメッセージング製品間の相互運用性を実現できます。メッセージング・ブリッジ・インスタンス、およびブリッジのソースおよびターゲット宛先インスタンスは、ドメインのconfig.xmlファイルに保持されます。詳細は、Oracle Fusion Middleware Oracle WebLogic Serverメッセージング・ブリッジの構成と管理のメッセージング・ブリッジの概要に関する項を参照してください。
