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

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

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

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

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

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

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

メッセージベースの通信プロトコルを使用する主な理由としては、送信者から受信者へメッセージを伝達する際に、メッセージを保存（バッファリング）、ルーティング、または変換できる能力が挙げられる。

クライアント間のメッセージングをメッセージングプロバイダ経由で行う場合のもう一つの利点は、管理インターフェースを追加することでパフォーマンスを監視および調整できることです。これにより、クライアントアプリケーションはメッセージの送受信および処理以外のあらゆる問題から解放されます。相互運用性、信頼性、セキュリティ、拡張性、パフォーマンスといった問題の解決は、MOMシステムを実装するコードと管理者に委ねられます。

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

さらに、多くのアプリケーション間通信には本質的に同期的な側面があり、送信側は処理を続行する前にメッセージへの応答を待つ必要がある（極端な例としてリアルタイムコンピューティングやニアリアルタイムを参照）。メッセージベースの通信は本質的に非同期的に動作するため、このような状況には適さない可能性がある。とはいえ、ほとんどのMOMシステムには、要求と応答を単一の擬似同期トランザクションとしてグループ化する機能がある。

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

歴史的に、メッセージ指向ミドルウェアの使用を規定する標準規格が欠如していたことが問題を引き起こしてきた。主要ベンダーのほとんどは独自の実装を持っており、それぞれ独自のアプリケーションプログラミングインターフェース（API）と管理ツールを備えている。

メッセージ指向ミドルウェアの長年の標準規格の一つに、X/OpenグループのXATMI仕様（分散トランザクション処理：XATMI仕様）があり、これはプロセス間通信のためのAPIを標準化しています。このAPIの実装例としては、ATR BalticのEnduro/XミドルウェアやOracleのTuxedoなどが知られています。

高度メッセージキューイングプロトコル(AMQP) は、OASIS ^{[ 5 ]}および ISO ^{[ 6 ]}の承認済み標準であり、参加するアプリケーション コンポーネント間で使用されるプロトコルとフォーマットを定義しているため、実装間の相互運用性があります。AMQP は、ポイントツーポイント、ファンアウト、パブリッシュ/サブスクライブ、リクエスト/レスポンスなどの一般的なメッセージング パラダイムを含む柔軟なルーティング スキームで使用できます(これらはプロトコル標準の v1.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）です。TCP/IP上に構築された軽量で信頼性の高いパブリッシュ/サブスクライブ型のメッセージングトランスポートプロトコルであり、コードフットプリントの削減やネットワーク帯域幅の制約が求められるM2M/IoT環境での通信に適しています。

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

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

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

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

• IBM MQ 開発者向け基本事項
• ORBexpress：概要