Curso: Programación Web con Tecnología Java

Curso: Programación Web con Tecnología Java

Enero 2008 V1.0

1. Introducción

4. Tecnología Java Servlets

Índice

2. Contenedores Web

CORT412: Programación Web con Tecnología Java

5. Sesiones

6. Modelo Vista Controlador

8. Opciones Avanzadas

7. Tecnología JavaServer Pages

3. Entorno de trabajo


1.1. Objetivos del curso

1.3. Concepto de URL

1. Introducción

1.2. El protocolo HTTP

1.4. Componentes para capa de presentación y lógica de negocio.

1.2. Un poco de historia

1. Introducción

1.1. Objetivos del curso

Lo que pretendemos con este curso es ser capaces de:

· Desarrollar aplicaciones Web usando tecnología Java: Servlets y JSP’s.

· Conocer los principios del patrón de diseño MVC y desarrollar aplicaciones robustas que sean capaces de gestionar sesiones y controlar eficazmente los errores.

· Desarrollar aplicaciones seguras cuando sea necesario.

· Desarrollar aplicaciones que puedan ser usadas a la vez por múltiples usuarios.

Además, durante el curso aprenderemos:

· Cómo trabajar con el entorno de desarrollo Eclipse.

· Cómo trabajar con el servidor de aplicaciones Web Tomcat.

· Cómo trabajar con bases de datos cuando desarrollamos en tecnología Java.

· Cómo desarrollar una aplicación web siguiendo el patrón de MVC.

1. Introducción

1.2. Un poco de Historia

La arquitectura de software de los últimos años ha ido evolucionando a la vez que la tecnología informática.

Se comenzó con los sistemas monolíticos donde el sistema sólo conocía su entorno de operación.

Con la aparición de las redes, surgió el sistema Cliente – Servidor, que es el que permite que un sistema interactúe con otros sistemas.

1. Introducción

1.2. Un poco de Historia (II)

Con Internet llegó el desarrollo de software por componentes, lo que permitía tener una aplicación distribuida con varios servidores y clientes ligeros, pero el contenido de las páginas era estático.

Para solucionar el problema del dinamismo aparecieron los Servlets y jsp, permitiendo separar las funciones de negocio con las de presentación.

Aparece la programación en capas, con objeto de incluir la mayor parte de lógica posible en el servidor, para que la funcionalidad del cliente sea simplemente de presentación.

El objetivo es dividir la funcionalidad en capas lógicas que se encapsulan como componentes que interactúan entre ellos a alto nivel.

La programación en capas más utilizada es la de tres capas:

• Funciones de BBDD en la capa de Base de Datos.

• Lógica de operación en la capa de Negocio.

• Funciones de interfaz de usuario en la capa de Presentación.

1. Introducción

1.2. Un poco de Historia (III)

1. Introducción

1.2. Un poco de Historia (IV)

Ventajas del sistema de capas:

• Realización de cambios sin tener que modificar toda la aplicación.

• Mayor portabilidad de las aplicaciones.

• Mayor escalabilidad a la aplicación.

Inconvenientes:

• Mayor esfuerzo de diseño.

• Mayor complejidad entre los componentes y la interacción entre ellos.

1. Introducción

1.2. El protocolo HTTP

Es el protocolo de comunicación más utilizado en las aplicaciones web.

Es un protocolo de alto nivel, que se asienta sobre TCP/IP.

Se desarrolla con la intención de realizar intercambios de información basados en enlaces (hipertexto e hipermedia) y en marcas de presentación (tags).

Las comunicaciones HTTP tienen dos partes: la petición y la respuesta. Una respuesta HTTP puede ser un documento de cualquier tipo, aunque lo más habitual es que sea una página HTML.

No es un protocolo permanente. Esto quiere decir que una vez que se transmite una petición, la conexión se destruye, e igualmente ocurre cuando se transmite una respuesta.

Los Métodos que definen este protocolo son:

• HTTP Request

• HTTP Response

1. Introducción

1.3. Concepto de URL

Una URL es una cadena con un formato especial que nos permite localizar un recurso en cualquier ordenador accesible mediante el protocolo TCP/IP.

Fijémonos en la siguiente URL:

http://www.servidor.org:7654/contexto/ruta/recurso?param1=valor1&param2=valor2

Las partes que la componen son las siguientes:

· El protocolo: http· El ordenador: www.servidor.org· El puerto: 7654· El contexto/aplicación: contexto· La ruta de acceso al recurso: ruta· El nombre del recurso: recurso· Parámetros que pasamos al recurso: param1=valor1&param2=valor2

1. Introducción

1.4 Componentes para la capa de presentación y lógica de negocio (I)

Un servlet es un componente web manejado por un contenedor que genera un contenido dinámico.

Es un programa que se ejecuta en un servidor Web y genera una página Web dinámicamente.

Un servlet es la respuesta java a la tecnología CGI.

La construcción de páginas web dinámicamente es muy útil en los siguientes casos:

• El contenido de la página es a petición del cliente.

• Los datos cambian constantemente.

• La página web utiliza la base de datos corporativa u otras fuentes.

1. Introducción

1.4 Componentes para la capa de presentación y lógica de negocio (II)

La principal diferencia entre Servlet y CGI es que un servlet siempre tiene una copia de la clase instanciada y N thread que acceden a él. En el caso del CGI se instancia una copia de la clase cada vez que se invoca al programa.

Las ventajas de los servlets sobre los CGIs son:

• Eficiencia

• Flexibilidad

• Portabilidad

1. Introducción

1.4 Componentes para la capa de presentación y lógica de negocio (III)

JSP (Java Server Pages) es una página que combina código HTML o XML con código Java para conseguir páginas dinámicas.

Cada página se compila como si fuese un servlet cuando se invoca y a continuación se ejecuta.

Las ventajas de un Jsp son:

• Sobre ASP: La parte dinámica está escrita en Java y es portable a otros sistemas operativos, mientras que ASP está escrito en Visual Basic.

• Sobre Servlets: Es más cómodo de modificar porque está escrito con HTML.

• Sobre JavaScript: El lenguaje JavaScript permite dar un dinamismo a la página web, pero sólo a nivel del cliente. No puede acceder a la parte del servidor, por lo que es imposible que acceda a la base de datos y otros recursos.


2.4. Deployment Descriptor

2. Contenedores Web

2.3. Estructura de una aplicación Web

2.5. Tipos de contenedores web

2.2. Contenedores y Aplicaciones Web

2.1. Métodos del protocolo HTTP

2. Contenedores Web

2.1. Métodos del protocolo HTTP (I)

Los métodos principales de HTTP Request son:

• Get: Es el método más simple y más utilizado para la petición de los recursos estáticos.

Cuando se utiliza para pedir recursos que se generan dinámicamente se le pasan parámetros de entrapara para obtener la respuesta.

Transmite los parámetros como cadena concatenada en la URL.

La forma de la URL con el método get es:

http://www.dominio.com?parametro1=valor1

El inconveniente es que algunos navegadores limitan el tamaño de la URL.

• Post: Es el más usado para obtener recursos generados de forma dinámica, subir ficheros al servidor, etc.

Los parámetros se pasan en el cuerpo de la petición y ofrece una mayor elección del contenido de la petición.

2. Contenedores Web

2.1. Métodos del protocolo HTTP (II)

El método HTTP Response, contiene el estado de la respuesta y la información que describe la respuesta.

La cabecera de la respuesta lleva el estado.

El cuerpo de la respuesta lleva el contenido.

En HTTP, servidores y clientes usan MIME (Multi-Purpose Internet Mail Extension) para indicar el tipo de contenido en la petición y la respuesta.

Ejemplo: text/html

La primera parte indica el tipo de respuesta.

La segunda parte indica la extensión estándar.

Los servidores HTTP emplean cabeceras MIME al inicio de cada transmisión.

Los navegadores emplean dicha información para decidir como mostrar el resultado de la petición.

2. Contenedores Web

2.2. Contenedores y Aplicaciones Web (I)

Para generar aplicaciones web tenemos los siguientes elementos:

• Servlets y Jsp’s: Son los componentes web básicos para crear una aplicación web.

• Aplicaciones Web: Es un conjunto de componentes web y de recursos estáticos.

• Contenedor Web: Es un entorno de ejecución creado en java, en el que están contenidos todos los componentes web y las librerías necesarias para que funcione la aplicación.

• Descriptor de despliegue: Es un fichero xml que contiene la descripción de configuración de cada aplicación web.

2. Contenedores Web

2.2. Contenedores y Aplicaciones Web (Servlets) (II) Los servlets son pequeños programas, independientes de la plataforma, que residen en

un servidor y que permiten extender la funcionalidad de un servidor web mediante programación.

Están escritos 100% en java.

Se definen en la especificación Java Servlet API 2.2 / 2.3 que se encuentra en http://java.sun.com/products/servlet.

