| Oracle® Fusion Middleware Oracle WebLogic Server JMSの構成と管理 12cリリース1 (12.1.1) B65900-02 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle WebLogic Server JMSの構成と管理 12cリリース1 (12.1.1) B65900-02 |
|
前 |
次 |
この章では、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.2/weblogic-jms.xsdからオンラインで入手できます。
スキーマ内のJMSリソース定義については、Oracle WebLogic Server MBeanリファレンスの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管理コンソールなど、JSR 88ベースのツールを使用します。
|
注意: 管理コンソールを使用してパッケージ化されたJMSモジュールを作成したら、作成されたXMLファイルを別のディレクトリにコピーし、ファイル接尾辞として |
EARファイル内では、JMSモジュールが以下の条件を満たしている必要があります。
http://xmlns.oracle.com/weblogic/weblogic-jms/1.2/weblogic-jms.xsdスキーマに準拠している
ファイル接尾辞として-jms.xmlを使用します(例: MyJMSDescriptor-jms.xml)
WebLogicドメイン内で一意の名前が付けられており、Java EEアプリケーションのルートからの相対パスが指定されている
パッケージ化JMSモジュールを構成するには、次の手順に従います。
必要に応じて、JMSモジュールをターゲット指定するJMSサーバーを作成します。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMSサーバーの構成に関する項を参照してください。
JMSシステム・モジュールを作成し、必要なリソース(キュー、トピックなど)を構成します。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMSシステム・モジュールの構成およびJMSリソースの追加に関する項を参照してください。
システム・モジュールは、ドメイン・ディレクトリのconfig\jmsサブディレクトリに、接尾辞「-jms.xml」が付加された形で保存されます。
システム・モジュールを新しい場所にコピーしてから以下を行います。
モジュールの名前を、ドメイン・ネームスペース内で一意の名前に変更します。
JNDI-Name属性を削除して、そのアプリケーションでのみ使用できるアプリケーション・スコープのモジュールにします。
『Oracle WebLogic Server JMSのプログラミング』のデプロイメント記述子ファイルのパッケージ化されたJMSアプリケーション・モジュールの参照に関する項の説明に従い、適用可能なすべてのJava EEアプリケーション・コンポーネントの記述子ファイルに、モジュール内のJMSリソースの参照を追加します。
EAR内のすべてのアプリケーション・モジュールをパッケージ化します。「エンタープライズ・アプリケーションをJMSアプリケーション・モジュールと共にパッケージ化する」を参照してください。
EARをデプロイします。「パッケージ化JMSアプリケーション・モジュールをデプロイする」を参照してください。
次のコード・スニペットは、パッケージ化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によって参照されるモジュールに宛先名がマップされます。res-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 WebLogic Serverアプリケーションの開発』のwlpackageを使用したアプリケーションのパッケージ化に関する項を参照してください。
パッケージ化JMSモジュールのデプロイメントは、アプリケーションの他のコンポーネントと同じモデルに従って行われます。個別のモジュールは、単一のサーバー、クラスタ、またはクラスタの個別のメンバーにデプロイできます。
他のアプリケーション・コンポーネントの推奨ベスト・プラクティスは、『Oracle WebLogic Server JMSのプログラミング』のデプロイメント記述子ファイルにおけるパッケージ化JMSアプリケーション・モジュールの参照に関する項で説明されているように、JMSエンティティへの参照を取得するためにjava:comp/env JNDI環境を使用することです。(ただし、このプラクティスは必須ではありません。)
パッケージ化JMSモジュールは、定義によってエンタープライズ・アプリケーションに含まれているため、エンタープライズ・アプリケーションをデプロイすると一緒にデプロイされます。パッケージ化JMSモジュールを含むアプリケーションのデプロイメントの詳細は、『Oracle WebLogic Serverアプリケーションの開発』の「wldeployを使用したアプリケーションのデプロイメント」を参照してください。
この節では、以下の内容について説明します。
JMSアプリケーション・モジュールは、スタンドアロン・モジュールとしてデプロイできます。この場合、アプリケーション・モジュールはデプロイメント・プロセス中にターゲット指定されたサーバーまたはクラスタで使用できます。この方法でデプロイされるJMSモジュールは、weblogic.Deployerユーティリティまたは管理コンソールで再構成できますが、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モジュールは、エンタープライズ・レベルのIDEまたはXML記述子ファイルの編集をサポートする他の開発ツールを使用して作成できます。スタンドアロンのモジュールをデプロイおよび管理するには、weblogic.Deployerユーティリティ、WebLogic管理コンソールなどのWebLogic Serverツールを使用します。
|
注意: 管理コンソールを使用してJMSアプリケーション・モジュールを作成したら、アプリケーションで使用するテンプレートとしてモジュールをコピーし、ファイル接尾辞として |
スタンドアロンJMSモジュールは、以下の条件を満たしている必要があります。
http://xmlns.oracle.com/weblogic/weblogic-jms/1.2/weblogic-jms.xsdスキーマに準拠している
ファイル接尾辞として-jms.xmlを使用します(例: MyJMSDescriptor-jms.xml)
WebLogicドメイン内で一意の名前を使用します(JMSシステム・モジュールと競合することはできません)
スタンドアロンJMSモジュールを構成するには、次の手順に従います。
必要に応じて、JMSモジュールをターゲット指定するJMSサーバーを作成します。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMSサーバーの構成に関する項を参照してください。
JMSシステム・モジュールを作成し、必要なリソース(キュー、トピックなど)を構成します。Oracle WebLogic Server管理コンソール・オンライン・ヘルプの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 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ユーティリティまたは管理コンソールを使用して再構成できます。ただし、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名を使用します。これらのリソースの実行時実装は、特定の名前を使用して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名に代入したりすることはできません。文字列 |
ローカル・アプリケーション内の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}パラメータは、この方法により、アプリケーション・ライブラリに結合されているホスト・アプリケーションのアプリケーション名で実行時に置き換えられます。
