4.4 Arquitecturas Orientadas a Servicios



La arquitectura orientada a servicios (SOA) es un concepto de arquitectura de software que describe el uso de servicios para proporcionar soluciones a requerimientos de negocio.

Se define SOA como un paradigma para la organización y la utilización de capacidades distribuidas que puede estar ofrecido sobre diferentes dominios. Proporciona una manera normalizada de descubrir, ofrecer e interactuar con un servicio para obtener los efectos deseados y definidos por sus precondiciones y poscondiciones.

SOA crea una arquitectura flexible y habilita la implementación de complejas arquitecturas que reflejen la organización. Además, proporciona un mapa bien definido para la invocación de servicios que habilita la interacción entre diferentes sistemas (por ejemplo, sistemas propietarios) y servicios externos (third party services).


¿Cómo funciona la Arquitectura Orientada a Servicios?

Antes de que se empezara a utilizar la arquitectura SOA a fines de los noventa, era muy difícil conectar una aplicación con los servicios alojados en otro sistema, y se necesitaba una integración profunda de punto a punto (conectividad, enrutamiento, traducción de los modelos de datos, etc.). Luego, los desarrolladores debían repetir el proceso para cada proyecto nuevo. Este modelo se conocía como "monolítico", ya que el código para toda la aplicación formaba parte de una sola implementación. Si algo no funcionaba correctamente, había que darla de baja por completo hasta que se solucionaran los problemas, para luego volverla a implementar como una versión nueva.

Dado que la arquitectura SOA expone los servicios utilizando protocolos estándar de red para enviar solicitudes o acceder a los datos (por ejemplo; SOAP, JSON, ActiveMQ o Apache Thrift), no es necesario que los desarrolladores realicen las integraciones desde cero. De hecho, pueden utilizar los patrones llamados buses de servicios empresariales (ESB) para integrar un elemento centralizado y los sistemas de backend, y ponerlos a disposición de todos como interfaces de servicios.

En la arquitectura SOA, los servicios se comunican por medio de un sistema sin conexión directa. Se trata de un método para interconectar los elementos en un sistema o una red, de manera que puedan transmitir información o coordinar un proceso sin depender tanto unos de otros. Como consecuencia, se crea una nueva aplicación.


Ventajas de la Arquitectura Orientada a Servicios

  • Comercialización más rápida y mayor flexibilidad: La posibilidad de reutilizar los servicios que ofrece la arquitectura SOA agiliza y simplifica el proceso de ensamblaje de las aplicaciones. Los desarrolladores no se ven obligados a empezar siempre desde cero, como es el caso con las aplicaciones monolíticas.
  • Uso de la infraestructura heredada en los mercados nuevos: La arquitectura SOA permite que los desarrolladores tomen las funciones de una plataforma o un entorno y las amplíen e implementen en otros.
  • Reducción de los costos gracias a una mayor agilidad y un desarrollo más eficiente.
  • Mantenimiento sencillo: Dado que todos los servicios son autónomos e independientes, se puede modificar y actualizar cada uno cuando sea necesario, sin afectar al resto.
  • Escalabilidad: La arquitectura SOA posibilita la ejecución de los servicios en varios lenguajes de programación, servicios y plataformas, lo cual aumenta la escalabilidad de forma considerable. Además, utiliza un protocolo de comunicación estandarizado para que las empresas puedan disminuir la interacción entre los clientes y los servicios, lo cual permite ampliar las aplicaciones con menos presiones e inconvenientes.
  • Mayor confiabilidad: La arquitectura SOA genera aplicaciones más confiables, ya que es más fácil depurar servicios pequeños que un código de gran volumen.
  • Gran disponibilidad: Las instalaciones de la arquitectura SOA están disponibles para todos.

Principios de la Arquitectura Orientada a Servicios

