Arquitectura de integraci on basada en tecnolog a

Arquitectura de integracion basada en tecnologıa

Blockchain para sistemas transaccionales con bases

de datos distribuidas

Caso de estudio: Facturacion agencia de viaje

Cristhian Camilo Jaramillo RamosMauricio Ivan Ospina Beltran

2 de diciembre de 2019

2

0.1. Resumen

El presente documento trata sobre el diseno de una nueva arquitecturade integracion para sistemas que cuenten con bases de datos distribuidas atraves de la implementacion de la tecnologıa blockchain, como una alterna-tiva para los actuales sistemas transaccionales que cuenten con este tipo decaracterısticas en sus sistemas.

Ademas, se muestra a traves de un caso de estudio real, cuales son lasprincipales ventajas de la implementacion de esta arquitectura, y como lopodemos realizar a traves del diseno de una arquitectura aplicada al caso.

En este documento se muestra todas las fases necesarias para poder llevara cabo el proyecto y la forma de implementarlo con base en la arquitecturaempresarial apoyada con metodologıa de proyecto ADM y la metodologıade trabajo scrum.

0.2. Palabras clave

Blockchain, bases de datos distribuidas, microservicios, api, arquitecturaempresarial, ADM, scrum, archimate, seguridad, tolerancia a fallos, escala-bilidad, agencias de viaje.

0.3. ABSTRACT 3

0.3. Abstract

This document relates about the design of a new integration architecturefor systems that have distributed databases through the implementation ofblockchain technology, as an alternative for current transactional systemsthat have these types of features in their systems.

In addition, it is shown through a real case study, which are the main ad-vantages of the implementation of this architecture, and how we can do itthrough the design of an architecture applied to the case.

This document shows all the phases necessary to accomplish the projectand how to implement it based on the enterprise architecture supported byADM project methodology and scrum work methodology.

0.4. Keywords

Blockchain, distributed databases, microservices, api, enterprise archi-tecture, ADM, scrum, archimate, security, fault tolerance, scalability, travelagencies.

4

Indice general

0.1. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

0.2. Palabras clave . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

0.3. Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

0.4. Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

INTRODUCCION 15

I Proyecto 17

1. Descripcion de la investigacion 19

1.1. Planteamiento del problema . . . . . . . . . . . . . . . . . . . 19

1.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

1.2.1. Objetivo General . . . . . . . . . . . . . . . . . . . . . 20

1.2.2. Objetivos especıficos . . . . . . . . . . . . . . . . . . . 20

1.3. Justificacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

1.4. Hipotesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

1.5. MARCO REFERENCIAL . . . . . . . . . . . . . . . . . . . . 22

1.5.1. MARCO TEORICO . . . . . . . . . . . . . . . . . . . 22

1.5.2. Arquitectura de software . . . . . . . . . . . . . . . . . 22

1.5.3. Bases de datos distribuidas . . . . . . . . . . . . . . . 22

1.5.4. Blockchain . . . . . . . . . . . . . . . . . . . . . . . . 24

1.5.5. Microservicios . . . . . . . . . . . . . . . . . . . . . . . 25

1.5.6. Metodologıa Scrum . . . . . . . . . . . . . . . . . . . . 26

1.6. MARCO CONCEPTUAL . . . . . . . . . . . . . . . . . . . . 28

1.6.1. Bases de datos . . . . . . . . . . . . . . . . . . . . . . 28

1.6.2. Protocolo de transferencia de hipertexto (HTTP) . . . 29

1.6.3. Servidor de aplicaciones . . . . . . . . . . . . . . . . . 30

1.6.4. Internet Protocol . . . . . . . . . . . . . . . . . . . . . 31

1.6.5. Node Js . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5

6 INDICE GENERAL

1.6.6. React JS . . . . . . . . . . . . . . . . . . . . . . . . . 33

1.7. Estudio de sistemas previos . . . . . . . . . . . . . . . . . . . 33

1.7.1. Implementacion de un sistema de microservicios concontratos inteligentes de Blockchain . . . . . . . . . . 33

1.7.2. Una arquitectura habilitada para microservicios parala vigilancia inteligente utilizando la tecnologıa Block-chain . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

II Arquitectura 39

2. Organizacion 41

2.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

2.2. Nombre de la Empresa . . . . . . . . . . . . . . . . . . . . . . 42

2.3. Mision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

2.4. Vision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

2.5. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

2.6. Servicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

2.7. Proceso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

2.8. Actores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

2.9. Productos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3. Metodologıa 45

3.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

3.2. ADM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

3.2.1. Fase preliminar . . . . . . . . . . . . . . . . . . . . . . 47

3.2.2. Fase A - Vision de la arquitectura . . . . . . . . . . . 47

3.2.3. Fase B - Arquitectura empresarial . . . . . . . . . . . 47

3.2.4. Fase C - Arquitectura de sistemas de informacion . . . 47

3.2.5. Fase D - Arquitectura tecnologica . . . . . . . . . . . 48

3.2.6. Fase E - Oportunidades y soluciones . . . . . . . . . . 48

3.2.7. Fase F - Planificacion de la migracion . . . . . . . . . 48

3.2.8. Fase G - Gobierno de implementacion . . . . . . . . . 48

3.2.9. Fase H - Gestion del cambio de arquitectura . . . . . . 48

3.3. Archimate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

3.4. Historias de usuario . . . . . . . . . . . . . . . . . . . . . . . 49

4. Negocio 53

4.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

4.2. Organizacion . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

INDICE GENERAL 7

4.2.1. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . 54

4.2.2. Caso . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

4.3. Cooperacion de Actor . . . . . . . . . . . . . . . . . . . . . . 55

4.3.1. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . 55

4.3.2. Caso . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

4.4. Funcion de Negocio . . . . . . . . . . . . . . . . . . . . . . . . 56

4.4.1. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . 56

4.4.2. Caso . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

4.5. Proceso de Negocio . . . . . . . . . . . . . . . . . . . . . . . . 57

4.5.1. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . 58

4.5.2. Caso . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

4.6. Cooperacion de Proceso de Negocio . . . . . . . . . . . . . . . 59

4.6.1. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . 59

4.6.2. Caso . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

4.7. Producto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

4.7.1. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . 61

4.7.2. Caso . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

5. Aplicacion 63

5.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

5.2. Comportamiento de Aplicacion . . . . . . . . . . . . . . . . . 64

5.2.1. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . 64

5.2.2. Caso . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

5.3. Estructura de Aplicacion . . . . . . . . . . . . . . . . . . . . . 65

5.3.1. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . 66

5.3.2. Caso . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

5.4. Cooperacion de Aplicacion . . . . . . . . . . . . . . . . . . . . 67

5.4.1. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . 67

5.4.2. Caso . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

5.5. Uso de Aplicacion . . . . . . . . . . . . . . . . . . . . . . . . 68

5.5.1. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . 69

5.5.2. Caso . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

6. Tecnologıa 71

6.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

6.2. Implementacion y Despliegue de Aplicacion . . . . . . . . . . 72

6.2.1. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . 72

6.2.2. Caso . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

6.3. Tecnologıa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

6.3.1. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . 74

8 INDICE GENERAL

6.3.2. Caso . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

6.4. Uso de Tecnologıa . . . . . . . . . . . . . . . . . . . . . . . . 76

6.4.1. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . 77

6.4.2. Caso . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

6.5. Estructura de informacion . . . . . . . . . . . . . . . . . . . . 78

6.5.1. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . 79

6.5.2. Caso . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

6.6. Realizacion del Servicio . . . . . . . . . . . . . . . . . . . . . 81

6.6.1. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . 81

6.6.2. Caso . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

6.7. Capas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

6.7.1. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . 83

6.7.2. Caso . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

7. Migracion 85

7.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

7.2. Proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

7.2.1. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . 86

7.2.2. Caso . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

7.3. Migracion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

7.3.1. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . 87

7.3.2. Caso . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

7.4. Implementacion . . . . . . . . . . . . . . . . . . . . . . . . . . 88

7.4.1. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . 89

7.4.2. Caso . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

8. Motivacion 91

8.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

8.2. Implicados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

8.2.1. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . 92

8.2.2. Caso . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

8.3. Realizacion de Objetivos . . . . . . . . . . . . . . . . . . . . . 93

8.3.1. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . 94

8.3.2. Caso . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

8.4. Contribucion de Objetivos . . . . . . . . . . . . . . . . . . . . 95

8.4.1. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . 95

8.4.2. Caso . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

8.5. Principios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

8.5.1. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . 97

8.5.2. Caso . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

INDICE GENERAL 9

8.6. Realizacion de Requerimientos . . . . . . . . . . . . . . . . . 98

8.6.1. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . 98

8.6.2. Caso . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

8.7. Motivacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

8.7.1. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . 100

8.7.2. Caso . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

9. Protocolo Blockchain 103

9.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

9.2. Diseno y especificacion . . . . . . . . . . . . . . . . . . . . . . 104

9.2.1. Definicion de propiedades . . . . . . . . . . . . . . . . 104

10.Patrones 107

10.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

10.2. Patrones creacionales . . . . . . . . . . . . . . . . . . . . . . . 108

10.2.1. Singleton . . . . . . . . . . . . . . . . . . . . . . . . . 108

10.3. Patrones estructurales . . . . . . . . . . . . . . . . . . . . . . 111

10.3.1. Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

11.Prototipo de aplicacion: TicketChain 115

11.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

11.2. Aerolineas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

11.2.1. Lectura . . . . . . . . . . . . . . . . . . . . . . . . . . 116

11.2.2. Creacion . . . . . . . . . . . . . . . . . . . . . . . . . . 116

11.2.3. Edicion . . . . . . . . . . . . . . . . . . . . . . . . . . 117

11.2.4. Eliminacion . . . . . . . . . . . . . . . . . . . . . . . . 118

11.3. Agencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

11.3.1. Lectura . . . . . . . . . . . . . . . . . . . . . . . . . . 118

11.3.2. Creacion . . . . . . . . . . . . . . . . . . . . . . . . . . 119

11.3.3. Edicion . . . . . . . . . . . . . . . . . . . . . . . . . . 120

11.3.4. Eliminacion . . . . . . . . . . . . . . . . . . . . . . . . 120

11.4. Destinos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

11.4.1. Lectura . . . . . . . . . . . . . . . . . . . . . . . . . . 121

11.4.2. Creacion . . . . . . . . . . . . . . . . . . . . . . . . . . 122

11.4.3. Edicion . . . . . . . . . . . . . . . . . . . . . . . . . . 123

11.4.4. Eliminacion . . . . . . . . . . . . . . . . . . . . . . . . 123

11.5. Clientes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

11.5.1. Lectura . . . . . . . . . . . . . . . . . . . . . . . . . . 124

11.5.2. Creacion . . . . . . . . . . . . . . . . . . . . . . . . . . 125

11.5.3. Edicion . . . . . . . . . . . . . . . . . . . . . . . . . . 126

10 INDICE GENERAL

11.5.4. Eliminacion . . . . . . . . . . . . . . . . . . . . . . . . 12611.6. Tiquetes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

11.6.1. Lectura . . . . . . . . . . . . . . . . . . . . . . . . . . 12711.6.2. Creacion . . . . . . . . . . . . . . . . . . . . . . . . . . 12811.6.3. Edicion . . . . . . . . . . . . . . . . . . . . . . . . . . 12911.6.4. Eliminacion . . . . . . . . . . . . . . . . . . . . . . . . 129

11.7. Facturas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13011.7.1. Lectura . . . . . . . . . . . . . . . . . . . . . . . . . . 13011.7.2. Creacion . . . . . . . . . . . . . . . . . . . . . . . . . . 13111.7.3. Edicion . . . . . . . . . . . . . . . . . . . . . . . . . . 13211.7.4. Eliminacion . . . . . . . . . . . . . . . . . . . . . . . . 132

III Cierre 135

12.Resultados y discusion 13712.1. Seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13812.2. Escalabilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . 14012.3. Tolerancia a fallos . . . . . . . . . . . . . . . . . . . . . . . . 14112.4. Pruebas funcionales . . . . . . . . . . . . . . . . . . . . . . . 144

13.Analisis de resultados 14713.1. Seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14713.2. Escalabilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . 14713.3. Tolerancia a fallos . . . . . . . . . . . . . . . . . . . . . . . . 148

14.Recomendaciones 149

15.Conclusiones 15115.1. Verificacion, contraste y evaluacion de los objetivos . . . . . . 15115.2. Sintesis del modelo propuesto . . . . . . . . . . . . . . . . . . 15215.3. Aportes originales . . . . . . . . . . . . . . . . . . . . . . . . 15215.4. Trabajos o publicaciones derivadas . . . . . . . . . . . . . . . 153

16.Prospectiva de trabajo de grado 15516.1. Lıneas de investigacion futura . . . . . . . . . . . . . . . . . . 15516.2. Trabajos de investigacion futuros . . . . . . . . . . . . . . . . 15516.3. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . 156

Indice de figuras

1.1. Capas de transparencia[1] . . . . . . . . . . . . . . . . . . . . 24

1.2. Vista general de arquitectura de microservicios[2] . . . . . . . 26

1.3. Fujo de scrum para un sprint[3] . . . . . . . . . . . . . . . . . 27

1.4. Comunicacion web server cliente[4] . . . . . . . . . . . . . . . 31

1.5. Cabecera de paquete de Protocolo Internet[5] . . . . . . . . . 32

1.6. Arquitectura del sistema basada en blockchain[6] . . . . . . . 35

1.7. Arquitectura del sistema basada en microservicios[6] . . . . . 36

1.8. Diagrama de bloques de microservicios de analisis de videoen Blockchain[7] . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.1. Modelo ADM [8] . . . . . . . . . . . . . . . . . . . . . . . . . 46

3.2. Historia de usuario - busqueda de tiquetes . . . . . . . . . . . 50

3.3. Historia de usuario - listado de tiquetes . . . . . . . . . . . . 50

3.4. Historia de usuario - facturacion . . . . . . . . . . . . . . . . 51

4.1. Organizacion[9] . . . . . . . . . . . . . . . . . . . . . . . . . . 54

4.2. Caso Organizacion . . . . . . . . . . . . . . . . . . . . . . . . 54

4.3. Metamodelo cooperacion de actor[9] . . . . . . . . . . . . . . 55

4.4. Caso cooperacion de actor . . . . . . . . . . . . . . . . . . . . 56

4.5. Metamodelo funcion de negocio[9] . . . . . . . . . . . . . . . 56

4.6. Caso funcion de negocio . . . . . . . . . . . . . . . . . . . . . 57

4.7. Metamodelo proceso de negocio[9] . . . . . . . . . . . . . . . 58

4.8. Caso proceso de negocio . . . . . . . . . . . . . . . . . . . . . 58

4.9. Metamodelo cooperacion de proceso de negocio[9] . . . . . . . 59

4.10. Caso cooperacion de proceso de negocio . . . . . . . . . . . . 60

4.11. Metamodelo de producto[9] . . . . . . . . . . . . . . . . . . . 61

4.12. Caso de producto . . . . . . . . . . . . . . . . . . . . . . . . . 62

5.1. Metamodelo comportamiento de aplicacion[9] . . . . . . . . . 64

5.2. Comportamiento de aplicacion . . . . . . . . . . . . . . . . . 65

11

12 INDICE DE FIGURAS

5.3. Metamodelo estructura de aplicacion[9] . . . . . . . . . . . . 665.4. Estructura de aplicacion . . . . . . . . . . . . . . . . . . . . . 665.5. Metamodelo cooperacion de aplicacion[9] . . . . . . . . . . . . 675.6. Cooperacion de aplicacion . . . . . . . . . . . . . . . . . . . . 685.7. Metamodelo uso de aplicacion[9] . . . . . . . . . . . . . . . . 695.8. Uso de aplicacion . . . . . . . . . . . . . . . . . . . . . . . . . 70

