0% encontró este documento útil (0 votos)
12 vistas66 páginas

Módulo 2 Unidad 2

Programacion en JAVA Nivel 0

Cargado por

luis
Derechos de autor
© © All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como PDF, TXT o lee en línea desde Scribd
0% encontró este documento útil (0 votos)
12 vistas66 páginas

Módulo 2 Unidad 2

Programacion en JAVA Nivel 0

Cargado por

luis
Derechos de autor
© © All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como PDF, TXT o lee en línea desde Scribd
Está en la página 1/ 66

Unidad 02

Servlet API

Copyright © Marzo de 2022 por TECSUP


1
Introducción
• En la presente unidad, se detallan diversos conceptos
sobre el desarrollo Web con Java.
• La librería base para crear aplicaciones Web con Java es
Servlet. Esta librería proporciona las clases y métodos
para desarrollar la capa Web de un proyecto Java.
• Las aplicaciones Web requieren un servidor de
aplicaciones. En esta unidad se detallan cuáles se podrían
utilizar para Java.

2
Objetivos
• Describir el funcionamiento de una aplicación Web.
• Explicar el funcionamiento del protocolo HTTP y como
afecta a las aplicaciones Web.
• Describir las bondades de la plataforma JavaEE.
• Definir la estructura de la aplicación Web en Java.
• Listar los servidores de aplicaciones que se encuentran
disponibles para Java.
• Escribir clases Servlet.

3
Índice
Tema 1: Introducción a la arquitectura Web
Tema 2: Protocolo HTTP
Tema 3: Introducción a la arquitectura JavaEE
Tema 4: Estructura de la aplicación Web
Tema 5: Servidores de aplicaciones
Tema 6: Servlet API

4
Tema 1:
Introducción a la arquitectura Web

Copyright © Marzo de 2022 por TECSUP


5
Introducción
• En la ingeniería de software se denomina aplicación Web
a aquellas aplicaciones que los usuarios pueden utilizar
accediendo a un servidor Web a través de Internet o de
una intranet mediante un navegador.
Paradigma Cliente/Servidor
• Patrón arquitectónico para el desarrollo de sistemas
distribuidos.
• Distribuye una aplicación entre 2 o más componentes
especializados cuya ejecución se distribuye entre 1 o más equipos.
• Define un modelo de interacción basado en el concepto de servicio
implementado sobre un diálogo petición-respuesta.
• Cliente inicia el diálogo mediante el envío de peticiones.
• Servidor presta el servicio en que se sincronizan los procesos.
Paradigma Cliente/Servidor
• Especifica el modo en que se sincronizan los procesos:
• Cliente (Parte activa)
• Demanda servicios a los servidores
• Se asume que cada petición deberá obtener respuesta
• Diseñado para soportar la interacción con el usuario final
• Servidor (Parte pasiva)
• Espera las peticiones de los clientes
• Procesa esas peticiones y envía una respuesta
• Diseño orientado a maximizar la eficiencia.
• Posibilidad de aplicar el patrón cliente – servidor en
múltiples niveles de abstracción dentro de un mismo
sistema distribuido (arquitecturas multinivel [n-tier] )
Componentes de los Sistemas Cliente / Servidor
• Características de los clientes
• Componente del sistema que interactúa con el usuario.
• No comparte sus recursos con otros clientes.
• No suelen tener restricciones especiales respecto a rendimiento,
fiabilidad y escalabilidad
• No suele requerir equipos de altas prestaciones
• Fallo de un cliente no afecta el resto.
• Debe dar soporte a restricciones relativas a ergonomía (facilidad
de uso) y seguridad (evitar comprometer los demás componentes).
Componentes de los Sistemas Cliente / Servidor
• Características de los servidores:
• Componente del sistema que presta servicios a los clientes.
• Gestiona y comparte sus recursos con los clientes y a los que
sirve.
• Suele tener restricciones especiales respecto al rendimiento,
fiabilidad, escalabilidad y seguridad.
• Capacidad suficiente para atender múltiples clientes
• Fallos en el servidor son críticos e invalidan el sistema
• El número de clientes (peticiones) puede ser muy variable y
aumentar si así se requiere
• Evitar comprometer la seguridad de los recursos o datos
gestionados y de los clientes.
Modelos y tipologías
• Esquema abstracto de aplicaciones distribuidas genéricas (capas). Se
corresponden con las funciones típicas de un sistema.
• Capa de presentación (interfaz de usuario)
• Interacciona con el usuario, presenta los datos y recibe las entradas.
• Capa de aplicación/negocio (lógica de aplicación)
• Responsable de las tareas propias de la aplicación concreta.
• Implementa la lógica de la aplicación y aplica las reglas de negocio
sobre los datos y las entradas de usuario.
• Capa de datos (almacenamiento y acceso a datos)
• Responsable de la gestión y almacenamiento permanente de los
datos.
• Cada tipo de sistema cliente-servidor distribuye esas capas de modo
distinto entre los componentes cliente y servidor
Arquitectura Web
Ventajas de la arquitectura Web
• Actualización automática
– Según el paradigma cliente/servidor, la lógica de la aplicación se
encuentra centralizada. Los clientes son ligeros.
• Multiplataforma
– Diferentes arquitecturas de hardware
– Diferentes sistemas operativos
– Diferentes navegadores Web
• Portable
– Tecnologías como Java permiten crear aplicaciones Web portables.
– Clientes ligeros sólo necesitan soportar el estándar HTML.
• Alta disponibilidad
– Servidores Web replicados en la misma y/o diferentes ubicaciones
geográficas.
Desventajas de la arquitectura Web
• Menos funcionalidades que aplicaciones Desktop (de
escritorio)
• Tradicionalmente, los navegadores Web presentan funciones
limitadas.
• Tendencia de nuevas formas de crear aplicaciones Web con Ajax,
RIA, entre otros.
• Requiere conexión a Internet
• Al menos que sea una sistema intranet.
Tema 2:
Protocolo HTTP

