1Sistemas DistribuidosBasados en

Coordinacin

Prof. M. CurielBasada en lminas y libro de

Tanenbaum y Van Steem

Contenido

z Introduccin a los modelos de Coordinacinz Arquitecturasz Procesosz Comunicacinz Asignacin de Nombresz Sincronizacinz Consistencia y Replicacin

Introduccin a los Modelos de Coordinacin

z Cmputo y Coordinacion:z Cmputo: la parte de cmputo de un SD est

formada por procesos, y cada proceso se ocupade efectuar una actividad computacionalespecfica la cual en principio es realizadaindependientemente de otros procesos.

z Coordinacin: maneja la comunicacin y cooperacin entre procesos.

2Introduccin a los Modelos de Coordinacin

z En SD basados en Coordinacin, el enfoque recae en cmo ocurre la Coordinacin entre procesos.

Taxonoma de Modelos de Coordinacin

Referential

TemporalCoupled

Coupled

Decoupled

Decoupled

Direct Mailbox

Meetingoriented

Generativecommunication

Cabri y Colaboradores (2000), para agentes mviles

Taxonoma

z Acoplamiento referencial: tiene que ver con la forma de hacer referencia explcita en la comunicacin. Por ejemplo, un procesopuede comunicarse con otro slo si conocesu nombre o identificador.

z Acoplamiento temporal: se refiere a que losprocesos que se comunican deben estarfuncionando.

3Taxonoma

z Coordinacin directa: los procesos debenestar funcionando y se conocen.

Referential

TemporalCoupled

Coupled

Decoupled

Decoupled

Direct Mailbox

Meetingoriented

Generativecommunication

Taxonoma z Coordinacin de Buzon de Correo: no se requiere quelos procesos que se estncomunicando funcionen al mismo tiempo para quefuncione la comunicacin. sta ocurre colocando losmensajes en un buzn de correo (posiblementecompartido).

z En la comunicacin esnecesario referirse al buznde correo que mantendrlos mensajes a ser intercambiados.

Referential

TemporalCoupled

Coupled

Decoupled

Decoupled

Direct Mailbox

Meetingoriented

Generativecommunication

Taxonoma z Coordinacin orientada a reunin: los procesos no se conocen entre s. Existe un concepto de reunin en la cual los procesos se agrupan temporalmentepara coordinar susactividades. Segn estemodelo los procesos sdeben estarse ejecutandoal mismo tiempo.

Un tipo de sistemas de publicacin/suscripcincaen dentro de estacategora.

Referential

TemporalCoupled

Coupled

Decoupled

Decoupled

Direct Mailbox

Meetingoriented

Generativecommunication

4Taxonomaz En los sistemas de publicacin y suscripcin

los procesos pueden suscribirse a mensajesque contienen informacin sobre temasespecficos, en tanto que otros procesosproducen o publican tales mensajes.

z La mayora de tales sistemas requiere quelos procesos que se estn comunicandoestn activos al mismo tiempo.

Taxonomaz Comunicacin Generativa:

(Linda) un conjunto de procesos independientesutilizan un espacio de datospersistente, compartido, conformado por tuplas.

z Las tuplas son registros de datos etiquetadoscompuestos por varioscampos de entrada.

z Las etiquetas sirven paradistinguir entre tuplas querepresentan diferentesclases de informacin.

Referential

TemporalCoupled

Coupled

Decoupled

Decoupled

Direct Mailbox

Meetingoriented

Generativecommunication

Taxonomaz Estos espacios de datos compartidos

implementan un mecanismo de bsquedaasociativa de tuplas: cuando un procesodesea extraer una tupla del espacio de datos, especifca los valores de aquelloscampos en los que est interesado.

z Cualquier tupla que coincida con la especificacin se retira del espacio de datos y se transfiere al proceso.

5Taxonomaz Si no se encuentra ninguna

coincidencia el proceso puede elegirbloquearse hasta que se encuentraalguna coincidencia.

z Estos espacios de comunicacingenerativa se consideran tambin con frecuencia como sistemas de publicacin/suscripcin.

Arquitecturas

