Successfully reported this slideshow.

Cliente servidor

6,914 views

Published on

calzada meza

Published in: Education
  • Be the first to comment

Cliente servidor

  1. 1. CLIENTE SERVIDOR<br />Alumno: Calzada meza, José Antonio<br />Tema: Cliente Servidor<br />
  2. 2. Tema I:<br />EL PARADIGMA CLIENTE SERVIDOR<br />
  3. 3. EL PARADIGMA CLIENTE SERVIDOR<br />En la práctica el esquema de programación mas utilizado para la implementación de aplicaciones distribuidas es el paradigma cliente - servidor. La motivación fundamental para el empleo del paradigma cliente - servidor surge del problema del rendezvous.<br /> Para entender dicho problema, imaginemos un técnico de computadoras que inicia la ejecución de dos programas en máquinas distintas y que tiene la intención de que dichos programas puedan comunicar entre sí. <br />Una vez iniciado el primer programa este envía un mensaje a su contertulio. La conexión con la maquina a la cual va dirigido el mensaje se puede establecer en un intervalo de unos pocos milisegundos (recordar que las computadoras funcionan a velocidades muchos ordenes de magnitud por encima de los humanos), por lo que el proceso recién lanzado determina que su contertulio todavía no existe, con lo cual emite un mensaje de error y finaliza su ejecución. <br />
  4. 4. El paradigma cliente-servidor como abstracción<br />El modelo de paso de mensajes<br />No especifica cómo se sincronizan los procesos<br />No especifica cuantos tipos de procesos comunican<br />No especifica el protocolo (diálogo) a seguir entre los procesos<br />El paradigma cliente-servidor es una abstracción del modelo de paso de mensajes<br />Especifica cómo se sincronizan los procesos: el servidor espera de forma pasiva la llegada de peticiones de clientes<br />Especifica que hay dos tipos de procesos y sus roles: servidores y clientes<br />Especifica el modelo de diálogo basado en petición-respuesta<br />Restringirnos al modelo cliente-servidor, limita lo que podemos hacer con una aplicación distribuida, pero abstrae algunos de los problemas asociados al IPC<br />Al desarrollar con APIs cliente-servidor (i.e.servlets) se percibe esa abstracción<br />
  5. 5. El paradigma cliente-servidor como arquitectura software<br />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í”<br />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<br />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<br />petición-respuesta<br />Este patrón arquitectural puede aplicarse al diseño de aplicaciones distribuidas en múltiples niveles de abstracción<br />
  6. 6. El paradigma cliente-servidor como arquitectura software<br />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<br />La interacción entre el cliente y el servidor es síncrona<br />El servidor<br />Es pasivo, espera las peticiones de los clientes<br />Cuando recibe peticiones, debe procesarlas y ofrecer una respuesta<br />Suele ser diseñado con objetivos de eficiencia<br />El cliente<br />Es activo, tiene la iniciativa de iniciar el diálogo con el servidor enviando peticiones<br />Por cada petición enviada, se debe obtener una respuesta<br />Suele ser diseñado con el objetivo de interaccionar con el usuario final<br />
  7. 7. El paradigma cliente-servidor como arquitectura de sistema<br />Un sistema distribuido está compuesto por Nodos de procesamiento (ordenadores)<br />Infraestructuras de comunicaciones (red)<br />En muchas ocasiones se eligen características específicas sobre los nodos de procesamiento en términos de hardware, sistema operativo, prestaciones, etc.<br />Estas características dependen del papel que el nodo esté destinado a representar<br />En muchas ocasiones, los ordenadores que están destinados a almacenar procesos<br />servidor (desde el punto de vista de arquitectura software) también son denominados servidores ellos mismos<br />En este caso, por tanto, la palabra servidor se refiere a un equipo, no a un proceso<br />
  8. 8. Tema II:<br />CLIENTE - SERVIDOR<br />
  9. 9. CLIENTE - SERVIDOR<br />TCP es un protocolo orientado a conexión. No hay relaciones maestro/esclavo. Las aplicaciones, sin embargo, utilizan un modelo cliente/servidor en las comunicaciones. Un servidor es una aplicación que ofrece un servicio a usuarios de Internet; un cliente es el que pide ese servicio. Una aplicación consta de una parte de servidor y una de cliente, que se pueden ejecutar en el mismo o en diferentes sistemas. <br />Los usuarios invocan la parte cliente de la aplicación, que construye una solicitud para ese servicio y se la envía al servidor de la aplicación que usa TCP/IP como transporte. <br />El servidor es un programa que recibe una solicitud, realiza el servicio requerido y devuelve los resultados en forma de una respuesta. Generalmente un servidor puede tratar múltiples peticiones(múltiples clientes) al mismo tiempo. <br />
  10. 10. CLIENTE - SERVIDOR<br />Algunos servidores esperan las solicitudes en puertos bien conocidos de modo que sus clientes saben a que zócalo IP deben dirigir sus peticiones. El cliente emplea un puerto arbitrario para comunicarse. Los clientes que se quieren comunicar con un servidor que no usa un puerto bien conocido tienen otro mecanismo para saber a qué puerto dirigirse. Este mecanismo podría usar un servicio de registro como Portmap, que utiliza un puerto bien conocido.<br />
  11. 11. Clientes y servidores: quién hace qué?<br />Las aplicaciones distribuidas existen para ofrecer unas funcionalidades al usuario<br />La arquitectura abstracta de una aplicación distribuida cliente-servidor es siempre<br />Capa de presentación<br />Suele residir en el cliente<br />El servidor puede tener funcionalidades de presentación menores<br />Lógica de negocio:<br />Puede residir en el servidor<br />Puede residir en el cliente<br />Puede residir parte en el cliente y parte en el servidor<br />Capa de servicios:<br />Es compartida, aunque suele tener más peso en el servidor<br />
  12. 12. Ejemplos de aplicaciones cliente/servidor<br />La capa de presentación requiere, entre otros:<br />Capacidad para representar documentos HTML C<br />Capacidad para representar imágenes en diferentes formatos C<br />Capacidad para representar e interpretar otros tipos datos (pdf, applets, etc.) C<br />La lógica de la aplicación requiere, entre otros:<br />No hay mucha lógica de negocio en un servidor/cliente web clásico<br />¿Hay algo en un cliente o en un servidor web que no tenga que ver con<br />Presentar los datos<br />Proporcionar un servicio de lectura/codificación/envío de ficheros?<br />La capa de servicios debe proporcionar, entre otros<br />La implementación del protocolo HTTP<br />Capacidad de acceder a ficheros identificados por un path HTTP S<br />Comprimir y descomprimir un fichero (si se soporta el encodinggzip) C<br />
  13. 13. Ejemplos de aplicaciones cliente/servidor<br />Lógica de negocio en pseudocódigo<br />VENTA (vendedor, numeroProductos, costeProducto){<br />pagado = numeroProductos*costeProducto<br />ingresos = pagado – pagado*0,1 – pagado*0,15<br />InsertarEnTabla(TESORERIA, ingresos)<br />BorrarDeTabla(INVENTARIO, numeroProductos)<br />InsertarTabla(MATERIALES, numeroProductos, pagado*0,15)<br />InsertarEnTabla(COMISIONES, vendedor, pagado*0,1)}<br />Quién hace qué?<br />Evidentemente, las tablas de datos deben estar en el servidor para que<br />diferentes tiendas puedan compartirlas (servicio de BBDD)<br />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<br />¿Quién implementa la lógica de negocio?<br />¿Qué pinta tiene el protocolo de nivel de aplicación que necesitamos?<br />•Ambas respuestas están muy relacionadas<br />
  14. 14. Ejemplos de aplicaciones cliente/servidor<br />Solución 1: El servidor proporciona al cliente un servicio para hacer operaciones<br />InsertarEnTabla(tabla, columna, valor)<br />BorrarDeLaTabla(tabla, comuna, valor)<br />Se define un protocolo de petición-respuesta para implementarlo<br />Solución 2: El servidor proporciona al cliente un servicio para hacer operaciones<br />ActualizarVenta(vendedor, numeroProductos, costePorProducto)<br />Se define un protocolo de petición-respuesta para implementarlo<br />Puede haber muchas otras soluciones intermedias<br />Solución 1:<br />¿Donde reside la lógica de negocio, en el cliente o en el servidor?<br />Solución 2:<br />¿Dónde reside la lógica de negocio, en el cliente o en el servidor?<br />
  15. 15. Clientes gordos, flacos e híbridos<br />Decimos que un cliente es<br />Flaco (thin)<br />Cuando no implementa en absoluto la lógica de la aplicación<br />Es un mero intermediario entre el usuario y el servidor<br />Requiere muy pocos recursos hardware<br />Gordo (thick, fat)<br />Cuando implementa la mayor parte de la lógica de la aplicación<br />Procesa la información del usuario antes de comunicar con el servidor<br />Requiere capacidad de proceso y, normalmente, capacidad de almacenamiento<br />Híbrido (hybrid)<br />Implementa una parte de la lógica de aplicación<br />Si optamos por una arquitectura basada en un cliente flaco/híbrido<br />El servidor será más complicado <br />Si optamos por una arquitectura basada en un cliente gordo<br />El servidor será más sencillo<br />
  16. 16. Servidores con estados y sin estados<br />
  17. 17. Servidores con estados y sin estados<br />
  18. 18. Tema III:<br />Mecanismos de caché en la arquitectura cliente-servidor<br />
  19. 19. Mecanismos de Caché<br />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<br />Las cachés son un elemento esencial de las aplicaciones cliente-servidor<br />Para comprender el funcionamiento de una caché observemos lo siguiente:<br />
  20. 20. Mecanismos de Caché<br />
  21. 21. Mecanismos de Caché<br />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<br />Las cachés son un elemento esencial de las aplicaciones cliente-servidor<br />Para comprender el funcionamiento de una caché observemos lo siguiente:<br />
  22. 22. Mecanismos de Caché<br />El mecanismo de caché, en el contexto de las redes de ordenadores, consiste en<br />duplicar (una parte de) los datos que posee un nodo, en otro distinto del original,<br />con el objetivo de mejorar las prestaciones del acceso a los mismos<br />Las cachés son un elemento esencial de las aplicaciones cliente-servidor<br />Para comprender el funcionamiento de una caché observemos lo siguiente:<br />
  23. 23. ¿Por qué la caché mejora la eficiencia?<br />Mejora en términos de latencia<br />Escenario: t1 = Latencia cliente-caché, t2 = Latencia caché-servidor<br />Descarga de servidor (proceso inmediato): TServ = t1 + t2 + t2 + t1 = 2(t1+t2)<br />Descarga de caché (proceso inmediato): TCache = t1 + t1 = 2t1<br />La descarga desde la caché siempre tiene latencia de comunicación menor<br />Mejora en términos de ancho de banda/tiempo de servicio<br />Escenario: Fichero de 1G, 100 clientes que comparten la misma caché<br />Sin caché: el servidor proporciona 100G bytes de datos a través de su línea<br />Con caché: el servidor proporciona 1G byte de datos a través de su línea<br />Mejora en términos de escalabilidad<br />Parte del trabajo del servidor la hace la caché: el servidor soporta más clientes<br />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<br />

×