第 1 章   概要


この章では、管理者およびプログラマを対象に、Sun ONE Message Queue (MQ) の概要を説明します。

Sun ONE Message Queue とは

---

MQ 製品には、アプリケーション間の通信や信頼できるメッセージ配信における問題の標準的なソリューションが用意されています。MQ は、企業向けメッセージングシステムで、Java Message Service (JMS) のオープンスタンダード JMS プロバイダを実装します。

JMS 仕様では、プログラミングインタフェースのセット (「JMS プログラミングモデル」を参照) を説明します。このインタフェースには、Java アプリケーションが分散環境でメッセージを作成、送信、受信、および読み込みを行う一般的な方法が用意されています。

Sun ONE Message Queue ソフトウェアを使用すると、異なるプラットフォームやオペレーティングシステムで実行されているプロセスが、共通の MQ メッセージサービス (「メッセージサービスのアーキテクチャ」を参照) に接続して、情報を送受信することが可能になります。アプリケーションの開発者は、ネットワーク上のアプリケーションの通信方法に関する低レベルな詳細ではなく、アプリケーションのビジネスロジックに集中できます。

MQ には、JMS 仕様の必要条件を上回る機能が用意されています。たとえば、次のような機能が含まれています。

集中管理   MQ メッセージサービスと、送信先やセキュリティなど、メッセージングアプリケーション固有の機能を管理するために、コマンド行と GUI ツールの両方が用意されています。

スケーラブルなメッセージサービス   連携して動作する複数の MQ メッセージサービスコンポーネントであるブローカ間 (マルチブローカクラスタ) でロードバランスを実行し、JMS クライアント (コンポーネントまたはアプリケーション) の増加を可能にします。

調整可能なパフォーマンス   信頼性の低い配信を受信する場合、MQ メッセージサービスのパフォーマンスを向上させます。

マルチトランスポート   JMS クライアントが、TCP や HTTP など、複数の異なるトランスポートを介し、安全な (SSL) コネクションを使用して互いに通信する機能をサポートします。

JNDI のサポート   ファイルベースおよび LDAP ディレクトリの両方のサービスを、オブジェクトストアおよびユーザリポジトリとしてサポートします。

SOAP メッセージングのサポート   JMS メッセージング経由で、SOAP (シンプルオブジェクトアクセスプロトコル) 仕様に準拠したメッセージである SOAP メッセージの作成と配信をサポートします。SOAP により、ピア間の構造化 XML データを分散環境で交換できます。詳細は、『MQ 開発者ガイド』を参照してください。

JMS 準拠に関連した問題については、『MQ3.0 リリースノート』を参照してください。

製品エディション

---

Sun ONE Message Queue 製品には、Platform および Enterprise の 2 つのエディションが用意されています。各エディションは、後続の節で説明するように、別々のライセンス機能に対応しています。MQ をいずれか一方のエディションから別のエディションにアップグレードするには、『MQ インストールガイド』を参照してください。

Platform Edition   このエディションは、Sun の Web サイトから無料でダウンロードできます。また、最新の Sun ONE Application Server プラットフォームにもバンドルされています。Platform Edition には、次のように 2 つのライセンスが付属しています。

• 基本ライセンス。このライセンスには、基本的な JMS サポート (完全な JMS プロバイダ) が用意されていますが、ロードバランス (マルチブローカのメッセージサービス)、HTTP/HTTPS コネクション、安全なコネクションサービス、スケーラブルなコネクション機能、複数キューの配信ポリシーなど、企業向けの機能は含まれていません。このライセンスには期限が設定されていないため、要求の少ない運用環境で使用できます。

• 90 日間の企業向けトライアルライセンス。このライセンスには、マルチブローカのメッセージサービス、HTTP/HTTPS コネクション、安全なコネクションサービス、スケーラブルなコネクション機能、複数キューの配信ポリシーに対するサポートなど、基本ライセンスには含まれていない企業向けの機能がすべて含まれています。ただし、ソフトウェアのライセンスの有効期間は 90 日間です。そのため、Enterprise Edition の製品 (「「Enterprise Edition」」を参照) で利用できる企業向けの機能を評価するのに最適です。

Platform Edition では、各 MQ メッセージサービスでサポートされる JMS クライアントのコネクション数に制限はありません。基本ライセンスから企業向けライセンスへの切り替えについては、『MQ 管理者ガイド』の license コマンド行オプションの説明を参照してください。

