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. Por consecuencia, también se aplica en el campo del diseño de software donde los componentes de la aplicación proporcionan servicios a los demás componentes, a través de un protocolo de comunicación a través de una red. Un servicio es una unidad discreta de funcionalidad a la que se puede acceder de forma remota y a la que se puede actuar y actualizar de forma independiente, como recuperar un extracto de una tarjeta de crédito en línea. SOA también pretende ser independiente de proveedores, productos y tecnologías.

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.

Un servicio tiene cuatro propiedades según una de las muchas definiciones de SOA:

1. Representa lógicamente una actividad comercial repetible con un resultado especificado.
2. Es autocontenido.
3. Es una caja negra para sus consumidores, lo que significa que el consumidor no tiene que ser consciente de los trabajos internos del servicio.
4. Puede estar compuesto por otros servicios.

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, un principio que SOA comparte con la programación modular. La arquitectura orientada a servicios integra componentes de software distribuidos, mantenidos e implementados por separado. Está habilitado por tecnologías y estándares que facilitan el funcionamiento de los componentes. comunicación y cooperación a través de una red, especialmente a través de una red IP.

SOA está relacionado con la idea de una API (interfaz de programación de aplicaciones), una interfaz o protocolo de comunicación entre diferentes partes de un programa informático destinado a simplificar la implementación y el mantenimiento del software. Se puede considerar una API como el servicio y la SOA como la arquitectura que permite que el servicio funcione.

Descripción general

En SOA, los servicios utilizan protocolos que describen cómo pasan y analizan mensajes utilizando metadatos de descripción. Estos metadatos describen tanto las características funcionales del servicio como las características de calidad del servicio. La arquitectura orientada a servicios tiene como objetivo permitir a los usuarios combinar grandes porciones de funcionalidad para formar aplicaciones que se crean exclusivamente a partir de servicios existentes y los combinan de manera ad hoc. Un servicio presenta una interfaz simple al solicitante que abstrae la complejidad subyacente actuando como una caja negra. Otros usuarios también pueden acceder a estos servicios independientes sin ningún conocimiento de su implementación interna.

Definición de conceptos

La palabra de moda relacionada orientación a servicios promueve un acoplamiento flexible entre servicios. SOA separa funciones en unidades distintas, o servicios, 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 correspondientes consumidores se comunican entre sí pasando datos en un formato compartido y bien definido, o coordinando una actividad entre dos o más servicios.

En octubre de 2009 se publicó un manifiesto para la arquitectura orientada a servicios. Este planteó seis valores fundamentales que se enumeran a continuación:

1. Valor comercial se da más importancia que la estrategia técnica.
2. Objetivos estratégicos se otorga más importancia que los beneficios específicos para proyectos.
3. Interoperabilidad intrínseca se da más importancia que la integración personalizada.
4. Servicios compartidos se dan más importancia que las implementaciones específicas.
5. Flexibilidad se da más importancia que la optimización.
6. Refinación evolutiva se da más importancia que la búsqueda de la perfección inicial.

SOA puede verse como parte del continuo que abarca desde el concepto más antiguo de computación distribuida y programación modular, pasando por SOA, hasta las prácticas de mashups, SaaS y computación en la nube (que algunos ven como descendientes de SOA)..

Principios

No existen estándares industriales relacionados 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 Incluya lo siguiente:

Contrato de servicios normalizados

Los servicios se adhieren a un acuerdo estándar de comunicaciones, 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 de acoplamiento suelto)

La relación entre los servicios se reduce al nivel que sólo son conscientes de su existencia.

Transparencia de ubicación de servicio (un aspecto de acoplamiento suelto)

Los servicios se pueden llamar desde cualquier lugar dentro de la red que se encuentra sin importar dónde esté presente.

Longitud del servicio

Los servicios deben estar diseñados para vivir mucho tiempo. Cuando sea posible los servicios deben evitar obligar a los consumidores a cambiar si no requieren nuevas características, si usted llama un servicio hoy debe ser capaz de llamar al mismo servicio mañana.

abstracción del servicio

Los servicios actúan como cajas negras, que es su lógica interior está oculta de los consumidores.

Autonomía de servicios

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

Servicio de apatridia

Los servicios son apátridas, es decir, devuelven el valor solicitado o dan una excepción por lo tanto minimizando el uso de los recursos.

Granularidad de servicio

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

Normalización del servicio

Los servicios están descompuestos o consolidados (normalizados) para minimizar la redundancia. En algunos, esto no puede hacerse. Estos son los casos en que se requieren optimización, acceso y agregación de rendimiento.

