qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John O'Hara" <john.r.oh...@gmail.com>
Subject Re: A question for the ActiveMQ chaps on the list...
Date Fri, 22 Sep 2006 11:45:39 GMT
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.


On 22/09/06, James Strachan <james.strachan@gmail.com> wrote:
> On 9/22/06, John O'Hara <john.r.ohara@gmail.com> 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
> > 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
> > 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
> 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/

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message