java.interview.preparation: Spring Framework Core Modules

Spring Core Modules
Spring consists of below mentioned main building blocks and these modules provide us bean management, application context, db interaction, JMS interfacing, web module and AOP. Understanding of these core modules help us to use services in our application. These services can be included in our application by simply adding spring library into classpath.

Inversion of Control container (dependency injection)

Central to the Spring Framework is its Inversion of control container, which provides a consistent means of configuring and managing Java objects using reflection. The container is responsible for managing object lifecycles: creating objects, calling initialization methods, and configuring objects by wiring them together.

Objects created by the container are also called Managed Objects or Beans. Typically, the container is configured by loading XML files containing Bean definitions which provide the information required to create the beans.

Objects can be obtained by means of Dependency lookup or Dependency injection. Dependency lookup is a pattern where a caller asks the container object for an object with a specific name or of a specific type. Dependency injection is a pattern where the container passes objects by name to other objects, via either constructors, properties, or factory methods.

In many cases one need not use the container when using other parts of the Spring Framework, although using it will likely make an application easier to configure and customize. The Spring container provides a consistent mechanism to configure applications and integrates with almost all Java environments, from small-scale applications to large enterprise applications.

Aspect-oriented programming framework (AOP)

The Spring Framework has its own AOP framework which modularizes cross-cutting concerns in aspects. The motivation for creating a separate AOP framework comes from the belief that it would be possible to provide basic AOP features without too much complexity in either design, implementation, or configuration. The Spring AOP framework also takes full advantage of the Spring Container.

The Spring AOP framework is interception based, and is configured at run time. This removes the need for a compilation step or load-time weaving. On the other hand, interception only allows for public method-execution on existing objects at a join point.

Compared to the AspectJ framework, Spring AOP is less powerful but also less complicated. Spring 1.2 includes support to configure AspectJ aspects in the container. Spring 2.0 added more integration with AspectJ; for example, the pointcut language is reused and can be mixed with Spring AOP-based aspects. Further, Spring 2.0 added a Spring Aspects library which uses AspectJ to offer common Spring features such as declarative transaction management and dependency injection via AspectJ compile-time or load-time weaving. SpringSource also uses AspectJ for AOP in other Spring projects such as Spring Roo and Spring Insight, with Spring Security also offering an AspectJ-based aspect library.

Spring AOP has been designed to make it able to work with cross-cutting concerns inside the Spring Framework. Any object which is created and configured by the container can be enriched using Spring AOP.

The Spring Framework uses Spring AOP internally for transaction management, security, remote access, and JMX.

Since version 2.0 of the framework, Spring provides two approaches to the AOP configuration:

schema-based approach and @AspectJ-based annotation style.

The Spring team decided not to introduce new AOP-related terminology; therefore, in the Spring reference documentation and API, terms such as aspect, join point, advice, pointcut, introduction, target object (advised object), AOP proxy, and weaving all have the same meanings as in most other AOP frameworks (particularly AspectJ).

Data access framework

Spring's data access framework addresses common difficulties developers face when working with databases in applications. Support is provided for all popular data access frameworks in Java: JDBC, iBatis / MyBatis, Hibernate, JDO, JPA, Oracle TopLink, Apache OJB, and Apache Cayenne, among others.

For all of these supported frameworks, Spring provides these features

Resource management - automatically acquiring and releasing database resources

Exception handling - translating data access related exception to a Spring data access hierarchy

Transaction participation - transparent participation in ongoing transactions

Resource unwrapping - retrieving database objects from connection pool wrappers

Abstraction for BLOB and CLOB handling

All these features become available when using Template classes provided by Spring for each supported framework. Critics say these Template classes are intrusive and offer no advantage over using (for example) the Hibernate API directly. In response, the Spring developers have made it possible to use the Hibernate and JPA APIs directly. This however requires transparent transaction management, as application code no longer assumes the responsibility to obtain and close database resources, and does not support exception translation.

Together with Spring's transaction management, its data access framework offers a flexible abstraction for working with data access frameworks. The Spring Framework doesn't offer a common data access API; instead, the full power of the supported APIs is kept intact. The Spring Framework is the only framework available in Java which offers managed data access environments outside of an application server or container. While using Spring for transaction management with Hibernate, the following beans may have to be configured

DataSource like com.mchange.v2.c3p0.ComboPooledDataSource or org.apache.commons.dbcp.BasicDataSource
SessionFactory like org.springframework.orm.hibernate3.LocalSessionFactoryBean with a DataSource attribute
HibernateProperties like org.springframework.beans.factory.config.PropertiesFactoryBean
TransactionManager like org.springframework.orm.hibernate3.HibernateTransactionManager with a SessionFactory attribute

Other configurations

AOP configuration of cutting points using
Transaction semantics of AOP advice using

Transaction management framework

Spring's transaction management framework brings an abstraction mechanism to the Java platform. Its abstraction is capable of:

Working with local and global transactions (local transaction does not require an application server)
Working with nested transactions
Working with transaction savepoints
Working in almost all environments of the Java platform

In comparison, JTA only supports nested transactions and global transactions, and requires an application server (and in some cases also deployment of applications in an application server).

The Spring Framework ships a PlatformTransactionManager for a number of transaction management strategies:

Transactions managed on a JDBC Connection
Transactions managed on Object-relational mapping Units of Work
Transactions managed via the JTA TransactionManager and UserTransaction
Transactions managed on other resources, like object databases

Next to this abstraction mechanism the framework also provides two ways of adding transaction management to applications:

Programmatically, by using Spring's TransactionTemplate

Configuratively, by using metadata like XML or Java 5 annotations (@Transactional, etc)

Together with Spring's data access framework — which integrates the transaction management framework — it is possible to set up a transactional system through configuration without having to rely on JTA or EJB. The transactional framework also integrates with messaging and caching engines.

Model-view-controller framework (MVC)

The Spring Framework features its own MVC web application framework, which wasn't originally planned. The Spring developers decided to write their own web framework as a reaction to what they perceived as the poor design of the (then) popular Jakarta Struts web framework, as well as deficiencies in other available frameworks. In particular, they felt there was insufficient separation between the presentation and request handling layers, and between the request handling layer and the model.

The DispatcherServlet class is the front controller of the framework and is responsible for delegating control to the various interfaces during the execution phases of a HTTP request.

The most important interfaces defined by Spring MVC, and their responsibilities, are listed below:

HandlerMapping: selecting objects that handle incoming requests (handlers) based on any attribute or condition internal or external to those requests

HandlerAdapter: execution of objects that handle incoming requests

Controller: comes between Model and View to manage incoming requests and redirect to proper response. It acts as a gate that directs the incoming information. It switches between going into model or view.

View: responsible for returning a response to the client. Some requests may go straight to view without going to the model part; others may go through all three.

ViewResolver: selecting a View based on a logical name for the view (use is not strictly required)

HandlerInterceptor: interception of incoming requests comparable but not equal to Servlet filters (use is optional and not controlled by DispatcherServlet).

LocaleResolver: resolving and optionally saving of the locale of an individual user

MultipartResolver: facilitate working with file uploads by wrapping incoming requests

Each strategy interface above has an important responsibility in the overall framework. The abstractions offered by these interfaces are powerful, so to allow for a set of variations in their implementations, Spring MVC ships with implementations of all these interfaces and together offers a feature set on top of the Servlet API. However, developers and vendors are free to write other implementations. Spring MVC uses the Java java.util.Map interface as a data-oriented abstraction for the Model where keys are expected to be string values.

The ease of testing the implementations of these interfaces seems one important advantage of the high level of abstraction offered by Spring MVC. DispatcherServlet is tightly coupled to the Spring Inversion of Control container for configuring the web layers of applications. However, web applications can use other parts of the Spring Framework—including the container—and choose not to use Spring MVC.

Remote access framework

Spring's Remote Access framework is an abstraction for working with various RPC-based technologies available on the Java platform both for client connectivity and exporting objects on servers. The most important feature offered by this framework is to ease configuration and usage of these technologies as much as possible by combining Inversion of Control and AOP.

The framework also provides fault-recovery (automatic reconnection after connection failure) and some optimizations for client-side use of EJB remote stateless session beans.

Spring provides support for these protocols and products out of the box:

HTTP-based protocols

Hessian: binary serialization protocol, open-sourced and maintained by CORBA-based protocols
RMI (1): method invocations using RMI infrastructure yet specific to Spring
RMI (2): method invocations using RMI interfaces complying with regular RMI usage
RMI-IIOP (CORBA): method invocations using RMI-IIOP/CORBA

Enterprise JavaBean client integration

Local EJB stateless session bean connectivity: connecting to local stateless session beans
Remote EJB stateless session bean connectivity: connecting to remote stateless session beans

SOAP

Integration with the Apache Axis web services framework

Apache CXF provides integration with the Spring Framework for RPC-style exporting of object on the server side.

Both client and server setup for all RPC-style protocols and products supported by the Spring Remote access framework (except for the Apache Axis support) is configured in the Spring Core container.

There is alternative open-source implementation (Cluster4Spring) of a remoting subsystem included into Spring Framework which is intended to support various schemes of remoting (1-1, 1-many, dynamic services discovering).

Convention-over-configuration rapid application development

Spring Roo is Spring's Convention-over-configuration solution for rapidly building applications in Java. It currently supports Spring Framework, Spring Security and Spring Web Flow, with remaining Spring projects scheduled to be added in due course. Roo differs from other rapid application development frameworks by focusing on:

Java platform productivity (as opposed to other languages)
Usability (particularly via the shell features and usage patterns)
Runtime avoidance (with associated deployment advantages)
Lock-in avoidance (Roo can be removed within a few minutes from any application)
Extensibility (via add-ons)

Batch framework

Spring Batch is a framework for batch processing that provides reusable functions that are essential in processing large volumes of records, including:

Logging/tracing
Transaction management
Job processing statistics
Job restart
Skip
Resource management

It also provides more advanced technical services and features that will enable extremely high-volume and high performance batch jobs through optimizations and partitioning techniques.

Integration framework

Spring Integration is a framework for Enterprise application integration that provides reusable functions that are essential in messaging, or event-driven architectures.

routers

transformers

adapters to integrate with other technologies and systems (HTTP, AMQP, JMS, XMPP, SMTP, IMAP, FTP (as well as FTPS/SFTP), file systems, etc.)

filters

service activators

management and auditing