Arquitectura orientada a servicios

En ingeniería de software , la arquitectura orientada a servicios ( SOA ) es un estilo arquitectónico que se centra en servicios discretos en lugar de un diseño monolítico . ^{[ 1 ]} SOA es una buena opción para la integración de sistemas . ^{[ 2 ]} Por consiguiente, también se aplica en el campo del diseño de software, donde los componentes de la aplicación proporcionan servicios a otros componentes mediante un protocolo de comunicación en red. Un servicio es una unidad discreta de funcionalidad a la que se puede acceder de forma remota, sobre la que se puede actuar y que se puede actualizar de forma independiente, como por ejemplo, consultar un extracto de tarjeta de crédito en línea. SOA también pretende ser independiente de proveedores, productos y tecnologías. ^{[ 3 ]}

La orientación al servicio es una forma de pensar en términos de servicios y desarrollo basado en servicios y los resultados de los servicios. ^{[ 1 ]}

Un servicio tiene cuatro propiedades según una de las muchas definiciones de SOA: ^{[ 4 ]}

1. Representa lógicamente una actividad empresarial repetible con un resultado específico.
2. Es autónomo.
3. Para sus consumidores, se trata de una caja negra , lo que significa que el consumidor no tiene por qué estar al tanto del funcionamiento interno del servicio.
4. Puede estar compuesto por otros servicios. ^{[ 5 ]}

Se pueden utilizar diferentes servicios en conjunto como una malla de servicios para proporcionar la funcionalidad de una aplicación de software de gran tamaño , ^{[ 6 ]} un principio que la SOA comparte con la programación modular . La arquitectura orientada a servicios integra componentes de software distribuidos, mantenidos y desplegados por separado. Se habilita mediante tecnologías y estándares que facilitan la comunicación y la cooperación de los componentes a través de una red, especialmente a través de una red IP.

SOA se relaciona con el concepto de API ( interfaz de programación de aplicaciones ), una interfaz o protocolo de comunicación entre diferentes partes de un programa informático, cuyo objetivo es simplificar la implementación y el mantenimiento del software. Una API puede considerarse el servicio, y SOA la arquitectura que permite que dicho servicio funcione.

Cabe señalar que la arquitectura orientada a servicios no debe confundirse con la arquitectura basada en servicios, ya que son dos estilos arquitectónicos diferentes. ^{[ 7 ]}

En SOA, los servicios utilizan protocolos que describen cómo transmiten y analizan los mensajes mediante metadatos de descripción . Estos metadatos describen tanto las características funcionales del servicio como las de calidad. La arquitectura orientada a servicios (SOA) busca permitir a los usuarios combinar grandes bloques de funcionalidad para formar aplicaciones construidas exclusivamente a partir de servicios existentes, combinándolos de forma ad hoc. Un servicio presenta una interfaz sencilla al solicitante que abstrae la complejidad subyacente, actuando como una caja negra. Además, los usuarios pueden acceder a estos servicios independientes sin necesidad de conocer su implementación interna. ^{[ 8 ]}

El término de moda relacionado, orientación a servicios, promueve un acoplamiento flexible entre servicios. SOA separa las funciones en unidades distintas, o servicios, ^{[ 9 ]} que los desarrolladores hacen accesibles a través de una red para permitir a los usuarios combinarlas y reutilizarlas en la producción de aplicaciones. Estos servicios y sus consumidores correspondientes se comunican entre sí mediante el intercambio de datos en un formato compartido y bien definido, o mediante la coordinación de una actividad entre dos o más servicios. ^{[ 10 ]}

SOA puede considerarse parte del continuo que abarca desde el concepto más antiguo de computación distribuida ^{[ 9 ] [ 11 ]} y programación modular , pasando por SOA, hasta prácticas como mashups , SaaS y computación en la nube (que algunos consideran descendientes de SOA). ^{[ 12 ]}

No existen estándares de la industria en relación con la composición exacta de una arquitectura orientada a servicios, aunque muchas fuentes de la industria han publicado sus propios principios. Algunos de estos ^{[ 13 ] [ 14 ] [ 15 ]} incluyen los siguientes:

Contrato de servicio estandarizado ^{[ 16 ]}

Los servicios se rigen por un acuerdo de comunicaciones estándar, definido colectivamente por uno o más documentos de descripción de servicios dentro de un conjunto determinado de servicios.

Autonomía de referencia de servicio (un aspecto del acoplamiento flexible)