6.1. Metamodelo implementacion y despliegue de aplicacion[9] . . 726.2. Implementacion y despliegue de aplicacion . . . . . . . . . . . 736.3. Modelo Tecnologıa[9] . . . . . . . . . . . . . . . . . . . . . . . 746.4. Caso Tecnologıa . . . . . . . . . . . . . . . . . . . . . . . . . 756.5. Metamodelo uso de tecnologıa[9] . . . . . . . . . . . . . . . . 776.6. Uso de tecnologıa . . . . . . . . . . . . . . . . . . . . . . . . . 786.7. Modelo Estructura de informacion[9] . . . . . . . . . . . . . . 796.8. Caso Estructura de informacion . . . . . . . . . . . . . . . . . 806.9. Modelo realizacion del servicio[9] . . . . . . . . . . . . . . . . 816.10. Realizacion del servicio . . . . . . . . . . . . . . . . . . . . . . 826.11. Metamodelo de capas[9] . . . . . . . . . . . . . . . . . . . . . 836.12. Capas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

7.1. Modelo Proyecto[9] . . . . . . . . . . . . . . . . . . . . . . . . 867.2. Caso Proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . 867.3. Modelo Migracion[9] . . . . . . . . . . . . . . . . . . . . . . . 877.4. Caso Migracion . . . . . . . . . . . . . . . . . . . . . . . . . . 887.5. Modelo Implementacion[9] . . . . . . . . . . . . . . . . . . . . 897.6. Caso Implementacion . . . . . . . . . . . . . . . . . . . . . . . 89

8.1. Metamodelo de implicados[9] . . . . . . . . . . . . . . . . . . 928.2. Implicados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 938.3. Modelo Realizacion de objetivos[9] . . . . . . . . . . . . . . . 948.4. Caso Realizacion de objetivos . . . . . . . . . . . . . . . . . . 948.5. Metamodelo contribucion de objetivos[9] . . . . . . . . . . . . 958.6. Contribucion de objetivos . . . . . . . . . . . . . . . . . . . . 968.7. Modelo Principios[9] . . . . . . . . . . . . . . . . . . . . . . . 978.8. Caso Principios . . . . . . . . . . . . . . . . . . . . . . . . . . 978.9. Metamodelo realizacion de requerimientos[9] . . . . . . . . . . 988.10. Realizacion de requerimientos . . . . . . . . . . . . . . . . . . 998.11. Modelo Motivacion[9] . . . . . . . . . . . . . . . . . . . . . . 1008.12. Caso Motivacion . . . . . . . . . . . . . . . . . . . . . . . . . 101

9.1. Protocolo - Transaccion blockchain . . . . . . . . . . . . . . . 104

INDICE DE FIGURAS 13

9.2. Protocolo - Bloque blockchain . . . . . . . . . . . . . . . . . . 104

10.1. Singleton [10] . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

10.2. Singleton actividad[10] . . . . . . . . . . . . . . . . . . . . . . 109

10.3. Singleton aplicacion . . . . . . . . . . . . . . . . . . . . . . . 110

10.4. Proxy[10] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

10.5. Secuencia de patron Proxy[10] . . . . . . . . . . . . . . . . . . 112

10.6. Modelo aplicado patron Proxy . . . . . . . . . . . . . . . . . 113

10.7. Codigo fuente patron proxy . . . . . . . . . . . . . . . . . . . 114

11.1. Lectura de aerolıneas . . . . . . . . . . . . . . . . . . . . . . . 116

11.2. Creacion de aerolınea . . . . . . . . . . . . . . . . . . . . . . . 117

11.3. Edicion de aerolınea . . . . . . . . . . . . . . . . . . . . . . . 117

11.4. Eliminacion de aerolınea . . . . . . . . . . . . . . . . . . . . . 118

11.5. Lectura de agencias . . . . . . . . . . . . . . . . . . . . . . . . 119

11.6. Creacion de agencias . . . . . . . . . . . . . . . . . . . . . . . 119

11.7. Edicion de agencia . . . . . . . . . . . . . . . . . . . . . . . . 120

11.8. Eliminacion de agencia . . . . . . . . . . . . . . . . . . . . . . 121

11.9. Lectura de destinos . . . . . . . . . . . . . . . . . . . . . . . . 122

11.10.Creacion de destino . . . . . . . . . . . . . . . . . . . . . . . . 122

11.11.Edicion de destino . . . . . . . . . . . . . . . . . . . . . . . . 123

11.12.Eliminacion de destino . . . . . . . . . . . . . . . . . . . . . . 124

11.13.Lectura de clientes . . . . . . . . . . . . . . . . . . . . . . . . 125

11.14.Creacion de cliente . . . . . . . . . . . . . . . . . . . . . . . . 125

11.15.Edicion de cliente . . . . . . . . . . . . . . . . . . . . . . . . . 126

11.16.Eliminacion de cliente . . . . . . . . . . . . . . . . . . . . . . 127

11.17.Lectura de tiquetes . . . . . . . . . . . . . . . . . . . . . . . . 128

11.18.Creacion de tiquete . . . . . . . . . . . . . . . . . . . . . . . . 128

11.19.Edicion de tiquete . . . . . . . . . . . . . . . . . . . . . . . . 129

11.20.Eliminacion de tiquete . . . . . . . . . . . . . . . . . . . . . . 130

11.21.Lectura de facturas . . . . . . . . . . . . . . . . . . . . . . . . 131

11.22.Registro de factura . . . . . . . . . . . . . . . . . . . . . . . . 131

11.23.Edicion de factura . . . . . . . . . . . . . . . . . . . . . . . . 132

11.24.Eliminacion de factura . . . . . . . . . . . . . . . . . . . . . . 133

12.1. Hash Seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . 139

12.2. Escalabilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

12.3. Tolerancia a fallos . . . . . . . . . . . . . . . . . . . . . . . . 141

12.4. Bases de datos nodos . . . . . . . . . . . . . . . . . . . . . . . 142

12.5. Sincronizacion bases de datos nodos . . . . . . . . . . . . . . 142

14 INDICE DE FIGURAS

12.6. Consenso nodos 1 . . . . . . . . . . . . . . . . . . . . . . . . . 14312.7. Consenso nodos 2 . . . . . . . . . . . . . . . . . . . . . . . . . 14312.8. Consenso base de datos . . . . . . . . . . . . . . . . . . . . . 14412.9. Pruebas funcionales ejecutadas . . . . . . . . . . . . . . . . . 14512.10.Total pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . 14512.11.Total pruebas por modulo . . . . . . . . . . . . . . . . . . . . 145

Introduccion

Las arquitecturas actuales de software se basan en la combinacion dediversas tecnologıas y protocolos que, sumando sus caracterısticas y benefi-cios, permiten resolver problemas de comunicacion y diseno en las solucionestecnologicas que son usadas hoy en dıa. Brindando diversas soluciones a pro-blemas especıficos, y obteniendo un valor agregado a un modelo de negociopredeterminado, potenciando los procesos y mejorando resultados.Debido a que cada vez el mercado esta en constante movimiento y deman-dando nuevas soluciones tecnologicas, donde se requiere de nuevos modelosque permitan cambiar, mejorar o complementar los actuales. En el presentedocumento se presenta como a traves de tecnologıas actuales y de licencia-miento libre se puede proponer una nueva arquitectura alternativa, enfocadaa sistemas transaccionales que trabajen con bases de datos distribuidas dis-frutando de las principales caracterısticas de la tecnologıa blockchain la cualbrinda un valor agregado en la seguridad y escalabilidad en los sistemas quela operan. Adicionalmente se muestra el proceso de investigacion y metodicoque se toma para ejecutar el proyecto, ası como el proceso y herramientasnecesarias para la construccion de los artefactos necesarios que la componen.

15

16 INTRODUCCION

Parte I

Proyecto

17

Capıtulo 1

Descripcion de lainvestigacion

1.1. Planteamiento del problema

En el diseno de nuevos sistemas de informacion, se tiene en cuenta losprocesos normales de arquitectura de nuevos sistemas, los cuales sugierencomo mınimo una capa de presentacion, una capa de logica y una capade persistencia, siendo esta ultima centralizada en la mayorıa de los casos,con una infraestructura potente, que normalmente se encuentra contratadaa terceros especializados en el tratamiento y gestion de grandes volumenesde datos que a traves de niveles (Tier) ofrecen servicios de disponibilidad,seguridad, respaldo y control de la informacion, lo cual conlleva a costosrelativamente altos al momento de contratar estos servicios, adicional deque los tiempos de respuesta del sistema gestor de bases de datos van a serrelativos de acuerdo al nivel de infraestructura y recursos con el que cuenteel servicio, traduciendose en costos mas elevados en caso de requerir mejo-res prestaciones o tiempos de respuesta, debido a que toda la carga de laoperacion se centra en un solo nodo. En base a este escenario, existen otrasalternativas como los sistemas de bases de datos distribuidas, donde todala carga de la operacion se centra en diversos sistemas gestores de basesde datos que fısicamente se encuentran con infraestructuras diferentes, perologicamente siguen siendo uno solo, donde uno de los inconvenientes que sepresentan es que estas implementaciones terminan siendo poco seguras, muycostosas, difıciles de configurar y sincronizar.De acuerdo a esto, se sugiere la creacion de una nueva arquitectura que per-mita la conexion de sistemas transaccionales con bases de datos distribuidas

19

20 CAPITULO 1. DESCRIPCION DE LA INVESTIGACION

implementando los conceptos de la tecnologıa blockchain, donde la carga detoda la operacion del sistema sea gestionada y distribuida por esta, favore-ciendo la seguridad, escalabilidad, disponibilidad, costos de implementaciony de configuracion al momento de disenar y mantener un sistema empresarialque requiera buen desempeno y rendimiento dentro de la operacion.

1.2. Objetivos

1.2.1. Objetivo General

Desarrollar una arquitectura de integracion para pequenas empresas quepermita la conexion de sistemas transaccionales con bases de datos distri-buidas implementando la tecnologıa blockchain, tomando como referencia elcaso de estudio de la compra de tiquetes aereos en lınea.

1.2.2. Objetivos especıficos

1. Disenar un prototipo web que permita utilizar la arquitectura propuestapara demostrar su funcionamiento.

2. Desarrollar microservicios implementando los conceptos de la tecnologıablockchain para la comunicacion de sistemas transaccionales con bases dedatos distribuidas.

3. Crear una arquitectura alternativa para los sistemas de informacion delas pequenas empresas.

1.3. Justificacion

Desde sus inicios, los sistemas de bases de datos distribuidos han sidoimplementados con el fin de manejar grandes volumenes de informacion demanera descentralizada, manteniendo una estructura relacional logica entrecada uno de los nodos existentes en el sistema distribuido. Este modelo deadministracion se caracteriza por que cada una de las bases de datos queconforman el sistema distribuido esta expuesto en la red, lo que permite darla impresion de funcionar como una unidad centralizada y a su vez brindarun manejo mejor y mas organizado de la informacion. No obstante, estemodelo dadas sus caracterısticas intrınsecas requiere de grandes esfuerzosde implementacion y configuracion, lo cual genera altos costos en su apli-cacion y otorga pocas alternativas para la comunicacion de todo el sistema

1.4. HIPOTESIS 21

distribuido. Por lo cual se plantea un modelo mediante la aplicacion de losconceptos de la tecnologıa blockchain orientado hacia los sistemas transac-cionales, manteniendo los principios de las bases de datos distribuidas, peroagregando valor agregado al utilizar los beneficios que esta trae a nivel de se-guridad, escalabilidad y tolerancia a fallos. Con lo cual, existirıa otra opcionpara la implementacion de bases de datos distribuidas a diferentes modelosde negocio y con cubrimiento a pequenas empresas.

El modelo a proponer plantea la alternativa de comunicar sistemas tran-saccionales con bases de datos distribuidas con la implementacion de losconceptos de blockchain, no solo para lograr costos menores de implemen-tacion sino tambien para brindar mejores aspectos a nivel de seguridad yescalabilidad. Actualmente las bases de datos distribuidas ofrecen la comu-nicacion directa con el motor a utilizar, pero al incorporar sistemas de in-tercomunicacion como los microservicios, se permitirıa interoperar con otrastecnologıas dentro del sistema distribuido.

La incorporacion de la arquitectura propuesta puede ser abordada desdeun enfoque empresarial que permita la intercomunicacion entre el servidorde aplicaciones y los diferentes nodos de persistencia. Esta aplicacion comose puede inferir, es una aplicacion comun existente en los sistemas de infor-macion, en donde la capa de presentacion a traves del control de solicitudesdel usuario ejecuta acciones de acuerdo a la logica de negocio implementa-da y posteriormente se efectuan tareas de almacenamiento en las bases dedatos. De la misma manera la arquitectura brindarıa el flujo de informacionentre las capas mencionadas con la particularidad de que la capa de persis-tencia es de tipo distribuido.

En consecuencia, la alternativa que se propone pretende brindar una al-ternativa eficiente de intercomunicacion en la capa de persistencia para ad-ministrar sistemas transaccionales con bases de datos distribuidas, haciendoun manejo mas optimo en terminos de infraestructura y mejorando la ver-satilidad para la comunicacion con diferentes aplicaciones y clientes

1.4. Hipotesis

La tecnologıa Blockchain permite integrar sistemas transaccionales au-mentando el nivel de seguridad de las aplicaciones, su escalabilidad y susincronıa en cada uno de los nodos de la base de datos distribuida.


1.5. MARCO REFERENCIAL

1.5.1. MARCO TEORICO

1.5.2. Arquitectura de software

La modularidad es el factor que permite ver los elementos que consti-tuyen un software de acuerdo a sus componentes visibles y las relacionesexistentes entre sı, de modo que el sistema pueda ser analizado de maneraholıstica y cohesiva. Esta vision integral del sistema permite analizar tantoel flujo de informacion como el nivel de cumplimiento de los requerimientosdefinidos, para ası interpretar el nivel de efectividad del diseno.La definicion de la arquitectura de software de un sistema esta ligada a sufase de construccion o diseno, siento esta ultima una instancia de la primeraal permitir multiples disenos de desarrollo de software enmarcados en unamisma arquitectura. La definicion esta esta ligada a determinadas fases quevan desde los escenarios de investigacion, obtencion de requerimientos y res-tricciones y la determinacion de estilos o patrones de arquitectura, hasta ladefinicion de atributos de calidad y crıtica de otras arquitecturas candidatas,lo cual permite que de manera iterativa se madure la definicion de la basearquitectural del sistema. De este modo la definicion de una arquitectura desoftware debe trabajarse a partir de la contextualizacion de un problema, ladefinicion de un arquetipo del software, la implementacion o desarrollo de lamisma y la definicion de instancias especıficas que aborden dicho problemapara brindar una solucion.

En una arquitectura de software se hace prioritario el uso de patrones dearquitectura de software, los cuales estan ligados a casos puntuales identifi-cados en la definicion de requerimientos y con los cuales se busca dar soluciona determinada problematica manteniendo los principios de cohesion y bajoacoplamiento del software, de modo que el flujo de datos que describa laestructura de la arquitectura sea de facil entendimiento, permita la visiontotal comprendida en el sistema de manera concisa y brinde a primera vistala solucion a las problematicas evidenciadas [11]

1.5.3. Bases de datos distribuidas

La integracion como el objetivo mas importante de los sistemas de ba-ses de datos en general, permite una mirada diferente a las arquitecturasimplementadas comunmente para el almacenamiento y procesamiento dedatos dentro de un contexto u organizacion. La centralizacion es una de las

1.5. MARCO REFERENCIAL 23

maneras mediante las cuales se puede mantener la informacion de maneraintegrada, sin embargo, no es la unica alternativa y dado a que los siste-mas distribuidos cada vez logran mayor impacto en las telecomunicaciones,la integracion por medio de esta arquitectura busca un mejor acoplamientode la informacion sin la necesidad de que esta se encuentre en un mismorepositorio fısico. No obstante, la implementacion de dichas arquitecturasdepende de resolver la pregunta ¿Que se va a distribuir? Lo cual permitedar un protocolo al sistema distribuido subyacente que podrıa estar enmar-cado segun la logica de procesamiento, las funciones de un sistema, los datoso el control del sistema.

Ademas de responder a la primera pregunta es importante analizar ¿Porque se distribuye? Lo cual permite dar una mirada crıtica sobre que patrones mejor seguir, sus ventajas y sus desventajas y bajo que contextos se pue-den aplicar cada uno. En los sistemas se ha implantado una regla generalla cual puede resumirse en la frase “dividir y conquistar”. La division o dis-tribucion de trabajo permite una mejor organizacion a la hora de brindarsoporte sobre un sistema al dividirlo en pequenos grupos de software. Asımismo, se puede establecer una analogıa entre el principio de bajo acopla-miento del software con la division de grupos mas pequenos en terminos dealmacenamiento de datos.

