You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Johnson, Eric" <Er...@iona.com> on 2006/09/18 23:16:17 UTC
To extend or not (was RE: QPID/HermesJMS)
If everything is addressed using an extended JMS front end how
complicated does the JMS API become? At what point do the abstractions
required become too extreme? If implementing some of the basic use cases
pushes the extended JMS API too far then I'd think from a developer's
POV that would not be OK.
Are there any use cases that would currently create this situation?
You may not be able to predict every conceivable case, but you can
predict a lot of them.
> -----Original Message-----
> From: Robert Greig [mailto:robert.j.greig@gmail.com]
> Sent: Monday, September 18, 2006 5:04 PM
> To: qpid-dev@incubator.apache.org
> Subject: Re: QPID/HermesJMS
>
> > Two more use cases
> > --------------------------------
> > I want to do a SCA/AMQP Binding for Tuscany and I would want to
leverage
> the
> > protocol artifacts using a more intutive API and not JMS or an
extended
> JMS.
> > There is also a JMS binding and if use the same interface then were
is
> the
> > differentiation factor?
>
> The differentiation would be that there is an "extended JMS" API for
> AMQ. So that API does not duplicate existing JMS concepts but adds
> AMQP concepts to it - for example, the immediate flag.
>
> > I also want to use AMQP as a protocol for Axis2. Now I really
haven't
> though
> > about this, but some of the unique features that AMQP offers maybe
> useful if
> > they can be accessed using a more natural API than through JMS.
>
> The idea is not that you would be limited to JMS "lowest common
> denominator" functionality but that you could exploit AMQP where
> appropriate but via the extra methods and classes exposed in
> conjunction with JMS.
>
> Or do you actually want to work at the protocol level? If so, we need
> to understand why the JMS API is deficient.
>
> RG
Re: To extend or not (was RE: QPID/HermesJMS)
Posted by ro...@jpmorgan.com.
Hi,
Sure I am keen to help out where I can.
I am fortunately able to focus on Qpid quite a bit at the moment.
RG
|---------+---------------------------->
| | "Rajith |
| | Attapattu" |
| | <rajith77@gmail.c|
| | om> |
| | |
| | 20/09/2006 16:30 |
| | Please respond to|
| | qpid-dev |
|---------+---------------------------->
>------------------------------------------------------------------------------------------------------------------------------|
| |
| To: qpid-dev@incubator.apache.org |
| cc: |
| Subject: Re: To extend or not (was RE: QPID/HermesJMS) |
>------------------------------------------------------------------------------------------------------------------------------|
Robert,
I guess thats where the misunderstanding started. I used the wrong choice
of
words.
Instead of saying AMQP client API, I should have used AMQP protocol level
API :)
>Are you planning on fleshing it out on a branch?
Yes that would be a better approach so I want disrupt the trunk in anyway.
However I am tied up this week and can only start looking at it next week.
I will also start a thread on this topic and I am counting on you for
support and comments/ideas/suggestions
Regards,
Rajith
On 9/20/06, robert.j.greig@jpmorgan.com <ro...@jpmorgan.com>
wrote:
>
> Yes, I think that a protocol-level API is fine. I had thought you were
> proposing something at a higher level.
>
> Are you planning on fleshing it out on a branch?
>
> RG
>
>
> |---------+---------------------------->
> | | "Rajith |
> | | Attapattu" |
> | | <rajith77@gmail.c|
> | | om> |
> | | |
> | | 20/09/2006 15:49 |
> | | Please respond to|
> | | qpid-dev |
> |---------+---------------------------->
>
>
>------------------------------------------------------------------------------------------------------------------------------|
>
> |
|
> | To: qpid-dev@incubator.apache.org
>
|
> |
> cc:
|
> | Subject: Re: To extend or not (was RE:
> QPID/HermesJMS)
|
>
>
>------------------------------------------------------------------------------------------------------------------------------|
>
>
>
>
> Greg,
>
> What I am also pushing is for a protocol level API.
> Even if we don't document this or promote this API, I still think from a
> design POV we need to have a cleaner seperation.
> So why not have protocol API and then have that 'extended JMS API' if you
> will.
>
> But lets not kill the idea of a protocol level API.
>
> Does this sound like a reasonable compromise???
>
> Regards,
>
> Rajith
>
> On 9/19/06, Gordon Sim <gs...@redhat.com> wrote:
> >
> > Robert Greig wrote:
> > > Unless what is being proposed is
> > > what I read into Gordon's comments (I don't want to put words in your
> > > mouth so let me know if I'm misrerepresenting you Gordon) which is a
> > > strictly protocol-level API.
> >
> > Yes, I was talking about a protocol-level API.
> >
>
>
>
>
> This communication is for informational purposes only. It is not intended
> as an offer or solicitation for the purchase or sale of any financial
> instrument or as an official confirmation of any transaction. All market
> prices, data and other information are not warranted as to completeness
or
> accuracy and are subject to change without notice. Any comments or
> statements made herein do not necessarily reflect those of JPMorgan Chase
&
> Co., its subsidiaries and affiliates.
>
> This transmission may contain information that is privileged,
> confidential, legally privileged, and/or exempt from disclosure under
> applicable law. If you are not the intended recipient, you are hereby
> notified that any disclosure, copying, distribution, or use of the
> information contained herein (including any reliance thereon) is STRICTLY
> PROHIBITED. Although this transmission and any attachments are believed
to
> be free of any virus or other defect that might affect any computer
system
> into which it is received and opened, it is the responsibility of the
> recipient to ensure that it is virus free and no responsibility is
accepted
> by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable,
for
> any loss or damage arising in any way from its use. If you received this
> transmission in error, please immediately contact the sender and destroy
the
> material in its entirety, whether in electronic or hard copy format.
Thank
> you.
>
>
This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates.
This transmission may contain information that is privileged, confidential, legally privileged, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you.
Re: To extend or not (was RE: QPID/HermesJMS)
Posted by Rajith Attapattu <ra...@gmail.com>.
Robert,
I guess thats where the misunderstanding started. I used the wrong choice of
words.
Instead of saying AMQP client API, I should have used AMQP protocol level
API :)
>Are you planning on fleshing it out on a branch?
Yes that would be a better approach so I want disrupt the trunk in anyway.
However I am tied up this week and can only start looking at it next week.
I will also start a thread on this topic and I am counting on you for
support and comments/ideas/suggestions
Regards,
Rajith
On 9/20/06, robert.j.greig@jpmorgan.com <ro...@jpmorgan.com> wrote:
>
> Yes, I think that a protocol-level API is fine. I had thought you were
> proposing something at a higher level.
>
> Are you planning on fleshing it out on a branch?
>
> RG
>
>
> |---------+---------------------------->
> | | "Rajith |
> | | Attapattu" |
> | | <rajith77@gmail.c|
> | | om> |
> | | |
> | | 20/09/2006 15:49 |
> | | Please respond to|
> | | qpid-dev |
> |---------+---------------------------->
>
> >------------------------------------------------------------------------------------------------------------------------------|
>
> | |
> | To: qpid-dev@incubator.apache.org
> |
> |
> cc: |
> | Subject: Re: To extend or not (was RE:
> QPID/HermesJMS) |
>
> >------------------------------------------------------------------------------------------------------------------------------|
>
>
>
>
> Greg,
>
> What I am also pushing is for a protocol level API.
> Even if we don't document this or promote this API, I still think from a
> design POV we need to have a cleaner seperation.
> So why not have protocol API and then have that 'extended JMS API' if you
> will.
>
> But lets not kill the idea of a protocol level API.
>
> Does this sound like a reasonable compromise???
>
> Regards,
>
> Rajith
>
> On 9/19/06, Gordon Sim <gs...@redhat.com> wrote:
> >
> > Robert Greig wrote:
> > > Unless what is being proposed is
> > > what I read into Gordon's comments (I don't want to put words in your
> > > mouth so let me know if I'm misrerepresenting you Gordon) which is a
> > > strictly protocol-level API.
> >
> > Yes, I was talking about a protocol-level API.
> >
>
>
>
>
> This communication is for informational purposes only. It is not intended
> as an offer or solicitation for the purchase or sale of any financial
> instrument or as an official confirmation of any transaction. All market
> prices, data and other information are not warranted as to completeness or
> accuracy and are subject to change without notice. Any comments or
> statements made herein do not necessarily reflect those of JPMorgan Chase &
> Co., its subsidiaries and affiliates.
>
> This transmission may contain information that is privileged,
> confidential, legally privileged, and/or exempt from disclosure under
> applicable law. If you are not the intended recipient, you are hereby
> notified that any disclosure, copying, distribution, or use of the
> information contained herein (including any reliance thereon) is STRICTLY
> PROHIBITED. Although this transmission and any attachments are believed to
> be free of any virus or other defect that might affect any computer system
> into which it is received and opened, it is the responsibility of the
> recipient to ensure that it is virus free and no responsibility is accepted
> by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for
> any loss or damage arising in any way from its use. If you received this
> transmission in error, please immediately contact the sender and destroy the
> material in its entirety, whether in electronic or hard copy format. Thank
> you.
>
>
Re: To extend or not (was RE: QPID/HermesJMS)
Posted by ro...@jpmorgan.com.
Yes, I think that a protocol-level API is fine. I had thought you were
proposing something at a higher level.
Are you planning on fleshing it out on a branch?
RG
|---------+---------------------------->
| | "Rajith |
| | Attapattu" |
| | <rajith77@gmail.c|
| | om> |
| | |
| | 20/09/2006 15:49 |
| | Please respond to|
| | qpid-dev |
|---------+---------------------------->
>------------------------------------------------------------------------------------------------------------------------------|
| |
| To: qpid-dev@incubator.apache.org |
| cc: |
| Subject: Re: To extend or not (was RE: QPID/HermesJMS) |
>------------------------------------------------------------------------------------------------------------------------------|
Greg,
What I am also pushing is for a protocol level API.
Even if we don't document this or promote this API, I still think from a
design POV we need to have a cleaner seperation.
So why not have protocol API and then have that 'extended JMS API' if you
will.
But lets not kill the idea of a protocol level API.
Does this sound like a reasonable compromise???
Regards,
Rajith
On 9/19/06, Gordon Sim <gs...@redhat.com> wrote:
>
> Robert Greig wrote:
> > Unless what is being proposed is
> > what I read into Gordon's comments (I don't want to put words in your
> > mouth so let me know if I'm misrerepresenting you Gordon) which is a
> > strictly protocol-level API.
>
> Yes, I was talking about a protocol-level API.
>
This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates.
This transmission may contain information that is privileged, confidential, legally privileged, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you.
Re: To extend or not (was RE: QPID/HermesJMS)
Posted by Alan Conway <ac...@redhat.com>.
Not only reasonable, it's inevitable. We can't build qpid without having
such an API inside it's only a question of how much we document and
promote it to users.
On Wed, 2006-09-20 at 10:49 -0400, Rajith Attapattu wrote:
> Greg,
>
> What I am also pushing is for a protocol level API.
> Even if we don't document this or promote this API, I still think from a
> design POV we need to have a cleaner seperation.
> So why not have protocol API and then have that 'extended JMS API' if you
> will.
>
> But lets not kill the idea of a protocol level API.
>
> Does this sound like a reasonable compromise???
>
> Regards,
>
> Rajith
>
> On 9/19/06, Gordon Sim <gs...@redhat.com> wrote:
> >
> > Robert Greig wrote:
> > > Unless what is being proposed is
> > > what I read into Gordon's comments (I don't want to put words in your
> > > mouth so let me know if I'm misrerepresenting you Gordon) which is a
> > > strictly protocol-level API.
> >
> > Yes, I was talking about a protocol-level API.
> >
Re: To extend or not (was RE: QPID/HermesJMS)
Posted by Rajith Attapattu <ra...@gmail.com>.
Greg,
What I am also pushing is for a protocol level API.
Even if we don't document this or promote this API, I still think from a
design POV we need to have a cleaner seperation.
So why not have protocol API and then have that 'extended JMS API' if you
will.
But lets not kill the idea of a protocol level API.
Does this sound like a reasonable compromise???
Regards,
Rajith
On 9/19/06, Gordon Sim <gs...@redhat.com> wrote:
>
> Robert Greig wrote:
> > Unless what is being proposed is
> > what I read into Gordon's comments (I don't want to put words in your
> > mouth so let me know if I'm misrerepresenting you Gordon) which is a
> > strictly protocol-level API.
>
> Yes, I was talking about a protocol-level API.
>
Re: To extend or not (was RE: QPID/HermesJMS)
Posted by Gordon Sim <gs...@redhat.com>.
Robert Greig wrote:
> Unless what is being proposed is
> what I read into Gordon's comments (I don't want to put words in your
> mouth so let me know if I'm misrerepresenting you Gordon) which is a
> strictly protocol-level API.
Yes, I was talking about a protocol-level API.
Re: To extend or not (was RE: QPID/HermesJMS)
Posted by James Strachan <ja...@gmail.com>.
Its maybe worth making a list of all the things which folks feel AMQP
could do one day which might not fit into the JMS API. Then folks can
ponder on whether or not a new API is required & what actually are the
real use cases when one might wish to avoid the JMS spec
On the ActiveMQ project we've extended the JMS spec in many ways
together with writing JMS-like APIs in C# and C++...
http://activemq.org/site/features.html
http://activemq.org/site/cross-language-clients.html
and so far found that so far we've been able to stick within the JMS
API apart from a few simple extensions here and there such as
http://activemq.org/site/jms-streams.html
Also within the JMS spec you can bend things to add optional extensions such as
http://activemq.org/site/structured-message-properties-and-mapmessages.html
http://activemq.org/site/virtual-destinations.html
So I'd recommend you figure out what are the use cases are first
before making decisions on what APIs to build. You might also be
surprised how much you can bend the JMS API to do what you need ;)
On 9/18/06, Robert Greig <ro...@gmail.com> wrote:
> On 18/09/06, Johnson, Eric <Er...@iona.com> wrote:
> > If everything is addressed using an extended JMS front end how
> > complicated does the JMS API become? At what point do the abstractions
> > required become too extreme? If implementing some of the basic use cases
> > pushes the extended JMS API too far then I'd think from a developer's
> > POV that would not be OK.
>
> Yes this is perhaps the key point. Unless what is being proposed is
> what I read into Gordon's comments (I don't want to put words in your
> mouth so let me know if I'm misrerepresenting you Gordon) which is a
> strictly protocol-level API.
>
> So far I think the "extended JMS" is quite simple although I am
> perhaps slightly biased :-)
>
> RG
>
--
James
-------
http://radio.weblogs.com/0112098/
Re: To extend or not (was RE: QPID/HermesJMS)
Posted by Robert Greig <ro...@gmail.com>.
On 18/09/06, Johnson, Eric <Er...@iona.com> wrote:
> If everything is addressed using an extended JMS front end how
> complicated does the JMS API become? At what point do the abstractions
> required become too extreme? If implementing some of the basic use cases
> pushes the extended JMS API too far then I'd think from a developer's
> POV that would not be OK.
Yes this is perhaps the key point. Unless what is being proposed is
what I read into Gordon's comments (I don't want to put words in your
mouth so let me know if I'm misrerepresenting you Gordon) which is a
strictly protocol-level API.
So far I think the "extended JMS" is quite simple although I am
perhaps slightly biased :-)
RG