qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: Getting started with Qpid
Date Wed, 15 Jan 2014 13:00:48 GMT
On 01/10/2014 06:07 PM, Tor Rune Skoglund wrote:
> So what do I need to get started? Proton only, or Proton + a broker like
> the C++ one? Or just Proton? Is the Dispatch Router optional? It is
> "built on Proton" ? Does it "include" Proton then? Is there any point in
> having the router and a broker? Whatwhatwhat? :)
> My point is, it would help if there were some kind of "Dummies guide" or
> "Getting Started" link on the web page. For those of us that have not
> done much practical work with of "queues", "brokers", "routers",
> "whatevers", the terminology makes little sense and getting along with
> the first steps are a little bit frustrating.
> Basically, I want to deliver messages with some kind payload, from A to
> B, or B to A - or even from A to all Bs - reliably, quickly, and some
> kind of automagic resume in case there is a network outage during the
> delivery, and a yummy API for my application (in C++ or PHP).
> Where to go next?

Very fair point! Thanks for the feedback and the list of questions. I've 
tried to take a quick sweep at answering them to see if this is the sort 
of information you would like to see and to get further feedback on gaps 
or things that are still not clear.

Proton is a library to help things that want to speak AMQP 1.0.

At present its really two distinct APIs. One is entirely independent of 
any IO approach, it is just a protocol engine that takes bytes in and 
give bytes out without caring where those bytes came from. The other is 
a more complete solution that handles connecting, reading & writing 
sockets etc, this is called the 'Messenger API'.

Some AMQP 1.0 enabled components within Qpid use the proton engine for 
this support (qpid::messaging, c++ broker, dispatch router etc).

The messenger API allows processes to communicate without any 
intermediary. It can also be used to communicate through an intermediary 
such as the c++ or java brokers or the dispatch router. Whether you 
need/want an intermediary depends on how complicated the communication 
patterns are (and how many different processes need to communicate).

Intermediaries work by having both the sending process and the receiving 
process connecting to the intermediary, and relaying or forwarding the 
messages from the sender to the receiver. This prevents either sender or 
receiver having to accept incoming connections, or even from knowing 
where the other party is located.

The store-and-forward pattern offered by some intermediaries allows the 
producer to send a message for eventual delivery to the receiver even if 
the receiver is not connected at the time of sending. This pattern is 
the common one for traditional message brokers. These use message queues 
in which to store messages until they can be delivered to the/an 
intended receiver.

Intermediaries can also relay or forward the message from one sender to 
many receivers. This saves the sender from having to connect to all the 
receivers itself. This is the 'pub-sub' pattern. The pub-sub and 
store-and-forward patterns can be used together.

Reliable message delivery works by having receivers confirm that they 
received messages. Until confirmed by a receiver, sent messages are 
considered 'in doubt'. If a failure occurs, in doubt messages can be 
resent. This gives an 'at-least-once' delivery guarantee. Assuming the 
failure is transient in nature, messages will be delivered to the 
receiver, but they may be delivered more than once. (This happens when 
the receiver did get a message, but where the sender did not receive the 
confirmation before the failure).

The stronger, exactly-once delivery guarantee requires some mechanism to 
detect and eliminate duplicates.

Traditionally, most brokers will confirm receipt of a message to the 
sending application independently of delivering that message to a 
receiver or getting confirmation that the receiver actually received it. 
This is again the store-and-forward pattern.

A key distinction between brokers and the dispatch router is that the 
latter doesn't offer store-and-forward. It will route the messages it 
receives to the applications they are intended for and can support the 
pub-sub pattern, but if there is no receiver it won't generally hold on 
to the message on the senders behalf. Reliability guarantees with the 
router are end-to-end, i.e. when the receiver(s) confirm receipt, that 
confirmation is passed back to the original sender. Brokers will also 
tend to have some more advanced/specialised features such as 
transactions, last-value-queues, prioritised delivery, durability, 
message selectors etc.

Dispatch router is an intermediary designed from the start to be 
distributed. A network of dispatch routers can handle redundant paths, 
which provides a useful tool in building resilient communication channels.

Brokers can be connected to the dispatch router network also, e.g. to 
provide some store-and-forwarding guarantees where needed, or as a way 
of getting specialised broker behaviour.

To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

View raw message