Análisis del rendimiento de la transaccionalidad en un Api Gateway desarrollado con el paradigma orientado a objetos frente al paradigma reactivo

(1)

1

AN ´ALISIS DEL RENDIMIENTO DE LA TRANSACCIONALIDAD EN UN API GATEWAY DESARROLLADO CON EL PARADIGMA ORIENTADO A

OBJETOS FRENTE AL PARADIGMA REACTIVO

Autor

Jairo Edinson Viuche Madro˜nero

Universidad Distrital Francisco Jose de Caldas Facultad de Ingenier´ıa

Especializaci´on en Ingenier´ıa de Software Bogot´a, Colombia

(2)

2

AN ´ALISIS DEL RENDIMIENTO DE LA TRANSACCIONALIDAD EN UN API GATEWAY DESARROLLADO CON EL PARADIGMA ORIENTADO A

OBJETOS FRENTE AL PARADIGMA REACTIVO

Autor

Jairo Edinson Viuche Madro˜nero

Monograf´ıa de grado

Presentada como requisito para optar al t´ıtulo de Especialista en Ingenier´ıa de Software

Director

Dr. Roberto Ferro Escobar

Revisor

Msc. John Freddy Parra

Universidad Distrital Francisco Jose de Caldas Facultad de Ingenier´ıa

Especializaci´on en Ingenier´ıa de Software Bogot´a, Colombia

(3)

´

_{Indice de figuras}

1-1. Arquitectura microservicios con Api Gateway . . . 7

1-2. Ejemplo de composici´on de Api para un Api Gateway . . . 9

1-3. Arquitectura Api Gateway con m´ultiples clientes . . . 10

1-4. Clasificaci´on taxon´omica de los vertebrados . . . 12

1-5. Caracter´ısticas de un sistema reactivo, y como se relacionan entre s´ı . . . 14

1-6. Relaci´on en una implementaci´on del flujo reactivo . . . 15

1-7. El zoo de los paradigmas . . . 16

1-8. Arquitectura en Api de Netflix . . . 19

2-1. Funciones del Api Gateway . . . 23

3-1. Diagrama de clases Api Gateway con paradigma orientado a objetos . . . 25

3-2. Diagrama de secuencia Api Gateway con paradigma orientado a objetos . . . 26

3-3. Diagrama de componentes Api Gateway con paradigma orientado a objetos . 26 3-4. Diagrama de flujo de datos f´ısico . . . 27

3-5. Diagrama de secuencia Api Gateway con paradigma reactivo . . . 27

3-6. Concurrencia api reactivo . . . 28

4-1. Plataforma Jhipster . . . 29

4-2. Ejemplo modelo de entidades microservicio en JDL Studio . . . 30

4-3. Ejemplo lenguaje JDL en modelo de entidades para microservicio . . . 31

4-4. Contenedores docker . . . 32

4-5. Documentaci´on Swagger para microservicio . . . 32

4-6. Documentaci´on detallada Swagger para microservicio . . . 33

4-7. Archivo app.js, ejecuci´on principal del Api Gateway . . . 34

4-8. Archivo router.js, contenedor de los microservicios que se desean consumir . 35 4-9. Gateway adapter, cada microservicio realiza su uso . . . 35

4-10.Configuraci´on de enrutamiento para cada microservicio, por servicio . . . 36

4-11.Configuraci´on de archivo pom.xml del servidor eureka . . . 37

4-12.Configuraci´on general del servidor . . . 37

4-13.Clase principal de Spring boot, servidor eureka . . . 38

4-14.Dependencias pom.xml Api Gateway con spring cloud . . . 38

4-15.Otras dependencias pom.xml Api Gateway con spring cloud . . . 39

4-16.Gateway Routing con spring cloud . . . 39

(4)

4 ´INDICE DE FIGURAS

4-18.Acci´on para la optenci´on de url . . . 41

4-19.Transformador de url a request . . . 41

4-20.Consumo de servicio RestFul, microservicio . . . 41

4-21.Diagrama de despliegue de componentes del an´alisis . . . 42

5-1. Logo Jirka It Solutions SAS . . . 43

5-2. Metamodelo punto de vista de organizaci´on . . . 45

5-3. Punto de vista de organizaci´on . . . 45

5-4. Metamodelo punto de vista cooperaci´on de actor . . . 45

5-5. Punto de vista cooperaci´on de actor . . . 46

5-6. Metamodelo punto de vista de funci´on de negocio . . . 46

5-7. Punto de vista de funci´on de negocio . . . 47

5-8. Metamodelo punto de vista de proceso de negocio . . . 47

5-9. Punto de vista de proceso de negocio . . . 48

5-10.Metamodelo punto de vista de cooperaci´on de proceso de negocio . . . 48

5-11.Punto de vista de cooperaci´on de proceso de negocio . . . 49

5-12.Metamodelo punto vista de producto . . . 50

5-13.Punto vista de producto . . . 50

5-14.Metamodelo punto de vista de comportamiento de aplicaci´on . . . 51

5-15.Punto de vista de comportamiento de aplicaci´on . . . 51

5-16.Metamodelo punto de vista de cooperaci´on de aplicaci´on . . . 52

5-17.Punto de vista de cooperaci´on de aplicaci´on . . . 52

5-18.Metamodelo punto de vista de estructura de aplicaci´on . . . 53

5-19.Punto de vista de estructura de aplicaci´on . . . 53

5-20.Metamodelo punto de vista de uso de aplicaci´on . . . 54

5-21.Punto de vista de uso de aplicaci´on . . . 54

5-22.Metamodelo punto de vista de infraestructura . . . 55

5-23.Punto de vista de infraestructura . . . 55

5-24.Metamodelo punto de vista de uso de infraestructura . . . 56

5-25.Punto de vista de uso de infraestructura . . . 56

5-26.Metamodelo punto de vista de organizaci´on e implementaci´on . . . 57

5-27.Punto de vista de organizaci´on e implementaci´on . . . 57

5-28.Metamodelo punto de vista de Estructura de Informaci´on . . . 58

5-29.Punto de vista de Estructura de Informaci´on . . . 58

5-30.Metamodelo punto de vista de Realizaci´on del Servicio . . . 59

5-31.Punto de vista de Realizaci´on del Servicio . . . 59

5-32.Punto de vista de Capas . . . 60

5-33.Metamodelo punto de vista de stakeholder . . . 61

5-34.Punto de vista de stakeholder . . . 61

5-35.Metamodelo punto de vista de realizaci´on de objetivos . . . 62

5-36.Punto de vista de realizaci´on de objetivos . . . 62

5-37.Metamodelo punto de vista de contribuci´on . . . 63

5-38.Metamodelo punto de vista de contribuci´on . . . 63

(5)

´INDICE DE FIGURAS 5

5-40.Ejemplo punto de vista de principios . . . 64

5-41.Metamodelo punto de vista de realizaci´on de Requerimientos . . . 64

5-42.Ejemplo punto de vista de realizaci´on de requerimientos . . . 65

5-43.Metamodelo punto de vista de motivaci´on . . . 65

5-44.Ejemplo punto de vista de realizaci´on de requerimientos . . . 66

5-45.Metamodelo punto de vista de proyecto . . . 66

5-46.Ejemplo punto de vista de proyecto . . . 67

5-47.Metamodelo punto de vista de migraci´on . . . 67

5-48.Ejemplo punto de vista de migraci´on . . . 68

5-49.Metamodelo punto de vista de migraci´on e implementaci´on . . . 68

5-50.Punto de Vista de Migraci´on e Implementaci´on . . . 69

6-1. Apache JMeter . . . 71

6-2. Respuesta de cada Api Gateway . . . 72

6-3. Promedio tiempos de respuesta para 100 peticiones . . . 73

6-4. Tiempos M´ınimo de respuesta para 100 peticiones . . . 73

6-5. Tiempos M´aximo de respuesta para 100 peticiones . . . 74

6-6. Respuesta de cada Api Gateway . . . 75

6-7. Promedio tiempos de respuesta para 500 peticiones . . . 75

6-8. Tiempos M´ınimo de respuesta para 500 peticiones . . . 76

6-9. Tiempos M´aximo de respuesta para 500 peticiones . . . 76

6-10.Respuesta de cada Api Gateway . . . 77

