qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <james.strac...@gmail.com>
Subject Re: A question for the ActiveMQ chaps on the list...
Date Fri, 22 Sep 2006 09:38:02 GMT
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 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/

Mime
View raw message