Relojes Físicos en Sistemas Distribuidos

La sincronización en los sistemas distribuidos se logra a través de relojes. Existen 2 tipos de relojes: los físicos y los lógicos. Los primeros están relacionados con el tiempo real mientras que en los segundos lo importante es el orden de los eventos.

Relojes Físicos.

Las computadoras poseen un circuito para el registro del tiempo conocido reloj, el cual es un cronómetro que consiste en un cristal de cuarzo de precisión sometido a una tensión eléctrica que Oscila con una frecuencia bien definida que depende de: 

• A la forma en que se corte el cristal. 
• El tipo de cristal. 
• La magnitud de la tensión.

 Estos relojes son dispositivos electrónicos que cuentan las oscilaciones que ocurren en un cristal a con una frecuencia definida, y generalmente dividen este recuento y almacenan el resultado en un contador de registro. Los dispositivos de reloj se pueden programar para generar interrupciones a intervalos regulares para que, por ejemplo, se pueda implementar la división de tiempo.

A cada cristal se le asocian dos registros, Contador y Mantenedor que operan de la siguiente manera: 

• Cada oscilación del cristal decrementa en  1 al contador. 
• Cuando el contador llega a 0: genera una interrupción. 
• Contador se vuelve a cargar mediante el registro mantenedor. 
• Se puede programar un cronómetro para generar una interrupción tantas veces por segundo.
• Cada interrupción se denomina marca de reloj.

Sesgo del reloj y deriva del reloj

Los relojes de computadora, como cualquier otro, tienden a no estar en perfecto acuerdo. La diferencia instantánea entre las lecturas de dos relojes se llama su sesgo. Además, los relojes a base de cristal utilizados en las computadoras son, como cualquier otros relojes, sujetos a la deriva del reloj, lo que significa que cuentan el tiempo a diferentes velocidades muy divergente.

UTC

Los relojes de computadora se pueden sincronizar con fuentes externas de tiempo muy precisas. La hora universal coordinada: abreviada como UTC (del equivalente francés) es un estándar internacional para el cronometraje. Las señales UTC se sincronizan y transmiten regularmente desde estaciones terrenas de radio y satélites que cubren muchas partes del mundo. 

Las fuentes satelitales incluyen el Sistema de Posicionamiento Global (GPS). Los receptores están disponibles comercialmente. En comparación con el UTC , las señales recibidas de estaciones terrestres tiene una precisión del orden de 0.1 a 10 milisegundos, Dependiendo de la estación utilizada. Las señales recibidas de los satélites GPS tienen una precisión de aproximadamente 1 microsegundo Las computadoras con receptores conectados pueden sincronizar sus relojes con estas señales de tiempo.

Sincronizacion de Relojes Fisicos  

La sincronización del reloj físico se puede lograr de dos formas: Sincronización del reloj externo e interno. La sincronización de reloj externo es aquella en la que está presente un reloj de referencia externo, que se utiliza como referencia, y los nodos del sistema pueden establecer y ajustar su tiempo en consecuencia. Por otra parte, la sincronización del reloj interno es aquella en la que cada nodo comparte su tiempo con otros nodos y todos los nodos configuran y ajustan sus tiempos en consecuencia.

Hay 2 tipos de algoritmos de sincronización de reloj: centralizados y distribuidos. El centralizado es aquel en el que se utiliza un servidor horario como referencia. El servidor de tiempo único propaga su tiempo a los nodos y todos los nodos ajustan el tiempo en consecuencia. Depende de un servidor de tiempo único, por lo que si ese nodo falla, todo el sistema perderá la sincronización. Ejemplos de centralizados son: algoritmo de Berkeley, servidor de tiempo pasivo, servidor de tiempo activo, etc.

El algoritmo Distribuido es aquel en el que no existe un servidor horario centralizado. En cambio, los nodos ajustan su tiempo usando su hora local y luego, tomando el promedio de las diferencias de tiempo con otros nodos. Los algoritmos distribuidos superan el problema de los algoritmos centralizados como la escalabilidad y la falla de un solo punto. Un ejemplo de algoritmos distribuidos es el  NTP (protocolo de tiempo de red).

Algoritmo de Cristian

El algoritmo de Cristian es un algoritmo de sincronización de reloj que los procesos del cliente utilizan para sincronizar la hora con un servidor de hora. Este algoritmo funciona bien con redes de baja latencia donde el tiempo de ida y vuelta es corto en comparación con la precisión, mientras que los sistemas o aplicaciones distribuidos son propensos a la redundancia y no van de la mano con este algoritmo.

Aquí el tiempo de ida y vuelta se refiere al tiempo que transcurre entre el inicio de una solicitud y el final de la respuesta correspondiente. A continuación se muestra una figura que ilustra el funcionamiento del Algoritmo de Cristian:

Algoritmo de Cristian

Pasos del Algoritmo de Cristian

1.  El proceso en la máquina cliente envía la solicitud para obtener la hora del reloj (hora en el servidor) al servidor de reloj en la hora T_0.  
2. El servidor de reloj escucha la solicitud realizada por el proceso del cliente y devuelve la respuesta en forma de hora del servidor de reloj. 
3. El proceso del cliente obtiene la respuesta del Clock Server en el momento T_1 y calcula el tiempo del reloj del cliente sincronizado utilizando la fórmula que se proporciona a continuación:

[   T_{CLIENTE} = T_ {SERVIDOR} + (T_1  -  T_0 ) / 2   ] 

• donde T_ {CLIENTE} se refiere a la hora del reloj sincronizado 

• T_ {SERVER} se refiere a la hora del reloj devuelta por el servidor,
• T_0 se refiere a la hora a la que el proceso del cliente envió la solicitud,

• T_1 se refiere al momento en que el proceso del cliente recibió la respuesta

Algoritmo de Bekerley 

En el algoritmo de Cristian el servidor de tiempo es pasivo. En el caso del algoritmo de Berkeley, el servidor del tiempo está activo y realiza un muestreo de forma periódica a todas las máquinas para preguntarles su tiempo. En base al tiempo de todas las máquinas incluyéndose él mismo, obtiene el promedio y les indica a cada máquina cuanto tiempo deben adelantarse o retrasarse para lograr la sincronización. Al igual que en Cristian, para adelantar o retrasar el reloj hay que hacerlo paulatinamente de acuerdo a las interrupciones que genera el cronómetro.

Procedimiento. 

1. El servidor de tiempo le envia a cada máquina su tiempo
2. Las máquinas cliente le indican el número de segundos que están adelantadas o retrasadas con respecto al tiempo del servidor, si es un número positivo entonces están adelantadas y si es negativo están atrasadas.
3. El servidor suma todos estos datos y los divide entre el número de máquinas incluyéndose él mismo.
4. El resultado lo suma a su propio tiempo obteniendo T, y calcula el número de segundos que le falta o le sobra a una máquina para llegar a ese tiempo T, y se lo envía a la máquina. Lo mismo hace para cada máquina.
5. Las máquinas reciben el resultado y sincronizan su tiempo.