Copyright © Marzo de 2022 por TECSUP


15
Hypertext Transfer Protocol
• El Hypertext Transfer Protocol es un protocolo sin estado
basado en petición – respuesta.
• Es el protocolo usado en cada transacción de la Web
(WWW).
• HTTP fue desarrollado por el consorcio W3C y la IETF,
colaboración que culminó en 1999 con la publicación de
una serie de RFC.
• Un cliente envía una petición HTTP para obtener un
recurso y el servidor le devuelve una respuesta HTTP con
el recurso deseado, como se muestra a continuación en
el gráfico.
Hypertext Transfer Protocol
Tema 3:
Introducción a la arquitectura JavaEE

Copyright © Marzo de 2022 por TECSUP


18
JavaEE
• Java Platform, Enterprise Edition o Java EE
(anteriormente conocido como Java 2 Platform, Enterprise
Edition o J2EE hasta la versión 1.4), es una plataforma de
programación—parte de la Plataforma Java—para
desarrollar y ejecutar software de aplicaciones en
Lenguaje de programación Java con arquitectura de N
niveles distribuida, basándose ampliamente en
componentes de software modulares ejecutándose sobre
un servidor de aplicaciones.
JavaEE: Arquitectura n-tier
JavaEE: API’s y tecnologías
Web Container
• El contenedor Web implementa el contrato de
componentes Web de la arquitectura J2EE.
• Este contrato especifica un entorno de ejecución para los
componentes Web que incluye la seguridad, concurrencia,
gestión de ciclo de vida, operación, despliegue y otros
servicios.
• Un contenedor Web maneja la ejecución de las páginas
JSP y componentes Servlet para aplicaciones JavaEE.
Tema 4:
Estructura de la aplicación Web

Copyright © Marzo de 2022 por TECSUP


23
Estructura de directorios

• WEB-INF: Este directorio contiene la información que necesita el


contenedor Web para iniciar la aplicación. No se puede acceder
públicamente.
• classes: Este directorio contiene a las clases Java compiladas.
• lib: Contiene a las librerías adicionales que requiere el proyecto.
• web.xml: Conocido como descriptor de despliegue de la
aplicación Web. Todos los proyectos Web tienen este archivo.
Descriptor web.xml
• Archivo de aplicación web.
• Contiene valores de configuración propios de una
aplicación o módulo web.
• Se registran los servlets, filters, la página de inicio, el
tiempo máximo de expiración de una sesión, seguridad,
entre otros.
• Ubicado en el directorio WEB-INF de la aplicación web.
Tema 5:
Servidores de aplicaciones

