2 JMSリソースの構成の理解

WebLogic JMSの基本的な概念と機能、およびそれらと他のアプリケーション・コンポーネントおよびOracle WebLogic Serverとの連携の仕組みについて学習します。

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

• JMSとOracle WebLogic Serverの概要
  JMSのWebLogic Server実装は、WebLogic Serverプラットフォームに緊密に統合されたエンタープライズ・クラスのメッセージング・システムです。
• JMS構成リソースとは
  宛先および接続ファクトリなどのJMS構成リソースは、モジュール記述子ファイルとしてWebLogicドメインの外に保持されます。これらのファイルは、weblogic-jms.xsdスキーマに準拠しているXMLドキュメントで定義されます。
• JMSサーバーの概要
  JMSサーバーは、特定のJMSサーバーのターゲットとして指定されたJMSモジュール内の宛先リソースの管理コンテナとして機能する、環境関連の構成エンティティです。
• JMSモジュールの概要
  JMSモジュールは、ドメイン環境から独立したアプリケーション関連の定義です。システム・モジュールまたはアプリケーション・モジュールのいずれかとして、JMSリソースを作成して管理できます。
• WebLogic JMSの他の環境関連システム・リソース
  JMSサーバーおよびシステム・モジュールに加えて、管理者は次のアーティファクトのいずれかを構成する必要がある場合があります。

JMSとOracle WebLogic Serverの概要

JMSのWebLogic Server実装は、WebLogic Serverプラットフォームに緊密に統合されたエンタープライズ・クラスのメッセージング・システムです。

