Objetivo de aprendizaje del tema

Transcripción

1 Computación II Tema 13. Servlets Objetivo de aprendizaje del tema Al finalizar el tema serás capaz de: Describir las características ti de las aplicaciones i Web y los protocolos que intervienen en la comunicación, así como la participación de Java EE en el desarrollo de las mismas. Distinguir entre los diferentes servidores de aplicaciones y describir su funcionalidad. Ejemplificar la manera de desarrollar aplicaciones Java EE usando Servlets. Construir aplicaciones Web con Servlets que reciban parámetros a partir de formularios HTML. Emplear adecuadamente los mecanismos de administración de sesiones en aplicaciones Web.

2 Introducción al tema Los Servlets son la alternativa de Sun Microsystems para las tecnologías de servidores web. Se basan en el principio de funcionamiento del protocolo HTTP e implementa su funcionalidad a través de métodos que reciben peticiones provenientes de un navegador de Internet, la procesan buscando los datos que el usuario solicita, o bien preparando una respuesta de acuerdo a la petición del usuario, y enviando dicha respuesta de regreso al navegador para ser mostrada. Introducción al tema El API de Java EE (Enterprise Edition) utiliza la especificación de Servlets de Java para definir la implementación de clases que encapsulan el comportamiento de responder a peticiones usando el protocolo HTTP. Aunque en otros lenguajes existen implementaciones similares, los Servlets de Java son ligeros debido a que son implementados usando un modelo de hilos, lo que hace que la ejecución de tales programas sea mucho más ágil que sus equivalentes en otros lenguajes de servidor.

3 Tecnologías de Aplicaciones Web El protocolo HTTP (Hypertext Transfer Protocol, Protocolo de Transferencia de Hipertexto) es similar a muchos otros protocolos en Internet, por ejemplo SMTP (Simple Mail Transfer Protocolo, Protocolo Simple de Transferencia de Correo) y FTP (File Transfer Protocol, Protocolo de Transferencia de Archivos), debido a que HTTP es un protocolo que se usa para transferir datos del servidor al cliente. Una diferencia i fundamental entre otros protocolos de Internet y HTTP es que los protocolos comunes de Internet soportan muchas solicitudes por conexión, mientras que HTTP típicamente sólo soporta una solicitud por conexión. Arquitectura Cliente-Servidor Para cada intercambio en la web usando HTTP, existe una solicitud (request) y una respuesta (response). El siguiente diagrama representa la arquitectura HTTP Cliente-Servidor:

4 Estructura de un Sitio Web Sabías qué? El archivo index.html es un archivo especial empleado cuando el usuario solicita un URL (Uniform Resource Locator) que termina en una diagonal (/). El servidor web le presenta al usuario un listado del directorio indicado en el URL, a menos que exista un archivo index.html en ese directorio. Si ese es el caso, entonces el servidor envía el archivo index.html como la respuesta al URL original. Localizador Uniforme de Recursos (URL) Un URL es un nombre canónico que localiza un recurso específico en Internet. Se forma de esta manera: protocolo://host:puerto/ruta/archivo Por ejemplo:

5 Localizador Uniforme de Recursos (URL) El elemento ruta incluye la estructura completa de la ruta en la estructura del directorio para encontrar el archivo solicitado. El número de puerto es usado para identificar el puerto TCP que es usado por el protocolo en el servidor. Si el número de puerto es el puerto estándar para el protocolo especificado, entonces el número de puerto puede omitirse del URL. Por ejemplo, el puerto 80 es el puerto por omisión de HTTP: Sitios Web y Aplicaciones Web Un sitio web es una colección de archivos estáticos, páginas HTML, imágenes y varios otros archivos. Una aplicación web es un sitio web con contenido dinámico en el servidor. Una aplicación web ejecuta programas en el servidor, por ejemplo: Un navegador de Internet (browser) envía la solicitud de un formulario HTML al servidor. El servidor responde enviando el formulario HTML al navegador, en forma de un flujo en una respuesta HTTP. A continuación el navegador envía al servidor otra solicitud, con los datos que llenó el usuario en el formulario HTML. El servidor transfiere la solicitud y los datos a un programa que responde enviando datos de regreso al navegador.

6 Ejecución de Servlets de Java Generalmente el navegador debe enviar datos al programa CGI en el servidor, quien determina cuál CGI ejecutará de acuerdo al URL. El programa CGI interpreta los datos recibidos en la solicitud, los procesa y genera una respuesta (generalmente una página HTML). El CGI envía esta respuesta al servidor web que a su vez la prepara en un HTTP response que es enviado al navegador. El problema con esta tecnología es que cada vez que se invoca a un programa CGI, se genera un nuevo proceso en el sistema operativo del servidor para poder ejecutarlo, lo que consume más recursos de CPU y memoria del propio servidor web, afectando al desempeño de la aplicación Ejecución de Servlets de Java

