Spring Framework

1
Spring Framework

• Alex Kotchnev 
• Michael Dudley
• Patrick Joyce

2
Intro to J2EE

• What is J2EE
• Open and standard based platform for developing,
  deploying and managing n-tier, Web-enabled,
  server-centric, and component-based enterprise
  applications
• What makes up J2EE
• API and Technology specifications
• Development and Deployment Platform
• Standard and production-quality implementation
• Sun Java System App Server Platform Edition 8.1
  as part of J2EE 1.4 SDK
• Compatibility Test Suite (CTS)
• J2EE brand
• J2EE Blueprints
• Sample codes

3
Intro to J2EE

• What is EJB Technology?
• Enterprise Java Beans
• component architecture for the development and
  deployment of object-oriented, distributed,
  enterprise-level applications
• Cornerstone of J2EE
• A server-side component technology
• Easy development and deployment Java
  technology-based application that are
• Transactional, distributed, multi-tier, portable,
  scalable, secure,

4
Intro to J2EE

• Why EJB Technology?
• Leverages the benefits of component-model on the
  server side
• Separates business logic from system code
• Container provides system services
• Provides framework for portable components
• Over different J2EE-compliant servers
• Over different operational environments
• Enables deployment-time configuration
• Deployment descriptor

5
Intro to J2EE

• Limitations of EJB
• Code written to the EJB model doesnt run without
  the EJB container
• Container is the term the authors used for
  application framework
• EJB containers are relatively slow to start up.
• EJB deployment is fairly onerous, involving
  multiple Java source files per EJB and possibly a
  predeployment code-generation and compilation
  step
• Code is written to run in a single environment.
• EJBs are not suited to use as fine-grained
  objects.

6
Intro to J2EE

• Whats left of J2EE without EJB?
• J2EE is more than just EJB
• EJB is only a part of the big picture
• J2EE is essentially about
• standardizing a range of enterprise services
• transaction management offering a standard API
  potentially
• connection to legacy systems
• resource pooling
• thread management
• EJB is merely one way of leveraging those
  valuable services through a particular component
  model.

7
Intro to J2EE

• Why do we need a container?
• Plug ability. A container allows plug ability of
  different components
• Different EJB implementation classes may be used
  for the same component interface, isolating
  calling code from the implementation strategy.
• While Java interfaces provide perfect separation,
  there has to be some way of looking up what
  implementation of an interface we want to use
• If its hard-coded in Java code, much of the
  advantage of using interfaces is lost.

8
Intro to J2EE

• Why do we need a container?
• Consistency. Without a container infrastructure,
  service lookup will be haphazard.
• Different service objects may be located
  differently, depending on developer preference.
• Configuration management will be equally
  haphazard, posing an ongoing maintenance
  challenge.
• One stop shop. Its necessary only to find the
  container to find all its services. There is no
  need for a dedicated Singleton or factory for
  every object.
• Delivery of enterprise services. A consistent
  approach makes it easier to deliver enterprise
  services as part of the container model or as an
  add-on.

9
Intro to J2EE

• Eliminating EJB
• In order manage business object we must use a
  container
• Not using a container leads to code chaos
• EJB is one of the containers that you can use to
  manage the chaos
• In order to eliminate EJB we must find another
  container to provide structure
• Lightweight containers
• Provide order without the complexity of EJB

10
What is a Lightweight Container?

• A container that can manage application code, but
  imposes no special dependencies on that code.
• A container that is quick to start up.
• A container that doesnt require any special
  deployment steps to deploy objects within it.
• A container that has such a light footprint and
  minimal API dependencies that it can be run in a
  variety of environments
• A lightweight container should be pure Java, not
  J2EE-only
• A container with the ability to add managed
  objects easily with low deployment effort and
  performance overhead

11
Benefits of Lightweight Container

• Escaping the monolithic container.
• EJB containers are heavyweight beasts.
• Theyre an all-or-nothing approach to an
  enterprise component model.
• Maximizing code reusability.
• As stated, code written to the EJB API is only
  ever going to run in an EJB container. It can be
  unwise to make assumptions about where code will
  always run.
• Greater object orientation.
• EJBs are often not true objects
• they are constrained by the characteristics of
  the EJB component model.

12
Benefits of Lightweight Container

• The EJB component model doesnt support
  inheritance
• although EJB implementation classes can
  participate in inheritance hierarchies.
• Greater productivity.
• With a lightweight container, application code
  can be closer to plain Java.
• It will have less dependence on heavyweight APIs
  and will be much easier to write and manipulate
  in any Java IDE.
• Better testability.
• Testability will also be greatly improved,
  because of the ability to test objects outside
  any container for example, in plain JUnit test
  cases.

13
Managing Business Objects

• Satisfy dependencies without introducing a
  dependency on a container can be achieved in most
  cases by
