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

前
 
次
 

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

この章では、WebLogic JMSの基本的な概念と機能を簡単に紹介し、それらと他のアプリケーション・コンポーネントおよびWebLogic Server 12.1.3との連携の仕組みについて説明します。

この章は、JavaのプログラミングおよびJMS 1.1の概念と機能に精通している読者を対象としています。

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

JMSとWebLogic Serverの概要

JMSのWebLogic Server実装は、WebLogic Serverプラットフォームに緊密に統合されたエンタープライズ・クラスのメッセージング・システムです。JMS 1.1仕様(http://www.oracle.com/technetwork/java/jms/index.htmlで入手可能)を完全にサポートしています。また、標準JMS APIより高度なWebLogic JMS拡張も数多く用意されています。

Java Message Serviceとは

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

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

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

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

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

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

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

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

図2-1の説明が続きます
「図2-1 WebLogic JMSのアーキテクチャ」の説明

図2-1では、A1およびB1が接続ファクトリ、B2がキューです。

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 Server管理コンソール、WebLogic Scripting Tool (WLST)などの様々なコマンド・ライン・ツール、またはプログラムによる管理用のJMX APIを使用できます。

ドメイン環境に依存しないアプリケーション関連の定義の例としては、様々なJava 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アプリケーション・モジュールは、Java EEモジュールのWebLogic固有の拡張機能であり、Java 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 Server管理コンソールまたはWebLogic Scripting Tool (WLST)を使用して構成され、ドメインのconfig.xmlファイル内にそのモジュールへの参照が追加されます。JMSアプリケーション・モジュールは、Java EEモジュールのWebLogic固有の拡張機能であり、Java EEアプリケーションと共に(パッケージ化されたリソースとして)、またはグローバルに使用可能なスタンドアロン・モジュールとしてデプロイできます。

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

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

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

JMSシステム・モジュール

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

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

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

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

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

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

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

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

JMSアプリケーション・モジュール

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

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

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

JMSアプリケーション・モジュールの構成については、第6章「JMSアプリケーション・モジュールのデプロイメントの構成」を参照してください。

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

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

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

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

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

モジュールの種類 作成手段 モジュールの動的追加/削除 JMXで変更(リモート) デプロイメント・チューニング・プランによる変更(非リモート) 管理コンソールによる変更 スコープ指定 デフォルト・サブ・モジュール・ターゲット指定

システム

管理コンソールまたはWLST

はい

はい

いいえ

はい - JMXから

グローバルおよびローカル

いいえ

アプリケーション

IDEまたはXMLエディタ

いいえ - 再デプロイが必要

いいえ

はい - デプロイメント・プランから

はい - デプロイメント・プランから

グローバル、ローカル、およびアプリケーション

はい


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

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

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

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

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.xmlinterop-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からルックアップできます。

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

以下の環境関連のリソースは、JMSサーバーおよびJMSモジュールにアクセス可能となるように、管理者によってドメイン構成リソースとして構成される必要があります。

永続ストア

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

JMSストア・アンド・フォワード(SAF)

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メッセージング・ブリッジの管理』のメッセージング・ブリッジの理解に関する項を参照してください。