ヘッダーをスキップ
Oracle® Fusion Middleware Oracle WebLogic Server JMSのプログラミング
12cリリース(12.1.1)
B65902-02
  ドキュメント・ライブラリへ移動
ライブラリ
製品リストへ移動
製品
目次へ移動
目次

前
 
 

D JMS宛先の可用性ヘルパーAPIを使用した分散宛先に関する拡張プログラミング

この章では、クラスタ環境でJMS分散宛先の使用時に、高可用性(HA)、スケーラビリティ、および柔軟性を提供する分散アプリケーションまたはコンテナを設計する方法について説明します。


重要:

このガイドには、経験豊富なJMS開発者向けの高度な情報が記載されています。分散宛先と相互運用する際はメッセージドリブンBeanを使用することをお薦めします。MDBコンテナは、分散宛先のすべてのメンバー間で内部コンシューマを必要に応じて自動的に作成して閉じます。また、セキュリティ、スレッド化、プーリング、アプリケーション・ライフサイクル、自動再接続、トランザクションのリスト化も処理します。MDBを使用できない場合、より簡単な回避策(分散宛先でコンシューマをリバランスするようにコンシューマを定期的に再起動したり、メッセージの順序付けやパフォーマンスを気にしない場合は、分散キューの転送オプションを有効にしたりするなど)も検討できます。


はじめに

分散宛先(DD)は、単一の論理宛先(キューまたはトピックのグループ)としてアクセスされるJMS物理宛先のグループです。メッセージはメンバー間でロード・バランシングされ、クライアントはメンバー宛先間でフェイルオーバーできます。

MDBを利用しない分散宛先ユーザーの場合、コンシューマ・アプリケーションに関する問題が生じることがあります。たとえば、次のような問題があります。

このような使用の問題を解決するため、WebLogic Serverは、「拡張パブリッシュ/サブスクライブ・アプリクーションの開発」で示されるように、JMS宛先高可用性ヘルパーAPIおよび拡張トピック機能を提供します。

DDプロデューサ・ロード・バランシングの制御

コンシューマ・ロード・バランシングについて説明する前に、プロデューサ・ロード・バランシングの基本事項とベスト・プラクティスを最初に確認しておくと便利です。

基本のJMS

JMSプログラムは、次の3つの段階でメッセージ送信を設定します。

  1. クライアントは、JMS接続ファクトリを使用してWebLogicへのJMS接続を作成します。

  2. クライアントはこの接続を使用して、JMSのセッションとセンダーを作成します。

  3. クライアントは、このセンダーを使用してメッセージを送信します。

WebLogic JMSでは、クライアントが接続するWebLogicサーバーはクライアントの接続ホストと呼ばれ、メッセージは常にセンダーからその接続ホストを介して、接続ホストと同じクラスタ内の宛先にルーティングします。接続は、その有効期間中は接続ホストに固定されます。

WebLogic接続ファクトリは、1つ以上のWebLogicサーバーでターゲット指定できます。接続ファクトリがターゲット指定される同じWebLogicサーバーでクライアントが実行している場合、ファクトリは常に、クライアントと同じサーバーの接続ホスト(接続はローカル)で接続を返します。一方で、接続ファクトリのターゲットに含まれるWebLogicサーバーでクライアントが実行していない場合、ファクトリはターゲット間で自動的にロード・バランシングして、そのいずれかに接続を返します。

センダーが分散宛先で機能する場合、各メンバーのJNDI名に送信するのではなく、DQまたはPDTのJNDI名(その論理名)に常に送信します。これにより、ロード・バランシング動作の自動化が可能になります。

分散キュー(DQ)およびパーティション化された分散トピック(PDT)へのセンダー

DQまたはPDTに対するセンダーのデフォルト動作では、メンバーがセンダーの接続ホストで実行する場合、すべての送信メッセージはいずれかのローカル・メンバーに送信されます。それ以外の場合、メッセージはすべてのメンバー間でラウンドロビンします。

