You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Rajith Attapattu <ra...@gmail.com> on 2012/09/20 00:32:04 UTC
AMQP 1.0 support for JMS client via Proton
Hi All,
There are a few folks who are keen to have AMQP 1.0 support for our JMS client.
Given that the parent AMQP TC is starting a bindings and mappings TC
which will cover JMS, I thought it would be a good idea to get a
discussion going on here as well.
We could aim to build the client as we progress through the TC and
provide feedback if necessary.
On the hand, we've had extensive discussions on building a new JMS
client from scratch when adding 1.0 support.
The primary motivation was to address some of the nagging issues
around the old client.
So far there have been two schools of thought on how to get AMQP 1.0 support.
1. JMS Client --> Qpid API --> Proton
2. JMS Client --> Proton
While option #1 seems like killing two birds with one stone, I think
we should seriously consider option #2 as well.
I would love to hear everybody's thoughts on this.
More importantly it's good if we could also discuss on a plan and set
some milestones to ensure we stay focused.
Personally I would love to see a reasonably working prototype by 0.22.
If we can get something going for 0.20 that would be a bonus, even if
it's just experimental (preferably on a branch) and Alpha quality.
I mentioned the above milestones to kick start the discussion and get
things rolling.
We could start on a branch and then move it to trunk during 0.22 if
everybody is satisfied with the progress.
Regards,
Rajith
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: AMQP 1.0 support for JMS client via Proton
Posted by Rajith Attapattu <ra...@gmail.com>.
On Thu, Sep 20, 2012 at 4:00 AM, Rob Godfrey <ro...@gmail.com> wrote:
> On 20 September 2012 00:32, Rajith Attapattu <ra...@gmail.com> wrote:
>
>> Hi All,
>>
>> There are a few folks who are keen to have AMQP 1.0 support for our JMS
>> client.
>> Given that the parent AMQP TC is starting a bindings and mappings TC
>> which will cover JMS, I thought it would be a good idea to get a
>> discussion going on here as well.
>> We could aim to build the client as we progress through the TC and
>> provide feedback if necessary.
>>
>> On the hand, we've had extensive discussions on building a new JMS
>> client from scratch when adding 1.0 support.
>> The primary motivation was to address some of the nagging issues
>> around the old client.
>>
>> So far there have been two schools of thought on how to get AMQP 1.0
>> support.
>>
>> 1. JMS Client --> Qpid API --> Proton
>>
>> 2. JMS Client --> Proton
>>
>> While option #1 seems like killing two birds with one stone, I think
>> we should seriously consider option #2 as well.
>>
>>
> So, regardless of which path we take I think we need to carefully define
> the functional requirements for our JMS client. Looking at the JIRAs, and
> based on the experience of supporting the current client, the two areas
> where it causes most problems are 1) failover and 2) addressing.
>
> For both (but especially failover) I think we need a very clear
> understanding of the functionality we are looking for the client to provide
> before we can decide which layer it is best placed in. If the functionality
> is likely to be common across the JMS and Qpid APIs then it would seem
> sensible not to write this code directly into the JMS layer.
>
> Before we start cutting any code I think we need general agreement in the
> Qpid Java community about the functionality that is required and where it
> is going to be implemented (and ideally we should also be coordinating by
> whom it is going to be implemented also :-) ).
Indeed! My intention was to get this conversation happening and for us
to start formulating a plan.
As I mentioned in my original email, a plan is very important, so we
know who's doing what and more importantly some milestones as to when
we can expect things to happen.
I agree with you about the main problem areas.
I also think we need to pay very close attention to our threading and
synchronization strategies as we have quite a few issues there.
We should put up a page on wiki to document the requirements and have
a conversation happening on the lists to come to an agreement.
We should then define milestones and deliverables. Without that it's
going to be meaningless.
Once we do that we could start coordinating about the code
contributions and adjust the plan if we feel we have resourcing
issues.
Rajith
> -- Rob
>
>
>
>> I would love to hear everybody's thoughts on this.
>> More importantly it's good if we could also discuss on a plan and set
>> some milestones to ensure we stay focused.
>>
>> Personally I would love to see a reasonably working prototype by 0.22.
>> If we can get something going for 0.20 that would be a bonus, even if
>> it's just experimental (preferably on a branch) and Alpha quality.
>>
>> I mentioned the above milestones to kick start the discussion and get
>> things rolling.
>> We could start on a branch and then move it to trunk during 0.22 if
>> everybody is satisfied with the progress.
>>
>> Regards,
>>
>> Rajith
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: dev-help@qpid.apache.org
>>
>>
Re: AMQP 1.0 support for JMS client via Proton
Posted by Rajith Attapattu <ra...@gmail.com>.
On Thu, Sep 20, 2012 at 4:00 AM, Rob Godfrey <ro...@gmail.com> wrote:
> On 20 September 2012 00:32, Rajith Attapattu <ra...@gmail.com> wrote:
>
>> Hi All,
>>
>> There are a few folks who are keen to have AMQP 1.0 support for our JMS
>> client.
>> Given that the parent AMQP TC is starting a bindings and mappings TC
>> which will cover JMS, I thought it would be a good idea to get a
>> discussion going on here as well.
>> We could aim to build the client as we progress through the TC and
>> provide feedback if necessary.
>>
>> On the hand, we've had extensive discussions on building a new JMS
>> client from scratch when adding 1.0 support.
>> The primary motivation was to address some of the nagging issues
>> around the old client.
>>
>> So far there have been two schools of thought on how to get AMQP 1.0
>> support.
>>
>> 1. JMS Client --> Qpid API --> Proton
>>
>> 2. JMS Client --> Proton
>>
>> While option #1 seems like killing two birds with one stone, I think
>> we should seriously consider option #2 as well.
>>
>>
> So, regardless of which path we take I think we need to carefully define
> the functional requirements for our JMS client. Looking at the JIRAs, and
> based on the experience of supporting the current client, the two areas
> where it causes most problems are 1) failover and 2) addressing.
>
> For both (but especially failover) I think we need a very clear
> understanding of the functionality we are looking for the client to provide
> before we can decide which layer it is best placed in. If the functionality
> is likely to be common across the JMS and Qpid APIs then it would seem
> sensible not to write this code directly into the JMS layer.
>
> Before we start cutting any code I think we need general agreement in the
> Qpid Java community about the functionality that is required and where it
> is going to be implemented (and ideally we should also be coordinating by
> whom it is going to be implemented also :-) ).
Indeed! My intention was to get this conversation happening and for us
to start formulating a plan.
As I mentioned in my original email, a plan is very important, so we
know who's doing what and more importantly some milestones as to when
we can expect things to happen.
I agree with you about the main problem areas.
I also think we need to pay very close attention to our threading and
synchronization strategies as we have quite a few issues there.
We should put up a page on wiki to document the requirements and have
a conversation happening on the lists to come to an agreement.
We should then define milestones and deliverables. Without that it's
going to be meaningless.
Once we do that we could start coordinating about the code
contributions and adjust the plan if we feel we have resourcing
issues.
Rajith
> -- Rob
>
>
>
>> I would love to hear everybody's thoughts on this.
>> More importantly it's good if we could also discuss on a plan and set
>> some milestones to ensure we stay focused.
>>
>> Personally I would love to see a reasonably working prototype by 0.22.
>> If we can get something going for 0.20 that would be a bonus, even if
>> it's just experimental (preferably on a branch) and Alpha quality.
>>
>> I mentioned the above milestones to kick start the discussion and get
>> things rolling.
>> We could start on a branch and then move it to trunk during 0.22 if
>> everybody is satisfied with the progress.
>>
>> Regards,
>>
>> Rajith
>>
>> ---------------------------------------------------------------------
>> 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
Re: AMQP 1.0 support for JMS client via Proton
Posted by Rob Godfrey <ro...@gmail.com>.
On 20 September 2012 00:32, Rajith Attapattu <ra...@gmail.com> wrote:
> Hi All,
>
> There are a few folks who are keen to have AMQP 1.0 support for our JMS
> client.
> Given that the parent AMQP TC is starting a bindings and mappings TC
> which will cover JMS, I thought it would be a good idea to get a
> discussion going on here as well.
> We could aim to build the client as we progress through the TC and
> provide feedback if necessary.
>
> On the hand, we've had extensive discussions on building a new JMS
> client from scratch when adding 1.0 support.
> The primary motivation was to address some of the nagging issues
> around the old client.
>
> So far there have been two schools of thought on how to get AMQP 1.0
> support.
>
> 1. JMS Client --> Qpid API --> Proton
>
> 2. JMS Client --> Proton
>
> While option #1 seems like killing two birds with one stone, I think
> we should seriously consider option #2 as well.
>
>
So, regardless of which path we take I think we need to carefully define
the functional requirements for our JMS client. Looking at the JIRAs, and
based on the experience of supporting the current client, the two areas
where it causes most problems are 1) failover and 2) addressing.
For both (but especially failover) I think we need a very clear
understanding of the functionality we are looking for the client to provide
before we can decide which layer it is best placed in. If the functionality
is likely to be common across the JMS and Qpid APIs then it would seem
sensible not to write this code directly into the JMS layer.
Before we start cutting any code I think we need general agreement in the
Qpid Java community about the functionality that is required and where it
is going to be implemented (and ideally we should also be coordinating by
whom it is going to be implemented also :-) ).
-- Rob
> I would love to hear everybody's thoughts on this.
> More importantly it's good if we could also discuss on a plan and set
> some milestones to ensure we stay focused.
>
> Personally I would love to see a reasonably working prototype by 0.22.
> If we can get something going for 0.20 that would be a bonus, even if
> it's just experimental (preferably on a branch) and Alpha quality.
>
> I mentioned the above milestones to kick start the discussion and get
> things rolling.
> We could start on a branch and then move it to trunk during 0.22 if
> everybody is satisfied with the progress.
>
> Regards,
>
> Rajith
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
>
Re: AMQP 1.0 support for JMS client via Proton
Posted by Rob Godfrey <ro...@gmail.com>.
On 20 September 2012 00:32, Rajith Attapattu <ra...@gmail.com> wrote:
> Hi All,
>
> There are a few folks who are keen to have AMQP 1.0 support for our JMS
> client.
> Given that the parent AMQP TC is starting a bindings and mappings TC
> which will cover JMS, I thought it would be a good idea to get a
> discussion going on here as well.
> We could aim to build the client as we progress through the TC and
> provide feedback if necessary.
>
> On the hand, we've had extensive discussions on building a new JMS
> client from scratch when adding 1.0 support.
> The primary motivation was to address some of the nagging issues
> around the old client.
>
> So far there have been two schools of thought on how to get AMQP 1.0
> support.
>
> 1. JMS Client --> Qpid API --> Proton
>
> 2. JMS Client --> Proton
>
> While option #1 seems like killing two birds with one stone, I think
> we should seriously consider option #2 as well.
>
>
So, regardless of which path we take I think we need to carefully define
the functional requirements for our JMS client. Looking at the JIRAs, and
based on the experience of supporting the current client, the two areas
where it causes most problems are 1) failover and 2) addressing.
For both (but especially failover) I think we need a very clear
understanding of the functionality we are looking for the client to provide
before we can decide which layer it is best placed in. If the functionality
is likely to be common across the JMS and Qpid APIs then it would seem
sensible not to write this code directly into the JMS layer.
Before we start cutting any code I think we need general agreement in the
Qpid Java community about the functionality that is required and where it
is going to be implemented (and ideally we should also be coordinating by
whom it is going to be implemented also :-) ).
-- Rob
> I would love to hear everybody's thoughts on this.
> More importantly it's good if we could also discuss on a plan and set
> some milestones to ensure we stay focused.
>
> Personally I would love to see a reasonably working prototype by 0.22.
> If we can get something going for 0.20 that would be a bonus, even if
> it's just experimental (preferably on a branch) and Alpha quality.
>
> I mentioned the above milestones to kick start the discussion and get
> things rolling.
> We could start on a branch and then move it to trunk during 0.22 if
> everybody is satisfied with the progress.
>
> Regards,
>
> Rajith
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
>
Re: AMQP 1.0 support for JMS client via Proton
Posted by Steve Huston <sh...@riverace.com>.
Ok. good to know Rajith. Thanks!
Steve Huston
(sent from my iPhone - please excuse brevity and typos)
On Sep 20, 2012, at 8:52 AM, "Rajith Attapattu" <ra...@gmail.com> wrote:
> On Wed, Sep 19, 2012 at 8:34 PM, Steve Huston <sh...@riverace.com> wrote:
>> Good start to this discussion, Rajith.
>>
>> I haven't worked with the current JMS client, so I'm not sure what the
>> "nagging issues" are, but my first reaction to the #2 path is it may give
>> you more opportunity for support in more environments over time. I can
>> envision proton going into environments where Qpid may not be, such as
>> embedded and low-power situations.
>
> 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.
>
> Regards,
>
> Rajith
>
>> FWIW,
>> -Steve
>>
>> On 9/19/12 6:32 PM, "Rajith Attapattu" <ra...@gmail.com> wrote:
>>
>>> Hi All,
>>>
>>> There are a few folks who are keen to have AMQP 1.0 support for our JMS
>>> client.
>>> Given that the parent AMQP TC is starting a bindings and mappings TC
>>> which will cover JMS, I thought it would be a good idea to get a
>>> discussion going on here as well.
>>> We could aim to build the client as we progress through the TC and
>>> provide feedback if necessary.
>>>
>>> On the hand, we've had extensive discussions on building a new JMS
>>> client from scratch when adding 1.0 support.
>>> The primary motivation was to address some of the nagging issues
>>> around the old client.
>>>
>>> So far there have been two schools of thought on how to get AMQP 1.0
>>> support.
>>>
>>> 1. JMS Client --> Qpid API --> Proton
>>>
>>> 2. JMS Client --> Proton
>>>
>>> While option #1 seems like killing two birds with one stone, I think
>>> we should seriously consider option #2 as well.
>>>
>>> I would love to hear everybody's thoughts on this.
>>> More importantly it's good if we could also discuss on a plan and set
>>> some milestones to ensure we stay focused.
>>>
>>> Personally I would love to see a reasonably working prototype by 0.22.
>>> If we can get something going for 0.20 that would be a bonus, even if
>>> it's just experimental (preferably on a branch) and Alpha quality.
>>>
>>> I mentioned the above milestones to kick start the discussion and get
>>> things rolling.
>>> We could start on a branch and then move it to trunk during 0.22 if
>>> everybody is satisfied with the progress.
>>>
>>> Regards,
>>>
>>> Rajith
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>
> ---------------------------------------------------------------------
> 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
Re: AMQP 1.0 support for JMS client via Proton
Posted by Gordon Sim <gs...@redhat.com>.
On 09/21/2012 10:51 PM, Rajith Attapattu wrote:
> 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.
I am challenging that assumption (and the inference you drew from it
regarding the attractiveness of particular - as yet unimplemented - APIs
in particular environments).
Why would the needs of users of these APIs with regard to logging be
different? If they aren't why would we pursue two different approaches
to meeting those needs and why would we align a particular approach with
a particular API?
[...]
> 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
> technical.
Are there non-technical advantages that you see with option #2?
> 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
Certainly. I am not suggesting otherwise, merely trying to establish the
case for the second option you presented.
I can understand a reluctance to have another public API.; but from what
you are saying that isn't really a factor in you're mind with option #2?
(While you are laying out *all* the options, it might be useful to
include the current approach for JMS over AMQP 1.0, as included in the
0.18 release. What are the particular issues that we would want to
address by picking another approach?).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: AMQP 1.0 support for JMS client via Proton
Posted by Rajith Attapattu <ra...@gmail.com>.
On Thu, Sep 20, 2012 at 3:43 PM, Gordon Sim <gs...@redhat.com> wrote:
> On 09/20/2012 08:16 PM, Rajith Attapattu wrote:
>>
>> On Thu, Sep 20, 2012 at 2:36 PM, Gordon Sim <gs...@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
technical.
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.
Rajith
>
> ---------------------------------------------------------------------
> 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
Re: AMQP 1.0 support for JMS client via Proton
Posted by Gordon Sim <gs...@redhat.com>.
On 09/20/2012 08:16 PM, Rajith Attapattu wrote:
> On Thu, Sep 20, 2012 at 2:36 PM, Gordon Sim <gs...@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
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.
>> 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
Re: AMQP 1.0 support for JMS client via Proton
Posted by Rajith Attapattu <ra...@gmail.com>.
On Thu, Sep 20, 2012 at 2:36 PM, Gordon Sim <gs...@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
Re: AMQP 1.0 support for JMS client via Proton
Posted by Gordon Sim <gs...@redhat.com>.
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).
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?
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?
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.
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?
I agree very much with Rob's point on the need for greater clarity on
the functionality offered by different APIs.
--Gordon
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: AMQP 1.0 support for JMS client via Proton
Posted by Rajith Attapattu <ra...@gmail.com>.
On Wed, Sep 19, 2012 at 8:34 PM, Steve Huston <sh...@riverace.com> wrote:
> Good start to this discussion, Rajith.
>
> I haven't worked with the current JMS client, so I'm not sure what the
> "nagging issues" are, but my first reaction to the #2 path is it may give
> you more opportunity for support in more environments over time. I can
> envision proton going into environments where Qpid may not be, such as
> embedded and low-power situations.
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.
Regards,
Rajith
> FWIW,
> -Steve
>
> On 9/19/12 6:32 PM, "Rajith Attapattu" <ra...@gmail.com> wrote:
>
>>Hi All,
>>
>>There are a few folks who are keen to have AMQP 1.0 support for our JMS
>>client.
>>Given that the parent AMQP TC is starting a bindings and mappings TC
>>which will cover JMS, I thought it would be a good idea to get a
>>discussion going on here as well.
>>We could aim to build the client as we progress through the TC and
>>provide feedback if necessary.
>>
>>On the hand, we've had extensive discussions on building a new JMS
>>client from scratch when adding 1.0 support.
>>The primary motivation was to address some of the nagging issues
>>around the old client.
>>
>>So far there have been two schools of thought on how to get AMQP 1.0
>>support.
>>
>>1. JMS Client --> Qpid API --> Proton
>>
>>2. JMS Client --> Proton
>>
>>While option #1 seems like killing two birds with one stone, I think
>>we should seriously consider option #2 as well.
>>
>>I would love to hear everybody's thoughts on this.
>>More importantly it's good if we could also discuss on a plan and set
>>some milestones to ensure we stay focused.
>>
>>Personally I would love to see a reasonably working prototype by 0.22.
>>If we can get something going for 0.20 that would be a bonus, even if
>>it's just experimental (preferably on a branch) and Alpha quality.
>>
>>I mentioned the above milestones to kick start the discussion and get
>>things rolling.
>>We could start on a branch and then move it to trunk during 0.22 if
>>everybody is satisfied with the progress.
>>
>>Regards,
>>
>>Rajith
>>
>>---------------------------------------------------------------------
>>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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: AMQP 1.0 support for JMS client via Proton
Posted by Steve Huston <sh...@riverace.com>.
Good start to this discussion, Rajith.
I haven't worked with the current JMS client, so I'm not sure what the
"nagging issues" are, but my first reaction to the #2 path is it may give
you more opportunity for support in more environments over time. I can
envision proton going into environments where Qpid may not be, such as
embedded and low-power situations.
FWIW,
-Steve
On 9/19/12 6:32 PM, "Rajith Attapattu" <ra...@gmail.com> wrote:
>Hi All,
>
>There are a few folks who are keen to have AMQP 1.0 support for our JMS
>client.
>Given that the parent AMQP TC is starting a bindings and mappings TC
>which will cover JMS, I thought it would be a good idea to get a
>discussion going on here as well.
>We could aim to build the client as we progress through the TC and
>provide feedback if necessary.
>
>On the hand, we've had extensive discussions on building a new JMS
>client from scratch when adding 1.0 support.
>The primary motivation was to address some of the nagging issues
>around the old client.
>
>So far there have been two schools of thought on how to get AMQP 1.0
>support.
>
>1. JMS Client --> Qpid API --> Proton
>
>2. JMS Client --> Proton
>
>While option #1 seems like killing two birds with one stone, I think
>we should seriously consider option #2 as well.
>
>I would love to hear everybody's thoughts on this.
>More importantly it's good if we could also discuss on a plan and set
>some milestones to ensure we stay focused.
>
>Personally I would love to see a reasonably working prototype by 0.22.
>If we can get something going for 0.20 that would be a bonus, even if
>it's just experimental (preferably on a branch) and Alpha quality.
>
>I mentioned the above milestones to kick start the discussion and get
>things rolling.
>We could start on a branch and then move it to trunk during 0.22 if
>everybody is satisfied with the progress.
>
>Regards,
>
>Rajith
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
>For additional commands, e-mail: dev-help@qpid.apache.org
>
Re: AMQP 1.0 support for JMS client via Proton
Posted by Steve Huston <sh...@riverace.com>.
Good start to this discussion, Rajith.
I haven't worked with the current JMS client, so I'm not sure what the
"nagging issues" are, but my first reaction to the #2 path is it may give
you more opportunity for support in more environments over time. I can
envision proton going into environments where Qpid may not be, such as
embedded and low-power situations.
FWIW,
-Steve
On 9/19/12 6:32 PM, "Rajith Attapattu" <ra...@gmail.com> wrote:
>Hi All,
>
>There are a few folks who are keen to have AMQP 1.0 support for our JMS
>client.
>Given that the parent AMQP TC is starting a bindings and mappings TC
>which will cover JMS, I thought it would be a good idea to get a
>discussion going on here as well.
>We could aim to build the client as we progress through the TC and
>provide feedback if necessary.
>
>On the hand, we've had extensive discussions on building a new JMS
>client from scratch when adding 1.0 support.
>The primary motivation was to address some of the nagging issues
>around the old client.
>
>So far there have been two schools of thought on how to get AMQP 1.0
>support.
>
>1. JMS Client --> Qpid API --> Proton
>
>2. JMS Client --> Proton
>
>While option #1 seems like killing two birds with one stone, I think
>we should seriously consider option #2 as well.
>
>I would love to hear everybody's thoughts on this.
>More importantly it's good if we could also discuss on a plan and set
>some milestones to ensure we stay focused.
>
>Personally I would love to see a reasonably working prototype by 0.22.
>If we can get something going for 0.20 that would be a bonus, even if
>it's just experimental (preferably on a branch) and Alpha quality.
>
>I mentioned the above milestones to kick start the discussion and get
>things rolling.
>We could start on a branch and then move it to trunk during 0.22 if
>everybody is satisfied with the progress.
>
>Regards,
>
>Rajith
>
>---------------------------------------------------------------------
>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