Luego de establecer lo que se va a distribuir y la razon por la cual se vaa hacer, es necesario entender que una base de datos distribuida es aque-lla que se encuentra logicamente interconectada a traves de una red, perofısicamente se encuentra segmentada en diferentes repositorios o servidores.Ademas, esta descentralizacion de los datos implica que la capa de presen-tacion se encuentre centralizada, es decir, que la aplicacion o servicio hagauso de la distribucion de la base de datos logrando una sincronıa trans-parente que permita ver la relacion logica entre los nodos existentes en elsistema de base de datos distribuido. De hecho, que la aplicacion haga usode la base de datos distribuida permite inferir que debe existir dicha trans-parencia de modo que a nivel logico una consulta pueda emplearse en unnodo u otro, siempre y cuando exista correlacion logica en cada uno de ellos.

La transparencia es un factor que debe estar implıcito en cada una de lascapas del sistema distribuido, es decir, debe estar presente en la indepen-dencia de los datos, la red del sistema, la replicacion de los datos a travesde los nodos, el nivel de fragmentacion y el lenguaje utilizado [1]


Figura 1.1: Capas de transparencia[1]

1.5.4. Blockchain

Uno de los objetivos de la arquitectura de internet era minimizar los pun-tos de fallo. Los centros de conmutacion que caracterizaban la red telefonicaeran tales puntos de fracaso. Si un centro de conmutacion era destruido, lostelefonos en esa area serıan desconectados de la red. Cambiando paquetesen lugar de circuitos. y distribuyendo la funcion de conmutacion a cada en-rutador de internet, se logro ese objetivo.

Por otro lado, poca atencion fue dada a otras dimensiones de la seguri-dad de la red, Y ası, hemos estado jugando con la seguridad en Internet.Cada vez mas funciones de la sociedad son transferidas a Internet, su faltade seguridad se ha convertido en un importante problema social. Esta faltade seguridad es el talon de Aquiles de hoy en dıa en internet, razon porla que la arquitectura P2P y la tecnologıa de cadena de bloques seguro lareemplazara. La arquitectura original de internet era, de hecho, P2P. Estosimplemente significa que cualquier nodo de internet podrıa tanto proporcio-nar servicios a otros nodos como pedir que presten servicios. Por ejemplo, elprotocolo de transferencia de archivos es bidireccional: cualquier nodo puedeenviar o recibir archivos. Internet maduro en los anos 90 y 2000, surgieronservicios importantes que eran unidireccionales, por ejemplo, busquedas enGoogle, compras en Amazon y Amigos de Facebook. Estos servicios fueronproporcionados por nodos que fueron llamados servidores, y los nodos queutilizaban estos servicios eran llamados clientes.

El modelo cliente-servidor esta sujeto a varias violaciones de seguridad (porsupuesto, tambien en P2P). Por ejemplo, los ataques de denegacion de servi-


cio distribuidos inundan un servidor con tantas solicitudes de servicio que seapaga. Ademas, la mayorıa de los servidores requieren nombres de usuarioy contrasenas de los clientes (y tal vez numeros de tarjetas de credito). Ası,muchos usuarios tienen cientos de nombres de usuario y contrasenas, que sesupone se deben recordar y nunca escribir. Y las violaciones de seguridadson muy comunes, cediendo millones de nombres de usuario, contrasenas, ynumeros de tarjetas de credito. Tales trucos son cada vez mas importantescomo en la banca y otros tipos de transacciones significativas que se realizanen lınea. La tecnologıa Blockchain es simplemente un libro mayor distribui-do en una red P2P cuyas transacciones no se puede borrar ni modificar.A medida que ocurren nuevas transacciones y son verificadas, se copian entodas las copias del libro mayor. [12]

1.5.5. Microservicios

La arquitectura orientada a servicios es una tendencia de desarrollo deproyectos informaticas en pro de mejorar la flexibilidad, escalabilidad y fa-cilidad de mantenimiento del software. Estos recursos permiten que existatambien un mejor uso de las practicas de integracion y despliegue continuodel software.

Los microservicios brindan soluciones para abstraer a un maximo nivel loscomponentes de un software de modo que este no sea un sistema monolıti-co el cual, de manera holıstica, sus componentes se encuentren con un altoacoplamiento. Ademas, el desarrollo orientado a los microservicios permi-te una perspectiva de intercomunicacion entre diferentes sistemas haciendouso de internet, de modo que pueda hacer uso de recursos compartidos y loscomponentes expuestos puedan ser usados por multiples plataformas segunel contexto.

Los microservicios presentan sin embargo retos tales como la mejora dela seguridad ya que al existir exposicion a internet de dichos servicios suacceso debe ser restringido o limitado al software cliente. Adicionalmente,al implementar microservicios es preciso inferir que la granularidad debe serun factor indispensable de modo tal que sean distribuibles e independientes,y por lo tanto desacoplados. [2]


Figura 1.2: Vista general de arquitectura de microservicios[2]

Los microservicios ofrecen diversas alternativas en la actualidad, sobretodo si estos quieren ser usados de manera adaptable en sistemas distribui-dos, manejando independencia, alta cohesion y bajo acoplamiento, ademasde permitir la creacion y conexion con diferentes tecnologıas y repositoriosde bases de datos. La subdivision de un sistema en varios microservicios per-mite la capacidad de evolucion del software y la alta recuperacion en caso dela existencia de fallos, ademas aporta hacia las metodologıas de desarrolloagil, despliegue continuo e interconexion desde diferentes aplicaciones clienteconstruidas en tecnologıas diversas.[2]

1.5.6. Metodologıa Scrum

Un proyecto Scrum consiste en un esfuerzo de colaboracion para crearun nuevo producto, servicio u otro resultado tal como se define en la Decla-racion de la vision del proyecto (Project Vision Statement). Los proyectosse ven afectados por limitaciones de tiempo, costos, alcance, calidad, re-cursos, capacidades organizacionales y demas limitaciones que dificultan suplanificacion, ejecucion, administracion y, por ultimo, su exito. Sin embar-go, la implementacion exitosa de los resultados de un proyecto terminado leproporciona ventajas economicas considerables a una organizacion. Por lotanto, es importante que las organizaciones seleccionen e implementen unmetodo adecuado de gestion de proyectos.


Scrum es uno de los metodos agiles mas populares. Es un framework adapta-ble, iterativo, rapido, flexible y eficaz, disenado para ofrecer un valor conside-rable en forma rapida a lo largo del proyecto. Scrum garantiza transparenciaen la comunicacion y crea un ambiente de responsabilidad colectiva y de pro-greso continuo.

El framework de Scrum, tal como se define en la Guıa SBOKTM, esta es-tructurado de tal manera que es compatible con el desarrollo de productosy servicios en todo tipo de industrias y en cualquier tipo de proyecto, inde-pendientemente de su complejidad.

Una fortaleza clave de Scrum radica en el uso de equipos interfuncionales(cross-functional), autoorganizados y empoderados que dividen su trabajoen ciclos de trabajo cortos y concentrados llamados Sprint.[3]

Figura 1.3: Fujo de scrum para un sprint[3]

El ciclo de Scrum empieza con una reunion de stakeholders, durante lacual se crea la vision del proyecto. Despues, el Product Owner desarrolla unaBacklog Priorizado del Producto (Prioritized Product Backlog) que contieneuna lista requerimientos del negocio y del proyecto por orden de importanciaen forma de una historia de usuario. Cada sprint empieza con una reunionde planificacion del sprint (Sprint Planning Meeting) durante la cual seconsideran las historias de usuario de alta prioridad para su inclusion en elsprint. Un sprint generalmente tiene una duracion de una a seis semanasdurante las cuales el Equipo Scrum trabaja en la creacion de entregables


(del ingles deliverables) en incrementos del producto. Durante el sprint, sellevan cabo Daily Standups muy breves y concretos, donde los miembros delequipo discuten el progreso diario. Haca el final del sprint, se lleva a cabouna Reunion de Revision del Sprint (Sprint Review Meeting) en la cualse proporciona una demostracion de los entregables al Product Owner y alos stakeholders relevantes. El Product Owner acepta los entregables solosi cumplen con los criterios de aceptacion predefinidos. El ciclo del sprinttermina con una Reunion de Retrospectiva del Sprint (Retrospect SprintMeeting), donde el equipo analiza las formas de mejorar los procesos y elrendimiento a medida que avanzan al siguiente sprint.[3]

1.6. MARCO CONCEPTUAL

1.6.1. Bases de datos

Las bases de datos son colecciones de informacion que estan relacionadasy permiten dar una organizacion o estructura logica a traves de su alma-cenamiento en un repositorio fısico. Estos datos normalmente no varıan encuanto a su estructura se refiere y su gestion esta dada por sistemas ges-tores de bases de datos (SGBD) lo cuales surgieron en la decada de los 70abarcando en su momento el mercado de las tecnologıas de la informacion.

Dato

Nombre dado a un valor que por sı solo no tiene una coherencia o relacionalguna con una entidad o atributo.

Informacion

Conjunto estructurado de datos asociados a una entidad o relacion logicade acuerdo a un modelo planteado o contexto.

Bases de datos Flat File

Archivos planos que almacenan informacion no relacionada, pero conuna estructura definida.

Bases de datos relacionales

Organizacion de datos a traves de relaciones y entidades.

1.6. MARCO CONCEPTUAL 29

Bases de datos orientadas a objetos

Bases de datos que permiten la organizacion de los datos a traves declases y objetos de las mismas, tambien conocidas a menudo como bases dedatos documentales.

Bases de datos dimensionales

Organizacion de datos integrados en diferentes dimensiones para facili-dad de consulta.[13]

1.6.2. Protocolo de transferencia de hipertexto (HTTP)

HTTP especifica como transferir hipertexto (es decir, documentos webvinculados) entre dos computadoras. Un protocolo es un conjunto de re-glas para la comunicacion entre dos computadoras. HTTP es un protocolotextual, sin estado.

Textual

Todos los comandos son de texto plano y legible para ser leıdo por hu-manos.

Sin estado

Ni el servidor ni el cliente recuerdan las comunicaciones anteriores. Porejemplo, al confiar solo en HTTP, un servidor no puede recordar la contra-sena que ingreso ni el paso que esta realizando en una transaccion. Necesitaun servidor de aplicaciones para tareas como esa.

HTTP proporciona reglas claras sobre como se comunican un cliente yun servidor:

Solo los clientes pueden hacer solicitudes HTTP a los servidores. Losservidores solo pueden responder a la solicitud HTTP de un cliente.

Al solicitar un archivo a traves de HTTP, los clientes deben propor-cionar la URL del archivo.

El servidor web debe responder a todas las solicitudes HTTP, al menoscon un mensaje de error.


En un servidor web, el servidor HTTP es responsable de procesar yresponder las solicitudes entrantes.

1. Al recibir una solicitud, un servidor HTTP primero verifica si la URLsolicitada coincide con un archivo existente.

2. Si es ası, el servidor web envıa el contenido del archivo de nuevo al nave-gador. Si no, un servidor de aplicaciones construye el archivo necesario.

3. Si ninguno de los procesos es posible, el servidor web devuelve un mensajede error al navegador, generalmente ”404 Not Found”. (Ese error es tancomun que muchos disenadores web pasan bastante tiempo disenandopaginas de error 404.) [4]

1.6.3. Servidor de aplicaciones

Podemos referirnos a hardware o software, o a ambos trabajando juntos.

En cuanto a hardware, un servidor web es una computadora que alma-cena los archivos que componen un sitio web (ej. documentos HTML,imagenes, hojas de estilos CSS y archivo JavaScript) y los entrega aldispositivo del usuario final. Esta conectado a internet y es accesiblea traves de un nombre de dominio como mozilla.org.

En cuanto a software, un servidor web tiene muchas partes encargadasdel control sobre como tienen acceso los usuarios a los archivos, por lomenos un servidor HTTP. UN servidor HTTP es una pieza de softwareque comprende URLs (direcciones web) y HTTP (el protocolo que tunavegador usa para ver las paginas web).

Al nivel mas basico, siempre que un navegador necesite un archivo al-macenado en un servidor web, el navegador lo solicita vıa HTTP. Cuando lapeticion llega al servidor web correcto (hardware), el servidor HTTP (soft-ware) envıa el archivo antes solicitado, tambien a traves de HTTP.

1.6. MARCO CONCEPTUAL 31

Figura 1.4: Comunicacion web server cliente[4]

Para publicar un sitio web, necesitaras un servidor web dinamico o estati-co. Un servidor web estatico, o pila, consiste en una computadora (hardware)con un servidor HTTP (software). Llamamos a este .estatico”debido a queel servidor envıa los archivos almacenados ”tal cual.a tu navegador.

Un servidor web dinamico consiste en un servidor web estatico con un soft-ware extra, lo mas comun es que sea una aplicacion servidor y una base dedatos. Llamamos a esto”dinamico”por que la aplicacion servidor actualizalos archivos almacenados antes de enviarlos mediante el servidor HTTP.[4]

1.6.4. Internet Protocol

El Internet Protocol o Protocolo Internet, proporciona la entrega de pa-quetes sin conexion no fiable para Internet.

IP no tiene conexiones porque trata cada paquete de informacion de formaindependiente. No es fiable porque no garantiza la entrada, lo que significaque no necesita reconocimientos del sistema principal de envıo, del sistemaprincipal de recepcion ni de los sistemas principales intermedios.

IP proporciona la interfaz en los protocolos de nivel de interfaz de red.Las conexiones fısicas de una red transfieren la informacion de una tramacon una cabecera y datos. La cabecera contiene la direccion de origen y ladireccion de destino. IP utiliza un datagrama de Internet que contiene infor-macion similar a la trama fısica. El datagrama tambien tiene una cabeceraque contiene direcciones de protocolo de Internet del origen y del destino delos datos.


IP define el formato de todos los datos enviados a traves de Internet.[5]

Figura 1.5: Cabecera de paquete de Protocolo Internet[5]

1.6.5. Node Js

Node.js es un entorno de ejecucion de JavaScript de codigo abierto ymultiplataforma. Node.js ejecuta el motor de JavaScript V8 fuera del nave-gador, el nucleo de Google Chrome. Esto permite que Node.js se beneficiede las mejoras sustanciales de rendimiento y compilacion Just-In-Time querealiza V8. Gracias a esto, el codigo JavaScript que se ejecuta en Node.jspuede llegar a ser muy eficaz.

Una aplicacion Node.js se ejecuta en un solo proceso, sin crear un nue-vo hilo para cada solicitud. Node.js proporciona un conjunto de primitivasI/O asıncronas en su biblioteca estandar que impiden el bloqueo del codigoJavaScript y, en general, las bibliotecas en Node.js se escriben utilizandoparadigmas de no bloqueo, lo que hace que el comportamiento de bloqueosea la excepcion y no la norma.

Cuando Node.js necesita realizar una operacion de I/O, como leer desdela red, acceder a una base de datos o al sistema de archivos, en lugar debloquear el subproceso y perder ciclos de CPU en espera, Node.js reanudaralas operaciones cuando vuelva la respuesta.

Esto permite que Node.js maneje miles de conexiones concurrentes con unsolo servidor sin introducir la carga de administrar la concurrencia de hilos,

1.7. ESTUDIO DE SISTEMAS PREVIOS 33

lo que podrıa ser una fuente importante de errores.[14]

1.6.6. React JS

React es una biblioteca de Javascript que permite crear interfaces dinami-cas de usuario. Esta librerıa ofrece un lenguaje declarativo que permite unamejor y mas facil depuracion, por ende mayor mantenebilidad ante el cam-bio. [15]

React esta basado en componentes encapsulados, los cuales manejan estadosindependientes y se pueden desplegar como interfaces de usuario complejas.Ademas, React ofrece una importante capacidad de usabilidad al integrarReact Native, el cual permite que se renderizen las interfaces de usuarios endispositivos moviles.[15]

