6 JMSアプリケーション・モジュールのデプロイメントの構成

この章では、WebLogic Server 12.1.3でJMSアプリケーション・モジュールをデプロイするために構成する方法について説明します。また、Java EEエンタープライズ・アプリケーションでパッケージ化されたJMSアプリケーション・モジュールや、グローバルに使用できるスタンドアロン・アプリケーション・モジュールについても説明します。

この章の内容は次のとおりです。

• JMSアプリケーション・モジュールの構成方法

• JMSスキーマ

• JMSアプリケーション・モジュールのエンタープライズ・アプリケーションへのパッケージ化

  • パッケージ化JMSアプリケーション・モジュールの主な作成手順

  • パッケージ化JMSアプリケーション・モジュールを作成する

  • EJBアプリケーション内のパッケージ化JMSアプリケーション・モジュールのサンプル

  • エンタープライズ・アプリケーションをJMSアプリケーション・モジュールと共にパッケージ化する

  • パッケージ化JMSアプリケーション・モジュールをデプロイする

• スタンドアロンJMSアプリケーション・モジュールをデプロイする

• JMSリソースの一意の実行時JNDI名の生成

JMSアプリケーション・モジュールの構成方法

注意:

アプリケーションがデプロイされた後で、アプリケーションのスコープ内で構成されたJMSリソースを変更することはできません。また、アプリケーション・モジュールで作成された宛先を直接削除するオプションはありません。アプリケーションをアンデプロイしても、宛先は削除されません。これらの理由から、かわりにJMSシステム・モジュールを使用して接続ファクトリと宛先を構成することをお薦めします。詳細は、 「JMSシステム・モジュールの構成」を参照してください

JMSシステム・モジュールに構成できるすべてのJMSリソースは、標準Java EEモジュールと同様にデプロイ可能なアプリケーション・モジュールとして構成および管理できます。デプロイされたJMSアプリケーション・モジュールの所有者は、モジュールをデプロイした管理者ではなく、モジュールを作成およびパッケージ化した開発者となります。したがって、デプロイしたリソースに対しては、管理者の制御が及ぶ範囲がより制限されます。

たとえば、管理者はデプロイメント時にデプロイメント・プラン(JSR-88)を使用して、モジュール内に指定されたリソースの特定のプロパティのみを修正(オーバーライド)することはできますが、リソースを動的に追加したり削除することはできません。他のJava EEモジュールのように、アプリケーション・モジュールの構成の変更はモジュールのデプロイメント・プランに格納され、元のモジュール自体は変更されません。

アプリケーション開発者は、こうしたツールを使用してシステム・リソースを作成およびデプロイ(ターゲット指定)できます。:

• 「JMSシステム・モジュールの構成」の説明に従ってJMSシステム・モジュールを作成し、生成されるXMLファイルを別のディレクトリにコピーして、ファイル接尾辞として-jms.xmlを付加した名前に変更します。

• エンタープライズ・レベルのIDEまたはXMLファイルの編集に対応した開発ツールでアプリケーション・モジュールを作成し、そのJMSモジュールをアプリケーションの一部としてパッケージ化して、デプロイのためにWebLogic管理者に渡します。

• ソース・コード・アノテーションに基づいて、Java EE接続ファクトリとアプリケーション・モジュールを暗黙的に作成する宛先定義を使用してください。「Java EEリソース定義を使用したJMSリソースの定義」を参照してください。

JMSスキーマ

WebLogic Server 9.x以上では、JMSリソース用にモジュール形式のデプロイメント・モデルをサポートするために、WebLogic JMSリソースの定義に使用するweblogic-jms.xsdというスキーマが用意されています。JMSモジュール(記述子)を作成する際は、モジュールをこのスキーマに準拠させる必要があります。IDEや他のツールでは、このスキーマに基づいてJMSモジュールを検証できます。

weblogic-jms.xsdスキーマは、http://xmlns.oracle.com/weblogic/weblogic-jms/1.4/weblogic-jms.xsdからオンラインで入手できます(新しいウィンドウが開きます)。

スキーマ内のJMSリソース定義については、Oracle WebLogic Server MBeanリファレンスのSystem Module MBeansフォルダ内の対応するシステム・モジュールBeanの説明を参照してください。JMSモジュールのルートBeanはJMSBeanで、JMSモジュール全体を表します。

Java EEリソース定義を使用したJMSリソースの定義

Java EE 7プラットフォーム仕様で定義されているとおり、WebLogic Serverを使用すると、@JMSConnectionFactoryDefinitionおよび@JMSDestinationDefinitionアノテーションを使用するか、<jms-destination>および<jms-connection-factory>要素を使用して、JMSリソースを定義できます。これらのJMSリソース定義を使用すると、アプリケーションを最小管理構成でJava EE環境にデプロイできます。この項では、次の項目について説明します。

