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

Oracle WebLogic ServerのJMS初級ユーザーと上級ユーザーのための推奨事項とベスト・プラクティスについて学習します。次のトピックでは、WebLogic Serverのターゲット指定、統合オプション、URLの概要、高可用性(HA)およびチューニングについて説明します。

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

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

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

• クライアント・レジリエンシのベスト・プラクティス

• 分散宛先ベスト・プラクティス

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

• WebLogic URLの理解

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

• リモートJMS宛先の統合

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

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

JMSアプリケーションの構成には、永続ストア、JMSサーバー、JMSモジュールおよびJMSモジュール内のJMSリソースの構成が含まれます。モジュール内のJMSリソースには、JMS接続ファクトリ、JMSスタンドアロン宛先またはJMS分散宛先が含まれます。SAFアプリケーションの構成は、JMSサーバーがSAFエージェントに置き換えられ、分散宛先がインポート済宛先に置き換えられることを除き、非常に類似しています。次の各項で、基本的な手順の概要を説明します。

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

2. JMS割当ておよびページングの構成

3. JMSモジュールの構成

4. JMSリソースの構成

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

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

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

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

• WebLogic JMS分散宛先が機能するには、WebLogicクラスタが機能している必要があります。

• クラスタ化されたJMS構成には、2種類あります。

  • クラスタをターゲットとして指定されたJMSサーバーおよびストアは、簡略化された構成、簡略化されたHA、およびリソースの動的スケーリング機能を提供します。クラスタ・サイズの増加に応じて、JMSサーバー、ストアおよび分散宛先メンバーが構成の変更を必要とせずに自動的に追加されます。

    ノート:

    クラスタをターゲットとして指定されたJMSは、構成されたクラスタのかわりにWebLogic動的クラスタを利用する場合には使用可能な唯一のJMSオプションです。「簡略化されたJMSクラスタと高可用性の構成」を参照してください

  • 個別に構成されたJMS HAは、個別に構成されたJMSサーバーおよびストアのセットからなり、これらのサーバーおよびストアにターゲットとしてクラスタ内の移行可能なターゲットが指定されます。このオプションは、主に、以前のバージョンとの互換性を保つために存在しています。

• クラスタを使用していない場合は、最小サイズのクラスタを再検討して使用し、スタンドアロン宛先のかわりに分散宛先を使用する可能性があります。これにより、構成とアプリケーションを複数のサーバーに容易に拡張できるようになるため、将来のHAおよびスケーリングのサポートについて、ご使用のアプリケーションが「将来においても有効な」ものになります。非クラスタ・アプリケーションおよび構成をクラスタ化されたトポロジに変更するのは困難なプロセスであるため、クラスタの活用は、構成およびアプリケーション設計の初期段階で行うのが最適です。

ノート:

高可用性とスケーリングについては、移行可能なターゲットを使用するかわりに、適切な高可用性構成設定とともにJMSアーティファクトにクラスタをターゲットとして指定することをお薦めします。

クラスタにJMSサーバーと永続ストアを構成するには、次のステップを実行します。

クラスタをターゲットとしてJMSを設定するステップは、次のとおりです。

1. カスタム・ストアを作成し、クラスタにターゲット指定します。「簡略化されたJMSクラスタと高可用性の構成」を参照してください「データの安全な永続化」で説明しているように、データを安全に永続化できるようにストアが構成されていることを確認します。

2. JMSサーバーを構成して、同じクラスタにターゲット指定します。さらにステップ1で作成したストアを参照するようにJMSサーバーを構成します。複数のJMSサーバーで同じストアを参照できます。

クラスタ内の個別に構成されたJMSを設定するステップは、次のとおりです。

1. クラスタ内の各WebLogic Serverにカスタム・ストアを作成します。各ストアを、サーバー上のデフォルトの移行可能なターゲット、またはカスタム移行可能なターゲットにターゲット指定します。Oracle WebLogic Serverクラスタの管理のサービスの移行を参照してください。「データの安全な永続化」で説明しているように、データを安全に永続化できるようにストアが構成されていることを確認します。

   ノート:

   チューニングと管理の柔軟性が高まるカスタム・ストアを使用することをお薦めします。また、デフォルト・ファイル・ストアはJVM間で移行できません。移行可能なのはカスタム・ストアのみです。

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

