INTRODUCCIÓN APLICACIONES WEB

¿Qué es JEE?

Una aplicación web se despliega en el contenedor Web que todo servidor de aplicaciones compatible con JEE debe poseer.

Este tipo de aplicaciones se componen de los siguientes recursos:

• Servlets; clases java que administra y se ejecutan en el contenedor Web.
• JSP; páginas web compuestas de HTML, CSS, …etc y código Java.
• Clases Java
• Descriptores de despliegue; archivo xml donde se configura los componentes de la aplicación.

Para poder ejecutar este tipo de aplicaciones necesitamos los siguientes recursos:

• Un servidor de aplicaciones donde se desplegará la aplicación.
• Un navegador web tipo Explorer, Mozilla, Crome, …etc.

A lo largo de este modulo iremos conociendo cada uno de los componentes web y su gestión.

ESTRUCTURA DE UN WAR

Una aplicación web se empaqueta en un modulo con extensión .war. Este modulo se puede desplegar directamente en el contenedor web.

Da igual el entorno de desarrollo que utilicemos ya que la estructura de un war forma parte de la especificación JEE y esto marca un estándar por lo cual siempre será la misma.

En la imagen siguiente podemos ver esta estructura

Carpeta META-INF: contiene el archivo de manifiesto que utilizamos para almacenar información sobre la aplicación, control de versiones, autor, …etc.

Carpeta WEB-INF:

• Los descriptores de despliegue web.xml y sun-web.xml; el primero de ellos es un estándar de JEE por lo cual su nombre no debe variar. El segundo toma su nombre del servidor de aplicaciones que estemos utilizando.
• Carpeta classes; aquí encontramos todas las clases java compiladas (.class) guardando la misma estructura que los paquetes definidos.

Contenido web:

En esta ubicación tenemos todo el contenido web: paginas jsp, html, hojas de estilo css, archivos javascript, imágenes, …etc.

PATRON MVC

Una aplicación web diseñada con la arquitectura del patrón MVC se caracteriza por lo siguiente:

• Un servlet actúa como controlador, que verifica los datos recibidos, actualiza el modelo con dichos datos y selecciona la próxima vista como respuesta.
• Una página de JSP actúa como vista. En ella se representa la respuesta HTML, recuperando los datos del modelo necesarios para generar la respuesta, y se proporcionan formularios HTML que permiten la interacción del usuario.
• Las clases Java actúan como modelo, que implementa la lógica de negocio de la aplicación web.

 

PETICIONES HTTP

Hypertext Transfer Protocol o HTTP (en español protocolo de transferencia de hipertexto) es el protocolo usado en cada transacción de la World Wide Web.

A través de dicho protocolo podemos emitir peticiones HTTP desde el cliente (navegador web) hasta el servidor. Una vez tramitada la petición, el servidor devolverá una respuesta HTTP al cliente que este interpretará mostrando el resultado al usuario.

Para poder emitir peticiones necesitamos de una URL. Una URL es un nombre canónico que localiza un recurso específico en Internet. Está formado por:

protocolo://host:puerto/ruta/archivo

 

Detallamos cada componente de la url:

• Protocolo: normalmente usaremos http o https para peticiones seguras.
• Host: es el nombre o IP del servidor
• Puerto: puerto de escucha para las aplicaciones web. Suele ser 8080 o únicamente 80.
• Ruta: es el context path de la aplicación. Es un nombre que hace referencia a la carpeta raíz de la aplicación.
• Archivo: puede ser una página web, un servlet o cualquier recurso de la aplicación.

Además de los componentes vistos también se pueden enviar datos en la url para su procesamiento. Estos viajarán de diferente forma dependiendo el método http elegido.

A continuación vemos los dos más importantes: GET y POST.

METODO GET

Es el más simple de los dos. Su principal tarea es pedir al servidor que coja un recurso y lo envíe. Los parámetros se ven en la URL.

En la siguiente imagen vemos como en la url se separa la lista de parámetros con el carácter «?». El parámetro opción viaja con el valor 1. Si hubiese más de un parámetro estos irían unidos con el carácter «&».

METODO POST

Es más seguro por estar oculto. Podemos solicitar algo y al mismo tiempo enviar datos de un formulario al servidor. Los parámetros están ocultos, se envían en el cuerpo del mensaje.

Razones para usar POST en vez de GET

• El numero de caracteres el limitado usando GET (dependiendo del servidor).
• Los datos enviados con GET se añaden al final de la URL.
• No permite almacenar los argumentos del formulario.
• Permite el envio de datos binarios como archivos de documentos o fotos.

En la imagen anterior vemos como se ha enviado el código del producto a buscar utilizando el método post. Esta vez no vemos el parámetro con su valor correspondiente ya que este viaja dentro del cuerpo de la petición.

SOBREESCRITURA URL

Podemos adjuntar nuestros propios parámetros sobreescribiendo una url. Esto consiste en añadir el carácter separación (?) y a continuación detallar los parámetros necesarios.

<a href=»nombreServlet?variable=dato»>Texto a mostrar</a>

 

ENVIO DE PARAMETROS DE UN FORMULARIO

A través del atributo name podemos establecer el nombre del parámetro. El valor será el que rellene el usuario.

También podemos hacer uso de los campos ocultos de esta forma el usuario no verá el dato que enviamos. Lo aconsejable con campos ocultos es utilizar el método POST ya que si utilizásemos GET estos se verían en la url.

En un formulario se puede elegir el método http. En nuestro ejemplo utilizamos POST.