メッセージ・キューイングの概要

IBM® MQ 製品により、プログラムは、一貫性のあるアプリケーション・プログラミング・インターフェースを使用して、異なるコンポーネント (プロセッサー、オペレーティング・システム、サブシステム、および通信プロトコル) のネットワークを介して相互に通信することができます。

メッセージングキューイング のスタイルをとるため、このインターフェースを使用して設計、作成されるアプリケーションをメッセージ・キューイング・アプリケーションといいます。
  • メッセージングでは、プログラムは、相互に直接呼び出す代わりに、メッセージでデータを送信し合うことにより通信します。
  • キューイングでは、メッセージがストレージ内のキューに配置されるので、複数のプログラムが互いに独立して、異なるスピードで、異なる時刻に、異なる場所で、プログラム間の論理接続をもたずに稼働できるようになります。

メッセージ・キューイングはデータ処理の分野で長年用いられてきました。 現在では、電子メールの分野で広く使われています。 キューイングがない場合、電子メッセージをリモート側で送信するには、経路上のすべてのノードがメッセージを転送でき、受信局をログオンさせて、メッセージを送信しようとしていることを常に認識させることが必要です。 キューイング・システムでは、メッセージはシステムがそれを転送できるようになるまで中間ノードに格納されます。 最終の宛先では、受信局が読み取り可能になるまで、メッセージは電子メールボックスに格納されます。

しかし、今日では多くの複雑な業務トランザクションがキューイングを使用しないで処理されています。 大規模ネットワークでは、システムが膨大な数の接続を使用可能な状態にしていなければなりません。 システムの一部で問題が発生すると、システムの多くの部分が使用できなくなります。

メッセージ・キューイングは、プログラム用の電子メールと考えることができます。 メッセージ・キューイング環境では、アプリケーション・スイートの各部分を構成するそれぞれのプログラムが、特定の要求に応答する形で、明確に定義された自己完結型の機能を実行します。 他のプログラムと通信するには、プログラムは事前定義キューにメッセージを書き込む必要があります。 他のプログラムは、そのメッセージをキューから取り出し、そこに入っている要求や情報を処理します。 このため、メッセージ・キューイングはプログラム間通信の 1 つのスタイルと言えます。

キューイングとは、アプリケーションがメッセージの処理が行えるようになるまでメッセージを保留する機能のことです。 キューイングによって次のことが可能になります。
  • 通信コードを記述することなく、プログラム間で通信を行うことができる (これらのプログラムはそれぞれ異なった環境で実行中でも構わない)。
  • プログラムがメッセージを処理する順序を選択することができる。
  • メッセージの数がしきい値を超えるときは、複数のプログラムが 1 つのキューをサービスするようにして、システム上の負荷のバランスをとることができる。
  • 基本システムが使用不可のときは、代替システムがキューをサービスするようにして、アプリケーションの使用可能度を向上させることができる。

メッセージ・キューとは

メッセージ・キューは、単にキューと呼ばれており、メッセージを送信することができる名前付きの宛先です。 メッセージは、それらのキューを取り扱うプログラムによって取り出されるまで、キューに蓄積されます。

キューはキュー・マネージャーに常駐し、キュー・マネージャーによって管理されます ( メッセージ・キューイングの用語 を参照)。 キューの物理的な特性は、キュー・マネージャーが実行されているオペレーティング・システムに依存します。 キューはコンピューターのストレージ内の揮発性バッファー域にあっても、あるいはディスクなどの永続記憶装置上のデータ・セットにあっても構いません。 キューの物理的な管理は、キュー・マネージャーの役目であり、関連するアプリケーション・プログラムには明らかにされません。

プログラムは、キュー・マネージャーの外部サービスを通じてのみキューにアクセスします。 外部サービスは、キューのオープン、キューへのメッセージの書き込み、キューからのメッセージの読み取り、およびキューのクローズを行うことができます。 また、キューの属性を設定したり、照会したりすることもできます。

さまざまなスタイルのメッセージ・キューイング

Point-to-Point

1 つのメッセージがキューに入れられ、1 つのアプリケーションがそのメッセージを受け取ります。

Point-to-Point メッセージングでは、送信側アプリケーションが受信側アプリケーションにメッセージを送信する前に、送信側アプリケーションが受信側アプリケーションについての情報を認識している必要があります。 例えば、送信側アプリケーションは、情報を送信するキューの名前を認識していて、キュー・マネージャー名を指定しなければならない場合があります。

パブリッシュ/サブスクライブ

パブリッシング・アプリケーションによってパブリッシュされた各メッセージのコピーは、各インタレスト・アプリケーションに送信されます。 インタレスト・アプリケーションは多数ある場合も、1 つある場合も、まったくない場合もあります。 パブリッシュ/サブスクライブでは、インタレスト・アプリケーションはサブスクライバーと呼ばれ、メッセージはサブスクリプションによって識別されるキューに入れられます。

パブリッシュ/サブスクライブ・メッセージングを使用すると、情報の提供者とその情報の利用者 を分離することができます。 送信側アプリケーションと受信側のアプリケーションは、情報を送受信するために、お互いについて何も知る必要がありません。 詳しくは、 パブリッシュ/サブスクライブ・メッセージングを参照してください。

アプリケーションの設計担当者および開発者にとってのメッセージ・キューイングの利点

IBM MQ により、アプリケーション・プログラムは メッセージ・キューイング を使用して、メッセージ・ドリブン処理に参加することができます。 適切なメッセージ・キューイング・ソフトウェア製品を使用すれば、プラットフォームが異なっていても、アプリケーション・プログラム相互間で通信することができます。 例えば、 z/OS® アプリケーションは IBM MQ for z/OSを介して通信できます。 アプリケーションは、基礎となる通信機構からは保護されています。 その他に、メッセージ・キューイングには次のような利点があります。
  • 多くのアプリケーション間で共用できる小規模のプログラム群を使用して、アプリケーションを設計できる。
  • これらの構築ブロックを再使用することによって、新しいアプリケーションを速やかに構築できる。
  • メッセージ・キューイング技法を用いるため作成されたアプリケーションは、キュー・マネージャーの作業の仕方が変更されても影響を受けない。
  • 通信プロトコルを使用する必要がない。 キュー・マネージャーが通信のすべての局面を処理します。
  • メッセージを受信するプログラムは、メッセージが送信されてくる時に実行中である必要はない。 これらのメッセージはキューに保存されます。

設計担当者はアプリケーションのコストを下げることができます。なぜなら、開発の速度が速くなり、開発担当者の必要人数が少なくてすみ、しかもメッセージ・キューイングを使わないアプリケーションの場合よりもプログラミング・スキルの要求レベルが低いからです。

IBM MQ は、アプリケーションがどこで実行されていても、 メッセージ・キュー・インターフェース (または MQI) と呼ばれる共通アプリケーション・プログラミング・インターフェースを実装します。 このため、アプリケーション・プログラムを、あるプラットフォームから 別のプラットフォームに移植するのが容易になります。

MQI について詳しくは、 メッセージ・キュー・インターフェースの概要を参照してください。