Algoritmo de Bekerley. Tomado de [2]

Algoritmo NTP 

NTP, Network Time Protocol, es un protocolo de internet para sincronizar  relojes de sistemas informaticos, a trav[es del enrutamiento de paquetes en redes con latencia variable. Usa UDP como su capa de transporte.  

NTP divide a los servidores en estratos: un servidor con un reloj de referencia, tal como un receptor WWV o un reloj atómico, se conoce como servidor de estrato 1 (se dice que el propio reloj opera en el estrato 0). Cuando A contacte a B, sólo ajustará su tiempo si su propio estrato es más alto que el de B. Además, después de la sincronización, el estrato de A será un nivel más alto que el de B. En otras palabras, si B es un servidor de estrato k, entonces A se volverá un servidor de estrato (k + 1) si el nivel de su estrato original ya era mayor que k. Debido a la simetría del NTP, si el nivel del estrato de A era menor que el de B, entonces B se autoajustará con A.

Algoritmo NTP. Tomado de NTP

Referencias

1. Coulouris, George F. Distributed Systems: Concepts and Design. Boston: Addison-Wesley, 2012.
2. Tanenbaum, Andrew S., and Maarten van Steen. Distributed Systems: Principles and Paradigms. Upper Saddle River, NJ: Pearson Prentice Hall, 2007

Sistemas Punto a Punto

 P2P

Los sistemas punto a punto (P2P) representan un paradigma para la construcción de aplicaciones y sistemas distribuidos en los que cada máquina (hosts) en Internet aportan datos y recursos computacionales;  permiten compartir estos datos y recursos a gran escala al eliminar cualquier requisito de servidores administrados por separado y su infraestructura asociada. Estos sistemas se utilizan para compartir archivos, almacenamiento en caché web, distribución de información y otros servicios, explotando los recursos de decenas de miles de máquinas en Internet.

Características de los Sistemas P2P

• El diseño de los sistemas P2P asegura que cada usuario aporte recursos al sistema. 
• Aunque los usuarios pueden diferir en los recursos que aportan, todos los nodos en un sistema P2P tienen la misma capacidad funcional y la misma responsabilidad. 
• El correcto funcionamiento de un sistema P2P no depende de la existencia de ningún sistema administrado centralmente. 
• Una cuestión clave para el funcionamiento eficiente de un sistema P2P es la elección del algoritmo para la ubicación de datos en los hosts y  su  posterior acceso  de manera que equilibre la carga de trabajo y garantice la disponibilidad sin agregar gastos generales indebidos.

Ubicación y enrutamiento de un Objeto Distribuido.

Un sistema P2P  de distribución de contenido esta conformado por una red de computadoras pares (nodos) y conexiones (enlaces) entre ellos. Esta red se forma encima de redes independiente de la red informática física subyacente (normalmente IP) y, por lo tanto, se denomina red superpuesta o una red de redes. 

Una red superpuesta ofrece: 

• un servicio que se adapta a las necesidades de una clase de aplicación o un servicio particular de nivel superior, por ejemplo, distribución de contenido multimedia;
• operación más eficiente en un entorno de red determinado, por ejemplo, enrutamiento en una red ad hoc; 
• una función adicional, por ejemplo, multidifusión o comunicación segura.

 Las redes superpuestas tienen las siguientes ventajas:

• Permiten definir nuevos servicios de red sin requerir cambios en la red subyacente.
• Fomentan la experimentación con servicios de red y la personalización de servicios para clases particulares de aplicaciones. 
• Se pueden definir múltiples superposiciones y pueden coexistir, siendo el resultado final una arquitectura de red más abierta y extensible.

Clasificación de Redes Superpuesta

Las redes superpuesta son centralizadas, desestructurada y estructuradas. Estas son sus características.

 

1. Red Superpuesta Centralizada. 

Se clasifican en:

  Arquitecturas puramente descentralizada.

• Todos los nodos de la red realizan las mismas tareas, actuando como servidores y clientes, indistintivamente. 
• No existe una coordinación central de sus actividades 

 Arquitecturas descentralizadas híbrida.

• Algunos de los nodos son supernodos y actúan como índices centrales locales
• Los supernodos se asignan dinámicamente (varía entre los diferentes sistemas) y, si fallan, se reemplazan automáticamente por otros.

Arquitecturas centralizadas

• Un servidor central que facilita la interacción entre pares
• El servidor mantiene directorios de metadatos que describen los archivos compartidos almacenados por los nodos pares
• El servidor realiza las búsquedas e identifica los nodos que almacenan los archivos.

2. Red Superpuesta No Estructurada. 

 La ubicación del contenido (archivos) no tiene ninguna relación con la topología de la red superpuesta. En una red no estructurada,  es necesario localizar el contenido, ya que:

• Ubicación del recurso  solo lo  conoce el remitente 
• Los compañeros y los recursos no tienen un identificador especial   
• Cada par es responsable solo de los recursos que envió 
• Introducción de nuevos recursos en cualquier lugar

La tarea principal es a) encontrar todos los nodos almacenando que están a cargo de los recursos que se ajustan a algunos criterios, y b) comunicarse directamente entre pares después de haber identificado a esos pares.

        Ejemplo de este tipo de redes es Napster y Gnutella 

3. Red superpuesta estructurada

La topología de superposición está estrictamente controlada y los archivos (o sus punteros) se colocan en ubicaciones especificadas con precisión. Básicamente, estos sistemas proporcionan una correspondencia entre el contenido (p. ej., el identificador del archivo) y la ubicación (p. ej., la dirección del nodo), en forma de una tabla de enrutamiento distribuida.

Las cualidades de estas redes:

• La ubicación de los recursos no solo la conoce el remitente

• Cada par bien puede ser responsable de  recursos que no ha enviado

• Agregar nuevos recursos en una ubicación específica (incluye identificadores (únicos) de pares y recursos)

• PeerIDs y ObjectIDs (RessourceIDs) deben ser el mismo tipo de claves

• Cada par es responsable de un rango específico de ObjectID (RessourceID)

La tarea principal es enrutar las consultas a través de la red superpuesta a pares con identificaciones específicas. Pastry es un ejemplo de este tipo de Redes

Referencias

1. Coulouris, George F. Distributed Systems: Concepts and Design. Boston: Addison-Wesley, 2012.
2. Tanenbaum, Andrew S., and Maarten van Steen. Distributed Systems: Principles and Paradigms. Upper Saddle River, NJ: Pearson Prentice Hall, 2007. 

Rest

REST

REST (Representational State Transfer) [1] es un estilo de arquitectura presenta por Roy Fielding  en su disertación doctoral el año 2000. Es un enfoque  en el que los clientes usan URL y las operaciones HTTP GET, PUT, DELETE y POST para manipular recursos que están representados en XML. El énfasis está en la manipulación de los recursos de datos más que en las interfaces. Cuando se crea un nuevo recurso, tiene una nueva URL mediante la cual se puede acceder o actualizar. A los clientes se les proporciona el estado completo de un recurso en lugar de llamar a una operación para obtener una parte de él.

