qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rajith Attapattu <rajit...@gmail.com>
Subject Re: AMQP 1.0 support for JMS client via Proton
Date Fri, 21 Sep 2012 21:51:28 GMT
On Thu, Sep 20, 2012 at 3:43 PM, Gordon Sim <gsim@redhat.com> wrote:
> On 09/20/2012 08:16 PM, Rajith Attapattu wrote:
>> On Thu, Sep 20, 2012 at 2:36 PM, Gordon Sim <gsim@redhat.com> wrote:
>>> However I am curious as to what dependencies and/or restrictions the Qpid
>>> messaging API imposes?  Also what precisely you mean by footprint here
>>> and
>>> why the Messenger API would necessarily have a lower footprint?
>> I can't think of any jvm level restrictions on the Qpid API if done
>> correctly.
>> But I suspect we will use log4j at the least as an external dependency.
>> However I agree that we could make a concious effort to ensure we
>> don't use any dependency even at this level.
>> (Ex by using jdk logging.)

> That seems orthogonal to the API. Either you offer configurable logging in
> the implementation or you don't; either you roll your own or you don't.

Gordon I'm not comparing the API's here. I'm comparing the
*implementations of those API's*.
My assumption is that the Qpid API implementation will likely use a
logging fa├žade like slf4j and perhaps some other dependencies, while
the Messenger implementation will be dependency free and more compact.
That is why I said the Messenger API will have a lower footprint.

>> If we do so then I see no difference or special advantage of the
>> Messenger API over the Qpid API.
>>  From an API perspective I don't think think one is better than the
>> other. They both seem to have their applicability.
>> By footprint I was referring to size in bytes from the dependencies.
>> My answer for based on the assumption that the Qpid API implementation
>> will have one or more deps.
> Other than logging what dependencies do you foresee? Would they be in
> support of functionality required by the messaging API by not by the
> messenger API?
>>> In your original point on the two routes to 1.0 support in JMS (not
>>> forgetting of course that 0.18 already has full JMS support over AMQP
>>> 1.0,
>>> verified both against the Qpid java broker and SwiftMQ), you have
>>> 'Proton'
>>> as the base in both cases but don't say specifically which part of it you
>>> mean -  I assume you mean the engine?
>> I believe we have two options there as well.
>> 1. Use the engine
>> 2. Use engine + driver
>> Which is more applicable is debatable at this point.
>> I haven't thought much about it yet, so don't have an opinion yet.
> Yes, I was counting both of these variations as engine based
> implementations.
> I wouldn't consider my point of view at all firm on this, but I would it
> seems to me that there are already IO frameworks in Java and it would be
> worth looking at some of those before going ahead an implementing something
> new. Specifically we should be clear on what we gain by (to some extent)
> reinventing the wheel there.

Indeed a very valid point. I also don't have a firm opinion on this yet.
I have some limited experience in exercising the Driver when writing
the mailbox example but not enough to form a more qualified opinion on
it's advantages and applicability in more complex situations.

>>> If so, the one observation I would offer is that the bulk of the work
>>> needed
>>> for something like the API currently available in c++ in the
>>> qpid::messaging
>>> namespace would be required there anyway. It is after all very similar in
>>> style to JMS without the issues mentioned above. My instinct is that
>>> having
>>> an explicit interface somewhere between the JMS and Proton Engine APIs
>>> will
>>> actually contribute to a cleaner simpler implementation.
>>> The question then seems to me whether there is value in exposing that
>>> interface, and offering user the option of avoiding the limitations
>>> imposed
>>> by JMS without loss of functionality and keeping a similar style. I
>>> myself
>>> believe there is.
>>> The Messenger API, at least as I understood it, was to be for the
>>> simplest
>>> use cases. Would a more fully functional API without the baggage of JMS
>>> but
>>> offering similar (indeed a little expanded) level of functionality not be
>>> valuable? I myself believe it would.
>> If we did chose option #2, I wasn't suggesting we shouldn't have a
>> Qpid API implementation.
>> In that case we could have,
>> JMS Client --> Proton
>> Qpid API --> Proton
>> The downside for the above approach is possible duplication of code.
>> A possible advantage could be that each implementation could be very
>> focused and evolving the Qpid API will not impact the JMS
>> implementation.
> In terms of focus, I do honestly believe that they would require very much
> the same code in both cases. The central pattern is the coordination between
> (an) application thread(s) and (a) io/driver thread(s). The functionality is
> also similar - optionally sync or async publication, prefetched,
> server-pushed subscriptions and client-pulled receivers, acknowledgements
> etc.
> Again I suspect that even if you didn't expose the interface, having it
> explicitly defined as part of the internal architecture would lead to a
> cleaner solution overall.

I agree with you that there is a lot of overlap btw the JMS and Qpid
API in terms of functionality and behaviour.
Infact the Qpid API seems like a superset of the JMS API

I also agree from a design point of view it seems cleaner.
But as I said I'm not discounting either approach. It's always good to
investigate all approaches and look into all kinds of factor not just

Until recently I have considered only option #1 (JMS --> Qpid API -->
Proton, but I have heard people looking at option #2 as well.
It's always good to consider all options and then choosing what the
majority feels the best.
As of now I don't have a firm opinion either way. I just merely wanted
to lay the options on the table and initiate a discussion.


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

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

View raw message