qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: AMQP 1.0 support for JMS client via Proton
Date Thu, 20 Sep 2012 19:43:38 GMT
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.

> 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 

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.

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

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

View raw message