React permite a cada componente manejar un estado propio, por tantocuando este estado cambia los nuevos valores se renderizan en el componen-te, permitiendo dinamismo en la actualizacion de las interfaces. Adicional-mente, esta librerıa permite interaccion con otras bibliotecas y frameworks,haciendolo adaptable y compatible con multiples plataformas.[15]

1.7. Estudio de sistemas previos

Debido a que el tema principal de la investigacion es el uso de la tec-nologıa Blockchain y esta embebida dentro de una arquitectura basada enmicroservicios, se tuvo en cuenta investigaciones que abordaran conjunta-mente ambos conceptos. Estas investigacionesmuestran la tendencia de am-bas tecnologıas en el mercado actual, de manera que su relacion forma partede un escenario viable de investigacion, abordando los conceptos clave deBlockchain y contratos inteligentes y su implementacion haciendo uso demicroservicios.

1.7.1. Implementacion de un sistema de microservicios concontratos inteligentes de Blockchain

La descentralizacion de las aplicaciones monolıticas y la aplicacion delos microservicios como tecnologıa emergente han hecho de esta un foco deinvestigacion contınuo. Adicionalmente, la aparicion de otras tecnologıas co-mo Blockchain han permitido que ambas tendencias ofrezcan un panoramaviable para la implementacion de servicios desacoplados haciendo uso de


contratos inteligentes.[6]

Debido a que los contratos inteligentes ejecutan tareas especıficas y general-mente de manera aislada, se puede hallar una corelacion con la arquitecturabasada en microservicios, ya que estos tambien son funcionalidades desaco-pladas que cumplen con una funcion especıfica dentro de una aplicacion. Alunir ambas tecnologıas se puede lograr la ejecucion de codigo confiable yademas la integridad de los datos a procesar.[6]

En terminos de arquitectura, los microservicios y los contratos inteligen-tes trabajan de maneras similares. Los microservicios generalmente estanconstruidos por 3 capas, una capa de aplicacion o presentacion, una cone-xion a un API Gateway y posteriormente un enlace a los microservicios.Ası mismo, los contratos inteligentes se basan en ABI (Interfaz binaria deaplicacion, por sus siglas en ingles) y como segunda capa los contratos inteli-gentes. Aplicaciones externas pueden conectarse a los contratos inteligentesa traves de ABI. Estos contratos inteligentes estan imlementados en la cade-na de bloques. La arquitectura propuesta para vincular estas dos tendenciases simple: vincular los microservicios a los contratos inteligentes a traves deRPC o llamadas a procedimiento remoto como se muestra en la figura.[6]


Figura 1.6: Arquitectura del sistema basada en blockchain[6]

En el caso de estudio se presentan 3 microservicios por simplicidad, noobstante, esta estructura puede escalarse a sistemas muchos mas grandes ycomplejos. El caso de estudio corresponde al seguimiento de los diagnosti-cos de las enfermedades asociadas a pacientes por parte de un medico. Laestructura basada en microservicios se describe en la figura siguiente.


Figura 1.7: Arquitectura del sistema basada en microservicios[6]

Si bien esta investigacion aporta la viabilidad que existe entre el uso demicroservicios y contratos inteligentes de Blockchain, la arquitectura pro-puesta para el caso de estudio de este trabajo no se basa en los contratosinteligentes, pero si en la integracion del prototipo a traves de tres componen-tes clave: Capa de presentacion, microservicios de negocio y API Blockchain.Ası pues, el aporte de trabajos similares ofrece una mirada de integracionpara los sistemas transaccionales usando tecnicas convergentes que permitanbrindar soluciones eficaces a los problemas actuales.

1.7.2. Una arquitectura habilitada para microservicios parala vigilancia inteligente utilizando la tecnologıa Block-chain

El internet de las cosas (IoT por sus siglas en ingles) ha permitido eldesarrollo de ciudades inteligentes al adoptar algoritmos capaces de identifi-car movimientos extranos y reconocimientos de patrones a traves de camaresde vigilancia. Sin embargo, el tratamiento de dicha informacion recopiladay su seguridad, se vuelve un factor a tener en cuenta debido a la aplicacion


de arquitecturas monolıticas que hacen vulnerable una unica base de datosque almacena los registros capturados.[7]

La necesidad de separar funciones y algortimos complejos y ademas separarsu almacenamiento en una red distribuida abre paso a que tecnologıas co-mo Blockchain se sincronicen con el uso de microservicios desacoplados, demodo que los analisis capturados se almacenen como hash en una cadena debloques distribuida.[7]

Figura 1.8: Diagrama de bloques de microservicios de analisis de video enBlockchain[7]

En este caso de estudio se puede ver otra manera de sincronizar tecno-logıas como Blockchain con el uso de microservicios. Cada componente eneste caso tiene una responsabilidad independiente. Los microservicios para ladescentralizacion de las operaciones capturadas en vıdeo y Blockchain comotecnologıa que permite la persistencia de la informacion de manera segura,manejando criptografıa por medio de hash y distribuyendo la informacion enla cadena de bloques. De este modo los movimientos se efectuan a traves delmineo de informacion de cada nodo haciendo uso de algoritmos de consensoque validen y confirmen las transacciones.


Parte II

Arquitectura

39

Capıtulo 2

Organizacion

2.1. Introduccion

En este capıtulo se especifica y aclara el contexto de la organizacionsobre la cual se desarrollara el proyecto, ası como las principales funcionesy productos que suministra la companıa sobre el sector de viajes, negociosobre el cual es destinada la investigacion propuesta. Tambien se abordade manera puntual la organizacion teniendo en cuenta sus objetivos y lasfunciones de negocio existentes para el cumplimiento de los mismos. Asıcomo la generalizacion de los actores, roles y servicios que existen en lacompanıa, con el fin de establecer los alcances e impactos de las solucionespropuestas respecto a las problematicas de la organizacion.

41

42 CAPITULO 2. ORGANIZACION

2.2. Nombre de la Empresa

AMADEUS

2.3. Mision

Desde Amadeus nuestra mision es crear un dialogo abierto con nuestrosinversores y analistas, para construir relaciones a largo plazo basadas en lacredibilidad y la confianza.

2.4. Vision

Ser el proveedor lıder en soluciones de tecnologıa para el sector del viaje.

2.5. Objetivos

Nuestro objetivo es moldear el futuro de los viajes

Viajar amplıa horizontes, establece conexiones y desarrolla economıas.Viajar nos permite progresar. Y Amadeus te permite viajar.

Creamos soluciones de gran importancia que ayudan a aerolıneas, ae-ropuertos, hoteles, lıneas ferroviarias, motores de busqueda, agenciasde viaje y operadores turısticos; y mejoramos la experiencia de viajeen innumerables ocasiones cada ano a escala mundial.

Nos dedicamos a esto desde hace mas de 30 anos y apenas acabamos deempezar. Apostamos por la innovacion. Apostamos por el dinamismo.Trabajamos con clientes y socios para facilitar viajes mejores y masenriquecedores. Nuestra posicion de liderazgo en el sector nos permitemoldear y mejorar el futuro de los viajes.

2.6. Servicios

1. Plataforma de reservas de vuelos aereos.

2. Desarrollo de portales para agencias de viajes

3. Gestion y desarrollo de Backoffice para las agencias de viaje.

4. Reservas de hoteles y carros.

2.7. PROCESO 43

2.7. Proceso

Analitica e inteligencia

Gestion de negocio

Operaciones

Ventas y marketing

Pagos

Gestion del cliente el huesped y el viajero

2.8. Actores

Ingeniero de desarrollo

Coordinador de proyectos

Arquitecto de software

Ingeniero Devops

Ingeniero QA

2.9. Productos

AOL

Web services de reservas

Backoffice

Consultoria

44 CAPITULO 2. ORGANIZACION

Capıtulo 3

Metodologıa

3.1. Introduccion

La arquitectura empresarial es un concepto que permite tener una visionorganizacional y sus relaciones con el entorno, con el fin de identificar estra-tegias para el cumplimiento de los objetivos. Este concepto puede soportarsea traves de ADM (Architecture development method) el cual como marcode trabajo ofrece una mirada al negocio, aplicaciones, infraestructura, im-plementacion, motivacion y estrategia.

Como lenguaje de modelado se hace el diseno de la arquitectura empresariala traves de Archimate, el cual permite desplegar la arquitectura a travesde modelos que soportan las capas de ADM, identificando la corelacion en-tre cada uno de sus niveles y evitando la ambiguedad en las definiciones.Por ultimo, en la metodologıa se muestra la adaptacion de requerimientos atraves de historias de usuario, con el fin de tener una mirada complementa-ria a los requerimientos del prototipo a implementar de cara a la vision deun usuario.

45

46 CAPITULO 3. METODOLOGIA

3.2. ADM

Figura 3.1: Modelo ADM [8]

El metodo de desarrollo de arquitectura o ADM (por sus siglas en igles)permite realizar una representacion de la arquitectura empresarial toman-do como eje 5 capas, las cuales tienen una responsabilidad en particular entorno a las diferentes perspectivas que pueden darse en un proyecto: Negocio,aplicacion, tecnologıa, motivacion y estrategia. Estas capas estan orientadasa modelar el estado actual de la organizacion, sus actores, procesos, servi-cios y productos para identificar dependencias y riesgos y gestionar posiblesmejoras del esquema de la companıa. Ası mismo, la identificacion de estosfactores es la entrada para el analisis de los artefatos de software y aplicacio-nes que contribuiran a la realizacion de dichos servicios de la organizacion,su comunicacion con aplicaciones externas y la colaboracion existente entreestas aplicaciones, los roles y los procesos del entorno. Posteriormente, losartefactos de software brindan informacion de entrada para los requerimien-tos tecnologicos y de infraestructura que se requieren para el funcionamientode la operacion.[8]

3.2. ADM 47

Las tres capas principales de ADM (Negocio, aplicacion y tecnologıa) per-miten dimensionar los requerimientos de despliegue y migracion de las apli-caciones, ası como sus dependencias y posibles riesgos. A su vez, permitenescalar los objetivos de una organizacion y sus partes interesadas de modoque se articulen todas las capas, con el fin de mejorar continuamente la es-trategia en funcion del tiempo.

ADM en su marco de trabajo plantea 8 fases para la definicion de la ar-quitectura empresarial, cada una de estas etapas esta embebida en una delas cinco capas propuestas, iniciando desde la motivacion y estrategia hastala gestion del cambio de la arquitectura, con el fin de que estas fases se pue-dan desplegar de manera iterativa, permitiendo la maduracion de la mismaen cada ciclo.[8]

3.2.1. Fase preliminar

La fase preliminar involucra las actividades de preparacion para crearla arquitectura empresarial. En esta etapa se encuentran los principios dela arquitectura, objetivos comerciales, modelo de la organizacion y el marcode la arquitectura. Los anteriores interactuan en la fase preliminar comoentregables de salida de la arquitectura empresarial.[8]

3.2.2. Fase A - Vision de la arquitectura

En esta fase se realiza la definicion del alcance que tendra la arquitecturaempresarial propuesta. De la misma manera, se identifican los interesados yse plantea la vision de la arquitectura, la cual debe pasar por su respectivaaprobacion para continuar con su desarrollo.

3.2.3. Fase B - Arquitectura empresarial

Esta fase define la estructura organizacional de la empresa para apoyarla vision previamente propuesta, sus areas, dependencias, actores y respon-sabilidades dentro de la arquitectura empresarial.

3.2.4. Fase C - Arquitectura de sistemas de informacion

Contempla el desarrollo de la arquitectura soportada en sistemas de in-formacion y servicios de aplicaciones que apoyen la vision planteada.


3.2.5. Fase D - Arquitectura tecnologica

Contiene los artefactos de infraestructura que soportan las aplicacionesy demas servicios de la fase C, con el fin de hallar riesgos y requisitos decalidad y rendimiento.

3.2.6. Fase E - Oportunidades y soluciones

Ligada a la implementacion y migracion, esta fase identifica rutas posi-bles para llevar a cabo la planificacion realizada hasta el momento en lasfases anteriores.

3.2.7. Fase F - Planificacion de la migracion

Aborda el plan a llevar a cabo para la migracion de la arquitectura base ala arquitectura de destino, con el fin de evolucionar en el tiempo mejorandola arquitectura anterior y adaptando nuevas estrategias y objetivos.

3.2.8. Fase G - Gobierno de implementacion

Funciona como una fase en la que se gestiona el alcance de la implemen-tacion, en esta etapa se evalua las solicitudes de cambio y cumplimiento dela arquitectura.

3.2.9. Fase H - Gestion del cambio de arquitectura

Establece procedimientos para gestionar el cambio de la arquitectura,ası como los requisitos que ello demanda.

3.3. Archimate

Archimate es un lenguaje de modelado enfocado en la arquitectura em-presarial, permite desarrollar modelos de arquitectura basados en ADM.Este lenguaje aborda tres niveles que son: negocio, sistemas de informaciony tecnologıa.

El negocio involucra todas las areas y dependencias de una organizacion asıcomo los roles, responsabilidades y procesos que en ellas se presentan. Tam-bien involucran los canales existentes para la distribucion de un producto oservicio y algunas colaboraciones de servicios de aplicacion que los soporten.

3.4. HISTORIAS DE USUARIO 49

En cuanto a los sistemas de informacion, Archimate permite modelar losdiferentes artefactos de software y los servicios que estos prestan, ası comolas relaciones con otros subsistemas y la relacion que tienen con la capade negocio. Por ultimo la perspectiva tecnologica ofrece la relacion de losartefactos de software con la infraestructura que se requiere para soportarestos artefactos. De igual manera ofrece una vista panoramica a los proto-colos de comunicacion que existen y los canales necesarios para el flujo deinformacion y comunicaciones.[16]

3.4. Historias de usuario

El modelamiento de la arquitectura empresarial sin duda ofrece una de-finicion de procesos y herramientas que evitan la ambiguedad que puedeexistir cuando se levantan requerimientos y estos se hacen explıcitos de ma-nera textual, dando lugar a diferentes interpretaciones y por ende a posiblesdificultades a medida que un proyecto avanza. Sin embargo, la existencia delmodelado de arquitectura empresarial y la adaptacion de marcos de trabajocomo ADM permiten la integracion de otras tecnicas en el desarrollo itera-tivo de la arquitectura. Por lo tanto, se realizo la adaptacion de historias deusuario para tener una vision complementaria de los requerimientos de unusuario para la adquisicion de tiquetes aereos.

Estas historias de usuario estan definidas de cara a la oportunidad que re-quiere el usuario a la hora de seleccionar y adquirir un tiquete aereo, permi-tiendo que el sistema sea usable y que para las agencias sea transparente laintegracion y sincronizacion de la informacion.


Figura 3.2: Historia de usuario - busqueda de tiquetes

En este caso se evidencia que el usuario requiere de un sistema integradoque relacione la informacion de agencias, aerolıneas y los productos que estasofrecen, para que de manera facil y rapida se pueda hacer la adquisicion deacuerdo a sus necesidades, en este caso el origen y destino de vuelo.

Figura 3.3: Historia de usuario - listado de tiquetes

Dado a que diferentes aerolıneas y agencias pueden ofertar productoscon las mismas caracterısticas, el usuario requiere que el portal cuente conun listado de tiquetes segun los filtros establecidos, mostrando la oferta y la

3.4. HISTORIAS DE USUARIO 51

variedad de productos que pueden seleccionarse.

Figura 3.4: Historia de usuario - facturacion

En el caso de las agencias, se requiere un portal mediante el cual seregistre la informacion de las compras realizadas por un usuario, indicandosu valor y las caracterısticas generales del producto.


Capıtulo 4

Negocio

4.1. Introduccion

El modelado del negocio permite tener un panorama general del funcio-namiento de la operacion y del dominio del sistema. En el dominio de lasagencias de viaje se puede observar la colaboracion entre aerolıneas quie-nes ofrecen servicios de transporte de acuerdo a su flota aerea, las agenciasquienes promocionan planes y paquetes, los clientes quienes adquieren losproductos de acuerdo a su necesidad y el proceso de facturacion que se ge-nera en el proceso.

Los diagramas de negocio buscan modelar de manera entendible el esta-do actual del dominio, la participacion de los implicados, las operacionesque estos realizan y las localizaciones de algunos artefactos que permiten elflujo de la operacion.

53

54 CAPITULO 4. NEGOCIO

4.2. Organizacion