6-11.Promedio tiempos de respuesta para 1.000 peticiones . . . 78

6-12.Tiempos M´ınimo de respuesta para 1.000 peticiones . . . 78

6-13.Tiempos M´aximo de respuesta para 1.000 peticiones . . . 79

6-14.Respuesta de cada Api Gateway . . . 80

6-15.Promedio tiempos de respuesta para 5.000 peticiones . . . 81

6-16.Tiempos M´ınimo de respuesta para 5.000 peticiones . . . 81

(6)

´

_{Indice de cuadros}

6-1. Resumen de transaccionalidad para 100 peticiones http . . . 72

6-2. Resumen de transaccionalidad para 500 peticiones http . . . 74

6-3. Resumen de transaccionalidad para 1.000 peticiones http . . . 77

(7)

Contenido

Introducci´on 2

I

Contextualizaci´

on de la investigaci´

on

3

1. Descripci´on de la investigaci´on 4

1.1. Planteamiento/Identificaci´on del problema . . . 4

1.2. Objetivos . . . 5

1.2.1. Objetivo General . . . 5

1.2.2. Objetivos espec´ıficos . . . 5

1.3. Justificaci´on del trabajo/investigaci´on . . . 6

1.4. Hip´otesis . . . 7

1.5. Marco referencial . . . 7

1.5.1. Marco te´orico . . . 7

1.5.2. Marco conceptual . . . 15

1.6. Metodolog´ıa de la investigaci´on . . . 17

1.7. Organizaci´on del trabajo de grado . . . 18

1.8. Estudio de sistemas previos . . . 18

II

Desarrollo de la investigaci´

on

22

2. An´alisis del sistema 23 2.1. Requerimientos . . . 24

3. Dise˜no de Api Gateway 25 3.1. Paradigma orientado a objetos . . . 25

3.2. Paradigma reactivo . . . 27

4. Construcci´on e Implementaci´on 29 4.1. Microservicios . . . 29

4.2. Api Gateway Reactivo . . . 34

4.2.1. Api Gateway NodeJS . . . 34

4.2.2. Api Gateway Spring Cloud . . . 35

(8)

CONTENIDO 1

4.4. Despliegue final . . . 41

5. ADM-Archimate 43 5.1. Organizaci´on . . . 43

5.2. Punto de vista del negocio . . . 44

5.3. Punto de vista de la aplicaci´on . . . 50

5.4. Punto de vista tecnol´ogico . . . 54

5.5. Punto de vista motivacional . . . 61

5.6. Punto de vista implementaci´on y migraci´on . . . 66

III

Cierre de la investigaci´

on

70

6. Resultados y discusión 71 7. Conclusiones 83 7.1. Verificación, contraste y evaluación de los objetivos . . . 83

7.2. S´ıntesis del modelo propuesto . . . 83

7.3. Aportes originales . . . 84

8. Prospectiva del trabajo de grado 85 8.1. L´ıneas de investigaci´on futuras . . . 85

8.2. Trabajos de Investigaci´on futuros . . . 85

Bibliograf´ıa 87

(9)

2 CONTENIDO

Introducci´

on

Este proyecto tiene como objetivo recabar información y formular una hipótesis acerca de la transaccionalidad en el componente API Gateway desarrollado con el paradigma orientado a objetos frente al paradigma reactivo. El componente Api Gateway es un patrón que bus-ca solucionar la forma que los diferentes clientes tratan de acceder a los microservicios del Banckend.

Las aplicaciones con arquitectura a microservicios, han optado por incluir este patr´on en su arquitectura y como es el caso de Netflix ha sido conveniente, puesto que ofrecen un API de servicios para cada tipo de cliente, de esta manera tiene una alta disponibilidad, escala-bilidad y rendimiento.

En el mundo y Colombia no es la excepción, las aplicaciones en su mayor´ıa usan la pro-gramación orientada a objetos, brindando buenas soluciones para lo que fueron construidas. Sin embargo, en los últimos años viene emergiendo el paradigma reactivo, el cual es una buena alternativa por su manejo de recursos f´ısicos.

Según la literatura sobre arquitectura de software actual, es conveniente que para el desa-rrollo de aplicación con una alta concurrencia, el paradigma elegido sea el reactivo, porque que as´ı cada flujo tiene un manejo independiente, lo que puede llevar a que haya un servicio de atención mucho más rápido.

(10)

Parte I

(11)

Cap´ıtulo 1

Descripci´

on de la investigaci´

on

1.1. Planteamiento/Identificaci´

on del problema

El patrón Api Gateway ha demostrado ser conveniente para aplicaciones basadas en micro-servicios. Si no se tiene un Api Gateway, las aplicaciones clientes deben enviar solicitudes directamente a los microservicios y eso plantea problemas tales como: acoplamiento, dema-siados viajes de ida y vuelta, temas de seguridad, inconvenientes transversales, entre otros [2]. Por lo tanto, el api Gateway se encuentra entre: las aplicaciones clientes y los microser-vicios. Actúa como un proxy inverso, enrutando las solicitudes de los clientes a los servicios. También puede proporcionar caracter´ısticas transversales adicionales como autenticación, terminación SSL y cache.

Por otro lado en los últimos años; el paradigma de la programación reactiva ha recibido una mayor atención, ya que cada vez más aplicaciones se han vuelto impulsadas por eventos [4, 1]. El paradigma gira en torno a la propagación del cambio para variables que var´ıan continuamente en el tiempo. En otras palabras, el paradigma gira en torno al procesamiento as´ıncrono de flujo de datos sin bloqueo. Este paradigma adopta un enfoque declarativo que permite a los desarrolladores especificar qué hacer, pero está dejando el tiempo de ejecución al lenguaje [4].

(12)

1.2 Objetivos 5

diferencias tiene la programaci´on reactiva frente a la programaci´on orientada a objetos?

Formulaci´

on del problema

Para un componente API Gateway de la arquitectura de microservicios desarrollado bajo el paradigma orientado a objetos y el mismo componente desarrollado bajo el paradigma reactivo, ¿Qu´e API tiene mayor ´ındice de atenci´on a las peticiones enviadas en un lapso de tiempo dado?

Sistematizaci´

on del problema

¿Cómo proveer los API Gateways que serán objetos de estudio, en donde se determinará cuál tiene mayor rendimiento en su transaccionalidad?

¿C´omo se obtendr´an los datos de la transaccionalidad de cada API Gateway para n peticiones en un lapso de tiempo dado?

¿Cómo demostrar qué API Gateway tiene mayor ´ındice de atención a sus peticiones enviadas?

1.2. Objetivos

1.2.1. Objetivo General

Analizar el rendimiento de la transaccionalidad en un API Gateway desarrollado con el paradigma orientado a objetos frente al paradigma reactivo, determinando qu´e paradigma tiene mayor ´ındice de atenci´on.

1.2.2. Objetivos espec´ıficos

Desarrollar el API Gateway mediante las tecnolog´ıas Spring Cloud y NodeJS para el paradigma Reactivo y por parte del paradigma orientado a objetos con Java; los cuales ser´an objetos de estudio.

Obtener los datos de la transaccionalidad de cada API Gateway con la ayuda de la herramienta: Apache JMeter; para n peticiones en un lapso de tiempo determinado, en donde n est´a en unidades de mil; estos datos representan a cada paradigma usado en el desarrollo del API.

(13)

6 1 Descripci´on de la investigaci´on

1.3. Justificaci´

on del trabajo/investigaci´

on

En la actualidad las aplicaciones con arquitectura a microservicios están en su pleno auge, esto se debe a que han solventado varios inconvenientes comunes que presentan las aplica-ciones monol´ıticas. Entre algunas ventajas se tienen: Servicios pequeños e independientes (principio de responsabilidad única), unidades de despliegue pequeñas, reducción en tiempos de desarrollo, agilidad en hot fixes, multitecnolog´ıa, fácil escalado horizontal.

