| Oracle® Fusion Middleware Oracle WebLogic Server JMSリソースの管理 12c (12.2.1.1.0) E77273-01 |
|
 前 |
 次 |
この章の内容は次のとおりです。
WebLogic Serverのクラスタとはドメイン内で連携して動作するサーバーのグループであり、単一のサーバーよりもスケーラブルで信頼性のあるアプリケーション・プラットフォームを提供します。クラスタはそのクライアントからは単一のサーバーに見えますが、実際には一体で機能するサーバー群です。
注意:
JMSクライアントがクラスタに正常にアクセスするには、一意のWebLogic Server名が必要です(WebLogic Serverが別々のドメインに存在する場合にも必要です)。このため、JMSクライアントがアクセスするWebLogic Serverの名前は、すべて一意でなければなりません。
JMSクラスタリングには、以下のメリットがあります。
クラスタ内の複数のサーバーにわたる宛先のロード・バランシング
管理者は、次のようにして、クラスタ内の複数のサーバーにわたって宛先のロード・バランシングを設定できます。
1つのJMSサーバーを構成し、1つのWebLogicクラスタをターゲットに指定します。「簡略化されたJMSクラスタと高可用性の構成」を参照してください
複数のJMSサーバーを構成し、構成済の複数のWebLogic Serverをターゲットに指定する。
複数のJMSサーバーを構成し、1つの移行可能なターゲットのセットをターゲットに指定する。
各JMSサーバーは、厳密に1つのWebLogic Serverインスタンスにデプロイされ、宛先の集合に対するリクエストを処理します。
宛先の高可用性
分散宛先: 分散宛先のキューおよびトピック・メンバーは通常、クラスタ内の複数のサーバーに分散され、各メンバーは個々のJMSサーバーに属します。分散宛先を使用するアプリケーションは、単純な宛先を使用するアプリケーションより可用性が高くなります。WebLogic JMSは、クラスタ内の分散宛先のメンバーのためのロード・バランシングとフェイルオーバーの機能を備えているからです。分散宛先の詳細については、「分散宛先リソースの構成」を参照してください
ストア・アンド・フォワード: JMSモジュールはSAFサービスを使用して、ローカルのJMSメッセージ・プロデューサがリモートのキューまたはトピックに確実にメッセージを送信できるようにします。ネットワークの問題やシステム障害が原因で、メッセージの送信時に宛先が使用不能になっている場合、メッセージはローカルのサーバー・インスタンスに保存され、リモートの宛先が使用可能になった時点で転送されます。詳細は、『Oracle WebLogic Serverストア・アンド・フォワード・サービスの管理』のストア・アンド・フォワード・サービスの理解に関する項を参照してください。
自動フェイルオーバーの場合、WebLogic Serverはサーバー・レベル(サーバー・インスタンス全体)での移行をサポートします。WebLogic Serverがホストするすべてのサービスを別のマシンに自動または手動で移行できます。詳細は、『Oracle WebLogic Serverクラスタの管理』のサーバー全体の移行に関する項を参照してください。
クラスタ内のあらゆるサーバーからの、宛先へのクラスタ全体で透過的なアクセス
管理者は、クラスタ内の各サーバー・インスタンスのデフォルト接続ファクトリを使用するか、1つまたは複数の接続ファクトリを構成してクラスタ内の1つまたは複数のサーバー・インスタンスまたはクラスタ全体をターゲットとすることで、クラスタ内のあらゆるサーバーから宛先へのクラスタ全体で透過的なアクセスを確立できます。これにより、各接続ファクトリを複数のWebLogic Serverインスタンスにデプロイできます。接続ファクトリについては、「接続ファクトリの構成」を参照してください
スケーラビリティ
クラスタ内の複数のサーバーにわたる宛先のロード・バランシング。
接続ファクトリを通じた、複数のJMSサーバーでのアプリケーション負荷の分散。その結果として、個々のJMSサーバーでの負荷が削減され、かつ接続先を特定のサーバーに決めることでセッションの集中が可能となります。
マルチキャストのサポート(オプション)。JMSサーバーで配信しなければならないメッセージの数が削減されます。JMSサーバーでは、サブスクライブしているアプリケーションの数に関係なく、マルチキャストIPアドレスと関連付けられている各ホスト・グループに対してメッセージが1コピーだけ転送されます。
移行性
WebLogic Serverはサーバー・レベル(サーバー・インスタンス全体)での移行をサポートします。WebLogic Serverがホストするすべてのサービスを別のマシンに自動または手動で移行できます。詳細は、『Oracle WebLogic Serverクラスタの管理』のサーバー全体の移行に関する項を参照してください。
WebLogic Serverは、クラスタをターゲットとして指定されたJMSサービスの自動サービス移行をサポートします。移行可能なターゲットを使用するかわりに、JMSサービス移行の場合はこの優先メソッドを使用してください。詳細は、「簡略化されたJMS構成と高可用性の拡張機能」を参照してください。
JMSクライアントに対するサーバー・アフィニティ
クラスタ用に構成したロード・バランシング・アルゴリズム(ラウンドロビン・アフィニティ、重みベース・アフィニティ、またはランダム・アフィニティ)は、JMSクライアント接続のためのサーバー・アフィニティを提供します。JMSアプリケーションから指定したサーバー・インスタンスに接続できる場合、JMSは同じサーバー・インスタンスとの新しいJMS接続を確立しようとします。サーバー・アフィニティの詳細は、『Oracle WebLogic Serverクラスタの管理』のクラスタでのロード・バランシングに関する項を参照してください。
WebLogicクラスタの使用による機能と利点の詳細は、『Oracle WebLogic Serverクラスタの管理』のWebLogic Serverのクラスタリングの理解に関する項を参照してください。
管理者は、クラスタ内の各サーバー・インスタンスのデフォルト接続ファクトリを使用するか、1つまたは複数の接続ファクトリを構成してクラスタ内の1つまたは複数のサーバー・インスタンスまたはクラスタ全体をターゲットとすることで、クラスタ内のあらゆるサーバーからJMS宛先へのクラスタ全体で透過的なアクセスを確立できます。これにより、各接続ファクトリを複数のWebLogic Serverにデプロイできます。接続ファクトリの構成とデプロイメントの詳細は、「接続ファクトリの構成パラメータ」を参照してください。
アプリケーションでは、Java Naming and Directory Interface (JNDI)を使用して接続ファクトリをルックアップし、JMSサーバーとの通信を確立するための接続を作成します。各JMSサーバーでは、複数の宛先に対するリクエストが処理されます。宛先へのリクエストが送信されるWebLogic Serverインスタンスが接続ファクトリのホストであり、JMSサーバーまたは宛先のホストではない場合、リクエストは接続ファクトリによって、JMSサーバーと宛先のホストになっている適切なWebLogic Serverインスタンスに転送されます。
管理者は、クラスタ内の様々なサーバー上の複数のJMSサーバーに一意の名前が付けられているかぎり、それらのJMSサーバーを構成して、JMSキューまたはトピック・リソースを割り当てることができます。または、クラスタの1つのJMSサーバーをターゲットにして、そのクラスタの各サーバーにJMSサーバーのインスタンスが自動的に作成されるようにすることもできます。アプリケーションでは、Java Naming and Directory Interface (JNDI)を使用して接続ファクトリをルックアップし、JMSサーバーとの通信を確立するための接続を作成します。各JMSサーバーでは、複数の宛先に対するリクエストが処理されます。JMSサーバーで処理されない宛先へのリクエストは、適切なWebLogic Serverインスタンスに転送されます。JMSサーバーの構成とデプロイメントの詳細は、「JMSサーバーの構成」を参照してください。
単一のWebLogicドメイン環境または複数ドメイン環境でJMSオブジェクトおよびリソース(JMSサーバー、JMSモジュール、JMSリソースなど)がクラスタ化された環境で動作するように構成する際には、いくつかの命名要件があります。詳細については、「JMS構成のネーミング要件」を参照してください
分散宛先リソースは、単一の論理的な宛先としてクライアントからアクセス可能な1つの宛先セット(キューまたはトピック)です(たとえば分散トピックは独自のJNDI名を持ちます)。この単位のメンバーは通常、クラスタ内の複数のサーバーに分散されており、各メンバーは個々のJMSサーバーに属しています。分散宛先を使用するアプリケーションは、単純な宛先を使用するアプリケーションより可用性が高くなります。WebLogic Serverは、クラスタ内の分散宛先のメンバーのためのロード・バランシングとフェイルオーバーの機能を備えているからです。詳細については、「分散宛先リソースの構成」を参照してください
JMSサービスは、サーバー全体の移行(サーバーでホストされるすべてのサービスを別のマシンに移行する場合)だけでなく、シングルトン・サービスの移行フレームワークに組み込むこともできます。したがって、たとえばサーバーの障害に対処する場合や定期的な保守を実施する場合に、管理者はJMSサーバーとそのすべての宛先をクラスタ内の別のWebLogic Serverに移行することも可能です。これには、予定されている手動移行のほかに自動移行も含まれます。JMSサービスの移行の詳細は、「JMS関連サービスの移行」を参照してください。
サーバーまたはネットワークの障害が発生した場合、JMSメッセージ・プロデューサ・オブジェクトとコンシューマ・オブジェクトは、別のサーバー・インスタンスに透過的にフェイルオーバーを試みます(使用可能なものがある場合)。WebLogic Serverリリース9.1以降では、既存のクライアント・コードを手動で構成または変更しなくても、WebLogic JMSメッセージ・プロデューサは、使用可能なサーバー・インスタンスへ自動的に再接続しようとします。WebLogic Serverリリース9.2以降では、WebLogic Server管理コンソールまたはWebLogic JMS APIを利用して、使用可能なサーバー・インスタンスに自動的に再接続を試行するようにWebLogic JMSメッセージ・コンシューマを構成できます。『Oracle WebLogic Serverアプリケーションの開発』のJMSクライアントの自動フェイルオーバーに関する項を参照してください。
注意:
WebLogic Server 9.x以前のJMSクライアント・アプリケーションについては、『Oracle WebLogic Server JMSアプリケーションの開発』のWebLogic Server 9.x以前のリリースでの障害に関するプログラミングの考慮事項に関する項を参照してください。
さらに、サービスの自動移行機能を実装すると、JMSのような「必ず1回」のサービスによって、クラスタ内の依存するアプリケーションに対するシングル・ポイント障害が発生しなくなります。動的クラスタをターゲットとして指定されたJMSサーバーのフェイルオーバーでは、フェイルバックおよび再起動インプレース機能を利用できます。「JMS関連サービスの移行」を参照してくださいWebLogic Serverでは、サーバー・レベルの移行、つまり、サーバー・インスタンス全体の移行もサポートされています。また、サーバー・インスタンスがホストするすべてのサービスを自動または手動で別のマシンに移行できます。『Oracle WebLogic Serverクラスタの管理』のサーバー全体の移行に関する項を参照してください。
クラスタ化環境では、WebLogic Serverは分散宛先を構成することによって1つのサーバーで障害が発生した場合でもサービスを継続できます。分散宛先では、キューおよびトピック・メンバーは通常、クラスタ内の複数のサーバーに分散され、各メンバーは個々のJMSサーバーに属します。「クラスタ内での分散宛先」を参照してください
また、高可用性クラスタリング・ソフトウェアを実装することをお薦めします。これにより、WebLogic Serverベースのアプリケーションに、統合された使いやすいソリューションがもたらされます。
JMS関連サービスはシングルトン・サービスであるため、クラスタ内のすべてのサーバー・インスタンスでアクティブになるわけではありません。かわりに、サービスがクラスタ内の単一サーバーに固定され、データの一貫性を保持します。シングルトンJMSサービスが原因で、クラスタ内の依存するアプリケーションに対するシングル・ポイント障害が発生しないようにするため、クラスタをターゲットとして指定されたJMSを使用して、JMS関連サービスを高可用性用に構成できます。詳細は、「簡略化されたJMS構成と高可用性の拡張機能」を参照してください。また、定期的なサーバー・メンテナンスを実施する前に、JMSサービスを手動で移行することも可能です。
移行可能なJMS関連サービスには以下が含まれます:
JMSサーバー: ターゲット指定されているJMSモジュール内のキューおよびトピックの管理コンテナです。「JMSサーバーの構成」を参照してください
ストア・アンド・フォワード(SAF)サービス: メッセージが送信された時点でリモート・エンドポイントが使用できない場合でも、ローカルの送信エンドポイントとリモートの受信エンドポイントの間でメッセージをストア・アンド・フォワードするサービスです。JMS SAF(送信機能のみ)用に構成された送信SAFエージェントのみを移行できます。『Oracle WebLogic Serverストア・アンド・フォワード・サービスの管理』のストア・アンド・フォワード・サービスの理解に関する項を参照してください。
パス・サービス: JMSメッセージ順序単位内のメッセージのグループからクラスタ内のメッセージ・リソースへのマッピングの保持に使用できる永続マップです。パス・サービスは、クラスタごとに1つずつ構成します。「WebLogicパス・サービスの使用」を参照してください
カスタム永続ストア: ユーザーが定義するディスク・ベースのファイル・ストアまたはJDBC対応データベースです。JMSメッセージやストア・アンド・フォワード・メッセージなどのサブシステム・データを格納するために使用します。『Oracle WebLogic Serverサーバー環境の管理』のWebLogic永続ストアの使用方法に関する項を参照してください。
『Oracle WebLogic Serverクラスタの管理』のサービスの移行フレームワークの理解に関する項を参照してください。
管理者は、ヘルス監視サブシステムを活用することで、障害が発生した現在のホスト・サーバーでホストされているJMSサービスが正常に動作しているサーバーに自動的に移行するよう、移行可能ターゲットを構成できます。JMS関連サービスの自動移行の構成の詳細は、『Oracle WebLogic Serverクラスタの管理』のJMS関連サービスの自動移行を構成するためのロードマップに関する項を参照してください。
ホスト・サーバーで障害が発生した場合や、サーバー・メンテナンスを実施する前には、JMS関連サービスを正常なサーバーに手動で移行できます。JMS関連サービスの手動移行の構成の詳細は、『Oracle WebLogic Serverクラスタの管理』のJMS関連サービスの手動移行を構成するためのロードマップに関する項を参照してください。
「フェイルオーバーの場合」で説明されているように、カスタム永続ストアを含むJMSサービスは、「サーバー全体」の移行機能の一部として移行したり、移行可能なJMS関連サービスをターゲットとした「サービス・レベル」の移行の一部として移行できます。移行可能なJMS関連サービスで、デフォルトの永続ファイル・ストアを使用することはできないので、カスタム・ファイル・ストアまたはJDBCストアを構成し、そのストアと関連付けられたJMSサーバーまたはSAFエージェントと同じ移行可能ターゲットにそのストアをターゲット指定する必要があります。(パス・サービスの場合は、専用のカスタム・ストアと移行可能ターゲットを使用するのがベスト・プラクティスです。)
移行可能なカスタム・ファイル・ストアは、クラスタ内の移行可能ターゲット・サーバーから使用できる共有ディスクに構成したり、移行前/移行後スクリプトを使用してバックアップ・サーバー・ターゲットに移行したりできます。永続ストアの移行の詳細は、『Oracle WebLogic Serverクラスタの管理』のJMSサービスで使用できるカスタム・ストアに関する項を参照してください。
WebLogic Serverパス・サービスは、JMSメッセージ順序単位内のメッセージのグループから、クラスタ内のメッセージ・リソースへの、マッピングの保持に使用できる永続マップです。パス・サービスは、サーブレットをホストするクラスタのメンバー、分散キュー・メンバー、またはストア・アンド・フォワード・エージェントにメッセージを固定することによって、順序付けを実現します。パス・サービスは、クラスタごとに1つずつ構成します。メッセージ順序単位機能の詳細は、『Oracle WebLogic Server JMSアプリケーションの開発』のメッセージ順序単位の使用に関する項を参照してください。
クラスタにパス・サービスを構成する方法については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのパス・サービスの構成に関する項を参照してください。
パス・サービスで高可用性を達成するには、様々な方法があります。
サーバー全体の移行を使用して、パス・サービスが実行されるWebLogic Serverを再起動できます。『Oracle Fusion Middlewareクラスタの管理』を参照してください。『Oracle WebLogic Serverクラスタの管理』のサーバー全体の移行に関する項を参照してください。
自動サービス移行を設定して、パス・サービス・ストアを構成できます。パス・サービスは、シングルトン分散ポリシーを使用して、クラスタをターゲットにしたストアを使用できます。詳細は、「簡略化されたJMSクラスタと高可用性の構成」を参照してください
パス・サービスとそのストアを構成して、移行可能なターゲットを使用できます。ただし、移行可能なパス・サービスではデフォルト・ストアを使用できないため、カスタム・ストアを構成し、同じ移行可能ターゲットにターゲット指定する必要があります。さらに、ベスト・プラクティスとしては、その移行可能ターゲットのユーザーを、パス・サービスとそのカスタム・ストアに限定する必要があります。『Oracle WebLogic Serverクラスタの管理』のサービスの移行フレームワークの理解に関する項を参照してください。
メッセージ順序単位とパス・サービス・ベースのルーティングを実装する際には、次の点に留意してください。
各パス・サービス・マッピングは永続ストアに格納されます。パス・サービスを構成する場合、高可用性ソリューションを使用する永続ストアを選択します。「永続ストアの高可用性」を参照してください
複数のプロデューサが同じ順序単位名を使用してメッセージを送信する場合、すべてのメッセージは同じパス・エントリを共有し、同じメンバー・キュー宛先を持ちます。
順序単位名に必要なルートにアクセスできない場合、メッセージを送信したプロデューサはJMSOrderExceptionを送出します。この例外がスローされるのは、JMSメッセージ・システムが必要なサービス品質を満たすことができないからです。特定の順序単位名に対しては、1つの分散宛先メンバーのみがメッセージを消費できます。
パス・エントリは、最後のプロデューサと最後のメッセージ参照が削除されたときに自動的に削除されます。
システムによっては、パス・サービスを使用するとシステムのスループットが低下する場合があります。これは、パス・エントリを作成、読み取り、および削除するためのリモート・ディスク処理が原因で起こります。
分散キューとその個々のメンバーは、一意の宛先を表します。例:
DXQ1は、Q1とQ2というメンバーを持つ分散キューです。またDXQ1はFredという名前の順序単位を持ち、パス・サービスによってQ2メンバーにマップされています。
メッセージM1がDXQ1に送信されると、パス・サービスによってQ2へのルートが定義されます。
メッセージM1が直接Q2に送信されると、パス・サービスによるルーティングは行われません。これは、アプリケーションが直接Q2を選択し、分散宛先からメンバーを選択するよう要求されなかったからです。
パス・サービスを使用する場合は、メッセージを分散宛先に送信します。使用しない場合は、直接メンバーに送信します。
ある分散キューの中に、同じ順序単位名の宛先が複数存在してもかまわません。例:
Fredという順序単位名のキューQ3が存在するとします。Q3がDXQ1に追加された場合は、分散キューの中に同じ順序単位名の宛先が2つ存在することになります。Q3とDXQ1は同じ順序単位名Fredを共有しますが、それぞれが一意のルートと宛先を持っており、これによりサーバーは宛先ごとに適切なメッセージ順序付けを提供し続けることができます。
分散キューからキューを削除する前や、分散キューにキューを追加する前には、キューを空にします。削除されたメンバーのパス・エントリはパス・サービスによって削除されますが、短い遷移期間が発生します。ここでは、キューが削除されているのにパス・エントリがまだ存在する場合に、生成されたメッセージによって例外JMSOrderExceptionがスローされる場合があります。
WebLogic JMSでは、サード・パーティJMSプロバイダをローカルWebLogic Server JNDIツリー内で参照できます。JMSモジュール内で外部サーバー・リソースを使用することで、外部のJMSプロバイダを即座にマップして、関連付けられた接続ファクトリと宛先をローカルJMSオブジェクトのようにWebLogic JNDIツリーに表示できます。また、別のクラスタまたはドメインにあるWebLogic Serverのリモート・インスタンスをローカルWebLogic JNDIツリー内で参照することもできます。
リモートおよび外部JMSプロバイダの統合の詳細は、『Oracle WebLogic Server JMSアプリケーションの開発』のEJBとサーブレットにWebLogic JMSを使用するための拡張2EEサポートに関する項を参照してください。
以下の節では、外部サーバーの機能と、リモートMQSeries JNDIプロバイダにアクセスするためのサンプル構成について説明します。
外部JMSサーバーがデプロイされると、WebLogic Server JNDIにローカルの接続ファクトリと宛先のオブジェクトが作成されます。外部接続ファクトリまたは宛先のオブジェクトがローカル・サーバーでルックアップされると、そのオブジェクトはリモートJNDIディレクトリで実際のルックアップを実行し、そのディレクトリから外部オブジェクトが返されます。
この方法を使用すると、複数のWebLogicメッセージング・ブリッジ送り先の構成が簡単になります。外部サーバーが、JNDI初期コンテキスト・ファクトリおよび接続URLの構成の詳細をメッセージング・ブリッジ送り先の構成の外側に移すからです。外部接続ファクトリおよび宛先JNDI名をオブジェクトごとに指定するだけで済みます。
メッセージング・ブリッジの構成の詳細は、『Oracle WebLogic Server WebLogicメッセージング・ブリッジの管理』を参照してください。
また、この構成の簡素化は、WebLogic JMSでのWebLogicサーブレット、EJB、およびメッセージドリブンBean (MDB)の構成にも当てはまります。たとえば、MDBのweblogic-ejb-jar.xmlファイルではローカルJNDI名を指定でき、外部JMSサーバーを使用してMDBがメッセージを受け取る場所を制御できます。具体的には、あるJMS宛先およびサーバーと通信するためにある環境でMDBをデプロイし、同じweblogic-ejb-jar.xmlファイルを別のサーバーにデプロイして、それを別のJMS宛先と通信させることができます。その際、weblogic-ejb-jar.xmlファイルを復元して編集する必要はありません。
外部サーバーには、ローカルWebLogic ServerインスタンスがリモートJNDIプロバイダにアクセスするための情報が保持されています。外部サーバーには、ローカルWebLogic ServerインスタンスがリモートJNDIプロバイダにアクセスするための情報が保持されています。これにより、1つのJNDIディレクトリに対して複数の外部接続ファクトリと宛先のオブジェクトを定義できます。
WebLogic Server管理コンソールを使用すると、システム・モジュール内の外部サーバー・リソースを構成、変更、ターゲット指定、および削除できます。外部サーバーのタスクの手順については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの外部サーバーの構成に関する項を参照してください。
注意:
エンタープライズ・アプリケーション内でのJMSアプリケーション・モジュールの構成およびデプロイについては、「JMSアプリケーション・モジュールのデプロイメントの構成」を参照してください。
一部の外部サーバー・オプションは、動的に構成できます。オプションが実行時に変更された場合、変更は新しく配信されるメッセージにのみ適用され、格納されているメッセージには影響しません。すべての外部サーバー・オプションのデフォルト値にの詳細は、Oracle WebLogic Server MBeanリファレンスのForeignServerBeanに関する項を参照してください。
外部サーバーを定義したら、接続ファクトリおよび宛先のオブジェクトを構成できます。各外部サーバーに対して、1つまたは複数の接続ファクトリおよび宛先(キューまたはトピック)を構成できます。
JMSモジュール内の外部接続ファクトリ・リソースには、リモートJNDIプロバイダの接続ファクトリのJNDI名、ローカルWebLogic Server JNDIツリー内でその接続ファクトリにマップされるJNDI名、およびユーザー名とパスワード(オプション)が定義されます。
外部接続ファクトリは、親の外部サーバーの割当て先となる各WebLogic Serverインスタンスに対してレプリケートされていないJNDIオブジェクトを作成します(クラスタ内の各ノードにJNDIオブジェクトを作成するには、クラスタに外部サーバーを割り当てます)。
表4-1に、リモートMQSeries JNDIプロバイダにアクセスする場合のサンプル構成を示します。
表4-1 MQSeriesサンプル構成
| 外部JMSオブジェクト | オプション名 | サンプル構成データ |
|---|---|---|
外部サーバー |
名前 JNDI初期コンテキスト・ファクトリ JNDI接続URL JNDIプロパティ |
MQJNDI com.sun.jndi.fscontext.RefFSContextFactory ファイル:/MQJNDI/ (必要な場合、カンマ区切りのname=valueプロパティ・リストを入力します)。 |
外部 接続ファクトリ |
名前 ローカルJNDI名 リモートJNDI名 ユーザー名 パスワード |
MQ_QCF mqseries.QCF QCF weblogic_jms weblogic_jms |
外部 宛先1 外部 宛先2 |
名前 ローカルJNDI名 リモートJNDI名 名前 ローカルJNDI名 リモートJNDI名 |
MQ_QUEUE1 mqseries.QUEUE1 QUEUE_1 MQ_QUEUE2 mqseries.QUEUE2 QUEUE_2 |
JMSモジュール内の分散宛先リソースは、単一の論理宛先としてクライアントからアクセス可能な1つの宛先セット(キューまたはトピック)です(たとえば分散トピックは独自のJNDI名を持ちます)。このセットのメンバーは通常、クラスタ内の複数のサーバーに分散されており、各メンバーは別々のJMSサーバーに属しています。分散宛先を使用するアプリケーションは、スタンドアロンの宛先を使用するアプリケーションより可用性が高くなります。これは、WebLogic JMSに、クラスタ内の分散宛先メンバーのためのロード・バランシングおよびフェイルオーバー機能があるためです。
以降の節では、分散宛先の作成、モニター、およびロード・バランシングを行う方法について説明します。
注意:
重み設定された分散宛先は、WebLogic Server 10.3.4.0では非推奨です。共通分散宛先を使用することをお薦めします。
WebLogic Server 9.x以降には、共通分散宛先と重み設定された分散宛先という2種類の分散宛先が用意されています。WebLogic Server 9.xより前のリリースでは、WebLogic管理者が、物理宛先を分散宛先のメンバーとして機能するように手動で頻繁に構成する必要がありました。この方法は、追加のメッセージ負荷または容量に対応するメンバーを作成できるという柔軟性を備えていました。しかし、このような重み設定された分散宛先はクラスタ内で一貫してデプロイされなかったため、管理上およびアプリケーション上の問題が発生することもよくありました。このタイプの分散宛先は、公式には「重み設定された分散宛先」(WDD)と呼ばれます。
共通分散宛先(UDD)は、分散宛先アプリケーションの管理と開発を大幅に簡略化します。共通分散宛先を使用すると、送り先のメンバーを作成したり指定する必要がなくなりますが、かわりにWebLogic Serverを使用して、必要なメンバーをJMSモジュールの対象となるJMSサーバー上に均等に作成することもできます。この機能によって、重み、セキュリティ、永続性、ページング、割り当てなどに関する分散宛先パラメータのすべてを一貫して構成できます。
分散宛先メンバーを手動で調整する場合は、従来の重み設定された分散宛先の機能も依然として使用できます。ただし、クラスタ内で一貫してデプロイされていない重み設定された分散宛先に起因して起こり得る管理上およびアプリケーションの問題を回避するため、共通分散宛先を構成することをお薦めします。
アプリケーションでの分散宛先の使用の詳細は、『Oracle WebLogic Server JMSアプリケーションの開発』の分散宛先の使用に関する項を参照してください。
WebLogic Server管理コンソールを使用すると、次のJMSシステム・モジュールのUDDリソースを構成、変更、ターゲット指定および削除できます。
注意:
UDDリソースをオプションのHA構成設定でホスティングするために、単一クラスタをターゲットとして指定されたJMSサーバーと、関連付けられた永続ストアを作成しておくことをお薦めします。これはUDD構成をシンプル、スケーラブルにし、可用性を高めます。「簡略化されたJMSクラスタと高可用性の構成」を参照してくださいレプリケートされた分散トピックは、クラスタをターゲットとして指定されたJMSサーバーによってサポートされません。
共通分散宛先のタスクの手順については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの次のトピックを参照してください。
共通分散宛先オプションの中には、動的に構成できるものもあります。オプションが実行時に変更された場合、変更は新しく配信されるメッセージにのみ適用され、格納されているメッセージには影響しません。すべての共通分散宛先オプションのデフォルト値については、Oracle WebLogic Server MBeanリファレンスの次の項目を参照してください。
注意:
エンタープライズ・アプリケーション内でのJMSアプリケーション・モジュールの構成およびデプロイについては、「JMSアプリケーション・モジュールのデプロイメントの構成」を参照してください。次の項では、共通分散宛先の追加情報を説明します。
ドメイン内の特定のJMSサーバーのみをターゲットとして指定できる、モジュール内のスタンドアロンのキューおよびトピック・リソースとは異なり、UDDは1つまたは複数のJMSサーバー、1つまたは複数のWebLogic Serverインスタンス、または1つのクラスタをターゲットとして指定できます。UDDの目的は、そのメンバーをドメイン内の各JMSサーバーに分散することだからです。たとえば、クラスタをUDDのターゲットとして指定した場合、そのクラスタ内の各JMSサーバーでメンバーが均等に構成されます。
注意:
UDDのターゲットとして、単一クラスタをターゲットとして指定されたJMSサーバーを指定することをお薦めします。
UDDのターゲットを変更すると、メンバー宛先が削除され、メッセージが失われてしまうおそれがあります。
また、UDDを構成するときにサブデプロイメント・グループを使用して、特定のリソースを分散メンバーにリンクできます。たとえば、jmssysmod-jms.xmlというシステム・モジュールが、構成済みのJMSサーバーを持つwlserver1、wlserver2、wlserver3という3つのWebLogic Serverインスタンスのターゲットとして指定されている場合に、1つの共通分散キューと接続ファクトリを各サーバー・インスタンスのターゲットとして指定するのであれば、共通分散キューと接続ファクトリをservergroupという名前の1つのサブデプロイメント内でグループ化して、これらのリソースが常にこれらのサーバー・インスタンスにリンクされるようにすることができます。
次に、サブデプロイメント・リソースservergroupをjmssysmod-jms.xmlでどのように指定するのかを示します。
<weblogic-jms xmlns="http://xmlns.oracle.com/weblogic/weblogic-jms">
<connection-factory name="connfactory">
<sub-deployment-name>servergroup</sub-deployment-name>
<jndi-name>jms.connectionfactory.CF</jndi-name>
</connection-factory>
<uniform-distributed-queue name="UniformDistributedQueue">
<sub-deployment-name>servergroup</sub-deployment-name>
<jndi-name>jms.queue.UDQ</jndi-name>
<forward-delay>10</forward-delay>
</uniform-distributed-queue>
</weblogic-jms>
次に、ドメインの構成ファイルでサブデプロイメントservergroupをどのようにターゲット指定するかを示します。
<jms-system-resource>
<name>jmssysmod-jms</name>
<target>cluster1,</target>
<sub-deployment>
<name>servergroup</name>
<target>wlserver1,wlserver2,wlserver3</target>
</sub-deployment>
<descriptor-file-name>jms/jmssysmod-jms.xml</descriptor-file-name>
</jms-system-resource>
共通分散宛先でのメッセージの生成、挿入、および消費処理は、プログラム的に(JMXと実行時MBean APIを使用)、または管理的に(WebLogic Server管理コンソールを使用)休止および再開できます。外部リソースに障害が発生したとき、JMSサブシステムがメッセージの受け付けと配信(および再配信)を継続すると、システムに過度の負荷がかかることがあります。しかし、メッセージ処理を休止(および再開)することで、外部リソースの障害発生時のJMSサブシステムの動作を制御できます。
「休止と再開」の機能の詳細は、「宛先でのメッセージ処理の制御」を参照してください
共通分散トピック・メッセージのForwarding Policyは、送信済メッセージがすべてのメンバーに転送されるかどうかを指定します。
有効な値は以下のとおりです。
Replicated: デフォルトです。すべての物理トピック・メンバーは各送信済メッセージを受信します。メッセージが物理トピック・メンバーのいずれかに着信する場合、該当する共通分散トピックの他のメンバーにこのメッセージのコピーが転送されます。いずれかの特定のメンバー上のサブスクリプションは、共通分散トピックの論理名または特定の共通分散トピック・メンバーに送信されたメッセージのコピーを取得します。
Partitioned: メッセージ受信側の物理メンバーは、メッセージを認識する共通分散トピックの唯一のメンバーです。メッセージがパーティション化された共通分散トピックの論理名にパブリッシュされるとき、特定の1つの物理トピック・メンバー上にのみ着信します。メッセージが物理トピック・メンバー上に着信すると、メッセージは共通分散宛先の残りのメンバーには転送されず、他の物理トピック・メンバー上のサブスクライバは当該メッセージのコピーを取得しません。
大半の新しいアプリケーションでは、次のように構成される共通分散トピック上の論理サブスクリプション・トポロジと組み合せて、Partitioned転送ポリシーを使用します。
各物理メンバー上で直接作成された同一名の物理サブスクリプション。
UnrestrictedのクライアントIDポリシー。
Sharableのサブスクリプション共有ポリシー。
パーティション化された分散トピックの作成および使用の詳細は、次を参照してください。
Oracle WebLogic Server管理コンソール・オンライン・ヘルプのシステム・モジュールにおけるパーティション化された共通分散トピックの作成に関する項
『Oracle WebLogic ServerメッセージドリブンBeanの開発』の分散トピックを使用したMDBの構成およびデプロイに関する項
『Oracle WebLogic Server JMSアプリケーションの開発』の高度なPub/Subアプリケーションの開発に関する項
パーティション化されたトピックのパブリッシャには、接続ファクトリのAffinityおよびLoad Balance属性をチューニングすることによって、複数のメンバー全体に渡るメッセージのロード・バランシング・オプションがあります。「順序単位」メッセージは、UOOルーティング・ポリシーおよびサブスクライバ・ステータスに基づいて適切なメンバーにルーティングされます。Oracle WebLogic Server管理コンソール・オンライン・ヘルプの接続ファクトリのロード・バランシング・パラメータの構成に関する項を参照してください。
注意:
重み設定された分散宛先(WDD)は、WebLogic Server 10.3.4.0では非推奨です。共通分散宛先を使用することをお薦めします。
WebLogic Server管理コンソールを使用すると、JMSシステム・モジュール内のWDDリソースを構成、変更、ターゲット指定、および削除できます。分散トピックまたはキューを構成する場合、「メンバーの均等割当て」チェック・ボックスのチェックを外すことによって、既存のキューとトピックを手動で選択して分散宛先に追加し、分散宛先メンバーの重みを調整できます。
重み設定された分散宛先のタスクの手順については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの次のトピックを参照してください。
重み設定された分散宛先のオプションには、動的に構成できるものもあります。オプションが実行時に変更された場合、変更は新しく配信されるメッセージにのみ適用され、格納されているメッセージには影響しません。重み設定された分散宛先の、すべてのオプションのデフォルト値の詳細は、Oracle WebLogic Server MBeanリファレンスの次の項目を参照してください。
UDDとは異なり、WDDメンバーはWebLogic Server管理コンソールまたは実行時MBeanでモニターできません。また、WDDメンバーはドメイン内のJMSサーバーまたはWebLogic Serverインスタンスに均等に割り当てることはできません。かわりに、これらのインスタンス上で新しいWDDメンバーを手動で構成し、手動でWDDに追加する必要があります。
JMSは分散宛先を使用して、複数の宛先にメッセージの負荷を分散し、バランスを取ることができます。これによって、リソースがさらに効率的に利用され、レスポンス時間が改善されます。JMSのロード・バランシング・アルゴリズムでは、メッセージの送信先となる物理宛先に加えて、コンシューマの割当て先の物理宛先も決定されます。
WebLogic JMSは、任意の分散宛先セットに含まれている複数の物理宛先間でメッセージのロード・バランシングを行うための2種類のアルゴリズムをサポートしています。これらのロード・バランシング・オプションのどちらかを選択するには、WebLogic Server管理コンソールで分散トピックまたは分散キューを構成します。
ラウンドロビン・アルゴリズムでは、WebLogic JMSは分散宛先内の物理宛先の順序を管理します。メッセージの負荷は、WebLogic Server構成(config.xml)ファイルに定義されている順番で、一度に1つずつ物理宛先に分散されます。各WebLogic Serverは同一の順序を維持しますが、その順序内の位置は異なります。特定の分散宛先を使用して単一のサーバー内で複数のスレッドを実行すると、スレッドからメッセージが生成されるたびに、メンバーが割り当てられている物理宛先に関連して、これらのスレッドが互いに影響し合うことになります。ラウンドロビンはデフォルトのアルゴリズムで、構成の必要はありません。
重み設定された分散宛先のみの場合、セット内の物理宛先のいずれかに重みが割り当てられている場合、それらの物理宛先は順序内に複数回発生します。
ランダム分散アルゴリズムでは、物理宛先に割り当てられている重みを使用して、一連の物理宛先の重み付き宛先を計算します。メッセージの負荷は、疑似ランダム的に宛先にアクセスすることで、物理宛先に分散されます。短期的には、負荷は重みには直接比例しません。長期的には、極限に近い分散が行われます。純粋なランダム分散は、重みすべてに同じ値を設定することで達成できます。この値は通常1です。
メンバーが追加または削除された(管理者が行うか、WebLogic Serverがシャットダウンまたは再起動した結果発生したもの)場合は、分散を再計算する必要があります。ただし、このようなイベントは頻繁に発生せず、計算は通常単純で、O(n)時間で実行されます。
アプリケーションがコンシューマを作成するときは、宛先を指定する必要があります。その宛先が分散宛先を表す場合、WebLogic JMSではコンシューマのメッセージの受信元になる物理宛先を見つける必要があります。使用する宛先メンバーの選択には、ロード・バランシング・アルゴリズム(「ロード・バランシングのオプション」を参照)のいずれかが使用されます。この選択は、コンシューマの作成時に1度だけ行われます。その後、コンシューマはそのメンバーのみからメッセージを受信するようになります。
プロデューサがメッセージを送信するとき、WebLogic JMSはメッセージが送信される宛先を確認します。宛先が分散宛先である場合は、メッセージの送信先がWebLogic JMSによって決定されます。つまり、プロデューサは「ロード・バランシングのオプション」で説明されているロード・バランシングのアルゴリズムのいずれかに従って、宛先のメンバーのいずれかに送信します。
プロデューサはメッセージを送信するたびにこのような決定を行います。ただし、コンシューマとプロデューサ間の序列の保証が脅かされることはありません。コンシューマのロード・バランシングがいったん行われると、コンシューマは単一の宛先メンバーに固定されるためです。
注意:
プロデューサが永続メッセージを分散宛先に送信しようとする場合、永続ストアを利用している分散メンバーにまずメッセージが転送されるよう、あらゆる努力がなされます。ただし、分散メンバーがいずれも永続ストアを利用していない場合でも、メッセージは選択されているロード・バランシング・アルゴリズムに従って、メンバーのいずれかに送信されます。
「ロード・バランシングのオプション」に説明されているアルゴリズムに加えて、WebLogic JMSでは、宛先のインスタンスを選択するときに次のヒューリスティックが使用されます。
トランザクション・セッション内で複数のメッセージを作成するときは、作成されたメッセージすべてを同じWebLogic Serverに送信しようとします。つまり、セッションが単一の分散宛先に複数のメッセージを送信した場合は、すべてのメッセージが同じ物理宛先に転送されます。セッションによって複数のメッセージが複数の異なる分散宛先に送信された場合は、同じWebLogic Serverがサービスを提供する一連の物理宛先が選択されるようになります。
接続ファクトリの「サーバー・アフィニティの有効化」パラメータでは、分散宛先内にある複数のメンバー宛先の間でコンシューマまたはプロデューサをロード・バランシングしているWebLogic Serverが、同じWebLogic Server上で実行されている他のローカル宛先メンバーの間でロード・バランシングを最初に試みるかどうかを定義します。
注意:
「サーバー・アフィニティの有効化」属性は、キュー・ブラウザには影響しません。したがって、「サーバー・アフィニティの有効化」が有効になっている場合でも、分散キューに作成されたキュー・ブラウザをリモート分散キュー・メンバーに固定できます。
接続ファクトリでサーバー・アフィニティを無効化するには:
Oracle WebLogic Server管理コンソール・オンライン・ヘルプの接続ファクトリのロード・バランシング・パラメータの構成に関する項の説明に従って、「JMS接続ファクトリ」→「構成」→「全般」ページに移動します。
「サーバー・アフィニティの有効化」フィールドを次のように定義します。
「サーバー・アフィニティの有効化」チェック・ボックスを選択します(trueとします)。この場合、分散宛先セット内にある複数の物理宛先の間でコンシューマまたはプロデューサをロード・バランシングしているWebLogic Serverは、同じWebLogic Server上で実行されている他の物理宛先の間でロード・バランシングを最初に試みます。
「サーバー・アフィニティの有効化」チェック・ボックスを選択しない場合(False)、WebLogic Serverは、分散宛先セット内の複数の物理宛先にまたがるコンシューマまたはプロデューサのロード・バランシングを実行し、同じWebLogic Serverで実行されている他の物理宛先を無視します。
「保存」をクリックします。
「サーバー・アフィニティの有効化」の設定が分散宛先のメンバー間のロード・バランシングにどのように影響するかについては、「サーバー・アフィニティを有効化した場合の分散宛先ロード・バランシングへの影響」を参照してください
複数のリモートの物理的キュー間でコンシューマのロード・バランシングを行う場合、1つまたは複数のキューにコンシューマがないとき、それらのキューだけがロード・バランシングの対象となります。セット内の物理的キューすべてに少なくとも1つのコンシューマが含まれるようになると、標準のアルゴリズムが適用されます。
また、プロデューサがメッセージを送信するとき、コンシューマのないキューはメッセージ生成の対象にはなりません。ただし、任意のキューのインスタンスのいずれにもコンシューマが含まれていない場合を除きます。
分散宛先でメッセージの生成または挿入が休止された場合、それらはメッセージ生成の対象とは見なされません。同様に、分散宛先でメッセージの消費が休止された場合、それらはメッセージ生成の対象とは見なされません。
宛先でのメッセージ処理の休止については、「宛先でのメッセージ処理の制御」を参照してください
アプリケーションは、個別の物理宛先に直接アクセスすることで、ロード・バランシングを回避できます。つまり、物理宛先にJNDI名がない場合でも、createQueue()メソッドまたはcreateTopic()メソッドを使用して参照することができます。
共通分散宛先や重み設定された分散宛先のメンバーに直接アクセスする方法については、『Oracle WebLogic Server JMSアプリケーションの開発』の分散宛先メンバーへのアクセスに関する項を参照してください。
アプリケーションにおいて、分散宛先を使用して、複数の物理宛先間でプロデューサやコンシューマを分散、つまりバランスさせることは行っても、メッセージが作成されるたびにロード・バランシングの決定を行いたくない場合は、「ロード・バランシングの有効化」パラメータを無効化した状態で接続ファクトリを使用します。分散宛先においてメッセージの負荷が適正に分散されるようにするには、プロデューサによって使用される初期の物理宛先(キューまたはトピック)が、物理宛先メンバーによって常にランダムに選択される必要があります。
接続ファクトリでのロード・バランシングを無効化するには:
Oracle WebLogic Server管理コンソール・オンライン・ヘルプの接続ファクトリのロード・バランシング・パラメータの構成に関する項の説明に従って、「JMS接続ファクトリ」→「構成」→「全般」ページに移動します。
次のガイドラインに従って、「ロード・バランシングの有効化」フィールドを設定します。
ロード・バランシングを有効化 = True
Queue.sender.send()メソッドでは、分散キュー・メンバー間での呼出しごとに、匿名でないプロデューサがロード・バランシングされます。
TopicPublish.publish()メソッドでは、「ロード・バランシングの有効化」設定に関係なく、匿名でないプロデューサが呼出しごとに常に同じ物理的なトピックに固定されます。
ロード・バランシングを有効化 = False
プロデューサは失敗するまで常に同じ物理宛先に対して生成します。失敗すると、新しい物理宛先が選択されます。
「保存」をクリックします。
注意:
実装によっては、「サーバー・アフィニティの有効化」属性の設定が分散宛先のロード・バランシングのプリファレンスに影響することがあります。詳細は、「サーバー・アフィニティを有効化した場合の分散宛先ロード・バランシングへの影響」を参照してください
匿名プロデューサ(作成時に宛先を指定しないプロデューサ)は、宛先を切り替えるたびにロード・バランシングされます。同じ宛先を使用し続けると、匿名でないプロデューサと同じ法則(前述)が適用されます。
表4-2では、接続ファクトリの「サーバー・アフィニティの有効化」パラメータの設定が、分散宛先メンバーのロード・バランシングのプリファレンスに与える影響について説明します。プリファレンス順位は、操作のタイプ、および恒久サブスクリプションまたは永続メッセージが含まれているかどうかによって異なります。
分散宛先の「サーバー・アフィニティを有効化」パラメータは、ClusterMBeanの「デフォルトのロード・バランス・アルゴリズム」属性によって提供されるサーバー・アフィニティとは異なります。後者は、JMS接続ファクトリでクライアント接続用の初期コンテキスト・アフィニティを作成するためにも使用されます。
詳細は、『Oracle WebLogic Serverクラスタの管理』のEJBとRMIオブジェクトのロード・バランシングに関する項とクライアント接続の初期コンテキスト・アフィニティとサーバー・アフィニティに関する項を参照してください。
表4-2 サーバー・アフィニティのロード・バランシングのプリファレンス
| 操作 | 「サーバー・アフィニティを有効化」の設定 | ロード・バランシングのプリファレンス |
|---|---|---|
|
True |
|
キューの |
False |
|
トピックの (注意: 非永続サブスクライバ) |
trueまたはfalse |
|
|
trueまたはfalse |
作成されたJMSプロデューサのロード・バランシング用の、独立した機能は存在しません。JMSプロデューサは、JMS接続のロード・バランシングまたは固定が行われるサーバーで作成されます。 接続ファクトリを使用して作成されたJMS接続のロード・バランシングの詳細は、『Oracle WebLogic Serverクラスタの管理』のEJBとRMIオブジェクトのロード・バランシングに関する項とクライアント接続の初期コンテキスト・アフィニティとサーバー・アフィニティに関する項を参照してください。 |
|
True |
|
|
False |
|
|
True |
|
非永続メッセージの場合:
|
False |
|
セッション・プール・キューおよびトピックの |
trueまたはfalse |
ローカル・メンバーのみ 注意: セッション・プールは現在ほとんど使用されていません。理由は、Java EE仕様の必須の部分ではないこと、JTAユーザー・トランザクションをサポートしていないこと、そして大部分がメッセージドリブンBean (MDB)に取ってかわられたことです。MDBの方が簡単で管理しやすく、高機能です。 |
サービス移行機能を利用するクラスタ化されたJMS実装では、JMSサーバーとその分散宛先メンバーを、クラスタ内の別のWebLogic Serverインスタンスに手動で移行できます。サービスの移行は、定期的なシステム保守の際や、クラスタ内のサーバーに障害が発生した際に実施できます。
ただし、移行先のWebLogic Serverに物理宛先すべてを持つJMSサーバーがすでにホストされている場合もあります。そのような場合には、同じWebLogic Serverインスタンスが単一の分散宛先について2つの物理宛先をホストするような状況が生じます。WebLogic Serverインスタンスでは、そのような分散宛先に対して複数の物理宛先をホストできるため、これは短期的に見れば許容できる状況です。ただし、こうした状況ではロード・バランシングの効率が低下します。
このような状況では、移行先のWebLogic Serverインスタンス上のJMSサーバーは独立して動作します。これは、2つの送り先インスタンスがマージされたり、両方の送り先で1つのインスタンスが無効化されることを回避するために必要です。このようなことが発生すると、メッセージが長時間使用できなくなる場合があります。ただし、長期的な目的は、移行されたJMSサーバーをクラスタ内のさらに別のWebLogic Serverインスタンスに最終的に再移行することにあります。
JMSの移行可能ターゲットの構成については、「JMS関連サービスの移行」を参照してください。
JMSプロデューサおよびJMSコンシューマのJMS接続をホストしているサーバー・インスタンスに障害が発生した場合、これらの接続を使用しているすべてのプロデューサとコンシューマは閉じられ、クラスタ内の別のサーバー・インスタンスで再作成されません。また、JMS宛先をホストしているサーバー・インスタンスに障害が発生した場合、その宛先のすべてのJMSコンシューマが閉じられ、クラスタ内の別のサーバー・インスタンスでは再作成されません。
キュー・プロデューサが作成された分散キュー・メンバーに障害が発生したが、プロデューサのJMS接続が存在するWebLogic Serverインスタンスがまだ実行されている場合、プロデューサはアクティブな状態を維持し、WebLogic JMSはロード・バランシングのオプションが有効になっているかどうかに関係なく、別の分散キュー・メンバーにフェイルオーバーします。
WebLogic Serverの障害から回復する手順については、『Oracle WebLogic Server JMSアプリケーションの開発』のサーバー障害からの回復に関する項を参照してください。
クライアントIDポリシーは、1つ以上のJMS接続がクラスタ内で同一のクライアントIDを使用できるかどうかを指定します。このポリシーの有効な値は次のとおりです。
RESTRICTED: これはデフォルトです。このポリシーを使用する接続で、特定のクライアントIDのクラスタ内に常時存在できるのは、1つのみです(所定のクライアントIDを使用した接続がすでに存在する場合、このポリシーを同じクライアントIDで使用して新しい接続を作成しようとしても、例外が発生して失敗します)。
UNRESTRICTED: このポリシーを使用して作成された接続は、他の制限/無制限接続がすでに同一クライアントIDを使用している場合でも、任意のクライアントIDを指定できます。恒久サブスクリプションが無制限クライアントIDを使用して作成されるとき、そのサブスクリプションはweblogic.jms.extensions.WLSession.unsubscribe(Topic topic, String name)を使用してのみクリーン・アップできます。『Oracle WebLogic Server JMSアプリケーションの開発』のサブスクリプションの管理に関する項を参照してください。
特にサブスクリプション(恒久/非恒久)を共有する場合は、新しいアプリケーションに対してクライアントIDポリシーをUnrestrictedを設定することをお薦めします(使用するアプリケーションのアーキテクチャに排他的クライアントIDが必要な場合を除く)。異なるクライアントIDポリシーを使用して作成されたサブスクリプションは、常に単独のサブスクリプションとして扱われます。Oracle WebLogic Server MBeanリファレンスのClientIdPolicyに関する項を参照してください。
WebLogicコンソールを使用した接続ファクトリ上でクライアントIDポリシーを設定する場合、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの同一クライアントIDを使用した複数接続の構成に関する項を参照してください。接続ファクトリ設定は、Oracle WebLogic Server Java APIリファレンスのWLConnectionインタフェースのsetClientIDPolicyメソッドを使用して、プログラム的にオーバーライドできます。
注意:
JMS接続ランタイム・オブジェクト上のクライアントIDポリシーのプログラムによる変更(オーバーライド)は、該当する特定の接続インスタンスおよび当該接続の存続期間中のみ有効です。接続ランタイム・オブジェクトへのいかなる変更も、基礎となるJMSモジュール記述子で定義される対応するJMS接続ファクトリ構成によって保存/反映されません。
クライアントIDポリシーを使用する方法の詳細は、次を参照してください。
Oracle WebLogic Server管理コンソール・オンライン・ヘルプの同一クライアントIDを使用した複数接続の構成に関する項
『Oracle WebLogic Server JMSアプリケーションの開発』の高度なPub/Subアプリケーションの開発に関する項
サブスクリプション共有ポリシーは、サブスクライバが同一接続上の他のサブスクライバとサブスクリプションを共有できるかどうかを指定します。このポリシーの有効な値は次のとおりです。
Exclusive: これはデフォルトです。この接続ファクトリを使用して作成されるすべてのサブスクライバは、サブスクリプションを他のサブスクリプションと共有できません。
Sharable: この接続ファクトリを使用して作成されたサブスクライバは、サブスクライバが同一の接続ファクトリまたは異なる接続ファクトリのどちらを使用して作成されたかに関係なく、サブスクリプションを他のサブスクライバと共有できるようになります。コンシューマは、同一のクライアントIDおよびクライアントIDポリシーを持つ場合にのみ非永続サブスクリプションを共有できます。また、同一のクライアントID、クライアントIDポリシー、およびサブスクリプション名を持つ場合にのみ永続スクリプトを共有できます。
WebLogic JMSアプリケーションは、javax.jms.Connectionインスタンスをweblogic.jms.extension.WLConnectionにキャストしてsetSubscriptionSharingPolicy(String)を呼び出すことによって、接続ファクトリ構成上で指定されるサブスクリプション共有ポリシーをオーバーライドできます。
サブスクリプション共有ポリシーを使用するアプリケーションのほとんどは、無制限クライアントIDポリシーを使用して、同一クライアントIDを使用する複数の接続が存続できようにします。
同一クライアントIDおよびサブスクリプション名を持つ2つの恒久サブスクリプションは、異なるクライアントIDポリシーを持つ場合、2種類の独自のサブスクリプションとして扱われます。同様に、同一クライアントIDを持つ2つの共有可能な非恒久サブスクリプションは、異なるクライアントIDポリシーを持つ場合、2種類の独自のサブスクリプションとして扱われます。
サブスクリプション共有ポリシーを使用する方法の詳細は、以下を参照してください。
Oracle WebLogic Server管理コンソール・オンライン・ヘルプの接続ファクトリ・サブスクリプション共有ポリシーの構成に関する項。
『Oracle WebLogic Server JMSアプリケーションの開発』の高度なPub/Subアプリケーションの開発に関する項
