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

Imágen de pdf Middleware. Modelos de interacción - Tema 4. Sistemas distribuidos

Middleware. Modelos de interacción - Tema 4. Sistemas distribuidosgráfica de visualizaciones

Publicado el 20 de Agosto del 2019
364 visualizaciones desde el 20 de Agosto del 2019
843,6 KB
16 paginas
Creado hace 3a (01/01/2017)
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(

mvalls@it.uc3m.es

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
  • Links de descarga
http://lwp-l.com/pdf16482

Comentarios de: Middleware. Modelos de interacción - Tema 4. Sistemas distribuidos (0)


No hay comentarios
 

Comentar...

Nombre
Correo (no se visualiza en la web)
Valoración
Comentarios...
CerrarCerrar
CerrarCerrar
Cerrar

Tienes que ser un usuario registrado para poder insertar imágenes, archivos y/o videos.

Puedes registrarte o validarte desde aquí.

Codigo
Negrita
Subrayado
Tachado
Cursiva
Insertar enlace
Imagen externa
Emoticon
Tabular
Centrar
Titulo
Linea
Disminuir
Aumentar
Vista preliminar
sonreir
dientes
lengua
guiño
enfadado
confundido
llorar
avergonzado
sorprendido
triste
sol
estrella
jarra
camara
taza de cafe
email
beso
bombilla
amor
mal
bien
Es necesario revisar y aceptar las políticas de privacidad