7 Ejecución de Servlets de Java Los servlets se ejecutan dentro de la arquitectura de contenedores de componentes de Java EE. Este contenedor se conoce como contenedor web (también conocido como el motor de servlets). El contenedor web es una Java Virtual Machine que provee una implementación del API de servlets. Las instancias de servlets son componentes que son administradores por el contenedor web para responder los HTTP requests. El siguiente diagrama muestra la arquitectura de Servlets: Ejecución de Servlets de Java Los pasos básicos de procesamiento de servlets de Java son muy similares a los de CGI. Sin embargo, el servlet se ejecuta como un hilo en el contenedor web en lugar de hacerlo en un proceso separado del sistema operativo. El contenedor web es en sí un proceso del sistema operativo, pero se ejecuta como un servicio y está disponible todo el tiempo. Esto es contrario a un script CGI que genera un nuevo proceso de sistema operativo con cada solicitud. Cuando se incrementa el número de solicitudes para un servlet, no se requiere crear nuevas instancias del proceso del servlet en el sistema operativo. Cada petición se maneja concurrentemente usando un thread o hilo de Java por solicitud.

8 Ejecución de Servlets de Java Ventajas y desventajas de los servlets de Java Los servlets tienen las siguientes ventajas: Cada solicitud se ejecuta en un thread independiente, por lo que el procesamiento de servlets es significativamente más rápido que el procesamiento tradicional de CGI. Los servlets son escalables, es decir, pueden atender muchas más solicitudes debido a que el contenedor web utiliza un thread en lugar de un proceso del sistema operativo, que es un recurso limitado del sistema. Los servlets son robustos y orientados a objetos. Cuando escribes un servlet tienes todas las capacidades de la tecnología Java, en lugar de las capacidades de Perl o cualquier otro lenguaje que pudieras usar para escribir scripts CGI.

9 Ventajas y desventajas de los servlets de Java Los servlets sólo pueden ser escritos en lenguaje Java, lo que los hace fáciles de escribir si conoces el lenguaje. Sin embargo, el uso de servlets para generar páginas con contenido dinámico requiere cierta experiencia en el desarrollo de aplicaciones. Los servlets son independientes de la plataforma porque están escritos en Java. Los servlets tienen acceso a capacidades de escribir en bitácoras (logs), que muchos programas CGI no tienen. El contenedor web provee servicios adicionales a los servlets, tales como manejo de errores y seguridad. Ventajas y desventajas de los servlets de Java Los servlets tienen las siguientes desventajas: Los servlets contienen tanto t lógica de negocios (business logic) como lógica de presentación (presentation logic). La lógica de presentación se encarga de mostrar la información al usuario. Un servlet genera respuestas HTML dentro del mismo código. La lógica de negocios es cualquier cosa que manipule datos para cumplir con algo, tal como almacenar datos. Los servlets deben tomar en cuenta los problemas que se derivan de la concurrencia (solicitudes que llegan al servidor al mismo tiempo).

10 Servidores de aplicaciones Las aplicaciones web tradicionalmente requieren implementar detalles complejos de bajo nivel para llevar a cabo funciones tales como: Manejo de estados y transacciones Multithreading Administración de conjuntos de recursos (pools) Servidores de aplicaciones La arquitectura Java EE está diseñada para ayudar a hacer las aplicaciones web más fáciles de escribir porque la lógica de negocios se organiza en componentes reutilizables. En la tradición de Java SE, Java EE también es independiente de la plataforma y basado en componentes, así que las aplicaciones web escritas para una plataforma que cumple con las especificaciones de Java EE deberían ser fácilmente transportadas a la plataforma de otro proveedor que también cumpla con las especificaciones de Java EE.

11 Servidores de aplicaciones Un contenedor Java EE contiene: Contenedor EJB. Administra la ejecución de enterprise beans para las aplicaciones Java EE. Los EJB y su contenedor se ejecutan en el servidor de aplicaciones Java EE. Contenedor de aplicaciones cliente. Administra la ejecución los componentes de aplicaciones cliente. Las aplicaciones cliente y su contenedor se ejecutan en el cliente. Contenedor Web. Administra la ejecución de los componentes JSP y servlets para las aplicaciones Java EE. Los componentes Web y su contenedor se ejecutan en el servidor de aplicaciones Java EE. Contenedor de applets. Administra la ejecución de applets. Consiste en un navegador y un plug-in de Java que se ejecutan juntos en el cliente. Servidores de aplicaciones La plataforma Java EE facilita una arquitectura en la que los componentes de negocios se colocan en una capa separada. Esto permite a las aplicaciones de interfaz gráfica (GUI) y aplicaciones web acceder a los mismos componentes comunes.

