Re: Any advantage in using Spring?

[Bruce Snyder <br...@gmail.com>]

On Fri, Aug 21, 2009 at 4:54 PM, gonzus<go...@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)U8V4\@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

Re: Any advantage in using Spring?

[Bruce Snyder <br...@gmail.com>]

On Sat, Aug 22, 2009 at 10:28 AM, gonzus<go...@diethelm.org> wrote:
>
> Hello Bruce, thanks for your response.
>
>
> bsnyder wrote:
>>
>> 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.
>>
>
> Ok, this is exactly the kind of opinion / information I was looking for.
> Thanks for sharing it.
>
>
> bsnyder wrote:
>>
>> 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.
>>
>
> Check. I would conclude, then, that when one develops a JMS client with
> Spring, one can also use all of the other niceties associated with Spring:
> ease of configuration, POJOs, orthogonal transactions and logging, etc. Is
> this right?

Yes, that is correct and a pretty huge benefit given the incredible
amount of goodies in the Spring Framework.

> bsnyder wrote:
>>
>> 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.
>>
>
> Excellent news. I found what I must suppose was an old article on Spring JMS
> that confused me into thinking the people at the Spring project were
> implementing their own flavor of ActiveMQ (that is, a new, complete JMS
> provider); your statement confirms that this is not the case, and that
> Spring JMS is a wrapper around the JMS API, that could be used with any JMS
> provider. Is this correct?

Yes, that is also correct. The Spring Framework does not contain a JMS
provider. Instead it provides JMS client APIs that work with any JMS
provider.

> bsnyder wrote:
>>
>>> 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.
>>
>
> How about some performance concerns stated in the ActiveMQ web site, where
> it says that when you use Spring you might be creating and destroying most /
> all of your JMS objects almost indiscriminately, rather than pooling and
> reusing them? If this is really a problem with Spring JMS, and ActiveMQ has
> a solution for it, would this solution work across all JMS providers (should
> I decide to switch)?

I'm guessing that you're referring to the following page:

http://activemq.apache.org/jmstemplate-gotchas.html

This page is mainly referring to the type of connection factory you're
using with the Spring JmsTemplate. Because connection factories are
specific to the JMS provider, and because not all connection factories
pool sessions, it's important to be aware of the fact that use of a
pooling connection factory is more or less a requirement when using
the Spring JmsTemplate.

The Spring JMS APIs do provide an efficient connection factory named
the CachingConnectionFactory
(http://static.springsource.org/spring/docs/2.5.x/api/org/springframework/jms/connection/CachingConnectionFactory.html).
This class creates one connection and uses it to create many sessions,
a model that works very well with JMS providers. This connection
factory will work with all JMS providers because it wraps the JMS
provider-specific connection factory.

Bruce
-- 
perl -e 'print unpack("u30","D0G)U8V4\@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

Re: Any advantage in using Spring?

[gonzus <go...@diethelm.org>]

Hello Bruce, thanks for your response.


bsnyder wrote:
> 
> 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.
> 

Ok, this is exactly the kind of opinion / information I was looking for.
Thanks for sharing it.


bsnyder wrote:
> 
> 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.
> 

Check. I would conclude, then, that when one develops a JMS client with
Spring, one can also use all of the other niceties associated with Spring:
ease of configuration, POJOs, orthogonal transactions and logging, etc. Is
this right?


bsnyder wrote:
> 
> 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.
> 

Excellent news. I found what I must suppose was an old article on Spring JMS
that confused me into thinking the people at the Spring project were
implementing their own flavor of ActiveMQ (that is, a new, complete JMS
provider); your statement confirms that this is not the case, and that
Spring JMS is a wrapper around the JMS API, that could be used with any JMS
provider. Is this correct?


bsnyder wrote:
> 
>> 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.
> 

How about some performance concerns stated in the ActiveMQ web site, where
it says that when you use Spring you might be creating and destroying most /
all of your JMS objects almost indiscriminately, rather than pooling and
reusing them? If this is really a problem with Spring JMS, and ActiveMQ has
a solution for it, would this solution work across all JMS providers (should
I decide to switch)?

Thanks again and best regards.
-- 
View this message in context: http://www.nabble.com/Any-advantage-in-using-Spring--tp25088551p25095336.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.