Arquitectura de Aplicaciones Web M2

Arquitectura deaplicaciones web

Xavier Vilajosana GuillnLeandro Navarro Moldes

PID_00184783

FUOC PID_00184783 Arquitectura de aplicaciones web

Ninguna parte de esta publicacin, incluido el diseo general y la cubierta, puede ser copiada,reproducida, almacenada o transmitida de ninguna forma, ni por ningn medio, sea ste elctrico,qumico, mecnico, ptico, grabacin, fotocopia, o cualquier otro, sin la previa autorizacin escritade los titulares del copyright.

FUOC PID_00184783 Arquitectura de aplicaciones web

ndice

Introduccin............................................................................................... 5

Objetivos....................................................................................................... 6

1. Caractersticas de la demanda de pginas web......................... 7

2. Organizacin de las aplicaciones en servidores web................ 172.1. El servidor web ............................................................................ 172.2. Organizacin del servidor web ................................................... 182.3. Organizacin de las aplicaciones web ........................................ 20

3. Servidores proxy-cache web............................................................. 22

4. Contenidos distribuidos................................................................... 284.1. Redes de distribucin de contenidos .......................................... 30

5. Computacin orientada a servicios.............................................. 355.1. SOA en detalle ............................................................................. 355.2. Grid computing............................................................................... 385.3. Cloud computing............................................................................ 40

Resumen....................................................................................................... 42

Bibliografa................................................................................................. 45

FUOC PID_00184783 5 Arquitectura de aplicaciones web

Introduccin

En este mdulo didctico se hablar de las maneras de organizar aplicacionesweb y de cmo hacer que puedan funcionar a pesar de estar sujetas al com-portamiento catico e imprevisible de Internet.

Primero se caracteriza la demanda de estos servicios y cmo medirla en unasituacin real. Despus se describen las formas de organizar las aplicaciones enservidores web y tambin se profundiza en su funcionamiento. Seguidamentese presentan formas distribuidas de servicio: servidores intermediarios proxy-cache, redes de distribucin de contenidos que no dejan de ser extensiones oservicios que facilitan las tareas de los servidores de aplicaciones y que permi-ten un funcionamiento ms ptimo de Internet. Finalmente se presentan lasaplicaciones orientadas a servicios y computacin bajo demanda que a da dehoy estn cambiando el funcionamiento global de Internet.


Objetivos

Las competencias que se alcanzarn fruto del trabajo de este mdulo didcticoson las siguientes:

1. Conocer las caractersticas de la demanda que tiene que satisfacer un ser-vidor web.

2. Conocer las diversas maneras de organizar una aplicacin web y los mo-delos que existen, segn varios criterios.

3. Conocer las caractersticas y el funcionamiento de cada modelo.

4. Poder elegir la mejor opcin en cada situacin y valorar las implicacionesdel montaje que hay que hacer.


1. Caractersticas de la demanda de pginas web

El trfico de web es el responsable de un buen porcentaje del trfico de Inter-net. Esta tendencia ha ido creciendo gradualmente desde que apareci la web(protocolo HTTP), y hoy da el trfico HTTP predomina respecto del resto delos protocolos, y hay una gran poblacin de usuarios navegantes que pue-den generar una cantidad inmensa de peticiones si el contenido es interesan-te. La organizacin de un servicio web conectado a Internet requiere tener encuenta las caractersticas de la demanda que pueda tener que atender.

Figura 1

Volumen de trfico en escala logartmica de flujos, paquetes y bytes intercambiados duranteveinticuatro horas en un enlace del ncleo de la red de MCI/Worlcom (1998), organizado por elprotocolo.

Figura 2

Porcentaje de trfico en bytes de cada protocolo respecto al total medido. Puede apreciarse mejor que en la figura 1,en escala logartimica, que el porcentaje de trfico web domina el resto (73% del total).

Arrecifes de coral y trficoen Internet

La organizacin CAIDA se de-dica al anlisis del trfico en In-ternet y ha desarrollado unaherramienta denominada CoralReef que toma trazas del trfi-co de un enlace. Con sta, en1998 hicieron un estudio detrfico por protocolos en el n-cleo de la red del proveedorMCI. El artculo que lo describese present en la conferenciaInet 98, y se titulaba The na-ture of the beast: recent traf-fic measurements from an In-ternet backbone. Las grficasadjuntas se han obtenido deestas medidas.

La cronologa de Internet

Un calendario de los eventosrelacionados con Internet des-de 1957 hasta hoy lo podisver en la direccin siguiente:Hobbes Internet Timeline 10.1


Por otro lado, la web (HTTP) es un servicio muy reclamado por todo tipo deorganizaciones para publicar informacin, como puede verse en la tendenciade crecimiento del nmero de servidores web en Internet, que ha sido expo-nencial, tal y como muestra la figura 3.

Figura 3

a. Crecimiento del nmero de sitios web durante los ltimos aos.b. Crecimiento del nmero de lugares web durante los ltimos aos en escala logartmica. Podemos ver la tendencia asinttica.Hobbes Internet Timeline Copyright 2010 Robert H. Zakon

La figura 4 nos muestra el crecimiento en la creacin de nuevos dominios quetambin sigue una tendencia exponencial fruto de la adopcin de la web comoprincipal media de distribucin de la informacin.

Figura 4

Crecimiento del nmero de dominios registrados en los ltimos aos.Hobbes Internet Timeline Copyright 2010 Robert H. Zakon


Para completar este anlisis de las tendencias a la Red, las figuras 5.a y 5.b nosmuestran por un lado el incremento exponencial del nmero de huspedesque acceden a la Red y por otra, el auge de las redes sociales como Facebookcon un incremento muy elevado del nmero de usuarios en muy poco tiempo.

Figura 5

a. Crecimiento del nmero de huspedes que acceden a la Red en los ltimos aos.b. Crecimiento del nmero de usuarios de la red social Facebook.


La popularidad de los servidores web tambin es muy variable. Un mismositio web puede recibir muy pocas visitas durante mucho tiempo y, de repente,recibir ms peticiones de las que puede servir: es un trfico a rfagas.

Figura 6

Evolucin del trfico entrante y saliente de un sitio web tpico durante una semana. Podis observar la gran variacin horaria yla reduccin de trfico durante el fin de semana.

Un servidor puede recibir aludes repentinos de trfico. Por ejemplo, por lasestadsticas del siguiente servidor web sabemos que, despus de que se anun-ciara en la pgina de noticias salshdot.org, experiment un exceso de visitastan elevado que el servidor se bloque.

Figura 7

Peticiones web por hora, servidas por http://linuxcounter.net durante tres das. Puede verse que mientras que el nmerohabitual de operaciones (peticiones web) estaba por debajo de 500, subi rpidamente a unas 2.500, lo cual provoc el fallodel sistema. Despus de reconfigurarlo, estuvo soportando durante unas doce horas en torno a 3.000 peticiones/hora parabajar posteriormente a valores normales. La historia completa est en la pgina The Linux Counter Slashdot Experience

Un servidor web puede tener miles de documentos y, sin embargo, recibir lamayora de las peticiones por un nico documento. En muchos casos, la po-pularidad relativa entre distintos sitios web o entre diferentes pginas de uncierto sitio se rige por la ley de Zipf (George Kingsley Zipf, 1902-1950).

Flash crowd

