activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Gomes <jgo...@apache.org>
Subject Re: [PROPOSAL] Pluggable Brokers...
Date Wed, 08 Apr 2015 13:53:59 GMT
I guess if this would help the ActiveMQ developer by reducing code debt and
making maintenance simpler, it's a Good Thing. Pluggable architectures have
a certain amount of overhead, though.

I don't want to discourage interesting and new areas of architecture. The
original message said the pluggable interface would be "above" the broker,
not within it. That's what didn't make a lot of sense to me. If it's above
it, then the obvious plugin interface would be the existing wire protocols:
JMS via OpenWire or STOMP. If it's within the broker, where are the plugin
interface points? Is that what would need to be rearchitected, and is this
a significant amount of effort? I don't know enough of ActiveMQ's internals
to know where the boundaries are for clean separation.

On Wed, Apr 8, 2015, 12:15 AM James Carman <james@carmanconsulting.com>
wrote:

> Pluggable *within* ActiveMQ.  That is what doesn't exist.  The idea is that
> the underlying engine could be optimized on a case-by-case basis.  For
> instance, you may be able to streamline the implementation of a broker that
> doesn't require persistence at all.  Right now, we have one implementation
> that tries to be the end-all-be-all solution for everything.
>
> On Wednesday, April 8, 2015, Jim Gomes <jgomes@apache.org> wrote:
>
> > I'm with Guillaume on this. From the NMS perspective, the broker already
> is
> > a plugin implementation. I don't understand why it would need to go any
> > deeper than that. NMS can talk to TIBCO or ActiveMQ brokers via one
> common
> > API. The idea of pluggable brokers already exists.
> >
> > On Mon, Mar 30, 2015, 8:32 AM Guillaume Nodet <gnodet@apache.org
> > <javascript:;>> wrote:
> >
> > > Fwiw, the whole broker implementation looks like an implementation
> detail
> > > from a user point of view that uses the JMS spec... ;-)
> > >
> > > 2015-03-30 17:12 GMT+02:00 Hadrian Zbarcea <hzbarcea@gmail.com
> > <javascript:;>>:
> > >
> > > > +1.
> > > >
> > > > The blocking today it merely an implementation detail than can be
> > > > addressed.
> > > >
> > > > Hadrian
> > > >
> > > >
> > > > On 03/30/2015 09:23 AM, James Carman wrote:
> > > >
> > > >> All,
> > > >>
> > > >> With all the talk over the last week or so regarding the "Broker
> > > >> Wars", especially after reading Rob Davies' email about how the
> broker
> > > >> has been tweaked through the years to emphasize different aspects
> > > >> (long-term storage for instance), it occurred to me that we might
be
> > > >> able to move past all this craziness by providing an abstraction
> layer
> > > >> above the broker and try to make them "pluggable."
> > > >>
> > > >> If there really are situations where the broker needs to focus on
> one
> > > >> particular aspect of message delivery, that sounds to me like the
> > > >> "strategy" pattern.  If a broker can be written in such a way that
> it
> > > >> is allowed to focus on certain aspects and maybe ignore or
> completely
> > > >> forego others, then it would seem to me that the code could be made
> > > >> much more straight-forward, because it doesn't have to try to be the
> > > >> "swiss army knife", solving everyone's problems at one time.
> > > >>
> > > >> Of course, this may be just a pipe dream and there's no way to do
it
> > > >> (admittedly I'm not terribly familiar with the code), but I thought
> > > >> I'd throw it out there as a possible approach.  I mean, we do this
> > > >> sort of thing already with the persistence providers, so maybe
> there's
> > > >> an opportunity here as well.
> > > >>
> > > >> Thoughts?
> > > >>
> > > >> James
> > > >>
> > > >>
> > >
> >
>

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