qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William Henry <whe...@redhat.com>
Subject Re: Proton Messenger and the Request/Response pattern
Date Fri, 04 Jan 2013 18:44:28 GMT
Hi Frase and others.


It is regrettable that there is so much confusion.  I understand where you're coming from.
Indeed I think I have had similar experiences with some of the changes that you have had and
are experiencing.

Before addressing some specific API issues I think it's first worth explaining Qpid Proton.
It looks like you have a handle on it now but I'll try to explain again as I understand it.

When looking at implementing AMQP 1.0 it was decided that rather than try to implement it
inside the much evolved Qpid, especially qpidd, it would be best to implement AMQP 1.0 as
a library that was plugable into other artifacts like qpidd (and for example ActiveMQ).  Let's
create a pure AMQP 1.0 implementation that can be consumed by others. It was decided to build
two libraries, one in C and one in Java. The Java can then be consumed by JMS implementation
such as Qpid or ActiveMQ or others. The C implementation can be the bases for other non-Java
implmentations, e.g. Qpid's C++.  With SWIG we could generate other language bindings on the
base API (called the Engine). 

As it turns out there was a second API build on top of the core Engine API. This Messenger
API provides a wrapper on top of the Engine to provide a very simple (yet very powerful) API
for develops that care little about complicated use cases but instead want to just publish
and subscribe for messages as simple as possible. This is a really cool for things like Python
and Ruby etc. But I've actually used the C based Messenger API to build bridge for the OpenMAMA
project. So far it seems to be working fine - but I can always go back to Engine if I find
I need some more complex semantics and message flows.

So Ted's email was, as the subject said, in reference to the Messenger API.  It is not to
do with the JMS API.

Many, or perhaps I should say several, of us believe that AMQP is not limited to traditional
MOM like deployments. We believe, in the near term, that AMQP will be used mostly for MOM.
 However in the future we see that AMQP could, if we don't screw it up, become a popular protocol
for building internet applications that require more asynch messaging patterns. AMQP can help
app developers avoid some of the unnatural gymnastics that they currently have to perform
when using HTTP.

For that reason we think the world won't all be about JMS - there will still be a lot of it
and, good news, it will interoperate with everything else.  Messenger allows app develops
access the power of messaging and in particular AMQP without having to learn much.  Having
said that if they want to dive in more they will find many common patterns and APIs to support
those patterns.

So Ted was looking at the current Messenger API that is part of Qpid Proton and saying, hey
for people using this API wouldn't it be nice if ...  Remember, people using the Messenger
API are not JMS developers.


Now the community does need to do a much better job of making these points clearer.  The websites
are, as you point out, not well linked or explained.

So here is some more explanation at a high level:

qpid::client the older API that exposed AMQP 0-10 artifacts like queues and exchanges

qpid::messaging the newer API that is more JMS like (even for C++) that recognized that AMQP
0-10 artifacts were not going to be part of the AMQP 1.0 spec.  

proton-c and proton-j part of qpid/proton qpid.apache.org/proton. These are libraries that
implement the AMQP 1.0 specification. They are intended to be consumed by clients and brokers
and other implementation that require AMQP 1.0 support. The project is slightly more than
the libraries in that it provides some tools for developers to help them consume AMQP 1.0
including Python, Ruby, Perl language bindings.

Proton Messenger API - a high level, simple but powerful wrapper on the core proton API to
provide easy access to AMQP messaging.

JMS implementations like Qpid proper and ActiveMQ (for example) can consume Proton. The C++
implementation in Qpid, including the broker, is planning on (has already been done I think)
integrating Proton for AMQP 1.0 support.

I know this doesn't answer all the questions but is this helpful? And others, did I get any
of this wrong?  I'm sure I've left bits out but is what I said accurate enough?

William

----- Original Message -----
> Hi Mary,
> Thanks for the response, unfortunately I must be a bit thick though,
> cause I'm still not totally clear.
> 
> I did take a look at the proton web site a little while back, looking
> at
> the link you attached it looks pretty much the same as the last time
> I
> looked a month or so back. But as I say the relationship between qpid
> and proton is far from clear (to me at least....)
> 
> I've just loaded up the main qpid website http://qpid.apache.org/ and
> there's no obvious linkage between that and proton so that's not too
> helpful. Also not helping with my confusion is that there has been
> quite
> a bit of traffic on the main qpid mailing list relating to work that
> Gordon Sim has been doing on qpid 0.2 there seem to be quite a few
> new
> features in this including replacing the flow-to-disk paging with
> something better, but Gordon has also been talking about adding AMQP
> v
> 1.0 functionality to qpid 0.2.
> 
> So is the AMQP stuff that Gordon is talking about just about
> combining
> in the proton library? Will the web pages for the qpid 0.2 release
> make
> all this clear.
> 
> I have to say that the proton work hasn't been especially well
> publicised, I only stumbled across it by accident a month or so back
> by
> noticing a reference to it in the mailing list so did some digging
> and
> eventually found the web page - and I look at the qpid mailing list
> pretty much daily.
> 
>  From your description below and from the web page it looks like
>  proton
> is primarily a library so you'd use it in combination with something
> like qpid, but is the idea that it could also be used "brokerless" so
> I'm thinking something analogous to say zeromq where say one might
> want
> an extremely lightweight messaging IPC mechanism between processes on
> the same host for example without the overhead of a full message
> broker
> process????
> 
> I noticed the proton API documentation - it looks very python centric
> at
> the moment, your maul below also suggests C++ but what's the state of
> Java support at the moment - looks like there's a proton-j download,
> how
> does that relate to JMS and the qpid Java client libraries??
> 
> The API stuff also makes me a bit nervous - relating on to the
> original
> thread spawning this question. The is already *way too much*
> confusion
> at the moment relating to qpid::messaging versus qpid::client, more
> or
> less once a week someone posts to the main qpid mailing list about
> that
> so I think it's really important that the relationship between qpid
> and
> proton is spelled out clearly in a very prominent place!! It sounds
> like
> for the most part that the proton APIs are lower level APIs so that
> for
> example a client would use qpid::messaging (or JMS) and that would
> delegate in the client runtime to the proton APIs, is that correct?
> So
> is the only time someone would actually use the proton API directly
> if
> one was running something embedded such as the lightweight messaging
> IPC
> analogy I mentioned above.
> 
> 
> Sorry if I'm being a bit thick about this, but as I say 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.
> 
> Regards,
> Frase
> 
> 
> On 03/01/13 20:00, Mary Hinton wrote:
> > I can't answer your other questions, but did anyone answer your
> > question on "What exactly is proton?
> > Have you gone to the proton web site:
> > http://qpid.apache.org/proton/
> >
> > Qpid was built around the older versions of the AMQP protocol.
> > Now that Proton is released, QPID can load the proton library and
> > be AMQP 1.0 compliant.
> > In the C++ code there are new AMQP projects, one for the server and
> > one for the client.
> >
> > After you compile and build all the required libraries (including
> > proton) and executables, you can use the qpidd executable with the
> > following argument
> > 	qpidd --load-module amqpd
> >
> > For the client you need to set up the environment variable
> > QPID_LOAD_MODULE and set it to the new amqp client project name,
> >   e.g. 	amqpcd
> >
> >
> 
> ---------------------------------------------------------------------
> 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


Mime
View raw message