1 / 103

Tema IV: El Paradigma Cliente-Servidor

Tema IV: El Paradigma Cliente-Servidor. Luis López Fernández. Tema IV: El paradigma Cliente-Servidor. Tema IV: Contenidos. 4.1: El paradigma cliente-servidor 4.2: Clientes y servidores 4.3: Mecanismos de caché en la arquitectura cliente-servidor 4.4: Desarrollo de clientes y servidores

Télécharger la présentation

Tema IV: El Paradigma Cliente-Servidor

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Tema IV:El Paradigma Cliente-Servidor Luis López Fernández

  2. Tema IV: El paradigma Cliente-Servidor Tema IV: Contenidos 4.1: El paradigma cliente-servidor 4.2: Clientes y servidores 4.3: Mecanismos de caché en la arquitectura cliente-servidor 4.4: Desarrollo de clientes y servidores 4.5: Modelos cliente servidor multinivel 4.6: Modelo cliente/servidor en la web: Java Servlets

  3. Tema IV: El paradigma Cliente-Servidor Lección 4.1: El paradigma cliente-servidor 4.1: El paradigma cliente-servidor 4.2: Clientes y servidores 4.3: Mecanismos de caché en la arquitectura cliente-servidor 4.4: Desarrollo de clientes y servidores 4.5: Modelos cliente servidor multinivel 4.6: Modelo cliente/servidor en la web: Java Servlets

  4. Tema IV: El paradigma Cliente-Servidor El paradigma Cliente-Servidor • El término paradigma/modelo “Cliente-Servidor” se utiliza en contextos muy diferentes • En cada uno de estos contextos, su significado cambia sutilmente • Eso es porque el modelo cliente-servidor es a la vez • Una abstracción que simplifica el modelo de paso de mensajes • Un patrón arquitectural para software distribuido • Un patrón de protocolo conversacional • Una arquitectura de sistemas distribuidos • En todos los casos, hablar de modelo cliente-servidor implica: • Que existe una comunicación entre dos entidades • Que esas entidades son asimétricas (realizan acciones diferentes) • Una de las entidades de denomina cliente • El cliente siempre origina el diálogo entre las entidades • La otra de las entidades se denomina servidor • El servidor siempre presta un servicio al cliente

  5. Servicios de red, ORB RPC y RMI Cliente-servidor Paso de mensajes Modelo OSI, modelo TCP/IP Hardware Tema IV: El paradigma Cliente-Servidor El paradigma cliente-servidor como abstracción • El modelo de paso de mensajes • No especifica cómo se sincronizan los procesos • No especifica cuantos tipos de procesos comunican • No especifica el protocolo (diálogo) a seguir entre los procesos • El paradigma cliente-servidor es una abstracción del modelo de paso de mensajes • Especifica cómo se sincronizan los procesos: el servidor espera de forma pasiva la llegada de peticiones de clientes • Especifica que hay dos tipos de procesos y sus roles: servidores y clientes • Especifica el modelo de diálogo basado en petición-respuesta • Restringirnos al modelo cliente-servidor, limita lo que podemos hacer con una aplicación distribuida, pero abstrae algunos de los problemas asociados al IPC • Al desarrollar con APIs cliente-servidor (i.e. servlets) se percibe esa abstracción

  6. Servicios de red, ORB RPC y RMI Cliente-servidor Paso de mensajes Modelo OSI, modelo TCP/IP Hardware Tema IV: El paradigma Cliente-Servidor El paradigma cliente-servidor como arquitectura software • Definición de arquitectura de un sistema software • “La arquitectura comprende la enumeración de los componentes software especificando sus interfaces y la relación que estos guardan entre sí” • Un patrón arquitectural es una plantilla o descripción que puede aplicarse al diseño de arquitecturas de sistemas que tienen una problemática similar • El modelo cliente servidor es un patrón arquitectural de software distribuido que define dos tipos de componentes y un modelo de interacción basado en un diálogo petición-respuesta • Este patrón arquitectural puede aplicarse al diseño de aplicaciones distribuidas en múltiples niveles de abstracción Patrón arquitectural pliente-servidor Patrón arquitectural peer-to-peer

  7. Tema IV: El paradigma Cliente-Servidor El paradigma cliente-servidor como arquitectura software • El patrón cliente-servidor trata de proporcionar una arquitectura escalable para el desarrollo de aplicaciones distribuidas en la que intervienen sólo dos tipos de procesos: clientes y servidores • La interacción entre el cliente y el servidor es síncrona • El servidor • Es pasivo, espera las peticiones de los clientes • Cuando recibe peticiones, debe procesarlas y ofrecer una respuesta • Suele ser diseñado con objetivos de eficiencia • El cliente • Es activo, tiene la iniciativa de iniciar el diálogo con el servidor enviando peticiones • Por cada petición enviada, se debe obtener una respuesta • Suele ser diseñado con el objetivo de interaccionar con el usuario final petición Servidor Cliente respuesta

  8. Tema IV: El paradigma Cliente-Servidor El paradigma cliente-servidor como patrón de protocolo • En un protocolo hay que especificar quién hace qué en cada momento • Múltiples protocolos se basan en el intercambio de mensajes siguiendo un esquema petición-respuesta • En múltiples ocasiones asimila este modelo conversacional como cliente-servidor • Cliente: el que realiza la petición • Servidor: el que espera peticiones y ofrece respuestas • Los términos cliente y servidor se utilizan con esta acepción de manera habitual • Ejemplos: • La API estándar de Java llama ServerSocket a la clase que “espera” conexiones • Pero un ServerSocket no tiene por qué formar parte de un servidor (entendido como patrón arquitectural). Podemos definir una aplicación basada en un modelo P2P en los que cada uno de los peers utiliza instancias de la clase ServerSocket • ¿Por qué, entonces, se denomina Server a este tipo de socket? • Porque, desde el punto de vista del protocolo, este socket estará en el proceso que espera peticiones y las atiende.

  9. Tema IV: El paradigma Cliente-Servidor El paradigma cliente-servidor como arquitectura de sistema • Un sistema distribuido está compuesto por • Nodos de procesamiento (ordenadores) • Infraestructuras de comunicaciones (red) • En muchas ocasiones se eligen características específicas sobre los nodos de procesamiento en términos de hardware, sistema operativo, prestaciones, etc. • Estas características dependen del papel que el nodo esté destinado a representar • En muchas ocasiones, los ordenadores que están destinados a almacenar procesos servidor (desde el punto de vista de arquitectura software) también son denominados servidores ellos mismos • En este caso, por tanto, la palabra servidor se refiere a un equipo, no a un proceso Arquitectura de red con dos servidores y tres PCs

  10. Tema IV: El paradigma Cliente-Servidor Lección 4.2: Clientes y servidores 4.1: El paradigma cliente-servidor 4.2: Clientes y servidores 4.3: Mecanismos de caché en la arquitectura cliente-servidor 4.4: Desarrollo de clientes y servidores 4.5: Modelos cliente servidor multinivel 4.6: Modelo cliente/servidor en la web: Java Servlets

  11. Tema IV: El paradigma Cliente-Servidor Clientes y Servidores • El cliente es la parte de la aplicación que interacciona con el usuario • El cliente no comparte (sus recursos no son “vistos” por otros clientes) • El cliente no tiene restricciones especiales en términos de • Prestaciones: No suelen requerir capacidades especiales • Fiabilidad: Si falla un cliente, el resto del sistema puede seguir funcionando • Escalabilidad: Cada cliente ejecuta en su propio ordenador • El cliente tiene restricciones especiales en términos de • Ergonomía: Debe adaptarse a la interacción con el usuario • Seguridad: No debe comprometer la seguridad de otras aplicaciones • El servidor es la parte de la aplicación que presta servicios al cliente • El servidor comparte sus recursos con todos los clientes que lo usan • El servidor tiene restricciones especiales en términos de • Prestaciones: Cuando queremos que numerosos clientes lo usen • Fiabilidad: Si el servidor falla, los clientes no pueden continuar • Escalabilidad: Queremos que el número de clientes pueda si se requiere • Seguridad: No debe comprometer la seguridad de los clientes ni de los datos • El servidor no tiene prestaciones especiales en términos de • Ergonomía: Lo controla un administrador experto

  12. Capa de presentación Lógica de la aplicación/negocio Capa de Servicios Tema IV: El paradigma Cliente-Servidor Clientes y servidores: quién hace qué? • Las aplicaciones distribuidas existen para ofrecer unas funcionalidades al usuario • La arquitectura abstracta de una aplicación distribuida cliente-servidor es siempre • Capa de presentación • Suele residir en el cliente • El servidor puede tener funcionalidades de presentación menores • Lógica de negocio: • Puede residir en el servidor • Puede residir en el cliente • Puede residir parte en el cliente y parte en el servidor • Capa de servicios: • Es compartida, aunque suele tener más peso en el servidor

  13. Tema IV: El paradigma Cliente-Servidor Ejemplos de aplicaciones cliente/servidor • El servicio WWW clásico (descarga de ficheros + representación): • La capa de presentación requiere, entre otros: • Capacidad para representar documentos HTML • Capacidad para representar imágenes en diferentes formatos • Capacidad para representar e interpretar otros tipos datos (pdf, applets, etc.) • La lógica de la aplicación requiere, entre otros: • No hay mucha lógica de negocio en un servidor/cliente web clásico • ¿Hay algo en un cliente o en un servidor web que no tenga que ver con • Presentar los datos • Proporcionar un servicio de lectura/codificación/envío de ficheros? • La capa de servicios debe proporcionar, entre otros • La implementación del protocolo HTTP • Capacidad de acceder a ficheros identificados por un path HTTP • Comprimir y descomprimir un fichero (si se soporta el encoding gzip) C C C C S S C S

  14. Tema IV: El paradigma Cliente-Servidor Ejemplos de aplicaciones cliente/servidor • Un servicio WWW de comercio electrónico (con páginas activas, por supuesto): • La capa de presentación requiere, entre otros: • Capacidad para representar documentos HTML • Capacidad para representar imágenes en diferentes formatos • Capacidad para representar e interpretar otros tipos datos (pdf, applets, etc.) • La lógica de la aplicación requiere, entre otros: • Comprobación del número de tarjeta de crédito • Gestión de los inventarios (actualizar stock, pedir más, etc.) • Gestión de los pedidos (realizar acciones para envío del pedido) • Gestión contable (actualizar tesorería con ingresos por venta, etc.) • La capa de servicios debe proporcionar, entre otros • La implementación del protocolo HTTPS • Capacidad para acceder a las diferentes bases de datos • Capacidad para comunicar con servicios bancarios • Servicios transaccionales C C C S S S S C S S S S

  15. Tema IV: El paradigma Cliente-Servidor Ejemplos de aplicaciones cliente/servidor • En aplicaciones web, el cliente no tiene lógica de negocio (es genérico) • En aplicaciones en las que el cliente no está prefabricado, esto puede cambiar • Ejemplo de aplicación típico: Aplicación de gestión de una cadena de tiendas • La especificación de una aplicación así puede ocupar cientos de páginas • Lo simplificamos imaginando que • La empresa tiene 4 tablas de datos generales • La tabla de tesorería (cuentas de ingresos y gastos) • La tabla de inventarios (cuantos productos hay en los almacenes) • La tabla de materiales (materias primas para producir productos) • Tabla de comisiones (comisión que cobra un vendedor por venta) • La lógica de negocio (proporcionada por un experto) es • Por cada venta, el vendedor recibe un 10% del montante de comisión • Por cada producto que se vende, hay que comprar el material para construir otro. Este material cuesta un 15% del precio del producto • Hay que actualizar en inventarios y tesorería en cada venta • En un sistema real de gestión tiendas puede haber cientos de operaciones asociadas a una venta

  16. Tema IV: El paradigma Cliente-Servidor Ejemplos de aplicaciones cliente/servidor • Lógica de negocio en pseudocódigo • VENTA (vendedor, numeroProductos, costeProducto){ • pagado = numeroProductos*costeProducto • ingresos = pagado – pagado*0,1 – pagado*0,15 • InsertarEnTabla(TESORERIA, ingresos) • BorrarDeTabla(INVENTARIO, numeroProductos) • InsertarTabla(MATERIALES, numeroProductos, pagado*0,15) • InsertarEnTabla(COMISIONES, vendedor, pagado*0,1) • } • Quién hace qué? • Evidentemente, las tablas de datos deben estar en el servidor para que diferentes tiendas puedan compartirlas (servicio de BBDD) • Evidentemente, en el cliente hay una GUI que permite al vendedor introducir su identificador, el número de productos vendidos y el coste por producto pactado • ¿Quién implementa la lógica de negocio? • ¿Qué pinta tiene el protocolo de nivel de aplicación que necesitamos? • Ambas respuestas están muy relacionadas

  17. Tema IV: El paradigma Cliente-Servidor Ejemplos de aplicaciones cliente/servidor • Solución 1: El servidor proporciona al cliente un servicio para hacer operaciones • InsertarEnTabla(tabla, columna, valor) • BorrarDeLaTabla(tabla, comuna, valor) • Se define un protocolo de petición-respuesta para implementarlo • Solución 2: El servidor proporciona al cliente un servicio para hacer operaciones • ActualizarVenta(vendedor, numeroProductos, costePorProducto) • Se define un protocolo de petición-respuesta para implementarlo • Puede haber muchas otras soluciones intermedias • Solución 1: • ¿Donde reside la lógica de negocio, en el cliente o en el servidor? • Solución 2: • ¿Dónde reside la lógica de negocio, en el cliente o en el servidor?

  18. Tema IV: El paradigma Cliente-Servidor Clientes gordos, flacos e híbridos • Decimos que un cliente es • Flaco (thin) • Cuando no implementa en absoluto la lógica de la aplicación • Es un mero intermediario entre el usuario y el servidor • Requiere muy pocos recursos hardware • Gordo (thick, fat) • Cuando implementa la mayor parte de la lógica de la aplicación • Procesa la información del usuario antes de comunicar con el servidor • Requiere capacidad de proceso y, normalmente, capacidad de almacenamiento • Híbrido (hybrid) • Implementa una parte de la lógica de aplicación • Si optamos por una arquitectura basada en un cliente flaco/híbrido • El servidor será más complicado • Si optamos por una arquitectura basada en un cliente gordo • El servidor será más sencillo Este modelo es el que se está imponiendo. ¿Por qué?

  19. Tema IV: El paradigma Cliente-Servidor Servidores con estados y sin estados • Dependiendo de si la lógica de la aplicación reside en el cliente o en el servidor y de la propia naturaleza de la aplicación • Puede ser que el servidor no requiera “recordar” la historia pasada del cliente • Puede ser que el servidor deba “recordar” todo o parte del pasado del cliente • Cuando el servidor requiere “recordar” se dice que es con estados • Cuando el servidor no requiere “recordar” se dice que es sin estados • Ejemplos • Servicio Web clásico: Es sin estados, para servir un fichero basta con el mensaje de petición en curso, no se necesita nada del pasado • Comercio electrónico web con carro de la compra: Es con estados, hace falta conocer lo que el usuario ha comprado en la última sesión • Los servidores sin estados son mucho más sencillos de desarrollar • Los servidores con estados son mucho más complejos • Un servidor con estados, en sentido estricto, debe contener un modelo (en forma de máquina de estados) por cada uno de los clientes que se conectan • Pueden existir modelos híbridos en los que el servidor guarda cierto estado del cliente, pero sin llegar a disponer de un modelo completo

  20. Tema IV: El paradigma Cliente-Servidor Servidores con estados y sin estados • Ejemplo: Servidor transaccional para gestión de agencias de viajes • Imaginemos que la especificación se simplifica del modo siguiente: • Tenemos una BD de vuelos que controla • Qué vuelos hay (con horario, compañía, etc) • Cuantas plazas disponibles quedan en cada vuelo • Tenemos un BD de hoteles que controla • Qué hoteles hay • Cuantas habitaciones disponibles hay en cada hotel y día • La aplicación debe ofrecer las funcionalidades siguientes • Debe permitir visualizar la disponibilidad de vuelos y hoteles • Debe permitir la definición de paquetes de viajes compuestos por varios vuelos diferentes y por varias estancias en hoteles diferentes • Debe gestionar los problemas asociados a las reservas • Ejemplo de problema típico: • Viaje: Madrid, París (hotel 2 días), Roma (hotel 2 días), Madrid • Chequeamos disponibilidad de hoteles y vuelos • En el momento de reservar, alguien se adelanta y toma la última habitación en el hotel de Roma

  21. Tema IV: El paradigma Cliente-Servidor Servidores con estados y sin estados • Ejemplo: Servidor sin estados CLIENTE SERVIDOR Dime Aviones Disponibles Dime Hoteles Disponibles Mensaje de otra agencia El viajero elige Reserva Avión Madrid-Paris Reserva Hotel Roma Reserva Hotel París Toma la última habitación Reserva Avión París-Roma Reserva Hotel Roma NO DISPONIBLE Hay que anular Anula reserva Avión París-Roma Anula reserva Hotel París Anula reserva Avión Madríd-París

  22. Tema IV: El paradigma Cliente-Servidor Servidores con estados y sin estados • Ejemplo: Servidor con estados CLIENTE SERVIDOR Dime Aviones Disponibles Dime Hoteles Disponibles Mensaje de otra agencia El viajero elige Comienza transacción T Reserva Hotel Roma Toma la última habitación T: Reserva Avión Madrid-Paris T: Reserva Hotel París T: Reserva Avión París-Roma T: Reserva Hotel Roma NO DISPONIBLE Hay que anular Anula transacción T El servidor debe recordar todo lo que hizo el cliente en la transacción T ANULADO

  23. Tema IV: El paradigma Cliente-Servidor Lección 4.3: Mecanismos de caché 4.1: El paradigma cliente-servidor 4.2: Clientes y servidores 4.3: Mecanismos de caché en la arquitectura cliente-servidor 4.4: Desarrollo de clientes y servidores 4.5: Modelos cliente servidor multinivel 4.6: Modelo cliente/servidor en la web: Java Servlets

  24. Tema IV: El paradigma Cliente-Servidor Mecanismos de Caché • El mecanismo de caché, en el contexto de las redes de ordenadores, consiste en duplicar (una parte de) los datos que posee un nodo, en otro distinto del original, con el objetivo de mejorar las prestaciones del acceso a los mismos • Las cachés son un elemento esencial de las aplicaciones cliente-servidor • Para comprender el funcionamiento de una caché observemos lo siguiente: • La caché es un repositorio de información que debe encontrarse localizado entre el cliente y el servidor. Es decir, debe poder “ver” e interceptar los mensajes que se intercambian clientes caché servidor

  25. Tema IV: El paradigma Cliente-Servidor Mecanismos de Caché • El mecanismo de caché, en el contexto de las redes de ordenadores, consiste en duplicar (una parte de) los datos que posee un nodo, en otro distinto del original, con el objetivo de mejorar las prestaciones del acceso a los mismos • Las cachés son un elemento esencial de las aplicaciones cliente-servidor • Para comprender el funcionamiento de una caché observemos lo siguiente: • La primera vez que el cliente solicita la información, esta se descarga desde el servidor, pero la caché se “guarda” una copia clientes caché servidor

  26. Tema IV: El paradigma Cliente-Servidor Mecanismos de Caché • El mecanismo de caché, en el contexto de las redes de ordenadores, consiste en duplicar (una parte de) los datos que posee un nodo, en otro distinto del original, con el objetivo de mejorar las prestaciones del acceso a los mismos • Las cachés son un elemento esencial de las aplicaciones cliente-servidor • Para comprender el funcionamiento de una caché observemos lo siguiente: • Si la caché “ve” alguna petición de un cliente que solicita una información que ella posee, intercepta la petición y responde a ella “como si” fuese el servidor. En caso contrario, deja pasar la petición sin alterarla clientes caché servidor

  27. Tema IV: El paradigma Cliente-Servidor ¿Por qué la caché mejora la eficiencia? • Mejora en términos de latencia • Escenario: t1 = Latencia cliente-caché, t2 = Latencia caché-servidor • Descarga de servidor (proceso inmediato): TServ = t1 + t2 + t2 + t1 = 2(t1+t2) • Descarga de caché (proceso inmediato): TCache = t1 + t1 = 2t1 • La descarga desde la caché siempre tiene latencia de comunicación menor • Mejora en términos de ancho de banda/tiempo de servicio • Escenario: Fichero de 1G, 100 clientes que comparten la misma caché • Sin caché: el servidor proporciona 100G bytes de datos a través de su línea • Con caché: el servidor proporciona 1G byte de datos a través de su línea • Mejora en términos de escalabilidad • Parte del trabajo del servidor la hace la caché: el servidor soporta más clientes • En general, la presencia de un sistema de caché permite que el cliente tenga “la respuesta” a sus peticiones de manera mucho más rápida

  28. Tema IV: El paradigma Cliente-Servidor Mecanismos de caché eficientes • ¿Qué parámetros mejoran el rendimiento de una caché? • Cuanto más próxima está la caché al cliente, mejores son sus prestaciones • Cuanto más pequeño es t1 en relación a t2, mayor será la mejora en tiempo • Cuantos mayor sea el tamaño de la caché, mayor número de hits tendremos • Si la caché es pequeña, se podrán almacenar pocos recursos y la probabilidad de que un cliente solicite un recurso en ella contenido será menor • Cuanto menor sea la dispersión de los datos solicitados, más hits tendremos • Si todos los clientes solicitan el mismo recurso, siempre habrá hits. Si los recursos que solicitan los clientes son muy heterogéneos, menor número de hits tendremos • ¿Cómo influye el hecho de que los datos originales cambien?

  29. Tema IV: El paradigma Cliente-Servidor Coherencia de datos en sistemas de caché • El mecanismo de caché que hemos descrito funciona siempre y cuando los datos sean estáticos (no cambien), pero esta suposición no siempre es correcta • Imaginemos que el recurso es una página web que indica: • Índices bursátiles • Disponibilidad de plazas en un vuelo • ¿Cómo se puede garantizar que los datos de la caché (la copia) y los del servidor (los originales) son los mismos? • Mecanismo 1 • Cada recurso se entrega junto con un tiempo de caducidad. El servidor garantiza que el recurso no cambia en ese tiempo. Al agotarse se borra el recurso de la caché • Mecanismo 2 • Por cada petición que recibe, la caché pregunta al servidor ¿estos datos han cambiado? • Mecanismo 3 • Cada vez que un dato cambia en el servidor, éste informa a todas las cachés que lo poseen diciendo “tal dato ha dejado de ser válido” y las cachés lo borran • Mecanismo 4 • Cada vez que un dato cambia en el servidor, éste informa a todas las cachés que lo poseen diciendo “tal dato ha cambiado, aquí tienes su nuevo valor”

  30. Tema IV: El paradigma Cliente-Servidor Mecanismos de caché en HTTP • Habitualmente, en los sistemas clientes-servidor, cada cliente tiene su propia caché localizada en el nodo en el que reside y bajo su control • Los navegadores web no son una excepción y disponen de este mecanismo • HTTP 1.1 ofrece soporte para que los navegadores controlen la consistencia de sus cachés (RFC 2619) . También hay soporte para cachés intermedias • Los detalles son complejos y tienen una casuística grande • Están implicados numerosos campos de la cabecera HTTP 1.1: • Age, Expires, Date, Etag, Last-Modified, If-Modified-Since, If-Match, etc • La consistencia se logra a través de dos mecanismos complementarios • Un mecanismo de expiración de recursos • El servidor proporciona un tiempo de vida a cada recurso • Mientras el recurso está “fresco”, se sirve de la caché • Si el recurso caduca, hay que validarlo • Permite disponer del recurso sin lanzar nuevas peticiones • Un mecanismo de validación • Para recursos caducados o sin información de caducidad • Permite validar el recurso sin necesidad de volverlo a descargar

  31. Tema IV: El paradigma Cliente-Servidor Expiración de recursos en HTTP 1.1 GET recurso HTTP/1.1 ... GET recurso HTTP/1.1 ... 200 OK Expires: tCaduc ... 200 OK Expires: tCaduc ... GET recurso HTTP/1.1 ... if (now() < tCaduc) recurso es válido else recurso es inválido 200 OK Expires: tCaduc ... caché clientes Servidor

  32. Tema IV: El paradigma Cliente-Servidor Validación de recursos en HTTP 1.1 GET recurso HTTP/1.1 ... GET recurso HTTP/1.1 ... 200 OK Date: tRespuesta Etag: 4ad4dx23 ... 200 OK Date: tReespuesta Etag: 4ad4dx23 ... GET recurso HTTP/1.1 If-Modified … If-None … ... No hay información de caducidad Se utiliza la validación GET recurso HTTP/1.1 If-Modified-Since: tRespuesta If-None-Match: 4ad4dx23 ... 304 Not modified Etag: 4ad4dx23 ... 200 OK Date: tRespuesta Etag: 4ad4dx23 ... caché clientes Servidor

  33. Tema IV: El paradigma Cliente-Servidor Lección 4.4: Desarrollo de clientes y servidores 4.1: El paradigma cliente-servidor 4.2: Clientes y servidores 4.3: Mecanismos de caché en la arquitectura cliente-servidor 4.4: Desarrollo de clientes y servidores 4.5: Modelos cliente servidor multinivel 4.6: Modelo cliente/servidor en la web: Java Servlets

  34. Tema IV: El paradigma Cliente-Servidor Desarrollo de clientes y servidores • El desarrollo de un cliente puede ser complicado si requiere una GUI compleja o tiene una lógica de negocio difícil. Ambos aspectos están fuera de esta asignatura • Desde el punto de vista de las comunicaciones, lo esencial sobre el cliente ya lo hemos tratado en temas anteriores (sockets, aplanamiento, formatos, etc.) • El servidor, sin embargo, además de implementar el servicio de comunicaciones, debe ser diseñado con objetivos de escalabilidad en mente • Un servidor tanto más útil cuantos más clientes lo comparten • ¿Cómo podemos lograr que muchos clientes compartan un mismo servidor? • Hay muchas soluciones, las más habituales son • Usar un modelo de servidor multihilo • Usa operaciones de comunicaciones (sockets) bloqueantes • El desarrollo del servidor es más intuitivo • La mayor complejidad viene de la necesidad del control de concurrencia • Usar un modelo de servidor basado en eventos • Usa operaciones de comunicaciones (sockets) no bloqueantes • El desarrollo es más enrevesado • Nos libramos del control de concurrencia y de los múltiples hilos

  35. Tema IV: El paradigma Cliente-Servidor Modelo conceptual de un servidor iterativo Inicio del servidor Crear serverSocket Llamada bloqueante Bucle infinito socket = serverSocket.accept() Leer mensaje del socket Procesar mensaje Enviar respuesta por el socket

  36. Tema IV: El paradigma Cliente-Servidor Esqueleto en código de un servidor iterativo public class IterativeServer { public static void main(String[] args) throws IOException { new IterativeServer().launchServer(2345); } private void launchServer(int serverPort) throws IOException { ServerSocket serverSocket = new ServerSocket(serverPort); while(true){ Socket socket = serverSocket.accept(); RequestMessage request = readRequest(socket); ResponseMessage response = process(request); sendResponse(socket, response); //... socket.close(); } } private RequestMessage readRequest(Socket socket) throws IOException { BufferedReader br = new BufferedReader(new InputStreamReader(socket.getInputStream())); RequestMessage request = new RequestMessage(); request.setMessage(br.readLine()); //System.out.println(request.getMessage()); return request; } private ResponseMessage process(RequestMessage request) { ResponseMessage response = new ResponseMessage(); response.setMessage(request.getMessage().toUpperCase()); return response; } private void sendResponse(Socket socket, ResponseMessage response) throws IOException { PrintWriter pw = new PrintWriter(socket.getOutputStream()); pw.println(response.getMessage()); pw.flush(); } }

  37. Tema IV: El paradigma Cliente-Servidor Tiempo útil en el servidor iterativo Servidor Iterativo Hilo en ejecución Hilo bloqueado (I/O) Todo el tiempo de espera por operaciones de entrada/salida se desperdicia (no es aprovechado para el procesamiento de ninguna petición de clientes) Tiempo

  38. Tema IV: El paradigma Cliente-Servidor Modelo conceptual de un servidor multihilo Inicio del servidor Llamada bloqueante Bucle infinito socket = serverSocket.accept() Cada sesión TCP del protocolo se atiende en un hilo de ejecución diferente lanzaThread(socket) m = leerMensaje() m = leerMensaje() m = leerMensaje() procesar(m) procesar(m) procesar(m) enviarRespuesta() enviarRespuesta() enviarRespuesta()

  39. Tema IV: El paradigma Cliente-Servidor Esqueleto en código de un servidor multihilo public class ConcurrentServer { public static void main(String[] args) throws Exception { ConcurrentServer server = new ConcurrentServer(); server.launchServer(Integer.parseInt(args[0])); } private ServerSocket serverSocket; private void launchServer(int serverPort) throws Exception { serverSocket = new ServerSocket(serverPort); //Bucle infinito de gestión de peticiones en el servidor while(true){ Socket connection = serverSocket.accept(); Handler requestProcessor = new Handler(connection); new Thread(requestProcessor).start(); } } }

  40. Tema IV: El paradigma Cliente-Servidor Esqueleto en código de un servidor multihilo public class Handler implements Runnable { private Socket socket; //Aquí se pueden definir variables de estado de sesión (servidor con estados) public Handler(Socket socket){ this.socket = socket; } public void run(){ try{ RequestMessage request = readRequest(); ResponseMessage response = process(request); sendResponse(response); //La sesión puede continuar con más intercambios socket.close(); } catch(IOException ioe){ //Gestión de errores en la comunicación } } private RequestMessage readRequest(){ //Aquí el código que lee y desaplana el mensaje desde un socket } private void sendResponse(ResponseMessage response){ //Aquí el código que aplana y envía el mensaje por un socket } private ResponseMessage process (RequestMessage request){ //Aquí el código que procesa la petición y genera la respuesta } }

  41. Tema IV: El paradigma Cliente-Servidor Algunos comentarios sobre el servidor multihilo • Problemas asociados al control de concurrencia • El servidor multihilo es un programa concurrente • Pueden aparecer problemas de control de concurrencia si múltiples hilos acceden a datos compartidos (hay interacción entre hilos) • Es necesario detectar cuáles son las secciones críticas • Es necesario implementar mecanismos de control de concurrencia • Problemas asociados a la gestión de hilos • La creación de un nuevo hilo dentro de un proceso es costosa • La destrucción de un hilo dentro de un proceso es costosa • La gestión de muchos hilos (por encima de los centenares) se vuelve muy pesada • Se pueden utilizar un thread-pool para minimizar estos efectos adversos • Los hilos se crean cuando el programa arranca (mejora tiempo de respuesta) • Se asignan los hilos a medida que se van recibiendo tareas • Si hay más tareas que hilos disponibles, algunas tareas deberán esperar

  42. Tema IV: El paradigma Cliente-Servidor Esqueleto en código de un servidor multihilo (pool) import java.util.concurrent.ExecutorService; import java.util.concurrent.Executors; import … public class PooledServer { private static final int NUM_THREADS_IN_POOL = 20; public static void main(String[] args) { new PooledServer().launchServer(Integer.parseInt(args[0])); } private ServerSocket serverSocket; private ExecutorService pool; private void launchServer(int serverPort) { pool = Executors.newFixedThreadPool(NUM_THREADS_IN_POOL); while(true){ try{ Socket connection = serverSocket.accept(); Handler requestProcessor = new Handler(connection); pool.execute(requestProcessor); } catch (IOException ioe){ pool.shutdown(); } } } }

  43. Tema IV: El paradigma Cliente-Servidor Tiempo útil en el servidor multihilo Servidor multihilo Servidor Iterativo Hilo en ejecución Hilo bloqueado (I/O) Cuando un hilo se bloquea por una operación de entrada/salida, el S.O. planifica otro diferente. Se pierde el tiempo asociado a los cambios de contexto y a creación/destrucción de hilos. Tiempo

  44. Tema IV: El paradigma Cliente-Servidor Modelo conceptual de un servidor basado en eventos Inicio del servidor registrar(serverSocket) Llamada bloqueante Bucle infinito evento = selectorEventos() Si evento es de conexión socket = serverSocket.accept() registrar(socket) Si hay errores, gestionarlos Si evento es de lectura socket = evento.getSocket() m = leerMensaje(socket) procesar(m) registrarInteres(socket, WRITE) Si evento es de escritura socket = evento.getSocket() escribirMensaje(socket) ¿eliminarInteres(socket)? ¿cerrar conexión de socket?

  45. Tema IV: El paradigma Cliente-Servidor Esqueleto en código de un servidor basado en eventos public class EventServer { public static void main(String[] args) throws Exception { new EventServer().launchServer(Integer.parseInt(args[0])); } private Selector selector; private ByteBuffer buf = ByteBuffer.allocateDirect(1024);//Se puede elegir otro tamaño private Map<SocketChannel, String> responses = new HashMap<SocketChannel, String>(); private void launchServer(int serverPort) throws Exception { ServerSocketChannel ssChannel = ServerSocketChannel.open(); ssChannel.configureBlocking(false); ssChannel.socket().bind(new InetSocketAddress(serverPort)); selector = Selector.open(); ssChannel.register(selector, SelectionKey.OP_ACCEPT); while(true){ selector.select(); for(SelectionKey key : selector.selectedKeys()){ if(key.isAcceptable()){ processAcceptEvent(key); } else if (key.isReadable()){ processReadEvent(key); } else if (key.isWritable()){ processWriteEvent(key); } } selector.selectedKeys().clear(); } } ...

  46. Tema IV: El paradigma Cliente-Servidor Esqueleto en código de un servidor basado en eventos public class EventServer { ... private void processAcceptEvent(SelectionKey key) throws IOException { ServerSocketChannel ssChannel = (ServerSocketChannel)key.channel(); SocketChannel sChannel = ssChannel.accept(); sChannel.configureBlocking(false); sChannel.register(selector, SelectionKey.OP_READ); } private void processReadEvent(SelectionKey key) throws IOException { SocketChannel channel = (SocketChannel)key.channel(); //Leemos los datos del socket y los metemos en un buffer buf.clear(); int bytesRead = channel.read(buf); if(bytesRead == -1){ //Si estamos aquí la conexión se ha cerrado } //Recuperamos los datos del buffer buf.flip(); byte[] data = new byte[buf.remaining()]; buf.get(data); //Procesamos la petición y creamos la respuesta String request = new String(data, "ISO-8859-1"); System.out.println("<<<<" + request); responses.put(channel, request.toUpperCase()); key.interestOps(SelectionKey.OP_WRITE); //Interés en evento de escritura } ...

  47. Tema IV: El paradigma Cliente-Servidor Esqueleto en código de un servidor basado en eventos public class EventServer { ... private void processWriteEvent(SelectionKey key) throws Exception { SocketChannel channel = (SocketChannel)key.channel(); //Escribimos la respuesta ya aplanada en el buffer buf.clear(); buf.put(responses.get(channel).getBytes("ISO-8859-1")); buf.flip(); responses.remove(channel); //Enviamos la respuesta el nodo remoto try{ channel.write(buf); key.cancel(); channel.close(); } catch (IOException ioe) { //Si estamos aquí es porque la conexión se ha cerrado //o tiene algún tipo de problema } }

  48. Tema IV: El paradigma Cliente-Servidor Tiempo útil en un servidor basado en eventos Servidor eventos Servidor multihilo Servidor Iterativo Hilo en ejecución Hilo bloqueado (I/O) Todas las operaciones de entrada/salida se gestionan a través del bucle de gestión de eventos (sockets, ficheros, etc) Tiempo

  49. Tema IV: El paradigma Cliente-Servidor Lección 4.5: Modelos multinivel 4.1: El paradigma cliente-servidor 4.2: Clientes y servidores 4.3: Mecanismos de caché en la arquitectura cliente-servidor 4.4: Desarrollo de clientes y servidores 4.5: Modelos cliente servidor multinivel 4.6: Modelo cliente/servidor en la web: Java Servlets

  50. Tema IV: El paradigma Cliente-Servidor Modelos cliente-servidor en múltiples niveles • El modelo tradicional cliente-servidor se denomina también modelo en dos niveles • La experiencia muestra que el modelo en dos niveles • Presenta problemas de escalabilidad • Un servidor que deba implementar una lógica de negocio compleja o que proporcione servicios de acceso a grandes bases de datos presenta problemas de escalabilidad a partir de los centenares de clientes • Es rígido a la hora de introducir modificaciones sobre la lógica de la aplicación • Cambios en el reparto de las tareas asociadas a la lógica de la aplicación suponen cientos/miles/millones de actualizaciones de clientes • Dificulta la evolución del servidor (al estar íntimamente ligado al cliente) • Por ese motivo, a mediados de los 90 surgió un modelo arquitectural de 3 niveles • Nivel cliente: Que implementa esencialmente la interfaz de usuario • Nivel intermedio: Middle tier o middleware • Nivel servidor: Que se reparte con el nivel intermedio la lógica de negocio y los servicios, dependiendo del modelo arquitectural que se elija

More Related