TIV ClienteServidor

Tema IV: El Paradigma Cliente-Servidor
Luis Lpez Fernndez
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
Leccin 4.1: El paradigma cliente-servidor

El paradigma Cliente-Servidor
El trmino 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 abstraccin que simplifica el modelo de paso de mensajes Un patrn arquitectural para software distribuido Un patrn de protocolo conversacional Una arquitectura de sistemas distribuidos En todos los casos, hablar de modelo cliente-servidor implica: Que existe una comunicacin entre dos entidades Que esas entidades son asimtricas (realizan acciones diferentes) Una de las entidades de denomina cliente El cliente siempre origina el dilogo entre las entidades La otra de las entidades se denomina servidor El servidor siempre presta un servicio al cliente
El paradigma cliente-servidor como abstraccin

El modelo de paso de mensajes No especifica cmo se sincronizan los procesos No especifica cuantos tipos de procesos comunican No especifica el protocolo (dilogo) a seguir entre los procesos El paradigma cliente-servidor es una abstraccin del modelo de paso de mensajes Especifica cmo 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 dilogo basado en peticin-respuesta

Restringirnos al modelo cliente-servidor, limita lo que podemos hacer con una aplicacin distribuida, pero abstrae algunos de los problemas asociados al IPC Al desarrollar con APIs cliente-servidor (i.e. servlets) se percibe esa abstraccin
Servicios de red, ORB RPC y RMI Cliente-servidor Paso de mensajes Modelo OSI, modelo TCP/IP Hardware
El paradigma cliente-servidor como arquitectura software

Definicin de arquitectura de un sistema software La arquitectura comprende la enumeracin de los componentes software especificando sus interfaces y la relacin que estos guardan entre s Un patrn arquitectural es una plantilla o descripcin que puede aplicarse al diseo de arquitecturas de sistemas que tienen una problemtica similar El modelo cliente servidor es un patrn arquitectural de software distribuido que define dos tipos de componentes y un modelo de interaccin basado en un dilogo peticin-respuesta Este patrn arquitectural puede aplicarse al diseo de aplicaciones distribuidas en mltiples niveles de abstraccin
Patrn arquitectural pliente-servidor
Servicios de red, ORB RPC y RMI Cliente-servidor
Paso de mensajes Modelo OSI, modelo TCP/IP Hardware
Patrn arquitectural peer-to-peer
El paradigma cliente-servidor como arquitectura software

El patrn cliente-servidor trata de proporcionar una arquitectura escalable para el desarrollo de aplicaciones distribuidas en la que intervienen slo dos tipos de procesos: clientes y servidores La interaccin entre el cliente y el servidor es sncrona
El servidor
Es pasivo, espera las peticiones de los clientes Cuando recibe peticiones, debe procesarlas y ofrecer una respuesta Suele ser diseado con objetivos de eficiencia El cliente Es activo, tiene la iniciativa de iniciar el dilogo con el servidor enviando peticiones Por cada peticin enviada, se debe obtener una respuesta Suele ser diseado con el objetivo de interaccionar con el usuario final
peticin
Servidor
respuesta
Cliente
El paradigma cliente-servidor como patrn de protocolo

En un protocolo hay que especificar quin hace qu en cada momento Mltiples protocolos se basan en el intercambio de mensajes siguiendo un esquema peticin-respuesta En mltiples ocasiones asimila este modelo conversacional como cliente-servidor Cliente: el que realiza la peticin Servidor: el que espera peticiones y ofrece respuestas Los trminos cliente y servidor se utilizan con esta acepcin de manera habitual
Ejemplos: La API estndar de Java llama ServerSocket a la clase que espera conexiones
Pero un ServerSocket no tiene por qu formar parte de un servidor (entendido como patrn arquitectural). Podemos definir una aplicacin 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 arquitectura de sistema

Un sistema distribuido est compuesto por Nodos de procesamiento (ordenadores) Infraestructuras de comunicaciones (red) En muchas ocasiones se eligen caractersticas especficas sobre los nodos de procesamiento en trminos de hardware, sistema operativo, prestaciones, etc. Estas caractersticas dependen del papel que el nodo est destinado a representar En muchas ocasiones, los ordenadores que estn destinados a almacenar procesos servidor (desde el punto de vista de arquitectura software) tambin 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
Leccin 4.2: Clientes y servidores

Clientes y Servidores
El cliente es la parte de la aplicacin que interacciona con el usuario El cliente no comparte (sus recursos no son vistos por otros clientes) El cliente no tiene restricciones especiales en trminos 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 trminos de Ergonoma: Debe adaptarse a la interaccin con el usuario Seguridad: No debe comprometer la seguridad de otras aplicaciones El servidor es la parte de la aplicacin que presta servicios al cliente El servidor comparte sus recursos con todos los clientes que lo usan El servidor tiene restricciones especiales en trminos de Prestaciones: Cuando queremos que numerosos clientes lo usen Fiabilidad: Si el servidor falla, los clientes no pueden continuar Escalabilidad: Queremos que el nmero 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 trminos de Ergonoma: Lo controla un administrador experto
Clientes y servidores: quin hace qu?

