Gerencia de Arquitectura Empresarial
Departamento de Arquitectura de Solución
enero de 2024
SOA
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.
Antecedentes arquitectónicos de SOA
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.
ESB
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 comunicación 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.
Preparado por:
Brian Eduardo Segura Lozano Revisado y aprobado por:
Juan Antonio Silva Flores Luis Alejandro Gutiérrez Mota
Gerencia de Arquitectura Empresarial
Departamento de Arquitectura de Solución
enero de 2024
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.
A continuación, se muestra de forma gráfica cómo funciona un Enterprise Service Bus (Diagrama 2).
Diagrama 2: Vista general de un Enterprise Service Bus
Características de SOA
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.
Preparado por:
Brian Eduardo Segura Lozano Revisado y aprobado por:
Juan Antonio Silva Flores Luis Alejandro Gutiérrez Mota
Gerencia de Arquitectura Empresarial
Departamento de Arquitectura de Solución
enero de 2024
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, .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.
Elementos arquitectónicos de la arquitectura orientada a servicios
• Proveedor de servicios: Se encarga de crear servicios web, ofrecerlos a un registro de
servicios disponibles y gestionar sus condiciones de uso.
• Agente o registro de servicios: Se encarga de brindar información acerca del servicio a quien
lo solicite, y puede ser público o privado.
• Usuario del servicio, persona que lo solicita o consumidor: Buscará un servicio en el registro
o por medio del agente, y se conectará con el proveedor para recibirlo (Ver diagrama 1)
Diagrama 1: Patrón de interacción de SOA
Preparado por:
Brian Eduardo Segura Lozano Revisado y aprobado por:
Juan Antonio Silva Flores Luis Alejandro Gutiérrez Mota
Gerencia de Arquitectura Empresarial
Departamento de Arquitectura de Solución
enero de 2024
Beneficios de SOA
• Mayor agilidad empresarial, comercialización más rápida: 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,
permiten a los desarrolladores crear aplicaciones con mucha mayor rapidez en respuesta a
nuevas oportunidades comerciales. El enfoque arquitectónico orientado al servicio admite
escenarios para la integración de aplicaciones, la integración de datos y la automatización del
estilo de orquestación de servicios de los procesos de negocio o flujos de trabajo. Esto acelera
el diseño de software y el desarrollo de software al permitir que los desarrolladores dediquen
mucho menos tiempo a la integración y mucho más tiempo a la entrega y mejora de sus
aplicaciones.
• Capacidad para aprovechar la funcionalidad heredada en nuevos mercados: una SOA bien
lograda permite a los desarrolladores adoptar fácilmente una funcionalidad "bloqueada" en
una plataforma o entorno informático y llevarla a entornos y mercados nuevos. Por ejemplo,
muchas empresas han utilizado SOA para exponer la funcionalidad de los sistemas financieros
basados en mainframe a nuevas aplicaciones web, lo que permite a sus clientes acceder a
procesos e información que antes solo eran accesibles a través de la interacción directa con
los empleados o business partners de la empresa.
• Mejora en la colaboración entre la empresa y la TI: en una SOA, los servicios se pueden definir
en términos comerciales (por ejemplo, "generar oferta de seguros"). Esto permite a los
analistas de negocio trabajar más eficazmente con los desarrolladores en aspectos
importantes, como el ámbito de un proceso de negocio definido por servicios o las
implicaciones para los negocios de cambiar un proceso, lo que puede generar mejores
resultados.
Preparado por:
Brian Eduardo Segura Lozano Revisado y aprobado por:
Juan Antonio Silva Flores Luis Alejandro Gutiérrez Mota
Gerencia de Arquitectura Empresarial
Departamento de Arquitectura de Solución
enero de 2024
Cuándo implementar la Arquitectura orientada a servicios.
• Construcción de aplicaciones con múltiples servicios y una interfaz única.
• Construcción de aplicaciones en la nube.
• Comunicación basada en mensajes.
• Funcionalidad con independencia de plataformas.
• Necesidad de establecer servicios federados.
• Exposición de servicios con independencia de conocimiento por parte del cliente de su
interfaz.
• Adecuado para escenarios de interoperabilidad e integración
Preparado por:
Brian Eduardo Segura Lozano Revisado y aprobado por:
Juan Antonio Silva Flores Luis Alejandro Gutiérrez Mota
Gerencia de Arquitectura Empresarial
Departamento de Arquitectura de Solución
enero de 2024
Anexo 1: Vista de la Arquitectura Orientada a Servicios (Service
Oriented Architecture)
Volver al roadmap
Preparado por:
Brian Eduardo Segura Lozano Revisado y aprobado por:
Juan Antonio Silva Flores Luis Alejandro Gutiérrez Mota
