| Oracle® Fusion Middleware Oracle WebLogic Server JMS のコンフィグレーションと管理 11g リリース 1 (10.3.1) B55547-01 |
|
 戻る |
 次へ |
| Oracle® Fusion Middleware Oracle WebLogic Server JMS のコンフィグレーションと管理 11g リリース 1 (10.3.1) B55547-01 |
|
戻る |
次へ |
以下の節では、JMS アプリケーション モジュールをデプロイするためにコンフィグレーションする方法について説明します。また、Java EE エンタープライズ アプリケーションでパッケージ化された JMS アプリケーション モジュールや、グローバルに使用できるスタンドアロン アプリケーション モジュールについても説明します。
JMS システム モジュールにコンフィグレーションできるすべての JMS リソースは、標準 Java EE モジュールと同様にデプロイ可能なアプリケーション モジュールとしてコンフィグレーションおよび管理できます。デプロイされた JMS アプリケーション モジュールの所有者は、モジュールをデプロイした管理者ではなく、モジュールを作成およびパッケージ化した開発者となります。したがって、デプロイしたリソースに対しては、管理者の制御が及ぶ範囲がより制限されます。
たとえば、管理者は、デプロイメント時にデプロイメント プラン (JSR-88) を使用して、モジュール内に指定されたリソースの特定のプロパティを修正 (オーバーライド) することはできますが、リソースを動的に追加したり削除したりすることはできません。他の Java EE モジュールのように、アプリケーション モジュールのコンフィグレーションの変更はモジュールのデプロイメント プランに格納され、元のモジュール自体は変更されません。
アプリケーション開発者は、こうしたツールを使用してシステム リソースを作成およびデプロイ (対象指定) できます。
「JMS システム モジュールのコンフィグレーション」の説明に従って JMS システム モジュールを作成し、生成される XML ファイルを別のディレクトリにコピーして、ファイル サフィックスとして -jms.xml を付加した名前に変更する。
エンタープライズ レベルの IDE または XML ファイルの編集に対応した開発ツールでアプリケーション モジュールを作成し、その JMS モジュールをアプリケーションの一部としてパッケージ化して、デプロイのために WebLogic 管理者に渡す。
WebLogic Server 9.x 以上では、JMS リソース用にモジュール形式のデプロイメント モデルをサポートするために、WebLogic JMS リソースの定義に使用する weblogic-jms.xsd というスキーマが用意されています。JMS モジュール (記述子) を作成する際は、モジュールをこのスキーマに準拠させる必要があります。IDE や他のツールでは、このスキーマに基づいて JMS モジュールを検証できます。
weblogic-jms.xsd スキーマは、http://xmlns.oracle.com/weblogic/weblogic-jms/1.0/weblogic-jms.xsd からオンラインで入手できます。
スキーマ内の JMS リソース定義については、『Oracle Fusion Middleware Oracle WebLogic Server MBean Reference』の「System Module MBeans」フォルダ内の対応するシステム モジュール Bean で説明しています。JMS モジュールのルート Bean は JMSBean で、JMS モジュール全体を表します。
JMS アプリケーション モジュールは、「パッケージ化されたモジュール」としてエンタープライズ アプリケーション アーカイブ (EAR) の一部にパッケージ化できます。パッケージ化されたモジュールは、EAR または展開された EAR ディレクトリにバンドルされ、weblogic-application.xml 記述子内で参照されます。
パッケージ化された JMS モジュールは、エンタープライズ アプリケーションと一緒にデプロイされます。このモジュールに定義されたリソースは、同梱されたアプリケーションでのみ利用可能 (すなわちアプリケーション スコープのリソース) にすることもできます。このようなモジュールは、JMS リソースを使用する EJB (特に MDB) や Web アプリケーションと一緒にパッケージ化する場合には特に便利です。パッケージ化したモジュールを使用することにより、アプリケーションで必要なリソースを常に使用でき、アプリケーションを新しい環境に移動する処理が簡素化されます。
パッケージ化 JMS モジュールは、エンタープライズ レベルの IDE または XML 記述子ファイルの編集をサポートする他の開発ツールを使用して作成します。スタンドアロンのモジュールをデプロイおよび管理するには、weblogic.Deployer ユーティリティ、WebLogic Administration Console など、JSR 88 ベースのツールを使用します。
|
注意 : Administration Console を使用してパッケージ化された JMS モジュールを作成したら、作成された XML ファイルを別のディレクトリにコピーし、ファイル サフィックスとして-jms.xml を付加してファイル名を変更します。 |
EAR ファイル内では、JMS モジュールが以下の条件を満たしている必要があります。
http://xmlns.oracle.com/weblogic/weblogic-jms/1.0/weblogic-jms.xsd スキーマに準拠している
ファイル サフィックスとして -jms.xml が付加されている (例 : MyJMSDescriptor-jms.xml)
WebLogic ドメイン内でユニークな名前が付けられており、Java EE アプリケーションのルートからの相対パスが指定されている
パッケージ化 JMS モジュールをコンフィグレーションするには、次の手順に従います。
必要に応じて、JMS モジュールを対象付ける JMS サーバを作成します。Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「JMS サーバのコンフィグレーション」を参照してください。
JMS システム モジュールを作成し、必要なリソース (キュー、トピックなど) をコンフィグレーションします。Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「JMS システム モジュールのコンフィグレーションおよび JMS リソースの追加」を参照してください。
システム モジュールは、ドメイン ディレクトリの config\jms サブディレクトリに、サフィックス「-jms.xml」が付加された形で保存されます。
システム モジュールを新しい場所にコピーしてから以下を行います。
モジュールの名前を、ドメイン ネームスペース内でユニークな名前に変更します。
JNDI-Name 属性を削除して、そのアプリケーションでのみ使用できるアプリケーション スコープのモジュールにします。
モジュール内の JMS リソースへの参照を、該当するすべての Java EE アプリケーション コンポーネントの記述子ファイルに追加します。「デプロイメント記述子ファイルでパッケージ化 JMS アプリケーション モジュールを参照する」を参照してください。
EAR 内のすべてのアプリケーション モジュールをパッケージ化します。「エンタープライズ アプリケーションを JMS アプリケーション モジュールと共にパッケージ化する」を参照してください。
EAR をデプロイします。「パッケージ化 JMS アプリケーション モジュールをデプロイする」を参照してください。
JMS モジュールをエンタープライズ アプリケーションにパッケージ化する際は、該当するすべての Java EE アプリケーション コンポーネントの記述子ファイルで、モジュール内の JMS リソースを参照する必要があります。以下に、該当する記述子ファイルの例を挙げます。
WebLogic エンタープライズ記述子ファイル (weblogic-application.xml)
WebLogic デプロイメント記述子ファイル (weblogic-ejb-jar.xml、weblogic.xml など)
EJB (ejb-jar.xml) ファイル、WebApp (web.xml) ファイルなど、すべての Java EE 記述子ファイル
エンタープライズ アプリケーションに JMS モジュールを含める際は、アプリケーションと一緒にパッケージ化された weblogic-application.xml 記述子ファイルで、JMS タイプのモジュール要素として各 JMS モジュールを列挙し、Java EE アプリケーションのルートからの相対パスを指定する必要があります。次に、Workflows という JMS モジュールへの参照の例を示します。
<module> <name>Workflows</name> <type>JMS</type> <path>jms/Workflows-jms.xml</path> </module>
EJB (weblogic-ejb-jar.xml)、WebApp (weblogic.xml) など、weblogic- で始まるすべての記述子ファイルでは、JMS モジュールの名前の後ろにシャープ記号 (#) の区切り文字を付加し、その後ろにモジュール内のリソースの名前を指定します。たとえば、OrderQueue というキューを含む Workflows という JMS モジュールであれば、Workflows#OrderQueue という名前になります。
<resource-env-description> <resource-env-ref-name>jms/OrderQueue</resource-env-ref-name> <resource-link>Workflows#OrderQueue</resource-link> </resource-env-description>
<resource-link> 要素は WebLogic Server 固有の要素で、JMS モジュール内に定義されたリソースを他のさまざまな Java EE アプリケーション コンポーネントから参照 (リンク) するために使用します。
JMS モジュール内に指定された JMS 接続ファクトリ リソースの name 要素は、これを参照する EJB または WebApp アプリケーション記述子ファイルに定義された res-ref-name 要素と一致させる必要があります。res-ref-name 要素により、java:comp/env で使用するリソース名が、EJB から参照されるモジュールにマップされます。
JMS モジュール内に指定されたキュー送り先リソースおよびトピック送り先リソースの name 要素の場合は、これを参照するモジュール記述子ファイルに定義された res-env-ref 要素と一致させる必要があります。
この名前は、EJB または Web アプリケーション モジュールで参照されるリソースと、JMS モジュールで定義されたリソースをリンクさせるためのものです。次に例を示します。
<resource-ref> <res-ref-name>jms/OrderQueueFactory</res-ref-name> <res-type>javax.jms.ConnectionFactory</res-type> </resource-ref> <resource-env-ref> <res-env-ref-name>jms/OrderQueue</res-env-ref-name> <res-env-ref-type>javax.jms.Queue</res-env-ref-type> </resource-env-ref>
次の抜粋コードは、パッケージ化 JMS モジュール appscopedejbs-jms.xml の例です。このモジュールは、図 5-1 のように記述子ファイルで参照されています。
<weblogic-jms xmlns="http://xmlns.oracle.com/weblogic/weblogic-jms"> <connection-factory name="ACF"> </connection-factory> <queue name="AppscopeQueue"> </queue> </weblogic-jms>
図 5-1 に、パッケージ化 JMS モジュールの JMS 接続ファクトリ リソースとキュー リソースが、EJB EAR ファイルで参照されている様子を示します。
エンタープライズ アプリケーションに JMS モジュールを含める際は、アプリケーションと一緒にパッケージ化された weblogic-application.xml 記述子ファイルで、JMS タイプのモジュール要素として各 JMS モジュールを列挙し、アプリケーションのルートからの相対パスを指定する必要があります。次に例を示します。
<module> <name>AppScopedEJBs</name> <type>JMS</type> <path>jms/appscopedejbs-jms.xml</path> </module>
アプリケーション内の 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 によって参照されるモジュールに送り先名がマップされます。resource-env-ref-type 要素には、キューの名前 (この例では javax.jms.Queue) を指定します。
参照される 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>
JDBC モジュールを含むアプリケーションは、他のエンタープライズ アプリケーションと同じようにパッケージ化します。『Oracle Fusion Middleware Oracle WebLogic Server アプリケーションの開発』の「wlpackage を使用したアプリケーションのパッケージ化」を参照してください。
パッケージ化 JMS モジュールのデプロイメントは、アプリケーションの他のコンポーネントと同じモデルに従って行われます。個別のモジュールは、単一のサーバ、クラスタ、またはクラスタの個別のメンバーにデプロイできます。
他のアプリケーション コンポーネントの推奨ベスト プラクティスは、java:comp/env JNDI 環境を使用して JMS エンティティへの参照を取得する方法です。詳細については、「Java EE アプリケーションで JMS リソースを参照する」を参照してください (ただし、必須ではありません)。
パッケージ化 JMS モジュールは、定義によってエンタープライズ アプリケーションに含まれているため、エンタープライズ アプリケーションをデプロイすると一緒にデプロイされます。パッケージ化 JMS モジュールを含むアプリケーションのデプロイメントの詳細については、『Oracle Fusion Middleware Oracle WebLogic Server アプリケーションの開発』の「wldeploy を使用したアプリケーションのデプロイメント」を参照してください。
この節では、以下の内容について説明します。
JMS アプリケーション モジュールは、スタンドアロン モジュールとしてデプロイできます。この場合、アプリケーション モジュールはデプロイメント プロセス中に対象指定されたサーバまたはクラスタで使用できます。この方法でデプロイされる JMS モジュールは、weblogic.Deployer ユーティリティまたは Administration Console で再コンフィグレーションできますが、JMX または WLST では使用できません。
しかし、WebLogic Server プラグインに付属の基本的な JSR-88 デプロイメント ツールでは、API の WebLogic Server 拡張を使用せずにスタンドアロン JMS モジュールを使用でき、Java EE アプリケーションやモジュールを WebLogic Server にコンフィグレーション、デプロイ、および再デプロイできます。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server アプリケーションのデプロイメント』の「WebLogic Server デプロイメントについて」を参照してください。
この方法でデプロイした JMS モジュールを「スタンドアロン モジュール」といいます。スタンドアロン JMS モジュール内のリソースは、モジュールがどのように対象指定されているかに応じて、クラスタ内でグローバルに使用できるか、サーバ インスタンスでローカルに使用できるかが決まります。スタンドアロン JMS モジュールを使用すると、JMS リソースの共有と移植が容易になります。作成した JMS モジュールは他の開発者に配布できます。スタンドアロン JMS モジュールも、ドメイン間で JMS 情報を移動するために使用できます。たとえば、JMS を広範囲にわたって手動で再コンフィグレーションすることなく、開発ドメインとプロダクション ドメインの間で JMS 情報を移動できます。
スタンドアロン JMS モジュールは、エンタープライズ レベルの IDE または XML 記述子ファイルの編集をサポートする他の開発ツールを使用して作成できます。スタンドアロンのモジュールをデプロイおよび管理するには、weblogic.Deployer ユーティリティ、WebLogic Administration Console などの WebLogic Server ツールを使用します。
|
注意 : Administration Console を使用して JMS アプリケーション モジュールを作成したら、アプリケーションで使用するテンプレートとしてモジュールをコピーし、ファイル サフィックスとして-jms.xml を付加します。また、ネームスペース内での名前の衝突を避けるため、モジュールをアプリケーションと一緒にデプロイする前に、モジュールの Name 要素と JNDI-Name 要素を変更する必要があります。 |
スタンドアロン JMS モジュールは、以下の条件を満たしている必要があります。
http://xmlns.oracle.com/weblogic/weblogic-jms/1.0/weblogic-jms.xsd スキーマに準拠している
ファイル サフィックスとして -jms.xml が付加されている (例 : MyJMSDescriptor-jms.xml)
WebLogic ドメイン内でユニークな名前を使用している (JMS システム モジュールと衝突していない)
スタンドアロン JMS モジュールをコンフィグレーションするには、次の手順に従います。
必要に応じて、JMS モジュールを対象付ける JMS サーバを作成します。Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「JMS サーバのコンフィグレーション」を参照してください。
JMS システム モジュールを作成し、必要なリソース (キュー、トピックなど) をコンフィグレーションします。Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「JMS システム モジュールのコンフィグレーションおよび JMS リソースの追加」を参照してください。
システム モジュールは、ドメイン ディレクトリの config\jms サブディレクトリに、サフィックス -jms.xml が付加された形で保存されます。
システム モジュールを新しい場所にコピーしてから以下を行います。
モジュールの名前を、ドメイン ネームスペース内でユニークな名前に変更します。
モジュールをグローバルに使用できるようにするには、モジュール内のリソースの JNDI-Name 属性をユニークな名前に変更します。
必要に応じて、他の調整可能な値を修正します。送り先のしきい値、接続ファクトリのフロー コントロールなどのパラメータを調整できます。
モジュールをデプロイします。「スタンドアロン 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 ユーティリティを使用してデプロイするコマンドラインは次のようになります。
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 Fusion Middleware 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 リソースは、バインド可能 (JNDI 名など) または調整可能 (送り先のしきい値など) とみなされるリソースであれば、weblogic.Deployer ユーティリティまたは Administration Console を使用して再コンフィグレーションできます。ただし、WebLogic JMX API や WebLogic Scripting Tool (WLST) を介してスタンドアロン リソースを使用することはできません。
しかし、WebLogic Server プラグインに付属の基本的な JSR-88 デプロイメント ツールでは、API の WebLogic Server 拡張を使用せずにスタンドアロン JMS モジュールを使用でき、Java EE アプリケーションやモジュールを WebLogic Server にコンフィグレーション、デプロイ、および再デプロイできます。WebLogic Server のデプロイメントの詳細については、『Oracle Fusion Middleware Oracle WebLogic Server アプリケーションのデプロイメント』の「WebLogic Server デプロイメントについて」を参照してください。
また、どの WebLogic Server ユーティリティを使用しても、スタンドアロン リソースを動的に追加または削除することはできません。再デプロイする必要があります。
接続ファクトリ、送り先などの 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>} 形式の文字列を使用しても特に効力はありません。 |
ローカル アプリケーション内の JMS モジュールの場合は、実行時の ${APPNAME} がそのアプリケーションの名前/ID で置き換えられます。次に例を示します。
<jndi-name>${APPNAME}/jms/MyConnectionFactory</jndi-name>
MyApp アプリケーション内にデプロイされているとすると、実行時 JNDI 名は次のようになります。
MyApp/jms/MyConnectionFactory
アプリケーション ライブラリ内の JMS モジュールの場合は、実行時の ${APPNAME} が、そのライブラリ (ライブラリの名前ではない) を参照するアプリケーションの名前/ID で置き換えられます。次に例を示します。
<jndi-name>${APPNAME}/jms/MyConnectionFactory</jndi-name>
MyAppLib というアプリケーション ライブラリ内にデプロイされており、MyApp というアプリケーションから参照されているとすると、実行時 JNDI 名は次のようになります。
MyApp/jms/MyConnectionFactory
スタンドアロン モジュールとしてデプロイされている JMS モジュールの場合は、実行時の ${APPNAME} がそのスタンドアロン モジュールの名前/ID で置き換えられます。次に例を示します。
<jndi-name>${APPNAME}/jms/MyConnectionFactory</jndi-name>
MyJMSModule というスタンドアロン JMS モジュール内にデプロイされているとすると、実行時 JNDI 名は次のようになります。
MyJMSModule/jms/MyConnectionFactory
${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} パラメータは、この方法により、アプリケーション ライブラリに結合されているホスト アプリケーションのアプリケーション名で実行時に置き換えられます。
