La descarga está en progreso. Por favor, espere

La descarga está en progreso. Por favor, espere

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

Presentaciones similares


Presentación del tema: "Tema IV: El Paradigma Cliente-Servidor Luis López Fernández."— Transcripción de la presentación:

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 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 El paradigma Cliente-Servidor

5 Tema IV: El paradigma Cliente-Servidor 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 abstracción Hardware Modelo OSI, modelo TCP/IP Paso de mensajes Cliente-servidor RPC y RMI Servicios de red, ORB

6 Tema IV: El paradigma Cliente-Servidor 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 Hardware Modelo OSI, modelo TCP/IP Paso de mensajes Cliente-servidor RPC y RMI Servicios de red, ORB Patrón arquitectural pliente-servidor Patrón arquitectural peer-to-peer

7 Tema IV: El paradigma Cliente-Servidor 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 software ServidorCliente petición respuesta

8 Tema IV: El paradigma Cliente-Servidor 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. El paradigma cliente-servidor como patrón de protocolo

9 Tema IV: El paradigma Cliente-Servidor 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 El paradigma cliente-servidor como arquitectura de sistema 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 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 Clientes y Servidores

12 Tema IV: El paradigma Cliente-Servidor 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 Clientes y servidores: quién hace qué? Lógica de la aplicación/negocio Capa de Servicios Capa de presentación

13 Tema IV: El paradigma 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) Ejemplos de aplicaciones cliente/servidor C S C C C C S S

14 Tema IV: El paradigma 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 Ejemplos de aplicaciones cliente/servidor C C C C S S S S S S S S

15 Tema IV: El paradigma 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 Ejemplos de aplicaciones cliente/servidor

16 Tema IV: El paradigma 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

17 Tema IV: El paradigma 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? Ejemplos de aplicaciones cliente/servidor

18 Tema IV: El paradigma Cliente-Servidor 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 Clientes gordos, flacos e híbridos Este modelo es el que se está imponiendo. ¿Por qué?

19 Tema IV: El paradigma Cliente-Servidor 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 Servidores con estados y sin estados

20 Tema IV: El paradigma Cliente-Servidor 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 Servidores con estados y sin estados

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

22 Tema IV: El paradigma Cliente-Servidor Ejemplo: Servidor con estados Servidores con estados y sin estados Dime Aviones Disponibles Dime Hoteles Disponibles T: Reserva Avión Madrid-Paris T: Reserva Hotel París T: Reserva Avión París-Roma T: Reserva Hotel Roma NO DISPONIBLE Reserva Hotel Roma Toma la última habitación El viajero elige Mensaje de otra agencia Hay que anular CLIENTESERVIDOR Comienza transacción T 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 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 Mecanismos de Caché caché clientes servidor

25 Tema IV: El paradigma Cliente-Servidor 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 Mecanismos de Caché caché clientes servidor

26 Tema IV: El paradigma Cliente-Servidor 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 Mecanismos de Caché caché clientes servidor

27 Tema IV: El paradigma Cliente-Servidor 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 ¿Por qué la caché mejora la eficiencia?

28 Tema IV: El paradigma Cliente-Servidor ¿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? Mecanismos de caché eficientes

29 Tema IV: El paradigma Cliente-Servidor 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 Coherencia de datos en sistemas de caché

30 Tema IV: El paradigma Cliente-Servidor 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 Mecanismos de caché en HTTP

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

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

35 Tema IV: El paradigma Cliente-Servidor Modelo conceptual de un servidor iterativo Llamada bloqueante Bucle infinito Inicio del servidor Crear serverSocket socket = serverSocket.accept() Procesar mensaje Leer mensaje del socket 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 Hilo en ejecución Hilo bloqueado (I/O) Tiempo Servidor Iterativo Todo el tiempo de espera por operaciones de entrada/salida se desperdicia (no es aprovechado para el procesamiento de ninguna petición de clientes)

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

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 Hilo en ejecución Hilo bloqueado (I/O) Tiempo Servidor Iterativo Servidor multihilo 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.

44 Tema IV: El paradigma Cliente-Servidor Modelo conceptual de un servidor basado en eventos Bucle infinito Inicio del servidor registrar(serverSocket) evento = selectorEventos() Llamada bloqueante Si evento es de lectura Si evento es de conexión Si evento es de escritura socket = serverSocket.accept() registrar(socket) Si hay errores, gestionarlos socket = evento.getSocket() m = leerMensaje(socket) procesar(m) registrarInteres(socket, WRITE) 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 responses = new HashMap (); 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 "); 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 ")); 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 Hilo en ejecución Hilo bloqueado (I/O) Tiempo Servidor Iterativo Servidor multihilo Servidor eventos Todas las operaciones de entrada/salida se gestionan a través del bucle de gestión de eventos (sockets, ficheros, etc)

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 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 Modelos cliente-servidor en múltiples niveles

