EIP / Return Address

Return Address †

サマリ †

色々と考えると、メッセージを送りつけた側が返信先も指定するのが一番いいんじゃない？

詳細 †

• アプリケーションはMessagingによってRequest-Replyを実現している。

返信側はどうやって返信先を知ればよいか？

• メッセージは通常は互いに完全に独立したものだが、Request-Replyでは要求メッセージと返信メッセージに1対1の関係があるので、返信側は、要求側が期待するチャネルにメッセージを送信する必要がある。
• 返信側に返信先チャネルをハードコーディングしてしまう方法もあるが、それだとソフトウェアの柔軟性が犠牲になりメンテナンス性も落ちる。また、1つの返信側が複数の異なる要求を処理することもできなくなる。
• 返信先を要求側とは別にしたいケースもある。その場合、返信処理用のコールバックプロセッサが別のチャネルを監視するような形になるだろう。コールバックプロセッサを複数持って、要求メッセージ毎に別々のコールバックプロセッサに処理させたいような場合も考えられる。
• 返信先が要求側と一致しないこともあるので、誰がどのチャネルに要求メッセージを送ってきたかは必ずしも役に立たない。したがって、要求側が返信側にどこにどうやって返信を送るべきかを指定する仕組みが必要となる。

要求メッセージに返信先アドレス（Return Address）を持たせて、どこに返信メッセージを送るべきかを指定する。

• こうすることで、要求／返信チャネルに関する知識が要求側にカプセル化され、返信側は返信先をハードコードする必要がなくなり、メッセージ毎に返信先を変えることもできる。返信先アドレスはアプリケーションデータではないので、メッセージのヘッダに持たせる。
• メッセージの返信先アドレスは電子メールのreply-toフィールドに似ている。reply-toアドレスは通常、fromアドレスと同じだが、返信先を分けたい時は送信者がreply-toアドレスを設定できる。

他のパターンとの関係 †

• 返信先アドレスで返信するときは、同時にCorrelation Identifierも必要になるかもしれない。返信先アドレスはどのチャネルに返信するかを指定するのに対し、Correlation Identifierは要求メッセージと返信メッセージとの対応を要求側に伝える。

例：JMSのReply-Toプロパティ †

• JMSメッセージにはJMSReplyTo?というプロパティが用意されている。

例：.NETのResponse-Queueプロパティ †

• .NETメッセージにはResponse-Queueプロパティが用意されている。

例：Webサービスのリクエスト／レスポンス †

• SOAP 1.2にはRequest-Responseメッセージ交換パターンが含まれるが、要求側と返信側を分離するための返信先アドレスの仕組みがない。
• WS-Addressing標準がその仕組みを提供するものとなる。

担当者のつぶやき †