|
|
以下の節では、WebLogic JMS のさまざまな概念と機能を簡単に紹介し、それらと他のアプリケーション コンポーネントおよび WebLogic Server との連携の仕組みについて説明します。
この章は、Java のプログラミングおよび JMS 1.1 の概念と機能に精通している読者を対象としています。
JMS の WebLogic Server 実装は、WebLogic Server プラットフォームに緊密に統合されたエンタープライズ クラスのメッセージング システムです。JMS 1.1 仕様を完全にサポートし、標準 JMS API を超える機能を持つ WebLogic JMS 拡張が数多く用意されています。
エンタープライズ メッセージング システムを使用すると、アプリケーションどうしがメッセージを交換することによって通信できます。メッセージとは、異なるアプリケーション間の通信を調整するために必要な情報が含まれている、要求、レポート、およびイベントです。メッセージで提供される抽象化の階層により、送り先システムについての詳細情報をアプリケーション コードから切り離すことができます。
Java Message Service (JMS) は、業界メッセージング プロバイダによって実装されるエンタープライズ メッセージング システムにアクセスするための標準 API です。具体的な JMS の特長は以下のとおりです。
WebLogic JMS は、プロデューサ アプリケーションからメッセージを受信し、そのメッセージをコンシューマ アプリケーションに配信します。WebLogic Server での JMS API プログラミングの詳細については、『WebLogic JMS プログラマーズ ガイド』を参照してください。
次の図は、WebLogic JMS のアーキテクチャを示しています。
WebLogic JMS アーキテクチャの主要コンポーネントは以下のとおりです。
weblogic-jms.xsd スキーマに準拠する XML ドキュメントによって定義される JMS モジュール。詳細については、「JMS コンフィグレーション リソースとは」を参照してください。
一般に、WebLogic Server ドメイン コンフィグレーション ファイル (config.xml) には、ドメインに必要なコンフィグレーション情報が記述されています。このコンフィグレーション情報をさらに分類すると、環境関連の情報とアプリケーション関連の情報に分けられます。環境関連の情報には、JMS サーバの ID と定義、JDBC データ ソース、WebLogic 永続ストア、サーバ ネットワーク アドレスなどがあります。通常、これらのシステム リソースは、ドメインごとにユニークです。
これらのシステム リソースのコンフィグレーションと管理を行うのは、WebLogic 管理者です。WebLogic 管理者は、組織のシステム管理者または MIS 部門からこの情報を受け取ります。これらのタスクを実行するために、管理者は WebLogic Administration Console、WebLogic Scripting Tool (WLST) などのさまざまなコマンドライン ツール、またはプログラムによる管理用の JMX API を使用できます。
ドメイン環境に依存しないアプリケーション関連の定義の例としては、さまざまな Java EE アプリケーション コンポーネント コンフィグレーション (EAR、WAR、JAR、RAR の各ファイル、JMS および JDBC モジュールなど) があります。アプリケーション コンポーネントは、アプリケーション開発チームによって開発およびパッケージ化され、さらにプログラム (コンパイル済み Java コード) とそのコンフィグレーション情報 (記述子とも呼ばれ、そのほとんどは XML ファイルとして格納される) を持つ場合があります。ただし、JMS および JDBC モジュールの場合、コンパイル済み Java コードは含まれません。あらかじめパッケージ化されたこれらのアプリケーションは、WebLogic Server 管理者によって WebLogic ドメインにデプロイされます。
アプリケーションをデプロイするプロセスによって、アプリケーション コンポーネントと環境固有のリソース定義がリンクされます。たとえば、特定のアプリケーション コンポーネントをホストするサーバ インスタンス (対象指定) や、JMS メッセージを保持する WebLogic 永続ストアなどです。
最初のデプロイメントの完了後は、デプロイされたアプリケーションに対する管理者の権限は限定されます。たとえば、管理者はアプリケーションの適切なライフ サイクルの保持 (デプロイ、アンデプロイ、再デプロイ、削除など) とパラメータの調整 (クライアントのニーズに合わせてアプリケーションのインスタンス数を増減するなど) しか行うことができません。ライフ サイクルとチューニング以外の変更は、アプリケーション開発チームによって行われます。
WebLogic Server 9.0 以降では、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 サーバはドメインの config.xml ファイルに保持され、クラスタ内のさまざまな WebLogic Server インスタンスで複数の JMS サーバをコンフィグレーションできます (独自の名前が付けられている場合に限る)。クライアント アプリケーションでは、JNDI ツリーまたは java:/comp/env ネーミング コンテキストを使用して接続ファクトリをルックアップし、接続を作成して JMS サーバとの通信を確立します。各 JMS サーバでは、すべての対象モジュールの送り先に対するリクエストが処理されます。JMS サーバによって処理されない送り先に対するリクエストは、適切なサーバ インスタンスに転送されます。
WebLogic Server 9.0 以降では、JMS サーバの動作が一部の点で 9.0 より前のリリースと異なります。
JMS サーバのコンフィグレーションの詳細については、「JMS サーバのコンフィグレーション」を参照してください。
JMS モジュールは、ドメイン環境から独立したアプリケーション関連の定義です。JMS リソースは、システム モジュールとして、またはアプリケーション モジュールとして作成および管理します。JMS システム モジュールは、通常、Administration Console または WebLogic Scripting Tool (WLST) を使用してコンフィグレーションされ、ドメインの config.xml ファイル内にそのモジュールへの参照が追加されます。JMS アプリケーション モジュールは、Java EE モジュールの WebLogic 固有の拡張機能であり、Java EE アプリケーションと共に (パッケージ化されたリソースとして)、またはグローバルに使用可能なスタンドアロン モジュールとしてデプロイできます。
システム モジュールとアプリケーション モジュールは、主に所有権に関して異なります。システム モジュールは WebLogic 管理者によって所有および変更され、すべてのアプリケーションで利用可能です。アプリケーション モジュールは、この JMS リソース モジュールをアプリケーションの EAR ファイルにパッケージ化する WebLogic 開発者によって所有および変更されます。
JMS リソースのモジュール形式のデプロイメントでは、エンタープライズ アプリケーション ファイル (EAR ファイルなど) またはスタンドアロン JMS モジュールを開いたり、JMS を手動で広範囲に再コンフィグレーションしたりすることなく、アプリケーションと必要な JMS コンフィグレーションを、ある環境から別の環境に (たとえば、テスト環境からプロダクション環境に) 移行できます。
以下の節では、さまざまなタイプの JMS モジュールとそこに含められるリソースについて説明します。
WebLogic 管理者は、通常、Administration Console または 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 ディレクトリ内のモジュールの例を示します。
JMS システム モジュールのコンフィグレーションの詳細については、「基本 JMS システム リソースのコンフィグレーション」を参照してください。
JMS コンフィグレーション リソースは、標準の Java EE 記述子ベースのモジュールと同様に、デプロイ可能なアプリケーション モジュールとしても管理できます。JMS アプリケーション モジュールは、Java EE アプリケーションと共にパッケージ化されたモジュールとして (この場合、モジュール内のリソースは同梱されたアプリケーションでのみ利用可能 (アプリケーション スコープなど))、またはそのモジュール内のリソースへのグローバル アクセスを提供するスタンドアロン モジュールとしてデプロイできます。
通常、アプリケーション開発者が、エンタープライズ レベルの IDE または XML 記述子ファイルの編集に対応した開発ツールでアプリケーション モジュールを作成し、それらの JMS モジュールをアプリケーションの一部としてパッケージ化して、デプロイ、管理、およびチューニングのためにアプリケーションを WebLogic 管理者に渡します。
「ドメイン コンフィグレーション : 環境関連リソースとアプリケーション関連リソース」で説明したように、JMS アプリケーション モジュールにはコンパイル済みの Java プログラムがパッケージの一部として含まれていないので、管理者またはアプリケーション開発者は必要に応じた形で JMS リソースを作成したり管理したりできます。
JMS アプリケーション モジュールのコンフィグレーションについては、「JMS アプリケーション モジュールのデプロイメントのコンフィグレーション」を参照してください。
WebLogic JMS のコンフィグレーションと管理を理解するための鍵は、JMS リソースの作成者と作成方法によってリソースをデプロイおよび変更する方法が決まるということです。JMS モジュールは、WebLogic の管理者とプログラマがコンフィグレーションできます。
システム モジュールとは対照的に、デプロイされた JMS アプリケーション モジュールの所有者は、モジュールをデプロイした管理者ではなく、モジュールを作成およびパッケージ化した開発者となります。したがって、デプロイしたリソースに対しては、管理者の制御が及ぶ範囲がより制限されます。アプリケーション モジュールをデプロイする場合、管理者はモジュールで指定されたリソース プロパティの変更はできますが、リソースの追加や削除はできません。他の Java EE モジュールのように、アプリケーション モジュールのデプロイメント コンフィグレーションの変更はモジュールのデプロイメント プランに格納され、元のモジュール自体は変更されません。
表 2-1 に、JMS モジュールのタイプとそれぞれのコンフィグレーションおよび変更方法を示します。
JMS アプリケーション モジュールのデプロイメントの準備については、「JMS アプリケーション モジュールのデプロイメントのコンフィグレーション」と『WebLogic Server アプリケーションのデプロイメント』の「weblogic.deployer によるアプリケーションおよびモジュールのデプロイ」を参照してください。
システム モジュールまたはアプリケーション モジュールの一部として、以下の基本コンフィグレーション リソースが定義されます。
これ以外のすべての JMS 環境関連リソースは、ドメイン コンフィグレーション リソースとして管理者がコンフィグレーションする必要があります。これには、以下のものが含まれます。
JMS システム モジュールのコンフィグレーションの詳細については、「基本 JMS システム リソースのコンフィグレーション」を参照してください。
JMS リソースのモジュラー コンフィグレーション モデルのサポートとして、WebLogic JMS オブジェクトのスキーマ、weblogic-jms.xsd が用意されています。JMS リソース モジュール (記述子) を作成する際は、モジュールをこのスキーマに準拠させる必要があります。IDE や他のツールでは、このスキーマに基づいて JMS リソース モジュールを検証できます。
weblogic-jms.xsd スキーマは、http://www.bea.com/ns/weblogic/weblogic-jms/1.0/weblogic-jms.xsd からオンラインで入手できます。
JMS Interop モジュールは、特殊なタイプの JMS システム リソース モジュールです。このモジュールは、このリリースのための JMS コンフィグレーション アップグレードの結果として、および旧リリースから WebLogic JMX MBean API を使用することによって作成および管理されます。
JMS Interop モジュールは、以下に示すように、JMS システム リソース モジュールとはさまざまな点で異なります。
interop-jms.xml で、このファイルはドメインの config\jms ディレクトリに存在する。JMSInteropModuleMBean。これは DomainMBean の子 MBean で、ドメイン内の他の子 MBean と同じように DomainMBean からルックアップできます。
JMS Interop モジュールには、メッセージの順序単位や送り先割り当てなどの、WebLogic Server 9.0 以降の機能の多くも実装できます。ただし、WebLogic Server 9.0 以降の機能のうち以下の機能は実装できません。
| 警告 : | JMS Interop モジュールで現在のリリースの新しい機能を使用すると、WebLogic Server 9.0 より前のバージョンの JMX クライアントとの互換性が損なわれる場合があります。 |
以下の環境関連のリソースは、JMS サーバおよび JMS モジュールにアクセス可能となるように、管理者によってドメイン コンフィグレーション リソースとしてコンフィグレーションされる必要があります。
WebLogic 永続ストアは、永続性を必要とするすべてのサブシステムとサービスに対し、組み込みの高性能なストレージの仕組みを提供します。たとえば、永続 JMS メッセージを格納したり、ストア アンド フォワード機能を使用して、メッセージを一時的に格納してから送信したりできます。ドメインの各 WebLogic Server インスタンスには、コンフィグレーションが不要で、システムのデフォルト ストレージを使用する複数のサブシステムで同時に使用できるデフォルトの永続ストアがあります。なお、JMS 実装に合わせて専用のファイル ベース ストアまたは JDBC データベース対応ストアを作成することもできます。JMS に対する永続ストアのコンフィグレーションについては、『サーバ環境のコンフィグレーション』の「WebLogic 永続ストアの使い方」を参照してください。
SAF サービスを使用すると、複数の WebLogic Server インスタンスに分散されているアプリケーション間でメッセージを確実に配信できます。たとえば、SAF サービスを利用すると、ローカルの WebLogic Server インスタンス上で動作するアプリケーション、またはローカルの WebLogic Server インスタンスに接続するアプリケーションは、リモート サーバ上の送り先にメッセージを確実に配信できます。ネットワークの問題やシステム障害が原因で、メッセージの送信時に送り先が使用不能になっている場合、メッセージはローカルのサーバ インスタンスに保存されて、リモートの送り先が使用可能になった時点で転送されます。
JMS モジュールは、SAF サービスを利用して、ローカルの JMS メッセージ プロデューサがリモートの JMS キューまたはトピックにメッセージを確実に送信できるようにします。詳細については、『WebLogic ストア アンド フォワードのコンフィグレーションと管理』の「JMS メッセージに対する SAF のコンフィグレーション」を参照してください。
WebLogic Server パス サービスは、分散キュー メンバーまたはストア アンド フォワード パスにメッセージを固定することによってメッセージ グループとメッセージング リソースの間のマッピングを格納するための永続マップです。パス サービスのコンフィグレーションについては、「WebLogic パス サービスの使用」を参照してください。
メッセージング ブリッジを使用すると、2 つのメッセージング製品間の転送メカニズムをコンフィグレーションすることで、WebLogic JMS の異なる実装間、または WebLogic JMS と別のメッセージング製品間の相互運用性を実現できます。メッセージング ブリッジ インスタンス、およびブリッジのソースおよび対象送り先インスタンスは、ドメインの config.xml ファイルに保持されます。詳細については、『WebLogic メッセージング ブリッジのコンフィグレーションと管理』の「メッセージング ブリッジについて」を参照してください。
  
|