Enterprise Edition   このエディションは、運用環境でメッセージングアプリケーションを配置および実行するために使用されます。また Enterprise Edition は、メッセージングアプリケーションやコンポーネントの開発、デバッグ、および負荷テストにも使用できます。Enterprise Edition のライセンスには有効期限がなく、マルチブローカのメッセージサービスにおけるブローカ数や、各ブローカにサポートされるクライアントコネクション数にも制限がありません。ただし、Enterprise Edition がサポートする CPU の数はライセンスで指定されています。

エンタープライズメッセージングシステム

---

エンタープライズメッセージングシステムを使用すると、独立した分散コンポーネントやアプリケーション間でメッセージを介して対話できるようになります。これらのコンポーネントは、同一システム、つまり同一ネットワーク上にあっても、インターネットを介して緩やかに接続されていても、メッセージングを使用してデータを渡し、それぞれの機能を調整します。

エンタープライズメッセージングシステムの要件

エンタープライズアプリケーションシステムは通常、24 時間連続した基幹システムで必要な操作で、大量のメッセージを交換する多数の分散コンポーネントで構成されています。これらのシステムをサポートするために、エンタープライズメッセージングシステムは、次の要件を満たす必要があります。

信頼性のある配信   あるコンポーネントから別のコンポーネントに送信されるメッセージが、ネットワークやシステムの障害で失われないようにする必要があります。つまり、システムで、メッセージが確実に配信されることを保証する必要があります。

非同期の配信   複数のコンポーネントでメッセージを同時に交換したり、高密度スループットのサポートを可能にするために、メッセージを即座に受信するコンシューマの準備状態に関係なくメッセージを送信する必要があります。コンシューマが使用中またはオフラインの場合、コンシューマの準備が完了すると、システムはメッセージの送受信を可能にする必要があります。これは非同期メッセージ配信、また一般には蓄積転送メッセージングとして知られています。

セキュリティ   メッセージングシステムは、ユーザの認証、メッセージやリソースへの承認されたアクセス、ネットワーク経由の暗号化といった基本的なセキュリティ機能をサポートする必要があります。

スケーラビリティ   メッセージングシステムは、パフォーマンスやメッセージスループットを実質的に失うことなく、ユーザやメッセージの増加という増大する負荷に対応できる必要があります。ビジネスやアプリケーションが拡大するにつれ、これは非常に重要な要件となります。

管理機能   メッセージングシステムには、メッセージの配信を監視および管理し、システムリソースを最適化するためのツールが用意されていることが必要です。これらのツールは、信頼性、セキュリティ、およびパフォーマンスの測定と維持に有用です。

集中メッセージングとピアツーピアメッセージング

図 1-1 で示すように、エンタープライズメッセージングシステムの要件を従来のピアツーピアメッセージングシステムで満たすのは困難です。

図 1-1    集中メッセージングとピアツーピアメッセージング

ピアツーピアのようなシステムでは、メッセージングコンポーネントは、ほかのそれぞれのコンポーネントとのコネクションを維持しています。これらのコネクションでは、高速で安全な、信頼性の高い配信が可能ですが、コンポーネントごとに信頼性やセキュリティをサポートするコードが必要となります。コンポーネントがシステムに追加されるに従い、コネクション数は急激に増加します。そのため、非同期メッセージ配信やスケーラビリティを実現するのは難しくなります。また、集中管理メッセージングにも問題があります。

図 1-1 に示すように、エンタープライズメッセージングに適しているのは、集中メッセージングシステムです。このアプローチ方法では、各メッセージングコンポーネントは、1 つの中央メッセージサービスへのコネクションを維持します。このメッセージサービスでは、コンポーネント間のメッセージのルーティングや配信ができ、信頼性の高い配信とセキュリティが実現されます。コンポーネントは、詳細に定義されたプログラミングインタフェースを使用してメッセージサービスと対話します。コンポーネントがシステムに追加されると、コネクション数は一定の割合で増加するため、メッセージサービスを拡張することにより、システムを容易に拡張できます。さらに、集中メッセージサービスを利用することで、システムを一元管理できます。

メッセージングシステムの概念

エンタープライズメッセージングサービスには、いくつかの基本概念があります。その概念には、メッセージ、メッセージサービスアーキテクチャ、およびメッセージ配信モデルが含まれます。

メッセージ

メッセージは、ある形式のデータ (メッセージ本体) と、送信先、生存期間、またはメッセージシステムによって決定されたほかの特性など、メッセージの特性やプロパティを示すメタデータ (メッセージヘッダー) で構成されています。

メッセージサービスのアーキテクチャ