Después de conocer algunas de las ventajas que proporciona SOA debemos entender o por lo menos tener un conocimiento básico en cuáles serían los principios en lo que está basado este marco de diseño:

  • Contratos estandarizados: Esto apunta a que todos los servicios cumplan con un estándar de diseño y estén en un mismo inventario de servicios.
  • Bajo acoplamiento: lo que permite que puedan ser reusables por diferentes consumidores.
  • Abstracción: Sólo contienen la información esencial, sin necesidad de detallar lo que publica el contrato.
  • Reutilización: corresponde a todos los servicios con lógica agnóstica, donde puede ser fácilmente reutilizada en diferentes contextos (Proyectos).
  • Autonomía: Ejerce un autocontrol sobre el entorno subyacente (Sin dependencias).
  • Ausencia de estado: Permite saber si el estado de la información de un servicio esta activa o pasiva.
  • Descubribilidad: Es toda la metadata que permite que un servicio pueda ser descubierto e interpretado.
  • Composición: Permite formar una lógica más compleja a partir de varios servicios.

Implementación de Servicios basados en la Arquitectura Orientada a Servicios

Cuando describimos la arquitectura orientada a servicios, por lo general nos referimos a un conjunto de servicios que se despliegan sobre Internet o intranet utilizando servicios web. Existen diferentes estándares asociados a los servicios web como XML, HTTP, SOAP, WSDL, UDDI o REST, XML y JSON, aunque SOA no se limita solo a estas especificaciones. Se puede diseñar un sistema que siga un paradigma orientado a servicios y aplicar un perfil tecnológico diferente del habitual uso de estándares.

En un entorno SOA, los nodos de una red publican sus recursos disponibles a otros participantes como servicios independientes que son accesibles de una manera estandarizada. Muchas definiciones de SOA identifican SOA con el uso de servicios web basados en SOAP (WS - *) y WSDL en su implementación, pero es posible implementar SOA usando cualquier tecnología basada en servicios.

Hay varios estilos para implementar servicios, las dos familias de servicios web mas usuales son: los servicios web basados en SOAP y WSDL (WS - *) y los servicios web basados en recursos (RESTful web services).


Ejemplo de la Arquitectura Orientada a Servicios

Un ejemplo de aplicación orientada a servicios podría ser una aplicación B2B de una gran empresa de la automoción (fabricante de vehículos) que ofrece sus productos con la información y las posibilidades de personalización de cada uno. 

Por otro lado, un concesionario multimarca, que puede vender vehículos de diferentes fabricantes o marcas, puede disponer de una aplicación web que muestre a sus clientes (B2C), con la identidad corporativa del concesionario, la información de los vehículos (de las diferentes marcas) con las opciones de personalización. La aplicación del concesionario accederá a los servicios que ofrece la aplicación B2B del fabricante (u otros fabricantes) para obtener la información de los vehículos, que posteriormente será presentada a los usuarios con el valor añadido que ofrecen los concesionarios.


Servicios Web basados en SOAP (WS - *)


Un servicio web basado en SOAP es un sistema de software identificado por una URI, cuyas interfaces públicas y enlaces se definen y describen usando XML. La definición puede ser descubierta por otros sistemas software, y estos sistemas suelen interactuar con el servicio web de la manera prescrita por la definición, usando mensajes basados en XML por medio de protocolos estándar de Internet. En definitiva, un servicio web expone su funcionalidad a posibles consumidores en una URI y proporciona mecanismos para invocar sus operaciones de manera remota (a través de Internet). El servicio web se puede implementar en cualquier lenguaje y en cualquier plataforma. Los servicios web utilizan una serie de especificaciones como SOAP, WSDL y UDDI, que se describirán a continuación. 

SOAP es un protocolo que permite la interacción con servicios web basado en XML. La especificación de SOAP incluye una sintaxis para definir los mensajes, reglas de codificación y convenciones para representar los RPC.

Las especificaciones de servicios se pueden hacer utilizando WSDL.

WSDL describe dónde se localiza un servicio, qué operaciones proporciona, el formato de los mensajes que deben ser intercambiados y cómo se invoca el servicio, además de proporcionar información adicional. 

La proliferación de los servicios web hace necesaria la existencia de directorios públicos que se pueden utilizar para el registro y la busca de servicios.

