ナビゲーションをスキップ.

eDocs ホーム > BEA WebLogic Server および WebLogic Express 8.1 ドキュメント > Administration Console オンライン ヘルプ > JMS: コンフィグレーション

Administration Console オンライン ヘルプ

  前 次 前/次ボタンと目次ボタンとの区切り線 目次

JMS: コンフィグレーション

[JMS に関する属性と Administration Console 画面のリファレンス]

以下の節では、WebLogic Server の Java Message Service (JMS) をコンフィグレーションする方法について説明します。

必要な場合は、以下の WebLogic JMS およびメッセージング ブリッジに関する節も参照してください。

 

JMS と WebLogic Server

JMS (Java Message Service) は、エンタープライズ メッセージング システムにアクセスするための標準 API です。WebLogic JMS を使用すると、以下のことが実現できます。

次の図は、WebLogic JMS メッセージングの仕組みを示しています。

図 48-1 WebLogic Server JMS メッセージング

WebLogic Server JMS メッセージング


 

図に示されているとおり、WebLogic JMS はプロデューサ アプリケーションからメッセージを受信し、受け取ったメッセージをコンシューマ アプリケーションに配信します。

WebLogic JMS のコンフィグレーション

Administration Console を使用して、コンフィグレーション属性を定義し、以下のことを行います。

WebLogic JMS では、一部のコンフィグレーション属性に対してデフォルト値が用意されていますが、それ以外のすべての属性に対しては値を指定する必要があります。コンフィグレーション属性に対して無効な値を指定した場合や、デフォルト値が存在しない属性に対して値を指定しなかった場合は、再起動時に JMS が起動されません。

Examples サーバには、サンプル コンフィグレーションとして examplesJMSServer が用意されています。 Examples サーバの起動の詳細については、『WebLogic Server のコンフィグレーションと管理』の「サーバの起動と停止 : クイック リファレンス」を参照してください。 基本的な JMS 実装をコンフィグレーションする手順については、『WebLogic JMS プログラマーズ ガイド』の「WebLogic Server の起動と JMS のコンフィグレーション」を参照してください。

『WebLogic JMS プログラマーズ ガイド』の「WebLogic JMS アプリケーションの移植」で説明されているように、WebLogic JMS アプリケーションを WebLogic Server の以前のリリースから移植する場合、コンフィグレーション情報は自動的に変換されます。

WebLogic JMS をコンフィグレーションしたら、アプリケーションで JMS API を使用してメッセージの送受信ができるようになります。 WebLogic JMS アプリケーションの開発の詳細については、『WebLogic JMS プログラマーズ ガイド』の「WebLogic JMS アプリケーションの開発」を参照してください。

ドメインの相互運用性を実現するための JMS リソースの命名規則

WebLogic ドメイン内では、各サーバ インスタンス、マシン、クラスタ、仮想ホスト、および他のすべてのタイプのリソースがユニークな名前を持つ必要があります。また、ドメイン名と同じ名前を使用することもできません。 ユニークな名前を持つという規則は、単一の WebLogic Server ドメインであるかマルチドメイン環境であるかに関係なく、すべての JMS リソースにも適用されます。

単一ドメイン環境の JMS リソースの命名規則

WebLogic JMS ドメイン内の相互運用性を実現するためには、スタンドアロンであるか、サーバ インスタンスがクラスタ化されているかに関係なく、リソースにはユニークな名前をつけるという規則をすべてのコンフィグレーション可能な JMS オブジェクト (JMS サーバ、ストア (ファイルまたは JDBC)、テンプレート、接続ファクトリ、セッション プール、接続コンシューマなど) に適用します。 たとえば、同じ名前を持つ 2 つの JMS サーバ (myJMSServer など) で、ドメイン内の 2 つの異なるサーバ インスタンスを対象とすることはできません。

JMS のクラスタ化の仕組みについて詳しくは、WebLogic JMS プログラマーズ ガイドの「WebLogic JMS のクラスタ化のコンフィグレーション」を参照してください。

ただし、このドメイン内ではユニークな名前をつけるという規則は、ドメイン内の別々の JMS サーバにある JMS キューおよびトピックの送り先には適用されません。この例外については、以下を参照してください。

マルチドメイン環境の JMS リソースの命名規則

JMS 接続ファクトリという例外を除き、WebLogic JMS リソースの単一ドメイン用の命名規則は、メッセージング ブリッジまたは外部 JMS サーバを使用して他の WebLogic ドメインにアクセスする、ドメイン間の相互運用性を実現するためにも適用されます。 この規則は、WebLogic Server の異なるリリースのドメインも対象としています。

たとえば、mydomain70 という名前のバージョン 7.0 ドメインに myserver というサーバ インスタンスがすでにある場合は、mydomain81 というバージョン 8.1 ドメインに myserver という WebLogic Server インスタンスを作成することはできません。 同様に、JMS のサブシステム レベルにおいて、別々のドメインにある場合であっても、名前が同じ 2 つの JMS サーバまたはストアを持つことはできません。

したがって、WebLogic ドメイン間の相互運用を行う際には以下の規則に従う必要があります。

WebLogic ドメインと相互運用するようにメッセージング ブリッジをコンフィグレーションする詳細については、異なるリリースの WebLogic Server およびドメインとの相互運用のためのメッセージング ブリッジの使用を参照してください。

外部 JMS サーバのコンフィグレーションの詳細については、リモートまたは外部 JMS プロバイダへの単純なアクセスを参照してください。

 

JMS サーバのタスク

JMS サーバは、クライアントに代わって接続とメッセージ要求を管理します。 [サービス｜JMS｜サーバ] ノードを使用して JMS サーバをコンフィグレーションし、JMS サーバのデプロイ先となる独立した WebLogic Server インスタンスまたは移行できる対象サーバに割り当てます。

JMS サーバのコンフィグレーション

送り先またはコンシューマをコンフィグレーションするには、あらかじめ JMS サーバをコンフィグレーションしておく必要があります。

  1. [JMS｜サーバ] ノードを展開します。 ドメインで定義されているすべての JMS サーバを示す [JMS サーバ] テーブルが右ペインに表示されます。
  2. [新しい JMS サーバのコンフィグレーション] テキスト リンクをクリックします。右ペインにダイアログが表示され、新しく作成する JMS サーバの設定に関連するタブが示されます。
  3. [コンフィグレーション｜一般] タブで、JMS サーバの一般的なコンフィグレーション属性を定義します。

    4. JMS サーバの [一般] タブにある属性の詳細については、[JMS サーバ] --> [コンフィグレーション] --> [一般]を参照してください。

  4. [作成] をクリックして、[名前] フィールドに指定した名前で JMS サーバ インスタンスを作成します。新しいインスタンスが左ペインの [サーバ] ノードの下に追加されます。[送り先] ノードと [セッション プール] ノードが新しいサーバ インスタンスの下にデフォルトで自動的に追加されます。
  5. [コンフィグレーション｜しきい値と割当] タブで、JMS サーバのメッセージ数またはバイト数の最大および最小しきい値と最大割り当てに関する以下の属性を指定します。

    6. [しきい値と割当] タブにある属性の詳細については、[JMS サーバ] --> [コンフィグレーション] --> [しきい値と割当]を参照してください。

  6. [適用] をクリックして変更を保存します。
  7. [対象とデプロイ] タブで、JMS サーバのデプロイ先となる独立した WebLogic Server または移行できる対象サーバを選択します。

    8. 詳細については、JMS サーバの割り当てとデプロイを参照してください。

  8. [適用] をクリックして JMS サーバを割り当てます。

JMS サーバの割り当てとデプロイ

JMS サーバは、デプロイ先となる独立した WebLogic Server インスタンスまたは移行できる対象サーバに割り当てることができます。接続ファクトリやテンプレートは、複数の WebLogic Server インスタンスで同時にインスタンス化されます。

  1. 左ペインの [JMS｜サーバ] ノードで、割り当てる JMS サーバ インスタンスのノードをクリックします。 右ペインにダイアログが表示され、このインスタンスに関連するタブが示されます。
  2. [対象とデプロイ] タブをクリックします。
  3. 以下のいずれかの手順に従って、独立したサーバまたは移行できる対象サーバのいずれかに割り当てます。
  4. [適用] をクリックして割り当てを保存します。

JMS サーバのモニタ

JMS の [モニタ] タブでは、アクティブな JMS サーバ、送り先、およびセッション プールの実行時情報の統計をモニタできます。

  1. [JMS] ノードを展開します。
  2. [サーバ] ノードをクリックします。 ドメインで定義されているすべての JMS サーバを示す [JMS サーバ] 情報が右ペインに表示されます。
  3. JMS サーバ リストまたは右ペインの [JMS サーバ] テーブルから、モニタする JMS サーバをクリックします。
  4. [モニタ] タブをクリックすると、JMS サーバ データをモニタするためのリンクが表示されます。

JMS オブジェクトのモニタの詳細については、JMS : モニタを参照してください。

 

JMS 接続ファクトリのタスク

接続ファクトリは、JMS クライアントが JMS 接続を作成するためのオブジェクトです。接続ファクトリでは同時使用がサポートされており、複数のスレッドがオブジェクトに同時にアクセスできます。 WebLogic JMS には、サーバ単位で有効/無効を切り替えられるコンフィグレーション済みの「デフォルト接続ファクトリ」が用意されています (詳細についてはデフォルト接続ファクトリの使い方を参照)。 また、1 つまたは複数の接続ファクトリを定義およびコンフィグレーションし、アプリケーションにより適合する定義済みの属性を使用して接続を作成することもできます。ただし、各接続ファクトリにはユニークな名前を付ける必要があります。WebLogic Server では、起動時に接続ファクトリが JNDI スペースに追加され、アプリケーションは WebLogic JNDI を使用して接続ファクトリを取得します。

クラスタ内のあらゆるサーバから JMS 送り先へのクラスタワイドで透過的なアクセスを確立するには、各サーバ インスタンスにデフォルト接続ファクトリを使用するか、クラスタ内の 1 つまたは複数のサーバ インスタンスを対象とする 1 つまたは複数の接続ファクトリをコンフィグレーションします。 これにより、各接続ファクトリを複数の WebLogic Server にデプロイできます。 JMS のクラスタ化のコンフィグレーションについては、『WebLogic JMS プログラマーズ ガイド』の「WebLogic JMS の管理」を参照してください。

デフォルト接続ファクトリの使い方

WebLogic JMS は、次の JNDI 名を使用してルックアップできる、2 つのデフォルト接続ファクトリを定義します。

新しい接続ファクトリのコンフィグレーションは、デフォルト接続ファクトリのコンフィグレーション済み設定がアプリケーションに適さない場合にのみ行います。 デフォルト接続ファクトリのコンフィグレーション済み設定とユーザ定義の接続ファクトリの主な違いは、次の表に示すように、JTA トランザクションを有効にするための [XA コネクション ファクトリを有効化] 属性のデフォルト値です。

表 48-2 トランザクション セッション (XA) 用のデフォルト接続ファクトリ設定

デフォルト接続ファクトリ

XAConnectionFactoryEnabled の設定

weblogic.jms.ConnectionFactory

False

weblogic.jms.XAConnectionFactory

True

XA ファクトリは、JMS アプリケーションが JTA ユーザ トランザクションを使用する際に必要となるもので、トランザクション セッションでは必要ありません。 WebLogic JMS によるトランザクションの使用については、『WebLogic JMS プログラマーズ ガイド』の「WebLogic JMS によるトランザクションの使い方」を参照してください。

