On 05/23/2013 11:08 AM, Bruno Matos wrote:
My motivation to use the domain feature has to do with sending messages from a service connected to source broker directly to a queue in destination broker, if you remember my first questions about it. But I don't know how can achieve that.
So, just to ensure I understand correctly, you have a service that subscribes to a request queue on broker A and a client that wants to use that service, connected to broker B. The client sends a message that should be transmitted across from B to A. The message contains a reply to that refers to a queue on B and responses should go there.
To achieve this with 0-10 based federation, you need to have the response queue bound to some explicit exchange (not simply the default exchange) and use that exchange in the reply-to address (along with a unique binding/routing key if the exchange is shared by other responses). E.g. create a 'responses' exchange (as a direct exchange) and then use 'response/#' as the address for the response receiver, passing the generated unique address in as the reply-to.
Part of the goals of the 1.0 federation equivalent was to make this more seamless/transparent and less dependent on pre 1.0 exchange types. You can configure each broker to know about the other (i.e. setup a domain), and then access queues on another broker through <queue-name>@<broker-name>. So for a my-responses queue on broker B, broker A could access that directly as my-responses@BrokerB (assuming a domain named BrokerB has been configured with the details of how to connect).
The next step is to make the qualification of the queue name by domain more transparent. For temp queues in 1.0, the broker assigns the name and passes this back to the client and the broker can be configured to add the necessary qualification transparently. I've just committed a fix to trunk that makes that work in such a way as to allow the client/server example shipped with the c++ messaging client to be able to be run against a pair of brokers without changing the examples themselves. That isn't possible yet on 0.20 (or 0.22) though I'm afraid, but hopefully it gives some idea of the motivation and direction.
And of course this is not limited to reply queues. You can use this to access nodes of any type in any other process that accepts 1.0 connections. E.g. if you have systems using ActiveMQ or SwiftMQ and need access to a particular piece of functionality or a particular source/sink for messages on those from clients connected to qpidd you can do that quite simply also (or even access a standalone proton based service).
--------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