Copyright © Marzo de 2022 por TECSUP


26
Características
Características
• El Servidor de Aplicaciones se encuentra compuesto por
tres componentes: un “servidor de páginas Web”, un “Web
Container" y un "EJB Container“.
• Dentro del “Web Container" se ejecutan exclusivamente
las clásicas aplicaciones de basadas en JSP's ("Java
Server Pages") y Servlets.
• Mientras el "EJB Container" es reservado para
aplicaciones desarrolladas alrededor de EJB's "Enterprise
Java Bean's".
• Casi todos los servidores de aplicaciones en el mercado
hoy en día son conocidos como "Fully JEE Compliant",
este termino implica que se cumplen todas las
especificaciones JavaEE definidas.
Servidor de aplicaciones
• Cuando utiliza un servidor de aplicaciones como alguno de
los siguientes ("Fully JEE Compliant"):
– Oracle WebLogic
– IBM WebSphere Application Server
– GlassFish
, no existe una clara distinción entre el "Web Container" y
"EJB Container", es decir, es posible ejecutar tanto
JSP/Servlets así como EJB's, sin embargo, el ambiente se
encuentra altamente integrado para que sea transparente
(al menos para el programador final) la comunicación entre
JSP/Servlets y EJB's.
Servidores
• Open Source
– Tomcat (sólo Web container)
– GlassFish
– Jboss
– Geronimo
• Comerciales
– IBM WebSphere Application Server
– Oracle WebLogic
– SAP Netweaver
Tema 6:
Servlet API

Copyright © Marzo de 2022 por TECSUP