その他のすべてのデフォルト コンフィグレーション属性は、ユーザ定義のファクトリと同じデフォルト値に設定されます。 [XA コネクション ファクトリを有効化] 属性の詳細、およびその他の接続ファクトリ属性のデフォルト値については、JMS に関する属性と Administration Console 画面のリファレンスを参照してください。

デフォルトの接続ファクトリを使用する場合のもう 1 つの違いは、接続ファクトリがデプロイされる可能性のある WebLogic Server を限定できない点です。 ただし、WebLogic Server 単位でデフォルト接続ファクトリを有効/無効を切り替えることはできます。

注意: 接続ファクトリの属性の中には、動的にコンフィグレーションできるものもあります。動的な属性が実行時に変更された場合、新しく設定された値は新規接続に対してのみ有効になります。既存の接続の動作には影響しません。

JMS 接続ファクトリのコンフィグレーション

[サービス｜JMS｜接続ファクトリ] ノードを使用すると、1 つまたは複数の接続ファクトリをコンフィグレーションして定義済みの属性で接続を作成できます。

  1. [JMS｜接続ファクトリ] ノードを展開します。 ドメインで定義されているすべての接続ファクトリを示す [JMS 接続ファクトリ] テーブルが右ペインに表示されます。
  2. [新しい JMS 接続ファクトリのコンフィグレーション] テキスト リンクをクリックします。右ペインにダイアログが表示され、新しく作成する接続ファクトリの設定に関連するタブが示されます。
  3. [コンフィグレーション｜一般] タブで、接続ファクトリの一般的なコンフィグレーション属性を定義します。

    4. 接続ファクトリの [一般] タブにある属性の詳細については、[JMS 接続ファクトリ] --> [コンフィグレーション] --> [一般]を参照してください。

  4. [作成] をクリックして、[名前] フィールドで指定した名前の接続ファクトリ インスタンスを作成します。新しいインスタンスが左ペインの [接続ファクトリ] ノードの下に追加されます。
  5. [コンフィグレーション｜トランザクション] タブで、トランザクション タイムアウト属性の値を定義し、[XA 接続ファクトリを有効化] フィールドを使用して、トランザクション キューまたはトピック接続ファクトリが返されるかどうか、および接続ファクトリによって JTA 対応セッションが作成されるかどうかを指定します。

    6. 注意: [ユーザ トランザクションを有効化] および [サーバサイド XA を有効化] フィールドは、WebLogic Server 8.1 では非推奨になりました。

    接続ファクトリ トランザクション属性の詳細については、「[JMS 接続ファクトリ] --> [コンフィグレーション] --> [トランザクション]」を参照してください。

  6. [適用] をクリックして変更を保存します。
  7. [コンフィグレーション｜フロー制御] タブで、メッセージ プロデューサがメッセージ フローを調整するための値を定義します。 具体的には、プロデューサはフローを最小値から最大値までの範囲内に制限する属性を受信します。 プロデューサは、条件が悪くなると最小値側に移動し、改善されると最大値側に移動します。[送信タイムアウト] 属性を使用して、送信しようとするメッセージを格納するための十分な割り当てが JMS サーバと送り先にできるまでプロデューサが待機する最長時間を指定します。

    8. 接続ファクトリの [フロー制御] タブにある属性の詳細については、[JMS 接続ファクトリ] --> [コンフィグレーション] --> [フロー制御]を参照してください。

  8. [適用] をクリックして変更を保存します。
  9. [対象とデプロイ] タブで、WebLogic Server インスタンスまたはサーバ クラスタに接続ファクトリを割り当てます。対象を指定することで、接続ファクトリのデプロイ先となるサーバ、グループ、およびクラスタのセットを制限できます。

    10. 詳細については、接続ファクトリの複数のサーバへのデプロイおよび接続ファクトリのクラスタへのデプロイを参照してください。

  10. [適用] をクリックして変更を保存します。

接続ファクトリの複数のサーバへのデプロイ

複数の WebLogic Server インスタンスに対して 1 つまたは複数の接続ファクトリを同時にデプロイすることで、ドメイン内のあらゆるサーバから JMS 送り先へのクラスタワイドで透過的なアクセスを確立できます。

  1. [JMS｜接続ファクトリ] ノードを展開し、デプロイする接続ファクトリを選択します。 右ペインにダイアログが表示され、このインスタンスに関連するタブが示されます。
  2. [対象とデプロイ] タブをクリックします。 [独立したサーバ] ボックスに、ドメイン内のすべてのサーバ インスタンスが表示されます。接続ファクトリが割り当てられている各サーバの横にはチェック マークが表示されます。
  3. リスト内の 1 つまたは複数のサーバに接続ファクトリをデプロイするには、各サーバ名の横のチェック ボックスをチェックします。
  4. 必要な場合は、各サーバ名の横のチェック ボックスからチェックをはずして、個々のサーバから接続ファクトリをアンデプロイできます。
  5. [適用] をクリックして割り当てを保存します。

接続ファクトリのクラスタへのデプロイ

クラスタ化環境では、クラスタ内のすべてのサーバ インスタンスまたは特定のサーバに対して接続ファクトリをデプロイすることで、クラスタ内のあらゆるサーバから JMS 送り先へのクラスタワイドで透過的なアクセスを確立できます。

  1. [JMS｜接続ファクトリ] ノードを展開し、デプロイする接続ファクトリを選択します。 右ペインにダイアログが表示され、このインスタンスに関連するタブが示されます。
  2. [対象とデプロイ] タブをクリックします。[クラスタ] ボックスに、ドメイン内でコンフィグレーションされているすべてのクラスタが表示されます。接続ファクトリが割り当てられている各クラスタ名の横にはチェック マークが表示されます。
  3. 接続ファクトリは、クラスタ内のすべてのサーバか、または選択したサーバに対して割り当てることができます。
  4. 必要な場合は、次の手順に従って、クラスタ全体またはクラスタ内の選択したサーバから接続ファクトリをアンデプロイできます。
  5. [適用] をクリックして割り当てを保存します。

 

JMS キューおよびトピック送り先のタスク

JMS サーバの送り先では、キュー (ポイント ツー ポイント) またはトピック (パブリッシュ/サブスクライブ) が識別されます。JMS サーバをコンフィグレーションしたら、各 JMS サーバに対して 1 つまたは複数のキューまたはトピック送り先をコンフィグレーションします。

送り先は、明示的にコンフィグレーションすることも、送り先テンプレートを使用してコンフィグレーションすることもできます。送り先テンプレートを使用すると、似た属性値を持つ複数の送り先を定義できます (JMS テンプレートのタスクを参照)。

クラスタ内の単一の分散送り先のメンバーとして、複数の物理な的送り先をコンフィグレーションすることができます。このため、クラスタ内で 1 つの WebLogic Server インスタンスがダウンしても、同じ分散送り先をホストする他のインスタンスから JMS プロデューサおよびコンシューマに継続してサービスを提供できます。 詳細については、JMS 分散送り先のタスクを参照してください。

注意: 回復またはロールバックされるメッセージを管理するために、再配信の制限に達したメッセージのエラー送り先をコンフィグレーションすることもできます。エラー送り先は、ローカル JMS サーバ上でコンフィグレーションされた送り先でなければなりません。 詳細については、『WebLogic JMS プログラマーズ ガイド』の「配信されなかったメッセージに対するエラー送り先のコンフィグレーション」を参照してください。

送り先の属性の中には、動的にコンフィグレーションできるものもあります。属性が実行時に変更された場合、変更は新しく配信されるメッセージにのみ適用され、格納されているメッセージには影響しません。

JMS キューの作成

JMS キューでは、JMS サーバのポイント ツー ポイントの送り先タイプが定義されます。JMS サーバを定義したら、JMS サーバごとに 1 つのまたは複数のキューを送り先としてコンフィグレーションします。

  1. [JMS｜サーバ] ノードを展開し、JMS サーバ インスタンスを選択します。
  2. [送り先] ノードをクリックします。すべての JMS キューを示す [JMS 送り先] テーブルが右ペインに表示されます。
  3. [新しい JMS キューのコンフィグレーション] テキスト リンクをクリックします。ダイアログが表示され、新しく作成するキューの設定に関連するタブが示されます。
  4. [コンフィグレーション｜一般] タブで、キューの一般的なコンフィグレーション属性を定義します。

    5. キューの一般属性の詳細については、[JMS キュー] --> [コンフィグレーション] --> [一般]を参照してください。

  5. [作成] をクリックして、キューのインスタンスを [名前] フィールドで指定した名前で作成します。左ペインの [送り先] ノードに、新しいインスタンスが追加されます。
  6. [コンフィグレーション｜しきい値と割当] タブで、作成したキューのメッセージ数またはバイト数の最大および最小しきい値と最大割り当てに関する以下の属性を指定します。

    7. [しきい値と割当] タブにある属性の詳細については、[JMS キュー] --> [コンフィグレーション] --> [しきい値と割当]を参照してください。

  7. [コンフィグレーション｜オーバライド] タブで、メッセージ プロデューサによって指定された属性をオーバーライドできるメッセージ属性 (優先順位、生存時間、配信時間、および配信モード) を定義します。

    8. キューのオーバーライド属性の詳細については、[JMS キュー] --> [コンフィグレーション] --> [オーバライド]を参照してください。

  8. [コンフィグレーション｜再配信] タブで、メッセージ再配信属性 (再配信遅延のオーバーライド、再配信制限、およびエラー送り先) を定義します。

    9. キューの [再配信] タブにある属性の詳細については、[JMS キュー] --> [コンフィグレーション] --> [再配信]を参照してください。

  9. [コンフィグレーション｜有効期限ポリシー] タブで、期限切れのメッセージがキューで検出されたときに適用するメッセージ有効期限ポリシーを定義します。

    10. キューの [有効期限ポリシー] タブにある属性の詳細については、[JMS キュー] --> [コンフィグレーション] --> [有効期限ポリシー]を参照してください。

  10. [適用] をクリックして、これらのタブで行ったすべての変更を保存します。

JMS トピックの作成