Un cuento de ciencia ficcinde varias Larry Niven (1973)predijo que una consecuenciade un mecanismo de teletrans-porte barato sera que gran-des multitudes se materializa-ran instantneamente en loslugares con noticias interesan-tes. Treinta aos despus, eltrmino se usa en Internet pa-ra describir los picos de trficoweb cuando un determinadositio se hace popular de repen-te y se visita de manera masi-va. Tambin se conoce comoefecto slashdot o efecto /.,que se da cuando un sitio webresulta inaccesible a causa delas numerosas visitas que reci-be cuando aparece en un ar-tculo del sitio web de noticiasslashdot.org (en castellano,barrapunto.com


Ley de Zipf

La frecuencia de ocurrencia de un evento concreto (P) como funcindel rango (i) cuando el rango ests determinado por la frecuencia de

ocurrencia es una funcin potencial Pi ~ 1/ia, con el exponente a cercanoa la unidad.

El ejemplo ms famoso es la frecuencia de palabras en ingls. En 423 artculosde la revista Time (245.412 palabras), the es la que ms aparece (15.861), of esten segundo lugar (7.239 veces), to en tercer lugar (6.331 veces), y con el restoforman una ley potencial con un exponente cercano a 1.

Una distribucin de popularidad Zipf forma una lnea recta cuando se dibujaen una grfica con dos ejes en escala logartmica, que resulta ms fcil de ver ycomparar que la grfica en escala lineal, tal y como puede verse en la figura 8.

Figura 8

Una distribucin de popularidad (casos ordenados por popularidad en el eje x, valor de popularidad en el eje y) que siguela ley de Zipf a escala lineal queda pegada a los ejes: muy pocos casos tienen mucha popularidad y muchos casos tienenmuy poca. Por este motivo, se suele representar en escalas logartmicas (grfica doble logartmica: los dos ejes en escalalogartmica).

Muchos estudios muestran que las visitas de pginas web siguen una distribu-cin de Zipf. La figura 9 muestra las visitas en www.sun.com durante un mesde 1996. La pgina principal recibi prcticamente 1 milln de visitas, mien-tras que la pgina de la posicin 10.000 de popularidad slo recibi una visitaaquel mes. La grfica de visitas sigue la curva de Zipf excepto para los valoresmenos populares, lo cual seguramente se debe al hecho de que el periodo deobservacin no fue lo bastante largo.


Figura 9

Nmero de visitas de las pginas de www.sun.com ordenadas por popularidad. Puede verse cmo se ajusta a unadistribucin de Zipf.

Como resumen, diferentes estudios del trfico web contribuyen a definir unperfil tpico o reglas a ojo de la web segn M. Rabinovich y O. Spatscheck(2002):

El tamao medio de un objeto es de 10-15 kbytes, y la media de 2-4 kbytes.La distribucin se decanta claramente hacia objetos pequeos, aunque seencuentra una cantidad nada despreciable de objetos grandes (del ordende Mbytes).

La mayora de los accesos a la web son por objetos grficos, seguidos delos documentos HTML. El 1-10% son por objetos dinmicos.

Una pgina HTML incluye de media diez imgenes y mltiples enlaces aotras pginas.

Un 40% de todos los accesos son para objetos que se considera que no sepueden inspeccionar.

La popularidad de objetos web es muy diferente: una pequea fraccin deobjetos es la responsable de la mayora de los accesos, siguiendo la ley deZipf.

El ritmo de acceso para objetos estticos es muy superior al ritmo de mo-dificacin.


En una escala de tiempo inferior al minuto el trfico web es a rfagas, porlo cual valores medidos con medias durante algunas decenas de segundoson muy poco fiables.

Un 5-10% de accesos a la web se cancelan antes de finalizar.

Prcticamente todos los servidores utilizan el puerto 80.

Cada sitio web es un poco distinto, y puesto que un servidor web es un sistemacomplejo y, por lo tanto, difcil de modelar, resulta conveniente hacer experi-mentos tanto para ver cmo los niveles de carga (peticiones de pginas web)crecientes afectan a nuestro servidor, como para observar peridicamente elcomportamiento de un servidor web analizando los diarios (logs) que puedegenerar.

Para probar el rendimiento de un servidor web, normalmente se utiliza algnprograma que, instalado en otro computador, genere un ritmo de peticionesequivalentes para medir el efecto de las visitas simultneas desde distintosclientes. El ritmo de peticiones puede configurarse de una manera ligeramentedistinta para cada herramienta, pero el objetivo es ser estadsticamente equi-valente a la demanda real que el servidor pueda experimentar durante su fun-cionamiento normal. Esto recibe el nombre de carga sinttica.

Hay muchas herramientas. A continuacin se describen brevemente tres he-rramientas populares y gratuitas:

Microsoft Web Application Stress (WAS) es una herramienta de simulacinpara Windows diseada para medir el rendimiento de un sitio web. Tieneen cuenta las pginas generadas dinmicamente (ASP) en un servidor webde Microsoft.

Apache JMeter, una aplicacin Java para medir el rendimiento de documen-tos y recursos estticos y dinmicos (archivos, servlets, scripts Perl, objetosJava, consultas de bases de datos, servidores FTP, etc.), que simula distintostipos de carga extrema de la Red, del servidor o de un objeto concreto.

Surge de la Universidad de Boston: una aplicacin Java que genera peticio-nes web con caractersticas estadsticas que simulan con mucha precisinla demanda tpica de un servidor web.

Durante el funcionamiento normal del servidor, es conveniente supervisar lademanda y el rendimiento del servicio para detectar su degradacin (respon-de muy lentamente por exceso de peticiones o trfico) o situaciones crticas(sobrecarga: no responde).

Enlaces de inters

Visitas web sobre generadoresde carga:Apache JmeterSurge


Figura 10

Una de las muchas grficas que genera una herramienta de estadsticas web popular y gratuita denominada webalizer, que facilita mucho el anlisis de la actividad de un servidorweb.

Las herramientas de visualizacin y anlisis de actividad del servidor se basanen el hecho de que prcticamente todos los servidores son capaces de generar

archivos histricos de la actividad del servidor (conocidos como diarios1) enun formato conocido como common log format o CLF.

En CLF cada lnea (a veces denominada entrada) registra una peticin recibidapor el servidor. La lnea est formada por distintos elementos separados porespacio:

mquina ident usuario_autorizado fecha peticin estado bytes

Si un dato no tiene valor, se representa por un guin (-). El significado de cadaelemento es el siguiente.

Mquina: el nombre DNS completo o su direccin IP si el nombre no estdisponible.

Ident: si est activado, la identidad del cliente tal y como lo indica el pro-tocolo identd. Puede no ser fiable.

UsuarioAutorizado: si se pidi un documento protegido por contrasea,corresponde al nombre del usuario utilizado en la peticin.

Fecha: la fecha y hora de la peticin en el formato siguiente:da = 2*digit

mes = 3*letter

ao = 4*digit

(1)En ingls, logs.


hora = 2*digit

minuto = 2*digit

segundo = 2*digit

zona = ('+' | '-') 4*digit

Peticin: el URL solicitado por el cliente, delimitado por comillas (").

Estado: el cdigo de resultado de tres dgitos devuelto al cliente.

Bytes: el nmero de bytes del objeto servido, sin incluir cabeceras.

Este formato es adecuado para registrar la historia de las peticiones, pero nocontiene informacin til para medir el rendimiento del servidor. Por ejemplo,no indica el tiempo transcurrido en servir cada URL.

Para permitir construir un formato de entrada de diario (log) que contengala informacin necesaria, puede definirse un formato particular que puedecontener otra informacin. A continuacin se muestra una lista de las variablesque el servidor web Apache puede guardar (mod_log).

Nombre Descripcin de la variable

%a Direccin IP remota.

%A Direccin IP local.

%B Bytes enviados, excluyendo las cabeceras HTTP.

%b Bytes enviados, excluyendo las cabeceras HTTP. En formato CLF: un '-' enlugar de un 0 cuando no se ha enviado ningn byte.

%c Estado de la conexin cuando la respuesta se acaba:'X' = conexin abortada antes de acabar la respuesta.'+' = conexin que puede quedar activa despus de haber enviado la res-puesta.'-' = conexin que se cerrar despus de haber enviado la respuesta.

%{NOMBRE}e El contenido de la variable de entorno NOMBRE.

%f Nombre del fichero.

%h Nombre de la mquina remota.

%H El protocolo de la peticin.

%{Nombre}i El contenido del encabezado o encabezados Nombre: de la peticin en-viada al servidor.

%l Usuario remoto (de identd, si lo proporciona).

%m El mtodo de la peticin.

%{Nombre}n El contenido de la nota Nombre desde otro mdulo.

%{Nombre}o El contenido de la cabecera o cabeceras Nombre: de la respuesta.

%p El puerto del servidor sirviendo la peticin.


Nombre Descripcin de la variable

%P El identificador del proceso hijo que sirvi la peticin.

%q El texto de una consulta o query string (precedido de ? si la consulta existe,si no, un texto vaco).

%r Primera lnea de la peticin.

%s Estado de peticiones que fueron redireccionadas internamente, el estadode la peticin original - %>s para el de la ltima.

%t Tiempo (fecha) en formato de LOG (formato estndar ingls).

%{formato}t El tiempo (hora), en el formato especificado, que debe expresarse en for-mato strftime (posiblemente localizado).

%T El tiempo de servicio de la peticin, en segundos.

%u Usuario remoto (de autentificacin; puede ser incorrecto si el estado de larespuesta %s es 401).

%U La parte de camino (path) del URL, sin incluir el texto de la consulta (querystring).

%v El nombre original o cannico del servidor dependiente de la peticin.

%V El nombre del servidor segn el valor del orden UseCanonicalName.

Segn estas variables, el formato CLF sera:

"%h %l %u %t \"%r\" %>s %b"

El formato CLF incluyendo el servidor web virtual solicitado (un servidor webpuede servir a diferentes dominios DNS o servidores virtuales):

"%v %h %l %u %t \"%r\" %>s %b"

El formato NCSA extendido/combinado sera:

"%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\""

Analizar la demanda y rendimiento de un servidor es una tarea necesaria, yaque los servidores web estn sujetos a variaciones de demanda muy extrema.Despus del anlisis de los ficheros de diario del servidor, puede ser necesariolimitar, resituar y ampliar los recursos del servidor y la red de acceso a Internetpara poder atender aceptablemente el extrao y voluble trfico de peticionesque visita los servidores web.


2. Organizacin de las aplicaciones en servidores web

En este apartado veremos cmo se organizan las aplicaciones en un servidorweb y detallaremos aspectos relevantes del funcionamiento de una aplicacinweb.

2.1. El servidor web

Un servidor web que se ejecuta en un ordenador se mantiene a la espera depeticiones por parte de un cliente (un navegador web o un programa que haceuna llamada a un servicio web). Cuando el servidor recibe una peticin, res-ponde adecuadamente mediante una pgina web que se exhibir en el nave-gador, o bien mostrar el mensaje de error correspondiente.

A guisa de ejemplo, al escribir www.uoc.edu en nuestro navegador, este realizauna peticin HTTP al servidor de la mencionada direccin (una vez resueltoel nombre mediante la DNS). El servidor responder al cliente enviando elcdigo HTML de la pgina, y el cliente una vez haya recibido el cdigo lointerpretar y lo presentar por pantalla. Como vemos con este ejemplo, elcliente es el encargado de interpretar el cdigo HTML, es decir, de mostrar lasfuentes, los colores y la disposicin de los textos y los objetos de la pgina.El servidor slo se limita a transferir el cdigo de la pgina sin llevar a caboninguna interpretacin.

Adems de la transferencia de cdigo HTML, los servidores web pueden ejecu-tar aplicaciones web. Estas estn formadas por cdigo que se ejecuta cuandose realiza alguna peticin o respuesta HTTP.

Hay que distinguir entre:

a)Aplicacionesenelladodelcliente: el cliente web es el encargado de eje-cutarlas en la mquina del usuario. Son las aplicaciones de tipo Java applets oJavascript. El servidor proporciona el cdigo de las aplicaciones al cliente y es-te, mediante el navegador, las ejecuta. Es necesario, por lo tanto, que el clientedisponga de un navegador con capacidad de ejecutar aplicaciones (tambinllamadas scripts). Normalmente, los navegadores permiten ejecutar aplicacio-nes escritas en lenguaje Javascript y Java, aunque pueden aadirse ms len-guajes mediante el uso de plugins.

b)Aplicacionesenelladodelservidor: el servidor web ejecuta la aplicaciny esta, una vez ejecutada, genera cierto cdigo HTML y lo devuelve al servidor.Seguidamente, el servidor enva este cdigo al cliente por medio del protocoloHTTP.


