Unidad de Aprendizaje 1

INTRODUCCIÓN A JAVA EE

ÍNDICE 1.1 Introducción ..........................................................................3  1.1.1  Java Card .......................................................................... 3   1.1.2  Java Micro Edition (Java ME) ......................................... 4  1.1.3  Java Standard Edition (Java SE).................................... 4  1.1.4  Java Enterprise Edition (Java EE) .................................. 4  1.2 El modelo de aplicación Java EE........................................5  1.2.1  Componentes Java EE .................................................... 6  1.2.2  Contenedores Java EE .................................................... 7  1.2.3  Servicios Java EE ............................................................. 8  1.3 El diseño de aplicaciones Java EE .....................................8  1.4 Las especificaciones Java EE...........................................10  1.5 El ensamblado y despliegue de aplicaciones Java EE ..13  1.6 El Servidor de Aplicaciones Java EE................................15  PARA RECORDAR ....................................................................18 

MÓDULO A – Unidad 1: Introducción a Java EE

1.1

Introducción

Debido a la naturaleza del lenguaje Java: portable, seguro, multithread, etc…, está siendo utilizado en multitud de ámbitos y tecnologías, desde el chip de una tarjeta de crédito hasta un servidor de la más alta gama. Evidentemente,

estos

distintos

ámbitos

o

entornos,

tienen

unas

características

y

peculiaridades muy distintas entre sí. Por ejemplo, la cantidad de memoria disponible en el chip de una tarjeta de crédito y la de un servidor es muy distinta, por lo que habrá que tenerlo en cuenta a la hora de desarrollar las aplicaciones. Es por ello que existen distintas plataformas Java, dependiendo del ámbito en el que se vaya a trabajar. Son las siguientes: 

Java Card.



Java Micro Edition (Java ME).



Java Standard Edition (Java SE).



Java Enterprise Edition (Java EE).

Podemos verlas resumidas en el siguiente gráfico:

1.1.1 Java Card La plataforma Java Card define las APIs y requerimientos necesarios para poder ejecutar aplicaciones Java en los chips de las tarjetas. Debido a las mínimas prestaciones del entorno de ejecución contiene el API más escueto. El estudio de esta plataforma no es el objetivo de este curso, pero si el alumno quiere profundizar en este tema podrá encontrar más información en la siguiente URL: http://www.oracle.com/technetwork/java/javame/javacard/overview/getstarted/index.html

3

1.1.2 Java Micro Edition (Java ME) La plataforma Java Micro Edition define las APIs y requerimientos necesarios para poder ejecutar aplicaciones Java en dispositivos embebidos. Debido a la gran diversidad de estos dispositivos, desde teléfonos móviles o buscas con pocas prestaciones hasta televisores o automóviles mucho más potentes, se definieron distintas configuraciones con más o menos APIs y por tanto, posibilidades. Por defecto existen estos dos:  CLDC (Connected Limited Device Configuration): Define las APIs y la JVM (denominada KVM) para dispositivos con muy pocas prestaciones.  CDC (Connected Device Configuration): Define las APIs para dispositivos con pocas prestaciones pero conectados a la red. No requiere una JVM especial. El estudio de esta plataforma no es el objetivo de este curso, pero si el alumno quiere profundizar en este tema podrá encontrar más información en la siguiente URL: http://www.oracle.com/technetwork/java/javame/index.html

1.1.3 Java Standard Edition (Java SE) La plataforma Java Standard Edition (Java SE) define las APIs y requerimientos necesarios para poder ejecutar aplicaciones Java de escritorio en ordenadores personales o portátiles. El estudio de esta plataforma no es el objetivo de este curso, pero si el alumno quiere profundizar en este tema, Aula Mentor cuenta con otros dos cursos que la cubren:  Programación en Java – Inicial  Programación en Java – Avanzado Puedes consultar la información de estos cursos en www.aulamentor.es, en el apartado “Cursos” – “Programación”.

1.1.4 Java Enterprise Edition (Java EE) La plataforma Java Enterprise Edition (Java EE) define las APIs y requerimientos necesarios para poder ejecutar aplicaciones Java servidoras, con todo lo que ello supone: clienteservidor, multiusuario, transaccionalidad, escalabilidad, etc…en definitiva, características que no eran importantes o imprescindibles en aplicaciones de escritorio. Se apoya en la plataforma Java SE, por lo que es imprescindible conocer y dominar dicha plataforma antes de aventurarse en esta otra. Utiliza la misma Máquina Virtual Java (JVM). Este curso se centra precisamente en esta plataforma, aunque no en su totalidad. Como veremos un poco más adelante, las aplicaciones Java EE pueden dividirse en varias capas y este curso se centra la denominada capa web o de presentación. La plataforma Java Enterprise Edition ha pasado por distintas nomenclaturas y versiones a lo largo de su vida, de manera que hubo momentos en el tiempo en el que se denominó Java 2 y luego simplemente Java. Las versiones también han sufrido modificaciones, comenzando a numerarse como 1.2, 1.3… para a posteriori pasar a numerarse como 5.0, 6.0… Actualmente estamos en la versión 6.0, pero en su totalidad han existido:

 Java 2 EE 1.2 4

MÓDULO A – Unidad 1: Introducción a Java EE  Java 2 EE 1.3  Java 2 EE 1.4  Java EE 5.0  Java EE 6.0 La definición de esta y las otras plataformas se realiza mediante un proceso colaborativo entre distintas empresas denominado Java Community Process (JCP). Para cada plataforma, API, funcionalidad… se crea lo que se denomina como Java Specification Request (JSR) donde se sientan las bases y especificaciones de dicha plataforma, API o funcionalidad. En concreto la discusión y definición de la futura plataforma Java EE 7.0 se puede seguir en la siguiente URL: http://www.jcp.org/en/jsr/detail?id=342

1.2

El modelo de aplicación Java EE

El modelo de aplicaciones Java EE define una arquitectura para implementar servicios como aplicaciones multicapa que aseguren la escalabilidad, accesibilidad y facilidad de gestión necesarias en un ámbito empresarial. El modelo divide el trabajo a realizar en la implementación en dos partes: 

La lógica de presentación y de negocio a implementar por el desarrollador.



Los servicios estándar que ofrece la plataforma Java EE.

El desarrollador puede apoyarse en los servicios ofrecidos por la plataforma Java EE en vez de reinventar la rueda una y otra vez, facilitándole así el concentrarse únicamente en la lógica específica de su aplicación. La plataforma Java EE utiliza un modelo de programación distribuido en distintas capas. La lógica de la aplicación se divide en distintos componentes dependiendo de su funcionalidad, y estos son desplegados en las distintas capas dependiendo de a cuál pertenecen. Las distintas capas son: 

Capa cliente (Client Tier): responsable de la interacción con el usuario.



Capa web (Web Tier): responsable del control de la aplicación y en ocasiones también de la interacción con el usuario.



Capa de negocio (Business Tier): responsable de la lógica de la aplicación propiamente dicha.



Capa de datos (EIS Tier): responsable de la persistencia de datos y/o lógica especializada (conocida con el nombre de EIS: Enterprise Information System, o Sistema

de

Información

Empresarial).

Por

ejemplo

ERPs,

BBDD,

Motores

Transaccionales (CICS, IMS, Tuxedo…). A continuación mostramos este concepto de multicapa en un diagrama:

5

Es muy importante tener en cuenta, que esta división es puramente lógica y no física. Es decir, físicamente cada capa no tendrá por qué estar en máquinas independientes, sino que podrán compartir hardware. Por ejemplo, veremos que lo normal será que el entorno de desarrollo que montaremos para resolver las distintas actividades de este curso tendrá todas las capas físicamente en la misma máquina. Adicionalmente al tema multicapa, el modelo de aplicación Java EE define otros tres conceptos claves para entender la plataforma: 

Componentes: Unidades de software que forman o componen la aplicación.



Contenedores: Entorno de ejecución donde se ejecutan los componentes.



Servicios: Funcionalidades estándar que todo contenedor debe proveer a los componentes.

Veamos qué son y en qué consisten cada uno de estos conceptos.

1.2.1 Componentes Java EE Una aplicación Java EE está compuesta de componentes. Un componente Java EE es una unidad de software funcional auto contenida que se ensambla como parte de una aplicación Java EE y que puede interactuar con otros componentes. Las especificaciones Java EE definen lo siguientes tipos de componentes: 

Componentes cliente: son aplicaciones Java SE (AWT/Swing, Applets) o un navegador web (Firefox, Chrome, IExplorer…). Se despliegan en la capa cliente.

6

MÓDULO A – Unidad 1: Introducción a Java EE 

Componentes web: son Java Servlets, JavaServer Pages (JSP) o JavaServer Faces (JSF). Se despliegan en la capa web.



Componentes de negocio: Enterprise JavaBeans (EJB). Se despliegan en la capa de negocio.

1.2.2 Contenedores Java EE Normalmente el desarrollo de una aplicación empresarial es muy complicado dado que el desarrollador tiene que tener en cuenta temas muy importantes como la gestión multiusuario, la gestión de la transaccionalidad, la gestión de la seguridad, la compartición de recursos, etc… El modelo de programación de la plataforma Java EE facilita enormemente esta tarea con la definición de los contenedores Java EE. Estos contenedores ofrecen al desarrollador una serie de servicios sobre los que se puede apoyar permitiéndole centrarse en el desarrollo de la lógica de negocio de la aplicación propiamente dicha. Dependiendo del tipo de contenedor, ofrecerá unos servicios u otros, y permitirá desplegar en él un tipo de componente u otro. Los tipos de contenedores Java EE son:  Contenedor cliente (Application Client Container o Applet Container).  Contenedor web (Web Container).  Contenedor de negocio o de EJBs (EJB Container). Como podemos ver, cada tipo de contenedor corresponde con una de las capas definidas, a excepción de la capa de datos que está implementada por otro tipo de productos (ya mencionados anteriormente) ajenos a la plataforma Java EE. En el siguiente diagrama, podemos observar la relación entre los distintos tipos de contenedores Java EE:

7

1.2.3 Servicios Java EE Las especificaciones Java EE, definen una serie de funcionalidades que los distintos tipos de contenedores deberán implementar y ofrecer a los desarrolladores de aplicaciones Java EE. Existen multitud de servicios, pero simplemente destacaremos algunos:  De directorio: para la indexación y búsqueda de componentes y recursos.  De despliegue: para facilitar la descripción y personalización de componentes a la hora de su instalación.  De transaccionalidad: para poder ejecutar distintas acciones en una misma unidad transaccional.  De seguridad: para poder autenticar y autorizar a los usuarios de una aplicación.  De acceso a datos: para facilitar el acceso a las Bases de Datos.  De conectividad: para facilitar el acceso a los distintos Sistemas de Información Empresarial (EIS).  De mensajería: para poder comunicarse con otros componentes, aplicaciones o EISs.

1.3

El diseño de aplicaciones Java EE

Todos los informáticos saben, que antes de ponerse a programar hay una fase muy importante de análisis y de diseño donde se estudia y define la solución. Para ello, contamos con el lenguaje UML (Unified Modeling Language) que define una serie de diagramas y notaciones para poder plasmar estos análisis y diseños. Nota: El lenguaje UML no es objeto de este curso pero se cubre con cierta profundidad en el curso de Aula Mentor: Programación en Java – Inicial. Adicionalmente, existe el concepto de Patrones de Diseño, que son un conjunto de soluciones (o diseños) a los problemas más comunes en la programación de aplicaciones, que han demostrado ser útiles y eficientes en la resolución de dichos problemas. Su existencia, permite poder reutilizar y aplicar soluciones existentes, y no estar reinventando la rueda constantemente. Pues bien, existe un conjunto importante de estos patrones de diseño muy relacionados con el desarrollo de aplicaciones Java EE. A lo largo del curso iremos viendo algunos, pero si el alumno quiere profundizar en este tema tiene el catálogo completo en las Blue Prints de Java EE: http://www.oracle.com/technetwork/java/catalog-137601.html

8

MÓDULO A – Unidad 1: Introducción a Java EE En este capítulo de introducción a Java EE, vamos a hablar de uno que ataca directamente las problemáticas derivadas del modelo de una aplicación Java EE multicapa. Es conocido con el nombre de: Modelo-Vista-Controlador (MVC). Las aplicaciones que manejan acceso a datos, gestionan distintas presentaciones y tienen lógica de negocio compleja, suelen sufrir un problema serio a la hora de mantenerlas debido a interdependencias entre todos los componentes. Dichas interdependencias también dificultan la reutilización de código, obligando a rescribir más veces de las deseadas una lógica muy parecida. El patrón de diseño MVC resuelve estos problemas desacoplando el acceso a datos de la lógica de negocio y esta de la presentación. De esta forma, se podrá reutilizar un acceso desde distintas funcionalidades, o reutilizar la misma funcionalidad desde distintos tipos de presentación, etc… facilitando también el mantenimiento posterior: 

El Modelo (Model): Representa los datos y cualquier lógica de negocio relacionada con ellos.



La Vista (View): renderiza el contenido de los modelos dependiendo de la tipología de cliente (navegador web, teléfono móvil, etc…), permitiendo su visualización.



El Controlador (Controller): define el comportamiento general de la aplicación coordinando a las otras dos partes (Modelo y Vista).

Veamos el patrón de diseño en un diagrama:

9

Pues bien, los distintos tipos de componentes que hemos introducido en el apartado del modelo de aplicación Java EE, encajan perfectamente en este diseño:  Modelo: Enterprise JavaBeans, POJOs (Plain Old Java Objects).  Vista: JavaServer Pages (JSP), JavaServer Faces (JSF).  Controlador: Java Servlets. Un ejemplo del flujo de una aplicación Java EE sería algo así: 1. El cliente, por ejemplo un navegador, solicitará una funcionalidad desde el interface visual (Vista). 2. Dicha petición entrará a través de un Java Servlet (Controlador). 3. Dicho Java Servlet, analizará qué se está pidiendo, qué información adicional aporta y decidirá que Enterprise JavaBean o POJO (Modelo) cubre dicha petición. 4. Lo invocará, y tras recibir un resultado, decidirá qué JavaServer Page (JSP) muestra dicho resultado al cliente (Vista). 5. El resultado será devuelto y mostrado. Y visualmente:

Evidentemente, las aplicaciones se pueden desarrollar sin tener en cuenta estos patrones de diseño, pero está demostrado sobradamente en el mercado, el aumento de productividad y mejora del mantenimiento con su uso. A lo largo del curso iremos insistiendo en este punto y detallando y practicando tanto este patrón como otros.

1.4

Las especificaciones Java EE

Las especificaciones Java EE son el conjunto de las definiciones detalladas de los conceptos que forman parte de la plataforma Java EE: componentes, contenedores y servicios. 10

MÓDULO A – Unidad 1: Introducción a Java EE No entraremos en el detalle de cada una. A lo largo del curso, iremos desgranando aquellas especificaciones relacionadas con la programación web. En concreto, las especificaciones Java EE 6.0 (última versión en el momento de la redacción de este manual) están compuestas por las siguientes definiciones (en negrita las que cubriremos en el curso): 

Java API for RESTful Web Services (JAX-RS) 1.1



Implementing Enterprise Web Services 1.3



Java API for XML-Based Web Services (JAX-WS) 2.2



Java Architecture for XML Binding (JAXB) 2.2



Web Services Metadata for the Java Platform



Java API for XML-Based RPC (JAX-RPC) 1.1



Java APIs for XML Messaging 1.3



Java API for XML Registries (JAXR) 1.0



Java Servlet 3.0



JavaServer Faces 2.0



JavaServer Pages 2.2/Expression Language 2.2



Standard Tag Library for JavaServer Pages (JSTL) 1.2



Debugging Support for Other Languages 1.0



Contexts and Dependency Injection for Java (Web Beans 1.0)



Dependency Injection for Java 1.0



Bean Validation 1.0



Enterprise JavaBeans 3.1 (incluye Interceptors 1.1)



Java EE Connector Architecture 1.6



Java Persistence 2.0



Common Annotations for the Java Platform 1.1



Java Message Service API 1.1



Java Transaction API (JTA) 1.1



JavaMail 1.4



Java Authentication Service Provider Interface for Java Authorization Contract for Containers 1.3



Java EE Application Deployment 1.2 11



J2EE Management 1.1

Dado que la plataforma Java EE extiende la Java SE, existen especificaciones Java SE incluidas en Java EE: 

Java API for XML Processing (JAXP) 1.3



Java Database Connectivity 4.0



Java Management Extensions (JMX) 2.0



JavaBeans Activation Framework (JAF) 1.1



Streaming API for XML (StAX) 1.0



Java Naming and Directory Interface (JNDI) 1.2

Como ya hemos comentado, la plataforma Java EE es un tema muy extenso que toca gran cantidad de ámbitos y tecnologías. Nosotros en este curso titulado “Programación Web” nos centraremos exclusivamente en aquellas especificaciones relacionadas con la presentación y el acceso a Bases de Datos. Existe documentación on-line de todas estas especificaciones o APIs que serán de enorme utilidad a la hora de desarrollar aplicaciones Java EE: http://download.oracle.com/javaee/6/api/

12

MÓDULO A – Unidad 1: Introducción a Java EE

1.5

El ensamblado y despliegue de aplicaciones Java EE

Una aplicación Java EE está formada por un empaquetamiento de una o varias unidades conocidas con el nombre de módulos. Estos módulos contienen a su vez:  Uno o varios componentes (Java Servlets, Enterprise JavaBeans (EJB)…).  Un descriptor de despliegue que describe el contenido y características del módulo (desde la versión 5.0 estos descriptores son opcionales, ya que el propio código puede ser auto descriptivo mediante el uso de anotaciones). Existen distintos tipos de módulos dependiendo de su contenido y el contenedor donde se vaya a ejecutar. Los distintos módulos van empaquetados en un fichero JAR (Java ARchive). No obstante, la extensión de dicho fichero dependerá del tipo de módulo:  Módulo Web (Web Module): contiene normalmente Java Servlets, JavaServer Pages (JSP), JavaServer Faces (JSF), contenidos estáticos como imágenes, HTMLs, CSSs… La extensión del fichero empaquetado será WAR (Web ARchive).  Modulo de EJBs (EJB Module): como su nombre indica, contiene Enterprise JavaBeans (EJB). La extensión del fichero empaquetado es la de por defecto, JAR (Java ARchive).  Modulo cliente (Application Client Module): contiene el código de la aplicación cliente. La extensión del fichero empaquetado es la de por defecto, JAR (Java ARchive).  Modulo

Adaptador

(Resource

Adapter

Module):

contiene un conector para

comunicarse con un Sistema de Información Empresarial (EIS). La extensión del fichero empaquetado será RAR (Resource ARchive). La aplicación Java EE a su vez, también es un empaquetado de los distintos módulos que la forman. La extensión del fichero empaquetado será EAR (Enterprise ARchive). Una aplicación Java EE no tiene por qué contener módulos de todos los tipos, lo que si es necesario, es que tenga como mínimo uno independientemente del tipo. Gráficamente, la estructura de una aplicación Java EE empaquetada sería la siguiente, partiendo desde la raíz del EAR (Assembly Root):

13

El descriptor de despliegue de una aplicación Java EE es un fichero XML llamado application.xml que reside en un directorio denominado META-INF. Como ya hemos mencionado, desde la versión 5.0 de las especificaciones Java EE, este descriptor de despliegue es opcional si se han usado anotaciones en el código. No obstante, no está mal seguir utilizándolos para que los administradores de los sistemas de una manera legible y sencilla puedan entender el contenido y las características de la aplicación. Un ejemplo de descriptor de despliegue sería:             PruebaConnector.rar              PruebaClient.jar              PruebaEJB.jar                      PruebaWeb.war        PruebaWeb              Se trata de una aplicación Java EE que contiene un módulo de cada tipo. No hay que preocuparse si no se entiende el contenido del fichero como tal, ya que de momento, simplemente se trata de ver un ejemplo del concepto de descriptor de despliegue.

14

MÓDULO A – Unidad 1: Introducción a Java EE Debido a que este curso es sobre programación web, nos centraremos únicamente en los módulos web, aunque no está de más conocer la existencia de otro tipo de módulos.

1.6

El Servidor de Aplicaciones Java EE

Hasta aquí, todo han sido especificaciones, definiciones… pero para poder ejecutar una aplicación Java EE necesitamos un entorno de ejecución. Dicho entorno de ejecución se conoce con el nombre de Servidor de Aplicaciones. Un Servidor de Aplicaciones por tanto, es un producto de software que implementa todas las especificaciones Java EE. De manera que al desplegar o instalar una aplicación Java EE en el servidor, sabemos seguro que va a encontrarse con todos los contenedores y servicios definidos por la especificación y que seguramente utiliza y necesita la aplicación. Existe una batería de pruebas estándar que todo proveedor de Servidores de Aplicaciones debe pasar satisfactoriamente para poder decir que es Java EE. Es lo que se conoce con el nombre de JCK (java Compatibility Kit o Kit de Compatibilidad Java). Gracias a la existencia del estándar Java EE, podemos tener la tranquilidad de que nuestra aplicación debe funcionar perfectamente en el Servidor de Aplicaciones de cualquier proveedor, asegurándonos así que no debemos de trabajar con ninguno en concreto. Existen multitud de Servidores de Aplicaciones en el mercado. Podríamos categorizarlos de la siguiente forma:  Gratuitos o de pago.  Certificados Java EE o no. A continuación comentamos algunos. No están todos los que son, ni son todos los que están, pero si los más usados y conocidos:  Apache Tomcat: Es gratuito de código abierto. No cumple con el 100% de las especificaciones Java EE por lo que no se puede decir que sea un Servidor de Aplicaciones Java EE. Pero si que cubre algunas de las especificaciones relacionadas con la programación web que estudiamos en este curso: Java Servlet 3.0, JavaServer Pages 2.2, Java Database Connectivity 4.0 y Java Naming and Directory Interface 1.2 Este es el Servidor de Aplicaciones que usaremos en este curso. En los Materiales de Apoyo de la Mesa del Alumno, encontraréis las instrucciones de descarga, instalación y configuración del servidor.

URL: http://tomcat.apache.org 15

 Jetty: Es gratuito y de código abierto. Al igual que pasara con Apache Tomcat, tampoco implementa el 100% de las especificaciones Java EE. Una vez más, se centra exclusivamente en algunas especificaciones web.

URL: http://jetty.codehaus.org/jetty/  WebSphere Application Server: Es de pago de la empresa IBM. Se trata de un Servidor de Aplicaciones Java EE completo.

URL: http://www-01.ibm.com/software/webservers/appserv/was/ 

Apache Gerónimo: Es gratuito y de código abierto. Se trata de un Servidor de Aplicaciones Java EE completo.

URL: http://geronimo.apache.org 

Oracle Weblogic Server: Es de pago de la empresa Oracle. Se trata de un Servidor de Aplicaciones Java EE completo.

16

MÓDULO A – Unidad 1: Introducción a Java EE URL: http://www.oracle.com/us/products/middleware/application-server/ 

GlassFish: Es gratuito y de código abierto. Se trata de un Servidor de Aplicaciones Java EE completo.

URL: http://glassfish.java.net/ 

JBoss: Es gratuito y de código abierto. Se trata de un Servidor de Aplicaciones Java EE completo.

URL: http://www.jboss.org/jbossas

17

PARA RECORDAR

 En esta unidad hemos visto la diferencia entre las distintas versiones de Java: Java Card, Java Micro Edition, Java Standar Edition y Java Enterprise Edition (Java EE).

 Las aplicaciones Java EE, están distribuidas en distintas capas para una mejor organización funcional: capa cliente (para interactuar con el usuario), capa web (para llevar el control de la aplicación y a veces interactuar con el usuario), capa de negocio (contiene la lógica del negocio como tal) y la capa de datos (contiene la información de negocio).

 A su vez la plataforma Java EE, para poder ejecutar las aplicaciones Java EE multicapa, está formada por:  Componentes: Unidades de software que forman o componen la aplicación  Contenedores: Entorno de ejecución donde se ejecutan los componentes.  Servicios: Funcionalidades estándar que todo contenedor debe proveer a los componentes.

 Para poder diseñar aplicaciones Java EE, ya existen distintos patrones de diseño muy extendidos que posibilitan la reutilización de los componentes y un mejor mantenimiento de los mismos, como es el patrón Modelo-Vista-Controlador (MVC).

 Para que una aplicación Java EE, pueda ejecutarse en un servidor Java EE, estos deben de cumplir las especificaciones determinadas en una versión dada o al menos aquellas necesarias para el tipo de aplicación que se desea implementar.

 Las aplicaciones Java EE (fichero EAR) están formadas por al menos un módulo de los siguientes tipos: Módulo Web (fichero WAR), Modulo de EJBs (fichero JAR), Modulo cliente (fichero JAR), Modulo Adaptador (fichero RAR).

18

 En el mercado existen una multitud de servidores de aplicaciones, pudiendo ser clasificados por dos categorías: 

Gratuitos o de pago.



Certificados Java EE o no.

19

20

Unidad de Aprendizaje 2

EL ENTORNO DE DESARROLLO

ÍNDICE 2.1

Introducción ................................................................... 23

2.2

Descarga, instalación y configuración del entorno de desarrollo........................................................................ 24 2.2.1 Java Runtime Environment (JRE) .................................24 2.2.2 Eclipse IDE for Java EE Developers ............................29 2.2.3 Apache Tomcat...............................................................34

PARA RECORDAR.................................................................... 40

MÓDULO A – Unidad 2: El Entorno de Desarrollo

2.1

Introducción

Existen multitud de herramientas de desarrollo y ejecución de aplicaciones Java EE. Muchas de ellas son de pago, pero existen también gratuitas proporcionadas por la Comunidad Open Source. Aunque en condiciones normales, en el día a día de una empresa se suelen utilizar soluciones de pago, principalmente por su estabilidad y soporte oficial, para la realización de este curso nos vamos a apoyar en herramientas gratuitas. En concreto: 

Eclipse IDE for Java EE Developers 3.7.x de Eclipse.org: Herramienta para el desarrollo.



Apache Tomcat 7.0.x de The Apache Software Foundation: Herramienta para la ejecución de aplicaciones web propuestas en este curso.

Como decimos, ambas dos son gratuitas y descargables de la red. No obstante, vamos a comentar algunas otras herramientas de desarrollo, aunque no las vayamos a utilizar, para el conocimiento del alumno (los servidores de aplicaciones ya se han mencionado en la Unidad 1): 

Java Enterprise Edition SDK: Es el entorno de desarrollo de referencia. Es gratuito y no cuenta con herramientas visuales. Es decir, sería el homónimo a la JDK de Java SE.

URL: http://www.oracle.com/technetwork/java/javaee/downloads/index.html 

Eclipse IDE for Java EE Developers: Es gratuito y de código abierto. En concreto, es el que utilizaremos en este curso como hemos mencionado anteriormente.

URL: http://www.eclipse.org/ 

Rational Application Developer: Es de pago de la empresa IBM.

23

URL: http://www.ibm.com/software/awdtools/developer/application/ 

NetBeans IDE: Es gratuito y de código abierto.

URL: http://netbeans.org/ 

Oracle JDeveloper: Es de pago de la empresa Oracle.

URL: http://www.oracle.com/technetwork/developer-tools/jdev/overview/index.html

2.2

Descarga, instalación y configuración del entorno de desarrollo

A continuación, describiremos los pasos para descargar, instalar y configurar las herramientas seleccionadas

en

este

curso

anteriormente

mencionadas

para

poder

realizar

satisfactoriamente las actividades de este curso. 2.2.1 Java Runtime Environment (JRE) Como seguramente ya conocerá el alumno, el Java Runtime Environment (JRE) es el entorno de ejecución Java, conocido también con el nombre de Java Virtual Machine (o Máquina Virtual Java). Es imprescindible para poder ejecutar código Java en un ordenador, y debido a que las dos herramientas que vamos a utilizar: Eclipse IDE for Java EE Developers y Apache Tomcat están desarrollados en Java, es necesaria la existencia de un JRE en nuestra máquina para poder ejecutarlas. Ir a la siguiente URL http://www.oracle.com/technetwork/java/javase/downloads mediante un navegador, y descargar el JRE 7. Para ello, seleccionar “Download JRE”:

24

MÓDULO A – Unidad 2: El Entorno de Desarrollo

En la siguiente pantalla, aceptar la Licencia (“Accept License Agreement”) y elegir la plataforma deseada pulsando el enlace correspondiente (por ejemplo, para Windows x64, sería jre-7u1-windows-x64.exe). Nota: En el momento de la redacción de este manual, el número de Update del JRE 7.0 es el 1, de ahí el nombre jre-7u1-windows-x64.exe; pero en el momento en el que el alumno esté siguiendo este manual, puede que ya exista un Update más moderno y por tanto que haya cambiado el número. No obstante, a excepción del cambio de número y por tanto de nomenclatura, todos los pasos de descarga, instalación y configuración aquí descritos deberían seguir siendo válidos, por lo que el alumno puede elegir utilizar el Update 1 o uno posterior.

25

Guardar el fichero en algún directorio temporal del ordenador:

Para instalarlo, ejecutar el fichero descargado (en nuestro ejemplo, jre-7u1-windowsx64.exe), mediante doble click del ratón.

26

MÓDULO A – Unidad 2: El Entorno de Desarrollo

Pulsar el botón “Install >” para comenzar la instalación. Durante dicho proceso, aparecerá una barra mostrando el progreso de la instalación. Nota: La ubicación por defecto donde se instalará el JRE es C:\Program Files\Java\jre7; si deseamos instalarlo en una ubicación distinta, marcar la casilla “Change destination folder” antes de pulsar el botón “Install >”.

27

Cuando la instalación haya terminado, y si ha sido satisfactoria, debería aparecer la siguiente pantalla:

Pulsar el botón “Close”. 28

MÓDULO A – Unidad 2: El Entorno de Desarrollo Aunque el instalador nos diga que la instalación ha sido satisfactoria, nunca está de más comprobar que efectivamente todo está bien. Para ello, una manera habitual de comprobarlo es abrir una sesión de DOS y ejecutar el comando: java.exe -version Si todo está correcto, debería devolver la versión del JRE instalado:

2.2.2 Eclipse IDE for Java EE Developers A continuación, pasaremos a descargar e instalar Eclipse IDE, la herramienta de desarrollo Java que vamos a utilizar durante este curso. Recordar que es importante asegurarse de la existencia de un Java Runtime Environment (JRE) en el ordenador. Si no existiese, seguir los pasos del apartado anterior. Ir a la siguiente URL http://www.eclipse.org/downloads mediante un navegador, y descargar Eclipse IDE for Java EE Developers para la plataforma deseada, pulsando sobre el enlace correspondiente (en nuestro ejemplo, Windows 64 bits):

29

Aparecerá una página con el mejor servidor para descargar el fichero que hemos solicitado dependiendo de nuestra conexión y localización. Simplemente pulsar sobre la flecha verde y guardar el fichero en un directorio temporal:

30

MÓDULO A – Unidad 2: El Entorno de Desarrollo

Nota: En el momento de la redacción de este manual, la versión de Eclipse es la 3.7.1, es decir, el número de revisión es el 1, de ahí el nombre eclipse-jee-indigo-SR1-win32x86_64.zip; pero en el momento en el que el alumno esté siguiendo este manual, puede que ya exista una revisión más moderna y por tanto que haya cambiado el número. 31

No obstante, a excepción del cambio de número y por tanto de nomenclatura, todos los pasos de descarga, instalación y configuración aquí descritos deberían seguir siendo válidos. El alumno puede elegir por tanto el instalar el Update 1 o elegir otro Update posterior. Descomprimir el fichero que hemos descargado (en nuestro ejemplo, eclipse-jee-indigo-SR1win32-x86_64.zip) en el disco duro donde queramos tener Eclipse. Por ejemplo: D:\eclipse-jee-indigo-SR1-win32-x86_64 Arrancar Eclipse ejecutando: D:\eclipse-jee-indigo-SR1-win32-x86_64\eclipse.exe

Nos preguntará por la ubicación del workspace (o área de trabajo) donde Eclipse va a ir guardando todos los proyectos y ficheros que vayamos desarrollando:

Una vez hayamos seleccionado la ubicación, pulsar el botón “OK”:

32

MÓDULO A – Unidad 2: El Entorno de Desarrollo

Cerrar la pestaña de “Welcome” (Bienvenida):

33

2.2.3 Apache Tomcat Por último, vamos a instalar el servidor Apache Tomcat, necesario para poder ejecutar las aplicaciones Java EE que desarrollemos en el Eclipse IDE for Java EE Developers. Para ello, ir a la siguiente URL http://tomcat.apache.org/download-70.cgi mediante un navegador, y descargar Tomcat para la plataforma deseada desde la sección “Core”, pulsando sobre el enlace correspondiente (en nuestro ejemplo, 64-bit Windows zip):

Descargar y descomprimir el fichero (en nuestro ejemplo, apache-tomcat-7.0.22-windowsx64.zip) en el disco duro donde queramos tener Eclipse. Por ejemplo: D:\apache-tomcat-7.0.22

34

MÓDULO A – Unidad 2: El Entorno de Desarrollo

Nota: En el momento de la redacción de este manual, la versión de Tomcat es la 7.0.22, es decir, el número de revisión es el 22, de ahí el nombre apache-tomcat-7.0.22-windowsx64.zip; pero en el momento en el que el alumno esté siguiendo este manual, puede que ya exista una revisión más moderna y por tanto que haya cambiado el número. No obstante, a excepción del cambio de número y por tanto de nomenclatura, todos los pasos de descarga, instalación y configuración aquí descritos deberían seguir siendo válidos. Como se ha mencionado en las herramientas anteriores, es decisión del alumno, el decidir utilizar esta revisión o una posterior. Una vez hecho esto, ya solo queda configurar Eclipse IDE for Java EE Developers para que utilice el Apache Tomcat que acabamos de descargar e instalar. Para ello, arrancamos de nuevo Eclipse y seleccionamos la vista “Servers”:

35

Pulsaremos el botón derecho del ratón sobre la zona en blanco de esta vista, y elegiremos la opción “New” -> “Server” del menú:

Del listado de posibles servidores, seleccionaremos “Tomcat v7.0 Server” y pulsaremos el botón “Next >”:

36

MÓDULO A – Unidad 2: El Entorno de Desarrollo

En la siguiente pantalla del asistente, añadiremos la ubicación donde hemos instalado Apache Tomcat (en nuestro ejemplo, D:\apache-tomcat-7.0.22

37

Y ya por último, pulsaremos el botón “Finish”. Si todo ha ido bien, ahora en la vista de Eclipse denominada “Servers”, debería aparecer nuestro servidor Apache Tomcat:

Si seleccionamos con el ratón el nuevo servidor, y pulsamos el botón derecho deberíamos ver un menú con las distintas acciones que podemos realizar con él:

38

MÓDULO A – Unidad 2: El Entorno de Desarrollo

Seleccionaremos la opción “Start” y veremos como aparecerá una nueva vista denominada “Console” donde irá apareciendo el log del servidor. En este caso, deberíamos ver cómo va saliendo toda la información del arranque. Algo parecido a esto:

Volviendo a la vista “Servers”, veremos como el estado del servidor ahora ha cambiado poniendo “[Started, Synchronized]”. Podemos parar el servidor nuevamente desde el mismo menú de opciones desde donde lo arrancamos en el paso anterior y una vez lo haya hecho, cerrar Eclipse. Con esto damos por finalizada la instalación y configuración del entorno de desarrollo necesario para llevar a cabo este curso.

39

PARA RECORDAR

 En esta unidad hemos aprendido a instalar la herramienta de desarrollo, Eclipse IDE for Java EE Developers, el servidor de aplicaciones Apache Tomcat y la Java Runtime Environment (JRE) necesarias para la implementación de las aplicaciones web propuestas en este curso.

40

Unidad de Aprendizaje 3

PROTOCOLO HTTP Y LENGUAJE HTML

ÍNDICE 3.1

Introducción ................................................................... 43

3.2

El protocolo HTTP ......................................................... 44 3.2.1 Dirección de Internet o URL..........................................45 3.2.2 Conversaciones HTTP ...................................................46 3.2.3 Sniffer HTTP ....................................................................51

3.3

El lenguaje HTML........................................................... 54 3.3.1 La etiqueta HTML ...........................................................55 3.3.2 La página HTML..............................................................56 3.3.3 El formulario HTML.........................................................57 3.3.3.1 Campos de texto ......................................................58 3.3.3.2 Áreas de texto ..........................................................59 3.3.3.3 Checkboxes...............................................................60 3.3.3.4 Radiobuttons............................................................61 3.3.3.5 Listas y Combos ........................................................62 3.3.3.6 Botones ....................................................................63 3.3.3.7 Campos ocultos ........................................................64

3.4

Ensamblado y despliegue ............................................ 64

PARA RECORDAR.................................................................... 67

MÓDULO A – Unidad 3: El protocolo HTTP y el lenguaje HTML

3.1

Introducción

Al estudiar las aplicaciones Java EE (o Web), es imposible no hablar primero de la red de redes: Internet, y de los fundamentos sobre los que se apoya. Simplificando mucho, esos dos fundamentos son el protocolo de comunicaciones HTTP (HiperText Transfer Protocol) y el lenguaje de etiquetado HTML (HiperText Markup Language). Vamos a hablar un poco más en detalle de lo que es un sistema de comunicaciones en general, y el sistema de comunicaciones en el que se basa Internet: TCP/IP. Un sistema de comunicaciones en general, se representa como una pila de capas en las que cada una aporta una funcionalidad concreta a la comunicación. Existe el modelo de referencia OSI, que representa los sistemas de comunicación desde un punto de vista teórico en 7 capas y luego sistemas de comunicación concretos reales, que implementan ese modelo de referencia de distintas formas, como por ejemplo el TCP/IP o el SNA. En el siguiente diagrama se puede ver la comparativa entre el modelo de referencia OSI y el TCP/IP que es el sistema de comunicaciones que utiliza Internet:

Muy brevemente, repasamos lo que cubre cada uno de los niveles: 1. Físico: Define las características físicas de la red material. 2. Enlace: Proporciona el servicio de envío de datos a través del enlace físico. 3. Red: Gestiona las conexiones de red para las capas superiores. 4. Transporte: Proporciona servicios de detección y corrección de errores. 5. Sesión: Gestiona las conexiones entre aplicaciones cooperativas. 6. Presentación: Estandariza la forma en la que se presentan los datos a las aplicaciones. 7. Aplicación: Aplicaciones que usan la red. 43

Cono podemos observar, el TCP/IP implementa los niveles teóricos en cuatro, a través de distintos protocolos como IP en el nivel que llama Internet, TCP y UDP entre otros en el nivel que llama Transporte, y HTTP, FTP, Telnet, etc… en el nivel que llama Aplicación. Es en este último nivel donde se encuentra el protocolo HTTP que realmente nos interesa para programar aplicaciones Java EE aunque este, sin el resto de los niveles sería inútil. De ahí que se hayan mencionado en esta introducción. Por otro lado, teníamos el lenguaje de etiquetado HTML, la otra piedra angular sobre la que se sustenta Internet. El HTML es el lenguaje mediante el cual definimos los contenidos que fluyen por Internet, conocidas como páginas HTML o páginas Web. Y quizás sin saberlo, todos los días estamos usando ambos dos fundamentos. Los navegadores web (IExplorer, Firefox, Chrome, Opera…) no son mas que aplicaciones que implementan el protocolo HTTP a través del cual se reciben bajo petición páginas HTML. ¿Por qué es tan importante tener claro los conceptos del HTTP y HTML entonces? Porque las aplicaciones Java EE que vamos a aprender a desarrollar, son las que están al otro lado sirviendo las peticiones de los navegadores web. Por tanto, van a tener que entender el protocolo HTTP y van a tener que saber contestar con páginas HTML que muestran la información solicitada. Nota: como decíamos al inicio de esta introducción, esta es una visión muy simplista pero que proporciona una idea clara. Es simplista en el sentido de que no solo se utiliza el protocolo HTTP (aunque si en la mayoría de los casos) ni siempre se utiliza HTML como medio para mostrar la información (aunque nuevamente si en la mayoría de los casos). Otras opciones a modo de ejemplo, mucho menos utilizadas, serían protocolos como FTP o Telnet, y lenguajes de etiquetado como WML o cHTML.

3.2

El protocolo HTTP

Como hemos dicho ya, el protocolo HTTP es el protocolo fundamental desde el punto de vista del desarrollo de aplicaciones Java EE. Es el encargado de la transferencia de los recursos que componen la red. Es un protocolo que sigue un esquema de petición – respuesta (request – response) entre un cliente (habitualmente un navegador) y un servidor (habitualmente un servidor de aplicaciones Java EE como ya vimos en las unidades anteriores) donde el cliente solicita un recurso y el servidor se lo devuelve. Actualmente se encuentra en su versión 1.1, y es un estándar definido por el IETF (RFC 2616): http://www.ietf.org/rfc/rfc2616.txt

44

MÓDULO A – Unidad 3: El protocolo HTTP y el lenguaje HTML 3.2.1 Dirección de Internet o URL Las URLs (Uniform Resource Locator) identifican de forma unívoca un recurso en la red. Un recurso que puede ser una página HTML, una imagen JPG o incluso un componente Java EE como un Java Servlet o una JavaServer Page (JSP). Las URLs constan de las siguientes partes:  Protocolo: HTTP, HTTPS, FTP, Telnet… a utilizar para acceder al recurso.  Servidor: Dirección IP o nombre del servidor donde reside el servicio o aplicación que sabe servir el recurso.  Puerto: Donde está escuchando el servicio o aplicación que sabe servir el recurso.  Path (o camino): Donde está ubicado el recurso.  Recurso: El recurso como tal que estamos solicitando. Utilizando el siguiente formato: Protocolo://Servidor:Puerto/Path/Recurso Nota: Es importante mantener el formato de los dos puntos y las barras. Lo entenderemos mucho mejor con un ejemplo muy sencillo que la mayoría hemos usado alguna vez al buscar algo en Google. Para ello, lo que hacemos es escribir en el navegador la siguiente dirección de Internet o URL: http://www.google.es:80/index.html ¿Qué significa realmente esto que escribimos habitualmente para buscar cosas en Internet? Significa que mediante el protocolo HTTP, nos conectamos a la aplicación que está escuchando en el puerto 80 del servidor www.google.es y le solicitamos el recurso index.html que está en el directorio raíz (porque no hemos especificado ningún path). Muchos estaréis pensando que vosotros no escribís nunca ese 80, o que nunca habíais especificado eso de index.html; correcto. ¿Qué ocurre entonces? Lo que ocurre, es que para ahorrar trabajo a los usuarios, se establecen muchas cosas por defecto. Por ejemplo, se ha establecido un puerto por defecto para cada protocolo de manera que si no decimos el puerto a utilizar, en este caso el navegador añade sin que nosotros lo sepamos el puerto correspondiente. Algunos puertos por defecto son:  HTTP: 80  HTTPS: 443  FTP: 21  Telnet: 23  etc… 45

Y con el nombre del recurso ocurre igual. Está establecido que por defecto si no se especifica el nombre del recurso, las aplicaciones prueben con unos nombres por defecto que suelen ser:  index.html  index.htm  index.jsp  etc… Por tanto, una URL equivalente a la analizada y con mismo resultado sería: http://www.google.es Los servidores en Internet se identifican mediante direcciones IP que consisten en cuatro grupos de números desde el 0 al 255 separados por puntos, por ejemplo: 74.125.39.103 Todo servidor en Internet tiene asignada una dirección IP única. Si no fuese así, sería inaccesible porque al hacer una petición, el sistema de comunicaciones TCP/IP no sabría con cuál conectar. Como el uso de estas direcciones es algo complejo para los usuarios (difíciles de recordar, fácil de cometer un error), existen unos servidores especiales denominados DNS (Domain Name Server o Servidores de Nombres de Dominio) que se encargan de traducir nombres legibles y fáciles de recordar por los usuarios a direcciones IP. Esta traducción mediante la conexión a los servidores DNS la hace el sistema de comunicaciones TCP/IP, que comentamos en la introducción, automáticamente sin la intervención del usuario. Por ejemplo, en el momento de la redacción de este manual, la dirección IP de www.google.es era la del ejemplo: 74.125.39.103, es decir, que en el navegador deberíamos ver la misma página si escribiéramos: http://74.125.39.103 o si escribiéramos: http://ww.google.es 3.2.2 Conversaciones HTTP Como ya comentamos al inicio de este capítulo, HTTP es un protocolo que sigue un esquema de petición – respuesta (request – response) entre un cliente (habitualmente un navegador) y un donde el cliente solicita un recurso y el servidor se lo devuelve. Una petición HTTP se compone a grandes rasgos de:  Método HTTP: se trata de la acción a realizar. Algunos ejemplos como veremos mas adelante son GET y POST.  Recurso sobre el que actuar: es decir, una URL. 46

MÓDULO A – Unidad 3: El protocolo HTTP y el lenguaje HTML  Parámetros: como los argumentos de un método Java. Por el otro lado, una respuesta HTTP se compone de:  Código de estado: un código numérico que indica qué ocurrió con la petición.  Tipo del contenido: que indica el formato de la respuesta. Por ejemplo, una página HTML, un documento XML, una imagen JPG, etc…  Contenido: la respuesta como tal. El envío de peticiones y respuestas, se realiza mediante un mensaje HTTP, es decir, una estructura bien definida que sigue una serie de reglas que todo cliente y servidor que mantengan una conversación HTTP deben conocer y cumplir. Un mensaje HTTP se compone de:  Una cabecera: que incluye información técnica.  Un cuerpo: que incluye el contenido del mensaje como tal. Los métodos HTTP que se pueden utilizar como parte de una petición HTTP son los siguientes:  HEAD: solicita un recurso al servidor, pero que la respuesta no ha de incluir el contenido, solo las cabeceras.  GET: solicita un recurso al servidor (normalmente estático como por ejemplo un fichero).  POST: solicita un recurso al servidor (normalmente dinámico, es decir, la ejecución de una aplicación).  PUT: solicita el envío de un recurso al servidor.  DELETE: solicita la eliminación de un recurso en el servidor.  TRACE: solicita al servidor que le conteste lo mismo que le solicita. Se utiliza normalmente para analizar problemas en la comunicación donde entre el cliente y el servidor existen otra serie de elementos de comunicaciones como proxies, firewalls, etc…  OPTIONS: solicita al servidor conocer qué métodos HTTP soporta.  CONNECT: solicita al servidor cambiar a un sistema de comunicación cifrada (HTTPS). Mas adelante, veremos un poco más en detalle los métodos GET y POST que son los utilizados habitualmente en la programación de aplicaciones Java EE incluyendo algún ejemplo. Los códigos de estado que se pueden recibir en una respuesta HTTP son muchos y variados. Aquí comentamos algunos:  Códigos 2xx: Petición realizada con éxito. 47

o 200: OK. Este es el código que deberíamos recibir habitualmente. o 204: Sin contenido. o 205: Sin contenido, recargar. o 206: Contenido parcial.  Códigos 3xx: Redirección. o 301: Recurso movido de forma permanente. o 303: Ver otro recurso. o 307: Recurso movido de forma temporal.  Códigos 4xx: Error del cliente. o 400: Petición incorrecta. Se produce si el mensaje HTTP de petición tiene errores. No es habitual cuando se usa un navegador, pero si, sí estamos programando un cliente HTTP. o 403: Prohibido. Se produce cuando intentamos acceder a un recurso protegido y no tenemos acceso. o 404: No encontrado. Se produce cuando se solicita un recurso no existente en el servidor.  Códigos 5xx: Error en el servidor. o 500: Error interno. Más habitual de lo que desearíamos. o 503: Servicio no disponible. o 505: Versión HTTP no soportada. Vamos a centrarnos en los dos métodos, es decir, en los dos tipos de petición HTTP más comunes en el desarrollo de aplicaciones Java EE y que con total seguridad utilizaremos: GET y POST. GET es el más simple, y se suele utilizar para solicitar un recurso estático, es decir, un fichero de tipo HTML, JPG, XML…. No obstante, también puede ser usado para solicitar un recurso dinámico, es decir, por ejemplo un componente de una aplicación web, y por tanto, permite el envío de parámetros. Eso si, dichos parámetros van añadidos como parte de la URL y son visibles, lo que desde un punto de vista de seguridad puede ser un problema. Veamos un ejemplo de una petición HTTP con el método GET de un servlet Java que suma dos números: GET /EjemploWeb/Sumador?param1=12¶m2=41 HTTP/1.1 Accept: image/gif, image/x-xbitmap, image/jpeg, */* Referer: http://127.0.0.1/Practica23a/index.html Accept-Language: en-us,es;q=0.5 Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727) Host: 127.0.0.1:8080 48

MÓDULO A – Unidad 3: El protocolo HTTP y el lenguaje HTML Connection: Keep-Alive Este mensaje HTTP, que en concreto es una petición (lo sabemos porque su primera línea es un método HTTP en vez de un código de estado) solo tiene cabecera. No tiene cuerpo. La primera línea de toda petición HTTP siempre es el método HTTP, seguido del recurso sobre el que queremos ejecutar la acción, y por último la versión de protocolo HTTP utilizada por el cliente. Después, hay una secuencia de distintas propiedades (de la forma nombre: valor) que añaden información técnica al mensaje. Por ejemplo, qué tipo de cliente se está utilizando (User-Agent). Hay muchas, y solo comentaremos a lo largo del curso aquellas que tengan relevancia. En este ejemplo, estamos pidiendo el recurso /EjemploWeb/Sumador pasándole dos parámetros: param1 y param2 con los valores 12 y 41. Como se puede ver, se indica que hay parámetros mediante el símbolo ? y se separan los parámetros (parejas de nombre=valor) mediante el símbolo &. Veamos ahora la respuesta HTTP de este mismo ejemplo: HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Set-Cookie: JSESSIONID=304CE17CCEB55869A606CE06271F915B; Path=/EjemploWeb Content-Type: text/html;charset=ISO-8859-1 Content-Length: 314 Date: Sun, 08 Jun 2008 09:19:19 GMT <META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> El resultado de la suma de 12 y 41 es: 53 En este caso, el mensaje HTTP si que incluye tanto cabecera como cuerpo. Lo primero, sabemos que es una respuesta porque la primera línea comienza con la versión HTTP utilizada por el servidor, seguido del código de estado. En este caso, un 200 que indica que todo ha ido bien. Hay otras cabeceras adicionales muy importantes para saber interpretar la respuesta como son: Content-Type, que indica el tipo de contenido del cuerpo (en este caso un fichero HTML) y Content-Lenght, que indica el tamaño del contenido (en este caso 314 bytes). Separado por un salto de línea viene el cuerpo del mensaje HTTP que como ya nos indicaba la cabecera es un fichero HTML (más adelante, en esta misma unidad, hablaremos del lenguaje HTML). 49

POST es el método que habitualmente se utiliza para enviar parámetros, porque van en el cuerpo de la petición en vez de añadidos a la URL del recurso solicitado. Veamos el mismo ejemplo que antes para identificar las diferencias. En este caso la petición sería: POST /EjemploWeb/Sumador HTTP/1.1 Accept: image/gif, image/x-xbitmap, image/jpeg, */* Referer: http://127.0.0.1/EjemploWeb/index.html Accept-Language: en-us,es;q=0.5 Content-Type: application/x-www-form-urlencoded Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727) Host: 127.0.0.1:8080 Content-Length: 19 Connection: Keep-Alive Cache-Control: no-cache param1=45¶m2=21 Nuevamente identificamos que se trata de una petición HTTP porque la primera línea comienza con un método HTTP. Y vemos, que a diferencia de lo que ocurría con el método GET, en esta ocasión la URL no incluye ningún parámetro sino que el mensaje tiene un cuerpo con dichos parámetros. Hay alguna diferencia en alguna cabecera más, pero tampoco entraremos en tanto detalle. La respuesta sería: HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Set-Cookie: JSESSIONID=304CE17CCEB55869A606CE06271F915B; Content-Type: text/html;charset=ISO-8859-1 Content-Length: 314 Date: Sun, 08 Jun 2008 09:27:24 GMT <META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> El resultado de la suma de 45 y 21 es: 66 Como vemos, es igual que la del ejemplo anterior, ya que lo que nos devuelve el servidor si le pedimos lo mismo (aunque sea por dos métodos distintos) siempre será lo mismo. Los parámetros que se envían en una petición, pueden ser cualquier carácter alfanumérico ASCII, incluyendo los caracteres: . (punto), - (guion), * (asterisco) y _ (subrayado). Cualquier otro tipo de carácter ha de ir codificado:  El espacio en blanco con el carácter + (suma).  Cualquier otro carácter con un valor hexadecimal de la forma %xx. Por ejemplo, la ñ (eñe), con %F1. En Internet están las tablas de conversión y el propio lenguaje Java 50

MÓDULO A – Unidad 3: El protocolo HTTP y el lenguaje HTML tiene métodos para decodificar y decodificar caracteres de una URL en la clase java.net.Encoder y java.net.Decoder Es importante tener presente, que si se usa el método GET para el envío de dichos parámetros, es responsabilidad del desarrollador la codificación. Por el contrario, si se usa el método POST, la codificación se realiza de forma automática. No obstante, en los casos en los que el cliente HTTP sea un navegador, como ocurrirá la mayoría de las veces en este curso, es el propio navegador el que se encarga de dicha codificación automáticamente.

3.2.3 Sniffer HTTP En principio, toda esta comunicación HTTP suele ocurrir sin un conocimiento muy profundo por parte del desarrollador de aplicaciones Java EE. Pero como iremos viendo en las sucesivas unidades, si que hay conceptos de los tratados hasta este momento en esta unidad que son imprescindibles de conocer. E incluso, en muchas ocasiones, para depurar un problema de nuestras aplicaciones, será imprescindible analizar los mensajes HTTP que fluyen entre el cliente (por ejemplo, un navegador) y nuestra aplicación Java EE servidora. Ahora, ¿y cómo podemos ver los mensajes HTTP que viajan por la red entre el cliente y el servidor? Para esto existen unas herramientas habituales en el mundo de las redes de comunicaciones que se llaman “sniffers”, que se encargan de monitorizar el tráfico de red. El funcionamiento habitual, consiste en ponerse entre medias del cliente y del servidor, y registrar todo el tráfico que fluye: tanto peticiones como respuestas. La herramienta de desarrollo que utilizamos en este curso, Eclipse IDE for Java EE Developers, incluye un sniffer denominado TCP/IP Monitor. Para acceder a él, ir a las opciones de menú “Window” -> “Show view” -> “Other…”:

51

Seleccionar la vista de “TCP/IP Monitor” de la carpeta “Debug”:

52

MÓDULO A – Unidad 3: El protocolo HTTP y el lenguaje HTML Se abrirá el TCP/IP Monitor en una pestaña más:

En sus propiedades, añadimos una configuración mediante el botón “Add…”, estableciendo el puerto por el que escucha, y a qué dirección y puerto debe renviar todo el tráfico. En nuestro caso, si monitorizamos el tráfico con el Servidor de Aplicaciones Tomcat que tenemos en el propio Eclipse IDE, podríamos decirle que escuche en el puerto 80 (por ejemplo) y que renvíe a nuestra misma máquina al puerto 8080 (puerto por donde escucha por defecto el Servidor de Aplicaciones Tomcat):

Por último, lo arrancamos mediante el botón “Start”. Ahora solo queda, realizar peticiones desde nuestro navegador al servidor, pero en vez de hacerlo directamente al puerto 8080, lo haremos a través del puerto 80 para que el sniffer intercepte las comunicaciones y las renvíe. Así, escucharemos en el puerto 80 de nuestra 53

máquina y lo renviaremos al 8080 del servidor de aplicaciones (que en este ejemplo, también está en nuestra máquina):

De momento, no hay que preocuparse mucho por su funcionamiento. Ya tendremos ocasión de probarlo con las primeras aplicaciones Java EE que desarrollemos

en la siguiente

unidad.

3.3

El lenguaje HTML

El HTML (HiperText Markup Languaje) es el lenguaje utilizado para crear documentos web (o lo que comúnmente se denominan páginas web). Básicamente se trata de un lenguaje de etiquetado, que define la estructura y el contenido de un documento a ser compartido y accedido en Internet a través de un navegador web. Junto con el protocolo HTTP son la base sobre la que se construyó la red de redes conocida como Internet. Este lenguaje está estandarizado bajo la supervisión del W3C. En el momento de la redacción de este manual, la última versión del lenguaje HTML es la 4.01: http://www.w3.org/TR/html4/ aunque la siguiente versión, 5.0, está en proceso de definición: http://www.w3.org/TR/html5/ No obstante, el lenguaje HTML requeriría un manual dedicado para cubrir todas sus características y posibilidades. En nuestro caso, al igual que hemos hecho con el protocolo HTTP, solo haremos un breve recorrido introductorio para conocer lo imprescindible que nos permita desarrollar aplicaciones Java EE. 54

MÓDULO A – Unidad 3: El protocolo HTTP y el lenguaje HTML Para profundizar en el lenguaje HTML recomendamos el curso de Aula Mentor HTML. Adicionalmente, junto con el lenguaje HTML, han ido surgiendo otras tecnologías y lenguajes para dotar a las páginas web de cierto dinamismo y potencia. Algunas de ellas son el lenguaje JavaScript, tecnologías AJAX, etc… que no cubriremos en este curso. Nuevamente, en la oferta de cursos de Aula Mentor, los hay orientados a estas tecnologías.

3.3.1 La etiqueta HTML Como ya hemos dicho, el lenguaje HTML está orientado a etiquetas. Una etiqueta no es más que un elemento que define qué se debe hacer o cómo se debe presentar la información que viene a continuación de ella dentro de una página web. Normalmente, las etiquetas se utilizan a pares, es decir, etiqueta de inicio de definición y etiqueta de final de definición. El formato es el siguiente: [contenido] [ ] Como podemos observar, las etiquetas van definidas entre los caracteres < y >. Y para diferenciar cuándo se trata de una etiqueta de apertura o de cierre, en la de cierre se utiliza el carácter / después del carácter <. Entre la pareja de etiquetas, se añade el contenido que se verá afectado por el significado de dichas etiquetas. Adicionalmente, las etiquetas pueden permitir atributos que complementan el significado y comportamiento de la etiqueta. Veámoslo con un ejemplo rápido:   Hola mundo    Este ejemplo es un fragmento de una página o documento HTML. Y en él, podemos observar fácilmente, que se trata del uso de la etiqueta FONT. En la primera línea vemos el uso de la etiqueta de inicio , y en la tercera línea la etiqueta de final . El contenido que se va a ver afectado por el significado y comportamiento de la etiqueta es el texto Hola mundo de la segunda línea. Adicionalmente, podemos observar que la etiqueta de inicio incluye una serie de atributos, como son ‘size’ (tamaño) y ‘color’. Una etiqueta de final, nunca lleva atributos. El resultado visual en un navegador web de una página web, que incluyera este fragmento sería este:

55

3.3.2 La página HTML Una vez visto la base del lenguaje HTML (las etiquetas), vamos a centrarnos en la página o documento HTML (también nombrada página web). Una página o documento HTML, es un fichero de texto con extensión *.htm o *.html que contiene una información formateada mediante el lenguaje HTML. Aunque los navegadores web, desde siempre han sido muy permisivos con las páginas HTML mal formateadas (etiquetas de final no añadidas, estructura de la página errónea, etc…) vamos a intentar crearlas siempre correctamente. La estructura mínima de una página HTML sintácticamente correcta, es la siguiente:                         Mi primer ejercicio      Este código HTML debería ir salvado en un fichero de extensión *.html y al abrirlo en un navegador, veríamos algo así:

La primera línea es un tanto especial. Se trata de una etiqueta de descripción técnica del fichero HTML donde especifica la versión de HTML utilizada, entre otras cosas.

56

MÓDULO A – Unidad 3: El protocolo HTTP y el lenguaje HTML Pero lo realmente importante viene después, y es, la estructura de una página HTML. Toda página HTML debe ir siempre definida por la etiqueta HTML. Una página HTML se divide en dos secciones distintas:  La cabecera, definida por la etiqueta HEAD.  El cuerpo, definido por la etiqueta BODY. En la cabecera de una página HTML se añadirá información relacionada con la página, como por ejemplo su título (definido por la etiqueta TITLE), mientras que en el cuerpo, irá el contenido de la página como tal. En nuestro caso, simplemente va el texto Mi primer ejercicio. Como se puede observar en la imagen de ejemplo, los navegadores web normalmente muestran el título de la página HTML en la pestaña que está mostrando dicha página (u otros, en la barra de título del navegador). Otro contenido típico de la cabecera de una página HTML, es información específica para algunos buscadores de Internet, que les ayuda a indexar y categorizar la página.

3.3.3 El formulario HTML Como ya hemos comentado, este curso no tiene como objetivo el lenguaje HTML sino la programación de aplicaciones Java EE. Por ello, no vamos a enumerar y explicar las decenas de etiquetas existentes en el lenguaje HTML, Solo nos vamos a centrarnos en un subconjunto que si son imprescindibles para interactuar con aplicaciones Java EE servidoras que son las relacionadas con los formularios HTML. Un formulario es la presentación visual de entrada de datos en una página HTML para ser enviados a una aplicación servidora. La etiqueta que lo define es FORM. Dicha etiqueta puede contener distintos atributos, algunos obligatorios y otros opcionales. Los dos atributos obligatorios son:  Method: El método HTTP que se va a utilizar al enviar al servidor la información recogida en el formulario.  Action: El recurso o componente del servidor al que se le va a enviar la información. Otros atributos posibles son: ‘name’, ‘target’, ‘id’, etc… Ejemplo:  

57

Este formulario va a enviar a un Java Servlet del servidor mediante el método HTTP POST toda la información que contenga. De momento, tal cual está en el ejemplo, no contiene ninguna información. Un formulario puede contener distintos elementos para recoger información del usuario:  Campos de texto.  Áreas de texto.  Checkboxes.  Radiobuttons.  Listas y combos.  Botones.  Campos ocultos. Veamos uno por uno. 3.3.3.1 Campos de texto  Un campo de texto se define mediante la etiqueta INPUT y su atributo ‘type’ con el valor ‘text’. Admite otros atributos como son:  Name: el nombre del campo y por tanto, nombre del parámetro que viajará al servidor.  Value: valor que debe aparecer por defecto si así se desea.  Size: tamaño del campo en la pantalla desde un punto de vista visual.  Maxlength: número máximo de caracteres que se pueden introducir en este campo.  Disabled: no tiene un valor, sino que su sola presencia significa que el campo está deshabilitado. Esta etiqueta no requiere su homónima de final. Ejemplo:   Introduzca su nombre:      El navegador mostraría algo así:

58

MÓDULO A – Unidad 3: El protocolo HTTP y el lenguaje HTML

Existe un caso particular de campo de texto, que es el utilizado para introducir información secreta (como por ejemplo una contraseña) donde no se quiere que se pueda leer la información tecleada. Se define igual que el campo de texto con la diferencia de que el atributo ‘type” debe tener el valor ‘password’. Ejemplo:   Introduzca su contraseña:     El navegador mostraría algo así:

3.3.3.2

Áreas de texto 

Un área de texto se define mediante la etiqueta TEXTAREA. Admite los siguientes atributos:  Name: el nombre del campo y por tanto, nombre del parámetro que viajará al servidor.  Cols: el número de columnas visible.  Rows: el número de filas visible.  Readonly: no tiene un valor, sino que su sola presencia significa que el campo es de solo lectura.  Disabled: no tiene un valor, sino que su sola presencia significa que el campo está deshabilitado. 59

Esta etiqueta si requiere su homónima de final. Y el contenido que queramos que aparezca por defecto en ella si así lo deseamos, debe ir entre ambas etiquetas. Ejemplo:   Introduzca sus comentarios: 
         El navegador mostraría algo así:

3.3.3.3

Checkboxes 

Una checkbox se define mediante la etiqueta INPUT y su atributo ‘type’ con el valor ‘checkbox’. Admite otros atributos como son:  Name: el nombre del campo y por tanto, nombre del parámetro que viajará al servidor.  Value: el valor del campo en caso de estar seleccionado.  Checked: no tiene un valor, sino que su sola presencia significa que la checkbox está seleccionada por defecto.  Disabled: no tiene un valor, sino que su sola presencia significa que el campo está deshabilitado. Esta etiqueta no requiere su homónima de final. Ejemplo:   Seleccione sus deportes favoritos: 
  Fútbol:  
  60

MÓDULO A – Unidad 3: El protocolo HTTP y el lenguaje HTML Baloncesto:  
  Petanca:     El navegador mostraría algo así:

3.3.3.4

Radiobuttons 

Un radiobutton se define mediante la etiqueta INPUT y su atributo ‘type’ con el valor ‘radio’. Admite otros atributos como son:  Name: el nombre del campo y por tanto, nombre del parámetro que viajará al servidor. Si varios radiobuttons comparten el mismo nombre, entonces forman un grupo donde solo uno de ellos puede estar seleccionado.  Value: el valor del campo en caso de estar seleccionado.  Checked: no tiene un valor, sino que su sola presencia significa que el radiobutton está seleccionada por defecto.  Disabled: no tiene un valor, sino que su sola presencia significa que el campo está deshabilitado. Esta etiqueta no requiere su homónima de final. Ejemplo:   Seleccione su sexo: 
   Hombre 
   Mujer 
  El navegador mostraría algo así:

61

3.3.3.5

Listas y Combos 

Tanto las listas como los combos se definen mediante la etiqueta SELECT. Admite los siguientes atributos:  Name: el nombre del campo y por tanto, nombre del parámetro que viajará al servidor.  Size: especifica el número de valores visible. Si solo es visible un valor, se mostrará como un Combo. Si son visibles dos o más, se mostrará como una lista.  Multiple: no tiene un valor, sino que su sola presencia significa que se pueden seleccionar más de un elemento a la vez.  Disabled: no tiene un valor, sino que su sola presencia significa que el campo está deshabilitado. Esta etiqueta si requiere su homónima de final. Y las distintas opciones que vayan a formar parte de la lista deberán ir definidas entre ambas mediante la etiqueta OPTION. La etiqueta OPTION admite los siguientes atributos:  Value: el valor del campo en caso de estar seleccionado.  Selected: no tiene un valor, sino que su sola presencia significa que esta opción está seleccionada por defecto. Esta etiqueta si requiere su homónima de final. Y el contenido que queramos que aparezca como opción debe ir entre ambas etiquetas. Ejemplo:   Seleccione el postre: 
      Fruta    Helado    Cuajada    Tarta      62

MÓDULO A – Unidad 3: El protocolo HTTP y el lenguaje HTML El navegador mostraría algo así:

3.3.3.6

Botones 

Un botón se define mediante la etiqueta INPUT. Y dependiendo del valor que tenga su atributo “type” será de un tipo u otro:  Button: se trata de un botón genérico que por sí solo no hace nada. Hay que acompañarlo de JavaScript, por ejemplo, para que realice alguna operativa.  Submit: se trata de un botón que al ser pulsado envía toda la información recogida en el formulario al recurso del servidor identificado en el atributo “action” del formulario mediante el método HTTP especificado en el atributo “method” del formulario.  Reset: se trata de un botón que al ser pulsado borra toda la información recogida en el formulario. Admite otros atributos como son:  Name: el nombre del botón, que puede ser útil cuando se programa con JavaScript en la página HTML.  Value: el texto que aparece escrito en el botón.  Disabled: no tiene un valor, sino que su sola presencia significa que el botón está deshabilitado. Esta etiqueta no requiere su homónima de final. Ejemplo:         El navegador mostraría algo así:

63

3.3.3.7

Campos ocultos 

Existen ocasiones, en las que nos interesará que como parte del formulario se envíe información no visible para el usuario pero necesaria para la lógica de nuestra aplicación. Dichos campos se definen mediante la etiqueta INPUT y su atributo ‘type’ con el valor ‘hidden’. Admite otros atributos como son:  Name: el nombre del campo y por tanto, nombre del parámetro que viajará al servidor.  Value: el valor del campo, no modificable por el usuario. Esta etiqueta no requiere su homónima de final. Ejemplo:       Evidentemente, en el navegador no se vería nada. Pues bien, esto es todo lo que hay que conocer de HTML para poder interactuar entre el usuario y la aplicación Java EE mediante un navegador web. Cualquier otra etiqueta HTML ya sería para dar formato a la página: tablas, cabeceras, imágenes, enlaces, frames, etc…

3.4

Ensamblado y despliegue

Las páginas HTML pueden desplegarse de distintas maneras. Por ejemplo, se pueden desplegar en un Servidor Web como Apache HTTP Server (http://httpd.apache.org/) o Internet Information Server (http://www.iis.net/) entre otros. Estos servidores, se limitan a servir webs estáticas basadas en páginas HTML y sus recursos: imágenes, hojas de estilo, etc... Pero como vimos en la primera unidad de este curso, también se pueden desplegar como parte de una aplicación Java EE (dentro de un módulo web) en un Servidor de Aplicaciones Java EE. 64

MÓDULO A – Unidad 3: El protocolo HTTP y el lenguaje HTML Esta segunda opción será la que estudiaremos y utilizaremos a lo largo del curso, pero a partir de la siguiente unidad. De momento, en las actividades de esta unidad, nos limitaremos a crear las páginas HTML en el sistema de archivos local y abrirlas con el navegador accediendo al disco duro (no escribiendo ninguna URL de un servidor). Por ejemplo, con Mozilla Firefox 10:

O con Internet Explorer 9:

65

66

PARA RECORDAR

 El modelo de referencia OSI representa los sistemas de comunicación desde un punto de vista teórico en 7 capas implementado en un sistema de comunicación real como es el TCP/IP.

 El protocolo HTTP es el encargado de la transferencia de los recursos, de las aplicaciones web, que componen la red. Estos recursos son identificados de forma unívoca mediante las URLs, que tienen el siguiente formato: Protocolo://Servidor:Puerto/Path/Recurso

 Las conversaciones HTTP, de petición – respuesta se componen de:  La petición contiene un método HTTP (GET y POST.), un recurso o URL y los parámetros o argumentos.  Una respuesta contiene un código de estado o resultado, tipo del contenido de la respuesta y el contenido como tal.

 Se han estudiado los métodos GET y POST para las solicitudes de recursos estáticos y dinámicos a un servidor de aplicaciones, su formato tanto en las peticiones como en las respuestas y la utilización de sniffers para poder depurar las solicitudes.

 HTML es el lenguaje mediante el cual definimos los contenidos que fluyen por Internet, conocidas como páginas HTML o páginas Web. Básicamente se trata de un lenguaje de etiquetado, que define la estructura y el contenido de un documento a ser compartido y accedido en Internet a través de un navegador web.  Una etiqueta es un elemento que define qué o como se debe presentar la información que viene a tras la etiqueta, dentro de una página web. 

Una página HTML, es un fichero de texto con extensión *.htm o *.html que contiene una información formateada mediante el lenguaje HTML. Está formada normalmente por una cabecera y un cuerpo .



Un formulario (FORM) es la presentación visual de entrada de datos en una página HTML para ser enviados a una aplicación servidora. Se han estudiado distintos elementos como INPUT, TEXTAREA …. 67

68

Unidad de Aprendizaje 4

JAVA SERVLETS

ÍNDICE 4.1

Introducción ................................................................... 71

4.2

Mi primer Java Servlet .................................................. 72

4.3

Java Servlets .................................................................. 84 4.3.1 El ciclo de vida de un Java Servlet ..............................84 4.3.2 Petición y respuesta de un Java Servlet .....................88 4.3.3 Procesamiento de un formulario HTML ......................93 4.3.4 Empaquetado y despliegue ..........................................97

RECORDAR............................................................................. 103

MÓDULO B – Unidad 4: Java Servlets

4.1

Introducción

Ya vimos en la primera unidad del curso, que los Java Servlets eran un tipo de componente Java EE que se empaquetaba en un módulo web (WAR) y se desplegaba y ejecutaba en el contenedor web de un Servidor de Aplicaciones Java EE. Adicionalmente, dentro del patrón de diseño MVC ocupaban el espacio del Controlador, como receptor/validador de peticiones, seleccionador de la lógica a ejecutar, y seleccionador de la vista a presentar como resultado.

No obstante, de momento, dado que es el primer componente que vamos a estudiar, va a cubrir completamente todas las responsabilidades del MVC. Y según vayamos avanzando en el curso, le iremos quitando responsabilidades que no debieran ser del Java Servlet, para dárselas a otro tipo de componente como la JavaServer Page (JSP).

Repetimos, esto es un mal diseño y una mala práctica de programación. Pero consideramos que es imprescindible ir aprendiendo poco a poco. Por tanto, este diseño es temporal mientras avanzamos en las sucesivas unidades del curso.

71

Por último, desde un punto de vista del lenguaje de programación Java, un Java Servlet no es más que una clase Java que implementa una determinada interface definida en las especificaciones.

4.2

Mi primer Java Servlet

Antes de entrar a estudiar en profundidad los Java Servlets, vamos a guiar los pasos para desarrollar nuestro primer Java Servlet con Eclipse IDE for Java EE Developers y desplegarlo en Apache Tomcat. Es requisito indispensable, haber seguido los pasos de instalación y configuración de ambas dos herramientas detallados en la unidad 2 de este curso. Estos mismos pasos nos servirán para los sucesivos ejemplos y actividades del resto del curso. Arrancamos Eclipse IDE for Java EE Developers y mediante el las opciones de menú “File” -> “New” -> “Dynamic Web Project”:

Creamos la estructura de desarrollo de un módulo web (WAR). Como nombre del proyecto, pondremos “HolaMundoWeb”, y nos aseguraremos que seleccionamos “Apache Tomcat v7.0” 72

MÓDULO B – Unidad 4: Java Servlets como entrono de ejecución y “3.0” como el nivel de especificaciones Java EE (en cuanto a contenedor web) que queremos utilizar. Pulsamos el botón “Next” dos veces:

En la última ventana del asistente, antes de pulsar el botón “Finish”, nos aseguramos de marcar la opción “Generate web.xml deployment descriptor”:

73

La estructura del proyecto creado debería ser algo así:

74

MÓDULO B – Unidad 4: Java Servlets

En el directorio /Java Resources/src es donde iremos colocando el código fuente de nuestras clases Java. En el directorio /WebContent es donde iremos colocando los recursos web, como por ejemplo, las páginas HTML, las JavaServer Pages (JSP), imágenes, etc… Y el fichero web.xml de /WebContent/WEB-INF es el descriptor de despliegue del módulo web (en nuestro caso, del proyecto HolaMundoWeb). Ahora crearemos un Java Servlet. Botón derecho sobre el nuevo proyecto -> “New” -> “Class”:

75

En la siguiente ventana, rellenamos el nombre del paquete Java (Package) con “es.aulamentor”, el nombre de la clase Java (Name) con “HolaMundoServlet” y la clase padre (Superclass) con “javax.servlet.http.HttpServlet”. Nota: No incluir las comillas en los nombres mencionados Y pulsamos el botón “Finish”:

76

MÓDULO B – Unidad 4: Java Servlets

Escribimos el siguiente código Java en la clase creada y salvamos: package es.aulamentor;    import java.io.IOException;  import java.io.PrintWriter;    import javax.servlet.ServletException;  import javax.servlet.http.HttpServlet;  import javax.servlet.http.HttpServletRequest;  import javax.servlet.http.HttpServletResponse;    public class HolaMundoServlet extends HttpServlet   {    protected void doGet(HttpServletRequest req, HttpServletResponse     resp) throws ServletException, IOException     {      resp.setContentType("text/html;charset=UTF‐8");      PrintWriter out = resp.getWriter();  77

    out.println("");      out.println("");      out.println("  ");      out.println("    ");      out.println("  ");      out.println("  ");      out.println("    Hola Mundo!");      out.println("  ");      out.println("");    }  }  No nos preocupemos en este momento por no entender el código. De momento, simplemente queremos mostrar los pasos para el desarrollo y despliegue de un Java Servlet. En los sucesivos apartados iremos entendiendo el por qué de cada línea. A continuación, editaremos el descriptor de despliegue del módulo web, el fichero web.xml de /WebContent/WEB-INF y añadiremos este código XML salvando al final el fichero:             HolaMundoServlet      es.aulamentor.HolaMundoServlet              HolaMundoServlet      /HolaMundoServlet        Ya solo queda, probar la aplicación. Para ello, pulsamos el botón derecho sobre la clase del Java Servlet -> “Run As” -> “Run on Server”:

78

MÓDULO B – Unidad 4: Java Servlets

En la siguiente ventana, seleccionar “Tomcat v7.0 Server at localhost” y pulsar el botón “Finish”:

79

En la vista de “Console” veremos las trazas que va dejando el Servidor de Aplicaciones Java EE al arrancar, cómo despliega la aplicación y automáticamente abre un navegador interno de Eclipse IDE con la URL: http://localhost:8080/HolaMundoWeb/HolaMundoServlet donde se ve el resultado de nuestro primer Java Servlet:

80

MÓDULO B – Unidad 4: Java Servlets

Perfectamente podríamos utilizar otro navegador web (tipo Mozilla Firefox o Internet Explorer) y escribir la misma URL. El comportamiento debería ser el mismo. Para abrir el navegador interno de Eclipse IDE a mano, utilizar el botón de la barra de herramientas:

Otra opción también válida habría sido utilizar el asistente de Java Servlets directamente en vez del asistente de una clase Java convencional, pero preferíamos que se viera un ejemplo “a mano”. Esta opción, habría sido con las opciones de menú “New” -> “Servlet”:

81

Este asistente, añade una anotación especial sobre la clase Java en el código fuente de manera que no es necesario añadir nada al descriptor de despliegue. Como ya comentamos en la primera unidad, esta era una novedad de la última versión de la especificación Java EE. En este curso, comentaremos ambas dos opciones. Ya solo nos queda desinstalar la aplicación mediante la opción “Add and Remove…”:

82

MÓDULO B – Unidad 4: Java Servlets

Y apagar el servidor mediante la opción “Stop”:

83

4.3

Java Servlets

Todas las clases Java relacionadas con los Java Servlets, están en los paquetes:

Los



javax.servet



javax.servlet.http Java

Servlets

fueron

concebidos

para

ser

independientes

del

protocolo

de

comunicaciones. Pero la realidad ha sido, que el 99% de su uso está relacionado con el protocolo HTTP (redes Internet e Intranets). De ahí, que existan clases en el API que nos ayudan a gestionar las peculiaridades de dicho protocolo en el segundo paquete mencionado: javax.servlet.http 4.3.1 El ciclo de vida de un Java Servlet Un Java Servlet tiene definido un ciclo de vida, forzado por la interface javax.servlet.Servlet, por tanto, siempre que queramos implementar un Java Servlet, nuestra clase deberá

84

MÓDULO B – Unidad 4: Java Servlets implementar dicho interface. Es una especie de contrato entre el Java Servlet y el contenedor web del Servidor de Aplicaciones Java EE para poder funcionar. Dicho ciclo de vida tiene los siguientes estados:  Cuando se recibe una petición de la ejecución de un Java Servlet en el Servidor de Aplicaciones Java EE y este no ha sido invocado nunca, el contenedor web instancia la clase del Java Servlet (llama a su constructor) y acto seguido invoca el método: public void init(ServletConfig config); Dicho método, solo se ejecuta una vez en la vida del Java Servlet y se suele utilizar para llevar a cabo todas las labores de inicialización que necesitemos para su posterior ejecución. Como se puede observar, recibe como parámetro una instancia de la clase ServletConfig, que representa información de configuración que el administrador del Servidor de Aplicaciones Java EE haya podido añadir. Veremos este método en más detalle en los siguientes apartados.  Una vez está ya inicializado, entonces invoca el método: public void service(ServletRequest request, ServletResponse response); Dicho método se ejecuta cada vez que se recibe una petición para este java Servlet. En su implementación, colocaremos la lógica para la que se creó dicho Java Servlet. Como se puede observar, recibe como parámetros un par de instancias de las clases ServletRequest y ServletResponse. Ambos dos parámetros representan la petición (la usaremos para entender qué nos están pidiendo) y la respuesta (la utilizaremos para devolver el resultado de la ejecución del java Servlet al peticionario).  Si por alguna razón el contenedor web necesita eliminar al Java Servlet (se detiene el Servidor de Aplicaciones Java EE, se queda sin recursos de memoria y necesita liberar espacio, etc…), entonces invoca el método: public void destroy(); Dicho método solo se ejecuta una vez en la vida del java Servlet y se suele utilizar para liberar todos aquellos recursos que pudiéramos estar utilizando, para dejar el sistema lo mas limpio posible. Lo que ocurre, es que el API ya tiene una serie de clases que no solo implementan por defecto el ciclo completo de vida de un Java Servlet, sino que como decíamos, también nos ayuda con los temas relacionados con el protocolo HTTP. Así, tenemos la clase javax.servlet.http.HttpServlet que además de implementar los métodos comentados anteriormente (es decir, implementar el interface javax.servlet.Servlet), añade otros más potentes que nos dan valor añadido al trabajar con el protocolo HTTP.

85

Por ejemplo, si recordamos de la unidad anterior donde hablábamos del protocolo HTTP, comentábamos que existían distintos métodos utilizables en la petición: GET, POST, PUT, etc… Pues esta clase, implementa un método Java por cada método HTTP existente, de forma, qué él ya se encarga de recibir la petición HTTP, examinarla, e invocar el método Java correspondiente al método HTTP utilizado, así como darnos acceso a un par de objetos que representan tanto la petición como la respuesta HTTP. Los más habituales que utilizaremos nosotros son: 

protected void doGet(HttpServletRequest request, HttpServletResponse response);



protected void doPost(HttpServletRequest request, HttpServletResponse response);

Dichos métodos normalmente los sobrescribiremos en nuestro Java Servlet para incluir nuestra lógica particular. Veamos un ejemplo de un Java Servlet que simplemente muestra por la consola del Servidor de Aplicaciones Java EE trazas del ciclo de vida: package es.aulamentor;    import java.io.IOException;  import javax.servlet.ServletConfig;  import javax.servlet.ServletException;  import javax.servlet.http.HttpServlet;  import javax.servlet.http.HttpServletRequest;  import javax.servlet.http.HttpServletResponse;    public class CicloDeVidaServlet extends HttpServlet   {    public CicloDeVidaServlet()     {      super();      System.out.println("CicloDeVidaServlet()");    }      public void init(ServletConfig config) throws ServletException     {      System.out.println("init()");    }      public void destroy()     {      System.out.println("destroy()");    }      protected void doGet(HttpServletRequest request, HttpServletResponse     response) throws ServletException,IOException     {      System.out.println("doGet()");    }  }  El editor de despliegue tendría algo así:

86

MÓDULO B – Unidad 4: Java Servlets             CicloDeVidaServlet      es.aulamentor.CicloDeVidaServlet              CicloDeVidaServlet      /CicloDeVidaServlet        Al invocar varias veces a este Java Servlet desde un navegador, y después parar el Servidor de Aplicaciones Java EE, deberíamos ver algo así:

Como podemos ver, en la consola salen en negro las trazas que dejamos desde nuestro código: primero el constructor, seguido del init(), seguido de tres doGet() porque ese fue el 87

número de veces que invocamos seguidas el Java Servlet, y por último, al apagar el Servidor de Aplicaciones Java EE el destroy(). En el navegador, evidentemente no se ve nada, puesto que no devolvimos ningún resultado en el código del Java Servlet.

4.3.2 Petición y respuesta de un Java Servlet La invocación de un Java Servlet independientemente del método HTTP que se utilice, siempre

recibe

dos

parámetros:

javax.servlet.http.HttpServletRequest

y

javax.servlet.http.HttpServletResponse. javax.servlet.http.HttpServletRequest, es un interfaz que define cómo interactuar con la información que viene en una petición HTTP, como por ejemplo, las cabeceras HTTP de la petición, los parámetros de la petición, etc… Algunos métodos son:  java.util.Enumeration getParameterNames(): devuelve una colección con los nombres de todos los parámetros enviados en la petición.  java.lang.String getParameter(java.lang.String name): devuelve el valor de un parámetro concreto enviado en la petición.  java.lang.String[] getParameterValues(java.lang.String name): devuelve todos los valores de un parámetro concreto enviado en la petición (imaginemos un conjunto de checkboxes con el mismo nombre de un formulario).  java.util.Enumeration getAttributeNames(): devuelve una colección con los nombres de todos los atributos de la petición.  java.lang.Object getAttribute(java.lang.String name): devuelve el valor de un atributo concreto de la petición.  java.util.Enumeration getHeaderNames(): devuelve una colección con los nombres de todas las cabeceras HTTP enviadas en la petición.  java.lang.String getHeader(java.lang.String name): devuelve el valor de una cabecera HTTP concreta de la petición.  java.lang.String getContextPath(): devuelve la porción de URL de la petición que corresponde al ContextPath. El ContextPath es el identificador que utiliza el Servidor de aplicaciones Java EE para diferenciar una aplicación u otra. Siempre va en la URL por delante del recurso pedido como tal. Existen muchos métodos más, algunos muy importantes para el manejo de la Sesión HTTP y de las Cookies (los veremos en la siguiente unidad), para redireccionar la petición a otro java Servlet o JavaServer Page (también los veremos en una unidad posterior) y otros 88

MÓDULO B – Unidad 4: Java Servlets muchos para acceder a más información disponible en una petición HTTP que podemos ver en el siguiente ejemplo: package es.aulamentor;    import java.io.IOException;  import java.util.Enumeration;    import javax.servlet.ServletException;  import javax.servlet.http.HttpServlet;  import javax.servlet.http.HttpServletRequest;  import javax.servlet.http.HttpServletResponse;    public class RequestServlet extends HttpServlet   {    protected void doGet(HttpServletRequest request, HttpServletResponse     response) throws ServletException, IOException     {      System.out.println("ContextPath: " + request.getContextPath());      System.out.println("LocalAddr: " + request.getLocalAddr());      System.out.println("LocalName: " + request.getLocalName());      System.out.println("LocalPort: " + request.getLocalPort());      System.out.println("Method: " + request.getMethod());      System.out.println("Protocol: " + request.getProtocol());      System.out.println("QueryString :" + request.getQueryString());      System.out.println("RemoteAddr :" + request.getRemoteAddr());      System.out.println("RemoteHost :" + request.getRemoteHost());      System.out.println("RemotePort :" + request.getRemotePort());      System.out.println();      Enumeration headers = request.getHeaderNames();      while(headers.hasMoreElements())      {        String header = headers.nextElement();        System.out.println(header + ": " + request.getHeader(header));      }      System.out.println();      Enumeration parameters = request.getParameterNames();      while(parameters.hasMoreElements())      {        String parameter = parameters.nextElement();        System.out.println(parameter + ": " +         request.getParameter(parameter));      }    }  }  Y el descriptor de despliegue:             RequestServlet      es.aulamentor.RequestServlet          89

    RequestServlet      /RequestServlet        Si en el navegador utilizamos la siguiente URL para invocar el Java Servlet: http://localhost:8080/EjemplosWeb/RequestServlet?param1=valor1¶m2=valor2 Nota: Fijaros, que hemos añadido dos parámetros en la URL. En la consola del Servidor de Aplicaciones Java EE deberíamos ver algo como esto (en cada caso dependerá un poco del entorno utilizado):

En el API Java EE, están detallados todos los métodos: http://docs.oracle.com/javaee/6/api/javax/servlet/http/HttpServletRequest.html javax.servlet.http.HttpServletResponse, es un interfaz que define cómo trabajar y generar la respuesta HTTP desde el Java Servlet, como por ejemplo, acceder al stream de escritura, especificar el tipo y longitud del contenido, etc… Algunos métodos son:  java.io.PrintWriter getWriter() throws java.io.IOException: nos devuelve una referencia al objeto de escritura en modo carácter de la respuesta, a través del cual escribiremos.  ServletOutputStream getOutputStream() throws java.io.IOException: nos devuelve una referencia al objeto de escritura en modo byte de la respuesta, a través del cual escribiremos. La diferencia con el anterior es el modo de escritura: carácter o byte. 90

MÓDULO B – Unidad 4: Java Servlets  void setContentType(java.lang.String type): nos sirve para especificar el tipo de contenido que vamos a enviar en la respuesta. Por ejemplo: text/html, text/plain, image/gif, etc… Los distintos tipos de contenido están estandarizados a través de las especificaciones MIME (Multipurpose Internet Mail Extensions). En la siguiente URL están documentados todos los posibles tipos: http://www.iana.org/assignments/media-types/index.html Recordemos de la tercera unidad de este manual, cuando hablábamos del protocolo HTTP, que esta era una información que viajaba en la cabecera de una respuesta HTTP. Los siguientes métodos, también sirven para añadir información específica de una respuesta HTTP.  void setContentLength(int len): nos sirve para especificar la longitud del cuerpo de la respuesta  void setStatus(int sc): nos sirve para devolver un código de estado HTTP.  void sendError(int sc, java.lang.String msg) throws java.io.IOException: nos sirve para devolver un código de error HTTP junto con un mensaje descriptivo. Existen muchos métodos más, algunos muy importantes para el manejo de las Cookies (los veremos en la siguiente unidad). Veamos un ejemplo: package es.aulamentor;    import java.io.File;  import java.io.FileInputStream;  import java.io.FileNotFoundException;  import java.io.IOException;  import java.io.OutputStream;    import javax.servlet.ServletConfig;  import javax.servlet.ServletException;  import javax.servlet.http.HttpServlet;  import javax.servlet.http.HttpServletRequest;  import javax.servlet.http.HttpServletResponse;    public class ResponseServlet extends HttpServlet   {    private byte[] buffer = new byte[0];      public void init(ServletConfig config) throws ServletException    {      try       {        File file = new File("C:\\images\\duke.gif");        FileInputStream in = new FileInputStream(file);        buffer = new byte[(int)file.length()];        in.read(buffer);        in.close();      }      catch(FileNotFoundException ex)   91

    {        ex.printStackTrace();      }      catch(IOException ex)       {        ex.printStackTrace();      }    }      protected void doGet(HttpServletRequest request, HttpServletResponse     response) throws ServletException, IOException     {      response.setContentType("image/gif");      response.setContentLength(buffer.length);      response.getOutputStream().write(buffer);      response.setStatus(200);    }  }  Y el descriptor de despliegue:             ResponseServlet      es.aulamentor. ResponseServlet              ResponseServlet      /ResponseServlet        Si en el navegador utilizamos la siguiente URL para invocar el Java Servlet: http://localhost:8080/EjemplosWeb/ResponseServlet En el navegador deberíamos ver la imagen que hemos utilizado en el ejemplo