JMS トピックでは、JMS サーバのパブリッシュ/サブスクライブの送り先タイプが定義されます。JMS サーバを定義したら、JMS サーバごとに 1 つのまたは複数のトピックを送り先としてコンフィグレーションします。

  1. [JMS｜サーバ] ノードを展開し、JMS サーバ インスタンスを選択します。
  2. [送り先] ノードをクリックします。コンフィグレーションされているすべての JMS トピックを示す [JMS 送り先] テーブルが右ペインに表示されます。
  3. [新しい JMS トピックのコンフィグレーション] テキスト リンクをクリックします。ダイアログが表示され、新しく作成するトピックの設定に関連するタブが示されます。
  4. [コンフィグレーション｜一般] タブで、トピックの一般的なコンフィグレーション属性を定義します。

    5. トピックの [一般] タブにある属性の詳細については、[JMS トピック] --> [コンフィグレーション] --> [一般]を参照してください。

  5. [作成] をクリックして、トピックのインスタンスを [名前] フィールドで指定した名前で作成します。左ペインの [送り先] ノードに、新しいインスタンスが追加されます。
  6. [コンフィグレーション｜しきい値と割当] タブで、作成したトピックのメッセージ数またはバイト数の最大および最小しきい値と最大割り当てに関する以下の属性を指定します。

    7. トピックの [しきい値と割当] 属性の詳細については、[JMS トピック] --> [コンフィグレーション] --> [しきい値と割当]を参照してください。

  7. [コンフィグレーション｜オーバライド] タブで、メッセージ プロデューサによって指定された属性をオーバーライドできるメッセージ属性 (優先順位、生存時間、配信時間、および配信モード) を定義します。

    8. トピックのオーバーライド属性の詳細については、[JMS トピック] --> [コンフィグレーション] --> [オーバライド]を参照してください。

  8. [コンフィグレーション｜再配信] タブで、メッセージ再配信属性 (再配信遅延のオーバーライド、再配信制限、およびエラー送り先) を定義します。

    9. トピックの再配信性の詳細については、[JMS トピック] --> [コンフィグレーション] --> [再配信]を参照してください。

  9. [コンフィグレーション｜有効期限ポリシー] タブで、期限切れのメッセージがトピックで検出されたときに適用するメッセージ有効期限ポリシーのログ プロパティを定義します。

    10. トピックの [マルチキャスト] タブにある属性の詳細については、[JMS トピック] --> [コンフィグレーション] --> [有効期限ポリシー]を参照してください。

  10. [コンフィグレーション｜マルチキャスト] タブで、トピックのマルチキャスト属性 (マルチキャスト アドレス、マルチキャスト生存時間 (TTL)、およびマルチキャスト ポート) を定義します。

    11. トピックの [マルチキャスト] タブにある属性の詳細については、[JMS トピック] --> [コンフィグレーション] --> [マルチキャスト]を参照してください。

  11. [適用] をクリックして、これらのタブで行ったすべての変更を保存します。

 

JMS テンプレートのタスク

JMS テンプレートを使用すると、似た属性設定を持つ複数の送り先を効率的に定義できます。JMS テンプレートには、以下のような利点があります。

JMS テンプレートのコンフィグレーション可能な属性は、送り先に対してコンフィグレーションされる属性と同じです。これらのコンフィグレーション属性は、それらを使用する送り先によって継承されます。ただし、以下の例外があります。

送り先に対して明示的に定義されない属性には、デフォルト値が割り当てられます。デフォルト値が存在しない場合は、必ず、JMS テンプレートで値を指定するか、または送り先の属性のオーバーライド値として値を指定します。そうしないと、コンフィグレーション情報は不備な状態のままとなります。その場合、WebLogic JMS コンフィグレーションは失敗し、WebLogic JMS が起動しません。

JMS テンプレートの作成

JMS テンプレートのコンフィグレーション属性を定義するには、[JMS｜テンプレート] ノードを使用します。

  1. [JMS｜テンプレート] ノードを展開します。右ペインに [JMS テンプレート] テーブルが表示され、ドメインで定義されているすべてのテンプレートが示されます。
  2. [新しい JMS テンプレートのコンフィグレーション] テキスト リンクをクリックします。右ペインにダイアログが表示され、新しく作成するテンプレートの設定に関連するタブが示されます。
  3. [コンフィグレーション｜一般] タブで、JMS テンプレートの一般的なコンフィグレーション属性を定義します。

    4. トピックの [一般] タブにある属性の詳細については、[JMS テンプレート] --> [コンフィグレーション] --> [一般]を参照してください。

  4. [作成] をクリックして、テンプレートのインスタンスを [名前] フィールドで指定した名前で作成します。左ペインの [テンプレート] ノードの下に、新しいインスタンスが追加されます。
  5. [コンフィグレーション｜しきい値と割当] タブで、この JMS テンプレートから作成した送り先のメッセージ数またはバイト数の最大および最小しきい値と最大割り当てに関する以下の属性を指定します。

    6. [しきい値と割当] の属性の詳細については、[JMS テンプレート] --> [コンフィグレーション] --> [しきい値と割当]を参照してください。

  6. [コンフィグレーション｜オーバライド] タブで、この JMS テンプレートから作成された送り先について、メッセージ プロデューサによって指定された属性をオーバーライドできるメッセージ属性 (優先順位、生存時間、配信時間、および配信モード) を定義します。

    7. JMS テンプレートのオーバーライド属性の詳細については、[JMS テンプレート] --> [コンフィグレーション] --> [オーバライド]を参照してください。

  7. [コンフィグレーション｜再配信] タブで、この JMS テンプレートから作成された送り先について、メッセージ再配信の属性 (再配信遅延のオーバーライド、再配信制限、およびエラー送り先) を定義します。

    8. JMS テンプレートの [再配信] タブにある属性の詳細については、[JMS トピック] --> [コンフィグレーション] --> [再配信]を参照してください。

  8. [コンフィグレーション｜有効期限ポリシー] タブで、この JMS テンプレートから作成された送り先で期限切れのメッセージが検出されたときに適用するメッセージ有効期限ポリシーのログ プロパティを定義します。

    9. JMS テンプレートの [有効期限ポリシー] タブにある属性の詳細については、[JMS テンプレート] --> [コンフィグレーション] --> [再配信]を参照してください。

  9. [適用] をクリックして、これらのタブで行ったすべての変更を保存します。

 

送り先キーのタスク

特定の送り先に到着すると、メッセージはデフォルトでは FIFO (先入れ先出し) 順でソートされます。ソートは、各メッセージのユニークな JMSMessageID に基づいて昇順に行われます。 送り先キーを使用して、送り先に LIFO (後入れ先出し) などの別のソート方式をコンフィグレーションすることもできます。

JMS 送り先キーの作成

送り先キーを作成するには、[送り先キー] ノードを使用します。

  1. [JMS｜送り先キー] ノードを展開します。すべての送り先キーを示す [JMS 送り先キー] テーブルが右ペインに表示されます。
  2. [新しい JMS 送り先キーの作成] テキスト リンクをクリックします。ダイアログが表示され、新しく作成する送り先キーの設定に関連するタブが示されます。
  3. [コンフィグレーション] タブで、送り先キーの属性を定義します。

    4. JMS 送り先キー属性の詳細については、[JMS 送り先キー] --> [コンフィグレーション]を参照してください。

  4. [作成] をクリックして、送り先キーのインスタンスを [名前] フィールドで指定した名前で作成します。新しいインスタンスが左ペインの [送り先キー] ノードの下に追加されます。

 

JMS ストアのタスク

WebLogic JMS では、永続メッセージを JDBC でアクセス可能なデータベースまたはディスクベースのファイルのいずれかに格納できます。

以下に、ファイル ストアと JDBC ストアの類似点と相違点を挙げます。

JMS ストアに格納されているメッセージ数が増加するにつれて、WebLogic Server の初期化に必要なメモリ量も増加します。WebLogic Server の再起動中にメモリ不足で初期化が失敗した場合は、Java 仮想マシン (JVM) のヒープ サイズを、現在 JMS ストアに格納されているメッセージ数に比例して大きくします。次に、WebLogic Server を再起動します。 ヒープ サイズの設定の詳細については、『WebLogic Server パフォーマンス チューニング ガイド』の「WebLogic Server アプリケーションのチューニング」を参照してください。

JMS ファイル ストアのタスク

JMS ファイル ストアは、永続メッセージと恒久サブスクライバをローカル ファイルシステムに格納する場合に使用するディスク ベースのファイルで構成されます。メモリがなくなったときに、メッセージをディスクに一時的にページングする場合の推奨ストアでもあります。

注意: JMS ファイル ストアの障害回復を行うには、ディスクを共有または移行しておく必要があります。そのため、デュアル ポート SCSI ディスクまたはストレージ エリア ネットワーク (SAN) などのハードウェア ソリューションを実装して、他のマシンからもファイル ストアを利用できるようにしておくことをお勧めします。

また、同時性の制限とパフォーマンス上の問題があるため、ネットワーク ファイル システム (NFS) を使用して JMS ファイル ストアにアクセスすることは避けてください。

JMS ファイル ストアの作成

JMS ファイル ストアでは、ファイル システム ディレクトリの中に永続メッセージと恒久サブスクライバが格納されます。 このディレクトリは、対象となるファイル システム上に存在する必要があります。このため、このタブを完了する前にこのディレクトリを作成しておいてください。

  1. [JMS｜ストア] ノードを展開します。 すべての JMS ストアを示す [JMS ストア] テーブルが右ペインに表示されます。
  2. [新しい JMS ファイル ストアの作成] テキスト リンクをクリックします。ダイアログが表示され、新しく作成するファイル ストアの設定に関連するタブが示されます。
  3. [コンフィグレーション] タブで、ファイル ストアの一般属性を定義します。
    • ファイル ストアの名前を入力します。 この名前は、WebLogic Server インスタンス、クラスタ、およびドメイン内、あるいは複数のドメインに渡ってユニークである必要があります。 詳細については、ドメインの相互運用性を実現するための JMS リソースの命名規則を参照してください。
    • [同期書き込みポリシー] を選択して、この JMS ファイル ストアでデータをディスクに書き込む方法を指定します。このポリシーは、JMS ファイル ストアのパフォーマンス、スケーラビリティ、および信頼性にも影響を与える。 詳細については、JMS ファイル ストアのパフォーマンスの向上を参照してください。

      • 注意: JMS ファイル ストアがメッセージのディスクへのページング専用に使用されている場合、同期書き込みポリシーは無視されます。

    • JMS ファイル ストアを保持するディレクトリのファイル システム上のパス名を入力します。 このディレクトリは、対象となるシステム上に存在する必要があります。このため、このタブを完了する前にこのディレクトリを作成しておいてください。

    JMS ファイル ストア属性の詳細については、[JMS ファイル ストア] --> [コンフィグレーション]を参照してください。

  4. [作成] をクリックして、ファイル ストアのインスタンスを [名前] フィールドで指定した名前で作成します。新しいインスタンスが左ペインの [ストア] ノードの下に追加されます。

ページング ストアのコンフィグレーション

JMS サーバおよび送り先のメッセージ ページングをコンフィグレーションする場合、ストア タイプには JMS ファイル ストアが適しています。 ページング ストアは、JMS サーバの永続メッセージまたは恒久サブスクライバを格納するための JMS ファイル ストアとは別個に指定する必要があります。このため、JMS サーバごとにメッセージ ページング専用の JMS ファイル ストアを新しくコンフィグレーションする必要があります。

JMS サーバのページングのコンフィグレーションについては、メッセージのページングによるメモリの解放を参照してください。

  1. [JMS｜ストア] ノードを展開します。 すべての JMS ストアを示す [JMS ストア] テーブルが右ペインに表示されます。
  2. [新しい JMS ファイル ストアの作成] テキスト リンクをクリックします。ダイアログが表示され、新しく作成するファイル ストアの設定に関連するタブが示されます。
  3. [コンフィグレーション] タブで、ファイル ストアの一般属性を定義します。
    • ファイル ストアの名前を入力します。この名前は、WebLogic Server インスタンスまたはクラスタ内でユニークでなければなりません (JMSPagingStore など)。 詳細については、ドメインの相互運用性を実現するための JMS リソースの命名規則を参照してください。
    • JMS ファイル ストアがメッセージのディスクへのページング専用に使用されている場合、同期書き込みポリシーは無視されます。
    • JMS ファイル ストアを保持するディレクトリのファイル システム上のパス名を入力します。 このディレクトリは、対象となるシステム上に存在する必要があります。このため、このタブを完了する前にこのディレクトリを作成しておいてください。

    JMS ファイル ストア属性の詳細については、[JMS ファイル ストア] --> [コンフィグレーション]を参照してください。

  4. [作成] をクリックして、ページング ストアのインスタンスを [名前] フィールドで指定した名前で作成します。新しいインスタンスが左ペインの [ストア] ノードの下に追加されます。
  5. JMS サーバの [コンフィグレーション｜一般] タブで、このページング ファイル ストアを選択します。

