SOA (arquitectura orientada a servicios)

menu icon

SOA (arquitectura orientada a servicios)

Explore SOA (arquitectura orientada a servicios), una etapa importante en la evolución del desarrollo y la integración de aplicaciones.

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

SOA, o arquitectura orientada a servicios, define una manera de conseguir que los componentes de software sean reutilizables a través de interfaces de servicio. Estas interfaces utilizan estándares de comunicación comunes de tal manera que puedan incorporarse rápidamente a nuevas aplicaciones sin tener que realizar una integración profunda cada vez.

Cada servicio en una SOA incorpora el código y las integraciones de datos necesarias para ejecutar una función de negocio 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 un acoplamiento débil, lo que significa que se pueden llamar sin apenas conocimientos, o incluso ningún conocimiento, de cómo se implementa la integración por debajo. Los servicios se exponen utilizando protocolos de red estándar, como SOAP (protocolo de acceso a objetos simple)/HTTP o JSON/HTTP, para enviar solicitudes para leer o cambiar datos. Los servicios se publican de una forma que permite a los desarrolladores encontrarlos rápidamente y reutilizarlos para ensamblar nuevas aplicaciones.

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

De este modo, 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 SOA a finales de la década de 1990, conectar una aplicación a datos o funcionalidad alojada en otro sistema requería una integración de 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. La exposición de estas funciones a través de SOA elimina la necesidad de recrear la integración profunda cada vez.

Tenga en cuenta que aunque SOA y la arquitectura de microservicios más reciente comparten muchas palabras en común, no guardan mucha relación y, de hecho, operan en diferentes ámbitos, como se describe más adelante en este artículo.

¿Qué es un ESB?

Un ESB, o bus de servicio empresarial, es un patrón por el que un componente centralizado realiza la integración a los sistemas de fondo y, a continuación, permite que dichas integraciones estén disponibles como interfaces de servicio. Realiza la traducción de modelos de datos, la conectividad profunda, el direccionamiento y potencialmente la composición de varias solicitudes, y los hace disponibles como una única interfaz de servicio para que nuevas aplicaciones puedan reutilizarlos. El patrón ESB normalmente se implementa utilizando un tiempo de ejecución de integración especialmente diseñado y herramientas que se adaptan bien a las funcionalidades anteriores, lo que garantiza la mejor productividad posible.

En teoría, podría implementar una SOA sin un ESB, pero los propietarios de aplicaciones tendrían que encontrar su propia forma exclusiva de exponer las interfaces de servicio, lo que supone mucho trabajo (incluso si las interfaces son finalmente reutilizables) y plantea un importante reto de mantenimiento en el futuro. De hecho, los ESB eran considerados como un elemento de facto de cualquier implementación de SOA, por lo que los dos términos se utilizan a veces como sinónimos, generando confusión.

Obtenga más información sobre los ESB leyendo el artículo "Introduction to ESB (Enterprise Service Bus)".

Ventajas de SOA

En comparación con las arquitecturas que le precedieron, SOA ofrece importantes ventajas a la empresa:

  • Mayor agilidad del negocio; comercialización más rápida: la eficiencia de ensamblar aplicaciones desde interfaces de servicio reutilizables, en lugar de reescribir y reintegrar con cada nuevo proyecto de desarrollo, permite a los desarrolladores crear aplicaciones mucho más rápidamente en respuesta a nuevas oportunidades de negocio.
  • Capacidad de aprovechar la funcionalidad existente en nuevos mercados: una SOA bien diseñada permite a los desarrolladores aprovechar fácilmente funcionalidad "bloqueada" en un entorno o plataforma informática y ampliarla a nuevos entornos y mercados. Por ejemplo, muchas empresas han utilizado SOA para exponer la funcionalidad de los sistemas financieros basados en mainframe a la web, lo que permite a sus clientes acceder ellos mismos a procesos e información previamente accesibles únicamente a través de la interacción directa con los empleados o los business partners de la empresa.
  • Mejora de la colaboración entre negocio y TI: en una SOA, los servicios se pueden definir en términos de negocio (por ejemplo, "generar cotización de seguros" o "calcular el ROI de equipo de capital"). Esto permite a los analistas de negocio trabajar de forma más efectiva con los desarrolladores en aspectos importantes, como el ámbito de un proceso de negocio definido por un servicio o las implicaciones empresariales de cambiar un proceso, lo que puede llevar a mejores resultados.