La relación entre los servicios se reduce al mínimo, hasta el punto de que apenas son conscientes de su existencia.

Transparencia en la ubicación del servicio (un aspecto del acoplamiento flexible)

Se puede acceder a los servicios desde cualquier punto de la red en la que se encuentren, independientemente de su ubicación.

longevidad del servicio

Los servicios deben diseñarse para ser duraderos. Siempre que sea posible, deben evitarse los cambios que puedan suponer para los consumidores si no necesitan nuevas funcionalidades; si usted llama a un servicio hoy, debería poder llamar al mismo mañana.

Abstracción de servicio

Los servicios funcionan como cajas negras, es decir, su lógica interna está oculta para los consumidores.

Autonomía del servicio

Los servicios son independientes y controlan la funcionalidad que encapsulan, tanto desde la perspectiva del diseño como desde la del tiempo de ejecución.

apatridia del servicio

Los servicios no tienen estado, es decir, o bien devuelven el valor solicitado o bien generan una excepción, minimizando así el uso de recursos.

Granularidad del servicio

Un principio para asegurar que los servicios tengan un tamaño y alcance adecuados. La funcionalidad que el servicio proporciona al usuario debe ser relevante.

Normalización del servicio

Los servicios se descomponen o consolidan (normalizan) para minimizar la redundancia. En algunos casos, esto puede no hacerse. Estos son los casos en los que se requiere optimización del rendimiento, acceso y agregación. ^{[ 17 ]}

Componibilidad de servicios

Los servicios pueden utilizarse para componer otros servicios.

descubrimiento de servicios

Los servicios se complementan con metadatos comunicativos que permiten descubrirlos e interpretarlos de forma eficaz.

Reutilización del servicio

La lógica se divide en varios servicios para fomentar la reutilización del código.

Encapsulación de servicios

Muchos servicios que inicialmente no estaban previstos bajo SOA, pueden encapsularse o pasar a formar parte de SOA.

Cada bloque de construcción SOA puede desempeñar cualquiera de los tres roles:

proveedor de servicios

Crea un servicio web y proporciona su información al registro de servicios. Cada proveedor debate sobre muchos aspectos, como qué servicio exponer, a cuál darle mayor importancia (seguridad o fácil disponibilidad), qué precio ofrecer y muchos más . El proveedor también debe decidir en qué categoría debe figurar el servicio para un servicio de corretaje determinado ^{[ 18 ]} y qué tipo de acuerdos de socios comerciales se requieren para utilizar el servicio.

Agente de servicios, registro de servicios o repositorio de servicios

Su principal función es poner a disposición de cualquier solicitante información sobre el servicio web. Quien implementa el intermediario decide su alcance. Los intermediarios públicos están disponibles en cualquier lugar, pero los privados solo están disponibles para un número limitado de usuarios. UDDI fue un intento inicial, que ya no recibe soporte activo, de proporcionar descubrimiento de servicios web .

Solicitante/consumidor del servicio

El sistema localiza las entradas en el registro del intermediario mediante diversas operaciones de búsqueda y, a continuación, se conecta al proveedor de servicios para invocar uno de sus servicios web. Los consumidores deben acceder al servicio que necesiten a través del intermediario, vincularlo con el servicio correspondiente y, posteriormente, utilizarlo. Pueden acceder a varios servicios si el proveedor ofrece múltiples opciones.

La relación entre el consumidor y el proveedor de servicios se rige por un contrato de servicio estandarizado , ^{[ 19 ]} que tiene una parte comercial, una parte funcional y una parte técnica.

Los patrones de composición de servicios tienen dos estilos arquitectónicos amplios y de alto nivel: coreografía y orquestación . Los patrones de integración empresarial de nivel inferior que no están ligados a un estilo arquitectónico particular siguen siendo relevantes y válidos en el diseño de SOA. ^{[ 20 ] [ 21 ] [ 22 ]}

La arquitectura orientada a servicios se puede implementar con servicios web o microservicios . ^{[ 23 ]} Esto se hace para que los bloques funcionales sean accesibles a través de protocolos de Internet estándar, independientes de plataformas y lenguajes de programación. Estos servicios pueden representar nuevas aplicaciones o simplemente envoltorios para sistemas heredados existentes, con el fin de habilitarlos para la red. ^{[ 24 ]}

