JEE 5 - EJB3

2.081 visualizaciones

Publicado el

Brief description about EJB3 made was few years ago while studying about SCEA certification.

Publicado en: Educación
0 comentarios
4 recomendaciones
Estadísticas
Notas
  • Sé el primero en comentar

Sin descargas
Visualizaciones
Visualizaciones totales
2.081
En SlideShare
0
De insertados
0
Número de insertados
1.315
Acciones
Compartido
0
Descargas
1
Comentarios
0
Recomendaciones
4
Insertados 0
No insertados

No hay notas en la diapositiva.
  • Although a Java EE application can consist of the three or four tiers shown in Figure 1-1, Java EE multitiered applications are generally considered to be three-tiered applications because they are distributed over three locations: client machines, the Java EE server machine, and the database or legacy machines at the back end. Three-tiered applications that run in this way extend the standard two-tiered client and server model by placing a multithreaded application server between the client application and back-end storage.
  • JEE 5 - EJB3

    1. 1. EJB 3.0 JSR 220 Emmerson Miranda SCJP 1.5 SCWCD J2EE 1.5 Blog : http://emmersonmiranda.blogspot.com/
    2. 2. Introducción Emmerson Miranda SCJP 1.5 SCWCD J2EE 1.5 Blog : http://emmersonmiranda.blogspot.com/
    3. 3.  Uso de anotaciones para anotar los EJB, esto reduce el número de clases e instancias necesarias, además de eliminar la necesidad de crear descriptores de despliegue.  “configuration by exception” es decir proporciona especificaciones por defecto para las opciones mas comunes.  Encapsulación de los accesos JNDI usando los mecanismos de anotaciones, inyección de dependencias y búsquedas simples.  Las interfaces de negocio requeridas para los beans de session ahora se basan en POJIs (Plain Old Java Interfaces)
    4. 4.  Simplificación de la persistencia de entidades mediante JPA.  Eliminación de todas las interfaces requeridas para las entidades persistentes.  Uso de anotaciones y descriptores XML para las entidades persistentes (tablas y sus relaciones)  Reduce la necesidad de uso de las excepciones checked.
    5. 5.  Son interfaces entre nuestros componentes y las funcionalidades de bajo nivel de un plataforma específica (que soporta el componente).  Todo componente web, enterprise bean, application client; necesita ser ensamblado como un modulo JEE y desplegado en el contenedor antes de ser ejecutado.  El proceso de ensamblado requiere especificar la configuración para cada componente mediante ficheros XML.  Configurando el contenedor se personaliza el soporte proporcionado por el servidor JEE, incluyendo servicios como seguridad, administración de transacciones, búsquedas JNDI y conectividad remota.
    6. 6.  El modelo de seguridad Java EE nos permite configurar los componentes Web o EJB de para que puedan ser utilizados por usuarios autorizados.  El modelo transaccional nos permite especificar las relaciones entre los métodos para realizar una transacción, de esta manera múltiples métodos pueden ser tratados como una unidad.  JNDI proporciona una interfaz unificada para la búsqueda de múltiples servicios empresariales, de esta manera los diversos componentes pueden acceder a estos servicios.  El modelo de conectividad remota administra las comunicaciones a bajo nivel entre los clientes y los beans empresariales.
    7. 7.  Los contenedores también manejan los servicios no-configurables como los :  Beans empresariales  Ciclo de vida de los servlets  Pool de conexiones a bases de datos  Persistencia de datos  Acceso a las APIS de la plataforma Java EE
    8. 8.  Servidor EE y contenedores
    9. 9.  Java EE Server  Proporciona contenedores Web y EJB  EJB Container  Administra la ejecución de los beans empresariales para aplicaciones Java EE  Web Container  Administra la ejecución de los servlets y las JSP para aplicaciones Java EE  Application client Container  Administra la ejecución de los componentes de la aplicación cliente (en el cliente)  Applet Container  Administra la ejecución de los applets, consiste en un navegador con el plug-in de Java
    10. 10.  APIs de la plataforma J2EE
    11. 11. Aplicaciones distribuidas Multicapa Emmerson Miranda SCJP 1.5 SCWCD J2EE 1.5 Blog : http://emmersonmiranda.blogspot.com/
    12. 12.  La plataforma Java EE usa el modelo de aplicaciones distribuidas multicapa para las aplicaciones empresariales.  La lógica de la aplicación se divide en capas según su función.  Descomposición de las capas:  Client tier .- Se ejecuta en la maquina del cliente  Web tier .- Se ejecuta en el servidor JEE  Business tier .- Se ejecuta en el servidor JEE  EIS(Enterprise Information System) tier.- Software que se ejecuta en el servidor EIS
    13. 13.  Los clientes se pueden comunicar con la capa de negocio, directa o indirectamente
    14. 14.  La capa Enterprise Information System maneja el software EIS e incluye la infraestructura del sistema como:  Enterprise resource planning (ERP)  Proceso de transacciones mainframe  Sistemas de bases de datos  Otros sistemas de información heredados.
    15. 15. Beans empresariales Emmerson Miranda SCJP 1.5 SCWCD J2EE 1.5 Blog : http://emmersonmiranda.blogspot.com/
    16. 16.  Simplifican el desarrollo de aplicaciones distribuidas extensas.  Los desarrolladores se pueden centrar únicamente en desarrollar los requerimientos funcionales, ya que el contenedor le proporciona acceso a los servicios de bajo nivel(transacciones, autorización …).  Ya que se centran en la lógica de negocio, los desarrolladores del lado cliente se pueden centrar únicamente en la presentación del cliente (olvidándose por ejemplo de los accesos a las bases de datos o reglas de negocio)  Ya que los EJB son componentes portables, el que compone o ensambla la aplicación puede construir nuevas aplicaciones utilizando los bean existentes. Estas aplicaciones se pueden ejecutar en cualquier servidor compatible, siempre y cuando se utilice el API estándar.
    17. 17.  Se puede empezar a considerar el uso de EJBs en una aplicación si esta tiene alguno de los siguientes requerimientos:  La aplicación necesita ser escalable, para soportar un numero creciente de usuarios y así poder distribuir los componentes entre múltiples maquinas y cuya localización sea transparente para los clientes.  Asegurar la integridad de los datos utilizando transacciones  La aplicación puede tener una variedad de clientes; con solo unas pocas líneas de código los clientes remotos pueden localizar fácilmente los beans empresariales.
    18. 18.  Representa un cliente simple dentro del servidor de aplicaciones; para acceder a una aplicación desplegada en un servidor, el cliente invoca los métodos de un bean de session.  Son creados por un cliente y usualmente existe solo durante la duración de una session cliente-servidor.  Pueden ser transaccionales, pero no son persistentes (sus datos no se guardan en una base de datos), por tanto si el sistema falla sus datos se pierden.  Son de dos tipos; stateful y stateless  Cuando el cliente termina los bean de sesion terminan.
    19. 19.  El estado de un objeto es o esta compuesto por los valores de sus variables de instancia.  En un stateful, las variables de instancia representan el estado de un bean durante una session de un cliente.  El estado del bean se mantiene entre las distintas invocaciones de sus métodos (cada stateful se asocia a un solo cliente).  Debido a que el cliente interactúa con su bean, su estado se suele llamar “conversational state”  Cuando el cliente elimina el bean o termina, el bean finaliza y su estado se pierde.
    20. 20.  No mantiene el “conversational state” con el cliente.  Cuando un cliente invoca los métodos de un bean stateless, el estado de las variables de instancia del bean se mantiene solo durante la duración de la ejecución del método  Los clientes pueden cambiar los estados de los beans stateless que se encuentran en el pool, utilizándose en la siguiente invocación del bean.  Todas las instancias de los beans stateless son equivalentes, permitiendo así al contenedor EJB asignar una instancia a cualquier cliente, es decir, el estado de un stateless se puede aplicar a todos los clientes..
    21. 21.  Debido a que pueden soportar un amplio número de clientes, ofrece mejor escalabilidad para aplicaciones con un amplio número de clientes.  Pueden implementar web services, pero los otros tipos de EJB no.
    22. 22.  Si en cualquier momento solo un cliente a de acceder a una determinada instancia de un bean.  El estado del bean no ha de ser persistente, existiendo solo durante un periodo corto de tiempo.  El bean implementa un web service.
    23. 23.  Los beans stateful son apropiados si se cumple una de las siguientes condiciones:  El estado del bean representa la interacción entre el bean y un cliente concreto.  El bean necesita almacenar información entre las distintas invocaciones de métodos  El bean media entre el cliente y otros componentes de la aplicación, dando una vista simplificada al cliente.  Detrás de escena, el bean maneja el flujo de trabajo de muchos beans empresariales.
    24. 24.  Para mejorar el rendimiento, se pueden elegir beans stateless si:  El estado del bean no tiene información para un cliente específico.  En una sola invocación de un método, el bean realiza tareas genéricas para todos los clientes (Ejemplo: enviar un mail de confirmación de pedidos)
    25. 25.  Es un bean empresarial que permiten procesar mensajes asíncronamente.  Normalmente actual como un escuchador de mensajes (Message Listener)  Los mensajes pueden ser enviados por cualquier componente Java EE  Aplicación cliente  Otro bean empresarial  Componente web  Aplicación JMS  Sistemas que no utilizan la tecnología Java EE  Pueden procesar mensajes JMS o de otro tipo
    26. 26.  Sus variables de instancia pueden mantener el estado durante el proceso de los mensajes de los clientes (por ejemplo una conexión a base de datos, un objeto de referencia a otro EJB, etc.)  Los clientes no pueden invocarlos directamente, la única forma que tienen de contactar con ellos es enviando mensajes a las colas a las cuales están escuchando.  Cada vez que llega un mensaje, el contenedor invoca el método onMessage del MDB para procesarlo. El método onMessage puede utilizar métodos helper o invocar beans de session para procesar la información y/o almacenarla en la bbdd.  Un mensaje puede ser entregado en el contexto de una transacción, así si esta es cancelada, el mensaje es nuevamente re-entregado.
    27. 27.  Se ejecutan cada vez que se recibe un mensaje  Son invocados asíncronamente  Relativamente tienen una vida corta  No representan datos de la base de datos, pero pueden acceder y modificarlos.  Son Stateless
    28. 28.  Los clientes no pueden acceder a los MDBs utilizando interfaces.  Los MDB solo tienen una clase a diferencia de los beans de Session  Parecidos entre los MDB y los beans de Session :  Los MDB no almacenan información, ni estado conversacional con clientes específicos  Todas las instancias de los MDB son equivalentes, siendo el contenedor EJB el que asigna un mensaje a cualquier instancia MDB.  Un MDB puede procesar mensajes de múltiples clientes
    29. 29.  Los beans de session permiten enviar mensajes JMS de manera síncrona, pero no asíncrona.  Para recibir mensajes asíncronamente hay que usar MDBs
    30. 30.  Son representaciones explícitas de datos o colecciones de estos, tales como filas de bases de datos.  Son persistentes y duran lo mismo que los datos en una base de datos.  La clave primaria identifica una única instancia  Son transaccionales y recuperables si el sistema falla.  Desde EJB 3.0 los beans de entidad son POJOs (Plain Old Java Objects) y soportan
    31. 31.  Utilizan anotaciones de Java incluso para su mapeo relacional  Soportan herencia y polimorfismo  Tienen un modelo simple de persistencia para las operaciones CRUD usando el EntityManager.  Capacidad de consultas mejora.
    32. 32.  Utilizar entity beans si los datos se han de guardar en algún almacén de datos, estos pueden ser consultados y actualizados por múltiples usuarios.
    33. 33.  Ya que un EJB esta compuesto de muchas partes, se usan las siguientes convenciones de nombres para las aplicaciones. Parte Sintaxis Ejemplo Enterprise bean name nombreBean CalculadoraBean Enterprise bean class nombreBean CalculadoraBean Business interface nombre Calculadora
    34. 34.  Las siguientes anotaciones pueden ser usadas en EJB 3.0 Anotación Descripción @Stateless Marca un bean como stateless @Stateful Marca un bean como stateful @MessageDriver Marca un bean como MDB @PostConstruct, @PreDestroy, @PostActivate, @PrePassivate Marcan los métodos dentro del bean, permitiendo asociarlos a su ciclo de vida. @RolesAllowed, @PermitAll, @DenyAll Declara permisos a nivel de métodos
    35. 35.  Las siguientes anotaciones pueden ser usadas en EJB 3.0 Anotación Descripción @RunAs Indica la identidad principal con la que se ejecutará el método @Timeout Indica el tiempo máximo de ejecución de un método @TransactionAttribute Aplica un atributo que indica el tipo de transacción que se aplica a una interfaz o métodos individuales en la clase del bean @TransactionManagement Indica si el bean será CMP o BMP @Resource Permite la inyección de recursos (SessionContext, DataSource, QueueConnectionFactory, Queue …)
    36. 36.  Las siguientes anotaciones pueden ser usadas en EJB 3.0 Anotación Descripción @EJB Usado por los clientes para hacer referencia a las interfaces de negocio de un EJB @PersistenceContext Usado para inyectar un EntityManager @PersistenceUnit Usado para inyectar un EntityManagerFactory @Entity Marca una clase como una Entity bean. @Table Especifica la tabla primaria del Entity bean @Column Asocia una propiedad con una columna @Id Especifica la clave primaria de una entidad
    37. 37.  Las siguientes anotaciones pueden ser usadas en EJB 3.0 Anotación Descripción @ManyToOne Define la relación many-to-one con otros beans @ManyToMany Define la relación many-to-many con otros beans @OneToMany Define la relación one-to-many con otros beans @OneToOne Define la relación one-to-one con otros beans @JoinColumn Define una asociacion con otra entidad @SecundaryTable Permite especificar una tabla secundaria, para indicar que los datos de la entidad se pueden almacenar en diferentes tablas.
    38. 38. Acceso a los EJB Emmerson Miranda SCJP 1.5 SCWCD J2EE 1.5 Blog : http://emmersonmiranda.blogspot.com/
    39. 39.  Los MDB no disponen de interfaces de acceso para clientes.  El acceso de los clientes puede local, remoto o web service.  Los clientes solo pueden acceder a los métodos del EJB que están definidos en sus interfaces de negocio (estos actúan como vistas del bean).  El resto de detalles no son visibles para los clientes  Un buen diseño basado en interfaces simplifica el desarrollo y mantenimiento de las aplicaciones Java EE.  Protegen de los cambios de implementación y de las complejidades propias de la capa de los EJB
    40. 40.  Se pueden ejecutar en maquina distinta y distinta JMV que el EJB al cual accede.  Puede ser un cliente web, una aplicación de escritorio u otro EJB.  La localización del EJB es transparente.  La interfaz remota de un EJB define los métodos accesibles para un bean.
    41. 41.  Para que un EJB permita acceso remoto  la interfaz que implementa tiene que tener la anotación @Remote @Remote public interface InterfaceName { ... }  O también utilizar @Remote en el bean @Remote(InterfaceName.class) public class BeanName implements InterfaceName { ... }
    42. 42.  Deben ejecutarse en la misma JVM que el EJB al cual se accede.  Puede ser un componente web u otro EJB.  Para un cliente local, la localización del bean no es transparente.  La interfaz local de un EJB define los métodos accesibles para un bean.  Todas las interfaces de negocio son por defecto local
    43. 43.  Para que un EJB permita acceso local  la interfaz que implementa tiene que tener la anotación @Local @Local public interface InterfaceName { ... }  O también utilizar @Local en el bean @Local(InterfaceName.class) public class BeanName implements InterfaceName { ... }
    44. 44.  Rendimiento  A causa de la latencia de red los EJB locales son mas rápidos que los remotos.  Si los componentes se distribuirán entre diferentes servidores, el EJB debe ser remoto, pudiendo mejorar el rendimiento de las aplicaciones  Distribución de los componentes  En una aplicación distribuida, los componentes web pueden ejecutarse en diferentes servidores los cuales deben acceder a los EJB, para este caso los beans empresariales deben permitir acceso remoto.
    45. 45.  Tipos de cliente  Si el EJB será accedido por diversos tipos de aplicaciones, debe permitir acceso remoto.  Si los clientes son componentes Web o EJBs, el acceso depende del tipo de distribución que se decida dar a los componentes.  Acoplamiento fuerte o pobre de los beans relacionados  En caso de acoplamiento fuerte el acceso local es un buen candidato, ya que da mejor rendimiento.
    46. 46.  Un cliente ws puede acceder a una aplicación JEE de dos formas:  Web Services creados con JAX-WS  Pueden invocar métodos de beans stateless (los MDB no)  Cualquier cliente ws puede acceder a un bean stateless, independientemente del lenguaje en el que se implemente (el cliente).  Tanto los EJB y los componentes web pueden ser clientes de ws  Por defecto todos los métodos del bean son accesibles, excepto si alguno de ellos lleva la anotación @WebMethod, en cuyo caso dejan de serlo (es decir solo serán accesibles aquellos que tengan dicha anotación)
    47. 47.  Los parámetros de las llamadas remotas son mas aislados que los de las llamadas locales.  En las llamadas remotas, el cliente y el bean utilizan copias distintas del objeto pasado por parámetro (por tanto un cambio en cualquiera de las partes no afecta a la otra).  Protege los datos del bean si el cliente modifica accidentalmente los datos.  En las llamadas locales, el cliente y el bean utilizan la misma copia.  Al igual que en las llamadas remotas, los clientes de ws trabajan con copias diferentes de los parámetros.
    48. 48. Composición Emmerson Miranda SCJP 1.5 SCWCD J2EE 1.5 Blog : http://emmersonmiranda.blogspot.com/ - Mail
    49. 49.  Un EJB esta compuesto de:  Enterprise bean class .- Es la clase que implementa los métodos de negocio definidos en las interfaces y los métodos que involucran al ciclo de vida de los ejb.  Business interfaces .- Define los métodos que el bean empresarial necesita implementar (@Local, @Remote)  Helper clases .- Otro tipo de clases que utiliza el EJB, como por ejemplo excepciones y clases de utilidad.  Descriptor de despliegue XML (opcional), los cuales pueden sobre escribir los metadatos definidos con las anotaciones de la clase del bean.
    50. 50.  Los ficheros que componen un EJB pueden ser ensamblados en un fichero .jar; el cual es portable y se pueden usar en diferentes aplicaciones.
    51. 51. Ciclos de vida Emmerson Miranda SCJP 1.5 SCWCD J2EE 1.5 Blog : http://emmersonmiranda.blogspot.com/
    52. 52.  Cada tipo de bean empresarial tiene un ciclo de vida diferente  Activation / Passivation  Técnica mediante la cual el contenedor EJB puede elegir serializar temporalmente un bean y almacenarlo en el sistema de ficheros del servidor de aplicaciones u otro sistema de persistencia, para poder posteriormente volver a recrear el estado del bean.  Esta técnica permite un óptimo manejo de recursos para la aplicación.
    53. 53.  El cliente inicia el ciclo de vida al obtener una referencia al bean  El contenedor realiza la inyección de dependencia  El contenedor invoca el método @PostConstruct si lo hubiera.  A partir de este punto el bean esta listo para que el cliente pueda invocar los métodos de negocio.  El contendor puede decidir si “deactivate” o “passivate” el bean.  El método @PrePassivate, es llamado antes que sea almacenado en el almacén persistente
    54. 54.     Cuando el cliente invoca un método de negocio de un bean que esta en estado “passive” ,el contenedor activa el bean llamando al método @PostActivate si lo hubiera.  Al final del ciclo de vida el cliente invoca el método @Remove, y el contenedor llama al método @PreDestroy si lo hubiera.  La instancia queda lista para el recolector de basura
    55. 55.  El cliente inicia el ciclo de vida al obtener una referencia al bean  El contenedor realiza la inyección de dependencia  El contenedor invoca el método @PostConstruct si lo hubiera.  A partir de este punto el bean esta listo para que el cliente pueda invocar los métodos de negocio (no se puede serializar).  Cuando el cliente se desconecta la session, el contenedor invoca el método @PreDestroy si lo hubiera.  La instancia queda lista para el recolector de basura
    56. 56.  El contenedor crea un conjunto de instancias y los almacena en el pool, cada una de las instancias realiza las siguientes tareas:  Si el MDB usa inyección de dependencia, el contenedor inyecta las referencias  El contendor invoca el método @PostConstuct si lo hubiera.  Cuando llega un mensaje el contenedor recoge una instancia del pool e invoca su método onMessage pasandole el mensaje como parámetro.  Al finalizar la vida del MDB el contenedor llama al método @PreDestroy si lo hubiera.  La instancia queda lista para el recolector de basura
    57. 57.  http://jcp.org/en/jsr/detail?id=220  Enterprise JavaBeans 3.0 Final Release  ejbcore .- ejb-3_0-fr-spec-ejbcore.pdf  Persistence .- ejb-3_0-fr-spec-persistence.pdf  Simplified.- ejb-3_0-fr-spec-simplified.pdf
    58. 58. Dudas y preguntas

    ×