html5-img
1 / 63

Spring – Power to the POJO Introductie tot het Spring Framework

Spring – Power to the POJO Introductie tot het Spring Framework. Aino Andriessen & Lucas Jellema KC Web & Java, donderdag 30 juni 2005. Agenda. Introductie Spring – History, Background Hoe kom je aan nieuwe objecten BeanFactory en Inversion of Control + Dependency Injection

amos
Télécharger la présentation

Spring – Power to the POJO Introductie tot het Spring Framework

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Spring – Power to the POJOIntroductie tot het Spring Framework Aino Andriessen & Lucas Jellema KC Web & Java, donderdag 30 juni 2005

  2. Agenda • Introductie Spring – History, Background • Hoe kom je aan nieuwe objecten • BeanFactory en Inversion of Control + Dependency Injection • Hoe laat je bestaande objecten naar je pijpen dansen? • Aspect Oriented Programming (AOP) • Business Tier & Architectuur • Test Driven Development • Spring Persistence & Spring DAO • Spring Remoting • Losse eindjes, conclusies, discussie • Workshop

  3. Where we’ve come from • EJB as we know it… • Resembles the original JavaBeans specification in name only. • Heavyweight: • Requires application server • Difficult to unit-test • Intrusive (must implement EJB interfaces) • Complex • Home/Remote/Local/LocalHome interfaces • Deployment descriptors • Non-intuitive

  4. The future of EJB… • Spilling the beans… • EJB 3.0 will embrace simplicity • Based on POJO/POJI (? Well, maybe) • Employ dependency injection instead of LDAP • Declarative services (transactions, security) will be aspects • Entity beans will be POJOs, persisted via Hibernate-like framework

  5. The future is NOW! • Spring is a lightweight container framework • Build applications based on POJO/POJI. • Wire beans together using dependency injection. • Declaratively apply transactions and security using aspect. • Integrates cleanly with Hibernate for persistence. • EJB 3.0=Spring + Hibernate + Metadata

  6. Spring History • J2EE Design and Development – by Rod Johnson, 2002 • Introducing the i21 framework • First release of Spring: Spring 2004 • Spring 1.2.1: June 2005 • Open Source • Interface21 – small company with most core committers • Contributions from Oracle and otherparties • Spawned many sub-projects

  7. Power to the POJO AOP Consistent Service Abstractions (Template Pattern) IoC (Dependency Injection)

  8. Spring’s modules

  9. What’s more… • Remoting support via RMI, JAX-RPC, and Hessian/Burlap • Metadata (ala, JSR-175 or Commons Attributes) • Persistence via TopLink, Hibernate, JDO, or iBatis support • E-mail support • EJB support • JMX Support (Spring 1.1) • JMS support • Spring Rich Client Platform (Spring 1.1) • Spring .Net

  10. Spring is HOT!

  11. Many books available • J2EE without EJB • The starting point • Spring Live • Pro Spring • Spring in Action • Professional Spring Development • To be released, july 2005

  12. Core SpringInversion of Control & Dependency Injection

  13. Coupling • Highly coupled code is… • Hard to test • Hard to maintain • Exhibits “whack-a-mole” style bugs • Uncoupled code is… • Code that doesn’t do anything • Coupling is somewhat necessary… • …but should be controlled

  14. Dependency Injection • The “Hollywood Principle”: Don’t call me, I’ll call you. • Collaborators aren’t asked for…they’re received. • Also known as “Dependency Injection”, thanks to Martin Fowler.

  15. Benefits of IoC • Objects are more cohesive because they are no longer responsible for obtaining their own collaborators. • When used with interfaces, code is very loosely coupled.

  16. Elements of a Spring app • Beans • Not EJBs. Actually, not necessarily JavaBeans. Just POJOs • Bean wiring • Typically an XML file. • A bootstrap class • A class with a main() method. • A servlet. • The bootstrap class uses a BeanFactory (or IoC Container) to retrieve POJOs • That have been ‘wired’ and ‘dependency injected’

  17. IoC Container in ActionApplication Class needs POJOs POJO 2 IoC Container POJO 1 POJO 3 xml pojo 1 pojo 2 getBean(“POJO1”) pojo 3 Application

  18. Wiring beans in XML • Root elements is <beans> • Contains one or more <bean> elements • id (or name) attribute to identify bean • class attribute to specify class The bean’s ID <beans> <bean id=“foo” class=“com.habuma.foobar.Foo”> <!-- Properties defined here --> </bean> </beans> The bean’s fully- qualified classname

  19. Wiring a property • Use <property> element • name attribute specifies name of property <beans> <bean id=“foo” class=“com.habuma.foobar.Foo”> <property name=“bar”> <!-- Property value goes here --> </property> </bean> </beans> Maps to a setBar() call

  20. Property values • Strings and numbers: • Null • Lists and arrays: <property name=“bar”><value>42</value></property> <property name=“bar”><value>Hello</value></property> <property name=“bar”><null/></property> <property name=“bar”> <list> <value>ABC</value> <value>123</value> </list> </property>

  21. Property values • Sets: • Maps: <property name=“bar”> <set> <value>ABC</value> <value>123</value> </set> </property> <property name=“bar”> <map> <entry key=“key1”><value>ABC</value></entry> <entry key=“key2”><value>123</value></entry> </set> </property>

  22. Property values • Property sets: • Other beans: <property name=“bar”> <props> <prop key=“prop1”>ABC</prop> <prop key=“prop2”>123</prop> </set> </property> <property name=“bar”> <ref bean=“bar”/> </property>

  23. Auto-wiring • You can auto-wire… • “byName”: Property names are matched to bean names • “byType”: Property names are matched to bean types • “constructor”: Pico-like constructor wiring. Like “byType” except using constructor. • “autodetect”: Uses reflection to decide whether to use “byType” or “constructor”

  24. Auto-wiring <bean id=“foo” class=“com.habuma.foobar.Foo” autowire=“byName”/> <bean id=“foo” class=“com.habuma.foobar.Foo” autowire=“byName”> <property name=“bar”><value>bar</value></property> </bean> <beans default-autowire=“byType”> <!-- Bean definitions go here --> </beans>

  25. BeanFactory vs. ApplicationContext • A BeanFactory is the Spring container. • Loads beans and wires beans together. • Dispenses beans as requested. • XmlBeanFactory is the most commonly used. • An ApplicationContext is a BeanFactory, but adds “framework” features such as: • I18N messages • Event notification

  26. IoC Examples

  27. Example of a IoC based programming

  28. The knight before…

  29. The knight after…

  30. Core SpringAspect Oriented Programming • AOP – a programming technique that promotes separation of concerns within a software system • Recurring – often infrastructural – concerns can easily be duplicatedin many objects • Security • Transaction Management • Logging • Profiling • AOP suggestsseparation • Concerns are appliedat compile or run-time

  31. AOP in a nutshell • Aspect: A modularization of a cross-cutting concern. Implemented in Spring as Advisors or interceptors • Joinpoint: Point during the execution of execution. • Advice: Action taken at a particular joinpoint. • Pointcut: A set of joinpoints specifying where advice should be applied. • Advisor: Fully represents an aspect, including both advice and a pointcut. • Introduction: Adding methods or fields to an advised class. • Weaving: Assembling aspects into advised objects.

  32. Without AOP

  33. With AOP

  34. Implementing AOP • Compile time – modify the source code during compilation • Requires a customized Java Compiler • For example AspectJ; Spring does not do compile time AOP • Run time – byte injection • Change the class when loaded, generating a subclass that contains the aspects • Uses CGLib library • Run time – using the JDK 1.3 Dynamic Proxy • Instead of getting an object instance, the application receives a proxy object • The proxy implements the same interface • And maybe something else as well • Besides, it can intercept and wrap method calls

  35. IoC Container hides AOP implementation from POJO consumer Aspect A invoke() Proxy Pojo1Impl xml target Aspect B before() target=pojo1Impl IoC Container implements • pojo1 = proxy • Target interceptorNames => AspectA, AspectB implements POJO 1(interface) getBean(“POJO1”) Application AspectA AspectB

  36. Different types of Advice • Before advice • Calls to advised methods are intercepted before the method is called. • After returning advice • Calls to advised methods are intercepted after a successful return. • After throws advice • Calls to advised methods are intercepted after an exception is thrown. • Around advice/interception • Calls to advised methods are intercepted. Call must be explicitly made to target method. • Introduction advice • Allows a class (or rather its proxy) to implement additional interfaces • Calls to methods are intercepted…even when the target bean doesn’t have the method! • Actually, just a special case of around advice

  37. Creating Advise • Create a class that implements one or more of the Spring AOP interfaces • MethodInterceptor • BeforeAdvice • AfterReturningAdvice • ThrowsAdvice • Implement the interface method • before (Method method, Object[] args) • afterReturning(Object returnValue, Method method, Object[] args) • invoke(MethodInvocation invocation)

  38. Defining Pointcuts in Spring(specify where to apply which Advice) • Programmatically • No BeanFactory required • Can be used independently of the rest of Spring • Declaratively • In the bean container configuration file (applicationContext.xml)

  39. Applications of AOP by Spring itselfalways in conjunction with IoC/DI • Remoting Support • Proxy references a remote object • Transaction Management • Service method is wrapped in around advice that opens and closes the transaction • Security • JMX • Proxy implements the MBean interfaces for its target object • Mock Testing • Tested objects are injected with Mock objects that are dynamically created (made up)

  40. AOP through Proxy Proxy EmployeeImpl Employee

  41. Future of AOP – according to Rod Johnson • Programming Aspects and composing an Application from Aspects will become widely accepted • Various orthogonal concerns can be dealt with in parallel • Maintaining a single – cross application concern – is done by maintaining a single aspect • Tool and Runtime support for AOP will further increase • Development of IBM WebSphere & WSAD is heavily done in an AOP fashion

  42. Spring’s recommended Application Guidelines and Architecture • Program against interfaces • For example Service Interface, DAO Interfaces • Typically no interfaces for Domain Classes • No configuration “plumbing” in your classes • Have configuration details injected • Domain Classes are used through all tiers • No Struts ActionForms to wrap domain classes • Controllers use Business Service methods to create or manipulate Domain Objects • Practice “Test driven development”

  43. Spring’s recommended architecture Presentation Tier View Components Generate HTML or PDF Remote Service Exporters Using SOAP, RMI, JAX-RPC etc. Web Tier Actions (Controllers) Business Tier Business Services Layer Interfaces and Container Managed Implementations Data Tier DAO Interface Layer Interfaces, independent of implementing DAO Technology Persistent DomainObjects DAO Implementation layer Retrieves, saves entities using ORM tool or JDBC O/R Mapping Layer JDBC JDBC RDBMS

  44. Spring and Test Driven Development • Agile Software Engineering methods, such as XP • First design and develop a test based on interfaces • Before implementing the interfaces • Before starting to resolve a bug • Automated Unit Testing for every class in the application • At every stage of development, the test can be rerun! • Unit Testing usually based on JUnit • Great integration in Eclipse and JDeveloper 10.1.3 (10.1.2 is somewhat sparse)

  45. Spring and Test Driven Development • Challenges include • Container Dependencies (HttpServlet object) • Dependencies on external objects (not a unit test) • Especially objects that are hard to configure, e.g. DAO Impl • Dependencies on objects that have not yet been implemented

  46. Spring support for Test Driven Development • When all objects (Service and DAO Impl) are Spring Beans • They get dependency injected by the container • During a test, instead of injecting them with real objects • We can inject them with Mock Objects, that will return the values we specify when called • The real objects do not need to exist • even when they do exist, using mock objects ensures we are performing a true UNIT test

  47. Unit Testing HrmServiceImpl using Mock objects Unit Test MockEmployeeDAOImpl HrmServiceTest (JUnit TestCase) Business Tier HrmServiceImpl Data Tier EmployeeDAO Interfaces, independent of implementing DAO Technology Persistent DomainObjects EmployeeDAOImpl (does not yet exist)

  48. Properly implementing those Mock DAO objects • … (Aino)

  49. Spring and Web ApplicationsStruts and other Controller Frameworks • Struts support • Auto-Load WebContext (== BeanFactory) in session • Make Action Classes Spring aware and have them reference the WebContext • Proxy Action Classes and Dependency Inject them • Register Actions as Spring Beans • Similar support for • WebWork • Tapestry

  50. Spring and Web ApplicationsJava Server Faces • Java Server Faces • JSF has managed-beans • Very similar to Spring Beans • Though no support for AOP • And: do you want low level, persistency related configuration details in the faces-config.xml • JSF-Spring project offers a JSF variable resolver • It takes bean references in faces-config.xml and tries to resolve them in Spring context files

More Related