図 1-2 に、メッセージングシステムの基本アーキテクチャを示します。この基本アーキテクチャは、共通メッセージサービス経由でメッセージを交換する、メッセージプロデューサとメッセージコンシューマで構成されています。メッセージプロデューサとメッセージコンシューマは、同一メッセージングコンポーネント (またはアプリケーション) 内に複数存在できます。メッセージプロデューサは、メッセージサービスにメッセージを送信します。次に、メッセージサービスはメッセージルーティングと配信コンポーネントを利用して、メッセージに必要事項を登録した 1 つまたはそれ以上のメッセージコンシューマにメッセージを配信します。メッセージルーティングと配信コンポーネントは、すべての適切なコンシューマへのメッセージの配信を保証する役割を担います。

図 1-2    メッセージサービスのアーキテクチャ

メッセージ配信モデル

プロデューサとコンシューマの関係には、いろいろな種類があります。1 対 1、1 対多、および多対多の関係です。たとえば、メッセージの配信は次のように行われます。

• 1 つのプロデューサから 1 つのコンシューマへ

• 1 つのプロデューサから多数のコンシューマへ

• 多数のプロデューサから 1 つのコンシューマへ

• 多数のプロデューサから多数のコンシューマへ

これらの関係は、多くの場合、ポイントツーポイントのメッセージングとパブリッシュ / サブスクライブのメッセージングという 2 つのメッセージ配信モデルにまとめることができます。ポイントツーポイント配信モデルは、特定のプロデューサが発信元となり、特定のコンシューマが受信するメッセージに焦点を当てています。パブリッシュ / サブスクライブ配信モデルは、不特定多数のプロデューサが発信元となり、不特定多数のコンシューマが受信するメッセージに焦点を当てています。この 2 つの配信モデルは、重複する場合もあります。

今まで、メッセージングシステムでは、これら 2 つのメッセージ配信モデルのさまざまな組み合わせをサポートしていました。JMS (Java Message Service) の API は、Java メッセージングの共通プログラミングアプローチの作成を目的としていました。JMS では、ポイントツーポイント、およびパブリッシュ / サブスクライブの両方のメッセージ配信モデルをサポートしています (「プログラミングドメイン」を参照)。

JMS 仕様

---

JMS では、メッセージ構造、プログラミングモデル、およびメッセージングの動作を決定するルールやセマンティックのセットを指定します。MQ は JMS を実装するため、JMS の概念は、MQ メッセージングシステムの動作を理解する基本となります。ここでは、マニュアルを理解するのに必要な概念や用語を説明します。

JMS メッセージ構造

JMS 仕様に従い、メッセージはヘッダー、プロパティ、および本体で構成されています。

ヘッダー   ヘッダーでは、メッセージの送信先、持続的かどうか、生存期間、および優先度といったメッセージの JMS 特性が指定されます。これらの特性によって、メッセージングシステムがどのようにメッセージを配信するかが決定されます。

プロパティ   ヘッダーの拡張部分とも考えられるプロパティは省略可能です。プロパティでは、アプリケーションがさまざまな選択条件に基づいて、メッセージをフィルタするのに使用する値が提供されます。プロパティは省略可能です。

メッセージ本体   メッセージ本体には、交換される実際のデータが含まれます。JMS では、6 種類のメッセージ本体がサポートされています。

JMS プログラミングモデル

JMS プログラミングモデルでは、JMS クライアント (コンポーネントまたはアプリケーション) が JMS メッセージサービス経由でメッセージを交換します。メッセージプロデューサはメッセージをメッセージサービスに送信し、メッセージコンシューマはこのメッセージサービスからメッセージを受信します。これらのメッセージングは、JMS アプリケーションプログラミングインタフェース (API) を実装するオブジェクトセット (JMS により提供) を使用して動作します。

ここでは、JMS API を実装し、メッセージ配信のための JMS クライアントの設定に使用されるオブジェクトを紹介します (詳細は、『MQ 開発者ガイド』を参照)。図 1-3 は、メッセージ配信のプログラム作成に使用される JMS オブジェクトを示します。

図 1-3    JMS プログラミングオブジェクト

[D]

JMS プログラミングモデルでは、JMS クライアントが ConnectionFactory オブジェクトを使用して、メッセージを JMS メッセージサービスから受信したり、JMS メッセージサービスへ送信したりするときに使用するコネクションを確立します。Connection とは、メッセージサービスに対する JMS クライアントのアクティブなコネクションです。通信リソースの割り当てとクライアントの認証は、コネクションが確立されたときに行われます。このオブジェクトは比較的重いため、多くのクライアントはメッセージングを 1 つのコネクションだけで行います。