JMS JDBC ストアのタスク

JMS では、JDBC を使用することで、指定の JDBC 接続プールを介してアクセスできるデータベースに永続メッセージを格納できます。JMS データベースには、JDBC ドライバからアクセスできる任意のデータベースを指定できます。WebLogic JMS では、以下のデータベース用の JDBC ドライバが検出されます。

weblogic.jar ファイル内の weblogic/jms/ddl ディレクトリには、これらのデータベース用の JMS DLL ファイルがあります。これらのファイルは、実際には JMS データベース テーブルを作成する SQL コマンドが記述されたテキスト ファイルです。別のデータベースを使用するには、これらの .ddl ファイルのいずれかをコピーして編集します。

注意: WebLogic Server 配布キットに添付されている JMS サンプルは、Pointbase Java データベースで動作するように設定されています。WebLogic Server には、Pointbase の評価版が付属しており、demoPool データベースが用意されています。

既存の JMS JDBC ストアに障害が発生した場合は、utils.Schema ユーティリティを使用して再生成できます。 詳細については、『WebLogic JMS プログラマーズ ガイド』の「JDBC データベース ユーティリティ」を参照してください。

JMS JDBC ストアの作成

  1. [JMS｜ストア] ノードを展開します。 すべての JMS ストアを示す [JMS ストア] テーブルが右ペインに表示されます。
  2. [新しい JMS JDBC ストアの作成] テキスト リンクをクリックします。ダイアログが表示され、新しく作成する JDBC ストアの設定に関連するタブが示されます。
  3. [コンフィグレーション] タブで、JMS JDBC ストアの一般属性を定義します。
    • JDBC データベース ストアの名前を入力します。 この名前は、WebLogic Server インスタンス、クラスタ、およびドメイン内、あるいは複数のドメインに渡ってユニークである必要があります。詳細については、ドメインの相互運用性を実現するための JMS リソースの命名規則を参照してください。
    • JMS JDBC ストアにアクセスするための既存 JDBC 接続プールを選択します。JDBC 接続プールのコンフィグレーションの詳細については、JDBC 接続プールのコンフィグレーションを参照してください。
    • 複数のインスタンスで使用するために、この JMS JDBC ストア内の JMS テーブル名に付加されるプレフィックス名を入力します。

    JMS JDBC ストアの属性の詳細については、[JMS JDBC ストア] --> [コンフィグレーション]を参照してください。

  4. [作成] をクリックして、JDBC ストアのインスタンスを [名前] フィールドで指定した名前で作成します。新しいインスタンスが左ペインの [ストア] ノードの下に追加されます。

JMS JDBC ストアとプレフィックスの使用

JMS データベースには、自動的に生成され、JMS 内部で使用される以下の 2 つのシステム テーブルが存在します。

JMS JDBC ストアを使用する場合、WebLogic Server JMS では、テーブルの検索にすべてのデータベース テーブルがスキャンされ、時間がかかり過ぎる場合があります。しかし、ストアの名前にスキーマ名を含むユニークなプレフィックスが付加されていれば、検索時間が短縮し、起動パフォーマンスも向上します。

こうした理由から、JMS JDBC ストアのコンフィグレーション時に、そのストア内の JMS テーブルを識別するためのユニークなプレフィックスをストア名に付加することをお勧めします。このプレフィックスはどのような文字列でも構いませんが、多くのデータベースではユーザ名がスキーマ名として使用されます。プレフィックスは、DBMS で完全修飾名が必要な場合や、2 つの WebLogic Server の JMS テーブルを区別する必要がある (1 つの DBMS で複数のテーブルを格納できるようにする) 場合にテーブル名の前に付けられます。

警告: データが破損するので、2 つの JMS ストアを同じデータベース テーブルで使用することはできません。

プレフィックスは、JMS テーブル名に付加されたときに有効なテーブル名になるように、次の形式で指定します。

[[[catalog.]schema.]prefix]JMSStore

catalog は DBMS が参照するシステム テーブルのセットを識別し、schema はテーブル オーナの ID に変換します。たとえば JMS 管理者は、次のようにプロダクション データベースで販売部門用の固有のテーブルを保持できます。

[[[Production.]JMSAdmin.]Sales]JMSStore

この場合、Production カタログに JMSAdmin というスキーマでテーブルが作成され、SalesJMSStore という名前になります。

注意: Oracle などの一部の DBMS ベンダの場合、設定または選択するカタログがないので、このフォーマットは [[schema.]prefix] となります。詳細については、DBMS のマニュアルで完全修飾テーブル名の作成および使用方法を参照してください。

JMS JDBC ストアでの Oracle 主キーの使用

Oracle データベースを使用する場合、Oracle Advanced Replication では LONG または LONG RAW データ型のカラムを含むテーブルは複製できません。代わりに主キーを使用する必要があります。 そのためには、デフォルトの Oracle DDL ファイルを変更して、JMS JDBC ストアで使用される JMSStore テーブルに手動で主キーを追加します。

jms_oracle.ddl というファイルが WebLogic の CLASSPATH (WL_HOME/server/lib/weblogic.jar ファイル内。ここで、WL_HOME はインストールされた WebLogic Server の最上位ディレクトリ) に、コンフィグレーション済みの状態で用意されています。

JMSStore および JMSState テーブルがすでに存在している場合には、変更済みの DDL ファイルを使用する前に、それらのテーブルを削除してから再作成してください。

  1. JDK で用意されている JAR ユーティリティを使用して、次のコマンドで JMS ストアの DDL ファイルを weblogic/jms/ddl ディレクトリに展開します。 
    2. jar xf weblogic.jar /weblogic/jms/ddl
  2. jms_oracle.ddl テキスト ファイルを以下のように編集します。
    1. CREATE TABLE JMSSTORE エントリを見つけ、 PRIMARY KEY NOT NULL を次に示すように追加します。
      2. CREATE TABLE JMSStore (recordHandle int PRIMARY KEY NOT NULL, recordState int, record LONG RAW);
    2. また、次に示す CREATE INDEX エントリを削除します。
      3. CREATE INDEX JMSMSGQ_X ON JMSStore (recordHandle);
  3. DDL ファイルに変更を保存します。
  4. JMS ストア テーブルを再生成して、カスタマイズした jms_oracle.ddl ファイルを使用するようにするには、『WebLogic JMS プログラマーズ ガイド』の「JDBC データベース ストアの再生成」の指示にしたがいます。

JMS JDBC ストア向けの JDBC 接続プールの推奨設定

JMS JDBC ストアに JDBC 接続プールを使用する場合は、以下の設定を推奨します。

障害が発生したデータベースへの自動再接続

WebLogic Server には、堅牢な JDBC 接続プールが用意されています。JDBC 接続プールでは、障害が発生したデータベースがオンラインに復旧した場合、WebLogic Server を再起動しなくても、自動的にこのデータベースとの再接続を確立できます。この機能を活用し、JMS JDBC ストアをより堅牢なものとして使用するには、JMS JDBC ストアに関連付けられている JDBC 接続プールに対して以下の属性をコンフィグレーションします。

TestConnectionsOnReserve="true"
TestTableName="SYSTABLES"
ConnectionCreationRetryFrequencySeconds="600"

JDBC のデフォルト テスト テーブル名の詳細については、『Administration Console Online Help』の「接続テストのオプション」を参照してください。 データベースへの再接続の試行回数の設定については、『Programming WebLogic JDBC』の「接続作成の再試行の有効化」を参照してください。

WebLogic Type 4 JDBC DB2 ドライバ用に必要な設定

JMS JDBC ストアとして使用する接続プールで DB2 用の WebLogic Type 4 JDBC ドライバを使用する場合は、JMS の内部的なバッチ処理の要件を満たすため、BatchPerformanceWorkaround プロパティを「true」に設定する必要があります。

詳細については、『WebLogic Type 4 JDBC ドライバ ガイド』の「バッチ挿入およびバッチ更新に関するパフォーマンスの回避策」を参照してください。JMS JDBC ストアを使用したトランザクションの処理

JMS JDBC ストアを使用する場合、トランザクション (XA) JDBC 接続プールまたは JDBC TxDataSource をコンフィグレーションすることはできません。JMS では、非 XAResource ドライバと非 TxDataSource を使用する JDBC 接続プールを使用する必要があります (XA ドライバと JTS ドライバは使用できず、[非 XA ドライバ用に 2 フェーズ コミットをエミュレート] オプションも実装できません)。WebLogic JMS は JDBC ドライバの上で XA をサポートします。

これは、WebLogic JMS が自身のリソース マネージャであるからです。つまり、JMS 自体が XAResource を実装し、メッセージがデータベースに格納されている場合でもそのデータベースに依存せずにトランザクションを処理するからです。このため、JMS とデータベース (JMS メッセージが格納されているデータベースと同じ場合でも) を使用する場合、それは常に 2 フェーズ コミット トランザクションになります。 WebLogic JMS によるトランザクションの使い方については、『WebLogic JMS プログラマーズ ガイド』の「WebLogic JMS によるトランザクションの使い方」を参照してください。

パフォーマンスの面では、JMS キューと同じ WebLogic Server 上にデータベース作業用の JDBC 接続プールが存在していればパフォーマンスが向上します。トランザクションは依然として 2 フェーズですが、より小さいオーバーヘッドで処理されるからです。また、JMS JDBC ストアではなく JMS ファイル ストアを使用することによっても、パフォーマンスが向上する場合があります。

 

セッション プールのタスク

サーバ セッション プールを使用すると、アプリケーションでメッセージを並行処理できます。JMS サーバを定義したら、必要に応じて各 JMS サーバに 1 つのまたは複数のサーバ セッション プールをコンフィグレーションします。セッション プールの属性の中には、動的にコンフィグレーションできるものもありますが、新しい値はセッション プールが再起動されるまで有効になりません。

注意: セッション プールは、現在ではほとんど使用されません。J2EE 仕様の必須コンポーネントではなく、JTA ユーザ トランザクションもサポートされていないからです。代わりに、J2EE 仕様の必須コンポーネントであるメッセージ駆動型 Bean (MDB) が主に使用されています。

セッション プールの作成の詳細については、『WebLogic JMS プログラマーズ ガイド』の「WebLogic JMS アプリケーションの開発」を参照してください。

JMS セッション プールの作成