El patrón Api Gateway nace en respuesta a cómo deber´ıan los clientes de una aplicación basada a microservicios acceder a los servicios individuales, porque estos sistemas necesi-tan mucha información que se distribuye en varios servicios dentro del catálogo de servicios [Web14]. Además, muchos tipos de clientes consumen los servicios del sistema, agregando más complejidad a las soluciones finales; cuando comenzamos a pensar en la evolución de esos servicios, respetando las comunicaciones y el intercambio de tamaño/formato de datos para cada uno de esos clientes; de esta manera, los servicios deben poder ”hablar¸con cada uno de estos clientes (y ser fácilmente detectables) sin perder los requisitos no funcionales de rendimiento, mantenimiento, escalabilidad, seguridad y disponibilidad necesarios para so-portar estas soluciones distribuidas [Web14].

Las aplicaciones microservicios con el patrón API Gateway están orientadas para tener una alta concurrencia, como es el caso de Netflix, por tal motivo la literatura se centra en un enfoque reactivo, impulsado por eventos, ya que se considera que es mejor por si debe es-calarse al manejo de altas cargas. En la JVM, las bibliotecas basadas en NIO como Netty, Spring Reactor, etc. tienen sentido. NodeJS es otra opción.

(14)

1.4 Hip´otesis 7

1.4. Hip´

otesis

Con el análisis de la transaccionalidad en el API Gateway desarrollado bajo el paradigma reactivo frente al paradigma orientado a objetos, para la funcionalidad de “mostrar regalo” de la aplicación microservicios seloreglo.com; se determinará que para el alto número de solicitudes concurrentes, el API Gateway desarrollado con programación reactiva responderá mayor número de peticiones en un tiempo dado.

1.5. Marco referencial

1.5.1. Marco te´

orico

El patr´

on Api Gateway

Un API Gateway es un servicio que es el único punto de entrada para las solicitudes de API en una aplicación desde fuera del firewall. Es similar al patrón de fachada del diseño orientado a objetos. Como una fachada, un Api Gateway encapsula la arquitectura interna de la aplicación y la proporciona a sus clientes. También podr´ıa tener otras responsabilidades, tales como autenticación, monitoreo y limitación de velocidad. La figura 1-1 muestra la relación entre los clientes, el Api Gateway y los servicios [7].

Figura 1-1: Arquitectura microservicios con Api Gateway

(15)

Gateway. Este encamina algunas solicitudes al servicio apropiado y da manejo a otras solici-tudes usando el patrón de composición de API e invocando múltiples servicios y agregando los resultados. También actúa como traductor entre protocolos amigables para el cliente, como HTTP y WebSockets, y los protocolos hostiles para el cliente que son utilizados por los servicios [7].

Enrutamiento de solicitudes Una de las funciones clave de un API Gateway es el en-rutamiento de solicitudes. Ya que implementa algunas operaciones de API al enrutar las solicitudes al servicio correspondiente. Cuando recibe una solicitud, el API Gateway consul-ta un mapa de enruconsul-tamiento que especifica a qué servicio enrutar la solicitud. Un mapa de enrutamiento podr´ıa, por ejemplo, asignar un método HTTP y una ruta a la URL HTTP de un servicio. Esta función es idéntica a las funciones de proxy inverso proporcionadas por servidores web como NGINX [7] .

Composición Api Un API Gateway normalmente hace más que un proxy inverso. Tam-bién podr´ıa implementar algunas operaciones de API utilizando la composición. Como se muestra en la Figura 1-2, la aplicación móvil realiza una solicitud al API Gateway, que obtiene los detalles del pedido de múltiples servicios.

Traducción del Protocolo Un API Gateway también puede realizar la traducción del protocolo. Puede proporcionar una API RESTful a clientes externos, aunque los servicios de la aplicación utilizan una combinación de protocolos que incluyen internamente REST y gRPC. Cuando sea necesario, la implementación de algunas operaciones de API se traduce entre la API externa RESTful y las API internas basadas en gRPC [7].

El API Gateway proporciona para cada cliente un API espec´ıfico Un API Ga-teway podr´ıa proporcionar una única API de talla única para todos (OSFA). El problema con una única API es que los diferentes clientes a menudo tienen diferentes requisitos. Por ejemplo, una aplicación de terceros puede requerire que la operación de obtención de detalles de pedidos de la API devuelva los detalles completos de los pedidos, mientras que un cliente móvil solo necesita un subconjunto de los datos. Una forma de resolver este problema es dar a los clientes la opción de especificar en una solicitud qué campos y objetos relacionados debe devolver el servidor. Este enfoque es adecuado para una API pública que debe servir a una amplia gama de aplicaciones de terceros, pero a menudo no proporciona a los clientes el control que necesitan [7].

Un mejor enfoque es que el API Gateway proporcione a cada cliente su propia API. Por ejemplo, se podr´ıa tener diferentes API para las aplicaciones m´oviles de Android e iPhone. Arquitectura Api Gateway

(16)

1.5 Marco referencial 9

Figura 1-2: Ejemplo de composici´on de Api para un Api Gateway

La capa API consta de uno o más módulos independientes. Cada módulo implementa una API para un cliente en particular. La capa común implementa una funcionalidad compartida que incluye funciones de borde como la autenticación.

En este ejemplo, el API Gateway tiene tres m´odulos:

Mobile API: Implementa el Api de servicios para clientes M´oviles.

Browser API: El cual implementa el API para aplicaciones Javascript ejecutadas por un navegador.

Public API: Hace referencia al API de servicios para desarrolladores terceros.

(17)

Figura 1-3: Arquitectura Api Gateway con m´ultiples clientes

una API espec´ıfica para cliente. Esto reduce el número de viajes de ida y vuelta entre el cliente y la aplicación. También simplifica el código del cliente [7].

Inconvenientes de un Api Gateway El patrón API Gateway también tiene algunos inconvenientes. Es otro componente altamente disponible que debe ser desarrollado, imple-mentado y administrado. Esto crea el riesgo de que el componente se convierta en un cuello de botella de desarrollo. Los desarrolladores deben actualizar el API Gateway para exponer la API de sus servicios. Es importante que el proceso para actualizarlo sea lo más liviano po-sible. De lo contrario, los desarrolladores se ven obligados a esperar en l´ınea para actualizar el API Gateway [7].

Netflix como ejemplo de un API Gateway

Un gran ejemplo de un API Gateway es el API de Netflix. El servicio de transmisión de Netflix está disponible en cientos de diferentes tipos de dispositivos, incluidos televisores, re-productores de Blu-ray, teléfonos inteligentes, etc. Inicialmente, Netflix intentó tener un API de estilo único para su servicio de transmisión. Desafortunadamente, pronto descubrieron que no funcionaba bien debido a la amplia gama de dispositivos y sus diferentes necesidades. Hoy en d´ıa, utilizan un API Gateway que implementa una API de servicios separada para cada dispositivo.

(18)

clien-1.5 Marco referencial 11

te Java proporcionadas por los equipos de servicio. Por un lado, esto funciona bien y los desarrolladores de clientes han escrito más de miles de scripts. El API Gateway de Netflix maneja miles de millones de solicitudes por d´ıa; en promedio, cada API llama a los fanáticos a seis o siete servicios de back-end. Netflix ha encontrado que esta arquitectura monol´ıtica es algo incómoda.

Como resultado, Netflix ahora se está moviendo a una arquitectura de API Gateway que es similar a los Backends para los patrones front-end. En esta nueva arquitectura, los equipos de clientes escriben módulos API utilizando NodeJS. Cada módulo API ejecuta su propio contenedor Docker. Los scripts no invocan los servicios directamente. En su lugar, invocan un segundo “API Gateway”, que expone las API de servicio utilizando Netflix Falcor. Netflix Falcor es una tecnolog´ıa de API que realiza una composición de API dinámica y declarativa, y permite a un cliente invocar múltiples servicios utilizando una sola solicitud. Esta nueva arquitectura tiene una serie de beneficios. Los módulos API están aislados entre s´ı, lo que mejora la confiabilidad y la capacidad de observación. Además, el módulo API del cliente es escalable de forma independiente.

Programaci´

on Orientada a Objetos

Un programa orientado a objetos (OOP) se ve como una colección de objetos interactivos, a diferencia del modelo convencional en el que un programa se ve como una lista de tareas (subrutinas) para realizar. En OOP, cada objeto es capaz de recibir mensajes, procesar datos y enviar mensajes a otros objetos. Cada objeto puede verse como una “máquina” independiente con una función o responsabilidad distinta. Las acciones o métodos en estos objetos están estrechamente asociados con el objeto [6].

