第 1 章   概要


この章では、開発者を対象に、Sun ONE Message Queue (MQ)、JMS の概念、プログラミング関連の問題全般について概説します。

Sun ONE Message Queue とは

---

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

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

MQ には、JMS 仕様の必要条件以上の機能があります。たとえば、次のような機能が含まれています。

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

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

チューニング可能なパフォーマンス   信頼性がそれほど重要ではない配信を行う場合に、MQ メッセージサービスのパフォーマンスを向上させることができます。

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

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

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

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 の数はライセンスで指定されています。

---

注	すべての MQ エディションで、製品の一部であるクライアントランタイムは商用目的での再配布が許可されています。ただし、製品のそれ以外のファイルの再配布は一切許可されていません。ライセンスを取得したあと、再配布可能な製品の一部を使用して、MQ メッセージサーバに接続できる JMS クライアントを開発し、MQ ライセンス料を支払わずにサードパーティ向けに販売することができます。サードパーティは、MQ の自社用バージョンを購入して MQ メッセージサーバにアクセスするか、または MQ メッセージサーバをインストールし実行している別の組織にコネクションする必要があります。

---

MQ メッセージングシステムのアーキテクチャ

---

この節では、MQ メッセージングシステムの主要部分について簡単に説明します。開発者は、メッセージングシステムのあらゆる部分、またはそれらの相互作用を完全に把握しておく必要はありません。基本アーキテクチャをしっかりと把握していれば、JMS クライアントの設計および開発に影響するシステムの機能を容易に理解できます。

MQ メッセージングシステムの主要部分は次のとおりです。これらの具体的な関連性については、図 1-1 を参照してください。

MQメッセージサーバ   MQ メッセージサーバは、メッセージングシステムの中核として機能します。メッセージサーバは、システムに配信サービスを提供する 1 つまたは複数のブローカで構成されます。配信サービスには、JMS クライアントへのコネクション、メッセージの転送と配信、持続性、セキュリティ、およびロギングなどのサービスがあります。メッセージサーバは、クライアントのメッセージ送信先であり、コンシューミングクライアントへのメッセージ配信元である、物理的な送信先を管理します。MQ メッセージサーバの詳細は、『MQ 管理者ガイド』を参照してください。

MQ クライアントランタイム   MQ クライアントランタイムは、JMS クライアントに MQ メッセージサーバへのインタフェースを提供します。つまり、クライアントランタイムによって、「JMS プログラミングモデル」に記載されるすべての JMS プログラミングオブジェクトがクライアントに提供されます。クライアントランタイムでは、送信先にメッセージを送信し、送信先からメッセージを受信する場合に、クライアントに必要なすべての処理がサポートされます。MQ クライアントランタイムの詳細は、第 4 章「クライアントの最適化」を参照してください。

図 1-1    MQ システムアーキテクチャ

MQ管理対象オブジェクト   管理対象オブジェクトは、プロバイダ固有の実装および構成情報を JMS クライアントが使用するオブジェクト内にカプセル化します。通常、管理対象オブジェクトは、管理者によって構成され、ネームサービスに格納されます。クライアントは、JNDI 検索コードを使ってこうした管理対象オブジェクトにアクセスし、プロバイダに依存しない方式でこれらを使用します。クライアントが管理対象オブジェクトをインスタンス化することもできますが、その場合は、プロバイダ固有の方式で使用されます。MQ クライアントランタイムの構成は、管理対象オブジェクト属性によって行われます。詳細は、第 4 章「クライアントの最適化」を参照してください。

MQ 管理   MQ には、MQ メッセージングシステムの管理に使用する多数の管理ツールが用意されています。これらのツールを使って、メッセージサーバの管理、管理対象オブジェクトの作成および格納、セキュリティ管理、メッセージアプリケーションリソースの管理、持続データの管理が可能です。通常、これらのツールは MQ 管理者によって使用されます。詳細は、『MQ 管理者ガイド』を参照してください。

JMS プログラミングモデル

---

この節では、JMS 仕様のプログラミングモデルについて簡単に説明します。ここでは、JMS クライアントのプログラミングで使用する重要な概念および用語を確認します。

JMS プログラミングインタフェース

JMS プログラミングモデルでは、JMS クライアント (コンポーネントまたはアプリケーション) は JMS アプリケーションプログラミングインタフェース (API) を使ってメッセージの送受信を行います。この節では、JMS API を実装し、メッセージ配信のための JMS クライアントの設定に使用されるオブジェクトを紹介します (「JMS クライアントの設定方法」を参照)。主なインタフェースオブジェクトは、図 1-2 に示されています。次に、各オブジェクトについて説明します。

メッセージ

