MQ4.1を使ってみよう！第1回 JMS概要
前回からちょっと時間が空いてしまいましたが、何回かに分けてMQ4.1の仕様、インストール方法、使い方、HA構成方法、パフォーマンスチューニングなどについて書いてみたいと思います。
まずは第一回目ということで、今回リリースされたSun Java System Message Queue4.1 Enterprise Editionが実装しているJMSの概念についてちょっと復習してみたいと思います。
JMSはJava Message Serviceの略語で、Javaでメッセージング機能を利用するための仕様のことです。JMSはJava Enterprise Editionに含まれていて、エンタープライズ向けのメッセージを利用したモジュール間のデータ通信に利用されます。メッセージの中身はテキストデータだったり、XMLデータだったり、ファイルなどのバイナリデータだったりと様々です。
エンタープライズレベルのメッセージ交換に求められる要件はいくつもありますが、代表的なものを挙げると以下の機能があります。
・配信保証（相手に確実に、重複せずにデータメッセージを届ける）
・トランザクション
・セキュリティ
・ログ
・非同期処理
・疎結合（相手との直接通信ではなく、間にシステムを挟むことによって柔軟な構成が可能、
将来相手先が変わったときにも柔軟に対処可能）
金融業など、１つ１つの処理が非常にクリティカルな場合、マシンがどのような状態になっても確実に処理を完了させる必要があります。ここではそのようなエンタープライズレベルのアプリケーションを開発する場合を例にとって、MQ4.1を使った場合のメッセージングと使わなかった場合の[自力]メッセージングについてみてみましょう。
上の図を見てください。MQを使わない場合は、エンタープライズ要件を満たすための機能を送信元と送信先のモジュール自体に持たせる必要があります。通常はプログラムで１つ１つの機能を記述する必要がありますが、要件を考えると１つの製品を開発するのと同じくらいの労力が必要です。通信することはできても、データの永続化やトランザクションなどを個々のプログラムで実装していくのはおよそ現実的ではありません。
これに対してMQを使用した場合が下の図になります。配信保証やトランザクション処理、メッセージの暗号化機能などはMQ側に実装されており、通信元や通信先は一切機能を作りこむ必要がありません。既に提供されているJMS-APIを使ってMQにデータを送信/受信するだけです。
送受信時にはトランザクションがサポートされているので、万が一処理中にマシンがクラッシュしても
メッセージの送受信に関しては整合性のある状態が保たれます
（データ欠けなど中途半端な状態でメッセージが送受信されることはない）
またメッセージの永続化機能があるので、一度MQへ送信されたメッセージはMQブローカが何らかの理由で停止してしまっても常に永続ストアにメッセージが保持されているので消えてしまったりすることはありません。
MQブローカが再起動すると自動的に永続ストアからメッセージが復元されます。
その他、サービス/データの可用性を高めるためにMQブローカをクラスタ構成にすることができます。クラスタ機能についての説明はHA構成の回で行う予定です。
＃メッセージの仲介をするプログラムのことをブローカと呼びます。
MQ製品は単独で使うというよりも、EAI製品などの基盤機能として働き、メッセージ交換や配信保証手段として利用されていることも多くあります。SunのEAI/ESB製品であるSun Java CAPS(旧Seebeyond)などはデフォルトのMQのほかにSun Java System Message Queueも利用することが可能です。また配信保証付きのWebサービスなどはベースにJMSを使っているものがほとんどです。（SOAP over JMS)
次回は、JMSの送受信タイプについて説明します。