| Oracle® Fusion Middleware Oracle WebLogic Server JMSリソースの管理 12c (12.2.1.1.0) E77273-01 |
|
 前 |
 次 |
この章の内容は次のとおりです。
WebLogic管理者は次のツールを使用して、JMSサーバーやJMSシステム・モジュールなどのシステム・リソースを作成およびデプロイ(ターゲット指定)できます。
WebLogic Server管理コンソールを使用すると、次のJMS関連リソースを構成、変更、およびターゲット指定できます。
JMSサーバー。「JMSサーバーの構成」を参照してください
JMSシステム・モジュール。「JMSシステム・モジュールの構成」を参照してください
JMSのストア・アンド・フォワード・サービス。『Oracle WebLogic Serverストア・アンド・フォワード・サービスの管理』のJMSメッセージに対するSAFの構成に関する項を参照してください。
永続ストア。『Oracle WebLogic Serverサーバー環境の管理』のWebLogic永続ストアの使用方法に関する項を参照してください。
WebLogic Scripting Tool (WLST)は、コマンド・ライン形式のスクリプト・インタフェースです。このツールを使用して、システム管理者とオペレータはWebLogic Serverの構成の変更を、対話形式または実行可能なスクリプトで開始、管理、および永続化できます。「WLSTを使用したJMSサーバーとJMSシステム・モジュール・リソースの管理」を参照してください。
Java Management Extensions (JMX)は、ネットワーク上でリソースをモニターしたり管理したりするためのJava EEソリューション。『Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発』のWebLogic ServerサブシステムMBeanの概要に関する項を参照してください。
JMSModuleHelper拡張クラスには、特定のモジュールのJMSモジュール構成リソースを作成および管理するためのメソッドが含まれています。詳細は、『Oracle WebLogic Server JMSアプリケーションの開発』のJMSモジュール・ヘルパーを使用したアプリケーションの管理に関する項またはJMSModuleHelperクラスのJavadocを参照してください。
注意:
エンタープライズ・アプリケーション内でのJMSアプリケーション・モジュールの構成およびデプロイについては、「JMSアプリケーション・モジュールのデプロイメントの構成」を参照してください。
WebLogic Server管理コンソールを使用して、永続ストア、JMSサーバー、および基本的なJMSシステム・モジュールを構成します。WebLogic Server管理コンソールを使用してWebLogic Serverドメインを管理する手順については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプを参照してください。
WebLogic JMSでは、一部の構成オプションに対するデフォルト値が用意されていますが、それ以外のすべての属性に対しては値を指定する必要があります。WebLogic JMSの構成後は、アプリケーションでJMS APIを使用してメッセージの送受信ができるようになります。デフォルト構成パラメータの調整の詳細は、Oracle WebLogic Server MBeanリファレンスのOracle WebLogic Serverのパフォーマンス・チューニングに関する項またはJMSBeanに関する項を参照してください。
WebLogic JMSでは、一部の構成オプションに対するデフォルト値が用意されていますが、それ以外のすべての属性に対しては値を指定する必要があります。WebLogic JMSの構成後は、アプリケーションでJMS APIを使用してメッセージの送受信ができるようになります。
JMSシステム・モジュールには、基本的なJMSリソース構成以外にも以下の拡張リソースを追加できます。
共通分散宛先リソースを作成して、各メンバーが別個のJMSサーバーに属するクラスタ内で分散されるキューまたはトピックのセットを構成できます。「分散宛先リソースの構成」を参照してください
JMSストア・アンド・フォワード・リソースを作成することで、送信時に宛先が使用不可能な場合にも、メッセージをリモートの宛先へ確実に転送できます。『Oracle WebLogic Serverストア・アンド・フォワード・サービスの管理』のWebLogicストア・アンド・フォワードの構成と管理に関する項を参照してください。
外部サーバー・リソースを作成して、ローカルWebLogic Server JNDIツリー内でサード・パーティのJMSプロバイダを参照するようにできます。「外部サーバー・リソースからサード・パーティJMSプロバイダへのアクセスの構成」を参照してください
ドメインの内部では、サーバー、マシン、クラスタ、仮想ホスト、およびその他のリソース・タイプのそれぞれに一意の名前を付ける必要があります。また、ドメインと同じ名前を使用することはできません。この一意の命名規則は、JMSサーバー、JMSシステム・モジュール、JMSアプリケーション・モジュールなどの構成可能なJMSオブジェクトを含む、すべての構成オブジェクトにも適用されます。
JMSモジュール内のリソースの名前は、リソース・タイプ(キュー、トピック、接続ファクトリなど)ごとに一意でなければなりません。ただし、2つの異なるJMSモジュールに、同じ名前、同じタイプのリソースを作成できます。
JMSモジュール間のバインド可能なJMSリソース(割当て制限、宛先キー、JMSテンプレートを除く)のJNDI名は、次のネーミング要件に従う必要があります。
グローバル名はクラスタ全体で一意である必要があります。
ローカル名はサーバー全体で一意である必要があります。
名前が競合する場合、JMSリソースはJNDIツリーにバインドされません。確信が持てない場合は、JNDI名をグローバルに一意にします。
注意:
2つの異なるWebLogicドメインが相互運用する場合や、クライアントが複数のWebLogicドメインと通信する場合、WebLogicドメイン、WebLogicサーバー、WebLogic JMSサーバーの名前には、一意のネーミング要件を追加する必要があります。詳細は、「統合およびマルチドメインのベスト・プラクティス」を参照してください
JMSサーバーは、それらのターゲットとして指定されたJMSモジュール内のJMSキューおよびトピック・リソースの管理コンテナとして機能する、環境関連の構成エンティティです。JMSサーバーの最も重要な役割は、JMSサーバーの宛先が受信するすべての永続メッセージに使用される永続ストアに関する情報を管理し、また、JMSサーバーの宛先で作成される恒久サブスクライバの状態を管理することです。また、ターゲット宛先のコンテナとして、JMSサーバーに対して加えられた構成の変更または実行時の変更をすべての宛先に対して有効にできます。
注意:
サンプル・サーバーの製品には、examplesJMSServerの構成例が提供されています。基本的なWebLogic JMSアプリケーションの開発の詳細は、『Oracle WebLogic Server JMSアプリケーションの開発』の基本的なJMSアプリケーションの開発に関する項を参照してください。
WebLogic Server管理コンソールを使用すると、システム・モジュール内のJMSサーバー・リソースを構成、変更、ターゲット指定、および削除できます。JMSサーバー・タスクの手順については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMSサーバーの構成に関する項を参照してください。
以下のパラメータをJMSサーバーに構成できます。
全般構成パラメータ。永続ストレージ、メッセージ・ページングのデフォルト、アプリケーションが一時的な宛先を作成する場合に使用するテンプレート、および期限切れメッセージのスキャンなどのパラメータがあります。
特定のJMSサーバーに割り当てられるJMSシステム・モジュール内の宛先のしきい値および割当てパラメータ。
JMSサーバーと宛先に対するメッセージおよびバイト割当ての構成については、『Oracle WebLogic Serverのパフォーマンスのチューニング』を参照してください。
JMSサーバーのログ・ファイル用のメッセージ・ロギング・パラメータ。ログ・ファイルには、メッセージの生成、消費、削除など、JMSメッセージが通過する基本的なイベントが記録されます。
JMSサーバーのメッセージ・ライフ・サイクル・ロギングの構成の詳細については「メッセージ・ライフ・サイクルのロギング」を参照してください
宛先の休止と再開の制御。これらを使用すると、単一のJMSサーバーによってホストされるすべての宛先でのメッセージの生成、挿入(処理中のメッセージ)、および消費処理を休止できます。
宛先でのメッセージ処理の休止については、「宛先でのメッセージ処理の制御」を参照してください
JMSサーバー・オプションの中には、動的に構成できるものもあります。オプションを実行時に変更した場合、新しく配信されるメッセージにのみ適用され、すでに保存されているメッセージには影響しません。すべてのJMSサーバー・オプションのデフォルト値の詳細は、Oracle WebLogic Server MBeanリファレンスのJMSServerBeanに関する項およびJMSServerRuntimeMBeanに関する項を参照してください。
JMSサーバーは、デプロイ先となる独立したWebLogic Serverインスタンス、(動的または混在)クラスタまたは移行可能ターゲット・サーバーのターゲットとして指定できます。
Weblogicサーバー・インスタンス - JMSサーバーのデプロイ先となるサーバー・ターゲットです。ターゲットWebLogic Serverが起動すると、JMSサーバーも起動します。ターゲットWebLogic Serverが指定されていない場合、JMSサーバーは起動しません。
クラスタをターゲットに指定したJMS - JMSサービス・アーティファクト(JMSサーバー、SAFエージェント、永続ストアおよびクラスタへのパス・サービス)をターゲットとして指定できます。
注意:
移行可能ターゲットを使用するかわりに、自動サービス移行をサポートする新しいストア構成を持つクラスタ・ターゲティングの使用をお薦めします。詳細は、「簡略化されたJMS構成と高可用性の拡張機能」を参照してください。移行可能ターゲット - 移行可能ターゲットは、JMSサーバーなどの必ず1回のサービスをホストする可能性があるクラスタ内のWebLogic Serverインスタンス・セットを定義します。移行可能ターゲット・サーバーが起動すると、JMSサーバーも、クラスタ内の指定したユーザーの優先サーバー上で起動します。ただし、JMSサーバーとそのすべての宛先は、サーバーの障害に対応するため、または予定されていた移行またはシステム・メンテナンスのためにクラスタ内の別のサーバーに移行できます。JMSサービスの移行可能ターゲットの構成については、「JMS関連サービスの移行」を参照してください。
WebLogic Server管理コンソールを使用したJMSサーバー・ターゲットの指定手順については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMSサーバー・ターゲットの変更に関する項を参照してください。JMSサーバー・ターゲット指定のベスト・プラクティスについては、「ターゲット指定のベスト・プラクティス」を参照してください
アクティブなJMSサーバー、宛先、およびサーバー・セッション・プールの実行時統計をモニターできます。
すべてのアクティブなJMSサーバーのモニター - WebLogic Serverドメイン全体にデプロイされているJMSサーバーのすべてのインスタンスを表示する表。
すべてのアクティブなJMS宛先のモニター - 現在のドメインのすべてのアクティブなJMS宛先を表示する表。
すべてのアクティブなJMSセッション・プール・ランタイムのモニター - 現在のドメインのすべてのアクティブなJMSセッション・プールを表示する表。
JMSオブジェクトの監視の詳細は、「JMS統計のモニターとメッセージの管理」を参照してください。
注意:
セッション・プールおよび接続コンシューマの構成オブジェクトは、WebLogic Server 9.xで非推奨となっています。これらは、Java EE仕様の必須コンポーネントではなく、JTAユーザー・トランザクションもサポートされていません。また、大部分がJava EEの必須コンポーネントであるメッセージドリブンBean (MDB)に取って代わられています。MDBの設計の詳細は、『Oracle WebLogic ServerメッセージドリブンBeanの開発』を参照してください。
サーバー・セッション・プールを使用すると、アプリケーションでメッセージを並行処理できます。JMSサーバーを定義したら、JMSサーバーごとに1つまたは複数のセッション・プールを構成できます。一部のセッション・プール・オプションは動的に構成できますが、新しい値はJMSサーバーを再起動するまで有効になりません。『Oracle WebLogic Server JMSアプリケーションの開発』のサーバー・セッション・プールの定義に関する項を参照してください。
接続コンシューマは、サーバー・セッションを取得してメッセージを処理するキュー(ポイント・ツー・ポイント)またはトピック(パブリッシュ/サブスクライブ)です。セッション・プールを定義したら、セッション・プールごとに1つまたは複数の接続コンシューマを構成します。『Oracle WebLogic Server JMSアプリケーションの開発』のサーバー・セッション・プールの定義に関する項を参照してください。
JMSシステム・モジュールは管理者が所有します。管理者は、いつでもJMSシステム・リソースを削除、変更、または追加できます。単一のJMSサーバーをターゲットとして指定されるスタンドアロンのキューおよびトピック・リソースを除き、システム・モジュール内の接続ファクトリ、分散宛先、外部サーバー、およびJMS SAF宛先リソースは、WebLogicドメインに構成された複数のサーバー・インスタンスとクラスタをターゲットとして指定することによってグローバルに使用できるようになります。このため、これらのリソースは、同じターゲットにデプロイされるすべてのアプリケーションとクライアント・アプリケーションで使用できます。JMSシステム・モジュールの命名規則は、MyJMSModule-jms.xmlです。
WebLogic Server管理コンソールを使用すると、使用している環境のJMSシステム・モジュールを構成、変更、ターゲット指定、監視、および削除できます。JMSシステム・モジュールの構成タスクの手順については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMSシステム・モジュールの構成およびJMSリソースの追加に関する項を参照してください。
以下の「基本的な」構成リソースをJMSシステム・モジュールの一部として定義します。
キューおよびトピック宛先。「キューおよびトピック宛先の構成」を参照。
接続ファクトリ。「接続ファクトリの構成」を参照。
テンプレート。「JMSテンプレートの構成」を参照。
宛先キー。「宛先キーの構成」を参照。
割当て。「割当ての構成」を参照。
以下の「拡張」クラスタリング構成リソースをJMSシステム・モジュールの一部として定義します。
外部サーバー。「外部サーバー・リソースからサード・パーティJMSプロバイダへのアクセスの構成」を参照。
分散宛先。「分散宛先リソースの構成」を参照。
JMSのストア・アンド・フォワードの構成。『Oracle WebLogic Serverストア・アンド・フォワード・サービスの管理』のJMSメッセージに対するSAFの構成に関する項を参照してください。
サンプル・サーバーには、製品と一緒にサンプル・モジュールとしてexamples-jmsが用意されています。サンプル・サーバーの起動の詳細は、『Oracle WebLogic Serverサーバーの起動と停止の管理』のサーバーの起動と停止に関する項を参照してください。
JMSシステム・モジュールを構成するための代替方法(WebLogic Scripting Tool (WLST)を使用する方法など)については、「JMSシステム・リソースの構成方法」を参照してください。
JMSシステム・モジュールは、1つまたは複数のWebLogic Serverインスタンスまたは1つのクラスタをターゲットとして指定されている必要があります。ターゲット指定が可能で、システム・モジュールに定義されているJMSリソースは、親モジュールのターゲットの範囲内のJMSサーバーか、WebLogic Serverインスタンスのターゲットでなければなりません。また、ターゲット指定が可能でシステム・モジュール内にあるJMSリソースは、構成またはターゲット指定のプロセス中にサブデプロイメントにグループ化して、WebLogicドメイン内のJMSリソースの結合度を一段と減らすことができます。
WebLogic Server管理コンソールでJMSシステム・モジュール内にリソースを構成する際には、親モジュールのデフォルトのターゲットを単純に受け入れることも、高度なターゲット指定のページに進んで、サブデプロイメントのメカニズムを使用してリソースをターゲット指定することもできます。ただし、スタンドアロンのキューおよびトピック・リソース・タイプではデフォルトのターゲットを使用できません。これらは単一のJMSサーバーにターゲット指定されているサブデプロイメントにターゲット指定する必要があります。
デフォルトのターゲット指定メカニズムを選択する場合、そのターゲット・ステータスはWebLogic Server管理コンソール上で当該リソース・タイプの「構成: 全般」ページにある「デフォルトのターゲット指定を有効化」チェック・ボックスに反映されます。
JMSシステム・リソースの構成の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMSシステム・モジュールのリソースの構成に関する項を参照してください。
注意:
宛先タイプの場合、デフォルトのターゲット指定はお薦めしません。かわりに、サブデプロイメントのターゲット指定を使用します。詳細は、「ターゲット指定のベスト・プラクティス」を参照してください
スタンドアロンのキューおよびトピック・リソースをターゲット指定する場合、または他のリソース・タイプに対してデフォルトのターゲット指定メカニズムをバイパスする場合、高度なターゲット指定(サブデプロイメントのターゲット指定)を使用する必要があります。サブデプロイメントとは、ターゲット指定できるシステム・モジュール・リソース(スタンドアロンの宛先、分散宛先、接続ファクトリなど)をグループ化して、システム・モジュール内のターゲット指定範囲内の特定のサーバー・リソースに割り当てるメカニズムです。
JMSシステム・モジュールはドメイン内の広範なWebLogic Serverインスタンスにターゲット指定できますが、モジュールのスタンドアロンのキューやトピックは、単一のJMSサーバーにのみ割り当てることができます。接続ファクトリ、共通分散宛先(UDD)、および外部サーバーは、1つまたは複数のJMSサーバー、1つまたは複数のWebLogic Serverインスタンス、あるいはクラスタに割り当てることができます。
したがってスタンドアロンのキューまたはトピックは、サブデプロイメントの他のメンバーが複数のJMSサーバーにターゲット指定されている場合、そのサブデプロイメントに関連付けられません。このような例としては、接続ファクトリがドメイン内のJMSサーバーをホストするクラスタに対してターゲット指定されている場合などが挙げられます。UDDを使用すると、こうしたサブデプロイメントとも関連付けることができます。これは、UDDがドメイン内の複数のJMSサーバーに対してメンバーを分散させることを目的としているためです。
表3-1にJMSシステム・リソースのサブデプロイメントの有効なターゲット指定オプションを示します。
表3-1 JMSシステム・リソースのサブデプロイメントのターゲット指定
| JMSリソース | 有効なターゲット |
|---|---|
キュー |
JMSサーバー |
トピック |
JMSサーバー |
接続ファクトリ |
JMSサーバー(複数可)、サーバー・インスタンス(複数可)、クラスタ |
共通分散キュー |
JMSサーバー(複数可)、サーバー・インスタンス(複数可)、クラスタ |
共通分散トピック |
JMSサーバー(複数可)、サーバー・インスタンス(複数可)、クラスタ |
外部サーバー |
JMSサーバー(複数可)、サーバー・インスタンス(複数可)、クラスタ |
SAFインポート済み宛先 |
SAFエージェント(複数可)、サーバー・インスタンス(複数可)、クラスタ |
注意:
接続ファクトリ、共通分散宛先、外部サーバー、およびSAFインポート済み宛先リソースは、デフォルトでそれらの親モジュールのターゲットを指定するよう構成することもできます。「デフォルトのターゲット指定」を参照してください
デフォルトのターゲット指定、サーバー・インスタンスのターゲット指定、クラスタのターゲット指定は、どのタイプの宛先(非分散宛先、分散宛先、またはSAFインポート宛先)にも推奨されません。かわりに、JMSサーバーを含むサブデプロイメントのターゲット(SAFインポート宛先の場合はSAFエージェントを含むサブデプロイメントのターゲット)を使用します。「ターゲット指定のベスト・プラクティス」を参照してください"
スタンドアロンのキューまたはトピックの単純なサブデプロイメントの例として、それらを接続ファクトリとともにグループ化して特定のJMSサーバーに配置することが考えられます。これにより、ネットワーク・トラフィックが減少します。また、ターゲットのJMSサーバーを別のWebLogic Serverインスタンスに移行する必要がある場合、接続ファクトリとそのすべての接続もJMSサーバーの宛先と一緒に移行されます。
たとえば、jmssysmod-jms.xmlという名前のシステム・モジュールが、jmsserver1とjmsserver2という構成済の2つのJMSサーバーを持つWebLogic Serverインスタンスのターゲットとして指定され、2つのキューと1つの接続ファクトリをjmsserver1のみに配置する場合、これらのキューと接続ファクトリをjmsserver1groupという名前の同じサブデプロイメントにグループ化すると、これらのリソースを常にjmsserver1にリンクできます(接続ファクトリが複数のJMSサーバーに関連付けられていない場合)。
<weblogic-jms xmlns="http://xmlns.oracle.com/weblogic/weblogic-jms">
<connection-factory name="connfactory1">
<sub-deployment-name>jmsserver1group</sub-deployment-name>
<jndi-name>cf1</jndi-name>
</connection-factory>
<queue name="queue1">
<sub-deployment-name>jmsserver1group</sub-deployment-name>
<jndi-name>q1</jndi-name>
</queue>
<queue name="queue2">
<sub-deployment-name>jmsserver1group</sub-deployment-name>
<jndi-name>q2</jndi-name>
</queue>
</weblogic-jms>
次に、ドメインの構成ファイルでのjmsserver1groupサブデプロイメントのターゲット指定を示します。
<jms-system-resource>
<name>jmssysmod-jms</name>
<target>wlsserver1</target>
<sub-deployment>
<name>jmsserver1group</name>
<target>jmsserver1</target>
</sub-deployment>
<descriptor-file-name>jms/jmssysmod-jms.xml</descriptor-file-name>
</jms-system-resource>
JMSシステム・モジュールのサブデプロイメントを簡単に管理するため、WebLogic Server管理コンソールにサブデプロイメントの管理用ページが用意されています。詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMSシステム・モジュールのサブデプロイメントの構成に関する項を参照してください。
スタンドアロンJMSモジュールのデプロイについては、『Oracle WebLogic Serverへのアプリケーションのデプロイ』のJDBC、JMS、およびWLDFアプリケーション・モジュールのデプロイに関する項を参照してください。
EJBまたはサーブレットで@Resourceアノテーションを使用するか、デプロイメント記述子の resource-ref要素を使用してJMS接続ファクトリを宣言する場合に、このリソース参照が参照属性またはmappedName属性(またはjndi-name)によってJNDI名に直接マップされていないと、WebLogic Serverでは、そのようなJMS接続ファクトリへのマップされないリソース参照の動作を指定できます。JNDI名がリソース参照にマップされている場合、マップされないリソース参照モードは有効になりません。また、リソース参照は、JNDIで指定されたオブジェクトに解決されるか、例外javax.naming.NameNotFoundExceptionを生成します。
リモート参照の詳細は、『Oracle WebLogic Server JMSアプリケーションの開発』のEJBとサーブレットにWebLogic JMSを使用するための拡張サポートに関する章を参照してください
WebLogic Server管理コンソール上で、サーバーの「接続ファクトリのマップされないリソース参照モード」パラメータに指定した値は、JMS接続ファクトリへのリソース参照の動作を決定します。可能な値は次のとおりです。
ReturnDefault: リソース参照が構成された外部JMSプロバイダのローカルJNDI名と一致しない場合や、JNDIツリーにバインドされたオブジェクトと一致しない場合、java:comp/DefaultJMSConnectionFactoryが戻されます。これはJava EE 7仕様で定義されたデフォルトJMS接続ファクトリです。「Java EE 7で定義されているデフォルトのJMS接続ファクトリの使用」を参照してください。
FailSafe: リソース参照は、リソース参照名と同じ名前のJNDIツリーにバインドされたオブジェクトに解決されます(JNDIに見つからない場合)。そうでない場合は、例外javax.naming.NameNotFoundExceptionがスローされます。
マップされないリソース参照モードの値の詳細は、『Oracle WebLogic Server MBeanリファレンス』の、JMSConnectionFactoryUnmappedResRefMode属性の定義を参照してください。
接続ファクトリは、JMSクライアントがJMS接続を作成できるようにするリソースです。接続ファクトリでは同時使用がサポートされており、複数のスレッドがオブジェクトに同時にアクセスできます。WebLogic JMSには、サーバー単位で有効/無効を切り替えられる構成済のデフォルト接続ファクトリが用意されています(「WebLogic Serverで定義されたデフォルト接続ファクトリの使用」を参照)。
デフォルトの接続ファクトリを使用しない場合、1つまたは複数の接続ファクトリを構成して、使用するアプリケーションに合わせて定義したオプションで接続を作成します。各JMSモジュール内では、接続ファクトリ・リソースの名前は一意でなければなりません。また、「JMS構成のネーミング要件」で定義したように、あらゆるJMSモジュールの接続ファクトリのJNDI名もすべて、WebLogicドメイン全体で一意でなければなりませんWebLogic Serverでは、こうした名前が起動時にJNDIスペースへ追加された後、アプリケーションでWebLogic JNDI APIを使用して接続ファクトリが取得されます。
クラスタ内のあらゆるサーバーからJMS宛先へのクラスタ全体で透過的なアクセスを確立するには、サーバー・インスタンスごとにデフォルト接続ファクトリを使用するか、クラスタ内の1つまたは複数のサーバー・インスタンスをターゲットとする1つまたは複数の接続ファクトリを構成します。これにより、各接続ファクトリを複数のWebLogic Serverインスタンスにデプロイできます。JMSのクラスタリングの構成の詳細は、「WebLogic JMSクラスタリングの構成」を参照してください
WebLogic Serverは、Java EE 7プラットフォーム仕様で定義されたデフォルトJMS接続ファクトリをサポートします。このデフォルト接続ファクトリはjava:comp/DefaultJMSConnectionFactory JNDI名を使用してルックアップできる一方、@Resourceアノテーションを使用してアクセスすることもできます。java:comp/DefaultJMSConnectionFactory JNDI名は、デフォルトのweblogic.jms.XAConnectionFactoryと同等のものに解決されます。
注意:
@ResourceとContext.lookup()を使用したDefaultJMSConnectionFactoryのルックアップは、常にプールおよびラップされた接続ファクトリを戻すため、リソースは確実に十分なパフォーマンスを提供し、サーバー側JMS API使用量のJava EE制限は確実に正しく強制適用されます。WebLogic Serverで定義されたデフォルト接続ファクトリとは異なり、Java EE 7のデフォルト接続ファクトリは、Java EEアプリケーション内からのみアクセスできます。Java EE 7接続ファクトリは、アプリケーション・クライアント・コンテナ・ファシリティを使用しないかぎり、スタンドアロン・クライアントからはアクセスできません。
注意:
デフォルトの接続ファクトリはチューニングできないため、デフォルトの接続ファクトリではなく、カスタム接続ファクトリを使用することをお薦めします。チューニング可能なカスタム接続ファクトリは、アプリケーションを本番環境に導入した後でも、アプリケーションのチューニングに役立つことがよくあります
WebLogic Server管理者がWebLogic ServerごとにデフォルトJMS接続ファクトリを無効にすることはできません。
詳細は、『Oracle WebLogic Server JMSアプリケーションの開発』の、JNDIでの接続ファクトリのルックアップに関する項を参照してください。
WebLogic Serverは、次のJNDI名を使用してルックアップできる、2つのデフォルト接続ファクトリを定義します。
weblogic.jms.ConnectionFactory
weblogic.jms.XAConnectionFactory
新しい接続ファクトリの構成は、デフォルト接続ファクトリの構成済設定がアプリケーションに適さない場合にのみ行います。デフォルトの接続ファクトリの使用の詳細は、『Oracle WebLogic Server JMSアプリケーションの開発』のWebLogic JMSの理解に関する項を参照してください。
デフォルト接続ファクトリの構成済設定とユーザー定義の接続ファクトリの主な違いは、JTAトランザクションを有効にするための「XA接続ファクトリの有効化」オプションのデフォルト値です。「XA接続ファクトリの有効化」オプションの詳細、およびその他の接続ファクトリ・オプションのデフォルト値については、Oracle WebLogic Server MBeanリファレンスのJMSConnectionFactoryBeanに関する項を参照してください。
また、デフォルト接続ファクトリを使用する場合、接続ファクトリがデプロイされる可能性のあるWebLogic Serverインスタンスを限定できません。ただし、WebLogic Server単位でデフォルト接続ファクトリを有効化および無効化することはできます。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのサーバー: 構成: サービスに関する項を参照してください。
注意:
デフォルトの接続ファクトリはチューニングできないため、デフォルトの接続ファクトリではなく、カスタム接続ファクトリを使用することをお薦めします。カスタム接続ファクトリはチューニング可能であるため、アプリケーションを本番環境にした後でもアプリケーションのチューニングをする場合に役立ちます。
WebLogic Server管理コンソールを使用すると、システム・モジュール内の接続ファクトリ・リソースを構成、変更、ターゲット指定、および削除できます。JMS接続の構成タスクの手順については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの接続ファクトリの構成に関する項を参照してください。
接続ファクトリの以下のパラメータを変更できます。
全般構成パラメータ。デフォルト・クライアント・パラメータの変更、デフォルト・メッセージ配信パラメータ、ロード・バランシング・パラメータ、順序単位パラメータ、セキュリティ・パラメータなどが含まれます。
トランザクション・パラメータ。これらを使用すると、トランザクション・タイムアウト・オプションの値の定義、XAキューまたはXAトピック接続ファクトリが返されるどうかの指定、および接続ファクトリでJTA対応セッションが作成されるかどうかの指定ができます。
注意:
XA接続ファクトリを有効化オプションを選択して、JDBCストアでJTAトランザクションを有効にした場合は、構成済のJDBCデータ・ソースがXA非対応のJDBCドライバを使用することを確認する必要があります。この制約によって、JDBCストアを使用するレイヤー・サブシステムのXA機能が使用できなくなるわけではありません。たとえば、WebLogic JMSは、ファイル・ストアやJDBCストアを使用するかどうかに関係なく完全にXA機能を使用できます。
フロー制御パラメータ。これらを使用すると、JMSサーバーまたは宛先で過負荷の状態になりつつあると判断された場合にメッセージ・プロデューサを低速化できます。
接続ファクトリのオプションの中には、動的に構成できるものもあります。オプションを実行時に変更した場合、新しく配信されるメッセージにのみ適用され、すでに保存されているメッセージには影響しません。接続ファクトリのオプションすべてのデフォルト値の詳細は、Oracle WebLogic Server MBeanリファレンスのJMSConnectionFactoryBeanに関する項を参照してください。
接続ファクトリは、1つまたは複数のJMSサーバー、1つまたは複数のWebLogic Serverインスタンス、または1つのクラスタのターゲットとして指定できます。
JMSサーバー - 接続ファクトリは、宛先と共に1つまたは複数のJMSサーバーのターゲットとして指定できます。また、接続ファクトリは、スタンド・アロンのキューまたはトピックとともに、特定のJMSサーバーのターゲットとなるサブデプロイメントにグループ化できます。これにより、グループ化されたすべてのリソースが同じ場所に配置され、余分なネットワーク・トラフィックを回避できます。この構成のもう1つのメリットは、ターゲットのJMSサーバーを別のWebLogic Serverインスタンスに移行する必要がある場合に、接続ファクトリとその接続のすべてがJMSサーバーの宛先と一緒に移行されることです。ただし、スタンドアロンのキューまたはトピックがサブデプロイメントのメンバーの場合は、接続ファクトリを同じJMSサーバー以外に関連付けることはできません。
WebLogicサーバー・インスタンス - ドメイン内のあらゆるサーバーからJMS宛先への透過的なアクセスを確立するために、接続ファクトリを複数のWebLogic Serverインスタンスに同時に関連付けることができます。
クラスタ - クラスタ内のすべてのサーバー・インスタンスまたは特定のサーバーに1つの接続ファクトリを関連付けることで、クラスタ内のあらゆるサーバーからJMS宛先へのクラスタ全体で透過的なアクセスを確立できます。
JMSシステム・モジュールのサブデプロイメントのターゲット指定の詳細は、「JMSシステム・モジュールとリソースのサブデプロイメントのターゲット指定」を参照してください。接続ファクトリのターゲット指定のベスト・プラクティスについては、「ターゲット指定のベスト・プラクティス」を参照してください
JMS宛先は、JMSモジュール内のキュー(ポイント・ツー・ポイント)またはトピック(パブリッシュ/サブスクライブ)リソースを識別するものです。各キューおよびトピック・リソースは、特定のJMSサーバーのターゲットとして指定されます。JMSサーバーの最も重要な役割は、JMSサーバーの宛先が受信するすべての永続メッセージに使用される永続ストアに関する情報を管理し、また、JMSサーバーの宛先で作成される恒久サブスクライバの状態を管理することです。
必要な場合、JMSテンプレート、割当て設定、宛先ソート・キーなど、キューまたはトピック内から参照できる他のJMSリソースをモジュール内に作成できます。
割当: 割当てを宛先に割り当てたり、複数の宛先が1つの割当てを共有したり、宛先がJMSサーバーの割当てを共有することができます。『Oracle WebLogic Serverのパフォーマンスのチューニング』を参照してください。
JMSテンプレート: 同じようなオプション設定で複数の宛先を定義できます。JMSテンプレートは、一時キューの作成にも必要です。「JMSテンプレートの構成」を参照してください
宛先キー: 宛先で受信するメッセージのソート順序を独自に定義できます。「宛先キーの構成」を参照してください
JMSキューは、JMSサーバーのポイント・ツー・ポイント宛先タイプを定義します。キューに配信されたメッセージは、1つのコンシューマに配信されます。JMSトピックは、JMSサーバーのパブリッシュ/サブスクライブ宛先タイプを識別します。トピックは、非同期のピア通信に使用されます。トピックに配信されたメッセージは、そのトピックでサブスクライブしているすべてのコンシューマに配信されます。
WebLogic Server管理コンソールを使用すると、システム・モジュール内のキューおよびトピック・リソースを構成、変更、ターゲット指定、および削除できます。キューおよびトピックのタスクの手順については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのキューの構成に関する項およびトピックの構成に関する項を参照してください。キューおよびトピック・リソースの名前は、各JMSモジュール内で一意でなければなりません。また、各JMSモジュール内のすべてのキューおよびトピックのJNDI名は、WebLogicドメイン全体にわたって一意でなければなりません(「JMS構成のネーミング要件」を参照)。
以下のパラメータをキューまたはトピックに構成できます。
全般構成パラメータ。JNDI名、宛先に届くメッセージをソートする宛先キー、または複数の宛先のプロパティの構成にJMSテンプレートを使用する場合のJMSテンプレートの選択などのパラメータがあります。
注意:
キューおよびトピックのJNDI名は動的に変更できますが、MDBのように長期間存続するプロデューサまたはコンシューマは、変更後もキューまたはトピックの元のJNDI名からメッセージを生成したり、元のJNDI名にメッセージを送信したりしようとすることがあります。
しきい値および割当てパラメータ。これらのパラメータによって、宛先のメッセージ数またはバイト数の最大および最小しきい値と最大割当てを定義します。「割当ての構成」を参照してください。
メッセージ・ロギング・パラメータ。メッセージ・タイプ、ユーザー・プロパティ、JMSログ・ファイルに含めるロギング・メッセージのライフ・サイクル情報などがあります。
「メッセージ・ライフ・サイクルのロギング」を参照してくださいメッセージの生成、メッセージの挿入(処理中のメッセージ)、および宛先でのメッセージの消費の処理についての停止と再開を制御します。「宛先でのメッセージ処理の制御」を参照してください
メッセージ配信オーバーライド・パラメータ。メッセージの優先度や配信時間の値など、メッセージ・プロデューサまたは接続ファクトリによって指定されている値をオーバーライドできます。
メッセージ配信の失敗に関するパラメータ。再配信の制限の定義、メッセージ有効期限ポリシーの選択、期限切れメッセージのエラー宛先の指定などが含まれます。
(トピックのみ)マルチキャスト・パラメータ。マルチキャスト・アドレス、存続時間(TTL)、ポートなどがあります。
オプションの中には、動的に構成できるものもあります。オプションが実行時に変更された場合、変更は新しく配信されるメッセージにのみ適用され、格納されているメッセージには影響しません。すべてのオプションのデフォルト値については、Oracle WebLogic Server MBeanリファレンスのQueueBeanに関する項およびTopicBeanに関する項を参照してください。
リカバリまたはロールバックされるメッセージを管理するために、再配信の制限に達したメッセージのエラー宛先を構成することもできます。エラー宛先はキューまたはトピックのいずれかにできますが、関連付けられている宛先と同じJMSサーバーのターゲットでなければなりません。詳細は、『Oracle WebLogic Server JMSアプリケーションの開発』の配信されなかったメッセージのエラー宛先の構成に関する項を参照してください。
分散宛先リソースは、単一の論理的な単位としてクライアントからアクセス可能な宛先のグループ(キューまたはトピック)です(たとえば分散トピックは独自のJNDI名を持ちます)。このセットのメンバーは通常、クラスタ内の複数のサーバーに分散されており、各メンバーは別々のJMSサーバーに属しています。「分散宛先の構成」を参照してください
スタンドアロンのキューおよびトピックは、ドメイン内の特定のJMSサーバーのみにデプロイできます。これは、永続メッセージ、恒久サブスクライバ、およびメッセージ・ページングの管理に関して、キューおよびトピックがターゲット指定されたJMSサーバーに依存するためです。
キューまたはトピックのグループを接続ファクトリとともに特定のJMSサーバーに関連付ける場合、これらの送り先と接続ファクトリを同じサブデプロイメントの対象として指定します。これにより、これらのリソースはサブデプロイメントの対象となるJMSサーバーに関連付けられます。ただし、スタンドアロンの宛先がサブデプロイメントのメンバーの場合は、接続ファクトリを同じJMSサーバー以外に関連付けることはできません。
JMSシステム・モジュールのサブデプロイメントのターゲット指定については、「JMSシステム・モジュールとリソースのサブデプロイメントのターゲット指定」を参照してください接続ファクトリのターゲット指定のベスト・プラクティスについては、「ターゲット指定のベスト・プラクティス」を参照してください
システム・モジュール内のキューおよびトピックの実行時統計をモニターできます。また、キューのメッセージおよびトピックの恒久サブスクライバを管理できます。
WebLogic Server管理コンソールを使用したキューのモニターの詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMSシステム・モジュールのキューのモニターに関する項を参照してください。
キューのメッセージの管理については、「JMSメッセージの管理」を参照してください。
WebLogic Server管理コンソールを使用したトピックのモニターの詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMSシステム・モジュールのトピックのモニターに関する項を参照してください
トピックの恒久サブスクライバの管理については、「JMSメッセージの管理」を参照してください。
JMSテンプレートを使用すると、同じようなオプション設定を持つ複数の宛先を効率的に定義できます。
新しい宛先を定義するたびに、すべてのオプション設定を再入力する必要はありません。JMSテンプレートを使用して、新しい値の割当てが必要な設定のみをオーバーライドします。
テンプレートを変更するだけで、共有されるオプション設定を動的に変更できます。
エラー宛先のサブデプロイメントを定義して、任意の数の宛先のサブデプロイメント(キューまたはトピックのグループ)が対応するテンプレート・サブデプロイメントで指定されたエラー宛先のみを使用するようにできます。
WebLogic Server管理コンソールを使用すると、システム・モジュール内のJMSテンプレート・リソースを構成、変更、ターゲット指定、および削除できます。JMSテンプレートのタスクの手順については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMSテンプレートの構成に関する項を参照してください。
JMSテンプレートに構成できるオプションは、宛先に構成されるオプションと同じです。「キューおよびトピックの構成パラメータ」を参照してください
これらの構成オプションは、それらを使用する宛先によって継承されます。ただし、以下の例外があります。
JMSテンプレートを使用する宛先でオプションのオーバーライド値が指定される場合は、そのオーバーライド値が使用されます。
JMSテンプレートを使用する宛先でオプションのメッセージ再配信値が指定される場合は、その再配信値が使用されます。
「名前」オプションは、宛先によって継承されません。この名前はJMSテンプレートでのみ有効です。宛先では、個々に一意の名前を明示的に定義しなければなりません。「JMS構成のネーミング要件」を参照してください
「JNDI名」、「ストアを有効化」、「テンプレート」の各オプションは、JMSテンプレートでは定義されません。
任意の数の宛先のサブデプロイメント(キューまたはトピックのグループ)が、対応するテンプレート・サブデプロイメントで指定されたエラー宛先のみを使用するように、エラー宛先のサブデプロイメントを構成できます。
宛先に対して明示的に定義されないオプションには、デフォルト値が割り当てられます。デフォルト値が存在しない場合は、JMSテンプレート内で値を指定するか、宛先のオプションのオーバーライドとして値を指定します。
テンプレート・オプションの中には、動的に構成できるものもあります。オプションを実行時に変更した場合、新しく配信されるメッセージにのみ適用され、すでに保存されているメッセージには影響しません。すべてのトピック・オプションのデフォルト値の詳細は、Oracle WebLogic Server MBeanリファレンスのTemplateBeanに関する項を参照してください。
特定の宛先に到着したメッセージは、デフォルトではFIFO (先入れ先出し)で格納され、各メッセージの一意のJMSMessageIDに基づいて昇順にソートされます。しかし、宛先キーを使用することで、宛先に対してLIFO (後入れ先出し)などの異なるソート方式を構成できます。
WebLogic Server管理コンソールを使用すると、システム・モジュール内の宛先キー・リソースを構成、変更、ターゲット指定、および削除できます。宛先キーのタスクの手順については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの宛先キーの構成に関する項を参照してください。
すべての宛先キー・オプションのデフォルト値については、Oracle WebLogic Server MBeanリファレンスのDestinationKeyBeanに関する項を参照してください。
割当てリソースでは、メッセージおよびバイトの最大数を定義します。これを1つまたは複数の宛先に関連付けることで、定義した最大数を強制することができます。
『Oracle WebLogic Serverのパフォーマンスのチューニング』を参照してください。
外部サーバー・リソースにより、ローカルのWebLogic ServerのJNDIツリー内で、サード・パーティのJMSプロバイダを参照できます。外部サーバー・リソースを使用することで、外部のJMSプロバイダを即座にマップして、関連付けられた接続ファクトリと宛先をローカルJMSオブジェクトのようにWebLogic JNDIツリーに表示できます。また、別のクラスタまたはドメインにあるWebLogic Serverのリモート・インスタンスをローカルWebLogic JNDIツリー内で参照することもできます。
分散宛先リソースは、単一の論理的な宛先としてクライアントからアクセス可能な1つの宛先セット(キューまたはトピック)です(たとえば分散トピックは独自のJNDI名を持ちます)。このセットのメンバーは通常、クラスタ内の複数のサーバーに分散されており、各メンバーは別々のJMSサーバーに属しています。分散宛先を使用するアプリケーションは、スタンドアロンの宛先を使用するアプリケーションより可用性が高くなります。これは、WebLogic JMSに、クラスタ内の分散宛先メンバーのためのロード・バランシングおよびフェイルオーバー機能があるためです。
「分散宛先リソースの構成」を参照してください
JMS SAFリソースは、WebLogicストア・アンド・フォワード(SAF)サービス上に構築され、高可用性を備えたJMSメッセージ生成を行います。たとえば、ローカルのサーバー・インスタンスに接続されたJMSメッセージ・プロデューサは、メッセージ送信時にリモートのJMS宛先が一時的に使用できない場合でも、そのリモート宛先に確実にメッセージを転送できます。JMSストア・アンド・フォワードはJMSアプリケーションからは透過的なので、JMSクライアント・コードは既存のJMS APIを使用して、リモートの宛先にアクセスできます。
詳細は、『Oracle WebLogic Serverストア・アンド・フォワード・サービスの管理』のJMSメッセージに対するSAFの構成に関する項を参照してください。
