Posts Tagged ‘AOP’

Why Spring Framework?

November 21, 2009 3 comments



Why Spring Framework?


Since the widespread implementation of J2EE applications in 1999/2000, it has not been an unqualified success in practice. While it has brought a welcome standardization to core middle-tier concepts such as transaction management, many — perhaps most — J2EE applications are over-complex, take excessive effort to develop, and exhibit disappointing performance. EJB  soon became  a widely accepted enterprise solution. But as time passed, many could recognize the disadvantages of using EJB.

In EJB versions prior to 3.0, a single EJB component requires a remote/local interface, a home interface, and a bean implementation class. Hence EJBs were called heavyweight components. Moreover, in those EJB versions, an EJB component could only run within an EJB container and had to look up other EJBs with JNDI (Java Naming and Directory Interface). So EJB components were technology dependent because they could not be reused and tested outside the scope of an EJB container.

Spring framework hence came out to reduce such complexities in enterprise application development. You can think of Spring framework as, minus of EJB’s disadvantages plus a comprehensively layered modular Java/JEE  framework which is flexible, light-weight, less intruisive and technology independent. Spring is applicable in a wide range of environments, not just server-side J2EE applications which was the original motivation. Spring also offers many valuable services for J2EE applications.


Problems with the Traditional Approach to J2EE:

Experience has highlighted specific causes of complexity and other problems in J2EE applications. (Of course, not all of these problems are unique to J2EE!) In particular:

  • J2EE applications tend to contain excessive amounts of “plumbing” code. Many code reviews repeatedly reveal a high proportion of code that doesn’t do anything: JNDI lookup code, Transfer Objects, try/catch blocks to acquire and release JDBC resources. Writing and maintaining such plumbing code proves a major drain on resources that should be focused on the application’s business domain.
  • Many J2EE applications use a distributed object model where it is inappropriate. This is one of the major causes of excessive code and code duplication. It’s also conceptually wrong in many cases. Internally distributed applications are more complex than co-located applications, and often much less performant. Of course, if your business requirements dictate a distributed architecture, you need to implement a distributed architecture and accept the trade-off that incurs (and Spring offers features to help in such scenarios). But you shouldn’t do so without a compelling reason.
  • The EJB component model is unduly complex. EJB was conceived as a way of reducing complexity when implementing business logic in J2EE applications; it has not succeeded in this aim in practice.
  • EJB is overused. EJB was essentially designed for internally distributed, transactional applications. While nearly all non-trivial applications are transactional, distribution should not be built into the basic component model.
  • Many “J2EE design patterns” are not, in fact, design patterns, but workarounds for technology limitations. Overuse of distribution, and use of complex APIs such as EJB, have generated many questionable design patterns; it’s important to examine these critically and look for simpler, more productive, approaches.
  • J2EE applications are hard to unit test. The J2EE APIs, and especially, the EJB component model, were defined before the agile movement took off. Thus their design does not take into account ease of unit testing. Through both APIs and implicit contracts, it is surprisingly difficult to test applications based on EJB and many other J2EE APIs outside an application server. Yet unit testing outside an application server is essential to achieve high test coverage and to reproduce many failure scenarios, such as loss of connectivity to a database. It is also vital to ensuring that tests can be run quickly during the development or maintenance process, minimizing unproductive time waiting for redeployment.
  • Certain J2EE technologies have simply failed. The main offender here is entity beans, which have proven little short of disastrous for productivity and in their constraints on object orientation.


The traditional response to these problems has been to wait for tool support to catch up with the J2EE specifications, meaning that developers don’t need to wrestle with the complexity noted above. However, this has largely failed. Tools based on code generation approaches have not delivered the desired benefits, and have exhibited a number of problems of their own. In this approach, you might generate all those verbose JNDI lookups, Transfer Objects, and try/catch blocks.

In general, experience has shown that frameworks are better than tool-enabled code generation. A good framework is usually much more flexible at runtime than generated code; it should be possible to configure the behavior of one piece of code in the framework, rather than change many generated classes. Code generation also poses problems for round-tripping in many cases. A well-conceived framework can also offer a coherent abstraction, whereas code generation is typically just a shortcut that fails to conceal underlying complexities during the whole project lifecycle. (Often complexities will re-emerge damagingly during maintenance and troubleshooting.)

A framework-based approach recognizes the fact that there is a missing piece in the J2EE jigsaw: the application developer’s view. Much of what J2EE provides, such as JNDI, is simply too low level to be a daily part of programmer’s activities. In fact, the J2EE specifications and APIs can be judged as far more successful, if one takes the view that they do not offer the developer a programming model so much as provide a solid basis on which that programming model should sit. Good frameworks supply this missing piece and give application developers a simple, productive, abstraction, without sacrificing the core capability of the platform.


