tema iv: el paradigma cliente-servidor luis lópez fernández
TRANSCRIPT
Tema IV:El Paradigma
Cliente-Servidor
Luis López Fernández
Tema IV: El paradigma Cliente-Servidor
Tema IV: ContenidosTema 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-servidorLecció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
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-ServidorEl paradigma Cliente-Servidor
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ónEl paradigma cliente-servidor como abstracción
HardwareModelo OSI, modelo TCP/IP
Paso de mensajes
Cliente-servidor
RPC y RMI
Servicios de red, ORB
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 softwareEl paradigma cliente-servidor como arquitectura software
HardwareModelo OSI, modelo TCP/IP
Paso de mensajes
Cliente-servidor
RPC y RMI
Servicios de red, ORB
Pa
tró
n a
rqu
ite
ctu
ral
pli
en
te-s
erv
ido
r
Pa
tró
n a
rqu
ite
ctu
ral
pe
er-
to-p
ee
r
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 softwareEl paradigma cliente-servidor como arquitectura software
Servidor Clientepetición
respuesta
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 protocoloEl paradigma cliente-servidor como patrón de protocolo
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 El paradigma cliente-servidor como arquitectura de sistema
Arquitectura de red con dos servidores y tres PCs
Tema IV: El paradigma Cliente-Servidor
Lección 4.2: Clientes y servidoresLecció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
•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 ServidoresClientes y Servidores
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é?Clientes y servidores: quién hace qué?
Lógica de la aplicación/negocio
Capa de Servicios
Capa de presentación
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/servidorEjemplos de aplicaciones cliente/servidor
C
S
C
C
C
C S
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
Ejemplos de aplicaciones cliente/servidorEjemplos de aplicaciones cliente/servidor
C
C
C
C
S
S
SS
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
Ejemplos de aplicaciones cliente/servidorEjemplos de aplicaciones cliente/servidor
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/servidorEjemplos de aplicaciones cliente/servidor
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/servidorEjemplos de aplicaciones cliente/servidor
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íbridosClientes gordos, flacos e híbridos
Este modelo esel que se estáimponiendo. ¿Por qué?
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 estadosServidores con estados y sin estados
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 estadosServidores con estados y sin estados
Tema IV: El paradigma Cliente-Servidor
•Ejemplo: Servidor sin estados
Servidores con estados y sin estadosServidores 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
CLIENTE SERVIDOR
Tema IV: El paradigma Cliente-Servidor
•Ejemplo: Servidor con estados
Servidores con estados y sin estadosServidores 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 RomaNO DISPONIBLE
Reserva Hotel Roma
Toma la última habitación
El viajero elige
Mensaje de otra agencia
Hay que anular
CLIENTE SERVIDOR
Comienza transacción T
Anula transacción T El servidor debe recordartodo lo que hizo el cliente
en la transacción TANULADO
Tema IV: El paradigma Cliente-Servidor
Lección 4.3: Mecanismos de caché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
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éMecanismos de Caché
caché
clientes
servidor
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éMecanismos de Caché
caché
clientes
servidor
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éMecanismos de Caché
caché
clientes
servidor
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?¿Por qué la caché mejora la eficiencia?
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é eficientesMecanismos de caché eficientes
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éCoherencia de datos en sistemas de caché
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 HTTPMecanismos de caché en HTTP
200 OKExpires: tCaduc
...
Tema IV: El paradigma Cliente-Servidor
Expiración de recursos en HTTP 1.1Expiración de recursos en HTTP 1.1
GET recurso HTTP/1.1... GET recurso HTTP/1.1
...
200 OKExpires: tCaduc
...
GET recurso HTTP/1.1...
if (now() < tCaduc) recurso es válidoelse recurso es inválido
200 OKExpires: tCaduc
...
clientes caché Servidor
200 OKDate: tReespuesta Etag: 4ad4dx23...
Tema IV: El paradigma Cliente-Servidor
Validación de recursos en HTTP 1.1Validación de recursos en HTTP 1.1
GET recurso HTTP/1.1... GET recurso HTTP/1.1
...
200 OKDate: tRespuestaEtag: 4ad4dx23...
GET recurso HTTP/1.1If-Modified …If-None …...
No hay información de caducidad Se utiliza la validación
200 OKDate: tRespuesta Etag: 4ad4dx23...
GET recurso HTTP/1.1If-Modified-Since: tRespuestaIf-None-Match: 4ad4dx23 ...
304 Not modifiedEtag: 4ad4dx23...
clientes caché Servidor
Tema IV: El paradigma Cliente-Servidor
Lección 4.4: Desarrollo de clientes y servidoresLecció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
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 servidoresDesarrollo de clientes y servidores
Tema IV: El paradigma Cliente-Servidor
Modelo conceptual de un servidor iterativoModelo 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
Tema IV: El paradigma Cliente-Servidor
Esqueleto en código de un servidor iterativoEsqueleto en código de un servidor iterativopublic 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 iterativoTiempo ú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)
Tema IV: El paradigma Cliente-Servidor
Modelo conceptual de un servidor multihiloModelo 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
Tema IV: El paradigma Cliente-Servidor
Esqueleto en código de un servidor multihiloEsqueleto 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 servidorwhile(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 multihiloEsqueleto 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 intercambiossocket.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 multihiloAlgunos 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)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 multihiloTiempo ú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.
Tema IV: El paradigma Cliente-Servidor
Modelo conceptual de un servidor basado en eventosModelo 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?
Tema IV: El paradigma Cliente-Servidor
Esqueleto en código de un servidor basado en eventosEsqueleto en código de un servidor basado en eventospublic 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ñoprivate 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
Esqueleto en código de un servidor basado en eventosEsqueleto 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 bufferbuf.clear();int bytesRead = channel.read(buf);if(bytesRead == -1){
//Si estamos aquí la conexión se ha cerrado}//Recuperamos los datos del bufferbuf.flip();byte[] data = new byte[buf.remaining()];buf.get(data);//Procesamos la petición y creamos la respuestaString request = new String(data, "ISO-8859-1");System.out.println("<<<<" + request);responses.put(channel, request.toUpperCase());key.interestOps(SelectionKey.OP_WRITE); //Interés en evento de escritura
}...
Tema IV: El paradigma Cliente-Servidor
Esqueleto en código de un servidor basado en eventosEsqueleto 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 bufferbuf.clear();buf.put(responses.get(channel).getBytes("ISO-8859-1"));buf.flip();responses.remove(channel);
//Enviamos la respuesta el nodo remototry{
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 eventosTiempo ú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)
Tema IV: El paradigma Cliente-Servidor
Lección 4.5: Modelos multinivelLecció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
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 nivelesModelos cliente-servidor en múltiples niveles
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 tierMiddle tier
Nivel Intermedio
(Middle tier)
Cliente
Cliente
Cliente
Cliente
Servidor
Servidor
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 intermedioObjetivo y funciones del nivel intermedio
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 nivelesArquitecturas en N niveles
Cliente
Cliente
Cliente
Cliente
Nivel
Intermedio 2
Nivel
Intermedio 1
Nivel
Intermedio 3
Datos
Datos
Tema IV: El paradigma Cliente-Servidor
Lección 4.6: Java ServletsLecció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
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 JavaLos servlets de Java
Tema IV: El paradigma Cliente-Servidor
HTTP: Funcionamiento básicoHTTP: 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 inicial CRLF
Cabecera-X: Valor-X CRLF
Cabecera-Y: Valor-Y CRLF
Cabecera-Z: Valor-Z CRLF
CRLF
Petición: Datos adicionales
Respuesta: Recursos solicitados
El cuerpo es opcional en ambos casos
MensajeHTTP
CR: Carriage ReturnASCII 13
LF: Line FeedASCII 10
Cabeceras opcionales
Línea en blanco
Tema IV: El paradigma Cliente-Servidor
HTTP: Mensajes de peticiónHTTP: Mensajes de petición
método sp recurso sp 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
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)
Tema IV: El paradigma Cliente-Servidor
método sp recurso sp 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
Recurso:Identificador del recurso sobre el que se realizará la acción. Suele coincidir con la sección path de la URLEjemplo: /directorio/subdirectorio/fichero.html
Para GET: Puede contener la parte query de la URLEjemplo: /directorio/subdirectorio/script.php?variable=valorDe 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ónHTTP: Mensajes de petición
Tema IV: El paradigma Cliente-Servidor
HTTP: Mensajes de peticiónHTTP: Mensajes de petición
método sp recurso sp 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
Versión:Versión del protocolo que se está utilizando en el cliente. En la actualidad sólo existen dos opciones:
HTTP/1.0HTTP/1.1
En general es de la forma HTTP/x.y
Tema IV: El paradigma Cliente-Servidor
HTTP: Mensajes de peticiónHTTP: Mensajes de petición
método sp recurso sp 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
Cabeceras:HTTP 1.0
•Pueden aparecer 0 o más cabeceras de 16 posiblesHTTP 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 ASCIIEjemplo: user-agent: Mozilla/4.07 [es] (Linux 2.2.15 i586; Nav)
Tema IV: El paradigma Cliente-Servidor
HTTP: Mensajes de peticiónHTTP: Mensajes de petición
método sp recurso sp 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
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
Tema IV: El paradigma Cliente-Servidor
HTTP: Mensajes de respuestaHTTP: Mensajes de respuesta
versión sp código de estado sp 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
Versión:Versión del protocolo que utiliza el servidor. En la actualidad sólo existen dos opciones:
HTTP/1.0HTTP/1.1
Si el servidor soporta ambas, debe contestar, preferentemente, con la versión que haya utilizado el cliente en la petición.
Tema IV: El paradigma Cliente-Servidor
HTTP: Mensajes de respuestaHTTP: Mensajes de respuesta
versión sp código de estado sp 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
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 exitoso3xx: Redirección del cliente a otra URL4xx: Error en la petición del cliente5xx: Error en el servidor
200 OK: La petición ha sido atendida con éxito301 Moved Permanently: El recurso solicitado ha sido trasladado permanentemente404 Not Found: El recurso solicitado no existe500 Server Error: Error interno en el servidor (permisos insuficientes, etc.)
Tema IV: El paradigma Cliente-Servidor
HTTP: Mensajes de respuestaHTTP: Mensajes de respuesta
versión sp código de estado sp 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
Cabeceras (El mismo formato que para las peticiones):HTTP 1.0
•16 posibilidadesHTTP 1.1
•46 posibilidades
Se recomienda incluir las cabeceras Server y Last-Modified
Tema IV: El paradigma Cliente-Servidor
HTTP: Mensajes de respuestaHTTP: Mensajes de respuesta
versión sp código de estado sp 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
Cuerpo:Dependiendo del método al que se responda, puede estar presente o no.
Respuesta a HEAD, DELETE, PUT: Nunca estará presenteRespuesta 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 contenidoConten-Length:Content-Type:
Tema IV: El paradigma Cliente-Servidor
HTTP: Mensajes de respuestaHTTP: Mensajes de respuesta
versión sp código de estado sp 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
Ejemplo:________________________________________________________________________HTTP/1.1 200 OKDate: Tue, 23 Jan 2001 12:44:27 GMTServer: Apache/1.3.9 (Unix) Debian/GNULast-Modified: Tue, 23 Jan 2001 12:39:45 GMTContent-Length: 34Content-type: text/html
<html>Esto es una prueba </html> __________________________________________________________________
Tema IV: El paradigma Cliente-Servidor
HTTP en acción: ejemplo básicoHTTP en acción: ejemplo básico
InternetInternet
S.O. S.O.
Aplicación(navegador web)
Aplicación(servidor web)
Cliente Servidor
Paso 1El usuario introduce la URL a la que quiere conectarse
en el navegador web:Ejemplo:
http://www.google.com/
Tema IV: El paradigma Cliente-Servidor
HTTP en acción: ejemplo básicoHTTP en acción: ejemplo básico
InternetInternet
S.O. S.O.
Aplicación(navegador web)
Aplicación(servidor web)
Cliente Servidor
Paso 2El 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
Tema IV: El paradigma Cliente-Servidor
HTTP en acción: ejemplo básicoHTTP en acción: ejemplo básico
InternetInternet
S.O. S.O.
Aplicación(navegador web)
Aplicación(servidor web)
Cliente Servidor
Paso 3El 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
Tema IV: El paradigma Cliente-Servidor
HTTP en acción: ejemplo básicoHTTP en acción: ejemplo básico
InternetInternet
S.O. S.O.
Aplicación(navegador web)
Aplicación(servidor web)
Cliente Servidor
Paso 4El cliente crea el mensaje
HTTP de petición solicitando el recurso deseado y lo
envía a través de la conexiónGET / HTTP/1.0User-Agent: Mozilla/8.0
Tema IV: El paradigma Cliente-Servidor
HTTP en acción: ejemplo básicoHTTP en acción: ejemplo básico
InternetInternet
S.O. S.O.
Aplicación(navegador web)
Aplicación(servidor web)
Cliente Servidor
Paso 5El 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.0User-Agent: Mozilla/8.0
Tema IV: El paradigma Cliente-Servidor
HTTP en acción: ejemplo básicoHTTP en acción: ejemplo básico
InternetInternet
S.O. S.O.
Aplicación(navegador web)
Aplicación(servidor web)
Cliente Servidor
Paso 6El servidor construye el mensaje de respuesta, incluyendo el recurso
solicitado en el cuerpo del mensaje (asumimos que no
se produce ningún error)
HTTP/1.0 200 OKServer: Apache 1.3.2Content-Type: text/htmlContent-Length: 8654
Tema IV: El paradigma Cliente-Servidor
HTTP en acción: ejemplo básicoHTTP en acción: ejemplo básico
InternetInternet
S.O. S.O.
Aplicación(navegador web)
Aplicación(servidor web)
Cliente Servidor
Paso 7El servidor envía el mensaje de respuesta al cliente, con el recurso solicitado dentro
del cuerpo del mismo
HTTP/1.0 200 OKServer: Apache 1.3.2Content-Type: text/htmlContent-Length: 8654
Tema IV: El paradigma Cliente-Servidor
HTTP en acción: ejemplo básicoHTTP en acción: ejemplo básico
InternetInternet
S.O. S.O.
Aplicación(navegador web)
Aplicación(servidor web)
Cliente Servidor
Paso 8El cliente recupera el
recurso solicitado y cierra la conexión con el servidor.
Acto seguido puede representar el recurso como
considere oportuno
Tema IV: El paradigma Cliente-Servidor
Paso de parámetros en las peticiones HTTPPaso de parámetros en las peticiones HTTP
<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>
•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
Tema IV: El paradigma Cliente-Servidor
Paso de parámetros en las peticiones HTTPPaso de parámetros en las peticiones HTTP
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
Paso de parámetros en las peticiones HTTPPaso de parámetros en las peticiones HTTP
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
Paso de parámetros en las peticiones HTTPPaso de parámetros en las peticiones HTTP
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
Paso de parámetros en las peticiones HTTPPaso de parámetros en las peticiones HTTP
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
Paso de parámetros en las peticiones HTTPPaso de parámetros en las peticiones HTTP
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
Paso de parámetros en las peticiones HTTPPaso de parámetros en las peticiones HTTP
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
Paso de parámetros en las peticiones HTTPPaso de parámetros en las peticiones HTTP
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)
Paso de parámetros en las peticiones HTTPPaso de parámetros en las peticiones HTTP
<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>
GET /index.html?nombre=Luis+L%F3pez&clave=rata3&rapido=on&pago=visa&producto=DVD HTTP/1.1Host: 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.1Host: localhostContent-type: application/x-www-form-urlencodedContent-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: conceptoLas páginas activas de servidor: concepto
GET /index.html?nombre=Luis+L%F3pez&clave=rata3&rapido=on&pago=visa&producto=DVD HTTP/1.1Host: 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
<HTML> …Página dinámica…</HTML>
Codificación + envío de respuesta
HTTP/1.1 200 OKContent-type: text/htmlContent-length: ……
<HTML> …Página dinámica…</HTML>
Cliente
Servidor-Contenedor
Página dinámica: ASP, PHP, servlet …
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 JavaLa API de Servlets de Java
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 HTTPEscribiendo servlets HTTP
Contenedor
Recurso Servlet/pag1 Serv1/index.html Serv2/caja Serv3
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.1Host: localhost...
GET /pag1 HTTP/1.1Host: localhost
Tema IV: El paradigma Cliente-Servidor
Escribiendo servlets HTTP Cont.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("<html>");out.println("<head><title>Example servlet</title></head>");out.println("<body>");out.println("<h1>Hola mundo</h1>");out.println("</body>");out.println("</html>");
}
}
•Servlet HTTP que implementa un “Hola mundo”
•Se puede “escribir” sobre la página de salida utilizando un PrintWriter
Tema IV: El paradigma Cliente-Servidor
Recuperando parámetros de entradaRecuperando 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
•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 estadoAplicaciones HTTP con estado
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=234141321454223; 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-CookieLa cabecera Set-Cookie
Tema IV: El paradigma Cliente-Servidor
La cabecera Set-Cookie en funcionamientoLa cabecera Set-Cookie en funcionamiento
InternetInternet
S.O. 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:
http://www.tienda.com/main/shop/menu.php
•El navegador crea un paquete HTTP para esa petición y lo envía al servidor correspondiente
GET /main/shop/menu.php HTTP/1.1Host: www.tienda.com
Tema IV: El paradigma Cliente-Servidor
La cabecera Set-Cookie en funcionamientoLa cabecera Set-Cookie en funcionamiento
InternetInternet
S.O. 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/1.1 200 OK Set-Cookie: shopC=123141121;Max-Age=3600;path=/main/shop;domain=.www.tienda.com...
Tema IV: El paradigma Cliente-Servidor
La cabecera Set-Cookie en funcionamientoLa cabecera Set-Cookie en funcionamiento
InternetInternet
S.O. 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...
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 CookieLa cabecera Cookie
Tema IV: El paradigma Cliente-Servidor
La cabecera cookie: ejemplosLa cabecera cookie: ejemplos
name=shopCvalue=1214512341expires=31 Jan 2006 00:00:00 GMTpath=/main/shopdomain=.www.tienda.comsecure=no
name=spyCvalue=afda2tg3q34gexpires=1 Jan 2006 00:00:00 GMTpath=/domain=.site.comsecure=no
name=varYesvalue=xc124das234sexpires=1 Jan 1974 01:14:00 GMTpath=/dir/z_filesdomain=.comsecure=yes
name=shopSvalue=1358372772expires=31 Jan 2006 00:00:00 GMTpath=/domain=.tienda.comsecure=yes
Cookies almacenadas en el navegador
GET /main/shop/menu.php HTTP/1.1Host: www.tienda.com
GET /index.html HTTP/1.1Host: www.tienda.com
GET /main/shop/file.php HTTP/1.1Host: casas.tienda.com
GET /dir/z_files/g.asp HTTP/1.1Host: www.site.com
GET /z_files/file HTTP/1.1Host: www.tienda.com
La cookie se incluye siempre
La cookie se incluye con canal seguro
Fecha: 31 Dec 2005 12:00:00 GMT
Tema IV: El paradigma Cliente-Servidor
La cabecera cookie en funcionamientoLa cabecera cookie en funcionamiento
InternetInternet
S.O. 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.phpHost: www.tienda.comCookie: shopC=123141121...
Tema IV: El paradigma Cliente-Servidor
La cabecera cookie en funcionamientoLa cabecera cookie en funcionamiento
InternetInternet
S.O. 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...
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 sesionesServlets y sesiones
Tema IV: El paradigma Cliente-Servidor
Uso de sesiones: el carrito de la compraUso 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
Uso de sesiones: el carrito de la compraUso de sesiones: el carrito de la comprapublic class CarritoServlet extends HttpServlet {
public void doGet(HttpServletRequest request,HttpServletResponse response) throws IOException, ServletException
{
//Recuperamos la sesión y creamos una nueva si hace faltaHttpSession 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 listaArrayList lista =
(ArrayList)session.getAttribute("listaDeLaCompra");if(lista == null)
lista = new ArrayList();
//Añadimos el nuevo producto elegido por el usuarioString producto = (String)request.getParameter("regalo");lista.add(producto);session.setAttribute("listaDeLaCompra", lista);
...}
}
Tema IV: El paradigma Cliente-Servidor
Uso de sesiones: el carrito de la compraUso de sesiones: el carrito de la comprapublic class CarritoServlet extends HttpServlet {
public void doGet(HttpServletRequest request,HttpServletResponse response) throws IOException,
ServletException {
...
//Imprimimos la página de respuestaPrintWriter 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>");
}}
Lección 1.6: Comentarios y referenciasLecció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:
http://www.unix.org.ua/orelly/java-ent/servlet/index.htm•Nunca desprecies el poder de Wikipedia•Nunca desprecies el poder de Google.
Tema IV: El paradigma Cliente-Servidor
Lección 1.6: ResumenLecció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