Enterprise Java Community: Introduction to the Spring Framework

Enterprise Java Community: Introduction to the Spring Framework

This is a basic introduction of Spring Framework.

The author thinks the Spring Framework is unique as:
Spring is unique, for several reasons:

• It addresses important areas that many other popular frameworks don't.
• Spring is both comprehensive and modular.
• Spring is designed from the ground up to help you write code that's easy to test.
• Spring is an increasingly important integration technology

I fully agree with it. The loose couple and tight couple inside way makes Spring eases to be used in any kind of applications.

Architectural benefits of Spring

Before we get down to specifics, let's look at some of the benefits Spring can bring to a project:

• Spring can effectively organize your middle tier objects, whether or not you choose to use EJB. Spring takes care of plumbing that would be left up to you if you use only Struts or other frameworks geared to particular J2EE APIs. And while it is perhaps most valuable in the middle tier, Spring's configuration management services can be used in any architectural layer, in whatever runtime environment.
• Spring can eliminate the proliferation of Singletons seen on many projects.
• Spring can eliminate the need to use a variety of custom properties file formats, by handling configuration in a consistent way throughout applications and projects. Ever wondered what magic property keys or system properties a particular class looks for, and had to read the Javadoc or even source code? With Spring you simply look at the class's JavaBean properties or constructor arguments. The use of Inversion of Control and Dependency Injection (discussed below) helps achieve this simplification.
• Spring can facilitate good programming practice by reducing the cost of programming to interfaces, rather than classes, almost to zero.
• Spring is designed so that applications built with it depend on as few of its APIs as possible. Most business objects in Spring applications have no dependency on Spring.
• Applications built using Spring are very easy to unit test.
• Spring can make the use of EJB an implementation choice, rather than the determinant of application architecture. You can choose to implement business interfaces as POJOs or local EJBs without affecting calling code.
• Spring helps you solve many problems without using EJB. Spring can provide an alternative to EJB that's appropriate for many applications. For example, Spring can use AOP to deliver declarative transaction management without using an EJB container; even without a JTA implementation, if you only need to work with a single database.
• Spring provides a consistent framework for data access, whether using JDBC or an O/R mapping product such as TopLink, Hibernate or a JDO implementation.
• Spring provides a consistent, simple programming model in many areas, making it an ideal architectural "glue." You can see this consistency in the Spring approach to JDBC, JMS, JavaMail, JNDI and many other important APIs.

Spring is essentially a technology dedicated to enabling you to build applications using POJOs. This desirable goal requires a sophisticated framework, which conceals much complexity from the developer.

What does Spring do?

Mission statement
POJO-based programming model
Spring is portable between application servers.
Inversion of control container
The core of Spring is the org.springframework.beans package, designed for working with JavaBeans.
The most commonly used BeanFactory definitions are:

• XmlBeanFactory. This parses a simple, intuitive XML structure defining the classes and properties of named objects. We provide a DTD to make authoring easier.
• DefaultListableBeanFactory: This provides the ability to parse bean definitions in properties files, and create BeanFactories programmatically.

The concept behind Inversion of Control is often expressed in the Hollywood Principle: "Don't call me, I'll call you." IoC moves the responsibility for making things happen into the framework, and away from application code. Whereas your code calls a traditional class library, an IoC framework calls your code. Lifecycle callbacks in many APIs, such as the setSessionContext() method for session EJBs, demonstrate this approach.

Spring provides sophisticated support for both Setter Injection (injection via JavaBean setters); and Constructor Injection (injection via constructor arguments), and even allows you to mix the two when configuring the one object.

JDBC abstraction and data access exception hierarchy

Spring addresses these problems in two ways:

• By providing APIs that move tedious and error-prone exception handling out of application code into the framework. The framework takes care of all exception handling; application code can concentrate on issuing the appropriate SQL and extracting results.
• By providing a meaningful exception hierarchy for your application code to work with in place of SQLException.

This is really cute feature that I like. It frees most of 3 tiers application developers paint.

Spring JDBC can help you in several ways:

• You'll never need to write a finally block again to use JDBC
• Connection leaks will be a thing of the past
• You'll need to write less code overall, and that code will be clearly focused on the necessary SQL
• You'll never need to dig through your RDBMS documentation to work out what obscure error code it returns for a bad column name. Your application won't be dependent on RDBMS-specific error handling code.
• Whatever persistence technology use, you'll find it easy to implement the DAO pattern without business logic depending on any particular data access API.
• You'll benefit from improved portability (compared to raw JDBC) in advanced areas such as BLOB handling and invoking stored procedures that return result sets.

O/R mapping integration

Of course often you want to use O/R mapping, rather than use relational data access. Your overall application framework must support this also. Thus Spring integrates out of the box with Hibernate (versions 2 and 3), JDO (versions 1 and 2), TopLink and other ORM products. Its data access architecture allows it to integrate with any underlying data access technology. Spring and Hibernate are a particularly popular combination.

Why would you use an ORM product plus Spring, instead of the ORM product directly? Spring adds significant value in the following areas:

• Session management.
• Resource management.
• Integrated transaction management.
• Exception wrapping, as described above.
• To avoid vendor lock-in.
  
• Ease of testing.

Above all, Spring facilitates a mix-and-match approach to data access. Spring enables a consistent architecture, and transaction strategy, even if you mix and match persistence approaches, even without using JTA.

AOP

The first goal of Spring's AOP support is to provide J2EE services to POJOs. Spring AOP is portable between application servers, so there's no risk of vendor lock in.

Spring AOP supports method interception. Key AOP concepts supported include:

• Interception: Custom behaviour can be inserted before or after method invocations against any interface or class. This is similar to "around advice" in AspectJ terminology.
• Introduction: Specifying that an advice should cause an object to implement additional interfaces. This can amount to mixin inheritance.
• Static and dynamic pointcuts: Specifying the points in program execution at which interception should take place. Static pointcuts concern method signatures; dynamic pointcuts may also consider method arguments at the point where they are evaluated. Pointcuts are defined separately from interceptors, enabling a standard interceptor to be applied in different applications and code contexts.

Spring supports both stateful (one instance per advised object) and stateless interceptors (one instance for all advice).

Spring does not support field interception.

Spring integrates with AspectJ, providing the ability to seamlessly include AspectJ aspects into Spring applications

MVC web framework

• Spring provides a very clean division between controllers, JavaBean models, and views.
• Spring's MVC is very flexible. Unlike Struts, which forces your Action and Form objects into concrete inheritance (thus taking away your single shot at concrete inheritance in Java), Spring MVC is entirely based on interfaces. Furthermore, just about every part of the Spring MVC framework is configurable via plugging in your own interface. Of course we also provide convenience classes as an implementation option.
• Spring, like WebWork, provides interceptors as well as controllers, making it easy to factor out behavior common to the handling of many requests.
• Spring MVC is truly view-agnostic. You don't get pushed to use JSP if you don't want to; you can use Velocity, XLST or other view technologies. If you want to use a custom view mechanism - for example, your own templating language - you can easily implement the Spring View interface to integrate it.
• Spring Controllers are configured via IoC like any other objects. This makes them easy to test, and beautifully integrated with other objects managed by Spring.
• Spring MVC web tiers are typically easier to test than Struts web tiers, due to the avoidance of forced concrete inheritance and explicit dependence of controllers on the dispatcher servlet.
• The web tier becomes a thin layer on top of a business object layer. This encourages good practice. Struts and other dedicated web frameworks leave you on your own in implementing your business objects; Spring provides an integrated framework for all tiers of your application.

Implementing EJBs
Using EJBs
Testing


Most of the key point of spring framework already mentioned here, but there are lots of part we haven't covered, or didn't touch the details: e.g. Spring Web Flow, Spring AOP, Available modules.