| Oracle Containers for J2EEサービス・ガイド 10g（10.1.3.5.0） B56027-01 |
|
 戻る |
 次へ |
Oracle Enterprise Messaging Service（OEMS）は、分散アプリケーションを構築および統合するための強力なメッセージ・プラットフォームです。OEMSにより、Oracleのメッセージ機能とメッセージ統合ソリューションのためのフレームワークが提供されます。
OEMSを構成する主要機能は、次のとおりです。
標準仕様インタフェース
Java Message Service（JMS）およびJ2EE Connector Architecture（J2CA）
メッセージの永続性のサービス品質（Quality of Service）オプション
メモリー内、ファイル・ベースまたはOracleデータベース
Oracle以外のメッセージ・システムとのシームレスな統合
JMSコネクタ、JMSルーターおよびメッセージ・ゲートウェイ（MGW）
この章では、これらすべての機能について説明します。OEMS機能のうち、この章で取り上げていないのは、メッセージ・ゲートウェイのみです。メッセージ・ゲートウェイの詳細は、『Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイドおよびリファレンス』を参照してください。
|
注意: 旧リリースでは、メモリー内、ファイル・ベースおよびデータベースの各永続性オプションを説明する際に、OracleAS JMSおよびOJMSという用語を使用していました。OracleAS JMSはメモリー内およびファイル・ベースのオプションを示し、OJMSはStreams Advanced Queuing（AQ）のJMSインタフェースを示していました。 JMSに関する混乱を避けるため、OracleAS JMSおよびOJMSという用語は使用されません。かわりに、OEMS JMSという用語が使用されます。これは、オラクル社が、メッセージの永続性に関する3つのオプションに対して単一のJMSインタフェースを提供しているという事実を反映しています。3つのサービス品質オプションの間でメッセージの永続性を変更するのであれば、JMSアプリケーション・コードを変更する必要はありません。 |
この章には、次の項目が含まれます。
JMSタスク
この章では、次のJMSタスクについて説明します。
JMSの新機能
次のOC4J JMSの機能および動作は、今回のリリースの新機能です。
JMS 1.1およびJ2EE 1.4準拠: OEMS JMSは、JMS 1.1およびJ2EE 1.4に準拠しています。
JMS 1.1仕様は、http://java.sun.com/products/jms/docs.htmlで入手できます。
J2EE 1.4仕様は、http://java.sun.com/j2ee/1.4/docs/index.htmlで入手できます。
ドメイン統合: 同じJMSコネクションおよびセッションを使用して、OEMS JMSのキューとトピックを操作できます。これは、JMS 1.1の機能の1つです。
JMSコネクタ: JMSコネクタは、OEMS JMSのメモリー内、ファイル・ベースおよびデータベースのリソース・プロバイダと、Oracle以外のJMSプロバイダをOC4Jに統合するための汎用JMS J2CAリソース・アダプタです。統合可能なOracle以外のJMSプロバイダとしてサポートされるのは、WebSphereMQ、TibcoおよびSonicMQです。これらすべてのプロバイダは、OC4Jと完全に統合されています。JMSコネクタでは、メッセージドリブンBean（MDB）がサポートされます。その他の主なメリットは、次のとおりです。
グローバル・トランザクションのサポート
変化する負荷に対応するMDB
JMS接続プーリング（非管理環境で稼働するアプリケーションには実装されない）
パフォーマンス強化機能: グローバル・トランザクションの遅延登録とJMS操作の遅延評価。リソースの登録やコネクション・ファクトリおよび宛先のルックアップなどの特定の操作は、必要になるまで実行されません。
リソース・アダプタの詳細は、『Oracle Containers for J2EEリソース・アダプタ管理者ガイド』を参照してください。
MDBのサポート: 次のJMSリソース・プロバイダでサポートされます。
OEMS JMSのメモリー内、ファイル・ベースおよびデータベース
IBM WebSphere MQベースのJMS
TIBCO Enterprise Message Server
SonicMQ
ドメイン間でのトランザクション: キューとトピックを同じトランザクションで使用できます。これは、JMS 1.1の機能の1つです。
JMSルーター: JMSルーターは、メッセージをブリッジするルーティング・サービスを提供します。JMSルーターの詳細は、「JMSルーター」の項を参照してください。
Oracleおよびサード・パーティ製品のサポート: 次のJMSメッセージ・プロバイダは、OC4Jに付属のJMSコネクタを通じて正式にサポートされます。
OEMS JMSのメモリー内、ファイル・ベースおよびデータベース
IBM WebSphere MQ for JMSバージョン6.0および5.3のリソース・プロバイダ
TIBCO Enterprise Message Serverバージョン4.3.0
SonicMQ JMS 6.0
サード・パーティ・プロバイダの詳細は、「リソース・プロバイダ」を参照してください。リソース・アダプタによるJMSプロバイダの構成と使用を確認できるデモは、http://www.oracle.com/technology/tech/java/oc4j/1013/how_to/index.htmlで入手できます。
開始順序非依存: 詳細は、「JMSコネクタ」の項を参照してください。
デモ・コード: 様々なJMS構成機能のデモを、http://www.oracle.com/technology/tech/java/oc4j/1013/how_to/index.htmlで入手できます。
How-Toドキュメントおよびデモ・セットと、そのURLのリストは、「JMSのHow-Toドキュメントおよびデモ・セット」を参照してください。
JavaクライアントおよびJava中間層サービスでは、エンタープライズ・メッセージ・システムを使用できる必要があります。Java Message Service（JMS）は、Javaプログラムに、これらのシステムにアクセスする共通の方法を提供します。JMSは、アプリケーション・コンポーネント間でデータを渡すための標準のメッセージAPIで、異機種間環境およびレガシー環境でのビジネス統合を可能にします。
この章の内容を理解するには、JMSとJMS APIに関する基本的な知識が必要です。チュートリアルやAPIドキュメントなど、JMSに関する基本情報は、Sun社の次のWebサイトを参照してください。
http://java.sun.com/products/jms/index.jsp
JMSには、次の2つのメッセージ・ドメインがあり、それぞれJMS宛先タイプおよびドメイン固有のJavaインタフェースのセットに関連付けられています。
Point-to-Point: メッセージはJMSキューを使用してシングル・コンシューマに送信されます。
パブリッシュ/サブスクライブ: メッセージは、JMSトピックを使用してすべての登録済リスナーに一斉送信されます。
JMS宛先オブジェクトは、JNDI環境にバインドされ、J2EEアプリケーションで使用可能になります。
それぞれのメッセージ・ドメインに対応する2つのメッセージ・インタフェース・セット以外に、JMS 1.1以上では、ドメイン非依存のアプリケーション・コードを実装するための共通インタフェース・セットも提供しています。この共通インタフェース・セットでは、2つのメッセージ・ドメインの動作が個別に管理されますが（この動作は、JMS宛先タイプとの関連付けに応じて、使用されるメッセージ・ドメインによって制御されます）、両方のメッセージ・ドメインに対して共通のプログラミング・インタフェースが提供されます。この共通インタフェース・セットに属するインタフェースと、ドメイン固有のインタフェースとの関連は、JMS 1.1仕様の表2-1を参照してください。
下位互換性
新しいJMSアプリケーションをデプロイする場合は、J2CA 1.5仕様に基づいており、J2EE 1.4標準に規定されているJMSコネクタを使用することをお薦めします。このマニュアルでは、OracleASで導入された新機能について説明します。ただし、オラクル社では、OracleASの旧リリースでサポートされていた独自仕様のOC4Jリソース・プロバイダを通じてデプロイされたJMSアプリケーションのサポートも継続しています。
Oracle JMSコネクタの詳細は、「JMSコネクタ」を参照してください。
How-Toドキュメントおよび使用例のセット（コメント付き構成ファイルを含む）は、How-To Webサイト（http://www.oracle.com/technology/tech/java/oc4j/1013/how_to/index.html）で入手できます。
JMSドキュメントとデモ・セットは、「Messaging（JMS）」という見出しの下にリストされています。デモ・セットのドキュメントおよびデプロイメント・ディスクリプタ・ファイルは、リソース・プロバイダごとに編成されており、サポート対象の様々なリソース・プロバイダに必要とされる各種の構成が含まれます。関連するリソース・プロバイダに適用されるファイルを解凍して使用してください。
この項では、次のJMS構成の概要について説明します。
このOEMSドキュメントと、関連デモおよびHow-Toドキュメントでは、サポートされる様々なリソース・プロバイダと組み合せてJMSコネクタを使用する方法について、特にOEMS JMSのメモリー内およびファイル・ベースの永続性オプションに重点を置いて説明します。
この項では、JMS操作のために次のコンポーネントを準備する方法について説明します。
リソース・プロバイダのセットと、一致するJMSコネクタのセットという形式で、コネクション・ファクトリおよび宛先オブジェクトの一致セットを作成できます（必須ではありません）。または、JMSコネクタの宛先の一致セットを作成せずに、自動宛先ラッピング機能を使用することもできます。
JMSメッセージ機能を使用するアプリケーションを開発および構成するためのタスクは、次のとおりです。
メッセージを送受信するコードの記述
JMSリソースの論理名の宣言
JMSリソースの論理名の使用
MDBクラスの作成と宣言
メッセージ宛先の宣言
メッセージ宛先へのリンク
onMessageトランザクション属性の定義
アプリケーション・モジュールの一覧表示
詳細は、デモ・セットに含まれるHow-Toドキュメントを参照してください。How-Toドキュメントおよびデモ・セットと、そのURLのリストは、「JMSのHow-Toドキュメントおよびデモ・セット」を参照してください。
アプリケーション・コンポーネント開発者とアプリケーション・アセンブラは、複数のコネクション・ファクトリおよび宛先を開発に使用するため、リソース・プロバイダの構成は、複数の作業に分割されるのが普通です。通常、開発時のコネクション・ファクトリと宛先は、デプロイ時のものとは異なります。開発サーバーと本番サーバーは、別個のマシンであることが普通であり、異なる組織方針に基づいて構成されるためです（場合によっては、異なるリソース・プロバイダが使用されることもあります）。このドキュメントでは、本番のデプロイに重点を置いて説明します。
リソース・プロバイダを構成する場合、次のことを決定する必要があります。
アプリケーションを満足させるのに必要なリソース・プロバイダのコネクション・ファクトリの数とタイプ。
アプリケーションを満足させるのに必要なリソース・プロバイダの宛先の数とタイプ。
リソース・プロバイダのコネクション・ファクトリの作成
リソース・プロバイダの宛先の作成
リソース・プロバイダ参照の宣言
詳細は、デモ・セットのHow-Toドキュメントを参照してください。How-Toドキュメントおよびデモ・セットと、そのURLのリストは、「JMSのHow-Toドキュメントおよびデモ・セット」を参照してください。
OEMSへのJMSコネクタ機能の導入により、様々なリソース・プロバイダの仕様からの独立が部分的に実現しています。J2CA 1.5仕様に基づくJMSコネクタは、リソース・プロバイダに対して、互換レイヤーおよび機能付加型のラッパーとして動作します。
JMSコネクタを構成するためのタスクは、次のとおりです。
ra.xmlの設定。
JMSコネクタ・インスタンスの作成
JMSコネクタのコネクション・ファクトリの作成
JMSコネクタの宛先の作成
詳細は、デモ・セットに含まれるHow-Toドキュメントを参照してください。How-Toドキュメントおよびデモ・セットと、そのURLのリストは、「JMSのHow-Toドキュメントおよびデモ・セット」を参照してください。
oc4j-connectors.xml、oc4j-ra.xmlおよびra.xmlファイルの具体的な使用例は、http://www.oracle.com/technology/tech/java/oc4j/1013/how_to/index.htmlを参照してください。
JMSコネクタのXMLファイルのリファレンス情報は、『Oracle Containers for J2EEリソース・アダプタ管理者ガイド』の付録A「OC4Jリソース・アダプタ構成ファイル」を参照してください。
次に、「How to Configure and Use Oracle's Generic JMS Resource Adapter with OracleAS JMS」と、対応するデモ・ファイルのセットを含むZIPファイルへのリンクを示します。これらのドキュメントに記載されている汎用JMSリソース・アダプタ（Generic JMS Resource Adapter）という用語は、JMSコネクタのことです。
「How to Configure and Use Oracle's Generic JMS Resource Adapter with OracleAS JMS」は、次のURLで参照できます。
対応するデモ・ファイルのセットを含むZIPファイルは、次のURLで入手できます。
この項では、コネクション・ファクトリおよび宛先について、JMS構成ファイル内の参照と定義の間に存在する必要のある整合性について説明します。図4-1「JMS構成」に、相互に一致する必要のある参照と定義を示します。
図4-1は、Javaソース・コード、アプリケーション・デプロイメント・ディスクリプタ、リソース・アダプタ・デプロイメント・ディスクリプタおよびリソース・プロバイダ間の様々なリンクを示しています。各矢印の元にはリンク参照があり、各矢印の先には参照されるアイテムのリンク・キー（名前、JNDIロケーションまたはJavaインタフェース）があります。任意の矢印の先にあるリンク・キーと、矢印の元にあるリンク参照のテキスト表現は、特に指定のないかぎり常に同じになります。
構成ファイルは次のとおりです。
ra.xml
oc4j-ra.xml
application.xml
orion-application.xml
oc4j-connectors.xml
ejb-jar.xml
orion-ejb-jar.xml
application-client.xml
orion-application-client.xml
web.xml
orion-web.xml
デモ・セットには、図4-1「JMS構成」に示されている関係の詳細な説明が含まれます。How-Toドキュメントおよびデモ・セットと、そのURLのリストは、「JMSのHow-Toドキュメントおよびデモ・セット」を参照してください。
関連するHow-To-gjra-with-xxx.zipファイル（xxxは関連するリソース・プロバイダの名前）をダウンロードして解凍します。
関連するhow-to-gjra-with-xxx.htmlドキュメントを開きます。この項の説明は、アイテム間の関係について記載したHow-Toドキュメントの項に対応します。
デモ・セットにも、Javaコードおよびデプロイメント・ディスクリプタのXMLファイルの使用例が含まれます。
Javaソース・コード
J2EEアプリケーションのJavaソース・コードでは、通常、JMSリソースを参照するために論理名を使用します。論理名（<resource-ref>および<message-destination-ref>要素で宣言される参照）は、環境エントリのタイプであり、すべての環境エントリは、JNDIサブコンテキストのjava:comp/env/に配置されます。詳細は、関連するHow-Toドキュメントの「Application Component Provider Task #3: Use Logical Names for JMS Resources」を参照してください。
図4-1には、Javaソース・コードからJ2EEアプリケーション・コンポーネント・デプロイメント・ディスクリプタに向かう次の2つのタイプのリンクがあります。次にリストする各説明の番号は、図のリンク番号に対応しています。
1: 典型的なアウトバウンド・コネクション・ファクトリ・チェーンの1番目のリンクは、Javaソース・コードからJ2EEアプリケーション・コンポーネント・デプロイメント・ディスクリプタの<resource-ref>要素に向かいます。リンク参照は、JMSコネクション・ファクトリを取得するためにJNDIルックアップで使用されるロケーションです。リンク参照には、java:comp/env接頭辞を含める必要があります。<resource-ref>要素のリンク・キーは、その<res-ref-name>サブ要素の値です。リンク・キーには、java:comp/env接頭辞を含めないでください。java:comp/env接頭辞を除けば、リンク参照とリンク・キーは同一です。
2: 典型的なアウトバウンド宛先チェーンの1番目のリンクは、Javaソース・コードからJ2EEアプリケーション・コンポーネント・デプロイメント・ディスクリプタの<message-destination-ref>要素に向かいます。リンク参照は、JMS宛先を取得するためにJNDIルックアップで使用されるロケーションです。リンク参照には、java:comp/env接頭辞を含める必要があります。<message-destination-ref>要素のリンク・キーは、その<message-destination-ref-name>サブ要素の値です。リンク・キーには、java:comp/env接頭辞を含めないでください。java:comp/env接頭辞を除けば、リンク参照とリンク・キーは同一です。
J2EEアプリケーション・コンポーネント・デプロイメント・ディスクリプタ（application-client.xml、ejb-jar.xml、web.xml）
アプリケーション・コンポーネント・プロバイダによって使用される論理名は、物理宛先と多対1の関係にあります。アプリケーション・アセンブラは、物理宛先と1対1の関係にある論理宛先を作成します。次に、アプリケーション・アセンブラは、自身が作成したメッセージ宛先に、アプリケーション・コンポーネント・プロバイダが作成したメッセージ宛先参照およびMDBをリンクする必要があります。これを行うには、適切なメッセージ宛先を名付ける<message-destination-link>要素を追加します。これらのリンクは、宛先チェーンの一部ではありませんが、これにより宛先チェーンを完成するために必要な情報がデプロイヤに提供されます。詳細は、関連するhow-to-gjra-with-xxx.htmlドキュメント（xxxは関連するリソース・プロバイダの名前）の「Application Assembler Task #2: Link to Message Destinations」を参照してください。
図4-1には、J2EEアプリケーション・コンポーネント・デプロイメント・ディスクリプタ内で完結する次の2つのタイプのリンクがあります。
3: アウトバウンド・メッセージの場合、この情報専用リンクは、<message-destination-ref>要素から<message-destination>要素に向かいます。どちらの要素も、J2EEアプリケーション・コンポーネント・デプロイメント・ディスクリプタに含まれます（必ずしも同じである必要はありません）。リンク参照は、<message-destination-link>サブ要素の値です。<message-destination>要素のリンク・キーは、その<message-destination-name>サブ要素の値です。リンク参照には、接頭辞として、リンク・キーを含むファイルの名前とそれに続く#文字が付く場合があります。（この接頭辞は、異なるファイルの様々なリンク・キーがまったく同じ値を保持する場合にのみ必要です。）このオプションの接頭辞を除けば、リンク参照とリンク・キーは同一です。
4: MDBおよびインバウンド・メッセージの場合、この情報専用リンクは、<message-driven>要素から<message-destination>要素に向かいます。どちらの要素も、J2EEアプリケーション・コンポーネント・デプロイメント・ディスクリプタに含まれます（必ずしも同じである必要はありません）。リンク参照は、<message-destination-link>サブ要素の値です。前述のとおり、<message-destination>要素のリンク・キーは、その<message-destination-name>サブ要素の値です。リンク参照には、接頭辞として、リンク・キーを含むファイルの名前とそれに続く#文字が付く場合があります。（この接頭辞は、異なるファイルの様々なリンク・キーがまったく同じ値を保持する場合にのみ必要です。）このオプションの接頭辞を除けば、リンク参照とリンク・キーは同一です。
OC4J固有のアプリケーション・コンポーネント・デプロイメント・ディスクリプタ（orion-application-client.xml、orion-ejb-jar.xml、orion-web.xml）
図4-1には、OC4J固有のアプリケーション・コンポーネント・デプロイメント・ディスクリプタから別のファイルに向かう次の7つのタイプの参照があります。
アプリケーション・コンポーネントでは、J2EEアプリケーション・コンポーネント・デプロイメント・ディスクリプタにコネクション・ファクトリの論理名を宣言します。次に、デプロイヤは、それらの論理名をJMSコネクタのコネクション・ファクトリにマップします。
詳細および使用例は、関連するHow-Toドキュメントの「Deployer Task #1: Map Logical Connection Factories to RA ConnectionFactories」を参照してください。
図には、<resource-ref-mapping>要素で指定される次の2つのタイプのコネクション・ファクトリ・リンクがあります。
6: 典型的なアウトバウンド・コネクション・ファクトリ・チェーンの2番目のリンクは、OC4J固有のアプリケーション・コンポーネント・デプロイメント・ディスクリプタの<resource-ref-mapping>要素からJ2EEアプリケーション・コンポーネント・デプロイメント・ディスクリプタの<resource-ref>要素に戻ります。リンク参照は、<resource-ref-mapping>要素のname属性の値です。前述のとおり、<resource-ref>要素のリンク・キーは、その<res-ref-name>サブ要素の値です。
5: 典型的なアウトバウンド・コネクション・ファクトリ・チェーンの3番目のリンクは、OC4J固有のアプリケーション・コンポーネント・デプロイメント・ディスクリプタの<resource-ref-mapping>要素から、oc4j-ra.xmlファイルの<connector-factory>要素に向かいます。リンク参照は、<resource-ref-mapping>要素のlocation属性の値です。<connector-factory>要素のリンク・キーは、そのlocation属性の値です（この値は、特定の<connector-factory>要素によって定義されるリソース・アダプタのコネクション・ファクトリがバインドされるJNDIロケーションとも一致します）。
アプリケーション・コンポーネントでは、J2EEアプリケーション・コンポーネント・デプロイメント・ディスクリプタに宛先の論理名を宣言します。次に、デプロイヤは、アプリケーション・アセンブラによって<message-destination-link>および<message-destination>の形式で提供される任意の情報を使用して、それらの論理名をJMSコネクタの宛先にマップします。
<message-destination>ごとに、デプロイヤは、その<message-destination>にリンクするすべての<message-destination-ref>およびMDBを同じ宛先にマップする必要があります。
詳細および使用例は、関連するHow-Toドキュメントの「Deployer Task #2: Map Logical Destinations to RA Destinations」を参照してください。
図には、<destination-ref-mapping>要素で指定される次の2つのタイプの宛先リンクがあります。
8: 典型的なアウトバウンド宛先チェーンの2番目のリンクは、OC4J固有のアプリケーション・コンポーネント・デプロイメント・ディスクリプタの<message-destination-ref-mapping>要素からJ2EEアプリケーション・コンポーネント・デプロイメント・ディスクリプタの<message-destination-ref>要素に戻ります。リンク参照は、<message-destination-ref-mapping>要素のname属性の値です。前述のとおり、<message-destination>要素のリンク・キーは、その<message-destination-name>サブ要素の値です。
7: 典型的なアウトバウンド宛先チェーンの3番目のリンクは、OC4J固有のアプリケーション・コンポーネント・デプロイメント・ディスクリプタの<message-destination-ref-mapping>要素から、oc4j-connectors.xmlファイルの<adminobject-config>要素に向かいます。リンク参照は、<message-destination-ref-mapping>要素のlocation属性の値です。<adminobject-config>要素のリンク・キーは、そのlocation属性の値です（この値は、特定の<adminobject-config>要素によって定義されるリソース・アダプタの宛先がバインドされるJNDIロケーションとも一致します）。
MDBごとに、デプロイヤは、MDBのインバウンド・メッセージ要件を満たすために使用されるJMSコネクタ・インスタンス、コネクション・ファクトリおよび宛先を指定する必要があります。
詳細および使用例は、関連するドキュメントの「Deployer Task #2: Map Logical Destinations to RA Destinations」および「Deployer Task #3: Configure the MDB」を参照してください。
図4-1には、orion-ejb-jar.xmlファイルからoc4j-connectors.xmlおよびoc4j-ra.xmlファイルに向かう次の3つのタイプのインバウンド・メッセージ・リンクがあります。
9: コンテナに対し、特定のMDBのインバウンド・メッセージ要件を処理するために使用するJMSコネクタ・インスタンスを指定するリンクは、orion-ejb-jar.xmlファイルのMDBの<message-driven-deployment>要素からoc4j-connectors.xmlファイルのJMSコネクタ・インスタンスの<connector>要素に向かいます。リンク参照は、<message-driven-deployment>要素のresource-adapter属性の値です。<connector>要素のリンク・キーは、そのname属性の値です（この値は、特定の<connector>要素によって定義されるリソース・アダプタ・インスタンスがバインドされるJNDIロケーションとも一致します）。
10: MDBおよびインバウンド・メッセージでは、ここまでに説明した3つのコネクション・ファクトリ・リンクのかわりに、1つのリンクが使用されます。このリンクは、orion-ejb-jar.xmlファイルの<message-driven-deployment>要素からoc4j-ra.xmlファイルの<connector-factory>要素に向かいます。リンク参照は、<message-driven-deployment>のConnectionFactoryJNDIName構成プロパティの値です。前述のとおり、<connector-factory>要素のリンク・キーは、そのlocation属性の値です（この値は、特定の<connector-factory>要素によって定義されるリソース・アダプタのコネクション・ファクトリがバインドされるJNDIロケーションとも一致します）。これは、アウトバウンドの3番目のリンクと同じ場所にリンクしていることに注意してください。コネクション・ファクトリ・チェーンの残りは、インバウンド・メッセージとアウトバウンド・メッセージの両方で同じです。
11: MDBおよびインバウンド・メッセージでは、ここまでに説明した3つの宛先リンクのかわりに、1つのリンクが使用されます。このリンクは、orion-ejb-jar.xmlファイルの<message-driven-deployment>要素からoc4j-connectors.xmlファイルの<adminobject-config>要素に向かいます。リンク参照は、<message-driven-deployment>のDestinationName構成プロパティの値です。前述のとおり、<adminobject-config>要素のリンク・キーは、そのlocation属性の値です（この値は、特定の<adminobject-config>要素によって定義されるリソース・アダプタの宛先がバインドされるJNDIロケーションとも一致します）。これは、アウトバウンドの3番目のリンクと同じ場所にリンクしていることに注意してください。宛先チェーンの残りは、インバウンド・メッセージとアウトバウンド・メッセージの両方で同じです。
oc4j-connectors.xml
JMSコネクタの宛先は、リソース・プロバイダ（RP）の宛先のラッパーとして機能します。JMSコネクタでRPの宛先をルックアップするには、JMSコネクタが、RPの宛先のJNDIロケーションを特定できる必要があります。
詳細および使用例は、関連するHow-Toドキュメントの「Resource Adapter Task #4: Create RA Destinations」を参照してください。リソース・プロバイダの宛先の作成方法は、関連するHow-Toドキュメントの「Configuring the Resource Provider」を参照してください。
図4-1には、oc4j-connectors.xmlに定義されたJMSコネクタの宛先をRPの宛先に関連付ける次の2つのタイプのリンクがあります。
12: 宛先チェーンの最後の部分は、（JMSコネクタの宛先を定義する）oc4j-connectors.xmlファイルの<adminobject-config>要素からリソース・プロバイダの宛先に向かいます。これは、2つのパラレル・リンクで構成されます。1番目のリンクは、<adminobject-config>要素から個々のアプリケーションのorion-application.xmlファイル（または、デフォルト・アプリケーションのapplication.xmlファイル）の<resource-provider>要素に向かいます。リンク参照は、<adminobject-config>のresourceProviderName構成プロパティの値です。<resource-provider>要素のリンク・キーは、そのname属性の値です（この値は、<resource-provider>要素によって定義されるリソース・プロバイダ参照がバインドされるjava:comp/resourceの下のJNDIロケーション（providerName）とも一致します）。
13: 2番目のリンクにより、<adminobject-config>要素からリソース・プロバイダの宛先に向かう接続が完成します。リンク参照は、<adminobject-config>のjndiName構成プロパティの値です。リンク・キーは、リソース・プロバイダ（RP）のJNDIコンテキスト内にあるRPの宛先のJNDIロケーション（resourceName）です。同時に、これら2つのリンクにより、JMSコネクタの宛先にRPの宛先として次の完全なJNDIロケーションが提供されます。
java:comp/resource/providerName/resourceName
oc4j-ra.xml
JMSコネクタのコネクション・ファクトリは、リソース・プロバイダ（RP）のコネクション・ファクトリのラッパーとして機能します。JMSコネクタでRPのコネクション・ファクトリをルックアップするには、JMSコネクタが、RPのコネクション・ファクトリのJNDIロケーションを特定できる必要があります。
詳細および使用例は、関連するHow-Toドキュメントの「Resource Adapter Task #3: Create RA Connection Factories」を参照してください。リソース・プロバイダのコネクション・ファクトリの作成方法は、関連するHow-Toドキュメントの「Configuring the Resource Provider」を参照してください（ただし、これらのコネクション・ファクトリがすべて自動的に前もって作成されるOEMS JMSのデータベースの永続性オプションは除きます）。
図4-1には、oc4j-ra.xmlに指定されたJMSコネクタのコネクション・ファクトリの実装を定義し、それらをRPのコネクション・ファクトリに関連付ける次の3つのタイプのリンクがあります。
15: 理論上、このリンクは、（JMSコネクタのコネクション・ファクトリを定義する）oc4j-ra.xmlファイルの<connector-factory>要素を（JMSコネクタ・インスタンスを定義する）oc4j-connectors.xmlファイルの<connector>要素に関連付けます。現時点では、このリンクは実際に使用されない可能性がありますが、将来的な互換性を考慮して次のように設定する必要があります。リンク参照は、<connector-factory>要素のconnector-name属性の値です。前述のとおり、<connector>要素のリンク・キーは、そのname属性の値です（この値は、特定の<connector>要素によって定義されるJMSコネクタ・インスタンスがバインドされるJNDIロケーションとも一致します）。
16: コネクション・ファクトリ・チェーンの最後の部分は、（JMSコネクタのコネクション・ファクトリを定義する）oc4j-ra.xmlファイルの<connector-factory>要素からRPのコネクション・ファクトリに向かいます。これは、2つのパラレル・リンクで構成されます。1番目のリンクは、リソース・プロバイダ参照がバインドされるjava:comp/resourceの下のJNDIロケーション（providerName）を指定します。そのリンク参照は、ra.xmlファイルに配置されます（矢印番号18の説明を参照）。2番目のリンクにより、<connector-factory>要素からリソース・プロバイダのコネクション・ファクトリに向かう接続が完成します。リンク参照は、<connector-factory>のjndiLocation構成プロパティの値です。リンク・キーは、リソース・プロバイダ（RP）のJNDIコンテキスト内にあるRPのコネクション・ファクトリのJNDIロケーション（resourceName）です。同時に、これら2つのリンクにより、JMSコネクタのコネクション・ファクトリにRPのコネクション・ファクトリとして次の完全なJNDIロケーションが提供されます。
java:comp/resource/providerName/resourceName
このリンクは、実際にはオプションの上書き設定です。（矢印番号17の説明を参照。）慣例的に、このオプションは常に設定します（上書きする値と同じであっても設定します）。
14: JMSコネクタのコネクション・ファクトリ（oc4j-ra.xmlファイルの<connector-factory>要素）の実装の詳細は、<connector-factory>要素をra.xmlファイルの<connection-definition>要素にリンクすることで定義します。リンク参照は、<connector-factory>の<connectionfactory-interface>サブ要素の値です。<connection-definition>要素のリンク・キーは、その<connectionfactory-interface>サブ要素の値です。
ra.xml
JMSコネクタを使用する場合、ra.xmlファイルのほとんどの内容は変更する必要がありません。ra.xmlファイルは、J2EE Connector Architecture 1.5のスキーマ・ファイル（JMS以外のリソース・アダプタも含め、多くのタイプのリソース・アダプタと連携するよう設計されている汎用スキーマ）に基づいているためです。
詳細および使用例は、関連するHow-Toドキュメントの「Resource Adapter Task #1: Customize the ra.xml File」を参照してください。
図4-1には、デフォルトのJMSコネクタのコネクション・ファクトリ設定をra.xmlに定義する次の2つのタイプのリンクがあります。
18: これは、コネクション・ファクトリ・チェーンの最後の部分における1番目のリンクです。（矢印番号16の説明を参照。）このリンクは、ra.xmlファイルの<resourceadapter>要素から個々のアプリケーションのorion-application.xmlファイル（または、デフォルト・アプリケーションのapplication.xmlファイル）の<resource-provider>要素に向かいます。リンク参照は、<resourceadapter>のresourceProviderName構成プロパティの値です。前述のとおり、<resource-provider>要素のリンク・キーは、そのname属性の値です（この値は、<resource-provider>要素によって定義されるリソース・プロバイダ参照がバインドされるjava:comp/resourceの下のJNDIロケーションとも一致します）。注意: ra.xmlファイルのリンク参照値は、単なるデフォルトであり、任意のJMSコネクタ・インスタンスに関して、そのインスタンスのoc4j-connectors.xmlファイルにある<connector>のresourceProviderName構成プロパティを使用して上書きできます。上書きは一般的には不要であるため、この図の矢印では示されていません。
17: このリンクは、<connection-definition>にリンクする<connector-factory>（矢印番号14の説明を参照）にjndiLocation構成プロパティ（矢印番号16の説明を参照）が含まれない場合、デフォルトとして機能します。リンク参照は、<connection-definition>のjndiLocation構成プロパティの値です。リンク・キーは、リソース・プロバイダ（RP）のJNDIコンテキスト内にあるRPのコネクション・ファクトリのJNDIロケーションです。
JMSコネクタによって提供されるほとんどの機能は、アプリケーション・クライアントに適用されません。アプリケーション・クライアントをできるかぎり軽量化するため、アプリケーション・クライアントでJMSコネクタを使用しないよう選択できます。JMSコネクタを使用しない場合、JMSコネクタにのみ必要なJARファイルをクラスパスに含める必要はありません（JMSコネクタに必要なJARファイルのリストは表4-9を参照してください）。
JMSコネクタを使用しないアプリケーション・クライアントは、JMSコネクタを使用するアプリケーション・コンポーネントと通信できます（ただし、基礎となるリソース・プロバイダ（RP）の宛先が両方のコンポーネントで同じである必要があります）。JMSコネクタの省略は、次のようにorion-application-client.xmlファイルでJMSコネクタのリソースではなくリソース・プロバイダのリソースを参照することで行います。
JMSコネクタのコネクション・ファクトリの省略
<resource-ref-mapping>要素ごとに、そのlocation属性の値を次のように設定します。
java:comp/resource/providerName/resourceName
ここで、providerNameは、図4-1「JMS構成」の矢印番号18のリンク・キーと同じであり、resourceNameは、図3-1の矢印番号16のリンク・キーと同じです。これにより、図3-1の矢印番号6、18、16が、RPのコネクション・ファクトリへの直接リンクで置き換えられ、JMSコネクタのoc4j-ra.mxlおよびra.xmlファイルが省略されます。
JMSコネクタの宛先の省略
<message-destination-ref-mapping>要素ごとに、そのlocation属性の値を次のように設定します。
java:comp/resource/providerName/resourceName
ここで、providerNameは、図4-1「JMS構成」の矢印番号12のリンク・キーと同じであり、resourceNameは、図3-1の矢印番号13のリンク・キーと同じです。これにより、図3-1の矢印番号7、12、13が、RPの宛先への直接リンクで置き換えられ、JMSコネクタのoc4j-connectors.xmlファイルが省略されます。
JNDIに直接アクセスする一部のサード・パーティ・ツールまたはライブラリには、java:comp/resource構文や特定のリソース・プロバイダの特殊な名前（Queues/接頭辞やOEMS JMSのデータベース・オプションで使用されるその他の接頭辞など）を許可しない厳密なロケーション制限または検証ルールが存在する場合があります。その場合、JMSコネクタは省略できません。（一般的に、この制限は、OEMS JMSのメモリー内およびファイル・ベースのオプションには適用されません。これらのリソースについては、JNDIルックアップ単独でresourceNameを使用できるためです。つまり、
java:comp/resource/providerName/
という接頭辞は、OEMS JMSのメモリー内またはファイル・ベースのオプションの使用時には、単なるオプションとなります。）
アプリケーションは、JMSコネクタの宛先を、RPのコネクション・ファクトリから導出された任意のオブジェクトに渡すことはできません。また、RPの宛先を、JMSコネクタのコネクション・ファクトリから導出された任意のオブジェクトに渡すこともできません。JMSコネクタでは、すべての送信、受信および参照メッセージのJMSDestinationおよびJMSReplyToヘッダー・フィールドで、任意の宛先タイプが別の宛先タイプに自動的に変換されます。たとえば、JMSコネクタを使用しないアプリケーション・クライアントが、RPのメッセージのJMSReplyToヘッダー・フィールドにRPの宛先を設定してメッセージを送信し、JMSコネクタを使用する別のアプリケーション・コンポーネントがそのメッセージを受信してJMSReplyToヘッダー・フィールドを読み取るとします。このとき、受信側は、元のRPのメッセージおよび宛先をラップするJMSコネクタ互換のメッセージおよび宛先を取得します。これ以外の場合には、自動変換されることはありません。たとえば、この使用例において、メッセージを直接送信するかわりにObjectMessageのボディとして送信した場合、受信側がObjectMessageのボディを抽出したときに、JMSコネクタのメッセージではなくRPのメッセージが取得されます。また、このRPメッセージのJMSReplyToヘッダー・フィールドには、JMSコネクタの宛先ではなくRPの宛先が含まれます。
アプリケーション・クライアントがJMSメッセージの送受信に使用する、基礎となるコネクション・ファクトリおよび宛先は、リソース・プロバイダ・オブジェクトです。OC4Jでは、JMSコネクタの使用により、OEMS JMS（メモリー内、ファイル・ベース、データベース）、IBM MQ、TIBCOおよびSonicの各リソース・プロバイダをプラグインします。
最終的には、リソース・プロバイダ内で宛先とコネクション・ファクトリを作成する必要があります。
リソース・プロバイダを構成する一般的な手順は、次のとおりです。
リソース・プロバイダ参照の宣言
リソース・プロバイダのコネクション・ファクトリの作成
リソース・プロバイダの宛先の作成
JMSプロバイダごとに、プロバイダを構成し、コネクション・ファクトリおよび宛先オブジェクトを作成するための独自の手順があります。OEMS JMS以外のリソース・プロバイダの詳細は、各プロバイダのドキュメントを参照してください。
OEMS JMSのメモリー内およびファイル・ベースのリソース・プロバイダのコネクション・ファクトリと宛先は、作成後にjms.xmlファイルのJNDIにバインドされます。OEMS JMSの永続性オプションの詳細は、「OEMS JMSのメモリー内およびファイル・ベースの永続性」を参照してください。
OEMS JMSのデータベースの永続性オプションのコネクション・ファクトリと宛先は、SQLプロシージャを使用して作成します。OEMS JMSのデータベースの永続性オプションの詳細は、「OEMS JMSのデータベースの永続性」を参照してください。
クライアントは、希望する統合機能およびサービス品質（QOS）機能に応じて、それぞれ独自のリソース・アダプタを持つ1つ以上の異なるJMSリソース・プロバイダを使用できます。
リソース・プロバイダへの参照は、orion-application.xmlファイルおよびapplication.xmlファイルの1つ以上の<resource-provider>要素で宣言します。
OEMS JMSのメモリー内およびファイル・ベースの永続性: これら2つのOEMS JMSの永続性オプションは、OC4Jとともにインストールされます。
OEMS JMSのデータベースの永続性: OEMS JMSのデータベースの永続性オプションは、Oracleデータベースの機能の1つであり、Streams Advanced Queuing（AQ）メッセージ・システムに基づきます。
OEMS JMSのデータベースの永続性オプションのメリットは、次のとおりです。
Oracleデータベースが基盤となります。
OEMS JMSのデータベースの永続性と、他のOracleデータベースのトランザクションを1フェーズ・コミット・トランザクション内で一緒に使用できます。
AQにより提供される拡張機能（PL/SQLおよびOCIとの相互運用性など）にアクセスできます。
サード・パーティJMSプロバイダの使用: 次のサード・パーティJMSプロバイダと統合できます。
WebSphere MQ for JMSバージョン6.0および5.3のリソース・プロバイダ
TIBCO Enterprise Message Serverバージョン4.3.0
SonicMQ 6.0
次のいずれかのファイルを使用して、リソース・プロバイダ参照を宣言します。
リソース・プロバイダ参照をすべてのアプリケーションに認識させるには（グローバル）、グローバルapplication.xmlファイルを使用します。
リソース・プロバイダ参照を単一のアプリケーションにのみ認識させるには（ローカル）、そのアプリケーションに固有のorion-application.xmlファイルを使用します。
次のコードを適切なXMLファイルに追加します。
<resource-provider class="providerClassName" name="providerName"> <description>description </description> <property name="name" value="value" /> </resource-provider>
<resource-provider>属性は、次のように構成します。
class: リソース・プロバイダ・クラスの名前。
OEMS JMSのメモリー内およびファイル・ベースのオプションでは、com.evermind.server.jms.Oc4jResourceProviderを使用します。
OEMS JMSのデータベース・オプションでは、oracle.jms.OjmsContextを使用します。
すべてのサード・パーティ・リソース・プロバイダでは、com.evermind.server.deployment.ContextScanningResourceProviderを使用します。
name: リソース・プロバイダの識別名。この名前を使用して、リソース・プロバイダのJNDIコンテキストをアプリケーションのJNDIに次のようにマップします。
java:comp/resource/providerName/
<resource-provider>のサブ要素は、次のように構成します。
<description>サブ要素: 特定のリソース・プロバイダの説明。
<property>サブ要素: リソース・プロバイダに提供されるパラメータの識別に使用されるnameおよびvalue属性。name属性でパラメータ名を指定し、value属性でその値を指定します。
OC4Jで稼働するアプリケーションまたはリソース・アダプタでリソース・プロバイダにアクセスするには、<resource-provider>要素でリソース・プロバイダ参照を宣言する必要があります。リソース・プロバイダ参照には、OC4Jがリソース・プロバイダと対話するための様々なデータが含まれます。また、リソース・プロバイダ参照には、リソース・プロバイダのリソースにアクセスするためのJNDIサブコンテキストも含まれます。リソース・プロバイダ参照（およびJNDIアクセス）は、orion-application.xmlに配置して特定のアプリケーションのみでローカルに使用するか、%ORACLE_HOME%/j2ee/home/config/application.xmlに配置してすべてのアプリケーションで使用することができます。
リソース・プロバイダ参照を宣言する場合は、常にリソース・プロバイダ参照に使用する名前と、リソース・プロバイダ・インタフェースを実装するJavaクラスを指定する必要があります。
リソース・プロバイダ参照により、リソース・プロバイダのJNDIコンテキスト（リソース・プロバイダのコネクション・ファクトリおよび宛先を含む）が、アプリケーションからアクセス可能なJNDIサブコンテキストにマップされます（この場合、特にJMSコネクタからアクセスできることが重要です）。リソース・プロバイダのリソースに対して、アプリケーションがアクセスできることよりもJMSコネクタがアクセスできることの方が重要なのは、JMSコネクタの使用時には、アプリケーションはリソース・プロバイダの任意のリソースを直接ルックアップまたは使用する必要がなくなるためです（使用してはならないのが普通です）。このJNDIサブコンテキストは、java:comp/resource/providerNameであり、providerNameはリソース・プロバイダ参照の名前です。
http://www.oracle.com/technology/tech/java/oc4j/1013/how_to/index.htmlにあるデモ・セットには、リソース・プロバイダ参照の宣言の例が含まれます。How-Toドキュメントおよびデモ・セットと、そのURLのリストは、「JMSのHow-Toドキュメントおよびデモ・セット」を参照してください。
How-To-gjra-with-xxx.zipファイル（xxxは関連するリソース・プロバイダの名前）をダウンロードして解凍します。
/src/META-INF/orion-application.xmlというファイルを見つけてください。
詳細は、関連するHow-Toドキュメントの「Configuring the Resource Provider」を参照してください。
デモでは、データソースとリソース・プロバイダは、アプリケーションに対してローカルに宣言されています。データソース定義が$J2EE_HOME/config/data-sources.xmlに、リソース・プロバイダ定義が$J2EE_HOME/config/application.xmlに配置されていれば、それらの定義はすべてのアプリケーションに認識されます。（データソースを必要とするか、含んでいるのは、OEMS JMSのデータベースの永続性を使用するプロバイダのデモのみです。）
OC4Jによってサポートされる各リソース・プロバイダでリソース・プロバイダ参照を宣言する方法の詳細（Javaクラスやリソース・プロバイダ参照名の例など）は、次の項を参照してください。
OEMS JMSのメモリー内およびファイル・ベースのオプションでは、次の機能が提供されます。
JMS 1.1仕様への準拠。
J2EE 1.4仕様への準拠。
メモリー内またはファイル・ベースのメッセージの永続性における選択肢の提供。
配信できないメッセージ用の例外キューの提供。
|
注意: Application Server Controlコンソール、MBeanまたはサンプル・コードでOC4J JMSまたはOracleAS JMSという用語が使用されている場合、それらはOEMS JMSのファイル内およびファイル・ベースの永続性オプションを示します。 |
この項には、次の項目が含まれます。
宛先オブジェクトは、キューまたはトピックです。OEMS JMSのメモリー内およびファイル・ベースのオプションは、OC4Jとともにすでにインストールされています。したがって、構成する必要があるのは、アプリケーションで使用するカスタムの宛先オブジェクトとコネクション・ファクトリのみです。
宛先オブジェクトとコネクション・ファクトリを構成するための主要ツールは、Application Server Controlコンソールです。XMLファイルを直接編集することも可能です。
デフォルトのメリットは、次のとおりです。
デフォルトのコネクション・ファクトリは、独自に作成するコネクション・ファクトリのテンプレートとしてコピーして使用できます。また、本番環境でも変更することなく使用できます。
デフォルトの宛先は、独自に作成する宛先のテンプレートとしてコピーして使用できます。ただし、本番環境では使用できません。
XA（グローバル・トランザクション対応）、非XA、および様々なJMSインタフェースの異なる組合せに対して、6つのデフォルト・コネクション・ファクトリが作成されます。アプリケーションでは、Application Server Controlコンソールまたはjms.xmlファイルで追加することなく、これらのコネクション・ファクトリを使用できます。connection-factory要素の1つ以上のオプション属性にデフォルト以外の値を指定する場合にのみ、新規コネクション・ファクトリを定義します。
デフォルトのコネクション・ファクトリ・オブジェクトは、OC4Jによって内部的に作成され、JMSコネクションが作成されるOC4Jサーバー内のデフォルトのJNDIロケーションにバインドされます。
次のデフォルトのコネクション・ファクトリが作成されます（jms.xmlファイルで明示的に定義していない場合でも作成されます）。カスタムのコネクション・ファクトリを作成する場合は、これらのデフォルトを予約済のJNDIロケーションとして扱い、他のJNDIロケーションを使用する方が安全です。
| XA | 非XA | |
|---|---|---|
| デフォルトのキュー・コネクション・ファクトリ | jms/XAQueueConnectionFactory |
jms/QueueConnectionFactory |
| デフォルトのトピック・コネクション・ファクトリ | jms/XATopicConnectionFactory |
jms/TopicConnectionFactory |
| デフォルトの統合コネクション・ファクトリ | jms/XAConnectionFactory |
jms/ConnectionFactory |
デフォルトの宛先は、次のとおりです。
デフォルトのキュー: jms/demoQueue
デフォルトのトピック: jms/demoTopic
Application Server Controlコンソールは、OEMS JMSのメモリー内およびファイル・ベースの永続性オプションのコネクション・ファクトリおよび宛先オブジェクトを構成するための主要ツールです。宛先オブジェクトごとに、その名前、ロケーションおよび宛先タイプ（キューまたはトピック）を指定する必要があります。
Application Server Controlコンソールへのパス:
「OC4J: ホーム」→「管理」タブ→「サービス」→「JMSプロバイダ」→「タスクに移動」→「OracleAS JMSの構成」→適切なタブを選択。
表4-1に、各構成要素と、Application Server Controlコンソール、MBeanおよびjms.xmlファイルでの設定場所を示します。
表4-1 構成要素
| コンソールおよびMBeanでの設定場所 | jms.xmlの要素 | 説明および属性 |
|---|---|---|
|
JMSAdministrator MBeanへのパス: 「OC4J: ホーム」→「管理」タブ→「タスク名: JMX」→「システムMBeanブラウザ」→「タスクに移動」→「J2EEDomain:oc4j」、「J2EEServer:standalone」、「JMSAdministratorResource」、「 |
サーバー構成のルート要素です。
|
|
|
リソース・プロバイダの宛先を作成し、その属性を 「宛先の追加」ページへのパス: 「OC4J: ホーム」→「管理」タブ→「タスク名: サービス」→「JMSプロバイダ」→「タスクに移動」→「宛先」タブ→「新規作成」 |
この要素では、キューを構成します。キューは、OC4Jの起動時に使用可能となり、サーバーが再起動または再構成されるまで使用できます。0（ゼロ）個以上のキューを任意の順序で構成できます。新規に構成したキューは、OC4Jを再起動するまで使用できません。
キューおよびトピックごとに、独自の永続性ファイル名を指定する必要があります。同じ永続性ファイルに書き込む2つのオブジェクトを使用することはできません。
|
|
|
トピックの宛先を作成し、その属性を 「宛先の追加」ページへのパス: 「OC4J: ホーム」→「管理」タブ→「タスク名: サービス」→「JMSプロバイダ」→「タスクに移動」→「宛先」タブ→「新規作成」 |
この要素では、トピックを構成します。トピックは、OC4Jの起動時に使用可能となり、サーバーが再起動または再構成されるまで使用できます。0（ゼロ）個以上のトピックを任意の順序で構成できます。新規に構成したトピックは、OC4Jを再起動するまで使用できません。
キューおよびトピックごとに、独自の永続性ファイル名を指定する必要があります。同じ永続性ファイルに書き込む2つのオブジェクトを使用することはできません。
|
|
|
|
|
|
|
コネクション・ファクトリを作成し、その属性を 「コネクション・ファクトリの追加」または「コネクション・ファクトリの編集」ページへのパス: 「OC4J: ホーム」→「管理」タブ→「タスク名: サービス」→「JMSプロバイダ」→「タスクに移動」→「コネクション・ファクトリ」タブ→「新規作成」または「プロパティの編集」 |
または または |
コネクション・ファクトリの構成です。コネクション・ファクトリ要素には、次の属性が含まれます。
|
|
XA対応のコネクション・ファクトリを作成し、その属性を 「コネクション・ファクトリの追加」または「コネクション・ファクトリの編集」ページへのパス: 「OC4J: ホーム」→「管理」タブ→「タスク名: サービス」→「JMSプロバイダ」→「タスクに移動」→「コネクション・ファクトリ」タブ→「新規作成」または「プロパティの編集」 |
または または
|
コネクション・ファクトリ構成のXAバリアントです。 XA対応のコネクション・ファクトリ要素には、前述のXA非対応のコネクション・ファクトリ要素と同じ属性が含まれます。 |
|
ファイルまたはODL形式によるJMSアクティビティのロギングを有効化します。ロギングの詳細は、『Oracle Containers for J2EE構成および管理ガイド』のOC4Jロギングの有効化に関する項を参照してください。 |
||
|
JMSAdministratorResource MBeanのシステム・プロパティ設定へのパス: 「OC4J: ホーム」→「管理」タブ→「タスク名: JMX」→「システムMBeanブラウザ」→「タスクに移動」→「J2EEDomain:oc4j」、「J2EEServer:standalone」、「JMSAdministratorResource」、「JMSAdministrator」→「操作」タブ→「setConfigProperty」にドリルダウン |
|
システム・プロパティを設定します。設定は、
これらの設定の詳細は、「JMS構成プロパティ」を参照してください。 |
OEMS JMSのメモリー内およびファイル・ベースの構成設定は、jms.xmlファイルに永続化されます。jms.xmlの設定は、次のとおりです。
コネクション・ファクトリ
宛先
JMSルーター・ジョブ
グローバル構成
|
注意: XMLファイルで直接変更した構成を有効化するには、OC4Jインスタンスを再起動する必要があります。 |
後述の例は、jms.xmlファイル内の<jms-server>以降の要素の構造を示しています。この例では、次のように宛先とコネクション・ファクトリを構成します。
キューMyQueueをJNDIロケーションjms/MyQueueに指定
トピックMyTopicをJNDIロケーションjms/MyTopicに指定
コネクション・ファクトリ（統合）をJNDIロケーションjms/Cfに指定
キュー・コネクション・ファクトリをJNDIロケーションjms/Qcfに指定
XAトピックのコネクション・ファクトリをJNDIロケーションjms/xaTcfに指定。
<jms>
<jms-server>
<queue name="MyQueue" location="jms/MyQueue" persistence-file="/tmp/MyQueue">
<description>The demo queue. </description>
</queue>
<topic name="MyTopic" location="jms/MyTopic" persistence-file="/tmp/MyTopic">
<description>The demo topic. </description>
</topic>
<connection-factory location="jms/Cf">
</connection-factory>
<queue-connection-factory location="jms/Qcf">
</queue-connection-factory>
<xa-topic-connection-factory location="jms/xaTcf"
username="foo" password="bar" clientID="baz">
</xa-topic-connection-factory>
<log>
<file path="../log/jms.log" />
</log>
<config-properties>
<config-property name="oc4j.jms.debug" value="true">
</config-property>
</config-properties>
</jms-server>
<jms-router>
<!-- JMS router configuration is shown in the
"JMS Router Configuration in jms.xml" section.
-->
</jms-router>
</jms>
<jms-router>以降の要素の詳細な構造例は、「jms.xmlでのJMSルーターの構成」を参照してください。
スタンドアロンOC4Jインスタンスでは、JMSAdministrator MBeanでポート範囲を設定できます。変更を有効にするには、OC4Jインスタンスを再起動する必要があります。再起動を必要とするのは、ポート設定の特殊な場合です。
管理対象となっている完全なOracle Application Server環境では、Application Server Controlコンソールを使用してポート範囲を構成します。
Application Server Controlコンソールでポート範囲を構成する場合のパス:
「OC4J: ホーム」→「管理」タブ→「タスク名: JVMプロパティ」→「JMSポート」
JMSメッセージを送受信するためのコードは、関連するJMSコネクタまたはリソース・プロバイダに依存しません。
この例は、http://www.oracle.com/technology/tech/java/oc4j/1013/how_to/index.htmlにあるデモ・セットのMyChannel.javaファイルからの抜粋です。
/src/common/MyChannel.javaというファイルを見つけてください。
デモにおいては、MyChannel.javaがJMSメッセージを送受信する唯一のクラスです。他のすべてのクラスでは、MyChannelをコールして送受信を行います。MyChannelは、様々なリソース・プロバイダのすべてに対応します。実際、コネクション・ファクトリと宛先のルックアップに使用できる（論理名に基づかない）代替JNDIロケーションを説明するPlayer.javaのいくつかのコメントを除けば、すべてのリソース・プロバイダの.javaソースは同じものです。
How-Toドキュメントおよびデモ・セットと、そのURLのリストは、「JMSのHow-Toドキュメントおよびデモ・セット」を参照してください。
public MyChannel(String connectionFactoryName, String destinationName) throws Exception {
Context ctx = new InitialContext();
// Get the destination.
Destination destination = (Destination) ctx.lookup(destinationName);
// Get the connection factory.
ConnectionFactory cf = (ConnectionFactory)
ctx.lookup(connectionFactoryName);
// Use the connection factory to create a connection.
connection = cf.createConnection();
// Start the connection.
connection.start();
// Use the connection to create a session.
session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
// Use the session and destination to create a message producer and a message consumer.
producer = session.createProducer(destination);
consumer = session.createConsumer(destination);
}
/**
* Send message.
* prerequisite: channel is open
* @param obj object to be sent
*/
public void send(Serializable obj) throws JMSException {
// Use the session to create a new message.
ObjectMessage msg = session.createObjectMessage(obj);
// Use the message producer to send the message.
producer.send(msg);
System.out.println("Sent message: " + obj);
}
/** * Receive message (wait forever).
* prerequisite: channel is open
* @return object which was received in message, or <code>null</code> if no message was received
*/
public Serializable receive() throws JMSException {
// Use the message consumer to receive a message.
ObjectMessage msg = (ObjectMessage) consumer.receive();
System.out.println("Got message: " + msg.getObject());
return msg.getObject();
}
/**
* Receive message (wait a while).
* prerequisite: channel is open
* @param timeout maximum time (in milliseconds) to wait for a message to arrive
* @return object which was received in message,
* or <code>null</code> if no message was received */
public Serializable receive(long timeout) throws JMSException {
// Use the message consumer to receive a message (if one comes in time).
ObjectMessage msg = (ObjectMessage) consumer.receive(timeout);
if (msg == null) return null;
System.out.println("Got message: " + msg.getObject());
return msg.getObject();
}
/**
* Close channel.
* prerequisite: channel is open
* Once a MyChannel object is closed, it may no longer be used to send or receive
* messages.
*/
public void close() throws JMSException {
// Close the connection (and all of its sessions, producers and consumers).
connection.close();
}
private Connection connection;
private Session session;
private MessageProducer producer;
private MessageConsumer consumer;
}
OEMS JMS実装は、OEMSとの通信に使用されるコマンドライン・ユーティリティに含まれており、JMS宛先のリスト作成や参照などのタスクを実行します。ユーティリティ・クラス（com.evermind.server.jms.JMSServerUtils）は、oc4j-internal.jarのOC4Jに付属しています。このユーティリティによって提供されるタスクの多くは、Oracle Enterprise Manager 10gコンソールを使用してアクセス可能な一連のMBeanからも使用できます。MBeanの使用方法の詳細は、「JMS MBeanの使用」を参照してください。
ユーティリティでは、実行時に次のJARファイルが必要です。これらのJARファイルは、CLASSPATH環境変数に追加できます。
J2EE_HOME\oc4j.jar
J2EE_HOME\oc4j-api.jar
J2EE_HOME\oc4jclient.jar
J2EE_HOME\rmic.jar
J2EE_HOME\lib\adminclient.jar
J2EE_HOME\lib\connector.jar
J2EE_HOME\lib\javax77.jar
J2EE_HOME\lib\jmxri.jar
J2EE_HOME\lib\oc4j-internal.jar
ユーティリティの構文は次のとおりです。
java com.evermind.server.jms.JMSServerUtils [generic-options] [command] [command-options] [arguments]
使用方法の詳細を参照するには、helpコマンドを使用します。
java com.evermind.server.jms.JMSServerUtils help
すべてのオプションおよびコマンドは、表4-2、表4-3および表4-4に説明されています。汎用オプションは、OracleAS JMSサーバーへの接続に使用されます。
|
注意: JMSServerUtilsを使用してサーバーに接続するには、OEMS JMSサーバーが実行されている必要があります。また、JMSServerUtilsで、管理者ロール内のユーザーとして接続できるのはJMSサーバーのみです。ユーザーは、セキュリティ・ユーザー・マネージャ内でロールに追加されます。セキュリティ・ロール内でのユーザーの定義の詳細は、『Oracle Containers for J2EEセキュリティ・ガイド』を参照してください。 |
表4-2 JMSユーティリティの汎用オプション
| オプション | 説明 |
|---|---|
|
|
OracleAS JMSサーバーがインストールされている（リモート）ホスト。クライアントがOracleAS JMSサーバーと同じノードに存在している場合、このオプションは不要です。 |
|
|
OracleAS JMSサーバーへのアクセスに使用される（リモート）ポート。デフォルトのJMSポート番号は9127です。 |
|
|
JMS接続を作成する際にOracleAS JMSサーバーにアクセスするためのユーザー名。このユーザーは、管理ロール内のユーザー・マネージャ・セキュリティ構成に定義されています。 |
|
|
JMS接続を作成するためにOracleAS JMSサーバーにアクセスするためのパスワード。このパスワードは、管理ロール内のユーザー・マネージャ・セキュリティ構成に定義されています。 |
|
|
すべてのJMS接続にこの識別子を使用します。トピックの永続サブスクリプションを特定する場合にのみ必要です。 |
コマンドは、実行される処理の内容を表します。表4-3で各コマンドを説明します。一部のコマンドには、実行する処理をさらに特定するための独自のオプション（command-options）があります。
| コマンド | 説明 |
|---|---|
|
すべてのユーティリティ・コマンドの詳細なヘルプを出力します。 |
|
|
|
|
|
使用可能なすべてのシステム・プロパティ（表4-6を参照）とOC4J JMSサーバーの現在の設定を表示します。 |
|
|
OC4J JMSサーバーの使用可能なすべてのDMS統計を表示します（JMS以外の統計も含まれます）。（DMSの詳細は、『Oracle Application Serverパフォーマンス・ガイド』を参照してください。） |
|
|
OC4J JMSが認識しているすべての永続 |
|
|
OC4J JMSが認識しているすべての永続サブスクリプションのリストを出力します。 |
|
|
<topic>に永続サブスクリプションを作成します。名前、メッセージ・セレクタ、ローカルであるかどうか、および永続サブスクリプションのクライアント識別子を指定します。これにより、既存のアクティブでない永続サブスクリプションが置き換えられます。名前は、 |
|
|
既存のアクティブでない永続サブスクリプションを削除します。永続サブスクリプションは、名前（ |
|
|
指定された宛先（ |
|
|
指定された宛先（キューまたはトピックの永続サブスクリプション）のメッセージをデキューします。 |
|
|
ある宛先（キューまたはトピックの永続サブスクリプション）から別の宛先にメッセージをコピーします。発信側と受信側の宛先が同一の場合はコマンドは実行されず、かわりにエラーが生成されます。 |
|
|
ある宛先（キューまたはトピックの永続サブスクリプション）から別の宛先にメッセージを移動します。発信側と受信側の宛先が同一の場合はコマンドは実行されず、かわりにエラーが生成されます。 |
表4-4 JMSユーティリティ・コマンドのオプション
| コマンド・オプション | 説明 |
|---|---|
|
|
指定されたJMSメッセージ・セレクタを使用して、キュー・レシーバおよび永続サブスクライバを作成します。 |
|
|
|
|
|
トピックで実行中の永続サブスクリプションの名前を定義します。このオプションは、トピックの読取りを行うコマンドでは必須で、キューの読取りでは無視されます。 |
|
|
処理中にはメッセージを出力しません。標準エラーと出力された、処理済のメッセージの合計件数を保持します。 |
|
|
現行の操作中には、指定された数を超えるメッセージは処理しません。数値が負の値またはゼロの場合は、選択されたすべてのメッセージが処理されます。 |
次の例では、クライアント・ユーティリティと同じコンピュータに配置されているOracleAS JMSサーバーに接続して例外キューを参照し、このキューで処理されたメッセージの数を戻します。
java com.evermind.server.jms.JMSServerUtils -username <username> -password <password> browse jms/Oc4jJmsExceptionQueue
トピックのリスニング
トピックをリスニングするには、まず（JMSUtilsを使用して）永続サブスクリプションを設定し、（所有する任意のパブリッシャを使用して）いくつかのメッセージをパブリッシュし、（JMSServerUtilsで参照して）これらのメッセージを取得します。
トピックをリスニングするには、次のようにします。
永続サブスクリプションを設定します。
java com.evermind.server.jms.JMSServerUtils -username oc4jadmin -password welcome1 -port 9127 -clientID demedclient subscribe -name demedjmsutils "Demo Topic"
そのトピックでいくつかのメッセージをパブリッシュします。
次のようにしてメッセージを参照します。
java com.evermind.server.jms.JMSServerUtils -username oc4jadmin -password welcome1 -port 9127 -clientID demedclient browse -name demedjmsutils "Demo Topic"
サブスクリプションと参照の両方で、同じclientIDおよびnameを使用します。これらはJMSの基本的なオプションで、clientIDはコネクション・ファクトリを、nameはそのコネクション・ファクトリの特定のサブスクリプションを指定します。
OEMS JMS実装は、OEMSとの通信に使用される一連のJMX MBeanに含まれており、JMS宛先のリスト作成や参照などのタスクを実行します。MBeanには、Oracle Enterprise Manager 10gコンソールを使用してアクセスします。MBeanを介して使用可能な属性や操作の多くは、コマンドライン・ユーティリティからも使用できます。コマンドライン・ユーティリティの使用方法の詳細は、「JMSユーティリティの使用」を参照してください。
次のMBeanには、Oracle Enterprise Manager 10gコンソールからアクセスします。
JMSAdministrator MBeanへのパス:
「OC4J: ホーム」→「管理」タブ→「タスク名: JMX」→「システムMBeanブラウザ」→「タスクに移動」→「J2EEDomain:oc4j」、「J2EEServer:standalone」、「JMSAdministratorResource」、「JMSAdministrator」にドリルダウン
JMS MBeanへのパス:
「OC4J: ホーム」→「管理」タブ→「タスク名: JMX」→「システムMBeanブラウザ」→「タスクに移動」→「J2EEDomain:oc4j」、「J2EEServer:standalone」、「JMSResource」、「JMS」にドリルダウン
様々なJMSDestinationResource MBeanへのパス:
「OC4J: ホーム」→「管理」タブ→「タスク名: JMX」→「システムMBeanブラウザ」→「タスクに移動」→「J2EEDomain:oc4j」、「J2EEServer:standalone」、「JMSResource」、「JMS」、「JMSDestinationResource」にドリルダウン→希望の宛先を示すMBeanを選択
表4-5 JMS MBean参照
| MBean実装 | コマンドラインの等価 | 説明 |
|---|---|---|
|
|
|
使用可能なすべてのシステム・プロパティ（表4-6を参照）と現在の設定を表示します。 |
|
|
|
|
|
|
|
指定されたJMSメッセージ・セレクタの妥当性をチェックします。この操作には、引数 |
|
|
|
指定された2つのセレクタを等価に扱えるかどうかをチェックします。これは、永続サブスクリプションを再アクティブ化する際に役立ちます。 この操作には、引数 |
|
ドメインが |
|
宛先に永続サブスクリプションを作成します。これにより、既存のアクティブでない永続サブスクリプションが置き換えられます。 この操作には、次の引数が含まれます。
|
|
ドメインが |
|
永続サブスクリプションを削除します。 この操作には、次の引数が含まれます。
|
|
すべてのJMSDestinationResource Mbeanの |
|
この宛先を参照します。 この操作には、次の引数が含まれます。
|
|
すべてのJMSDestinationResource Mbeanの |
|
メッセージをこの宛先から指定された宛先にコピーします。 この操作には、次の引数が含まれます。
|
|
すべてのJMSDestinationResource Mbeanの |
|
この宛先からメッセージを排出します。 この操作には、次の引数が含まれます。
|
|
すべてのJMSDestinationResource Mbeanの |
|
メッセージをこの宛先から指定された宛先に移動します。 この操作には、次の引数が含まれます。
|
ファイル・ベースの永続性が有効の場合、OC4Jでは、次の操作が自動的に実行されます。
永続性ファイルが存在しない場合、OC4Jにより、自動的にファイルが作成されて適切なデータで初期化されます。
永続性ファイルが存在しているが空の場合、OC4Jにより、適切なデータで初期化されます。
|
注意: OC4Jサーバーがアクティブなときに、永続性ファイルのコピー、削除または名前変更を実行しないでください。このような操作を実行すると、データが破損してメッセージが消失する可能性があります。OC4Jがアクティブではないときに、永続性ファイルを削除すると、その永続性ファイルに関連付けられている宛先からすべてのメッセージおよび永続サブスクリプションが削除されます。ファイルは、OC4Jの再起動時に、JMSサーバーにより通常の方法で再度初期化されます。 詳細は、「永続性ファイルの管理」を参照してください。 |
永続性が有効化されていても、ファイルに残るのは特定のメッセージのみです。メッセージが永続化されるためには、次の条件がすべて満たされている必要があります。
Application Server Controlコンソールで永続性ファイルを指定するか、jms.xmlファイルで宛先のpersistence-file属性を設定することにより、宛先オブジェクトの永続化を定義していること。
メッセージにPERSISTENT配信モードが設定されていること。これは、デフォルト・モードです。
非永続配信モード（DeliveryMode.NON_PERSISTENTとして定義される）が設定されたメッセージが永続的な宛先に送信されても、それらのメッセージは永続化されません。
宛先がキューである場合。または、宛先がトピックであり、コンシューマが永続サブスクライバである場合。
DeliveryModeをPERSISTENTまたはNON_PERSISTENTに設定する方法は、JMS仕様を参照してください。
メッセージ・プロデューサにデフォルトのDeliveryModeを設定する方法は、http://java.sun.com/j2ee/1.4/docs/api/javax/jms/MessageProducer.html#setDeliveryMode(int)を参照してください。
デフォルト設定を上書きしてメッセージごとにDeliveryModeを設定する方法は、http://java.sun.com/j2ee/1.4/docs/api/javax/jms/MessageProducer.html#send(javax.jms.Destination,%20javax.jms.Message,%20int,%20int,%20long)およびhttp://java.sun.com/j2ee/1.4/docs/api/javax/jms/MessageProducer.html#send(javax.jms.Message,%20int,%20int,%20long)を参照してください。
ファイル・ベースの永続性を有効化する際の注意
前述の条件が満たされる場合、ファイル・ベースの永続性オプションにより、メッセージ用にリカバリ可能な永続記憶域が提供されます。各宛先は、宛先オブジェクトに送信されたメッセージを格納するためのファイルを指し示す相対または絶対パス名に関連付けることができます。ファイルは、ファイル・システムの任意の場所に配置できます（必ずしもJ2EE_HOMEディレクトリ内である必要はありません）。同じディレクトリに複数の永続性ファイルを配置できます。永続性ファイルは、リモート・ネットワークのファイル・システムに配置するか、ローカル・ファイル・システムの一部とすることが可能です。
Application Server Controlコンソールは、宛先オブジェクト用にファイル・ベースの永続性を有効化するための主要ツールです。次のパスを使用して、Application Server Controlコンソールで永続性ファイルのパラメータを指定します。
Application Server Controlコンソールで宛先の永続性ファイルを指定する場合のパス:
「OC4J: ホーム」→「管理」タブ→「タスク名: サービス」→「JMSプロバイダ」→「タスクに移動」→「宛先」→「新規作成」→「永続性ファイル」
永続性ファイルは、新規の宛先を作成するときにApplication Server Controlコンソールで指定できます。既存の宛先の永続性ファイルの指定は、コンソールでは変更できません。永続性の指定は、jms.xmlファイルで変更できます。「jms.xmlファイルでのファイル・ベースの永続性の有効化」を参照してください。
宛先オブジェクトのファイル・ベースの永続性は、jms.xmlファイルのpersistence-file属性を指定することで有効化できます。
次のXML構成の例に、persistence-file属性を使用してファイル名をpersと定義する方法を示します。
<queue name="foo" location="jms/persist" persistence-file="pers"> </queue>
persistence-file属性のパスは、ファイルの絶対パス、またはapplication.xmlに定義されているpersistenceディレクトリに対する相対パスです。
OC4Jサーバーは、永続性ファイル用のディレクトリを一切作成しません。そのため、永続性ファイルをjms.xmlに定義する場合、次のように既存の絶対ディレクトリを指定する必要があります。
persistence-file="/this/dir/exists/PersistenceFile"
または、次のようにファイル名のみを指定します。
persistence-file="PersistenceFile"
ファイル名のみを指定する場合、永続性ファイルは、デフォルトで$J2EE_HOME/persistence（スタンドアロン・インスタンスの場合）または$J2EE_HOME/persistence/<group_name>（完全なOracle Application Server環境の場合）に作成されます。
persistence-file属性の詳細は、表4-1「構成要素」を参照してください。
Oracle Application Serverでは、複数のOC4Jインスタンスが同じファイル・ディレクトリに書き込む場合があり、その際に同じ永続性ファイル名を指定する場合もあります。この属性を設定するとファイル・ベースの永続性が有効化されますが、永続性ファイルが他のOC4Jインスタンスにより上書きされる可能性もあります。
次の項では、永続性のリカバリの様々な側面について説明します。
リカバリ可能性の有効範囲
OEMS JMSのファイル・ベースの永続性オプションでは、発生する可能性のある一部の障害からのリカバリが可能ですが、すべての障害からリカバリできるわけではありません。次のいずれかの障害が発生した場合、永続性ファイルのリカバリ可能性は保証されません。
メディアの破損: 永続性ファイルを保持するディスク・システムが異常終了したか破損した場合。
外部的な破損: 永続性ファイルが、削除、編集、変更されるか、（ソフトウェアによって）他の方法で破壊された場合。永続性ファイルへの書込みは、JMSサーバーにのみ許可する必要があります。
エラーを戻さない失敗または破損: JDKのI/Oメソッドが、エラーを戻さずに失敗したか、読取りまたは書込み中のデータを破壊してエラーを戻さない場合。
java.io.FileDescriptor.sync()の失敗: sync()コールが、指定のディスクリプタに関連付けられているファイル・バッファすべてを、基礎となるファイル・システムに正常かつ完全にフラッシュしない場合。
JMSサーバーの稼働中は、現在使用中の永続性ファイルのコピー、削除または名前変更を実行しないでください。使用中の永続性ファイルに対してこれらのアクションを実行すると、リカバリ不可能なエラーが発生します。
ただし、OEMSサーバーで永続性ファイルが使用されていない場合は、これらのファイルに対して次の管理およびメンテナンス操作を実行できます。
削除: 永続性ファイルを削除すると、すべてのメッセージが削除され、トピックの場合はすべての永続サブスクリプションが削除されます。起動時に、OEMS JMSにより新しい空の永続性ファイルが初期化されます。
コピー: 既存の永続性ファイルをアーカイブまたはバックアップのためにコピーできます。既存の永続性ファイルが破損した場合に、（OEMS JMSの宛先名とファイル間の関連付けが維持されていれば）適切なパス名によって示される以前のバージョンを使用して、JMS宛先の以前の内容に戻すことができます。
永続性ファイルの連結、分割、並替え、マージはできません。このような操作を実行すると、永続性ファイル内のデータが破損し、リカバリ不可能になります。
OEMS JMSのメモリー内およびファイル・ベースのオプションでは、内部構成およびトランザクション状態管理のために、ユーザー指定の永続性ファイルとロック・ファイルに加えて特殊ファイルjms.stateが使用されます。OEMS JMSサーバーは、通常の操作中にこのファイルとその内容をクリーン・アップします。アーカイブを目的とする場合でも、このファイルは削除、移動、コピーまたは変更しないでください。jms.stateファイルを操作すると、メッセージとトランザクションが消失する可能性があります。
|
注意: jms.stateファイルの位置は、OC4Jの運用モード（スタンドアロンまたはOracle Application Serverモード）に応じて次のように異なります。
persistenceディレクトリの位置は、 |
JMSクライアントへのエラーのレポート
JMSクライアントがメッセージをエンキューまたはデキューしたり、トランザクションをコミットまたはロールバックするときの操作順序は、次のとおりです。
クライアントがファンクション・コールを実行します。
事前永続性操作が行われます。
永続性が発生します。
事後永続性操作が行われます。
クライアントのファンクション・コールが戻ります。
事前永続性フェーズまたは永続性フェーズで障害が発生すると、クライアントは、JMSExceptionや他のなんらかのタイプのエラーを受け取りますが、永続性ファイルは変更されません。
事後永続性フェーズで障害が発生すると、クライアントは、JMSExceptionや他のなんらかのタイプのエラーを受け取ります。ただし、永続性ファイルはそのまま更新され、OEMS JMSは操作が成功した場合と同様にリカバリします。
OC4Jが正常終了すると、ロック・ファイルが自動的にクリーン・アップされます。ただし、（kill -9コマンドなどにより）OC4Jが異常終了すると、ロック・ファイルはファイル・システムに残ります。通常、残されたロック・ファイルは、OC4Jに認識されます。認識されない場合は、異常終了してからOC4Jを再起動する前に、ロック・ファイルを手動で削除する必要があります。
ロック・ファイルのデフォルトの位置は、persistenceディレクトリです（J2EE_HOME/persistence）。persistenceディレクトリは、application.xmlファイルで定義されます。その他の位置は、宛先オブジェクトのpersistence-file属性内で設定できます。
ロック・ファイルは、複数のOC4Jプロセスが同じ永続性ファイルに書き込まないようにします。複数のOC4J JVMが、同じ位置の同じ永続性ファイルを指し示すように構成されていると、データが相互に上書きされ、永続化されたJMSメッセージが破損または消失する可能性があります。このような共有違反を防止するため、OEMS JMSでは、各永続性ファイルがロック・ファイルに関連付けられます。そのため、各永続性ファイル（/path/to/persistenceFileなど）は、/path/to/persistenceFile.lockというロック・ファイルに関連付けられます。永続性ファイルの詳細は、「ファイル・ベースの永続性の構成」を参照してください。
OC4Jには、ロック・ファイルを作成および削除するための適切なパーミッションが必要です。
終了後に再起動した場合、次のいずれかのロック・ファイル操作が適用されます。
正常終了: ロック・ファイルは、自動的にクリーン・アップされます。再起動は通常どおり進行します。
異常終了: 再起動時に、ロック・ファイルが認識されます。再起動は通常どおり進行します。
異常終了: 再起動時に、共有違反を示すクリティカル・メッセージが配信されます。再起動は継続できません。エラー・メッセージに示されたロック・ファイルを削除し、再起動してください。複数のロック・ファイルが関連している場合、それぞれのファイルを削除する必要があります。
JMS永続性のロック・ファイルには、サーバーおよびpersistenceディレクトリの位置情報が含まれています。JMSサーバーの起動時にロック・ファイルが存在し、ロック・ファイルが（同じIPアドレスを持つ）同じサーバーで、同じpersistenceディレクトリの位置を使用して作成されている場合、JMSサーバーは、そのロック・ファイルの制御を継承して正常に起動します。
これ以降に記載するOEMS JMSのファイル・ベースのリカバリ手順では、関連するすべてのロック・ファイルが削除されていると仮定して説明を続けます。
OEMS JMSは、異常終了時にOEMS JMSで構成されていたすべての永続性ファイルに対してリカバリ操作を実行します。つまり、OC4Jが異常終了し、ユーザーがJMSサーバーの構成を変更してOC4Jを再起動した場合、JMSサーバーは、元の構成に存在していたすべての永続性ファイルをリカバリしようとします。JMSサーバーは、リカバリの成功後に、指定された新しい構成に移行します。
古い構成のリカバリに失敗すると、JMSサーバーは起動しません。サーバーは停止されるか、またはリカバリに成功するまで繰り返し再起動されます。
JMSサーバーは、jms.stateファイルに現行の永続性構成をキャッシュします。このファイルは、トランザクション状態の維持にも使用されます。現行構成を完全にリカバリしない場合は、jms.stateファイルとすべてのロック・ファイルを削除し、構成の変更を受け入れることで、サーバーを白紙の状態で起動できます。（この方法はお薦めしません。）jms.stateファイルが見つからない場合は、JMSサーバーにより新規作成されます。
なんらかの理由でjms.stateファイル自体が破損した場合は、このファイルを削除する必要があります。これに伴い、保留中のすべてのトランザクション（コミットされたが、そのトランザクションに参加する個々の宛先オブジェクトすべてによってコミットされていないトランザクション）は消失します。
異常終了時にメッセージ・アクティビティが進行中だった場合、OEMS JMSは、永続性ファイルのリカバリを試行します。データの（前述したタイプの）破損は、破損データのクリーン・アウトにより処理されますが、これによりメッセージとトランザクションが消失する可能性があります。
永続性ファイルのヘッダーが破損すると、この種の破損ファイルはユーザー構成エラーと区別できないことが多いため、OEMS JMSではファイルをリカバリできなくなる場合があります。oc4j.jms.forceRecovery管理プロパティ（表4-6「システム・プロパティ」を参照）を使用すると、（メッセージの消失やユーザー構成エラーの隠蔽というデメリットはありますが）無効なデータをすべて消去してリカバリを続行するようにJMSサーバーに指示できます。
OEMS JMSのメモリー内およびファイル・ベースのオプションには、JMS仕様の拡張機能として、配信できないメッセージを処理するための事前定義済の例外キューが付属しています。これは、単一の永続的なグローバル例外キューであり、OEMS JMSの宛先から配信できないメッセージが格納されます。例外キューには、次の固定プロパティがあります。
固定の名前: jms/Oc4jJmsExceptionQueue
固定のJNDIロケーション: jms/Oc4jJmsExceptionQueue
固定の永続性ファイル: Oc4jJmsExceptionQueue
|
注意: Oc4jJmsExceptionQueue永続性ファイルの位置は、OC4Jの運用モード（スタンドアロンまたはOracle Application Serverモード）に応じて次のように異なります。
|
例外キューは、JMSサーバーとそのクライアントで常に使用可能です。jms.xml構成ファイルで明示的に定義することはできません。定義しようとすると、エラーが発生します。例外キューの名前、JNDIロケーション、およびpersistenceディレクトリへのパス名は、各ネームスペースにおける予約語になります。これらの名前で他のエンティティを定義しようとすると、エラーが発生します。
メッセージは、期限切れまたはリスナー・エラーが原因で配信できなくなることがあります。次の項では、期限切れで配信できないメッセージに対して実行される操作について説明します。
デフォルトでは、永続的な宛先に送信されたメッセージが期限切れになると、そのメッセージは例外キューに移動されます。期限切れになったメッセージのJMSXStateは、EXPIREDを示す値である3に設定されますが、メッセージ・ヘッダー、プロパティおよびボディは特に変更されません。メッセージはObjectMessageにラップされ、ラップされたメッセージが例外キューに送られます。
ラップしているObjectMessageのDeliveryModeは、元のメッセージと同じです。
デフォルトでは、非永続的または一時的な宛先オブジェクトで期限切れになったメッセージは、例外キューに移動されません。通常、これらの宛先オブジェクトに送信されたメッセージは、永続化の必要がないと判断され、期限切れバージョンも存在しません。
送信先となる宛先オブジェクトが永続的、非永続的、一時的のいずれであるかにかかわらず、期限切れのメッセージをすべて例外キューに送信するよう指定できます。これには、OC4Jサーバーの起動時に、oc4j.jms.saveAllExpired管理プロパティをtrueに設定します（表4-6「システム・プロパティ」を参照）。この場合、期限切れのメッセージはすべて例外キューに移動します。これにより、非永続的なメッセージが例外キューに送られた場合でも、その非永続的な性質は変化しません。
OEMS JMSのメモリー内およびファイル・ベースのオプションでは、次の場合にメッセージ本文のページング・インおよびページング・アウトがサポートされます。
メッセージが永続的な配信モードに設定されている場合。
メッセージが永続的な宛先オブジェクトに送信される場合（「ファイル・ベースの永続性の構成」を参照）。
宛先がキューである場合。または、宛先がトピックであり、コンシューマが永続サブスクライバである場合。
OC4JサーバーのJVMのメモリー使用量がユーザー定義のしきい値を超えた場合。
ページングされるのはメッセージ本文のみです。メッセージ・ヘッダーとプロパティは、ページングされません。ページングしきい値は、システム・プロパティのoc4j.jms.pagingThresholdを使用して設定できます（表4-6「システム・プロパティ」を参照）。
しきい値の範囲は、0.0〜1.0です。JVMメモリーを使用しないJavaプログラムを記述するのはまず不可能であり、プログラムは、JVMヒープがいっぱいになる前にメモリーをすべて消費して終了するのが普通です。
たとえば、ページングしきい値が0.5の場合にJVMのメモリー使用率が0.6に上昇すると、JMSサーバーは、メモリー使用率がしきい値を下回るまで、またはメッセージ本文をそれ以上ページング・アウトできなくなるまで、可能なかぎり多くのメッセージ本文をページング・アウトしようとします。
ページング・アウトされたメッセージがJMSクライアントからリクエストされると、JMSサーバーは、（JVMのメモリー使用率とは関係なく）そのメッセージ本文を自動的にページング・インし、正しいメッセージ・ヘッダーと本文をクライアントに配信します。クライアントに配信されたメッセージは、サーバーJVMでのメモリー使用率に応じて再びページング・アウトの対象とみなすことができます。
メモリー使用率がページングしきい値を下回ると、JMSサーバーは、メッセージ本文のページング・アウトを停止します。すでにページング・アウトされていたメッセージ本文が自動的にページング・インされることはありません。メッセージ本文のページング・インは、必要な場合（つまり、メッセージがデキューされるかクライアントにより参照される場合）にのみ発生します。
デフォルトでは、ページングしきい値は1.0に設定されます。つまり、デフォルトでは、メッセージ本文はページングされません。
ページングしきい値として適切な値は、JMSアプリケーション、送受信するメッセージのサイズ、および実際の使用例における試行結果とメモリー使用率の監視結果に応じて選択する必要があります。
ページングしきい値には、正しい値を指定する必要があります。JMSのセマンティクスは、ページングが有効であるかどうかにかかわらず常に維持されます。ページングしきい値の設定により、JMSサーバーは、ページングを使用しない場合よりも多くのメッセージをメモリー内で処理できます。
OEMS JMSのメモリー内およびファイル・ベースのオプションとJMSクライアントの実行時構成は、JVMシステム・プロパティを通じて管理します。これらのプロパティは、JMSの基本機能には影響しません。これらのプロパティは、JMSサーバーに固有の機能、拡張機能およびパフォーマンスの最適化に関係します。knobsコマンドライン・コマンドを使用すると、これらのプロパティを確認できます。
実行時に構成プロパティを編集するための主要ツールは、JMSAdministrator MBeanです。
別の方法として、スタンドアロン環境では、次のようにコマンドライン引数で構成プロパティを渡すことができます。
java -D<propertyname>=<value>
これらのプロパティ設定は、jms.xmlファイルに永続化されます。
JMSAdministratorResource MBeanのJMS構成プロパティ設定へのパス:
「OC4J: ホーム」→「管理」タブ→「タスク名: JMX」→「システムMBeanブラウザ」→「タスクに移動」→「J2EEDomain:oc4j」、「J2EEServer:standalone」、「JMSAdministratorResource」、「JMSAdministrator」にドリルダウン→「操作」タブ→setConfigProperty
表4-6に、OEMS JMSリソース・プロバイダのメモリー内およびファイル・ベースのオプションのシステム・プロパティとその説明を示します。
| JVMシステム・プロパティ | サーバー/クライアント | 説明 |
|---|---|---|
|
JMSクライアント |
JMSコネクションがOC4Jサーバーをpingして、通信例外を例外リスナーにレポートする間隔（ミリ秒単位）。 型はlong、デフォルトは |
|
|
JMSクライアント |
JMSコンシューマが新規メッセージの有無をチェックするまでに待機する最大間隔（ミリ秒単位）。 型はlong、デフォルトは |
|
|
JMSクライアント |
メッセージが配信不可能と宣言されるまでの、リスナーによる配信試行回数。 このプロパティで配信試行回数が制限されるのは、 型はint、デフォルトは |
|
|
OC4Jサーバー |
永続性ファイルのオープン・ファイル記述子の最大数。これは、オペレーティング・システムにより許可されているオープン・ファイル記述子の最大数より多くの永続的な宛先オブジェクトでサーバーを構成する場合に使用します。 型はint、デフォルトは |
|
|
OC4Jサーバー |
すべての宛先オブジェクト（永続的、非永続的および一時的）に存在する期限切れになったすべてのメッセージを例外キューに保存します。 型はboolean、デフォルトは |
|
|
JMSクライアント |
クライアント/サーバー通信にTCP/IPソケットを使用する場合は、ソケットのI/Oストリームに指定されたバッファ・サイズを使用します。最小バッファ・サイズの8KBが規定されます。クライアントとサーバーの間で送信されるメッセージのサイズが大きいほど、バッファ・サイズを大きくすると妥当なパフォーマンスが得られます。 型はint、デフォルトは |
|
|
JMSクライアント |
型はboolean、デフォルトは |
|
|
JMSクライアント |
型はboolean、デフォルトは |
|
|
OC4Jサーバー |
型はboolean、デフォルトは |
|
|
OC4Jサーバー |
JMSサーバーは、メモリー使用率がこの値を超えるとメッセージ本文のページングを開始します。この値は、JVMで使用中のメモリー量の見積です。この値の範囲は、 型はdouble、デフォルトは 詳細は、「メッセージのページング」を参照してください。 |
|
|
|
OC4Jサーバー |
このプロパティは下位互換性のためにのみ使用します。デフォルトでは無効化されています。 XAまたはXA JMS以外の接続をOC4Jグローバル・トランザクションに登録するには、この構成プロパティは設定しないでください。かわりに次のようにします。 JMS APIを使用して、OC4J-JMSのjavax.jms.XA*実装を使用しているOC4Jグローバル・トランザクションにXA接続を明示的に登録します。また、XA JMS以外の接続から作成された、指定のJMSセッションのローカル・トランザクションを明示的にコミットまたはロールバックします。 |
jms.xmlファイルでのJMS構成プロパティの設定
次の例は、jms.xmlファイルで構成プロパティを設定する方法を示しています。
<config-properties>
<config-property name="oc4j.jms.debug" value="true">
</config-property>
</config-properties>
この例は、「jms.xmlを使用した構成」に記載されているjms.xmlの一部です。表4-1「構成要素」にも記載されています。
この項では、変数resourceNameを使用して、リソース・プロバイダ（RP）のJNDIコンテキスト内に存在するRPのリソース（コネクション・ファクトリまたは宛先）のJNDIロケーションを示します。
OEMS JMSリソースのresourceNameは、「宛先オブジェクトおよびコネクション・ファクトリの構成」で説明したとおり、コンソールでJNDIロケーションとして指定します。コネクション・ファクトリのresourceNameの値は、特定のOEMS JMSコネクション・ファクトリを識別するために使用されます（図4-1の矢印番号16のリンク・キーを参照）。宛先のresourceNameの値は、特定のOEMS JMS宛先を識別するために使用されます（図4-1の矢印番号13のリンク・キーを参照）。コネクション・ファクトリおよび宛先のresourceNameの値は、JMSコネクタが省略される場合にも使用されることがあります（「アプリケーション・クライアントのJMSコネクタの省略」を参照）。
OEMS JMSのメモリー内およびファイル・ベースのオプションをアプリケーション・クライアントから直接使用する場合、表4-7「OEMS JMSのメモリー内およびファイル・ベースのルックアップに必要なクライアント・サイドのJARファイル」にリストされたクラスパスに各JARファイルが含まれている必要があります。
表4-7 OEMS JMSのメモリー内およびファイル・ベースのルックアップに必要なクライアント・サイドのJARファイル
| JAR | ORACLE_HOMEパス |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
（ |
|
OEMS JMSのデータベースの永続性オプションは、Oracle Database Streams Advanced Queuing（AQ）機能へのJMSインタフェースです。この項では、AQを永続的なメッセージ・ストアとして使用するOEMS JMSの構成方法と使用方法について詳細に説明します。
OEMS JMSのメモリー内およびファイル・ベースのオプションと同様に、OEMS JMSのデータベースのオプションを通じてAQにアクセスする場合は、アプリケーションでJMSコネクタを使用することをお薦めします。
AQを使用してOEMS JMSを構成する方法の詳細は、『Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイドおよびリファレンス』を参照してください。
この項には、次の項目が含まれます。
|
注意: 以前、Oracle Application Serverのドキュメントや関連資料、および『Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイドおよびリファレンス』では、OEMS JMSのデータベースの永続性オプションのことをOJMSと記載していました。OJMSという頭字語は、OEMS JMSのデータベースの永続性オプションを示しています。 |
OEMS JMSのデータベース・オプションで、リソース・プロバイダの宛先オブジェクト（キューおよびトピック）を作成してアクセスする手順は、次のとおりです。
データベースにOEMS JMSをインストールして構成します。「OEMS JMSのデータベース・オプションのインストールと構成」を参照してください。
データベースで、RDBMSユーザーを作成します。JMSアプリケーションでは、RDBMSユーザーをバックエンド・データベースに接続し、権限を割り当てます。「ユーザーの作成と権限の割当て」を参照してください。
JMS宛先オブジェクトを作成します。「OEMS JMSのデータベース・オプションの宛先オブジェクトの作成」を参照してください。
必要に応じて、データソースまたはLDAPディレクトリ・エントリを作成します。「OEMS JMSのデータベース参照の宣言」を参照してください。
OC4JのXML構成で、バックエンド・データベースの情報を使用して、orion-application.xmlファイルの<resource-provider>要素にOEMS JMSのデータベース・オプションを定義します。
JNDIルックアップを介して実装内のリソースにアクセスします。「JMSメッセージの送受信」を参照してください。
管理者またはDBAは、『Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイドおよびリファレンス』および共通のデータベース・マニュアルに従って、OEMS JMSをインストールする必要があります。OEMS JMSのインストールおよび構成後に、追加の構成を適用します。これには、次が含まれます。
管理者またはDBAは、JMSクライアントからデータベースへの接続に使用するRDBMSユーザーを作成する必要があります。このユーザーに、OEMS JMS操作を実行するための適切なアクセス権限を付与します。OEMS JMSにより、データベース・ユーザーは、適切なアクセス権限があれば任意のスキーマのキューにアクセスできます。「ユーザーの作成と権限の割当て」を参照してください。
管理者またはDBAは、JMS宛先オブジェクトをサポートするための表およびキューを作成する必要があります。「OEMS JMSのデータベース・オプションの宛先オブジェクトの作成」を参照してください。
|
注意: 次の各項では、キュー、トピック、表の作成と、権限の割当てを実行するSQLを使用します。これらの使用例は、 |
JMSクライアントからデータベースへの接続に使用するRDBMSユーザーを作成します。このユーザーに、OEMS JMS操作を実行するためのアクセス権限を付与します。必要な権限は、必要な機能に応じて異なります。各種機能に必要な権限の詳細は、『Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイドおよびリファレンス』を参照してください。
次の例では、jmsuserを作成します。このユーザーは、固有のスキーマ内で作成し、OEMS JMS操作に必要な権限を付与する必要があります。次の文を実行するには、SYS DBAであることが必要です。
DROP USER jmsuser CASCADE ; GRANT connect,resource,AQ_ADMINISTRATOR_ROLE TO jmsuser IDENTIFIED BY jmsuser ; 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; connect jmsuser/jmsuser;
ユーザーの必要に応じて、2フェーズ・コミット権限やシステム管理権限など、他の権限の付与が必要になる場合があります。2フェーズ・コミット権限の詳細は、第3章「OC4Jトランザクション・サポート」を参照してください。
DBMS_AQADMパッケージの詳細と、OEMS JMSのデータベース・オプションのメッセージ・タイプは、『Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイドおよびリファレンス』を参照してください。
次の例では、OEMS JMSのデータベースにキューとトピックを作成します。
OEMS JMSの宛先（キューまたはトピック）を処理する表を作成します。
トピックとキューの両方でキュー表を使用します。次のSQLの例では、キュー用に1つの表（demoTestQTab）を作成します。
DBMS_AQADM.CREATE_QUEUE_TABLE(
Queue_table => 'demoTestQTab',
Queue_payload_type => 'SYS.AQ$_JMS_MESSAGE',
sort_list => 'PRIORITY,ENQ_TIME',
multiple_consumers => false,
compatible => '8.1.5');
multiple_consumersパラメータは、複数のコンシューマが存在するかどうかを指定します。キューの場合、multiple_consumersはfalseに設定します。トピックの場合、multiple_consumersはtrueに設定します。
JMS宛先を作成します。次のSQLの例では、キュー表demoTestQTab内にdemoQueueというキューを作成し、キューを開始します。
DBMS_AQADM.CREATE_QUEUE(
Queue_name => 'demoQueue',
Queue_table => 'demoTestQTab');
DBMS_AQADM.START_QUEUE(
queue_name => 'demoQueue');
例:
次の例では、トピック表demoTestTTab内にdemoTopicというトピックを作成する方法を示します。作成後は、2つの永続サブスクライバがトピックに追加されます。最後に、トピックを開始します。
DBMS_AQADM.CREATE_QUEUE_TABLE(
Queue_table => 'demoTestTTab',
Queue_payload_type => 'SYS.AQ$_JMS_MESSAGE',
multiple_consumers => true,
compatible => '8.1.5');
DBMS_AQADM.CREATE_QUEUE( 'demoTopic', 'demoTestTTab');
DBMS_AQADM.START_QUEUE('demoTopic');
|
注意: OEMS JMSのデータベース・オプションでは、 OEMS JMSの宛先をJMSコネクタの宛先でラップするには、OEMS JMSが提供する宛先のJNDI名と、 |
リソース・プロバイダ参照の宣言の概要は、「リソース・プロバイダ参照の宣言」を参照してください。
リソース・プロバイダ参照を宣言する場合は、常にリソース・プロバイダ参照に使用する名前と、リソース・プロバイダ・インタフェースを実装するJavaクラスを指定する必要があります。
OEMS JMSのデータベース・オプションの場合、クラスはoracle.jms.OjmsContextです。OJMSReferenceという名前のリソース・プロバイダ参照を宣言するには、次のようにします。
<resource-provider class="oracle.jms.OjmsContext" name="OJMSReference"> ... </resource-provider>
たとえば、OEMS JMSの参照の名前がOJMSReferenceで、リソース・プロバイダ・キューのJNDIコンテキスト内のJNDIロケーションがQueues/MY_QUEUEである場合、アプリケーションとリソース・アダプタは、JNDIロケーションjava:comp/resource/OJMSReference/Queues/MY_QUEUEを使用してこのリソース・プロバイダ・キューにアクセスできます。
OEMS JMSの参照を宣言する一般的な手順は、次のとおりです。
最初に、data-sources.xmlファイルにローカル・データソースを作成します。デモ・セットには、この例が含まれます。/ojms/src/META-INF/data-sources.xmlを参照してください。
次に、OC4Jにdata-sources.xmlファイルの配置場所を指示するため、orion-application.xmlに<data-sources>要素を追加します。
<data-sources path="data-sources.xml"/>
data-sourcesのパスは、orion-application.xmlファイルに対する相対パスです。
最後に、リソース・プロバイダ参照にデータソースを設定するため、以前作成した<resource-provider>要素に<property>サブ要素を追加します。
<resource-provider class="oracle.jms.OjmsContext" name="OJMSReference">
<property name="datasource" value="jdbc/xa/MyChannelDemoDataSource"></property>
</resource-provider>
データソースの構成方法の詳細は、このマニュアルの「データソース」を参照してください。使用するドライバ（OCIまたはシン）を選択する場合は、実際のアプリケーション・パフォーマンスを測定するのが最も効果的です。OCIドライバは、非XA操作では一般的に高速ですが、XA操作ではシン・ドライバより大幅に遅くなる可能性があります。
How-Toドキュメントおよびデモ・セットと、そのURLのリストは、「JMSのHow-Toドキュメントおよびデモ・セット」を参照してください。
OEMS JMSのデータベース・オプションのリソースのresourceNameは、次のとおりです。
typeName/instanceName
typeNameおよびinstanceNameの値は、リソースのタイプ（コネクション・ファクトリまたは宛先）に応じて変化します。次に、この詳細を説明します。
OEMS JMSのデータベース・オプションのコネクション・ファクトリの場合:
typeNameは、コネクション・ファクトリ・タイプに応じて次のいずれかになります。
ConnectionFactories
QueueConnectionFactories
TopicConnectionFactories
XAConnectionFactories
XAQueueConnectionFactories
XATopicConnectionFactories
instanceNameには、何を指定してもかまいません（OEMS JMSのデータベース・オプションのコネクション・ファクトリはカスタマイズできず、同じコネクション・ファクトリ・タイプの複数のインスタンスは必要とされないため、この名前は無視されます）。
たとえば、OEMS JMSのデータベース・オプションで、非XAキューのコネクション・ファクトリのresourceNameは次のようになります（無視されるinstanceNameは、任意でmyQCFに設定します）。
QueueConnectionFactories/myQCF
前の手順で作成されたコネクション・ファクトリのresourceNameの値は、OEMS JMSのデータベース・オプションで特定のコネクション・ファクトリを識別するために使用されます（図4-1「JMS構成」の矢印番号16のリンク・キーを参照）。これらの値は、リソース・アダプタが省略される場合にも使用されることがあります（「アプリケーション・クライアントのJMSコネクタの省略」を参照）。
次の表に、実装されるjavax.jms.*インタフェースを示します。
表4-8 実装されるjavax.jms.*インタフェース
| typeName | CF | QCF | TCF | XACF | XAQCF | XATCF |
|---|---|---|---|---|---|---|
|
ConnectionFactories |
○ |
|||||
|
QueueConnectionFactories |
○ |
○ |
||||
|
TopicConnectionFactories |
○ |
○ |
||||
|
XAConnectionFactories |
○ |
○ |
||||
|
XAQueueConnectionFactories |
○ |
○ |
○ |
○ |
||
|
XATopicConnectionFactories |
○ |
○ |
○ |
○ |
アプリケーションで（<res-type>要素の指定どおり）javax.jms.TopicConnectionFactoryを必要とする場合、適切なコネクション・ファクトリを戻すタイプ名は、TopicConnectionFactoriesおよびXATopicConnectionFactoriesのみです。
OEMS JMSのデータベース・オプションの宛先の場合:
typeNameは、宛先タイプに応じて次のいずれかになります。
Queues
Topics
|
注意: 宛先は、DBMS_AQADM.CREATE_QUEUE_TABLEに渡されたmultiple_consumersパラメータがfalseの場合、キュー（typeName = Queues）になります。それ以外の場合、宛先はトピック（typeName = Topics）になります。 |
instanceNameは、宛先の名前（DBMS_AQADM.CREATE_QUEUEに渡されるQueue_Nameパラメータ）です。宛先が<resource-provider>要素のusernameプロパティで指定されたユーザーによって所有されていない場合は、instanceNameにowner接頭辞（ownerは宛先の所有者）を付ける必要があります。（付ける必要がない場合でも、owner接頭辞は許可されます。）
たとえば、OEMS JMSのデータベース・オプションで、DBMS_AQADM.CREATE_QUEUEのコール内で使用されるdemoQueueというキューのresourceNameは、次のとおりです。
Queues/demoQueue
owner（someUserなど）を指定する必要がある場合、resourceNameは次のようになります。
Queues/someUser.demoQueue
前の手順により作成された宛先のresourceNameの値は、OEMS JMSのデータベース・オプションで特定の宛先を識別するために使用されます（図4-1の矢印番号13のリンク・キーを参照）。これらの値は、リソース・アダプタが省略される場合にも使用されることがあります（「アプリケーション・クライアントのJMSコネクタの省略」を参照）。
アプリケーションでは、メッセージの送受信にJMSコネクタを使用することをお薦めします。この方法の場合、使用するリソース・プロバイダとは無関係に送受信コードを記述できます。「JMSメッセージの送受信」に記載されている例は、渡される宛先およびコネクション・ファクトリのロケーションを別にするだけで、OEMS JMSのデータベースを含むすべてのリソース・プロバイダで使用できます。
OEMS JMSのデータベース・オプションをアプリケーション・クライアントから直接使用する場合、表4-9「OEMS JMSのデータベース・オプションのルックアップに必要なクライアント・サイドのJARファイル」にリストされたクラスパスに各JARファイルが含まれている必要があります。
表4-9 OEMS JMSのデータベース・オプションのルックアップに必要なクライアント・サイドのJARファイル
| JAR | ORACLE_HOMEパス |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
（ |
|
この項では、OEMS JMSのデータベース・オプションとOracle Application Serverを組み合せて使用するユーザーにとって一般的な問題について説明します。
OEMS JMSのデータベース・オプションをOracle Application Serverと組み合せて使用する場合に発生する一般的なエラーは、次のとおりです。
PLS-00306 "wrong number or types of arguments"
このメッセージが表示される場合は、Oracle Application Serverで使用されているaqapi.jarファイルに、AQで使用されているOracleデータベースのリリースとの互換性がありません。OEMS JMSのデータベース・オプションの現行リリースでサポートされている旧Oracleデータベースは、9.0.1.4、9.2.0.2以上、10.1.0以上および10.2.0以上です。
Oracle Application ServerおよびOracle Databaseのどちらにも、OEMS JMSクライアントJARファイルが付属しています。よくある間違いは、双方の環境に互換性があると誤解して、Oracleデータベースのインストール環境とOracle Application Serverのインストール環境の間でaqapi.jarファイルをコピーすることです。どちらのインストールからもこのファイルをコピーしないでください。
Oracle Application Serverのインストール環境の場合、OEMS JMSのデータベース・オプションのクライアントJARファイルは、ORACLE_HOME/rdbms/jlib/aqapi.jarです。このファイルは、CLASSPATHに含める必要があります。
データベース永続性モードでメッセージ・セレクタを使用する際に順序が重要な場合には、Javaシステム・プロパティoracle.jms.orderWithSelectorをtrueに設定する必要があります。このプロパティは、デフォルトでfalseに設定されています。このシステム・プロパティを使用するには、AQユーザーにALTER SESSION権限が必要です。また、ORDER BY句に変換されるため、このプロパティをtrueに設定するとパフォーマンスに影響があります。
この項では、サポートされるサード・パーティJMSリソース・プロバイダへの参照を宣言する方法について簡単に説明します。
リソース・プロバイダにXAインタフェースが存在し、JMSコネクタとアプリケーションがそのインタフェースを使用するよう構成されている場合、OC4Jでは、サポートされるすべてのリソース・プロバイダにおいて2フェーズ・コミット（2pc）に対応します。サポートされるすべてのサード・パーティ・プロバイダには、XAインタフェースがあります。
OC4Jでサポートされる各サード・パーティJMSプロバイダのバージョンは、「サード・パーティJMSプロバイダの使用」にリストされています。
この項では、次のサード・パーティJMSプロバイダの参照を宣言する方法について説明します。
コンテキスト・スキャン・リソース・プロバイダ・クラスは、汎用のリソース・プロバイダ・クラスです。このクラスは、サード・パーティのメッセージ・プロバイダで使用するためにOCJに付属しています。
WebSphere MQは、IBM社のメッセージ・プロバイダです。WebSphere MQのリソースは、次のロケーションで使用できます。
java:comp/resource/providerName
ここで、providerNameは、<resource-provider>要素で使用される名前です。
WebSphere MQのリソース・プロバイダ参照を宣言する手順は、次のとおりです。
システムにWebSphere MQをインストールして構成します。次に、ベンダーから提供されている例またはツールを実行してインストールが成功していることを確認します。手順の詳細は、WebSphere MQソフトウェアに付属のドキュメントを参照してください。
WebSphere MQをカスタム・リソース・プロバイダとして追加します。
次の例は、orion-application.xmlファイルの<resource-provider>要素を使用して、WebSphere MQのリソース・プロバイダ参照を宣言する方法を示しています。
<resource-provider
class="com.evermind.server.deployment.ContextScanningResourceProvider"
name="MQSeries">
<description> MQSeries resource provider </description>
<property
name="java.naming.factory.initial"
value="com.sun.jndi.fscontext.RefFSContextFactory">
</property>
<property
name="java.naming.provider.url"
value="file:/home/developer/services_guide_demo/mqseries/src/bindings">
</property>
</resource-provider>
この例は、デモ・セットの環境での構成方法を示しています。この例は、デモ作成者の環境にのみ適用されるため、他の環境で使用する場合は適切に編集する必要があります。
IBM社のドキュメントに従って、WebSphere MQのJMSクライアントに必要なJARファイルをJ2EE_HOME/applibに追加します。
詳細は、デモ・セットのhow-to-gjra-with-mqseries.htmlドキュメントにある「Resource Provider Task #3: Declare a Resource Provider Reference」を参照してください。
How-Toドキュメントおよびデモ・セットと、そのURLのリストは、「JMSのHow-Toドキュメントおよびデモ・セット」を参照してください。
TIBCO Enterprise Message Serviceは、TIBCO Software社のメッセージ・プロバイダです。TIBCOのリソースは、次のロケーションで使用できます。
java:comp/resource/providerName
ここで、providerNameは、<resource-provider>要素で使用される名前です。
TIBCOのリソース・プロバイダ参照を宣言する手順は、次のとおりです。
システムにTIBCO Enterprise Message Serviceをインストールして構成します。次に、ベンダーから提供されている例またはツールを実行してインストールが成功していることを確認します。手順の詳細は、TIBCOソフトウェアに付属のドキュメントを参照してください。
TIBCOをカスタム・リソース・プロバイダとして追加します。次の例は、orion-application.xmlファイルの<resource-provider>要素を使用して、TIBCOのリソース・プロバイダ参照を宣言する方法を示しています。
<resource-provider
class="com.evermind.server.deployment.ContextScanningResourceProvider"
name="TibcoJMSReference">
<property
name="java.naming.factory.initial"
value="com.tibco.tibjms.naming.TibjmsInitialContextFactory">
</property>
<property
name="java.naming.provider.url"
value="tibjmsnaming://jleinawe-sun:7222">
</property>
</resource-provider>
この例は、デモ・セットの環境での構成方法を示しています。この例は、デモ作成者の環境にのみ適用されるため、他の環境で使用する場合は適切に編集する必要があります。
TIBCO社のドキュメントに従って、TIBCOのJMSクライアントに必要なJARファイルをJ2EE_HOME/applibに追加します。
詳細は、デモ・セットのhow-to-gjra-with-tibco.htmlドキュメントにある「Resource Provider Task #3: Declare a Resource Provider Reference」を参照してください。
How-Toドキュメントおよびデモ・セットと、そのURLのリストは、「JMSのHow-Toドキュメントおよびデモ・セット」を参照してください。
SonicMQは、Sonic Software社のメッセージ・プロバイダです。SonicMQのリソースは、次のロケーションで使用できます。
java:comp/resource/providerName
ここで、providerNameは、<resource-provider>要素で使用される名前です。
SonicMQのリソース・プロバイダ参照を宣言する手順は、次のとおりです。
システムにSonicMQをインストールして構成します。次に、ベンダーから提供されている例またはツールを実行してインストールが成功していることを確認します。手順の詳細は、Sonicソフトウェアに付属のドキュメントを参照してください。
SonicMQをカスタム・リソース・プロバイダとして追加します。次の例は、orion-application.xmlファイルの<resource-provider>要素を使用して、SonicMQのリソース・プロバイダ参照を宣言する方法を示しています。
<resource-provider
class="com.evermind.server.deployment.ContextScanningResourceProvider"
name="SonicJMSReference">
<property
name="java.naming.factory.initial"
value="com.sonicsw.jndi.mfcontext.MFContextFactory">
</property>
<property
name="java.naming.provider.url"
value="tcp://stadd41:2506">
</property>
<property
name="com.sonicsw.jndi.mfcontext.domain"
value="Domain1">
</property>
</resource-provider>
この例は、デモ・セットの環境での構成方法を示しています。この例は、デモ作成者の環境にのみ適用されるため、他の環境で使用する場合は適切に編集する必要があります。
Sonic社のドキュメントに従って、SonicMQのJMSクライアントに必要なJARファイルをJ2EE_HOME/applibに追加します。
詳細は、デモ・セットのhow-to-gjra-with-sonic.htmlドキュメントにある「Resource Provider Task #3: Declare a Resource Provider Reference」を参照してください。
How-Toドキュメントおよびデモ・セットと、そのURLのリストは、「JMSのHow-Toドキュメントおよびデモ・セット」を参照してください。
Oracle Application Serverには、JMSコネクタと呼ばれる、J2CA 1.5に準拠したリソース・アダプタがあります。JMSコネクタは、アプリケーションがJMS 1.1または1.02bを実装する任意のJMSプロバイダにアクセスする際に統一されたメカニズムを提供します。OracleASjmsはJMSコネクタのインスタンスで、OEMS JMSのメモリー内およびファイル・ベースのオプションで使用できるように構成されています。JMSコネクタでは、Oracle固有のAPIは使用されていません。サポートされるJMS実装には、OEMS JMSに加え、IBM Websphere MQ JMS、TIBCO Enterprise Message Server、SonicMQ JMSなどのサード・パーティ製品が含まれます。
JMSコネクタは、OC4J実装でJMSを使用する場合に推奨されます。JMSコネクタは、J2CA 1.5標準と、JMS 1.1および1.02b標準に準拠しています。OC4J用の最小限のカスタマイズが含まれますが、個々のJMSプロバイダ用のカスタマイズは含まれません。JMSコネクタは、すべての標準的なJMS実装をシームレスに統合するよう設計されています。
|
注意: JMSプロバイダではカスタムの拡張機能がサポートされることが多いため、一般的にJMSコネクタでは、特定のJMSプロバイダへの最適なアクセスは保証されません。 |
JMSコネクタには、次の機能が含まれます。
JNDIマッピング
MDB統合（変化するメッセージ負荷に応じた動的調整を含む）
グローバル・トランザクション・サポート（トランザクション・リカバリの標準ベースのサポートを含む）。トランザクション・サポートの詳細は、第3章「OC4Jトランザクション・サポート」を参照してください。
|
注意: OEMS JMSは、JMSコネクタを使用しないグローバル・トランザクションでは使用できません。 |
真に汎用的なJMS接続プーリング
容易なデプロイ（順序非依存など）
JMS操作の遅延解決（開始順序非依存、JMSプロバイダの開始と停止などの動的管理の許可、プロバイダ障害時における接続の再試行を含む）
パフォーマンス
JSR-77統計
通常、JMSコネクタは、接続先のEISがJMSリソース・プロバイダである場合に使用します。ただし、JMSコネクタは、EISでJ2EEアプリケーション・コンポーネントへの通知手段としてJMSメッセージ機能を使用する場合にも使用できます。この場合、リソース・アダプタ（およびJMSリソース・プロバイダ）は、EIS固有のリソース・アダプタに存在するインバウンド通信機能のかわりに使用できます。この2面アダプタ・ソリューション（EIS固有のアダプタをアウトバウンド通信に使用し、JMSコネクタをインバウンド通信に使用する方法）により、通常であれば不可能であるEISとJ2EEアプリケーション間の双方向通信が可能になります。
リソース・アダプタの詳細は、『Oracle Containers for J2EEリソース・アダプタ管理者ガイド』を参照してください。
OC4Jに付属のJMSコネクタは、OEMS JMSのメモリー内およびファイル・ベースの永続性オプションをサポートするよう事前に構成されています。OEMS JMSのデータベース・オプション、またはサポートされるOracle以外のJMSプロバイダのいずれかを統合する場合は、JMSコネクタ用に別の構成を作成する必要があります。アプリケーションのローカル・アダプタを使用してOEMS JMSのメモリー内およびファイル・ベースのオプションに接続する場合も、別のJMSコネクタを作成することが可能です。
How-Toドキュメントおよびデモ・セットと、そのURLのリストは、「JMSのHow-Toドキュメントおよびデモ・セット」を参照してください。
新規JMSコネクタ・モジュールを作成および構成する手順は、次のとおりです。
接続先のリソース・プロバイダのデモ・セットに移動します。
How-Toドキュメントを読みます。
新規JMSコネクタ・モジュールのテンプレートとして使用する次のファイルをコピーします。
ra.xml
oc4j-ra.xml
oc4j-connectors.xml
How-Toドキュメントの「Configuring the Resource Adapter」の指示に従って、ra.xml、oc4j-ra.xmlおよびoc4j-connectors.xmlファイルを変更します。
次の構造を使用して、新規.rarファイルを作成します（ファイル名は任意です）。
META-INF/ra.xml
META-INF/oc4j-ra.xml
希望する可視性レベルに応じて、次のいずれかの場所に新規oc4j-connectors.xmlを配置します。
アプリケーション単位のローカルな可視性を確保するには、アプリケーションの.earファイルのトップレベルにあるMETA-INF/ディレクトリに新規oc4j-connectors.xmlファイルを配置します。
グローバルな可視性を確保するには、1つ以上の新規<connector>要素を$J2EE_HOME/config/oc4j-connectors.xmlファイルにコピーします。新規コネクタの名前（<connector>のname属性）が、他のコネクタまたは任意のJNDIオブジェクトの名前と競合していないことを確認してください。
次のように、デプロイの準備を行います。
ローカルな可視性を確保する場合は、次のようにします。
新規.rarファイルを.earファイルに配置します。
次のような<connectors>要素を.earファイルのMETA-INF/orion-application.xmlファイルに挿入します。
<connectors path="oc4j-connectors.xml"/>
次のような<module>要素を.earファイルのMETA-INF/application.xmlファイルに挿入します。
<module>
<connector>rarFileName</connector>
</module>
グローバルな可視性を確保する場合は、『Oracle Containers for J2EEデプロイメント・ガイド』に記載されているコネクタのデプロイ手順に従ってください。
Application Server Controlコンソールは、JMSコネクタを構成するための主要ツールです。
デフォルト・アプリケーションには、デフォルトのJMSコネクタ用に次の宛先オブジェクトが定義されています。
JNDIロケーションOracleASjms/MyQueue1にバインドされたキュー。
JNDIロケーションOracleASjms/MyTopic1にバインドされたトピック。
JNDIロケーションOracleASjms/QueuesにバインドされたキューのJNDIサブコンテキストをラップする自動宛先。
JNDIロケーションOracleASjms/TopicsにバインドされたトピックのJNDIサブコンテキストをラップする自動宛先。
これらの宛先およびJNDIサブコンテキストをラップする自動宛先は、コンソールやJMSAdministrator MBeanで事前に宛先を定義することなくアプリケーションで使用できます。自動宛先ラッピング機能を使用する場合、JNDIルックアップの名前には次の形式を使用します。
<JNDIsubcontext>/providerName
ここで、<JNDIsubcontext>は、oc4j-connectors.xmlファイルで指定されたJNDIサブコンテキストをラップする自動宛先です。たとえば、自動宛先ラッピングをJMSコネクタと組み合せて使用する場合、JNDI名は次の形式になります。
OracleASjms/Queues/jms/<queue_name>
または
OracleASjms/Topics/jms/<topic_name>
JMSコネクタのデフォルトのコネクション・ファクトリは、次のとおりです。
| XA | 非XA | |
|---|---|---|
| デフォルトのキュー・コネクション・ファクトリ | OracleASjms/MyXAQCF |
OracleASjms/MyQCF |
| デフォルトのトピック・コネクション・ファクトリ | OracleASjms/MyXATCF |
OracleASjms/MyTCF |
| デフォルトの統合コネクション・ファクトリ | OracleASjms/MyXACF |
OracleASjms/MyCF |
この表のデフォルト・コネクション・ファクトリは、OC4Jに付属のデフォルトのoc4j-ra.xmlファイルに明示的に宣言されています。
データベースの永続性の宛先
自動宛先ラッピングは、OEMS JMSのデータベース・オプションを使用するためにJMSコネクタをカスタマイズする際にも使用できます。前述のデフォルトのコネクタと同様に、JNDIルックアップの名前には次の形式を使用します。
<JNDIsubcontext>/providerName
ここで、<JNDIsubcontext>は、oc4j-connectors.xmlファイルで指定されたJNDIサブコンテキストをラップする自動宛先で、<providerName>は、接頭辞queueまたはtopicが付く物理データベース宛先です。
たとえば、自動宛先ラッピングを、OracleDB/wrapのJNDIsubcontextとともにデプロイされたOEMSデータベースのJMSコネクタと組み合せて使用する場合、そのデータベースのJNDI名は次の形式になります。
OracleDB/wrap/Queues/<queue_name>
または
OracleDB/wrap/Topics/<topic_name>
JMSコネクタのコネクション・ファクトリおよび宛先の作成
JMSコネクタのコネクション・ファクトリおよび宛先を構成する方法（oc4j-connectors.xml、oc4j-ra.xmlおよびra.xmlファイルの例を含む）は、http://www.oracle.com/technology/tech/java/oc4j/1013/how_to/index.htmlを参照してください。
関連するhow-to-gjra-with-xxx.zipファイル（xxxはリソース・プロバイダの名前）をダウンロードして解凍します。関連するHow-Toドキュメントの「Configuring the Resource Adapter」を参照してください。
JMSコネクタのXMLファイルのリファレンス情報は、『Oracle Containers for J2EEリソース・アダプタ管理者ガイド』の付録A「OC4Jリソース・アダプタ構成ファイル」を参照してください。
表4-10に、JMSコネクタの構成設定とその説明を示します。
Application Server ControlコンソールのJMSコネクタ設定へのパス:
「OC4J: ホーム」→「アプリケーション」タブ→「ビュー: スタンドアロン・リソース・アダプタ」→「OracleAS JMS」
表4-10 JMSコネクタの構成設定
| コンソール設定 | XML永続性ファイル | 説明 |
|---|---|---|
|
「OC4J: ホーム」→「アプリケーション」タブ→「ビュー: スタンドアロン・リソース・アダプタ」→「OracleAS JMS」→「コネクション・ファクトリ」タブ→「作成」ボタン コネクション・ファクトリ・インタフェース 図4-1の矢印番号14のリンク参照。 |
この設定は、 |
コネクション・ファクトリ・インタフェース設定では、作成するコネクション・ファクトリのタイプを定義します。 |
|
JNDIロケーション 図4-1の矢印番号5のリンク・キー。 |
この設定は、 |
JNDIロケーション設定では、リソース・アダプタの新規コネクション・ファクトリをバインドするJNDIロケーションを指定します。EISに接続するアプリケーション・コンポーネントがコネクション・ファクトリを特定できるように、有効なJNDIロケーションを入力します。 このJNDIロケーションは、jndiLocationとは異なることに注意してください。 |
|
接続プーリング |
この設定は、 |
接続プーリングにより、EISへの一連の接続をアプリケーション内で再利用できます。アプリケーションでは、独自の排他的接続プールを作成するか、このリソース・アダプタで使用可能ないずれかの共有接続プールを使用するかを選択できます。
|
|
jndiLocation 図4-1の矢印番号16のリンク参照。 |
この設定は、 |
このjndiLocationは、JNDIロケーションとは異なることに注意してください。 |
|
|
この設定は、 |
|
|
「OC4J: ホーム」→「アプリケーション」タブ→「ビュー: スタンドアロン・リソース・アダプタ」→「OracleAS JMS」→「管理対象オブジェクト」タブ→「作成」ボタン オブジェクト・クラス |
この設定は、 |
|
|
JNDIロケーション 図4-1の矢印番号7および11のリンク・キー。 |
この設定は、 |
|
|
jndiName 図4-1の矢印番号13のリンク参照。 |
この設定は、 |
注意: この |
|
resourceProviderName 図4-1の矢印番号12のリンク参照。 |
この設定は、 |
|
|
「ResourceAdapter」→「管理」→「enableDMS」 |
この設定は、 また、この設定は、
|
このプロパティは、JMSリソース・アダプタによりDMSパフォーマンス・メトリックが収集されるかどうかを指定します。このプロパティは、デフォルトで |
|
「ResourceAdapter」→「管理」→「loggerName」 |
この設定は、 また、この設定は、
|
このプロパティは、JMSリソース・アダプタのロギングを処理するログ出力の名前を指定します。ログ出力は |
JMSコネクタの構成設定は、次のファイルで永続化されます。
oc4j-connectors.xml: oc4j-connectors.xmlファイルは、JMSコネクタ・インスタンスとJMSコネクタの宛先を作成する際に使用されます。
oc4j-ra.xml: oc4j-ra.xmlファイルには、JMSコネクタのOC4J固有の構成が含まれます。Application Server Controlコンソールを使用してJMSコネクタのコネクション・ファクトリを作成または編集すると、OC4Jによってoc4j-ra.xmlファイルが更新されます。
ra.xml: オラクル社が提供する標準のJMSコネクタ・モジュール構成ファイルです。JMSコネクタを構成する場合、ra.xmlのエントリは、通常、デフォルトとして機能します。
oc4j-connectors.xml、oc4j-ra.xmlおよびra.xmlファイルの具体的な使用例は、http://www.oracle.com/technology/tech/java/oc4j/1013/how_to/index.htmlを参照してください。
JMSコネクタのXMLファイルのリファレンス情報は、『Oracle Containers for J2EEリソース・アダプタ管理者ガイド』の付録A「OC4Jリソース・アダプタ構成ファイル」を参照してください。
|
注意: XMLファイルで直接変更した構成を有効化するには、OC4Jインスタンスを再起動する必要があります。 |
OC4Jでは、JMSコネクタを使用してメッセージ・プロバイダをプラグインするMDBをサポートしています。このプロバイダには、OEMS JMSやサポートされているサード・パーティのメッセージ・プロバイダが含まれます。これにより、JMS接続プーリングや、変化する負荷に応じてサイズ変更（動的負荷調整）を行うMDBリスナー・スレッド・セットなど、各種の有益な機能が提供されます。
MDBの使用方法の詳細な例は、http://www.oracle.com/technology/tech/java/oc4j/1013/how_to/index.htmlのメッセージングのデモに含まれます。
How-Toの.zipファイルのいずれかをダウンロードして解凍します。MDBの構成例は、/src/ejb/META-INF/ejb-jar.xmlおよび/src/ejb/META-INF/orion-ejb-jar.xmlファイルで確認できます。
接続プーリング
JMSコネクタでは、J2CAの接続プーリングが使用されます。接続プーリングの詳細は、『Oracle Containers for J2EEリソース・アダプタ管理者ガイド』を参照してください。
各MDBエンドポイントは、一連の構成プロパティ（ActivationSpecプロパティと呼ばれる）と関連付けられています。このプロパティは、JMSコネクタによりメッセージ・エンドポイントがアクティブ化され、メッセージ・エンドポイントがメッセージドリブンBeanと関連付けられる際に使用されます。このプロパティは、特にパフォーマンス、ロギング、例外キュー、メッセージ承認およびサブスクリプションの操作に使用されます。
通常、このプロパティはorion-ejb-jar.xmlに設定されています。ただし、JMSコネクタがアプリケーションの.earファイルに含まれる場合には、ejb-jar.xmlファイルでもこのプロパティを設定できます。各ファイルでの構文は異なります。
orion-ejb-jar.xmlを使用する場合、プロパティは次の構文を使用して、各<message-driven-deployment>ノードに追加されます。
<config-property> <config-property-name>ExamplePropertyName</config-property-name> <config-property-value>ExampleValue</config-property-value> </config-property>
ejb-jar.xmlファイルを使用する場合、プロパティは次の構文を使用して、各<message-driven>ノードに追加されます。
<activation-config-property> <activation-config-property-name>ExamplePropertyName </activation-config-property-name> <activation-config-property-value>ExampleValue </activation-config-property-value> </activation-config-property>
次の表に、MDBエンドポイントの微調整に使用可能な構成プロパティを説明します。
表4-11 MDBの構成プロパティ
| 構成プロパティ | 説明 |
|---|---|
|
|
（整数でデフォルトは エンドポイントに作成するリスナー・スレッドの最大数を設定します。キューでは、メッセージを使用できる割合を増加する際には、複数のスレッドを使用すると便利です。トピックでは、この値は常に |
|
|
（ミリ秒でデフォルトは リスナー・スレッドによるポーリングで、処理を待機しているメッセージの有無が確認されます。ポーリングを頻繁に実行すると、指定したリスナー・スレッドが（平均では）より迅速に新しいメッセージに対応できます。リソース・プロバイダは、ポーリングが行われるたびに受信リクエストを処理する必要があるため、ポーリングを頻繁に実行するとオーバーヘッドが発生します。 オラクル社のJMSコネクタ実装では、（アクティビティが認識されると）アクティビティの期間中はポーリング間隔が短く（ポーリング率が高く）なり、非アクティブの期間中はポーリング間隔が長く（ポーリング率が低く）なる、調整可能なアルゴリズムが適用されます。 |
|
|
（ミリ秒でデフォルトは メッセージを受信していないリスナー・スレッドが保持される期間を表します。（エンドポイントがアクティブなかぎり、少なくとも1つのリスナー・スレッドが残ります。） |
|
|
（ミリ秒でデフォルトは リスナー・スレッドがメッセージを受信した際に、（新しいメッセージの到着を待機する必要があったため） |
|
|
（整数でデフォルトは メッセージにJMSXDeliveryCountプロパティがあり、そのプロパティの値が |
|
|
（ミリ秒でデフォルトは JMSプロバイダに障害が発生すると、リスナー・スレッドは自動的に終了します。（たとえば、リスナー・スレッドが
|
|
|
（文字列でデフォルトはなし） 設定すると、リスナー・スレッドにより使用される接続は、このクライアントIDを使用するように設定されます。 |
|
|
（文字列でデフォルトは これらのプロパティを使用すると、ユーザー/パスワードをリソース・プロバイダに渡すことができます。これらのプロパティのどちらも設定されていない場合、MDBのインバウンド・メッセージの処理（および有効化されている場合は例外キューの処理）に使用される接続は、引数のないcreate*Connectionメソッドを使用して作成されます。これらのプロパティのいずれかまたは両方が設定されている場合は、ユーザー/パスワード引数としてcreate*Connectionメソッドに渡されます。（設定されていないプロパティが1つのみの場合は、create*Connectionのその特定の引数にはNULLが使用されます。）ResPasswordプロパティでは、標準のパスワードの間接化オプションがサポートされています（たとえば、->joeuserでjoeuserのパスワードを表すことができます）。 |
|
|
（文字列でデフォルトは
|
|
|
（文字列でデフォルトのメッセージのフィルタ処理はなし） MDBの |
|
|
（文字列でデフォルトは トピックの場合は、 |
|
|
（文字列でデフォルトはなし） このプロパティは、 |
|
|
（ミリ秒でデフォルトは 現行のトランザクションを終了するまでにJMSコネクタがメッセージの到着を待機する期間を制限します。トランザクション・マネージャにより、トランザクションが存在できる期間が制限されます（ |
|
|
（ブールでデフォルトは
前の手順のその他の実行方法は、
第1の宛先として使用されるだけでなく、 |
|
|
（文字列でデフォルトはなし） 例外キューとして使用する |
|
|
（ブールでデフォルトは 例外キューに送信されたメッセージにメッセージ本文を含めるかどうかを制御します。（例外キューの使用の詳細は、
|
|
|
（文字列でデフォルトはなし） JMSコネクタで記録するメッセージの詳細レベルを制御します。これらのメッセージは主にJMSコネクタ自体のデバッグを目的としていますが、JMSコネクタの使用に関する問題のデバッグにも便利です。本番コードでは、このプロパティは設定しないでください。（デバッグ目的で一時的にのみ設定してください。JMSコネクタの今後のリリースで特定のログ・メッセージおよびログ・レベルが追加/削除/変更されます。）使用可能な値は次のとおりです。
|
動的負荷調整
リスナー・スレッドの動的負荷調整は、次の<activation-config>プロパティに基づきます。表4-11「MDBの構成プロパティ」で説明されています。
ListenerThreadMaxIdleDuration
ListenerThreadMinBusyDuration
ReceiverThreads
MDBインスタンスの動的負荷調整を含むMDB構成の詳細は、『Oracle Containers for J2EE Enterprise JavaBeans開発者ガイド』を参照してください。
この項では、クライアント・アプリケーションで論理名を使用する方法について説明します。これにより、OC4Jに固有ではないデプロイメント・ディスクリプタに含まれるインストール環境固有のJMS構成に依存する設定の数を減らすことができます。この間接化により、クライアント実装を任意のJMS構成に対して汎用的にすると同時に、特定のJMSリソース・プロバイダから分離することができます。
論理名を使用すると、リソース・プロバイダに依存しないクライアント・アプリケーション・コードを作成できます。論理名を構成および使用する一般的な手順は、次のとおりです。
クライアント・アプリケーション・コードで、JMSの宛先およびコネクション・ファクトリの論理名を使用します。
J2EEアプリケーション・コンポーネント・デプロイメント・ディスクリプタ（application-client.xmlやejb-jar.xmlなど）で論理名を宣言します。
OC4J固有のアプリケーション・コンポーネント・デプロイメント・ディスクリプタ（orion-application-client.xmlやorion-ejb-jar.xmlなど）の明示的なJNDIロケーションに論理名をマップします。
論理名を構成して使用する方法は、http://www.oracle.com/technology/tech/java/oc4j/1013/how_to/index.htmlのHow-Toドキュメントと.javaおよび.xmlファイルを参照してください。
how-to-gjra-with-xxx.zipファイルのいずれか（xxxはリソース・プロバイダの名前）をダウンロードして解凍します。
この項には、次の項目が含まれます。
クライアントでは、JMSの宛先とコネクション・ファクトリを使用してメッセージを送受信します。クライアントでJMSの宛先オブジェクトまたはコネクション・ファクトリを取得する場合は、論理名（環境エントリ）を使用することをお薦めします。一般的に、論理名を適用できない場合を除き、JNDIロケーションを直接使用することは避けてください。または、アプリケーションの移植性を確保するために、その他のメカニズムを使用します。
アプリケーション・コードで論理名を使用するには、アプリケーションをデプロイする前に、次のいずれかのXMLデプロイメント・ファイルに論理名を宣言する必要があります。
スタンドアロンJavaクライアントの場合: application-client.xmlファイル
EJBの場合: ejb-jar.xmlファイル
JSPまたはサーブレットの場合: web.xmlファイル
詳細は、http://www.oracle.com/technology/tech/java/oc4j/1013/how_to/index.htmlのHow-Toドキュメントを参照してください。「Developing the Application Components」のタスク番号2「Declare Logical Names for JMS Resources」を参照してください。
コネクション・ファクトリおよび宛先の論理名を宣言する手順は、次のとおりです。
コネクション・ファクトリの論理名を<resource-ref>要素を使用して宣言します。
コネクション・ファクトリの論理名を<res-ref-name>要素に指定します。図4-1の矢印番号1および6のリンク・キー。
コネクション・ファクトリのクラス・タイプを、次のいずれかを使用して<res-type>要素に指定します。
javax.jms.ConnectionFactory
javax.jms.QueueConnectionFactory
javax.jms.TopicConnectionFactory
認証方式（ContainerまたはApplication）を<res-auth>要素に指定します。
共有範囲（ShareableまたはUnshareable）を<res-sharing-scope>要素に指定します。
JMS宛先の論理名を<message-destination-ref>要素を使用して宣言します。
宛先の論理名を<message-destination-ref-name>要素に指定します。図4-1の矢印番号2および8のリンク・キー。
宛先タイプを、javax.jms.Queueまたはjavax.jms.Topicのいずれかを使用して<message-destination-ref-type>要素に指定します。
クライアントでこの宛先へのメッセージを生成するか、この宛先からのメッセージを使用するか、またはその両方を行うかを、Produces、Consumes、ConsumesProducesのいずれかを使用して<message-destination-usage>要素に指定します。
例
次の例では、キューの論理名を指定する方法を示します。この例では、jms/PlayerConnectionFactoryがコネクション・ファクトリの論理名であり、jms/PlayerCommandDestinationが宛先キューの論理名です。この例は、デモ・セットのapplication-client.xmlファイルからの抜粋です。
<resource-ref> <res-ref-name>jms/PlayerConnectionFactory</res-ref-name> <res-type>javax.jms.ConnectionFactory</res-type> <res-auth>Application</res-auth> </resource-ref> <message-destination-ref> <message-destination-ref-name>jms/PlayerCommandDest</message-destination-ref-name> <message-destination-type>javax.jms.Queue</message-destination-type> <message-destination-usage>Produces</message-destination-usage> </message-destination-ref>
論理名を指定する方法の説明コメント付きの詳細な例は、http://www.oracle.com/technology/tech/java/oc4j/1013/how_to/index.htmlのデモに含まれます。
/src/client/META-INF/application-client.xml
および
/src/ejb/META-INF/ejb-jar.xmlというファイルを見つけてください。
How-Toドキュメントおよびデモ・セットと、そのURLのリストは、「JMSのHow-Toドキュメントおよびデモ・セット」を参照してください。
作成した論理名は、リソースのJNDIロケーションにマップする必要があります。通常は、デプロイヤがこれらを設定します。このマッピングは、次のいずれかのOC4Jデプロイメント・ディスクリプタ・ファイルで定義します。
スタンドアロンJavaクライアントの場合、そのクライアントのorion-application-client.xmlファイルに定義します。
EJBの場合、そのEJBのorion-ejb-jar.xmlファイルに定義します。
JSPまたはサーブレットの場合、そのJSPまたはサーブレットのorion-web.xmlファイルに定義します。
アプリケーション・コンポーネントのデプロイメント・ディスクリプタで論理名をマップする手順は、次のとおりです。
コネクション・ファクトリの場合、<resource-ref>要素に宣言されている論理名を、<resource-ref-mapping>要素を使用してJNDIロケーションにマップします。これは、図4-1の矢印番号6および5で示されます。
宛先の場合、<message-destination-ref>要素を使用して宣言されている論理名を、<message-destination-ref-mapping>要素を使用してJNDIロケーションにマップします。これは、図4-1の矢印番号8および7で示されます。
OEMS JMSの3つのサービス品質オプションにおけるマッピングと、アプリケーション・コンポーネントでこのネーミング規則を使用する方法の詳細は、次の項を参照してください。
OC4Jスタンドアロン環境では、Javaアプリケーション・クライアントは、jndi.propertiesファイルの次のプロパティ定義に基づいてOEMS JMSの宛先オブジェクトにアクセスします。
java.naming.factory.initial= com.evermind.server.ApplicationClientInitialContextFactory java.naming.provider.url=ormi://myhost/myApplicationDeploymentName java.naming.security.principal=oc4jadmin java.naming.security.credentials=welcome
ポートを指定する場合は、オプションの:port要素を次のように使用します。
java.naming.provider.url=ormi://myhost:port/myApplicationDeploymentName
デフォルトのRMIポートは、23791です。
次の操作が必要です。
ApplicationClientInitialContextFactoryを初期コンテキスト・ファクトリ・オブジェクトとして使用します。
スタンドアロンOC4Jのホストとポート、およびアプリケーション・デプロイ名をプロバイダURLに指定します。
Oracle Application Server環境では、Javaアプリケーション・クライアントは、jndi.propertiesファイルの次のプロパティ定義に基づいてOEMS JMSの宛先オブジェクトにアクセスします。
java.naming.factory.initial= com.evermind.server.ApplicationClientInitialContextFactory java.naming.provider.url=opmn:ormi://$HOST:$OPMN_REQUEST_PORT:$OC4J_INSTANCE/myApplicationDeploymentName java.naming.security.principal=oc4jadmin java.naming.security.credentials=welcome
ApplicationClientInitialContextFactoryを初期コンテキスト・ファクトリ・オブジェクトとして使用します。
OPMNのホストとポート、OC4Jインスタンスおよびアプリケーション・デプロイ名をプロバイダURLに指定します。
jndi.propertiesファイルの詳細な例は、http://www.oracle.com/technology/tech/java/oc4j/1013/how_to/index.htmlを参照してください。
次のファイルを見つけてください。
/src/client/jndi.properties
リソースを定義してJNDIプロパティを構成した後、クライアントでは、次の手順に従ってJMSメッセージを送信する必要があります。この手順は、「JMSメッセージの送受信」に記載されている手順を要約したものです。
JNDIルックアップを使用して、構成済のJMS宛先とそのコネクション・ファクトリを取得します。
コネクション・ファクトリから接続を作成します。
接続を使用してセッションを作成します。
取得済のJMS宛先を指定して、メッセージ・プロデューサを作成します。
メッセージを作成します。
メッセージ・プロデューサを使用してメッセージを送信します。
接続をクローズします。
JMSコネクタをアプリケーション・クライアントから使用する場合、表4-12「JMSコネクタのルックアップに必要なクライアント・サイドのJARファイル」にリストされたクラスパスに各JARファイルが含まれている必要があります。
表4-12 JMSコネクタのルックアップに必要なクライアント・サイドのJARファイル
| JAR | ORACLE_HOMEパス |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
可用性の高いJMSサーバーは、JMS要求がソフトウェアまたはハードウェア障害による中断なしで処理されるという保証を提供します。高可用性を実現する方法の1つはフェイルオーバー機能を使用することです。サーバー・インスタンスの1つに障害が発生すると、ソフトウェア、ハードウェアおよびインフラストラクチャ・メカニズムの組合せにより、別のサーバー・インスタンスが要求の処理を引き継ぎます。
高可用性の詳細は、『Oracle Application Server高可用性ガイド』を参照してください。
表4-13「高可用性の概要」に、OEMS JMSでの高可用性のサポートを示します。
| 機能 | データベース | メモリー内およびファイル・ベース |
|---|---|---|
|
高可用性 |
RAC + OPMN |
OPMN |
|
構成 |
RAC構成、リソース・プロバイダ構成 |
専用JMSサーバー、 |
|
メッセージ・ストア |
RACデータベース上 |
専用JMSサーバー/永続性ファイル内 |
|
フェイルオーバー |
同一または異なるマシン（RACによる） |
Oracle Application Server Cold Failover Cluster（中間層）内の同一または異なるマシン |
OEMS JMSのクラスタリング環境にデプロイされたJMSアプリケーションは、複数のOC4Jインスタンスまたはプロセス間でJMSリクエストのロード・バランシングを実行できます。ステートレス・アプリケーションのクラスタリングは一般的に行われます。アプリケーションは複数のサーバーにデプロイされ、ユーザー・リクエストはそのうちの1つにルーティングされます。
JMSは、ステートフルAPIです。JMSクライアントとJMSサーバーの両方に、相互の状態（接続、セッション、永続サブスクリプションに関する情報など）が保持されます。ユーザーは、その環境を構成し、クラスタ対応アプリケーションを記述するときに少数の単純なテクニックを使用できます。
次の項では、OEMS JMSで高可用性とクラスタリングを実現する方法について説明します。
OEMS JMSのクラスタリングでは、通常、この種の環境にデプロイされたアプリケーションが、複数のOC4Jインスタンス間でメッセージのロード・バランシングを実行できます。また、この環境では、コンテナ・プロセスを複数のノード間で分散できるため、ある程度の高可用性が実現します。いずれかのプロセスまたはノードが停止した場合は、代替ノード上のプロセスがメッセージの処理を続行します。
この項には、OEMS JMSのクラスタリングに関する次の項目が含まれます。
この構成では、すべてのファクトリと宛先がすべてのOC4Jインスタンス上で定義されます。各OC4Jインスタンスには、それぞれの宛先の個別コピーがあります。
この構成は、OC4Jインスタンス間でリクエストのロード・バランシングを必要とする高スループットのアプリケーションに適しています。この使用例の場合、構成変更は不要です。
この構成は2ノード・クラスタです。常にアクティブなノードは1つのみです。2つ目のノードは、1つ目のノードに障害が発生した場合にアクティブになります。
この構成では、1つのOC4Jインスタンス内の1つのJVMが専用JMSサーバーとなります。JMSクライアントをホスティングする他のすべてのOC4Jインスタンスは、JMS要求を専用JMSサーバーに転送します。
この構成は、メンテナンスとトラブルシューティングが最も容易であり、大多数のJMSアプリケーション、特にメッセージの順序付けを必要とするアプリケーションに適しています。
この項では、カスタム・トポロジを使用する理由について説明し、様々なトポロジ・オプションの要件とその効果をリストします。また、カスタム・トポロジの作成方法について説明します。
カスタム・トポロジは、本質的に、正しく理解して使用することが通常より難しく、構成の手間もかかります。カスタム・トポロジは、標準の構成が適切でない場合にのみ使用してください。
ここで説明する用語の詳細は、『Oracle Application Server高可用性ガイド』および『Oracle Process Manager and Notification Server管理者ガイド』を参照してください。
OHS: Oracle HTTP Server
OracleASクラスタ: 同じように構成されたOracle Application Serverインスタンスのグループ
Oracle Application Serverインスタンス: Oracle Application Serverのインストール環境を表します（つまり、ORACLE_HOME）。
OC4Jインスタンス: 1つのOracle Application Serverインスタンス内に、複数のOC4Jインスタンスが存在する場合があります。
ファクトリ: JMSコネクション・ファクトリを示します。
宛先: JMS宛先を示します。
この構成では、OHSは、HTTPリクエストを処理し、Oracle Application Serverクラスタ内の2つ以上のOracle Application Serverインスタンス間でリクエストのロード・バランシングを実行します。
宛先のコピーはそれぞれ一意で、OC4Jインスタンス間ではレプリケートまたは同期化されません。宛先は、永続的でもメモリー内でもかまいません。1つのOC4Jインスタンスにエンキューされたメッセージは、そのOC4Jインスタンスからでなければデキューできません。
この種のデプロイメントには、次のような多数のメリットがあります。
アプリケーションとJMSサーバーの両方が同じJVM内で実行され、プロセス間通信が不要であるため、高スループットが実現します。
ロード・バランシングにより、高スループットと高可用性が促進されます。
シングル・ポイント障害が発生しません。OC4Jプロセスが1つでも使用可能であれば、リクエストを処理できます。
JMS操作に影響を与えずにOracle Application Serverインスタンスをクラスタリングできます。
宛先オブジェクトは、メモリー内またはファイル・ベースのいずれでもかまいません。
分散宛先クラスタの構成
各Oracle Application Serverインスタンス内に、2つのOC4Jインスタンスが定義されています。これらのOC4Jインスタンスでは、それぞれ別のアプリケーションが実行されます。つまり、OC4Jインスタンス#1（Home1）はアプリケーション#1を実行し、OC4Jインスタンス#2（Home2）はアプリケーション#2を実行します。各OC4Jインスタンスは複数のJVMを実行するよう構成できるため、アプリケーションは複数のJVM間でスケーラビリティを持つことができます。
Oracle Application Serverクラスタ内では、各Oracle Application Serverインスタンスの構成情報は（ホスト名やポート番号など、インスタンス固有の情報を除いて）同一です。つまり、Oracle Application Serverインスタンス#1のOC4Jインスタンス#1にデプロイされたアプリケーション#1は、Oracle Application Serverインスタンス#2のOC4Jインスタンス#1にもデプロイされます。このタイプのアーキテクチャでは、複数のOracle Application Serverインスタンス間でメッセージのロード・バランシングを実行できます。特に、ハードウェア障害への対策としてOracle Application Serverインスタンス#2が別のノードにデプロイされている場合、JMSアプリケーションの高可用性が実現します。
各アプリケーションのセンダーとレシーバは、1つのOC4Jインスタンスにともにデプロイする必要があります。つまり、あるOC4JプロセスでJMSサーバーにエンキューされたメッセージは、そのOC4Jプロセスからでなければデキューできません。
すべてのファクトリと宛先は、すべてのOC4Jプロセス上で定義されます。各OC4Jプロセスには、それぞれの宛先の個別コピーがあります。宛先のコピーは、レプリケートまたは同期化されません。そのため、この図では、アプリケーション#1はmyQueue1という宛先に書込みを行います。この宛先は、2つの場所（Oracle Application Serverインスタンス#1および#2）に物理的に存在し、各OC4Jインスタンス内でそれぞれのJMSサーバーにより管理されます。
この種のJMSデプロイメントは、特定のタイプのJMSアプリケーションにのみ適していることに注意してください。メッセージの順序が重要でない場合、メッセージは同じ名前を持つ分散キューにエンキューされます。JMSのPoint-to-Pointメッセージングのセマンティクスでは、メッセージは複数のキュー間で複製できません。前述の例では、メッセージはロード・バランシング・アルゴリズムにより決定されたキューに送信され、着信時にMDBによりデキューされます。
この構成は2ノード・クラスタです。常にアクティブなノードは1つのみです。2つ目のノードは、1つ目のノードに障害が発生した場合にアクティブになります。より大規模なクラスタでは、次の項で説明する専用JMSサーバー構成とCold Failover Clusterを組み合せて使用できます。この場合、2つのノードを専用JMSサーバーとして構成し、任意の時点で1つのノードのみがアクティブになるよう設定します。コールド・フェイルオーバーの詳細は、『Oracle Application Server高可用性ガイド』を参照してください。
Cold Failover Clusterの構成
次の例に示すように、両方のノードを同じ構成にします。両方のOC4Jインスタンスのjms.xmlファイルを変更します。jms-serverのhostパラメータを次のように設定します。
<jms-server host=vmt.my.company.com port="9127"> …. …. </jms-server>
ファイル・ベースのメッセージの永続性をキューに使用する場合、両方のノードからアクセスできる共有ディスク上にファイルを置く必要があります。共有ディスクは、一方のノードから他方のノードにフェイルオーバーする際に、仮想IPを使用する必要があります。次のようにpersistence-fileを構成します。
<queue name="Demo Queue" location="jms/demoQueue" persistence-file="/path/to/shared_file_system/demoQueueFile">
<description>A dummy queue</description>
</queue>
停止と起動
各ノードでは、次のコマンドを使用して停止と起動を行います。
$ORACLE_HOME/opmn/bin/opmnctl stopall $ORACLE_HOME/opmn/bin/opmnctl startall
この構成では、Oracle Application Serverクラスタ環境で1つのOC4Jインスタンスが専用JMSサーバーとして構成されます。このOC4Jインスタンスはすべてのメッセージを処理するため、常にメッセージの順序付けが維持されます。すべてのJMSアプリケーションは、この専用サーバーを使用してコネクション・ファクトリと宛先をホスティングし、エンキューおよびデキューのリクエストを処理します。
専用JMSプロバイダとして機能するOC4J JVMは、クラスタ内のすべてのJMSアプリケーションに対して1つのみです。そのために、opmn.xmlファイル内のJMSポート範囲は専用OC4Jインスタンス用の1つのポートのみに制限されます。
次の図は、OC4JのHomeインスタンス内のアクティブなJMSサーバーを示していますが、JMSプロバイダは独自のOC4Jインスタンス内でホスティングすることをお薦めします。たとえば、HomeはOracle Application Serverのインストール後に実行されるデフォルトのOC4Jインスタンスですが、Oracle Enterprise Manager 10g Application Server Controlコンソールを使用して2つ目のOC4Jインスタンスを作成する必要があります。後述のopmn.xmlファイルの例では、JMSserverというOC4Jインスタンスを作成しています。
OC4JインスタンスJMSserverを作成した後、このOracle Application Serverインスタンスについてopmn.xmlファイルに次の2つの変更を加える必要があります。
このOC4Jインスタンス（JMSserver）用に起動されるJVMが1つのみであることを確認します。
OC4Jインスタンス内のJVMを1つに限定することで、他のJVMが同じ永続性ファイル・セットを使用しないことが保証されます。
このインスタンスのJMSポート範囲の値を1つのみ指定します。
ポート値を1つにすると、OPMNでは、常にこの値が専用JMSサーバーに割り当てられます。このポート値を使用して、jms.xmlファイル内でコネクション・ファクトリを定義できます。他のOC4Jインスタンスは、これを専用JMSサーバーへの接続に使用します。
OPMNと動的ポート割当ての詳細は、『Oracle Process Manager and Notification Server管理者ガイド』を参照してください。
次のXMLは、opmn.xmlファイルからの抜粋であり、必要な変更内容と変更する場所を示しています。
Application Server Controlコンソールを使用して、JMSserverと呼ばれるOC4Jインスタンスが作成されたと仮定すると、(1)で示されている行は、JMSserver定義の開始位置を示しています。
(2)で示されている行は、OC4J JVMにJMSポートを割り当てるときにOPMNで使用されるJMSポート範囲です。JMSプロバイダとして機能させる必要のある専用OC4Jインスタンスについて、この範囲を1つの値に限定します。この例では、元の範囲は3701-3800でした。今回のコネクション・ファクトリ定義では、この値を3701-3701に構成してポートを使用します。
|
注意: 専用JMSサーバーに割り当てられたポートは、このホストのその他のアプリケーションで使用されないようにしておく必要があります。また、このポートはこのホストを共有するすべてのOC4Jインスタンスに対する、全OC4Jコンポーネントのポート範囲から除外する必要があります。 |
(3)で示されている行は、JMSserverのデフォルト・グループに含まれるJVM数の定義です。この値は、デフォルトで1に設定されています。この値は、常に1である必要があります。
<ias-component id="OC4J">
(1) <process-type id="JMSserver" module-id="OC4J" status="enabled">
<module-data>
<category id="start-parameters">
<data id="java-options" value="-server
-Djava.security.policy=$ORACLE_HOME/j2ee/home/config/java2.policy
-Djava.awt.headless=true
"/>
</category>
<category id="stop-parameters">
<data id="java-options"
value="-Djava.security.policy=
$ORACLE_HOME/j2ee/home/config/java2.policy
-Djava.awt.headless=true"/>
</category>
</module-data>
<start timeout="600" retry="2"/>
<stop timeout="120"/>
<restart timeout="720" retry="2"/>
<port id="ajp" range="3000-3100"/>
<port id="rmi" range="3201-3300"/>
(2) <port id="jms" range="3701-3701"/>
(3) <process-set id="default_group" numprocs="1"/>
</process-type>
</ias-component>
この使用例で前述したように、OC4Jインスタンスの1つはJMSサーバー専用です。他のOC4JインスタンスおよびOC4J外部で実行されるスタンドアロンJMSクライアントは、JMS要求を専用JMSサーバーに転送するように設定する必要があります。すべてのコネクション・ファクトリと宛先は、JMSサーバー・インスタンスのjms.xmlファイル内で定義されます。このjms.xmlファイルを、JMSサーバーと通信する他のすべてのOC4Jインスタンスにコピーする必要があります。
専用JMSサーバー上のjms.xmlファイル内で構成するコネクション・ファクトリでは、サーバーのホスト名とポート番号を明示的に指定する必要があります。jms.xmlのホスト名とポート番号は、前述のとおり専用サーバー用にOPMNで定義されているホスト名および単一のポート番号と一致する必要があります。他のすべてのOC4Jインスタンスでも同じコネクション・ファクトリ構成を使用します。これにより、すべてのOC4Jインスタンスが、操作時に専用JMSサーバーを参照することになります。
したがって、専用JMSサーバーがhost1のポート3701で実行される場合、クラスタ内の各OC4Jインスタンス用のjms.xmlファイルに定義されるすべてのコネクション・ファクトリは、host1のポート3701を指し示す必要があります。このポートは、専用JMSサーバーのための専用OC4Jインスタンス（この例ではJMSserver）で使用されるopmn.xmlファイルに記述された単一のポートです。
専用JMSサーバー上のjms.xmlファイル内で構成されている宛先は、他のすべてのOC4Jインスタンス上でも構成する必要があります。ただし、これらの宛先の物理ストアは専用JMSサーバー上にあります。
キュー・コネクション・ファクトリ定義の例
次に、専用サーバーのjms.xmlファイル内でキュー・コネクション・ファクトリを定義する例を示します。
<!-- Queue connection factory -->
<queue-connection-factory name="jms/MyQueueConnectionFactory"
host="host1" port="3701"
location="jms/MyQueueConnectionFactory"/>
管理上の変更（新規宛先オブジェクトの追加）は、専用JMSサーバーのjms.xmlファイルに加える必要があります。次に、JMSアプリケーションを実行する他のすべてのOC4Jインスタンスのjms.xmlファイル内で、同じ変更を実行します。この変更には、手動で実行する方法と、専用JMSサーバーのjms.xmlファイルを他のOC4Jインスタンスにコピーする方法があります。
JMSコネクタは、専用JMSサーバーのメッセージを送受信するアプリケーションのホストである各OC4Jインスタンスにデプロイされます。このJMSコネクタにより、専用JMSサーバーを参照する、ローカルに構成されたJMSコネクション・ファクトリのJNDIマッピングが提供されます。OC4Jインスタンスにデプロイされたアプリケーションは、JMSコネクタ実装を介して基礎となるJMS管理オブジェクトにアクセスできます。JMSコネクタの使用方法の詳細は、「JMSコネクタ」を参照してください。
JMSコネクタ用のキュー・コネクション・ファクトリの定義
次の例では、事前に（前の例を参照）jms.xmlファイルに定義されているキュー・コネクション・ファクトリ（jms/MyQueueConnectionFactory）をマップするoc4j-ra.xmlファイルにキュー・コネクション・ファクトリを定義しています。
<connector-factory location="MyJMSConnector/QCF"
connector-name="MyJMSConnector">
<config-property name="jndiLocation" value="jms/MyQueueConnectionFactory"/>
<connection-pooling use="private">
<property name="waitTimeout" value="300" />
<property name="scheme" value="fixed_wait" />
<property name="maxConnections" value="50" />
<property name="minConnections" value="0" />
</connection-pooling>
<security-config use="principal-mapping-entries">
<principal-mapping-entries>
<principal-mapping-entry>
<initiating-user>servletuser</initiating-user>
<res-user>jmsuser</res-user>
<res-password>->jmsuser</res-password>
</principal-mapping-entry>
</principal-mapping-entries>
</security-config>
<connectionfactory-interface>
javax.jms.QueueConnectionFactory</connectionfactory-interface>
</connector-factory>
この例で説明すると、OC4JインスタンスにデプロイされたアプリケーションはロケーションMyJMSConnector/QCFを使用して専用サーバーのコネクション・ファクトリをルックアップしています。このロケーションは、jms.xmlファイルに定義されている実際のJMSキュー・コネクション・ファクトリのJNDIロケーション（jms/MyQueueConnectionFactory）にマップされています。リソース・アダプタの構成やデプロイ、およびJMSコネクタの構成の詳細は、「JMSコネクタ」を参照してください。
JMSアプリケーションが実際にデプロイされる場所は、ユーザーが決定します。専用JMSサーバーは、JMS要求を処理する一方で、デプロイされたJMSアプリケーションも実行できます。また、JMSアプリケーションは他のOC4Jインスタンス（つまりHome）にもデプロイできます。
専用JMSサーバーのjms.xmlファイルは、JMSアプリケーションがデプロイされるOC4Jインスタンスすべてに伝播させる必要があることに注意してください。JMSアプリケーションは、別のJVMで実行中のスタンドアロンJMSクライアントにデプロイすることもできます。
OPMNには、専用JMSサーバーの稼働を維持するために、フェイルオーバー・メカニズムが用意されています。なんらかの理由でJMSサーバーに障害が発生すると、OPMNはそれを検出してJVMを再起動します。ハードウェア障害が発生した場合、メッセージをリカバリする唯一の方法は、永続する宛先がネットワーク・ファイル・システム上でホスティングされるようにすることです。OC4Jインスタンスを起動し、これらの永続するファイルを指すように構成できます。
OPMNによるOracle Application Serverプロセスの管理の詳細は、『Oracle Process Manager and Notification Server管理者ガイド』を参照してください。
前述の構成に加え、OEMS JMSは、任意のユーザー定義トポロジとなるように構成できます。
この項では、カスタム・トポロジを作成して機能させるためのメカニズムについて説明します。これらのメカニズムは、このマニュアルの別の項でもすでに定義されていますが、この項では、カスタム・トポロジを使用する場合に理解する必要のあるより高度な内容について説明します。
ローカルのOC4J JVMのサーバー以外にJMSサーバーを使用する場合、目的のJMSサーバーを参照するコネクション・ファクトリが必要です。この構成には、ホストおよびポートのマッピングを使用します。
最初に、JMSサーバーをホストとポートに関連付ける必要があります。通常、ホストは、JMSサーバーが稼働するマシンの単一のホスト（IPアドレス）です。複数のホスト（IPアドレス）を持つマシンの場合、特定のアドレスをjms.xmlファイルの<jms-server>要素のhost属性を使用して指定しないかぎり、すべてのアドレスがJMSサーバーに関連付けられます。portは、port属性を使用して異なる値を指定しないかぎり、9127です。表4-1「構成要素」の<jms-server>エントリと、「ポートの構成」を参照してください。OPMNが使用される場合、port属性は無視され、ポート割当てはopmn.xmlファイルに設定されたポート範囲の値に基づいて自動的に処理されます。「OPMN構成の変更」を参照してください。
各JMSサーバーにホストとポートを指定したら、特定のJMSサーバーを参照するためのコネクション・ファクトリを作成できます。コネクション・ファクトリで特定のJMSサーバーを参照するための最初の手順では、コネクション・ファクトリ要素のhost属性を、特定のJMSサーバーのホスト（IPアドレス）と同じ値に設定します。表4-1「構成要素」で、<connection-factory>や<xa-connection-factory>などのコネクション・ファクトリ要素を参照してください。単一のホスト（IPアドレス）を持つ同じマシン上のJMSサーバーをコネクション・ファクトリで参照する場合、この手順は省略できます（host属性は無視できます）。コネクション・ファクトリで特定のJMSサーバーを参照するための次の手順では、コネクション・ファクトリ要素のport属性を、特定のJMSサーバーのポートと同じ値に設定します。ポートが9127の場合、この手順は省略できます（port属性は無視できます）。
ここまでの手順によってJMSサーバーJMS1を参照するためのコネクション・ファクトリCF1が構成された場合、CF1から作成される接続は、JMS1への接続になります。この接続を通じて実行されるすべての操作は、JMS1を対象とします。この接続を使用して他のJMSサーバーと通信することはできません。（JMS1を対象とするものでないかぎり、この接続を使用してローカルのJVMで稼働するJMSサーバーと通信することもできません。）同様に、この接続を使用してセッションを作成し、そのセッションでメッセージ・プロデューサを作成すると、そのセッションとメッセージ・プロデューサは両方ともJMS1に接続されます。このメッセージ・プロデューサを通じて送信されるすべてのメッセージは、JMS1を対象とし、JMS1によって（メモリー内またはファイルに）格納され、（JMS1に接続されたメッセージ・コンシューマまたはキュー・ブラウザを使用して）JMS1からのみ受信または参照可能となります。ただし、このJMSサーバーとの関連付けは、javax.jms.Messageオブジェクトには拡張されません。あるJMSサーバーと関連付けられたセッションやメッセージ・プロデューサから作成（または受信）されたメッセージ・オブジェクトは、任意のメッセージ・プロデューサを使用して送信できます。つまり、アプリケーションでは、JMSサーバーJMS1で管理されている物理宛先から（JMS1に関連付けられたメッセージ・コンシューマを使用して）メッセージを受信した後に、そのメッセージをJMSサーバーJMS2で管理されている物理宛先に（JMS2に関連付けられたメッセージ・プロデューサを使用して）送信することが可能です。
複数のJMSサーバーを扱う場合は、物理宛先（メッセージが格納される物理的な場所）、宛先構成（jms.xmlの要素と属性）および宛先管理オブジェクト（JNDIでルックアップされるJavaオブジェクト）を区別する必要があります。
JMSサーバーの観点から検討すると、次のようになります。
名前は（宛先構成または宛先管理オブジェクトのいずれにおける名前でも）、特定のJMSサーバーによって個別に管理されている一意の物理宛先を示します。
persistence-file属性（またはこの属性の欠如）は、JMSサーバーに対し、特定の物理宛先のメッセージを永続化する場所を示します。
location属性は、JMSサーバーに対し、（name属性の値を含む）宛先管理オブジェクトをバインドするローカルJVMのJNDIロケーションを示します。
JMSクライアントの観点から検討すると、次のようになります。
宛先管理オブジェクトには、JNDIロケーションは含まれません。かわりに、それらはJNDIロケーションでルックアップされます。
宛先管理オブジェクトには、永続性ファイルの設定は含まれません。かわりに、特定の物理宛先で使用される永続性ファイルは、その物理宛先を管理するJMSサーバーによって決定されます（永続性ファイルが存在する場合）。
宛先管理オブジェクトには、名前のみが含まれ、それらの名前は物理宛先を一意に識別しません。JMSサーバーJMS1と通信する場合、宛先管理オブジェクトは、JMS1によって管理される物理宛先への参照とみなされます。JMSサーバーJMS2と通信する場合、同じ宛先管理オブジェクトは、JMS2によって管理される別の物理宛先への参照とみなされます。（JMSサーバーとの通信時に、特定のJMSサーバーの物理宛先名と一致しない名前を持つ宛先管理オブジェクトが使用されると、操作は失敗します。）
たとえば、JMSサーバーJMS1のjms.xmlファイルが次のように記述されているとします。
<queue name="queue1"
location="jms/alpha"
persistence-file="foo">
</queue>
また、JMSサーバーJMS2のjms.xmlファイルが次のように記述されているとします。
<queue name="queue1" location="jms/omega" persistence-file="bar"> </queue>
<queue name="queue2"
location="jms/alpha">
</queue>
表4-14「様々なメッセージ使用例の結果」は、宛先が列1のサーバーから列2のJNDIロケーションを使用してルックアップされ、列3のサーバーに接続されたメッセージ・プロデューサを通じてPERSISTENTメッセージが送信された場合に、列4の結果となることを示しています。
表4-14 様々なメッセージ使用例の結果
| 宛先がルックアップされるJVM内のサーバー | 宛先のルックアップに使用されるJNDIロケーション | メッセージ・プロデューサの接続先 | 結果（メッセージが受信される物理宛先またはエラー） |
|---|---|---|---|
|
JMS1 |
jms/alpha |
JMS1 |
JMS1のqueue1、ファイルfooに永続化 |
|
JMS1 |
jms/alpha |
JMS2 |
JMS2のqueue1、ファイルbarに永続化 |
|
JMS2 |
jms/alpha |
JMS2 |
JMS2のqueue2、JMS2のメモリー内に格納 |
|
JMS2 |
jms/alpha |
JMS1 |
エラー（JMS1にqueue2はないため） |
|
JMS1 |
jms/omega |
任意 |
JNDIでのjms/omegaのルックアップ・エラー |
|
JMS2 |
jms/omega |
JMS1 |
JMS1のqueue1、ファイルfooに永続化 |
|
JMS2 |
jms/omega |
JMS2 |
JMS2のqueue1、ファイルbarに永続化 |
この例（および分散宛先構成でのコネクション・ファクトリ）では、様々なJVMで同じJNDIロケーションに異なる値をバインドしているか、異なる値を必要とするため、あるJVMから別のJVMにJNDI値を自動的に伝播できません。
次の組合せを使用する場合について検討します。
OPMN（自動JMSポート割当て）
1つ以上の専用JMSサーバー
1つのマシンにおける複数のOC4Jインスタンス
この組合せでは、次の要件に注意する必要があります。
使用可能なJMSポートの範囲が、特定のマシン上のJMSサーバーの数に対して十分であること。これにより、専用JMSサーバーのポート番号が、使用可能なJMSサーバーのいずれかに実際に割り当てられることが保証されます。
専用JMSサーバーによって管理される1つ以上の宛先の永続性ファイルが存在する場合、絶対パスを使用してjms.xmlファイルに指定すること。パスがOC4Jインスタンスに対する相対パスである場合、OPMNが専用JMSサーバーのポート番号を前回の再起動時とは異なるOC4JインスタンスのJMSサーバーに割り当てると、以前に永続化されたメッセージはサーバーの再起動後に失われます。
専用JMSサーバー構成と分散宛先構成は、任意のJMSアプリケーションの各インスタンスが常に単一のJMSサーバーとのみ通信することが保証されている構成です。この項で説明する考慮事項は、これらの使用例には適用されません。同様に、JMSアプリケーション・インスタンスが常に単一のJMSサーバーとのみ通信することが保証される他の使用例にも適用されません。
たとえば、アプリケーションAのすべてのインスタンスでJMSサーバー#1を使用し、アプリケーションBのすべてのインスタンスでJMSサーバー#2を使用する場合、次の考慮事項は適用されません。
ただし、単一のJMSアプリケーション・インスタンスが2つ以上のJMSサーバーと通信するその他の使用例では、次のようにいくつかの考慮事項があります。
アプリケーションが複雑化する問題
JMSサーバーは、コネクション・ファクトリ（およびその導出オブジェクト）に基づいて選択されるため、1つのアプリケーション・インスタンスで複数のJMSサーバーを使用する場合、複数のコネクション・ファクトリ（およびセッション、コンシューマ、プロデューサなどの導出オブジェクト）を使用する必要があります。たとえば、アプリケーションでプロデューサAを使用してメッセージをJMSサーバー#1にエンキューする場合、同じプロデューサAを使用してメッセージをJMSサーバー#2にエンキューすることはできません。かわりに、プロデューサAが導出されたコネクション・ファクトリとは別のコネクション・ファクトリから導出されたプロデューサを使用する必要があります。（具体的には、JMSサーバー#2に関連付けられたコネクション・ファクトリから導出されたプロデューサを使用します。）つまり、アプリケーションがこの前提条件にまだ対応していない場合や、対応するように変更できない場合は、既存のJMSアプリケーションで複数のJMSサーバーを使用できない可能性があります。
パフォーマンス上の問題
2つの異なるJMSサーバーが2つの異なるリソース・マネージャに相当するため、2つのJMSサーバーに関連するグローバル・トランザクションでは、常に2フェーズ・コミットを必要とします（JDBCなどの他のリソース・タイプがトランザクション中に使用されない場合でも同様です）。特定のトランザクションですでに2フェーズ・コミットを必要としていた場合でも、トランザクションに参加するリソース・マネージャの増加は、トランザクションの（パフォーマンス上の）コストの増大につながります。ただし、複数のJMSサーバーを使用することによるパフォーマンス上のメリットも多くあります。複数のJMSサーバーの使用により、潜在的なボトルネック（単一の専用JMSサーバーなど）に起因する作業負荷を軽減し、並列性と局所性の両方を向上することが可能となるためです。
これらの考慮事項は、単一のJMSアプリケーション・インスタンスで2つの異なるJMSリソース・プロバイダを使用する場合にも適用されます。たとえば、アプリケーションでは、メモリー・ベースまたはファイル・ベースの永続性を確保するためにOEMS JMSのメモリー内のオプションを使用し、同時に、データベースに基づく永続性を確保するためにOEMS JMSのデータベースのオプションを使用する可能性があります。
この項では、アプリケーション固有のメッセージ要件が存在する2つの使用例と、各使用例でスループットを改善するために使用できるカスタム・トポロジについて説明します。これらの例は、実際の状況的にも作成可能なトポロジ的にも、完全なものではありません。
使用例1: 一部の宛先のみでグローバル整合性を必要とする場合
一部の宛先では専用JMSサーバー構成に基づくグローバル整合性を必要とする一方で、他の宛先にはそのような要件はないことがあります。この場合、グローバル整合性（単一のJMSサーバーを通じたすべてのメッセージのルーティング）を必要としない宛先でその要件を無理に満たす必要はありません。かわりに、分散宛先構成などを使用してローカルに分割することが可能です。
たとえば、グローバル整合性を必要とする宛先AおよびBと、必要としない宛先CおよびDがあるとします。この場合、すべてのjms.xmlファイルで、4つのすべての宛先を定義します。宛先AおよびB用に、専用JMSサーバーとして機能する1つのマシンを選択します。コネクション・ファクトリで参照できるように、専用JMSサーバーには、固定のホスト値とポート値を割り当てる必要があります。jms.xmlファイルには、少なくとも2つのコネクション・ファクトリを定義します。1つのコネクション・ファクトリは（固定のホスト値とポート値を持つ）専用JMSサーバーを参照し、もう1つはローカルJVM内の（デフォルトのホスト値とポート値を持つ）JMSサーバーを参照します。宛先AおよびBにアクセスするには（グローバル整合性を確保するには）、Javaコードで、専用JMSサーバーを参照するコネクション・ファクトリを使用します。宛先CおよびDにアクセスするには、ローカルJVM内のJMSサーバーを参照するコネクション・ファクトリを使用します。
使用例2: ロード・バランシングのために複数の専用JMSサーバーを使用する場合
前の例では、2つの宛先（AおよびB）がグローバル整合性を必要としていました。この場合、宛先Aと宛先Bの両方に専用JMSサーバーを用意する必要がありますが、これら2つのJMSサーバーは同じである必要はありません。グローバル整合性を必要とする複数の宛先を頻繁に使用する場合は、それらの宛先に対する負荷を複数の専用JMSサーバー間で分散すると効果的である可能性があります。特にこの方法が有効なのは、宛先が一般的なトランザクションにあまり関与しない場合や、複数の宛先を処理する専用JMSサーバーがシステムのボトルネックとなっている場合です。
この場合、すべてのjms.xmlファイルで、4つのすべての宛先を定義します。宛先A用に、専用JMSサーバーとして機能する1つのマシンを選択します。宛先B用に、専用JMSサーバーとして機能するもう1つのマシン（または同じマシン上の別のJVM）を選択します。コネクション・ファクトリで参照できるように、これら2つの専用JMSサーバーには、固定のホスト値とポート値を割り当てる必要があります。jms.xmlファイルには、少なくとも3つのコネクション・ファクトリを定義します。1つのコネクション・ファクトリは宛先Aの専用JMSサーバーを、1つは宛先Bの専用JMSサーバーを、1つはローカルJVM内のJMSサーバーをそれぞれ参照します。宛先Aにアクセスするには、Javaコードで、宛先Aの専用JMSサーバーを参照するコネクション・ファクトリを使用します。宛先Bにアクセスするには、宛先Bの専用JMSサーバーを参照するコネクション・ファクトリを使用します。宛先CおよびDにアクセスするには、ローカルJVMのJMSサーバーを参照するコネクション・ファクトリを使用します。
OEMS JMSのデータベース・オプションで高可用性を実現するには、次のようにします。
AQキューおよびトピックを含むOracleデータベースをRACモードで実行します。これにより、データベースの高可用性が保証されます。
Oracle Application ServerをOPMNモードで実行します。これにより、アプリケーション・サーバー（およびそこにデプロイされたアプリケーション）の高可用性が保証されます。
Oracle Application Serverクラスタ内の各アプリケーション・インスタンスは、OC4Jリソース・プロバイダを使用して、RACモードで稼働しているバックエンドOracleデータベースを参照します。これらのリソース・プロバイダから導出されたオブジェクトで起動されるJMS操作は、Real Application Clusters（RAC）データベースに送られます。
アプリケーション障害が発生すると、そのアプリケーション内の状態情報は失われます（つまり、接続、セッションおよびメッセージの状態はコミットされていません）。アプリケーション・サーバーが再起動されると、アプリケーションはJMS状態を適切に再作成して操作を再開する必要があります。
バックエンド・データベース（非RACデータベース）のネットワーク・フェイルオーバーが発生すると、サーバー内の状態情報は失われます（つまり、トランザクションの状態はコミットされていません）。また、アプリケーション内部のJMSオブジェクト（コネクション・ファクトリ、宛先オブジェクト、接続、セッションなど）も無効になることがあります。
データベース障害の発生後に、アプリケーション・コードでこれらのJMSオブジェクトを使用すると、常に例外がスローされます。リカバリするためには、このような例外をスローしているすべてのJMSオブジェクトをアプリケーションで再作成する必要があります。この処理には、JNDIを使用したコネクション・ファクトリの再ルックアップも含まれます。
RACデータベースを使用するアプリケーションでは、データベース・フェイルオーバーを使用する必要があります。この項で説明されているように、フェイルオーバーには2つのタイプがあります。
RACデータベースに対して実行するスタンドアロン・クライアントでは、API oracle.oc4j.sql.DataSourceUtils.isOracleFatalError()を起動して接続オブジェクトが無効であるかどうかを判断し、接続を再取得するためのコードを記述する必要があります。その後、必要に応じてデータベース接続を再確立します。isOracleFatalError()メソッドは、ネットワーク・フェイルオーバー中にデータベースによりスローされたSQLエラーが致命的エラーであるかどうかを検出します。このメソッドはSQLエラーとデータベース接続を取得して、致命的エラーの場合はtrueを戻します。trueの場合は、トランザクションを積極的にロールバックし、JMSの状態（失われた接続、セッションおよびメッセージなど）を再作成する必要があります。
次の例にこのロジックの概略を示します。
Message getMessage(QueueSession session, Queue rcvrQueue) {
try {
Message msgRec = null;
QueueReceiver rcvr = session.createReceiver(rcvrQueue);
msgRec = rcvr.receive();
rcvr.close();
return msgRec;
}
catch (Exception ex) {
if (ex instanceof JMSException) {
Exception exLinked = ((JMSException) ex).getLinkedException();
if (exLinked instanceof SQLException) {
if (DataSourceUtils.isOracleFatalError((SQLException) exLinked) {
// failover logic
}
}
}
}
}
TAFが構成されているほとんどの場合、アプリケーションは他のデータベース・インスタンスへのフェイルオーバーが発生したことを認識しません。そのため、障害からリカバリするために何かする必要はありません。
ただし、障害の発生時にOC4JからORAエラーがスローされる場合があります。JMSクライアントは、これらのエラーを関連するSQL例外とともにJMSExceptionとしてユーザーに渡します。この場合は、次の1つ以上の操作を実行してください。
エラーが致命的エラーであるかどうかは、isOracleFatalError()メソッドを使用して判断できます。「RACネットワーク・フェイルオーバー」を参照してください。致命的エラーでない場合、クライアントは短時間だけスリープした後、現行の操作を再試行してリカバリします。
少し待ってからJMSコネクションの使用を試行することで、不完全なフェイルオーバーにより発生したフェイルバックと一時的なエラーからリカバリできます。待っている間に、データベースはフェイルオーバーして障害からリカバリし、データベース自体を元の状態に戻します。
トランザクション例外（「トランザクションをロールバックしてください。」（ORA-25402）、「トランザクションのステータスが不明です。」（ORA-25405）など）の場合は、現行の操作をロールバックし、前回のコミット後の操作をすべて再試行する必要があります。例外の原因が解消されるまで、接続は使用できません。この再試行に失敗した場合は、すべての接続をクローズして再作成し、コミットされていない操作をすべて再試行します。
次の例は、任意の永続性オプションで使用できるOEMS JMSのアプリケーション・コードです。このキューにより、ネットワークの障害、サーバーの再起動、JMSサーバーのフェイルオーバーなどの状況で発生することのある断続的な接続に対応できます。
while (!shutdown) {
Context ctx = new InitialContext();
// get the queue connection factory
QueueConnectionFactory qcf =
(QueueConnectionFactory) ctx.lookup(QCF_NAME);
// get the queue
Queue q = (Queue) ctx.lookup(Q_NAME);
ctx.close();
QueueConnection qc = null;
try {
// create a queue connection, session, sender and receiver
qc = qcf.createQueueConnection();
QueueSession qs = qc.createQueueSession(true, 0);
QueueSender snd = qs.createSender(q);
QueueReceiver rcv = qs.createReceiver(q);
// start the queue connection
qc.start();
// receive requests using the queue receiver and send
// replies using the queue sender
while (!done) {
Message request = rcv.receive();
Message reply = qs.createMessage();
// put code here to process request and construct reply
snd.send(reply);
qs.commit();
}
} catch (JMSException ex) {
if (transientServerFailure) {
// retry
} else {
shutdown = true;
}
} finally {
// close the queue connection
if (qc != null) qc.close();
}
}
接続プーリングでは、アプリケーションによって接続がクローズされる場合、実際には物理接続はコネクタによってクローズされず、接続プールに戻されることに注意してください。接続に失敗すると、無効な接続がプールに戻される可能性があります。続けて新規接続を作成すると、無効な接続が取得されることがあります。その場合、前述のコードの有効性は失われます。フェイルオーバーの信頼性を保証するには、接続を作成するコネクション・ファクトリの接続プーリングを無効にする必要があります。これを行うには、oc4j-ra.xmlファイルのコネクション・ファクトリの<connector-factory>要素を次のように変更します。
<connection-pooling use="none">
</connection-pooling>
JMSクライアント・サイドの状態を最小限に抑えます。
処理をトランザクション済セッションで実行します。
完全なリカバリ可能性を得るために、中間的なプログラムの状態をJMSキューまたはトピックに保存するか、チェックポイントを設定します。
J2EEアプリケーションの状態がJVM境界にまたがってシリアライズ可能またはリカバリ可能であるかどうかに依存しません。JMSオブジェクトには常に一時的なメンバー変数を使用し、JMSの状態を適切に保存してリカバリする受動/能動およびシリアライズ/デシリアライズ関数を記述します。
トピックへの非永続サブスクリプションを使用しません。
トピックへの非永続サブスクリプションでは、アクティブなサブスクライバごとにメッセージが複製されます。クラスタリングやロード・バランシングにより、複数のアプリケーション・インスタンスが作成されます。アプリケーションで非永続サブスクライバが作成されると、各メッセージの複製がトピックにパブリッシュされます。これは非効率的であるか、セマンティック的に無効です。
トピックには永続サブスクリプションのみを使用します。できるだけキューを使用してください。
永続サブスクリプションがアクティブな期間を延長しません。
常にアクティブであることが可能な永続サブスクリプションのインスタンスは1つのみです。クラスタリングやロード・バランシングにより、複数のアプリケーション・インスタンスが作成されます。アプリケーションで永続サブスクリプションが作成されると、クラスタ内のアプリケーションのインスタンスは1つのみ成功し、他のすべてはJMSExceptionが発生して失敗します。
永続サブスクリプションは短時間または少数のコード範囲で作成、使用してクローズし、サブスクリプションがアクティブになっている期間を最短に抑えます。
クラスタリング（クラスタ内で実行されているアプリケーションの他のインスタンスが現在同じコード・ブロック内にあること）による永続サブスクリプションの作成失敗に対応するアプリケーション・コードを記述し、適切なバックオフ方法をプログラミングします。永続サブスクリプションの作成失敗は、常に致命的エラーとして処理しないでください。
複雑な異機種間エンタープライズ・コンピューティング環境では、様々なメッセージング・システムと統合して相互運用するメッセージング・インフラストラクチャが必要です。JMSルーターにより、次の宛先間をブリッジできる信頼性の高い非同期JMSメッセージ・ルーティング・サービスが提供されます。
同一のJMSプロバイダの宛先。
異なるJMSプロバイダの宛先。
JMSルーターにより、次の動作が保証されます。
永続的なJMSメッセージの場合、必ず1回のメッセージ配信が保証されます。
非永続的なJMSメッセージの場合、最大1回のメッセージ配信が保証されます。
ソース宛先からJMSルーターが受信した順序でのメッセージ配信が保証されます。
ユーザーは、ルーター・ジョブの作成時に、メッセージを選択的にルーティングするメッセージ・セレクタを指定できます。セレクタの条件を満たすメッセージのみが、JMSルーターによってソース宛先からターゲット宛先にルーティングされます。メッセージ・セレクタは、有効なJMSメッセージ・セレクタである必要があります。JMSキューおよびトピック用のメッセージ・セレクタの構文とセマンティックは、JMS 1.1仕様を参照してください。
JMSルーターでは、JMSルーター・ジョブのソースまたはターゲットがJMSトピックである場合、関連するJMSプロバイダがJMS 1.1をサポートしている必要があります。
JMS 1.1仕様は、http://java.sun.com/products/jms/docs.htmlで入手できます。
JMSの宛先をブリッジするJMSルーターには、次のメリットがあります。
あるメッセージ・システムでメッセージを送信するアプリケーションと別のメッセージ・システムでメッセージを受信するアプリケーションを分離できます。2つのアプリケーションでは、メッセージが異なるメッセージ・システムを経由していることを考慮する必要はありません。
複数のメッセージ・システムを介してメッセージを送受信するアプリケーションでは、1つのメッセージ・システムに接続するだけで済み、JMSルーターを使用して複数のメッセージ・システムにメッセージを配信できます。これにより、複数のメッセージ・システムへの接続、2フェーズ・コミットによるグローバル・トランザクションの管理、メッセージの変換処理などを行う必要がなくなるため、アプリケーション・コードが簡略化されます。
JMSルーターの自動リカバリおよびメッセージ配信保証機能により、すべての関連メッセージ・システムが同時に稼働する必要がなくなるため、アプリケーションおよびアプリケーション統合の信頼性が向上します。
JMSルーターでは、JMSコネクタを使用して次のJMSプロバイダにアクセスします。
OEMS JMSのメモリー内、ファイル・ベースおよびデータベースの永続性オプション
IBM WebSphere MQ V6.0 JMSおよびFix Pack 8（CSD08）を適用したMQ V5.3 JMS
TIBCO Enterprise Message Serverバージョン4.3.0
SonicMQ 6.0 JMS
JMSルーターでは、OC4J付属パッケージのスタンドアロンJMSコネクタ・インスタンスであるOracleASjmsを使用して、JMSルーターと同じコンテナ内で稼働するOEMS JMSのメモリー内およびファイル・ベースのオプションにアクセスします。したがって、OEMS JMSのメモリー内またはファイル・ベースの宛先を対象にメッセージをルーティングする場合、追加のアダプタをデプロイする必要はありません。
OracleAS JMS以外のJMSプロバイダを対象にメッセージをルーティングする場合、そのJMSプロバイダ用のスタンドアロンJMSコネクタをデプロイする必要があります。
JMSルーターでは、JMSプロバイダの認証と認可に、J2CAアダプタによる宣言的なコンテナ管理のサインオン・メカニズムを使用します。JMSルーターは、ロールjmsRouterのかわりに実行されます。したがって、JMSルーターに使用されるすべてのリソース・アダプタには、<default-mapping>要素、またはoc4j-ra.xmlの<initiating-user>にjmsRouterを保持する<principal-mapping-entry>要素に基づく有効なプリンシパル・マッピングが含まれる必要があります。
OEMS JMSでJMSルーターを使用する方法の詳細は、http://www.oracle.com/technology/tech/java/oc4j/1013/how_to/index.htmlのドキュメントを参照してください。
この項では、次のJMSルーター・オブジェクトに関する構成について説明します。
JMSルーターの主要な管理インタフェースは、JMSルーターMBeanです。このMBeanにより、構成の管理、個々のJMSルーター・ジョブの起動と停止、およびジョブのステータスの監視を行うことができます。
JMSルーターは、jms.xmlファイルを通じて静的に構成することも可能です。
JMSルーター・ジョブは、ソース宛先からターゲット宛先にメッセージを移動するメッセージ・ルーティング・タスクとして定義されます。ルーター・ジョブを処理する場合、JMSルーターは、ソース宛先からメッセージをデキューし、ターゲット宛先にそのメッセージをエンキューします。
ソース宛先とターゲット宛先は、JMSキューまたはトピックのいずれかです。ソースがJMSキューである場合、JMSルーターは、すべてのメッセージをキューから移動します。ソースがトピックである場合、JMSルーターは、JMS永続サブスクライバが作成されてからそのトピックにパブリッシュされたすべてのメッセージを移動します。
|
注意: JMSルーター・ジョブでは、ソースがキューであるか永続サブスクライバであるかにかかわらず、そのソースを共有できません。 |
JMSルーター・ジョブでは、表4-16「JMSルーター設定」に記載されているオブジェクトを使用します。
JMSルーターでは、JMSコネクタを使用して、JMSの宛先とコネクション・ファクトリにアクセスします。JMSルーターでは、すべてのJMSルーター・ジョブのソース宛先およびターゲット宛先が、アクセス先のJMSプロバイダに存在し、適切に構成されたJMSコネクタ内で設定されている必要があります。キュー、トピックおよびコネクション・ファクトリを構成する方法の詳細は、「宛先オブジェクトおよびコネクション・ファクトリの構成」を参照してください。リソース・アダプタを構成する方法の詳細は、「JMSコネクタ」および『Oracle Containers for J2EEリソース・アダプタ管理者ガイド』を参照してください。
同時ジョブの数は、JMSルーター属性maxLocalConcurrencyで構成できます。この属性により、多くのアクティブなジョブを処理するJMSルーターがOC4J J2EEコンテナを占有しないよう調整できます。また、この属性では、JMSルーターが使用するJMSコネクタで作成されるJMSセッションの上限数も設定できます。
ソースがJMSトピックである場合、トピックの永続サブスクライバ名を指定できます。実際の永続サブスクライバは、関連するルーター・ジョブの作成前に作成できます。永続サブスクライバ名を指定しない場合、JMSルーターにより、ジョブ名に基づいたサブスクライバ名が作成されます。JMSルーターがジョブの処理を開始したときに、サブスクライバ名に関連付けられた永続サブスクライバが存在しない場合、ルーターにより永続サブスクライバが作成されます。JMSルーターは、永続サブスクライバが作成されてからそのトピックにパブリッシュされたすべてのメッセージを移動します。
デフォルトでは、JMSルーターは、JMSルーター・ジョブが削除された段階で永続サブスクライバも削除するよう試みます。JMSルーターが永続サブスクライバの削除に失敗した場合は、不要なメッセージが蓄積されないように、ユーザーがメッセージ・システムの管理インタフェースを使用してその永続サブスクライバを削除する必要があります。オプションで、JMSルーター・ジョブの削除時に永続サブスクライバを削除しないようJMSルーターを設定することも可能です。
この項では、ログ・キューと例外キューについて説明します。
ログ・キュー
JMSルーターでは、内部ロギングにキューを使用します。各ルーター・ジョブには、ソース・ログ・キューとターゲット・ログ・キューが必要です。これらのキューは、ルーター・ジョブを処理する際のサービス品質を確保するために使用されます。OEMS JMSのメモリー内およびファイル・ベースのオプションでは、ログ・キューはJMSルーターによって作成されます。OEMS JMSのデータベースのオプションやサポートされる他のOracle以外のJMSプロバイダでは、JMSキューをそのシステムで作成し、キューの名前をルーター・ジョブの作成時に指定する必要があります。ログ・キューは、複数のジョブで共有可能です。
JMSルーターのログ・キューは、アクセス先のメッセージ・システムに存在し、適切なリソース・アダプタ内で構成されている必要があります。
例外キュー
ターゲット宛先に対するメッセージの送信に失敗した場合、JMSルーターは、メッセージの順序を維持するために関連するルーター・ジョブの処理をブロックします。
問題のあるメッセージを含むジョブの処理をJMSルーターで継続するには、例外キューを使用してジョブを構成します。JMSルーターでは、ソース宛先の残りのメッセージを処理するために、問題のあるメッセージを例外キューに移動できます。
JMSルーター・ジョブごとに1つの例外キューを割り当てます。この例外キューは、ソース宛先と同じメッセージ・システム内にあるJMSキューで、ソース宛先と同じコネクション・ファクトリを使用してアクセスできる必要があります。例外キューの物理的なJMS宛先は、JMSルーター・ジョブでの使用前に存在している必要があります。OEMS JMSのメモリー内およびファイル・ベースのオプションでは、Oc4jJmsExceptionQueueという例外キューがデフォルトで定義されています。
JMSルーターで問題のあるメッセージを例外キューに移動するためには、関連するルーター・ジョブのuseExceptionQueueフラグをtrueに設定する必要があります。
JMSルーターの例外キューをオプションで構成する場合、その例外キューは、アクセス先のメッセージ・システムに存在し、適切なリソース・アダプタ内で構成されている必要があります。
JMSルーターの主要な管理インタフェースは、JMSルーターMBeanです。このMBeanを使用して、構成の管理、個々のJMSルーター・ジョブの起動と停止、およびジョブのステータスの監視を行います。
この項では、JMSルーターMBeanで使用できる操作および設定について説明します。
JMSルーターMBeanへのパス:
「OC4J: ホーム」→「管理」タブ→「サービス」→「JMSプロバイダ」→アイコンをクリック→適切なタブを選択→「関連リンク: OracleAS JMS Router」
|
注意: JMSルーターは、OC4Jインスタンスごとに1つのJMSルーターMBeanをエクスポートします（jmsrouter:j2eeType=OracleASJMSRouter）。 |
次の表に、JMSルーターMBeanで使用可能な操作とその説明を示します。すべての操作はJMSルーターを動的に更新し、その変更はjms.xmlに永続化されます。
表4-15 JMSルーターMBeanの操作
| 操作 | 説明 |
|---|---|
|
|
JMSルーター・ジョブを構成します。 |
|
|
JMSルーター・ジョブの属性を変更します。alterRouterJobのすべてのパラメータのデフォルト値は、パラメータを変更しないままの状態です。 |
|
|
JMSルーターの特定のグローバル・パラメータ（ |
|
|
JMSルーター・ジョブの実行を一時停止します。 |
|
|
JMSルーター・ジョブを削除します。 |
|
|
JMSルーター・ジョブの失敗数を0（ゼロ）にリセットします。 |
|
|
JMSルーター・ジョブの実行を再開します。 |
表4-16「JMSルーター設定」に、JMSルーターMBeanでのルーター設定およびルーター・ジョブ設定とその説明を示します。表の最初の列は、JMSルーターMBeanでの設定の名前です。JMSルーターMBeanで実行した設定は、jms.xmlファイルに永続化されます。表の2番目の列は、jms.xmlファイルでの対応する要素の名前です。
表4-16 JMSルーター設定
| MBean設定 | XMLエンティティ | 説明 |
|---|---|---|
|
|
ルーター・ジョブ要素 |
このルーター・ジョブの名前。構成対象のOC4Jインスタンスに対して一意である必要があります。 |
|
|
ルーター・ジョブ要素 |
メッセージのソースとして使用する宛先（トピックまたはキュー）のJNDIロケーション。 自動宛先ラッピングを使用する場合、名前には次の形式を使用できます。
ここで、 たとえば、自動宛先ラッピングをJMSコネクタと組み合せて使用する場合、名前は次の形式になります。
または
|
|
|
ルーター・ジョブ要素 |
メッセージ・ソースへのアクセスに使用するコネクション・ファクトリのJNDIロケーション。 たとえば、JMSコネクタを使用する場合、名前は次のようになります。
メッセージ・ソースがJMSトピックの場合、この名前には、JMSキューおよびトピックの両方をサポートするコネクション・ファクトリを指定する必要があります。 |
|
|
< ルーター・ジョブ要素 |
メッセージ伝播のターゲットとして使用する宛先（トピックまたはキュー）のJNDIロケーション。 自動宛先ラッピングを使用する場合、名前には次の形式を使用できます。
ここで、 たとえば、自動宛先ラッピングをJMSコネクタと組み合せて使用する場合、名前は次の形式になります。
または
|
|
|
ルーター・ジョブ要素 |
たとえば、JMSコネクタを使用する場合、名前は次のようになります。
メッセージ・ソースがJMSトピックの場合、この名前には、JMSキューおよびトピックの両方をサポートするコネクション・ファクトリを指定する必要があります。 |
|
|
ルーター・ジョブ要素 |
JMSルーターがソース・メッセージ・システムの内部ロギングに使用するキューのJNDIロケーション。ログ・キューは、次の名前で識別されるコネクション・ファクトリを通じてアクセスできる必要があります。
OEMS JMSのメモリー内またはファイル・ベースの宛先を使用している場合、このパラメータはオプションです。指定しない場合、JMSルーターでは次のキューが使用されます。
このキューが存在しない場合、JMSルーターにより作成されます。 |
|
|
ルーター・ジョブ要素 |
JMSルーターがターゲット・メッセージ・システムの内部ロギングに使用するキューのJNDIロケーション。ログ・キューは、次の名前で識別されるコネクション・ファクトリを通じてアクセスできる必要があります。
OEMS JMSのメモリー内またはファイル・ベースの宛先を使用している場合、このパラメータはオプションです。指定しない場合、JMSルーターでは次のキューが使用されます。
このキューが存在しない場合、JMSルーターにより作成されます。 |
|
|
ルーター・ジョブ要素 |
オプション。 |
|
|
ルーター・ジョブ要素 |
オプション。 デフォルト値は次のとおりです。
OracleASRouter_jobName
ここで、jobNameは、ルーター・ジョブの名前です。 |
|
|
ルーター・ジョブ要素 |
配信できないメッセージを配置するキューのJNDIロケーション。例外キューは、 このパラメータは、useExceptionQueueがtrueの場合にのみ指定する必要があります。useExceptionQueueが
|
|
|
ルーター・ジョブ属性 |
オプション。JMSルーターでこのジョブの実行を一時停止する前にメッセージの配信を試行する回数。 値は、整数値文字列である必要があります。文字列が整数を示していない場合、無視されてデフォルトが使用されます。
|
|
|
ルーター・ジョブ属性 |
オプション。メッセージがメッセージ・ソースに存在しない場合に、メッセージ・ソースを再度チェックする前に待機する最低限の秒数。 値は、整数を示す文字列である必要があります。文字列が整数を示していない場合、無視されてデフォルトが使用されます。
|
|
|
ルーター・ジョブ属性 |
オプション。値が
|
|
|
ルーター・ジョブ属性 |
オプション。 ジョブを開始するには、
デフォルトは |
|
|
ルーター・ジョブ属性 |
オプション。1回のトランザクションでデキューおよびエンキューするメッセージの数。
|
|
|
ルーター・ジョブ属性 |
デフォルトは |
|
|
グローバルJMSルーター属性 |
オプション。可能にするデキュー操作の最大同時実行数。この引数では、JMSルーターがメッセージをデキューするために一度に使用できるスレッドの数を制限します。このパラメータは、JMSルーターによって使用されるコンテナ・リソースの量を制限します。 デフォルト値は |
J2EE_HOME/config/jms.xmlファイルは、JMSルーター・ジョブおよびグローバル構成を永続化するのに使用されます。
JMSルーターは、jms.xmlファイルの<jms-router>要素で構成します。<jms-router>要素には、0個以上の<router-job>要素が含まれます。JMSルーター・ジョブは、<router-job>要素で定義します。
表4-16「JMSルーター設定」はjms.xmlファイルのJMSルーター要素とその説明の一覧です。
最小構成の例: jms.xmlでのJMSルーター構成
この例では、単一のJMSルーター・ジョブの最小構成を示します。このジョブは、OEMS JMSのメモリー内のキューをソースおよびターゲットとして使用し、グローバルにデプロイされたJMSコネクタ・インスタンスのOracleASjmsをJMSオブジェクトとして利用します。
<?xml version="1.0"?>
<jms xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchema
Location="http://www.oracle.com/technology/oracleas/schema/jms-server-10_1.xsd"
schema-major-version="10" schema-minor-version="1">
<!-- OracleAS JMS server configuration -- omitted for brevity -->
<jms-server>
...
</jms-server>
<!-- JMS Router configuration -->
<jms-router max-local-concurrency="-1" >
<!-- Minimal configuration for a JMS Router job.-->
<router-job job-name="routerjob1">
<!-- The name of a JMS Router destination -->
<message-source>OracleASjms/Topics/jms/mySource</message-source>
<!-- Connection factory for the message source. -->
<source-connection-factory>OracleASjms/MyCF</source-connection-factory>
<!-- The name of a JMS Router destination -->
<message-target>OracleASjms/Queues/jms/myTarget</message-target>
<!--Connection factory for the message target. -->
<target-connection-factory>OracleASjms/MyCF</target-connection-factory>
</router-job>
</jms-router>
</jms>
構文の例: jms.xmlでのJMSルーター構成
この例では、使用可能なすべての属性値を設定するルーター・ジョブを定義して、jms.xmlのJMSルーターに関する構文を示します。この例では、単一のJMSルーター・ジョブの構成を定義しますが、このジョブは、OEMS JMSのメモリー内のキューをソースとして、OEMS JMSのデータベースのキューをターゲットとして使用します。また、JMSコネクタ・インスタンスのOracleASjmsをソースJMSオブジェクトとして、JMSコネクタ・インスタンスのojmsaqをターゲット・オブジェクトとして利用します。
<?xml version="1.0"?>
<jms xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchema
Location="http://www.oracle.com/technology/oracleas/schema/jms-server-10_1.xsd"
schema-major-version="10" schema-minor-version="1">
<!-- OracleAS JMS server configuration -- omitted for brevity -->
<jms-server>
...
</jms-server>
<!-- JMS Router configuration -->
<jms-router max-local-concurrency="-1" >
<router-job
job-name="routerjob1"
max-retries="16"
polling-interval="5"
pause-job="false"
use-exception-queue="true"
batch-size="30"
>
<!-- The name of an JMS Router source destination -->
<message-source>OracleASjms/Topics/jms/mySource</message-source>
<!-- Connection factory for the message source. -->
<source-connection-factory>OracleASjms/MyCF</source-connection-factory>
<!-- A message selector used at the message source -->
<message-selector>color='blue'</message-selector>
<!--This is the default subscriber name for this job as written to this
file by the JMS Router -->
<subscriber-name>OracleASRouter_routerjob1</subscriber-name>
<!--There is no need to specify the log queue for OracleAS JMS, but the
default value will be written back to this file by the JMS Router -->
<source-log-queue>OracleASjms/Queues/OracleASRouter_LOGQ</source-log-queue>
<!-- An exception queue -->
<exception-queue>OracleASjms/Queues/jms/myExQ</exception-queue>
<!-- The name of an JMS Router target destination -->
<message-target>ojmsaq/Queues/Queues/MyDBTarget</message-target>
<!-Connection factory for the message target. -->
<target-connection-factory>ojmsaq/CF</target-connection-factory>
<!-- A log queue must be specified for all providers but OracleAS JMS.
This queue must already exist ->
<target-log-queue>ojmsaq/Queues/Queues/MyJMSRouterLog</target-log-queue>
</router-job>
</jms-router>
</jms>
この項では、JMSルーターを管理するためのJMSルーターMBeanの操作について説明します。
JMSルーターMBeanでは、次の操作を実行できます。
各JMSルーター・ジョブの開始と停止
ルーター・ジョブ・ステータスの監視
JMSルーターの監視と問合せ
表4-15「JMSルーターMBeanの操作」 は、JMSルーターMBeanの操作とその説明の一覧です。
JMSルーターMBeanへのパス:
「OC4J: ホーム」→「管理」タブ→「サービス」→「JMSプロバイダ」→アイコンをクリック→適切なタブを選択→「関連リンク: OracleAS JMS Router」
JMSルーターの実行時ステータス情報にアクセスするには、JMSルーターMBeanのRouterJobsStatusおよびRouterGlobalStatus属性を使用します。
JMSルーター・ジョブの処理中には、ソースまたはターゲット宛先への接続障害やメッセージ操作の失敗などの様々な障害が発生する可能性があります。JMSルーターは、障害の性質やルーター・ジョブの構成に基づいて、障害を次のように処理します。
JMSルーターが、メッセージの内容を原因としてターゲット宛先にメッセージをエンキューできない場合で、かつ
例外キューが存在しないか、関連するルーター・ジョブのuseExceptionQueueフラグがfalseに設定されている場合、JMSルーターは、ルーター・ジョブの処理を停止します。
ジョブ用の例外キューが存在し、関連するルーター・ジョブのuseExceptionQueueフラグがtrueに設定されている場合、JMSルーターは、そのメッセージを例外キューに移動して後続のメッセージの処理を続けます。
メッセージがソース宛先から例外キューに移動される場合、エラー情報の維持を目的として、JMSルーターにより元のメッセージに特定のメッセージ・プロパティが追加されます。表4-18「例外キューのメッセージに追加されるプロパティ」に、これらのメッセージとその説明を示します。
表4-18 例外キューのメッセージに追加されるプロパティ
| JMSプロパティ | 説明 |
|---|---|
|
|
ソース・メッセージのID |
|
|
ルーター・ジョブの名前 |
|
|
デキューまたはエンキューに使用されたコネクション・ファクトリの名前 |
|
|
メッセージが取得されたソース・キューの名前 |
|
|
メッセージが例外キューに移動された理由 |
|
|
メッセージが例外キューに移動された時刻 |
障害の原因がメッセージの内容ではない場合、JMSルーターは、次の式に基づいて徐々に間隔を空けながら失敗した操作を自動的に再試行します。
(2^n) * (pollingInterval),
この間隔は、最大15分です。この再試行操作は、成功するまで、またはmaxRetries属性（表4-16「JMSルーター設定」を参照）で指定された構成可能な最大再試行回数に到達してルーター・ジョブの処理が停止されるまで継続されます。
maxRetries設定で指定された再試行回数に到達してルーター・ジョブの処理が停止された場合に、ジョブの処理を再開するには、resetJobをコールして失敗回数を0にリセットします。
各ジョブの失敗回数は、メモリーに格納されます。そのため、JMSルーターが再起動すると、すべてのジョブの失敗回数は0にリセットされます。
JMSルーター・ジョブには、表4-16「JMSルーター設定」に記載したpauseJob設定で指定できるactivatedモードとdeactivatedモードがあります。
deactivatedモードのジョブは、JMSルーターで処理されません。
ジョブをdeactivatedモードに移行するには、JMSルーターMBeanのpauseJob操作を使用します。
ジョブをactivatedモードに移行するには、JMSルーターMBeanのresumeJob操作を使用します。
デフォルトでは、ジョブはactivatedモードで作成されます。
OC4Jクラスタ環境では、JMSルーター・インスタンスは、OC4Jインスタンスごとに実行できます。これらのJMSルーター・インスタンスは、個別に構成され、相互に独立して実行されます。あるOC4Jインスタンス上に構成されたJMSルーター・ジョブは、そのOC4Jインスタンスで稼働するJMSルーター・インスタンスによってのみ処理されます。
JMSルーター・ジョブは、特定のOC4JインスタンスのJMSルーターMBeanまたはjms.xmlファイルを使用して作成または管理する必要があります。
OC4Jインスタンスに定義されたJMSルーター・ジョブにより参照されるすべてのJMSコネクション・ファクトリおよびJMS宛先は、そのOC4Jインスタンスからアクセスできる必要があります。
OC4Jインスタンスが停止すると、そのOC4Jインスタンス上で稼働するJMSルーター・インスタンスに定義されたジョブは、処理されません。
原則として、異なるJMSルーター・ジョブでは、一般的なソース（キューまたは永続サブスクライバ）を共有することはできません。違反した場合、JMSルーター・ジョブにリカバリ不可能な障害が発生する可能性があります。OC4Jクラスタ環境では、クラスタ内のすべてのOC4Jインスタンスにこの原則が適用されます。
OEMS JMSのメモリー内またはファイル・ベースの分散宛先ではないJMSキューは、OC4Jクラスタ全体でただ1つのJMSルーター・ジョブのソースとなることができます。
OEMS JMSのメモリー内またはファイル・ベースの分散宛先ではないJMSトピックは、OC4Jクラスタ全体で複数のJMSルーター・ジョブのソースとなることができます。ただし、関連する永続サブスクライバの名前は、クラスタ内で一意である必要があります。具体的には、JMSルーター・ジョブのサブスクライバ名を指定するときに、それぞれ異なる名前を付けます。サブスクライバ名を指定しない場合、JMSルーター・ジョブの名前に基づいて永続サブスクライバ名が生成されるため、JMSルーター・ジョブの名前は、ソースとして同じトピックを共有するジョブに関してクラスタ全体で一意である必要があります。
クラスタ内のOC4Jインスタンスに存在するOEMS JMSのメモリー内またはファイル・ベースの分散宛先の各コピーは、JMSルーターにより個別のJMS宛先として扱われます。OEMS JMSのメモリー内またはファイル・ベースの分散宛先からメッセージをルーティングするには、その宛先をソースとして使用するJMSルーター・ジョブを各OC4Jインスタンスに定義する必要があります。
JMSルーターでは、OEMS JMSのリモート・コネクション・ファクトリを使用して、あるOC4JインスタンスからOEMS JMSを介して別のOC4Jインスタンスにメッセージをルーティングできます。詳細は、「カスタム・トポロジ」を参照してください。
リモートOEMS JMSインスタンスのコネクション・ファクトリを使用してJMSルーター・ジョブを定義する場合、そのコネクション・ファクトリを使用してアクセスされる任意のJMS宛先は、リモートとローカル両方のOC4Jインスタンスで定義される必要があります。ソース・コネクション・ファクトリがリモートである場合、これらのJMS宛先には、メッセージ・ソース、JMSルーターのソース・ログ・キュー、および（オプションの）例外キューが含まれます。ターゲット・コネクション・ファクトリがリモートである場合、適切なJMS宛先には、メッセージ・ターゲットと、JMSルーターのターゲット・ログ・キューが含まれます。
メッセージ・ソースまたはメッセージ・ターゲットがリモートである場合、JMSルーター・ジョブの作成時に、JMSルーター・ログ・キューをリモート・インスタンス上に手動で作成して指定する必要があります。
OEMS JMSでは、JMSメッセージがファイアウォールを通過できるようHTTPトンネリングがサポートされています。この機能は、Webで稼働しているOC4Jインスタンス上にJMS HTTPトンネル・プロバイダを構成することで有効化されます。Webで稼働するOC4Jインスタンスは、ファイアウォールの内側に配置されている場合があります。この機能は、OEMS JMSのメモリー内およびファイル・ベースでのみ使用可能です。リモート宛先へのルーティングの詳細は、「リモート宛先を使用したルーティング」および「カスタム・トポロジ」を参照してください。
JMS HTTPトンネル・プロバイダが構成されている場合、JMSアプリケーションはtunnel、hostおよびport属性が定義されているコネクション・ファクトリをルックアップしてHTTPトンネリングを使用します。tunnel属性は、JMS HTTPトンネル・プロバイダのURLを指定します。hostおよびport属性は、JMSリクエストを処理するターゲットJMSサーバーを指定します。前述のコネクション・ファクトリを使用してJMSアプリケーションによりJMS接続が作成されると、ターゲットJMSサーバーへの通信はJMS HTTPトンネル・プロバイダ経由でルーティングされます。アプリケーションとJMS HTTPトンネル・プロバイダ間の通信には、HTTP（またはSSLを使用するよう構成されている場合はHTTPS）が使用されます。JMS HTTPトンネル・プロバイダとターゲットJMSサーバー間の通信には、TCPが使用されます。
<http-tunnel>要素がOC4Jインスタンスのjms.xml構成ファイルに含まれている場合、OC4Jインスタンスは、JMS HTTPトンネル・プロバイダとして機能します。<http-tunnel>要素は、<jms-server>要素のオプションのサブ要素です。各OC4Jインスタンスに定義できるJMS HTTPトンネルは最大で1つです。
|
注意: OC4Jインスタンスのjms.xml構成ファイルで<http-tunnel>要素が追加、変更または削除された場合には、OC4Jインスタンスを再起動する必要があります。 |
次の表に、<http-tunnel>ノードの構成要素を示します。
表4-19 OEMS JMS HTTPトンネルの構成
| 要素および属性 | 説明 |
|---|---|
|
|
値 値 |
|
|
|
|
|
値 値 確実に自動検出できる特定の |
|
|
|
|
|
|
次の例では、jms.xmlファイルに構成されたJMS HTTPトンネルを示します。
<jms>
<jms-server>
...
<http-tunnel authentication="required">
<tcp-relay filter="list" timeout="5000">
<target host="host1" port="9127"/>
<target host="host2" port="9127"/>
</tcp-relay>
</http-tunnel>
...
</jms-server>
<jms-router>
...
</jms-router>
</jms>
JMS HTTPトンネル・プロバイダは、JMS HTTPトンネル・プロバイダのOC4JインスタンスでJMS接続のユーザー名/パスワードが両方とも有効（認証がrequiredに設定されているため）で、ターゲットJMSサーバーがJMSトンネリング・プロトコルに肯定的に対応する場合に、JMSリクエストをJMSサーバーにリレーするように構成できます。
<http-tunnel authentication="none"/>
JMS HTTPトンネル・プロバイダは、JMS HTTPトンネル・プロバイダのOC4JインスタンスでJMS接続のユーザー名/パスワードが両方とも有効（認証がrequiredに設定されているため）で、ターゲットJMSサーバーがJMS HTTPプロトコルに肯定的に対応する場合に、リクエストを任意のJMSサーバーに転送するように構成できます。
<http-tunnel authentication="required">
<tcp-relay filter="auto"/>
</http-tunnel>
JMS HTTPトンネル・プロバイダは、server1.xyz.com port 9127またはserver2.xyz.com port 2000のJMSサーバー宛のJMSリクエストのみをリレーするように構成できます。
<http-tunnel authentication="none">
<tcp-relay filter="list">
<target host="server1.xyz.com" port="9127">
<target host="server2.xyz.com" port="2000">
</tcp-relay>
</http-tunnel>
JMS HTTPトンネル・プロバイダの機能はWebアプリケーションとして構成され、Oracle Application ServerでOracle HTTP Serverを使用する場合とOracle HTTP Serverを使用しないスタンドアロンの場合のどちらでも、Secure Socket Layer（SSL）通信でのOC4Jのサポートを利用できます。SSL通信の設定方法の詳細は、『Oracle Containers for J2EEセキュリティ・ガイド』を参照してください。
コネクション・ファクトリ構成に構成済のOEMS JMS HTTPトンネル・プロバイダのURLに設定されたtunnel属性が含まれる場合、OEMS JMSアプリケーションはJMS HTTPトンネルのみを通過します。この章の表4-1ですでに説明したコネクション・ファクトリ属性に加え、JMSのコネクション・ファクトリ属性も設定されています。
|
注意: OC4Jインスタンスのjms.xml構成ファイルでコネクション・ファクトリが追加、変更または削除された場合には、OC4Jインスタンスを再起動する必要があります。 |
表4-20 コネクション・ファクトリの属性
| 属性 | 説明 |
|---|---|
|
|
この属性は、JMS HTTPトンネル・プロバイダ・サーブレットのURLです。URLは、 スタンドアロンのOC4J:
iAS:
HTTPSを介してJMS HTTPトンネリングを使用している場合には、ポート番号が、SSL対応のOC4J Webサイトを指定している必要があります。 |
|
|
この属性には、キーストアの名前およびパスが含まれます。キーストアは、SSLを使用してJMS HTTPトンネル・プロバイダ・サーブレットを通過する場合にのみ使用されます。絶対パスをお薦めします。 |
|
|
この属性はキーストアのパスワードです。keystore属性が指定されている場合には、この属性は必須です。 |
|
|
この属性には、トラストストアの名前およびパスが含まれます。トラストストアを指定しない場合、OC4Jではキーストアがトラストストアとして使用されます。トラストストアは、SSLを使用してJMS HTTPトンネル・プロバイダ・サーブレットを通過する場合にのみ使用されます。絶対パスをお薦めします。 |
|
|
この属性はトラストストアのパスワードです。truststore属性が指定されている場合には、この属性は必須です。 |
|
|
この属性は、JavaセキュリティAPIに |
次の例では、JNDIロケーションjms/SomeQCFでルックアップされるOEMS JMSのQueueConnectionFactoryを作成します。JMS接続の作成に使用される場合、接続は、ホストjmstunnelhostに存在するSSL以外のHTTPトンネルを通過します。
<queue-connection-factory
name="jms/SomeQCF"
location="jms/SomeQCF"
host="server1.abc.com" port="9127"
tunnel="http://jmstunnelhost:8888/jms"/>
次の例では、JNDIロケーションjms/AnXaTCFでルックアップされるOEMS JMSのXATopicConnectionFactoryを作成します。JMS接続の作成に使用される場合、keystoreおよびkeystore-passwordが有効であれば、接続は、ホストserver1.xyz.comに存在するSSLのHTTPSトンネルを通過します。
<xa-topic-connection-factory
name="jms/AnXaTCF"
location="jms/AnXaTCF"
host="server1.xyz.com" port="2000"
tunnel="https://server1.xyz.com:4443/jms"
keystore="/location/of/keystore"
keystore-password="keypass"/>
OEMS JMSのメモリー内およびファイル・ベースのオプションでは、識別子（メッセージIDなど）が一意である必要があります。識別子の一部は、JMSサーバーおよびクライアントのマシンのホスト名から構成されます。同じJMSサーバーと通信している異なる2つのマシンのホスト名が同一である場合、IDは一意ではなくなり、JMSの機能が予期したとおりに機能しない可能性があります。
たとえば、イントラネットAのJMSクライアントAで、イントラネットBのJMSサーバーへのアクセスにJMS HTTPトンネル・プロバイダを使用していて、イントラネットBのJMSクライアントBもそのJMSサーバーにアクセスしている場合、JMSクライアントAが稼働しているマシンのホスト名は、JMSクライアントBが稼働しているマシンのホスト名とは異なる必要があります。2つのイントラネットへの接続にJMS HTTPトンネリングが使用されている場合、これらのイントラネットの管理者は、ホスト名の競合を避けるためにそれぞれを調整する必要があります。
|
注意: 同じマシン（つまりホスト名が同じ）の同一または異なるJVMで2つ以上のJMSサーバー（またはJMSクライアント、あるいはその両方）が稼働していても、JVM全体および個々のJVM内で一意のIDが生成されるため特に問題はありません。ホスト名の競合は、2つの異なるマシンに同じホスト名がある場合にのみ問題になります。 |
この項では、JMS固有のロギングを構成するための様々なオプションを説明します。OEMSはOC4Jロギング実装を使用して、JMSに関連するメッセージを記録します。通常、メッセージは、問題のトラブルシューティングや診断に使用されます。OC4Jロギングはデフォルトの設定を使用するように構成されます。ただし、これらの設定をJMS用に変更して、さらに詳細なログ・メッセージを取得できます。OC4Jロギング実装の詳細は、『Oracle Containers for J2EE開発者ガイド』を参照してください。
標準のJMS機能のトレースに使用可能なログ出力は2つあります。それらのログ出力は次のとおりです。
oracle.j2ee.jms: 基本的なJMSロギングに使用
com.evermind.server.jms.JMSServer: 主なJMSサーバー・クラスからの高度なJMSサーバー・レベルのロギングに使用
標準のJMSログ出力は、J2EE_HOME/config/j2ee-logging.xmlファイルに構成されます。たとえば、高度なサーバー・レベルのロギングを構成し、ログ・レベルをFINESTに設定するには、次のログ出力ノードを追加します。
<loggers>
...
<logger name='com.evermind.jms.JMSServer' level='FINEST'
useParentHandlers='false'>
<handler name='oc4j-handler'/>
<handler name='console-handler'/>
</logger>
<loggers>
この例では、ログ出力からのメッセージは、oc4j-handlerおよびconsole-handlerログ・ハンドラでの指定どおりに出力に送信されます。
com.evermind.server.jmsログ出力は、OEMS JMSファイル全体の永続性プロバイダ実装のログ情報を取得するために使用されます。JMSプロバイダのログ出力は、J2EE_HOME/config/j2ee-logging.xmlファイルに構成されます。たとえば、ログ出力を構成してログ・レベルをFINESTに設定するには、次のログ出力ノードを追加します。
<loggers>
...
<logger name='com.evermind.jms' level='FINEST'
useParentHandlers='false'>
<handler name='oc4j-handler'/>
<handler name='console-handler'/>
</logger>
<loggers>
この例では、ログ出力からのメッセージは、oc4j-handlerおよびconsole-handlerログ・ハンドラでの指定どおりに出力に送信されます。
JMSコネクタを使用する際には、すべてのコネクタのログ出力を設定するオプションと、各コネクタのログ出力を設定するオプションがあります。
すべてのコネクタ
oracle.j2ee.ra.jms.genericログ出力は、すべてのコネクタに対して使用します。ログ出力は、J2EE_HOME/config/j2ee-logging.xmlファイルに構成されます。たとえば、ログ出力を構成してログ・レベルをFINESTに設定するには、次のログ出力ノードを追加します。
<loggers>
...
<logger name='oracle.j2ee.ra.jms.generic' level='FINEST'
useParentHandlers='false'>
<handler name='oc4j-handler'/>
<handler name='console-handler'/>
</logger>
<loggers>
この例では、ログ出力からのメッセージは、oc4j-handlerおよびconsole-handlerログ・ハンドラでの指定どおりに出力に送信されます。
各コネクタ
ログ出力は各コネクタに構成し、そのコネクタに関する特定のメッセージを指定できます。ログ出力は、J2EE_HOME/config/oc4j-connectors.xmlファイル、またはra.xmlファイルに構成されます。例:
<config-property> <config-property-name>loggerName</config-property-name> <config-property-type>java.lang.String</config-property-type> <config-property-value>mylog</config-property-value> </config-property> <config-property> <config-property-name>logLevel</config-property-name> <config-property-type>java.lang.String</config-property-type> <config-property-value>FINEST</config-property-value> </config-property>
ログ・レベルは、LogLevel構成プロパティを使用して、特定のメッセージ・エンドポイント用に調整できます。本番コードでは、このプロパティは設定しないでください。デバッグ目的で一時的にのみ設定してください。
このプロパティは、<message-driven-deployment>ノード内のorion-ejb-jar.xmlファイルに追加されます。例:
<enterprise-beans>
<message-driven-deployment ... >
...
<config-property>
<config-property-name>LogLevel</config-property-name>
<config-property-value>FINEST</config-property-value>
</config-property>
</message-driven-deploymnet>
</enterprise-beans>
|
注意: LogLevelプロパティは、ejb-jar.xmlファイルにも設定できます。構成プロパティの使用方法の詳細は、「MDBエンドポイントの微調整」を参照してください。設定できる有効なログ・レベルの詳細なリストは、表4-11「MDBの構成プロパティ」のLogLevelエントリを参照してください。 |
この項では、oracle.j2ee.jms実装を使用するための情報を提供します。この項には、次の項目が含まれます。
oracle.j2ee.jms実装はOC4J JMSをほぼ完全に設計および作成しなおしたもので、パフォーマンスが大幅に向上しました。oracle.j2ee.jms実装の使用はオプションで、使用するには有効にする必要があります。oracle.j2ee.jms実装の有効化の詳細は、「oracle.j2ee.jms実装の有効化」を参照してください。
新機能
oracle.j2ee.jms実装には、次の新機能があります。
ユーザー可視化機能
単一のサブスクリプションでの複数のサブスクライバ（アプリケーション・スケーリングの支援）
接続リークの検出
信頼性
電源の遮断が原因で、進行中の書込みの対象セクターが読取り不可能になった場合も、データを損失することなくリカバリ（それ以降の読取り操作は失敗する）
ディスクで検出されない場合も、部分セクター書込みを検出
同時実行のパフォーマンス
最小限の内部ロック
1タスク1スレッド・モデルを使用しない（つまり、存在するスレッドより多数のアクティブなJMS操作をサポート可能。少数のスレッドだけを使用して数千の同時操作に容易にスケーリング）
1つのリソースが飽和するまで、パフォーマンスはワークロードの同時実行性を維持してスケーリングされる
ネットワーク・パフォーマンス
単一のTCP接続上で複数のJMS接続が動作
バッチ送信
バッチ受信
送信インタリーブにより、小規模メッセージのブロックを防止
不必要なサーバー・ラウンド・トリップの防止
受信者は定期ポーリングでなく登録を使用
ファイル・パフォーマンス
単一の永続性ファイル
バッチ書込み
バッチ読取り
読取りの並べ替え
高い同時実行性の使用例では、永続的メッセージのパフォーマンスが、OC4J JMSのメモリー内メッセージングのパフォーマンスに匹敵するか上回る
一般パフォーマンス
メモリー低消費メッセージ（メモリー内、ディスク状、ネットワーク経由）
コンシューマのメッセージ・セレクタに適合しないメッセージの再スキャンを回避
不必要なメッセージのシリアライゼーションやシリアライゼーション解除の回避
不必要なメッセージのコピーや複製の回避
送受信のみでなく、すべてのJMS操作を最適化
制限事項
oracle.j2ee.jms実装には、次の制限があります。
oracle.j2ee.jms実装は、JDK 1.5以上でのみ使用できます。
oracle.j2ee.jms実装が有効化されている場合、JMSメッセージ・ルーターは使用できません。
Oracle DMSメトリックは、oracle.j2ee.jms実装に使用できません。
jms.xmlファイルの移行
oracle.j2ee.jms実装では、jms.xmlファイル用の新しいXMLスキーマを使用します。初めてoracle.j2ee.jms実装を使用してOC4Jを起動すると、jms.xmlファイルが、古い形式から新しい形式に自動的に移行されます。反対方向の移行は自動では行われません。OC4J JMSを実行する状態に戻したい場合は、手動でjms.xmlファイルをリストアする必要があります。このため、OC4J JMSからoracle.j2ee.jms実装に移行する場合、oracle.j2ee.jms実装を使用してOC4Jを起動する前に、jms.xmlファイルのバックアップ・コピーを作成することをお薦めします。
メッセージの移行
jms.xmlファイルを移行するとコネクション・ファクトリと宛先も移行されますが、メッセージの自動移行機能はありません。oracle.j2ee.jms実装では、OC4J JMSの永続性ファイルを使用できません。oracle.j2ee.jms実装用に永続性ファイルを構成する場合、OC4J JMSによって作成されたファイルを使用しないでください。
OC4J JMSからoracle.j2ee.jms実装にメッセージを移行する必要がある場合、JMSメッセージ・ルーターを使用することもできます。ジョブ・ソースがOC4J JMSのコネクション・ファクトリと宛先で、ジョブ宛先がoracle.j2ee.jms実装のコネクション・ファクトリと宛先になるようにルーター・ジョブを構成します。OC4Jは一度に1つのバージョンのOC4J JMSのみ実行できるため、この方法では、OC4J JMSを使用するように構成したOC4J JVM（およびメッセージを含むOC4J JMS永続性ファイル）と、oracle.j2ee.jms実装を使用するように構成したOC4J JVMの、2つのOC4J JVMを実行する必要があります。JMSメッセージ・ルーターは、OC4J JMSを実行しているOC4Jインスタンス上で構成する必要があります。トピックに複数のサブスクリプションがある場合は、この方法をトピック・メッセージの移行に適用できません。どのサブスクリプションがどのメッセージを受信しているかに関する情報が維持されないためです。
永続サブスクリプションの移行
永続サブスクリプションは移行されません。永続サブスクリプションは、そのサブスクリプションがOC4J JMS永続性ファイル内に存在するかどうかに関係なく、アプリケーションがその永続サブスクリプションのサブスクライバを最初に作成するときに、oracle.j2ee.jms実装永続性ファイルに作成されます。サブスクリプションは、その時点より前にパブリッシュされたいかなるメッセージも受信しません。
ネットワークの相互運用性
oracle.j2ee.jms実装は本質的に新しいJMSプロバイダであり、OC4J JMSと相互運用できません。つまり、oracle.j2ee.jms実装を使用するJMSクライアントは、OC4J JMSと通信することができません。同様に、OC4J JMSを使用するJMSクライアントは、oracle.j2ee.jms実装と通信することができません。
JMSルーターの互換性
JMSルーターは、ロギング・キューの操作を、OC4J JMSの内部詳細に依存しています。このため、JMSルーターをoracle.j2ee.jms実装で使用することはできません。
ただし、OC4J JMSを実行しているOC4JでJMSルーターを使用している場合、TibcoやSonicなどサード・パーティのJMSプロバイダに対するメッセージのルーティングのためにJMSルーターを使用するのと同じ方法で、oracle.j2ee.jms実装のメッセージに対するメッセージのルーティングのためにJMSルーターを使用することができます。
OC4Jが起動する場合、OC4J JMSとoracle.j2ee.jms実装のいずれかを使用できます。OC4Jでは、両方の実装を同時に使用することはできません。
|
警告: oracle.j2ee.jms実装を実行するとjms.xmlファイルが変更され、その変更を元に戻すことはできません。oracle.j2ee.jms実装を有効化する場合、あらかじめ「jms.xmlファイルの移行」の項を一読し、理解しておくことが重要です。 |
oracle.j2ee.jms実装を有効化するには、OC4Jを起動する際に、次のシステム・プロパティを設定します。
-Doc4j.jms.implementation=oracle.j2ee.jms
このプロパティは、OC4JサーバーJVMにのみ設定する必要があります。クライアントJVMに設定する必要はありません。
|
注意: oracle.j2ee.jms実装のためのコードは、oracle.j2ee.jms.*パッケージ階層内にあり、OC4J JMSのためのコードは、com.evermind.server.jms.*パッケージ階層内にあります。このことを利用して、どの実装が使用されているかを検証できます（コネクション・ファクトリ、宛先、接続、セッションなどのJMSオブジェクトのいずれかで.getClass().getName()を実行するか、例外またはスレッド・ダンプでスタック・トレースを検査します）。 |
この項では、OC4J JMS（「OEMS JMSのメモリー内およびファイル・ベースの永続性」を参照）と、oracle.j2ee.jms実装の間の相違点の概要を説明します。この後の項名は、この章の項名を参照しているため、関連を容易に把握できます。引用元も参照先の項です。それぞれの引用に続くテキストは、oracle.j2ee.jms実装がどのように異なるかを説明しています。
"配信できないメッセージ用の例外キューの提供。"
oracle.j2ee.jms実装には、例外キューが用意されていません。MDBの場合、JMSコネクタ例外キュー機能を使用できます。表4-11「MDBの構成プロパティ」にある、MaxDeliveryCntプロパティの説明を参照してください。
"XA（グローバル・トランザクション対応）、非XA、および様々なJMSインタフェースの異なる組合せに対して、6つのデフォルト・コネクション・ファクトリが作成されます。"..."次のデフォルトのコネクション・ファクトリが作成されます（jms.xmlファイルで明示的に定義していない場合でも作成されます）。"...（など。）oracle.j2ee.jms実装は、いかなるデフォルト・コネクション・ファクトリも作成しません。希望するコネクション・ファクトリはすべて、明示的に構成する必要があります。jms.xmlファイルを移行する場合、これらの6つのコネクション・ファクトリのための明示的な構成が、新しいjms.xmlファイルに追加されます。
oracle.j2ee.jms実装は、いかなるデフォルト宛先ストアも作成しません。希望する宛先ストアはすべて、明示的に構成する必要があります。jms.xmlファイルを移行する場合、前述の宛先が既存のjms.xmlファイルですでに定義されていれば、それらは他の宛先とまったく同様に新しいjms.xmlファイルに移行されます。
Application Server Controlコンソールでの構成
oracle.j2ee.jms実装のためのApplication Server Controlコンソールの構成オプションは、非常にかぎられています。OC4Jサーバーがシャットダウンされている場合、oracle.j2ee.jms実装MBeanを使用するか、直接jms.xmlを構成することをお薦めします。MBeanの詳細な説明は、「oracle.j2ee.jms実装MBeanの使用」を参照してください。
Application Server Controlコンソールの使用に関する制限は、次のとおりです。
「JMS宛先」ページは、宛先を作成または削除するためにのみ使用できます。宛先の監視はできません。宛先作成機能では、新しいプロバイダに対して使用できるオプション属性をユーザーが指定することができません。オプション属性を指定する必要がある場合は、新しいJmsConfigResource MBeanを使用して宛先を作成することをお薦めします。
「JMSコネクション・ファクトリ」ページは、コネクション・ファクトリを作成、変更、または削除するために使用できます。ただし、ユーザー名属性とパスワード属性はoracle.j2ee.jms実装に適用されません。
「メモリー内およびファイル・ベースの永続性」ページは使用できません。
「OracleAS JMS Router」ページは使用できません。
oracle.j2ee.jms実装のjms.xmlスキーマは、次の2つのノードで構成されています。
<oc4j-jndi-bindings>: このノードでは、OC4J JNDIにバインドされるOC4J JMSオブジェクトを指定します。宛先バインディングとコネクション・ファクトリ・バインディングの、2つのタイプのオブジェクトがあります。宛先バインディング<destination-binding>は、名前付きの宛先を固有のJNDIロケーションにバインドします。この宛先は、ローカルのOC4J JMS jms.xml上、またはリモートのOC4J JMSサーバー（専用JMSサーバー・トポロジの場合）で、<destination>要素として定義される必要があります。ファクトリ・バインディング<factory-bindings>は、JMSコネクション・ファクトリを、固有のJNDIロケーションに定義します。
<server>: このノードは、JMSサーバーの動作（ポート設定、有効化など）、およびJMS宛先の定義を制御します。サーバー要素で定義された宛先は、メッセージの物理ストレージを表し、いくつかのオプション属性を含んでいるため、アクションによって配信モードの上書き、削除ポリシーの設定などを行うことができます。
要素/属性を記したサンプルのjms.xmlを次に示します。
<jms>
<oc4j-jndi-bindings>
<!-- destination-binding, location, type, and name are required -->
<destination-binding
location="jms/myTopic"
type="Topic"
name="myTopic" />
<!-- factory-binding, location and type are required -->
<factory-binding
location="jms/myTopicFactory"
type="TopicConnectionFactory"
name="myName"
url="tcp://host:port"
clientID="myid" />
</oc4j-jndi-bindings>
<server host="host" port="9127">
<!-- destination, name and type are required -->
<destination
name="myTopic"
type="Topic"
deliveryModeOverride="PERSISTENT | NON-PERSISTENT"
trueDeliveryModeVisibleToReceiver="true | false"
durableSubscriptionsPersistent="true | false" >
</server>
</jms>
概要:
<server>属性:
host: このサーバーがバインドされる、Stringで定義されるホスト名です。デフォルトで、サーバーは0.0.0.0にバインドされます。
port: JMSサーバーがバインドされるポート番号。デフォルト値は、9127です。
enable: enableがfalseに設定されている場合、JMSサーバーは起動せず、使用できません。
enablePort: enablePortがtrue（デフォルト）に設定されている場合、JMSクライアントのリスニング・ポートは有効です。falseの場合、JMSクライアント・リスナー・ポートは開始されません。
persistenceLocation: jms.dat永続性ファイルの場所（オプション）。persistenceLocation属性に指定されるパスは、ファイルの絶対パスか、OC4Jインスタンスが起動された場所に対する相対パスです。指定しない場合、OC4Jインスタンスのapplication.xmlで定義されるpersistenceディレクトリが使用されます。
autoCreatePersistenceFile: falseに設定すると、ファイルがまだ存在しない場合に、永続性ファイルが自動作成されなくなります。この設定にすると、永続性ファイルの場所が相対指定で、OC4J JMSが実行されるプロセスが、異なる現行ディレクトリで誤って起動された場合に、不要な永続性ファイルが作成されなくなります。デフォルト値はtrueです。
<destination-binding>属性:
location: JMS宛先をバインドするOC4J JNDIロケーションを指定する必須属性。
type: JMS宛先タイプを、QueueとTopicのいずれかに指定する必須属性。
name : OC4J JMS宛先名を指定する必須属性。この名前は、JMSサーバーで定義される<destination>のname属性に対応している必要があります。
<factory-binding>属性:
location: OC4J JMSコネクション・ファクトリのOC4J JNDIバインディングを定義する必須属性。
name: OC4J JMSコネクション・ファクトリの名前を定義するオプション属性。
type: JMSコネクション・ファクトリ・タイプを指定する必須属性は、ConnectionFactory、QueueConnectionFactory、TopicConnectionFactory、XAConnectionFactory、XAQueueConnectionFactoryまたはXATopicConnectionFactoryのいずれかである必要があります。
url: このバインディング用にJMSサーバーの固定アドレスを指定するオプション属性。tcp://host:portという形式である必要があります。hostとportにより、固有JMSサーバーを指定します。この属性を指定しない場合、ローカルのJMSサーバーとみなされます。
clientID: このコネクション・ファクトリから作成される接続に対して、管理のために構成された固定JMS clientIDを指定するオプション属性。
<destination>属性:
name : 宛先の名前を定義する必須属性。
type: 宛先のJMSタイプを定義する必須属性。QueueとTopicのいずれかである必要があります。
deliveryModeOverride: この宛先にエンキューされているメッセージのためのオプションのオーバーライド。PERSISTENTに設定すると、宛先にエンキューされたすべてのメッセージが、ファイルに永続化されます。NON-PERSISTENTに設定すると、宛先にエンキューされたすべてのメッセージが、ファイルに永続化されません。指定しない場合、宛先にエンキューされたメッセージは、ファイルに永続化されるか、メッセージの配信モードのプログラム的な設定に基づかないかのいずれかです。
trueDeliveryModeVisibleToReceiver: デフォルトはfalseです。falseに設定すると、メッセージのコンシューマに対して表示されるdeliveryModeは、deliveryModeOverrideの設定やメッセージの実際の配信モードに関係なく、メッセージのプロデューサが設定したモードに一致します。trueの場合、メッセージのコンシューマに対して表示される配信モードは、deliveryModeOverrideによって配信モードが変更された場合を含め、メッセージの実際の配信方法に一致します。
durableSubscriptionsPersistent: デフォルトはtrueです。trueに設定すると、永続サブスクリプションはディスクにバックアップされ、JMSサーバーが再起動されても存続し、該当するメッセージ（JMS仕様による）をすべて蓄積します。falseに設定すると、永続サブスクリプションはメモリーにバックアップされ、JMSサーバーが再起動されると存続しません。JMSサーバーの再起動前に蓄積されたメッセージは失われ、JMS再起動後、アプリケーションにより永続サブスクリプションが再作成される前にパブリッシュされたメッセージは蓄積されません。非永続サブスクライバと異なるのは、対応するサブスクライバがクローズされても破棄されない点です。
evictionPolicy: オプション。削除ポリシーがneverの場合、キャッシュ済メッセージはメモリーから削除されません。キャッシュ済メッセージは、破棄されるまで（完全に消費されるか、期限が切れるか、サブスクリプションが破棄されるまで）メモリーを消費します。このポリシーでは、送信されたメッセージは必要になるまでメモリー内に残ります。使用例によっては、これが最高のパフォーマンスをもたらします。ただし、JVMのメモリーが不足すると、キャッシュ済メッセージを破棄できなくなり、OutOfMemoryErrorをスローすることがあります。その場合、通常はサーバーが動作を継続できなくなります。削除ポリシーがsoftRefの場合、完全に永続的なキャッシュ済メッセージ（その時点で送信中/トランザクション中/消費中/参照中でないもの）は、java.lang.ref.SoftReference経由でのみ維持されます。これにより、JVMは、キャッシュ済メッセージにより消費されたメモリーを再利用することができます。この方法で削除されたメッセージは、必要に応じてディスクからロードされる必要があるため、パフォーマンスが低下することがあります。JVMの中には、ソフト参照経由で維持されるオブジェクトを積極的に削除するものもあります。ただし、キャッシュ済のアイドル・メッセージがある状態でJVMのメモリーが少なくなった場合、JVMには、キャッシュ済メッセージを破棄して、メモリー不足によるサーバー障害を回避するオプションもあります。
スタンドアロンのOC4Jインスタンスでは、JmsConfigResource MBeanのchangeServerAttribute操作を使用して、oracle.j2ee.jms実装ポート値を設定できます。oracle.j2ee.jms実装サーバー・ポートを変更すると、JMSサーバーは強制的に再起動されます。
管理対象となっているOracle Application Server環境では、Application Server Controlコンソールを使用してポート範囲を構成します。
Application Server Controlコンソールでポート範囲を構成する場合のパス:
「OC4J: ホーム」→「管理」タブ→「タスク名: JVMプロパティ」→「JMSポート」
oracle.j2ee.jms実装には、ランタイム構成のためのコマンドライン・ユーティリティは用意されていません。次に説明する新しいJMS MBeanを使用してください。
oracle.j2ee.jms実装には、JmsConfigResourceとJmsOperationsMBeanの2つのJMX MBeanが用意されています。MBeanの操作の詳細な説明は、「oracle.j2ee.jms実装MBeanの使用」を参照してください。
JmsConfigResource MBean: JmsConfigResource MBeanには、oracle.j2ee.jms実装の構成を変更する操作が用意されています。JmsConfigResource MBeanには、Application Server Controlコンソールを使用して、次のパスでアクセスできます。
「OC4J: ホーム」→「管理」タブ→「タスク名: JMX」→「システムMBeanブラウザ」→「タスクに移動」→「J2EEDomain:oc4j」、「J2EEServer:standalone」、「JmsConfigResource」、「JmsConfig」→「操作」タブにドリルダウン
JmsOperationsResource MBean : このBeanは、トピック・サブスクリプションの作成、削除および監視のためのランタイム操作を提供します。JmsOperationsResource MBeanには、Application Server Controlコンソールを使用して、次のパスでアクセスできます。
「OC4J: ホーム」→「管理」タブ→「タスク名: JMX」→「システムMBeanブラウザ」→「タスクに移動」→「J2EEDomain:oc4j」、「J2EEServer:standalone」、「JmsOperationsResource」、「JmsOperations」→「操作」タブにドリルダウン
"OC4Jがアクティブではないときに、永続性ファイルを削除すると、その永続性ファイルに関連付けられている宛先からすべてのメッセージおよび永続サブスクリプションが削除されます。"
oracle.j2ee.jms実装の場合、すべての宛先が単一の永続性ファイルに保存されるため、そのファイルを削除すると、すべての宛先にあるすべてのメッセージと永続サブスクリプションが削除されます。
"各宛先は、宛先オブジェクトに送信されたメッセージを格納するためのファイルを指し示す相対または絶対パス名に関連付けることができます。"
oracle.j2ee.jms実装の場合、すべての宛先が単一の永続性ファイルに保存されます。JMSサーバーごとに永続性ファイルは1つだけ存在します。
Application Server Controlコンソールで宛先の永続性ファイルを指定する場合のパス:
oracle.j2ee.jms実装の場合、永続性ファイルのパスは、JmsConfigResource MBeanのchangeServer属性操作を使用して指定できます。
"persistence-file属性のパスは、ファイルの絶対パス、またはapplication.xmlに定義されているpersistenceディレクトリに対する相対パスです。"
oracle.j2ee.jms実装の場合、永続性ファイルへのパスは、サーバーのpersistenceLocation属性によって決定されます。
"java.io.FileDescriptor.sync()の失敗"
oracle.j2ee.jms実装では、java.io.FileDescriptor.sync()ではなくjava.nio.channels.FileChannel.force(true)（永続性ファイル・サイズが変更された場合）または、java.nio.channels.FileChannel.force(false)（永続性ファイル・サイズが変更されない場合）を使用しますが、原則は同じです。具体的には、forceのコールは、データがファイルに書き込まれた後、forceが物理メディア（ディスクにバッテリでバックアップされた書込みキャッシュがない場合）またはディスクのキャッシュ（ディスクにバッテリでバックアップされた書込みキャッシュがある場合）に到達する前に戻すことはできません。
次の情報は、oracle.j2ee.jms実装に固有のものです。
書込みはすべて512バイト単位に揃えられ、整数個の連続した512バイト・ブロックから構成されます。大部分の回転ディスクは、512バイトのセクターを備えています。この項では、「セクター」という用語を「512バイト単位で揃えられた512バイト・ブロック」という意味で使用し、「物理セクター」という用語を「RAWデバイス・ブロック・サイズ」を指す言葉として使用します。
次のものはデータの整合性のために必要ありません。
ファイル・システムとディスクは、書込み操作が発行された順序、または個々の書込み内でのセクターの順序に従ってセクターを書き込む必要はありません。つまり、ファイル・システムとディスクは、パフォーマンスを向上させるために、セクターの書込み順序を自由に変更（またその合間に読取りを挿入する）ことができます。前述のように、forceに関する順序だけは必須です。
ファイルが大きくなっても、ファイル・システムは新しいファイル領域をゼロで埋める必要はありません（ただし、セキュリティ上の理由でそうすることを選択してもかまいません）。
ファイルが小さくなっても、ファイル・システムは開放されたセクターをゼロで埋める必要はありません（冗長にはなりますが、セキュリティ上の理由でそうすることを選択してもかまいません）。メッセージ・データが不正ユーザーに漏洩するのを防止するために、新しいOC4J JMSでは、ファイルを小さくする前に、解放されるセクターを常にゼロで埋めます。
データの整合性を確保するために、oracle.j2ee.jms実装は、不完全なセクター書込みを検出できる必要があります（たとえば、書込み操作中に電力が遮断された場合）。そのために、ディスクで、次のうち少なくとも1つの保証が提供されている必要があります。
保証オプション#1: バイト順序
いずれのセクターの書込みも、常に最初のバイトから最後へ、または最後のバイトから最初へという順に実行されます。
この順序保証がある場合、oracle.j2ee.jms実装によって各セクターに埋め込まれたヘッダー/フッターを使用して、不完全なセクター書込みを検出できます。通常、回転ディスク（物理セクター・サイズが512バイト以上のもの）には、この順序保証があります。
保証オプション#2: 書込み障害検出
障害時のいかなるセクター書込みも、次の3つの結果のいずれかになることが保証されます。
書込みがまったく反映されない。
書込みが正常に完了する。
書込みが開始され、完全には完了しないが、ドライブがそれを検出でき、そのセクターの読取り試行をすべて失敗させる（java.nio.channels.FileChannel.readで例外がスローされる）。
この書込み失敗検出保証がある場合、oracle.j2ee.jms実装は、スローされた例外を使用して、不完全なセクター書込みを検出できます。
保証オプション#3: 原子セクター書込み
障害時のいかなるセクター書込みも、次の2つの結果のいずれかになることが保証されます。
書込みがまったく反映されない。
書込みが正常に完了する。
この原子セクター書込み保証がある場合、oracle.j2ee.jms実装で検出される必要がある不完全セクターは決して存在しません。電力が回復するまで書込みキャッシュ内容を維持するため、または電力の回復を待たずに保留中の書込みを完了するためのバッテリ（またはキャパシタ）を備えたディスクには、一般に原子セクター書込み保証があります。
SSD（Solid State Disk）では、バイト順序保証が提供されません。前述のバッテリー/キャパシタ機能の1つを備えていないSSDには、書込み障害検出か、原子セクター書込み保証が用意されていることがあります。現在、そのようなSSDで提供されるそれらの保証は、一般に確率的な保証にとどまります（たとえば、エラーの検出確率が特定のパーセントしかないECCチェックの使用）。また、ECC信頼性の数字は通常、ビット・エラーが少数である事例のためだけに提供されているものであり、不完全なセクター書込みによりビット・エラーが多数ある事例（検出失敗の確率が何桁も大きくなる）では有効ではありません。
oracle.j2ee.jms実装では、永続性ファイルは、必要に応じて大きくなりますが、状況が許せば（非常に緩慢に）小さくなります。データの整合性を確保するため、ファイルの存在や、それらのファイルに割り当てられるディスク領域を記録するために使用されるファイル・システム・メタデータは、障害がメタデータ更新の際に発生する場合も含め、障害（たとえば電源の遮断）に対するリジリエンスを備えている必要があります。
oracle.j2ee.jms実装は、ライブ・データを含むセクターを決してリライトしません。たとえば、メッセージのJMSXDeliveryCountが更新される場合、現行のJMSXDeliveryCountを含むセクターはリライトされません。そのかわり、新しいセクターに、特定のメッセージのJMSXDeliveryCountの新しい値を（場合によっては、他に優先して）記録します。その非常に重要な理由の1つは、セクターをリライトすると、そのセクターのすべてのデータが危険にさらされるということです。たとえば、あるメッセージの送信がすでにコミットされ、受信中に、そのJMSXDeliveryCountを更新するために、そのメッセージを含むセクターがリライトされ（これはあくまで仮定であり、oracle.j2ee.jms実装はライブ・データを決して上書きすることはありません）、そのリライト中に電源が遮断されたとすると、メッセージの全体（およびそのセクター内の他のデータすべて）が完全に破損して、回復不可能になる可能性があります。
oracle.j2ee.jms実装はライブ・データを含むセクターをリライトしませんが、ライブ・データを含むセクターをリライトするものが他にないということも、同様に重要です。特に、一部のファイル・システムでは、セクターがファイル・システムにリライトされなかった場合も、それらのセクターをディスクにリライトします。これは通常、read-modify-writeと呼ばれています。たとえば、oracle.j2ee.jms実装がセクター#Nに書き込む場合、そのようなファイル・システムではセクター#N-3〜#N+4を読み取ることができます。それらのセクターの大部分はoracle.j2ee.jms実装によって書き込まれませんが、その後forceがコールされたとき、このファイル・システムによりすべてのセクター（#N-3〜#N+4）に書き込まれることがあります。この場合、ディスク帯域幅を浪費し、oracle.j2ee.jms実装がアクセスを試みなかったセクターも読み書きすることでパフォーマンスが低下するだけでなく、ライブ・データが潜在的な危険にさらされます。
データの整合性を確保するには、そのようなファイル・システムを使用しないでください（そのようなファイル・システムを使用する必要がある場合、バッテリでバックアップされたディスクを使うことで、read-modify-writeによるリスクを、完全にはなくせませんが、低下させることができます。ファイル・システム・ブロック・サイズを512バイト近くまで減らすことができれば、read-modify-writeがパフォーマンスに与える影響だけでなく、そのリスクも減少します）。
また、物理セクター・サイズが512バイトより大きいディスクは、通常、read-modify-write操作を実行する必要があります。データの整合性を確保するには、そのようなディスクは、バッテリでバックアップされる必要があります。
パリティを使用するRAIDシステムも、通常、read-modify-write操作を実行する必要がありますが、システムの使用とその運用方法によって、read-modify-writeがデータの整合性に影響を及ぼすことも、及ぼさないこともあります。これはこのマニュアルで扱う範囲外の内容です。
"コピー: 既存の永続性ファイルをアーカイブまたはバックアップのためにコピーできます。既存の永続性ファイルが破損した場合に、（OEMS JMSの宛先名とファイル間の関連付けが維持されていれば）適切なパス名によって示される以前のバージョンを使用して、JMS宛先の以前の内容に戻すことができます。"
JMSサーバーごとに永続性ファイルは1つだけ存在するため、宛先とファイルの間に関連付けがないことを除いて、これはoracle.j2ee.jms実装の場合にも当てはまります。ただし、トランザクション・マネージャのデータ（およびXAトランザクションに含まれる他のすべてのリソースのデータ）を旧リリースにリストアしないでoracle.j2ee.jms実装の永続性ファイルを同じ時点にリストアする場合、XAトランザクションの不整合性が存在する可能性がある点に注意してください。JMS永続性ファイルだけをリストアすると、トランザクション・マネージャは、トランザクションがもともとコミットされている場合も（また、他のトランザクションについてJMS以外のリソースがまだコミットされている場合も）、情報がなくなったJMSからのリカバリ対象トランザクションをすべてロールバックする可能性があります。
"OEMS JMSのメモリー内およびファイル・ベースのオプションでは、内部構成およびトランザクション状態管理のために、ユーザー指定の永続性ファイルとロック・ファイルに加えて特殊ファイルjms.stateが使用されます。OEMS JMSサーバーは、通常の操作中にこのファイルとその内容をクリーン・アップします。アーカイブを目的とする場合でも、このファイルは削除、移動、コピーまたは変更しないでください。jms.stateファイルを操作すると、メッセージとトランザクションが消失する可能性があります。"
oracle.j2ee.jms実装の場合、個別のjms.stateファイルがありません。単一の永続性ファイルだけが存在します。
OC4Jが正常終了すると、ロック・ファイルが自動的にクリーン・アップされます。ただし、（kill -9コマンドなどにより）OC4Jが異常終了すると、ロック・ファイルはファイル・システムに残ります。
oracle.j2ee.jms実装では.lockファイルは使用されません。そのかわりにファイル・システム・ロックを使用します。このため、クリーン・アップする.lockファイルは1つもありません。
"サーバーは停止されるか、またはリカバリに成功するまで繰り返し再起動されます。"
oracle.j2ee.jms実装では、通常、何度も再起動する必要はありません。ファイルがリカバリ可能な場合、oracle.j2ee.jms実装は1回目の試行でリカバリします。（唯一の例外は、正常な起動に、使用可能量を超えるヒープ・メモリーが必要であるために、OutOfMemoryErrorになる場合です。その場合、より大量のヒープを持つようにJVMを構成してから再試行してください。）
"異常終了時にメッセージ・アクティビティが進行中だった場合、OEMS JMSは、永続性ファイルのリカバリを試行します。データの（前述したタイプの）破損は、破損データのクリーン・アウトにより処理されますが、これによりメッセージとトランザクションが消失する可能性があります。"
oracle.j2ee.jms実装では、正常にコミットされたライブ・データ（または、正常に準備されたがロールバックされなかったライブ・データ）が消去されることはありません。異常終了時に操作が進行中で、その操作がディスクに完全には書き込まれていない場合、その操作は、次の起動の際に、自動的にロールバックされます（たとえば、永続的なメッセージの受信を含むXAトランザクションが、正常に準備されたがコミットされず、コミット操作中に電力が遮断されて、コミット記録がディスクに完全には書き込まれなかった場合、次回の起動時に、不完全コミットの記録が削除され、XAトランザクションは準備済の状態に戻ります。トランザクションは、その後トランザクション・マネージャがコミットを再発行したときにコミットされます。他方、電力が準備操作中に遮断されて準備記録がディスクに完全には書き込まれなかった場合、次回起動時にトランザクション全体が自動的にロールバックされ、メッセージは再度、受信される準備が完了した状態になります）。
"永続性ファイルのヘッダーが破損すると、この種の破損ファイルはユーザー構成エラーと区別できないことが多いため、OEMS JMSではファイルをリカバリできなくなる場合があります。oc4j.jms.forceRecovery管理プロパティ（表4-6「システム・プロパティ」を参照）を使用すると、（メッセージの消失やユーザー構成エラーの隠蔽というデメリットはありますが）無効なデータをすべて消去してリカバリを続行するようにJMSサーバーに指示できます。"
oracle.j2ee.jms実装で、永続性ファイルの破損が構成エラーと混同されることはありません（唯一の例外は、実際の永続性ファイル以外の場所を参照するjms.xml）。ファイル破損がリカバリ可能な場合（たとえば、セクター書込み中の電源の遮断のために不完全に書き込まれ、場合によっては読取りもできないセクター）、ファイルは自動的にリカバリされます（たとえば、不完全な書込み操作がロールバックされ、読取り不可能なセクターはゼロでリライトされて、ディスク・ドライブがセクターのECCを修正してセクターを読取り可能な状態に戻すことで、その後の再起動時に、誤警告の発生を防止します）。ファイル破損がリカバリ可能でない場合（たとえば、OC4J JMSで、以前に正常に書き込まれたデータを含んでいる可能性があるファイルの一部が現在失われるか、破損していることを検出した場合）、エラー・メッセージを表示して起動が中止され、永続性ファイルは変更されません。oracle.j2ee.jms実装には、リカバリを強制する方法はありません（永続性ファイル全体、およびそれが含むすべてのメッセージ/サブスクリプション/トランザクションを削除できません）。
oracle.j2ee.jms実装には、例外キューが用意されていません。MDBの場合、JMSコネクタ例外キュー機能を使用できます。表4-11「MDBの構成プロパティ」にある、MaxDeliveryCntプロパティの説明を参照してください。
oracle.j2ee.jms実装には、oc4j.jms.pagingThreshold設定が用意されていません。oracle.j2ee.jms実装は、デフォルトで、ソフト参照を使用して永続的なメッセージをキャッシュします。このためJVMは、そのようなキャッシュ済メッセージを、必要に応じて自動的にメモリーから削除できます。JVMによりメッセージが削除され、アプリケーションがメッセージの受信または参照を試みた場合、OC4J JMSは自動的にディスクからメッセージをリロードします。
ソフト参照は、JVMのガベージ・コレクタが管理を行い、メッセージのメモリー内コピーを削除することでヒープ上に新しい割当てを行う領域を確保し、OutOfMemoryErrorsを回避できる点で、oc4j.jms.pagingThresholdより優れています。一方、oc4j.jms.pagingThresholdで単に定期的にメッセージを削除し、これを2回実行する間にメモリーの高速割当てを行うと、十分な量のメモリーを使用可能にできるだけの削除可能なメッセージがあった場合でも、メモリー不足の原因になります。
oc4j.jms.pagingThresholdと比較して、ソフト参照にはいくつかのデメリットもあります。JVMのガベージ・コレクタがメッセージのメモリー内コピーを過度に積極的に削除する場合、メッセージがキャッシュに残ったままにならず、ディスクから読み取る必要があるため、パフォーマンスが低下することがあります。過度に多くのメッセージを含むことが決してないとわかっている宛先がある場合（つまりOutOfMemoryErrorsが発生しない場合）、それらの宛先の削除ポリシーをsoftRefではなくneverに設定できます。その場合、それらの宛先のメッセージはメモリーから削除されることがないため、ディスクから読み込む必要がありません（サーバーが再起動された場合を除く）。
"ページングされるのはメッセージ本文のみです。メッセージ・ヘッダーとプロパティは、ページングされません。"
oracle.j2ee.jms実装は、トピック・メッセージのヘッダーとプロパティを削除できます（キュー・メッセージのヘッダーとプロパティは削除できません）。
"実行時に構成プロパティを編集するための主要ツールは、JMSAdministrator MBeanです。"
...
"別の方法として、スタンドアロン環境では、次のようにコマンドライン引数で構成プロパティを渡すことができます。"
...
"これらのプロパティ設定は、jms.xmlファイルに永続化されます。"
...
"jms.xmlファイルでのJMS構成プロパティの設定"
oracle.j2ee.jms実装がサポートするのは、システム・プロパティなどのプロパティの設定だけです。oracle.j2ee.jms実装は、jms.xmlファイル内のプロパティの設定をサポートしていません。
既存のシステム・プロパティ:
oc4j.jms.messagePoll: oracle.j2ee.jms実装では、このプロパティは必要ないため、用意されていません。ポーリングはサーバーとネットワークのリソースを浪費し、レスポンス時間も劣るため、oracle.j2ee.jms実装ではメッセージをポーリングしません。
oc4j.jms.listenerAttempts: oracle.j2ee.jms実装には、このプロパティが用意されていません。MDBの場合、JMSコネクタ例外キュー機能を使用できます。表4-11「MDBの構成プロパティ」にある、MaxDeliveryCntプロパティの説明を参照してください。
oc4j.jms.maxOpenFiles: oracle.j2ee.jms実装では、このプロパティは必要ないため、用意されていません。oracle.j2ee.jms実装は、宛先ごとに異なるファイルでなく、単一の永続性ファイルを使用します。つまり、JMSサーバー操作では、同時に開いているファイルの数を減らす必要もなく、またそれが可能でもありません。
oc4j.jms.forceRecovery: 修正できる破損はすべて自動的に修正され、修正できない破損は修正できないため、oracle.j2ee.jms実装にはこのプロパティが用意されていません。oracle.j2ee.jms実装には、リカバリを強制する方法はありません（永続性ファイル全体、およびそれが含むすべてのメッセージ/サブスクリプション/トランザクションを削除できません）。
oc4j.jms.noDms: oracle.j2ee.jms実装はDMSイベントを生成しないため、このプロパティは用意されていません。
oc4j.jms.pagingThreshold: oracle.j2ee.jms実装には、このプロパティが用意されていません。かわりにSoftReferenceベースの削除ポリシーが実装されています。「メッセージのページング」を参照してください。また、「jms.xmlを使用した構成」のevictionPolicyも参照してください。
oc4j.jms.pseudoTransactionEnlistment : 疑似トランザクション登録機能は以前に非推奨になったため、oracle.j2ee.jms実装では使用できません。
oc4j.jms.debug: oracle.j2ee.jms実装には、このプロパティが用意されていません。ただし、後述するoracle.j2ee.jms.v1.unsupportedOptions.enableMessageTracingおよびoracle.j2ee.jms.v1.unsupportedOptions.debugを参照してください。
oc4j.jms.serverPoll、oc4j.jms.saveAllExpired、oc4j.jms.socketBufsize: oracle.j2ee.jms実装には、これらのプロパティが用意されていません。
新しいシステム・プロパティ - 本番使用がサポートされているもの
oc4j.jms.implementation: このプロパティは、使用するOC4J JMSの実装を選択するために使用されます。oracle.j2ee.jms実装を有効化するために使用されます。「oracle.j2ee.jms実装の有効化」を参照してください。
型: String、デフォルト: com.evermind.server.jms（OC4J JMS）、JVM: server
oc4j.jms.suppressExceptions.Message.setJMSReplyTo: 通常、外部の宛先（oracle.j2ee.jms実装以外の、一部のJMSプロバイダによるjavax.jms.Destinationの実装）を指定してjavax.jms.Message.setJMSReplyToがコールされた場合、ClassCastExceptionがスローされます。別のJMSプロバイダを使用してOC4J JMSメッセージの送信を試みると、他のJMSプロバイダがsetJMSReplyToをコールすることがあります。一部のJMSプロバイダでは、SetJMSReplyToがClassCastExceptionをスローすると、送信操作の全体が失敗します。OC4J JMSを、そのようなJMSプロバイダと相互運用できるようにする必要がある場合、oc4j.jms.suppressExceptions.Message.setJMSReplyToをtrueに設定できます。これにより、setJMSReplyToをコールしてもClassCastExceptionがスローされず、警告なしで失敗します（JMSReplyToが設定されません）。
型: boolean、デフォルト: false、JVM: client
oc4j.jms.suppressExceptions.Message.setJMSType: JMS仕様によると、JMSTypeの有効な型名は、プロバイダごとに固有です。oracle.j2ee.jms実装の場合、有効な型名はnullのみです。通常、null以外の任意の型名でjavax.jms.Message.setJMSTypeをコールすると、setJMSTypeがJMSExceptionをスローします。別のJMSプロバイダを使用してOC4J JMSメッセージの送信を試みると、他のJMSプロバイダがnull以外の値でsetJMSTypeをコールすることがあります。一部のJMSプロバイダでは、setJMSTypeがJMSExceptionをスローすると、送信操作の全体が失敗します。OC4J JMSを、そのようなJMSプロバイダと相互運用する必要がある場合、oc4j.jms.suppressExceptions.Message.setJMSTypeをtrueに設定できます。これにより、setJMSTypeをコールしてもJMSExceptionがスローされず、警告なしで失敗します（JMSTypeが設定されません）。
型: boolean、デフォルト: false、JVM: client
新しいシステム・プロパティ - 本番使用がサポートされていないもの
これらのプロパティは本番使用に対してサポートされていないため、本番では使用しないでください。また、本番で使用されるOC4J JMS永続性ファイルに対して使用しないでください。また製品の今後のバージョンでは、これらのプロパティがなくなったり、異なる動作になる可能性があります。ただしこれらのプロパティは、開発やデバッグの際に有効である可能性があるため、ドキュメント化しています。
oracle.j2ee.jms.v1.unsupportedOptions.enableMessageTracing: メッセージ・トレース機能の詳細は、「メッセージ・トレースの使用」を参照してください。
型: boolean、デフォルト: false、JVM: serverおよびclient
oracle.j2ee.jms.v1.unsupportedOptions.protocolDebug: 正常動作時も、すべての通信が正しくプロトコルに従っていることを、クライアントとサーバーが常に検証します。なんらかのプロトコル障害が検出されると、通常は例外がスローされるか（クライアントが障害を検出した場合）、JMSコネクションがすぐにクローズされます（サーバーが障害を検出した場合）。接続が不明な理由で削除されるか、他の説明不能な問題が発生した場合、プロトコル・エラーが検出されているかどうかを確認するために、oracle.j2ee.jms.v1.unsupportedOptions.protocolDebugをtrueに設定することをお薦めします。プロトコル・エラーの原因は、クライアントと通信先サーバーのバージョンが異なる、関連のないTCPクライアント/サーバーと通信しているoracle.j2ee.jms実装のクライアントまたはサーバーがある、またはネットワークの問題のためにTCPデータ・ストリームが破損した、のいずれかです。
型: boolean、デフォルト: false、JVM: serverおよびclient
oracle.j2ee.jms.v1.unsupportedOptions.debug: このプロパティをtrueに設定すると、送受信やXAメソッドのコールに関する冗長デバッグ出力が生成されます。通常、メッセージ・トレース機能の方が有効です。対象がより明確で、システム内を通るメッセージをよりよく追跡できます。このプロパティは、適切なメッセージ・トレースを有効化するためにコードを変更することなく情報を取得する手段として使用できます。
このプロパティは、ローカル接続（クライアントとサーバーが同じJVMで実行されている場合のクライアントとサーバーの間の接続）でのみ機能します。
型: boolean、デフォルト: false、JVM: server
oracle.j2ee.jms.v1.unsupportedOptions.all.debugSetClientID: JMS仕様によると、javax.jms.Connection.setClientIDは、どのような接続においても最初の操作である必要があります。その接続で先に行われた操作が原因でsetClientIDが失敗し（この時点でclientIDが設定されていない可能性があることを示す例外メッセージが生成され）、接続上でどのような操作が実行されたかわからない場合に、このプロパティが役立ちます。oracle.j2ee.jms.v1.unsupportedOptions.all.debugSetClientIDをtrueに設定すると、setClientIDコールより先に行われた操作のスタック・トレースが記録されます（clientIDがjms.xmlファイルを使用して管理のために設定される場合、これはコンストラクタ操作です）。その後でsetClientIDがコールされると、先行する操作のスタック・トレースがSystem.outに送信されます。
このプロパティは、リモート接続（クライアントとサーバーが同じJVMで実行されていない場合のクライアントとサーバーの間の接続）でのみ機能します。
型: boolean、デフォルト: false、JVM: client
oracle.j2ee.jms.v1.unsupportedOptions.enableTempDestTracing: このプロパティをtrueに設定すると、一時的な宛先が作成または破棄されるとき、常にスタック・トレースが表示されます。
型: boolean、デフォルト: false、JVM: server
OEMS JMSのメモリー内およびファイル・ベースの直接ルックアップを使用するアプリケーション・クライアントに必要なクラスパス
純粋なJMS使用の場合、oracle.j2ee.jms実装のクライアントに必要なのは、oc4j-jms-client.jarとjms.jarの、2つのJARファイルだけです。
JMSクライアントが、コネクション・ファクトリをJNDIでルックアップするのではなく作成する場合、またクライアントが、宛先をJNDIでルックアップするのではなくjavax.jms.SessionのcreateQueueおよびcreateTopicメソッドを使用する場合、他に必要なクラスはありません。
JMSクライアントがOC4JのJNDIサービスを使用してコネクション・ファクトリや宛先をルックアップする場合、参照先の項にリストされているクラス・ライブラリが必要です。
oracle.j2ee.jms実装のコネクション・ファクトリは、Java Beanとして実装されます。次の引数なしコンストラクタを使用して、それらを直接作成できます。
| oracle.j2ee.jms実装クラス | 実装されるインタフェース |
|---|---|
oracle.j2ee.jms.v1.ConnectionFactoryImpl |
javax.jms.ConnectionFactory |
oracle.j2ee.jms.v1.QueueConnectionFactoryImpl |
javax.jms.QueueConnectionFactory |
oracle.j2ee.jms.v1.TopicConnectionFactoryImpl |
javax.jms.TopicConnectionFactory |
oracle.j2ee.jms.v1.XAConnectionFactoryImpl |
javax.jms.XAConnectionFactory |
oracle.j2ee.jms.v1.XAQueueConnectionFactoryImpl |
javax.jms.XAQueueConnectionFactory |
oracle.j2ee.jms.v1.XATopicConnectionFactoryImpl |
javax.jms.XATopicConnectionFactory |
インスタンス化した後、setメソッドを使用して、jms.xmlファイルでサポートされているものと同じコネクション・ファクトリ・プロパティを設定できます。
| setメソッド | コネクション・ファクトリ・プロパティ |
|---|---|
setUrl(String) |
url: URLの形式はtcp://<host>:<port>です。ここで<host>はホスト名かリテラルIPアドレスで、<port>は1〜65535の整数です。to-same-JVM-as-serverコネクション・ファクトリでは、URLを設定する必要はありません。 |
setClientID(String) |
clientID |
setName(String) |
name |
setLeakDetect(String) |
leakDetect（後述を参照） |
setEnableJMSXConsumerTXID(boolean) |
enableJMSXConsumerTXID（後述を参照） |
setEnableJMSXRcvTimestamp(boolean) |
enableJMSXRcvTimestamp（後述を参照） |
コネクション・ファクトリJava Beanも、対応するgetメソッドを実装します。この方式では、JMX Mbeanやjms.xml構成ファイルを使用して構成することができない、3つの追加のコネクション・ファクトリ・プロパティが使用されます。
leakDetect
各設定は次のとおりです。none: これがデフォルトの設定です。リーク検出は行われず、パフォーマンスへの影響は基本的にありません。silent: この設定（およびlog/track設定）では、このコネクション・ファクトリを使用して作成されたすべての接続をラップするために、ファイナライザを持つクラスが使用されます。ファイナライザは、接続がまだクローズされていないかどうかを判別し、クローズされていなければクローズします。これは、緊急用の設定、つまり、アプリケーションの修復中にのみ使用する応急的な方法です。接続のクローズを適切に代替する方法とは考えないでください（実際にそうではありません）。log: この設定（およびtrack設定）では、接続の自動クローズに加えて、リークがあったという事実が、接続の作成に使用されたファクトリの名前とともに記録されます（nameプロパティが設定されている場合は、それを参照してください）。track: この設定はlogと同様ですが、接続の作成時にスタック・トレースが記録されます。
このプロパティは、どのようなコンテキストでも、2回以上設定しないでください。
型: String
値: none、silent、log、track
enableJMSXConsumerTXID
JMSXConsumerTXIDが有効で、メッセージがXAトランザクション内で受信された場合、トランザクションIDは、JMSXConsumerTXIDプロパティとしてメッセージに自動的に格納されます。JMSXConsumerTXIDが有効でない場合も、アプリケーションはJMSXConsumerTXIDプロパティを設定または取得できますが、送信者がこのプロパティを設定した場合も含め、新たに受信したメッセージでJMSXConsumerTXIDが設定されることはありません。アプリケーションは、接続のメタデータ（javax.jms.ConnectionMetaData.getJMSXPropertyNamesを参照）を調べることで、JMSXConsumerTXIDが有効にされているかどうかを判別できます。
このプロパティは、どのようなコンテキストでも、2回以上設定しないでください。
型: boolean
enableJMSXRcvTimestamp
JMSXRcvTimestampが有効なときにメッセージが受信された場合、現在時刻がJMSXRcvTimestampプロパティとしてメッセージに自動的に格納されます。JMSXRcvTimestampが有効でない場合も、アプリケーションはJMSXRcvTimestampプロパティを設定または取得できますが、送信者がこのプロパティを設定した場合も含め、新たに受信したメッセージでJMSXRcvTimestampが設定されることはありません。アプリケーションは、接続のメタデータ（javax.jms.ConnectionMetaData.getJMSXPropertyNamesを参照）を調べることで、JMSXRcvTimestampが有効にされているかどうかを判別できます。
このプロパティは、どのようなコンテキストでも、2回以上設定しないでください。
型: boolean
oracle.j2ee.jms実装には、JmsConfigResource MBeanとJmsOperationsResource MBeanが含まれています。これらのMBeanは、oracle.j2ee.jms実装を構成および管理するための様々な操作を提供します。この項では、各MBeanで使用できる操作を説明します。
JmsConfigResource MBeanには、oracle.j2ee.jms実装の構成を変更する操作が用意されています。JmsConfigResource MBeanには、Application Server Controlコンソールを使用して、次のパスでアクセスできます。
「OC4J: ホーム」→「管理」タブ→「タスク名: JMX」→「システムMBeanブラウザ」→「タスクに移動」→「J2EEDomain:oc4j」、「J2EEServer:standalone」、「JmsConfigResource」、「JmsConfig」→「操作」タブにドリルダウン
表4-21 JmsConfigResource MBeanの操作
| 操作グループ | 操作 | 操作の説明 |
|---|---|---|
|
宛先バインディング |
showDestinationBinding |
場所を指定すると、宛先バインディングを1つ示します。 |
|
showDestinationBindings |
すべての宛先バインディングのリストを戻します。 |
|
|
addDestinationBinding |
新しい宛先バインディングを追加します。 |
|
|
removeDestinationBinding |
既存の宛先バインディングを削除します。 |
|
|
ファクトリ・バインディング |
showFactoryBinding |
場所を指定すると、ファクトリ・バインディングを1つ示します。 |
|
showFactoryBindings |
すべてのファクトリ・バインディングのリストを戻します。 |
|
|
addFactoryBinding |
新しいファクトリ・バインディングを追加します。 |
|
|
removeFactoryBinding |
既存のファクトリ・バインディングを削除します。 |
|
|
宛先 |
showDestination |
宛先タイプと名前を指定すると、その属性を示します。 |
|
showDestinations |
すべての宛先のリストを戻します。 |
|
|
addDestination |
新しい宛先を追加します。 |
|
|
removeDestination |
既存の宛先を削除します。 |
|
|
same-jvm-client-properties |
showSameJvmClientProperty |
same-jvm-client-propertyの値を表示します。 |
|
showSameJvmClientProperties |
すべてのsame-jvm-client-propertyのリストを戻します。 |
|
|
addSameJvmClientProperty |
新しいsame-jvm-client-propertyを追加します。 |
|
|
removeSameJvmClientProperty |
same-jvm-client-propertyを削除します。 |
|
|
サーバー・プロパティ |
showServerProperty |
サーバー・プロパティの値を表示します。 |
|
showServerProperties |
すべてのサーバー・プロパティのリストを戻します。 |
|
|
addServerProperty |
新しいサーバー・プロパティを追加します。 |
|
|
removeServerProperty |
サーバー・プロパティを削除します。 |
|
|
サーバー属性 |
showServerAttribute |
サーバー属性の値を表示します。 |
|
changeServerAttribute |
サーバー属性を変更（または追加）します。 |
|
|
removeServerAttribute |
サーバー属性を削除します。 |
JmsOperationsResource MBeanは、トピック・サブスクリプションの作成、削除および監視のためのランタイム操作を提供します。JmsOperationsResource MBeanには、Application Server Controlコンソールを使用して、次のパスでアクセスできます。
「OC4J: ホーム」→「管理」タブ→「タスク名: JMX」→「システムMBeanブラウザ」→「タスクに移動」→「J2EEDomain:oc4j」、「J2EEServer:standalone」、「JmsOperationsResource」、「JmsOperations」→「操作」タブにドリルダウン
表4-22 JmsOperationsResource MBeanの操作
| 操作グループ | 操作 | 説明 |
|---|---|---|
|
サブスクリプションの管理 |
subscribe |
トピックのサブスクリプションを作成します。 |
|
unsubscribe |
既存のサブスクリプションをサブスクライブ解除します。 |
|
|
drainSubscription |
サブスクリプションの未配信メッセージを排出します。 |
|
|
プロバイダ固有の拡張 |
showSubscriptionMessageHeaders |
サブスクリプションの未配信メッセージのJMSヘッダーのリストを戻します。 |
|
browseSubscription |
内容がサブスクリプションの未配信メッセージであるXML形式の文字列を戻します。 |
|
|
サブスクリプション・サマリー |
showSubscriptionSummaries |
1つまたはすべてのJMSトピックのサブスクリプションのリストを戻します。 |
|
showSubscriptionSummary |
個別のサブスクリプションのサブスクリプション・サマリーを戻します。 |
メッセージ・トレースは、JMSアプリケーションをデバッグするために使用される未サポートの機能です。この機能を使用すると、アプリケーション開発者は、メッセージにタグを付けて、メッセージがoracle.j2ee.jms実装を通るのを監視できます。これにより、問題の発生箇所（メッセージが破棄されたりスタックしている箇所）を、開発者が見つけることができます。また、正常に動作していることを検証するためにも使用できます（メッセージが永続化中である、メッセージがトランザクション内で移動中である、メッセージが期限切れになる、配信数が更新中であるなどの状態確認）。
次のオプションを付けてJVMを起動します。
-Doracle.j2ee.jms.v1.unsupportedOptions.enableMessageTracing=true
このプロパティは、トレース用にメッセージをタグ付けしているJVMに対して設定する必要があります。また、トレース出力を必要とするすべてのJVMにも設定する必要があります。大部分のトレース出力はJMSサーバーを含むJVMで生成されますが、メッセージに影響を与えたりメッセージにアクセスしたりするJMSクライアント（たとえば、送信、受信、参照、コミット、ロールバック）を含んでいるすべてのJVMでも、トレース出力が生成されます（トレースが有効化されている場合）。
次のメッセージが出力される場合、特定のJVMでメッセージ・トレースが有効化されていることがわかります。
message tracing is enabled
クライアントJVMは、JMS操作が実行されるまで、メッセージを出力できません。（出力はoracle.j2ee.jms.v1.MessageImplクラス初期化の際に生成されます。これは、クラス・ローダーがMessageImplクラスをロードして初期化することを決定してから行われます。）
コードに次の内容を追加して、メッセージが送信される前にメッセージにタグを付けます。
message.setBooleanProperty("JMS_OC4J_TraceMe", true);
それにより、出力は次のようになります。
JMS_OC4J_TraceMe = true; tracing message
プロパティをfalseに設定することもできますが、すでに送信されたメッセージのコピーに対するトレースは停止されません。メッセージが再送信される場合の追加トレースが行われなくなるだけです。
メッセージのタグ付けは永続的です（サーバーは停止または起動できます。メッセージがディスク上で永続化された場合も、サーバーの再起動時にはタグ付けされます。その場合、実際には、サーバーがメッセージを適切なキューまたはサブスクリプションに配置すると、起動時にトレース出力が生成されます）。
|
注意: トレースが有効化されない場合、次のようになります。
|
メッセージ・トレースは、対象を絞ったツールとして設計されています。いくつかのログ出力をFINESTにしても、処理しきれない量の出力が得られるだけです。単一のメッセージにタグ付けし、その1つのメッセージに発生する内容に関する完全情報を取得するのが適切です。こうした使用方法が本来の意図であるため、メッセージIDを出力に含むことはそれほど優先されず、現時点でメッセージIDはトレース出力に含まれません。
それでも出力が大量になる可能性があることに注意してください。トレースされたメッセージがトピックに送信されると、メッセージを受信する各サブスクリプションごとに1つのメッセージ参照が作成されます。（つまり、すべてのサブスクリプションがそのメッセージを共有し、各サブスクリプションは、共有メッセージへの独自の参照を持ちます。）各メッセージ参照（トレース出力では「message ref」と呼ばれる）がトレースされます。このため、サブスクリプションが多数ある場合、出力が大量になることがあります。
混乱を避ける方法:
1つのメッセージにのみタグ付けします。
テスト実行を行います（永続性やリカバリの使用例をテストする場合は、サーバーの再起動が含まれる可能性があります）。
テスト実行が完了したら、jms.datファイルを削除して、前のテスト実行のトレース・メッセージが次のテスト実行に誤って入り込まないようにします。
複数のメッセージにタグ付けしても機能しますが（一部、それが有効である事例もあります）、出力がわかりにくくなる可能性があります。
タグ付けされたメッセージを消費すると、他のメッセージと同様にメッセージが削除されるため、実行時にjms.datファイルを削除することは、厳密には不要です。しかし、この場合も、アプリケーションでエラーが発生し、タグ付けされたメッセージが残された場合に混乱の原因になる可能性があります。
次の使用例はトレースされます。
タグ付けされたメッセージを含んでいるメッセージの操作。たとえば次のようなものがあります。
サーバーからクライアントに（またはその逆）メッセージが送信される
ディスクとの間でメッセージが読み書きされる
メッセージが、トランザクション、キュー・ブローカまたはサブスクリプションに提供される
メッセージがロックされるか（受信のため）、ロック解除される（ロールバックまたはリカバリのため）
メッセージが削除される（ディスクまたはメモリーから）
メッセージが期限切れになる
メッセージのキュー/サブスクリプションを破棄するときに、メッセージが破棄される
メッセージを含んでいるトランザクション（明示的または暗黙的）が、確認、準備、コミット、リカバリ、またはロールバックされる
ミスに近い事例
サブスクリプション、キュー・レシーバまたはキュー・ブラウザが、メッセージ・セレクタの考慮事項以外のメッセージを取得する場合
サブスクリプションが、noLocal考慮事項以外のメッセージを取得する場合
次の使用例はトレースされません。
下位レベルのプロトコル違反: TCP接続（およびその上のすべてのJMS接続）が即時クローズされます。oracle.j2ee.jms.v1.unsupportedOptions.protocolDebugをtrueに設定して、サーバーのJVMがこれらのイベントに関する出力を取得するようにできます。
例外事例: JMSプロバイダがJMSException（またはXAExceptionなど）をスローする場合、アプリケーションが例外を暗黙処理するのでなく、アプリケーション開発者が例外に気づくのが理想的です。ただし、アプリケーションには不具合がある（このためにトレース機能に意味がある）ため、これらのすべてをトレースする方法がいくつかあれば好都合ですが、実際にはありません。当面、ユーザーはoracle.j2ee.jms.v1.unsupportedOptions.debugを使用して送信/受信/XAメソッドの各事例の例外を確認しますが、いくつかのメソッド（Session.commitなど）では、このときに何も出力しません。oracle.j2ee.jms.v1.unsupportedOptions.debugは、メッセージ・トレースと違って極端に冗長で、出力の対象とされません。
完全なミス
停止した接続を使用してメッセージを受信しようとした場合、試行された受信はトレースされません。
1つの宛先上でタグ付けされたメッセージを送信し、別の宛先上でそれを受信しようとしても、試行された受信はトレースされません。
誤ったOC4J JMSサーバーを使用してメッセージを受信しようとした場合、試行された受信はトレースされません。
接続は、<connection-id>のように識別されます。
セッションは、<connection-id>:<session-id>のように識別されます。
セッションの子（コンシューマ、ブラウザなど）は、<connection-id>:<session-id>:<child-id>のように識別されます。
その規則（場合により後述を参照）により、コンシューマやブラウザがどのセッションに属しているか、セッションがどの接続に属しているかを容易に確認できます。現在、リモート・セッションは、サーバーとリモート・クライアントに共通のID（つまり実用的なID）を持たないため、空欄のままです。その場合、セッションの子は<connection-id>::<child-id>のように識別されます。
セッションの子が、クローズされてから作成された場合、リモート・セッションの子のIDは、時系列中の特定の瞬間にのみ一意であり、時系列を通じて一意であるわけではありません。たとえば、コンシューマがクローズされて、後からブラウザが作成された場合、コンシューマが持っていたIDがブラウザで再利用されることがあります。
また、ローカル・セッションとセッションの子に良好なIDが割り当てられず、かわりに、IDのそれぞれの部分に対してObject.hashCode()（一意性はまったく保証されない）が使用されます。