Administration Console の [セッション プール] ノードを使用して、以下のコンフィグレーション属性を定義します。

  1. [JMS｜サーバ] ノードを展開します。
  2. [サーバ] ノードで JMS サーバ インスタンスを展開します。
  3. [セッション プール] ノードをクリックします。すべてのセッション プールを示す [JMS セッション プール] テーブルが右ペインに表示されます。
  4. [新しい JMS セッション プールのコンフィグレーション] テキスト リンクをクリックします。ダイアログが表示され、新しく作成するセッション プールの設定に関連するタブが示されます。
  5. [コンフィグレーション] タブで、セッション プールの一般属性を定義します。
    • セッション プールの名前を入力します。 この名前は、WebLogic Server インスタンスまたはクラスタ内でユニークでなければなりません。 詳細については、ドメインの相互運用性を実現するための JMS リソースの命名規則を参照してください。
    • サーバ セッション プールが関連付けられ、セッションを作成するために使用される接続ファクトリ名を入力します。
    • 並行して複数のメッセージを受信および処理する場合に使用されるメッセージ リスナ クラスを入力します。
    • JMS セッション プール内の非トランザクション セッションによって使用される確認応答モードを選択します。
    • 並行セッションの最大数を指定します。
    • セッション プールがトランザクション セッションを作成するかどうかを選択します。

    セッション プールの属性の詳細については、[JMS セッション プール] --> [コンフィグレーション]を参照してください。

  6. [作成] をクリックして、[名前] フィールドで指定した名前のセッション プール インスタンスを作成します。新しいインスタンスが左ペインの [セッション プール] ノードの下に追加されます。

 

接続コンシューマのタスク

接続コンシューマは、サーバ セッションを取得してメッセージを処理するキュー (ポイント ツー ポイント) またはトピック (Pub/Sub) です。セッション プールを定義したら、セッション プールごとに 1 つまたは複数の接続コンシューマをコンフィグレーションします。

接続コンシューマの作成の詳細については、『WebLogic JMS プログラマーズ ガイド』の「WebLogic JMS アプリケーションの開発」を参照してください。

JMS 接続コンシューマの作成

接続コンシューマをコンフィグレーションするには、[セッション プール] ノードを使用して、以下のコンフィグレーション属性を定義します。

  1. [JMS｜サーバ] ノードを展開します。
  2. [サーバ] ノードで JMS サーバ インスタンスを展開します。
  3. [セッション プール] ノードを展開し、セッション プール インスタンスをクリックします。
  4. [コンシューマ] ノードをクリックします。すべての接続コンシューマを示す [コンシューマ] テーブルが右ペインに表示されます。
  5. [新しい JMS 接続コンシューマのコンフィグレーション] テキスト リンクをクリックします。ダイアログが表示され、新しく作成する接続コンシューマの設定に関連するタブが示されます。
  6. [コンフィグレーション] タブで、接続コンシューマの一般属性を定義します。
    • 接続コンシューマの名前を入力します。 この名前は、WebLogic Server インスタンスまたはクラスタ内でユニークでなければなりません。 詳細については、ドメインの相互運用性を実現するための JMS リソースの命名規則を参照してください。
    • 接続コンシューマが蓄積できるメッセージの最大数を指定します。
    • メッセージをフィルタ処理する場合に使用される JMS セレクタ式を指定します。 セレクタの定義については、『WebLogic JMS プログラマーズ ガイド』の「WebLogic JMS アプリケーションの開発」を参照してください。
    • 接続コンシューマがリスン対象とする送り先を指定します。

    接続コンシューマの属性の詳細については、[JMS 接続コンシューマ] --> [コンフィグレーション]を参照してください。

  7. [作成] をクリックして、[名前] フィールドで指定した名前の接続コンシューマ インスタンスを作成します。新しいインスタンスが左ペインの [コンシューマ] ノードの下に追加されます。

 

JMS 分散送り先のタスク

分散送り先は、単一の JNDI 名でアクセスし、JMS クライアントからは単一の論理的な送り先に見える一連の物理的な JMS 送り先 (キューまたはトピック) です。分散送り先のメンバーは、実際にはクラスタ内の複数のサーバに分散されており、各送り先メンバーは個々の JMS サーバに属しています。

複数の物理的キューおよびトピックを単一の分散送り先のメンバーとしてコンフィグレーションできるようにすることで、WebLogic JMS はクラスタ内の物理的な送り先の高可用性とロードバランシングを実現します。 アプリケーション内での分散送り先の使用については、『WebLogic JMS プログラマーズ ガイド』の「分散送り先の使用」を参照してください。

分散送り先のコンフィグレーションのガイドライン

JMS 分散送り先は、[サービス｜JMS｜分散送り先] ノードでコンフィグレーションできます。コンフィグレーション プロセスを分かりやすくするために、以下のシナリオに対応する手順に分けて説明します。

分散送り先のコンフィグレーションのベスト プラクティス

分散送り先アプリケーションの管理および開発を簡単にするために、参加する各 JMS サーバとそれに関連付けられた物理的送り先に同じようなコンフィグレーションを適用して、クラスタ全体で一貫性を持つように分散送り先をデプロイすることをお勧めします。 JMS ストア、メッセージ ページング、エラー送り先、メッセージ数またはバイト数の割り当て、および接続ファクトリのコンフィグレーションについても一貫性を持たせる必要があります。 たとえば、永続的なメッセ-ジングがコンフィグレーションされている場合には、必ずすべての分散送り先のメンバーが、同じような容量およびパフォーマンスの JMS ストアと関連付けられるようにします。

分散送り先メンバーのコンフィグレーションの一貫性を維持する方法として、JMS テンプレートを使用することをお勧めします。これは、それぞれの物理的送り先に共通するカスタム コンフィグレーションを集中して管理できるもっとも信頼性の高い方法です。 新しい分散送り先のメンバーの作成を Administration Console を使用してコンフィグレーションした場合には、JMS テンプレートの自動作成に説明されているように、そのメンバー用に自動的に作成された JMS テンプレートを使用します。 既存の物理的送り先を表す分散送り先を作成した場合には、その物理的送り先に関連付けられた JMS テンプレートがあればそれを使用します。ない場合には、JMS テンプレートのタスクに説明されているように JMS テンプレートをコンフィグレーションします。

警告: アプリケーションにおける障害の発生を避けるために、参加する各分散送り先メンバーに対して一貫性のあるセキュリティ パーミッションをコンフィグレーションする必要があります。 たとえば、分散送り先の 1 つのメンバーに他のメンバーとは異なる送信制限がコンフィグレーションされていると、アプリケーションによる分散送り先への送信が、あるときには許可されるが、別のときには許可されないという状況に陥ることがあります。

ロード バランシングとサーバ アフィニティのチューニング

分散送り先のコンフィグレーションをチューニングするためのデフォルトの [ロード バランスを有効化] および [サーバ アフィニティを有効化] 属性の値は、Administration Console を使って JMS 接続ファクトリで変更できます。 詳細については、分散送り先におけるメッセージのロード バランシングのコンフィグレーションおよび分散送り先のサーバ アフィニティのコンフィグレーションを参照してください。

JMS テンプレートの自動作成

Administration Console を使用して、新しい分散トピックまたはキュー メンバーを含む分散送り先を作成すると、それらのメンバーについて、対応する JMS テンプレートが自動的にデフォルトの属性値で作成されます。 新しい JMS テンプレートは、[JMS｜テンプレート] ノードに分散送り先と同じ名前で表示されます。 分散送り先メンバーのしきい値、割り当てなどの属性は、このテンプレートを使用して再設定できます。 JMS テンプレートの使用方法の詳細については、JMS テンプレートのタスクを参照してください。

JMS サーバを削除する場合の注意事項

クラスタ化されたコンフィグレーションでは、分散送り先メンバーをホストしている JMS サーバを割り当て解除または削除する場合、まず分散送り先コンフィグレーションからそのメンバーを手動で削除してからでないと、コンフィグレーション ファイル (config.xml) が起動不可となります。 分散送り先メンバーを削除する手順については、JMS 分散キュー メンバーの削除およびJMS 分散トピック メンバーの削除を参照してください。

分散トピックの作成とメンバーの自動作成

分散トピックをコンフィグレーションし、WebLogic Server クラスタの一部である JMS サーバ (高可用性のため)、またはクラスタの一部ではない単一の WebLogic Server インスタンス上の JMS サーバにトピック メンバーを自動的に作成するには、次の手順に従います。

  1. [JMS｜分散送り先] ノードを展開します。
  2. 右ペインで [新しい分散トピックのコンフィグレーション] リンクをクリックします。ダイアログが表示され、新しく作成する分散トピックの設定に関連するタブが示されます。
  3. [コンフィグレーション｜一般] タブで、分散キューの一般的なコンフィグレーション属性を定義します。
    • 分散トピックの名前を入力します。
    • JNDI ネームスペース内で分散トピックにアクセスするための JNDI 名を入力します。アプリケーションは、この JNDI 名を使用して分散トピックをルックアップします。

      • 注意: JNDI 名を持たない分散トピックは、分散トピックの名前を javax.jms.TopicSession.createTopic() に渡すことで参照できます。

    • プロデューサがどのようにメッセージを分散トピックのメンバー間に分散するかを定義します。 有効値は、[ラウンドロビン] と [ランダム] です (分散送り先におけるメッセージのロード バランシングのコンフィグレーションを参照)。

    分散トピックの一般属性の詳細については、[JMS 分散トピック] --> [コンフィグレーション] --> [一般]を参照してください。

  4. [作成] をクリックして、分散トピックのインスタンスを [名前] フィールドで指定した名前で作成します。新しいインスタンスが左ペインの [分散送り先] ノードの下に追加されます。
  5. [コンフィグレーション｜しきい値と割当] タブで、作成した分散トピックの全メンバーについて、メッセージ数またはバイト数の最大および最小しきい値と最大割り当てに関する以下の属性を指定します。
    • 分散トピックに保存可能な最大バイト数またはメッセージ数の割り当てを指定します。
    • 分散トピックに保存されているバイト数またはメッセージ数に基づいてイベントを発生させる上限しきい値を指定します。イベントには、メッセージ ページング、メッセージ フロー制御、システム ログ メッセージがあります。
    • 分散トピックに保存されているバイト数またはメッセージ数に基づいてイベントを発生させる下限しきい値を指定します。イベントには、メッセージ ページング、メッセージ フロー制御、システム ログ メッセージがあります。
    • 分散トピックのメッセージ負荷が指定のしきい値に達したときにメッセージをメモリからページング ストアに一時的にスワップ アウトするためのバイト ページングまたはメッセージ ページングを有効にするかどうかを指定します。
    • 分散トピックでメッセージ プロデューサから受信するメッセージの最大サイズを指定します。 このサイズには、メッセージ本文、ユーザ定義のプロパティ、およびユーザ定義の JMS ヘッダ フィールド (JMSCorrelationID と JMSType) が含まれます。

    これらの属性の詳細については、[JMS 分散トピック] --> [コンフィグレーション] --> [しきい値と割当]を参照してください。

  6. [適用] をクリックして、このタブで行ったすべての変更を保存します。
  7. [自動デプロイ] タブで、分散トピック メンバーの自動作成先となる WebLogic Server インスタンスを指定します。
  8. [選択されたサーバ (および JMS サーバ) にメンバを作成する] テキスト リンクをクリックします。自動デプロイ ダイアログが表示されたら、以下のいずれかのオプションを選択します。
    • 分散トピックの対象となるクラスタを選択して [次へ] をクリックします。

      • または

    • [なし] オプションをそのまま選択してこのダイアログを終了し、個々のサーバまたはクラスタ内のサーバを選択します(この場合は手順 10 に進む)。
  9. クラスタを選択した場合は、次の手順に従ってクラスタ内の WebLogic Server インスタンスを選択します。
    1. クラスタのメンバーであって、まだ分散トピックをホストしていないすべての WebLogic Server サーバが表示され、デフォルトで選択されます。サーバ インスタンスが分散トピックのホストにならないようにするには、該当するチェック ボックスのチェックをはずします。
    2. [次へ] をクリックして次のダイアログに進みます。
    3. 分散トピック メンバーを作成するために選択した WebLogic Server で利用可能な JMS サーバを選択するには、手順 11 に進みます。
  10. 手順 8 の [クラスタ] ダイアログで [なし] を選択した場合は、ドメイン内の単一の WebLogic Server インスタンスを選択します。
    1. リスト ボックスから、分散トピック メンバーの作成先となる個々のサーバを選択します。
    2. [次へ] をクリックして次のダイアログに進みます。
  11. 選択した WebLogic Server インスタンスにデプロイされており、まだ分散トピックをホストしていないすべての JMS サーバが表示され、デフォルトで選択されます。JMS サーバが分散トピック メンバーのホストにならないようにするには、該当するチェック ボックスのチェックをはずします。

    12. 選択した JMS サーバに既存の分散トピック メンバーがない場合は、各 JMS サーバに新しい JMS トピックが 1 つ作成され、分散トピックのメンバーとして追加されます。

  12. [次へ] をクリックして、最後の [自動デプロイ] ダイアログに進みます。
  13. [適用] をクリックして、[自動デプロイ] での選択を保存します。
  14. [コンフィグレーション｜メンバ] タブをクリックすると、新しい分散トピック用に自動作成されたトピック メンバーが表示されます。
  15. [JMS｜テンプレート] ノードを展開して、分散トピックと同じ名前で自動的に作成された JMS テンプレートを表示します。