Los implementadores suelen construir SOA utilizando estándares de servicios web. Un ejemplo es SOAP , que ha obtenido una amplia aceptación en la industria tras la recomendación de la versión 1.2 por parte del W3C ^{[ 25 ]} (World Wide Web Consortium) en 2003. Estos estándares (también conocidos como especificaciones de servicios web ) también proporcionan una mayor interoperabilidad y cierta protección contra la dependencia de software propietario de proveedores. Sin embargo, también se puede implementar SOA utilizando cualquier otra tecnología basada en servicios, como Jini , CORBA , Internet Communications Engine , REST o gRPC .

Las arquitecturas pueden funcionar independientemente de tecnologías específicas y, por lo tanto, pueden implementarse utilizando una amplia gama de tecnologías, entre las que se incluyen:

• Servicios web basados ​​en WSDL y SOAP
• Mensajería, por ejemplo, con ActiveMQ, JMS, RabbitMQ.
• HTTP RESTful, con la transferencia de estado representacional (REST) ​​constituyendo su propio estilo arquitectónico basado en restricciones.
• Servicio de Distribución de Datos (DDS)
• OPC-UA
• Motor de comunicaciones de Internet
• WCF (implementación de servicios web de Microsoft, que forma parte de WCF)
• Ahorro Apache
• gRPC
• HECHICERO

Las implementaciones pueden utilizar uno o más de estos protocolos y, por ejemplo, podrían emplear un mecanismo de sistema de archivos para comunicar datos siguiendo una especificación de interfaz definida entre procesos que se ajustan al concepto SOA. La clave reside en servicios independientes con interfaces definidas que pueden invocarse para realizar sus tareas de forma estandarizada, sin que el servicio tenga conocimiento previo de la aplicación que lo invoca, y sin que la aplicación tenga o necesite saber cómo el servicio realiza realmente sus tareas. SOA permite el desarrollo de aplicaciones que se construyen combinando servicios interoperables y débilmente acoplados .

Estos servicios interactúan basándose en una definición formal (o contrato, por ejemplo, WSDL) que es independiente de la plataforma subyacente y del lenguaje de programación. La definición de la interfaz oculta la implementación del servicio específico del lenguaje. Por lo tanto, los sistemas basados ​​en SOA pueden funcionar independientemente de las tecnologías y plataformas de desarrollo (como Java, .NET, etc.). Los servicios escritos en C# que se ejecutan en plataformas .NET y los servicios escritos en Java que se ejecutan en plataformas Java EE , por ejemplo, pueden ser consumidos por una aplicación compuesta común (o cliente). Las aplicaciones que se ejecutan en cualquiera de las plataformas también pueden consumir servicios que se ejecutan en la otra como servicios web que facilitan la reutilización. Los entornos gestionados también pueden encapsular sistemas heredados COBOL y presentarlos como servicios de software ^{. [ 26 ]}

Los lenguajes de programación de alto nivel, como BPEL , y las especificaciones, como WS-CDL y WS-Coordination, amplían el concepto de servicio al proporcionar un método para definir y respaldar la orquestación de servicios de grano fino en servicios empresariales de grano más grueso, que los arquitectos pueden, a su vez, incorporar en flujos de trabajo y procesos empresariales implementados en aplicaciones compuestas o portales .

El modelado orientado a servicios (SOMF) es un marco de trabajo SOA que identifica las diversas disciplinas que guían a los profesionales de SOA para conceptualizar, analizar, diseñar y desarrollar sus activos orientados a servicios. El marco de modelado orientado a servicios (SOMF) ofrece un lenguaje de modelado y una estructura de trabajo o "mapa" que representa los diversos componentes que contribuyen a un enfoque de modelado orientado a servicios exitoso. Ilustra los elementos principales que identifican los aspectos "qué hacer" de un esquema de desarrollo de servicios. El modelo permite a los profesionales elaborar un plan de proyecto e identificar los hitos de una iniciativa orientada a servicios. SOMF también proporciona una notación de modelado común para abordar la alineación entre las organizaciones de negocio y de TI.

Algunos arquitectos empresariales creen que la SOA puede ayudar a las empresas a responder de forma más rápida y rentable a las cambiantes condiciones del mercado. ^{[ 28 ]} Este estilo de arquitectura promueve la reutilización a nivel macro (servicio) en lugar de a nivel micro (clases). También puede simplificar la interconexión y el uso de los activos de TI (heredados) existentes.