Rest se basa en los  principios descritos a continuación:

• Interfaz uniforme. Para lograr una interfaz REST uniforme se requiere que la Identificación de recursos, manipulación de recursos a través de representaciones (los recursos deben tener representaciones uniformes en la respuesta del servidor), Mensajes autodescriptivos (cada representación de recursos tiener suficiente información para describir cómo procesar el mensaje) e  Hipermedia como motor del estado de la aplicación (el cliente debe tener solo el URI inicial de la aplicación). 
• Cliente-Servidor. El patrón de diseño cliente-servidor impone la separación de intereses, lo que ayuda a que los componentes del cliente y del servidor evolucionen de forma independiente. 
• Sin Estado:  exige que cada solicitud del cliente al servidor debe contener toda la información necesaria para comprender y completar la solicitud. 
• Cacheable  o almacenable en caché: requiere que una respuesta se etiquete implícita o explícitamente como cacheable o no cacheable.
• Sistema en capas: permite que una arquitectura se componga de capas jerárquicas al restringir el comportamiento de los componentes.
• Código bajo demanda. REST permite que la funcionalidad del cliente se extienda mediante la descarga y ejecución de código en forma de applets o scripts.

Aplicación de comercio electrónico.

A continuación y como ejemplo práctico de desarrollo un aplicaciones de microservicios usando Rest,  se presenta el desarrollo de una aplicación de comercio electrónico usando una arquitectura orientada a microservicios (tomada de [1]). La metodología de  desarrollo que se muestra se basa en la metodología propuesta  por [2,3] para la implementación de microservicios.  A continuacion, los aspectos resaltantes del diseño de la aplicación.

1. Diseño del Monolito.  

Identificar qué entidades pertenecen al dominio de la aplicación, y qué interacciones y relaciones habrá entre las mismas, lo cual es posible de evidenciar mediante el diseño de un diagrama entidad y relación.

Diagrama entidad relación de una aplicación de comercio electrónico. Tomada de [1]

2. Casos de Usos.

Se diseña los casos de usos, entre ellos,  el proceso de compra de producto y el proceso de administración. En el primero, figura izquierda, se proyectan  dos procesos: compra manual y compra automática. En la compra manual el usuario obtiene la información del vendedor para que determinen el método de pago mientras que en la compra automática el pago se realiza cuando el usuario decida a través de la plataforma de servicio externa.

Caso de Uso Compras. Tomado [1]

Caso de Uso Administración. Tomado[1]

En el caso de uso de la figura derecha, se pueden ver las acciones que puede hacer un usuario cuando entra al módulo de administración, en la cual puede gestionar distintos procesos acerca de sus compras, ventas, productos, reputación y configuración de su cuenta. 

3. Diseño del API 

Se  especifica  la definición de la interfaz de la API Rest que expone la aplicación monolítica, ya que esta sirve como guía para detallar que recursos manejan los servicios y como se ofrecen. Los servicios de una API, son un contrato entre el servicio y sus clientes, es importante definir precisamente los servicios de la API usando algún tipo de lenguaje de definición de interfaz.  Se usa un lenguaje de definición de interfaz , por ejemplo  ApiBlueprint, que engloba el conjunto de suposiciones semánticas sobre la sintaxis usada para describir la interfaz de la aplicación. 

4. Diseño de  Microservicios

Se proyectan  los microservicios, y como primer paso se define  el contexto límite (bounded context) de la aplicación.  para delimitar los dominios de la aplicación.  

Contexto limites  aplicación Comercio Elctrónico. Tomado de [1]

Los contextos límite son Producto, Publicación, Orden y Usuario. El contexto límite Producto es responsable de gestionar los productos y sus ofertas. Publicación gestiona la información de las publicaciones asociadas a los productos del comercio electrónico y sus comentarios. El contexto Orden gestiona el proceso de órdenes de compra. El contexto  de Usuario gestiona la información de los usuarios que se registran en la aplicación de comercio electrónico.

 Se diseña cada microservicio a partir de los contextos limites descritos arriba. En la figura siguiente se muestra los  cuatros contexto límite definido. Cada uno de ellos se proyecta como un microservicio, pero también es posible que cada entidad sea un microservicio; por ejemplo, en el contexto Producto, pudiera generarse el microservicio de Producto y el microservicio de Oferta, sin embargo, si la comunicación entre ambos microservicios es muy frecuente, debe considerarse la latencia del sistema distribuido asociada con la comunicación entre ambos microservicios. 

Entidades agrupadas según contexto limite. Tomada de [1]

En la siguiente figura  se presenta un esquema de la aplicación comercio electrónico utilizando los microservicios definidos a través del contexto límite:    

 

Aplicación Comercio Electrónico. Tomado de [1]

 Un aspecto importante para resaltar, es que en el microservicio de Orden se usa un adaptador de un proveedor externo, conocido este término como third-party API, esto con el fin de gestionar los pagos a través de una Api de un servicio externo. 

5. Escoger patrón comunicación Cliente-Microservicio 

El patrón de comunicación Cliente-Microservicio escogido en la aplicación fue el API Gateway, dado que este patrón evita que los clientes tengan una  comunicación directa con cada microservicio para pedir una información específica. El API Gateway es la puerta de entrada a la aplicación, que le permite al cliente tener comunicación con los microservicios. Aunque por sí mismo, no es considerado como un microservicio, este sigue siendo una parte del sistema, y por ende, debe ser diseñado, desarrollado y desplegado.

El API Gateway diseñado usa la interfaz REST ya definida en la sección 3, por lo que las peticiones hechas hacia las API deben ser por el protocolo HTTP. Dentro de la aplicación el API Gateway cumplirá con la función de ser el principal orquestador de los microservicios, y se encargará de agregar y agrupar las respuestas que devuelvan estos, para así devolver una única respuesta al cliente que realice la petición.

La comunicación entre el cliente y el API Gateway será a través de HTTP, pero la comunicación entre el API Gateway y los microservicios será por RPC, como se muestra la figura. Se observa  como el cliente web (navegador) realiza una petición HTTP con el método POST al endpoint /api/user/account con el fin de crear una nueva cuenta de usuario dentro de la aplicación, posteriormente el API Gateway se comunica con el microservicio de usuario a través de RPC y como paso final devuelve una respuesta al cliente para indicar que la creación de su cuenta de usuario fue exitosa.

Protocolo de comunicaciones. Tomado de [1]

   

La arquitectura completa de la aplicación se muestra en este esquema:

Arquitectura de aplicación Comercio Electrónico. Tomado de [1]

 6. Descubrimiento de Servicios