Clase Una clase, es simplemente una abstracción que hacemos de nuestra experiencia sen-sible. El ser humano tiende a agrupar seres o cosas -objetos- con caracter´ısticas similares en grupos -clases-. As´ı, aun cuando existen por ejemplo multitud de vasos diferentes, podemos reconocer un vaso en cuanto lo vemos, incluso aun cuando ese modelo concreto de vaso no lo hayamos visto nunca. El concepto de vaso es una abstracción de nuestra experiencia sensible. Quizás el ejemplo más claro para exponer esto lo tengamos en las taxonom´ıas; los biólogos han dividido a todo ser (vivo o inerte) sobre la tierra en distintas clases [5] . Tomemos como ejemplo una pequeña porción del inmenso árbol taxonómico: Ellos, llaman a cada una de estas parcelas reino, tipo, clase, especie, orden, familia, género, etc.; sin embargo, nosotros a todas las llamaremos del mismo modo: clase. As´ı, hablaremos de la clase animal, clase vegetal y clase mineral, o de la clase félidos y de las clases leo (león) y tigris (tigre). Cada clase posee unas cualidades que la diferencian de las otras. As´ı, por ejemplo, los vegetales se diferencian de los minerales -entre otras muchas cosas- en que los primeros son seres vivos y los minerales no. De los animales se diferencian en que las plantas son capaces de sintetizar clorofila a partir de la luz solar y los animales no [5].

(19)

Figura 1-4: Clasificaci´on taxon´omica de los vertebrados

Los datos son lo que antes hemos llamado caracter´ısticas o atributos, los m´etodos son los comportamientos que pueden realizar [5].

Lo importante de un sistema OOP es que ambos, datos y métodos están tan intr´ınseca-mente ligados, que forman una misma unidad conceptual y operacional. En OOP, no se pueden desligar los datos de los métodos de un objeto. As´ı es como ocurre en el mundo real [5].

Herencia Esta es la cualidad más importante de un sistema OOP, la que nos dará mayor potencia y productividad, permitiéndonos ahorrar horas y horas de codificación y de depu-ración de errores.

(20)

Encapsulamiento Hay muchos datos que no tiene por qué conocerlo aquel que esté usan-do la clase X; ya que son inherentes al objeto y solo controlan su funcionamiento interno. Esto es la encapsulación u ocultación; hacer las variables que son innecesarias para el trata-miento del objeto pero necesarias para su funcionatrata-miento privadas, as´ı como las funciones que no necesitan interacción del usuario o que solo pueden ser llamadas por otras funciones dentro del objeto (como por ejemplo, palpitar) [5].

La encapsulaci´on es muy conveniente y nos permite colocar en funcionamiento nuestro ob-jeto en cualquier tipo de sistema, de una manera modular y escalable (algunas de las reglas de la ingenieria del software) [5].

Formas de encapsular:

Abierto: hace que el miembro de la clase pueda ser accedido desde el exterior de la Clase cualquier parte del programa.

Protegido: solo es accesible desde la Clase y las clases que heredan (a cualquier nivel). Cerrado: Solo es accesible desde la Clases.

Polimorfismo Por polimorfismo entendemos aquella cualidad que poseen los objetos para responder de distinto modo ante el mismo mensaje.

Pongamos por ejemplo las clases hombre, vaca y perro, si a todos les damos la orden -enviamos el mensaje- Come, cada uno de ellos sabe c´omo hacerlo y realizar´a este comporta-miento a su modo.

Veamos otro ejemplo algo más ilustrativo. Tomemos las clases barco, avión y coche, to-das ellas derivato-das de la clase padre veh´ıculo; si les enviamos el mensaje Desplázate, cada una de ellas sabe cómo hacerlo.

Realmente, y para ser exactos, los mensaje no se env´ıan a las clases, sino a todos o algunos de los objetos instanciados de las clases. As´ı, por ejemplo, podemos decirle a los objetos Juan Sebastián el Cano y Kontiqui, de la clase barco que se desplacen, con los que el resto de los objetos de esa clase permanecerán inmóviles.

Paradigma reactivo

Sistemas Reactivos

(21)

Sin embargo, los sistemas reactivos se definen como sistemas que responden continuamente a las entradas. Harel y Puneli también señalan que los sistemas reactivos están presentes en todas partes, desde automóviles hasta teléfonos. La reactividad puede ser incluida por soft-ware o chips, por ejemplo. Tanto los sistemas transformacionales como los reactivos pueden ser s´ıncronos o as´ıncronos.

El centro de mayor atención para la programación reactiva está especialmente en combinar la programación reactiva y la distribución. Buenos ejemplos para la combinación de programa-ción reactiva y distribución son las aplicaciones web y las aplicaciones móviles distribuidas. Un inconveniente conocido de la combinación de programación reactiva y distribución es que puede provocar fallas [1, 4]. Evitar fallos es un factor a considerar cuando se utiliza la programación reactiva. Es más dif´ıcil evitarlos en los sistemas distribuidos debido a los pro-blemas de la red, como la latencia. La combinación de programación reactiva y distribución a menudo se denomina programación reactiva distribuida o microservicios reactivos.

Figura 1-5: Caracter´ısticas de un sistema reactivo, y como se relacionan entre s´ı

Programaci´on reactiva

En la comunidad Java, el paradigma de la programación reactiva ha logrado cada vez más atención en los últimos años. Las bibliotecas reactivas como Project Reactor y RxJava y la introducción de un estándar reactivo en la API de Java 9 han contribuido al mayor interés en la programación reactiva en Java.

Esta programación se trata de flujos de datos y propagación de cambios. Para aplicaciones dirigidas por eventos, este paradigma es adecuado. Sin embargo, centrándose principalmente en el paradigma de la programación reactiva funcional [1, 4].

(22)

contraste con la programación imperativa, donde el desarrollador usa declaraciones para cambiar el estado de un programa, en la programación declarativa el desarrollador define qué hacer, pero el tiempo de ejecución lo maneja el propio programa [1, 4].

Programaci´on Reactiva vs Sistemas Reactivos

La diferencia entre la programación reactiva y los sistemas reactivos están en sus aplicaciones. La programación reactiva se aplica a la lógica interna de los componentes, mientras que los sistemas se aplican a nivel arquitectónico para los sistemas. Las aplicaciones que implementan la programación reactiva son altamente controladas por eventos, lo que significa que son estos los que impulsan la ejecución en lugar de un hilo de ejecución. La programación reactiva facilita el desacoplamiento en el tiempo y, por lo tanto, la concurrencia. Los sistemas reactivos son altamente impulsados por mensajes. Los sistemas facilitaron el acoplamiento en el espacio y por lo tanto la distribución.

Figura 1-6: Relaci´on en una implementaci´on del flujo reactivo

La diferencia entre ser dirigido por eventos y por mensaje se define en el Reactivo Ma-nifiesto [Web3]. En el maMa-nifiesto, el evento controlado se define como or´ıgenes de eventos direccionables y el mensaje se define como destinatarios direccionables. Esto significa que los suscriptores en un sistema controlado por eventos se adjuntan a los editores, mientras que en un sistema dirigido por mensajes, los suscriptores esperan que los mensajes lleguen sin la necesidad de adjuntarlos al editor.

1.5.2. Marco conceptual

Paradigma

Un paradigma de programación indica un método de realizar cómputos y la manera en que se deben estructurar y organizar las tareas que debe llevar a cabo un programa [8].

(23)

Tambien se asocian a un determinado estilo de programaci´on.

Los lenguajes de programaci´on suelen implementar, a menudo de forma parcial, varios pa-radigmas [8].

Figura 1-7: El zoo de los paradigmas

Patr´on

Los patrones son disciplinas de la Ingenier´ıa de Software que facilitan la reutilización del diseño y de la arquitectura. Son soluciones de problemas conocidos en la programación. No es obligatorio usar patrones pero reinventar la rueda en situaciones similares facilitan catálogos de elementos reusables, evitar reiteraciones, formular un vocabulario común entre programadores, estandarizar el diseño y facilitar el aprendizaje de los nuevos programadores [Web2].

Arquitectura software

(24)

1.6 Metodolog´ıa de la investigaci´on 17