ローカル・メンバーがセンダーの接続ホストに存在する場合でも、同じDQまたはPDTセンダーのメッセージをすべてのアクティブなメンバー間でラウンドロビンするようにするには、Server Affinityfalseに、Load Balancetrueに設定してカスタム接続ファクトリを使用します。

レプリケートされた分散トピック(RDT)へのセンダー

RDTへのセンダーは、常にロード・バランシングを1回実行し、次にすべてのメッセージの特定のメンバーに固定します。このメンバーが「センダー・ホスト」になります。メッセージがセンダー・ホストに着信すると、メッセージはすべてのRDTメンバー上にあるすべてのサブスクリプションに自動的に複製されます。

センダー・ホストに対する初期ロード・バランシング判定が、接続ホストへの判定と同じ扱いにならないように制御する場合、false (デフォルトはtrue)に構成された「サーバー・アフィニティ」およびtrue (デフォルト)に構成された「ロード・バランシング」と共に接続ファクトリを使用します。

JMS宛先可用性ヘルパーAPIの使用

次の項では、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を使用するアプリケーションは、次の一般的なステップに従います。

  1. 下記のステップ3の動作を実現するため、weblogic.jms.extensions.DestinationAvailableListenerインタフェースを実装します。

  2. 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
    )
    
  3. リスナー・コールバックを処理します。各リスナー・インスタンスに対するコールバックは単一のスレッドがあり、これにより、2つのコールバックが同時に発生することはあります。

    1. onDestinationsAvailable() - 通常は最初の通知。このコールバックの実装は、指定の各宛先でゼロ以上のコンシューマを作成すると反応するのが一般的です。これが失敗した場合、定期的に再試行します。

    2. onDestinationsUnavailable() - このコールバックは、通常、宛先で既存のコンシューマを破棄する場合に使用されます。

    3. onFailure() - このコールバックは、通常、生じた失敗のログを記録する場合に使用されます。ヘルパーは引き続き内部で再試行し、以降のコールバックを行いますが、管理者は失敗を確認する必要があります。ヘルパーは、最善を尽くして、繰り返される同じ失敗に対してonFailure()を一度呼び出します。

  4. 完了したら、rh.unregister()を呼び出して宛先の関連事項の登録を解除します。

weblogic.jms.extension.DestinationDetailの処理

前述のように、onDestinationsAvailable()通知は、スタンドアロンの宛先、外部宛先、分散宛先のメンバーが使用可能になることを示します。通知はDestinationDetailインスタンスのリストで構成され、キー情報は各DetailでgetDestinationType()getJNDIName()isLocalWLSServer()isLocalCluster()を呼び出すことで取得されます。

宛先の詳細は、呼出し元が行うアクションの決定に役立ちます。宛先のタイプがDD_QUEUEREPLICATED_DTまたはPARTITIONED_DTの場合、詳細のgetJNDIName()メソッドにより、特定のDDメンバーのJNDI名が返されます。呼出し元はアプリケーション・コンシューマのインスタンスをメンバーにデプロイする場合としない場合があります。宛先のタイプがPHYSICALまたはFOREIGNの場合、アプリケーションは宛先を通常の宛先として扱います。

特にDDで使用する場合、DestinationDetailのコロケーション・フラグを利用することを強くお薦めします。宛先のコロケーションの性質を判断するには、isLocalWLSServer()isLocalCluster()を呼び出します。「ローカル・サーバー・コンシューマのベスト・プラクティス」を参照してください。

APIとそのメソッドの詳細は、Oracle WebLogic Server APIリファレンスDestinationDetailに関する項を参照してください。

コンシューマ・コンテナのベスト・プラクティス

次の項では、コンシューマ・コンテナのベスト・プラクティスのガイドラインを示します。

