What is Spring
Modules of Spring Framework
Sweet Spot of framework
What is Spring
Spring is grate application framework for development of Enterprise grade applications.
Spring is a dependency injection (sometimes known as inversion of control) framework, designed to make configuring and connecting numerous java objects easier.
Key features
- Built-in generic strategies for JTA and a single JDBC DataSource. This removes the dependency on a Java EE environment for transaction support.[citation needed]
- Extensive aspect-oriented programming framework to provide services such as transaction management. As with the Inversion-of-Control parts of the system, this aims to improve the modularity of systems created using the framework.
Modules of the Spring Framework
Spring is well-organized architecture consisting of seven modules.
1.IOC-To manage interdependecy between Objects.-xml Flies
IoC container.
||-->
org.springframework.context
||-->
org.springframework.beans(advanced configuration mechanism
)
||-->.factory.BeanFactory
||
||-->XmlBeanFactory implementation BeanFactory
2.AOP-meta data
3.Application Context-To manage validation,Global Resource,Event Handle
4.ORM-Data base Management through xml file
5.DAO-Data base Management
6.Spring MVC
Client Request->
||
||
Dispatcher Servlet(web.xml->
||
||
Handler Mapping(xml file)->
||
||
Controler(java)->
||
||
ModelAndView(Controler class Return type )->
||
||
Dispatch Servlet->
||
||
View Resolver->
||
||
Response To Client
7.Spring Web
The Spring Framework can be considered as a collection of smaller frameworks or frameworks-in-the-framework. Most of these frameworks are designed to work independently of each other yet provide better functionalities when used together. These frameworks are divided along the building blocks of typical complex applications:
Inversion of Control container
IoC container.
org.springframework.context
The ApplicationContext interface builds on top of the BeanFactory
ApplicationContext functionality
-->such as easier integration with Spring's AOP features,
-->message resource handling (for use in internationalization),
-->event propagation, and
-->application-layer specific contexts such as the WebApplicationContext for use in web applications.
-->and any description of BeanFactory capabilities and behavior is to be considered
to apply to the ApplicationContext as well
org.springframework.beans
The BeanFactory interface provides an advanced configuration mechanism
capable of managing objects of any nature.
The org.springframework.beans.factory.BeanFactory
BeanFactory is the actual representation of the Spring IoC container that is responsible for containing and otherwise managing the aforementioned beans.
XmlBeanFactory implementation BeanFactory
This implementation allows you to express the objects that compose your application, and the doubtless rich
interdependencies between such objects, in terms of XML.
The XmlBeanFactory takes this XML configuration metadata and uses it to create a fully configured system or application.
XML configuration metadata +Business object =appplication (interdependencies between such objects)
Central in the Spring Framework is its Inversion of Control container that provides a consistent means of configuring and managing Java objects. This container is also known as BeanFactory, ApplicationContext or Core container.
The container has many responsibilities and extension points that can all be considered as forms of Inversion of Control, hence its name. Examples are: creating objects, configuring objects, calling initialization methods and passing objects to registered callback objects. Many of the functionalities of the container together form the object lifecycle which is one of the most important features it provides.
Objects that are created by the container are also called Managed Objects or Beans. Typically the container is configured by loading XML files that contain Bean definitions. These provide all information that is required to create objects. Once objects are created and configured without raising error conditions they become available for use. 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, either via constructors, properties, or factory methods.
In many cases it's not necessary to 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[citation needed].
The container can be turned into a partially-compliant EJB3 container by means of the Pitchfork project. This project by itself however does not make the container fully compliant with the EJB3 specifications. The Spring Framework is criticized by some as not being standards compliant. SpringSource doesn't see EJB3 compliance as a major goal and claims the Spring Framework and the container allow for more powerful programming models[2].
Aspect-oriented programming framework
The Spring Framework has its own AOP framework that 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 versatile and flexible Spring Container to ease configuration and add features.
The Spring AOP framework is interception-based and configured at runtime. This removes the need for a special compilation step or load-time weaving. On the other hand interception only allows for public or protected method execution on existing objects at a join point. The trade-off between simplicity and available features is an important one as Spring AOP is reasonably powerful yet remains reasonably easy to learn.
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 has more integration with AspectJ, for example the pointcut language is reused.
Spring AOP has been designed to make it reasonably easy to work with cross-cutting concerns inside the Spring Framework. Any object that 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
- @AspectJ-based annotation style
Spring team decided not to introduce new AOP-related terminology, therefore in Spring reference documentation or API all the terms such as aspect, join point, advice, pointcut, introduction, target object (advised object), AOP proxy or weaving means the same as in context the most of the existing 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[2], iBatis[3], Hibernate[4], JDO[5], JPA[6], Oracle TopLink, Apache OJB[7] and Cayenne[8], among others.
For all 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 [9]. In response the Spring developers have made it possible to directly use the Hibernate and JPA APIs. 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 are kept intact. The Spring Framework is the only framework available in Java that offers managed data access environments outside of an application server or container.[citation needed]
Transaction management framework
Spring's transaction management framework brings an abstraction mechanism to the Java platform. Its abstraction is capable of:
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
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
The Spring Framework features its own MVC framework, which wasn't originally planned. The Spring developers decided to write their own web framework as a reaction to the poor design[neutrality disputed] of the popular Jakarta Struts web framework [10].
Like Struts, Spring MVC is a request-based framework. The framework defines strategy interfaces for all responsibilities that have to be handled by a modern request-based framework. The responsibility of each interface is sufficiently simple and clear that it's easy for Spring MVC users to write their own implementations if they choose to. All interfaces are tightly coupled to the Servlet API to offer the full power of this API. This tight coupling to the Servlet API is seen by some as a failure on the part of the Spring developers to offer a high-level abstraction for web-based applications[citation needed]. However, this coupling makes sure that the features of the Servlet API remain available to developers while offering a high abstraction framework to ease working with said API.
The DispatcherServlet class is the front controller [11] of the framework and is responsible for delegating control to the various interfaces during the execution phases of an 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.
- View: responsible for returning a response to the client
- 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 sufficiently powerful to allow for a wide set of variations in their implementations. Spring MVC ships with implementations of all these interfaces and together offers a powerful 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 is 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, applications can use other parts of the Spring Framework—including the container—and choose not to use Spring MVC.
Because Spring MVC uses the Spring container for configuration and assembly, web-based applications can take full advantage of the Inversion of Control features offered by the container.
