SOA, o arquitectura orientada a servicios, define una manera de hacer que los componentes de software sean reutilizables a través de interfaces de servicio. Los servicios utilizan estándares de interfaz comunes y un patrón arquitectónico para que puedan incorporarse rápidamente a aplicaciones nuevas. De este modo, se evitan determinadas tareas al desarrollador de aplicaciones, que antes debía volver a desarrollar o duplicar la funcionalidad existente o tenía que saber cómo conectar o proporcionar interoperatividad con las funciones existentes.
Cada servicio de una SOA incorpora el código y las integraciones de datos necesarias para ejecutar una función de negocios completa y discreta (por ejemplo, comprobar el crédito de un cliente, calcular un pago de préstamo mensual o procesar una solicitud de hipoteca). Las interfaces de servicio proporcionan acoplamiento suelto, lo que significa que se pueden invocar con poco o ningún conocimiento de cómo el servicio se implementa de manera subyacente, reduciendo las dependencias entre aplicaciones.
Esta interfaz es un contrato de servicios entre el proveedor de servicios y el consumidor de servicios. Las aplicaciones detrás de la interfaz de servicios se pueden escribir en Java, Microsoft .Net, Cobol o en cualquier otro lenguaje de programación, suministrado como aplicaciones de software empaquetadas por un proveedor (por ejemplo, SAP), aplicaciones SaaS (por ejemplo, Salesforce CRM) u obtenidas como aplicaciones de código abierto. Las interfaces de servicio se definen con frecuencia utilizando un Lenguaje de Descripción de Servicios Web (WSDL), que es una estructura de etiqueta estándar basada en xml (lenguaje de marcado extensible).
Los servicios se exponen utilizando protocolos de red estándar, como SOAP (protocolo simple de acceso a objetos)/HTTP o Restful HTTP (JSON/HTTP), para enviar solicitudes para leer o cambiar datos. La gestión del servicio controla el ciclo de vida para el desarrollo y, en la etapa que corresponde, 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 desarrollar desde cero, pero es común que se creen exponiendo funciones de sistemas heredados de registro como interfaces de servicio.
De este modo, en las últimas décadas, la SOA representa una etapa importante en la evolución del desarrollo de aplicaciones y la integración. Antes de que surgiese la SOA a fines de la década de 1990, la conexión de una aplicación a datos o funcionalidad alojada en otro sistema requería una compleja integración punto a punto, 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 de SOA permitía al desarrollador simplemente reutilizar la capacidad existente y conectarse a través de la arquitectura SOA ESB (consulte a continuación).
Tenga en cuenta que aunque la SOA y la arquitectura de microservicios más reciente comparten muchas palabras en común (es decir, "servicio" y "arquitectura"), solo están relacionadas de manera vaga y, de hecho, operan en diferentes ámbitos, como se explica más adelante en este artículo.
Un ESB, o bus de servicios empresariales, es un patrón arquitectónico mediante el cual un componente de software realiza integraciones entre aplicaciones. Realiza transformaciones de modelos de datos, se encarga de la conectividad/mensajería, realiza enrutamiento, convierte protocolos de comunicacion y potencialmente gestiona la composición de múltiples solicitudes. Los ESB pueden encargarse de estas integraciones y transformaciones disponibles como interfaces de servicio para su reutilización por nuevas aplicaciones. El patrón ESB generalmente se implementa en un entorno de ejecución de integración especialmente diseñado y un conjunto de herramientas que garantizan la mejor productividad posible.
Es posible implementar una SOA sin un ESB, pero esto equivaldría a tener un montón de servicios. Cada propietario de la aplicación debería conectarse directamente a cualquier servicio que necesite y realizar las transformaciones de datos necesarias para cumplir con cada una de las interfaces de servicio. Esto es mucho trabajo (incluso si las interfaces son reutilizables) y crea importantes desafíos de mantenimiento en el futuro, ya que cada conexión es punto a punto. De hecho, con el tiempo, los ESB llegaron a ser considerados un elemento tan propio de cualquier implementación de SOA que los dos términos se utilizan a veces como sinónimos, lo que genera confusión.
En comparación con las arquitecturas que le precedieron, SOA ofrece importantes ventajas a la empresa:
En 2010, las implementaciones de SOA estaban en plena expansión entre las empresas líderes en prácticamente todas las industrias. Por ejemplo:
Los expertos han escrito miles de páginas de literatura impresa y digital comparando SOA y microservicios y definiendo las sutilezas de la relación entre estos dos conceptos. A efectos del presente artículo, las principales diferencias entre ambos son el acoplamiento de componentes y el ámbito de uso:
La arquitectura de microservicios surgió y cobró fuerza con el auge de la virtualización, la computación en la nube, las prácticas de desarrollo de Agile 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 los siguientes aspectos:
Para profundizar en las diferencias entre SOA y los microservicios, consulte "SOA frente a microservicios: ¿cuál es la diferencia?"
De la misma manera que la arquitectura de microservicios tiene el potencial de aportar mejoras en agilidad, escalabilidad y resiliencia al diseño de aplicaciones, estas mismas técnicas también se pueden aplicar a la integración. Esto es importante porque, con el tiempo, el patrón de ESB fuertemente centralizado y su equipo de especialistas en integración centralizado y asociado pueden provocar un cuello de botella. Tomando en cuenta los principios de microservicios, podemos potencialmente dividir el ESB en una integración más precisa y descentralizada. Esta es una de las premisas fundamentales detrás de integración ágil.
Conecte aplicaciones, servicios y datos con IBM Cloud Pak for Integration, la plataforma de integración más completa del mercado.
Conecte aplicaciones y datos con un potente software de integración de aplicaciones automatizado por IA.
IBM® API Connect es una solución de gestión de API segura que utiliza una experiencia intuitiva para ayudar a crear, gestionar, proteger, socializar y monetizar las API de forma consistente.
Conozca los conceptos básicos de la arquitectura orientada a servicios (SOA) y los microservicios, sus diferencias principales y qué enfoque sería el mejor para su situación.
Esta guía describe cómo acelerar la modernización de aplicaciones, incrementar la productividad de los desarrolladores y mejorar la eficiencia operativa y la estandarización.
Conozca más acerca de ESB (un componente esencial de SOA), los beneficios que ofrece y cómo se relaciona con la arquitectura de microservicios.