MOM 標準としての JMS

Java Messaging Service 仕様は、本来、Java アプリケーションから既存の MOM システムにアクセスできるようにするために開発されました。この仕様は発表以来、既存の多くの MOM ベンダーによって採用され、それ自体で非同期メッセージングシステムとして実装されてきました。

JMS 仕様の設計者は、その作成時に、既存のメッセージングシステムの本質的要素を取り入れようと考えました。この本質的要素は次のとおりです。

• メッセージのルーティングと配信を行うメッセージングプロバイダの概念

• ポイントツーポイントメッセージングやパブリッシュ / サブスクライブメッセージングなど、個別のメッセージングパターンまたはドメイン

• 同期および非同期メッセージ受信用の機構

• 信頼性の高いメッセージ配信のサポート

• ストリーム、テキスト、バイトなどの、共通のメッセージ形式

ベンダーは、JMS インタフェースを実装するライブラリ、メッセージのルーティングおよび配信の機能、およびメッセージングサービスの管理、監視、調整を行う管理ツールから構成される JMS プロバイダを用意して、JMS 仕様を実装しています。ルーティングおよび配信機能は、集中メッセージングサーバーまたはブローカが実行する場合も、各クライアントのランタイムに組み込んだ機能を通じて実装する場合もあります。

同時に、JMS プロバイダはさまざまな役割を果たすことができます。スタンドアロン製品として作成することも、より大規模な分散ランタイムシステム内の埋め込みコンポーネントとして作成することも可能です。スタンドアロン製品の場合、エンタープライズアプリケーション統合システムの基幹を定めるために使用できます。アプリケーションサーバーに埋め込む場合は、内部コンポーネントメッセージングをサポートできます。たとえば、J2EE は、JMS プロバイダを使用してメッセージ駆動型 Beans を実装し、EJB コンポーネントによるメッセージの送受信ができるようにしています。

既存のシステムのすべての機能を含んだ標準を作成していたなら、習得が難しく実装の困難なシステムになっていたでしょう。JMS ではそのようにせず、メッセージングの概念および機能の共通項を定義しました。この結果、習得が容易で、JMS プロバイダ間での JMS アプリケーションの移植性を最大限にした標準となりました。JMS が API 標準であり、プロトコル標準ではないことに留意することが重要です。あるベンダーから別のベンダーに JMS クライアントを移行するのは簡単です。ただし、JMS ベンダーが異なると、一般的に、直接互いに通信することはできません。

次の節では、JMS 仕様で規定された、基本オブジェクトとメッセージングパターンについて説明します。

JMS メッセージングオブジェクトおよびパターン

メッセージの送受信を行うために、JMS クライアントはまず、しばしばメッセージブローカとして実装される JMS プロバイダに接続する必要があります。接続すると、クライアントとブローカ間の通信チャネルが開かれます。次に、クライアントはメッセージの作成、プロデュース、およびコンシュームを行うためにセッションを設定する必要があります。このセッションは、クライアントとブローカ間の特定のやり取りを定めるメッセージのストリームと見なすことができます。クライアント自体は、 メッセージプロデューサ または メッセージコンシューマ、あるいはその両方になります。メッセージプロデューサは、ブローカが管理している送信先に、メッセージを送信します。メッセージコンシューマは、その送信先にアクセスして、メッセージをコンシュームします。メッセージには、ヘッダー、オプションのプロパティー、および本体が含まれます。本体にはデータが格納されます。ヘッダーには、メッセージのルーティングおよび管理にブローカで必要とされる情報が含まれます。プロパティーは、クライアントアプリケーションまたはプロバイダが、メッセージの処理でのそれぞれのニーズを満たすように定義できます。コネクション、セッション、送信先、メッセージ、プロデューサ、およびコンシューマは、JMS アプリケーションを構成する基本オブジェクトです。

これらの基本オブジェクトを使用して、クライアントアプリケーションは、2 つのメッセージングパターン (ドメイン) でメッセージを送受信できます。図 1–4 に、この様子を示します。

図 1–4 JMS メッセージングパターン

クライアント A および B はメッセージプロデューサであり、2 種類の異なる送信先を経由して、クライアント C、D、および E にメッセージを送信しています。

• クライアント A、C、D 間のメッセージングは、ポイントツーポイントパターンを表しています。このパターンを使用した場合、クライアントがキュー送信先へメッセージを送信し、ただ 1 つの受信側がその送信先からメッセージを取得できます。この送信先にアクセスするほかの受信側は、そのメッセージを取得できません。

• クライアント B、E、F 間のメッセージングは、パブリッシャー / サブスクライブパターンを表しています。このブロードキャストパターンを使用した場合、クライアントがトピック送信先にメッセージを送信し、任意の数のコンシューミングサブスクライバがその送信先からメッセージを取得できます。各サブスクライバは、メッセージのコピーをそれぞれ取得します。

