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]
