メッセージ指向ミドルウェア

メッセージ指向ミドルウェア( MOM ) は、分散システム間でのメッセージの送受信をサポートするソフトウェアまたはハードウェア インフラストラクチャです。メッセージ指向ミドルウェアは、データが明示的なメッセージ境界のないバイト シーケンスとして通信されるストリーミング指向ミドルウェアとは対照的です。ストリーミング プロトコルは、ほとんどの場合、フレーム (イーサネット)、データグラム ( UDP )、パケット ( IP )、セル ( ATM ) などの個別のメッセージを使用するプロトコルの上に構築されることに注意してください。

MOM は、アプリケーション モジュールを異機種プラットフォームに分散することを可能にし、複数のオペレーティング システムとネットワーク プロトコルにまたがるアプリケーションの開発の複雑さを軽減します。ミドルウェアは、アプリケーション開発者をさまざまなオペレーティング システムとネットワーク インターフェイスの詳細から分離する分散通信層を作成します。さまざまなプラットフォームとネットワークにまたがるアプリケーション プログラミング インターフェイス ( API ) は、通常、MOM によって提供されます。^[1]

このミドルウェア層により、独立して開発され、異なるネットワーク プラットフォーム上で実行されるソフトウェア コンポーネント (アプリケーション、サーブレット、その他のコンポーネント) が相互にやり取りできるようになります。異なるネットワーク ノードに分散されたアプリケーションは、アプリケーション インターフェイスを使用して通信します。さらに、管理インターフェイスを提供することで、相互接続されたアプリケーションのこの新しい仮想システムは、フォールト トレランスとセキュリティを実現できます。^[2]

MOM は、クライアント/サーバー アーキテクチャのすべての通信コンポーネントに存在するソフトウェア要素を提供し、通常はクライアント アプリケーションとサーバー アプリケーション間の非同期呼び出しをサポートします。MOM により、クライアント/サーバー メカニズムのマスター/スレーブ特性の複雑さに伴うアプリケーション開発者の関与が軽減されます。

• リモート プロシージャ コールまたは RPC ベースのミドルウェア
• オブジェクトリクエストブローカーまたはORBベースのミドルウェア^[3]
• メッセージ指向ミドルウェアまたはMOMベースのミドルウェア

これらのモデルはすべて、1 つのソフトウェア コンポーネントがネットワークを介して別のコンポーネントの動作に影響を与えることを可能にします。RPC ベースおよび ORB ベースのミドルウェアは密結合コンポーネントのシステムを作成するのに対し、MOM ベースのシステムはコンポーネントの疎結合を可能にするという点で異なります。RPC ベースまたは ORB ベースのシステムでは、あるプロシージャが別のプロシージャを呼び出すと、呼び出されたプロシージャが返されるまで待機してから、他の操作を実行できます。これらのほとんどが同期メッセージング モデルでは、ミドルウェアは部分的にスーパー リンカーとして機能し、ネットワーク上で呼び出されたプロシージャを見つけ、ネットワーク サービスを使用して関数またはメソッド パラメータをプロシージャに渡し、結果を返します。[ ^2]オブジェクト リクエスト ブローカーは、一方向呼び出しによる完全な非同期メッセージングもサポートします。^[3]

メッセージベースの通信プロトコルを使用する主な理由としては、送信者から受信者にメッセージを伝達する際に、メッセージを保存 (バッファリング)、ルーティング、または変換する機能などがあります。

クライアント間のメッセージング プロバイダーを介したメッセージングのもう 1 つの利点は、管理インターフェイスを追加することで、パフォーマンスを監視および調整できることです。これにより、クライアント アプリケーションは、メッセージの送信、受信、および処理以外のすべての問題から実質的に解放されます。相互運用性、信頼性、セキュリティ、スケーラビリティ、およびパフォーマンスなどの問題を解決するのは、MOM システムを実装するコードと管理者の責任です。

MOM システムを使用すると、クライアントは API 呼び出しを行って、プロバイダーが管理する送信先にメッセージを送信します。この呼び出しにより、プロバイダー サービスが呼び出され、メッセージがルーティングおよび配信されます。メッセージを送信すると、クライアントは、受信側クライアントがメッセージを取得するまでプロバイダーがメッセージを保持していることを確信して、他の作業を続行できます。メッセージ ベースのモデルとプロバイダーの仲介を組み合わせることで、疎結合コンポーネントのシステムを作成できます。

MOM は、一般に要求応答アーキテクチャではなく、非同期メッセージ パッシングに依存するアプリケーション間 通信ソフトウェアのカテゴリを構成します。非同期システムでは、送信先プログラムがビジー状態または未接続の場合に、メッセージ キューが一時的なストレージを提供します。さらに、ほとんどの非同期 MOM システムは、メッセージ キューをバックアップするための永続的なストレージを提供します。つまり、送信側と受信側は同時にネットワークに接続する必要がなく (非同期配信)、断続的な接続の問題は解決されます。また、受信側アプリケーションが何らかの理由で失敗した場合でも、送信側は影響を受けずに続行できます。送信側が送信したメッセージは、受信側が再起動したときに後で処理できるようにメッセージ キューに蓄積されるだけです。

多くのメッセージ指向ミドルウェア実装は、メッセージ キューシステムに依存しています。実装によっては、ルーティング ロジックをメッセージング レイヤー自体で提供できるものもあれば、クライアント アプリケーションに依存してルーティング情報を提供したり、両方のパラダイムを混在させたりしているものもあります。実装によっては、ブロードキャストまたはマルチキャスト配信パラダイムを利用するものもあります。

メッセージベースのミドルウェアシステムでは、送信先で受信されるメッセージは、元のメッセージと同一である必要はありません。インテリジェンスが組み込まれた MOM システムは、送信者または受信者の要件に合わせてメッセージを変換し、ルーティングすることができます。 ^{[4]ルーティングおよびブロードキャスト/}マルチキャスト機能と組み合わせることで、1 つのアプリケーションが独自のネイティブ形式でメッセージを送信し、2 つ以上の他のアプリケーションがそれぞれ独自のネイティブ形式でメッセージのコピーを受信できます。最近の MOM システムの多くは、プログラマが単純なGUI ドラッグ アンド ドロップ操作に適用できる変換ルールを指定できる、洗練されたメッセージ変換 (またはマッピング) ツールを提供しています。

多くのメッセージ指向ミドルウェア システムの主な欠点は、アーキテクチャ内にメッセージ転送エージェント (メッセージ ブローカー) という追加のコンポーネントが必要になることです。他のシステムと同様に、別のコンポーネントを追加すると、パフォーマンスと信頼性が低下する可能性があり、システム全体の保守がより困難になり、コストもかかる可能性があります。

さらに、多くのアプリケーション間通信は本質的に同期的な側面を持っており、送信者は特にメッセージへの応答を待ってから処理を続行します (極端なケースについては、リアルタイム コンピューティングとニア リアルタイムを参照してください)。メッセージ ベースの通信は本質的に非同期で機能するため、このような状況には適さない可能性があります。ただし、ほとんどの MOM システムには、要求と応答を 1 つの疑似同期トランザクションとしてグループ化する機能があります。

同期メッセージング システムでは、呼び出された関数がタスクを完了するまで、呼び出し関数は戻りません。疎結合の非同期システムでは、呼び出しクライアントは、この作業の処理に必要なリソースが枯渇し、呼び出されたコンポーネントが失敗するまで、受信者に作業をロードし続けることができます。もちろん、パフォーマンスを監視し、メッセージ フローを調整することで、これらの状況を最小限に抑えたり回避したりできますが、これは同期メッセージング システムでは不要な作業です。重要なのは、各種類のシステムの利点と欠点を理解することです。各システムは、異なる種類のタスクに適しています。場合によっては、目的の動作を得るために、2 種類のシステムを組み合わせる必要があります。

