The Spring framework began as one programmer's need to solve a set of problems that Sun had tried to solve through edict in the Enterprise JavaBeans (EJB) Specification. At the time, companies were putting a lot of money and effort into developing web applications. The lack of established industry standards made management nervous, and development, haphazard. The J2EE specification promised scalability, security, high availability. Enterprise JavaBeans (EJB), as part of the J2EE suite of specifications from Sun, were intended to be as reusable and portable as their non-enterprise counterparts, plain JavaBeans.

When the final draft of the first EJB specification was released in 1998, Java web programmers looked to it as the golden child of enterprise web development.

But what they found was that the many interfaces and configuration files required to create an EJB were awkward, tedious, and prone to error. The EJBs' marriage to the container made unit testing close to impossible. And applications became heavy in the bulk of extra container features.

Since then, certain IDEs and EJB 3.0 have addressed some of these issues, but to many application developers, it's too little, too late.

The reality is that while Java and your business needs are here to stay, everything in between is likely to change, and change often. This takes us back to Java's early notion of portability (“compile once, run everywhere”) - portability is important because in today's programming environment, hardware, operating systems, IDEs, and containers, rapidly change.

Spring provides a POJO (Plain Old Java Object) based configuration environment, a container to manage the instantiation and lifecycle of your POJO components, and a framework to help you put into place some established best practices for your applications. The idea behind Spring is that your code should be well-factored, and components, kept pristine. Your components should run with or without a container, and be testable with minimal to no intrusion from outside classes. In essence, your components should have a life outside of the framework.

And as complete entities unto the themselves, these truly modular components should have a loose affiliation with other components but should not be bogged down in these dependencies. Component factoring in this way has become central to object oriented programming.

While helping you make your code more truly object oriented, Spring introduces you to two new grammars in the world of application development – the Inversion of Control (IoC) container and Aspect Oriented Programming (AOP). Both of these concepts arose naturally from the needs of developers to improve maintainability, productivity, portability, and design.

Spring also provides practical and modular solutions to JDBC connectivity and transaction management. These solutions offer a superset of the traditional JDBC and JTA offered in J2EE containers. The modular design of these aspects of Spring also allow you to leverage these pieces outside of the context of Spring's container.

And this is the beauty of Spring. Spring provides all of these features and tools, and more, in a non-intrusive framework. Spring is a container, but it is also a set of utilities which can be used outside of the container. And in keeping with the idea of portability, the authors of Spring have taken into account where your applications might be today (tangled up in EJB interfaces, or RMI services, for example), and have provided means to port your existing code as simply as possible.