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.
2014-03-28 13:00 GMT+00:00 Gordon Sim <g...@redhat.com>: > On 03/28/2014 12:53 PM, Gordon Sim wrote: > >> On 03/28/2014 11:22 AM, Chris Richardson wrote: >> >>> Static routes might be ok for a prototype, but a production system would >>> have many hundreds or even thousands of clients frequently being added >>> and >>> removed. My assumption is that a static configuration would incur a much >>> higher management overhead? >>> >> >> It really depends on the messaging patterns between the clients. At one >> extreme, if each client was using the same 'topic' (whether sending or >> receiving), then the static configuration would be very simple. At the >> other extreme if each client would require extra routes to be defined, >> then yes, that would be an unwieldy solution most likely. >> > > Putting the question a better way, how many different exchanges will you > be using and what will be the type of the exchange(s)? > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > For additional commands, e-mail: users-h...@qpid.apache.org > >