Las aplicaciones distribuidas existen para ofrecer unas funcionalidades al usuario La arquitectura abstracta de una aplicacin distribuida cliente-servidor es siempre Capa de presentacin Suele residir en el cliente El servidor puede tener funcionalidades de presentacin menores Lgica 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 ms peso en el servidor
Capa de presentacin Lgica de la aplicacin/negocio Capa de Servicios

Ejemplos de aplicaciones cliente/servidor

El servicio WWW clsico (descarga de ficheros + representacin): La capa de presentacin requiere, entre otros: Capacidad para representar documentos HTML C Capacidad para representar imgenes en diferentes formatos C Capacidad para representar e interpretar otros tipos datos (pdf, applets, etc.) C La lgica de la aplicacin requiere, entre otros:
No hay mucha lgica de negocio en un servidor/cliente web clsico

Hay algo en un cliente o en un servidor web que no tenga que ver con Presentar los datos Proporcionar un servicio de lectura/codificacin/envo de ficheros? La capa de servicios debe proporcionar, entre otros La implementacin del protocolo HTTP
S S
Capacidad de acceder a ficheros identificados por un path HTTP S Comprimir y descomprimir un fichero (si se soporta el encoding gzip) C

Un servicio WWW de comercio electrnico (con pginas activas, por supuesto): La capa de presentacin requiere, entre otros: Capacidad para representar documentos HTML C Capacidad para representar imgenes en diferentes formatos
Capacidad para representar e interpretar otros tipos datos (pdf, applets, etc.) C La lgica de la aplicacin requiere, entre otros:
Comprobacin del nmero de tarjeta de crdito
Gestin de los inventarios (actualizar stock, pedir ms, etc.) S Gestin de los pedidos (realizar acciones para envo del pedido) S Gestin contable (actualizar tesorera con ingresos por venta, etc.) S
La capa de servicios debe proporcionar, entre otros

La implementacin del protocolo HTTPS C S Capacidad para acceder a las diferentes bases de datos Capacidad para comunicar con servicios bancarios S Servicios transaccionales

En aplicaciones web, el cliente no tiene lgica de negocio (es genrico) En aplicaciones en las que el cliente no est prefabricado, esto puede cambiar Ejemplo de aplicacin tpico: Aplicacin de gestin de una cadena de tiendas La especificacin de una aplicacin as puede ocupar cientos de pginas Lo simplificamos imaginando que La empresa tiene 4 tablas de datos generales La tabla de tesorera (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 (comisin que cobra un vendedor por venta) La lgica de negocio (proporcionada por un experto) es Por cada venta, el vendedor recibe un 10% del montante de comisin 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 tesorera en cada venta En un sistema real de gestin tiendas puede haber cientos de operaciones asociadas a una venta

Lgica de negocio en pseudocdigo 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)
}
Quin 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 nmero de productos vendidos y el coste por producto pactado Quin implementa la lgica de negocio? Qu pinta tiene el protocolo de nivel de aplicacin que necesitamos? Ambas respuestas estn muy relacionadas

Solucin 1: El servidor proporciona al cliente un servicio para hacer operaciones InsertarEnTabla(tabla, columna, valor) BorrarDeLaTabla(tabla, comuna, valor) Se define un protocolo de peticin-respuesta para implementarlo Solucin 2: El servidor proporciona al cliente un servicio para hacer operaciones ActualizarVenta(vendedor, numeroProductos, costePorProducto) Se define un protocolo de peticin-respuesta para implementarlo Puede haber muchas otras soluciones intermedias Solucin 1: Donde reside la lgica de negocio, en el cliente o en el servidor? Solucin 2: Dnde reside la lgica de negocio, en el cliente o en el servidor?
Clientes gordos, flacos e hbridos

Decimos que un cliente es Flaco (thin) Cuando no implementa en absoluto la lgica de la aplicacin 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 lgica de la aplicacin Procesa la informacin del usuario antes de comunicar con el servidor
Requiere capacidad de proceso y, normalmente, capacidad de almacenamiento

Hbrido (hybrid) Implementa una parte de la lgica de aplicacin Si optamos por una arquitectura basada en un cliente flaco/hbrido El servidor ser ms complicado Si optamos por una arquitectura basada en un cliente gordo El servidor ser ms sencillo
Este modelo es el que se est imponiendo. Por qu?
Servidores con estados y sin estados

Dependiendo de si la lgica de la aplicacin reside en el cliente o en el servidor y de la propia naturaleza de la aplicacin 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 clsico: Es sin estados, para servir un fichero basta con el mensaje de peticin en curso, no se necesita nada del pasado Comercio electrnico web con carro de la compra: Es con estados, hace falta conocer lo que el usuario ha comprado en la ltima sesin Los servidores sin estados son mucho ms sencillos de desarrollar Los servidores con estados son mucho ms complejos
Un servidor con estados, en sentido estricto, debe contener un modelo (en forma de mquina de estados) por cada uno de los clientes que se conectan
Pueden existir modelos hbridos en los que el servidor guarda cierto estado del cliente, pero sin llegar a disponer de un modelo completo

