<font face="trebuchet ms,sans-serif">Hi, I'm stuck with trying to find a way to implement generic asynchronous request-reply which works well across shovels. It is going to be somewhat contrived since I'm building a generic bus int .NET using RabbitMQ as the transport, so please bear with me.</font><div>
<div><font class="Apple-style-span" face="'trebuchet ms', sans-serif">So far it used to work like this: when performing a request I created a temporary queue and sent its name in the ReplyTo field, then the receiver of the request sent its reply on the default exchange using this�queue name�as the routing key.</font></div>
<div><font class="Apple-style-span" face="'trebuchet ms', sans-serif"><br></font></div><div><font class="Apple-style-span" face="'trebuchet ms', sans-serif">Now what I would like to do it make it work across shovels, but my implementation (the way I would like it to be) ideally imposes some decoupling between the request message and the reply message which prevents me from being able to achieve this result.</font></div>
<div><font class="Apple-style-span" face="'trebuchet ms', sans-serif"><br></font></div><div><font class="Apple-style-span" face="'trebuchet ms', sans-serif">To explain, the request message and the reply message are supposed to be published to different exchanges to make it work across a shovel. This is because, supposing I have two servers, the request has to be published to an exchange that is "shoveled" from server1 to server2, while the reply in order to come back to the requestor needs to be published to an exchange shoveled from server2 to server1. I hope it makes sense so far.</font></div>
<div><font class="Apple-style-span" face="'trebuchet ms', sans-serif"><br></font></div><div><font class="Apple-style-span" face="'trebuchet ms', sans-serif">What I would like to do is avoiding, when performing the request, to know what exchange the reply will be published to, as I don't even want to let the requestor be aware of what kind of reply the application is going to receive; it could be a RequestSuccessfulMessage or a RequestFailedMessage for instance. Of course my application will have "handlers" for both of them, but the requestor needen't know about that.�</font></div>
<div><font class="Apple-style-span" face="'trebuchet ms', sans-serif">As an additional detail,�in the system I am setting up the channel that dispatches messages is already subscribing to the response exchange because, by convention, I am subscribing to all message types for whom there is a suitable consumer in the application by using their exposed exchange name (I decorate every message type with an attribute containing the name of the exchange that message type is published to) and a string representation of message type as the binding key, but in a request/reply scenario I don't want every instance of my application to receive the reply message, just the one which sent the request, therefore the reply has to come through a different combination of exchange/routing key.</font></div>
</div><div><font class="Apple-style-span" face="'trebuchet ms', sans-serif"><br></font></div><div><font class="Apple-style-span" face="'trebuchet ms', sans-serif">Any advice is welcome, you can look at the code <a href="http://code.google.com/p/mexexp/source/checkout">here</a>.�There is a failing test in�RabbitMQ\Tests.Integration\Bus\RequestReply\Request_and_reply.cs which exposes the problem. The tests are self contained except that they expect a rabbitmq server to be running on localhost (there is one embedded in the repo in folder RabbitMQServer, you can start that one directly)</font></div>