qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William Henry <whe...@redhat.com>
Subject Re: Qpid AMQP 1.0 - How does it all hang together? - was Re: Qpid Dispatch Router component
Date Wed, 09 Oct 2013 19:16:36 GMT
Great post! +1.

The community needs to do more to explain, document, and promote.


----- Original Message -----
> Hey all,
> The thread below on the dev list has prompted me to ask something that
> I've tentatively mentioned before, but am still a bit embarrassed to
> raise 'cause it probably makes me seem a bit stupid :-( here goes
> anyway.....
> So I've kind of held off going down the AMQP 1.0 path partly due to lack
> of time, but also partly due to lack of understanding of how it "all
> hangs together", the new website helps a bit - but TBH I'm still left
> scratching my head somewhat.
> I'll try to explain:
> Now I know that Proton is intended to be a component usable beyond just
> the Qpid "product set", but there's a "protocol engine" and a "messenger
> API" and I'm not even that clear on the relationship between the two of
> those - for example could one use the protocol engine completely
> independently (is there an engine API?) or is the messenger API intended
> to be the lowest "unit of currency", what would be the benefit using the
> raw engine?
> Then beyond that there's the relationship with say qpidd and
> qpid::messaging. Now I'm aware that when the Proton libraries are
> detected qpidd and qpid::messaging get built with Proton support, I'm
> "guessing" that in that case the relationship analogous to that of
> qpid::client where qpid::client was the low level AMQP speaking API and
> qpid::messaging provides a higher level abstraction, so I *think* that's
> the relationship with Proton there - but I'm not sure? Is the proton API
> close to the AMQP 1.0 specification in say the way that qpid::client was?
> But then there's more nuance, so I'm aware that with AMQP 1.0 there's a
> more peer-to-peer relationship and indeed the Proton tests seem to have
> msgr-recv and msgr-send talking directly to each other without a broker.
> So that leads me to ask the question what's the relationship with the
> broker - in other words what services are provided in messenger, what
> are enhanced in qpid::messaging and what are layered on top of that via
> the broker (and how does the addressing and routing work?).
> Some examples of where I'm befuddled include how does subscription work
> at a peer to peer level? For example I think that exchange nodes are
> only something I've heard discussed in the context of qpidd and
> similarly I think the same is true of message selectors, so does Proton
> only provide low level network connectivity and data serialisation (and
> possibly single client queue) and all the other stuff needed for
> connecting a network of clients are part of the broker services.
> I suppose what I'm really asking is what "services" are provided at each
> "layer" of the Qpid "stack" - clearly you can do useful stuff with just
> Proton - but what stuff and what are the limits? What would you then get
> from qpid:messaging and what then does the broker throw into the mix.
> Are there any diagrams that illustrate this sort of relationship?
> The dispatch router adds yet more nuance into the mix. From my (limited)
> understanding it seems to offer at least some of the same services as
> the broker - but I'm not quite sure what. In my case I've got a very
> large federated topology and I have lots of left hand systems feeding in
> to fewer systems towards the right. Given that it's only on the right
> hand side broker that I have lots of consumers doing complex
> subscriptions and the rest of the brokers are employing fairly simple
> queue routes I'm thinking that the dispatch router could ultimately be
> something to "tidy up" the left hand side of my system - but I'm not
> quite sure.
> Apologies if these seem silly questions, I'm sure that the answers are
> obvious to those who've been involved at the architectural stages, but
> ultimately from my perspective the overall holistic architecture isn't
> totally clear.
> Even at a basic level I've not actually noticed anything in the
> programming book
> http://qpid.apache.org/releases/qpid-0.24/programming/book/index.html
> that seems to mention even how to connect via AMQP 1.0 vice 0.10. I
> think that it has been mentioned on the mailing list by Gordon so I'm
> sure I could dig the info out, but is it missing from the docs (or am I
> just not looking hard enough). On a similar note for Proton the
> msgr-send and msgr-recv examples are fine as far as it goes, but I'm
> thinking that to figure out how to do anything more complex my best bet
> is likely to be to "reverse engineer" the qpid::messaging bindings - I
> can't see anything obvious for how to send a map for example. I'm
> guessing that Proton is just as erm "nuanced" as qpid::client, so really
> powerful and flexible, but you have to know what you're doing to get the
> best (say performance) out of it, the API documentation looks pretty
> decent to be fair but I'm not sure that's enough to help me drive it
> really effectively.
> On top of that there seems to be a growing number of JMS clients,
> there's the original AMQP 0.10, there's an AMQP 1.0 one in the main Qpid
> tree and there's a separate Proton based AMQP 1.0 one that's a separate
> component (in a similar vein to Proton). I can see that the increased
> modularisation is a good thing and I assume that at some point the
> original AMQP 1.0 JMS client will be deprecated in favour of the Proton
> based one, but at the moment it's all a bit confusing without anything
> that describes the relationship between then. I'm gleaning what little
> knowledge I have out of a range of threads on the mailing list and I've
> probably missed something.
> I'm sorry if this comes across in any way as critical in email form,
> it's really not intended to, I'm just keen to finally make a proper
> start on my AMQP 1.0 journey and to be honest I feel a little out of my
> depth at the moment :-(
> Blame Ted for prompting me to write this ;->
> Cheers,
> Frase
> On 09/10/13 17:20, Rob Godfrey wrote:
> > Hi Ted,
> >
> > I think before we make this a full sub project, it would be good to have
> > clarity on exactly the proposed scope of Dispatch, how it is expected to
> > interact with other components within Qpid, or within wider AMQP networks.
> > I think in retrospect we didn't do this clearly enough with Proton (for
> > example).
> >
> > Moreover I would personally like to understand which AMQP standards it will
> > be looking to implement, and which not.  For instance I notice this line in
> > the docs for Dispatch:
> >
> > *Address**Description* /_local/agentThe management agent on the attached
> > router/container. This address would be used by an endpoint that is a
> > management client/console/tool wishing to access management data from the
> > attached container.
> > Which doesn't seem to conform with the proposed management specification
> > for AMQP, nor does the document make any mention of how dispatch is to be
> > managed.
> >
> >
> > Cheers,
> > Rob
> >
> >
> > On 9 October 2013 17:22, Ted Ross <tross@redhat.com> wrote:
> >
> >> The AMQP Router project (Qpid Dispatch, announced previously on the user
> >> list) is gaining in community interest and is nearing the point where a
> >> first release is appropriate. In preparation for a release, I proposethat
> >> this sub-project follow the lead of both Proton and the AMQP1.0 JMS
> >> projects. This involves:
> >>
> >> 1. Moving the code from qpid/extras to
> >>     http://svn.apache.org/repos/**asf/qpid/dispatch<http://svn.apache.org/repos/asf/qpid/dispatch>
> >> ,
> >> 2. Requesting, by vote, the creation of a JIRA project to track its
> >>     issues and releases.
> >>
> >> Unless there are objections, I will move forward with the above two tasks.
> >>
> >> Regards,
> >>
> >> -Ted
> >>
> >>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org

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

View raw message