Introducción al desarrollo de aplicaciones web Arquitectura web en aplicaciones empresariales basadas en tecnología Java/J2EE César Fernández Acebal Universidad de Oviedo www.cesaracebal.com acebal@uniovi.es

Índice Introducción a Internet y la Web HTTP, HTML, URL, servidores web… Introducción a las páginas dinámicas CGI, ASP, JSP y Servlets, etc. Mantenimiento de la sesión del usuario Servidores de aplicaciones

Introducción a Internet y la Web La Web es una vasta colección de documentos en Internet que están enlazados a través de los hiperenlaces Internet: millones de ordenadores conectados Un conjunto de redes heterogéneas conectadas entre sí mediante el protocolo TCP/IP Los hiperenlaces permiten a los usuarios acceder a documentos situados en otros servidores web, sin preocuparse de su ubicación

Tecnologías clave de Internet Veamos una somera introducción a las tecnologías fundamentales sobre las que se sustenta Internet, que serán útiles para comprender posteriormente algunas de las dificultades intrínsecas del desarrollo de aplicaciones web.

Tecnologías claves de Internet La infraestructura de Internet es proporcionada fundamentalmente por tres tecnologías: La conmutación de paquetes El protocolo TCP/IP La arquitectura cliente/servidor

Conmutación de paquetes Consiste en dividir un mensaje en trozos denominados “paquetes”, enviar éstos por diferentes caminos y ensamblarlos una vez que lleguen a su destino para recomponer el mensaje original. Surge como respuesta a las redes de conmutación de circuitos, como la telefónica El primer libro sobre esta tecnología data de 1964 (Leonard Kleinrock) y luego fue desarrollada por otros en laboratorios de investigación de Estados Unidos e Inglaterra Con la conmutación de paquetes, la capacidad de una red (su “ancho de banda”) se incrementa en un factor de 100 o más

Conmutación de circuitos Era la que usaban las primeras redes de ordenadores, a imagen y semejanza de la telefónica En ellas, se establece una comunicación “punto a punto” entre ambos extremos mientras tiene lugar la comunicación Existe un canal “dedicado” entre ambos, independientemente de los datos que se estén enviando Problemas: Ineficiente Poco fiable (Si se corta el canal, se interrumpe la conexión)

Ejemplo de conmutación de circuitos Una vez establecido el circuito, es siempre el mismo durante toda la conexión. Telecable Telefónica

Conmutación de paquetes Es la tecnología que emplea la red Internet Los mensajes se dividen en paquetes A cada paquete se le añaden la dirección de origen y destino, el número de secuencia, información de control de errores… En vez de enviarse directamente a la dirección de destino, los paquetes viajan de una máquina a otra hasta alcanzar su destino Estas máquinas se denominan routers Ordenadores que interconectan las diferentes subredes y que son capaces de encaminar los paquetes de una a otra Para asegurar que siguen la mejor ruta disponible, utilizan programas llamados algoritmos de encaminamiento (“routing algorithms”)

La heroica ciudad dormía la siesta. Ejemplo El mensaje original a transmitir se divide en cuatro paquetes, con cierta información de control adicional que permita su reconstrucción en el destino. La heroica ciudad dormía la siesta. Origen 192.168.1.1 Destino 10.0.0.1 Nº de bytes 144 Nº de paquetes 4 Posición 1 Datos La heroica Origen 192.168.1.1 Destino 10.0.0.1 Nº de bytes 144 Nº de paquetes 4 Posición 2 Datos ciudad do Origen 192.168.1.1 Destino 10.0.0.1 Nº de bytes 144 Nº de paquetes 4 Posición 3 Datos rmía la si Origen 192.168.1.1 Destino 10.0.0.1 Nº de bytes 139 Nº de paquetes 4 Posición Datos esta.

Ventajas de la conmutación de paquetes Al no tener un circuito dedicado, puede hacer uso en cada momento de cualquiera de las rutas disponibles Hace uso de casi la totalidad del ancho de banda disponible “Casi la totalidad” porque es necesario incluir información de control, que no formaría parte del mensaje en sí a transmitir Si algunas líneas estuvieran caídas o demasiado ocupadas, los paquetes se envían por otra de las disponibles

TCP/IP Si bien la conmutación de paquetes supuso un gran avance en la capacidad de las redes de comunicaciones, era necesario implementar el modo de llevarla a cabo Eso es de lo que se encargan los protocolos TCP/IP Transmission Control Protocol (TCP) Internet Protocol (IP) Un protocolo es un conjunto de reglas para formatear, ordenar y comprimir mensajes, comprobar errores, etc. Pueden ser implementados por hardware o por software

Cuatro capas La familia de protocolos TCP/IP se divide en cuatro capas: La capa de red es la de más bajo nivel Representa el medio físico encargado de enviar en última instancia los 0 y 1 que componen cada mensaje Diversas tecnologías: Ethernet, ATM… La capa de Internet es donde se sitúa el protocolo IP Esquema de direcciones, encaminamiento de los mensajes… En la capa de transporte está TCP Envía acuses de recibo, reagrupa el mensaje en destino, vuelve a mandar los paquetes perdidos o defectuosos… Por último, en la capa de aplicación están los programas que hacen uso de los servicios proporcionados por las capas inferiores HTTP (HyperText Transfer Protocol), FTP (File Transfer Protocol), SMTP (Simple Mail Transfer Protocol)…

Arquitectura de TCP/IP

Encaminamiento de paquetes con TCP/IP

