Mailing-List: contact dev-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@activemq.apache.org
Received-SPF: pass (nike.apache.org: domain of e.semog@gmail.com designates
 209.85.214.172 as permitted sender)
MIME-Version: 1.0
References: 
 <CALznzY40Cb4FS9dCc=AMFhwVbu+H7QGPfpXj5n6acC3gtpW46g@mail.gmail.com>
 <551967FA.9000409@gmail.com>
 <CAA66TprTyu3Vb=sv7ksRzwrcUtWgm08kP=UcupqQh5cVYi0qog@mail.gmail.com>
 <CAGeZ+biE0eEFvK-57XiN5hc6Os2XqYD0Shbbke8yKbgXBfdRrw@mail.gmail.com>
 <CALznzY6HVd7iKjOVFjm8nAdWHARca84AUQsKM4gTho84kij-5A@mail.gmail.com>
In-Reply-To: 
 <CALznzY6HVd7iKjOVFjm8nAdWHARca84AUQsKM4gTho84kij-5A@mail.gmail.com>
From: Jim Gomes <jgomes@apache.org>
Date: Wed, 08 Apr 2015 13:53:59 +0000
Message-ID: 
 <CAGeZ+bhwNjFf=CS6S=XuWtMaDeUrvx6HBi9Cwy_yKNuZByqSQw@mail.gmail.com>
Subject: Re: [PROPOSAL] Pluggable Brokers...
To: "dev@activemq.apache.org" <dev@activemq.apache.org>
Content-Type: multipart/alternative; boundary=e89a8ff25134f59039051336dc9b

--e89a8ff25134f59039051336dc9b
Content-Type: text/plain; charset=ISO-8859-1

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
> > > >>
> > > >>
> > >
> >
>

--e89a8ff25134f59039051336dc9b--