Gobierno de arquitecturas híbridas REST y GRAPHQL basadas en acuerdos de nivel de servicio

• Autores: José Antonio Quiña Mera
• Directores de la Tesis: Pablo Fernández Montes (dir. tes.) , José María García Rodríguez (dir. tes.)
• Lectura: En la Universidad de Sevilla ( España ) en 2022
• Idioma: español
• Número de páginas: 297
• Enlaces
  • Tesis en acceso abierto en: Idus
• Resumen
  • español

    En la actualidad, los proveedores de software tienen el reto de construir soluciones informáticas fiables y eficientes que superen cuestiones técnicas y funcionales esenciales como la redundancia, la recuperación y la escalabilidad para proporcionar servicios en la nube o servicios multi tenencia. La arquitectura de microservicios (MSA, por sus siglas en inglés de MicroService Architecture) representa una clara tendencia para superar estos retos, tanto en el ámbito académico como en el industrial, por lo que, grandes empresas de todo el mundo han evolucionado sus aplicaciones hacia este estilo arquitectónico. En concreto, MSA se compone de pequeñas aplicaciones (microservicios) con una única responsabilidad (requisitos funcionales, no funcionales, o transversales) que pueden desplegarse, escalarse y probarse de forma independiente. Los microservicios se comunican a través de mecanismos ligeros, por lo general utilizando el estilo arquitectónico REST para construir interfaces de programación de aplicaciones (API, por sus siglas en inglés de Application Programming Interface) denominadas API REST. Las organizaciones de software han adoptado rápidamente las APIs REST en el desarrollo de sus aplicaciones tras su creación en el año 2000, y aunque es el paradigma más utilizado en el desarrollo de microservicios, ha presentado algunos problemas de acceso a los datos, tales como: i) La complejidad de la consulta, es decir, REST requiere múltiples peticiones HTTP para obtener múltiples recursos. ii) El over-fetching ocurre cuando la solicitud a una API REST devuelve más datos de los que el cliente necesita. iii) El under-fetching, ocurre cuando un punto final concreto de una API no devuelve suficiente información, y hay que hacer solicitudes adicionales para obtener la información necesaria. En este sentido, se ha observado que en la última década han surgido varias alternativas para acceder a datos desde APIs como SPARQL, Cypher, Gremlin, y GraphQL. En donde, GraphQL ha conseguido una creciente aplicación e interés en la academia e industria; y según varios estudios se muestra como una alternativa para resolver varios problemas encontrados en las API REST tradicionales. En este sentido, en la presente memoria se ha identificado la necesidad, por un lado, de evaluar adecuadamente las ventajas e inconvenientes de utilizar, e integrar la tecnología de GraphQL con la existente REST en una arquitectura híbrida REST/GraphQL. Las cuales se estudiaron mediante la implementación de una API GraphQL pasarela que reutiliza como fuente de datos la infraestructura de las APIs REST existentes; a esta práctica se la conoce comúnmente como envoltorios. Por otro lado, se identificó también la necesidad de fomentar la gobernanza de arquitecturas híbridas REST y GraphQL basadas en acuerdos de nivel de servicio. Debido a lo antes expuesto, este trabajo se estructuró en doce capítulos que se agruparon en seis partes. Parte I: Introducción, contiene el planteamiento del problema y la metodología de investigación. Parte II: Estado de la cuestión, contiene básicamente el estado de GraphQL y los acuerdos de nivel de servicios. Parte III: Propuesta, contiene, por un lado, dos diseños experimentales para comprobar los efectos de las arquitecturas REST, GraphQL, e híbrida REST/GraphQL en la calidad de software. Por otro lado, la descripción de un estándar denominado SLA4GraphQL para modelar y operativizar acuerdos de nivel de servicio (SLA) para APIs GraphQL. Parte IV: Validación, contiene la validación de las propuestas expuestas en la parte III. Parte V: Conclusiones del estudio. Y finalmente Parte VI: Anexos. La importancia de elaborar el estándar SLA4GraphQL para modelar y operativizar SLA ha sido motivado por tres aspectos. Primero, debido a que no existe en la comunidad científica una propuesta para modelar y operativizar acuerdos de nivel de servicio de una manera estandarizada. Segundo la importancia de proponer un ciclo de vida para el desarrollo de APIs basado en SLA. Tercero facilitar una herramienta que valide la especificación de documentos SLA basados en un estándar. La validación del estándar SLA4GraphQL consistió en evaluar la viabilidad, flexibilidad y la idoneidad funcional mediante la instanciación del estándar en varios casos de APIs públicas. El resultado de la validación indica que el estándar SLA4GraphQL es viable, flexible, y tiene una idoneidad del 92.33% para modelar acuerdos de nivel de servicios para APIs GraphQL.

  • English

    Currently, software providers are challenged to build reliable and efficient IT solutions that overcome critical technical and functional issues such as redundancy, recovery, and scalability to provide cloud or multi-tenancy services. Microservice Architecture (MSA) represents a clear trend to overcome these challenges, both in academia and industry, so large companies worldwide have evolved their applications towards this architectural style. Specifically, MSA comprises small applications (microservices) with a single responsibility (functional, non-functional, or cross-cutting requirements) that can be deployed, scaled, and tested independently. Microservices communicate through lightweight mechanisms, typically using the REST architectural style to build Application Programming Interfaces (APIs) called REST APIs. Software organizations have rapidly adopted REST APIs in their application development after its inception in 2000. Although it is the most widely used paradigm in microservices development, it has presented some data access issues, such as i) Query complexity, i.e., REST requires multiple HTTP requests to fetch various resources. ii) Over-fetching occurs when the request to a REST API returns more data than the client needs. iii) Under-fetching occurs when a particular endpoint of an API does not return enough information, and additional requests have to be made to obtain the required information. In this sense, we have observed that in the last decade, several alternatives have emerged to access data from APIs such as SPARQL, Cypher, Gremlin, and GraphQL. GraphQL has achieved a growing application and interest in academia and industry. Several studies show it as an alternative to solve several problems encountered in traditional REST APIs. In this sense, this memory has identified the need, on the one hand, to properly evaluate the advantages and disadvantages of using and integrating GraphQL technology with existing REST technology in a hybrid REST/GraphQL architecture. We studied these through implementing a GraphQL API gateway that reuses the existing REST APIs infrastructure as a data source; this practice is known as wrappers. On the other hand, we also identified the need to promote the governance of hybrid REST and GraphQL architectures based on service-level agreements. Due to the above, we structured this work into twelve chapters in six parts. Part I: Introduction, contains the problem statement and the research methodology. Part II: State of the art, basically includes the state of GraphQL and service level agreements. Part III: Proposal, contains, on the one hand, two experimental designs to test the effects of REST, GraphQL, and hybrid REST/GraphQL architectures on software quality. On the other hand, the description of a standard called SLA4GraphQL for modeling and operationalizing service level agreements (SLA) for GraphQL APIs. Part IV: Validation, contains the validation of the proposals presented in Part III. Part V: Conclusions of the study. And finally, Part VI: Annexes. The importance of developing a standard for modeling and operationalizing SLA has been motivated by three aspects. First, there is no proposal in the scientific community to model and operationalize SLAs in a standardized way. Second, the importance of proposing a lifecycle for API development based on SLAs. Third, to provide a tool to validate the specification of SLA documents based on a standard. The validation of the SLA4GraphQL standard consisted of assessing the feasibility, flexibility, and functional suitability by instantiating the standard in several instances of public APIs. The result of the validation indicates that the SLA4GraphQL standard is feasible, flexible, and has suitability of 92.33% for modeling service level agreements for GraphQL APIs.