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 Thu, 20 Sep 2012 19:16:52 GMT
On Thu, Sep 20, 2012 at 2:36 PM, Gordon Sim <gsim@redhat.com> wrote:
> On 09/20/2012 01:52 PM, Rajith Attapattu wrote:
>>
>> Steve, there has been several inquiries about using AMQP in mobile
>> environments.
>> I would assume Messenger API (defined in proton) is going to be more
>> attractive in those env's due to it's low footprint.
>> JMS may not be as attractive an option as the above (or even the
>> Messaging API defined in Qpid) due to dependencies and even
>> restrictions in some cases.
>> For example the javax namespace is not allowed in Android.
>
>
> Certainly the javax related baggage that comes with JMS is a drawback in
> certain environments. The current JMS interface also has some functional
> deficiencies (e.g. no confirmation of asynchronous sends).
Indeed. There are workarounds, but none of them are as effective as we
would like it to be :(

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

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.

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

>
> 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.
There could be other factors for and against that I might not have
thought about yet. These were the ones that came to my mind.
How much the above factors come into play is up for debate.

To be very clear, I wasn't discounting the value of a java
implementation of the Qpid API.
Instead was looking at how we could arrive at a JMS implementation and
what the possible paths are.

> You say you believe we should seriously consider option #1. What do you see
> as the advantage of that over #2? Is it simply avoiding the maintenance of
> another public API?
See above.

> I agree very much with Rob's point on the need for greater clarity on the
> functionality offered by different APIs.

+1 to that!

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


Mime
View raw message