12 Servidores de aplicaciones La arquitectura Java EE refuerza características tales como escalabilidad, extensibilidad y facilidad de mantenimiento. Servidores de aplicaciones No todas las aplicaciones necesitan una arquitectura Java EE, aunque muchas con cualquier complejidad transaccional significante pudieran beneficiarse. Muchas aplicaciones comienzan siendo muy pequeñas y se construyen de manera incremental. Siempre es provechoso diseñar una aplicación de manera que pueda ser migrada a un diseño escalable y de múltiples capas conforme cambia el alcance del proyecto. En general hay cuatro tipos de aplicaciones web que pueden ser implementadas con la plataforma Java EE: HTML estático. HTML con páginas básicas JSP y servlets. Páginas JSP con componentes JavaBeans. Aplicaciones muy estructuradas que usan componentes modulares y EJB.

13 Servidores de aplicaciones La siguiente figura muestra una matriz con la relación entre la complejidad arquitectónica y la robustez, basado en la tecnología usada. Conforme se incrementa la riqueza y robustez de una aplicación web, también lo hace la complejidad. La complejidad de la aplicación puede ser administrada por un diseño adecuado que separe los aspectos de programación. El contenedor web y la plataforma Java EE proveen componentes que pueden ser usados para ayudar a manejar los diseños complejos de aplicaciones. Servidores de aplicaciones

14 Servidores de aplicaciones Uno de los contenedores más utilizados en la actualidad es Apache Tomcat, que es en sí un contenedor de servlets y no alcanza la categoría de servidor de aplicaciones, pero es suficiente para muchas de las aplicaciones que únicamente requieren ejecutar los tres primeros tipos de aplicaciones web mencionadas (HTML, JSP y servlets). Tomcat es un proyecto de desarrollo open source con licencia de código abierto, que no tiene costo. Existen además otros servidores de aplicaciones profesionales que pueden ejecutar cualquier aplicación Java EE que cumpla con las especificaciones. Servidores de aplicaciones Por ejemplo, Sun Microsystems está respaldando GlassFish Enterprise Server (de licencia open source), mientras que IBM tiene a WebSphere (con licencia comercial). Una lista de servidores de aplicaciones que cumplen con la especificación Java EE es: Sun Java System Application Server Platform Edition GlassFish Sun GlassFish Enterprise Server RedHat JBoss Application Server OW2 JOnAS Apache Geronimo Apache OpenEJB IBM WebSphere Application Server Oracle WebLogic Application Server SAP NetWeaver Application Server

15 Protocolo de Transferencia de Hipertexto (HTTP) En cualquier protocolo de comunicación, el cliente debe transmitir una solicitud y el servidor debe transmitir alguna respuesta significativa. En HTTP, la solicitud es algún recurso especificado en un URL. Si el URL especifica un documento estático, entonces la respuesta incluye el texto de ese documento. Puedes pensar en la solicitud y respuesta (request y response) como un sobre alrededor del URL (mas los datos) y el texto de respuesta. Protocolo de Transferencia de Hipertexto (HTTP) Método HTTP Descripción OPTIONS Solicitud de las opciones de comunicación disponibles en la cadena request/response. GET Solicitud i para obtener la información ió identificada ifi d por el URL de la petición. HEAD Idéntico a GET excepto en que no regresa ningún cuerpo de mensaje, únicamente los encabezados. POST Solicitud para que el servidor acepte la entidad enviada en el cuerpo del mensaje HTTP. PUT Solicitud para que el servidor almacene la entidad enviada en el cuerpo del mensaje HTTP. DELETE Solicitud para que el servidor borre el recurso identificado en el URL de la petición. TRACE Solicitud para que el servidor envíe de regreso al browser en el cuerpo del mensaje HTTP la información enviada en la solicitud. CONNECT Reservado para su uso con un proxy que pueda funcionar como túnel.

