On Fri, Aug 21, 2009 at 4:54 PM, gonzus<gonzalo.dieth...@diethelm.org> wrote:
>
> As a JMS newbie, I am trying to get my head around ActiveMQ. It seems to me
> that it could be advisable to write ActiveMQ servers and clients using
> Spring technology; at least in theory, one could avoid writing lots of
> boilerplate code and tying the code to any ActiveMQ vagaries... at least in
> theory. Is this really correct in practice?
I have always recommended the use of the Spring Framework for building
Java apps. It's diminishes the complexity of the application and
provides many well-tested, widely used convenience classes. In fact,
ActiveMQ itself is built on top of the Spring Framework.
> On the plus side, do I gain anything from developing on ActiveMQ via Spring?
> If later I wanted to switch to, say, SonicMQ or MQSeries, would the fact
> that the code uses Spring ease this path? Would I avoid lots of boilerplate
> code?
One item I stress to my customers is not to create homegrown JMS
clients unless you have an extremely good reason for doing so. When
creating homegrown JMS clients you need to worry about creating your
own MessageProducers and MessageConsumers, you must manually manage
concurrency, transactionality, and resources. The biggest mistake
people make is underestimating the level of effort and time this
involves. The complexity in creating homegrown JMS clients far
outweighs adopting the tools in the Spring JMS APIs such as the
JmsTemplate and the message listener containers.
In a situation where you might be switching between JMS providers, the
biggest advantage to using the Spring JMS APIs is that you don't need
to rewrite your JMS clients. The Spring JMS APIs will work with any
JMS compliant provider. The work to switch between JMS providers
includes first changing the connection factory that is specific to a
JMS provider, and then testing that the configuration utilized from
the Spring JMS APIs (e.g., caching, concurrent consumers, task
executors, etc.) are appropriate for the new JMS provider.
> On the minus side, would I be likely to fall into any pitfalls by using
> Spring?
Not particularly. As a testament to it's extraordinarily widespread
adoption and incredible flexibility, the Spring Framework has been
deployed with all the application servers and web containers in
existence as well as with POJO-based applications, too. I've always
been very surprised how far and wide I've seen the Spring Framework
used on my travels as a consultant over the years.
Bruce
--
perl -e 'print
unpack("u30","D0G)u8...@4vyy9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
ActiveMQ in Action: http://bit.ly/2je6cQ
Blog: http://bruceblog.org/
Twitter: http://twitter.com/brucesnyder
