メッセージングパターン

ソフトウェア アーキテクチャでは、メッセージング パターンは、アプリケーションの 2 つの異なる部分、または異なるシステムが相互に接続して通信する方法を説明するアーキテクチャ パターンです。メッセージングの概念には多くの側面があり、ハードウェア デバイス メッセージング (電気通信、コンピューター ネットワーク、IoT など) とソフトウェア データ交換 (さまざまなデータ交換形式とそのようなデータ交換のソフトウェア機能) のカテゴリに分類できます。コンテキストの違いにもかかわらず、両方のカテゴリはデータ交換に関して共通の特性を示します。

電気通信において、メッセージ交換パターン( MEP )は、通信チャネルを確立または使用するために通信プロトコルで必要なメッセージのパターンを表します。通信プロトコルは、すべての通信当事者が同意する (または処理できる) メッセージを表すために使用される形式です。通信チャネルは、通信当事者間でメッセージが「移動」できるようにするインフラストラクチャです。メッセージ交換パターンは、通信プロセスにおける当事者間のメッセージ フローを表します。メッセージ交換パターンには、要求応答パターンと一方向パターンの 2 つの主要なパターンがあります。

たとえば、インターネット(チャネル) 上のコンテンツを表示する場合、Web ブラウザー(通信相手) はHTTP (通信プロトコル) を使用してサーバー (別の通信相手) に Web ページを要求し、返されたデータを視覚的な形式でレンダリングします。これが、要求応答メッセージング パターンの動作方法です。

あるいは、コンピュータネットワークでは、 UDPネットワークプロトコルがあります。これは、一方向メッセージングパターン^[1]で使用され、送信側はメッセージが受信側に届くかどうかに関心がなく、受信側が「応答」メッセージを生成することも期待していません。

このセクションでは、ハードウェア デバイス間のデータ交換について説明します。デバイスがデータを読み取って交換できるようにするには、送信側 (ラジオ塔) として機能するハードウェア デバイスによって生成され、受信側 (キッチンのラジオなど) である別のハードウェア デバイスによって解釈されるハードウェア固有のプロトコル (無線信号など) を使用します。ラジオの例では、一方向の通信パターンがあり、メッセージ交換プロトコルは無線信号そのものです。

デバイス通信は、メッセージ交換システム内のハードウェア デバイスがメッセージ交換を可能にする方法を指す場合もあります。たとえば、インターネットを閲覧する場合、ルーター、スイッチ、ネットワーク アダプターなど、さまざまなデバイスが連携してインターネット トラフィックを通じてメッセージを配信します。これらのデバイスは、ハードウェア レベルでTCPまたは UDP パッケージの形式で信号を送受信します。このような各パッケージは、相互に通信するハードウェア デバイスのペアに視野を絞れば、それ自体がメッセージと呼ばれることもありますが、インターネット通信の一般的な意味では、順番に配置された多数のパッケージが一緒になって、画像や Web ページなどの意味のあるメッセージを形成します。

メッセージ データの形式が、関連するデバイスのタイプと機能によってサポートされているプロトコルに制限されるデバイス通信 (たとえば、コンピュータ ネットワークには TCP プロトコルと UDP プロトコルがあり、トランシーバーは特定の周波数で電波を送信し、ビーコンは人間が判読できるモールス信号シーケンスを点滅させます) とは異なり、ソフトウェアはより複雑で堅牢なデータ交換形式を確立できます。

これらの形式は、送信側によって基盤となるハードウェアで配信可能な形式に変換され、受信側によってハードウェア固有の形式から、通信ソフトウェア システムによって確立された元のプロトコルに準拠した形式にデコードされます。この高レベルのデータ交換により、より人間が読みやすい形式で情報を転送できるようになり、ソフトウェア暗号化および復号化技術を使用してメッセージを安全にすることもできます。さらに、ソフトウェア メッセージ交換により、単純な要求応答や一方向のアプローチに限定されなくなった、より多くのメッセージ交換パターンが可能になります。そして最後に、ソフトウェア通信システムは、メッセージ配信を最適化したり、特定のメッセージを受信する相手を決定するのに役立つ選択とフィルタリングの複雑なルールを確立したりするために使用できる、さまざまなデータ交換チャネルを提供できます。これにより、ソフトウェアによってオーケストレーションされたメッセージ ルーティングが可能になります。後者の結果として、トピック(対象グループ内のすべての受信側にメッセージのコピーが配信される) とキュー(対象グループ内の 1 つの相手だけがメッセージを受信する) の概念が生まれました。

前述のように、ソフトウェア メッセージングでは、データ交換プロトコルのオプションと自由度が高まります。ただし、通信相手がプロトコルの詳細について合意しない限り、これはあまり役に立ちません。そのため、標準化されたソフトウェア メッセージング プロトコルが数多く存在します。この標準化により、通常は別々の組織によって作成および保守され、異なるハードウェア デバイス (サーバー、コンピューター、スマート デバイス、IoT コントローラー) で動作するさまざまなソフトウェア システムが、リアルタイムのデータ交換に参加できるようになります。

