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
Date Thu, 19 Mar 2009 13:29:33 GMT
On Thu, Mar 19, 2009 at 6:36 AM, Aidan Skinner <aidan@apache.org> wrote:
> On Wed, Mar 18, 2009 at 8:26 PM, Gordon Sim <gsim@redhat.com> wrote:
>> I think, as has been discussed on this list recently, that getting some
>> higher level, protocol-independent APIs for those languages that don't
>> currently have them is a necessary first step and one that will be valuable
>> regardless.
> I think this is going to be really helpful for client applications,
> most of which don't really want to be tied to protocol versions.
> The Java client uses JMS for this to an extent, but we still need a
> way of exposing AMQP specific things in ways that are as version
> independent as possible (such as the mandatory flag). I've been
> kicking around the idea of something like this:

I am of the opinion that you could get 99% of the AMQP stuff while
still using pure JMS.
I have a few ideas around how to do the immediate flag etc while still
using pure JMS.
One such idea is to pass in a QPID specific property in the message
called "AMQP_IMMEDIATE" and the respective sender method can look for
the presense of this flag and put that in the delivery props. When
using properties like this we don't have to worry about a specific
AMQP version, as the respective delegate (ex BasicMessageProducer_0_10
in this instance) will know which flags to look and anything else can
be ignored.

I am currently working on a prototype to see how best we can use queue
declare and binding arguments when defining our destinations, so we
don't have to use anything non JMS.

So I believe a fair bit can be done while still using pure JMS.

> JMSSession -> AMQSession -> AMQ_[ver]_session
> With only things that are supported by all version fo AMQP in
> AMQSession. This does lead to a couple of problems though, such as
> features that are in all but one version of spec.
> The other option I was considering was something like
> JMSSession -> AMQSession -> AMQPre10Session -> AMQ010Session
> but I think that may be over engineering for the sake of over engineering.

I think the current way of having a version specific delegate seems to
have worked well.
AMQSession (JMS Session) --> AMQ_version_specific_delegate.

But of course I am always open to better ideas.



Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org

View raw message