2009/3/19 Aidan Skinner <[email protected]>: > On Wed, Mar 18, 2009 at 8:26 PM, Gordon Sim <[email protected]> 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.
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 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. > >> 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. 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 Hope this helps, Rob --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
