The Spring Solution

Spring essentially has three elements:

• IoC container: The Spring core, which provides highly sophisticated capabilities for configuration management.

• AOP framework: A proxy-based AOP framework that works in conjunction with the Spring IoC container to provide declarative services to POJOs and allow the use of custom aspects.

• Consistent service abstraction and integration: This provides a basis for a POJO application model delivered using IoC and AOP. It also allows Spring to integrate with numerous other products within a consistent conceptual framework.

Let's quickly review some of the major modules in the framework, as shown in the following table.

Module	What It Does	Why and When to Use It
IoC container: bean factory	Basic Spring IoC container. Provides powerful and extensible Dependency Injection capabilities.	If you need a small-footprint IoC container — for example, in use in an applet.
IoC container: application context	More advanced IoC container. Adds resource loading, event publication, and other capabilities.	Normal usage of Spring IoC container. An application context is a bean factory so the usage model is consistent.
AOP framework	Allows sophisticated interception to be applied to any object managed by a Spring container, or programmatically using a proxy factory. Supports core AOP concepts such as pointcuts, making it much more than a simple interception mechanism.	As an enabling technology for Spring enterprise services such as declarative transaction management — in which case there is no need for developers to be consciously aware of the use of AOP. To enable application developers to implement custom aspects to modularize code that would otherwise be scattered throughout an application's object model.
Data access abstraction	Provides a common approach to resource management and exception handling, regardless of which of the supported data access technologies you use. Spring supports the following data access technologies out of the box: Hibernate, JDO, TopLink, iBATIS, and Apache OJB. The framework provides a strong conceptual basis for supporting other APIs. JSR-220 POJO persistence will be supported as soon as the specification and binaries are released in mature form. It is also possible for users to implement support for proprietary or other unsupported data access APIs, while building on Spring's key data access concepts.	We recommend that you use Spring's data access abstraction, whichever data access technology you use. We recommend that you use Spring's data access support to implement persistence framework–agnostic DAO interfaces, meaning that your business service layer is decoupled from the persistence framework.
JDBC abstraction framework	Provides an API layer over JDBC that simplifies exception handling, greatly reduces the amount of code that needs to be written in typical JDBC operations, and reduces the likelihood of making common errors.	Use instead of direct use of JDBC whenever you need to perform SQL-based relational operations.
Transaction abstraction	Integrates with Spring's data access framework to provide a transaction abstraction that works in any environment and can provide declarative transaction management without EJB — even, without JTA.	To decouple application code from the underlying transaction management infrastructure. To provide simpler, more easily testable programmatic transaction management than JTA or local transactions. To provide more powerful and portable declarative transaction management than EJB CMT, for any POJO.
MVC web framework	Spring's own web MVC framework.. Conceptually most similar to Struts.	Use if you prefer a request-based web framework (as opposed to a component-based framework such as Tapestry or JSF) and want a highly flexible, customizable framework that has a clean separation of model, view, and controller responsibilities and can accommodate a wide variety of view technologies.
JMS	Supports publication of JMS messages. Support for message-driven objects — an alternative to message-driven beans — is planned for future releases of Spring.	Use to make sending JMS messages much easier, regardless of how you consume messages.
J2EE integration	Integrates with the core container to avoid the need for JNDI lookups and to make EJBs easier to implement and access.	To decouple application code from the JNDI environment, making it easier to test and use in non-J2EE environments, and making the intent clearer by focusing on the relevant business interfaces providing application functionality, not J2EE API details. Greatly reduces the amount of code you need to write — for example, by wholly eliminating the need to write JNDI lookups or obtain an EJB reference via the EJB's home interface.
Lightweight remoting	Provides remoting support to export POJO services across a range of remoting protocols.	Use to export remote services based on any Spring-managed objects.
JMX support	Provides JMX management to Spring-managed objects. Spring does not provide its own JMX MBean server: Its JMX support integrates with that provided with your application server, or a standalone JMX server.	Use to manage your application objects at runtime with JMX.
Scripting support	To enable any object managed by a Spring container to be written in a scripting language instead of Java.	We discuss when you might choose to implement an object in a language other than Java later in this chapter.

Together, these modules make a coherent whole. Dependency Injection is used consistently within the framework, as is AOP (where necessary). Once you understand the core Spring concepts, you will be able to leverage that knowledge in all parts of the framework.