7 Oracle AQ JMSとの相互運用
この章の内容は次のとおりです。
『Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイド』のOracle Databaseアドバンスト・キューイングの概要に関する項を参照してください。
ノート:
AQ-JMSの統合は、混在クラスタと動的クラスタではサポートされません。この操作を試行しても、例外はスローされません。
概要
AQ JMSはデータベース接続を使用し、WebLogic Serverクラスタ全体にアクセス可能なデータベースにJMSメッセージを格納します。この接続により、データ操作およびバックアップのためのデータベース機能およびツールを使用できるようになります。必要なクラスは、インストールしたWebLogic Serverにすべて含まれているので、Oracle AQ JMSと相互運用するためにWebLogic Server classpath
にファイルを追加する必要はありません。
WebLogic AQ JMSでは、WebLogic JMS外部サーバー・フレームワークが使用されます。これによって、WebLogic Serverアプリケーションやスタンドアロン・クライアントでの標準WebLogic JNDIコンテキストを使用したAQ JMS接続ファクトリおよび宛先のルックアップや、アプリケーションやクライアントでの標準Java EE API群を使用したAQ JMSのロードおよび呼出しが可能になります。必要なデータベースへの参照、JDBCドライバ、およびデータ・ソースは、このフレームワークの一部として構成されています。
WebLogic ServerのJVM内で実行されるアプリケーションのために、次のような仕組みが提供されています。
-
構成済のWebLogicデータ・ソースで、特定のJDBCドライバを参照し、JDBC接続をプールして、AQ JMSをホストするOracleデータベースへの接続を提供します。
-
構成済のWebLogic外部サーバーで、データ・ソースを参照します。
-
WebLogic JMS外部サーバー構成の一部として、AQ JMSの接続ファクトリおよび宛先用にローカルJNDI名が定義されます。これらのJNDI名は、既存のAQ接続ファクトリや宛先にマップするように構成されます。
-
言い換えると、MDBなどのWebLogic Serverアプリケーションは、このローカルJNDI名を参照することになります。
外部宛先としてのAQ宛先の使用
AQ外部宛先は、アプリケーションを実行するサーバーや、メッセージを送信または受信するMDBに対してローカルである必要があります。
1つのWebLogic Serverインスタンス上で実行中のアプリケーションは、AQ JMS外部サーバーおよび別のWebLogic Serverインスタンス上で登録されるデータ・ソースを参照したり使用したりできません。WebLogic AQ JMSは、リモート接続をサポートしないデータ・ソースまたはDB接続を使用します。あるいは、一方のドメイン上のAQ宛先ともう一方のドメインで実行中のアプリケーションまたはMDB間のメッセージング・ブリッジを使用します。「WebLogicメッセージング・ブリッジ」を参照してください
ドライバ・サポート
トランザクション・サポート
-
非XA JDBCドライバを選択する場合は、ローカル・トランザクションでのみWebLogic AQ JMSを使用できます。
-
XA JDBCドライバを選択する場合は、ローカルとグローバルの両方のトランザクションでWebLogic AQ JMSを使用できます。
-
このリリースでは、ロギング・ラスト・リソース(LLR)、1相コミット(JTS)、エミュレート2相コミットといったグローバル・トランザクション・オプションを伴う非XA JDBCドライバのデータ・ソースはサポートされません。
Supports Global Transactions
が選択されている場合は、警告メッセージがログに記録されます。 -
グローバル・トランザクションは、XA JDBCドライバの1フェーズ・コミット最適化でのみサポートされます。AQ JMSとJDBCの処理の両方に同じXA対応データ・ソースを使用した場合、XAトランザクションの動作は、単一のデータ・ソース(トランザクション・マネージャで単一のリソースとして扱われるもの)の中に2つの接続がある状態と同等になります。そのため、同じJTAトランザクションでAQ JMSとJDBCの処理が呼び出され、そのトランザクションに他のリソースが関わらない場合、トランザクションでは2フェーズ・コミットのかわりに1フェーズ・コミット最適化が使用されるか、読取り専用最適化が使用されます。
Oracle WebLogic Server JMSアプリケーションの開発のトランザクションの理解を参照してください。
Real Application Clusters
ノート:
AQ JMSを使用するロード・バランシング
に複数のデータ・ソースを構成することはお薦めしません。AQ JMSおよびAQを使用するシナリオでは、ロードがOracle RACインスタンス全体に広がるときに過剰な同期が発生する状況が多発します。このような状況では、重要なパフォーマンスの低下が起こる可能性があります。
MBeanおよびコンソールのサポート
AQのキュー表の作成や削除、宛先の作成や削除、および統計問合せといったAQの管理およびモニターを行うには、SQLスクリプトまたはその他のツールを使用してください。
JMS外部サーバーを使用したAQ JMSとの相互運用を目的とするものを除き、AQ JMX固有のMBeanや、WebLogic Server管理コンソールでのAQ JMSの構成のサポートはありません。
AQ JMSとの相互運用のためのWebLogic Serverの構成
AQ JMSキューおよびトピックの準備ができている場合には、WebLogicコンソールまたはWLSTコマンド・ライン・インタフェースを使用して、以降の構成タスクを実行できます。
データベース内でのOracle AQの構成
WebLogic ServerをAQ JMSと統合するよう構成する前に、Oracle DatabaseにAQ JMSキューおよびトピックを設定すると役立つ場合があります。以下の節では、構成方法の1つを説明します。
AQの使用と構成の詳細は、Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイドのOracle Databaseアドバンスト・キューイングの概要を参照してください。
ユーザーの作成および許可の付与
データベース内にユーザーを作成し、そのユーザーにAQ JMSの許可を与えます。管理者権限を持つデータベース・ユーザーで、以下のタスクを実行します。
-
Oracle SQL*Plus環境を使用して、管理者ログインでログインします。
connect / as sysdba;
-
JMSユーザー・スキーマを作成します。以下の例の場合、ユーザー名はjmsuser、パスワードはjmsuserpwd。
Grant connect, resource TO jmsuser IDENTIFIED BY jmsuserpwd
; -
jmsuserにAQユーザーのロールを付与します。
Grant aq_user_role TO jmsuser
; -
AQパッケージに対する実行権限を付与します。
Grant execute ON sys.dbms_aqadm TO jmsuser
;Grant execute ON sys.dbms_aq TO jmsuser
;Grant execute ON sys.dbms_aqin TO jmsuser
;Grant execute ON sys.dbms_aqjms TO jmsuser
;
AQキュー表の作成
AQ JMSの各JMSキューやJMSトピックのデータは、AQキュー表に格納されます。各キュー表が、JMSメッセージのリポジトリの機能を担います。JMSキューまたはJMSトピック(「AQキュー表の作成」を参照)は、基底のAQキュー表への論理的な参照です。
AQキュー表は、個々のJMSユーザー・スキーマ内に作成され、Oracle SQL*PLUSを使用して定義できます。例:
connect jmsuser / jmsuserpwd;
AQキュー表を構成するには、最低でも3つのパラメータが必要です。キュー表の名前、ペイロード・タイプ、そしてAQキュー表で複数のコンシューマを受け入れるかどうかのフラグです。例:
dbms_aqadm.create_queue_table( queue_table=>"myQueueTable", queue_payload_type=>'sys.aq$_jms_text_message', multiple_consumers=>false );
説明:
-
queue_table:キュー表の名前。Oracleデータベースでは、大文字と小文字の混在がサポートされますが、この名前は二重引用符で囲む必要があります。キュー表の名前は24文字を超えないようにします。
-
queue_payload_type: メッセージのタイプ。すべてのJMSメッセージのインタフェース・タイプをサポートするには、
sys.aq$_jms_message
を使用します。 -
multiple_consumers:キューの場合はfalse、トピックの場合はtrueを設定。
キュー表の作成の詳細は、Oracle Database PL/SQLパッケージおよびタイプ・リファレンスのCREATE_QUEUE_TABLEプロシージャを参照してください。
JMSキューまたはトピックの作成
AQ JMSキューは、キューとトピックの両方を対象としたJMS管理リソースです。AQキュー表の作成後に、Oracle SQL*PLUSを使用して個々のJMSユーザー・スキーマ内に、AQ JMSキューを作成できます。例:
connect
jmsuser
/
jmsuserpwd
;
キューまたはトピックを作成するためのPL/SQLプロシージャは、次のような書式になります。
dbms_aqadm.create_queue( queue_name=>'userQueue', queue_table=>'myQueueTable' );
説明:
-
queue_name
はJMSキューのユーザー定義名です。 -
queue_table
は、既存のAQキュー表を指している必要があります。
キュー表の作成の詳細は、Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンスのCREATE_QUEUEプロシージャを参照してください。
JMSキューまたはトピックの開始
初めて使用する際には、事前にAQ JMSキューを開始しておく必要があります。JMSユーザー・スキーマを使用して、以下のPL/SQLプロシージャを実行します。queue_name
はAQ JMSキューの名前です。
connect jmsuser / jmsuserpwd dbms_aqadm.start_queue(queue_name=>'userQueue'
キューの開始の詳細は、Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンスのSTART_QUEUEプロシージャを参照してください。
AQ JMS用のWebLogic Serverの構成
以下の節では、AQ JMSと相互運用するようにWebLogic Serverを構成する方法を説明します。
AQ JMS用のWebLogicデータ・ソースの構成
AQ JMSを使用するWebLogic Serverアプリケーション(MDB、EJB、Webアプリケーションなど)には、AQ JMSサービスを提供するOracleデータベース用のデータ・ソースを構成します。このデータ・ソースは、JMSのユーザーおよびパスワードを使用して、データベース内のスキーマに接続するため、ほとんどの状況ではAQ JMS専用として使用されます。データベース接続で使用されるスキーマに作成した場合は、複数のキューおよびトピックがサポートされます。汎用データ・ソースまたはActive GridLink (AGL)データ・ソースを使用できます。
AQ JMS用の汎用データ・ソースの構成
データ・ソースを構成する場合は、以下の作業を実行します。
-
適切なOracle Thinドライバを選択します。
-
AQ JMSで必要なトランザクションのタイプに基づいて、ドライバのタイプを選択します。
-
ローカル・トランザクションでAQ JMSと併用するためには、非XAベースJDBCドライバを選択します。
-
グローバル・トランザクションまたはローカル・トランザクションでAQ JMSと併用するためには、XAベースJDBCドライバを選択します。
-
-
非XAドライバのデータ・ソースを構成する場合、「
グローバル・トランザクションのサポート
」オプションは選択しません。このリリースでは、非XA JDBCドライバのデータ・ソースと、LLR、JTS、エミュレート2相コミットといったグローバル・トランザクション・オプションとの併用はサポートされていません。グローバル・トランザクション・オプションが選択されていると、サーバー・インスタンスでログに警告メッセージが記録されます。グローバル・トランザクションは、XAベースのJDBCドライバでサポートされています。
-
データ・ソースの接続プールに、データベースのユーザー名とパスワードを構成します。IDベースの接続プールはサポートされていません。
次を参照:
-
Oracle WebLogic Server JDBCデータ・ソースの管理のJDBCデータ・ソースの構成。
-
Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBCデータ・ソースの作成。
AQ JMS用のAGLデータ・ソースの構成
データ・ソースを構成する場合は、以下の作業を実行します。
-
接続用のOracle Thin XAドライバを選択します。
-
データ・ソースの接続プールに、データベースのユーザー名とパスワードを構成します。
次を参照:
-
Oracle WebLogic Server JDBCデータ・ソースの管理のActive GridLinkデータ・ソースの使用
-
Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBC GridLinkデータ・ソースの作成
AQ JMS用の汎用データ・ソースの構成
データ・ソースを構成する場合は、以下の作業を実行します。
-
適切なOracle Thinドライバを選択します。
-
AQ JMSで必要なトランザクションのタイプに基づいて、ドライバのタイプを選択します。
-
ローカル・トランザクションでAQ JMSと併用するためには、非XAベースJDBCドライバを選択します。
-
グローバル・トランザクションまたはローカル・トランザクションでAQ JMSと併用するためには、XAベースJDBCドライバを選択します。
-
-
非XAドライバのデータ・ソースを構成する場合、「
グローバル・トランザクションのサポート
」オプションは選択しません。このリリースでは、非XA JDBCドライバのデータ・ソースと、LLR、JTS、エミュレート2相コミットといったグローバル・トランザクション・オプションとの併用はサポートされていません。グローバル・トランザクション・オプションが選択されていると、サーバー・インスタンスでログに警告メッセージが記録されます。グローバル・トランザクションは、XAベースのJDBCドライバでサポートされています。
-
データ・ソースの接続プールに、データベースのユーザー名とパスワードを構成します。IDベースの接続プールはサポートされていません。
次を参照:
-
Oracle WebLogic Server JDBCデータ・ソースの管理のJDBCデータ・ソースの構成。
-
Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBCデータ・ソースの作成。
AQ JMS用のAGLデータ・ソースの構成
データ・ソースを構成する場合は、以下の作業を実行します。
-
接続用のOracle Thin XAドライバを選択します。
-
データ・ソースの接続プールに、データベースのユーザー名とパスワードを構成します。
次を参照:
-
Oracle WebLogic Server JDBCデータ・ソースの管理のActive GridLinkデータ・ソースの使用
-
Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBC GridLinkデータ・ソースの作成
JMSシステム・モジュールの構成
AQリソース用のJMS外部サーバーをホストするために、専用のJMSシステム・モジュールを構成します。そのモジュールを、WebLogic Serverインスタンス、または外部JNDI名をホストする必要のあるクラスタでターゲット指定します。次を参照:
-
Oracle WebLogic Server管理コンソール・オンライン・ヘルプのシステム・モジュールでの外部サーバーの作成。
JMS外部サーバーの構成
JMS外部サーバーの構成で、次の内容を指定します。
-
oracle.jms.AQjmsInitialContextFactory
をJNDI初期コンテキスト・ファクトリとして指定します。 -
アプリケーション環境に必要なJDBCデータ・ソースを構成します。
次を参照:
-
Oracle WebLogic Server管理コンソール・オンライン・ヘルプの外部サーバーの構成
データ・ソースの参照
datasource
というJNDIプロパティを指定します。これは、ローカルにバインドされたWLSデータ・ソースのJNDIの場所です。
例:
<foreign-server> <initial-context-factory>oracle.jms.AQjmsInitialContextFactory</initial-context-factory> <jndi-property> <key>datasource</key> <value>jdbc/aqjmsds</value> </jndi-property> </foreign-server>
datasource
JNDIプロパティの値は、AQ JMS Oracleデータベースにアクセスするように構成されているデータ・ソースの名前です。セキュリティ・プリンシパルまたは資格証明など、その他の構成情報は必要ありません。ただし、データベースURLを指定する場合は、java.naming.security.principal
とjava.naming.security.credentials
が必要です。
「AQ JMS用のWebLogicデータ・ソースの構成」を参照してください
JMS外部サーバーの接続ファクトリの構成
JMS外部サーバーの作成後は、WebLogic ServerのJNDIツリーにAQ JMS接続ファクトリのJNDIマッピングを作成できます。宛先とは異なり、AQ JMSの場合、Oracleデータベースで接続ファクトリを再定義する必要はありません。かわりに、接続ファクトリのリモートJNDI名の特定時に事前定義済みのJNDI名が指定されます。AQ JMS接続ファクトリのリモートJNDI名は、表7-1のいずれかになります。
表7-1 AQ JMS接続ファクトリのリモートJNDI名
<AQ JMSの接頭辞値> | JMSインタフェース |
---|---|
|
|
|
|
|
|
|
|
|
|
|
|
たとえば、AQ JMS外部サーバー用に構成された以下のような2つの接続ファクトリがあるとします。
表7-2 AQ JMS外部サーバーの接続ファクトリ例
ローカルJNDI名 | リモートJNDI名 |
---|---|
|
|
|
|
WebLogicアプリケーションでjms/aq/myCF
にあるJMSファクトリをルックアップした場合、アプリケーションはそのJMSのjavax.jms.ConnectionFactory
インタフェースを実装するAQ JMSオブジェクトを取得します。WebLogicアプリケーションでaq/orderXaTopicFactory
にあるJMSファクトリをルックアップした場合、アプリケーションはそのJMSのjavax.jms.XATopicConnectionFactory
インタフェースを実装するAQ JMSオブジェクトを取得します。
AQ JMS外部サーバーの接続ファクトリを構成するには、以下の作業を行う必要があります。
-
ローカルおよびリモートのJNDI名を指定します。
-
ローカルJNDI名は、接続ファクトリをWebLogic JNDIツリーにバインドするために使用される名前。ローカルJNDI名は、ローカルのWebLogic Serverで公開されている他のJNDI名と競合しないように、一意のものとする必要があります。
-
リモートJNDI名は、AQ JMS接続ファクトリをルックアップするためにAQ JMSへ渡される名前。
AQ JMSをグローバル・トランザクションで使用するように構成する場合、XAベースの接続ファクトリを使用してください。そうしないと、非XAベースの接続ファクトリが構成されます。
-
-
これ以外の構成パラメータは不要です。
次を参照:
-
Oracle WebLogic Server管理コンソール・オンライン・ヘルプの外部接続ファクトリの作成。
AQ JMS外部サーバーの宛先の構成
AQ JMSの外部宛先を構成する場合、以下の内容を構成する必要があります。
-
ローカルJNDI名: WebLogic JNDIツリーに宛先をバインドするために使用される名前。ローカルJNDI名は、ローカルのWebLogic Serverインスタンスで公開されている他のJNDI名と競合しないように、一意のものとする必要があります。
-
リモートJNDI名: ルックアップを行うためにAQ JMSに渡される名前。AQ JMSには、以下の構文に従ったリモートJNDI名が必要です。
-
宛先がキューの場合、リモートJNDI名は
Queues
/<queue name>
にする必要があります。 -
宛先がキューの場合、リモートJNDI名は
Topics
/<topic name>
にする必要があります
-
接続ファクトリと同様、AQ JMSの宛先にも、JMSオブジェクト・タイプを識別するために接頭辞の付いたリモートJNDI名が必要です。宛先用には以下の2つの値が用意されています。
表7-3 JMSインタフェースのAQ JMSの接頭辞値
AQ JMSの接頭辞値 | JMSインタフェース |
---|---|
|
|
|
|
AQ JMS接続ファクトリのJNDI名とは異なり、宛先名の値はデータベースに定義されているAQ JMS宛先を表しています。JMSキューまたはトピックの作成を参照してください。たとえば、AQ JMS外部サーバーに次の表に示すような2つの宛先が構成されているとします。
表7-4 AQ JMS外部サーバーの宛先例
ローカルJNDI名 | リモートJNDI名 |
---|---|
|
|
|
|
jms/myQueue
という場所をルックアップするWebLogicアプリケーションは、userQueue
で定義されているAQ JMSキューを参照します。AqTopic
という場所をルックアップすると、myTopic
で定義されているAQ JMSトピックが参照されます。
次を参照:
-
Oracle WebLogic Server管理コンソール・オンライン・ヘルプの外部宛先の作成。
Oracle 12cデータベースとの相互運用のための追加構成
次の項では、Oracle 12cデータベース上でAQ JMSを相互運用する場合に必要な追加構成について説明します。
-
Oracle 12cデータベースのシャード・キューでのAQ非同期通知機能は、デフォルトで有効です。
AQシャード・キューを使用する場合、メッセージ・リスナーまたはメッセージドリブンBean (MDB)からの非同期受信により、負荷に基づいて追加のJDBC接続が内部的に作成されます。JDBC接続の数がシステムで制限されている場合、クライアント・アプリケーションではシステム・プロパティの値
oracle.jms.useJmsNotification
をfalse
に設定して、非同期通知を無効にする必要があります。転送可能MDBの場合、または
-Dweblogic.mdb.message.MinimizeAQSessions
がtrueに設定されている場合、MDB接続は内部的に同期受信を使用し、非同期コンシューマは使用しません。 -
通知サービス(
-Doracle.jms.useJmsNotification=true
)を使用するには、JDBC URLのSIDのかわりにデータベース・サービス名を設定します。例:jdbc:oracle:thin:@//
DB_HOST:
DB_PORT/
Database ServiceName -
init.ora
ファイルにinit
パラメータを設定することでローカル・リスナーを指定し、データベースを再起動します。例:LOCAL_LISTENER="(ADDRESS=(PROTOCOL=tcp)(host=
DB_HOST)(port=
DB_PORT)) -
WebLogic Serverプロパティを設定して、使用されるJMSセッションの数を最小限に抑え、MDBポーリング間隔を制御します。AQ JMSとの相互運用のためのメッセージ・ドリブンBeanの設定を参照してください
ノート:
WebLogic Server 12.2.1.2では、WebLogic Server Javaシステムのプロパティweblogic.mdb.message.MimizeAQSessions
およびweblogic.ejb.container.MDBDestinationPollIntervalMillis
は廃止されています。かわりに、対応するactivation-config-propertyを使用してください。2つのactivation-config-propertyは、それぞれのJavaシステム・プロパティをオーバーライドします。
プログラミングの考慮事項
次の項では、高度なWebLogic AQ JMSのトピックに関する情報を紹介します。
AQ JMSとの相互運用のためのメッセージドリブンBeanの設定
メッセージドリブンBean (MDB)は、AQ JMSとの相互運用に、構成済の外部サーバーを使用します。「概要」を参照してください。
次に、AQ JMSと相互運用する場合のMDBの考慮事項を示します。
-
次のWebLogic Serverプロパティを設定して、使用されるJMSセッションの数を最小限に抑え、MDBポーリング間隔を制御します。
-
—Dweblogic.mdb.message.MinimizeAQSessions=true
このプロパティを使用すると、MDBレイヤー内のAQ JMSセッションの数が減少するため、MDBにより保持されるJDBC接続の数が減少します。また、このプロパティの値trueは、
weblogic.ejb.container.MDBDestinationPollIntervalMillis
が5000ミリ秒より大きい数に設定された場合にのみ有効です。-Dweblogic.ejb.container.MDBDestinationPollIntervalMillis=6000
-
メッセージドリブン・パラメータ
initial-context-factory
およびprovider-url
は、JMS外部サーバーの構成の一部として提供されるため、サポートされません -
ejb-jar.xml
ファイルで、MDBの宛先の宛先タイプをjavax.jms.Queue
またはjavax.jms.Topic
に構成する必要があります -
コンテナ管理トランザクション、恒久トピック・サブスクリプションなどのMDB機能を有効にするには、他にもMDBの構成が必要です。
『Oracle WebLogic ServerメッセージドリブンBeanの開発』のメッセージドリブンBeanの理解に関する項を参照してください。
AQトピックをリスニングするクラスタ化されたWebLogic MDBのスケーラビリティ
クラスタ化されたMDBでAQトピックをリスニングする場合は、One-Copy-Per-Applicationのメッセージング戦略を実装するために、共有サブスクリプションを使用します。
サブスクリプションを共有するサブスクライバは、次の要件を満たしている必要があります。
-
異なるVM上に存在する。
-
同じデータ・ソース(または同じデータベース・ユーザー名とパスワードを使用するデータ・ソース)を使用します。
-
同じサブスクリプション名を使用します。
データベース・ユーザー名は、サブスクリプションのクライアントIDとして機能します。同じ名前のサブスクリプションに対するクライアントIDが同じ場合、そのサブスクリプションはAQで共有されます。共有サブスクリプションの詳細は、Oracle WebLogic Server JMSアプリケーションの開発の高可用性のための高度なメッセージング機能を参照してください。
AQ JMS拡張
AQ JMS拡張APIがAQ JMSの特定のクラスでサポートされています。AQ JMS拡張は、標準のJMSオブジェクト(接続ファクトリや宛先など)を独自仕様のAQ JMSクラスにキャストすると、呼び出せるようになります。例:
. . .
import oracle.jms.AQjmsFactory;
. . .
ConnectionFactory myCF = (ConnectionFactory) jndiCtx.lookup("aqjms/testCF");
AQjmsFactory myCF = (AQjmsFactory) myCF;
myCF.someProprietaryAQJMSmethod(..);
. . .
AQ JMS接続ファクトリのリソース参照を使用する場合、WebLogic Serverでは基底のAQ JMS接続ファクトリがラッパー・オブジェクトでラップされます。このラッパー・オブジェクトはJMSの標準APIを実装していますが、AQ JMS拡張APIを提供するAQ JMSクラスにはキャストできません。例:
. . .
// Implements wrapping and cannot cast to AQ JMS
<resource-ref>
<res-ref-name>aqjms/testCF</res-ref-name>
<res-type>javax.jms. ConnectionFactory</res-type>
<res-auth>Application</res-auth>
</resource-ref>
. . .
ラップ処理を回避するには、リソース参照のリソース・タイプとして、デプロイメント記述子のjavax.jms.XXXConnectionFactory
のかわりにjava.lang.Object
を指定します。この制限事項はAQ JMSに固有のものです。リソース参照はJavaインタフェースを使用して公開される拡張のみをサポートするためです。例:
. . .
// Use for AQ JMS extensions
<resource-ref>
<res-ref-name>aqjms/testCF</res-ref-name>
<res-type>java.lang.Object</res-type>
<res-auth>Application</res-auth>
</resource-ref>
. . .
AQ JMSでは、その拡張用のJavaインタフェースは定義されません。AQ JMSでは、ラップ処理を回避しても、自動JTAトランザクションの登録は無効にならず、プーリングも妨げられません。AQ JMSは、WebLogicデータ・ソースの組込みの使用を通して、これらの機能を暗黙的に取得するためです。
AdtMessageの使用
AdtMessage
は抽象データ型(ADT)をサポートする、特殊なタイプのAQ JMS拡張機能です。ADTは、データ構造と、Oracleデータベースでデータを操作するサブプログラムで構成されます。
ノート:
これは、メッセージ・ドリブンBean (MDB)ではサポートされません。
次を参照:
-
Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイドのOracle Java Message Service (OJMS)を使用したOracle Streamsアドバンスト・キューイングへのアクセスとオブジェクト・タイプのサポート
- Oracle Database PL/SQL言語リファレンスのデータ抽象化
リソース参照
リソース参照を使用し、リソース・タイプがjavax.jms.XXXConnectionFactory
の場合は、ユーザー・アプリケーションに渡されるAQ JMSオブジェクトがラップされます。AQ JMS拡張APIも使用する場合は、これらのAPIをラップしないようにする必要があります(「AQ JMS拡張」を参照)。
WebLogicリソース参照ラッパーでは、AQ JMS接続は自動的にはプールされません。かわりに、AQ JMSのサーバー側統合はデータ・ソースの接続プーリング機能に依存し、それによってJMS接続およびセッションのオープンとクローズに関わるオーバーヘッドが軽減されます。WebLogicリソース参照でプーリング機能が無効になるのは、AQ JMSプロバイダのJMS接続ファクトリが常にクライアントの識別子で事前に構成されているためです。逆に、このようになっているのでWebLogicリソース参照でプーリング機能が無効になると言うこともできます。
JDBC接続の利用
AQ JMSセッションでは、JMSセッションが閉じるまでJDBC接続が維持されます。これは、その接続でデータ・ソースやJDBC URLが使用されるかどうかとは関係なく行われます。セッションが長時間にわたってアイドル状態になった場合、AQ JMSセッションを閉じることをお薦めします。JMSセッションを閉じると、JDBC接続が開放されてWebLogicデータ・ソースのプールに戻るか、データベースおよびJDBC URLのネットワーク・リソースが開放されます。
Oracle RACサポート
次の項では、Oracle RAC環境での制限事項について説明します。
-
Oracle RAC環境でAQ JMS RACのフェイルオーバーを実現するには、WebLogicマルチ・データ・ソースの構成が必要です。Oracle WebLogic Server JDBCデータ・ソースの管理のOracle RACでのWebLogic Serverの使用を参照してください。
-
Oracle RACのフェイルオーバーは、このリリースではWebLogic AQ JMSスタンドアロン・クライアントの使用時にはサポートされません。
デバッグ
AQ JMSのトレースやデバッグの機能を使用するには、システム・プロパティoracle.jms.traceLevel
を設定する必要があります。
このプロパティの値は1 - 6までの整数で、6に設定した場合に詳細度が最大になります。トレースの結果は実行中のJVMの標準出力に出力されます。
パフォーマンスの考慮事項
Oracle RDBMS 11.2.0.2以前のリリースでは、キュー表についての統計がデフォルトでロックされているため、各デキュー処理ごとに全表スキャンが行われます。この問題を解決するには、キュー表のロックを解除して統計を収集します。例:
exec DBMS_STATS.UNLOCK_TABLE_STATS ('<schema>','<queue table>');
exec DBMS_STATS.gather_table_stats('<schema>','<queue table>');
exec DBMS_STATS.LOCK_TABLE_STATS ('<schema>','<queue table>');
高度なトピック
WebLogic ServerアプリケーションとAQ JMSを相互運用する場合の高度な相互運用情報について学習します。
この項には次のトピックが含まれます:
セキュリティの考慮事項
スタンドアロンのクライアントとサーバー側のアプリケーションでは、セキュリティのセマンティクスや構成が異なります。セキュリティについて知りたい場合は、この項をよくお読みください。また、WebLogicのロックダウンに関するドキュメントでも、WebLogic Serverやクラスタを保護する方法について説明しています(『Oracle WebLogic Server本番環境の保護』を参照)。次の項では、このリリースでのセキュリティに関する考慮事項について説明します。
AQ宛先のセキュリティの構成
AQでは、宛先でのルックアップや、エンキューおよびデキューのため、データベース・ユーザーにENQUEUEまたはDEQUEUEあるいはその両方の許可を構成する必要があります。
以下のユーザー名に対し、ENQUEUEまたはDEQUEUEあるいはその両方の許可を必ず指定します。
-
スタンドアロン・クライアントの場合:
-
構成済みのJMS外部サーバーのユーザー名(
java.naming.security.principal
プロパティを使用して指定されたとおり)。 -
JMS ConnectionFactory APIのI
createConnection()
メソッドを使用してusername
を渡すJavaコードの場合、このusername
に許可が必要です。
-
-
サーバー側アプリケーションの場合:
-
WebLogicデータ・ソースに
データベース・ユーザー名
が構成されています。 -
JMS ConnectionFactory APIの
createConnection()
メソッドでusername
を渡すJDBCデータ・ソース・クライアントに指定されているusername
には、許可を付与しません。このusername
はWebLogicのusername
であり、データベースのusername
ではありません。
-
AQのルックアップ、エンキュー、およびデキューに使用されるJDBC接続の資格証明や許可については、Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイドのキューのセキュリティとアクセス制御を参照してください。
ノート:
宛先のルックアップ時に許可が失敗すると、アプリケーションの呼出し側に(セキュリティ例外ではなく)「name not found」という例外として明示されます。
JNDIで公開された宛先および接続ファクトリへのアクセス
これまでに説明したように、JMS外部サーバーの構成タスクの一部として、接続ファクトリや宛先のローカルJNDI名を構成する必要があります。こうしたJNDI名には必要に応じてセキュリティ・ポリシーを構成することもできます。そのようにすると、JNDIルックアップ時に現在のWebLogic資格証明に基づいてアクセス・チェックが行われます。現在のWebLogic資格証明はクライアントのタイプによって決まります。
アプリケーションのWebLogic JNDIルックアップのセキュリティ・ポリシーの資格証明のチェックで宛先として合格すると、Oracle AQのその宛先リソースが、JMS外部サーバーの宛先で自動的にJDBC接続を使用してルックアップされます。
スタンドアロンのクライアントの場合、この宛先ルックアップの2番目のプロセスで使用される資格証明は、JMS外部サーバーに構成されているusername
およびpassword
に基づくものです。
サーバー側アプリケーションのJDBCデータ・ソース・クライアントの場合、この2番目の宛先ルックアップで使用される資格証明は、そのデータ・ソースの一部として構成されているデータベースのusername
およびpassword
に基づきます。このデータ・ソースへのアクセス権を得るために使用される資格証明は、現在のWebLogic資格証明であることに注意してください。このデータ・ソースにWebLogicセキュリティ・ポリシーを構成することも可能です。WebLogicデータ・ソースのIDベースの接続プーリング機能は、この目的のためにはサポートされていません。
前述したように、データベースの資格証明には、宛先の正常なルックアップのために、宛先に対するAQ JMSのエンキューまたはデキュー・パーミッションが必要です。「AQ宛先のセキュリティの構成」を参照してください
JMS APIでルックアップされる宛先へのアクセスの制御
JMSのQueueSession
およびTopicSession
APIには、宛先のルックアップのために、それぞれcreateQueue()
、createTopic()
というJNDIにかわるものが用意されています。Oracle WebLogic Server JMSアプリケーションの開発の宛先のルックアップ方法を参照してください。
createQueue()
およびcreateTopic()
の呼出しでは、JMS接続に関連付けられているデータベース資格証明が使用されます。以降の節では、この資格証明を設定する方法について説明します。
スタンドアロン・クライアント向けのその他のセキュリティ構成
以下の節では、スタンドアロン・クライアント向けのセキュリティ構成について説明します。
-
JNDIの初期コンテキストの確立時や後続のJNDIルックアップの実行時には、クライアントからWebLogicへのネットワーク通信が発生します。確実にセキュアな通信を行い、プレーン・テキストが渡されないようにするには、SSL対応のプロトコル(t3sやhttpsなど)を使用します。データベース・ログイン用に構成されるJMS外部サーバーの資格証明はもちろん、WebLogicログインに使用される資格証明も、SSLが構成されていない場合にはプレーン・テキストで渡されます。
-
ネットワーク通信は、AQとの通信時にクライアントからデータベースに対して行われます。この通信はJDBC URLの構成で制御され、JDBC URLがSSLを使用するように構成されていない限り、プレーン・テキストで渡されます。スタンドアロンのクライアントは、AQ JMS APIを使用してデータベース接続でデータベースと直接的に通信し、そのJMSリクエストはWebLogicサーバーを通りません。
-
WebLogic Serverのユーザー名およびパスワード: クライアントからWebLogicへのネットワーク・ログインは、JNDIの初期コンテキスト確立の一部として実行されます。このコンテキストの作成時にオプションとして指定されるユーザー名およびパスワードのプロパティが、WebLogicのIDとなります(プロパティ名はそれぞれ
Context.SECURITY_PRINCIPAL = "java.naming.security.principal"
、Context.SECURITY_CREDENTIALS = "java.naming.security.credentials"
)。これが、後続のJNDIルックアップでチェックされる資格証明となります。この資格証明は現在のスレッドとも暗黙的に関連付けられるため、同じスレッドでの後続のWebLogic処理にも使用される資格証明になります。ただし、これはAQ JMS処理に使用される資格証明ではありません。 -
javax.jms.ConnectionFactory createConnection()
メソッドには、オプションのユーザー名とパスワードがあります。スタンドアロン・クライアントの場合、これらが、JMS外部サーバー構成の一部として構成されているコンテキストの資格証明をオーバーライドします。AQ JMSでは、この指定されたユーザーIDでデータベース接続が作成されます。ユーザー名とパスワードを指定せずにcreateConnection()
が呼び出された場合は、JMS外部サーバー構成の一部として構成されているユーザー名とパスワードを使用して、データベース接続が作成されます。 -
ユーザー名やパスワードを直接、JDBC URLに含めてはなりません。かわりにJMS外部サーバーのユーザー名およびパスワードを使用します。
-
JMS外部サーバーの接続ファクトリに、ユーザー名やパスワードを構成しないでください。このようにした場合の動作はサポートされません。
サーバー側アプリケーション向けのその他のセキュリティ構成
以下の節では、サーバー側アプリケーション向けのセキュリティ構成について説明します。
-
スタンドアロン・クライアントのサポートにも使用されているJMS外部サーバーでないかぎり、そのJMS外部サーバーに
java.naming.security.principal
や資格証明を構成しないでください。 -
JMS外部サーバーの接続ファクトリに、ユーザー名やパスワードを構成しないでください。このようにした場合の動作はサポートされません。
-
サーバーからデータベースへのネットワーク通信(サーバー側アプリケーション)は、データ・ソースの構成で制御され、そのデータ・ソースがSSLを使用するように構成されていない限り、プレーン・テキストで行われます。
-
javax.jms.ConnectionFactory createConnection()
メソッドには、オプションのユーザー名とパスワードがあります。サーバー側のJMS AQアプリケーションの場合、このメソッドはユーザー名をWebLogicユーザーのものと見なして、WebLogic serverに対する認証を行います。この動作は他の種類のJMS AQクライアントの動作とは異なります。他の種類のJMS AQクライアントでは、ユーザー名がデータベース・ユーザーとして扱われます。WebLogicデータ・ソースとともに構成されている場合、AQ JMSではそのWebLogicデータ・ソースに認証が委託され、AQ JMSでWebLogicユーザーのセマンティクスが継承されます。 -
AQ JMS外部サーバーがWebLogicデータ・ソースとともに構成されている場合、そのデータ・ソースは汎用JDBC利用のために公開されます。データ・ソースは、Oracle WebLogic Server JDBCデータ・ソースの管理のJDBCデータ・ソースを保護するためのロールおよびポリシーの使用の説明に従って保護することをお薦めします。
-
WebLogic Serverのユーザー名およびパスワードについて。WebLogicの資格証明は、JNDI内の保護されている名前にアクセスするときや、保護されているデータ・ソースにアクセスするときにチェックされます。サーバー側アプリケーションでは、その同じWebLogic資格証明を自動的にアプリケーションの呼出し側と見なします。あるいはMDBの場合には、この資格証明をMDB構成の一部として構成することも可能です。
-
WebLogicデータ・ソースのIDベースの接続プーリング機能はサポートされていません。
-
JNDIコンテキストの資格証明: 通常、サーバー側アプリケーション内でJNDIコンテキストの設定の一部として資格証明を指定する必要はありません。また、一般的に推奨されません。このようにすると新しい資格証明が作成され、アプリケーションの現在の資格証明がオーバーライドされます。つまり、コンテキストの作成時にオプションで指定されたユーザー名とパスワードのプロパティがWebLogicのIDになり、現在のIDと置き換えられます(プロパティ名は
Context.SECURITY_PRINCIPAL = "java.naming.security.principal"
とContext.SECURITY_CREDENTIALS = "java.naming.security.credentials"
)。このオプションの新しい資格証明は、暗黙的に現在のスレッドと関連付けられます。そのため、同じスレッドの後続のWebLogic処理(JNDIルックアップなど)でも、その資格証明が使用されます。この新しい資格証明は、AQ JMS処理に使用される資格証明ではありません。
WebLogicメッセージング・ブリッジ
WebLogicメッセージング・ブリッジは、構成済のソース・ブリッジ宛先およびターゲット・ブリッジ宛先と通信します。ソース宛先とターゲット宛先とのマッピングごとに、メッセージング・ブリッジのインスタンスを構成する必要があります。各メッセージング・ブリッジ・インスタンスは、マッピングするソース宛先とターゲット宛先、メッセージ・フィルタリング・セレクタ、サービスの品質(QOS)、トランザクション・セマンティクスおよび各種再接続パラメータを定義します。
AQ外部宛先が、メッセージを送受信するアプリケーションやMDBを実行するサーバーに対してローカルではない場合、AQ外部宛先に対してローカルなサーバーでメッセージング・ブリッジ・インスタンスを構成する必要があります。ローカル・データベース接続は、AQ宛先からのメッセージの送受信プロセスで使用されます。
WebLogicメッセージング・ブリッジの詳細は、Oracle WebLogic Server WebLogicメッセージング・ブリッジの管理のメッセージング・ブリッジの理解を参照してください。
メッセージング・ブリッジ・インスタンスを作成する
次に、あるドメインで外部宛先として構成されたAQ宛先と、別のドメインで実行するアプリケーションまたはMDBとの間にメッセージング・ブリッジを作成する主なステップについて説明します。
WebLogic Server管理コンソールは、適切なリソース・アダプタをデプロイし、一部の属性値を設定して、メッセージング・ブリッジを作成するために役立ちます。使用する環境に合うように、メッセージング・ブリッジの設定変更が必要な場合もあります。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのメッセージング・ブリッジ・インスタンスの作成を参照してください。
スタンドアロンのWebLogic AQ JMSクライアント
WebLogic AQ JMSスタンドアロン・クライアントを作成できます。これは、JDBC URLを使用してJMS外部サーバーが定義した、AQ JMS接続ファクトリと宛先をルックアップできます。クライアント側のクラスパスのjarとして$MW_HOME/oracle_common/modules/oracle.jdbc_12.1.0/aqapi.jar
と$MW_HOME/oracle_common/modules/features/com.oracle.db.jdbc7-no-dms.jar
が必要であり、wlthint3client.jar
、wlclient.jar
、wlfullclient.jar
のいずれかのWebLogicクライアントjarも必要です。
ノート:
クライアント側のクラスパスではWebLogic Server 12cのjarファイルのみを使用してください。11gのjarファイルの使用や12cと11gのjarファイルを組み合せた使用はサポートされていません。
WebLogic ServerのJVMの外部で実行されるアプリケーションについては、以下のような処理が行われます。
-
構成済のWebLogic JMS外部サーバーで、データベースのURLや、その他のJDBCドライバの構成が参照されます。「データベースのJDBC URLを使用した外部サーバーの構成」を参照してください
-
WebLogic JMS外部サーバー構成の一部として、AQ JMSの接続ファクトリおよび宛先用にローカルJNDI名が定義されます。これらのJNDI名は、既存のAQ接続ファクトリや宛先にマップするように構成されます。
-
スタンドアロンのクライアントではローカルJNDI名を参照します。WebLogic Serverで実行されるアプリケーションとは異なり、スタンドアロンのクライアントではドライバおよびAQクライアントが確実にclasspathに存在する必要があります。
データベースのJDBC URLを使用した外部サーバーの構成
jndi-properties-credentials
に、db_url
およびjava.naming.security.principal
JNDIプロパティと、パスワードを指定します。
例:
<foreign-server> <initial-context-factory>oracle.jms.AQjmsInitialContextFactory</initial-context-factory> <jndi-properties-credential-encrypted>{3DES}g8yFFu1AhP8=</jndi-properties-credential-encrypted> <jndi-property> <key>java.naming.security.principal</key> <value>j2ee</value> </jndi-property> <jndi-property> <key>db_url</key> <value>jdbc:oracle:thin:@{hostname}:{port}:{sid}</value> </jndi-property> </foreign-server>
-
db_url
JNDIプロパティの値は、AQ JMS Oracleデータベースへの接続に使用されるJDBC URLです。 -
java.naming.security.principal
の値は、AQ JMSがデータベースへの接続に使用するデータベース・ユーザー名です。 -
jndi-properties-credentials
はデータベースのパスワードを格納。
これ以外の構成プロパティは不要です。