PDF de programación - Middleware. Modelos de interacción - Tema 4. Sistemas distribuidos

Tema%4.(
Sistemas(distribuidos(
Middleware.(Modelos(de(interacción.(
ICE(–(Internet(Communica8ons(Engine(

Marisol(García(Valls(

(



Departamento(de(Ingeniería(Telemá8ca(

Universidad(Carlos(III(de(Madrid(

[email protected]

Arquitectura(de(sistemas(II(

(

Grado(en(Ingeniería(Telemá8ca(
Curso:(3º,(cuatrimestre:(2º



Índice(

•  Conceptos(((

•  Estructura(de(comunicación(

•  Ejemplo(

©2017((Marisol(García(Valls((

(2(

Arquitectura(de(sistemas(II(Q(GIT(

BibliograSa(

•  Manual(de(Ice(3.5.1(
((((((((((hVp://download.zeroc.com/Ice/3.5/IceQ3.5.1.pdf(
(
Capítulo(1.1(Ice(overview(
Capítulo(1.2.(Wri8ng(a(HelloWorld(applica8on(
(((((1.2.1(Wri8ng(a(Slice(defini8on(
(((((1.2.2(Wri8ng(an(Ice(applica8on(in(C++((
(
Lecturas(no(exhaus8vas((consul8vas):(
•  En(el(libro(anterior:(The(Slice(language(
•  S.(B.(Lippman,(J.(Lajoie,(B.(E.(Moo.(
(((((C++(Primer.(5th(Edi8on.((AddisonQWesley.(2013.(

©2017((Marisol(García(Valls((

(3(

Arquitectura(de(sistemas(II(Q(GIT(

(Middleware(

Síncronos:(
•  RPC:(remote(procedure(call(
•  Orientado(a(objetos(e(invocaciones(remotas(

(RMI(de(Java(o((ICE)(

•  Componentes((CORBA)(

¡ Clasificación
no estricta !

Asíncronos:(
•  Orientado(a(mensajes((JMS)(
•  Publicación/suscripción((ICE,(DDS)(

©2017(Marisol(García(Valls((

(4(

Arquitectura(de(sistemas(II(Q(GIT(

Síncrono(vs.(Asíncrono(

•  Middleware(síncrono(
((((((invocación(remota)(

Invocación

Servidor

Cliente

Recibe invocación
Procesa invocación y genera respuesta
Devuelve respuesta

Sigue

•  Middleware(asíncrono(
((((((publicación/suscripción)(

Envía datos
Sigue

Ejecuta
Decide recibir datos/conecta a un tipo de datos
Procesa datos
Le envían datos del tipo subscrito

A través de un
servidor o
directamente a
los que están
subscritos

Ejecuta
Decide recibir datos/conecta a un tipo de datos
Le envían datos del tipo subscrito
Procesa datos

©2017(Marisol(García(Valls((

(5(

Arquitectura(de(sistemas(II(Q(GIT(

Middleware(orientado(a(objetos(
•  Permite(realizar(invocaciones(a(métodos(remotos((invocaciones(remotas).(

–  En(un(programa(centralizado(las(invocaciones(entre(objetos(son(locales.(

• 

• 

En(un(programa(distribuido(existen(objetos(distribuidos(y(puede(haber(invocaciones(
locales(y(remotas.(

Los(objetos%remotos(son(aquellos(que(exponen(parte(de(sus(funciones(o(métodos(como(
una(interfaz(remota:(
–  Tienen(métodos(remotos(que(pueden%ser%invocados%por(objetos(cliente.(

•  Conceptos(clave(en(el(modelo(distribuido(son:(
–  Referencia(a(objeto(remoto(((e((interfaz(remota(

• 

Las(invocaciones(concurrentes(sobre(un(objeto(distribuido(son(posibles(y(pueden(ocasionar(
condiciones(de(carrera.(

•  Un(objeto(distribuido(que(pueda(sufrir(invocaciones(concurrentes(deberá(proteger(su(

estado(adecuadamente.(

©2017((Marisol(García(Valls((

(6(

Arquitectura(de(sistemas(II(Q(GIT(

Invocación(de(métodos(remotos.((Ej.%RMI%de%Java%

CountRMIClient

CountRMIServer

RMI Stub



RMI
sobre
TCP/IP

RMI Skeleton



Bus software

©2017((Marisol(García(Valls((

(7(

Arquitectura(de(sistemas(II(Q(GIT(

Stubs(y(Skeletons(

Objeto
Cliente

Interfaz
remota

Stub

Objeto
Remoto

Skeleton

Red

©2017((Marisol(García(Valls((

(8(

Arquitectura(de(sistemas(II(Q(GIT(

Transferencia(de(objetos:(serialización(

• 

La serialización (serialization) es un mecanismo que permite convertir un objeto o una
instancia en un flujo de datos para ser almacenado.
– 

Implica la traducción de estructuras de datos o estado de instancias u objetos a un formato que
puede ser almacenado en un fichero, buffer de memoria, o transmitido por la red.

(

•  Esto permite implementar persistencia.

•  Deserialización (deserialization) es el proceso que permite que una instancia

almacenada como flujo de datos (data stream) sea reconstituida.
–  Una instancia serializada puede ser reconstituida después en la misma u otra máquina.
–  Se crea un clon semánticamente idéntico al objeto original.

•  Problemas a resolver:

–  Ordenamiento de bytes (endianness)
–  Organización de la memoria
–  Representaciones diferentes de las estructuras de datos en diferentes lenguajes de programación

•  Se requiere un formato de almacenamiento independiente de la arquitectura.

©2017((Marisol(García(Valls((

(9(

Arquitectura(de(sistemas(II(Q(GIT(

Serialización:(detalles(de(rendimiento(

• 

La codificación de los datos es secuencial.
–  La extracción de una parte de los datos requiere que el objeto completo sea leído de principio a fin y

sea reconstruido.

•  A veces este mecanismo simple es una ventaja:

–  Es simple, permite usar interfaces I/O comunes para pasar el estado de una instancia

•  En aplicaciones que requieren más alto rendimiento es conveniente:

–  Mecanismo más complejo, con una organización no lineal del almacenamiento.

•  Almacenamiento de punteros:

–  Es muy sensible – las instancias a las que apuntan pueden cargarse en una zona diferente de la

memoria

portables. (remover)

–  Swizzling – convertir punteros dependientes de zonas específicas de memoria a símbolos o posiciones

–  UNswizzling – convertir referencias basadas en nombres o posiciones a referencias (punteros) directas.

•  Ejecución diferencial basada en código común de serialización
–  Detectar diferencias entre objetos a serializar y sus copias anteriores
–  Obtener realimentación para la siguiente detección de diferencias (on the fly)

©2017((Marisol(García(Valls((

(10(

Arquitectura(de(sistemas(II(Q(GIT(

Diferencias(entre(serialización(y(marshalling(

•  Marshalling(es(un(concepto(similar(a(la(serialización((p.ej.,(Python)(aunque(no(

para(todos(los(entornos((p.ej.,(Java(RFC(2713).(

•  Hacer(un(marshal(de(un(objeto(implica(guardar(su(estado(y(la(dirección(base(de(

su(código((codebase).(

•  Unmarshalling(consiste(en(obtener(una(copia(del(objeto(original(posiblemente(

descargando(automá8camente(las(definiciones(de(clase(del(objeto.(
–  Unmarshalling(trata(a(los(objetos(remotos(de(forma(diferente((RFC(2713).(

•  NOTA:(Se(escribe(indis8ntamente:(marshalling(o(marshaling.((
(

©2017((Marisol(García(Valls((

(11(

Arquitectura(de(sistemas(II(Q(GIT(

Paso(de(Parámetros(a(Métodos(Remotos(

((((((((((
(
(((((((((Hay(3%mecanismos%básicos((

Tipos%primiAvos:(se(pasan(por(valor((copia).(Todos(son(serializables((

1. 
2.  Objetos%Remotos:(se(pasan(por(referencia((stubs,(usados(para(invocar(métodos(

remotos).((

3.  Objetos%Locales:(se(pasan(por(valor((sólo(si(son(serializables),(se(crea(un(nuevo(

objeto(en(el(nodo(que(recibe(la(copia.((

©2017((Marisol(García(Valls((

(12(

Arquitectura(de(sistemas(II(Q(GIT(

Middleware(de(publicación/suscripción(

•  Generalmente los publicadores (P) y los subscriptores (S) son anónimos.

– 

Los datos se clasifican por tópicos

Las aplicaciones (nodos) se suscriben a los datos que necesitan: suscriptores.

• 

• 

Las aplicaciones publican los datos que quieren compartir: publicadores.
– 

Los publicadores envían un mensaje a un tópico o tema (topic).


•  Publicadores y subscriptores pueden publicar o subscribirse a la jerarquía de contenidos

de forma dinámica.

•  El sistema se encarga de distribuir los mensajes que llegan desde los múltiples

publicadores de un tópico a los múltiples subscriptores de ese tópico.

• 

• 

• 

• 

Los tópicos retienen los mensajes sólo durante el tiempo que se tarda en distribuirlos a
los subscriptores actuales.

Implementaciones de PS:
–  A través de un servidor central (JMS)
–  Los datos pasan directamente entre los publicadores y los suscriptores (DDS)

©2017((Marisol(García(Valls((

(13(

Arquitectura(de(sistemas(II(Q(GIT(

Mensajería con esquemas publicador-suscriptor

Cada(mensaje(puede(tener(múlAples%consumidores.(

Publicadores(y(subscriptores(Aenen%dependencias%temporales.(
–  Un(cliente(que(se(subscribe(a(un(tópico(sólo(puede(consumir(mensajes(publicados(después(de(que(el(
–  El(subscriptor(debe(estar(ac8vo(para(poder(consumir(mensajes((

cliente(haya(creado(la(subscripción,(

Publicador(

Msj.

Publica



o
c
i
p
ó
T

Se subscribe

Suscriptor(1(

Entrega

Msj.

Se subscribe

Suscriptor(3(

Entrega
Msj.

• 

Se(usa(en(situaciones(en(las(que(cada(mensaje(pueda(ser(procesado(por(cero,(uno(o(muchos(
consumidores.(

©2017((Marisol(García(Valls((

(14(

Arquitectura(de(sistemas(II(Q(GIT(

El(middleware(de(comunicaciones(ICE(
•  Orientado a objetos.

• 

Interfaz de programación multi-lenguaje: C++, C#, Java, etc.

•  Sigue el modelo cliente-servidor (existen peticionarios y servidores de

peticiones).

•  Clientes

•  Servidores

–  entidades activas que generan peticiones de servicio.

–  entidades pasivas que ofrecen servicio en respuesta a peticiones.

• 

Ice proporciona un protocolo RPC que puede usar TCP/IP o UDP como
transportes.
–  También permite usar SSL como transporte para encriptar las comunicaciones.

©2017((Marisol(García(Valls(

(15(

Arquitectura(de(sistemas(II(Q(GIT(

Tipos(de(invocación(soportados(
•  Síncrona

•  Asíncrona

•  Unidireccional (one way method invocation)

–  Requieren TCP/IP o SSL

•  Datagramas

–  Requieren UDP

•  Lote unidireccional (batched one way method invocation)

•  Lote datagrama (batched datagram method invocation)

•  Adicionalmente Ice Storm ofrece publicación-suscripción

©2017((Marisol(García(Valls(

(16(

Arquitectura(de(sistemas(II(Q(GIT(

Conceptos(

•  Objectos ICE

–  Abstracción (local o remota) que responde a peticiones de clientes,
–  Pueden(ser(instanciados(en(uno(o(varios(servidores,(
–  Sus(operaciones(8enen(de(0(a(n(parámetros((de(entrada(se(inicializan(en(cliente(y(se(pasan(

al(servidor;(los(parámetros(de(salida(se(inicializan(en(el(servidor)(

–  Cada(objeto(ICE(8ene(una(iden8dad(única.

•  Proxy

–  Represent