CLIENTE SERVIDOR

Alumno: Calzada meza, José AntonioTema: Cliente Servidor

TEMA I:EL PARADIGMA CLIENTE SERVIDOR

EL PARADIGMA CLIENTE SERVIDOR

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.

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

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.

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

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

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

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

TEMA II:CLIENTE - SERVIDOR

CLIENTE - SERVIDOR 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.

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.

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.

CLIENTE - SERVIDOR 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.

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

EJEMPLOS DE APLICACIONES CLIENTE/SERVIDOR La capa de presentación requiere, entre otros: Capacidad para representar documentos HTML C Capacidad para representar imágenes en diferentes formatos C Capacidad para representar e interpretar otros tipos datos (pdf,

applets, etc.) C 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 S Comprimir y descomprimir un fichero (si se soporta el encoding

gzip) C

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

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?

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

SERVIDORES CON ESTADOS Y SIN ESTADOS

SERVIDORES CON ESTADOS Y SIN ESTADOS

TEMA III:Mecanismos de caché en la arquitectura 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:

MECANISMOS DE CACHÉ

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:

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:

¿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