ヘッダーをスキップ
Oracle® Fusion Middleware Oracle WebLogic Server JMSの構成と管理
11g リリース1 (10.3.6)
B61636-06
  ドキュメント・ライブラリへ移動
ライブラリ		 製品リストへ移動
製品		 目次へ移動
目次
前
前 		 次
次		  

9 JMS初級ユーザーおよび上級ユーザーのベスト・プラクティス

この章では、JMS初級ユーザーと上級ユーザーのためのアドバイスおよびベスト・プラクティスを示します。ターゲット設定、統合オプション、URLの概要、高可用性(HA)およびチューニングについて説明します。

構成のベスト・プラクティス

次の項では、JMSアプリケーションの構成方法に関する基本手順の概要を示します。

  1. JMSサーバーと永続ストアの構成

  2. JMSモジュールの構成

  3. JMSリソースの構成

  4. SAFエージェント、ストア、インポート宛先の構成

JMSサーバーと永続ストアの構成

JMSサーバーと永続ストアを構成する前に、次の内容を検討します。

  • 宛先、接続ファクトリ、およびその他のJMSリソースが、そのホストJMSサーバーおよび永続ストアとは別に構成されています。JMSリソースを構成するベスト・プラクティスの手順については後ほど説明します。

  • WebLogic分散宛先を利用する場合、WebLogicクラスタを、そのクラスタの各WebLogicサーバーのJMSサーバーとカスタム永続ストアで構成する必要があります。WebLogic JMS分散宛先が機能するには、WebLogicクラスタが機能している必要があります。

  • 移行可能ターゲットのみがクラスタでサポートされます。クラスタを使用していない場合、サイズ1のクラスタを再検討して使用できます。これにより、移行可能ターゲットを使用できます。移行可能ターゲットを使用すると、次に示すように便利な再起動インプレース機能が有効になります。また、単一サーバーから複数サーバーへの拡張プロセスが容易になるため、アプリケーションの将来保証にも役立ちます。

次の手順で、JMSサーバーと永続ストアを構成します。

  1. JMSサーバーをホストする各WebLogicサーバーでカスタム・ストアを作成します。WebLogicサーバーにすでにカスタム・ストアがある場合、サービスでストアを共有すると、通常は利便性とパフォーマンスが向上するため、この手順をスキップできます。(カスタム・ストアを使用する理由は何でしょうか。カスタム・ストアにより、チューニングと管理の柔軟性が高まります。また、デフォルト・ファイル・ストアは移行できません。

  2. クラスタで、各ストアをそのホスト・サーバーの「デフォルトの移行可能ターゲット」にターゲット指定します。クラスタを使用しない場合、各ストアをそのホスト・サーバーに直接ターゲット指定します。移行可能ターゲットでは、ストアに障害が発生した場合に再起動インプレース・オプションを使用でき、サービス移行オプションも有効になります。

    使用可能な場合(直接のサービス・ターゲットではない)、移行可能ターゲットに常にターゲット指定することをお薦めします。移行可能ターゲットは、サーバー移行オプション全体と互換性があり、サーバー移行全体がプライマリ・フェイルオーバー・オプションの場合でも通常は構成する必要があります。

  3. 各WebLogicサーバーでJMSサーバーを構成します。ステップ1で作成されたストアを参照するようにJMSサーバーを構成します。ストアに使用されたターゲットにJMSサーバーをターゲット指定します。複数のJMSサーバーで同じストアを参照できます。

  4. 各JMSサーバーでメッセージ数の割当てを構成します。デフォルトの割当てがないため、割当てを構成すると、メモリー不足状況の防止に役立ちます。経験則によれば、従来、各メッセージはページ・アウトする場合でも512バイトのメモリーを消費すると仮定されます。

  5. JMSページングはデフォルトで有効ですが、デフォルトの動作が環境に対して有効であることを確認します。

JMSモジュールの構成

同種のJMSサーバーは、非分散宛先をホストする単一JMSサーバーになるか、それぞれが同じ分散宛先をホストするように同様に構成されたJMSサーバーのセットになります。同種のJMSサーバーごとに、JMSモジュールと単一の関連サブデプロイメントを構成します。

  1. システム・モジュールを作成します。そのモジュールを、単一クラスタ(クラスタを使用する場合)または単一WebLogicサーバー・インスタンスにターゲット指定します。サブデプロイメントを利用する場合も常にモジュールをターゲット指定する必要があります。

    ほとんどの場合、デプロイ可能なアプリケーション・モジュールではなく、システム・モジュールを常に使用することをお薦めします。システム・モジュールは、管理コンソール、JMX API (Java MBean)、またはWLSTを使用して作成できます。デプロイ可能なモジュールに相当するツールはありません。デプロイ可能なモジュールを変更するには、XMLを手動で編集して再デプロイするしかありません。

  2. モジュールにつき厳密に1つのサブデプロイメントを作成します。サブデプロイメントは、管理コンソールでは「高度なターゲット指定」と呼ばれる場合もあります。1つのサブデプロイメントにより、簡単になります。つまり、サード・パーティによるターゲット指定が理解しやすくなり、構成エラーが生じる可能性が少なくなります。1つのサブデプロイメントで十分でない場合は2つのモジュールを作成します。

  3. サブデプロイメントはJMSサーバー(WebLogicサーバーではない)にのみ移入します。宛先をホストするJMSサーバーのみになります。これにより、JMSリソースを構成する際に、リソースが正しいJMSサーバーにターゲット指定されます。非分散宛先をサポートするモジュールの場合、サブデプロイメントは単一のJMSサーバーのみを参照する必要があります。分散宛先と非分散宛先が混在している場合、2つのモジュール(それぞれに各自のサブデプロイメントが含まれる)を使用します。

JMSリソースの構成

JMSリソースを構成し、そのリソースを適切にターゲット指定します。

  1. 宛先を作成し、その宛先を1つのサブデプロイメント(コンソールでは「高度なターゲット指定」と呼ばれる)にターゲット指定します。複数のJMSサーバーに解決するサブデプロイメント・ターゲットにターゲット指定できるのは分散宛先のみです。分散宛先、スタンドアロン宛先、インポート宛先が混在している場合、2つのモジュール(それぞれに各自のサブデプロイメントが含まれる)を使用します。「ターゲット指定のベスト・プラクティス」を参照してください。

  2. カスタム接続ファクトリを作成し、デフォルト接続ファクトリのかわりに使用します。デフォルト接続ファクトリは調整できません。

    ほとんどの場合、デフォルトのターゲット指定ではリソースがモジュールのターゲットを継承するため、デフォルトのターゲット指定と接続ファクトリを一緒に使用できます。リモート・クライアントでのみ使用される接続ファクトリの場合、モジュールのサブデプロイメント・ターゲットを使用します。

SAFエージェント、ストア、インポート宛先の構成

SAFエージェントとそのストア、およびそのインポート宛先は、JMSサーバーとそのストア、およびJMS宛先と同じベスト・プラクティスに従う必要があります。SAFエージェントは移行可能ターゲットを使用できないため、クラスタでSAFエージェントをターゲット指定しないでください。

ターゲット指定のベスト・プラクティス

JMSリソースには次のターゲット指定のガイドラインをお薦めします。

統合およびマルチドメインのベスト・プラクティス

次の項では、WebLogic Serverを使用する統合環境とマルチドメイン環境のベスト・プラクティス情報を示します。

WebLogic JMSクライアント・オプションの理解

クライアント・アプリケーション(WebLogic Serverに依存しないランタイム環境のアプリケーション)の場合、Java、.NET、Cクライアントなどの複数のJMSクライアント・オプションがあります。『Oracle WebLogic Serverスタンドアロン・クライアントのプログラミング』の「JMSクライアント」を参照してください。


注意:

WebLogic JMSクライアントは、外部トランザクション・マネージャを直接サポートしません。可能な場合、WebLogic TMを使用します。上級ユーザーの場合、トランザクション・サブシステムの割込みトランザクション・マネージャ機能をXAリソースとして使用できます。

WebLogic URLの理解

リモートWebLogic Serverインスタンスまたはクラスタと通信するアプリケーションは、サーバーやクラスタに接続する場合、JNDI InitialContextオブジェクトの作成時またはアプリケーション属性の設定時(あるいはその両方)にURLを指定する必要があります。

URL構文

WebLogic URL構文は次のようになります。

[t3|t3s|http|https|iiop|iiops]://address[,address]...

説明:

  • address = hostlist : portlist

  • hostlist = hostname [,hostname]...

  • portlist = portrange [+portrange]...

  • portrange = port [-port]

port-portを使用してポート範囲を示し、+で複数のポート範囲を分割します。たとえば、簡単なアドレスは、通常t3://hostA:7001のようになります。アドレスt3://hostA,hostB:7001-7002は、次のアドレスに相当します。

  • t3://hostA,hostB:7001+7002

  • t3://hostA:7001-7002,hostB:7001-7002

  • t3://hostA:7001+7002,hostB:7001+7002

  • t3://hostA:7001,hostA:7002,hostB:7001,hostB:7002

厳密なメッセージの順序付けのベスト・プラクティス

厳密に順序付けられたメッセージ処理が必要な場合、アプリケーションの設計と構成で、この要件を慎重に考慮する必要があります。

WebLogic JMS順序単位機能を利用する方法が最も簡単で効率的です。この方法では、通常、アプリケーションの変更は最小限(あるいは変更なし)で済みます。さらに、分散宛先、スケジュール済メッセージ、遅延メッセージ、トランザクション、ストア・アンド・フォワードとともに機能します。『Oracle WebLogic Server JMSのプログラミング』のメッセージ順序単位の使用に関する項を参照してください。

高可用性のベスト・プラクティス

高可用性(HA)またはスケーラビリティが気になる場合、クラスタ化されたWebLogic機能を利用するようにアプリケーションを開発します。非クラスタ・アプリケーションからクラスタ・アプリケーションへの変更は一般的に困難なプロセスであるため、これは初期構成およびアプリケーションの設計段階で行われる最適な手段になります。

WebLogic JMSでは、メッセージは、宛先のホストJMSサーバーが実行している場合のみ利用できます。メッセージが中央の永続ストアにある場合、最初にメッセージを格納したサーバーがメッセージにアクセスできる唯一のJMSサーバーになります。WebLogicには、障害後にJMSサーバーを自動的に再起動または移行(あるいはその両方)する機能があります。また、同じクラスタ内の複数のJMSサーバー間で宛先をクラスタリング(分散)する機能もあります。

通常、HAは次の両方を使用することで実現します。

分散キューと分散トピック

分散キューは、通常、任意のクラスタ化されたキューイング使用例に対してかなり容易に適用できます。分散トピックは、次のような場合に最も適しています。

  • サブスクライバが非恒久である場合。

  • または、MDBを使用してサブスクライブする場合(直接的な非恒久サブスクライバには制限があり、最新の拡張要素を使用する必要があることがあります)。

『Oracle WebLogic ServerメッセージドリブンBeanのプログラミング』のJMSトピックを使用したMDBの構成およびデプロイに関する項およびOracle WebLogic Server JMSのプログラミングの分散宛先の使用に関する項を参照してください。

JMSのパフォーマンスとチューニング

次の項には、WebLogic JMSをチューニングする場合に考慮する項目のチェックリストのリンクがあります。

  前
前 		 次
次
  ドキュメント・ライブラリへ移動
ライブラリ		 製品リストへ移動
製品		 目次へ移動
目次