コネクションはセッションの確立に使用されます。Session は、メッセージのプロデュースとコンシュームのためのシングルスレッドコンテキストです。このコンテキストは、メッセージの送受信を行うメッセージプロデューサとメッセージコンシューマの作成に使用され、配信するメッセージの順番を定義します。セッションでは、複数の通知オプションまたはトランザクション (分散トランザクションマネージャで管理されている) を通して、信頼性の高い配信をサポートしています。

JMS クライアントは MessageProducer を使用して、送信先オブジェクトとして API で表される特定の物理的送信先にメッセージを送信します。メッセージプロデューサは、デフォルトの配信モード (持続メッセージと持続的でないメッセージ)、優先度、およびプロデューサが物理的送信先に送信する全メッセージを決定する生存期間を指定します。

同様に、JMS クライアントは MessageProducer を使用して、送信先オブジェクトとして API で表される特定の物理的送信先からメッセージを受信します。メッセージコンシューマは、メッセージセレクタを使用できます。このメッセージセレクタを使用すると、メッセージサービスで選択条件に一致するメッセージコンシューマにだけメッセージを送信できます。

メッセージコンシューマは、同期または非同期のどちらかのメッセージのコンシュームをサポートしています (『MQ 開発者ガイド』を参照)。コンシューマを使用して MessageListener を登録すると、非同期のコンシュームが実行されます。セッションスレッドが MessageListener オブジェクトの onMessage() メソッドを呼び出すと、クライアントはメッセージをコンシュームします。

管理対象オブジェクト

「JMS プログラミングモデル」で説明している 2 つのオブジェクトは、JMS プロバイダがどのように JMS メッセージサービスを実装するかに依存します。コネクションファクトリオブジェクトは、基礎となっているプロトコルや、プロバイダがメッセージの送信に使用するメカニズムに依存し、送信先オブジェクトは、特定の命名規則や、プロバイダが使用する物理的送信先に依存します。

通常、これらプロバイダ固有の特性により、JMS クライアントコードは特定の JMS 実装に依存します。ただし、JMS クライアントコードがプロバイダに依存しないようにするには、JMS 仕様ではプロバイダ固有の実装と設定情報が管理対象オブジェクトと呼ばれるものにカプセル化される必要があります。これらのオブジェクトには、プロバイダ固有ではない、標準的な方法でアクセスできます。

管理対象オブジェクトは管理者によって作成、設定されてネーミングサービスに格納されます。JMS クライアントは標準的な Java Naming and Directory Service (JNDI) 検索コードを介して格納された管理対象オブジェクトにアクセスします。この方法で管理対象オブジェクトを使用すると、JMS クライアントコードがプロバイダに依存しなくなります。

JMS には、コネクションファクトリと送信先の 2 種類の一般的な管理対象オブジェクトがあります。どちらもプロバイダ固有情報をカプセル化しますが、JMS クライアント内では、それぞれまったく違った方法で使用されます。コネクションファクトリは、メッセージサーバへのコネクションを確立するのに使用されますが、送信先オブジェクトは、JMS メッセージサービスに使用される物理的送信先を識別するのに使用されます。

管理対象オブジェクトの詳細については、「MQ 管理対象オブジェクト」を参照してください。

JMS/J2EE プログラミング : メッセージ駆動型 Beans

---