• Inversion of Control (IoC)
• Dependency Injection

14
Inversion of Control

• IoC is a broad concept that can be implemented in
  different ways. There are two main types
• Dependency Lookup
• The container provides callbacks to components,
  and a lookup context. The Inversion of Control
  is limited to the container invoking callback
  methods that application code can use to obtain
  resources.
• Dependency Injection
• Components do no look up they provide plain Java
  methods enabling the container to resolve
  dependencies.
• The container is wholly responsible for wiring up
  components
• passing resolved objects in to JavaBean
  properties or constructors
• Use of JavaBean properties is called Setter
  Injection
• Use of constructor arguments is called
  Constructor Injection.

15
Inversion of Control
Different Types of IoC
16
Dependency Lookup

• Dependency Lookup
• The container manages object lifecycle, while
  managed objects are responsible for doing their
  own lookups.
• Following Problems Occur
• The class wont run outside application server
  environment
• Class is hard to test
• Too much code
• Strongly typed

17
Dependency Injection

• Dependency Injection
• Make the container wholly responsible for
  dependency lookup
• have the managed object expose JavaBean setter
  methods or constructor arguments to enable
  dependencies to be passed into it when the
  container is initialized.
• The container is responsible for looking up the
  resources, and will provide the necessary
  resources to the business object.
• The container can be reconfigured to use a
  different approach to obtaining the necessary
  resources without affecting application

18
Dependency Injection Advantages

• Lookup is completely removed from application
  code.
• Theres no dependence on a container API
• In fact, its not even Java-specific its a true
  pattern, which is also growing in popularity in
  .NET.
• Therefore, its easy to use application objects
  outside any container.
• No special interfaces are required
• Minimizes the dependency of application code on
  the lightweight container

19
Dependency Injection

• Settler Injection
• Components express dependencies on configuration
  values and collaborators via JavaBean properties.
• This concept is not Java-specific.
• Other languages support similar conventions to
  JavaBeans, such as C properties.
• Constructor Injection
• With Constructor Injection, components express
  dependencies via constructor arguments.
• This approach to Dependency Injection was
  invented by the PicoContainer team in mid 2003
• Has since been implemented in Spring and other
  containers

20
Setter Injection Advantages

• JavaBean properties are well supported in IDEs.
• JavaBean properties are self-documenting.
• JavaBean properties are inherited by subclasses
  without the need for any code.
• Its possible to use the standard JavaBeans
  property-editor machinery for type conversions if
  necessary.

21
Setter Injection Advantages

• Many existing JavaBeans can be used within a
  JavaBean-oriented IoC container without
  modification.
• If there is a corresponding getter for each
  setter (making the property readable, as well as
  writable), it is possible to ask the component
  for its current configuration state.
• Setter Injection works well for objects that have
  default values, meaning that not all properties
  need to be supplied at runtime.

22
Setter Injection Disadvantages

• The order in which setters are called is not
  expressed in any contract.
• Sometimes need to invoke a method after the last
  setter has been called to initialize the
  component.
• Spring provides the org.springframework.beans.fact
  ory.InitializingBean interface for this
• Not all the necessary setters may have been
  called before use. The object can thus be left
  partially configured.

23
Constructor Injection Advantages

• Each managed object is guaranteed to be in a
  consistent statefully configuredbefore it can
  be invoked in any business methods.
• This is the primary motivation of Constructor
  Injection.
• However, it is possible to achieve the same
  result with JavaBeans via dependency checking, as
  Spring can optionally perform.) Theres no need
  for initialization methods.
• There may be slightly less code than results from
  the use of multiple JavaBean methods, although
  will be no difference in complexity.

24
Constructor Injection Disadvantages

• Multi-argument constructors are probably less
  common in existing code than use of JavaBean
  properties.
• Thus, a container that offered only Constructor
  Injection would be unable to run much valuable
  legacy code, such as the Commons DBCP connection
  pool.
• Java constructor arguments dont have names
  visible by introspection.
• This leaves us dependent on argument index
• Constructor argument lists are less well
  supported by IDEs than JavaBean setter methods.

25
Constructor Injection Disadvantages

• Long constructor argument lists and large
  constructor bodies can become unwieldy
• the downside of concentrating configuration in
  one method
• Concrete inheritance can become problematic, as
  constructors are not automatically inherited.
• Defining constructors that invoke the wrong
  superclass constructor is a common source of
  coding errors.
• Poor support for optional properties, compared to
  JavaBeans, which can have default values
• In the absence of C-style default argument
  lists, optional properties can be given default
  values only through multiple constructors, with
  constructors with fewer arguments invoking a
  constructor with the full argument list providing
  default values.

26
Constructor Injection Disadvantages

• Unit testing can be slightly more difficult
• All constructor arguments need to be provided
• Even those collaborators irrelevant to the
  particular test case.