Ejemplo: Servidor transaccional para gestin de agencias de viajes Imaginemos que la especificacin se simplifica del modo siguiente: Tenemos una BD de vuelos que controla Qu vuelos hay (con horario, compaa, 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 da
La aplicacin debe ofrecer las funcionalidades siguientes

Debe permitir visualizar la disponibilidad de vuelos y hoteles Debe permitir la definicin 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 tpico: Viaje: Madrid, Pars (hotel 2 das), Roma (hotel 2 das), Madrid Chequeamos disponibilidad de hoteles y vuelos En el momento de reservar, alguien se adelanta y toma la ltima habitacin en el hotel de Roma

Ejemplo: Servidor sin estados
CLIENTE Dime Aviones Disponibles Dime Hoteles Disponibles SERVIDOR
Mensaje de otra agencia

El viajero elige Reserva Avin Madrid-Paris Reserva Hotel Roma
Reserva Hotel Pars

Reserva Avin Pars-Roma Reserva Hotel Roma
Toma la ltima habitacin
NO DISPONIBLE
Hay que anular Anula reserva Avin Pars-Roma Anula reserva Hotel Pars Anula reserva Avin Madrd-Pars

Ejemplo: Servidor con estados
CLIENTE Dime Aviones Disponibles Dime Hoteles Disponibles SERVIDOR
Mensaje de otra agencia

El viajero elige Comienza transaccin T T: Reserva Avin Madrid-Paris T: Reserva Hotel Pars Reserva Hotel Roma
Toma la ltima habitacin
T: Reserva Avin Pars-Roma

T: Reserva Hotel Roma
NO DISPONIBLE
Hay que anular Anula transaccin T
ANULADO
El servidor debe recordar todo lo que hizo el cliente en la transaccin T
Leccin 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 cachs 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 informacin 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
Mecanismos de Cach

La primera vez que el cliente solicita la informacin, esta se descarga desde el servidor, pero la cach se guarda una copia clientes
cach
servidor
Mecanismos de Cach

Si la cach ve alguna peticin de un cliente que solicita una informacin que ella posee, intercepta la peticin y responde a ella como si fuese el servidor. En caso contrario, deja pasar la peticin sin alterarla clientes
cach
servidor
Por qu la cach mejora la eficiencia?

Mejora en trminos 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 comunicacin menor Mejora en trminos 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 travs de su lnea

Con cach: el servidor proporciona 1G byte de datos a travs de su lnea Mejora en trminos de escalabilidad Parte del trabajo del servidor la hace la cach: el servidor soporta ms clientes En general, la presencia de un sistema de cach permite que el cliente tenga la respuesta a sus peticiones de manera mucho ms rpida
Mecanismos de cach eficientes

Qu parmetros mejoran el rendimiento de una cach? Cuanto ms prxima est la cach al cliente, mejores son sus prestaciones Cuanto ms pequeo es t1 en relacin a t2, mayor ser la mejora en tiempo Cuantos mayor sea el tamao de la cach, mayor nmero de hits tendremos Si la cach es pequea, se podrn almacenar pocos recursos y la probabilidad de que un cliente solicite un recurso en ella contenido ser menor
Cuanto menor sea la dispersin de los datos solicitados, ms hits tendremos

Si todos los clientes solicitan el mismo recurso, siempre habr hits. Si los recursos que solicitan los clientes son muy heterogneos, menor nmero de hits tendremos
Cmo influye el hecho de que los datos originales cambien?
Coherencia de datos en sistemas de cach

El mecanismo de cach que hemos descrito funciona siempre y cuando los datos sean estticos (no cambien), pero esta suposicin no siempre es correcta Imaginemos que el recurso es una pgina web que indica: ndices burstiles Disponibilidad de plazas en un vuelo Cmo 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 peticin 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 cachs que lo poseen diciendo tal dato ha dejado de ser vlido y las cachs lo borran Mecanismo 4 Cada vez que un dato cambia en el servidor, ste informa a todas las cachs que lo poseen diciendo tal dato ha cambiado, aqu tienes su nuevo valor
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 excepcin y disponen de este mecanismo HTTP 1.1 ofrece soporte para que los navegadores controlen la consistencia de sus cachs (RFC 2619) . Tambin hay soporte para cachs intermedias Los detalles son complejos y tienen una casustica grande Estn 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 travs de dos mecanismos complementarios Un mecanismo de expiracin 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 validacin Para recursos caducados o sin informacin de caducidad Permite validar el recurso sin necesidad de volverlo a descargar
Expiracin 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 vlido else recurso es invlido
200 OK Expires: tCaduc ...
clientes
cach
Servidor
Validacin 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 informacin de caducidad Se utiliza la validacin
GET recurso HTTP/1.1 If-Modified-Since: tRespuesta If-None-Match: 4ad4dx23 ...
200 OK Date: tRespuesta Etag: 4ad4dx23 ...
304 Not modified Etag: 4ad4dx23 ...
clientes
cach
Servidor
Leccin 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 lgica de negocio difcil. Ambos aspectos estn 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, adems de implementar el servicio de comunicaciones, debe ser diseado con objetivos de escalabilidad en mente
Un servidor tanto ms til cuantos ms clientes lo comparten Cmo podemos lograr que muchos clientes compartan un mismo servidor? Hay muchas soluciones, las ms habituales son Usar un modelo de servidor multihilo Usa operaciones de comunicaciones (sockets) bloqueantes El desarrollo del servidor es ms 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 ms enrevesado Nos libramos del control de concurrencia y de los mltiples hilos
Modelo conceptual de un servidor iterativo

Inicio del servidor Crear serverSocket Bucle infinito socket = serverSocket.accept()
Llamada bloqueante
Leer mensaje del socket
Procesar mensaje
Enviar respuesta por el socket
Esqueleto en cdigo 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(); } }
Tiempo til en el servidor iterativo

Servidor Iterativo
Hilo en ejecucin
Hilo bloqueado (I/O)
Todo el tiempo de espera por operaciones de entrada/salida se desperdicia (no es aprovechado para el procesamiento de ninguna peticin de clientes)
Tiempo
Modelo conceptual de un servidor multihilo

Inicio del servidor
Llamada bloqueante
Bucle infinito socket = serverSocket.accept() Cada sesin TCP del protocolo se atiende en un hilo de ejecucin diferente
lanzaThread(socket)
m = leerMensaje()
m = leerMensaje()
m = leerMensaje()
procesar(m)
procesar(m)
procesar(m)
enviarRespuesta()
enviarRespuesta()
enviarRespuesta()
Esqueleto en cdigo 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 gestin de peticiones en el servidor while(true){ Socket connection = serverSocket.accept(); Handler requestProcessor = new Handler(connection); new Thread(requestProcessor).start(); } } }
Esqueleto en cdigo de un servidor multihilo

public class Handler implements Runnable { private Socket socket; //Aqu se pueden definir variables de estado de sesin (servidor con estados) public Handler(Socket socket){ this.socket = socket; } public void run(){ try{ RequestMessage request = readRequest(); ResponseMessage response = process(request); sendResponse(response); //La sesin puede continuar con ms intercambios socket.close(); } catch(IOException ioe){ //Gestin de errores en la comunicacin } } private RequestMessage readRequest(){ //Aqu el cdigo que lee y desaplana el mensaje desde un socket } private void sendResponse(ResponseMessage response){ //Aqu el cdigo que aplana y enva el mensaje por un socket } private ResponseMessage process (RequestMessage request){ //Aqu el cdigo que procesa la peticin y genera la respuesta } }
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 mltiples hilos acceden a datos compartidos (hay interaccin entre hilos) Es necesario detectar cules son las secciones crticas Es necesario implementar mecanismos de control de concurrencia Problemas asociados a la gestin de hilos
La creacin de un nuevo hilo dentro de un proceso es costosa

La destruccin de un hilo dentro de un proceso es costosa La gestin 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 ms tareas que hilos disponibles, algunas tareas debern esperar
Esqueleto en cdigo 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(); } } } }
Tiempo til en el servidor multihilo

Servidor Iterativo Servidor multihilo
Hilo en ejecucin
Cuando un hilo se bloquea por una operacin de entrada/salida, el S.O. planifica otro diferente. Se pierde el tiempo asociado a los cambios de contexto y a creacin/destruccin de hilos.
Tiempo
Modelo conceptual de un servidor basado en eventos

Inicio del servidor registrar(serverSocket) Bucle infinito evento = selectorEventos() Llamada bloqueante
Si evento es de conexin 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 conexin de socket?
Esqueleto en cdigo 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 tamao 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(); } } ...

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 conexin se ha cerrado } //Recuperamos los datos del buffer buf.flip(); byte[] data = new byte[buf.remaining()]; buf.get(data); //Procesamos la peticin y creamos la respuesta String request = new String(data, "ISO-8859-1"); System.out.println("<<<<" + request); responses.put(channel, request.toUpperCase()); key.interestOps(SelectionKey.OP_WRITE); //Inters en evento de escritura } ...

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-8859-1")); 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 conexin se ha cerrado //o tiene algn tipo de problema } }
Tiempo til en un servidor basado en eventos

Servidor Iterativo Servidor multihilo Servidor eventos
Hilo en ejecucin
Todas las operaciones de entrada/salida se gestionan a travs del bucle de gestin de eventos (sockets, ficheros, etc)
Tiempo
Leccin 4.5: Modelos multinivel

Modelos cliente-servidor en mltiples niveles

El modelo tradicional cliente-servidor se denomina tambin modelo en dos niveles La experiencia muestra que el modelo en dos niveles Presenta problemas de escalabilidad Un servidor que deba implementar una lgica 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 rgido a la hora de introducir modificaciones sobre la lgica de la aplicacin Cambios en el reparto de las tareas asociadas a la lgica de la aplicacin suponen cientos/miles/millones de actualizaciones de clientes Dificulta la evolucin 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 lgica de negocio y los servicios, dependiendo del modelo arquitectural que se elija
Middle tier
Es un proceso independiente que suele residir en su propio nodo de procesamiento Se ocupa de proporcionar a la aplicacin 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
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 lgica de negocio de la aplicacin

Los clientes suelen ser muy simples (i.e. navegadores web) Nivel intermedio como cola de mensajes El nivel intermedio es un gestor de mensajes asncronos 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 introduccin de un intermediario que gestiona las peticiones

Veremos este tipo de arquitectura en detalle cuando estudiemos CORBA
Arquitecturas en N niveles
En los ltimos aos, 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 provisin de servicios entre el cliente los datos de aplicacin La inclusin de mltiples 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
Leccin 4.6: Java Servlets

Los servlets de Java

La Java Servlet API es una API diseada para el desarrollo de servidores basados en un protocolo de peticin-respuesta Suele utilizarse en el contexto de aplicaciones web (usando HTTP) Permite aadir contenido dinmico sobre los documentos web que se devuelven Hay otras tecnologas de pginas activas similares (PHP, ASP, CGI, etc.) La idea es la misma en todos los casos El cliente (navegador) enva una peticin HTTP parametrizada al servidor
El servidor ejecuta un programa que utiliza esos parmetros

Como resultado de esa ejecucin, se obtiene un documento web El documento web es enviado como respuesta al cliente Estas tecnologas son muy utilizadas en el desarrollo de modelos de 3 niveles Cliente: El navegador que contiene la capa de presentacin Nivel intermedio: El servlet, que contiene la lgica de la aplicacin Nivel de datos: Servidores de BBDD que contienen los datos de la aplicacin
HTTP: Funcionamiento bsico

En el protocolo HTTP hay dos tipos de mensajes Mensajes de peticin: 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
Lnea inicial Cabecera-X: Valor-X Cabecera-Y: Valor-Y Mensaje HTTP Cabecera-Z: Valor-Z CRLF Lnea en blanco CRLF CRLF CRLF CRLF Cabeceras opcionales CR: Carriage Return ASCII 13 LF: Line Feed ASCII 10
Cabecera (Header) Cuerpo (Body)

Peticin: Datos adicionales Respuesta: Recursos solicitados El cuerpo es opcional en ambos casos
HTTP: Mensajes de peticin

Mtodo: HTTP 1.0 GET: Solicita la recuperacin de un recurso POST: Solicita un recurso, pero permite que el cliente enve informacin adicional al servidor en el cuerpo del mensaje HEAD: Solicita informacin 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
mtodo sp recurso sp versin CRLF CRLF CRLF CRLF CRLF sp = espacio en blanco CRLF = ASCII-CR (13) + ASCI-LF(10)
nombre de cabecera nombre de cabecera nombre de cabecera nombre de cabecera
: valor de cabecera : valor de cabecera : valor de cabecera : valor de cabecera
CRLF
Cuerpo opcional del mensaje de peticin

Recurso: Identificador del recurso sobre el que se realizar la accin. Suele coincidir con la seccin 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 enve informacin adicional al servidor a travs de GET (con POST esta informacin viaja en el cuerpo del mensaje)
mtodo
sp
recurso
sp
versin
CRLF CRLF CRLF CRLF CRLF
nombre de cabecera nombre de cabecera nombre de cabecera nombre de cabecera CRLF


Versin: Versin del protocolo que se est utilizando en el cliente. En la actualidad slo existen dos opciones: HTTP/1.0 HTTP/1.1 En general es de la forma HTTP/x.y
mtodo
sp
recurso
sp
versin
CRLF

Cabeceras: HTTP 1.0 Pueden aparecer 0 o ms 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 2.2.15 i586; Nav)
mtodo sp recurso sp versin CRLF CRLF CRLF CRLF CRLF
CRLF

Cuerpo: GET, HEAD, DELETE: No aparece POST: Permite enviar informacin adicional al cliente (p.e. de formularios, etc). Esta informacin 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
mtodo
sp
recurso
sp
versin
CRLF
HTTP: Mensajes de respuesta

Versin: Versin del protocolo que utiliza el servidor. En la actualidad slo existen dos opciones: HTTP/1.0 HTTP/1.1 Si el servidor soporta ambas, debe contestar, preferentemente, con la versin que haya utilizado el cliente en la peticin.
versin
sp
cdigo de estado
sp
descripcin CRLF CRLF CRLF CRLF CRLF
CRLF

Cdigo de estado y descripcin: Cdigo numrico que indica el resultado de la peticin. Viene asociado con la descripcin, que el un texto descriptivo de ese estado legible por un ser humano. 2xx: Resultado exitoso 3xx: Redireccin del cliente a otra URL 4xx: Error en la peticin del cliente 5xx: Error en el servidor 200 OK: La peticin 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.) versin sp cdigo de estado sp descripcin CRLF CRLF CRLF CRLF CRLF
CRLF

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
versin
sp
cdigo de estado
sp
descripcin CRLF CRLF CRLF CRLF CRLF
CRLF

