<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 Framework is a Java platform that provides comprehensive
infrastructure support for developing Java applications. Spring handles the
infrastructure so you can focus on your application.<!--First text mention should be *Spring Framework* not just *Spring*. I revised next sentence because *plumbing* is idiomatic and --><!--*the domain problem* is an unclear reference. Isn't the point that Spring takes care of *under the covers* so you can focus on app? TR: OK.--></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>Spring enables you to build applications from “plain old Java objects”
(POJOs) and to apply enterprise services non-invasively to POJOs. This
capability applies to the Java SE programming model and to full and partial
Java EE.</para>
<para>Examples of Spring as a platform:</para>
<para>Examples of how you, as an application developer, can use the Spring
platform advantage:<!--In each of the examples, clarify what you mean by *the implementer* (identify it, or is it a person?). ALSO in each sentence replace--><!--*dealing with* APIs with what you mean: what does not have to be done in regard to APIs? IMPORTANT, because this discusses advantage--><!--of product. TR: REVISED, PLS REVIEW. I changed *implementer* to *application developer* and put it upfront rather than repeat it.--></para>
<itemizedlist>
<listitem>
<para>Make a Java method execute in a database transaction; without the
implementer dealing with transaction APIs</para>
<para>Make a Java method execute in a database transaction without
having to deal with transaction APIs.</para>
</listitem>
<listitem>
<para>Make a local Java method a remote-procedure; without the
implementer dealing with remoting APIs</para>
<para>Make a local Java method a remote procedure without having to deal
with remote APIs.</para>
</listitem>
<listitem>
<para>Make a local Java method a management operation; without the
implementer dealing with JMX APIs</para>
<para>Make a local Java method a management operation without having to
deal with JMX APIs.</para>
</listitem>
<listitem>
<para>Make a local Java method a message handler; without the
implementer dealing with JMS APIs</para>
<para>Make a local Java method a message handler without having to deal
with JMS APIs.</para>
</listitem>
</itemizedlist>
<sectionid="overview-dependency-injection">
<title>Dependency Injection</title>
<title>Dependency Injection and Inversion of Control</title>
<sidebarid="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
<para><quote><emphasis>The question is, what aspect of control are
[they] inverting?</emphasis></quote> Martin Fowler posed this question
about Inversion of Control on his site in 2004. Fowler suggested
renaming the principle to make it more self-explanatory and came up with
<firstterm>Builder</firstterm>, <firstterm>Decorator</firstterm>, and
<firstterm>Service Locator</firstterm> to compose the various classes and
object instances that make up an application. However, these patterns are
simply that: best practices given a name, with a description of what the
pattern does, where to apply it, the problems it addresses, and so forth.
Patterns are formalized best practices that <emphasis>you must implement
yourself</emphasis> in your application.</para>
<para>The Spring Framework IoC component addresses this concern by
providing a formalized means of composing disparate components into a
fully working application ready for use. <!--Preceding sentence sounds like a description of what patterns do (and Spring uses patterns). Distinguish from patterns.-->The
Spring Framework codifies formalized design patterns as first-class
objects that you can integrate into your own application(s). <!--Preceding sentence suggests that you already have the application and *then* you integrate design patterns into it. Again, I--><!--don't see a major distinction here from use of patterns (as described in earlier paragraph) and use of IoC component to build apps.
TR: This section doesn't read well and I think we should try to rewrite it.-->Numerous
organizations and institutions use the Spring Framework in this manner to
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>
implementation for web applications. Spring's MVC framework provides a
<emphasis>clean</emphasis> separation between domain model code and web
forms, and integrates with all the other features of the Spring
Framework.<!--MVC allows you to use *all other features*? (Or just all other features in Web layer?) How do you mean? Does this need elaboration?
It sounds important.--><!--TR: REVISED, PLS REVIEW.--></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>
implementation to be used in a portlet environment and mirrors the
functionality of Web-Servlet module.<!--mirrors it in what way?--><!--TR: REVISED, PLS REVIEW. The functionality is mirrored - one for Servlets and the other for Portlets--></para>
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>
method-interceptors and pointcuts to cleanly decouple code that
implements functionality that should be separated. Using source-level
metadata functionality, you can also incorporate behavioral information
into your code, in a manner similar to that of .NET attributes.</para>
<para>The separate <emphasis>Aspects</emphasis> module provides
integration with AspectJ.<!--Aspects module not shown in diagram, add it to that. Also, why is this line under AOP and Instrumentation if it's separate?
<para>There is also a separate <emphasis>Aspects</emphasis> module that
provides integration with AspectJ.</para>
TR: OK. Added to diagram.--></para>
<para>The <emphasis>Instrumentation</emphasis> module provides class
instrumentation support and classloader implementations to be used in
@ -260,21 +233,21 @@
@@ -260,21 +233,21 @@
<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>
<para>The <emphasis>Test</emphasis> module supports the testing of
Spring components with JUnit or TestNG. It provides consistent loading
of Spring ApplicationContexts and caching of those contexts. It also
provides mock objects that you can use to test your code in
isolation.</para>
</section>
</section>
<sectionid="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>The building blocks described previously make Spring a logical
choice in many scenarios, from applets to full-fledged enterprise
applications that use Spring's transaction management functionality and
Thomas Risberg
17 years ago