分散トピックの作成および既存の物理的なトピックのメンバーとしての手動追加

WebLogic JMS の既存の実装で、コンフィグレーション済みの送り先を分散送り先セットのメンバーとして追加する必要がある場合は、以下の手順に従って分散トピックをコンフィグレーションし、既存の物理的なトピックをメンバーとして手動で追加します。

  1. [JMS｜分散送り先] ノードを展開します。
  2. 右ペインで [新しい分散トピックのコンフィグレーション] リンクをクリックします。ダイアログが表示され、新しく作成する分散トピックの設定に関連するタブが示されます。
  3. [コンフィグレーション｜一般] タブで、分散キューの一般的なコンフィグレーション属性を定義します。
    • 分散トピックの名前を入力します。
    • JNDI ネームスペース内で分散トピックにアクセスするための JNDI 名を入力します。アプリケーションは、この JNDI 名を使用して分散トピックをルックアップします。

      • 注意: JNDI 名を持たない分散トピックは、分散トピックの名前を javax.jms.TopicSession.createTopic() に渡すことで参照できます。

    • プロデューサがどのようにメッセージを分散トピックのメンバー間に分散するかを定義します。 有効値は、[ラウンドロビン] と [ランダム] です (分散送り先におけるメッセージのロード バランシングのコンフィグレーションを参照)。

    分散トピックの一般属性の詳細については、[JMS 分散トピック] --> [コンフィグレーション] --> [一般]を参照してください。

  4. [作成] をクリックして、分散トピックのインスタンスを [名前] フィールドで指定した名前で作成します。新しいインスタンスが左ペインの [分散送り先] ノードの下に追加されます。
  5. [コンフィグレーション｜しきい値と割当] タブで、作成した分散トピックの全メンバーについて、メッセージ数またはバイト数の最大および最小しきい値と最大割り当てに関する以下の属性を指定します。
    • 分散トピックに保存可能な最大バイト数またはメッセージ数の割り当てを指定します。
    • 分散トピックに保存されているバイト数またはメッセージ数に基づいてイベントを発生させる上限しきい値を指定します。イベントには、メッセージ ページング、メッセージ フロー制御、システム ログ メッセージがあります。
    • 分散トピックに保存されているバイト数またはメッセージ数に基づいてイベントを発生させる下限しきい値を指定します。イベントには、メッセージ ページング、メッセージ フロー制御、システム ログ メッセージがあります。
    • 分散トピックのメッセージ負荷が指定のしきい値に達したときにメッセージをメモリからページング ストアに一時的にスワップ アウトするためのバイト ページングまたはメッセージ ページングを有効にするかどうかを指定します。
    • 分散トピックでメッセージ プロデューサから受信するメッセージの最大サイズを指定します。 このサイズには、メッセージ本文、ユーザ定義のプロパティ、およびユーザ定義の JMS ヘッダ フィールド (JMSCorrelationID と JMSType) が含まれます。

    分散トピック メンバーの基底の物理的なトピックに、すでにしきい値と割り当てがコンフィグレーションされた JMS テンプレートが存在する場合、これらの属性はそのトピック メンバーには適用されません。 これらの属性の詳細については、[JMS 分散トピック] --> [コンフィグレーション] --> [しきい値と割当]を参照してください。

  6. [適用] をクリックして、このタブで行ったすべての変更を保存します。

    7. 注意: WebLogic Server クラスタの一部である JMS サーバ (高可用性のため)、またはクラスタの一部ではない単一の WebLogic Server インスタンス上の JMS サーバにトピック メンバーを自動的に作成する場合は、分散トピックの作成とメンバーの自動作成を参照してください。

  7. [コンフィグレーション｜メンバ] タブで、既存の物理的なトピック用の分散トピック メンバーを作成します。
  8. 右ペインで [新しい分散トピック メンバーのコンフィグレーション] リンクをクリックします。[コンフィグレーション] ダイアログに、新しい分散トピック メンバーのコンフィグレーションに関連するタブが表示されます。
  9. [コンフィグレーション] タブで、分散トピックの一般的なコンフィグレーション属性を定義します。
    • WebLogic Server ドメイン内で分散トピック メンバーをユニークに識別します。
    • 分散トピック メンバーに関連付けられる基底の物理的なトピックを選択します。
    • トピック メンバーの重み (メッセージ負荷を処理する能力の尺度) を、分散送り先における他のトピック メンバーとの比較で定義します。 分散送り先のロード バランシングの詳細については、『WebLogic JMS プログラマーズ ガイド』の「WebLogic JMS アプリケーションの開発」を参照してください。

    分散トピック メンバーの属性の詳細については、[JMS 分散トピック メンバー] --> [コンフィグレーション]を参照してください。

  10. [作成] をクリックして新しい分散トピック メンバーを作成します。新しいメンバーが [分散トピック] テーブルに追加されます。
  11. 必要に応じて手順 8 〜 10 を繰り返し、トピック メンバーを分散トピックに追加し続けます。

分散キューの作成とメンバーの自動作成

分散キューをコンフィグレーションし、WebLogic Server クラスタの一部である JMS サーバ (高可用性のため)、またはクラスタの一部ではない単一の WebLogic Server インスタンス上の JMS サーバにキュー メンバーを自動的に作成するには、次の手順に従います。

  1. [JMS｜分散送り先] ノードを展開します。
  2. 右ペインで [新しい分散キューのコンフィグレーション] リンクをクリックします。 [コンフィグレーション] ダイアログに、新しい分散キューのコンフィグレーションに関連するタブが表示されます。
  3. [コンフィグレーション｜一般] タブで、分散キューの一般的なコンフィグレーション属性を定義します。
    • 分散キューの名前を入力します。
    • JNDI ネームスペース内で分散キューにアクセスするための JNDI 名を入力します。アプリケーションは、この JNDI 名を使用して分散キューをルックアップします。

      • 注意: JNDI 名を持たない分散キューは、分散キューの名前を javax.jms.QueueSession.createQueue() に渡すことで参照できます。

    • プロデューサがどのようにメッセージを分散キューのメンバー間に分散するかを定義します。 有効値は、[ラウンドロビン] と [ランダム] です (分散送り先におけるメッセージのロード バランシングのコンフィグレーションを参照)。
    • メッセージを持つがコンシューマを持たない分散キュー メンバーが、コンシューマを持つ他のキューにメッセージを転送するまでに待機する時間 (秒単位) を定義します。

    分散キューの [一般] にある属性の詳細については、[JMS 分散キュー] --> [コンフィグレーション] --> [一般]を参照してください。

  4. [作成] をクリックして、分散キューのインスタンスを [名前] フィールドで指定した名前で作成します。新しいインスタンスが左ペインの [分散送り先] ノードの下に追加されます。
  5. [コンフィグレーション｜しきい値と割当] タブで、作成した分散キューの全メンバーについて、メッセージ数またはバイト数の最大および最小しきい値と最大割り当てに関する以下の属性を指定します。
    • 分散キューに保存可能な最大バイト数またはメッセージ数の割り当てを指定します。
    • 分散キューに保存されているバイト数またはメッセージ数に基づいてイベントを発生させる上限しきい値を指定します。イベントには、メッセージ ページング、メッセージ フロー制御、システム ログ メッセージがあります。
    • 分散キューに保存されているバイト数またはメッセージ数に基づいてイベントを発生させる下限しきい値を指定します。イベントには、メッセージ ページング、メッセージ フロー制御、システム ログ メッセージがあります。
    • 分散キューのメッセージ負荷が指定のしきい値に達したときにメッセージをメモリからページング ストアに一時的にスワップ アウトするためのバイト ページングまたはメッセージ ページングを有効にするかどうかを指定します。
    • 分散キューでメッセージ プロデューサから受信するメッセージの最大サイズを指定します。 このサイズには、メッセージ本文、ユーザ定義のプロパティ、およびユーザ定義の JMS ヘッダ フィールド (JMSCorrelationID と JMSType) が含まれます。

    分散キュー メンバーの基底の物理的なキューに、すでにしきい値と割り当てがコンフィグレーションされた JMS テンプレートが存在する場合、これらの属性はそのキュー メンバーには適用されません。 これらの属性の詳細については、[JMS 分散トピック] --> [コンフィグレーション] --> [しきい値と割当]を参照してください。

  6. [適用] をクリックして、このタブで行ったすべての変更を保存します。
  7. [自動デプロイ] タブで、分散キュー メンバーの自動作成先となる WebLogic Server インスタンスを指定します。
  8. [選択されたサーバ (および JMS サーバ) にメンバを作成する] テキスト リンクをクリックします。以下のオプションのいずれかを選択するよう要求するダイアログが表示されます。
    • 分散キューの対象とするクラスタを選択して [次へ] をクリックする。

      • または

    • [なし] オプションをそのまま選択してこのダイアログを終了し、個々のサーバまたはクラスタ内のサーバを選択します(この場合は手順 10 に進む)。
  9. クラスタを選択した場合は、次の手順に従ってクラスタ内の WebLogic Server インスタンスを選択します。
    1. クラスタのメンバーであって、まだ分散キューをホストしていないすべてのサーバが表示され、デフォルトで選択されます。サーバが分散キューのホストにならないようにするには、該当するチェック ボックスのチェックをはずします。
    2. [次へ] をクリックして次のダイアログに進みます。
    3. 分散キュー メンバーを作成するために選択した WebLogic Server で利用可能な JMS サーバを選択するには、手順 11 に進みます。
  10. 手順 8 の [クラスタ] ダイアログで [なし] を選択した場合は、ドメイン内の単一の WebLogic Server インスタンスを選択します。
    1. リスト ボックスから、分散キュー メンバーの作成先となる個々のサーバを選択します。
    2. [次へ] をクリックして次のダイアログに進みます。
  11. 選択した WebLogic Server 上にデプロイされており、まだ分散キューをホストしていないすべての JMS サーバが表示され、デフォルトで選択されます。JMS サーバが分散キュー メンバーのホストにならないようにするには、該当するチェック ボックスのチェックをはずします。

    12. 選択した JMS サーバに既存の分散キュー メンバーがない場合は、各 JMS サーバに新しい JMS キュー が 1 つ作成され、分散キューのメンバーとして追加されます。

  12. [次へ] をクリックして、最後の [自動デプロイ] ダイアログに進みます。
  13. [適用] をクリックして、[自動デプロイ] での選択を保存します。
  14. [コンフィグレーション｜メンバ] タブをクリックすると、新しい分散キュー用に自動作成されたキュー メンバーが表示されます。
  15. [JMS｜テンプレート] ノードを展開して、分散キューと同じ名前で自動的に作成された JMS テンプレートを表示します。