51 Tema IV: El paradigma Cliente-Servidor Es un proceso independiente que suele residir en su propio nodo de procesamiento Se ocupa de proporcionar a la aplicación buenas propiedades en cuanto a Flexibilidad: Independizando el cliente y el servidor Escalabilidad: Realizando parte del trabajo del servidor y permitiendo el balanceo de carga entre diferentes servidores Robustez: Permitiendo el uso de servidores replicados Middle tier Nivel Intermedio (Middle tier) Cliente Servidor

52 Tema IV: El paradigma Cliente-Servidor Aparte de las propiedades generales que hemos descrito, el nivel intermedio puede tener asignadas responsabilidades diferentes, con lo podemos clasificar las arquitecturas en tres niveles en los siguientes grupos Nivel intermedio como servidor de aplicaciones El nivel intermedio contiene la lógica de negocio de la aplicación Los clientes suelen ser muy simples (i.e. navegadores web) Nivel intermedio como cola de mensajes El nivel intermedio es un gestor de mensajes asíncronos La arquitectura MOM es un ejemplo de nivel intermedio de este tipo Nivel intermedio como gestor transaccional El nivel intermedio gestiona transacciones entre el cliente y la capa servidora Suele utilizarse en arquitecturas muy orientadas hacia datos Arquitectura basada en ORB Se basa en la introducción de un intermediario que gestiona las peticiones Veremos este tipo de arquitectura en detalle cuando estudiemos CORBA Objetivo y funciones del nivel intermedio

53 Tema IV: El paradigma Cliente-Servidor En los últimos años, la arquitectura en 3 nivele se ha visto generalizada a N En la arquitectura en N niveles, es posible insertar diferentes capas de procesamiento o provisión de servicios entre el cliente los datos de aplicación La inclusión de múltiples niveles tiene un efecto negativo sobre la latencia Las aplicaciones distribuidas basadas en componentes suelen tomar forma de arquitecturas de N niveles Arquitecturas en N niveles Cliente Nivel Intermedio 2 Nivel Intermedio 1 Nivel Intermedio 3 Datos

54 Tema IV: El paradigma Cliente-Servidor Lección 4.6: Java Servlets 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

55 Tema IV: El paradigma Cliente-Servidor La Java Servlet API es una API diseñada para el desarrollo de servidores basados en un protocolo de petición-respuesta Suele utilizarse en el contexto de aplicaciones web (usando HTTP) Permite añadir contenido dinámico sobre los documentos web que se devuelven Hay otras tecnologías de páginas activas similares (PHP, ASP, CGI, etc.) La idea es la misma en todos los casos El cliente (navegador) envía una petición HTTP parametrizada al servidor El servidor ejecuta un programa que utiliza esos parámetros Como resultado de esa ejecución, se obtiene un documento web El documento web es enviado como respuesta al cliente Estas tecnologías son muy utilizadas en el desarrollo de modelos de 3 niveles Cliente: El navegador que contiene la capa de presentación Nivel intermedio: El servlet, que contiene la lógica de la aplicación Nivel de datos: Servidores de BBDD que contienen los datos de la aplicación Los servlets de Java

56 Tema IV: El paradigma Cliente-Servidor HTTP: Funcionamiento básico En el protocolo HTTP hay dos tipos de mensajes Mensajes de petición: Van del cliente al servidor Mensajes de respuesta: Van del servidor al cliente La cabecera de los mensajes va en texto plano (ASCII) Los mensajes tienen siembre el formato siguiente Cabecera (Header) Cuerpo (Body) Línea inicialCRLF Cabecera-X: Valor-XCRLF Cabecera-Y: Valor-YCRLF Cabecera-Z: Valor-ZCRLF Petición: Datos adicionales Respuesta: Recursos solicitados El cuerpo es opcional en ambos casos Mensaje HTTP CR: Carriage Return ASCII 13 LF: Line Feed ASCII 10 Cabeceras opcionales Línea en blanco

57 Tema IV: El paradigma Cliente-Servidor HTTP: Mensajes de petición métodosprecursospversiónCRLFnombre de cabecera :valor de cabeceraCRLF nombre de cabecera :valor de cabeceraCRLF nombre de cabecera :valor de cabeceraCRLF nombre de cabecera :valor de cabeceraCRLF Cuerpo opcional del mensaje de petición Método: HTTP 1.0 GET: Solicita la recuperación de un recurso POST: Solicita un recurso, pero permite que el cliente envíe información adicional al servidor en el cuerpo del mensaje HEAD: Solicita información de un recurso (sin solicitar el recurso en sí) HTTP 1.1 GET, POST, HEAD PUT: Permite subir un recurso desde el cliente hacia el servidor DELETE: Permite borrar un recurso del servidor sp = espacio en blanco CRLF = ASCII-CR (13) + ASCI-LF(10)

