So I had a look at qpid-dispatch, but it doesn't seem to solve our problem. Unless I'm misunderstanding, the way it works is that a client (consumer/producer) connects to the router, which then links it to another endpoint – a queue inside a broker, or producer/consumer. In our scenario we want something that independently forwards messages between queues in different brokers.
Here's an illustration: <http://activemq.2283324.n4.nabble.com/file/n4729171/Corda_Messaging.png> A client connects to the broker, posts a message to the "outgoing" queue and waits for a response on the "incoming" queue. The message then gets forwarded to an "incoming" queue on another broker, where it gets processed by the recipient. A response is sent back the same way. The blue lines currently represent Core bridges. What we want to achieve is have a bridging mechanism that works over AMQP, so e.g. Broker 1 could be Artemis and Broker 2, say, Qpid. It may well be that JMS bridges is the best solution here, but the docs mention that it's less performant (are there any rough perf metrics for Core vs JMS bridges?), so I was wondering how difficult it would be to build a custom Core -> AMQP bridge (even if it only works one way in this case). Our second concern is backwards-compatibility, and having all communication done via AMQP solves that. Are there any backwards-compatibility guarantees for the Core protocol? Thanks again for your help! -- View this message in context: http://activemq.2283324.n4.nabble.com/Artemis-AMQP-bridges-tp4728934p4729171.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
