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.