overview.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
"http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd">
<chapter id="overview">
  <title>Introduction to Spring Framework</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="overview-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="overview-modules">
    <title>Modules</title>

    <para>The Spring Framework contains a lot of features, which are
    well-organized in about 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. It
      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. The <classname>ApplicationContext</classname>
      interface is the focal point of the Context module that provides these
      features.</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>