第 1 章概要

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

Sun Java System Message Queue とは

Message Queue 製品は、分散アプリケーションに対応した信頼性の高い非同期メッセージングを実現する標準的なソリューションです。Message Queue は、JMS (Java^TM Message Service) オープンスタンダードを実装するエンタープライズメッセージングシステムで、実際に、JMS 参照実装として利用されています。ただし、Message Queue は、企業向けの強力な機能をフルに備えた JMS プロバイダでもあります。

JMS 仕様では、一連のメッセージングのセマンティクスと動作、アプリケーションプログラミングインタフェース (API) が規定されています。この仕様には、Java 言語アプリケーションが分散環境でメッセージを作成、送信、受信、および読み込みを行う一般的な方法が用意されています (「JMS プログラミングモデル」を参照)。Message Queue は、Java メッセージングアプリケーションをサポートする以外にも、Message Queue サービスへの C 言語インタフェース (Message Queue C-API) を提供しています。

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

Message Queue には、JMS 仕様で要求されている以上の機能があります。たとえば、次のような機能が含まれています。

集中管理 Message Queue サービスや、送信先、トランザクション、永続サブスクリプション、セキュリティなどのアプリケーションによって異なるエンティティを管理するために、コマンド行と GUI ツールの両方を提供します。Message Queue は、Message Queue サービスのリモートでの監視もサポートしています。

スケーラブルなメッセージサービス増加するコンポーネントやアプリケーションといったクライアントにサービスを提供するため、マルチブローカクラスタでは並行して動作することで、複数の Message Queue メッセージサーバコンポーネント (ブローカ) 間でのロードバランスを最適化します。

クライアントコネクションフェイルオーバー Message Queue メッセージサーバへのクライアントコネクションに障害が生じた場合に、コネクションを自動的に復元します。

調整可能なパフォーマンス信頼性がそれほど重要ではない配信を行う場合に、Message Queue サービスのパフォーマンスを向上させることができます。

複数のトランスポート TCP や HTTP など、複数の異なるトランスポートを介し、安全な (SSL) コネクションを使用して、Message Queue クライアントが Message Queue メッセージサーバと通信する機能をサポートします。

JNDI のサポートオブジェクトストアおよびユーザーリポジトリとしてファイルベースと Java Naming and Directory Interface (JNDI) による LDAP 実装の両方をサポートします。

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

製品エディション

Sun Java System Message Queue 製品には、Platform および Enterprise の 2 つのエディションが用意されています。各エディションは、後続の節で説明するように、それぞれ機能とライセンス数が異なります。Message Queue のエディションのアップグレード方法については、『Message Queue インストールガイド』を参照してください。

Platform Edition

このエディションは、Sun の Web サイトから無料でダウンロードできます。また、Sun Java System Application Server プラットフォームにもバンドルされています。Platform Edition では、Message Queue メッセージサーバでサポートされるクライアントコネクションの数に制限はありません。Platform Edition には、次の 2 つのライセンスが付属しています。

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

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



注	90 日間のトライアルライセンスは、「Enterprise Edition のトライアルライセンスでブローカインスタンスを起動するには」の説明にしたがい、Message Queue メッセージサーバ (Message Queue ブローカインスタンス) を起動することで有効にできます。

Enterprise Edition

このエディションは、運用環境でメッセージングアプリケーションを配備および実行するために使用されます。このエディションには、マルチブローカメッセージサービス、HTTP/HTTPS コネクション、安全なコネクションサービス、スケーラブルなコネクション機能、クライアントコネクションフェイルオーバー、複数コンシューマへのキュー配信、リモートメッセージベースでの監視、C-API サポートが含まれています。また Enterprise Edition は、メッセージングアプリケーションやコンポーネントの開発、デバッグ、および負荷テストにも使用できます。Enterprise Edition のライセンスには有効期限はありません。また、マルチブローカのメッセージサービスにおけるブローカ数には制限がありませんが、これは使用される CPU の数によって決まります。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

メッセージ

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

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

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

メッセージ配信モデル

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

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

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

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

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

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

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

JMS 仕様

JMS 仕様では、プログラミングモデル、メッセージ構造、API をはじめ、メッセージングを制御する一連のルールとセマンティクスが規定されています。Message Queueは JMS を実装するため、JMS の概念は、Message Queue メッセージングシステムの動作を理解する基本となります。ここでは、マニュアルを理解するのに必要な概念や用語を説明します。

