qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aidan Skinner <ai...@apache.org>
Subject Re: AMQP 1.0
Date Thu, 19 Mar 2009 13:37:04 GMT
On Thu, Mar 19, 2009 at 1:13 PM, Robert Godfrey <rob.j.godfrey@gmail.com> wrote:
> 2009/3/19 Aidan Skinner <aidan@apache.org>:
>> 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 think that we may find that from a Java/JMS perspective the more
> profitable route will be to separate out a 1.0 implementation from the

Are you talking about the interfaces here, or at a deeper level?
That's sort of how 0-10 and 0-9/0-8 are implemented in the client
currently, and I'm not convinced that the cut-n-shunt model works all
that well. It may just be a matter of the process that occured there
though, and with some refcatoring could well be the way to go.

> legacy code.  Defining an AMQSession interface which exposes AMQP
> (1-0) semantics is still my preferred mechanism. I'm unsure whether
> such an interface would have any direct relationship to JMS Session
> however.

It would seem sensible for the JMSSession to sit on top of AMQSession
and then dispatch on the type of the session where it needs to do
something different for earlier AMQP versions.

I'm not sure how much backward compatibility we need to provide for
existing users who are accessing the AMQP extensions. We've made some
effort to do so so far, but the move to 1-0 may present a good
opportunity and reason for breaking API compatibility. We'd only get
one chance at this for a while though, so we'd need to get it right.

>> There are still some significant details to work out, particularly
>> around administration and translating messages from one protocol
>> version to another. Clearly nirvana here is for a 0-8 client to be
>> able to connect, send a message and have it go to 0-9, 0-10 and 1-0
>> clients and it Just Works. Similarly, persistence plugins shouldn't
>> have to care about the type of message that they get - they should be
>> able to persist any of them.
>
> Once we have completed the core of the AMQP1-0 specification then
> myself, Rafi, John and others from the AMQP Working Group will be
> working on documenting such things as
>
> * How to map JMS to AMQP in a portable way,
> * How to send AMQP0-8/0-9/0-10 Messages ove AMQP1-0 Networks, and
> * How to emulate the behaviour of exchanges using Links and Queues

Those would be Really Helpful, particularly the first two if we're
going to have meaningful interop with other AMQP vendors.

- Aidan
-- 
Apache Qpid - World Domination through Advanced Message Queueing
http://qpid.apache.org

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


Mime
View raw message