April 2, 2020
Hot Topics:

Spring: the Eclectic Framework

  • By Vlad Kofman
  • Send Email »
  • More Articles »

Originally, I intended to discuss the Spring framework from the development perspective, but given the fact that there are numerous articles and publications about the topic, including the well-documented reference manual, I decided to switch my focus to the usability of this technology. In this article, I will play the role of the devil's advocate and will concentrate on the framework as a whole, its usefulness, and the problem space it is trying to address. I will still discuss the concepts and components of the framework in detail, and will assume the readers are familiar with Java Web development.


The Spring framework was nominated in the Developer.com contest for the Framework of the Year 2006; I have briefly described its features in the contest-related article. I have also talked about its main features in "Modern Java Frameworks for Web Development", and if you are looking for a very-hands-on, rich-in-details book I suggest Spring in Action from Manning Publishing (see references).

If you have been involved in any way with Web development in the past couple of years, chances are you have invariably created some generic/reusable components in addition to the Web framework you were using. Perhaps you wrote something to reduce the development and maintenance—maybe it was a utility class, wrapper for JDBC connections code, exceptions with meaningful messages, or maybe a re-usable lookup mechanism. The fact is that any popular Web development framework, such as Struts or WebWork, addresses the domain of Web application flow control, provides some kind of MVC, and very rarely tries to give the developers anything extra. Spring, on the other hand, seems to provide a smorgasbord of generic components geared to cover most development needs.

The framework was designed with the following objectives in mind:

  • Good design is more important than underlying technology
  • JavaBeans loosely coupled through interfaces is a good model
  • Code should be easy to test

In fact, Spring looks like a collection of modules to replace EJB and provide many generic services, rather then a Web framework.

The framework is based on code published in Expert One-on-One J2EE Design and Development by Rod Johnson (Wrox, 2002). As of this writing, it is up to version 1.2.8. It consists of several main modules and some smaller ones. They are all encapsulated within a well-defined package and interface structure, and serve a distinct purpose. The framework's purpose cannot be easily defined because all of the modules can be used separately from each other, and a project may use one, some, or all of them. Therefore, Spring (or parts of it) can easily co-exist in any project based on Struts, JSF, WebWork, Tapestry, or any other framework. Some very good design principles are implemented in the framework, such as decoupling of code with interfaces, Factory design pattern, and so forth. Spring also relies heavily on XML config files to tie and wire beans with different logic and from different modules together. In addition, the framework can be integrated with other technologies and has hooks for various third-party Object/Relational Mapping (ORM) technologies, such as JDO, iBATIS, and OJB. As if all of this was not enough, Spring has hooks for JMS, Tiles, and Velocity; and can even work with EJBs (which, by ideology, it is trying to avoid).

Main Features

So, what problem space does the Spring framework really address? Is it only one problem or multiple problems? Who should use Spring? What will involve implementing this technology in an enterprise project? Is there an ROI benefit from it? Is there industry support?

If you are an enterprise architect presented with a new project specification and daunted with the task of choosing a framework, you may be asking yourself these same questions. I'll discuss the main features of this framework and look at their usefulness, ease of implementation, learning curve, and the problem domains they address.

The first question of what problem Spring helps to solve is really difficult to answer. As I have mentioned, there are a lot of problems that Spring is trying to address, but the two main areas the framework concentrates on are: replacing complexity of EJBs with plain Java Beans (or POJOs) and providing easy Web flow or MVC-like framework implementation. Besides these two distinct and unrelated areas, other modules are designed to eliminate tedious database connection open and clean up code (JDBC code wrappers), clear exception handling with meaningful messages, easier JNDI lookup, and so on. Overall, it looks like that framework is trying to provide something for every conceivable problem in Web development.

Here is the view of the Spring packages, from which you also can get the sense of its vast scope and diversity.

The beans and web packages, along with aop and context, are main packages dealing with the two problem domains that I indicated above. Other packages of interest are jdbc, dao, and orm dealing with the database interactions. Most of the packages can be used without the others, so if you only want a scheduling logic (scheduling package), you can use just that.

Spring Concepts

At the heart of Spring lie two extremely powerful concepts: Aspect-Oriented Programming (AOP) and Inversion of Control (IoC).

The IoC is a design pattern (also known as Dependency Injection) that provides one object to another object through injection at runtime, thus inverting or shifting the control from the main object to resolve other objects it needs by providing them at runtime. This sounds complicated, but really it is not.

For example, say that you have an application that shows news to the user and, as a news feed, you are using Reuters World News.

This is a pseudo code of a ShowNews bean that is using another bean, ReutersWorldNews, to show and format the news in a method called show_latest_news.

Class ShowNews {
   ReutersWorldNews rwn = new ReutersWorldNews();

   Public News show_latest_news(){
      news = Rwn.getNews();
      return news.format();


Say that you have decided to add Bloomberg News as another news source. However, that would require rewriting an entire ShowNews class because it is hard coupled with the ReutersWorldNews bean.

To fix this using IoC, you will need to create an interface and provide a specific news feed class (implementing this interface) for use in the ShowNews bean.

For example:

Interface NewsFeed {
   News getNews();

ReutersWorldNews implements NewsFeed ...
BloombergNews    implements NewsFeed ...

The fixed ShowNews class:

Class ShowNews {
   NewsFeed nf;    // now an interface

   void setNewsFeed(NewsFeed injected_news_feed){
   this.nf = injected_news_feed.

   Public News show_latest_news(){
      news = nf.getNews();
      return news.format();


Now, the class can be injected with any news feed that implements NewsFeed interface and there is no hard coupling. This of course is a very simplified example, but it shows the main idea behind this pattern. You can use setter injection, as well as constructor injection, which is a matter of preference.

Page 1 of 2

This article was originally published on June 8, 2006

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date