Un servlet se invoca por el contenedor web en el que esté desplegada la aplicación.

El contenedor web es el que enlaza las peticiones web del usuario con los servlets desplegados.

2. Contenedores Web

2.2. Contenedores y Aplicaciones Web (JSP) (III)

Los Jsp’s son los encargados de generar contenido dinámico basado en plantillas.

Los Jsp’s son documentos basados en texto. Se componen de dos partes:

1. HTML o XML que forman el contenido estático

2. Etiquetas JSP y pequeños scripts escritos en Java para el contenido dinámico.

La principal ventaja sobre los servlets es que permiten separar la parte lógica de negocio que es 100% java (Servlet), de la parte lógica de presentación (HTML).

2. Contenedores Web

2.3. Estructura de una aplicación Web

Una Aplicación Web se crea con los siguientes componentes:

1. Un directorio Público.

1. Contiene los recursos públicos tal como HTML, imágenes, páginas Jsp o documentos que maneja la aplicación.

2. Un directorio /WEB-INF. Directorio privado al que no puede acceder el usuario.

1. El fichero web.xml.

2. Un directorio classes que contiene las clases compiladas.

3. Un directorio lib con todas las librerías de la aplicación.

2. Contenedores Web

2.4. Deployment Descriptor (I)

Es el fichero que define la configuración del despliegue de una aplicación web.

En los contenedores web es un fichero llamado web.xml, que se almacena en el directorio

/WEB-INF de la aplicación.

El descriptor de despliegue se utiliza para:

• Inicialización de parámetros, tanto de servlets como de la aplicación.

• Definición de Servlets y Jsps.

• Mapeo de Servlets y Jsps.

• Tipos MIME.

• Seguridad.

2. Contenedores Web

2.4. Deployment Descriptor (II)El fichero web.xml contiene la configuración de la aplicación.A continuación describiremos los elementos más importantes según la versión 2.4 de la especificación:

ELEMENTO DESCRIPCIÓN

<web-app> Elemento raíz de la aplicación.

<display-name> Define un nombre que identifica la aplicación. Es opcional.

<description> Incluye una descripción de la aplicación. Es opcional.

<context-param> Define, opcionalmente, parámetros de inicialización del contexto. Se puede repetir.

<filter> Define un filtro. Tantos <filter> como filtros hayamos definido.

<filter-mapping> Indica cada filtro sobre qué recursos se aplica.

<servlet> Define un servlet.

<servlet-mapping> Indica qué URL’s se utilizarán para invocar a un servlet determinado.

<session-config> Define parámetros de la sesión.

<mime-mapping> Indica en una aplicación tipos MIME distintos a los que el contenedor tiene configurados.

<welcome-file-list> Establece la lista de ficheros que se utilizarán como páginas de bienvenida.

<error-page> Define manejo de errores a nivel del contenedor.

<jsp-config> Define librerías de tag.

2. Contenedores Web

2.4. Deployment Descriptor (III)

<?xml version="1.0" encoding="UTF-8"?><web-app id="WebApp_ID" version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">

<display-name>Practicas</display-name><servlet>

<description>Prueba de Servlet</description><display-name>PruebaServlet</display-name><servlet-name>PruebaServlet</servlet-name><servlet-class>practicas.PruebaServlet</servlet-class>

</servlet><servlet>

<display-name>CicloDeVidaServlet</display-name><servlet-name>CicloDeVidaServlet</servlet-name><servlet-class>practicas.CicloDeVidaServlet</servlet-class><init-param>

<description>Mensaje inicial</description><param-name>mensaje-init</param-name><param-value>El servlet está inicializado</param-value>

</init-param><servlet-mapping>

<servlet-name>PruebaServlet</servlet-name><url-pattern>/PruebaServlet</url-pattern>

</servlet-mapping><servlet-mapping>

<servlet-name>CicloDeVidaServlet</servlet-name><url-pattern>/CicloDeVidaServlet</url-pattern>

</servlet-mapping><context-param>

<param-name>mensaje-show-time</param-name><param-value>El servlet procesa la petición</param-value>

</context-param><welcome-file-list>

<welcome-file>index.html</welcome-file><welcome-file>index.jsp</welcome-file>

</welcome-file-list></web-app>

2. Contenedores Web

2.5. Tipos de contenedores web

Existen tres maneras de configurar un Contenedor Web:

1. Contenedor Web en un servidor de Aplicaciones Web.

2. Contenedor Web desarrollado en el Servidor Web.

3. Contenedor Web en un entorno de ejecución separado.


3.1. Herramientas que vamos a utilizar

3.3. Instalación de Tomcat


3.2. Instalación del SDK de Java (JDK)

3.4. Instalación de OracleEX

3.5. Instalación de Eclipse

3.6. Primera aplicación web


3.1. Herramientas que vamos a utilizar

Durante el curso utilizaremos las herramientas que indicamos a continuación:

Como máquina virtual y compilador Java utilizaremos:

· Java 2 SDK Standard Edition v1.5.0 revisión 06 (JDK)

Como entorno de desarrollo integrado utilizaremos Eclipse con algunos plug-ins:

· Eclipse IDE v3.2

Como servidor de aplicaciones Web utilizaremos:

· Apache Tomcat v5.5 (con el módulo de compatibilidad con JDK 1.5.x)

Y finalmente, como motor de base de datos:

· OracleEX


3.2. Instalación del SDK de Java (JDK)

Para instalar el SDK de Java simplemente debemos ejecutar el fichero jdk-1_5_0_06-windows-i586-p y seguir las instrucciones en pantalla.

Debemos tomar nota del directorio en que instalamos el SDK pues deberemos crear una variable de entorno de nombre JAVA_HOME cuyo valor sea el directorio donde está instalado el SDK. Por ejemplo, podemos instalar el JDK en la ruta c:\java\jdk-1.5.0 o en la ruta por defecto.


3.3. Instalación de Tomcat

Para instalar Tomcat debemos descomprimir el fichero apache-tomcat-5.5.25 en un directorio de nuestra elección. Podemos utilizar, por ejemplo, el directorio c:\tomcat5.5 de forma que la instalación se realice en el directorio c:\tomcat5.5\jakarta-tomcat-5.5.25.

Una vez descomprimido el fichero deberemos crear una variable de entorno de nombre CATALINA_HOME cuyo valor sea el directorio donde está instalado Tomcat. Esta versión lo crea por defecto.

Modificamos el puerto por el que va a escuchar el servidor, ya que la administración de BBDD que vamos a instalar escucha en el mismo puerto.

Para ello modificamos el fichero server.xml que está en el directorio C:\tomcat5.5\apache-tomcat-5.5.25\conf . Modificamos las siguientes líneas:

<Connector port="8080" maxHttpHeaderSize="8192"por

<Connector port="8085" maxHttpHeaderSize="8192"


3.4. Instalación de OracleEX

Como motor de base de datos vamos a utilizar OracleEX.

Hacemos doble clic sobre el programa y le indicamos la ruta donde queremos instalarlo.

Nos pide introducir una contraseña. Esta password es la que se va a utilizar con el usuario System.

A continuación pulsamos Aceptar y comienza la instalación de la BBDD.

La página de la administración de la BBDD es: http://127.0.0.1:8080/apex


3.5. Instalación de Eclipse (I)

Para instalar Eclipse debemos descomprimir el fichero wtp-all-in-one-sdk-R-1.5.5-200708291442-win32 a un directorio de nuestra elección. Por ejemplo, podemos utilizar el directorio c:\eclipse de forma que la instalación se realice en el directorio c:\eclipse.

Este fichero lleva todos los plug-ins estándar de Eclipse necesarios para permitirnos gestionar tanto el servidor web que hemos instalado como la BBDD.

Si lo deseamos, podemos crear un acceso directo en el escritorio al fichero eclipse.exe que se encuentra donde hemos descomprimido Eclipse.

El paso siguiente es configurar el servidor web y la BBDD dentro de Eclipse.


3.5. Instalación de Eclipse (II)Asignar el servidor web a Eclipse:


3.5. Instalación de Eclipse (III)Asignar de la BBDD a Eclipse:

4.2. El Ciclo de vida de un Servlet

4.4. Contexto de un Servlet


4.3. Configuración de un servlet


4.5. Otras clases de interés

4.1. El API Java Servlets

4.6. La clase HttpServlet

4.7.Concurrencia

4.8. Interacción entre HTML y Servlets

4.9. Colaboración entre servlets


4.1. El API Java Servlets (I)

El API Java Servlets es el conjunto de clases e interfaces que nos permite interactuar con peticiones HTTP y generar las respuestas.

Con el API podremos crear clases que actuarán como servlets, acceder a la información de la petición y controlar la respuesta que estamos generando.

Si queremos consultar o descargar las especificaciones, o los API’s, podemos hacerlo en la web:

http://java.sun.com/products/servlets

http://java.sun.com/products/jsp