Una ventaja de desarrollar aplicaciones web del lado del servidor es que, alejecutarse en el servidor y no en la la mquina del cliente, no hacen necesarianinguna capacidad aadida al navegador cliente, como s que sucede en elcaso de la ejecucin de aplicaciones de Javascript o Java. As pues, cualquiercliente dotado de un navegador web bsico puede utilizar este tipo de aplica-ciones. En contrapartida, la carga del servidor aumenta, y el rendimiento seve afectado. La llamada Web 2.0 ha cambiado la tendencia en el desarrollode aplicaciones, que hace unos aos se basaban casi completamente en la eje-cucin en el lado del servidor. Ms recientemente, las tecnologas AJAX hantrado la computacin a los navegadores de los clientes, distribuyendo as lacarga que reciban los servidores web entre sus clientes y por lo tanto, consi-guiendo un Internet ms escalable y con aplicaciones ms potentes.

Las aplicaciones web aplicaciones que van asociadas o son extensiones de unservidor web pueden necesitar un diseo y ajuste muy cuidadosos para ofre-cer un rendimiento adecuado en situaciones de alta demanda, o simplementepara responder rpidamente o aprovechar de manera adecuada los recursos dela mquina en la que estn instalados.

En primer lugar, hay que saber cmo est organizado un servidor web paraatender peticiones HTTP de la manera ms eficiente. En segundo lugar, se debeconocer cmo puede extenderse el servidor web para ofrecer otros serviciosgestionados por un cdigo adicional.

2.2. Organizacin del servidor web

Para caracterizar cmo se organiza un servidor web para atender peticiones deuna manera eficiente y econmica, es necesario definir algunos trminos:

Proceso: la unidad ms pesada de la planificacin de tareas que ofreceel sistema operativo. No comparte espacios de direcciones ni recursos re-lacionados con ficheros, excepto de manera explcita (heredando referen-cias a ficheros o segmentos de memoria compartida), y el cambio de tarealo fuerza el ncleo del sistema operativo (preemptivo).

Flujo o thread: la unidad ms ligera de planificacin de tareas que ofreceel sistema operativo. Como mnimo, hay un flujo por proceso. Si distintosflujos coexisten en un proceso, todos comparten la misma memoria y re-cursos de archivos. El cambio de tarea en los flujos lo fuerza el ncleo delsistema operativo (preemptivo).

Fibra: flujos gestionados por el usuario de manera cooperativa (no preem-ptivo), con cambios de contexto en operaciones de entrada/salida u otrospuntos explcitos: al llamar a ciertas funciones. La acostumbran a imple-mentar libreras fuera del ncleo, y la ofrecen distintos sistemas operati-vos. Para ver qu modelos de proceso interesan en cada situacin, hay queconsiderar las combinaciones del nmero de procesos, flujo por proceso y


fibras por flujo. En todo caso, cada peticin la sirve un flujo que resulta launidad de ejecucin en el servidor.

Para ver qu modelos de proceso interesan en cada situacin, hay que consi-derar las combinaciones del nmero de procesos, flujo por proceso y fibraspor flujo. En todo caso, cada peticin la sirve un flujo que resulta la unidadde ejecucin en el servidor.

Los modelos que se pueden construir son (U: nico, M: mltiple):

Proceso Flujo Fibra Descripcin

U U U Es el caso de los procesos gestionados por inetd. Cada peticin genera un proceso hijo quesirve la peticin.

M U U El modelo del servidor Apache 1.3 para Unix: distintos procesos preparados que se van encar-gando de las peticiones que llegan.Lo implementa el mdulo Apache: mpm_prefork.

M U M En cada proceso, una librera de fibras cambia de contexto teniendo en cuenta la finalizacinde operaciones de entrada/salida. En Unix se denomina select-event threading y lo usan losservidores Zeus y Squid. Ofrece un rendimiento mejor en Unix que en MUU.Lo implementa el mdulo Apache state-threaded multi processing.

M M U El modelo MMU cambia fibras por flujos.Lo implementan los mdulos Apache: perchild y mpm_worker_module. El nmero de peticio-nes simultneas que puede atender es ThreadsPerChild x MaxClients.

U M U El modelo ms sencillo con diferentes flujos. Se puede montar en Win32, OS2, y con flujosPOSIX.Lo implementa el mdulo Apache: mpm_netware.

U M M Probablemente el que proporciona un rendimiento ms alto. En Win32 se puede conseguircon los denominados completion ports. Se usan los flujos necesarios para aprovechar el para-lelismo del hardware (nmero de procesadores, tarjetas de red), y cada flujo ejecuta las fibrasque han completado su operacin de entrada/salida.Es el modelo con un rendimiento ms alto en Windows NT.Lo implementa el mdulo Apache: mpm_winnt_module.Muchos servidores como Internet Information Server o IIS 5.0 utilizan este modelo con Win-dows NT. El servidor web interno al ncleo de Linux Tux tambin utiliza este modelo.

M M M Puede ser una generalizacin de UMM o MUM, y en general la presencia de distintos proce-sos hace que el servidor se pueda proteger de fallos como consecuencia de que un procesotenga que morir por fallos internos, como por ejemplo el acceso a memoria fuera del espaciodel proceso.

En general, los modelos con muchos procesos son costosos de memoria (cadaproceso ocupa su parte) y de carga (creacin de procesos). En servidores dealto rendimiento, los modelos con flujos parecen mejores, aunque tienen elproblema de la portabilidad difcil y la posible necesidad de mecanismos queanticipan el coste de creacin de procesos o flujos y, por lo tanto, son muyrpidos atendiendo peticiones.

TUX: servidor web en el ncleo de Linux

Tux es un servidor web incorporado al ncleo de Linux que usa un pool con muy pocosflujos del ncleo (un flujo por procesador), lee directamente de la memoria del sistemade ficheros de dentro del ncleo, usa su propio algoritmo de planificacin de fibras yusa el TCP/IP zero-copy que minimiza las veces que los datos que vienen de la Red secopian en la memoria (en redes de alta velocidad como Gigabit Ethernet, las copias de

Lectura complementaria

El apartado 4.4 Server Ar-chitecture del libro Krish-namurthy, Web Protocols andPractice (pgs. 99-116), descri-be un estudio sobre el funcio-namiento de Apache 1.3.


bloques de memoria son el factor limitante). Puede servir entre dos y cuatro veces mspeticiones/ segundo que Apache o IIS.

Para ms informacin: http://docs.huihoo.com/tux

Cuando la Red limita el servicio web, lanzar procesos para atender peticionespuede funcionar razonablemente bien, pero en redes de alta velocidad, comoATM o Gigabit Ethernet, la latencia en iniciar un proceso al recibir una peti-cin es excesivo.

En mquinas uniprocesador, los modelos con un solo flujo funcionan bien. Enmquinas multiprocesador, es necesario usar mltiples flujos o procesos paraaprovechar el paralelismo del hardware.

El mayor obstculo para el rendimiento es el sistema de ficheros del servidor,ya que la funcin principal del servidor web es trasladar ficheros del disco ala Red. Si ste se ajusta, el siguiente obstculo es la gestin de la concurrencia.

Adems, los estudios de trfico web indican que la mayora de las peticionesson de ficheros pequeos, por lo cual sera conveniente optimizar el servidorpara poder priorizar estas peticiones que son ms frecuentes y mejoran el tiem-po de respuesta percibido por los usuarios, por ejemplo al cargar pginas webcon muchos grficos pequeos insertados.

Por esta razn, Apache es un servidor web modular, en el cual la gestin delproceso est concentrada en un mdulo que puede seleccionarse en la insta-lacin, segn las caractersticas del sistema operativo, la mquina, los recursosque tendr que utilizar el servidor, etc.

2.3. Organizacin de las aplicaciones web

Los servidores web se encargan de atender y servir peticiones HTTP de recursos,que en su forma ms simple acostumbran a ser documentos guardados en elsistema de ficheros. Sin embargo, la otra funcin importante de un servidorweb es la de actuar de mediador entre un cliente y un programa que procesadatos. Recibe una peticin con algn argumento, la procesa y devuelve unresultado que el servidor web entrega al cliente. La interaccin entre el servidorweb y los procesos que tiene asociados es otro aspecto que hay que considerar.

Existen distintas maneras de organizar una aplicacin web. A continuacin,por orden cronolgico de complejidad y rendimiento creciente, se presentandistintos modelos de organizacin.

CGI: es el modelo ms antiguo y simple. Para cada peticin HTTP se invocaun programa que recibe datos por las variables del entorno y/o de entra-da estndar, y devuelve un resultado por la salida estndar. Consumir unproceso por cada peticin genera problemas importantes de rendimiento,que el modelo FastCGI intenta mejorar.


Servlets: es un modelo diseado para Java, ms eficiente y estructurado,que permite elegir distintos modelos de gestin de flujos o threads, dura-cin de procesos del servidor, etc. Partiendo de este modelo, se han cons-truido servidores de aplicaciones con mltiples funciones adicionales quefacilitan el desarrollo de aplicaciones web complejas.

