Module
Summary
Let's now examine the functionality that Spring offers in
more detail. It is divided into a number of separate modules.
There are two main categories of functionality in Spring:
-
An IoC container and AOP framework, which handle
configuration and application of services to objects. -
A set of services that can be applied to application
objects. These services can be used as a class library, even in a different
runtime container.
Each of the modules discussed here fits into one or both of these
categories.
Spring is a layered framework with the following core modules:
-
IoC container: The core of Spring is the IoC container. This configures
objects by Dependency Injection, but also supports a variety of optional
callbacks for application objects that have more complex requirements of their
environment. 33 -
Proxy-based AOP framework: Spring's AOP
framework is the other essential in delivering a non-invasive framework that can
manage POJOs. Spring AOP can be used programmatically, or integrated with the
IoC container, in which case any object managed by a Spring IoC container can be
"advised" transparently. -
Data access abstraction: This
includes:-
The DAO exception hierarchy and consistent architectural
approach discussed earlier in this chapter. -
Template and other integration classes for Hibernate, JDO,
TopLink, iBATIS, and other data access APIs. -
Spring's own JDBC abstraction framework. While in general
Spring's approach to persistence is consistent integration, Spring does provide
one persistence API of its own: its JDBC framework. This is an abstraction layer
over JDBC that simplifies error handling, improves code portability, and
eliminates the potential for many common errors when using JDBC, such as failure
to close connections and other valuable resources in the event of errors.
Spring's JDBC abstraction is suitable when you want SQL-based persistence, and
not O/R mapping: for example, when you have a legacy database that doesn't lend
itself to O/R mapping, or you need to make extensive use of stored procedures or
BLOB types. Spring's JDBC framework is also a good choice if the persistence
needs are limited and you don't want to introduce the learning curve/maintenance
cost of an additional persistence framework such as JDO or
Hibernate.
-
-
Transaction abstraction: Spring provides a transaction abstraction that can run over
a variety of underlying transaction APIs, including JTA, JDBC, Hibernate, and
JDO transactions. Naturally, JTA is the only option for working with multiple
transactional resources, as Spring does not provide its own distributed
transaction manager. However, many applications work with a single database, and
do not require distributed transactions for any other reason (such as working
with JMS). However, Spring's transaction abstraction provides a consistent
programming model in any environment, from high-end J2EE application servers
down to simple web containers and standalone clients: a unique value proposition
that does away with the traditional need to choose between "global" and "local"
transaction management and commit to one or another programming model early in
each J2EE project. Spring provides programmatic declarative management that is
much more usable than JTA, which is a fairly cumbersome API, not ideally suited
for use by application developers. But most users prefer Spring's sophisticated
declarative transaction management, which can provide transaction management for
any POJO. Spring transaction management is integrated with all of Spring's
supported data access integrations. -
Simplification for working with JNDI, EJB, and
other complex J2EE APIs and services: If you're an experienced J2EE
developer, you will have written many JNDI lookups. You may have chosen to move
the lookup code to a helper class, but you can't completely conceal the
complexity, or hide the implications for testing. If you've worked with EJB,
you've needed to write code to look the EJB home up in JNDI before calling the
create() method to obtain an EJB reference you can use
to do work. Chances are, you've done essentially the same thing, over and over,
and worked on applications where many developers have done essentially the same
thing over and over, but in various different ways. These are routine tasks that
are much better done by a framework. Spring's support for JNDI and EJB can
eliminate the need to write boilerplate code for JNDI lookups and EJB access or
implementation. By eliminating JNDI and EJB API dependencies in application
code, it also increases the potential for reuse. For example, you don't need to
write code that depends on an EJB home interface or handles EJB exceptions; you
merely need to express a dependency on the relevant EJB's Business Methods Interface, which is a plain Java interface.
Spring can do the necessary JNDI lookup and create an AOP proxy for the EJB that
hides the need to work with the EJB APIs. Your code is no longer dependent on
EJB — you could choose to implement the Business Methods Interface without using
EJB — and another bit of tedious boilerplate is gone. -
MVC web framework: Spring's own
request-driven MVC framework. This is closely integrated with Spring's
middle-tier functionality, with all controllers being configured by Dependency
Injection, providing the ability to access middle-tier functionality from the
web tier without any code. Spring MVC is similar in how it approaches controller
lifecycle to Struts, but provides some key benefits over struts, such as:-
Better support for view technologies other than JSP, such as
Velocity and PDF generation libraries -
Interceptors, in addition to "actions" or "controllers"
-
Ability to use domain objects to back forms, rather than
special objects such as Struts ActionForm
subclasses -
Interface-based design, making the framework highly
customizable, and avoiding the need to subclass framework classes, which is a
convenience rather than a necessity
-
-
Integration with numerous third-party
products: This fits into Spring's role as architectural glue. As the Spring
IoC container is extensible, it's also easy to "alias" additional services into
Spring IoC. The JndiObjectFactoryBean, which looks up a
named object in JNDI, is a good example. -
Remoting: Spring provides lightweight
remoting support over a variety of protocols, including web services, RMI, RMI
over HTTP, IIOP, and Caucho's Hessian and Burlap protocols. Remoting is
available for POJOs, in keeping with Spring's emphasis on providing a rich
environment for POJOs. -
Simplification for working with EJBs: This
consists of:-
Support for implementing EJBs: EJB 2.1
and earlier have no built-in configuration management. EJB 3.0 looks set to
offer a simplistic Dependency Injection capability. In either case, there is a
compelling value proposition in using a lightweight container behind an EJB
facade. Spring provides support for implementing EJBs that serve as a facade in
front of POJOs managed by a Spring application context. -
Support for accessing EJBs, via the
"codeless proxying" described earlier.
-
-
Message publication using JMS: Spring's
callback template approach is ideally suited to minimizing the complexity of
application code required to publish JMS messages. -
JMX support: Spring 1.2 provides a
powerful JMX layer that can publish any Spring-managed object to JMX, enabling
monitoring and management with standard tools.
When you use Spring's AOP framework, a layer of dynamic
capabilities is available over the Spring IoC container in Spring 1.3: