La arquitectura orientada a servicios ( SOA ) es un estilo arquitectónico que admite la orientación a servicios. [1] En consecuencia, también se aplica en el campo del diseño de software, donde los servicios se prestan a los otros componentes mediante componentes de aplicación , 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 se puede actuar y actualizar de forma independiente, como recuperar un extracto de tarjeta de crédito en línea. SOA también pretende ser independiente de proveedores, productos y tecnologías. [2]
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: [3]
- Lógicamente, representa una actividad comercial repetible con un resultado específico.
- Es autónomo.
- Es una caja negra para sus consumidores, lo que significa que el consumidor no tiene que ser consciente del funcionamiento interno del servicio.
- Puede estar compuesto por otros servicios. [4]
Se pueden utilizar diferentes servicios en conjunto como una malla de servicios para proporcionar la funcionalidad de una gran aplicación de software , [5] 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 la comunicación y cooperación de los componentes a través de una red, especialmente a través de una red IP.
SOA está relacionada con la idea de una interfaz de programación de aplicaciones (API), 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. Una API se puede considerar 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 los mensajes utilizando metadatos de descripción . Estos metadatos describen tanto las características funcionales del servicio como las características de la 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 construyen puramente a partir de servicios existentes y combinándolos de manera ad hoc. Un servicio presenta una interfaz simple para el solicitante que abstrae la complejidad subyacente que actúa como una caja negra. Otros usuarios también pueden acceder a estos servicios independientes sin ningún conocimiento de su implementación interna. [6]
Definición de conceptos
La palabra de moda relacionada que promueve la orientación al servicio es un acoplamiento flexible entre servicios. SOA separa las funciones en distintas unidades, o servicios, [7] que los desarrolladores hacen accesibles a través de una red para permitir que los usuarios las combinen y reutilicen en la producción de aplicaciones. Estos servicios y sus correspondientes consumidores se comunican entre sí pasando datos en un formato compartido bien definido o coordinando una actividad entre dos o más servicios. [8]
En octubre de 2009 se publicó un manifiesto para la arquitectura orientada a servicios. Esto dio como resultado seis valores fundamentales que se enumeran a continuación: [9]
- Se le da más importancia al valor comercial que a la estrategia técnica.
- Se da más importancia a los objetivos estratégicos que a los beneficios específicos del proyecto.
- Se da más importancia a la interoperabilidad intrínseca que a la integración personalizada.
- A los servicios compartidos se les da más importancia que a las implementaciones con propósitos específicos.
- Se da más importancia a la flexibilidad que a la optimización.
- Se le da más importancia al refinamiento evolutivo que a la búsqueda de la perfección inicial.
SOA puede verse como parte del continuo que va desde el concepto más antiguo de computación distribuida [7] [10] y programación modular , pasando por SOA, y hasta prácticas de mashups , SaaS y computación en la nube (que algunos ven de SOA). [11]
Principios
No existen estándares de la industria 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 [12] [13] [14] [15] incluyen los siguientes:
- Contrato de servicio estandarizado
- Los servicios se adhieren a un acuerdo de comunicaciones estándar, tal como se define colectivamente por uno o más documentos de descripción de servicios dentro de un conjunto de servicios dado.
- Autonomía de referencia de servicio (un aspecto del acoplamiento flojo)
- La relación entre servicios se minimiza al nivel de que solo son conscientes de su existencia.
- Transparencia en la ubicación del servicio (un aspecto del acoplamiento flojo)
- Se puede llamar a los servicios desde cualquier lugar de la red en el que se encuentre, sin importar dónde esté presente.
- Longevidad del servicio
- Los servicios deben diseñarse para durar mucho tiempo. Siempre que sea posible, los servicios deben evitar obligar a los consumidores a cambiar si no requieren nuevas funciones; si llama a un servicio hoy, debería poder llamar al mismo servicio mañana.
- Abstracción de servicios
- Los servicios actúan como cajas negras, es decir, su lógica interna está oculta a los consumidores.
- Autonomía del servicio
- Los servicios son independientes y controlan la funcionalidad que encapsulan, desde una perspectiva de tiempo de diseño y tiempo de ejecución.
- Servicio de apatridia
- Los servicios no tienen estado, es decir, devuelven el valor solicitado o dan una excepción, lo que minimiza el uso de recursos.
- Granularidad del servicio
- Un principio para garantizar que los servicios tengan un tamaño y alcance adecuados. La funcionalidad proporcionada por el servicio al usuario debe ser relevante.
- Normalización del servicio
- Los servicios se descomponen o consolidan (normalizan) para minimizar la redundancia. En algunos, es posible que esto no se haga. Estos son los casos en los que se requiere la optimización del rendimiento, el acceso y la agregación. [dieciséis]
- Capacidad de composición del servicio
- Los servicios se pueden utilizar para componer otros servicios.
- Descubrimiento de servicios
- Los servicios se complementan con metadatos comunicativos mediante los cuales se pueden descubrir e interpretar de manera eficaz.
- Reutilización del servicio
- La lógica se divide en varios servicios para promover la reutilización del código.
- Encapsulación de servicios
- Muchos servicios que no se planificaron inicialmente bajo SOA, pueden encapsularse o convertirse en parte de SOA.
Patrones
Cada bloque de creación de SOA puede desempeñar cualquiera de los tres roles:
- Proveedor de servicio
- Crea un servicio web y proporciona su información al registro de servicios. Cada proveedor debate sobre muchos cómo y por qué, como qué servicio exponer, a cuál dar más importancia: seguridad o fácil disponibilidad, a qué precio ofrecer el servicio y muchos más . El proveedor también tiene que decidir en qué categoría debe incluirse el servicio para un servicio de intermediario determinado [17] 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 funcionalidad es poner a disposición de cualquier potencial solicitante la información relativa al servicio web. Quien implementa el corredor decide el alcance del corredor. Los corredores públicos están disponibles en cualquier lugar y en todas partes, pero los corredores privados solo están disponibles para una cantidad limitada de público. UDDI fue uno de los primeros intentos de proporcionar descubrimiento de servicios web que ya no recibió apoyo activo .
- Solicitante / consumidor de servicios
- Localiza entradas en el registro del corredor mediante varias operaciones de búsqueda y luego se vincula con el proveedor de servicios para invocar uno de sus servicios web. Cualquiera que sea el servicio que necesiten los consumidores de servicios, deben llevarlo a los corredores, vincularlo con el servicio respectivo y luego usarlo. Pueden acceder a varios servicios si el servicio proporciona varios servicios.
La relación proveedor-consumidor de servicios se rige por un contrato de servicio estandarizado , [18] que tiene una zona de negocios, 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 continúan siendo relevantes y elegibles en el diseño SOA. [19] [20] [21]
Enfoques de implementación
La arquitectura orientada a servicios se puede implementar con servicios web o microservicios . [22] Esto se hace para que los bloques de construcción funcionales sean accesibles a través de protocolos estándar de Internet 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 habilitarlos para la red. [23]
Los implementadores suelen crear SOA utilizando estándares de servicios web. Un ejemplo es SOAP , que ha ganado una amplia aceptación en la industria tras la recomendación de la versión 1.2 del W3C [24] (World Wide Web Consortium) en 2003. Estos estándares (también denominados especificaciones de servicios web ) también proporcionan una mayor interoperabilidad y cierta protección contra bloqueo al software propietario del proveedor. Sin embargo, también se puede implementar SOA utilizando cualquier otra tecnología basada en servicios, como Jini , CORBA , REST o gRPC .
Las arquitecturas pueden operar 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
- HTTP RESTful, con transferencia de estado representacional (REST) que constituye su propio estilo arquitectónico basado en restricciones
- OPC-UA
- WCF (implementación de servicios web de Microsoft, que forma parte de WCF)
- Apache Thrift
- gRPC
- HECHICERO
Las implementaciones pueden usar uno o más de estos protocolos y, por ejemplo, pueden usar un mecanismo de sistema de archivos para comunicar datos siguiendo una especificación de interfaz definida entre procesos que cumplen con el concepto SOA. La clave son los servicios independientes con interfaces definidas que pueden ser llamados para realizar sus tareas de manera estándar, sin que un servicio tenga conocimiento previo de la aplicación que realiza la llamada, 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 crean mediante la combinación de servicios interoperables y de acoplamiento flexible .
Estos servicios interactúan basándose en 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 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 administrados también pueden envolver los sistemas heredados COBOL y presentarlos como servicios de software. . [25]
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 los arquitectos pueden a su vez incorporar en flujos de trabajo y procesos de negocio implementados en aplicaciones compuestas o portales .
El modelado orientado a servicios es un marco SOA que identifica las diversas disciplinas que guían a los profesionales de SOA a conceptualizar, analizar, diseñar y diseñar sus activos orientados a servicios. El marco de trabajo 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 los aspectos de "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 al servicio. SOMF también proporciona una notación de modelado común para abordar la alineación entre las organizaciones comerciales 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. [27] 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 existentes (heredados).
Con SOA, la idea es que una organización pueda considerar 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 al negocio. SOA también se ha ilustrado como un sistema de carreteras que proporciona eficiencia a los conductores de automóviles. El punto es que si todos tuvieran un automóvil, pero no hubiera una carretera en ningún lado, las cosas serían limitadas y desorganizadas, en cualquier intento de llegar a cualquier lugar de manera rápida o eficiente. El vicepresidente de servicios web de IBM, Michael Liebow, dice que SOA "construye carreteras". [28]
En algunos aspectos, SOA podría considerarse como una evolución arquitectónica más que como una revolución. Captura 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 enfatizar 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 autónoma de funcionalidad disponible solo a través de una interfaz definida formalmente. Los servicios pueden ser algún tipo de "nanoempresas" fáciles de producir y mejorar. También los servicios pueden ser "megacorporaciones" construidas 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:
- La separación promueve en la empresa el concepto de que los servicios se pueden entregar de forma rápida e independiente de los proyectos más grandes y de menor movimiento que son comunes en la organización. La empresa comienza a comprender los sistemas y las interfaces de usuario simplificadas que solicitan servicios. Esto aboga por la agilidad . Es decir, fomenta las innovaciones empresariales y acelera el tiempo de comercialización. [29]
- La separación promueve la disociación de los servicios de los proyectos consumidores. Esto fomenta el buen diseño en la medida en que el servicio se diseña sin saber quiénes son sus consumidores.
- La documentación y los artefactos de prueba del servicio no están integrados en los detalles del proyecto más grande. Esto es importante cuando es necesario reutilizar el servicio 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 apropiadamente, entonces se crea un stub correspondiente que reacciona a los datos de prueba cuando se está construyendo un servicio. También se captura un conjunto completo de pruebas de regresión, scripts, datos y respuestas para el servicio. El servicio se puede probar como una 'caja negra' utilizando los stubs existentes correspondientes a los servicios que llama. Se pueden construir entornos de prueba donde los servicios primitivos y fuera de alcance son stubs, 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 prueba 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. La gestión del estado de los datos de los servicios idempotentes es la única complejidad.
Los ejemplos pueden resultar útiles para ayudar a documentar un servicio al nivel en el que se vuelve útil. La documentación de algunas API dentro del Proceso de la comunidad de Java proporciona buenos ejemplos. Como estos son exhaustivos, el personal normalmente utilizaría solo subconjuntos importantes. El archivo 'ossjsa.pdf' dentro de JSR-89 ejemplifica tal archivo. [30]
Crítica
SOA se ha combinado con servicios web ; [31] 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 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 de XML de código abierto (como VTD-XML ) y varios formatos binarios compatibles con XML prometen mejorar significativamente el rendimiento de SOA. [32] [33] [34]
Los servicios con estado requieren que tanto el consumidor como el proveedor compartan el mismo contexto específico del consumidor, que se incluye o 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 el proveedor de servicios necesita retener el contexto compartido para cada consumidor. También aumenta el acoplamiento entre un proveedor de servicios y un consumidor y dificulta el cambio de proveedores de servicios. [35] En última instancia, algunos críticos sienten que los servicios SOA todavía están demasiado limitados por las aplicaciones que representan. [36]
Un desafío principal al que se 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 crea un gran problema de confianza. Por tanto, la gobernanza de SOA entra en el esquema de las cosas. [37]
Otro problema importante al que se enfrenta SOA es la falta de un marco de prueba uniforme. No existen herramientas que proporcionen las características necesarias para probar estos servicios en una arquitectura orientada a servicios. Las principales causas de dificultad son: [38]
- 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 proveedores diferentes y competidores.
- La plataforma cambia continuamente debido a la disponibilidad de nuevas funciones y servicios.
Extensiones y variantes
Arquitecturas impulsadas por 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 la web percibidas y en rápido crecimiento. [39] Un tema que ha experimentado una amplia cobertura es la relación entre la Web 2.0 y las arquitecturas orientadas a servicios. [ cual? ]
SOA es la filosofía de encapsular la lógica de la aplicación en los servicios con una interfaz definida uniformemente y hacer que estén disponibles públicamente a través de mecanismos de descubrimiento. La noción de ocultación de la complejidad y la reutilización, pero también el concepto de servicios de acoplamiento flexible, ha inspirado a los investigadores a profundizar en las 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 los dos conceptos como complementarios y consideran la Web 2.0 como la SOA global. [40]
Las filosofías de Web 2.0 y SOA satisfacen las diferentes necesidades de los usuarios y, por lo tanto, exponen las 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[actualizar], los casos de uso demostraron el potencial de combinar tecnologías y principios de Web 2.0 y SOA. [40]
Microservicios
Los microservicios son una interpretación moderna de las arquitecturas orientadas a servicios que se utilizan para construir sistemas de software distribuidos . Los servicios en una arquitectura de microservicios [41] 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 , [42] que ayudan a encapsular la elección del lenguaje y los marcos, haciendo de su elección 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. [43]
No existe una definición única de microservicios comúnmente acordada. Las siguientes características y principios se pueden encontrar en la literatura:
- interfaces detalladas (a servicios desplegables de forma independiente),
- desarrollo impulsado por negocios (por ejemplo , diseño impulsado por dominios ),
- Arquitecturas IDEALES de aplicaciones en la nube,
- programación políglota y persistencia,
- 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, computación y comunicación distribuidas optimizadas de baja latencia, así como administración de recursos e instancias. [44] [45] [46]
Ver también
- Interfaz de programación de aplicaciones
- Bajo acoplamiento
- Modelo de referencia SOA de OASIS
- Principio de granularidad del servicio
- Gobernanza SOA
- Arquitectura de software
- Comunicaciones orientadas a servicios (SOC)
- Desarrollo de aplicaciones orientado al servicio
- Aplicaciones distribuidas orientadas a servicios
Referencias
- ^ a b "Libro de fuentes de SOA - ¿Qué es SOA?" . Collaboration.opengroup.org . Consultado el 30 de marzo de 2021 .
- ^ "Capítulo 1: Arquitectura Orientada a Servicios (SOA)" . msdn.microsoft.com . Archivado desde el original el 7 de julio de 2017 . Consultado el 21 de septiembre de 2016 .
- ^ "Estándares de Arquitectura Orientada a Servicios - El Grupo Abierto" . www.opengroup.org .
- ^ "¿Qué es SOA?" . www.opengroup.org . Archivado desde el original el 19 de agosto de 2016 . Consultado el 21 de septiembre de 2016 .
- ^ Velte, Anthony T. (2010). Computación en la nube: un enfoque práctico . McGraw Hill. ISBN 978-0-07-162694-1.
- ^ "Migración a una arquitectura orientada a servicios, Parte 1" . 9 de diciembre de 2008. Archivado desde el original el 9 de diciembre de 2008 . Consultado el 21 de septiembre de 2016 .CS1 maint: bot: estado de URL original desconocido ( enlace )
- ^ a b Michael Bell (2008). "Introducción al Modelado Orientado a Servicios". Modelado orientado a servicios: análisis, diseño y arquitectura de servicios . Wiley & Sons. pag. 3 . ISBN 978-0-470-14111-3.
- ^ Michael Bell (2010). Patrones de modelado SOA para análisis y descubrimiento orientados a servicios . Wiley & Sons. pag. 390 . ISBN 978-0-470-48197-4.
- ^ "Manifiesto SOA" . www.soa-manifesto.org . Consultado el 21 de septiembre de 2016 .
- ^ Thomas Erl (junio de 2005). Sobre los Principios . Serviceorientation.org
- ^ "Blog de estrategias de plataforma de aplicaciones: SOA ha muerto; Larga vida a los servicios" . Apsblog.burtongroup.com. 5 de enero de 2009. Archivado desde el original el 15 de enero de 2009 . Consultado el 13 de agosto de 2012 .
- ^ Yvonne Balzer Mejore sus planes de proyecto SOA , IBM , 16 de julio de 2004
- ^ Equipo de Microsoft Windows Communication Foundation (2012). "Principios del Diseño Orientado a Servicios" . msdn.microsoft.com . Consultado el 3 de septiembre de 2012 .
- ^ Principios de Thomas Erl de SOA Systems Inc. ocho principios específicos de orientación al servicio
- ^ M. Hadi Valipour; Bavar AmirZafari; Kh. Niki Maleki; Negin Daneshpour (2009). "Un breve estudio de los conceptos de arquitectura de software y arquitectura orientada a servicios". 2009 2ª Conferencia Internacional IEEE sobre Ciencias de la Computación y Tecnología de la Información . págs. 34–38. doi : 10.1109 / ICCSIT.2009.5235004 . ISBN 978-1-4244-4519-6. S2CID 14980694 .
- ^ Tony Shan (2004). "Construcción de una plataforma de banca electrónica orientada a servicios ". Conferencia Internacional IEEE sobre Computación de Servicios , 2004. (SCC 2004). Actas. 2004 . págs. 237–244. doi : 10.1109 / SCC.2004.1358011 . ISBN 978-0-7695-2225-8. S2CID 13156128 .2004
- ^ Duan, Yucong; Narendra, Nanjangud; Du, Wencai; Wang, Yongzhi; Zhou, Nianjun (2014). "Exploración de la intermediación de servicios en la nube desde una perspectiva de interfaz". 2014 IEEE International Conference on Web Services . IEEE . págs. 329–336. doi : 10.1109 / ICWS.2014.55 . ISBN 978-1-4799-5054-6. S2CID 17957063 .
- ^ Duan, Yucong (2012). "Una encuesta sobre el contrato de servicios". 2012 XIII Congreso Internacional ACIS sobre Ingeniería de Software, Inteligencia Artificial, Redes y Computación Paralela / Distribuida . IEEE . págs. 805–810. doi : 10.1109 / SNPD.2012.22 . ISBN 978-1-4673-2120-4. S2CID 1837914 .
- ^ Olaf Zimmermann, Cesare Pautasso, Gregor Hohpe, Bobby Woolf (2016). "Una década de patrones de integración empresarial". Software IEEE . 33 (1): 13-19. doi : 10.1109 / MS.2016.11 .CS1 maint: varios nombres: lista de autores ( enlace )
- ^ Rotem-Gal-Oz, Arnon (2012). Patrones SOA . Publicaciones Manning. ISBN 978-1933988269.
- ^ Julisch, Klaus; Suter, Christophe; Woitalla, Thomas; Zimmermann, Olaf (2011). "Cumplimiento por diseño: superando el abismo entre auditores y arquitectos de TI" (PDF) . Computadoras y seguridad . 30 (6–7): 410–426. CiteSeerX 10.1.1.390.3652 . doi : 10.1016 / j.cose.2011.03.005 .
- ^ Brandner, M., Craes, M., Oellermann, F., Zimmermann, O., Arquitectura orientada a servicios web en producción en la industria financiera, Informatik-Spektrum 02/2004, Springer-Verlag, 2004
- ^ "www.ibm.com" . Consultado el 10 de septiembre de 2016 .
- ^ "SOAP Version 1.2 の 公開 に つ い て (W3C 勧 告)" (en japonés). W3.org . Consultado el 13 de agosto de 2012 .
- ^ Okishima, Haruhiru (2006). "." Estudio de caso de arquitectura de sistemas que utilizan activos COBOL " " (PDF) .
- ^ Enterprise SOA . Prentice Hall, 2005
- ^ Christopher Koch A New Blueprint For The Enterprise , CIO Magazine , 1 de marzo de 2005
- ^ Elizabeth Millard (enero de 2005). "Construyendo un mejor proceso". Usuario de computadora . Página 20.
- ^ Brayan Zimmerli (11 de noviembre de 2009) Beneficios comerciales de SOA , Universidad de Ciencias Aplicadas del Noroeste de Suiza, Escuela de Negocios
- ^ JSR-000089 OSS Service Activation API Specification 1.0 Final Release . sun.com
- ^ Joe McKendrick. "Bray: SOA demasiado complejo; 'solo BS del proveedor ' " . ZDNet.
- ^ Jimmy Zhang (20 de febrero de 2008) "Documentos XML de índice con VTD-XML" Archivado el 4 de julio de 2008 en Wayback Machine . XML Journal .
- ^ Jimmy Zhang (5 de agosto de 2008) "Punto de vista de i-Technology: La desgracia de rendimiento de XML binario" . Revista de microservicios .
- ^ Jimmy Zhang (9 de enero de 2008) "Manipular contenido XML a la manera Ximple" . devx.com .
- ^ "La razón por la que SOA no ofrece software sostenible" . jpmorgenthal.com. 19 de junio de 2009 . Consultado el 27 de junio de 2009 .
- ^ "Los servicios SOA todavía están demasiado limitados por las aplicaciones que representan" . zdnet.com. 27 de junio de 2009 . Consultado el 27 de junio de 2009 .
- ^ "Capa de gobernanza" . www.opengroup.org . Consultado el 22 de septiembre de 2016 .
- ^ "Cómo probar eficientemente la arquitectura orientada a servicios | WSO2 Inc" . wso2.com . Consultado el 22 de septiembre de 2016 .
- ^ "Qué es la Web 2.0" . Tim O'Reilly. 30 de septiembre de 2005 . Consultado el 10 de junio de 2008 .
- ^ a b Christoph Schroth; Hasta Janner (2007). "Web 2.0 y SOA: conceptos convergentes que habilitan la Internet de los servicios" . Profesional de TI . 9 (3): 36–41. doi : 10.1109 / MITP.2007.60 . S2CID 2859262 . Consultado el 23 de febrero de 2008 .
- ^ Dragoni, Nicola; Giallorenzo, Saverio; Alberto Lluch Lafuente; Mazzara, Manuel; Montesi, Fabrizio; Mustafin, Ruslan; Safina, Larisa (2016). "Microservicios: ayer, hoy y mañana". arXiv : 1606.04036v1 [ cs.SE ].
- ^ James Lewis y Martin Fowler. "Microservicios" .
- ^ Balalaie, A .; Heydarnoori, A .; Jamshidi, P. (1 de mayo de 2016). "La arquitectura de microservicios permite DevOps: migración a una arquitectura nativa de la nube" (PDF) . Software IEEE . 33 (3): 42–52. doi : 10.1109 / MS.2016.64 . hdl : 10044/1/40557 . ISSN 0740-7459 . S2CID 18802650 .
- ^ Frank Glinka; Allaithy Raed (2009). "Una interfaz orientada a servicios para aplicaciones distribuidas altamente interactivas" . Conferencia europea sobre procesamiento paralelo . Apuntes de conferencias en Ciencias de la Computación. 6043 : 266–277. doi : 10.1007 / 978-3-642-14122-5_31 . ISBN 978-3-642-14121-8. Consultado el 9 de febrero de 2021 .
- ^ Dieter Hildebrandt; Jan Klimke (2011). "Visualización 3D interactiva orientada a servicios de modelos masivos de ciudades 3D en clientes ligeros" . COM.Geo '11: Actas de la 2ª Conferencia Internacional sobre Computación para Investigaciones y Aplicaciones Geoespaciales : 1. doi : 10.1145 / 1999320.1999326 . ISBN 9781450306812. S2CID 53246415 . Consultado el 9 de febrero de 2021 .
- ^ Mahy Aly; Michael Franke (2016). "Motores de medios interactivos orientados a servicios (SOIM) habilitados por recursos compartidos optimizados" . Simposio IEEE 2016 sobre ingeniería de sistemas orientados a servicios (SOSE) : 231–237. doi : 10.1109 / SOSE.2016.47 . hdl : 1854 / LU-7215326 . ISBN 978-1-5090-2253-3. S2CID 9511734 . Consultado el 9 de febrero de 2021 .