58 Tema IV: El paradigma Cliente-Servidor métodosprecursospversiónCRLFnombre de cabecera :valor de cabeceraCRLF nombre de cabecera :valor de cabeceraCRLF nombre de cabecera :valor de cabeceraCRLF nombre de cabecera :valor de cabeceraCRLF Cuerpo opcional del mensaje de petición Recurso: Identificador del recurso sobre el que se realizará la acción. Suele coincidir con la sección path de la URL Ejemplo: /directorio/subdirectorio/fichero.html Para GET: Puede contener la parte query de la URL Ejemplo: /directorio/subdirectorio/script.php?variable=valor De este modo se permite que el cliente envíe información adicional al servidor a través de GET (con POST esta información viaja en el cuerpo del mensaje) HTTP: Mensajes de petición

59 Tema IV: El paradigma Cliente-Servidor HTTP: Mensajes de petición métodosprecursospversiónCRLFnombre de cabecera :valor de cabeceraCRLF nombre de cabecera :valor de cabeceraCRLF nombre de cabecera :valor de cabeceraCRLF nombre de cabecera :valor de cabeceraCRLF Cuerpo opcional del mensaje de petición Versión: Versión del protocolo que se está utilizando en el cliente. En la actualidad sólo existen dos opciones: HTTP/1.0 HTTP/1.1 En general es de la forma HTTP/x.y

60 Tema IV: El paradigma Cliente-Servidor HTTP: Mensajes de petición métodosprecursospversiónCRLFnombre de cabecera :valor de cabeceraCRLF nombre de cabecera :valor de cabeceraCRLF nombre de cabecera :valor de cabeceraCRLF nombre de cabecera :valor de cabeceraCRLF Cuerpo opcional del mensaje de petición Cabeceras: HTTP 1.0 Pueden aparecer 0 o más cabeceras de 16 posibles HTTP 1.1 La cabecera Host es obligatoria en las peticiones Se recomienda incluir la cabecera user-agent Hay 46 cabeceras posibles En todos los casos las cabeceras se expresan en texto ASCII Ejemplo: user-agent: Mozilla/4.07 [es] (Linux i586; Nav)

61 Tema IV: El paradigma Cliente-Servidor HTTP: Mensajes de petición métodosprecursospversiónCRLFnombre de cabecera :valor de cabeceraCRLF nombre de cabecera :valor de cabeceraCRLF nombre de cabecera :valor de cabeceraCRLF nombre de cabecera :valor de cabeceraCRLF Cuerpo opcional del mensaje de petición Cuerpo: GET, HEAD, DELETE: No aparece POST: Permite enviar información adicional al cliente (p.e. de formularios, etc). Esta información suele ir codificada (normamente en formato URLEncoded) nombre=luis&apellidos=l%F3pez+fern%E1ndez PUT: Los ficheros que se suben viajan en el cuerpo del mensaje

62 Tema IV: El paradigma Cliente-Servidor HTTP: Mensajes de respuesta versiónspcódigo de estadospdescripciónCRLF nombre de cabecera :valor de cabeceraCRLF nombre de cabecera :valor de cabeceraCRLF nombre de cabecera :valor de cabeceraCRLF nombre de cabecera :valor de cabeceraCRLF Cuerpo opcional del mensaje de petición Versión: Versión del protocolo que utiliza el servidor. En la actualidad sólo existen dos opciones: HTTP/1.0 HTTP/1.1 Si el servidor soporta ambas, debe contestar, preferentemente, con la versión que haya utilizado el cliente en la petición.

63 Tema IV: El paradigma Cliente-Servidor HTTP: Mensajes de respuesta versiónspcódigo de estadospdescripciónCRLF nombre de cabecera :valor de cabeceraCRLF nombre de cabecera :valor de cabeceraCRLF nombre de cabecera :valor de cabeceraCRLF nombre de cabecera :valor de cabeceraCRLF Cuerpo opcional del mensaje de petición Código de estado y descripción: Código numérico que indica el resultado de la petición. Viene asociado con la descripción, que el un texto descriptivo de ese estado legible por un ser humano. 2xx: Resultado exitoso 3xx: Redirección del cliente a otra URL 4xx: Error en la petición del cliente 5xx: Error en el servidor 200 OK: La petición ha sido atendida con éxito 301 Moved Permanently: El recurso solicitado ha sido trasladado permanentemente 404 Not Found: El recurso solicitado no existe 500 Server Error: Error interno en el servidor (permisos insuficientes, etc.)

