1. Springing into action

1.  Spring was created as an alternative to heavier enterprise Java technologies, especially EJB. Spring offered a lighter and leaner programming model as compared to EJB. It empowered plain old Java objects (POJOs) with powers previously only available using EJB and other enterprise Java specifications. These techniques furnish plain-old Java objects (POJOs) with a declarative programming model reminiscent of EJB, but without all of EJB’s complexity. No longer must you resort to writing an unwieldy EJB component when a simple JavaBean will suffice. Leading the charge for lightweight POJO-based development is the Spring Framework.

 

2.  Spring is an open source framework, originally created by Rod Johnson and described in his book “Expert One-on-One: J2EE Design and Development”. It was created to address the complexity of enterprise application development, and makes it possible to use plain-vanilla JavaBeans to achieve things that were previously only possible with EJB.

 

3.  To back up its attack on Java complexity, Spring employs four key strategies:

    1)  Lightweight and minimally invasive development with plain old Java objects (POJOs)

    2)  Loose coupling through dependency injection and interface orientation

    3)  Declarative programming through aspects and common conventions

    4)  Eliminating boilerplate code with aspects and templates

 

4.  Some frameworks lock you in by forcing you to extend one of their classes or implement one of their interfaces. These heavyweight frameworks forced developers to write classes that were littered with unnecessary code, locked into their framework, and were often difficult to write tests against. Spring avoids (as much as possible) littering your application code with its API. Spring almost never forces you to implement a Spring-specific interface or extend a Spring-specific class. Instead, the classes in a Spring-based application often have no indication that they’re being used by Spring. At worst, a class may be annotated with one of Spring’s annotations, but is otherwise a POJO.

 

5.  Any nontrivial application is made up of two or more classes that collaborate with each other to perform some business logic. Traditionally, each object is responsible for obtaining its own references to the objects it collaborates with (its dependencies). This can lead to highly coupled and hard-to-test code.

 

6.  Coupling is a two-headed beast. On one hand, tightly coupled code is difficult to test, difficult to reuse, difficult to understand, and typically exhibits “whack-a-mole” bug behavior (fixing one bug results in the creation of one or more new bugs). On the other hand, a certain amount of coupling is necessary—completely uncoupled code doesn’t do anything. In order to do anything useful, classes need to know about each other somehow. Coupling is necessary, but should be carefully managed. With DI, on the other hand, objects are given their dependencies at creation time by some third party that coordinates each object in the system. Objects aren’t expected to create or obtain their dependencies—dependencies are injected into the objects that need them.

 

7.  The key benefit of DI is loose coupling. If an object only knows about its dependencies by their interface (not by their implementation or how they’re instantiated), then the dependency can be swapped out with a different implementation without the depending object knowing the difference. One of the most common ways that a dependency will be swapped out is with a mock implementation during testing.

 

8.  The act of creating associations between application components is commonly referred to as wiring. In Spring, there are many ways to wire components together, but a common approach has always been via XML. If XML configuration doesn’t suit your tastes, you might like to know that Spring also allows you to express configuration using Java.

 

9. In a Spring application, an application context loads bean definitions and wires them together. The Spring application context is fully responsible for the creation of and wiring of the objects that make up the application. Spring comes with several implementations of its application context, each primarily differing only in how they load their configuration.

 

10.  ClassPathXmlApplicationContext implementation loads the Spring context from one or more XML files located in the application’s classpath. For Java-based configurations, Spring offers AnnotationConfigApplicationContext.

 

11.  Although DI makes it possible to tie software components together loosely, aspect-oriented programming (AOP) enables you to capture functionality that’s used throughout your application in reusable components.

 

12.  System services such as logging, transaction management, and security often find their way into components whose core responsibility is something else. These system services are commonly referred to as cross-cutting concerns because they tend to cut across multiple components in a system. By spreading these concerns across multiple components, you introduce two levels of complexity to your code:

    1)  The code that implements the system-wide concerns is duplicated across multiple components. This means that if you need to change how those concerns work, you’ll need to visit multiple components. Even if you’ve abstracted the concern to a separate module so that the impact to your components is a single method call, that method call is duplicated in multiple places.

    2)  Your components are littered with code that isn’t aligned with their core functionality. A method to add an entry to an address book should only be concerned with how to add the address and not with whether it’s secure or transactional.

 
 

AOP makes it possible to modularize these services and then apply them declaratively to the components that they should affect. This results in components that are more cohesive and that focus on their own specific concerns, completely ignorant of any system services that may be involved. At its core, an application consists of modules that implement business functionality. With AOP, you can then cover your core application with layers of system functionality. These layers can be applied declaratively throughout your application in a flexible manner without your core application even knowing they exist. This is a powerful concept, as it keeps the security, transaction, and logging concerns from littering the application’s core business logic.

 

