第 1 章 メッセージングシステム: 概論

Sun Java^TM System Message Queue は、Java Message Service (JMS) 標準を実装し、拡張するメッセージングミドルウェア製品です。このことを十分に理解している場合は、「Message Queue: 要素と機能 」へ進んでください。そうでない場合は、最初からお読みください。

この章では、Message Queue などの製品の基盤をなすメッセージングテクノロジについて述べ、このテクノロジを標準化した JMS 仕様を、Message Queue がどのように実装し拡張するかについて説明します。次のトピックが含まれます。

• 「メッセージ指向ミドルウェア (MOM)」

• 「MOM 標準としての JMS」

• 「Message Queue: 要素と機能 」

• 「Message Queue サービスの拡張」

• 「イネーブリングテクノロジとしての Message Queue」

メッセージ指向ミドルウェア (MOM)

ビジネス、制度、およびテクノロジは絶えず変化しているため、そこで使用されるソフトウェアシステムには、このような変化に順応できる能力が要求されます。ビジネスで、合併、サービスの追加、または使用可能なサービスの拡張を行ったあとで、情報システムを作り直すだけの余裕はほとんど残っていません。この最も重要な時点でこそ、新しいコンポーネントの統合または既存のコンポーネントの拡張を、できるだけ効率的に行う必要があります。異種コンポーネントを最も簡単に統合する方法は、同種の要素として作り直すことではなく、異種であっても相互に通信できるようにする層を用意することです。ミドルウェアと呼ばれるこの層によって、個別に開発され、異なるネットワークプラットフォームで稼働するソフトウェアコンポーネント (アプリケーション、エンタープライズ Java Bean、サーブレットなどのコンポーネント) が、相互に対話できるようになります。この対話が可能になった時点から、ネットワークはコンピュータとして機能できます。

図 1–1 に示すように、ミドルウェアは、概念上、アプリケーション層とプラットフォーム層 (オペレーティングシステムと基礎となるネットワークサービス) の間に位置します。

図 1–1 ミドルウェア

異なるネットワークノードに分散したアプリケーションはアプリケーションインタフェースを使用して通信し、ほかのアプリケーションをホストしているオペレーティング環境の詳細を意識する必要も、これらのアプリケーションに接続するサービスを使用する必要もありません。さらに、相互接続したアプリケーションによるこの新しい仮想的なシステムは、管理インタフェースを備えることにより、信頼性と安全性を確保します。そのパフォーマンスは測定および調整可能であり、機能を損ねずにシステムを拡張できます。

ミドルウェアは、次のカテゴリに分類できます。

• リモートプロシージャー呼び出し (RPC) ベースのミドルウェア。あるアプリケーション内のプロシージャーが、ローカルでの呼び出しであるかのように、リモートのアプリケーション内のプロシージャーを呼び出せるようにします。このミドルウェアにはリンクメカニズムが実装されており、リモートプロシージャーを検索して、呼び出し側から透過的にこれらのプロシージャーを利用できるようにしています。従来、この種のミドルウェアは、プロシージャーベースのプログラムを扱っていましたが、現在、オブジェクトベースのコンポーネントにも対応しています。

• オブジェクトリクエストブローカ (ORB) ベースのミドルウェア。アプリケーションのオブジェクトを、異種ネットワーク間で分散し共有できるようにします。

• メッセージ指向ミドルウェア (MOM) ベースのミドルウェア。分散型アプリケーションが、メッセージの送受信によって、データの通信および交換を行えるようにします。

これらのすべてのモデルで、あるソフトウェアコンポーネントが別のコンポーネントの動作にネットワークを介して影響を及ぼすことができます。RPC ベースと ORB ベースのミドルウェアが、密結合コンポーネントのシステムを作成する一方、MOM ベースのシステムが、疎結合コンポーネントに対応しているという点で、これらには違いがあります。RPC ベースまたは ORB ベースのシステムでは、あるプロシージャーが別のプロシージャーを呼び出すと、呼び出されたプロシージャーが返されるまで、別の処理を行えなくなります。前述のように、これらのモデルでは、ミドルウェアは部分的にスーパーリンカーとして機能し、呼び出されたプロシージャーをネットワーク上で検索し、ネットワークサービスを使用して、関数やメソッドのパラメータをプロシージャーに渡し、結果を返します。

