ドキュメントメッセージ †
要約 †
- アプリケーションでデータを別のアプリケーションに転送したい。ファイル転送（43）や共有データベース（47）を使ってもよいが、こうしたアプローチには欠点がある。メッセ―ジング（53）を使った方がうまくいく
アプリケーション間でデータを転送するのにメッセージングをどう使えばいいだろう
- ファイル転送（43）は簡単だが欠点もある。出力されたファイルは他のファイルが使うまで、置きっぱなし。使うアプリが複数ある場合、誰が消せばよいのかわからない。
- 共有データベース（47）では、データをDBに格納するのに新しいスキーマを追加するか、既存のスキーマにはめ込まなければならない。また、いったんDBに格納してしまうと、見てはいけないアプリケーションからも見えてしまう。データの受け手に読みに来てもらうのは難しいし、データを誰が消せばいいかもわからない。
- リモートプロシージャ呼び出し（50）を使ってデータを送信することもできる。しかし、呼び出し側は受け手にそのデータを使って何をするかも伝えなければならない。コマンドメッセージ（145）も同じようにデータを送るが、受け手が何をするかがきわめて限定されている。また、リモートプロシージャ呼び出し（50）は双方向のコミュニケーションを想定しているが、データを渡すだけであれば不要だ。
- 我々はデータを転送するのにメッセージング（53）を使いたい。メッセージング（53）はRPCよりも信頼性が高い。ポイント・ツー・ポイント・チャネル（103）を使えば、特定の受け手だけがデータを受け取るようにできる。パブリッシュ・サブスクライブ・チャネル（106）を使えば、データがほしい受け手誰もがデータのコピーをもらえる。こうしたコツを使えば、RPCのように複雑にすることなくメッセージング（66）のメリットを享受できる。
アプリケーション間でデータ構造を信頼性高く転送するためにドキュメントメッセージを使う
- コマンドメッセージ（145）が受け手に対してあるふるまいをするように伝えるのに対して、ドキュメントメッセージはデータを渡すだけで、そのデータで何をするかは受け手に任せる。
- ドキュメントメッセージはイベントメッセージ（151）と似ている。違いは、タイミングと中身。ドキュメントメッセージでは中身（ドキュメント）を正しく送ることが重要で、いつそれを送るかはそれほど重要ではない。デリバリーの保証（122）が重要で、メッセージの賞味期限（176）は考える必要がない。イベントメッセージは中身よりもタイミングが重要。
- ドキュメントメッセージは、どんな種類でもいい。JMSでは、Serializableなデータオブジェクトを含むObjectMessage?でもいいし、XML形式のデータを含むテキストメッセージでもいい。.NETでは、データが格納されたMessage（66）になる。SOAPのリプライメッセージもドキュメントメッセージだ。
- ドキュメントメッセージは通常ポイント・ツー・ポイント・チャネル（103）を使う。シンプルなワークフローを実装するにメッセージング（53）が使える。場合によってはパブリッシュ・サブスクライブ・チャネル（106）を使ってブロードキャストもできるが、そうするとドキュメントのコピーがいっぱいできてしまう。コピーはリードオンリーにしないと大変。リクエスト・リプライ（154）では、リプライはたいていドキュメントメッセージになる。
