> On 14/09/06, Rajith Attapattu <[EMAIL PROTECTED]> wrote:
> > I am planning a refactoring of the java client to create an AMQP
client API
> > and then build the JMS layer on top of it.
> > So people who are interested can directly access AMQP specific
features.
Hi Rajith,
I've been thinking the same thing myself lately.
I kinda like the idea of an AMQP API underneath the JMS API. This still
requires
JMS extensions for AMQP features not accessibly otherwise. However, it's
possible that
one of those extensions - immediate send - will be replaced with a new
mechanism
soon.
I wanted to start a list of pros and cons to address some of the things
that Robert was
talking about. I feel I haven't done a very good job but here it is:
Advantages:
* Clearer structure for the JMS client code.
* Ability to write tests for the broker that are rendered impossible via
the JMS API.
I guess we are using the Python client API for that though. I took a
brief look
at the Python client a while ago and I think it's excellent btw!
* You can asynchronously send without having to worry about the send
semantics
in JMS. Specifically it appears that there is a need to block to
detect and throw
an InvalidDestinationException. In general you don't have to worry
about JMS
semantics which is nice.
* You can declare exchanges queues and bindings directly. Perhaps allowing
things that are not available through JMS.
* You could directly supply headers as a field table.
* Perhaps later when the managment commands are available in the protocol,
you will
be able to do more command-and-control type of operations.
Disadvantages:
* the perception problem of having two APIs from a user's point of view
* maintenance could be a burden
* now is probably not the time to do it.
* stability
In order to get around the disadvantages of having 2 APIs to choose from,
we
should perhaps should not promote it as an alternative to the JMS API. It
could be useful for internal
use in testing etc. The JMS API does surprisingly suck quite a bit as it's
a lowest common denominator kind of
API (but also for small things like JMSException's linkedException
presumably because it was designed
prior to Java 1.4). One odd thing about the JMS API is a number of setter
methods on Message that should only
be called by a JMS provider (like setJMSDestination). Unfortunately
neither of the two gripes to the JMS API
really call for an AMQP API, just some tweaks to JMS or, as is likely, a
better understanding of the JMS requirements.
Hopefully work on JMS extensions and any future AMQP specific Java API
will feed into JMS specifications down the track.
For now I think it would be interesting to see an AMQP API - at least one
just the the JMS client to use. My biggest concern
is that this kind of refactoring is possibly an unstabilalising for the
current code base. However that concern can curbed by
using a branch for such a refactoring.
Cheers,
Steve.
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.
