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 4.5: Modelos cliente servidor multinivel 4.6: Modelo cliente/servidor en la web: Java Servlets Tema IV: El paradigma Cliente-Servidor

Lección 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 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 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 Hardware Modelo OSI, modelo TCP/IP Paso de mensajes Cliente-servidor RPC y RMI Servicios de red, ORB 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 Hardware Modelo OSI, modelo TCP/IP Paso de mensajes Cliente-servidor RPC y RMI Servicios de red, ORB 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 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. 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 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 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 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 Capa de presentación Lógica de la aplicación/negocio Capa de Servicios 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 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 C C C S S S S C S S S S 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 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 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) 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? 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é? 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 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 Tema IV: El paradigma Cliente-Servidor

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

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 T: Reserva Avión Madrid-Paris Toma la última habitación 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 Tema IV: El paradigma Cliente-Servidor

Lección 4.3: 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: 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 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 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 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 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? 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” 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 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 ... clientes caché Servidor 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 ... clientes caché Servidor Tema IV: El paradigma Cliente-Servidor

Lección 4.4: Desarrollo de clientes y servidores

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 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 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(); Tema IV: El paradigma Cliente-Servidor

Tiempo útil en el 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 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() 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(); 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 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 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(); Tema IV: El paradigma Cliente-Servidor

Tiempo útil en el servidor multihilo
Servidor Iterativo Servidor multihilo 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 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? 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(); ... Tema IV: El paradigma Cliente-Servidor

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

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 } Tema IV: El paradigma Cliente-Servidor

Tiempo útil en un servidor basado en eventos
Servidor Iterativo Servidor multihilo Servidor eventos 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 Tema IV: El paradigma Cliente-Servidor

Lección 4.5: Modelos multinivel

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

Middle tier 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 Cliente Servidor Cliente Nivel Intermedio (Middle tier) Cliente Servidor Cliente Tema IV: El paradigma Cliente-Servidor

Objetivo y funciones del nivel intermedio
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 Tema IV: El paradigma Cliente-Servidor

Arquitecturas en N niveles
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 Cliente Datos Cliente Nivel Intermedio 1 Nivel Intermedio 2 Nivel Intermedio 3 Cliente Datos Cliente Tema IV: El paradigma Cliente-Servidor

Lección 4.6: Java Servlets

Los servlets de Java 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 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 CR: Carriage Return ASCII 13 LF: Line Feed ASCII 10 Línea inicial CRLF Cabecera-X: Valor-X CRLF Cabecera-Y: Valor-Y CRLF Cabeceras opcionales Mensaje HTTP Cabecera-Z: Valor-Z CRLF CRLF Cabecera (Header) Línea en blanco Cuerpo (Body) Petición: Datos adicionales Respuesta: Recursos solicitados El cuerpo es opcional en ambos casos Tema IV: El paradigma Cliente-Servidor

HTTP: Mensajes 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 método sp recurso versión CRLF nombre de cabecera : valor de cabecera CRLF nombre de cabecera : valor de cabecera CRLF sp = espacio en blanco CRLF = ASCII-CR (13) + ASCI-LF(10) nombre de cabecera : valor de cabecera CRLF nombre de cabecera : valor de cabecera CRLF CRLF Cuerpo opcional del mensaje de petición Tema IV: El paradigma Cliente-Servidor

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) método sp recurso versión CRLF nombre de cabecera : valor de cabecera CRLF nombre de cabecera : valor de cabecera CRLF nombre de cabecera : valor de cabecera CRLF nombre de cabecera : valor de cabecera CRLF CRLF Cuerpo opcional del mensaje de petición Tema IV: El paradigma Cliente-Servidor

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 método sp recurso versión CRLF nombre de cabecera : valor de cabecera CRLF nombre de cabecera : valor de cabecera CRLF nombre de cabecera : valor de cabecera CRLF nombre de cabecera : valor de cabecera CRLF CRLF Cuerpo opcional del mensaje de petición Tema IV: El paradigma Cliente-Servidor

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) método sp recurso versión CRLF nombre de cabecera : valor de cabecera CRLF nombre de cabecera : valor de cabecera CRLF nombre de cabecera : valor de cabecera CRLF nombre de cabecera : valor de cabecera CRLF CRLF Cuerpo opcional del mensaje de petición Tema IV: El paradigma Cliente-Servidor

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 método sp recurso versión CRLF nombre de cabecera : valor de cabecera CRLF nombre de cabecera : valor de cabecera CRLF nombre de cabecera : valor de cabecera CRLF nombre de cabecera : valor de cabecera CRLF CRLF Cuerpo opcional del mensaje de petición Tema IV: El paradigma Cliente-Servidor