• アノテーションを使用するリソース定義

• デプロイメント記述子におけるリソース定義

• JMSリソース定義の考慮事項とベスト・プラクティス

注意:

アプリケーションがデプロイされた後で、アプリケーションのスコープ内で構成されたJMSリソースを変更することはできません。また、アプリケーション・モジュールで作成された宛先を直接削除するオプションはありません。アプリケーションをアンデプロイしても、宛先は削除されません。これらの理由から、かわりにJMSシステム・モジュールを使用して接続ファクトリと宛先を構成することをお薦めします。詳細は、「JMSシステム・モジュールの構成」を参照してください。

アノテーションを使用するリソース定義

Webモジュール、EJBモジュールまたはアプリケーション・クライアント・モジュールの内部で、アノテーション@JMSConnectionFactoryDefinitionおよび@JMSDestinationDefinitionsを定義できます。これらのクラス内部では、アノテーションを使用してリソースを定義することもできます。

• application.xmlデプロイメント記述子の<library-directory>要素で定義されたライブラリで定義されたクラス

• EJB jarファイルまたは.warファイルのClass-pathエントリによって参照されている.jarファイル内のクラス

これが定義されると、コンポーネントは@Resourceアノテーションのlookup要素を使用するか、resource-refデプロイメント・ディスクリプタ要素のlook-up要素を使用して、リソースを参照できます。

例6-1 例: JMS接続ファクトリの定義

@JMSConnectionFactoryDefinition(   name="java:app/MyJMSConnectionFactory",   interfaceName="javax.jms.QueueConnectionFactory").

例6-2 例: JMS宛先の定義

@JMSDestinationDefinition(   name="java:app/MyJMSQueue",   interfaceName="javax.jms.Queue",   destinationName="myQueue1")

リソース定義で使用できる要素とプロパティの詳細は、「JMSリソース定義要素リファレンス」を参照してください

デプロイメント記述子におけるリソース定義

アノテーションを使用するかわりに、デプロイメント記述子内で<jms-destination>および<jms-connection-factory>要素を使用して、リソースを定義できます。

JMSコネクション・ファクトリの定義

ejb-jar.xmlまたはweb.xmlデプロイメント記述子内で、jms-connection-factory要素を使用して、JMS宛先リソースを定義できます。接続ファクトリが作成され、指定されるネームスペースに基づいて適切な名前コンテキストにバインドされます。

次の例は、場所java:app/MyJMSConnectionFactoryでJNDIにバインドされた接続ファクトリを定義します。

<jms-connection-factory>   <description>Sample JMS ConnectionFactory definition</description>   <name>java:app/MyJMSConnectionFactory</name>   <interface-name>javax.jms.QueueConnectionFactory</interface-name>   <user>scott</user>   <password>tiger</password>   <client-id>MyClientId</client-id>   <property>     <name>Property1</name>     <value>10</value>  </property>   <property>     <name>Property2</name>     <value>20</value>   </property>   <transactional>false</transactional>   <max-pool-size>30</max-pool-size>   <min-pool-size>20</min-pool-size> </jms-connection-factory>

jms-connection-factory要素やその属性の詳細は、http://xmlns.jcp.org/xml/ns/javaee/javaee_7.xsdにあるスキーマを参照してください

JMS宛先の定義

ejb-jar.xmlまたはweb.xmlデプロイメント記述子内で、jms-destination要素を使用して、JMS宛先リソースを定義できます。宛先が作成され、指定されるネームスペースに基づいて適切な名前コンテキストにバインドされます。

次の例は、場所java:app/MyJMSDestination:でJNDIにバインドされたキュー宛先myQueue1を定義します

<jms-destination>   <description>JMS Destination definition</description>   <name>java:app/MyJMSDestination</name>   <interface-name>javax.jms.Queue</interface-name>   <destination-name>myQueue1</destination-name>   <property>     <name>Property1</name>     <value>10</value>   </property>   <property>     <name>Property2</name>     <value>20</value>   </property> </jms-destination>

jms-destination要素やその属性の詳細は、http://xmlns.jcp.org/xml/ns/javaee/javaee_7.xsdにあるスキーマを参照してください

JMSリソース定義の考慮事項とベスト・プラクティス

新しいアノテーションを使用して定義されたリソースの考慮事項を以下に示します。

• 次に示す許可されたJNDIネームスペースのいずれかにJMSリソースを定義します。

  • java:comp

  • java:module

  • java:app

  • java:global