登録と登録解除のタイミング

  1. アプリケーションのデプロイメント時にJMSDestinationAvailabilityHelperに登録します。ヘルパーがリスナーでonFailure()コールバックを呼び出す場合、デプロイメントを失敗しないでください(断続的な失敗になると想定されます)。

  2. アプリケーションのアンデプロイメント時にJMSDestinationAvailabilityHelperへの登録を解除します。

URLの処理

  1. クライアントが宛先と同じサーバーまたは同じクラスタで実行している場合、ヘルパーへの登録やJNDIコンテキストの作成時にURLを指定しないでください。これにより、ヘルパーは確実にローカル・コンテキストを作成します。

  2. isLocalCluster()またはisLocalServer()trueを返しても、URLを指定した場合(この場合URLは不要)、1つの警告ログと見なします。

失敗の処理

  1. onFailure()通知で報告されるエラーのログを記録するため、アプリケーションの開発者は、構成/アプリケーションのエラーを修正することができます。同じ例外のログを繰り返し記録することは避けてください。ヘルパーは引き続き内部で再試行し、成功または異なるタイプの失敗に対して以降のコールバックを行いますが、管理者は失敗を確認する必要があります。エラーは、不正なURL、無効なセキュリティ情報、存在しない宛先などのアプリケーションまたは管理上のエラーが原因で発生します。また、JNDIコンテキストのホストまたは宛先が一時的に使用不可になる場合にも発生します。

  2. JMS呼出しが例外をスローするか、JMS接続例外リスナーが接続の失敗を報告した場合、接続を閉じます。すべてのリソースの誤りが修正されたら、すべてのリソースを定期的に再初期化します。再初期化には、通常、コンテキストの作成、JNDIルックアップの実行、接続、セッション、コンシューマの作成が必要です。

  3. 失敗後すぐに再試行することは避けてください。かわりに数秒ごとに定期的に再試行して、サーバーがオーバーロードしないようにします。

JNDIコンテキストの処理

  1. 通常、同一のサーバーまたはクラスタに対して複数のJNDI初期コンテキスト・インスタンスを作成しないようにします。


    注意:

    特にドメイン間シナリオなどの一部のセキュリティ問題を解決するには、追加のコンテキスト・インスタンスを使用する必要があります。


  2. アンデプロイ時にコンテキストでclose()を呼び出して、メモリー・リークを防止します。

  3. コンテキストでclose()を呼び出して、失敗時(ルックアップの失敗を含む)に再作成します。

JMS接続の処理

  1. JMS接続の場合、標準のJMS接続「例外リスナー」を必ず登録します。

  2. onException()で接続を閉じてJNDIルックアップを定期的に再試行し、JMS接続を再作成して別のスレッドでコンシューマを設定します。

  3. アンデプロイ時に接続を閉じて、メモリー・リークを防止します。

  4. 複数のセッション間でWebLogic Server接続を共有するのではなく、セッションにつき1つの接続を作成することを検討します。WebLogic Serverでは、複数の接続によりロード・バランシング機能が向上します。WebLogic Serverを使用する場合、パフォーマンス・ペナルティはありませんが、一部の外部ベンダーは接続ごとにTCP/IPソケットや同様の高価なリソースを作成するため、外部ベンダーによる予想外のオーバーヘッドが生じる場合があります。

相互運用性ガイドライン

Oracle WebLogic Server APIリファレンス「JMSDestinationAvailabilityHelper」には、使用可能な各種メソッドの使用法や動作に関する詳細があります(次の項で説明する相互運用性ガイドラインに関する詳細を含む)。

APIの可用性

パブリックJMS宛先可用性ヘルパーAPIは、AS11gR1PS2(WebLogic Serverバージョン10.3.3)以降のクライアントとサーバーで利用できます。

外部コンテキスト

DAヘルパーに通知リスナーを登録する際に指定するコンテキスト・プロパティは、外部ベンダーや旧バージョンのWebLogic Serverのコンテキストを含む有効なJNDIコンテキストに解決できます。