Direcciones IP Cada ordenador conectado a Internet debe tener una dirección para poder recibir los paquetes TCP Ésta puede ser: Estática Fija, siempre la misma Dinámica Por ejemplo, cada vez que nos conectamos a Internet con un módem telefónico, nuestro proveedor de Internet (ISP, Internet Service Provider) nos asigna una dirección temporal Las direcciones IP son números de 32 bits separados en cuatro partes (por ejemplo, 156.35.94.5) Cada uno va de 0 a 255; esto nos da un total de 232 direcciones (algo más de cuatro mil millones)

IPv6 El problema es que con cada vez más y más dispositivos conectados, este esquema de direcciones está cercano a quedarse pequeño Por ello, se está desarrollando una nueva versión, denominada IPv6 para sustituir a la actual (IPv4), que con 128 bits podrá tener 3,4 × 1038 direcciones Además, mejora otras deficiencias de IPv4

Nombres de dominio y URL Para no tener que recordar direcciones IP tal cual, éstas pueden ser representadas mediante nombres de dominio (por ejemplo, www.euitio.uniovi.es) El sistema de nombres de domino (DNS) permite que éstas se resuelvan a direcciones IP Ejemplo: ping www.euitio.uniovi.es Los URL (Uniform Resource Locator) son las direcciones que escribimos en el navegador Como http://www.euitio.uniovi.es/

Computación Cliente/Servidor En este modelo de computación distribuida, un cliente solicita una acción a un servidor, que le devuelve los resultados Puede haber diversos tipos de clientes, desde los más ligeros (como un navegador Web, que únicamente es capaz de mostrar documentos HTML) hasta clientes pesados que también realizan procesamiento Surgen como respuesta a los mainframes de los 60 y 70 (con 128 KB de RAM y y discos duros de 10 MB) Despega este modelo con el advenimiento de los ordenadores personales Toda Internet es una inmensa red cliente/servidor

Esquema Cliente/Servidor

Introducción a la Web Ahora, veremos los principios básicos de la World Wide Web (WWW o Web, a secas): lenguajes, protocolos, servidores y clientes, etcétera.

Internet ≠ Web Internet permite a cualquier ordenador del mundo compartir datos con otro ordenador remoto Un programa cliente en un ordenador accede a un programa servidor en otro ordenador remoto La Web es el sistema de hipertexto que funciona sobre Internet como uno de sus servicios En este caso, el programa cliente es nuestro navegador, y el servidor el programa que hace de servidor web que está ejecutándose en el ordenador remoto y que se encarga de entregar el documento solicitado a nuestro navegador

Nacimiento de la World Wide Web En 1989, Tim Berners-Lee, en el laboratorio europeo de partículas (CERN), en Suiza, crea un lenguaje de etiquetas para representar y enlazar documentos HTML —HyperText Markup Language Lenguaje de Marcado de Hipertexto Tim Berners-Lee Berners-Lee creó las versiones iniciales de: HTML, HTTP, un servidor web y un navegador Los cuatro componentes esenciales de la Web

Esquema general Cliente/Servidor Petición Red Servidor Respuesta Cliente

Visión general de la Web www.cesaracebal.com index.html Internet enlace El usuario teclea http://www.cesaracebal.com/ en su navegador www.uniovi.es

Visión general de la Web El usuario solicita un documento tecleando su dirección en el navegador: http://www.uniovi.es Es lo que se denomina un URL (localizador uniforme de recursos) El cliente busca en el DNS cuál es la IP de www.uniovi.es: 156.35.14.3 Cada ordenador en Internet está identificado por una dirección única denominada IP El DNS traduce de nombres lógicos a direcciones físicas Navegador y servidor web comienzan un diálogo a través del protocolo HTTP (protocolo de transferencia de hipertexto) GET /HTTP/1.0 El servidor, si todo es correcto, devuelve el documento solicitado más información adicional

Visión general de la Web El navegador mira el tipo de documento devuelto (MIME) Si es “text/html” es un documento HTML, lo visualiza el propio navegador Si es otro tipo de documento se ejecutará el programa que tenga asociado, o nos preguntará si queremos guardar el documento en nuestro ordenador Nota: estos tipos MIME los podemos configurar en nuestro navegador

Funcionamiento de la Web Éste envía una petición al servidor Web HTTP Tecleamos una dirección en el navegador (por ejemplo, www.euitio.uniovi.es) Quien devuelve la página solicitada (en este caso, la index.html del directorio raíz) Y el navegador se encarga de interpretar el código HTML y mostrar el resultado

Funcionamiento de la Web Un servidor web es un ordenador en Internet que sirve páginas web a petición Para ello, debe tener un programa ejecutándose que haga de servidor web: Apache, IIS, etcétera El usuario accede a la web a través de un navegador (browser) Se encarga de solicitar las páginas web al servidor y de mostrarlas

HTML Es el lenguaje de creación de páginas Web Al menos, de las páginas “estáticas” Era imprescindible que la misma información se pudiese ver en diferentes plataformas Por tanto, Berners-Lee diseñó un lenguaje de estructuración de documentos, no de presentación (ésta se dejaba al programa cliente)

HTML es un lenguaje Como tal, tiene unas reglas que deben ser cumplidas, esto es, una sintaxis, una gramática... igual que el español o cualquier otro lenguaje informático Es además un lenguaje informático, para ser procesado por ordenadores; pero no es un lenguaje de programación

¿Por qué de marcado ? ¿Qué vemos de un vistazo en el siguiente texto? Acme Computer Corp. Acme Computer Corporation is a technology-based company that seeks to offer its customers the latest in technological innovation. Our products are created using the latest breakthroughs in computers and are designed by a team of top- notch experts. We are based in Acmetown, USA, and have offices in most major cities around the world. Our goal is to have a global approach to the future of computing. Have a look at our product catalog for some examples of our innovative approach. Que tiene un título y dos párrafos Pero un ordenador sólo vería un montón de caracteres Necesitamos un modo de indicarle la estructura del documento

