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 

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.