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.