test

Sun Java System Message Queue 3.7 UR1 技術の概要

信頼性の高いメッセージング

メッセージ配信は 2 つのステップで行われます。最初のステップでは、プロデューサからブローカ上の物理的な送信先へメッセージが送られます。次のステップでは、その送信先からコンシューマへメッセージが送られます。このように、メッセージは、ブローカへの移動、ブローカに障害が発生した場合にブローカのメモリーに格納されている間、ブローカからコンシューマへの移動という 3 つのいずれかの段階で消失する可能性があります。信頼性の高い配信は、これらのどの段階でも配信が失敗しないように保証します。ブローカに障害が発生した場合、非持続メッセージは常に消失する可能性があるので、信頼性の高い配信は持続メッセージにのみ該当します。

信頼性の高い配信を確保するために、次の 2 つのメカニズムが使用されます。

次の節では、信頼性を確保する場合の 2 つの側面について説明します。

通知

通知は、信頼性の高いメッセージの配信を確実に行うために、クライアントとメッセージサービスの間で送信されるメッセージです。通知は、プロデューサとコンシューマとでは使用方法が異なります。

メッセージがプロデュースされる場合、ブローカは、メッセージを受信し、送信先に保管し、持続的に保存したことを通知します。プロデューサの send() メソッドは、通知を受信するまでブロックします。持続メッセージが送信されるとき、これらの通知はクライアントからは見えません。

メッセージがコンシュームされる場合、クライアントは、ブローカが送信先からメッセージを削除する前に、送信先から配信されたメッセージを受信し、コンシュームしたことを通知します。JMS では、違うレベルの信頼性を表す別の通知モードを規定しています。

信頼性よりもパフォーマンスを重視するクライアントの場合、Message Queue サービスでは、NO_ACKNOWLEDGE モードを用意することにより、JMS API を拡張しています。このモードでは、ブローカはクライアント通知を追跡しないので、メッセージがコンシューミングクライアントによって正常に処理されたかどうか保証されません。このモードを選択した場合、非永続サブスクライバへ送信される非持続メッセージのパフォーマンスが向上します。

トランザクション

トランザクションとは、1 つ以上のメッセージのプロデュースまたはコンシューム、あるいはその両方を 1 つの極小の単位にグループ化する方法です。前述のクライアントとブローカの通知プロセスは、トランザクションにも適用されます。この場合、クライアントランタイムおよびブローカ通知は、トランザクションのレベルで自動的に処理されます。トランザクションがコミットされると、ブローカの通知が自動的に送信されます。

セッションは処理済みとして設定でき、JMS API には、トランザクションの開始、コミット、またはロールバックを行うメソッドが用意されています。

メッセージがトランザクション内でプロデュースまたはコンシュームされるに従って、メッセージサービスがさまざまな送受信を追跡し、JMS クライアントが呼び出しを実行してトランザクションを確定したときにだけ、送受信の操作を完了させます。トランザクション内での特定の送信や受信の操作が失敗すると、例外が発生します。クライアントコードは、これを無視するか、操作を試行し直すか、またはトランザクション全体をロールバックして、例外を処理できます。トランザクションがコミットされると、すべての操作が完了します。トランザクションがロールバックされると、正常に行われたすべての操作が取り消されます。

トランザクションの範囲は、常に単一セッションです。つまり、単一セッションのコンテキストで実行された、1 つ以上のプロデューサまたはコンシューマの操作は、単一のトランザクションにグループ化されます。トランザクションは 1 つのセッション内で行われるので、1 つの終端間トランザクションでメッセージのプロデュースとコンシュームの両方を行うことはできません。

JMS 仕様では、分散トランザクションもサポートしています。つまり、メッセージのプロデュースとコンシュームは、データベースシステムなど、ほかのリソースマネージャーに関連した操作を含む大容量の分散トランザクションの一部となります。分散トランザクションをサポートするには、Java Systems Application Server が提供するトランザクションマネージャーなどを入手する必要があります。

分散トランザクションでは、Java Transaction API (JTA)、XA Resource API の仕様で定義された 2 フェーズコミットプロトコルを使用して、メッセージサービスやデータベースマネージャーといった複数のリソースマネージャーによって実行される操作を、分散トランザクションマネージャーが追跡および管理します。Java の世界では、リソースマネージャーと分散トランザクションマネージャー間の対話は、JTA の仕様で記述されます。

分散トランザクションのサポートとは、メッセージングクライアントが、JTA で定義される XAResource インタフェースを介して、分散トランザクションに加わることができるということです。このインタフェースでは、2 フェーズコミットを実装するための、数多くのメソッドが定義されます。API の呼び出しがクライアント側で行われている間、JMS メッセージサービスは分散トランザクション内のさまざまな送受信操作やトランザクションの状態を追跡し、Java Transaction Service (JTS) で提供される分散トランザクションマネージャーと一致したときにだけ、メッセージング操作を完了します。ローカルトランザクションに関しては、無視したり、操作を試行し直したり、分散トランザクション全体をロールバックしたりして、クライアントは例外を処理できます。

注 –

Message Queue では、Java Enterprise Edition プラットフォームで JMS プロバイダとして使用される場合にのみ、分散トランザクションをサポートします。分散トランザクションの使用方法について詳しくは、各 Application Server プロバイダによって提供されるマニュアルを参照してください。

持続ストレージ

信頼性のもう 1 つの側面は、ブローカが持続メッセージをコンシューマに配信する前に、その持続メッセージを失うことがないようにすることです。つまり、メッセージが物理的な送信先に到達したら、ブローカはそのメッセージを持続データストアに保管する必要があります。何かの理由でブローカが停止した場合、持続データストアはあとからメッセージを復元し、適切なコンシューマに配信します。

ブローカは、永続サブスクリプションも持続的に保存する必要があります。持続的に保存しないと、障害が発生した場合、ブローカは、メッセージがトピック送信先に届いたあとにアクティブになった永続サブスクライバにメッセージを配信できなくなります。

メッセージ配信を保証するメッセージングアプリケーションは、メッセージを持続的として指定し、永続サブスクリプション状態のトピック送信先またはキュー送信先のいずれかにメッセージを配信する必要があります。

第 3 章「Message Queue サービス」では、Message Queue サービスで用意されているデフォルトのメッセージストアと、管理者による代替ストアのセットアップおよび設定方法について説明します。