JMS メッセージ構造

JMS メッセージは、ヘッダー、プロパティ、本体の 3 つの部分から構成されています。

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

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

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

JMS プログラミングモデル

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

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

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

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

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

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

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

JMS 管理対象オブジェクト

JMS 仕様では、プロバイダ固有の設定情報をカプセル化する管理対象オブジェクトを規定することで、プロバイダからのクライアントの独立性を高めています。

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

通常、これらプロバイダ固有の特性により、JMS クライアントコードは特定の JMS 実装に依存します。ただし、JMS 仕様では、プロバイダ固有の実装をして、設定情報をコネクションファクトリと送信先オブジェクトにカプセル化する必要があります。その後、プロバイダに依存しない標準的な方法で、これらのオブジェクトにアクセスできます。

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

コネクションファクトリと送信先の 2 つのタイプの管理対象オブジェクトはどちらもプロバイダ固有の情報をカプセル化しますが、クライアント内での用途は大きく異なっています。コネクションファクトリは、メッセージサーバへのコネクションを確立するのに使用されますが、送信先オブジェクトは、物理的送信先を識別するのに使用されます。

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

「JMS プログラミングモデル」で説明した一般的な JMS クライアントプログラミングモデルのほかに、さらに JMS に特化したプログラミングモデルがあり、Java 2 Platform, 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 コンポーネント、および Web コンポーネントにより、メッセージをプロデュースできます。

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

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

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

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

Sun Java System アプリケーションサーバでは、Sun Java System Message Queue によって JMS メッセージングのリソースが提供されます。

Sun Java System アプリケーションサーバ 7.0 の場合、Message Queue メッセージングシステムはネイティブな JMS プロバイダとしてアプリケーションサーバに統合されます。

Sun J2EE 1.4 アプリケーションサーバの場合、Message Queue は埋め込みの JMS リソースアダプタとしてアプリケーションサーバにプラグインされます (付録 F 「Message Queue リソースアダプタ」を参照)。

アプリケーションサーバの将来リリースでは、Message Queue はりソースアダプタの標準的な配備方法と設定方法を使用してアプリケーションサーバにプラグインされる予定です。

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

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

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

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

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

また、Message Queue 管理対象オブジェクトは、JNDI ディレクトリサービスで検索されず、クライアントによってインスタンス化されます。この欠点は、アプリケーション開発者がプロバイダ固有の API を使用しなければならない点です。また、Message Queue 管理者が Message Queue メッセージサーバを容易に制御し管理するための機能も損なわれてしまいます。

プログラミングドメイン

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

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

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

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

表 1-1 JMS プログラミングオブジェクト
基本タイプ (統一ドメイン)	ポイントツーポイントドメイン	パブリッシュ / サブスクライブドメイン
Destination (Queue または Topic)1	Queue	Topic
ConnectionFactory	QueueConnectionFactory	TopicConnectionFactory
Connection	QueueConnection	TopicConnection
Session	QueueSession	TopicSession
MessageProducer	QueueSender	TopicPublisher
MessageConsumer	QueueReceiver	TopicSubscriber

1プログラミングの手法によっては、特定の送信先タイプを指定する場合がある

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

クライアント識別子

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

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

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

この Message Queue の機能の使用に関する詳細は、『Message Queue Java Client Developer's Guide』にあるコネクションファクトリの属性についての記述を参照してください。

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

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

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

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

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

通知/トランザクション

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

通知

信頼性の高い配信を確実にするため、通知を使用するようにセッションを構成できます。

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

ローカルトランザクション

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

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

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

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

分散トランザクション

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

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

ローカルトランザクションに関しては、無視したり、操作を試行し直したり、分散トランザクション全体をロールバックしたりして、クライアントは例外を処理できます。

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

持続ストレージ

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

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

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

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

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

メッセージの選択

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

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

一般には、単一のセッションにより送信先に設定されたすべてのメッセージは、送信された順にコンシューマへ配信されるようになっています。ただし、別々のプロパティが割り当てられている場合、メッセージングサービスは、優先度が高いほうのメッセージを先に配信しようとします。

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

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

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

前へ目次索引次へ
Sun Java System Message Queue 3.5 SP1 管理ガイド

第 1 章 概要