Cuerpo: Dependiendo del mtodo 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:
versin sp cdigo de estado sp descripcin CRLF CRLF CRLF CRLF CRLF
CRLF

Ejemplo: ________________________________________________________________________ HTTP/1.1 200 OK Date: Tue, 23 Jan 2001 12:44:27 GMT Server: Apache/1.3.9 (Unix) Debian/GNU Last-Modified: Tue, 23 Jan 2001 12:39:45 GMT Content-Length: 34 Content-type: text/html <html>Esto es una prueba </html> __________________________________________________________________
versin sp cdigo de estado sp descripcin CRLF CRLF CRLF CRLF CRLF
CRLF
Cliente
HTTP en accin: ejemplo bsico
Servidor
Aplicacin (navegador web)
Paso 1 El usuario introduce la URL a la que quiere conectarse en el navegador web: Ejemplo: http://www.google.com/
Aplicacin (servidor web)
S.O.
S.O.
Internet
Cliente
Servidor
Paso 2 El navegador resuelve el nombre de dominio de la URL indicada y obtiene la direccin IP del servidor en el que se localiza el recurso
S.O.
S.O.
Internet
Cliente
Servidor
S.O.
Paso 3 El navegador crea un socket TCP y lana una conexin entre el mismo y el servidor. Obsrvese que se conocen la direccin IP y el puerto (80) donde est escuchando el servidor
S.O.
Internet
Cliente
Servidor

GET / HTTP/1.0 User-Agent: Mozilla/8.0
Paso 4 El cliente crea el mensaje HTTP de peticin solicitando el recurso deseado y lo enva a travs de la conexin
S.O.
S.O.
Internet
Cliente
Servidor
Paso 5 El servidor analiza la peticin 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 Aplicacin
(servidor web)
S.O.
S.O.
Internet
Cliente

HTTP/1.0 200 OK Server: Apache 1.3.2 Content-Type: text/html Content-Length: 8654
Servidor
Paso 6 El servidor construye el mensaje de respuesta, incluyendo el recurso solicitado en el cuerpo del mensaje (asumimos que no se produce ningn error)
S.O.
S.O.
Internet
Cliente

HTTP/1.0 200 OK Server: Apache 1.3.2 Content-Type: text/html Content-Length: 8654
Servidor
Paso 7 El servidor enva el mensaje de respuesta al cliente, con el recurso solicitado dentro del cuerpo del mismo
S.O.
S.O.
Internet
Cliente
Servidor
Paso 8 El cliente recupera el recurso solicitado y cierra la conexin con el servidor. Acto seguido puede representar el recurso como considere oportuno
S.O.
S.O.
Internet
Paso de parmetros en las peticiones HTTP

El lenguaje HTML permite la inclusin de formularios en las pginas web En un formulario, el usuario introduce informacin sobre la pgina Cada elemento de informacin viene identificado por un nombre
<html> <head><title>Pgina 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> Opcin: <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>

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> Opcin: <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">







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> Opcin: <SELECT NAME="producto"> ... Reset: ... Submit: ...
</FORM>
Peticin 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 Parmetros como pares nombre=valor codificados en formato URLEncoded
Qu sucede si el mtodo es POST? POST /index.html HTTP/1.1 Host: localhost Content-type: application/x-www-form-urlencoded Content-length: ... ... Tema IV: El paradigma Cliente-Servidor nombre=Luis+L%F3pez&clave=rata3&rapido=on&pago=visa&producto=DVD HTTP/1.1
Las pginas 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 Recepcin del mensaje de peticin Anlisis del mensaje + decodificacin Cliente String nombre=Luis Lpez String clave = rata String producto = DVD
Invocacin de un procedimiento o mtodo que toma los parmetros

Pgina dinmica: ASP, PHP, servlet <HTML> Pgina dinmica</HTML> HTTP/1.1 200 OK Content-type: text/html Content-length: <HTML> Pgina dinmica</HTML>
Codificacin + envo de respuesta
La API de Servlets de Java

La API de Servlets de Java es una API que permite escribir pginas activas de servidor utilizando directamente el lenguaje de programacin Java Hay dos paquetes fundamentales en esta API: javax.servlet Sirve para escribir pginas activas de servidor con cualquier protocolo de peticin respuesta que se base en sockets TCP El aplanamiento/desaplanamiento de los mensajes es responsabilidad del programador se la pgina activa javax.servlet.http Sirve para escribir pginas activas de servidor bajo HTTP El aplanamiento/desaplanamiento del mensaje HTTP es automtico El programador se puede concentrar en el desarrollo de la lgica 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.
Escribiendo servlets HTTP