• JNDI名がjava:で始まるが、前述のネームスペース接頭辞のいずれでも始まっていない場合は、デプロイメント時に例外が発生します。

• JNDI名がjava:で始まらない場合、宛先または接続ファクトリは java:comp/env namespaceで定義されます。たとえば、jms/myDestinationという形式のJNDI名は、java:comp/env/jms/myDestinationと同じと見なされます。

• WebLogic Serverでは、アプリケーションは宛先をapplication.xmlデプロイメント記述子のjava:appおよびjava:globalネームスペースで、または、Webモジュール、EJBモジュールまたはアプリケーション・クライアント・モジュール内のクラス以外のアプリケーション・パッケージにあるクラス上のアノテーションを使用して定義できます。

• @JMSDestinationDefinition を使用して定義された宛先は、内部的に共通分散宛先(キューまたはトピック)として作成されます。デフォルトでは、タイプjavax.jms.Topicの@JMSDestinationDefinition (interfaceNameを指定)を使用して作成される共通分散トピックのForwarding Policyオプションの値は「Partitioned」になります。アプリケーション・デプロイメント時に、値を「レプリケート」に指定できます。ただし、リソース・グループまたはリソース・グループ・テンプレートでForwarding Policyを「replicated」として使用することは、適格性チェックで制限されます。詳細は、Oracle WebLogic Server JMSアプリケーションの開発の分散トピックのベスト・プラクティスを参照してください。

• @JMSDestinationDefinitionを使用してキューを定義するアプリケーションがアンデプロイされている場合、永続ストアは受信または消費されていないメッセージを保持します。これらのメッセージはアプリケーションの再デプロイ時に、宛先の消費者が利用できます。

@JMSConnectionFactoryDefinitionの詳細は、http://docs.oracle.com/javaee/7/api/javax/jms/JMSConnectionFactoryDefinition.htmlを参照してください

@JMSDestinationDefinitionの詳細は、http://docs.oracle.com/javaee/7/api/javax/jms/JMSDestinationDefinition.htmlを参照してください

JMSアプリケーション・モジュールのエンタープライズ・アプリケーションへのパッケージ化

JMSアプリケーション・モジュールは、パッケージ化されたモジュールのように、エンタープライズ・アプリケーション・アーカイブ(EAR)の一部としてパッケージ化できます。パッケージ化されたモジュールは、EARまたは展開されたEARディレクトリにバンドルされ、weblogic-application.xml記述子内で参照されます。

パッケージ化されたJMSモジュールは、エンタープライズ・アプリケーションと一緒にデプロイされます。このモジュールに定義されたリソースは、同梱されたアプリケーションでのみ利用可能(すなわちアプリケーション・スコープのリソース)にすることもできます。このようなモジュールは、JMSリソースを使用するEJB(特にMDB)またはWebアプリケーションとともにパッケージ化すると、非常に役立ちます。パッケージ化モジュールを使用することにより、アプリケーションで必要なリソースを常に使用でき、アプリケーションを新しい環境に移動する処理が簡素化されます。

パッケージ化JMSアプリケーション・モジュールを作成する

パッケージ化JMSモジュールは、エンタープライズ・レベルのIDEまたはXML記述子ファイルの編集をサポートする他の開発ツールを使用して作成します。スタンドアロンのモジュールをデプロイおよび管理するには、weblogic.Deployerユーティリティ、WebLogic Server管理コンソールなど、JSR 88ベースのツールを使用します。

注意:

WebLogic Server管理コンソールを使用してパッケージ化されたJMSモジュールを作成したら、作成されたXMLファイルを別のディレクトリにコピーし、ファイル接尾辞として-jms.xmlを付加してファイル名を変更します。

パッケージ化JMSアプリケーション・モジュールの要件

EARファイル内では、JMSモジュールが以下の条件を満たしている必要があります。

• http://xmlns.oracle.com/weblogic/weblogic-jms/1.4/weblogic-jms.xsdスキーマに準拠している

• ファイル接尾辞として-jms.xmlを使用します(例: MyJMSDescriptor-jms.xml)

• WebLogicドメイン内で一意の名前が付けられており、Java EEアプリケーションのルートからの相対パスが指定されている

パッケージ化JMSアプリケーション・モジュールの主な作成手順

パッケージ化JMSモジュールを構成するには:

1. 必要に応じて、JMSモジュールをターゲット指定するJMSサーバーを作成します。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMSサーバーの構成を参照してください。

2. JMSシステム・モジュールを作成し、必要なリソース(キュー、トピックなど)を構成します。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMSシステム・モジュールの構成およびJMSリソースの追加を参照してください。

