Your SlideShare is downloading. ×
01 jee5-componentes
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

01 jee5-componentes

101

Published on

jee components

jee components

Published in: Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
101
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. •COMPONENTES
  • 2. ÍNDICE • Bloque I: Introducción a JEE / PRÁCTICAS − PARTE I: Visión General • Definiciones • Componentes de JEE − − − Aplicaciones clientes y applets Java Servlets, JavaServer Pages y JavaServer Faces Enterprise Java Beans − Parte II: Desarrollo fácil de Enterprise Applications (EA) • Empaquetado de aplicaciones JEE5 • Líneas de desarrollo de software EJB − − − Stateless Session Beans Stateful Session Beans Message Driven Beans • EJB2.1 vs EJB3 • Java Persistence API (entities)
  • 3. BLOQUE I Introducción a J2EE: PARTE I - Visión General
  • 4. ENTORNO • Preparando el entorno (I) − Instalación del SDK y App. Server Bundle (trae a Netbeans incluído). Instalar Netbeans y el APP Server en c:Sun − Crear directorio c:temp y c:CursoSOA − Cambiar la variable entorno TMP de %SystemRoot%TEMP o al valor c:temp − Cambiar el valor de la variable de usuario TMP a c:temp • Sirve para evitar un bug de Application Server y glassfish, conocida como el bug multibyte. En la versión más reciente del IDE esto no ocurre, pero no usaremos la última versión. − Usar el script setenv.bat para crear las variables de entorno que contiene. − Instalar el paquete unxutils.
  • 5. ENTORNO • Preparando el entorno (II) − Añadir al path estos directorios: • App-server-install-dirbin • App-server-install-dirlibantbin − Por último… − Copiamos el archivo 03-librerias externas en netb-ide7modules-ext.zip a un directorio temporal y extraemos su contenido. − Copiamos todas las librerías que aparezcan a: • %Netbeans-install-dir%Sunnetbeans-5.5.1ide7modulesext
  • 6. ENTORNO • Preparando el entorno (III) − Hacer algunos cambios para que AXIS funcione en Application Server: − Editamos el fichero: C:SunAppServerdomainsdomain1configserver.policy • Le agregamos al final, estas líneas: grant codeBase INF/lib/-" { permission permission permission permission }; "file:C:/Sun/AppServer/domains/domain1/server/applications/j2ee-modules/axis/WEBjava.lang.RuntimePermission "getClassLoader"; java.lang.RuntimePermission "createClassLoader"; java.net.SocketPermission "*", "connect,accept,resolve"; java.io.FilePermission "<>", "read,write,delete";
  • 7. Visión general • Java ha sufrido una evolución que prácticamente ha tomado vida propia. • Diseñado originalmente para controlar dispositivos electrónicos, hoy es el lenguaje preferido para aplicaciones empresariales basadas en la web • Tres ediciones de Java » » » J2SE (Java 2 Standard Edition): Contiene las API's para construir una aplicación Java o un applet. J2ME (Java 2 Mobile Edition): API's para aplicaciones inalámbricas o dispositivos pequeños (teléfonos móviles, PDA's, etc. con prestaciones reducidas) J2EE (Java 2 Enterprise Edition): API's para crear aplicaciones para arquitecturas multicapa.
  • 8. Visión general • JEE simplifica la creación de aplicaciones empresariales, ya que la funcionalidad se encapsula en los componentes de JEE • JEE es una tecnología versátil, ya que los componentes se comunican entre sí mediante métodos estándar como HTTP, SSL, XML, RMI e IIOP. • El diseño multicapa JEE frente a otras alternativas, garantiza que si se efectúan cambios en la lógica de negocio, no es necesario reconstruir TODA la aplicación, y reinstalarla en todos los clientes.
  • 9. Visión general
  • 10. Visión general • Modelo: encapsula la lógica o funcionalidad de negocio. − Ejemplo: en una aplicación bancaria, el modelo es el conjunto de clases que nos permiten crear y destruir cuentas, hacer transferencias, etc. El modelo debería ser reusable con otras GUI • Problema − − − Un cambio en la implementación del modelo implica recompilación de toda la aplicación y reinstalación en los clientes. » Cambios de drivers de acceso a BD Cambio en la lógica del modelo Cambio de fabricante de BD • Solución: − − Modelo en servidor intermedio » Un cambio en la implementación del modelo sólo afecta al servidor. Clientes standalone » Sólo disponen de la interfaz gráfica » Acceden al servidor que implementa el modelo.
  • 11. Visión general
  • 12. BLOQUE I: Definiciones
  • 13. Definiciones • JEE: es una especificación para implementar aplicaciones de arquitectura multicapa de tipo empresarial y aplicaciones basadas en la Web. • Componente JEE: Es una unidad de software funcional autocontenida que se ensambla dentro de una aplicación JEE con sus clases de ayuda y ficheros y que se comunica con otros componentes. La especificación JEE define los siguientes componentes: − Las aplicaciones clientes y los applets son componentes que se ejecutan en el lado del cliente. − Los componentes java servlet y los JSP's son componentes web que se ejecutan en el lado del servidor − Los Enterprise Java Beans (EJB) son componentes de negocio que se ejecutan en el servidor de aplicación, destinados al desarrollo y despliegue de aplicaciones empresariales.
  • 14. Definiciones • Componente Web: Pueden ser servlets o páginas creadas con la tecnología JSP y/o JavaServer Faces. JavaServerFaces se construye sobre servlets y páginas JSP y proporciona un framework de interfaz de usuario para aplicaciones web. • Aplicación cliente: Se ejecuta en una máquina cliente y proporciona un medio para que los usuarios lleven a cabo un GUI más rico que el que puede proporcionarse por un lenguaje de marcas (HTML, etc). • Cliente JEE: Puede ser un cliente web (navegador) o una aplicación cliente.. • Cliente web: Consiste de dos partes: − Páginas dinámicas generadas por componentes web de la capa web − Navegador web, que presenta las páginas recibidas del servidor.
  • 15. Definiciones • Contenedor: es un interfaz entre un componente y la funcionalidad específica de bajo nivel que da soporte al componente. Antes de que se ejecute un componente web, enterprise bean, o componente cliente de aplicación, debe ensamblarse en un módulo JEE y disponerse dentro de un contenedor. CONTENEDOR = SERVIDOR − Contenedor web = contenedor servlet + contenedor JSP • Servidor de aplicaciones: Servidor en red que facilita o proporciona a los clientes aplicaciones software. − Serv. aplicaciones = contenedor web + contenedor EJB
  • 16. Definiciones • Servlet: Es un programa Java capaz de procesar datos, y generar una respuesta utilizando HTTP, y que es ejecutado a través de un navegador. • JSP (Java Server Pages): Es una página en formato HTML que contiene código Java encerrado entre etiquetas especiales, y que se convierte en servlet la primera vez que se ejecuta. • Applet: Es una pequeña aplicación cliente escrita en Java que se ejecuta la la JVM del navegador.
  • 17. Definiciones • ¿Qué es un Java Bean? − componente software que pueden encapsular una funcionalidad por sí mismo y ofrecerla allí donde sea necesario independientemente del tipo de aplicación que se esté programando. − Por ejemplo, un Java Bean puede ser una clase Java que agrupe funcionalidades y propiedades utilizadas en una aplicación WEB y poder utilizarse desde una página JSP • Conseguiríamos así separar: − LÓGICA DE APLICACIÓN − ASPECTO
  • 18. Definiciones • Diferencia entre JavaBean y EJB: − Basados en los paquetes JavaBeans y javax.ejb respectivamente. − Los primeros interactúan entre ellos SÓLO dentro del mismo espacio de nombres, mientras que los segundos interactúan con otros componentes que pueden pertenecer a otro espacio de nombres como objetos distribuidos. − JavaBeans es una interfaz de SUN para construir aplicaciones reutilizables; permite construir bloques que pueden usarse de forma separada o en conjunción con otros, y se pueden utilizar en la capa de cliente, mientras que los componentes EJB sólo se utilizan en la capa de negocio, y pueden servir para comunicación entre los componentes del servidor y una base de datos.
  • 19. Definiciones • Componentes de negocio (Business Components): El código de negocio, que es la lógica que resuelve o cumple las necesidades de un negocio particular, como la banca, la venta, o la financiación, se maneja mediante enterprise beans que se ejecutan en la capa de negocio (business tier). Representa el medio de comunicarnos con lo que conocemos como el modelo de datos. • Tipos de EJB: − Beans de sesión: representa una conversación temporal con un cliente. Cuando el cliente finaliza su ejecución, el bean de sesión y sus datos desaparecen. − Java Persistence API / Beans de entidad: representa datos persistentes almacenados en una fila de una tabla/relación de una base de datos. Si el cliente termina o si se apaga el servidor, los servicios subyacentes de aseguran de grabar el bean. • La nueva Java Persistence API ha simplificado la persistencia de los entity beans. Los nuevos entity objects son POJOs que proporcionan una vista orientada a objetos de los datos almacenados en una base de datos. − Beans dirigidos por mensajes: combina las características de un bean de sesión y de un oyente de Java Message Service (JMS), permitiendo que un componente de negocio reciba asíncronamente mensajes JMS. • Capa del sistema de información empresarial (EIS –Enterprise Information System tier-): La capa del sistema de información empresarial maneja el software del sistema de información empresarial como ERP's, BD, etc. Las aplicaciones J2EE pueden necesitar acceder a estas aplicaciones, pEj. para acceder a sus BD.
  • 20. Definiciones • Empaquetado: Para desplegar una aplicación JEE, se empaquetan los componentes en ficheros especiales que contienen los ficheros de las clases relevantes y los descriptores de despliegue XML − Estos descriptores de despliegue contienen información específica de componentes empaquetados y son un mecanismo para configurar el comportamiento de la aplicación en el momento del ensamble o del despliegue. • Estos se empaquetan en diferentes tipos de archivos según los distintos componentes. − Los componentes Web se empaquetan en un archivo Web (.war) que contiene los servlets, las páginas JSP y los componentes estáticos como las páginas HTML y las imágenes. • El fichero .war contiene clases y ficheros utilizados en la capa Web junto con un descriptor de despliegue (no siempre). − Los componentes de negocio se empaquetan en un archivo Java (.jar) que contiene los descriptores de despliegue EJB (no siempre), los ficheros de interfaz remoto junto con los ficheros de ayuda requeridos por el componente EJB. − Los ficheros de clases del lado del cliente se empaquetan en un fichero Java (.jar). − Una aplicación JEE se empaqueta en un archivo enterprise (.ear) que contiene toda la aplicación junto con el descriptor de despliegue (no siempre) que proporciona información sobre la aplicación y todos sus componentes.
  • 21. Arquitectura multicapa visión detallada (I) • Arquitecura multicapa J2EE
  • 22. Arquitectura multicapa: visión detallada (II)
  • 23. Comunicación entre componentes Web
  • 24. Comunicación entre componentes de negocio
  • 25. Definiciones • Ejemplo de arquitectura JEE Capa de Interfaz de Usuario Cliente Cliente (HTML, (HTML, JavaScript, JavaScript, Applets, Applets, PDF, etc) PDF, etc) (MSIE, NSN, (MSIE, NSN, Java PlugIn Java PlugIn Acrobat Acrobat Reader) Reader) Petición HTTP Respuesta HTTP (HTML+ JavaScript PDF, ZIP, etc.) Servidor Servidor Web Web Contenedor Servlets /JSP (Apache) (Apache) (Sun App. Serv, Glassfish, Tomcat…) Capa de Lógica Capa de Datos Contenedor EJBs (Sun App Serv, Glassfish, JBoss, …) Base de Datos Base de Datos (Oracle) (Oracle) Clases, JavaBeans, SQLJs sobre una JVM (Sun App. S., Glassfish…)
  • 26. Empaquetado
  • 27. Visión de Arquitectura distribuida J2EE • Las referencias de objetos se obtienen buscando un objeto por su nombre notificado, una vez encontrado, se obtiene la referencia, y se llevan a cabo las operaciones necesarias sobre ese objeto utilizando los servicios del host. Un objeto remoto notifica su disponibilidad en el servicio de nombres utilizando un nombre lógico y el servicio de nombres lo traduce a la localización física del objeto en el entorno J2EE. Ahora, en EE5, estas referencias pueden resolverse automáticamente por el contenedor si usamos annotations.
  • 28. JNDI • JNDI (Java Naming Directory Interface): es un API que permite acceder a servicios de directorio utilizando tecnología Java.
  • 29. Bloque I. Parte II. Contenido Desarrollo fácil de Enterprise Applications (EA) Empaquetado de aplicaciones JEE5 Líneas de desarrollo de software EJB Stateless Session Beans Stateful Session Beans Message Driven Beans EJB2.1 vs EJB3 Java Persistence API (entities)
  • 30. Desarrollo fácil de EAs • JEE5 elimina gran parte de tareas engorrosas necesarias en modelos Java anteriores. • Con JEE5, los descriptores de despliegue XML son ahora opcionales. • En lugar de ello, empleamos Annotations (anotaciones, también llamados metadatos) directamente en un POJO, dentro del código fuente en el que estemos trabajando. • Se reconocen porque empiezan por @
  • 31. Desarrollo fácil de EAs • Las anotaciones se usan para incrustar datos en un programa que de otra forma tendrían que ser proporcionados en un fichero por separado. • JEE5 proporciona anotaciones para estas tareas: − Definir y usar Web Services − Desarrollar aplicaciones EJB − Mapeo de clases Java a XML − Mapeo de clases Java a Bases de Datos − Mapeo de métodos a operaciones − Especificación de dependencias externas − Especificación de información de despliegue, incluyendo seguridad.
  • 32. Desarrollo fácil de EAs • Algunos beneficios inmediatos de JEE5 − Ya no son necesarios los marcadores: • extends java.rmi.Remote • throws java.rmi.RemoteException − Ya no es necesario que exista un fichero application.xml en un paquete que contenga una aplicación JEE5; el servidor determina el tipo de cada módulo examinando el contenido del paquete. − Ya no es necesario incluir un fichero de MANIFEST en los paquetes de librerías .JAR
  • 33. Empaquetado en JEE5 • Empaquetado de aplicaciones JEE5 − Las aplicaciones web usan: .WAR − Los ficheros .RAR son Resource Adapters − El directorio lib contiene ficheros compartidos .JAR − Un fichero .JAR con Main-Class se considera una aplicación cliente − Un fichero .JAR con la anotación @stateless es considerada una aplicación EJB
  • 34. Empaquetado en JEE5 • Aplicaciones que ya no requieren descriptores de despliegue: − Aplicaciones EJB (.JAR) − Aplicaciones web exclusivamente JSP − Aplicaciones clientes (.JAR) − Enterprise Applications (.EAR)
  • 35. Líneas de desarrollo EJB • ¿Qué es un Enterprise Bean? − Es un componente del extremo del servidor que encapsula la lógica de negocio de una aplicación. La Lógica de negocio es el código que cumplimenta el propósito de la aplicación. − Ejemplo: en una aplicación de control de inventario, el enterprise bean podría implementar la lógica de negocio de métodos que se llamasen compruebaNivelInventario o por ejemplo solicitaProducto. Invocando a estos métodos, los clientes remotos podrían acceder a los servicios de inventario proporcionados por la aplicación.
  • 36. Líneas de desarrollo EJB • Beneficios de EJB − Simplifican el desarrollo de aplicaciones grandes y/o distribuídas. Razones: • El contenedor proporciona servicios a nivel de sistema a los enterpise beans, por lo que el desarrollador puede dedicarse a resolver problemas de negocio. Ejemplo de esos servicios: la gestión de transacciones y las autorizaciones de seguridad. • Como los EJBs (y no los clientes) contienen la lógica de negocio de la aplicación, el programador de la capa cliente, puede dedicarse a mejorar la presentación hacia el cliente. Esto permite construir clientes ligeros, lo cual es especialmente interesante para dispositivos móviles. • Al ser los EJBs componentes portables, pueden construirse nuevas aplicaciones ensamblando Beans existentes.
  • 37. Líneas de desarrollo EJB • ¿Cuándo debemos usar EJBs? − Cuando la aplicación deba ser escalable.- Si el número de usuarios de la aplicación puede ser elevado, cabe la posibilidad de tener que distribuir los componentes de la aplicación entre múltiples máquinas. No sólo pueden ejecutarse EJBs en diferentes máquinas, sino que además, su localización es transparente a los clientes. − Cuando las transacciones deban asegurar integridad de datos: Los enterprise beans soportan transacciones, que son los mecanismos que administran los accesos concurrentes de objetos compartidos. − Cuando la aplicación tenga clientes de tipos variados: Con pocas líneas de código, cualquier cliente remoto puede localizar enterprise beans.
  • 38. Líneas de desarrollo EJB • La API EJB 3.0 se ha simplificado muchísimo; Beneficios de la nueva API EJB 3.0 − Se requieren menos clases e interfaces: El EJB Home ya no se necesita − − − − y ya no hay que implementar el interfaz javax.ejb.SessionBean para codificar un bean de sesión. Descriptores de despliegue opcionales: Uso de anotaciones. Búsquedas simples: Ya no se necesitan las APIs JNDI (Java Naming and Directoy Interface) ni en el servidor ni en el cliente. Se ha añadido un método de búsqueda en el interfaz EJBContext, permitiendo buscar un objeto dinámicamente dentro del espacio de nombres JNDI. Persistencia ligera y simplificada para el mapeo de objetos relacionales: la nueva Java Persistence API ha simplificado la persistencia de los entity beans. Los nuevos entity objects son POJOs que proporcionan una vista orientada a objetos de los datos almacenados en una base de datos. Interceptors: Son objetos que se usan para interceptar una llamada a un business method.
  • 39. Líneas de desarrollo EJB • Algunas annotations que pueden usarse en desarrollo de software EJB: − @Stateless, @Stateful. Para indicar si es un componente bean de sesión stateless o stateful − @PostConstruct, @PreDestroy, @PostActivate, @PrePassivate. Indicación un método como de − − − − − − − − − − − − * event callback * @EJB. Usado en un cliente JEE para referenciar instancias de Enterprise Beans. @PersistenceUnit. Se usa para expresar una dependencia de un EntityManagerFactory. @PersistenceContext. Se usa para expresar una dependencia de un EntityManager. @WebServiceRef. Se usa en un cliente para referenciar web services. @Resource. Para todos los demás recursos no cubiertos por @EJB o @WebServiceRef @Timeout. Especifica un método timeout sobre un componente que use servicios de temporizador (container-managed timer services). @MessageDriven. Especifica un bean message-driven. Un bean message-driven es un consumidor de mensajes que puede ser llamado por su contenedor. @TransactionAttribute. Aplica un atributo transaction a todos los métodos de un interfaz de negocio o a métodos de negocio individuales de un bean @TransactionManagement. Declara si un bean tendrá transacciones container-managed o bean-managed (controladas por contenedor o por bean). @RolesAllowed, @PermitAll, and @DenyAll. Permisos de métodos. @RolesReferenced. Declara roles de seguridad referenciados en el código del bean @RunAs. Usa un rol de seguridad especificado para ejecutar un método. Listeners o callback methods son métodos destinados a recibir invocaciones de proveedores de persistencia a varios niveles del ciclo de vida de la entidad (@Prepersist, @Postload, @Postpersist).
  • 40. Líneas de desarrollo EJB : EJB 2.1 Vs EJB 3.0 • Características EJB 2.1 − Muy potente, pero complejo de usar − Demasiadas clases e interfaces. − Java Naming an Directory Interface (JNDI) para búsquedas. − Interfaces Javax.ejb − Descriptores de despliegue − Modelo de programación complicado y pesado − Incremento de costes ….. …..
  • 41. Líneas de desarrollo EJB : EJB 2.1 Vs EJB 3.0 • Desarrollo simplificado con EJB 3.0 − La tecnología EJB es ahora más sencilla de aprender y usar. − Menor número de clases e interfaces − Inyección de dependencias (dependency injection) − Búsquedas simples − No se requieren interfaces de contenedor − No se requieren descriptores de despliegue − Persistencia simplificada − Mapeo objeto/relacional − Incremento de la productividad del programador.
  • 42. Líneas de desarrollo EJB : EJB 2.1 Vs EJB 3.0 • La mejor forma de comprobar los beneficios de JEE5 respecto de J2EE en la línea de desarrollo EJB puede ser mediante ejemplos. Sigamos con más ejemplos incrementando el nivel de detalle. • El ejemplo 1, muestra el código fuente de una aplicación que use un hipotético session bean usando la API EJB 2.1. • El ejemplo 2, muestra el código equivalente usando la API EJB 3.0, resaltando en negrita las nuevas características.
  • 43. Líneas de desarrollo EJB : EJB 2.1 Vs EJB 3.0 • Ejemplo EJB 2.1 public class PayrollBean implements javax.ejb.SessionBean { SessionContext ctx; DataSource empDB; public void setSessionContext(SessionContext ctx) { this.ctx = ctx; } public void ejbCreate() { Context initialContext = new InitialContext(); empDB = (DataSource)initialContext.lookup(“java:comp/env/jdbc/empDB”); } } public void ejbActivate() {} public void ejbPassivate() {} public void ejbRemove() {} public void setBenefitsDeduction (int empId, double deduction) { ... Connection conn = empDB.getConnection(); } ... // **** * Y ADEMÁS, ES NECESARIO UN DESCRIPTOR DE DESPLIEGUE * ***
  • 44. Líneas de desarrollo EJB : EJB 2.1 Vs EJB 3.0 • Ejemplo EJB 2.1: Descriptor ejb-jar.xml necesario: <session> <ejb-name>PayrollBean</ejb-name> <local-home>PayrollHome</local-home> <local>Payroll</local> <ejb-class>com.example.PayrollBean</ejb-class> <session-type>Stateless</session-type> <transaction-type>Container</transaction-type> <resource-ref> <res-ref-name>jdbc/empDB</res-ref-name> <res-ref-type>javax.sql.DataSource</res-ref-type> <res-auth>Container</res-auth> </resource-ref> </session> ... <assembly-descriptor> ... </assembly-descriptor>
  • 45. Líneas de desarrollo EJB :EJB 2.1 Vs EJB 3.0 • Ejemplo con EJB 3.0 // El mismo ejemplo, con EJB 3.0 @Stateless public class PayrollBean implements Payroll { @Resource DataSource empDB; public void setBenefitsDeduction (int empId, double deduction) { ... Connection conn = empDB.getConnection(); ... } ... } // Y no hacen falta descriptores de despliegue.
  • 46. Líneas de desarrollo EJB :EJB 2.1 Vs EJB 3.0 • Mejoras de la versión EJB 3.0 respecto EJB 2.1 − Hemos eliminado del código los métodos no usados del ciclo de vida del EJB. − Ya no se necesita la declaración: implements javax.ejb.SessionBean En lugar de ello, la Bean Class PayrollBean implementa el interfaz Payroll. − La anotation @Resource permite que las dependencias se inyecten directamente al componente cunado el contenedor la instancie, eliminando la necesidad de búsquedas JNDI (véase el lookup del ejemplo 1).
  • 47. Líneas de desarrollo EJB :EJB 2.1 Vs EJB 3.0 • Búsquedas dinámicas en JNDI − Las búsquedas dinámicas también se han simplificado Algunas aplicaciones siguen teniendo la necesidad de hacer búsquedas dinámicas en JNDI. Estas búsquedas pueden llevarse a cabo ahora mucho más fácilmente con un método lookup añadido a SessionContext. − Las APIS JNDI se han eliminado de la visión del desarrollador − Las dependencias se expresan a nivel de la clase Bean − El método: EJBContext.lookup se usa en tiempo de ejecución.
  • 48. Líneas de desarrollo EJB :EJB 2.1 Vs EJB 3.0 • Ejemplo: @Resource(name= myDB” type=javax.sql.DataSource) @Resource(name=”myDB”, type=javax.sql.DataSource) @Stateful public class ShoppingCartBean implements ShoppingCart { ctx; @Resource SessionContext ctx; public Collection startToShop (String productName) { ... DataSource productDB =(DataSource)ctx.lookup(“myDB”); Connection conn = myDB.getConnection(); ... } ... } El recurso MyDB es buscado en tiempo de ejecución, lo que permite a una aplicación decidir a qué recursos acceder dependiendo de la disponibilidad o por ejemplo, de parámetros de QoS
  • 49. Líneas de desarrollo EJB: Compatibilidad y migración • Todas las aplicaciones existentes en la actualidad siguen funcionando en este modelo. • Facilidad de integración entre componentes y aplicaciones preexistentes. • Permite que se actualicen o reemplacen componentes (usando APIS EJB 3.0) sin afectar a los clientes existentes. • La migración incremental facilita la adopción de la tecnología EJB 3.0
  • 50. Líneas de desarrollo EJB: EJB3 • Tácticas de EJB 3.0 (I) − Simplificación de las APIS EJB • Se elimina la necesidad de EJBHomes y EJBObjects • Se eliminan las APIS JNDI del punto de vista del desarrollador y el cliente. • Eliminamos la necesidad de los descriptores de despliegue − Utilizar las ventajas de los metadatos Java (annotations) • Beneficiarnos de las configuraciones por defecto para los casos típicos • Los metadatos han sido diseñados de modo que los casos más frecuentes o comunes son más fáciles de expresar.
  • 51. Líneas de desarrollo EJB: EJB3 • Tácticas de EJB 3.0 (II) − El contenedor realiza más cantidad de trabajo tedioso, y el desarrollador menos, de modo que puede centrarse en tareas más importantes. − El Bean especifica lo que necesita usando metadatos, de modo que ya no tenemos que escribir interfaces de contenedor innecesarios. − El contenedor actúa de intermediario para proporcionar los servicios que sean requeridos.
  • 52. Líneas de desarrollo EJB: EJB3 • EJB3: Conceptos básicos − Beans de sesión (session beans) • Stateless session bean • Stateful session beans − Beans dirigidos por mensaje (Message Driven Bean) NOTA: Los beans de entidad (entity beans) han sido sustituidos por entidades de la Java Persistence API.
  • 53. Líneas de desarrollo EJB3 • Stateless Session Bean (Bean de sesión sin estado) − Es aquél que no dispone de variables de instancia en las cuales se guarden datos que puedan ser compartidos entre los distintos métodos del bean. − Se trata de un bean que por lo general contará con una serie de métodos que realizarán un trabajo determinado e independiente y que el resultado de las operaciones realizadas dentro de cada uno de los métodos no dependerá de ningún “estado” relativo a la conversación que mantiene el cliente con el bean.
  • 54. Líneas de desarrollo EJB3 • Ejemplo de stateless session bean − Tomemos como ejemplo un bean que se encarga de gestionar las operaciones básicas que podemos realizar con un cliente, como son consultar un cliente, guardar un cliente y borrarlo. − En primer lugar tendríamos que crear una interface : public interface CustomerServiceLocal { public void saveCustomer( Customer customer ); public Customer getCustomer( Long id ); public Collection getAllCustomers(); public void deleteCustomer( Long id ); } − Todo bean de sesión sin estado es necesario que disponga de una interface. − Si no la hubiéramos creado y hubiéramos definido directamente el bean sin la creación de la interface, hubiera sido el propio contenedor quién la hubiera creado por nosotros.
  • 55. Líneas de desarrollo EJB3 • La interfaz debiera de tener una anotación, que le indicara si se trata de una interface Local o Remote. • Si el bean va a ser utilizado por una clase que se ejecute dentro de la misma JVM en la que se ejecuta el bean de sesión entonces la interface podría ser Local, y si el bean va a ser llamado por una clase que se ejecuta en una JVM distinta entonces la interface tendría que ser Remote. • Por defecto, si no se indica nada, será tratada como una interface Local.
  • 56. Líneas de desarrollo EJB3 • Ejemplo de una interface local: @Local public interface CustomerServiceLocal { public void saveCustomer( Customer customer ); public Customer getCustomer( Long id ); public Collection getAllCustomers(); public void deleteCustomer( Customer customer ); } • Ejemplo de una interfaz remota: @Remote public public public public public } interface CustomerServiceRemote{ void saveCustomer( Customer customer ); Customer getCustomer( Long id ); Collection getAllCustomers(); void deleteCustomer( Customer customer );
  • 57. Líneas de desarrollo EJB3 • El bean completo sería: @Stateless public class CustomerService implements CustomerServiceLocal { @PersistenceContext() private EntityManager em; // Persistencia de tipo: container-managed entity manager. public void saveCustomer( Customer customer ) { em.persist( customer ); } public Customer getCustomer( Long id ) { Query q=em.createQuery( "SELECT c FROM Quiz c WHERE c.id = :id" ).setParameter("id", id ); return (Customer) q.getSingleResult(); } public Collection getAllCustomers() { return em.createQuery( "SELECT c from Customer c" ).getResultList(); } public void deleteCustomer( Customer customer ) { em.remove( customer ); } }
  • 58. Líneas de desarrollo EJB3 • Stateful session bean − Al contrario que en los beans de sesión sin estado, los stateful session bean, como su nombre indica, sí tienen estado. − Lo que esto significa es que dentro de la sesión del usuario estos beans van a almacenar datos en variables de instancia, y esos datos van a tener un significado concreto durante toda la conversación mantenida entre el cliente y el bean. − Un ejemplo típico de bean de sesión con estado es un carro de la compra, en el cual, durante la sesión de usuario, éste va agregando productos en el carro a través de una lista. − Tras ir agregando productos llegará un momento en el que el usuario quiera efectuar la compra, para lo cuál tendrá que realizar previamente un registro de sus datos, especificar la dirección de entrega, indicar el número de su tarjeta de crédito, etcétera, y finalmente confirmará la compra de los productos seleccionados.
  • 59. Líneas de desarrollo EJB3 • Todos estos datos hay que almacenarlos en unas variables, que son las que conforman el estado del bean. • Al igual que los Stateless Session Bean, los Stateful también deben de implementar una interface que puede ser Local o Remote : @Local public interface CartServiceLocal { public void addProduct( Product product ); public void removeProduct( Product product ); public Collection getProducts(); }
  • 60. Líneas de desarrollo EJB3 • Y la implementación de esta interface sería el Stateful Session Bean : @Stateful public class CartService implements CartServiceLocal { private List products; public void addProduct( Product product ) { products.add( product ); } public void removeProduct( Product product ){ products.remove( product ); } public Collection getProducts() { return products; } }
  • 61. Líneas de desarrollo EJB3 • Message Driven Beans (beans Dirigidos por mensaje) − Este tipo de beans ( MDB ) permite a las aplicaciones procesar mensajes de forma asíncrona a través del servicio JMS ( Java Messaging Service ). − JMS funciona a través de colas de mensajes, donde los clientes envían sus peticiones, y estas colas son controladas por los Message Driven Beans, los cuales procesan los mensajes que hay en ellas y ejecutan ciertos servicios dependiendo del mensaje procesado. − Este tipo de beans se aproximan más a la forma conceptual de los Stateless Session Bean en el sentido que son beans que no deben almacenar estado alguno.
  • 62. Líneas de desarrollo EJB3 • Cuando un mensaje llega a la cola el contenedor hace una llamada al método onMessage del Message Driven Bean y en este método el bean debería invocar a métodos de otros sesión bean o realizar la lógica de negocio de debiera ejecutar ( es más conveniente no tener aquí lógica de negocio, sino hacer invocaciones a métodos de otras clases que sí se encarguen de realizar lógica de negocio ). • Para declarar un MDB sólo hemos de establecer la anotación @MessageDriven a una clase que implemente la interface MessageListener, e indicar el nombre de la cola del contenedor ( la cuál es accesible vía JNDI) que va a controlar el MDB
  • 63. Líneas de desarrollo EJB3 • Veamos un ejemplo de MDB: @MessageDriven( mappedName = "jms/Queue" ) public class AsynchronousService implements MessageListener { public void onMessage( Message message ) { TextMessage textMessage = (TextMessage)message; System.out.println( textMessage.getText() ); } }
  • 64. Dependency Injection • Dependency Injection es un patrón según el cual, las dependencias de un objeto se proporcionan automáticamente por una entidad externa a ese objeto, y no es necesario que ese objeto pida el recurso explícitamente. • Para solicitar la inyección de un recurso, el componente usa la anotación @Resource. En algunos recursos especializados, también las anotaciones @EJB y @WebServiceRef.
  • 65. Dependency Injection
  • 66. Java Persistence API • La Java Persistence API trata lo siguiente: − Cómo los datos relacionales se mapean en Objetos Java (Persistent Entities) − Cómo esos objetos se almacenan en una base de datos relacional para que puedan ser accedidos con posterioridad − Conseguir la existencia continuada de un estado de entidad incluso después de que finalice la aplicación que la usa. − Estandariza el mapeo objeto/relacional • Una entidad (entity) es un objeto de persistencia. Normalmente una entidad representa una tabla en una BD relacional, y cada instancia de entidad es una fila de la tabla.
  • 67. Java Persistence API • Características clave de la Java Persistence API (I) 1. Las entidades son POJOs: al contrario que los componentes EJB que usan container-managed persistence (CMP). Los objetos entidad usando la nueva API ya no son componentes 2. Mapeo estandarizado objeto/relacional: podemos mapear información objeto/relacional bien usando annotations o bien descriptores XML 3. Soporte de herencia y polimorfismo: Obviamente al ser los objetos de entidad POJOs. 4. Soporte a consultas nativas (native query): Además del Java Persistence Query Language, ahora también podemos expresar nuestras consultas en el lenguaje nativo de la BD subyacente. 5. Named Query: Es una consulta estática expresada en metadatos. La consulta puede ser o bien una Java Persistence query o bien una native query, lo cual mejora la reutilización de consultas.
  • 68. Java Persistence API • Características clave de la Java Persistence API (II) 6. Reglas de empaquetado simplificadas: Ya que las entity beans son clases java (POJO), pueden ser empaquetadas en cualquier lugar de una aplicación JEE5. Por ejemplo, pueden formar parte de un .JAR EJB o en un .JAR que forme parte de librerías de un .EAR. 7. Soporte para bloqueo optimista (optimist locking): Es una técnica que evita el bloqueo por razones de rendimiento pero teniendo en consideración que la transacción puede fallar debido a colisión con otro usuario. 8. Entidades separadas (Detached Entities): Como las entidades son POJOs, pueden ser serializadas (implements Serializable) y enviadas a a través de la red a distintas direcciones. Ya no son necesarios los Data Transfer Objects (DTOs). 9. EntityManager API: En operaciones CRUD (Create Read Update Delete) que impliquen entidades. 10. Conectividad de proveedores de persistencia de terceros: Es un interfaz entre un contenedor Java EE y un proveedor de persistencia.
  • 69. Java Persistence API • Entity Beans (beans de entidad) − Un Entity Bean es una clase ( POJO ) que representa una tabla de una base de datos, y cada instancia de esta clase representa un registro de la tabla, es decir, con los entity beans lo que conseguimos es crear un mapeo entre las propiedades de una clase y los campos de una tabla. − Además de este mapeo también vamos a poder especificar las relaciones que tienen las clases entre sí ( uno a uno, uno a muchos, muchos a uno y muchos a muchos ). − Todo Entity Bean debe de tener una clave primaria que identifica a ese registro de forma única dentro de la tabla. Todas estas configuraciones las vamos a realizar a través de anotaciones, y el API que se encarga de gestionar todos los aspectos relativos a la persistencia es JPA ( Java Persistent API ).
  • 70. Java Persistence API • Como ejemplo, vamos a crear una entidad llamada Team, para lo cual veremos que lo único que vamos a tener en cuenta es: − Establecer una anotación @Entity al principio de la clase, − Una anotación @Id para indicar cuál es la propiedad que representa la clave primaria, − Y por último una anotación @OneToMany para indicar que un equipo puede estar compuesto por muchos jugadores y que éstos sólo pueden pertenecer a un equipo :
  • 71. Java Persistence API @Entity public class Team { private int id; private String name; private Date foundationDate; private Collection players; @Id public int getId() { return id; } public void setId( int value ) { id = value; } Un Team (equipo) puede tener muchos jugadores public String getName() { return name; } public void setName( String value ) { name = value; } public Date getFoundationDate() { return foundationDate; } public void setFoundationDate( Date value ) { foundationDate = value; } @OneToMany public Collection getPlayers() { return players; } public void setPlayers( Collection value ) { players = value; } }
  • 72. Java Persistence API • A continuación vamos a crear la Entidad Player, que al igual que la entidad anterior va a tener: − una anotación @Entity, − otra anotación @Id, − y por último una anotación @ManyToOne para establecer una relación bidireccional entre las dos entidades :
  • 73. Java Persistence API public class Player { private int id; private String name; private Team team; @Id public int getId() { return id; } public void setId( int value ) { id = value; } public String getName() { return name; } public void setName( String value ) { name = value; } @ManyToOne public Team getTeam() { return team; } public void setTeam( Team value ) { team = value; } } Muchos player (jugadores) pertenecen a un mismo equipo
  • 74. Java Persistence API − Creando entidades que utilizan en nuevo modelo de persistencia package demo; import javax.persistence.*; import java.util.*; import java.io.Serializable; @Entity public class Employee implements Serializable { private String id; private String name; private Department department; // Every entity must have a no-arg public/protected constructor. public Employee(){ } public Employee(String name, Department dept) { this.name = name; this.department = dept; } @ManyToOne public Department getDepartment() { return department; } public void setDepartment(Department department) { this.department = department; } } @Entity public class Department implements Serializable { private String name; private Set<Employee> employees = new HashSet<Employee>(); public Department() { } @Id public String getName() { return name; } @Id // Every entity must have an identity. public String getId() { return id; } public void setId(String id) { this.id = id; } public void setName(String name) { this.name = name; } @OneToMany(mappedBy="department") ="department @OneToMany(mappedBy="department") public Set<Employee> getEmployees() { return employees; } public String getName() { return name; } public void setName(String name) { this.name = name; } public void setEmployees(Set<Employee> employees) { this.employees = employees; } }
  • 75. Java Persistence API • Este stateless bean demuestra cómo usar las anteriores entidades: @Stateless public class HRMSBean implements HRMS { em; @PersistenceContext private EntityManager em; public Employee createEmployee(String empName, String departmentName) { Department dept = em.find(Department.class, empName); Employee emp = new Employee(empName, dept); // User is responsible for managing bidirectional relationships dept.getEmployees().add(emp); em.persist(emp); return emp; } } @Remote public interface HRMS { Employee createEmployee(String empName, String departmentName); }
  • 76. Soporte a Web Services • JAXB 2.0 − Es el API estándar para hacer corresponder documentos XML a objetos Java. − JAXB 2.0 reduce significativamente la complejidad del procesado de documentos XML. − JAXB 2.0 ofrece las siguientes mejoras respecto JAXB 1.0: • Soporte completo al XML Schema: Incluyendo los tipos de datos predefinidos. • Capacidad para clases java existentes a un XML Schema ya generado. • Menor consumo de memoria (smaller footprint) conversión objeto/xml acelerada (faster marshalling*). • Enlace parcial de documentos XML hacia objetos JAXB 2.0: * Marshalling: Consiste en convertir un objeto Java en un flujo de datos XML. UnMarshalling: El proceso inverso: obtener los objetos Java a partir de un documento XML.
  • 77. Soporte a Web Services • SOAP with Attachments API for Java (SAAJ) 1.3 − Las aplicaciones que necesitan manipular mensajes SOAP directamente, usan SAAJ. Esta nueva versión incluye algunas clases y métodos que facilitan integrar SAAJ con las transformaciones producto de Java Api for Xml Processing (JAXP), y con el marshalling producto de Java Architecture for Xml Binding (JAXB). • Streaming API for XML (StAX) − StAX define un parser XML dinámico basado en eventos, usando una filosofía diferente que SAX. StAX usa una técnica a demanda; es decir, el cliente sólo consigue datos XML cuando explícitamente lo pide. StAX tiene un menor consumo de memoria, menor coste de CPU y mejor rendimiento en ciertas situaciones. − Streaming se refiere a un modelo de programación en el que los bloques de datos son transmitidos y parseados en serie en tiempo de ejecución, a menudo en tiempo real, y de fuentes dinámicas cuyos contenidos no son conocidos a priori.
  • 78. Ventajas de JSF • Java Server Faces es un framework* del lado de servidor, que proporciona componentes de interfaz de usuario (IU) para construir aplicaciones web. • JSF proporciona los siguientes beneficios: − Permite unir un conjunto de componentes de IU permitiendo construir fácilmente nuevos IUs − Facilita la construcción de componentes IU a medida. − Facilita la movilidad de datos DESDE y HACIA el IU − Ayuda a gestionar los IU − Facilita la conexión de eventos generados por el usuario a código de aplicación en el lado servidor. * un Framework es una estructura de soporte en la cual se organiza y desarrolla un proyecto de software
  • 79. Ventajas de JSF • Elementos de una aplicación JSF En su mayor parte, una aplicación JSF es como cualquier otra aplicación Web en Java. Tiene los siguientes elementos: − Páginas JSP − Un Bean de copia (backing bean), es un POJO (clase) que almacena datos de componentes con propiedades de bean y que proporciona varios métodos como convertidores, validadores, y receptores de eventos (event listeners). − Un fichero de configuración faces-config.xml − Un fichero de configuración web.xml (un descriptor JEE web) • Veremos un ejemplo más adelante.
  • 80. JavaServer Pages Standard Tag Library (JSTL) • Ahora JSTL es parte de la plataforma JEE5. • JSTL proporciona un lenguaje fácil de usar encapsulando las funcionalidades comunes a muchas aplicaciones JSP. • JSTL permite emplear un único conjunto estandarizado de etiquetas (tags) en lugar de mezclar diferentes tags de distintos fabricantes en nuestras aplicaciones JSP. • JSTL tiene tags para iteradores, condicionales, control de flujo, manipulación de documentos XML, aceso a bases de datos mediante SQL y otras funciones.
  • 81. Fin

×