El modelo de organizacion pretende mostrar la estructura organizacionalde la empresa, identificando los actores y dependencias que existen en ella,ası como las responsabilidades de los actores implicados.

4.2.1. Modelo

Figura 4.1: Organizacion[9]

El punto de vista de organizacion permite relacionar los roles con elentorno en donde se presentan los servicios. Ası mismo las responsabilidadesde cada actor implicado y sus competencias.

4.2.2. Caso

Figura 4.2: Caso Organizacion

Para el caso analizado, se evidencia la existencia de los clientes, asesoresy aerolıneas interactuando en la agencia, todos sobre un departamento de

4.3. COOPERACION DE ACTOR 55

ventas en donde se efectua el proceso. A su vez, este proceso de ventas seda a partir de un portal web en donde el usuario consulta los productos yservicios de la companıa.

4.3. Cooperacion de Actor

Las colaboraciones de los actores y estos a su vez ejerciendo un rol es-pecıfico dentro del dominio del sistema, permite analizar la manera en que secomunican las operaciones con los artefactos de software para la prestaciondel servicio.

4.3.1. Modelo

Figura 4.3: Metamodelo cooperacion de actor[9]

Este punto de vista permite ver la relacion de los actores con su en-torno. Este entorno pueden ser otros actores o roles o servicios de aplicacionimplıcitos en la operacion.


4.3.2. Caso

Figura 4.4: Caso cooperacion de actor

En el caso de las agencias de viaje se evidencia la existencia del portalweb, que permite una comunicacion inicial entre el cliente y el asesor. Asımismo, el proceso de aseorıa puede darse a traves de correo electronicoo contacto telefonico. Este portal web involucra los productos y serviciosprestados por la agencia y representados como tiquetes aereos segun su flotade transporte.

4.4. Funcion de Negocio

Este modelo pretende mostrar el flujo de negocio mas especıfico por actoro rol segun corresponda. A su vez, permite ver las acciones que emergen encada rol para la facturacion de los tiquetes aereos.

4.4.1. Modelo

Figura 4.5: Metamodelo funcion de negocio[9]

4.5. PROCESO DE NEGOCIO 57

El punto de vista de funcion de negocio ofrece una mirada especıfica a lasfunciones de la organizacion y los roles que la desempenan. En este apartadose analizan las funciones mas importantes en el flujo de la operacion.

4.4.2. Caso

Figura 4.6: Caso funcion de negocio

El inicio de la operacion esta marcada por la busqueda y seleccion detiquetes aereos por parte de un cliente de acuerdo a su necesidad. La asesorıase da cuando el cliente realiza una cotizacion sobre algun tiquete de vuelo.Tras existir la confirmacion de la compra se realiza el proceso de facturacion.Estos procesos corresponden a funciones especıficas en la operacion por partede los actores implicados.

4.5. Proceso de Negocio

Muestra las entradas procesos y salidas de la operacion sumadas a lasactividades a realizar en cada una de ellas con el fin de evidenciar el serviciode la organizacion.


4.5.1. Modelo

Figura 4.7: Metamodelo proceso de negocio[9]

El punto de vista de proceso de negocio permite ver los procesos invo-lucrados a los servicios que se prestan en el mercado, ası como la respon-sabilidad de los actores con dichos procesos y el flujo de informacion denegocio.

4.5.2. Caso

Figura 4.8: Caso proceso de negocio

4.6. COOPERACION DE PROCESO DE NEGOCIO 59

El proceso de negocio inicial es la seleccion del tiquete, y este a su veztiene el servicio de recepcion de la solicitud por parte de la agencia para larespectiva asesorıa. Cuando el cliente confirma la compra se da el procesode facturacion, el cual asocia el servicio de venta de los tiquetes aereos alos usuarios. Finalmente se muestra como con estos servicios y procesos secumple el servicio principal de las agencias de viaje: la venta de tiquetesaereos.

4.6. Cooperacion de Proceso de Negocio

Este punto de vista permite tener una vision general de los roles ejerci-dos en el proceso de negocio de la operacion. Aquı se evidencian los serviciosinteractuando conjuntamente con los roles en un marco que permite la pres-tacion de los mismos.

4.6.1. Modelo

Figura 4.9: Metamodelo cooperacion de proceso de negocio[9]

El punto de vista de cooperacion de proceso de negocio permite esta-blecer las relaciones entre procesos y servicios en un alto nivel. Tambienpermite hacer un mapeo de los procesos comerciales de la companıa y larealizacion de servicios por procesos de negocio.


4.6.2. Caso

Figura 4.10: Caso cooperacion de proceso de negocio

En el caso de la venta de tiquetes, existe el proceso de facturacion, elcual, como se ha visto en modelos anteriores tiene subprocesos asociados. Esen esta fase en donde se establece asesorıa por parte de la agencia, a travesde la consulta de productos en el portal web.

4.7. Producto

El punto de vista de producto pretende mostrar la materializacion de unservicio a traves de un artefacto que permita la prestacion del mismo.

4.7. PRODUCTO 61

4.7.1. Modelo

Figura 4.11: Metamodelo de producto[9]

El punto de vista de producto esta enfocado principalmente en el valorque este ofrece a los clientes. No obstante, este punto de vista tambienrefleja los acuerdos o contratos que interfieren en los procesos de negocio dela organizacion, de modo que se analicen posibles mejoras en los serviciospara la mejora del producto o los servicios necesarios a ser creados.


4.7.2. Caso

Figura 4.12: Caso de producto

Dado a que TicketChain es una plataforma prototipo, el valor dado alcliente y agencias es el flujo de la operacion, centralizado en la comprade tiquetes aereos. Este flujo involucra otros procesos evidenciados en lospuntos de vista de aplicacion, en donde el valor dado a las agencias tambiense da al sincronizar de manera segura y escalable la informacion de la reddistribuida.

Capıtulo 5

Aplicacion

5.1. Introduccion

Archimate ofrece una capa orientada a modelar los artefactos y sus inter-acciones para la realizacion de un servicio. Ası mismo modela su estructura,sus componentes y muestra como estos permiten la realizacion de los servi-cios de negocio.

En el caso del dominio que se esta trabajando, existen 4 componentes ejepara la facturacion de tiquetes. Estos son la gestion de clientes, la gestionde tiquetes, la facturacion y el componente de Blockchain, el cual permitela sincronizacion de la base distribuida en donde cada nodo de la mismacorresponde a las agencias que forman parte del dominio del sistema.

63

64 CAPITULO 5. APLICACION

5.2. Comportamiento de Aplicacion

La aplicacion a realizar denominada TiquetChain, interactua con loscomponentes ejes para realizar la facturacion de un tiquete adquirido porun cliente. Toda la informacion sincronizada para cada agencia permite tenerde manera distribuida el respaldo de la misma, y la seguridad en cada unade las transacciones que se realizan.

5.2.1. Modelo

Figura 5.1: Metamodelo comportamiento de aplicacion[9]

El punto de vista de comportamiento de aplicacion muestra las interac-ciones a nivel interno de los artefactos de software, y como estos resuelvenun servicio de aplicacion. Tambien permite establecer los enlaces y relacio-nes entre diferentes tecnologıas, ası como su responsabilidad en el flujo dela operacion.

5.3. ESTRUCTURA DE APLICACION 65

5.2.2. Caso

Figura 5.2: Comportamiento de aplicacion

5.3. Estructura de Aplicacion

TiquetChain hace uso de los componentes manejando una capa abstractay el uso de interfaces para la comunicacion. Estas interfaces permiten vercomo se compone la aplicacion teniendo en cuenta la gestion de tiquetes,clientes, facturas y sincronizacion de los nodos que forman parte de la basede datos distribuida.


5.3.1. Modelo

Figura 5.3: Metamodelo estructura de aplicacion[9]

La estructura de la aplicacion muestra la manera en que se comunicanlos componentes de software. Este punto de vista se da de manera general enlos componentes principales de la aplicacion con el fin de tenerlos en cuentaen el despliegue y migracion de dichos artefactos, ası como sus dependenciasy jerarquıas.

5.3.2. Caso

Figura 5.4: Estructura de aplicacion

El punto de vista de estructura de aplicacion para el caso de las agenciasse basa en el portal web que funcionara como prototipo de aplicacion para

5.4. COOPERACION DE APLICACION 67

la realizacion de transacciones, compra de tiquetes, registro de clientes, etc.En este caso, el portal esta compuesto por un componente de presentacionque se comunica a los microservicios y estos a su vez al API de Blockchain.La comunicacion entre el web API y Blockchain se da a traves de entidadesdefinidas en el sistema, tales como clientes, destinos, aerolıneas, agencias,tiquetes y facturas.

5.4. Cooperacion de Aplicacion

Debido a que el componente de Blockchain funciona como un artefactoexterno dentro de la arquitectura, se modela la cooperacion de la aplicacionde manera tal que se vean los componentes estrechamente ligados al dominioy posteriormente su sincronizacion en el backOffice.

5.4.1. Modelo

Figura 5.5: Metamodelo cooperacion de aplicacion[9]

El punto de vista de cooperacion de aplicacion permite ver el flujo deinformacion que se da entre artefactos o aplicaciones de software. Ası mismo,permite establecer las colaboraciones de dichos componentes a la prestacionde servicios comerciales.


5.4.2. Caso

Figura 5.6: Cooperacion de aplicacion

En el caso del prototipo TicketChain se muestran las 3 capas principalesde la aplicacion. El frontend o capa de presentacion, el web API y el APIBlockchain. La capa de presentacion y web Api se conectan a traves demicroservicios, y con la capa de Blockchain existe una comunicacion a travesde interfaces comunes, que representan los objetos de datos asociados a lalogica de negocio: agencias, aerolıneas, clientes, destinos, tiquetes y facturas.

5.5. Uso de Aplicacion

Los artefactos de software que han sido mencionados a lo largo del capıtu-lo, pueden verse interactuando con las funciones de aplicacion para las cualesque fueron creados.

5.5. USO DE APLICACION 69

5.5.1. Modelo

Figura 5.7: Metamodelo uso de aplicacion[9]

Este punto de vista permite relacionar el uso que se le da a las aplicacio-nes para soportar los servicios o procesos de negocio. Por tanto, se puedenidentificar dependencias de los artefactos de software para el flujo normalde la operacion.


5.5.2. Caso

Figura 5.8: Uso de aplicacion

En el caso de TicketChain, la cual no es una aplicacion monolıtica yesta basada en la incorporacion de servicios descentralizados, cada uno delos componentes que conforman la aplicacion generan dependencia para laprestacion del servicio eje del negocio, es decir la venta de tiquetes aereos. Lacapa de presentacion como servicio de aplicacion y los servicios de factura-cion requieren de disponibilidad para que la operacion funciones de maneranormalizada. Aunque existe un tercer componente que es el de Blockchain,este no genera necesariamente una dependencia, pues precisamente al seruna red distribuida, al existir concenso entre los nodos de dicha red la in-formacion podra ser sincronizada en cada agencia.

Capıtulo 6

Tecnologıa

6.1. Introduccion

Los puntos de vista que hacen parte de la tecnologıa, permiten aso-ciar los artefactos de software con la infraestructura fısica utilizada parasu despliegue. Ası mismo, pretende mostrar la arquitectura de la aplicacionconsolidada en terminos de software y hardware.

El uso de tecnologıa muestra como a traves de los artefactos, APIs y micro-servicios se presta el servicio eje del negocio, para este caso la facturacionde los tiquetes aereos. De la misma manera, muestra como se sincroniza lared distribuida en cada uno de los nodos y los artefactos utilizados en cadauno para el funcionamiento de la aplicacion.

71

72 CAPITULO 6. TECNOLOGIA

6.2. Implementacion y Despliegue de Aplicacion

Se detallan los componentes de hardware en los que las aplicaciones fun-cionan, mostrando la infraestructura fısica, sus protocolos de comunicaciony los sistemas operativos o servidores web implementados. Del mismo modo,muestra como la capa de presentacion se comunica con las APIs y como atraves de Blockchain se sincronizan los nodos dentro de la red distribuida.

6.2.1. Modelo

Figura 6.1: Metamodelo implementacion y despliegue de aplicacion[9]

El punto de vista de implementacion y despliegue se basa en la identifica-cion de riesgos y dependencias entre artefactos y componentes de software.Adicionalmente, permite mostrar la estructura de las aplicaciones, su comu-nicacion con el entorno y la infraestructura que las soporta.

6.3. TECNOLOGIA 73

6.2.2. Caso

Figura 6.2: Implementacion y despliegue de aplicacion

En el caso de TicketChain existe un servidor de aplicaciones donde sedispone del sitio web, el cual se conecta con los microservicios y estos asu vez con el servidor Node quien consume el API Blockchain. Cada unode estos componentes son necesarios para el despliegue de la operacion deventas de tiquetes aereos.

6.3. Tecnologıa

En el caso de la aplicacion TiquetChain, existe un aplicativo web quepermite la interaccion con los componentes de negocio y estos a su vez con elcomponente Blockchain. En este modelo se ve los protocolos de comunicacionası como las tecnologıas usadas en cada capa.


6.3.1. Modelo

Figura 6.3: Modelo Tecnologıa[9]

En este modelo vemos como es la interaccion de cada uno de los compo-nentes que soportan la capa de aplicacion, ası como cada uno de los elementosde software y hardware que la componen como lo pueden ser dispositivosfısicos, redes, sistemas operativos y demas.

6.3. TECNOLOGIA 75

6.3.2. Caso

Figura 6.4: Caso Tecnologıa

Dentro del proyecto se tiene una distribucion de componentes de hard-ware y software en 3 capas divididas en aplicacion, negocio y persistencia,donde podemos ver cada uno de los elementos que la componen:

Capa aplicacion: Componente de la arquitectura donde se presenta deforma visual los procesos del negocio, realiza las peticiones a la ca-pa del negocio y se renderizan los resultados obtenidos, esta capa seencuentra desarrollada sobre javascript y html, y realiza peticiones alservidor de la capa del negocio por protocolo TCP/IP, de acuerdo acada uno de los nodos pertenecientes a la red de blockchain.

Esta capa se encuentra bajo un servidor de aplicaciones IIS, y se en-cuentra desarrollado con el patron MVC.

Capa negocio: Capa encargada de la logica del negocio de la aplica-cion, donde se procesan las solicitudes y se redireccionan a los nodosde blockchain de la aplicacion, esta se encuentra desarrollada sobre.Net Core y se conecta por protocolo HTTP a los diversos nodos queintegran la red de persistencia la cual se encuentra bajo tecnologıablockchain.


Capa de persistencia: Componte de la arquitectura encargada de lapersistencia y el acceso a datos a traves de la tecnologıa blockchain,las peticiones llegan a traves de la capa del negocio y son procesadaspor la capa de datos por microservicios los cuales envıan la transacciona la red blockchain para posteriormente ser persistidas en la base dedatos NoSQL.

Esta capa se compone de microservicios desarrollados bajo NodeJS,los cuales reciben el request de la solicitud para ser enviado a la redblockchain, y adicional procesar la transaccion en la base de datostransaccional la cual se encuentra bajo MongoDB.

Cada uno de los nodos de la red de persistencia cuenta con micro-servicios para el manejo de las solicitudes, base de datos NoSQL parael procesamiento de las transacciones de cada una de los envıos y fi-nalmente el envio hacia la red blockchain, donde se enviara cada unade las transacciones enviadas hacia el sistema.

6.4. Uso de Tecnologıa

Los componentes previamente mencionados forman parte de un artefactopara la gestion de tiquetes aereos, ası como una funcion conjunta de laaplicacion.

6.4. USO DE TECNOLOGIA 77

6.4.1. Modelo

Figura 6.5: Metamodelo uso de tecnologıa[9]

Este punto de vista ofrece una mirada a los requerimientos de rendimien-to y calidad de las aplicaciones segun la infraestructura requerida para quelas aplicaciones y componentes funcionen optimamente.


6.4.2. Caso

Figura 6.6: Uso de tecnologıa

TicketChain trabaja con 3 componentes principales de los cuales se hahablado en anteriores puntos de vista: Presentacion, web API y API Block-chain. Estos a su vez ofrecen los servicios de aplicacion para cada entidadcomo tiquetes, clientes y facturas. En el caso de Blockchain su responsabili-dad a nivel de servicio es la sincronizacion de nodos de la red distribuida.

