Modulo Aplicaciones Web
Modulo Aplicaciones Web
Objetivos:
Conocer que el código html permite insertar menús, tablas, imágenes o bases de
datos en los documentos, pero no permite al usuario que maneje esos elementos
como mejor le convenga, que quién permite esto es XML
Utilizar varias técnicas de estudio para el aprendizaje total del tema. Se puede
además ampliar los conocimientos con el uso de la bibliografía y manteniendo
charlas técnicas con personas entendidas en el tema.
EVALUACIONES Y CALIFICACIONES
Las evaluaciones se realizarán de acuerdo al reglamento del instituto, el cual consiste en:
1. Evaluaciones Parciales.
a. Parcial después de cada capítulo. 10 puntos.
b. Deberes y Consultas. 10 puntos.
c. Exposiciones. 10 puntos.
Lo que da un total de 30 puntos, dividido para las tres opciones que se presentan
tenemos 10 puntos.
BIBLIOGRAFIA
INTRODUCCIÓN
Internet, la red de redes, nace a mediados de la década de los setenta, bajo los
auspicios de DARPA, la Agencia de Proyectos Avanzados para la Defensa de
Estados Unidos. DARPA inició un programa de investigación de técnicas y
tecnologías para unir diversas redes de conmutación de paquetes, permitiendo
así a los ordenadores conectados a estas redes comunicarse entre sí de forma
fácil y transparente.
CAPÍTULO I
INTERNET Y DISEÑO DE UNA PÁGINA WEB
1.3. Introducción.
Este capítulo pretende llevar a la práctica los conocimientos obtenidos durante el
desarrollo del módulo Introducción al Web. La parte teórica y los conocimientos
necesarios para lograr la consecución exitosa de esta unidad se los debe
consultar en los registros mantenidos en el nivel antes mencionado.
CAPÍTULO II
INTRODUCCIÓN A LAS APLICACIONES WEB
El protocolo HTTP
El protocolo HTTP (hypertext tranfer protocol) es el protocolo base de la WWW.
Se trata de un protocolo simple, orientado a conexión y sin estado. La razón de
que esté orientado a conexión es que emplea para su funcionamiento un
protocolo de comunicaciones (TCP, transport control protocol) de modo
conectado, un protocolo que establece un canal de comunicaciones de extremo a
extremo (entre el cliente y el servidor) por el que pasa el flujo de bytes que
constituyen los datos que hay que transferir, en contraposición a los protocolos
de datagrama o no orientados a conexión que dividen los datos en pequeños
Ing. Nancy Montoya R. ITSGA 2005
Aplicaciones Web 7
paquetes (datagramas) y los envían, pudiendo llegar por vías diferentes del
servidor al cliente.
HTML del texto, así como las imágenes que la componen, pues en la
especificación inicial de HTTP, la 1.0, se abrían y usaban tantas conexiones como
componentes tenía la página, trasfiriéndose por cada conexión un componente
(el texto de la página o cada una de las imágenes).
Existe una variante de HTTP llamada HTTPS (S por secure) que utiliza el
protocolo de seguridad SSL (secure socket layer) para cifrar y autenticar el
tráfico entre cliente y servidor, siendo ésta muy usada por los servidores web de
comercio electrónico, así como por aquellos que contienen información personal
o confidencial.
El lenguaje HTML.
El otro puntal del éxito del WWW ha sido el lenguaje HTML (hypertext mark-up
language). Se trata de un lenguaje de marcas (se utiliza insertando marcas en el
interior del texto) que nos permite representar de forma rica el contenido y
también referenciar otros recursos (imágenes, etc.), enlaces a otros documentos
(la característica más destacada del WWW), mostrar formularios para
posteriormente procesarlos, etc.
El esquema de funcionamiento de los CGI tenía un punto débil: cada vez que
recibíamos una petición, el servidor web lanzaba un proceso que ejecutaba el
programa CGI. Como, por otro lado, la mayoría de CGI estaban escritos en algún
lenguaje interpretado (Perl, Python, etc.) o en algún lenguaje que requería run-
time environment (VisualBasic, Java, etc.), esto implicaba una gran carga para la
máquina del servidor. Además, si la web tenía muchos accesos al CGI, esto
suponía problemas graves.
Dicho método fue conocido como CGI (common gateway interface) y definía un
mecanismo mediante el cual podíamos pasar información entre el servidor HTTP
y programas externos. Los CGI siguen siendo muy utilizados, puesto que la
mayoría de los servidores web los soportan debido a su sencillez. Además, nos
proporcionan total libertad a la hora de escoger el lenguaje de programación
para desarrollarlos.
El esquema de funcionamiento de los CGI tenía un punto débil: cada vez que
recibíamos una petición, el servidor web lanzaba un proceso que ejecutaba el
programa CGI. Como, por otro lado, la mayoría de CGI estaban escritos en algún
lenguaje interpretado (Perl, Python, etc.) o en algún lenguaje que requería run-
time environment (VisualBasic, Java, etc.), esto implicaba una gran carga para la
máquina del servidor.
Además, si la web tenía muchos accesos al CGI, esto suponía problemas graves.
Por ello se empiezan a desarrollar alternativas a los CGI para solucionar este
grave problema de rendimiento. Las soluciones vienen principalmente por dos
vías. Por un lado se diseñan sistemas de ejecución de módulos más integrados
con el servidor, que evitan que éste tenga que instanciar y ejecutar multitud de
programas.
Otra de las tecnologías que más éxito ha obtenido y una de las que más se utiliza
en Internet es el lenguaje de programación interpretado por el servidor PHP. Se
trata de un lenguaje que permite incrustar HTML en los programas, con una
sintaxis que proviene de C y Perl. Además, habida cuenta de su facilidad de
aprendizaje, su sencillez y potencia, se está convirtiendo en una herramienta
muy utilizada para algunos desarrollos.
CAPÍTULO III
INSTALACION DEL SERVIDOR WEB
Un servidor web que siguiese el esquema anterior cumpliría los requisitos básicos
de los servidores HTTP, aunque, eso sí, sólo podría servir ficheros estáticos.
A partir del esquema anterior se han diseñado y construido todos los programas
servidores de HTTP que existen, variando sólo el tipo de peticiones (páginas
estáticas, CGI, Servlets, etc.) que pueden atender, en función de que sean o no
multi-proceso, multi-hilados, etc. A continuación detallaremos algunas de las
características principales de los servidores web, que extienden, obviamente el
esquema anterior.
3.1.1. Servicio de ficheros estáticos.
Todos los servidores web deben incluir, como mínimo, la capacidad para servir
los ficheros estáticos que se encuentren en alguna parte concreta del disco. Un
requisito imprescindible es la capacidad de especificar qué parte del disco se
servirá. No resulta en absoluto recomendable que el servidor nos obligue a usar
un directorio concreto, si bien puede tener uno por defecto.
La mayoría de servidores web permiten, además, añadir otros directorios para
servir, especificando en qué punto del “sistema de ficheros” virtual del servidor
se ubicarán.
La mayoría de servidores web ofrecen soporte para CGI (cabe recordar que los
CGI son el método más antiguo y simple de generación de contenido dinámico).
Muchos ofrecen soporte para algunos lenguajes de programación (básicamente
interpretados) como PHP, JSP, ASP, Pike, etc. Es altamente recomendable que el
servidor web que utilicemos proporcione soporte para alguno de estos lenguajes,
siendo uno de los más utilizados PHP, sin tener en cuenta JSP, que usualmente
requiere un software externo al servidor web para funcionar (como por ejemplo,
un contenedor de Servlets).
Cabe destacar que todos los dominios y servidores web de AOL, más de
doscientos, que soportan miles de usuarios, millones de conexiones, etc.,
funcionan gracias a AOLServer. AOLServer tiene una amplia base de usuarios,
Práctica:
Instalación y Configuración del Servidor Apache.
CAPÍTULO IV
XML
4.1. Introducción a XML
XML son las siglas de eXtensible Markup Language, lenguaje extensible de
marcas. Se trata de un estándar del Word Wide Web Consortium
(http://www.w3.org es una referencia básica de XML), cuyo objetivo original
consistía en permitir afrontar los retos de la publicación electrónica de
documentos a gran escala. Actualmente, XML está empezando a desempeñar un
papel muy importante en el intercambio de una gran variedad de información en
la web y en otros contextos.
XML deriva del lenguaje de marcas SGML (un estándar ISO, concretamente el
ISO-8879). Concretamente, es un subconjunto de SGML que pretende que éste
pueda ser servido, recibido y procesado en la web de la misma forma que el
HTML. XML ha sido diseñado buscando la simplicidad de implementación y la
interoperabilidad con SGML y HTML y tratando, por otra parte, de que sea usado
para diseñar aplicaciones centradas en los datos.
XML nace en 1996, desarrollado por un grupo auspiciado por el W3C y al que
inicialmente se conocía como grupo de trabajo de SGML, con los siguientes
objetivos, tal como se enumeran en el documento de definición del estándar:
Ante todo esto, el W3C desarrolló un nuevo lenguaje (XML), que nos
proporciona:
4.2. XML
Un objeto XML (o un documento XML) se define como un documento ormado por
etiquetas y valores que cumple con la especificación de XML, y que estará bien
formado.
</Ingredientes>
<Instrucciones>
<Paso>
Pelar y cortar la patata en rodajas
</Paso>
<Paso>
Poner aceite en una paella
</Paso>
<!-- Y así seguimos... -->
</Instrucciones>
</Receta>
Como podemos apreciar en nuestra receta, todas las etiquetas de XML siguen el
formato mostrado.
ML en el sitio
Documento bien formado
El concepto de bien formado procede de las matemáticas, donde es factible
escribir una expresión usando símbolos matemáticos como:
Todas las etiquetas cerradas: en HTML podemos trabajar con un gran nivel de
relajación de las normas sintácticas, lo cual nos permite dejar etiquetas (como
<B> por ejemplo) abiertas a lo largo de todo el documento, o usando
indiscriminadamente etiquetas como <P> sin cerrarlas con la correspondiente
</P>. XML no permite este nivel de relajación. Todas las etiquetas abiertas
deben tener su correspondiente etiqueta de cierre. Esto se debe a que las
etiquetas en XML representan una información jerárquica que nos indica cómo se
relacionan los diferentes elementos entre ellos. Si no cerramos las etiquetas,
introducimos en esta representación una serie de ambigüedades que nos
impedirían un procesamiento automático.
No está bien formado porque Autor no se cierra dentro de Libro, que es donde
debería cerrarse. La sentencia correcta sería:
<Libro>Platero y Yo<Autor>J. R. Jiménez</Autor></Libro>
7Es decir, la estructura del documento debe ser estrictamente jerárquica. Los
valores de los atributos deben estar entrecomillados; a diferencia de HTML,
donde podemos poner atributos sin comillas. Por ejemplo,
<IMAGE SRC=img.jpg SIZE=10>
en XML todos los atributos deben estar entrecomillados. Los atributos anteriores
quedarían, pues, de la siguiente manera:
<IMAGE SRC=“img.jpg” SIZE=“10”>.
4.3. DTD
DTD (Document Type Definition) es un estándar que nos permite definir una
gramática que deben cumplir nuestros documentos XML para considerarlos
válidos. Una definición DTD para n documentos XML especifica: qué elementos
pueden existir en un documento XML, qué atributos pueden tener éstos, qué
elementos pueden o deben aparecer contenidos en otros elementos y en qué
orden.
Los parsers de XML que son capaces de validar documentos con DTD leen esos
documentos y el DTD asociado. En caso de que el documento XML no cumpla los
requerimientos que le impone el DTD, nos advertirán del error y no validarán el
documento.
Mediante los DTD definimos cómo será nuestro dialecto de XML (recordad que
nosotros definimos qué etiquetas vamos a usar en nuestros documentos, qué
significado les damos, etc.). Esta capacidad de definir un dialecto propio de XML
es lo que permite que XML se denomine. A pesar de que DTD es un estándar que
deberá ser sustituido por XML Schema, sigue siendo muy usado. Además, su uso
resulta más simple que el de XML Schema. Por otro lado, es más compacto. A
eso hay que añadir que las mejoras que aporta XML Schema no son necesarias
para la mayoría de los usos. Con DTD se han definido multitud de dialectos de
XML que son usados ampliamente en Internet, como RDF para la web semántica,
MathML para documentos matemáticos, XML/EDI para intercambio de datos
electrónicamente para negocio, VoiceXML para aplicaciones que se utilicen
mediante voz o que hagan uso de ésta, WML para representar documentos para
los navegadores de dispositivos móviles como teléfonos, etc.
De este documento DTD podemos inferir una descripción de las reglas de validez
que sea un poco más legible:
Vamos a estudiar ahora la sintaxis de DTD para definir los dialectos XML.
Como hemos visto, la sintaxis de DTD no resulta evidente a primera vista. Pese a
ello, tampoco es excesivamente compleja. El primer paso para entenderla es
disponer de las definiciones y usos de los diferentes símbolos usados, que
podemos ver en la tabla siguiente:
elW3C:
Elemento ELEMENT
Los elementos de DTD llamados ELEMENT nos definen una etiqueta de nuestro
dialecto de XML. Por ejemplo:
<!ELEMENT Receta (Nombre, Descripcion?,
Ingredientes?, Instrucciones?)>
Elementos vacíos
Los elementos vacíos se declaran empleando la categoría EMPTY .
<!ELEMENT nombre EMPTY>
Este elemento nombre, en XML se usaría así:
<nombre />
Elementos con sólo caracteres
Los elementos que sólo contendrán datos alfanuméricos se declaran usando
#PCDATA entre paréntesis.
Los hijos que se declaran como una secuencia de elementos separados por
comas deben aparecer en el mismo orden en el documento. Los elementos hijo
también deben declararse en el documento DTD. Estos elementos hijo pueden, a
su vez, tener elementos hijo. La declaración completa de coche sería entonces:
<!ELEMENT coche (marca, matricula, color)>
<!ELEMENT marca (#PCDATA)>
<!ELEMENT matricula (#PCDATA))>
<!ELEMENT color (#PCDATA)>
Elemento ATTLIST
Como ya hemos visto, los elementos en XML pueden tener atributos.
Evidentemente, en DTD disponemos de un mecanismo para indicar qué atributos
puede tener un ELEMENT, de qué tipo, si son o no obligatorios, etc. Para ello
disponemos del elemento ATTLIST, cuya sintaxis es:
Y su uso en XML:
<pago metodo=“contra-reembolso” />
Sintaxis de #IMPLIED
En el siguiente ejemplo:
<!ELEMENT pago EMPTY>
<!ATTLIST pago metodo CDATA #IMPLIED >
Validará correctamente el siguiente XML:
<pago metodo=“tarjeta” />
<pago />
Usaremos, pues, #IMPLIED en aquellos casos en los que no queremos forzar al
usuario a usar atributos pero no podemos poner valores por defecto.
Sintaxis de #REQUIRED
En el siguiente ejemplo:
<!ELEMENT pago EMPTY>
<!ATTLIST pago metodo CDATA #REQUIRED >
Validará correctamente el siguiente XML:
<pago metodo=“tarjeta” />
pero no validará:
<pago />
Usaremos #REQUIRED en aquellos casos en los que no podemos proporcionar un
valor por defecto, pero deseamos que el atributo aparezca y se le asigne algún
valor.
XML Schema presenta ciertas características que la hacen mucho más potente
que DTD:
CAPÍTULO V
JAVA SERVLETS Y JSP
Los Servlets Java presentan una serie de ventajas sobre los CGI, el método
tradicional de desarrollo de aplicaciones web. Éstos son más portables, más
potentes, mucho más eficientes, más fáciles de usar, más escalables, etc.
Eficiencia
Con el modelo tradicional de CGI, cada petición que llega al servidor dispara la
ejecución de un nuevo proceso. Si el tiempo de vida del CGI (el tiempo que tarda
en ejecutarse) es corto, el tiempo de instanciación (el tiempo de arrancar un
proceso) puede superar al de ejecución. Con el modelo de Servlets, la máquina
virtual de Java, el entorno donde se ejecutan, se arranca al iniciar el servidor,
permaneciendo arrancada durante toda la ejecución del mismo. Para atender
cada petición no se arranca un nuevo proceso, sino un thread, un proceso ligero
de Java, mucho más rápido (de hecho, casi instantáneo).
El estándar de Servlets también nos ofrece más alternativas que los CGI para
optimizaciones: caches de cálculos previos, pools de conexiones de bases de
datos, etc.
Facilidad de uso
El estándar de Servlets nos ofrece una magnífica infraestructura de desarrollo de
aplicaciones web, proporcionándonos métodos para análisis automático y
decodificación de los datos de los formularios de HTML, acceso a las cabeceras de
las peticiones HTTP, manejo de cookies, seguimiento, control y gestión de
sesiones, entre otras muchas facilidades.
Potencia
Los Servlets Java permiten hacer muchas cosas que son difíciles o imposibles de
realizar con los CGI tradicionales. Los Servlets pueden compartir los datos entre
sí, permitiendo compartir datos, conexiones a bases de datos, etc. Asimismo,
pueden mantener información de solicitud en solicitud, facilitando tareas como el
seguimiento de las sesiones de usuario, etc.
Portabilidad
Los Servlets están escritos en Java y se rigen por un API estándar bien
documentado. Como consecuencia de ello, los Servlets pueden ejecutarse en
Tanto los CGI como los Servlet nos obligan a generar la página por completo
desde nuestro código de programa, dificultando así las tareas de mantenimiento,
diseño gráfico, comprensión del código, etc. Los JSP, por otro lado, nos permiten
crear las páginas fácilmente.
Como podemos ver en el ejemplo, una página JSP no es más que una página
HTML donde, merced a unas marcas especiales < % y %>, podemos incluir
código Java.
http://java.sun.com/products/servlet/industry.html
Apache.
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
public class ServletBasico extends HttpServlet
{
public void doGet(HttpServletRequest request,
HttpServletResponse response)
throws ServletException, IOException {
// Disponemos de request para acceder a los datos de la
// petición HTTP.
// Disponemos de response para modificar la respuesta HTTP
// que generara el Servlet.
PrintWriter out = response.getWriter();
// Podemos usar out para devolver datos al usuario
out.println(“¡Hola!\n”);
}
}
Para escribir un Servlet debemos escribir una clase de Java que extienda (por
herencia) la clase HttpServlet (o la clase más genérica Servlet) y que
sobreescriba el método service o alguno de los métodos de petición más
específicos (doGet, doPost, etc.).
Los métodos de servicio (service, doPost, doGet, etc.) tienen dos argumentos:
un HttpServletRequest y un HttpServletResponse. El HttpServletRequest
proporciona métodos que nos permiten leer la información entrante como los
datos de un formulario de HTML (FORM), las cabeceras de la petición HTTP, los
cookies de la petición, etc. Por otro lado, el HttpServletResponse tiene métodos
que nos permiten especificar los códigos de respuesta de HTTP (200, 404, etc.),
las cabeceras de respuesta (Content-Type, Set-Cookie, etc.). Y lo más
importante, nos permiten obtener un PrintWriter (una clase de Java que
representa un “fichero” de salida) usado para generar los datos de salida que se
enviarán de vuelta al cliente. Para Servlets sencillos, la mayoría del código se
destina a trabajar con este PrintWriter en sentencias println que generan la
página deseada.
El primer paso para construir un Servlet que devuelva HTML al cliente es notificar
al contenedor de Servlets que el retorno de nuestro Servlet es de tipo HTML. Hay
que recordar que HTTP contempla la transferencia de múltiples tipos de datos
mediante el envío de la etiqueta MIME de marcado de tipo: Content-Type. Para
ello disponemos de un método que nos permite indicar el tipo retornado,
setContentType.
{
response.setContentType(“text/html”);
PrintWriter out = response.getWriter();
out.println(
“<!DOCTYPE HTML PUBLIC \”-//W3C//DTD HTML 4.0 “ +
“Transitional//EN\”>\n” +
“<HTML>\n” +
“<HEAD><TITLE>Hola</TITLE></HEAD>\n” +
“<BODY>\n” +
“<H1>Hola web</H1>\n” +
“</BODY></HTML>“);
}
}
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
import java.util.*;
public class DosParams extends HttpServlet
{
public void doGet(HttpServletRequest request,
HttpServletResponse response)
throws ServletException, IOException
{
response.setContentType("text/html");
PrintWriter out = response.getWriter();
String tit= "Leyendo 2 Parametros";
out.println(Utilidades.cabeceraTitulo(tit) +
"<BODY>\n" +
"<H1 ALIGN=CENTER>" + tit + "</H1>\n" +
"<UL>\n" +
" <LI>param1: "
+ request.getParameter("param1") + "\n" +
" <LI>param2: "
+ request.getParameter("param2") + "\n" +
"</UL>\n" +
"</BODY></HTML>");
}
public void doPost(HttpServletRequest request,
HttpServletResponse response)
throws ServletException, IOException
{
doGet(request, response);
}
}
Este ejemplo de Servlet lee dos parámetros llamados param1, param2 y nos
muestra sus valores en una lista de HTML. Podemos observar el uso de
getParameter y cómo, haciendo que doPost llame a doGet, se consigue que la
aplicación responda a los dos métodos. Disponemos, si fuera necesario, de
métodos para leer la entrada estándar, al igual que en la programación de CGI.
Un ejemplo más complejo que ilustrará toda la potencia del API de Servlets. Este
ejemplo recibe los datos de un formulario, busca los nombres de los parámetros
y los pinta, indicando los que tienen valor cero y los de múltiples valores.
Un ejemplo simple de página JSP que nos introducirá algunos de los conceptos
básicos del estándar es la siguiente:
<HTML>
<BODY>
<H1>Bienvenido. Día: < %= fecha %> </H1>
<B>
< % if(nombre==null)
out.println(“Nuevo Usuario”);
else
out.println(“Bienvenido de nuevo”);
%>
</B>
</BODY>
</HTML>
Las páginas JSP normalmente tienen extensión .jsp y suelen colocarse en el
mismo directorio que los ficheros HTML. Como podemos ver, una página .jsp no
es más que una página HTML en la que incrustamos trozos de código Java,
delimitados por < % y %>. Las construcciones delimitadas por < % y %>
pueden ser de tres tipos:
Elementos de script
Los elementos de script nos permiten insertar código Java dentro del Servlet
resultante de la compilación de nuestra página JSP. Tenemos tres opciones de
inserción de código:
Este código mostrará el usuario remoto (si está autenticado) y la fecha en que se
solicitó la página. Podemos ver en el ejemplo que estamos utilizando una
variable, request, que representa la petición de HTTP. Esta variable predefinida
pertenece a un conjunto de variables predefinidas de las que podemos servirnos:
request: el HttpServletRequest
response: el HttpServletResponse
session: el HttpSession asociado con el request (si existe)
out: el PrintWriter usado para enviar la salida al cliente
Declaraciones JSP
Las declaraciones nos permiten definir métodos o campos que serán
posteriormente insertados en el Servlet fuera del método service. Su forma es
como:
< %! codigo %>
Las declaraciones no generan salida. Por ello suelen usarse para definir variables
globales, etc. Por ejemplo, el siguiente código incluye un contador en nuestra
página:
< %! private int visitas = 1; %>
Visitas a la página durante el funcionamiento del servidor:
< %= visitas++ %>
Indicar que este contador se pone a uno cada vez que el contenedor de Servlets
se reinicia o cada vez que modificamos el Servlet o el fichero JSP (lo que obliga
al servidor a recargarlo). El equivalente a las declaraciones para XML es:
<jsp:declaration> código </jsp:declaration>
BIBLIOGRAFIA