MOM ベースのシステムは、図 1–2 に示すように、メッセージの非同期的交換を通じて、通信を行えるようにします。

図 1–2 MOM ベースのシステム

メッセージ指向ミドルウェアは、メッセージングプロバイダを利用して、メッセージング操作を仲介します。MOM システムの基本要素は、クライアント、メッセージ、および MOM プロバイダです。MOM プロバイダには API と管理ツールが含まれます。MOM プロバイダは、メッセージのルーティングおよび配信に使用されるアーキテクチャーとして、集中メッセージサーバーを使用したものと、ルーティングおよび配信機能を各クライアントマシンに分散したものを使用します。この 2 つの方式を併用した MOM 製品もあります。

MOM システムを使用した場合、クライアントは API 呼び出しを作成して、プロバイダが管理する送信先にメッセージを送信します。この呼び出しによって、プロバイダのサービスが呼び出され、メッセージのルーティングと配信を行います。クライアントはメッセージを送ったあと、受信側クライアントがメッセージを取得するまでメッセージがプロバイダに保持されるため、他の作業を続行することができます。メッセージベースのモデルとプロバイダの仲介とを組み合わせることにより、疎結合コンポーネントのシステムを作成できます。このようなシステムは、個々のコンポーネントまたはコネクションに障害が生じた場合でも確実に機能を続行でき、停止時間がありません。

メッセージングプロバイダにクライアント間のメッセージングを仲介させた場合、管理インタフェースを追加することによって、パフォーマンスの監視と調整を行えるという別のメリットが得られます。したがって、クライアントアプリケーションは、メッセージの送信、受信、および処理の問題を除く実質的にすべての問題から解放されます。相互運用性、信頼性、セキュリティー、スケーラビリティー、パフォーマンスなどの問題の解決は、MOM システムを実装するコードと管理者に委ねられます。

これまで、メッセージ指向ミドルウェアを使用した分散コンポーネントの接続によるメリットについて述べてきました。しかし、デメリットもあります。そのひとつは、疎結合自体から生じるものです。RPC システムでは、呼び出し側の関数は、呼び出された関数が実行中のタスクを終了するまで戻りません。非同期システムでは、呼び出し側のクライアントは、この作業の処理に必要なリソースが欠乏し、呼び出されたコンポーネントに障害が発生するまで、受信側に負荷をかけ続けることがあります。もちろん、パフォーマンスの監視とメッセージフローの調整によって、このような状況を最小限にとどめたり、回避したりすることができますが、RPC システムでは不要な作業になります。それぞれのシステムのメリットとデメリットを理解することが重要です。それぞれのシステムは、異なるタスクに適しています。場合によっては、必要とする動作を得るために、2 種類のシステムを組み合わせる必要が生じることもあります。

図 1–3 では、MOM システムが、2 つの RPC ベースのシステム間の通信を可能にしている様子を示しています。図の左側は、パフォーマンスの改善のために、クライアント、サーバー、およびデータストアのコンポーネントを別々のネットワークノードに分散しているアプリケーションを示しています。これは、割引航空券予約システムです。エンドユーザーがこのサービスの利用料を支払うことにより、このサービスが指定された行先と時間に対して利用可能な最低運賃を見つけます。データストアは、登録ユーザーに関する情報と、このプログラムに参加している航空会社に関する情報を格納しています。サーバーのロジックは、ユーザーの要求に基づいて、参加している航空会社の価格を照会し、情報を調べて、最も安い 3 社の料金をユーザーに提示します。図の右側には、参加している航空会社のいずれか 1 社の航空券 / 予約システムを表す、RPC ベースのシステムが示されています。図の右側は、割引システムに接続している航空会社の数だけ複製されます。データストアは、このような航空会社ごとに、利用可能なフライトに関する情報 (座席、フライト時間、価格など) を保存します。サーバーコンポーネントは、エンドユーザーが入力したデータに応じて情報を更新します。航空会社のサーバーも MOM サービスを利用して、割引予約システムから情報の要求を受け取り、座席および価格情報を返します。顧客が PanWorld 社の割引航空券を購入することにした場合、このシステムのサーバーコンポーネントは、データストア内の情報を更新してから、請求者に対してチケットを発券するか、チケットを発券するように割引サービスへメッセージを送信します。

図 1–3 RPC システムと MOM システムとの組み合わせ

この例には、RPC システムと MOM システムとの相違点がいくつか示されています。分散コンポーネントの結合方法における相違点については、すでに述べました。そのほかにも、RPC システムは多くの場合、クライアントがエンドユーザーであるクライアントおよびサーバーコンポーネントの分散と結合に使用されますが、MOM システムでは、クライアントが、メッセージングによってのみ相互運用可能な異種ソフトウェアコンポーネントであるという点も異なります。

MOM システムでのより重要な問題は、MOM が有標製品として実装されるということから生じます。SuperMOM-X に依拠している企業が、SuperMOM-Y を使用している企業を合併すると、どうなるでしょうか。この問題を解決するために、標準的なメッセージングインタフェースが必要になります。SuperMOM-X と SuperMOM-Y の両方にこのインタフェースが実装されていれば、一方のシステムで稼働するように開発されたアプリケーションは、もう一方のシステムでも稼働できます。このようなインタフェースは、習得が容易であると同時に、高度なメッセージングアプリケーションをサポートできるだけの十分な機能を備えているべきです。1998 年に発表された Java Message Service (JMS) 仕様は、まさしくこのことを目的としています。次の節では、JMS の基本機能について説明し、既存の有標 MOM 製品の共通要素を取り入れ、異種の受け入れと今後の成長に対応するために、この標準がどのように開発されたかについて説明します。

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. メッセージコンシューマが、送信先からメッセージを取得します。

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

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

Message Queue: 要素と機能

これまで、メッセージ指向ミドルウェアの要素について説明し、JMS を使用して MOM アプリケーションに移植性をもたらす方法について説明してきました。次に、Message Queue での JMS 仕様の実装について説明し、信頼性、安全性、拡張性の高いメッセージングサービスの実現に使用する機能およびツールを紹介します。

まず、多くの JMS プロバイダと同様に、Message Queue は、スタンドアロン製品として使用することも、J2EE アプリケーションサーバーに埋め込んで非同期メッセージングをもたらす、イネーブリングテクノロジとして使用することもできます。第 5 章「Message Queue と J2EE」では、J2EE で Message Queue が果たす役割について、さらに詳しく説明します。ほかの JMS 製品とは異なり、Message Queue は、JMS リファレンス実装と呼ばれています。この名称は、Message Queue が正確で完全な JMS 実装であるということを意味しています。また、将来、JMS に改訂や拡張が行われた場合でも、Message Queue 製品を使用できるということも保証しています。

Message Queue サービス

JMS プロバイダとして、Message Queue には、JMS インタフェースを実装し、管理サービスおよび制御を備えたメッセージングサービスが用意されています。これまでの JMS プロバイダの説明では、主に、メッセージの中継におけるブローカの役割に焦点を当ててきました。しかし、実際、JMS プロバイダには、信頼性、安全性、拡張性の高いメッセージングを提供するために、ブローカ以外にも多くの要素が必要です。図 1–6 では、Message Queue メッセージングサービスを構成する要素を示しています。これらの要素には、異なるプロトコルに対応したさまざまなコネクションサービスや管理ツールのほか、メッセージング用、監視用、およびユーザー情報用のデータストアがあります。Message Queue サービスには、この図で灰色で示されたすべての要素が含まれます。

図 1–6 Message Queue サービス

見てわかるとおり、フル機能を備えた JMS プロバイダは、基本的な JMS モデルが疑わしく思われるほど複雑です。次の節では、上の図に示した Message Queue サービスの要素について説明します。これらの要素は、ブローカ、クライアントランタイムサポート、管理の 3 つのカテゴリに分類できます。

ブローカへの接続

図 1–6 に示すように、アプリケーションクライアントと管理クライアントの両方を、ブローカに接続できます。JMS 仕様では、プロバイダに実装する特定のワイヤプロトコルを規定していません。アプリケーションクライアントと管理クライアントがブローカへの接続に使用する Message Queue は、現在、TCP、TLS、HTTP、または HTTPS プロトコルの上の層に位置しています。HTTP の上の層に位置しているサービスのメッセージはファイアウォールを通過できます。

• JMS サポートを実現し、クライアントによるブローカへの接続を可能にしているサービス (jms、ssljms、http、または https) は、サービスタイプが NORMAL であり、TCP、TLS、HTTP 、または HTTPS プロトコルの上の層に位置しています。

• 管理者によるブローカへの接続を可能にしているサービス ( admin、ssladmin) は、サービスタイプが ADMIN であり、TCP または TLS プロトコルの上の層に位置しています。

デフォルトでは、ブローカを起動すると、jms および admin サービスが稼働します。さらに、ブローカを設定して、これらのコネクションサービスのいずれかを実行することも、すべてを実行することもできます。各サービスは、特定の認証および承認 (アクセス制御) 機能をサポートしており、複数のコネクションをサポートするマルチスレッドです。

コネクションに障害が発生した場合、Message Queue サービスは、自動的にクライアントを同じブローカに再度接続したり、またこの機能を有効にしている場合は、別のブローカに接続したりすることができます。詳細は、付録 B 「Message Queue の機能」の自動再接続機能についての説明を参照してください。

クライアントは、コネクションを取得するコネクションファクトリを作成するときに、コネクションランタイムサポートを設定できます。オプションを使用すると、接続先のブローカ、再接続の処理方法、メッセージフロー制御などを指定できます。コネクションの設定方法については、「コネクションファクトリとコネクション」を参照してください。

ブローカ

ブローカは、メッセージサービスの中心にあたり、信頼性の高いメッセージのルーティングと配信、ユーザーの認証、およびパフォーマンス監視用のデータ収集を行います。

• メッセージをルーティングおよび配信するために、ブローカは、受信メッセージをそれぞれの送信先に保管し、これらの送信先へのメッセージの出入りを管理します。

• 信頼性の高い配信を行うため、ブローカでは持続ストアを使用して、メッセージが受信されるまで状態情報と持続メッセージを保存します。ブローカまたはコネクションに障害が発生した場合、ブローカは、保存された情報に基づいて、ブローカの状態を復元し、操作を再試行できます。

• 交換するデータのセキュリティーを確保するために、ブローカでは認証されたコネクションを使用します。オプションで、SSL などのセキュアプロトコル上で実行することにより、データを暗号化できます。ブローカはまた、ユーザーに関する情報と、ユーザーがアクセス可能なデータまたは操作に関する情報を保持したリポジトリを使用し、管理します。ブローカは、このリポジトリで情報を検索することにより、サービスを要求しているユーザーを認証し、そのユーザーが実行しようとしている操作を承認します。

• システム監視のために、ブローカはメトリックスと診断情報を生成し、管理者はこれらの情報にアクセスして、パフォーマンスを測定しブローカを調整できます。メトリックス情報はプログラムでも利用でき、アプリケーションは、メッセージフローおよびパターンを調整して、パフォーマンスを向上できます。

Message Queue サービスには、管理者がブローカサポートの設定に使用できるさまざまな管理ツールが用意されています。詳細については、「管理」を参照してください。

クライアントランタイムサポート

クライアントランタイムサポートは、Message Queue クライアントの作成時に、関連付けるライブラリで提供されます。クライアントランタイムは、Message Queue サービスと見なすことができ、クライアントに含まれます。たとえば、クライアントコードが API 呼び出しを作成してメッセージを送信する場合、これらのライブラリ内のコードが呼び出され、ブローカの物理的な送信先へメッセージを中継するために使用されるプロトコルに合わせて適切にメッセージをパッケージします。

Java および C クライアントサポート

Java クライアントのサポートには、JMS プロバイダのみを必要とします。ただし、図 1–6 に示すように、Message Queue クライアントでは、メッセージの送受信に、Java を使用することも、プロバイダ固有の C API を使用することもできます。これらのインタフェースは、Java または C ランタイムライブラリに実装されています。このランタイムライブラリが、ブローカへのコネクションを作成し、要求されたコネクションサービスに合わせて適切にパッケージするという実際の処理を行います。