La API Java Servlets se especifica en dos paquetes que son:

javax.servlet

javax.serlvet.http


4.1. El API Java Servlets (II)

Tabla de clases e interfaces principales del API Java Servlet:

PROPOSITO CLASE/INTERFACE

Implementación de servlet javax.servlet.Servletjavax.servlet.SingleThreadModeljavax.servlet.GenericServletjavax.servlet.http.HttpSerlvet

Configuración del servlet javax.servlet.ServletConfig

Servlet Exceptions javax.servlet.ServletExceptionjavax.servlet.UnavailableException

Peticiones y Respuestas javax.servlet.ServletRequestjavax.servlet.ServletResponsejavax.servlet.ServletInputStreamjavax.servlet.ServletOutputStreamjavax.servlet.http.HttpSerlvetRequestjavax.servlet.http.HttpServletResponse

Gestión de la sesión javax.servlet.http.HttpSessionjavax.servlet.http.HttpSessionBindingListenerjavax.servlet.http.HttpSessionBindingEvent

Contexto del Servlet javax.servlet.ServletContext

Colaboración entre Servlets javax.servlet.RequestDispatcher


4.1. El API Java Servlets (III)

La tabla anterior divide las clases e interfaces principales del API Java Servlet en las siguientes categorías:

• API para la implementación de servlets.

Lo más común es que un servlet extienda de las clases javax.servlet.GenericServlet o javax.servlet.http.HttpSerlvet

• Configuración de servlets.

Permitir acceder al objeto ServletConfig

• Excepciones lanzadas por los servlets.

Las excepciones son javax.servlet.ServletException y javax.servlet.UnavailableException

• API para peticiones y respuestas.

Permiten leer los datos de entrada y generar una respuesta al cliente

• Contexto del servlet.

La interfaz javax.servlet.ServletContext permite compartir datos entre servlets.

• Colaboración entre servlets.

Permite a un servlet invocar a otro servlet.


4.1. El API Java Servlets (IV)

Cómo crear una clase Java para que se comporte como un servlet.

1. Crear una clase que extienda a la clase javax.servlet.http.HttpServlet.

2. Sobreescribir el método doGet(javax.servlet.http.HttpServletRequest, javax.servlet.http.HttpServletResponse).

El proceso general que seguiremos al diseñar un método doGet() es el siguiente:

• Primero leemos los datos de la petición.

• Escribimos las cabeceras de la respuesta.

• Obtenemos el objeto donde escribimos la respuesta y escribimos los datos de la respuesta.

Es recomendable siempre informar la cabecera con el tipo MIME del contenido; de esta forma el navegador puede escoger la mejor manera de presentar el documento de respuesta.


4.2. El ciclo de vida de un servlet (I)

El ciclo de vida de un servlet lo controla el servlet container y tiene tres fases principales:

1. El contenedor carga e inicializa el servlet

2. El contenedor maneja cero o más peticiones de cliente.

3. El contenedor elimina el servlet.


4.2. El ciclo de vida de un servlet (II)

El ciclo de vida de un servlet se compone de los siguientes estados:

• Instanciación.

• Inicialización.

• Servicio.

• Destrucción.

• Inexistente.


4.2. El ciclo de vida de un servlet (III)

Los métodos principales de la interface javax.servlet.Servlet son:

1. El método init():

Es el primer método que se llama para instanciar un servlet.

Solo se le llama una vez.

Su único argumento es una referencia a un objeto de la interface ServletConfig

2. El método service():

Método abstracto que debe ser definido por el programador.

Se invoca con cada petición que realiza el cliente.

Recibe dos parámetros, un objeto de la interface ServletRequest y un objeto de la interface ServletResponse

1. El método destroy():

Elimina la instancia de un servlet que ya no se va a ejecutar.


4.3. Configuración de un servlet (I)La interface javax.servlet.ServletConfig declara los cuatro métodos que nos permiten acceder a la configuración del servlet:

• getInitParameterNames():

Este método devuelve una enumeración con los nombres de todos los parámetros definidos para el servlet en el fichero web.xml.

• getInitParameter(String):

Este método devuelve el valor dado a un parámetro en el fichero web.xml.

• getServletName():

Este método devuelve una cadena con el nombre del servlet.

• getServletContext():

Este método devuelve un objeto de tipo javax.servlet.ServletContext con la información del contexto.

String valorParametro;

public void init(ServletConfig config) {

valorParametro = config.getInitParameter(nombreParametro);

}


4.3. Configuración de un servlet (II)Los parámetros de inicialización y el nombre del servlet pueden especificarse en el fichero descriptor de despliegue (web.xml), como muestra el siguiente ejemplo:

<web-app> <welcome-file-list> <welcome-file>techsupp.html</welcome-file> </welcome-file-list> <servlet> <servlet-name>techSupport</servlet-name> <servlet-class>TechSupportServlet</servlet-class> <init-param> <param-name>driver</param-name> <param-value>oracle.jdbc.driver.OracleDriver</param-value> </init-param> <init-param> <param-name>protocol</param-name> <param-value>jdbc:oracle:thin:@BLCZZ1002:1521:INNOVA</param-value> </init-param> </servlet></web-app>


4.4. Contexto de un servlet

El contexto es un área común compartida por todos los servlets de una misma aplicación Web.

Debe implementar el interfaz javax.servlet.ServletContext.

Algunos de sus métodos son:

METODO DESCRIPCIÓN

getInitParameterNames() Devuelve una enumeración con los nombres de todos los parámetros de inicialización del contexto definidos en el fichero web.xml mediante el elemento <context-param>.

getInitParameter(String) Devuelve el valor dado a un parámetro de inicialización del contexto en el fichero web.xml.

getAttributeNames() Devuelve una enumeración con los nombres de todos los atributos definidos en el contexto

getAttribute(String) Devuelve un objeto que está vinculado como valor al atributo dado como parámetro

setAttribute(String, Object) Almacena un objeto como atributo del contexto

removeAttribute(String) Elimina el atributo de la memoria del servidor.

getContext(String) Devuelve el contexto asociado a la ruta que pasamos como parámetro.

getResource(String) Devuelve un objeto de tipo java.net.URL apuntando al recurso cuya ruta pasamos como parámetro.

getResourceAsStream(String) Devuelve un objeto de tipo java.io.InputStream.

getRequestDispatcher(String) Devuelve el objeto de tipo javax.servlet.RequestDispatcher asociado a la ruta indicada.

getNamedDispatcher(String) Como el anterior, pero el parámetro es el nombre del servlet

getServletContextName() Este método devuelve el nombre del contexto tal y como se define en el fichero web.xml en el elemento <display-name>.


4.5. Otras clases de interés

Otras clases principales son:

• La interface javax.servlet.SingleThreadModel:

Permite hacer más sencillo el desarrollo de servlets.

Implementado en un servlet hace que el servidor procese todas las peticiones de servicio dentro de un mismo thread.

Facilita el desarrollo de servlets pero obstaculiza el rendimiento.

• Las clases de excepciones de servlets son:

javax.servlet.ServletException:

Se utiliza cuando ocurre un fallo general en el servlet.

javax.servlet.UnavailableException:

Indica que el servlet no se encuentra disponible.


4.6. La clase HttpServlet (I)

Extiende de la clase GenericServlet y provee una implementación de la interface Servlet específica del protocolo HTTP.Es una clase abstracta y hay que redefinir sus métodos, al menos los métodos doGet o doPost.

No define el método service() como abstract, sino como protected, al igual que los métodos init(), destroy(), doGet(), doPost(), etc., de forma que ya no es necesario escribir una implementación de service() en un servlet que herede de dicha clase.

Es una clase capaz de decir al cliente cual de sus métodos está redefinido y se puede utilizar.

Por ejemplo:Si en un servlet sólo se ha redefinido el método doPost(), si el cliente realiza una

petición de tipo HTTP GET el servidor lanzará automáticamente un mensaje de error similar al siguiente:

501 Method GET Not Supported

Todos los métodos de clase HttpServlet que debe o puede redefinir el programador (doGet(), doPost(), doPut(), doOptions(), etc.) reciben como argumentos un objeto HttpServletRequest y otro HttpServletResponse.


4.6. La clase HttpServlet (II)

Recapitulado, las diferencias entre Get y Post son:

• El método doGet() debería:

1. Leer los datos de la solicitud, tales como los nombres de los parámetros y sus valores.

2. Establecer el header de la respuesta (longitud, tipo y codificación).3. Escribir la respuesta en formato HTML para enviarla al cliente.

• El método doPost() debería:

1. Obtener input stream del cliente y leer los parámetros de la solicitud.2. Realizar aquello para lo que está diseñado (actualización de bases de datos,

etc.).3. Informar al cliente de la finalización de dicha tarea o de posibles imprevistos.

Para ello hay que establecer primero el tipo de la respuesta, obtener luego un PrintWriter y enviar a través suyo el mensaje HTML.


