The Spring Framework J2EE without EJB Jürgen Höller http://www.springframework.com [email_address]
Agenda J2EE Reviewed Introducing the Spring Framework Spring and J2EE Core Container AOP Framework Transactions & Data Access Remoting Further Services
J2EE Reviewed (1) Challenges of modern server-side software development multi-threaded execution resource and transaction management remote service access HTTP server integration Java 2 Enterprise Edition (J2EE  tm ) set of specifications for standard application server infrastructure industry standard: backed by Sun, IBM, Oracle application server implements standard APIs application uses standard APIs
J2EE Reviewed (2) J2EE specifies system services Servlets, JSP, JTA, JDBC, JMS, JavaMail builds on underlying standard Java runtime J2EE also specifies component models Servlets for HTTP endpoints EJBs for middle tier components Focus on traditional 3-tier server layout focus on physical separation between tiers middle tier always requires application server Low-level APIs direct usage in applications often cumbersome comfortable high-level APIs?
J2EE Reviewed (3) Scope of J2EE is limited EJBs are coarse-grained components mainly for (remote) service façades special deployment effort for every component How to deal with fine-grained, co-located application objects? forced to use custom solutions common: open source libraries / frameworks How to run outside of an application server? not covered by traditional J2EE important for unit tests and integration tests also important for productive development
Spring Framework (1) Java / J2EE Application Framework based on Rod Johnson’s book “J2EE Design & Development” (Wiley, 2002) current book: "J2EE Development without EJB" (Rod Johnson, Jürgen Höller; Wiley, 2004) Focus on "Plain Old Java Objects" (POJOs) natural, generic component model for applications flexible alternative to EJB, not tied to J2EE Open Source Project on SourceForge Apache license since February 2003 25 developers
Spring Framework (2) Business objects as decoupled POJOs configuration and wiring through framework or usage as normal Java objects independent from the actual environment no unnecessary ties to a framework reusable in any kind of environment in particular: testability in unit / integration tests Generic middleware services e.g. declarative transactions for POJOs flexible alternative to EJB CMT for all applications, including standalone leverage J2EE container services when available
Spring Framework (3) Integration with existing solutions Object/Relational Mapping tools web frameworks remoting protocols "It‘s all about choice" JDBC, Hibernate, JDO, Oracle TopLink, Apache OJB, iBATIS SQL Maps Spring Web MVC, Spring Web Flow, Struts, WebWork, Tapestry, JSF HTTP invoker, RMI invoker, conventional RMI, JAX-RPC (WSDL/SOAP), Hessian, Burlap
Spring and J2EE (1) J2EE provides standard system services to be leveraged by higher-level components Spring abstractions can run on top of J2EE J2EE system services J2EE deployment and management Spring application container Spring service abstractions Application components
Spring and J2EE (2) Spring is a de-facto standard Java / J2EE application framework typically running on top of J2EE server but: application components are not tied to J2EE Most popular "lightweight container" widespread adoption over the past 2.5 years endorsed / supported by BEA, IBM, Oracle e.g.: support partnership for Spring on WebLogic EJB3 specification will follow Spring model adopts some important ideas from Spring
Spring and J2EE (3) Constantly increasing download numbers ~30.000 downloads of every point release >400.000 downloads overall Growing Spring ecosystem Spring sister projects Acegi Security, Spring Web Flow used or supported by many other products open source and commercial e.g. Atlassian Confluence, Liferay Portal 5 dedicated books on Spring already available by various authors more books in the works
Core Container (1) "Inversion of Control" configuration and lifecycle of application objects objects do not configure themselves, but get  configured from the outside objects don't know the origin of their configuration "Dependency Injection" "setter-based" (JavaBean properties) "constructor-based" (constructor arguments) alternative: "Service Lookup" for example: JNDI
Core Container (2) Fine-grained externalized configuration representing the internal structure of the application references to other components configuration parameters enables flexible configuration management at fine-grained component level switching between different deployment scenarios XML bean definitions most common configuration format often: separate admin properties file linked into XML bean definitions through placeholders
Core Container (3) <bean id=&quot; dataSource &quot; class=&quot;org.apache.commons.dbcp.BasicDataSource&quot;> <property name=&quot;driverClassName&quot; value=&quot;${jdbc.driver}&quot;/>   <property name=&quot;url&quot; value=&quot;${jdbc.url}&quot;/>   <property name=&quot;username&quot; value=&quot;${jdbc.username}&quot;/>   <property name=&quot;password&quot; value=&quot;${jdbc.password}&quot;/> </bean> <bean id=&quot; itemDao &quot;  class=&quot;org.springframework.samples.jpetstore.dao.ibatis.SqlMapItemDao&quot;> <property name=&quot;dataSource&quot; ref=&quot; dataSource &quot;/>   <property name=&quot;sqlMap&quot; ref=&quot; sqlMap &quot;/> </bean> <bean id=&quot; petStore &quot; class=&quot;org.springframework.samples.jpetstore.domain.logic.PetStoreImpl&quot;> <property name=&quot;orderDao&quot; ref=&quot; orderDao &quot;/>   <property name=&quot;itemDao&quot; ref=&quot; itemDao &quot;/> </bean>
AOP Framework (1) &quot;Aspect-Oriented Programming&quot; proxies for arbitrary POJOs flexible combination of interceptors no  fixed component model (&quot;EJB a la carte&quot;) &quot;Cross-Cutting Concerns&quot; actions at the beginning/end of a method call Target method Caller intercept
AOP Framework (2) Do not repeat code: factor out interceptor e.g. logging: configurable trace log e.g. security: authorization checks e.g. common exception handling e.g. transaction demarcation Method interceptor interceptor can be applied to any methods interceptor can be enabled/disabled AOP Alliance: MethodInterceptor interface reuse of pre-built interceptors
Transactions & DAOs (1) Transaction Strategy Abstraction PlatformTransactionManager SPI switching between JTA and native transactions Transaction Demarcation Options programmatic demarcation a la JTA declarative demarcation for arbitrary POJOs Transaction Definitions all EJB CMT propagation codes supported REQUIRED, REQUIRES_NEW, etc optional transaction semantics beyond EJB nested, isolation level, timeout, read-only flag
Transactions & DAOs (2) DataAccessException hierarchy independent of JDBC, Hibernate, JDO, etc unchecked, as most failures are not recoverable subclasses like OptimisticLockingFailureException Support for DAO implementations implicit access to resources many operations become one-liners no try/catch blocks anymore Pre-built integration classes for many solutions JDBC:  JdbcTemplate Hibernate:  HibernateTemplate
Transactions & DAOs (3) Example for a JDBC-based DAO public class ExampleJdbcDao extends  JdbcDaoSupport  {   public void clearDatabase() throws DataAccessException {      getJdbcTemplate() .update(&quot;DELETE FROM imagedb&quot;);   }   public void deleteImage(int imageId) throws DataAccessException {      getJdbcTemplate() .update(&quot;DELETE FROM imagedb WHERE id=?&quot;,   new Object[] {new Integer(imageId)});   }   public int getNrOfImages() throws DataAccessException {     return  getJdbcTemplate() .queryForInt(   &quot;SELECT COUNT(*) FROM imagedb&quot;);   } }
Remoting Export POJOs as remote services in server-side Spring applications through Spring remote service exporter Make remote services accessible in client-side Spring applications through Spring remote proxy factory Protocol choice is configuration matter Hessian, Burlap, SOAP, RMI, HTTP invoker protocol to be chosen according to requirements Support for integration of EJBs through Spring EJB proxy factory declarative proxies for Stateless Session Beans
Further Services JMS Support lightweight messaging JCA Support access to J2EE Connectors Mail Support JavaMailSender Scheduling Support Quartz, Timer Web Application Support Struts, JSF, WebWork, Tapestry Spring Web MVC, Spring Web Flow
Summary (1) Spring is a popular Java application framework core container, AOP framework transactions, data access, remoting dedicated support for J2EE environments integrating with many existing solutions Solves ubiquitous architectural issues wiring and configuration of components flexible configuration of interceptors declarative transaction demarcation implicit management of resources
Summary (2) Works in any environment no special compilation or deployment steps no special class loader can run on J2EE, but not tied to J2EE seamless switching between deployment scenarios For any kind of application J2EE web applications running on e.g. Tomcat full J2EE applications running on e.g. WebLogic rich clients (usually with J2EE server as backend) standalone applications (with GUI or headless)
http://www.springframework.org   http://www.springframework.com