外部(WebLogic以外の)コンテキストの場合、外部JNDIベンダーのクラスは現在のクラスパス内に存在する必要があります。また、Context.INITIAL_CONTEXT_FACTORYプロパティは、外部ベンダーのJNDIコンテキスト・ファクトリのクラス名を参照する必要があります。

宛先タイプのサポート

JMSDestinationAvailabilityHelper APIは、JNDIコンテキストに登録できるどのタイプの宛先(非分散宛先、外部ベンダーの宛先など)でも機能します。ただし、使用不可の通知は、DDメンバーに対してのみ生成され、DestinationDetailの特定のフィールドはDDメンバーにのみ適用されます。使用不可の通知は、外部宛先には適用されません。

使用不可の通知

使用不可の通知は、DDタイプの宛先にのみ適用されます(DQ_QUEUE、PARTITIONED_DT、REPLICATED_DT)。

WebLogic Server 9.0以前の分散キューとの相互運用

DAヘルパーがWebLogic Server 9.0以降のDDと相互運用する場合、DDのメンバーごとに通知が生成されますが、9.0以前のバージョンと使用する場合、DD宛先の論理JNDI名を含む単一のDestinationDetail通知のみが生成され、getDestinationType()PHYSICALを返します。

WebLogic Server 9.0以前のDDは、通常の宛先として扱われることが多いため、「レプリケートされた分散トピック使用時のアプリケーション設計制限」で説明した概略と同様の制限を持つことになります。

WebLogic Server 10.3.4.0以前の分散トピックとの相互運用

WebLogic Server 10.3.4以前のリリースでは、無制限の(非排他的な)client-idまたは共有サブスクリプションを有効化する機能がありません。


注意:

無制限ClientIDおよび共有サブスクリプションを有効化する方法の詳細は、『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つのみ存在できます)。

DestinationDetailのフィールド

一部の宛先詳細フィールドの動作は、宛先のタイプ、JMSベンダー、WebLogic JMS動作時のWebLogic Serverバージョンに基づいて変わります。Oracle WebLogic Server APIリファレンス「JMSDestinationAvailabilityHelper」を参照してください。

セキュリティの考慮事項

次の項では、Java EEおよびWebLogic Serverセキュリティ・モデルを使用したセキュリティの実施について説明します。

WebLogic Serverセキュリティ・モデル

WebLogic資格証明の伝播は、多くの場合、スレッドを基準に実行されます。現在のスレッド資格証明は、JNDIコンテキストまたはアプリケーション記述子の作成時に指定することによって確立されます。このような資格証明は、WebLogic JMS呼出しを含むJVM間のRMIベースの呼出しと共に自動的に伝播されます。

スレッド間の資格証明の受渡し

コンテキスト・インスタンスが異なるスレッドに渡されてそこで使用される場合、JNDIコンテキストに関連付けられる件名は失われます。これによって、一部のマルチ・ドメイン・アプリケーション・シナリオでセキュリティ問題が起こる可能性があります。次の項では、資格証明の受渡しに関するメソッドを説明します。

同一スレッドの使用

可能な場合、コンテキスト作成のために同一スレッドを使用して問題の発生を避け、すべてのJMSおよびJNDI操作を実行してコンテキストを閉じます。

匿名ユーザーとして渡す

JMS宛先とJNDIリソースが保護されていない場合、匿名の件名を使用します。特に、複数のWebLogicドメイン間で相互運用するとき、JMS宛先とJNDIリソースが保護されていない場合には、通常、すべての呼出しが匿名の件名を使用するように強制することが最も簡単な方法となります。非匿名資格証明情報は通常、特定のドメインに対してのみ有効で、異なるドメインを使用するように試行を実行する場合、セキュリティの例外が発生することに繋がります。

匿名ユーザーとして渡す