Con SOA, la idea es que una organización pueda abordar un problema de forma holística. Una empresa tiene mayor control general. Teóricamente, no habría una multitud de desarrolladores utilizando las herramientas que les plazcan, sino que programarían según un estándar establecido por la empresa. También pueden desarrollar una SOA a nivel empresarial que encapsule una infraestructura orientada al negocio. SOA también se ha comparado con un sistema de autopistas que proporciona eficiencia a los conductores. La idea es que si todos tuvieran un coche, pero no hubiera autopistas, todo sería limitado y desorganizado, dificultando cualquier intento de llegar a cualquier lugar de forma rápida y eficiente. El vicepresidente de servicios web de IBM, Michael Liebow, afirma que SOA "construye autopistas". ^{[ 29 ]}

En cierto modo, SOA podría considerarse una evolución arquitectónica más que una revolución. Incorpora muchas de las mejores prácticas de arquitecturas de software anteriores. En los sistemas de comunicaciones, por ejemplo, se ha desarrollado poco el uso de enlaces estáticos para comunicarse con otros equipos de la red. Al adoptar un enfoque SOA, estos sistemas pueden priorizar la importancia de interfaces bien definidas y altamente interoperables. Otros precursores de SOA incluyen la ingeniería de software basada en componentes y el análisis y diseño orientado a objetos (OOAD) de objetos remotos, como CORBA .

Un servicio comprende una unidad de funcionalidad independiente, accesible únicamente a través de una interfaz definida formalmente. Los servicios pueden ser una especie de "nanoempresas" fáciles de producir y mejorar. Asimismo, pueden ser "megacorporaciones", formadas por el trabajo coordinado de servicios subordinados.

Entre las razones para tratar la implementación de servicios como proyectos separados de proyectos más grandes se incluyen:

1. La separación promueve en la empresa la idea de que los servicios pueden entregarse de forma rápida e independiente de los proyectos más grandes y de menor duración que son habituales en la organización. La empresa comienza a comprender los sistemas y las interfaces de usuario simplificadas que utilizan los servicios. Esto fomenta la agilidad ; es decir, impulsa la innovación empresarial y acelera el tiempo de comercialización. ^{[ 30 ]}
2. La separación promueve el desacoplamiento de los servicios de los proyectos que los consumen. Esto fomenta un buen diseño, ya que el servicio se diseña sin conocer quiénes son sus consumidores.
3. La documentación y los artefactos de prueba del servicio no están integrados en los detalles del proyecto general. Esto es importante cuando el servicio necesita ser reutilizado posteriormente.

SOA promete simplificar las pruebas indirectamente. Los servicios son autónomos, sin estado, con interfaces completamente documentadas y separados de las preocupaciones transversales de la implementación. Si una organización posee datos de prueba definidos adecuadamente, se crea un stub correspondiente que reacciona a dichos datos durante la creación del servicio. También se captura un conjunto completo de pruebas de regresión, scripts, datos y respuestas para el servicio. Este puede probarse como una "caja negra" utilizando stubs existentes que corresponden a los servicios a los que llama. Se pueden construir entornos de prueba donde los servicios primitivos y fuera del alcance son stubs, mientras que el resto de la malla son implementaciones de prueba de servicios completos. Dado que cada interfaz está completamente documentada con su propio conjunto completo de documentación de pruebas de regresión, resulta sencillo identificar problemas en los servicios de prueba. Las pruebas evolucionan para simplemente validar que el servicio de prueba opera de acuerdo con su documentación y detectan deficiencias en la documentación y los casos de prueba de todos los servicios dentro del entorno. La gestión del estado de los datos de los servicios idempotentes es la única complejidad.

Los ejemplos pueden resultar útiles para documentar un servicio hasta el nivel en que se vuelve útil. La documentación de algunas API dentro del Proceso de la Comunidad Java proporciona buenos ejemplos. Dado que son exhaustivos, el personal normalmente solo utilizaría subconjuntos importantes. El archivo 'ossjsa.pdf' dentro de JSR-89 ejemplifica un archivo de este tipo. ^{[ 31 ]}

Aunque la arquitectura orientada a servicios (SOA) se utiliza ampliamente en infraestructuras corporativas y gubernamentales a gran escala, varias plataformas destacadas demuestran su valor en la federación de servicios específicos de dominio para la investigación y la colaboración global:

• Cancer Biomedical Informatics Grid (caBIG) : Una iniciativa creada por el Instituto Nacional del Cáncer de EE. UU. que utilizó SOA para federar herramientas bioinformáticas y datos clínicos. Al integrar diversos recursos médicos como servicios estandarizados, permitió a los investigadores del cáncer de diferentes instituciones compartir y analizar datos dentro de una red unificada. ^{[ 32 ]}
• Observatorio Virtual (VO) : Una colección de archivos de datos y herramientas de software interoperables en astronomía. Utiliza principios SOA para federar diversas bases de datos astronómicas y herramientas de análisis distribuidas en observatorios globales, lo que permite a los investigadores consultar y procesar datos sin problemas como si se tratara de un único sistema transparente. ^{[ 33 ]}
• Language Grid : Una plataforma de servicios multilingües que utiliza SOA para federar recursos lingüísticos dispares, como motores de traducción automática y diccionarios en línea, distribuidos mundialmente. Al encapsular estos recursos heterogéneos como servicios web estandarizados, la plataforma permite a los usuarios y las comunidades crear herramientas de comunicación intercultural personalizadas. ^{[ 34 ]}

SOA se ha confundido con los servicios web ; ^{[ 35 ]} sin embargo, los servicios web son solo una opción para implementar los patrones que componen el estilo SOA. En ausencia de formas nativas o binarias de llamada a procedimiento remoto (RPC), las aplicaciones podrían ejecutarse más lentamente y requerir más potencia de procesamiento, aumentando los costos. La mayoría de las implementaciones incurren en estos gastos generales, pero SOA puede implementarse utilizando tecnologías (por ejemplo, Java Business Integration (JBI), Windows Communication Foundation (WCF) y el servicio de distribución de datos (DDS)) que no dependen de llamadas a procedimiento remoto ni de la traducción a través de XML o JSON. Al mismo tiempo, las tecnologías emergentes de análisis XML de código abierto (como VTD-XML ) y varios formatos binarios compatibles con XML prometen mejorar significativamente el rendimiento de SOA. ^{[ 36 ] [ 37 ] [ 38 ]}

Los servicios con estado requieren que tanto el consumidor como el proveedor compartan el mismo contexto específico del consumidor, el cual se incluye o se referencia en los mensajes intercambiados entre ambos. Esta restricción tiene el inconveniente de que podría reducir la escalabilidad general del proveedor de servicios si este necesita conservar el contexto compartido para cada consumidor. También aumenta el acoplamiento entre el proveedor y el consumidor y dificulta el cambio de proveedor. ^{[ 39 ]} En última instancia, algunos críticos consideran que los servicios SOA aún están demasiado limitados por las aplicaciones que representan. ^{[ 40 ]}

Un desafío fundamental para la arquitectura orientada a servicios (SOA) es la gestión de metadatos. Los entornos basados ​​en SOA incluyen numerosos servicios que se comunican entre sí para realizar tareas. Dado que el diseño puede implicar múltiples servicios trabajando conjuntamente, una aplicación puede generar millones de mensajes. Además, los servicios pueden pertenecer a diferentes organizaciones o incluso a empresas competidoras, lo que genera un grave problema de confianza. Por lo tanto, la gobernanza de SOA entra en juego. ^{[ 41 ]}

Otro problema importante al que se enfrenta SOA es la falta de un marco de pruebas uniforme. No existen herramientas que proporcionen las características necesarias para probar estos servicios en una arquitectura orientada a servicios. Las principales causas de la dificultad son: ^{[ 42 ]}

• Heterogeneidad y complejidad de la solución.
• Gran variedad de combinaciones de pruebas debido a la integración de servicios autónomos.
• Inclusión de servicios de proveedores diferentes y competidores.
• La plataforma está en constante evolución debido a la disponibilidad de nuevas funciones y servicios.

• Interfaz de programación de aplicaciones
• Acoplamiento suelto
• Modelo de referencia OASIS SOA
• principio de granularidad del servicio
• gobernanza de SOA
• Arquitectura de software
• Comunicaciones orientadas a servicios (SOC)
• Desarrollo de aplicaciones orientado a servicios
• Aplicaciones distribuidas orientadas a servicios
• Lenguaje de descripción de aplicaciones web

• Mauro, Christian; Leimeister, Jan Marco; Krcmar, Helmut (enero de 2010). «Integración de dispositivos orientada a servicios: un análisis de patrones de diseño SOA» (PDF) . 43.ª Conferencia Internacional de Hawái sobre Ciencias de Sistemas, 2010. págs. 1-10 . doi : 10.1109/HICSS.2010.336 . ISBN  978-1-4244-5509-6. S2CID 457705 . Archivado del original (PDF) el 24 de enero de 2022 . Recuperado el 21 de septiembre de 2021 .