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 エージェントがブローカを起動して、このブローカが共有ストアを引き継ぎます。クライアントはそのブローカに接続し直されます。この結果、サービスの継続と持続データへのアクセスの両方が確保されます。