• Java クライアントランタイムは、ブローカとの対話に必要なオブジェクトを Java クライアントに提供します。これらのオブジェクトには、コネクション、セッション、メッセージ、メッセージプロデューサ、メッセージコンシューマなどがあります。

• C クライアントランタイムは、C クライアントに、ブローカとの対話に必要な関数と構造を提供します。C クライアントランタイムは、JMS プログラミングモデルのプロシージャー版をサポートします。C クライアントは、管理対象オブジェクトへのアクセスに JNDI を使用できませんが、コネクションファクトリと送信先をプログラムによって作成できます。

Message Queue サービスには C API が用意されているため、旧バージョンの C アプリケーションと C++ アプリケーションを、JMS ベースのメッセージングに加えることができます。これら 2 つの API によって提供される機能には多数の相違点があります。これらについては、「Java クライアントと C クライアント」で説明しています。

JMS 仕様は Java クライアントに限定した標準であることに注意してください。C サポートは、Message Queue プロバイダ固有の機能です。ほかのプロバイダに移植しようとしているクライアントアプリケーションでは使用しないでください。

Java クライアントでの SOAP サポート

Message Queue Java クライアントは、SOAP メッセージを JMS メッセージとしてラップして送受信することもできます。SOAP (Simple Object Access Protocol) を使用すると、分散環境にある 2 つのピア間で構造化データを交換できます。交換されるデータは、XML 方式で指定されます。

Sun の SOAP 処理は、現在、ポイントツーポイントモデルを使用した場合に制限されており、信頼性が保証されません。SOAP メッセージを JMS メッセージにラップし、ブローカを使用してルーティングすることにより、フル機能を備えた Message Queue メッセージングを活用することができます。これにより、信頼性の高い配信が保証され、ポイントツーポイントドメインのほかにトピックを使用できるようになります。Message Queue には、メッセージプロデューサが SOAP メッセージを JMS メッセージにラップする際に使用でき、メッセージコンシューマが SOAP メッセージを JMS メッセージから抽出する際に使用できるユーティリティールーチンが用意されています。

「SOAP メッセージの処理」では、SOAP メッセージ処理について詳しく説明しています。

管理

Message Queue サービスには、次の作業に使用できるコマンド行ツールが用意されています。

• ブローカの起動および設定。

• 送信先の作成および管理、ブローカコネクションの管理、およびブローカリソースの管理。

• JNDI オブジェクトストア内の管理対象オブジェクトの追加、一覧表示、更新、および削除。

• ファイルベースのユーザーリポジトリの入力と管理。

• 持続ストレージ用の JDBC 準拠データベースの作成と管理。

また、GUI ベースの管理コンソールを使用して、次のコマンド行機能を実行できます。

• ブローカへの接続および管理。

• 物理的な送信先の作成および管理。

• オブジェクトストアへの接続、ストアへのオブジェクトの追加、およびそれらの管理。

Message Queue サービスの拡張

クライアント数またはコネクション数が増加するにつれ、ボトルネックを解消し、パフォーマンスを向上させるために、メッセージサービスを拡張する必要が生じる場合があります。Message Queue メッセージサービスでは、ユーザーのニーズに応じた拡張オプションを多数用意しています。これらは、便宜上、次のカテゴリに分類されます。

• 垂直方向の拡張は、より高い処理能力を追加し、利用可能なリソースを拡張することによって実現できます。この拡張を行うには、プロセッサまたはメモリーを追加するか、共有スレッドモデルへ切り替えるか、または Java VM を 64bit モードで実行します。

  ポイントツーポイントドメインを使用している場合は、複数のコンシューマからのキューへのアクセスを有効にすることにより、コンシューマ側を拡張できます。この方式を使用すると、アクティブおよびバックアップコンシューマの最大数を指定できます。ロードバランスメカニズムでも、コンシューマの現在の容量とメッセージ処理速度を考慮します。これは Message Queue の機能です。JMS 仕様で規定しているメッセージング動作は、1 つのコンシューマのみがキューにアクセスしている場合のものです。複数のコンシューマを許可するキューの動作は、プロバイダ固有の機能です。『Message Queue developer guide』で、この拡張オプションの詳細について説明しています。

