WebLogic JMS のコンフィグレーションと管理
|
 |
 |
|
以下の節では、WebLogic Server の実装のグローバル JMS システム リソースをコンフィグレーションする方法について説明します。
メッセージング リソースは、以下のように、いくつかの方法でコンフィグレーションできます。
WebLogic 管理者は通常、Administration Console、WebLogic Java Management Extensions (JMX) API、または WebLogic Scripting Tool (WLST) を使用して、メッセージング リソースの作成およびデプロイ (対象指定) を行います。
開発者は、エンタープライズ レベルの IDE または XML ファイルの編集に対応した開発ツールでアプリケーション モジュールを作成し、それらをアプリケーションの一部としてパッケージ化して、そのアプリケーションをデプロイするために WebLogic 管理者に渡します。
WebLogic Server Administration Console は、JMS を含む WebLogic Server の機能を簡単にコンフィグレーションおよび管理するためのインタフェースを備えています。Administration Console の起動手順については、『サーバの起動と停止の管理』の「サーバの起動と停止」を参照してください。
Administration Console では、コンフィグレーション属性を定義して以下のことを行います。
WebLogic JMS では、一部のコンフィグレーション オプションに対するデフォルト値が用意されていますが、それ以外のすべての属性に対しては値を指定する必要があります。この節で説明する手順に従って、JMS リソースをコンフィグレーションおよび管理します。WebLogic JMS をコンフィグレーションしたら、アプリケーションで JMS API を使用してメッセージの送受信ができるようになります。基本的な WebLogic JMS アプリケーションの開発の詳細については、『WebLogic JMS プログラマーズ ガイド』の「基本的な JMS アプリケーションの開発」を参照してください。
examplesServer には、サンプル コンフィグレーションとして examplesJMSServer が用意されています。examplesServer の起動と停止の詳細については、『サーバの起動と停止の管理』の「サーバの起動と停止」を参照してください。
以下の節では、WebLogic Server および Administration Console の起動方法を概説し、基本的な WebLogic JMS 実装をコンフィグレーションする手順について説明します。
WebLogic Server のデフォルトのロールは管理サーバです。ドメインが 1 つの WebLogic Server のみで構成されている場合は、そのサーバが管理サーバになります。ドメインが複数の WebLogic Server インスタンスで構成されている場合は、まず管理サーバを起動してから、管理対象サーバを起動します。
管理サーバの起動の詳細については、『サーバの起動と停止の管理』の「サーバの起動と停止」を参照してください。
Administration Console は、WebLogic Server に対する Web ベースの管理者フロントエンド (管理者クライアント インタフェース) です。サーバの Administration Console にアクセスする前に、サーバを起動する必要があります。Administration Console による WebLogic Server ドメインの管理の方法については、Administration Console のオンライン ヘルプの「WebLogic Server Administration Console」を参照してください。
この節では、Administration Console を使用して、永続ストア、JMS サーバ、および基本的な JMS システム モジュールをコンフィグレーションする方法について説明します。
この節では、作成した JMS リソースを調整するためのコンフィグレーション パラメータについては説明しません。これらのパラメータの詳細については、『WebLogic Server MBean リファレンス』の「System Module MBeans」フォルダ内の対応するシステム モジュール Bean を参照してください。JMS モジュールのルート Bean は JMSBean で、JMS モジュール全体を表現します。
詳細については、『WebLogic Server 環境のコンフィグレーション』の「カスタム (ユーザ定義) ファイル ストアの作成」を参照してください。
JDBC ストアの詳細については、『WebLogic Server 環境のコンフィグレーション』の「JDBC ストアの作成」を参照してください。
詳細については、「JMS サーバ」を参照してください。
詳細については、「JMS システム モジュール」を参照してください。
JMS トピックのコンフィグレーションの詳細については、「トピックの作成」を参照してください。
JMS キューのコンフィグレーションの詳細については、「キューの作成」を参照してください。
デフォルト接続ファクトリの使い方の詳細については、「デフォルト接続ファクトリの使用」を参照してください。接続ファクトリのコンフィグレーションの詳細については、「接続ファクトリの作成」を参照してください。
この節では、Administration Console を使用して JMS システム モジュールに追加できる拡張リソースについて説明します。
ドメイン内の各サーバ インスタンスの名前は、同じドメイン内のすべてのコンフィグレーション オブジェクトに対してユニークでなければなりません。ドメインの内部では、サーバ、マシン、クラスタ、仮想ホスト、およびその他のリソース タイプのそれぞれにユニークな名前を付ける必要があります。また、ドメインと同じ名前を使用することはできません。この命名規則は、JMS サーバ、JMS システム モジュール、JMS アプリケーション モジュールなど、コンフィグレーション可能なすべての JMS オブジェクトに適用されます。
JMS モジュール内のリソースの名前は、リソース タイプ (キュー、トピック、接続ファクトリなど) ごとにユニークでなければなりません。ただし、2 つの異なる JMS モジュールに、同じ名前、同じタイプのリソースを作成できます。
また、バインディング可能な JMS リソース (割り当て、送り先キー、および JMS テンプレート) の JNDI 名は、すべての JMS モジュールにわたってユニークでなければなりません。
JMS サーバは、それらの対象として指定された JMS モジュール内の JMS キューおよびトピック リソースの管理コンテナとして機能する、環境関連のコンフィグレーション エンティティです。JMS サーバの最も重要な役割は、JMS サーバの送り先が受信するすべての永続メッセージに使用される永続ストアに関する情報を管理し、また、JMS サーバの送り先で作成される恒久サブスクライバの状態を管理することです。また、対象送り先のコンテナとして、JMS サーバに対して加えられたコンフィグレーションの変更または実行時の変更をすべての送り先に対して有効にできます。
JMSServerMBean および JMSServerRuntimeMBean MBean にアクセスして JMS サーバを作成および管理できる。詳細については、『JMX によるカスタム管理ユーティリティの開発』の「WebLogic Server サブシステム MBean の概要」を参照してください。JMSModuleHelper Javadoc を参照してください。送り先の管理コンテナとして、JMS サーバには以下のコンフィグレーション パラメータが用意されています。
JMS サーバと送り先のメッセージおよびバイト割り当てのコンフィグレーションについては、「割り当ての定義」を参照してください。
JMS サーバのメッセージ ライフ サイクル ロギングをコンフィグレーションする方法については「メッセージ ライフ サイクルのロギング」を参照してください。
送り先でのメッセージ処理の休止については、「送り先でのメッセージ処理の制御」を参照してください。
一部の JMS サーバ オプションは、動的にコンフィグレーションできます。オプションを実行時に変更した場合、新しく配信されるメッセージにのみ適用され、すでに保存されているメッセージには影響しません。すべての JMS サーバ オプションのデフォルト値については、『WebLogic Server MBean リファレンス』の「JMSServerMBean」を参照してください。
JMS サーバは、デプロイ先となる独立した WebLogic Server インスタンスまたは移行可能な対象サーバの対象として指定できます。
JMS の移行可能な対象のコンフィグレーションについては、「JMS サーバの移行可能な対象のコンフィグレーション」を参照してください。
アクティブな JMS サーバ、送り先、およびサーバ セッション プールの実行時統計をモニタできます。
JMS オブジェクトのモニタの詳細については、「JMS 統計のモニタとメッセージの管理」を参照してください。
注意 : セッション プールおよび接続コンシューマのコンフィグレーション オブジェクトは、WebLogic Server 9.0 では非推奨となっています。これらは、J2EE 仕様の必須コンポーネントではなく、JTA ユーザ トランザクションもサポートされていないためです。代わりに、J2EE の必須コンポーネントであるメッセージ駆動型 Bean (MDB) が主に使用されています。MDB の設計の詳細については、『WebLogic エンタープライズ JavaBeans (EJB) プログラマーズ ガイド』の「メッセージ駆動型 EJB」を参照してください。
サーバ セッション プールを使用すると、アプリケーションでメッセージを並行処理できます。JMS サーバを定義したら、JMS サーバごとに 1 つまたは複数のセッション プールをコンフィグレーションできます。一部のセッション プール オプションは動的にコンフィグレーションできますが、新しい値は JMS サーバを再起動するまで有効になりません。セッション プールの作成の詳細については、『WebLogic JMS プログラマーズ ガイド』の「サーバ セッション プールの定義」を参照してください。
接続コンシューマは、サーバ セッションを取得してメッセージを処理するキュー (ポイント ツー ポイント) またはトピック (Pub/Sub) です。セッション プールを定義したら、セッション プールごとに 1 つまたは複数の接続コンシューマをコンフィグレーションします。接続コンシューマの作成の詳細については、『WebLogic JMS プログラマーズ ガイド』の「サーバ セッション プールの定義」を参照してください。
JMS システム モジュールは管理者が所有し、いつでも JMS システム リソースを削除、変更、または追加できます。単一の JMS サーバの対象となるスタンドアロンのキューおよびトピック リソースを除き、システム モジュール内の接続ファクトリ、分散送り先、外部サーバ、および JMS SAF 送り先リソースは、WebLogic ドメインにコンフィグレーションされた複数のサーバ インスタンスとクラスタの対象として指定することによってグローバルに使用できるようになります。このため、これらのリソースは、同じ対象にデプロイされるすべてのアプリケーションとクライアント アプリケーションで使用できます。JMS システム モジュールの命名規約は、MyJMSModule-jms.xml です。
JMS システム モジュールの一部として、以下の基本コンフィグレーション リソースが定義されます。
また、JMS システム モジュールの一部として、以下の拡張クラスタ化コンフィグレーション リソースが定義されます。
JMS システム モジュールとそのリソースは、以下のいずれかの方法で作成できます。
JMSSystemResourceMBean および JMSRuntimeMBean MBean にアクセスして JMS の送り先と接続を作成および管理できる。詳細については、『JMX によるカスタム管理ユーティリティの開発』の「WebLogic Server サブシステム MBean の概要」を参照してください。JMSModuleHelper の Javadoc を参照してください。JMS システム モジュールは、1 つまたは複数の WebLogic Server インスタンスまたは 1 つのクラスタの対象でなければなりません。また、システム モジュールに定義されている対象指定できるリソースは、親モジュールの対象の範囲内の JMS サーバまたは WebLogic Server インスタンスの対象でなければなりません。さらに、システム モジュール内の対象指定できる JMS リソースをコンフィグレーションまたは対象指定プロセス中にサブデプロイメントとしてグループ化して、WebLogic ドメイン内の JMS リソースの結合度を減らすことができます。
Administration Console で JMS システム モジュール内にリソースをコンフィグレーションする際には、リソースのタイプに応じてあらかじめ選定されている有効な対象を単純に受け入れることも、高度な対象指定のページに進んで、既存のサブデプロイメントから選択したり新しい対象を作成したりすることもできます。
あらかじめ選定されている対象を選択する場合、リソースおよび選択した対象用にシステム制御のサブデプロイメントが自動的に生成されます。システムが作成または制御するサブデプロイメントのネーム スペースは次のように定義されます。
BEA_JMS_SUBDEPLOYMENT_XXXX
BEA_JMS_SUBDEPLOYMENT_MyJMSServer-0 のようになります。BEA_JMS_SUBDEPLOYMENT_MyModule-0 のようになります。JMS 管理者が BEA_JMS_SUBDEPLOYMENT で始まるサブデプロイメントを作成することはできません。この命名上の制限は、サブデプロイメントの作成プロセス中に検証されます。
JMS システム リソースのコンフィグレーションの詳細については、Administration Console オンライン ヘルプの「JMS システム モジュールのリソースのコンフィグレーション」を参照してください。
サブデプロイメントとは、対象指定できる JMS システム モジュール リソース (キュー、トピック、接続ファクトリなど) をグループ化して、システム モジュールの対象範囲内の特定のサーバ リソースに割り当てるメカニズムです。JMS システム モジュールはドメイン内の複数の WebLogic Server インスタンスの対象として指定できますが、モジュールのスタンドアロンのキューまたはトピックは単一の JMS サーバのみの対象となることができます。一方、接続ファクトリ、共通分散送り先 (UDD)、および外部サーバは、1 つまたは複数の JMS サーバ、1 つまたは複数の WebLogic Server インスタンス、または 1 つのクラスタの対象として指定できます。
したがってスタンドアロンのキューまたはトピックは、サブデプロイメントの他のメンバーが複数の JMS サーバに対象指定されている場合、そのサブデプロイメントに関連付けられません。このような例としては、接続ファクトリがドメイン内の JMS サーバをホストするクラスタに対して対象指定されている場合などが挙げられます。UDD を使用すると、こうしたサブデプロイメントとも関連付けることができます。これは、UDD がドメイン内の複数の JMS サーバに対してメンバーを分散させることを目的としているためです。
表 3-1 に JMS システム リソースのサブデプロイメントの有効な対象指定オプションを示します。
スタンドアロンのキューまたはトピックの単純なサブデプロイメントの例として、それらを接続ファクトリと共にグループ化して特定の JMS サーバに配置することが考えられます。これにより、ネットワーク トラフィックが減少します。また、対象の JMS サーバを別の WebLogic Server インスタンスに移行する必要がある場合、接続ファクトリとそのすべての接続も JMS サーバの送り先と一緒に移行されます。
たとえば、jmssysmod-jms.xml というシステム モジュールが、jmsserver1 と jmsserver2 というコンフィグレーション済みの 2 つの JMS サーバを持つ WebLogic Server インスタンスの対象として指定されており、2 つのキューと 1 つの接続ファクトリを jmsserver1 だけに配置する場合、これらのキューと接続ファクトリを同じサブデプロイメント、jmsserver1group としてグループ化すれば、これらのリソースは常に jmsserver1 にリンクされます (接続ファクトリが複数の JMS サーバに関連付けられていない場合)。
<weblogic-jms xmlns="http://www.bea.com/ns/weblogic/91">
<connection-factory name="connfactory1">
<sub-deployment-name>jmsserver1group</sub-deployment-name>
<jndi-name>cf1</jndi-name>
</connection-factory>
<queue name="queue1">
<sub-deployment-name>jmsserver1group</sub-deployment-name>
<jndi-name>q1</jndi-name>
</queue>
<queue name="queue2">
<sub-deployment-name>jmsserver1group</sub-deployment-name>
<jndi-name>q2</jndi-name>
</queue>
</weblogic-jms>
次に、ドメインのコンフィグレーション ファイルでの jmsserver1group サブデプロイメントの対象指定を示します。
<jms-system-resource>
<name>jmssysmod-jms</name>
<target>wlsserver1</target>
<sub-deployment>
<name>jmsserver1group</name>
<target>jmsserver1</target>
</sub-deployment>
<descriptor-file-name>jms/jmssysmod-jms.xml</descriptor-file-name>
</jms-system-resource>
JMS システム モジュールのサブデプロイメントを簡単に管理するため、Adminstration Console にサブデプロイメントの管理用ページが用意されています。詳細については、Administration Console オンライン ヘルプの「JMS システム モジュールのサブデプロイメントのコンフィグレーション」を参照してください。
スタンドアロン JMS モジュールのデプロイについては、「JDBC、JMS、および WLDF アプリケーション モジュールのデプロイ」を参照してください。
接続ファクトリは、JMS クライアントが JMS 接続を作成できるようにするオブジェクトです。接続ファクトリでは同時使用がサポートされており、複数のスレッドがオブジェクトに同時にアクセスできます。WebLogic JMS には、サーバ単位で有効/無効を切り替えられるコンフィグレーション済みの「デフォルト接続ファクトリ」が用意されています (「デフォルト接続ファクトリの使用」を参照)。
デフォルトの接続ファクトリを使用しない場合、1 つまたは複数の接続ファクトリをコンフィグレーションして、使用するアプリケーションに合わせて定義したオプションで接続を作成します。各 JMS モジュール内では、接続ファクトリ リソースの名前はユニークでなければなりません。しかし、各 JMS モジュール内のすべての接続ファクトリの JNDI 名は、WebLogic ドメイン全体でユニークでなければなりません (「JMS コンフィグレーションのネーミング要件」を参照)。WebLogic Server では、起動時に接続ファクトリが JNDI スペースに追加され、アプリケーションが WebLogic JNDI API を使用して接続ファクトリを取得します。
クラスタ内のあらゆるサーバから JMS 送り先へのクラスタワイドで透過的なアクセスを確立するには、サーバ インスタンスごとにデフォルト接続ファクトリを使用するか、クラスタ内の 1 つまたは複数のサーバ インスタンスを対象とする 1 つまたは複数の接続ファクトリをコンフィグレーションします。これにより、各接続ファクトリを複数の WebLogic Server にデプロイできます。JMS のクラスタ化のコンフィグレーションについては、「WebLogic JMS クラスタ化のコンフィグレーション」を参照してください。
WebLogic JMS は、次の JNDI 名を使用してルックアップできる、2 つのデフォルト接続ファクトリを定義します。
新しい接続ファクトリのコンフィグレーションは、デフォルト接続ファクトリのコンフィグレーション済み設定がアプリケーションに適さない場合にのみ行います。デフォルト接続ファクトリの使い方の詳細については、『WebLogic JMS プログラマーズ ガイド』の「WebLogic JMS について」を参照してください。
デフォルト接続ファクトリのコンフィグレーション済み設定とユーザ定義の接続ファクトリの主な違いは、JTA トランザクションを有効にするための [XA 接続ファクトリを有効化] オプションのデフォルト値です。[XA 接続ファクトリを有効化] オプションの詳細、およびその他の接続ファクトリ オプションのデフォルト値については、『WebLogic Server MBean リファレンス』の「JMSConnectionFactoryBean」を参照してください。
デフォルトの接続ファクトリを使用する場合のもう 1 つの違いは、接続ファクトリがデプロイされる可能性のある WebLogic Server インスタンスを限定できない点です。ただし、WebLogic Server 単位でデフォルト接続ファクトリを有効化および無効化できます。詳細については、Administration Console オンライン ヘルプの「サーバ : サービス : コンフィグレーション」を参照してください。
WebLogic Server Administration Console を使用すると、システム モジュール内の接続ファクトリ リソースをコンフィグレーション、変更、対象指定、および削除できます。JMS 接続のコンフィグレーションの手順については、Administration Console オンライン ヘルプの「接続ファクトリのコンフィグレーション」を参照してください。
接続ファクトリには、以下のコンフィグレーション パラメータが用意されています。
接続ファクトリ オプションの中には、動的にコンフィグレーションできるものもあります。オプションを実行時に変更した場合、新しく配信されるメッセージにのみ適用され、すでに保存されているメッセージには影響しません。すべての接続ファクトリ オプションのデフォルト値については、『WebLogic Server MBean リファレンス』の「JMSConnectionFactoryBean」を参照してください。
接続ファクトリは、1 つまたは複数の JMS サーバ、1 つまたは複数の WebLogic Server インスタンス、または 1 つのクラスタの対象として指定できます。
JMS システム モジュールのサブデプロイメントの対象指定については、「JMS モジュールとサブデプロイメント リソースの対象指定」を参照してください。
JMS 送り先は、JMS モジュール内のキュー (ポイント ツー ポイント) またはトピック (パブリッシュ/サブスクライブ) リソースを識別するものです。各キューおよびトピック リソースは、特定の JMS サーバの対象として指定されます。JMS サーバの最も重要な役割は、JMS サーバの送り先が受信するすべての永続メッセージに使用される永続ストアに関する情報を管理し、また、JMS サーバの送り先で作成される恒久サブスクライバの状態を管理することです。
必要な場合、JMS テンプレート、割り当て設定、送り先ソート キーなど、キューまたはトピック内から参照できる他の JMS リソースをモジュール内に作成できます。
回復またはロールバックされるメッセージを管理するために、再配信の制限に達したメッセージのエラー送り先をコンフィグレーションすることもできます。エラー送り先はキューまたはトピックのいずれかですが、関連付けられている送り先と同じ JMS サーバの対象でなければなりません。詳細については、『WebLogic JMS プログラマーズ ガイド』の「配信されなかったメッセージに対するエラー送り先のコンフィグレーション」を参照してください。
注意 : エラー送り先は関連付けられている送り先と同じ JMS サーバの対象でなければならないため、分散送り先と一緒に使用することはできません。分散送り先のメンバーは、複数の JMS サーバの対象として指定されるからです。
分散送り先リソースは、単一の論理的な送り先としてクライアントからアクセス可能な 1 単位の送り先 (キューまたはトピック) です (たとえば分散トピックは独自の JNDI 名を持ちます)。この単位のメンバーは通常、クラスタ内の複数のサーバに分散されており、各メンバーは個々の JMS サーバに属しています。分散送り先を使用するアプリケーションは、単純な送り先を使用するアプリケーションより可用性が高くなります。WebLogic JMS は、クラスタ内の分散送り先のメンバーのためのロード バランシングとフェイルオーバの機能を備えているからです。
WebLogic Server では、以下の 2 種類の分散送り先がサポートされます。
共通分散送り先 - 共通分散送り先 (UDD) では、各メンバーには、すべての分散送り先パラメータ (重み、セキュリティ、永続性、ページング、割り当てなどに関するパラメータ) の一貫したコンフィグレーションが設定されます。
重み設定された分散送り先 - 重み設定された分散送り先では、各メンバーには、すべての分散送り先パラメータ (重み、セキュリティ、永続性、ページング、割り当てなどに関するパラメータ) の一貫したコンフィグレーションが設定されません。
分散送り先リソースのコンフィグレーションの詳細については、「分散送り先のコンフィグレーション」を参照してください。
JMS キューでは、JMS サーバのポイント ツー ポイントの送り先タイプが定義されます。キューは、非同期のピア通信に使用されます。キューに配信されたメッセージは、1 つのコンシューマに配信されます。
WebLogic Server Administration Console を使用すると、システム モジュール内のキュー リソースをコンフィグレーション、変更、対象指定、および削除できます。キューに関するタスクの詳細については、Administration Console オンライン ヘルプの「キューのコンフィグレーション」を参照してください。各 JMS モジュール内では、キュー リソースの名前はユニークでなければなりません。しかし、各 JMS モジュールのすべてのキューの JNDI 名は、WebLogic ドメイン全体でユニークでなければなりません (「JMS コンフィグレーションのネーミング要件」を参照)。
キューには、以下のコンフィグレーション パラメータが用意されています。
注意 : キューの JNDI 名は動的に変更できますが、MDB のように長期間存続するプロデューサまたはコンシューマは、変更後も元の JNDI 名からメッセージを生成したり、元の JNDI 名にメッセージを送信したりしようと試みます。
キューのメッセージおよびバイト割り当てリソースのコンフィグレーションについては、「割り当てリソース」を参照してください。
キューのメッセージ ライフ サイクル ロギングをコンフィグレーションする方法については、「メッセージ ライフ サイクルのロギング」を参照してください。
キューでのメッセージ処理の休止については、「送り先でのメッセージ処理の制御」を参照してください。
キューのオプションには、動的にコンフィグレーションできるものがあります。オプションが実行時に変更された場合、変更は新しく配信されるメッセージにのみ適用され、格納されているメッセージには影響しません。すべてのキュー オプションのデフォルト値については、『WebLogic Server MBean リファレンス』の「QueueBean」を参照してください。
JMS トピックでは、JMS サーバのパブリッシュ/サブスクライブの送り先タイプが定義されます。トピックは、非同期のピア通信に使用されます。トピックに配信されたメッセージは、すべてのトピック コンシューマに配信されます。
WebLogic Server Administration Console を使用すると、システム モジュール内のトピック リソースをコンフィグレーション、変更、対象指定、および削除できます。トピックに関するタスクの詳細については、Administration Console オンライン ヘルプの「トピックのコンフィグレーション」を参照してください。各 JMS モジュール内では、トピック リソースの名前はユニークでなければなりません。しかし、各 JMS モジュールのすべてのトピックの JNDI 名は、WebLogic ドメイン全体でユニークでなければなりません (「JMS コンフィグレーションのネーミング要件」を参照)。
トピックには、以下のコンフィグレーション パラメータが用意されています。
注意 : トピックの JNDI 名は動的に変更できますが、MDB のように長期間存続するプロデューサまたはコンシューマは、変更後も元の JNDI 名からメッセージを生成したり、元の JNDI 名にメッセージを送信したりしようと試みます。
トピックのメッセージおよびバイト割り当てリソースのコンフィグレーションについては、「割り当てリソース」を参照してください。
トピックのメッセージ ライフ サイクル ロギングをコンフィグレーションする方法については、「メッセージ ライフ サイクルのロギング」を参照してください。
トピックでのメッセージ処理の休止については、「送り先でのメッセージ処理の制御」を参照してください。
トピック オプションの中には、動的にコンフィグレーションできるものもあります。オプションが実行時に変更された場合、変更は新しく配信されるメッセージにのみ適用され、格納されているメッセージには影響しません。すべてのトピック オプションのデフォルト値については、『WebLogic Server MBean リファレンス』の「TopicBean」を参照してください。
スタンドアロンのキューとトピックは、ドメイン内の特定の JMS サーバのみにデプロイできます。これは、永続メッセージ、恒久サブスクライバ、およびメッセージ ページングの管理に関しては、これらのキューとトピックは対象指定された JMS サーバに依存するからです。
キューとトピックのグループを接続ファクトリと共に特定の JMS サーバに関連付ける場合、これらの送り先と接続ファクトリを同じサブデプロイメントの対象として指定します。これによって、これらのリソースはサブデプロイメントの対象となる JMS サーバに関連付けられます。しかし、スタンドアロンのキューまたはトピックがサブデプロイメントのメンバーである場合、接続ファクトリは同じ JMS サーバのみに関連付けることができます。
JMS システム モジュールのサブデプロイメントの対象指定については、「JMS モジュールとサブデプロイメント リソースの対象指定」を参照してください。
JMS テンプレートを使用すると、同じようなオプション設定を持つ複数の送り先を効率的に定義できます。JMS テンプレートには、以下のような利点があります。
JMS テンプレートのコンフィグレーション可能なオプションは、送り先に対してコンフィグレーションされるオプションと同じです。これらのコンフィグレーション オプションは、それらを使用する送り先によって継承されます。ただし、以下の例外があります。
送り先に対して明示的に定義されないオプションには、デフォルト値が割り当てられます。デフォルト値が存在しない場合は、必ず、JMS テンプレートで値を指定するか、または送り先のオプションのオーバーライド値として値を指定します。
WebLogic Server Administration Console を使用すると、システム モジュール内の JMS テンプレート リソースをコンフィグレーション、変更、対象指定、および削除できます。JMS テンプレートに関するタスクの詳細については、Administration Console オンライン ヘルプの「JMS テンプレートのコンフィグレーション」を参照してください。
JMS テンプレートには、これを使用する送り先用に以下のコンフィグレーション パラメータが用意されています。
送り先のメッセージおよびバイト割り当てリソースのコンフィグレーションについては、「割り当てリソース」を参照してください。
送り先のメッセージ ライフ サイクル ロギングをコンフィグレーションする方法については、「メッセージ ライフ サイクルのロギング」を参照してください。
トピックでのメッセージ処理の休止については、「送り先でのメッセージ処理の制御」を参照してください。
テンプレートのオプションには、動的にコンフィグレーションできるものがあります。オプションが実行時に変更された場合、変更は新しく配信されるメッセージにのみ適用され、格納されているメッセージには影響しません。すべてのトピック オプションのデフォルト値については、『WebLogic Server MBean リファレンス』の「TemplateBean」を参照してください。
特定の送り先に到着したメッセージは、デフォルトでは FIFO (先入れ先出し) で格納され、各メッセージのユニークな JMSMessageID に基づいて昇順にソートされます。しかし、送り先キーを使用することで、送り先に対して LIFO (後入れ先出し) などの異なるソート方式をコンフィグレーションできます。
WebLogic Server Administration Console を使用すると、システム モジュール内の送り先キー リソースをコンフィグレーション、変更、対象指定、および削除できます。送り先キーに関するタスクの詳細については、Administration Console オンライン ヘルプの「送り先キーのコンフィグレーション」を参照してください。
すべての送り先キー オプションのデフォルト値については、『WebLogic Server MBean リファレンス』の「DestinationKeyBean」を参照してください。
Weblogic Server 9.0 より前のバージョンには、複数のレベルの割り当てが存在しました。送り先には独自の割り当てが設定され、JMS サーバの割り当てと競合する必要がありました。Weblogic Server 9.0 以降では、割り当てのレベルは 1 つだけです。つまり、送り先に独自の割り当てリソースを設定するか、または共有割り当てリソースを使用して送り先を他の送り先と競合させるかのいずれかになります。
割り当てリソースのコンフィグレーションの詳細については、「割り当ての定義」を参照してください。
外部サーバ リソースを使用すると、外部 (サードパーティ) JMS プロバイダをローカル WebLogic Server JNDI ツリー内で参照できます。外部サーバ リソースを使用することで、外部の JMS プロバイダを即座にマップして、関連付けられた接続ファクトリと送り先をローカル JMS オブジェクトのように WebLogic JNDI ツリーに表示できます。また、別のクラスタまたはドメインにある WebLogic Server のリモート インスタンスをローカル WebLogic JNDI ツリー内で参照することもできます。
外部サーバ リソースのコンフィグレーションの詳細については、「外部サーバ プロバイダへのアクセス」を参照してください。
分散送り先リソースは、単一の論理的な送り先としてクライアントからアクセス可能な 1 単位の送り先 (キューまたはトピック) です (たとえば分散トピックは独自の JNDI 名を持ちます)。この単位のメンバーは通常、クラスタ内の複数のサーバに分散されており、各メンバーは個々の JMS サーバに属しています。分散送り先を使用するアプリケーションは、単純な送り先を使用するアプリケーションより可用性が高くなります。WebLogic JMS は、クラスタ内の分散送り先のメンバーのためのロード バランシングとフェイルオーバの機能を備えているからです。
WebLogic Server では、以下の 2 種類の分散送り先がサポートされます。
共通分散送り先 - 共通分散送り先 (UDD) では、各メンバーには、すべての分散送り先パラメータ (重み、セキュリティ、永続性、ページング、割り当てなどに関するパラメータ) の一貫したコンフィグレーションが設定されます。
重み設定された分散送り先 - 重み設定された分散送り先では、各メンバーには、すべての分散送り先パラメータ (重み、セキュリティ、永続性、ページング、割り当てなどに関するパラメータ) の一貫したコンフィグレーションが設定されません。
分散送り先リソースのコンフィグレーションの詳細については、「分散送り先のコンフィグレーション」を参照してください。
JMS SAF リソースは、WebLogic ストア アンド フォワード (SAF) サービス上に構築され、高可用性を備えた JMS メッセージ生成を行います。たとえば、ローカル サーバ インスタンスに接続された JMS メッセージ プロデューサは、メッセージ送信時にリモートの送り先が一時的に利用できない場合でも、リモートの JMS 送り先に確実にメッセージを転送できます。JMS ストア アンド フォワードは JMS アプリケーションからは透過的なので、JMS クライアント コードは既存の JMS API を使用して、リモートの送り先にアクセスできます。
JMS SAF リソースのコンフィグレーションの詳細については、『WebLogic ストア アンド フォワードのコンフィグレーションと管理』の「JMS メッセージに対する SAF のコンフィグレーション」を参照してください。
|
|
|