Sin embargo, el seguimiento de la arquitectura del software es dif´ıcil, porque siempre se esconde detrás de lo que se puede tocar. Visualizarlo requiere un profundo conocimiento de la información global de los sistemas, as´ı como excelentes habilidades y métodos. Las per-sonas de diferentes organizaciones o empresas utilizan diferentes estrategias para manejarlo, pero la mayor´ıa de ellas tiene algo en común. El resumen y el sol de estas experiencias se han convertido en la base de la ciencia de la arquitectura de software en la actualidad [Web1].

Servicio web

Un servicio web realiza una tarea espec´ıfica o un conjunto de tareas. La descripci´on de servicio proporciona todos los detalles necesarios para interactuar con el servicio, incluidos los formatos de mensaje (que detallan las operaciones), los protocolos de transporte y la ubicaci´on [Web6].

1.6. Metodolog´ıa de la investigaci´

on

Tipo de estudio

El nivel de profundidad que aborda este proyecto, es el tipo de confirmatorio. Ya que la intención de este análisis es determinar qué paradigma tiene un mayor rendimiento en la atención de solicitudes en un API Gateway para un tiempo determinado.

El nivel en la investigación hol´ıstica es la Integrativa y el holotipo de investigación es confirmatoria. Porque se verificará y demostrará con datos la conclusión final del presente trabajo.

M´

etodo de investigaci´

on

En aras de obtención de la respuesta planteada en la formulación del problema, es necesario establecer un procedimiento riguroso de manera organizada. Por lo anterior, se define como método de investigación elMétodo Cuantitativo, en donde a partir de diversas mediciones en la transaccionalidad del API Gateway, se encontrarán diferencias entre paradigmas de programación.

Fuentes y t´

ecnicas para recolecci´

on de la informaci´

on

Las fuentes a los que se acudi´o para el marco referencial son:

(25)

1.7. Organizaci´

on del trabajo de grado

El trabajo realizado para el presente proyecto inicia con la Contextualización de la in-vestigación, en donde se puede identificar el planteamiento del problema, definición de la justificación, los objetivos para la investigación, hipótesis, marco referencial, metodolog´ıa y estudio de sistemas previos.

En una segunda parte, se puede econtrar el Desarrollo de la investigaci´on, la cual la compone los siguientes cap´ıtulos:

Fase de Análisis: Se realizó identificación de tecnolog´ıas y requerimientos de un Api Gateway.

Fase de dise˜no: Modelamiento de cada Api Gateway mediante UML, y se acompa˜na el uso del componente en aplicaciones con microservicios mediante el uso de ADM-Archimate.

Fase de construcci´on: Se muestra la implementaci´on de cada uno de los Api Gateway haciendo uso de los microservicios.

Fase de pruebas: Se realizan consumos de los servicios expuestos por cada Api Gateway mediante herramientas de an´alisis de peticiones RestFul.

Para el cierre de la investigación, se presenta una muestreo de la recolección de datos para cada Api Gateway, orientado a objetos y reactivo; se presenta el comportamiento de cada Api Gateway mediante gráficas estad´ısticas y se realiza comparación de resultados en peti-ciones atendidas en un lapso de tiempo.

Adicionalmente se discute a cerca de los resultados obtenidos, para finalmente concluir nues-tra hip´otesis planteada.

1.8. Estudio de sistemas previos

Hace aproximadamente un año, el equipo de API de Netflix comenzó a rediseñar la API para mejorar el rendimiento y permitir que los equipos de ingenier´ıa de UI en Netflix optimicen las aplicaciones de cliente para dispositivos espec´ıficos. Las filosof´ıas del rediseño se introdujeron en una publicación anterior acerca de abarcar las diferencias entre los diferentes clientes y dispositivos [Web5].

(26)

1.8 Estudio de sistemas previos 19

Arquitectura

Para lograr los objetivos por encima de nuestra arquitectura destilada en algunos puntos clave:

Tiempo de ejecución pol´ıglota dinámico. capa de servicio totalmente as´ıncrono. Modelo de programación reactiva.

El siguiente diagrama, Figura 1-8 y las siguientes anotaciones explican la arquitectura:

Figura 1-8: Arquitectura en Api de Netflix

(27)

2. Administración y gestión de códigos Endpoint El código de punto final se publica en un clúster multirregional de Cassandra (replicado globalmente) a través de una API RESTful Endpoint Management utilizada por los equipos de clientes para administrar sus puntos finales [Web5].

3. Lenguaje Runtime JVM pol´ıglota dinámico Se puede admitir cualquier lenguaje JVM para que cada equipo pueda utilizar el idioma que mejor se adapte a ellos. El len-guaje Groovy JVM fue elegido como nuestro primer idioma compatible. La existencia de funciones de primera clase (cierres), sintaxis de lista / diccionario, rendimiento y capacidad de depuración fueron todos aspectos de nuestra decisión. Además, Groovy proporciona una sintaxis cómoda para una amplia gama de desarrolladores, lo que ayuda a reducir la curva de aprendizaje del primer idioma en la plataforma [Web5].

4 y 5 API Java As´ıncrona + modelo de programación reactiva Adoptar la concu-rrencia fue un requisito clave para lograr mejoras de rendimiento, pero abstraer los detalles de implementación de ejecución paralela y seguridad de subprocesos de los desarrolladores clientes fue igualmente importante para reducir la complejidad y acelerar su tasa de inno-vación. El primer paso fue hacer que la API de Java fuera totalmente as´ıncrona, ya que permite que las implementaciones de los métodos subyacentes controlen si algo se ejecuta simultáneamente o no, sin que cambie el código del cliente. Elegimos un modelo de pro-gramación reactivo con un estilo de programación funcional para manejar la composición y los flujos condicionales de devoluciones de llamada as´ıncronas. Nuestra implementación está modelada a partir de Rx Observables [Web5].

6. Tolerancia a fallos de Hystrix Como hemos descrito en una publicación anterior, todas las llamadas de servicio a los sistemas de back-end se realizan a través de la capa de tolerancia a fallos Hystrix (que se abrió recientemente, junto con su panel de control) que a´ısla los puntos finales dinámicos y la capa de servicio API de los inevitables fallos que Ocurre mientras se ejecutan miles de millones de llamadas de red cada d´ıa desde la API a los sistemas backend [Web5].

La capa Hystrix es intr´ınsecamente multihilo debido a su uso de subprocesos para aislar dependencias y, por lo tanto, se aprovecha para la ejecución simultánea de llamadas de blo-queo a sistemas backend. Estas solicitudes as´ıncronas se componen juntas a través del marco reactivo [Web5].

(28)

1.8 Estudio de sistemas previos 21

(29)

Parte II

(30)

Cap´ıtulo 2

An´

alisis del sistema

En una arquitectura de microservicios, un cliente puede interactuar con más de un servicio de frontEnd. Dado este hecho, ¿cómo sabe un cliente a qué puntos finales llamar? ¿Qué sucede cuando se introducen nuevos servicios o se refactorizan los servicios existentes? ¿Cómo ma-nejan los servicios la terminación SSL, la autenticación y otras inquietudes? El Api Gateway que se propone a continuación puede ayudar a enfrentar estos desaf´ıos.

Figura 2-1: Funciones del Api Gateway

(31)

24 2 An´alisis del sistema

El Gateway ayuda a resolver estos problemas mediante el desacoplamiento de los clien-tes de los servicios. Estos pueden realizar una serie de funciones diferenclien-tes, y es posible que no las necesite todas. Las funciones que cumplirán cada Api desarrollado cumplen con los siguientes patrones de diseño que serán los requerimientos:

2.1. Requerimientos

Gateway Routing Uso del Gateway como un proxy inverso para enrutar las solicitudes a uno o m´as servicios de backEnd. La puerta de enlace proporciona un ´unico punto final para los clientes y ayuda a desvincular a los clientes de los servicios.

Gateway Aggregation Utiliza el Gateway para agregar varias solicitudes individuales en una sola solicitud. Este patrón se aplica cuando una sola operación requiere llamadas a múltiples servicios backend. El cliente env´ıa una solicitud al Gateway. El Gateway env´ıa solicitudes a los diversos servicios de backEnd, y luego agrega los resultados y los env´ıa de vuelta al cliente. Esto ayuda a reducir el chattiness entre el cliente y el backend.

