Advanced Web Systems 5- Designing Complex Applications. -The IOC Pattern -Light Weight Container. A. Venturini

Transcription

1 Advanced Web Systems 5- Designing Complex Applications -The IOC Pattern -Light Weight Container A. Venturini

2 Introduction Design and maintainability issues The Inversion of Control Pattern How IoC solves those design issues The Spring Framework and IoC Most of the slides from: Inversion of control - Spring, Pascal Bleser

3 The Inversion of Control Pattern Design and maintainability issues

4 Design maintainable systems Design maintainable systems = cope well with change and iterations key issue: manage dependencies Other important aspects/techniques: Design by Contract clearly define the Contract of a class/interface (Javadoc) Contract: what it does, how it behaves NOT how it is implemented! Unit Testing write tests that verify the class/interface's Contract Separation of Concerns write a class/interface for every single Concern

5 Design maintainable systems Dependency = when you tie a component to another one, by one of: inheritance (specialization, generalization) composition instanciation instanciation by factory method parameter use of static methods or attributes

6 Dependency through inheritance public class Dog extends Animal { //... } Animal Dog Dog depends on Animal Inheritance results in strong coupling and is extremely overused in OO. Only use inheritance when it really makes sense from the natural classes' definition, not to avoid duplicating code. Always try to favor Composition over Inheritance.

7 Dependency through composition public class UserManager { private UserDAO userdao; } UserManage r UserDAO UserManager depends on UserDAO Composition creates loose coupling, because when the dependency's (UserDAO) interface or behaviour changes, you only need to adapt the dependant (UserManager). It doesn't have the side effects Inheritance has.

8 Dependency: instanciation Dependency through instanciation public class WebServerProbe { public boolean isrunning() { Socket socket = new Socket();... WebServerProb e Socket <<use>> WebServerProbe depends on Socket

9 Dependency: instanciation by Factory public class UserManager { public Collection getusers() { UserDAO userdao = UserDAOFactory.newInstance();... UserManager <<use>> UserDA O <<use>> UserDAO Factory <<create>> UserManager depends on UserDAOFactory (UserManager also depends on UserDAO)

10 Dependency: static method Dependency through use of a static method public class WebServerProbe { private Collection ports;... public void setports(integer[] ports) { this.ports = java.util.arrays.aslist(ports); WebServerProb e <<use>> Arrays WebServerProbe depends on java.util.arrays

11 What dependencies mean Having a dependency means: dependent component is subject to change when the component it depends on is modified Some forms of dependency are worse than others: inheritance: change of behaviour may be insidious, as new methods are added and used, and your component doesn't notice it has to overwrite them favor composition over inheritance accessing static classes, methods, attributes (e.g. Singletons): dependencies are hidden inside the dependant components' implementation (code), makes it difficult to track down which dependants to modify when you change the static component use Dependency Injection (IoC) instead

12 What dependencies mean Dependencies not bad per-se: of course, you always have dependencies the goal is to minimize the number of dependencies in your design only depend on interfaces What you should aim for: aim for loosely coupled components depend on Interfaces rather than classes, as much as possible The less likely your application is subject to change, the more stable and maintainable it becomes. A complex application is composed of many classes, dependencies are difficult to maintain

13 Loosely coupled Loose vs tight coupling Tight coupling: instanciating of concrete classes inside your logic InputStream is = new FileInputStream(...); using static methods InputStream is = StreamUtils.getConfigFileInputStream(); inheritance Loose coupling: using Factories and Service Locators InputStream is = new ConfigFactory().createInputStream(); use the Inversion of Control pattern

14 Weather Portlet Dependencies

15 Weather Portlet depends on WeatherService Class weatherportlet { public void init() { String proxyhost= String proxyport= ; WeatherService.init(proxyHost,proxyPort); } } WeatherPortlet initialize the WeatherService using a static method call to WeatherService object

16 WeatherService class WeatherService { WeatherService service; public static void init(string proxyhost, String proxyport) { service = new WeatherService(proxyHost, proxyport); } } WeatherService init method creates the only ONE instance of WeatherService object and set in the service class WeatherService { public static void instance() { return service; } } WeatherService implements a singleton pattern: Only one instance object used by the whole application Centralize the creation of the object

17 WeatherPortlet depends on WeatherService WeatherService is tight to the specific weather service provider: What if we need to get weather by another service provider? We need to create a new and different WeatherService class (i.e. YahooWeatherService) We would need to change WeatherPortlet to use YahooWeatherService If we had more objects depending on WeatherService, this should be done for all of them! This is not good, since we should minimize changes of dependent components

18 WeatherPortlet dependency WeatherPortlet extends GenericPortlet GenericPortlet is part of JSR 168 GenericPortlet will not change (or impacts of changes will be carefully studied) It is safe to extend in this case

19 The Inversion of Control Pattern The Inversion of Control Pattern

20 Inversion of Control First... without IoC

21 w/o IoC Implementation without IoC: must retrieve dependencies yourself, inside the logic e.g. JNDI, EJB stub, JDBC Connection, Properties file,... decouple by: coding against interfaces fetch objects using a Factory or a Service Locator call methods on those objects, potentially to retrieve other dependencies e.g. JNDI, JDBC Connection Pool,... creates chained dependencies

22 w/o IoC: Drawbacks Drawbacks of not using IoC: code bloated with dependency retrieval instantiation still creates coupling code bound to a particular environment (container) (EJB container, Servlet container, Rich client,...) difficult to unit test We're going to have a look at those, one by one.

23 w/o IoC: Drawbacks logic bloated with dependency retrieval e.g.: EJB stub, JDBC Connection, Properties file,... sometimes more code for that than for the actual logic solution: encapsulate it (Service Locator, Factory) issue: you'll have to write those Factories yourself issue: Singletons are evil dependencies are not clear, spread all over your code they make unit testing difficult they are difficult to refactor

24 w/o IoC: Drawbacks coding against interfaces decouples, but... instantiation still uses a concrete implementation (=> coupling) solution: use a Factory issue: tight coupling towards the Factory, makes it hard to maintain, difficult to unit test,...

25 w/o IoC: Factory Pattern WeatherPortlet +doview() +processaction() WeatherServiceFactory +createinstance(): WeatherService +getfactory(type: String) <<interface>> WeatherService +getweatherbycity() WeatherComServiceFactory +createinstance(): WeatherService YhaooWeatherServiceFactory +createinstance(): WeatherService WeatherComService YahooWeatherService This is how it becomes our weather portlet if we needed to manage more services WeatherServiceFactory mechanism should be coded On Factory pattern (and DAO, another pattern we will use):

26 w/o IoC: Creation Process WeatherPortlet WeatherServiceFactory WeatherComServiceFactory 1 : getfactory("weathercomservice") <<create>> 2 4 : instance := createinstance() 3 <<create>> 5 WeatherComService 6 7

27 w/o IoC: Drawbacks Code is bound to a particular environment dependency retrieval coded inside your business logic various environments / containers: standalone Java application Swing/SWT application running inside an EJB container running inside a Servlet container example: retrieving a JDBC Connection standalone: using java.sql.drivermanager standalone with a pool: using Apache Commons DBCP inside Tomcat: using InitialContext and DataSource inside Jetty: using Apache Commons DBCP inside EJB container: using InitialContext and DataSource

28 w/o IoC: Drawbacks Difficult to unit test because how to retrieve a dependency is coded inside the class you want to unit test e.g.: when using a Factory, how could you change its behaviour accordingly to your unit test? class MyLogic { public void dosomething() { // use the InitialContext (JNDI) Service Locator // to retrieve the BusinessLogic object InitialContext ctx = new InitialContext(); BusinessLogic partner = (BusinessLogic) ctx.lookup( my/business/logic/impl ); } } // now perform the actual logic: partner.doyourownbusiness(); Now... how to unit test MyLogic without using the EJB and requiring an EJB container?

29 The Inversion of Control Pattern The Inversion of Control Pattern

30 Two types of IOC common to J2EE Dependency Lookup EJB and Apache Avalon - The coarse-grain beans are left looking up dependencies it needs. In J2EE, JNDI is the glue that holds J2EE applications together IBM Dependency Injection Spring and Pico Factories create beans with all the dependencies set on the bean. In Spring that glue is externalized so business classes don t have to worry about how or what they need to glue together.

31 Inversion of Control (1/5) A way of wiring components together wiring = assembling, putting Collaborators together You define Interfaces and implementations Dependencies between interfaces/classes (making them Collaborators ) the Inversion of Control container assembles the Dependent and the Provider, injects the Provider into the Dependent gives you the possibility of selecting which Provider implementation to inject into each Dependent (by configuration, code or automatically (autowiring))

32 Inversion of Control (2/5) WeatherPortlet IoC Container <<interface>> WeatherService WeatherComService YahooWeatherService

33 Inversion of Control (3/5) Lightweight container architecture uses POJOs (Plain Old Java Objects) no need to deploy to a heavyweight container (such as an EJB or Servlet Container) improves testability, makes writing Unit Tests much easier Non-intrusive you don't depend on any specific APIs from the Container no interfaces to implement, no classes to extend from, except your own

34 Inversion of Control (4/5) instead, an IoC container will inject the dependencies into the objects (hence the other name for IoC: Dependency Injection ) Hollywood principle : don't call me, I'll call you without IoC, your logic component (e.g. EJB, POJO, Servlet,...) has the control over its dependencies and, hence, <<use>> Factory has to retrieve them <<use>> MyLogic <<create>> Partner with IoC, the logic components don't have control over their dependencies and don't retrieve them by themselves

35 Inversion of Control (5/5) Key Advantages: effectively decouples your logic components from their dependencies removes the dependency fetching bloat from your code (now it's the IoC container's job) greatly improves your design gives much greater flexibility and reuse of components unit testing becomes much easier don't depend on specific environments

36 Example: w/o IoC Without Inversion of Control: class WeatherPortlet { private WeatherService weatherservice = null; protected final BusinessServiceInterface getweatherservice() { if (weatherservice == null) { // get the factory??? WeatherFactory factory= WeatherServiceFactory.getFactory( weather.com )); weatherservice = factory.create(); } return weatherservice; } public void doview() { getweatherservice().getweatherbycity( bolzano ); } } The creation code should go in any class that uses weatherservice you'll have to reengineer if you change WeatherFactory And if you want to use yahoo weather provider? You should allow to configure your class

37 Example: with IoC With Inversion of Control: class WeatherPortlet { // WeatherService will be set by the IoC container: private WeatherService weatherservice ; // we'll use setter-based injection (explained later): public void setweatherservice(weatherservice weatherservice) { this. weatherservice = weatherservice; } } public void doview() { // perform call on businessservice weatherservice.getweatherbycity( bolzano ); } no dependency at all on how weatherservice is retrieved/provided no code clutter to retrieve the dependency: just an attribute and a setter only dependency is the interface weatherservice The framework is in charge to initialize the weatherservice instance

38 What is the Spring Framework? Spring is a Lightweight Application Framework Where Struts, WebWork and others can be considered Web frameworks, Spring addresses all tiers of an application Spring provides the plumbing so that you don t have to! Spring is based on the Inversion of Control approach

39 Spring Framework History Started 2002/2003 by Rod Johnson and Juergen Holler Started as a framework developed around Rod Johnson s book Expert One-on-One J2EE Design and Development Spring 1.0 Released March /2005 Spring emerged as a leading full-stack Java/J2EE application framework

40 Spring == J2EE Application Server? Spring is NOT a J2EE application server Spring can integrate nicely with J2EE application servers (or any Java environment) Spring can, in many cases, elegantly replace services traditionally provided by J2EE application servers

41 Spring Framework Mission Statement The authors of Spring aim that: Spring should be a pleasure to use Your application code should not depend on Spring APIs Spring should not compete with good existing solutions, but should foster integration. (For example, JDO and Hibernate are great O/R mapping solutions. We don't need to develop another one.)

42 The Spring Framework Mission Statement (2) From springframework.org The authors of Spring believe that: 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.

43 Spring (3) Spring brings a consistent structure to your entire application Spring provides a consistent way to glue your whole application together Spring provides elegant integration points with standard and defacto-standard interfaces: Hibernate, JDO, TopLink, EJB, RMI, JNDI, JMS, Web Services, Struts, etc. Just as Struts did on the web tier, we can realize huge productivity gains by not having to write the common integration points across your application

44 Spring features Below is a list of some of the features in Spring. IOC (Inversion of Control) Container to facilitate Dependency Injection MVC Framework implemented with interfaces and IOC(future presentation) AOP Framework for accessing J2EE service declaratively JDBC and DAO layer Abstraction (another presentation) Declarative Transaction Management support, Security Management JMS producer, consumer abstractions, and conversion

45 Spring is Non-Invasive What does that mean? You are not forced to import or extend any Spring APIs An invasive API takes over your code. Anti-patterns: EJB forces you to use JNDI Struts forces you to extend Action Invasive frameworks are inherently difficult to test. You have to stub the runtime that is supplied by the application server

46 what IS Spring (1/2)? At it s core, Spring provides: An Inversion of Control Container Also known as Dependency Injection (Fowler s term) An AOP Framework Spring provides a proxy-based AOP framework You can alternatively integrate with AspectJ or AspectWerkz A Service Abstraction Layer Consistent integration with various standard and 3 rd party APIs These together enable you to write powerful, scalable applications using POJOs.

47 what IS Spring (2/2)? Spring at it s core, is a framework for wiring up your entire application BeanFactories are the heart of Spring

48 Spring Overview from springframework.org Note: Spring distribution comes as one big jar file and alternatively as a series of smaller jars broken out along the above lines (so you can include only what you need)

49 Preview: Spring Framework Open Source project License: Apache Software License 2.0 Website: First public release: June 2003 Lightweight framework, written in Java Started by Rod Johnson while he wrote the book Expert One-on-One J2EE Design and Development (Wrox Press, ISBN: )

50 Why a lightweight framework? J2EE works well but... it's a heavyweight architecture that puts a lot of constraints it's often too much to implement simple applications it's very difficult to test (no unit testing possible) J2EE services are not very modular (JMS, JTA, EJB, JNDI,...) Component reuse is limited by the container and environment that it's used it EJB Container, Servlet Container, standalone, Rich client, Embedded Devices,... No component wiring on POJO level IoC Containers address that topic

51 Spring and Inversion of Control Inversion of Control, a.k.a. Dependency Injection pattern at the core of Spring Framework advantages of applying IoC: makes code much easier to unit test removes bloat from code, helps you concentrate on implementing the actual business logic select service implementations by configuration, not code no more evil singletons enforces use of several good practices in design

52 Example: but how does it work?!? class MyMain { public static void main(string[] args) { // initialize the IoC container (here it's Spring): XmlBeanFactory xmlbeanfactory = new XmlBeanFactory(new ClassPathResource( beans.xml )); // retrieve MyLogic: MyLogic mylogic = (MyLogic) xmlbeanfactory.getbean( mylogic ); } } // call the method: mylogic.doyourthing(); <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE beans...> <!-- this is beans.xml --> <beans> <bean id= thebusinesssvc class= foo.businessservicemock /> <bean id= mylogic class= foo.mylogic > <property name= businessservice > <bean ref= thebusinesssvc /> </property> </bean> </beans>

53 What Spring is doing... <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE beans...> <!-- this is beans.xml --> <beans> <bean id= usermanagerdao" class="my.pkg.dao.hibernateusermanagerdao/"> (1) <bean id= usermanager" class="my.pkg.usermanagerimpl"> (2) <property name="usermanagerdao" ref="usermanagerdao"/> (a) </bean> <bean id="logonservice class= my.pkg.services.logonserviceimpl > (3) <property name= usermanager ref= usermanager /> (b) <property name= guestlogon value= guest /> (c) </bean> </beans> usermanagerdao = new my.pkg.dao.hibernateusermanagerdao(); // (1) usermanager = new my.pkg.usermanagerimpl(); // (2) usermanager.setusermanagerdao(usermanagerdao); // (a) logonservice = new my.pkg.services.logonserviceimpl(); // (3) logonservice.setusermanager(usermanager); // (b) logonservice.setguestlogon("guest"); // (c)

54 Setter and Constructor Injection // Example of Setter Injection package eg; public class ExampleBean { private AnotherBean beanone; private YetAnotherBean beantwo; } public void setbeanone(anotherbean b) { beanone = b; } public void setbeantwo(yetanotherbean b) { beantwo = b; } // Example of Constructor Injection (This is the typical Spring usage) public class ExampleBean { private AnotherBean beanone; private YetAnotherBean beantwo; public ExampleBean (AnotherBean a, YetAnotherBean b){ this.beanone = a; this.beantwo = b;

55 BeanFactories A BeanFactory is typically configured in a XML file with the root element: <beans> The XML contains one or more <bean> elements id (or name) attribute to identify the bean class attribute to specify the fully qualified class

56 BeanFactories By default, beans are treated as singletons Can also be prototypes Here is an example: <beans> <bean id= widgetservice class= com.zabada.base.widgetservice > <property name= poolsize > <! -property value here--> </property> </bean> </beans> The bean s ID The bean s fullyqualified classname Maps to a setpoolsize() call

57 Property Values for BeanFactories Strings and Numbers <property name= size ><value>42</value></property> <property name= name ><value>jim</value></property> Arrays and Collections <property name= hobbies > <list> <value>basket Weaving</value> <value>break Dancing</value> </list> </property>

58 Property Values for BeanFactories (continued) The real magic comes in when you can set a property on a bean that refers to another bean in the configuration: <bean name= widgetservice class= com.zabada.base.widgetserviceimpl > <property name= widgetdao > <ref bean= mywidgetdao /> </property> </bean> calls setwidgetdao(mywidgetdao) where mywidgetdao is another bean defined in the configuration This is the basic concept of Inversion of Control