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 10:36:18 GMT
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:

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.

> The broker has some limited support for multiple protocols at present, but
> they are really the remnants of upgrading from 0-9 'wip' to one version of
> 0-10 and then onto the final 0-10 without breaking the build and test
> suites. I think some thinking and design around improving that in general
> terms would also be a valuable step forwards.

The java server supports 0-8 and 0-9, but they're really additional
protocol dialects. 0-10 and, in particular, 1-0 have somewhat more
substantial semantic differences. In order to properly support them I
think they key is to have as modular a server as possible.

I've written up some of the improvements to the java server I think
should be made here:
http://qpid.apache.org/java-broker-modularisation.html (that page
needs to be updated a little since some of the works been done in
0.5).

The idea is that the core of the server does the basic work of taking
a message, putting it on disk, putting on a queue, taking it from a
queue and giving it to the client. The details of that, such as how
what message goes on what queue before being delivered to a consumer
and the protocol used to transfer messages, are implemented by 1 or
more plugins which contribute queues, protocol packs, admin wiring
etc.

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.

- 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