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: [email protected]
For additional commands, e-mail: [email protected]
