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 06:45:42 GMT
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> 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>:
>
> > +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