13.  JDBC’s not alone in the boilerplate code business. Many activities often require similar boilerplate code. JMS, JNDI, and the consumption of REST services often involve a lot of commonly repeated code. Spring seeks to eliminate boilerplate code by encapsulating it in templates.

 

14.  In a Spring-based application, your application objects will live within the Spring container. The container will create the objects, wire them together, configure them, and manage their complete lifecycle from cradle to grave.

 

15.  The container is at the core of the Spring Framework. Spring’s container uses dependency injection (DI) to manage the components that make up an application. This includes creating associations between collaborating components.

 

16.  Spring comes with several container implementations that can be categorized into two distinct types. Bean factories (defined by the org.springframework.beans.factory.BeanFactory interface) are the simplest of containers, providing basic support for DI. Application contexts (defined by the org.springframework.context.ApplicationContext interface) build on the notion of a bean factory by providing application framework services, such as the ability to resolve textual messages from a properties file and the ability to publish application events to interested event listeners. Although it’s possible to work with Spring using either bean factories or application contexts, bean factories are often too low-level for most applications. Therefore, application contexts are preferred over bean factories.

 

17.  Spring comes with several flavors of application context:

    1)  AnnotationConfigApplicationContext —Loads a Spring application context from one or more Java-based configuration classes.

     2)  AnnotationConfigWebApplicationContext —Loads a Spring web application context from one or more Java-based configuration classes.

    3)  ClassPathXmlApplicationContext—Loads a context definition from an XML file located in the classpath, treating context definition files as classpath resources.

    4)  FileSystemXmlApplicationContext—Loads a context definition from an XML file in the file system.

    5)  XmlWebApplicationContext—Loads context definitions from an XML file contained within a web application.

 

18.  With an application context in hand, you can retrieve beans from the Spring container by calling the context’s getBean() method.

 

19.  A bean factory performs several setup steps before a bean is ready to use:

    1)  Spring instantiates the bean.

    2)  Spring injects values and bean references into the bean’s properties.

    3)  If the bean implements BeanNameAware, Spring passes the bean’s ID to the setBeanName() method.

    4)  If the bean implements BeanFactoryAware, Spring calls the setBeanFactory() method, passing in the bean factory itself.

    5)  If the bean implements ApplicationContextAware, Spring will call the setApplicationContext() method, passing in a reference to the enclosing application context.

    6)  If any of the beans implement the BeanPostProcessor interface, Spring calls their postProcessBeforeInitialization() method.

    7)  If any beans implement the InitializingBean interface, Spring calls their afterPropertiesSet() method. Similarly, if the bean was declared with an init-method, then the specified initialization method will be called.

    8)  If there are any beans that implement BeanPostProcessor, Spring will call their postProcessAfterInitialization() method.

    9)  At this point, the bean is ready to be used by the application and will remain in the application context until the application context is destroyed.

    10)  If any beans implement the DisposableBean interface, then Spring will call their destroy() methods. Likewise, if any bean was declared with a destroy-method, then the specified method will be called.

 
 

 

20.  The 20 JAR files that make up Spring can be arranged in one of six different categories of functionality:

 
 

You don’t have to base your application fully on the Spring Framework. You’re free to choose the modules that suit your application and look to other options when Spring doesn’t fit the bill. Spring even offers integration points with several other frameworks and libraries so that you won’t have to write them yourself.

 

22.  Spring’s JDBC and data access objects (DAO) module abstracts away the boilerplate code so that you can keep your database code clean and simple, and prevents problems that result from a failure to close database resources. This module also builds a layer of meaningful exceptions on top of the error messages given by several database servers. No more trying to decipher cryptic and proprietary SQL error messages. For those who prefer using an object-relational mapping (ORM) tool over straight JDBC, Spring provides the ORM module. Spring’s ORM support builds on the DAO support, providing a convenient way to build DAOs for several ORM solutions. Spring doesn’t attempt to implement its own ORM solution, but does provide hooks into several popular ORM frameworks, including Hibernate, Java Persistence API, Java Data Objects, and iBATIS SQL Maps. Spring’s transaction management supports each of these ORM frameworks as well as JDBC. This module also includes a Spring abstraction over the Java Message Service (JMS) for asynchronous integration with other applications through messaging. In addition, this module uses Spring’s AOP module to provide transaction-management services for objects in a Spring application.

 

23.  Java has no shortage of MVC frameworks, with Apache Struts, JSF, WebWork, and Tapestry being among the most popular MVC choices. Even though Spring integrates with several popular MVC frameworks, its web and remoting module comes with a capable MVC framework that promotes Spring’s loosely coupled techniques in the web layer of an application.

 