Lenguajes de script: existen tambin lenguajes, como por ejemplo PHP,que permiten incluir trozos de cdigo (scripts) en el cdigo HTML y que alllegar al servidor son ejecutados como si fueran un CGI, devolviendo asla respuesta al cliente. Las Java Server Pages (JSP) son scripts en cdigo Javaque al llegar al servidor son ejecutadas como si fueran servlets.


3. Servidores proxy-cache web

Para la web, se dise un protocolo simple (HTTP) de acceso a documentossobre un transporte fiable como TCP. Un objetivo de diseo era la interactivi-dad: el cliente se conecta con el servidor web, solicita el documento (peticin)e inmediatamente lo recibe del servidor. Este esquema es rpido en situacionesde trfico en la Red y carga de los servidores reducida, pero no es eficiente ensituaciones de congestin.

Para todas aquellas situaciones en las cuales la comunicacin directa cliente-servidor no es conveniente, se ha introducido un tipo de servidores que hacende intermediarios entre los extremos.

Un servidor intermediario (proxy) es un servidor que acepta peticiones(HTTP) de clientes u otros intermediarios y genera a su vez peticioneshacia otros intermediarios o hacia el servidor web destino. Acta comoservidor del cliente y como cliente del servidor.

Ejemplo de servidor intermediario

La idea del proxy se usa en muchos protocolos adems del HTTP. En general, se sitan enuna discontinuidad para realizar en la misma una funcin. Por ejemplo: Cambio de red.Una mquina conectada a la red interna de una organizacin que usa direcciones IPv4privadas (por ejemplo, 10.*.*.*), y tambin en Internet, puede hacer de intermediario paratraduccin de direcciones IP entre las dos redes (NAT).

Figura 11

Interaccin entre cliente-servidor intermediario-servidor tal y como aparece en la publicacin original (Luotonen, 94)describiendo el servidor intermediario HTTP del CERN (Centro Europeo de Investigacin en Fsica), en el que fue inventada laweb.

NAT (networkaddresstranslation)

En los paquetes IP salientes:sustituir la direccin IP de m-quinas internas (no vlidas enInternet) por la suya propia,en los paquetes IP entrantes:sustituir su propia direccin IPpor la de una mquina internay reenviar el paquete hacia lared interna. Para poder sabera quin entregarlo, el interme-diario debe asociar cada unode sus puertos a mquinas in-ternas, pues una direccin detransporte es una pareja (direc-cin IP, puerto).


Si no se desea usar este mecanismo, que tiene ciertas limitaciones, se puedesalvar la discontinuidad al nivel del HTTP poniendo un intermediario HTTP:una mquina conectada a las dos redes que recibira peticiones de pginas webdesde cualquier cliente interno por una direccin interna y volvera a generarla misma peticin desde el intermediario, pero hacia Internet, con la direccinexterna.

Un servidor intermediario (proxy) es un servidor que acepta peticiones (HTTP)de clientes u otros intermediarios y genera a su vez peticiones hacia otros in-termediarios o hacia el servidor web destino. Acta como servidor del clientey como cliente del servidor.

Como podis suponer, aprovechando que tanto la peticin como el resultado(la pgina web) pasarn por el intermediario, se puede aprovechar para ofreceralgunas funciones:

a)Controldeaccesoacontenidos. El intermediario consulta si la pginasolicitada est o no permitida por la poltica de la organizacin. Puede hacerseconsultando una tabla de permisos o usando el mecanismo denominado PICS.

b)Controlde seguridad. El intermediario genera todas las peticiones quesalen a Internet, lo que oculta informacin y evita ataques directos sobre lasmquinas internas de la organizacin. Adems, puede existir un cortafuegoque no permita acceder directamente hacia el exterior, con lo que el uso delintermediario es imprescindible.

c)Aprovecharpeticionesreiteradas(funcincach). El intermediario puedealmacenar (en memoria o disco) una copia de los objetos que llegan comoresultado de peticiones que han pasado por el intermediario. Estos objetos sepueden usar para ahorrar peticiones hacia Internet y servir peticiones sucesivasde un mismo objeto con una copia almacenada en el intermediario, sin tenerque salir a buscarlo a Internet. Los proxy-cache son el caso ms frecuente deservidor intermediario, y son los que detallaremos aqu.

d)Adaptarelcontenido. Un intermediario podra tambin adaptar los ob-jetos que vienen del servidor a las caractersticas de su cliente. Por ejemplo,convertir los grficos al formato que el cliente entiende, o reducir su tamaopara clientes, como telfonos mviles con reducida capacidad de proceso, co-municacin o presentacin.

El intermediario puede ser transparente, invisible para cliente y servidor: seobtiene el mismo resultado con el mismo o sin el mismo, aunque en los nave-gadores web habitualmente el usuario debe configurar expresamente su nave-gador para usarlo, pues el navegador no tiene un mecanismo para detectarloy usarlo automticamente.

PICS: Platform forInternet Content Selection

Figura12

PICS define mecanismos pa-ra que se puedan catalogar si-tios y pginas web segn cier-tos criterios y, de esta manera,controlar el acceso a conteni-dos no deseados. Es til en es-cuelas y hogares para controlarel acceso a Internet de los me-nores. Control de contenidos:ciertos contenidos que se con-sideren no apropiados por laorganizacin pueden ser blo-queados o redirigidos. Podisencontrar ms informacin enla pgina web de Platform forInternet Content Selection (PI-CS).


En algunas instalaciones, se puede instalar un proxy transparente que son rou-ters extensiones del software del que hacen que ste intercepte las conexionesTCP salientes hacia el puerto 80 (HTTP) y las redirija a un proxy-cache. Tiene elpeligro de que el usuario no es consciente de esto, y puede llevar a situacionesequvocas si el proxy-cache falla o trata mal la peticin.

En la figura 13 podemos ver cmo hay servidores intermediarios para distintosprotocolos adems de HTTP, y que un proxy puede comunicarse con el servi-dor origen (el que tiene el documento original que el usuario ha solicitado) opedirlo a otro proxy, formando una jerarqua de proxies.

Figura 13

Un servidor intermediario se suele situar con proximidad a un cliente y puede colaborar con otrosservidores intermediarios, pero tambin puede estar cerca de un servidor (servidor intermediarioinverso).

Se usan tambin proxies en la proximidad de un servidor para reducir la cargade peticiones sobre el mismo. Son los proxies inversos: puede ser ms senci-llo y barato colocar uno o varios proxy-cache que reciban todas las peticiones:respondern directamente a las peticiones ya cacheadas y al servidor slo lellegarn unas pocas que no estn an en el proxy-cache, o han expirado o soncontenidos dinmicos.

a) Peticin HTTP 1.0 cliente servidor intermediario:

GET http://www.ac.upc.es/docencia/ HTTP/1.0

User-agent: Mozilla/4.0

Accept: text/html, image/jpeg

b) Peticin HTTP 1.0 servidor intermediario ; servidor. Podemos observarcmo el servidor intermediario introduce un campo reenviado (forwarded)para notificar su presencia al servidor:

GET /docencia/ HTTP/1.0

User-agent: Mozilla/4.0

Accept: text/html, image/gif, image/jpeg

Forwarded: by http://proxy.ac.upc.es:8080

Reflexi

El protocolo HTTP 1/1 tienedefinido un cdigo de res-puesta a una peticin: 305 Useproxy. El problema es que nose lleg a un acuerdo al escri-bir la especificacin, y la res-puesta hace que simplemen-te en el navegador aparezcael mismo mensaje de error, enlugar de tratar de buscar unproxy y reintentar la conexinmediante el mismo. Cmoarreglarlo?


Debido a la gran difusin del uso de servidores proxy-cache, sobre todo en en-tornos acadmicos, la especificacin HTTP/1.1 define una nueva cabecera quepermite controlar el comportamiento de un servidor proxy-cache tanto desdeel cliente en la peticin como desde el servidor en una respuesta.

Cache-control (peticin)

No-cache Cliente origen (las memorias cach se inhiben).

No-store El proxy no debe almacenar permanentemente peticin/respues-ta.

Max-age = sgs La mxima "edad" aceptable de los objetos en la cach.

Max-stale Se aceptan objetos viejos.

Max-stale = sgs Se aceptan objetos sgs segundos viejos.

Min-fresh = sgs Al objeto deben quedarle sgs de vida.

Only-If-Cached Peticin si slo est en el servidor proxy-cache.

Cache-control (respuesta)

Public Se puede cachear por proxies y cliente.

Private Slo se puede guardar en la memoria cach del cliente.

Private="cabc" Todos pueden mediar el objeto, excepto la cabecera cabc: sloen la memoria cach del cliente.

No-cache No se puede mediar ni en servidores intermediarios ni en el clien-te.

No-cache="cabc" Combinacin de los dos anteriores.

No-store Nadie puede almacenar permanentemente (slo en la memoriadel navegador).

No-transform Los servidores intermediarios no pueden transformar el conteni-do.

Must-revalidate Revalidar (con origen) si es necesario.

Max-age Margen de edad en segundos.

Los servidores proxy-cache tienen algoritmos para decidir si, cuando llega unapeticin de un contenido que ya tienen, es o no necesario confirmar que nohaya cambiado en el servidor origen, y el campo cach-control permite influiren la decisin. Otro problema grave es la prdida de privacidad potencial sise guardan contenidos en el proxy-cache, ms cuando se almacenan objetos endisco. Para esto tambin sirve el campo cache-control.


Un proxy-cache est formado por un almacn de mensajes de respuesta(objetos), un algoritmo de control del almacn (entrar, salir, borrar oreemplazar) y un algoritmo rpido de consulta (lookup) de un mapa delcontenido; toma la decisin de servirlo del almacn o pedirlo al servidororigen o a otro proxy-cache.

Cookies (galletas): estado y privacidad

