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: ActiveMQ can now support AMQP clients.
Date Thu, 26 Oct 2006 18:38:07 GMT
On 10/26/06, Gordon Sim <gsim@redhat.com> wrote:
> James Strachan wrote:
> > The desire is to share code - partlcularly the low level Qpid framing
> > code. We're all Apache folk afterall and projects are meant to work
> > together & share code where it makes sense to do so.
> >
> > Ideally qpid and ActiveMQ would share a large chunk of ocde for the
> > AMQP framing stuff; though right now its hard to do that as qpid is
> > not terribly easy to reuse and is based on MINA and ActiveMQ has its
> > own transport framework.
>
> I agree, sharing code is ideal. The qpid proposal included reusable
> libraries as an objective and this seems sensible in the effort to
> promote AMQP and interoperability.
>
> Right now the feedback seems to be that the code is mainly useful as
> 'seed' code for a fork. Forks are clearly not ideal as they dilute the
> collective effort, but sometimes they may be inevitable due to different
> long term needs/aims or lack of short term resources to make more minor
> adjustments to satisfy all needs.

Note I wouldn't call this a fork; its just an early experimental spike
to see how much of the qpid code needs to be changed to be usable in
ActiveMQ. The intention is to refactor and reuse as much qpid code as
possible (assuming the qpid project accepts those refactors) and work
with the qpid community to ensure we have one codebase for AMQP
framing where possible. A fork is only   a last resort when you can't
work with a community after trying all other possibilities.

Now we have the spike working, we can step back and compare the two
sets of qpid framing code to see if we can refactor things into one
library we can share (hopefully) - or at least find the common bits we
can share; maybe one common core with 2 optional parts (for MINA v
anything else).

Until this exercise was done it was a little hard to know exactly what
would need to be changed in the qpid marshalling/framing code so that
we could reuse it in ActiveMQ


> The second reason certainly applies here and perhaps the first one does
> as well.

I think both qpid and ActiveMQ could share the same framing code (or
at least large chunks of it) especially if the qpid folks are happy to
live with some refactors to make the framing code a little easier to
work with & allow the MINA stuff to be decoupled


> Regardless, moving to a more componentized code base for qpid
> is desirable and will happen (though perhaps not fast enough for everyone).

Cool


> On more specific issues, the main obstacle in reuse of the framing layer
> is I believe the coupling to Mina.

Agreed.

Though Hiram's added a similar Visitor pattern to the generated code
that we use in OpenWire as well which can make working with the
protocol much simpler - it might be nice to add that to qpid too.


> As stated in an earlier mail, I think
> there will always be different needs here: jdk ByteBuffer, mina
> ByteBuffer, Data- Input/Output. As a lot of the code here is already
> generated, we may be able when time allows, to address all needs through
> different (or parameterized) templates.

Agreed. It should be pretty trivial to have MINA and non-MINA generated code.

I wonder if it'd make sense to generate interfaces for the various
AMQP commands; then have a couple of options for generated
implementations (MINA versus pure POJO)?

Then the core framing/exchange handling code could work with either
marshalling approaches.


> At a higher level, e.g. the various exchange classes, there seem to be
> less changes between the codebases now (mainly just repackaging?) so
> maybe there we can more easily share in the short term.

Yeah. The exchange, queue & security packages seem pretty much the
same & could be reused if the MINA code could be decoupled - say
behind an interface / implementation class separation.

e.g. we could share the generated interfaces; then qpid's broker could
depend on the mina-generated implementation classes and ActiveMQ could
depend on the non-mina generated classes (in different packages). Note
this interface separation could further help for dealing with multiple
versions of the protocol etc.

Or another approach could be just to decouple the marshalling code
from the commands e.g. see how Hiram's decoupled the marshalling of
the commands from the actual commands (so the commands themselves have
no dependency on any transport/marshalling code). If that were done we
could then share the same command classes & we'd just have different
marshalling plugins.

Either way, hopefully we can share most of the same framing/exchange
handling code.


Would some qpid-ers be interested in an attempt to merge some of
Hiram's spike back into qpid so we can share more of the
framing/exchange handling code across qpid and ActiveMQ?

-- 

James
-------
http://radio.weblogs.com/0112098/

Mime
View raw message