I'll let one of the other guys answe the code bits wrt Qpid.
Sounds like me and the guys have an AMQP-Interop spec to write. I suspect we should do it after some of the open discussions are nailed down and feedback incorporated back at amqp.org prior to proposing such a thing. Save rework. The Interop spec would allow AMQP clients to use destinations on JMS servers and propage the ACK modes or some subset of them. I suspect a "Not Implemented" exception will ne needed for some things at the wire level. As to the re-use point -- there are two approaches to reuse going on here, one in AMQP and the one you're suggesting be implemented in QPID; both can happen simultaneously: 1) AMQP.ORG provides an XML description of the framing, so by running a stylesheet you can generate your framing layer. This makes life easier for the C++, Python, ,NET, Ruby developers. But you could also copy the style sheet for QPID and modify it to generate a very fast and accurate binding into the engine of your choice, eg ActiveMQ. But cut and paste coding, even of generators, never won any prizes :-) 2) Abstracting the QPID generated marshalling into an interface module like you describe is probably also a very good thing to do -- we need to make sure all the major subsystems are clean modules for all the reasons you give. MINA is kind of a module, but tx logging, replication, HA mechanisms could all become pluggable, and potentially shareable between QPID and ActiveMQ, or further. It would be interesting to see if there is any measurable performance difference in going through a redirection vs being bound tightly. I suspect its not measurable. Also Robert has an interesting idea about building an exchange type within QPID that proxies onto other kinds of middleware. I'm not sure how it would work and it wouldn't be optimal, but like the JDBC/ODBC bridge it could be a useful thing for people stuck on some older middleware without the ability for wholesale conversion. John On 22/09/06, James Strachan <[EMAIL PROTECTED]> wrote:
On 9/22/06, John O'Hara <[EMAIL PROTECTED]> wrote: > Do you think ActiveMQ can support AMQP semantics as defined in the spec? Absolutely. Providing there is a clear and unambiguous mapping of AMQP to JMS/MQ/EMS semantics it shouldn't be a problem. A specification for how to map from AMQP to a JMS/MQ would really help - though until someone goes through the exercise of mapping AMQP to an existing JMS/MQ system I've no idea how clean the mapping will be - I can imagine a few grey areas. > When James spent some time with us back on the early early days of the AMQP > I got the impression that he held the view that you could plug the command > verbs onto ActiveMQ and it would just work. Assuming there is indeed a well defined mapping of AMQP commands to JMS/MQSeries semantics then yes it should. Given the fact that ActiveMQ has been designed to work with many different protocols, it'd be a bit of a worry for AMQP if ActiveMQ could not implement it :) > I wasn't convinced of that approach back then. But I do hope an AMQP > compatible ActiveMQ is possible. > > I'd like to work on a AMQP-Interop spec which defines how some set of AMQP > behaviours can work with existing middleware semantics. That might be a > useful starting point for an AMQP transport for ActiveMQ. > > I believe getting the semantics clear and consistent is crucial to interop. > > Any interest in that, or is it not a useful idea? Sure, sounds good to me. I spent a few hours yesterday trying to figure out if I could reuse some of the qpid protocol/framing code to add AMQP support to ActiveMQ; unfortunately it seems the AMQP code in qpid is pretty tightly coupled to the current qpid broker - I couldn't really see a place where we could plugin ActiveMQ or any other messaging provider for that matter. If other messaging providers are to support AMQP then it'd make sense to make it as easy as possible for folks to reuse as much of the basic plumbing code from the qpid project as possible. e.g. for dealing with the low level AMQP protocol, marshalling the commands to and from the wire & handling connection / channel lifecycles - then allowing different providers to drop in handlers for the actual commands on a channel. Otherwise if every provider has to effectively create and maintain a rewrite of lots of the protocol code in qpid. If thats the case I can see vendors taking the easy route of just sticking with the JMS API to bridge to foreign providers, kinda defeating one of the main goals of AMQP. So I think some refactoring of the current qpid code would be a very good idea and certainly increase the chances of ActiveMQ supporting AMQP. e.g. how about refactoring the code in the org.apache.qpid.server.protocol somewhat to make it easy to separate the transport/protocol handling with the actual implementation of the protocol using interfaces to separate the two? Ideally something like AMQMinaProtocolSession being refactored so that it can use pluggable AMQChannel and AMQMessage implementations (so making those two classes interfaces rather than classes that are deeply bound into a specific implementation). I guess we need an AMQP 'broker API' so folks can just implement a couple of interfaces and plug right into the qpid AMQP marshalling/framing/protocol code which would then greatly lower the bar to AMQP implementaors and also encourage more code reuse and participation across the AMQP (and Apache) community To see how this kinda thing can look, here's ActiveMQ's OpenWire interface that wraps up the core protocol & marshalling details... http://incubator.apache.org/activemq/maven/activemq-core/apidocs/org/apache/activemq/broker/Broker.html notice how its an interface and passes the various commands (or AMQMethodBody as AMQP often calls them) as parameters so its very easy to for any provider to implement the broker however they wish. Some vaguely similar API for AMQP would really make it easy for folks to try write AMQP bridges or integrate AMQP support into existing messaging providers. e.g. imagine something vaguely like this... // a handler of a Channel operations public interface ChannelHandler { // channel operations AMQMethodBody channelFlow(AMQFrame frame, ChannelFlowBody body) // exchange operations AMQMethodBody exchangeDeclare(AMQFrame frame, ExchangeDeclareBody body) AMQMethodBody exchangeDelete(AMQFrame frame, ExchangeDeleteBody body) // queue operations AMQMethodBody queueDeclare(AMQFrame frame, QueueDeclareBody body) AMQMethodBody queueBind(AMQFrame frame, QueueBindBody body) AMQMethodBody queuePurge(AMQFrame frame, QueuePurgeBody body) AMQMethodBody queueDelete(AMQFrame frame, QueueDeleteBody body) // allows async replies to be sent etc void setChannel(Channel channel); } Then folks could create an AMQP transport and plug in a handler to deal with the semantics of channel operations, exchanges, queues and whatnot. I don't much mind how the API it looks so long as it loosely couples the low level AMQP plumbing details from the implementation and minimises the amount of effort getting started at writing an AMQP provider/bridge - as processing the various commands in other providers should be relatively straightforward, assuming there is a way of mapping the commands to semantics in JMS/MOM etc. Thoughts? -- James ------- http://radio.weblogs.com/0112098/