HTML, lenguaje de hipertexto Por hipertexto designamos al texto al que se le añade una propiedad: determinadas porciones de texto pueden ser enlazadas a otros documentos De ahí surge el concepto de navegación: surcamos el Web yendo de unos enlaces a otros El hipertexto debe ser utilizado en los sitios web para facilitar al usuario la labor de búsqueda de la información

¿Qué necesitamos para crear un documento HTML? Un editor de texto ¡Ojo!, no un procesador de textos tipo el Word, por ejemplo Debe ser texto plano, sin formato (p. ej., con el Bloc de Notas) Le daremos la extensión .html o .htm, y un nombre sin espacios ni caracteres especiales Nota: ninguna de las dos características son obligatorias, pero nos ahorrarán problemas

¿Y para verlo? Un programa cliente que entienda lenguaje HTML (que pueda visualizar de alguna manera documentos HTML) Técnicamente, recibe el nombre de HTML User Agent Un ejemplo de agente de usuario son los navegadores (literalmente, hojeadores) web (web browsers) El navegador es quien se encarga de la presentación del documento (el estándar no especifica cómo debe visualizarse cada elemento)

Especificación de HTML La especificación del lenguaje HTML y de la mayoría de tecnologías relacionadas con el Web está definida por el World Wide Web Consortium (W3C) www.w3c.org Nota: Ahora, HTML ha dado lugar a una variación del mismo denominada XHTML

El World Wide Web Consortium (W3C) Consorcio formado por cerca de 500 organizaciones que dicta los estándares de la Web HTML, CSS, XML, XHTML, DOM… http://www.w3.org Objetivo: promover la evolución de la Web garantizando que las distintas tecnologías funcionen bien conjuntamente Dirigido por Tim Berners-Lee, el inventor de la Web, en 1989 Premio Príncipe de Asturias de Investigación Científica y Técnica 2002 Tim Berners-Lee

La Oficina Española del W3C En octubre de 2003 se presentó la Oficina Española del W3C, sita en Asturias www.w3c.es Concretamente, albergada en las instalaciones de la Fundación CTIC, en el Parque Científico Tecnológico de Gijón Responsables de la Oficina: José Manuel Alonso Responsable de la oficina Jesús García Coordinador Experto en accesibilidad Acto de presentación de la Oficina Española, en el Hotel de la Reconquista (Oviedo)

Ejemplo de documento HTML holaMundo.html <?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <title>Introducción a HTML</title> </head> <body> <h1>Mi primera página Web</h1> <p> Éste es el equivalente al típico <em>¡Hola, mundo!</em> pero en HTML (cuya <a href="http://www.w3.org/MarkUp/" title="Especificación de las distintas versiones de HTML y XHTML en el W3C">especificación</a> puede encontrarse en el sitio Web del <acronym title="World Wide Web Consortium">W3C</acronym>). </p> </body> </html>

HTTP HTTP (HyperText Transform Protocol) es el protocolo usado para transferir páginas web Es el modo en que un navegador se comunica con un servidor Web (Apache, Internet Information Server…) Es un protocolo sin estado La sesión termina en cuanto se devuelve el objeto solicitado Incluso, si una página contiene otros objetos (imágenes, frames, etc.) cada uno de ellos inicia una nueva petición HTTP

Pero… ¿y TCP/IP? HTTP TCP/IP ¿No era TCP/IP el conjunto de protocolos sobre los que sustenta Internet? ¿Qué es eso de HTTP? La comunicación entre el navegador y el servidor web se realiza mediante HTTP La transmisión efectiva de información la controla TCP/IP TCP/IP HTTP

Ejemplo de mensaje HTTP Petición GET / HTTP/1.0 > > Respuesta < HTTP/1.0 200 OK < Date: Wed, 18 Sep 1996 20:18:59 GMT < Server: Apache/1.0.0 < Content-type: text/html < Content-length: 1579 < Last-modified: Mon, 22 Jul 1996 22:23:34 GMT < HTML document

URL URI: Uniform Resource Identifier URL: Uniform Resource Locator Un URL es la dirección única de todo documento en la Web http://www.eutio.uniovi.es/

protocolo://dirección[:puerto]/directorio/fichero Sintaxis de un URL protocolo://dirección[:puerto]/directorio/fichero Ejemplos: http://www.princast.es/ http://195.55.30.17/ http://www.cfacebal.com/ http://www.cfacebal.com/index.html http://web.uniovi.es/Vicerrectorados/Extension/ http://localhost:8080/ http://petra.euitio.uniovi.es/

Protocolo Un protocolo define el modo en que se comunican dos ordenadores para llevar a cabo alguna tarea Protocolo de la Web: HTTP (HyperText Transfer Protocol) Especifica cómo tiene lugar el diálogo entre el navegador y el servidor para conseguir el fichero especificado No se ocupa del transporte en sí: TCP Cada vez que tecleamos una dirección o pulsamos un enlace el navegador se comunica vía HTTP con el servidor web indicado

Ejemplos de protocolos file Permite acceder a un fichero en el sistema de ficheros local ftp File Transfer Protocol http Páginas web

Dirección del sitio Suele ser un nombre simbólico: nombre de dominio www.uniovi.es especifica una máquina llamada “www” en el dominio “uniovi.es” El nombre de máquina puede ser cualquiera “www” no es más que un convenio para especificar aquellas máquinas que son servidores Web como “ftp” suele designar a los servidores de FTP incluso aunque muchas veces se trate de la misma máquina

