William, I see, there is work in progress and my concerns will get covered it future. Pretty good! Besides the SPOF and problems what I have in mind are two things: (a) massively distributed systems with no server at all (grid type applications where each client has its own local broker -- the shared memory transport is beneficial here), (b) clients with no LAN synchronizing queues every other day when getting their batteries loaded (a local broker will work here, too).
Sounds all pretty well for such a young software. I hardly can't wait for AMQP 1.0 and the first MSMQ release supporting it to try out communication between Qpid clients and MSMQ native clients... :-) Regards Markus > -----Original Message----- > From: William Henry [mailto:[email protected]] > Sent: Samstag, 21. Februar 2009 22:23 > To: [email protected] > Subject: Re: [Newbie Question] Why not sending to multiple brokers > directly from client? > > Hi Markus, > > Good question. There are several answers: > > 1. Qpid is not really client/server based (though that can be achieved > using the direct exchange). Qpid is broker based and therefore messages > go through this intermediary. This decouples the sender from the > receiver and allows many consumers to receive the same message without > putting the burden of delivery (including location and multiple > delivery) on the producer. > > 2. The broker abstraction, with it's exchanges, allow for several types > of patterns - hence the exchanges: direct, fanout, topic. And you can > add your own custom exchange. > > 3. So is the broker a single point of failure? Well there are a number > of things that address this and I'm sure Carl and others will weigh in. > But to address your chief concern there is federation and clustering. > Federation allows a group of brokers to cooperate by forwarding > messages from one broker to another to satisfy consumers that may need > to cross some boundaries. Clustering allows for high availability in a > cluster of brokers so that if any one broker goes down then there is > another to make sure that messages can be delivered. > > 4. Work is been investigated in using shared memory between a broker > and a client (producer or consumer) so that any network stack delays > can be eliminated. There is also the possibility of having a plugin to > the broker that would be a client so that it is in process. It's early > days yet but these approaches are been considered. > > William > > > > ----- "Markus KARG" <[email protected]> wrote: > > > Here is another newbie question...: :-) > > > > > > > > William Henry wrote: > > > > > > > > " So the producer posts messages using AMQP to an exchange on the > > broker and > > the message is transfered to the consumer(s) using AMQP." > > > > > > > > I wonder why the QPID client is sending to a QPID server first, which > > then > > will forward to a different vendor's server -- wouldn't it make sense > > if the > > QPID client directly sends to the different vendor's server and only > > does > > the detour via the QPID server if the different vendor's server is > > not > > accessible currently? This would increase the overall availability of > > the > > system, since each client will always find some broker being able to > > store > > and forward, even if the own QPID server is currently shut down. I > > mean, > > what should be the benefit of sending it via "the own" server always > > instead > > of first trying to deliver directly? > > > > > > > > Thanks > > > > Markus > > --------------------------------------------------------------------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:[email protected]