3. システム・モジュールは、ドメイン・ディレクトリのconfig\jmsサブディレクトリに、接尾辞-jms.xmlが付加された形で保存されます。

4. システム・モジュールを新しい場所にコピーしてから以下を行います。

   1. モジュールの名前を、ドメイン・ネームスペース内で一意の名前に変更します。

   2. JNDI-Name属性を削除して、そのアプリケーションでのみ使用できるアプリケーション・スコープのモジュールにします。

5. 該当するすべてのJava EEアプリケーション・コンポーネントのディスクリプタ・ファイルに、モジュール内のJMSリソースへの参照を追加します。Oracle WebLogic Server JMSアプリケーションの開発のデプロイメント・ディスクリプタ・ファイルにおけるパッケージ化JMSアプリケーション・モジュールの参照を参照してください。

6. EAR内のすべてのアプリケーション・モジュールをパッケージ化します。「エンタープライズ・アプリケーションをJMSアプリケーション・モジュールと共にパッケージ化する」を参照してください

7. EARをデプロイします。「パッケージ化JMSアプリケーション・モジュールをデプロイする」を参照してください

EJBアプリケーション内のパッケージ化JMSアプリケーション・モジュールのサンプル

次のコード・スニペットは、パッケージ化JMSモジュールappscopedejbs-jms.xmlの例です。このモジュールは、図6-1のようにディスクリプタ・ファイルで参照されています。

<weblogic-jms xmlns="http://xmlns.oracle.com/weblogic/weblogic-jms">
  <connection-factory name="ACF">
  </connection-factory>
  <queue name="AppscopeQueue">
  </queue>
</weblogic-jms>

図6-1に、パッケージ化JMSモジュールのJMS接続ファクトリ・リソースとキュー・リソースが、EJB EARファイルで参照されている様子を示します。

図6-1 JMSアプリケーション・モジュールとEJBアプリケーションの記述子との関係

「図6-1 JMSアプリケーション・モジュールとEJBアプリケーションの記述子との関係」の説明

weblogic-application.xmlでパッケージ化JMSアプリケーション・モジュールを参照する

エンタープライズ・アプリケーションにJMSモジュールを含める際は、アプリケーションと一緒にパッケージ化されたweblogic-application.xml記述子ファイルで、JMSタイプのモジュール要素として各JMSモジュールを列挙し、アプリケーションのルートからの相対パスを指定する必要があります。例:

<module>
  <name>AppScopedEJBs</name>
  <type>JMS</type>
  <path>jms/appscopedejbs-jms.xml</path>
</module>

ejb-jar.xmlでパッケージ化JMSアプリケーション・モジュールを参照する

アプリケーション内のEJBで、アプリケーションと一緒にパッケージ化されたJMSモジュールを介して接続ファクトリを使用している場合は、JMSモジュールをres-ref要素として列挙し、EJBと一緒にパッケージ化されたejb-jar.xml記述子ファイルにres-ref-nameパラメータとres-typeパラメータを含める必要があります。これにより、アプリケーションのローカル・コンテキストで、EJBがJMS接続ファクトリをルックアップできるようになります。例:

<resource-ref>
  <res-ref-name>jms/QueueFactory</res-ref-name>
  <res-type>javax.jms.QueueConnectionFactory</res-type>
</resource-ref>

res-ref-name要素により、java:comp/envで使用するリソース名が、EJBから参照されるモジュールにマップされます。res-type要素には、モジュール・タイプ(この例ではjavax.jms.QueueConnectionFactory)を指定します。

アプリケーション内のEJBで、アプリケーションと一緒にパッケージ化されたJMSモジュールを介してキューまたはトピックを使用している場合は、JMSモジュールをresource-env-ref要素として列挙し、EJBと一緒にパッケージ化されたejb-jar.xml記述子ファイルにresource-env-ref-nameパラメータとresource-env-ref-typeパラメータを含める必要があります。これにより、アプリケーションのローカル・コンテキストで、EJBがJMSキューまたはトピックをルックアップできるようになります。例:

<resource-env-ref>
  <resource-env-ref-name>jms/Queue</resource-env-ref-name>
  <resource-env-ref-type>javax.jms.Queue</resource-env-ref-type>
</resource-env-ref>

resource-env-ref-name要素により、EJBによって参照されるモジュールに宛先名がマップされます。res-type要素には、キューの名前(この例ではjavax.jms.Queue)を指定します。

weblogic-ejb-jar.xmlでパッケージ化JMSアプリケーション・モジュールを参照する