Cada microservicio posee un registro local,  pero es necesario un mecanismo de eventos a través del cual un microservicio pueda comunicarle a los demás que se encuentra disponible o que ha dejado de estarlo. Para esta tarea se utilizó RedisDB, que es una  base de datos en memoria que puede funcionar como una caché o agente de mensajes (publicador/suscriptor).  

 El proceso que siguen los microservicios de la aplicación al momento de guardar y borrar información de sus registros locales es el siguiente:

• Se despliega un microservicio en su entorno correspondiente. A su vez, este microservicio se suscribe a un canal compartido de RedisDB que le permitirá recibir mensajes publicados por otros microservicios. Figura izquierda.
• Al ser desplegado, el microservicio publica un nuevo mensaje en el canal compartido, en el cual envía información que contendrá su IP, puerto e ID.  Figura derecha.

• Los microservicios que se encontraban previamente disponibles, reciben el nuevo mensaje publicado por el microservicio que acaba de desplegarse, y proceden a guardar en su registro local la información de este. Figura izquierda.
• Estos microservicios también envían su información a través del canal compartido, para que el microservicio que acaba de ser desplegado guarde en su registro local toda la información de los otros microservicios que ya se encontraban disponibles. Figura derecha.

• Cuando algún microservicio se detiene por alguna razón, este envía un mensaje por el canal, indicando a los demás microservicios que deben borrar su información de su registro local:

Una vez registrados los microservicios es necesario descubrir su ubicación para entablar una comunicación entre estos a través de RPC. El proceso para descubrir a otro microservicio dentro de la aplicación es el siguiente: 

1. Un servicio (API Gateway o microservicio) busca dentro de su registro local, en que puerto y en que IP un microservicio específico se encuentra disponible. 
2. Una vez que se ha obtenido la ubicación del microservicio, se realiza la comunicación con éste a través de RPC

Descubrimiento de Servicios. Tomado de [1].

7. Orquestación

Dentro de la aplicación, el API Gateway se encarga de enrutar cada petición al microservicio que corresponda, por lo que, el API Gateway es el cerebro orquestador de la aplicación. Un caso de orquestación se muestra cuando se intenta consultar el detalle de una publicación, debido a que,  es necesario consultar a varios microservicios para devolver una respuesta al cliente.

En la figura siguiente se observa como el API Gateway se comunica con el microservicio de Publicación para obtener los detalles de la publicación que se desea consultar; una vez obtenida esta respuesta, se comunica con el microservicio de Producto para obtener el detalle del producto que está asociado con la publicación consultada; y en última instancia, pasa a comunicarse con el microservicio de Usuario para obtener la información del usuario (vendedor) al que le pertenece dicha publicación. En todo este proceso el API Gateway se encarga de ir consultando uno a uno los microservicios e ir agregando la información devuelta por cada uno de estos, para luego dar una respuesta unificada al cliente. 

Diagrama de secuencia Detalle Publicación. Tomado [1].

8. Coreografía

En la figura  se presenta el proceso de creación de una publicación. En dicho proceso se puede observar que cuando el API Gateway envía una petición al microservicio de Publicación para crear una nueva, este último actúa en consecuencia invocando al método checkOnwerShip del microservicio de Producto, para saber, si el producto que se desea asociar a la nueva publicación, le pertenece al usuario que realizó la petición inicial. Esta acción en consecuencia llevada a cabo por parte del microservicio Publicación, es característico de un enfoque coreógrafo. Para este caso la interacción de la comunicación sigue siendo síncrona, ya que, para cada petición realizada, se espera una respuesta para poder continuar con el proceso.

Diagrama de colaboración: Creación de publicación. Tomado de [1]

 

Referencias

1. Salas, A., Marquez, A. Arquitectura orientada a Microservicios aplicada a un sistema de Comercio Electrónico. Trabajo de Grado de Pregrado, UNEG. 2017.
2. Newman, S. Building Microservices. O'Reilly Media, Feb. 2015. 
3. Richardson, C., and Smith, F. Microservices from Design to Deployment. NGINX, Inc. 2016. 
4.  Thomas Erl, Service Oriented Architecture: Principles of Service Design. The Prentice Hall Service-Oriented Computing Series by Thomas Erl. 2007 

Monolitos vs Microservicios

Aplicaciones monolíticas 

 Las aplicaciones monolíticas consisten en un solo proceso que abarca una sola capa de aplicación, soportando las reglas de negocio, la manipulación de los datos y en ocasiones la interfaz de usuario. Los datos pueden ser almacenados físicamente en una ubicación remota, pero la lógica para su acceso y procesamiento es parte de la  aplicación.

Como se observa en la figura 1, en el núcleo de una aplicación monolítica está la lógica de negocio, que definen los servicios que ofrece el sistema. Alrededor del núcleo están los adaptadores que se conectan con servicios externos, que incluyen componentes de acceso a base de datos, de mensajería web y que exponen la interfaz de programación de la aplicación,  API.

1. Ejemplo de un monolito. Tomado de [2]

Ventajas y desventajas de aplicaciones monolíticas.

Entre las ventajas se destaca:

• Pruebas Unitarias: las aplicaciones monolíticas son fáciles de probar, debido a su popularidad en los últimos años, existen variedades de herramientas para realizar las pruebas unitarias, y debido a que estas aplicaciones corren bajo un mismo proceso, con sólo ejecutar el proceso se pueden hacer las pruebas necesarias.
• Implementación:  son fáciles de implementar ya que, por lo general, es necesario copiar un único archivo en un directorio. 
• Comunicación: ya que en las aplicaciones monolíticas todo está construido en un solo programa, no hay necesidad de una comunicación complicada a través de la red.  

Y la desventajas de su uso:

• Desarrollo: las aplicaciones exitosas tienen el hábito de crecer con el tiempo, este crecimiento s refleja en el incremento de los requerimientos, el alcance de la aplicación  y en la ampliación del equipo de desarrolladores, así como aumento de la complejidad del código. 
• Despliegue continuo: Para realizar cambios en producción, es necesario redesplegar toda la aplicación, independientemente de lo que se necesite modificar, resultando difícil su manejo.
• Escalabilidad:  cada uno de lo módulos de un  monolito posee requerimientos de hardware distintos, en consecuencia, la capacidad de escalar de manera independiente se convierte en una tarea compleja. 
• Resistencia a fallas: ya que todos los módulos que componen las aplicaciones corren sobre un mismo proceso, una falla en cualquiera de estos módulos, puede hacer fallar el proceso completo. 
• Heterogeneidad Tecnológica: los módulos de la aplicación corren bajo un mismo proceso, y estos están escritos en un mismo lenguaje de programación con un framework específico, haciendo costoso adoptar nuevas tecnologías.

Microservicios

El estilo arquitectónico de microservicio se enfoca en desarrollar una sola aplicación como un conjunto de pequeños servicios, cada uno ejecutándose en su propio proceso y comunicándose con mecanismos ligeros. Estos servicios se basan en capacidades de negocios y son desplegados independientemente mediante cualquier mecanismo de despliegue automatizado

