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

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


Lección 4.1: El paradigma cliente-servidorLección 4.1: 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


•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


•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


•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


•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


•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


Lección 4.2: Clientes y servidoresLección 4.2: Clientes y servidores








•El cliente es la parte de la aplicación que interacciona con el usuario•El cliente no comparte (sus recursos no son “vistos” por otros clientes)•El cliente no tiene restricciones especiales en términos de

•Prestaciones: No suelen requerir capacidades especiales•Fiabilidad: Si falla un cliente, el resto del sistema puede seguir funcionando•Escalabilidad: Cada cliente ejecuta en su propio ordenador

•El cliente tiene restricciones especiales en términos de•Ergonomía: Debe adaptarse a la interacción con el usuario•Seguridad: No debe comprometer la seguridad de otras aplicaciones

•El servidor es la parte de la aplicación que presta servicios al cliente•El servidor comparte sus recursos con todos los clientes que lo usan•El servidor tiene restricciones especiales en términos de

•Prestaciones: Cuando queremos que numerosos clientes lo usen•Fiabilidad: Si el servidor falla, los clientes no pueden continuar•Escalabilidad: Queremos que el número de clientes pueda si se requiere•Seguridad: No debe comprometer la seguridad de los clientes ni de los datos

•El servidor no tiene prestaciones especiales en términos de•Ergonomía: Lo controla un administrador experto

Clientes y ServidoresClientes y Servidores


•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


•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


•Un servicio WWW de comercio electrónico (con páginas activas, por supuesto):

•La capa de presentación requiere, entre otros:

•Capacidad para representar documentos HTML

•Capacidad para representar imágenes en diferentes formatos

•Capacidad para representar e interpretar otros tipos datos (pdf, applets, etc.)

•La lógica de la aplicación requiere, entre otros:

•Comprobación del número de tarjeta de crédito

•Gestión de los inventarios (actualizar stock, pedir más, etc.)

•Gestión de los pedidos (realizar acciones para envío del pedido)

•Gestión contable (actualizar tesorería con ingresos por venta, etc.)

•La capa de servicios debe proporcionar, entre otros

•La implementación del protocolo HTTPS

•Capacidad para acceder a las diferentes bases de datos

•Capacidad para comunicar con servicios bancarios

•Servicios transaccionales


C

C

C

C

S

S

SS

S

S

S

S


•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



•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



•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?



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


•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


•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



•Ejemplo: Servidor 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


•Ejemplo: Servidor con 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


Lección 4.3: Mecanismos de cachéLección 4.3: Mecanismos de caché








•El mecanismo de caché, en el contexto de las redes de ordenadores, consiste en duplicar (una parte de) los datos que posee un nodo, en otro distinto del original, con el objetivo de mejorar las prestaciones del acceso a los mismos

•Las cachés son un elemento esencial de las aplicaciones cliente-servidor

•Para comprender el funcionamiento de una caché observemos lo siguiente:

La caché es un repositorio de información que debe encontrarse localizado entre el cliente y el servidor. Es decir, debe poder “ver” e interceptar los

mensajes que se intercambian

Mecanismos de CachéMecanismos de Caché

caché

clientes

servidor





La primera vez que el cliente solicita la información, esta se descarga desde el servidor, pero la caché se “guarda” una copia


caché

clientes

servidor





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


caché

clientes

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?


•¿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


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


•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

...


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

...


...

GET recurso HTTP/1.1...

if (now() < tCaduc) recurso es válidoelse recurso es inválido


...

clientes caché Servidor

200 OKDate: tReespuesta Etag: 4ad4dx23...


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


Lección 4.4: Desarrollo de clientes y servidoresLección 4.4: Desarrollo de clientes y servidores








•El desarrollo de un cliente puede ser complicado si requiere una GUI compleja o tiene una lógica de negocio difícil. Ambos aspectos están fuera de esta asignatura

•Desde el punto de vista de las comunicaciones, lo esencial sobre el cliente ya lo hemos tratado en temas anteriores (sockets, aplanamiento, formatos, etc.)

•El servidor, sin embargo, además de implementar el servicio de comunicaciones, debe ser diseñado con objetivos de escalabilidad en mente

•Un servidor tanto más útil cuantos más clientes lo comparten

•¿Cómo podemos lograr que muchos clientes compartan un mismo servidor?

•Hay muchas soluciones, las más habituales son

•Usar un modelo de servidor multihilo

•Usa operaciones de comunicaciones (sockets) bloqueantes

•El desarrollo del servidor es más intuitivo

•La mayor complejidad viene de la necesidad del control de concurrencia

•Usar un modelo de servidor basado en eventos

•Usa operaciones de comunicaciones (sockets) no bloqueantes

•El desarrollo es más enrevesado

•Nos libramos del control de concurrencia y de los múltiples hilos

Desarrollo de clientes y servidoresDesarrollo de clientes y servidores


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


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();

}}


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)


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


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();

}}

}


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}

}


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


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();

}}

}}


Tiempo útil en el servidor multihiloTiempo útil en el servidor multihilo

Hilo en ejecución


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.


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?


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();

}}

...


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

}...


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

}}


Tiempo útil en un servidor basado en eventosTiempo útil en un servidor basado en eventos

Hilo en ejecución


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)


Lección 4.5: Modelos multinivelLección 4.5: Modelos multinivel








•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


•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


•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


•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


Lección 4.6: Java ServletsLección 4.6: Java Servlets








•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


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


HTTP: Mensajes de peticiónHTTP: Mensajes de petición

método sp recurso sp versión 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)







CRLF


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)









CRLF


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








CRLF


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)








CRLF


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


HTTP: Mensajes de respuestaHTTP: Mensajes de respuesta

versión sp código de estado sp descripción CRLF





CRLF


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.








CRLF


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








CRLF


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








CRLF


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:








CRLF


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


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/

http://images.google.es/imgres?imgurl=http://powerfulwebsites.com/uploaded_graphics/fab.os.logo.apache.200.150.jpg&imgrefurl=http://powerfulwebsites.com/the_engine/open_source.html&h=150&w=200&sz=10&tbnid=vnROxN7AuLMJ:&tbnh=74&tbnw=99&hl=es&start=7&prev=/images%3Fq%3Dapache%2Bhttp%26svnum%3D10%26hl%3Des%26lr%3D



InternetInternet

S.O. S.O.



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




InternetInternet

S.O. S.O.



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




InternetInternet

S.O. S.O.



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




InternetInternet

S.O. S.O.



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




InternetInternet

S.O. S.O.



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




InternetInternet

S.O. S.O.



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




InternetInternet

S.O. S.O.



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



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



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



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


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 …


•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


•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(…) {…







POST /index.html HTTP/1.1Host: localhost...

GET /pag1 HTTP/1.1Host: localhost


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


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);

}}


•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


•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


La cabecera Set-Cookie en funcionamientoLa cabecera Set-Cookie en funcionamiento

InternetInternet

S.O. S.O.



•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




InternetInternet

S.O. S.O.



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



InternetInternet

S.O. S.O.



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


•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


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


La cabecera cookie en funcionamientoLa cabecera cookie en funcionamiento

InternetInternet

S.O. S.O.



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


La cabecera cookie en funcionamientoLa cabecera cookie en funcionamiento

InternetInternet

S.O. S.O.



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


•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


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>


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);

...}

}


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.


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


Documents

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