Un servlet HTTP es una clase que extiende javax.servlet.http.HttpServlet El servlet redefine un conjunto de mtodos asociados a las peticiones HTTP que pueden recibirse. Normalmente se hace con los mtodos 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 tecnologas (PHP, ASP), el mapeo es automtico, quedando asociado la pgina activa con la localizacin fsica del recurso en el rbol de directorios
POST /index.html HTTP/1.1 Host: localhost ...
public class Serv1 extends { Contenedor public void doGet() { public void doPost() { public class Serv2 extends { public void doGet() {
GET /pag1 HTTP/1.1 Host: localhost
Recurso /pag1 /index.html /caja
Servlet Serv1 Serv2 Serv3
public void doPost() { public class Serv2 extends {
public void doGet() {

public void doPost() {
Escribiendo servlets HTTP Cont.

Servlet HTTP que implementa un Hola mundo Se puede escribir sobre la pgina 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>"); } }
Recuperando parmetros 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> Opcin: <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); }
Aplicaciones HTTP con estado

HTTP fue diseado como un protocolo sin estados Esta restriccin limita enormemente la viabilidad de uso del protocolo en aplicaciones con lgica 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 bsica 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 informacin siguiente: Un nombre: En forma de cadena de caracteres Un valor: Se utiliza para dotar de unicidad a la sesin Una fecha de expiracin: 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
La cabecera Set-Cookie
La RFC 2109 define la cabecera Set-Cookie como mecanismo para que un servidor enve 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 Mxima 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 aade un segundo formato en la cabecera Set-Cookie2 que incorpora informaciones adicionales tales como: puertos que aplican, flag Discard, posibilidad de insertar comentarios de varios tipos, etc. Aun con esas diferencias, el fundamento del mecanismo en ambas RFCs es el mismo, vamos a estudiarlo aplicado a la 2109 por simplicidad
La cabecera Set-Cookie 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: http://www.tienda.com/main/shop/menu.php El navegador crea un paquete HTTP para esa peticin y lo enva al servidor correspondiente
S.O.
S.O.
Internet
GET /main/shop/menu.php HTTP/1.1 Host: www.tienda.com

El servidor recibe la peticin 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 parmetros asociados a la misma: nombre, valor, fecha, etc. En este caso el servidor deposita la cookie utilizando la cabecera Set-Cookie
S.O.
S.O.
HTTP/1.1 200 OK Internet Set-Cookie: shopC=123141121;Max-Age=3600; path=/main/shop;domain=.www.tienda.com ...

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 expiracin El navegador suele tener un fichero en el que almacena todas las cookies activas
S.O.
shopC ...
Antes de enviar una peticin (cualquiera que sea) el navegador chequea si es necesario incluir una o varias cookies en la peticin HTTP
S.O.
Internet
La cabecera Cookie
La RFC 2109 define la cabecera Cookie como mecanismo para que un cliente enve cookies a un servidor (en mensajes de respuesta HTTP) Con cookies habilitadas, cada vez que el navegador enva un peticin HTTP debe comprobar si es necesario incluir una o varias cookies en la peticin
El navegador determina qu cookies es necesario incluir haciendo lo siguiente:

Se recupera el URI que identifica el recurso de la peticin Se recupera el nombre de dominio del servidor al que va dirigida la peticin En la peticin, se incluyen todas las cookies que cumplan lo siguiente: La cookie est activa (no ha expirado) La URI de la peticin 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 peticin es subdominio del domain de la cookie. Es decir, el nombre de dominio termina por la derecha con el domain El modo de transmisin (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 envan en una sola cabecera del tipo Cookie: nombreCookie=valorCookie; otroNombre=otroValor; nombre=valor
La cabecera cookie: ejemplos

Cookies almacenadas en el navegador
name=shopC value=1214512341 expires=31 Jan 2006 00:00:00 GMT path=/main/shop domain=.www.tienda.com secure=no name=spyC value=afda2tg3q34g expires=1 Jan 2006 00:00:00 GMT path=/ domain=.site.com secure=no name=varYes value=xc124das234s expires=1 Jan 1974 01:14:00 GMT path=/dir/z_files domain=.com secure=yes name=shopS value=1358372772 expires=31 Jan 2006 00:00:00 GMT path=/ domain=.tienda.com secure=yes La cookie se incluye siempre La cookie se incluye con canal seguro Fecha: 31 Dec 2005 12:00:00 GMT
GET /main/shop/menu.php HTTP/1.1 Host: www.tienda.com
GET /index.html HTTP/1.1 Host: www.tienda.com
GET /main/shop/file.php HTTP/1.1 Host: casas.tienda.com
GET /dir/z_files/g.asp HTTP/1.1 Host: www.site.com
GET /z_files/file HTTP/1.1 Host: www.tienda.com
La cabecera cookie en funcionamiento

Cada vez que el cliente enva una peticin HTTP, chequea las cookies para ver si tiene que incluir alguna de ellas
La inclusin de una cookie permite devolver al servidor el valor que este deposit en la misma
S.O.
shopC ...
S.O.
GET /main/shop/products.php Internet Host: www.tienda.com Cookie: shopC=123141121 ...
La cabecera cookie en funcionamiento

Al recibir la peticin, el servidor recupera el par nombre/valor de la cookie Con ese par nombre valor es posible establecer variables de sesin que conservan estado Ejemplos: El valor de la cookie es un identificador nico que acta como llave en una tabla hash
S.O.
shopC ...
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 informacin de sesin
S.O.
Internet
Servlets y sesiones
Es posible utilizar variables de sesin dentro de la API de servlets HTTP puede soportar sesiones basadas en Uso de cookies: Cada sesin est asociada a un identificador nico que el cliente enva al servidor en cada peticin que se realiza dentro de una cabecera cookie URL-rewriting: Cada sesin est asociada a un identificador nico que el cliente enva 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 pginas (bien dentro de anclas, bien dentro de atributos ACTION) contienen el citado identificador nico Las variables de sesin Permiten la persistencia de datos asociados a un mismo cliente a lo largo de una sesin (un conjunto de pares peticin/respuesta) El programador puede crear variables de sesin, asignarles un valor u obtener el valor previo El programador puede invalidar la sesin borrando todas las variables previamente establecidas Muchos entornos de pginas activas (PHP, ASP, etc.) permiten que una sesin se invalide automticamente tras cierto tiempo de inactividad
<HTML> <HEAD> <TITLE>Formulario de comercio electrnico</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="Aadir regalo a mi lista"> </FORM> <P><HR><BR><HR><BR> </BODY> </HTML>
Uso de sesiones: el carrito de la compra

public class CarritoServlet extends HttpServlet { public void doGet( HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException { //Recuperamos la sesin 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 sesin que tiene la lista ArrayList lista = (ArrayList)session.getAttribute("listaDeLaCompra"); if(lista == null) lista = new ArrayList(); //Aadimos el nuevo producto elegido por el usuario String producto = (String)request.getParameter("regalo"); lista.add(producto); session.setAttribute("listaDeLaCompra", lista); ... } }

public class CarritoServlet extends HttpServlet { public void doGet( HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException { ... //Imprimimos la pgina 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>"); } }
Leccin 1.6: Comentarios y referencias

Comentarios y reflexiones Qu significa el trmino modelo cliente-sevidor? Por qu tiene tantos significados? Qu es un cliente gordo? y uno flaco? Qu relacin 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 aplicacin? 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, Computacin 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.
Leccin 1.6: Resumen

Contenidos El paradigma cliente-servidor Concepto El modelo cliente servidor como abstraccin El modelo cliente servidor como patrn arquitectural El modelo cliente servidor como arquitectura de sistema Clientes y servidores Tipos de clientes y tipos de servidores Localizacin de la lgica de la aplicacin Mecanismos de cach Concepto Parmetros 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 tecnologa web Desarrollo de servidores basados en la API de Java Servlets

TIV ClienteServidor

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

TIV ClienteServidor

Diunggah oleh

Hak Cipta:

Format Tersedia

Tema IV: El Paradigma Cliente-Servidor

Luis Lpez Fernndez

Tema IV: Contenidos

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

Leccin 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

Tema IV: El paradigma Cliente-Servidor

El paradigma cliente-servidor como abstraccin

Especifica el modelo de dilogo basado en peticin-respuesta

Tema IV: El paradigma Cliente-Servidor

El paradigma cliente-servidor como arquitectura software

Patrn arquitectural pliente-servidor

Servicios de red, ORB RPC y RMI Cliente-servidor

Paso de mensajes Modelo OSI, modelo TCP/IP Hardware

Tema IV: El paradigma Cliente-Servidor

Patrn arquitectural peer-to-peer

El paradigma cliente-servidor como arquitectura software

Tema IV: El paradigma Cliente-Servidor

El paradigma cliente-servidor como patrn de protocolo

Por qu, entonces, se denomina Server a este tipo de socket?

Tema IV: El paradigma Cliente-Servidor

El paradigma cliente-servidor como arquitectura de sistema

Arquitectura de red con dos servidores y tres PCs

Tema IV: El paradigma Cliente-Servidor

Leccin 4.2: Clientes y servidores

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

Tema IV: El paradigma Cliente-Servidor

Clientes y servidores: quin hace qu?

Puede residir parte en el cliente y parte en el servidor

Capa de presentacin Lgica de la aplicacin/negocio Capa de Servicios

Ejemplos de aplicaciones cliente/servidor

No hay mucha lgica de negocio en un servidor/cliente web clsico

Ejemplos de aplicaciones cliente/servidor

Comprobacin del nmero de tarjeta de crdito

La capa de servicios debe proporcionar, entre otros

Tema IV: El paradigma Cliente-Servidor

Ejemplos de aplicaciones cliente/servidor

La tabla de materiales (materias primas para producir productos)

Tema IV: El paradigma Cliente-Servidor

Ejemplos de aplicaciones cliente/servidor

Tema IV: El paradigma Cliente-Servidor

Ejemplos de aplicaciones cliente/servidor

Tema IV: El paradigma Cliente-Servidor

Clientes gordos, flacos e hbridos

Requiere capacidad de proceso y, normalmente, capacidad de almacenamiento

Tema IV: El paradigma Cliente-Servidor

Servidores con estados y sin estados

Tema IV: El paradigma Cliente-Servidor