HTTP: Mensajes de respuesta
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. versión sp código de estado descripción CRLF nombre de cabecera : valor de cabecera CRLF nombre de cabecera : valor de cabecera CRLF nombre de cabecera : valor de cabecera CRLF nombre de cabecera : valor de cabecera CRLF CRLF Cuerpo opcional del mensaje de petición Tema IV: El paradigma Cliente-Servidor

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.) versión sp código de estado descripción CRLF nombre de cabecera : valor de cabecera CRLF nombre de cabecera : valor de cabecera CRLF nombre de cabecera : valor de cabecera CRLF nombre de cabecera : valor de cabecera CRLF CRLF Cuerpo opcional del mensaje de petición Tema IV: El paradigma Cliente-Servidor

Cabeceras (El mismo formato que para las peticiones): HTTP 1.0 16 posibilidades HTTP 1.1 46 posibilidades Se recomienda incluir las cabeceras Server y Last-Modified versión sp código de estado descripción CRLF nombre de cabecera : valor de cabecera CRLF nombre de cabecera : valor de cabecera CRLF nombre de cabecera : valor de cabecera CRLF nombre de cabecera : valor de cabecera CRLF CRLF Cuerpo opcional del mensaje de petición Tema IV: El paradigma Cliente-Servidor

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: versión sp código de estado descripción CRLF nombre de cabecera : valor de cabecera CRLF nombre de cabecera : valor de cabecera CRLF nombre de cabecera : valor de cabecera CRLF nombre de cabecera : valor de cabecera CRLF CRLF Cuerpo opcional del mensaje de petición Tema IV: El paradigma Cliente-Servidor

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 <html>Esto es una prueba </html> __________________________________________________________________ versión sp código de estado descripción CRLF nombre de cabecera : valor de cabecera CRLF nombre de cabecera : valor de cabecera CRLF nombre de cabecera : valor de cabecera CRLF nombre de cabecera : valor de cabecera CRLF CRLF Cuerpo opcional del mensaje de petición Tema IV: El paradigma Cliente-Servidor

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

Cliente Servidor HTTP en acción: ejemplo básico 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 Aplicación (navegador web) Aplicación (servidor web) S.O. S.O. Internet Tema IV: El paradigma Cliente-Servidor

Cliente Servidor HTTP en acción: ejemplo básico 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 Aplicación (navegador web) Aplicación (servidor web) S.O. S.O. Internet Tema IV: El paradigma Cliente-Servidor

Cliente Servidor HTTP en acción: ejemplo básico 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 Aplicación (navegador web) Aplicación (servidor web) GET / HTTP/1.0 User-Agent: Mozilla/8.0 S.O. S.O. Internet Tema IV: El paradigma Cliente-Servidor

Cliente Servidor HTTP en acción: ejemplo básico 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 Aplicación (navegador web) Aplicación (servidor web) S.O. S.O. Internet Tema IV: El paradigma Cliente-Servidor

Cliente Servidor HTTP en acción: ejemplo básico HTTP/ OK Server: Apache 1.3.2 Content-Type: text/html Content-Length: 8654 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) Aplicación (navegador web) Aplicación (servidor web) S.O. S.O. Internet Tema IV: El paradigma Cliente-Servidor

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

Cliente Servidor HTTP en acción: ejemplo básico 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 Aplicación (navegador web) Aplicación (servidor web) S.O. S.O. Internet Tema IV: El paradigma Cliente-Servidor

Paso de parámetros en las peticiones HTTP
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 <html> <head><title>Página HTML de prueba</title></head> <body> <FORM METHOD=“GET” ACTION=“/index.html"> Input de texto: <INPUT TYPE="text" SIZE="50" NAME="nombre"><BR> Input de password: <INPUT TYPE="password" SIZE="20" NAME="clave"><BR> Checkbox: <INPUT TYPE="checkbox" NAME="rapido"><BR> Radio: <INPUT TYPE="radio" NAME="pago" VALUE="contado"> <INPUT TYPE="radio" NAME="pago" VALUE="visa"><BR> Opción: <SELECT NAME="producto"> <OPTION SELECTED>Ordenador</OPTION> <OPTION>Camara de fotos</OPTION> <OPTION>Disco duro</OPTION> <OPTION>DVD</OPTION> </SELECT><BR> Reset: <INPUT TYPE="reset" VALUE="Reset"><BR> Submit: <INPUT TYPE="submit" VALUE="Enviar"> </FORM> </body> </html> Tema IV: El paradigma Cliente-Servidor

Input de texto: <INPUT TYPE="text" SIZE="50" NAME="nombre"><BR> Input de password: <INPUT TYPE="password" SIZE="20" NAME="clave"><BR> Checkbox: <INPUT TYPE="checkbox" NAME="rapido"><BR> Radio: <INPUT TYPE="radio" NAME="pago" VALUE="contado"> <INPUT TYPE="radio" NAME="pago" VALUE="visa"><BR> Opción: <SELECT NAME="producto"> <OPTION SELECTED>Ordenador</OPTION> <OPTION>Camara de fotos</OPTION> <OPTION>Disco duro</OPTION> <OPTION>DVD</OPTION> </SELECT><BR> Reset: <INPUT TYPE="reset" VALUE="Reset"><BR> Submit: <INPUT TYPE="submit" VALUE="Enviar"> Tema IV: El paradigma Cliente-Servidor

Rellenamos los campos del formulario y pulsamos sobre “Enviar” (submit) <FORM METHOD=“GET” ACTION=“/index.html"> Input de texto: <... NAME="nombre"><BR> Input de password: <... NAME="clave"><BR> Checkbox: <... NAME="rapido"><BR> Radio: <...NAME="pago" VALUE="contado"> <...NAME="pago" VALUE="visa"><BR> Opción: <SELECT NAME="producto"> ... Reset: ... Submit: ... </FORM> Petición HTTP generada por el navegador al pulsar sobre “Enviar” GET /index.html?nombre=Luis+L%F3pez&clave=rata3&rapido=on&pago=visa&producto=DVD HTTP/1.1 Host: localhost Parámetros como pares nombre=valor codificados en formato URLEncoded ¿Qué sucede si el método es POST? 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 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 Servidor-Contenedor Recepción del mensaje de petición Análisis del mensaje + decodificación Cliente 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: ASP, PHP, servlet … <HTML> …Página dinámica…</HTML> HTTP/ OK Content-type: text/html Content-length: … … <HTML> …Página dinámica…</HTML> Codificación + envío de respuesta Tema IV: El paradigma Cliente-Servidor

La API de Servlets de Java
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. Tema IV: El paradigma Cliente-Servidor