JMS割当ておよびページングの構成

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

ノート:

永続JDBCストア・メッセージ、永続ファイル・ストア・メッセージおよび非永続メッセージはすべて、ページ・アウトするまでJVMメモリーに完全にキャッシュされます。また、すべてのタイプのメッセージにおいて、メッセージがページ・アウトした後もJVMメモリーにヘッダーが残ります。

JMSページングはデフォルトで有効ですが、デフォルトの動作が環境に対して有効であることを確認します。『Oracle WebLogic Serverのパフォーマンスのチューニング』のメッセージのページングによるメモリーの解放に関する項を参照してください。

JMSモジュールの構成

JMSモジュールで、JMS接続ファクトリおよび宛先の構成がカプセル化されます。ベスト・プラクティスは、クラスタ内の同種のJMSサーバーのセットごとに、システム・モジュールとシステム・モジュール・サブデプロイメントを構成することです。これにより、JMSモジュール・リソース構成、JMSモジュール・サブデプロイメントおよびJMSサーバー構成の間で単純な1対1の対応が保持されます。

同種のJMSサーバーのセットは、次のいずれかです。

• ストアの分散ポリシーがDistributedに設定されている、クラスタをターゲットとして指定された単一のJMSサーバー。

• ストアの分散ポリシーがSingletonに設定されている、クラスタをターゲットとして指定された単一のJMSサーバー。

• 1つ以上の個別に構成されたJMSサーバーのセット。

異なるJMS構成は、それぞれ異なる構成名と異なるJNDI名が使用されているかぎり、同じクラスタ・スコープに共存できます。

具体的には、次のようになります。

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

   ノート:

   システム・モジュールは、JMSリソースの構成方法として推奨されます。これに対し、デプロイ可能なモジュールとJMSリソース定義は推奨されません。デプロイ可能なモジュールは、非推奨になった機能です。構成可能なシステム・モジュールを使用した接続ファクトリおよび宛先の指定は、通常、アプリケーションにハード・コードされた構成よりもはるかに柔軟で保守性がよく、移植も容易なため、JMSリソース定義よりもシステム・モジュールのほうが強く推奨されます。

2. モジュールにつき厳密に1つのサブデプロイメントを作成します。サブデプロイメントは、WebLogic Server管理コンソールでは「高度なターゲット指定」と呼ばれる場合もあります。1つのサブデプロイメントにより、簡単になります。つまり、サード・パーティによるターゲット指定が理解しやすくなり、構成エラーが生じる可能性が少なくなります。1つのサブデプロイメントで十分でない場合は2つのモジュールを作成します。
3. 前述の「同種のJMSサーバーのセット」に含まれているJMSサーバーのみをサブデプロイメントに移入します(これは、クラスタをターゲットとして指定された簡略化されたJMS構成では、単一のJMSサーバーになります)。サブデプロイメントでWebLogic Serverまたはクラスタを参照しないでください。宛先をホストするJMSサーバーのみになります。これにより、次のステップでJMSリソースを構成する際に、リソースが正しいJMSサーバーにターゲット指定されます。非分散宛先をサポートするモジュールの場合、サブデプロイメントは、個別に構成された単一のJMSサーバー、または分散ポリシーがSingletonに設定されているストアを参照する、クラスタをターゲットとして指定された単一のJMSサーバーのみを参照する必要があります。分散宛先をサポートするモジュールの場合は、分散ポリシーがDistributedに設定された、クラスタをターゲットとして指定された単一のJMSサーバー、または個別に構成されたJMSサーバーの同種のセットを常に選択してください。分散宛先と非分散宛先が混在している場合、2つのモジュール(それぞれに各自のサブデプロイメントが含まれる)を使用します。

JMSリソースの構成

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

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

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