16 El método HTTP GET El método HTTP más común es la solicitud GET. Un método GET es usado siempre que el usuario hace clic en un hipervínculo en la página HTML que está viendo actualmente. También se usa cuando un usuario escribe una dirección (URL) en la barra de dirección de su navegador. Al mismo tiempo que se procesan las páginas web, el navegador también realiza solicitudes GET cuando pide las imágenes, applets, hojas de estilo y otros recursos. HTTP Request y HTTP Response El flujo de la solicitud funciona como un sobre para el URL y el cuerpo del mensaje que envía el cliente. La primera línea del flujo de la solicitud se llama request line, e incluye el método HTTP (generalmente GET o POST), seguido de un espacio, y a continuación el URL solicitado, seguido de otro espacio y finalmente el número de la versión de HTTP usado. Después del request line sigue cualquier cantidad de líneas de encabezado de solicitud, que incluyen información tales como el tipo de navegador usado, el idioma y otros datos.

17 HTTP Request y HTTP Response El flujo de respuesta funciona como un sobre para el cuerpo del mensaje de la respuesta HTTP del servidor. La primera línea se llama status line, que incluye el número de versión de HTTP, seguido de un espacio y un código numérico con el código de estado de la respuesta, otro espacio y finalmente un breve mensaje indicando el código de estado. Después del status line puede haber varias líneas de encabezado de respuesta y al final el cuerpo del mensaje, que típicamente lleva el contenido HTML que será mostrado en el navegador. Desarrollo de un servlet HTTP Un desarrollador de servlets HTTP debe proveer una clase de Java que sea usada para responder a las solicitudes del navegador del cliente. Para crear un servlet que responda a una solicitud HTTP, debes crear una clase que herede de la clase abstracta HttpServlet (contenida en el paquete javax.servlet.http ). El método service de HttpServlet identifica el tipo de método HTTP recibido en el flujo de la solicitud it HTTP y ejecuta el método doxyz que corresponde al método HTTP que llega. Por ejemplo, si el servlet necesita responder a una solicitud HTTP GET, debes rescribir el método doget.

18 Desarrollo de un servlet HTTP La información de HTTP Response es encapsulada por la interfaz HttpServletResponse. Puedes especificar un encabezado de respuesta usando el método setheader. También, la interfaz HttpServletResponse te da acceso al cuerpo del flujo de respuesta. El cuerpo de respuesta se encapsula en un objeto de flujo de Java (output stream). Necesitas generar el texto de respuesta que será enviado desde el servidor al navegador. Debes primero obtener el flujo del cuerpo usando alguno de los métodos getwriter (si generas una respuesta HTML) o getoutputstream (si vas a generar una respuesta binaria, como la transmisión de una imagen). Desarrollo de un servlet HTTP También es necesario establecer el tipo de contenido (content type) o tipo MIME del texto de respuesta. Este es el encabezado que le dice al navegador web cómo debe interpretar el cuerpo de la respuesta HTTP para mostrarlo. Los ejemplos de tipos MIME incluyen text/plain, text/html, image/jpeg, image/png, audio/au, etc. Por omisión, el tipo MIME para los servlets es text/plain, pero puede especificarse uno diferente con el método setcontenttype.

19 Configuración de la definición de un Servlet El archivo web.xml es el archivo de configuración más importante en las aplicaciones web hechas con Java, y es conocido como un deployment descriptor y usado por el contenedor web para configurar los servlets. En este fragmento del web.xml, se le asigna el nombre Saludo a la clase del servlet HolaServlet. <servlet> <servlet-name>saludo</servlet-name> <servlet-class>holaservlet</servlet-class> </servlet> Configuración de la definición de un Servlet El URL que se usará para invocar al servlet también se configura en el archivo web.xml. En este ejemplo, el servlet Saludo será accedido usando el patrón URL /saludo.view. <servlet-mapping> <servlet-name>saludo</servlet-name> <url-pattern>/saludo.view</url-pattern> </servlet-mapping>

20 Configuración de la definición de un Servlet El contenedor web recibe una solicitud HTTP para URLs específicos, y debe buscar su correspondencia en el web.xml para determinar cuál servlet deberá ejecutar. Por ejemplo, para acceder al servlet recién configurado, debes usar el URL: Interacción de Servlets con formularios HTML Los formularios HTML son el recurso utilizado para enviar datos del cliente hacia el servidor web para ser procesados. El navegador web sólo muestra el formulario, no procesa datos en el formulario. El botón submit en un formulario envía los datos al contenedor web en un HTTP Request. Los formularios se basan en etiquetas HTML (tags) que tienen la función específica de mostrar controles que interactúen con el usuario, permitiéndole escribir datos, seleccionar una opción de una lista, etc. A continuación ió se presentarán algunas de las etiquetas más comunes utilizadas en los formularios.

