1. メッセージングとは

“メッセージング” という言葉は、コンピュータの世界のさまざまな場面で広く使われています。例えば、OS のコンセプトを説明する場面や e-メール システムを説明する場合にも使われています。

ここで説明するメッセージングとは、JMS におけるメッセージングを指し、アプリケーション間の非同期通信 を説明する言葉として用いています。

また、”メッセージ” とは、非同期に送受信される情報データ、リクエスト、レポート、イベントなどを指し、人間ではなくアプリケーション ソフトウェアによってコンシューム (受信、処理) されるものを指してしています。

今回は、JMS をメッセージングのプロトコルとして使用することの意味について考察します。

1.1 JMS を使用することの意味

JMS (Java メッセージ サービス) とは、MOM (Message Oriented Middle-ware: メッセージ指向ミドルウェア) にアクセスするための Java プログラム用の API を定めた標準規格です。JMS 規格では、JMS メッセージング モデル (セマンティクス) に基づいて MOM にアクセスするための API インタフェースが定められています。標準規格として確立された JMS は、企業のメッセージング インフラの基礎を築くのに最適なものとなっています。

JMS のメッセージング モデルは、以下の特徴 (利点) を有しています。

• ストア&フォワード メカニズムによる疎結合
• 2 種類のドメインによる非同期メッセージング (同期メッセージングも可)
  • ポイント・ツー・ポイント (PTP)
  • パブリッシュ-サブスクライブ (Pub/Sub))
• メッセージ配信の保証
• メッセージの永続化
• Java によるインターオペラビリティ
• 他の Java API (JDBC, EJB, JTA, JTS, JNDI など）との連携

 

1.2 ストア&フォワード メカニズムによる疎結合

JMS で定義されているメッセージング システムの環境は、図 のようになっています。

 

 

 

 

 

 

 

メッセージを送り出すクライアント (メッセージ プロデューサ) は、JMS サーバーにメッセージを送信します。相手側のアプリケーションに対して送るのではありません。メッセージは、JMS サーバー上の “ディストネーション” を宛先として送られ、ディストネーション上に格納されます。メッセージを受け取る側のクライアント (メッセージ コンシューマ) は、ディストネーションにメッセージが存在すれば、それをコンシュームします (受け取ります)。プロデューサ側もコンシューマ側も相手のことを関知する必要がなく、おたがいにアノニマス (anonymous) な関係にあります。

• JMS クライアント
  JMSクライアントは、JMS API (クライアント ランタイム) を使用してメッセージを送受信するプログラムです。メッセージの送り側も受け側もクライアントであり、両者の間に “サーバー” と “クライアント” という区別が無いことに留意してください。両者ともメッセージング サービスを利用するクライアントとして位置付けられています。 このことは、アプリケーション間 (メッセージの送信側と受信側) に強い関係が無いことを意味しています。
• JMS サーバー
  JMS サーバーとは JMS を実装した MOM (メッセージ指向ミドルウェア) のことで、FioranoMQ など多くの製品がソフトウェア ベンダーからリリースされています。
  MOM 製品は、また、JMS クライアントを作成するための JMS API に基づいたクライアント ランタイム (ライブラリ) も提供しています。
• ディストネーション
  JMS サーバーが管理するオブジェクトの一つで、プロデューサが送るメッセージの宛先となります。ディストネーションに送られてきたメッセージは、ここに格納され、コンシューマがコンシューム (受信) するまで保持されます。
  JMS サーバーは、ディストネーションを用いて、いわゆる “ストア&フォワード” のメカニズムを実装していることになります。

 

JMS の “ストア&フォワード” メカニズムは、アプリケーション間の結びつきを “疎結合” なものとします。

疎結合なメッセージングは、次のような大きな利点をもたらします。

• アプリケーション間の非同期な連携
  CORBA に代表されるような RPC (Remote Procedure Call) では、通信を行うアプリケーションが同時に稼動している必要があります。また、アプリケーション間で同期をとるため、相手アプリケーションの処理状況に連動していなければなりません (例えば、リクエストの処理結果を受け取るまで待機するなど)。
  これと異なり、非同期な連携では次の利点が得られます。
  • 相手側アプリケーションに障害 (ネットワーク障害やアプリケーション自体の障害) が発生していても、メッセージを送信できる
  • ディストネーションにメッセージを送った直後から、次の処理に移行できる
• 耐障害性
  ネットワーク障害などによってコンシューマがメッセージを受け取れない場合でも、ストア&フォワード メカニズムによってメッセージを保存しておくことができ、メッセージを損失することがありません。障害が解消した時点で、メッセージの処理を再開できます。このことは、一方のアプリケーションに障害が発生しても、他方のアプリケーションは処理を継続できることを意味し、システム全体が停止してしまうことがありません。
• システム変更の容易性
  非同期に連携している環境では、アプリケーションの変更や他のアプリケーションとの置き換えの必要が生じても、相手アプリケーションに大きな影響をおよびしません。また、変更時にシステム全体を停止する必要がなくなります。