En la figura 2 se observa el esquema de la aplicación presentada en la figura 1, adoptando ahora un enfoque orientado a microservicios, donde se puede ver que cada módulo de la aplicación monolítica ahora se ha convertido en un microservicio independiente, que interactúa con otros.

2. Ejemplo de Aplicación con microservicios. Tomada de [1]

Ventajas y Desventajas de los Microservicios

Entre sus ventajas destaca:

• Heterogeneidad tecnológica: con un sistema compuesto de múltiples microservicios colaboradores, se puede decidir utilizar diferentes tecnologías dentro de cada uno.
• Resistencia: en las aplicaciones basadas en microservicios: si en un microservicio se presenta una falla, esta solo afectará a dicho microservicio, y no a todo el sistema, existen mecanismos de resistencia a fallas para que los otros microservicios continúen trabajando.
• Escalabilidad: en microservicios, la escalabilidad se puede aplicar a los microservicios que la necesiten, esto permite que se enfoquen los recursos necesarios a los microservicios que lo requieran.
• Fácil despliegue: a diferencia de las aplicaciones monolíticas, que para realizar un cambio en producción se requiere el despliegue de toda la aplicación como una pieza independientemente del tamaño del cambio, en los microservicios, el despliegue es por microservicio; un cambio en un microservicio es independiente de los demás que conformen el sistema.
• Reemplazabilidad: En un sistema con microservicios individuales de pequeño tamaño, el costo de reemplazarlos o borrarlos, es menor, que reemplazar alguna funcionalidad de un sistema monolítico.

Los  microservicios tienen muchas ventajas, pero no son perfectos; tienen asociados las dificultades que acompañan  a los sistemas distribuidos.  Entre sus desventajas:

• Complejidad: por el hecho de que son sistemas distribuidos. Los desarrolladores necesitan elegir e implementar un mecanismo de comunicación entre procesos;  también el  código para manejar fallos parciales.
• Bases de datos: para microservicios se puede manejar varios enfoques para base de datos; es común  el crear una base de datos para cada microservicio, lo cual conlleva a transacciones con múltiples bases de datos. Las transacciones en este tipo de sistema, conllevan a gestionar varias bases de datos pertenecientes a diferentes microservicios.
• Pruebas unitarias:  las pruebas unitarias las cuales son complejas, ya que en este tipo de aplicaciones es necesario acoplar el funcionamiento de los módulos o funciones del sistema que requieran conexiones con otros componentes de la red (bases de datos o microservicios). 

Referencias

1. Salas, A., Marquez, A. Arquitectura orientada a Microservicios aplicada a un sistema de Comercio Electrónico. Trabajo de Grado de Pregrado, UNEG. 2017.
2. Richardson, C., and Smith, F. Microservices from Design to Deployment. NGINX, Inc. 2016. NG.
3. Thomas Erl, Service Oriented Architecture: Principles of Service Design. The Prentice Hall Service-Oriented Computing Series by Thomas Erl. 2007 

SOAP

De acuerdo a W3C , SOAP ( Simple Object Access Protocol)   es un protocolo ligero para el intercambio de información en un entorno distribuido y descentralizado. Esta  basado en XML y  consta de tres partes: 

• El constructo Sobre o envelope   define un marco general para expresar lo que hay en un mensaje; quién debe ocuparse de él, y si es opcional u obligatorio.
• Las reglas de codificación SOAP definen un mecanismo de serialización que se puede utilizar para intercambiar instancias de tipos de datos definidos por la aplicación.
• La representación SOAP RPC  define una convención que se puede utilizar para representar llamadas y respuestas a procedimientos remotos.

Sobre 

Un mensaje SOAP contiene lo siguiente, vea el esquema presentado en la figura 1:

• El Sobre o Envelope es el elemento superior, la raíz del documento XML que representa el mensaje.
• El Encabezado o Header  es un mecanismo genérico para agregar características a un mensaje SOAP de manera descentralizada sin acuerdo previo entre las partes comunicantes. 
• El Cuerpo o Body  es un contenedor de información obligatoria destinada al destinatario final del mensaje.

1. Sobre o Envelope. Tomado de [1]

Reglas de Codificación SOAP 

El conjunto de reglas de codificación expresa instancias de tipos de datos definidos por la aplicación. Las reglas de codificación definen un mecanismo de serialización que puede utilizarse para intercambiar instancias de los tipos de datos definidos por la aplicación. SOAP define un esquema de tipos de datos independiente del lenguaje de programación basado en XSD (XML Schema) más reglas de codificación para todos los tipos de datos definidos de acuerdo con este modelo.

Ver el detalle de estas reglas en  W3C Soap Encoding

La representación SOAP RPC

Las comunicaciones pueden seguir el formato de llamada a procedimiento remoto (RPC).  ver W3C SOAP RPC 

Un mensaje SOAP se puede utilizar para transmitir un documento o para respaldar la comunicación cliente-servidor:

• El mensaje o documento  que se va a comunicar se coloca directamente dentro del elemento body junto con una referencia a un esquema XML que contiene la descripción del servicio, que define los nombres y tipos utilizados en el documento. Este tipo de mensaje SOAP se puede enviar de forma síncrona o asíncrona. 
• Para la comunicación cliente-servidor, el elemento del cuerpo contiene una Solicitud o una Respuesta. Estos dos casos se pueden ver en la  Figura 2 y la Figura 3.

2. Mensaje solicitud. Tomado de [1]

3. Mensaje de Respuesta. Tomado de [1]

 

La figura 2 [1]  muestra un ejemplo de un mensaje de solicitud simple sin encabezado. El cuerpo incluye un elemento que contiene el nombre del procedimiento que se llamará y el URI del espacio de nombres  para la descripción del servicio relevante, que se denota por m. Los elementos internos de un mensaje de solicitud contienen los argumentos del procedimiento. Este mensaje de solicitud proporciona dos cadenas que el procedimiento del servidor devolverá en el orden opuesto. El espacio de nombres XML denotado por env contiene las definiciones SOAP para un envelope.

La Figura 3 muestra el ejemplo de un  mensaje de respuesta correspondiente, que contiene los dos argumentos de salida. Si un procedimiento tiene un valor de retorno, entonces puede indicarse como un elemento denominado rpc:result. El mensaje de respuesta utiliza los mismos dos esquemas XML que el mensaje de solicitud, el primero define el sobre SOAP y el segundo los nombres de argumentos y procedimientos específicos de la aplicación.

SOAP y HTTP

Se requiere un protocolo de transporte para enviar un mensaje SOAP a su destino. SOAP sigue  el modelo de mensaje de solicitud/respuesta HTTP que proporciona parámetros de solicitud SOAP en una solicitud HTTP y parámetros de respuesta SOAP en una respuesta HTTP.  La figura 4 ilustra cómo se utiliza el método HTTP POST para transmitir un mensaje SOAP. 

4. HTTP y SOAP. Tomado de [1]

