blog

JMS

JMS(Java Message Service API)は、Javaプラットフォーム上のメッセージング・ミドルウェアのための標準化されたJavaAPIインターフェースのセットで、非同期通信のために2...

Oct 9, 2020 · 4 min. read
シェア

JMSとは?

JMS(Java Message Service)とは、Java Message Service Application Programming Interfaceの略で、非同期通信のために2つのアプリケーションや分散システム間でメッセージを送信するための標準化されたJavaAPIインターフェースのセットで、メッセージングミドルウェアのためのJavaプラットフォームです。

JMS的作用:

JMS APIに基づいて書かれたプログラムが、どのようなモデルにも適用できるように共通のインターフェースを提供することで、メッセージキュー・プロバイダが変わっても、アプリケーション関連のコードをあまり変更する必要がないようにします。

アナロジー

AMQP や STOMP などのプロトコルをサポートするメッセージ・ミドルウェア製品に接続するために JMS API を使用します。この点では、特定のデータベース製品にアクセスするために使用できる Java の JDBC の役割に非常に似ています。

歴史的なバージョン

JMSのこの仕様はSUNによって提案され、現在使用されている主なバージョンは2つあります:

ひとつは2002年にリリースされたバージョン1.1。

一つは2013年にリリースされたバージョン2.0です。

JMSはメッセージキューイングプロトコルではなく、メッセージキューイング製品は言うに及ばず、プラットフォームに依存しないAPIであり、市場のメッセージングミドルウェアベンダーの大部分はJMSインタフェース仕様をサポートしています。

JMSメッセージモデル

2つのメッセージキューモデル:ピアツーピアとパブリッシュ/サブスクライブの2つの方法で

ポイントツーポイントモデル

  • ピアツーピアモデルでは、アプリケーションはキュー、送信者、受信者で構成されます。

  • 各メッセージは特定のキューに送信され、受信者はキューからメッセージを取得します。メッセージは、受信されるかタイムアウトするまでキューに残ります。

ピアツーピアモデルの特徴は以下の通りです:

  • 各メッセージの受信者は1つだけで、一度受信したメッセージはメッセージ・キューには残りません。送信者と受信者の間に時間的な依存関係はありません。つまり、いったんメッセージが送信されると、受信者が実行中であろうとなかろうと、キューに送信されるメッセージには影響しません。

  • 各メッセージは1つの受信者のみに配送されます。つまり、ある待ち行列で複数のレシーバが listen していることがありますが、そのメッセージを受信できるのは、その待ち行列に含まれる 1つのレシーバだけです。

  • メッセージは連続したものです。キューは、メッセージサーバがキューに入れた順番に、レシーバにメッセージを配送します。メッセージは、すでに受信された時点で、キューの先頭から削除されます。

  • 受信者がメッセージを受信すると、受信確認を送信します。

一般的に、ピアツーピア・モデルは、送信されたすべてのメッセージが正常に処理されることを望む場合に使用されます。

パブリッシュ/サブスクライブ・モデル
  • Publish/Subscribeモデルでは、アプリケーションはトピック、パブリッシャー、サブスクライバーで構成されます。

  • パブリッシャはメッセージを発行し、そのメッセージはトピックを通じてすべてのサブスクライバに配信されます。

  • このモデルでは、パブリッシャーとサブスクライバーはお互いを知らず、匿名であり、動的にトピックをパブリッシュしたりサブスクライブしたりすることができます。

  • トピックはメッセージの保存と配信に使われ、購読者に配信されるまでメッセージを保持します。

Publish/Subscribeモデルの特徴は以下の通りです:

  • 各メッセージは複数の購読者を持つことができます。

  • パブリッシャーとサブスクライバーの間には時間的な依存関係があります。

  • 通常、トピックのサブスクライバは、メッセージを受信する前にサブスクリプションを作成する必要があります。

  • JMS では、サブスクライバが永続的なサブスクリプションを作成できるため、サブスクライバが実行中でなくてもサブスクライブしたメッセージを受信できます。

  • 各メッセージはそのトピックの下にある全てのサブスクライバーに配信されます。

  • 通常、パブリッシャーはどのサブスクライバーがメッセージを受信しているのか知りません。

そのため、送信されたメッセージを何の処理もせずに、あるいは 1 つ以上のサブスクライバーに処理させたい場合は、パブリッシュ/サブスクライブモデルを使うことができます。

ConnectionFactory インターフェース

ConnectionFactoryは、Connectionオブジェクトを作成するファクトリです。 メッセージの種類に応じて、QueueConnectionFactoryまたはTopicConnectionFactoryを選択できます。 JNDIを使用して、ConnectionFactoryオブジェクトを見つけることができます。ConnectionFactory オブジェクトを見つけるには、JNDI を使用します。

デスティネーション・インターフェイス

Destination は、メッセージ宛先識別子でラップされた管理オブジェクトです。 メッセージの宛先は、キューまたはトピックとして、メッセージが発行されたり受信されたりする場所です。メッセージ・プロデューサの場合、その宛先はキューまたはトピックです。メッセージ・コンシューマの場合、その宛先もキューまたはトピックです。 つまり、Destinationは実際にはキューとトピックという2つのタイプのオブジェクトであり、JNDIを通じてDestinationを見つけることができます。

セッションインタフェース

セッションは実際にメッセージを操作するインタフェースで、メッセージを送受信するシングルスレッド・コンテキストを表します。セッションはシングルスレッドなので、メッセージは送信された順に 1 つずつ受信されます。プロデューサー、コンシューマー、メッセージなどは、セッションを通じて作成できます。この仕様では、セッションはトランザクション機能も提供します。 セッションはまた、キュー・セッションとデイリー・トピック・セッションの2つのタイプに分けられます。

MessageProducer インターフェース(メッセージ・プロデューサー)

メッセージ・プロデューサーは、セッションによって作成され、Destination にメッセージを送信するために使用されます。 コンシューマーは、キュー・タイプとトピック・タイプのメッセージを同期または非同期で受け取ることができます。メッセージ・プロデューサーには、QueueSenderとTopicPublisherの2種類があります。

メッセージインターフェース

メッセージは、コンシューマとプロデューサの間で転送されるオブジェクトです。

メッセージリスナー

メッセージリスナーが登録されている場合、メッセージが到着すると、リスナーの onMessage メソッドが自動的に呼び出されます。

Read next

センチネルにおけるコールドスタート流量制限アルゴリズム

コールドスタートアルゴリズムはトークンバケットアルゴリズムに基づいて実装されています。 トークンバケットアルゴリズムの原理は、トークンを一定の割合でトークンバケットに入れ、リクエストを受信したらトークンバケットからトークンを申請し、トークンを得たリクエストのみが通過します。トークン・バケツがいっぱいになると、余分なトークンは破棄され、バケツが空になると、トークンを獲得できないリクエストは拒否されます。 例えば、トークンバケットアルゴリズムを使って、あるインターフェイスの 最大QPSを20に制限したいとします。

Oct 9, 2020 · 4 min read