Loading article…
ソフトウェアアーキテクチャにおいて、メッセージングパターンとは、アプリケーションの異なる部分、あるいは異なるシステムがどのように接続し、通信するかを記述するアーキテクチャパターンです。メッセージングの概念には多くの側面があり、ハードウェアデバイスメッセージング（電気通信、コンピュータネットワーク、IoTなど）とソフトウェアデータ交換（さまざまなデータ交換フォーマットと、そのようなデータ交換のソフトウェア機能）という2つのカテゴリに分類できます。コンテキストの違いはあるものの、どちらのカテゴリもデータ交換において共通の特徴を示します。
電気通信において、メッセージ交換パターン（MEP）とは、通信プロトコルが通信チャネルを確立または使用するために必要なメッセージのパターンを記述するものです。通信プロトコルとは、通信を行うすべての当事者が合意する（または処理できる）メッセージ表現のフォーマットです。通信チャネルとは、通信を行う当事者間でメッセージが「伝わる」ことを可能にするインフラストラクチャです。メッセージ交換パターンは、通信プロセスにおける当事者間のメッセージの流れを記述するもので、大きく分けて要求応答パターンと一方向パターンの2種類があります。
例えば、インターネット（チャネル）上でコンテンツを閲覧する場合、ウェブブラウザ（通信主体）はHTTP（通信プロトコル）を使用してサーバー（別の通信主体）にウェブページを要求し、返されたデータを視覚的な形式に変換します。これがリクエスト・レスポンス型のメッセージングパターンの動作原理です。
あるいは、コンピュータネットワークでは、 UDPネットワークプロトコルがあります。これは、一方向メッセージングパターンで使用され、 [ 1 ]送信側はメッセージが受信側に届くかどうかに関心がなく、受信側が「応答」メッセージを生成することも期待していません。
このセクションでは、ハードウェアデバイス間のデータ交換について説明します。デバイスがデータを読み書きできるようにするには、送信側（無線塔）のハードウェアデバイスによって生成され、受信側（例えばキッチンのラジオ）の別のハードウェアデバイスによって解釈される、ハードウェア固有のプロトコル（無線信号など）を使用します。ラジオを例にとると、通信パターンは一方向であり、メッセージ交換プロトコルは無線信号そのものです。
デバイス間の通信とは、メッセージ交換システムにおけるハードウェアデバイスがどのようにメッセージ交換を可能にするかを指す場合もあります。例えば、インターネットを閲覧する際、ルーター、スイッチ、ネットワークアダプタなど、さまざまなデバイスが連携してインターネットトラフィックを通じてメッセージを配信します。これらのデバイスはハードウェアレベルではTCPまたはUDPパケットの形式で信号を送受信します。ハードウェアデバイス同士の通信という観点から見ると、個々のパケットはそれぞれメッセージとみなすことができますが、インターネット通信全般においては、複数のパケットが順番に並んで、画像やウェブページといった意味のあるメッセージを構成します。
デバイス間の通信では、メッセージデータの形式は、関係するデバイスの種類と機能によってサポートされるプロトコルに限定されます（たとえば、コンピュータネットワークではTCPとUDPプロトコルがあり、トランシーバーは特定の周波数の電波を送信し、ビーコンは人が読み取れるモールス信号のシーケンスを点滅させます）。一方、ソフトウェアは、より複雑で堅牢なデータ交換フォーマットを確立できます。
これらのフォーマットは、送信側によって基盤となるハードウェアが配信可能な形式に変換され、受信側によってハードウェア固有のフォーマットから通信ソフトウェアシステムによって確立された元のプロトコルに準拠した形式にデコードされます。この高レベルのデータ交換により、より人間が読みやすい形式で情報を転送できるだけでなく、ソフトウェア暗号化および復号化技術を使用してメッセージを安全に送信することも可能です。さらに、ソフトウェアによるメッセージ交換により、単純な要求応答や一方通行のアプローチに限定されない、より多くのバリエーションのメッセージ交換パターンが可能になります。そして最後に、ソフトウェア通信システムは、メッセージ配信を最適化したり、特定のメッセージを受信する当事者を決定するのに役立つ選択およびフィルタリングの複雑なルールを確立したりするために使用できる、さまざまなデータ交換チャネルを提供できます。これにより、ソフトウェアによるメッセージルーティングが可能になります。その結果、トピック（対象グループ内のすべての受信当事者にメッセージのコピーが配信される）とキュー（対象グループ内の1つの当事者のみがメッセージを受信する）の概念が生まれました。
前述のとおり、ソフトウェアメッセージングはデータ交換プロトコルにおいてより多くの選択肢と自由度を提供します。しかし、通信当事者が関連するプロトコルの詳細について合意しない限り、これはあまり役に立ちません。そのため、多くの標準化されたソフトウェアメッセージングプロトコルが存在します。この標準化により、通常は別々の組織によって作成および保守され、異なるハードウェアデバイス（サーバー、コンピューター、スマートデバイス、IoTコントローラーなど）上で動作する可能性のある、さまざまなソフトウェアシステムがリアルタイムのデータ交換に参加できるようになります。
以下に、現在も広く使用されている代表的なソフトウェアメッセージングプロトコルをいくつか示します。これらのプロトコルはそれぞれ、前述のメッセージング概念に拡張された意味合いを与えています。
メッセージ交換パターンという用語は、 Simple Object Accessプロトコル（SOAP ）内で拡張された意味を持ちます。[ 2 ] [ 3 ] SOAP MEPタイプには以下が含まれます。
ØMQメッセージキューイングライブラリは、いわゆるソケット(従来のIPおよびUnix ソケットの一般化の一種) を提供しており、使用するメッセージングパターンを指定する必要があり、各パターンに合わせて最適化されています。基本的な ØMQ パターンは次のとおりです。[ 4 ]
各パターンは特定のネットワークトポロジーを定義します。リクエスト/リプライは「サービスバス」と呼ばれるものを定義し、パブリッシュ/サブスクライブは「データ配信ツリー」を定義し、プッシュ/プルは「並列パイプライン」を定義します。すべてのパターンは、無限に拡張可能で、インターネット規模で使用できるように意図的に設計されています。[ 5 ]
RESTプロトコルはHTTPプロトコルの上に構築されたメッセージングプロトコルであり、同様にリクエスト/レスポンス方式のメッセージ交換パターンを使用します。HTTPの主な目的は、人間のエンドユーザーを対象としたWebページやファイルをインターネット経由で配信することですが、RESTプロトコルは主に異なるソフトウェアシステム間の通信に使用され、マイクロサービスソフトウェアアーキテクチャパターンにおいて重要な役割を果たします。RESTプロトコルの注目すべき特徴の一つは、データを他の多くの形式（一般的にはJSONとXML）で表現できる汎用性の高さと、表現するメッセージに追加のメタデータ記述子を提供する点です。メタデータ記述子はHTTP標準に準拠しており、HTTPヘッダー（基盤となるHTTPプロトコルによって標準化されている）として表現されるため、受信側がメッセージペイロードをどのように解釈するかの指示として使用できます。そのため、開発者はメッセージペイロードの上位レベル形式（JSONまたはXMLモデル）だけを意識すればよく、RESTは他のソフトウェアシステムと通信できるソフトウェアシステムの開発を大幅に改善します。実際のHTTP通信は通常、ソフトウェアライブラリまたはフレームワークによって処理されます。
RESTプロトコルのもう1つの優れた点は、その上に他のプロトコルセマンティクスを構築するのに適していることです。HATEOASはその例です。