MQ 製品では、JMS 仕様に準拠した JMS メッセージを使ってデータ交換を行います。JMS の仕様に従い、メッセージはヘッダー、プロパティ、本体で構成されています。

プロパティはオプションです。クライアントがメッセージのフィルタリングに使用する値を提供します。本体もオプションです。交換する実際のデータです。

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

[D]

ヘッダー
すべてのメッセージにはヘッダーが必要です。ヘッダーフィールドには、メッセージのルーティングや識別に使用する値が含まれています。

ヘッダーフィールドの一部の値は、メッセージの作成および配信処理の間に MQ によって自動的に設定されます。一部の値は、クライアントにメッセージプロデューサを作成するときに指定する、メッセージプロデューサの設定に依存します。また、その他の値は JMS API を使用するユーザによってメッセージごとにメッセージ上に設定されます。次の表に、JMS 定義 (必須) のヘッダーフィールドとその設定方法を示します。

表 1-1    JMS 定義のメッセージヘッダー 

ヘッダーフィールド	設定者	デフォルト値
JMSDestination	クライアント、メッセージプロデューサまたはメッセージごとに設定
JMSDeliveryMode	クライアント、メッセージプロデューサまたはメッセージごとに設定	Persistent
JMSExpiration	クライアント、メッセージプロデューサまたはメッセージごとに設定	生存期間 0 (有効期限なし)
JMSPriority	クライアント、メッセージプロデューサまたはメッセージごとに設定	4 (標準)
JMSMessageID	プロバイダ、自動設定
JMSTimestamp	プロバイダ、自動設定
JMSRedelivered	プロバイダ、自動設定
JMSCorrelationID	クライアント、メッセージごとに設定
JMSReplyTo	クライアント、メッセージごとに設定
JMSType	クライアント、メッセージごとに設定

プロパティ
2 つのプロセス間でデータをやりとりするとき、ペイロードデータ以外の情報も同時に送信できます。このような記述的フィールドまたはプロパティにより、データの作成プロセス、作成時刻、データの各部分の構造を一意に識別する情報など、データに関する追加情報を提供することができます。プロパティ (ヘッダーの拡張部分とも考えられる) は、JMS クライアントが指定したプロパティ名とプロパティ値のペアで構成されます。

コンシューミングクライアントは、特定の送信先に配信対象を登録することにより、選択基準として特定のプロパティ値を指定して、選択内容を細かく調整できます。たとえば、クライアントが施設管理に関するメッセージは除いて、給与に関するメッセージ、とくに New Jersey の非常勤社員の給与明細だけを配信対象として指定することができます。指定した基準を満たしていないメッセージは、コンシューマに配信されません。

メッセージ本体のタイプ
JMS には、JMS プロバイダがサポートする必要のある 6 つのメッセージのクラス (タイプ) が指定されています。次の表でこれらのタイプについて説明します。

表 1-2    メッセージ本体のタイプ 

タイプ	説明
Message	メッセージ本体を持たないメッセージ
StreamMessage	本体に Java プリミティブ値のストリームを含むメッセージ。いっぱいになると順番に読み込まれる
MapMessage	本体に一連の名前と値のペアを含むメッセージ。エントリの順番は定義されていない
TextMessage	本体に Java 文字列 (XML メッセージなど) を含むメッセージ
ObjectMessage	本体に直列化された Java オブジェクトを含むメッセージ
BytesMessage	本体に未解釈のバイトストリームを含むメッセージ

送信先

Destination は、JMS メッセージサービスの物理的な送信先を示す JMS 管理対象オブジェクトです (「管理対象オブジェクト」を参照)。物理的な送信先は、JMS メッセージサービスエンティティの 1 つです。プロデューサはこの送信先にメッセージを送信し、コンシューマはこの送信先からメッセージを受信します。メッセージサービスは、物理的な送信先に送信されるメッセージのルーティングおよび配信の機能を提供します。Destination 管理対象オブジェクトは、物理的な送信先のプロバイダ固有の命名規則をカプセル化します。これにより、JMS クライアントがプロバイダに依存しなくなります。

コネクションファクトリ

ConnectionFactory は、プロバイダ固有のコネクション設定情報をカプセル化する JMS 管理対象オブジェクトです (「管理対象オブジェクト」を参照)。クライアントは、このオブジェクトを使って、メッセージ配信に使用するコネクションを作成します。JMS 管理対象オブジェクトは、Java Naming and Directory Service (UNDI) 検索によって取得できますが、プロバイダ固有のクラスを使って直接インスタンス化することもできます。

コネクション

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

セッション

