 Internet ◦ Protocolo TCP/IP ◦ Aplicaciones: DNS, FTP, SMTP, etc.  World Wide Web ◦ HTTP ◦ URLs ◦ Unicode ◦ HTML  Servidor Web ◦ Arquitectura cliente/servidor.

Presentación del tema: " Internet ◦ Protocolo TCP/IP ◦ Aplicaciones: DNS, FTP, SMTP, etc.  World Wide Web ◦ HTTP ◦ URLs ◦ Unicode ◦ HTML  Servidor Web ◦ Arquitectura cliente/servidor."— Transcripción de la presentación:

1

2  Internet ◦ Protocolo TCP/IP ◦ Aplicaciones: DNS, FTP, SMTP, etc.  World Wide Web ◦ HTTP ◦ URLs ◦ Unicode ◦ HTML  Servidor Web ◦ Arquitectura cliente/servidor ◦ Páginas estáticas/dinámicas  Servidor de Aplicaciones ◦ Servicios

3  Web = vasta colección de documentos en Internet enlazados a través de hiperenlaces hiperenlaces  Internet: millones de ordenadores conectados 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

4  (60-80) Origen militar ◦ Protocolos de comunicación (TCP/IP) ◦ Seguridad ante ataques (múltiples servidores)  (80 – 90) Implantación académica ◦ Protocolos de intercambio de información (FTP, SMTP,...)  (90-95) World Wide Web ◦ HTTP, HTML, etc. ◦ Enorme biblioteca con material hipermedia  (95 – 00) Acceso comercial ◦ Posibilidad de negocio  Dinero!! ◦ Boom comercial  (00-) Crisis de las punto com ◦ Historias de fracasos  Lecciones aprendidas ◦ Nuevas posibilidades: Computación ubicua, Web semántica, etc.

5 wireless ISP local ISP regional Acceso particular Modem Router servidores Acceso corporativo Telefonía móvil

6  Se encarga de llevar a cabo la conmutación de paquetes ◦ Transmission Control Protocol (TCP) ◦ Internet Protocol (IP)  Protocolo = conjunto de reglas para formatear, ordenar y comprimir mensajes, comprobar errores, etc. ◦ Pueden implementarse en hardware o software

7  La familia de protocolos TCP/IP se divide en 4 capas: ◦ Capa de red: 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… ◦ Capa de Internet (IP)  Esquema de direcciones, encaminamiento de los mensajes… ◦ Capa de transporte (TCP)  Envía acuses de recibo, reagrupa el mensaje en destino, vuelve a mandar los paquetes perdidos o defectuosos…  No garantiza tiempos de transmisión ◦ Capa de aplicación: 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)…

8 Capa de Aplicación Capa de Transporte Capa de Internet Capa de red HTTPTelnetFTPSMTP TCP IP Ethernet Token Ring Frame Relay ATM …

9 Emisor Receptor 1.El protocolo TCP trocea los datos en paquetes 2. Los paquetes viajan de router a router según protocolo IP 3. El protocolo TCP ensambla los paquetes para obtener el mensaje original router

10  Cada ordenador conectado a Internet (=Host) debe tener una dirección para poder recibir los paquetes TCP ◦ 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 2 32 direcciones (algo más de cuatro mil millones)

11  Diversas protocolos de aplicación ◦ SMTP (correo electrónico) ◦ FTP (intercambio ficheros) ◦ IRC (Chat) ◦ HTTP (hipertexto) ◦ DNS (nombres dominio) ◦ …

12  DNS (sistema de nombres de domino) permite asociar nombres lógicos a direcciones IP ◦ DNS es una base de datos distribuida www.euitio.uniovi.es – 156.35.94.5 ◦ Ejemplo: www.euitio.uniovi.es – 156.35.94.5

13

14  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 = sistema de hipertexto que funciona sobre Internet como uno de sus servicios navegador servidor Web ◦ 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

15  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 Berners-Lee creó las versiones iniciales de: HTMLHTTPservidor Webnavegador HTML, HTTP, un servidor Web y un navegador Los cuatro componentes esenciales de la Web Tim Berners-Lee

16 Servidor Red Petición Respuesta Cliente

17 Internet index.html www.uniovi.es www.euitio.uniovi.es enlace El usuario teclea http://www.uniovi.es/ en su navegador http://www.uniovi.es/

18  El usuario solicita un documento tecleando su dirección en el navegador: http://www.uniovi.eshttp://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

19 ◦ 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

20