64 Tema IV: El paradigma Cliente-Servidor HTTP: Mensajes de respuesta versiónspcódigo de estadospdescripciónCRLF nombre de cabecera :valor de cabeceraCRLF nombre de cabecera :valor de cabeceraCRLF nombre de cabecera :valor de cabeceraCRLF nombre de cabecera :valor de cabeceraCRLF Cuerpo opcional del mensaje de petición Cabeceras (El mismo formato que para las peticiones): HTTP posibilidades HTTP posibilidades Se recomienda incluir las cabeceras Server y Last-Modified

65 Tema IV: El paradigma Cliente-Servidor HTTP: Mensajes de respuesta versiónspcódigo de estadospdescripciónCRLF nombre de cabecera :valor de cabeceraCRLF nombre de cabecera :valor de cabeceraCRLF nombre de cabecera :valor de cabeceraCRLF nombre de cabecera :valor de cabeceraCRLF Cuerpo opcional del mensaje de petición Cuerpo: Dependiendo del método al que se responda, puede estar presente o no. Respuesta a HEAD, DELETE, PUT: Nunca estará presente Respuesta a GET y POST: Será el contenido del recurso solicitado en caso de que no haya error Cuando está presente, se utilizan algunas cabeceras para caracterizar su contenido Conten-Length: Content-Type:

66 Tema IV: El paradigma Cliente-Servidor HTTP: Mensajes de respuesta versiónspcódigo de estadospdescripciónCRLF nombre de cabecera :valor de cabeceraCRLF nombre de cabecera :valor de cabeceraCRLF nombre de cabecera :valor de cabeceraCRLF nombre de cabecera :valor de cabeceraCRLF Cuerpo opcional del mensaje de petición Ejemplo: ________________________________________________________________________ HTTP/ OK Date: Tue, 23 Jan :44:27 GMT Server: Apache/1.3.9 (Unix) Debian/GNU Last-Modified: Tue, 23 Jan :39:45 GMT Content-Length: 34 Content-type: text/html Esto es una prueba __________________________________________________________________

67 Tema IV: El paradigma Cliente-Servidor HTTP en acción: ejemplo básico Internet S.O. Aplicación (navegador web) Aplicación (servidor web) Cliente Servidor Paso 1 El usuario introduce la URL a la que quiere conectarse en el navegador web: Ejemplo:

68 Tema IV: El paradigma Cliente-Servidor HTTP en acción: ejemplo básico Internet S.O. Aplicación (navegador web) Aplicación (servidor web) Cliente Servidor Paso 2 El navegador resuelve el nombre de dominio de la URL indicada y obtiene la dirección IP del servidor en el que se localiza el recurso

69 Tema IV: El paradigma Cliente-Servidor HTTP en acción: ejemplo básico Internet S.O. Aplicación (navegador web) Aplicación (servidor web) Cliente Servidor Paso 3 El navegador crea un socket TCP y lana una conexión entre el mismo y el servidor. Obsérvese que se conocen la direccinó IP y el puerto (80) donde está escuchando el servidor

70 Tema IV: El paradigma Cliente-Servidor HTTP en acción: ejemplo básico Internet S.O. Aplicación (navegador web) Aplicación (servidor web) Cliente Servidor Paso 4 El cliente crea el mensaje HTTP de petición solicitando el recurso deseado y lo envía a través de la conexión GET / HTTP/1.0 User-Agent: Mozilla/8.0

71 Tema IV: El paradigma Cliente-Servidor HTTP en acción: ejemplo básico Internet S.O. Aplicación (navegador web) Aplicación (servidor web) Cliente Servidor Paso 5 El servidor analiza la petición del cliente y recupera el recurso solicitado (normalmente un fichero que se encuentra en el disco o en memoria) GET / HTTP/1.0 User-Agent: Mozilla/8.0

72 Tema IV: El paradigma Cliente-Servidor HTTP en acción: ejemplo básico Internet S.O. Aplicación (navegador web) Aplicación (servidor web) Cliente Servidor Paso 6 El servidor construye el mensaje de respuesta, incluyendo el recurso solicitado en el cuerpo del mensaje (asumimos que no se produce ningún error) HTTP/ OK Server: Apache Content-Type: text/html Content-Length: 8654

73 Tema IV: El paradigma Cliente-Servidor HTTP en acción: ejemplo básico Internet S.O. Aplicación (navegador web) Aplicación (servidor web) Cliente Servidor Paso 7 El servidor envía el mensaje de respuesta al cliente, con el recurso solicitado dentro del cuerpo del mismo HTTP/ OK Server: Apache Content-Type: text/html Content-Length: 8654

