Arquitectura Jakarta EE Parte 1 PDF

B3T6 JAKARTA EE Y.NET TAI 1. ARQUITECTURA JAKARTA EE Las arquitecturas web han revolucionado el panorama del desarrollo de software en los últimos años. Esta revolución se ha debido a diferentes causas de entre las que destacan...

B3T6 JAKARTA EE Y.NET TAI 1. ARQUITECTURA JAKARTA EE Las arquitecturas web han revolucionado el panorama del desarrollo de software en los últimos años. Esta revolución se ha debido a diferentes causas de entre las que destacan poderosamente la explosión de Internet y sus protocolos, y el apoyo por parte de la industria a este nuevo paradigma de aplicación. El desarrollo de sistemas corporativos basados en una arquitectura Web es algo relativamente reciente. Durante los años 90, los desarrollos de aplicaciones corporativas se diseñaban con tecnología cliente/servidor. La implantación de la tecnología cliente/servidor no se hizo sin problemas ya que dieron lugar a entornos heterogéneos y distribuidos que eran muy difíciles de integrar y sobre todo de gestionar. La necesidad de distribuir aplicaciones a un creciente número de clientes, situados en centros geográficamente dispersos, creó importantes problemas de eficiencia, eficacia y servicio durante la utilización de estas aplicaciones cliente/servidor. El objetivo inicial de alcanzar flexibilidad, acceso rápido y seguro a los datos corporativos, a un precio razonable, seguía siendo una meta por conseguir. El coste de gestión de estos sistemas era enorme y las corporaciones seguían buscando una nueva tecnología que resolviese al menos algunos de estos problemas. A finales de los 90, gran número de desarrollos corporativos empezaron a aprovechar los estándares, lenguajes y protocolos surgidos alrededor de la Web, creándose el concepto de las arquitecturas multicapa, que se presentaban como alternativa a la arquitectura cliente/servidor clásica, que permitiría utilizar un entorno cliente ligero y, por lo tanto, evitar el problema de la distribución y mantenimiento del software de los PCs cliente. Indudablemente estos inicios fueron duros ya que la tecnología que se estaba utilizando no había sido inicialmente pensada para lo que ahora se quería utilizar. Las empresas de software iniciaron una carrera para conseguir adaptar los protocolos, lenguajes y estándares de Internet, que parecían claramente asentados en un tipo de aplicaciones con gran cantidad de información estática e interfaces de usuario sencillas, a las necesidades de los desarrollos corporativos estratégicos. Java es uno de estos lenguajes que aparecieron alrededor de Internet y ha impulsado el desarrollo de aplicaciones con arquitectura Web como ningún otro lenguaje. La complejidad de las arquitecturas web seguía siendo bastante importante, poco a poco se definieron recomendaciones y estándares que intentaron simplificarlo. Con la publicación de las especificaciones J2EE (Java 2 Enterprise Edition) se dio el impulso definitivo para la entrada de esta tecnología en el ámbito empresarial, con muchas menos dudas, ya que estos estándares sí fueron pensados para la problemática de complejos desarrollos corporativos y se ha convertido en la base para los próximos años de la arquitectura de desarrollo para la Web con tecnología Java. PABLO ARELLANO www.theglobeformacion.com Página 3 B3T6 JAKARTA EE Y.NET TAI Jakarta Enterprise Edition o Jakarta EE es un conjunto de especificaciones y prácticas que permiten desarrollar, desplegar y gestionar aplicaciones Java multicapa de entorno empresarial. La plataforma Jakarta EE consta de un conjunto de servicios, APIs y protocolos que proporcionan la funcionalidad necesaria para desarrollar aplicaciones en lenguaje de programación Java basadas en una arquitectura distribuida de varios niveles o capas. NOVEDAD La plataforma Java EE 8 es la última versión especificada por Oracle en el año 2017. A partir de ese momento la organización Eclipse Foundation es la nueva encargada. Como Java es una marca registrada por Oracle, en 2018 Eclipse cambió el nombre de Java EE a Jakarta EE. Actualmente, versión 10. Jakarta EE modifica el nombre de los JCP a Eclipse EE.next Working Group (EE.next). La plataforma Java EE se desarrolla a través de Java Community Process (JCP), que es responsable de todas las tecnologías Java. Grupos de expertos compuestos por partes interesadas han creado solicitudes de especificación Java (JSR) para definir las diversas tecnologías Java EE. El trabajo de la Comunidad Java bajo el programa JCP ayuda a garantizar los estándares de estabilidad y compatibilidad entre plataformas de la tecnología Java. Las especificaciones Jakarta EE se consideran generales. Tenemos especificaciones de: - Plataforma: incluye un conjunto de especificaciones individuales. - Perfil: solo incluyen aquellas especificaciones individuales para desarrollar un tipo específico de aplicaciones. Perfiles: o Perfil web. o Perfil core. Updated Not Updated New MicroProfile es una especificación de la comunidad de código abierto para microservicios Enterprise Java. Esta comunidad colabora dentro de un grupo de trabajo de la Fundación Eclipse para llevar microservicios a la comunidad Enterprise Java. MicroProfile adopta el perfil Core de Jakarta EE. PABLO ARELLANO www.theglobeformacion.com Página 4 B3T6 JAKARTA EE Y.NET TAI Además de la plataforma Jakarta EE, se citan otras plataformas existentes (propiedad de Oracle): - Java Card: permite que elementos seguros, como tarjetas inteligentes y otros chips de seguridad a prueba de manipulaciones, alojen aplicaciones basadas en tecnología Java. Pensado para IoT. - Java ME (Micro Edition): proporciona un entorno robusto y flexible para aplicaciones que se ejecutan en dispositivos integrados y móviles: microcontroladores, sensores, puertas de enlace, teléfonos móviles, PDAs, decodificadores de TV e impresoras entre otros. Java Embedded es parte de esta plataforma. - Java SE (Standard Edition): permite desarrollar e implementar aplicaciones Java de escritorio y servidor. 1. Arquitectura Los desarrollos basados en arquitecturas multicapa, como es el caso de Jakarta EE, utilizan dos conceptos que conviene aclarar: - Capa: una capa es una funcionalidad de la aplicación separada del resto. Por tanto, desde un punto de vista lógico, una aplicación se puede dividir en varias capas. - Nivel: un nivel es un entorno físico donde residen una o varias capas. Es un enfoque desde un punto de vista físico. La arquitectura multicapa que sigue capa es la que se muestra en la figura: Jakarta EE Jakarta EE Application 1 Application 2 Client Client Machine Tier Application Web Client Pages Jakarta Server Pages Faces Web Tier Jakarta EE Server Enterprise Enterprise Beans Beans Business Tier EIS Database Database Database Server Tier PABLO ARELLANO www.theglobeformacion.com Página 5 B3T6 JAKARTA EE Y.NET TAI Por lo general, las aplicaciones de varias capas tienen una capa de cliente, una capa de negocio y una capa de datos. El nivel de cliente consta de un programa de cliente que realiza solicitudes al nivel de servidor. Éste se divide en una capa web y una capa de lógica de negocio, que manejan las solicitudes de los clientes y procesan los datos de la aplicación, almacenándolos en un almacén de datos permanente en el nivel de datos. El desarrollo de aplicaciones Jakarta EE se concentra en la capa web y de negocio. La arquitectura de desarrollo multicapa se caracteriza por dividir el sistema en distintas capas que se comunican a través de interfaces: (1) Nivel de cliente El nivel de cliente consta de clientes de aplicaciones que acceden a un servidor Jakarta EE y que generalmente se encuentran en una máquina diferente del servidor. Los clientes hacen solicitudes al servidor. El servidor procesa las solicitudes y devuelve una respuesta al cliente. Muchos tipos diferentes de aplicaciones pueden ser clientes Jakarta EE. Los clientes pueden ser un navegador web, una aplicación independiente u otros servidores, y se ejecutan en una máquina diferente del servidor Jakarta EE. (2) Nivel servidor Jakarta EE - Capa de presentación web La capa web consta de componentes que manejan la interacción entre los clientes y la capa de negocio. Sus tareas principales son las siguientes: - Genere dinámicamente contenido en varios formatos para el cliente. - Recopile información de los usuarios de la interfaz del cliente y devuelva los resultados apropiados de los componentes en el nivel empresarial - Controle el flujo de pantallas o páginas en el cliente. - Mantener el estado de los datos para la sesión de un usuario. - Realice una lógica básica y mantenga algunos datos temporalmente en beans administrados. PABLO ARELLANO www.theglobeformacion.com Página 6 B3T6 JAKARTA EE Y.NET TAI Algunas de las principales tecnologías Jakarta EE que se utilizan en la capa son (en la imagen, todas las APIs): - Jakarta Faces (JSF): un marco de componentes de interfaz de usuario para aplicaciones web que le permite incluir componentes de IU (como campos y botones) en una página HTML, llamada página Facelets; convierten y validan datos de componentes de la interfaz de usuario, guardan datos de componentes de la IU en almacenes de datos del lado del servidor y mantienen el estado del componente. - Jakarta Servlets: clases del lenguaje de programación Java que procesan dinámicamente solicitudes y construyen respuestas, generalmente para páginas HTML. - Jakarta Server Pages (JSP): nos permite incrustar en el código HTML código Java para generar las partes dinámicas. (3) Nivel servidor Jakarta EE - Capa de negocio o lógica de negocio La capa de negocio consta de componentes que proporcionan la lógica empresarial para una aplicación. La lógica empresarial es un código que proporciona funcionalidad a un dominio comercial particular, como la industria financiera o un sitio de comercio electrónico. En una aplicación empresarial diseñada adecuadamente, la funcionalidad principal existe en los componentes de nivel empresarial. En esta capa se encuentran las siguientes tecnologías Jakarta EE (en la imagen, todas las APIs): - Componentes Jakarta Enterprise Beans (versión actual 4.0) (en Java EE, EJB). - Jakarta RESTful Web Services (en Java EE, JAX-RS, Java API for RESTful Web Services): API para desarrollo de servicios web RESTful. - Jakarta XML Web Services (en Java EE, JAX-WS, Java API for XML Web Services): provee funcionalidad para servicios web que utilizan mensajes XML y que siguen el estándar SOAP. - Jakarta SOAP with Attachments (en Java EE, SAAJ, SOAP with Attachments API for Java): API que permite la producción y el consumo de mensajes que cumplen con las especificaciones SOAP. PABLO ARELLANO www.theglobeformacion.com Página 7 B3T6 JAKARTA EE Y.NET TAI (4) Nivel servidor Jakarta EE - Capa de persistencia o acceso a datos La capa de persistencia se encarga de la manipulación de los datos que requiere el sistema de información y que están situados en diferentes fuentes de datos. Esta capa puede estar diferenciada de la capa de negocio o estar integrada en ella. Las tecnologías de Jakarta EE para el acceso a los datos son: - API de conectividad a base de datos (JDBC). - API para acceso a servicios de directorio (JNDI) - Jakarta Persistence (versión actual 3.1). La API de persistencia de Java (en Java EE, JPA). - Jakarta Transactions (versión actual 2.0). La API de transacciones Java (en Java EE, JTA). - Jakarta Data (actualmente en desarrollo). La API de acceso a datos relaciones/no relaciones y en nube. (5) Nivel de datos Este nivel consta de servidores de bases de datos, sistemas de planificación de recursos empresariales y otras fuentes de datos. Estos recursos generalmente se encuentran en una máquina separada del servidor Jakarta EE, y se accede a ellos por componentes de la lógica de negocio. 2. Servidor Jakarta EE y contenedores Un servidor Jakarta EE es un servidor de aplicaciones que implementa las API de la plataforma Java EE y proporciona servicios estándar Jakarta EE (capa web y de negocio). Los servidores Jakarta EE que cumplen las especificaciones Jakarta EE se les denomina servidores de aplicaciones certificados. PABLO ARELLANO www.theglobeformacion.com Página 8 B3T6 JAKARTA EE Y.NET TAI Los servidores de aplicaciones Java EE certificados son productos comerciales: PRODUCTO COMPAÑÍA WebLogic Oracle Java EE JOnAS ObjectWeb JBoss Red Hat Eclipse GlassFish Eclipse Foundation Software Enterprise Application Platform Fujitsu WebSphere Liberty IBM Jakarta EE 10 Open Liberty Open Liberty PLATFORM Server Community y Server Enterprise Payara JBoss Enterprise Application Platform Red Hat WildFly WildFly Eclipse GlassFish Eclipse Foundation Jakarta EE 10 WebSphere Liberty IBM WEB PROFILE JBoss Enterprise Application Platform Red Hat y Jakarta EE 10 Open Liberty Open Liberty CORE PROFILE Server Community y Server Enterprise Payara WildFly WildFly Los servidores Jakarta EE alojan varios tipos de componentes de aplicación que corresponden a las capas en una aplicación multicapa. El servidor Jakarta EE proporciona servicios a estos componentes en forma de contenedor. Un contenedor es un proceso donde se ejecutan los componentes. Los contenedores Jakarta EE son la interfaz entre el componente y la funcionalidad de la capa inferior proporcionada por la plataforma para soportar ese componente. La funcionalidad del contenedor está definida por la plataforma y es diferente para cada tipo de componente. No obstante, el servidor permite que los diferentes tipos de componentes trabajen juntos para proporcionar funcionalidad en una aplicación empresarial. - El contenedor del cliente de la aplicación es la interfaz entre los clientes de la aplicación Jakarta EE (aplicaciones especiales de Java SE que usan componentes del servidor Jakarta EE) y el servidor Jakarta EE. PABLO ARELLANO www.theglobeformacion.com Página 9 B3T6 JAKARTA EE Y.NET TAI El contenedor del cliente de la aplicación se ejecuta en la máquina del cliente y es la puerta de enlace entre la aplicación del cliente y los componentes del servidor Jakarta EE que utiliza el cliente. - El contenedor web es la interfaz entre los componentes web y el servidor web. Un componente web puede ser un servlet, una página JSP o JSF. El contenedor gestiona el ciclo de vida del componente, envía solicitudes a los componentes de la aplicación y proporciona interfaces para datos de contexto, como información sobre la solicitud actual. El contenedor web se ejecuta en el servidor web (habitualmente) o en el servidor Jakarta EE. Contenedores web: Apache Tomcat es un contenedor de servelts y JSPs. El protocolo AJP (Apache Jserv Protocol), orientado a paquetes, permite la comunicación entre el servidor web (por ejemplo, Apache) y Tomcat a través de conexiones TCP persistentes. Apache sirve las peticiones de páginas estáticas y Tomcat las peticiones de páginas con contenido dinámico. - El contenedor EJB es la interfaz entre los beans empresariales, que proporciona la lógica empresarial de una aplicación Jakarta EE, y se ubica en el servidor Jakarta EE. El contenedor EJB se ejecuta en el servidor Jakarta EE y gestiona la ejecución de los beans empresariales de una aplicación. Interoperabilidad Muchas de las API proveen interoperabilidad con componentes que no forman parte de la plataforma Jakarta EE, como servicios web externos o CORBA. Jakarta EE Interoperability ofrece las facilidades de interoperabilidad que pueden estar disponibles en la plataforma Jakarta EE. IIOP HTT P IIOP HTT P SSL SSL SOAP SOAP JRMP JRMP EJB / IIOP / SSL HTT P HTT P Web EJB Container Container Database Application Client Container Jakarta EE Platform JRMP IIOP SOAP HTT P HTT P SSL PABLO ARELLANO www.theglobeformacion.com Página 10 B3T6 JAKARTA EE Y.NET TAI Java RMI (RMI, Remote Method Invocation) es una tecnología que proporciona comunicación remota entre programas escritos en el lenguaje Java, permitiendo tener los objetos distribuidos en diversas máquinas, esto es, que un objeto que se ejecuta en una JMV (máquina virtual Java) invoque métodos en un objeto que se ejecuta en otra JVM. Anterior a esta tecnología, para realizar llamadas a funciones y procedimientos remotos se usaba (RPC, Remote Procedure Calls). Para usar Java RMI se necesita el siguiente paquete: import java.rmi.*; Cada servicio RMI (objeto remoto) se define mediante una interface, que especifica los métodos que se pueden invocar en el objeto remoto. Esta interface debe estar disponible en el cliente y en el servidor. Además, se puedan pasar argumentos al método remoto y recibir los datos que devuelve (tipos primitivos u objetos de clases que sean serializables). RMI-JRMP es el protocolo de invocación de método remoto (RMI, Remote Method Invocation) específico de Java que permite la comunicación de aplicaciones distribuidas basadas exclusivamente en Java. Java IDL (IDL, Interface Description Language) es una implementación CORBA que permite que dos objetos interactúen sobre diferentes plataformas a través de una red. Al ser una interfaz, posibilita que objetos escritos con diferentes lenguajes (a diferencia de Java RMI) interactúen entre sí. RMI/IIOP (IIO, Internet Inter-ORB Protocol) es un protocolo de comunicación para CORBA que utiliza RMI para permitir la comunicación entre aplicaciones distribuidas en diferentes lenguajes (no necesariamente Java). 3. Componentes Los componentes se despliegan y ejecutan en contenedores especializados. Citamos los siguientes componentes: - Componentes WEB: o Jakarta Servlet. Versión actual 6.0. (en Java EE, Java Servlet) o Jakarta Pages (JSP). Versión actual 3.1. (en Java EE, JavaServer Pages) o Jakarta Faces (JSF). Versión actual 4.0. (en Java EE, JavaServer Faces) - Componentes de NEGOCIO: o Jakarta Enterprise Beans (EJB). Versión actual 4.0. (en Java EE, Enterprise JavaBeans) PABLO ARELLANO www.theglobeformacion.com Página 11 B3T6 JAKARTA EE Y.NET TAI (1) Servlets Un servlet es una clase de lenguaje de programación Java que se utiliza para ampliar las capacidades de los servidores que alojan aplicaciones a las que se accede mediante un modelo de programación de petición/respuesta. Se utilizan en los servidores web proporcionando contenido dinámico al usuario. Para este tipo de aplicaciones, la tecnología Java Servlet define clases de servlet específicas de HTTP. Los servlets son pequeños programas escritos en Java que admiten peticiones a través del protocolo HTTP. Por lo tanto, los servlets pueden recibir peticiones desde un navegador web, procesarlas, y devolver una respuesta al navegador, normalmente en HTML. Para realizar estas tareas podrán utilizar las clases incluidas en el lenguaje Java. Los servlets se instalan, gestionan y ejecutan en un componente del sistema denominado contenedor web, que se comunican con el cliente normalmente mediante el protocolo HTTP. Estos programas suelen ser intermediarios entre el cliente (la mayoría de las veces un navegador web) y los datos (normalmente una base de datos). El funcionamiento básico de un servlet es el siguiente: - El cliente envía una petición al servlet mediante HTTP. - El servlet procesa los argumentos de la petición. - El servlet realiza la tarea solicitada. - El servlet devuelve una respuesta al cliente, normalmente en HTML. El ciclo de vida de un servlet tiene 3 fases: - Instanciación e inicialización: se crea el servlet en memoria (si no existe una instancia previa del mismo) y se llama al método init() para inicializar su funcionamiento. - Gestión de peticiones: para atender cada petición, el servidor de aplicaciones o contenedor de servlets crea un hilo de ejecución del servlet, lo que permite atender varias peticiones de forma simultánea, compartir datos de forma automática, etc. Como desventaja, es importante tener en cuenta los posibles problemas de concurrencia que pueden derivarse de esto. - Destrucción: si durante un tiempo (configurable) el servlet no recibe peticiones, es descargado de memoria. PABLO ARELLANO www.theglobeformacion.com Página 12 B3T6 JAKARTA EE Y.NET TAI La estructura básica de un servlet comprende: - La importación de las clases necesarias para desarrollar nuestros propios servlets, son: import jakarta.servlet.*; (en Java EE, javax.servlet.*) import jakarta.servlet.http.*; (en Java EE, javax.servlet.http.*) - La clase a implementar debe extender un servlet del API. Como las aplicaciones a desarrollar son aplicaciones web utilizaremos como clase base el servlet HttpServlet, que implementa el comportamiento de un servlet capaz de trabajar con el protocolo http: public class MiClase extends HttpServlet {... } La clase HttpServlet es una clase abstracta de la que heredarán todos los servlets destinados a dar servicios desde un contenedor web. Los métodos más interesantes y que un servlet puede sobrecargar son los siguientes: o doGet(): se ejecuta cuando se recibe una petición HTTP GET. o doPost(): se ejecuta cuando se recibe una petición HTTP POST. o doPut(): se ejecuta cuando se recibe una petición HTTP PUT. o doDelete(): se ejecuta cuando se recibe una petición HTTP DELETE. o init() y destroy(): gestionan el ciclo de vida del servlet, ejecutándose en la creación y destrucción del servlet. o getServletInfo(): lo utiliza el servlet para proporcionar información acerca de sí mismo. o service(): maneja la petición HTTP para redirigir al método doXXX que corresponda. Los métodos doXXX reciben como parámetros, objetos de la clase HttpServletRequest con la información de la solicitud HTTP y HttpServletResponse, donde se incluye la información de respuesta a la petición HTTP. En ellos se implementa normalmente la funcionalidad del servlet ante los distintos tipos de solicitudes HTTP. - Después debemos sobrescribir, si lo necesitamos, el método init() heredado de la superclase, encargado de inicializar el servlet. En él debemos incluir todo lo que queramos que se ejecute sólo cuando se cree el servlet en memoria. Para ello, primero llamamos al init() de la superclase. Después podemos incluir las inicializaciones necesarias. public void init(ServletConfig conf) throws ServletException { super.init(conf); // Inicializaciones } - Finalmente se sobrescriben los métodos doXXX según los tipos de peticiones que se vayan a tratar. PABLO ARELLANO www.theglobeformacion.com Página 13 B3T6 JAKARTA EE Y.NET TAI Ejemplo: Nombre Apellidos import java.io.*; import jakarta.servlet.*; import jakarta.servlet.http.*; public class ArgumentosPost extends HttpServlet { public void doPost(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException { res.setContentType("text/plain"); PrintWriter out = res.getWriter(); out.println("Nombre: " + req.getParameter("nombre")); out.println("Apellidos: " + req.getParameter("apellidos")); } } El protocolo HTTP es un protocolo que no es capaz de almacenar el estado en el que se encuentra, es decir, no es capaz de almacenar qué ha pasado en el pasado inmediato. Los servidores de aplicaciones suplen esa carencia permitiendo que almacenemos variables en un entorno de ejecución de nuestra aplicación web denominado sesión. Los servlets son capaces de conectarse a una determinada sesión en curso o crear una nueva y añadir, modificar o borrar atributos de la sesión. Ejemplo: aplicación web que cuenta el número de veces que accedemos o recargamos una página mientras la sesión está activa. import java.io.*; import jakarta.servlet.*; import jakarta.servlet.http.*; public class Contador extends HttpServlet { public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { PrintWriter out = response.getWriter(); HttpSession session = request.getSession(true); Integer contador; if (session.isNew()) { out.println("Hola. "); contador = new Integer(0); } else { out.println("Hola de nuevo. "); contador = (Integer)session.getAttribute("valor"); } PABLO ARELLANO www.theglobeformacion.com Página 14 B3T6 JAKARTA EE Y.NET TAI Integer nuevoValor = new Integer(contador.intValue()+1); session.setAttribute("valor", nuevoValor); out.println("En la sesión: "+session.getId()+ " el contador vale " + contador + "\n"); } } (2) Faces Jakarta Faces es un framework IU para aplicaciones web Java. Está diseñado para reducir significativamente la carga de escribir y mantener aplicaciones que se ejecutan en un servidor de aplicaciones Java. Jakarta Faces: - Facilita la construcción de IU a partir de un conjunto de componentes de interfaz de usuario reutilizables. - Simplifica la migración de los datos de la aplicación hacia y desde la IU. - Ayuda a gestionar el estado de la IU en todas las solicitudes del servidor. - Proporciona un modelo sencillo para comunicar eventos generados por el cliente al servidor. - Permite crear y reutilizar fácilmente los componentes de IU personalizados. Para usar Jakarta Faces se necesita el siguiente paquete: import jakarta.faces.*; (en Java EE, javax.faces) Java Server Faces (JSF) ofrece: - Un conjunto de APIs para representar componentes de IU y administrar su estado, manejar eventos y validación de entradas, definir la navegación de la página y respaldar la internacionalización y la accesibilidad. - Una biblioteca de etiquetas personalizadas de JSP para expresar una interfaz JSF dentro de una página JSP. La página web myfacelet.xhtml está construida utilizando etiquetas de componente JSF, las cuales se utilizan para agregar componentes a la vista (myView en la imagen), que es la representación de la página en el lado del servidor. La página web también puede hacer referencia a objetos, como eventos, validadores y conversores que estén registrados en los componentes, y también a los componentes JavaBeans que capturan los datos y procesan la funcionalidad específica de la aplicación de los componentes. A petición del cliente, la vista se presenta como respuesta. La renderización es el proceso mediante el cual, basándose en la vista del lado del servidor, el contenedor web genera una salida HTML que puede ser leída por el navegador. Los componentes de JSF son: - Componentes IU: clases que extienden de IUComponentBase (subclase de UIComponent), la cual define el estado y el comportamiento por defecto de los PABLO ARELLANO www.theglobeformacion.com Página 15 B3T6 JAKARTA EE Y.NET TAI componentes. Componentes: UIColumn, UICommand, IUForm, UIInput, UIMessage, UIPanel… - Conversor: transforma de forma conveniente los valores de los objetos Java vinculados a los componentes JSF en Strings y transforman los Strings enviados por el cliente (parámetros HTTP) en los objetos Java vinculados a los componentes JSF según el tipo que corresponda. - Validador: comprueba que los valores recibidos y almacenados en los componentes JSF cumplen las restricciones especificadas. - Renderizador: genera la representación de los componentes a mostrar en los clientes y de recuperar las entradas de usuario recibidas para actualizar los valores vinculados a los componentes. Por último, recordamos que tanto Jakarta Faces como JSF son una especificación, por lo que necesitamos de un framework que implemente dicha especificación. Entre las implementaciones destacamos: - Eclipse MojarraTM (incluido en Eclipse GlassFish) es una implementación que define un marco MVC para crear IU para aplicaciones web, incluidos los componentes de la IU, la gestión del estado, la entrega de eventos, la validación de entradas, la navegación por páginas y el soporte para la internacionalización y la accesibilidad. - Apache MyFaces. (3) JSP JSP es un lenguaje que permite insertar etiquetas de distintos tipos que añaden comportamiento dinámico a nuestras páginas. JSP se considera un nivel de abstracción por encima de los servlets, ya que las páginas JSP se transforman en servlets para ejecutarse. Ejemplo: Salvo por algunos detalles, el código incluido entre las etiquetas es código Java normal y corriente: podemos definir variables, mostrar su contenido, debemos incluir paquetes, etc. Se puede incluir código Java dentro de las páginas JSP de tres formas distintas: - Expresiones: que se evalúan y el resultado se muestra en el navegador. Pueden ser tan sencillas como incluida en el ejemplo anterior o pueden contener concatenaciones y acceso a atributos estáticos de clases de java. PABLO ARELLANO www.theglobeformacion.com Página 16 B3T6 JAKARTA EE Y.NET TAI Ejemplo: - Scriptlets: son fragmentos de código Java entre las etiquetas. Para poder mostrar cosas en el navegador debemos utilizar el objeto implícito out. Ejemplo: - Declaraciones: que se encuentran entre los símbolos. Las variables declaradas se consideran globales. En el ejemplo “hola mundo”, podemos ver cómo se declara una variable global de tipo String que luego se utiliza. Ejemplo: Como se comentó en la introducción, los archivos JSP se transforman en un servlet para su ejecución. Las directivas influyen en la manera en la que se realiza esta transformación. Hay tres tipos de directivas: - : se utiliza para importar clases, acceder a la sesión, gestión de errores, etc. - : nos permite incluir un fichero dentro de otro. Simplemente copia el contenido de un fichero dentro de otro. - : se utiliza en el uso de JSTL1 (JavaServer Pages Standard Tag Library). 1 Extiende JSP proporcionando cuatro bibliotecas de etiquetas: core, xml, sql y fmt. PABLO ARELLANO www.theglobeformacion.com Página 17 B3T6 JAKARTA EE Y.NET TAI Las acciones tienen diversos usos, como por ejemplo incluir la salida resultante de ejecutar un fichero JSP en otro. Podemos escribir un fichero index.jsp de la forma. Ejemplo: Y un fichero cuerpo.jsp de la forma: