On 01/04/2013 10:07 AM, Fraser Adams wrote:
I really haven't seen an awful lot of publicity around proton and how it relates to qpid so I think it'd be really good to get the documentation around the relationships properly sorted to avoid a whole world of confusion.
You are quite right. Communication has been very poor and we need to change that.
On 01/03/2013 09:14 AM, Fraser Adams wrote:
BTW what *exactly* is Proton, I've seen a few references to it but nothing is especially clear to me, is Proton the name for the AMQP v1.0 version of Qpid? How does it differ from say Qpid v0.20? Will Proton end up being Qpid v1.0?
Let me try and lay out my own understanding. Forgive me if it seems a little long-winded, it isn't really that different from what William described...
Qpid is an openly governed community that seeks to aid adoption of AMQP through collaborative development of various pieces of open sourced software. Historically that has included two different brokers, various client libraries and management tools. Although the different parts should combine well, not every user will want or need every component. Given the purpose of AMQP is to enable interoperability and choice, it is important that individual components from Qpid can be combined with other software and systems in a flexible manner.
Proton is a new component under the Qpid umbrella - a set of components is perhaps more accurate as there is both a java and c version and some swig wrappers. It is an AMQP 1.0 toolkit.
Part of this is a 'protocol engine'; an implementation of the rules specified by AMQP 1.0 in a manner that is independent of any threading model or IO mechanism. This makes it easier to integrate in diverse contexts including existing brokers and messaging clients and not limited to just those within Qpid.
One of the uses has been to add AMQP 1.0 support to existing Qpid components, such as the work I have been doing to add 1.0 support to the qpid::messaging API in c++ and to the qpidd (i.e. c++) broker. There has also been work to add 1.0 support to ActiveMQ, and that also uses the (java version) of the proton protocol engine.
Being independent of any IO framework is important for one set of use cases, but it does mean that the protocol engine isn't really usable 'by itself'. It was recognised that adoption of 1.0 would be aided by a simple, self contained library allowing sending and receiving of messages.
To that end the messenger API was added to the proton toolkit. This ties network IO into the protocol engine, exposing a simple abstraction of an input and output queue for messages, each message containing an address to which it is to be delivered. It manages connections, session and links under the covers. At present it is a blocking API though support for non-blocking use is likely to evolve as well.
AMQP 1.0 is fully symmetric (i.e a peer protocol) as opposed to its asymmetric (i.e. client-server) predecessors. This means it can be used with or without intermediaries such as brokers. The messenger API allows an application to listen for incoming connections as well as initiating its own outgoing connections. It can therefore be used for simple, direct communication as well as communication through intermediaries. (You can also for example use a messenger based application to accept connections from a qpid::messaging or even a JMS client).
Proton is on its own release cycle at present, reflecting the early stage in its lifecycle. So far all other Qpid components have been on the same release cycle. So the 0.20 release includes qpidd, qpid-server (i.e. the qpid java broker), a JMS client, the c++ qpid::messaging library (and the deprecated qpid::client library), the python qpid.messaging library (and older deprecated libraries), QMF tools, a JMX console etc etc.
The 0.3 release of proton on the other hand contains c and java libraries offering the protocol engine and messenger APIs (the java version of the messenger API has some outstanding issues still) as well as wrappers for python, perl and ruby. The 0.20 release of qpidd and qpid::messaging has an optional dependency on the c version of proton, which if available enables 1.0 support in those components. The subsequent release of those two components will contain enhanced support.
So, qpid::messaging isn't going away. A key goal for that API was to allow smooth transition to AMQP 1.0 and that is still something I am working towards (0.20 represents the first step). Support for JMS likewise will continue. However the messenger API is in my opinion a novel approach that is may also be interesting for many cases. Ultimately I think the different APIs offer different styles. While there may be certain things that can't be done in one or other, often it may come down to personal preference.
Ultimately the vision behind AMQP is all about choice; enabling the emergence of a rich palette of interoperable pieces from which diverse solutions can be flexibly composed. AMQP 1.0 in my opinion expands the opportunities here and rightly Qpid is innovating and evolving to exploit those.
These are exciting times! We do however need more open communication (and better documentation ;-).
--Gordon. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