21 Tecleamos una dirección en el navegador (por ejemplo, www.euitio.uniovi.es) Éste envía una petición al servidor Web 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 HTTP

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

23  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

24 GET / HTTP/1.0 > > < 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 Respuesta Petición

25  Tipos de peticiones ◦ GET, HEAD, POST, PUT, DELETE, …  Define códigos de respuestas ◦ 200 – OK ◦ 400 – Bad Request ◦ 401 – Unauthorized ◦ 403 – Forbidden ◦ 404 – Not Found ◦...

26

27 Representación de Caracteres ASCII: 7 bits  (0 – 127) (A)merican (S)tandard (C)ode for (I)nformation (I)nterchange Extensiones de ASCII ISO-8859-1 (iso-latin-1) (8 bits) ASCII (0-127) + otros caracteres típicos de Europa occidental Familia ISO-8859-X = Otros alfabetos europeos ISO-8859-15 (iso-latin-9) Igual que iso-8859-1 + símbolo de € ¡CUIDADO!...hay muchos idiomas y muchos caracteres... ℜ € き ㄝ ㌟ ㉃ ⋐ ∀ ℵ ₤ ウ ぼ

28  ISO-10646 (31 bits) Define un repertorio universal de caracteres (UCS)  En continua revisión: ISO-10646-2:2001 contiene más de 70.000 caracteres  UNICODE = Consorcio de empresas que define restricciones sobre la implementación de ISO-10646  Varias codificaciones (UTF = Unicode Transformation Format)  - UTF-8: Los primeros 127 códigos se presentan igual (compatible con ASCII)  El resto se codifican en longitud variable  Relativamente Eficiente  - UTF-16: Usa 16bits para los caracteres más comunes, el resto con pares de 16 bits  - UTF-32: Codificación directa en 32 bits (desperdicio de espacio) NOTA: Conviene distinguir: Carácter: Entidad abstracta (Letra A) Glifo (Glyph): Representación del carácter A A A A A A Fuente (Font): Conjunto de glyphs, ejemplo: Times Roman, Arial, etc.

29

30  URI: Uniform Resource Identifier  URL: Uniform Resource Locator  Además de una identificador único, indica protocolo de acceso  http://www.euitio.uniovi.es  URN: Uniform Resource Name  Identificador único  urn:isbn:0451450523  IRI: Internationalized Resource Identifier ◦ Admite caracteres Unicode

31  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://dirección[:puerto]/directorio/fichero

32  Un protocolo define el modo en que se comunican dos ordenadores para llevar a cabo alguna tarea  Protocolo del Web: ◦ HTTP (HyperText Transfer Protocol) ◦ Especifica cómo tiene lugar el diálogo entre el navegador y el servidor para conseguir el fichero especificado TCP ◦ 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

33 filePermite acceder a un fichero en el sistema de ficheros local ftpFile Transfer Protocol httpPáginas Web

34  Suele ser un nombre simbólico: nombre de dominio ◦ www.uniovi.es especifica una máquina llamada “www” en el dominio “uniovi.es” www.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

35  También podría ser directamente la dirección IP ◦ http://156.35.14.3/ 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/ http://WWW.UNIOVI.ES/ ◦ http://wWw.UniOvi.es/ http://wWw.UniOvi.es/

36  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)

37  Depende del SO 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

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

39  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/

40

41  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)

42  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

43  ¿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

44  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

45  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 www.w3c.org

46 Pizzeria Al Capone <body bgcolor="blue" text="yellow" link="red" vlink="white"> Pizzería Al Capone Lista de enlaces Tipos de Pizzas Patrocinadores Contacto Contacto Dirección: C/ Génova Nº 3, Oviedo, España Teléfono: 985203040 AlCapone.htmlPágina visualizada Cabecera Cuerpo Lista Enlaces Detalles de presentación

47 <!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.0//EN” “http://www.w3.org/TR/REC-html40/strinct.dtd”...... DTD = Declaración de tipo de documento Muchos visualizadores asumen tipo HTML por defecto Su inclusión garantiza mayor compatibilidad y validación La cabecera incluye información sobre el documento actual (meta- información) Título, autor, palabras clave para robots de búsqueda, etc. El cuerpo incluye el contenido del documento El formato HTML se basa en la utilización de elementos Cabecera Cuerpo DTD

48 Hola... Etiqueta de inicioContenidoEtiqueta final Elemento Un elemento contiene: Una etiqueta inicial (nombre entre signos ): La etiqueta inicial puede contener atributos: El elemento debe acabar con una etiqueta final con el mismo nombre El contenido del elemento es todo lo que hay entre la etiqueta inicial y la final El contenido pueden ser otros elementos

49 En caso de un elemento vacío puede usarse la sintaxis: Elemento vacío Aunque en HTML pueden no incluirse las etiquetas finales de algunos elementos

50  En la cabecera se pueden incluir los elementos  especifica el título del documento  especifica meta-información. Dos modos: –Atributo name Podemos usar nuestros valores Pueden incluirse palabras clave que ayudan a los buscadores y descripciones –Atributo http-equiv: Solicita al servidor que incluya información en la cabecera de envío

51  Otros elementos de la cabecera  especifica relaciones entre documentos  Muchas opciones dependen del soporte ofrecido por el visualizador   Pueden especificarse hojas de estilo (se verán más adelante)  especifica estilo del documento (se verá más adelante) body { background: blue; color: yellow }

52  Niveles de encabezado (headings) ◦ h1, h2, h3, h4, h5, h6  Párrafo p ◦ Los saltos de línea son gestionados por el visualizador ◦ br inserta un salto de línea ◦ inserta un espacio pero impide un salto de línea  Elementos de frases ◦ em, strong, cite, dfn, code, samp, kbd, var, abbr, acronym, blockquote, q  Texto preformateado pre ◦ ◦ void main() { ◦ return (“Hola”); ◦ } ◦

53  Listas no ordenadas (unordered-lists)  Listas ordenadas (ordered-lists)  Items de listas (list-item)  Primer valor  Segundo valor Primer valor Segundo valor 1. Primer valor 2. Segundo valor Primer valor Segundo valor

54 Listas de definiciones (definition-list) Término de definición (definition-term) Descripción de definición (definition-description) HTML Hypertext Markup Language XML eXtensible Markup Language HTML Hypertext markup Language XML eXtensible Markup Language

55 Lista de enlaces Tipos de Pizzas Patrocinadores Contacto Lista de enlaces Tipos de pizzas Patrocinadores Contacto http://www.mafia.it Dirección absoluta pizzas.html Dirección relativa Información de contacto... Dirección interna #contacto

56 <object data=“images/fotoPizza.gif” width=“500” height=“500” type=“image/gif”> Foto de una pizza También puede usarse <img src=“images/fotoPizza.gif” width=“500” height=“500” alt=“Foto de una pizza”> Incluir dimensiones permite al visualizador reservar espacio El texto alternativo es conveniente incluirlo para visualizadores que no puedan mostrar imágenes

57  HTML 4.01 incluye características de formateo de texto ◦ b (bold, negrita) i (itálica) big (más grande) small (más pequeño) tt (teletipo) ◦ Control de fuentes  Texto rojo grande ◦ Líneas horizontales Es posible agrupar contenidos mediante span y div span se utiliza dentro de líneas de texto div se utiliza para bloques de contenido (divide unidades) Con los atributos “id” o “class” se asigna un nombre lógico Son útiles para trabajar con hojas de estilos Dirección: C/ Génova Nº 3, Oviedo, España Teléfono: 985203040

58 Pizzas disponibles Nombre Ingredientes Precio Barbacoa Mozzarella, Bacon 8 € Hawaiana Tomate, Piña, Queso 7€ 4 quesos Tomate, Mezcla 4 quesos 7 € Nombre Pizzas Disponibles IngredientesPrecio Barbacoa Hawaiana 4 Quesos Mozzarella, Bacon Tomate, Piña, Queso Tomate, Mezcla 4 quesos 8€8€ 7€7€ 7€7€

