プライマリ・コンテンツに移動
Oracle® Fusion Middleware Oracle WebLogic Server JMSリソースの管理
12c (12.2.1)
E70018-02
  ドキュメント・ライブラリへ移動
ライブラリ
製品リストへ移動
製品
目次へ移動
目次

前
 
次
 

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

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

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

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システム・モジュールの構成」を参照してください。

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

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

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

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

コンポーネントは、@Resourceアノテーションのlookup要素を使用するか、resource-re fデプロイメント記述子要素のlook-up要素を使用して、定義されたリソースを参照できます。

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

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

例: JMS宛先の定義

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

リソース定義で使用できる要素とプロパティの詳細は、付録A「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.TopicinterfaceName@JMSDestinationDefinitionを使用して作成される共通分散トピックの「転送ポリシー」オプションの値は「パーティション化」になります。アプリケーション・デプロイメント時に、値を「レプリケート」に指定できます。ただし、リソース・グループまたはリソース・グループ・テンプレートで転送ポリシーを「レプリケート」として使用することは、適格性チェックで制限されます。詳細は、『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の説明が続きます
「図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アプリケーション・モジュールの参照に関する項で説明されているように、JMSエンティティへの参照を取得するためにjava:comp/env JNDI環境を使用することです。(ただし、このプラクティスは必須ではありません。)

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

スタンドアロン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モジュールは、以下の条件を満たしている必要があります。

スタンドアロン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アプリケーション・モジュールのデプロイ

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

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}パラメータは、この方法により、アプリケーション・ライブラリに結合されているホスト・アプリケーションのアプリケーション名で実行時に置き換えられます。