3. 接続ファクトリのマップされないリソース参照のモードを、デフォルト値「ReturnDefault」のままにしておくのではなく、「FailSafe」に設定します。値を「FailSafe」にすると、アプリケーションはマップされないリソース参照を確実に使用しません。『Oracle WebLogic Serverリリース・ノート』の接続ファクトリのマップされないリソースの動作変更に関する項を参照してください。
   マップされないリソース参照モードの設定の詳細は、「接続ファクトリのマップされないリソース参照モードの指定」を参照してください。

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

SAFエージェントとそのストア、およびそのインポート宛先は、JMSサーバーとそのストア、およびJMS宛先と同じベスト・プラクティスに従う必要があります。

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

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

これらは次のとおりです。

• デフォルトのターゲット指定、WebLogicサーバーのターゲット指定、宛先を含むクラスタのターゲット指定は避けてください。かわりに、宛先で高度なターゲット指定(サブデプロイメントのターゲット指定)を使用して、サブデプロイメントがJMSサーバーまたはSAFエージェントのみを参照するようにしてください。これは、非分散、分散およびインポート済を含む、すべての宛先タイプに適用されます。

  ドメインの現在のJMSサーバーまたはSAFエージェントのみが特定のアプリケーションに使用される場合でも、次の理由によりこれがベスト・プラクティスとなります。

  • 現在のアプリケーションに関連しない新しいJMSサーバーまたはSAFエージェントは、他のアプリケーション、Webサービス、またはサード・パーティ製品で導入できます。

  • 今後、アプリケーションでは、スケーラビリティや管理上の目的で異なる宛先や異なるJMSサーバーまたはSAFエージェントが必要になります。

• Webサービス・デプロイメントおよびエラー・キューを構成する場合は常に高度なターゲット指定を使用します。これは、開発環境と本番環境のどちらも該当します。

• 分散キュー内でエラー宛先を使用するには、その親の宛先と同じサブデプロイメントにエラー宛先をターゲット指定する必要があります。

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

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

WebLogic Serverで高可用性機能を実現および利用するためのベスト・プラクティスを学習します。

この項には次のトピックが含まれます:

• クラスタでのアプリケーションの開発

• WebLogic HA機能の利用

• データの安全な永続化

クラスタでのアプリケーションの開発

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

WebLogic HA機能の利用

WebLogic JMSでは、メッセージのホストJMSサーバー・インスタンスが実行中の場合にのみ、コンシューマが送信メッセージを使用できます。メッセージが共有ファイル・システムまたはデータベース、あるいは分散宛先に格納されている場合でも、メッセージを回復できるJMSサーバー・インスタンスは、メッセージが最初に格納されたのと同じインスタンスのみです。たとえば、メッセージが複数のJMSサーバー・インスタンスでホストされている分散キューに送信された場合、メッセージはこれらのインスタンスの1つのみに内部的にロード・バランシングされ、その特定のインスタンスに格納されます。後にそのインスタンスがクラッシュした場合、そのインスタンスが再起動するまでの間、メッセージはコンシューマに対して使用不可になります。

障害後にメッセージの可用性を回復するために、WebLogicには、WebLogic Server JVM全体を自動的に再起動または移行(あるいはその両方)する機能があります。これには、障害の発生後にJVM内でJMSサーバーおよびストア・インスタンスを格納する機能、または同じクラスタ内にある別のJVMにインスタンスを移行する機能も含まれています。最後に、同じクラスタ内の複数のJMSサーバー間で宛先をクラスタリング(分散)する機能があります。分散宛先は、宛先の保存済メッセージの一部が、障害が発生したJMSサーバーおよびストアが再起動または移行されるまで待機している間使用できない場合でも、論理宛先のその他のメッセージは実行中のJMSサーバーを介して生成および使用できるため、高可用性の実現に役立ちます。

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

• WebLogicクラスタリング(動的または構成済クラスタ)。詳細は、『Oracle WebLogic Serverクラスタの管理』のWebLogic Serverのクラスタリングの理解に関する項を参照してください。

• サーバー全体の移行または再起動(あるいはこの両方)。Oracle WebLogic Serverクラスタの管理のサーバー全体の移行を参照してください。

