pro-ductivity and eliminate the potential for common errors such as leaked connections, compared
with direct use of JDBC. The Spring JDBC abstraction integrates with the transaction and DAO
abstractions.
Integration with O/R mapping tools. Spring provides support classes for O/R Mapping tools
like Hibernate, JDO, and iBATIS Database Layer to simplify resource setup, acquisition, and
release, and to integrate with the overall transaction and DAO abstractions. These integration
packages allow applications to dispense with custom ThreadLocal sessions and native transac-tion
handling, regardless of the underlying O/R mapping approach they work with.
Web MVC framework. Spring provides a clean implementation of web MVC, consistent
with the JavaBean configuration approach. The Spring web framework enables web controllers to
be configured within an IoC container, eliminating the need to write any custom code to access
business layer services. It provides a generic DispatcherServlet and out-of-the-box controller
classes for command and form handling. Request-to-controller mapping, view resolution, locale
resolution and other important services are all pluggable, making the framework highly
extensi-ble. The web framework is designed to work not only with JSP, but with any view
technology, such as Velocity—without the need for additional bridges. Chapter 13 discusses web
tier design and the Spring web MVC framework in detail.
Remoting support. Spring provides a thin abstraction layer for accessing remote services
without hard-coded lookups, and for exposing Spring-managed application beans as remote
services. Out-of-the-box support is included for RMI, Caucho’s Hessian and Burlap web service
protocols, and WSDL Web Services via JAX-RPC. Chapter 11 discusses lightweight remoting.
While Spring addresses areas as diverse as transaction management and web MVC, it uses a
consistent approach everywhere. Once you have learned the basic configuration style, you will be
able to apply it in many areas. Resources, middle tier objects, and web components are all set up
using the same bean configuration mechanism. You can combine your entire configuration in one
single bean definition file or split it by application modules or layers; the choice is up to you as the
application developer. There is no need for diverse configuration files in a variety of formats,
spread out across the application.
Spring on J2EE
Although many parts of Spring can be used in any kind of Java environment, it is primarily a
J2EE application framework. For example, there are convenience classes for linking JNDI
resources into a bean factory, such as JDBC DataSources and EJBs, and integration with JTA for
distributed transaction management. In most cases, application objects do not need to work with
J2EE APIs directly, improving reusability and meaning that there is no need to write verbose,
hard-to-test, JNDI lookups.
Thus Spring allows application code to seamlessly integrate into a J2EE environment
without being unnecessarily tied to it. You can build upon J2EE services where it makes sense for
your application, and choose lighter-weight solutions if there are no complex requirements. For
example, you need to use JTA as transaction strategy only if you face distributed transaction
requirements. For a single database, there are alternative strategies that do not depend on a J2EE
container. Switching between those transac-tion strategies is merely a matter of configuration;
Spring’s consistent abstraction avoids any need to change application code.
Spring offers support for accessing EJBs. This is an important feature (and relevant even in a