Included Reply Destination

This is a very common trick in use in most messaging systems. In fact, some of them support it as part of their standard API.

When you are building a messaging system (especially a point-to-point system) you have the problem of deciding where to place the response to a message. If you are building a simple point-to-point system with two endpoints (a source and a sink) then it's simple -- you can hardcode the destination of the messages in the code that processes each message on receipt.

However, if you add another message source then this complicates things. Now you'd be sending replies back to the wrong queue -- you'd be sending the reply to a system that didn't send you the message.

So the standard trick is to include inside each message that is sent out that needs a reply a reference to the destination queue for that message. That way the code reads out the destination when it processes the message and sends the reply to the correct place.

--KyleBrown with original pattern discovery by MartinFowler

Like a return address on a postal envelope. Or the Reply-To field in e-mail

Or the sender's address in IP packets, Ethernet packets, Token Ring packets and pretty much every other networking protocol ever invented.

I think that meets the RuleOfThree!

That brings up an interesting point -- one of the problems that CORBA has is that it dies when you try to run IIOP over a NATting (Network Address Translating) firewall. The reason is that the address in the packet is NOT the address that you want to send the reply to. Sounds like there might be another pattern of indirection there...

The problem is that addressing information is being duplicated, and CORBA lets it gets out of sync (the classic problem with duplicating data). Each protocol layer in a stack uses the IncludedReplyDestination. TCP and UDP add their port number to outgoing packets, IP adds the machine's address to the outgoing packets, and so on. A TCP layer can reproduce the entire address of the sender from the the IP and TCP headers. (Lower level reply destinations are usually exposed through some clean API to reduce coupling between stack layers.)

CORBA, however, puts the entire reply address into the header of a request. When the request goes through a NAT box, the reply address in the header becomes out of sync with the addresses in the TCP and IP headers. If CORBA instead reconstructed the reply address from information provided by lower level protocols, this would not happen.

Perhaps there is a pattern to be mined here?

--NatPryce