• WebLogic JMSサーバーおよびストアの再起動準備完了。『WebLogic永続ストアの管理』のサービスの再起動準備完了に関する項を参照してください。

• クラスタ内でのJVM間のJTAサービスの移行(JMSアプリケーションはトランザクションを利用することが多いため)。Oracle WebLogic Serverクラスタの管理のサービスの移行を参照してください。

• クラスタ内でのJVM間のJMSサービスの移行。Oracle WebLogic Serverクラスタの管理のサービスの移行を参照してください。

• クラスタ・リーシング。サービスの自動移行とサーバー全体の自動移行では、いずれもクラスタ・リーシングを設定する必要があります。クラスタ・リーシングでなく、データベース・リーシングを構成するのがベスト・プラクティスです。Oracle WebLogic Serverクラスタの管理のリースを参照してください。

• 分散宛先。『Oracle WebLogic Server JMSアプリケーションの開発』の分散宛先の使用に関する項を参照してください。

データの安全な永続化

• ファイル・ストアを使用している場合は、ファイルが高可用性のストレージ(RAIDなど)に格納されていること、および障害発生後にファイル・データを回復できるように、クラスタ内のすべてのマシンから(SANなどを介して)、またはサーバー全体の移行後にWebLogic Serverをホストする可能性のあるすべてのマシンから一元的にアクセスできることを確認してください。JTAがJDBC TLogストアを使用していない場合は、トランザクション・ログはデフォルトでデフォルト・ファイル・ストアに格納されるため、デフォルト・ファイル・ストアも同様に高可用性と一元的なアクセスが必要となります。『WebLogic永続ストアの管理』のファイルの場所に関する項および高可用性ファイル・ストアについてのその他の要件に関する項を参照してください。

  ノート:

  ファイル・ストアが中央ディレクトリの場所を使用するようにするには、カスタムまたはデフォルト・ファイル・ストアのディレクトリを明示的に構成することが重要です。そうしない場合、ファイル・ストアは現在のWebLogic Server名に基づいたディレクトリの場所を使用してデータを回復するため、ファイル・ストアがWebLogic Server間を移動した場合に間違ったディレクトリからデータを回復する可能性があります。

• ページング・ファイルとキャッシュ・ファイルは、高可用性を必要とせず、パフォーマンス上の理由により、ローカル・ファイル・システムに配置する必要があります。

• カスタム・データベース・ストア、トランザクション・ログJDBCストアまたはクラスタ・データベース・リーシングを使用している場合は、データベース表をOracle RACなどの可用性の高いデータベース・ソリューションに格納する必要があります。

• データの非同期レプリケーションを利用する障害回復ソリューションがある場合は、通常、ファイル・ベースのストレージはお薦めしません。かわりに、すべてのJMSデータとJTAデータを、メッセージング操作とデータベース操作の組合せを実行する任意のアプリケーションと同じデータベースに格納することを強くお薦めします。これにより、障害回復後も、回復されたメッセージおよびデータの同期を保つことができます。『WebLogic永続ストアの管理』のJDBCストアの使用に関する項およびJDBC TLogストアの使用に関する項を参照してください。

クライアント・レジリエンシのベスト・プラクティス

JMSレジリエンシを確保するには、一般に、インフラストラクチャ・レベル・レジリエンシおよびJMSアプリケーション・レジリエンシの2つの主な領域で注意が必要です。

前述の「高可用性のベスト・プラクティス」で説明しているように、最初の領域はインフラストラクチャ・レベルの回復力で、これは通常、構成によって解決され、永続性、クラスタの活用、JVM移行およびサービス移行が含まれます。2つ目の領域はJMSアプリケーションの回復力です。これは一般に、JMSプロバイダ(WebLogic JMSのみでなく)に適用されるコーディングのベスト・プラクティスによって解決され、次で説明しています。