z Una caracterstica importante de estossistemas (P/S) es que la comunicacinocurre describiendo las caractersticas de loselementos de datos que se van a intercambiar. Los elementos de datos no son identificados explcitamente por remitentes y destinatarios.

z Los elementos de datos se describen pormedio de una serie de atributos.

Arquitectura Generalz Un elemento de datos est publicado cuando

se coloca a disposicin de otros procesos parasu lectura.

z Mediante una subscripcin, el subscriptorinforma al sistema las caractersticas de aquellos elementos de datos que son de suinters.

z Tal descripcin se compone de los pares(atributo, valor) posiblemente combinados con pares (atributo, rango). Las descripciones a veces pueden darse utilizando varias clases de predicados formulados sobre los atributos.

6Arquitectura General

z Qu pasa cuando las suscripciones tienenque compararse con elementos de datos y se da la coincidencia?

1. El middleware puede remitir los datos a sugrupo de suscriptores (cuando el middleware no ofrece almacenamiento de datos, se trata de un sistema referencialmente desacoplado perotemporalmente acoplado)

Arquitectura General

2. Se remite una notificacin, despus de lo cual los suscriptores pueden realizar la operacin read para leer el elemento de datos. El middleware necesariamente tieneque guardar el elemento de datos. Tambines posible anexar un contrato a un elementode datos, de forma que cuando expire dichoelemento se elimine automticamente.

Publisher Subscriber

SubscriptionNotification

Read/Delivery

Match

Data item

Publish/subscribe middleware

Subscriber

7Arquitectura General

z Se supone que cada elemento de datos tiene un vector asociado de pares (atributo, valor).

z En muchos sistemas basados en coordinacin lo que se publica son eventos.

z En este tipo de sistemas es importante cmo se implemente la coincidencia de suscripciones.

z Los mtodos de coordinacin proporcionan un granpotencial para construir SD a muy gran escaladebido al fuerte desacoplamiento de los procesos.

Arquitecturas Tradicionales

z Solucin ms simple: arquitecturaCliente/Servidor centralizada: WebSphere de IBM, implementaciones de JMS (Sun), implementaciones de Jini y JavaSpaces.

Jini y JavaSpaces

z Jini es un sistema distribuido que implementaun modelo de coordinacin de comunicacingenerativa.

z Est fuertemente relacionado con Java, aunque muchos de sus principios se puedenimplementar en otros lenguajes.

z Ofrece desacoplamiento temporal y referencial de procesos mediante un sistemade Coordinacin llamado JavaSpaces(derivado de Linda).

8Jini y JavaSpaces

z Un JavaSpace es un espacio de datoscompartido que guarda tuplas que representanun conjunto de referencias a objetos Java. En un sistema Jini pueden coexistir mltiplesJavaSpaces.

z Las tuplas se guardan en forma serializada (se empaqueta la tupla y sus campos)

z Una tupla se coloca en un JavaSpace por mediode una operacin write, que empaqueta primerola tupla antes de guardarla.

Jini y JavaSpaces

z Cada vez que se invoca la operacin write en relacin a una tupla, se guarda otra copiade dicha tupla (instancia) en el JavaSpace.

z Para leer una instancia de tupla, un procesoproporciona otra tupla que utiliza comoplantilla (tambin es un conjunto de referencias a objetos).

z Slo pueden leerse desde el JavaSpaceinstancias de tupla del mismo tipo que la plantilla.

Tuple instance

A

A B T

C

B A

CBB

Insert acopy of A

Write A Write B Read T

Insert acopy of B

Look fortuple thatmatches T

Return C(and optionally

remove it)

A JavaSpace

9class public Tupla implements Entry {public integer id, value;public Tupla(Integer id, Integer value){this.id=id; this.value=value}

}

La siguiente plantilla:

Tupla template = new Tupla(null, new Integer(42))

equiparar la tupla:

Tupla item = new Tupla(newInteger(64)), new Integer(42))

Dos campos coinciden si ambos tienen una copia de la misma referencia o si el campo en la tupla plantilla es NULL. Una instancia de tupla es igual a unatupla plantilla si sus campos concuerdan.

Jini y JavaSpacesz Cuando se est haciendo una operacin