Escribiendo servlets HTTP
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 public class Serv1 extends …{ public void doGet(…) {… public void doPost(…) {… POST /index.html HTTP/1.1 Host: localhost ... Contenedor public class Serv2 extends …{ public void doGet(…) {… public void doPost(…) {… GET /pag1 HTTP/1.1 Host: localhost Recurso Servlet /pag1 Serv1 /index.html Serv2 /caja Serv3 public class Serv2 extends …{ public void doGet(…) {… public void doPost(…) {… Tema IV: El paradigma Cliente-Servidor

Escribiendo servlets HTTP Cont.
Servlet HTTP que implementa un “Hola mundo” Se puede “escribir” sobre la página de salida utilizando un PrintWriter 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("<html>"); out.println("<head><title>Example servlet</title></head>"); out.println("<body>"); out.println("<h1>Hola mundo</h1>"); out.println("</body>"); out.println("</html>"); } Tema IV: El paradigma Cliente-Servidor

Recuperando parámetros de entrada
<FORM METHOD=“GET” ACTION=“/index.html"> Input de texto: <... NAME="nombre"><BR> Input de password: <... NAME="clave"><BR> Checkbox: <... NAME="rapido"><BR> Radio: <...NAME="pago" VALUE="contado"> <...NAME="pago" VALUE="visa"><BR> Opción: <SELECT NAME="producto"> ... </FORM> 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 + "<br>"); pw.println("Su clave es " + param2 + "<br>"); pw.println("El pago vale " + param3 + "<br>"); pw.println("El producto es " + param4); } Tema IV: El paradigma Cliente-Servidor

Aplicaciones HTTP con estado
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 Tema IV: El paradigma Cliente-Servidor

La cabecera Set-Cookie
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 Tema IV: El paradigma Cliente-Servidor

La cabecera Set-Cookie en funcionamiento
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 Aplicación (navegador web) Aplicación (servidor web) S.O. S.O. Internet GET /main/shop/menu.php HTTP/1.1 Host: Tema IV: El paradigma Cliente-Servidor

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 Aplicación (navegador web) Aplicación (servidor web) S.O. S.O. Internet HTTP/ OK Set-Cookie: shopC= ;Max-Age=3600; path=/main/shop;domain=. ... Tema IV: El paradigma Cliente-Servidor

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 Aplicación (navegador web) Aplicación (servidor web) S.O. S.O. shopC ... Internet Tema IV: El paradigma Cliente-Servidor

La cabecera Cookie 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 Tema IV: El paradigma Cliente-Servidor

La cabecera cookie: ejemplos
La cookie se incluye siempre Cookies almacenadas en el navegador La cookie se incluye con canal seguro name=shopC value= expires=31 Jan :00:00 GMT path=/main/shop domain=. secure=no name=spyC value=afda2tg3q34g expires=1 Jan :00:00 GMT path=/ domain=.site.com name=varYes value=xc124das234s expires=1 Jan :14:00 GMT path=/dir/z_files domain=.com secure=yes name=shopS value= domain=.tienda.com Fecha: 31 Dec :00:00 GMT 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: Tema IV: El paradigma Cliente-Servidor

La cabecera cookie en funcionamiento
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 Aplicación (navegador web) Aplicación (servidor web) S.O. S.O. shopC ... Internet GET /main/shop/products.php Host: Cookie: shopC= ... Tema IV: El paradigma Cliente-Servidor

La cabecera cookie en funcionamiento
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 Aplicación (navegador web) Aplicación (servidor web) S.O. S.O. shopC ... Internet Tema IV: El paradigma Cliente-Servidor

Servlets y sesiones 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 Tema IV: El paradigma Cliente-Servidor

Uso de sesiones: el carrito de la compra
<HTML> <HEAD> <TITLE>Formulario de comercio electrónico</TITLE> </HEAD> <BODY> <BR><BR><HR><HR> <P> <H1 ALIGN="center">Bienvenido al bazar de los reyes magos</H1> </P><HR> <P ALIGN="center"> <FORM METHOD=GET ACTION="/ExampleServlet/carrito"> Escriba el regalo que desea recibir en el formulario<BR> <INPUT TYPE="text" SIZE="50" NAME="regalo"><BR> <INPUT TYPE="checkbox" NAME="borrarTodo"> Borrar los regalos elegidos anteriormente<BR> <INPUT TYPE="submit" VALUE="Añadir regalo a mi lista"> </FORM> <P><HR><BR><HR><BR> </BODY> </HTML> Tema IV: El paradigma Cliente-Servidor

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); ... Tema IV: El paradigma Cliente-Servidor

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("<HTML>"); pw.println("<HEAD><TITLE>Carrito de la compra</TITLE><HEAD>"); pw.println("<BODY>"); pw.println("Esta vez has elegido el regalo <b>" + producto + "</b><br><br>"); pw.println("En total, tienes los siguientes regalos: <br>"); for(int i = 0; i < lista.size(); i++) pw.println("<li>" + (String)lista.get(i)); pw.println("<BR>"); pw.println("<A HREF=\"form.html\">Vover a elegir regalos</A>"); pw.println("</BODY>"); pw.println("</HTML>"); } Tema IV: El paradigma Cliente-Servidor

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. 1996 M. L. Liu, Computación Distribuida: Fundamentos y Aplicaciones, Pearson Addison Wesley, 2004. Java Servlet Programming Tutorial: Nunca desprecies el poder de Wikipedia Nunca desprecies el poder de Google. Tema IV: El paradigma Cliente-Servidor

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é 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

Tema IV: El Paradigma Cliente-Servidor

Presentaciones similares

Presentación del tema: "Tema IV: El Paradigma Cliente-Servidor"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback

Iniciar la sesión

Autorizarse a través de una red social:

Tema IV: El Paradigma Cliente-Servidor

Presentaciones similares

Presentación del tema: "Tema IV: El Paradigma Cliente-Servidor"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback