Oracle® Fusion Middleware Oracle WebLogic Server JMS のコンフィグレーションと管理 11g リリース 1 (10.3.1) B55547-01 |
|
![]() 戻る |
![]() 次へ |
以下の節では、Oracle AQ JMS との相互運用の方法について説明します。
『Oracle Streams Advanced Queuing User's Guide』を参照してください。
Oracle WebLogic Server アプリケーションでは、WebLogic Server リソース (Web アプリケーション、EJB、MDB) またはスタンドアロン クライアントを使用し、JMS API を介して Oracle Streams Advanced Queuing (AQ) と相互運用できます。AQ JMS では、WebLogic Server クラスタ全体にアクセス可能なデータベースに格納された JMS メッセージと、データベース接続を使用して、データベース機能やデータ操作およびバックアップのツールを利用できるようにします。必要なクラスは、インストールした WebLogic Server にすべて含まれているので、WebLogic Server の classpath
にファイルを追加する必要はありません。
WebLogic AQ JMS では、WebLogic JMS 外部サーバ フレームワークが使用されます。これによって、WebLogic Server アプリケーションやスタンドアロン クライアントでの標準 WebLogic JNDI コンテキストを使用した AQ JMS 接続ファクトリおよび送り先のルックアップや、アプリケーションやクライアントでの標準 JEE 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 名を参照することになる。
WebLogic AQ JMS は、Oracle データベースとの通信に JDBC ドライバを必要とします。このリリースでは、インストールした WebLogic Server に含まれている Oracle JDBC 11g シン ドライバのみがサポートされます。Oracle OCI JDBC ドライバや、非 Oracle JDBC ドライバはサポートされません。
グローバル XA (JTA) トランザクションと、ローカル JMS でトランザクション処理されるセッション トランザクションがサポートされます。グローバル トランザクションでは XA ベースの接続ファクトリを使用する必要があり、一方のローカル トランザクションでは、XA ベースでない JMS 接続ファクトリが使用されます。
非 XA JDBC ドライバを選択する場合、ローカル トランザクションでのみ WebLogic AQ JMS を使用できる。
XA JDBC ドライバを選択する場合、ローカルとグローバルの両方のトランザクションで WebLogic AQ JMS を使用できる。
このリリースでは、ロギング ラスト リソース (LLR)、1 相コミット (JTS)、エミュレート 2 相コミットといったグローバル トランザクション オプションを伴う非 XA JDBC ドライバのデータ ソースはサポートされない。[グローバル トランザクションのサポート
] が選択されている場合、警告メッセージがログに記録されます。グローバル トランザクションは、XA JDBC ドライバの 1 相コミットが最適化されている場合にのみサポートされます。AQ JMS と JDBC の処理の両方に同じ XA 対応データ ソースを使用した場合、XA トランザクションの動作は、単一のデータ ソース (トランザクション マネージャで単一のリソースとして扱われるもの) の中に 2 つの接続がある状態と同等になります。そのため、同じ JTA トランザクションで AQ JMS と JDBC の処理が呼び出され、そのトランザクションに他のリソースが関わらない場合、トランザクションでは 2 相コミットではなく 1 相コミットの最適化が使用されるか、読み取り専用の最適化が使用されます。
『Oracle Fusion Middleware Oracle WebLogic Server JMS プログラマーズ ガイド』の「トランザクションについて」を参照してください。
WebLogic AQ JMS では、Oracle Real Application Clusters (RAC) と WebLogic マルチ データ ソースの併用がサポートされ、RAC 環境でのフェイルオーバが提供されます。『Oracle Fusion Middleware Oracle WebLogic Server JDBC のコンフィグレーションと管理』の「WebLogic Server での Oracle RAC の使い方」を参照してください。
JMS 外部サーバを使用した AQ JMS との相互運用を目的とするものを除き、AQ JMX 固有の MBean や、Administration Console での AQ JMS のコンフィグレーションのサポートはありません。AQ のキュー テーブルの作成や削除、送り先の作成や削除、および統計クエリといった AQ の管理およびモニタを行うには、SQL スクリプトまたはその他のツールを使用してください。
Oracle OC4J から Oracle WebLogic Server に AQ JMS アプリケーションを移行する方法については、『Oracle Fusion Middleware Upgrade Guide for Java EE』の「Upgrading OEMS JMS Database Persistence」を参照してください。
以下の節では、Oracle データベースに AQ JMS キューおよびトピックをコンフィグレーションし、WebLogic Server に JMS 外部サーバをコンフィグレーションして、アプリケーションから AQ JMS 接続ファクトリや送り先を WebLogic JNDI コンテキストでルックアップできるようにする方法の一例を紹介します。
AQ JMS キューおよびトピックの準備ができている場合には、WebLogic Console または WLST コマンドライン インタフェースを使用して、以降のコンフィグレーション タスクを実行できます。
WebLogic Server リソースのコンフィグレーションを開始する前に、Oracle データベース内に AQ JMS キューおよびトピックが確実にあるようにする必要があります。以下の節では、コンフィグレーション方法の 1 つを説明します。
AQ の使用とコンフィグレーションの詳細については、『Oracle Streams Advanced Queuing User's Guide』を参照してください。
データベース内にユーザを作成し、そのユーザに 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 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_consomers=>false );
各値の説明は次のとおりです。
queue_table: キュー テーブルの名前。データベースが 10.0 の場合、大文字と小文字の混在がサポートされます。ただし、この名前は 二重引用符で囲む必要があります。キュー テーブルの名前は 24 文字を超えないようにします。
queue_payload_type: メッセージのタイプ。すべての JMS メッセージのインタフェース タイプをサポートするには、sys.aq$_jms-message
を使用します。
multiple_consumers: キューの場合は false、トピックの場合は true を設定。
キュー テーブルの作成の詳細については、『Oracle Database PL/SQL Packages and Types Reference』の「CREATE_QUEUE_TABLE Procedure」を参照してください。
AQ JMS キューは、キューとトピックの両方を対象とした JMS 管理リソースです。AQ JMS キューは、AQ キュー テーブルの作成後に、Oracle SQL*PLUS を使用して個々の 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 Packages and Types Reference』の「CREATE_QUEUE Procedure」を参照してください。
初めて使用する前には、AQ JMS キューを開始する必要があります。JMS ユーザ スキーマを使用して、以下の PL/SQL プロシージャを実行します。queue_name
は AQ JMS キューの名前です。
connect jmsuser / jmsuserpwd dbms_aqadm.start_queue(queue_name=>'userQueue'
キューの開始の詳細については、『Oracle Database PL/SQL Packages and Types Reference』の「START_QUEUE Procedure」を参照してください。
以下の節では、AQ JMS と相互運用するように WebLogic Server をコンフィグレーションする方法を説明します。
AQ JMS を使用する WebLogic Server アプリケーション (MDB、EJB、Web アプリケーションなど) には、AQ JMS サービスを提供する Oracle データベース用のデータ ソースをコンフィグレーションします。このデータ ソースは、JMS のユーザおよびパスワードを使用して、データベース内のスキーマに接続するため、ほとんどの状況では AQ JMS 専用として使用されます。データベース接続で使用されるスキーマに作成した場合は、複数のキューおよびトピックがサポートされます。データ ソースをコンフィグレーションする場合は、以下の作業を実行します。
Oracle Thin Driver を選択する。
AQ JMS で必要なトランザクションのタイプに基づいて、ドライバのタイプを選択する。
ローカル トランザクションで AQ JMS と併用するためには、非 XA ベース JDBC ドライバを選択する。
グローバル トランザクションまたはローカル トランザクションで AQ JMS と併用するためには、XA ベース JDBC ドライバを選択する。
非 XA ドライバのデータ ソースをコンフィグレーションする場合、[グローバル トランザクションのサポート
] オプションは選択しない。このリリースでは、非 XA JDBC ドライバのデータ ソースと、LLR、JTS、エミュレート 2 相コミットといったグローバル トランザクション オプションとの併用はサポートされていません。グローバル トランザクション オプションが選択されていると、サーバ インスタンスでログに警告メッセージが記録されます。グローバル トランザクションは、XA ベースの JDBC ドライバでサポートされています。
データ ソースの接続プールに、データベースのユーザ名とパスワードをコンフィグレーションする。ID ベースの接続プールはサポートされていません。
以下を参照してください。
『Oracle Fusion Middleware Oracle WebLogic Server JDBC のコンフィグレーションと管理』の「JDBC データ ソースのコンフィグレーション」。
Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「JDBC データ ソースの作成」。
Oracle RAC 環境では、shrink-frequency-seconds
に小さな値を設定することをお勧めします。
例 : shrink-frequency-seconds=10
このようにすると、接続が失敗したときに、その接続をデータ ソースで削除できます。以下を参照してください。
Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「JDBC データ ソース : コンフィグレーション : 接続プール」。
『Oracle Fusion Middleware Oracle WebLogic Server JDBC のコンフィグレーションと管理』の「WebLogic Server での Oracle RAC の使い方」を参照してください。
AQ リソース用の JMS 外部サーバをホストするために、専用の JMS システム モジュールをコンフィグレーションします。そのモジュールを、WebLogic Server インスタンス、または外部 JNDI 名をホストする必要のあるクラスタで対象指定します。以下を参照してください。
『Oracle Fusion Middleware Oracle WebLogic Server JMS のコンフィグレーションと管理』の「JMS モジュールの概要」。
Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「Create foreign servers in a system module」。
JMS 外部サーバのコンフィグレーションで、以下の内容を指定します。
oracle.jms.AQjmsInitialContextFactory
を JNDI 初期コンテキスト ファクトリとして指定する。
アプリケーション環境に必要な JDBC データ ソースをコンフィグレーションする。
以下を参照してください。
Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「外部サーバのコンフィグレーション」。
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 データベースにアクセスするようにコンフィグレーションされているデータ ソースの名前です。これ以外のコンフィグレーション情報は不要です。
「WebLogic データ ソースのコンフィグレーション」を参照してください。
JMS 外部サーバを作成したら、WebLogic Server の JNDI ツリーに AQ JMS 接続ファクトリの JNDI マッピングを作成できます。送り先とは異なり、AQ JMS の場合、Oracle データベースで接続ファクトリを再定義する必要はありません。代わりに、接続ファクトリのリモート JNDI 名の特定時に事前定義済みの JNDI 名が指定されます。AQ JMS 接続ファクトリのリモート JNDI 名は、以下のいずれかになります。
表 8-1 AQ JMS 接続ファクトリのリモート JNDI 名
<AQ JMS のプレフィックス値 > | JMS インタフェース |
---|---|
|
javax.jms.QueueConnectionFactory |
|
javax.jms.TopicConnectionFactory |
|
javax.jms.ConnectionFactory |
|
javax.jms.XAQueueConnectionFactory |
|
javax.jms.XATopicConnectionFactory |
|
javax.jms.XQConnectionFactory |
たとえば、AQ JMS 外部サーバ用にコンフィグレーションされた以下のような 2 つの接続ファクトリがあるとします。
表 8-2 AQ JMS 外部サーバの接続ファクトリ例
ローカル JNDI 名 | リモート JNDI 名 |
---|---|
jms/aq/myCF |
ConnectionFactory |
aqjms/orderXaTopicFactory |
XATopicConnectionFactory |
WebLogic アプリケーションで jms/aq/myCF
にある JMS ファクトリをルックアップした場合、アプリケーションはその JMS の javax.jms.ConnectionFactory
インタフェースを実装する AQ JMS オブジェクトを取得します。WebLogic アプリケーションで aq/orderXaTopicFactory
にある JMS ファクトリをルックアップした場合、アプリケーションはその JMS の javax.jms.XAToicConnectionFactory
インタフェースを実装する AQ JMS オブジェクトを取得します。
AQ JMS 外部サーバの接続ファクトリをコンフィグレーションするには、以下の作業を行う必要があります。
ローカルおよびリモートの JNDI 名を指定する。
ローカル JNDI 名は、接続ファクトリを WebLogic JNDI ツリーにバインドするために使用される名前。ローカル JNDI 名は、ローカルの WebLogic Server で公開されている他の JNDI 名と衝突しないように、ユニークなものとする必要があります。
リモート JNDI 名は、AQ JMS 接続ファクトリをルックアップするために AQ JMS へ渡される名前。
AQ JMS をグローバル トランザクションで使用するようにコンフィグレーションする場合、XA ベースの接続ファクトリを使用してください。そうしないと、非 XA ベースの接続ファクトリがコンフィグレーションされます。
これ以外のコンフィグレーション パラメータは不要。
以下を参照してください。
Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「Create foreign connection factories」
AQ JMS の外部送り先をコンフィグレーションする場合、以下の内容をコンフィグレーションする必要があります。
ローカル JNDI 名 - WebLogic JNDI ツリーに送り先をバインドするために使用される名前。ローカル JNDI 名は、ローカルの WebLogic Server インスタンスで公開されている他の JNDI 名と衝突しないように、ユニークなものとする必要があります。
リモート JNDI 名 - ルックアップを行うために AQ JMS に渡される名前。AQ JMS には、以下の構文に従ったリモート JNDI 名が必要です。
送り先がキューの場合、リモート JDNI 名は Queues
/<queue name>
とする必要がある。
送り先がトピックの場合、リモート JDNI 名は Topics
/<topic name>
とする必要がある。
接続ファクトリと同様、AQ JMS の送り先にも、JMS オブジェクト タイプを識別するためにプレフィックスの付いたリモート JNDI 名が必要です。送り先用には以下の 2 つの値が用意されています。
表 8-3 JMS インタフェースの AQ JMS のプレフィックス値
AQ JMS のプレフィックス値 | JMS インタフェース |
---|---|
Queues |
Javax.jms.Queue |
Topics |
javax.jms.Topic |
AQ JMS 接続ファクトリの JNDI 名とは異なり、送り先名の値はデータベースに定義されている AQ JMS 送り先を表しています。「JMS キューまたはトピックの作成」を参照してください。たとえば、AQ JMS 外部サーバに以下の表に示すような 2 つの送り先がコンフィグレーションされているとします。
jms/myQueue
という場所をルックアップする WebLogic アプリケーションは、userQueue
で定義されている AQ JMS キューを参照します。AqTopic
という場所をルックアップすると、myTopic
で定義されている AQ JMS トピックが参照されます。
以下を参照してください。
Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「Create foreign destinations」
以下の節では、高度な WebLogic AQ JMS トピックについて説明します。
MDB (メッセージ駆動型 Bean) は、AQ JMS との相互運用に、コンフィグレーション済みの外部サーバを使用します。「JMS 外部サーバのコンフィグレーション」を参照してください。メッセージ駆動型パラメータ initial-context-factory
および provider-url
は、JMS 外部サーバのコンフィグレーションの一部として提供されるため、サポートされません。ejb-jar.xml
ファイルで、MDB の送り先の送り先タイプを javax.jms.Queue
または javax.jms.Topic
にコンフィグレーションする必要があります。コンテナ管理トランザクション、恒久トピック サブスクリプションなどの MDB 機能を有効にするには、他にも MDB のコンフィグレーションが必要です。
『Oracle Fusion Middleware Oracle WebLogic Server エンタープライズ JavaBeans (EJB) プログラマーズ ガイド』の「メッセージ駆動型 EJB」を参照してください。
AQ JMS 拡張 API が AQ JMS の特定のクラスでサポートされています。AQ JMS 拡張は、標準の JMS オブジェクト (接続ファクトリや送り先など) を独自仕様の AQ JMS クラスにキャストすると、呼び出せるようになります。
AQ JMS 接続ファクトリのリソース参照を使用する場合、WebLogic Server では基底の AQ JMS 接続ファクトリがラッパー オブジェクトでラップされます。このラッパー オブジェクトは JMS の標準 API を実装していますが、AQ JMS 拡張 API を提供する AQ JMS クラスにはそれをキャストできません。ラップ処理を回避するには、リソース参照のリソース タイプとして、デプロイメント記述子の javax.jms.XXXConnectionFactory
の代わりに java.lang.Object
を指定します。この制限事項は AQ JMS に固有のものです。リソース参照は Java インタフェースを使用してエクスポーズされる拡張のみをサポートするためです。AQ JMS では、その拡張用の Java インタフェースは定義されません。AQ JMS では、ラップ処理を回避しても、自動 JTA トランザクションの登録は無効にならず、プーリングも妨げられません。WebLogic データ ソースが組み込まれた状態で使用され、こうした機能が暗黙的に有効な状態になります。
リソース参照を使用することを選択し、リソース タイプが javax.jms.XXXConnectionFactory
である場合、ユーザ アプリケーションに渡される AQ JMS オブジェクトはラップされます。AQ JMS 拡張 API も使用する場合、それらはラップしないようにする必要があります (「AQ JMS 拡張」を参照)。
WebLogic リソース参照ラッパーでは、AQ JMS 接続は自動的にはプールされません。代わりに、AQ JMS のサーバサイド統合はデータ ソースの接続プーリング機能に依存し、それによって JMS 接続およびセッションのオープンとクローズに関わるオーバーヘッドが軽減されます。WebLogic リソース参照でプーリング機能が無効になるのは、AQ JMS プロバイダの JMS 接続ファクトリが常にクライアントの識別子で事前にコンフィグレーションされているためです。逆に、このようになっているので WebLogic リソース参照でプーリング機能が無効になると言うこともできます。
AQ JMS セッションでは、JMS セッションが閉じるまで JDBC 接続が維持されます。これは、その接続でデータ ソースや JDBC URL が使用されるかどうかとは関係なく行われます。セッションが長時間にわたってアイドル状態になった場合、AQ JMS セッションを閉じることをお勧めします。JMS セッションを閉じると、JDBC 接続が開放されて WebLogic データ ソースのプールに戻るか (「データ ソースのチューニング」を参照)、データベースおよび JDBC URL のネットワーク リソースが開放されます。
以下の節では、RAC 環境での制限事項について説明します。
Oracle RAC 環境で AQ JMS RAC のフェイルオーバを実現するには、WebLogic マルチ データ ソースのコンフィグレーションが必要です。『Oracle Fusion Middleware Oracle WebLogic Server JDBC のコンフィグレーションと管理』の「WebLogic Server での Oracle RAC の使い方」を参照してください。
RAC のフェイルオーバは、このリリースでは WebLogic AQ JMS スタンドアロン クライアントの使用時にはサポートされません。
AQ JMS のトレースやデバッグの機能を使用するには、システム プロパティ oracle.jms.traceLevel
を設定する必要があります。
このプロパティの値は 1 ~ 6 までの整数で、6 に設定した場合に詳細度が最大になります。トレースの結果は実行中の JVM の標準出力に出力されます。
以下の節では、WebLogic Server アプリケーションと AQ JMS を相互運用する場合の高度な相互運用に関して説明します。
スタンドアロンのクライアントとサーバサイドのアプリケーションでは、セキュリティのセマンティクスやコンフィグレーションが異なります。セキュリティについて知りたい場合は、この節をよくお読みください。また、WebLogic のロックダウンに関するドキュメントでも、WebLogic Server やクラスタを保護する方法について概説しています (『Oracle Fusion Middleware Oracle WebLogic Server プロダクション環境の保護』を参照)。以下の節では、このリリースでのセキュリティに関する考慮事項について概説します。
AQ では、送り先でのルックアップや、エンキューおよびデキューのため、データベース ユーザに ENQUEUE または DEQUEUE あるいはその両方のパーミッションをコンフィグレーションする必要があります。
以下のユーザ名に対し、ENQUEUE または DEQUEUE あるいはその両方のパーミッションを必ず指定します。
スタンドアロン クライアントの場合。
コンフィグレーション済みの JMS 外部サーバのユーザ名 (java.naming.security.principal
プロパティを使用して指定されたとおり)。
JMS ConnectionFactory API の createConnection()
メソッドを使用して username
を渡す Java コードの場合、この username
にパーミッションが必要です。
サーバサイド アプリケーションの場合。
WebLogic データ ソースに [データベース ユーザ名
] がコンフィグレーションされている。
JMS ConnectionFactory API の createConnection()
メソッドで username
を渡す JDBC データ ソース クライアントに指定されている username
には、パーミッションを付与しない。この username
は WebLogic の username
であり、データベースの username
ではありません。
AQ のルックアップ、エンキュー、およびデキューに使用される JDBC 接続の資格やパーミッションについては、『Oracle Streams Advanced Queuing User's Guide』の「Queue Security and Access Control」を参照してください。
注意 : 送り先のルックアップ時にパーミッションが失敗すると、アプリケーションの呼び出し側に (セキュリティ例外ではなく)「name not found」という例外として明示されます。 |
これまでに説明したように、JMS 外部サーバのコンフィグレーション タスクの一部として、接続ファクトリや送り先のローカル JNDI 名をコンフィグレーションする必要があります。こうした JNDI 名には必要に応じて ACL をコンフィグレーションすることもできます。そのようにすると、JNDI ルックアップ時に現在の WebLogic 資格に基づいてアクセス チェックが行われます。現在の WebLogic 資格はクライアントのタイプによって決まります。
アプリケーションの WebLogic JNDI ルックアップの ACL 資格のチェックで送り先として合格すると、Oracle AQ のその送り先リソースが、JMS 外部サーバの送り先で自動的に JDBC 接続を使用してルックアップされます。
スタンドアロンのクライアントの場合、この送り先ルックアップの 2 番目のプロセスで使用される資格は、JMS 外部サーバにコンフィグレーションされている username
および password
に基づくものです。
サーバサイド アプリケーションの JDBC データ ソース クライアントの場合、この 2 番目の送り先ルックアップで使用される資格は、そのデータ ソースの一部としてコンフィグレーションされているデータベースの username
および password
に基づきます。このデータ ソースへのアクセス権を得るために使用される資格は、現在の WebLogic 資格であることに注意してください。このデータ ソースに WebLogic ACL をコンフィグレーションすることも可能です。WebLogic データ ソースの ID ベースの接続プーリング機能は、この目的のためにはサポートされていません。
前述したように、データベースの資格には、送り先の正常なルックアップのため、その送り先に対する AQ JMS の ENQUEUE または DEQUEUE パーミッションがある必要があります。「AQ 送り先のセキュリティのコンフィグレーション」を参照してください。
JMS の QueueSession
および TopicSession
API には、送り先のルックアップのために、それぞれ createQueue()
、createTopic()
という JNDI に代わるものが用意されています。『Oracle Fusion Middleware 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 Fusion Middleware 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 AQ JMS では、WebLogic メッセージング ブリッジとの相互運用はサポートされていません。
JDBC URL を使用して JMS 外部サーバで定義された AQ JMS 接続ファクトリおよび送り先をルックアップできる、WebLogic AQ JMS スタンドアロン クライアントを作成できます。このクライアントでは、クライアントサイドの classpath に aqapi.jar
、ojdbc6.jar
、orai18n.jar
、および wlclient.jar
または wlfullclient.jar
を指定する必要があります。
WebLogic Server の JVM の外部で実行されるアプリケーションについては、以下のような処理が行われます。
コンフィグレーション済みの WebLogic JMS 外部サーバで、データベースの URL や、その他の JDBC ドライバのコンフィグレーションが参照される。「データベースの JDBC URL を使用した外部サーバのコンフィグレーション」を参照してください。
WebLogic JMS 外部サーバ コンフィグレーションの一部として、AQ JMS の接続ファクトリおよび送り先用にローカル JNDI 名が定義される。これらの JNDI 名は、既存の AQ 接続ファクトリや送り先にマップするようにコンフィグレーションされます。
スタンドアロンのクライアントではローカル JNDI 名を参照する。WebLogic Server で実行されるアプリケーションとは異なり、スタンドアロンのクライアントではドライバおよび AQ クライアントが確実に classpath に存在する必要があります。
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
はデータベースのパスワードを格納。
これ以外のコンフィグレーション プロパティは不要です。
以下の節では、関連ドキュメントへのリンクを紹介します。
『Oracle Fusion Middleware Oracle WebLogic Server パフォーマンス チューニング ガイド』
『Oracle Fusion Middleware Oracle WebLogic Server JMS プログラマーズ ガイド』の「FAQ : リモート JMS プロバイダの統合」
『Oracle Fusion Middleware Oracle WebLogic Server JMS のコンフィグレーションと管理』
『Oracle Fusion Middleware Oracle WebLogic Server スタンドアロン クライアント プログラマーズ ガイド』