74 Tema IV: El paradigma Cliente-Servidor HTTP en acción: ejemplo básico Internet S.O. Aplicación (navegador web) Aplicación (servidor web) Cliente Servidor Paso 8 El cliente recupera el recurso solicitado y cierra la conexión con el servidor. Acto seguido puede representar el recurso como considere oportuno

75 Tema IV: El paradigma Cliente-Servidor Paso de parámetros en las peticiones HTTP Página HTML de prueba Input de texto: Input de password: Checkbox: Radio: Opción: Ordenador Camara de fotos Disco duro DVD Reset: Submit: El lenguaje HTML permite la inclusión de formularios en las páginas web En un formulario, el usuario introduce información sobre la página Cada elemento de información viene identificado por un nombre

76 Tema IV: El paradigma Cliente-Servidor Paso de parámetros en las peticiones HTTP Input de texto: Input de password: Checkbox: Radio: Opción: Ordenador Camara de fotos Disco duro DVD Reset: Submit:

77 Tema IV: El paradigma Cliente-Servidor Paso de parámetros en las peticiones HTTP Input de texto: Input de password: Checkbox: Radio: Opción: Ordenador Camara de fotos Disco duro DVD Reset: Submit:

78 Tema IV: El paradigma Cliente-Servidor Paso de parámetros en las peticiones HTTP Input de texto: Input de password: Checkbox: Radio: Opción: Ordenador Camara de fotos Disco duro DVD Reset: Submit:

79 Tema IV: El paradigma Cliente-Servidor Paso de parámetros en las peticiones HTTP Input de texto: Input de password: Checkbox: Radio: Opción: Ordenador Camara de fotos Disco duro DVD Reset: Submit:

80 Tema IV: El paradigma Cliente-Servidor Paso de parámetros en las peticiones HTTP Input de texto: Input de password: Checkbox: Radio: Opción: Ordenador Camara de fotos Disco duro DVD Reset: Submit:

81 Tema IV: El paradigma Cliente-Servidor Paso de parámetros en las peticiones HTTP Input de texto: Input de password: Checkbox: Radio: Opción: Ordenador Camara de fotos Disco duro DVD Reset: Submit:

82 Tema IV: El paradigma Cliente-Servidor Paso de parámetros en las peticiones HTTP Input de texto: Input de password: Checkbox: Radio: Opción: Ordenador Camara de fotos Disco duro DVD Reset: Submit:

83 Tema IV: El paradigma Cliente-Servidor Rellenamos los campos del formulario y pulsamos sobre Enviar (submit) Paso de parámetros en las peticiones HTTP Input de texto: Input de password: Checkbox: Radio: Opción:... Reset:... Submit:... GET /index.html?nombre=Luis+L%F3pez&clave=rata3&rapido=on&pago=visa&producto=DVD HTTP/1.1 Host: localhost ¿Qué sucede si el método es POST? Parámetros como pares nombre=valor codificados en formato URLEncoded Petición HTTP generada por el navegador al pulsar sobre Enviar POST /index.html HTTP/1.1 Host: localhost Content-type: application/x-www-form-urlencoded Content-length: nombre=Luis+L%F3pez&clave=rata3&rapido=on&pago=visa&producto=DVD HTTP/1.1

84 Tema IV: El paradigma Cliente-Servidor Las páginas activas de servidor: concepto GET /index.html?nombre=Luis+L%F3pez&clave=rata3&rapido=on&pago=visa&producto=DVD HTTP/1.1 Host: localhost Recepción del mensaje de petición Análisis del mensaje + decodificación String nombre=Luis López String clave = rata String producto = DVD Invocación de un procedimiento o método que toma los parámetros …Página dinámica… Codificación + envío de respuesta HTTP/ OK Content-type: text/html Content-length: … … …Página dinámica… Cliente Servidor-Contenedor Página dinámica: ASP, PHP, servlet …

85 Tema IV: El paradigma Cliente-Servidor La API de Servlets de Java es una API que permite escribir páginas activas de servidor utilizando directamente el lenguaje de programación Java Hay dos paquetes fundamentales en esta API: javax.servlet Sirve para escribir páginas activas de servidor con cualquier protocolo de petición respuesta que se base en sockets TCP El aplanamiento/desaplanamiento de los mensajes es responsabilidad del programador se la página activa javax.servlet.http Sirve para escribir páginas activas de servidor bajo HTTP El aplanamiento/desaplanamiento del mensaje HTTP es automático El programador se puede concentrar en el desarrollo de la lógica de negocio Para que la API de sockets pueda funcionar, es necesario un contenedor El contenedor proporciona diferentes servicios esenciales Ejemplos de contenedor: Servlet Containers libres: Apache Tomcat, Jetty, Enhydra, JBoss Servlet Containers propietarios: BEA WebLogic, IBM WebSphere, Oracle A.S. La API de Servlets de Java

