II Curso Online JAVA-J2EE

Transcripción

II Curso Online JAVA-J2EE
TEMA 4
Desarrollo web con las tecnologías J2EE
Autor: PCYTA / Centro de Excelencia de Software Libre de Castilla-La Mancha
Versión: 1.0
Fecha: Revisado 07-02-2008 11:46
Licencia: CC-by-sa 2.5
0 Licencia
Usted es libre de:
Copiar, distribuir y comunicar públicamente la obra
Hacer obras derivadas
Bajo las condiciones siguientes:
uso
Reconocimiento. Debe reconocer los créditos de la obra de la manera especificada por el
autor o el licenciador (pero no de una manera que sugiera que tiene su apoyo o apoyan el
que hace de su obra).
Compartir bajo la misma licencia. Si altera o transforma esta obra, o genera una obra
derivada, sólo puede distribuir la obra generada bajo una licencia idéntica a ésta.
•
•
•
Al reutilizar o distribuir la obra, tiene que dejar bien claro los términos de la licencia
de esta obra.
Alguna de estas condiciones puede no aplicarse si se obtiene el permiso del titular de
los derechos de autor
Nada en esta licencia menoscaba o restringe los derechos morales del autor.
Para ver la licencia visite:
http://creativecommons.org/licenses/by-sa/2.5/es/legalcode.es
6 de febrero de 2008
Tema 4
2
UNIDAD IV. DESARROLLO WEB CON LAS TECNOLOGÍAS J2EE
0 Licencia............................................................................................................................................2
1 Estructura de una aplicación Web................................................................................................4
1.1 Componentes y contenedores Web............................................................................................4
1.2 Elementos de una aplicación web..............................................................................................5
1.3 Desarrollo y despliegue de una aplicación web........................................................................6
1.4 El fichero descriptor: Web.xml..................................................................................................7
2 Servlet y JSP...................................................................................................................................9
2.1 Servlet (básico)..........................................................................................................................9
2.2 JSP (Básico).............................................................................................................................10
2.3 Request and Response.............................................................................................................11
2.4 Servlet (avanzado)...................................................................................................................15
2.5 JSP (Avanzado)........................................................................................................................17
2.6 JSTL........................................................................................................................................19
3 Frameworks: Struts, JSF y Spring.............................................................................................21
3.1 Patrón MVC.............................................................................................................................21
3.2 Struts........................................................................................................................................22
3.3 JSF...........................................................................................................................................24
3.4 Spring......................................................................................................................................26
4 AJAX..............................................................................................................................................28
4.1 Introducción.............................................................................................................................28
4.2 Principales elementos de AJAX..............................................................................................28
4.3 Ejemplo de uso de AJAX........................................................................................................30
4.4 Otras posibilidades..................................................................................................................34
5 ANEXO..........................................................................................................................................35
5.1 INSTALACIÓN DE TOMCAT...............................................................................................35
5.2 INTEGRACIÓN DE TOMCAT Y ECLIPSE..........................................................................42
5.3 IMPORTACIÓN, CONFIGURACIÓN, FUNCIONAMIENTO APP STRUTS.....................46
Tema 4
3
1 Estructura de una aplicación Web
1.1 Componentes y contenedores Web
Como ya vimos en el Tema 3 de introducción a J2EE, la arquitectura J2EE define componentes y
contenedores, en este tema veremos los Servlets y JSP que son componentes dedicados a la capa
web. La siguiente figura (que ya vimos en el tema anterior) muestra donde están ubicados estos
componentes:
Tal y como hemos dicho las piezas fundamentales para la construcción de aplicaciones web con
Java son los Servlets y los JSP, además, también se pueden usar los JavaBeans y las librerías de
etiquetas (JSTL).
Las aplicaciones web se despliegan en contenedores web, entre los más populares se encuentran:
•
Tomcat (http://jakarta.apache.org/tomcat/index.html) que será el que utilizaremos en este
curso,
•
Caucho Resin (http://www.caucho.com/) y
•
Jetty (http://jetty.mortbay.org/index.html).
Los contenedores web se encargan principalmente de recibir las peticiones de los clientes remotos,
dirigirlas a los componentes adecuados y devolver la respuesta generada, pero además se pueden
encargar de la seguridad, controlar el acceso de los usuarios, gestionar el ciclo de vida de los
componentes y un largo etcétera dependiendo de la implementación del contenedor.
Tema 4
4
1.2 Elementos de una aplicación web
Una aplicación web se compone de los siguientes elementos:






Componentes estáticos (ficheros html,css, javascripts, imágenes, etc).
Servlets.
JSPs.
Clases de apoyo (Javabeans, POJOs, DAOs, etc)
Librerías (ficheros JAR).
Fichero descriptor del despliege (web.xml).
Estos elementos tienen que organizarse dentro de una jerarquía de directorios predefinido en la
especificación J2EE. La estructura mínima es la siguiente:

Directorio raíz o padre (document root): será el que dé el nombre a la aplicación web. En
este nivel de anidamiento se pueden encontrar los componentes estáticos y los JSPs, aunque
se suelen crear subdirectorios para agrupar dichos elementos.
 Subdirectorio WEB-INF: en este directorio se debe encontrar el fichero descriptor
web.xml.
 WEB-INF\classes: en este directorio se encuentran las clases de apoyo
(ficheros *.class).
 WEB-INF\lib: aquí están las librerías (ficheros *.jar) que se utilizan en la aplicación,
bien propietarias o de terceros.
En la siguiente imagen podemos ver la estructura de un aplicación mínima que se llama
HolaMundoServlet con un único Servlet:
Las aplicaciones web las podemos encontrar dentro de los contenedores web (Tomcat) de dos
formas distintas:
1. exploded o desempaquetadas, es decir, cada fichero se encuentra en cada directorio de
forma separada siguiendo la estructura anteriormente mencionada;
2. packaged o empaquetadas, es decir, como un único fichero con la extensión WAR (Web
Application Archive) que contiene toda la estructura mencionada (al igual que hacen los
compresores o se realiza con los archivos JAR).
Durante el desarrollo de las aplicaciones se suele trabajar con la primera forma y cuando la
aplicación se pasa a entornos de producción se entrega como un solo fichero WAR.
Los ficheros WAR se pueden crear mediante la herramienta ‘jar’ que proporciona la JDK (jar cvf
<nombreAplicacion>.war). También es algo que se puede realizar de forma automática
mediante el IDE.
Tema 4
5
1.3 Desarrollo y despliegue de una aplicación web
A continuación vamos a enumerar los pasos que es necesario llevar a cabo para desarrollar una
aplicación web y posteriormente desplegar dicha aplicación en un contenedor web (Tomcat) para
que sea accesible desde los navegadores.
1. Crear la estructura de directorios adecuada.
Como ya hemos visto en el apartado anterior las aplicaciones web necesitan tener una estructura de
directorios predefinida por lo que necesitaremos crear dicha estructura de directorios.
También es recomendable, y así lo hacen la mayoría de IDEs por defecto, mantener separado las
clases fuente de las clases compiladas, es decir, crear dos directorios principales para cada proyecto
(los nombres son orientativos y pueden ser diferentes):


src: mantiene el código fuente (ficheros .java) de los Servlets y las clases de apoyo.
web: debajo de éste directorio se crea la estructura definida en el apartado anterior y donde
se guardan los ficheros JSPs, el contenido estático y el fichero web.xml.
En la siguiente imagen podemos ver en detalle la estructura que podría tener una aplicación web
normal.
2. Implementación de la aplicación.
Llevar a cabo el desarrollo del contenido estático y dinámico (JSPs, Servlets) que necesite la
aplicación. Estos ficheros deberán ir en su directorio adecuado. En la figura anterior se ha creado el
directorio JSP donde se guardarían los ficheros JSP.
3. Modificar el fichero web.xml.
Una vez desarrollada la aplicación se debe crear el fichero descriptor web.xml. En este fichero se
dan las instrucciones que necesita el contenedor web para poder desplegar correctamente la
aplicación y ser capaz de recibir-ejecutar-responder correctamente las peticiones de los clientes
remotos. Es un fichero XML cuyo contenido veremos en el apartado siguiente.
4. Compilar las fuentes.
Tema 4
6
Compilar los ficheros fuentes (Servlets y clases de apoyo). Los ficheros compilados (*.class) deben
residir en el directorio WEB-INF\classes. Este proceso se puede realizar de forma automática
mediante ANT (una herramienta similar al makefile), o bien, mediante el IDE.
5. Despliegue de la aplicación.
Desplegar la aplicación en el contenedor web (Tomcat). Este proceso supone copiar el directorio de
la aplicación web en el directorio webapps donde esté instalado el Tomcat. Como dijimos la
aplicación se puede desplegar como directorio desempaquetado, o bien, como fichero WAR.
6. Probar la aplicación.
Ahora sólo queda probar desde un navegador (Internet Explorer, Mozilla Firefox, etc) que la
aplicación se ha desplegado correctamente y que el contenedor web es capaz de procesar
correctamente las peticiones y devolver las respuestas adecuadas.
DOCUMENT ROOT / CONTEXTO / PETICION HTTP
Se denomina document root al directorio raiz de la aplicación web donde están contenidos todos
los subdirectorios obligatorios (WEB-INF, web.xml, etc) y los ficheros desarrollados (JSPs,
Servlets, contenidos estáticos).
El contexto es el nombre del document root que identifica de una forma univoca a la aplicación
web dentro de un contenedor web.
La petición HTTP que se realiza desde el navegador cliente tiene la forma:
http://servidor:puerto/contexto/componenteWeb?query_string
1.4 El fichero descriptor: Web.xml
El fichero web.xml es el encargado de configurar la aplicación web para que el contenedor sea
capaz de resolver adecuadamente las peticiones HTTP. Este fichero distingue entre mayúsculas y
minúsculas y, además, es importante el orden en que se encuentran las etiquetas XML.
En dicho fichero XML se identifican las siguientes partes (vamos a resumir las más comunes):
•
Prólogo: la cabecera de todo fichero XML. Para la especificación J2EE 1.3 es:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
"http://java.sun.com/dtd/web-app_2_3.dtd">

Rutas de alias: cuando un contenedor recibe una petición tiene que ser capaz de determinar
que componente de que aplicación web debe responder. Este se realiza definiendo unas rutas
de mapeo. Por ejemplo, a continuación definimos que la aplicación web tiene un Servlet
llamado
HolaServlet
y
que
se
mapea
sobre
la
ruta
http://servidor:puerto/contexto/servlet/HolaServlet:
<servlet>
Tema 4
7
<description>HolaServlet</description>
<display-name>HolaServlet</display-name>
<servlet-name>HolaServlet</servlet-name>
<servlet-class>HolaServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>HolaServlet</servlet-name>
<url-pattern>/servlet/HolaServlet</url-pattern>
</servlet-mapping>

Parámetros de inicialización para la aplicación web. Se definen con las siguientes
etiquetas:
<context-param>
<param-name>nombreBaseDatos</param-name>
<param-value>OraclePruebas</param-value>
</context-param>


Filtros: definen que filtros (clases, código implementado) se deben aplicar a que peticiones
y en que orden. Se definen con las etiquetas <filter> y <filter-mapping>.
Referencias a recursos: son necesarios cuando los componentes web hacen referencias a
recursos del entorno, por ejemplo, bases de datos.
<resource-ref>
<res-ref-name>jdbc/BookDB</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
</resource-ref>
Tema 4
8
2 Servlet y JSP
2.1 Servlet (básico)
Para situar históricamente la creación de los Servlets tenemos que volver la vista hacia un origen de
Internet donde todo el contenido que se podía ver en los servidores era estático, formado por
páginas HTML interrelacionadas con hiperenlaces.
Posteriormente, se implementa la mejora de hacer que los servidores web generasen contenido
dinámico, es decir, que dependiendo de los parámetros que se enviasen a un servidor (usuario
conectado, catálogo de productos elegido, etc) la respuesta se generase de forma dinámica y fuese
diferente dependiendo de esos parámetros.
Esta mejora implica que ya no sólo tenemos en el servidor páginas HTML fijas, sino que es
necesario tener programas que generen este HTML con cada nueva petición. Surgen entonces los
CGI que son los programas que generan el contenido dinámico y que se implementan en
diversos lenguajes (C, Perl, Python, etc).
Evidentemente, en Sun no se quedan atrás y definen una especificación que cumpla con el cometido
de estas aplicaciones CGI. A estos programitas los denominan Servlets, en contraposición a los
applets que son programitas que se ejecutan en el cliente, mientras que los Servlets se ejecutan en el
servidor.
Resumiendo, los Servlets son objetos de Java que siguen la especificación y el API correspondiente
y que sirven para dar la capacidad de generar contenido dinámico a un servidor http.
Veamos nuestro primer y sencillito ejemplo de Servlet, evidentemente hablamos del famoso 'Hola
Mundo'.
public class HolaMundoServlet extends HttpServlet {
public void doGet(HttpServletRequest request, HttpServletResponse response) throws
ServletException, IOException {
response.setContentType("text/html");
PrintWriter out = response.getWriter();
out.println("<HTML>");
out.println("<HEAD><TITLE>Hola Mundo</TITLE></HEAD>");
out.println("<BODY>");
out.print(" ¡HOLA MUNDO! ");
out.print("La fecha actual es: " +
java.util.GregorianCalendar.getInstance().getTime().toString());
out.println(" </BODY>");
out.println("</HTML>");
out.flush();
out.close();
}
}
Tema 4
9
Revisando el código tendríamos que darnos cuenta de:
1. Nuestro primer servlet y todos los servlets heredan de la clase HttpServlet.
2. Se implementan el método doGet. Lo estudiaremos en el apartado tercero.
3. Ambos métodos tienen como parámetros dos objetos: request y response. Estos objetos
están directamente relacionados con la petición al servidor y la respuesta devuelta por este.
4. En el objeto response se indica que la respuesta es un fichero html
(response.setContentType("text/html")).
5. Al response se le pide una salida donde escribir (PrintWriter out=response.getWriter()).
6. En la salida vamos escribiendo código HTML (out.println("<HTML>")).
7. Y finalmente se cierra dicho fichero de salida (out.close()).
¿Sencillo verdad? Ahora que ya empezamos a comprender los servlets puedes levantar el Tomcat
que te has instalado y desde un navegador vuelve a revisar los ejemplos de servlets que vienen
(http://localhost:8080/examples/servlets/index.html).
2.2 JSP (Básico)
Ya hemos visto que con los servlets se consigue mediante Java devolver contenido dinámico desde
un servidor http a los clientes. Si seguimos con la visión histórica, una vez que se crearon los
Servlets los programadores Java estarían muy emocionados por todas las posibilidades que ofrecían.
Ahora bien, ¿cuál es el problema más evidente que tienen los Servlets?.
Piénsalo un rato … vamos, quiero decir 30 segundos, pues es algo que salta a la vista.
¡EXACTO! Que dentro de las aplicaciones se encuentra embebido el código HTML. No existe
separación entre la parte de la presentación y la parte propia de programación de la lógica de la
aplicación.
Para aquellos que no vean claramente el problema os contaré como funcionan las cosas en el mundo
laboral. En las empresas suele existir un departamento de diseño gráfico, estos se encargan de la
parte visual y, normalmente, serán expertos en código HTML o, más bien, en Dreamweaver (es un
departamento donde gustan los colores y en pocas ocasiones se da que les guste los unos y ceros,
suelen ser licenciados en Bellas Artes). Y, por otro lado, tenemos el departamento de desarrollo,
estos son expertos en programación y, normalmente, ven en monocromo y la calidad visual de sus
diseños deja mucho que desear (nos importa más que funcione bien, solemos ser Ingenieros
Informáticos).
En casi todos los proyectos los diseñadores realizan la parte visual de un proyecto, el cliente lo
aprueba y finalmente eso se traduce en una maqueta HTML que se pasa al departamento de
desarrollo para que lo integre en la aplicación web. Si sólo tuviésemos Servlet, el programador
cogería el HTML lo integraría dentro del código Java y ya sería una página dinámica. Ahora bien,
¿qué pasa si hay que cambiar el diseño HTML? ¿Quién y cómo se realizan las modificaciones?
Sabiendo que cada departamento controla de una sola cosa, una solución estaría en juntar el
diseñador con el programador para que éste le diga en que clases está el HTML de tal página que
hay que modificar y así lo pueda ir cambiando el diseñador. Evidentemente, el diseñador ya no
tendría la posibilidad de utilizar ninguna herramienta visual (como Dreamweaver) para ir realizando
las modificaciones y para cada cambio hay que estar recompilando la clase para poder ver el
resultado. Otra solución sería que el diseñador hiciese las modificaciones sobre la maqueta para ver
el resultado rápidamente y una vez modificada, volver a pasar todo el código al programador para
que volviese otra vez a meterlo en los Servlets (seguro que el programador se iba a poner muy
contento). Finalmente, se puede optar a tener programadores con conocimiento de diseño HTML,
Tema 4
10
pero este caso no siempre se da.
¿No os suena todo un poco engorroso y poco viable para conseguir hacer proyectos de una forma
sencilla?
Pues evidentemente la mejor solución es intentar mantener esos ficheros HTML con su aspecto
prácticamente original, incrustándole pequeños trozos de código Java que hagan la página dinámica
(esto lo haría el programador) y enseñar al diseñador que esa parte no la debe tocar e incluso decirle
que con el Dreamweaver esa parte le va resultar invisible. Mantener el código HTML con el
mínimo código Java posible y llevarnos la lógica de negocio a las clases (Servlets y clases de
apoyo).
Pues esto es lo que se consigue con los JSPs. Resumiendo:




Mantener separadas la vista de la lógica de negocio.
Simplificar el desarrollo de las aplicaciones web mediante JSP, Javabeans y librerías de
etiquetas (JSLT).
Facilitar las modificaciones visuales (HTML).
Además, los contenedores web recompilan automáticamente los JSP cuando se realizan
modificaciones sobre dichos ficheros.
Veamos el ejemplo de HolaMundo ahora con JSP.
<HTML>
<HEAD><TITLE>Hola Mundo</TITLE></HEAD>
<BODY>
¡HOLA MUNDO!
La fecha actual es: <%= java.util.GregorianCalendar.getInstance().getTime().toString() %>
</BODY>
</HTML>
¿Significa esto que los JSP son mejores que los Servlets y no debemos utilizar estos últimos?.
Evidentemente no, en la práctica los que se hace es utilizar ambos, veremos como la tendencia
actual es desarrollar las aplicaciones web siguiendo el patrón MVC (Modelo-Vista-Controlador) y
los Servlets se encargan de hacer de controladores y los JSPs de implementar la vista.
2.3 Request and Response
La siguiente figura representa el proceso de petición y respuesta HTTP que se trata con los Servlet
(Request y Response):
Tema 4
11
En este proceso podemos distinguir tres aplicaciones: el navegador cliente o BROWSER (IE,
Mozilla, Opera, etc), el servidor web o WEB SERVER (Apache, IIS, etc) y el contenedor de
servlets o SERVLET CONTAINER (Tomcat, Resin, etc). Normalmente, los límites entre el
servidor web y el contenedor web son muy difusos por encontrarse dichas aplicaciones, en la
mayoria de los casos, en la misma máquina. A continuación vamos a aclarar los pasos que se llevan
a cabo por cada una de las aplicaciones.
El usuario desde su navegador hace la petición de una página y le sale el típico formulario de
petición de datos para que se registre. Lo que tiene en frente es una página HTML con un
formulario (FORM) que contiene campos de entrada de datos (INPUT) y un botón de enviar los
datos (SUBMIT).
Tema 4
12
El usuario envía el formulario y el servidor web se encarga de recibir la petición http (HTTP
REQUEST) y pasar dicha petición al contenedor de servlets que se encarga de crear un objeto que
representa la petición http (HttpServletRequest) y una sesión (HttpSession) que sirve para
identificar al mismo usuario durante toda la navegación.
El contenedor se encargará de decidir que Servlet tiene que ejecutarse, para ello utilizará el fichero
descriptor web.xml donde consultará que servlet se tiene que ejecutar según la ruta URL solicitada.
Una vez identificado el servlet, realizará las tareas programadas, por ejemplo, comprobar que llegan
todos los datos estan correctamente escritos en el formulario y si son correctos almacenar en la base
de datos, ejecutando las clases adecuadas (el servlet y las clases que pueda ser invocadas desde el
Tema 4
13
mismo).
Finalmente, en el servlet se creará la respuesta http (HttpServletResponse) que devolverá al
navegador cliente a través del servidor web. Esta respuesta normalmente será una página HTML
que en nuestro caso nos confirmaría el alta del registro del usuario.
La siguiente tabla resume que es lo que contiene la petición (request) y la respuesta (response)
HTTP:
REQUEST
La petición es la información que envía un
cliente a un servidor, esta información incluye
quién ha realizado la petición (dirección ip, tipo
navegador, etc) y la información propiamente
introducida por el usuario en el formulario.
RESPONSE
La respuesta es la información que envía el
servidor al cliente. Se debe indicar que tipo de
información se está devolviendo, si es texto
(html, plain) o binario (imagen). Además, se
devuelve también de cookies, headers, etc.
La petición http se compone de:
- header: información de quien envía la
petición.
- method: método de envío. Los dos más
Tema 4
14
conocidos son GET y POST, con el primero los
datos enviados se añaden a la URL, con el
segundo se envían como un dato.
- request data: Los datos propiamente.
2.4 Servlet (avanzado)
La siguiente imagen muestra la jerarquía de clases del API de Servlets en Java:
Cuando creamos un nuevo Servlet heredamos de la clase HttpServlet. Tal y como hemos
comentado en el apartado anterior, cuando llegan nuevas peticiones de un cliente, el contenedor
crea los objetos HttpServletRequest y HttpServletResponse y pasa dichos objetos al método
service() de la clase HttpServlet. Y finalmente, tenemos la clase HttpSession que se encarga de
mantener información relacionada con la sesión.
En la siguiente figura podemos ver los métodos que se implementan en un Servlet y el ciclo de vida
que presentan dichos métodos dentro del contenedor:
Tema 4
15
El método init() se llamará una única vez cuando se crea una instancia del Servlet (por defecto, se
crea una sola instancia de cada Servlet definido en el fichero web.xml en tiempo de despliegue de la
aplicación web). Éste método sirve para realizar tareas de inicialización (por ejemplo, crear las
conexiones a base de datos).
El método service() se llama cada vez que llega una nueva petición y éste método invoca doGet() o
doPost() dependiendo del tipo de petición http que haya llegado. Es en estos métodos donde se
programa realmente la aplicación. Dentro de las tareas que se llevan a cabo en dichos métodos
podemos resumir:





Extraer información enviada por el cliente (http parameter) de la petición http.
Leer (get) o escribir (set) atributos en los Scope Objects (veremos que son a continuación).
Llevar a cabo la lógica de negocio o el acceso a base de datos.
Opcionalmente, redirigir la petición a otro componente web (Servlet o JSP).
Crear el mensaje de respuesta http y enviarlo al cliente.
Finalmente, cuando la instancia del Servlet se elimina (por quitar la aplicación web del contenedor
o por detener el contenedor) se invoca el método destroy(). En éste método se llevan a cabo tareas
de finalización (por ejemplo, cerrar conexiones a base de datos).
Scope Objects.
Se denomina Scope Objects a los objetos que permiten compartir información guardada en sus
atributos entre distintos componentes de las aplicaciones web. Un ejemplo claro donde se utilizan
este tipo de objetos es en una aplicación de comercio electrónico donde se está manteniendo durante
toda la sesión de un usuario el carrito de la compra con la lista de los elementos seleccionados.
Existen cuatro tipos de objetos predefinidos dependiendo del tipo de alcance (scope) que tengan:




Web context o ServletContext (contexto): los objetos almacenados en éste alcance estarán
disponibles por todos los componentes web dentro de una misma aplicación web.
Session (sesión): el alcance de estos objetos es a nivel de la misma sesión.
Request (petición): los objetos con este alcance se comparten por una misma petición.
Page (página): los objetos están disponibles a nivel de página JSP.
Tema 4
16
Dentro del código de nuestras aplicaciones la forma de acceder a los valores guardados en estos
objetos es idéntica, mediante el método setAttribute() para almacenar valores y getAttribute() para
recuperarlos.
HTTPSession.
Vamos a hablar más detalladamente de los objetos que tienen el alcance de sesión por ser los que se
utilizan más frecuentemente en las aplicaciones.
Lo primero que debemos recordar es lo que ya se dijo en el primer tema del protocolo HTTP que
es un protocolo sin estado. Las aplicaciones web utilizan este protocolo para realizar la
comunicación entre cliente y servidor, para ello es necesario que se dote a los servidores con la
capacidad de mantener la lista de peticiones sucesivas desde un mismo cliente simulando una
sesión.
Como antes dijimos, el ejemplo típico es una tienda de comercio electrónico donde es deseable que
un usuario que se conecte a nuestra tienda tenga la sensación de que las peticiones no sean
inconexas sino que formen parte de una misma sesión y así se pueda mantener el carrito de la
compra durante dicha sesión.
public class ComprarCarritoServlet extends HttpServlet {
public void doGet (HttpServletRequest request, HttpServletResponse response) throws
// Recuperamos de la sesión del usuario el carrito de la compra
HttpSession session = request.getSession();
ShoppingCart carrito = (ShoppingCart) session.getAttribute ("carrito");
...
// Calculamos el precio total de la compra realizada por el usuario
double total = carrito.getTotal();
}
}
Otro ejemplo muy recurrido es en las aplicaciones de banca donde se nos pide autenticarnos para
poder recuperar nuestros datos bancarios. Si no mantenemos la información del usuario autenticado
en la sesión, cada vez que tengamos que recuperar algún dato bancario (listado de cuentas, saldos,
movimientos, etc) tendríamos que volver a solicitar que el usuario se autenticase. Sin embargo, lo
normal es guardar en la sesión el identificador del usuario y en cada consulta recuperarlo de dicho
objeto.
2.5 JSP (Avanzado)
Tal y como dijimos en la introducción a los JSPs, la principal característica que presentan respecto a
los Servlet es la separación entre la presentación y la lógica de negocio de la aplicación. En la
siguiente figura vemos a la izquierda un Servlet donde la lógica de la aplicación y la
presentación están juntos, a la derecha podemos ver como utilizando conjuntamente los
Servlets con los JSPs mejoramos la aplicación dividiendo las tareas, pasando el Servlet a
realizar tareas de controlador y dejando a la JSP la presentación.
Tema 4
17
¡LOS JSPs SON SERVLETS!
Es importante reseñar que el contenedor (Tomcat) se encarga de coger cada JSP de las
aplicaciones web, traducirlos y compilarlos generando los correspondientes Servlet y clases de
forma transparente. Para comprobarlo, podemos ir al directorio donde tengamos instalado el
Tomcat y revisar el contenido del directorio 'work' que es donde se generan dichos ficheros
intermedios.
Podemos ver que se han añadido los métodos init(), destroy() y service(), es decir, los mismos
métodos que en los Servlets. Se tienen como parámetros del método service las instancias de los
objetos request y response, y además, se crean variables que referencian a los Scope Objects
comentados en el apartado anterior (pageContext, session, application) y, por último, tenemos la
variable out que referencia a la salida del response.
Existen tres formas de añadir código Java en una JSP:
1. Expresiones: las expresiones JSP se utilizan para añadir el valor resultante de una expresión
Java convertido a un string en la página HTML devuelta al navegador. El formato es <%=
expresion %>.
2. Scriptlets: cuando se quiera introducir varias instrucciones Java se debe incluir dentro de
estos bloques. El formato es <% código Java %>.
3. Declaraciones: estos bloques se utilizan para definir variables y métodos que vayan a ser
Tema 4
18
utilizados en el JSP. En éste código se realizan declaraciones para inicialización y
finalización pues es código que se incluye en los métodos Init y Destroy. El formato es <%!
Código declarativo %>.
Javabeans.
Los Javabeans son clases de Java que siguen una serie de reglas de diseño. Estas reglas están
relacionadas con los atributos de la clase y los métodos de acceso a dichos atributos. Cualquier
clase de Java que siga dichas reglas puede ser un Javabean.
Los atributos de un Javabeans han de ser:



Simples, es decir, tienen que contener un valor único o indexado dentro un array.
De lectura/escritura, sólo lectura o sólo escritura.
El acceso a dichos atributos se tiene que hacer definiendo métodos setXXX() y getXXX(),
donde XXX es el nombre de un atributo. Además, si un Javabean implementa algún método
constructor debe ser un constructor que no tenga ningún parámetro.
Los Javabeans se pueden utilizar dentro de los JSP mediante etiquetas que permiten crear y acceder
a los atributos de dichos objetos de una forma más sencilla que con scriplet. En el siguiente ejemplo
podemos ver en la izquierda el código que se necesita para acceder al objeto del carrito de la
compra que se encuentra en la sesión mediante scriplet y en la derecha el mismo acceso pero
mediante el uso de etiquetas JSP para acceso a Javabeans.
<%
ShoppingCart carrito =
(ShoppingCart)session.getAttribute("carrito");
// Si el usuario no tiene en sesión un objeto
carrito es necesario crear uno nuevo.
if (carrito == null) {
carrito = new ShoppingCart();
session.setAttribute("carrito", carrito);
}
%>
<jsp:useBean id="cart"
class="cart.ShoppingCart" scope="session"/>
2.6 JSTL
Asociado a los JSPs aparece las librerías de etiquetas JSTL (JavaServer Pages Standard Tag
Library). Estas librerías de etiquetas encapsulan funcionalidades comunes que se realizan dentro
de los JSPs, por ejemplo, en vez de mezclar código HTML con scriptlet para realizar un bucle y
pintar una lista, se define una nueva etiqueta que realiza dicha labor.
A continuación resumimos las ventajas que ofrece diseñar JSPs utilizando las librerías de etiquetas:


No tenemos que escribir el código que encapsulan nosotros sino que es código
implementado y probado (Reusabilidad).
Sólo necesitamos aprender y utilizar un sencillo conjunto de etiquetas que vienen
Tema 4
19


proporcionadas por las plataformas J2EE.
Estas etiquetas suelen estar más optimizadas que el código que nosotros implementásemos.
Mediante la utilización de etiquetas la portabilidad de las aplicaciones JSP sigue
manteniéndose.
En la siguiente tabla se presentan los distintos grupos de librerías de etiquetas que nos podemos
encontrar en la versión 1.1 de JSLT:
Core (prefijo: c)
XML (prefijo: x)
Internationalization
(prefijo: fmt)
Database (prefijo: sql)
Functions (prefijo: fn)
Soporte de variables, control de flujo y gestión de URL.
Control de flujo, transformaciones.
Formateo de mensajes, números y fechas.
Realización de consultas y actualizaciones SQL.
Longitud de collections, manipulación de cadenas.
En la siguiente tabla podemos ver en la izquierda una página JSP con scriptlet donde se muestra el
contenido de una agenda de clientes y en la derecha el mismo resultado se obtiene utilizando las
librerías de etiquetas.
<%@ page
import="com.cursojava.model.Cliente,
java.util.*"%>
<p><h1>Listado de clientes</h1></p>
<%
List agenda =
(List)request.getAttribute("agenda");
Iterator agendaIter = agenda.iterator();
while(agendaIter.hasNext()) {
Cliente cliente = (Cliente)agendaIter.next();
if( (cliente!=null ) &&
(cliente.getLastName()!=null) &&
(cliente.getNombre().length() > 0)) {
%>
<%=cliente.getNombre()%><br/>
<%
}
else {
%>
INDEFINIDO<br/>
<%
}
}
%>
<p><h5>Última actualización: <%=new
Date()%></h5></p>
<%@ taglib prefix="c"
uri="http://java.sun.com/jstl/core" %>
<p><h1>Listado de clientes</h1></p>
<c:forEach items="${agenda}" var="cliente">
<c:choose>
<c:when test="${not empty cliente.nombre}" >
<c:out value="${cliente.nombre}"/><br/>
</c:when>
<c:otherwise>
INDEFINIDO<br/>
</c:otherwise>
</c:choose><br/>
</c:forEach><br/>
<jsp:useBean id="now" class="java.util.Date" />
<p><h5>Last Updated on: <c:out
value="${now}"/></h5></p>
Tema 4
20
3 Frameworks: Struts, JSF y Spring
3.1 Patrón MVC
En este apartado vamos a estudiar el patrón MVC (Model-View-Controler), aunque ya se le dejó
como tarea al alumno estudiar dicho patrón en el tema 1. Es necesario que el alumno comprenda
perfectamente dicho patrón para poder entender la base en la que se fundamentan los frameworks
que posteriormente se presentarán en esta lección.
La siguiente figura muestra el patrón MVC, donde se pueden ver los componentes que lo integran y
como interactúan entre ellos:
Mediante este patrón se consigue definir una arquitectura de capas para una aplicación Web. La
siguiente tabla resume las tareas que se llevan a cabo por cada componente del patrón:
MODEL o capa
de lógica de
negocio
VIEW o capa de
presentación
- Define los datos y la lógica de negocio de la aplicación.
- En esta capa se llevan a cabo las consultas a BD, los procesos del negocio y
las ordenes de procesamiento.
- Nos encontraremos con los datos y el comportamiento que sea independiente
de la presentación
- Muestra la información según el tipo de cliente (HTML, XML, etc).
- Presenta los resultados de la lógica de negocio
- No trata como ni de donde se obtiene la información (esto es parte del
modelo)
Tema 4
21
CONTROLLER - Se utiliza como conector entre la interacción del cliente y los servicios
o capa
ofrecidos por el servidor.
controladora
- Cuando se realiza una petición al controlador, éste decide quién va a gestionar
dicha petición y que información se debe devolver.
Este patrón no es exclusivo de las aplicaciones web sino que se puede utilizar en cualquier tipo
de aplicación, téngase en cuenta que es un patrón de diseño aportado originariamente por el
lenguaje Smalltalk para el desarrollo de aplicaciones con dicho lenguaje (http://stwww.cs.uiuc.edu/users/smarch/st-docs/mvc.html).
3.2 Struts
Struts es uno de los primeros frameworks que surgen para el desarrollo de aplicaciones web java
siguiendo el patrón MVC. Es un proyecto open source que se encuentra desarrollado en Apache
Jakarta (http://struts.apache.org/1.3.8/).
Las características principales que presenta Struts son:




Es un framework MVC.
Se utiliza para construir aplicaciones web utilizando Servlets y JSPs.
Esta desarrollado utilizando patrones de diseño (Singleton, composition view, delegate).
Incluye un librería de etiquetas para facilitar el desarrollo de los JSPs.
Struts está enfocado sobre todo en el Controlador, por eso se dice que es un framework
independiente del Modelo y la Vista. Struts se integra con cualquier tipo de tecnología utilizada
en el Modelo (JavaBeans, POJOs, EJBs, etc) y en la Vista (JSPs, JSTL, Velocity, etc)
En la siguiente figura presentamos la estructura y el funcionamiento de Struts:
Tema 4
22
Paso 1.
En este entorno, todas las peticiones que se realicen se deben corresponder con
alguna acción que debe estar mapeada en el fichero de configuración XML de Struts
(struts-config.xml). Ahí se especifican todas las relaciones entre acciones y clases,
formularios y clases, acciones y jsps de presentación, que globalmente conforman el
“mapa” de la aplicación.
Pasos 2 y 3. Cuando la petición realizada implique el envío de un formulario por parte del cliente,
en dicho fichero se podrá configurar una clase ActionForm asociada a dicha acción y
si se debe realizar algún tipo de validación. Struts se encargará de recuperar los
parámetros enviados, instanciar la clase ActionForm adecuada, poblar sus atributos
(que deberán nombrarse igual que los parámetros) y realizar las validaciones
adecuadas. Cuando todo sea correcto, Struts se encargará de pasar dicha instancia de
ActionForm a la acción solicitada.
Pasos 4, 5 y Una acción se corresponderá con una clase Java (heredera de la clase Action de
6.
Struts). En este punto Struts se encarga de invocar el método perform() de dicha
clase Action y será en esta clase donde se realizarán las acciones que se hayan
implementado para llevar a cabo la lógica de negocio (guardar en BD un registro,
consultar un listado de BD, enviar un email de notificación, etc), bien en la propia
clase o invocando los objetos de negocio correspondientes.
Pasos 7, 8 y Una vez llevada a cabo la lógica de negocio, el controlador de Struts se encargará de
9.
redirigir el flujo a la parte de la vista. Se invocarán el JSP asociado a la petición y se
construirá la página de resultado utilizando si fuese necesario los datos
proporcionados por los objetos de negocio, devolviendo dicha página al cliente.
A continuación se indican como configurar los ficheros de una aplicación web para que se utilice
Struts.
Fichero descriptor web.xml
Las aplicaciones desarrolladas con Struts son aplicaciones Web Java y, por lo tanto, tienen que
seguir la estructura definida en apartados anteriores y también tendrán el fichero descriptor
web.xml.
En este fichero se necesita configurar la siguiente información:



La definición y el mapeo URL del ActionServlet.
Añadir el fichero de configuración de struts como parámetro de inicialización. (strutsconfig.xml).
Definir la librería de etiquetas de Struts.
Fichero configuración struts-config.xml
Este es el fichero principal de Struts. En este fichero se encuentran las siguientes etiquetas XML
que definen los siguientes elementos:


<form-beans> contiene las definiciones de los FormBean (formularios) indicando el nombre
y el tipo (nombre de la clase).
<action-mapping> contiene la definición de las acciones. Se utiliza una etiqueta n <action>
para cada una de las URLs que los navegadores pueden solicitar y quien será el Servlet
(ActionServlet) encargado de responder a dicha petición.
Tema 4
23

<global-forwards> contiene la definición de los forwards comunes a toda la aplicación web.
Formularios.
En Struts se pueden utilizar dos tipos de formularios: ActionForm y DynaActionForm, que se
definen en el fichero struts-config.xml. Con los primeros tenemos que crear clases que hereden de
ActionForm y que únicamente tengan atributos y los métodos set y get de acceso a los mismo. Con
el segundo tipo (DynaActionForm) no es necesario crear nuevas clases sino que en fichero strutsconfig.xml se listan los atributos o propiedades que lo componen y el tipo de cada propiedad.
Para cada uno de los formularios definidos en struts-config.xml, el controlador de Struts realiza las
siguientes tareas:



Comprobar si el formulario (objeto) se encuentra en la sesión, en el caso de que no exista
dicho objeto, se crea uno nuevo.
Llamar a los métodos set del objeto formulario con cada parámetro de la petición cuyo
nombre sea igual a alguna propiedad del formulario.
Pasar el formulario con sus atributos actualizados como parámetro del método execute() de
la acción que se haya invocado.
Acciones.
Las acciones en struts están enfocadas en desarrollar toda el flujo de control de la aplicación.
Cuando el controlador principal de Struts recibe una petición, según la parametrización del fichero
struts-config.xml redirige el flujo de control a la acción adecuada. La acción es una clase que hereda
de org.jakarta.struts.action.Action y que tendrá un método execute() donde se encontrará la lógica
de negocio que tiene que llevarse a cabo (bien dentro de este ActionServlet o llamando a otras
clases auxiliares). Finalmente, devuelve un objeto ActionForward que define el destino (JSP, otra
accion, etc) donde debe dirigirse la ejecución.
3.3 JSF
JSF (Java Server Faces) es el segundo framework que vamos a estudiar basado en el patrón MVC.
Al igual que Struts, JSF pretende normalizar y estandarizar el desarrollo de aplicaciones web. Hay
que tener en cuenta JSF es posterior a Struts, y por lo tanto se ha nutrido de la experiencia de éste,
mejorando algunas de sus deficiencias.
A continuación se presentan algunos de los puntos por los que JSF parece una tecnología muy
interesante:




Hay una serie de especificaciones que definen JSF:JSR 127, JSR 252, JSR 276.
JSF trata la vista (el interfaz de usuario) de una forma similar al estilo de Swing, Visual
Basic o Delphi (Drag & Drop), donde la programación del interfaz se hace a través de
componentes y basada en eventos (se pulsa un botón, cambia el valor de un campo, ...).
JSF es muy flexible. Por ejemplo, nos permite crear nuestros propios componentes, o crear
nuestros propios “render” para pintar los componentes según nos convenga. Luego no se
limita a navegadores HTML.
Es muy sencillo de utilizar pero sobre todo si se tiene un IDE que ofrezca esta capacidad.
JSF no puede competir en madurez e integración en las aplicaciones actuales con Struts, pero si
Tema 4
24
puede ser una opción muy recomendable para nuevos desarrollos, sobre todo si todavía no tenemos
experiencia con Struts. Aunque hay que tener claro que para poder explotar la verdadera potencia de
JSF es necesario utilizar IDEs que proporcionen esta tecnología.
En la siguiente imagen podemos ver la estructura y funcionamiento de JSF de forma sencilla.
Como en otros frameworks basados en el patrón MVC, JSF tiene un servlet controlador que se
denomina FacesServlet y que se encarga de recibir las peticiones y ejecutar las acciones definidas
en el fichero de configuración faces-config.xml. Las páginas JSF se construyen como un árbol de
componentes de Interfaz de Usuario (UI Components). Estos componentes se pueden asociar con
un modelo de objetos denominado backing beans, estos objetos son los encargados de
implementar la lógica de negocio, permitiendo mapear parámetros de la petición sobre atributos
de estos objetos y eventos del cliente sobre sus métodos. Las respuestas se construyen cogiendo los
componentes de Interfaz y transformándolos en un tipo de cliente particular (por ejemplo, o un
navegador HTML o un navegador VML de un teléfono móvil).
A continuación se indican como configurar los ficheros de una aplicación web para que utilice JSF.
Fichero descriptor web.xml.
En este fichero se necesita configurar la siguiente información:


La definición y el mapeo URL del FacesServlet.
Añadir varios parámetros del contexto.
Fichero configuración faces-config.xml.
Este es el fichero principal de JSF. En este fichero se encuentran las siguientes etiquetas XML que
definen los siguientes elementos:


<navigation-rule> contiene las reglas de navegación de la aplicación. Estas reglas
determinan que página va después de que un usuario pinche un botón o un enlace.
<managed-bean> contiene la declaración de los bean manegados o backing bean. Estos son
objetos de la capa del modelo que mantienen datos, validaciones, gestiones de eventos y la
lógica de navegación.
Páginas JSF.
La creación de las páginas es una tarea del desarrollador. Esta tarea implica definir los componentes
UI que tendrá la página, mapear dichos componentes sobre el modelo de objetos (backing beans) y
añadir, si es necesario, las llamadas a los eventos del modelo.
Tema 4
25
Backing beans u objetos del modelo.
Como ya hemos dicho, los componentes de la Interfaz de Usuario (UI) se pueden mapear sobre las
propiedades (atributos) de los objetos del modelo. Además, los eventos que se generan en los
navegadores (pulsar un botón, cambiar el valor seleccionado de una lista, etc) también se pueden
relacionar con métodos de dichos beans.
3.4 Spring
Spring es un framework ligero que se puede utilizar tanto para desarrollar aplicaciones web J2EE
como aplicaciones de escritorio Java.
El objetivo de Spring es no ser ‘intrusivo’, es decir, aquellas aplicaciones configuradas para usar
beans (clases) mediante Spring no necesitan depender de interfaces o clases propias del framework
(como ocurre en Struts donde los formularios y las acciones heredan de clases de Struts) sino que la
configuración particular de la aplicación se definirá en ficheros descriptores XML. De esta forma
Spring permite que objetos del negocio y de acceso a datos sean reutilizables.
Las características principales que proporciona Spring son:






Gestión de configuración basada en JavaBeans, aplicando los principios de Inversión de
Control (IoC). Esto hace que la configuración de aplicaciones sea rápida y sencilla.
Un gestor de transacciones sencillo, permitiendo añadir nuevos gestores de transacción
(pluggables), y haciendo sencilla la demarcación de transacciones sin tratarlas a bajo nivel.
Se incluyen estrategias genéricas para JTA y un único JDBC DataSource. En contraste con
el JTA simple o EJB CMT, el soporte de transacciones de Spring no está atado a entornos
J2EE.
Una capa de abstracción JDBC que ofrece una jerarquía propia de
Excepciones, evitando la necesidad de obtener de SQLException los códigos que cada
gestor de base de datos asigna a los errores, simplifica el manejo de errores, y reduciendo la
cantidad de código necesario.
Integración con Hibernate, JDO e iBatis SQL Maps en términos de soporte a
implementaciones DAO y estrategias con transacciones. Especial soporte a Hibernate
añadiendo convenientes características de IoC, y solucionando muchos de los comunes
problemas de integración de Hibernate. Todo ello cumpliendo con las transacciones
genéricas de Spring y la jerarquía de excepciones DAO.
Funcionalidad AOP. Se puede aplicar AOP a cualquier objeto gestionado por Spring,
añadiendo aspectos como gestión de transacciones declarativa.
Un framework MVC (Model-View-Controller), construido sobre el núcleo de Spring. Este
framework es altamente configurable vía interfaces y permite el uso de múltiples tecnologías
para la capa vista como pueden ser JSP, Velocity,Tiles, iText o POI. De cualquier manera
una capa modelo realizada con Spring puede ser fácilmente utilizada con una capa web
basada en cualquier otro framework MVC, como Struts, WebWork o Tapestry.
La arquitectura en capas de Spring ofrece mucha de flexibilidad. Toda la
funcionalidad está construida sobre los niveles inferiores. Por ejemplo se puede utilizar la gestión
de configuración basada en JavaBeans sin utilizar el framework MVC o el soporte AOP.
Tema 4
26
Tema 4
27
4 AJAX
4.1 Introducción
A pesar de haberlo introducido en el tema 2, vamos a hacer un nuevo repaso de los conceptos en los
que se basa AJAX.
AJAX es una tecnología que se utiliza en las aplicaciones Web (en todas, no solo en J2EE), que
ayuda a que las aplicaciones sean más rápidas, sencillas y "amigables" para el usuario.
AJAX funciona en todos los navegadores "modernos", es decir, en versiones con pocos años de
antigüedad. Esto es debido a que AJAX está basado en estándares que son implementados y
"entendidos" por gran parte de los navegadores. En concreto, AJAX está basado en
JavaScript, XML, HTML y CSS.
Como decíamos en el tema 2, sin AJAX, si un usuario quiere hacer una petición al servidor, lo tiene
que hacer mediante una petición GET o POST que implica que la página tiene que recargarse
completamente. Usando AJAX, conseguimos hacer peticiones "en background" usando
JavaScript y, al recibir la respuesta, tratarla sin necesidad de recargar la página. Esta
comunicación con el servidor se hace mediante el objeto JavaScript XMLHttpRequest.
AJAX no es mucho más que esto, en el resto de la lección vamos a ver los conceptos básicos y un
ejemplo de uso.
4.2 Principales elementos de AJAX
Como decíamos antes, la clave de AJAX es el objeto JavaScript XMLHttpRequest.
Los distintos navegadores existentes (Internet Explorer, Mozilla FireFox, Opera, etc.) crean este
objeto de diferentes formas, pero una vez creado el uso es el mismo.
No olvidemos que AJAX es JavaScript, de modo que se ejecuta en el cliente (navegador).
Para crear el objeto, hay que tener en cuenta al escribir nuestro código que puede ejecutarse en
diferentes navegadores, de modo que la mejor forma de crearlo es mediante el uso de
excepciones. El siguiente código es el que se suele usar:
try {
// Firefox, Opera 8.0+, Safari
xmlHttp=new XMLHttpRequest();
Tema 4
28
} catch (e) {
// Internet Explorer 6.0 o superiores
try {
xmlHttp=new ActiveXObject("Msxml2.XMLHTTP");
} catch (e) {
// Internet Explorer 5.5 o superiores
try {
xmlHttp=new ActiveXObject("Microsoft.XMLHTTP");
} catch (e) {
alert("Your browser does not support AJAX!");
return false;
}
}
}
Con lo anterior ya tendríamos creado el objeto para enviar peticiones y gestionarlas con AJAX.
Aún no estamos preparados para enviar la petición al servidor, antes tenemos que ver las tres
principales propiedades del objeto XMLHttpRequest.
- La propiedad onreadystatechange guardará la función que procesará la respuesta del servidor.
- La propiedad readyState tendrá el valor del estado de la respuesta (response) del servidor. Los
posibles valores de esta propiedad los vemos en la siguiente tabla:
Estado
Descripción
0
La petición no está inicializada
1
La petición ha sido preparada
2
La petición ha sido enviada
3
La petición está en proceso
4
La petición ha sido completada
- La propiedad responseText contendrá la respuesta del servidor.
Con esto ya tendremos lo necesario para tratar la respuesta, pero nos falta lo necesario para enviar
la petición. Para ello usamos los métodos "open" y "send" del objeto XMLHttpRequest.
En el siguiente apartado vemos un ejemplo de código para asimilar los conceptos vistos hasta el
Tema 4
29
momento.
4.3 Ejemplo de uso de AJAX
Una vez vistas las piezas clave de AJAX, llega el momento de ponerlas en práctica, para ello,
vamos a crear una aplicación web muy simple con un "servlet" y con una "jsp".
La idea de esta aplicación es que la "jsp" tendrá un campo para insertar un texto, en concreto una
provincia y, cuando escribamos sobre ella, mediante AJAX se enviará una petición al servidor para
que nos devuelva un texto con las provincias que empiecen igual que el texto que estamos
introduciendo. El típico ejemplo para sugerir al usuario opciones.
Esto es muy sencillo, solamente tenemos que crear una aplicación Web tal y como hemos visto en
este tema (llamadla "cursoAJAX" y desplegadla en ese contexto para que el código que os pongo
abajo os funcione a la primera).
Luego cread una "jsp" directamente sobre "WebContent" llamada "index.jsp" y en el fichero dejad
este contenido:
<%@ page language="java" contentType="text/html; charset=ISO-8859-1"
pageEncoding="ISO-8859-1"%>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>Mi aplicación AJAX</title>
<script type="text/javascript">
function mostrarSugerencia(dato) {
if (dato=='')
document.getElementById("sugerencia").innerHTML='';
else {
var xmlHttp;
try {
// Firefox, Opera 8.0+, Safari
xmlHttp=new XMLHttpRequest();
} catch (e) {
// Internet Explorer
try {
xmlHttp=new ActiveXObject("Msxml2.XMLHTTP");
} catch (e) {
try {
xmlHttp=new ActiveXObject("Microsoft.XMLHTTP");
} catch (e) {
alert("Your browser does not support AJAX!");
return false;
}
Tema 4
30
}
}
xmlHttp.onreadystatechange=function() {
if(xmlHttp.readyState==4){
document.getElementById("sugerencia").innerHTML=xmlHttp.responseText;
}
}
xmlHttp.open("GET","/cursoAJAX/MiServlet?dato=" + dato,true);
xmlHttp.send(null);
}
}
</script>
</head>
<body>
<form>
Provincia: <input type="text" onkeyup="mostrarSugerencia(this.value)" id="provincia">
Sugerencia: <span id="sugerencia"></span>
</form>
</body>
</html>
Luego cread un "Servlet" y llamadlo "MiServlet" en un paquete llamado "mipaquete". En este
"Servlet" meted el siguiente código:
package mipaquete;
import java.io.IOException;
import java.io.PrintWriter;
import java.util.HashMap;
import java.util.Map;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
/**
* Servlet implementation class for Servlet: MiServlet
*
*/
public class MiServlet extends javax.servlet.http.HttpServlet implements javax.servlet.Servlet {
static final long serialVersionUID = 1L;
static String[] provincias = {"Albacete","Madrid","Barcelona"};
/* (non-Java-doc)
Tema 4
31
* @see javax.servlet.http.HttpServlet#HttpServlet()
*/
public MiServlet() {
super();
}
/* (non-Java-doc)
* @see javax.servlet.http.HttpServlet#doGet(HttpServletRequest request, HttpServletResponse
response)
*/
protected void doGet(HttpServletRequest request, HttpServletResponse response) throws
String sugerencia = "";
//aquí obtenemos lo que ha escrito hasta ahora el usuario
String datoInsertado = request.getParameter("dato");
for (int i = 0; i < provincias.length; i++) {
if (provincias[i].startsWith(datoInsertado))
sugerencia += provincias[i];
}
if (sugerencia.length()==0)
sugerencia="No conozco ninguna provincia que empiece asi. OJO con las mayusculas";
response.setContentType("text/html");
PrintWriter out = response.getWriter();
out.print(sugerencia);
out.flush();
out.close();
}
}
Y una vez echo esto, meted el mapeo para el servlet en el fichero "web.xml". Este fichero debería
quedar así:
<?xml version="1.0" encoding="UTF-8"?>
<web-app id="WebApp_ID" version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/webapp_2_4.xsd">
<display-name>aplicacion ajax</display-name>
<servlet>
<description></description>
<display-name>MiServlet</display-name>
<servlet-name>MiServlet</servlet-name>
Tema 4
32
<servlet-class>mipaquete.MiServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>MiServlet</servlet-name>
<url-pattern>/MiServlet</url-pattern>
</servlet-mapping>
<welcome-file-list>
<welcome-file>index.jsp</welcome-file>
</welcome-file-list>
</web-app>
Una vez hecho esto, si arrancamos el servidor y escribimos en un navegador la url
http://localhost:8080/cursoAJAX/index.jsp se cargaría la página. Y si probamos a escribir en el
cuadro de texto, tras cada pulsación se nos mostrará una sugerencia. Mi memoria no alcanzaba a
recordar más provincias que "Albacete", "Madrid" y "Barcelona", y tened cuidado con las
mayúsculas!!! Probad y mejorad el código!
Bueno, pues con esto ya debería estar funcionando la aplicación. Ahora vamos a explicar un poco su
funcionamiento (id mirando el código mientras vais leyendo las siguientes líneas):

Gracias al evento "onkeyup", se llama la función javascript "mostrarSugerencia", pasándole
como parámetro el valor introducido hasta el momento en el campo "provincia".

La función javascript "mostrarSugerencia" obtiene el objeto apropiado según el navegador
para usar AJAX, y después define la función que se ejecutará cuando haya cambios en el
estado de la petición al servidor.

Esta función simplemente escribe la respuesta recibida en el "span" que se definió a tal
efecto.

Tras la definición, se hace la petición a nuestro servlet pasándole el texto introducido hasta
el momento.

Cuando el "servlet" recibe la petición, calcula la sugerencia y la devuelve.

Cuando es devuelta, el estado de la petición pasa a ser 4 ("request completada") con lo que
se ejecuta la función javascript que hemos definido, actualizando así el valor contenido en el
"span".

¡¡¡¡Nos hemos comunicado con el servidor y actualizado nuestra página sin recargar!!!!
Sencillo, ¿no?. Y para que veáis las ventajas de AJAX, imaginad que lo tuvierais que hacer sin
AJAX, y además pensad que la página es muchísimo más compleja y pesada que nuestra simple
"index.jsp".
Tema 4
33
4.4 Otras posibilidades
Ya hemos visto un ejemplito de uso básico suficiente para entender la utilidad de AJAX. Pero por
supuesto existen muchos más aspectos interesantes y útiles en AJAX. Un enlace muy interesante
y
bastante
didáctico
para
aprender
más
aspectos
de
AJAX
es
http://www.w3schools.com/ajax/default.asp.
Supongo que ya estaréis enamorados de AJAX pero antes deberíais saber que también existen
frameworks para usar AJAX que nos proporcionan más funcionalidades, simplifican nuestros
desarrollos, mejoran la calidad, aumentan el rendimiento, proporcionan integración con otros
entornos, etc. A continuación os pongo un par de ellos que he usado y son bastante útiles.
- AjaxAnyWhere (http://ajaxanywhere.sourceforge.net)
- DWR (http://getahead.org/dwr/)
Y, por si no tenéis suficiente, aquí tenéis una página con un listado muy amplio
http://ajaxpatterns.org/Java_Ajax_Frameworks
Tema 4
34
5 ANEXO
5.1 INSTALACIÓN DE TOMCAT
Vamos a proceder a realizar la instalación del contenedor de Servlets Tomcat 6. Esta aplicación se
puede descargar desde la siguiente dirección http://tomcat.apache.org. Podemos encontrarnos con la
versión ejecutable o ZIP. La primera realizará la instalación mediante un Wizard y, además,
configura un servicio de Windows para poder administra el servidor Apache. Con la versión ZIP no
se configura ningún servicio de Windows y seremos nosotros los encargados de parametrizar
adecuadamente la aplicación.
A continuación vamos a mostrar una guía para instalar la versión ejecutable
Una vez tengamos el instalable comenzaremos la instalación haciendo doble clic sobre el
ejecutable. Lo primero que debemos hacer es aceptar la licencia que se nos presenta (I Agree):
Seleccionamos el tipo de instalación del servidor que se va a realizar, ampliamos la normal para que
incluya también los ejemplos (examples):
Tema 4
35
Decidimos el directorio en que va a ser instalado el programa:
Se solicita los parámetros de inicialización del servidor, donde tenemos que decidir el puerto donde
va a escuchar el servidor (8080 por defecto, pero se puede seleccionar cualquier otro que este libre)
y el usuario y password que se utilizará para la aplicación de administración del servidor.
Tema 4
36
Ahora nos solicita que le indiquemos la ruta donde tenemos instalada la Java Runtime (JRE) e
iniciamos la instalación pulsando el botón de Install.
Completada la instalación pinchamos en Finish.
Tema 4
37
Se ha finalizado con la instalación y comprobamos el acceso en el menú de inicio que se ha creado
para administrar el servidor Tomcat. Pinchando en ‘Configure Tomcat’.
Nos aparece una ventana para poder administrar el servidor Tomcat que se ha instalado como un
servicio de Windows. Desde esta ventana podemos configurar el servicio de Windows para que se
arranque de forma manual, automática o deshabilitarlo. Si pinchamos en Start arrancamos el
servidor de Tomcat.
Tema 4
38
Podemos comprobar que se ha arrancado correctamente y podemos tener acceso a la herramienta de
administración, a la documentación y a los ejemplos conectándonos a la dirección
http://localhost:8080 con nuestro navegador (IE, Mozilla, etc).
Tema 4
39
Pasamos a continuación a explicar como realizar la instalación de la versión ZIP del instalable del
Tomcat.
Descomprimimos el fichero en el directorio donde deseamos tener la aplicación. Y podemos ver las
carpetas que componen el instalable.
Abrimos una ventana de comandos, nos situamos en el directorio bin e intentamos lanzar el tomcat
con la llamada a startup.
Vemos que nos da un error y nos pide que se definan las variables de entorno JAVA_HOME O
JRE_HOME. Configuramos la variable JAVA_HOME para que apunte al directorio donde
Tema 4
40
tengamos instalado la JDK 1.5.
Volemos a llamar a startup para que arranque el Tomcat y si todo es correcto, abre otra ventana de
comandos donde tendremos el log del Tomcat.
Al igual que para la versión ejecutable, para comprobar que se ha arrancado correctamente nos
conectamos a la dirección http://localhost:8080 con nuestro navegador (IE, Mozilla, etc).
Tema 4
41
5.2 INTEGRACIÓN DE TOMCAT Y ECLIPSE
Ya tenemos instalado en nuestro ordenador el Tomcat y funciona correctamente. Vamos a ver como
se integra dentro de nuestro entorno de desarrollo Eclipse.
Arrancamos el Eclipse y nos vamos a la opción de menú Window -> Preferences…
Dentro de la ventana de Preferences, seleccionamos la opción Server -> Installed Runtimes y dentro
de esta ventana es donde se gestionan los servidores de aplicaciones instalados. Pinchamos en el
botón Add para añadir y configurar nuestro servidor Tomcat:
Tema 4
42
Desplegamos la carpeta de Apache y seleccionamos la versión de nuestro Apache Tomcat :
Pinchando en el botón de Browse seleccionamos el directorio donde hayamos instalado nuestra
versión del Tomcat y del desplegable debemos seleccionar la JRE/JDK con la que queremos que se
despliegue el servidor:
Tema 4
43
Pinchando en Finish terminamos la instalación y configuración del Tomcat dentro del Eclipse y
podemos ver como se ha añadido dentro de los servidores instalados:
Volviendo al Eclipse, en la vista Servers podemos ver como aparece el servidor Tomcat que hemos
configurado. Pinchando con el botón de la derecha aparece el menú emergente que nos permitirá
administrar dicho servidor:
Tema 4
44
Si pinchamos en la opción Start iniciamos dicho servidor y podemos ver el log que devuelve dicho
servidor para notificarnos que está arrancado correctamente y en que puerto está escuchando
(8080):
Tema 4
45
5.3 IMPORTACIÓN, CONFIGURACIÓN, FUNCIONAMIENTO APP STRUTS
A continuación vamos a detallar los pasos que hay que llevar a cabo para importar, configurar y
poner en funcionamiento la primera aplicación web con Struts dentro de nuestro entorno de
desarrollo Eclipse.
Lo primero es descargar dicho proyecto de aquí. Descomprimir dicho fichero en un directorio
temporal. Iniciamos el Eclipse y pinchando con el botón de la derecha sobre la vista de ‘Project
Explorer’ nos vamos a la opción Import –> Import:
En la ventana de Import, desplegamos la carpeta General y pinchamos sobre la opción ‘Existing
Projects into Workspace’:
Tema 4
46
En esta ventana tenemos que buscar (Browse) el directorio donde hayamos descomprimido el
fichero struts-registration.rar. Una vez seleccionado nos aparece el proyecto ‘struts-registration’, lo
marcamos con el check y pinchamos el botón de Finish:
Una vez importado el proyecto nos aparece en la vista de ‘Project Explorer’. Como en mi caso es
probable que aparezca marcado con la cruz roja de tener problemas con la compilación:
Tema 4
47
Para solucionar el/los problemas que existan, pinchamos con el botón de la derecha del ratón sobre
el proyecto y pinchamos en la opción de Properties, nos aparece la ventana de propiedades del
proyecto donde se configuran diferentes opciones siendo las principales la dependencia de librerías
(Java Build Path), otros proyectos de los que dependa (Project Referentes), el context root (Web
Content Settings) o el servidor donde se va a desplegar el proyecto:
Podemos ver que en el Build Path nos indica con un aviso que la librería de la JRE no la encuentra.
¡Lógico! Es poco probable que vosotros y yo tengamos configurado en el Eclipse las versiones de la
Tema 4
48
JDK/JRE idénticas y con el mismo nombre. Para arreglar dicho problema pinchamos sobre dicha
librería y en el botón de ‘edit’:
Seleccionamos la JRE que tengamos en nuestro Eclipse y finalizamos y cerramos la ventana de
propiedades, lo que provoca que se recompile el proyecto y desaparezcan los problemas (ya no
tenemos la marca roja). También podrían aparecer problemas relacionados con las versiones del
Tomcat que se solucionan de idéntica forma.
Si echamos un vistazo a la aplicación web que habeís importado es una aplicación con Struts muy
sencilla que prácticamente consiste en un formulario para registrarte donde se pide el nombre,
dirección, edad y teléfono, siendo campos obligatorios el nombre y la edad. Si todo es correcto y la
edad introducida es mayor de 18 años te notifica con que el registro ha sido correcto sino te informa
que sólo pueden registrarse mayores de 18 años.
Veamos como desplegar dicha aplicación con Eclipse en el Tomcat que tenemos instalado. Tenemos
dos opciones para levantar el Tomcat: en modo ejecución y en modo debug, que no necesitan más
explicación para toda persona que haya programado alguna vez con un entorno de desarrollo.
Arrancamos en modo ejecución normal:
Tema 4
49
Nos indica que seleccionemos el servidor Tomcat donde se va a desplegar el proyecto,
seleccionamos el Tomcat 6 y marcamos que siempre use este servidor:
Pinchamos en Next y nos muestra la pantalla con las aplicaciones web disponibles en el Eclipse
para que pasemos al lado de la derecha aquellos que queramos que se desplieguen en el servidor
(debe aparecer el struts-registration):
Tema 4
50
Pulsamos Finish, se arranca el servidor Tomcat y nos inicia el navegador web configurado (en la
imagen se ha iniciado el navegador interno que incluye el Eclipse):
Tema 4
51
Se propone al alumno que pruebe la aplicación web estudiando como se lleva a cabo con Struts la
validación del formulario, la configuración de las acciones en el struts-action.xml, la clase que
implementa la acción de registrar (RegistrarAction) o la internacionalización de la aplicación
(español, inglés). Podeís hacer modificaciones sobre el código y realizar traceo del código mediante
breakpoints (modo debug).
La segunda aplicación que se va a estudiar es con el framework JSF y es un ejemplo que viene con
la distribución de J2EE de Sun, para descargarla pincha aquí. Consiste en un formulario que te pide
que adivines el número que está pensando Duke (un valor entre 0 y 10). Es una aplicación muy
sencilla y que sirve para ver como configurar y relacionar formularios con backing beans en JSF,
como se configuran los JSP con los componentes UI de JSF y como se define la navegación.
Los pasos que se tienen que realizar para importar, compilar y desplegar la aplicación son similares
a los llevados a cabo con el ejemplo de Struts. La única diferencia esta en que esta aplicación se
recomienda que se despliegue en el servidor Tomcat 5.5 que los alumnos ya tendrían que tener
instalado e integrado en Eclipse. La aplicación también funciona sobre Tomcat 4.1 pero se obtienen
trazas de error continua por temas de XML.
Al igual que con el ejemplo de Struts, probar la aplicación, tracearla, modificarla, etc... con el
objetivo de que el alumno sea capaz de controlar dicho tipo de aplicaciones y frameworks pues
serán la base para los ejercicios que se proponen en el tema y éste tema se considera uno de los más
importantes de cara a la preparación para el mundo laboral.
Como último ejemplo, vamos a ver que pasos hay que llevar a cabo para poder importar en Eclipse
un proyecto que no se haya realizado con dicho IDE, por ejemplo, porque lo hayamos bajado de
Internet o venga en algún tutorial que estemos leyendo. Para este caso, la aplicación que tenemos te
la puedes descargar de aquí.
Tema 4
52
Una vez que descomprimas el fichero podrás comprobar que en la estructura de subdirectorios
encontramos lo siguiente:






build: no tiene contenido.
dist/lib: archivo banking.war.
lib: librerías o archivos .jar.
META-INF: sin contenido.
src: dentro de las subcarpetas correspondientes (paquetes) se encuentran los archivos .java.
web: con la estructura obligatoria de una aplicación web Java, encontramos dentro
imágenes, JSPs, web.xml y fichero de estilos.
Vamos a ver como encajamos estas piezas dentro de un proyecto de Eclipse. Lo primero es crear un
nuevo proyecto web (Dynamic Web Project) en Eclipse con el nombre de banking, para esto
podemos seguir el ejemplo de HolaMundo que ya hemos visto en el tema 4.
Una vez creado el proyecto banking, nos vamos a ir a una ventana del explorador de Windows y
vamos a ir copiando desde las carpetas anteriores hasta la ruta donde se encuentra nuestro proyecto
banking en el workspace del Eclipse. En la siguiente imagen podemos ver que la intención es copiar
desde el explorador de la izquierda (donde tenemos descomprimido el banking-dev.zip) en el
explorador de la derecha (donde se encuentra nuestro proyecto banking creado con Eclipse).
Tenemos que copiar el contenido de las siguientes carpetas:



del src (zip) al src (eclipse);
del web (zip) al WebContent (Eclipse), pregunta si sobreescribe y confirmamos la
sobreescritura del contenido;
del lib (zip) al WebContent/WEB-INF/lib.
Una vez que lo tenemos todo copiado, volvemos a Eclipse y refrescamos el proyecto (F5), debería
recompilarse el proyecto con los nuevos fuentes que hemos copiado desde el explorador de
Windows. Y ahora ya podemos desplegar la aplicación banking en el Tomcat mediante el ‘run on
server’.
Tema 4
53

II Curso Online JAVA-J2EE

Transcripción

Documentos relacionados