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: ActiveMQ can now support AMQP clients.
Date Thu, 26 Oct 2006 22:13:20 GMT
James

It would be really useful if you would answer my question about code sharing
from Apache ActiveMQ into Apache Qpid too, please.

I could do with some mentoring in this.

Many thanks
John

On 26/10/06, James Strachan <james.strachan@gmail.com> wrote:
>
> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message