10g（10.1.3.1.0）
B31858-01
 目次 |
 索引 |
| Oracle Containers for J2EE サービス・ガイド 10g（10.1.3.1.0） B31858-01 |
|
Oracle Enterprise Messaging Service（OEMS）は、分散アプリケーションを構築および統合するための強力なメッセージ・プラットフォームです。OEMSにより、Oracleのメッセージ機能とメッセージ統合ソリューションのためのフレームワークが提供されます。
OEMSを構成する主要機能は、次のとおりです。
この章では、これらすべての機能について説明します。OEMS機能のうち、この章で取り上げていないのは、メッセージ・ゲートウェイのみです。メッセージ・ゲートウェイの詳細は、『Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイドおよびリファレンス』を参照してください。
この章には、次の項目が含まれます。
この章では、次のJMSタスクについて説明します。
次のOC4J JMSの機能および動作は、今回のリリースの新機能です。
JMS 1.1仕様は、http://java.sun.com/products/jms/docs.htmlで入手できます。
J2EE 1.4仕様は、http://java.sun.com/j2ee/1.4/docs/index.htmlで入手できます。
リソース・アダプタの詳細は、『Oracle Containers for J2EEリソース・アダプタ管理者ガイド』を参照してください。
サード・パーティ・プロバイダの詳細は、「リソース・プロバイダ」を参照してください。リソース・アダプタによる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インタフェースのセットに関連付けられています。
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メッセージ機能を使用するアプリケーションを開発および構成するためのタスクは、次のとおりです。
詳細は、デモ・セットに含まれるHow-Toドキュメントを参照してください。How-Toドキュメントおよびデモ・セットと、そのURLのリストは、「JMSのHow-Toドキュメントおよびデモ・セット」を参照してください。
アプリケーション・コンポーネント開発者とアプリケーション・アセンブラは、複数のコネクション・ファクトリおよび宛先を開発に使用するため、リソース・プロバイダの構成は、複数の作業に分割されるのが普通です。通常、開発時のコネクション・ファクトリと宛先は、デプロイ時のものとは異なります。開発サーバーと本番サーバーは、別個のマシンであることが普通であり、異なる組織方針に基づいて構成されるためです（場合によっては、異なるリソース・プロバイダが使用されることもあります）。このドキュメントでは、本番のデプロイに重点を置いて説明します。
リソース・プロバイダを構成する場合、次のことを決定する必要があります。
詳細は、デモ・セットのHow-Toドキュメントを参照してください。How-Toドキュメントおよびデモ・セットと、そのURLのリストは、「JMSのHow-Toドキュメントおよびデモ・セット」を参照してください。
OEMSへのJMSコネクタ機能の導入により、様々なリソース・プロバイダの仕様からの独立が部分的に実現しています。J2CA 1.5仕様に基づく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コネクタのことです。
http://www.oracle.com/technology/tech/java/oc4j/1013/how_to/how-to-gjra-with-oracleasjms/doc/how-to-gjra-with-oracleasjms.html
http://www.oracle.com/technology/tech/java/oc4j/1013/how_to/how-to-gjra-with-oracleasjms/how-to-gjra-with-oracleasjms.zip
この項では、コネクション・ファクトリおよび宛先について、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ファイルの使用例が含まれます。
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つのタイプのリンクがあります。次にリストする各説明の番号は、図のリンク番号に対応しています。
<resource-ref>要素に向かいます。リンク参照は、JMSコネクション・ファクトリを取得するためにJNDIルックアップで使用されるロケーションです。リンク参照には、java:comp/env接頭辞を含める必要があります。<resource-ref>要素のリンク・キーは、その<res-ref-name>サブ要素の値です。リンク・キーには、java:comp/env接頭辞を含めないでください。java:comp/env接頭辞を除けば、リンク参照とリンク・キーは同一です。
<message-destination-ref>要素に向かいます。リンク参照は、JMS宛先を取得するためにJNDIルックアップで使用されるロケーションです。リンク参照には、java:comp/env接頭辞を含める必要があります。<message-destination-ref>要素のリンク・キーは、その<message-destination-ref-name>サブ要素の値です。リンク・キーには、java:comp/env接頭辞を含めないでください。java:comp/env接頭辞を除けば、リンク参照とリンク・キーは同一です。
アプリケーション・コンポーネント・プロバイダによって使用される論理名は、物理宛先と多対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つのタイプのリンクがあります。
<message-destination-ref>要素から<message-destination>要素に向かいます。どちらの要素も、J2EEアプリケーション・コンポーネント・デプロイメント・ディスクリプタに含まれます（必ずしも同じである必要はありません）。リンク参照は、<message-destination-link>サブ要素の値です。<message-destination>要素のリンク・キーは、その<message-destination-name>サブ要素の値です。リンク参照には、接頭辞として、リンク・キーを含むファイルの名前とそれに続く#文字が付く場合があります。（この接頭辞は、異なるファイルの様々なリンク・キーがまったく同じ値を保持する場合にのみ必要です。）このオプションの接頭辞を除けば、リンク参照とリンク・キーは同一です。
<message-driven>要素から<message-destination>要素に向かいます。どちらの要素も、J2EEアプリケーション・コンポーネント・デプロイメント・ディスクリプタに含まれます（必ずしも同じである必要はありません）。リンク参照は、<message-destination-link>サブ要素の値です。前述のとおり、<message-destination>要素のリンク・キーは、その<message-destination-name>サブ要素の値です。リンク参照には、接頭辞として、リンク・キーを含むファイルの名前とそれに続く#文字が付く場合があります。（この接頭辞は、異なるファイルの様々なリンク・キーがまったく同じ値を保持する場合にのみ必要です。）このオプションの接頭辞を除けば、リンク参照とリンク・キーは同一です。
図4-1には、OC4J固有のアプリケーション・コンポーネント・デプロイメント・ディスクリプタから別のファイルに向かう次の7つのタイプの参照があります。
詳細および使用例は、関連するHow-Toドキュメントの「Deployer Task #1: Map Logical Connection Factories to RA ConnectionFactories」を参照してください。
図には、<resource-ref-mapping>要素で指定される次の2つのタイプのコネクション・ファクトリ・リンクがあります。
<resource-ref-mapping>要素からJ2EEアプリケーション・コンポーネント・デプロイメント・ディスクリプタの<resource-ref>要素に戻ります。リンク参照は、<resource-ref-mapping>要素のname属性の値です。前述のとおり、<resource-ref>要素のリンク・キーは、その<res-ref-name>サブ要素の値です。
<resource-ref-mapping>要素からoc4j-ra.xmlファイルの<connector-factory>要素に向かいます。リンク参照は、<resource-ref-mapping>要素のlocation属性の値です。<connector-factory>要素のリンク・キーは、そのlocation属性の値です（この値は、特定の<connector-factory>要素によって定義されるリソース・アダプタのコネクション・ファクトリがバインドされるJNDIロケーションとも一致します）。
<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つのタイプの宛先リンクがあります。
<message-destination-ref-mapping>要素からJ2EEアプリケーション・コンポーネント・デプロイメント・ディスクリプタの<message-destination-ref>要素に戻ります。リンク参照は、<message-destination-ref-mapping>要素のname属性の値です。前述のとおり、<message-destination-ref>要素のリンク・キーは、その<message-destination-ref-name>サブ要素の値です。
<message-destination-ref-mapping>要素からoc4j-connectors.xmlファイルの<adminobject-config>要素に向かいます。リンク参照は、<message-destination-ref-mapping>要素のlocation属性の値です。<adminobject-config>要素のリンク・キーは、そのlocation属性の値です（この値は、特定の<adminobject-config>要素によって定義されるリソース・アダプタの宛先がバインドされるJNDIロケーションとも一致します）。
詳細および使用例は、関連するドキュメントの「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つのタイプのインバウンド・メッセージ・リンクがあります。
orion-ejb-jar.xmlファイルのMDBの<message-driven-deployment>要素からoc4j-connectors.xmlファイルのJMSコネクタ・インスタンスの<connector>要素に向かいます。リンク参照は、<message-driven-deployment>要素のresource-adapter属性の値です。<connector>要素のリンク・キーは、そのname属性の値です（この値は、特定の<connector>要素によって定義されるリソース・アダプタ・インスタンスがバインドされるJNDIロケーションとも一致します）。
orion-ejb-jar.xmlファイルの<message-driven-deployment>要素からoc4j-ra.xmlファイルの<connector-factory>要素に向かいます。リンク参照は、<message-driven-deployment>のConnectionFactoryJNDIName構成プロパティの値です。前述のとおり、<connector-factory>要素のリンク・キーは、そのlocation属性の値です（この値は、特定の<connector-factory>要素によって定義されるリソース・アダプタのコネクション・ファクトリがバインドされるJNDIロケーションとも一致します）。これは、アウトバウンドの3番目のリンクと同じ場所にリンクしていることに注意してください。コネクション・ファクトリ・チェーンの残りは、インバウンド・メッセージとアウトバウンド・メッセージの両方で同じです。
orion-ejb-jar.xmlファイルの<message-driven-deployment>要素からoc4j-connectors.xmlファイルの<adminobject-config>要素に向かいます。リンク参照は、<message-driven-deployment>のDestinationName構成プロパティの値です。前述のとおり、<adminobject-config>要素のリンク・キーは、そのlocation属性の値です（この値は、特定の<adminobject-config>要素によって定義されるリソース・アダプタの宛先がバインドされるJNDIロケーションとも一致します）。これは、アウトバウンドの3番目のリンクと同じ場所にリンクしていることに注意してください。宛先チェーンの残りは、インバウンド・メッセージとアウトバウンド・メッセージの両方で同じです。
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つのタイプのリンクがあります。
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）とも一致します）。
<adminobject-config>要素からリソース・プロバイダの宛先に向かう接続が完成します。リンク参照は、<adminobject-config>のjndiName構成プロパティの値です。リンク・キーは、リソース・プロバイダ（RP）のJNDIコンテキスト内にあるRPの宛先のJNDIロケーション（resourceName）です。同時に、これら2つのリンクにより、JMSコネクタの宛先にRPの宛先として次の完全なJNDIロケーションが提供されます。
java:comp/resource/providerName/resourceName
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つのタイプのリンクがあります。
oc4j-ra.xmlファイルの<connector-factory>要素を（JMSコネクタ・インスタンスを定義する）oc4j-connectors.xmlファイルの<connector>要素に関連付けます。現時点では、このリンクは実際に使用されない可能性がありますが、将来的な互換性を考慮して次のように設定する必要があります。リンク参照は、<connector-factory>要素のconnector-name属性の値です。前述のとおり、<connector>要素のリンク・キーは、そのname属性の値です（この値は、特定の<connector>要素によって定義されるJMSコネクタ・インスタンスがバインドされるJNDIロケーションとも一致します）。
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の説明を参照。）慣例的に、このオプションは常に設定します（上書きする値と同じであっても設定します）。
oc4j-ra.xmlファイルの<connector-factory>要素）の実装の詳細は、<connector-factory>要素をra.xmlファイルの<connection-definition>要素にリンクすることで定義します。リンク参照は、<connector-factory>の<connectionfactory-interface>サブ要素の値です。<connection-definition>要素のリンク・キーは、その<connectionfactory-interface>サブ要素の値です。
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つのタイプのリンクがあります。
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構成プロパティを使用して上書きできます。上書きは一般的には不要であるため、この図の矢印では示されていません。
<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コネクタのリソースではなくリソース・プロバイダのリソースを参照することで行います。
<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ファイルが省略されます。
<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以外のリソース・プロバイダの詳細は、各プロバイダのドキュメントを参照してください。
jms.xmlファイルのJNDIにバインドされます。OEMS JMSの永続性オプションの詳細は、「OEMS JMSのメモリー内およびファイル・ベースの永続性」を参照してください。
クライアントは、希望する統合機能およびサービス品質（QOS）機能に応じて、それぞれ独自のリソース・アダプタを持つ1つ以上の異なるJMSリソース・プロバイダを使用できます。
リソース・プロバイダへの参照は、orion-application.xmlファイルおよびapplication.xmlファイルの1つ以上の<resource-provider>要素で宣言します。
OEMS JMSのデータベースの永続性オプションのメリットは、次のとおりです。
次のいずれかのファイルを使用して、リソース・プロバイダ参照を宣言します。
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: リソース・プロバイダ・クラスの名前。
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のメモリー内およびファイル・ベースのオプションでは、次の機能が提供されます。
この項には、次の項目が含まれます。
宛先オブジェクトは、キューまたはトピックです。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ロケーションを使用する方が安全です。
デフォルトの宛先は、次のとおりです。
Application Server Controlコンソールは、OEMS JMSのメモリー内およびファイル・ベースの永続性オプションのコネクション・ファクトリおよび宛先オブジェクトを構成するための主要ツールです。宛先オブジェクトごとに、その名前、ロケーションおよび宛先タイプ（キューまたはトピック）を指定する必要があります。
「OC4J: ホーム」→「管理」タブ→「サービス」→「JMSプロバイダ」→「タスクに移動」→「OracleAS JMSの構成」→適切なタブを選択。
表4-1「構成要素」に、OracleAS JMSのリソース・プロバイダの構成要素とその属性を示します。
表4-1に、各構成要素と、Application Server Controlコンソール、MBeanおよびjms.xmlファイルでの設定場所を示します。
| コンソールおよびMBeanでの設定場所 | jms.xmlの要素 | 説明および属性 |
|---|---|---|
|
「OC4J: ホーム」→「管理」タブ→「タスク名: JMX」→「システムMBeanブラウザ」→「タスクに移動」→「J2EEDomain:oc4j」、「J2EEServer:standalone」、「JMSAdministratorResource」、 |
|
|
|
リソース・プロバイダの宛先を作成し、その属性を 「OC4J: ホーム」→「管理」タブ→「タスク名: サービス」→「JMSプロバイダ」→「タスクに移動」→「宛先」タブ→「新規作成」 |
|
この要素では、キューを構成します。キューは、OC4Jの起動時に使用可能となり、サーバーが再起動または再構成されるまで使用できます。0（ゼロ）個以上のキューを任意の順序で構成できます。新規に構成したキューは、OC4Jを再起動するまで使用できません。
キューおよびトピックごとに、独自の永続性ファイル名を指定する必要があります。同じ永続性ファイルに書き込む2つのオブジェクトを使用することはできません。
|
|
トピックの宛先を作成し、その属性を 「OC4J: ホーム」→「管理」タブ→「タスク名: サービス」→「JMSプロバイダ」→「タスクに移動」→「宛先」タブ→「新規作成」 |
|
この要素では、トピックを構成します。トピックは、OC4Jの起動時に使用可能となり、サーバーが再起動または再構成されるまで使用できます。0（ゼロ）個以上のトピックを任意の順序で構成できます。新規に構成したトピックは、OC4Jを再起動するまで使用できません。
persistence-file: オプションのパスおよびファイル名（String）です。persistence-file属性のパスは、ファイルの絶対パス、またはapplication.xmlに定義されているpersistenceディレクトリに対する相対パスです。デフォルト・パスは、Oracle Application Server環境の場合はJ2EE_HOME/persistence/<group>で、スタンドアロン環境の場合はJ2EE_HOME/persistenceです。 キューおよびトピックごとに、独自の永続性ファイル名を指定する必要があります。同じ永続性ファイルに書き込む2つのオブジェクトを使用することはできません。
|
|
|
|
|
|
コネクション・ファクトリを作成し、その属性を 「コネクション・ファクトリの追加」または「コネクション・ファクトリの編集」ページへのパス: 「OC4J: ホーム」→「管理」タブ→「タスク名: サービス」→「JMSプロバイダ」→「タスクに移動」→「コネクション・ファクトリ」タブ→「新規作成」または「プロパティの編集」 |
|
コネクション・ファクトリの構成です。コネクション・ファクトリ要素には、次の属性が含まれます。
|
|
XA対応のコネクション・ファクトリを作成し、その属性を 「コネクション・ファクトリの追加」または「コネクション・ファクトリの編集」ページへのパス: 「OC4J: ホーム」→「管理」タブ→「タスク名: サービス」→「JMSプロバイダ」→「タスクに移動」→「コネクション・ファクトリ」タブ→「新規作成」または「プロパティの編集」 |
|
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ファイル内の<jms-server>以降の要素の構造を示しています。この例では、次のように宛先とコネクション・ファクトリを構成します。
jms/MyQueueに指定
jms/MyTopicに指定
jms/Cfに指定
jms/Qcfに指定
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コンソールを使用してポート範囲を構成します。
「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サーバーへの接続に使用されます。
コマンドは、実行される処理の内容を表します。表4-3で各コマンドを説明します。一部のコマンドには、実行する処理をさらに特定するための独自のオプション（command-options）があります。
| コマンド | 説明 |
|---|---|
|
|
すべてのユーティリティ・コマンドの詳細なヘルプを出力します。 |
|
|
|
|
|
使用可能なすべてのシステム・プロパティ（表4-6を参照）とOC4J JMSサーバーの現在の設定を表示します。 |
|
|
OC4J JMSサーバーの使用可能なすべてのDMS統計を表示します（JMS以外の統計も含まれます）。（DMSの詳細は、『Oracle Application Serverパフォーマンス・ガイド』を参照してください。） |
|
|
OC4J JMSが認識しているすべての永続宛先オブジェクトのリストを出力します。 |
|
|
OC4J JMSが認識しているすべての永続サブスクリプションのリストを出力します。 |
|
|
<topic>に永続サブスクリプションを作成します。名前、メッセージ・セレクタ、ローカルであるかどうか、および永続サブスクリプションのクライアント識別子を指定します。これにより、既存のアクティブでない永続サブスクリプションが置き換えられます。名前は、 |
|
|
既存のアクティブでない永続サブスクリプションを削除します。永続サブスクリプションは、名前（ |
|
|
指定された宛先（ |
|
|
指定された宛先（キューまたはトピックの永続サブスクリプション）のメッセージをデキューします。 |
|
|
ある宛先（キューまたはトピックの永続サブスクリプション）から別の宛先にメッセージをコピーします。発信側と受信側の宛先が同一の場合はコマンドは実行されず、かわりにエラーが生成されます。 |
|
|
ある宛先（キューまたはトピックの永続サブスクリプション）から別の宛先にメッセージを移動します。発信側と受信側の宛先が同一の場合はコマンドは実行されず、かわりにエラーが生成されます。 |
次の例では、クライアント・ユーティリティと同じコンピュータに配置されている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」にドリルダウン
「OC4J: ホーム」→「管理」タブ→「タスク名: JMX」→「システムMBeanブラウザ」→「タスクに移動」→「J2EEDomain:oc4j」、「J2EEServer:standalone」、「JMSResource」、「JMS」、「JMSDestinationResource」にドリルダウン→希望の宛先を示すMBeanを選択
| MBean実装 | コマンドラインの等価 | 説明 |
|---|---|---|
|
JMSAdministrator MBeanの |
|
使用可能なすべてのシステム・プロパティ（表4-6を参照）と現在の設定を表示します。 |
|
|
stats |
|
|
JMSAdministrator Mbeanの |
check <selector> |
指定されたJMSメッセージ・セレクタの妥当性をチェックします。この操作には、引数 |
|
JMSAdministrator Mbeanの |
check <sel1> <sel2> |
指定された2つのセレクタを等価に扱えるかどうかをチェックします。これは、永続サブスクリプションを再アクティブ化する際に役立ちます。
この操作には、引数 |
|
ドメインがtopicであるすべてのJMSDestinationResource MBeanの |
|
宛先に永続サブスクリプションを作成します。これにより、既存のアクティブでない永続サブスクリプションが置き換えられます。 この操作には、次の引数が含まれます。 |
|
ドメインがtopicであるすべてのJMSDestinationResource MBeanの |
|
この操作には、次の引数が含まれます。 |
|
すべてのJMSDestinationResource Mbeanの |
|
この操作には、次の引数が含まれます。 |
|
すべてのJMSDestinationResource Mbeanの |
|
この操作には、次の引数が含まれます。 |
|
すべてのJMSDestinationResource Mbeanの |
|
この操作には、次の引数が含まれます。 |
|
すべてのJMSDestinationResource Mbeanの |
|
この操作には、次の引数が含まれます。 |
次の項では、ファイル・ベースの永続性について説明します。
ファイル・ベースの永続性が有効の場合、OC4Jでは、次の操作が自動的に実行されます。
OC4Jサーバーがアクティブなときに、永続性ファイルのコピー、削除または名前変更を実行しないでください。このような操作を実行すると、データが破損してメッセージが消失する可能性があります。
OC4Jがアクティブではないときに、永続性ファイルを削除すると、その永続性ファイルに関連付けられている宛先からすべてのメッセージおよび永続サブスクリプションが削除されます。ファイルは、OC4Jの再起動時に、JMSサーバーにより通常の方法で再度初期化されます。
詳細は、「永続性ファイルの管理」を参照してください。
注意
永続性が有効化されていても、ファイルに残るのは特定のメッセージのみです。メッセージが永続化されるためには、次の条件がすべて満たされている必要があります。
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コンソールで永続性ファイルのパラメータを指定します。
「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のファイル・ベースの永続性オプションでは、発生する可能性のある一部の障害からのリカバリが可能ですが、すべての障害からリカバリできるわけではありません。次のいずれかの障害が発生した場合、永続性ファイルのリカバリ可能性は保証されません。
java.io.FileDescriptor.sync()の失敗: sync()コールが、指定のディスクリプタに関連付けられているファイル・バッファすべてを、基礎となるファイル・システムに正常かつ完全にフラッシュしない場合。
JMSサーバーの稼働中は、現在使用中の永続性ファイルのコピー、削除または名前変更を実行しないでください。使用中の永続性ファイルに対してこれらのアクションを実行すると、リカバリ不可能なエラーが発生します。
ただし、OEMSサーバーで永続性ファイルが使用されていない場合は、これらのファイルに対して次の管理およびメンテナンス操作を実行できます。
永続性ファイルの連結、分割、並替え、マージはできません。このような操作を実行すると、永続性ファイル内のデータが破損し、リカバリ不可能になります。
OEMS JMSのメモリー内およびファイル・ベースのオプションでは、内部構成およびトランザクション状態管理のために、ユーザー指定の永続性ファイルとロック・ファイルに加えて特殊ファイルjms.stateが使用されます。OEMS JMSサーバーは、通常の操作中にこのファイルとその内容をクリーン・アップします。アーカイブを目的とする場合でも、このファイルは削除、移動、コピーまたは変更しないでください。jms.stateファイルを操作すると、メッセージとトランザクションが消失する可能性があります。
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
jms/Oc4jJmsExceptionQueue
Oc4jJmsExceptionQueue例外キューは、JMSサーバーとそのクライアントで常に使用可能です。jms.xml構成ファイルで明示的に定義することはできません。定義しようとすると、エラーが発生します。例外キューの名前、JNDIロケーション、およびpersistenceディレクトリへのパス名は、各ネームスペースにおける予約語になります。これらの名前で他のエンティティを定義しようとすると、エラーが発生します。
メッセージは、期限切れまたはリスナー・エラーが原因で配信できなくなることがあります。次の項では、期限切れで配信できないメッセージに対して実行される操作について説明します。
デフォルトでは、永続的な宛先に送信されたメッセージが期限切れになると、そのメッセージは例外キューに移動されます。期限切れになったメッセージのJMSXStateは、EXPIREDを示す値である3に設定されますが、メッセージ・ヘッダー、プロパティおよびボディは特に変更されません。メッセージはObjectMessageにラップされ、ラップされたメッセージが例外キューに送られます。
ラップしているObjectMessageのDeliveryModeは、元のメッセージと同じです。
デフォルトでは、非永続的または一時的な宛先オブジェクトで期限切れになったメッセージは、例外キューに移動されません。通常、これらの宛先オブジェクトに送信されたメッセージは、永続化の必要がないと判断され、期限切れバージョンも存在しません。
送信先となる宛先オブジェクトが永続的、非永続的、一時的のいずれであるかにかかわらず、期限切れのメッセージをすべて例外キューに送信するよう指定できます。これには、OC4Jサーバーの起動時に、oc4j.jms.saveAllExpired管理プロパティをtrueに設定します（表4-6「システム・プロパティ」を参照）。この場合、期限切れのメッセージはすべて例外キューに移動します。これにより、非永続的なメッセージが例外キューに送られた場合でも、その非永続的な性質は変化しません。
OEMS JMSのメモリー内およびファイル・ベースのオプションでは、次の場合にメッセージ本文のページング・インおよびページング・アウトがサポートされます。
ページングされるのはメッセージ本文のみです。メッセージ・ヘッダーとプロパティは、ページングされません。ページングしきい値は、システム・プロパティの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ファイルに永続化されます。
「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で使用中のメモリー量の見積です。この値の範囲は、 詳細は、「メッセージのページング」を参照してください。 |
|
|
OC4Jサーバー |
このプロパティは下位互換性のためにのみ使用します。デフォルトでは無効化されています。 XAまたはXA JMS以外の接続をOC4Jグローバル・トランザクションに登録するには、この構成プロパティは設定しないでください。かわりに次のようにします。 JMS APIを使用して、OC4J-JMSのjavax.jms.XA*実装を使用しているOC4Jグローバル・トランザクションにXA接続を明示的に登録します。また、XA JMS以外の接続から作成された、指定の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ファイルが含まれている必要があります。
OEMS JMSのデータベースの永続性オプションは、Oracle Database Streams Advanced Queuing（AQ）機能へのJMSインタフェースです。この項では、AQを永続的なメッセージ・ストアとして使用するOEMS JMSの構成方法と使用方法について詳細に説明します。
OEMS JMSのメモリー内およびファイル・ベースのオプションと同様に、OEMS JMSのデータベースのオプションを通じてAQにアクセスする場合は、アプリケーションでJMSコネクタを使用することをお薦めします。
AQを使用してOEMS JMSを構成する方法の詳細は、『Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイドおよびリファレンス』を参照してください。
この項には、次の項目が含まれます。
OEMS JMSのデータベース・オプションで、リソース・プロバイダの宛先オブジェクト（キューおよびトピック）を作成してアクセスする手順は、次のとおりです。
orion-application.xmlファイルの<resource-provider>要素にOEMS JMSのデータベース・オプションを定義します。
管理者またはDBAは、『Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイドおよびリファレンス』および共通のデータベース・マニュアルに従って、OEMS JMSをインストールする必要があります。OEMS JMSのインストールおよび構成後に、追加の構成を適用します。これには、次が含まれます。
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のデータベースにキューとトピックを作成します。
トピックとキューの両方でキュー表を使用します。次の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に設定します。
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を参照してください。
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.*インタフェースを示します。
アプリケーションで（<res-type>要素の指定どおり）javax.jms.TopicConnectionFactoryを必要とする場合、適切なコネクション・ファクトリを戻すタイプ名は、TopicConnectionFactoriesおよびXATopicConnectionFactoriesのみです。
OEMS JMSのデータベース・オプションの宛先の場合:
typeNameは、宛先タイプに応じて次のいずれかになります。
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ファイルが含まれている必要があります。
この項では、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のリソース・プロバイダ参照を宣言する手順は、次のとおりです。
次の例は、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>
この例は、デモ・セットの環境での構成方法を示しています。この例は、デモ作成者の環境にのみ適用されるため、他の環境で使用する場合は適切に編集する必要があります。
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のリソース・プロバイダ参照を宣言する手順は、次のとおりです。
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>
この例は、デモ・セットの環境での構成方法を示しています。この例は、デモ作成者の環境にのみ適用されるため、他の環境で使用する場合は適切に編集する必要があります。
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のリソース・プロバイダ参照を宣言する手順は、次のとおりです。
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>
この例は、デモ・セットの環境での構成方法を示しています。この例は、デモ作成者の環境にのみ適用されるため、他の環境で使用する場合は適切に編集する必要があります。
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コネクタは、接続先の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コネクタ・モジュールを作成および構成する手順は、次のとおりです。
ra.xml、oc4j-ra.xmlおよびoc4j-connectors.xmlファイルを変更します。
.rarファイルを作成します（ファイル名は任意です）。META-INF/ra.xml
META-INF/oc4j-ra.xml
oc4j-connectors.xmlを配置します。
Application Server Controlコンソールは、JMSコネクタを構成するための主要ツールです。
デフォルト・アプリケーションには、デフォルトのJMSコネクタ用に次の宛先オブジェクトが定義されています。
OracleASjms/MyQueue1にバインドされたキュー
OracleASjms/MyTopic1にバインドされたトピック
OracleASjms/Queuesにバインドされたキューの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 | |
|---|---|---|
|
デフォルトのキュー・コネクション・ファクトリ |
|
|
|
デフォルトのトピック・コネクション・ファクトリ |
|
|
|
デフォルトの統合コネクション・ファクトリ |
|
|
この表のデフォルト・コネクション・ファクトリは、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コネクタのコネクション・ファクトリおよび宛先を構成する方法（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コネクタの構成設定とその説明を示します。
「OC4J: ホーム」→「アプリケーション」タブ→「ビュー: スタンドアロン・リソース・アダプタ」→「OracleAS JMS」
| コンソール設定 | XML永続性ファイル | 説明 |
|---|---|---|
|
「OC4J: ホーム」→「アプリケーション」タブ→「ビュー: スタンドアロン・リソース・アダプタ」→「OracleAS JMS」→「コネクション・ファクトリ」タブ→「作成」ボタン 図4-1の矢印番号14のリンク参照。 |
この設定は、 |
コネクション・ファクトリ・インタフェース設定では、作成するコネクション・ファクトリのタイプを定義します。 |
|
図4-1の矢印番号5のリンク・キー。 |
この設定は、 |
JNDIロケーション設定では、リソース・アダプタの新規コネクション・ファクトリをバインドするJNDIロケーションを指定します。EISに接続するアプリケーション・コンポーネントがコネクション・ファクトリを特定できるように、有効なJNDIロケーションを入力します。 このJNDIロケーションは、jndiLocationとは異なることに注意してください。 |
|
接続プーリング |
この設定は、 |
接続プーリングにより、EISへの一連の接続をアプリケーション内で再利用できます。アプリケーションでは、独自の排他的接続プールを作成するか、このリソース・アダプタで使用可能ないずれかの共有接続プールを使用するかを選択できます。
|
|
図4-1の矢印番号16のリンク参照。 |
この設定は、 |
このjndiLocationは、JNDIロケーションとは異なることに注意してください。 |
|
|
この設定は、 |
|
|
「OC4J: ホーム」→「アプリケーション」タブ→「ビュー: スタンドアロン・リソース・アダプタ」→「OracleAS JMS」→「管理対象オブジェクト」タブ→「作成」ボタン オブジェクト・クラス |
この設定は、 |
|
|
図4-1の矢印番号7および11のリンク・キー。 |
この設定は、 |
|
|
図4-1の矢印番号13のリンク参照。 |
この設定は、 |
注意: この |
|
図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リソース・アダプタ構成ファイル」を参照してください。
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エンドポイントの微調整に使用可能な構成プロパティを説明します。
リスナー・スレッドの動的負荷調整は、次の<activation-config>プロパティに基づきます。表4-11「MDBの構成プロパティ」で説明されています。
MDBインスタンスの動的負荷調整を含むMDB構成の詳細は、『Oracle Containers for J2EE Enterprise JavaBeans開発者ガイド』を参照してください。
この項では、クライアント・アプリケーションで論理名を使用する方法について説明します。これにより、OC4Jに固有ではないデプロイメント・ディスクリプタに含まれるインストール環境固有のJMS構成に依存する設定の数を減らすことができます。この間接化により、クライアント実装を任意のJMS構成に対して汎用的にすると同時に、特定のJMSリソース・プロバイダから分離することができます。
論理名を使用すると、リソース・プロバイダに依存しないクライアント・アプリケーション・コードを作成できます。論理名を構成および使用する一般的な手順は、次のとおりです。
application-client.xmlやejb-jar.xmlなど）で論理名を宣言します。
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デプロイメント・ファイルに論理名を宣言する必要があります。
application-client.xmlファイル
ejb-jar.xmlファイル
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>要素に指定します。
ContainerまたはApplication）を<res-auth>要素に指定します。
ShareableまたはUnshareable）を<res-sharing-scope>要素に指定します。
<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デプロイメント・ディスクリプタ・ファイルで定義します。
orion-application-client.xmlファイルに定義します。
orion-ejb-jar.xmlファイルに定義します。
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を初期コンテキスト・ファクトリ・オブジェクトとして使用します。
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/myApplicat ionDeploymentName java.naming.security.principal=oc4jadmin java.naming.security.credentials=welcome
ApplicationClientInitialContextFactoryを初期コンテキスト・ファクトリ・オブジェクトとして使用します。
jndi.propertiesファイルの詳細な例は、http://www.oracle.com/technology/tech/java/oc4j/1013/how_to/index.htmlを参照してください。
次のファイルを見つけてください。
/src/client/jndi.properties
リソースを定義してJNDIプロパティを構成した後、クライアントでは、次の手順に従ってJMSメッセージを送信する必要があります。この手順は、「JMSメッセージの送受信」に記載されている手順を要約したものです。
JMSコネクタをアプリケーション・クライアントから使用する場合、表4-12「JMSコネクタのルックアップに必要なクライアント・サイドのJARファイル」にリストされたクラスパスに各JARファイルが含まれている必要があります。
可用性の高いJMSサーバーは、JMS要求がソフトウェアまたはハードウェア障害による中断なしで処理されるという保証を提供します。高可用性を実現する方法の1つはフェイルオーバー機能を使用することです。サーバー・インスタンスの1つに障害が発生すると、ソフトウェア、ハードウェアおよびインフラストラクチャ・メカニズムの組合せにより、別のサーバー・インスタンスが要求の処理を引き継ぎます。
高可用性の詳細は、『Oracle Application Server高可用性ガイド』を参照してください。
表4-13「高可用性の概要」に、OEMS JMSでの高可用性のサポートを示します。
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管理者ガイド』を参照してください。
ORACLE_HOME）
この構成では、OHSは、HTTPリクエストを処理し、Oracle Application Serverクラスタ内の2つ以上のOracle Application Serverインスタンス間でリクエストのロード・バランシングを実行します。
宛先のコピーはそれぞれ一意で、OC4Jインスタンス間ではレプリケートまたは同期化されません。宛先は、永続的でもメモリー内でもかまいません。1つのOC4Jインスタンスにエンキューされたメッセージは、そのOC4Jインスタンスからでなければデキューできません。
この種のデプロイメントには、次のような多数のメリットがあります。
各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高可用性ガイド』を参照してください。
次の例に示すように、両方のノードを同じ構成にします。両方の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つの変更を加える必要があります。
JMSserver）用に起動されるJVMが1つのみであることを確認します。OC4Jインスタンス内のJVMを1つに限定することで、他のJVMが同じ永続性ファイル・セットを使用しないことが保証されます。
ポート値を1つにすると、OPMNでは、常にこの値が専用JMSサーバーに割り当てられます。このポート値を使用して、jms.xmlファイル内でコネクション・ファクトリを定義できます。他のOC4Jインスタンスは、これを専用JMSサーバーへの接続に使用します。
OPMNと動的ポート割当ての詳細は、『Oracle Process Manager and Notification Server管理者ガイド』を参照してください。
次のXMLは、opmn.xmlファイルからの抜粋であり、必要な変更内容と変更する場所を示しています。
JMSserverが作成されたと仮定すると、(1)で示されている行は、JMSserver定義の開始位置を示しています。
3701-3800でした。今回のコネクション・ファクトリ定義では、この値を3701-3701に構成してポートを使用します。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.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サーバーの観点から検討すると、次のようになります。
persistence-file属性（またはこの属性の欠如）は、JMSサーバーに対し、特定の物理宛先のメッセージを永続化する場所を示します。
name属性の値を含む）宛先管理オブジェクトをバインドするローカルJVMのJNDIロケーションを示します。
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の結果となることを示しています。
この例（および分散宛先構成でのコネクション・ファクトリ）では、様々なJVMで同じJNDIロケーションに異なる値をバインドしているか、異なる値を必要とするため、あるJVMから別のJVMにJNDI値を自動的に伝播できません。
次の組合せを使用する場合について検討します。
この組合せでは、次の要件に注意する必要があります。
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つの使用例と、各使用例でスループットを改善するために使用できるカスタム・トポロジについて説明します。これらの例は、実際の状況的にも作成可能なトポロジ的にも、完全なものではありません。
一部の宛先では専用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つの宛先（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のデータベース・オプションで高可用性を実現するには、次のようにします。
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ネットワーク・フェイルオーバー」を参照してください。致命的エラーでない場合、クライアントは短時間だけスリープした後、現行の操作を再試行してリカバリします。
次の例は、任意の永続性オプションで使用できる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>
JMSExceptionが発生して失敗します。
複雑な異機種間エンタープライズ・コンピューティング環境では、様々なメッセージング・システムと統合して相互運用するメッセージング・インフラストラクチャが必要です。JMSルーターにより、次の宛先間をブリッジできる信頼性の高い非同期JMSメッセージ・ルーティング・サービスが提供されます。
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ルーターには、次のメリットがあります。
JMSルーターでは、JMSコネクタを使用して次の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ルーター・ジョブでは、表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で使用できる操作および設定について説明します。
「OC4J: ホーム」→「管理」タブ→「サービス」→「JMSプロバイダ」→アイコンをクリック→適切なタブを選択→「関連リンク: OracleAS JMS Router」
次の表に、JMSルーターMBeanで使用可能な操作とその説明を示します。すべての操作はJMSルーターを動的に更新し、その変更はjms.xmlに永続化されます。
表4-16「JMSルーター設定」に、JMSルーターMBeanでのルーター設定およびルーター・ジョブ設定とその説明を示します。表の最初の列は、JMSルーターMBeanでの設定の名前です。JMSルーターMBeanで実行した設定は、jms.xmlファイルに永続化されます。表の2番目の列は、jms.xmlファイルでの対応する要素の名前です。
J2EE_HOME/config/jms.xmlファイルは、JMSルーター・ジョブおよびグローバル構成を永続化するのに使用されます。
JMSルーターは、jms.xmlファイルの<jms-router>要素で構成します。<jms-router>要素には、0個以上の<router-job>要素が含まれます。JMSルーター・ジョブは、<router-job>要素で定義します。
jms.xmlファイルのJMSルーター要素とその説明は、表4-16「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ルーター・ジョブの構成を定義しますが、このジョブは、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ルーターMBeanの操作とその説明は、表4-15「JMSルーターMBeanの操作」を参照してください。
「OC4J: ホーム」→「管理」タブ→「サービス」→「JMSプロバイダ」→アイコンをクリック→適切なタブを選択→「関連リンク: OracleAS JMS Router」
JMSルーターは、すべての重要なイベントおよびエラー・メッセージをOC4Jの標準ログ・ファイルに記録します。ログ出力名は、oracle.j2ee.jms.routerです。
JMSルーターの実行時ステータス情報にアクセスするには、JMSルーターMBeanのRouterJobsStatusおよびRouterGlobalStatus属性を使用します。
JMSルーター・ジョブの処理中には、ソースまたはターゲット宛先への接続障害やメッセージ操作の失敗などの様々な障害が発生する可能性があります。JMSルーターは、障害の性質やルーター・ジョブの構成に基づいて、障害を次のように処理します。
JMSルーターが、メッセージの内容を原因としてターゲット宛先にメッセージをエンキューできない場合で、かつ
useExceptionQueueフラグがfalseに設定されている場合、JMSルーターは、ルーター・ジョブの処理を停止します。
useExceptionQueueフラグがtrueに設定されている場合、JMSルーターは、そのメッセージを例外キューに移動して後続のメッセージの処理を続けます。
メッセージがソース宛先から例外キューに移動される場合、エラー情報の維持を目的として、JMSルーターにより元のメッセージに特定のメッセージ・プロパティが追加されます。表4-18「例外キューのメッセージに追加されるプロパティ」に、これらのメッセージとその説明を示します。
障害の原因がメッセージの内容ではない場合、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ルーター・ジョブでは、一般的なソース（キューまたは永続サブスクライバ）を共有することはできません。違反した場合、JMSルーター・ジョブにリカバリ不可能な障害が発生する可能性があります。OC4Jクラスタ環境では、クラスタ内のすべての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つです。
次の表に、<http-tunnel>ノードの構成要素を示します。
次の例では、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のコネクション・ファクトリ属性も設定されています。
次の例では、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トネリングが使用されている場合、これらのイントラネットの管理者は、ホスト名の競合を避けるためにそれぞれを調整する必要があります。
この項では、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>
|
注意
|
|
 Copyright © 2006 Oracle Corporation. All Rights Reserved. |
|