JMS宛先とJNDIリソースが保護されていない場合、匿名の件名を使用します。特に、複数のWebLogicドメイン間で相互運用するとき、JMS宛先とJNDIリソースが保護されていない場合には、通常、すべての呼出しが匿名の件名を使用するように強制することが最も簡単な方法となります。非匿名資格証明情報は通常、特定のドメインに対してのみ有効で、異なるドメインを使用するように試行を実行する場合、セキュリティの例外が発生することに繋がります。

次のコードでは、件名をキャッシュし、匿名ユーザーを使用して別のスレッドに関連付ける方法の例を示します。

import java.security.PrivilegedExceptionAction;
import java.security.PrivilegedActionException;
 
import weblogic.security.subject.AbstractSubject;
import weblogic.security.SubjectUtils;
import weblogic.security.Security;
 
class MyClass {
 
  void doSomethingAsAnonymous() {

 
     // get the anonymous user
     AbstractSubject anon = SubjectUtils.getAnonymousSubject();

 
     // run some operation as the anonymous user
     try {
       Security.runAs(anon.getSubject(),
         new java.security.PrivilegedExceptionAction() {
           public Object run()  throws Exception {
             //  do something;
             return null; // or return some Object
       }});
     } catch (PrivilegedActionException e) {
        //  handle exception
     }
  }
}
初期コンテキストからの件名のキャッシュと再利用

次のコードでは、件名をキャッシュし、匿名ユーザーを使用して別のスレッドに関連付ける方法の例を示します。

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アクセス時のユーザー名とパスワードを説明します。

JNDIコンテキストへの資格証明の指定

JMSリソースにアクセスするためには、アプリケーションがJNDIプロバイダへのアクセス権を持つ必要があります。資格証明は、アプリケーション・コードがJNDIプロバイダへの初期コンテキストを作成するときに提供されます。初期コンテキストを確立するスレッドが件名を送信するため、すべてのサブシーケンス操作に使用されます。初期コンテキストの作成中にアプリケーションがWebLogic Server上で実行されていて、サーバーURLおよびセキュリティ資格証明が提供されない場合、スレッドは書きコンテキスト作成前にスレッド上にあった同一の資格証明を引き続き所持します。初期コンテキストを作成するスレッドがコンテキストを閉じるとき、スレッドは最初にコンテキスト作成前のスレッド上にある元のセキュリティ資格証明を再開します。

JMS接続への資格証明の指定

ConnectionFactory.createConnection()呼出しは、任意でユーザー名とパスワードをサポートします。接続作成時に提供される資格証明は、作成される接続上の任意のJMS操作のセキュリティに関する影響がありません(これは、WebLogic JMS Javaクライアント用のWebLogic JMS固有の動作で、.NETクライアントの例外があります)。資格証明は、接続が作成されるドメインでユーザーが有効なユーザーかどうかを確認するためにのみ使用されます。

外部JMSサーバーJNDIコンテキストの資格証明の使用

JNDIプロパティを持つ外部JMSサーバー・インスタンスを構成してJNDIプロバイダへのアクセス権を取得します。JNDIプロパティには、セキュリティ・プリンシパルと資格証明設定用のオプションが含まれます。

外部JMSサーバー接続の資格証明の使用

ユーザー名およびパスワードは、JMS接続ファクトリを参照するためにEJBまたはサーブレット・リソース・リファレンスを使用しない場合に、外部接続ファクトリ・マッピングの構成が無視されるときに指定できます。「プーリングを使用したパフォーマンスの向上」を参照してください。

宛先の保護

WebLogic JMSは、ACLを宛先に指定するための機能を提供します。この機能を使用すると宛先を保護でき、認可されたユーザーのみが宛先上で操作を実行できるようになります。『Oracle WebLogic Serverロールおよびポリシーを使用したリソースの保護』のJava Messaging Service (JMS)リソースに関する項を参照してください。

ワイヤー・データの保護

アプリケーションがワイヤー上に受け渡されるJMSデータを保護する必要があるとき、ネットワークがSSLを使用するように構成します。『Oracle WebLogic Serverの保護』のSSLの構成に関する項を参照してください。