Gateway Offloading Se usa el Gateway para descargar la funcionalidad de los servi-cios individuales a el mismo, en particular las preocupaciones transversales. Puede ser útil consolidar estas funciones en un solo lugar, en lugar de hacer que cada servicio sea responsa-ble de implementarlas. Esto es particularmente cierto para las caracter´ısticas que requieren habilidades especializadas para implementarse correctamente, como la autenticación y la au-torización.

Estos son algunos ejemplos de la funcionalidad que se podr´ıa descargar en un Gateway: Terminaci´on SSL.

(32)

Cap´ıtulo 3

Dise˜

no de Api Gateway

En el presente cap´ıtulo se presentan los dise˜nos del API Gateway desarrollados bajo el paradigma orientado a objetos y el reactivo respectivamente. Se hace uso de diagramas que el autor considera representativos para la monograf´ıa.

3.1. Paradigma orientado a objetos

En funci´on del desarrollo del Api Gateway usando el paradigma orientado a objetos se usan los diagramas de clases, secuencia y componentes para resaltar su dise˜no.

(33)

26 3 Dise˜no de Api Gateway

Diagrama de secuencia

Figura 3-2: Diagrama de secuencia Api Gateway con paradigma orientado a objetos

Diagrama de componentes

(34)

3.2 Paradigma reactivo 27

3.2. Paradigma reactivo

En funci´on del desarrollo del Api Gateway usando el paradigma reactivo se usan los diagra-mas flujos de datos, secuencia. En adici´on, la figura 3-6 muestra la concurrencia en el Api Gateway reactivo, elemento que no tiene el Api bajo el paradigma orientado a objetos.

Figura 3-4: Diagrama de flujo de datos f´ısico

(35)

28 3 Dise˜no de Api Gateway

(36)

Cap´ıtulo 4

Construcci´

on e Implementaci´

on

4.1. Microservicios

Aunque los microservicios no hacen parte del análisis de transaccionalidad del presente tra-bajo, son la fuente de datos para cada API Gateway desarrollados. Con el ánimo de conservar la misma fuente de datos y la razón del patrón API Gateway se comenta a continuación su desarrollo:

Construcci´

on con JHipster

JHipster es una plataforma de desarrollo para generar, desarrollar e implementar aplicacio-nes web Spring Boot + Angular / React / Vue y microservicios Spring [Web10]. El objetivo es generar para usted una aplicaci´on web completa y moderna o una arquitectura de microservicio, unificando:

Figura 4-1: Plataforma Jhipster

Un Stack de Java robusto y de alto rendimiento en el lado del servidor con Spring Boot.

Un frontal moderno, elegante y moderno, con Angular, React y Bootstrap.

(37)

30 4 Construcci´on e Implementaci´on

Una vez instalado, ver gu´ıa de instalación en [Web10]; se realizó modelo de entidades del negocio del microservicio; Una caracter´ıtica de Jhipster es generar código a partir de este modelo.

Figura 4-2: Ejemplo modelo de entidades microservicio en JDL Studio

Enhttps://start.jhipster.tech/jdl-studio/se puede realizar el archivo .jh, el cual es de gran ayuda para la exposici´on de un Api RestFul.

Implementaci´

on con Docker

Un contenedor es una unidad estándar de software que empaqueta el código y todas sus dependencias para que la aplicación se ejecute de forma rápida y confiable de un entorno informático a otro. Una imagen de contenedor Docker es un paquete de software liviano, independiente y ejecutable que incluye todo lo necesario para ejecutar una aplicación: c´ odi-go, tiempo de ejecución, herramientas del sistema, bibliotecas del sistema y configuraciones [Web9].

(38)

4.1 Microservicios 31

Figura 4-3: Ejemplo lenguaje JDL en modelo de entidades para microservicio

Documentaci´

on con Swagger

Simplifica el desarrollo de API para usuarios, equipos y empresas con el conjunto de herra-mientas de c´odigo abierto y profesional de Swagger. Descubre c´omo te puede ayudar Swagger [Web15].

(39)

Figura 4-4: Contenedores docker

(40)

4.1 Microservicios 33

(41)

4.2. Api Gateway Reactivo

4.2.1. Api Gateway NodeJS

NodeJS

Concebido como un entorno de ejecución de JavaScript orientado a eventos as´ıncronos, Node está diseñado para construir aplicaciones en red escalables. En dichas aplicaciones, se pueden manejar muchas conexiones concurrentes. Por cada conexión el callback será ejecutado, sin embargo si no hay trabajo que hacer Node estará durmiendo [Web7].

ExpressJS

Express es una infraestructura de aplicaciones web Node.js m´ınima y flexible que proporcio-na un conjunto s´olido de caracter´ısticas para las aplicaciones web y m´oviles [Web8].

Con miles de métodos de programa de utilidad HTTP y middleware a su disposición, la creación de una API sólida es rápida y sencilla [Web8].

Aprovechando esta tecnolog´ıa se cre´o el Api Gateway nodeJS haciendo uso del siguiente c´odigo, Figura 4-7- Figura 4-10:

(42)

4.2 Api Gateway Reactivo 35

Figura 4-8: Archivo router.js, contenedor de los microservicios que se desean consumir

Figura 4-9: Gateway adapter, cada microservicio realiza su uso

4.2.2. Api Gateway Spring Cloud

Este proyecto proporciona una biblioteca para construir una API Gateway sobre Spring MVC. Spring Cloud Gateway tiene como objetivo proporcionar una forma sencilla y eficaz de enrutar a las API y brindarles preocupaciones transversales, como la seguridad, monitoreo / m´etrica y la resistencia [Web12].

Servidor Eureka

(43)

Figura 4-10: Configuraci´on de enrutamiento para cada microservicio, por servicio

Server tambi´en se conoce como Discovery Server [Web16].

El servidor eureka desarrollado para el funcinamiento del api gateway est´a bajo el siguiente c´odigo (figura4-11 - figura4-13):

(44)

Figura 4-11: Configuraci´on de archivo pom.xml del servidor eureka

(45)

Figura 4-13: Clase principal de Spring boot, servidor eureka

(46)

Figura 4-15: Otras dependencias pom.xml Api Gateway con spring cloud

(47)

4.3. Api Gateway Orientado a Objetos

Spring boot

SpringBoot nace con la intención de simplificar los siguientes pasos: seleccionar los jar con maven y despliegues en servidor; con la intención de que el programador se centre en el desarrollo de la aplicación [Web4].

A continuaci´on se incluye c´odigo en spring boot que hace referencia al Api Gateway orien-tado a objetos:

(48)

4.4 Despliegue final 41

Figura 4-18: Acci´on para la optenci´on de url

Figura 4-19: Transformador de url a request

Figura 4-20: Consumo de servicio RestFul, microservicio

(49)

(50)

Cap´ıtulo 5

ADM-Archimate

Archimate 2.1 facilita el modelado de la arquitectura empresarial, permitiendo bosquejar la organización desde diversos puntos de vista donde se reflejan tanto los involucrados en el negocio, la infraestructura y la misma solución como los diferentes componentes, dando una visión general que describe a la perfección la organización y su solución informática.

El presente trabajo es del interés para la empresa Jirka IT Solutions, el cual sin nin-guna duda le sacará provecho para sus desarrollos futuros. Por esta razón el ejercicio de arquitectura empresarial se realizará sobre esta compañ´ıa

5.1. Organizaci´

on

Jirka IT Solutions SAS

Jirka es una compañ´ıa especializada en servicios IT de desarrollo de software que ofrecemos soluciones integrales con los más altos estándares tecnológicos del sector. Nos caracterizamos por la investigación e innovación al fin de promover el desarrollo de soluciones que ayuden a la transformación de la sociedad.

(51)

44 5 ADM-Archimate

Misi´

on

Jirka es una compañ´ıa especializada en servicios IT de desarrollo de software y Software Factory que ofrece soluciones integrales con los más altos estándares tecnológicos del sec-tor. Nos caracterizamos por la investigación e innovación al fin de promover el desarrollo de soluciones que ayuden a la transformación de la sociedad, por ello, estamos comprometidos con la excelencia, la responsabilidad y la calidad, de la mano con nuestro Talento Humano, quienes poseen una alta formación profesional enmarcada en las excelentes relaciones hu-manas, con el objetivo de dar respuesta a las necesidades de nuestros clientes, proveedores y colaboradores; conocemos la satisfacción que ofrece el éxito y estamos comprometidos en lograrlo.