Los encabezados y el cuerpo HTTP se utilizan de la siguiente manera:

• Encabezados HTTP especifican la dirección del punto final (el URI del último receptor) y la acción que se llevará a cabo. El encabezado Action tiene como objetivo optimizar el envío al revelar el nombre de la operación sin necesidad de analizar el mensaje SOAP en el cuerpo del mensaje HTTP. 
• El cuerpo HTTP lleva el mensaje SOAP.

Como HTTP es un protocolo síncrono, se usa un mensaje de respuesta SOAP para devolver la respuesta. Si una solicitud SOAP es solo una solicitud de devolución de información, no tiene argumentos y no altera los datos en el servidor, entonces se puede usar el método HTTP GET para llevarla a cabo.

Referencias

1. Coulouris, George F. Distributed Systems: Concepts and Design. Boston: Addison-Wesley, 2012.
2. Tanenbaum, Andrew S., and Maarten van Steen. Distributed Systems: Principles and Paradigms. Upper Saddle River, NJ: Pearson Prentice Hall, 2007. 
3. Thomas Erl, Service Oriented Architecture: Principles of Service Design. The Prentice Hall Service-Oriented Computing Series by Thomas Erl. 2007 
4. Salas, A., Marquez, A. Arquitectura orientada a Microservicios aplicada a un sistema de Comercio Electrónico. Trabajo de Grado de Pregrado, UNEG. 2017.

Servicios Web

 Servicios Web (Web Services) en [1] lo definen como  una colección de operaciones que un cliente puede utilizar a través de Internet. Las operaciones en un servicio web pueden ser proporcionadas por una variedad de recursos diferentes, por ejemplo, programas, objetos o bases de datos. Un servicio web puede ser administrado por un servidor web junto con páginas web; o puede ser un servicio totalmente separado.

En W3C definen a los servicios web como un sistema de software diseñado para admitir la interacción  de máquina a máquina a través de una red. Tiene una interfaz descrita en un formato procesable por máquina (específicamente WSDL). Otros sistemas interactúan con el servicio web de la manera prescrita por su descripción utilizando mensajes SOAP, normalmente transmitidos mediante HTTP con una serialización XML junto con otros estándares relacionados con la web.

La arquitectura del Servicio Web esta compuesta de tres elementos: el proveedor del  servicios web, el que pide el servicio web (cliente) y el publicador (corredor) del servicio (ver figura). 

La interacción entre estos componentes se detallan a continuación: el proveedor de servicios envía al publicador (corredor) del servicio un fichero WSDL con la definición del servicio web. El que pide el servicio contacta con el publicador y descubre quién es el proveedor (protocolo WSDL) y contacta con el proveedor (protocolo SOAP). El proveedor valida la petición de servicio y envía el dato estructurado en formato XML utilizando el protocolo SOAP. El fichero XML es validado de nuevo por el que pide el servicio utilizando un fichero XSD (XML Schema).

Servicios

Características de los Servicios Web

• Uso de XML para representación de los mensajes  y  SOAP como protocolo. 
• Combinación con otros servicios web para construir otras funcionalidades.
• Uso de múltiple paradigmas de comunicación: Solicitud-Respuesta (RR) síncronos y  RR asíncronos, o combinaciones de ellos.
• Acoplamiento Débil: minimizar las dependencias entre servicios proporcionando una arquitectura  flexible y tolerancia a fallas
• Referencia a servicios: Uso de URL (o URN) para identificar los servicios
• Activación de servicios: el servicio puede estar activo o activarse por demanda, y puede estar replicado.
• Transparencia:  se proporciona API  para esconder los  detalles del uso de SOAP y XML.

Referencias

1. Coulouris, George F. Distributed Systems: Concepts and Design. Boston: Addison-Wesley, 2012.
2. Tanenbaum, Andrew S., and Maarten van Steen. Distributed Systems: Principles and Paradigms. Upper Saddle River, NJ: Pearson Prentice Hall, 2007. 
3. Thomas Erl, Service Oriented Architecture: Principles of Service Design. The Prentice Hall Service-Oriented Computing Series by Thomas Erl. 2007 
4. Salas, A., Marquez, A. Arquitectura orientada a Microservicios aplicada a un sistema de Comercio Electrónico. Trabajo de Grado de Pregrado, UNEG. 2017.

Computación Orientada a Servicios

Un servicio [1] es una abstracción que representa un componente autodescriptivo e independiente de la plataforma y que puede realizar cualquier función, desde una función simple hasta un proceso comercial complejo. Prácticamente cualquier pieza de código que realice una tarea se puede convertir en un servicio y exponer sus funcionalidades a través de un protocolo accesible en red. 

Las características relevante del servicio es que está débilmente acoplado, es reutilizable, es independiente del lenguaje de programación y tiene una ubicación transparente. El bajo acoplamiento permite que los servicios sirvan a diferentes escenarios más fácilmente y los hace reutilizables. La independencia de una plataforma específica aumenta la accesibilidad de los servicios. Por lo tanto, se puede atender a una gama más amplia de clientes, que pueden buscar servicios en registros globales y consumirlos de manera transparente en cuanto a la ubicación. 

La orientación a servicios [2] es un paradigma de diseño destinado a la creación de unidades de soluciones lógicas que tienen forma individual, para que puedan utilizarse colectiva y repetidamente  con el propósito de respaldar la realización de los objetivos y beneficios estratégicos específicos asociados con la arquitectura orientada a servicios SOA y la informática orientada a servicios. La solución lógica diseñada de acuerdo con la orientación a servicios se puede calificar como orientada a servicios, y las unidades de solución  lógica orientada a servicios se denominan servicios.

Los servicios se componen y agregan en una arquitectura orientada a servicios (SOA), que es una forma lógica de organizar los sistemas de software para proporcionar a los usuarios finales u otras entidades distribuidas en la red servicios a través de interfaces publicadas y detectables. SOA establece un modelo arquitectónico orientado a mejorar la eficiencia, la agilidad y la productividad de una empresa mediante el uso de la informática orientada a servicios. Una implementación de SOA puede consistir en una combinación de tecnologías, productos, API, infraestructura de soporte y otros elementos.

La  computación orientada a servicios (COS) [2] representa una plataforma informática distribuida de nueva generación.  Como tal, abarca muchas cosas, incluido su propio paradigma de diseño y principios de diseño, catálogos de patrones de diseño, lenguajes de patrones, un modelo arquitectónico distinto y conceptos, tecnologías y marcos relacionados. COS introduce y difunde dos conceptos importantes, que también son fundamentales para la computación en la nube[1]: la calidad de servicio (QoS) y el software como servicio (SaaS):

