Java Reference
In-Depth Information
EJBs were designed to help ease the development of transactional and distributed
applications. Although even the smallest database-driven application requires transac-
tion, it may not need to be distributed. However, overusing EJBs, especially session beans
to simplify business logic, leads to the distribution being built into the application com-
ponent model. Distributed applications are unduly complex and hence consume more
CPU cycles for processing. They result in excessive and duplicated code along with meta-
data. Accessing a distributed application component requires network traversals, and
marshalling and unmarshalling of large datasets. The misuses of distributed objects have
often led to even a simple application not performing to its desired level.
Java EE encompasses a lot of technologies and APIs that are inherently complex. The
entity bean API, for example, required a significant learning curve and in turn provided
limited benefits for an application. Since Java EE components run inside the application
server containers, they are very difficult to unit test. This prevents test-driven develop-
ment (TDD).
The difficulties in Java EE application development forced the development commu-
nity to look for alternatives. Soon there was a rapid proliferation of frameworks built on
top of different Java EE APIs. The Apache Struts framework, for example, helps imple-
ment MVC principles using the servlet API. The framework implements a servlet-based
front controller and allows developers to provide implementation for simple page con-
trollers. Hibernate, on the other hand, emerged to answer the immense pain associated
with entity bean development. It provided persistence of POJOs with minimal configura-
tion metadata. These POJOs were not distributed objects like entity beans and hence led
to better application performance. Hibernate did not require any container support, thus
making it easy to unit test these persistence objects. Then there was HiveMind for devel-
oping simple POJO-based business services.
The Spring Framework also started to address the complexity associated with devel-
oping Java EE applications. However, unlike the single-tier frameworks such as Struts,
Hibernate, or HiveMind, Spring provides a comprehensive multitier framework that can
be leveraged in all tiers of an application. It helps structure together the entire applica-
tion with out-of-the-box components as well as integrates with the best single-tier
frameworks. Just like its single-tier counterparts, it provides a simple programming
model based on POJOs and makes them easily testable because these components can
run outside server containers.
The Spring Inversion of Control (IOC) container (to be discussed in the next section)
is the heart of the entire framework. It helps glue together the different parts of the appli-
cation, thus forming a coherent architecture. Spring MVC components can be used to
build a very flexible web tier. The IOC container simplifies the development of business
layer with POJOs.
