Java Reference
In-Depth Information
The Spring Framework is currently available under the Apache 2.0 open source
license. It is a high-quality software product that can be used to build clean, flexible
enterprise-class software. This is proven by tests done using Structure101 from Headway
that the Spring Framework code has no package-level dependency cycles “despite its
reasonable size of about 70KLOC (estimated from bytecode) divided into 139 packages.”
This speaks volumes about the sound underlying architecture and design of the Spring
Framework. If you're interested in more information, refer to
http://www.
springframework.org/node/310
.
Why Is Spring So Important?
The Java EE platform was intended to solve the complexities associated with distributed
application development. The traditional Java EE platform achieved great success in
standardizing low-level middleware services through the various APIs such as EJB, JTA,
and JMS. This was possible because both commercial vendors and the open source
community came together, realizing the immense potential of the platform based on
standard Java. Because the primary focus was on standardizing system services, the fun-
damental problem of a simplified programming model was overlooked. Hence, in spite of
widespread adoption in the late 1990s and early 2000, developing multitier applications
on the Java EE platform still required strenuous effort.
The Java EE platform aimed to build applications based on a component model.
A
component
is a self-contained piece of code that ideally could be reused in multiple
applications. An order component can comprise an entity bean to handle the persistence
of order information and a session bean to carry out different workflows on order enti-
ties. Theoretically, this has immense potential for reuse. But reality is different, because
components developed in one project are seldom utilized again in another project. The
Java EE server-specific deployment descriptors also make it difficult to reuse these com-
ponents. The complexities in the Java EE programming model also leads to a lot of
unnecessary code being written, tested, and maintained by development teams. This
includes boilerplate code to look up an EJB object on the JNDI tree, retrieve a database
connection, prepare and execute database queries, and finally release all database
resources. The data transfer objects used to circumvent the limitations of the entity bean
API seriously violated the object-oriented principle of encapsulation. Even a midsize
project had a significant number of transfer objects to develop and maintain. All these
led to a significant drain of resources that should otherwise be used only for developing
sound business logic.
