stringtranslate.com

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] La SOA es una buena opción para la integración de sistemas . [2] En consecuencia, también se aplica en el campo del diseño de software , donde los servicios se proporcionan a los otros componentes por los componentes de la aplicación , a través de un protocolo de comunicación sobre una red. Un servicio es una unidad discreta de funcionalidad a la que se puede acceder de forma remota y se puede actuar sobre ella y actualizarla de forma independiente, como recuperar un extracto de tarjeta de crédito en línea. La 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 comercial repetible con un resultado específico.
  2. Es autónomo.
  3. Es una caja negra para sus consumidores, lo que significa que el consumidor no tiene que 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 gran aplicación de software , [6] 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. Es posible gracias a 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 está relacionada con la idea de 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 pensar en una API como el servicio y en SOA como la arquitectura que permite que el servicio funcione.

Tenga en cuenta que la arquitectura orientada a servicios no debe confundirse con la arquitectura basada en servicios, ya que son dos estilos arquitectónicos diferentes. [7]

Descripción general

En SOA, los servicios utilizan protocolos que describen cómo pasan y analizan los mensajes mediante 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 construyen exclusivamente a partir de servicios existentes y combinarlos de manera ad hoc. Un servicio presenta una interfaz simple para el solicitante que abstrae la complejidad subyacente actuando como una caja negra. Además, los usuarios también pueden acceder a estos servicios independientes sin ningún conocimiento de su implementación interna. [8]

Definición de conceptos

La palabra de moda relacionada con la orientación a servicios promueve el acoplamiento flexible entre servicios. SOA separa las funciones en unidades o servicios distintos [9] , que los desarrolladores hacen accesibles a través de una red para permitir que los usuarios los combinen y reutilicen en la producción de aplicaciones. Estos servicios y sus correspondientes consumidores se comunican entre sí mediante el paso de datos en un formato compartido bien definido o mediante la coordinación de una actividad entre dos o más servicios [10] .

SOA puede verse como parte de un continuo que va desde el concepto más antiguo de computación distribuida [9] [11] y programación modular , pasando por SOA, hasta las prácticas de mashups , SaaS y computación en la nube (que algunos ven como la descendencia de SOA). [12]

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 ellos [13] [14] [15] incluyen los siguientes:

Contrato de servicio estandarizado [16]
Los servicios se adhieren a un acuerdo de comunicaciones estándar, según se define colectivamente en uno o más documentos de descripción de servicios dentro de un conjunto determinado de servicios.
Autonomía de referencia del servicio (un aspecto del acoplamiento flexible)
La relación entre los servicios se minimiza hasta el punto en que sólo son conscientes de su existencia.
Transparencia en la ubicación del servicio (un aspecto del acoplamiento flexible)
Los servicios pueden ser llamados desde cualquier lugar dentro de la red en la que se encuentren, sin importar dónde estén presentes.
Longevidad del servicio
Los servicios deben diseñarse para que duren mucho tiempo. Siempre que sea posible, los servicios deben evitar obligar a los consumidores a cambiar si no necesitan 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, minimizando así el uso de recursos.
Granularidad del servicio
Un principio para garantizar que los servicios tengan un tamaño y un alcance adecuados. La funcionalidad que el servicio ofrece al usuario debe ser relevante.
Normalización de servicios
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 la optimización del rendimiento, el acceso y la agregación. [17]
Componibilidad de servicios
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 fueron planificados inicialmente bajo SOA pueden encapsularse o convertirse en parte de SOA.

Patrones

Cada bloque de construcción 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 muchos aspectos, como qué servicio exponer, a qué dar más importancia: seguridad o disponibilidad, qué precio ofrecer por el servicio y muchos más . El proveedor también tiene que decidir en qué categoría debe figurar el servicio para un servicio de corretaje determinado [18] y qué tipo de acuerdos con socios comerciales se requieren para utilizar el servicio.
Broker de servicios, registro de servicios o repositorio de servicios
Su principal funcionalidad es poner a disposición de cualquier solicitante potencial la información relativa al servicio web. Quien implemente el broker decide el alcance del mismo. Los brokers públicos están disponibles en cualquier lugar, pero los privados solo están disponibles para una cantidad limitada de público. UDDI fue un intento temprano, que ya no cuenta con soporte activo, de proporcionar detección de servicios web .
Solicitante/consumidor de servicios
Localiza entradas en el registro del corredor mediante diversas operaciones de búsqueda y luego se vincula al proveedor de servicios para invocar uno de sus servicios web. Cualquiera sea el servicio que necesiten los consumidores del servicio, deben llevarlo a los corredores, vincularlo 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 , [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 vinculados a un estilo arquitectónico en particular siguen siendo relevantes y elegibles en el diseño de SOA. [20] [21] [22]

Enfoques de implementación

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 que sean independientes de plataformas y lenguajes de programación. Estos servicios pueden representar nuevas aplicaciones o simplemente envoltorios de sistemas heredados existentes para que sean compatibles con la red. [24]

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 después de la recomendación de la versión 1.2 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 el bloqueo de software de proveedores propietarios. 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:

Las implementaciones pueden utilizar uno o más de estos protocolos y, por ejemplo, pueden 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 las que se puede llamar para que realicen sus tareas de forma 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 saber cómo realiza realmente sus tareas el servicio. SOA permite el desarrollo de aplicaciones que se construyen combinando servicios interoperables y poco acoplados .

Estos servicios interoperan en base a 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 administrados también pueden encapsular sistemas heredados de COBOL y presentarlos como servicios de software. . [26]

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 de grano fino en servicios comerciales de grano grueso, que los arquitectos pueden a su vez incorporar en flujos de trabajo y procesos comerciales implementados en aplicaciones compuestas o portales .

El modelado orientado a servicios es un marco de trabajo SOA que identifica las distintas 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 trabajo de modelado orientado a servicios (SOMF) ofrece un lenguaje de modelado y una estructura de trabajo o "mapa" que representa los distintos 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 diseñar 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 comerciales y de TI.

Elementos de SOA, por Dirk Krafzig, Karl Banke y Dirk Slama [27]
Metamodelo SOA, The Linthicum Group, 2007

Beneficios organizacionales

Algunos arquitectos empresariales creen que la SOA puede ayudar a las empresas a responder con mayor rapidez y de manera más 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 con los activos de TI existentes (heredados) y su uso.

Con SOA, la idea es que una organización pueda analizar un problema de manera holística. Una empresa tiene un mayor control general. Teóricamente, no habría una masa de desarrolladores que utilizarían cualquier conjunto de herramientas que les pareciera conveniente, sino que 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. El punto es que si todos tuvieran un automóvil, pero no hubiera autopistas en ninguna parte, las cosas estarían limitadas y desorganizadas, en cualquier intento de llegar a algún lugar de manera rápida o eficiente. El vicepresidente de servicios web de IBM, Michael Liebow, dice que SOA "construye autopistas". [29]

En algunos aspectos, SOA podría considerarse una evolución arquitectónica más que 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 enfatizar la importancia de las 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 de funcionalidad independiente disponible únicamente a través de una interfaz definida formalmente. Los servicios pueden ser algún tipo de "nanoempresas" que son fáciles de producir y mejorar. También 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:

  1. 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 ritmo que son comunes en la organización. La empresa comienza a comprender los sistemas y las interfaces de usuario simplificadas que requieren servicios. Esto promueve la agilidad , es decir, fomenta las innovaciones empresariales y acelera el tiempo de comercialización. [30]
  2. La separación promueve la disociación de los servicios de los proyectos de consumo, lo que fomenta el buen diseño en la medida en que el servicio se diseña sin saber 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 más amplio. Esto es importante cuando es necesario reutilizar el servicio más adelante.

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 los datos de prueba cuando se crea 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 stubs existentes correspondientes a los servicios 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. 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 documentar un servicio hasta el nivel en que se vuelve útil. La documentación de algunas API dentro del Proceso de la Comunidad Java ofrece buenos ejemplos. Como son exhaustivos, el personal normalmente utilizaría solo subconjuntos importantes. El archivo 'ossjsa.pdf' dentro de JSR-89 ejemplifica un archivo de este tipo. [31]

Crítica

SOA se ha confundido con los servicios web ; [32] sin embargo, los servicios web son solo una opción para implementar los patrones que comprenden 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 aumenta 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 procedimiento remoto 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. [33] [34] [35]

Los servicios con estado requieren que tanto el consumidor como el proveedor compartan el mismo contexto específico del consumidor, que se incluye en los mensajes intercambiados entre el proveedor y el consumidor o se hace referencia a ellos en ellos. 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 un proveedor de servicios y un consumidor y dificulta el cambio de proveedores de servicios. [36] En última instancia, algunos críticos creen que los servicios SOA todavía están demasiado limitados por las aplicaciones que representan. [37]

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 a que el diseño puede implicar que varios servicios trabajen 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 enorme problema de confianza. De este modo, la gobernanza de SOA entra en escena. [38]

Otro de los principales problemas que 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 dificultad son: [39]

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 percibido y de rápido crecimiento de aplicaciones basadas en la Web. [40] Un tema que ha experimentado una amplia cobertura involucra la relación entre la Web 2.0 y las arquitecturas orientadas a servicios. [ ¿cuál? ]

SOA es la filosofía de encapsular la lógica de la aplicación en servicios con una interfaz definida de manera uniforme y ponerlos a disposición del público mediante mecanismos de descubrimiento. La noción de ocultamiento de la complejidad y reutilización, pero también el concepto de servicios acoplados de manera flexible, ha inspirado a los investigadores a elaborar las similitudes entre las dos filosofías, SOA y Web 2.0, y sus respectivas aplicaciones. Algunos sostienen que 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 a Web 2.0 como la SOA global. [41]

Las filosofías de la Web 2.0 y SOA atienden distintas necesidades de los usuarios y, por lo tanto, presentan diferencias con respecto al diseño y también a las tecnologías utilizadas en 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 la Web 2.0 como de SOA. [41]

Microservicios

Los microservicios son una interpretación moderna de las arquitecturas orientadas a servicios que se utilizan para crear sistemas de software distribuidos . Los servicios en una arquitectura de microservicios [42] 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 [43] que ayudan a encapsular la elección del lenguaje y los marcos de trabajo, lo que hace 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 [44] .

No existe una única definición de microservicios aceptada por todos. En la literatura se pueden encontrar las siguientes características y principios:

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 orientadas a servicios específicas que abordan las necesidades específicas de este tipo de aplicaciones. Estas incluyen, por ejemplo, computación y comunicación distribuidas optimizadas de baja latencia, así como gestión de recursos e instancias. [45] [46] [47]

Véase también

Referencias

  1. ^ ab "Libro de fuentes de SOA: ¿Qué es SOA?". collaborative.opengroup.org . Consultado el 30 de marzo de 2021 .
  2. ^ Fundamentos de la arquitectura de software: un enfoque de ingeniería . O'Reilly Media. 2020. ISBN 978-1492043454.
  3. ^ "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 .
  4. ^ "Estándares de arquitectura orientada a servicios - The Open Group". www.opengroup.org .
  5. ^ "¿Qué es SOA?". www.opengroup.org . Archivado desde el original el 19 de agosto de 2016 . Consultado el 21 de septiembre de 2016 .
  6. ^ Velte, Anthony T. (2010). Computación en la nube: un enfoque práctico . McGraw Hill. ISBN 978-0-07-162694-1.
  7. ^ Fundamentos de la arquitectura de software: un enfoque de ingeniería . O'Reilly Media. 2020. ISBN 978-1492043454.
  8. ^ "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 .{{cite web}}: CS1 maint: bot: estado de URL original desconocido ( enlace )
  9. ^ de Michael Bell (2008). "Introducción al modelado orientado a servicios". Modelado orientado a servicios: análisis, diseño y arquitectura de servicios . Wiley & Sons. pág. 3. ISBN 978-0-470-14111-3.
  10. ^ Michael Bell (2010). Patrones de modelado SOA para el descubrimiento y análisis orientados a servicios . Wiley & Sons. pág. 390. ISBN 978-0-470-48197-4.
  11. ^ Thomas Erl (junio de 2005). Acerca de los principios . Serviceorientation.org
  12. ^ "Blog de estrategias de plataformas de aplicaciones: SOA ha muerto; vivan 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 .
  13. ^ Yvonne Balzer Mejore sus planes de proyecto SOA, IBM , 16 de julio de 2004
  14. ^ Equipo de Microsoft Windows Communication Foundation (2012). "Principios del diseño orientado a servicios". msdn.microsoft.com . Consultado el 3 de septiembre de 2012 .
  15. ^ Principios de Thomas Erl de SOA Systems Inc. ocho principios específicos de orientación al servicio
  16. ^ "4.4 Pautas para el uso de tecnologías de contratos de servicios web: anatomía de un contrato de servicios web". InformIT . 11 de junio de 2021 . Consultado el 9 de septiembre de 2021 .
  17. ^ Tony Shan (2004). "Construcción de una plataforma de banca electrónica orientada a servicios". IEEE International Conference on Services Computing, 2004. (SCC 2004). Actas. 2004. págs. 237–244. doi :10.1109/SCC.2004.1358011. ISBN 978-0-7695-2225-8.S2CID13156128  .​2004
  18. ^ Duan, Yucong; Narendra, Nanjangud; Du, Wencai; Wang, Yongzhi; Zhou, Nianjun (2014). "Explorando la intermediación de servicios en la nube desde una perspectiva de interfaz". Conferencia internacional IEEE sobre servicios web de 2014. IEEE . págs. 329–336. doi :10.1109/ICWS.2014.55. ISBN . 978-1-4799-5054-6.S2CID 17957063  .
  19. ^ Duan, Yucong (2012). "Una encuesta sobre contratos de servicios". 2012 13.ª Conferencia 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. Número de identificación del sujeto  1837914.
  20. ^ Olaf Zimmermann, Cesare Pautasso, Gregor Hohpe, Bobby Woolf (2016). "Una década de patrones de integración empresarial". IEEE Software . 33 (1): 13–19. doi : 10.1109/MS.2016.11 .{{cite journal}}: CS1 maint: varios nombres: lista de autores ( enlace )
  21. ^ Rotem-Gal-Oz, Arnon (2012). Patrones SOA . Publicaciones Manning. ISBN 978-1933988269.
  22. ^ Julisch, Klaus; Suter, Christophe; Woitalla, Thomas; Zimmermann, Olaf (2011). "Cumplimiento por diseño: cerrando la brecha entre auditores y arquitectos de TI" (PDF) . Computers & Security . 30 (6–7): 410–426. CiteSeerX 10.1.1.390.3652 . doi :10.1016/j.cose.2011.03.005. 
  23. ^ 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
  24. ^ "www.ibm.com". IBM . Consultado el 10 de septiembre de 2016 .
  25. ^ "SOAP Versión 1.2 の公開について (W3C 勧告)" (en japonés). W3.org. 24 de junio de 2003 . Consultado el 13 de agosto de 2012 .
  26. ^ Okishima, Haruhiru (2006). "Estudio de caso de arquitectura de sistemas que utilizan activos COBOL"" (PDF) .
  27. ^ SOA empresarial . Prentice Hall, 2005
  28. ^ Christopher Koch Un nuevo modelo para la empresa Archivado el 16 de enero de 2009 en Wayback Machine , CIO Magazine , 1 de marzo de 2005
  29. ^ Elizabeth Millard (enero de 2005). "Construyendo un mejor proceso". Usuario de computadora . Página 20.
  30. ^ Brayan Zimmerli (11 de noviembre de 2009) Beneficios empresariales de SOA, Universidad de Ciencias Aplicadas del Noroeste de Suiza, Facultad de Negocios
  31. ^ "JSR-000089 OSS Service Activation API Specification 1.0 Final Release". 26 de julio de 2011. Archivado desde el original el 26 de julio de 2011. Consultado el 18 de mayo de 2024 .
  32. ^ Joe McKendrick. "Bray: SOA es demasiado compleja; 'solo mentiras del proveedor'". ZDNet.
  33. ^ Jimmy Zhang (20 de febrero de 2008) "Indexar documentos XML con VTD-XML" Archivado el 4 de julio de 2008 en Wayback Machine . XML Journal .
  34. ^ Jimmy Zhang (5 de agosto de 2008) "Punto de vista de la tecnología de la información: el problema del rendimiento del XML binario" Archivado el 9 de enero de 2020 en Wayback Machine . Microservices Journal .
  35. ^ Jimmy Zhang (9 de enero de 2008) "Manipular contenido XML al estilo Ximple" Archivado el 30 de julio de 2017 en Wayback Machine . devx.com .
  36. ^ "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 .
  37. ^ "Los servicios SOA todavía están demasiado limitados por las aplicaciones que representan". ZDNet . 27 de junio de 2009 . Consultado el 27 de junio de 2009 .
  38. ^ "Capa de gobernanza". www.opengroup.org . Archivado desde el original el 4 de junio de 2016 . Consultado el 22 de septiembre de 2016 .
  39. ^ "Cómo probar de manera eficiente la arquitectura orientada a servicios | WSO2 Inc". wso2.com . Consultado el 22 de septiembre de 2016 .
  40. ^ "¿Qué es la Web 2.0?". Tim O'Reilly. 30 de septiembre de 2005. Consultado el 10 de junio de 2008 .
  41. ^ ab Christoph Schroth; Till Janner (2007). "Web 2.0 y SOA: conceptos convergentes que posibilitan la Internet de los servicios". IT Professional . 9 (3): 36–41. doi :10.1109/MITP.2007.60. S2CID  2859262. Archivado desde el original el 3 de diciembre de 2013 . Consultado el 23 de febrero de 2008 .
  42. ^ Dragoni, Nicola; Giallorenzo, Saverio; Alberto Lluch Lafuente; Mazzara, Manuel; Montesi, Fabricio; Mustafin, Ruslán; Safina, Larisa (2016). "Microservicios: ayer, hoy y mañana". arXiv : 1606.04036v1 [cs.SE].
  43. ^ James Lewis y Martin Fowler. "Microservicios".
  44. ^ 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) . IEEE Software . 33 (3): 42–52. doi :10.1109/MS.2016.64. hdl : 10044/1/40557 . ISSN  0740-7459. S2CID  18802650.
  45. ^ Frank Glinka; Allaithy Raed (2009). "Una interfaz orientada a servicios para aplicaciones distribuidas altamente interactivas". Conferencia Europea sobre Procesamiento Paralelo . Apuntes de clase en Ciencias de la Computación. Vol. 6043. págs. 266–277. doi :10.1007/978-3-642-14122-5_31. ISBN 978-3-642-14121-8. Recuperado el 9 de febrero de 2021 .
  46. ^ Dieter Hildebrandt; Jan Klimke (2011). "Visualización tridimensional interactiva orientada a servicios de modelos masivos de ciudades tridimensionales en clientes ligeros". COM.Geo '11: Actas de la 2.ª Conferencia Internacional sobre Informática para la Investigación y Aplicaciones Geoespaciales . p. 1. doi :10.1145/1999320.1999326. ISBN 9781450306812. S2CID  53246415 . Consultado el 9 de febrero de 2021 .
  47. ^ Mahy Aly; Michael Franke (2016). "Motores de medios interactivos orientados a servicios (SOIM) habilitados por el uso compartido optimizado de recursos". Simposio IEEE de 2016 sobre ingeniería de sistemas orientados a servicios (SOSE). págs. 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 .
Escuche este artículo ( 54 minutos )
Icono de Wikipedia hablado
Este archivo de audio se creó a partir de una revisión de este artículo con fecha del 27 de octubre de 2011 y no refleja ediciones posteriores. ( 27 de octubre de 2011 )