qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tor Rune Skoglund <...@swi.no>
Subject Re: Getting started with Qpid
Date Thu, 16 Jan 2014 14:45:28 GMT

thanks a lot! This was the kind of "missing link" information I needed. :-D

I could suggest that this info should be added to the web page, with
some "Understanding the basics" or "Dummies intro" heading or something.
I am sure a lot of new users would appreciate this.

Best regards,
Tor Rune Skoglund, trs@swi.no

Den 15. jan. 2014 14:00, skrev Gordon Sim:
> 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