Gobierno de APIs REST basado en SLAs

ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA INFORMÁTICA Trabajo de Fin de Grado Grado en Ingeniería Informática – Tecnologías Informáticas G OBIERNO DE API S REST BASADO EN SLA S Realizado por A NTONIO G ÁMEZ D ÍAZ Dirigido por P ABLO F ERNÁNDEZ M ONTES Departamento L ENGUAJES Y S ISTEMAS I NFORMÁTICOS Sevilla, 2 de junio de 2015 Publicado en mayo 2015 por Antonio Gámez Díaz Copyright © MMXV http://personal.us.es/agamez2 [email protected] Esta obra está licenciada bajo la Licencia Creative Commons Atribución-CompartirIgual 4.0 Internacional. Para ver una copia de esta licencia, visita http://creativecommons.org/licenses/by-sa/4.0 Yo, D. Antonio Gámez Díaz con NIF número 77808176G, DECLARO mi autoría del trabajo que se presenta en la memoria de este trabajo fin de grado que tiene por título: Gobierno de APIs REST basado en SLAs Lo cual firmo, Fdo. D. Antonio Gámez Díaz en la Universidad de Sevilla 27/05/2015 Dedicado mi madre, Rosi. Sin todo su esfuerzo no hubiera llegado nunca hasta donde estoy. Gracias por todo. AGRADECIMIENTOS I Quisiera agradecer a varias personas y entidades la ayuda que me han prestado en la realización de este Trabajo de Fin de Grado. Entre ellas, y en primer lugar, a mi tutor, Pablo Fernández, por todas las horas de reuniones y revisiones que hemos tenido y, especialmente, por confiar en mí desde el primer momento: un trabajo distinto a lo que se suele ofertar, un apoyo continuo y muchas ganas de que participe en la línea del grupo ISA. En este sentido he de agradecer también el interés de Antonio Ruiz, que ha hecho posible que elabore una publicación para un congreso nacional exponiendo los resultados de este trabajo y ha mostrado un continuo interés en mi desarrollo dentro del grupo. Gracias a ellos he comenzado a introducirme en el mundo de la investigación, con gran ilusión, ganas de progresar y esperando que el contrato como Técnico Especialista de Apoyo a la Investigación sólo sea el primer paso de una larga carrera. Asimismo quiero aprovechar esta sección para mostrar mi enorme agradecimiento a mis padres, y en especial, a mi madre, por la infinita paciencia que ha tenido y por ser siempre un apoyo y referente en todos los momentos. Gracias a ella conocí el mundo de la informática cuando era pequeño y ha conseguido que llegue a ser lo que siempre he deseado: Ingeniero Informático. ¡Muchas gracias por todo! II RESUMEN III CONTEXTO La evolución de la industria hacia un modelo de software como servicio ha favorecido la aparición de un mercado de APIs en continuo crecimiento. En este contexto es necesario para los desarrolladores de APIs dar soporte a planes de precio y gestión de niveles de servicio. Para desacoplar la lógica de la API de estas tareas se han creado plataformas de gestión denominadas API Gateways. Sin embargo, estas plataformas presentan bastantes limitaciones debido a que no establecen un modelo de SLA explícito. OBJETIVOS En este trabajo se pretende realizar un estudio del estado del arte de las APIs y SaaS existentes en el mercado para comprobar las necesidades en cuanto a planes de precio y gestión de peticiones, además de estudiar los API Gateways para analizar sus funcionalidades y así construir una herramienta que proporcione soporte a las APIs para cubrir tales necesidades. RESULTADOS La investigación realizada durante este trabajo ha dado como resultado una framework que cualquier API puede incorporar, personalizable con plantillas de SLA, que dota a la API de forma automática de un sistema de gestión de autorización de peticiones basadas en cuotas establecidas en los acuerdos. Además se ha realizado un estudio de las necesidades de las APIs y características de algunos API Gateways. CONCLUSIONES En un contexto donde existe un mercado abierto y en crecimiento de APIs con modelos de precio muy variados, el framework desarrollado establece los fundamentos de un gobierno automatizado de las APIs, simplificando y abriendo la puerta a otros que tengan en cuenta elementos como los costes de infraestructura y modelos avanzados de penalizaciones. Las contribuciones de este trabajo han permitido la elaboración de un artículo para un congreso nacional y han servido de base para complementar material de algunas prácticas docentes en asignaturas de la Escuela. ÍNDICE GENERAL A. Towards SLA-Driven API Gateways 117 A.1.Abstract ..................................... 117 A.2.Introduction................................... 117 A.3.PricingplansinAPIs.............................. 119 A.4. Pricing plans in API Gateways . . . . . . . . . . . . . . . . . . . . . . . . 122 A.5.ResearchChallenges .............................. 124 A.6.Conclusions ................................... 126 B. Memoria para la beca de iniciación a la investigación de la US 127 B.1. Introducción................................... 127 B.2. Background del equipo investigador . . . . . . . . . . . . . . . . . . . . . 128 B.3. Objetivos..................................... 129 B.4. Plandetrabajo.................................. 130 C. Códigos 131 Bibliografía 155 X ÍNDICE DE FIGURAS XI 2.1. Diagrama de Gantt de hitos. . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.1. Configuración del proxy en Mashape...................... 47 4.2. Creación de los diferentes recursos en Mashape................ 48 4.3. Creación de los diferentes recursos en Mashape................ 49 4.4. Creación de planes en Mashape......................... 50 4.5. Monitorización de peticiones en Mashape. .................. 52 5.1. Cronología de diversos frameworks ...................... 55 6.1. Pricing plan deSemantics3............................ 66 6.2. Plan de precios de PapamoscasAPI ....................... 67 7.1. Situación de las APIs actuales. . . . . . . . . . . . . . . . . . . . . . . . . . 70 7.2. Situación de las APIs tras la solución propuesta. . . . . . . . . . . . . . . 71 7.3. Esquema detallado de la solución propuesta. . . . . . . . . . . . . . . . . 72 7.4. Diagrama simplificado de AML. . . . . . . . . . . . . . . . . . . . . . . . 73 7.5. Estructura de un documento WS-Agreement.................. 74 7.6. Diagrama de clases de los términos de garantía de un acuerdo. . . . . . . 76 8.1. Representación del stack tecnológico empleado. . . . . . . . . . . . . . . . 80 10.1. Vista de la pantalla inicial de la API . . . . . . . . . . . . . . . . . . . . . 100 ÍNDICE DE FIGURAS 10.2. Ejemplo de petición GET . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 10.3. Plan de precios de PapamoscasAPI ....................... 101 10.4. Jerarquía de directorios en el proyecto de la solución . . . . . . . . . . . . 104 10.5. Usuarios y cuotas por defecto. . . . . . . . . . . . . . . . . . . . . . . . . . 106 10.6. Error mostrado al alcanzar el límite. . . . . . . . . . . . . . . . . . . . . . 106 A.1.Contextdiagram. ................................ 119 A.2. Semantics3 Pricing Plan. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 A.3.APIscomparative................................. 122 A.4. API Gateways comparative. . . . . . . . . . . . . . . . . . . . . . . . . . . 125 XII ÍNDICE DE CUADROS XIII 2.1. Tabla resumen de tiempos y planificación . . . . . . . . . . . . . . . . . . 12 2.2. Planificación temporal de iteraciones . . . . . . . . . . . . . . . . . . . . . 13 3.1. Tabla resumen de costes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 4.1. Resumen comparativo de APIs estudiadas . . . . . . . . . . . . . . . . . 32 4.2. Resumen comparativo de SaaS estudiados . . . . . . . . . . . . . . . . . . 37 4.3. Resumen comparativo de API gateways. ................... 46 B.1. Tabla resumen de planificación semanal. . . . . . . . . . . . . . . . . . . . 130 ÍNDICE DE CUADROS XIV CÓDIGOS XV 4.1. Petición a la API a través de Mashape. .................... 50 4.2. Respuesta de la API a través de Mashape. .................. 51 7.1. Estructuradeacuerdo. ............................. 75 8.1. Extracto del POM del proyecto. . . . . . . . . . . . . . . . . . . . . . . . . 81 8.2. Fragmento de la clase AgreementsServlet. . . . . . . . . . . . . . . . . . . 82 8.3. AnotaciónSLA. ................................. 82 8.4. Fragmento 1 de la clase SLARequestFilter. . . . . . . . . . . . . . . . . . . 83 8.5. Fragmento 2 de la clase SLARequestFilter. . . . . . . . . . . . . . . . . . . 84 8.6. Fragmento de la clase SLARequestFilter. . . . . . . . . . . . . . . . . . . . 85 8.7. Clase AgreementsRESTFragment. . . . . . . . . . . . . . . . . . . . . . . 86 9.1. Método authorizeRequest sin biblioteca. . . . . . . . . . . . . . . . . . . . 90 9.2. Método requestDone sin biblioteca. . . . . . . . . . . . . . . . . . . . . . . 91 9.3. Inicialización de la clase Helper con AML . . . . . . . . . . . . . . . . . . 91 9.4. Método authorizeRequest con biblioteca. . . . . . . . . . . . . . . . . . . 92 9.5. Método requestDone con biblioteca. . . . . . . . . . . . . . . . . . . . . . 93 9.6. Extracto del POM del proyecto base. . . . . . . . . . . . . . . . . . . . . . 94 9.7. Extracto de un método de la API anotado con @SLA. . . . . . . . . . . . 94 10.1. Estructura de acuerdo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 10.2. Plantilla del acuerdo para el basic plan .................... 103 10.3. Extracto del POM del proyecto PapamoscasAPI................ 104 CÓDIGOS 10.4. Ejemplo de configuración para el acuerdo de PapamoscasAPI........ 104 10.5. Extracto de un método de PapamoscasAPI anotada con @SLA. . . . . . . 105 C.1. Salida del análisis formal de conceptos sobre estudio de API gateways. . 131 C.2. Clase principal de la biblioteca de prueba en JavaEE. . . . . . . . . . . . . 132 C.3. Extracto del POM de la biblioteca de prueba en JavaEE. . . . . . . . . . . 133 C.4. Servlet en el proyecto JavaEE. . . . . . . . . . . . . . . . . . . . . . . . . . 134 C.5. Clase productora para poder inyectar la biblioteca en el proyecto JavaEE. 134 C.6. Bean de JavaEE que usa la biblioteca de prueba en JavaEE. . . . . . . . . 134 C.7. Extracto del POM de la biblioteca de prueba en Spring. . . . . . . . . . . 135 C.8. Configuración XML de la biblioteca en Spring. . . . . . . . . . . . . . . . 135 C.9. Extracto del POM del proyecto de prueba en Spring. . . . . . . . . . . . . 135 C.10.Controlador del proyecto de prueba en Spring. . . . . . . . . . . . . . . . 136 C.11.Clase AgreementFilter sin AML. . . . . . . . . . . . . . . . . . . . . . . . 137 C.12.ClaseHelpersinAML.............................. 138 C.13.Plantilla del acuerdo para el medium plan. .................. 139 C.14.Plantilla del acuerdo para el pro plan...................... 139 C.15.Plantilla del acuerdo basic plan en WS-Agreement. . . . . . . . . . . . . . 140 C.16.ClaseHelperconAML.............................. 141 C.17.ClaseHelper................................... 143 C.18.Clase AgreementFilter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 C.19.Clase AgreementsServlet. . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 C.20.Clase AgreementsServlet. . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 C.21.Clase SLARequestFilter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 C.22.Clase ApplicationConfig. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 C.23.Clase AgreementsREST. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 XVI CÓDIGOS C.24.Clase APIConfiguration de PapamoscasAPI ................. 152 XVII INTRODUCCIÓN PARTE I METODOLOGÍA PARTE II 2 PLANIFICACIÓN 11 Adventure is just bad planning. Roald Amundsen (1872-1928), Norwegian explorer La planificación para un proyecto es el estudio del tiempo, necesidades y distribución de tareas que debemos tener para la realización de las distintas fases o etapas de un proyecto. La medición final se basa en la contabilización de las horas que finalmente nos ha llevado realizar cada una de las tareas y subtareas. CAPÍTULO 2. PLANIFICACIÓN Este trabajo de fin de grado se enmarca dentro de una línea de investigación en curso, por lo que presenta unas peculiaridades derivadas de las incertidumbres propias de tales actividades. 2.1 METODOLOGÍA DE DESARROLLO Se ha usado una metodología ligera, incremental e iterativa adaptada a las peculiaridades del proyecto donde se ha optado por establecer un calendario de reuniones breves semanales, en las que se realice el seguimiento de las tareas a realizar identificadas. En caso de no haber cubierto los objetivos para una reunión determinada, se analizan las causas y se pospone a la siguiente semana. El control de tareas ha sido realizado con la aplicación web de Assembla, una aplicación realizada sobre Ruby on Rails (con algunas partes en Python) que ofrece espacios de trabajo para los desarrolladores software, con soporte SVN, GIT, Mercurial, blog, wiki, gestión de bugs y tickets, gestión de usuarios, múltiples proyectos, repositorio para documentación, anotación de imágenes, chat, alertas, etc. Para las comunicaciones y compartición de archivos entre se ha empleado, fundamentalmente, el stack integrado por Google Drive,Google Docs yMicrosoft OneNote. 2.2 RESUMEN TEMPORAL DEL PROYECTO En la figura §2.1 se aprecia resumen de la temporalización de este proyecto. Resumen del proyecto Fecha de inicio 21/10/2014 Fecha de fin 2/06/2015 Periodicidad de las revisiones 1 semanas Carga de trabajo semanal 12 horas Horas totales previstas 320 horas Horas finales 343,8 horas Cuadro 2.1: Tabla resumen de tiempos y planificación 12 2.3. INFORME DE TIEMPOS DEL PROYECTO 2.3 INFORME DE TIEMPOS DEL PROYECTO De las iteraciones semanales anteriormente mencionadas, extraemos los hitos fundamentales del proyecto, tal y como se aprecia en §2.2 Resumen de iteraciones Iteración 1: toma de contacto inicial 21/10/14 a 18/11/14 Iteración 2: puesta en marcha tecnológica 18/11/14 a 2/12/14 Iteración 3: formación en Ingeniería del Software 2/12/14 a 23/12/14 Iteración 4: estudio de soluciones existentes 23/12/14 a 19/02/15 Iteración 5: diseño 19/02/15 a 9/04/15 Iteración 6: elaboración documentos derivados 9/04//15 a 8/05/15 Iteración 7: implementación y documentación 8/05/15 a 18/05/15 Cuadro 2.2: Planificación temporal de iteraciones En concreto, cada iteración de las mostradas en la figura §2.2 se detalla a continuación: Iteración 1: investigación y documentación del background investigador a modo de toma de contacto. Iteración 2: instalación de stack tecnológico y creación de pruebas de concepto para un estudio tecnológico. Iteración 3: documentación y formación en conceptos de la Ingeniería del Software (patrones de diseño y documentación de autores clásicos). Iteración 4: estudio detallado de herramientas del grupo y propuesta de mejora de las soluciones existentes para la gestión de SLA. Iteración 5: uso de biblioteca desarrollada por el grupo y aplicación a casos concretos. Iteración 6: elaboración de memoria para beca de iniciación a la investigación y artículo para congreso nacional. Iteración 7: implementación de la solución propuesta y finalización de la documentación. 13 CAPÍTULO 2. PLANIFICACIÓN Para mejorar la visión y perspectiva global del desarrollo del proyecto, se han volcado las tareas realizadas, agrupadas por hitos y se han representado en un diagrama de Gantt, tal y como aparece en la Figura §2.1. Se puede observar una desviación en unas 20 horas respecto de la planificación inicial, pero es justificable debido a especial carácter de este proyecto. Se había estimado en algo más de 300 horas al valorar la complejidad de enfrentarse por primera vez a tareas investigadoras siguiendo la línea de un grupo de investigación, pero aun así, no se ha ajustado a lo planificado. El hecho de haber desarrollado un artículo para un congreso nacional y centrar algunos esfuerzos en mostrar un prototipo funcional del uso de la biblioteca desarrollada por el grupo por necesidades docentes hayan conducido a ese incremento de la horas dedicadas. 14 2.3. INFORME DE TIEMPOS DEL PROYECTO Figura 2.1: Diagrama de Gantt de hitos. 15 CAPÍTULO 2. PLANIFICACIÓN 16 3 ESTIMACIÓN DE COSTES 17 Goals are dreams with deadlines Diana Scharf Hunt (1990), Author En este capítulo se calculan los costes estimados en base a la planificación realizada, teniendo conocimiento de los salarios de cada rol involucrado en el proyecto, las horas planificadas por cada uno y el coste de las licencias utilizadas en caso de haberlas. CAPÍTULO 3. ESTIMACIÓN DE COSTES 3.1 COSTES DE PERSONAL Al tratarse de un proyecto con una fuerte componente investigadora asumiremos que para la realización del mismo han sido necesarios tres roles diferentes: un Profesor Contratado Doctor para la coordinación del proyecto, un Ayudante de Investigación para las tareas técnicas derivadas directamente con la investigación y un Analista- Programador para la ejecución de la solución propuesta. El cálculo de estos costes se basa en dos convenios: XVI CONVENIO COLECTIVO ESTATAL DE EMPRESAS DE CONSULTORÍA Y ESTUDIOS DE MERCADOS Y DE LA OPINIÓN PÚBLICA [2], que regula el salario mínimo para un Analista-Programador. XIII CONVENIO COLECTIVO DE ÁMBITO ESTATAL PARA LOS CENTROS DE EDUCACIÓN UNIVERSITARIA E INVESTIGACIÓN [3], que regula el salario mínimo de los puestos del Personal Docente e Investigador. Se determina para cada uno de los puestos el salario en e/h: Profesor Contratado Doctor: 1.573,93 e/ 160 h = 9,84 e/h Analista-Programador: 1.468,54 e/ 160 h = 9,18 e/h A estos costes se les debe añadir los costes de la Seguridad Social a cargo de la empresa. Estos se calculan aplicando unos porcentajes que se determinan según el tipo de contrato y puesto de trabajo, aplicándose sobre la base de cotización de cada trabajador, que se calcula como la suma de todos los conceptos salariales de la nómina del trabajador, que se corresponde con las cifras obtenidas en el párrafo anterior. La seguridad social a cargo de la empresa cubre los siguientes riesgos: Contingencias comunes: contempla el riesgo de enfermedad común del trabajador, por motivos ajenos al trabajo. Este coste se calcula aplicando un 23,6% a la base de cotización de cada trabajador. Desempleo: cubre el riesgo de que el trabajador se quede en paro, ya sea por despido o por fin del contrato. Para los contratos temporales a tiempo parcial (, como es el caso que nos ocupa, se calcula aplicando un 7,7% sobre la base de cotización. 18 4 ESTADO DEL ARTE 25 Study nature, love nature, stay close to nature. It will never fail you. Frank Lloyd Wright (1867–1959), American architect Comenzaremos analizando algunas de las APIs y soluciones de Software como Servicio más conocidas y analizaremos sus características. Posteriormente realizaremos un recorrido por las numerosas soluciones de gateway para APIs y veremos una comparativa haciendo especial hincapié en las funciones esenciales que se esperan. Más tarde detallaremos la puesta en marcha de una API existente bajo Mashape, intentando analizar la funcionalidad que nos ofrece. CAPÍTULO 4. ESTADO DEL ARTE 4.1 INTRODUCCIÓN Es un hecho que los nuevos modelos de distribución de software y computación han ido ganando terreno en el campo empresarial; de hecho, es muy frecuente ver blogs no técnicos hablando de Software como Servicio (SaaS) y APIs. Por eso, es importante conocer e intentar definir estos términos. Saas puede entenderse como aquel modelo de distribución de software donde una empresa ofrece el mantenimiento, soporte y operación del software para su utilización por varios clientes durante el tiempo que hayan contratado el servicio. El usuario paga por el uso, por la infraestructura necesaria (CPD, servidores, sistemas de almacenamiento, sistemas de seguridad, etc.) para el correcto funcionamiento de la aplicación y por el mantenimiento (nuevas versiones, corrección de bugs, almacenamiento necesario, etc.) de la infraestructura y aplicación. Por otro lado las APIs, si bien son conceptos completamente distintos, guardan mucha relación con lo anterior. Un cliente cuando adquiere una solución SaaS está llevando sus datos a las instalaciones de un tercero y quizás este sea el principal temor y causa de la resistencia al cambio de muchos empresarios. Y aquí entran en juego las APIs, pues se ofrece al cliente la posibilidad de acceder a sus datos de una manera programática y flexible. No obstante, el enfoque de API que estudiaremos aquí no es el de aportar valor añadido a una solución SaaS, sino el de aquella API que tiene valor per se y por ello es susceptible de tener un modelo de cobro. Todo este estudio preliminar guarda estrecha relación con lo que se presentará en esta memoria, pues conocer el paradigma actual es esencial para poder proponer nuevas soluciones basadas en la investigación sobre la formalización y razonamiento con Acuerdos a Nivel de Servicio. En concreto, dedicaremos este capítulo a estudiar varias APIs y soluciones SaaS, dando una descripción general y detallando los planes que ofrecen. Es una tarea difícil el seleccionar un número reducido de servicios para analizarlos aquí y existen multitud de criterios para la selección; aquí presentamos una pequeña selección arbitraria, centrándonos en ilustrar la diversidad existente. No obstante, podría ser ampliada tan- to como quisiéramos, pues cada día se desarrollan nuevas APIs y salen a luz nuevos SaaS. 26 4.2. ESTUDIO DE APIS 4.2 ESTUDIO DE APIS 4.2.1 AlchemyAPI Es una empresa perteneciente a IBM que ofrece servicios de procesamiento de lenguaje natural (aka NLP) y reconocimiento de imágenes. En el primer campo, dado un texto, permite extraer y clasificar entidades, analizar sentimientos, extraer relaciones, taxonomías, reconocer idiomas, etc. En el segundo, dada una imagen, permite clasificarla y etiquetarla y, si además contiene caras, devuelve las coordenadas junto al género, rango de edad y, si se trata de un rostro conocido, lo indica y devuelve metadatos de la persona reconocida. Existen 3 planes basados exclusivamente en el volumen de peticiones diarias realizadas, oscilando entre las 90.000 y 3 millones. Hay una capa gratuita de 1000 peticiones diarias y ofrece la posibilidad de contactar para planes personalizados con alto volumen de demanda. Además de lo anterior, se puede seleccionar de forma independiente el paquete de rendimiento y soporte deseado: desde la capa gratuita con soporte vía email y una conexión concurrente, podemos llegar a soporte telefónico, uptime garantizado por SLA y hasta 50 conexiones concurrentes. Finalmente, para un uso esporádico, se establece un modelo de cobro alternativo pay-as-you-go, segmentado en rangos de 250k, 750k, 1M, 3M y 5M de transacciones. 4.2.2 Algorithmia Esta compañía pretende construir un mercado donde los desarrolladores construyan y consuman algoritmos. Podemos encontrar desde implementaciones de Dijkstra para caminos mínimos hasta técnicas estadísticas para clustering en el procesamiento de lenguaje natural. El modelo de cobro es algo innovador; se pretende que el usuario que desarrolla un algoritmo ponga precio a la llamada del mismo y luego se tarifique por el tiempo de cómputo. 27 CAPÍTULO 4. ESTADO DEL ARTE Para ello, se establece un modelo de créditos (un dólar equivale a unos 10k créditos) que se compran a la compañía y el usuario los consume como desee. No tiene capa gratuita, aunque sí se bonifica a los nuevos usuarios con 10k créditos iniciales. Existen planes personalizados para grandes cantidades. 4.2.3 FlightStats Esta organización ofrece información completa sobre los vuelos y aeropuertos, de forma que podemos obtener planes de vuelos, planificaciones, retrasos, aterrizajes, vuelos cerca de una zona, etc. El modelo de cobro es sencillo: cada recurso tiene un coste por transacción. De esta forma, por ejemplo, conseguir los vuelos cercanos dado un punto es más barato que listar todos los vuelos planificados para un aeropuerto. Por otro lado, se ofrecen recursos premium (como alertas de vuelo o información de las pantallas FIDS1) de forma personalizada hablando con un asistente de ventas. No existe una capa gratuita, aunque sí nos ofrecen 20k peticiones repartidas por tipo para que podamos probar antes de lanzar nuestra aplicación. 4.2.4 Groupdocs Esta compañía centra sus servicios en la gestión de documentos colaborativos con tres modelos de negocio: vender sus bibliotecas en Java/.NET, usar su solución SaaS y ofrecer sus servicios como API. Nos centraremos en este último modelo. Se ofrecen 7 productos: visor de documentos, creador de anotaciones y marcas para documentos, conversor a distintos formatos, ensamblador de documentos partiendo de plantillas, firma digital de documentos, comparación de documentos. Cada uno de estos productos tiene una API asociada y el cobro es independiente. Cada API tiene varios planes asociados en función del volumen de operaciones realizadas. 1Flight information display system. 28 4.2. ESTUDIO DE APIS Por cada API, el concepto de operación es distinto; por ejemplo, para las visualizaciones sólo cuenta cada documento visto, sin importar el número de visualizaciones o usuarios. Sin embargo, para una comparación, se considera operación a cada llamada que realice tal comparación. Existen 6 planes por cada API, donde el número de operaciones oscila entre las 750 y las 100k mensuales. Se ofrece una capa gratuita de prueba con 100 operaciones mensuales y otras limitaciones, además de planes personalizados para clientes con mayor volumen de operaciones. 4.2.5 Kraken Esta empresa se dedica en exclusiva a la compresión de imágenes manteniendo la calidad aparente para reducir los costes derivados del almacenamiento y ancho de banda. Existen 5 planes basados en la cantidad de bytes subidos para ser comprimidos. De esta forma, podemos llegar a comprimir desde 500MB hasta 60GB de imágenes. Después de esa cantidad, dependiendo del plan contratado, existe un coste extra por cada GB adicional. Además del acceso a la API, cada plan da acceso a una interfaz web y un plugin de Wordpress por si deseamos hacer un uso no programático. No existe una capa gratuita, aunque sí se ofrecen 50MB de subida gratis para las pruebas. No se menciona ningún tipo de plan personalizado que se pueda negociar. 4.2.6 Mailgun Esta organización, que es parte de Rackspace, ofrece un servicio de envío masivo de emails para desarrolladores, es decir, no ofrece otro tipo de interfaz no programática como otros tantos proveedores de servicios de mailing. Cada dominio funciona de forma aislada, de forma que si tenemos varios clientes y existe problema de spamming, podemos deshabilitar esa cuenta de forma separada. Además, cada email es parseado como JSON, lo que facilita el tratamiento programático. Finalmente, incluye con un servicio de validación y rastreo de emails. 29 CAPÍTULO 4. ESTADO DEL ARTE El modelo de cobro es muy simple, cuenta con una capa gratuita de 10k envíos mensuales y luego un coste incremental por rango de envíos: 500k, 1M, 5M y más. Se puede añadir además una IP dedicada por un coste fijo adicional. Existe un plan personalizado donde la propia organización revisa los envíos, monitoriza la reputación de los servidores y garantiza la llegada a la bandeja de entrada. Es preciso contactar con algún asistente de ventas para obtener más información. 4.2.7 OpenWeatherMap Esta empresa ofrece información meteorológica, aunque comparte nicho de mercado con otras muchas. Quizás el aspecto más destacable es que se permite que los usuarios con estaciones meteorológicas amateur puedan subir sus datos. De esta forma se cubren zonas locales y la predicción no se basa sólo en estaciones oficiales y de aeropuertos. De forma análoga a otros competidores, se ofrece una capa gratuita de 3000 llamadas por minuto, aunque los datos tienen un retraso de dos horas y el registro histórico es menor a un mes. Cuenta con tres planes basados en el número de peticiones por minuto, aunque también se aumenta el histórico disponible, la disponibilidad garantizada y el soporte del que se dispone. 4.2.8 Semantics3 Esta compañía ofrece información de productos vendidos en diferentes plataformas de comercio electrónico, de hecho, afirman que almacenan más de 60 millones de productos y de cada uno, las distintas ofertas del mercado. De esta forma se permite acceder a histórico de precios, buscar productos por código de barras, búsqueda semántica de productos, etc. Existen 3 planes que cuentan con 1k, 25k y 100k llamadas diarias, además se permite añadir dominios personalizados para monitorizar y crear alertas para cuando existan nuevos productos que encajen con la descripción. También cuenta con una capa gratuita de 1k llamadas diarias, pero sin acceso a las imágenes de los productos. Asimismo existen soluciones personalizadas, con un SLA propio y acceso completo a la API. 30 4.2. ESTUDIO DE APIS 4.2.9 Stupeflix Esta organización ofrece el tratamiento integral de imágenes, vídeo y audio. De esta forma, se puede, por ejemplo, editar un vídeo y subirlo a Youtube yFacebook, recortar imágenes y crear audio a partir de texto. El modelo de cobro es sencillo, no existen planes definidos, sino que cada recurso se tarifica de forma independiente. Además se ofrece un servicio de alojamiento multimedia con un precio fijo por almacenamiento y ancho de banda usados. No existe una capa gratuita, aunque sí ofrecen crédito gratuito para las primeras pruebas. Tampoco existe ninguna mención a planes personalizados. 31 CAPÍTULO 4. ESTADO DEL ARTE 4.2.10 Resumen comparativo APIs estudiadas Plataforma 1 2 3 4 5 6 7 8 AlchemyAPI x x x x x - x x Algorithmia - - - x x x - - FlightStats - - x - x x - - Groupdocs x x x - x - - - Kraken - x - - - x - - Mailgun x - - x x - - - OpenWeatherMap x x x - - - - x Semantics3 x x x - x - - x Stupeflix - - - x - x - - Cuadro 4.1: Resumen comparativo de APIs estudiadas 4.2.11 Análisis comparativo Cada columna de la tabla §4.1 se corresponde con ciertas características analizadas, de forma que una xen la celda Ci,jsignifica que la plataforma iposee la característica j. 1. Capa gratuita. 2. Varios planes disponibles. 3. Plan basado en un número fijo de peticiones. 4. Plan basado en el número peticiones realizadas. 5. Posibilidad de planes personalizados. 6. Periodo de prueba limitado. 7. Paquetes de soporte adicional. 8. Disponibilidad garantizada por SLA. 32 4.3. ESTUDIO DE SAAS 4.3 ESTUDIO DE SaaS 4.3.1 Dropbox Esta conocida empresa ofrece un servicio de almacenamiento de ficheros con numerosas características de valor añadido como son su cliente de sincronización de archivos, el histórico de cambios, la subida automática de fotos desde dispositivos móviles, etc. Existen dos segmentos de clientes: los particulares y las empresas. En el primer caso, el modelo de cobro es muy sencillo, por una cuota mensual se consigue 1TB de espacio y ciertas características que el plan gratuito no tiene. A nivel empresarial, se tarifica por usuarios que vayan a hacer uso del servicio. Además esta versión cuenta características adicionales enfocadas a mejorar la seguridad y la compartición de archivos. La versión gratuita ofrece almacenamiento de 2GB, aunque ampliables según diversas campañas promocionales, y numerosas características básicas. Existe una versión de prueba de 14 días de la edición para empresas. 4.3.2 Google Apps Google ofrece sus aplicaciones más populares como servicio y de manera corporativa. De esta forma, tendremos, por ejemplo, toda la funcionalidad de Gmail pero con nuestro propio dominio de la compañía, llamadas y contactos dentro de la empresa, almacenamiento para los documentos editados y compartidos online... en definitiva, todos los servicios de Google al servicio de la empresa. Es destacable además la posibilidad de establecer políticas y restricciones de seguridad: incluso se pueden configurar teléfonos Android para que estén sujetos a tales políticas. Si bien anteriormente existía una versión gratuita limitada, esta ha sido retirada y sustituida por dos planes similares. La diferencia está en que uno tiene almacenamiento ilimitado y registro de emails enviados por la compañía. Se tarifica por usuario dado de alta en el servicio y se permite el pago mensual o anual. 33 CAPÍTULO 4. ESTADO DEL ARTE Cabe mencionar aquí que Google, en apoyo de organizaciones sin ánimo de lucro y colegios e institutos, ofrece estos servicios de forma gratuita. Existe un límite de usuarios inicial, aunque con una solicitud lo incrementan sin mayor problema. Existe una versión de prueba durante 30 días. 4.3.3 Matlab Online Desde la compañía Mathworks, creadora del conocido programa MATLAB, nos ofrecen una versión en la nube con ciertas limitaciones. Por ejemplo, no podemos ejecutar comandos de más de 5 minutos, acceder al hardware directamente, subir archivos de más de 16MB y otras limitaciones. A pesar de ello, con un ordenador2con conexión a Internet y un mínimo de memoria, podemos acceder a este potente software. Aquí no existe un modelo de cobro específico, sino que se trata de una solución de valor añadido al adquirir una licencia de MATLAB. Con una licencia de prueba, podemos disponer de tal servicio durante 30 días. 4.3.4 Office365 La conocida suite de ofimática busca nuevos nichos de mercado ofreciendo sus productos como servicio. De esta forma, según el segmento de mercado, se crean familias de planes dependiendo de la funcionalidad ofrecida. Sin contar planes para ONG, estudiantes y otro tipo de entidades, se ofertan tres tipos de familias de planes: para usuarios domésticos, pequeña empresa y gran empresa. Los planes domésticos incluyen Word,Excel,PowerPoint yOneNote, 1TB de almacenamiento, 60 minutos de llamadas por Skype. La diferencia entre ellos está en el número de dispositivos en los que se permite la activación. En el ámbito empresarial añadimos Outlook yPublisher yAccess en algunos planes. La bandeja de entrada de correo electrónico se incrementa a 50GB, se añade una red social corporativa y otras características. 2Existe un cliente para dispositivos móviles aún más ligero. 34 4.4. ESTUDIO DE API GATEWAYS Se realiza un balanceo de carga inicial con Nginx y las peticiones que vayan dirigidas a la API serán redirigidas al servidor con NodeJS, mientras que las que vayan al portal de desarrolladores serán dirigidas al servidor con Ruby on Rails. Sobre las peticiones realizadas a la API, permite autenticación de peticiones por API key y roles, limitación del tráfico y reescrituras de respuestas. Asimismo, mediante Varnish, se realiza un cacheado de las respuestas. Finalmente las peticiones son enrutadas a los diferentes API backends de los que dispongamos. 4.4.4 Apiaxle Esta es otra herramienta Open Source que se vuelve a basar en Nginx yVarnish para realizar sus funciones. Permite autenticación por API Keys, limitación del tráfico de peticiones y detección de errores en JSON/XML. Cuenta con estadísticas en tiempo real de los distintos eventos que se suceden. 4.4.5 Apigee Edge API Esta compañía ha desatollado una herramienta comercial con un modelo de negocio por uso, si se opta por el despliegue en sus servidores. Si se prefiere un sistema on-premises, se adquieren licencias por servidor. En cuanto a control de acceso y seguridad de la API, permite especificar numerosos sistemas de autenticación, desde el simple API key hasta mecanismos propios, pasando por OAuth ySAML. También se permiten establecer cuotas y límites por aplicación y usuario. Es destacable además la prevención contra ataques de seguridad según las distintas políticas y workflows que presenta integrados. De cara a los desarrolladores que usen la API, se permiten establecer distintos planes con sus cuotas de uso específicas. Además se pueden realizar paquetes con las APIs que deseemos exponer y extraer variables desde la respuesta, monitorizarlas y tenerlas en cuenta en los planes. Entre otras características destacan la posibilidad de realizar versionado de la API, las transformaciones de protocolo sobre la respuesta de la API y el sistema de caché y de distribución de contenido distribuido. 41 CAPÍTULO 4. ESTADO DEL ARTE En relación a formas de cobro que existen, podemos personalizar el workflow de acuerdo a nuestras necesidades y, mediante el portal para desarrolladores, se puede centralizar y controlar todo el proceso. El sistema de monitorización a tiempo real nos permite establecer alertas y reportes tanto a nivel técnico como de de negocio. 4.4.6 Axway API Gateway Esta compañía cuenta con un fuerte trasfondo de SOA y la mayoría de sus productos están orientados a ello. En este caso, pretenden dotar a las APIs de la misma idea de governanza clásica. Se pretende controlar el ciclo de vida del desarrollo de APIs, disponiendo además de un catálogo donde se publiquen. Se incluyen políticas integradas para facilitar la configuración y desarrollo. En cuanto a control de acceso y seguridad de la API, esta solución cumple numerosos estándares de seguridad y nos permite emplear mecanismos de autenticación propios, además de conectores con conocidos productos de IBM y Oracle y soporte a OAuth,LDAP, etc. La monitorización a tiempo real de las peticiones a la API permite controlar el cumplimiento de SLAs y QoS. Además ofrece planes configurables y cuotas de uso. Entre otras características se encuentra el balanceo de carga, versionado, cacheado de peticiones y conversión de respuestas SOAP/REST. En el sentido de la governanza SOA, da soporte a la recepción de mensajes asíncronos (JMS,Websockets...) y orquestación de servicios. 4.4.7 Azure API Management Entre los servicios que ofrece Microsoft en su solución cloud se incluye la administración de APIs desplegadas en sus sistemas. En cuanto a control de acceso y seguridad de la API, se pueden establecer cuotas y límites de uso. La autenticación se realiza de forma nativa, según los propios 42 4.4. ESTUDIO DE API GATEWAYS mecanismos de esta; no obstante, se pueden aplicar políticas de grupo por Active Directory. Además, ofrece un portal para desarrolladores con consola para realizar pruebas, un sistema de monitorización y alertas y permite también la conversión XML/J- SON de las respuestas. 4.4.8 CA API Gateway Es un producto de una empresa que también prioriza la governanza SOA en su catálogo de servicios. En particular esta solución pretende servir de soporte a aplicaciones desarrolladas para dispositivos móviles. En cuanto a control de acceso y seguridad de la API, se da soporte a múltiples mecanismos de autenticación, incluyendo LDAP,SAML,OAuth ySingle Sign On (SSO). Se pueden establecer límites y métricas de cara al cumplimiento de SLAs. Además pretende proteger la API frente diversos ataques. Entre otras características, ofrece cacheado de peticiones, versionado y analíticas. 4.4.9 Mashape Además de ofrecer los servicios de gateway, se introduce el concepto de marketplace, donde a través de una interfaz similar se pueden consumir las APIs publicadas. Es una organización orientada a la sencillez y facilidad de uso de cara al desarrollador. En cuanto a control de acceso y seguridad de la API, se acepta autenticación básica y OAuth. Además se pueden enviar headers exclusivos entre el proxy y la API, de forma que la petición quede transparente para el desarrollador. Se pueden crear planes basados en peticiones y endpoints, además de poder establecer hasta cuatro cuotas distintas De esta forma, con un HTTP header podemos controlar las unidades que se incrementa hasta llegar al límite. Asimismo, se pueden crear planes privados sólo para ciertos desarrolladores invitados. La monitorización permite verificar el estado de la API y generar alertas, además de visualizar los ingresos generados y cuotas usadas por los distintos desarrolladores. 43 CAPÍTULO 4. ESTADO DEL ARTE Permite crear un portal con documentación y consola para pruebas, además de generar código en varios lenguajes para consumir rápidamente la API. Permite también ofrecer soporte a los usuarios con un sistema de tickets. 4.4.10 Mashery API Gateway Mashery fue una de las primeras organizaciones en adoptar el término API management, aunque también por ello cuenta con una funcionalidad más limitada. Los mecanismos de autenticación son básicos, por IP o mediante autenticación HTTP. De cara al control, se permite establecer límites de uso, pero de una forma básica, accediendo directamente al portal que ofrece. También se pueden realizar analíticas y recopilar estadísticas del uso de la API. 4.4.11 Monarch API Manager Es una ligera herramiente Open Source que se puede desplegar on-premises o en cloud de dos formas distintas: directamente en el código de la API o mediante un proxy inverso con Nginx. Permite establecer políticas básicas de seguridad basadas en OAuth a fin de gestionar el control de acceso a la API. Además realiza una monitorización a tiempo real que almacena sobre MongoDB. 4.4.12 Repose Es otra solución Open Source middleware para la gestión de APIs que se despliega on-premises y permite que sólo peticiones bien formadas y validadas lleguen a la API a través de un sencillo workflow: En primer lugar, se realiza la autenticación por API Key, HTTP o IP y se comprueba que no se ha sido superado el límite de peticiones. En caso de autorizarse, se realiza un balanceo de carga y se sirve la petición donde corresponda. Finalmente, se guarda el registro de la petición en el log. 44 4.4. ESTUDIO DE API GATEWAYS 4.4.13 WSO2 API Management Como todos los productos de WSO2, es una herramienta Open Source desplegada on-premises que permite realizar una gestión de las APIs durante todo el ciclo de vida. En cuanto a control de acceso y seguridad de la API, se permiten mecanismos de autorización como OAuth,LDAP ySAML. Además se pueden establecer planes y límites en el uso de la API. Cuenta una un panel de administración donde controlar el estado de publicación de cada API y un portal con la documentación especificada con Swagger. Realiza monitorización de las peticiones realizadas para ofrecer reportes, generar alertas y garantizar el cumplimiento de los SLA. 4.4.14 Análisis comparativo Cada columna de la tabla §4.3 se corresponde con ciertas características analizadas, de forma que una xen la celda Ci,jsignifica que la plataforma iposee la característica j. Es importante destacar que la ausencia de esa marca no implica directamente que la plataforma no posea la característica, es posible que no lo publiciten en sus especificaciones y luego esté incluida. 1. Open Source. 2. Free tier. 3. Autenticación básica. 4. Autenticación avanzada. 5. Planes personalizados. 6. Cuotas por uso. 7. Analíticas. 8. Portal de desarrolladores. 9. Soporte al versionado. 10. Conversión de respuestas. 11. Protección contra ataques. 12. Balanceo de carga. 13. Caché de peticiones. 14. Orquestación de servicios REST. 45 CAPÍTULO 4. ESTADO DEL ARTE API Gateways estudiados Plataforma 1 2 3 4 5 6 7 8 9 10 11 12 13 14 3Scale - x x - x x x x - - - - - - Akana API Gateway - - x x - x x - - x x - - x API Umbrella x x x - - - x x - - - x x - Apiaxle x x x - - - x - - - - - - - Apigee Edge API - - x x x x x x x - x - x - Axway API Gateway - - x x x x x - x x - x x x Azure API Management - - - - - x x x - x - - - - CA API Gateway - - x x - - x - x - x - x - Mashape - x x - x x x x - - - - - - Mashery API Gateway - - x - - x x x - - - - - - Monarch API Manager x x x - - - x - - - - - - - Repose x x x - - x x - - - - x - - WSO2 API Management x x x x x x x x x x - - - - Cuadro 4.3: Resumen comparativo de API gateways. Si aplicamos técnicas propias del análisis formal de conceptos (completo en C.1), podemos ver fácilmente las tendencias del mercado: Todos ofrecen analíticas sobre el uso de la API. La mayor parte da soporte a mecanismos de autenticación básicos. Los que ofrecen versionado o protección suelen permitir mecanismos de autenticación más avanzados. Casi todos los que permiten cuotas y y planes ofrecen un portal para desarrolladores. 46 4.4. ESTUDIO DE API GATEWAYS 4.4.15 Estudio de Mashape Como ya hemos visto en §4.4.9 de la sección anterior Mashape nos ofrece los servicios de gateway para nuestras APIs y además un marketplace donde publicarlas. Al estar orientado al pequeño desarrollador y no a grandes organizaciones enfocadas a SOA, la sencillez con la que podemos publicar una API existente es bastante superior a la del resto de proveedores estudiados en la sección anterior. Justo por eso dedicaremos esta sección a detallar las funcionalidades que nos ofrece a través de un ejemplo de uso. Aunque bien podríamos hablar de otros proveedores de soluciones Open Source o con una capa gratuita, puesto que la funcionalidad ofrecida es muy similar no merece detenerse tanto. Partiremos de una API existente desplegada en el endpoint siguiente: HTTP:// PAPAMOSCASISA.APPSPOT.COM/API/V3. En primer lugar debemos asociar nuestro endpoint con el proxy inverso de Mashape; esto es inmediato, pues desde un simple formulario web obtenemos la dirección detrás del proxy: HTTP:// PAPAMOSCAS.P.MASHAPE.COM. En la figura §4.1 se puede ver este proceso. Figura 4.1: Configuración del proxy en Mashape. Una vez que hemos obtenido la dirección pública de nuestra API deberíamos adaptar nuestra API para que sólo permitiese peticiones si se envía un header del tipo X- MASHAPE-PROXY-SECRET: XXXXXX, pero como la API desplegada es compartida por otros ejemplos de la presente memoria, hemos optado por omitir tal cambio. Es interesante destacar que podemos enviar headers entre el proxy de Mashape y nuestra API, así podemos realizar diversas acciones programáticamente. Una vez definido el endpoint de Mashape empezamos a definir los diferentes re- 47 CAPÍTULO 4. ESTADO DEL ARTE cursos que la API ofrece. De esta forma estamos haciendo el mapeo entre el proxy y nuestra API y a la vez generamos una documentación y entorno de pruebas para los desarrolladores. Debido al diseño de Mashape, es preciso que los desarrolladores registren una Aplicación que consume la API. De esta forma se puede controlar y limitar las peticiones de los diferentes planes que luego crearemos. Esto es independiente de la autenticación de usuarios dentro de la propia API, como ahora veremos. Figura 4.2: Creación de los diferentes recursos en Mashape. Como se aprecia en las figuras §4.2 y §4.3 el proceso es bastante intuitivo y sólo requiere conocer los datos que usa nuestra API. Respecto a autorización de peticiones en Mashape hay que distinguir la autenticación propia que use nuestra API y el registro de la aplicación de Mashape que hace uso de nuestra API (y cualquier otra). Los mecanismos de autenticación soportados son: Basic Authentication. Header Authentication. 48 4.4. ESTUDIO DE API GATEWAYS Figura 4.3: Creación de los diferentes recursos en Mashape. Query Authentication. OAuth 1 Authentication. OAuth 2 Authentication. En primer lugar, la API que usamos, emplea una autenticación basada en Query Authentication, esto es, el endpoint requiere el par ?USER=TOKEN. De ahí que en §4.2 aparezca PROUSER1. Hasta aquí el proceso de definición de los diferentes recursos que nuestra API ofrece, el siguiente paso es definir los planes para cobrar por el uso de la misma. Sólo se pueden establecer cuatro planes: basic,pro,ultra ymega, aunque se pueden establecer planes privados e invitar a desarrolladores elegidos a ellos. Como se aprecia en la figura §4.4, cada plan puede tener cuatro tipos de cuotas distintas y diferentes características. Actualmente, Mashape sólo tiene en cuenta las cuotas. Por defecto, cada llamada al endpoint especificado en la cuota hará que esta se incremente en una unidad. No obstante, este comportamiento se puede modificar mediante headers: X-MASHAPE-BILLING: [QUOTA] = [VALUE] (;[QUOTA] = [VALUE]). 49 CAPÍTULO 4. ESTADO DEL ARTE Figura 4.4: Creación de planes en Mashape. Si se quiere tratar las características de forma programática en la API, Mashape genera, entre otros5, un header (X-MASHAPE-SUBSCRIPTION) para indicar el nombre del plan. Desde el punto de vista del consumidor de la API, el proceso es aún más simple; basta con crear una aplicación que haga uso de una o varias APIs y crear la key que enviaremos al realizar la petición a la API como un header (X-MASHAPE-KEY). Según el plan al que nos hayamos subscrito, si superamos las peticiones máximas, se nos bloqueará el acceso a la API o se cobrará en función de las peticiones extra. Con esto, ya podemos usar la API desde otro lugar, basta con hacer una petición como 4.1. 1GET /birds?user=proUser1 HTTP/1.1 2Host: papamoscas.p.mashape.com 3Connection: keep-alive 4X-Mashape-Key: NgBxs1cxsTmshUnRGveaEHudtDFKp1v9a9ejsnnGCjglswvTxc 5CSP: active 6User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) ,→AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2353.0 ,→Safari/537.36 7Accept: */* 8Accept-Encoding: gzip, deflate, sdch 9Accept-Language: es,en;q=0.8 10 Cookie: ajs_anonymous_id=%22d64c0f0f-202e-4040- ,→b336-f5023ca84555%22; _cio=e8ecbc7a-9880- 5El resto se pueden consultar en la documentación 50 5.1. EVALUACIÓN JAVAEE VS SPRING ser considerado un framework como tal, JavaEE es una especificación. Esto es, Spring es un conjunto de bibliotecas descargables desde la página oficial del proyecto o de los repositorios centrales de Maven, mientras que Java EE es un conjunto de especificaciones estándares, escritas, revisadas y aprobadas por una comunidad de expertos que definen qué servicios debería proveer y cómo se debería programar en una plataforma para aplicaciones empresariales. Además, suelen ofrecer implementaciones de referencia de muchas de las especificaciones. Por ejemplo la de JPA 2 es EclipseLink (otras son Hibernate de Red Hat, TopLink de Oracle y OpenJPA de Apache). La implementación de referencia de EJB 3.1 es el contenedor de EJBs de Glassfish (otras pueden ser JBoss de Red Hat, Weblogic de Oracle, Websphere de IBM o TomEE de Apache) y la implementación de referencia de CDI 1.0 es Weld de Red Hat. Y estamos llegando a un punto más diferenciador aún: la portabilidad. JavaEE es el conjunto de especificaciones que define los servicios que debe proveer un servidor de aplicaciones. Por ejemplo, un EJB se usa y configura de la misma forma en JBoss, Weblogic, TomEE o Glassfish. De tener algún problema con alguno, podemos migrar a otro sin necesidad de modificar el código de nuestra aplicación. Sin embargo, es imprescindible que el servidor destino implemente la misma versión de la especificación que el servidor origen. Sin embargo, con Spring, esto no es así: el propio contenedor de dependencias está integrado en esta biblioteca, por lo que podemos desplegar en cualquier servidor, por ejemplo, Tomcat. Esta portabilidad se paga, y muy caro: el tamaño del WAR generado es excesivamente grande comparado con el de un proyecto en JavaEE. Nótese entonces que con Spring estamos ligados a una sola compañía, actualmente, VMware. Si la compañía abandona el proyecto o la comunidad se disuelve, estamos ante una situación bastante inquietante. Parece evidente que, en esta situación, empresas que busquen estabilidad, confiabilidad y alta disponibilidad no dudarán en apostar por JavaEE, mientras que en otros desarrollos donde se persigan otras metas, Spring puede ser un gran aliado. No obstante y, a pesar de la visión beligerante que hemos ofrecido en párrafos anteriores, hay que mencionar que Spring y JavaEE pueden coexistir, de forma que los gaps de uno, los ocupe otro. Spring tiene una estructura modular (i.e. Spring Core, Spring Security, Spring WS, Spring LDAP...), por lo que podemos integrarlos en un proyecto JavaEE sin problemas. Además, los Spring Beans pueden inyectarse dentro de los beans de JSF y EJB. En definitiva, no hay ninguna postura clara hoy en día. Cada plataforma ofrece sus 57 CAPÍTULO 5. ESTUDIO TECNOLÓGICO ventajas e inconvenientes. El conflicto por la hegemonía en desarrollo Java empresarial sigue abierta. 5.1.2 Integración de bibliotecas Tras haber hecho un recorrido por la historia de Spring y JavaEE, merece la pena centrarnos y reflexionar sobre qué es lo que más nos interesa para diseñar nuestra biblioteca. Para hacer una decisión más fundamentada, podríamos diseñar una pequeña biblioteca de prueba, con una funcionalidad extremadamente simple, que nos sirva de prueba de concepto que soporte nuestra decisión final. Por ejemplo, vamos a implementar una biblioteca que nos ofrezca la posibilidad de guardar pares Objeto, Metadatos, posteriormente, exportaremos dicha biblioteca como un JAR que será usado mediante dependencia Maven en otro proyecto. Sin duda, algo muy sencillo, pero nos servirá de base para poder decidir. Antes de empezar, conviene comentar que, dado que apostamos por garantizar la máxima portabilidad posible (incluso si el despliegue se realiza en servicios de Platform as a Service, PaaS), realizaremos el despliegue en un servidor local Tomcat 7. Como es de esperar, habrá que añadir las dependencias manualmente para que el contenedor de EJB o CDI corra en el servidor. Biblioteca en JavaEE - Proyecto principal en JavaEE Si apostamos por una biblioteca realizada en JavaEE 7, lo primero que tenemos que hacer es elegir si nuestro bean será de EJB o CDI. En nuestro caso, vamos a optar por CDI, pues, para nuestro simple objetivo, no existe diferencia alguna. El código es bastante sencillo: se trata de un singleton que tiene un atributo Map<Object, Map<String, Object>>, que será la estructura de datos necesaria para mantener los metadatos asociados a cada objeto. Se puede ver completo en el C.2 del anexo. Como acabamos de ver, es bastante sencillo. Ahora llega el siguiente paso, empaquetar el proyecto como un JAR e importarlo en el proyecto principal. Para ello, sólo debemos editar el POM de nuestra biblioteca, añadiendo la información de la versión, groupId,artifactId y en packaging, elegir JAR. Con ello, al ejecutar en Maven el comando install-file, tendremos instalado en nuestro repositorio local el JAR de la biblioteca. A continuación sólo nos queda crear un simple proyecto que use esta biblioteca que acabamos de crear. En particular, queremos una aplicación web que muestre un objeto 58 5.1. EVALUACIÓN JAVAEE VS SPRING con los metadatos asociados. Para ello, habiendo creado ya un proyecto Maven, vamos a introducir las dependencias necesarias en el POM. En concreto, añadimos nuestra biblioteca que acabamos de instalar en el repositorio local y un contenedor de CDI, tal y como comentamos anteriormente. Vamos a usar la implementación de referencia de CDI, Weld de Red Hat. En el fragmento C.3 del anexo, vemos el extracto del POM. Con esto hecho, definimos un nuevo servlet que escuche las peticiones en y muestre la cadena dada por un método de un bean. Esto es trivial, tal y como se aprecia en el C.4 del anexo. Y ahora viene un pequeño problema con el que nos encontramos: CDI escanea los beans de nuestro proyecto por defecto. Si queremos incorporar otros, basta con añadirlos al archivo beans.xml. Ahora bien, ¿qué ocurre si se actualiza el JAR? Evidentemente, no se actualizará. Por este motivo, buscamos otra solución alternativa. Simplemente creamos una clase con un método productor que nos devuelva el objeto que queremos. La clase completa puede verse en el C.5 del anexo. Tras todos estos pasos intermedios, por fin llegamos al final de nuestro ejemplo: el bean de CDI que usará nuestra biblioteca, tal y como vemos en código C.6 del anexo. Lo más destacable aquí quizás sea mencionar que el objeto metadata esté siendo inyectado y sea el método productor el que se encarga del binding entre el JAR externo y nuestro proyecto principal. Tras esto, ya tenemos nuestra primera prueba realizada con éxito. Antes de realizar una valoración más detallada, hay algo que destacar: si queremos usar una biblioteca realizada en JavaEE, necesitamos que nuestro servidor corra un contenedor de EJB o CDI (como es nuestro caso). Aunque pudiera darse el caso, es algo extraño tener una biblioteca realizada en JavaEE cuando va a importarse en proyectos que no usen esta especificación. Por tanto, descartamos realizar el ejemplo de Biblioteca en JavaEE - Proyecto principal en Spring. Biblioteca en Spring - Proyecto principal en JavaEE En esta sección seremos algo más escuetos, puesto que en la anterior hemos analizado cada detalle a fin de aclarar todos los conceptos de lo que buscamos conseguir. Ahora queremos ver las diferencias existentes en la biblioteca y cómo ésta se incorpora a un proyecto JavaEE. Nótese que seguimos teniendo la necesidad de añadir las 59 CAPÍTULO 5. ESTUDIO TECNOLÓGICO dependencias de Weld, ya que no hemos cambiado de servidor en ningún momento. Antes de nada, hay que añadir las dependencias de Spring en nuestro POM, además de declarar el packaging del proyecto como JAR. Todo esto se puede apreciar en el C.7 del anexo. Hay que hacer notar que la configuración en Spring es algo más compleja (o, al menos, lo es para alguien que venga directamente desde el mundo JavaEE 7). Hay tres formas de realizarla: desde un XML tradicional, con anotaciones o desde una clase anotada con @Configuration. En concreto, para este ejemplo simple, hemos optado por usar el clásico XML. Allí declaramos nuestro bean con un scope singleton. El application- Context.xml lo podemos ver en el C.8 del anexo. Tras esto, creamos el SingletonMapBean con un código muy similar al de C.5. La única diferencia es que aquí no hay ninguna anotación propia de JavaEE. Finalmente, con Maven, hacemos install-file y ya tendremos el JAR instalado en nuestro repositorio local. Ahora sólo tenemos que agregarlo en nuestro proyecto JavaEE; pero este paso es trivial si tenemos la información del apartado anterior. Volvemos a crear una clase con un método productor que nos dé el objeto y, con esto, ya puede ser inyectado donde haga falta. En definitiva, repetimos los códigos descritos en C.5 y C.6. Si lo usamos como en el servlet creado en C.4, obtendremos una salida muy similar. En definitva, volvemos a conseguir lo que nos habíamos propuesto. Biblioteca en Spring - Proyecto principal en Spring Y hemos llegado al último de los ejemplos, usando Spring plenamente. Esto nos ofrece una enorme ventaja respecto a los anteriores: ya no tenemos que incorporar el contenedor de CDI (Weld) como dependencia (pero, al fin y al cabo, vamos a introducir otro motor de inyección de dependencias con Spring). El proceso de crear la biblioteca en Spring ya acaba de ser detallado en la sección anterior, así que ahora nos centraremos en crear el proyecto Spring para usarla. Si empezamos por la dependencias necesarias, además del propio core de Spring vamos a necesitar MVC y algunos espacios de nombres (JSTL, Apache Taglibs). Esto es, tendremos algo similar al fragmento C.9 del anexo. Tras esto, siguiendo los principios de la arquitectura MVC de Spring, definimos un servlet que escuche todas las peticiones, las redirija a un JSP cuyo controlador renderice algo similar a lo que obteníamos antes. No merece la pena comentar al detalle 60 5.1. EVALUACIÓN JAVAEE VS SPRING todo lo necesario para montar la aplicación web con MVC, pues en la documentación de Spring encontramos bastante información. Sin embargo, en el C.10 del anexo mostramos cómo sería este controlador. Cabe destacar que, salvo las particularidades de MVC, el código es casi idéntico al que escribimos en C.6. 5.1.3 Eligiendo un framework para la biblioteca Habiendo realizado este estudio detallado, Spring parece ser la solución ideal en cuanto a portabilidad de servidores, mientras que JavaEE nos aporta la estabilidad y respaldo que unos estándares sólidos nos ofrecen. Es una decisión compleja y, con objeto de facilitar la integración con otros proyectos, la opción más indicada sería Spring. No obstante, puesto que JavaEE no se encuentra en los planes de estudio de la titulación y el autor del presente proyecto tiene experiencia laboral previa con este este stack tecnológico, hemos decidido realizar este framework para realizar la implementación. 61 CAPÍTULO 5. ESTUDIO TECNOLÓGICO 62 DISEÑO PARTE IV 6 REQUISITOS 65 Failure comes only when we forget our ideals and objectives and principles. Jawaharlal Nehru (1889–1964), First Prime Minister of India En este capítulo se pretende establecer los objetivos generales del proyecto a fin de poder comenzar con la arquitectura propuesta para la solución. CAPÍTULO 6. REQUISITOS 6.1 REQUISITOS TECNOLÓGICOS Como ya vimos en §4.3.10, el modelo de cobro y gestión de una API es una tarea compleja y, justo por ello, existen numerosas soluciones de terceros, tanto comerciales como Open Source, que nos facilitan la tarea. Sin embargo, casi todas las plataformas se centran en lo mismo: limitar peticiones y establecer planes en función de las características que se ofrecen. Si asumimos que existe una biblioteca para la gestión de acuerdos a nivel de servicio, podríamos usarla directamente y tendríamos una API con acuerdos explícitos. No obstante, el objetivo del proyecto es distinto: se pretende crear una biblioteca que cualquier API pueda incorporar y que, con añadir un acuerdo explícito, sea suficiente para obtener una API que gestione las limitaciones de peticiones basado en SLA. 6.1.1 Caso de estudio Para motivar nuestro proyecto en un caso real, en la Figura §6.1 encontramos un plan de precios de una API comercial. Figura 6.1: Pricing plan de Semantics3. En concreto, en la Figura §6.1 se muestra el plan de precios de la empresa Seman- 66 7.2. ARQUITECTURA DE AML mos del modelo del acuerdo y podemos evaluar expresiones sobre el mismo. A nivel conceptual y de forma simplificada, los elementos que conforman la Agreement Management Library son los que observamos en la Figura §7.4. Figura 7.4: Diagrama simplificado de AML. 7.2.1 WS-Agreement y acuerdos Antes de nada, conviene mencionar la estructura de un documento de acuerdo formalizado en WS-Agreement a través de la Figura §7.5 perteneciente a la Sección 2.2 de [9]. Hablar con detalle de la formalización de un documento de acuerdo y la negociación entre plantilla, oferta y acuerdo definitivo sería una tarea que se escapa de los objetivos del presente trabajo de fin de grado y además ha sido un tema ampliamente tratado en numerosas publicaciones del grupo de investigación. No obstante, es preciso dar nociones básicas que permitan comprender, a grandes rasgos, las características de un acuerdo a nivel de servicio. Un SLA definido en WS-Agreement debe contener un identificador de acuerdo, un contexto de acuerdo y unos términos de acuerdo: 1. El contexto tiene información general sobre el propio acuerdo, el tiempo de vida, métricas y tipos de datos del dominio de éstas. 2. Los términos clasifican en dos grupos: los términos del servicio y los términos de 73 CAPÍTULO 7. ARQUITECTURA Figura 7.5: Estructura de un documento WS-Agreement. garantía: a) Los términos del servicio definen las características del servicio y se diferencian según su objetivo en: 1) Referencia del servicio:endpoint de la interfaz del servicio. 2) Descripción del servicio: características del servicio acordadas entre consumidor y proveedor. 3) Propiedades del servicio: especifican las variables monitorizables que serán usadas para definir los términos de garantía. Estas propiedades deben estar especificadas en las métricas definidas en el contexto. b) Los términos de garantía (Guarantee Term GT) especifican las diferentes expresiones (Service Level Objective SLO) que el respondedor (usualmente, el proveedor del servicio) debe cumplir. Además, estos términos pueden tener 74 7.2. ARQUITECTURA DE AML una condición de aplicación (Qualifying Condition, QT) que determina si esa expresión debe ser usada o no. Finalmente, se pueden añadir compensaciones, esto es, recompensas o penalizaciones. De esta forma, un GT con compensaciones determinaría si el consumidor o proveedor puede solicitar una recompensa o debe ser penalizado. Mediante el diagrama de clases adaptado de [9] de la Figura §7.6 representamos las distintas partes que conforman un término de garantía. Nótese que la coloración gris indica que actualmente AML no ofrece soporte a compensaciones en acuerdos [14]. En definitiva, estos términos de garantía nos servirán para modelar las restricciones sobre las peticiones dentro de los planes de precio de una API. Definiendo una variable (property) donde actualicemos el valor del número de peticiones del usuario en concreto, basta con evaluar el término de garantía correspondiente para determinar si una petición es aceptada o no. En el fragmento 7.1 vemos un ejemplo. 1Template IDENTIFICADOR version 1.0 2Initiator: "NOMBRE DEL INICIADOR DEL SERVICIO"; 3Provider "NOMBRE DEL PROVEEDOR" as Responder; 4Metrics: 5int: integer[0..10000]; //rango a elegir 6AgreementTerms 7Service NOMBRE DEL SERVICIO availableAt "ENDPOINT DEL SERVICIO" 8GlobalDescription 9MonitorableProperties 10 global: 11 REQUEST_VAR: int = 0; 12 GuaranteeTerms 13 GT_NAME: Consumer guarantees REQUEST_VAR <=MAX_REQUESTS; // ,→MAX_REQUESTS es fijo 14 EndTemplate Código 7.1: Estructura de acuerdo. En este caso, el término de garantía GT_NAME evalúa que REQUEST_VAR <= MAX_REQUESTS. Estos nombres pueden ser escogidos libremente, pero han de ser indicados de alguna forma a la hora de usar nuestra propuesta. Este tema será tratado en la siguiente sección. 75 CAPÍTULO 7. ARQUITECTURA Figura 7.6: Diagrama de clases de los términos de garantía de un acuerdo. 76 IMPLEMENTACIÓN PARTE V 8 IMPLEMENTACIÓN DE AGL 79 Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure. Melvyn Conway (1967), Computer Scientist Este es el capítulo central del presente trabajo de fin de grado, donde se realiza el desarrollo de la solución anteriormente propuesta. En primer lugar se realiza un resumen de las tecnologías sobre las que se realiza el proyecto. Posteriormente se entra en los detalles de la implementación, desde la importación de AML, la creación de la anotación, el desarrollo del filtro y la generación de una API REST que muestre el estado del acuerdo en cada instante. CAPÍTULO 8. IMPLEMENTACIÓN DE AGL 8.1 STACK TECNOLÓGICO Entramos ya en el núcleo de este proyecto, la implementación de la solución propuesta en este trabajo de fin de grado. Conviene antes destacar las tecnologías que van a ser usadas. Además, en la Figura §8.1 se aprecia un diagrama que condensa esta información. Lenguaje: Java. Framework: Java EE 7. Elementos destacables: Servlet 3.1, Annotations 1.2, JPA 2.1, EJB 3.2, CDI 1.1, MySQL 5.6 Especificación de servicios web: JAX-RS (2.0), con implementación de Jersey. Servidor de aplicaciones: Glassfish 4.1. Figura 8.1: Representación del stack tecnológico empleado. 80 8.2. DESARROLLO 8.2 DESARROLLO 8.2.1 Importación de AML El desarrollo de este proyecto es la parte principal que nos ocupa, pues tras realizar todo lo que aquí se detallará dispondremos de un JAR que cualquier proyecto Java podrá importar para hacer uso de los servicios de gestión de peticiones basada en acuerdos explícitos. En primer lugar es necesario importar la biblioteca AML de forma similar a como hicimos en §5. La única diferencia es que la gestión de dependencias se realiza directamente con Maven, pues el grupo tiene un repositorio Nexus de artefactos JAR desplegado en la red. En el fragmento 8.1 se encuentra lo que debemos añadir al pom.xml, además de las dependencias necesarias de la API de JavaEE. 1<repositories> 2<repository> 3<id>AML-releases</id> 4<name>ISA</name> 5<url>http:// clinker.isagroup.es/ nexus/ content/ repositories/ ,→AML</url> 6</repository> 7</repositories> 8 9<dependencies> 10 <dependency> 11 <groupId>es.us.isa</groupId> 12 <artifactId>AML</artifactId> 13 <version>0.1.2</version> 14 </dependency> 15 </dependencies> Código 8.1: Extracto del POM del proyecto. Una vez que hemos importado AML, es necesario instanciar la biblioteca. Para ello, y aprovechando las ventajas de JavaEE, definimos un bean con scope de aplicación (en definitiva, no es más que una implementación del patrón singleton dentro del contexto de CDI) que instancie AML y tenga un método que produzca tal objeto. Nótese que con este diseño, nos desacoplamos de la versión de la biblioteca; al estar en un contexto 81 CAPÍTULO 8. IMPLEMENTACIÓN DE AGL de inyección de dependencias e inversión del control, basta con anotar un método con @Produces y en otro sitio inyectar un objeto del mismo tipo. En el fragmento 8.2 se puede apreciar, el código completo se encuentra en el C.20 del Anexo. 1@ApplicationScoped 2public class AMLHandler{ 3@PostConstruct 4public void init() { 5am=new AgreementManager(); 6} 7@Produces 8public AgreementManager getAML() { 9return am; 10 } 11 } Código 8.2: Fragmento de la clase AgreementsServlet. Como se puede ver en las líneas 3-6, basta con realizar la instanciación en el método anotado como @PostConstruct y luego devolverlo en el getter, líneas 7-10. 8.2.2 Creación de @SLA Una vez realizado esto podemos hacer uso de todas las funcionalidades que AML ofrece. Sin embargo, puesto que queremos ofrecer una forma sencilla para que una API REST la use, vamos a introducir una anotación propia que debemos crear. Esta tarea es sencilla, tal y como se observa en el fragmento 8.3. Nótese que las líneas 1-4 son otras anotaciones que describiremos y la 5 es la propia declaración de la interfaz. 1@SLA 2@Retention(RetentionPolicy.RUNTIME) 3@Target({ElementType.TYPE, ElementType.METHOD}) 4@NameBinding 5public @interface SLA { 6} Código 8.3: Anotación SLA. En primer lugar, declaramos la @interface SLA sin ningún método. Además dicha interfaz la anotamos con: 82 9 VALIDACIÓN 89 To infinity and beyond. Buzz Lightyear (1995), Toy Story Durante este capítulo se analizarán las soluciones propuestas anteriormente para que, dada una API inicial, se realice la autorización de peticiones basada en una cuota determinada. Estas soluciones son: sin usar ninguna biblioteca de gestión de SLAs, usando AML y, finalmente, empleando AGL. CAPÍTULO 9. VALIDACIÓN Tras haber mostrado la solución propuesta es preciso analizar si es realmente necesario el uso de una biblioteca que nos facilite la gestión de la autorización de peticiones en función de un acuerdo explícito. Por un lado, es posible realizar otros diseños que no requieran ningún concepto de SLA y por otro, podemos usar AML directamente, sin depender de JavaEE ni añadir más dependencias al proyecto base. Por lo anterior, es importante la existencia de este capítulo, donde se explicita cómo, dada una API inicial, realizar la autorización de peticiones basada en una cuota determinada de tres formas distintas: sin usar ninguna biblioteca de gestión de SLAs, usando AML y, finalmente, empleando AGL. 9.1 IMPLEMENTACIÓN BASE En el caso de no emplear ninguna biblioteca, debemos guardar de alguna forma la relación entre tokens y número de peticiones disponibles. En el caso más sencillo, asumimos que se trata de un simple mapa en memoria donde a cada cadena de texto se le asigna un determinado entero. En un caso real usaríamos JPA o algún otro tipo de persistencia. El mapa se crea sobre un singleton que realiza la inicialización de la instancia del handler y crea una entrada en el mapa por cada uno de los usuarios de la API. Además, ofrece una pequeña fachada del mapa creado para hacer más sencilla la lógica del filtro. El código completo puede verse en el C.12 del Anexo. La lógica sobre si una petición debe o no ser aceptada es extremadamente simple, tal y como se puede apreciar en 9.1. 1private boolean authorizeRequest(HttpServletRequest req) { 2Integer availableRequests = Helper_noAML.getInstance(). ,→getAvailableRequestsFromUser(clientId); 3return availableRequests > 0 || availableRequests == -1; 4} Código 9.1: Método authorizeRequest sin biblioteca. Dada una petición, hemos extraído el token del usuario y con eso podemos obtener peticiones restantes del mapa en memoria. Si tiene al menos una petición disponible (o es -1, para contemplar planes ilimitados). Si la petición fue aceptada, es preciso decrementar el número de peticiones dispo- 90 9.2. IMPLEMENTACIÓN BASADA EN AML nibles (o dejarlo como está en planes ilimitados). Esto puede verse en 9.2. 1private void requestDone(HttpServletRequest req) { 2Integer availableRequests = Helper_noAML.getInstance(). 3getAvailableRequestsFromUser(clientId); 4if (availableRequests > 0) { 5availableRequests--; 6Helper_noAML.getInstance(). 7setRequests(clientId, availableRequests); 8} 9} Código 9.2: Método requestDone sin biblioteca. Una gran ventaja de la arquitectura que hemos usado es que permitimos que el servlet sea ajeno a toda la lógica de autorizaciones, pues usamos un filtro (o cadena de filtros, en el caso más general), para realizar estas tareas. 9.2 IMPLEMENTACIÓN BASADA EN AML Para trabajar con una biblioteca de gestión de acuerdos, como AML, es preciso disponer de un acuerdo formalizado en alguna especificación, como iAgree. La implementación no es demasiado compleja una vez que se conoce el modelo de datos del acuerdo. Es importante que la biblioteca nos ofrezca operaciones de alto nivel para simplificar el acceso al modelo. Siguiendo la arquitectura descrita en la introducción, en primer lugar debemos inicializar el sistema cargando las plantillas y registrando los usuarios de prueba con sus correspondientes acuerdos. Esta tarea la realizará una clase Helper singleton que tendrá también la instanciación de la biblioteca de gestión de acuerdos. Si bien la clase completa se puede encontrar en C.17 del Anexo, la parte fundamental se aprecia a continuación en 9.3. 1private static void init() { 2agr = new AgreementManager(); 3agr.getStoreManager().registerFromFolder (new ,→File("files").getAbsolutePath(), false); 4} 5 91 CAPÍTULO 9. VALIDACIÓN 6private static void loadTestAgreements() { 7loadTestAgreement("basicPlanT", "basicUser1"); 8loadTestAgreement("basicPlanT", "basicUser2"); 9loadTestAgreement("mediumPlanT", "mediumUser1"); 10 loadTestAgreement("mediumPlanT", "mediumUser2"); 11 loadTestAgreement("proPlanT", "proUser1"); 12 loadTestAgreement("proPlanT", "proUser2"); 13 } 14 15 private static void loadTestAgreement(String templateName, String ,→clientId) { 16 agr.getStoreManager(). getAgreementTemplate(templateName). ,→generateAgreementOffer(clientId). ,→generateAgreement(clientId). register(clientId); 17 } Código 9.3: Inicialización de la clase Helper con AML Lo que aquí se hace es sencillo: se instancia la biblioteca con la configuración por defecto, aunque se le podría pasar un JSON para configurarla de forma determinada, la instanciamos, cargamos las plantillas desde fichero y las registramos en la biblioteca. Posteriormente creamos el acuerdo a partir de la plantilla (en este caso basta con clonarla) y lo registramos. Con lo anterior ya tenemos el sistema en operación. Estudiemos ahora qué ocurre si llega una petición: el método authorizeRequest del filtro es el responsable de responder, por lo que deberá cargar el acuerdo correspondiente al cliente que ha efectuado la petición y comprobar el número de peticiones realizadas a través de la Monitorable Property correspondiente. Con esto, basta con evaluar el Guarantee Term correspondiente Si bien el filtro completo se encuentra en C.18, la parte fundamental la podemos ver en 9.4. 1private boolean authorizeRequest(HttpServletRequest req) { 2Agreement agreement = ,→agr.getStoreManager().getAgreement(clientId); 3if (agreement != null) { 4return agreement.evaluateGT("RequestTerm"); 5} 6return false; 7} 92 9.3. IMPLEMENTACIÓN BASADA ES AGL Código 9.4: Método authorizeRequest con biblioteca. Tras esto ya sabemos si una petición debe o no ser aceptada pero aún falta el último paso: actualizar incrementar el valor de las peticiones realizadas. En este ejemplo, es bastante sencillo, pues basta con acceder a la Monitorable Property, incrementarla y actualizar su valor en el modelo del acuerdo. Esto lo vemos en 9.5. 1private void requestDone() { 2Integer numReq; 3Agreement agreement = agr.getStoreManager(). ,→getAgreement(clientId); 4if (agreement != null) { 5if (agreement.getProperty("Requests"). ,→getExpression() == null) { 6agreement.setProperty("Requests", 0); 7} 8numReq = agreement. ,→getProperty("Requests").intValue(); 9numReq++; 10 agreement.setProperty("Requests", numReq); 11 } 12 } Código 9.5: Método requestDone con biblioteca. No obstante, en un caso más real, podríamos invocar a este método sólo en el caso de las peticiones exitosas o tener varios contadores y decidir en función de ellos. 9.3 IMPLEMENTACIÓN BASADA ES AGL Al igual que en la sección anterior y puesto que seguimos trabajando con una biblioteca de gestión de acuerdos, es preciso disponer de acuerdos formalizados. En este caso además, imponemos que la API a la que le vamos a añadir el control de peticiones está realizada mediante JAX-RS. En §8.2.4 ya vimos cómo se ponía en marcha una API diseñada siguiendo esta especificación. Asumimos que esta API o proyecto base se encuentra en un proyecto Maven. A continuación añadimos la dependencia del artefacto generado por la biblioteca y ya 93 CAPÍTULO 9. VALIDACIÓN podemos hacer uso de las clases que hemos desarrollado en este proyecto. Esto se aprecia en el fragmento 9.6. 1<dependency> 2<groupId>${project.groupId}</groupId> 3<artifactId>tfg-api-gateway</artifactId> 4<version>${project.version}</version> 5</dependency> Código 9.6: Extracto del POM del proyecto base. Con esto, ya podemos anotar los métodos que sean susceptibles de controlar las peticiones que se le realizan, tal y como se aprecia en el fragmento 9.7. Nótese que para el resto de métodos, la lógica es similar. 1@GET 2@Path("{id}") 3@SLA() 4@Produces(MediaType.APPLICATION_JSON) 5public Bird find(@PathParam("id") Integer id) { 6return super.find(id); Código 9.7: Extracto de un método de la API anotado con @SLA. Por otro lado debemos inicializar el sistema cargando las plantillas y registrando los usuarios de prueba con sus correspondientes acuerdos, esto es un código muy similar al que mostramos en la sección anterior (fragmento 9.3 y C.17 del Anexo). Finalmente, puesto que disponemos del código de ambos proyectos, modificamos el código del fichero de configuración (Configuration.properties) para adaptar los nombres a los usemos en el acuerdo. Una vez hecho eso, tenemos una API guiada por SLAs en los métodos que hayamos anotado. 9.4 COMPARATIVA Hemos visto que podemos solucionar el problema de forma programática sin necesidad de usar acuerdos a nivel de servicio, aunque también se proponen dos soluciones usando una biblioteca externa que facilita la tarea. Llegados a este punto conviene analizar todos los casos y compararlos de forma objetiva. 94 9.4. COMPARATIVA Veamos un resumen de los pasos a dar en cada uno de los casos estudiados antes: Implementación base: 1. Persistir de alguna forma el par token-peticiones. 2. Crear filtro que compruebe si el número de peticiones del usuario ha sido excedido. 3. Actualizar número de peticiones y persistir. Implementación basada en AML: 1. Definir acuerdos y formalizarlos en iAgree o WS-Agreement. 2. Instanciar AML por defecto o con configuración personalizada. 3. Cargar los acuerdos y crear sistema de asignación de estos al usuario. 4. Crear filtro que evalúe los términos de garantía deseados del acuerdo. 5. Actualizar la Monitorable Property correspondiente a las peticiones. Implementación basada en AGL: 1. Definir acuerdos y formalizarlos en iAgree o WS-Agreement. 2. Importar proyecto AGL al proyecto base en JAX-RS. 3. Anotar métodos que vayan a ser monitorizados por el filtro con @SLA. 4. Adaptar el archivo de configuración a la nomenclatura del acuerdo. La opción más rápida quizás sea no emplear ningún tipo de acuerdo y codificar la lógica manualmente. Esto es adecuado si se trata de una API sencilla o el plan de precios es muy simple; sin embargo, en cuanto la complejidad o el tamaño aumenta, la mejor forma de mantener el sistema escalable quizás sea desacoplando la lógica de la autorización de peticiones de la de la API. Puesto que los SLAs son ya ampliamente usados, con un esfuerzo inicial al realizar la formalización, obtenemos grandes ventajas. 95 CAPÍTULO 9. VALIDACIÓN 96 MANUALES PARTE VI 10.4. USANDO @SLA EN LA API 3queryParamToken=user Código 10.4: Ejemplo de configuración para el acuerdo de PapamoscasAPI. 10.4 USANDO @SLA EN LA API Con esto, ya podemos anotar los métodos que sean susceptibles de controlar las peticiones que se le realizan, tal y como se aprecia en el fragmento 10.5. Nótese que para el resto de métodos, la lógica es similar. 1@GET 2@Path("{id}") 3@SLA() 4@Produces(MediaType.APPLICATION_JSON) 5public Bird find(@PathParam("id") Integer id) { 6return super.find(id); Código 10.5: Extracto de un método de PapamoscasAPI anotada con @SLA. Por otro lado debemos debemos inicializar el sistema cargando las plantillas y registrando los usuarios de prueba con sus correspondientes acuerdos, esto es un código muy similar al que ya hemos visto. Se puede encontrar en el C.24 del Anexo. 10.5 PROBANDO EL SISTEMA Una vez que hemos seguido todos pasos anteriores, podemos comenzar a hacer pruebas con diferentes usuarios y SLAs que definamos. En particular, en este ejemplo se han creado dos usuarios de cada tipo; además las cuotas por defecto de cada usuario son las mostradas en la Figura §10.5. 1. A continuación realizamos una petición de tipo GET sobre el recurso LOCALHOST:PORT/API /V3/BIRDS?USER=PROUSER1. Si antes no hemos hecho POST el resultado será vacío, pero en cualquier caso, se sirve la petición. 2. Ahora repetimos el caso de prueba, pero cambiando el token de usuario por basicUser1. Realizamos diez peticiones con este usuario y, a la undécima vez, un código de error nos es enviado, tal y como se muestra en la figura §10.6 105 CAPÍTULO 10. MANUAL DE USO DE AGL Figura 10.5: Usuarios y cuotas por defecto. Figura 10.6: Error mostrado al alcanzar el límite. Habiendo realizado lo anterior de forma satisfactoria, veamos qué partes podemos cambiar con facilidad para obtener un funcionamiento distinto. En primer lugar podríamos editar las plantillas de acuerdos. Actualmente hay tres planes que se pueden alterar como se desee antes de desplegar la aplicación. En concreto, podemos cambiar el Guarantee Term RequestTerm: Consumer guarantees Requests <=10; y así controlar el número de peticiones deseado. Otro aspecto fácil de modificar es la inicialización de usuarios. Desde el método loadTestAgreements() podemos cambiarlo. En caso de querer añadir una plantilla de acuerdo más, basta con añadirlo a la carpeta, cargarlo y luego añadir un usuario como arriba se comenta. 106 CONCLUSIONES PARTE VII 11 CONCLUSIONES 109 Space... the final frontier. William Shatner (1966), Star Trek Llegados al final de este trabajo de fin de grado conviene realizar un análisis del proyecto, por ello, en el presente capítulo se realiza una evaluación final del mismo, destacando los hechos relevantes durante el transcurso del mismo. Finalmente se proponen y analizan diversas propuestas de extensiones o líneas de trabajo futuras. CAPÍTULO 11. CONCLUSIONES 11.1 EVALUACIÓN FINAL DEL PROYECTO Si queremos diseñar una API para comercializarla en mercado se han de resolver una serie de problemáticas como la gestión, control y limitación del número de peticiones realizadas a una API. Tras un análisis del estado del arte en el contexto de APIs ySoftware as a Service que nos llevó a un estudio de las soluciones de API Gateway que existen en el mercado actualmente, concluimos que no existía ninguna solución basada en acuerdos a nivel de servicio explícitos. El hecho de obtener una API guiada por SLAs nos permite desacoplar la lógica de negocio de lo fundamental de la aplicación, cosa que favorece la evolución del sistema y facilita el mantenimiento. El presente trabajo de fin de grado se enmarca dentro de las líneas investigadoras del grupo de Ingeniería del Software Aplicada (ISA), en concreto, en un proyecto de governanza de SaaS y API en entornos cloud con soluciones basadas en SLAs en el que se ha seguido un proceso iterativo para conseguir los resultados planificados. Desde el punto de vista de los objetivos técnicos, estos han sido completamente satisfechos, pues hemos realizado un estudio del arte en el contexto de APIs y Gateways y hemos desarrollado una prueba de concepto funcional y extensible. Por otro lado, los objetivos académicos que se habían plantando han sido igualmente satisfechos, pues ya existe dentro del grupo una visión a corto plazo de avanzar y mejorar los resultados que se han alcanzado en este proyecto. Gracias a este proyecto se ha desarrollado un artículo para un congreso nacional de referencia en ingeniería de servicios (Jornadas de Ciencia e Ingeniería de Servicios, JCIS), cosa que ha supuesto la primera producción investigadora del autor del presente trabajo de fin de grado. 11.2 TRABAJO FUTURO En este trabajo se muestra una prueba de concepto que demuestra que el uso de un acuerdo formalizado puede ser usado para tareas de nivel operativo, por ejemplo, para autorizar peticiones y dar así soporte a los diversos modelos de cobro que puedan existir. Por ello, una primera vía de actuación sería seguir investigando en esta línea a fin de desarrollar una biblioteca de gestión de APIs mucho más versátil y con mayor funcionalidad. 110 11.2. TRABAJO FUTURO Por otro lado, puesto que limitamos que la API esté basada en JAX-RS, una posible mejora tecnológica sería dar soporte a APIs realizadas con Spring en vez de JavaEE. De este modo se cubriría gran parte del mercado de APIs desarrolladas en Java. Otra mejora tecnológica podría consistir en añadir un cierto paylaod a la anotación, de forma que cada método pudiera especificar modificadores que afectaran en el cómputo de las propiedades y términos de garantía. Por ejemplo, con @SLA(cost=2) podemos definir que el uso de ese recurso consume dos unidades en vez de una. A nivel de investigación en el marco de los acuerdos a nivel de servicio ya existen líneas de trabajo activas y hay diversas actuaciones planificadas relacionadas con este proyecto. 111 CAPÍTULO 11. CONCLUSIONES 112 ANEXOS PARTE A.4. PRICING PLANS IN API GATEWAYS From the 13 API Gateways studied we have selected 13 criteria in order to compare all of them. In Figure §A.4 we illustrate that comparison4, where a cell Cij marked with an xmeans that platform ihas the property j, and we provide some examples extracted from the same table. Security: •Basic Authentication (Q1): it supports basic authorization methods (e.g. Mashape let us configure authentication by a HTTP header, a query parameter and an API key). •Advanced Authentication (Q2): it supports advanced authorization methods (e.g. Apigee offers OAuth and LDAP authentications). •Attacks protection (Q3): it includes a way to protect itself from attacks (e.g. CA prevents our API from DoS attacks). Pricing plans support: •Free Tier (Q4): it has a free plan with basic features or limited by somehow (e.g. 3Scale offers a basic tier with 50 thousand calls per day for free). •Requests limit (Q5): there exists a way to establish quotas per user (e.g. with Azure it is possible to limit API calls by user to a custom value). •Enterprise Plans (Q6): it offers customized plans for enterprise clients (e.g. 3Scale let enterprise clients configure unlimited APIs with a guaranteed availability). Lifecycle control: •API versions (Q7): it supports versioning (e.g. Axway let us set different versions from the same API). •Orchestration (Q8): there exists a way to orchestrate RESTful services in terms of SOA governance (e.g. Akana let us control complete API lifecycle and orchestrate all services involved). Other features: 4The reference of all studied API Gateways can also be found at: goo.gl/0n8cPr 123 APÉNDICE A. TOWARDS SLA-DRIVEN API GATEWAYS •OpenSource (Q9): the code is available to anyone (e.g. WSO2 and API Umbrella are both Open Source solutions). •Load balancing (Q10): it makes possible to do load balancing between various API servers (e.g. API Umbrella balance the requests between our backend). •Cache (Q11): it includes request caching in order to reduce the effective API calls amount (e.g. Apigee save the API responses in order to serve the same data if there is no changes). •Response conversion (Q12): it gives the possibility of converting API response into another language (e.g. Akana perform a JSON to SOAP conversion). •Documentation (Q13): it generates a developer portal with API documentation (e.g. Mashape generate an interactive documentation and a playground where developers can make requests). 3Scale is an API gateway service provider who let us connect up to 3 different APIs with a daily traffic close to one million requests. It is possible to establish requests filtering policies based upon trusted API keys, black and whitelisting or OAuth authentication. In order to create billing plans, we could limit the requests amount per user and create a billing for that use or simply a billing plan based upon the requests that a user has made; it is also possible to create trial plans. Besides these core features, it also offers several statistics, a developer portal, documentation generation and different ways to deploy the reverse proxy towards 3Scale. Almost all API gateway studied services offer the same core functionality: request authorization and quota establishment so that various billing plans could be created. It might be enough for few APIs that do not need a more complex business billing logic, but does not allow to introduce all business logic we may need. A.5 RESEARCH CHALLENGES We propose API Gateways based on SLAs. We have analyzed API properties and billing needs and how third-party API Gateways solutions could be useful to solve this problem. Nevertheless, there are some API requirements that are not satisfied by the previous solution, so the only possibility is to code it manually into the API code. This implies an increasing error probability and a coupling API code itself with API 124 A.5. RESEARCH CHALLENGES Figura A.4: API Gateways comparative. management one. Previously we have shown the importance of considering SLAs in our design, therefore we focus on a SLA-Driven solution. In this section we analyze these requirements and we try to identify other ones that could appear in a different scenario. Finally, we propose several research challenges in order to establish a road-map to focus our researches on. We can identity new requirements that could be met by a theoretical API that use a SLA based pricing plan. Challenge 1: supporting temporarily in pricing plans. As current API gateways are static, if an API pricing plan depends on the moment that the API is called, it would be necessary to code this logic manually. It is possible to find more examples, such as support plan life-time (i.e. when it starts and expires) or time periods for guarantee terms (e.g. availability level is guaranteed only during Monday- 125 APÉNDICE A. TOWARDS SLA-DRIVEN API GATEWAYS Friday working hours). In this way, we have dynamics and elastic pricing plans, regulated according to demand cycles. In [10], [12] and [11] authors analyze formal temporarily in SLAs. Challenge 2: adding a more fine-grained configuration by supporting other features and metrics than the requests amount. An API could define custom metrics that represent the cost for the business. For instance, metrics such as CPU time consumption, memory or storage usage. Challenge 3: adding support to compensations (penalties and rewards) according to the under-fulfillment or over-fulfillment of SLA service level objectives (SLO). For instance, API provider could be committed to serve requests in an established time; if there is a percentage of these request served out of time, provider should compensate client by certain way (e.g. claiming a refund). In [15] and [14] authors show the formal specification of a SLA with compensations. A.6 CONCLUSIONS In this paper we have shown an analysis of the state of art in API and API Gateway paradigm and propose a SLA-Driven solution in an API Gateway design. The API and SaaS management is a difficult task and there is no solution yet that help providers to automatize simple things like pricing management, feature limitation, billing based upon custom parameters, etc. Currently, service providers have to code this logic by hand or they ought to resort to third-party platforms, which involves an extra cost. We try to define the main research lines so that we could continue working on and, in the future, we could give a framework that permits APIs be managed by Service Level Agreements. 126 B MEMORIA PARA LA BECA DE INICIACIÓN A LA INVESTIGACIÓN DE LA US 127 B.1 INTRODUCCIÓN El término microservicio ha ido adquiriendo notoriedad en un contexto de la Ingeniería del Software donde el paradigma de la Computación Orientada a Servicios cuenta mayor peso actualmente. Se observa que desde una década atrás se ha hablado de arquitectura orientada a servicios (SOA) y cómo sus principios aportan valor a la organización; dichos pilares de SOA incluyen el bajo acoplamiento, abstracción, reusabilidad, autonomía e interoperatibilidad. En definitiva, elementos imprescindibles para alejarse de las arquitecturas monolíticas convencionales. Bajo la denominación de microservicio se incluyen desde servicios web de tipo REST oSOAP hasta nuevos modelos de distribución de software bajo demanda, conocidos como SaaS. De ahí que la proliferación de estos nuevos modelos han llegado a convertirlos en estándar de facto en el paradigma de la producción de software. En este contexto, las posibilidades de personalización y adaptación del servicio a cada cliente van más allá de la necesidad de integración y orquestación del servicio. Históricamente en entornos empresariales se han extendido numerosas herramientas que ofrecen soporte a los principales pilares de una arquitectura orientada a servicios: integración, orquestación, enrutado, monitorización... casi todas ellas están bajo el término Enterprise Service Bus (ESB) oEnterprise Application Integration (EAI). Actualmente las necesidades de la organización se mueven desde una integración centralizada hacia un contexto distribuido y flexible. Es por ello que ha existido un cambio de visión de la arquitectura orientada a servicios; los microservicios deben seguir dando soporte a ciertas necesidades, como la integración, publicación y descubrimiento de servicios, administración y despliegue escalable. APÉNDICE B. MEMORIA PARA LA BECA DE INICIACIÓN A LA INVESTIGACIÓN DE LA US Casi todas estas necesidades están siendo ya cubiertas en mayor o menor medida, sin embargo, la gestión y automatización de contratos de servicios está aún sin resolver de una forma consensuada; entendiendo contrato como el compromiso y acuerdo alcanzados entre el consumidor y el productor del servicio. Para esta tarea cada organización emplea sus propias estrategias, pero casi todas confluyen en sistemas de monitorización ligados a un acuerdo en lenguaje natural. En este contexto, el presente proyecto de investigación se enfoca en estudiar las formas de mejorar la gestión y automatización de acuerdos a nivel de servicio (SLA) en microservicios que permiten la personalización y adaptación al cliente y, en concreto, su relación con los nuevos modelos Software as a Service (SaaS). B.2 BACKGROUND DEL EQUIPO INVESTIGADOR Este proyecto se enmarca dentro de las líneas investigadoras del grupo de Ingeniería del Software Aplicada (TIC205) de la Universidad de Sevilla, coordinado por el Dr. Antonio Ruiz Cortés; en un contexto de Líneas de Productos, Métodos Formales Aplicados a Familias de Procesos y de Productos, Ingeniería de Requisitos, Sistemas Complejos y, sobre todo, Computación Orientada a Servicios. En concreto, el proyecto de investigación guarda estrecha relación con el proyecto financiado por el Ministerio de Economía y Competitividad Tecnologías Avanzadas para Procesos como Servicios (TIN2012-32273). Este proyecto incluye entre sus principales metas el soporte a servicios que puedan personalizarse de acuerdo a las necesidades del cliente y correr en la nube, un claro caso de necesidad de aplicación de acuerdos a nivel de servicio. El grupo de investigación ha sido pionero y referente internacional en la formalización de acuerdos desde hace una década. En este marco, destacan artículos como [17], automatizando el análisis de conflictos de SLA tratándolo como problemas de satisfacción de restricciones (CSP); [14], ofreciendo una explicación de las violaciones al acuerdo en tiempo de ejecución mediante una herramienta de monitorización; [15], dando un modelo para la creación de SLA con penalizaciones o recompensas según el cumplimiento de objetivos de nivel de servicio (SLO) y [4], dando herramientas para la edición y validación de documentos de acuerdos formalizados en lenguajes estándares como WS-Agreement. 128 B.3. OBJETIVOS Varias tesis doctorales han sido realizadas también en este campo, por ejemplo, [8], donde se estudia la relación entre servicios web y la programación con restricciones; y [13], donde se define un lenguaje alternativo para la formalización de acuerdos y se realiza la correspondencia con operaciones de análisis de tipo CSP. B.3 OBJETIVOS Todos los objetivos del plan de trabajo van destinados a converger con la línea investigadora del grupo, además de pretender sentar una base sólida sobre la que poder continuar en futuras investigaciones. En concreto, definimos dos objetivos fundamentales: 1. Analizar el estado del arte en acuerdos de servicios reales. 2. Desarrollar los principales requisitos de un futuro framework para el gobierno de SaaS. En primer lugar, se pretende realizar un estudio detallado de los acuerdos en servicios reales y mayoritariamente usados para así tener una visión más completa y detallada de las necesidades a satisfacer en fases más avanzadas del proyecto. Los servicios a analizar se dividen, principalmente, en dos tipos, las APIs y los proveedores de SaaS. Por otro lado, y en relación con el segundo objetivo fundamental, se estudiarán las herramientas existentes en el mercado para proporcionar soporte a la gestión de microservicios. En particular, se verán distintos proxies de APIs que ofrecen valor al desarrollador y consumidor de la misma. Toda esta investigación pretende confluir en la identificación de los requisitos que un framework para el gobierno de aplicaciones con modelo de Software como Servicio debe satisfacer. Con esto se pretenden sentar unas bases sólidas sobre las que apoyar una futura investigación y desarrollo de la plataforma que ofrezca un soporte eficaz y logre solucionar los problemas y deficiencias actuales en el gobierno de las arquitecturas basadas en microservicios. 129 APÉNDICE B. MEMORIA PARA LA BECA DE INICIACIÓN A LA INVESTIGACIÓN DE LA US B.4 PLAN DE TRABAJO Durante las 8 semanas durante los meses de julio y septiembre de 2015 se estima la siguiente planificación: Resumen de la planificación Julio Semana 1 Introducción al contexto del problema. Semana 2 Identificación de plataformas SaaS yAPIs a estudiar. Semana 3 Estudio de proveedores de APIs. Semana 4 Estudio de proveedores SaaS. Septiembre Semana 5 Recapitulación de resultados obtenidos. Semana 6 Identificación de requisitos y necesidades primarias. Semana 7 Análisis e identificación de requisitos secundarios. Semana 8 Análisis final y valoración de resultados. Cuadro B.1: Tabla resumen de planificación semanal. La carga de trabajo se ha repartido a razón de 70/30 entre los dos objetivos fundamentales identificados, siendo la planificación coherente con tal reparto. No obstante, es susceptible de cambios en función de los resultados que se vayan obteniendo. 130 C CÓDIGOS 131 11 < 13 > { } =[100%]=> < 13 > Analíticas; 22 < 13 > Analíticas =[92%]=> < 12 > BasiAuth; 33 < 9 > Cuotas Analíticas =[89%]=> < 8 > BasiAuth; 44 < 7 > FreeTier Analíticas =[100%]=> < 7 > BasiAuth; 55 < 7 > Analíticas Portal =[86%]=> < 6 > Cuotas; 66 < 7 > Analíticas Portal =[86%]=> < 6 > BasiAuth; 77 < 5 > OpenSource Analíticas =[100%]=> < 5 > FreeTier BasiAuth; 88 < 5 > AdvAuth Analíticas =[100%]=> < 5 > BasiAuth; 99 < 5 > Planes Analíticas =[100%]=> < 5 > BasiAuth Cuotas; 10 10 < 6 > Cuotas Analíticas Portal =[83%]=> < 5 > BasiAuth; 11 11 < 4 > Analíticas Versionado =[100%]=> < 4 > BasiAuth AdvAuth; 12 12 < 4 > Analíticas Conversión =[100%]=> < 4 > Cuotas; 13 13 < 4 > Analíticas Caché =[100%]=> < 4 > BasiAuth; 14 14 < 5 > BasiAuth Cuotas Analíticas Portal =[80%]=> < 4 > Planes; 15 15 < 5 > BasiAuth Planes Cuotas Analíticas =[80%]=> < 4 > Portal; 16 16 < 5 > BasiAuth AdvAuth Analíticas =[80%]=> < 4 > Versionado; 17 17 < 5 > BasiAuth AdvAuth Analíticas =[80%]=> < 4 > Cuotas; 18 18 < 3 > FreeTier BasiAuth Planes Cuotas Analíticas =[100%]=> < 3 > ,→Portal; 19 19 < 3 > FreeTier BasiAuth Cuotas Analíticas Portal =[100%]=> < 3 > ,→Planes; 20 20 < 3 > BasiAuth AdvAuth Planes Cuotas Analíticas =[100%]=> < 3 > ,→Versionado; 21 21 < 3 > BasiAuth AdvAuth Cuotas Analíticas Versionado =[100%]=> < 3 ,→> Planes; 22 22 < 3 > BasiAuth AdvAuth Analíticas Caché =[100%]=> < 3 > ,→Versionado; 23 23 < 3 > BasiAuth Cuotas Analíticas Conversión =[100%]=> < 3 > ,→AdvAuth; 24 24 < 3 > Analíticas Protección =[100%]=> < 3 > BasiAuth AdvAuth; 25 25 < 3 > Analíticas Balanceo =[100%]=> < 3 > BasiAuth; 26 26 < 2 > FreeTier BasiAuth Analíticas Balanceo =[100%]=> < 2 > ,→OpenSource; 27 27 < 2 > BasiAuth AdvAuth Analíticas Portal =[100%]=> < 2 > Planes ,→Cuotas Versionado; 28 28 < 2 > BasiAuth AdvAuth Analíticas Versionado Protección =[100%]=> ,→< 2 > Caché; 29 29 < 2 > BasiAuth Cuotas Analíticas Caché =[100%]=> < 2 > AdvAuth ,→Planes Versionado; 30 30 < 2 > Analíticas Orquestación =[100%]=> < 2 > BasiAuth AdvAuth ,→Cuotas Conversión; 31 31 < 1 > OpenSource FreeTier BasiAuth Planes Cuotas Analíticas ,→Portal =[100%]=> < 1 > AdvAuth Versionado Conversión; 32 32 < 1 > FreeTier BasiAuth AdvAuth Analíticas =[100%]=> < 1 > ,→OpenSource Planes Cuotas Portal Versionado Conversión; 33 33 < 1 > FreeTier BasiAuth Analíticas Caché =[100%]=> < 1 > ,→OpenSource Portal Balanceo; 34 34 < 1 > BasiAuth AdvAuth Planes Cuotas Analíticas Portal Versionado ,→Conversión =[100%]=> < 1 > OpenSource FreeTier; 35 35 < 1 > BasiAuth AdvAuth Planes Cuotas Analíticas Portal Versionado ,→Caché =[100%]=> < 1 > Protección; 36 36 < 1 > BasiAuth AdvAuth Planes Cuotas Analíticas Versionado ,→Conversión Caché =[100%]=> < 1 > Balanceo Orquestación; 37 37 < 1 > BasiAuth AdvAuth Planes Cuotas Analíticas Versionado ,→Conversión Orquestación =[100%]=> < 1 > Balanceo Caché; 38 38 < 1 > BasiAuth AdvAuth Planes Cuotas Analíticas Versionado ,→Protección Caché =[100%]=> < 1 > Portal; 39 39 < 1 > BasiAuth AdvAuth Cuotas Analíticas Conversión Protección ,→=[100%]=> < 1 > Orquestación; 40 40 < 1 > BasiAuth AdvAuth Analíticas Balanceo =[100%]=> < 1 > Planes ,→Cuotas Versionado Conversión Caché Orquestación; 41 41 < 1 > BasiAuth Planes Cuotas Analíticas Balanceo =[100%]=> < 1 > ,→AdvAuth Versionado Conversión Caché Orquestación; 42 42 < 1 > BasiAuth Analíticas Portal Balanceo =[100%]=> < 1 > ,→OpenSource FreeTier Caché; Código C.1: Salida del análisis formal de conceptos sobre estudio de API gateways. 1@ApplicationScoped 2public class SingletonMapBean implements Serializable{ 3private Map<Object, Map<String, Object>> map = new HashMap<>(); 132