En el API Java EE, están detallados todos los métodos: 92

MÓDULO B – Unidad 4: Java Servlets http://docs.oracle.com/javaee/6/api/javax/servlet/http/HttpServletResponse.html

4.3.3 Procesamiento de un formulario HTML Hasta ahora, todos los ejemplos no han tenido interacción real con el usuario. Vamos a ver cómo sería un Java Servlet que procese una información recogida a través de un formulario HTML. Por ejemplo, una calculadora muy sencilla que simplemente sume dos números. Tendremos la siguiente página HTML:             <META http‐equiv="Content‐Type" content="text/html; charset=ISO‐ 8859‐1">                                              Primer número:                            Segundo número:                                                    Y el siguiente Java Servlet: package es.aulamentor;    import java.io.IOException;  import java.io.PrintWriter;    import javax.servlet.ServletException;  import javax.servlet.http.HttpServlet;  import javax.servlet.http.HttpServletRequest;  import javax.servlet.http.HttpServletResponse;    public class SumadorServlet extends HttpServlet   {    protected void doGet(HttpServletRequest request, HttpServletResponse     response) throws ServletException, IOException     {      procesarPeticion(request, response);    }  93

    protected void doPost(HttpServletRequest request, HttpServletResponse     response) throws ServletException, IOException     {      procesarPeticion(request, response);    }        private void procesarPeticion(HttpServletRequest request,     HttpServletResponse response) throws ServletException, IOException    {      response.setContentType("text/html;charset=UTF‐8");            try      {        int param1 = Integer.parseInt(request.getParameter("param1"));     int param2 = Integer.parseInt(request.getParameter("param2"));     int result = param1 + param2;           response.setStatus(200);     PrintWriter out = response.getWriter();     out.println("");     out.println("");     out.println("");     out.println("  ");     out.println("    ");     out.println("  ");     out.println("  ");     out.println("    El resultado de la suma es: " + result);     out.println("    

");     out.println("    Volver         atrás...");     out.println("  ");     out.println("");      }      catch(NumberFormatException ex)      {     response.sendError(500, "Alguno de los números no contenía dígitos         válidos...");      }    }  }  Nota: Recordar que los contenidos estáticos como una página HTML se ubican dentro del directorio /WebContent. Al cargar la página en el navegador, deberíamos ver algo así:

94

MÓDULO B – Unidad 4: Java Servlets

Al introducir los números 2 y 8 y pulsar el botón de Sumar, desde el navegador se lanzará una petición HTTP al Servidor de Aplicaciones Java EE pidiendo la ejecución del Java Servlet (que está en el mismo servidor que el HTML) con dichos parámetros y en el navegador, deberíamos ver algo así:

En caso de que no hubiéramos introducido algún parámetro, o alguno de ellos llevase algún carácter que no fuese un dígito, deberíamos ver una página de error parecida a esta:

95

En la siguiente unidad, hablaremos un poco mas del tratamiento de errores. En este ejemplo, hemos optado por mostrar una página de error HTTP, pero podríamos perfectamente haber contestado una página HTML al estilo de la que mostraba el resultado correcto, indicando los motivos del error. Aprovechando este ejemplo, vamos a comentar otro tema interesante. En la unidad donde tratamos el protocolo HTTP, comentamos que la diferencia entre los métodos HTTP GET y POST era que uno enviaba los parámetros en la URL (GET) y otro en el cuerpo del mensaje HTTP (POST). En este ejemplo, hemos utilizado el método POST, pero fijaros lo que veríamos en la URL del navegador si en vez de POST hubiéramos utilizado GET: http://localhost:8080/EjemplosWeb/SumadorServlet?param1=2¶m2=8

Por eso comentábamos, que lo habitual cuando se utilizan formularios es emplear el método POST para evitar mostrar al usuario URLs farragosas, además de que por temas de seguridad, se intente evitar que se lea en claro una contraseña (por ejemplo).

96

MÓDULO B – Unidad 4: Java Servlets 4.3.4 Empaquetado y despliegue Como comentábamos en la primera unidad de este curso de introducción al Java EE, una aplicación Java EE está formada por un empaquetamiento de una o varias unidades conocidas con el nombre de módulos. Este empaquetamiento final era un EAR (Enterprise ARchive). Uno de los distintos tipos de módulos mencionados son los módulos Web, que contienen normalmente Java Servlets, JavaServer Pages (JSP), JavaServer Faces (JSF), contenidos estáticos como imágenes, HTMLs, CSSs… Su extensión del fichero empaquetado es WAR (Web ARchive). En este curso, nos vamos a centrar exclusivamente de este tipo de módulos, ya que intentamos cubrir solo la parte web de la programación Java EE y no el resto de aspectos que darían lugar a un curso demasiado extenso o a un segundo curso. A pesar de que las aplicaciones Java EE se empaquetan en un EAR, los Servidores de Aplicación que solo cubren parte de la especificación Java EE, como ocurre con Apache Tomcat, permiten desplegar simplemente módulos Web aislados. Este será nuestro caso durante este curso. Gráficamente, la estructura de un módulo Web empaquetado sería la siguiente:

Como podemos observar, tiene bastante parecido a la estructura del proyecto web dentro de Eclipse IDE for Java EE Developers aunque no es igual. En principio, el raíz del fichero

97

WAR correspondería al directorio /WebContent y el directorio /classes del fichero WAR correspondería al directorio /build/classes. Ahora bien, normalmente no nos preocuparemos mucho de la generación de un módulo Web u otro tipo de módulo, porque son los IDEs los que nos van a ayudar a generarlo. Por ejemplo, en nuestro caso, con Eclipse IDE for Java EE Developers basta con seleccionar el proyecto, pulsar el botón derecho del ratón y seleccionar las opciones “Export” -> “WAR file”:

98

MÓDULO B – Unidad 4: Java Servlets En la siguiente ventana, nos aseguramos que el proyecto seleccionado es el correcto, y decidimos donde y con que nombre se va a generar el fichero WAR, por ejemplo, “C:\EjemplosWeb.war”. Pulsar el botón “Finish”:

Si vamos a una sesión de DOS, mediante el comando de la JDK jar.exe (jar tvf nombreFichero.war), podemos ver su contenido y confirmar que la estructura generada es exactamente la de la especificación Java EE:

99

Este fichero WAR, sería el que un administrador de Servidores de Aplicación Java EE desplegaría y configuraría para que la aplicación estuviese disponible y dando servicio. Pero en nuestro caso, simplemente añadiremos o quitaremos aplicaciones en el Apache Tomcat de Eclipse IDE for Java EE Developers mediante el interfaz de usuario: botón derecho del ratón y la opción “Add and Remove…”, o directamente sobre el componente y “Run As” -> “Run on Server”. Nos queda no obstante hablar un poco sobre el descriptor de despliegue. Como ya adelantábamos en la primera unidad, se trata de un fichero XML donde se describe el contenido y posible comportamiento del contenido del módulo. En el caso concreto de los módulos Web, su descriptor de despliegue es el fichero web.xml A lo largo de esta unidad, hemos visto en los ejemplos algunas etiquetas, pero ahora hablaremos un poco más despacio de algunas de ellas:             SumadorServlet      es.aulamentor.SumadorServlet              SumadorServlet      /SumadorServlet        La primera línea es obligatoria, y simplemente indica que el fichero es XML 1.0 Después, viene el bloque “web-app” que es el que delimita el contenido del descriptor de despliegue del módulo Web. En la etiqueta de inicio, se añaden una serie de atributos entre los cuales está la ubicación del esquema XML que contiene la especificación utilizada: http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd Los bloques “servlet” y “servlet-mapping” son más interesantes. Sirven para registrar los Java Servlets que hay en el módulo Web, y especificar la URL para cada uno de ellos. Por ejemplo, en el descriptor de despliegue que hemos usado, decimos que hay un Java Servlet que

llamamos

SumadorServlet

que

está

implementado

en

la

clase

Java

es.aulamentor.SumadorServlet y que su URL es /SumadorServlet. Si no tuviéramos esos dos bloques en el descriptor de despliegue, el Servidor de Aplicaciones Java EE nos devolvería un error HTTP 404 que significaba que el recurso solicitado no existe. Veamos el error visualmente:

100

MÓDULO B – Unidad 4: Java Servlets

Aunque el Java Servlet vaya en el módulo Web, si no está especificado en el descriptor de despliegue, el Servidor de Aplicaciones Java EE no lo sabe identificar. Existen muchas más etiquetas a utilizar en un descriptor de despliegue de un módulo Web, pero las iremos viendo a lo largo del curso según las vayamos necesitando. De momento nos quedamos con la general “web-app” y las necesarias para registrar e identificar un Java Servlet. No obstante, muchos recordaréis que en la primera unidad comentábamos que con la última especificación Java EE, había aparecido la opción de obviar los descriptores de despliegue a cambio de anotar el código fuente con unas anotaciones especiales. Esta es otra opción, en cuyo caso no hace falta ni tener físicamente el fichero web.xml Una anotación se identifica precediéndola del carácter @ (arroba) y acompaña a la definición de una clase, de un atributo o de un método Java. Al igual que ocurre con las etiquetas del descriptor de despliegue, hay muchas anotaciones, pero las iremos viendo poco a poco a lo largo del curso. De momento, para sustituir a los bloques “servlet” y “servlet-mapping” que como hemos visto registran y definen un Java Servlet, existe la anotación: @WebServlet Que puede añadir atributos entre paréntesis para complementar si definición. En nuestro caso, el código fuente Java de nuestro Java Servlet sería algo así: ....  import javax.servlet.annotation.WebServlet;  ....  @WebServlet(name="SumadorServlet", urlPatterns={"/SumadorServlet"})  public class SumadorServlet extends HttpServlet   {  ....  }  Mediante la anotación, al desplegar el módulo Web en el Servidor de Aplicaciones Java EE, estamos registrando un Java Servlet que se llama SumadorServlet, cuya URL es /SumadorServlet. 101

Todos los posibles atributos de la anotación @WebServlet están en el API: http://docs.oracle.com/javaee/6/api/javax/servlet/annotation/WebServlet.html Si nuestro Java Servlet está desarrollado haciendo uso de la anotación, entonces no hace falta que lo registremos en el descriptor de despliegue. Incluso, si el descriptor de despliegue solo llevaba esa información, podemos prescindir de él. Ambas dos opciones pueden convivir en un mismo módulo Web, es decir, podemos describir algunas cosas en el descriptor de despliegue, y otras mediante anotaciones, aunque normalmente no es una buena práctica el mezclar las dos opciones. Normalmente se utiliza una u otra. ¿Y cuál es mejor utilizar? Pues depende. Normalmente los desarrolladores prefieren las anotaciones porque les es más rápido el desarrollo, pero los administradores de sistemas prefieren los descriptores de despliegue porque les permite entender el contenido de un módulo web sin necesidad de saber interpretar código fuente (código fuente que en ocasiones no tienen a su disposición debido a que solo reciben los bytecodes de las clases Java). A lo largo del curso, iremos explicando siempre ambas dos opciones.

102

RECORDAR

 Los Java Servlets son un tipo de componente Java EE que se empaquetan en un módulo web (WAR) y se despliegan y ejecutan en el contenedor web de un Servidor de Aplicaciones Java EE.

 Adicionalmente, dentro del patrón de diseño MVC ocupan el espacio del Controlador, como receptor/validador de peticiones, seleccionador de la lógica a ejecutar, y seleccionador de la vista a presentar como resultado

 Los Java Servlets siempre deben de implementar la interface javax.servlet.Servlet o heredar de la clase javax.servlet.http.HttpServlet.

 El ciclo de vida viene determinado por los siguientes métodos  init: se ejecuta una vez en la vida del Java Servlet y se suele utilizar para llevar a cabo todas las labores de inicialización que necesitemos para su posterior ejecución.  service: se ejecuta cada vez que se recibe una petición para el Java Servlet. En su implementación, se coloca la lógica para la que se creó. Si se ha heredado de la clase javax.servlet.http.HttpServlet, se utilizan los métodos doGet o doPost. 

destroy: se ejecuta una vez en la vida del Java Servlet y se suele utilizar para liberar todos aquellos recursos que pudiéramos haber utilizado, con el afán de dejar el sistema lo más limpio posible.

 Los

objetos

de

los

tipos

javax.servlet.http.HttpServletRequest

y

javax.servlet.http.HttpServletResponse. que reciben los métodos doGet y doPost, se utilizan para identificar la petición realizada y la respuesta dada. Contienen métodos para obtener de la petición parámetros, atributos, cabeceras … poner en la respuesta la respuesta en si misma, su longitud, el estado de la petición …

103

 Hemos aprendido que la principal diferencia entre las peticiones GET y POST es que en las primeras el paso de parámetros es apreciable en la URL. Para poder utilizar el POST, se utilizan los formularios (FORM) de HTML.

 Para poder desplegar una aplicación web, se puede realizar mediante un EAR o un WAR (dependiendo del servidor de aplicaciones). El descriptor de despliegue web.xml, aunque no es obligatorio si se utilizan anotaciones, conviene que exista para poder determinar de una manera sencilla que es lo que se va a desplegar y el comportamiento asociado.

104

Unidad de Aprendizaje 5

JAVASERVER PAGES

ÍNDICE 5.1

Introducción ................................................................. 107

5.2

Mi primer JavaServer Page ........................................ 108

5.3

JavaServer Pages ........................................................ 118 5.3.1 Etiqueta de comentario................................................119 5.3.2 Etiqueta de directiva.....................................................119 5.3.3 Etiqueta de declaración ...............................................120 5.3.4 Etiqueta de scriptlets ...................................................121 5.3.5 Etiqueta de expresión ..................................................122 5.3.6 Ejemplo con todas las etiquetas ................................123

5.4

Otros conceptos .......................................................... 127 5.4.1 El ciclo de vida de un JavaServer Page ....................127 5.4.2 Objetos implícitos de un JavaServer Page...............128 5.4.3 Empaquetado y despliegue ........................................129

PARA RECORDAR.................................................................. 134

MÓDULO B – Unidad 5: JavaServer Pages

5.1

Introducción

Ya vimos en la primera unidad del curso, que los JavaServer Pages, también conocidos por su acrónimo JSP, eran un tipo de componente Java EE que se empaquetaba en un módulo web (WAR) y se desplegaba y ejecutaba en el contenedor web de un Servidor de Aplicaciones Java EE. Adicionalmente, dentro del patrón de diseño MVC ocupaban el espacio de la Vista, como encargado de mostrar el resultado de la petición al usuario final. Es decir, al contrario que los Java Servlets, estas están enfocadas a la presentación.

No obstante, de momento, va a cubrir completamente todas las responsabilidades del MVC. Y según vayamos avanzando en el curso, le iremos quitando responsabilidades que no debieran ser del JavaServer Page, para dárselas a otro tipo de componente como los Java Servlets.

Repetimos, esto es un mal diseño y una mala práctica de programación. Pero consideramos que es imprescindible ir aprendiendo poco a poco. Por tanto, este diseño es temporal mientras avanzamos en las sucesivas unidades del curso.

107

Por último, desde un punto de vista del lenguaje de programación Java, una JavaServer Page no es más que un fichero con un lenguaje de etiquetado como HTML y trozos de código Java embebidos.

5.2

Mi primer JavaServer Page

Antes de entrar a estudiar en profundidad los JavaServer Pages, vamos a guiar los pasos para desarrollar nuestro primer JavaServer Page con Eclipse IDE for Java EE Developers y desplegarlo en Apache Tomcat. Es requisito indispensable, haber seguido los pasos de instalación y configuración de ambas dos herramientas detallados en la unidad 2 de este curso. Estos mismos pasos nos servirán para los sucesivos ejemplos y actividades del resto del curso. Arrancamos Eclipse IDE for Java EE Developers y mediante el las opciones de menú “File” -> “New” -> “Dynamic Web Project”:

108

MÓDULO B – Unidad 5: JavaServer Pages Creamos la estructura de desarrollo de un módulo web (WAR). Como nombre del proyecto, pondremos “HolaMundoWeb”, y nos aseguraremos que seleccionamos “Apache Tomcat v7.0” como entrono de ejecución y “3.0” como el nivel de especificaciones Java EE (en cuanto a contenedor web) que queremos utilizar. Pulsamos el botón “Next” dos veces:

En la última ventana del asistente, antes de pulsar el botón “Finish”, nos aseguramos de marcar la opción “Generate web.xml deployment descriptor”:

109

La estructura del proyecto creado debería ser algo así:

110

MÓDULO B – Unidad 5: JavaServer Pages

En el directorio /Java Resources/src es donde iremos colocando el código fuente de nuestras clases Java. En el directorio /WebContent es donde iremos colocando los recursos web, como por ejemplo, las páginas HTML, las JavaServer Pages, imágenes, etc… Y el fichero web.xml de /WebContent/WEB-INF es el descriptor de despliegue del módulo web (en nuestro caso, del proyecto HolaMundoWeb). Ahora crearemos un JavaServer Page. Botón derecho sobre el nuevo proyecto -> “New” -> “JSP File”:

111

En la siguiente ventana, rellenamos el nombre del fichero (File name) con “HolaMundo.jsp”. Nos aseguraremos de que el directorio donde se va a crear sea /WebContent (normalmente se selecciona por defecto). Y pulsamos el botón “Finish”:

112

MÓDULO B – Unidad 5: JavaServer Pages

Escribimos el siguiente código y salvamos: <%@ page language="java" contentType="text/html; charset=ISO‐8859‐1"  pageEncoding="ISO‐8859‐1"%>              <META http‐equiv="Content‐Type" content="text/html; charset=ISO‐      8859‐1">                    Hola Mundo!        No nos preocupemos en este momento por no entender el código. De momento, simplemente queremos mostrar los pasos para el desarrollo y despliegue de un JavaServer Page. En los sucesivos apartados iremos entendiendo el por qué de cada línea. 113

Ya solo queda, probar la aplicación. Para ello, pulsamos el botón derecho sobre el fichero JSP -> “Run As” -> “Run on Server”:

En la siguiente ventana, seleccionar “Tomcat v7.0 Server at localhost” y pulsar el botón “Finish”:

114

MÓDULO B – Unidad 5: JavaServer Pages

En la vista de “Console” veremos las trazas que va dejando el Servidor de Aplicaciones Java EE al arrancar, cómo despliega la aplicación y automáticamente abre un navegador interno de Eclipse IDE con la URL: http://localhost:8080/HolaMundoWeb/HolaMundo.jsp donde se ve el resultado de nuestro primer JavaServer Page:

115

Perfectamente podríamos utilizar otro navegador web (tipo Mozilla Firefox o Internet Explorer) y escribir la misma URL. El comportamiento debería ser el mismo. Para abrir el navegador interno de Eclipse IDE a mano, utilizar el botón de la barra de herramientas:

Ya solo nos queda desinstalar la aplicación mediante la opción “Add and Remove…”:

116

MÓDULO B – Unidad 5: JavaServer Pages

Y apagar el servidor mediante la opción “Stop”:

117

5.3

JavaServer Pages

Una JavaServer Page, es un fichero de extensión *.jsp que utiliza principalmente lenguajes de etiquetado como el HTML (estudiado en la unidad 3) u otros menos extendidos como WML, SVG, cHTML, etc, en el que se pueden embeber mediante unas etiquetas especiales, código Java. Es decir, vendrían a ser como el opuesto de los Java Servlets. Si aquellos eran código Java con código de etiquetado embebido en las sentencias de escritura, estas son código de etiquetado con código Java embebido. A la hora de su ejecución, el Servidor Java EE convertirá estos ficheros en un Java Servlet como los estudiados en la unidad anterior. Es decir, generará de forma automática, un Java Servlet en el que incluirá todos los fragmentos de Java embebidos, y añadirá sentencias de impresión con el lenguaje de etiquetado de presentación estático. Aunque como decimos, este proceso ocurre a sin conocimiento directo del desarrollador y lo realiza automáticamente el Servidor de Aplicaciones Java EE, siempre va bien tenerlo en 118

MÓDULO B – Unidad 5: JavaServer Pages cuenta para entender correctamente el significado de las etiquetas específicas de las JavaServer Pages. Existen unas cuantas etiquetas específicas de las JavaServer Pages, que nada tienen que ver con el lenguaje de etiquetado que se esté utilizando para la presentación, y son las que estudiaremos a continuación como parte de la sintaxis.

5.3.1 Etiqueta de comentario Los comentarios en una JavaServer Page se añaden delimitados por las siguientes dos etiquetas de inicio y fin: <%-- Comentario --%> Dichos comentarios, no se envían como parte de la respuesta desde el Servidor Java EE. Es decir, no es información que viaje por la red y por tanto no afectan al volumen de información transferido. Veamos un ejemplo: <%@ page language="java" contentType="text/html; charset=ISO‐8859‐1"  pageEncoding="ISO‐8859‐1"%>              <META http‐equiv="Content‐Type" content="text/html; charset=ISO‐      8859‐1">                    <%‐‐ Mi primera página JSP ‐‐%>      Hola Mundo!        Al ejecutar el ejemplo, en el navegador no veréis nada distinto. Y si al navegador se le pide ver el código fuente de la página HTML que ha cargado, tampoco veréis ninguna de las etiquetas relacionadas con las JavaServer Pages.

5.3.2 Etiqueta de directiva Las etiquetas de directiva siguen la siguiente sintaxis: <%@ directiva [atributo=”valor”] %> Existen tres tipos de directivas. De hecho, en los ejemplos anteriores ya hemos utilizado una de ellas: page, como primera línea de la JavaServer Page. Los tres tipos son:

119

 page: añade información técnica a la página utilizada por el Servidor de Aplicaciones Java EE para su posterior conversión a un Java Servlet. Puede utilizar múltiples atributos, pero los más extendidos e importantes son: o contentType: para identificar el contenido. o pageEncoding: para identificar el juego de caracteres utilizado. o import: fundamental para poder importar las clases Java utilizadas en los trozos de código java embebido y poder compilar correctamente. o Otras como errorPage, isThreadSafe o session, que veremos en siguientes unidades. Veamos un ejemplo: <%@ page contentType="text/html; charset=ISO‐8859‐1"  pageEncoding="ISO‐8859‐1" %>  <%@ page import="java.util.Date, es.aulamentor.*" %>   include: se utiliza para incluir en ese punto el resultado de la ejecución de otra JavaServer Page. Dichas JavaServer Pages suelen ser fragmentos de una presentación, por ejemplo, una cabecera, un mensaje de copyright, etc. Es muy útil para reutilizar código y no tener que escribirlo n veces, además de facilitar su posterior mantenimiento. Utiliza un único atributo que es “file”, para identificar la JavaServer Page a incluir. Veamos un ejemplo: <%@ include file="cabecera.jsp” %>   taglib: se utiliza para definir una librería de etiquetas (tags) propia que se va a utilizar en la JavaServer Page. La estudiaremos en siguientes unidades. No obstante, veamos un ejemplo: <%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>    5.3.3 Etiqueta de declaración En una JavaServer Page, es posible definir atributos y métodos, como si de una clase Java se tratase, que serán accesibles desde toda la JavaServer Page. Dichas declaraciones se realizan mediante las etiquetas: <%! … %> Por ejemplo, si queremos definir un atributo de tipo java.lang.String con el valor “Hola Mundo!” lo haríamos así: 120

MÓDULO B – Unidad 5: JavaServer Pages <%! String var = “Hola Mundo!” %>  El Servidor de Aplicaciones Java EE, al generar el Java Servlet añadiría dicha variable como un atributo en la clase Java generada. Si lo que queremos es definir un método que sume dos números, por ejemplo, lo haríamos así: <%!    public int suma(int param1, int param2)    {      return param1 + param2;    }  %>  El Servidor de Aplicaciones Java EE, al generar el Java Servlet, añadiría dicha definición como un método en la clase Java generada. Nota: es muy importante en este punto, tener en cuenta que este tipo de aplicaciones Java EE son multiusuario y por tanto multitarea. Es decir, se producen n ejecuciones paralelas del mismo código y por tanto el uso de los atributos o variables de instancia pueden ser “peligrosos” y producir efectos no deseados. Asumimos que el lector es conocedor de las problemáticas asociadas a la programación concurrente tratadas en el Curso de Aula Mentor “Programación en Java – Avanzado”. No obstante, volveremos de nuevo a este tema en las siguientes unidades.

5.3.4 Etiqueta de scriptlets Los scriptles son las porciones de código Java embebidos en la JavaServer Page. Utilizan las siguientes etiquetas: <% … %> Por ejemplo: <% String var = “Hola Mundo!”; %>  Seguramente, os estaréis preguntando si esto no es lo mismo que la etiqueta de declaración que vimos antes. La respuesta es no. La declaración, creaba un atributo, es decir, una variable de instancia. Sin embargo, en este caso de ahora, al usar un scriptlet, se trata de una variable local. Pero variable local, ¿de qué método? Como ya hemos comentado varias veces, el Servidor de Aplicaciones Java EE automáticamente convierte la JavaServer Page en un Java Servlet. Y por tanto, tendrá un método service() como ya vimos en la unidad anterior dedicada a los Java Servlets. Pues bien, todo el etiquetado de presentación de la JavaServer Page, así como los scriptlets, son incluidos en el método service() del Java Servlet autogenerado. Es por tanto en dicho método donde se crea la variable local de nuestro último ejemplo. 121

Un uso habitual de los scriptlets que dota de gran potencia y dinamismo a las JavaServer Pages, es su integración con el etiquetado de presentación. Por ejemplo: <%    if(sexo.equals(“Hombre”))    {  %>      

Buenos días señor

  <%    }    else    {  %>      

Buenos días señora

  <%    }  %>  Como podemos observar, hemos conseguido dotar de dinamismo al lenguaje HTML que por su naturaleza es estático. Dependiendo del valor de una variable, la etiqueta HTML que se envía al cliente como parte de la respuesta es una u otra. Igual que hemos utilizado una bifurcación, pensad en la flexibilidad que nos da poder usar también un bucle para alimentar listas o tablas de forma dinámica.

5.3.5 Etiqueta de expresión Este es el último tipo de etiquetas específicas de la tecnología JavaServer Page. Este tipo lo que permite es devolver un valor de una variable o un método e insertarlo como parte de la respuesta. La sintaxis de la etiqueta es así: <%= … %> Por ejemplo:

El resultado de sumar 2 + 2 es: <%= 2 + 2 %>.

  O por ejemplo: La hora actual es: <%= Calendar.getInstance().getTime() %>.  Es importante fijarse, que la expresión Java no se termina con el signo de punto y coma (;) como se hace habitualmente. Evidentemente, no se pueden encadenar expresiones, solo se permite una. El Servidor de Aplicaciones Java EE, incluirá en el Java Servlet autogenerado el mix de código estático y código dinámico como ya aprendimos a hacerlo en la unidad de Java Servlets.

122

MÓDULO B – Unidad 5: JavaServer Pages

5.3.6 Ejemplo con todas las etiquetas Vemos un ejemplo completo con todos los tipos de etiquetas en funcionamiento: <%@ page language="java" contentType="text/html; charset=ISO‐8859‐1"  pageEncoding="ISO‐8859‐1" %>  <%@ page import="java.util.Calendar" %>              <META http‐equiv="Content‐Type" content="text/html; charset=ISO‐      8859‐1">                    <%‐‐ Método para sumar dos números enteros ‐‐%>      <%!        public int sumar(int param1, int param2)        {          return param1 + param2;        }      %>      <%        if(request.getParameter("switch") == null)    {      %>                                            Primer número:                                            Segundo número:                                                                          <%        }        else        {          try          {          int param1 = Integer.parseInt(request.getParameter("param1"));          int param2 = Integer.parseInt(request.getParameter("param2"));          int result = param1 + param2;      %>      El resultado de la suma es: <%= sumar(param1, param2) %>

      <%        }        catch(NumberFormatException ex)        {      %>  123

    Alguno de los números no contenía dígitos válidos...

      <%        }      %>      <%= Calendar.getInstance().getTime() %>

      Volver atrás...      <%        }      %>        Si analizamos detenidamente el ejemplo, podemos observar el uso de los distintos tipos de etiquetado:  Directivas para definir algunos aspectos técnicos de la JavaServer Page, así como añadir imports necesarios para la correcta compilación.  Comentarios para documentar el objetivo del método sumar.  Declaraciones para definir el método sumar.  Scriptlets para implementar la lógica de control.  Expresiones para devolver los valores calculados. Evidentemente se trata de un ejemplo, donde hemos intentado utilizar el 100% de los conceptos expuestos. No quiere decir que la mejor solución implique utilizarlos todos. Por cierto, algún lector se habrá dado cuenta de la utilización de un objeto “request” sin haberlo mencionado ni definido en ningún sitio. Las JavaServer Pages cuentan con una serie de objetos implícitos accesibles desde cualquier punto de la página. Los comentaremos en la siguiente sección. Adicionalmente, y simplemente a modo ilustrativo, adjuntamos el código fuente del Java Servlet que el Servidor de Aplicaciones Java EE habría generado para la JavaServer Page de ejemplo. Como decimos, es puramente a modo ilustrativo, por si puede ayudar a entender los conceptos explicados. Recordar que la generación y compilación de este Java Servlet es algo automático e intrínseco del Servidor de Aplicaciones Java EE: /*   * Generated by the Jasper component of Apache Tomcat   * Version: Apache Tomcat/7.0.22   * Generated at: 2012‐02‐17 12:25:10 UTC   * Note: The last modified time of this file was set to   *       the last modified time of the source file after   *       generation to assist with modification tracking.   */  package org.apache.jsp;    import javax.servlet.*;  import javax.servlet.http.*;  import javax.servlet.jsp.*;  import java.util.Calendar;    124

MÓDULO B – Unidad 5: JavaServer Pages public final class calculadora_jsp extends  org.apache.jasper.runtime.HttpJspBase      implements org.apache.jasper.runtime.JspSourceDependent {      public int sumar(int param1, int param2)    {      return param1 + param2;    }          private static final javax.servlet.jsp.JspFactory _jspxFactory =            javax.servlet.jsp.JspFactory.getDefaultFactory();      private static java.util.Map  _jspx_dependants;      private javax.el.ExpressionFactory _el_expressionfactory;    private org.apache.tomcat.InstanceManager _jsp_instancemanager;      public java.util.Map  getDependants() {      return _jspx_dependants;    }      public void _jspInit() {      _el_expressionfactory =  _jspxFactory.getJspApplicationContext(getServletConfig().getServletCon text()).getExpressionFactory();      _jsp_instancemanager =  org.apache.jasper.runtime.InstanceManagerFactory.getInstanceManager(ge tServletConfig());    }      public void _jspDestroy() {    }      public void _jspService(final javax.servlet.http.HttpServletRequest     request, final javax.servlet.http.HttpServletResponse response)          throws java.io.IOException, javax.servlet.ServletException {        final javax.servlet.jsp.PageContext pageContext;      javax.servlet.http.HttpSession session = null;      final javax.servlet.ServletContext application;      final javax.servlet.ServletConfig config;      javax.servlet.jsp.JspWriter out = null;      final java.lang.Object page = this;      javax.servlet.jsp.JspWriter _jspx_out = null;      javax.servlet.jsp.PageContext _jspx_page_context = null;        try {        response.setContentType("text/html; charset=ISO‐8859‐1");        pageContext = _jspxFactory.getPageContext(this, request,         response, null, true, 8192, true);        _jspx_page_context = pageContext;        application = pageContext.getServletContext();        config = pageContext.getServletConfig();        session = pageContext.getSession();        out = pageContext.getOut();        _jspx_out = out;          out.write("\r\n");        out.write("\r\n");  125

      out.write("\r\n");        out.write("\r\n");        out.write("  \r\n");        out.write("    <META http‐equiv=\"Content‐Type\"         content=\"text/html; charset=ISO‐8859‐1\">\r\n");        out.write("    \r\n");        out.write("  \r\n");        out.write("  \r\n");        out.write("  ");        out.write("\r\n");        out.write("    ");        out.write("\r\n");        out.write("  \t");          if(request.getParameter("switch") == null)        {        out.write("\r\n");        out.write("\t\r\n");        out.write("\t\t\r\n");        out.write("\t\t\r\n");        out.write("\t\t\t\r\n");        out.write("\t\t\t\tPrimer número:\r\n");        out.write("\t\t\t\t\r\n");        out.write("\t\t\t\r\n");        out.write("\t\t\t\r\n");        out.write("\t\t\t\tSegundo número:\r\n");        out.write("\t\t\t\t\r\n");        out.write("\t\t\t\r\n");        out.write("\t\t\t\r\n");        out.write("\t\t\t\t\r\n");        out.write("\t\t\t\r\n");        out.write("\t\t\r\n");        out.write("\t\r\n");        out.write("\t");      }     else     {    try    {      int param1 = Integer.parseInt(request.getParameter("param1"));      int param2 = Integer.parseInt(request.getParameter("param2"));        out.write("\r\n");        out.write("\tEl resultado de la suma es: ");        out.print( sumar(param1, param2) );        out.write("

\r\n");        out.write("\t");    }    catch(NumberFormatException ex)    {        out.write("\r\n");        out.write("\tAlguno de los números no contenía dígitos         válidos...

\r\n");        out.write("\t");    }        out.write('\r');        out.write('\n');  126

MÓDULO B – Unidad 5: JavaServer Pages       out.write('  ');        out.print( Calendar.getInstance().getTime() );        out.write("

\r\n");        out.write("\tVolver         atrás...\r\n");        out.write("\t");        }        out.write("\r\n");        out.write("  \r\n");        out.write("");      } catch (java.lang.Throwable t) {        if (!(t instanceof javax.servlet.jsp.SkipPageException)){          out = _jspx_out;          if (out != null && out.getBufferSize() != 0)            try { out.clearBuffer(); } catch (java.io.IOException e) {}          if (_jspx_page_context != null)           _jspx_page_context.handlePageException(t);        }      } finally {        _jspxFactory.releasePageContext(_jspx_page_context);      }    }  }  Aunque hay muchas líneas de código que no son fáciles de interpretar a estas alturas del curso, si que de un simple vistazo el alumno debería ser capaz de identificar los métodos _jspInit(), _jspService() y _jspDestroy() que son invocados por los métodos del ciclo de vida de los Java Servlets estudiados en la unidad anterior. Y si nos centramos en concreto en el método _jspService(), se debería poder identificar fácilmente la lógica de control de nuestro JavaServer Page, así como las impresiones del código estático HTML a la respuesta. También se puede identificar al inicio, la declaración del método sumar() como parte del Java Servlet generado.

5.4

Otros conceptos

En este apartado trataremos algunos otros conceptos relacionados con los JavaServer Pages que ya hemos mencionado pero no hemos tratado con el suficiente detalle.

5.4.1 El ciclo de vida de un JavaServer Page Al igual que ocurría con los Java Servlets, los JavaServer Pages también siguen un ciclo de vida definido por el API de la especificación Java EE. En concreto el interface: javax.servlet.jsp.HttpJspBase Dicho ciclo de vida es el mismo que el de los Java Servlets ya que como hemos indicado en varias ocasiones ya, los JavaServer Pages terminan siendo transformados por el Servidor de Aplicaciones Java EE en un Java Servlet. La única diferencia radica en los nombres. Los métodos del ciclo de vida de un JavaServer Page son: 127

 public void _jspInit();  public _jspService(HttpServletRequest request, HttpServletResponse response);  public void _jspDestroy(); Si quisiéramos sobrescribir el comportamiento de inicialización o finalización de un JavaServer Page, deberíamos hacerlo redefiniendo el método en cuestión mediante las etiquetas de declaración. Pero es raro tener que hacerlo. El método _jspService por el contrario, no se sobrescribe nunca, porque ya hemos visto que cualquier cosa que añadamos al JavaServer Page forma parte de él. Es decir, crear un JavaServer Page implica siempre sobreescribir el método _jspService.

5.4.2 Objetos implícitos de un JavaServer Page El contenedor Web de un Servidor de Aplicaciones Java EE, pone a disposición de los desarrolladores de JavaServer Pages una serie de objetos implícitos sin necesidad de que estos tengan que crearlos o buscarlos. En el último ejemplo que vimos, utilizamos el objeto request que representa a la petición HTTP recibida por el JavaServer Page sin necesidad de crearlo, o pedirlo. Directamente existe y es utilizable. Los objetos implícitos son:  request: representa la petición HTTP y normalmente la utilizaremos para acceder a los parámetros enviados desde el cliente.  response: representa la respuesta HTTP.  session: representa la sesión HTTP del usuario. Este tema lo veremos con mayor profundidad en siguientes unidades.  application: representa el contexto de la aplicación. Este tema lo veremos con mayor profundidad en siguientes unidades.  config: representa la configuración inicial que se ha hecho para este JavaServer Page. Este tema lo veremos con mayor profundidad en siguientes unidades.  page: representa la propia página. Sería lo mismo que usar la keyword de Java: this.  exception: representa la excepción que se ha producido y que ha motivado que el Servidor de Aplicaciones Java EE redirigiese la ejecución a esta página. Debe utilizar la directiva “isErrorPage”. Si no se es una página definida como página de error, este objeto no estará accesible.  out: representa el writer de escritura de la respuesta HTTP. No suele ser habitual su uso desde una JavaServer Page..

128

MÓDULO B – Unidad 5: JavaServer Pages 5.4.3 Empaquetado y despliegue Como comentábamos en la primera unidad de este curso de introducción al Java EE, una aplicación Java EE está formada por un empaquetamiento de una o varias unidades conocidas con el nombre de módulos. Este empaquetamiento final era un EAR (Enterprise ARchive). Uno de esos módulos son los Web, que contienen normalmente Java Servlets, JavaServer Pages (JSP), JavaServer Faces (JSF), contenidos estáticos como imágenes, HTMLs, CSSs… Su extensión del fichero empaquetado es WAR (Web ARchive). En este curso, nos vamos a centrar exclusivamente de este tipo de módulos, ya que intentamos cubrir solo la parte web de la programación Java EE y no el resto de aspectos que darían lugar a un curso demasiado extenso o a un segundo curso. A pesar de que las aplicaciones Java EE se empaquetan en un EAR, los Servidores de Aplicación que solo cubren parte de la especificación Java EE como ocurre con Apache Tomcat, permiten desplegar simplemente módulos Web aislados. Este será nuestro caso durante este curso. Gráficamente, la estructura de un módulo Web empaquetado sería la siguiente:

Como podemos observar, tiene bastante parecido a la estructura del proyecto web dentro de Eclipse IDE for Java EE Developers aunque no es igual. En principio, el raíz del fichero WAR correspondería al directorio /WebContent y el directorio /classes del fichero WAR correspondería al directorio /build/classes. 129

Ahora bien, normalmente no nos preocuparemos mucho de la generación de un módulo Web u otro tipo de módulo, porque son los IDEs los que nos van a ayudar a generarlo. Por ejemplo, en nuestro caso, con Eclipse IDE for Java EE Developers basta con seleccionar el proyecto, pulsar el botón derecho del ratón y seleccionar las opciones “Export” -> “WAR file”:

130

MÓDULO B – Unidad 5: JavaServer Pages En la siguiente ventana, nos aseguramos que el proyecto seleccionado es el correcto, y decidimos donde y con que nombre se va a generar el fichero WAR, por ejemplo, “C:\EjemplosWeb.war”. Pulsar el botón “Finish”:

Si vamos a una sesión de DOS, mediante el comando de la JDK jar.exe (jar tvf nombreFichero.war), podemos ver su contenido y confirmar que la estructura generada es exactamente la de la especificación Java EE:

131

Este fichero WAR, sería el que un administrador de Servidores de Aplicación Java EE desplegaría y configuraría para que la aplicación estuviese disponible y dando servicio. Pero en nuestro caso, simplemente añadiremos o quitaremos aplicaciones en el Apache Tomcat de Eclipse IDE for Java EE Developers mediante el interfaz de usuario: botón derecho del ratón y la opción “Add and Remove…”, o directamente sobre el componente y “Run As” -> “Run on Server”. Nos queda no obstante hablar un poco sobre el descriptor de despliegue. Como ya adelantábamos en la primera unidad, se trata de un fichero XML donde se describe un poco el contenido y posible comportamiento del contenido del módulo. En el caso concreto de los módulos Web, su descriptor de despliegue es el fichero web.xml A lo largo de esta unidad, nunca hemos hecho mención de él, ya que a diferencia de los Java Servlets, los JavaServer Pages pueden ser invocados directamente mediante el nombre del fichero sin necesidad de registrarlos en el descriptor de despliegue. No obstante, es posible registrarlos con otro alias para evitar que sean invocados mediante el nombre del fichero. Esto se consigue de forma parecida a como hacíamos con los Java Servlets pero con la etiqueta ”jsp-file” en vez de “servlet-class”. Veamos un ejemplo:             CalculadoraJSP      /calculadora.jsp              CalculadoraJSP      /CalculadoraJSP        Si utilizamos este descriptor de despliegue en nuestro ejemplo, en vez de usar esta URL para invocar nuestra JavaServer Page: http://localhost:8080/EjemplosWeb/calculadora.jsp podríamos utilizar esta otra: http://localhost:8080/EjemplosWeb/CalculadoraJSP Existen muchas mas etiquetas a utilizar en un descriptor de despliegue de un módulo Web, pero las iremos viendo a lo largo del curso según las vayamos necesitando. De momento nos quedamos con la general “web-app” y las necesarias para registrar un alias a un JavaServer Page. 132

MÓDULO B – Unidad 5: JavaServer Pages Es una buena práctica utilizar siempre el alias y ocultar de esta manera el nombre del fichero al llamante de la JavaServer Page (JSP).

133

PARA RECORDAR

 Los JavaServer Pages, son un tipo de componente Java EE que se empaquen en un módulo web (WAR) y se despliegan y ejecutan en el contenedor web de un Servidor de Aplicaciones Java EE.

 Dentro del patrón de diseño MVC ocupan el espacio de la Vista, como encargado de mostrar el resultado de la petición al usuario final. Están enfocadas a la presentación.

 Un JavaServer Page, es un fichero de extensión *.jsp que utiliza principalmente lenguajes de etiquetado como el HTML en el que se pueden embeber mediante unas etiquetas especiales, código Java.

 Contienen distintos tipos de etiquetas, como son las:  Comentario: <%-- … --%>  Directiva: o page: añade información técnica a la página o include: se utiliza para incluir el resultado de la ejecución de otra JSP o taglib: se utiliza para definir una librería de etiquetas (tags) que se va a utilizar en la JavaServer Page  Declaración: <%! … %> utilizada para definir atributos y método que serán accesibles desde toda la JavaServer Page. 

Scriptles: <% … %> para incluir código Java embebido en la JavaServer Page.



Expresión: <%= … %> devuelve el valor de una variable o un método para insertarlo como parte de la respuesta.

 El ciclo de vida de una JavaServer Page es similar a los Java Servlets, solo que cambian los nombres, jspInit, jspService y jspDestroy

134

 Las JavaServer Pages, tienen una serie de objetos a su disposición de forma implícita, para utilizarlos en caso de necesitarlos:  request: representa la petición HTTP  response: representa la respuesta HTTP.  session: representa la sesión HTTP del usuario.  application: representa el contexto de la aplicación.  config: representa la configuración inicial que se ha hecho para este JavaServer Page.  page: representa la propia página.  exception: representa la excepción que se ha  out: representa el writer de escritura de la respuesta HTTP

135

136

Unidad de Aprendizaje 6

DISEÑO DE APLICACIONES JAVA EE

ÍNDICE 6.1

Introducción ................................................................. 139 6.1.1 El Controlador ...............................................................140 6.1.2 La Vista...........................................................................140 6.1.3 El Modelo .......................................................................141

6.2

Conectando Java Servlets con JavaServer Pages . 142 6.2.1 RequestDispatcher .......................................................142 6.2.2 Un ejemplo completo ...................................................143

6.3

Otros patrones de diseño........................................... 147

PARA RECORDAR.................................................................. 150

MÓDULO B – Unidad 6: Diseño de Aplicaciones Java EE

6.1

Introducción

Llegados a este punto, el alumno ya conoce lo básico de las tecnologías Java Servlet y JavaServer Page (JSP), sus pros y contras, puntos fuertes y puntos flojos. En más de una ocasión durante las últimas unidades, hemos comentado que estábamos haciendo un mal diseño de las aplicaciones pero que desde un punto de vista didáctico nos parecía conveniente hacerlo así, para comprender mejor esta unidad dedicada al diseño de Aplicaciones Java EE. Existen multitud de patrones de diseño relacionados con las Aplicaciones Java EE, pero hay uno ya mencionado durante el curso que tiene en cuenta a la aplicación en su conjunto y no a una parte solo. Estamos hablando del patrón MVC (Modelo-Vista- Controlador o Model-View-Controller en inglés). Este patrón de diseño divide la aplicación en tres roles, cada uno de ellos con unas responsabilidades muy concretas. 

El Modelo (Model): Representa los datos y cualquier lógica de negocio relacionada con ellos.



La Vista (View): renderiza el contenido de los modelos dependiendo de la tipología de cliente (navegador web, teléfono móvil, etc…).



El Controlador (Controller): define el comportamiento general de la aplicación coordinando a las otras dos partes (Modelo y Vista).

Veamos el patrón de diseño en un diagrama:

139

Pues bien, los dos tipos de componentes Java EE que hemos estudiado ya, encajan perfectamente en este diseño:  Controlador: Java Servlets.  Vista: JavaServer Pages (JSP).

6.1.1 El Controlador De la experiencia que hemos cogido con las actividades relacionadas con la unidad de los Java Servlets, hemos visto que son muy potentes para contener código Java, analizar los parámetros de las peticiones, validarlos, manipularlos, etc… pero sin embargo son realmente tediosos para manejar la presentación. Para un diseñador gráfico de páginas HTML, es realmente complicado crear y mantener dichas páginas a través de líneas out.println(….) que dificultan ver el resultado final en su conjunto.

6.1.2 La Vista Por el contrario, los JavaServer Pages (JSP) han demostrado ser muy valiosos para realizar el diseño gráfico de la presentación, insertando pequeños scriptlets Java, pero muy tediosos cuando el número de líneas de código Java se incrementa y entonces la mezcla de lógica y presentación se hace muy complicada.

140

MÓDULO B – Unidad 6: Diseño de Aplicaciones Java EE 6.1.3 El Modelo Con lo visto hasta ahora, no parece que ninguna de las dos tecnologías sea la más adecuada para implementar la lógica de negocio, es decir, encapsular e implementar la razón de nuestra Aplicación Java EE. Las especificaciones Java EE contemplan un tipo de componente cuyo objetivo es cubrir este hueco: los Enterprise JavaBeans (EJBs). Pero como no son objetivo de este curso, utilizaremos directamente POJOs (Plain Old Java Object, o lo que es lo mismo, clases Java sin más).

Por tanto, todo en su conjunto quedaría visualmente así:

Y el flujo habitual de una aplicación Java EE a partir de ahora quedará de la siguiente manera: 1. El cliente, por ejemplo un navegador, solicitará una funcionalidad desde el interface visual (Vista). 2. Dicha petición entrará a través de un Java Servlet (Controlador). 3. Dicho Java Servlet, analizará qué se está pidiendo, qué información adicional aporta y decidirá que JavaBean (Modelo) cubre dicha petición (implementado mediante un POJO). 4. Lo invocará, y tras recibir un resultado, decidirá qué JavaServer Page muestra dicho resultado al cliente (Vista). 5. El resultado será devuelto y mostrado. Para profundizar en el patrón de diseño Model-View-Controller, conectarse al Catálogo OnLine de patrones Java EE: http://www.oracle.com/technetwork/java/catalog-137601.html

141

6.2

Conectando Java Servlets con JavaServer Pages

Quedan claras entonces las interrelaciones que existirán entre los distintos componentes estudiados. ¿Pero técnicamente cómo hacemos dichos enlaces? La invocación desde un Java Servlet a un JavaBean (o POJO) es muy sencilla. Simplemente instanciará la clase en cuestión e invocará algún método de la misma. Pero, ¿y la invocación desde un Java Servlet a un JavaServer Page (JSP)? Dicha invocación se realiza mediante el interface javax.servlet.RequestDispatcher.

6.2.1 RequestDispatcher Una instancia del tipo RequestDispatcher, representa la información necesaria para lanzar una petición a un recurso web. En nuestro caso, podremos lanzar una petición a otro Java Servlet o un JavaServer Page (JSP). El acceso a dicha instancia se puede realizar mediante el método: RequestDispatcher getRequestDispatcher(java.lang.String path); de la HttpServletRequest, donde el parámetro que necesita, indica el recurso al que queremos acceder. RequestDispatcher tiene dos métodos:  void forward(ServletRequest request, ServletResponse response) throws…. Este primer método, nos permite redirigir la petición a otro componente y delegar en él la respuesta. Es decir, el control de lo que se responde al cliente por parte del Servidor Java EE queda delegado.  void include(ServletRequest request, ServletResponse response) throws…. Este segundo método nos permite incluir como parte de nuestra respuesta, la respuesta de otro componente. Es decir, dicho componente colabora con la respuesta, pero el control lo seguimos teniendo nosotros. Es el mismo resultado que la directiva JSP “include” que estudiamos en la unidad anterior. Los parámetros de ambos métodos son la petición y respuesta HTTP. Normalmente serán los mismos que hemos recibido. Por tanto, ya sabemos cómo redirigir la ejecución desde un Java Servlet a un JavaServer Page (JSP). Pero nos quedaría un tema pendiente. ¿Cómo le pasamos información de la lógica de negocio al siguiente? Existen varias maneras de hacerlo:  A través de la HttpServletRequest. Podemos utilizar los métodos setParameter(…) o setAttribute(…) de la petición para añadir información que será utilizada por el siguiente componente de la aplicación mediante los correspondientes métodos getParameter(…) o getAttribute(…).  A través de la HttpSession. Todavía no hemos estudiado este concepto. Lo trataremos en la siguiente unidad. 142

MÓDULO B – Unidad 6: Diseño de Aplicaciones Java EE  A través del ServletContext. Todavía no hemos estudiado este concepto. Lo trataremos en la siguiente unidad.

6.2.2 Un ejemplo completo Veamos un ejemplo completo de una aplicación web que resta dos números y que implementa todos los roles del patrón de diseño Java EE MVC, cada uno de ellos en su sitio adecuado. Nota: Aunque un ejemplo tan sencillo se podría pensar en implementar en un solo componente como hemos hecho en las actividades anteriores, debemos ser capaces de extrapolar el ejemplo a una aplicación mucho más compleja y entenderemos las grandes ventajas de este diseño que ya utilizaremos siempre a partir de ahora en el curso.

Página JSP de cabecera a ser reutilizada (Vista) cabecera.jsp: <%@ page language="java" contentType="text/html; charset=ISO‐8859‐1"  pageEncoding="ISO‐8859‐1"%>                                        

Ejemplo de MVC

                                 

---

  Página JSP inicial (Vista): <%@ page language="java" contentType="text/html; charset=ISO‐8859‐1"  pageEncoding="ISO‐8859‐1"%>              <META http‐equiv="Content‐Type" content="text/html; charset=ISO‐      8859‐1">                    <%@ include file="/cabecera.jsp" %>                                      Primer número:                        143

                    Segundo número:                                                                          JavaBean o POJO (Modelo) RestadorBean.java: package es.aulamentor;    public class RestadorBean  {    public int restar(int param1, int param2)    {      return param1 + param2;    }  }  Java Servlet (Controlador) index.jsp: package es.aulamentor;    import java.io.IOException;    import javax.servlet.ServletException;  import javax.servlet.annotation.WebServlet;  import javax.servlet.http.HttpServlet;  import javax.servlet.http.HttpServletRequest;  import javax.servlet.http.HttpServletResponse;    @WebServlet(name="RestadorServlet", urlPatterns={"/RestadorServlet"})  public class RestadorServlet extends HttpServlet   {          protected void doGet(HttpServletRequest request,     HttpServletResponse response) throws ServletException, IOException     {        this.procesarPeticion(request, response);    }      protected void doPost(HttpServletRequest request,     HttpServletResponse response) throws ServletException, IOException     {        this.procesarPeticion(request, response);    }          private void procesarPeticion(HttpServletRequest request,     HttpServletResponse response) throws ServletException, IOException    {        try        {  int param1 =  Integer.parseInt(request.getParameter("param1"));  144

MÓDULO B – Unidad 6: Diseño de Aplicaciones Java EE

      

       

    } 

int param2 =  Integer.parseInt(request.getParameter("param2"));      RestadorBean restadorBean = new RestadorBean();          int result = restadorBean.restar(param1, param2);         request.setAttribute("result", result);         request.getRequestDispatcher("/result.jsp").forward(reques t, response);      }      catch(NumberFormatException ex)      {  request.setAttribute("error", "Alguno de los números no  contenía dígitos válidos...");      request.getRequestDispatcher("/error.jsp").forward(request , response);      }    } 

Página JSP de resultado (Vista) result.jsp: <%@ page language="java" contentType="text/html; charset=ISO‐8859‐1"  pageEncoding="ISO‐8859‐1"%>              <META http‐equiv="Content‐Type" content="text/html; charset=ISO‐      8859‐1">                    <%@ include file="/cabecera.jsp" %>      El resultado de la suma es: <%= request.getAttribute("result") %>      

      Volver atrás...        Página JSP de error (Vista) error.jsp: <%@ page language="java" contentType="text/html; charset=ISO‐8859‐1"  pageEncoding="ISO‐8859‐1"%>              <META http‐equiv="Content‐Type" content="text/html; charset=ISO‐      8859‐1">                    <%@ include file="/cabecera.jsp" %>      Se ha producido el siguiente error:

      <%= request.getAttribute("error") %>      

  145

    Volver atrás...        No es necesario utilizar un descriptor de despliegue, ya que en el Java Servlet hicimos uso de las Anotaciones Java. Si el alumno implementa este ejemplo, debería ver algo así… Página de inicio:

Página de resultado:

146

MÓDULO B – Unidad 6: Diseño de Aplicaciones Java EE Página de error:

6.3

Otros patrones de diseño

A lo largo de la vida de las especificaciones Java EE, se han ido definiendo distintos patrones de diseño (buenas prácticas) que han demostrado ser muy útiles por distintos motivos tanto en el desarrollo como en el mantenimiento de las aplicaciones web. Existe mucha literatura sobre el tema, aunque la guía básica es la denominada Java EE BluePrints: http://java.sun.com/blueprints/patterns/ Este curso no pretende entrar a estudiar en profundidad los distintos patrones, pero si que comentaremos y utilizaremos alguno adicional que resultan interesantes A continuación, listamos alguno sencillo de entender y de mucha utilidad: 

Business Delegate (o Delegación de Negocio): permite reducir el acoplamiento entre la capa web y la capa de negocio. Se trata de una capa intermedia que abstrae a la capa de presentación de la tecnología empleada en la capa de negocio, es decir, conseguiríamos que la capa de presentación no supiera si la lógica de negocio se implementa mediante entidades Java Persistence API (JPA), Enterprise JavaBeans (EJBs), POJOs, etc…y un cambio de tecnología, no afectaría para nada a la capa de presentación, solo a los Business Delegates. Más información en: http://www.oracle.com/technetwork/java/businessdelegate-142190.html 147



Data Access Object, también llamado DAO (u Objeto de Acceso a Datos): permite abstraer a la lógica de negocio del sistema de persistencia de los datos. Seguramente a muchos os sonará de cuando estudiasteis el acceso a Bases de Datos con Java: JDBC (Java DataBase Access). Es decir, la lógica de la aplicación es agnóstica de si estamos usando Bases de Datos, ficheros, o cualquier otra fórmula de persistencia y acceso a los datos. Nuevamente, un cambio en la forma de hacerlo, solo afectaría al Data Access Object pero no a la lógica de negocio. Tendremos oportunidad de utilizarlo en los ejemplos y actividades de las siguientes unidades. Más información en: http://www.oracle.com/technetwork/java/dao-138818.html



Front Controller (o Controlador Frontal): se trata de una pieza controladora que centraliza todas las peticiones y va eligiendo qué lógica de negocio y presentación son necesarias para dicha petición. Sin saberlo, así es como hemos trabajado en esta unidad. Siempre hemos manejado un único Java Servlet controlador que ha gestionado las peticiones. Evidentemente nuestros ejemplos eran muy sencillos y quizás no se vea la utilidad pero imaginemos por un momento una aplicación web típica de altas, bajas y modificaciones. Una primera aproximación podría ser contar con un Java Servlet para cada petición, pero este patrón de diseño recomienda tener uno solo que sepa gestionar de manera centralizada los tres tipos de petición. Tendremos oportunidad de utilizarlo en los ejemplos y actividades de las siguientes unidades. Más información: http://www.oracle.com/technetwork/java/frontcontroller-141071.html



Intercepting Filter (o Filtro Interceptor): permite implementar una lógica que se ejecute siempre previamente a recibir una petición y posteriormente a enviar la respuesta. Imaginemos por ejemplo que queremos incluir en nuestra aplicación un sistema de logging, o de autenticación, etc… Técnicamente se implementa mediante unos Java Servlets especiales denominados filtros que estudiaremos en la siguiente unidad. Más información en: http://www.oracle.com/technetwork/java/interceptingfilter-136585.html



Service Locator (o Localizador de Servicios): permite simplificar el acceso a servicios de la aplicación (por ejemplo Enterprise JavaBeans) o del Servidor de Aplicaciones Java EE (por ejemplo Pool de Conexiones a Bases de Datos o Conectores a Sistemas Empresariales) encapsulando dicha búsqueda y permitiendo su reutilización.

148

MÓDULO B – Unidad 6: Diseño de Aplicaciones Java EE Hablaremos de nuevo de este patrón en la siguiente unidad, cuando tratemos el acceso a Bases de Datos y los Pool de Conexiones (conocidos también con el nombre de Data Sources). Más información en: http://www.oracle.com/technetwork/java/servicelocator-138528.html 

Transfer Object (u Objeto de Transferencia): permite encapsular la información que viaja entre las distintas capas de la aplicación. Tiene mucho sentido cuando ambas capas están separadas físicamente y por tanto implica una comunicación por red en cada petición. Suele ser mejor desde un punto de vista de rendimiento, pedir una vez y recibir mucha información, que pedir más de una vez. Se utiliza frecuentemente en las invocaciones desde la capa de presentación y la capa de lógica de negocio cuando esta es distribuida, por ejemplo utilizando Enterprise JavaBeans (EJBs). En nuestro caso que utilizamos JavaBeans locales, no tiene un impacto tan grande. Más información: http://www.oracle.com/technetwork/java/transferobject-139870.html

149

PARA RECORDAR

 En esta unidad hemos visto detalladamente que componentes son los adecuados a utilizar siguiendo el patrón de diseño MVC:  El Modelo: Representa los datos y cualquier lógica de negocio relacionada con ellos. Implementado mediante POJOS (también EJBs).  La Vista: Renderiza el contenido de los modelos dependiendo de la tipología de cliente (navegador web, teléfono móvil, etc…). Implementado mediante JavaServer Pages (JSP).  El Controlador: Define el comportamiento general de la aplicación coordinando a las otras dos partes (Modelo y Vista). Implementado mediante Java Servlets.

 La conexión entre un Java Servlet y un POJO se realiza mediante las llamadas a los métodos de dicho componente.

 La conexión entre un Java Servlet y un JavaServer Page (JSP) se realiza mediante los métodos forward o include (dependiendo de las necesidades) de la clase RequestDispatcher.

 Para pasarle los datos necesarios del Java Servlet y un JavaServer Page (JSP) se pueden utilizar los siguiente mecanismos:  HttpServletRequest. Podemos setAttribute(…) de la petición

utilizar

los

métodos

setParameter(…)

o

 HttpSession.  ServletContext.

 Otros patrones de diseño Java EE son:  Business Delegate: permite reducir el acoplamiento entre la capa web y la capa de negocio.  Data Access Object: permite abstraer a la lógica de negocio del sistema de 150

 Front Controller: se trata de una pieza controladora que centraliza todas las peticiones y va eligiendo qué lógica de negocio y presentación son necesarias para dicha petición.  Intercepting Filter: permite implementar una lógica que se ejecute siempre previamente a recibir una petición y posteriormente a enviar la respuesta.  Service Locator: permite simplificar el acceso a servicios de la aplicación o del Servidor de Aplicaciones Java encapsulando dicha búsqueda y permitiendo su reutilización.  Transfer Object: permite encapsular la información que viaja entre las distintas capas de la aplicación

151

152

Unidad de Aprendizaje 7

JAVA SERVLETS AVANZADO

ÍNDICE 7.1

Introducción ................................................................. 155

7.2

Configuración de un Java Servlet ............................. 155 7.2.1 Mediante descriptor de despliegue ...........................155 7.2.2 Mediante anotaciones..................................................156

7.3

Concurrencia en un Java Servlet .............................. 158

7.4

Acceso a Bases de Datos........................................... 160 7.4.1 Acceso directo desde el código.................................160 7.4.2 Acceso a través de un Pool de Conexiones.............166

7.5

Filtros............................................................................. 175

7.6

Mantenimiento del estado del cliente ...................... 179 7.6.1 Cookies ..........................................................................179 7.6.2 Sesión HTTP..................................................................188

7.7

Gestión de eventos...................................................... 193

PARA RECORDAR.................................................................. 201

MÓDULO C – Unidad 7: Java Servlets Avanzado

7.1

Introducción

A estas alturas del curso, ya hemos aprendido las tecnologías básicas sobre las que se apoya el desarrollo de aplicaciones web Java EE y cuándo usar unas u otras. Incluso ya hemos desarrollado algunas aplicaciones sencillas. El objetivo de las siguientes unidades, es profundizar en estas tecnologías para poderle sacar más provecho y llegar a desarrollar aplicaciones Java EE reales.

7.2

Configuración de un Java Servlet

Como bien recordarás de las unidades anteriores, el ciclo de vida de un Java Servlet tenía un método de inicialización: public void init(ServletConfig config); que se ejecutaba una sola vez al inicio de la vida del Java Servlet y que se solía utilizar para llevar a cabo todas las labores de inicialización y configuración que necesitáramos para su posterior ejecución. Como

se

puede

observar,

javax.servlet.ServletConfig,

que

recibe

como

representa

parámetro la

una

información

de

instancia

de

configuración

la

clase

que

el

administrador del Servidor de Aplicaciones Java EE haya podido añadir. Dicha clase tiene distintos métodos para facilitar el acceso a su información: 

java.lang.String getInitParameter(java.lang.String name) Devuelve el parámetro de configuración que coincide con el nombre que se envía.



java.util.Enumeration getInitParameterNames() Devuelve una colección con los nombres de todos los parámetros de configuración que tiene.

¿Y cómo añadimos información de configuración a un Java Servlet? Pues bien, el desarrollador tiene dos modos de añadir dicha información: 

Mediante el descriptor de despliegue.



Mediante anotaciones en el código (a partir de Java EE 6.0).

7.2.1 Mediante descriptor de despliegue Consiste en añadir un bloque “init-param” por cada parámetro, con parejas de bloques “param-name” y “param-value”, dentro del bloque “servlet” que ya conocemos y hemos utilizado anteriormente. Veamos un ejemplo de un Java Servlet que recibe dos parámetros de configuración mediante el descriptor de despliegue: 155

            ConfigServlet      es.aulamentor.ConfigServlet              param1        Hola                    param2        Mundo                    ConfigServlet      /ConfigServlet       

7.2.2 Mediante anotaciones Se realiza añadiendo el atributo “initParams” a la anotación @WebServlet que ya hemos utilizado anteriormente. Dicho atributo, contiene a su vez, anotaciones @WebInitParam por cada parámetro, la cual nuevamente, contiene parejas de atributos “name” y “value”. Se entiende mucho más fácil con un ejemplo: package es.aulamentor;    import java.io.IOException;  import java.util.Enumeration;    import javax.servlet.ServletConfig;  import javax.servlet.ServletException;  import javax.servlet.annotation.WebInitParam;  import javax.servlet.annotation.WebServlet;  import javax.servlet.http.HttpServlet;  import javax.servlet.http.HttpServletRequest;  import javax.servlet.http.HttpServletResponse;    @WebServlet(name="ConfigServlet",urlPatterns={"/ConfigServlet"},  initParams={@WebInitParam(name="param1", value="Hola"),  @WebInitParam(name="param2", value="Mundo")})  public class ConfigServlet extends HttpServlet   {    public void init(ServletConfig config) throws ServletException     {      Enumeration parameters = config.getInitParameterNames();      while(parameters.hasMoreElements())      {        String name = parameters.nextElement();  156

MÓDULO C – Unidad 7: Java Servlets Avanzado       System.out.println("Nombre: " + name + " Valor: " +         config.getInitParameter(name));      }    }      protected void doGet(HttpServletRequest request,      HttpServletResponse response) throws ServletException,       IOException     {    }  }  Este código de ejemplo en ejecución dentro del entorno de desarrollo mostraría algo así:

Ambos dos métodos no son excluyentes, aunque no tiene mucho sentido utilizar ambos para un mismo Java Servlet. No obstante, si así fuera y en el hipotético caso de que en ambos dos sitios existiera un parámetro con el mismo nombre, tendría prioridad el del descriptor de despliegue.

157

7.3

Concurrencia en un Java Servlet

Nota: En esta sección se asume que el alumno tiene conceptos de programación avanzada en Java, en concreto, en la programación concurrente con Java Threads. Se dice que una aplicación soporta concurrencia cuando permite ejecuciones en paralelo de su código. Es decir, en el caso de las aplicaciones Java EE que estamos estudiando, significaría que varios usuarios puedan conectarse y ejecutar la aplicación a la vez. Las aplicaciones Java EE son concurrentes por naturaleza. El Servidor de Aplicaciones Java EE se encarga de controlar y permitir la concurrencia de la aplicación permitiendo al desarrollador prácticamente despreocuparse de esta casuística. Teniendo en cuenta que solamente hay una instancia de un Java Servlet por cada JVM, no debemos olvidarnos nunca del tema y tenerlo siempre presente en nuestros desarrollos para evitar problemas y comportamientos no deseados. Por ejemplo, imaginemos lo que puede ocurrir si utilizamos variables de instancia en el Java Servlet para manejar una información temporal durante la ejecución de un método, en el que hemos sustituido un posible código que tarda cierto tiempo en ejecutar por un Thread.sleep(5000); package es.aulamentor;    import java.io.IOException;  import javax.servlet.ServletException;  import javax.servlet.annotation.WebServlet;  import javax.servlet.http.HttpServlet;  import javax.servlet.http.HttpServletRequest;  import javax.servlet.http.HttpServletResponse;    @WebServlet("/ConcurrenciaServlet")  public class ConcurrenciaServlet extends HttpServlet   {    private int val = 0;      protected void doGet(HttpServletRequest request, HttpServletResponse     response) throws ServletException, IOException     {      val = Integer.parseInt(request.getParameter("param"));      System.out.println("Thread: " + Thread.currentThread().getName() +       " usa el valor: " + val);      try      {        //Simulamos que el servlet está con alguna operativa antes de         //volver a utilizar el valor de la variable val.        Thread.sleep(5000);      }      catch(InterruptedException ex)      {      }      System.out.println("Thread: " + Thread.currentThread().getName() +       " usa el valor: " + val);    }  }  E invocamos desde el navegador a este Java Servlet dos veces consecutivas (en menos de 5 segundos) primero con el parámetro 5 y luego con el parámetro 2: 158

MÓDULO C – Unidad 7: Java Servlets Avanzado http://localhost:8080/EjemplosWeb/ConcurrenciaServlet?param=5  http://localhost:8080/EjemplosWeb/ConcurrenciaServlet?param=2 Observemos en la salida por consola lo que ocurre:

La primera petición la sirve un thread controlado por el Servidor de Aplicaciones Java EE que se llama “http-bio-8080-exec3” y el inicio de la ejecución del Java Servlet muestra que el parámetro con el que tiene que trabajar vale 5. Entonces, se duerme durante 5 segundos (ha sido la forma de simular una tarea costosa) y cuando vuelve a por el parámetro, resulta que vale 2. ¿Qué ha pasado? Lo que ha pasado es que antes de que el primer Java Servlet terminara de ejecutarse, el Servidor de Aplicaciones Java EE recibió una segunda petición al mismo Java Servlet con un valor del parámetro distinto. Como ambos dos threads, en este caso “http-bio8080-exec-4”, ejecutan el mismo código, el segundo ha machacado el valor al primero. Se trata de un ejemplo muy sencillo, pero el problema que demuestra puede ser muy complicado de detectar. Existen distintas soluciones: 159



Evitar en la medida de lo posible utilizar variables de instancia cuando su valor es de escritura/lectura.



Implementar el interface javax.servlet.SingleThreadModel que le indica al Servidor de Aplicaciones Java EE, que no puede paralelizar las ejecuciones de este Java Servlet. Esta solución no es recomendable porque por regla general implica un tiempo de respuesta pésimo a los usuarios. Imaginad cien usuarios pidiendo este servicio a la vez y teniendo que esperar en cola a ser respondidos.



7.4

Utilizar técnicas de sincronización del lenguaje Java (synchronized).

Acceso a Bases de Datos

Nota: En esta sección se asume que el alumno tiene conceptos de programación avanzada en Java, en concreto, en la programación de acceso a Bases de Datos con JDBC. Existen distintas alternativas para el acceso a Bases de Datos desde aplicaciones web. Vamos a comentar dos de ellas: mediante el acceso directo a la Base de Datos desde el código y mediante un servicio que nos proveen los Servidores de Aplicaciones Java EE denominado Pool de Conexiones (o Data Source). La primera alternativa tiene bastantes problemas (uno de ellos es que tiene peor rendimiento que las otras alternativas) y no es para nada recomendada. Pero, no obstante, la veremos brevemente para entender mejor la naturaleza de una aplicación web, el por qué esta es una mala alternativa y cómo la segunda es una opción mucho mejor.

7.4.1 Acceso directo desde el código Este método supone ejecutar todos los pasos típicos del API JDBC en el código de nuestra aplicación:  Cargar el Driver JDBC en la JVM.  Crear una conexión a la Base de Datos.  Crear una sentencia (de cualquiera de los tipos) y ejecutarla.  Analizar el resultado de la sentencia.  Cerrar y liberar los recursos. Con lo que conocemos ya del desarrollo de Java Servlets, podríamos pensar en colocar los distintos pasos en distintos lugares del código. Por ejemplo, una opción sería realizar la carga del Driver JDBC, la creación de la conexión a la Base de Datos y de la sentencia a ejecutar en el método de inicialización de Java Servlet (init). En los métodos de proceso de HTTP GET o HTTP POST (doGet o doPost) la ejecución

160

MÓDULO C – Unidad 7: Java Servlets Avanzado de la sentencia y análisis del resultado. Y por último, en el método de finalización del Java Servlet (destroy) incluiríamos el código de limpieza, cerrando y liberando los recursos. Ahora bien, esta opción tiene un inconveniente, y es que la sentencia será una variable de instancia (o atributo), y como ya hemos tratado en la sección anterior, debido a que las aplicaciones web son multiusuario (multithread) por naturaleza, tendríamos que tener en cuenta el acceso sincronizado a la variable. Podríamos pensar entonces en otra opción, y sería pasar todos los pasos a los métodos de proceso de HTTP GET y HTTP POST (doGet y doPost) dejando únicamente la carga del Driver JDBC en el método de inicialización (init). En este caso es cierto que no tendremos que estar pendientes de sincronizar el acceso a ninguna variable de instancia (o atributo), pero penalizamos enormemente el rendimiento (tiempo de respuesta) de la aplicación al estar conectando y desconectando constantemente con la Base de Datos. Vamos a ver un ejemplo de código para que se visualice mejor esta primera alternativa de acceso a Bases de Datos aunque como ya dijimos no es la recomendada. El ejemplo consiste en una aplicación web de consulta de títulos de libros mediante el código ISBN: Página HTML de inicio:             <META http‐equiv="Content‐Type" content="text/html; charset=ISO‐      8859‐1">                                                  Introduzca el ISBN:                                                                            Java Servlet con la lógica: package es.aulamentor;    import java.io.IOException;  import java.sql.Connection;  import java.sql.DriverManager;  import java.sql.PreparedStatement;  import java.sql.ResultSet;  161

import java.sql.SQLException;    import javax.servlet.ServletConfig;  import javax.servlet.ServletException;  import javax.servlet.annotation.WebServlet;  import javax.servlet.http.HttpServlet;  import javax.servlet.http.HttpServletRequest;  import javax.servlet.http.HttpServletResponse;    @WebServlet("/BaseDatosServlet")  public class BaseDatosServlet extends HttpServlet   {    public void init(ServletConfig config) throws ServletException     {      try      {        Class.forName("org.apache.derby.jdbc.EmbeddedDriver");      }      catch(ClassNotFoundException ex)      {        System.out.println("Driver JDBC no encontrado...");        ex.printStackTrace();      }    }      protected void doPost(HttpServletRequest request,     HttpServletResponse response) throws ServletException, IOException     {      Connection con = null;      PreparedStatement pstmt = null;      ResultSet rs = null;      String isbn = request.getParameter("isbn");            try       {        con = DriverManager.getConnection("jdbc:derby:D:/biblioteca",        "derbyuser","derbyuser");        pstmt = con.prepareStatement("SELECT * FROM PRESTAMOS WHERE ISBN         = ?");        pstmt.setString(1,isbn);        rs = pstmt.executeQuery();        if(rs.next())        {      request.setAttribute("titulo", rs.getString(3));        }        request.getRequestDispatcher("/resultDB.jsp").forward(request,           response);      }       catch(SQLException ex)       {        System.out.println("Problemas en el acceso a la BD...");        ex.printStackTrace();      }      finally      {        try        {          if(rs != null)            rs.close();        }        catch(SQLException ex)  162

MÓDULO C – Unidad 7: Java Servlets Avanzado       {          ex.printStackTrace();        }        try        {          if(pstmt != null)            pstmt.close();        }        catch(SQLException ex)        {          ex.printStackTrace();        }        try        {          if(con != null)            con.close();        }        catch(SQLException ex)        {          ex.printStackTrace();        }      }    }  }  Página JSP de resultado: <%@ page language="java" contentType="text/html; charset=ISO‐8859‐1"  pageEncoding="ISO‐8859‐1"%>              <META http‐equiv="Content‐Type" content="text/html; charset=ISO‐      8859‐1">                    <%        if(request.getAttribute("titulo") != null)        {      %>          El título del libro es: <%= request.getAttribute("titulo") %>      <%        }        else        {      %>          Código ISBN no encontrado.      <%        }      %>      

      Volver atrás...       

163

En esta ocasión, nuestra aplicación está haciendo uso de los Drivers JDBC de una Base de Datos (en concreto de Apache Derby) por lo que tendremos que tener en cuenta añadir el fichero JAR que contiene dichas clases Java en nuestra aplicación. La estructura de un módulo Web según las especificaciones Java EE dictaba que este tipo de ficheros debían ubicarse en el directorio /WEB-INF/lib, que en un proyecto web de Eclipse IDE for Java EE Developers corresponde a /WebContent/WEB-INF/lib:

Otra opción sería añadir el fichero a la instalación del Servidor de Aplicaciones Java EE en vez de añadirlo a cada módulo web que acceda a la Base de Datos. La configuración de esta opción es dependiente del servidor, es decir, dependiendo del servidor que estemos utilizando se hará de una manera u otra. En nuestro caso, que estamos utilizando Apache Tomcat 7.0.x, el fichero JAR se debe copiar en el directorio /lib de la instalación:

164

MÓDULO C – Unidad 7: Java Servlets Avanzado

Independientemente de la opción de configuración elegida, la ejecución del ejemplo debería mostrar algo así… Página de inicio:

Página de resultado:

165

No obstante, como ya hemos comentado, esta forma de acceder a Bases de Datos tiene graves problemas de rendimiento en el caso de tener muchos usuarios y además, si decidimos compartir la conexión y la sentencia a través de una variable de instancia (o atributo) para mejorar algo el rendimiento, tenemos que introducir en la programación técnicas de sincronización que no son triviales. Por este motivo, las especificaciones Java EE definieron el concepto de Pool de Conexiones (Data Source) que todo Servidor de Aplicaciones Java EE debe implementar y que estudiaremos a continuación.

7.4.2 Acceso a través de un Pool de Conexiones Todo Servidor de Aplicaciones Java EE, debe implementar un servicio de Pool de Conexiones a Bases de Datos que implemente el siguiente interface: javax.sql.DataSource Dicho interface tiene solo dos métodos que permiten el acceso a una conexión:  Connection getConnection() throws SQLException; Devuelve una conexión a Base de Datos disponible del pool.  Connection getConnection(String username, String password) throws SQLException; Devuelve una conexión a Base de Datos disponible del pool pero usando un usuario y contraseña específico (no necesariamente el que use por defecto el Data Source). Al tratarse de un servicio del Servidor de Aplicaciones Java EE, tendremos que crearlo y configurarlo en el servidor para que sea accesible desde nuestra aplicación web. Y evidentemente, esto no se hace en el código sino en el propio servidor. Cada Servidor de Aplicaciones Java EE tiene su propio mecanismo de administración, es decir, las especificaciones Java EE dictan qué servicios e interfaces deben implementar, 166

MÓDULO C – Unidad 7: Java Servlets Avanzado pero indican en cómo lo tienen que hacer. Por tanto, la forma de configurar el servidor dependerá del que estemos usando. A continuación, comentaremos cómo se configura un Pool de Conexiones en Apache Tomcat 7.0.x que es el Servidor de Aplicaciones Java EE que estamos utilizando a lo largo de este curso. Apache Tomcat 7.0.x basa toda su administración y configuración en ficheros XML que residen en el directorio /conf. Pero como en nuestro caso lo estamos usando integrado en Eclipse IDE for Java EE Developers, existe un proyecto especial adicional a los dedicados a nuestros desarrollos que se llama “Servers”. Ahí es donde residen los ficheros XML de configuración del Apache Tomcat 7.0.x que estamos utilizando.

En concreto, para configurar un Pool de Conexiones nuevo, debemos editar el fichero de configuración context.xml, y a la sección ya existente añadirle el siguiente bloque “Resource”:
   

driverClassName="org.apache.derby.jdbc.EmbeddedDriver"   url="jdbc:derby:D:/biblioteca" />

Este bloque “Resource” define y configura un Pool de Conexiones a la Base de Datos Apache Derby que estamos usando en nuestro ejemplo. Repasemos el significado de algunas de las propiedades de la configuración:  name: identificador JNDI (Java Naming and Directory Interface) que utilizaremos para acceder al pool.  type:

tipo

de

interface

que

implementa

el

recurso

(en

nuestro

caso

javax.sql.DataSource).  username: identificador de usuario en el caso de que el Gestor de Base de Datos que estamos utilizando tenga la seguridad activada.  password: contraseña de usuario en el caso de que el Gestor de Base de Datos que estamos utilizando tenga la seguridad activada.  driverClassName: nombre del Driver JDBC de acceso al Gestor de Base de Datos que estamos utilizando.  url: URL JDBC. El resto de propiedades suelen estar relacionadas con las características más funcionales del Pool de Conexiones, temas como el número máximo de conexiones que puede tener, el tiempo máximo que una conexión puede estar asignada sin ser devuelta al pool, etc… Con esto, el Servidor de Aplicaciones Java EE ya va a crear y gestionar un Pool de Conexiones con nuestra Base de Datos. Ahora, nos queda indicar que nuestra aplicación web está interesada en el acceso a dicho pool y lo haremos mediante el descriptor de despliegue del módulo web (web.xml). Para ello, añadiremos el siguiente bloque “resource-ref”:     Conexion BD    jdbc/TestDB    javax.sql.DataSource    Container  Simplemente hacemos referencia al recurso creado y configurado en el servidor, identificando básicamente el nombre (res-ref-name) y tipo (res-type). De esta manera, al desplegar la aplicación web, el Servidor de Aplicaciones Java EE nos dará acceso al recurso. Ya solo nos queda modificar el código fuente de nuestra aplicación para que ahora haga uso del Data Source en vez de crear las conexiones a la Base de Datos directamente.

168

MÓDULO C – Unidad 7: Java Servlets Avanzado Para buscar y acceder a un recurso definido en el Servidor de Aplicaciones Java EE se utiliza el API JNDI (Java Naming and Directory Interface). Es el API a través del cual podemos conectarnos al directorio de recursos del servidor y acceder a ellos. Dicho API se encuentra en el paquete Java: javax.naming; Su uso es muy sencillo y normalmente consta de dos pasos:  Creación del Contexto de búsqueda: dirección IP, puerto del servicio, y punto de entrada en el directorio.  Realización de la búsqueda del recurso y downcasting a su tipo concreto. Veamos un ejemplo típico: try   {    Context initialContext = new InitialContext();    DataSource datasource =     (DataSource)initialContext.lookup("java:comp/env/jdbc/TestDB");  }   catch(NamingException ex)   {    System.out.println("Problemas en el acceso al recurso...");    ex.printStackTrace();  }  En el ejemplo creamos un Contexto con los valores por defecto, es decir, acceso al servicio del propio Servidor de Aplicaciones Java EE en el que la aplicación se está ejecutando desde la raíz del directorio. Si hubiéramos querido conectar con un servicio JNDI de otro Servidor de Aplicaciones Java EE remoto, tendríamos que haber creado el Contexto con los parámetros adecuados. Y a continuación, realizamos la búsqueda del recurso con el nombre “jdbc/TestDB”, que nos es devuelto como un java.lang.Object y de ahí que debamos hacer el downcasting a javax.sql.DataSource. Si no se encontrase el recurso por el motivo que fuese (el nombre está mal, no está bien configurado

en

el

servidor,

etc…)

se

producirá

una

excepción

javax.naming.NamingException que deberemos tratar según la lógica de nuestra aplicación. El lugar dentro del servicio JNDI donde se ubican siempre todos los recursos accesibles a las aplicaciones web es: java:comp/env, de ahí que la búsqueda no haya sido solo de “jdbc/TestDB” sino que ha sido de “java:comp/env/jdbc/TestDB”. Por último, ya solo quedaría pedirle al Data Source una conexión disponible a la Base de Datos a través de uno de los métodos comentados al inicio de este apartado. En este punto se encuentra la clave de esta alternativa de programación de acceso a Bases de Datos. En este caso, al contrario que ocurría cuando la conexión se la pedíamos al DriverManager, la conexión ya está establecida con el Gestor de Base de Datos con lo que el tiempo de respuesta es mucho mayor. Además, varias ejecuciones paralelas de nuestra aplicación 169

pueden estar accediendo a la Base de Datos en paralelo, no como antes que el acceso era sincronizado (y por tanto serializado) a una única conexión. No obstante, al igual que cuando accedíamos directamente a la Base de Datos desde el código, es importante liberar los recursos cuando se han dejado de utilizar. En este caso, la diferencia es que la llamada al método “close” de la conexión, en vez de cerrarla lo que hace es devolverla al Pool de Conexiones como disponible para poder ser utilizada por otra petición. Veamos la aplicación de ejemplo de antes, pero esta vez utilizando un Pool de Conexiones. Descriptor de despliegue:             DataSourceServlet      es.aulamentor.DataSourceServlet              DataSourceServlet      /DataSourceServlet              Conexion BD      jdbc/TestDB      javax.sql.DataSource      Container      Página HTML de inicio:             <META http‐equiv="Content‐Type" content="text/html; charset=ISO‐      8859‐1">                                      Introduzca el ISBN:                                              170

MÓDULO C – Unidad 7: Java Servlets Avanzado     Java Servlet: package es.aulamentor;    import java.io.IOException;  import java.sql.Connection;  import java.sql.PreparedStatement;  import java.sql.ResultSet;  import java.sql.SQLException;    import javax.naming.Context;  import javax.naming.InitialContext;  import javax.naming.NamingException;  import javax.servlet.ServletConfig;  import javax.servlet.ServletException;  import javax.servlet.http.HttpServlet;  import javax.servlet.http.HttpServletRequest;  import javax.servlet.http.HttpServletResponse;  import javax.sql.DataSource;    public class DataSourceServlet extends HttpServlet   {    DataSource datasource = null;      public void init(ServletConfig config) throws ServletException     {      try       {        Context initialContext = new InitialContext();        datasource =         (DataSource)initialContext.lookup("java:comp/env/jdbc/TestDB");      }       catch(NamingException ex)       {        System.out.println("Problemas en el acceso a la Base de         Datos...");        ex.printStackTrace();      }    }      protected void doPost(HttpServletRequest request,     HttpServletResponse response) throws ServletException, IOException     {      Connection con = null;      PreparedStatement pstmt = null;      ResultSet rs = null;      String isbn = request.getParameter("isbn");          try       {        con = datasource.getConnection();        pstmt = con.prepareStatement("SELECT * FROM PRESTAMOS WHERE ISBN         = ?");        pstmt.setString(1,isbn);        rs = pstmt.executeQuery();        if(rs.next())        {          request.setAttribute("titulo", rs.getString(3));  171

      }        request.getRequestDispatcher("/resultDS.jsp").forward(request,         response);      }       catch(SQLException ex)       {        System.out.println("Problemas en el acceso a la Base de         Datos...");        ex.printStackTrace();      }      finally      {        try        {          if(rs != null)            rs.close();        }        catch(SQLException ex)        {          ex.printStackTrace();        }        try        {          if(pstmt != null)            pstmt.close();        }        catch(SQLException ex)        {          ex.printStackTrace();        }        try        {          if(con != null)            con.close();        }        catch(SQLException ex)        {          ex.printStackTrace();        }      }    }  }  Página JSP de resultado: <%@ page language="java" contentType="text/html; charset=ISO‐8859‐1"  pageEncoding="ISO‐8859‐1"%>              <META http‐equiv="Content‐Type" content="text/html; charset=ISO‐      8859‐1">                    <%        if(request.getAttribute("titulo") != null)        {      %>          El título del libro es: <%= request.getAttribute("titulo") %>  172

MÓDULO C – Unidad 7: Java Servlets Avanzado     <%        }        else        {      %>          Código ISBN no encontrado.      <%        }      %>      

      Volver atrás...      La ejecución del ejemplo debería mostrar exactamente los mismos resultados que antes. Es decir, el cómo accedamos a la Base de Datos no afecta en nada a la presentación de la aplicación aunque seguramente si se notará mejor rendimiento (la búsqueda se hará más rápida). Página de inicio:

Página de resultado:

173

Ahora bien, como ya hemos comentado en otras ocasiones, a partir de Java EE 6.0 existe otra alternativa al descriptor de despliegue y código Java. Son las anotaciones Java. Veamos cómo quedaría el mismo ejemplo usando la anotación @Resource. En vez de escribir las líneas de código necesarias para realizar la búsqueda: public class DataSourceServlet extends HttpServlet   {    DataSource datasource = null;      public void init(ServletConfig config) throws ServletException     {      try       {        Context initialContext = new InitialContext();        datasource =         (DataSource)initialContext.lookup("java:comp/env/jdbc/TestDB");      }       catch(NamingException ex)       {        System.out.println("Problemas en el acceso a la BD...");        ex.printStackTrace();      }    } podríamos simplemente usar esta anotación: public class DataSourceServlet extends HttpServlet   {    @Resource(name="java:comp/env/jdbc/TestDB")    DataSource datasource;  teniendo en cuenta importar el paquete: javax.annotation; Cualquiera de las dos opciones es válida. Adicionalmente, existe otra anotación muy útil sobre todo para los entornos de desarrollo locales que permite realizar la definición de los DataSources sin necesidad de tocar los ficheros de configuración de los Servidores de Aplicación Java EE. Es mediante la anotación @DataSourceDefinition que requiere importar el paquete: javax.annotation.sql; Nota: esta opción no está disponible en el servidor Apache Tomcat 7.0.x que utilizamos en este curso (que como recordaremos, no implementaba el 100% de las especificaciones Java EE, sola las relacionadas con la capa web), pero no obstante la comentamos: @DataSourceDefinition(name = "java:comp/env/jdbc/TestDB", className =  "org.apache.derby.jdbc.EmbeddedDriver", url =  "jdbc:derby:D:/biblioteca")  public class DataSourceServlet extends HttpServlet   {    @Resource(name=" java:comp/env/jdbc/TestDB ")    DataSource datasource; 

174

MÓDULO C – Unidad 7: Java Servlets Avanzado En este ultimo ejemplo, vemos como en el propio código realizamos la definición del DataSource. Los Servidores de Aplicación Java EE, al encontrar este código, dinámicamente crean el DataSource sin necesidad de haberlo definido en la configuración del servidor. Esta manera de definirlos está recomendada únicamente en los entornos locales de los desarrolladores, para facilitar y agilizar las pruebas. Pero no es la manera recomendada de configurarlos en los entornos reales de ejecución donde deberán ser los administradores los que decidan cómo configurarlos. El uso de Pool de Conexiones, siempre lleva relacionado temas de “tunning” (ajustes de la configuración para mejorar el rendimiento), pero este es un tema que trasciende el ámbito de este curso y que además es muy dependiente del Servidor de Aplicaciones Java EE que se esté utilizando. Pero si es interesante que recuerdes que es importante que los administradores del servidor realicen pruebas de carga y analicen cómo afecta al rendimiento de la aplicación el número máximo de conexiones disponible en el pool entre otros parámetros, decidiendo el valor óptimo en cada caso.

7.5

Filtros

Un filtro es un componente web más, que a diferencia de los que hemos visto hasta ahora no son invocados directamente. Son unos componentes que se despliegan como parte de la aplicación Web, y cuya misión es interceptar las peticiones y respuesta de un componente concreto para por ejemplo, realizar algún tipo de validación, algún tipo de auditoria, algún tipo de transformación, etc… Es decir, sin que el usuario lo sepa, antes y después de la ejecución de un componente web se ejecuta este nuevo componente. Un filtro de implementar el interface: javax.servlet.Filter que incluye tres métodos: 

void init(FilterConfig filterConfig) throws ServletException;

Se invoca una única vez en la vida del filtro y se utiliza para realizar las labores de inicialización. El parámetro del tipo javax.servlet.FilterConfig da acceso a cualquier atributo de configuración del filtro que se haya especificado en el descriptor de despliegue o en las anotaciones. 

void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws java.io.IOException, ServletException;

Es el método que realiza la lógica específica del filtro: auditoria, transformaciones, etc… A través del último parámetro del tipo javax.servlet.FilterChain podremos renviar la petición al siguiente filtro en la cadena si lo hubiera, o al componente web destino que estábamos filtrando. 

void destroy();

175

Nuevamente, se invoca una única vez en la vida del filtro y se utiliza para realizar las labores de limpieza y liberación de recursos si fuese necesario. Como vemos, es muy parecido a un Java Servlet con la diferencia de que no son invocados expresamente por la presentación, sino que se ejecutan cuando el componente web al que filtran es invocado. Desde la aparición de Java EE 6.0 existen dos maneras de declarar los filtros y asociarlos a unos componentes web determinados: el descriptor de despliegue y las anotaciones Java. Veamos primero cómo se definen y configuran en el descriptor de despliegue, el fichero web.xml Definimos el filtro a través del bloque “filter” con sus bloques “filter-name” y “filter-class”. Y configuramos qué componentes web filtra mediante el bloque “filter-mapping” con sus bloques “filter-name” y “url-pattern”. Por ejemplo:             DataSourceServlet      es.aulamentor.DataSourceServlet              DataSourceServlet      /DataSourceServlet          AuditoriaFilter      es.aulamentor.AuditoriaFilter            AuditoriaFilter    /*        En este ejemplo, además de un Java Servlet de un ejemplo anterior, tenemos un Filtro que se llama AuditoriaFilter implementado mediante la clase es.aulamentor.AuditoriaFilter que filtra (es decir, intercepta las peticiones) cualquier componente web de la aplicación. A través del patrón de URL, podríamos afinar un poco más el filtrado. Por ejemplo, si queremos que solo filtre los ficheros HTML, podríamos poner *.html en vez de /*, o /RequestServlet si lo que queremos es filtrar a ese Java Servlet o JavaServer Page concreta. Hay muchas posibilidades.

176

MÓDULO C – Unidad 7: Java Servlets Avanzado A continuación, vamos a ver el código fuente del filtro de este ejemplo, que se limita a escribir en consola la dirección IP que realiza la petición y a qué hora, y la hora en la que se envía la respuesta: package es.aulamentor;    import java.io.IOException;  import java.util.Calendar;    import javax.servlet.Filter;  import javax.servlet.FilterChain;  import javax.servlet.FilterConfig;  import javax.servlet.ServletException;  import javax.servlet.ServletRequest;  import javax.servlet.ServletResponse;    public class AuditoriaFilter implements Filter   {    public void init(FilterConfig fConfig) throws ServletException     {    }      public void doFilter(ServletRequest request, ServletResponse     response, FilterChain chain) throws IOException, ServletException     {      Calendar time = Calendar.getInstance();      System.out.println("Acceso desde IP: " + request.getRemoteAddr() +       " a las " + time.get(Calendar.HOUR) + ":" +  +         time.get(Calendar.MINUTE));        chain.doFilter(request, response);        System.out.println("Contestado a las " + time.get(Calendar.HOUR) +        ":" +  + time.get(Calendar.MINUTE));    }      public void destroy()     {    }  }  Es muy importante siempre realizar la llamada al siguiente miembro de la cadena (que puede ser otro filtro o el componente web final) mediante el método doFilter() del parámetro FilterChain. Aunque también existe la posibilidad de desviar la ejecución, invocando a otro componente web (por ejemplo de error) a través del RequestDispatcher como ya sabemos hacer. Es decir, que un filtro puede decidir en un momento dado interrumpir la ejecución normal de la petición y desviarla por el motivo que sea a otro componente. La ejecución en el entorno de desarrollo debería mostrar algo así:

177

Como mencionamos, desde Java EE 6.0 también existe la opción de obviar el descriptor de despliegue y utilizar anotaciones Java para las definiciones y configuraciones. En este caso, usaremos la anotación @WebFilter con sus atributos “filterName” y “urlPatterns”: package es.aulamentor;    import java.io.IOException;  import java.util.Calendar;    import javax.servlet.Filter;  import javax.servlet.FilterChain;  import javax.servlet.FilterConfig;  import javax.servlet.ServletException;  import javax.servlet.ServletRequest;  import javax.servlet.ServletResponse;  import javax.servlet.annotation.WebFilter;    @WebFilter(filterName="AuditoriaFilter", urlPatterns={"/*"})  public class AuditoriaFilter implements Filter   {    public void init(FilterConfig fConfig) throws ServletException     {    }      public void doFilter(ServletRequest request, ServletResponse   178

MÓDULO C – Unidad 7: Java Servlets Avanzado   response, FilterChain chain) throws IOException, ServletException     {      Calendar time = Calendar.getInstance();      System.out.println("Acceso desde IP: " + request.getRemoteAddr() +         " a las " + time.get(Calendar.HOUR) + ":" +  +       time.get(Calendar.MINUTE));        chain.doFilter(request, response);          System.out.println("Contestado a las " + time.get(Calendar.HOUR) +       ":" +  + time.get(Calendar.MINUTE));    }      public void destroy()     {    }  }  El resultado debería ser el mismo. En casos de que existiese más de un filtro, y que además filtrasen al mismo componente web, su ejecución se realizaría en el orden en el que fueron definidos.

7.6

Mantenimiento del estado del cliente

El protocolo HTTP es un protocolo sin estado, es decir, cada petición que se recibe en el servidor de un mismo cliente se recibe como si fuese la primera petición que hace. Es decir, no hay constancia de que ya se hubiese conectado antes y hubiera solicitado una acción. Este es un inconveniente importante. Supone por ejemplo, que aunque un cliente ya se hubiera autenticado con el sistema, como la próxima petición parece una petición nueva pediría autenticarse de nuevo. O que un cliente que mediante una petición anterior movió un producto al carrito de la compra en una aplicación de comercio electrónico, en la siguiente petición el carrito aparece vacío. Por suerte, el protocolo HTTP contempla la posibilidad de almacenar en el lado cliente información del servidor, de manera que dicha información viaje a partir de entonces en cada nueva petición, y tanto la aplicación Web como el Servidor de Aplicaciones Java EE puedan usarla para recordar al cliente. Esta información que se puede almacenar en el lado cliente recibe el nombre de Cookie.

7.6.1 Cookies Básicamente, una Cookie es una pareja formada por una clave y un valor que contiene información textual. Es decir, tiene un nombre que identifica la Cookie y un valor asociado, junto con alguna información relacionada adicional que ahora comentaremos sobre cuándo caduca, quién la creó, quién la puede ver, etc…

179

El hecho de que se puedan crear desde el servidor, es decir, desde una aplicación web, las hace muy útiles para poder “recordar” los clientes y evitar interacciones redundantes, pérdidas de información y similares. Normalmente (a no ser que tengamos el navegador configurado para evitarlas) en nuestro navegador tendremos decenas de Cookies guardadas sin que fuéramos conscientes de ello. Por ejemplo, si utilizas Mozilla Firefox ves a la opción de menú “Firefox” -> “Options” -> “Options”:

En la opción “Privacy”, selecciona “Use custom settings for history” en la sección “history”, y entonces pulsa el botón “Show Cookies…”:

180

MÓDULO C – Unidad 7: Java Servlets Avanzado

Te sorprenderá ver todas las que tienes (incluyendo Cookies de Aula Mentor):

181

En el caso de Internet Explorer, es un poco más complicado. Ir a la opción de menú “tools” > “Internet Options”:

Pulsar el botón “Settings” de la sección “Browsing history”:

182

MÓDULO C – Unidad 7: Java Servlets Avanzado

Y en la nueva ventana, pulsar el botón “View files”:

183

Se abrirá el explorador de archivos, y tendremos que buscar todos aquellos que empiezan por Cookie:

184

MÓDULO C – Unidad 7: Java Servlets Avanzado

Bien, veamos qué información guarda una Cookie antes de meternos con el API Java para crearlas y acceder a ellas desde nuestras aplicaciones: 

Nombre: Identificador de la Cookie para poder ser accedida.



Contenido: La información en modo texto que guarda.



Servidor (o Host): Servidor que creo la Cookie.



Ruta (o Path): Dentro de ese Servidor, a qué rango de URLs les mandará el navegador la Cookie (un / significa que a todas).



Segura: Indica si debe ser enviada exclusivamente a través de conexiones seguras (HTTPS).



Caducidad: Indica la fecha en la que caduca y por tanto es borrada. Se puede indicar en vez de una fecha, que se borre cuando se cierre el navegador. 185

Las Cookies están implementadas en Java por la clase: javax.servlet.http.Cookie; Las

Cookies

ya

existentes

son

accesibles

a

través

de

la

petición

(javax.servlet.http.HttpServletRequest) mediante el método: Cookie[] getCookies(); Y

las

nuevas,

una

vez

creadas

se

deben

incluir

en

la

respuesta

(javax.servlet.http.HttpServletResponse) mediante el método: void addCookie(Cookie cookie); Para crear una Cookie nueva utilizaremos su constructor, pasándole la información que ya hemos comentado: public Cookie(java.lang.String name, java.lang.String value); A su vez, la clase Cookie tiene una serie de métodos para acceder o establecer los distintos valores que hemos comentado. Lo más sencillo es verlo en un ejemplo. Vamos a desarrollar una aplicación web, que implementa un contador de visitas por parte de un mismo cliente independientemente de que cerremos el navegador mediante el uso de una Cookie: <%@ page language="java" contentType="text/html; charset=ISO‐8859‐1"  pageEncoding="ISO‐8859‐1"%>              <META http‐equiv="Content‐Type" content="text/html; charset=ISO‐      8859‐1">                    <%        Cookie cookie = null;    Cookie[] cookies = request.getCookies();    if(cookies != null)    {      for(int i=0; i
MÓDULO C – Unidad 7: Java Servlets Avanzado   response.addCookie(cookie);      %>        Número de veces visitada esta página: <%= cookie.getValue() %>         Al ejecutar la aplicación desde un navegador y recargar (o refrescar) la página varias veces, veremos que el contador sigue contando donde se quedó. Es mas, si paramos el servidor y cerramos el navegador y volvemos a rearrancar todo, el contador debería seguir por donde iba también. Sin embargo, si utilizamos otro navegador distinto o el mismo pero desde otra máquina de nuestra red, veremos que el contador comienza en cero porque ese navegador no tiene la Cookie guardada.

Y si le pedimos al navegador que nos muestre todas las Cookies que tiene (filtramos por CONTADOR) veremos todos los datos de nuestra Cookie.

187

Hay varios puntos importantes que tener presentes de este ejemplo:  Por defecto, el tiempo de expiración de la Cookie es el de la vida del navegador (tiene el mismo efecto asignarle un valor negativo), es decir, cuando este se cierra se borra. Asignarle un valor de cero borraría inmediatamente la Cookie. Y asignarle cualquier otro valor positivo. es la nueva vida de la Cookie en segundos. En nuestro ejemplo, hemos establecido que sea una semana tras cada uso.  Cada vez que se modifica algo de la Cookie, hay que añadirla de nuevo a la respuesta. Si no se añade, la Cookie sigue con los valores antiguos porque la respuesta contiene una copia de la Cookie recibida y no una referencia.  Por defecto, la ruta (o path) del servidor al que el navegador mandará la Cookie es el de la aplicación que creo la Cookie. En nuestro caso, /EjemplosWeb/. Si el navegador conecta con otra aplicación en otra ruta o en otro servidor, la Cookie no se enviará. Aunque el ejemplo que hemos utilizado para presentar las Cookies es muy simple, la potencia de esta tecnología es inmensa cuando pensamos en empresas de comercio electrónico, de marketing, etc… Todas ellas llenan nuestro navegador de Cookies con identificadores que les permiten a nuestro regreso recordar nuestros gustos, lo último que hicimos en su aplicación, etc…

7.6.2 Sesión HTTP Las Cookies por tanto, son un mecanismo muy potente para poder recordar al usuario y actuar en consecuencia. Pero tiene algunos inconvenientes técnicos como el hecho de solo 188

MÓDULO C – Unidad 7: Java Servlets Avanzado poder albergar 4Kb de información y que dicha información solo puede ser textual no muy estructurada (recordemos que el valor en una Cookie es una simple cadena de caracteres). Adicionalmente, no son muy seguras. Los usuarios pueden ver el contenido, pueden borrarlas e incluso pueden modificarlas con mínimos conocimientos de informática. Por este motivo, aunque basándose en la existencia de las Cookies, las especificaciones Java EE definieron un mecanismo de persistencia en el servidor denominado Sesión HTTP (o HTTP Session). Todos los Servidores de Aplicación Java EE implementan este servicio. La sesión HTTP es una zona de almacenaje en el servidor exclusiva de cada cliente, donde las aplicaciones pueden dejar información para ser utilizada en sucesivas peticiones del mismo cliente. Cada vez que se recibe una petición, el servidor analiza las cabeceras HTTP del mensaje en busca de una Cookie que incluya un identificador de sesión para ponerla a disposición de la aplicación.

Normalmente

dicha

Cookie

se

llama

JSESSIONID

y

es

gestionada

automáticamente por el servidor. Las aplicaciones manejarán la Sesión HTTP desde un punto de vista funcional, los detalles técnicos de su mantenimiento quedan cubiertos por el servicio ofrecido por el servidor. La Sesión HTTP implementa el interface: javax.servlet.http.HttpSession; Es accesible desde la petición HTTP mediante el método: HttpSession getSession(); que nos devolverá una referencia a la sesión de este cliente si ya existiese o a una nueva creada en este instante y asignada a este cliente. Existe otra opción, que es el método: HttpSession getSession(boolean create); La diferencia con el anterior, es que este recibe un boolean como parámetro. Si le mandamos “true”, en caso de no existir sesión para este cliente nos devuelve la referencia a una nueva. Si le mandamos “false”, nuevamente en caso de no existir, esta vez no la crea y devuelve null. Técnicamente la implementación de la Sesión HTTP es una especia de colección al estilo de las Hashtables y HashMaps. Es decir, es una colección en la que se guardan parejas de clave y valor, teniendo que ser ambas del tipo java.lang.Object (es decir, tipos complejos). Tiene distintos métodos, pero los más usados son:  java.lang.Object getAttribute(java.lang.String name); Devuelve el valor de un atributo concreto.  java.util.Enumeration getAttributeNames(); 189

Devuelve una colección con el nombre de todos los atributos que contiene.  void setAttribute(java.lang.String name, java.lang.Object value); Guarda un atributo con su valor.  void removeAttribute(java.lang.String name); Elimina un atributo.  void invalidate(); Elimina la sesión del servidor. Recordemos que su creación no se realiza a través de un constructor sino simplemente pidiéndosela a la petición HTTP. Los Servidores de Aplicación Java EE, implementan un sistema de expiración de sesiones inactivas. El motivo es que la sesión consume recursos y no se puede garantizar ni que la aplicación web implemente un sistema de limpieza (invocando el método invalidate() cuando un usuario termine de trabajar con la aplicación), ni que el usuario de las aplicación web siempre termine de manera ordenada la aplicación invocando la petición de limpieza (por ejemplo, un logout) en vez de cerrar el navegador directamente. Sin este sistema de expiración, podríamos terminar con “infinitas” sesiones huérfanas en el servidor. Este tiempo de expiración, es un parámetro de configuración propio de cada servidor. En el caso de Apache Tomcat 7.0.x se realiza en el fichero de configuración /conf/web.xml que por defecto viene con media hora de tiempo:     30    Todos los objetos que se guarden en la sesión, deben ser serializables (es decir, implementar java.io.Serializable). El motivo es que los Servidores de Aplicación Java EE, normalmente implementan mecanismos de persistencia de las sesiones para facilitar mecanismos de balanceo de carga y tolerancia a fallos, para liberar recursos de memoria, etc.. y si el contenido no es serializable no lo puede guardar. Como buena práctica, la información guardada en la Sesión HTTP debe de ser lo más pequeña posible. Veamos un ejemplo similar al que mostramos con las Cookies, pero en esta ocasión añade un botón para invalidar la sesión y comprobar como se pierde la información del contador y comienza de nuevo en uno. <%@ page language="java" contentType="text/html; charset=ISO‐8859‐1"  pageEncoding="ISO‐8859‐1"%>              <META http‐equiv="Content‐Type" content="text/html; charset=ISO‐      8859‐1">        190

MÓDULO C – Unidad 7: Java Servlets Avanzado             <%        HttpSession sesion = request.getSession(true);        int cont = 1;        boolean isInvalidate = false;            if(request.getParameter("invalidate") != null &&         request.getParameter("invalidate").equals("true"))        {          sesion.invalidate();          isInvalidate = true;        }        else        {          if(sesion.getAttribute("CONTADOR") != null)          {            cont =             ((Integer)sesion.getAttribute("CONTADOR")).intValue();          }          sesion.setAttribute("CONTADOR", new Integer(cont+1));        }      %>                            <%            if(!isInvalidate)            {          %>                          Número de veces visitada esta página: <%= cont %>                      <%            }          %>                          Invalidar sesión:                                                                             Al ejecutar el ejemplo desde un navegador externo, deberíamos ver algo así:

191

Y si le pedimos al navegador que nos muestre todas las Cookies que tiene (filtramos por localhost) veremos la Cookie JSESSIONID que el Servidor de Aplicaciones Java EE ha creado para gestionar la Sesión HTTP.

Si invalidamos la sesión mediante la checkbox, además de comprobar que el contador se resetea porque su valor se pierde al destruirse la sesión, podremos comprobar como la 192

MÓDULO C – Unidad 7: Java Servlets Avanzado Cookie JSESSIONID desaparece. De igual modo, si seguimos ejecutando el ejemplo creando una nueva sesión, el valor de la Cookie (el identificador de la sesión en el servidor) cambiará. Otro tema importante a tener en cuenta, es que la Cookie con el identificador de la Sesión HTTP caduca con la vida del navegador, es decir, si cerramos el navegador, al abrirlo de nuevo y solicitar la aplicación, se crea una sesión nueva. Da igual que no la hubiéramos invalidado antes de cerrar. Posiblemente cuando entremos de nuevo en el servidor, siga existiendo la anterior que todavía no habrá caducado por el tiempo máximo de inactividad pero ya no está relacionada con ningún cliente (está huérfana). Esta es una desventaja importante frente a las Cookies, ya que en las Cookies controladas por nuestra aplicación, la expiración era controlable. Por eso, normalmente un carrito de la compra, se implementa mediante la Sesión HTTP porque no tiene sentido que permanezca tras haber realizado una compra. Mientras que los gustos o preferencias de un cliente se controlan con una Cookie para que perdure entre compras (normalmente se mantiene un identificador de algún registro en Base de Datos donde se han ido almacenando todas la navegaciones del cliente por la tienda). Indicar que en ambos dos casos, las Cookies son utilizadas. En el primer caso la Cookie guarda toda la información del estado del cliente que queremos mantener, mientras que en la segunda guarda solamente el identificador de la Sesión HTTP del servidor que guarda la información que queremos mantener de cada cliente.

7.7

Gestión de eventos

Las especificaciones Java EE definen una serie de notificación de eventos a los que las aplicaciones web se pueden suscribir para ser notificadas de cuándo dichos eventos ocurren. El funcionamiento de la gestión de eventos en las aplicaciones web funciona igual que en las aplicaciones visuales de escritorio (AWT/Swing). Es decir, siguen más o menos el siguiente diagrama:

193

Básicamente, contamos con dos piezas fundamentales. Un notificador (Notifier), que es quién generará los eventos, y un escuchador (Listener) que es quien está interesado en dichos eventos para reaccionar y actuar en consecuencia. Para que un escuchador, pueda escuchar los eventos de un notificador, ha de subscribirse a estos. En caso de estar subscrito, el notificador, cuando ocurra el evento, se lo notificará al escuchador. En Java, esto significa enviar un mensaje concreto al escuchador (ejecutar un método concreto). El mecanismo que tenemos en Java de poder garantizar que el escuchador implementa dichos métodos, es forzándole a implementar un interfaz. Y esto lo consigue mediante el API del método de subscripción, que solo permite recibir parámetros de un tipo concreto. Luego el escuchador interesado ha de ser de dicho tipo para poder subscribirse. Un escuchador, igual que se subscribe, puede finalizar la subscripción. Los notificadores pasan la información a los escuchadores invocando un método concreto como ya hemos comentado, pasándole como parámetro un evento que encapsula toda la información necesaria para conocer lo que ha ocurrido. Los eventos contienen información sobre lo que ha ocurrido, accesible a través de distintos métodos. Ahora bien, existe una diferencia muy importante de operativa con las aplicaciones Java SE (visuales de escritorio), y es que en Java EE no hay que invocar un método para suscribirse una familia de eventos (addXXXListener), sino que basta con:

194



O informar de quién es el escuchador en el descriptor de despliegue.



O utilizar una anotación Java en el código del escuchador.

MÓDULO C – Unidad 7: Java Servlets Avanzado Adicionalmente, no hay forma de finalizar la subscripción (removeXXXListener) como ocurre con las aplicaciones visuales. Pero por lo demás, el mecanismo de funcionamiento es el mismo. Antes de ver código, vamos a revisar las familias de eventos que existen con sus métodos. En concreto, existen tres familias de eventos:  Relacionadas con el Contexto del Java Servlet: por ejemplo, cuándo se arranca o se para la aplicación.  Relacionadas con la petición: por ejemplo, cuándo se comienza a procesar una petición.  Relacionadas con la Sesión HTTP: por ejemplo, cuándo se invalida una sesión. Los tipos de eventos que existen son los siguientes: javax.servlet.ServletContextEvent

Cuando se arranca o para una aplicación web.

javax.servlet.ServletContextAttributeEvent

Cuando se crea, modifica o elimina un atributo del contexto del Java Servlet.

javax.servlet.http.HttpSessionEvent

Cuando se crea o se destruye una sesión. También cuando se persiste y elimina de la memoria, y cuando se restaura de nuevo en memoria.

javax.servlet.http.HttpSessionBindingEvent

Cuando se añade, modifica o eliminan atributos de la sesión. También cuando un objeto ha sido añadido o eliminado de la sesión.

javax.servlet.ServletRequestEvent

Cuando se inicializa o destruye una petición.

javax.servlet.ServletRequestAttributeEvent

Cuando se añade, modifica o elimina un atributo de la petición.

A continuación añadiremos una tabla con un listado de todos los interfaces que hay para cada una de las familias de eventos que hemos visto, y sus métodos:

javax.servlet.ServletContextListener

contextDestroyed contextInitialized attributeAdded

javax.servlet.ServletContextAttribute

attributeRemoved attributeReplaced

javax.servlet.http.HttpSessionActivationListener

javax.servlet.http.HttpSessionBindingListener

sessionDidActivate sessionWillPassivate valueBound valueUnbound

195

attributeAdded javax.servlet.http.HttpSessionAttributeListener

attributeRemoved attributeReplaced

javax.servlet.ServletRequestListener

requestDestroyed requestInitialized attributeAdded

javax.servlet.ServletRequestAttributeListener

attributeRemoved attributeReplaced

No nos detendremos en explicar uno a uno cada método. El API Java EE esta disponible en la web, así que no lo reproduciremos por completo aquí. Veamos eso si, cómo se suscribe una clase a un notificador mediante el descriptor de despliegue y mediante anotaciones Java: 

Mediante descriptor de despliegue. Utilizaremos el bloque “listener” con su bloque “listener-class”:           es.aulamentor.EjemploListener         Y la clase es.aulamentor.EjemploListener ya implementará los interfaces necesarios para las acciones que quiera escuchar.



Mediante anotaciones Java (recordemos que esta opción solo está disponible desde Java EE 6.0). Utilizaremos la anotación @Weblistener import javax.servlet.annotation.WebListener;    @WebListener  public class EjemploListener implements  Y la clase es.aulamentor.EjemploListener ya implementará los interfaces necesarios para las acciones que quiera escuchar.

Veamos un ejemplo que escucha todos los eventos posibles, y muestra por consola una línea por cada evento que ha ocurrido. Lo ejecutaremos junto con la aplicación que demostraba el uso de la Sesión HTTP para ver qué eventos se van lanzando: package es.aulamentor;    import javax.servlet.ServletContextAttributeEvent;  import javax.servlet.ServletContextAttributeListener;  import javax.servlet.ServletContextEvent;  import javax.servlet.ServletContextListener;  import javax.servlet.ServletRequestAttributeEvent;  import javax.servlet.ServletRequestAttributeListener;  import javax.servlet.ServletRequestEvent;  196

MÓDULO C – Unidad 7: Java Servlets Avanzado import javax.servlet.ServletRequestListener;  import javax.servlet.annotation.WebListener;  import javax.servlet.http.HttpSessionActivationListener;  import javax.servlet.http.HttpSessionAttributeListener;  import javax.servlet.http.HttpSessionBindingEvent;  import javax.servlet.http.HttpSessionBindingListener;  import javax.servlet.http.HttpSessionEvent;  import javax.servlet.http.HttpSessionListener;    @WebListener  public class EjemploListener implements ServletContextListener,  ServletContextAttributeListener, HttpSessionListener,  HttpSessionAttributeListener, HttpSessionActivationListener,  HttpSessionBindingListener, ServletRequestListener,  ServletRequestAttributeListener   {    public void requestDestroyed(ServletRequestEvent ev)     {      System.out.println("Se ha invocado requestDestroyed...");    }      public void attributeAdded(HttpSessionBindingEvent ev)     {      System.out.println("Se ha invocado attributeAdded...");    }      public void contextInitialized(ServletContextEvent ev)     {      System.out.println("Se ha invocado contextInitialized...");    }      public void sessionDidActivate(HttpSessionEvent ev)     {      System.out.println("Se ha invocado sessionDidActivate...");    }      public void valueBound(HttpSessionBindingEvent ev)     {      System.out.println("Se ha invocado valueBound...");    }      public void attributeAdded(ServletContextAttributeEvent ev)     {      System.out.println("Se ha invocado attributeAdded...");    }      public void attributeRemoved(ServletContextAttributeEvent ev)     {      System.out.println("Se ha invocado attributeRemoved...");    }      public void sessionDestroyed(HttpSessionEvent ev)     {      System.out.println("Se ha invocado sessionDestroyed...");    }      public void attributeRemoved(HttpSessionBindingEvent ev)     {      System.out.println("Se ha invocado attributeRemoved...");    }    197

  public void attributeAdded(ServletRequestAttributeEvent ev)     {      System.out.println("Se ha invocado attributeAdded...");    }      public void valueUnbound(HttpSessionBindingEvent ev)     {      System.out.println("Se ha invocado valueUnbound...");    }      public void sessionWillPassivate(HttpSessionEvent ev)     {      System.out.println("Se ha invocado sessionWillPassivate...");    }      public void sessionCreated(HttpSessionEvent ev)     {      System.out.println("Se ha invocado sessionCreated...");    }      public void attributeReplaced(HttpSessionBindingEvent ev)     {      System.out.println("Se ha invocado attributeReplaced...");    }      public void attributeReplaced(ServletContextAttributeEvent ev)     {      System.out.println("Se ha invocado attributeReplaced...");    }      public void attributeRemoved(ServletRequestAttributeEvent ev)     {      System.out.println("Se ha invocado attributeRemoved...");    }      public void contextDestroyed(ServletContextEvent ev)     {      System.out.println("Se ha invocado contextDestroyed...");    }      public void attributeReplaced(ServletRequestAttributeEvent ev)     {      System.out.println("Se ha invocado attributeReplaced...");    }      public void requestInitialized(ServletRequestEvent ev)     {      System.out.println("Se ha invocado requestInitialized...");    }  }  La ejecución en el entorno de desarrollo debería mostrar algo así:

198

MÓDULO C – Unidad 7: Java Servlets Avanzado

199

200

PARA RECORDAR

 La información de configuración de un Java Servlet que es recogida mediante el método getInitParameter del parámetro javax.servlet.ServletConfig, que es pasado al método init del Java Servlet. Para pasar dicha información, el administrador puede hacerlo en el despliegue de la aplicación o el desarrollador puede hacerlo en el descriptor de despliegue o mediante anotaciones.

 Aunque el servidor de aplicaciones Java EE permite y posibilita la concurrencia en las llamadas a un Java Servlet, hay que tener cuidado con la definición de atributos o código que no se quiera que sea multithread.

 Hemos visto dos alternativas de acceso a Bases de datos:  Acceso directo desde el código. Su principal problema es su pobre rendimiento.  Acceso a través de un Pool de conexión, siendo esta la recomendada para las aplicaciones

Java

EE.

El

método

utilizado

es

el

getConnection

de

javax.sql.DataSource

 Los filtros son unos componentes que se despliegan como parte de la aplicación Web, y cuya misión es interceptar las peticiones y respuesta de un componente concreto para por ejemplo, realizar algún tipo de validación, algún tipo de auditoria, algún tipo de transformación, etc…

 Un filtro de implementar el interface: javax.servlet.Filter que incluye tres métodos: 

init: Se invoca una única vez en la vida del filtro y se utiliza para realizar las labores de inicialización.



doFilter: Es el método que realiza la lógica específica del filtro: auditoria, transformaciones, etc…



destroy: Se invoca una única vez en la vida del filtro y se utiliza para realizar las labores de limpieza y liberación de recursos si fuese necesario.

201

 Para el mantenimiento del estado del cliente en el servidor, se pueden utilizar:  Cookies: es información formada por una clave y un valor que contiene información textual. Esta cookie es creada en el servidor de aplicaciones y almacenada en el navegador cliente utilizado en las llamadas a la aplicación web.  Sesión HTTP: Es una zona de almacenaje en el servidor exclusiva de cada cliente, donde las aplicaciones pueden dejar información para ser utilizada en sucesivas peticiones del mismo cliente.

 Las especificaciones Java EE definen una serie de notificación de eventos a los que las aplicaciones web se pueden suscribir para ser notificadas de cuándo dichos eventos ocurren. Contamos con dos piezas fundamentales:  Un notificador (Notifier), que es quién generará los eventos  Un escuchador (Listener) que es quien está interesado en dichos eventos para reaccionar y actuar en consecuencia.

 En concreto, existen tres familias de eventos:  Relacionadas con el Contexto del Java Servlet  Relacionadas con la petición  Relacionadas con la Sesión HTTP

202

Unidad de Aprendizaje 8

JAVASERVER PAGES AVANZADO

ÍNDICE 8.1

Introducción ................................................................. 205

8.2

Etiquetas JSP estándar .............................................. 205

8.3

Lenguaje de Expresiones JSP (EL) ........................... 208

8.4

Librerías de etiquetas JSP estándar......................... 211 8.4.1 Core ................................................................................214 8.4.2 XML.................................................................................215 8.4.3 I18N.................................................................................215 8.4.4 Database ........................................................................216 8.4.5 Functions........................................................................217

8.5

Librerías de etiquetas JSP personalizadas.............. 218

PARA RECORDAR.................................................................. 224

MÓDULO C – Unidad 8: JavaServer Pages Avanzado

8.1

Introducción

A menudo, en el desarrollo de aplicaciones web de una cierta envergadura, existen equipos de desarrollo con roles y skills diferentes. Así, nos encontraremos con desarrolladores expertos en Java que se encargarán normalmente del modelo y controlador, mientras que tendremos otro grupo de desarrolladores expertos en diseño que se encargarán de la presentación. Estos expertos en diseño, no suelen conocer ni manejar el lenguaje Java, centrando sus skills más en diseño gráfico, tratamiento de imágenes, etc… por lo que al desarrollar la presentación emplearán herramientas más orientadas a etiquetas que a programar con el lenguaje Java. Por este motivo, la especificación de JavaServer Pages (JSP) define una serie de mecanismos para seguir permitiendo el desarrollo de la presentación sin necesidad de escribir líneas de lenguaje Java. Estos mecanismos son: 

Las acciones JSP estándar.



Las librerías de etiquetas JSP

Esta unidad se centra en el estudio de ambos mecanismos.

8.2

Etiquetas JSP estándar

Las etiquetas JSP estándar, son etiquetas del estilo de las empleadas en las páginas HTML o en los descriptores de despliegue (XML) que permiten realizar acciones en el momento de ejecución de la página. Cualquier etiqueta JSP podría ser sustituida sin ningún problema por código Java equivalente como ya hicimos en unidades anteriores. La sintaxis de una etiqueta JSP consiste en el prefijo “jsp:” seguido del identificador de la acción y opcionalmente atributos (parejas de nombre y valor). Las especificaciones definen múltiples etiquetas JSP estándar, a saber: 

: redirige la petición a otra página JSP, HTML o Java Servlet.



: incluye el resultado de otra página JSP, Java Servlet u otro componente web estático.



: se utiliza dentro de un bloque de o para indicar los parámetros que opcionalmente se pueden enviar.



: referencia o instancia una clase Java y la asocia un nombre y un ámbito concreto.



: inserta un valor a un atributo del bean (o clase Java).



: recoge el valor de un atributo del bean (o clase Java) y lo incluye en la respuesta 205



: inserta texto en la respuesta.



: inserta un elemento XML en la respuesta.



: inserta un Applet Java en la respuesta.



: inserta la etiqueta XML DOCTYPE de toda JSP en la respuesta.



: identifica el comienzo del cuerpo del documento HTML (viene a sustituir a ). Se ha de utilizar siempre que en la página se utilice la acción .



Otras: , , , , …

Son muchas las etiquetas pero trataremos solo algunas de ellas porque en general, a excepción de unas pocas, su uso es muy raro. La etiqueta produce un efecto exactamente igual que el de la directiva <%@ include file=”xxx” %> que ya hemos visto y practicado en alguna actividad durante el curso. La diferencia es que el atributo que necesita se llama “page”. Algunos ejemplos:               Y la etiqueta es parecida a con la diferencia de que no incluye el resultado, sino que delega en ese nuevo recurso la respuesta. Algunos ejemplos:             Otra etiqueta típica es la de referenciar o instanciar una clase Java para trabajar con ella. Como vimos en la enumeración de etiquetas existentes, la etiqueta a emplear es . Esta etiqueta busca un objeto con el identificador dado en el ámbito seleccionado y de no encontrarlo, lo crea con dicho identificador en dicho ámbito. Utiliza por tanto estos tres atributos:

206



id: identificador del objeto.



scope: ámbito donde buscar o crearlo. Existen cuatro valores posibles: o

request: la petición.

o

page: la página:

o

session: la sesión HTTP.

MÓDULO C – Unidad 8: JavaServer Pages Avanzado o 

application: la aplicación.

class: la clase Java (el tipo).

Por ejemplo:    Esta etiqueta busca en la sesión HTTP un objeto de la clase edu.aulamentor.Cesta que se llama cesta. Si no existiera lo crea. ¿Y esto para qué? Pues normalmente va a acompañado de las etiquetas y para utilizar el objeto en cuestión. nos permite establecer el valor de alguno de los atributos del objeto. Para ello utiliza tres atributos: 

name: identificador del objeto.



attribute: atributo del objeto.



value: valor del atributo del objeto.

Por ejemplo:     De igual forma, podemos acceder al valor de un atributo del objeto mediante la acción . Para ello utiliza dos atributos: 

name: identificador del objeto.



attribute: atributo del objeto.

Por ejemplo: Total de la cesta es:    Para que estas etiquetas funcionen bien, la clase Java debe seguir las especificaciones JavaBean. Esto significa que, entre otras cosas, la clase debe tener un constructor por defecto (constructor sin parámetros) y un getter/setter por cada atributo (siguiendo la norma de utilizar get y set seguido del nombre del atributo con la primera letra en mayúsculas). Es decir, en nuestro ejemplo: package es.aulamentor;    public class Cesta  {    private double total;      public Cesta()    {    }    207

  public double getTotal()    {      return this.total;    }      public void setTotal(double param)    {      this.total = param;    }  }  Simplemente por comparar, este mismo ejemplo pero con código Java habría sido algo así: <%    es.aulamentor.Cesta cesta =     (es.aulamentor.Cesta)session.getAttribute(“cesta”);    cesta.setTotal(0.0);  %>  Total de la cesta es: <%= cesta.getTotal() %> Pero la etiqueta puede tener un uso más potente todavía, y es el de transferir el valor de los parámetros de un formulario que se reciba en una petición a los atributos de un objeto Java sin necesidad de ir uno a uno. Basta con eliminar el atributo value:      En este caso, el servidor va a buscar todos (porque hemos usado el carácter * en vez de un nombre concreto) aquellos parámetros que vengan en la petición que se llamen igual que algún atributo de la clase Cesta y ponerle su valor.

8.3

Lenguaje de Expresiones JSP (EL)

Conocido con el acrónimo EL (Expression Language). EL es un pseudolenguaje para identificar y acceder de una manera muy sencilla a las variables. Veamos primero un ejemplo con el que se verá rápidamente la idea. Mediante código Java, para acceder por ejemplo al atributo nombre, de un objeto de tipo Perro guardado en un atributo llamado perro en un objeto de tipo Persona que está guardado en la Sesión HTTP con el identificador de persona escribiríamos algo así: Se llama: <%=  ((es.aulamentor.Persona)session.getAttribute(“persona”)).getPerro().getN ombre() %>  Sin embargo, utilizando EL sería algo así: Se llama: ${persona.perro.nombre}  Sencillo, ¿verdad?

208

MÓDULO C – Unidad 8: JavaServer Pages Avanzado La sintaxis y opciones de EL son realmente sencillas. Ahora, es muy importante no pensar en Java cuando usemos EL y viceversa, porque aunque se parecen son distintos y nos llevarán a equivocaciones. Las expresiones EL siempre van entre llaves ({ }) precedidas del símbolo del dólar ($): ${   }  El contenido de las llaves siempre será uno o varios identificadores separados por puntos. El primer identificador puede ser dos cosas: 

Una referencia a un objeto implícito: que existe en el contenedor web y es accesible directamente.



Un atributo existente en uno de los distintos ámbitos: página, petición, sesión o aplicación. Es importante tener en cuenta que se busca en ese orden, por si existiese más de un atributo con el mismo nombre en ámbitos diferentes.

Todos los objetos implícitos son una colección del tipo Map, es decir, contiene parejas de clave y valor. Estos son los que hay: 

pageScope: ámbito de la página.



requestScope: ámbito de la petición.



sessionScope: ámbito de la sesión.



applicationScope: ámbito de la aplicación.



param: parámetros de la petición.



paramValues: parámetros de la petición en caso de que el parámetro sea a su vez una colección.



header: cabeceras de la petición.



headerValues: cabeceras de la petición en caso de que la cabecera sea a su vez una colección.



cookie: cookies de la petición.



initParam: parámetros del contexto.



pageContext: es el único que no es un Map. Directamente es una referencia a una instancia de la clase javax.servlet.jsp.PageContext

Por tanto, si queremos referenciar al atributo persona que está en la Sesión HTTP tenemos dos opciones: ${persona}  o para evitar colisiones en el caso de que existiese otro atributo con el mismo nombre en ámbitos con mayor precedencia: 209

${sessionScope.persona}  Ahora, si queremos seguir profundizando en el atributo, accediendo a otros atributos más internos en su estructura (como el ejemplo anterior donde accedimos al nombre del perro de la persona), es cuando utilizaremos una secuencia de nombres de atributos separados por puntos: ${sessionScope.persona.perro.nombre}  Ahora bien, llegados a este punto es importante volver a recordar, que esto solo funciona si las clases Java accedidas siguen las especificaciones JavaBean, que entre otras cosas obligan a que: 

La clase tenga un constructor por defecto (sin parámetros).



La clase tenga un método getter por cada atributo siguiendo la regla de que se llamara get seguido del nombre del atributo con la primera letra en mayúscula.



La clase tenga un método setter por cada atributo siguiendo la regla de que se llamara set seguido del nombre del atributo con la primera letra en mayúscula.

Por tanto, para que funcione el ejemplo: ${sessionScope.persona.perro.nombre}  significa que la clase Persona tiene un método que se llama getPerro() y que la clase Perro tiene un método que se llama getNombre(). Si esto no fuese así, la compilación de la página JSP fallaría. Veamos otro ejemplo de cómo sería el acceso al valor de una Cookie. Usando Java sería algo así: <%  Cookie[] cookies = request.getCookies();  for(int i=0; i      <%= cookies[i].getValue() %>  <%    }  }  %> Con EL sería simplemente esta línea: ${cookie.nombreUsuario.value}  Las expresiones EL también admiten el uso de corchetes ([]). Su uso vale para dos cosas:

210

MÓDULO C – Unidad 8: JavaServer Pages Avanzado 

Lo

mismo

que

el

punto,

es

decir,

${perro.nombre}

es

equivalente

a

${perro[“nombre”]} usando las comillas dobles para especificar el nombre del atributo. 

Para profundizar en atributos que son de algún tipo de colección (array, Map o List), por ejemplo: ${perros[3].nombre}

Las expresiones EL también permiten implementar una mínima lógica, aunque no está recomendado su uso para ello. Soporta los operadores aritméticos (+, -, *, / y %), los operadores lógicos (&&, || y !) y los operadores relacionales (==, ¡=, <, >, <= y >=). Otro dato a tener muy en cuenta es que las expresiones EL pueden ser usadas como valores de los atributos de las etiquetas JSP que ya hemos comentado en la sección anterior y en las que comentaremos a continuación.

8.4

Librerías de etiquetas JSP estándar

Al igual que existen las etiquetas JSP estándar definidas en las especificaciones JSP, con el tiempo surgió otra especificación denominada JSTL (JavaServer Page Standard Tag Library o Librería de etiquetas JSP estándar) que aglutina una serie de librerías de etiquetas o acciones adicionales que persiguen el mismo objetivo que las anteriores: facilitar la programación de la presentación de las aplicaciones web a diseñadores gráficos sin conocimientos del lenguaje Java mediante herramientas visuales orientadas al manejo de etiquetas. En este curso no pretendemos cubrir todas y cada una de las etiquetas, pero si comentar cómo se especifica el uso de una librería, qué librerías hay, y algún ejemplo. La guía de referencia completa de JSTL está disponible en: http://docs.oracle.com/javaee/5/jstl/1.1/docs/tlddocs/ Actualmente existen cinco librerías de etiquetas presentes en cualquier servidor de aplicaciones Java EE completo: 

Core (en castellano principal): Su prefijo es c y su URI http://java.sun.com/jsp/jstl/core. Cubre funcionalidades básicas como el manejo de variables, el control del flujo, la gestión de URLs y otras acciones.



XML: Su prefijo es x y su URI http://java.sun.com/jsp/jstl/xml. Cubre funcionalidades de gestión de ficheros XML.



I18N

(en

castellano

internacionalización):

Su

prefijo

es

fmt

y

su

URI

http://java.sun.com/jsp/jstl/fmt. Cubre funcionalidades de formateo de mensajes, números, fechas, horas, etc… teniendo en cuenta la localización de cada cliente. 

Database

(en

castellano,

Base

de

Datos):

Su

prefijo

es

sql

y

su

URI

http://java.sun.com/jsp/jstl/sql. Cubre funcionalidades de acceso a Bases de Datos.

211



Functions

(en

castellano

funciones):

Su

prefijo

es

fn

y

su

URI

http://java.sun.com/jsp/jstl/functions. Cubre funcionalidades relacionadas con el manejo de cadenas de caracteres. Antes de entrar más en detalle en cada librería, vamos a ver cómo se indica en una página JSP el uso de una librería. Para ello se utiliza una directiva que ya mencionamos en una unidad anterior pero que no explicamos en detalle “taglib”: <%@ taglib uri=”xxx” prefix=”xxx” %>  Recibe dos atributos:  URI: identificador del espacio de nombres (viene a significar algo parecido a los paquetes Java para evitar colisiones de dos etiquetas de mismo nombre).  prefix: identificador de la librería a utilizar. Por tanto, si en nuestra página JSP queremos utilizar por ejemplo las librerías Core y Database deberíamos añadir estas dos líneas al inicio de la página: <%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>  <%@ taglib uri="http://java.sun.com/jsp/jstl/sql" prefix="sql" %>  El uso de una acción concreta de una de estas librerías, sigue la sintaxis de las acciones JSP estándar: pero cambiando “jsp” por el prefijo de la librería, seguido de los dos puntos, seguidos de la acción en cuestión, seguida de sus atributos. Por ejemplo, el uso de la acción “set” de la librería Core sería algo así:   Pero ¿qué pasa cuando añadimos una de estas directivas en Eclipse IDE for Java EE Developers? Salen errores. El motivo, es que Apache Tomcat no cumple el 100% de las especificaciones Java EE, y en concreto JSTL 1.2 no lo cumple. Pero es muy sencillo añadir la implementación de referencia de la especificación a nuestra aplicación web, añadiendo a /WebContent/WEB-INF/lib estos dos ficheros JAR: 

http://search.maven.org/remotecontent?filepath=javax/servlet/jsp/jstl/javax.servlet.jsp.j stl-api/1.2.1/javax.servlet.jsp.jstl-api-1.2.1.jar



http://search.maven.org/remotecontent?filepath=org/glassfish/web/javax.servlet.jsp.jst l/1.2.1/javax.servlet.jsp.jstl-1.2.1.jar

212

MÓDULO C – Unidad 8: JavaServer Pages Avanzado

Una vez hemos copiado ambos dos ficheros en el directorio /WebContent/WEB-INF/lib del proyecto, si no se fuese el error forzamos una recompilación mediante la opción de menú: “Project” -> “Clean…”:

Revisemos a continuación brevemente las etiquetas de cada una de las librerías estándar. Como ya comentamos, no va a ser una explicación exhaustiva. Simplemente pretendemos que se conozcan qué posibilidades hay y dónde poder consultar en caso de llegar a necesitarse alguna.

213

8.4.1 Core Implementa acciones básicas para el tratamiento de variables, control de flujo, gestión de URLs, y otras:  Gestión de variables: o set: estable el valor de una variable EL o del atributo de una variable EL en uno de los ámbitos posibles. Si dicha variable no existiese la crea.   o remove: elimina una variable EL.    Control de flujo: o choose junto con when y otherwise: viene a ser una especie de estructura switch, case, default de Java. Evalúa las condiciones EL de cada etiqueta when y entra por la que sea true. Si ninguna fuese true, ejecuta la otherwise.           No se ha encontrado ningún elemento.              Se han encontrado ${cont} elementos.        o forEach: permite iterar por una colección de elementos.                   ${libro.titulo}              o forTokens: permite iterar por una colección de tokens separados por un delimitador. o if: evalúa una condición EL y si es true sigue ejecutando el contenido del bloque.     

El nombre es Pepe.

     Gestión de URLs: o import: importa el contenido de un recurso de Internet en una variable EL. Puede utilizar param para especificar parámetros.   o redirect: envía al cliente un código HTTP de redirección. Puede utilizar param para especificar parámetros. 214

MÓDULO C – Unidad 8: JavaServer Pages Avanzado o url: guarda URLs en una variable EL. Puede utilizar param para especificar parámetros.  Otras: o catch: captura una excepción. La excepción no se propaga y por tanto no se invocará la página JSP de error si la hubiera. o out: evalúa una expresión EL y devuelve su valor. Más detalles y ejemplos: http://docs.oracle.com/javaee/5/jstl/1.1/docs/tlddocs/

8.4.2 XML Implementa acciones básicas para el parseo de documentos XML, control de flujo recorriendo estructuras XML y transformaciones:  Parseo: o out: evalúa una expresión XPath y su resultado lo devuelve como parte de la respuesta. o parse: parsea un documento XMl y guarda el contenido en una variable identificada mediante EL. o set: evalúa una expresión XPath y su resultado lo guarda en una variable identificada mediante EL.  Control de flujo: o choose junto con when y otherwise: similar a la librería Core pero itera sobre el resultado de evaluar una expresión XPath sobre un documento XML. o forEach: similar a la librería Core pero itera sobre el resultado de evaluar una expresión XPath sobre un documento XML. o if: similar a la librería Core pero itera sobre el resultado de evaluar una expresión XPath sobre un documento XML.  Transformación: o transform: aplica una transformación a un documento XML especificado en el atributo doc definida en una plantilla XSLT especificada en el atributo xslt. Más detalles y ejemplos: http://docs.oracle.com/javaee/5/jstl/1.1/docs/tlddocs/

8.4.3 I18N Implementa acciones básicas para la gestión de la localización, seleccionar los mensajes a mostrar en base a dicha localización y el formateo de números y fechas:  Localización: o setLocale: fuerza una localización concreta independientemente de la que enviara el cliente web. o requestEncoding: especifica la codificación a utilizar para interpretar los parámetros de una petición.  Mensajes: 215

o bundle: especifica el conjunto de recursos “localizados” a utilizar. o setBundle: similar a bundle pero para un contexto específico. o message: sirve para añadir a la respuesta un texto “localizado” especificando en el atributo key la clave de dicho texto dentro del bundle.  Formateo: o formatNumber: formatea un número teniendo en cuenta la localización. o formatDate: formatea una fecha teniendo en cuenta la localización. o parseNumber: convierte una cadena de texto en un número teniendo en cuenta la localización. o parseDate: convierte una cadena de texto en una fecha teniendo en cuenta la localización. o setTimeZone: especifica la zona horaria. Más detalles y ejemplos: http://docs.oracle.com/javaee/5/jstl/1.1/docs/tlddocs/

8.4.4 Database Implementa acciones básicas para el acceso a las Bases de Datos:  Configuración: o setDataSource: sirve para especificar el identificador JNDI del Data Source a utilizar.    SQL: o query: ejecuta una query que devuelve un resultado que guarda en el atributo var. Dicho resultado es un Java Bean con los siguientes atributos (a tener en cuenta para poder explotar la información resultante mediante EL):  public String[] columnNames  public int rowCount  public Map[] rows()  public Object[][] rowsByIndex  public boolean limitedByMaxRows Un ejemplo imaginando que tenemos una tabla LIBROS con columnas como AUTOR, TITULO y PAGINAS:               

${libro.titulo}

      Núm. De Páginas: ${libro.paginas}

    216

MÓDULO C – Unidad 8: JavaServer Pages Avanzado o update: ejecuta una actualización en la Base de Datos. o transaction: sirve para aglutinar varias queries y/o updates en una unidad transaccional. Más detalles y ejemplos: http://docs.oracle.com/javaee/5/jstl/1.1/docs/tlddocs/

8.4.5 Functions Implementa acciones básicas de manejo de cadenas de caracteres pero al contrario que todas las librerías anteriores, estás no son etiquetas como tal sino funciones a emplear en una EL: 

length: devuelve la longitud de una colección.  0}" >    Longitud del nombre mayor de cero. Correcto!   



toUpperCase: devuelve la cadena en mayúsculas.



toLowerCase: devuelve la cadena en minúsculas.



substring: devuelve una parte de una cadena.



substringAfter: devuelve una parte de una cadena a partir de un carácter especificado.



substringBefore: devuelve una parte de una cadena antes de un carácter especificado.



trim: devuelve la cadena sin espacios en blanco por delante ni por detrás.



replace: devuelve una cadena con un carácter/cadena remplazado por otro.



indexOf: devuelve la posición de un carácter/cadena especificado.



startsWith: chequea si una cadena comienza con un carácter/cadena especificado.



endsWith: chequea si una cadena termina con un carácter/cadena especificado.



contains: chequea si una cadena contiene un carácter/cadena especificado.



containsIgnoreCase: chequea si una cadena contiene un carácter/cadena especificado ignorando las mayúsculas y minúsculas.



split: divide una cadena devolviendo un array de cadenas.



join: devuelve la unión de varias cadenas en una sola cadena.



escapeXml: devuelve la cadena habiendo cambiado los caracteres especiales por sus valores codificados para poder ser usados en una URL.

Más detalles y ejemplos: http://docs.oracle.com/javaee/5/jstl/1.1/docs/tlddocs/

217

8.5

Librerías de etiquetas JSP personalizadas

Al igual que existen las librerías de etiquetas JSP estándar estudiadas en la sección anterior, las especificaciones Java EE contemplan la posibilidad de que podamos definir e implementar nuestra propia librería de etiquetas. De esta forma, en caso de haber decidido minimizar el código Java que aparecerá en las páginas JSP podemos implementar etiquetas que cubran necesidades particulares de nuestra aplicación. De igual forma, encontraremos en Internet cantidad de librerías adicionales de etiquetas desarrolladas por terceras personas. El API necesario para la implementación de etiquetas personalizadas se encuentra en el paquete: javax.servlet.jsp.tagext; La implementación de una etiqueta personalizada siempre ha de implementar el interface: javax.servlet.jsp.tagext.Tag o extender la clase: javax.servlet.jsp.tagext.TagSupport que es una clase que contiene implementaciones por defecto de los métodos del interface Tag. El interface Tag tiene varios métodos, pero aquí solo comentaremos: 

int doStartTag() throws JspException Este método es invocado cuando el contenedor web detecta el inicio de la etiqueta. Lo normal, es usar este método para implementar la lógica asociada a la etiqueta. Debe devolver un número entero que corresponde a una de estas constantes definidas en el interface Tag: o

SKIP_BODY: significa que la etiqueta ya ha procesado el resto de etiquetas o contenido incluido dentro de su bloque (si lo hubiera) así que el contenedor web puede proceder con el final de la etiqueta.

o

EVAL_BODY_INCLUDE: significa que la etiqueta no ha procesado el resto de etiquetas o contenido incluido dentro de su bloque (si lo hubiera) así que el contendor web debe procesar ese contenido antes de proceder con el final de la etiqueta.



int doEndTag() throws JspException Este método es invocado cuando el contenedor web detecta el final de la etiqueta. Debe devolver un número entero que corresponde a una de estas constantes definidas en el interface Tag: o

EVAL_PAGE: indica al contendor web que continúe con el proceso de ejecución normal de la página JSP.

218

MÓDULO C – Unidad 8: JavaServer Pages Avanzado o

SKIP_PAGE: indica al contendor web que interrumpa el proceso de ejecución normal de la página JSP.

Si la nueva etiqueta va a soportar atributos, entonces la implementación Java debe incluir un atributo con un método setter con idéntico nombre por cada uno. El método setter debe seguir las especificaciones JavaBean, es decir, debe llamarse set seguido del nombre del atributo con la primera letra en mayúsculas. El contenedor web, al encontrarse con la nueva etiqueta, instanciará la implementación y especificará los valores de todos los atributos basado en los valores que se encuentran en la etiqueta en la página JSP. Al extender la clase TagSupport, tenemos acceso a una variable con nombre pageContext de tipo: javax.servlet.jsp.PageContext que nos permite acceder al writer (java.io.Writer) de la respuesta, para poder escribir el resultado de la ejecución de la etiqueta mediante el método: public JspWriter getOut() Veamos un ejemplo. Vamos a definir e implementar una etiqueta que añada por delante y por detrás del contenido de su cuerpo (el bloque definido por la etiqueta) un carácter un número concreto de veces. Para ello, tendrá dos atributos donde especifiquemos el carácter y el número de veces llamados “caracter” y “veces”. Esta sería la implementación: package es.aulamentor;    import java.io.IOException;  import java.io.Writer;    import javax.servlet.jsp.JspException;  import javax.servlet.jsp.tagext.Tag;  import javax.servlet.jsp.tagext.TagSupport;    public class RepiteTag extends TagSupport   {    private char caracter;    private int veces;        public void setCaracter(char carcater)    {      this.caracter = carcater;    }        public void setVeces(int veces)    {      this.veces = veces;    }      public int doStartTag() throws JspException     {  219

    Writer out = pageContext.getOut();      for(int i=0; i
220

MÓDULO C – Unidad 8: JavaServer Pages Avanzado

Este fichero, sigue una sintaxis concreta. Veamos el contenido para nuestro ejemplo y repasaremos las etiquetas más relevantes:       1.0    Aula_Mentor_Tag_Library    http://www.aulamentor.es/jsp/jstl/tags          repite      es.aulamentor.RepiteTag      scriptless              caracter        true                    veces        false            La primera línea indica que se trata de un archivo XML. La segunda indica que se trata de la definición de una librería de etiquetas. Como bloques o etiquetas relevantes tenemos: 

uri: a la que luego haremos referencia desde la página JSP para indicar que usamos esta librería. 221



tag: incluye la definición de una etiqueta personalizada.



name: el identificador de la etiqueta cuando la usemos en una página JSP.



tag-class: la clase Java que implementa el comportamiento de la etiqueta.



body-content: indica si la etiqueta puede albergar contenido dentro de su bloque o no (entre la etiqueta de inicio y la de cerrado). Puede tomar varios valores: o

empty: no puede tener contenido.

o

scriptless: puede tener contenido pero solo otras etiquetas, no código de script.

o 

tagdependent: puede contener cualquier cosa.

attribute: incluye la definición de un atributo de la etiqueta. Indica su nombre que usaremos luego en la página JSP y si es obligatorio o no.

Por último, ya solo nos queda utilizar la nueva etiqueta en la aplicación. Para ello vamos a crear una página JSP muy sencilla: <%@ page language="java" contentType="text/html; charset=ISO‐8859‐1"  pageEncoding="ISO‐8859‐1"%>  <%@ taglib uri="http://www.aulamentor.es/jsp/jstl/tags" prefix="am" %>              <META http‐equiv="Content‐Type" content="text/html; charset=ISO‐      8859‐1">                            PRUEBA              Primero, fijémonos en cómo decimos que vamos a utilizar etiquetas de la nueva librería: <%@ taglib uri="http://www.aulamentor.es/jsp/jstl/tags" prefix="am" %>  La URI debe coincidir exactamente con la que especificamos en le fichero de configuración de la librería. Y el prefijo, puede ser cualquiera. En este caso hemos decidido que sea: am. Ahora, veamos dónde y cómo hemos usado la etiqueta:     PRUEBA    Identificada con el prefijo y utilizando exactamente el mismo nombre que usamos en el fichero de configuración. Hemos usado también sus dos atributos (solo carácter era obligatorio).

222

MÓDULO C – Unidad 8: JavaServer Pages Avanzado El resultado de su ejecución, debería ser la palabra PRUEBA rodeada de cinco asteriscos por delante y detrás:

El API para la creación de etiquetas personalizadas es más extenso de lo que hemos visto en esta sección. Aquí hemos repasado las bases para la creación de etiquetas sencillas, pero el API ofrece más posibilidades que si el alumno está interesado puede profundizar consultando la guía de referencia en Internet: http://docs.oracle.com/javaee/6/api/javax/servlet/jsp/tagext/packagesummary.html#package_description

223

PARA RECORDAR

 Las etiquetas JSP estándar, son etiquetas del estilo de las empleadas en las páginas HTML o en los descriptores de despliegue (XML) que permiten realizar acciones en el momento de ejecución de la página. Su sintaxis consiste en el prefijo “jsp:”.

 Las Expression Language (EL) son un pseudolenguaje para identificar y acceder de una manera muy sencilla a las variables. Su sintaxis es ${…}

 La especificación JSTL (JavaServer Page Standard Tag Library o Librería de etiquetas JSP estándar) aglutina una serie de librerías de etiquetas o acciones adicionales. Se especifican mediante la directiva “taglib”.

 Las librerías existentes en un servidor de aplicaciones Java EE son:  Core: Cubre funcionalidades básicas como el manejo de variables, el control del flujo, la gestión de URLs y otras acciones.  XML: Cubre funcionalidades de gestión de ficheros XML.  I18: Cubre funcionalidades de formateo de mensajes, números, fechas, horas, etc… teniendo en cuenta la localización de cada cliente.  Database: Cubre funcionalidades de acceso a Bases de Datos.  Functions: Cubre funcionalidades relacionadas con el manejo de cadenas de caracteres.

 Las especificaciones Java EE contemplan la posibilidad de que podamos definir implementar nuestra propia librería de etiquetas. La implementación de una etiqueta personalizada siempre ha de implementar el interface, javax.servlet.jsp.tagext.Tag o extender la clase javax.servlet.jsp.tagext.TagSupport

224

Unidad de Aprendizaje 9

OTROS CONCEPTOS AVANZADO

ÍNDICE 9.1

Introducción ................................................................. 227

9.2

Gestión de errores....................................................... 227

9.3

Gestión de la seguridad.............................................. 232

9.4

Frameworks de desarrollo web................................. 244 9.4.1 JavaServer Faces .........................................................244 9.4.2 Apache Struts................................................................245 9.4.3 Spring Source................................................................245 9.4.4 Apache Wicket ..............................................................246

PARA RECORDAR.................................................................. 247

MÓDULO C – Unidad 9: Otros conceptos

9.1 Introducción  Esta es la última unidad del curso. En ella trataremos algunos temas no menos importantes que no han tenido cabida en las unidades anteriores como son la gestión de errores y la seguridad en Java EE. Por último, daremos una breve pincelada de algunos frameworks de desarrollo de aplicaciones web, que construidos sobre los conceptos que hemos visto en este curso pretenden acelerar y facilitar el desarrollo de aplicaciones web. La idea es simplemente que el alumno conozca de su existencia y profundice en alguno de ellos si los encuentra de interés. Cada uno de ellos por si solo, daría lugar a un curso completo.

9.2

Gestión de errores

Según las especificaciones Java EE, existen dos alternativas no excluyentes para la gestión de errores: 

Programática: Toda la gestión se lleva dentro de la aplicación mediante código fuente. Es el modo que hemos estado empleando hasta ahora en todos los ejemplos de las distintas unidades.



Declarativa: La gestión se externaliza en configuraciones en el descriptor de despliegue.

Evidentemente cada una tiene sus ventajas e inconvenientes. Por un lado, la programática es la gestión más potente y flexible, sin embargo el código es más complejo y la lógica más complicada de seguir. Por otro lado, la declarativa es la gestión más sencilla pero por otro lado tiene más restricciones. La gestión programática ya la conocemos. Mediante las estructura try & catch o cualquier otro medio de detección de errores, realizamos mediante código redirecciones a páginas concretas de tratamiento y muestra del error. Por tanto, en esta unidad nos vamos a ceñir a la gestión declarativa. Mediante la gestión declarativa podemos controlar dos aspectos: 

Errores HTTP: Qué eran y qué tipos de errores HTTP existían ya lo estudiamos en la unidad dedicada al protocolo HTTP en este mismo curso. Es el propio Servidor de Aplicaciones Java EE el que habitualmente gestiona este tipo de errores mostrando una página de error. Pero las especificaciones Java EE nos permiten definir en el descriptor de despliegue un componente web (página HTML, página JSP, Java Servlet, etc…) que se invocará cuando ocurra dicho error en vez de mostrar la página por defecto del servidor.

Por ejemplo, la página por defecto para un error 404 (recurso no encontrado) de Apache Tomcat 7.0.x es la siguiente:

227

Sin embargo, mediante los bloques “error-page” y sus bloques “error-code” (para especificar el código de error) y “location” (para especificar qué componente web invocar) podemos cambiar este comportamiento por defecto. Veamos un ejemplo de cómo cambiar la página que se muestra para el error HTTP 404:             404      /Error404.jsp      Y esta es la página JSP: <%@ page language="java" contentType="text/html; charset=ISO‐ 8859‐1" pageEncoding="ISO‐8859‐1"%>              <META http‐equiv="Content‐Type" content="text/html;       charset=ISO‐8859‐1">                    Página no encontrada. Disculpe las molestías...
      Si el problemea persiste póngase en contacto con el       administrador.
      <%= Calendar.getInstance().getTime() %>        228

MÓDULO C – Unidad 9: Otros conceptos Este sería el resultado ahora:

Y así podríamos hacer con todos los tipos de errores HTTP más habituales, consiguiendo dar una imagen más corporativa y cercana al usuario (evidentemente la página de nuestro ejemplo no es ninguna de las dos cosas). 

Excepciones Java: También se pueden gestionar de manera declarativa las excepciones Java que se produzcan. Lo más habitual, es hacerlo con aquellas excepciones

Java

no

esperadas

o

con

difícil

solución.

Por

ejemplo,

java.lang.NullPointerException. Pero podemos gestionar cualquiera que queramos. Veamos primero cómo contesta por defecto Apache Tomcat 7.0.x a una excepción del tipo java.lang.NullPointerException no capturada.

229

El mecanismo para declarar qué componente invocar cuando se produzca una excepción concreta, es similar al visto anteriormente. La única diferencia es que en vez del bloque “error-code” usaremos “exception-type”. Otra diferencia, es que el Servidor de Aplicaciones Java EE nos pasará en la petición dos atributos (ojo, no parámetros): o

javax.servlet.error.exception: Conteniendo la excepción que se ha producido (no el nombre, sino la instancia como tal).

o

javax.servlet.error.request_uri: Indicando el componente que produjo el error.

Veamos un ejemplo de cómo cambiar la página que se muestra para la excepción java.lang.Exception no capturada y tratada en el código:             java.lang.NullPointerException      /NullPointerException.jsp      Y esta es la página JSP: <%@page import="java.util.Calendar"%>  <%@ page language="java" contentType="text/html; charset=ISO‐ 8859‐1" pageEncoding="ISO‐8859‐1"%>              <META http‐equiv="Content‐Type" content="text/html;       charset=ISO‐8859‐1">                    <%        Exception ex = (Exception)request.getAttribute        ("javax.servlet.error.exception");        StackTraceElement[] stack = ex.getStackTrace();      %>      Se produjo un error no esperado. Disculpen las       molestias...
      Contacte con el administrador con la siguiente       información:
      

        
• Componente defectuoso:          <%=           request.getAttribute("javax.servlet.error.request_uri")             %>  230
  
  MÓDULO C – Unidad 9: Otros conceptos       
        
• Error producido: NullPointerException
        
• Más detalle:
            <%            for(int i=0; i          <%= stack[i].toString() %>
            <%              }          %>        
      

      <%= Calendar.getInstance().getTime() %>        Este sería el resultado ahora:

Y así podríamos hacer con todos los tipos de excepciones más habituales no controlados o que se pueden escapar mas fácilmente en el código, consiguiendo dar una imagen más corporativa y cercana al usuario (evidentemente la página de nuestro ejemplo no es ninguna de las dos cosas).

231

9.3

Gestión de la seguridad

La seguridad, es un tema que no podemos descuidar cuando hablamos de aplicaciones web. Y las especificaciones Java EE tampoco la descuidan para nada. Imaginemos lo que podría pasar con aplicaciones web típicas de hoy en día sin una buena gestión de la seguridad: home banking, bróker online, tiendas virtuales, etc… En general, desde un punto de vista teórico, una buena gestión de la seguridad debe cubrir los siguientes puntos: 

Autenticación: Asegurarse que un cliente es quien dice ser.

Por ejemplo, al acceder a una aplicación web se nos puede solicitar identificador y contraseña para validar que somos quien decimos ser. Existen otras opciones además del identificador y contraseña, como son los certificados digitales. 

Autorización: Asegurarse que un cliente accede solo a los recursos a los que puede/debe tener acceso y no a otros.

Por ejemplo, si no somos administradores de una aplicación web, al entrar en el sistema no deberíamos poder acceder a opciones de configuración de la aplicación. 

Integridad de datos: Asegurarse que los mensajes llegan sin haber sido alterados por el camino.

Por ejemplo, evitar que alguien pueda estar “pinchado” a la red y modifique el contenido de los mensajes que enviamos a un servidor. 

Confidencialidad: Asegurarse que solo las personas autorizadas pueden ver y acceder a información sensible.

Por ejemplo, evitar que alguien pueda estar “pinchado” a la red y lea información sensible como contraseñas, números de cuenta y similares que fluye entre nuestro navegador y el servidor. 

No repudio: Asegurarse que quedan evidencias que eviten que un cliente pueda negar haber realizado una transacción contra el servidor.

Por ejemplo, evitar que alguien pueda decir que no hizo algo en nuestro sistema. 

Auditoria: Asegurarse que queda registrado todos los eventos relacionados con la seguridad para posteriores estudios y análisis.

Por ejemplo, registrar todos los intentos de acceso fallidos al sistema. No trataremos en profundidad todos los puntos pero si nos centraremos en algunos imprescindibles como son la autenticación y autorización. Otros como la integridad de datos o la confidencialidad los comentaremos brevemente ya que no dependen tanto de la aplicación sino de una correcta configuración de la infraestructura. Las especificaciones Java EE, nos ofrecen dos aproximaciones distintas al tema de la seguridad: 232

MÓDULO C – Unidad 9: Otros conceptos 

Programática: es decir, define una serie de APIs para que la gestión de la seguridad se realice directamente desde el código. APIs como Java Authentication and Authorization Service (JAAS) para realizar autenticación y autorización, Java Cryptography Extension (JCE) para realizar cifrados, Java Security Socket Extension (JSSE) para realizar comunicaciones seguras, etc…



Declarativa: es decir, la posibilidad de delegar en los contenedores Java EE (Servidor de Aplicaciones Java EE) algunos de los temas relacionados con la gestión de la seguridad, permitiendo a los desarrolladores centrarse en la lógica de negocio de la aplicación y no en estos temas colaterales pero no menos importantes.

La aproximación declarativa se realiza mediante el uso de los descriptores de despliegue o las anotaciones Java (a partir de Java EE 6.0). Ambas dos aproximaciones tienes pros y contras. La aproximación declarativa no cubre el 100% de las áreas ni es tan flexible como la programática, pero es mucho más sencilla, está sujeta a menos errores y cubre las necesidades habituales de autenticación y autorización. En este curso vamos a tratar solamente la aproximación declarativa, ya que no tiene sentido dedicar más unidades a estudiar APIs tan específicas. No obstante, todas están documentadas en la web: http://docs.oracle.com/javase/7/docs/technotes/guides/security/ Antes de entrar en los detalles Java EE, vamos a revisar unos conceptos teóricos previos imprescindibles como son: Realm, Usuario, Grupo y Rol. 

Realm: Recibe el nombre en inglés de Realm, el conjunto de usuarios y grupos identificados como válidos para una aplicación web junto con las políticas de seguridad asociadas. Podríamos decir que se trata de toda la configuración de seguridad de una aplicación web concreta.



Usuario: Es el identificador unívoco de una persona o entidad de software que puede interactuar con la aplicación.



Grupo: Es el identificador de un conjunto de usuarios que tienen algo en común.



Rol: Es el identificador de un concepto abstracto que agrupa a varios usuarios individuales o grupos. Se utiliza para realizar la autorización de acceso a los recursos.

¿Cómo encajan estos conceptos juntos y cómo se utilizan para securizar una aplicación web? En el Servidor de Aplicaciones Java EE gestionado por los administradores de sistemas existen definidos usuarios y grupos. Dependiendo del Servidor de Aplicaciones Java EE y de la solución corporativa que haya instalada en cada caso, esto usuarios y grupos estarán definidos directamente en el servidor o están delegados en el Sistema Operativo, o en un Servidor de Directorio LDAP. Lo importante en nuestro caso es que ambos dos conceptos son un tema ajeno a la aplicación web y está delegado en la infraestructura. 233

Los roles sin embargo, si que son algo que definimos en la aplicación. Es un concepto abstracto de quién puede hacer qué. Es decir, en la aplicación diremos que a un recurso concreto solo puede acceder el rol A y B. Y a otro recurso distinto solo el rol A o por el contrario el rol C. El “truco” llega en el momento de la instalación de la aplicación donde el administrador encargado de dicho proceso mapeará el concepto abstracto de rol, con los conceptos reales de usuario y/o grupo. Y el conjunto de esas definiciones para una aplicación concreta, es lo que llamamos un Realm. Pero vayamos por partes. Ha quedado claro que primero necesitamos contar con una serie de usuarios y opcionalmente grupos en nuestro sistema. En el caso de este curso, estamos usando el Servidor de Aplicaciones Java EE Apache Tomcat 7.0.x que ofrece distintas alternativas de configuración. Optaremos por la más sencilla, que consiste en el uso de un fichero de configuración de usuarios: /conf/tomcatusers.xml La primera “dificultad” viene porque Apache Tomcat denomina rol lo que en la teoría de seguridad hemos llamado grupo. No pasa nada, pero evidentemente crea confusión. Así que es importante recordarlo a lo largo del resto de esta sección: lo que en la configuración de Apache Tomcat se denomina rol, realmente corresponde al concepto que hemos comentado de grupo. No tiene nada que ver con el concepto abstracto de rol que aplica a las aplicaciones web y que veremos mas adelante. Vamos a trabajar sobre un ejemplo donde tendremos seis usuarios: usuario1, usuario2, usuario3, usuario4, usuario5 y usuarios6, y tres grupos: clientes (representa usuarios normales de nuestra aplicación), operadores (representa usuarios especiales que pertenecen a nuestra empresa y que tienen más permisos que los usuarios cliente) y administradores (representa usuarios nuevamente de nuestra empresa que tienen todos los permisos). Los dos primeros usuarios pertenecen al primer grupo, los dos siguientes al segundo grupo y los dos últimos al tercero. Las contraseñas de cada usuario son su propio identificador, es decir, usuario1 tendrá como contraseña usuario1, y así sucesivamente. Vamos a editar el fichero de configuración en el entorno de desarrollo Eclipse IDE for Java EE Developers (recordemos que los ficheros de configuración de Apache Tomcat en este caso estarán en un proyecto denominado Servers):

234

MÓDULO C – Unidad 9: Otros conceptos

El contenido del fichero debería ser algo así para nuestro ejemplo:                                                  De esta manera, nuestro sistema ya cuenta con los usuarios y grupos definidos. Nota: Un usuario puede pertenecer a más de un grupo. En ese caso, simplemente se añadiría un grupo separado por coma a la definición del usuario. A continuación, vamos a desarrollar nuestra aplicación de ejemplo antes de seguir avanzando en la configuración de la seguridad. La aplicación va a ser muy sencilla, va a consistir en una página HTML de entrada con tres botones: clientes, operadores y administradores. Esta página es pública, es decir, será accesible por todo el mundo esté dado de alta en los sistemas como usuario o no. Cada uno de los tres botones, invocará a una JavaServer Page (JSP) distinta accesible por cada uno de los tres grupos. Y aquí vendrá el grueso del ejemplo porque los clientes solo podrán acceder a la página de clientes, los operadores podrán acceder tanto a la de clientes 235

como a la de operadores y los administradores a todas. Para ello, el navegador nos pedirá un usuario y una contraseña, para saber quién somos y si nos puede autorizar o no. Pero la configuración para que esto ocurra la veremos después de escribir el código. Página HTML (publica.html):             <META http‐equiv="Content‐Type" content="text/html; charset=ISO‐      8859‐1">                    Esta página es pública y accesible por todo el mundo.                                                                    Página JSP (clientes.jsp): <%@ page language="java" contentType="text/html; charset=ISO‐8859‐1"  pageEncoding="ISO‐8859‐1"%>              <META http‐equiv="Content‐Type" content="text/html; charset=ISO‐      8859‐1">                    Página de Clientes accesible por usuarios:      

        
• Usuario1
        
• Usuario2
        
• Usuario3
        
• Usuario4
        
• Usuario5
        
• Usuario6
      

        Página JSP (operadores.jsp): <%@ page language="java" contentType="text/html; charset=ISO‐8859‐1"  pageEncoding="ISO‐8859‐1"%>    236

MÓDULO C – Unidad 9: Otros conceptos           <META http‐equiv="Content‐Type" content="text/html; charset=ISO‐      8859‐1">                    Página de Clientes accesible por usuarios:      

        
• Usuario3
        
• Usuario4
        
• Usuario5
        
• Usuario6
      

        Página JSP (administradores.jsp): <%@ page language="java" contentType="text/html; charset=ISO‐8859‐1"  pageEncoding="ISO‐8859‐1"%>              <META http‐equiv="Content‐Type" content="text/html; charset=ISO‐      8859‐1">                    Página de Clientes accesible por usuarios:      

        
• Usuario5
        
• Usuario6
      

        La clave viene ahora con el descriptor de despliegue, donde definiremos los roles que existen en nuestra aplicación, las restricciones de seguridad de los componentes de la aplicación, y el modo de autenticación al acceder a la aplicación. Los roles existentes en una aplicación web, se definen mediante los bloques “security-role” y “role-name”. En nuestro ejemplo:     clientes        operadores        administradores    Como ya comentamos en los conceptos teóricos, Grupo y Rol no tienen por qué ser lo mismo. Los roles son un concepto abstracto independiente de los sistemas de usuarios/grupos que 237

haya definidos en una empresa De esta manera se consigue una independencia entre la aplicación y los sistemas donde se vaya a desplegar. Es a la hora de instalar la aplicación, donde se hace un mapeo de roles con usuarios/grupos. Pero cómo se hace este mapeo es dependiente de cada Servidor de Aplicaciones Java EE. Cada uno lo realiza en un fichero de configuración distinto y con una sintaxis distinta. Pero es más, en el caso de Apache Tomcat 7.0.x dicho mapeo no existe y nos obliga a que los roles correspondan con nombres de grupos idénticos lo cual es una restricción importante. Las restricciones de acceso a los componentes de la aplicación web se definen mediante el bloque “security-constraint”, el cual a su vez contiene múltiples bloques. Veamos un ejemplo:           Area de Operadores      /operadores.jsp      GET      POST              administradores      operadores              NONE        Como se puede observar, primero se define el recurso o conjunto de recursos a proteger, identificados por una URL que podría usar comodines tipo: /*, o /*.jsp, etc… especificando además los protocolos HTTP de acceso a tener en consideración. Después de especifican los roles que tienen autorización a acceder a los recursos definidos anteriormente. Y por último, especifica si las comunicaciones deben ser seguras o no (utilizando HTTPS). Este bloque puede tomar tres valores: 

NONE: no existe requerimiento de comunicaciones seguras para acceder a los recursos definidos, es decir, HTTP.



CONFIDENTIAL: las comunicaciones deben no ser legibles, por tanto se debe usar HTTPS para acceder a los recursos definidos.



INTEGRAL: las comunicaciones deben asegurar su integridad, es decir, que nadie pueda haber cambiado el contenido por en medio entre el cliente y el servidor. A efectos prácticos implica lo mismo que CONFIDENTIAL, se debe usar HTTPS para acceder a los recursos definidos.

De esta manera, definiríamos todas las posibles autorizaciones de acceso a los componentes de la aplicación web. 238

MÓDULO C – Unidad 9: Otros conceptos El modo de autenticación se define mediante los bloques “login-config” y “auth-method”. Por ejemplo, para que sea el navegador el que nos muestre una ventana de autenticación de usuario y contraseña:     BASIC     Existen múltiples métodos de autenticación. Brevemente son: 

BASIC: el servidor pedirá al cliente que solicite el usuario y contraseña. Estas viajaran codificadas en Base64 en claro (a no ser que las comunicaciones sean seguras).



FORM: la aplicación web implementa la página de solicitud de usuario y contraseña, en vez de ser una ventana del navegador. La configuración en el descriptor de despliegue requiere algún parámetro adicional que veremos más tarde.



CLIENT-CERT: requiere que el navegador envíe un certificado digital con la información del usuario. Este es el mecanismo que se utiliza por ejemplo en aplicaciones como la declaración de Hacienda en la AEAT.



DIGEST: la información del usuario y la contraseña van cifradas utilizando alguno de los algoritmos soportados por ambos lados, cliente y servidor.

Con todo esto, veamos cómo sería el descriptor de despliegue de nuestro ejemplo:             clientes              operadores              administradores                      Area de Adminitradores        /administradores.jsp        GET        POST                    administradores                    NONE            239

                Area de Operadores        /operadores.jsp        GET        POST                    administradores        operadores                    NONE                            Area de Clientes        /clientes.jsp        GET        POST                    administradores        operadores        clientes                    NONE                    BASIC          Como se puede ver, definimos tres roles, tres colecciones de recursos con sus definiciones de acceso y el método de autenticación BASIC. Si ejecutamos el ejemplo siguiendo la siguiente secuencia lógica: 1. Accedemos a la página HTML principal pública que no está protegida. Deberíamos poder acceder y ver su contenido sin ningún tipo de problema.

240

MÓDULO C – Unidad 9: Otros conceptos 2. Solicitamos el acceso a la zona de Clientes ya protegida. Y el navegador debería mostrarnos una ventanita de autenticación. Nos autenticamos con usuario3/usuario3, es decir, con un miembro del grupo de operadores. Y deberíamos poder ver la zona de clientes sin problemas.

3. Navegamos hacia atrás y solicitamos el acceso a la zona de Operadores. Deberíamos poder acceder nuevamente sin problemas ya que el usuario3 pertenece al grupo de operadores.

241

4. Por último, navegamos hacia atrás y solicitamos el acceso a la zona de Administradores. En este caso deberíamos recibir un error HTTP 403 porque no tenemos autorización para acceder a esa zona.

Se trata de un ejemplo muy sencillo pero bastante ilustrativo de la gestión de la seguridad en Java EE de forma declarativa. Antes de dar por finalizada esta sección, vamos a mostrar el uso del mecanismo de autenticación FORM (el del ejemplo anterior ha sido BASIC). Como indicábamos, FORM implica que la ventana de petición de usuario y contraseña es proporcionada por la aplicación web y no es una ventanita del navegador. El primer paso es modificar el descriptor de despliegue. En este caso debería ser algo así:     FORM          /login.jsp      /loginerroneo.jsp        Como configuración adicional, especificamos los componentes web que muestran la pantalla de autenticación, y la pantalla de error en caso de que la autenticación sea errónea. El formulario de la pantalla de autenticación debe tener en cuenta tres cosas: 

Debe invocar mediante HTTP POST un recurso denominado: j_security_check



El usuario lo debe enviar en una variable denominada: j_username



La contraseña debe enviarla en una variable denominada: j_password

Por lo demás, la página puede mostrar la información como quiera. Por ejemplo:   <%@ page language="java" contentType="text/html; charset=ISO‐8859‐1"  pageEncoding="ISO‐8859‐1"%>  242

MÓDULO C – Unidad 9: Otros conceptos             <META http‐equiv="Content‐Type" content="text/html; charset=ISO‐      8859‐1">                                              Página de ejemplo para login:                                                                                                                                          

Usuario:
Contraseña:

              En esta ocasión, cuando el servidor detecte que ha de pedir autenticación al cliente, en vez de solicitar al navegador que muestre una ventana devolverá nuestra página:

Hemos mencionado en varias ocasiones las comunicaciones seguras basadas en el protocolo HTTPS (HTTP con SSL). Dado que se trata de un tema puramente de configuración y administración de los servidores, y que cada servidor lo hace de una manera distinta no vamos a detenernos en los detalles en este curso.

243

No obstante, la información de cómo se configuran las comunicaciones HTTPS en Apache Tomcat 7.0.x se encuentra en la siguiente URL: http://tomcat.apache.org/tomcat-7.0-doc/ssl-howto.html

9.4

Frameworks de desarrollo web

Uno de los objetivos habituales en el mundo de la informática es el de mejorar constantemente la productividad de los desarrolladores. Una manera es mejorando día a día las herramientas de desarrollo disponibles. Y otra, facilitando el desarrollo a través de frameworks que escondan las complejidades y eviten los trabajos repetitivos a los desarrolladores. Esta última es la que comentaremos brevemente a continuación. Un framework no es más que una librería de código junto con una metodología o forma de trabajar. Su objetivo, no es reinventar la rueda sino basándose en las tecnologías ya existentes intentar facilitar la vida al desarrollador. Durante este curso hemos estudiado las tecnologías, especificaciones y APIs en las que se basa el desarrollo web Java EE. Los frameworks que comentaremos brevemente a continuación no son algo totalmente distinto, sino que basándose en lo que ya hemos aprendido intentan mejorar la experiencia del desarrollador facilitando el mantenimiento del código, mejorando los interfaces visuales, evitando trabajos repetitivos, etc… pero siempre por debajo, lleva todo lo aprendido en este curso. Frameworks hay muchos, simplemente comentaremos cuatro de los más extendidos en el mercado laboral actualmente.

9.4.1 JavaServer Faces JavaServer Faces es una especificación más de Java EE. Nació como un framework separado y con el tiempo se adhesionó a las especificaciones. Siguiendo el estándar Java EE, esta debería ser la vía de evolución de los programadores web. ¿Y por qué no hemos estudiado esta opción entonces en este curso? Dos motivos: 1. Se basa en las especificaciones Java Servlet y JavaServer Page. Sin ese conocimiento adquirido en este curso, no podríamos entender JavaServer Faces. Sería como comenzar la casa por el tejado. 2. Adicionalmente, en el mercado siguen existiendo millones de aplicaciones basadas en Java Servlets y JavaServer Pages. La necesidad de estos conocimientos sigue estando ahí, es algo que no podemos obviar. 244

MÓDULO C – Unidad 9: Otros conceptos La idea que persigue JavaServer Faces es definir una serie de conceptos por encima de las APIs básicas como son: componentes visuales (controles con lógica avanzada reutilizables a utilizar en las páginas), beans de gestión (mecanismo que facilita la transmisión de información por el flujo de la aplicación), validadores (un sistema de control de errores en los valores de los campos), proveer de un controlador que ya implementa el control del flujo de la aplicación mediante un fichero de configuración, etc… Para profundizar en este framework: http://docs.oracle.com/javaee/6/tutorial/doc/bnaph.html

9.4.2 Apache Struts Fue el primer framework de este estilo que surgió en la Fundación Apache. Era muy sencillo de utilizar, y básicamente añadía la posibilidad de definir el flujo de la aplicación en un fichero de propiedades que un controlador del propio framework se encargaba de interpretar. Todas las peticiones pasaban por este controlador y él se encargaba de direccionar a la página que el fichero dijera dependiendo de los valores de distintos parámetros y/o condiciones. También añadía validadores para facilitar el control de errores de los formularios. Con la aparición de JavaServer Faces y otros frameworks como Spring se fue quedando algo obsoleto y cada vez se usa menos. Para profundizar en este framework: http://struts.apache.org/

9.4.3 Spring Source Junto con JavaServer Faces, es uno de los frameworks mas extendidos. Nació como una ayuda mas a la programación web pero con el tiempo se fue extendiendo a otras muchas áreas

como

la

programación

transaccional,

la

persistencia de datos, la programación de batch, para móviles, etc… Para profundizar en este framework: http://www.springsource.org/documentation

245

9.4.4 Apache Wicket Este

es

un

nuevo

framework

junto

con

Struts

también

perteneciente a la Fundación Apache. Su objetivo es conseguir separar lo máximo posible la presentación de la lógica, y definir un modelo de lógica de negocio basado en POJOs muy sencillo. No está muy extendido su uso. Para profundizar en este framework: http://wicket.apache.org/

246

PARA RECORDAR

 Existen dos alternativas, según las especificaciones Java EE para la gestión de errores: 

Programática: Toda la gestión se lleva dentro de la aplicación mediante código fuente (por ejemplo mediante bloques try/catch).



Declarativa: La gestión se externaliza en configuraciones en el descriptor de despliegue. Permite controlar: o Errores HTTP o Excepciones Java

 Una buena gestión de la seguridad debe cubrir los siguientes puntos: 

Autenticación: Asegurarse que un cliente es quien dice ser.



Autorización: Asegurarse que un cliente accede solo a los recursos a los que puede/debe tener acceso y no a otros.



Integridad de datos: Asegurarse que los mensajes llegan sin haber sido alterados por el camino.



Confidencialidad: Asegurarse que solo las personas autorizadas pueden ver y acceder a información sensible.



No repudio: Asegurarse que quedan evidencias que eviten que un cliente pueda negar haber realizado una transacción contra el servidor.



Auditoria: Asegurarse que queda registrado todos los eventos relacionados con la seguridad para posteriores estudios y análisis.

 Las especificaciones Java EE, nos ofrecen dos aproximaciones distintas al tema de la seguridad: 

Programática: Define una serie de APIs para que la gestión de la seguridad se realice directamente desde el código.



Declarativa: Delega en los contenedores Java EE (Servidor de Aplicaciones Java EE) algunos de los temas relacionados con la gestión de la seguridad.

247

 Los métodos de autenticación´ comúnmente más usados son: 

BASIC: el servidor pedirá al cliente que solicite el usuario y contraseña



FORM: la aplicación web implementa la página de solicitud de usuario y contraseña, en vez de ser una ventana del navegador.



CLIENT-CERT: requiere que el navegador envíe un certificado digital con la información del usuario.



DIGEST: la información del usuario y la contraseña van cifradas utilizando alguno de los algoritmos soportados por ambos lados, cliente y servidor.

 Los Frameworks más extendidos para el desarrollo de aplicaciones web son: 

JavaServer Faces es una especificación más de Java EE basada en Java Servlets y en JavaServer Pages (JSP).



Apache Struts fue el primer framework de este estilo que surgió en la Fundación Apache.



Spring Source nació como una ayuda mas a la programación web pero con el tiempo se fue extendiendo a otras muchas áreas como la programación transaccional, la persistencia de datos, la programación de batch, para móviles, etc…



Apache Wicket. Su objetivo es conseguir separar lo máximo posible la presentación de la lógica, y definir un modelo de lógica de negocio basado en POJOs muy sencillo.

248