13 拡張パブリッシュ/サブスクライブ・アプリクーションの開発
高可用性(HA)アプリケーションの設計に必要な、高度なWebLogic JMSのパブリッシュとサブスクライブ(pub/sub)の概念および共通分散トピック(UDT)の機能について説明します。
拡張高可用性の概念の概要
WebLogicメッセージングでは、分散宛先を使用して高可用性および拡張性を提供します。WebLogic Serverの移行機能も、分散宛先の個々のメンバーに対して高可用性を提供します。
ノート:
すべてのトポロジ変更の可能性を明示的に処理するよりは、WebLogic Server MDBまたはOracle SOA JMSアダプタを活用するアプリケーションを設計することをお薦めします。
WebLogicメッセージングの高可用性機能
OracleのWebLogicメッセージングでは、次の機能を使用して高可用性(HA)および拡張性を提供します。
-
『Oracle WebLogic Server JMSリソースの管理』のJMS関連サービスの移行に関する項
-
『Oracle WebLogic Serverクラスタの管理』のサーバー全体の移行に関する項
分散宛先によって、JMSグループの物理的な宛先は、クライアントへの単一の論理的な宛先にアクセスできるようになります。通常、分散宛先を使用するアプリケーションでは、WebLogic JMSがクラスタ内の分散宛先のメンバー宛先間のロード・バランシングおよびフェイルオーバーを提供するため、可用性と拡張性がより高くなっています。自動サービス移行(ASM)およびサーバー全体移行(WSM)によって、サービス・セット(JMSサーバーと宛先を含む)または新規ロケーションにおけるWebLogic Server全体のインスタンスのいずれかを再起動できるようになります。これらの移行機能は、分散宛先の各メンバーに対する高可用性を提供します。
このようなテクノロジの本質は、次に示すようにJMSシステムのトポロジがクライアント・アプリケーションにとって不明である可能性を示します。
-
分散宛先のスケーリングに従ったクラスタのスケーリングは、アプリケーションによって定義されたコンシューマ数を超える場合があります。
-
トポロジは、サーバーまたはサービスの障害発生時に動的に変更される可能性があります。
通常、トポロジの変更は、ローカル上またはリモートWebLogic Serverインスタンス上のいずれかでMDBを使用して透過的に処理されます。ただし、他のクライアント・タイプを使用するとき、特にJMS宛先をホストしているサーバーに対してアプリケーションがリモートである場合、このようなトポロジの変更はアプリケーションによって明示的に処理される必要があります。
レプリケートされた分散トピック使用時のアプリケーション設計の制限
WebLogic Server 10.3.4.0以前の共通分散トピックを実装するアプリケーションでは、次の制限によって制約を受けていました。
-
メッセージは常に分散トピック全体にわたって転送および重複されます。つまり、クラスタ化アプリケーションが各メッセージのコピーを1つ取得するような保証処理および/またはパラレル処理のいずれかには、重要な構成、コーディング、およびメッセージ・ホップを追加する必要があることを示します。
-
1回に1つのみのコンシューマが、XA以外のMDBに限定される場合(サブスクリプションの全処理がスレッド・プールを持つ同一のサーバー上で行われる必要がある場合)を除き、所定のサブスクリプションでメッセージを処理できます。これによって大半の顧客は、単一スレッド式処理ではなく、単一サブスクリプションのトピック・メッセージをラウンドロビン方式で分散処理またはパラレル処理するように意図するアプリケーション・アーキテクチャを設計しなくても済みます。
-
MDBは、同一クラスタに配置される分散トピック上で恒久サブスクリプションのみを直接サポートします。
-
MDB以外のアプリケーションの場合、分散トピック用に作成された永続サブスクライバは、分散トピック(DT)メンバー上でのみ作成でき、永続サブスクリプションはそのメンバー上でのみ存在できます。サブスクリプションをホストしているメンバーがダウンする場合、どのサブスクライバに対してもサブスクリプションが利用できなくなります(そのため、定義ごとに「可用性が高い」状態にはなりません)。
-
サブスクライバを分散トピック・メンバーに確保すると、分散キューに対して実行される調整と同様に、トポロジの変更に対する自動調整が阻害されます。
拡張トピック機能
WebLogic Server 10.3.4.0以降では、パーティション化された分散トピックは、サブスクリプションを共有する機能および複数接続に同一クライアントIDの使用を許可する機能が組み合され、パラレル処理と分散キューに似たHA機能を備えた次のアプリケーション設計パターンを提供しています。
-
インスタンスごとに1つのコピー: アプリケーションの各インスタンスは、トピックにパブリッシュされる各メッセージのコピーを1つ取得します。
-
アプリケーションごとに1つのコピー: 各アプリケーションが全体として(つまり、アプリケーションのすべてのインスタンスを合せて)、トピックにパブリッシュされる各メッセージのコピーを1つ取得します。各インスタンスはトピックに送信されるメッセージのサブセットのみを取得します。
ノート:
WebLogic ServerのMDBを活用するアプリケーションを設計することをお薦めします。高可用性と拡張性の向上にメッセージドリブンBeanを使用するアプリケーションを設計・実装する方法の詳細は、『Oracle WebLogic ServerメッセージドリブンBeanのプログラミング』のJMSトピックを使用したMDBの構成およびデプロイに関する項を参照してください。
高可用性のための拡張トピック・メッセージング機能
アプリケーションが「インスタンスごとに1つのコピー」および「アプリケーションごとに1つのコピー」の設計パターンを達成する仕組みを理解するためには、共有サブスクリプションやクライアントIDポリシーなどの新機能と変更された機能を理解する必要があります。
共有サブスクリプションおよびクライアントIDポリシー
WebLogic Server 10.3.4.0以前では、恒久/非恒久に関係なく1つのサブスクリプションは、いつでも単一のサブスクライバ・インスタンスによってのみアクセスできました。各サブスクライバは、サブスクリプションの確立後にトピックに送信されるすべてのメッセージを受信し、各サブスクリプションのメッセージは1つのコンシューマによって連続して処理されます。
今回のWebLogic Serverリリースでは、複数のサブスクライバは(恒久/非恒久に関係なく)1つのサブスクリプションを共有できます。メッセージは、同一のサブスクリプションを共有する複数のコンシューマ間に配信され、並列に処理されます。サブスクリプションの共有は、同一の宛先インスタンス上またはDTの同一メンバー・インスタンス上でのみ行われます。『Oracle WebLogic Server JMSリソースの管理』の共有サブスクリプションの構成に関する項を参照してください。
サブスクリプションを共有するため、恒久/非恒久に関係なくサブスクリプションは、接続ファクトリまたは接続に設定されたクライアントIDを持つ必要があります。WebLogic Server 10.3.4.0以前では、クライアントIDは所定の時間に1つの接続によって排他的に使用されていました。今回のWebLogic Serverのリリースでは、この制限が緩和されており、クライアントIDの制限使用または無制限使用のための新しいクライアントIDポリシーが採用されています。デフォルトのポリシーである「制限」
では、1つのクライアントIDのみが1つの接続によって使用されます。「制限なし」
ポリシーでは、複数の接続が同一のクライアントIDを使用できるようになります。詳細は、「恒久サブスクリプションの共有が機能する仕組み」を参照してください
サブスクリプション・キーとは
サブスクリプション・キーは、サブスクリプションを一意に識別するために使用されます。非恒久サブスクリプションの場合、キーはクライアントIDおよびクライアントIDポリシーから構成されます。恒久サブスクリプションの場合、キーはクライアントID、クライアントIDポリシー、およびサブスクリプション名から構成されます。
共有サブスクリプションの構成
共有サブスクリプションを構成するには、接続ファクトリ上にサブスクリプション共有ポリシー属性を構成する必要があります。サブスクリプション共有ポリシーを「共有可能」
に設定すると、接続ファクトリを使用して作成されたサブスクライバは、サブスクライバが同一の接続ファクトリまたは異なる接続ファクトリのどちらを使用して作成されたかに関係なく、サブスクリプションを他のサブスクライバと共有できるようになります。コンシューマは、同一のクライアントIDおよびクライアントIDポリシーを持つ場合にかぎり、非恒久サブスクリプションを共有できます。コンシューマは、同一のクライアントID、クライアントIDポリシー、およびサブスクリプション名を持つ場合にかぎり、恒久サブスクリプションを共有できます。次を参照してください。
-
Oracle WebLogic Server管理コンソール・オンライン・ヘルプの接続ファクトリ・サブスクリプション共有ポリシーの構成に関する項
-
Oracle WebLogic Server MBeanリファレンスのClientIdPolicyに関する項
非恒久サブスクリプションの共有が機能する仕組み
複数の非恒久サブスクライバ間でサブスクリプションを共有するため、サブスクライバは、サブスクリプションを識別するために使用されるクライアントIDを持つ必要があります。サブスクリプションの共有を意図するすべてのサブスクライバは、接続上で同一のサブスクリプション・キー(clientID
およびclientIDPolicy
)を持つ必要があります。サブスクリプション共有ポリシーがSHARABLE
に設定されていても、clientID
がConnection
上に設定されていない場合、そのサブスクリプションは共有サブスクリプションではありません。
サブスクリプション・キーを使用して作成される最初のサブスクライバが、サブスクリプションを作成します。同一のサブスクリプション・キーを使用して連続作成されたすべてのサブスクライバは、すべてのサブスクリプションの詳細(セレクタ、noLocal
オプション、および物理的な宛先など)が一致する場合、最初のサブスクライバによって作成されたサブスクリプションを共有します。たとえば:
-
サブスクリプションがセレクタと
noLocal
オプションを使用して作成される場合、同一のサブスクリプション・キーを使用していてもセレクタ、noLocal
、または物理的な宛先が異なるサブスクライバの作成呼出しは、異なるサブスクリプションとして処理されます。 -
EXCLUSIVE
サブスクライバによってclientID
が使用される場合、同一のclientID
、セレクタ、およびnoLocal
オプションを使用する現在または後続のサブスクライバは、異なるサブスクリプションとして処理されます。ノート:
サブスクライバが同一の接続インスタンスまたは
UNRESTRICTED
のクライアントIDポリシーを使用する接続を使用して作成される場合にかぎり、同一のclientID
を持つことが可能です。
非恒久サブスクリプション用の共有サブスクリプション・ポリシーが決定される仕組み
特定の非恒久サブスクリプション用のサブスクリプション共有ポリシーは、サブスクリプション上の最初のアクティブ・サブスクライバによって動的に決定され、サブスクリプションの存続期間中は変更されません。サブスクリプション用のサブスクリプション共有ポリシーを変更しようと試行しても、javax.jms.JMSException
を拡張するInvalidSubscriptionSharingException
がスローされます。たとえば:
-
非恒久サブスクリプションが宛先上に
EXCLUSIVE
サブスクライバを持ち、サブスクリプションがEXCLUSIVE
の場合、同一の宛先上のサブスクリプションを使用して追加サブスクライバを作成しようと試行しても、未作成のサブスクライバがEXCLUSIVE
またはSHARABLE
かどうかに関係なく、InvalidSubscriptionSharingException
がスローされて失敗します。 -
サブスクリプションが
SHARABLE
ポリシーを使用するアクティブ・サブスクライバを持ち、サブスクリプションがSHARABLE
の場合、サブスクリプション上で新しいEXCLUSIVE
サブスクライバを作成しようと試行しても、InvalidSubscriptionSharingException
がスローされて失敗します。
非恒久サブスクリプションが終了する仕組み
同一のサブスクリプションを共有するすべてのサブスクライバがクローズされると、該当するサブスクリプションはクリーンアップされます。具体的には、共有サブスクリプション上の最後のサブスクライバ・コンシューマが close()
メソッドを呼び出すと、サブスクリプションおよび関連付けられたすべてのJMSリソースがクリーンアップされます。
共有サブスクリプションまたは排他的サブスクリプションかどうかに関係なく、非恒久サブスクリプションを示すランタイムMBeanはありません。適切なJMSConsumerRuntime
MBeanを使用した個別のサブスクライバの監視が可能です。
恒久サブスクリプションの共有が機能する仕組み
以前のリリースでは、サブスクリプション・キー(<ClientID, SubscriptionName>
)はクラスタ内のサブスクリプションを一意で識別していました。クラスタ内では、サブスクリプションは、クラスタ内にある単一の宛先インスタンスまたはDTの単一メンバー上にのみ存在できました。このWebLogic Serverリリースでは、サブスクリプション・キーは<ClientID, ClientIDPolicy, SubscriptionName>
になります。同一のサブスクリプション・キーを使用するすべての永続サブスクライバは、通常トピックをサブスクライブする場合、または分散トピックの同一メンバーをサブスクライブする場合に、同一のサブスクリプションを共有します。同一のサブスクリプション・キーを使用する複数のサブスクリプションは、複数の分散宛先メンバーの宛先上に存在できます。
特定のサブスクリプション・キーを使用して作成される最初のサブスクライバが、サブスクリプションを作成します。同一のサブスクリプション・キーを使用して連続作成されたすべてのサブスクライバは、すべてのサブスクリプションの詳細(セレクタ、noLocal
オプション、および物理的な宛先など)が一致し、かつ同一の物理的な宛先上にある場合、最初のサブスクライバによって作成されたサブスクリプションを共有します。
サブスクリプションがセレクタとnoLocal
オプションを使用して作成される場合、異なるセレクタとnoLocal
オプションと同一のサブスクリプション・キーを使用して同一の物理的な宛先上で作成されたサブスクライバは、次のとおりになります。
-
この既存サブスクリプションを使用するアクティブ・サブスクライバが存在しない場合、既存の恒久サブスクリプションを置換し、恒久サブスクリプション用に保存されるすべての保留メッセージをクリーンアップします。
-
異なるセレクタまたは
noLocal
オプションと同一のサブスクリプション・キーを使用するアクティブ・サブスクライバが存在する場合、InvalidSubscriptionSharingException
をスローします。
恒久サブスクリプション用の共有サブスクリプション・ポリシーが決定される仕組み
特定の恒久サブスクリプション用サブスクリプション共有ポリシーは、サブスクリプション上の最初のアクティブ・サブスクライバによって動的に決定され、すべての現在のサブスクライバが終了し、新規サブスクライバが異なるポリシーに接続しないかぎり、変更されません。すでにアクティブ・サブスクライバを持つサブスクリプションのポリシーを変更しようと試行しても、InvalidSubscriptionSharingException
がスローされます。たとえば:
-
恒久サブスクリプションが
EXCLUSIVE
サブスクライバを持ち、サブスクリプション共有ポリシーがEXCLUSIVE
の場合、サブスクリプション上で追加サブスクライバを作成しようと試行しても、未作成のサブスクライバがEXCLUSIVE
またはSHARABLE
かどうかに関係なく、InvalidSubscriptionSharingException
がスローされます。 -
恒久サブスクリプションが
SHARABLE
ポリシーを使用するアクティブ・サブスクライバを持ち、サブスクリプション共有ポリシーがSHARABLE
の場合、サブスクリプション上で新しいEXCLUSIVE
サブスクライバを作成しようと試行しても、InvalidSubscriptionSharingException
がスローされます。
ノート:
既存の恒久サブスクリプション上でサブスクリプション共有ポリシーを変更しても、サブスクリプション上にすでに存在するメッセージは一切削除されません。
恒久サブスクリプションのサブスクライブを解除する方法
サブスクリプションのサブスクライブを解除する前に、サブスクリプション用のクライアントIDポリシーを考慮する必要があります。
-
RESTRICTED
の値を持つクライアントIDポリシーを使用するアプリケーションは、標準のSession.unsubscribe(String name)
APIを使用して恒久サブスクリプションのサブスクライブを解除します。
ノート:
WebLogic Server 10.3.4.0以前では、すべてのクライアントIDはデフォルトでRESTRICTED
になっています。所定のクライアントIDは、WLS JMSクラスタで所定の時間に1つの接続によってのみ使用できました。
-
UNRESTRICTED
の値を持つクライアントIDポリシーを使用するアプリケーションは、サブスクリプション名およびトピックまたは分散トピック・メンバー・オブジェクトを提供することによって、WLSession.unsubscribe(String name, Topic topic)
拡張を使用して、恒久サブスクリプションのサブスクライブを解除します。
恒久サブスクライバのサブスクライブ解除時に考慮する点
次の項では、サブスクライブを解除する方法または例外をスローするシナリオを避ける方法について説明します。
-
サブスクリプションにアクティブなコンシューマが存在する場合、
unsubscribe()
メソッドへの呼出しは、JMSException
をスローします。
-
サブスクリプション上にアクティブ・コンシューマが存在しない場合、
unsubscribe()
メソッドへの呼出しは、サブスクリプション・キー<ClientID, ClientIDPolicy, SubscriptionName>
によって識別される一致する恒久サブスクリプションを削除します。 -
恒久サブスクリプションの
unsubscribe()
メソッドは、スタンドアロン・トピックごとまたはDTメンバーごとに実行されます。 -
RESTRICTED
のクライアントIDを持つ接続を使用して作成されたサブスクリプションは、同一のRESTRICTED
のクライアントIDを使用する接続からのみクリーンアップされます。 -
UNRESTRICTED
のクライアントIDを持つ接続を使用して作成されたサブスクリプションは、同一のUNRESTRICTED
のクライアントIDを使用する接続からのみクリーンアップされます。 -
WebLogic JMSが、
unsubscribe
呼出しと同一のクライアントIDとクライアントIDポリシーを使用して作成されたトピック上で一致するサブスクリプションを検出しない場合、InvalidDestinationException
がスローされます。 -
UNRESTRICTED
のクライアントIDを持つunsubscribe
呼出しが、DTを指定する場合またはいかなるトピックも指定しない場合、InvalidDestinationException
がスローされます。 -
.NetおよびCのAPIメッセージング・アプリケーションは、WebLogic Server 10.3.4.0以降でデプロイされる接続ファクトリ上でクライアントIDポリシーおよびサブスクリプション共有ポリシーを使用することによって、サブスクリプションを共有できますが、アンサブスクライブAPI拡張は、制限なしのクライアントIDを使用するサブスクリプションには使用できません。これを解決するには、恒久サブスクリプションの管理に関する項で説明されているように、管理用の手段を使用します
恒久サブスクリプションの管理
クラスタ全体に分散したサブスクリプションが存在する場合、削除する必要があってもまだ削除されてはいないサブスクリプションが存在する可能性があります。このようなサブスクリプションは「中止された」サブスクリプションと呼ばれることがあり、メッセージを処理するサブスクライバが存在しない場合でも、メッセージを蓄積し続ける可能性があります。蓄積しているメッセージの有効期限が切れていない場合、それらのメッセージによって結果的にトピックがリソース割当て例外(割当て例外)のスローを開始する可能性があったり、割当てが構成されていない場合には、蓄積しているメッセージのためにサーバーがメモリーを使い果たしたりする可能性があります。
たとえば、アクティブ・サブスクライバがサブスクリプション上に存在する場合、unsubscribe
呼出しは失敗し、unsubscribe
呼出しは非アクティブ(シャットダウン)メンバー上のサブスクリプションに到達しません。これが発生すると、サブスクリプションはメンバー上に残され、管理者によって手動で削除されるか、または呼出しが繰り返されるまで呼出しは失敗します。
このような状況の処理に役立てるため、管理者には恒久サブスクリプションの監視および管理用の次のオプションがあります。
-
各恒久サブスクリプションには1つの
JMSDurableSubscriptionRuntimeMBean
インスタンスがあります。管理者は、WebLogic Server管理コンソールまたはWLSTコマンド行/スクリプトを使用してトピックまたはUDT上で監視できます。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMSサーバーの監視に関する項を参照してください。 -
中止または孤立した恒久サブスクリプションを検出するには、管理者は
JMSDurableSubscriberRuntimeMBean
上でLastMessagesReceivedTime
をチェックします。getLastMessagesReceivedTime()
メソッドは、サブスクライバがサブスクリプションからメッセージを取得した最後の時間を返します。この情報に基づき、同一MBean上のMessagesPendingCount
またはBytesPendingCount
などの属性とともに、管理者は特定の恒久サブスクリプションのステータスに関する明確なビジョンを構築し、リソースのクリーンアップなどの適切な対応を取ることが可能です。
JMSDurableSubscriberRuntimeMbeanのネーミング・ルール
恒久サブスクリプションがサブスクリプション・キー<MyClientID, MySubscriptionName>
を使用して作成される場合、関連付けられるJMSDurableSubscriberRuntimeMBean
の名前は次のいずれかになります。
-
クライアントIDポリシーが
RESTRICTED
の場合は、MyClientID
_
MySubscriptionName
。ここで、MyClientID
はこのサブスクリプションのクライアントIDであり、MySubscriptionName
はサブスクリプション名です。 -
クライアントIDポリシーが
UNRESTRICTED
の場合は、MyClientID
_
MySubscriptionName
@
topicName
@
JMSServerName
。ここで、MyClientID
はこのサブスクリプションのクライアントID、MySubscriptionName
はサブスクリプション名、topicName
はスタンドアロン・トピックまたはUDTメンバーの名前、JMSServerName
はトピックまたはメンバーがデプロイされる場所のJMSServerの名前です。
トピック使用時の設計方針
高可用性アプリケーションの開発に使用できるトピックベースの設計方針について学習します。
「インスタンスごとに1つのコピー」設計方針
「インスタンスごとに1つのコピー」設計方針は従来の設計パターンで、10.3.4.0以前のWebLogic Serverリリースと後方互換性があります。「インスタンスごとに1つのコピー」には、次の特徴があります。
-
アプリケーションの各インスタンスは、トピックにパブリッシュされる各メッセージのコピーを1つ取得します。
-
通常、このパターンを最適に実装するには、クラスタでポリシーとサブスクリプションを自動的に設定するMDBを活用します。「分散トピックのベスト・プラクティス」を参照してください
「アプリケーションごとに1つのコピー」設計方針
「アプリケーションごとに1つのコピー」設計方針は、WebLogic Server 10.3.4.0以降のリリースで使用できる設計パターンです。「アプリケーションごとに1つのコピー」設計方針には、次の特徴があります。
-
通常、このパターンを最適に実装するには、クラスタでポリシーとサブスクリプションを自動的に設定するMDBを活用します。「分散トピックのベスト・プラクティス」を参照してください
-
各アプリケーションが全体として(つまり、アプリケーションのすべてのインスタンスを合せて)、DTにパブリッシュされる各メッセージのコピーを1つ取得します。つまり、各インスタンスはDTに送信されたメッセージのサブセットのみを受信します
-
クライアントIDポリシーは
UNRESTRICTED
です。 -
サブスクリプション共有ポリシーは
SHARABLE
です。 -
サブスクライバが恒久の場合は、同一のサブスクリプションを使用します。
-
すべてのコンシューマは同一のトピック・インスタンス(またはDTメンバー)をサブスクライブします。
JMS 2.0共有サブスクリプション使用時の考慮事項
JMS 2.0共有サブスクリプションは、独自のWebLogic共有サブスクリプション機能を内部的に利用します。このため、JMS 2.0および独自のWebLogic共有サブスクリプションは、類似したセマンティクスを持っています。
この項では、JMS 2.0共有サブスクリプションを使用して例外のスローを回避する方法に関する情報を提供します。
-
共有の非恒久サブスクリプションが分散トピック上に直接、または分散トピック・メンバー上に作成され、接続上にクライアントIDが設定されていない場合は、
UNRESTRICTED
クライアントIDポリシーを持つ接続を使用します。 -
共有の恒久サブスクリプションが分散トピック上に直接作成された場合は、MDBを使用するか、メンバー上で拡張機能およびサブスクリプションを使用します。
-
共有の恒久サブスクリプションが分散トピック・メンバー上に作成され、接続上にクライアントIDが設定されていない場合は、
UNRESTRICTED
クライアントIDポリシーを持つ接続を使用します。
ノート:
クライアントIDポリシーがUNRESTRICTED
に設定されている場合は、サブスクリプション名およびトピックまたは分散トピック・メンバー・オブジェクトを提供することによって、WLSession.unsubscribe(String name, Topic topic)
拡張を使用して、恒久サブスクリプションのサブスクライブを解除します。
レプリケートされた分散トピックの置換
レプリケートされた分散トピック(RDT)をスタンドアロン・トピックまたはPDTで置き換える方法について学習します。
レプリケートされた分散トピックを置換する理由
次のスコープではRDTはサポートされないため、場合によっては、既存のレプリケートされた分散トピック(RDT)をパーティション化された分散トピック(PDT)またはスタンドアロン・トピックに置き換える必要があります。
-
クラスタをターゲットとするJMSサーバー。Oracle WebLogic Server JMSリソースの管理のJMSクラスタと高可用性の簡略化された構成を参照してください。
-
マルチテナント・リソース・グループまたはリソース・グループ・テンプレート
-
動的クラスタ
ノート:
WebLogic Server Multitenantドメイン・パーティション、リソース・グループ、リソース・グループ・テンプレート、仮想ターゲットおよびリソース消費管理は、WebLogic Server 12.2.1.4.0で非推奨になり、次のリリースで削除されます。これらのスコープでRDTを構成またはデプロイしようとすると、構成検証エラーが生成されます。
また、PDTとスタンドアロン・トピックは同じユース・ケースに対応している上、より単純で、パフォーマンスに優れていることが多いため、RDTをこれらのオプションで置き換えることは有用です。RDTは、トランザクションの内部フォワーダを暗黙的に実行してそのメンバー間でメッセージをレプリケートするため、これらのフォワーダには比較的高い負荷がかかります。
RDTの置換前の重要な前提条件
RDTを別のタイプのトピックに置換する前に、事前に存在していたメッセージが確実に処理されるようにすることが重要です。さらに、RDTの古いサブスクリプションをすべて削除するか、さらに単純な方法として、すべてのストア・ファイルまたはデータベース表を削除する必要があります。クラスタを再起動せずに変更を行う必要がある場合は、別の名前の新しいトピックを作成して、古いトピックを削除します。
スタンドアロン・トピックによるRDTの置換
RDTをPDTではなくシングルトン・スタンドアロン・トピックで置換するのは最も単純なオプションですが、拡張性と一部のHAが犠牲になります。クラスタでホストされているスタンドアロン・トピックが移行可能であることを確認すれば、HAに関する懸念事項を軽減できます。『Oracle WebLogic Server JMSリソースの管理』のフェイルオーバーの場合に関する項を参照してください。
ノート:
クラスタをターゲットとするJMSサーバー、動的クラスタまたはマルチテナント・スコープの構成でホストされているスタンドアロン・トピックは、シングルトン分散ポリシーが構成されたストアを参照するJMSサーバー上でのみホストできます。また、これらについては、クラスタで、コンセンサス・リーシングよりもデータベース・リーシングが推奨されるクラスタ・リーシングを構成する必要があります。 Oracle WebLogic Server JMSリソースの管理のJMSクラスタと高可用性の簡略化された構成を参照してください。
ノート:
WebLogic Server Multitenantドメイン・パーティション、リソース・グループ、リソース・グループ・テンプレート、仮想ターゲットおよびリソース消費管理は、WebLogic Server 12.2.1.4.0で非推奨になり、次のリリースで削除されます。PDTによるRDTの置換
PDTを構成するには、共通分散トピックのforwarding-policy
属性をReplicated
ではなくPartitioned
に設定します。PDTでは、メンバーの1つに対して生成されたメッセージを他のすべてのメンバーにレプリケートしないため、この異なるセマンティックによってさらに変更が必要になる場合があります。
-
MDBを使用してPDTから消費している場合は、各MDBの
topic-message-distribution-mode
属性をone-copy-per-server
またはone-copy-per-app
に設定する必要があります(まだ設定されていない場合)。デフォルトの互換性topic-message-distribution-mode
は、PDTでは機能しません。MDBによって例外が生成されます。『Oracle WebLogic ServerメッセージドリブンBeanの開発』のJMSトピックを使用したMDBの構成とデプロイメントに関する項およびトピックのデプロイメント・シナリオに関する項を参照してください。 -
SOA JMSアダプタを使用してPDTから消費している場合は、変更は必要ありません。これは、PDTから消費する場合に、デフォルトでMDBと同等の
one-copy-per-app
に設定されます。『テクノロジ・アダプタの理解』のWebLogic Server JMSでの分散宛先(キューおよびトピック)へのアクセスに関する項を参照してください。 -
同様に、OSA JMSアダプタを使用してPDTから消費している場合は、多くの場合、変更は必要ありません。
-
MDB、SOA JMSアダプタまたはOSA JMSアダプタ以外の
javax.jms
トピック・コンシューマがある場合は、アプリケーション・コードの変更が必要になることがあります。たとえば、アプリケーションがシングル・サブスクリプションからではなくすべての各PDTメンバーのサブスクリプションから消費するように、アプリケーションの変更が必要になる場合があります。これは、PDTは送信された各メッセージをその各メンバーにレプリケートしないためです。この領域におけるヘルパーAPIの詳細および説明は、「拡張パブリッシュ/サブスクライブ・アプリクーションの開発」、「分散宛先に関する拡張プログラミング」および「JMS宛先可用性ヘルパーAPIの使用」を参照してください。
分散トピックのベスト・プラクティス
分散トピックを使用して新しいアプリケーションを設計するときには、Oracleの推奨事項に従ってください。
-
MDBを活用してアプリケーションの設計および複雑性を簡略化します。次を参照してください。
-
『Oracle WebLogic ServerメッセージドリブンBeanの開発』の分散トピック・デプロイメント・シナリオに関する項
-
『Oracle WebLogic ServerメッセージドリブンBeanの開発』の分散トピックを使用したMDBの構成およびデプロイに関する項
-
-
MDBがオプションではない場合、
UNRESTRICTED
クライアントIDポリシー、SHARABLE
サブスクリプション・ポリシーをパーティション化トピック(PARTITIONED
転送ポリシーを持つ分散トピック)と組み合せて使用することを検討します。次を参照してください。-
『Oracle WebLogic Server JMSリソースの管理』の無制限クライアントIDの構成に関する項
-
『Oracle WebLogic Server JMSリソースの管理』の共有サブスクリプションの構成に関する項
-
『Oracle WebLogic Server JMSリソースの管理』のパーティション化された分散トピックの構成に関する項
-