59 ... Aquí venía un applet que saludaba... import java.lang.*; import java.applet.*; import java.awt.*; public class MiApplet extends Applet { public void paint(Graphics g) { g.drawString("Hola desde Java",10,10); } MiApplet.java Compilador de java MiApplet.class El código se ejecuta en la máquina cliente (visualizador) Ventaja: Liberar al servidor de ejecutar tareas Desventaja: Seguridad? También puede usarse NOTA: Object es más general y se adaptará a otros usos en el futuro <object codetype=“application/java” classid=“MiApplet.class” width=“500” height=“500”> Aquí venía un applet que saludaba

60 <object data="dibujo.gif" width="250" height="250" type="image/gif" usemap="#mapa1"> Barra de navegación

61 Ejemplo con marcos información sin marcos Se puede asignar un nombre para hacer referencias Enlace

62 <form action="http://www.mafia.it/cgi-bin/nuevoSocio" method="get"> Nombre: Apellido email: Hombre Mujer <textarea name="Comentarios" rows="5" cols="50"> > <input type="submit" value="Envía"> <input type="reset” value="Borra" > Al pulsar “Envía” se le pasan los valores a esa url Se realiza una computación en el servidor Posibilidades: CGI, Servlets, PHP, ASP, etc

63 <!-- if (document.images) { coche1 = new Image(128,128); coche2 = new Image(128,128); coche1.src = "coche1.gif"; coche2.src = "coche2.gif"; } function cambia(name, image) { if (document.images) {document[name].src = eval(image+".src"); }} // --> <img name="coche1“ width="128" height="128“ onMouseOver=' cambia("coche1", "coche2")' onMouseOut = ‘cambia("coche1", "coche1")'> src="coche1.gif“ /> La etiqueta permite incluir guiones (scripts) Son interpretados por navegador (JavaScript, VBScript, etc.) Computación en cliente Depende de las posibilidades del visualizador Al avanzar el ratón cambia la imagen

64

65  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/ http://httpd.apache.org/ ◦ Internet Information Server (IIS)

66  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 …  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

67 Petición pagina.html 17/10/2005 17/10/2005 En el navegador se vería Respuesta 17/10/2005 pagina.html

68 Petición pagina.html 18/10/2005 18/10/2005 En el navegador se vería Respuesta <?php printf(“ %s ”, date(“d/m/Y”)); ?> pagina.php Motor PHP

69  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  Diversas tecnologías ◦ CGIs, ASP, JSP, Servlets, etc.

70 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.

71  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

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

73  Hay dos formas posibles en que el servidor Web puede pasarle los datos al programa CGI: variables de entorno ◦ Mediante las variables de entorno entrada estándar ◦ Mediante la entrada estándar ( stdin )

74  La tabla siguiente muestra alguna de las variables de entorno: ◦ (Puede verse una lista completa en http://hoohoo.ncsa.uiuc.edu/cgi/env.html) http://hoohoo.ncsa.uiuc.edu/cgi/env.html VariableDescripció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 … …

75  La forma de acceder al contenido de dichas variables desde el programa CGI varía dependiendo del lenguaje en que haya sido escrito SERVER_NAME ◦ 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'}

76  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} "; }

77

78  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

79  Algunas de las alternativas son: Session ◦ 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

80  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

81  Según la especificación, un agente de usuario (es decir, un navegador), debe permitir al menos: 300 cookies ◦ Un total de 300 cookies 4 KBpor cookie ◦ Hasta 4 KB (4.096 bytes) por cookie 20 cookies de un servidor ◦ 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

82  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 expires ◦ Aunque también se utiliza bastante el atributo expires nombre=valor; [expires=fecha; path=directorio; domain=nombreDeDominio; secure]

83  Un par nombre = valor IDUsuario = 49; ◦ Por ejemplo: IDUsuario = 49;  expires ◦ Hasta cuándo será válida la cookie Wdy, DD-Mon-YYYY HH:MM:SS GMT  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)

84  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 https ◦ Es booleano; si está definido (si aparece el atributo) deberá haber una conexión segura ( https ) para que la cookie sea enviada

85  Consiste en incluir la información del estado en el propio URL ◦ /…/comprar.asp?paso=3&producto1=01992CX&prod ucto2=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.

86  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

87  Privacidad ◦ 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

88  Implementación compleja ◦ Mantener “a mano” el estado en el cliente puede ser realmente complicado si queremos hacerlo de manera robusta  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

89

90  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 middleware ◦ Es una capa intermedia ( middleware ) que se sitúa entre el servidor Web y las aplicaciones y bases de datos subyacentes

91 Servidor de aplicaciones (Transacciones, mensajería, servicios Web…) CORBAJ2EE.NET Aplicación cliente SGBD

92  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…

93  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

94  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  …

95

96  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. El servidor ha de conservar información entre peticiones del usuario a lo largo de la duración de una sesión

97  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

98  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 Los servidores de aplicaciones proporcionan mecanismos de equilibrado de carga (aspecto clave para la escalabilidad)

99  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

100  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

101  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 Transacción: secuencia de pasos que, o se ejecutan todos, o si no el sistema queda en el estado original

102  Actualmente, las dos plataformas más comunes son JEE 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)

103 Navegador Contenedor Aplicación Cliente Aplicación Cliente Aplicación Cliente Contenedor Web Servlets Páginas JSP EJB Contenedor EJBs Servidor J2EE Base Datos Máquina Cliente