+
Sistemas Distribuidos
Middleware
Rodrigo Santamaría
+ Middleware
• Introducción
• Middleware de bajo nivel
• Invocación remota
2
+ 3
Introducción
Middleware: es una capa
software que:
Enmascara la heterogeneidad Aplicaciones y servicios
de la red subyacente, el
hardware, el sistema
Invocación remota
Middleware
operativo y los lenguajes de RMI, RPC, CORBA
programación
Ofrece un modelo Primitivas de comunicación
computacional para los marshalling, apoyo a multicast, virtualización
programadores de
Plataforma
aplicaciones distribuidas sistema operativo
Capa de transporte: UDP y TCP
Plataforma
red, hardware
+ 4
Introducción
UDP y TCP
Protocolos de nivel de transporte de Internet
Ambos permiten un paso de mensajes básico
UDP: con fallos por omisión
TCP: garantiza la entrega en condiciones normales, pero al coste de
una bajada en el rendimiento
Generalmente, usamos TCP sobre IP, o TCP/IP
Aunque TCP/UDP abstraen del nivel de red, no abstraen
perfectamente de los niveles de hardware y ssoo
Distinto almacenamiento de números (little endian/big endian)
Distinta codificación de caracteres (ASCII/Unicode)
Etc.
+ 5
Introducción
Middleware vs TCP/IP
TCP/IP: transmisión de bytes mediante de TCP/UDP+IP
Middleware: transmisión de mensajes sobre TCP/UDP+IP
Java RMI
HTTP Web Service
socket socket
TCP/IP TCP/IP
[Link]
+ 6
Introducción
Tipos de middleware
Bajo nivel
Ofrece funcionalidades esenciales, generalmente
relacionadas con cambios sobre el soporte básico TCP/UDP
+ IP
Representación independiente de SSOO (marshalling)
Multicast sobre IP
Red virtual sobre la red IP subyacente
Alto nivel (invocación remota)
Centrada en el envío/recepción de datos
Remote Procedure Call (RPC)
Remote Method Invocation (RMI)
+ Middleware
• Introducción
• Middleware de bajo nivel
• Marshalling
• Redes superpuestas
• Invocación remota
7
+ 8
Marshalling
Proceso de ensamblado de datos de forma que puedan
ser convenientemente transmitidos en un mensaje
Traducción de los valores locales a una representación
externa
Alternativas de marshalling
CORBA Common Data Representation (CDR)
Serialización Java
XML (eXtensible Markup Language)
Sun XDR
…
+ 9
Marshalling en la Tierra Media
Lengua común*
* [Link]
+ 10
Marshalling
CORBA CDR
CORBA CDR se define en CORBA 2.0 (2004)
Permite representar los tipos de datos manejados por CORBA
El tipo de dato no está incluido en la representación del dato
Requiere conocimiento de los tipos por ambas partes
Colouris et al. 2011
Representación en CDR de una
estructura Person{string, string, long}
para el valor {‘Smith’, ‘London’, 1984}
+ 11
Marshalling
Serialización Java
Permite representar objetos Java de un modo adecuado
para almacenarlos en disco o transmitirlos
La representación incluye
Estado del objeto
Definición de su clase (nombre, versión)
Definición de otras clases (heredadas, implementadas) a
través de referencias o handles
+ 12
Marshalling
Serialización Java
public class Person implements Serializable {
private String name;
private String place;
private int year;
public Person(String aName, String aPlace, int aYear) {
name = aName;
place = aPlace; year = aYear;
}
// followed by methods for accessing the instance variables
}
Person p = new Person("Smith", "London", 1984);
Colouris et al. 2011
+ 13
Marshalling
Extensible Markup Language (XML)
Definido por el W3C para su uso general en Internet1
Modo de codificación textual que representa tanto el
contenido como los detalles de su estructura o apariencia
Cada dato en un fichero XML va etiquetado
Las etiquetas pueden servir para definir la estructura
O para asociar pares atributo-valor
<person id="123456789">
id es un atributo
<name>Smith</name> person, name, place o year son elementos
<place>London</place> name, place y year son elementos
<year>1984</year> contenidos en person
<!-- a comment -->
</person >
1
Proviene, junto con HMTL, de SGML, un lenguaje de marcas muy complicado. HTML se diseñó para definir la
apariencia de las páginas web, mientras que XML se diseñó para escribir documentos estructurados para la web
+ 14
Marshalling
Comparativa
Marshalling Conocimiento previo Tipos de datos
CORBA Sí Cualquiera del lenguaje
Java No* Cualquiera del lenguaje
XML No Texto
Imagina que queremos coordinar dos nodos:
• Un servidor con una base de datos que ofrece un servicio de consultas SQL.
• Un cliente en python que procesa y visualiza datos obtenidos (entre otras fuentes) del servidor
anterior.
¿Qué tipo de marshalling de los vistos hasta ahora te parece más adecuado? ¿Por qué?
A pesar de ser el más adecuado, ¿crees que se le podría sacar alguna desventaja?
+ 15
Redes superpuestas
Red superpuesta (overlay network)
Red virtual consistente en nodos reales y enlaces virtuales,
construida sobre una red subyacente (típicamente IP)
Ofrece funcionalidades adicionales
Servicio optimizado a las necesidades de una aplicación
Operación más eficiente en un determinado entorno de red
Características adicionales, como multicast o seguridad
Algunos ejemplos:
Redes P2P (ahorro de espacio y ancho de banda en servidores)
Redes multijugador (velocidad de descarga)
Redes TOR (anonimato)
+ 16
Redes superpuestas
Caso de Estudio: Skype
Sistema de gran escala: 370 millones de usuarios
en 2009
Skype funciona como una red superpuesta que
establece conexiones entre suscriptores de su
servicio
No se requiere una IP o puerto para hacer la llamada
Infraestructura P2P con hosts y super nodos (SN)
Conexión centralizada (autenticación en un login
server + asignación SN)
Búsqueda de usuarios mediante SNs (~3-4s, ~8SN
visitados)
La transmisión se hace generalmente vía UDP
Software especial para la codificación de
audio/vídeo
¿Por qué crees que Skype hace
la transmisión mediante UDP?
+ 17
Redes superpuestas
Caso de Estudio: red Tor
Red superpuesta a IP para separar identificación de enrutado
36 millones de usuarios en 2011
[Link]
+ Middleware
• Introducción
• Middleware de bajo nivel
• Invocación remota
• Petición-respuesta
• Remote Procedure Call
• Remote Method Invocation
18
+ 19
Invocación remota
Los conceptos de middleware a alto nivel se centran en cómo
los procesos se comunican en un sistema distribuido
Hay tres paradigmas de invocación remota
Protocolos de petición-respuesta, un modo relativamente a
bajo nivel para ejecutar una operación remota.
Sienta las bases para RPC y RMI
Remote procedure call (RPC) es el primer modelo (y el más
conocido) para facilitar las llamadas a servidores remotos
Remote method invocation (RMI) extensión de RP para la
llamada a métodos de objetos en nodos remotos
+ 20
Protocolo de petición-respuesta
Se basa en tres primitivas de comunicación
doOperation(s,args): invoca una operación remota en s, con los
argumentos indicados en args (parámetros y tipo de operación)
getRequest: espera/adquiere una petición en el servidor
sendReply(r,c): manda el mensaje de respuesta r al cliente c
Colouris et al. 2011
+ 21
Protocolo de petición-respuesta
Modelo de fallo
Por omisión: el servidor no responde o el mensaje se pierde
doOperation puede implementar un timeout en su espera por el
mensaje de respuesta.
Repite la petición o determina que el servidor está caído (tras un
determinado número de intentos)
Bizantino: el servidor recibe peticiones duplicadas
Puede implementar un mecanismo para descartarlas si todavía
está realizando la operación
Si ya la ha realizado y la operación es idempotente, la realiza de
nuevo
Si no, puede implementar un histórico con los resultados de las
operaciones realizadas
+ 22
Protocolo de petición-respuesta
Variaciones
Variaciones sobre el protocolo petición-respuesta
Request (R): cuando no hay valor de retorno y no se requiere
confirmación de que la operación se ha realizado
Request-Reply (RR): el protocolo básico
Request-reply-acknowledge (RRA): permite borrar del histórico
las respuestas de las que obtiene acuso de recibo (A).
Protocolo Mensajes enviados por
Cliente Servidor Cliente
R Request
RR Request Reply
RRA Request Reply Acknowledge reply
+ 23
Protocolo de petición-respuesta
Caso de estudio: HTTP
HTTP es un buen ejemplo de protocolo de petición-respuesta
Protocolo para hacer peticiones a servidores web
Páginas HTML
Applets
Servlets
Las peticiones especifican una URL que incluye
El DNS del host servidor
Número de puerto (opcional)
Identificador de un recurso
Fija una serie de tipos de petición: PUT, GET, POST, UPDATE.
+ 24
Protocolo de petición-respuesta
HTTP: GET y POST
GET: pide el recurso cuya URL se da como argumento.
Si es un dato, el servidor lo retorna
Si es un programa, el servidor lo ejecuta y devuelve su salida
Se pueden añadir argumentos a la URL para el programa
Colouris et al. 2011
petición
respuesta
POST: especifica la URL de un recurso que pueda tratar con los
datos suministrados en el cuerpo del mensaje
Postear en una lista de correo/modificar un perfil web
Añadir entradas a una base de datos
Proveer datos a un programa ([Link]. un formulario)
+ 25
Remote Procedure Call
Objetivo: hacer la programación distribuida similar, si no
igual, a la programación convencional
Procedimiento: extender las llamadas a procedimientos
para que funcionen en entornos distribuidos
Los procedimientos ubicados en máquinas remotas se pueden
llamar como si fueran locales [Birrell & Nelson, 1984]
+ 26
Remote Procedure Call
Problemas de diseño: interfaces
Programación mediante interfaces
Casi todos los lenguajes modernos son modulares
La interfaz de cada módulo especifica la manera de usarlo
El resto del módulo permanece ‘oculto’
En un SD, los módulos pueden ejecutarse en procesos
separados
El paso de argumentos por referencia no está permitido
Los parámetros de salida van en un mensaje de respuesta
Lenguajes de definición de interfaz (IDL)
En un SD, los métodos a menudo están en diferentes lenguajes
Los IDLs permiten llamar procedimientos de otros lenguajes
Sun XDR, CORBA IDL o WSDL son algunos ejemplos de IDL
+ 27
Remote Procedure Call
Problemas de diseño: semántica de la llamada
Diversos modos de garantizar la entrega de mensajes
Reintentos: controla la retransmisión de la petición hasta que el
servidor la reciba o la asunción de que ha fallado
Filtro de duplicados: controla el uso de retransmisiones y si el
servidor descarta peticiones duplicadas
Retransmisión de resultados: controla si se debe mantener un
histórico de resultados para poder retransmitirlos si se pierden
Colouris et al. 2011
+ 28
Remote Procedure Call
Problemas de diseño: semántica de la llamada
Semántica “quizás”:
El procedimiento remoto se ejecuta 0 ó 1 veces
Fallos por omisión (mensaje de respuesta perdido)
Fallos de parada (falla el servidor o su operación remota)
Semántica “al menos uno”
El procedimiento remoto se ejecuta 1+ veces
Fallos de parada (falla el servidor)
Fallos arbitrarios (re-ejecución de la operación remota)
Semántica “como mucho uno”
El procedimiento remoto se ejecuta 0 ó 1 veces, pero si se
ejecuta 0 veces tenemos conocimiento de ello
+ 29
Remote Procedure Call
Problemas de diseño: transparencia
Birrell y Nelson [1984] intentaron hacer las RPC tan parecidas
a las llamadas locales como fuera posible
Todos los procedimientos de middleware a bajo nivel (marshalling,
etc.) se ocultan al programador.
Sin embargo, las llamadas remotas
Tienen más posibilidades de fallar que las locales y no se puede
determinar si fue un fallo de red o de proceso
Las aplicaciones deben poder recuperarse de estos fallos
Tienen una latencia mayor
Es conveniente minimizar las llamadas remotas
+ 30
Remote Procedure Call
Implementación
El cliente incluye un procedimiento stub (cabo) que realiza el marshalling y (en vez de
ejecutar el procedimiento) envía la petición y espera por la respuesta
El servidor tiene otro stub por cada procedimiento de servicio. Cuenta también con un
único despachador que selecciona el stub que hay que invocar dependiendo de la
petición recibida
Los módulos de comunicación (uno por proceso) direccionan el mensaje y se
encarga de posibles semánticas (retransmisiones, timeouts, duplicados, multicast, etc.)
Coulouris et al. 2011
+ 31
Remote Method Invocation
Extensiónde RPC para objetos distribuidos: un objeto
puede invocar un método de un objeto remoto.
Aspectos a tener en cuenta
Atributos: en un modelo orientado a objetos, se puede
acceder a atributos del objeto directamente
Referencias a objetos: cuando accedemos a un objeto, lo
hacemos a través de referencias.
Interfaces: definición de un método sin especificar su
implementación
Excepciones: si un método falla de manera controlada,
puede lanzar una excepción, pasando el control de la
ejecución al objeto que lo invocó
+ 32
Remote Method Invocation
Interfaz remota
objeto remoto
referencia Datos
interfaz
remota
m1 m1
proxy m2 m2
registro Métodos
m3
m4 El acceso local continúa
como siempre
● Cada objeto distribuido tendrá una interfaz remota indicando los métodos disponibles.
● Esa interfaz se anunciará mediante un registro (binding) y se instanciará a modo de proxy en los clientes
● Evita el acceso a atributos (referencia a memoria remota) y trata las referencias a objetos remotos como
proxies
+ 33
Remote Method Invocation
Implementación
Nodo 1
Nodo 2
Proceso Cliente
Proceso Servidor
A
B
petición
esqueleto y
despachador
de B
Proxy respuesta
de B
módulo de módulo de
comunicación comunicación
instancia
sirviente
módulo de
referencias remotas
módulo de
referencias remotas
+ 34
Remote Method Invocation
Implementación
Proxy: realiza la invocación remota transparente al cliente, comportándose como un objeto
local, pero en vez de ejecutar el método invocado, lo manda en un mensaje al servidor.
Despachador: recibe mensajes de petición del módulo de comunicación, selecciona el
método adecuado y pasa la petición al esqueleto
Esqueleto: implementa los métodos de la interfaz remota, recibiendo una petición
del despachador, realizando el unmarshalling e invocando al sirviente
Sirviente: instancia de una clase que provee el cuerpo de un objeto remoto. Es el que
realmente ejecuta las peticiones remotas
Módulo de referencias remotas: traduce las referencias locales a remotas (o viceversa)
Crea referencias remotas
Contiene una entrada por cada objeto remoto y por cada proxy
Módulo de comunicación: lleva a cabo el protocolo de petición-respuesta
Cuando llega una petición, el módulo de comunicación del servidor traduce la referencia
remota en una referencia local mediante el módulo de referencias remotas
Manda la referencia local junto con el mensaje al despachador
+ 35
Remote Method Invocation
Implementación
Nodo 1
Nodo 2
Proceso Cliente
Proceso Servidor
A
(1) petición (3) petición
ref remota ref local despachador
y esqueleto (4) petición/método
de B (5) unmarshalling
(2
Proxy respuesta
)tr
ad
de B
uc
sirviente (6) ejecución
c
módulo de módulo de
ió
n
comunicación comunicación
módulo de
referencias
remotas
módulo de B
referencias remotas
+ 36
Remote Method Invocation
Caso de estudio: Java RMI
Afortunadamente, la generación toda esta infraestructura es
automática y relativamente trasparente
Por ejemplo, en Java los objetos remotos deben implementar una
interfaz que herede de la clase Remote
Los métodos de esta interfaz serán accesibles vía remota
Estos métodos deben lanzar la excepción RemoteException
Utilizan un registroRMI para hacerse públicos
/**
* Interfaz para un servicio RMI de corredores de bolsa
* Debe heredar de [Link]
* Debe manejar RemoteException en sus métodos
*/
public interface CorredorDeBolsa extends Remote
{
String listarTitulos() throws RemoteException;
void comprar(String nombre, int cantidad) throws RemoteException;
void vender(String nombre, int cantidad) throws RemoteException;
}
+ 37
Remote Method Invocation
Caso de estudio: Java RMI
Nodo 1
Nodo 2
Proceso Cliente
Proceso Servidor
proxy de B
Remote
extends
Interfaz
implements
Objeto A
RMIregistry
[Link] (2)
[Link] (1)
Objeto B
nombre stub
38
+ 39
Referencias
G. Colouris, J. Dollimore, T. Kindberg and G. Blair.
Distributed Systems: Concepts and Design (5th Ed).
Addison-Wesley, 2011
Capítulo 4 para middleware de bajo nivel
Capítulo 5 para invocación remota
Sobre Java RMI
Seminario [Link] en la página web de la asignatura
+ 40
Resumen
El middleware es una capa El middleware de alto nivel resuelve
software que abstrae de los problemas de comunicación, mediante
esquemas de petición-respuesta (RR)
problemas de un sistema
distribuido El esquema RR debe tratar con fallos
arbitrarios o de omisión, utilizando
El middleware de bajo nivel se distintas estrategias (R, RR, RRA) que
encarga de resolver problemas de pueden necesitar de componentes
adicionales como timeouts o históricos de
heterogeneidad peticiones. Estas estrategias darán lugar
El marshalling trata los datos a distintas semánticas de comunicación
comunicados para crear (0+, 1+, 0-1)
representaciones homogéneas La implementación de estos esquemas en
Las redes superpuestas programación estructurada es RPC, que
mejoran problemas de trata llamadas a métodos remotos como
direccionamiento, movilidad y locales gracias a una arquitectura de
escala, apoyándose en las redes stubs y módulos de comunicación
de comunicación existentes La implementación en orientación a
Un ejemplo de red objetos es RMI, que permite invocar
superpuesta es el multicast métodos de objetos remotos gracias a
una combinación de publicación de
sobre IP, que se basa en este
interfaces y objetos proxy
protocolo para realizar
direccionamiento ‘simultáneo’
a varios nodos
41
[Link]