|
| |
| Sun Java System Message Queue 3 2005Q1 技術の概要 | |
第 2 章
Message Queue の紹介Message Queue は、JMS 1.1 仕様に準拠した信頼性の高い非同期メッセージングサービスです。また Message Queue には、大規模なエンタープライズ配備の必要を満たすために、JMS 仕様で定められた要件以上の機能も多数用意されています。
この章では、Message Queue サービスのアーキテクチャについて説明し、企業向けのさまざまな特長や機能を紹介します。章には次のトピックが含まれます。
メッセージサービスのアーキテクチャMessage Queue サービスは、以下の要素で構成されています。
図 2-1 に、これらのエレメントの連携動作の仕組みを示します。
図 2-1 Message Queue サービスのアーキテクチャ
図に示されるとおり、Message Queue クライアントは、Java または C API を使用してメッセージを送受信します。これらの API は、Java または C クライアントのランタイムライブラリに実装されます。ランタイムライブラリは、ブローカへのコネクションを作成する実際の動作を行い、要求されるコネクションサービスに合わせて適切にパッケージします。アプリケーションが管理対象オブジェクトを使用すると、クライアントランタイムはオブジェクトストアの中からその管理対象オブジェクトを見つけ、管理対象オブジェクトを使用してコネクションを設定し、物理的な送信先を特定します。ブローカは、メッセージのルーティングと配信を行います。管理者は、Message Queue 管理ツールを使用してブローカを管理し、管理対象オブジェクトをオブジェクトストアに追加します。
これらの各要素については、以下の節で簡単に説明します。
メッセージサーバー
メッセージサーバーは、1 つ以上のブローカで構成され、メッセージのルーティングと配信を実行します。Message Queue サービスの中核となる構成要素です。
メッセージサーバーは、メッセージのルーティングサービスと配信サービスを実行する、1 つのブローカまたはブローカクラスタとして連携動作するブローカのセットで構成されています。ブローカは、以下のタスクを実行するプロセスです。
メッセージサーバー、メッセージサーバーの内部コンポーネント、および実行可能な機能についての詳細は、第 4 章「メッセージサーバー」を参照しください。
Message Queue Enterprise Edition は、連結された複数のブローカインスタンスによって構成されるブローカクラスタをサポートしており、これによりメッセージサーバーは、メッセージトラフィックの量に応じて拡張または縮小することができます。アーキテクチャとクラスタ構成の問題の詳細は、第 5 章「ブローカクラスタ」を参照してください。
クライアントランタイム
Message Queue クライアントランタイム (client runtime) は、Message Queue サービスへのインタフェースを備えるクライアントアプリケーションです。クライアントランタイムは、Message Queue クライアントがメッセージをプロデュース (送信先にメッセージを送信) し、メッセージをコンシューム (送信先からメッセージを受信) する場合に必要なすべての操作をサポートします。
図 2-1 に示すように、Message Queue クライアントランタイムは次の 2 種類の言語で実装されています。
- Java クライアントランタイム: JMS API を実装し、Message Queue メッセージサーバーと対話するために必要なすべてのオブジェクトとともに、Java クライアントアプリケーションとコンポーネントを提供します。これらのインタフェースオブジェクトには、コネクション、セッション、メッセージ、メッセージプロデューサ、メッセージコンシューマなどがあります。
- C クライアントランタイム: Message Queue サーバーと対話するために必要な C プログラミングインタフェースとともに、C クライアントアプリケーションとコンポーネントを提供します。C クライアントランタイムは、JMS API メッセージングモデルのプロシージャ版をサポートします。
Message Queue クライアントとメッセージサーバーの間でクライアントランタイムが担う中心的役割を、図 2-2 に示します。メッセージの配信がクライアントランタイムとメッセージサーバーの間の対話動作であるのに対し、メッセージのプロデュースおよびコンシュームは、クライアントとクライアントランタイムの間の対話動作です。
図 2-2 クライアントランタイムとメッセージング操作
クライアントランタイムは以下の機能を実行します。
以下の項では、クライアントランタイムの機能について簡単に説明します。クライアントランタイムの何種類かの動作は、コネクションファクトリオブジェクトのプロパティを設定することによりカスタマイズできます。
コネクション処理
コネクション処理動作を設定するには、クライアントの接続先にするブローカのホスト名とポート、および使用するコネクションサービスのタイプを指定する必要があります。クラスタを構成するブローカとの間でコネクションを確立する場合には、コネクションの確立先となるアドレスの一覧を指定する必要があります。ブローカがオフラインの場合は、クライアントランタイムによってクラスタ内の別のブローカに接続されます。
Enterprise Edition では、コネクションに失敗すると、ブローカへの再接続がクライアントランタイムによって自動的に実行されます。クラスタを構成するブローカにクライアントが接続されている場合は、同じブローカに再接続するか、最初のコネクションとは異なるブローカに接続できます。
ブローカインスタンスが、Message Queue と Sun Cluster を統合することで実現できる高可用性共有持続ストアを使用しない場合は、異なるブローカインスタンスに再接続すると、障害が発生したり切断されたりしたブローカが保持している持続メッセージや他の状態情報は消失する可能性があります。つまり、再接続によってコネクションはフェイルオーバーしますが、データは失われます。
クライアントの識別
アプリケーションで使用すると有効な場合には、どのコネクションにでもクライアント ID を設定できます。クライアント ID は、永続サブスクライバを識別できるように設定する必要があります。
永続サブスクリプションを追跡し続けるため、ブローカは一意のクライアント識別情報を使用します。クライアント ID を使用して、メッセージがトピック送信先に配信されたときに非アクティブ状態になっている永続サブスクライバを識別します。ブローカは、非アクティブのサブスクライバ宛のメッセージを保持し、そのサブスクライバがアクティブになったら配信できるようにします。
したがって、配置されたアプリケーションで永続サブスクリプションを使用する場合はいつでも、クライアント ID を設定する必要があります。Message Queue 機能により、クライアント ID を指定するときに特殊な変数名構文を使用できます。これにより、管理者またはプログラムのどちらがオブジェクトを作成した場合でも、コネクションファクトリオブジェクトから入手したコネクションごとに、異なるクライアント ID を入手することが可能です。詳細は、『Message Queue 管理ガイド』を参照してください。
コンシューマへのメッセージ分散
コネクションを介してブローカが配信したメッセージは、クライアントランタイムが受信し、適切な Message Queue セッションに分散されます。メッセージは、図 2-3 に示すようにキューに入れられ、それぞれのメッセージコンシューマによってコンシュームされるのを待ちます。
図 2-3 Message Queue クライアントランタイムへのメッセージの配信
メッセージは、各セッションキューから 1 つずつフェッチされ、receive() メソッドを呼び出すクライアントスレッドにより同期的に、またはメッセージリスナオブジェクトの onMessage() メソッドを呼び出すセッションスレッドにより非同期的にコンシュームされます (セッションはシングルスレッド)。
クライアントランタイムに配信されるメッセージのフローは、コンシューマレベルで測定されます。コネクションファクトリのプロパティを適切に調整することにより、メッセージのフローのバランスをとり、1 つのセッションに配信されたメッセージが、同じコネクションの他のセッションへのメッセージ配信に悪影響を与えることのないようにします。
信頼性の高い確実なメッセージ配信
クライアントランタイムには、信頼性の高い方法で確実にメッセージを配信するという重要な役割があります。クライアントランタイムは、JMS 仕様のクライアント通知機能とトランザクションモードをサポートし、信頼性の高い配信を保証するためのさまざまなブローカ通知動作を制御します。
JMS 仕様では、さまざまな信頼性レベルを提供する多くのクライアント通知モードについて規定しています。これらの通知モード、および Message Queue によって実装される追加モードについては、メッセージのコンシュームに関する節で説明します (「クライアント通知」を参照)。
持続メッセージおよび信頼性の高い配信の場合、ブローカは通常、一度だけかつ確実にメッセージをコンシュームするために使用した操作が完了すると、クライアントランタイムに通知します。コネクションファクトリのプロパティを使用してそのようなブローカ通知を抑制し、それによってネットワーク帯域幅と処理を節約することが可能です。当然のことですが、ブローカ通知を抑制すると信頼性の高い配信は保証されなくなります。
メッセージフロー制御
クライアントランタイムは、コネクション全体のメッセージのフローを見張るゲートキーパーです。Message Queue は、コネクション全体を流れる正規の JMS ペイロードメッセージ以外にもさまざまなコントロールメッセージを送信して、信頼性の高い配信を保証し、コネクション全体でのメッセージのフローを管理し、他の制御機能を実行します。
ペイロードメッセージとコントロールメッセージは同じコネクションで競合するので、衝突して停滞を引き起こす可能性があります。クライアントランタイムは、さまざまな設定可能フロー制限と測定手段を強制的に適用してペイロードメッセージとコントロールメッセージの衝突を最小限に抑え、これによりメッセージのスループットを最大限に高めます。
メッセージのヘッダー値のオーバーライド
クライアントランタイムは、メッセージの持続性、生存期間、および優先度を指定する JMS メッセージヘッダーフィールドをオーバーライドできます。
Message Queue は、コネクションレベルでメッセージヘッダーのオーバーライドを許可します。オーバーライドは、所定のコネクションのコンテキストでプロデュースされるすべてのメッセージに適用されます。
クライアントランタイムがメッセージヘッダー値をオーバーライドする機能を備えているので、Message Queue 管理者は、メッセージサーバーのリソースをより細かく制御できます。ただし、これらのフィールドをオーバーライドすることには、メッセージの持続性などのアプリケーション固有の要件を阻害する危険性が伴います。したがってこの機能は、適当なアプリケーションユーザーまたは設計者に相談した上でのみ使用してください。
その他の機能
クライアントランタイムは、ほかに以下の機能を実行します。
管理対象オブジェクト
管理対象オブジェクトは、プロバイダ固有の実装情報と、コネクションおよび送信先に関する設定情報をカプセル化します。管理対象オブジェクトは、プログラムによって作成するか、管理者ツールを使用して作成および設定し、オブジェクトストアに保管して、標準 JNDI 検索コードによりクライアントアプリケーションからアクセスできます。
Message Queue には、以下の表に示す管理対象オブジェクトタイプが用意されています。
表 2-1 Message Queue 管理対象オブジェクトタイプ
タイプ
説明
Destination
ブローカ内の物理的な送信先を表します。ブローカ内の物理的な送信先のプロバイダ固有名が収められています。メッセージコンシューマまたはメッセージプロデューサのオブジェクトは、送信先管理対象オブジェクトを使用して対応する物理的な送信先にアクセスします。
Connection Factory
クライアントアプリケーションと Message Queue メッセージサーバーの間で物理的な接続を確立します。また、物理的な接続の動作を制御する Message Queue クライアントランタイムも設定します。コネクションファクトリ管理対象オブジェクトの属性値を設定する場合は、そのオブジェクトが確立するすべてのコネクションに適用されるプロパティを指定します。
XA Connection Factory
分散トランザクションをサポートする物理的な接続を確立するために使用します (「分散トランザクション」を参照)。XA コネクションファクトリオブジェクトは、正規のコネクションファクトリオブジェクトと同じ属性セットを共有しますが、分散トランザクションに対応するために必要な補足メカニズムを使用可能にします。
SOAP Endpoint
SOAP メッセージの最終送信先を特定します。これは、SOAP メッセージを受信可能なサーブレットの URL です。SOAP 終端管理対象オブジェクトは、複数の URL を指定して設定可能です。また、オブジェクトに関連付けられた検索名とオブジェクトストア属性を指定します。
JNDI を介しての管理対象オブジェクトの使用
JMS 仕様では、JMS クライアントが JNDI ネームスペースの管理対象オブジェクトを検索するよう規定していませんが、管理対象オブジェクトを検索することにははっきりとした利点があります。たとえば、一元管理を行い、レコードがなくてもコネクション (クライアントランタイムの動作) を設定および再設定し、クライアントを他の JMS プロバイダに移植可能にすることができます。
管理対象オブジェクトにより、次のように Message Queue サービスを容易に制御および管理できます。
言い換えると、管理対象オブジェクトを使用することにより、Message Queue の管理者は、メッセージサービスの詳細設定を制御しながら、同時にクライアントアプリケーションをプロバイダ非依存にすることができます。
管理対象オブジェクトを使用することにより、クライアントプログラマは、プロバイダ固有の構文とオブジェクト命名規則、またはプロバイダ固有の設定プロパティを把握している必要がなくなります。実際、管理対象オブジェクトを読み取り専用に指定することにより、管理者は、管理対象オブジェクトが最初に作成されたときに設定した管理対象オブジェクトの属性値を、クライアントアプリケーションが変更できないようにすることができます。
クライアントアプリケーションでは、所有するコネクションファクトリオブジェクトと送信先管理対象オブジェクトの両方をインスタンス化することができますが、この手法は管理対象オブジェクトの基本目的を損ないます。Message Queue 管理者は、アプリケーションによって要求されるブローカリソースを制御し、メッセージングのパフォーマンスを調整する必要があります。また、管理対象オブジェクトを直接インスタンス化すると、クライアントアプリケーションがプロバイダに依存したものになります。
管理対象オブジェクトについては上述のとおりですが、管理制御が問題にならない開発環境では、多くの場合アプリケーションによって管理対象オブジェクトがインスタンス化されます。
オブジェクトストア
Message Queue 管理対象オブジェクトはオブジェクトストアに保管され (図 2-1 を参照)、クライアントアプリケーションは JNDI 検索を行なってオブジェクトストアに保管された管理対象オブジェクトにアクセスできます。Message Queue は、標準 LDAP ディレクトリサーバーとファイルシステムオブジェクトストアの 2 つのオブジェクトストアタイプをサポートします。
LDAP サーバーオブジェクトストア LDAP サーバーは、運用メッセージングシステム用のオブジェクトストアとしてお勧めします。LDAP 実装は、多数のベンダーでサポートされており、分散システムでの使用を考慮した設計になっています。LDAP サーバーは、運用環境で役立つセキュリティ機能も備えています。
ファイルシステムオブジェクトストア ファイルシステムのオブジェクトストアは、運用システムでの使用はお勧めしませんが、開発環境で使いやすいという利点があり、Message Queue でもサポートされています。LDAP サーバーをセットアップする必要はなく、ローカルのファイルシステム上にディレクトリを作成するだけで利用できます。ただし、複数のコンピュータノードにまたがって配備されたクライアントの集中オブジェクトストアとして、ファイルシステムのオブジェクトストアを使用できるのは、これらのクライアントが、オブジェクトストアの常駐するディレクトリに対してアクセス権を持っている場合に限られます。
管理ツール
Message Queue 管理ツールは、一連のコマンド行ユーティリティとグラフィカルユーザーインタフェース (GUI) 管理コンソールで構成されています。
コマンド行ユーティリティ Message Queue は、ブローカの起動と管理、物理的な送信先の作成と管理、管理対象オブジェクトの管理、より特殊なその他の管理タスクの実行など、すべての Message Queue 管理タスクを実行するコマンド行ユーティリティを装備しています。すべてのコマンド行ユーティリティは、共通の形式、構文規則、およびオプションを共有します。コマンド行ユーティリティの使用法の詳細は、『Message Queue 管理ガイド』を参照してください。
管理コンソール 管理コンソールは、Message Queue コマンド行ユーティリティの機能の一部を提供します。管理コンソールを使用して、ブローカの管理、物理的な送信先の作成と管理、および管理対象オブジェクトの管理を行うことができます。ただし、コマンド行ユーティリティが提供するいくつかの特殊なタスクは実行できません。たとえば、管理コンソールを使用して、ブローカを起動したり、ブローカクラスタを作成したり、ユーザーリポジトリを管理したりすることはできません。これらのタスクを実行するには、Message Queue のコマンド行ユーティリティを使用する必要があります。
『Message Queue 管理ガイド』には、管理コンソールについて解説し、基本的なタスクを実行する場合の管理コンソールの使用法を示した、簡単で実践的なチュートリアルが用意されています。
管理コンソールおよびコマンド行ユーティリティの一部を使用することにより、ブローカおよび物理的な送信先をリモート管理することができます。
製品の機能Message Queue サービスおよび前の節で説明したアーキテクチャでは、柔軟で信頼性の高い非同期メッセージ配信に関する JMS 1.1 仕様を全面的に実装しています。JMS への準拠に関連する問題については、付録 A 「Message Queue オプションの JMS 機能の実装」を参照してください。
ただし、Message Queue は、JMS 仕様の要件よりはるかに多くの機能や特長を備えています。Message Queue は、これらの機能により、24 時間稼働の基幹業務で大量のメッセージを交換する多くの分散コンポーネントで構成されるシステムを統合できます。
以下で説明する Message Queue のエンタープライズ機能は、次のカテゴリに分類されています。
統合サポート機能
Message Queue を使用して、数種類のトランスポートプロトコルのサポート、Message Queue サービスへの C クライアントインタフェース、SOAP (XML) メッセージのサポート、および接続可能 J2EE リソースアダプタを組み込むことにより、エンタープライズ全体で異なるアプリケーションとコンポーネントを統合することができます。
複数トランスポートのサポート
Message Queue は、TCP や HTTP などの異なる多くのトランスポートプロトコルを介し、セキュリティ保護コネクションを使用して、クライアントが Message Queue メッセージサーバーと対話する機能をサポートしています。
HTTP コネクション HTTP トランスポートにより、ファイアウォールを通過してメッセージを配信できます。Message Queue は、Web サーバー環境で実行される HTTP トンネルサーブレットを使用して、HTTP の仕組みを実装しています。クライアントによってプロデュースされるメッセージは、HTTP を介し、ファイアウォールを通過してトンネルサーブレットに配信されます。トンネルサーブレットは HTTP 要求からメッセージを抽出し、そのメッセージを TCP/IP 経由でブローカに配信します。同様に Message Queue は、HTTPS トンネルサーブレットを使用してセキュリティ保護された HTTP コネクションをサポートします。HTTP コネクションのアーキテクチャについての詳細は、「HTTP/HTTPS サポート」を参照してください。HTTP/HTTPS コネクションの設定と構成の詳細は、『Message Queue 管理ガイド』を参照してください。
セキュリティ保護コネクション Message Queue は、TCP/IP および HTTP トランスポートでの SSL (Secure Socket Layer) 標準に基づく、セキュリティ保護されたメッセージ送信機能を備えています。これらの SSL ベースのコネクションサービスでは、クライアントとブローカ間で送信されるメッセージを暗号化することができます。
SSL のサポートは、自己署名サーバー証明書に基づいています。Message Queue は、非公開 / 公開キーを生成するユーティリティを備え、自己署名証明書に公開キーを埋め込みます。証明書はブローカへのコネクションを要求しているクライアントに渡され、クライアントはこの証明書を使用して暗号化されたコネクションを設定します。自己署名証明書を作成して SSL ベースのコネクションサービスを有効にする方法の詳細は、『Message Queue 管理ガイド』を参照してください。
C クライアントインタフェース
Message Queue は、Java 言語メッセージングクライアントをサポートする以外に、Message Queue サービスへの C 言語インタフェースとしても機能します。C API により、旧バージョンの C アプリケーションと C++ アプリケーションを JMS ベースのメッセージに加えることができます。ただし、Message Queue の C API を使用するクライアントは、他の JMS プロバイダに移植できません。
Message Queue の C API は、標準 JMS 機能のほとんどに対応する C クライアントランタイムによってサポートされています。例外は、管理対象オブジェクト、マップ / ストリーム / メッセージ本体のタイプ、分散トランザクション、およびキューブラウザを使用する場合です。C クライアントランタイムも、Message Queue のエンタープライズ機能のほとんどをサポートしません。
C API の機能、および C API が C データタイプと関数を使用して JMS プログラミングモデルを実装する方法の詳細は、『Message Queue Developer's Guide for C Clients』を参照してください。
SOAP (XML) メッセージングサポート
Message Queue は、シンプルオブジェクトアクセスプロトコル (Simple Object Access Protocol、SOAP) 仕様に準拠したメッセージの作成と配信をサポートします。SOAP では、非集中の分散環境にあるピア間で、構造化 XML データ、つまり SOAP メッセージを交換できます。SOAP メッセージは、XML 形式にする必要のない添付ファイルも含めることが可能な XML ドキュメントです。
SOAP メッセージは XML でエンコードされているので、SOAP のメッセージをプラットフォーム非依存にすることができます。SOAP メッセージは、旧式のシステムからデータにアクセスし、エンタープライズ間でデータを共有するために使用できます。XML に基づくデータ統合テクノロジなので、Web サービスなどの Web ベースコンピューティングとの相性も良好です。ファイアウォールは、SOAP パケットを認識し、SOAP メッセージヘッダーで開示される情報に基づいてメッセージをフィルタできます。
Message Queue は、SAAJ (Attachments API for Java) 仕様による SOAP を実装します。SAAJ は、アプリケーションプログラミングインタフェースの 1 つで、実装することにより、SOAP メッセージングのプログラミングモデルをサポートし、SOAP メッセージを作成、送信、受信、および検査するために使用可能な Java オブジェクトを提供できます。SAAJ は次の 2 つのパッケージを定義します。
Message Queue は、SOAP メッセージを JMS メッセージに変換し、またその逆の変換も実行するユーティリティを備えています。これらのユーティリティにより、SOAP メッセージがサーブレットよって受信され、JMS メッセージに変換され、Message Queue によって JMS コンシューマに配信されるようにすることができます。また、もう一度 SOAP メッセージに変換し、SOAP 終端に配信することも可能です。言い換えると、Message Queue により、SOAP 終端の間で、信頼性の高い非同期の方法で SOAP メッセージを交換する、つまり SOAP メッセージを Message Queue サブスクライバにパブリッシュすることができます。
詳細は、『Message Queue Developer's Guide for Java Clients』を参照してください。
J2EE リソースアダプタ
Java 2 Platform, Enterprise Edition (J2EE プラットフォーム) は、Java プログラミング環境における分散コンポーネントモデルについて規定する仕様です。J2EE プラットフォームの要件の 1 つは、分散コンポーネントが、信頼性の高い非同期メッセージ交換機能により相互に対話できるようにすることです。つまり、J2EE プラットフォームでは JMS のサポートが必要となります。
JMS のサポートは、JMS メッセージをコンシューム可能な特殊な種類の EJB (Enterprise Java Bean) である MDB (メッセージ駆動型 Bean) を使用して、J2EE プログラミングモデルで提供されます。J2EE 準拠のアプリケーションサーバーは、JMS メッセージングをサポートする MDB コンテナを用意する必要があります。MDB コンテナは、JMS リソースアダプタをアプリケーションサーバーに接続して準備します。Message Queue は、そのようなリソースアダプタを装備しています。
Message Queue リソースアダプタをアプリケーションサーバーに接続することにより、アプリケーション環境内に配備されて稼働している MDB などの J2EE コンポーネントは、それらのコンポーネントどうしおよび外部 JMS コンポーネントとの間で、JMS メッセージを交換できます。これにより、分散コンポーネントを緊密に統合することができます。
Message Queue リソースアダプタについての詳細は、第 6 章「Message Queue と J2EE」を参照してください。
セキュリティ機能
保管されたメッセージデータや移送中のメッセージデータを保護する機能は、ほとんどのエンタープライズアプリケーションにとって必要不可欠です。Message Queue は、ユーザー認証、リソースへのアクセス制御、メッセージの暗号化など、さまざまなレベルでのセキュリティ機能を提供します。
認証 Message Queue は、パスワードベースのユーザー認証をサポートしています。メッセージサーバーへの接続は、単層型ファイルユーザーリポジトリまたは LDAP ユーザーリポジトリに格納されているパスワードに基づいて許可されます。すべての接続試行に関する情報 (ユーザーおよびホストコンピュータ) はログに記録され、追跡できます。
承認 アクセス制御リスト (Access control list、ACL) により、ブローカのコネクションと物理的な送信先へのアクセスを、設定可能な方法できめ細かく制御することができます。ユーザーとグループアクセスの両方がサポートされています。承認処理はブローカ単位で実行され、各ブローカは別々のアクセス制御ファイルを保有できます。
暗号化 SSL サポートにより、最大長の SSL 実装を使用して、メッセージサーバーとそのクライアントの間 (TCP/IP コネクションと HTTP コネクションのどちらでも) のすべてのメッセージトラフィックを暗号化できます。
ユーザーリポジトリへの入力方法、アクセス制御リストの管理方法、および SSL サポートの設定方法については、『Message Queue 管理ガイド』を参照してください。
スケーラビリティ機能
Message Queue では、ユーザー、クライアントコネクション、およびメッセージ負荷が大きくなるにつれて、アプリケーションを拡張することができます。
スケーラブルなコネクション機能
Message Queue ブローカは、数千の同時コネクションを処理できます。デフォルトでは、それぞれのコネクションが専用のブローカスレッドによって処理されます。この方式では、コネクションがアイドル状態のときでもスレッドが結合されるので、コネクションサービスを設定して、複数のコネクションが同じスレッドを共有できるようにすることが可能です。この共有スレッドプールモデルは、ブローカがサポート可能なコネクション数を大幅に増大させます。詳細は、「スレッドプールマネージャ」を参照してください。
ブローカクラスタ
コネクション数およびブローカによって配信されるメッセージ数が増大するにつれ、余分な負荷は補足的なブローカインスタンスを Message Queue サーバーに追加することによって管理できます。ブローカクラスタにより、クライアントコネクションどうしの平衡をとり、数多くのブローカインスタンス全体における配信処理を管理して、メッセージサーバーのスケーラビリティを大幅に高めます。ブローカインスタンスは、同じホストに、またはネットワーク全体に分散して配置することができます。クラスタリングは、メッセージのスループットを向上させ、ビジネスの必要が大きくなるのに伴ってメッセージング帯域幅を拡大する場合に理想的な方法です。ブローカクラスタについては、第 5 章「ブローカクラスタ」で説明されています。詳しくは『Message Queue 管理ガイド』を参照してください。
複数のコンシューマへのキューの配信
JMS 仕様に従って、1 つのキュー送信先にある 1 つのメッセージは、1 つのコンシューマにだけ配信することができます。Message Queue では、複数のコンシューマを 1 つのキューに登録できます。これによりブローカは、メッセージを異なる登録コンシューマに分配することができるので、コンシューマ間で負荷が分散され、システムの拡張性が維持されます。
複数コンシューマへのキューの配信の実装では、設定可能なロードバランス方式を使用します。この方式を使用することにより、アクティブコンシューマの最大数と、何らかの障害が発生した場合にアクティブコンシューマに入れ替えられる準備のできたバックアップコンシューマの最大数を指定できます。また、ロードバランスのメカニズムでは、コンシューマの現在の容量とメッセージの処理速度を考慮します。
ロードバランスされたキューの配信についての詳細は、「複数のコンシューマへのキューの配信」を参照してください。
可用性機能
Message Queue は、サービスの停止時間を最小限に抑える数多くの機能を備えています。たとえば、障害を防止するメカニズムから、Sun Cluster と統合して高可用性を実現する機能まで、広範囲に及びます。
メッセージサービスの安定性
メッセージサービスの可用性を保証するもっとも有力な方法の 1 つとして、高いパフォーマンスを発揮し、障害を最小限に抑えるサービスを提供することが挙げられます。Message Queue は、メモリーのオーバーヘッドやパフォーマンスの停滞を防ぐメカニズムを備えています。このメカニズムは、メッセージサーバーとクライアントランタイムの両方で作動します。
メッセージサーバーのリソース管理 メッセージサーバーは、メモリーと CPU リソースの点で限界があるので、応答がなくなったり、動作が不安定になるほどに過負荷がかかる可能性があります。一般にこの状態は、メッセージのプロデュース速度がコンシューム速度をはるかに上回るときに発生します。そのような状況を避けるため、個々の物理的な送信先レベルとシステム全域レベルでブローカを設定し、メモリーのオーバーランを回避することができます。詳細は、「メモリーリソース管理」を参照してください。
クライアントランタイムのメッセージフロー制御 さらに Message Queue は、クライアントランタイムへのメッセージ配信を制御するメカニズムも備えています。フロー制御メカニズムを使用することにより、クライアントランタイムへのメッセージ配信を最適化すると同時に、クライアントがメモリーを使い尽くしてしまう事態を避けることができます。詳細は、「メッセージフロー制御」を参照してください。
メッセージサーバーへの自動再接続
Message Queue には、自動再接続機能があります。メッセージサーバーとクライアントの間のコネクションで障害が発生すると、Message Queue は、コネクションの再確立を試みながらクライアント状態を保持します。ほとんどの場合、コネクションが再確立されると、メッセージのプロデュースとコンシュームは透過的に再開されます。詳細は、『Message Queue 管理ガイド』を参照してください。
Sun Cluster による高可用性
Message Queue のブローカクラスタにより、非常にスケーラブルなメッセージサーバーを構築できますが、クラスタ内の 1 つのブローカインスタンスから別のブローカインスタンスへのフェイルオーバーは現在のところサポートされていません。ただし、Message Queue を Sun Cluster ソフトウェアと統合すれば、高可用性を備えたメッセージサーバーを構築できます。Message Queue 用に開発された Sun Cluster エージェントを使用すれば、Sun Cluster により、ブローカで障害が発生した場合でも状態データを失わずに、実質的な停止時間なしでメッセージサーバーを透過的かつ即座に復元することができます。
管理機能
Message Queue は、メッセージサービスの監視と管理を行い、メッセージサービスのパフォーマンスを調整するための機能を数多く備えています。
堅牢な管理ツール
Message Queue は、コマンド行ツールと GUI ツールの両方を備えており、これらのツールによって Message Queue メッセージサーバーを運用し、送信先、トランザクション、永続サブスクリプション、およびセキュリティを管理することができます (「管理ツール」を参照)。
また Message Queue は、メッセージサーバーのリモート監視と管理をサポートするとともに、JMS 管理対象オブジェクト、ユーザーリポジトリ、プラグイン JDBC 準拠データストア、および自己署名サーバー証明書を管理するツールをサポートしています。管理ツールの使用法についての詳細は、『Message Queue 管理ガイド』を参照してください。
メッセージベースの監視 API
Message Queue では、カスタム監視アプリケーションを作成する際に使用可能な、単純な JMS ベース監視 API を使用できます。これらの監視アプリケーションは、特殊なトピック送信先からメトリックスメッセージを取得するコンシューマです。メトリックスメッセージには、Message Queue ブローカによって提供される監視データが含まれています (「メトリックスメッセージプロデューサ (Enterprise Edition)」を参照)。
各タイプのメトリックスメッセージで報告されるメトリックスの数量についての詳細は、Message Queue クライアントを開発してメトリックスメッセージをコンシュームする方法について説明した、『Message Queue Developer's Guide for Java Clients』を参照してください。メトリックスメッセージのプロデュースの設定方法に関する詳細は、『Message Queue 管理ガイド』を参照してください。
調整可能なパフォーマンス
Message Queue では、多くの方法でメッセージサーバーとクライアントランタイムの両方を調整し、最適なパフォーマンスを発揮することができます。主要なリソースを監視し、メモリーの使用状況、スレッド処理リソース、メッセージのフロー、コネクションサービス、信頼性パラメータ、およびメッセージのスループットとシステムのパフォーマンスに影響を与える他の要素を調整できます。メッセージサービスのパフォーマンスを調整する方法についての詳細は、『Message Queue 管理ガイド』を参照してください。
柔軟なサーバー設定機能
Message Queue では、持続オブジェクト、ユーザー情報、および管理対象オブジェクトの保管方法を選択できます。
設定可能な持続性
メッセージの配信を保証するため、Message Queue は、メッセージがコンシュームされるまでメッセージと他の持続オブジェクトを保管します。優れたパフォーマンスのファイルベース持続ストアを用意するとともに、Message Queue は、設定可能な持続性もサポートします。これにより、Oracle 8i などの埋め込みまたは外部の JDBC 準拠データベースに持続メッセージを保管できます。詳細は、「持続マネージャ」を参照してください。
LDAP サーバーのサポート
Message Queue では、認証および承認処理で必要になる管理対象オブジェクトとユーザー情報の両方を保管する、ファイルベースストレージを使用できます。また Message Queue は、管理対象オブジェクトストアとユーザーリポジトリで LDAP サーバーを使用する方法もサポートしています。LDAP サーバーでは、そのような情報を保存および取得するためのより安全で標準的な方法を提供しているので、運用システムで使用することをお勧めします。管理対象オブジェクトおよびユーザーリポジトリで LDAP サーバーを使用する場合についての詳細は、『Message Queue 管理ガイド』を参照してください。
製品エディションMessage Queue 製品には、Enterprise および Platform の 2 つのエディションが用意されています。どちらのエディションも JMS 仕様を完全に実装していますが、それぞれ異なる機能セットとライセンス数に対応しています。機能セットについては、次の表に比較を示します。機能についての詳細は、「製品の機能」を参照してください。
Platform Edition と Enterprise Edition のライセンス数については、以下の節で説明します。
Enterprise Edition
Message Queue Enterprise Edition により、企業の運用環境にメッセージングアプリケーションを配備して稼働させることができます。また Enterprise Edition を使用して、メッセージングアプリケーションやコンポーネントの開発、デバッグ、および負荷テストも実施できます。Enterprise Edition には、使用する CPU 数に基づいた無制限の永続的ライセンスが用意されています。このライセンスでは、複数ブローカメッセージサービスでのブローカ数に制限がありません。
Platform Edition
Message Queue Platform Edition では、メッセージサーバーでサポートされるクライアントコネクションの数に制限がありません。製品には、基本ライセンスまたは 90 日間トライアルライセンスが付いています。
- 基本ライセンスには有効期限はありません。基本ライセンスの Platform Edtion は、要件の緩い運用環境の JMS プロバイダとして使用できます。このライセンスには、Enterprise Edition の機能は含まれていません。
- 90 日間の企業向けトライアルライセンスには、基本ライセンスには含まれていない Enterprise Edition の全機能が含まれています。ただし、ライセンスの有効期間は 90 日間であるため、Enterprise Edition の製品で提供される機能を評価するのに適しています。90 日間の企業向けトライアルライセンスの使用方法についての詳細は、『Message Queue 管理ガイド』で説明されている起動オプションを参照してください。
Platform Edition は、Sun の Web サイトから無料でダウンロードできます。また、Sun Java System Application Server プラットフォームにもバンドルされています。Message Queue を Platform Edition から Enterprise Edition にアップグレードする方法については、『Message Queue インストールガイド』を参照してください。
Sun 製品群の中の Message QueueMessage Queue は、アプリケーションによって直接使用されるミドルウェアであるだけでなく、他のミドルウェアによっても使用され、Sun が提供する他のサーバーやアプリケーションでも使用されます。このため、Message Queue は、Solaris や Java Enterprise System で配布されると同時に、Sun Java System Application Server にも同梱されています。
Application Server に同梱されている Message Queue は、J2EE プラットフォームが JMS プロバイダに提供する JMS 要件を満たしています。この場合の Message Queue は、Application Server でホストされるアプリケーションによって直接使用されます。詳細は、第 6 章「Message Queue と J2EE」を参照してください。