トランザクションについて

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インスタンスのリストを取得します。その後、リストのメンバー宛先ごとに、メンバー宛先に対して以前に作成されたコンシューマを探し、そのコンシューマを閉じます。

ローカル・サーバー・コンシューマのベスト・プラクティス

アプリケーションがJMS分散宛先と同じクラスタにデプロイされる場合、可能なかぎり、UDQをホストする同じセットのサーバーにアプリケーションをデプロイする必要があります。この構成のベスト・プラクティスとして、アプリケーションはローカル・メンバーからのメッセージのみを受け取り、DestinationDetail isLocalWLSCluster()呼出しとisLocalWLSServer()呼出しを使用してローカル・メンバーを決定できます。この方法では、すべてのメッセージがローカルになり(ネットワーク呼出しでメッセージが転送されない)、すべてのメンバーがコンシューマで処理されるため、パフォーマンスが向上します。

一部の使用事例では、バランスの取れていないキューの負荷に関して、ローカル・サーバーの最適化ネットワークを節約するよりも、クラスタのすべてのJVM間でメッセージ処理を分散するメリットの方が上回ります。これは特に、メッセージのバックログがクラスタ全体で不規則に生じ、メッセージ処理に費用がかかる場合に関連します。このような使用事例では、リモート・コンシューマに対して一般的な戦略モデルを支持して最適化を回避してください。

共通分散トピックに関するサブスクライバ用の方針


注意:

レプリケートされた分散トピックおよびパーティション化された分散トピックを使用する拡張メッセージ分散モードを実装するためにMDBを使用することをお薦めします。MDBを使用する拡張パブリッシュ/サブスクライブ・アプリケーション設計の詳細は、『Oracle WebLogic ServerメッセージドリブンBeanのプログラミング』拡張パブリッシュ/サブスクライブ・アプリケーションの開発および分散トピックを使用したMDBの構成とデプロイに関する項を参照してください。


UDTからメッセージを処理するすべてのクラスタ・アプリケーションおよび分散アプリケーションの場合、次の設定と組み合せて10.3.4以降のトピックを使用することをお薦めします。

WebLogic JMSには2種類の共通分散トピックがあります。

次の項では、RDTおよびPDT使用時の構成要件とプログラミング・パターンを説明します。

インスタンスごとに1つのコピー

「インスタンスごとに1つのコピー」のパターンは、各インスタンスがトピックにパブリッシュされる各メッセージのコピーを取得することを保証します。たとえば、各インスタンスがJVMの場合、このパターンは各JVMがソース・トピックに送信された各メッセージのコピーを取得することを保証します。次の項では、「インスタンスごとに1つのコピー」に基づいた設計パターンの開発について説明します。

「インスタンスごとに1つのコピー」の一般的パターン設計方針

分散アプリケーション/コンテナのインスタンスが、「インスタンスごとに1つのコピー」方式でDTに送信されるメッセージを受信するためには、各インスタンスが次を実行する必要があります。

  1. すべての接続によって共有される基本のClientIDと、すべての恒久サブスクライバによって共有される恒久サブスクリプション名を選択します。サブスクリプション名は、使用するアプリケーション・インスタンスを一意に識別します。たとえば、各インスタンスが異なる名前のWebLogic Server JVM上で実行される場合、各インスタンスのサブスクリプション名はWebLogic Server名に基づく可能性があります。

  2. JMS接続およびセッションを標準JMS仕様に従って作成します。接続のClientIDは、当該インスタンスに対して一意の識別子によって付加される基本のClientIDに設定する必要があります。たとえば、アプリケーションまたはコンテナが実行中のWebLogic Server名またはサード・パーティのアプリケーション・サーバーを使用します。ClientIDPolicyUnrestrictedに設定する必要があります。

  3. SubscriptionSharingPolicySharableに設定します。

  4. JNDI名またはDTを指定し、メンバーシップ可用性通知のJMSDestinationAvailabilityHelperに登録します。

  5. 例外リスナーを設定します。

  6. onDestinationsAvailable()通知の受信時に、リスト中の新しく利用可能になった各宛先上でサブスクライバを作成します。DTがレプリケートされたDTの場合、サブスクライバはNOT JMS_WL_DDForwardedセレクタまたは(NOT JMS_WL_DDForwarded) AND接頭辞を既存アプリケーションが指定したセレクタに使用する必要があります。

  7. onDestinationsUnavailable()通知の受信時に、対応するconsumer()を終了します。