UDDI proporciona un mecanismo para que los proveedores de servicios puedan especificar sus servicios de una manera normalizada, y los clientes puedan consultar información de dichos servicios.

Las entradas de los UDDI consisten en páginas blancas (dirección, información de contacto, etc.), páginas amarillas (características basadas en ontologías estándares) o páginas verdes (referencias a especificaciones de servicios).

Los servicios web WS - * utilizan SOAP para codificar los mensajes XML que se transportan. Los mensajes deben ser capaces de interpretarse de manera automatizada, tal como se describen las operaciones en WSDL. No es obligatorio que WSDL esté vinculado a un extremo SOAP, pero sí que es un prerrequisito para automatizar la generación de las clases auxiliares (stubs o skeletons) que se utilizan en diferentes plataformas. Algunas organizaciones (como WS-I y OASIS) incluyen SOAP y WSDL en las definiciones de sus servicios web.


Servicios Web basados en REST



Los servicios web basados en REST (RESTful web services) son servicios diseñados para funcionar de manera más eficiente sobre la Web. REST es un estilo arquitectónico que especifica restricciones, como por ejemplo una interfaz uniforme (basada en identificadores para los recursos), que si se aplica a un servicio web infiere propiedades como el rendimiento o la escalabilidad, que hacen posibles servicios más eficientes, simples y de un alto rendimiento. REST se basa en una arquitectura web denominada arquitectura orientada a recursos (ROA), que se basa en acciones sobre recursos para permitir la interacción entre cliente y servidor, mediante el uso de los métodos get, post, put y delete inherentes de HTTP (y relacionados, como operaciones CRUD) e implementado en navegadores, que no requieren mensajes SOAP/XML o descripciones WDSL. Esto hace que esta estrategia resulte mucho más ligera. 

En REST, los datos y la funcionalidad son considerados como recursos, y a estos recursos se accede mediante identificadores (URI), por medio de un conjunto de operaciones sencillas y bien definidas. El estilo arquitectónico REST se basa en una arquitectura cliente-servidor, y está diseñado para que clientes y servidores intercambien información mediante una interfaz estandarizada, simple y mediante el uso de un protocolo de comunicación sin estado, por lo general, de HTTP.

REST o los servicios web RESTful se están utilizando de manera regular, sobre todo y especialmente, en dispositivos de escasos recursos y en un contexto web 2.0. Un desarrollo basado en servicios web (llamado Web API) también puede realizarse con un estilo de comunicaciones REST. Web API permite la combinación de múltiples servicios web en nuevas aplicaciones llamadas mashups.


Diferencias entre Servicios Web basados en SOAP (WS - *) y Servicios Web basados en REST




Una de las diferencias fundamentales entre las dos estrategias de implementación de servicios web estudiadas (RESTful WS y basados en SOAP) es la filosofía intrínseca de las dos opciones. Buscando una analogía, podemos acordar que las aplicaciones basadas en REST se organizan en recursos (nombres), mientras que las aplicaciones basadas en servicios web (WS - *) se organizan en acciones (verbos). 

La siguiente tabla muestra una comparativa entre las dos estrategias para la construcción de servicios web y presenta las ventajas e inconvenientes sobre cada una.






* Arquitectura Orientada a Servicios






Fuentes Consultadas:

Red Hat. redhat.com. (2021). ¿Qué es la arquitectura orientada a los servicios (SOA)?.

Cubides Claudia Maritza - Jaramillo Liliana - Muriel Londoño Andrea | ACADEMIA Pragma Blog. praga.com.co. (23 de febrero de 2021). Qué es la Arquitectura Orientada al Servicio SOA.

Oller Arcas Antoni | Universidad Abierta de Catalunya. uoc.gitlab.io. (2014). SOA Arquitecturas orientadas a servicios.

CEUPE Magazine. ceupe.com. (2021). ¿Qué es SOA?.

MegaPractical | YouTube. youtube.com. (04 de octubre de 2016). Arquitectura Orientada a Servicios (SOA), BPM y ESB.