Visi´

on

A 2020, ser la compañ´ıa l´ıder en servicios IT de desarrollo de software y Software Factory del Mercado, con casos de éxitos que posicionan a nuestros clientes como referentes de la adop-ción de nuestras soluciones tecnológicas, enmarcadas en los más altos estándares del sector; demostrando siempre nuestro compromiso social soportado en la investigación e innovación, de la mano con la formación de nuestro Talento Humano para afrontar los retos que diaria-mente impone la excelencia, construyendo relaciones basadas en la ética, la responsabilidad y la confianza.

5.2. Punto de vista del negocio

Los puntos de vista del negocio visualizan y definen los procesos de negocio, servicios y funciones de la organización, los cuales se ofrecen a los clientes externos y son generados por la organización por medio de procesos de negocios, a través de actores y sus diferentes roles de participación.

Punto de vista organizacional

Este punto de vista se centra en la organización interna de la empresa, una red de empresas, un departamento u otra entidad organizacional. Se pueden modelar diagramas de bloques anidados o de una forma más tradicional como un organigrama. Estos diagramas ayudan en la visualización e identificación de las responsabilidades, jerarqu´ıas y competencias de una organización.

Punto de vista cooperaci´

on de actor

(52)

5.2 Punto de vista del negocio 45

Figura 5-2: Metamodelo punto de vista de organizaci´on

Figura 5-3: Punto de vista de organizaci´on

en un ambiente de entidades externas tales como clientes, proveedores y dem´as colabora-dores del negocio. Estos diagramas ayudan a determinar las dependencias externas y sus colaboraciones, y a su vez visualizar la cadena de valor o la red de actores en la cual opera.

(53)

46 5 ADM-Archimate

Figura 5-5: Punto de vista cooperaci´on de actor

Punto de vista de funci´

on del negocio

Este punto de vista visualiza las principales funciones de negocio de la organización y las relaciones de los flujos de información, el valor y los bienes entre ellos. Estas funciones per-miten representar las caracter´ısticas de más estabilidad en una empresa en función de su actividad principal, sin importar los cambios de la organización o desarrollos tecnológicos.

Figura 5-6: Metamodelo punto de vista de funci´on de negocio

Punto de vista proceso del negocio

(54)

Figura 5-7: Punto de vista de funci´on de negocio

al producto final de la organizaci´on, as´ı como los roles en los procesos y las responsabilidades de los actores implicados.

(55)

48 5 ADM-Archimate

Figura 5-9: Punto de vista de proceso de negocio

Punto de vista cooperaci´

on proceso del negocio

Este punto de vista visualiza la relaci´on entre los procesos de negocio y su entorno, as´ı como las dependencias entre estos mismos. Sus caracter´ısticas son:

(56)

Figura 5-11: Punto de vista de cooperaci´on de proceso de negocio

Punto de vista de producto

(57)

50 5 ADM-Archimate

Figura 5-12: Metamodelo punto vista de producto

Figura 5-13: Punto vista de producto

5.3. Punto de vista de la aplicaci´

on

(58)

5.3 Punto de vista de la aplicaci´on 51

Punto de vista de comportamiento de aplicaci´

on

Este punto de vista visualiza y define el comportamiento a nivel interno de las aplicaciones, se utiliza para modelar y dise˜nar el comportamiento de las aplicaciones o componentes y lograr identificar el proceso funcional entre las aplicaciones.

Figura 5-14: Metamodelo punto de vista de comportamiento de aplicaci´on

(59)

52 5 ADM-Archimate

Punto de vista de cooperaci´

on de aplicaci´

on

Este punto de vista visualiza y define las relaciones de los componentes a través del flujo de información de los servicios ofrecidos o usados por la organización. Permite visualizar la cooperación de los servicios que se unen para la ejecución de los procesos del negocio.

Figura 5-16: Metamodelo punto de vista de cooperaci´on de aplicaci´on

Figura 5-17: Punto de vista de cooperaci´on de aplicaci´on

Punto de vista de estructura de aplicaci´

on

(60)

5.3 Punto de vista de la aplicaci´on 53

asociada.

Figura 5-18: Metamodelo punto de vista de estructura de aplicaci´on

Figura 5-19: Punto de vista de estructura de aplicaci´on

Punto de vista de uso de aplicaci´

on

(61)

54 5 ADM-Archimate

Figura 5-20: Metamodelo punto de vista de uso de aplicaci´on

Figura 5-21: Punto de vista de uso de aplicaci´on

5.4. Punto de vista tecnol´

ogico

Los puntos de vista tecnológicos visualizan y definen la infraestructura que soporta y permite la comunicación de la capa de aplicación, dispone de servicios de infraestructura hardware y software para el despliegue de las aplicaciones en la organización.

Punto de vista de infraestructura

(62)

5.4 Punto de vista tecnol´ogico 55

Figura 5-22: Metamodelo punto de vista de infraestructura

Figura 5-23: Punto de vista de infraestructura

Punto de vista de uso de infraestructura

(63)

56 5 ADM-Archimate

Figura 5-24: Metamodelo punto de vista de uso de infraestructura

Figura 5-25: Punto de vista de uso de infraestructura

Punto de vista de organizaci´

on e implementaci´

on

(64)

Figura 5-26: Metamodelo punto de vista de organizaci´on e implementaci´on

Figura 5-27: Punto de vista de organizaci´on e implementaci´on

Punto de vista de estructura de informaci´

on

(65)

58 5 ADM-Archimate

Figura 5-28: Metamodelo punto de vista de Estructura de Informaci´on

Figura 5-29: Punto de vista de Estructura de Informaci´on

Punto de vista de realizaci´

on del servicio

Este punto de vista visualiza y define como los servicios del negocio son ejecutados por procesos subyacentes, a trav´es de un puente de comunicaci´on entre los puntos de vista de negocio y los puntos de vista de procesos de negocio.

(66)

Figura 5-30: Metamodelo punto de vista de Realizaci´on del Servicio

(67)

60 5 ADM-Archimate

(68)

5.5 Punto de vista motivacional 61

5.5. Punto de vista motivacional

Punto de vista de los skateholder

Este punto de vista visualiza y define los stakeholders, los manejadores internos y externos de cambio, sus fortalezas, debilidades, oportunidades y amenazas (DOFA). Permite el proceso de ingenier´ıa de requerimientos, el refinamiento de objetivos, contribuci´on y an´alisis de conflictos derivados de los objetivos.

Figura 5-33: Metamodelo punto de vista de stakeholder

Figura 5-34: Punto de vista de stakeholder

Punto de vista de realizaci´

on de objetivos

(69)

62 5 ADM-Archimate

de los objetivos planteados. Estas mejoras se modelan a través de la relación de realización. Figura 5-35: Metamodelo punto de vista de realización de objetivos

Figura 5-36: Punto de vista de realizaci´on de objetivos

Punto de Vista de Contribuci´

on

(70)

Figura 5-37: Metamodelo punto de vista de contribuci´on

Figura 5-38: Metamodelo punto de vista de contribuci´on

Punto de vista de principios

(71)

64 5 ADM-Archimate

Figura 5-39: Metamodelo punto de vista de principios

Figura 5-40: Ejemplo punto de vista de principios

Punto de vista de realizaci´

on de requerimientos

Este punto de vista visualiza y define la relaci´on de requerimientos con los actores de negocio, los servicios, procesos y aplicaciones de negocio.

(72)

Figura 5-42: Ejemplo punto de vista de realizaci´on de requerimientos

Punto de vista de motivaci´

on

Este punto de vista visualiza y define la revisi´on de los aspectos motivacionales relacionados con los stakeholders, sus principios primarios, aplicados y los requerimientos m´as relevantes de los servicios, procesos, aplicaciones y objetivos del negocio.

(73)

66 5 ADM-Archimate

Figura 5-44: Ejemplo punto de vista de realizaci´on de requerimientos

5.6. Punto de vista implementaci´

on y migraci´

on

Punto de vista de proyecto

Este punto de vista visualiza y define los cambios en la arquitectura del proceso de migración desde un estado actual de la arquitectura empresarial a un estado objetivo de la arquitectura empresarial, esta migración aporta de forma significativa en el proceso de crecimiento de la estrategia y las decisiones de los procesos de realización.

