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 <ja...@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 <jgo...@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 <gno...@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 <hzbar...@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 > > > >> > > > >> > > > > > >