21 Interacción de Servlets con formularios HTML La etiqueta form El componente para campos de texto El componente para listas desplegables El componente para enviar los datos Envío de datos del formulario Procesamiento de datos del formulario en el Servlet Sesiones en el contenedor web HTTP es un protocolo que no mantiene el estado de la conexión (stateless). Cada conexión de mensajes de request y response es independiente de las demás. Esto es relevante porque de una solicitud a otra (del mismo usuario) el servidor HTTP no mantiene una referencia a la solicitud anterior. Así que el contenedor web debe crear un mecanismo para almacenar la información de la sesión de cada usuario en particular. Para poder administrar sesiones se requiere un contenedor web. Las sesiones son un mecanismo para almacenar datos específicos de un cliente a través de múltiples solicitudes de HTTP. A esto se le llama el alcance de sesión.

22 Sesiones en el contenedor web Administración de sesiones usando Cookies El RFC número 2109 de la Internet Engineering Task Force (IETF) crea una extensión a HTTP que le permite a un servidor web almacenar información en la máquina del cliente. Las cookies son enviadas al cliente en una respuesta desde el servidor web. Las cookies se almacenan en la computadora del cliente. Las cookies se almacenan en una partición asignada al nombre del dominio del servidor web. Las cookies pueden ser posteriormente reclasificadas en una ruta dentro del dominio.

23 Administración de sesiones usando Cookies Todas las cookies del dominio son enviadas en cada solicitud al servidor web. Las cookies tienen un cierto tiempo de vida y son borradas por el navegador del cliente al finalizar su tiempo de vida, o por solicitud del usuario al navegador. En el siguiente ejemplo, hay un visitante en el sitio web y quieres almacenar su nombre, de tal manera que en la siguiente visita al sitio se muestre la pantalla personalizada con su nombre. Para almacenar la cookie, el servlet debe contener: String nombre = request.getparameter("nombre"); Cookie c = new Cookie("tunombre", nombre); response.addcookie(c); Administración de sesiones usando Cookies Después, cuando el visitante regrese, el servlet puede acceder a la cookie tunombre usando el código: Cookie[] lascookies = request.getcookies(); for (int i=0; i < lascookies.length; i++) { if (lascookies[i].getname().equals("tunombre" )) { nombre = lascookies[i].getvalue(); } }

24 Administración de sesiones usando Cookies Puedes usar cookies de HTTP para administrar las sesiones. El contenedor web almacena el identificador de sesión (session ID) en la máquina del cliente. Cada solicitud HTTP del cliente incluye la cookie de ID de sesión que fue almacenada en la máquina del cliente. Errores más comunes en la programación Un error común en los servlets al leer parámetros de la solicitud (request.getparameter()) es no validar que en efecto el parámetro tenga un valor. Si el usuario en el formulario no capturó algún dato, el parámetro llega al servidor como null, lo que podría generar una excepción en Run-time (NullPointerException). Lo más conveniente es siempre validar que el parámetro no sea null o, mejor aún, identificarlo desde el navegador usando JavaScript.

25 Cierre Conocer la forma en que funcionan los Servlets de Java, así como el protocolo HTTP, es uno de los requerimientos para el correcto desarrollo de las aplicaciones Web. Las aplicaciones para Internet están siendo cada vez más requeridas en sistemas empresariales que demandan a su vez mayor capacidad de cómputo y agilidad en las respuestas. A pesar de no ser la única alternativa para el desarrollo de tales aplicaciones, los Servlets han demostrado ser mucho más eficientes que sus contrapartes en otros lenguajes de programación para servidores, al utilizar hilos en lugar de procesos completos para cada solicitud, aligerando enormemente la carga de un servidor web; esto se deriva en un mejor manejo de la concurrencia y de las sesiones. Cierre Sin embargo, el desarrollo de Servlets puede ser complicado en ocasiones cuando se trata de enviar el contenido HTML al navegador. Las páginas JSP fueron la respuesta inmediata a la necesidad de tener mayor capacidad de programación sin sacrificar la presentación de contenidos en el cliente. En la siguiente lección aprenderás cómo se lleva a cabo el desarrollo de páginas JSP como una alternativa a la programación directa de Servlets.

26 Referencias bibliográficas Sun Microsystems (2008). Web Component Development with Servlet and JSP Technologies. Sun Microsystems, Inc. Créditos Diseño de contenido: Ing. Romeo Alfonso Sánchez López Coordinador académico: L.I. Oscar Andrés Rodríguez Múgica, MATI Edición de contenido: Lic. María Teresa Grosso Espinosa, MEE Edición de texto: Lic. Arcelia Ramos Monobe, MEE Diseño Gráfico: Lic. Miguel Angel Reynosa Castro, MANM