If there was a semantic behavior in common where this would be possible, we probably wouldn't need any improvements at all.
For instance, when you receive a message, activemq is blocking a thread, while it should be asynchronous on the server, a callback be sent to the client whenever it was possible, from a callback handler. It's different how lockings will happen, what makes a common API even more unlikely. Besides, It gets a bit recursive really, implementing an interface to the broker implementing the broker. I'm not saying it's impossible, but it seems unlikely to be possible. On Mon, Mar 30, 2015 at 9:23 AM, James Carman <ja...@carmanconsulting.com> 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 -- Clebert Suconic http://community.jboss.org/people/clebert.suco...@jboss.com http://clebertsuconic.blogspot.com
