Modelos Arquitectónicos. Entidades

 

Los modelo arquitectónicos clasifican su contenido en componentes de la arquitectura: entidades, paradígmas de comunicación, roles y responsabilidades, y correspondencia con la infraestructura física. A continuación se describe los modelos arquitectónicos de los sistemas distribuidos de acuerdo a esa caracterización [1].

1. Entidades

 Las entidades presentes en un sistema distribuidos son: procesos, nodos, hilos, componentes, servicios web.

• Procesos. Conducen a visión predominante de un sistema distribuido como procesos acoplados y paradigmas de comunicación entre procesos. Por ejemplo en la figura 1 se ilustra la organización de una base de datos una red de monitoreo y los procesos que se ejecutan en ella, en el lugar del operador (a), o en los sensores (b).

Figura 1: Organización de una base de datos para una red de monitoreo, mientras se lmacena y procesa información (a) sólo en el lugar del operador, o (b) sólo en los sensores.Tomado de [2]

• Nodos. En algunos entornos primitivos, como las redes de sensores, los sistemas operativos pueden que no admitan abstracciones de proceso y, por lo tanto, las entidades que se comunican en este tipo de sistemas son nI Figura 2 muestra la organización de los nodos en la arquitectura de Chord [3], un protocolo y algoritmo para sistemas P2P con tablas hash distribuidas y que proporciona un servicio de búsqueda descentralizado que almacena pares clave/valor para esas redes.

Figura 2. Mapeo de elementos de datos hacia nodos organizados en Chord. Tomado de [3]

• Hilos. En la mayoría de los entornos de sistemas distribuidos, los procesos se complementan con hilos, que son los puntos finales de la comunicación. En la Figura 3 se presenta los hilos que se establecen en la comunicación del cliente y el servidor con el protocolo solicitud-respuesta.

Figura 3. Hilos en Arquitectura Cliente Servidor

• Objetos. En el enfoque de sistemas distribuido basado en objetos, un cálculo consiste en una serie de objetos interactivos que representan unidades para el dominio del problema dado. Se accede a los objetos a través de interfaces, con un lenguaje de definición de interfaz asociado ( interface definition language, IDL) que proporciona un especificación de los métodos definidos en un objeto. Por ejemplo, en la Figura 4, se muestra la constitución de la arquitectura de Corba, detallando los objetos y sus funciones [4].

Figure 4: Componentes de la arquitectura CORBA

• Componentes. En los componentes de software, cada componente es una unidad de composición con interfaces especificadas contractualmente y dependencias de contexto explícitas únicamente. Esto indica que no hay dependencias implícitas. Los componentes de software son como objetos distribuidos en el sentido de que están encapsulados en unidades de composición, pero un componente dado especifica tanto sus interfaces proporcionadas al mundo exterior y sus dependencias de otros componentes en el entorno distribuido [5]. La Figura 5 muestra la arquitectura de un sistema de archivos simple que proporciona una interfaz a otros usuarios y, a su vez, que requiere conexión a un componente de servicio de directorio y un componente de servicio de archivo plano.

Figure 5: Arquitectura de software basado en componentes. Tomado de [1]

• Servicios Web. Los servicios web están estrechamente relacionado con objetos y componentes, adoptando un enfoque basado en la encapsulación de comportamiento y acceso a través de interfaces. Están integrados en la World Wide Web, utilizando estándares web para representar y descubrir servicios [6].En [7] lo definen como un sistema software diseñado para soportar la interacción máquina-a-máquina, a través de una red, de forma interoperable. Cuenta con una interfaz descrita en un formato procesable por un equipo informático (específicamente en WSDL), a través de la que es posible interactuar con el mismo mediante el intercambio de mensajes SOAP, típicamente transmitidos usando serialización XML sobre HTTP conjuntamente con otros estándares web.

Bibliografia

[1]George Coulouris et al. Distributed Systems: Concepts and Design. 5th. USA: Addison-Wesley Publishing Company, 2011

[2]AndrewTanenbaum and Van Marteen. Distributed Systems: Principles andParadigms. Edited by Pearson Prentice Hall. 2nd. 2007.

[3]Ion Stoica et al. “Chord: A Scalable Peer-to-Peer Lookup Service for Internet Applications”. In: SIGCOMM Comput. Commun. Rev. 31.4 (Aug. 2001), pages 149– 160.

[4]Corba. “Common Object Request Broker Architecture”. In: (Dec. 2022). Documento electrónico

[5]Szyperski C. and Murer S. Component Software: Beyond Object-Oriented Programming. 2nd edition. Addison-Wesley Professional, 2002.

[6]Thomas Erl. Service Oriented Architecture: Principles of Service Design (The Prentice Hall Service-Oriented Computing Series) by Thomas Erl. 1st edition. The Prentice Hall Service-Oriented Computing Series from Thomas Erl. Prentice Hall, 2007.

[7]W3C. “World Wide Web Consortium.” In: (2022). Documento electrónico. URL: http://www.w3.org

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.