Dirección del sitio También podría ser directamente la dirección IP http://156.35.14.3/ Los nombres de dominio no distinguen entre mayúsculas y minúsculas http://www.uniovi.es/ http://WWW.UNIOVI.ES/ http://wWw.UniOvi.es/

Directorio Hay que indicar la ruta hasta el fichero deseado Como mínimo, debe ir la barra (“/”) http://www.uniovi.es/ Si no la ponemos, la pone el navegador por nosotros ...pero en los enlaces en HTML sí debe aparecer También se puede indicar un subdirectorio: http://www.uniovi.es/Vicerrectorados/Postgrado_TitulosPropios/doctorado/ Siempre se usa la barra “/”, no “\” (incluso aunque el servidor Web sea una máquina Windows: está definido por el estándar URI, no depende del SO) La ruta sí puede diferenciar entre mayúsculas y minúsculas (si el servidor web es, por ejemplo, una máquina Unix)

Nombre del fichero Depende del sistema operativo del servidor web Las páginas Web generalmente tienen como extensión .html o .htm Las extensiones son importantes para que el navegador sepa cómo tratar un fichero un .html, lo interpreta y lo muestra un .jpg, trata de mostrar la imagen un .doc, abre el Word si lo tenemos instalado etcétera

Nombre del fichero Si no se especifica, el servidor busca un fichero con un nombre determinado en el directorio especificado Normalmente, el index.html o el index.htm Se puede configurar el el programa que utilicemos como servidor web (Apache, IIS...)

Puerto Por omisión, una petición HTTP se dirige al puerto 80 Por eso casi nunca la especificamos Pero se podría configurar el servidor web para que “escuchase” peticiones en otro puerto En ese caso, hay que indicarlo explícitamente: http://www.midominio.com:8080/

¿Qué es un servidor Web? Un programa que atiende las peticiones HTTP llegadas a un puerto determinado de la máquina También se denomina así, por extensión, a la máquina que cuenta con uno de tales programas Ejemplos de servidores web: Apache Apache HTTP Server Project http://httpd.apache.org/ Internet Information Server (IIS)

Descarga de Apache La versión actual es la 2.0.54 Dirección de descarga: http://httpd.apache.org/download.cgi Ahí podemos obtener tanto los fuentes para Unix o Windows (que habrá que compilar) como un programa de instalación para Windows (Win32 Binary)

Instalación de Apache (Windows) Opciones de instalación: Como servicio en el puerto 80 Para ser arrancado manualmente (puerto 8080) No da conflictos con otro servidor Web que ya pudiéramos tener instalado en el puerto 80 No requiere ningún privilegio de administración de Windows Por no ser instalado como servicio Por estar en un puerto superior al 1024 Dominio, dirección del servidor y correo del administrador Directorio de instalación C:/Apache

Ejecución Una vez finalizada la instalación, hay que ejecutar Apache manualmente c:/Apache/Apache2/bin/Apache.exe Ahora, ya podemos comenzar a solicitarle páginas Nuestra máquina ya puede actuar como servidor web Aunque en local; si quisiéramos que funcionase a través de la red, habría que crear un usuario para Apache y darle los permisos necesarios Para probar si funciona, tecleamos en el navegador: http://localhost:8080/ o http://127.0.0.1:8080/ Deberá aparecer la página siguiente:

Página de prueba de la instalación

¿Qué hace un servidor Web cuando recibe una solicitud? Si el último elemento del URL es un fichero: Si se incluye una ruta de directorios, lo buscará a partir del indicado en la directiva DocumentRoot Por omisión, es el directorio htdocs dentro del directorio de instalación de Apache

¿Qué hace un servidor Web cuando recibe una solicitud? En el caso de que el último elemento del URL sea un directorio, sin especificar el fichero: Si en dicho directorio existe un fichero index.html (o lo que se especifique en DirectoryIndex), se devolverá éste Si no existe dicho fichero, y siempre y cuando esté habilitada la opción Options Indexes) se hará un listado del directorio

Índice Introducción a Internet y el Web HTTP, HTML, URL, servidores Web… Introducción a las páginas dinámicas CGI, ASP, JSP y Servlets, etc. Mantenimiento de la sesión del usuario Servidores de aplicaciones

Páginas estáticas Al principio, el Web estaba poblado únicamente por páginas estáticas El servidor Web simplemente localizaba el documento solicitado en el URL y se lo entregaba al cliente Este enfoque puede ser perfectamente válido para muchos sitios Siempre y cuando no requieran actualizaciones continuas, ya que hay que eso implica o bien modificar, a mano, las páginas existentes, o bien crear una nueva Pero no permitiría, por ejemplo, crear un sitio de comercio electrónico donde se pueda comprar, o el de un banco Es necesario acceder a datos en el servidor y crear una página a petición

Funcionamiento de las páginas estáticas

Funcionamiento de las páginas dinámicas

Modo de funcionamiento El esquema de funcionamiento de las páginas dinámicas es siempre similar independientemente de en qué se hayan desarrollado éstas CGI, ASP, Servlets/JSP… El servidor Web detecta una petición de una página dinámica y se la pasa al programa necesario Podría ser una extensión del servidor O bien un programa completamente independiente Éste programa es quien sabe cómo interpretar el código de la página para devolver el HTML apropiado

CGI CGI fue la primera tecnología que permitió crear páginas dinámicas, que realizaban algún tipo de procesamiento en el lado del servidor.

CGI: Common Gateway Interface Es un estándar que permite el intercambio de información entre servidores Web y programas externos Así, mientras que un documento HTML es estático (un fichero de texto que no cambia), un programa CGI permite mostrar información dinámica, al ejecutarse Por ejemplo, puede hacer una consulta a una base de datos ubicada en el servidor y mostrar los resultados en HTML

/cgi-bin/buscar.cgi?texto=“web standards” Introducción El servidor Web invoca al programa CGI pasándole los parámetros recibidos Los datos del formulario son enviados vía HTTP HTTP El usuario, por ejemplo, rellena un formulario y pulsa el botón de enviar Y éste devuelve el resultado al servidor por medio de la salida estándar

Ejemplo: Hola, mundo #!C:\Perl\bin\perl.exe print "Content-type: text/html\n\n"; print "<html>\n<head>\n<title>El Hola, mundo en  CGI</title>\n</head>\n<body>\n"; print " <p>¡Hola, mundo</p>\n"; print "</body>\n</html>";

¿Cómo obtiene el programa los datos necesarios? Depende del método HTTP por el que se envíen GET Los datos viajan codificados en el propio URL POST Los datos viajan encapsulados en el propio mensaje HTTP Hay dos formas posibles en que el servidor Web puede pasarle los datos al programa CGI: Mediante las variables de entorno Mediante la entrada estándar (stdin)

