qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rafael Schloming <...@alum.mit.edu>
Subject Re: Java broker queue questions....
Date Tue, 12 Mar 2013 13:48:58 GMT
On Sun, Mar 10, 2013 at 3:14 PM, Rob Godfrey <rob.j.godfrey@gmail.com>wrote:

> On 10 March 2013 16:29, Fraser Adams <fraser.adams@blueyonder.co.uk>
> wrote:
> [.. snip ..]
> >
> > As a philosophical question, given all of the quirky little differences
> an
> > interesting question might be "what exactly is Qpid"? there's two AMQP
> > brokers, but both quite different, supporting different queue and
> exchange
> > types and even with different declaration options, I guess they evolved
> > separately so perhaps it's not surprising but it's *really* confusing :-)
> So my take on what "What is Qpid?" is that Qpid is the Apache
> implementation of AMQP, and should aspire to be the de facto reference
> implementation of AMQP.
> Qpid started out speaking AMQP 0.8 which was very much a definition of
> a client/broker model with defined broker semantics.  At the time I
> think it was envisioned that extensions would come through exchange
> types, and possibly sub-protocols (don't ask!).  As the AMQP community
> has evolved and learned from its earlier work we have moved away from
> specifying in terms of a "client" and a "broker" into a notion of a
> network of AMQP peers.  This provides for much more interesting
> scenarios than a strict client <-> broker <-> client model.
> Because of the history of Qpid, where people wanted to use AMQP but a
> feature was not standardised in the protocol, then the temptation has
> been to add bespoke extensions into our implementations to meet those
> requirements.  This has led to the two brokers growing functionality
> often in similar but incompatible ways as developers have dine their
> best to meet users needs from messaging products.  In hindsight we
> could definitely have managed this feature growth in a better way.
> What I would like to see going forward is that we align our
> implementations with AMQP standards... where we have a feature that
> isn't a standard then we look to see how we can get that feature
> "standardised". Where a feature is being standardised then we as the
> Apache Qpid community should be looking to be amongst the first, if
> not the first, to implement.  Many members of the Apache Qpid
> community are prominent players in the OASIS AMQP standardisation
> process... Steve Huston chairs the Bindings and Mappings Techincal
> Committee, I am one of the two co-chairs of the core AMQP Technical
> Committee, Rafael Schloming and I were both editors of the AMQP 1.0
> specification.
> What does this mean in terms of branding, cohesion and
> interoperability? I think if people want to use AMQP, Qpid should be
> their first port of call.  We should be aiming to be *the* place
> people go for libraries and components which interoperably speak AMQP
> 1.0.  Interoperability doesn't just mean within the Qpid suite, but
> with all other AMQP compliant implementations.  That means a lot more
> focus on "client" libraries than we have previously had.  In terms of
> the existing brokers... As above would be focussing on driving
> interoperability and cohesion by driving standards.  While it is
> useful for the Java and C++ brokers to do the same things in the same
> way... it is *much* more useful if I can also use the same tooling to
> make ActiveMQ, Microsoft's ServiceBus or SwiftMQ do the same thing.
> I know Justin has suggested retrospectively naming the existing
> brokers so that we can better distinguish between the Qpid project and
> the existing components... as the project as a whole aims to be much
> more than a couple of message brokers and client libraries aimed at
> working with them.  I'm not sure how I feel about that, but we do need
> to do a much better job at articulating what the project vision is,
> and who is the target user for the various components that make up the
> whole.
> The above are my personal views - I'm sure others may differ, and I'd
> be interested to hear their thoughts.

I largely agree with what you've said, however a few thoughts come to mind.

First, because AMQP 1.0 is different and so much more general than previous
versions, I think the notion of a reference implementation of AMQP has
problems as a way of defining scope. Strictly speaking, AMQP 1.0 is a very
general purpose protocol that could be used by any network application (not
just message brokers), and therefore a reference implementation that makes
no choices beyond what is defined in the spec would be limited to a general
purpose protocol implementation like the protocol engine that Proton

There are, however, a whole host of intermediaries, (brokers, proxies,
gateways, etc) that form key infrastructure for building distributed
systems, and it would certainly be very handy to have good versions of
these that speak AMQP in a first class way. There is a slippery slope here
though since you could build an AMQP controlled networked toaster and
unlike the previous examples, that wouldn't necessarily fit in as part of

Gven the above and the fact that not everyone necessarily knows what AMQP
is, I think we should be able to define what we are and where we are going
without so heavily referencing AMQP.

Finally, I've seen your view and similar views expressed a number of times
now. There appears to be strong consensus that there is a problem here, and
rough agreement on the nature of the problem, yet no concrete action ever
seems to arise despite several attempts (e.g. Justin's retrospective naming
changes and web site work). I don't mean to single you out or anything, but
I feel like there has been general apathy (myself included) on this front
when it comes to taking real action, so I have to ask: what do you suggest
we actually do to address the problem?

FWIW, I think the retrospective naming is something small and concrete that
we could actually do about the problem, and it strikes me as better than
doing nothing, so I'd be in favor.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message