4.7. Concurrencia(I)

Dentro del contenedor Web, cada petición HTTP es procesada por una hebra diferente dentro de la VM del contenedor.

Por defecto, el contenedor sólo construye una instancia de cada servlet, por lo que en cualquier momento pueden existir múltiples hebras accediendo a la misma instancia de clase.

Si un servlet realiza operaciones sobre recursos compartidos, pueden aparecer problemas de concurrencia ya que distintos hilos pueden estar modificando a la vez las mismas variables.

En relación a las variables, en función de su ámbito, podremos concretar los problemas que pueden presentarse y cómo resolverlos.

Los ámbitos principales son:

• Variables locales.

Se definen en el ámbito del método service() o doGet(), y pueden utilizarse de forma segura ya que cada hilo tendrá definida sus propias variables dentro del ámbito de ejecución.

• Variables no estáticas de la instancia.

Son las compartidas por todos los hilos de ejecución, son variables que almacenan parámetros de inicialización. Para usarlas como variables de lectura/escritura se deben usar en bloques synchronized para evitar el acceso simultáneo al bloque de código.


4.7. Concurrencia (II)• Variables estáticas de la instancia.

Se comparten por todas las instancias de una misma clase, por lo que deben tenerse en cuenta las mismas consideraciones que para las variables no estáticas excepto cuando además de ser estáticas son finales. En este caso, al ser valores de solo lectura, sí pueden utilizarse de forma segura.

• Atributos de la petición.

Son atributos que están encapsulados en el objeto de tipo ServletRequest,por lo que son propios de cada petición y pueden utilizarse de forma segura entre diferentes hilos.

• Atributos de la sesión.

Son compartidos por diferentes peticiones realizadas por el mismo cliente a la aplicación, por lo que son compartidos entre los diferentes hilos que simultáneamente pueden estar accediendo a un servlet.

• Atributos del contexto.

Son compartidos por todos los servlets de la misma aplicación, por lo que aplican las mismas consideraciones que para los atributos de sesión. Es decir, no podemos utilizar con seguridad los atributos del contexto entre múltiples hilos.


4.8. Interacción entre HTML y servlets

Los campos de entrada de datos en un formulario HTML pueden ser de los siguientes tipos:

TIPO DE CAMPO TAG DESCRIPCIÓN

Campo de texto <INPUT TYPE="text" …> Campo de texto libre; se puede añadir una línea únicamente.

Botón submit <INPUT TYPE="submit" …> Al pulsar este botón se envía el formulario al recurso definido como ACTION.

Botón reset <INPUT TYPE="reset" …> Al pulsar este botón se limpian todos los campos del formulario.

Check-box <INPUT TYPE="checkbox" …> Campo de selección booleano.

Radio-button <INPUT TYPE="radio" …> Campo de selección excluyente.

Campo contraseña

<INPUT TYPE="password" …> Campo de texto utilizado para introducir contraseñas; la información que se escribe en este campo no es visible al usuario.

Campo oculto <INPUT TYPE="hidden" …> Es un campo que no se muestra en el formulario pero cuyo valor es enviado al servidor.

Lista desplegable <SELECT …><OPTION …></SELECT>

Permite elegir una o más opciones de las que se muestran en una lista.

Área de texto <TEXTAREA …>…</TEXTAREA>

Campo de texto libre; se puede añadir texto en varias líneas.


4.9. Colaboración entre servlets (I)

Existen casos en los que un servlet envía la respuesta a una página jsp que se crea dinámicamente, o a otro servlet que es encargado de darnos la respuesta.

Hay dos soluciones para realizar esto:

• Encadenar servlets (Servlet chaining):

Se diseñan varios servlets, cada uno con una tarea.

Se configura el contenedor para especificar la cadena de servlets a invocar para un alias de una determinada URL.

Su uso no es recomendado ya que nunca se ha incluido en las especificaciones del API servlet.

• Envío de la respuesta (Request Dispatching):

Para enviar la petición a un segundo servlet, sólo hace falta tener la referencia del servlet que invocamos.

Para esto el API de Java para Servlet ha desarrollado una interface especial llamada javax.serlvet.RequestDispatcher.


4.9. Colaboración entre servlets (II)

La interface javax.serlvet.RequestDispatcher permite enviar peticiones a otros servlets o Jsp’s.

Los dos métodos del interfaz son:

• forward():

Permite remitir la petición a otro servlet o página JSP, o un fichero HTML del servidor.

• include():

Incluye el contenido producido por otro recurso en la respuesta del servlet que invoca al recurso.

Se puede obener un objeto RequestDispatcher para un recurso con los siguientes métodos:

• getRequestDispatcher() de la interface javax.servlet.ServletContext que requiere un path absoluto.

• getNamedDispatcher() de la interface javax.servlet.ServletContext que acepta el nombre asociado con el servlet, el cual se especifica en el fichero descriptor de despligue en el elemento <servlet-name>.

• getRequestDispatcher() de la interface javax.servlet.ServletRequest que acepta tanto el path absoluto como el path relativo.

5.2. Cookies

5.4. Reescritura de URLs

5. Sesiones

5.3. Sesiones (Session tracking)


5.1. Introducción

5. Sesiones

5.1. Introducción

El protocolo HTTP no está acoplado, esto es, no mantiene conectadas peticiones continuadas sobre un mismo recurso o aplicación. Dos peticiones HTTP son mutuamente independientes.

Para suplir esta carencia, el contenedor Web debe proveer mecanismos que permitan almacenar información importante concerniente a distintas peticiones de un mismo usuario. Esta información es lo que denominaremos una sesión.

Un ejemplo de aplicación con sesión es la típica tienda on-line, donde el componente principal es el carrito de la compra. La aplicación provee interfaces para consultar un catálogo, añadir productos al carrito de la compra, y generar una orden de compra a partir del contenido del carrito.

Para implementar este tipo de aplicaciones necesitamos cumplir dos requerimientos básicos:

1. Conservar la sesión. El servidor ha de ser capaz de identificar la peticiones de un cliente y asociarlas a su sesión de trabajo.

1. Conservar el estado. El servidor tiene que recordar toda la información relativa a peticiones anteriores o decisiones de negocio tomadas a partir de esas peticiones

5. Sesiones

5.2. Cookies (I)

Existe una extensión al protocolo HTTP que permite a un servidor Web almacenar información en la máquina cliente. A cada pieza de información que se guarda en cliente se llama cookie.

Se utiliza para que un servidor HTTP reconozca a un cliente como alguien que ya se había conectado anteriormente.

Las cookies se identifican por un dominio y una ruta y se intercambian en cada petición y respuesta HTTP en la sección de cabeceras.

Varias cookies pueden compartir el mismo nombre y se almacenan en un directorio o fichero predeterminado en el disco duro del cliente.

Tienen un determinado tiempo de vida y es responsabilidad del navegador limpiar las cookies que han expirado.

Se envían añadiendo campos adicionales al header de un mensaje HTTP., de la forma clave/valor.

Las cookies en Java son objetos de la clase javax.servlet.http.Cookie.

Toda la información almacenada en cookies lo es en forma de String, por lo que será preciso convertir cualquier valor a String antes de añadirlo a una cookie.

5. Sesiones

5.2. Cookies (II)

Es necesario crear la cookie antes de acceder al Writer del objeto HttpServletResponse, ya que las cookies son enviadas al cliente en el header del mensaje.

Los siguientes métodos permiten establecer los valores de una cookie y sus atributos:

String IdObjetoAComprar = new String("301");

if(IdObjetoAComprar!=null)

Cookie miCookie=new Cookie("Compra", IdObjetoAComprar);

MÉTODO DESCRIPCIÓN

setComment(String) Asigna un comentario a la Cookie

setDomain(String) Establece el patrón de dominio a quien permitir el acceso a la información contenida en la cookie.

setMaxAge(int) Establece el tiempo de caducidad de la cookie en segundos.

setPath(String) Establece la ruta de acceso del directorio de los servlets que tienen acceso a la cookie.

setSecure(boolean) Indica al browser que la cookie sólo debe ser enviada utilizando un protocolo seguro (https).

setValue(String) Establece el valor de la cookie

setVersion(int) Establece la versión del protocolo de la cookie.

5. Sesiones

5.2. Cookies (III)

Enviar una cookie: Recoger las cookies:

Obtener el valor de una cookie:

...public void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {...

Cookie miCookie=new Cookie("Nombre","Valor");miCookie.setMaxAge(-1);miCookie.setComment("Esto es un comentario");resp.addCookie(miCookie);PrintWriter out=resp.getWriter();

...

}

Cookie miCookie = null;Cookie miCookie2= null;Cookie miCookie3= null;

Cookie[] arrayCookies = req.getCookies();

miCookie = arrayCookies[0];miCookie2 = arrayCookies[1];miCookie3 = arrayCookies[2];

