docservidor web - Universidad de Alicante
download 
Demanda Transcripción
servidor web - Universidad de Alicante
Tema 1. HTTP y aplicaciones web 1. El protocolo HTTP El protocolo HTTP y su relación con las aplicaciones web Petición/Respuesta HTTP • Un servidor web está a la escucha por un determinado puerto (típicamente el 80), aceptando peticiones y generando respuestas según el protocolo HTTP • El protocolo especifica la sintaxis de peticiones y respuestas • El intercambio de información se hace en modo texto GET notas.html HTTP/1.0 HTTP/1.0 200 OK <html> <head> </head> <body> <h1> Notas de ADI </h1> ... Estructura de la petición Línea de petición Cabeceras GET / HTTP/1.1 Host: www.ua.es User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.2) Gecko/20100101 Firefox/6.0.2 Accept: text/html,application/xhtml+xml,application/ xml;q=0.9,*/*;q=0.8 Accept-Language: es-es,es;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip, deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Connection: keep-alive If-Modified-Since: Tue, 20 Sep 2011 08:58:31 GMT If-None-Match: "f90d3d-63b6-4e7855b7;4dd6141f" Estructura de la respuesta Línea de estado Cabeceras Cuerpo entidad HTTP/1.1 200 OK Date: Tue, 20 Sep 2011 09:08:58 GMT Server: Apache/1.3.41 Content-Location: index.html.es-es Vary: negotiate,accept-language TCN: choice Last-Modified: Tue, 20 Sep 2011 08:58:31 GMT Etag: "f90d3d-63b6-4e7855b7;4dd6141f" Accept-Ranges: bytes Content-Length: 25526 Keep-Alive: timeout=15, max=100 Connection: Keep-Alive Content-Type: text/html Content-Language: es-es (línea en blanco...) <html xmlns="http://www.w3.org/1999/xhtml" lang="es" xml:lang="es"> <head> <title>Universidad de Alicante</title> ... Una página = múltiples recursos • Una sola página contiene normalmente múltiples recursos (imágenes, código Javascript, flash,...). Cada uno de ellos requiere una transacción HTTP separada Métodos de petición • Los navegadores suelen usar dos tipos: GET y POST • GET (solicitar un recurso). • Se pueden enviar también parámetros con la petición. En su caso van en la 1ª línea de la petición HTTP • Al pulsar en enlace o enviar formulario tipo GET • POST (enviar datos). • Los datos van al final de la petición • Al enviar formulario tipo POST • Existen otros, pero para lanzarlos desde un navegador hay que usar Javascript • PUT • DELETE • ... Códigos de estado • Diferentes rangos numéricos indican distintos tipos de resultados • Consultar por ejemplo http://httpstatus.es • 1xx Informational • 2xx success (p. ej. 200 OK) • 3xx redirection (p. ej. 301 MOVED PERMANENTLY) • 4xx client error (p. ej. 404 NOT FOUND, 400 BAD REQUEST, 401 UNAUTHORIZED, 418 I’M A TEAPOT :) ) • 5xx server error • Se pueden usar como respuestas a llamadas a un API • Por ejemplo, aunque la gente entiende comúnmente el 404 como “página no encontrada” en realidad es “recurso no encontrado”. Imaginemos una llamada a un API para obtener el expediente de un alumno al que pasamos un DNI inexistente Protocolo “sin estado” • Cada ciclo petición/respuesta es independiente del anterior • No se “recuerda” nada del anterior ciclo • Como esto es un problema para ciertas actividades en la web, se han añadido elementos al HTTP para “solucionarlo” => Cookies • Tendremos que tener en cuenta esto cuando usemos HTTP para acceder a un API (aplicaciones REST) • En principio el servidor no recordaría que ya nos hemos autentificado http://xkcd.com/869/ 2. Aplicaciones web Aplicaciones web • Una aplicación web es una colección de “rutinas” o “programas”. A cada uno se accede a través de una URL • La comunicación con la aplicación se hace a través de HTTP • Al igual que en línea de comandos podemos pasar parámetros. En HTTP se pasan bien en la primera línea de la petición, bien al final 1. “Parsea” los parámetros HTTP y verifica que son válidos. Valida permisos GET notas/verNota?asig=adi&dni=22333444 HTTP/1.0 2. Lanza una consulta SQL en la B.D. y obtiene los resultados verNota HTTP/1.0 200 OK <html> <head> </head> <body> <h1> Tu nota de ADI </h1> <p> Juan Ruiz: 10 </p> </body> 3. Formatea los resultados en HTML Capas lógicas (layers) • El código de “verNota” no debería ser monolítico, ya que implica tareas muy diferentes • Lo más común es organizar el código en capas • Cada capa forma una unidad lógica • ... y solo se relaciona con las adyacentes • En aplicaciones web típicamente se distinguen 3 capas • Acceso a datos • Lógica de negocio • Presentación http://en.wikipedia.org/wiki/Multitier_architecture Servidores de aplicaciones • Estrictamente hablando, un servidor web solo sirve páginas “estáticas” (HTML) • Un servidor de aplicaciones nos da infraestructura software para ejecutar aplicaciones web. Además de ejecutar las aplicaciones puede ofrecer servicios adicionales como • Clustering y balanceo de carga • Autentificación y autorización • Conexión con bases de datos y transaccionalidad • ... Capas vs. niveles • Hay que distinguir entre capas lógicas (layers) y niveles físicos (tiers), aunque muchas veces se usan de forma intercambiable • Las capas implican separación lógica en la organización del código • Un nivel físico distinto implica una máquina distinta (o una máquina virtual distinta) • Podemos tener varias capas en el mismo nivel (p. ej. misma máquina como servidor web y de aplicaciones) Presentación Servidor web Negocio Servidor de aplicaciones Acceso a datos Servidor legacy y de acceso a datos Base de datos Frontend y Backend • El frontend es la parte con que interactúa el usuario, el backend todo lo que hay “por detrás” • Hasta ahora hemos simplificado considerando que todo lo hace el servidor y que el cliente se limita a renderizar el HTML, pero... • En aplicaciones web modernas el código frontend suele ejecutarse en el cliente y el backend en el servidor Charla: Picking a Technology Stack, Pamela Fox, Coursera Petición/Respuesta con AJAX • No solo hay petición/respuesta en el “cambio de página”, también se puede disparar mediante Javascript (AJAX) 3. Arquitecturas web Arquitecturas web • En general, siempre vamos a separar en presentación/negocio/ acceso a datos, pero aparte de esto hay mucho que decidir... • ¿Dónde va a residir el frontend? ¿Va a ser “estático” (solo HTML, cliente “tonto”) o “dinámico” (HTML + Javascript)? • ¿Cómo vamos a organizar la capa de negocio? ¿Va a ser monolítica o la vamos a dividir en módulos independientes (servicios)? • ¿Vamos a colocar las capas en niveles separados físicamente? • ¿Usaremos nuestra propia infraestructura o “la nube”? • ... • Vamos a discutir unos cuantos modelos típicos Aplicaciones monolíticas • Aquí, “monolítico” no significa que el código no esté organizado en capas, sino que la aplicación es una única “unidad de despliegue” • Es la arquitectura más “clásica” en aplicaciones web • Aunque no tienen por qué, es típico que sean además “orientadas a presentación” (generan HTML que se envía al cliente) Aplicaciones “orientadas a presentación” • El HTML no está pre-generado, se genera dinámicamente • Bien “a base de printfs” (para entendernos) • Bien con un lenguaje de plantillas, en que se mezcla código estático con sentencias genéricas de un lenguaje de programación o con instrucciones especiales de control de flujo slim-lang.org PHP Mustache: http://mustache.github.io/mustache.5.html Ejemplo: Twitter hasta 2010 Presentación: Decomposing Twitter: Adventures in Service-Oriented Architecture, QCon New York 2013 Ejemplo: LinkedIn 2003-2005 http://www.slideshare.net/linkedin/linkedins-communication-architecture Problemas • “Too many cooks spoil the broth” • Acoplamiento del código • Difícil optimizar • Por ejemplo, ver el timeline y enviar un tweet son operaciones muy diferentes (1ª frecuente, solo lectura, 2ª menos frecuencia, escritura) El caso Amazon • Un buen día de 2002, Jeff Bezos se despierta y decide que... (http:// steverant.pen.io) • En adelante, todos los equipos expondrán sus datos y funcionalidades a través de interfaces de servicios. • Cada equipo deben comunicarse con los demás a través de estos interfaces. • No se permitirá otra forma de intercomunicar procesos: ni accesos directos, ni acceso directo al almacén de datos de otro equipo, ni memoria compartida ni puertas traseras de ningún tipo. La única comunicación permitida es a través del interfaz de servicio y sobre la red. • No importa qué tecnología se use: HTTP, Corba, PubSub, protocolos propios... • Todos los interfaces de servicio deben diseñarse desde el principio para ser externalizables, es decir, el equipo debe [...] ser capaz de exponer el interfaz a desarrolladores externos. Sin excepciones. • El que no haga esto será despedido. • ¡Gracias y que tengáis un buen día¡ Aplicaciones orientadas a servicios • La capa de negocio se divide en módulos totalmente independientes, llamados servicios • SOA: Service Oriented Architecture • Cuidado, se ha convertido en un término de marketing con un altísimo nivel de hype SOA según los desarrolladores “El motivo de introducir estos servicios no es escalar el sitio web. Añadiendo servicios no va a funcionar más rápidamente [...] En realidad esto va de escalar las cosas para los ingenieros [...] Va de hacer a la gente más productiva.” Jay Kreps, LinkedIn “Lo llames SOA, descomposición funcional, o simplemente buena ingeniería, las funcionalidades relacionadas deben ir juntas, mientras que las no relacionadas deben ir separadas. Más aún, cuanto más desacopladas estén las funcionalidades no relacionadas, más flexibilidad tendrás para escalarlas independientemente unas de otras.” Randy Shoup, eBay Ejemplos: Twitter Presentación: Decomposing Twitter: Adventures in Service-Oriented Architecture, QCon New York 2013 ¿Qué pasa cuando se envía un tweet? Ejemplos: LinkedIn Problemas de SOA • Primera regla sobre el diseño de objetos distribuídos de Martin Fowler: “no distribuyas tus objetos” • Sobrecarga en la comunicación entre servicios • Es difícil dividir en servicios y diseñar APIs estables cuando no está muy claro cuáles deberían ser tus funcionalidades más importantes (p.ej. startups) • De Steve Yegge • Es más difícil encontrar quién es el responsable de un error (en un proceso pueden estar implicados muchos servicios) • Cualquier servicio de tus compañeros se convierte en un posible “atacante” de tu servicio • Depurar los problemas de interacción con otros servicios es difícil Tecnologías de implementación • El protocolo de comunicación con los servicios podría ser propio, pero ya hay “estándares” definidos • SOAP: multiplataforma, pesado, basado en XML, facilita la generación automática de código • REST: multiplataforma, ligero, se podría ver como una “capa muy fina” sobre HTTP “Para diseñar un buen API para los servicios necesitamos usar algo que la gente conozca. Así que, aunque no hay nada superior desde el punto de vista técnico en REST y JSON sobre usar RPC con un protocolo de nivel más bajo, usar algo que la gente comprenda bien [...] ayuda mucho en el diseño del API” Jay Kreps, LinkedIn REST • Realmente no es una tecnología sino una filosofía de diseño • Simplificando • Cada recurso se representa con una URL única • http://miaplicaciondeviajes.com/usuarios/pepito • http://miaplicaciondeviajes.com/usuarios/pepito/viajes/1 • La operación sobre el recurso se define con el método de la petición HTTP • GET = leer, POST = crear, PUT, PATCH = actualizar, DELETE = borrar • El intercambio de datos se hace en formatos estándar • Típicamente XML o JSON • No hay estado • Lo que significa que para cada operación restringida tenemos que enviar de nuevo las credenciales Lógica de negocio en el cliente • Un paso más allá • Ya hemos visto que el código del servidor se puede considerar como un API que ofrece diferentes servicios • Podemos colocar la aplicación en su mayor parte en el cliente (frontend). Aquí estárá la presentación y parte del negocio • En el servidor está la otra parte de negocio y el código de acceso a datos The New Application Architectures, Adrian Colyer http://www.infoq.com/presentations/SpringOne-2GX-2012-Keynote-2 Ejemplo: Coursera Frontend Architectures, Pamela Fox: http://frontend-architectures.appspot.com/ Platform as a Service • Los servicios no se ejecutan en una infraestructura propia, sino en “la nube” • La plataforma también es un servicio (Platform as a Service PaaS) http://www.paasify.it/vendors Backend as a Service • Todas las aplicaciones hacen una serie de tareas comunes • Gestionar usuarios: identificar, dar de alta, de baja, ... • Almacenar y recuperar datos • ... • Los servicios BaaS ofrecen APIs para estas tareas, incluso algunos permiten ejecutar funciones propias en sus servidores Referencias: libros • Accesible online desde la UA en http://proquestcombo.safaribooksonline.com Referencias: charlas • Jeremy Cloud: “Decomposing Twitter: Adventures in Service-Oriented Architecture” (QCon NY 2013) • http://www.infoq.com/presentations/twitter-soa • Jay Kreps: “Lessons from Building and Scaling LinkedIn” (QCon NY 2013) • http://www.infoq.com/presentations/linkedinarchitecture-stack
Documentos relacionados
operar sobre recursos
Una sola página contiene normalmente múltiples recursos
(imágenes, código Javascript, flash,...). Cada uno de ellos
requiere una transacción HTTP separada