El protocolo HTTP no tiene estado: cada interaccin (peticin + respuesta) no tiene rela-cin con las dems y cada una puede usar una conexin TCP distinta. Para poder relacio-nar varias interacciones HTTP y pasar informacin de estado entre las mismas, Netscapeinvent las cookies: un servidor web puede enviar al cliente un objeto de hasta 4096 bytes,que contiene datos que el navegador devolver a ese mismo servidor en el futuro (o aotros servidores que indique la cookie). Las cookies han sido muy usadas para cuestionespublicitarias (qu sitios web visita la gente y en qu orden), para guardar contraseas,identificar usuarios, etc. sin que el usuario sea consciente ni de que est recibiendo estasgalletas, ni de que las est enviando cuando visita la web. Hay quien dice que son unerror llevado a la perfeccin. Qu opinis? Habis mirado alguna vez qu cookies tenisen vuestro navegador?

Su uso puede producir una reduccin de trfico en la Red y en el tiempo deespera si los objetos que se piden estn en la memoria y el contenido se puedemediar. Estudios en distintas organizaciones muestran con frecuencia tasas deacierto en la memoria del 15-60% de objetos, aunque esto pueda variar muchocon los usuarios y el contenido.

El GET condicional

Hemos visto que el caching puede reducir el tiempo de respuesta percibido por el usuario,pero la copia que tenga la cach puede ser obsoleta. Es decir, el objeto hospedado en elservidor web puede haberse modificado de manera posterior a que al cliente lo copiaraen su cach. Para solucionarlo, el protocolo HTTP incluye un mecanismo que permite ala cach verificar que su copia del objeto est actualizada.

GET /elMeuDirectori/pagina.html HTTP/1.1Host: www.servidor.eduIf-modified-since: Wed, 18 Feb 2009 21:11:55 GMT

La cabecera If-modified-since: contiene el valor de la cabecera Last-Modified: de cuando elservidor envi el objeto. Esta peticin GET, que se denomina GET condicional, indica alservidor que enve el objeto slo si el objeto se ha modificado desde la fecha especificada.

En el caso de que el objeto no se haya modificado desde la fecha indicada, el servidorweb contesta un mensaje a la cach como el siguiente:

HTTP/1.1 304 Not ModifiedDate: Tue, 24 Mar 2009 18:23:40 GMT(sense cos)

304 Not Modified en la lnea de estado del mensaje de respuesta indica a la cach quepuede pasar su copia del objeto al navegador que ha hecho la solicitud. Hay que destacarque el mensaje de respuesta del servidor no incluye el objeto, ya que esto slo haramalgastar ancho de banda y la percepcin del usuario sobre el tiempo de respuesta.

Los servidores proxy-cache son sistemas pasivos que aprovechan para guardarlas respuestas a peticiones de usuarios. Automticamente no intentan guardarcontenidos que parecen privados, dinmicos o de pago: los detectan por lapresencia de campos en la cabecera como por ejemplo: WWW-Authenticate,Cache-Control:private, Pragma:no-cache, Cache-control:no-cache, Set-Cookie.


Se han propuesto mejoras para hacer de los servidores proxy-cache intermedia-rios activos: acumular documentos de inters en horas de bajo trfico paratener el contenido preparado y de esta manera ayudar a reducir el trfico enhoras de alta demanda, o mecanismos de pre-fetch en los que la memoria cachse adelanta a mostrar, antes de que se lo pidan, pginas web que con gran pro-babilidad el usuario va a solicitar a continuacin. Sin embargo, no son de usocomn pues no siempre suponen un ahorro o mejora del tiempo de respuesta,sino que pueden llevar a malgastar recursos de comunicacin.

Los mecanismos de proxy-cache son tiles para que una comunidad de usua-rios que comparten una conexin a Internet pueda ahorrar ancho de banda,y reducir transferencias repetitivas de objetos. Sin embargo, sta es slo unaparte del problema.

El problema en conjunto se conoce humorsticamente como el World-WideWait. Varios agentes participan en el rendimiento de una transferencia web:

a)Proveedordecontenidos (servidor web): debe planificar su capacidad parapoder dar servicio en horas punta y aguantar posibles avalanchas de peticionesy, de esta manera, tener cierta garanta de que sus clientes dispondrn de buenservicio con cierta independencia de la demanda.

b)Cliente: podra usar un servidor proxy-cache para economizar recursos dela Red. Cuando un contenido est en ms de un lugar, debera elegir el mejorservidor en cada momento: el original o una rplica rpida (o traer por trozosel objeto desde varios a la vez).

c)Rplica: si un servidor guarda una rplica de algn contenido probable-mente es porque desea ofrecerlo y reducir la carga del servidor original. Portanto, debe ser conocido por sus clientes, pero adems el contenido tieneque ser consistente con el contenido original.

d)Proveedordered: debera elegir el mejor camino para una peticin, vadireccionamiento IP, va resolucin DNS (resolver nombres en la direccin IPms prxima al cliente que consulte, aunque no es lo ms habitual), va servi-dores proxy-cache HTTP y evitar zonas congestionadas (hot spots) o flash crowd(congestin en el servidor y en la red prxima debida a una avalancha de de-mandas).

Por tanto, los proxy-cach slo son parte de la solucin. Las redes de distribu-cin de contenidos son la solucin de otra parte del W-W-Wait.

Una rplica (mirror)?

En enero del 2007, el progra-ma HTTPD de Apache, el ser-vidor web ms utilizado en In-ternet, poda bajarse unas 300rplicas del sitio web original.La lista de rplicas est en ladireccin direccin The statusof Apache mirrors y la informa-cin del servidor, en la pginaweb del http server project deApache.


4. Contenidos distribuidos

Otra mejora que ayuda a combatir el mal del W-W-Wait son los sistemasde distribucin de documentos: basta un nico servidor para cualquier "au-diencia"? La respuesta es que no, si se desea ofrecer una calidad adecuada parademandas tanto muy pequeas como bastante grandes, para contenidos quepueden llegar a ser muy populares en ciertos momentos, que pueden visitarsedesde cualquier lugar del mundo o que pueden tener una audiencia potencialenorme.

Las aplicaciones que ofrecen contenidos en Internet se enfrentan al retode la escala: un solo servidor ante eventualmente millones de personasque pueden pedirle sus servicios todos a la vez: el proveedor de infor-macin debe poner tantos recursos como audiencia pueda tener.

En consecuencia, debe pagar ms quien tiene algo ms interesante que contaro quiere llegar a ms. La web no funciona como una antena de radio: la po-tencia de emisin determina la cobertura, pero el nmero de receptores no laafecta; es ms similar al telfono: la capacidad se mide en nmero de lneas yesto determina el nmero de personas que pueden atenderse a la vez.

Por este motivo, puede ser necesario disponer de varios servidores para poderrepartir la carga entre los mismos.

La primera pgina web pblica, ahora ya fuera de funcionamiento, fue http://info.cern.ch. Sin embargo, la primera web con una demanda importante fuehttp://www.ncsa.uiuc.edu. Esta web tuvo que usar cuatro servidores replicadospara satisfacer la demanda. En la siguiente grfica puede verse la evolucin delnmero de peticiones entre julio de 1993 (91.000 peticiones/semana) y abrilde 1994 (1.500.000 peticiones/semana).


Figura 14

Crecimiento del nmero de peticiones semanales durante dos aos. Cada tono de gris se corresponde con una mquinadistinta. A mediados de febrero de 1994, diferentes mquinas empezaron a servir peticiones al mismo tiempo hasta llegar acuatro.

Existen varios trucos para repartir peticiones entre diferentes mquinas:

Mirrors con un programa que redirige la peticin HTTP a la mejor rplica(podis ver el ejemplo siguiente de Apache).

Hacer que el servicio de nombres DNS devuelva diferentes direcciones IP(el mtodo round robin). De esta manera, los clientes pueden hacer peticio-nes HTTP cada vez a una direccin IP distinta.

Redireccin en el nivel de transporte (conmutador de nivel 4, L4 switch):un encaminador mira los paquetes IP de conexiones TCP hacia un servidorweb (puerto80) y las redirige a la mquina interna menos cargada.

Redireccin en el nivel de aplicacin (conmutador de nivel 7, L7 switch):un encaminador que mira las conexiones HTTP y puede decidir a qu r-plica contactar en funcin del URL solicitado. Muy complejo.

Mandar todas las peticiones a un proxy inverso que responda o con con-tenido guardado en la memoria o que pase la peticin a uno o varios ser-vidores internos.

Si, adems, las rplicas se sitan cerca de los clientes, el rendimiento ser mejory ms predecible. El inconveniente es que es difcil y caro montar un servicioweb distribuido.

www.google.com

Si se pregunta al DNS porwww.google.com, la respuestacontiene varias direcciones IP:nslookup www.google.com.


La Fundacin Apache distribuye el servidor HTTPD Apache con la colabora-cin de ms de doscientas rplicas distribuidas en todo el mundo. Aunque laspginas web se pueden consultar en el servidor origen, a la hora de bajar elprograma hay un programa que calcula y redirige al visitante al servidor msprximo. De esta manera, las rplicas ayudan a repartir la carga a la vez queofrecen un mejor servicio al cliente. Aqu el contenido se actualiza peridica-mente.

4.1. Redes de distribucin de contenidos

Han surgido empresas que se han dedicado a instalar mquinas en muchoslugares del mundo y algoritmos para decidir qu mquina es la ms adecuadapara atender peticiones segn la ubicacin del cliente y la carga de la Red.Estas empresas venden este servidor web distribuido a varios clientes quepagan por poder disponer de un sistema de servicio web de gran capacidadque puede responder a demandas extraordinarias de contenidos.

Estos sistemas se denominan redes de distribucin de contenidos (content de-livery networks o CDN), y se pueden encontrar varias empresas que ofrecen esteservicio: Akamai es la ms importante.

