IBM MQ

IBM MQは、 IBM が1993 年 12 月に発表したメッセージ指向ミドルウェア製品ファミリーです。当初はMQSeriesと呼ばれていましたが、 2002 年にWebSphere製品スイートに加わるためWebSphere MQに名前が変更されました。2014 年 4 月にIBM MQに名前が変更されました。MQ ファミリーに含まれる製品は、IBM MQ、IBM MQ Advanced、IBM MQ Appliance、IBM MQ for z/OS、および IBM MQ on IBM Cloud です。IBM MQ には、コンテナー化されたデプロイメント オプションもあります。

MQ を使用すると、分散システム上の独立した非同時実行の可能性のあるアプリケーションが、メッセージを使用して安全に相互通信できます。MQ は、 z/OS (メインフレーム)、IBM i、Transaction Processing Facility、UNIX ( AIX、HP-UX、Solaris )、HP NonStop、OpenVMS、Linux、Microsoft Windowsなど、多数のプラットフォーム(IBM および非 IBM の両方) で使用できます。

MQ のコア コンポーネントは次のとおりです。

• メッセージ: メッセージは、参加プログラムにとって何らかの意味を持つバイナリまたは文字 ( ASCIIやEBCDICなど) データの集合です。他の通信プロトコルと同様に、ストレージ、ルーティング、および配信情報は送信前にメッセージに追加され、受信側アプリケーションに配信される前にメッセージから削除されます。
• キュー:メッセージ キューは、アプリケーション内のメッセージを保存するオブジェクトです。
• キュー マネージャー: メッセージ キューの論理コンテナーを提供するシステム サービス。メッセージ チャネルを介して他のキュー マネージャーにデータを転送する役割を担います。メッセージ指向ミドルウェアには厳密には必要ではありませんが、IBM MQ の前提条件です。キュー マネージャーは、ストレージ、タイミングの問題、トリガー、および実際のデータ移動に直接関係のないその他のすべての機能を処理します。

IBM MQ と統合されたプログラムは、すべてのプラットフォームにわたって一貫したアプリケーション プログラム インターフェース (API) を使用します。

MQ は、ポイントツーポイントおよびパブリッシュ サブスクライブメッセージングをサポートします。

IBM が直接サポートする API には次のものがあります。

• C、COBOL、PL/I、Java、Rexx、^[1] RPG、C++用のIBMメッセージキューインターフェース（MQI）
• Java メッセージ サービス(JMS)
• C/C++および.NET用のXMS ^[2]
• 。ネット
• 休む
• 石鹸

追加の API (公式にはサポートされていません) もサードパーティ経由で利用できます。これには以下が含まれます。

• Perlインターフェース（Hildo Biersmaによって開発および提供）、CPANから入手可能。^[3]
• PythonインターフェースPyMQI（元々はLes Smithsonによって開発され、PyPIから入手可能^[4]）
• パワーシェル^[5]

1 回限りの配信: MQ は 1 回限りの配信を使用します。このサービス品質により、通常、メッセージの損失や重複が防止されます。

非同期メッセージング: MQ は、アプリケーション設計者に時間に依存しないアーキテクチャを実現するためのメカニズムを提供します。アプリケーションが同時に実行されているかどうかに関係なく、メッセージを 1 つのアプリケーションから別のアプリケーションに送信できます。送信者がメッセージを送信したときにメッセージ受信側アプリケーションが実行されていない場合、キュー マネージャーは受信側が要求するまでメッセージを保持します。すべてのメッセージの順序は保持されます。デフォルトでは、これはメッセージの優先度内でローカル キューで受信されたFIFO順序です。

データ変換: たとえば、ビッグ エンディアンからリトル エンディアン、またはEBCDICからASCIIなど。これは、メッセージ データ出口を使用して実行されます。出口は、キュー マネージャー ホストで実行されるコンパイル済みアプリケーションであり、データ変換が必要なときに IBM MQ ソフトウェアによって実行されます。