JMSプロバイダとの間で回復不能なクライアントAPIレベルのメッセージング障害が発生した場合には、プログラマが責任を持って関連するJMSリソースを閉じて再作成し、また必要に応じて失敗した操作を再試行するようにします。JMSリソースを再作成するための推奨ステップは、JMSリソースを作成する場合と同様です。たとえば、JMSプロデュースまたはJMSコンシュームの呼出しで例外がスローされた場合は、親のJMS接続またはJMSコンテキストを閉じ、初期JNDIコンテキストを閉じて(まだ開いている場合)、最後に初期コンテキストを再作成し、JMS接続ファクトリおよび宛先をJNDIから再取得して、接続またはJMSContext、セッション、プロデューサまたはコンシューマを再作成します。

サーバー側アプリケーションでの例外処理は、通常、JMS非同期コンテナまたはプーリングを利用することで簡略化されます。

• サーバー側メッセージングでの同期アプリケーションのエラー処理では、組込みプーリングを利用して問題を単純に処理できます(たとえば、接続、セッションおよびプロデューサを作成し、各送信済メッセージに対する接続を閉じるなど)。プールにより、キャッシュからオブジェクトが取得され、必要に応じて再作成されます。プーリングは、JMS接続ファクトリにアクセスするリソース参照、またはJMS 2.0 Java EE 7 JMSコンテキスト・インジェクションを使用して透過的に有効化されます。リソース参照によってオブジェクトがプールされる場合でも、通常、エラーの発生後には新しいJMS接続ファクトリまたは宛先オブジェクトを取得するのが最良です(これらのオブジェクトがなんらかの理由で変更されている場合に備えて)。『Oracle WebLogic Server JMSアプリケーションの開発』のEJBやサーブレットと組み合せたWebLogic JMSの使用に対する拡張サポートに関する項を参照してください。

• 非同期のonMessageサーバー側メッセージングのエラー処理では、通常、WebLogic MDBコンテナを利用するか、MDBが選択肢にない場合はフレームワークからのJMS JCAアダプタを利用するのが最良です。これらのコンテナにより、障害が自動的に処理され、必要に応じて再試行されます。詳細は、『Oracle WebLogic ServerメッセージドリブンBeanの開発』を参照してください。

非同期メッセージング・アプリケーションでコンテナを利用できない場合は、アプリケーションで接続にonException例外リスナーを登録し、障害を検出して処理することを強くお薦めします。javadocのjavax.jms.Connection.setExceptionListener()、またはJMS 2.0を使用している場合はjavax.jms.JMSContext.setExceptionListener()を参照してください。

ノート:

• JMSクライアント・オブジェクトの再作成を必要としない例外タイプが1つあります。それは、メッセージ・プロデューサによってスローされるjavax.jms.ResourceAllocationExceptionです。この例外は、割当て条件に達したためにサーバーがメッセージを受け入れられないという、メッセージ割当て障害を示しています。

• アプリケーションでは、比較的負荷の高い作成操作が頻繁に実行されすぎるのを防ぐために、短期間での操作の再試行を回避する必要があります。これは、ほとんどの障害は即時には解決されず、JNDIコンテキスト、接続、セッション、プロデューサまたはコンシューマなどのJMSクライアント・オブジェクトを短期間のうちに頻繁に破棄して作成すると、メッセージの送信または受信などの通常の実行時操作よりもはるかに高い負荷がかかる可能性があるためです。つまり、短期間での再試行は、他の操作よりもはるかに多くのリソースを消費する可能性があります。Oracleでは、即時に1回再試行した後、少なくとも最大数秒間の間隔をおき、再試行の間隔を段階的に長くすることをお薦めします。

• JMSリソースのプールまたはキャッシュは、非常に推奨されるベスト・プラクティスです。エラー処理を簡略化するために、このアドバイスを無視して、各JMSメッセージに対して常に新しいJMS接続やセッションなどを作成するアプリケーションを上書きしたほうがよいと感じることがあります。しかし、これらのアイテムがプールまたはキャッシュされない場合、短期間での再試行について前述したのと同じコスト上の理由により、このアプローチはお薦めしません。メッセージング・アプリケーションによっては、パフォーマンスへの影響が5倍以上になる場合があります。プーリングを使用できない場合は、アプリケーションでJMSオブジェクトをキャッシュして再利用できるようにすることをお薦めします。

