Manual Java U3
Manual Java U3
Diseño de aplicaciones
distribuidas
Índice de contenidos
3. Diseño de aplicaciones distribuidas ................................................................................................................3
Introducción............................................................................................................................................................... 3
Programación de Servlets ........................................................................................................................................ 3
Desarrollo de páginas activas de servidor mediante JSP ..................................................................................... 6
Conceptos básicos sobre el desarrollo de aplicaciones Web ............................................................................ 10
Conceptos básicos sobre Servlets ........................................................................................................................ 12
Componentes principales de un Servlet .............................................................................................................. 13
Ciclo de vida de un Servlet ..................................................................................................................................... 17
Conceptos básicos de JSP....................................................................................................................................... 17
Intercambio de información con el navegador ................................................................................................... 21
Conectividad con base de datos ........................................................................................................................... 26
Diseño y utilización de páginas JSP....................................................................................................................... 30
Página 2 de 39
3. DISEÑO DE APLICACIONES DISTRIBUIDAS
Programación de Servlets
Un Servlet es una clase Java que genera una página web dinámica HTML.
Es decir, a partir de un programa escrito en lenguaje Java, la arquitectura J2EE (Java SDK 2 Enterprise Edition)
que incluye las librerías y estructuras necesarias para ejecutar y alojar páginas web .jsp, ofrece un mecanismo
para generar páginas web capaces de atender las peticiones de los clientes a través de un navegador, ya que
se encarga de alojar las páginas HTML generadas y ofrecerlas desde un servidor web.
Anteriormente, Java ofrecía un mecanismo de Applets, que eran pequeños programas incrustados
directamente en una página HTML. Debido a que se desaconsejó su uso, apareció la tecnología basada en
Servlets.
La principal ventaja de estos es que se ejecutan en una máquina virtual Java (JVM) así que, por medio de esta
tecnología, J2EE consigue que se puedan alojar y disponer páginas web .jsp (JavaServer Pages) en HTML para
cualquier plataforma que tenga dicha máquina virtual.
Habrá máquinas servidoras que dispongan de un software servidor web, como son Apache Tomcat o
GlassFish, para comunicarse con los navegadores web (que trabajan con HTML). La máquina servidora atiende
peticiones de clientes hechas desde el navegador, las procesa a través de algún Servlet y, finalmente, envía una
respuesta.
A continuación, se detalla cómo instalar el servidor web Apache Tomcat en una máquina para que pueda
actuar como servidor web de aplicaciones Java.
Página 3 de 39
3. DISEÑO DE APLICACIONES DISTRIBUIDAS
Cuando finalice la instalación pulsamos Finish y comenzará la ejecución del servicio de Apache Tomcat sobre
la máquina.
Finalizado el proceso, en la barra de tareas de Windows habrá aparecido un icono para el Apache Tomcat.
Haciendo clic derecho sobre él podremos cambiar la configuración del servidor (Configure), o detener su
ejecución (Stop Service).
Página 4 de 39
3. DISEÑO DE APLICACIONES DISTRIBUIDAS
Página 5 de 39
3. DISEÑO DE APLICACIONES DISTRIBUIDAS
El origen de las páginas .jsp responde a la separación de capas de una aplicación web con el patrón Modelo-
Vista-Controlador (MVC):
Vista
La conforman las clases que servirán como interfaces con el usuario, principalmente las páginas web
desplegadas en la máquina.
Controlador
Lo constituyen las clases que atienden las peticiones de los clientes y que determinarán qué módulo debe
controlar tal petición.
En esta capa actúan los Servlets y comunica las otras dos capas, de manera que el modelo no tiene contacto
con la vista (ni al revés) si no es a través de algún elemento del controlador.
Modelo
Aglutina a todas las clases Java que conforman la lógica de negocio de la aplicación, es decir, el procesamiento
de la información proveniente del usuario a partir de una petición para dar lugar a una respuesta en forma de
resultados generados.
En ocasiones esta capa ha de comunicarse con algún origen de datos (como puede ser una Base de Datos)
para recuperar y/o guardar información.
Cuando se diseña una aplicación basada en el patrón MVC es importante que se haga una adecuada división
de las tareas. Así, las páginas JSP no deben realizar procesamiento de datos, y los Servlets no deben incluir
código para presentar las páginas.
La división de tareas entre la capa del controlador y la capa de modelo es la más difícil de conseguir, ya que
mantener una independencia total entre los módulos, aunque sea el objetivo ideal es, en ocasiones, imposible.
Se entiende por página web activa aquella en la que el resultado del procesamiento de una petición es
diferente en cada momento, dando lugar a una respuesta dinámica, todo lo contrario que las páginas web
estáticas cuyo procesamiento siempre es el mismo.
A continuación, detallamos el proceso para generar un nuevo proyecto web Java desde Netbeans, utilizando
el servidor Apache Tomcat.
Página 6 de 39
3. DISEÑO DE APLICACIONES DISTRIBUIDAS
A continuación, seleccionamos el
tipo de servidor web, en nuestro
caso, Apache Tomcat or TomEE.
Página 7 de 39
3. DISEÑO DE APLICACIONES DISTRIBUIDAS
La siguiente pantalla permite elegir si se aplica algún framework de trabajo para la creación de la aplicación
web.
En este caso no vamos a utilizar ningún framework para nuestra primera página JSP, por lo que dejamos
desmarcadas todas las casillas y pulsamos Finish.
Por defecto Netbeans crea ya una estructura de carpetas y archivos para organizar la aplicación web. No vamos
a detallarla, pero sí destacamos que habrá una carpeta WebPages que contendrá las páginas html y jsp que
formarán la aplicación.
Página 8 de 39
3. DISEÑO DE APLICACIONES DISTRIBUIDAS
Ello nos dará como resultado la fecha actual del servidor en el que se
aloje la página cuando se procese la petición a través de un
Página 9 de 39
3. DISEÑO DE APLICACIONES DISTRIBUIDAS
navegador.
El servidor web Apache Tomcat debe estar corriendo para que se puedan ejecutar las peticiones desde los
navegadores web de los clientes.
Si colocamos esta página jsp en esa carpeta raíz para el servidor web y luego escribimos en nuestro navegador
la dirección URL http://localhost:8080/newjsp.jsp el servidor Apache gestionará nuestra petición para la fecha,
la procesará y la devolverá al navegador en forma de página web.
Este es el resultado:
Un navegador web, que es el software que utilizan los usuarios para acceder a Internet.
Un servidor, que es la máquina en la cual se alojan las aplicaciones web y que se identifica mediante una
dirección IP.
El protocolo HTTP (HyperText Transfer Protocol), basado a su vez sobre TCP/IP, que es el utilizado para
comunicar las peticiones de los clientes desde un navegador con las máquinas servidoras.
El lenguaje HTML (HyperText Markup Language) con el que se escriben las páginas web y que los navegadores
interpretan para mostrar su contenido.
Normalmente se utiliza junto a las hojas de estilos en cascada CSS (Cascade Style Sheets), que dotan a las
páginas de un diseño y apariencia para ser presentadas al usuario.
Página 10 de 39
3. DISEÑO DE APLICACIONES DISTRIBUIDAS
Para el desarrollo de una aplicación web ha de tenerse en cuenta que habrá, por un lado, una parte
correspondiente al cliente y, por otro, una parte asociada al servidor. Eso da lugar a diferentes tecnologías
que se definen como “del lado del cliente” o “del lado del servidor”.
Lado cliente
Permiten diseñar y desarrollar las interfaces gráficas con las que el usuario interactúa, y se encargan de
establecer comunicación con los servidores.
Entre ellas encontramos las basadas en HTML, CSS, JavaScript… (este último es un lenguaje que permite realizar
acciones en la máquina cliente; no es propio de Java).
Lado servidor
Se encargan del diseño y desarrollo de la parte servidora de una aplicación web, la que recibe una petición y
la procesa para devolver una respuesta.
Son implementadas en algún lenguaje de desarrollo web como Java EE, .NET, PHP, Ruby…
Por otro lado, en función del tipo de contenido que se maneja en la parte cliente y en la parte servidora, nos
encontramos con que pueden trabajar con:
• contenido estático: cuando no hay interacción por parte de los usuarios, sino que a éstos simplemente
se les ofrece una información fija.
• contenido dinámico: cuando los usuarios pueden interaccionar con la aplicación mediante botones,
formularios y otros elementos que aportan información que es gestionada, por lo que la respuesta
ofrecida varía en función de la interacción.
No hay ningún tipo de interacción con el usuario, así que el servidor devuelve siempre la misma respuesta.
Cuando el servidor recibe una petición desde el navegador del cliente, devuelve contenido del disco o ejecuta
un código para generar el recurso solicitado dinámicamente (ese código normalmente consiste en realizar
consultas a una base de datos para recuperar información, generando la página web en HTML y sus contenidos
de forma dinámica).
En él se aloja el contenido en la máquina servidora de forma estática, pero el cliente es dinámico porque las
páginas incluyen código JavaScript ejecutado en el propio navegador del usuario. Este código JavaScript puede
realizar acciones y efectos gráficos, como mostrar y ocultar elementos de la web, adaptando así los contenidos
a cada cliente.
Página 11 de 39
3. DISEÑO DE APLICACIONES DISTRIBUIDAS
Este modelo combina los aspectos de los dos casos anteriores: generalmente del lado del cliente se usa una
parte de código JavaScript para efectos gráficos y comportamientos interactivos con el usuario, pero también
para realizar peticiones AJAX (Asynchronous JavaScript And XML) en segundo plano y aplicaciones de página
única con REST.
Así se evita recargar completamente una página al pulsar un enlace, y cuando el resultado de una petición llega
al navegador, el código JavaScript actualiza únicamente las partes necesarias de la página.
Dicho de otra manera, los Servlets son clases Java alojadas en el servidor, atienden las peticiones
provenientes de los clientes, procesan la información recibida y devuelven una respuesta con los resultados.
Los Servlets, al ser clases Java, pueden utilizarse como cualquier otra clase, de manera que se pueden incluir
en otros Servlets, llamar a sus métodos, etc.
Así mismo, los Servlets pueden ejecutarse en cualquier servidor independientemente del sistema operativo
utilizado siempre que tenga una máquina virtual de Java y un contenedor web instalados.
Un contenedor web aloja páginas web JSP y dispone de un contenedor de Servlets para que éstos estén
disponibles.
El propósito de los Servlets es servir de enlace entre el cliente y el servidor, por lo que pueden obtener
información acerca del cliente de forma directa. Además, permiten el uso de variables de sesión y de cookies,
con el objeto de mejorar la interacción con los clientes.
Un Servlet es capaz de atender a muchos clientes simultáneamente, ya que trabaja a partir de hilos de
ejecución. Esto significa que, desde el propio Servlet, ha de implementarse la sincronización entre ellos en
caso de necesitar compartir algún recurso del servidor.
Página 12 de 39
3. DISEÑO DE APLICACIONES DISTRIBUIDAS
Destacar que los métodos service(), doPost() y doGet() tienen como argumentos los objetos request y response,
de tipo HttpServletRequest y HttpServletResponse respectivamente.
El primero contiene la información que se le envía al Servlet para que éste se encargue de su procesamiento,
mientras que el segundo sirve para que el Servlet mande la información resultante hacia el cliente.
Página 13 de 39
3. DISEÑO DE APLICACIONES DISTRIBUIDAS
El fichero creado se trata de una clase Java que hereda de HttpServlet. Dispone de varios métodos creados
automáticamente:
processRequest
Tiene como argumentos un objeto de tipo HttpServletRequest y otro HttpServletResponse.
Página 14 de 39
3. DISEÑO DE APLICACIONES DISTRIBUIDAS
doGet y doPost
Atienden las peticiones HTTP de tipo GET y POST
respectivamente. En su interior precisamente se llama al
método processRequest.
Así mismo, como previamente hemos marcado que se incluyera la información sobre el Servlet en el descriptor
de despliegue de la aplicación, tenemos que en el archivo web.xml de la carpeta Configuration Files (Archivos
de configuración) se ha añadido esta información.
Página 15 de 39
3. DISEÑO DE APLICACIONES DISTRIBUIDAS
Página 16 de 39
3. DISEÑO DE APLICACIONES DISTRIBUIDAS
En ocasiones el archivo web.xml incluye alguna etiqueta relativa a los parámetros de los Servlets. Estos se
utilizan durante el proceso de inicialización y han de ser recogidos mediante el método getInitParameter(String
parameter), que devuelve un objeto String con el valor del String parameter que se pasa como argumento en la
llamada.
A través de los métodos doGet() y doPost() se llama a service() cada vez que se recibe una petición de algún
cliente para el Servlet, por lo que puede recibir llamadas simultaneas de varios clientes. En ese caso se crea
un nuevo hilo de servicio del Servlet y se examina el tipo de petición HTTP, (GET o POST) para, a continuación,
procesar la información con el método doGet o doPost (según el tipo).
Ambos métodos tienen como argumentos un objeto HttpServletRequest y otro HttpServletResponse. A partir del
request se encapsulan los datos provenientes del cliente.
Para obtener el valor (o valores) de dichos parámetros, doGet y doPost utilizan la función String
getParmeter(String parameter) o String[] getParameterValues(String parameter) teniendo en cuenta que el String
parameter indica el nombre del parámetro en la petición HTTP y distingue mayúsculas de minúsculas.
Este método no es necesario redefinirlo; en caso de hacerlo, no debe ser llamado hasta que no se hayan
procesado y concluido todas las peticiones de los clientes.
El archivo que contiene la página tendrá la extensión .jsp por lo que los clientes realizan peticiones
introduciendo su dirección en el navegador. Si es la primera vez que lo hacen, el gestor JSP compila la página
convirtiéndola en un Servlet que atiende la petición, y envía la respuesta de vuelta al cliente.
Una vez compilada la página JSP este proceso no vuelve a realizarse, y la petición se atiende directamente
a través del Servlet compilado, respondiendo con el código HTML generado en un hilo de ejecución
independiente.
Para crear una página JSP desde Netbeans hacemos clic derecho New - JSP. Damos un nombre a la página y su
localización dentro de la aplicación (por defecto en la carpeta Web Pages).
Página 17 de 39
3. DISEÑO DE APLICACIONES DISTRIBUIDAS
Por defecto todas las JSP comienzan con un comentario que sólo es visible en la parte servidor y que indica
la autoría del documento, su versión (o revisión) y una descripción. El objetivo no es otro que facilitar la
programación a futuros desarrolladores de la página cuando realicen tareas de mantenimiento.
Página 18 de 39
3. DISEÑO DE APLICACIONES DISTRIBUIDAS
A continuación, se incluye una directiva <%@page %> y lo siguiente ya es código HTML con sus etiquetas
habituales <head>, <body>, etc.
Existen principalmente 3 elementos que se pueden incrustar en una JSP como código para ser procesado por
el servidor:
Scriptles
Para incluir código Java como si se tratara de una clase, con declaración de variables, métodos, etc.
• <%= expresión en Java %> se evalúa la expresión y el resultado se escribe en forma de String.
• <% código Java %> será código ejecutado en el método _jspService() del Servlet que se genera.
• <%! declaración Java %> se utiliza principalmente para declarar variables globales que se deberán
compartir por todas las instancias, es decir, todas las peticiones desde los clientes, de la página JSP.
• <%-- comentario --%> los comentarios serán ignorados durante la compilación de la JSP.
Directivas
Para dar las instrucciones de cómo ejecutar la JSP.
• <%@ page import="libreriaJava" %> para importar una librería y poder ser utilizada en la JSP.
• <%@ page sesión=true %> para establecer o no el uso de variables de sesión.
Página 19 de 39
3. DISEÑO DE APLICACIONES DISTRIBUIDAS
• <%@ page errorPage="\pagina.jsp" %> para establecer una página de error al que redirigir al usuario en
caso de error.
• <%@ include file="URL_fichero"%> para incluir un fichero en el momento de compilación de la JSP para
generar el Servlet.
Acciones
Tiene usos variados, generalmente para modificar el flujo normal de ejecución.
La siguiente figura muestra un ejemplo en el que se incluyen varios de los anteriores elementos.
Página 20 de 39
3. DISEÑO DE APLICACIONES DISTRIBUIDAS
GET
Las peticiones GET trabajan en pares clave=valor que se marcan directamente en la URL para la cual se hace
la petición.
Entendemos que se trata de una petición de tipo GET en la que pasa al servidor 2 parámetros (parametro1 y
parametro2) con valores 10 y 20 respectivamente.
Tenemos el nombre de la página jsp y el carácter ‘?’ que indica el comienzo de los parámetros para esa petición,
cada uno con su nombre y valor y separados mediante el carácter ‘&’.
El nombre de los parámetros diferencia mayúsculas y minúsculas y es éste el que se indica dentro del servlet
en la función doGet() cuando se realiza la llamada a getParameter(String parameter) o a getParameterValues(String
parameter) para obtener su valor y procesarlo. Normalmente se usan peticiones GET cuando son pocos
parámetros y no es importante que queden al descubierto sus nombres o valores.
El procesamiento de éstos ya se encargará de validar los datos, procesarlos y, generalmente, devolver una
respuesta al cliente en forma de texto a través de un objeto de tipo PrintWriter que dispone el objeto response
y que puede obtenerse con la llamada PrintWriter out = response.getWriter();
Este objeto response dispone también de otro método getOutputStream() que devuelve un objeto de tipo
ServletOutputStream para devolver datos binarios al cliente.
POST
Las peticiones POST encapsulan los valores de los datos en las peticiones de los clientes, por lo que
no son visibles como en el caso anterior. No obstante, desde el método doPost, que es el que gestiona
las peticiones HTTP de este tipo, también están disponibles los métodos para obtener los valores de los
parámetros (getParamater(String parameter) y getParameterValues(String parameter))
Destacar que, en una página JSP, normalmente se tienen formularios procesados con Servlets. En sus etiquetas
<form> se tiene un atributo llamado Method en el que se indica si la petición se procesa mediante GET o POST,
es decir, de qué manera se van a enviar los datos al servidor. Además, se tiene también un atributo llamado
Action en el que se indica la URL de la dirección donde se encuentra el Servlet con el nombre de éste.
En la siguiente imagen tenemos un par de ejemplos básicos de cómo se podrían realizar peticiones desde una
página web JSP:
Página 21 de 39
3. DISEÑO DE APLICACIONES DISTRIBUIDAS
Podemos elaborar otro ejemplo en el que se procesen los datos mediante un formulario. Para ello tendremos
dos páginas web: inicio.jsp y destino.jsp que creamos mediante el asistente de Netbeans.
Página 22 de 39
3. DISEÑO DE APLICACIONES DISTRIBUIDAS
Página 23 de 39
3. DISEÑO DE APLICACIONES DISTRIBUIDAS
Página 24 de 39
3. DISEÑO DE APLICACIONES DISTRIBUIDAS
inicio.jsp
Dispone de un formulario a través de la etiqueta ‘Form’ con el atributo action=”destino.jsp” y method=”post”, lo
que significa que se procesará la petición de tipo POST y que será la página destino.jsp la que tratará los datos
que el usuario introduzca desde inicio.jsp.
Así mismo, en el formulario se tiene una tabla con campos para que el usuario introduzca su nombre, edad
y email; dos radio buttons para seleccionar el género y checkboxes para los intereses. Finalmente, el botón
Enviar que pulsará cuando finalice.
destino.jsp
Tiene el siguiente código para gestionar la información
que proviene desde inicio.jsp y para mostrar los
resultados al cliente.
Página 25 de 39
3. DISEÑO DE APLICACIONES DISTRIBUIDAS
Para ejecutar este ejemplo, abrimos el navegador e introducimos la dirección donde se encuentra la página
.jsp, en este caso en la carpeta raíz del servidor Apache Tomcat (que obviamente debe estar arrancado).
Java incluye mecanismos para preparar el conector con la base de datos con la que se desee trabajar, así como
para operar directamente sobre ella.
A continuación, explicamos la manera de establecer una conexión desde Netbeans a una base de datos de tipo
MySQL. Para ello, lo primero es descargar el conector “mysql-connector-java” disponible en esta dirección.
Página 26 de 39
3. DISEÑO DE APLICACIONES DISTRIBUIDAS
Al pulsar Download seremos redirigidos a la página de descarga, con la posibilidad de registrarnos en la web
de MySQL.
Si pulsamos “No, thanks. Just start my download” comenzará la descarga del instalador del gestor de bases de
datos de MySQL. Lo abrimos con permisos de administrador, aceptamos las condiciones y pulsamos Next.
En la siguiente pantalla podremos elegir el tipo de instalación que deseemos, en este caso Full (Completa) para
que instale todos los componentes: cliente, servidor, conectores, etc.
Si nuestra máquina no dispone de algunos de los componentes requeridos, nos informará de que deberán
instalarse también. Al pulsar en Execute se descargarán e instalarán dichos componentes adicionales.
Página 27 de 39
3. DISEÑO DE APLICACIONES DISTRIBUIDAS
Una vez instalados pulsaremos Next y en la siguiente pantalla Finish para terminar la instalación de MySQL.
Página 28 de 39
3. DISEÑO DE APLICACIONES DISTRIBUIDAS
Para trabajar con las bases de datos más cómodamente de manera gráfica, podemos descargar e instalar
MySQL Workbench desde esta página.
Abrimos el instalador de MySQL Workbench con permisos de administrador, elegimos la ubicación para su
instalación y seleccionamos instalación completa. Cuando termine, lanzamos el programa.
Página 29 de 39
3. DISEÑO DE APLICACIONES DISTRIBUIDAS
Creamos un nuevo proyecto web de Java y añadimos 2 paquetes para las capas Modelo y Controlador de
nuestra aplicación.
Creamos una nueva clase Java en el paquete Modelo de nombre ConectarBD.java cuya misión será la de
conectar a una base de datos sobre la que operará nuestra aplicación. Tenemos su código en la siguiente
pantalla.
Dispone de un par de métodos para abrir y cerrar la conexión con la base de datos.
En este ejemplo, dicha base se llamará “tienda”, es de tipo MySQL (por lo que se necesita el conector
com.mysql.jdbc.Driver) y estará ubicada en la dirección local localhost.
Página 30 de 39
3. DISEÑO DE APLICACIONES DISTRIBUIDAS
Creamos ahora una base de datos. Esto podría hacerse, por ejemplo, a través de la consola de comandos del
servidor MySQL, pero en este caso utilizaremos el programa MySQL Workbench.
Página 31 de 39
3. DISEÑO DE APLICACIONES DISTRIBUIDAS
Creamos una primera página index.jsp para registrar los productos de la tienda. Todas las JSP irán en la capa
de vista de nuestra aplicación.
En esta página el usuario introduce los datos de un producto: identificador, nombre, precio y cantidad.
Se dispone de los botones:
Y un enlace hacia la página consultaProducto.jsp cuya finalidad es buscar un producto de entre los registrados.
Index.jsp
Página 32 de 39
3. DISEÑO DE APLICACIONES DISTRIBUIDAS
Registro.java
Se trata de un Servlet que, a partir de las clases gestoras de la BD, realiza una inserción en la tabla
"productos". Recoge los datos desde la página index.jsp y muestra el resultado al cliente en la página
MuestraRegistro.jsp
Página 33 de 39
3. DISEÑO DE APLICACIONES DISTRIBUIDAS
ConectarBD.java
Es una clase para realizar la apertura y cierre de conexión con la base de datos. Maneja un objeto de la clase
java.sql.Connection
Página 34 de 39
3. DISEÑO DE APLICACIONES DISTRIBUIDAS
GestorBD.java
Es la clase encargada de realizar las operaciones de inserción (método regsitrar), consulta de un elemento
(consulta) y consulta de todos los elementos de la tabla productos (leerTodos).
Página 35 de 39
3. DISEÑO DE APLICACIONES DISTRIBUIDAS
Página 36 de 39
3. DISEÑO DE APLICACIONES DISTRIBUIDAS
Página 37 de 39
3. DISEÑO DE APLICACIONES DISTRIBUIDAS
MuestraRegistro.jsp
Esta página muestra el resultado de una correcta inserción de un producto en la base de datos.
Página 38 de 39
3. DISEÑO DE APLICACIONES DISTRIBUIDAS
Página 39 de 39