Session は、メッセージのプロデュースとコンシュームのためのシングルスレッドコンテキストです。セッションを使用できるスレッドの数に制限はありませんが、同じセッションを複数のスレッドで同時に使用することはできません。このコンテキストは、メッセージの送受信を行うメッセージプロデューサとメッセージコンシューマの作成に使用され、配信するメッセージの順番を定義します。セッションは、多数の通知オプションまたはトランザクションを使って、信頼性の高い配信処理をサポートします。処理済みセッションは、一連の順次処理を、複数のプロデューサとコンシューマにまたがる単一のトランザクションに結合します。

メッセージプロデューサ

クライアントは、MessageProducer を使って、物理的な送信先へメッセージを送信します。通常、MessageProducer オブジェクトは、Destination 管理対象オブジェクトをメッセージプロデューサを作成するセッションのメソッドに渡すことによって作成されます。なお、特定の送信先を参照しないメッセージプロデューサを作成する場合は、作成するメッセージごとに送信先を指定する必要があります。クライアントは、メッセージプロデューサのデフォルトの配信モード、優先度、生存期間を指定して、これらの情報が明示的にオーバーライドされないかぎり、プロデューサから送信されるすべてのメッセージを制御します。

メッセージコンシューマ

クライアントは、MessageConsumer を使って、物理的な送信先からメッセージを受信します。通常、このオブジェクトは、Destination 管理対象オブジェクトをメッセージコンシューマを作成するセッションのメソッドに渡すことによって作成されます。メッセージコンシューマは、メッセージセレクタを使用できます。このメッセージセレクタを使用すると、メッセージサービスで、選択条件に一致するメッセージだけをメッセージコンシューマに送信できます。メッセージコンシューマは、同期または非同期のどちらかのメッセージのコンシュームをサポートしています (「メッセージのコンシューム : 同期と非同期」を参照)。

メッセージリスナー

JMS クライアントは、MessageListener オブジェクトを使って、非同期にメッセージをコンシュームします。メッセージリスナーはメッセージコンシューマに登録されます。セッションスレッドが MessageListener オブジェクトの onMessage() メソッドを呼び出すと、クライアントはメッセージをコンシュームします。

管理対象オブジェクト

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

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

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

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

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

JMS クライアントの設定方法

JMS プログラミングモデルには、メッセージをプロデュースまたはコンシュームする JMS クライアントの設定に関する一般的な方法があります。この方法は、前の節で説明した JMS プログラミングインタフェースオブジェクトを使用します。

メッセージのプロデュースとコンシュームに関する一般的な手順は次のとおりです。メッセージのプロデュースとコンシュームの両方を行うクライアントの場合、多くの共通手順は複製する必要がありません。

メッセージをプロデュースする JMS クライアントを設定するには

1. JNDI を使って ConnectionFactory オブジェクトを検索します。ConnectionFactory オブジェクトを直接インスタンス化し、属性値を設定することもできます。

2. ConnectionFactory オブジェクトを使って Connection オブジェクトを作成します。

3. Connection オブジェクトを使って 1 つまたは複数の Session オブジェクトを作成します。

4. JNDI を使って 1 つまたは複数の Destination オブジェクトを検索します。Destination オブジェクトを直接インスタンス化し、名前属性を設定することもできます。

5. Session オブジェクトと Destination オブジェクトを使って、必要な MessageProducer オブジェクトを作成します。MessageProducer は Destination オブジェクトを指定しなくても作成できますが、この場合はプロデュースするメッセージごとに Destination オブジェクトを指定する必要があります。

これで、クライアントがメッセージをプロデュースするために必要な基本的なセットアップが完了しました。

メッセージをコンシュームする JMS クライアントをセットアップするには

1. JNDI を使って ConnectionFactory オブジェクトを検索します。ConnectionFactory オブジェクトを直接インスタンス化し、属性値を設定することもできます。

2. ConnectionFactory オブジェクトを使って Connection オブジェクトを作成します。

3. Connection オブジェクトを使って 1 つまたは複数の Session オブジェクトを作成します。

4. JNDI を使って 1 つまたは複数の Destination オブジェクトを検索します。Destination オブジェクトを直接インスタンス化し、名前属性を設定することもできます。

5. Session オブジェクトと Destination オブジェクトを使って、必要な MessageConsumer オブジェクトを作成します。

6. 必要に応じて、MessageListener オブジェクトをインスタンス化し、MessageConsumer オブジェクトに登録します。

7. Connection オブジェクトにメッセージ配信を開始するように指示します。これで、メッセージがクライアントに配信され、コンシュームされます。

これで、クライアントがメッセージをコンシュームするために必要な基本的なセットアップが完了しました。

JMS クライアントの設計に関する問題

---