メッセージ駆動型アーキテクチャ フレームワーク: IBM MQ では、メッセージを受信して​​他のアプリケーションの実行を「トリガー」できます。

API の範囲: Java Message Service (JMS) 標準 APIを実装し、JMS より数年前から存在する Message Queuing Interface (MQI) と呼ばれる独自の API も備えています。バージョン 8.0.0.4 以降、MQ は MQ Light API もサポートしています。

クラスタリング: 複数の MQ 実装がメッセージの処理を共有し、負荷分散を実現します。

キュー マネージャーは、次のいずれかの方法で外部と通信します。

• バインディング: 直接的なソフトウェア接続。一般的に高速ですが、キュー マネージャーと同じ物理ホスト上で実行されているプログラムに制限されます。
• ネットワークまたは「クライアント」接続: クライアント接続を使用するアプリケーションは、ネットワーク内の他のホスト上のキュー マネージャーに接続できます。キュー マネージャーの物理的な場所は、ネットワーク経由でアクセスできる限り、関係ありません。

これはチャネルに依存します。各キュー マネージャーは、1 つ以上のチャネルを使用して、他のキュー マネージャーとデータを送受信します。チャネルは単方向です。データを返すには 2 番目のチャネルが必要です。TCP/IP ベースのネットワークでは、チャネルは特定のポートでデータを送受信します。

チャネルタイプ:

• 送信チャネル: 宛先が定義されており、特定の送信キュー (チャネル上で送信を待機するメッセージをキューに入れるメカニズム) に関連付けられています。
• 受信チャネル: 同じ名前の送信チャネルを持つ他のキュー マネージャーからデータを受信します。

受信チャネルがメッセージを受信すると、そのメッセージがどのキュー マネージャーとキューに宛てられているかが調べられます。通信障害が発生した場合、問題が解決されると MQ は自動的に接続を再確立できます。

リスナーは、キュー マネージャーへのアプリケーションのネットワーク インターフェイスです。リスナーは、受信チャネルからの接続を検出し、送信チャネルから受信チャネルへの接続を管理します。TCP/IP ネットワークでは、リスナーは特定のポートで接続を「リッスン」します。

キューの種類:

• ローカル キュー: 処理を待機しているデータが格納される場所を表します。
• リモート キュー: 別のキュー マネージャー上のキューを表します。メッセージのルーティング メカニズムの要素の 1 つである宛先キューを定義します。
• クラスター キュー: クラスター内の任意のキュー マネージャーを介してアクセス可能なキューを表します。

メッセージはリモート キューに配置されます。メッセージは、チャネルに関連付けられた一時ストレージ送信キューに送られます。メッセージをリモート キューに配置すると、メッセージはリモート チャネルを介して送信されます。送信が成功すると、メッセージは送信キューから削除されます。メッセージを受信すると、受信側キュー マネージャーはメッセージを調べて、メッセージが自分宛てのものか、別のキュー マネージャーに送るものかを判断します。受信側キュー マネージャーの場合は、必要なキューがチェックされ、存在する場合は、メッセージはこのキューに配置されます。存在しない場合は、メッセージはデッド レター キューに配置されます。MQ には、さまざまな通信メディア間での効率的なデータ送信を管理する機能があります。たとえば、キュ​​ーが特定の深さに達するまで、メッセージをまとめてバッチ処理できます。

キューは FIFO ですが、送信者からのメッセージのコミットではなく、ローカル キューでの受信に基づいて順序付けされます。メッセージには優先順位を付けることができ、デフォルトでは、キューは到着順に優先順位が付けられます。メッセージがローカルに追加された場合にのみ、キューは追加順になります。メッセージのグループ化を使用すると、一連のメッセージが特定の順序になっていることを保証できますが、順序が重要な場合は、アプリケーションがメッセージにシーケンス データを配置するか、戻りキューを介してハンドシェイク メカニズムを実装する必要があります。実際には、順序は単純な構成で維持されます。

キュー マネージャーのもう 1 つの要素はログです。メッセージがキューに置かれるか、構成が変更されると、そのデータもログに記録されます。障害が発生した場合、ログは破損したオブジェクトとメッセージを再作成するために使用されます。障害が発生すると、永続的なメッセージのみが再作成され、「非永続的な」メッセージは失われます。非永続的なメッセージは、高速モードに設定されたチャネルを介して送信できますが、このモードでは、チャネル障害が発生した場合に配信が保証されません。

MQ は循環ログと線形ログの両方をサポートします。

キューから情報を取得するには、適切な間隔でキューをポーリングして利用可能なデータを確認するか、または MQ がイベントをトリガーしてクライアント アプリケーションがメッセージの配信に応答できるようにします。

IBM MQ は、可用性に対応するためのさまざまなソリューションを提供します。

複製データ キュー マネージャー (RDQM / 'Easy HA' - 分散のみの MQ Advanced): 浮動 IP アドレスを共有する 3 つのサーバー間の同期レプリケーション。

キュー マネージャー クラスター: 1 台以上のコンピューター上の 2 台以上のキュー マネージャーのグループがクラスターに定義され、自動相互接続が提供され、負荷分散と冗長性のためにキューをそれらの間で共有できるようになります。

キュー共有グループ (z/OS のみ): 共有キュー環境では、アプリケーションはキュー共有グループ内の任意のキュー マネージャーに接続できます。キュー共有グループ内のすべてのキュー マネージャーが同じ共有キュー セットにアクセスできるため、アプリケーションは特定のキュー マネージャーの可用性に依存しません。これにより、キュー マネージャーが停止しても、キュー共有グループ内の他のすべてのキュー マネージャーがキューの処理を続行できるため、可用性が向上します。

マルチインスタンス キュー マネージャー (バージョン 7.0.1 から使用可能): 同じキュー マネージャーのインスタンスが 2 台以上のコンピューター上に構成され、キューとメタデータが共有ストレージ上に置かれます。複数のインスタンスを起動すると、1 つのインスタンスがアクティブ インスタンスになり、他のインスタンスはスタンバイになります。アクティブ インスタンスに障害が発生すると、別のコンピューターで実行されているスタンバイ インスタンスが自動的に引き継ぎます。

以下の表はMQソフトウェアに適用されます。MQアプライアンスのファームウェアとハ​​ードウェアのライフサイクルの日付は、表のものとは異なります。^[11]

コンピュータの出現により、IBM はメッセージ交換のニーズに新しいテクノロジーを適用する機会を見出しました。

1960 年代初頭、IBM は、プログラム可能なメッセージ交換システムである IBM 7740 通信制御システムと IBM 7750 プログラム伝送制御を販売しました。

IBM System/360 は 1964 年 4 月に発表され、BTAMやQTAM (Basic and Queued Telecommunications Access Methods) などの通信アクセス方式が導入されました。1971 年には、TCAM (Telecommunications Access Method ) によって、より高度な形式のメッセージ交換またはメッセージ ルーティングがユーザーに提供されました。TCAM は、特に金融業界や証券業界で広く受け入れられました。後の MQ と同様に、非同期メッセージングがサポートされていました。その後すぐに、TCAM 3.0 では、MQ と同様に、回復用に再利用可能なディスク メッセージ キューが追加されました。高水準の PL/I プログラムを使用して、TRANSIENT データセット (動的メッセージ キュー) にアクセスできます。一時データセットからメッセージを読み取ると、MQ による非ブラウズ READ と同様に、そのメッセージがキューから削除されます。

1970 年代後半には、トランザクション管理システムが誕生し、それぞれが業界で主導的地位を獲得しようとしました。IBM では、トランザクション管理のニーズに対応するために、 CICSとIMSが戦略的製品として選ばれました。CICS と IMS の両方に、それぞれ独自のメッセージ交換バージョンがあり、IMS はフロントエンドのキュー システムであり、CICS はメッセージ交換の基盤として一時データ機能を備えていました。^{[引用が必要]}

