| Oracle® Fusion Middleware Oracle WebLogic Server JMSリソースの管理 12c (12.2.1.2.0) E82889-02 |
|
 前 |
 次 |
この章の内容は次のとおりです。
次の項では、JMSアプリケーションの構成方法に関する基本手順の概要を示します。
JMSサーバーと永続ストアを構成する前に、次の内容を検討します。
宛先、接続ファクトリ、およびその他のJMSリソースが、そのホストJMSサーバーおよび永続ストアとは別に構成されています。JMSリソースを構成するベスト・プラクティスの手順については後ほど説明します。
WebLogic分散宛先を利用する場合、WebLogicクラスタを、そのクラスタの各WebLogicサーバーのJMSサーバーとカスタム永続ストアで構成する必要があります。WebLogic JMS分散宛先が機能するには、WebLogicクラスタが機能している必要があります。
クラスタ化されたJMSサーバーは、すべてのWebLogic JMS機能(順序単位、シングルトン宛先、ストア・アンド・フォワード・エージェントなど)をサポートするわけではありませんが、簡略化された構成と、リソースの規模の動的変更を可能にします。「簡略化されたJMSクラスタと高可用性の構成」を参照してください
移行可能ターゲットのみがクラスタでサポートされます。クラスタを使用していない場合、サイズ1のクラスタを再検討して使用できます。これにより、移行可能ターゲットを使用できます。移行可能ターゲットを使用すると、次に示すように便利な再起動インプレース機能が有効になります。また、単一サーバーから複数サーバーへの拡張プロセスが容易になるため、アプリケーションの将来保証にも役立ちます。
注意:
高可用性については、移行可能なターゲットを使用するかわりに、適切な高可用性構成設定とともにJMSアーティファクトにクラスタをターゲットとして指定することをお薦めします。構成済クラスタにJMSサーバーと永続ストアを構成するには、次の手順を実行します。
同種のJMSサーバーのセットは、分散ポリシーが「Distributed」に設定された、クラスタをターゲットとして指定された単一JMSサーバーか、それぞれが同じ分散宛先をホストするように同様に構成されたJMSサーバーのセットになります。同種のJMSサーバーごとに、JMSモジュールと単一の関連サブデプロイメントを構成します。
JMSリソースには次のターゲット指定のガイドラインをお薦めします。
デフォルトのターゲット指定、WebLogicサーバーのターゲット指定、宛先を含むクラスタのターゲット指定は避けてください。宛先には高度なターゲット指定(サブデプロイメントのターゲット指定)を使用し、サブデプロイメントがJMSサーバーまたはSAFエージェントのみを参照するようにします。これは、非分散宛先、分散宛先、インポート宛先を含むすべての宛先タイプに適用されます。
ドメインの現在のJMSサーバーまたはSAFエージェントのみが特定のアプリケーションに使用される場合でも、次の理由によりこれがベスト・プラクティスとなります。
現在のアプリケーションに関連しない新しいJMSサーバーまたはSAFエージェントは、他のアプリケーション、Webサービス、またはサード・パーティ製品で導入できます。
今後、アプリケーションでは、スケーラビリティや管理上の目的で異なる宛先や異なるJMSサーバーまたはSAFエージェントが必要になります。
Webサービス・デプロイメントおよびエラー・キューを構成する場合は常に高度なターゲット指定を使用します。これは、開発環境と本番環境のどちらも該当します。
分散キュー内でエラー宛先を使用するには、その親の宛先と同じサブデプロイメントにエラー宛先をターゲット指定する必要があります。
ほとんどの場合、デフォルトのターゲット指定ではリソースがモジュールのターゲットを継承するため、デフォルトのターゲット指定と接続ファクトリを一緒に使用できます。リモート・クライアントでのみ使用される接続ファクトリの場合、モジュールのサブデプロイメント・ターゲットを使用します。
クラスタ化されたJMSサーバーは、すべてのWebLogic JMS機能(順序単位、シングルトン宛先、ストア・アンド・フォワード・エージェントなど)をサポートするわけではありませんが、構成を簡略化し、WebLogicメッセージング・リソースの規模をアプリケーションで容易に変更できるようにするために、その使用を検討してください。「簡略化されたJMSクラスタ構成」を参照してください
次の項では、WebLogic Serverを使用する統合環境とマルチドメイン環境のベスト・プラクティス情報を示します。
リモートWebLogicクラスタまたはサーバーの宛先と通信するサーバー側アプリケーションの場合は、Oracle WebLogic Server JMSアプリケーションの開発のリモートJMSプロバイダの統合を参照してください。
相互運用WebLogic Serverドメインには次の制限事項があります。
ドメイン名は一意にします。
WebLogicサーバー名は、2つの異なるドメインにある場合でも一意にします。
JMSサーバー名は、2つの異なるドメインにある場合でも一意にします。
相互運用ドメインには、セキュリティ上の特殊な注意事項があります。
AQ JMSと相互運用するアプリケーションについては、「Oracle AQ JMSとの相互運用」を参照してください
ドメインを構成してドメイン間トランザクションを有効にするには、Oracle WebLogic Server JTAアプリケーションの開発のドメイン間トランザクションに対する通信の構成を参照してください。
クライアント・アプリケーション(WebLogic Serverに依存しないランタイム環境のアプリケーション)の場合、Java、.NET、Cクライアントなどの複数のJMSクライアント・オプションがあります。Oracle WebLogic Serverスタンドアロン・クライアントの開発のJMSクライアントを参照してください。
注意:
WebLogic JMSクライアントは、外部トランザクション・マネージャを直接サポートしません。可能な場合、WebLogic TMを使用します。上級ユーザーの場合、トランザクション・サブシステムの割込みトランザクション・マネージャ機能をXAリソースとして使用できます。
リモートWebLogic Serverインスタンスまたはクラスタと通信するアプリケーションは、サーバーやクラスタに接続する場合、JNDI InitialContextオブジェクトの作成時またはアプリケーション属性の設定時(あるいはその両方)にURLを指定する必要があります。
JMSリソースと同じサーバーやクラスタで実行するアプリケーションのURLを指定しないでください。最初のコンテキストがURLを指定せずに作成されると、ローカル・サーバーまたはクラスタJNDIが自動的に参照されます。
URLが複数のアドレスに解決する場合、WebLogic Serverクライアントはリスト内のアドレスをランダムに選択して開始し、成功するまで順番に各アドレスを自動で試行します。
本番システムでは、「URL構文」に示す複数のホスト/ポートURL表記を使用せず、最初のホスト名解決にDNSラウンド・ロビンやハードウェア・ロード・バランサを使用することを検討します
WebLogic URL構文は次のようになります。
[t3|t3s|http|https|iiop|iiops]://address[,address]...
説明:
address = hostlist : portlist
hostlist = hostname [,hostname]...
portlist = portrange [+portrange]...
portrange = port [-port]
port-portを使用してポート範囲を示し、+で複数のポート範囲を分割します。たとえば、簡単なアドレスは、通常t3://hostA:7001のようになります。アドレスt3://hostA,hostB:7001-7002は、次のアドレスに相当します。
t3://hostA,hostB:7001+7002
t3://hostA:7001-7002,hostB:7001-7002
t3://hostA:7001+7002,hostB:7001+7002
t3://hostA:7001,hostA:7002,hostB:7001,hostB:7002
厳密に順序付けられたメッセージ処理が必要な場合、アプリケーションの設計と構成で、この要件を慎重に考慮する必要があります。
WebLogic JMS順序単位機能を利用する方法が最も簡単で効率的です。この方法では、通常、アプリケーションの変更は最小限(あるいは変更なし)で済みます。さらに、分散宛先、スケジュール済メッセージ、遅延メッセージ、トランザクション、ストア・アンド・フォワードとともに機能します。『Oracle WebLogic Server JMSアプリケーションの開発』のメッセージ順序単位の使用に関する項を参照してください。
高可用性(HA)またはスケーラビリティが気になる場合、クラスタ化されたWebLogic機能を利用するようにアプリケーションを開発します。非クラスタ・アプリケーションからクラスタ・アプリケーションへの変更は一般的に困難なプロセスであるため、これは初期構成およびアプリケーションの設計段階で行われる最適な手段になります。
WebLogic JMSでは、メッセージは、宛先のホストJMSサーバーが実行している場合のみ利用できます。メッセージが中央の永続ストアにある場合、最初にメッセージを格納したサーバーがメッセージにアクセスできる唯一のJMSサーバーになります。WebLogicには、障害後にJMSサーバーを自動的に再起動または移行(あるいはその両方)する機能があります。また、同じクラスタ内の複数のJMSサーバー間で宛先をクラスタリング(分散)する機能もあります。
通常、HAは次の両方を使用することで実現します。
分散宛先
HAサーバー/サービス。サーバーの全体移行または自動サービス移行のいずれかを使用して、JMSサーバーを自動的に再起動または移行(あるいはその両方)できます。
分散キューは、通常、任意のクラスタ化されたキューイング使用例に対してかなり容易に適用できます。分散トピックは、次のような場合に最も適しています。
サブスクライバが非恒久である場合。
または、MDBを使用してサブスクライブする場合(直接的な非恒久サブスクライバには制限があり、最新の拡張要素を使用する必要があることがあります)。
Oracle WebLogic ServerメッセージドリブンBeanの開発のJMSトピックを使用したMDBの構成とデプロイメントと、Oracle WebLogic Server JMSアプリケーションの開発の分散宛先の使用を参照してください。
JMS外部サーバーの構成で、次の内容を指定します。
oracle.jms.AQjmsInitialContextFactoryをJNDI初期コンテキスト・ファクトリとして指定します。
アプリケーション環境に必要なJDBCデータ・ソースを構成します。
詳細は、次を参照してください。
Oracle WebLogic Server管理コンソール・オンライン・ヘルプの外部サーバーの構成