この節では、JMS クライアントの設計に影響を及ぼすさまざまな JMS メッセージングの問題について説明します。

プログラミングドメイン

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

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

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

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

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

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

JMS 1.1 仕様に準拠する統一ドメインオブジェクトを使用して、ポイントツーポイントとパブリッシュ/サブスクライブのどちらのメッセージングもプログラミングできます (表 1-3 の最初のカラムを参照)。JMS 1.1 仕様は、JMS 1.02 と比較してより簡単な JMS クライアントプログラミングの方法を提供します。特に、JMS クライアントは、同じコネクション上でまた同じセッション内でポイントツーポイントとパブリッシュ/サブスクライブのどちらのメッセージングも実行できます。また、同じトランザクションにキューとトピックの両方を含めることができます。

つまり、JMS クライアントの開発者は、より簡単な JMS 1.1 統一ドメイン手法を選択することにより、JMS 1.0.2 のポイントツーポイントとパブリッシュ/サブスクライブプログラミングドメインを個別に選択する必要がありません。この方法をお勧めしますが、JMS 1.1 仕様は個別の JMS 1.02 プログラミングドメインも引き続きサポートします。事実、MQ 製品に含まれるサンプルアプリケーションとこのガイドで提供されるサンプルコードは、すべて個別の JMS 1.02 プログラミングドメインを使用しています。

---

注	Sun ONE Application Server 環境で実行するアプリケーションの開発者は、JMS 1.0.2 API を使用するように制限されています。これは、Sun ONE Application Server が、JMS 1.0.2 だけをサポートする J2EE 1.3 仕様に準拠しているからです。これは、サーブレットと メッセージ駆動 Bean (「メッセージ駆動型 Beans」を参照) を含む EJB で実行される JMS メッセージングが、ドメイン固有の JMS API に基づく必要があることを意味します。

---

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

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

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

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

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

クライアント識別子

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

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

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

配置済みアプリケーションの場合、クライアント識別子は、 JMS API を使用してクライアントがプログラム上設定するか、またはでクライアントが使用する ConnectionFactory オブジェクト内に管理上設定する必要があります。

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

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

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

持続性メッセージ   持続性メッセージは、必ず 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 固有の持続性や通知プロパティの使用をはじめ、アプリケーションの必要性によって異なります (「パフォーマンス要因」を参照)。

メッセージのコンシューム : 同期と非同期

JMS クライアントがメッセージをコンシュームする方法には、同期または非同期のいずれか 2 つの方法があります。

同期コンシュームの場合、クライアントは、MessageConsumer オブジェクトの receive() メソッドを呼び出してメッセージを取得します。クライアントスレッドは、メソッドが復帰するまでブロックされます。これは、使用可能なメッセージが存在しない場合、メッセージが使用可能になるまでクライアントがブロックされるか、または receive() メソッドがタイムアウトするまで (タイムアウトを指定して呼び出された場合) クライアントがブロックされることを意味します。このモデルでは、メッセージは、クライアントスレッドによって 1 つずつコンシュームされます (同期方式)。

非同期コンシュームの場合、クライアントは、メッセージコンシューマに MessageListener オブジェクトを登録します。メッセージリスナーはコールバックオブジェクトのように機能します。セッションが MessageListener オブジェクトの onMessage() メソッドを呼び出すと、クライアントはメッセージをコンシュームします。このモデルでは、クライアントスレッドはブロックされず、メッセージが非同期でコンシュームされます。これは、メッセージを待機し、コンシュームするスレッドが、MQ クライアントランタイムに属しているためです。

メッセージの選択

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

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

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

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

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

---

「JMS プログラミングモデル」で説明した一般的な JMS クライアントプログラミングモデルのほかに、さらに JMS に特化したプログラミングモデルがあり、Java 2 Enterprise Edition (J2EE) アプリケーションのコンテキストで使用されます。この特殊な JMS クライアントは、メッセージ駆動型 Beans メッセージ駆動型 Beansと呼ばれ、EJB 2.0 Specification (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 コンポーネメッセージ駆動型 Beansントの場合とは異なり、メソッドを MDB でリモートに呼び出さないため、これと関連付けられているホームまたはリモートのインタフェースはありません。MDB は単一の送信先からのメッセージをコンシュームできます。図 1-3 にあるように、スタンドアロン JMS アプリケーション、JMS コンポーネント、EJB コンポーネントにより、メッセージをプロデュースできます。

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

[D]

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 メッセージングシステム (「MQ メッセージングシステムのアーキテクチャ」を参照) は Sun ONE Application Server に統合され、アプリケーションサーバ環境で実行している MDB やほかの JMS メッセージングコンポーネントへ JMS メッセージを送信するために必要なサポートを提供しています。