qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Godfrey <rob.j.godf...@gmail.com>
Subject Re: Java broker queue questions....
Date Sun, 10 Mar 2013 19:14:01 GMT
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

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

The above are my personal views - I'm sure others may differ, and I'd
be interested to hear their thoughts.

-- Rob

> I've mentioned this casually to Gordon Sim, but I think that I'm more
> adamant about this than ever now. I *really* think that some effort needs to
> be put into "branding" Qpid. Part of that is about providing maximum
> cohesion and interoperability between the brokers and the client libraries.
> Particularly now that Proton appears to be being used in say ActiveMQ for
> AMQP 1.0 support I think it becomes all the more important to have the "big
> set of features" like you have on shrink wrapped software so users know what
> Qpid is and so when someone is tasked with selecting between a big list of
> Messaging platforms it really jumps out why Qpid is the right choice!!
> Cheers,
> Frase
> ---------------------------------------------------------------------
> 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