どちらのドメインのメッセージコンシューマも、メッセージの取得を同期または非同期にするかを選択できます。同期コンシューマは、メッセージを取得するための明示的な呼び出しを作成します。非同期コンシューマは、保留中のメッセージを渡すために呼び出されるコールバックメソッドを指定します。コンシューマは、受信メッセージに対して選択基準を指定することによって、メッセージをフィルタで除外することもできます。

管理対象オブジェクト

JMS 仕様は、あらゆる可能性を網羅しようとせずに、既存の MOM システムの多くの要素を結合した標準を作成しました。むしろ、異種および将来の成長に対応できる拡張可能な方式を確立しようとしました。JMS では、多くのメッセージング要素の定義と実装を、個々のプロバイダに任せています。これらの要素には、ロードバランス、標準エラーメッセージ、管理 API、セキュリティー、基本的なワイヤプロトコル、およびメッセージストアがあります。次の節の「Message Queue: 要素と機能 」では、Message Queue で、これらの要素の多くがどのように実装され、JMS 仕様がどのように拡張されているかについて説明します。

JMS で完全には規定されていない 2 つのメッセージング要素が、コネクションファクトリと送信先です。これらは JMS プログラミングモデルで不可欠な要素ですが、プロバイダによるこれらのオブジェクトの定義および管理方法には、非常に多くの相違点および予想される相違点があったため、共通の定義の作成は不可能であり、また望ましいことでもありませんでした。したがって、これらの 2 つのオブジェクトは、プログラムによって作成されるのではなく、通常、管理ツールを使用して、作成および設定されます。次にこれらのオブジェクトはオブジェクトストアに保存され、JNDI 検索を通じて JMS クライアントからアクセスされます。

• コネクションファクトリ管理対象オブジェクトは、クライアントからブローカへのコネクションを生成するために使用されます。これらのオブジェクトは、メッセージング動作のある側面を制御する、プロバイダ固有の情報をカプセル化します。たとえば、コネクション処理、クライアントの識別、メッセージヘッダーのオーバーライド、信頼性、フロー制御などです。特定のコネクションファクトリから生成したすべてのコネクションは、そのファクトリに対して設定された動作を行います。

• 送信先管理対象オブジェクトは、ブローカ上の物理的な送信先を参照するために使用されます。プロバイダ固有の命名 (アドレス指定構文) 規則をカプセル化し、送信先を使用するメッセージングドメインが、キューかトピックかを指定します。

JMS クライアントは、管理対象オブジェクトの検索には必要ありません。これらのオブジェクトはプログラムによって作成された後、ブローカのメモリーに保存されます。プロトタイピングを迅速に行うには、これらのオブジェクトをプログラムによって作成する方法が最も簡単です。ただし、本稼働環境に配備する場合は、中央のリポジトリから管理対象オブジェクトを検索した方が、メッセージング動作の制御または管理をより簡単に行えます。

• コネクションファクトリオブジェクトに対して管理オブジェクトを使用することによって、管理者は、これらのオブジェクトを設定し直して、メッセージングパフォーマンスを調整できます。コーディングし直さずに、パフォーマンスを改善できます。

• 物理的な送信先に対して管理オブジェクトを使用した場合、管理者は、設定済みのオブジェクトにクライアントをアクセスさせることにより、ブローカ上で送信先が拡大しないよう制御できます。

• 管理対象オブジェクトにより、開発者は、プロバイダ固有の実装詳細を意識せずに済みます。あるプロバイダ用に開発するコードが、ほとんどあるいはまったく変更せずに、ほかのプロバイダへ移植できるようになります。

管理対象オブジェクトの使用により、図 1–5 に示す基本的な JMS アプリケーションの図式に最後の要素が加わります。

図 1–5 JMS アプリケーションの基本要素

図 1–5 では、メッセージプロデューサとメッセージコンシューマが、送信先管理対象オブジェクトを使用して、それに対応する物理的な送信先にアクセスする様子を示しています。番号の付いた手順は、このメカニズムを使用してメッセージを送受信する場合に、管理者およびクライアントアプリケーションが行う必要のある操作を指しています。

管理対象オブジェクトを送信先として使用する

1. 管理者が、ブローカ上に物理的な送信先を作成します。

2. 管理者が、送信先管理対象オブジェクトを作成し、そのオブジェクトが対応する物理的な送信先の名前とそのタイプ (キューまたはトピック) を指定して、オブジェクトを設定します。

3. メッセージプロデューサが、JNDI 検索呼び出しを使用して、送信先管理対象オブジェクトを検索します。

4. メッセージプロデューサが、送信先にメッセージを送信します。

5. メッセージコンシューマが、メッセージを取得できると予想する送信先管理対象オブジェクトを検索します。

6. メッセージコンシューマが、送信先からメッセージを取得します。

   コネクションファクトリ管理対象オブジェクトを使用するプロセスも同様です。管理者は、管理ツールを使用して、コネクションファクトリ管理対象オブジェクトを作成および設定します。クライアントは、コネクションファクトリオブジェクトを検索し、そのオブジェクトを使用してコネクションを作成します。

   管理対象オブジェクトを使用すると、メッセージングプロセスの手順が増えますが、同時に、メッセージングアプリケーションの堅牢性と移植性も高まります。