Spring module summary, spring module Overview

Module
Summary

Let's now examine the functionality that spring offers in
More detail. It is divided into a number of separate modules.

There are two main categories of functionality in Spring:

• An IOC container and AOP framework, which handle
  Configuration and application of services to objects.

• A set of services that can be applied to Application
  Objects. These services can be used as a class library, even in a different
  Runtime container.

Each of the modules discussed here fits into one or both of these
Categories.

 

Spring is a layered framework with the following core modules:

• IOC container:The core of spring is the IOC container. This configures
  Objects by dependency injection, but also supports a variety of optional
  Callbacks for application objects that have more complex requirements of their
  Environment. 33

• Proxy-based AOP framework:Spring's AOP
  Framework is the other essential in delivering a non-invasive framework that can
  Manage pojos. Spring AOP can be used programmatically, or integrated with
  IOC container, in which case any object managed by a Spring IoC container can be
  "Advised" transparently.

• Data Access logging action:This
  Schemdes:

  • The Dao exception hierarchy and consistent invalid tural
    Approach discussed earlier in this chapter.

  • Template and other integration classes for hibernate, JDO,
    Toplink, ibatis, and other data access APIs.

  • spring's own JDBC prepare action framework. while in general
    spring's approach to persistence is consistent integration, spring does provide
    one persistence API of its own: Its JDBC framework. this is an internal action layer
    over JDBC that simplifies error handling, improves code portability, and
    eliminates the potential for each common errors when using JDBC, such as failure
    to close connections and other valuable resources in the event of errors.
    spring's JDBC connector action is suitable when you want SQL-based persistence, and
    not o/R Mapping: for example, when you have a legacy database that doesn't lend
    itself to o/R Mapping, or you need to make extensive use of stored procedures or
    blob types. spring's JDBC framework is also a good choice if the persistence
    needs are limited and you don't want to introduce the learning curve/maintenance
    cost of an additional persistence framework such as JDO or
    hibernate.

• Transaction upload action: Spring provides a transaction implements action that can run over
  A variety of underlying transaction APIs, including JTA, JDBC, hibernate, and
  JDO transactions. Naturally, JTA is the only option for working with multiple
  Transactional resources, as spring does not provide its own distributed
  Transaction Manager. However, applications work with a single database, and
  Do not require distributed transactions for any other reason (such as working
  With JMS). However, spring's transaction provided action provides a consistent
  Programming Model in any environment, from high-end J2EE application servers
  Down to simple web containers and standalone clients: A unique value proposition
  That does away with the traditional need to choose between "Global" and "local"
  Transaction Management and commit to one or another programming model early in
  Each J2EE project. Spring provides programmatic declarative management that is
  Much more usable than JTA, which is a fairly cumbersome API, not ideally suited
  For use by application developers. But most users prefer spring's sophisticated
  Declarative transaction management, which can provide transaction management
  Any pojo. Spring transaction management is integrated with all of spring's
  Supported data access integrations.

• Simplification for working with JNDI, EJB, and
  Other complex J2EE APIs and services: If you're a experienced J2EE
  Developer, you will have written outer JNDI lookups. You may have chosen to move
  The lookup code to a helper class, but you can't completely conceal
  Complexity, or hide the implications for testing. If you're 've worked with EJB,
  You 've needed to write code to look the EJB home up in JNDI before calling
  Create () Method to obtain an EJB reference you can use
  To do work. Chances are, you 've done essential the same thing, over and over,
  And worked on applications where your developers have done essential tially the same
  Thing over and over, but in varous different ways. These are routine tasks that
  Are much better done by a framework. Spring's support for JNDI and EJB can
  Eliminate the need to write boilerplate code for JNDI lookups and EJB access or
  Implementation. By eliminating JNDI and ejb api dependencies in Application
  Code, it also increases the potential for reuse. For example, you don't need
  Write code that depends on an EJB home interface or handles EJB exceptions; you
  Merely need to express a dependency on the relevant EJB's Business Methods Interface , Which is a plain Java interface.
  Spring can do the necessary JNDI lookup and create an AOP proxy for the EJB that
  Hides the need to work with the EJB APIs. Your code is no longer dependent on
  EJB-You cocould choose to implement the business methods interface without using
  EJB-and another bit of tedious boilerplate is gone.

• MVC Web framework:Spring's own
  Request-driven MVC framework. This is closely integrated with spring's
  Middle-tier functionality, with all controllers being configured by dependency
  Injection, providing the ability to access middle-tier functionality from
  Web Tier without any code. Spring MVC is similar in how it approaches Controller
  Lifecycle to struts, but provides some key benefits over struts, such:

  • better support for view technologies other than JSP, such as
    velocity and PDF generation libraries

  • interceptors, in addition to "actions" or "controllers"

  • ability to use domain objects to back forms, rather than
    special objects such as Struts actionform
    subclasses

  • interface-based design, making the framework highly
    customizable, and avoiding the need to subclass framework classes, which is a
    convenience rather than a necessity

• Integration with numerous third-party
  Products:This fits into spring's role as your tural glue. As the spring
  IOC container is extensible, it's also easy to "alias" additional services
  Spring IoC.Jndiobjectfactorybean, Which looks up
  Named object in JNDI, is a good example.

• Remoting:Spring Provides Lightweight
  Remoting support over a variety of protocols, including Web Services, RMI, RMI
  Over HTTP, IIOP, and Caucho's Hessian and burlap protocols. remoting is
  Available for pojos, in keeping with spring's emphasis on providing a rich
  Environment for pojos.

• simplification for working with ejbs: This
  consists of:

  • support for implementing ejbs: ejbs 2.1
    and earlier have no built-in configuration management. ejbs 3.0 looks set to
    offer a simplistic dependency Injection capability. in either case, there is a
    compelling value proposition in using a lightweight container behind an EJB
    facade. spring provides support for implementing ejbs that serve as a facade in
    front of pojos managed by a spring application context.

  • support for accessing ejbs, via the
    "codeless proxying" described earlier.

• Message publication using JMS:Spring's
  Callback template approach is ideally suited to minimizing the complexity
  Application code required to publish JMS messages.

• JMX support:Spring 1.2 provides
  Powerful JMX layer that can publish any spring-managed object to JMX, enabling
  Monitoring and management with standard tools.

When you use spring's AOP framework, a layer of dynamic
Capabilities is available over the Spring IoC container in spring 1.3:

• support for scripting languages, with full support both ways
  for dependency injection. this means that any application object can be written
  in any supported scripting language, depending on other objects written in Java,
  or vice-versa.

• support for objects
  backed by a database.