JavaOne: TS-7695: Spring Application Framework
Agile J2EE: where do we want to go?
- Need to produce high quality apps, faster and at lower cost
- cope with changing requirements (waterfall not an option)
- need to simplify programming model (reduce complexity rather than hide with tools)
- J2EE powerful, but complicated
Agile J2EE: Why important?
- Survival: challenges from .NET, and PHP/Ruby at low end
- Concerns that J2EE dev is slow and expensive
Why aren't we there yet?
- Difficult to test traditional J2EE app
- EJB's really tie code to runtime framework, hard to test w/o
- Simply too much code, much is glue code (I concur, based on my experience with a J2EE portal in EDS)
- Heavyweight runtime environment -- in order to test, need to deploy
Enter Lightweight Containers:
- frameworks central to modern J2EE development
- frameworks capture generic functionality, for solving common problems
- J2EE out of box doesn't provide a complete programming model
- Result is many in-house frameworks (expensive to maintain and develop, hard to share code)
Open Source Frameworks
- Responsible for much of the innovation in the last 2-3 years
- Several projects aim to simply development experience and remove excessive complexity from the developer's view
- Easy to tell which ones are popular; driven by collective developer experience (refined, powerful, best-of-breed)
- Tapping into "collective experience" of developers
How do Lightweight Containers work?
- Inversion of Control/Dependency Injection (sophisticated configuration of POJOs)
- Aspect Oriented Programming (AOP)
- provide declarative services to POJOs
- can get POJOs working with special features, JMX, etc.
What is Inversion of Control?
- hollywood principle - don't call me, I'll call you
- framework calls your code, not the reverse
What is Dependency Injection?
- specialization of Inversion of Control
- container injects dependencies into object instances using java methods
- a.k.a. push configuration -- object gets configuration, doesn't know where it came from
- decouples object from configuration from environment. Values get pushed in at runtime, so it is easy to run object in test or prod.
Why is Dependency Injection different?
- configuration requires no container API
- can use existing code that has no knowledge of container
- your code can evolve independently of container code
- easy to unit test (no JNDI stub, or properties files to monkey around with)
- code is self-documenting
Advanced Dependency Injection:
- shared instance, pooling
- lifecycle tied to container objects
- maps, sets, other complex types
- type conversion with property editors
- instantiation via factory methods
- FactoryBean adds level of indirection; configured by framework, and returns objects based upon that configuration.
What is AOP?
- paradigm for modularizing cross-cutting code (code that would otherwise be scattered across multiple places)
- think about interception
- callers invoke proxy, chain of interceptors decorate that call with additional functionality, callee finally invoked, and return passes back through chain
- idea for transaction management and security
- enabling technology, for defining own services, and applying them to POJOs.
Incremental AOP
- think of it as a generic way similar to how EJB implemented
- can be implemented with dynamic proxies
DI + AOP delivers POJO ideal
- configure objects w/o invasive API
Spring Framework
- OSS project, apache 2 license
- Aims:
- simplify J2EE development
- provide a comprehensive solution to developing applications built on POJOs.
- aims to address all sorts of applications, large banking, or small in-house
- easy to work with JDBC, Hibernated, transaction management, etc.
- consistency makes Spring more than sum of its parts.
- don't need to deploy, can all run from within IDE if desired.
Posted by andyr at June 28, 2005 01:01 PM