Composibilidad de servicio

Los servicios se pueden utilizar para componer otros servicios.

Servicio de descubrimiento

Los servicios se complementan con datos meta comunicativos mediante los cuales se pueden descubrir e interpretar eficazmente.

Reutilización del servicio

La lógica se divide en diversos servicios, para promover la reutilización del código.

Encapsulación de servicio

Muchos servicios que no fueron planeados inicialmente bajo SOA, pueden ser encapsulados o convertirse en parte de SOA.

Patrones

Cada componente básico de SOA puede desempeñar cualquiera de las tres funciones:

Proveedor de servicios

Crea un servicio web y proporciona su información al registro de servicios. Cada proveedor debate sobre un montón de cómo y por qué como qué servicio exponer, que dar más importancia: seguridad o disponibilidad fácil, qué precio ofrecer el servicio y muchos más. El proveedor también tiene que decidir qué categoría debe incluir el servicio en un servicio de corredor determinado y qué tipo de acuerdos de socios comerciales están obligados a utilizar el servicio.

Interventor de servicios, registro de servicios o depósito de servicios

Su funcionalidad principal es hacer que la información relativa al servicio web esté disponible para cualquier solicitante potencial. Quien implemente el corredor decide el alcance del corredor. Los corredores públicos están disponibles en todas partes, pero los corredores privados sólo están disponibles para una cantidad limitada de público. UDDI fue un intento temprano, ya no apoyado activamente para proporcionar el descubrimiento de servicios web.

Solicitud de servicio/consumer

Localiza entradas en el registro de corredores usando varias operaciones y luego se une al proveedor de servicios para invocar uno de sus servicios web. Cualquier servicio que necesiten los consumidores de servicio, tienen que llevarlo a los corredores, atarla con el servicio respectivo y luego usarlo. Pueden acceder a múltiples servicios si el servicio proporciona múltiples servicios.

La relación consumidor-proveedor de servicios se rige por un contrato de servicios estandarizado, 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 vinculados a un estilo arquitectónico particular siguen siendo relevantes y elegibles en el diseño SOA.

Enfoques de implementación

La arquitectura orientada a servicios se puede implementar con servicios web o microservicios. Esto se hace para que los componentes funcionales sean accesibles a través de protocolos de Internet estándar que son independientes de las plataformas y los lenguajes de programación. Estos servicios pueden representar nuevas aplicaciones o simplemente envoltorios de sistemas heredados existentes para que estén habilitados para la red.