• When collaborators are passed in on object
  construction, it becomes impossible to change the
  reference held in the object.
• A JavaBeans approach can potentially support
  dynamic configuration, if a managed object is
  capable of accepting it
• A constructor-based approach cant without
  changing the identity of the managed object.

27
The Spring Framework

• The Spring Framework offers sophisticated support
  for
• Setter Dependency Injection
• Constructor Dependency Injection.
• Just about any Java object can be used in a
  Spring container.
• The class must be configurable via JavaBean
  properties or constructor arguments if it is to
  benefit from the full power of IoC. (Some classes
  may require no properties.)

28
Introduction to Spring

• History
• Open source project since February 2003
• Code was designed for use in real applications
• Expert One-on-One J2EE laid out the basic
  architectural thinking behind Spring

29
Motivations to Develop Spring

• To address areas not well served by other
  frameworks
• Solutions to
• Web frameworks
• Persistence solutions
• Remoting Tools
• To allow easy adoption
• Allows clean layers
• JDBC abstraction layer

30
Motivation to develop Spring

• To deliver ease of use
• To make it easier to apply best practices
• Spring aims to cost of adhering to best practices
• Non-invasive
• Application objects have a minimal dependence on
  framework

31
Motivation to develop Spring

• Consistent configuration
• Keeps application configuration flexible and
  consistent
• Ease of testing
• To allow for extensibility
• Spring relies on interfaces rather than classes
  and is easy to extend or customize

32
Spring Framework

• Mission Statement
• J2EE should be easier to use
• It's best to program to interfaces, rather than
  classes. Spring reduces the complexity cost of
  using interfaces to zero.
• JavaBeans offer a great way of configuring
  applications.
• OO design is more important than any
  implementation technology, such as J2EE.
• Checked exceptions are overused in Java. A
  framework shouldn't force you to catch exceptions
  you're unlikely to be able to recover from.
• Testability is essential, and a framework such as
  Spring should help make your code easier to test.
  
• from www.springframework.org

33
Spring Building Blocks

• Bean Factory
• Capable of configuring and wiring up Java-Beans
• Application context
• Support for message sources and resource loading
• AOP framework
• AOP support for method interception on any class
  managed by a Spring lieghtweight container

34
Spring Building Blocks

• Auto-proxying
• Higher level of abstraction over AOP framework
  and low level services
• Transaction Management
• Provides a generic transaction management
  infrastructure
• DAO abstraction
• Spring defines a set of generic data access
  exceptions that can be used for creating generic
  DAO interfaces that throw meaningful exceptions
  independent of the underlying persistence
  mechanism

35
Spring Building Blocks

• JDBC support
• Spring offers two levels of JDBC abstraction that
  significantly ease the effort of writing
  JDBC-based DAOs
• the org.springframework.jdbc.core package (a
  template/callback approach)
• the org.springframework.jdbc.object package
  (modeling RDBMS operations as reusable objects).
• Integration with O/R mapping tools
• Spring provides support classes for O/R Mapping
  tools like Hibernate, JDO, and iBATIS Database
  Layer to simplify resource setup, acquisition,
  and release, and to integrate with the overall
  transaction and DAO abstractions.

36
Spring Building Blocks

• Web MVC framework
• Spring provides a clean implementation of web
  MVC, consistent with the JavaBean configuration
  approach.
• Remoting support
• Spring provides a thin abstraction layer for
  accessing remote services without hard-coded
  lookups, and for exposing Spring-managed
  application beans as remote services.

37
Getting Started

• 1. Create regular Java classes
• 2. Create Spring Context to wire them up
  (applicationContext.xml)
• 3. Retrieve configured classes from context
  (Main.java)

38
DAO Getting Started

• 1. Create regular Java classes (value objects
  e.g. Fruit.java)
• 2. Create hibernate mapping file (e.g.
  Fruit.hbm.xml)
• 3. Create DAO Interface and Implementation
  (FruitDAO and FruitDAOImpl). Use Spring
  templates.

39
DAO Getting Started (cont.)

• 4. Create Spring Context (applicationContext-hiber
  nate.xml)
• - create data source (jdbc.properties,
  propertyConfigurer bean, dataSource bean)
• - set up Hibernate Session (sessionFactory bean,
  Fruit.hbm.xml)
• - set up transaction handling (transactionManager
  bean, fruitTarget bean, fruitMgr)
• 5. Use configured beans (DbAccessMain.java)

40
Questions ???
41
Resources

• ttp//www.javapassion.com/j2ee/J2EEOverview4.pdf
  Introduction to J2EE.
• Rod Johnson with Juergen Hoeller. Expert
  One-on-One J2EE Development without EJB.
  Indianapolic, IN Wiley Publishing, Inc. 2004
• ttp//www.springframework.org/articles Spring
  Framework.