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