Continuing the thoughts from the previous post.... Adding two sets of source/destination is pretty trivial (Perhaps differentiate bridges by calling them OneWayBridge and TwoWayBridge?). Without using temp destinations we could just keep track of original messageid's and original ReplyTo destinations from JBM and their corresponding remote messageid. Then, when the message is received from the remote provider (using JMSCorrelationId to link request/response), we could look up the correlationid on it and find the original data, replacing it before sending to a JBM destination. A lookup table would need: originalJBMJMSMessageId - originalJBMReplyTo - remoteJMSMessageId With temp destinations it becomes even more powerful (but requires more support on the remote side, both client and server). In this case we don't need to keep track of the remote messageid, since we know that messages received on the temp destination are a reply to a specific JBM message. The downside is that the receiving part of the bridge would need to listen to a temp destination (or use unique selectors on a shared destination). Come to think of it, selectors would actually suffice and be cleaner, but maybe theres an anti-pattern there somewhere. * JMS Message arrives at a JBM destination * TwoWayBridge receives it, sees that it has a ReplyTo destination, keeps track of the original replyto destination and jmsmessageid * TWB creates a remote temp destination * TWB sends the message with the remote temp destination as the ReplyTo value, after send() it adds the remoteJMSMessageId to the same record * TWB begins listening on the remote temp queue (it now knows which message it is waiting for a response to) * TWB receives a response from the remote provider on the temp destination * TWB replaces the correlationid and the replyto values with the original ones * TWB sends to a JBM destination View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4052056#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...