31
Servlets
• Un Servlet es una Clase de Java que se ejecuta en el Web
Container (llamado también contenedor de Servlets).
• La especificación de Servlet proporciona un estándar y un
framework independiente de la plataforma para la
comunicación entre los servlets y contenedores.
• Este framework es un conjunto de Clases e Interfaces.
• Estas Clases e Interfaces conforman el Servlet API.
• Un servlet puede manejar múltiples requerimientos de
concurrencia y puede sincronizarlos.
• Los servlets pueden redireccionar los requerimientos a
otros servlets.
Servlet API
Ciclo de Vida de un Servlet
Ciclo de Vida de un Servlet
• Carga e inicialización del Servlet
• En forma predeterminada la clase HttpServlet inicializa el Servlet.
• Para adicionar una inicialización personalizada se debe
sobreescribir el método init().
• Servicio del Servlet
• Atiende a las peticiones POST o GET de los clientes. El método
service() invoca a doPost() o doGet(), según sea el caso.
• Destrucción el Servlet
• El método destroy() destruye el servlet.
• Para destruir algún recurso específico del Servlet se debe
sobreescribir el método destroy().
Interface Servlet
• La interface Servlet es la central abstracción del Servlet
API.
• Todos los Servlet se implementan de esta interface, en forma
directa o indirecta (a través de la clase extendida HttpServlet )
• Cuando un Servlet acepta un requerimiento desde un
cliente recibe 2 objetos:
• ServletRequest: Encapsula la comunicación del cliente al servidor.
• ServletResponse: Encapsula la comunicación del servidor al
cliente.
Interface Servlet
Interface ServletRequest
• La interface ServletRequest permite al Servlet acceder a:
• Información enviada por el cliente.
• El protocolo usado por el cliente.
• El nombre del cliente, dirección IP, navegador utilizado.
• Suministra el flujo de entrada de ServletInputStream.
• Las interfaces que se extienden de la interface
ServletRequest permiten obtener más información de un
protocolo específico.
• La interface HttpServletRequest contiene métodos para
acceder a la información de cabecera del HTTP.
Interface HttpServletRequest
• Acceso a datos del cliente :
• El método getParameter() retorna el valor de un parámetro y lo
almacena como String.
• El método getParameterValues() retorna los valores de los varios
parámetros (checkboxes, listas desplegables múltiples) y lo
almacena en un String[].
• El método getParameterNames() provee los nombres de los
parámetros y lo almacena un java.util.Enumeration.
Interface HttpServletRequest
• Método HTTP GET
• Es utilizado para recuperar un recurso.
• También para enviar información en texto plano al Servlet.
• La información enviada por URL utiliza GET:
• http://localhost/TestServlet?id=drodriguez
• Los hiperenlaces utilizan GET.
• Método HTTP POST
• Utilizado para enviar datos al Servlet (texto plano o documentos)
• Se configura en los formularios:
<form method=“post”>
Interface ServletResponse
• La interface ServletResponse provee los métodos para
contestar al cliente:
• Suministra un flujo de salida ServletOutputStream y un Writer a
través del cual el Servlet puede enviar datos al cliente.
• Permite al Servlet configurar el tipo MIME (Multipurpose Internet
Mail Extension) a enviar.
• Las interfaces que se extienden de la interface
ServletResponse permiten aumentar las capacidades de
un protocolo específico.
• La interface HttpServletResponse contiene métodos que permiten
manipular la información de cabecera del HTTP.
Interface HttpServletResponse
• El objeto HttpServletResponse provee dos formas de
enviar datos al cliente :
• El método getWriter() que retorna un objeto PrintWriter. Este objeto
le permite al Servlet enviar texto plano (como HTML) al cliente.
• El método getOutputStream() que retorna un objeto
ServletOutputStream. Este objeto le permite al Servlet enviar datos
en binario (doc, pdf, exe, ppt, zip, entre otros) al cliente.
Formularios con Servlet
• Los objetos o componentes HTML que permiten
interactuar con los usuarios son los formularios.
• Los formularios brindan al desarrollador Web diferentes
componentes para poder obtener información dinámica de
los usuarios.
• Para poder manejar formularios debemos conocer la
estructura de las etiquetas.
Formularios con Servlet
Formularios con Servlet
<html><body>
<form action=“RecServlet" method="post">
Nombre : <input name="nom" type="text">
Apellidos:<input name="ape" type="text">
<input type="submit" value="Aceptar">
</form>
</body></html>
Formularios con Servlet
• Para poder recuperar los valores del formulario debemos
verficar:
• El destino del formulario (action=" RecServlet ")
• El método de envio (method="post").
• Los parámetros o variables a enviar:
• nombre (name="nom")
• apellido (name="ape")
Formularios con Servlet
• Con la información reconocida podemos crear el Servlet.

