qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject what *exactly* is Proton? (was Re: Proton Messenger and the Request/Response pattern)
Date Fri, 18 Jan 2013 16:51:04 GMT
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 

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 ;-).


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

View raw message