歴史的に、メッセージ指向ミドルウェアの使用を規定する標準が欠如していたため、問題が発生していました。大手ベンダーのほとんどは独自の実装を持っており、それぞれに独自のアプリケーション プログラミング インターフェイス(API) と管理ツールがあります。

メッセージ指向ミドルウェアの長年にわたる標準の 1 つに、プロセス間通信の API を標準化する X/Open グループの XATMI 仕様 (分散トランザクション処理: XATMI 仕様) があります。この API の既知の実装には、ATR Baltic のEnduro/XミドルウェアとOracleのTuxedoがあります。

AMQP ( Advanced Message Queuing Protocol ) は、OASIS ^[5]および ISO ^[6]の承認済み標準であり、参加するアプリケーション コンポーネント間で使用されるプロトコルと形式を定義しているため、実装は相互運用可能です。AMQP は、ポイントツーポイント、ファンアウト、パブリッシュ/サブスクライブ、要求/応答などの一般的なメッセージング パラダイムを含む柔軟なルーティング スキームで使用できます (これらはプロトコル標準のバージョン 1.0 では意図的に省略されていますが、ルーティングについては特定の実装や基礎となるネットワーク プロトコルに依存しています)。また、トランザクション管理、キューイング、分散、セキュリティ、管理、クラスタリング、フェデレーション、異機種マルチプラットフォームのサポートもサポートしています。AMQP を使用する Java アプリケーションは通常、Java JMS で記述されます。他の実装では、 C#、C++、PHP、Python、Ruby、その他のプログラミング言語用の API が提供されます。

高レベル アーキテクチャ(HLA IEEE 1516) は、シミュレーション相互運用性に関する米国電気電子技術者協会(IEEE) およびシミュレーション相互運用性標準化機構(SISO) の標準です。これは、C++ または Java の API を通じて提供される一連のサービスを定義します。これらのサービスは、モジュール式のフェデレーション オブジェクト モデルに基づいて、パブリッシュ/サブスクライブ ベースの情報交換を提供します。また、論理シミュレーション時間や同期ポイントに基づいて、調整されたデータ交換や時間を進めるサービスもあります。追加のサービスでは、所有権の移転、データ配布の最適化、参加フェデレート (システム) の監視と管理が提供されます。

MQテレメトリ トランスポート(MQTT) は、OASIS 組織によってサポートされている ISO 標準 (ISO/IEC PRF 20922) です。MQTT は、TCP/IP をベースにした軽量のパブリッシュ/サブスクライブ型の信頼性の高いメッセージング トランスポート プロトコルを提供します。これは、小さなコード フットプリントが要求される M2M/IoT コンテキストでの通信や、ネットワーク帯域幅が重要視される M2M/IoT コンテキストでの通信に適しています。

オブジェクト管理グループのデータ配信サービス（DDS）は、メッセージ指向のパブリッシュ/サブスクライブ（P/S）ミドルウェア標準を提供し、パブリッシャーとサブスクライバー間のスケーラブルでリアルタイム、信頼性、高性能、相互運用性のあるデータ交換を可能にすることを目的としています。^[7]この標準は、C++、C++11、C、Ada、Java、およびRubyへのインターフェイスを提供します。