86 Tema IV: El paradigma Cliente-Servidor Un servlet HTTP es una clase que extiende javax.servlet.http.HttpServlet El servlet redefine un conjunto de métodos asociados a las peticiones HTTP que pueden recibirse. Normalmente se hace con los métodos doGet(…) y doPost(…) En un contenedor se pueden despegar tantos servlets como se quiera El contenedor proporciona un mecanismo para mapear los nombres de recurso de las peticiones HTTP sobre las clases que deben atender esos recursos El otras tecnologías (PHP, ASP), el mapeo es automático, quedando asociado la página activa con la localización física del recurso en el árbol de directorios Escribiendo servlets HTTP Contenedor RecursoServlet /pag1Serv1 /index.htmlServ2 /cajaServ3 public class Serv1 extends …{ public void doGet(…) {… public void doPost(…) {… public class Serv2 extends …{ public void doGet(…) {… public void doPost(…) {… public class Serv2 extends …{ public void doGet(…) {… public void doPost(…) {… POST /index.html HTTP/1.1 Host: localhost... GET /pag1 HTTP/1.1 Host: localhost

87 Tema IV: El paradigma Cliente-Servidor Escribiendo servlets HTTP Cont. import java.io.*; import javax.servlet.*; import javax.servlet.http.*; public class ExampleServlet extends HttpServlet { public void doGet (HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException{ response.setContentType("text/html"); PrintWriter out = response.getWriter(); out.println(" "); out.println(" Example servlet "); out.println(" "); out.println(" Hola mundo "); out.println(" "); } Servlet HTTP que implementa un Hola mundo Se puede escribir sobre la página de salida utilizando un PrintWriter

88 Tema IV: El paradigma Cliente-Servidor Recuperando parámetros de entrada Input de texto: Input de password: Checkbox: Radio: Opción:... public class LectorParametros extends HttpServlet { public void doGet(HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException { String param1 = request.getParameter("nombre"); String param2 = request.getParameter("clave"); String param3 = request.getParameter("pago"); String param4 = request.getParameter("producto"); PrintWriter pw = response.getWriter(); response.setContentType("text/html"); pw.println("Usted es " + param1 + " "); pw.println("Su clave es " + param2 + " "); pw.println("El pago vale " + param3 + " "); pw.println("El producto es " + param4); }

89 Tema IV: El paradigma Cliente-Servidor HTTP fue diseñado como un protocolo sin estados Esta restricción limita enormemente la viabilidad de uso del protocolo en aplicaciones con lógica compleja A mediados de los 90 Netscape propone un mecanismo para posibilitar el mantenimiento de estado en sesiones HTTP en la RFC 2109 Este mecanismo se extiende y modifica posteriormente en la RFC 2965 La idea básica consiste en utilizar Cookies (galletitas) Se denomina cookie a un conjunto de informaciones de estado susceptibles de viajar en una cabecera HTTP y de ser almacenadas en un fichero de texto Una Cookie se compone de la información siguiente: Un nombre: En forma de cadena de caracteres Un valor: Se utiliza para dotar de unicidad a la sesión Una fecha de expiración: Que indica la caducidad de la cookie Un nombre de recurso: Suele tener forma de path de fichero o directorio Un nombre de dominio: Que suele estar asociado a un servidor Algunos flags adicionales Aplicaciones HTTP con estado

90 Tema IV: El paradigma Cliente-Servidor La RFC 2109 define la cabecera Set-Cookie como mecanismo para que un servidor envíe cookies a un cliente (en mensajes de respuesta HTTP) Formato: Nombre de cabecera: Set-Cookie: Nombre de la cookie y valor que se le asocia: nombre=valor_de_la_cookie Máxima edad de la cookie: Max-Age=segundos Path: path=/el/path Dominio: domain=.el.dominio.com Seguridad: secure o nada Ejemplo: Set-Cookie: shopCCokkie= ; Max-Age=3600; path=/main/shop; domain=my.shop.com; secure La RFC 2965 añade un segundo formato en la cabecera Set-Cookie2 que incorpora informaciones adicionales tales como: puertos que aplican, flag Discard, posibilidad de insertar comentarios de varios tipos, etc. Aun con esas diferencias, el fundamento del mecanismo en ambas RFCs es el mismo, vamos a estudiarlo aplicado a la 2109 por simplicidad La cabecera Set-Cookie

91 Tema IV: El paradigma Cliente-Servidor La cabecera Set-Cookie en funcionamiento Internet S.O. Aplicación (navegador web) Aplicación (servidor web) Inicialmente, el navegador no tiene ninguna cookie almacenada ni en el disco ni en memoria. El usuario introduce una URL a la que quiere conectarse o sigue un hiperenlace: Ejemplo: El navegador crea un paquete HTTP para esa petición y lo envía al servidor correspondiente GET /main/shop/menu.php HTTP/1.1 Host:

92 Tema IV: El paradigma Cliente-Servidor La cabecera Set-Cookie en funcionamiento Internet S.O. Aplicación (navegador web) Aplicación (servidor web) El servidor recibe la petición y prepara la respuesta El servidor puede decidir si deposita o no deposita una cookie en la respuesta Si deposita una cookie, el servidor puede elegir los parámetros asociados a la misma: nombre, valor, fecha, etc. En este caso el servidor deposita la cookie utilizando la cabecera Set-Cookie HTTP/ OK Set-Cookie: shopC= ;Max-Age=3600; path=/main/shop;domain=.www.tienda.com...

93 Tema IV: El paradigma Cliente-Servidor La cabecera Set-Cookie en funcionamiento Internet S.O. Aplicación (navegador web) Aplicación (servidor web) Al recibir la cookie el cliente tiene dos opciones Descartarla (el usuario puede configurarlo) Aceptarla Una cookie que se acepta es almacenada de manera persistente (en el disco duro) hasta que se alcanza su fecha de expiración El navegador suele tener un fichero en el que almacena todas las cookies activas Antes de enviar una petición (cualquiera que sea) el navegador chequea si es necesario incluir una o varias cookies en la petición HTTP shopC...

94 Tema IV: El paradigma Cliente-Servidor La RFC 2109 define la cabecera Cookie como mecanismo para que un cliente envíe cookies a un servidor (en mensajes de respuesta HTTP) Con cookies habilitadas, cada vez que el navegador envía un petición HTTP debe comprobar si es necesario incluir una o varias cookies en la petición El navegador determina qué cookies es necesario incluir haciendo lo siguiente: Se recupera el URI que identifica el recurso de la petición Se recupera el nombre de dominio del servidor al que va dirigida la petición En la petición, se incluyen todas las cookies que cumplan lo siguiente: La cookie está activa (no ha expirado) La URI de la petición está contenida dentro del path de la cookie. Es decir, la URI comienza por la izquierda con el path El nombre de dominio de la petición es subdominio del domain de la cookie. Es decir, el nombre de dominio termina por la derecha con el domain El modo de transmisión (seguro, no seguro) es compatible con el de la cookie. Es decir, si la cookie contiene el flag secure, solo puede viajar por un canal con seguridad habilitada Todas las cookies a incluir se envían en una sola cabecera del tipo Cookie: nombreCookie=valorCookie; otroNombre=otroValor; nombre=valor La cabecera Cookie

95 Tema IV: El paradigma Cliente-Servidor La cabecera cookie: ejemplos name=shopC value= expires=31 Jan :00:00 GMT path=/main/shop domain=.www.tienda.com secure=no name=spyC value=afda2tg3q34g expires=1 Jan :00:00 GMT path=/ domain=.site.com secure=no name=varYes value=xc124das234s expires=1 Jan :14:00 GMT path=/dir/z_files domain=.com secure=yes name=shopS value= expires=31 Jan :00:00 GMT path=/ domain=.tienda.com secure=yes Cookies almacenadas en el navegador GET /main/shop/menu.php HTTP/1.1 Host: GET /index.html HTTP/1.1 Host: GET /main/shop/file.php HTTP/1.1 Host: casas.tienda.com GET /dir/z_files/g.asp HTTP/1.1 Host: GET /z_files/file HTTP/1.1 Host: La cookie se incluye siempre La cookie se incluye con canal seguro Fecha: 31 Dec :00:00 GMT

96 Tema IV: El paradigma Cliente-Servidor La cabecera cookie en funcionamiento Internet S.O. Aplicación (navegador web) Aplicación (servidor web) Cada vez que el cliente envía una petición HTTP, chequea las cookies para ver si tiene que incluir alguna de ellas La inclusión de una cookie permite devolver al servidor el valor que este depositó en la misma shopC... GET /main/shop/products.php Host: Cookie: shopC=

97 Tema IV: El paradigma Cliente-Servidor La cabecera cookie en funcionamiento Internet S.O. Aplicación (navegador web) Aplicación (servidor web) Al recibir la petición, el servidor recupera el par nombre/valor de la cookie Con ese par nombre valor es posible establecer variables de sesión que conservan estado Ejemplos: El valor de la cookie es un identificador único que actúa como llave en una tabla hash El valor de la cookie es un identificador único que permite recuperar campos de una base de datos El valor de la cookie es un identificador único que coincide con el nombre de un fichero en el que se incluye la información de sesión shopC...

98 Tema IV: El paradigma Cliente-Servidor Es posible utilizar variables de sesión dentro de la API de servlets HTTP puede soportar sesiones basadas en Uso de cookies: Cada sesión está asociada a un identificador único que el cliente envía al servidor en cada petición que se realiza dentro de una cabecera cookie URL-rewriting: Cada sesión está asociada a un identificador único que el cliente envía al servidor como parte de la URI a la que se accede. En este caso, hay que garantizar que todas las URIs que aparecen en las páginas (bien dentro de anclas, bien dentro de atributos ACTION) contienen el citado identificador único Las variables de sesión Permiten la persistencia de datos asociados a un mismo cliente a lo largo de una sesión (un conjunto de pares petición/respuesta) El programador puede crear variables de sesión, asignarles un valor u obtener el valor previo El programador puede invalidar la sesión borrando todas las variables previamente establecidas Muchos entornos de páginas activas (PHP, ASP, etc.) permiten que una sesión se invalide automáticamente tras cierto tiempo de inactividad Servlets y sesiones

99 Tema IV: El paradigma Cliente-Servidor Uso de sesiones: el carrito de la compra Formulario de comercio electrónico Bienvenido al bazar de los reyes magos Escriba el regalo que desea recibir en el formulario Borrar los regalos elegidos anteriormente

100 Tema IV: El paradigma Cliente-Servidor Uso de sesiones: el carrito de la compra public class CarritoServlet extends HttpServlet { public void doGet( HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException { //Recuperamos la sesión y creamos una nueva si hace falta HttpSession session = request.getSession(true); String borrar = (String)request.getParameter("borrarTodo"); if(borrar!= null && borrar.equalsIgnoreCase("on")){ session.invalidate(); session = request.getSession(true); } //Recuperamos la variable de sesión que tiene la lista ArrayList lista = (ArrayList)session.getAttribute("listaDeLaCompra"); if(lista == null) lista = new ArrayList(); //Añadimos el nuevo producto elegido por el usuario String producto = (String)request.getParameter("regalo"); lista.add(producto); session.setAttribute("listaDeLaCompra", lista);... }

101 Tema IV: El paradigma Cliente-Servidor Uso de sesiones: el carrito de la compra public class CarritoServlet extends HttpServlet { public void doGet( HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException {... //Imprimimos la página de respuesta PrintWriter pw = response.getWriter(); pw.println(" "); pw.println(" Carrito de la compra "); pw.println(" "); pw.println("Esta vez has elegido el regalo " + producto + " "); pw.println("En total, tienes los siguientes regalos: "); for(int i = 0; i < lista.size(); i++) pw.println(" " + (String)lista.get(i)); pw.println(" "); pw.println(" Vover a elegir regalos "); pw.println(" "); }

102 Lección 1.6: Comentarios y referencias Comentarios y reflexiones ¿Qué significa el término modelo cliente-sevidor? ¿Por qué tiene tantos significados? ¿Qué es un cliente gordo? ¿y uno flaco? ¿Qué relación guardan ambos con el servidor? ¿En un servidor sin estados, qué elemento del sistema tiene la responsabilidad de mantener la consistencia en las acciones de la aplicación? ¿Y si el servidor es con estados completos? ¿Es HTTP un protocolo sin estados? ¿Puede un servidor HTTP convertirse en un servidor con estados? Referencias Kenneth P. Birman, Building Secure and Reliable Network Applications, Manning Publications Co M. L. Liu, Computación Distribuida: Fundamentos y Aplicaciones, Pearson Addison Wesley, Java Servlet Programming Tutorial: Nunca desprecies el poder de Wikipedia Nunca desprecies el poder de Google. Tema IV: El paradigma Cliente-Servidor

103 Lección 1.6: Resumen Contenidos El paradigma cliente-servidor Concepto El modelo cliente servidor como abstracción El modelo cliente servidor como patrón arquitectural El modelo cliente servidor como arquitectura de sistema Clientes y servidores Tipos de clientes y tipos de servidores Localización de la lógica de la aplicación Mecanismos de caché Concepto Parámetros que intervienen en la eficiencia de la caché Mecanismos de caché en la web Desarrollo de clientes y servidores Servidores iterativos, concurrentes y basados en eventos Modelos multinivel El modelo en tres niveles Funciones del nivel intermedio Java Servlets HTTP y otros conceptos de la tecnología web Desarrollo de servidores basados en la API de Java Servlets Tema IV: El paradigma Cliente-Servidor


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

Presentaciones similares


Anuncios Google