Una CDN es un software intermediario (middleware) entre proveedoresde contenidos y clientes web. La CDN sirve contenido desde varios ser-vidores repartidos por todo el planeta. La infraestructura de la CDN es-t compartida por varios clientes de la CDN, y las peticiones tienen encuenta la situacin de la Red para hacer que cada cliente web obtengael contenido solicitado del servidor de la CDN ms eficiente (habitual-mente, una combinacin del ms prximo, el menos cargado y el quetiene un camino de mayor ancho de banda con el cliente).

Es como un servicio de logstica: la CDN se encarga de mantener copias cercade los clientes en sus propios almacenes (no en un punto central, sino en losextremos de la Red). Para esto, debe disponer de multitud de puntos de servicioen multitud de proveedores de Internet (servidores surrogate: funcionalidadentre servidor proxy-cache y rplica). Por ejemplo, Akamai ofreca en enero del2007 unos 20.000 puntos de servicio en todo el mundo.

Una propuesta difcil de rechazar

La oferta de una CDN como Akamai a un proveedor de acceso a Internet (ISP) podraser: nos dejas en tu sala de mquinas el espacio equivalente para un frigorfico casero,nosotros te mandamos unas mquinas y t las enchufas a la red elctrica y a tu red(Internet). Nosotros las administramos. Qu ocurrir? Todas las peticiones web a variosmiles de empresas sern servidas por nuestras mquinas. El ISP ahorra gasto de ancho debanda con Internet, pues sus usuarios no necesitarn ir a Internet para buscar algunoscontenidos, que sern servidos por las mquinas de Akamai en el ISP. Akamai cobra delproveedor de contenidos por servir el contenido ms rpido y mejor que nadie.

Cmo ser mirror deApache?

Apache pide que al menosse actualice el contenido dosveces por semana. Las herra-mientas para hacerlo son las si-guientes:a. rsync: un programa quecompara dos lugares remotosy transfiere los bloques o fiche-ros que hayan cambiado. Vedhttp://rsync.samba.org.b. cvs: un programa pensadopara desarrollo de cdigo adistancia, y que permite detec-tar e intercambiar diferencias.Ved http://www.cvshome.org.c. Apache como proxy-cache:configurar un servidor Apachepara pasar y hacer cache de laspeticiones. Orden: ProxyPass /http://www.apache.org / Ca-cheDefaultExpire.


Algunas CDN, adems, se sirven de enlaces va satlite de alta capacidad (y re-tardo) para trasladar contenidos de un lugar a otro evitando la posible conges-tin de Internet. Aunque puedan no ser ideales para objetos pequeos, puedefuncionar bien para objetos grandes (por ejemplo, software, audio, vdeo). Al-gunos ejemplos son las empresas Amazon 33, Castify y Real Networks.

Por otra parte, la transferencia de una pgina web normal funciona de la ma-nera como se observa en la figura 15.

Figura 15

Fases de una peticin web

Una peticin de una pgina web (documento HTML + algunos grficos) hacedistintas operaciones: 0.1) resolucin DNS del nombre del servidor, 1.1) cone-xin TCP con el servidor, 1.2) solicitud del URL del documento, 2) el servidordevuelve el documento HTML que contiene referencias a grficos incluidos enla pgina, 3) resolucin DNS del nombre del servidor donde estn los grficos,que acostumbra a ser el mismo servidor que para la pgina HTML, 3.1) solici-tud de los grficos necesarios (puede repetirse distintas veces), 4) contenidoservido y pgina visualizada por el cliente (navegador).

Una peticin a una CDN como Akamai aprovecha para tomar decisiones encada paso de la peticin:

Enlace de inters

Es interesante visitar la web deAkamai.


Figura 16

Fases de una peticin web usando una CDN.

La CDN puede actuar sobre:

El DNS: cuando se resuelve un nombre, el servidor DNS responde segn laubicacin de la direccin IP del cliente.

El servidor web: cuando se pide una pgina web, se reescriben los URLinternos segn la ubicacin de la direccin IP del cliente.

Cuando se pide un objeto a la direccin IP de un servidor de la CDN, el

conmutador2 de acceso a un conjunto de distintos servidores proxycache, orplicas, puede redirigir la conexin al servidor menos cargado del grupo(todo el conjunto responde bajo una misma direccin IP).

Los pasos de la peticin de una pgina web con grficos podran ser los si-guientes:

0. El usuario escribe un URL (por ejemplo, http://www.adobe.com) en su na-vegador, y su navegador resuelve el nombre en DNS (192.150.14.120).

1. El usuario pide el URL a la direccin IP (192.150.14.120).

1.a. El servidor web elige la mejor rplica, segn IP origen, estado de la Red yubicacin de las rplicas, o al menos clasifica al cliente en una zona geogrficadeterminada (por ejemplo, con Akamai decide que estamos en la zona delmundo o regin g).

2. El servidor devuelve el HTML con el URL de los grficos incluidos en lapgina (marcas ), que se han redirigido a una rplica. De esta manera,los grficos que constituyen el mayor nmero de bytes de una pgina websern transferidos por la CDN. Por ejemplo:

(2)En ingls, switch.


3. El cliente resuelve el nombre y pide grficos u otro contenido a la rplicams cercana.

3.a. Posible redireccin con el DNS o por redireccin de la conexin TCP (enel nivel del TCP o el HTTP: un conmutador de nivel 4 o 7), reparto de la cargaen un grupo de servidores.

4. Contenido servido ms rpido desde una rplica.

La ventaja de todo este montaje es que el usuario sigue viendo en su navega-dor un URL normal (el de la pgina HTML), el servidor de la empresa tienelogs con visitas a pginas HTML y el departamento de marketing puede hacerestadsticas, pero la mayora del trfico (los grficos) lo sirve Akamai desde laproximidad del cliente.

El servei d'Akamai des de la proximitat del client

Akamai mantiene informacin del estado de la Red, de los clusters, de sus servidores.No siempre elige el mejor posible, pero s uno de los mejores, y en cambio evita lospeores servidores en cada momento.

Figura 17

Distribucin acumulada de tiempo de respuesta (latencia) de distintos servidores Akamai.

La grfica anterior muestra en lneas finas el tiempo que se tarda en obtener desde unlugar determinado un objeto de 4Kb pedido a muchos servidores de Akamai.

El eje x, en escala logartmica, mide el tiempo (ms). El eje y mide la fraccin acumuladade casos en los que el tiempo de descarga es inferior a un cierto valor. La lnea gruesacontnua (agregado) mide la media de todos los servidores, y la lnea gruesa discontnua(akamai) muestra el tiempo de respuesta del servidor que selecciona Akamai en cadamomento (prcticamente siempre selecciona el mejor).


La lnea gruesa continua indica que si se hiciese una eleccin aleatoria, para el 20% (0,2)de los casos el tiempo de servicio sera inferior a 64 ms, pero para el 80% de los casos eltiempo sera inferior a 400 ms. Con la eleccin de Akamai, el 80% de las peticiones sesirven en menos de 50 ms. Si eligiramos uno de los peores servidores, slo podramosdecir que el 80% de las peticiones se sirven en menos de 1.000 ms.

Consecuencia: la decisin de Akamai es casi ideal, mucho mejor que la decisin aleatoria,y por supuesto que el peor caso (Ley de Murphy).


5. Computacin orientada a servicios

Las aplicaciones web devuelven resultados que pueden corresponder al con-tenido de un archivo (contenidos estticos) o ser el resultado de la ejecucinde un programa (contenidos dinmicos). Las aplicaciones que generan conte-nidos dinmicos pueden requerir pequeas o grandes dosis de computaciny almacenamiento. Algunos ejemplos son los buscadores web, las tiendas enInternet, los lugares de subastas, los servicios de mapas o imgenes de satlite,que pueden necesitar hacer complejos clculos, buscas, o servir enormes vol-menes de informacin. Dentro de las organizaciones tambin se utilizan sis-temas complejos que procesan cantidades ingentes de datos y que presentansus resultados a travs de un navegador. Son ejemplos de ello las aplicacionesfinancieras, cientficas, de anlisis de mercados, que tratan con enormes can-tidades de datos que hay que recoger, simular, predecir, resumir, estimar, etc.,para que unas personas puedan evaluar una situacin y tomar decisiones.

En estos sistemas cada unidad autnoma de procesamiento se puede agruparen un servicio y la forma de interaccin entre ellos se suele basar en serviciosweb. En cuanto a la interaccin con el usuario, todo este conjunto de servi-cios se puede esconder detrs de un servidor web y de una interfaz de usua-rio que puede ser tradicional (basada en formularios HTML sencillos) o bienser ms interactiva y ms parecida a una aplicacin centralizada que utilicelas capacidades avanzadas de los navegadores como AJAX. En este modelo deaplicaciones o sistemas, el procesamiento est repartido entre el que ocurre enel navegador del usuario (relacionado con la presentacin e interaccin conel usuario), el servidor web (mediacin entre una aplicacin en el servidor yel navegador remoto) y otros servidores y servicios localizados potencialmen-te en otras mquinas, ubicaciones e incluso otras organizaciones, siguiendoun modelo federado. Estos sistemas pueden tener una estructura fija o biendinmica, en las cuales las herramientas y los recursos se incorporan segn lademanda (un modelo de uso llamado utility computing).

5.1. SOA en detalle

Utility computing

Se define como el suministrode recursos computacionales,como pueden ser el procesa-miento y el almacenamiento,como servicio cuantificado pa-recido a las infraestructuraspblicas tradicionales (comopor ejemplo la electricidad, elagua, el gas natural o el tel-fono).

Se hace muy difcil encontrar una definicin exacta de lo que quiere decirla expresin arquitectura orientada a servicios (SOA). El problema es que haymuchas definiciones diferentes que contienen algunas palabras comunes pe-ro que no acaban de converger. Todas las definiciones sin embargo estn de

acuerdo con el hecho de que el trmino SOA3 hace referencia a un paradigmaque permite una mayor flexibilidad en el desarrollo de aplicaciones web.

(3)SOA es la sigla de arquitecturasorientadas a servicios.


SOA no es una arquitectura concreta, sino un paradigma. Para entenderlo te-nemos que pensar que es algo que nos lleva hacia una manera de hacer quenos permite desarrollar una arquitectura concreta. Lo podemos denominar es-tilo, paradigma, perspectiva, concepto, filosofa, representacin o manera de pensar,que nos lleva a desarrollar aplicaciones de una cierta manera.

Las SOA son adecuadas para el desarrollo de aplicaciones distribuidas, sobretodo a gran escala, puesto que facilitan la interaccin entre proveedores deservicios y consumidores de los servicios.

Entonces, las arquitecturasorientadasaservicios (SOA) se pueden de-finir como un paradigma de diseo de software que impone el uso delos servicios web para apoyar los requisitos de los usuarios. As pues,en una aplicacin distribuida los recursos se harn accesibles a travsde servicios independientes, a los que se podr acceder sin conocer losdetalles de la implementacin.

Las arquitecturas orientadas a servicios estn basadas en el uso de servicios webestndar, como por ejemplo SOAP o REST, aunque se pueden implementar concualquier especificacin de servicio web. Un requisito deseable a pesar de queno es obligatorio de cualquier servicio web es que este sea sin estado, puestoque favorece la escalabilidad y la independencia de ejecucin de cada servicio.Este requisito ha favorecido que el uso de los servicios basados en REST hayaaumentado mucho en los ltimos aos.

Las propiedades principales de una arquitectura orientada a servicios son:

Distribucin. Las funcionalidades de la arquitectura se ofrecen como ser-vicios que pueden estar ubicados en diferentes lugares, incluso un mismoservicio puede ser ofrecido de forma distribuida.

Heterogeneidad. Los servicios son independientes de la tecnologa sub-yacente; por lo tanto, esta tecnologa se puede ejecutar en mquinas dife-rentes, sobre sistemas operativos diferentes y puede estar implementadacon lenguajes diferentes. A la vez, los servicios tambin pueden ser hete-rogneos, se pueden ofrecer diferentes servicios o un mismo servicio im-plementado de diferentes maneras.

Lectura recomendada

La obra siguiente nos puedeservir de referencia para pro-fundizar en las arquitecturasorientadas a servicios:NicolaiM.Josuttis (2007).SOA in practice: the art of dis-tributed system design. O'reilly.

Interoperabilidad. La especificacin de los servicios sigue estndares co-mo los de OASIS o los contratos definidos con WSDL. Esto hace que ser-vicios implementados con tecnologas diferentes puedan interoperar por-que la interfaz es comn.

Desacoplamiento. Los servicios exponen funcionalidades que se puedenofrecer de forma remota y distribuida. Esto permite desacoplar el servicio

OASIS

OASIS es un consorcio sin ni-mo de lucro que gua y regu-la el desarrollo, la convergen-cia y la adopcin de estnda-res abiertos por parte de la so-ciedad de la informacin.


de la mquina en cuanto que un servicio puede estar replicado o distribui-do, o puede migrar a otras mquinas.

Flexibilidad. Un servicio puede apoyar o ser usado por diferentes aplica-ciones para permitir un aprovechamiento de funcionalidades y ms flexi-bilidad en el desarrollo de nuevas aplicaciones. El hecho de que los servi-cios se expongan con interfaces estndar permite un desarrollo ms hete-rogneo de las aplicaciones y una eleccin ms adecuada de las tecnolo-gas segn cada situacin.

Escalabilidad. Los servicios se pueden replicar y distribuir de forma trans-parente al usuario, que los ve como una nica fachada. Esta caractersticade las arquitecturas orientadas a servicios favorece la implementacin deaplicaciones que pueden soportar grandes cantidades de usuarios.

Toleranteafallos. Gracias al desacoplamiento de la especificacin del ser-vicio y de la mquina que lo ejecuta, se pueden desarrollar tcnicas paraque un fallo de un servicio pueda ser atendido por una rplica de formatransparente al usuario.

No tenemos que pensar que los servicios de una SOA siempre apoyan a unusuario o a una funcionalidad de la arquitectura, sino que muchas veces losservicios se organizan en jerarquas de servicios que constituyen una arquitec-tura en varias capas formadas por servicios. Este tipo de organizacin permitedesarrollar aplicaciones tan complejas como las aplicaciones de la banca, lasque rigen el funcionamiento de grandes cadenas de produccin, las de grandeslugares web como Amazon o eBay, etc.


Figura 18

Estructura de una aplicacin desarrollada siguiendo una arquitectura orientada a servicios.

5.2. Grid computing

Los sistemas de parrilla de clculo4 tienen como objetivo la metacompu-tacin, es decir, capacidades computacionales a escala Internet. No se puedenhacer asunciones sobre el tipo de hardware, sistemas operativos, interconexio-nes de red, dominios administrativos, polticas de seguridad, de este sistema.

(4)En ingls, grid computing.

Cuando se habla de grid se hace referencia a una infraestructura que comportael uso integrado y colaborativo de ordenadores, redes, bases de datos e instru-mentos cientficos que son de propiedad y estn gestionados por diferentesorganizaciones. A menudo, las aplicaciones en parrilla de clculo trabajan congrandes cantidades de datos y/o recursos computacionales, que requieren unacomparticin segura de recursos que atraviesan diferentes lmites organizati-vos o dominios de administracin. Por su parte, e idealmente, el usuario tieneuna visin del sistema de clculo en parrilla como si fuera un nico sistemainformtico, puesto que este le proporciona un acceso uniforme a los recursos.

Como las SOA que hemos visto antes, la definicin de grid ha sido muy ampliay abierta. A continuacin, presentamos una serie de definiciones que puedenayudar a entender mejor qu se quiere decir cuando se habla de grid.

Figura19Una parrilla de clculo puede agregar recursos

heterogneos de todo el mundo.


Definiciones

[Sobre la tecnologia grid] la tecnologa que posibilita la virtualizacin de recursos, elaprovisionamiento bajo demanda y la comparticin de servicios (recursos) entre organi-zaciones.

Plaszczak/Wellner

[Sobre el grid computing] la posiblidad, usando un conjunto de protocolos y estndaresabiertos, de ganar acceso a aplicaciones y datos, potencia de procesado, capacidad dealmacenamiento y un amplio abanico de otros recursos de computacin por Internet.Una parrilla es un tipo de sistema paralelo y distribuido que permite la comparticin, laseleccin y la agregacin de recursos distribuidos a travs de dominios administrativosmltiples, basados en su disponibilidad (de recursos), capacidad, potencia de ejecucin,coste y requisitos de calidad de servicio de los usuarios.

IBM, IBM Solutions Grid for Business Partners: Helping IBM Business Partners to Grid-enable applications for the next phase of e-business on demand

[Sobre el grid] un tipo de sistema paralelo y distribuido que permite la comparticin, laseleccin y la agregacin de recursos autnomos geogrficamente dispersos de maneradinmica y en tiempo de ejecucin segn su disponibilidad, capacidad, potencia de eje-cucin, coste y requisitos de calidad de servicio de los usuarios.

Rajkumar Buyya, Srikumar Venugopal, A Gentle Introduction to Grid Computing andTechnologies (2005)

Se empieza a hablar de parrillas de clculo a partir de la segunda mitad delos aos noventa del siglo XX. Como en el caso de igual a igual, los sistemasde parrilla de clculo fueron una consecuencia del aumento sustancial en elrendimiento de los ordenadores personales y de las redes en los ltimos veinteaos. Por otro lado, gracias a la combinacin entre el abaratamiento de losordenadores personales y su aumento de potencia, proliferaron sistemas dealtas prestaciones a bajo coste, que permitieron a muchos colectivos disponerde suficiente potencia de cmputo para solucionar problemas que requeranun uso intensivo de recursos sin tener que disponer de superordenadores.

En particular, el mundo cientfico se ha beneficiado de esta potencia decmputo para hacer simulaciones y experimentos mucho ms exhaustivos ypara los cuales antes haba que disponer de grandes superordenadores. Las re-des ms rpidas han permitido compartir datos de los instrumentos y resul-tados de los experimentos con colaboradores de todo el mundo casi instant-neamente. En este contexto, las parrillas de clculo nacen como un paso msen este esfuerzo de colaboracin y comparticin.

El trmino grid

Esta infraestructura se deno-min grid por analoga con lared elctrica (en ingls, electri-cal power grid), que proporcio-na un acceso universal, fiable,compatible y transparente a laenerga elctrica, con indepen-dencia de su origen.

En el ao 2007 el trmino computacin en nube5 se hizo popular hasta desban-car al concepto de parrilla de clculo. No obstante, y como veremos ms ade-lante, el grid computing y el cloud computing mantienen cierta relacin, cuando

(5)En ingls, cloud computing.


menos la que Foster postulaba ya el ao 1999 en trminos de computacinconsumida como si fuera electricidad. Incluso el trmino grid se asocia a vecesa la capacidad de computacin de los sistemas cloud computing.

5.3. Cloud computing

Lectura recomendada

IanFoster's,CarlKesselman's (1999). TheGrid: Blueprint for a newcomputing infrastructure.

La computacinennube6 es una forma de computacin fundamenta-da en Internet, mediante la cual los recursos compartidos, el software yla informacin, son ofrecidos a todo tipo de dispositivos con acceso ala Red bajo demanda como servicios ubicados en Internet.

(6)En ingls, cloud computing

Se trata de un cambio de paradigma despus del paso de estructura de orde-nador central (mainframe) a estructura de cliente-servidor, que lo precedi enla dcada de 1980. Los detalles son transparentes para los usuarios que ya notienen necesidad de tener conocimientos tcnicos, ni control sobre la infra-estructura de tecnologa en nube que los apoya. La computacin en nubedescribe un nuevo suplemento, consumo y modelo de prestacin de serviciosde tecnologas de la informacin (TI) basados en Internet, y que generalmenteimplica el suministro dinmico escalable y muchas veces virtualizado de losrecursos como servicio a travs de Internet. Es consecuencia de la facilidadde acceso a los lugares remotos de computacin que ofrece Internet graciasal al incremento en la calidad de las conexiones (ancho de banda, latencia yfiabilidad).

Los sistemas de computacin en nube han surgido de una evolucin lgica delos sistemas de parrilla de clculo. Mientras que la parrilla procuraba el accesoa recursos bajo demanda, la nube ha pretendido desacoplar la demanda de lainfraestructura fsica ofreciendo la computacin no en forma de recurso sinoen forma de servicio, hacindola transparente a la infraestructura subyacente.

La computacin bajo demanda se puede encontrar enfocada desde niveles di-ferentes:

Mainframe

Ordenador central, potente ycostoso utilizado para el proce-samiento y la gestin de unagran cantidad de datos y/ousuarios. En los inicios de In-ternet, la mayora de empresastenan su mainframe, que dabaservicio a todos los empleadosmediante terminales muy sen-cillos.

Figura20Imagen de un mainframe de los aos 70.

SaaS7. Se ofrece el software como servicio, es decir, el proveedor de compu-tacin en nube ofrece como un servicio software alojado en sus mquinasa otros que obtienen el acceso a aquel software. Los clientes no se tienenque preocupar del mantenimiento, las actualizaciones ni las licencias delsoftware, y adems, pueden acceder a l desde donde quieran.

(7)Acrnimo de software as a servi-ce.

PaaS8. Los proveedores de computacin en nube ofrecen servicios de ac-ceso y uso de plataformas de software especficas, como servidores de apli-caciones, sistemas operativos, entornos de trabajo especficos y todo enforma de servicio sin que el cliente se tenga que preocupar de la infraes-tructura necesaria para mantener las plataformas.

(8)Acrnimo de platform as a servi-ce.


IaaS9. Este nivel de computacin en nube es lo ms parecido al sistemade parrilla de clculo. La infraestructura como servicio es el ofrecimientode hardware, la capacidad de comunicacin, etc., no limitado y ampliabletransparentemente, que evita la complejidad de mantenimiento y agrega-cin de hardware a los clientes.

Figura 21

Diferentes formas de ofrecer servicios de computacin en nube. Cuanto ms arriba en la pirmide,mayor es la relacin coste-eficiencia de los servicios en detrimento del control que tenemos de ellos.Cuanto ms cerca del hardware, los clientes tienen ms control del sistema pero a expensas de sumantenimiento.

(9)Acrnimo de infrastructure as aservice.


Resumen

En este mdulo se han presentado las formas con las que un servicio web ouna aplicacin asociada a un servidor web se pueden organizar para atenderla demanda que pueden recibir de Internet. Muchos indicadores de Internetcontinan creciendo de forma exponencial: el nmero de personas con acce-so a Internet y el trfico web, que hoy en da predomina sobre el resto deprotocolos. La popularidad de los contenidos sigue la ley de Zipf, la ley de ladesigualdad extrema: muchas visitas para muy pocos lugares. Esto hace que lademanda que pueda recibir en un momento concreto un servidor web puedaser exageradamente grande. Conocer las caractersticas principales de esta de-manda ayuda a prever situaciones en el diseo de un servicio web.

La capacidad para servir peticiones es difcil de prever en un sistema tan com-plejo en el que influyen, entre muchos factores, la capacidad de la Red y sucarga, las caractersticas de toda la mquina, el sistema operativo con nume-rosos subsistemas o el servidor web. Es conveniente conocer la capacidad deservicio de nuestro servidor y observar su comportamiento con niveles de car-ga elevados usando herramientas de generacin de trfico y medida del com-portamiento bajo una carga sinttica, as como herramientas de visualizacinde estadsticas de demanda real a partir de diarios (logs), que nos permitandetectar sobrecargas, sintonizar o actualizar el conjunto adecuadamente.

Las aplicaciones en servidores web tienen dos componentes principales: el ser-vidor web y el cdigo adicional que ampla el servidor para ofrecer servicios ocontenidos dinmicos. El servidor web es un sistema que se encarga de serviralgunas de las muchas peticiones a la vez, por lo cual, se tiene que optimizarla organizacin de toda esta actividad simultnea a partir de procesos, flujosy fibras. Las aplicaciones web reciben peticiones del servidor y devuelven unresultado para enviar al cliente.

Otro componente importante son los servidores intermedios entre navegado-res y servidores web que desean copias de los objetos que ven pasar desde unservidor hacia un navegador. Principalmente, permiten acortar peticionessirvindolas a medio camino del servidor, en la memoria, con objetos recibi-dos recientemente, hecho que reduce la congestin de Internet y la carga delos servidores.

Mientras que los servidores de memoria rpida de trabajo se suelen situar cercade los lectores, la demanda global de ciertos contenidos o la tolerancia a fallospuede recomendar ofrecer un servicio web desde varias ubicaciones. Hay va-


rias maneras de montar un servicio distribuido: replicacin o mirroring, DNSround-roben, redireccionamiento a nivel de transporte o HTTP, servidores in-termediarios inversos.

Otra alternativa es contratar la provisin de servicio a una red de distribucinde contenidos o CDN, que es una infraestructura comercial compartida porvarios clientes con infinidad de puntos de presencia prximos a la mayora deusuarios de Internet, que se encargan de repartir y dirigir las peticiones webhacia los servidores menos cargados y ms cercanos en su origen de la peticin.

La computacin bajo demanda es un modelo ms general que permite distri-buir un sistema en varios componentes distribuidos que se comunican coninvocaciones a servicios y el uso de recursos (computacin, almacenamiento,servicios de aplicacin), que se asignan dinmicamente segn cul sea la ne-cesidad o el volumen de demanda de sus usuarios. Hemos visto las SOA comoparadigma de construccin de aplicaciones a escala de Internet, los sistemasde parrilla de clculo y su evolucin hacia sistemas de computacin en nube,muy relevantes hoy en da.


Bibliografa

Krishnamurthy, B.; Rexford, J. (2001). Web protocols and practice: HTTP/1.1, networkingprotocols, caching, and traffic measurement. Cambridge: Addison-Wesley (ISBN 0-201-71088-9).

Un libro exhaustivo y detallado sobre el funcionamiento de la web ms all de la presenta-cin a los navegadores. Estudia los detalles de las diversas versiones del protocolo HTTP, surendimiento, la interaccin con los otros servicios involucrados: DNS, TCP, IP, la evolucinhistrica de los componentes de la web, scripts, buscadores, galletas, autenticacin, tcnicaspara recoger y analizar trfico web, proxy-caches web e interaccin entre proxy-caches.

Luotonen, A. (1998). Web proxy servers. Londres: Addison-Wesley (ISBN 0-13-680612-0).

Ari desarroll el servidor proxy-cache del CERN y tambin el servidor intermediario de Nets-cape. Habla de los detalles de la estructura interna (procesos) de los servidores, cooperacinentre servidores, mediacin, filtrado, monitorizacin, control de acceso, seguridad, aspectosque afectan al rendimiento de un servidor intermediario y otros aspectos.

Luotonen, A.; Altis, K. (1994). World-Wide Web Proxies. Actas de la ConferenciaWWW94.

Es el artculo histrico sobre proxy-cache en web, basado en la experiencia con la memoriaweb del CERN.

Rabinovich, M.; Spatscheck, O. (2002). Web caching and replication. Boston (EE.UU.):Addison-Wesley (ISBN 0-201-61570-3).

Un libro exhaustivo y detallado sobre los avances recientes en memorias rpidas de trabajoy replicacin para la web. Los captulos 4: Protocolos de aplicacin para la web, 5: ApoyoHTTP para proxy-cache y replicacin, 6: Comportamiento de la web, ofrecen una buenavisin general del problema y los mecanismos que influyen en l. La parte II analiza condetalle los mecanismos de proxy-cache y la parte III, los mecanismos de replicacin en laweb. Hay muchos libros especficos y detallados sobre cada tecnologa explicada: sobre lasespecificaciones, sobre cmo utilizarla, cmo instalarla y administrarla, referencias breves,etc. Entre otros, la editorial O'Reilly tiene muchos libros bastantes buenos y muy actualizadossobre varios temas de la asignatura. Son muy detallados, mucho ms de lo que se pretendeen la asignatura, pero en la vida profesional pueden ser de gran utilidad para profundizar enlos aspectos prcticos de un tema.

Jossuttis, N. (2007). SOA in practice. The art of distributed system design. Un libro muy com-pleto y ameno sobre el paradigma de arquitecturas orientadas a servicios. Presenta el para-digma desde un punto de vista prctico y hace referencia a los aspectos ms relevantes en elproceso de desarrollo de aplicaciones basadas en servicios web.

Arquitectura de aplicaciones webIntroduccinObjetivosndice1. Caractersticas de la demanda de pginas web2. Organizacin de las aplicaciones en servidores web2.1. El servidor web2.2. Organizacin del servidor web2.3. Organizacin de las aplicaciones web

3. Servidores proxy-cache web4. Contenidos distribuidos4.1. Redes de distribucin de contenidos

5. Computacin orientada a servicios5.1. SOA en detalle5.2. Grid computing5.3. Cloud computing

ResumenBibliografa

Documents

Arquitectura de Aplicaciones Web M2