24.  Spring’s remoting capabilities include Remote Method Invocation (RMI), Hessian, Burlap, JAX-WS, and Spring’s own HTTP invoker. Spring also offers first-class support for exposing and consuming REST APIs.

 

25.  Spring’s instrumentation module includes support for adding agents to the JVM. Specifically, it provides a weaving agent for Tomcat that transforms class files as they’re loaded by the classloader.

 

26.  Within the Test module you’ll find a collection of mock object implementations for writing unit tests against code that works with JNDI, servlets, and portlets. For integration-level testing, this module provides support for loading a collection of beans in a Spring application context and working with the beans in that context.

 

27.  Spring Web Flow builds upon Spring’s core MVC framework to provide support for building conversational, flow-based web applications that guide users toward a goal (think wizards or shopping carts). And you can learn more about Spring Web Flow from its home page at http://www.springsource.org/webflow.

 

28.  Spring Framework provides for declaratively publishing Spring beans as web services, those services are based on an arguably architecturally inferior contract-last model. The contract for the service is determined from the bean’s interface. Spring Web Services offers a contract-first web services model where service implementations are written to satisfy the service contract. You can read more about it from its home page at http://static.springsource.org/spring-ws/sites/2.0.

 

29.  Implemented using Spring AOP, Spring Security offers a declarative security mechanism for Spring-based applications. For further exploration, Spring Security’s home page is at http://static.springsource.org/spring-security/site.

 

30.  Many enterprise applications must interact with other enterprise applications. Spring Integration offers implementations of several common integration patterns in Spring’s declarative style. If you want more information on Spring Integration, have a look at “Spring Integration in Action” or you can visit the Spring Integration home page at http://www.springsource.org/spring-integration.

 

31.  If you’re going to be developing a batch application, you can leverage Spring’s robust, POJO-oriented development model to do it using Spring Batch. For more information, you can read “Spring Batch in Action”. You can also learn about Spring Batch from its home page at http://static.springsource.org/spring-batch.

 

32.  Whether you’re using a document database like MongoDB, a graph database such as Neo4j, or even a traditional relational database, Spring Data offers a simplified programming model for persistence. This includes, for many database types, an automatic repository mechanism that creates repository implementations for you.

 

33.  Spring Social is a social networking extension to Spring. It helps you connect your Spring application with REST APIs, including many that may not have any social purpose to them. You can find out more about it at http://www.springsource.org/spring-social. The following two links can help you connect with Facebook or Twitter :

https://spring.io/guides/gs/accessing-facebook/ and https://spring.io/guides/gs/accessing-twitter/.

 

35.  Spring Mobile is a new extension to Spring to support development of mobile web applications. Related to Spring Mobile is the Spring Android project, which aims to bring some of the simplicity afforded by the Spring Framework to development of native applications for Android-based devices. You can learn more about them at http://www.springsource.org/spring-mobile and http://www.springsource.org/spring-android.

 

35.  Spring Dynamic Modules (Spring-DM) blends Spring’s declarative dependency injection with OSGi’s dynamic modularity. Using Spring-DM, you can build applications that are composed of several distinct, highly cohesive, loosely coupled modules that publish and consume services declaratively within the OSGi framework. The Spring-DM model for declarative OSGi services has been formalized into the OSGi specification itself as the OSGi Blueprint Container. In addition, SpringSource has transitioned Spring-DM to the Eclipse project as a part of the Gemini family of OSGi projects and is now known as Gemini Blueprint.

 

36.  Spring LDAP brings Spring-style template-based access to LDAP, eliminating the boilerplate code that’s commonly involved in LDAP operations. More information on Spring LDAP can be found at http://www.springsource.org/ldap.

 

37.  Spring Rich Client a rich application toolkit that brings the power of Spring to Swing.

 

38.  The Spring-Flex integration package enables Flex and AIR applications to communicate with server-side Spring beans using BlazeDS. It also includes an addon for Spring Roo to enable rapid application development of Flex applications. You may begin your exploration of Spring Flex at http://www.springsource.org/spring-flex. You may also want to check out Spring ActionScript at http://www.springactionscript.org, which offers many benefits of the Spring Framework in ActionScript.

 

39.  Spring Roo provides an interactive tooling environment that enables rapid development of Spring applications, pulling together the best practices that have been identified over the past few years. More information about Spring Roo can be found at http://www.springsource.org/roo.

 

40.  There’s also a community-driven collection of Spring extensions at http://www.springsource.org/extensions.

 

41.  The significance of Spring 2.5 was that it marked Spring’s embrace of annotation-driven development. Prior to Spring 2.5, XML-based configuration was the norm. With the 3.0 release, Spring one-upped itself with the continuation of the annotation-driven theme and several new features.