Tu1 1 5l

  • 1.
    The Spring FrameworkJ2EE without EJB Jürgen Höller http://www.springframework.com [email_address]
  • 2.
    Agenda J2EE ReviewedIntroducing the Spring Framework Spring and J2EE Core Container AOP Framework Transactions & Data Access Remoting Further Services
  • 3.
    J2EE Reviewed (1)Challenges of modern server-side software development multi-threaded execution resource and transaction management remote service access HTTP server integration Java 2 Enterprise Edition (J2EE tm ) set of specifications for standard application server infrastructure industry standard: backed by Sun, IBM, Oracle application server implements standard APIs application uses standard APIs
  • 4.
    J2EE Reviewed (2)J2EE specifies system services Servlets, JSP, JTA, JDBC, JMS, JavaMail builds on underlying standard Java runtime J2EE also specifies component models Servlets for HTTP endpoints EJBs for middle tier components Focus on traditional 3-tier server layout focus on physical separation between tiers middle tier always requires application server Low-level APIs direct usage in applications often cumbersome comfortable high-level APIs?
  • 5.
    J2EE Reviewed (3)Scope of J2EE is limited EJBs are coarse-grained components mainly for (remote) service façades special deployment effort for every component How to deal with fine-grained, co-located application objects? forced to use custom solutions common: open source libraries / frameworks How to run outside of an application server? not covered by traditional J2EE important for unit tests and integration tests also important for productive development
  • 6.
    Spring Framework (1)Java / J2EE Application Framework based on Rod Johnson’s book “J2EE Design & Development” (Wiley, 2002) current book: &quot;J2EE Development without EJB&quot; (Rod Johnson, Jürgen Höller; Wiley, 2004) Focus on &quot;Plain Old Java Objects&quot; (POJOs) natural, generic component model for applications flexible alternative to EJB, not tied to J2EE Open Source Project on SourceForge Apache license since February 2003 25 developers
  • 7.
    Spring Framework (2)Business objects as decoupled POJOs configuration and wiring through framework or usage as normal Java objects independent from the actual environment no unnecessary ties to a framework reusable in any kind of environment in particular: testability in unit / integration tests Generic middleware services e.g. declarative transactions for POJOs flexible alternative to EJB CMT for all applications, including standalone leverage J2EE container services when available
  • 8.
    Spring Framework (3)Integration with existing solutions Object/Relational Mapping tools web frameworks remoting protocols &quot;It‘s all about choice&quot; JDBC, Hibernate, JDO, Oracle TopLink, Apache OJB, iBATIS SQL Maps Spring Web MVC, Spring Web Flow, Struts, WebWork, Tapestry, JSF HTTP invoker, RMI invoker, conventional RMI, JAX-RPC (WSDL/SOAP), Hessian, Burlap
  • 9.
    Spring and J2EE(1) J2EE provides standard system services to be leveraged by higher-level components Spring abstractions can run on top of J2EE J2EE system services J2EE deployment and management Spring application container Spring service abstractions Application components
  • 10.
    Spring and J2EE(2) Spring is a de-facto standard Java / J2EE application framework typically running on top of J2EE server but: application components are not tied to J2EE Most popular &quot;lightweight container&quot; widespread adoption over the past 2.5 years endorsed / supported by BEA, IBM, Oracle e.g.: support partnership for Spring on WebLogic EJB3 specification will follow Spring model adopts some important ideas from Spring
  • 11.
    Spring and J2EE(3) Constantly increasing download numbers ~30.000 downloads of every point release >400.000 downloads overall Growing Spring ecosystem Spring sister projects Acegi Security, Spring Web Flow used or supported by many other products open source and commercial e.g. Atlassian Confluence, Liferay Portal 5 dedicated books on Spring already available by various authors more books in the works
  • 12.
    Core Container (1)&quot;Inversion of Control&quot; configuration and lifecycle of application objects objects do not configure themselves, but get configured from the outside objects don't know the origin of their configuration &quot;Dependency Injection&quot; &quot;setter-based&quot; (JavaBean properties) &quot;constructor-based&quot; (constructor arguments) alternative: &quot;Service Lookup&quot; for example: JNDI
  • 13.
    Core Container (2)Fine-grained externalized configuration representing the internal structure of the application references to other components configuration parameters enables flexible configuration management at fine-grained component level switching between different deployment scenarios XML bean definitions most common configuration format often: separate admin properties file linked into XML bean definitions through placeholders
  • 14.
    Core Container (3)<bean id=&quot; dataSource &quot; class=&quot;org.apache.commons.dbcp.BasicDataSource&quot;> <property name=&quot;driverClassName&quot; value=&quot;${jdbc.driver}&quot;/> <property name=&quot;url&quot; value=&quot;${jdbc.url}&quot;/> <property name=&quot;username&quot; value=&quot;${jdbc.username}&quot;/> <property name=&quot;password&quot; value=&quot;${jdbc.password}&quot;/> </bean> <bean id=&quot; itemDao &quot; class=&quot;org.springframework.samples.jpetstore.dao.ibatis.SqlMapItemDao&quot;> <property name=&quot;dataSource&quot; ref=&quot; dataSource &quot;/> <property name=&quot;sqlMap&quot; ref=&quot; sqlMap &quot;/> </bean> <bean id=&quot; petStore &quot; class=&quot;org.springframework.samples.jpetstore.domain.logic.PetStoreImpl&quot;> <property name=&quot;orderDao&quot; ref=&quot; orderDao &quot;/> <property name=&quot;itemDao&quot; ref=&quot; itemDao &quot;/> </bean>
  • 15.
    AOP Framework (1)&quot;Aspect-Oriented Programming&quot; proxies for arbitrary POJOs flexible combination of interceptors no fixed component model (&quot;EJB a la carte&quot;) &quot;Cross-Cutting Concerns&quot; actions at the beginning/end of a method call Target method Caller intercept
  • 16.
    AOP Framework (2)Do not repeat code: factor out interceptor e.g. logging: configurable trace log e.g. security: authorization checks e.g. common exception handling e.g. transaction demarcation Method interceptor interceptor can be applied to any methods interceptor can be enabled/disabled AOP Alliance: MethodInterceptor interface reuse of pre-built interceptors
  • 17.
    Transactions & DAOs(1) Transaction Strategy Abstraction PlatformTransactionManager SPI switching between JTA and native transactions Transaction Demarcation Options programmatic demarcation a la JTA declarative demarcation for arbitrary POJOs Transaction Definitions all EJB CMT propagation codes supported REQUIRED, REQUIRES_NEW, etc optional transaction semantics beyond EJB nested, isolation level, timeout, read-only flag
  • 18.
    Transactions & DAOs(2) DataAccessException hierarchy independent of JDBC, Hibernate, JDO, etc unchecked, as most failures are not recoverable subclasses like OptimisticLockingFailureException Support for DAO implementations implicit access to resources many operations become one-liners no try/catch blocks anymore Pre-built integration classes for many solutions JDBC: JdbcTemplate Hibernate: HibernateTemplate
  • 19.
    Transactions & DAOs(3) Example for a JDBC-based DAO public class ExampleJdbcDao extends JdbcDaoSupport { public void clearDatabase() throws DataAccessException {      getJdbcTemplate() .update(&quot;DELETE FROM imagedb&quot;);   }   public void deleteImage(int imageId) throws DataAccessException {      getJdbcTemplate() .update(&quot;DELETE FROM imagedb WHERE id=?&quot;, new Object[] {new Integer(imageId)});   }   public int getNrOfImages() throws DataAccessException {     return  getJdbcTemplate() .queryForInt( &quot;SELECT COUNT(*) FROM imagedb&quot;);   } }
  • 20.
    Remoting Export POJOsas remote services in server-side Spring applications through Spring remote service exporter Make remote services accessible in client-side Spring applications through Spring remote proxy factory Protocol choice is configuration matter Hessian, Burlap, SOAP, RMI, HTTP invoker protocol to be chosen according to requirements Support for integration of EJBs through Spring EJB proxy factory declarative proxies for Stateless Session Beans
  • 21.
    Further Services JMSSupport lightweight messaging JCA Support access to J2EE Connectors Mail Support JavaMailSender Scheduling Support Quartz, Timer Web Application Support Struts, JSF, WebWork, Tapestry Spring Web MVC, Spring Web Flow
  • 22.
    Summary (1) Springis a popular Java application framework core container, AOP framework transactions, data access, remoting dedicated support for J2EE environments integrating with many existing solutions Solves ubiquitous architectural issues wiring and configuration of components flexible configuration of interceptors declarative transaction demarcation implicit management of resources
  • 23.
    Summary (2) Worksin any environment no special compilation or deployment steps no special class loader can run on J2EE, but not tied to J2EE seamless switching between deployment scenarios For any kind of application J2EE web applications running on e.g. Tomcat full J2EE applications running on e.g. WebLogic rich clients (usually with J2EE server as backend) standalone applications (with GUI or headless)
  • 24.
    http://www.springframework.org http://www.springframework.com