public class RecServlet extends HttpServlet { public void


doPost(HttpServletRequest request, HttpServletResponse
response)
throws IOException, ServletException {
String nom = request.getParameter("nom”);
String ape = request.getParameter("ape");
}
Cooperación y comunicación de
Servlets

Copyright © Marzo de 2022 por TECSUP


Cooperación de Servlets
• Se usa para repartir la carga de una aplicación o hacer un
requerimiento de algún recurso de la aplicación.
• Para utilizar los recursos del Servidor se debe manejar
dos procesos:
• Obtener el objeto RequestDispatcher .
• Reenviar el requerimiento del cliente o incluir la respuesta del
recurso.
Cooperación de Servlets
• Obtener el objeto RequestDispatcher:
• Se obtiene el objeto RequestDispatcher usando el método
getRequestDispatcher del objeto ServletContext.
• Reenviar el requerimiento del cliente:
• Se usa el método forward del objeto RequestDispatcher.
• Si se accede antes al objeto PrintWriter o ServletOutputStream no
se podrá usar el método forward.
Cooperación de Servlets
• Obtener el objeto RequestDispatcher:
• RequestDispatcher dispatcher =
getServletContext().getRequestDispatcher(“/respuesta.jsp”);

• Reenviar el requerimiento del cliente :


• dispatcher.forward(request,response);
Cooperación de Servlets
• Incrementar la respuesta del recurso :
• Usa el método include del objeto RequestDispatcher para llamar a
un servlet y usar el objeto RequestDispatcher asociado al recurso
para formar parte de la respuesta al cliente.

RequestDispatcher dispatcher =
getServletContext().getRequestDispatcher(“/dentro.jsp”);
PrintWriter out = res.getWriter(); out.println(“ANTES”);
dispatcher.include(request,response);
out.println(“DESPUES”);
Comunicación de Servlets
Comunicación de Servlets
• Los servlets de una aplicación pueden compartir recursos
usando alguno de los ambientes o scopes:
• Context (o application)
• Session
• Request
• Page
Comunicación de Servlets
• Estos ambientes o scopes tienen los siguientes métodos:
• setAttribute(nombre, valor)
• getAttribute(nombre)
• removeAttribute(nombre)
Sesiones

Copyright © Marzo de 2022 por TECSUP


Session Tracking
• El seguimiento de sesiones es necesario para mantener el
estado entre el Servlet y el cliente que persiste en
múltiples conexiones durante un tiempo determinado.
• El seguimiento de sesiones se realiza de las siguientes
formas:
• Cookies
• URL Rewriting
• Hidden Fields
Session Tracking
• ¿Cómo el servidor puede mantener una sesión con un
cliente si el HTTP no proporciona ningún mecanismo de
recordar al cliente?
• Cuando el servidor recibe la primera petición del cliente, el servidor
inicia una sesión y le asigna un identificador único.
• El cliente debe incluir este identificador único en cada
requerimiento subsiguiente. El servidor inspecciona el identificador
y asocia la petición con la correspondiente sesión.
Session Tracking
Session Tracking
• Cookies
• Consiste en almacenar ese ID de sesión en una cookie del cliente:
• JSESSIONID=61C4F23524521390E70993E5120263C6
• URL Rewriting
• Consiste en agregar el ID en la URL. Es utilizado cuando el
soporte a cookies ha sido deshabilitado.
• <a href= "/ReportServlet;JSESSIONID=C084B32241B58114">
Reporte </a>
Session Tracking
• Hidden Fields
• Consiste en agregar el ID en campos ocultos de HTML:
• <input type=“hidden” name=“JSESSIONID”
value=“C084B32241B58114”/>
HttpSession
• El Servlet API trae el soporte de sesiones en la interfase
javax.servlet.http.HttpSession.
• El contenedor de Servlet crea un nuevo objeto
HttpSession cuando inicia una sesión para un cliente.
• Además de representar la sesión, este objeto actúa como
un contenedor para la información relacionada a la sesión.
• Normalmente, se necesitan hacer 3 acciones con una
sesión HTTP:
• Recuperar la sesión asociada con la petición.
• Agregar o remover atributos de sesión.
• Cerrar o invalidar la sesión si es necesario.
HttpSession
• Usualmente, un cliente no ofrece ningún indicador de que
ha terminado la sesión. En este caso, el servidor nunca
sabrá si el cliente ha terminado la sesión o no.
• Para ayudarnos en este trabajo, el contenedor cerrará
automáticamente la sesión después de un cierto periodo
de tiempo de inactividad del usuario.
• Este período de tiempo es configurado en minutos en el
web.xml.
HttpSession
• Recuperar la sesión:
• HttpSession session = request.getSession();
• Agregar un objeto a la sesión:
• session.setAttribute(NOMBRE, OBJETO);
• Recuperar un objeto de la sesión:
• Object lista = (Object)session.getAttribute(NOMBRE);
• Invalidando una sesión:
• session.invalidate();
HttpSession
• Tiempo de expiración de la sesión
• La configuración se realiza en el web.xml. El tiempo establecido
está en MINUTOS. El valor 0 indicaría que la sesión nunca
expirará.
<web-app>
<session-config>
<session-timeout>30</session-timeout>
</session-config>
</web-app>
Conclusiones
• Las aplicaciones Web se despliegan en servidores como
el Apache Tomcat, Jboss AS, entre otros.
• Los Servlet con clases Java que permiten manejar
peticiones HTTP. Estas clases deben heredar de la clase
HttpServlet.
• Los Servlet disponen de dos métodos: doGet y doPost.
Estos métodos manejarán las peticiones Web de acuerdo
al método HTTP que se utilice.

66

También podría gustarte