• QoS identifica un conjunto de atributos funcionales y no funcionales que se pueden utilizar para evaluar el comportamiento de un servicio desde diferentes perspectivas. Estas podrían ser métricas de rendimiento como el tiempo de respuesta o los atributos de seguridad, la integridad transaccional, la confiabilidad, la escalabilidad y la disponibilidad.
• SaaS  introduce un nuevo modelo de entrega de aplicaciones.  El enfoque de SaaS alcanza su pleno desarrollo con la computación orientada a servicios (SOC), donde los componentes de software débilmente acoplados pueden exponerse y cotizarse individualmente, en lugar de aplicaciones completas. Esto permite la entrega de procesos comerciales complejos y transacciones como un servicio, al tiempo que permite que las aplicaciones se compongan sobre la marcha y los servicios se reutilicen desde cualquier lugar y por cualquier persona.

La orientación al servicio es el modelo de referencia central para los sistemas de computación en la nube. Este enfoque adopta el concepto de servicios como los principales componentes básicos del desarrollo de aplicaciones y sistemas. La computación orientada a servicios  admite el desarrollo de aplicaciones y sistemas rápidos, de bajo costo, flexibles, interoperables y evolutivos.

Una de las expresiones más populares de orientación a servicios está representada por los servicios web (WS)[1] . Estos introducen los conceptos de COS  en la World Wide Web, haciéndola consumible por aplicaciones y no solo por humanos. Los servicios web son componentes de software que exponen funcionalidades accesibles mediante un patrón de invocación de métodos que pasa por el Protocolo de transferencia de hipertexto (HTTP). La interfaz de un servicio web se puede inferir programáticamente mediante metadatos expresados ​​a través del lenguaje de descripción de servicios web (WSDL); este es un lenguaje XML que define las características del servicio y todos los métodos, junto con los parámetros, descripciones y tipo de retorno, expuestos por el servicio.  La interacción con los servicios web ocurre a través del Protocolo simple de acceso a objetos (SOAP). Este es un lenguaje XML que define cómo invocar un método de servicio web y recopilar el resultado.

 Usando SOAP y WSDL sobre HTTP, los servicios web se vuelven independientes de la plataforma y accesibles para la World Wide Web. Los estándares y especificaciones relativos a los servicios web están controlados por el World Wide Web Consortium (W3C). 

Referencias

1. Buyya, R., Vecchiola, C., & Selvi, S. T.,  Mastering Cloud Computing, Mc Graw Hill India, 2013, ISBN 9781259029950.
2. Thomas Erl, Service Oriented Architecture: Principles of Service Design. The Prentice Hall Service-Oriented Computing Series by Thomas Erl. 2007 
3. Coulouris, George F. Distributed Systems: Concepts and Design. Boston: Addison-Wesley, 2012.
4. Tanenbaum, Andrew S., and Maarten van Steen. Distributed Systems: Principles and Paradigms. Upper Saddle River, NJ: Pearson Prentice Hall, 2007. 
5. Rodrigues, Luís and Veríssimo, Paulo. Advances in Distributed Computing and Middleware. 
6. Salas, A., Marquez, A. Arquitectura orientada a Microservicios aplicada a un sistema de Comercio Electrónico. Trabajo de Grado de Pregrado, UNEG. 2017.

Cola de Mensajes y Microservicios

 Cola de Mensajes

Una cola de mensaje es un protocolo de comunicaciones asíncrono, el cual consiste en comunicar dos procesos separados mediante una cola (de mensajes) la cual incluye una secuencia de objetos creados por el emisor (productor)  esperando ser procesados por el proceso que lo consumirá (consumidor). Un sistema que pone un mensaje en una cola de mensajes no requiere una respuesta inmediata para continuar el procesamiento. 

 Una cola de mensajes ofrece un búfer ligero que almacena temporalmente los mensajes, y puntos de enlace que permiten a los componentes de software conectarse a la cola para enviar y recibir mensajes.  ver Figura 1.

1. Cola de Mensajes

Existen varias soluciones para protocolos de colas de mensajes: AMQP, MQTT, STOMP. Veamos las características de AMQP.

Protocolos de Colas de Mensaje AMQP

AMQP (Advanced Message Queuing Protocol). El protocolo AMQP opera de la siguiente manera: por un lado, el protocolo (en colaboración con un bróker de mensajería) se encarga de una transmisión de datos. Por otro, AMQP permite almacenar mensajes en una cola. Esto, a su vez, permite una comunicación asíncrona: transmisor y receptor no deben actuar al mismo ritmo. El receptor (consumidor) recuperará el mensaje de la cola cuando tenga capacidad disponible para ello ( el receptor  no tiene por qué aceptar el procesamiento de la información  ni la confirmación de la recepción al emisor).  Esto ofrece al productor (publicador), entre otras cosas, la posibilidad de seguir trabajando y se evitan los tiempos de inactividad.  Ver Figura 2.

2. Protocolo AMQP

En AMQP. el mensaje es el elemento central de comunicación y además de una serie de elementos:

• El productor o publicador (publisher) crea un mensaje, lo envía y es publicado en un buzón (exchange).
• El servidor (bróker de mensajería) distribuye o enruta el mensaje desde el buzón de acuerdo con unas reglas definidas (bindings) en diferentes colas (queue).
• El consumidor (consumer) recupera el mensaje de la cola a la que está suscrito.

El buzón o intercambiador (exchange) recibe los mensajes y dirige los datos a una cola utilizando una vinculación (binding) que le permite decidir cuál es la correcta. 

El bróker interrumpe la difusión del mensaje una vez más: el intercambiador recibe los mensajes y dirige los datos a la cola correcta. La vinculación informa al intercambiador sobre la cola a la que pertenece el mensaje. 

Cola de Mensajes y Microservicios

Una cola de mensajes es una forma de comunicación asíncrona que se usa en arquitecturas de microservicios. Los mensajes se almacenan en la cola hasta que se reciben y, luego se eliminan,  siendo cada mensaje procesado una sola vez.

Esta estructura intermedia permite ajustar la velocidad y disponibilidad de diferentes microservicios de forma que puedan trabajar conjuntamente y puedan recuperarse de los errores, lo que aumenta el nivel de tolerancia a fallos. 

La siguiente figura, Figura 3, muestra la arquitectura propuesta para una aplicación de comercio electrónico, usando microservicios. Los microservicios proyectados son: Facturación, Notificaciones, Pagos, Gestión de Cuenta, Archivos y Reportes. Cada microservicio tiene una  interfaz pública, API. El API Gateway, es un microservicio adicional que opera como un balanceador de cargas.

3.  Arquitectura de Aplicación de Comercio Electrónico. Tomado de  [4].

Cuando se usa el patrón de mensaje publicador/subscriptor y la topología de comunicación AMQP , el publicador envía un mensaje al destinatario con un tópico. La habilidad del publicador de poner el mensaje es independiente de la disponibilidad de la aplicación subscriptora. 

La cola de mensaje actúa como intermediario, y es responsable de entregar el mensaje a los subscriptores.  En cualquier momento, el subscriptor podría no estar disponible, por lo que la cola de mensaje puede retener el mensaje hasta que el subscriptor sea capaz de consumirlo, esto puede servir como un mecanismo de comunicación resistente a fallas entre los servicios involucrados.

