¿Qué es la arquitectura orientada a servicios (SOA)?

La SOA elimina las tareas del desarrollador de aplicaciones que antes rediseñaba o duplicaba funciones existentes, o que tenía que saber cómo conectar o proporcionar interoperabilidad con funciones existentes.

Cada servicio de una SOA incorpora el código y los datos necesarios para ejecutar una función empresarial completa y discreta (por ejemplo, comprobar la solvencia de un cliente, calcular la cuota mensual de un préstamo o tramitar una solicitud de hipoteca.). Las interfaces de servicio proporcionan un acoplamiento flexible. Esto significa que se pueden invocar con poco o ningún conocimiento sobre la implementación del servicio en segundo plano, lo que reduce las dependencias entre aplicaciones.

Esta interfaz es un contrato de servicio entre el proveedor de servicios y el consumidor de servicios. Las aplicaciones que hay detrás de la interfaz de servicio pueden estar escritas en Java, Microsoft .Net, Cobol o cualquier otro lenguaje de programación. Dichas aplicaciones pueden suministrarse como software empaquetado por un proveedor (por ejemplo, SAP), como aplicaciones SaaS (por ejemplo, Salesforce CRM) o como aplicaciones de código abierto.

Las interfaces de servicio se definen con frecuencia mediante el lenguaje de definición de servicios web (WSDL), que es una estructura de etiquetas estándar basada en xml (lenguaje de marcado extensible).

Los servicios se exponen mediante el uso de protocolos de red estándar, como el protocolo simple de acceso a objetos (SOAP)/HTTP o Restful HTTP (JSON/HTTP), para enviar solicitudes de lectura o modificación de datos. El gobierno del servicio controla el ciclo de vida del desarrollo y, en la etapa adecuada, los servicios se publican en un registro que permite a los desarrolladores encontrarlos rápidamente y reutilizarlos para ensamblar nuevas aplicaciones o procesos de negocio.

Estos servicios se pueden crear desde cero, pero a menudo se crean exponiendo funciones de sistemas heredados como interfaces de servicio.

De este modo, la SOA representa una etapa importante en la evolución del desarrollo y la integración de aplicaciones en las últimas décadas. Antes de que surgiera la SOA a finales de la década de 1990, conectar una aplicación a datos o funciones alojados en otro sistema requería una integración punto a punto compleja, integración que los desarrolladores tenían que recrear, en parte o en su totalidad, para cada nuevo proyecto de desarrollo. Exponer esas funciones a través de servicios SOA permitió al desarrollador reutilizar fácilmente la capacidad existente y conectarse a través de la arquitectura SOA ESB (véase más abajo).

Aunque la SOA y la arquitectura de microservicios más reciente comparten muchos términos (es decir, "servicio" y "arquitectura"), solo están vagamente relacionadas y, de hecho, operan en ámbitos diferentes, como se explica más adelante en este artículo.

Un ESB, o bus de servicio empresarial, es un patrón arquitectónico mediante el cual un componente de software centralizado realiza integraciones entre aplicaciones. Realiza transformaciones de modelos de datos, gestiona la conectividad y la mensajería, realiza enrutamiento, convierte protocolos de comunicación y gestiona potencialmente la composición de múltiples solicitudes.

El ESB puede hacer que estas integraciones y transformaciones estén disponibles como interfaz de servicio para su reutilización por aplicaciones nuevas. El patrón ESB suele implementarse mediante un tiempo de ejecución de integración y un conjunto de herramientas especialmente diseñados que ayudan a garantizar la mejor productividad posible.

Es posible implementar una SOA sin un ESB, pero en ese caso se trataría simplemente de un conjunto de servicios. Cada propietario de aplicación tendría que conectarse directamente a cualquier servicio que necesite y realizar las transformaciones de datos necesarias para cumplir cada una de las interfaces de servicio.

Esto supone mucho trabajo (incluso si las interfaces son reutilizables) y crea un importante reto de mantenimiento en el futuro, ya que cada conexión es punto a punto. De hecho, los ESB se consideraron, finalmente, un elemento tan de facto de cualquier implementación SOA que los dos términos a veces se utilizan como sinónimos, creando confusión.

En comparación con las arquitecturas que la precedieron, la SOA ofreció beneficios significativos a la empresa:

• Mayor agilidad empresarial, tiempo de comercialización más rápido: la reutilización es clave. La eficiencia de ensamblar aplicaciones a partir de servicios reutilizables (es decir, bloques de construcción) en lugar de reescribir y reintegrar con cada nuevo proyecto de desarrollo permite a los desarrolladores crear aplicaciones mucho más rápidamente y responder así a nuevas oportunidades de negocio.
  El método arquitectónico orientado a servicios es compatible con escenarios de integración de aplicaciones, integración de datos y automatización de procesos empresariales o flujos de trabajo al estilo de la orquestación de servicios. Esto acelera el diseño y el desarrollo de software al permitir a los desarrolladores dedicar mucho menos tiempo a la integración y más tiempo a centrarse en entregar y mejorar sus aplicaciones.
