367 lines
17 KiB
XML
367 lines
17 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
|
|
"http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd">
|
|
|
|
<chapter id="introduction">
|
|
<title>Introduction</title>
|
|
|
|
<para>Fundamentally, what is Spring? We think of it as a Platform for your
|
|
Java code. It provides comprehensive infrastructural support for developing
|
|
Java applications. Spring deals with the plumbing so you can focus on
|
|
solving the domain problem</para>
|
|
|
|
<para>Spring as a platform allows applications to be built from “plain old
|
|
Java objects” (POJOs). This is true for the Java SE programming model as
|
|
well as within a number of other environments including full and partial
|
|
Java EE. Spring allows enterprise services to be applied to POJOs in a
|
|
non-invasive way</para>
|
|
|
|
<para>Examples of Spring as a platform:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Make a Java method execute in a database transaction; without the
|
|
implementer dealing with transaction APIs</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Make a local Java method a remote-procedure; without the
|
|
implementer dealing with remoting APIs</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Make a local Java method a management operation; without the
|
|
implementer dealing with JMX APIs</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Make a local Java method a message handler; without the
|
|
implementer dealing with JMS APIs</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<section id="introduction-dependency-injection">
|
|
<title>Dependency Injection</title>
|
|
|
|
<sidebar id="background-ioc">
|
|
<title>Background</title>
|
|
|
|
<para>In early 2004, Martin Fowler asked the readers of his site: when
|
|
talking about Inversion of Control: <quote><emphasis>the question is,
|
|
what aspect of control are [they] inverting?</emphasis></quote>. Fowler
|
|
then suggested renaming the principle (or at least giving it a more
|
|
self-explanatory name), and started to use the term
|
|
<firstterm>Dependency Injection</firstterm>. His article then continued
|
|
to explain the ideas underpinning the Inversion of Control
|
|
(<acronym>IoC</acronym>) and Dependency Injection
|
|
(<acronym>DI</acronym>) principle.</para>
|
|
|
|
<para>If you need a decent insight into IoC and DI, please do refer to
|
|
said article: <ulink
|
|
url="http://martinfowler.com/articles/injection.html">http://martinfowler.com/articles/injection.html</ulink>.</para>
|
|
</sidebar>
|
|
|
|
<para>Java applications (a loose term which runs the gamut from
|
|
constrained applets to full-fledged n-tier server-side enterprise
|
|
applications) typically are composed of a number of objects that
|
|
collaborate with one another to form the application proper. The objects
|
|
in an application can thus be said to have
|
|
<emphasis>dependencies</emphasis> between themselves.</para>
|
|
|
|
<para>The Java language and platform provides a wealth of functionality
|
|
for architecting and building applications, ranging all the way from the
|
|
very basic building blocks of primitive types and classes (and the means
|
|
to define new classes), to rich full-featured application servers and web
|
|
frameworks. One area that is decidedly conspicuous by its absence is any
|
|
means of taking the basic building blocks and composing them into a
|
|
coherent whole; this area has typically been left to the purvey of the
|
|
architects and developers tasked with building an application (or
|
|
applications). Now to be fair, there are a number of design patterns
|
|
devoted to the business of composing the various classes and object
|
|
instances that makeup an all-singing, all-dancing application. Design
|
|
patterns such as <firstterm>Factory</firstterm>, <firstterm>Abstract
|
|
Factory</firstterm>, <firstterm>Builder</firstterm>,
|
|
<firstterm>Decorator</firstterm>, and <firstterm>Service
|
|
Locator</firstterm> (to name but a few) have widespread recognition and
|
|
acceptance within the software development industry (presumably that is
|
|
why these patterns have been formalized as patterns in the first place).
|
|
This is all very well, but these patterns are just that: best practices
|
|
given a name, typically together with a description of what the pattern
|
|
does, where the pattern is typically best applied, the problems that the
|
|
application of the pattern addresses, and so forth. Notice that the last
|
|
paragraph used the phrase <quote>... a <emphasis>description</emphasis> of
|
|
what the pattern does...</quote>; pattern books and wikis are typically
|
|
listings of such formalized best practice that you can certainly take
|
|
away, mull over, and then <emphasis>implement yourself</emphasis> in your
|
|
application.</para>
|
|
|
|
<para>The IoC component of the Spring Framework addresses the enterprise
|
|
concern of taking the classes, objects, and services that are to compose
|
|
an application, by providing a formalized means of composing these various
|
|
disparate components into a fully working application ready for use. The
|
|
Spring Framework takes best practices that have been proven over the years
|
|
in numerous applications and formalized as design patterns, and actually
|
|
codifies these patterns as first class objects that you as an architect
|
|
and developer can take away and integrate into your own application(s).
|
|
This is a <firstterm>Very Good Thing Indeed</firstterm> as attested to by
|
|
the numerous organizations and institutions that have used the Spring
|
|
Framework to engineer robust, <emphasis>maintainable</emphasis>
|
|
applications.</para>
|
|
</section>
|
|
|
|
<section id="introduction-modules">
|
|
<title>Modules</title>
|
|
|
|
<para>The Spring Framework contains a lot of features, which are
|
|
well-organized in ab out twenty modules. These modules can be grouped
|
|
together based on their primary features into Core Container, Data
|
|
Access/Integration, Web, AOP (Aspect Oriented Programming),
|
|
Instrumentation and Test. These groups are shown in the diagram
|
|
below.</para>
|
|
|
|
<para><mediaobject>
|
|
<imageobject role="fo">
|
|
<imagedata align="left" fileref="images/spring-overview.png"
|
|
format="PNG" />
|
|
</imageobject>
|
|
|
|
<imageobject role="html">
|
|
<imagedata align="center" fileref="images/spring-overview.png"
|
|
format="PNG" />
|
|
</imageobject>
|
|
|
|
<caption><para>Overview of the Spring Framework</para></caption>
|
|
</mediaobject></para>
|
|
|
|
<section>
|
|
<title>Core Container</title>
|
|
|
|
<para>The <link linkend="beans-introduction"><emphasis>Core
|
|
Container</emphasis></link> consists of the Core, Beans, Context and
|
|
Expression modules. </para>
|
|
|
|
<para>The <link linkend="beans-introduction"><emphasis>Core and
|
|
Beans</emphasis></link> modules provide the most fundamental parts of
|
|
the framework and provides the IoC and Dependency Injection features.
|
|
The basic concept here is the <classname>BeanFactory</classname>, which
|
|
provides a sophisticated implementation of the factory pattern which
|
|
removes the need for programmatic singletons and allows you to decouple
|
|
the configuration and specification of dependencies from your actual
|
|
program logic.</para>
|
|
|
|
<para>The <link
|
|
linkend="context-introduction"><emphasis>Context</emphasis></link>
|
|
module build on the solid base provided by the <link
|
|
linkend="beans-introduction"><emphasis>Core and Beans</emphasis></link>
|
|
modules: it provides a way to access objects in a framework-style manner
|
|
in a fashion somewhat reminiscent of a JNDI-registry. The Context module
|
|
inherits its features from the Beans module 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. The Context module also
|
|
contains support for some Java EE features like EJB, JMX and basic
|
|
remoting support.</para>
|
|
|
|
<para>The <emphasis>Expression Language</emphasis> module provides a
|
|
powerful expression language for querying and manipulating an object
|
|
graph at runtime. It can be seen as an extension of the unified
|
|
expression language (unified EL) as specified in the JSP 2.1
|
|
specification. The language supports setting and getting of property
|
|
values, property assignment, method invocation, accessing the context of
|
|
arrays, collections and indexers, logical and arithmetic operators,
|
|
named variables, and retrieval of objects by name from Spring's IoC
|
|
container. It also supports list projection and selection, as well as
|
|
common list aggregators.</para>
|
|
</section>
|
|
|
|
<section>
|
|
<title>Data Access/Integration</title>
|
|
|
|
<para>The <emphasis>Data Access/Integration</emphasis> layer consists of
|
|
the JDBC, ORM, OXM, JMS and Transaction modules.</para>
|
|
|
|
<para>The <link linkend="jdbc-introduction">JDBC</link> module provides
|
|
a JDBC-abstraction layer that removes the need to do tedious JDBC coding
|
|
and parsing of database-vendor specific error codes. </para>
|
|
|
|
<para>The <link
|
|
linkend="orm-introduction"><emphasis>ORM</emphasis></link> module
|
|
provides integration layers for popular object-relational mapping APIs,
|
|
including <link linkend="orm-jpa">JPA</link>, <link
|
|
linkend="orm-jdo">JDO</link>, <link
|
|
linkend="orm-hibernate">Hibernate</link>, and <link
|
|
linkend="orm-ibatis">iBatis</link>. Using the ORM package you can use
|
|
all those O/R-mappers in combination with all the other features Spring
|
|
offers, such as the simple declarative transaction management feature
|
|
mentioned previously.</para>
|
|
|
|
<para>The <link linkend="oxm">OXM</link> module provides an abstraction layer for using a number of
|
|
Object/XML mapping implementations. Supported technologies include JAXB,
|
|
Castor, XMLBeans, JiBX and XStream.</para>
|
|
|
|
<para>The <link linkend="jms">JMS</link> module provides Spring's support for the Java Messaging Service. It
|
|
contains features for both producing and consuming messages. </para>
|
|
|
|
<para>The <link linkend="transaction">Transaction</link> module provides a way to do programmatic as well
|
|
as declarative transaction management, not only for classes implementing
|
|
special interfaces, but for <emphasis>all your POJOs (plain old Java
|
|
objects)</emphasis>.</para>
|
|
</section>
|
|
|
|
<section>
|
|
<title>Web</title>
|
|
|
|
<para>The <emphasis>Web</emphasis> layer consists of the Web, Web-Servlet
|
|
and Web-Portlet modules.</para>
|
|
|
|
<para>Spring's <emphasis>Web</emphasis> module 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. It also contains the web
|
|
related parts of Spring's remoting support.</para>
|
|
|
|
<para>The <emphasis>Web-Servlet</emphasis> module provides Spring's
|
|
Model-View-Controller (<link
|
|
linkend="mvc-introduction"><emphasis>MVC</emphasis></link>)
|
|
implementation for web-applications. Spring's MVC framework is not just
|
|
any old implementation; it provides a <emphasis>clean</emphasis>
|
|
separation between domain model code and web forms, and allows you to
|
|
use all the other features of the Spring Framework.</para>
|
|
|
|
<para>The <emphasis>Web-Portlet</emphasis> module provides the MVC
|
|
implementation to be used in a portlet environment and mirrors what is
|
|
provided in the Web-Servlet module.</para>
|
|
</section>
|
|
|
|
<section>
|
|
<title>AOP and Instrumentation</title>
|
|
|
|
<para>Spring's <link
|
|
linkend="aop-introduction"><emphasis>AOP</emphasis></link> module
|
|
provides an <emphasis>AOP Alliance</emphasis>-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.</para>
|
|
|
|
<para>There is also a separate <emphasis>Aspects</emphasis> module that
|
|
provides integration with AspectJ.</para>
|
|
|
|
<para>The <emphasis>Instrumentation</emphasis> module provides class
|
|
instrumentation support and classloader implementations to be used in
|
|
certain application servers.</para>
|
|
</section>
|
|
|
|
<section>
|
|
<title>Test</title>
|
|
|
|
<para>The <emphasis>Test</emphasis> module contains the Test Framework
|
|
that supports testing Spring components using JUnit or TestNG. It
|
|
provides consistent loading of Spring ApplicationContexts and caching of
|
|
those contexts. It also contains a number of Mock objects that are usful
|
|
in many testing scenarios to test your code in isolation.</para>
|
|
</section>
|
|
</section>
|
|
|
|
<section id="overview-usagescenarios">
|
|
<title>Usage scenarios</title>
|
|
|
|
<para>With the building blocks described above you can use Spring in all
|
|
sorts of scenarios, from applets up to fully-fledged enterprise
|
|
applications using Spring's transaction management functionality and web
|
|
framework integration.</para>
|
|
|
|
<para><mediaobject>
|
|
<imageobject role="fo">
|
|
<imagedata align="center" fileref="images/overview-full.png" format="PNG" />
|
|
</imageobject>
|
|
|
|
<imageobject role="html">
|
|
<imagedata align="center" fileref="images/overview-full.png" format="PNG" />
|
|
</imageobject>
|
|
|
|
<caption><para>Typical full-fledged Spring web
|
|
application</para></caption>
|
|
</mediaobject></para>
|
|
|
|
<para>By using Spring's <link
|
|
linkend="transaction-declarative">declarative transaction management
|
|
features</link> the web application is fully transactional, just as it
|
|
would be when using container managed transactions as provided by
|
|
Enterprise JavaBeans. All your custom business logic can be implemented
|
|
using simple POJOs, managed by Spring's IoC container. Additional services
|
|
include support for sending email, and validation that is independent of
|
|
the web layer enabling you to choose where to execute validation rules.
|
|
Spring's ORM support is integrated with JPA, Hibernate, JDO and iBatis;
|
|
for example, when using Hibernate, you can continue to use your existing
|
|
mapping files and standard Hibernate
|
|
<interfacename>SessionFactory</interfacename> configuration. Form
|
|
controllers seamlessly integrate the web-layer with the domain model,
|
|
removing the need for <classname>ActionForms</classname> or other classes
|
|
that transform HTTP parameters to values for your domain model.</para>
|
|
|
|
<para><mediaobject>
|
|
<imageobject role="fo">
|
|
<imagedata align="center" fileref="images/overview-thirdparty-web.png"
|
|
format="PNG" />
|
|
</imageobject>
|
|
|
|
<imageobject role="html">
|
|
<imagedata align="center" fileref="images/overview-thirdparty-web.png"
|
|
format="PNG" />
|
|
</imageobject>
|
|
|
|
<caption><para>Spring middle-tier using a third-party web
|
|
framework</para></caption>
|
|
</mediaobject></para>
|
|
|
|
<para>Sometimes the current circumstances do not allow you to completely
|
|
switch to a different framework. The Spring Framework does
|
|
<emphasis>not</emphasis> force you to use everything within it; it is not
|
|
an <emphasis>all-or-nothing</emphasis> solution. Existing front-ends built
|
|
using WebWork, Struts, Tapestry, or other UI frameworks can be integrated
|
|
perfectly well with a Spring-based middle-tier, allowing you to use the
|
|
transaction features that Spring offers. The only thing you need to do is
|
|
wire up your business logic using an
|
|
<classname>ApplicationContext</classname> and integrate your web layer
|
|
using a <classname>WebApplicationContext</classname>.</para>
|
|
|
|
<para><mediaobject>
|
|
<imageobject role="fo">
|
|
<imagedata align="center" fileref="images/overview-remoting.png" format="PNG" />
|
|
</imageobject>
|
|
|
|
<imageobject role="html">
|
|
<imagedata align="center" fileref="images/overview-remoting.png" format="PNG" />
|
|
</imageobject>
|
|
|
|
<caption><para>Remoting usage scenario</para></caption>
|
|
</mediaobject></para>
|
|
|
|
<para>When you need to access existing code via web services, you can use
|
|
Spring's <literal>Hessian-</literal>, <literal>Burlap-</literal>,
|
|
<literal>Rmi-</literal> or <classname>JaxRpcProxyFactory</classname>
|
|
classes. Enabling remote access to existing applications suddenly is not
|
|
that hard anymore.</para>
|
|
|
|
<para><mediaobject>
|
|
<imageobject role="fo">
|
|
<imagedata align="center" fileref="images/overview-ejb.png" format="PNG" />
|
|
</imageobject>
|
|
|
|
<imageobject role="html">
|
|
<imagedata align="center" fileref="images/overview-ejb.png" format="PNG" />
|
|
</imageobject>
|
|
|
|
<caption><para>EJBs - Wrapping existing POJOs</para></caption>
|
|
</mediaobject></para>
|
|
|
|
<para>The Spring Framework also provides an <link linkend="ejb">access-
|
|
and abstraction- layer</link> for Enterprise JavaBeans, enabling you to
|
|
reuse your existing POJOs and wrap them in Stateless Session Beans, for
|
|
use in scalable, failsafe web applications that might need declarative
|
|
security.</para>
|
|
</section>
|
|
</chapter> |