| Oracle® Fusion Middleware Oracle WebLogic Server JMSアプリケーションの開発 12c (12.2.1.3.0) E90332-02 |
|
 前 |
クラスタ環境でJMS分散宛先の使用時に、高可用性(HA)、スケーラビリティおよび柔軟性を提供する分散アプリケーションまたはコンテナを設計する方法について説明します。
注意:
このガイドには、経験豊富なJMS開発者向けの高度な情報が記載されています。分散宛先と相互運用する際はメッセージドリブンBean (MDB)を使用することをお薦めします。MDBコンテナは、分散宛先のすべてのメンバー間で内部コンシューマを必要に応じて自動的に作成して閉じます。また、セキュリティ、スレッド化、プーリング、アプリケーション・ライフサイクル、自動再接続、トランザクションのリスト化も処理します。MDBを使用できない場合、より簡単な回避策(分散宛先でコンシューマをリバランスするようにコンシューマを定期的に再起動したり、メッセージの順序付けやパフォーマンスを気にしない場合は、分散キューの転送オプションを有効にしたりするなど)を使用できます。
分散宛先(DD)は、単一の論理宛先(キューまたはトピックのグループ)としてアクセスされるJMS物理宛先のグループです。メッセージはメンバー間でロード・バランシングされ、クライアントはメンバー宛先間でフェイルオーバーできます。
MDBを利用しない分散宛先ユーザーの場合、コンシューマ・アプリケーションに関する問題が生じることがあります。たとえば、次のような問題があります。
すべてのDDメンバーをコンシューマで確実に処理できません。
コンシューマのないDDメンバーに未処理のメッセージが蓄積されます。
JMSサーバーの移行時、WebLogic Serverの再起動時、あるいはDDメンバーに変更が生じるイベントの際にDDコンシューマが自動的にリバランスしません。
このような使用の問題を解決するため、WebLogic Serverは、「拡張パブリッシュ/サブスクライブ・アプリクーションの開発」で示されるように、JMS宛先高可用性ヘルパーAPIおよび拡張トピック機能を提供します
コンシューマ・ロード・バランシングについて説明する前に、プロデューサ・ロード・バランシングの基本事項とベスト・プラクティスを最初に確認しておくと便利です。
JMSプログラムは、次の3つの段階でメッセージ送信を設定します。
クライアントは、JMS接続ファクトリを使用してWebLogicへのJMS接続を作成します。
クライアントはこの接続を使用して、JMSのセッションとセンダーを作成します。
クライアントは、このセンダーを使用してメッセージを送信します。
WebLogic JMSでは、クライアントが接続するWebLogicサーバーはクライアントの接続ホストと呼ばれ、メッセージは常にセンダーからその接続ホストを介して、接続ホストと同じクラスタ内の宛先にルーティングします。接続は、その有効期間中は接続ホストに固定されます。
WebLogic接続ファクトリは、1つ以上のWebLogicサーバーでターゲット指定できます。接続ファクトリがターゲット指定される同じWebLogicサーバーでクライアントが実行している場合、ファクトリは常に、クライアントと同じサーバーの接続ホスト(接続はローカル)で接続を返します。一方で、接続ファクトリのターゲットに含まれるWebLogicサーバーでクライアントが実行していない場合、ファクトリはターゲット間で自動的にロード・バランシングして、そのいずれかに接続を返します。
センダーが分散宛先で機能する場合、各メンバーのJNDI名に送信するのではなく、DQまたはPDTのJNDI名(その論理名)に常に送信します。これにより、ロード・バランシング動作の自動化が可能になります。
DQまたはPDTに対するセンダーのデフォルト動作では、メンバーがセンダーの接続ホストで実行する場合、すべての送信メッセージはいずれかのローカル・メンバーに送信されます。それ以外の場合、メッセージはすべてのメンバー間でラウンドロビンで送信されます。
ローカル・メンバーがセンダーの接続ホストに存在する場合でも、同じDQまたはPDTセンダーのメッセージをすべてのアクティブなメンバー間でラウンドロビンで送信されるようにするには、Server Affinityをfalseに、Load Balanceをtrueに設定してカスタム接続ファクトリを使用します。
RDTへのセンダーは、常にロード・バランシングを1回実行し、次にすべてのメッセージの特定のメンバーに固定します。このメンバーが「センダー・ホスト」になります。メッセージがセンダー・ホストに着信すると、メッセージはすべてのRDTメンバー上にあるすべてのサブスクリプションに自動的に複製されます。
センダー・ホストに対する初期ロード・バランシング判定が、接続ホストへの判定と同じ扱いにならないように制御する場合、false (デフォルトはtrue)に構成された「サーバー・アフィニティ」およびtrue (デフォルト)に構成された「ロード・バランシング」と共に接続ファクトリを使用します。
次の項では、JMSDestinationAvailabilityHelper APIの使用方法について説明します。
クライアントのjavax.jms APIを使用してコンシューマを作成し、DD論理JNDI名を指定した場合、コンシューマはアクティブなDDメンバーにロード・バランシングされ、その存続期間中は該当メンバーに固定されます。すべてのコンシューマの作成後に新しいメンバーがアクティブになる場合、新しいメンバーにコンシューマはありません。
JMSDestinationAvailabilityHelper APIにより、宛先が使用可能または使用不可になる場合に通知を取得する手段が提供されます。これらの通知は、アプリケーションを初期化したときに使用不可のメンバーが存在する場合でもすべてのDDメンバーでアプリケーションがコンシューマを作成する際に役立ちます。同じメカニズムを使用して、他のタイプの宛先(WebLogic分散宛先のみではなく、通常の宛先や外部ベンダーの宛先)の可用性を検出することもできます。
アプリケーションは、JNDIコンテキスト・パラメータと宛先のJNDI名を指定して、ヘルパーに通知リスナーを登録します。DDについては、メンバーが使用可能および使用不可になる場合、アンデプロイされる場合、新しいメンバーとして追加される場合、移行、停止、再起動する場合に、ヘルパーによってリスナーに通知されます。
WebLogic ServerのMDBは、両方のローカルMDB (DDと同じクラスタにデプロイされたMDB)とリモートMDB (DDをホストするクラスタとは別のクラスタにデプロイされたMDB)に同じメカニズムを内部で使用することに注意してください。MDBには、JMSDestinationAvailabilityHelper APIが提供する同じ動的適応性をDDトポロジ変更に対して実現する即時利用可能なソリューションがあります。
JMSDestinationAvailabilityHelper APIを使用するアプリケーションは、次の一般的なステップに従います。
下記のステップ3の動作を実現するため、weblogic.jms.extensions.DestinationAvailableListenerインタフェースを実装します。
JNDIコンテキスト・プロパティ(通常はURLとコンテキスト・ファクトリのみ)、宛先のJNDI名、リスナー・インスタンスを指定して、ヘルパーに関連事項を登録します。クライアントがDDと同じクラスタで実行している場合はURLを指定しないでください。
import java.util.Hashtable; import javax.naming.Context; import weblogic.jms.extensions.JMSDestinationAvailabilityHelper; Hashtable contextProps = new Hashtable(); contextProps.put(javax.naming.Context.PROVIDER_URL, myURL); contextProps.put(Context.INITIAL_CONTEXT_FACTORY, "weblogic.jndi.WLInitialContextFactory"); JMSDestinationAvailabilityHelper dah = JMSDestinationAvailabilityHelper.getInstance(); RegistrationHandler rh = dah.register( contextProperties, destinationJNDIName, myDestinationAvailableListener )
リスナー・コールバックを処理します。各リスナー・インスタンスに対するコールバックは単一のスレッドがあり、これにより、2つのコールバックが同時に発生することはあります。
onDestinationsAvailable(): 通常は最初の通知。このコールバックの実装は、指定の各宛先でゼロ以上のコンシューマを作成すると反応するのが一般的です。これが失敗した場合、定期的に再試行します。
onDestinationsUnavailable(): このコールバックは、通常、宛先で既存のコンシューマを破棄する場合に使用されます。
onFailure(): このコールバックは、通常、失敗のログを記録する場合に使用されます。ヘルパーは引き続き内部で再試行し、以降のコールバックを行いますが、管理者は失敗を確認する必要があります。同じ失敗が繰り返された場合に、ヘルパーは1回のみonFailure()メソッドを呼び出そうとします。
完了したら、rh.unregister()メソッドを呼び出して宛先の関連事項の登録を解除します。
前述のように、onDestinationsAvailable()通知は、スタンドアロンの宛先、外部宛先、分散宛先のメンバーが使用可能になることを示します。通知はDestinationDetailインスタンスのリストで構成され、キー情報は各DetailでgetDestinationType()、getJNDIName()、isLocalWLSServer()、isLocalCluster()を呼び出すことで取得されます。
宛先の詳細は、呼出し元が行うアクションの決定に役立ちます。宛先のタイプがDD_QUEUE、REPLICATED_DTまたはPARTITIONED_DTの場合、詳細のgetJNDIName()メソッドにより、特定のDDメンバーのJNDI名が返されます。呼出し元はアプリケーション・コンシューマのインスタンスをメンバーにデプロイする場合としない場合があります。宛先のタイプがPHYSICALまたはFOREIGNの場合、アプリケーションは宛先を通常の宛先として扱います。
特にDDで使用する場合、DestinationDetailのコロケーション・フラグを利用することをお薦めします。宛先のコロケーションの性質を判断するには、isLocalWLSServer()とisLocalCluster()を呼び出します。「ローカル・サーバー・コンシューマのベスト・プラクティス」を参照してください
APIとそのメソッドの詳細は、Oracle WebLogic Server Java APIリファレンスのDestinationDetailに関する項を参照してください。
次の項では、コンシューマ・コンテナのベスト・プラクティスのガイドラインを示します。
アプリケーションのデプロイメント時にJMSDestinationAvailabilityHelperに登録します。ヘルパーがリスナーでonFailure()コールバックを呼び出す場合、デプロイメントを失敗しないでください(断続的な失敗になると想定されます)。
アプリケーションのアンデプロイメント時にJMSDestinationAvailabilityHelperへの登録を解除します。
クライアントが宛先と同じサーバーまたは同じクラスタで実行している場合、ヘルパーへの登録やJNDIコンテキストの作成時にURLを指定しないでください。これにより、ヘルパーは確実にローカル・コンテキストを作成します。
isLocalCluster()またはisLocalServer()がtrueを返しても、URLを指定した場合(この場合URLは不要)、1つの警告ログと見なします。
onFailure()通知で報告されるエラーのログを記録するため、アプリケーションの開発者は、構成/アプリケーションのエラーを修正することができます。同じ例外のログを繰り返し記録することは避けてください。ヘルパーは引き続き内部で再試行し、成功または異なるタイプの失敗に対して以降のコールバックを行いますが、管理者は失敗を確認する必要があります。エラーは、不正なURL、無効なセキュリティ情報、存在しない宛先などのアプリケーションまたは管理上のエラーが原因で発生します。また、JNDIコンテキストのホストまたは宛先が一時的に使用不可になる場合にも発生します。
JMS呼出しが例外をスローするか、JMS接続例外リスナーが接続の失敗を報告した場合、接続を閉じます。すべてのリソースの誤りが修正されたら、すべてのリソースを定期的に再初期化します。再初期化には、通常、コンテキストの作成、JNDIルックアップの実行、接続、セッション、コンシューマの作成が必要です。
失敗後すぐに再試行することは避けてください。かわりに数秒ごとに定期的に再試行して、サーバーがオーバーロードしないようにします。
通常、同一のサーバーまたはクラスタに対して複数のJNDI初期コンテキスト・インスタンスを作成しないようにします。
注意:
特にドメイン間シナリオなどの一部のセキュリティ問題を解決するには、追加のコンテキスト・インスタンスを使用する必要があります。
アンデプロイ時にコンテキストでclose()を呼び出して、メモリー・リークを防止します。
コンテキストでclose()を呼び出して、失敗時(ルックアップの失敗を含む)に再作成します。
JMS接続の場合、標準のJMS接続「例外リスナー」を必ず登録します。
onException()で接続を閉じてJNDIルックアップを定期的に再試行し、JMS接続を再作成して別のスレッドでコンシューマを設定します。
アンデプロイ時に接続を閉じて、メモリー・リークを防止します。
複数のセッション間でWebLogic Server接続を共有するのではなく、セッションにつき1つの接続を作成することを検討します。WebLogic Serverでは、複数の接続によりロード・バランシング機能が向上します。WebLogic Serverを使用する場合、パフォーマンス・ペナルティはありませんが、一部の外部ベンダーは接続ごとにTCP/IPソケットや同様の高価なリソースを作成するため、外部ベンダーによる予想外のオーバーヘッドが生じる場合があります。
Oracle WebLogic Server Java APIリファレンスのJMSDestinationAvailabilityHelperに関する項には、使用可能な各種メソッドの使用方法や動作に関する詳細があります(次の項で説明する相互運用性ガイドラインに関する詳細を含む)。
DAヘルパーに通知リスナーを登録する際に指定するコンテキスト・プロパティは、外部ベンダーや旧バージョンのWebLogic Serverのコンテキストを含む有効なJNDIコンテキストに解決できます。
外部(WebLogic以外の)コンテキストの場合、外部JNDIベンダーのクラスは現在のクラスパス内に存在する必要があります。また、Context.INITIAL_CONTEXT_FACTORYプロパティは、外部ベンダーのJNDIコンテキスト・ファクトリのクラス名を参照する必要があります。
JMSDestinationAvailabilityHelper APIは、JNDIコンテキストに登録できるどのタイプの宛先(非分散宛先、外部ベンダーの宛先など)でも機能します。ただし、使用不可の通知は、DDメンバーに対してのみ生成され、DestinationDetailの特定のフィールドはDDメンバーにのみ適用されます。使用不可の通知は、外部宛先には適用されません。
DAヘルパーがWebLogic Server 9.0以降のDDと相互運用する場合、DDのメンバーごとに通知が生成されますが、9.0以前のバージョンと使用する場合、DD宛先の論理JNDI名を含む単一のDestinationDetail通知のみが生成され、getDestinationType()はPHYSICALを返します。
WebLogic Server 9.0以前のDDは、通常の宛先として扱われることが多いため、「レプリケートされた分散トピック使用時のアプリケーション設計の制限」で説明した概略と同様の制限を持つことになります
WebLogic Server 10.3.4以前のリリースでは、無制限の(非排他的な)クライアントIDまたは共有サブスクリプションを有効化する機能がありません。
注意:
無制限クライアントIDおよび共有サブスクリプションを構成する方法については、『Oracle WebLogic Server JMSリソースの管理』の無制限ClientIDの構成に関する項および共有サブスクリプションの構成に関する項を参照してください。
宛先がWebLogic 10.3.4.0以降のトピックかどうかを判定するには、宛先タイプがPHYSICAL_TOPIC, REPLICATED_DTまたはPARTITIONED_DTで、FOREIGN_TOPICになっていないことを確認し、isAdvancedTopicSupported()がtrueを戻すことを確認します。WebLogic Server 10.3.4.0以前のトピックは次のとおりです。
PARTITIONED_DTにはなりません。
PHYSICAL_TOPICは通常トピックとして扱われることが多く、サブスクリプションごとに1つのコンシューマに制限されます。
論理DT名が指定されているとき、WebLogic 10.3.4.0以前のDTメンバーそれぞれに対して恒久的なサブスクライバを自動的に試行しようとすることはお薦めできません。ご使用のアプリケーションがこのオプションをサポートしないようにすることをお薦めするとともに、WebLogic 10.3.4.0以前のDT上の恒久サブスクリプションが、論理DT名を指定するかわりにメンバーのJNDI名を直接指定する必要があることをユーザーに通知するエラー・ログを記録することをお薦めします。
WebLogic Server 10.3.4.0以前の分散トピックを非恒久的にサブスクライブする場合、任意の単一のメンバーJNDI名上または論理DR名上でコンシューマを作成し、他のすべての通知を無視することをお薦めします(あるサブスクライバがDTに送信されるすべてのメッセージを取得するため、サブスクリプション上にはコンシューマ・スレッドが1つのみ存在できます)。
一部の宛先詳細フィールドの動作は、宛先のタイプ、JMSベンダー、WebLogic JMS動作時のWebLogic Serverバージョンに基づいて変わります。Oracle WebLogic Server Java APIリファレンスのJMSDestinationAvailabilityHelperに関する項を参照してください。
次の項では、Java EEおよびWebLogic Serverセキュリティ・モデルを使用したセキュリティの実施について説明します。
WebLogic Server資格証明の伝播は、多くの場合、スレッドを基準に実行されます。現在のスレッド資格証明は、JNDIコンテキストまたはアプリケーション記述子の作成時に指定することによって確立されます。このような資格証明は、WebLogic JMS呼出しを含むJVM間のRMIベースの呼出しとともに自動的に伝播されます。
コンテキスト・インスタンスが異なるスレッドに渡されてそこで使用される場合、JNDIコンテキストに関連付けられる件名は失われます。これによって、一部のマルチ・ドメイン・アプリケーション・シナリオでセキュリティ問題が起こる可能性があります。次の項では、資格証明の受渡しに関するメソッドを説明します。
JMS宛先とJNDIリソースが保護されていない場合、匿名の件名を使用します。特に、複数のWebLogicドメイン間で相互運用するとき、JMS宛先とJNDIリソースが保護されていない場合には、通常、すべての呼出しが匿名の件名を使用するように強制することが最も簡単な方法となります。非匿名資格証明情報は通常、特定のドメインに対してのみ有効で、異なるドメインを使用するように試行を実行する場合、セキュリティの例外が発生することに繋がります。
次のコードでは、件名をキャッシュし、匿名ユーザーを使用して別のスレッドに関連付ける方法の例を示します。
import java.security.PrivilegedExceptionAction;
import java.security.PrivilegedActionException;
import javax.security.auth.Subject;
import weblogic.security.Security;
class MyClass {
// don't make the cached subject public
private Subject subject;
MyClass() {
subject = Security.getCurrentSubject();
}
void doSomething() {
// run some operation as the subject on the original thread
try {
Security.runAs(subject,new PrivilegedExceptionAction() {
public Object run() throws Exception {
// do something;
return null; // or return some Object
}});
} catch (PrivilegedActionException e) {
// handle exception
}
}
}
クロス・ドメイン・セキュリティは、2つ以上のWebLogic Serverドメイン全体のセキュリティを確立するためにWebLogic Server 10.0で導入された機能です。WebLogic Serverは、クロス・ドメイン・ユーザーのセキュリティ・ロールを確立し、各ドメインでWebLogic資格証明マッピング・セキュリティ・プロバイダを使用してクロス・ドメイン・ユーザーに使用される資格証明を保存します。クロス・ドメイン・セキュリティ機能は、ドメイン・ベースごとに有効化できます。クロス・ドメイン資格証明マッピングは、内部通信の保護が必要な各リモート・ドメインに構成される必要があります。JTA、MDB、およびJMSは、この機能に依存する3つのサブシステムです。クロス・ドメイン・セキュリティを構成する方法の詳細は、次を参照してください。
『Oracle WebLogic Serverセキュリティの管理』のWebLogic Serverドメイン間の信頼の有効化に関する項
『Oracle WebLogic Server JMSアプリケーションの開発』のクロス・ドメイン・セキュリティの使用に関する項
『Oracle WebLogic Serverストア・アンド・フォワード・サービスの管理』のSAFとクロス・ドメイン・セキュリティに関する項
『Oracle WebLogic Server JTAアプリケーションの開発』のクロス・ドメイン・セキュリティの構成に関する項
『Oracle WebLogic ServerメッセージドリブンBeanの開発』のクロス・ドメイン・セキュリティでのMDBの使用に関する項
次の項では、アプリケーションを認証し、JNDIやJMS操作のアプリケーションも認可するJMSアクセス時のユーザー名とパスワードを説明します。
JMSリソースにアクセスするためには、アプリケーションがJNDIプロバイダへのアクセス権を持つ必要があります。資格証明は、アプリケーション・コードがJNDIプロバイダへの初期コンテキストを作成するときに提供されます。初期コンテキストを確立するスレッドが件名を送信するため、すべてのサブシーケンス操作に使用されます。初期コンテキストの作成中にアプリケーションがWebLogic Server上で実行されていて、サーバーURLおよびセキュリティ資格証明が提供されない場合、スレッドは書きコンテキスト作成前にスレッド上にあった同一の資格証明を引き続き所持します。初期コンテキストを作成するスレッドがコンテキストを閉じるとき、スレッドはコンテキスト作成前のスレッド上にある元のセキュリティ資格証明を再開します。
ConnectionFactory.createConnection()呼出しは、任意でユーザー名とパスワードをサポートします。接続作成時に提供される資格証明は、作成される接続上の任意のJMS操作のセキュリティに関する影響がありません(これは、WebLogic JMS Javaクライアント用のWebLogic JMS固有の動作で、.NETクライアントの例外があります)。資格証明は、接続が作成されるドメインでユーザーが有効なユーザーかどうかを確認するためにのみ使用されます。
JNDIプロパティを持つ外部JMSサーバー・インスタンスを構成してJNDIプロバイダへのアクセス権を取得します。JNDIプロパティには、セキュリティ・プリンシパルと資格証明設定用のオプションが含まれます。
ユーザー名およびパスワードは、JMS接続ファクトリをルックアップするためにEJBまたはサーブレット・リソース・リファレンスを使用しない場合に、外部接続ファクトリ・マッピングの構成が無視されるときに指定できます。「プーリングを使用したパフォーマンスの向上」を参照してください
WebLogic JMSは、ACLを宛先に指定するための機能を提供します。この機能を使用すると宛先を保護でき、認可されたユーザーのみが宛先上で操作を実行できるようになります。『Oracle WebLogic Serverロールおよびポリシーを使用したリソースの保護』のJava Messaging Service (JMS)リソースに関する項を参照してください。
WebLogic Server JTAトランザクションの伝播は、スレッド・ベースで実行されます。トランザクションを起動するスレッドは、トランザクションをコミットまたはロールバックするスレッドにする必要があります。WebLogic JMS宛先上でsendまたはreceive操作を実行するとき、WebLogic JTAトランザクションが現在のスレッド上に存在する場合、JMSリソースはWebLogicトランザクション・マネージャに自動的に登録されるため、独自に登録を実行する必要はありません。
WebLogic JMSリソースが外部またはサードパーティのトランザクションに関与する必要があるとき、またはWebLogic以外の宛先がトランザクションに関与する必要があるとき、明示的に「手動」登録を実行するだけで済みます。外部トランザクション・マネージャ(TM)への登録は、WebLogic JMSスタンドアロン・クライアントでは直接サポートされていません。EJBおよびサーブレットのリソース参照を使用すると、WebLogic以外のJMSベンダーをWebLogic TMに自動的に登録できます。
アプリケーションは、JMS操作がグローバルXA—トランザクションに参加する必要がある場合、処理対象セッションを使用しない必要があります。グローバル・トランザクションではXAベースの接続ファクトリを使用する必要があり、一方のローカル・トランザクションでは、XAベースでないJMS接続ファクトリが使用されます。
コンシューマ・アプリケーションは、WebLogic Serverの同じJVMで実行する場合とそうではない場合があります。これらは、それぞれサーバー側コンシューマおよびスタンドアロン・コンシューマと呼ばれます。
JMS UDQコンシューマがWebLogic Serverまたはクラスタにデプロイされる場合、アプリケーションはUDQと同じクラスタ/サーバー、または別のクラスタで実行できます。これら2つの異なるアプリケーション構成を、それぞれローカル・ケースおよびリモート・ケースと言います。
注意:
レプリケートされた分散トピックおよびパーティション化された分散トピックを使用する拡張メッセージ分散モードを実装するためにMDBを使用することをお薦めします。MDBを使用する拡張パブリッシュ/サブスクライブ・アプリケーション設計の詳細は、『Oracle WebLogic ServerメッセージドリブンBeanの開発』の拡張パブリッシュ/サブスクライブ・アプリケーションの開発に関する項および分散トピックを使用したMDBの構成とデプロイに関する項を参照してください。
なんらかの理由によりアプリケーション・アーキテクチャでMDBを使用できないアプリケーションの場合、次のガイドラインに従ってください。
UDQに送信されるすべてのメッセージをアプリケーションで受信するには、アプリケーションがメンバーJNDI名を使用してUDQのメンバーごとに1つのコンシューマを作成する必要があります。このためには、アプリケーションがドメインのトポロジとUDQ構成を把握する必要があります。この場合、JMSDestinationAvailabilityHelperが役立ちます。
一般的な戦略では、特定のアプリケーションの各デプロイメント・インスタンスはJMSDestinationAvailabilityHelperに登録する必要があります。リスナーはメンバーの可用性に関する通知を受け取ります。
onDestinationsAvailable()通知を受け取ると、アプリケーションは使用可能なすべてのメンバーのDestinationDetailインスタンスのリストを取得します。その後、リストのメンバーごとにメンバーのJNDI名を使用して1つ以上のコンシューマ・インスタンスを作成する必要があります。リモート・コンシューマの場合、アプリケーションの各インスタンスは、UDQのメンバーごとにコンシューマを作成する必要があります。ローカル・コンシューマの場合、ローカルUDQメンバーでのみコンシューマを作成します。「ローカル・サーバー・コンシューマのベスト・プラクティス」を参照してください
onDestinationsUnavailable()通知を受け取ると、アプリケーションは、最後の通知以降に使用不可になるすべての宛先のDestinationDetailインスタンスのリストを取得します。その後、リストのメンバー宛先ごとに、メンバー宛先に対して以前に作成されたコンシューマを探し、そのコンシューマを閉じる必要があります。
アプリケーションは可能なかぎり、UDQをホストする同じサーバー、サーバー・グループまたはクラスタにデプロイしてください。この構成で最適なパフォーマンスを実現するために、アプリケーションはローカル・メンバーからのみメッセージを受信する必要があります。サーバーがクラスタ内にある場合はDestinationDetail isLocalWLSCluster()呼出しで、個々のサーバーやクラスタ・メンバーの場合はisLocalWLSServer()呼出しでローカル・メンバーを特定できます。この方法では、すべてのメッセージがローカルになり(ネットワーク呼出しでメッセージが転送されない)、すべてのメンバーがコンシューマで処理されるため、パフォーマンスが向上します。
一部の使用事例では、バランスの取れていないキューの負荷に関して、ローカル・サーバーの最適化ネットワークを節約するよりも、クラスタのすべてのJVM間でメッセージ処理を分散するメリットの方が上回ります。これは特に、メッセージのバックログがクラスタ全体で不規則に生じ、メッセージ処理に費用がかかる場合に関連します。このような使用事例では、リモート・コンシューマに対して一般的な戦略モデルを支持して最適化を回避してください。
注意:
レプリケートされた分散トピックおよびパーティション化された分散トピックを使用する拡張メッセージ分散モードを実装するためにMDBを使用することをお薦めします。MDBを使用する拡張パブリッシュ/サブスクライブ・アプリケーション設計の詳細は、『Oracle WebLogic ServerメッセージドリブンBeanの開発』の拡張パブリッシュ/サブスクライブ・アプリケーションの開発に関する項および分散トピックを使用したMDBの構成とデプロイに関する項を参照してください。
UDTからメッセージを処理するすべてのクラスタ・アプリケーションおよび分散アプリケーションの場合、次の設定と組み合せて10.3.4以降の製品のトピックを使用することをお薦めします。
クライアントIDポリシーをUnrestrictedに設定します。『Oracle WebLogic Server JMSリソースの管理』の無制限ClientIDの構成に関する項を参照してください。
サブスクリプション共有ポリシーをSHARABLEに設定します。『Oracle WebLogic Server JMSリソースの管理』の共有サブスクリプションの構成に関する項を参照してください。
JMSDestinationAvailabilityHelper APIを使用して、メンバー可用性通知を取得します
常にメンバー宛先上でサブスクライバを作成します。
WebLogic JMSには2種類の共通分散トピックがあります。
レプリケートされた分散トピック(RDT)には、メンバー間の転送機能があります。その結果、RDTの各メンバーはRDTに送信されるすべてのメッセージのコピーを持ちます。
パーティション化された分散トピック(PDT)には、メンバー間の転送機能がありません。その結果、PDTの各メンバーは特定のメンバーに送信されたすべてのメッセージの独自のコピーを持ちます。これは、WebLogic Server 10.3.4.0で導入された新しいタイプのDTです。『Oracle WebLogic Server JMSリソースの管理』のパーティション化された分散トピックの構成に関する項を参照してください。
次の項では、RDTおよびPDT使用時の構成要件とプログラミング・パターンを説明します。
「インスタンスごとに1つのコピー」のパターンは、各インスタンスがトピックにパブリッシュされる各メッセージのコピーを取得することを保証します。たとえば、各インスタンスがJVMの場合、このパターンは各JVMがソース・トピックに送信された各メッセージのコピーを取得することを保証します。次の項では、「インスタンスごとに1つのコピー」に基づいた設計パターンの開発について説明します。
分散アプリケーション/コンテナのインスタンスが、「インスタンスごとに1つのコピー」方式でDTに送信されるメッセージを受信するためには、各インスタンスが次を実行する必要があります。
ClientIDと、すべての恒久サブスクライバによって共有される恒久サブスクリプション名を選択します。サブスクリプション名は、使用するアプリケーション・インスタンスを一意に識別します。たとえば、各インスタンスが異なる名前のWebLogic Server JVM上で実行される場合、各インスタンスのサブスクリプション名はWebLogic Server名に基づく可能性があります。ClientIDは、当該インスタンスに対して一意の識別子によって付加される基本のClientIDに設定する必要があります。たとえば、アプリケーションまたはコンテナが実行中のWebLogic Server名またはサード・パーティのアプリケーション・サーバーを使用します。ClientIDPolicyをUnrestrictedに設定する必要があります。SubscriptionSharingPolicyをSharableに設定します。JMSDestinationAvailabilityHelperに登録します。onDestinationsAvailable()通知の受信時に、リスト中の新しく利用可能になった各宛先上でサブスクライバを作成します。DTがレプリケートされたDTの場合、サブスクライバはNOT JMS_WL_DDForwardedセレクタまたは(NOT JMS_WL_DDForwarded) AND接頭辞を既存アプリケーションが指定したセレクタに使用する必要があります。onDestinationsUnavailable()通知の受信時に、対応するconsumer()を終了します。アプリケーションは可能なかぎり、UDTをホストする同じサーバー、サーバー・グループまたはクラスタにデプロイしてください。この構成では、ローカル・メンバーでのみコンシューマを作成する点を除いて、アプリケーションが「「インスタンスごとに1つのコピー」の一般的パターン設計方針」と同じ手順に従う必要があります。JMSDestinationAvailabilityHelper.DestinationDetail.isLocalWLSServer()呼出しを使用して、メンバーがローカルかどうかを判定できます。
「アプリケーションごとに1つのコピー」のパターンは、アプリケーションが複数のJVM全体でクラスタ化されている場合でも、アプリケーションがトピックに送信される各メッセージのコピーを1つ受信することを保証します。たとえば、メッセージ「A」、「B」、および「C」がトピックに送信される場合、アプリケーション・インスタンスごとに1つのコピーを取得するかわりに、メッセージはアプリケーションによって1回処理されます。
次の項では、「アプリケーションごとに1つのコピー」に基づいた設計パターンの開発について説明します。
分散アプリケーション/コンテナのインスタンスが、「アプリケーションごとに1つのコピー」方式でDTに送信されるメッセージを受信するためには、各インスタンスが次を実行する必要があります。
ClientIDと、すべての恒久サブスクライバの恒久サブスクリプション名を選択します。サブスクリプション名は、使用するアプリケーション・インスタンスを一意に識別します。たとえば、各インスタンスが異なる名前のWebLogic Server JVM上で実行される場合、各インスタンスのサブスクリプション名はWebLogic Server名に基づく可能性があります。ClientIDを基本のClientIDに設定する必要があります。ClientIDPolicyをUnrestrictedに設定する必要があります。SubscriptionSharingPolicyをSharableに設定します。JMSDestinationAvailabilityHelperに登録します。onDestinationsAvailable()通知の受信時に、リスト中の新しく利用可能になった各宛先上でサブスクライバを作成します。DTがレプリケートされたDTの場合、サブスクライバはNOT JMS_WL_DDForwardedセレクタまたは(NOT JMS_WL_DDForwarded) AND接頭辞を既存アプリケーションが指定したセレクタに使用する必要があります。アプリケーションは可能なかぎり、UDTをホストする同じサーバー、サーバー・グループまたはクラスタにデプロイしてください。この構成では、ローカル・メンバーでのみコンシューマを作成する点を除いて、アプリケーションが「「アプリケーションごとに1つのコピー」の一般的パターン設計方針」と同じ手順に従う必要があります。JMSDestinationAvailabilityHelper.DestinationDetail.isLocalWLSServer()呼出しを使用して、メンバーがローカルかどうかを判定できます。