• Capacidad para utilizar funciones heredadas en nuevos mercados: una SOA bien diseñada permite a los desarrolladores tomar fácilmente funciones "bloqueadas" en una plataforma o entorno informático y extenderlas a nuevos entornos y mercados. Por ejemplo, muchas empresas han utilizado la SOA para exponer funciones de sistemas financieros basados en mainframe a nuevas aplicaciones web. Esto permite a sus clientes acceder a procesos e información a los que antes solo se podía acceder a través de la interacción directa con los empleados o business partners de la empresa.
• Mejora de la colaboración entre la empresa y la TI: en una SOA, los servicios se pueden definir en términos empresariales (por ejemplo, "generar cotización de seguro" o "calcular el ROI en bienes de equipo"). Esto permite a los analistas empresariales trabajar de forma más eficaz con los desarrolladores en conocimientos importantes, como el alcance de un proceso empresarial definido mediante el uso de servicios o las implicaciones empresariales de cambiar un proceso, que puede conducir a mejores resultados.

En 2010, las implementaciones de SOA iban a toda máquina en las principales empresas de prácticamente todos los sectores. Por ejemplo:

Delaware Electric recurrió a la SOA para integrar sistemas que antes no se comunicaban entre sí, lo que se tradujo en eficiencias de desarrollo que ayudaron a la organización a mantenerse solvente durante una congelación de las tarifas eléctricas de cinco años exigida por el estado.

Cisco adoptó la SOA para asegurarse de que su experiencia de pedido de productos fuera coherente en todos los productos y canales al exponer los procesos de pedido como servicios que las divisiones, adquisiciones y business partners de Cisco podrían incorporar a sus sitios web.

Independence Blue Cross (IBC) de Filadelfia implementó una arquitectura orientada a servicios (SOA) para garantizar que los diferentes componentes que gestionaban datos de pacientes (agentes de atención al cliente de IBC, consultas médicas y usuarios del sitio web de IBC) utilizaran la misma fuente de datos (una "única fuente fiable").

Los expertos han escrito miles de páginas impresas y digitales comparando SOA y microservicios, y analizando en profundidad su relación. A los efectos de este artículo, las principales diferencias entre ambos son el acoplamiento de los componentes y el ámbito de uso:

la SOA es un estilo arquitectónico de integración y un concepto para toda la empresa. Permite exponer las aplicaciones existentes a través de interfaces débilmente acopladas, cada una de las cuales corresponde a una función empresarial que permite a las aplicaciones de una parte de una empresa ampliada reutilizar funciones en otras aplicaciones.

La arquitectura de microservicios es un estilo arquitectónico de aplicación y un concepto de ámbito de aplicación. Permite dividir el interior de una única aplicación en pequeñas piezas que se pueden cambiar, escalar y administrar de forma independiente. No define cómo se comunican las aplicaciones entre sí, por lo que volvemos al ámbito empresarial de las interfaces de servicio proporcionadas por la SOA.

La arquitectura de microservicios surgió y ganó fuerza con el auge de la virtualización, el cloud computing, las prácticas de desarrollo ágil y DevOps. La mayoría de las ventajas de los microservicios en estos contextos surgen del desacoplamiento de los componentes, lo que simplifica y mejora lo siguiente:

• Agilidad y productividad de los desarrolladores: los microservicios permiten a los desarrolladores incorporar nuevas tecnologías a una parte de la aplicación sin afectar al resto. Cualquier componente puede modificarse, probarse e implementarse independientemente de los demás, lo que acelera los ciclos de iteración.
• Escalabilidad: los microservicios pueden aprovechar al máximo la escalabilidad de la nube, ya que cualquier componente se puede escalar de forma independiente para ofrecer la respuesta más rápida posible a las demandas de carga de trabajo y hacer un uso más eficiente de los recursos informáticos.
• Resiliencia: de nuevo, gracias al desacoplamiento, el fallo de un microservicio no afecta a los demás. Y cada microservicio puede funcionar según sus propios requisitos de disponibilidad sin poner en juego los otros componentes o toda la aplicación a los mayores requisitos de disponibilidad comunes.

Para profundizar en las diferencias entre SOA y microservicios, consulte SOA frente a microservicios: ¿cuál es la diferencia?

Del mismo modo que la arquitectura de microservicios tiene el potencial de aportar mejoras en agilidad, escalabilidad y resiliencia al diseño de aplicación, estas mismas técnicas también pueden aplicarse a la integración.

Esto es importante porque, con el tiempo, el patrón ESB altamente centralizado y su equipo centralizado de especialistas en integración pueden convertirse en un cuello de botella. Si adoptamos los principios de los microservicios, podemos dividir el ESB en una integración más detallada y descentralizada. Esta es una de las premisas fundamentales de la integración ágil.