SOA (arquitectura orientada a servicios)

menu icon

SOA (arquitectura orientada a servicios)

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

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

La 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. Estas interfaces utilizan estándares de comunicación comunes entre sí, de tal manera que pueden incorporarse rápidamente a nuevas aplicaciones sin tener que realizar una integración profunda cada vez.

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 brindan un acoplamiento suelto, lo que significa que se pueden llamar con poco o ningún conocimiento sobre la forma de implementación de la integración subyacente. Los servicios se exponen utilizando protocolos de red estándar, como SOAP (protocolo simple de acceso a objetos) /HTTP o JSON/HTTP, para enviar solicitudes para leer o cambiar datos. Los servicios se publican de tal forma que permite a los desarrolladores encontrarlos rápidamente y reutilizarlos para ensamblar nuevas aplicaciones.

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, la SOA representa una etapa importante en la evolución del desarrollo de aplicaciones y la integración en las últimas décadas. Antes de que la SOA emergiera a finales de la década de 1990, conectar una aplicación a datos o a una funcionalidad hospedada en otro sistema requería una integración de punto a punto compleja, 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 la SOA elimina la necesidad de recrear la integración profunda cada vez.

Tenga en cuenta que aunque la SOA y la arquitectura de microservicios más reciente comparten muchas palabras en común, solamente están relacionadas de forma flexible 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 backend y, a continuación, hace que dichas integraciones estén disponibles como interfaces de servicio. Realiza la traducción de modelos de datos, conectividad profunda, direccionamiento y potencialmente composición de varias solicitudes, y las pone a disposición como una única interfaz de servicio para su reutilización mediante nuevas aplicaciones. El patrón ESB se implementa normalmente utilizando un tiempo de ejecución de integración especialmente diseñado y herramientas que se adaptan bien a las capacidades 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 única de exponer las interfaces de servicio, lo que es mucho trabajo (incluso si las interfaces son eventualmente reutilizables) y crea un importante desafío de mantenimiento en el futuro. De hecho, los ESB eran considerados como un elemento de facto de cualquier implementación de la SOA tanto que los dos términos se utilizan a veces como sinónimos, creando confusión.

Obtenga más información sobre los ESB en Introducción a ESB (bus de servicio empresarial).

Ventajas de la SOA

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

  • Mayor agilidad empresarial; tiempo de comercialización más rápido: la eficiencia de ensamblar aplicaciones de interfaces de servicio reutilizables, en lugar de reescribir y reintegrarse con cada nuevo proyecto de desarrollo, permite a los desarrolladores crear aplicaciones mucho más rápido en respuesta a nuevas oportunidades de negocios.
  • Capacidad de aprovechar la funcionalidad heredada en nuevos mercados: una SOA bien diseñada permite a los desarrolladores tomar fácilmente la funcionalidad bloqueada en una plataforma o en un entorno de computación y ampliarla a nuevos entornos y mercados. Por ejemplo, muchas empresas han utilizado la SOA para exponer la funcionalidad de los sistemas financieros basados en mainframe a la web, lo que permite a sus clientes proporcionarse a sí mismos procesos e información previamente accesibles solamente a través de la interacción directa con los empleados de la empresa o los socios de negocios.
  • Mejora de la colaboración entre empresas y TI: en una SOA, los servicios se pueden definir en términos de negocios (por ejemplo, generar cotización de seguros o calcular el retorno de la inversión de equipo de capital). Esto permite a los analistas empresariales trabajar más eficazmente con los desarrolladores en conocimientos importantes, como el ámbito de un proceso de negocios definido por un servicio o las implicaciones para los negocios de cambiar un proceso, lo que puede llevar a un mejor resultado.

Ejemplos de SOA

Para 2010, las implementaciones de SOA iban a toda marcha en empresas líderes en prácticamente todas las industrias. Por ejemplo:

  • Delaware Electric recurrió a la SOA para integrar sistemas que antes no se comunicaban entre sí, lo que generó eficiencias de desarrollo que ayudaron a la organización a mantenerse solvente durante un congelamiento de cinco años por mandato estatal de las tarifas eléctricas.
  • Cisco adoptó la SOA para asegurarse de que su experiencia de pedidos de productos fuera consistente en todos los productos y canales exponiendo los procesos de pedidos como servicios que las divisiones, adquisiciones y socios de negocios de Cisco podrían incorporar a sus sitios web.
  • Independence Blue Cross (IBC) de Filadelfia implementó una SOA para asegurar que los diferentes componentes que se ocupan de los datos de los pacientes —agentes del servicio al cliente de IBC, consultas médicas, usuarios del sitio web de IBC— estuvieran funcionando con la misma fuente de datos (una “versión única de la verdad”).

SOA vs. microservicios

Hay miles de páginas impresas y digitales de expertos que comparan la SOA y los microservicios y definen 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 uso:

  • La SOA es un concepto que abarca toda la empresa. Permite que las aplicaciones se expongan sobre interfaces de acoplamiento flexible, cada una de las cuales corresponde a una función de negocios, 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 que los datos internos de una sola aplicación se dividan en partes pequeñas que se pueden cambiar, escalar y administrar de forma independiente. No define cómo las aplicaciones se comunican entre sí; para eso, volvamos al ámbito de negocios de las interfaces de servicio proporcionadas por la SOA.

La arquitectura de microservicios surgió y ganó 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 completo de los componentes, lo que simplifica y mejora los siguientes aspectos:

  • Agilidad y productividad de los desarrolladores: los microservicios permiten a los desarrolladores incorporar nuevas tecnologías a una parte de la aplicación sin abarcar el resto de la aplicación. Cualquier componente se puede modificar, probar e implementar 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; 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 de computación.
  • Resiliencia: de nuevo, gracias al desacoplamiento, la falla de un microservicio no afecta a los demás. Y cada microservicio puede cumplir sus propios requisitos de disponibilidad sin dejar de lado los demás componentes o toda la aplicación a los mayores requisitos de disponibilidad común.

Para profundizar en las diferencias entre la SOA y los microservicios, consulte SOA vs. 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 ESB fuertemente centralizado y su equipo centralizado asociado de especialistas en integración pueden convertirse en 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 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 nube híbrida, hay una alta probabilidad de que esté transformando diversas cargas de trabajo, incluidas las basadas en SOA, en modelos de implementación de nube 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 en SOA a la nube.

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 capitalizar las inversiones en la medida en que moderniza aplicaciones en la ruta hacia la nube.

Empiece hoy mismo con una cuenta de IBM Cloud.