eXtensible Messaging and Presence Protocol ( XMPP ) は、拡張マークアップ言語 ( XML )に基づくメッセージ指向ミドルウェアの通信プロトコルです。拡張できるように設計されたこのプロトコルは、パブリッシュ/サブスクライブ システム、VoIP のシグナリング、ビデオ、ファイル転送、ゲーム、スマート グリッドなどの IoT アプリケーション、ソーシャル ネットワーキング サービスにも使用されています。ほとんどのインスタント メッセージング プロトコルとは異なり、XMPP はオープン スタンダードで定義されており、開発とアプリケーションのオープン システム アプローチを使用しているため、誰でも XMPP サービスを実装し、他の組織の実装と相互運用できます。XMPP はオープン プロトコルであるため、任意のソフトウェア ライセンスを使用して実装を開発できます。多くのサーバー、クライアント、およびライブラリの実装は無料のオープン ソース ソフトウェアとして配布されていますが、フリーウェアやプロプライエタリ ソフトウェアの実装も多数存在します。インターネット技術タスク フォース (IETF) は、コア プロトコルを IETF インスタント メッセージングおよびプレゼンス テクノロジとして公式化するために、2002 年に XMPP ワーキング グループを結成しました。 XMPPワーキンググループは4つの仕様（RFC 3920、RFC 3921、RFC 3922、RFC 3923）を作成し、2004年に提案標準として承認されました。2011年に、RFC 3920とRFC 3921はそれぞれRFC 6120とRFC 6121に置き換えられ、RFC 6122はXMPPアドレス形式を指定しました。IETFで標準化されたこれらのコアプロトコルに加えて、XMPP Standards Foundation（旧Jabber Software Foundation）はオープンなXMPP拡張機能の開発に積極的に取り組んでいます。XMPP Standards Foundationによると、XMPPベースのソフトウェアはインターネット全体に広く導入されており、国防総省（DoD）のUnified Capabilities Frameworkの基礎となっています。^[8]

Java EEプログラミング環境は、 Java Message Service (JMS)と呼ばれる標準 API を提供します。これは、ほとんどの MOM ベンダーによって実装され、特定の MOM API 実装を隠すことを目的としています。ただし、JMS では交換されるメッセージの形式が定義されていないため、JMS システムは相互運用可能ではありません。

同様の取り組みとして、活発に進化している OpenMAMA プロジェクトがあります。このプロジェクトは、特に C クライアントに共通の API を提供することを目指しています。2012 年 8 月現在、このプロジェクトは主に、pub-sub ミドルウェアを介して市場指向のデータ (株価など) を配布するのに適しています。

メッセージキューは、分散アプリケーション間での情報交換を可能にします。メッセージキューは、メモリまたはディスクストレージに常駐できます。メッセージは、サービスコンシューマによって処理されるまでキューに留まります。メッセージキューを通じて、アプリケーションは独立して実装できます。アプリケーションは、互いの位置を知る必要はなく、このメッセージを受信するのを待つ必要性をなくすための手順を実装し続ける必要もありません。^[9]

• アドバンストメッセージキューイングプロトコル（AMQP）は、メッセージ指向ミドルウェア向けのオープン標準アプリケーション層プロトコルを提供します。^[10]
• Object Management Groupのデータ配布サービス(DDS) では、基本的な DDS 仕様に多くの新しい標準が追加されました。詳細については、OMG データ配布サービス (DDS) 仕様のカタログを参照してください。
• Object Management GroupのCommon Object Request Broker Architecture (CORBA) には最近、 C#への新しい言語マッピングや、 C++言語標準の最新の更新をサポートするために IDL から C++ へのマッピング仕様の更新など、多くの新しい標準が追加されました。詳細については、OMG CORBA 仕様のカタログを参照してください。
• 拡張メッセージングおよびプレゼンスプロトコル（XMPP）は、拡張マークアップ言語（XML）に基づくメッセージ指向ミドルウェア用の通信プロトコルです。^[11]
• ストリーミングテキスト指向メッセージングプロトコル（STOMP）は、以前はTTMPと呼ばれていましたが、シンプルなテキストベースのプロトコルであり、STOMPクライアントがプロトコルをサポートする任意のメッセージブローカーと通信できるようにする相互運用可能なワイヤフォーマットを提供します。^[12]
• さらに、メッセージ指向ミドルウェア機能がハードウェア、通常はフィールドプログラマブルゲートアレイ（FPGA）、特定用途向け集積回路（ASIC）、またはその他の特殊なシリコンチップに実装される傾向も見られます。 ^[13]

^[14]

• エンタープライズ統合パターン(書籍)
• エンタープライズ メッセージング システム
• エンタープライズ サービス バス
• フローベースプログラミング
• イベント駆動型アーキテクチャ

• IBM MQ 開発者向け基本情報。
• ORBexpress: 概要。