6.5. Estructura de informacion

Este modelo permite ver como se relacionan los datos dentro del dominiode negocio. Sus dependencias y el flujo de la informacion entre las entidades.

6.5. ESTRUCTURA DE INFORMACION 79

6.5.1. Modelo

Figura 6.7: Modelo Estructura de informacion[9]

Dentro de este modelo se muestra la estructura de la informacion utiliza-da en la empresa. Tambien puede mostrar como se representa la informaciona nivel empresarial en el nivel de aplicacion en forma de las estructuras dedatos utilizadas allı, y como se asignan a la infraestructura tecnologica sub-yacente.


6.5.2. Caso

Figura 6.8: Caso Estructura de informacion

Dentro del caso se encuentra como la informacion puede ser representadaa nivel de tipos de entidades, la cual puede ser interpretada en la informa-cion empresarial mas relevante que maneja la empresa, es por esto que aquıvemos como es la relacion en cada una de los objetos o tipos de datos quela componen, logrando ver su uso dentro del negocio.

Visualizamos como tenemos una entidad principal cliente, la cual posee asu vez una composicion por la entidad facturas, y esta una composicion portiquete, las cuales son entidades determinantes para el negocio del caso deestudio abordado, pues son estructuras que demuestran el proposito del usoempresarial de la informacion en la organizacion.

6.6. REALIZACION DEL SERVICIO 81

6.6. Realizacion del Servicio

Muestra a nivel de negocio, como se presta el servicio eje dentro deldominio de los tiquetes aereos. Partiendo de la creacion de un portafoliode tiquetes segun la flota aerea, la asesorıa a un cliente y el proceso defacturacion.

6.6.1. Modelo

Figura 6.9: Modelo realizacion del servicio[9]

Este punto de vista muestra la realizacion de un servicio a traves de losprocesos asociados e incluso de los artefactos de aplicacion. En este puntose conectan los procesos de negocio con los productos de la organizacion.


6.6.2. Caso

Figura 6.10: Realizacion del servicio

Como producto las agencias de viaje ofrecen de acuerdo a la flota delas aerolıneas, opciones a los usuarios que cumplan con sus requerimientos.Como proceso existe la facturacion de los tiquetes y el acompanamiento queexiste por parte de las agencias en el proceso de compra.

6.7. Capas

Permite relacionar los la infraestructura fısica con los artefactos de soft-ware y la prestacion de servicios de negocio. En este caso, se evidencia laconfiguracion de servidores, los APIs expuestos para las funciones de negocioy sincronizacion y el servicio eje de toda agencia: la facturacion de tiquetes.

6.7. CAPAS 83

6.7.1. Modelo

Figura 6.11: Metamodelo de capas[9]


El punto de vista de capas permite tener una vision panoramica de laarquitectura empresarial propuesta. Muestra los artefactos de infraestructu-ra existentes y su conexion con las aplicaciones o componentes de software,posteriormente muestra como estos artefactos interactuan en la procesos denegocio y realizacion de servicios.

6.7.2. Caso

Figura 6.12: Capas

En el caso de la arquitectura propuesta, los servidores de aplicacionque soportan los componentes de software tienen asociacion con los flujos denegocio de la organizacion. Es decir que la operacion esta ligada directamentea los artefactos y servicios de aplicacion, por tanto existe dependencia de lacapa de negocio, los servicios y artefactos de software.

Capıtulo 7

Migracion

7.1. Introduccion

Los puntos de vista de migracion permiten la gestion de cambios de laaplicacion. En este caso se hacen explıcitas las etapas tenidas en cuenta paraabordar el proyecto, ası como los actores participantes en cada una de ellas.Tambien se muestran las etapas mediante las cuales se puede pasar de unaarquitectura a otra, en el caso en que los artefactos cambien o se migrenpara optimizar o mejorar funcionalidades.

La parte mas importante de estos puntos de vista se encuentra en la rela-cion de componentes y su funcion dentro de la arquitectura implementada,ya que permiten dar un alcance a dichos artefactos dentro del dominio delnegocio, en este caso la facturacion de los tiquetes aereos y la sincronizacionde cada uno de sus nodos (agencias).

85

86 CAPITULO 7. MIGRACION

7.2. Proyecto

Debido a que la aplicacion implementada corresponde a un prototipo desoftware y sus funcionalidades ası como su alcance son faciles de abordar, seimplemento un enfoque clasico en donde se analizaron los requerimientos, sediseno la solucion a cada uno de ellos, se desarrollo y desplego sus conjuntosde pruebas y finalmente se realizo el despliegue de la funcionalidad.

7.2.1. Modelo

Figura 7.1: Modelo Proyecto[9]

En el modelo se encuentra como se interpretan los pasos necesarios almomento de querer llegar a una arquitectura deseada, evidenciando roles yobjetivo deseado, la cual es relevante al momento de querer identificar unproceso definido dentro de la meta a alcanzar.

7.2.2. Caso

Figura 7.2: Caso Proyecto

7.3. MIGRACION 87

Debido a que en el proyecto se desea una nueva arquitectura en base aun producto ya implementado, se identifican los procesos mas importantesa implementar para lograr el resultado esperado de poder contar con unsistema transaccional que utilice tecnologıa blockchain, es por esto que seidentifican los procesos principales de diseno, los cuales serian ejecutadospor los desarrolladores, que serian premisas necesarias para cumplir con lameta propuesta.

7.3. Migracion

La migracion permite dar un alcance a los artefactos de software desarro-llados para gestionar los cambios que puedan darse dentro de la arquitectura.Por lo tanto se realiza una division de los componentes de negocio y los com-ponentes Blockchain, de modo que ambos se migren para formar las mejorasen la aplicacion distribuida.

7.3.1. Modelo

Figura 7.3: Modelo Migracion[9]

El modelo define los conceptos y modelos que se pueden usar desdeuna arquitectura deseada. Los cuales son importantes al querer alcanzar undiseno de una nueva arquitectura planteada.


7.3.2. Caso

Figura 7.4: Caso Migracion

De acuerdo al objetivo planteado, se identifican los siguientes conceptosque deben ser necesarios para llegar a la arquitectura deseada:

Baseline: Son todos los parametros iniciales que deben ser establecidosdesde un inicio en el proyecto, donde se definen todas las pautas y pasosa dar en el progreso del mismo.

Capa aplicacion: Contempla el diseno y ejecucion de la capa de apli-cacion y negocio del proyecto, la cual debe ser tenida en cuenta almomento de desarrollar el nuevo sistema.

Capa blockchain: Contempla todas las caracterısticas y requerimientosa tener en cuenta para desarrollar una capa de datos que implementetecnologıa blockchain.

Aplicacion distribuida: Es el objetivo final del proyecto y de la mi-gracion de la arquitectura, donde se plantea generar una aplicaciondistribuida a traves de tecnologıa blockchain.

7.4. Implementacion

Permite mostrar los recursos fısicos para el despliegue de la aplicacion,ası como la comunicacion entre componentes del software.

7.4. IMPLEMENTACION 89

7.4.1. Modelo

Figura 7.5: Modelo Implementacion[9]

El modelo identifica las aplicaciones y la relacion frente a los componen-tes fısicos que estos tienen, lo cual juega un rol importante al momento derealizar un analisis de rendimiento y escalabilidad entre la infraestructurafısica y la parte logica.

7.4.2. Caso

Figura 7.6: Caso Implementacion


Dentro del caso se evidencia una infraestructura fısica compuesta por dosnodos donde se encuentran alojados nuestro componente rest y la aplicacionweb, y n nodos de datos de acuerdo a la composicion de la red blockchain,adicional se encuentra conexion por LAN para nuestra capa de presentaciony negocio y WAN para nuestra persistencia dentro de la red blockchain.

Capıtulo 8

Motivacion

8.1. Introduccion

Los aspectos motivacionales dentro de una arquitectura empresarial per-miten gestionar las causas por las que se pretende abordar el proyecto. Portanto, se hace un control de las partes interesadas, los riesgos, oportunida-des, fortalezas y amenazas dentro del contexto abordado. Ası mismo, permitegestionar los objetivos iniciales y de requerimientos conforme a las metas es-tablecidas.

Los objetivos en el marco de la motivacion tambien suelen estar asociados alos componentes de software o aplicaciones, procesos, servicios y principiosdefinidos en el proyecto.

91

92 CAPITULO 8. MOTIVACION

8.2. Implicados

Contiene de manera explıcita la relacion de las partes interesadas o Sta-keholders y su participacion a traves de los objetivos dentro del proyecto.

8.2.1. Modelo

Figura 8.1: Metamodelo de implicados[9]

En este punto de vista se analizan los implicados en la organizacion y susprocesos. Ası mismo se pone en evidencia los impulsores de los cambios anivel interno y externo, analizando las fortalezas, oportunidades, debilidadesy amenazas existentes. Este punto de vista tambien puede relacionarse conlos objetivos trazados por la organizacion.

8.3. REALIZACION DE OBJETIVOS 93

8.2.2. Caso

Figura 8.2: Implicados

TicketChain es un prototipo de aplicacion en donde se relacionan lostiquetes de diferentes agencias y aerolıneas de acuerdo a la oferta de susproductos. Por tanto estos dos actores interactuan en el proceso y son im-plicados directamente en el flujo de la operacion. Ası mismo, los clientesquienes adquieren estos productos forman parte del negocio. Cada uno deestos actores tiene objetivos especıficos, en el caso de los clientes su objetivoprincipal es la compra de tiquetes aereos que cumplan sus requerimientos.En el caso de las agencias y aerolıneas, su objetivo es la venta de los ti-quetes atacando posibles problematicas que se pueden presentar, tales comoinseguridad de las transacciones y fallos del sistema.

8.3. Realizacion de Objetivos

Permite abordar objetivos generales a traves de objetivos con alcancesmas definidos y especıficos y su relacion con las acciones para llevarlos acabo.


8.3.1. Modelo

Figura 8.3: Modelo Realizacion de objetivos[9]

En el modelo permite identificar como a traves de objetivos mas concre-tos o requerimientos se puede alcanzar un objetivo final, esto para identifi-car plenamente las necesidades y requisitos que pueden estar presentes enla consecucion de una meta final.

8.3.2. Caso

Figura 8.4: Caso Realizacion de objetivos

8.4. CONTRIBUCION DE OBJETIVOS 95

Dentro del caso se identifican algunos objetivos especıficos y requeri-mientos necesarios para alcanzar el objetivo final, tal como lo vemos en eldiagrama, pues para poder alcanzar la meta a nivel del negocio, es necesarioprimero abordar temas como los son la implementacion de la red blockchainen nuestro sistema, implicando posteriormente una revision de objetivos masespecıficos a nivel de seguridad, tolerancia a fallos y escalabilidad, lo cualcontribuye para una reduccion de gastos para el sistema.

8.4. Contribucion de Objetivos

Muestra como aquellos objetivos o principios especıficos contribuyen ala realizacion del servicio u objetivo eje del proyecto o aplicacion.

8.4.1. Modelo

Figura 8.5: Metamodelo contribucion de objetivos[9]

Este punto de vista permite relacionar los objetivos con los requisitosimplıcitos para su cumplimiento. De esta manera se establece el aporte deun requerimiento para llevar a cabo la realizacion del objetivo.


8.4.2. Caso

Figura 8.6: Contribucion de objetivos

Para el caso de estudio se muestra como la red Blockchain reduce elcontacto con el cliente, ya que la existencia del portal centralizado permiteque el usuario de manera segura realice las transacciones para la comprade los tiquetes aereos. Ası mismo, ofrece una alternativa para la mejora dela sincronıa de las agencias que convergen en la red distribuida. Al final,estos beneficios otorgados por la implementacion de Blockchain se traducenen reduccion de costos al minimizar los fallos de seguridad, aumentar laescalabilidad de la red y aportar en la seguridad del sistema.

8.5. Principios

Establece aquellos objetivos clave que deben ser abordados para generarun servicio o producto mejor.

8.5. PRINCIPIOS 97

8.5.1. Modelo

Figura 8.7: Modelo Principios[9]

El modelo permite identificar los principios que se deben tener en cuentaal momento de disenar la solucion de un problema, ademas permiten identi-ficar la relacion de esos principios con los objetivos que se estan abarcando.

8.5.2. Caso

Figura 8.8: Caso Principios


Se permite identificar algunos principios necesarios para llegar a los ob-jetivos del diseno de la arquitectura, donde se recalca que con la implemen-tacion de la tecnologıa blockchain obtenemos principios de gran relevanciacuando se habla de el mejoramiento de la confianza de un cliente o de lamisma reduccion de costos de un sistema.

Esto gracias a que tenemos el beneficio de abordar caracterısticas muy im-portantes cuando se habla del tratamiento de informacion sobre sistemastransaccionales, puntos muy importantes que se pueden ver como principiosnecesarios al momento de llegar a la meta propuesta.

8.6. Realizacion de Requerimientos

Gestiona las actividades o artefactos a desarrollar para cumplir con losobjetivos trazados dentro del proyecto.

8.6.1. Modelo

Figura 8.9: Metamodelo realizacion de requerimientos[9]

Este punto de vista permite establecer la gestion de requerimientos yrestricciones asociadas al objetivo. Estos requerimientos pueden ser de dife-rentes tipos, bien sea requerimientos de aplicacion, servicios de aplicacion,procesos de negocio, etc.

8.7. MOTIVACION 99

8.6.2. Caso

Figura 8.10: Realizacion de requerimientos

En el caso de estudio que se esta abordando, se plantean los requeri-mientos basados en la implementacion del prototipo web, y la realizacionde sus componentes principales como requerimientos de software, con el finde enmarcarlos en el objetivo central de las agencias: la reduccion de costosde operacion a traves del aumento de seguridad, escalabilidad y toleranciaa fallos.

8.7. Motivacion

Muestra la relacion de partes interesadas, su impacto dentro del dominio,sus objetivos y los principales requerimientos de las aplicaciones, servicios uobjetos.


8.7.1. Modelo

Figura 8.11: Modelo Motivacion[9]

El modelo permite identificar la parte motivacional para presentar unvision general relacionando los principios, los objetivos y los requisitos prin-cipales que debe cumplir el sistema

8.7. MOTIVACION 101

8.7.2. Caso

Figura 8.12: Caso Motivacion

Se identifica dentro del caso los principios, objetivos y requisitos, juntocon el stakeholder principal del sistema, quien es el gerente de cada una delas agencias, lo cual permite tener una vision global del modelo a desarrollary un aspecto motivacional a trabajar.


Capıtulo 9

Protocolo Blockchain

9.1. Introduccion

Dentro del funcionamiento de una red blockchain, se tienen que imple-mentar ciertos conceptos que involucra la tecnologıa y que son esencialespara su funcionamiento, pues sin esto no seria posible gozar de los principa-les beneficios que esta posee, por tal motivo es necesario crear un protocolode comunicacion para la implementacion donde a traves de un mismo len-guaje se pueda hacer uso de sus conceptos.[17]

De esta forma se crean unos mensajes estandarizados dentro de la aplica-cion, los cuales se caracterizan por tener dentro de sus propiedades atributosque enriquecen el funcionamiento de la red y que permiten que esta puedafuncionar sin algun inconveniente, ademas de velar por el cumplimiento decada uno de los conceptos de la tecnologıa.

103

104 CAPITULO 9. PROTOCOLO BLOCKCHAIN

9.2. Diseno y especificacion

El diseno del protocolo a utilizar dentro de la arquitectura estara cons-truido bajo formato JSON, donde se incluiran todas las transacciones queintervienen en el sistema, la estructura del formato estara estructurada porla identificacion de los emisores de las transacciones, y los datos de la tran-saccion enviada por el sistema, la cual sera procesada por la red blockchainpara posteriormente persistirla en la base de datos. La estructura JSON delas transacciones tendran la siguiente definicion. [17]

Figura 9.1: Protocolo - Transaccion blockchain

Por otro lado, encontramos la estructura de los mensajes transmitidos atraves de la red blockchain los cuales poseen la siguiente estructura.

Figura 9.2: Protocolo - Bloque blockchain

9.2.1. Definicion de propiedades

Dentro de las propiedades de la transaccion tenemos las siguientes defi-niciones:

Dml: Operacion DML a ejecutar en el sistema transaccional de basede datos.

Sender: Cuenta de quien envıa la transaccion.

9.2. DISENO Y ESPECIFICACION 105

Collection: Coleccion de modelo de datos a afectar.

Transaction: Transaccion del objeto a procesar al momento de leer latransaccion desde la persistencia de datos.

Dentro de las propiedades de la estructura de datos del bloque blockchainestan:

Index: Indice del bloque a anadir en la cadena

Nonce: Dato reservado para alcanzar el nivel de dificultad definidopara generacion de los hash de los bloques.

PreviousHash: Hash previo del bloque anterior en la cadena.

Hash: Hash generado de acuerdo al bloque insertado en la cadena.

TimeSpan: Fecha en la cual se anadio el bloque.

Transactions: Transacciones almacenadas en cada uno de los bloquesque corresponden a la accion DML a ejecutar en el sistema transac-cional.

106 CAPITULO 9. PROTOCOLO BLOCKCHAIN

Capıtulo 10

Patrones

10.1. Introduccion

Teniendo en cuenta que los patrones de diseno ofrecen estrategias o solu-ciones previamente probadas a problemas frecuentes en el diseno del softwa-re, para el diseno de la prototipo han sido tenidos en cuenta algunos patronesde diseno. Estos patrones hacen parte de los patrones Gof (Gangs of four),y solucionan aspectos puntuales en cuanto a la instanciacion y estructurade la aplicacion.

Como se puede observar en los modelos de aplicacion, el prototipo se di-vide en tres tecnologıas. Por tanto los patrones empleados en el diseno dela solucion, estan enmarcados en dicha estructura, su comunicacion y surespectiva responsabilidad.

107

108 CAPITULO 10. PATRONES

10.2. Patrones creacionales

Los patrones de diseno creacionales ofrecen alternativas de instanciaciony comunicacion entre clases de tal modo que la responsabilidad de creacionde instancias sea delegada a otro objeto. En el caso del prototipo propuesto,se puede establecer patrones de tipo creacional a la hora de realizar transac-ciones en el API Blockchain el cual actua como eje central y luego replicadichas transacciones en los nodos de la red distribuida.

10.2.1. Singleton

El patron de diseno Singleton recibe su nombre debido a que solo sepuede tener una unica instancia para toda la aplicacion de una determinadaclase, esto se logra restringiendo la libre creacion de instancias de esta clasemediante el operador new e imponiendo un constructor privado y un metodoestatico para poder obtener la instancia.

La intencion de este patron es garantizar que solamente pueda existir unaunica instancia de una determinada clase y que exista una referencia globalen toda la aplicacion.[10]

Figura 10.1: Singleton [10]

Los componentes que conforman el patron son los siguientes:

Client: Componente que desea obtener una instancia de la clase Sin-gleton.

10.2. PATRONES CREACIONALES 109

Singleton: Clase que implementa el patron Singleton, de la cual uni-camente se podra tener una instancia durante toda la vida de la apli-cacion.

Figura 10.2: Singleton actividad[10]

1. El cliente solicita la instancia al Singleton mediante el metodo estaticogetInstance.

2. El Singleton validara si la instancia ya fue creada anteriormente, de nohaber sido creada entonces se crea una nueva.

3. Se regresa la instancia creada en el paso anterior o se regresa la instanciaexistente en otro caso[10].

Aplicacion

En la ejecucion y desarrollo del proyecto, el patron singleton fue utiliza-do para la gestion y generacion de la cadena de bloques. Este nos permitio


siempre tener una sola instancia de la cadena, lo cual nos garantizaba la nocreacion de demas objetos que pudieran alterar el funcionamiento del siste-ma.

Esto garantizo el metodo de creacion de los objetos desde la capa de persis-tencia, permitiendo una adecuada solucion al problema ya conocido.

Figura 10.3: Singleton aplicacion

10.3. PATRONES ESTRUCTURALES 111

10.3. Patrones estructurales

Los patrones estructurales representan la manera en que las clases y losobjetos estan compuestos a traves de la aplicacion. En este caso, en dondeexisten diferentes tecnologıas interactuando entre sı y que forman el paquetedel prototipo desarrollado, los patrones estructurales desempenan una im-portante labor en la comunicacion de estos subsistemas y las colaboracionesque allı se generan.

10.3.1. Proxy

El patron proxy tiene como objetivo proteger el acceso a un objeto uti-lizando un intermediario. A menudo este patron se presenta como una capaintermedia en la aplicacion para acceder o tratar un objeto determinado.

El patron proxy tiene diferentes variaciones de acuerdo al proposito parael que es empleado: proxy remoto, proxy virtual y proxy de proteccion.

Figura 10.4: Proxy[10]

Los componentes que conforman el patron son los siguientes:

IObject: Acciones que se emplearan para tratar el objeto.


Proxy: Objeto con propiedades y comportamientos a ser accesadas.

Object: Objeto delegado que se comunicara con servicio remoto y pro-tegera acceso al proxy.

Figura 10.5: Secuencia de patron Proxy[10]

1. Un cliente realiza una peticion a un objeto determinado.

2. Tras existir comunicacion entre los dos subsistemas, se realizan las ope-raciones definidas en el contrato.

3. El objeto Proxy realiza las operaciones involucrando al objeto protegidoy retorna un resultado a la aplicacion cliente.

Aplicacion

En el caso de la arquitectura del prototipo propuesto, el patron proxyes utilizado como capa intermedia entre el Api de Blockchain y el backend

10.3. PATRONES ESTRUCTURALES 113

de la aplicacion. En este caso, en el contrato son definidas dos operacionesbasicas: la obtencion de informacion y la transaccion de operaciones paraagregar, actualizar y eliminar informacion.

Figura 10.6: Modelo aplicado patron Proxy

En la arquitectura propuesta la interface creada es transversal a todas lasentidades del sistema. La figura muestra el patron proxy implementado parala entidad ”Ticket”. En este caso el proxy realiza las acciones de consultarinformacion y ejecutar transacciones de persistencia. Estas implementacio-nes se hacen en cada proxy, en este caso en la clase TicketProxy, la cual atraves del cliente RestSharp accede al API de Blockchain para ejecutar lasoperaciones CRUD correspondientes.


Figura 10.7: Codigo fuente patron proxy

Capıtulo 11

Prototipo de aplicacion:TicketChain

11.1. Introduccion

El prototipo de aplicacion corresponde a una plataforma web centra-lizada, la cual se encarga de realizar las transacciones entorno al servicioprestado por las agencias de viajes. Esta plataforma permite persistir lastransacciones Blockchain de manera que sea transparente el acceso a los da-tos y el tratamiento de los mismos, de modo que cualquier nodo de la redtenga la informacion actualizada de acuerdo a las operaciones realizadas porun usuario.

TickectChain es el nombre dado a dicha plataforma web y los modulosdel prototipo corresponden a la gestion de agencias, aerolıneas, destinos,clientes, tiquetes y facturas. La gestion de estos modulos corresponden aoperaciones de creacion, lectura, edicion y eliminacion, con su respectivapersistencia en la red de transacciones Blockchain y su reproduccion en ca-da nodo de la red distribuida.

115

116 CAPITULO 11. PROTOTIPO DE APLICACION: TICKETCHAIN

11.2. Aerolineas

Las aerolıneas corresponden a empresas prestadoras del servicio de trans-porte y flota aerea. Estas empresas prestan su servicio teniendo en cuentala flota disponible, por tal motivo se genera un modulo para realizar la pa-rametrizacion de dicha informacion como se muestra a continuacion.

11.2.1. Lectura

Consulta general de aerolıneas mostrando sus propiedades, codigo IATAy las acciones a realizar: Edicion, eliminacion y busqueda en tabla.

Figura 11.1: Lectura de aerolıneas

11.2.2. Creacion

Al pulsar la opcion para crear una aerolınea, se agrega un campo en latabla para diligenciar las propiedades correspondientes.

11.2. AEROLINEAS 117

Figura 11.2: Creacion de aerolınea

11.2.3. Edicion

Al pulsar la opcion para editar una aerolınea, se cargan sus propiedadespermitiendo su edicion y almacenamiento de cambios.

Figura 11.3: Edicion de aerolınea


11.2.4. Eliminacion

Como accion, todas los registros de la tabla permiten la edicion y elimi-nacion del registro.

Figura 11.4: Eliminacion de aerolınea

11.3. Agencias

Las agencias son empresas prestadoras del servicio de turismo. Estasempresas involucran planes en donde contemplan los tiquetes, hospedaje yalimentacion o diferentes combinaciones de sus productos. Con los productosque comercializan, las agencias involucran planes de tiquetes a diferentesdestinos lo cual en el aplicativo esta registrado como un tiquete de vuelo.

11.3.1. Lectura

Consulta general de agencias mostrando sus propiedades, codigo y ac-ciones a realizar: Edicion, eliminacion y busqueda en tabla.

11.3. AGENCIAS 119

Figura 11.5: Lectura de agencias

11.3.2. Creacion

Al pulsar la opcion para crear una agencia, se agrega un campo en latabla para diligenciar las propiedades correspondientes.

Figura 11.6: Creacion de agencias


11.3.3. Edicion

Al pulsar la opcion para editar una agencia, se cargan sus propiedadespermitiendo su edicion y almacenamiento de cambios.

Figura 11.7: Edicion de agencia

11.3.4. Eliminacion


11.4. DESTINOS 121

Figura 11.8: Eliminacion de agencia

11.4. Destinos

Los destinos son lugares a los cuales una aerolınea -de acuerdo a suflota de transporte- presta el servicio de transporte aereo. Estos destinosson transversales a los servicios de las aerolıneas.

11.4.1. Lectura

Consulta general de destinos mostrando sus propiedades, codigo y accio-nes a realizar: Edicion, eliminacion y busqueda en tabla.


Figura 11.9: Lectura de destinos

11.4.2. Creacion

Al pulsar la opcion para crear un destino, se agrega un campo en la tablapara diligenciar las propiedades correspondientes.

Figura 11.10: Creacion de destino

11.4. DESTINOS 123

11.4.3. Edicion

Al pulsar la opcion para editar un destino, se cargan sus propiedadespermitiendo su edicion y almacenamiento de cambios.

Figura 11.11: Edicion de destino

11.4.4. Eliminacion



Figura 11.12: Eliminacion de destino

11.5. Clientes

Los clientes son personas naturales o jurıdicas que realizan la comprade un tiquete aereo. Este tiquete ademas esta ligado a una aerolınea y unaagencia de viajes.

11.5.1. Lectura

Consulta general de clientes mostrando sus propiedades, codigo y accio-nes a realizar: Edicion, eliminacion y busqueda en tabla.

11.5. CLIENTES 125

Figura 11.13: Lectura de clientes

11.5.2. Creacion

Al pulsar la opcion para crear un cliente, se agrega un campo en la tablapara diligenciar las propiedades correspondientes.

Figura 11.14: Creacion de cliente


11.5.3. Edicion

Al pulsar la opcion para editar un cliente, se cargan sus propiedadespermitiendo su edicion y almacenamiento de cambios.

Figura 11.15: Edicion de cliente

11.5.4. Eliminacion


11.6. TIQUETES 127

Figura 11.16: Eliminacion de cliente

11.6. Tiquetes

Los tiquetes de vuelo son los servicios ofertados por una aerolınea segunsu flota de transporte. Estos tiquetes asocian un lugar de origen y un lugarde destino, ası como una fecha asociada de la prestacion del servicio.

11.6.1. Lectura

Consulta general de tiquetes mostrando sus propiedades, codigo y accio-nes a realizar: Edicion, eliminacion y busqueda en tabla.


Figura 11.17: Lectura de tiquetes

11.6.2. Creacion

Al pulsar la opcion para crear un tiquete, se agrega un campo en la tablapara diligenciar las propiedades correspondientes.

Figura 11.18: Creacion de tiquete

11.6. TIQUETES 129

11.6.3. Edicion

Al pulsar la opcion para editar un tiquete, se cargan sus propiedadespermitiendo su edicion y almacenamiento de cambios.

Figura 11.19: Edicion de tiquete

11.6.4. Eliminacion



Figura 11.20: Eliminacion de tiquete

11.7. Facturas

Las facturas corresponden a la compra de un servicio o tiquete por partede un cliente.

11.7.1. Lectura

Consulta general de facturas mostrando sus propiedades, codigo y accio-nes a realizar: Edicion, eliminacion y busqueda en tabla.

11.7. FACTURAS 131

Figura 11.21: Lectura de facturas

11.7.2. Creacion

Al pulsar la opcion para registrar una factura, se agrega un campo en latabla para diligenciar las propiedades correspondientes.

Figura 11.22: Registro de factura


11.7.3. Edicion

Al pulsar la opcion para editar una factura, se cargan sus propiedadespermitiendo su edicion y almacenamiento de cambios.

Figura 11.23: Edicion de factura

11.7.4. Eliminacion


11.7. FACTURAS 133

Figura 11.24: Eliminacion de factura


Parte III

Cierre

135

Capıtulo 12

Resultados y discusion

Como resultado de la investigacion y desarrollo del proyecto, se lograronobtener los siguientes prototipos:

Prototipo web: Aplicacion web basada en el caso de estudio de factura-cion de agencias de viaje, la cual realiza el consumo de microserviciosbasados en la tecnologıa blockchain. La aplicacion cuenta con dife-rentes modulos que permiten la creacion, modificacion, eliminacion yconsulta de las diferentes entidades que componen el negocio.

Componente servicio rest: Servicio rest que se encarga de realizar elconsumo entre la aplicacion web y los microservicios de la red block-chain.

Microservicios blockchain: Microservicios basados en la tecnologıa block-chain, que se encarga de realizar la persistencia de las transaccionesenviadas a partir de la aplicacion web.

Artefactos que comprueban el uso de sistemas transaccionales con tec-nologıa blockchain, obteniendo una notable mejora en la seguridad de lainformacion, tolerancia a fallos y escalabilidad del sistema.

Adicional la arquitectura propuesta es altamente escalable y flexible paraser adecuada a demas sistemas transaccionales.

A continuacion, se especifica de que forma es comprobada la hipotesis:

El uso de la tecnologıa blockchain aplicada a microservicios orientadosa sistemas transaccionales permiten brindar a la informacion una ca-racterıstica de inmutabilidad, lo cual permite que una vez ingresada la

137

138 CAPITULO 12. RESULTADOS Y DISCUSION

transaccion a un bloque de la cadena, no se pueda modificar de ningu-na forma, lo cual garantiza la seguridad de la informacion al momentode ser adicionada.

En la red blockchain se pueden aceptar los nodos que sean necesarios,lo cual permite que una vez ingresados este sea sincronizado, garanti-zando que toda la red se encuentre en el mismo estado que los demas.

Debido a que en la red se pueden ingresar los nodos que sean nece-sarios, permite mejorar la caracterıstica de escalabilidad, pues es unode los beneficios de la tecnologıa blockchain, y pueden ser aplicadosa sistemas transaccionales como se encuentra en el caso de estudiodesarrollado.

12.1. Seguridad

De acuerdo a los resultado presentados, podemos evidenciar como la se-guridad de la aplicacion es dada por lo beneficios de la implementacion deuna red blockchain, debido a que cada uno de los bloques y transaccionesson asegurados mediante hash, proporcionando una caracterıstica de inmu-tabilidad de la informacion, evitando que cualquier persona pueda alterarlos datos sobre la cadena, de esta forma garantizando la integridad de lainformacion frente a cualquier tipo de ataque.

12.1. SEGURIDAD 139

Figura 12.1: Hash Seguridad

Como podemos ver dentro de la imagen ”Hash Seguridad”, cada uno delos bloques se encuentra asegurado con un hash producto de la transacciona almacenar junto con una clave para hallar el nivel de dificultad de dos


dıgitos ”00.al inicio de cada hash, adicional se encuentra un hash por cadatransaccion el cual es producto de la transaccion junto al hash del bloqueanterior, proporcionando no solo un nivel de seguridad bloque que componecada cadena, sino que ademas nos brinda un aseguramiento por transaccionque se encuentre en cada cadena.

12.2. Escalabilidad

