Message Construction Introduction †
サマリ †
- メッセージングシステムを使用するときには、「メッセージの意図」「応答」「大量データ」「遅いメッセージ」について検討しよう。
詳細 †
- メッセージングシステムの概要ではメッセージについて説明した。2つのアプリケーションでデータ片を交換したいときメッセージでそれを包むことで行う。メッセージチャネルは、生データを送信することができず、メッセージにラップされたデータを送ることができる。
- メッセージを作成して送信するといくつかの問題を発生させる。
メッセージの意図
- 送信者は、受信者がメッセージで何を行うのかについての異なる意図をもつ。
- 送信者が受信側の呼び出したい関数やメソッドを指定する意図の場合 → Command Message(コマンドメッセージ)
- 送信者が受信者にデータ構造（の一片）送る意図の場合 → Document Messsage(文書メッセージ)
- 送信者が受信者にデータを渡すが、受信側がそれを使って何をすべきか指定しない、もしくは送信者の変更を受信者に通知する意図の場合 → Event Message(イベントメッセージ)
応答を返す
- アプリケーションがメッセージを送るとき、たびたびメッセージが処理されたことを確認し、結果を提供する応答を期待する。これはRequest-Reply(要求-応答)のシナリオ。
- リクエストは、通常Command Message(コマンドメッセージ)であり、レスポンスが結果値を含むDocument Message(文書メッセージ)または例外となる。
- 要求者は、応答を送信するに使用するチャネルのリプライヤを指定するために、リターンアドレスを指定する必要がある。複数のプロセスから複数のリクエストがあるかもしれないので、リクエストを指定する相関ID（Correlation Identifier）が含まれているはず。
- 注目に値する２つの一般的なRequest-Reply(要求 - 応答)のシナリオとして、CommandMessage?(コマンドメッセージ)のリクエストと対応するDocumentMessage?(ドキュメントメッセージ)のレスポンスがある。最初のシナリオでは、「メッセージングRPC」で、要求者はリプライヤーで関数を呼び出すことだけでなく戻り値を望んでいる。これは、アプリケーションがメッセージを使用してRPC（リモートプロシージャコール）を実行する方法。別のシナリオは、「メッセージングクエリ」で、要求者は、リプライヤーが実行して、応答の結果を返すクエリを実行する。これは、アプリケーションがリモートでクエリを実行ためにメッセージング使用する方法。
大量のデータ
- アプリケーションが実際に単一のメッセージでは適切でない大規模なデータ構造を送りたいことがある。
- この場合、より管理しやすいチャンクにデータを分割し、メッセージシーケンスとして送信する。チャンクは、シーケンスとしてではなく、メッセージの束として送らなければならない。それで、受信者が元のデータ構造を再構築することができる。
遅いメッセージ
- メッセージングでの懸念は、送付者が受信者がメッセージを受信することがどれくらいかかるか分からないこと。メッセージの内容は、期限までに受信できなかったメッセージ場合、それは単に無視して破棄されるべきであることなど、時間に敏感かもしれない。
- このような状況では、送信者が有効期限を指定するには、メッセージの有効期限を使用することができる。
- メッセージングシステムは、その期限が終了することにより、メッセージを配信できない場合は、メッセージを捨てるべき。
- したがって、メッセージを使用することに決めるのでは、まだ十分ではありません。データを転送する必要があるときはいつでも、それはメッセージを介して行われます(←なんか変な文章になったので訳に自信がない：So it's not enough to decide to use a Message; anytime data needs to be transferred, it will be done through a message.)。この章では、メッセージを正常に機能させる他の決定を説明します。