• 操作で成功が返されれば、その操作は成功したと想定できますが、例外がスローされた場合には、常にその操作が失敗したと想定できるわけではありません。たとえば、メッセージ送信の失敗は、生成されたメッセージがサーバーの宛先に正常に届いていても、サーバーが内部の成功応答を送信元クライアントに送信できなければ発生する可能性があります。別の例としては、コミット呼出しの失敗は、必ずしもトランザクションがコミットされなかったことを示しているわけではありません(プロデューサの例と同様の理由により)。

• JMS接続ファクトリでの構成可能なWebLogic JMS再接続設定、および対応する再接続weblogic.jms.extension.WLConnectionおよびweblogic.jms.extension.JMSContext APIは非推奨になっています。これらによって、可能性のあるすべての障害が処理されるわけではなく、前述のレジリエンシのベスト・プラクティスに置き換わる効果ももたらされません。これらは、将来のリリースでは削除または無視される予定です。

分散宛先ベスト・プラクティス

分散宛先を使用するアプリケーションは、単純な宛先を使用するアプリケーションより可用性が高くなります。WebLogic JMSは、クラスタ内の分散宛先のメンバーのためのロード・バランシングとフェイルオーバーの機能を備えているからです。

• 分散キュー

• 分散トピック

• 重み設定された分散宛先

分散キュー

分散キューは、任意のクラスタ化されたキューイング使用例に対してかなり容易に適用でき、そうした使用例からMDB、SOA JMSアダプタまたはOSAアダプタから使用する際に適用が最も簡単です。MDBおよびアダプタ・オプションは、すべての分散宛先メンバーがコンシューマによって処理されていることを自動的に確認します。さらに、これらのコンテナは障害に対して回復力があり、一般に、宛先タイプに関係なく、コンシューマ・アプリケーションの安全かつマルチスレッド化するための実証済の簡単な方法を提供します。

分散トピック

分散トピックは、直接サブスクライバに制限があり、高度な拡張機能の使用が必要ため、MDB、SOA JMSアダプタまたはOSA JMSアダプタを使用してサブスクライブする場合に最適です。MDBおよびアダプタ・コンテナは、自動的にサブスクリプションおよびコンシューマを設定します。

分散トピックは、「レプリケートされた分散トピック」ではなく、「パーティション化された分散トピック」(共通分散トピック・タイプ)として設定することをお薦めします。これは、RDTは動的クラスタ、WebLogicマルチテナント、またはクラスタをターゲットとして指定されたJMS構成ではサポートされていないが、PDTはすべての拡張機能でスケーラビリティとフル・サポートを提供する傾向があるからです。PDTは、転送ポリシーがレプリケートされるかわりにパーティション化されるように構成された共通分散トピックです。RDTをすでに使用している場合には、PDTに置き換えることを検討してください。

『Oracle WebLogic ServerメッセージドリブンBeanの開発』の「JMSトピックを使用したMDBの構成とデプロイメント」と、『Oracle WebLogic Server JMSアプリケーションの開発』の「分散宛先の使用」およびRDTのPDTへの置き換えに関する項を参照してください。

重み設定された分散宛先

重み設定された分散宛先のかわりに、共通分散宛先を使用することを強くお薦めします。重み設定された分散宛先は非推奨となり、WebLogic Server 9.0で共通分散宛先に取って代わりました。重み設定された分散宛先は、動的クラスタ、WebLogicマルチテナントまたはクラスタをターゲットとして指定されたJMS構成ではサポートされません。

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

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

ノート:

WebLogic JMSクライアントは、外部トランザクション・マネージャを直接サポートしません。可能な場合、WebLogic TMを使用します。上級ユーザーの場合、トランザクション・サブシステムの割込みトランザクション・マネージャ機能をXAリソースとして使用できます。『Oracle WebLogic Server JTAアプリケーションの開発』のサード・パーティ・トランザクション・マネージャで管理されるトランザクションへの参加に関する項を参照してください。

WebLogic URLの理解

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