...String libroABorrar = req.getParameter("Borrar");...

if (libroABorrar != null) {Cookie[] arrayCookies = req.getCookies();for (i=0; i<arrayCookies.length; i++) {Cookie miCookie = arrayCookies[i];

if (miCookie.getName().equals("compra") &&miCookie.getValue.equals("libro1") { miCookie.setMaxAge(0); // Elimina la cookie

} // fin del if} // fin del for

} // fin del if...

5. Sesiones

5.3. Sesiones. (Session tracking) (I)

Una sesión es una conexión continuada de un mismo browser a un servidor durante un período prefijado de tiempo que depende habitualmente del servidor.

Las sesiones son compartidas por todos los servlets de un mismo servidor.

Las sesiones son creadas automáticamente por el contenedor cuando el cliente se conecta por primera vez y se pueden destruir de dos formas diferentes:

• El usuario no realiza una petición pasado el tiempo de inactividad

• La sesión se invalida a través del código.

La manera de acceder a los objetos de sesión es a través del interfaz javax.servlet.http.HttpSession.

Podemos acceder a la sesión utilizando los métodos:public HttpSession getSession(boolean crear);public HttpSession getSession();

5. Sesiones

5.3. Sesiones. (Session tracking) (II)Algunos métodos de este interfaz y con los que podemos interactuar con la sesión son los siguientes:

METODO DESCRIPCIÓN

getId(): Devuelve una cadena con el identificador de la sesión.

isNew(): Indica si la sesión es o no de nueva creación.

invalidate() Invalida una sesión

getAttributeNames() Devuelve una enumeración con los nombres de todos los atributos que están definidos para la sesión actual.

getAttribute(String) Devuelve un objeto con el valor asociado al atributo indicado.

setAttribute(String, Object): Añade un atributo a la sesión. Si un atributo con el mismo nombre existiera, su valor se perdería.

removeAttribute(String) Elimina de la sesión el atributo cuyo nombre indicamos.

getCreationTime(), getLastAccessedTime(), getMaxInactiveInterval()setMaxInactiveInterval()

Permiten obtener más información de la sesión y modificar el tiempo máximo de inactividad de la misma.

5. Sesiones

5.4. Reescritura de URLs (I)

Se utiliza para poder emplear sesiones con clientes, que o bien no soportan cookies o bien las rechazan.Para emplear está técnica se incluye el código identificativo de la sesión (sessionId) en el URL de la petición.Los métodos que se encargan de reescribir el URL son de la interface HttpServletResponse:

encodeURL(): lee un String que representa un URL y si fuera necesario la reescribe añadiendo el identificativo de la sesión

encodeRedirectURL(): realiza lo mismo que el anterior, sólo que con URLs de redirección, es decir, permite reenviar la petición del cliente a otra URL .

...HttpSession miSesion=req.getSesion(true);CarritoCompras compra =

(CarritoCompras)miSesion.getAttribute(miSesion.getId());if (compra == null) {compra = new CarritoCompras();miSesion.setAttibute(miSesion.getId(), compra);}

...PrintWriter out = resp.getWriter();resp.setContentType("text/html");...out.println("Esto es un enlace reescrito");out.println("<a href\""+resp.encodeUrl("/servlet/buscador?nombre=Pedro")+"\"</a>");...

6. Modelo Vista Controlador


6.1. El patrón de diseño MVC

1. Introducción

1.4. El patrón de diseño MVC

1. Introducción

1.4. El patrón de diseño MVC (II)

El patrón MVC señala tres capas básicas en la aplicación:

• La capa de presentación o Vista. Típicamente serán las páginas de entrada de datos y páginas de respuesta o los documentos que se generan como resultado de la interacción con el usuario.

• La capa de control o Controlador. Típicamente son los componentes que se encargan de recibir peticiones, ver a qué caso de uso corresponden, ver si el usuario está autorizado para hacer esa acción y redirigen a la lógica de negocio adecuada.

• La capa de lógica de negocio o Modelo. Son los componentes que contienen la lógica de negocio propiamente dicha: realizarán cálculos, procesarán información contenida en una BD o se integrarán con otras aplicaciones. Esta capa habitualmente se divide a su vez en 3 capas:

· Lógica de negocio de alto nivel.

· Lógica de acceso a datos.

· Información encapsulada en objetos Java.

Utilizando patrones de diseño en varias capas conseguimos, por ejemplo, que un cliente Java por Web, un cliente Java Swing o un cliente .Net sean capaces de acceder a la misma lógica de negocio. Es decir, reaprovechamos el Controlador y el Modelo y creamos tantas Vistas como sea necesario.

1. Introducción

1.4. El patrón de diseño MVC (III)Clase Modelo:

1. Contiene la funcionalidad de la aplicación.

2. Lleva un registro de las vistas y controladores del sistema.

3. Notifica los cambios en los datos a los componentes.

Clase controlador:

1. Acepta los eventos de entrada.

2. Traduce los eventos de entrada a peticiones al modelo o a las vistas.

3. Implementa el procedimiento actualizar si es necesario.

Clase vista:

1. Crea e inicializa su controlador asociado.

2. Muestra información al usuario.

3. Actualiza la información.

4. Recoge datos del modelo.

II.3. Creación de VO’s, DAO’s y BO’s

Práctica del curso

II.4. Probando la capa de acceso a datos


II.1. La aplicación Agenda

II.5. Creación de la capa Web (controlador+vista)

II.6. Soluciones

II.2. Modelo de datos de la aplicación

Practica del curso

1. La aplicación Agenda

En este laboratorio vamos a crear una aplicación completa, llamada Agenda, que nos permitirá mantener una pequeña base de datos de direcciones y teléfonos.

Esta aplicación tendrá dos capas separadas: la de acceso a datos, y la capa Web, que incluirá el controlador y la vista. Nuestro objetivo principal es que la capa de acceso a datos esté totalmente aislada y se reutilice al 100% sin cambios en un modelo de tres capas (ver el Laboratorio II).

Como objetivos secundarios nos marcamos que la aplicación tenga un control de acceso y tratamiento de errores.

Como guión general, seguiremos los siguientes pasos para la creación de la aplicación:

· Creación de los objetos de acceso a datos: VO’s, DAO’s y BO’s, tratando de crear componentes comunes que faciliten la implementación de múltiples clases similares.

· Creación de servlets de prueba que nos permitan probar los objetos de acceso a datos.

· Creación de la capa Web, primero creando páginas HTML siempre que una interfaz estática pueda ser utilizada y posteriormente creando servlets que procesen las peticiones y generen las vistas dinámicas.

Laboratorio II

II.2. Modelo de datos de la aplicación

El modelo de datos de la aplicación consiste en dos tablas: USUARIOS, donde guardamos los usuarios autorizados a entrar en la aplicación y sus contraseñas, y AGENDA, donde guardamos las direcciones y teléfonos administrados por la aplicación.

Las tablas las creamos en la base de datos :

CREATE TABLE USUARIOS (USERNAME VARCHAR(10),PASSWORD VARCHAR(10)

);

CREATE TABLE AGENDA (NAME VARCHAR(50),ADDRESS VARCHAR(150),TELEPHONE VARCHAR(15),LASTUPDATED TIMESTAMP

);

ALTER TABLE AGENDAADD CONSTRAINT PK_AGENDAPRIMARY KEY (NAME);

Laboratorio II

II.3. Creación de VO’s, DAO’s y BO’s

Los Value Objects o VO’s, son JavaBeans que se construyen como imagen de un registro en base de datos, por lo que su definición se corresponde con la definición de la tabla a la que dan respaldo, con las equivalencias lógicas entre tipos de datos.

Los Data Access Objects o DAO’s, son objetos donde realizamos el acceso a los datos. Cada DAO recibirá al instanciarse una conexión que utilizará para el acceso. Esta conexión estará inicializada correctamente y estará incluida en una transacción si funcionalmente es necesario. Los métodos de un DAO arrojan excepciones de tipo java.sql.SQLException, y no tratan esas excepciones, ni cierran conexiones, pero sí deben cerrar los objetos que ellos creen.

Los Business Objects o BO’s, son objetos que encapsulan la lógica de negocio de alto nivel o lógica del proceso. Se apoyan en DAO’s para realizar los accesos a los datos necesarios, las operaciones necesarias a realizar sobre los datos para devolver los resultados y se encargan además de gestionar transacciones y accesos distribuidos

Los BO’s recibirán al instanciarse la información de contexto necesaria para su correcta inicialización. En nuestro caso, utilizaremos el contexto de la aplicación para inicializar la conexión a la base de datos. Mediante un listener de la aplicación, crearemos la conexión y la guardaremos en el contexto para que sea accesible a los BO’s.

Laboratorio II

II.4. Probando la capa de acceso a datos

Una vez que hemos terminado de desarrollar la capa de acceso a datos, vamos a desarrollar un par de componentes de prueba que nos permitan probarlos.

Con estos componentes podremos asegurarnos que la capa de acceso a datos funciona correctamente sin tener que completar la capa Web para capturar los datos y ejecutar la lógica de negocio.

Cada componente de prueba será un servlet que recibirá desde la petición los parámetros necesarios para ejecutar la lógica de negocio. A continuación, instanciará el BO de la entidad que queremos probar, instanciará un VO que inicializaremos con los datos leidos desde la petición, y por último ejecutará la lógica contenido en el BO pasando el VO como parámetro.

Los resultados los mostraremos de forma sencilla, por consola o salida del servlet. En este punto no vamos a crear la vista, sólo verificar que los datos son correctos.

También se capturarán las excepciones de la aplicación y se mostrará la información de la misma.

Laboratorio II

II.5. Creación de la capa Web (controlador+vista)

En la creación de la capa Web vamos a desarrollar dos tipos de componentes: páginas HTML con formularios de captura de datos, que son estáticos y podemos desarrollar de esta forma, y servlets que cumplirán una doble función: la de controlador, ejecutando la lógica de negocio contenida en los BO’s, y la de vista, generando las páginas de resultados, que al ser dinámicas no pueden generarse con páginas HTML.

Las páginas HTML de captura de datos serán tres:

· Una para el login;· Una para introducir criterios de búsqueda, y;· Una para dar de alta nuevos registros en la agenda.

Los servlets necesarios serán 5:

· Uno que valide los datos del login y en caso de que dichos datos correspondan a un usuario autorizado, redirigir a la página de criterios de búsqueda;

· Uno que valide los criterios, ejecute la consulta y cree la página de resultados de forma dinámica, junto con acceso a la ventana de alta y a la modificación y a la consulta;

· Uno que valide los datos de un alta y la ejecute y cree una página de confirmación del alta;

· Uno que genere dinámicamente la ventana de confirmación de la baja, ejecute la misma y luego muestre un mensaje que indique si la baja se realizó o no.

· Uno que genere dinámicamente la ventana de modificación, ejecute la misma y luego muestre un mensaje que indique si la modificación se realizó o no.

7.1. JSP

7.4 . La directiva JSP page


7.2. Elementos disponibles en una página JSP


7.6. Acciones

7.3. Sintaxis JSP’s

7.5 . La directiva JSP include


7.1. JSP

La tecnología JavaServer Pages, JSP, está basada en la tecnología de servlets.

Permite generar páginas de forma dinámica y separar la lógica de presentación de la lógica de negocio.

El contenido de un JSP se compone de código HTML, además de tags especiales JSP que permiten a la página interactuar con la información que tenemos en el servidor, además de darnos la posibilidad de incluir código Java.

Puesto que el código HTML es interpretado correctamente por el intérprete/compilador de un JSP, todo fichero HTML puede ser convertido en un JSP únicamente cambiando su extensión.

Cada página JSP es convertida, mediante compilación, en un servlet por el motor JSP. La creación y compilación automática del servlet ocurre la primera vez que se accede a la página JSP.


7.2. Sintaxis JSP’s

ELEMENTO SINTAXIS

Expresión JSP <%= expression %>;

Scriptlet JSP <% code %>;

Declaración JSP <%! code %>

Directiva page JSP <%@ page att="val" %>

Directiva include JSP <%@ include file="url" %>

Comentario JSP <%-- comment --%>

Acción jsp:include <jsp:include page="relative URL" flush="true"/>

Acción jsp:useBean <jsp:useBean att=val*/> <jsp:useBean att=val*> ... </jsp:useBean>

Acción jsp:setProperty <jsp:setProperty att=val*/>

Acción jsp:getProperty <jsp:getProperty name="propertyName" value="val"/>

Acción jsp:forward <jsp:forward page="relative URL"/>

Acción jsp:plugin <jsp:plugin attribute="value"*> ... </jsp:plugin>


7.3. Elementos disponibles en una página JSP’s (I)

En una página JSP hay cinco tipos de elementos disponibles:

• Elementos HTML (incluidos las cadenas de texto, la definición de estilos y el código JavaScript).

• Elementos de scripting (incluidos entre las cadenas “<%” y “%>”).

Los elementos de scripting nos permiten controlar ciertos aspectos de la generación de la página, además de incluir código Java directamente. Hay cinco tipos de elementos de scripting:

• Comentarios: delimitados por las cadenas “<%--” y “--%>”.

• Directivas: delimitadas por las cadenas “<%@” y “%>”.

• Declaraciones: delimitadas por las cadenas “<%!” y “%>”.

• Código Java (scriptlets): Los bloques de código Java están delimitados por las cadenas “<%” y “%>”.

• Expresiones: delimitadas por las cadenas “<%=“ y “%>”.


7.3. Elementos disponibles en una página JSP’s (II)

<%-- código en el JSP --%><% if (i > 100) {%><b>i</b> es un número grande.<% } else {%><b>i</b> es un número pequeño.<% }%>

// código en el servlet

if (i > 100) { pw.println(“<b>i</b> es un número grande.”);} else { pw.println(“<b>i</b> es un número pequeño.”);}


7.3. Elementos disponibles en una página JSP’s (III)

• Elementos JSP (también conocidos como acciones estándar JSP).

Estos elementos son tags definidos por el API JavaServer Pages y se traducen en código Java que nos permite interactuar con JavaBeans, realizar redirecciones del flujo de la página o permitir la inclusión de unos JSP’s dentro de otros. Estos elementos empiezan todos por la cadena “<jsp:”.

Ejemplo:

<%-- código en el JSP --%><jsp:forward page=“DetalleUsuarios.jsp”>

// código en el servletRequestDispatcher view = request.getRequestDispatcher(“DetalleUsuarios.jsp”);view.forward(request, response);return;

• Tags personalizados (incluida la librería de tags estándar JSP o JSTL).

Se traducen en código HTML según se define en clases Java construidas según el API JavaServer Pages. Estos tags se agrupan en librerías.


7.3. Elementos disponibles en una página JSP’s (IV)• Variables implícitas.

Son variables que dan acceso a los siguientes objetos :

• request: El HttpServletRequest.

• response: El HttpServletResponse.

• out: El objeto de tipo JspWriter asociado con el stream de salida de la respuesta.

• session: El HttpSession asociado con el request (si existe).

• application: El objeto de tipo ServletContext asociado al contexto de la aplicación donde está contenida la página JSP.

• config: El objeto de tipo ServletConfig asociado a la configuración del servlet que se genera al interpretar la página.

• pageContext: Este objeto encapsula el entorno de una petición para la página JSP.

• page: Esta variable es equivalente al uso de la variable this en código Java.

• exception: Excepción que se produce en el código.


7.4. La directiva JSP pagePermite importar clases, personalizar la superclase del servlet, etc. Su sintaxis y atributos son:

<%@ page (atributo=“valor”)* %> ATRIBUTO DESCRIPCIÓN

import="package.class" o import="package.class1,...,package.classN"

Permite especificar los packages que deberían ser importados. Es el único que puede aparecer múltiples veces.

contentType="MIME-Type" o contentType="MIME-Type; charset=Character-Set".

Especifica el tipo MIME de la salida. El valor por defecto es text/html.

isThreadSafe="true|false" Indica si el servlet generado implementará la interfaz SingleThreadModel. Su valor por defecto es “true” e indica que no lo implementa.

session="true|false" El valor de este atributo indica si la página participa o no en una sesión. Su valor por defecto es “true” e indica que implementa una sesión.

buffer="sizekb|none" Especifica el tamaño del buffer para el JspWriter out.

autoflush="true|false" Indica si la salida se vuelca cuando el buffer se llena o se arroja una excepción.

extends="package.class" Indica la superclase del servlet que se va a generar

info="message". Define una cadena informativa acerca de la página

errorPage="url". Especifica la página JSP que se debería procesar si se lanzará cualquier Excepción.

isErrorPage="true|false" Indica si la página actual actúa o no como página de error de otra página JSP.

language="java" Especifica el lenguaje a utilizar.

pageEncoding Define el tipo de codificación usado en el stream de salida. Por defecto su valor es “ISO-8859-1”.

7.5. La directiva JSP includePermite incluir ficheros en el momento en que la página JSP es traducida a un servlet. Su es:

<%@ include file="url relativa" %>

La URL especificada normalmente se interpreta como relativa a la página JSP a la que se refiere.

Los contenidos del fichero incluido son analizados como texto normal JSP, y así pueden incluir HTML estático, elementos de script, directivas y acciones.

Ejemplo:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"><HTML><HEAD><TITLE>Servlet Tutorial: JavaServer Pages (JSP) 1.0</TITLE><META NAME="author" CONTENT="[email protected]"><META NAME="keywords" CONTENT="..."><META NAME="description" CONTENT="..."><LINK REL=STYLESHEET HREF="Site-Styles.css" TYPE="text/css"></HEAD> <BODY><%@ include file="/navbar.html" %>  </BODY></HTML>


7.6. Acciones (I)Las acciones JSP usan construcciones de sintaxis XML para controlar el comportamiento del motor de Servlets.

Las acciones disponibles son:

ACCIÓN DESCRIPCIÓN

jsp:include Permite insertar ficheros en una página que está siendo generada. La sintaxis es la siguiente: <jsp:include page="relative URL" flush="true" />Inserta el fichero en el momento en que la página es solicitada.

jsp:useBean permite cargar y utilizar un JavaBean en la página JSP. La sintaxis más simple es: <jsp:useBean id="name" class="package.class" />Usamos esta instrucción para cargar el Bean, jsp:setProperty y jsp:getProperty para modificar y recuperar propiedades del bean.

ATRIBUTO USO

id Da un nombre a la variable que referenciará el bean.

Class Designa el nombre completo del paquete que contiene el bean.

scope Indica el contexto en el que el bean debería estar disponible. Hay cuatro posibles valores: page, request, session, y application.

type Especifica el tipo de la variable a la que se referirá el objeto.

beanName Da el nombre del bean.


7.6. Acciones (II)

ACCION DESCRIPCION

jsp:setProperty Asignar valores a las propiedades de los beans que se han referenciado anteriormente.

jsp:getProperty Recupera el valor de una propiedad del bean, lo convierte a un string, e inserta el valor en la salida. Los dos atributos requeridos son name, el nombre de un bean referenciado anteriormente y property, la propiedad cuyo

valor debería ser recuperado. jsp:forward Permite reenviar la petición a otra página. Tiene un sólo atributo, page, que debería consistir en una URL relativa.

jsp:plugin Permite insertar un elemento OBJECT o EMBED específico del navegador para indicar que el navegador debería ejecutar un applet usando el Plug-in Java.

ATRIBUTO USO

name Designa el bean cuya propiedad va a ser seleccionada.

property Indica la propiedad que queremos seleccionar. Un valor de "*" significa que todos los parámetros de la petición cuyos nombres correspondan con nombres de propiedades del Bean serán pasados a los métodos de selección apropiados.

value Atributo opcional que especifica el valor para la propiedad. Los valores string son convertidos automáticamente a números, boolean, Boolean, byte, Byte, char, y Character mediante el método estándar valueOf en la fuente o la clase envolvente.

param Parámetro opcional que designa el parámetro de la petición del que se debería derivar la propiedad.

8.2. Seguridad en una aplicación web


8.3. Filtros


8.1. Tratamiento de errores

8.4. Concurrencia de la BBDD

8.5. Creación de tags parsonalizados


8.1. Tratamiento de errores (I)

En una aplicación Web pueden producirse dos tipos de errores:

• Errores HTTP: Cada respuesta HTTP que el servidor envía de vuelta al cliente incluye un código de estado, indicando al navegador si la petición se procesó correctamente o si hubo un error.

• Excepciones en los servlets: Son excepciones Java que se producen durante el ciclo de vida de los servlets.

ERROR DESCRIPCION

400 Petición inválida (bad request)

401 No autorizado (unauthorized)

403 Acceso prohibido (forbidden)

404 Recurso no encontrado (not found)

405 Método no permitido (method not allowed)

415 Tipo no soportado (unsupported media type)

500 Error interno (internal server error)

501 No implementado (not implemented)

503 Servicio no disponible (service unavailable)


8.1. Tratamiento de errores (II)Una página de error puede ser tanto un fichero HTML estático como un servlet y debe proporcionar a los usuarios información bien formateada de un error producido durante el uso de una aplicación

Las páginas de error creadas pueden ser activadas de dos formas:

• Declarativamente, en el fichero web.xml.

• En código, capturando excepciones y redirigiendo el flujo según sea necesario.

Si la página de error la genera un servlet, se accede a la información con los atributos:

• javax.servlet.error.exception: El valor es el objeto Exception arrojado por el servlet.

• javax.servlet.error.request_uri: Este atributo contiene una cadena con la URL del recurso que originó el error tal y como el usuario lo solicitó.Ejemplo:

En el caso de que estemos capturando un error HTTP, la sintaxis será como sigue:

<error-page><error-code>404</error-code><location>/errores/error404.html</location>

</error-page>

En el caso de que estemos capturando una excepción Java, la sintaxis será así:

<error-page><exception-type>java.lang.ArithmeticException</exception-type><location>/errores/ErrorServlet</location>

</error-page>


8.1. Tratamiento de errores (III)

Habitualmente, cada vez que se produce un error en código suele quedar registrado en un log de actividad como el que todo contenedor Web nos ofrece.

A este log podemos acceder usando los métodos log() de la clase servlet o del contexto.

Existen dos métodos log():

• Primer tipo: Almacena el mensaje.

• Segundo tipo: Almacena la causa de error.

En la práctica, este log no es utilizado pues su control lo tiene el contenedor.

Es por esto que habitualmente los logs de actividad se realizan accediendo directamente a librerías de terceros, como es el caso de log4j.


8.2. Seguridad en una aplicación web (I)

La seguridad es un aspecto crítico en cualquier aplicación Web.

El objetivo de un desarrollador debe ser, por un lado, crear aplicaciones robustas, y por otro, mantener la seguridad en los equipos en la mejor forma posible.

Las formas de gestionar la seguridad de una aplicación más habituales son:

• Utilizando el protocolo SSL sobre HTTP, también conocido como HTTPS.

• Utilizando un certificado digital que es expedido por una entidad certificadora (CA.

• Realizar una auditoría de la aplicación manteniendo un log de accesos y operaciones.

Se denomina código malicioso a toda pieza de software diseñada para dañar un sistema. En aplicaciones Web, código malicioso es aquél código en el servidor diseñado con la intención de dañarlo o evitar su funcionamiento normal.

Se denomina ataque Web al acceso externo a un servidor con el fin de crear una situación de denegación del servicio, robar contraseñas o información confidencial.


8.2. Seguridad en una aplicación web (II)

Desde una aplicación web las formas de garantizar la seguridad son:

• Autenticación: Proceso por el cuál se valida la identidad de un usuario. Los métodos más comunes de validar la identidad de un usuario son los siguientes:

• Incluir una página de validación de usuario y contraseña.

• Utilizar un certificado digital por parte del cliente y usar sus claves pública y privada para mantener con el servidor un intercambio de información encriptado.

• Utilizar un sistema de tarjetas inteligentes y un lector para suministrar su identificación.

La autentificación es un proceso que podemos configurar en un contenedor Web.METODO DESCRIPCION

BASIC El navegador solicita al usuario su identificador y su contraseña y envía esa información de forma abierta al servidor el cual valida el par.

DIGEST El navegador solicita al usuario su identificador y su contraseña y envía esa información de forma encriptada al servidor el cual valida el par.

FORM La aplicación Web utiliza un formulario HTML que es enviado al navegador para recoger la información de identificación del usuario.

CLIENT-CERT El contenedor utiliza un certificado digital para verificar la identidad del usuario. La comunicación en este caso se realiza con SSL sobre HTTP.


8.2. Seguridad en una aplicación web (III)

• Autorización: Proceso por el cuál la funcionalidad de una aplicación es accesible o no en función de perfiles de usuario (roles).

El mapeo entre una lista de recursos en nuestra aplicación y un rol de usuario, denominado un dominio de seguridad, es configurable dentro del contenedor Web.

Seguridad declarativa es la posibilidad de incluir configuración de autentificación y de autorización en una aplicación Web sin tener que modificar el código de la misma.

Autentificación declarativa.

Para habilitar alguno de los mecanismos de autentificación declarativa, hacemos uso del elemento <login-config> del fichero web.xml. Este elemento incluirá un elemento <auth-method> cuyo contenido podrá ser uno de los cuatro métodos de autentificación que proporciona el servidor: BASIC, DIGEST, FORM o CLIENT-CERT.

<login-config><auth-method>FORM</auth-method><form-login-config> <form-login-page>/login/login.html</form-login-page> <form-error-page>/login/error.html</form-error-page></form-login-config>

</login-config>


8.2. Seguridad en una aplicación web (III)

Autorización declarativa.

Hay que identificar las colecciones de recursos de la aplicación, identificar los roles, relacionar los recursos con los roles e identificar a los usuarios. Una vez encontrada una relación, haremos uso del elemento <security-constraint> en el fichero web.xml:

<security-constraint> <web-resource-collection> <web-resource-name>Recursos restringidos</web-resource-name> <url-pattern>/Parametros.html</url-pattern> <url-pattern>/PrimerForm.html</url-pattern> <http-method>GET</http-method> <http-method>POST</http-method> </web-resource-collection> <auth-constraint> <role-name>CursoServletsRole</role-name> </auth-constraint></security-constraint>

También debemos indicar todos los roles que serán utilizados en la aplicación usando el elemento <security-role> en el fichero web.xml una vez por cada rol que utilicemos:

<security-role> <role-name>CursoServletsRole</role-name></security-role>


8.3. Filtros

Un filtro en la tecnología Java Servlets es una clase que, a partir de la versión 2.3 de la especificación, e implementando el interfaz javax.servlets.Filter, se sitúa delante de uno o varios recursos de nuestra aplicación Web, modificando la petición y/o la respuesta.

Los filtros son componentes que, se emplean para:

• Construir componentes de autentificación no basados en la seguridad declarativa.

• Construir componentes de log y auditoría.

• Construir componentes que realicen conversiones en el formato de imágenes.

• Construir componentes que compriman y descompriman la información que se transmite.

• Construir componentes de encriptación/desencriptación de información.

Un filtro contiene tres métodos: init(), destroy() y doFilter(). Los dos primeros se comportan de forma análoga a los de un servlet, y también se pueden definir parámetro de inicialización para los filtros.

Puesto que pueden existir distintos filtros superpuestos para un mismo recurso, la manera de seguir con la ejecución hacia abajo es mediante la invocación del método doFilter() del objeto de tipo javax.servlet.FilterChain que es el tercer parámetro del método doFilter(). En el caso de que no se cumpla el criterio de filtrado, podemos no pasar al siguiente eslabón de la cadena y redirigir a otro componente, por ejemplo una página de error o de login.


8.4. Concurrencia de la BBDD

Uno de los principales problemas relacionados con la concurrencia consiste en el acceso a recursos que, por su naturaleza, son compartidos

Utilizando transacciones, logramos que se atomicen operaciones complejas, que no se queden datos corruptos, pero en ningún caso evitamos que un registro borrado por un usuario deje de estar disponible para otros.

Las situaciones más comunes que deberemos controlar al trabajar de forma concurrente con BBDD son:

• Un registro consultado por un usuario, durante su visualización, ha sido modificado por otro usuario.

• Un registro consultado por un usuario, durante su visualización, ha sido eliminado por otro usuario.

Nuestro código deberá, por tanto, antes de actualizar o eliminar un registro, verificar:

• Que no haya sido modificado mientras tanto por otro usuario.

• Que no haya sido borrado mientras tanto por otro usuario.

La primera verificación la realizamos añadiendo a nuestras tablas los llamados campos de auditoría.

La segunda verificación la hacemos por PK.


8.5. Tags personalizados (I)

Un tag personalizado es un tag XML utilizado dentro de una página JSP y que representa alguna acción dinámica o de generación de contenido en tiempo de ejecución.

Los tags personalizados se utilizan para eliminar la necesidad de código Java dentro de la página, o para encapsular elementos HTML que se utilizan de forma recurrente.

Además de eliminar código Java de las páginas, son componentes totalmente reutilizables y que podemos compartir fácilmente en muchas páginas en incluso en diferentes aplicaciones.

Todo tag personalizado debe cumplir lo siguiente:

• Un tag estándar tendrá la siguiente estructura:

<prefix:name {attribute={“value”|’value’}}*> body</prefix:name>

• Un tag vacío tendrá la siguiente estructura:

<prefix:name {attribute={“value”|’value’}}*/>

Los prefijos, los nombres de los tags y los de sus atributos distinguen entre mayúsculas y minúsculas.


8.5. Tags personalizados (II)

Una librería de tags ya existente se compone de dos elementos:

• Fichero JAR con las clases Java que implementan los tags

• Fichero XML denominado descriptor de la librería (Tag Library Descriptor, TLD).

Para poder utilizar una librería de tags ya existente, debemos declarar el TLD en el fichero web.xml de la aplicación utilizando el elemento <taglib>. También deberemos tener en cuenta que, a partir de la versión 2.4 de la especificación de Servlets, el elemento <taglib> se incluye dentro del elemento <jsp-config>.

<jsp-config> <taglib> <taglib-uri> http://www.coritel.es/csdc/curso-servlets-taglib </taglib-uri> <taglib-location>

/WEB-INF/curso-servlets.tld </taglib-location>

</taglib></jsp-config>


8.5. Tags personalizados (III)

Normalmente el TLD se guarda en el directorio WEB-INF, mientras que el fichero JAR con la librería se guarda en el directorio WEB-INF/lib. El mapeo que realizamos en el fichero web.xml empareja un TLD situado en una localización física a una URI utilizada como identificador lógico de la librería.

A partir de la versión 2.4 de la especificación de Servlets, no es necesario declarar el TLD pues su localización es obligatoriamente el directorio WEB-INF.

Para utilizar la librería en un JSP, debemos usar la directiva taglib utilizando la URI de la librería tal y como la hemos declarado en el fichero web.xml:

<%@ taglib uri=“http://www.coritel.es/csdc/curso-servlets-taglib” prefix=“csdc” %>

Y con el prefijo que definimos, accedemos a los tags que componen la librería:

<csdc:tabla nombre=“ConsultaUsuarios”> <csdc:iterar nombre=“elemento”> <csdc:campo nombre=“username”/> </csdc:iterar></csdc:tabla>


8.5. Tags personalizados (IV)

Para desarrollar tags personalizados, dentro de la especificación se incluye un API denominada Tag Handler.

Se crea una clase que implementa el interfaz javax.servlet.jsp.tagext.Tag. Este interfaz declara una serie de métodos que el servlet asociado al JSP ejecuta cuando encuenta, en tiempo de ejecución, el tag de apertura y el de cierre del elemento.

El método doStartTag() es ejecutado cuando el tag de apertura es procesado. Análogamente, el método doEndTag() es ejecutado cuando el tag de cierre es procesado.

Para facilitar el desarrollo de tags, el API incluye la clase javax.servlet.jsp.tagext.TagSupport que proporciona una implementación por defecto del interfaz Tag. Esta clase proporciona una variable de tipo javax.servlet.jsp.PageContext con la que podemos acceder a las variables implícitas.

Para desarrollar tags más complejos, el API incluye las interfaces IterationTag (para tags que deben iterar su contenido) y BodyTag (para tags que deben manipular el resultado de evaluar su contenido).


8.5. Tags personalizados (V)

Para procesar los tags de una forma diferente, se incluye la interfaz SimpleTag, la cuál únicamente declara el método doTag(), el cuál se evaluará una sola vez cuando el tag se procesa en tiempo de ejecución y si lo precisa, se encargará de evaluar el contenido o de iterar sobre él. La clase SimpleTagSupport puede utilizar como base para construir nuevos tags, de forma análoga a la clase TagSupport sobre el interfaz Tag.

Un tag con contenido opcional evalúa, en el método doStartTag(), la condición que generamos a partir de los atributos del tag, y en el caso de cumplirse, devuelve la constante EVAL_BODY_INCLUDE. Si la condición no se cumple, devuelve la constante SKIP_BODY.

Los tags iteradores implementan al interfaz IterationTag. Este interfaz introduce el método doAfterBody(), que es el que utilizaremos para verificar si procede una nueva iteración del contenido del tag o no, lo que se consigue devolviendo EVAL_BODY_AGAIN o SKIP_BODY.

Los elementos fundamentales de un tag personalizado respecto a una página JSP son tres:

• Tag de apertura: invoca al método doStartTag().

• Contenido: Si el valor que devuelve la invocación al método anterior es igual a la constante Tag.EVAL_BODY_INCLUDE, la página JSP puede procesar el contenido del tag.

• Tag de cierre: invoca al método doEndTag().

Referencias


· Las especificaciones oficiales de la norma Java EE (antiguamente J2EE) y de las API’s de Servlets y JavaServer Pages pueden descargarse de la web de Sun:

http://java.sun.com/javaee/reference/index.jsp http://java.sun.com/products/servlets http://java.sun.com/products/jsp

· El tutorial oficial contiene mucha información acerca de cómo trabajar con Servlets y JSP’s:

http://java.sun.com/j2ee/1.4/docs/tutorial/doc http://java.sun.com/javaee/5/docs/tutorial/doc

· Para descargar y obtener documentación sobre Tomcat y sobre Eclipse, el mejor punto de partida son las webs oficiales de ambos productos:

http://tomcat.apache.org http://www.eclipse.org

Referencias (II)


· El sitio Web TheServerSide contiene mucha información sobre tecnologías Web, los últimos productos, librerías y tendencias, además de tutoriales y libros que podemos descargar de forma gratuita:

http://www.theserverside.com

· El sitio Web JavaWorld también es una fuente importante de información sobre tecnología Java y Web. En este sitio se publican artículos y tutoriales muy útiles:

http://www.javaworld.com

· Y, por supuesto, el portal de SDC dedicado a la Capability de Java:

https://tseme.accenture.com/sites/SDC/Java

Curso: Programación Web con Tecnología Java

Technology

Transcript of Curso: Programación Web con Tecnología Java