Thanks very much Gordon. I have had some previous endeavours with the dispatch router (in fact I started there before switching to the broker) and will return to that plan of attack.
I think we will still need brokers in this topology in order to queue messages for offline clients, otherwise the router would be the better option. I look forward to future releases with the improved broker integration! /Chris 2014-03-28 15:52 GMT+00:00 Gordon Sim <g...@redhat.com>: > On 03/28/2014 01:36 PM, Chris Richardson wrote: > >> Ah, now we are really opening Pandora's box! ;) >> >> The term "client" here is actually quite a simplified term and actually >> refers loosely speaking to a system managing a number of products on >> that... client. Both the management system and the products should be >> individually identifiable and addressable over AMQP; it should also be >> possible to address them in groups. Furthermore the client system will >> typically be connected over an unreliable network link and the messaging >> system is expected to guarantee delivery. Given these constraints I >> envisage each client system having at least one local exchange (and queues >> to cope with disconnections), and most probably it/they will be topic >> exchanges to support the addressing functionality. However I'm very new to >> the AMQP routing and addressing concepts so I may be misguided. >> > > Even with dynamic routing, you need to manually set it up per exchange > (what it then does is manage the set of routing keys in use for > inter-broker links, based on the interest expressed by subscriptions). > > If you are using topic exchanges you might be able to simply forward all > messages for a given exchange through from A->B->C, which you can do by > simple static routes per exchange (not actually any more management > operations than making setting up dynamic routing for the same exchange). > The static routes *should* work ok with 'push' routes (though I will warn > that those are not as well used), allowing you to choose the direction of > the TCP connection independent of the direction of message flow. > > Also, without wanting to confuse the picture too much, I'll just note in > passing that the recent developments around AMQP 1.0 may be of some > interest to your scenario. First off there is the 'Dispatch Router' > component. This is superficially similar to a broker, but it only forwards > messages it never accepts responsibility for them. It could be used as the > 'server' broker in your setup, with the 'clients' both connecting in and > sending or receiving to/from that. You could use this in conjunction with > qpidd (which supports establishing basic AMQP 1.0 links to/from other > processes), or depending on your use case there may not be a real need for > brokers at all. > > (A future release of the router will be able to establish links out to > other 1.0 capable brokers (or other types of 'thing') itself making it even > more flexible/powerful). > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > For additional commands, e-mail: users-h...@qpid.apache.org > >