Variables de entorno La tabla siguiente muestra alguna de las variables de entorno: (Puede verse una lista completa en http://hoohoo.ncsa.uiuc.edu/cgi/env.html) Variable Descripción SERVER_NAME El nombre del servidor o su dirección IP QUERY_STRING La información que sigue al “?” en el URL que referencia a este programa CONTENT_LENGTH Para consultas que llevan asociada información (por ejemplo, las hechas mediante POST), el tamaño en bytes de dicha respuesta PATH_INFO …

Acceder a las variables de entorno La forma de acceder al contenido de dichas variables desde el programa CGI varía dependiendo del lenguaje en que haya sido escrito Por ejemplo, a continuación se muestra cómo acceder al valor de la variable SERVER_NAME en C y en Perl: C getenv("SERVER_NAME") Perl $ENV{'SERVER_NAME'}

Ejemplo El siguiente programa CGI en Perl muestra el valor de todas las variables de entorno: #!/usr/bin/perl print "Content-type: text/html\n\n"; foreach $key (keys %ENV) { print "$key --> $ENV{$key}<br>"; }

Configuración de Apache para CGI Antes, es necesario saber qué debemos hacer en el fichero de configuración de Apache (httpd.conf) para permitir la ejecución de programas CGI

Directiva ScriptAlias Aunque hay otras formas de hacerlo en Apache, por motivos de seguridad suele hacerse mediante la directiva ScriptAlias Definiendo un único directorio para todos los programas (scripts) CGI ScriptAlias /cgi-bin/ "C:/Apache/Apache2/cgi-bin/"

Intérprete de Perl Además, claro está, necesitamos tener un intérprete de Perl instalado en nuestra máquina Podemos obtener uno para Windows en: http://www.activestate.com/

Entrada estándar El contenido de un formulario enviado mediante el método POST está disponible como un flujo de caracteres en la entrada estándar En ese caso, la variable de entorno CONTENT_LENGTH indica el número total de bytes disponibles El programa puede así obtener esa información como si estuviese leyendo de un fichero o del teclado Los datos del formulario se codifican en un determinado formato, muy simple

Formato de los datos Consiste en pares nombre=valor separados por “&” Los caracteres especiales, como espacios en blanco, “=” y “&” se convierten a su valor hexadecimal La cadena de datos completa sería similar a ésta: Hay bibliotecas de funciones que dividen dicha cadena en partes, ahorrándonos así la labor de procesamiento name=Rich%20Bowen&city=Lexington&state=KY

Entrada estándar. Ejemplo en Perl #!/usr/local/bin/perl #Script 'example1-b.cgi‘ # print "Content-type: text/html","\n\n"; if ($ENV{'REQUEST_METHOD'} eq "POST“ && $bytes=$ENV{'CONTENT_LENGTH'}) { read(STDIN,$input,$bytes); print "I read the following data:<BR>"; print $input; } else { print "Please give me a POST request with some data<BR>\n"; } exit(0);

Entrada estándar. Ejemplo en C El mismo programa que antes, ahora en C: int main(int argc, char ** argv) { char *type,*length,*input; int bytes; printf("Content-type: text/html"); printf("\n\n"); if(type=getenv("REQUEST_METHOD") && length=getenv("CONTENT_LENGTH") ) { bytes=atoi(length); input=malloc(length+1); read(stdin,input,bytes); printf("I read the following data:<BR>"; printf("%s",input); } else { printf("Please give me a POST request with some data<BR>\n") exit(0);

¿Cómo llegan los datos cuando se usa GET en vez de POST? En ese caso, la cadena que venía antes por la entrada estándar ahora se añade al URL, tras un “?” Luego, al llegar al servidor Web, éste mete esa información en la variable de entorno QUERY_STRING A través de la cual ya está disponible para el programa CGI, como veíamos antes

Introducción a ASP Una vez visto CGI, y como paso previo antes de ver la tecnología J2EE, que será el objetivo propiamente dicho del curso, echémosle un vistazo a esta otra tecnología de páginas dinámicas.

Requisitos de software Uno de los inconvenientes de ASP es que es dependiente de un servidor Web concreto El Internet Information Server (IIS) de Microsoft Dicho servidor ya viene de manera predeterminada en las últimas versiones de Windows Aunque quizá no lo hayamos instalado junto con el Sistema Operativo En ese caso, podríamos hacerlo a través de la opción de Añadir o quitar componentes de Windows del Panel de Control ¿Cómo probar si está instalado? Teclear en el navegador http://localhost/

Sintaxis general ASP, al igual que las JSP de Java, se basa en mezclar instrucciones de programación en nuestras páginas HTML El motor de ASP procesará dichas instrucciones dinámicamente y obviará el HTML Esto permite generar HTML dinámicamente, añadiendo lógica a nuestras páginas Para ello, hay que encerrar el código ASP entre los símbolos <% %>

Lenguaje de programación ¿Y en qué lenguaje se escriben esas instrucciones? ASP permite el uso de dos lenguajes: Visual Basic Script (VBScript) JScript (como denomina Microsoft a su implementación de ECMAScript –que a su vez es el estándar de JavaScript–) Si no decimos nada, por omisión asume VBScript Será el lenguaje que emplearemos en los ejemplos Es el más frecuente cuando hablamos de páginas ASP

Ejemplo: mi primera página ASP Será –¡cómo no!– el archiconocido “Hola, mundo” La página siguiente escribe dinámicamente el mensaje <html> <head> <title>Mi primera página ASP</title> </head> <body> <h1> <% Response.Write “¡Hola, mundo!" %> (mi primera página ASP) </h1> </body> </html>

¿Cómo probamos la página? Si la abrimos directamente en el navegador, no veremos el mensaje O veríamos el código fuente U obtendríamos un error (si los navegadores validasen el código HTML que reciben) Para que tenga sentido, es necesario que la interprete el motor de ASP Es decir, que reciba la petición el IIS

Administración del IIS Se instala en el directorio C:/Inetpub Dentro de él, el directorio raíz del servidor está en wwwroot Y ahí es donde deberemos poner nuestra página (También podríamos configurar directorios virtuales) Creamos una carpeta ejemplos y llamamos holaMundo.asp al fichero anterior La forma de ejecutarlo es: http://localhost/holaMundo.asp

Otro ejemplo, más “dinámico” Naturalmente, para el viaje anterior no hacen falta tantas alforjas No tiene ningún sentido emplear una página dinámica para eso Hagamos ahora una página que muestre algo de información dinámica Por ejemplo, que diga “Buenos días” o “Buenas tardes” en función de la hora

Saludo personalizado: fecha y hora <% ‘ Crear algunas variables Dim fecha Dim hora ‘ Obtener la fecha y la hora fecha = Date() hora = Time() ' Imprimir un saludo en función de la hora If Hour(hora) >= 12 Then Response.Write "¡Buenas tardes!" Else If (Hour(hora) >= 20) Or (Hour(hora) < 6) Then Response.Write "¡Buenas noches!" Response.Write "¡Buenos días!" End If %> Hoy es <%=fecha%> y son las <%=hora%>

Objetos predefinidos ASP tiene los siguientes objetos predefinidos: Application Permite compartir información entre todos los usuarios de una aplicación (en esto se diferencia de Session) ASPError ObjectContext Request Para obtener información de la petición HTTP (parámetros, cookies…) Response Para enviar datos al cliente (escribir código HTML, redirigir a otra página, etc.) Server Fundamentalmente, para crear objetos de componentes del servidor Session Permite almacenar el estado de la sesión

Acceso a bases de datos Prácticamente cualquier aplicación Web va a necesitar acceder a una base de datos en el servidor

Aplicación de ejemplo Veremos una aplicación de ejemplo que simulará un sitio Web sobre cine, con información acerca de las películas: Se podrá buscar una película por su título y listar todas las películas de un determinado director Además, de cada película se podrá ver información detallada: Director, año de estreno, intérpretes, sinopsis Y se podrá ver el cartel de la película (en pequeño y en grande)

Diseño de la base de datos Cada película tiene varios actores, y un actor puede participar en varias películas Intérprete Película n n

Relación actor-película Una relación “n” a “n” no puede modelarse directamente en una base de datos relacional, sino que necesitamos una tabla intermedia: Intérprete Película 1 1 Reparto n n

Cartel Para poder mostrar el cartel de cada película de forma automática, guardamos el nombre del fichero de imagen en la base de datos Y las guardamos todas en el mismo directorio del sitio Web, con ese mismo nombre

Creación de la base de datos Nos servirá Microsoft Access Luego se podrá acceder a ella desde las páginas ASP independientemente del Sistema de Gestión de Bases de Datos utilizado (Access, Oracle, SQL Server…) La forma más flexible es hacerlo mediante ODBC Permite acceder de forma genérica a cualquier base de datos definida en el sistema No obstante, no se utilizará en el ejemplo (Por facilidad de depuración)

Creación del origen de datos ODBC Creamos un nuevo origen de datos del tipo “Microsoft Access Driver”

Configuración de ODBC Aparecerá esta pantalla, en la que asignamos un nombre al origen de datos y seleccionamos la ubicación de la base de datos:

Seleccionar base de datos Tras pulsar el botón Seleccionar, buscamos la ubicación de la base de datos (el fichero .mdb donde hayamos creado la base de datos con Access)

Configuración de ODBC Éste deberá ser el aspecto de la ventana una vez configurado el nuevo origen de datos: Sólo falta pulsar Aceptar para que sea creado

Origen de datos creado Ahora ya está creado el origen de datos para nuestra base de datos de películas

Creación de un directorio virtual

Estudio de la aplicación A continuación, examinemos el código fuente ASP de las páginas de la aplicación Iremos explicando diferentes aspectos de ASP sirviéndonos de la aplicación de ejemplo: Acceso a datos Manejo de formularios Redirección de páginas Generación de HTML dinámico (en función de determinadas condiciones) Etcétera

Índice Introducción a Internet y el Web HTTP, HTML, URL, servidores Web… Introducción a las páginas dinámicas CGI, ASP, JSP y Servlets, etc. Mantenimiento de la sesión del usuario Servidores de aplicaciones

Mantenimiento de la sesión Una de los grandes inconvenientes a solventar en las aplicaciones Web es cómo mantener la sesión del usuario. Veamos en qué consiste y qué alternativas existen para hacerlo.

HTTP, protocolo sin estado HTTP es un protocolo sin estado Esto significa que para el servidor Web cada petición de una página es única No tendría forma de saber, por ejemplo, que ese usuario acaba de añadir un producto a su carrito, o si ya se validó o no, en qué punto del proceso de compra se encuentra, etcétera Son necesarias alternativas software, por tanto, que permitan simular el estado

Alternativas Aunque hay varias formas de hacerlo (dependiendo de si trabajamos en ASP, en J2EE…) la mayoría pasan por el uso de “cookies” Algunas de las alternativas son: Usar el objeto Session (o similar) provisto por los entornos de programación como ASP o J2EE (Servlets, JSP...) Almacenar toda la información de la sesión, a mano, en una cookie (por ejemplo, mediante JavaScript) Una combinación de cookie (para guardar un ID de usuario) y bases de datos “URL rewriting” Etcétera

Cookies Veamos una introducción a las cookies y algunos ejemplos en los que aprenderemos a manipularlas.

¿Qué son las cookies? Las cookies son pequeñas porciones datos que son almacenados localmente por el navegador en forma de pequeños ficheros de texto Cada vez que el cliente envía información al servidor, incluye en la petición HTTP las cookies que previamente haya guardado provenientes de ese servidor

Detalles de implementación Según la especificación, un agente de usuario (es decir, un navegador), debe permitir al menos: Un total de 300 cookies Hasta 4 KB (4.096 bytes) por cookie Al menos 20 cookies de un servidor dado El navegador se encarga automáticamente de eliminar aquéllas que hace más tiempo que no se utilizan cuando necesita guardar nuevas cookies

Sintaxis Cada cookie presenta la siguiente sintaxis general: Lo único obligatorio es que tenga un nombre y un valor asociado; el resto de atributos son opcionales Aunque también se utiliza bastante el atributo expires nombre=valor; [expires=fecha; path=directorio; domain=nombreDeDominio; secure]

Descripción de los atributos Un par nombre = valor Por ejemplo: IDUsuario = 49; expires Hasta cuándo será válida la cookie Debe ir en este formato: Wdy, DD-Mon-YYYY HH:MM:SS GMT Si no se dice nada, la cookie será eliminada al terminar la sesión Es decir, al cerrar la ventana actual del navegador path El conjunto de directorios del servidor para los que es válida esta cookie (por omisión, será el raíz “/”, es decir, todos)

Descripción de los atributos (2) domain El servidor o nombre de dominio para el que es válida la cookie Una cookie sólo puede ser leída y modificada desde el servidor y directorio especificados en la cookie cuando ésta fue creada secure Es booleano; si está definido (si aparece el atributo) deberá haber una conexión segura (https) para que la cookie sea enviada

Veamos de qué forma podemos establecer y leer cookies en ASP. Uso de cookies en ASP Veamos de qué forma podemos establecer y leer cookies en ASP.

Response.Cookies Mediante la colección Cookies del objeto predefinido Response podemos establecer el valor de una cookie Si la cookie especificada no existe, se creará Si existe, machacará el valor que tuviera anteriormente Ejemplo: <% Response.Cookies(“IDUsuario”) = 49 Response.Cookies(“IDUsuario”).Expires = “December 31, 2004” %>

Leer el valor de una cookie Se hace a través de la misma colección, sólo que ahora sin especificar ningún valor: <%= Request.Cookies(“IDUsuario”) %>

Ejemplo: contador de visitas Realicemos un sencillo ejemplo en el que se cuenten las visitas de un usuario a una página

URL Rewriting Consiste en incluir la información del estado en el propio URL /…/comprar.asp?paso=3&producto1=01992CX&producto2=ZZ112230&producto3=HJ19X25… No es de recibo en aplicaciones “serias” Un cliente puede iniciar dos o más sesiones simultáneas, páginas tediosas de programar, sólo se puede usar el método GET, etc.

Ventajas e inconvenientes Almacenar el estado de la sesión en el cliente presenta algunas ventajas frente a hacerlo en el servidor, pero también tiene algunos inconvenientes.

Ventajas Menor uso de los recursos del servidor Los servidores “sin estado” no necesitan reservar y mantener recursos para guardar el estado de la sesión Fácil escalabilidad y uso de clusters Al no tener estado, cualquier servidor puede atender a cualquier cliente No hace falta que un cliente siempre sea atendido por el mismo servidor, ni ningún tipo de distribución del estado entre servidores La sesión del cliente podría sobrevivir a una caída del servidor Un reintento por parte del cliente con el mismo URL suele funcionar

Inconvenientes Privacidad Los datos pueden ser alterados Otros servidores podrían leer información almacenada en las cookies del cliente No son válidas para guardar números de tarjeta, contraseñas y cosas por el estilo Los datos pueden ser alterados Un usuario podría modificar el fichero de una cookie Lo mismo ocurre con otros mecanismos de cliente: URL, formularios, etc. Aumenta el tráfico por la red El estado se transmite con cada petición al servidor

Inconvenientes Implementación compleja Tamaño de datos limitado Mantener “a mano” el estado en el cliente puede ser realmente complicado si queremos hacerlo de manera robusta (Lo hemos visto con el ejemplo del sitio Web de cine en ASP) Tamaño de datos limitado Tanto el tamaño máximo permitido por las cookies como la longitud máxima de un URL pueden darnos problemas para almacenar sesiones complejas

Índice Introducción a Internet y el Web HTTP, HTML, URL, servidores Web… Introducción a las páginas dinámicas CGI, ASP, JSP y Servlets, etc. Mantenimiento de la sesión del usuario Servidores de aplicaciones

¿Qué es un servidor de aplicaciones? Es un programa que provee la infraestructura necesaria para las aplicaciones Web empresariales ¿Qué quiere decir esto? Que los programadores van a poder dedicarse casi en exclusiva a implementar la lógica del dominio, ya que servicios de uso común, como transacciones, seguridad, persistencia, etc. ya son proporcionados por el servidor Web Se ha convertido en una pieza de software clave para cualquier empresa dedicada al comercio electrónico Es una capa intermedia (middleware) que se sitúa entre el servidor Web y las aplicaciones y bases de datos subyacentes

Visión general Servidor de aplicaciones SGBD Aplicación cliente (Transacciones, mensajería, servicios Web…) CORBA J2EE .NET SGBD

Motivación Comienzan a surgir cuando queda claro las aplicaciones cliente/servidor no iban a ser escalables a un gran número de usuarios Debido a las características de los clientes “pesados” Se hacía necesario mover las reglas de negocio a algún lugar intermedio entre los clientes y la base de datos Empezaron a surgir productos para hacer esa tarea Cada compañía los llamaba de una forma distinta Servidores de transacciones, servidores de aplicaciones…

Misión Los llamasen como los llamasen, estaban diseñados para gestionar de forma centralizada el modo en que los clientes debían conectarse a la base de datos o a los servicios con los que tenían que interoperar

Servicios proporcionados Creación y gestión de los componentes del servidor Por aquel entonces, basados en CORBA o COM Clustering Equilibrado de carga Transacciones Seguridad Acceso a datos …

Servicios proporcionados A continuación, se explicarán un poco más en detalle cada uno de los servicios anteriores, ofrecidos, en mayor o menor medida, por los servidores de aplicaciones.

Gestión de la sesión Como sabemos, HTTP es un protocolo sin sesión El servidor ha de conservar información entre peticiones del usuario a lo largo de la duración de una sesión Como sabemos, HTTP es un protocolo sin sesión No permite mantener una conexión abierta entre el cliente y el servidor más allá de lo que dura la transferencia del documento en cuestión En cualquier aplicación de comercio electrónico, es necesario poder identificar al usuario a través de su navegación por el sitio Web Autenticación, adición de productos al carrito de la compra, etc.

Gestión de la sesión (2) La implementación “a mano” se complicaría enormemente en el caso de contar con varios servidores (equilibrado de carga) La petición de un usuario registrado en la máquina A puede ser redirigida al servidor B Lo lógico es que sea el servidor de aplicaciones quien se encargue de gestionar la sesión Además, debería ser más eficiente que si lo programamos nosotros mismos

Equilibrado de carga Los servidores de aplicaciones proporcionan mecanismos de equilibrado de carga (aspecto clave para la escalabilidad) Por equilibrado de carga (load balancing) se entiende la capacidad de repartir el procesamiento entre distintos servidores Las peticiones de los clientes se redirigen a la máquina que más desocupada se encuentre en ese momento Mejora de rendimiento de la aplicación No es tan sencillo como añadir una nueva máquina y ya está Además de la escalabilidad, se consigue una mayor tolerancia a fallos

Acceso a datos Los servidores de aplicaciones proveen facilidades para administrar conexiones a bases de datos relacionales Oracle, SQL Server, DB2… Los componentes (las clases que implementan la lógica del negocio) acceden a ellas de forma estándar Independiente de la base de datos subyacente También suelen permitir acceder a otros tipos de fuentes de datos: Tales como distintos ERP (SAP, Vaan...), repositorios XML, etc. Los servidores de aplicaciones son también importantes, por tanto, como mecanismo de integración de sistemas heredados

“Pooling” de conexiones Abrir una conexión a una base de datos suele ser un proceso costoso No es viable abrir una nueva conexión por cada consulta a la base de datos Penalizaría enormemente el rendimiento de la aplicación Los servidores de aplicaciones suelen contar con una serie de conexiones permanentemente abiertas que distribuye de forma transparente a los distintos procesos Se debería poder configurar el número de conexiones abiertas, e incluso la política de asignación

Gestión transaccional Transacción: secuencia de pasos que, o se ejecutan todos, o si no el sistema queda en el estado original Son un elemento básico de cualquier aplicación comercial Evitan que haya información inconsistente Sería complejísimo implementarlas “a mano” Con un servidor de aplicaciones que tenga esta característica, bastaría con indicarle dónde empieza y termina la transacción Encargándose él de deshacer los pasos intermedios en caso de un error del sistema

Para terminar… Un comentario final, acerca de las tecnologías o plataformas típicas sobre las que se implementan los servidores de aplicaciones, junto con un sencillo esquema de una de ellas: J2EE

Tecnologías actuales Actualmente, las dos plataformas más comunes son J2EE y, más recientemente, ha surgido .NET De hecho, hasta hace poco hablar de servidores de aplicaciones era prácticamente hablar de J2EE (aunque no debemos hacer tal asociación)

Ejemplo: arquitectura J2EE