Using J2EE “out of the box” is not an attractive option. Many J2EE APIs and services are cumbersome to use. J2EE does a great job of standardizing low-level infrastructure, solving such problems as how can Java code access transaction management without dealing with the details of XA transactions. But J2EE does not provide an easily usable view for application code.That is the role of an application framework, such as Spring.


Recognizing the importance of frameworks to successful J2EE projects, many developers and companies have attempted to write their own frameworks, with varying degrees of success. In a minority of cases, the frameworks achieved their desired goals and significantly cut costs and improved productivity. In most cases, however, the cost of developing and maintaining a framework itself became an issue, and framework design flaws emerged. As the core problems are generic, it’s much preferable to work with a single, widely used (and tested) framework, rather than implement one in house.

No matter how large an organization, it will be impossible to achieve a degree of experience matching that available for a product that is widely used in many companies. If the framework is open source, there’s an added advantage in that it’s possible to contribute new features and enhancements that may be adopted. (Of course it’s possible to contribute suggestions to commercial products, but it’s typically harder to influence successful commercial products, and without the source code it’s difficult to make equally useful contributions.) Thus, increasingly, generic frameworks such as Struts and Hibernate have come to replace in-house frameworks in specific areas.

The Spring Framework grew out of this experience of using J2EE without frameworks, or with a mix of in-house frameworks. However, unlike Struts, Hibernate, and most other frameworks, Spring offers services for use throughout an application, not merely in a single architectural tier. Spring aims to take away much of the pain resulting from the issues in the list we’ve seen, by simplifying the programming model, rather than concealing complexity behind a complex layer of tools.


Spring enables you to enjoy the key benefits of J2EE, while minimizing the complexity encountered by application code.The essence of Spring is in providing enterprise services to Plain Old Java Objects (POJOs). This is particularly valuable in a J2EE environment, but application code delivered as POJOs is naturally reusable in a variety of runtime environments.



Spring in Context:

Spring is a manifestation of a wider movement. Spring is the most successful product in what can broadly be termed agile J2EE. While Spring has been responsible for real innovation, many of the ideas it has popularized were part of the zeitgeist and would have become important even had there been no Spring project. Spring’s greatest contribution — besides a solid, high quality, implementation — has been its combination of emerging ideas into a coherent whole, along with an overall architectural vision to facilitate effective use.


Inversion of Control and Dependency Injection: Read more…

Spring Framework Introduction

November 20, 2009 Leave a comment


Chapter 2: Introduction to Spring


Spring Framework:

The Spring framework is a comprehensive layered Java/Java EE application platform. It was created to address the complexity of enterprise application development. The Spring Framework takes best practices and design patterns that have been proven over the years, codifies these patterns as first class objects that can be integrated into applications. Spring makes it possible to use plain-vanilla Java Beans (POJOs) to achieve things that were previously only possible with EJBs.


Spring includes:

  • An IOC lightweight container
  • AOP functionality
  • Abstraction layer for JDBC / transaction management                    
  • ORM integration layer
  • Web integration layer
  • A flexible MVC web application framework 


Spring is not only an application framework, it also serves as a platform for several open source projects that are based on the core Spring Framework project such as Spring IDE, Spring Security, Spring Web Flow, Spring Web Services, Spring Rich Client,  Spring Batch, Spring Modules, Spring Dynamic Modules, Spring Integration, Spring LDAP, Spring JavaConfig, Spring .NET, Spring BeanDoc.


Spring’s features:


Spring makes it possible to develop and maintain complex applications using simple components. In Spring, application objects are configured declaratively typically in an XML file. Spring also provides much infrastructure functionality (transaction management, integration, etc.), leaving only the development of application logic to you.



Spring is lightweight in terms of both size and overhead. Spring Framework can be distributed in a single JAR file that weighs just over 2.5 MB and the processing overhead required by Spring is negligible. Spring is non intrusive in a way that the objects in a Spring-enabled application often have no dependencies on Spring-specific classes.



Spring provides a container which contains and manages the lifecycle and configuration of application objects. In Spring, you can declare how each of application objects should be created, how they should be configured, and how they should be associated with each other.


Dependency Injection:

Spring promotes loose coupling through dependency injection (DI). When DI is applied, objects are passively given their dependencies instead of looking for dependencies themselves. You can think of DI as JNDI in reverse — instead of an object looking up for dependencies from a container, the container gives the dependencies to the object at its instantiation without waiting to be asked.



Spring comes with rich support for aspect-oriented programming (AOP) that enables separating application business logic from system services (such as auditing, transaction management, logging etc). Application objects do what they’re supposed to do i.e., perform business logic — and nothing more. They are not responsible for or even be aware of other system concerns, such as logging or transactional support.


Spring Framework Architecture: Read more…