Sistemas Distribuidos Basados en Coordinación Prof. M. Curiel Basada en láminas y libro de Tanenbaum y Van Steem Contenido z z z z z z z Introducción a los modelos de Coordinación Arquitecturas Procesos Comunicación Asignación de Nombres Sincronización Consistencia y Replicación Introducción a los Modelos de Coordinación z Cómputo y Coordinacion: z z Cómputo: la parte de cómputo de un SD está formada por procesos, y cada proceso se ocupa de efectuar una actividad computacional específica la cual en principio es realizada independientemente de otros procesos. Coordinación: maneja la comunicación y cooperación entre procesos. 1 Introducción a los Modelos de Coordinación z En SD basados en Coordinación, el enfoque recae en cómo ocurre la Coordinación entre procesos. Taxonomía de Modelos de Coordinación Temporal Coupled Decoupled Coupled Referential Decoupled Direct Mailbox Meeting oriented Generative communication Cabri y Colaboradores (2000), para agentes móviles Taxonomía z z Acoplamiento referencial: tiene que ver con la forma de hacer referencia explícita en la comunicación. Por ejemplo, un proceso puede comunicarse con otro sólo si conoce su nombre o identificador. Acoplamiento temporal: se refiere a que los procesos que se comunican deben estar funcionando. 2 Taxonomía Coupled Coupled Referential Decoupled Temporal Decoupled Direct Mailbox Meeting oriented Generative communication z Taxonomía Coupled Coupled Referential Decoupled Temporal Decoupled Direct Mailbox Meeting oriented Generative communication Taxonomía z Coordinación directa: los procesos deben estar funcionando y se conocen. Coordinación de Buzon de Correo: no se requiere que los procesos que se están comunicando funcionen al mismo tiempo para que funcione la comunicación. Ésta ocurre colocando los mensajes en un buzón de correo (posiblemente compartido). En la comunicación es necesario referirse al buzón de correo que mantendrá los mensajes a ser intercambiados. Coordinación orientada a reunión: los procesos no se conocen entre sí. Existe un concepto de reunión en la cual los procesos se agrupan temporalmente para coordinar sus actividades. Según este modelo los procesos sí deben estarse ejecutando al mismo tiempo. Un tipo de sistemas de publicación/suscripción caen dentro de esta categoría. z Temporal Coupled Decoupled Coupled Referential Decoupled z Direct Mailbox Meeting oriented Generative communication 3 Taxonomía z z En los sistemas de publicación y suscripción los procesos pueden suscribirse a mensajes que contienen información sobre temas específicos, en tanto que otros procesos producen o publican tales mensajes. La mayoría de tales sistemas requiere que los procesos que se están comunicando estén activos al mismo tiempo. z Taxonomía Coupled Temporal Decoupled z Coupled Referential Decoupled Direct Mailbox Meeting oriented Generative communication z Comunicación Generativa: (Linda) un conjunto de procesos independientes utilizan un espacio de datos persistente, compartido, conformado por tuplas. Las tuplas son registros de datos etiquetados compuestos por varios campos de entrada. Las etiquetas sirven para distinguir entre tuplas que representan diferentes clases de información. Taxonomía z z Estos espacios de datos compartidos implementan un mecanismo de búsqueda asociativa de tuplas: cuando un proceso desea extraer una tupla del espacio de datos, especifíca los valores de aquellos campos en los que está interesado. Cualquier tupla que coincida con la especificación se retira del espacio de datos y se transfiere al proceso. 4 Taxonomía z z Si no se encuentra ninguna coincidencia el proceso puede elegir bloquearse hasta que se encuentra alguna coincidencia. Estos espacios de comunicación generativa se consideran también con frecuencia como sistemas de publicación/suscripción. Arquitecturas z z Una característica importante de estos sistemas (P/S) es que la comunicación ocurre describiendo las características de los elementos de datos que se van a intercambiar. Los elementos de datos no son identificados explícitamente por remitentes y destinatarios. Los elementos de datos se describen por medio de una serie de atributos. Arquitectura General z z z Un elemento de datos está publicado cuando se coloca a disposición de otros procesos para su lectura. Mediante una subscripción, el subscriptor informa al sistema las características de aquellos elementos de datos que son de su interés. Tal descripción 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. 5 Arquitectura General Qué pasa cuando las suscripciones tienen que compararse con elementos de datos y se da la coincidencia? z 1. El middleware puede remitir los datos a su grupo de suscriptores (cuando el middleware no ofrece almacenamiento de datos, se trata de un sistema referencialmente desacoplado pero temporalmente acoplado) Arquitectura General 2. Se remite una notificación, después de lo cual los suscriptores pueden realizar la operación read para leer el elemento de datos. El middleware necesariamente tiene que guardar el elemento de datos. También es posible anexar un contrato a un elemento de datos, de forma que cuando expire dicho elemento se elimine automáticamente. Publisher Data item Subscriber Subscriber Read/Delivery Subscription Notification Publish/subscribe middleware Match 6 Arquitectura General z z z z Se supone que cada elemento de datos tiene un vector asociado <(a1,v1),(a2,v2),(a3,v3)....> de pares (atributo, valor). En muchos sistemas basados en coordinación lo que se publica son eventos. En este tipo de sistemas es importante cómo se implemente la coincidencia de suscripciones. Los métodos de coordinación proporcionan un gran potencial para construir SD a muy gran escala debido al fuerte desacoplamiento de los procesos. Arquitecturas Tradicionales Solución más simple: arquitectura Cliente/Servidor centralizada: WebSphere de IBM, implementaciones de JMS (Sun), implementaciones de Jini y JavaSpaces. z Jini y JavaSpaces z z z Jini es un sistema distribuido que implementa un modelo de coordinación de comunicación generativa. Está fuertemente relacionado con Java, aunque muchos de sus principios se pueden implementar en otros lenguajes. Ofrece desacoplamiento temporal y referencial de procesos mediante un sistema de Coordinación llamado JavaSpaces (derivado de Linda). 7 Jini y JavaSpaces z z z Un JavaSpace es un espacio de datos compartido que guarda tuplas que representan un conjunto de referencias a objetos Java. En un sistema Jini pueden coexistir múltiples JavaSpaces. Las tuplas se guardan en forma serializada (se empaqueta la tupla y sus campos) Una tupla se coloca en un JavaSpace por medio de una operación write, que empaqueta primero la tupla antes de guardarla. Jini y JavaSpaces z z z Cada vez que se invoca la operación write en relación a una tupla, se guarda otra copia de dicha tupla (instancia) en el JavaSpace. Para leer una instancia de tupla, un proceso proporciona otra tupla que utiliza como plantilla (también es un conjunto de referencias a objetos). Sólo pueden leerse desde el JavaSpace instancias de tupla del mismo tipo que la plantilla. A Write A B Write B T Read T C Insert a copy of A B A Tuple instance Look for tuple that matches T Insert a copy of B B Return C (and optionally remove it) A B C A JavaSpace 8 class 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 una tupla plantilla si sus campos concuerdan. Jini y JavaSpaces z z z Cuando se está haciendo una operación read y se encuentra una coincidencia, se devuelve una copia de la instancia de la tupla al proceso que la está solicitando. La operación take retira la tupla del JavaSpace. Ambas operaciones bloquean al invocador hasta que se encuentra una tupla coincidente. También existen variantes para: especificar un tiempo máximo de bloqueo o regresar de inmediato si no se encuentra coincidencia. Jini y JavaSpaces z z Los procesos que usan JavaSpaces no tienen que coexistir al mismo tiempo. Si el JavaSpace se implementa mediante almacenamiento persistente, un sistema Jini completo puede “bajarse” y reiniciarse más tarde sin que se pierda ninguna tupla. Un servidor centralizado permite suscripciones bastante elaboradas y facilita la sincronización. 9 TIB/Rendezvous z z Una solución al uso de servidores centrales es diseminar de inmediato los elementos de datos publicados a los suscriptores apropiados mediante multitransmisión (TIB/Rendezvous) En este sistema un elemento de datos es un mensaje etiquetado con una palabra clave compuesta que describe su contenido, tal como news.comp.os.books TIB/Rendezvous z z Un suscriptor proporciona (partes de) una palabra clave o indica los mensajes que desea recibir, tal como news.comp.*.books. Se dice que estas palabras clave indican el tema de un mensaje. Para la implementación se utiliza con frecuencia la multitransmisión en redes de área local, aunque también puede utilizarse comunicación punto-punto (si se sabe donde reside un suscriptor) TIB/Rendezvous z z z Cada servidor ejecutará un demonio rendezvous, que se encarga de que los mensajes sean enviados y entregados de acuerdo con el tema. Siempre que se publica un mensaje, se multitransmite a cada servidor de la red que ejecuta un demonio rendezvous. Los procesos suscritos a un tema transfieren su suscripción a un demonio local. Éste construye una tabla de entradas (proceso, tema) 10 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 existen suscriptores para S, el mensaje se desecha. Publ. on A Subs. to A Subj: A Subs. to A Publ. on B Subs. to A Subs. to B Subs. to B Subj: B RV lib RV lib RV lib RV lib RV lib RV daemon RV daemon RV daemon RV daemon RV daemon Network Multicast message on A to subscribers Multicast message on B to subscribers Arquitecturas Punto-a-Punto z z Servidor central Æ no es escalable Model TIB/R Æ la multitransmisión requiere de medidas especiales para ir mas allá de una red de área local. 11 Arquitecturas Punto a Punto z z Son sistemas de publicación/suscripción en los cuales los eventos que se publican son re-dirigidos sólo a los nodos que se han suscrito previamente a dicho evento. Las suscripciones pueden variar desde la especificación de un simple atributo o evento hasta la especificación de un rango de valores Ejemplo: Sub-2-Sub2 (Sistema de P/S basado en Conversación) z z z Voulgaris et all (2004) Los elementos de datos pueden describirse por medio de N atributos a1, ...aN cuyo valor puede se un entero, flotante, enumeraciones, booleanos y cadenas. Una suscripción s adopta la forma de una tupla de pares (atributo, valor/rango) tales como: s =< a1 → 3.0, a4 → [0.0,0.5) > Ejemplo: Sub-2-Sub z z Cada suscripción si en realidad especifica un subconjunto Si en el espacio de N-dimensiones de números punto flotante. A tal subconjunto se le llama también hiperespacio. Los nodos regularmente intercambian suscripciones por medio de un protocolo epidémico. Si dos nodos i, j advierten que sus respectivas suscripciones se entrecruzan, es decir: S ij ≡ S i ∩ S j ≠ O registrarán este hecho y mantendrán referencias entre ellos. 12 Ejemplo Sub-2-Sub z ≡ S ij ∩ S k ≠ 0 Si descubren un tercer nodo k con: ijk S los tres se conectarán entre sí, de modo que un elemento de datos de interés 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 suscripciones se entrecruzan. Los nodos ubicados en el mismo grupo deberán organizarse en una red sobre-puesta que permitirá la diseminación eficiente de un elemento de datos en el hiperespacio asociado con dicho grupo. Bidirectional ring 12 10 Node IDs 8 6 4 2 5 10 15 20 25 Group of four nodes for interval [16.5, 21.0] 30 35 Attribute value 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 deberá diseminarse sólo a esos 4 nodos. 13 Ejemplo Sub-2-Sub z z Los nodos no sólo mantienen la información a los otros nodos en su anillo. Para descubrir nuevos nodos (que pudieran estar interesados en los mismos datos) los autores del sistema desarrollaron cyclon, un protocolo epidémico mediante el cual un nodo mantiene una lista de vecinos seleccionados aleatoriamente (vista), y regularmente intercambia vistas con otros pares (conversación). Tal intercambio permitirá que un nodo aprenda sobre otros nodos del sistema. Ejemplo Sub-2-Sub z Se manejan tres tipos diferentes de enlaces: z z z Enlaces aleatorios: enlaces a pares seleccionados aleatoriamente, se necesitan para descubrir nuevos nodos y para mantener la red conectada. Enlaces de intereses solapados: reflejan similitudes entre suscripciones y se usan para enviar eventos publicados a otros pares interesados. Se usa un protocolo epidémico basado en proximidad (vicinity) Enlaces de anillos: Hay un orden entre los nodos que tienen intereses comunes. Después de un intercambio de información (nodo i, nodo j) el nodo i ordena todos los nodos en el conjunto por sus identificadores y selecciona el que tenga el identificador más bajo 14 Movilidad y Coordinación z Cómo combinar soluciones de publicación y suscripción con la movilidad de los nodos? z z Cómo garantizar que los mensajes publicados no sean entregados más de una vez a un suscriptor que cambia de puntos de acceso. Sol: que los suscriptores no pierdan de vista los mensajes que ya recibieron y desechen los duplicados. Soluciones más complicadas se basan en enrutadores o direccionadores que no pierden de vista qué mensajes fueron enviados a cuáles suscriptores. Lime z z z En el caso de comunicación generativa, se han propuesto varias soluciones para operar un espacio de datos compartido donde todos/algunos de los nodos son móviles. Un ejemplo de estos sistemas es Lime. Cada proceso tiene su propio espacio de datos asociado, pero cuando los procesos están próximos entre sí (conectados), sus espacios de datos se vuelven compartidos. Conectados: z z Teoría: existe una ruta en una red subyacente conjunta que permite que dos procesos intercambien datos. Práctica: procesos en el mismo servidor o que sus servidores pueden comunicarse mediante un enlace inalambrico. Lime Transient, shared dataspace Process Process Process Local dataspace Local dataspace Local dataspace Wireless link 15 Lime z z z Si hay un espacio de datos compartidos de forma transitoria los procesos pueden intercambiar tuplas El espacio de datos compartidos, está distribuido, pero esto es transparente para los procesos participantes. Lime también permite romper con esta transparencia y especificar para qué proceso va el mensaje. Las operaciones read y take pueden tener un parámetro adicional que especifique de qué proceso se espera una tupla. Comunicación en Sistemas de Publicación/Suscripción z z En la mayoría de estos sistemas la comunicación es relativamente simple, por ejemplo en casi todos los sistemas basados en Java, toda la comunicación se realiza mediante invocaciones a métodos remotos. Un problema: los datos publicados deben llegar sólo a los suscriptores. Una solución puede ser la organización de los nodos presentes en un sistema punto-punto, después de lo cual la diseminación ocurre por grupo. Enrutamiento basado en contenido z z Se supone que el sistema está construido encima de una red punto-punto en la cual los mensajes son explícitamente direccionados entre los nodos. Es crucial que los enrutadores sean capaces de tomar decisiones, utilizando el contenido del mensaje. En otras palabras...cada mensaje porta una descripción de su contenido. Esta descripción puede utilizarse para interrumpir rutas que no conducen a receptores interesados. 16 Enrutamiento basado en contenido z z Carzaniga y colaboradores proponen un esquema de enrutamiento donde los servidores se conectan en forma de árbol. En el dibujo, los servidores están en los extremos del árbol y los nodos intermedios son los enrutadores. 1 1 3 1 2 R1 5 R2 3 3 3 4 Enrutamiento basado en contenido z z Sol 1 (extrema) enviar cada mensaje publicado a cada servidor y dejar que éste verifique si cualquiera de sus clientes se había suscrito al tema de dicho mensaje (TIB/Rendevouz) Sol 2 (extrema) cada servidor transmita sus suscripciones a todos los demás servidores (y enrutadores). Cada servidor o enrutador tiene una lista de pares (tema, destino). Cuando el mensaje llega a un enrutador, éste puede utilizar la lista para decidir las rutas que el mensaje deberá seguir. 17 Enrutamiento basado en contenido z Podemos afinar las capacidades de los enrutadores para decidir a donde van los mensajes. Cada servidor transmite su suscripción a través de la red de modo que los enrutadores puedan componer filtros de almacenamiento. 1 Tabla o filtro de Enrutamiento del enrutador R2 1 Interfaz Filtro Hacia el a ∈ [0,3] Nodo 3 Hacia el a ∈ [2 ,5 ] nodo 4 Hacia el No a ∈ [2,5] enrutador especifica r1 -do 3 1 2 a ∈ [0,3] R1 5 a∈ [0,3]∪ [2,5] = [0,5] R2 3 3 3 4 a ∈[0,3] a ∈[2,5] z z Cuando un nodo abandone el sistema , o ya no esté interesado en mensajes específicos deberá cancelar su suscripción y transmitir esa información a todos los enrutadores. Como producto de esta cancelación se pueden ajustar varios filtros de enrutamiento. 18 Asignación de Nombres z z Hasta ahora hemos trabajado bajo la suposición que todo dato publicado tiene un vector asociado de N pares (atributo, valor) y que los procesos pueden suscribirse a elementos de datos especificando predicados sobre estos valores de atributos. Existen sistemas en los cuales los elementos de datos no están etiquetados con valores para todos los atributos. Asignación de Nombres z z En particular veremos que un elemento de datos tiene sólo un par asociado (atributo, valor), en cuyo caso también se conoce como evento. El soporte a suscripción de eventos y, especialmente, a eventos compuestos inspira en gran medida el análisis sobre temas de asignación de nombres en los sistemas de publicación/suscripción. Asignación de Nombres z Cuando se trabaja con eventos tenemos que tomar en cuenta: z z Cómo componer los eventos (describir las composiciones) (Pietzuch y colaboradores 2003 propusieron una estructura general para la composición de eventos en SD) Cómo recopilar eventos (primitivos) y posteriormente equiparalos con suscripciones. 19 Descripción de Eventos Compuestos Evento Descripción S1 Notifica cuando el cuarto R4.2 está desocupado (simple) S2 Notifica cuando el cuarto R4.2 está desocupado y la puerta está abierta (compuesto) S3 Notifica cuando el cuarto R4.2 está desocupado durante 10 segundos y la puerta está abierta (compuesto + requiere de tiempo) S4 Notifica cuando la temperatura del cuarto sube más de un grado por cada 30 minutos (medir temperatura) S5 Notifica cada vez que la temperatura promedio del cuarto se mantuvo por mas de 20 grados en la última ½ hora (calcular promedio) Descripción de Eventos Compuestos z z La idea básica es habilitar la formulación de suscripciones en función de eventos primitivos. Pietzuch y colaboradores, proponen un lenguaje basado en una máquina de estado finito ampliada. Las extensiones permiten especificar tiempos de permanencia en estados, así como la generación de eventos nuevos (compuestos) Room unoccupied Door is locked t=10s (start) Room is occupied Door is unlocked (generate event) Máquina de Estado Finito para la suscripción S3. Se hace una transición al estado final si la puerta no se cierra y el salón permanecen vacíos por 10 segs. 20 Descripción de Eventos Compuestos z z Las FSM (Finite State Machines) se pueden descomponer en otras máquinas más pequeñas que se comunican pasándose eventos entre sí. Ejem: se desea apagar las luces de la habitación R4.2 después de 2 segundos de estar seguros que no hay nadie en ella (y la puerta está cerrada) (generate event) Room unoccupied Door is locked (start) t=10s Room is occupied (start) Door is unlocked t=2s Switch lights off Dos máquinas de Estado Finito Acopladas Descripción de Eventos compuestos z z Las FSM pueden implementarse como procesos aparte en el sistema distribuido. La segunda FSM se suscribirá al evento compuesto que se deriva de la primera. Los eventos son mensajes enviados a través dela red a procesos suscritos a ellos. 21 Sincronización z z Es simple cuando se utiliza un solo servidor. Los procesos pueden simplemente bloquearse hasta que las tuplas estén disponibles Todo se complica cuando el espacio de datos compartido se replica y distribuye a través de múltiples servidores. Consistencia y Replicación: Métodos Estáticos z z Ejem: JavaSpace. Se desea replicar y distribuir el conjunto de tuplas en varias máquinas. Consideraciones generales: z z Cómo realizar la asociación (publicación/suscripciones) sin necesidad de realizar una búsqueda masiva? Como distribuir instancias de tuplas entre máquinas y localizarlas después? Consistencia y Replicación: Métodos Estáticos Dividir el espacio de tuplas en sub-espacios, cada una de cuyas tuplas es del mismo tipo. Como las tuplas entran por teclado es posible determinar a tiempo de compilación en qué subespacio opera una invocación a read, take o write. z Cada sub-espacio puede organizarse mediante una tabla de hash, utilizando uno de los campos de las tuplas. z Las tuplas de un mismo sub-espacio pueden replicarse enwrite diferentes máquinas. Una invocación a read, o take se ejecuta calculando la función de z hash del i-ésimo campo para determinar la posición de la tabla donde pertenece la instancia de la tupla. Si el campo i-ésimo es NULL, no puede aplicar una función de hash y es necesario hacer una búsqueda completa. 22 Consistencia y Replicación: Métodos Estáticos z z z Si se dispone de una transmisión confiable se pueden replicar todos los sub-espacios en todas las máquinas. Cuando se realiza una operación write la nueva instancia de tupla se transmite e ingresa en el sub-espacio adecuado para cada máquina Read o take realiza la búsqueda en el subespacio local. Para la consumación exitosa de un take, es necesario eliminar la tupla de todas las máquinas. Tuple broadcast Network Process doing a write broadcasts (a) Process doing a take examines local JavaSpace Tuple delete Subspaces Network (b) Consistencia y Replicación: Métodos Estáticos z z Este diseño es simple pero no escala bien a medida que aumenta el número de instancias de tupla o el tamaño de la red. El diseño inverso es realizar los write localmente, guardando la instancia de la tupla sólo en la máquina que la generó. Para realizar un read o take el proceso debe transmitir la tupla-plantilla. Cada receptor revisa para ver si tiene una tupla igual y contesta afirmativamente si la tiene. Si la instancia de la tupla no está presente o si no se recibe el mensaje en la máquina que tiene la tupla, la máquina solicitante retransmite (ad infinitum) hasta que obtiene una respuesta satisfactoria. 23 Process doing a write inserts tuple into local JavaSpace Network (a) Process doing a read broadcasts template Template broadcast Network (b) Consistencia y Replicación: Métodos Estáticos z Los dos métodos anteriores pueden combinarse para producir un sistema con replicación parcial: z z z Suponga que todas las máquinas forman una cuadrícula rectangular. Cuando el proceso A desea realizar una una operación write transmite (o envía un mensaje punto-punto) la tupla a todas las máquinas ubicadas en su fila de la cuadrícula. Cuando el proceso B desea leer o tomar una instancia de la tupla, transmite la tupla plantilla a todas las máquinas de su columna. Debido a la geometría siempre habrá exactamente una máquina que ve tanto la instancia de tupla como la tupla plantilla (C) A C A broadcasts tuple to these machines B B broadcasts template to these machines 24 Consistencia y Replicación: Métodos Estáticos z z Todas las implementaciones presentadas tienen problemas de escalabilidad (la mayoría se basa en multitransmisión) Las implementaciones de espacios de tuplas en redes de área amplia no existen. En el mejor de los casos pueden existir varios espacios de tuplas diferentes, y cada espacio se implementa en un servidor o en una red de área local. Replicación Dinámica z z z Ejem: GigaSpaces Se construyó encima de JavaSpaces. En este sistema la distribución y replicación de tuplas se realizan por dos razones: desempeño y disponibilidad. Se utilizan estrategias diferentes en ambos casos. Por esta razón se soportan varias políticas de replicación. Replicación Dinámica z z z Se ofrecen las llamadas read, write, take, al igual que con JavaSpaces. Cada una de estas llamadas es captada por un manejador de invocaciones local que busca la política a seguirse para la invocación específica. Se selecciona una política basada en el tipo y contenido de la tupla que se transfiere como parte de la invcación. 25 Replicación Dinámica z z z El manejador de invocación usa plantillas para identificar los diferentes tipos de tuplas. Posteriormente se invoca al gestor de distribución, el cual implemnta la misma interfaz pero ahora de acuerdo con una política de replicación específica. Ejem. Maestro-Esclavo. Todos tienen la tupla, un read puede ser local. Un write puede requerir que el gestor de distribución remita el nodo al maestro y espere un acuse de recibo antes de realizar la operación localmente. Application Dataspace slice Distribution Distribution Distribution manager manager manager Invocation handler Policy table Local OS To network Replicación Dinámica z z En GigaSpace la gestión de replicación es automática, i.e. en lugar de permitir que el desarrollador de aplicaciones decida qué política es la mejor, el sistema monitorea los patrones de acceso y comportamiento para posteriormente adoptar las políticas que se requieran. Con este objetivo GigaSpace continuamente mide el ancho de banda consumido, la latencia de la red y el uso de la memoria , coloca las tuplas en diferentes nodos y elige la manera más apropiada de mantener las réplicas consistentes. 26 Resumen z Los sistemas distribuidos basados en coordinación están enfocados en el desacoplamiento referencial de los procesos, i.e. éstos no tienen que referirse explícitamente entre sí para habilitar la comunicación. También es posible tener desacoplamiento temporal, de modo que los procesos no tienen que estar activos para comunicarse. Resumen z z Un grupo importante de estos sistemas está formado por aquellos que siguen el paradigma de publicación/suscripción (TIB/Rendevouz) En este modelo los mensajes no portan la dirección de sus receptores sino que en cambio son direccionados por tema. Un poco más complejos son aquellos sistemas donde los suscriptores pueden formar predicados sobre los atributos de los elementos de datos publicados. El enrutamiento en estos sistemas se hace basado en contenido. Resumen z z Otro grupo importante utiliza comunicación generativa, la cual ocurre por un espacio compartido de tuplas. Los principios de los SD se aplican a sistemas basados en coordinación. El almacenamiento en cache y la replicación desempeñan un rol menos prominente en las replicaciones actuales 27