Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

CDI para Java EE 7

834 views

Published on

Presentación a nivel introductoria sobre CDI. Desarrollado en base a los libros de Antonio, Arun Gupta y ejemplos de CDI en https://github.com/javaee-samples.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

CDI para Java EE 7

  1. 1. CDI Context and Dependency Injection Ing. Jose Diaz Diaz JOEDAYZ
  2. 2. Acerca de Ing. José Amadeo Martin Díaz Díaz CEO JoeDayz.pe & Docente en EPE UPC Formación BlueStar Energy (2007) Bristol Myers Squibb (2006) Trans Solutions Systems (2003 - 2005) Telefonica Servicios Internet (2000 - 2002) Egresado de la Pontificia Universidad Católica del Perú (1994 - 2000) @jamdiazdiaz
  3. 3. JoeDayz.pe Partnership
  4. 4. Introducción La primera versión de Java EE (J2EE) introdujo el concepto de inversión de control No fue hasta Java EE 5 y 6 que el API para administración de ciclo de vida e inyección de dependencias estuviese robusta. Hoy CDI nos da un modelo de programación donde cada componente Java EE puede ser inyectable, interceptable y administrable. CDI esta construido sobre la base de “pobre acoplamiento y fuerte tipado"
  5. 5. ¿Que son los Beans?
  6. 6. Entendiendo a los Beans Java SE tiene JavaBeans Java EE tiene Enterprise Java Beans Otros: Servlets, SOAP WS, RESTful WS, entidades Beans Manejados POJOs
  7. 7. Entendiendo a los Beans Los Bean Manejados son objetos administrados por el contenedor que soportan un conjunto basico de servicios: inyección de recursos, administración de ciclo de vida, e intercepción. Introducidos en Java EE 6
  8. 8. Entendiendo a los Beans Por ejemplo un EJB puede ser un Bean Manejado con servicios extra Un Servlet puede ser un Bean Manejado con servicios extra (diferentes al del EJB), etc. etc.
  9. 9. Entendiendo a los Beans Los Beans son objetos CDI que son construidos sobre la base del modelo de Bean Manejados. Tienen contextos definidos, soporte a inyección de dependencias, intercepción, decoración, son especializados con el uso de qualifiers y pueden ser usados en EL.
  10. 10. Entendiendo a los Beans En resumen, cualquier clase Java que tenga un constructor por defecto y se ejecute en un contenedor es un bean. De esta forma los JavaBeans y EJBs pueden tomar ventaja de los servicios CDI
  11. 11. Inyección de Dependencias
  12. 12. Dependency Injection (DI) Es un patrón de diseño que desacopla componentes dependientes. Termino concebido por Martin Fowler. Java EE 5 introdujo inyección para recursos como EJBs, entity managers, data sources, fabricas JMS, y destinos al interior de componentes como Servlets, JSF beans y EJBs. Así aparecieron @Resource, @PersistenceContext, @PersistenceUnit, @EJB y @WebServiceRef
  13. 13. Dependency Injection (DI) El primer paso tomado en Java EE 5 no fue suficiente y Java EE 6 creo dos especificaciones diferentes para potenciar DI en la plataforma: Dependency Injection (JSR 350) y Context and Dependency Injection (JSR 299) En Java EE 7 se han juntado las dos especificaciones
  14. 14. Ciclo de vida de un Bean Manejado
  15. 15. Scopes y Context CDI viene con scopes predefinidos: request, session, application y conversation
  16. 16. Interception Similar a la programación orientada a aspectos (AOP) El AOP se logra en la plataforma, a través, de interceptors. Estos son automaticamente disparados por el contenedor cuando un método de un bean manejado es invocado.
  17. 17. Interception
  18. 18. Deployment Descriptor beans.xml y es obligatorio Ubicado en META-INF o WEB-INF Aquí se configura interceptors, decoradores, alternatives, etc. Si tu aplicación contiene diferentes jars y deseas tener CDI para toda la aplicación. Cada jar debe tener su propio beans.xml
  19. 19. ¿De que trata CDI?
  20. 20. Resumen CDI es importante para otras especificaciones como Bean Validation, JAX-RS, EJB, JSF. Pero, CDI 1.1 no sería nada sin otras como: DI (JSR 330), Managed Bean 1.0 (JSR 342), Common Annotations 1.2 (JSR 250), Expression Language 3.0 (JSR 341) e Interceptors 1.2 (JSR 318)
  21. 21. Historia En el 2006 inspirado en Seam, Guice y Spring Framework, Gavin King (creador de Seam) lidero la especificación JSR 299 denominada Web Beans dirigida para Java EE 6. Web Beans ha sido renombrado a Context and Dependency Injection 1.0 construida sobre la base de la nueva JSR 330 : Dependency Injection para Java 1.0 (@Inject)
  22. 22. Historia Dependency Injection aporto las anotaciones: @Inject, @Named, @Qualifier, @Scope, @Singleton CDI añadió nuevas características como context management, events, decorators, e interceptors (JSR 318). Ademas de permitir al desarrollador extender la plataforma que era imposible hasta entonces.
  23. 23. Historia El objetivo principal de CDI es entonces: Dar mas cohesión a la plataforma Unir la capa web y la capa de transacciones Que DI sea el ciudadano de primera clase Poder agregar nuevas extensiones facilmente En JAVA EE 7, CDI 1.1 es el fundamento para multiples JSRs y ha recibido muchas mejoras
  24. 24. ¿Que hay de nuevo en CDI 1.1? No añade nuevas características. Su objetivo es integrar CDI con otras especificaciones. La nueva clase CDI provee acceso programático a facilidades de CDI fuera de un bean manejado Interceptors, decoradores, y alternatives pueden ser prioridades (@Priority) y ordenados para una aplicación completa Cualquier tipo o paquete puede ser ignorado de ser considerado un bean para CDI con @Vetoed en el tipo o paquete El @New qualifier es deprecado y se debe en su lugar usar @Dependent @WithAnnotations permite una extensión para filtrar por tipos
  25. 25. Principales CDI Packages
  26. 26. Implementación de Referencia La implementación de referencia para CDI es Weld, un proyecto Open Source de JBoss Existen otras como Apache OpenWebBeans o CanDi (Caucho), así como Apache DeltaSpike
  27. 27. Escribiendo un bean CDI
  28. 28. Anatomía de un CDI Bean No es una clase non-static inner Es una clase concreta o anotada con @Decorator y Tiene un constructor por defecto sin parámetros, o declara un constructor anotado con @Inject Todo lo demás es opcional
  29. 29. Dependency Injection
  30. 30. Dependency Injection
  31. 31. @Inject Nota en Java EE 7 aún se puede usar @Resource, pero, deberías considerar usar @Inject
  32. 32. @Inject
  33. 33. Puntos de Inyección El punto de inyección puede ser en propiedad, setter o constructor No es necesario crear un getter/setter para un atributo para usar inyección. No importa si es privado. En el caso de un constructor solo puedes tener uno solo con @Inject
  34. 34. Puntos de Inyección ¿Cuándo deberías usar inyección por setter o constructor? No hay respuesta técnica real para esta pregunta; depende de tu elección. Recuerda que el contenedor es quien hace el trabajo.
  35. 35. Default Injection Si en los ejemplos anteriores asumimos que GeneradorNumero solo tiene una implementación (IsbnGenerador). CDI puede inyectarlo sin problemas usando @Inject Cuando no declaras un Qualifier, el contenedor asume el qualifier @javax.enterprise.inject.Default.
  36. 36. Default Injection
  37. 37. Default Injection
  38. 38. Qualifiers Cuando tenemos que escoger una implementación especifica entonces usamos Qualifiers
  39. 39. Qualifiers
  40. 40. Qualifiers
  41. 41. Qualifiers
  42. 42. Qualifiers
  43. 43. Qualifiers con Miembros Que pasa si queremos tener qualifiers combinados. Es decir @DosDigitos, @OchoDigitos, @DiezDigitos, @TreceDigitos O @DosParDigitos, @OchoImparDigitos, @OchoParDigitos, etc.
  44. 44. Qualifiers con Miembros En ese caso podemos crear un solo qualifier @NumeroDeDigitos con una enumeration como valor y un Boolean para la paridad.
  45. 45. Qualifiers con Miembros
  46. 46. Qualifiers con Miembros
  47. 47. Multiples Qualifiers
  48. 48. Alternatives Algunas veces tu deseas inyectar una implementación según el escenario de deployment. Digamos que en el ejemplo que estamos revisando, deseamos generar un numero falso (mock) en un ambiente de pruebas.
  49. 49. Alternatives
  50. 50. Alternatives Si queremos que el alternativo funcione tenemos que habilitarlo en beans.xml
  51. 51. Producers Hemos visto hasta ahora como un bean CDI se inyecta en otro bean CDI. Pero, también podemos inyectar primitivos (long, float, …), tipos de array, o cualquier otro POJO que no tiene CDI habilitado. Esto gracias a los producers.
  52. 52. Producers Por defecto, no podemos inyectar clases de java.util.Date, java.lang.String. Esto debido a que estas clases están en rt.jar y este jar no tiene un beans.xml Recordemos que si un archivo .jar no tiene beans.xml bajo un META-INF, CDI no podrá descubrir nada y el POJO no podrá tratarse como un bean. Es decir, no podrá ser inyectable. La única forma de hacerlo inyectable es usando campos producers o métodos producers.
  53. 53. Producers
  54. 54. Producers
  55. 55. InjectionPoint API Los atributos y tipos de retorno producidos por @Produces no necesitan información alguna de donde ellos serán inyectados Pero hay otros casos en que si se necesita saber. Este último es el caso de java.util.logging.Logger.
  56. 56. InjectionPoint API
  57. 57. Producer
  58. 58. Disposers Hemos usado producers para crear tipos o POJOs para que sean inyectados. Pero, no hemos tenido que destruirlos o cerrarlos una vez usados. Algunos métodos producers necesitan objetos que requieren explicitamente destrucción como JDBC connections, JMS session, o entity manager. Para destrucción existen los disposers.
  59. 59. Disposers
  60. 60. Disposers Gracias a los producers y disposers, ya no tenemos que crear y cerrar recursos
  61. 61. Scopes @ApplicationScoped @SessionScoped @RequestScoped @ConversationScoped @Dependent (ciclo de vida que depende del cliente)
  62. 62. Scopes Los beans con scope @SessionScoped o @ConversationScoped deben ser serializables, puesto que el contenedor los pone en pausa de rato en rato. Si un scope no es dado. El default es @Dependent
  63. 63. Conversation Este scope guarda información del estado del usuario, permanece entre multiples requests y es demarcado programáticamente por la aplicación. Ejemplos de uso: reservas, compras en una tienda virtual, wizard en general
  64. 64. Conversation
  65. 65. Conversation
  66. 66. Beans en Expression Language Por defecto los beans CDI no tienen un nombre y no son resuelto vía EL binding. Para asignarle un nombre se tiene que usar @Named
  67. 67. Beans en Expression Language
  68. 68. Interceptors Los interceptors son de 4 tipos: @AroundConstruct: Asociado con el constructor de la clase destino @AroundInvoke: Asociado con un metodo de negocio especifico @AroundTimeout: Solo para EJB timer service @PostConstruct y @PreDestroy
  69. 69. Interceptors Desde JAVA EE 6, los interceptors han evolucionado a una especificación separada. Ellos pueden ser aplicados a Bean Manejados, así como a EJBs, SOAP y RESTful web services.
  70. 70. Interceptor en la misma clase
  71. 71. Interceptor en la misma clase Respecto al ejemplo anterior. Solo se intercepta métodos que sean públicos, privados, protected o default; pero, no static o final El método interceptor debe tener un InvocationContext como parámetro y debe retornar Object El método puede arrojar excepciones chequeadas
  72. 72. Interceptor en la misma clase Respecto al ejemplo anterior. Solo se intercepta métodos que sean públicos, privados, protected o default; pero, no static o final El método interceptor debe tener un InvocationContext como parámetro y debe retornar Object El método puede arrojar excepciones chequeadas
  73. 73. InvocationContext Interface
  74. 74. InvocationContext Interface
  75. 75. Interceptor en la misma clase En el ejemplo anterior se ha usado @Transactional. Este se usa para el manejo de transacciones en CDI beans como Servlets, JAX-RS, JAX-WS. @Transactional es implementado via un interceptor
  76. 76. Clases Interceptor Esta opción es cuando se desea que el comportamiento cross-cutting concerns se debe tener en una clase separada. Un ejemplo de esto es el Logging
  77. 77. Clases Interceptor
  78. 78. Clases Interceptor
  79. 79. Clases Interceptor Si se desea que diferentes métodos sean interceptados de una clase, se puede colocar la referencia al interceptor en la parte superior de la clase. Y si se desa excluir algún metodo se usara @ExcludeClassInterceptors
  80. 80. Interceptors de ciclo de vida
  81. 81. Interceptors de ciclo de vida
  82. 82. Encadenando y Excluyendo Interceptors
  83. 83. Interceptor Binding Interceptor Binding es solo permitido si CDI es habilitado Un Interceptor Binding es una anotación definida por el usuario con la anotación @InterceptorBinding
  84. 84. Interceptor Binding
  85. 85. Interceptor Binding
  86. 86. Interceptors Los interceptors esta deshabitados por defecto. Al igual que las alternatives, los interceptors tienen que ser definidos en el beans.xml del jar o módulo Java EE.
  87. 87. Interceptors
  88. 88. Priorizando Interceptors Binding Si bien los Interceptors binding nos dan pobre acoplamiento de interceptors, perdemos la posibilidad de ordenarlos. Desde CDI 1.1 ya podemos hacerlo usando @Priority
  89. 89. Priorizando Interceptors Binding
  90. 90. Priorizando Interceptors Binding @Priority puede tomar un Integer de cualquier valor. La regla es que interceptors con prioridad pequeña son llamados primero. Java EE 7 define prioridades a nivel de la plataforma y podemos tener interceptors llamados antes o después de ciertos eventos.
  91. 91. Priorizando Interceptors Binding PLATFORM_BEFORE = 0: Inicio de un rango de interceptors definidos por la plataforma Java EE LIBRARY_BEFORE = 1000: Inicio de un rango de interceptors definidos por extension libraries APPLICATION = 2000: Inicio de un rango de interceptors definidos por aplicaciones LIBRARY_AFTER = 3000: Inicio de un rango de últimos interceptors definidos por extension libraries PLATFORM_AFTER = 4000: Inicio de un rango de últimos interceptors definidos por la plataforma Java EE
  92. 92. Priorizando Interceptors Binding En Conclusión, si deseamos que nuestro interceptor sea ejecutado antes de cualquier interceptor de aplicación, pero después de cualquier interceptor temprano de la plataforma debemos escribir:
  93. 93. Decoradores Los decoradores son un patrón de diseño común de Gang of Four. La idea es tomar una clase y wrap otra clase alrededor de ella (decorarla). Es decir, si llamas a una clase decorada, pasamos, a través, del decorador antes de llegar a la clase destino. Los Decoradores son especiales para añadir lógica adicional a un método de negocios. Son similares a los interceptors en cierta forma, pero son complementarios
  94. 94. Decoradores
  95. 95. Decoradores Los decoradores deben tener un delegate injection point anotado con @Delegate, del mismo tipo que el bean que se esta decorando. Esto permite al decorador invocar al objeto delegado y adicionalmente llamar a un método de negocio de este. Los decoradores por defecto están deshabilitados. Estos deben ser habilitados en el beans.xml
  96. 96. Decoradores
  97. 97. Eventos Los Events permite a los beans interactuar fuera del tiempo de compilación. Un Bean puede definir un evento, otro puede dispararlo y otro manejar el evento Los beans pueden estar en paquetes separados y aún en capas separadas de la aplicación Este es el observer/observable design pattern del Gang of Four
  98. 98. Eventos Event producers disparan eventos usando la interface Event. Un producer lanza eventos llamando al método fire(), pasa el objeto event y no es dependiente del observer. En el ejemplo que vamos a ver LibroService dispara un event (LibroAddedEvent) cada vez que un Libro es creado. Este fire(libro) dispara el evento y notifica a los metodos observer este particular evento.
  99. 99. Eventos
  100. 100. Eventos
  101. 101. Eventos
  102. 102. Demos en https://github.com/joedayz/javaee7samples https://github.com/joedayz/javaee7samples https://github.com/joedayz/javaee7samples
  103. 103. Libros Recomendos http://oreil.ly/1jUrX Db http://amzn.to/1bzie KC
  104. 104. Participa en GitHub https://github.com/javaeesamples
  105. 105. Gracias por su atención JOEDAY Z @joedayz www.joedayz.pe Ing. Jose Diaz

×