JavaEnterprise JavaSpring: the Eclectic Framework

Spring: the Eclectic Framework

Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

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.

Background

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.

The only problem that remains is that the use of the news feed class needs to be hard coded in some main logic that uses the ShowNews bean; this is where Spring comes in. Its beans package allows developers to define bean wiring and dependencies in XML and then use some provided bean factory to read this XML, generate the beans, and properly set all injections.

For example, instead of hard coding explicit injection:

ShowNews sn = new ShowNews();
sn.setNewsFeed(new ReutersWorldNew());
sn.show_latest_news();

XML can be created for the Spring purposes.

<beans>
   <bean id="ReutersWorldNew"
         class="com.example.ReutersWorldNew"/>
   <bean id="BloombergNew"
         class="com.example.BloombergNew"/>

   <bean id="ShowNews"
      class="com.example.ShowNews">
      <property name="NewsFeed">
         <ref bean="ReutersWorldNew"/>
      </property>
   </bean>
</beans>

The initiation code then would look like this:

BeanFactory factory =
   new XMLBeanFactory(new FileInputStream("config.xml"));
ShowNews sn = (ShowNews) factory.getBean("ShowNews");
sn.show_latest_news();

If you need to change or add the news source, only the XML config file needs to be updated.

Note: In this example, none of the classes (or beans) reference any of the Spring interfaces or classes. Spring is fully transparent here; that is one of a more attractive features of the framework. Also, note that Spring provides many different implementations of the BeanFactory interface (and design pattern), so that reading XML is relatively easy.

The AOP’s definition is: “The programming paradigm that attempts to aid programmers in the separation of concerns, or the breaking down of a program into distinct parts that overlap in functionality as little as possible. In particular, AOP focuses on the modularization and encapsulation of cross-cutting concerns”.

What this basically means is that business logic should be clearly separated and represented as separate beans whose functionality does not overlap. Moreover, this concept can be extended further than the implementation of only business rules. For example, a bean that shows news should not do any logging, transductions, persistence, or security logic. The AOP aspect of Spring allows precisely that—to non-intrusively add (or weave in) services to the beans in XML, reuse services throughout the application, and separate overlapping functionality.

For example, to add a logging functionality to the News Feed service, something similar to this XML can be used:

<bean id=" ShowNews" class="com.example.ShowNews">
</bean>

<bean id="myLogger" class="com.example.MyLogger">
   <property name="someProperty">
      <value>Custom string property value</value>
   </property>
</bean>

<bean id="debugInterceptor"
      class="org.springframework.aop.interceptor.DebugInterceptor">
</bean>

<bean id="news"
      class="org.springframework.aop.framework.ProxyFactoryBean">
   <property name="proxyInterfaces">
      <value>com.example.ShowNews</value>
   </property>

   <property name="target">
      <ref local="ShowNews"/>
   </property>
   <property name="interceptorNames">
      <list>
         <value>myLogger</value>
         <value>debugInterceptor</value>
      </list>
   </property>
</bean>

Note: The interceptorNames property takes a list of String: the bean names of the interceptor or aspects in the current factory. Also, note the myLogger bean has a primitive string property set in XML as an example.

Spring provides a lot of functionality to wire beans in XML, such as injecting other beans via setters or constructors, setting primitive bean properties, setting collections of bean properties, and using AOP aspects. It can even auto-wire the beans by type or name. All of these features, in particular AOP, are provided by the Spring to eliminate the need to use EJBs. The transactions, security, and any other business rule can be woven as an aspect by using the Spring container.

Devil’s Advocate Discussion

Now, return to the questions of industry support. Who should use Spring and what is involved to implement this technology in an enterprise project? As of this writing, Spring is not supported by any major IDE vendor. There is a stable third-party plug-in for Eclipse, but if you are using any other IDE, you are out of luck. The limited support means that there is no easy (or visual) way to generate configuration XML, which can be quite extensive in a large enterprise application with hundreds of beans and aspects, and thousands of properties. Even complex EJBs can be created visually with any modern IDE, and their code and configuration can be auto generated. To implement Spring in an enterprise project, developers need to learn the “XML language” of Spring configuration, bean wiring, and AOP and then code in both Java and XML. The IDE will not help unless the company adopts Eclipse as a standard, but even after that, a lot of XML will be coded by hand.

Spring’s Web module also is configured via XML and with limited support in IDEs creating a Web application based on Spring, MVC can be a much longer and error-prone process. This can be compared to the JavaServer Faces framework, which offers visual application flow creation and auto XML config generation in most of the IDEs that support it.

Conclusion

In this article, I talked about the Spring framework. I have looked at its features, concepts, and usability. Despite the elegance and eclectic structure of the framework, my biggest concern is the limited industry support and heavy reliance on XML, which is a two-edged sword of the framework. On one hand, XML is the glue and makes the framework truly powerful; on the other, such complex XML should not be written by hand. Unfortunately, without proper tool support, there is not way around it at the moment. Having said that, I believe that Spring offers many useful modules and concepts, and investing some time to learn them can be beneficial. It will be interesting to see what will happen to this technology with the arrival of EJB3 and continued evolution of the other frameworks.

References

About the Author

Vlad Kofman is a Senior System Architect. He has implemented enterprise-scale projects for the major Wall Street firms, defense contracts, and the U.S. government. His main interests are object-oriented programming methodologies and the design patterns.

Get the Free Newsletter!

Subscribe to Developer Insider for top news, trends & analysis

Latest Posts

Related Stories