The request/response pattern involves sending a message to a broker with a Reply property set to a QueueName to indicate to the receiver what to use for a return path.
All the slideshows I've seen show a Reply Queue as a single channel. This works fine when the listener on the other end knows how to broker the reply messages correctly on that queue. But, that can make dealing with messages received out of sequence more of a pain.
I've seen code that builds a new unique queue for every sent message to use for sending the reply on. Then after the receiver sends back the reply, the original sender takes the reply off the queue and deletes the queue. That seems like it could be a lot of temporary queue creation/destruction.
Another option I've seen is creating a single reply channel as a Topic, and then each original sender creates a new subscription on that topic that is filtered for the correlationID == sendersID. And then when the original sender receives that reply, they delete that subscription. But, again that seems like a lot of setup/tear-down, just to receive a message reply.
For Request/Reply correlation you generally have two options:
i) Correlate messages to/from a particular "Sender" or
ii) Correlate request/response on a per message basis
For Service Bus there are 3 key ways to achieve correlation:
1) Separate/Unique Queues per Sender (say a single Request queue and then one response queue per sender). This works well for the option i above where there is a fixed number of Senders since you can plan for capacity accordingly based on the quotas mentioned above (http://msdn.microsoft.com/en-us/library/ee732538.aspx)
2) Use Sessions within a single Queue to correlate between Senders/groups of messages. Sessions are very useful when you have ordering and state management requirements since they give you strict ordering as well as GetState/SetState to co-ordinate the progress of a particular session of messages. This can be used for both options above. More information on this is available here: - Session sample with Brokered messaging - Request / Response Queue using Sessions samples
3) Use Topics/Subscriptions to implement PubSub using filters. Here again if you want to create say a Subscription per Sender then you can achieve that using simple SQL filters. Using correlation filters will allow you to add/remove a large number of filters (100,000) per subscription and that way you can correlate on a per message basis. So for example you have 10 senders then you create one topic with 10 subscriptions. Every time a sender processes a request it sends a message and at the same time adds a correlation filter instance to its subscription containing the correlationid value for that message. When a response is received then that filter value is removed by the sender for that message. So each subscription can then maintain a set of filters that indicate a unique filter per message that the sender is expecting a response for.