Dentro de las pruebas realizadas, se evidencia como la red soporta nnodos conectados al momento de persistir la informacion, permitiendo uncrecimiento que es equivalente al numero de nodos que compongan la red,brindando una escalabilidad importante, lo cual es un gran beneficio pa-ra el sistema cuando se habla de crecimiento, pues cualquier nodo puedepertenecer a la red sin ningun tipo de inconveniente.

Figura 12.2: Escalabilidad

Como lo vemos en la figura .Escalabilidad”donde tenemos tres nodostrabajando dentro del sistema y totalmente sincronizados, permitiendo uncrecimiento a nivel de recursos y distribuyendo la carga de la operacion,mejorando tiempos de respuesta para los usuarios que se encuentren conec-tados.

12.3. TOLERANCIA A FALLOS 141

12.3. Tolerancia a fallos

Dentro de los resultado presentados, vemos como se evidencia la toleran-cia a fallos del sistema gracias a los beneficios que brinda la red blockchain,donde sin importar el fallo o la caıda de un nodo, la red puede seguir funcio-nando sin ningun problema, esto es gracias a que al momento de entrar o devolver a incluir un nodo dentro de la red, se ejecuta un algoritmo de consen-so, donde los nodos vuelven a tomar el estado de los actuales, sincronizandolas operaciones faltantes y volviendo a retomar las actuales peticiones sinningun inconveniente.

Figura 12.3: Tolerancia a fallos

En la imagen ”Tolerancia a fallos.evidenciamos solo dos nodos los cualesse encuentran sincronizados con un numero determinado de transacciones,y tenemos un tercer nodo el cual se encuentra desconectado y sin perteneceraun a la red.


Figura 12.4: Bases de datos nodos

Como lo vemos en la figura ”Bases de datos nodos”, se encuentran per-sistidos las transacciones de los dos primeros nodos, pero en el tercero aunno existen datos debido a que aun no pertenece a la red.

Figura 12.5: Sincronizacion bases de datos nodos

Ya en la figura ”Sincronizacion bases de datos nodos.evidenciamos comoal momento de incluir una nueva transaccion, esta solo es distribuida sobre

12.3. TOLERANCIA A FALLOS 143

los nodos conectados en la red, en este caso, solo se sincroniza sobre los dosprimeros nodos, debido a que el tercero aun no se encuentra en linea.

Figura 12.6: Consenso nodos 1

Figura 12.7: Consenso nodos 2

Luego de que un nuevo nodo ingresa a la red como lo vemos en las image-nes Consenso 1 2Consenso 2”, se ejecuta un algoritmo de consenso, el cualpermite que los nodos adquieran el estado actual de los demas, permitiendode esta forma una sincronizacion en toda la red.


Figura 12.8: Consenso base de datos

Y al mismo tiempo como vemos en la imagen Consenso base de datos”seevidencia que al momento de que un nuevo nodo ingresa o vuelve a ingresar,este se actualiza de acuerdo a los demas nodos que ya se encuentran en lared, permitiendo que este nuevo haga parte de la red, y se sincronice frentea los demas que ya se encuentran en ella.

De acuerdo a esto podemos ver como la implementacion de la tecnologıablockchain brinda una alta resistencia frente a la tolerancia a fallos a la cualpuede verse afectado un sistema, donde la unica forma de apagar o afectarla red seria apagando todos los nodos que la conforman al mismo tiempo,afectando la cadena blockchain ya construida.

12.4. Pruebas funcionales

Las pruebas aplicadas al prototipo TicketChain se basan en el flujo dela aplicacion a partir de acciones CRUD (Create, Read, Update, Delete).Estas pruebas estan inmersas en un set que contempla los datos de entra-da, la duracion de la prueba y el resultado final, con el fin de valorar elfuncionamiento de la aplicacion en cada uno de sus modulos.

12.4. PRUEBAS FUNCIONALES 145

Figura 12.9: Pruebas funcionales ejecutadas

De acuerdo al set de pruebas ejecutado se evidencian los resultados sa-tisfactorios de las acciones CRUD realizadas y su persistencia en los nodosde la red distribuida Blockchain.

Figura 12.10: Total pruebasFigura 12.11: Total pruebas pormodulo


Capıtulo 13

Analisis de resultados

Teniendo en cuenta los set de pruebas ejecutados, tanto del funciona-miento de la aplicacion como de la sincronıa de los nodos de la red distri-buida, se evidencia que la arquitectura propuesta cumple con los objetivostrazados: ofrecer una alternativa para sistemas transaccionales distribuidoshaciendo uso de la tecnologıa Blockchain. Adicionalmente, estos set de prue-bas son realizados con el fin de contrastar el funcionamiento del prototipoweb y sus componentes. En cuanto a los lineamientos de calidad del soft-ware, se evaluan 3 aspectos centrales de la implementacion Blockchain: Laseguridad de la informacion, la escalabilidad y la tolerancia a fallos.

13.1. Seguridad

Dentro de las pruebas realizadas, se evidencia que la seguridad de lastransacciones es validada gracias a el aseguramiento de los nodos y de lastransacciones a traves de los hash, obtenidos a traves de la misma informa-cion persistida dentro de cada uno de los bloques.

Adicional se puede observar como a traves de la cadena de bloques la infor-macion llega a ser inmutable, es decir que despues de haber sido insertadaen el bloque esta no puede ser modificada ni alterada por nadie, pues parahacer esto se tendria que modificar todo los hash que componen la cadena.

13.2. Escalabilidad

En las pruebas evidenciadas, logramos ver como al anadir un nuevo no-do, la red aumenta su escalabilidad en tiempos de respuesta y tolerancia a

147

148 CAPITULO 13. ANALISIS DE RESULTADOS

problemas que se puedan presentar en el funcionamiento del sistema, estohace destacar una de las caracterısticas fundamentales que debe tener unaarquitectura y es la escalabilidad y flexibilidad que debe tener un sistema almomento de crecer.

13.3. Tolerancia a fallos

Dentro de los resultados obtenidos, evidenciamos como la tolerancia afallos al momento de implementar una red blockchain es muy alta, debidoa que no es indispensable que todos los nodos se encuentren en lınea en sufuncionamiento. Sin importar que los nodos puedan estar abajo teniendo encuenta que al menos solo un nodo puede estar en lınea para que la red entreen funcionamiento.

Por lo tanto, la tolerancia a fallos de una red blockchain es muy alta, cuandose habla de funcionamiento de sistemas transaccionales con un alto nivel dedisponibilidad debido a que la unica manera de que la red blockchain noeste en funcionamiento es cuando esta se encuentre con todos los nodos quela componen abajo.

Capıtulo 14

Recomendaciones

Al momento de disenar una solucion con tecnologıa blockchain, po-demos contemplar la idea de persistir la cadena dentro de la base dedatos, debido a que ası podemos liberar memoria en los nodos y me-jorar los tiempos de respuesta en los mismos.

Dentro de las soluciones que se disenen con tecnologıa blockchain,se debe contemplar el rendimiento y metodo de minerıa apropiadoal momento de realizar una distribucion de las transacciones que seenvıen dentro de la red, ya que esto puede ser un factor importanteen el funcionamiento del sistema, y puede determinar el exito de lamisma.

Al realizar el desarrollo de un API cuya responsabilidad es la persisten-cia de la informacion en cada nodo de la red distribuida Blockchain, sedebe buscar la manera en que esta sea adaptable a cualquier negocio,desacoplando sus componentes y permitiendo la integracion de otrossistemas de informacion.

149

150 CAPITULO 14. RECOMENDACIONES

Capıtulo 15

Conclusiones

15.1. Verificacion, contraste y evaluacion de losobjetivos

En el proyecto desarrollado se plantearon diversos objetivos necesariospara el cumplimiento de las metas propuestas donde:

De acuerdo al primer objetivo ”Disenar un prototipo web que permita utili-zar la arquitectura propuesta para demostrar su funcionamiento.”se cumpleen su totalidad, pues se evidencia como la red blockchain trabaja a partir delas peticiones del prototipo web y ejecuta su funcionamiento con normali-dad de acuerdo a las solicitudes de este, ademas cumple con las operacionesDML basicas necesarias para un sistema transaccional.

En el segundo objetivo ”Desarrollar microservicios implementando los con-ceptos de la tecnologıa blockchain para la comunicacion de sistemas transac-cionales con bases de datos distribuidas.”se verifica y prueba de acuerdo a loresultados obtenidos (Capitulo Resultados y discusion”), como a traves delos microservicios desarrollados los cuales implementan los conceptos de latecnologıa blockchain, se logra la comunicacion y sincronizacion de diversosnodos de un sistema transaccional que cuentan con bases de datos indepen-dientes pero que actuan como bases de datos distribuidas gracias a la redblockchain.

Por ultimo en el objetivo Crear una arquitectura alternativa para los siste-mas de informacion de las pequenas empresas.”se identifica y valida dentrodel desarrollo del proyecto que se puede contar con una nueva arquitectura

151

152 CAPITULO 15. CONCLUSIONES

para las pequenas empresas como es el caso de estudio de las agencias deviaje en la empresa amadeus, donde al no tener mas alternativas se recurrena sistemas transaccionales tradicionales, no confiables en muchos casos al notener garantıas sobre sus sistemas ni contar con la infraestructura adecuada,lo cual provoca riesgos cuando se habla de mantenimiento y resguardo de lainformacion. Factores que pueden ser prevenidos con esta nueva arquitectu-ra que implementa blockchain y que puede ser implementada por este tipode empresas.

Con esto se cumplirıa el objetivo general del proyecto el cual es ”Desa-rrollar una arquitectura de integracion para pequenas empresas que permitala conexion de sistemas transaccionales con bases de datos distribuidas im-plementando la tecnologıa blockchain.”pues vemos como con la consecucionde los demas objetivos especıficos, podemos alcanzar nuestra meta final, ygenerar una arquitectura de integracion en base a blockchain para las pe-quenas empresas.

15.2. Sintesis del modelo propuesto

El trabajo de investigacion desarrollado tiene impacto en los sistemastransaccionales distribuidos citando el caso de estudio de agencias de viajelos cuales se caracterizan por tener bases de datos en diferentes locacionesfısicas, de tal forma de que estos tipos de sistemas se vean beneficiados alcontar con una red de persistencia basada en tecnologıa blockchain, lo cualbrindarıa caracterısticas de escalabilidad, tolerancia a fallos y seguridad.

Los prototipos desarrollados permiten realizar operaciones de insercion, ac-tualizacion, eliminacion y consulta de informacion, adicional el prototipoutilizado para la red blockchain realiza operaciones de sincronizacion, con-senso, mineo, encriptacion y adicion de bloques.

15.3. Aportes originales

Uso de tecnologıa blockchain sobre sistemas transaccionales con basesde datos distribuidas.

Contruccion de un prototipo para el manejo de la tecnologia blockchainen sistemas transaccionales.

15.4. TRABAJOS O PUBLICACIONES DERIVADAS 153

Incentivo hacia los sistemas transaccionales distribuidos para el uso detecnologıa blockchain sobre sus sistemas de informacion.

Motivacion para la mejora en seguridad de la informacion, toleranciaa fallos y escalabilidad en los actuales sistemas.

Uso de nuevas tecnicas y metodos en los sistemas que garanticen laseguridad de la informacion, y que eviten ataques ciberneticos quepuedan afectar el funcionamiento de los mismos.

15.4. Trabajos o publicaciones derivadas

En el desarrollo del proyecto se obtuvo como publicaciones el presentedocumento, las vistas y los prototipos desarrollados.

154 CAPITULO 15. CONCLUSIONES

Capıtulo 16

Prospectiva de trabajo degrado

16.1. Lıneas de investigacion futura

Con el desarrollo de la arquitectura propuesta, es posible ver otras al-ternativas de investigacion futuras como:

Posibilidad de desarrollar sistemas con uso de tecnologıa blockchainpara bases de datos SQL o basadas en grafos.

Minerıa y big data a traves de redes blockchain de sistemas transac-cionales.

Manejo de contratos inteligentes desde la red blockchain, para descu-brir nuevas funcionalidades a partir de la data ya utilizada.

16.2. Trabajos de investigacion futuros

Los trabajos futuros establecidos a partir del proyecto desarrollado son:

Implementacion de autenticacion por protocolo OAuth a traves de lared blockchain.

Despliegue de aplicacion y revision de rendimiento desde una cantidaddeterminada de nodos.

Revision e implementacion de la solucion desde otros sistemas tran-saccionales.

155

156 CAPITULO 16. PROSPECTIVA DE TRABAJO DE GRADO

Persistencia y validacion de la cadena blockchain desde el motor debase de datos.

16.3. Conclusiones

El uso de una arquitectura basada en microservicios permite descen-tralizar la aplicacion logrando que cada componente tenga una res-ponsabilidad particular, en este caso la presentacion para enlazar loscomponentes graficos, el web API para tener acceso a los servicios denegocio y el API de Blockchain el cual permite gestionar la informa-cion de la red de modo que registros sean inmutables y atomicos frentea cualquier cambio.

Con el funcionamiento de esta arquitectura, se evidencia el controlhistorico sobre todos los cambios a nivel de informacion de la base dedatos, lo cual permite un mayor seguimiento al momento de consultarcambios sobre la informacion de una base.

La implementacion de una arquitectura basada e Blockchain permiteuna alternativa a los sistemas transaccionales distribuidos, por lo tantoes importante introducir nuevas tecnologıas emergentes en el mercado,con el fin de crear y generar soluciones novedosas que se adapten a lasnecesidades actuales.

Bibliografıa

[1] M. T. Ozsu and P. Valduriez, Principles of distributed database systems.Springer Science & Business Media, 2011.

[2] K. T. G. Suarez, R. Anaya, and A. F. Cano, “Un acercamiento a losmicroservicios,” Unaciencia, vol. 10, no. 19, pp. 11–11, 2017.

[3] SCRUMStudyTM, SBOKTM Guide. VMEdu, 2017.

[4] “Que es un servidor WEB,” https://developer.mozilla.org/es/docs/learn/common questions/que es un servidor web, accedido: 2019-04-27.

[5] “Ibm knowledge center,” https://www.ibm.com/support/knowledgecenter/es/ssw aix 72/com.ibm.aix.networkcomm/protocols ip.htm, accedido: 2019-04-27.

[6] R. Tonelli, M. I. Lunesu, A. Pinna, D. Taibi, and M. Marchesi, “Imple-menting a microservices system with blockchain smart contracts,” in2019 IEEE International Workshop on Blockchain Oriented SoftwareEngineering (IWBOSE), Feb 2019, pp. 22–31.

[7] D. Nagothu, R. Xu, S. Y. Nikouei, and Y. Chen, “A microservice-enabled architecture for smart surveillance using blockchain techno-logy,” in 2018 IEEE International Smart Cities Conference (ISC2),Sep. 2018, pp. 1–4.

[8] “Togaf adm tutorial,” https://www.visual-paradigm.com/guide/togaf/togaf-adm-tutorial, accedido: 2019-11-16.

[9] M. E. Iacob, H. Jonkers, M. Lankhorst, E. Proper, and D. Quartel,“Archimate 2.0 specification: The open group,” 2012.

157

158 BIBLIOGRAFIA

[10] “Introduction to design patterns,” https://reactiveprogramming.io/books/design-patterns/en/catalog, accedido: 2019-11-16.

[11] R. S. Pressman and J. M. Troya, “Ingenierıa del software,” 1988.

[12] G. Strawn, “Blockchain,” IT Professional, vol. 21, no. 1, pp. 91–92, Jan2019.

[13] M. A. Benıtez and A. Arias, Curso de Introduccion a la Administracionde Bases de Datos. IT Campus Academy, 2015.

[14] “Introduction to node.js,” https://nodejs.dev/introduction-to-nodejs,accedido: 2019-04-28.

[15] “Starting,” https://es.reactjs.org/docs/getting-started.html, accedido:2019-11-16.

[16] “Full archimate viewpoints guide,” https://www.visual-paradigm.com/guide/archimate/full-archimate-viewpoints-guide/, accedido: 2019-10-26.

[17] A. Kok, Hands-On Blockchain for Python Developers. PacktPublishing, 2019. [Online]. Available: https://books.google.com.co/books?id=eRVfwgEACAAJ

Documents

Arquitectura de integraci on basada en tecnolog a