• JMSリソースと同じサーバーやクラスタで実行するアプリケーションのURLを指定しないでください。最初のコンテキストがURLを指定せずに作成されると、ローカル・サーバーまたはクラスタJNDIが自動的に参照されます。

• URLが複数のアドレスに解決する場合、WebLogic Serverクライアントはリスト内のアドレスをランダムに選択して開始し、成功するまで順番に各アドレスを自動で試行します。

• 本番システムでは、「URL構文」に示す複数のホスト/ポートURL表記を使用せず、最初のホスト名解決にDNSラウンド・ロビンやハードウェア・ロード・バランサを使用することを検討します

ノート:

JMS接続ファクトリは、JNDIから取得されます。ただし、デフォルトでは、JNDIコンテキスト・アドレスとは関係なく、接続がロード・バランスされます。JMS接続ファクトリは通常、JMS接続ファクトリの構成済ターゲットに含まれるサーバー間でロード・バランシングを行います。EJBリファレンスと同様に、JMS接続ファクトリは、ドメイン構成から暗黙的に取得され、クラスタの拡張および縮小に伴って暗黙的に更新されるサーバー・アドレスのリストを含む「スマート・スタブ」です。つまり、JNDIコンテキストのURLがクラスタ内の単一のサーバーのみを参照していて、このJNDIコンテキストからクラスタをターゲットに指定されたまたはターゲットがデフォルト指定される接続ファクトリが取得されても、JMS接続はクラスタ全体でロード・バランシングされます。

URL構文

WebLogic 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の「順序単位」機能を使用することをお薦めします。UOOは、最もシンプルで最も厳密に機能する配信順序オプションであり、同じ宛先内で様々な順序の並行消費をサポートします。通常、アプリケーションへの変更を最小限にするか、アプリケーションを変更することなく、あらゆるタイプの障害に対応します。さらに、分散宛先、スケジュールされたメッセージ、遅延されたメッセージ、トランザクション、ストア・アンド・フォワードを処理します。

JMS順序単位を分散宛先またはSAFインポート済宛先と組み合せて使用​​する場合は、宛先の順序単位ルーティング・ポリシーを「パス・サービス」オプションに構成し、クラスタの「パス・サービス」を構成することをお薦めします。「パス・サービス」オプションは、新しいメンバーが分散宛先に構成されている場合でも順序を保持し、クラスタ・ターゲットのJMS構成で唯一サポートされているポリシーです。

『Oracle WebLogic Server JMSアプリケーションの開発』のメッセージ順序単位の使用に関する項を参照してください。

厳密なメッセージの順序付けが必要で順序単位機能が使用できない場合には、『Oracle WebLogic Server JMSアプリケーションの開発』のメッセージの再配信の順序付けに関する項を参照してください。

リモートJMS宛先の統合

リモートJMS宛先をローカルのWebLogic ServerまたはWebLogic Clusterに統合するには、リモートJMS宛先および接続ファクトリJNDI名をローカル・スタンドアロン・サーバーJNDIまたはローカル・クラスタJNDIネームスペースにマップする外部JMSサーバー・マッピングを構成することがベスト・プラクティスです。マッピングできる宛先には、WebLogic JMS宛先、Oracle AQ JMS宛先およびOracle以外のJMS宛先が含まれます。

さらに、別のベスト・プラクティスとしては、外部JMSサーバー・マッピングをMDB、res-refかコンテキスト・インジェクションJMSプール、またはメッセージング・ブリッジと組み合せて使用​​する方法があります。これらのコンポーネントは、マッピングに加えて外部JMSサーバーで構成されたセキュリティ資格証明を使用してリモートJMSリソースにアクセスします。

または、WL JMS SAFエージェントを使用して、リモートWebLogic JMSメッセージをローカル・サーバーまたはクラスタに転送することを検討してください。

『Oracle WebLogic Server JMSアプリケーションの開発』の「FAQ :リモートJMSプロバイダの統合」を参照してください。

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

次のリンクには、WebLogic JMSのチューニング時に考慮する項目のチェックリストが記載されています。

• Oracle WebLogic ServerのパフォーマンスのチューニングのJMSのパフォーマンスとチューニングのチェックリストを参照してください。