Los implementadores suelen crear SOA utilizando estándares de servicios web. Un ejemplo es SOAP, que ha obtenido una amplia aceptación en la industria después de la recomendación de la Versión 1.2 del W3C (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 bloqueos. en software propietario del proveedor. 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, que incluyen:

• Servicios web basados en WSDL y SOAP
• Mensajería, por ejemplo, con ActiveMQ, JMS, RabbitMQ
• RESTful HTTP, con la transferencia estatal representacional (REST) que constituye su propio estilo arquitectónico basado en limitaciones
• OPC-UA
• Comunicaciones en Internet Motor
• WCF (Microsoft implementa servicios Web, formando parte de WCF)
• Apache Thrift
• gRPC
• SORCER

Las implementaciones pueden utilizar uno o más de estos protocolos y, por ejemplo, podrían utilizar un mecanismo de sistema de archivos para comunicar datos siguiendo una especificación de interfaz definida entre procesos que se ajusten al concepto SOA. La clave son los servicios independientes con interfaces definidas a los que se puede llamar para realizar sus tareas de manera estándar, sin que un servicio tenga conocimiento previo de la aplicación que llama, y sin que la aplicación tenga o necesite conocimiento de cómo el servicio realmente realiza sus tareas. SOA permite el desarrollo de aplicaciones que se construyen combinando servicios interoperables y poco acoplados.

Estos servicios interoperan según una definición formal (o contrato, por ejemplo, WSDL) que es independiente de la plataforma subyacente y el lenguaje de programación. La definición de la interfaz oculta la implementación del servicio específico del idioma. Por 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 (o cliente) compuesta común. 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 administrados también pueden envolver sistemas heredados COBOL y presentarlos como servicios de software.^.

Los lenguajes de programación de alto nivel como BPEL y 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 detallados en servicios empresariales más detallados, que diseñan a su vez puede incorporarse a flujos de trabajo y procesos de negocio implementados en aplicaciones o portales compuestos.

El modelado orientado a servicios es un marco SOA que identifica las diversas disciplinas que guían a los profesionales de SOA para conceptualizar, analizar, diseñar y diseñar 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 describe los diversos componentes que contribuyen a un enfoque exitoso de modelado orientado a servicios. Ilustra los elementos principales que identifican el "qué hacer" aspectos de un plan de desarrollo de servicios. El modelo permite a los profesionales elaborar un plan de proyecto e identificar los hitos de una iniciativa orientada al servicio. SOMF también proporciona una notación de modelado común para abordar la alineación entre las organizaciones empresariales y de TI.

Beneficios organizacionales

Algunos arquitectos empresariales creen que SOA puede ayudar a las empresas a responder de forma más rápida y rentable a las condiciones cambiantes del mercado. Este estilo de arquitectura promueve la reutilización a nivel macro (servicio) en lugar de 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 manera integral. Una empresa tiene un control más general. En teoría, no habría una gran cantidad de desarrolladores que utilizaran cualquier conjunto de herramientas que les agradara. Más bien, estarían codificando según un estándar establecido dentro de la empresa. También pueden desarrollar SOA para toda la empresa que encapsule una infraestructura orientada a los negocios. SOA también se ha ilustrado como un sistema de autopistas que proporciona eficiencia a los conductores de automóviles. La cuestión es que si todo el mundo tuviera un coche, pero no hubiera autopista en ninguna parte, las cosas serían limitadas y desorganizadas, en cualquier intento de llegar a cualquier parte de forma rápida o eficiente. El vicepresidente de servicios web de IBM, Michael Liebow, afirma que SOA "construye autopistas".

En algunos aspectos, SOA podría considerarse más como una evolución arquitectónica que como una revolución. Capta muchas de las mejores prácticas de arquitecturas de software anteriores. En los sistemas de comunicaciones, por ejemplo, se ha producido poco desarrollo de soluciones que utilicen enlaces verdaderamente estáticos para comunicarse con otros equipos de la red. Al adoptar un enfoque SOA, dichos sistemas pueden posicionarse para resaltar la importancia de interfaces bien definidas y altamente interoperables. Otros predecesores 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, por ejemplo en CORBA.

Un servicio comprende una unidad independiente de funcionalidad disponible sólo a través de una interfaz definida formalmente. Los servicios pueden ser algún tipo de "nanoempresas" que sean fáciles de producir y mejorar. También los servicios pueden ser "megacorporaciones" construido como el trabajo coordinado de servicios subordinados.

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

1. La separación promueve el concepto a la empresa que los servicios pueden ser entregados de forma rápida e independiente de los proyectos más grandes y más lentos comunes en la organización. El negocio comienza a entender sistemas e interfaces de usuario simplificadas llamando a servicios. Esto aboga por la agilidad. Es decir, fomenta innovaciones empresariales y acelera el tiempo al mercado.
2. La separación promueve la desvinculación de servicios de proyectos consumidores. Esto fomenta el buen diseño en la medida en que el servicio está diseñado sin saber quiénes son sus consumidores.
3. La documentación y los artefactos de prueba del servicio no están incrustados en el detalle del proyecto más amplio. Esto es importante cuando el servicio debe ser reutilizado más adelante.

SOA promete simplificar las pruebas de forma indirecta. 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, entonces se crea un código auxiliar correspondiente que reacciona a los datos de prueba cuando se crea un servicio. También se captura para el servicio un conjunto completo de pruebas de regresión, scripts, datos y respuestas. El servicio se puede probar como una 'caja negra' utilizando stubs existentes correspondientes a los servicios que llama. Se pueden construir entornos de prueba donde los servicios primitivos y fuera de alcance sean resguardos, mientras que el resto de la malla son implementaciones de prueba de servicios completos. Como 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 funciona de acuerdo con su documentación y encuentra lagunas en la documentación y los casos de prueba de todos los servicios dentro del entorno. Gestionar el estado de los datos de los servicios idempotentes es la única complejidad.

Los ejemplos pueden resultar útiles para ayudar a documentar un servicio hasta el nivel en que resulte útil. La documentación de algunas API dentro del Proceso de la comunidad Java proporciona buenos ejemplos. Como son exhaustivos, el personal normalmente utilizaría sólo subconjuntos importantes. El 'ossjsa.pdf' El archivo dentro de JSR-89 ejemplifica dicho archivo.

Crítica

SOA se ha combinado con servicios web; sin embargo, los servicios web son sólo 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, lo que aumentaría los costos. La mayoría de las implementaciones incurren en estos gastos generales, pero SOA se puede implementar utilizando tecnologías (por ejemplo, Java Business Integration (JBI), Windows Communication Foundation (WCF) y servicio de distribución de datos (DDS)) que no dependen de llamadas a procedimientos remotos o 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.

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

Uno de los principales desafíos que enfrenta la arquitectura orientada a servicios es la gestión de metadatos. Los entornos basados en SOA incluyen muchos servicios que se comunican entre sí para realizar tareas. Debido al hecho de que el diseño puede involucrar múltiples servicios trabajando en conjunto, una Aplicación puede generar millones de mensajes. Otros servicios pueden pertenecer a diferentes organizaciones o incluso a empresas competidoras, lo que genera un enorme problema de confianza. Así, la gobernanza SOA entra en el esquema de las cosas.

Otro problema importante al que se enfrenta SOA es la falta de un marco de pruebas uniforme. No existen herramientas que proporcionen las funciones necesarias para probar estos servicios en una arquitectura orientada a servicios. Las principales causas de dificultad son:

• Heterogeneidad y complejidad de solución.
• Gran conjunto de combinaciones de pruebas debido a la integración de servicios autónomos.
• Inclusión de servicios de diferentes proveedores y competidores.
• La plataforma está cambiando continuamente debido a la disponibilidad de nuevas características y servicios.

Extensiones y variantes

Arquitectura basada en eventos

Interfaces de programación de aplicaciones

Las interfaces de programación de aplicaciones (API) son los marcos a través de los cuales los desarrolladores pueden interactuar con una aplicación web.

Web 2.0

Tim O'Reilly acuñó el término "Web 2.0" para describir un conjunto de aplicaciones basadas en web percibidas y de rápido crecimiento. Un tema que ha experimentado una amplia cobertura es el de la relación entre la Web 2.0 y las arquitecturas orientadas a servicios.

SOA es la filosofía de encapsular la lógica de la aplicación en servicios con una interfaz uniformemente definida y ponerlos a disposición del público a través de mecanismos de descubrimiento. La noción de ocultación de complejidad y reutilización, pero también el concepto de servicios ligeramente acoplados, ha inspirado a los investigadores a elaborar similitudes entre las dos filosofías, SOA y Web 2.0, y sus respectivas aplicaciones. Algunos argumentan que la Web 2.0 y SOA tienen elementos significativamente diferentes y, por lo tanto, no pueden considerarse "filosofías paralelas", mientras que otros consideran que los dos conceptos son complementarios y consideran la Web 2.0 como la SOA global.

Las filosofías de Web 2.0 y SOA satisfacen diferentes necesidades de los usuarios y, por lo tanto, exponen diferencias con respecto al diseño y también a las tecnologías utilizadas en las aplicaciones del mundo real. Sin embargo, a partir de 2008, los casos de uso demostraron el potencial de combinar tecnologías y principios tanto de Web 2.0 como de SOA.

Microservicios

Los microservicios son una interpretación moderna de las arquitecturas orientadas a servicios que se utilizan para crear sistemas de software distribuido. Los servicios en una arquitectura de microservicios son procesos que se comunican entre sí a través de la red para cumplir un objetivo. Estos servicios utilizan protocolos independientes de la tecnología, que ayudan a encapsular la elección de lenguaje y marcos, haciendo que su elección sea una preocupación interna del servicio. Los microservicios son un nuevo enfoque de realización e implementación de SOA, que se han vuelto populares desde 2014 (y después de la introducción de DevOps) y que también enfatizan la implementación continua y otras prácticas ágiles.

No existe una definición única y común de microservicios. Las siguientes características y principios se pueden encontrar en la literatura:

• interfaces finas (a servicios de despliegue independiente),
• desarrollo impulsado por empresas (por ejemplo, diseño impulsado por dominios),
• IDEAL cloud application architectures,
• programación y persistencia de poliglotas,
• despliegue de contenedores ligeros,
• entrega continua descentralizada y
• DevOps con monitoreo integral de servicios.

Arquitecturas orientadas a servicios para aplicaciones interactivas

Las aplicaciones interactivas que requieren tiempos de respuesta en tiempo real, por ejemplo las aplicaciones 3D interactivas de baja latencia, utilizan arquitecturas específicas orientadas a servicios que abordan las necesidades específicas de este tipo de aplicaciones. Estos incluyen, por ejemplo, comunicación y computación distribuida optimizada de baja latencia, así como gestión de recursos e instancias.