Today Java and Java EE technologies are facing many
challenges at the low end. The Java
EE
platform is being targeted from many standpoints. The problem is not that Java
EE doesn't do some of the things that it should do, but that it does them in a
complicated way. One of the problems today, faced with EJB programming model is
that it ties your code to the runtime framework. The other issue, of course, is
the heavyweight runtime environment. Java EE applications often end up being
bulky in terms of the number of lines of code. Also, testing requires you to
deploy the components, which eventually take a lot of time. In response to this,
the lightweight container movement was initiated. Lightweight containers are the
frameworks that are aimed at simplifying development experience, minimizing cost
and cutting cycle time. Spring is one such popular framework that has caught up
with the developer community recently.
|
n this series of two articles, we'll first introduce the
Spring framework and it's enabling technologies. Next, we'll take you
through a Spring example based on DI (Dependency Injection) design pattern.
What is Spring?
Spring is an open source, POJO-based (Plain Old Java Object) application
framework, developed and lead by Rod Johnson of
Interface21. It is aimed at simplifying Java EE application development, testing
and promoting good programming practices, which radically improves productivity
and cuts cost. It's published under the Apache license. Spring is a layered
Java EE application framework that addresses many problems that are today faced
by the developers. Spring doesn't conflict with Java EE, it rather fosters
integration. It offers a lightweight alternative to EJB. For instance, Spring
can provide declarative transaction management without deploying heavyweight EJB
containers. Spring can prove to be an asset to developers who subscribe to the
opinion that EJB introduces complexities if used where it is not required, like
many projects don't require remote and distributed transaction functionality
but still heavily rely on EJBs.
Yet another framework
The best part about Spring is that it's not a rip-off of any
existing framework or project. Rather, Spring has embraced other open-source
projects such as Toplink, Hibernate and JDO. But, what Spring really does is
that it aims to make existing technologies easier to use and integrate. Spring
provides a plug-in of other such technologies. For instance, to simplify JDBC
coding, tools such as iBatis are available out of box. Spring runs in a very
wide variety of environments. It runs in Java 1.3 and above. It is highly
portable across application servers and is supported by all major J2EE vendors
such as IBM, Oracle and BEA.
Since Spring is heavily based on POJO-based programming
model, it reduces the complexities involved in the EJB architecture. Instead of
EJB, Spring suggests that we make use of ordinary JavaBeans to achieve the same
functionality as provided by EJBs. Moreover, Spring is designed to operate with
EJB if required. The beauty of Spring is that it offers the developer a choice
to either
implement business interfaces as POJOs or local EJBs without affecting the
calling code. One of the elegant features of the Spring framework is that POJOs
are loosely coupled. The framework wires application services to the POJOs by
injecting service objects to the POJOs at runtime. Thus, the POJOs themselves
are not
concerned about the 'wiring' and have little dependency upon the framework.
This in turn helps the developers to concentrate more on business logic and unit
test their POJOs independent of the framework.
Under the hood
The Spring framework combines technologies such as DI (Dependency Injection)
and AOP (Aspect Oriented Programming) that are driving the lightweight container
movement. Spring combines these technologies to provide an effective programming
experience based around POJOs.
Dependency Injection
Dependency Injection or DI is a specialization of IoC (Inversion of Control).
IoC is based on a simple
Hollywood
principle- 'Don't call me, I'll call you'. What this means is that
the framework calls your code rather than the other way around. That's the
difference between a class library and a framework. So, we write applications in
the form of POJOs and then use the DI
pattern to configure those POJOs and tell them about each other at runtime. With
DI, you can have high level of decoupling between your code and the container.
DI configuration requires no
container API. You can use existing code that has no knowledge of the container.
So, in a way you are minimizing framework lock-in, thus,
allowing the application code to evolve independently of the framework.
Moreover, it aids in unit testing and encourages the programming to interfaces
than classes. The container injects
dependencies into object instances using Java methods. This is popularly known
as 'push' configuration. The framework is responsible for instantiating the
object and pushing configuration into it, and the object doesn't know where
that configuration comes from.
Let's look at two popular forms of DI namely constructor
and setter injections. A setter injection is a configuration through JavaBeans
property. Just to give you a feel of how simple it is to code in Spring,
consider the following code snippets.
package
com.pcquest.springdemo;
public class NameBean{
private String name;
public NameBean(String name){
this.name=name;
}
public void setName(String name){
this.name=name;
}
public String getName(){
return this.name;
}
}
This code snippet defines an ordinary JavaBean-based on
standard naming conventions. Next, we'll invoke the setter and constructor
injections. The following code snippet first instantiates the bean and then
calls the setter injection.
Jaggi
The sub-element
sets the 'name' property. Below we have used the
element to set the property through a constructor injection.
The client uses a service wrapped in an interface but,can't see the implementation |
Aspect Oriented Programming
We use AOP (Aspect Oriented Programming) to provide
declarative services to the POJOs. For example, making POJOs transactional,
without it knowing about a transaction API. AOP is a paradigm for modularizing
crosscutting code. Code that
would otherwise be scattered in multiple places can be gathered in one place.
Conclusion
Spring is modular and has been divided logically into independent packages,
which can function independently. Spring seamlessly blends into the existing
framework users have without hindrances. So, no matter what kind of framework
you are using now, Spring will co-exist with it without causing nightmares.
Spring packages are optional and Spring does not make any of them mandatory. For
instance, you can use Struts for the Web tier and toplink O/R for the database
and meanwhile hook Spring to provide Web services support. Stay tuned for the
next article in this series, where we'll show you DI pattern and inject
dependency through Spring.
Note: Sun has recently made an update to the Java
platform names. Sun has dropped the embedded '2' from all the three Java
editions. So, J2EE would now be known as 'Java EE', and same applies to the
other two platforms. Secondly, Sun is
using single digit version
numbers. So, Java 5.0 would now be called Java SE 5. Therefore, in this article,
we have followed this latest naming convention.
Kunal Jaggi