JMS 2.0仕様(http://www.oracle.com/technetwork/java/jms/index.htmlで入手可能)を完全にサポートしています。また、標準JMS APIより高度なWebLogic JMS拡張も数多く用意されています。

• Jakarta Messagingとは
  
• WebLogic JMSのアーキテクチャと環境
  
• ドメインの構成
  

Jakarta Messagingとは

エンタープライズ・メッセージング・システムを使用すると、アプリケーション同士がメッセージを交換することによって非同期的に通信できます。メッセージとは、異なるアプリケーション間の通信を調整するために必要な情報が含まれている、リクエスト、レポート、およびイベントです。メッセージで提供される抽象化の階層により、宛先システムについての詳細情報をアプリケーション・コードから切り離すことができます。

JMSは、業界メッセージング・プロバイダによって実装されるエンタープライズ・メッセージング・システムにアクセスするための標準APIです。具体的なJMSの特長は以下のとおりです。

• メッセージング・システムを共有するJakartaアプリケーション同士でメッセージを交換できます

• メッセージを作成、送信、および受信するための標準インタフェースによりアプリケーションの開発が容易になります

WebLogic JMSは、プロデューサ・アプリケーションからメッセージを受信し、そのメッセージをコンシューマ・アプリケーションに配信します。WebLogic Serverを使用したJMS APIプログラミングの詳細は、Oracle WebLogic Server JMSアプリケーションの開発で、簡略化されたAPIプログラミング・モデルを参照してください。

WebLogic JMSのアーキテクチャと環境

図2-1にWebLogic JMSのアーキテクチャを示します。

図2-1 WebLogic JMSのアーキテクチャ

「図2-1 WebLogic JMSのアーキテクチャ」の説明

WebLogic JMSアーキテクチャの主要コンポーネントは以下のとおりです。

• JMSサーバーは環境関連の構成エンティティであり、特定のJMSサーバーのターゲットとして指定されたJMSモジュール内のJMSキューおよびトピック・リソースの管理コンテナとして機能します。JMSサーバーの最も重要な役割は、JMSサーバーの宛先が受信するすべての永続メッセージに使用される永続ストアに関する情報を管理し、また、JMSサーバーの宛先で作成される恒久サブスクライバの状態を管理することです。ドメインごとに1つまたは複数のJMSサーバーを構成でき、1つのJMSサーバーでは1つまたは複数のJMSモジュールを管理できます。「JMSサーバーの概要」を参照してください

• スタンドアロンのキューおよびトピック宛先、分散宛先、接続ファクトリなどの構成リソースを含み、weblogic-jms.xsdスキーマに準拠するXMLドキュメントによって定義されるJMSモジュール。「JMS構成リソースとは」を参照してください

• クライアントJMSアプリケーションは、宛先へのメッセージを生成するか、または宛先からのメッセージを消費します。

• JNDI (Java Naming and Directory Interface)は、サーバー・ルックアップ機能を提供します。

• WebLogic永続ストレージ(サーバー・インスタンスのデフォルト・ストア、ユーザー定義のファイル・ストア、またはJDBCでアクセス可能なユーザー定義ストア)。永続メッセージ・データを保持します。

ドメインの構成

一般に、WebLogic Serverドメイン構成ファイル(config.xml)には、ドメインに必要な構成情報が記述されています。この構成情報は、環境関連の情報とアプリケーション関連の情報にさらに分類できます。環境関連の情報には、JMSサーバーのIDと定義、JDBCデータ・ソース、WebLogic永続ストア、サーバー・ネットワーク・アドレスなどがあります。通常、これらのシステム・リソースは、ドメインごとに一意です。

これらのシステム・リソースの構成と管理を行うのは、WebLogic管理者です。WebLogic管理者は、組織のシステム管理者またはMIS部門からこの情報を受け取ります。これらのタスクを実行するために、管理者はWebLogicリモート・コンソール、WebLogic Scripting Tool (WLST)などの様々なコマンドライン・ツール、またはプログラムによる管理用のJMX APIを使用できます。

ドメイン環境に依存しないアプリケーション関連の定義の例としては、様々なJakarta EEアプリケーション・コンポーネント構成(EAR、WAR、JAR、RARの各ファイル、JMSおよびJDBCモジュールなど)があります。アプリケーション・コンポーネントは、アプリケーション開発チームによって開発およびパッケージ化され、さらにプログラム(コンパイル済みJavaコード)とその構成情報(記述子とも呼ばれ、そのほとんどはXMLファイルとして格納される)を持つ場合があります。ただし、JMSおよびJDBCモジュールの場合、コンパイル済みJavaコードは含まれません。あらかじめパッケージ化されたこれらのアプリケーションは、WebLogic Server管理者によってWebLogicドメインにデプロイされます。

アプリケーションをデプロイするプロセスによって、アプリケーション・コンポーネントと環境固有のリソース定義がリンクされます。たとえば、特定のアプリケーション・コンポーネントをホストするサーバー・インスタンス(ターゲット指定)や、JMSメッセージを保持するWebLogic永続ストアなどです。

最初のデプロイメントの完了後は、デプロイされたアプリケーションに対する管理者の権限は限定されます。たとえば、管理者はアプリケーションの適切なライフ・サイクルの保持(デプロイ、アンデプロイ、再デプロイ、削除など)とパラメータの調整(クライアントのニーズにあわせてアプリケーションのインスタンス数を増減するなど)しかできません。ライフ・サイクルとチューニング以外の変更は、アプリケーション開発チームによって行われます。

JMS構成リソースとは

宛先および接続ファクトリなどのJMS構成リソースは、モジュール記述子ファイルとしてWebLogicドメインの外に保持されます。これらのファイルは、weblogic-jms.xsdスキーマに準拠しているXMLドキュメントで定義されます。

JMSモジュールにはJMSサーバーの定義は含まれません。「JMSサーバーの概要」で説明するように、JMSサーバーの定義はWebLogicドメインの構成ファイルに格納されます

JMSリソースは、旧リリースの場合と同様の方法で管理するシステム・モジュールか、またはアプリケーション・モジュールとして作成し、管理します。JMSアプリケーション・モジュールは、Jakarta EEモジュールのWebLogic固有の拡張機能であり、Jakarta EEアプリケーションとともに(パッケージ化されたリソースとして)、またはグローバルに使用可能なスタンドアロン・モジュールとしてデプロイできます。「JMSモジュールの概要」を参照してください

JMSサーバーの概要

JMSサーバーは、特定のJMSサーバーのターゲットとして指定されたJMSモジュール内の宛先リソースの管理コンテナとして機能する、環境関連の構成エンティティです。

JMSサーバーの最も重要な役割は、JMSサーバーの宛先が受信するすべての永続メッセージに使用される永続ストアに関する情報を管理し、また、JMSサーバーの宛先で作成される恒久サブスクライバの状態を管理することです。また、ターゲット宛先のコンテナとして、JMSサーバーに対して加えられた構成の変更または実行時の変更をすべての宛先に対して有効にできます。

JMSサーバーはドメインのconfig.xmlファイルに保持され、クラスタ内の様々なWebLogic Serverインスタンスで複数のJMSサーバーを構成できます(独自の名前が付けられている場合に限ります)。クライアント・アプリケーションでは、JNDIツリーまたはjava:/comp/envネーミング・コンテキストを使用して接続ファクトリをルックアップし、接続を作成してJMSサーバーとの通信を確立します。各JMSサーバーでは、すべてのターゲット・モジュールの宛先に対するリクエストが処理されます。JMSサーバーによって処理されない宛先に対するリクエストは、適切なサーバー・インスタンスに転送されます。

JMSモジュールの概要

JMSモジュールは、ドメイン環境から独立したアプリケーション関連の定義です。システム・モジュールまたはアプリケーション・モジュールのいずれかとして、JMSリソースを作成して管理できます。

JMSシステム・モジュールは、通常、WebLogicリモート・コンソールまたはWebLogic Scripting Tool (WLST)を使用して構成され、ドメインのconfig.xmlファイル内にそのモジュールへの参照が追加されます。JMSアプリケーション・モジュールは、Jakarta EEモジュールのWebLogic固有の拡張機能であり、Jakarta EEアプリケーションとともに(パッケージ化されたリソースとして)、またはグローバルに使用可能なスタンドアロン・モジュールとしてデプロイできます。

システム・モジュールとアプリケーション・モジュールの主な相違点は所有権です。システム・モジュールはWebLogic管理者によって所有および変更され、すべてのアプリケーションで利用可能です。アプリケーション・モジュールは、このJMSリソース・モジュールをアプリケーションのEARファイルにパッケージ化するWebLogic開発者によって所有および変更されます。

JMSリソースのモジュール形式のデプロイメントでは、エンタープライズ・アプリケーション・ファイル(EARファイルなど)やスタンドアロンJMSモジュールを開いたり、JMSを手動で広範囲に再構成したりすることなく、アプリケーションと必要なJMS構成を、ある環境から別の環境に(たとえば、テスト環境から本番環境に)移行できます。

以下の節では、様々なタイプのJMSモジュールと、それらのモジュールに含められるリソースについて説明します。

• JMSシステム・モジュール
  
• JMSアプリケーション・モジュール(非推奨)
  
• JMSシステム・モジュールとアプリケーション・モジュールを比較する
  
• モジュールに構成できるJMSリソース
  
• JMSスキーマ
  
• JMS相互運用モジュール(非推奨)
  

JMSシステム・モジュール

WebLogic管理者は、通常、WebLogicリモート・コンソールまたはWebLogic Scripting Tool (WLST)を使用して、(ターゲット)JMSモジュールの作成とデプロイ、およびモジュールの構成リソース(キュー、トピック、接続ファクトリなど)の構成を行います。

このように構成するJMSモジュールは、システム・モジュールと見なされます。JMSシステム・モジュールは管理者が所有し、管理者はいつでもリソースを削除、変更、または追加できます。システム・モジュールは、ドメインに構成されたサーバーおよびクラスタのターゲット指定に対して全面的に利用できます。つまり、同じターゲットにデプロイされているすべてのアプリケーションおよびクライアント・アプリケーションで利用できます。

JMSシステム・モジュールを作成する場合、ドメイン・ディレクトリのconfig\jmsサブディレクトリにJMSモジュール・ファイルが作成され、ドメインのconfig.xmlファイルにJMSSystemResource要素としてそのモジュールへの参照が追加されます。この参照には、JMSシステム・モジュール・ファイルへのパス、およびこのモジュールがデプロイされるサーバーとクラスタのリストが含まれます。

JMSモジュールは、weblogic-jms.xsdスキーマに準拠します(「JMSスキーマ」を参照)。システム・モジュールは、WebLogic Management Extension (JMX)ユーティリティからもJMSSystemResourceMBeanとしてアクセス可能です。JMSシステム・モジュールのネーミング・ルールは、MyJMSModule-jms.xmlです。

図2-2に、ドメインのconfig.xmlファイルに記述されるJMSシステム・モジュールと、対応するconfig\jmsディレクトリ内のモジュールの例を示します。

図2-2 config.xmlからJMSシステム・モジュールへの参照

「図2-2 config.xmlからJMSシステム・モジュールへの参照」の説明

JMSシステム・モジュールの構成の詳細は、「基本JMSシステム・リソースの構成」を参照してください

JMSアプリケーション・モジュール(非推奨)

JMS構成リソースは、標準のJakarta EE記述子ベースのモジュールと同様に、デプロイ可能なアプリケーション・モジュールとしても管理できます。JMSアプリケーション・モジュールは、Jakarta EEアプリケーションとともにパッケージ・モジュールとしてデプロイできます。この場合、モジュール内のリソースは、包含アプリケーション(アプリケーション・スコープ)でのみ使用可能になります。また、そのモジュールで定義されているリソースへのグローバル・アクセスを提供するスタンドアロン・モジュールとしてもデプロイできます。

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

「ドメインの構成」で説明されているように、JMSアプリケーション・モジュールにはコンパイル済のJavaプログラムがパッケージの一部として含まれていないので、管理者またはアプリケーション開発者は必要に応じてJMSリソースを作成および管理できます。

JMSアプリケーション・モジュールの構成の詳細は、JMSアプリケーション・モジュールのデプロイメントの構成を参照してください。

ノート:

WebLogic JMSアプリケーション・モジュールのデプロイメントは、パッケージ化されたモジュールとスタンドアロン・モジュールも含めて非推奨になりました。JMSアプリケーション・モジュールのサポートは、今後のリリースではなくなります。必須のJMS構成は、システム・モジュールを使用して作成することをお薦めします。

JMSシステム・モジュールとアプリケーション・モジュールを比較する

WebLogic JMS構成および管理を理解する上でキーとなるのは、JMSリソースの作成者およびJMSリソースの作成方法が、リソースのデプロイと変更の方法を決定するという点にあります。JMSモジュールは、WebLogicの管理者とプログラマが構成できます。

システム・モジュールとは対照的に、デプロイされたアプリケーション・モジュールの所有者は、モジュールをデプロイした管理者ではなく、モジュールを作成およびパッケージ化した開発者となります。したがって、デプロイしたリソースに対しては、管理者の制御が及ぶ範囲がより制限されます。アプリケーション・モジュールをデプロイする場合、管理者はモジュールで指定されたリソース・プロパティの変更はできますが、リソースの追加や削除はできません。他のJakarta EEモジュールのように、アプリケーション・モジュールのデプロイメント構成の変更はモジュールのデプロイメント・プランに格納され、元のモジュール自体は変更されません。

表2-1に、JMSモジュールの種類と、それらがどのように構成および変更されるかを示します。

表2-1 JMSモジュール・タイプと構成および管理オプション

モジュールの種類	作成に使用するツール	モジュールの動的追加/削除	JMXでのリモート変更	デプロイメント・チューニング・プランによる変更(非リモート)	リモート・コンソールでの変更	スコープ指定	デフォルト・サブ・モジュール・ターゲット指定
システム	リモート・コンソールまたはWLST	はい	はい	いいえ	はい。JMXを使用	グローバルおよびローカル	いいえ
アプリケーション	IDEまたはXMLエディタ	いいえ。再デプロイが必要	いいえ	はい。デプロイメント計画を使用	はい。デプロイメント計画を使用	グローバル、ローカル、およびアプリケーション	はい

JMSアプリケーション・モジュールのデプロイメントの準備については、JMSアプリケーション・モジュールのデプロイメントの構成とOracle WebLogic Serverへのアプリケーションのデプロイのweblogic.deployerによるアプリケーションおよびモジュールのデプロイを参照してください。

モジュールに構成できるJMSリソース

システム・モジュールまたはアプリケーション・モジュールの一部として、以下の基本構成リソースが定義されます。

• キューおよびトピック宛先。「キューおよびトピック宛先の構成」を参照。

• 接続ファクトリ。「接続ファクトリの構成」を参照。

• テンプレート。「JMSテンプレートの構成」を参照。

• 宛先キー。「宛先キーの構成」を参照。

• 割当て。「割当ての構成」を参照。

• 分散宛先。「分散宛先リソースの構成」を参照。

• 外部サーバー。「外部サーバー・リソースからサード・パーティJMSプロバイダへのアクセスの構成」を参照。

• JMSストア・アンド・フォワード(SAF)構成項目。「JMSストア・アンド・フォワード(SAF)」を参照してください。

これ以外のすべてのJMS環境関連リソースは、ドメイン構成リソースとして管理者が構成する必要があります。これには、以下のものが含まれます。

• JMSサーバー(必須)。「JMSサーバーの概要」を参照してください

• ストア・アンド・フォワード・エージェント(オプション)。「JMSストア・アンド・フォワード(SAF)」を参照してください。

• パス・サービス(オプション)。「パス・サービス」を参照してください

• メッセージング・ブリッジ(オプション)。「メッセージング・ブリッジ」を参照してください

• 永続ストア(オプション)。「永続ストア」を参照してください

JMSシステム・モジュールの構成の詳細は、「基本JMSシステム・リソースの構成」を参照してください

JMSスキーマ

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相互運用モジュール(非推奨)

ノート:

JMS相互運用モジュールは、WebLogic Server 12.1.1では非推奨です。config.xmlにinterop-jms.xmlという名前のモジュールがある場合は、標準のシステム・モジュールに変換してください。「JMSシステム・モジュールの構成」を参照してください

JMS Interopモジュールは、特殊なタイプのJMSシステム・リソース・モジュールです。このモジュールは、このリリースのためのJMS構成アップグレードの結果として、および旧リリースからWebLogic JMX MBean APIを使用することによって作成および管理されます。

JMS Interopモジュールは、以下に示すように、JMSシステム・リソース・モジュールとは様々な点で異なります。

• JMSモジュール記述子の名前は常にinterop-jms.xmlです。このファイルはドメインのconfig\jmsディレクトリにあります。

• 他のJMSシステム・リソース・モジュールの所有者が主に管理者であるのに対し、Interopモジュールはシステムによって所有されます。

• Interopモジュールは、ドメインのどこでもターゲット指定されます。

• JMS Interopモジュールに存在するJMSリソースは、非推奨のJMX (MBean) APIを使用してアクセスおよび管理できます。

• JMS InteropモジュールのMBeanはJMSInteropModuleMBeanです。これはDomainMBeanの子MBeanであり、ドメイン内の他の子MBeanと同様にDomainMBeanからルックアップできます。

JMS Interopモジュールには、メッセージ順序単位や宛先割当てなどの、WebLogic Server 9.x以降の機能の多くも実装できます。ただし、WebLogic Server 9.x以降の機能のうち次の機能は実装できません。

• 共通分散宛先リソース

• JMSストア・アンド・フォワード・リソース

  ノート:

  JMS Interopモジュールで現在のリリースの新しい機能を使用すると、WebLogic Server 9.xより前のバージョンのJMXクライアントとの互換性が損なわれる場合があります。

WebLogic JMSの他の環境関連システム・リソース

JMSサーバーおよびシステム・モジュールに加えて、管理者は次のアーティファクトのいずれかを構成する必要がある場合があります。

• 永続ストア
  
• JMSストア・アンド・フォワード
  
• パス・サービス
  
• メッセージング・ブリッジ
  

永続ストア

WebLogic永続ストアは、永続性を必要とするすべてのサブシステムとサービスに対し、組込みの高性能なストレージの仕組みを提供します。たとえば、永続JMSメッセージを格納したり、ストア・アンド・フォワード機能を使用して、メッセージを一時的に格納してから送信したりできます。ドメインの各WebLogic Serverインスタンスには、構成が不要で、システムのデフォルト・ストレージを使用する複数のサブシステムで同時に使用できるデフォルトの永続ストアがあります。なお、JMS実装に合せて専用のファイル・ベース・ストアまたはJDBCデータベース対応ストアを作成することもできます。JMSの永続ストアの構成の詳細は、Oracle WebLogic Serverサーバー環境の管理のWebLogic永続ストアの使用方法を参照してください。

JMSストア・アンド・フォワード

SAFサービスを使用すると、複数のWebLogic Serverインスタンスに分散されているアプリケーション間でメッセージを確実に配信できます。たとえば、SAFサービスを利用すると、ローカルのWebLogic Serverインスタンス上で動作するアプリケーション、またはローカルのWebLogic Serverインスタンスに接続するアプリケーションは、リモート・サーバー上の宛先にメッセージを確実に配信できます。ネットワークの問題やシステム障害が原因で、メッセージの送信時に宛先が使用不能になっている場合、メッセージはローカルのサーバー・インスタンスに保存され、リモートの宛先が使用可能になった時点で転送されます。

JMSモジュールはSAFサービスを使用して、ローカルのJMSメッセージ・プロデューサがリモートのJMSキューまたはトピックにメッセージを確実に送信できるようにします。Oracle WebLogic Serverストア・アンド・フォワード・サービスの管理のJMSメッセージに対するSAFの構成を参照してください。

パス・サービス

WebLogic Serverパス・サービスは、分散キュー・メンバーまたはストア・アンド・フォワード・パスにメッセージを固定することによってメッセージ・グループとメッセージング・リソースの間のマッピングを格納するための永続マップです。パス・サービスの構成の詳細は、「WebLogicパス・サービスの使用」を参照してください。

メッセージング・ブリッジ

メッセージング・ブリッジを使用すると、2つのメッセージング製品間の転送メカニズムを構成することで、WebLogic JMSの異なる実装間、またはWebLogic JMSと別のメッセージング製品間の相互運用性を実現できます。メッセージング・ブリッジ・インスタンスと、ブリッジのソースおよびターゲット宛先インスタンスは、ドメインのconfig.xmlファイルに保持されます。Oracle WebLogic Server WebLogicメッセージング・ブリッジの管理のメッセージング・ブリッジの理解を参照してください。