以下は、現在でも使用されている、最も人気のあるソフトウェア メッセージング プロトコルの一部です。それぞれが、前のセクションで説明したメッセージングの概念に拡張された意味を提供します。

メッセージ交換パターンという用語は、シンプルオブジェクトアクセスプロトコル（SOAP ）内で拡張された意味を持っています。^{[2] [3]} SOAP MEPタイプには次のものがあります。

1. 受信のみ: これは一方向と同等です。コンシューマーがプロバイダーにメッセージを送信し、プロバイダーはいかなる種類の応答も送信しない標準的な一方向メッセージ交換です。
2. 堅牢な In-Only : このパターンは、信頼性の高い一方向のメッセージ交換用です。コンシューマーはメッセージで開始し、プロバイダーはステータスで応答します。応答がステータスの場合、交換は完了しますが、応答がエラーの場合、コンシューマーはステータスで応答する必要があります。
3. In-Out : これは、リクエストとレスポンスに相当します。コンシューマーがメッセージで開始し、プロバイダーがメッセージまたは障害で応答し、コンシューマーがステータスで応答する標準的な双方向メッセージ交換です。
4. In-Optional-Out : プロバイダーの応答がオプションである標準的な双方向メッセージ交換。
5. Out-Only : In-Only の逆です。主にイベント通知をサポートします。障害メッセージをトリガーすることはできません。
6. 堅牢な送信専用: 送信専用パターンに似ていますが、障害メッセージをトリガーできます。送信メッセージによって送信が開始されます。
7. Out-In : In-Out の逆。プロバイダーがリクエストを送信し、交換を開始します。
8. Out-Optional-In : In-Optional-Out の逆です。サービスは送信メッセージを生成します。受信メッセージはオプションです ("Optional-in")。

ØMQメッセージキューイングライブラリは、使用するメッセージパターンを指定する必要があり、各パターンに最適化されている、いわゆるソケット（従来のIPおよびUnixソケットの一種の一般化）を提供します。基本的なØMQパターンは次のとおりです。^[4]

• リクエスト-応答は、一連のクライアントを一連のサービスに接続します。これは、リモート プロシージャ コールとタスク分散パターンです。 ^{[説明が必要]}
• パブリッシュ・サブスクライブは、パブリッシャーのセットをサブスクライバーのセットに接続します。これはデータ配布パターンです。 ^{[説明が必要]}
• プッシュプルは、複数のステップとループを持つファンアウト/ファンイン パターンでノードを接続します。これは、並列タスクの分散および収集パターンです。 ^{[説明が必要]}
• 排他ペアは、排他ペアで 2 つのソケットを接続します。これは、特定の高度な使用例のための低レベルのパターンです。

各パターンは特定のネットワークトポロジを定義します。リクエスト-リプライはいわゆる「サービスバス」を定義し、パブリッシュ-サブスクライブは「データ分散ツリー」を定義し、プッシュ-プルは「並列パイプライン」を定義します。すべてのパターンは、無限にスケーラブルでインターネット規模で使用できるように意図的に設計されています。^[5]

RESTプロトコルは、 HTTP プロトコルの上に構築されたメッセージング プロトコルであり、同様に、メッセージ交換の要求応答パターンを使用します。HTTP の主な目的は、人間のエンド ユーザーを対象とした Web ページとファイルをインターネット経由で配信することですが、 RESTプロトコルは主に異なるソフトウェア システム間の通信に使用され、マイクロサービスソフトウェア アーキテクチャ パターンで重要な役割を果たします。REST プロトコルの注目すべき特性の 1 つは、他の多くの形式 (通常は JSON と XML) でデータを表現できるほど汎用性が高く、表現するメッセージに追加のメタデータ記述子を提供することです。メタデータ記述子は、HTTP ヘッダー (基礎となる HTTP プロトコルによって標準化されている) として表現されることにより HTTP 標準に準拠しているため、受信側がメッセージ ペイロードを解釈する方法の指示として使用できます。そのため、開発者はメッセージ ペイロードの高レベル形式 (JSON または XML モデル) のみを意識するだけでよいため、REST により、別のソフトウェア システムと通信できるソフトウェア システムの開発が大幅に改善されます。実際の HTTP 通信は通常、ソフトウェア ライブラリまたはフレームワークによって処理されます。

REST プロトコルのもう 1 つの優れた点は、その上に他のプロトコル セマンティクスを構築するのに適していることです。これはHATEOASの例です。

• プッシュテクノロジー
• 分散データフロー
• エンタープライズ統合パターン

• サービス指向アーキテクチャにおけるメッセージング パターン
• エンタープライズ統合パターン - パターン カタログ