CICS は、1968 年から 1971 年にかけて、人気のトランザクション管理システムとしての地位を確立しました。メッセージ処理機能のために TCAM を採用したユーザーは、CICS と TCAM を組み合わせて使用​​することを望んでいました。1971 年 12 月、IBM は CICS/OS 標準製品の一部として CICS が TCAM をサポートすることを発表しました。これは 1972 年 12 月に提供される予定です。関心のある顧客は、これにより、TCAM をメッセージ処理の強みとして使用できるようになり、TCAM に接続された端末またはコンピューターを CICS オンライン アプリケーションとインターフェイスさせることもできます。^{[引用が必要]}

1973 年 1 月、TCAM は CICS/OS 標準バージョン 2.3 で引き続きサポートされました。ただし、1973 年 2 月に発表され 1974 年 6 月に提供された CICS/VS の最初のリリースでは、TCAM サポートは省略されました。言うまでもなく、多くの CICS-TCAM 顧客は、この製品の方向性に満足していませんでした。

CICS-TCAM の顧客からの強い要望により、1974 年 9 月の時点で、CICS の TCAM サポートは CICS/VS 1.1 製品で復活しました。以前の DCB サポートに加えて、この TCAM サポートの復活により、CICS は VTAM 経由の TCAM アクセス (ACB サポートとも呼ばれる) のサポートを開始しました。CICS TCAM ACB サポートは、1990 年の CICS/ESA バージョン 3 製品で廃止されました。

1992 年、IBM は MQSeries という新製品を発表しました。このブランド名は、WebSphere ファミリー名と製品をサポートするために、2002 年に WebSphere MQ に改名されました (ただし、正式な短縮名は MQ のままです)。2014 年に、IBM MQ に改名されました。MQ は、IBM のみのシステムから他のすべてのプラットフォームへの TCAM 機能の拡張となるはずでした。MQ には、異機種システムが相互に通信できるようにするアーキテクチャがあります (IBM、HP、Sun、Tandem など)。MQ を CICS システムで使用すると、他の MQ 対応システムとの間でデータを送受信できます。MQ を使用して CICS システムで作業を開始したり、CICS トランザクションを使用して別の CICS システムまたは非 CICS システムで作業を開始したりできます。

IBM MQは現在80種類の環境をサポートしており、業界をリードするメッセージ保証配信スイッチング/ルーティング製品となっています。^[12]

IBM MQ は、サービス指向アーキテクチャーを作成するための基盤として使用できます。MQ を使用してレガシー プログラムを機能するWeb サービスに変換するのに役立つ追加の製品オプションがいくつかあります。大規模で異機種混在の企業は、多くの場合、事業分野、機能、またはガバナンス領域に基づいた、ある程度自律的なドメインの連合として現れます。このような環境では、一部のサービスは単一のドメイン内でのみ共有または再利用される可能性がありますが、他のサービスは企業全体で共有または再利用される可能性があります。IBM MQ は、事業分野間または別のビジネス ドメイン間で通信を行う手段を提供します。

IBM MQ 製品ファミリーの関連製品であるIBM App Connect Enterprise (旧称 IBM Integration Bus / WebSphere Message Broker) を使用すると、キューベースのアーキテクチャーに対する多様で堅牢な拡張機能のセットが可能になります。IBM Integration Bus を使用すると、ユーザーは、任意のキューベースのアプリケーションと対話できるWSDLファイル サポートを備えた WebServices フロントエンドを実装できます。

• 高度なメッセージキューイングプロトコル
• IBM WebSphere メッセージブローカー
• Java メッセージ サービス
• メッセージキュー
• サービスとしてのメッセージキューイング
• 翻訳

この記事を聞く（22分）

この音声ファイルは、2011 年 10 月 29 日付のこの記事の改訂版から作成されたもので、その後の編集は反映されていません。 ( 2011-10-29 )

(音声ヘルプ ·その他の音声記事)

• IBM MQ 製品ページ