(74)

5.6 Punto de vista implementaci´on y migraci´on 67

Figura 5-46: Ejemplo punto de vista de proyecto

Punto de vista de migraci´

on

Este punto de vista visualiza y define las caracter´ısticas para la transici´on de una arquitec-tura existente a una arquitecarquitec-tura deseada. La platea es el estado de la arquitecarquitec-tura que tiene un un tiempo limitado.

Figura 5-47: Metamodelo punto de vista de migraci´on

Punto de vista de migraci´

on e implementaci´

on

(75)

68 5 ADM-Archimate

Figura 5-48: Ejemplo punto de vista de migraci´on

relaciona objetivos de negocio a trav´es de los programas y proyectos de la arquitectura.

(76)

5.6 Punto de vista implementaci´on y migraci´on 69

(77)

Parte III

(78)

Cap´ıtulo 6

Resultados y discusi´

on

Los resultados de este trabajo se hallaron con la ayuda de la aplicación Apache JMeter, en donde se realizó cuatro (4) series de env´ıo de peticiones a cada Api Gateway. Las series se estableció con las siguientes peticiones: 100, 500, 1.000 y 5.000 request.

Apache JMeter

La aplicación Apache JMeter es un software de c´digo abierto, una aplicación Java 100 % pura diseñada para cargar el comportamiento funcional de la prueba y medir el rendimiento. Ori-ginalmente fue diseñado para probar aplicaciones web, pero desde entonces se ha expandido a otras funciones de prueba.

Figura 6-1: Apache JMeter

(79)

72 6 Resultados y discusi´on

Resultados con 100 Peticiones http

En la figura 6-2muestra el comportamiento de cada Api Gateway en relaci´on al tiempo de contestaci´on de 100 peticiones.

Figura 6-2: Respuesta de cada Api Gateway

Promedio M´ınimo M´aximo

Gateway NodeJS 126 4 2161

Gateway Spring Cloud 10 5 110

Gateway Spring Boot 15 9 45

Cuadro6-1: Resumen de transaccionalidad para 100 peticiones http

En la obtenci´on de resultados, se evidencia que el Api con mayor transaccionalidad en prome-dio para 100 peticiones realizadas es el Gateway desarrollado con Spring Cloud. (ver figura 6-3)

(80)

73

Figura 6-3: Promedio tiempos de respuesta para 100 peticiones

Figura 6-4: Tiempos M´ınimo de respuesta para 100 peticiones

(81)

Figura 6-5: Tiempos M´aximo de respuesta para 100 peticiones

Resultados con 500 Peticiones http

La figura 6-6 detalla el comportamiento de 500 peticiones env´ıadas a cada uno de los Api Gateway.

Gateway Spring Cloud 213 9 778 Gateway Spring Boot 185 18 850 Cuadro6-2: Resumen de transaccionalidad para 500 peticiones http

De la figura 6-7, se puede ver que la tendencia es que el API Gateway orientado a objetos con Spring Boot, es el que tiene mayor transaccionalidad.

Por otro lado, el API Gateway que present´o la respuesta en el menor tiempo posible, fue el desarrollado con tecnolog´ıa Spring Cloud Gateway. (Ver figura 6-8)

(82)

75

(83)

Figura 6-8: Tiempos M´ınimo de respuesta para 500 peticiones

(84)

77

Resultados con 1.000 Peticiones http

La figura 6-10 muestra los tiempos de respuesta para 1000 peticiones env´ıadas a cada uno de los Api Gateway.

Gateway Spring Cloud 1510 9 3373 Gateway Spring Boot 2124 46 3691 Cuadro6-3: Resumen de transaccionalidad para 1.000 peticiones http

De las métricas obtenidas están muy similares pero se puede determinar que el API Gateway empezó a tener tendencia lineal.

(85)

Figura 6-11: Promedio tiempos de respuesta para 1.000 peticiones

(86)

79

(87)

Resultados con 5.000 Peticiones http

Seg´un los datos arrojados, se muestra en la figura 6-14 los tiempos de respuesta para 5.000 peticiones env´ıadas a cada uno de los Api Gateway.

Gateway Spring Cloud 466 4 2401 Gateway Spring Boot 1474 5 6603 Cuadro 6-4: Resumen de transaccionalidad para 5.000 peticiones http

Aunque en las figuras 6-15, 6-16, 6-17 el API Gateway desarrollado con NodeJS, presen-ta una baja transaccionalidad; en la figura 6-14 muestra la siguiente tendencia: a mayor n´umero de peticiones empieza a decrecer los tiempos de respuesta, caso contrario pasa con el desarrollo de Spring Boot, el cual empieza a formar tendencia lineal a mayor n´umero de peticiones.

(88)

81

Figura 6-15: Promedio tiempos de respuesta para 5.000 peticiones

(89)

(90)

Cap´ıtulo 7

Conclusiones

7.1. Verificaci´

on, contraste y evaluaci´

on de los

objeti-vos

A continuaci´on se presentan algunas reflexiones que a partir del desarrollo del presente trabajo se generaron, se realiza un an´alisis de sus objetivos.

Analizando la transaccionalidad de un Api Gateway desarrollado con el paradigma orientado a objetos frente al paradigma reactivo, se logra determinar que gracias a la arquitectura as´ıncrona del paradigma, el API Gateway que tiene mayor transacciona-lidad concurrente es el desarrollado con programaci´on reactiva.

El paradigma orientado a objetos con Spring Boot, es una buena alternativa para hacer software en donde el dominio de usuario no supere los 5.000 usuarios, pero cuando se trata de manejar una alta concurrencia de usuarios, como por ejemplo aplicaciones de talla mundial (Netflix, Uber, etc). No es un paradigma recomendado.

Spring Cloud Gateway es una tecnolog´ıa bastante eficiente comparada con las dem´as tecnolog´ıas evaluadas, en verdad es una alternativa a servicios ofrecidos por grandes compa˜n´ıas como por ejemplo Amazon con su AWS. Sin embargo se recomienda realizar pruebas con tecnolog´ıas tales como: ReactiveX y Akka.

El análisis no solo sirvió para identificar qué paradigma tiene un mejor rendimiento frente al otro, sino que también se destaca el diseño, funcionamiento y comportamiento del componente software.

7.2. S´ıntesis del modelo propuesto

(91)

84 7 Conclusiones

7.3. Aportes originales

(92)

Cap´ıtulo 8

Prospectiva del trabajo de grado

8.1. L´ıneas de investigaci´

on futuras

El API Gateway con programación reactiva fue el reto para este análisis, por lo tanto hay tecnolog´ıas que ameritan explorarse, con estas tecnolog´ıas quizás se pueda crear componentes con mayor rendimiento software.

Reactive X

ReactiveX es una biblioteca para componer programas as´ıncronos y basados en eventos me-diante el uso de secuencias observables.

Extiende el patr´on de observador para admitir secuencias de datos y/o eventos y agrega operadores que le permiten componer secuencias de manera declarativa al tiempo que abs-trae las preocupaciones sobre cosas como subprocesos de bajo nivel, sincronizaci´on, seguridad de subprocesos, estructuras de datos concurrentes. Bloqueo de Entrada/Salida. [Web13]

Akka

Akka proporciona API para Java y Scala. Ambas son compatibles con la gama completa de caracter´ısticas de Akka para brindar una excelente experiencia de desarrollo al crear sistemas concurrentes y distribuidos. [Web11]

Akka es un conjunto de herramientas para crear aplicaciones basadas en mensajes altamente concurrentes, distribuidas y resistentes para Java y Scala.

8.2. Trabajos de Investigaci´

on futuros

(93)

86 8 Prospectiva del trabajo de grado

´

unicamente se consider´o el rendimiento a la hora de contestar peticiones. Por eso se propone los siguientes trabajos futuros:

Analizar la mantenibilidad de un componente API Gateway desarrollado bajo el paradigma orientado a objetos frente al paradigma reactivo. Si bien es cierto, la pro-gramación reactiva es as´ıncrona lo cual permite una mayor transaccionalidad, no tiene mucha documentación; por lo tanto realizar un cambio, una mejora, puede ser más costoso si se compara a otra programación.