read y se encuentra una coincidencia, se devuelve una copia de la instancia de la tupla al proceso que la est solicitando.

z La operacin take retira la tupla del JavaSpace.

z Ambas operaciones bloquean al invocadorhasta que se encuentra una tuplacoincidente. Tambin existen variantes para: especificar un tiempo mximo de bloqueo o regresar de inmediato si no se encuentracoincidencia.

Jini y JavaSpaces

z Los procesos que usan JavaSpaces no tienen que coexistir al mismo tiempo. Si el JavaSpace se implementa mediantealmacenamiento persistente, un sistemaJini completo puede bajarse y reiniciarsems tarde sin que se pierda ninguna tupla.

z Un servidor centralizado permitesuscripciones bastante elaboradas y facilitala sincronizacin.

10

TIB/Rendezvous

z Una solucin al uso de servidores centraleses diseminar de inmediato los elementos de datos publicados a los suscriptoresapropiados mediante multitransmisin(TIB/Rendezvous)

z En este sistema un elemento de datos es un mensaje etiquetado con una palabra clave compuesta que describe su contenido, talcomo news.comp.os.books

TIB/Rendezvous

z Un suscriptor proporciona (partes de) unapalabra clave o indica los mensajes quedesea recibir, tal como news.comp.*.books.Se dice que estas palabras clave indican el tema de un mensaje.

z Para la implementacin se utiliza con frecuencia la multitransmisin en redes de rea local, aunque tambin puede utilizarsecomunicacin punto-punto (si se sabe dondereside un suscriptor)

TIB/Rendezvous

z Cada servidor ejecutar un demonio rendezvous, que se encarga de que los mensajes seanenviados y entregados de acuerdo con el tema.

z Siempre que se publica un mensaje, se multitransmite a cada servidor de la red queejecuta un demonio rendezvous.

z Los procesos suscritos a un tema transfieren sususcripcin a un demonio local. ste construyeuna tabla de entradas (proceso, tema)

11

TIB/Rendezvous

z Siempre que llega un mensaje sobre un tema S, el demonio revisa en su tabla en busca de suscriptores locales y remite el mensaje a cada uno. Si no existensuscriptores para S, el mensaje se desecha.

Network

Multicast message on B to subscribersMulticast messageon A to subscribers

Subj: A

Publ. on A

RVdaemon

RV lib

Subs. to A

RVdaemon

RV lib

Subj: B

RVdaemon

RV lib

Subs. to APubl. on B

RVdaemon

RV lib

Subs. to ASubs. to B

RVdaemon

RV lib

Subs. to B

Arquitecturas Punto-a-Punto

z Servidor central no es escalablez Model TIB/R la multitransmisin requiere

de medidas especiales para ir mas all de una red de rea local.

12

Arquitecturas Punto a Punto

z Son sistemas de publicacin/suscripcin en los cuales los eventos que se publican son re-dirigidos slo a los nodos que se hansuscrito previamente a dicho evento.

z Las suscripciones pueden variar desde la especificacin de un simple atributo o eventohasta la especificacin de un rango de valores

Ejemplo: Sub-2-Sub2 (Sistema de P/S basado en Conversacin)

z Voulgaris et all (2004)z Los elementos de datos pueden describirse por

medio de N atributos a1, ...aN cuyo valor puede se un entero, flotante, enumeraciones, booleanos y cadenas.

z Una suscripcin s adopta la forma de una tupla de pares (atributo, valor/rango) tales como:

>=< )5.0,0.0[,0.3 41 aas

Ejemplo: Sub-2-Sub

z Cada suscripcin si en realidad especifica un subconjunto Si en el espacio de N-dimensiones de nmeros punto flotante. A tal subconjunto se le llama tambin hiperespacio.

z Los nodos regularmente intercambiansuscripciones por medio de un protocoloepidmico. Si dos nodos i, j advierten que susrespectivas suscripciones se entrecruzan, es decir:

OSSS jiij registrarn este hecho y mantendrn referencias entre ellos.

13

Ejemplo Sub-2-Subz Si descubren un tercer

nodo k con: 0 kijijk SSSlos tres se conectarn entre s, de modo que un elemento de datosde inters para los tres pueda diseminarse con eficiencia.

En esencia lo que se busca es agrupar los nodos en M grupos diferentes, de modo que los nodos i y j pertenezcan a un mismo grupo si sus suscripcionesse entrecruzan. Los nodos ubicados en el mismo grupo debern organizarseen una red sobre-puesta que permitir la diseminacin eficiente de un elemento de datos en el hiperespacio asociado con dicho grupo.

Node IDs

Attribute value

2

4

6

8

10

12

Group of four nodes for interval [16.5, 21.0]

10 20 305 15 25 35

Bidirectional ring

Los nodos 3,4, 7 y 10 se agrupan para representar el intervalo [16.5, 21.0].Cualquier elemento de datos con un valor presente en ese intervalo deberdiseminarse slo a esos 4 nodos.

14

Ejemplo Sub-2-Sub

z Los nodos no slo mantienen la informacin a losotros nodos en su anillo.

z Para descubrir nuevos nodos (que pudieran estarinteresados en los mismos datos) los autores del sistema desarrollaron cyclon, un protocoloepidmico mediante el cual un nodo mantiene unalista de vecinos seleccionados aleatoriamente(vista), y regularmente intercambia vistas con otrospares (conversacin). Tal intercambio permitirque un nodo aprenda sobre otros nodos del sistema.

Ejemplo Sub-2-Sub

z Se manejan tres tipos diferentes de enlaces:z Enlaces aleatorios: enlaces a pares seleccionados

aleatoriamente, se necesitan para descubrir nuevos nodos y para mantener la red conectada.

z Enlaces de intereses solapados: reflejan similitudes entresuscripciones y se usan para enviar eventos publicados a otros pares interesados. Se usa un protocolo epidmicobasado en proximidad (vicinity)

z Enlaces de anillos: Hay un orden entre los nodos que tienenintereses comunes. Despus de un intercambio de informacin (nodo i, nodo j) el nodo i ordena todos losnodos en el conjunto por sus identificadores y selecciona el que tenga el identificador ms bajo

15

Movilidad y Coordinacinz Cmo combinar soluciones de publicacin

y suscripcin con la movilidad de losnodos?z Cmo garantizar que los mensajes

publicados no sean entregados ms de unavez a un suscriptor que cambia de puntos de acceso.

z Sol: que los suscriptores no pierdan de vista los mensajes que ya recibieron y desechenlos duplicados. Soluciones ms complicadasse basan en enrutadores o direccionadoresque no pierden de vista qu mensajes fueronenviados a cules suscriptores.

Limez En el caso de comunicacin generativa, se han

propuesto varias soluciones para operar un espaciode datos compartido donde todos/algunos de losnodos son mviles. Un ejemplo de estos sistemases Lime.

z Cada proceso tiene su propio espacio de datosasociado, pero cuando los procesos estnprximos entre s (conectados), sus espacios de datos se vuelven compartidos.

z Conectados: z Teora: existe una ruta en una red subyacente conjunta

que permite que dos procesos intercambien datos.z Prctica: procesos en el mismo servidor o que sus

servidores pueden comunicarse mediante un enlace inalambrico.

Lime

Localdataspace

Localdataspace

Process Process

Localdataspace

Process

Wireless link

Transient, shared dataspace

16

Lime

z Si hay un espacio de datos compartidos de forma transitoria los procesos pueden intercambiar tuplas

z El espacio de datos compartidos, est distribuido, pero esto es transparente para los procesosparticipantes.

z Lime tambin permite romper con estatransparencia y especificar para qu proceso va el mensaje. Las operaciones read y take pueden tenerun parmetro adicional que especifique de quproceso se espera una tupla.

Comunicacin en Sistemas de Publicacin/Suscripcin

z En la mayora de estos sistemas la comunicacin es relativamente simple, porejemplo en casi todos los sistemas basadosen Java, toda la comunicacin se realizamediante invocaciones a mtodos remotos.

z Un problema: los datos publicados debenllegar slo a los suscriptores. Una solucinpuede ser la organizacin de los nodospresentes en un sistema punto-punto, despus de lo cual la diseminacin ocurre porgrupo.

Enrutamiento basado en contenidoz Se supone que el sistema est construido

encima de una red punto-punto en la cuallos mensajes son explcitamentedireccionados entre los nodos.

z Es crucial que los enrutadores seancapaces de tomar decisiones, utilizando el contenido del mensaje. En otraspalabras...cada mensaje porta unadescripcin de su contenido. Estadescripcin puede utilizarse parainterrumpir rutas que no conducen a receptores interesados.

17

Enrutamiento basado en contenido

z Carzaniga y colaboradores proponen un esquema de enrutamiento donde losservidores se conectan en forma de rbol.

z En el dibujo, los servidores estn en losextremos del rbol y los nodosintermedios son los enrutadores.

5

1

43

21

1

33

3 R1

R2

Enrutamiento basado en contenido

z Sol 1 (extrema) enviar cada mensaje publicado a cada servidor y dejar que ste verifique si cualquierade sus clientes se haba suscrito al tema de dichomensaje (TIB/Rendevouz)

z Sol 2 (extrema) cada servidor transmita sussuscripciones a todos los dems servidores (y enrutadores). Cada servidor o enrutador tiene unalista de pares (tema, destino). Cuando el mensajellega a un enrutador, ste puede utilizar la lista paradecidir las rutas que el mensaje deber seguir.

18

Enrutamiento basado en contenido

z Podemos afinar las capacidades de losenrutadores para decidir a donde van losmensajes. Cada servidor transmite sususcripcin a travs de la red de modo quelos enrutadores puedan componer filtros de almacenamiento.

[ ]3,0a

[ ]5,2aNo especifica-do

Hacia el enrutadorr1

Hacia el nodo 4

Hacia el Nodo 3

FiltroInterfaz

[ ]3,0a[ ]5,2a

Tabla o filtro de Enrutamiento del enrutadorR2

5

1

43

21

1

33

3 R1

R2

[ ]3,0a[ ]5,2a

[ ] [ ] [ ]5,05,23,0 =a

z Cuando un nodo abandone el sistema , o ya no est interesado en mensajesespecficos deber cancelar sususcripcin y transmitir esa informacina todos los enrutadores.

z Como producto de esta cancelacin se pueden ajustar varios filtros de enrutamiento.

19

Asignacin de Nombresz Hasta ahora hemos trabajado bajo la

suposicin que todo dato publicado tiene un vector asociado de N pares (atributo, valor)y que los procesos pueden suscribirse a elementos de datos especificandopredicados sobre estos valores de atributos.

z Existen sistemas en los cuales loselementos de datos no estn etiquetadoscon valores para todos los atributos.

Asignacin de Nombresz En particular veremos que un elemento de

datos tiene slo un par asociado (atributo, valor), en cuyo caso tambin se conoce comoevento.

z El soporte a suscripcin de eventos y, especialmente, a eventos compuestos inspiraen gran medida el anlisis sobre temas de asignacin de nombres en los sistemas de publicacin/suscripcin.

Asignacin de Nombresz Cuando se trabaja con eventos tenemos que

tomar en cuenta:z Cmo componer los eventos (describir las

composiciones) (Pietzuch y colaboradores 2003 propusieron una estructura general para la composicin de eventos en SD)

z Cmo recopilar eventos (primitivos) y posteriormente equiparalos con suscripciones.

20

Descripcin de Eventos Compuestos

Notifica cada vez que la temperatura promedio del cuarto se mantuvo por mas de 20 grados en la ltima hora (calcular promedio)

S5

Notifica cuando la temperatura del cuarto sube ms de un grado por cada 30 minutos (medir temperatura)

S4

Notifica cuando el cuarto R4.2 est desocupadodurante 10 segundos y la puerta est abierta(compuesto + requiere de tiempo)

S3

Notifica cuando el cuarto R4.2 est desocupado y la puerta est abierta (compuesto)

S2

Notifica cuando el cuarto R4.2 est desocupado(simple)

S1

DescripcinEvento

Descripcin de EventosCompuestos

z La idea bsica es habilitar la formulacin de suscripciones en funcin de eventosprimitivos.

z Pietzuch y colaboradores, proponen un lenguaje basado en una mquina de estadofinito ampliada. Las extensiones permitenespecificar tiempos de permanencia en estados, as como la generacin de eventosnuevos (compuestos)

Room unoccupied Door is locked

Door is unlockedRoom is occupied

t=10s

(generate event)

(start)

Mquina de Estado Finito para la suscripcin S3. Se hace una transicin al estado final si la puerta no se cierray el saln permanecen vacos por 10 segs.

21

Descripcin de EventosCompuestos

z Las FSM (Finite State Machines) se puedendescomponer en otras mquinas mspequeas que se comunican pasndoseeventos entre s.

z Ejem: se desea apagar las luces de la habitacin R4.2 despus de 2 segundos de estar seguros que no hay nadie en ella (y la puerta est cerrada)

Room unoccupied Door is locked

Door is unlockedRoom is occupied

t=10s

(generate event)

(start)

Switch lights offt=2s(start)

Dos mquinas de Estado Finito Acopladas

Descripcin de Eventoscompuestos

z Las FSM pueden implementarse comoprocesos aparte en el sistema distribuido. La segunda FSM se suscribir al eventocompuesto que se deriva de la primera.

z Los eventos son mensajes enviados a travsdela red a procesos suscritos a ellos.

22

Sincronizacin

z Es simple cuando se utiliza un solo servidor. Los procesos pueden simplementebloquearse hasta que las tuplas estndisponibles

z Todo se complica cuando el espacio de datos compartido se replica y distribuye a travs de mltiples servidores.

Consistencia y Replicacin: Mtodos Estticos

z Ejem: JavaSpace. Se desea replicar y distribuir el conjunto de tuplas en variasmquinas.

z Consideraciones generales:z Cmo realizar la asociacin

(publicacin/suscripciones) sin necesidad de realizar una bsqueda masiva?

z Como distribuir instancias de tuplas entremquinas y localizarlas despus?

Consistencia y Replicacin: Mtodos Estticosz Dividir el espacio de tuplas en sub-espacios, cada

una de cuyas tuplas es del mismo tipo. Como lastuplas entran por teclado es posible determinar a tiempo de compilacin en qu subespacio opera una invocacin a read, take o write.

z Cada sub-espacio puede organizarse mediante unatabla de hash, utilizando uno de los campos de lastuplas.

z Las tuplas de un mismo sub-espacio puedenreplicarse en diferentes mquinas. Una invocacin a read, write o take se ejecuta calculando la funcin de

hash del i-simo campo para determinar la posicin de la tabla donde pertenecela instancia de la tupla. Si el campo i-simo es NULL, no puede aplicar una funcin de hash y es necesario hacer una bsqueda completa.

23

Consistencia y Replicacin: Mtodos Estticosz Si se dispone de una transmisin confiable

se pueden replicar todos los sub-espacios en todas las mquinas.

z Cuando se realiza una operacin write la nueva instancia de tupla se transmite e ingresa en el sub-espacio adecuado paracada mquina

z Read o take realiza la bsqueda en el subespacio local. Para la consumacinexitosa de un take, es necesario eliminar la tupla de todas las mquinas.

Process doinga write broadcasts

Process doing a takeexamines local JavaSpace

Tuple broadcast

Tuple delete

Network

Network

(a)

(b)

Subspaces

Consistencia y Replicacin: Mtodos Estticos

z Este diseo es simple pero no escala bien a medidaque aumenta el nmero de instancias de tupla o el tamao de la red.

z El diseo inverso es realizar los write localmente, guardando la instancia de la tupla slo en la mquina que la gener. Para realizar un read o takeel proceso debe transmitir la tupla-plantilla. Cadareceptor revisa para ver si tiene una tupla igual y contesta afirmativamente si la tiene. Si la instanciade la tupla no est presente o si no se recibe el mensaje en la mquina que tiene la tupla, la mquina solicitante retransmite (ad infinitum) hastaque obtiene una respuesta satisfactoria.

24

Process doing a writeinserts tuple into local JavaSpace

Process doing a readbroadcasts template Template broadcast

Network

Network

(a)

(b)

Consistencia y Replicacin: Mtodos Estticos

z Los dos mtodos anteriores pueden combinarsepara producir un sistema con replicacin parcial:z Suponga que todas las mquinas forman una cuadrcula

rectangular. z Cuando el proceso A desea realizar una una operacin

write transmite (o enva un mensaje punto-punto) la tuplaa todas las mquinas ubicadas en su fila de la cuadrcula.

z Cuando el proceso B desea leer o tomar una instancia de la tupla, transmite la tupla plantilla a todas las mquinas de su columna. Debido a la geometra siempre habrexactamente una mquina que ve tanto la instancia de tupla como la tupla plantilla (C)

A C

B

A broadcaststuple to these

machines

B broadcasts templateto these machines

25

Consistencia y Replicacin: Mtodos Estticosz Todas las implementaciones presentadas tienen

problemas de escalabilidad (la mayora se basa en multitransmisin)

z Las implementaciones de espacios de tuplas en redes de rea amplia no existen. En el mejor de loscasos pueden existir varios espacios de tuplasdiferentes, y cada espacio se implementa en un servidor o en una red de rea local.

Replicacin Dinmica

z Ejem: GigaSpacesz Se construy encima de JavaSpaces. z En este sistema la distribucin y replicacin

de tuplas se realizan por dos razones: desempeo y disponibilidad. Se utilizanestrategias diferentes en ambos casos. Poresta razn se soportan varias polticas de replicacin.

Replicacin Dinmica

z Se ofrecen las llamadas read, write, take, al igual que con JavaSpaces.

z Cada una de estas llamadas es captada porun manejador de invocaciones local quebusca la poltica a seguirse para la invocacin especfica.

z Se selecciona una poltica basada en el tipoy contenido de la tupla que se transfierecomo parte de la invcacin.

26

Replicacin Dinmica

z El manejador de invocacin usa plantillas paraidentificar los diferentes tipos de tuplas.

z Posteriormente se invoca al gestor de distribucin, el cual implemnta la misma interfazpero ahora de acuerdo con una poltica de replicacin especfica.

z Ejem. Maestro-Esclavo. Todos tienen la tupla, un read puede ser local. Un write puede requerirque el gestor de distribucin remita el nodo al maestro y espere un acuse de recibo antes de realizar la operacin localmente.

Distributionmanager

Distributionmanager

Distributionmanager Invocationhandler

PolicytableDataspace

slice

Local OS

To network

Application

Replicacin Dinmica

z En GigaSpace la gestin de replicacin esautomtica, i.e. en lugar de permitir que el desarrollador de aplicaciones decida qu polticaes la mejor, el sistema monitorea los patrones de acceso y comportamiento para posteriormenteadoptar las polticas que se requieran.

z Con este objetivo GigaSpace continuamentemide el ancho de banda consumido, la latenciade la red y el uso de la memoria , coloca lastuplas en diferentes nodos y elige la manera msapropiada de mantener las rplicas consistentes.

27

Resumen

z Los sistemas distribuidos basados en coordinacin estn enfocados en el desacoplamiento referencial de losprocesos, i.e. stos no tienen que referirseexplcitamente entre s para habilitar la comunicacin. Tambin es posible tenerdesacoplamiento temporal, de modo que losprocesos no tienen que estar activos paracomunicarse.

Resumen

z Un grupo importante de estos sistemas estformado por aquellos que siguen el paradigma de publicacin/suscripcin (TIB/Rendevouz) En estemodelo los mensajes no portan la direccin de susreceptores sino que en cambio son direccionadospor tema.

z Un poco ms complejos son aquellos sistemasdonde los suscriptores pueden formar predicadossobre los atributos de los elementos de datospublicados. El enrutamiento en estos sistemas se hace basado en contenido.

Resumen

z Otro grupo importante utiliza comunicacingenerativa, la cual ocurre por un espaciocompartido de tuplas.

z Los principios de los SD se aplican a sistemas basados en coordinacin. El almacenamiento en cache y la replicacindesempean un rol menos prominente en las replicaciones actuales