分散キューの作成および既存の物理キューのメンバーとしての手動追加

WebLogic JMS の既存の実装で、コンフィグレーション済みの送り先を分散送り先セットのメンバーとして追加する必要がある場合、次の手順に従って分散キューをコンフィグレーションし、既存の物理的なキューをメンバーとして手動で追加します。

  1. [JMS｜分散送り先] ノードを展開します。
  2. 右ペインで [新しい分散キューのコンフィグレーション] リンクをクリックします。 [コンフィグレーション] ダイアログに、新しい分散キューのコンフィグレーションに関連するタブが表示されます。
  3. [コンフィグレーション｜一般] タブで、分散キューの一般的なコンフィグレーション属性を定義します。
    • 分散キューの名前を入力します。
    • JNDI ネームスペース内で分散キューにアクセスするための JNDI 名を入力します。アプリケーションは、この JNDI 名を使用して分散キューをルックアップします。

      • 注意: JNDI 名を持たない分散キューは、分散キューの名前を javax.jms.QueueSession.createQueue() に渡すことで参照できます。

    • プロデューサがどのようにメッセージを分散キューのメンバー間に分散するかを定義します。 有効値は、[ラウンドロビン] と [ランダム] です (分散送り先におけるメッセージのロード バランシングのコンフィグレーションを参照)。
    • メッセージを持つがコンシューマを持たない分散キュー メンバーが、コンシューマを持つ他のキュー メンバーにメッセージを転送するまでに待機する時間 (秒単位) を定義します。

    分散キューの [一般] にある属性の詳細については、[JMS 分散キュー] --> [コンフィグレーション] --> [一般]を参照してください。

  4. [作成] をクリックして、分散キューのインスタンスを [名前] フィールドで指定した名前で作成します。新しいインスタンスが左ペインの [分散送り先] ノードの下に追加されます。
  5. [コンフィグレーション｜しきい値と割当] タブで、作成した分散キューの全メンバーについて、メッセージ数またはバイト数の最大および最小しきい値と最大割り当てに関する以下の属性を指定します。
    • 分散キューに保存可能な最大バイト数またはメッセージ数の割り当てを指定します。
    • 分散キューに保存されているバイト数またはメッセージ数に基づいてイベントを発生させる上限しきい値を指定します。イベントには、メッセージ ページング、メッセージ フロー制御、システム ログ メッセージがあります。
    • 分散キューに保存されているバイト数またはメッセージ数に基づいてイベントを発生させる下限しきい値を指定します。イベントには、メッセージ ページング、メッセージ フロー制御、システム ログ メッセージがあります。
    • 分散キューのメッセージ負荷が指定のしきい値に達したときにメッセージをメモリからページング ストアに一時的にスワップ アウトするためのバイト ページングまたはメッセージ ページングを有効にするかどうかを指定します。
    • 分散キューでメッセージ プロデューサから受信するメッセージの最大サイズを指定します。 このサイズには、メッセージ本文、ユーザ定義のプロパティ、およびユーザ定義の JMS ヘッダ フィールド (JMSCorrelationID と JMSType) が含まれます。

    分散キュー メンバーの基底の物理的なキューに、すでにしきい値と割り当てがコンフィグレーションされた JMS テンプレートが存在する場合、これらの属性はそのキュー メンバーには適用されません。 これらの属性の詳細については、[JMS 分散キュー] --> [コンフィグレーション] --> [しきい値と割当]を参照してください。

  6. [適用] をクリックして、このタブで行ったすべての変更を保存します。

    7. 注意: WebLogic Server クラスタの一部である JMS サーバ (高可用性のため)、またはクラスタの一部ではない単一の WebLogic Server インスタンス上の JMS サーバにキュー メンバーを自動的に作成する場合は、分散キューの作成とメンバーの自動作成を参照してください。

  7. [コンフィグレーション｜メンバ] タブをクリックして、分散キューのキュー メンバーを定義します。
  8. 右ペインの [新しい分散キュー メンバーのコンフィグレーション] テキスト リンクをクリックします。 [コンフィグレーション] ダイアログに、新しい分散キュー メンバーのコンフィグレーションに関連するタブが表示されます。
  9. [コンフィグレーション] タブで、分散キューの一般的なコンフィグレーション属性を定義します。
    • WebLogic Server ドメイン内で分散キュー メンバーをユニークに識別します。
    • 分散キュー メンバーに関連付けられる基底の物理的なキューを選択します。
    • キュー メンバーの重み (メッセージ負荷を処理する能力の尺度) を、分散送り先における他のキュー メンバーとの比較で定義します。 分散送り先のロードバランシングの詳細については、『WebLogic JMS プログラマーズ ガイド』の「WebLogic JMS アプリケーションの開発」を参照してください。

    分散キュー メンバーの属性の詳細については、[JMS 分散キュー メンバー] --> [コンフィグレーション]を参照してください。

  10. [作成] をクリックして新しい分散キュー メンバーを作成します。新しいメンバーが [分散キュー] テーブルに追加されます。
  11. 手順 8 〜 10 を繰り返して、分散キューにメンバーを追加し続けます。

JMS 分散キュー メンバーの作成

既存の物理的なトピックを分散キューのメンバーとして追加するには、次の手順に従います。

  1. [JMS｜分散送り先] ノードを展開します。右ペインに [分散送り先] テーブルが表示され、すべての分散キューおよびトピックが示されます。
  2. メンバーの追加先となる分散キューをクリックします。[分散キュー] テーブルが表示され、その分散キューに属しているすべての分散キュー メンバーが示されます。
  3. [新しい分散キュー メンバーのコンフィグレーション] テキスト リンクをクリックします。新しい分散キュー メンバーをコンフィグレーションするための [コンフィグレーション] タブが表示されます。
  4. 分散キューのコンフィグレーション属性を定義します。
    • WebLogic Server ドメイン内で分散キュー メンバーをユニークに識別します。
    • 分散キュー メンバーに関連付けられる基底の物理的なキューを選択します。
    • キュー メンバーの重み (メッセージ負荷を処理する能力の尺度) を、分散送り先における他のキュー メンバーとの比較で定義します。 分散送り先のロードバランシングの詳細については、『WebLogic JMS プログラマーズ ガイド』の「WebLogic JMS アプリケーションの開発」を参照してください。

    分散キュー メンバーの属性の詳細については、[JMS 分散キュー メンバー] --> [コンフィグレーション]を参照してください。

  5. [作成] をクリックして、[名前] フィールドで指定した名前で分散キュー メンバーを作成します。新しいメンバーが左ペインの [分散キュー メンバ] テーブルに追加されます。
  6. [適用] をクリックして、変更を保存します。

JMS 分散キュー メンバーの削除

分散キューのメンバーを削除し、必要な場合はそのメンバーの基底の物理的なキューも削除するには、次の手順に従います。

注意: 分散キュー全体を削除する必要がある場合は、分散送り先の削除の説明に従ってください。

  1. [JMS｜分散送り先] ノードを展開します。右ペインに [分散送り先] テーブルが表示され、すべての分散キューおよびトピックが示されます。
  2. 削除するメンバーが属する分散キューをクリックします。[分散キュー] テーブルが表示され、その分散キューに属しているすべての分散キュー メンバーが示されます。
  3. 削除する分散キュー メンバーの行で [削除] アイコンをクリックします。削除の要求を確認するダイアログが表示されます。
  4. 基底の物理的なトピックも削除する場合は、[Also Delete] チェック ボックスを選択します。
  5. [削除] をクリックして、分散キュー メンバーを (選択した場合は基底の物理的なキューも) 削除します。
  6. 右ペインに [分散キュー] テーブルが表示されます。[分散キュー] テーブルから分散キュー メンバーが削除されます。

JMS 分散トピック メンバーの作成

既存の物理的なトピックを分散キューのメンバーとして追加するには、次の手順に従います。

  1. [JMS｜分散送り先] ノードを展開します。右ペインに [分散送り先] テーブルが表示され、すべての分散キューおよびトピックが示されます。
  2. メンバーの追加先となる分散トピックをクリックします。[分散トピック] テーブルが表示され、その分散トピックに属しているすべての分散トピック メンバーが示されます。
  3. [新しい分散トピック メンバーのコンフィグレーション] テキスト リンクをクリックします。新しい分散トピック メンバーをコンフィグレーションするための [コンフィグレーション] タブが表示されます。
  4. 分散トピックのコンフィグレーション属性を定義します。
    • WebLogic Server ドメイン内で分散トピック メンバーをユニークに識別します。
    • 分散トピック メンバーに関連付けられる基底の物理的なトピックを選択します。
    • トピック メンバーの重み (メッセージ負荷を処理する能力の尺度) を、分散送り先における他のトピック メンバーとの比較で定義します。 分散送り先のロード バランシングの詳細については、『WebLogic JMS プログラマーズ ガイド』の「WebLogic JMS アプリケーションの開発」を参照してください。

    分散トピック メンバーの属性の詳細については、[JMS 分散トピック メンバー] --> [コンフィグレーション]を参照してください。

  5. [作成] をクリックして、[名前] フィールドで指定した名前で分散トピック メンバーを作成します。新しいメンバーが左ペインの [分散トピック] テーブルに追加されます。
  6. [適用] をクリックして、変更を保存します。

JMS 分散トピック メンバーの削除

分散トピックのメンバーを削除し、必要な場合はそのメンバーの基底の物理的なトピックも削除するには、次の手順に従います。

注意: 分散トピック全体を削除する必要がある場合は、分散送り先の削除の説明に従ってください。

  1. [JMS] ノードを展開します。
  2. [分散送り先] ノードを展開します。右ペインに [分散送り先] テーブルが表示され、すべての分散キューおよびトピックが示されます。
  3. 削除するメンバーが属する分散トピックをクリックします。[分散トピック] テーブルが表示され、その分散トピックに属しているすべての分散トピック メンバーが示されます。
  4. 削除する分散トピック メンバーの行で [削除] アイコンをクリックします。削除の要求を確認するダイアログが表示されます。
  5. 基底の物理的なトピックも削除する場合は、[Also Delete] チェック ボックスを選択します。
  6. [削除] をクリックして、分散トピック メンバーを (選択した場合は基底の物理的なトピックも) 削除します。
  7. 右ペインに [分散トピック] テーブルが表示されます。[分散トピック] テーブルから分散トピック メンバーが削除されます。

分散送り先の削除

分散送り先全体を削除する場合は、次の手順で削除する必要があります。

  1. 分散キューまたは分散トピックのすべてのメンバーを削除します。以下の節を参照してください。
  2. [JMS｜分散送り先] ノードを展開し、削除する分散送り先の横にあるごみ箱アイコンをクリックして分散送り先自体を削除します。

    3. 注意: 分散送り先のすべてのメンバーが削除されていないと、その分散送り先を削除することはできません。

  3. 削除した分散送り先に関連付けられている JMS テンプレートを削除できます。 ただし、このテンプレートが他の JMS サーバまたは送り先で使用されていないことを確認してください。 JMS テンプレートを削除するには、[JMS｜テンプレート] ノードを展開し、削除する JMS テンプレートと同じ行にあるごみ箱アイコンをクリックします。

分散送り先のモニタ

分散送り先をモニタする場合、トピック メンバーまたはキュー メンバー用に自動的に作成されるプロキシ トピック メンバまたはシステム サブスクリプションを確認することができます。 詳細については、分散送り先システム サブスクリプションおよび代理トピック メンバーのモニタを参照してください。

 

リモートまたは外部 JMS プロバイダへの単純なアクセス

WebLogic JMS では、外部 (サードパーティ) JMS プロバイダをローカル WebLogic Server JNDI ツリー内で参照できます。 [外部 JMS サーバ] ノードを使用すると、外部 JMS プロバイダをすぐにマップし、関連付けられた接続ファクトリと送り先をローカル JMS オブジェクトのように WebLogic JNDI ツリーに表示できます。

また、外部 JMS サーバをコンフィグレーションすることで、別のクラスタまたはドメインに属するリモート WebLogic Server インスタンスをローカル WebLogic JNDI ツリー内で参照することもできます。 ただし、ドメイン間の相互運用性を実現するには、WebLogic Server ドメインのリソースにはユニークな名前をつけるという規則に従う必要があります。 たとえば、mydomain1 に myserver というサーバ インスタンスがある場合は、mydomain2 に myserver という WebLogic Server インスタンスを作成することはできません。 同様に、JMS のサブシステム レベルにおいて、別々のドメインにある場合であっても、名前が同じ 2 つの JMS サーバまたはストアを持つことはできません。 JMS リソースの命名要件の詳細については、ドメインの相互運用性を実現するための JMS リソースの命名規則を参照してください。

注意: 外部 JMS プロバイダ機能を使用して WebLogic Server のクラスタやドメインを参照するには、クラスタ化された JMS ライセンスが必要です。このライセンスにより、接続プールや送り先を別のサーバ インスタンスに配置することが可能になります。

以下の節では、[外部 JMS サーバ] ノードの機能、コンフィグレーション手順、およびリモート MQSeries JNDI プロバイダにアクセスするためのサンプル コンフィグレーションについて説明します。

WebLogic JMS から外部 JMS プロバイダへのアクセス

外部 JMS サーバがデプロイされると、WebLogic Server JNDI にローカルの接続ファクトリと送り先のオブジェクトが作成されます。外部 JMS 接続ファクトリまたは送り先のオブジェクトがローカル サーバでルックアップされると、そのオブジェクトはリモート JNDI ディレクトリで実際のルックアップを実行し、そのディレクトリから外部オブジェクトが返されます。

この方法を使用すると、複数の WebLogic メッセージング ブリッジ送り先のコンフィグレーションが簡単になります。外部 JMS サーバが、JNDI 初期コンテキスト ファクトリおよび接続 URL のコンフィグレーションの詳細をメッセージング ブリッジ送り先のコンフィグレーションの外側に移すからです。外部接続ファクトリおよび送り先 JNDI 名をオブジェクトごとに指定するだけで済みます。

メッセージング ブリッジの詳細については、ブリッジのリソース アダプタについてを参照してください。

また、このコンフィグレーションの簡素化は、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 ファイルを復元して編集する必要はありません。

外部 JMS サーバの作成

外部 JMS サーバは、WebLogic JMS サーバの外部にある JNDI プロバイダを表します。 外部 JMS サーバには、ローカル WebLogic Server インスタンスがリモート JNDI プロバイダにアクセスするための情報が含まれています。これにより、1 つの JNDI ディレクトリに対して複数の外部 JMS 接続ファクトリと送り先のオブジェクトを定義できます。

外部 JMS サーバを定義したら、接続ファクトリおよび送り先のオブジェクトをコンフィグレーションできます。外部 JMS サーバごとに、1 つまたは複数の接続ファクトリと送り先 (キューまたはトピック) をコンフィグレーションできます。

外部 JMS サーバをコンフィグレーションするには、次の手順に従います。

  1. ナビゲーション ツリーで [JMS] ノードを展開し、[外部 JMS サーバ] ノードをクリックします。
  2. 右ペインで [新しい外部 JMS サーバのコンフィグレーション] リンクをクリックします。ダイアログが表示され、新しい外部 JMS サーバのコンフィグレーションに関連するタブが示されます。
  3. [コンフィグレーション｜一般] タブで、[名前]、[JNDI 初期コンテキスト ファクトリ]、[JNDI 接続 URL]、および [JNDI プロパティ] の各フィールドに値を入力します。

    4. 外部 JMS サーバの一般属性の詳細については、[外部 JMS サーバ] --> [コンフィグレーション] --> [一般]を参照してください。

    注意: [JNDI プロパティ] フィールドに外部 JMS プロバイダ用のサードパーティ クラスが含まれている場合、それらのクラスは、APP-INF/lib ディレクトリの EAR ファイル内でアプリケーション スコープにならないため、システム CLASSPATH にも指定されている必要があります。


     
  4. [作成] をクリックして、[名前] フィールドに指定した名前で 外部 JMS サーバ インスタンスを作成します。ナビゲーション ツリーの [外部 JMS サーバ] ノードの下に新しいインスタンスが追加され、そのインスタンスの下に [外部 JMS 接続ファクトリ] ノードと [外部 JMS 送り先] ノードが自動的に追加されます。
  5. [対象] タブで、外部 JMS サーバのデプロイ先となるスタンドアロンの WebLogic Server インスタンスまたはクラスタを選択します。
    • [サーバ] タブ—[選択可] リストで、外部 JMS サーバ オブジェクトのデプロイ先となる WebLogic Server インスタンスを選択します。
    • [クラスタ] タブ—[対象] リストで WebLogic Server クラスタを選択すると、クラスタ内のすべてのノードに外部 JMS サーバ オブジェクトがデプロイされます。

      • 注意: [クラスタ] タブは、JMS サーバが WebLogic Server クラスタ環境の一部である場合にのみ使用できます。

  6. [適用] をクリックして外部 JMS サーバを割り当てます。

続いて、接続ファクトリおよび送り先のオブジェクトをコンフィグレーションします。外部 JMS サーバごとに、1 つまたは複数の接続ファクトリと送り先 (キューまたはトピック) をコンフィグレーションできます。

外部 JMS 接続ファクトリの作成

外部 JMS 接続ファクトリには、リモート JNDI プロバイダ内の接続ファクトリの JNDI 名、接続ファクトリがマップされるローカル WebLogic Server JNDI ツリー内の JNDI 名、および省略可能なユーザ名とパスワードが含まれています。

外部 JMS 接続ファクトリは、親の外部 JMS サーバの割り当て先となる各 WebLogic Server に対してレプリケートされていない JNDI オブジェクトを作成します(クラスタ内の各ノードに JNDI オブジェクトを作成するには、クラスタに外部 JMS サーバを割り当てます)。

外部 JMS 接続ファクトリをコンフィグレーションするには、次の手順に従います。

  1. [外部 JMS サーバ] ノードを展開し、[外部 JMS 接続ファクトリ] ノードを展開します。
  2. [新しい外部 JMS 接続ファクトリのコンフィグレーション] テキスト リンクをクリックします。右ペインにダイアログが表示され、新しい外部 JMS 接続ファクトリのコンフィグレーションに関連するタブが示されます。
  3. [コンフィグレーション｜一般] タブで、[名前]、[ローカル JNDI 名]、[リモート JNDI 名]、[ユーザ名]、および [パスワード] の各属性フィールドに値を入力します。

    4. 外部 JMS 接続ファクトリの [一般] タブにある属性の詳細については、[外部 JMS 接続ファクトリ] --> [コンフィグレーション] --> [一般]を参照してください。


     

    注意: ユーザ名およびパスワードは、EJB またはサーブレットの resource-reference 内で外部 JMS 接続ファクトリを使用する場合、および認証のコンテナ モードを使用する場合にのみ使用されます。

  4. [作成] をクリックして、[名前] フィールドで指定した名前で外部 JMS 接続ファクトリ インスタンスを作成します。ナビゲーション ツリーの [外部 JMS 接続ファクトリ] ノードの下に新しいインスタンスが追加されます。

続いて、送り先オブジェクトをコンフィグレーションします。外部 JMS サーバごとに、1 つまたは複数の送り先 (キューまたはトピック) をコンフィグレーションできます。

外部 JMS 送り先の作成

外部 JMS 送り先は、キューまたはトピックのどちらかを表します。外部 JMS 送り先には、外部 JNDI プロバイダでルックアップされる送り先 JNDI 名、およびローカル WebLogic Server で送り先がマップされる JNDI 名が含まれています。外部送り先がローカル サーバでルックアップされる場合、ルックアップはリモート JNDI ディレクトリで実行され、そのディレクトリから送り先オブジェクトが返されます。

外部 JMS 送り先をコンフィグレーションするには、次の手順に従います。

  1. [外部 JMS サーバ] ノードを展開し、[外部 JMS 送り先] ノードを展開します。
  2. [新しい外部 JMS 送り先のコンフィグレーション] テキスト リンクをクリックします。右ペインにダイアログが表示され、外部送り先のコンフィグレーションに関連するタブが示されます。
  3. [コンフィグレーション｜一般] タブで、[名前]、[ローカル JNDI 名]、および [リモート JNDI 名] の各属性フィールドに値を入力します。

    4. 外部 JMS 送り先の一般属性の詳細については、[外部 JMS 送り先] --> [コンフィグレーション] --> [一般]を参照してください。


     
  4. [作成] をクリックして、[名前] フィールドで指定した名前で外部 JMS 送り先インスタンスを作成します。ナビゲーション ツリーの [外部 JMS 送り先] ノードの下に新しいインスタンスが追加されます。

MQSeries JNDI 用のサンプル コンフィグレーション

次の表に、リモート MQSeries JNDI プロバイダにアクセスする場合のサンプル コンフィグレーションを示します。

表 48-3 サンプル MQSeries コンフィグレーション

外部 JMS オブジェクト

属性名

サンプル コンフィグレーション データ

外部 JMS サーバ

[名前]

[JNDI 初期コンテキスト ファクトリ]

[JNDI 接続 URL]

[JNDI プロパティ]

MQJNDI

com.sun.jndi.fscontext.RefFSContextFactory

file:/MQJNDI/

(If necessary, enter a comma-separated name=value list of properties.)

外部 JMS
接続ファクトリ

[名前]

[ローカル JNDI 名]

[リモート JNDI 名]

[ユーザ名]

[パスワード]

MQ_QCF

mqseries.QCF

QCF

weblogic_jms

weblogic_jms

外部 JMS
送り先 1



外部 JMS
送り先 2

[名前]

[ローカル JNDI 名]

[リモート JNDI 名]


[名前]

[ローカル JNDI 名]

[リモート JNDI 名]

MQ_QUEUE1

mqseries.QUEUE1

QUEUE_1


MQ_QUEUE2

mqseries.QUEUE2

QUEUE_2


 

外部サーバ、外部接続ファクトリ、属性、およびそれらの有効値とデフォルト値については、以下のトピックを参照してください。

 

Skip navigation bar  ページの先頭 前 次