• ステートレスな水平方向の拡張は、追加ブローカを使用して、これらのブローカに既存のクライアントを分散することにより実現できます。この方式は実装が簡単ですが、独立した作業グループにメッセージング操作を分割できる場合にのみ適しています。

• ステートフルな水平方向の拡張は、複数のブローカを接続してクラスタを構成することにより実現されます。ブローカクラスタでは、各ブローカは、クラスタ内のほかのすべてのブローカ、およびローカルアプリケーションクライアントにも接続します。ブローカは、同一ホスト上に置くことも、ネットワーク上に分散させることもできます。送信先とコンシューマに関する情報は、クラスタ内のすべてのブローカで複製されます。送信先またはサブスクライバに対する更新も伝えられます。これにより、各ブローカは、直接接続しているプロデューサから、クラスタ内のほかのブローカに接続しているコンシューマへ、メッセージをルーティングできます。バックアップコンシューマが使用されている状況では、1 つのブローカまたはコネクションに障害が発生した場合、アクセスできないコンシューマへ送信されたメッセージを、別のブローカ上のバックアップコンシューマに転送できます。

  ブローカまたはコネクションに障害が発生した場合、持続エンティティー (送信先および永続サブスクリプション) に関する状態情報が同期されなくなる可能性があります。たとえば、クラスタ化したブローカが停止し、送信先がクラスタ内の別のブローカ上に作成された場合、最初のブローカが再起動されると新しい送信先が不明になります。この問題に対処するために、クラスタ内の 1 つのブローカをマスターブローカとして指定することができます。このブローカは、マスター設定ファイルでの送信先と永続サブスクリプションに対するすべての変更を追跡し、一時的にオフラインになっているクラスタ内のブローカを更新します。詳細は、第 4 章「ブローカクラスタ」を参照してください。

  マスターブローカを使用した場合でも、Message Queue ではサービスの可用性しか向上しません。ブローカまたはコネクションに障害が発生した場合、データの可用性は確保されません。たとえば、クラスタ化したブローカが利用できなくなった場合、そのブローカが保持しているすべての持続メッセージは、そのブローカが復元されるまで利用できません。現在のところ、データの可用性を確保する唯一の手段は、SunCluster Message Queue エージェントを使用するというものです。この場合、持続ストアが共有ファイルシステム上に保持されます。ブローカに障害が発生した場合、2 番目のノード上の Message Queue エージェントがブローカを起動して、このブローカが共有ストアを引き継ぎます。クライアントはそのブローカに接続し直されます。この結果、サービスの継続と持続データへのアクセスの両方が確保されます。

イネーブリングテクノロジとしての Message Queue

Java 2 Platform, Enterprise Edition (J2EE プラットフォーム) は、Java プログラミング環境における分散コンポーネントモデルについて規定する仕様です。J2EE プラットフォームの要件の 1 つは、分散コンポーネントが、信頼性の高い非同期メッセージ交換機能により相互に対話できるようにすることです。この機能は JMS プロバイダが提供するものであり、サービスを提供するという役割と、JMS メッセージをコンシュームできる特殊な種類の Enterprise Java Bean (EJB) コンポーネントであるメッセージ駆動型 Beans (MDB) をサポートするという 2 つの役割を果たします。

J2EE 準拠のアプリケーションサーバーは、指定された JMS プロバイダの機能を使用する場合、そのプロバイダによって用意されたリソースアダプタを使用する必要があります。Message Queue は、このようなリソースアダプタを用意しています。アプリケーションサーバー環境に配備され稼働する MDB などの J2EE コンポーネントは、プラグインの JMS プロバイダのサポートを使用すると、J2EE コンポーネント、および外部の JMS コンポーネントと、JMS メッセージを交換できます。これにより、分散コンポーネントを緊密に統合することができます。

Message Queue リソースアダプタについては第 5 章「Message Queue と J2EE」を参照してください。

Message Queue 機能の要約

Message Queue は、JMS 仕様の要件よりはるかに多くの機能や特長を備えています。Message Queue は、これらの機能により、24 時間稼働の基幹業務で大量のメッセージを交換する多くの分散コンポーネントで構成されるシステムを統合できます。これらの機能についての概要は、付録 B 「Message Queue の機能」を参照してください。