参照されるJMSモジュールをres-ref-name要素として列挙し、EJBと一緒にパッケージ化されているweblogic-ejb-jar.xml記述子ファイルのresource-linkパラメータに含める必要があります。

<resource-description>
  <res-ref-name>jms/QueueFactory</res-ref-name>
  <resource-link>AppScopedEJBs#ACF</resource-link>
</resource-description>

res-ref-name要素により、EJBによって参照されるモジュールに接続ファクトリ名がマップされます。resource-link要素では、JMSモジュール名の後ろにシャープ記号(#)の区切り文字を付加し、その後ろにモジュール内のリソースの名前を指定します。この例では、接続ファクトリACFを含むJMSモジュールAppScopedEJBsが、AppScopedEJBs#ACFという名前で指定されています。

上の例の続きでは、res-ref-name要素によって、EJBが参照するモジュールにキュー名もマップされます。そのresource-link要素では、次のようにキューAppScopedQueueの名前がAppScopedEJBs#AppScopedQueueになります。

<resource-env-description>
  <resource-env-ref-name>jms/Queue</resource-env-ref-name>
  <resource-link>AppScopedEJBs#AppScopedQueue</resource-link>
</resource-env-description>

エンタープライズ・アプリケーションをJMSアプリケーション・モジュールと共にパッケージ化する

JDBCモジュールを含むアプリケーションは、他のエンタープライズ・アプリケーションと同じようにパッケージ化します。Oracle WebLogic Serverアプリケーションの開発のwlpackageを使用したアプリケーションのパッケージ化を参照してください。

パッケージ化JMSアプリケーション・モジュールをデプロイする

パッケージ化JMSモジュールのデプロイメントは、アプリケーションの他のコンポーネントと同じモデルに従って行われます。個別のモジュールは、単一のサーバー、クラスタ、またはクラスタの個別のメンバーにデプロイできます。

他のアプリケーション・コンポーネントの推奨ベスト・プラクティスは、Oracle WebLogic Server JMSアプリケーションの開発のデプロイメント・ディスクリプタ・ファイルにおけるパッケージ化JMSアプリケーション・モジュールの参照で説明されているように、java:comp/env JNDI環境を使用してJMSエンティティへの参照を取得することです。(ただし、このプラクティスは必須ではありません。)

パッケージ化JMSモジュールは、定義によってエンタープライズ・アプリケーションに含まれているため、エンタープライズ・アプリケーションをデプロイすると一緒にデプロイされます。パッケージ化JMSモジュールを含むアプリケーションのデプロイメントの詳細は、Oracle WebLogic Serverアプリケーションの開発のwldeployを使用したアプリケーションのデプロイメントを参照してください。

スタンドアロンJMSアプリケーション・モジュールのデプロイ

この節では、以下の内容について説明します。

• スタンドアロンJMSモジュール

• スタンドアロンJMSアプリケーション・モジュールを作成する

• 単純なスタンドアロンJMSアプリケーション・モジュールのサンプル

• スタンドアロンJMSアプリケーション・モジュールをデプロイする

• スタンドアロンJMSアプリケーション・モジュールをチューニングする

スタンドアロンJMSモジュール

JMSアプリケーション・モジュールは、スタンドアロン・モジュールとしてデプロイできます。この場合、アプリケーション・モジュールはデプロイメント・プロセス中にターゲット指定されたサーバーまたはクラスタで使用できます。この方法でデプロイされるJMSモジュールは、weblogic.DeployerユーティリティまたはWebLogic Server管理コンソールで再構成できますが、JMXまたはWLSTでは使用できません。

しかし、WebLogic Serverプラグインに付属の基本的なJSR-88デプロイメント・ツールでは、APIのWebLogic Server拡張を使用せずにスタンドアロンJMSモジュールを使用でき、Java EEアプリケーションやモジュールをWebLogic Serverに構成、デプロイ、および再デプロイできます。WebLogic Serverのデプロイメントについては、Oracle WebLogic ServerへのアプリケーションのデプロイのWebLogic Serverデプロイメントの理解を参照してください。

この方法でデプロイしたJMSモジュールを「スタンドアロン・モジュール」といいます。スタンドアロンJMSモジュール内のリソースは、モジュールがどのようにターゲット指定されているかに応じて、クラスタ内でグローバルに使用できるか、サーバー・インスタンスでローカルに使用できるかが決まります。スタンドアロンJMSモジュールを使用すると、JMSリソースの共有と移植が容易になります。作成したJMSモジュールは他の開発者に配布できます。スタンドアロンJMSモジュールも、ドメイン間でJMS情報を移動するために使用できます。たとえば、JMSを広範囲にわたって手動で再構成することなく、開発ドメインと本番ドメインの間でJMS情報を移動できます。

スタンドアロンJMSアプリケーション・モジュールを作成する

スタンドアロンJMSモジュールは、エンタープライズ・レベルのIDEまたはXML記述子ファイルの編集をサポートする他の開発ツールを使用して作成できます。スタンドアロンのモジュールをデプロイおよび管理するには、weblogic.Deployerユーティリティ、WebLogic Server管理コンソールなどのWebLogic Serverツールを使用します。

注意:

WebLogic Server管理コンソールを使用してJMSアプリケーション・モジュールを作成したら、アプリケーションで使用するテンプレートとしてモジュールをコピーし、ファイル接尾辞として-jms.xmlを付加します。また、ネームスペース内での名前の競合を避けるため、モジュールをアプリケーションと一緒にデプロイする前に、モジュールのName要素とJNDI-Name要素を変更する必要があります。

スタンドアロンJMSアプリケーション・モジュールの要件

スタンドアロンJMSモジュールは、以下の条件を満たしている必要があります。

• http://xmlns.oracle.com/weblogic/weblogic-jms/1.4/weblogic-jms.xsdスキーマに準拠している

• ファイル接尾辞として-jms.xmlを使用します(例: MyJMSDescriptor-jms.xml)

• WebLogicドメイン内で一意の名前を使用します(JMSシステム・モジュールと競合することはできません)

スタンドアロンJMSアプリケーション・モジュールの主な作成手順

スタンドアロンJMSモジュールを構成するには:

1. 必要に応じて、JMSモジュールをターゲット指定するJMSサーバーを作成します。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMSサーバーの構成を参照してください。

2. JMSシステム・モジュールを作成し、必要なリソース(キュー、トピックなど)を構成します。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMSシステム・モジュールの構成およびJMSリソースの追加を参照してください。

3. システム・モジュールは、ドメイン・ディレクトリのconfig\jmsサブディレクトリに、接尾辞-jms.xmlが付加された形で保存されます。

4. システム・モジュールを新しい場所にコピーしてから以下を行います。

   1. モジュールの名前を、ドメイン・ネームスペース内で一意の名前に変更します。

   2. モジュールをグローバルに使用できるようにするには、モジュール内のリソースのJNDI-Name属性を一意の名前に変更します。

   3. 宛先のしきい値や接続ファクトリのフロー・コントロールのパラメータなど、その他の調整可能な値を必要に応じて修正します。

5. モジュールをデプロイします。「スタンドアロンJMSアプリケーション・モジュールをデプロイする」を参照してください

単純なスタンドアロンJMSアプリケーション・モジュールのサンプル

次のコード・スニペットは、単純なスタンドアロンJMSモジュールの例です。

<weblogic-jms xmlns="http://xmlns.oracle.com/weblogic/weblogic-jms">
  <connection-factory name="exampleStandAloneCF">
    <jndi-name>exampleStandAloneCF</jndi-name>
  </connection-factory>
  <queue name="ExampleStandAloneQueue">
    <jndi-name>exampleStandAloneQueue</jndi-name> 
  </queue>
</weblogic-jms>

スタンドアロンJMSアプリケーション・モジュールのデプロイ

weblogic.Deployerユーティリティを使用してスタンドアロンJMSモジュール(前述の例で使用)をデプロイするコマンド・ラインは、次のようになります。

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
-password weblogic \
-name ExampleStandAloneJMS \
-targets examplesServer \
-submoduletargets ExampleStandaloneQueue@examplesJMSServer,ExampleStandaloneCF@examplesServer \
-deploy ExampleStandAloneJMSModule-jms.xml

スタンドアロンJMSモジュールのデプロイについては、Oracle WebLogic ServerへのアプリケーションのデプロイのJDBC、JMS、およびWLDFアプリケーション・モジュールのデプロイを参照してください。

スタンドアロンJMSモジュールをデプロイすると、ドメインのconfig.xmlファイルにapp-deploymentエントリが追加されます。例:

<app-deployment>
  <name>standalone-examples-jms</name> 
  <target>MedRecServer</target> 
  <module-type>jms</module-type> 
  <source-path>C:\modules\standalone-examples-jms.xml</source-path> 
  <sub-deployment>
  ...
  </sub-deployment>
  <sub-deployment>
  ...
  </sub-deployment>
</app-deployment>

モジュールのsource-pathは、絶対パスでも、domainディレクトリからの相対パスでも構いません。この点は、domain\configディレクトリからの相対パスで指定するシステム・リソース・モジュールのdescriptor-file-nameパスとは異なります。

スタンドアロンJMSアプリケーション・モジュールをチューニングする

スタンドアロン・モジュール内でデプロイされたJMSリソースは、リソースがバインド可能(JNDI名など)または調整可能(宛先のしきい値など)と見なされるかぎり、weblogic.DeployerユーティリティまたはWebLogic Server管理コンソールを使用して再構成できます。ただし、WebLogic JMX APIやWebLogic Scripting Tool (WLST)を介してスタンドアロン・リソースを使用することはできません。

しかし、WebLogic Serverプラグインに付属の基本的なJSR-88デプロイメント・ツールでは、APIのWebLogic Server拡張を使用せずにスタンドアロンJMSモジュールを使用でき、Java EEアプリケーションやモジュールをWebLogic Serverに構成、デプロイ、および再デプロイできます。WebLogic Serverのデプロイメントについては、Oracle WebLogic ServerへのアプリケーションのデプロイのWebLogic Serverデプロイメントの理解を参照してください。

また、どのWebLogic Serverユーティリティを使用しても、スタンドアロン・リソースを動的に追加または削除することはできません。再デプロイする必要があります。

JMSリソースの一意の実行時JNDI名の生成

接続ファクトリ、宛先などのJMSリソースの構成ではJNDI名を使用します。これらのリソースの実行時実装は、特定の名前を使用してJNDIにバインドされます。しかし、状況によっては、これらのリソースに静的なJNDI名を指定することが不可能(または不都合)な場合があります。

たとえば、JMSリソースがアプリケーション・ライブラリ内のJMSモジュールに定義されている場合です。この場合、アプリケーション・ライブラリは複数のアプリケーションから参照できます。各アプリケーションはデプロイ時にライブラリ(およびそれに含まれているJMSモジュール)のコピーを受け取ります。この状況でJMSリソースに静的なJNDI名を使用すると、ライブラリを参照するすべてのアプリケーションが、同じ静的JNDI名で同じJNDIリソースのセットをバインドすることになります。

その結果、最初にデプロイしたアプリケーションではJMSリソースをJNDIに問題なくバインドできますが、それ以降のアプリケーション・デプロイメントではJNDI名がすでにバインドされていることを示す例外が発生します。

この問題を回避するため、WebLogic Serverには以下のJMSリソースのJNDI名を動的に生成する機能が用意されています。

• 接続ファクトリ

• 宛先(キューおよびトピック)

• 重み設定された分散宛先(非推奨)

• 重み設定された分散宛先メンバー

• 共通分散宛先

この機能では、前述のJMSリソースのJNDI名に${APPNAME}という特別な文字シーケンスを含めることで、一意の名前を生成します。JMSリソース(JMSモジュール記述子またはweblogic-ejb-jar.xml記述子)のJNDI名要素に${APPNAME}を含めると、実行時に実際に使用されるJNDI名では、${APPNAME}文字列がそのJMSリソースをホストするアプリケーションの有効なアプリケーションID (名前と、可能であればバージョン)で置き換えられます。

注意:

${APPNAME}機能を使用して独自の変数を定義したり、実行時にそれらの値をJNDI名に代入したりすることはできません。文字列${APPNAME}はJMS実装によって特別に処理されるもので、JMSリソース以外で${<some name>}形式の文字列を使用しても特に効力はありません。

ローカル・アプリケーションの一意の実行時JNDI名

ローカル・アプリケーション内のJMSモジュールの場合は、実行時の${APPNAME}がそのアプリケーションの名前またはIDで置き換えられます。例:

<jndi-name>${APPNAME}/jms/MyConnectionFactory</jndi-name>

MyAppアプリケーション内にデプロイされているとすると、実行時JNDI名は次のようになります。

MyApp/jms/MyConnectionFactory

アプリケーション・ライブラリの一意の実行時JNDI名

アプリケーション・ライブラリ内のJMSモジュールの場合は、実行時の${APPNAME}が、そのライブラリ(ライブラリの名前ではない)を参照するアプリケーションの名前/IDで置き換えられます。例:

<jndi-name>${APPNAME}/jms/MyConnectionFactory</jndi-name>

MyAppLibというアプリケーション・ライブラリ内にデプロイされており、MyAppというアプリケーションから参照されているとすると、実行時JNDI名は次のようになります。

MyApp/jms/MyConnectionFactory

スタンドアロンJMSモジュールの一意の実行時JNDI名

スタンドアロン・モジュールとしてデプロイされているJMSモジュールの場合は、実行時の${APPNAME}がそのスタンドアロン・モジュールの名前/IDで置き換えられます。例:

<jndi-name>${APPNAME}/jms/MyConnectionFactory</jndi-name>

MyJMSModuleというスタンドアロンJMSモジュール内にデプロイされているとすると、実行時JNDI名は次のようになります。

MyJMSModule/jms/MyConnectionFactory

${APPNAME}文字列の使用場所

${APPNAME}文字列は、JMSモジュールのJNDI名を参照する場所であればどこでも使用できます。以下に、使用できる場所の例を示します。

• JMSモジュール記述子のconnection-factory要素のjndi-nameまたはlocal-jndi-name要素

• JMSモジュール記述子のqueueまたはtopic要素のjndi-nameまたはlocal-jndi-name要素

• JMSモジュール記述子のdistributed-queueまたはdistributed-topic要素のjndi-name要素

• JMSモジュール記述子のuniform-distributed-queueまたはuniform-distributed-topic要素のjndi-name要素

• weblogic-ejb-jar.xml記述子のmessage-destination-descriptor要素のdestination-jndi-name要素

  注意:

  ${APPNAME}文字列は、WebLogic EJBでもサポートされています。

• weblogic-ejb-jar.xml記述子のweblogic-enterprise-bean要素のjndi-name

サンプル・ユースケース

シングル・サーバー環境では、モジュール形式のデプロイメント・モデルをサポートするため、WebLogic Integrationワークリストでアプリケーション・スコープのJMSリソース(キュー、接続ファクトリなど)を使用します。Weblogic Integrationでアプリケーション・スコープのJMSを使用すると、ワークリストで必要なEJBやJMSリソースなどをアプリケーション・ライブラリに定義できます。ユーザーはlibrary-refを追加するだけで、アプリケーションにワークリストを含めることができます。ただし、この場合は、ワークリスト・ユーザーがそれらの宛先をアプリケーション・ライブラリからクラスタにスケーリングできなくなります。

クラスタリングされた環境においては、キューのJNDI名の${APPNAME}文字列を実行時に置換して、キューのグローバルJNDI名を一意にすることができるようになりました。JMS ${APPNAME}パラメータは、この方法により、アプリケーション・ライブラリに結合されているホスト・アプリケーションのアプリケーション名で実行時に置き換えられます。

JMSサービスのための追加の構成オプション

表6-1 JMSサービス移行のための構成プロパティ

プロパティ	デフォルト値	説明
再起動準備完了	True	正常なWebLogic Server内で、システムがJMSサービス障害にどのように応答するかを定義します。サービスが失敗した場合に、このプロパティが有効にされると、まずシステムはそのストアと、同じサーバー上の関連するサービス・アーティファクトの再起動を試行し、その後で別のサーバーに移行します。 注意: この属性は、サーバー全体に障害が発生したときには適用されません。
再起動間隔	30	Restart In Placeが有効の場合、このプロパティは同じサーバー上での再起動と再起動の間の遅延を秒単位で指定します。
再起動回数	6	Restart In Placeが有効の場合、この数は別のサーバーへのアーティファクト・インスタンス移行を試行する前に、システムが行う再起動試行回数を決定します。
初期起動遅延(秒)	60	最初のインスタンスが起動された後、後続の高速インスタンスがサーバー上でどのように起動されるかを制御します。これにより、システムが起動時に過負荷になるのを防止できます。 値0は、システムが待機する必要はないことを示しますが、これは過負荷状況に導く場合があります。システムのデフォルト値は60秒です。
フェイルバック遅延(秒)	-1	アーティファクトのインスタンスを優先サーバーにフェイルバックする前に待機する時間を指定します。 0より大きい値は、JMSアーティファクトを優先サーバーにフェイルバックする前に、遅延させる時間を秒数で指定します。 値に0を指定した場合、インスタンスはフェイルバックしません。 値に-1を指定した場合、遅延は発生せず、インスタンスはただちにフェイルバックします。
部分クラスタ安定遅延	240	部分的に起動されたクラスタが、「常時」または「失敗時」の移行ポリシーで構成された、クラスタをターゲットとして指定されたすべてのJMSアーティファクト・インスタンスを開始する前に、遅延させる時間を秒数で指定します。 この遅延によって、サーバーが順次起動される場合でも、サービスがクラスタ全体で分散されます。 > 0の値は、部分的に開始されたクラスタが動的に構成されたサービスを開始する前に、遅延させる時間を秒数で指定します。 値0は、利用できるサーバー上でのすべてのインスタンスを遅延なしで起動することを指定します。 遅延のデフォルト値は240秒です。

これらのプロパティの詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBCストア: HA構成に関する項を参照してください。