|
| |
| Sun Java System Message Queue 3 2005Q1 技術の概要 | |
第 1 章
基本概念Sun JavaTM System Message Queue (Message Queue) は、企業全体に分散されたアプリケーションとコンポーネントを統合可能な、信頼性の高い非同期メッセージングサービスを提供します。異なるプラットフォームやオペレーティングシステムで実行されるプロセスであっても、このサービスに接続して相互に対話することができます。
Message Queue は、JavaTM Message Service (JMS) オープン標準を実装する標準ベースのメッセージング (messaging) ソリューションです。また Message Queue は、相互運用性、セキュリティ、スケーラビリティ、可用性、管理機能、および企業での大規模配備に必要なその他の特長を備えています。
この章では、Message Queue の基本概念を説明します。次のトピックが含まれます。
JMS の概念や用語についてすでに理解している場合は、第 2 章「Message Queue の紹介」にお進みください。
エンタープライズメッセージングシステムエンタープライズメッセージングシステムにより、独立した分散アプリケーションやアプリケーションコンポーネントは、メッセージを介して対話することができます。これらのコンポーネントは、同一ホストや同一ネットワークにあっても、またはインターネットを介して疎結合されていても、メッセージングによってデータを渡し、それぞれの機能を調整します。
多数のコンポーネントがメッセージを同時に交換し、高密度スループットをサポートできるようにするには、メッセージを受信するコンシューマの準備が整ってからメッセージを送信するという方法では対応しきれません。メッセージコンシューマが使用中またはオフラインの場合には、準備が整ってからコンシューマ側でメッセージを受け取ることができるような仕組みを、システムに備える必要があります。このように、メッセージの送信と受信を切り離す方法を非同期メッセージ配信と呼びます。
非同期メッセージングモデルは、複雑なシステムを統合するタスクに対して優れた適性を示します。複雑なシステムでは、1 つのコンポーネントが処理を実行する過程で別のコンポーネントの動作を抑制することは難しく、望ましくもありません。非同期メッセージングでは、同期システムで実行可能な制御機能の一部が犠牲になりますが、コンポーネントの相互動作の柔軟性を大幅に向上させることができます。また、1 つのコンポーネントで障害が発生した場合でもシステム全体に波及しないので、堅牢性も高められます。
エンタープライズメッセージングシステムの要件
一般的なエンタープライズアプリケーションシステムは、多くの分散コンポーネントで構成されており、24 時間稼働の基幹業務で大量のメッセージを交換します。非同期メッセージングをサポートすることに加えて、このような基幹システムをサポートするには、エンタープライズメッセージングシステムが次の要件を満たしている必要があります。
信頼性の高い配信能力 あるコンポーネントから別のコンポーネントに送信されるメッセージが、ネットワークやシステムの障害で失われないようにする必要があります。つまりシステムには、メッセージ配信を保証できるだけの信頼性が必要です。
セキュリティ メッセージングシステムは、ユーザーの認証、メッセージとリソースへの承認されたアクセス、ネットワーク上の暗号化など、基本的なセキュリティ機能をサポートしている必要があります。
スケーラビリティ メッセージングシステムは、パフォーマンスやメッセージスループットを実質的に低下させることなく、ユーザーやメッセージ数の増加などによる負荷の増大に対応できるようにする必要があります。ビジネスやアプリケーションが拡大するにつれ、これは重要な要件となります。
可用性 メッセージングシステムは、ほとんど停止することなく稼働する必要があります。そのためシステムは、障害が発生した場合でもメッセージングサービスを継続して提供できるよう、十分な冗長性を備えています。
管理機能 メッセージングシステムは、メッセージの配信状態を監視および管理するツールを装備している必要があります。管理者には、システムリソースを最適化し、システムパフォーマンスを調整する能力が必要です。
集中 (MOM) メッセージング
Message Queue では、図 1-1 に示すような集中メッセージングシステムを採用しています。このようなシステムでは、各メッセージングコンポーネントが 1 つの中央メッセージサービスとのコネクションを維持します。各コンポーネントは、きめ細かに定義されたインタフェースを介してメッセージサービスと対話します。
一方、図の左側に示すようなピアツーピアシステムでは、すべてのメッセージングコンポーネントそれぞれが他のすべてのコンポーネントとのコネクションを維持します。ピアツーピアシステムでは、高速かつ安全に信頼性の高い方法で配信できますが、コンポーネントごとに信頼性やセキュリティを確保するためのコードを備える必要があります。メッセージの送信と受信が緊密に結び付いているので、非同期で配信することも困難です。システムにコンポーネントが追加されると、コネクション数は急激に増加することになるので、システムの拡張性はすぐに尽きてしまいます。集中管理する方法でも、ピアツーピアシステムの場合には問題が残ります。
図 1-1 集中メッセージングとピアツーピアメッセージング
エンタープライズメッセージングの実現手段に適した集中システムでは、メッセージサービスによってコンポーネント間のメッセージのルーティングと配信を行います。メッセージサービスには、信頼性の高い配信処理を実行し、セキュリティを確保する役割があります。このシステムのコンポーネントは疎結合なので、非同期メッセージングを実現しやすい形態になっています。
メッセージコンポーネントがシステムに追加されても、コネクション数は一定の割合で増加するだけなので、メッセージサービスを拡張すればシステムも容易に拡張できます。集中メッセージサービスは、メッセージングクライアントを接続することのほかに管理インタフェースとしての機能も提供し、これにより、動作の設定、パフォーマンスの監視、およびサービスの調整を行って各メッセージクライアントの必要を満たすことができます。
メッセージサービスの基本アーキテクチャ
図 1-2 に、集中メッセージングシステムの基本アーキテクチャを示します。この基本アーキテクチャは、共通メッセージサービス経由でメッセージを交換する、メッセージプロデューサ (producer) とメッセージコンシューマ (consumer) で構成されています。メッセージプロデューサとメッセージコンシューマは、同一メッセージングコンポーネント (またはアプリケーション) 内に複数存在できます。
メッセージプロデューサは、メッセージサービスプログラミング API を使用して、メッセージをメッセージサーバー (message server) に送信します。メッセージサーバーは、メッセージルーティングと配信コンポーネントを利用して、メッセージの配信対象として登録されている 1 つ以上のメッセージコンシューマにメッセージを配信します。コンシューマは、メッセージサービスプログラミング API を使用してメッセージを受信します。メッセージサービスは、すべての適切なコンシューマへのメッセージの配信を保証する役割を担います。
図 1-2 メッセージサービスのアーキテクチャ
このプロセスは、郵便物のやり取りを例にして説明できます。郵便物の宛先には最終的な受取人の住所を記入しますが、郵便物は郵便局を通して配送され、受取人がその郵便物をポストから取り出すまでには、その中間地点で何度か保管されることになります。
Java Message Service (JMS) の基本Message Queue は、Java Message Service (JMS) オープン標準を実装するエンタープライズメッセージングシステム、JMS プロバイダ (JMS provider) です。そのため、JMS の概念は Message Queue サービスの仕組みを理解する上で欠かすことができません。
JMS 仕様には、信頼性の高い非同期メッセージングの動作を制御する、規則とセマンティクスのセットが規定されています。この仕様では、メッセージ構造、プログラミングモデル、および API を定義しています。
この節では、このマニュアルを理解するのに必要な JMS の概念や用語を説明します。次のトピックが含まれます。
JMS メッセージ構造
Message Queue のデータは、JMS メッセージを使用して交換されます。JMS 仕様に準じて、プロデューシングクライアントによって作成される JMS メッセージは、ヘッダー、プロパティ、および本体の 3 つの部分で構成されています。
ヘッダー
すべての JMS メッセージにはヘッダーが必要です。ヘッダーフィールドには、メッセージのルーティングと識別に使用する値が入力されています。
ヘッダーの値は次の複数の方法で設定できます。
JMS によって定義されるヘッダーフィールドについての詳細は、『Message Queue Developer's Guide for Java Clients』または『Message Queue Developer's Guide for C Clients』を参照してください。これらのヘッダーフィールドにより、メッセージの送信先、有効期限、優先度などを定義できます。
プロパティ
メッセージには、プロパティというヘッダーフィールドをオプションで追加できます。プロパティフィールドは、プロパティ名とプロパティ値のペアで指定されます。プロパティは、メッセージヘッダーの延長と見なすことができ、データを作成したプロセス名、作成された時刻、および各データの構造に関する情報が入力されています。JMS プロバイダは、圧縮の有無や存続終了時の廃棄方法など、メッセージの処理方法を判別するためのプロパティを追加することもあります。
JMS プロバイダは、セレクタとしてメッセージプロパティを使用し、メッセージのソートとルーティングを実行できます。プロデューシングクライアントは、アプリケーション固有のプロパティをメッセージに設定することができ、コンシューミングライアントは、プロパティに特定の値が含まれるメッセージだけを受け取る方法を選択できます。たとえば、コンシューミングクライアントは、ニュージャージーで働くパートタイム従業員の給与に関するメッセージのみが必要であることを指示することが可能です。指定された選択条件に一致しないメッセージは、クライアントに配信されません。
セレクタは、コンシューミングクライアントの動作を単純化し、メッセージが不要なクライアントへの配信メッセージによるオーバーヘッドを解消します。ただし、メッセージサービスでは選択条件を処理する必要があるので、オーバーヘッドが若干増加します。メッセージセレクタの構文とセマンティクスについては、JMS の仕様書で解説されています。
メッセージ本体のタイプ
JMS メッセージのタイプにより、表 1-1 の規定に従ってメッセージ本体の内容が決まります。
JMS プログラミングモデル
JMS プログラミングモデルは、非同期メッセージングサービスのアーキテクチャをサポートしており、JMS クライアントは、JMS メッセージサービスによってメッセージを交換します。JMS プロバイダは、JMS メッセージングを実行するために必要なオブジェクトを用意します。これらのオブジェクトは、JMS アプリケーションプログラミングインタフェース (API) を実装します。
この節では、JMS メッセージングに必要なプログラミングオブジェクトについて説明し、メッセージの送受信に使用する配信モデル (ポイントツーポイントおよびパブリッシュ / サブスクライブ) を紹介します。
プログラミングオブジェクト
図 1-3 に、JMS クライアントをセットアップしてメッセージを配信するために使用するオブジェクトを示します。
図 1-3 JMS プログラミングオブジェクト
JMS プログラミングモデルでの JMS クライアントは、コネクションファクトリ (connection factory) オブジェクト (ConnectionFactory) を使用して、JMS メッセージサーバーとの間でメッセージを送受信するときに使用するコネクション (connection) を確立します。コネクションオブジェクト (Connection) は、メッセージサーバーに対するクライアントのアクティブなコネクションです。
通信リソースの割り当てとクライアントの認証は、コネクションが作成されるときに行われます。このオブジェクトは比較的重いため、ほとんどのクライアントはメッセージングのすべてを 1 つのコネクションだけで行います。
コネクションは、セッション (session) オブジェクト (Session) の作成に使用されます。セッションは、シングルスレッドコンテキストで、メッセージのプロデュースとコンシュームを実行します。このコンテキストは、メッセージの作成と、メッセージの送受信を行うメッセージプロデューサおよびメッセージコンシューマを作成するために使用され、配信するメッセージの順番を定義します。セッションは、多数の通知オプションまたはトランザクションを使って、信頼性の高い配信処理をサポートします。
クライアントは、メッセージプロデューサオブジェクト (MessageProducer) を使用して、API の中の送信先オブジェクトによって示される特定の物理的な送信先 (destination) にメッセージを送信します。メッセージプロデューサは、配信モード (持続と非持続)、優先度、生存期間など、プロデューサが物理的な送信先に送信する全メッセージを制御するデフォルトのメッセージヘッダー値を指定できます。
同様にクライアントは、メッセージコンシューマオブジェクト (MessageConsumer) を使用して、API の中の送信先オブジェクトに示される特定の物理的な送信先からメッセージを受信します。送信先のタイプは、キュー (queue) とトピック (topic) の 2 種類あり、メッセージ配信モデルによって決まります。
メッセージコンシューマは、メッセージセレクタを使用して、プロパティが特定の選択条件に一致するメッセージだけをメッセージサービスによって配信させることができます。
メッセージコンシューマは、同期または非同期のどちらかのメッセージのコンシュームをサポートしています。
プログラミングドメイン: メッセージ配信モデル
JMS は、ポイントツーポイントとパブリッシュ / サブスクライブという 2 つの異なるメッセージ配信モデル (delivery model) をサポートしています。
ポイントツーポイント (キュー送信先) メッセージは、1 つのプロデューサから 1 つのコンシューマに配信されます。この配信モデルの送信先タイプはキューです。メッセージは、最初にキュー送信先に配信され、次にそのキューから、1 回に 1 つずつ、そのキューに対して登録されたコンシューマのいずれかに配信されます。キュー送信先にメッセージを送信できるプロデューサの数に制限はありませんが、個々のメッセージは、1 つのコンシューマだけに向けて配信され、コンシュームされることが保証されています。キュー送信先のコンシューマが 1 つも登録されていない場合、キューは受信したメッセージを保持し、キュー送信先に対してコンシューマが登録されたときにそのメッセージを配信します。
パブリッシュ / サブスクライブ (トピック送信先) メッセージは、1 つのプロデューサから複数のコンシューマに配信されます。この配信モデルの送信先タイプはトピックです。メッセージは最初にトピック送信先に配信され、次にトピックに加入した、すべてのアクティブなコンシューマに配信されます。任意の数のプロデューサが 1 つのトピック送信先にメッセージを送信することができ、各メッセージは任意の数の加入済みコンシューマに配信できます。
トピック送信先は、永続サブスクリプションもサポートします。永続サブスクリプションは、トピック送信先に登録されていても、メッセージが配信されたときに非アクティブになっている可能性があるコンシューマを表しています。コンシューマは、もう一度アクティブになったときにメッセージを受け取ります。トピック送信先として登録されたコンシューマがない場合、トピックは、永続サブスクリプション状態の非アクティブコンシューマ宛のメッセージを保持するだけです。
この 2 つのメッセージ配信モデルは、セマンティクスが若干異なる API オブジェクトの 3 つの組み合わせを使用して処理され、表 1-2 に示すように異なるプログラミングドメイン (domain) を表しています。
表 1-2 JMS プログラミングドメインとオブジェクト
基本タイプ (統一ドメイン)
ポイントツーポイントドメイン
パブリッシュ / サブスクライブドメイン
Destination (Queue または Topic)1
Queue
Topic
ConnectionFactory
QueueConnectionFactory
TopicConnectionFactory
Connection
QueueConnection
TopicConnection
Session
QueueSession
TopicSession
MessageProducer
QueueSender
TopicPublisher
MessageConsumer
QueueReceiver
TopicSubscriber
1プログラミングの手法によっては、特定の送信先タイプを指定する必要があります。
統一ドメインは、JMS バージョン 1.1 から導入されています。以前の 1.02b 仕様に適合する必要がある場合は、ドメイン固有 API を使用できます。ドメイン固有 API を使用することには、たとえばキュー送信先の永続サブスクライバの作成など、特定のプログラミングエラーを防止するクリーンなプログラムインタフェースという利点もあります。ただしドメイン固有 API には、同じトランザクションまたは同じセッションにおいて、ポイントツーポイント操作とパブリッシュ / サブスクライブ操作を組み合わせることができないというマイナス面もあります。両方の操作を組み合わせる必要がある場合は、統一ドメイン API を選択してください。
Message Queue 製品に付属するアプリケーション例や、Message Queue のマニュアルに掲載されるコードの多くでは、別々のプログラミングドメインを使用しています。
信頼性の高いメッセージング
メッセージの配信モード (delivery mode) は、持続モードか非持続モードのいずれかに設定できます。配信モードにより、メッセージ配信の信頼性が決まります。
持続メッセージの場合、信頼性の保証には 2 つの側面があります。1 つは、通知とトランザクションを使用することにより、メッセージの作成とコンシュームが正常に実行されるようにすることです。もう 1 つは、持続ストアにメッセージを格納することにより、コンシューマに配信される前にメッセージサービスが持続メッセージを失うことがないようにすることです。
次の節では、信頼性を確保する場合の 2 つの側面について説明します。
通知 / トランザクション
信頼性の高いメッセージングは、メッセージプロデューサからメッセージサーバーの物理的な送信先への、および物理的な送信先からメッセージコンシューマへの持続メッセージの正常配信の保証に依存しています。この信頼性は、JMS セッションによってサポートされる 2 つの一般的なメカニズムである、通知およびトランザクション (transaction) のいずれかを使用することによって確保されます。トランザクションの場合、分散トランザクションマネージャに制御されている状態では、ローカルまたは分散のどちらかになる可能性があります。
通知
通知は、信頼性の高い配信を確実に行うために、クライアントとメッセージサービスの間で送信されるメッセージです。
メッセージが作成される場合、メッセージサービスは、配信されたメッセージを受信して送信先に格納し、持続的に保存したことを通知します。プロデューサの send() メソッドは、通知が返されるまでブロックします。
メッセージがコンシュームされる場合、クライアントは、メッセージサービスが送信先からメッセージを削除する前に、送信先から配信されたメッセージを受信してコンシュームしたことを通知します。JMS では、違うレベルの信頼性を表す別の通知モードを規定しています。それらのモードの一部では、クライアントがブロックし、メッセージを削除したためにクライアントがそのメッセージを再配信できないことをメッセージサーバーが確認するまで待機します。
ローカルトランザクション
セッションを処理済みとして設定することもできます。この場合は、1 つ以上のメッセージのプロデュースおよびコンシュームが、トランザクションという極小の単位にグループ化されます。JMS API には、トランザクションを起動、確定、およびロールバックするメソッドが用意されています。
メッセージがトランザクション内でプロデュースまたはコンシュームされるに従って、メッセージサービスがさまざまな送受信を追跡し、JMS クライアントが呼び出しを実行してトランザクションを確定したときにだけ、送受信の操作を完了させます。トランザクション内での特定の送信や受信の操作が失敗すると、例外が発生します。クライアントコードは、これを無視するか、操作を試行し直すか、またはトランザクション全体をロールバックして、例外を処理できます。トランザクションがコミットされると、すべての操作が完了します。トランザクションがロールバックされると、正常に行われたすべての操作が取り消されます。
ローカルトランザクションの範囲は、常に単一セッションです。つまり、単一セッションのコンテキストで実行された、1 つ以上のプロデューサまたはコンシューマの操作は、単一のローカルトランザクションにグループ化されます。
トランザクションは 1 つのセッション内で行われるので、1 つの終端間トランザクションでメッセージのプロデュースとコンシュームの両方を行うことはできません。言い換えると、送信先へのメッセージの配信とそれに続くクライアントへのメッセージの配信は、同じトランザクション内に入れることができません。
分散トランザクション
JMS 仕様では、分散トランザクションもサポートしています。つまり、メッセージのプロデュースとコンシュームは、データベースシステムなど、ほかのリソースマネージャに関連した操作を含む大容量の分散トランザクションの一部となります。分散トランザクションでは、Java Transaction API (JTA)、XA Resource API の仕様で定義された 2 フェーズコミットプロトコルを使用して、メッセージサービスやデータベースマネージャといった複数のリソースマネージャによって実行される操作を、分散トランザクションマネージャが追跡および管理します。Java の世界では、リソースマネージャと分散トランザクションマネージャ間の対話は、JTA の仕様で記述されます。
分散トランザクションをサポートするということは、メッセージングクライアントが、JTA で定義される XAResource インタフェースを介して分散トランザクションに加わることができるということです。このインタフェースでは、2 フェーズコミットを実装するための、数多くのメソッドが定義されます。API の呼び出しがクライアント側で行われている間、JMS メッセージサービスは分散トランザクション内のさまざまな送受信操作やトランザクションの状態を追跡し、Java Transaction Service (JTS) で提供される分散トランザクションマネージャと一致したときにだけ、メッセージング操作を完了します。
ローカルトランザクションに関しては、無視したり、操作を試行し直したり、分散トランザクション全体をロールバックしたりして、クライアントは例外を処理できます。
持続ストレージ
信頼性のもう 1 つの面は、メッセージサービスが持続メッセージをコンシューマに配信する前に、その持続メッセージを失うことがないようにすることです。つまり、持続メッセージが物理的な送信先に到達したら、メッセージサーバーはそのメッセージを持続データストアに保管する必要があります。何かの理由でメッセージサーバーが停止した場合、持続データストアはメッセージを復元し、適切なコンシューマに配信します。
メッセージサーバーは、永続サブスクリプションも持続的に格納する必要があります。持続的に格納しないと、障害が発生した場合、メッセージサーバーはメッセージがトピック送信先に到達したあとにアクティブになる永続サブスクライバにメッセージを配信できなくなります。
メッセージ配信を保証するメッセージングアプリケーションは、メッセージを持続的として指定し、永続サブスクリプション状態のトピック送信先またはキュー送信先のいずれかにメッセージを配信する必要があります。
JMS 管理対象オブジェクト
JMS プログラミングモデルで使用されるオブジェクトの中の 2 つであるコネクションファクトリと送信先は、プロバイダの JMS 仕様の実装方法によって異なります。
クライアントの移植性を維持しながら、プロバイダがこれらのオブジェクトを定義する場合の柔軟性を最大限に引き出せるようにするため、JMS 仕様では、プロバイダ固有情報をカプセル化する管理対象オブジェクトをコネクションファクトリと送信先用に定義しています。これらのオブジェクトは、管理者によって設定され、JNDI ネームスペース (オブジェクトストア) に格納されます。クライアントは、標準 JNDI 検索コードを介して管理対象オブジェクトにアクセスします。
管理対象オブジェクトにより、JMS クライアントはプロバイダ固有オブジェクトを検索および参照するための論理名を使用できます。この方法では、クライアントコードで、特定の命名構文やアドレス指定構文、またはプロバイダによって使用される設定可能なプロパティについて意識する必要はありません。これにより、クライアントコードはプロバイダに依存しなくなります。
「管理対象オブジェクト」には、Message Queue で使用される管理対象オブジェクトに関する補足情報があります。
注
JMS 仕様では、JNDI 検索を使用して管理対象オブジェクトにアクセスする必要はありません。クライアントコードにより、コネクションファクトリオブジェクトと送信先オブジェクトをインスタンス化し、その属性の値を設定できます。ただし、クライアントコードは他のプロバイダに移植できません。
