|- JavaTouch||- Design Patterns||- Spring Framework||- JEE Home||- JSE Home|
In 1996 the Java programming language was still a young, exciting, up-andcoming platform. Many developers flocked to the language because they had seen how to create rich and dynamic web applications using applets.
Unlike any language before it, Java made it possible to write complex applications made up of discrete parts. They came for theapplets, but they stayed for the components.
It was in December of that year that Sun Microsystems published the Java-Beans 1.00-A specification. JavaBeans defined a software component model for Java. This specification defined a set of coding policies that enabled simple Java objects to be reusable and easily composed into more complex applications. Although JavaBeans were intended as a general-purpose means of defining reusable application components, they have been primarily used as a model for building user interface widgets. They seemed too simple to be capable of any “real”
work. Enterprise developers wanted more.
Sophisticated applications often require services such as transaction support, security, and distributed computing -services not directly provided by the Java-Beans specification. Therefore, in March 1998, Sun published the 1.0 version of the Enterprise JavaBeans (EJB) specification. This specification extended the notion of Java components to the server side, providing the much-needed enterprise services, but failed to continue the simplicity of the original JavaBeans specification. In fact, except in name, EJB bears very little resemblance to the original JavaBeans specification.
Despite the fact that many successful applications have been built based on EJB, EJB never really achieved its intended purpose: to simplify enterprise application development. Every version of the EJB specification contains the following statement: “Enterprise JavaBeans will make it easy to write applications.” It is true that EJB’s declarative programming model simplifies many infrastructural aspects of development, such as transactions and security. But EJBs are complicated in a different way by mandating deployment descriptors and plumbing code (home and remote/local interfaces). Over time many developers became disenchanted with EJB. As a result, its popularity has started to wane in recent years, leaving many developers looking for an easier way.
There had been lots of criticism over its undue complexity and developer productivity. Even for developing a simplest EJB component developers needed to follow tedious cycle which involved deploying to application servers, configuring multiple configuration files, developing multiple classes (home interfaces, remote interfaces etc). It was equally criticized for difficulty in testing EJB components. Sun's EJB specification had been under fire from both developers and customers alike!
Rod Johnson has been one of the world's leading authorities on Java and J2EE development. He is a best-selling author, experienced consultant, and open source developer, as well as a popular conference speaker. Rod's best-selling Expert One-on-One J2EE Design and Development (2002) was one of the most influential books ever published on J2EE.
Rod had been one of the critics of drawbacks of J2EE and the sequel book by him, J2EE without EJB (July 2004, with Juergen Hoeller), has proven almost equally significant, establishing a comprehensive vision for lightweight, post-EJB J2EE development.
The first version of the Spring Framework was written by Rod Johnson and the framework was first released under the Apache 2.0 license in June 2003. The first milestone release was 1.0 which was released in March 2004 with further milestone releases in September 2004 and March 2005.
Although the Spring Framework does not enforce any specific programming model it has become widely popular in the Java community primarily as an alternative and replacement for the Enterprise JavaBean model. By design the framework offers a lot of freedom to Java developers yet provides well-documented and easy to use solutions for common practices in the industry.
While the core features of the Spring Framework are usable in any Java application there are many extensions and improvements for building web-based applications on top of the Java Enterprise platform. Spring has gained a lot of popularity because of this and is recognized by vendors as a strategically important framework.
Interface21 - the company behind the Spring Framework
Spring is an opensource framework. Springframework.com is operated by Interface21 Limited, a privately owned company. The developers that brought you the Spring framework also provide training, consulting and support.
CEO of the Interface21 is Rod Johnson who is the founder of Spring Framework.
The CTO of Interface21 is Adrian Colyer who is the leader of the AspectJ open source project and a well-known industry expert on the topic of aspect-oriented programming (AOP).
Good design is more important than the underlying technology
As a developer, you should always be seeking the best design for your application, regardless of the implementation you choose. Many applications require few, if any, of the services provided by EJB yet are still implemented using this technology for technology’s sake.
With EJB, application complexity is high, regardless of the complexity of the problem being solved—even simple
applications are unduly complex. With Spring, the complexity of your application is proportional to the complexity of the problem being solved.
The idea behind Spring is that you can keep your code as simple as it needs to be. If what you want are some plain-vanilla Java objects to perform some services supported by transparent transactions, you’ve got it.
JavaBeans loosely coupled through interfaces is a good model
If you are relying on EJBs to provide your application services, your components do not just depend on the EJB business interface. They are also responsible for retrieving these EJB objects from a directory, which entails a Java Naming and Directory Interface (JNDI) lookup and communicating with the bean’s EJBHome interface. This is not creating a decoupled application. This is tightly coupling your application to a specific implementation, namely EJB.
With Spring, your beans depend on collaborators through interfaces. Since there are no implementation-specific dependencies, Spring applications are very decoupled, testable, and easier to maintain.
Code should be easy to test
Testing J2EE applications can be difficult. If you are testing EJBs within a container, you have to start up a container to execute even the most trivial of test cases. Since starting and stopping a container is expensive, developers may be tempted to skip testing all of their components. Avoiding tests because of the rigidness of a framework is not a good excuse.
Because you develop Spring applications with JavaBeans, testing is cheap. There is no J2EE container to be started since you will be testing a POJO. And since Spring makes coding to interfaces easy, your objects will be loosely coupled, making testing even easier. A thorough battery of tests should be present in all of your applications; Spring will help you accomplish this.
"Any fool can make things bigger, more complex, and more violent. It takes a touch of genius-and a lot of courage-to move in the opposite direction."
"Anyone who has never made a mistake has never tried anything new."
"The only reason for time is so that everything doesn't happen at once."
"When the solution is simple, God is answering."
- Many developers are describing their experiences with Spring and praising its ease of use.
- Not only does Spring solve developers’ problems, it also enforces good programming practices like coding to
interfaces and, reducing coupling and allowing for easy testability.
- In the modern era of programming, particularly in Java, good developers are practicing Test Driven Development (TDD). TDD is a way of letting your tests, or clients of your classes, drive the design of those classes. Rather than building a class, then trying to retrofit the client, you’re building the client first. This way, you know exactly what you want from the class you’re developing. Spring has a rich test suite of its own that allows for easy testing of your classes.
- Compare this to “best practices” from J2EE, where the blueprints recommend that you use EJBs to handle
business logic. EJBs require an EJB container to run, so you have to startup your container to test them. When’s
the last time you started up an EJB server like WebLogic, WebSphere or JBoss? It can test your patience if you
have to do it over and over to test your classes.
With success, there’s always some criticism. The most compelling argument seen against Spring is that it’s
not a “standard,” meaning it’s not part of the J2EE specification and it hasn’t been developed through the Java
Community Process. The same folks who argue against Spring advocate EJBs, which are standard. However, the
main reason for standards is to ensure portability across appservers. The code you develop for one server should
run on another, but porting EJBs from one EJB container to another is not as simple as it should be. Different
vendors require different deployment descriptors and there’s no common way of configuring data sources or
other container dependencies. However coding business logic with Spring is highly portable across containers –
with no changes to your code or deployment descriptors!
While Spring “makes things easier,” some developers complain that it’s “too heavyweight.” However, Spring is
really an a la carte framework where you can pick and choose what you want to use. The development team has
segmented the distribution so you can use only the Java ARchives (JARs) you need.
The J2EE Design and Development book illustrates Spring and how it works. Spring is a way to configure applications using JavaBeans. When we say JavaBeans, mean Java classes with getters and setters (also called
accessors and mutators) for its class variables. Specifically, if a class exposes setters, Spring configures that
class. Using Spring, you can expose any of your class dependencies (that is, a database connection) with a setter,
and then configure Spring to set that dependency. Even better, you don’t have to write a class to establish the
database connection; you can configure that in Spring too! This dependency resolution has a name: Inversion of
Control or Dependency Injection. Basically, it’s a technical term for wiring dependent objects together through
some sort of container.
In order to have an easily maintainable and extendable application, it’s not desirable to tightly couple your code
to a specific resource (for example, you may have code that uses SQL functions that are specific to a database
type). Of course, it’s often easier to code to a specific database if the proprietary functionality helps you get your
job done quicker. When you do end up coding proprietary functionality into a class, the J2EE Patterns recommend that you use a Factory Pattern to de-couple your application from the implementing class.
The Factory Pattern is a complicated J2EE pattern. Not only does it require two classes to setup, but it also
introduces issues with managing dependencies of those “factoried” objects. For instance, if you’re getting a DAO from the factory, how do you pass in a connection (rather than opening one for each method)? You can pass it in as part of the constructor, but what if you’re using a DAO implementation that requires a Hibernate Session? You could make the constructor parameter a java.lang.Object and than cast it to the required type, but it just
The better way is to use Spring to bind interfaces to implementations. Everything is configured in an XML file and you can easily switch out your implementation by modifying that file. Even better, you can write your unit tests so no one knows which implementation you’re using – and you can run them for numerous implementations.
"Spring is a lightweight inversion of control and aspect-oriented container framework".
Spring makes it possible to use plain-vanilla JavaBeans to achieve things that were previously only possible with EJBs. However, Spring’s usefulness isn’t limited to server-side development. Any Java application can benefit from Spring in terms of simplicity, testability, and loose coupling.
To make more sense of Spring, let’s break this description down;
Spring is lightweight in terms of both size and overhead. The entire Spring framework can be distributed in a single JAR file that weighs in at just over 1 MB. And the processing overhead required by Spring is negligible.
What’s more, Spring is non intrusive: objects in a Spring-enabled application typically have no dependencies on Springspecific classes.
Spring promotes loose coupling through a technique known as inversion of control (IoC). When IoC is applied, objects are passively given their dependencies instead of creating or looking for dependent objects for themselves. You can think of IoC as JNDI in reverse; instead of an object looking up dependencies from a container, the container gives the dependencies to the object at instantiation without waiting to be asked.
Spring comes with rich support for aspect-oriented programming that enables cohesive development by separating application business logic from system services (such as auditing and transaction management).
Application objects do what they’re supposed to do—perform business logic—and nothing more. They are not responsible for (or even aware of) other system concerns, such as logging or transactional support.
Spring is a container in the sense that it contains and manages the life cycle and configuration of application objects. You can configure how your each of your beans should be created—either create one single instance of your bean or produce a new instance every time one is needed based on a configurable prototype—and how they should be associated with each other. Spring should not, however, be confused with traditionally heavyweight EJB containers, which are often large and cumbersome to work with.
Spring makes it possible to configure and compose complex applications from simpler components. In Spring, application objects are composed declaratively, typically in an XML file. Spring also provides much infrastructure functionality (transaction management, persistence framework integration, etc.), leaving the development of application logic to you.
In computer programming, the Hollywood Principle is stated as "don't call us, we'll call you."
The Spring Framework contains a lot of features, which are well-organized in six modules shown in the diagram below.
When taken as a whole, these modules give you everything you need to develop enterprise-ready applications. But you do not have to base your application fully on the Spring framework. You are free to pick and choose the modules that suit your application and ignore the rest.
As you can see, all of Spring’s modules are built on top of the core container.The container defines how beans are created, configured, and managed—more of the nuts-and-bolts of Spring. You will implicitly use these classes when you configure your application. But as a developer, you will most likely be interested in the other modules that leverage the services provided by the container.
Spring’s core container provides the fundamental functionality of the Spring framework. In this module you’ll find Spring’s BeanFactory, the heart of any Spring-based application. A BeanFactory is an implementation of the factory pattern that applies IoC to separate your application’s configuration and dependency specifications from the actual application code. This module is what make spring framework a container.
The Context package build on the solid base provided by the Core package: it provides a way to access objects in a framework-style manner in a fashion somewhat reminiscent of a JNDI-registry. The context package inherits its features from the beans package and adds support for internationalization (I18N) (using for example resource bundles), event-propagation, resource-loading, and the transparent creation of contexts by, for example, a servlet container. In addition, this module supplies many enterprise services such as e-mail, JNDI access, EJB integration, remoting, and scheduling. Also included is support for integration with templating frameworks such as Velocity and FreeMarker.Context module is what makes spring a framework. (This module is not shown in the above diagram, but you may consider this module as part of both Web and JEE modules)
Spring's AOP package provides an AOP Alliance-compliant aspect-oriented programming implementation allowing you to define, for example, method-interceptors and pointcuts to cleanly decouple code implementing functionality that should logically speaking be separated. Using source-level metadata functionality you can also incorporate all kinds of behavioral information into your code, in a manner similar to that of .NET attributes.
To ensure interoperability between Spring and other AOP frameworks, much of Spring’s AOP support is based on the API defined by the AOP Alliance. The AOP Alliance is an open-source project whose goal is to promote adoption of AOP and interoperability among different AOP implementations by defining a common set of interfaces and components. You can find out more about the AOP Alliance by visiting their website at http://aopalliance.sourceforge.net.
Working with JDBC often results in a lot of boilerplate code that gets a connection, creates a statement, processes a result set, and then closes the connection. 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! Also, the JDBC package provides a way to do programmatic as well as declarative transaction management, not only for classes implementing special interfaces, but for all your POJOs (plain old Java objects).
Spring doesn’t attempt to implement its own ORM (object-relational mapping) solution, but does provide hooks into several popular ORM frameworks, including Hibernate, JDO, and iBATIS SQL Maps. Spring’s simple declarative transaction management supports each of these ORM frameworks as well as JDBC.
The Spring Web (context) module builds on the application context module, providing a context that is appropriate for web-based applications.Spring's Web package provides basic web-oriented integration features, such as multipart file-upload functionality, the initialization of the IoC container using servlet listeners and a web-oriented application context. When using Spring together with WebWork or Struts, this is the package to integrate with.
Spring comes with a full-featured Model/View/Controller (MVC) framework for building web applications. Although Spring can easily be integrated with other MVC frameworks, such as Struts, Spring’s MVC framework uses IoC to provide for a clean separation of controller logic from business objects. It also allows you to declaratively bind request parameters to your business objects, What’s more, Spring’s MVC framework can take advantage of any of Spring’s other services, such as I18N messaging and validation.