「インスタンスごとに1つのコピー」を使用したローカル・サーバー・コンシューマ向けベスト・プラクティス

アプリケーションがUDTと同じクラスタにデプロイされる場合、可能なかぎり、UDTをホストする同じセットのサーバーにアプリケーションをデプロイする必要があります。この構成に従い、すべてのローカル・メンバー上でのみコンシューマを作成する点を除き、アプリケーションはインスタンスごとに1つのコピー用の一般パターン・デザイン戦略に関する項で説明されている手順と同じ手順に従う必要があります。JMSDestinationAvailabilityHelper.DestinationDetail.isLocalWLSServer()呼出しを使用して、メンバーがローカルかどうかを判定できます。

アプリケーションごとに1つのコピー

「アプリケーションごとに1つのコピー」のパターンは、アプリケーションが複数のJVM全体でクラスタ化されている場合でも、アプリケーションがトピックに送信される各メッセージのコピーを1つ受信することを保証します。たとえば、メッセージ「A」、「B」、および「C」がトピックに送信される場合、アプリケーション・インスタンスごとに1つのコピーを取得するかわりに、メッセージはアプリケーションによって1回処理されます。

次の項では、「アプリケーションごとに1つのコピー」に基づいた設計パターンの開発について説明します。

「アプリケーションごとに1つのコピー」の一般的パターン設計方針

分散アプリケーション/コンテナのインスタンスが、「アプリケーションごとに1つのコピー」方式でDTに送信されるメッセージを受信するためには、各インスタンスが次を実行する必要があります。

  1. すべての接続の基本のClientIDと、すべての恒久サブスクライバの恒久サブスクリプション名を選択します。サブスクリプション名は、使用するアプリケーション・インスタンスを一意に識別します。たとえば、各インスタンスが異なる名前のWebLogic Server JVM上で実行される場合、各インスタンスのサブスクリプション名はWebLogic Server名に基づく可能性があります。

  2. JMS接続およびセッションを標準JMS仕様に従って作成します。接続のClientIDを基本のClientIDに設定する必要があります。ClientIDPolicyUnrestrictedに設定する必要があります。

  3. SubscriptionSharingPolicySharableに設定します。

  4. JNDI名またはDTを指定し、メンバーシップ可用性通知のJMSDestinationAvailabilityHelperに登録します。

  5. 例外リスナーを設定します。

  6. onDestinationsAvailable()通知の受信時に、リスト中の新しく利用可能になった各宛先上でサブスクライバを作成します。DTがレプリケートされたDTの場合、サブスクライバはNOT JMS_WL_DDForwardedセレクタまたは(NOT JMS_WL_DDForwarded) AND接頭辞を既存アプリケーションが指定したセレクタに使用する必要があります。

「アプリケーションごとに1つのコピー」を使用したローカル・サーバー・コンシューマ向けベスト・プラクティス

アプリケーションがUDTと同じクラスタにデプロイされる場合、可能なかぎり、UDTをホストする同じセットのサーバーにアプリケーションをデプロイする必要があります。この構成に従い、すべてのローカル・メンバー上でのみコンシューマを作成する点を除き、アプリケーションはアプリケーションごとに1つのコピー用の一般パターン・デザイン戦略に関する項で説明されている手順と同じ手順に従う必要があります。JMSDestinationAvailabilityHelper.DestinationDetail.isLocalWLSServer()呼出しを使用して、メンバーがローカルかどうかを判定できます。