Si un proceso en un sistema desacoplado falla  al procesar mensajes de la cola, otros mensajes pueden agregarse a la cola y procesarse cuando el sistema se haya recuperado.  

En la figura 3, el API Gateway y  Orden, poseen un adaptador para trabajar con cola de mensajes ( con RabbitMQ ). Este adaptador les provee acceso a un servidor de cola de mensajes, en el cual pueden publicar información en caso de que ocurra algún error en la comunicación. En tal sentido, el API Gateway al recibir un mensaje de error cuando se comunica con  Orden, guarda la información en la cola. Dicha información será leída de la cola de mensaje cuando el microservicio Orden esté disponible nuevamente, y de esta manera pueda continuar con el flujo del proceso.

El mismo mecanismo de cola de mensaje se utiliza entre el microservicio de Notificación y el de Usuario:  cuando el microservicio de Notificación hace el llamado asíncrono a un método del microservicio de Usuario  , y por algún error o falla el microservicio de Usuario no está disponible, el microservicio Notificación publicará un mensaje en la cola de mensajes. Cuando el microservicio Usuario esté disponible, automáticamente leerá la cola de mensaje para resolver las llamadas a funciones que estén en la cola.

Referencias

1. Coulouris, George F. Distributed Systems: Concepts and Design. Boston: Addison-Wesley, 2012.
2. Tanenbaum, Andrew S., and Maarten van Steen. Distributed Systems: Principles and Paradigms. Upper Saddle River, NJ: Pearson Prentice Hall, 2007. 
3. Rodrigues, Luís and Veríssimo, Paulo. Advances in Distributed Computing and Middleware. 
4. Salas, A., Marquez, A. Arquitectura orientada a Microservicios aplicada a un sistema de Comercio Electrónico. Trabajo de Grado de Pregrado, UNEG. 2017.
5. Protocolo AMQP
6. Microservicios y Colas de Mensajes
7. Cola de Mensajes

Memoria Compartida Distribuida

La memoria compartida distribuida (DSM) [1] es una abstracción utilizada para compartir datos entre computadoras que no comparten memoria física. Los procesos acceden a DSM mediante lecturas y actualizaciones de lo que parece ser la memoria ordinaria dentro de su espacio de direcciones. Sin embargo, un sistema de tiempo de ejecución subyacente garantiza de manera transparente que los procesos que se ejecutan en diferentes computadoras observen las actualizaciones realizadas entre sí. Es como si los procesos accedieran a una única memoria compartida, pero en realidad la memoria física está distribuida.

 La memoria compartida distribuida (DSM) es un paradigma intuitivo [3] que emula el entorno de ejecución de un multiprocesador de memoria compartida en un sistema distribuido. El modelo es intuitivo en el sentido de que los paradigmas que son válidos para la programación concurrente en sistemas de memoria compartida siguen siendo válidos en sistemas distribuidos.  Un área de aplicación donde los paradigmas de memoria compartida distribuida son útiles es el área de computación de alto rendimiento. 

Arquitecturas DSM

El comportamiento más intuitivo para la memoria es el de un sistema centralizado donde todas las operaciones son atómicas. Este modelo se denomina consistencia atómica o linealizabilidad: todas las operaciones de escritura están totalmente ordenadas (obedeciendo el orden en tiempo real de las operaciones) y las operaciones de lectura siempre devuelven el último valor escrito en la memoria. Estos modelos de consistencia de memoria  se etiquetan como modelos de consistencia fuerte. 

La implementación más simple de DSM, se ilustra en la figura 1. En esta arquitectura, un servidor central mantiene las páginas de memoria y los accesos a los datos, por parte de los clientes, se realizan a través de una invocación remota al servidor. El servidor serializa todas las solicitudes, asegurando así el orden total en los mensajes que son  necesario para mantener una consistencia fuerte. El sistema se comporta como si se dispusiera de una única memoria central.

En la arquitectura anterior, si todos los accesos a la memoria tuvieran que ser remotos el rendimiento sería bajo. 

Arquitectura Centralizada. Adaptada de [3]

Afortunadamente, los programas presentan cierto grado de localidad en los accesos a datos. Localidad significa que si se lee o escribe una posición de memoria determinada, es probable que también se acceda a otras posiciones de memoria adyacentes. En lugar de forzar la ejecución remota de todos los accesos, simplemente se puede migrar una parte de la memoria (por ejemplo, una página) del servidor al cliente, como se ilustra en la figura 2. El cliente puede realizar accesos locales posteriores a esa misma página. Si otro cliente quiere acceder a la misma página, la página se vuelve a migrar. Dado que una página determinada se encuentra en una única ubicación en un momento determinado, también se garantiza la coherencia.

Migraciones. Adaptada de [3]

La arquitectura anterior funciona mucho mejor que una centralizada ya que permite que la mayoría de los accesos se ejecuten localmente, en la máquina del cliente. Sin embargo, no permite que dos clientes accedan a la misma página al mismo tiempo. Siempre se debe migrar la página antes de que otro sitio pueda acceder a ella. 

Dado que las lecturas suelen ser mucho más comunes que las escrituras, y dado que muchas aplicaciones se basan en estructuras compartidas que pueden ser leídas en paralelo por hilos  diferentes, es aconsejable permitir varias copias idénticas del mismo página para ser replicada en el sistema.  La variante ilustrada en la figura 3 tiene réplicas de solo lectura que se leen simultáneamente. Cada vez que un cliente solicita, se crea una nueva réplica. Las solicitudes de escritura son coordinadas por el servidor. Naturalmente, si existen varias réplicas de una misma página, hay que garantizar que se comporten como una sola página. Se pueden usar dos enfoques para garantizar que las réplicas se mantengan con contenidos similares en una escritura: uno es propagar la actualización a todas las réplicas; la otra es invalidar las copias obsoletas y mantener actualizada una única copia.

Replicación con solo lectura. Adaptada de [3]

 La figura 4 muestra el enfoque de replicación completa, donde las réplicas de páginas de lectura y escritura se pueden mantener en varios clientes. Los clientes pueden realizar solicitudes de acceso, que son coordinadas por un secuenciador. La intercalación de operaciones y comandos locales del secuenciador depende de la semántica de coherencia del DSM. La función de secuenciador se puede distribuir, por ejemplo, realizada por un protocolo descentralizado ejecutado por todos los clientes interesados.

Replicación Lectura-Escritura. Adaptada de [3]

Referencias

1. Coulouris, George F. Distributed Systems: Concepts and Design. Boston: Addison-Wesley, 2012.
2. Tanenbaum, Andrew S., and Maarten van Steen. Distributed Systems: Principles and Paradigms. Upper Saddle River, NJ: Pearson Prentice Hall, 2007. 
3. Rodrigues, Luís and Veríssimo, Paulo. Advances in Distributed Computing and Middleware.