「JMS プログラミングモデル」で説明した一般的な JMS クライアントプログラミングモデルのほかに、JMS に特化したプログラミングモデルがあり、Java 2 Enterprise Edition (J2EE) アプリケーションのコンテキストで使用されます。この特殊な JMS クライアントは、メッセージ駆動型 Beans と呼ばれ、EJB 2.0 仕様書 (http://java.sun.com/products/ejb/docs.html) で指定されている Enterprise JavaBeans (EJB) コンポーネントのファミリーの 1 つです。

ほかの EJB コンポーネント (セッション Beans とエンティティ Beans) はメッセージ駆動型 Beans と同時に呼び出す必要があります。これらの EJB コンポーネントは、標準的な EJB インタフェースを介してしかアクセスできないため、非同期メッセージ受信のメカニズムは備わっていません。

ただし、非同期メッセージングは多くのエンタープライズアプリケーションの要件となっています。これらのアプリケーションの多くは、サーバサイドコンポーネントがサーバリソースと結びつかずに、お互いに通信や応答できることが要件となっています。このため、メッセージのプロデューサにしっかり対応していなくてもメッセージを受信し、コンシュームできる EJB コンポーネントが必要となります。この機能は、サーバサイドコンポーネントがアプリケーションイベントに応答する必要のある、すべてのアプリケーションで必要となります。エンタープライズアプリケーションでは、負荷が増加する場合、この機能を拡張する必要があります。

メッセージ駆動型 Beans

メッセージ駆動型 Beans (MDB) は、特殊な EJB コンテナ (サポートするコンポーネントに分散サービスを提供するソフトウェア環境) がサポートする特殊な EJB コンポーネントです。

メッセージ駆動型 Beans   MDB とは、JMS MessageListener インタフェースを実装する JMS メッセージコンシューマです。MDB 開発者により書き込まれた onMessage メソッドは、MDB コンテナがメッセージを受信したときに呼び出されます。onMessage() メソッドは、標準的な MessageListener オブジェクトの onMessage() メソッドがコンシュームするのと同じように、メッセージをコンシュームします。ほかの EJB コンポーネントの場合とは異なり、MDB はメソッドをリモートで呼び出さないため、これと関連付けられているホームまたはリモートのインタフェースはありません。MDB は単一の送信先からのメッセージをコンシュームできます。図 1-4 にあるように、スタンドアロン JMS アプリケーション、JMS コンポーネント、または EJB コンポーネントでメッセージをプロデュースできます。

図 1-4    MDB を使用したメッセージング

MDB コンテナ   MDB コンテナは、MDB のインスタンスを作成し、メッセージの非同期のコンシュームのためにそのインスタンスを設定する役割を担います。これには、メッセージサービスを使用したコネクションの設定 (認証を含む)、特定の送信先に関するセッションのプールの作成、セッションのプールや関連する MDB インスタンスでメッセージが受信されるときのメッセージ分散の管理が含まれます。コンテナは MDB インスタンスのライフサイクルを制御するので、受信メッセージの読み込みに対応できるように MDB インスタンスのプールを管理します。

コネクションファクトリと送信先のメッセージコンシュームを設定するときに、コンテナに使用される管理対象オブジェクトの JNDI 検索名を指定する配置記述子は、MDB に関連付けられています。また、配置記述子には、MDB コンテナを設定するために配置ツールで使用されるほかの情報も含まれます。各 MDB コンテナは、1 つの MDB のインスタンスだけをサポートします。

アプリケーションサーバのサポート

J2EE アーキテクチャ (http://java.sun.com/j2ee/download.html#platformspec にある「J2EE Platform Specification」を参照) では、EJB コンテナ (MDB コンテナを含む) がアプリケーションサーバにホストされます。アプリケーションサーバには、トランザクションマネージャ、持続マネージャ、ネーミングサービス、JMS プロバイダ (メッセージングの場合) などのさまざまなコンテナで必要とされるリソースが用意されています。

Sun ONE Application Server の場合、メッセージングリソースは Sun ONE Message Queue に用意されています。つまり、MQ メッセージングシステム (第 2 章「MQ メッセージングシステム」を参照) は Sun ONE Application Server に統合され、アプリケーションサーバ環境で実行している MDB やほかの JMS メッセージングコンポーネントへ JMS メッセージを送信するのに必要なサポートを提供しています。

JMS メッセージングの問題点

---

この節では、MQ メッセージサービスの管理に影響を与える、JMS プログラミングの多くの問題点を説明します。その中で MQ 管理者に必要な概念や用語について重点的に解説しています。

JMS プロバイダへの非依存性

JMS は管理対象オブジェクト (「管理対象オブジェクト」を参照) の使用方法を指定し、ほかの JMS プロバイダに移植可能なクライアントアプリケーションの開発をサポートします。管理対象オブジェクトにより、JMS クライアントはプロバイダ固有オブジェクトを検索および参照するための論理名を使用できます。この方法では、クライアントコードは特定の命名構文やアドレス指定構文、またはプロバイダによって使用される設定可能なプロパティを知る必要はありません。これにより、コードはプロバイダに依存しなくなります。

管理対象オブジェクトは、MQ 管理者により作成および設定される MQ システムオブジェクトです。これらのオブジェクトは、JNDI ディレクトリサービスに配置され、JMS クライアントは JNDI 検索を使用してアクセスします。

また、MQ 管理対象オブジェクトは、JNDI ディレクトリサービスで検索されず、クライアントによってインスタンス化されます。この管理対象オブジェクトには、アプリケーション開発者がプロバイダ固有の API を使用する必要があるという欠点があります。また、MQ 管理者が MQ メッセージサーバを制御、管理できないこともあります。

管理対象オブジェクトの詳細については、「MQ 管理対象オブジェクト」を参照してください。

プログラミングドメイン

JMS では、ポイントツーポイント、およびパブリッシュ / サブスクライブの 2 つのメッセージ配信モデルをサポートしています。

ポイントツーポイント (キュー送信先)   メッセージは、1 つのプロデューサから 1 つのコンシューマに配信されます。この配信モデルの場合、送信先はキューです。まず、メッセージはキュー送信先に配信されます。次にキューの配信ポリシー (「キューの送信先」を参照) に従って 1 回に 1 つずつ、キューに登録されたコンシューマの 1 つへ配信されます。複数のプロデューサがメッセージをキュー送信先に配信しても、メッセージは 1 つだけのコンシューマに配信されて、正常にコンシュームされます。キュー送信先にコンシューマが 1 つも登録されていない場合、キューは受信したメッセージを保持し、コンシューマがキューに登録されるとすぐに、そのメッセージを配信します。

パブリッシュ / サブスクライブ (トピック送信先)   メッセージは、1 つのプロデューサから複数のコンシューマに配信されます。この配信モデルの場合、送信先はトピックです。まず、メッセージはトピック送信先に配信されます。次にトピックに加入されているすべてのアクティブなコンシューマに配信されます。トピック送信先へのメッセージの送信は、複数のプロデューサで実行でき、メッセージごとに加入済みの複数のコンシューマに配信されます。また、トピック送信先は、永続サブスクリプションの概念もサポートしています。永続サブスクリプションは、トピック送信先とともに登録されたコンシューマを表していますが、メッセージ配信時にアクティブでないことがあります。その後、コンシューマがアクティブになると、メッセージを受信します。トピック送信先に登録されたコンシューマがない場合、アクティブでないコンシューマの永続サブスクリプションがない限り、トピックは受信したメッセージを保持しません。

これら 2 つのメッセージ配信モデルは、わずかに異なるセマンティックを持った別々の API オブジェクトを使用して処理され、表 1-1 にあるように異なるプログラミングドメインを表しています。

表 1-1    JMS プログラミングオブジェクト 

基本タイプ(統一ドメイン)	ポイントツーポイントドメイン	パブリッシュ / サブスクライブドメイン
Destination (Queue または Topic)*	Queue	Topic
ConnectionFactory	QueueConnectionFactory	TopicConnectionFactory
Connection	QueueConnection	TopicConnection
Session	QueueSession	TopicSession
MessageProducer	QueueSender	TopicPublisher
MessageConsumer	QueueReceiver	TopicSubscriber
*プログラミングのアプローチによっては、特定の送信先タイプを指定する場合がある

表 1-1 の 1 列目にある統一ドメインオブジェクトを使用して、ポイントツーポイントとパブリッシュ / サブスクライブのどちらのメッセージングもプログラミングできます。このアプローチをお勧めします。ただし、JMS 1.02b 仕様に準拠するには、ポイントツーポイントのメッセージングにポイントツーポイントドメインのオブジェクトを、パブリッシュ / サブスクライブのメッセージングにパブリッシュ / サブスクライブドメインのオブジェクトを使用します。

クライアント識別子

JMS プロバイダは、クライアント識別子の概念をサポートする必要があります。それによりクライアントの代わりにメッセージサービスが保持しているステート情報を使用して、JMS クライアントのコネクションはメッセージサービスに関連付けられます。クライアント識別子は固有のもので、一度に 1 人のユーザだけに適用されます。クライアント識別子は永続サブスクリプション名 (「パブリッシュ / サブスクライブ (トピック送信先)」を参照) と組み合わせて使用され、各永続サブスクリプションが 1 人のユーザだけに対応するようにします。

JMS 仕様では、クライアント識別子は、API メソッドの呼び出しを介してクライアントで設定できますが、コネクションファクトリ管理対象オブジェクト (「管理対象オブジェクト」を参照) を使用して管理者が設定することをお勧めします。ただし、コネクションファクトリに物理的に組み込まれている場合、各ユーザは個々のコネクションファクトリに固有の ID を持たせる必要があります。

MQ には、ConnectionFactory オブジェクトで設定できる特殊な変数置換構文を使用してクライアント識別子を ConnectionFactory とユーザ固有のものの両方にできる方法が用意されています。この方法を使用すると、命名の重複やセキュリティの問題を気にせずに、永続サブスクリプションを作成する複数のユーザが、単一の ConnectionFactory オブジェクトを使用できます。したがって、ユーザの永続サブスクリプションは、誤って消去されることも、別のユーザが間違ったクライアント識別子を設定したために使用できなくなることもありません。

この MQ の機能の使用に関する詳細は、『MQ 開発者ガイド』にあるコネクションファクトリの属性についての記述を参照してください。

どんな場合でも、永続サブスクリプションを作成するには、クライアントが JMS API を使用してプログラム的にクライアント識別子を設定するか、クライアントが使用する ConnectionFactory オブジェクト内で管理者がクライアント識別子を設定する必要があります。

信頼性のあるメッセージング

JMS は、次の 2 つの配信モードを定義します。

持続メッセージ   持続メッセージは、必ず 1 回 (1 回のみ) 配信され確実にコンシュームされることが保証されています。持続メッセージにとって、信頼性は大変重要です。

持続的でないメッセージ   持続的でないメッセージは、1 回の配信だけが保証されています。持続的でないメッセージにとって、信頼性はそれほど重要な問題ではありません。

持続メッセージの場合、信頼性の保証には 2 つの側面があります。1 つは、メッセージサービスへの配信とメッセージサービスからの配信が問題なく行われるようにすることです。もう 1 つは、コンシューマに配信される前にメッセージサービスが持続メッセージを失わないようにすることです。

通知およびトランザクション

信頼性のあるメッセージングでは、持続メッセージの送信先からの配信や送信先への配信が確実に行われることが重要です。MQ セッションは 2 つの一般的なメカニズム (通知およびトランザクション) をサポートしています。このどちらかを使用すると、信頼性のあるメッセージングを実現できます。トランザクションを使用する場合、分散トランザクションマネージャに制御されている状態では、ローカルまたは分散のどちらかになります。

通知
信頼性の高い配信を実現するために、セッションを設定して通知を使用するようにします。

プロデューサの場合、プロデューサの send() メソッドが返される前に、メッセージサービスが送信先に持続メッセージの配信を通知します。コンシューマの場合は、メッセージサービスが送信先からメッセージを削除する前に、クライアントが送信先からの持続メッセージの配信とコンシュームを通知します。

ローカルトランザクション
セッションを処理済として設定することもできます。その場合、1 つ以上のメッセージのプロデュースおよびコンシュームが、トランザクションという極小の単位にグループ化されます。JMS API には、トランザクションの起動、コミット、およびロールバックするメソッドが用意されています。

メッセージがトランザクション内でプロデュースまたはコンシュームされると、ブローカはさまざまな送受信を追跡し、クライアントが呼び出しを実行してトランザクションをコミットしたときにだけ、追跡を完了させます。トランザクション内で特定の送信や受信が失敗すると、例外が発生します。クライアントコードは、例外の無視、操作の再試行、あるいはトランザクション全体のロールバックを実行して、例外を処理します。トランザクションがコミットされると、すべての操作が正常に完了したことになります。トランザクションがロールバックされると、正常に行われたすべての操作が取り消されます。

ローカルトランザクションの範囲は、常に単一セッションです。つまり、単一セッションのコンテキストで実行される、1 つ以上のプロデューサまたはコンシューマの操作は、単一のローカルトランザクションにグループ化されます。

トランザクションは単一セッションだけに及ぶため、メッセージのプロデュースとコンシュームの両方を含むエンド・ツー・エンドのトランザクションを持つことはできません。言い換えると、送信先へのメッセージの配信と、それに続くクライアントへのメッセージの配信は、単一トランザクションに置くことはできません。

分散トランザクション
MQ は、分散トランザクションもサポートしています。つまり、メッセージのプロデュースとコンシュームは、データベースシステムなど、ほかのリソースマネージャに関連した操作を含む大容量の分散トランザクションの一部です。分散トランザクションでは、Java Transaction API (JTA)、XA Resource API 仕様で定義された 2 階層コミットプロトコルを使用して、メッセージサービスやデータベースマネージャといった複数のリソースマネージャが実行する操作を、分散トランザクションマネージャが追跡および管理します。Java の世界では、リソースマネージャと分散トランザクションマネージャ間の対話は、JTA 仕様で記述されます。

分散トランザクションをサポートするということは、JTA で定義される XAResource インタフェースを介して、メッセージングクライアントが、分散トランザクションに参加できるということです。このインタフェースは、2 階層コミットを実装するために数多くのメソッドを定義します。API の呼び出しがクライアント側で行われている間、MQ ブローカは分散トランザクション内のさまざまな送受信操作やトランザクションの状態を追跡し、Java Transaction Service (JTS) で提供される分散トランザクションマネージャと一致したときにだけ、メッセージング操作を完了します。

ローカルトランザクションで例外を処理する場合、クライアントは例外の無視、操作の再試行、および分散トランザクション全体のロールバックを実行します。

MQ は、XA コネクションファクトリを介した分散トランザクションのサポートを実装しています。この XA コネクションファクトリでは、XA セッション (「JMS プログラミングモデル」を参照) を作成する XA コネクションを確立できます。さらに、分散トランザクションをサポートするには、サードパーティの JTS、または JTS を提供する J2EE 準拠の Application Server のいずれかが必要です。

持続ストレージ

信頼性のほかの重要な側面は、1 度持続メッセージが送信先に配信されたら、そのメッセージがコンシューマに配信されるまで、メッセージサービスがメッセージを失わないようにすることです。つまり、持続メッセージが送信先に配信されたら、メッセージサービスは持続メッセージを持続ストレージ (「持続マネージャ」を参照) に配置する必要があります。何かの理由でメッセージサービスが停止した場合、持続データストアでメッセージは復元され、適切なコンシューマに配信されます。これにより、メッセージ配信にオーバーヘッドが発生しますが、信頼性も向上します。

メッセージサービスは、永続サブスクリプションも格納する必要があります。これは、トピック送信先への配信を保証するには、持続メッセージの復元だけでは十分ではないからです。メッセージサービスでは、トピックの永続サブスクリプションに関する情報も復元する必要があります。復元しないと、メッセージ到着時にアクティブではなく、あとからアクティブになるサブスクライバにメッセージを配信できません。

保証されたメッセージ配信を行うには、メッセージングアプリケーションは、メッセージを持続的として指定し、キュー送信先、またはトピック送信先のどちらかに対する永続サブスクリプションを使用する必要があります。

パフォーマンスのかね合い

メッセージ配信の信頼性が高くなるにつれて、その信頼性を実現するために、より多くのオーバーヘッドや帯域幅が必要となります。信頼性とパフォーマンスのかね合いは、設計上考慮するべき重要な点です。持続的でないメッセージをプロデュースおよびコンシュームするように設定すると、パフォーマンスを最大に高められます。一方、持続メッセージをプロデュースおよびコンシュームして、処理済みのセッションを使用すると、信頼性を最大に高められます。この 2 つの要素には複数のオプションがあり、どちらを優先させるかは MQ 固有のコネクションや通知プロパティの使用など、アプリケーションの必要性によって異なります (『MQ 開発者ガイド』を参照)。

メッセージの選択

JMS には、メッセージセレクタに設定された条件に基づいて、メッセージサービスがフィルタやルーティングを実行できるようにするメカニズムが用意されています。プロデューシングクライアントは、アプリケーション固有のプロパティをメッセージに設定します。コンシューミングクライアントは、設定されたプロパティに基づく選択条件を使用して、メッセージの項目を示します。これにより、クライアントの作業が単純になり、不要なクライアントにメッセージを配信するオーバーヘッドがなくなります。ただし、選択条件を処理しているメッセージサービスに、一部のオーバーヘッドが追加されます。メッセージセレクタの構文とセマンティックは、JMS 仕様書で解説されています。

メッセージの順番と優先度

通常、単一のセッションで送信先に送信されたすべてのメッセージは、送信された順にコンシューマへ配信されるようになっています。ただし、異なる優先度が割り当てられている場合、メッセージングサービスは、優先度の高いメッセージを先に配信しようとします。

それ以外の場合、クライアントアプリケーションがメッセージをコンシュームする順番は、プロデュースされた順番と関係しますが、密接な関係はありません。これは、メッセージの送信先への配信と、送信先からの配信が、メッセージの送信順、メッセージの送信元となるセッション (コネクション)、メッセージが持続的かどうか、メッセージの生存期間、メッセージの優先度、キュー送信先 (「キューの送信先」を参照) のメッセージ配信ポリシー、およびメッセージサービスの可用性といった、配信のタイミングに影響を与える多くのことに依存するためです。

相互接続された複数のブローカ (「複数ブローカの設定 (クラスタ)」を参照) を使用している MQ メッセージサーバの場合、クライアントがメッセージをコンシュームする順序付けはさらに複雑になります。これは、異なるブローカの送信先からの配信順が決定されていないためです。したがって、あるブローカが配信したメッセージが、他のブローカが配信して先にメッセージングサービスに受信されたメッセージよりも優先的に配信されることもあります。

どんな場合でも、特定のコンシューマでは、優先度の低いメッセージよりも優先度の高いメッセージが優先されます。