Ejemplos de SOA

En 2010, las implementaciones de SOA estaban en plena expansión entre las empresas líderes en prácticamente todas los sectores. Por ejemplo:

  • Delaware Electric recurrió a SOA para integrar sistemas que antes no se comunicaban entre sí, lo que incrementó la eficiencia de desarrollo y ayudó a la organización a mantenerse solvente durante un congelamiento de cinco años de las tarifas eléctricas impuesto por el estado.
  • Cisco adoptó SOA para asegurarse de que su experiencia en la realización de pedidos de productos fuera coherente en todos los productos y canales exponiendo los procesos de pedidos como servicios que las divisiones, adquisiciones y socios comerciales de Cisco pudieran incorporar a sus sitios web.
  • Independence Blue Cross (IBC) de Filadelfia implementó una SOA para asegurarse de que los diferentes integrantes que se ocupan de los datos de los pacientes (agentes del servicio al cliente de IBC, las consultas de los médicos y los usuarios del sitio web de IBC) estuvieran trabajando con la misma fuente de datos (una "versión única de la verdad").

SOA frente a microservicios

Los expertos han escrito miles de páginas impresas y digitales comparando SOA y microservicios y definiendo las sutilezas de su relación entre sí. A efectos del presente artículo, las principales diferencias entre ambos son el acoplamiento de componentes y el ámbito de aplicación:

  • SOA es un concepto de toda la empresa. Permite que las aplicaciones existentes se expongan sobre interfaces sin conexión directa, cada una de las cuales corresponde a una función de negocio, que permite a las aplicaciones en una parte de una empresa ampliada reutilizar la funcionalidad en otras aplicaciones.
  • La arquitectura de microservicios es un concepto con ámbito de aplicación. Permite descomponer los elementos internos de una sola aplicación en piezas pequeñas que se pueden cambiar, escalar y administrar de forma independiente. No define cómo las aplicaciones se comunican entre sí, para ello volvemos al ámbito empresarial de las interfaces de servicio proporcionadas por SOA.

La arquitectura de microservicios surgió y ganó fuerza con el auge de la virtualización, cloud computing, las prácticas de desarrollo Agile y DevOps. La mayoría de las ventajas de los microservicios en estos contextos surgen del desacoplamiento completo 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 recuperar el resto de la aplicación. Cualquier componente se puede modificar, probar y desplegar independientemente de los demás, lo que acelera los ciclos de iteración.
  • Escalabilidad: los microservicios pueden aprovechar al máximo la escalabilidad del cloud: cualquier componente se puede escalar independientemente de los demás para obtener la respuesta más rápida posible a las demandas de carga de trabajo y el 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 cumplir sus propios requisitos de disponibilidad sin dejar de lado a los demás componentes o toda la aplicación para requisitos de disponibilidad más amplios.

Para profundizar en las diferencias entre SOA y los microservicios, consulte el artículo "SOA vs. Microservices: What's the difference?"

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 centralizado y asociado de especialistas en integración pueden provocar un cuello de botella. Teniendo en cuenta los principios de microservicios, podemos dividir potencialmente el ESB en una integración más precisa y descentralizada. Esta es una de las premisas principales detrás de la integración ágil.

SOA e IBM Cloud

A medida que su empresa cambia su infraestructura de TI hacia un enfoque de cloud híbrido, mayor es la probabilidad de que esté transformando una variedad de cargas de trabajo, incluidas las basadas en SOA, en modelos de despliegue de cloud más ligeros y flexibles. IBM es uno de los pioneros de SOA, y las ofertas y servicios de IBM Cloud pueden aprovechar y ampliar sus inversiones de SOA existentes al cloud.

Dé el siguiente paso:

SOA proporciona la capacidad de hacer que los servicios sean consumibles en distintos canales, independientemente de dónde resida la aplicación principal o la base de datos, lo que ayuda a su organización a sacar el máximo partido de sus inversiones para modernizar las aplicaciones en la transición al cloud.

Empiece hoy mismo con una cuenta de IBM Cloud.