Prototipo arquitectónico para aplicaciones de alta concurrencia basado en el modelo de actores con la Aplicación de Akka Toolkit

Texto completo

(1)PROTOTIPO ARQUITECTÓNICO PARA APLICACIONES DE ALTA CONCURRENCIA BASADO EN EL MODELO DE ACTORES CON LA APLICACIÓN DE AKKA TOOLKIT. SIMÓN ANDRÉS MONTAÑEZ BRAVO. UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD TECNOLÓGICA INGENIERÍA EN TELEMÁTICA BOGOTÁ D.C. MAYO DE 2016.

(2) PROTOTIPO ARQUITECTÓNICO PARA APLICACIONES DE ALTA CONCURRENCIA BASADO EN EL MODELO DE ACTORES CON LA APLICACIÓN DE AKKA TOOLKIT. SIMÓN ANDRÉS MONTAÑEZ BRAVO CÓDIGO: 20122378020. Proyecto presentado como requisito para optar el título de Ingeniero en Telemática. PROYECTO DE DESARROLLO TECNOLÓGICO. INGENIERO MIGUEL ÁNGEL LEGUIZAMÓN PÁEZ TUTOR. UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD TECNOLÓGICA INGENIERÍA EN TELEMÁTICA BOGOTÁ D.C. MAYO DE 2016.

(3) CONTENIDO. 1.. DEFINICIÓN, PLANEACIÓN Y ORGANIZACIÓN.................................................... 10. 1.1. Título ........................................................................................................................ 10 1.2. Planteamiento del problema ..................................................................................... 10 1.3. Formulación de la pregunta ...................................................................................... 12 1.4. Objetivos .................................................................................................................. 12 1.4.1.. Objetivo General................................................................................................ 12. 1.4.2.. Objetivos Específicos ........................................................................................ 12. 1.5. Justificación .............................................................................................................. 12 1.6. Estado del arte ......................................................................................................... 13 1.7. Marco Teórico........................................................................................................... 15 1.7.1.. Paradigma Funcional ......................................................................................... 16. 1.7.2.. Scala ................................................................................................................. 16. 1.7.3.. Concurrencia y Paralelismo ............................................................................... 17. 1.7.4.. Tolerancia a fallos. ............................................................................................ 17. 1.7.5.. Modelo de Actores ............................................................................................. 19. 1.7.6.. Aplicaciones Reactivas ...................................................................................... 20. 1.7.7.. Akka Toolkit ....................................................................................................... 22. 1.7.8.. Ciclo PHVA ........................................................................................................ 23. 1.8. Delimitaciones .......................................................................................................... 24 1.9. Metodología .............................................................................................................. 24 1.10.. Cronograma ...................................................................................................... 26. 1.11. Presupuesto ........................................................................................................... 27 2.. DISEÑO DEL PROTOTIPO ...................................................................................... 29. 2.1. Conceptualización modelo de actores. ..................................................................... 29 2.1.1.. Construcción de la prueba ................................................................................. 31. 2.1.2.. Características utilizadas del modelo de actores y el Toolkit Akka..................... 33. 2.2. Diseño ...................................................................................................................... 36 2.2.1.. Resiliencia ......................................................................................................... 37.

(4) 2.2.2.. Elasticidad .........................................................................................................39. 2.2.3.. Orientación a mensajes (message-driven) .........................................................42. 2.2.4.. Responsividad ...................................................................................................42. 3.. DESARROLLO .........................................................................................................43. 3.1. Vista Lógica ..............................................................................................................43 3.2. Vista de Desarrollo....................................................................................................44 3.3. Vista de Proceso .......................................................................................................46 3.4. Vista Física ...............................................................................................................48 3.5. Escenarios ................................................................................................................49 4.. PRUEBAS ................................................................................................................50. 4.1. Despliegue solución AWS ........................................................................................51 4.2. Descripción de los escenarios y definición de métricas .............................................52 4.3. Ejecución ..................................................................................................................53 4.3.1.. Escenarios .........................................................................................................53. 4.3.2.. Análisis ..............................................................................................................68. 5.. OPTIMIZACIÓN ........................................................................................................70. 5.1. Estado Inicial ............................................................................................................70 5.2. Foco de optimización ................................................................................................72 5.3. Ajustes y pruebas de regresión .................................................................................72 CONCLUSIONES ............................................................................................................78 RECOMENDACIONES ....................................................................................................81 REFERENCIAS ...............................................................................................................82.

(5) ÍNDICE DE FIGURAS. Figura 1. Fases tolerancia a Errores ................................................................................ 18 Figura 2. Esquema de actores para la prueba de concepto ............................................. 29 Figura 3. Estados de la máquina finita de estados dentro del actor ................................. 30 Figura 4. Implementación del trait Actor del Toolkit Akka. ................................................ 31 Figura 5. Implementación FSM ........................................................................................ 31 Figura 6. Reporte pruebas unitarias de la prueba de concepto ........................................ 33 Figura 7. Representación de una FSM en el Toolkit Akka. ............................................... 33 Figura 8.Vista de los componentes de la implementación de actores en el Toolkit Akka. 34 Figura 9 Ciclo de Vida del Actor....................................................................................... 35 Figura 10. Diseño del prototipo ........................................................................................ 36 Figura 11. Estrategias de supervisión .............................................................................. 38 Figura 12.Supervisión en el diseño del prototipo.............................................................. 38 Figura 13. Modelo Publish-Subscribe Channel local ........................................................ 41 Figura 14. Modelo Publish-Subscribe Channel remoto .................................................... 41 Figura 15. Vista lógica ..................................................................................................... 44 Figura 16. Vista de Desarrollo.......................................................................................... 45 Figura 17. Vista de Proceso ............................................................................................. 47 Figura 18. Vista Física ..................................................................................................... 48 Figura 19. Vista +1 Escenario .......................................................................................... 49 Figura 20. Esquema de pruebas ...................................................................................... 50 Figura 21. AWS Esquema ............................................................................................... 51 Figura 22. Mensajes procesados por segundo - Escenario 1 ........................................... 54 Figura 23. Tiempo de procesamiento por Actor - Escenario 1.......................................... 54 Figura 24. Procesos ejecutados en la FSM - Escenario 1 ................................................ 55 Figura 25. Uso de CPU – Escenario 1 ............................................................................. 55 Figura 26. Mensajes procesados por segundo - Escenario 2 ........................................... 56 Figura 27. Tiempo de procesamiento por Actor - Escenario 2.......................................... 56 Figura 28. Procesos ejecutados en la FSM - Escenario 2 ................................................ 57 Figura 29. Uso de CPU – Escenario 2 ............................................................................. 57 Figura 30. Mensajes procesados por segundo - Escenario 3 ........................................... 58.

(6) Figura 31. Tiempo de procesamiento por Actor - Escenario 3 ..........................................59 Figura 32. Procesos ejecutados en la FSM - Escenario 3 ................................................59 Figura 33. Uso de CPU – Escenario 3 .............................................................................60 Figura 34. Mensajes procesados por segundo - Escenario 4 ...........................................60 Figura 35. Tiempo de procesamiento por Actor - Escenario 4 ..........................................61 Figura 36. Procesos ejecutados en la FSM - Escenario 4 ................................................61 Figura 37. Uso de CPU – Escenario 4 .............................................................................62 Figura 38. Mensajes procesados por segundo - Escenario 5 ...........................................62 Figura 39. Tiempo de procesamiento por Actor - Escenario 5 ..........................................63 Figura 40. Procesos ejecutados en la FSM - Escenario 5 ................................................63 Figura 41. Uso de CPU – Escenario 5 .............................................................................64 Figura 42. Mensajes procesados por segundo - Escenario 6 ...........................................64 Figura 43. Mensajes procesados por segundo - Escenario 6 ...........................................65 Figura 44. Procesos ejecutados en la FSM - Escenario 6 ................................................65 Figura 45. Uso de CPU – Escenario 6 .............................................................................66 Figura 46. Procesos ejecutados en la FSM Escenario 7 ..................................................67 Figura 47. Mensajes procesados por el Actor Validador Escenario 7 ...............................67 Figura 48. Mensajes procesados por el Actor Persistencia Escenario 7 ..........................67 Figura 49. Mensajes procesados por el Actor Notificador Escenario 7 .............................67 Figura 50. Procesos ejecutados en la FSM Escenario 8 ..................................................68 Figura 51. Mensajes procesados por el Actor Validador Escenario 8 ...............................68 Figura 52. Mensajes procesados por el Actor Persistencia Escenario 8 ..........................68 Figura 53. Mensajes procesados por el Actor Notificador Escenario 8 .............................68 Figura 54. Mensajes procesados por segundo Actor de notificación - Estado Inicial ........70 Figura 55. Mensajes procesados por segundo Actor de persistencia - Estado Inicial.......71 Figura 56. Mensajes procesados por segundo Actor de validación - Estado Inicial ..........71 Figura 57. Mensajes por segundo Actor Notificador - Optimización .................................73 Figura 58. Mensajes por segundo Actor Validador - Optimización ..................................75 Figura 59. Mensajes totales Actor Validador - Optimización ............................................75 Figura 60. Mensajes por segundo Actor Persistencia - Optimización ..............................77 Figura 61. Mensajes totales Actor Persistencia - Optimización ........................................77.

(7) ÍNDICE DE TABLAS. TABLA 1. COSTOS DE PERSONAL. .............................................................................................................................. 27 TABLA 2. COSTOS RECURSOS FÍSICOS. ......................................................................................................................... 27 TABLA 3. COSTOS INSTANCIAS AWS. ......................................................................................................................... 28 TABLA 4. COSTOS TOTALES....................................................................................................................................... 28 TABLA 5. INSTANCIAS DE AWS PARA LAS PRUEBAS DE RENDIMIENTO................................................................................ 51 TABLA 6. CONFIGURACIONES ESCENARIOS .................................................................................................................. 52 TABLA 7. MÉTRICAS PRUEBAS RENDIMIENTO .............................................................................................................. 53 TABLA 8. MEDICIÓN INICIAL ACTORES. ....................................................................................................................... 72 TABLA 9. CONFIGURACIONES OPTIMIZACIÓN ACTOR NOTIFICADOR .................................................................................. 73 TABLA 10. CONFIGURACIONES OPTIMIZACIÓN ACTOR VALIDADOR ................................................................................... 74 TABLA 11 CONFIGURACIONES OPTIMIZACIÓN ACTOR VALIDADOR .................................................................................... 76.

(8) RESUMEN. Con el propósito de analizar soluciones alternativas a los problemas de concurrencia y la alta demanda de los usuarios sobre las aplicaciones actuales, en el presente documento se realiza un análisis del modelo de actores, a partir de la construcción de un prototipo arquitectónico que se preocupa, además, por los elementos descritos por el manifiesto reactivo: responsividad, resiliencia, elasticidad y orientación a mensajes. Bajo esos paradigmas se ejecuta este proyecto. En el documento se presenta la elaboración del diseño, el desarrollo y las pruebas de rendimiento en búsqueda de concluir si la propuesta constituye una solución adecuada.. ABSTRACT. In order to analyze alternative solutions to the problems of concurrency and high user demand for current applications, herein an analysis model of actors is made, from the construction of an architectural prototype that cares, also by the elements described by The Reactive Manifesto: responsiveness, resilience, elasticity and messages driven. This report elaborate the work out of design, the development and the performance testing, in search to conclude if the proposal constitutes an adequate solution..

(9) INTRODUCCIÓN. La concurrencia y la tolerancia a fallos, constituyen dos elementos esenciales dentro de los atributos de calidad de Software. Un incorrecto diseño puede ocasionar problemas de inconsistencia o de falta de disponibilidad. Existen diversos modelos para tratar esos retos tecnológicos; no obstante, dada la actual demanda de usuarios sobre los sistemas informáticos, surge la necesidad de analizar e implementar nuevos esquemas arquitectónicos como solución. En este sentido, una de las soluciones que se pueden señalar es el Modelo de Actores. Aunque este modelo fue teóricamente descrito en el año 1973 por Carl Hewitt, solo hasta ahora se resalta como una opción que permite el máximo aprovechamiento de los recursos de hardware y un mantenimiento seguro de la consistencia en escenarios de alta concurrencia. En este sentido, la compañía Typesafe ha desarrollado un conjunto de herramientas al que denominaron Akka Toolkit, en el que implementaron todos los elementos del modelo planteado por Hewiit. Dadas las demandas de las aplicaciones actuales se pretende, entonces, analizar la implementación y el rendimiento del modelo de Hewiit con el uso de Akka Toolkit. De otra parte, vale la pena señalar la presentación, en el año 2014, del Manifiesto Reactivo. Este documento, describió cuatro elementos esenciales a tener en cuenta en el desarrollo de aplicaciones: Responsive, Resilient, Elastic y Message Driven. De acuerdo con el Manifiesto, el diseño de software debe enmarcarse dentro de estas características, y sus componentes relacionarse, de manera directa, con uno o más de estos atributos. Bajo estos dos paradigmas, el modelo de actores y el diseño de aplicaciones reactivas, en el presente trabajo se planteó la construcción de un prototipo arquitectónico para aplicaciones de alta concurrencia, el cual se expone y se analiza en este documento. Para la ejecución del proyecto se siguió como metodología el ciclo PHVA, presentada a lo largo de los capítulos que componen el trabajo, como se muestra a continuación: Planear, en el capítulo uno, de Definición; Hacer, en los capítulos dos y tres, de Diseño y Desarrollo, respectivamente; Verificar, en el capítulo cinco, de Pruebas; y, Actuar, en el capítulo seis, de Optimización..

(10) 1.. 1.1.. DEFINICIÓN, PLANEACIÓN Y ORGANIZACIÓN. Título. Prototipo arquitectónico para aplicaciones de alta concurrencia basado en el modelo de actores con la aplicación de Akka Toolkit.. 1.2.. Planteamiento del problema. Colombia cuenta, en la actualidad, con cerca de 32 millones de votantes potenciales. Partamos de una situación hipotética: supongamos que el Ministerio de Tecnologías de la Información y las Comunicaciones (MinTIC) requiere, como parte de un proyecto, implementar el voto en línea. De inmediato, deviene la pregunta por la manera como debería ser procesada la información y con ella, una aún más específica: ¿cuántas transacciones por segundo debemos soportar? La cifra que obtendremos como respuesta superaría, fácilmente, los miles. ¿Y si ampliamos el espectro de nuestra situación hipotética?, por ejemplo, que todas las entidades estatales deban validar las huellas digitales de los usuarios ante la Registraduría para realizar trámites como: la expedición de licencias de conducción, el ingreso de personas -empleados y particulares- a entidades públicas y el ingreso de reclusos al sistema penitenciario, entre otros. Como es de esperar, la cifra de transacciones aumentará al orden de los millones. Además, tendríamos que contemplar otro importante requerimiento: el sistema no se puede detener. Lo anterior, se resume en dos atributos generales de los sistemas: la concurrencia y la tolerancia a fallos. Una inadecuada implementación, puede conllevar problemas como pérdida de información, inconsistencia, datos no guardados, bloqueo mutuo e inanición, entre otros. Con los altos niveles de concurrencia y de tolerancia a fallos requeridos en la actualidad para el desarrollo de diversas aplicaciones, ¿cómo cumplir a satisfacción estos requerimientos a nivel de software?, ¿cuál sería el modelo óptimo para la administración. 10.

(11) de los recursos de hardware? Asimismo, los expertos en las aplicaciones distribuidas deberán responder, de manera puntual, a cuestiones como: ¿cuál es el estilo arquitectónico adecuado? ¿Los modelos tradicionales aún son una solución viable? ¿De qué manera han evolucionado los diseños? Estas cuestiones no constituyen un problema exclusivo de las grandes aplicaciones de redes sociales y mensajería (Google, Facebook, Microsoft, Whatsapp), configuran una preocupación que se acerca tanto al mundo empresarial como a los servicios del Estado. En Colombia, la ingeniería de software se halla ante la ineludible tarea de plantear soluciones que permitan pasar de atender cientos a millones de transacciones por segundo. En este sentido, el manejo de concurrencia debe aprovechar al máximo los actuales elementos de procesamiento. Respecto a esta cuestión Haller & Odersky (2009) plantean que “(...) los procesadores multi-núcleo hacen de la concurrencia un ingrediente esencial para la eficiente ejecución de un programa” (202). Por otro lado, problemas como la latencia o la falta de disponibilidad, aumentan cuando se está sobre las redes móviles. Los fallos en la entrega de mensajes son claramente predecibles. Este tema, al igual que el de la necesidad de un modelo de concurrencia eficiente, representa una gran importancia para el desarrollo de software. En los diseños actuales de aplicaciones se torna necesario el reparo en que el modelo utilizado contenga un esquema de tolerancia a fallos, con el propósito de que sea capaz de auto recuperarse y, de esta manera, reducir al mínimo la pérdida de información. Para escenarios como los expuestos hasta ahora, existen múltiples soluciones. Diversos estilos arquitectónicos, modelos y diseños tienen como propósito cumplir con los mencionados atributos de calidad. Uno de estos, es el modelo de actores. Sin embargo, vale la pena preguntarnos si ¿el modelo de actores puede ser un modelo de computación concurrente que asegure la tolerancia a fallos y soporte un alto número de transacciones? ¿Bajo qué modelo arquitectónico se aplicaría? Con base en estos interrogantes, se torna pertinente el desarrollo de un prototipo arquitectónico basado en el modelo de actores que responda a los principios reactivos como una solución para escenarios altamente concurrentes y distribuidos.. 11.

(12) 1.3.. Formulación de la pregunta. Para una demanda de transacciones que superan los millones por segundo, ¿Cómo apoyar el funcionamiento de estos sistemas informáticos altamente concurrentes y distribuidos?. 1.4.. Objetivos. 1.4.1. Objetivo General. Diseñar un prototipo arquitectónico reactivo en una aplicación de mensajería como solución a sistemas informáticos altamente concurrentes y distribuidos, basado en el modelo de Actores a través del uso de Akka Toolkit.. 1.4.2. Objetivos Específicos . Conceptualizar el Modelo de Actores con Akka Toolkit, como solución para sistemas de alta concurrencia y como alternativa para la aplicación de tolerancia a fallos.. . Diseñar un prototipo arquitectónico reactivo utilizando como solución base Akka Toolkit.. . Desarrollar el prototipo arquitectónico bajo la estructura de Akka Toolkit con atención a las características de una aplicación reactiva.. . Analizar el rendimiento, la estabilidad y el comportamiento de la cola mensajes de Akka Toolkit con el propósito de establecer el uso de recursos y el procesamiento de mensajes en razón del tiempo.. . Ajustar el diseño y la implementación del prototipo arquitectónico reactivo de acuerdo con las conclusiones obtenidas en los análisis de rendimiento.. 1.5.. Justificación. Es necesario que en Colombia, por cuenta del acceso globalizado a la información, se potencie la utilización de nuevas tecnologías, en el desarrollo de software distribuido,. 12.

(13) altamente concurrente, tolerante a fallos y escalable. La investigación en esta área es de vital importancia para el crecimiento tecnológico. Los sistemas de gestión, atención al ciudadano, canales de interacción e información, entre otros, deben estar alineados con nuevos modelos y paradigmas de programación. Plantear una investigación e implementación de un proyecto como el aquí expuesto ofrece una base fundamental para apalancar las nuevas dimensiones del desarrollo de software en Colombia. En este sentido, se abre la puerta al Modelo de Actores que nace de la necesidad de plantear una solución eficiente a los problemas que acontecen con la concurrencia, pues, “ha sido utilizado tanto como un marco de trabajo para el entendimiento teórico de la concurrencia, como la base teórica para implementaciones prácticas de sistemas concurrentes y distribuidos.” (Hewitt, 2010). La utilización del modelo de actores ha venido creciendo en la práctica en los lenguajes de programación como Erlang ó Scala y en librerías como Akka (Typesafe, 2012). Este modelo y otros de manejo no bloqueante de recursos, vienen siendo utilizados en aplicaciones populares como Twitter o WhatsApp. Si se consideran las aplicaciones actuales como sistemas que interactúan con redes sociales y mensajería instantánea, donde se apunta a atender un gran número de usuarios, con los problemas ya planteados de concurrencia y latencia de red, entonces, la aplicación del Modelo de Actores resulta oportuna para atender a las demandas planteadas. No sólo para plantear una muy cercana solución, sino para abrir el camino a nuevas implementaciones sobre aplicaciones cliente – servidor, bien sean sobre sistemas operativos para dispositivos móviles o computadores personales.. 1.6.. Estado del arte. Estudios Académicos. En el ámbito académico existen diferentes investigaciones acerca del Modelo de Actores. Este modelo es analizado desde varios escenarios e implementado desde diferentes tecnologías. A continuación se presentan algunos títulos de los trabajos que se consideran relevantes, acompañados por un breve resumen y por los aportes al tema de interés.. -. Using Actors to Implement Sequential Simulations: Tesis de Maestría de Ryan Harrison en la Universidad de Saskatchewan, Canada. (2015). 13.

(14) Resumen: Investiga el uso de un enfoque basado en el paradigma de Actores para la implementación de un sistema de simulación de eventos discretos y la comparación de los resultados con los enfoques más tradicionales. El objetivo de ese trabajo es determinar si el uso de Actores para la programación secuencial es viable. Aporte: Este trabajo ofrece un marco de referencia en términos de los resultados obtenidos y las comparaciones que realiza sobre modelos tradicionales.. -. Actor Model of Computation: Scalable Robust Information Systems. Artículo de Carl Hewitt (2011). Resumen: Define la teoría base matemática, partiendo de la hipótesis que indica que la computación puede ser directamente implementada usando Actores. Aporte: Es la base fundamental del modelo de actores.. -. Representation of asynchronous communication protocols in Scala and Akka: Tesis de Maestría de Joakim Eriksson en la Universidad de Linköpings, Suecia. (2013). Resumen: Investiga cómo representar protocolos para la comunicación asíncrona en el lenguaje de programación Scala y el framework Akka, analizando el uso sobre la máquina virtual de Java. Aporte: Akka y Scala se ejecutan sobre la JVM, esta investigación ofrece un punto de partida para interpretar los hilos que se utilizan al programar sobre estas tecnologías.. -. Why Do Scala Developers Mix the Actor Model with Other Concurrency Models? Artículo de Samira Tasharofi, Peter Dinges, y Ralph Johnson. Universidad de Illinois. (2013). Resumen: Este estudio es el primero en señalar el fenómeno de la mezcla de modelos de concurrencia que tiene lugar en el lenguaje Scala, y en identificar sistemáticamente los factores que conducen a ella. Se estudiaron 15 proyectos de utilizan actores y que fueron escritos en Scala; encontraron que el 80% de ellos mezclan el modelo de actores con otro modelo de concurrencia. Aporte: El modelo de actores no es el único que trata el tema de la concurrencia, en ese sentido este artículo, no es solo un marco de referencia. Justifica técnicamente la combinación de tecnologías, para este caso puntual Scala y Akka. En las aplicaciones. 14.

(15) que modelan problemas reales, se puede encontrar que el modelo de actores no es suficiente. En Colombia, en el campo académico no se encuentran artículos o tesis investigativas relacionadas con el tema. Productos Implementados. Typesafe la empresa creadora de Akka (Implementación del modelo de actores). A través de empresas de construcción de software asociadas ha implementado la solución en varias compañías, entre ellas (Typesafe, 2012): . Nitro: Servicios en línea. . Gilt: Servicios Financieros. . Intel: Streaming en tiempo real.. . Walmart.. En Colombia, la aplicación de nuevos modelos para el manejo de concurrencia, como el de actores, es poco utilizado. Sin embargo, vale la pena resaltar que empresas de desarrollo como Seven4n utilizan estas tecnologías en clientes como: . SURA (Suramericana de Seguros).. . Alianza Fiduciaria.. . Certicamara.. Es importante resaltar, que estas experiencias pueden arrojar datos acerca del rendimiento en ambientes productivos del modelo de actores. Además es posible determinar el alcance del dominio utilizado, identificando con cuales otros modelos fue combinada la solución final.. 1.7.. Marco Teórico. El diseño de una arquitectura final encaminada a resolver los asuntos expuestos en el planteamiento del problema requiere delinear aspectos relevantes alrededor de una serie de tecnologías y delimitar elementos de orden conceptual. Dentro de esos conceptos se 15.

(16) incluirán los relacionados con Paradigma Funcional, Scala, Concurrencia y Paralelismo, Tolerancia a Fallos, Modelo de Actores, Aplicaciones Reactivas y Akka Toolkit, entre otros.. 1.7.1. Paradigma Funcional. La programación funcional es un enfoque de la programación basado en los llamados a funciones como la construcción de programación primaria (Michaelson, 2013). De la utilización de ese tipo de programación se obtienen las siguientes ventajas (Manual guía de aprendizaje de programación avanzada, 1998): . Programación sin asignaciones: la ausencia de estado, evita la utilización de asignaciones, lo cual facilita la aplicación de técnicas matemáticas al razonar sobre el comportamiento de los programas funcionales. Esto resulta en la simplificación del desarrollo y de la demostración de programas.. . Alto nivel de abstracción: los lenguajes funcionales proveen mayor poder de abstracción para la manipulación de los datos; por ejemplo, a través de listas por comprensión y pattern matching, lo cual permite escribir programas más concisos, legibles y de alto nivel. Además, la utilización de funciones de Orden Superior permite abstraer el comportamiento de los programas.. 1.7.2. Scala Es un lenguaje de programación, que puede ser escrito utilizando dos paradigmas de forma simultánea: el paradigma Orientado a Objetos y el paradigma Funcional. De acuerdo con Odersky, Spoon, & Venners, Scala "está diseñado para crecer con la demanda de los usuarios. Se puede aplicar a un amplio rango de tareas de programación, desde escribir pequeños scripts hasta construir sistemas extensos" (Odersky, Spoon, & Venners, 2008). Este lenguaje fue desarrollado por Martín Odersky y su lanzamiento se produjo en el año 2004. Scala se ejecuta en la plataforma Java estándar e interactúa a la perfección con todas las bibliotecas de Java. Es un lenguaje bastante bueno para escribir scripts que unifican componentes Java (Odersky, Spoon, & Venners, 2008). La combinación de 16.

(17) ambos estilos en Scala hace que sea posible expresar nuevos tipos de patrones de programación y abstracciones componentes. También conduce a un estilo legible y conciso de programación. 1.7.3. Concurrencia y Paralelismo Comúnmente, Paralelismo y Concurrencia son referenciados como si se tratase de lo mismo, por ello, se considera necesario presentar algunas precisiones que demarque sus diferencias: Paralelismo. Es el acto de la modificación de un algoritmo, aparentemente secuencial, en un conjunto de partes independientes que se pueden ejecutar de forma simultánea, bien sea en varios núcleos o varias máquinas. Por ejemplo, miles de matrices pueden multiplicarse secuencialmente, pero también puede hacerse en paralelo si se rompe hacia arriba en una jerarquía de multiplicaciones (Wyatt, 2013, págs. 33-34). Concurrencia. Es el acto de una aplicación que tiene muchos algoritmos dependientes o independientes corriendo a través de múltiples hilos de ejecución de manera simultánea. El ejemplo más sencillo es el de un servicio web, como Twitter, el cual es altamente orientado a eventos, tiene tweets de millones de usuarios, así como eventos de sus propios sistemas internos. Todo esto sucede al mismo tiempo (Wyatt, 2013, pág. 33). Se dice que un sistema es concurrente si puede soportar dos o más acciones en progreso al mismo tiempo. Es paralelo si puede soportar dos o más acciones que se ejecutan de forma simultánea. El concepto clave y la diferencia entre estas definiciones es la frase "en progreso". (Breshears, 2009) 1.7.4. Tolerancia a fallos. En software, la tolerancia a fallos hace referencia a un atributo de calidad que indica la capacidad de responder ante los errores que se puedan presentar durante la ejecución de una aplicación sin afectar su disponibilidad. ¿Qué puede salir mal en una situación dada? Esa es una pregunta clave para cualquiera que trate de desarrollar software tolerante a fallos. Se considera que existe una 17.

(18) mentalidad tolerante a errores cuando se piensa en este interrogante y se define la solución. En casi cualquier situación algo puede salir mal. Un programa tolerante a fallos está preparado para estos errores. Hacer preguntas del tipo ¿Qué sucede si…? y la planificación durante el diseño de los errores que pueden ocurrir durante la ejecución, son las características de la mentalidad tolerante a errores. Preguntas como ¿Qué pasa si el puntero de pila se convierte en negativo? ¿Qué pasa si la subclase se instancia mal? Son algunos ejemplos del tipo de interrogantes que es pertinente realizar. La aplicación de una mentalidad tolerante a errores en todas las etapas de desarrollo de software es beneficioso. Esto se incluye tanto en la definición de requerimientos y desarrollo de las pruebas, como en las fases tradicionales de creación de software (arquitectura, diseño, codificación) (Breshears, 2009) (Hanmer, 2013) El ciclo de vida de la tolerancia a fallos, puede describirse a partir de cuatro fases: detección, recuperación, mitigación y tratamiento del fallo.. Figura 1. Fases tolerancia a Errores. Fuente: El Autor. Para ser tolerante a fallos, lo primero que debe suceder cuando una falla se activa y se produce un error, es la detección. Para esto existen técnicas como la supervisión o la comparación de respuestas mediante algún algoritmo. Una vez detectado, el error debe ser procesado. Allí se sitúa el foco de las siguientes dos fases; estas se deben ejecutar en tiempo real y afectarán directamente la disponibilidad del sistema. La recuperación trabaja para establecer un estado en el sistema libre de errores; es decir, para liberar al sistema del estado que indica el error. Dependiendo de la circunstancia, el error puede ser eliminado o mitigarse sin cambiar el estado del sistema. Por ejemplo, cuando un valor de 18.

(19) un dato es erróneo puede ser corregido y continuar con el proceso, en lugar de reiniciar el proceso.. 1.7.5. Modelo de Actores El modelo de actores fue definido por Carl Hewitt en un artículo publicado en 1973, su popularización ocurrió por cuenta del lenguaje Erlang y, además, fue utilizado por Ericsson con gran éxito en la construcción de sistemas altamente concurrentes y confiables. De acuerdo con Agha, "los actores son agentes computacionales muchos más poderosos que el procesamiento secuencial" (Agha, 1986). Técnicamente, el modelo de actores se define como un modelo matemático de computación concurrente que establece los actores como elementos primitivos, con responsabilidades claramente establecidas. Según Agha (1986) el modelo de actores puede, en respuesta a un mensaje que recibe, tomar decisiones locales:  Crear más actores  Enviar más mensajes  Determinar cómo responder el siguiente mensaje.. Los actores encapsulan estados y comportamientos, son capaces de crear nuevos actores y de llevar a cabo la reorientación de los enlaces de comunicación a través del intercambio de identidades de los actores. Cuando Hewitt conceptualizó el modelo de actores en los años 70, los computadores eran relativamente lentos, pero para los desarrolladores ya era posible dividir el procesamiento a través de diferentes computadores. Hewitt y su equipo querían un modelo que no sólo simplificara la construcción de sistemas concurrentes, sino que además permitiera un razonamiento general sobre los programas concurrentes (Haller & Sommers, 2012). El diseño general de este modelo permitiría a los desarrolladores seguir una línea segura para que los sistemas concurrentes se comportaran de la manera como se esperaba. Aunque la concurrencia basada en actores ha sido un concepto importante desde entonces, solo hasta hace unos años se ha venido generalizando, en parte, debido a la poca y pobre implementación en los lenguajes de programación, además de la falta de un. 19.

(20) proyecto libre basado en la construcción de un framework o de herramientas para trabajar sobre el modelo de actores. Otra característica que se torna importante mencionar, hace referencia a que todos los actores se ejecutan simultáneamente y utilizan mensajería asíncrona como estrategia de comunicación. Esto trae como elemento positivo un diseño simple comprensible y fácil de razonar. Malas prácticas, como el bloqueo, son más sencillas de evitar. El rango de problemas que es posible modelar con actores es bastante amplio. 1.7.6. Aplicaciones Reactivas Las aplicaciones reactivas utilizan una arquitectura que permite construir sistemas que requieran cumplir con las siguientes características: responsive (responsivos), resilente (resilientes), elastic (elásticos) y message-driven (orientados a mensajes) y que, además, sean capaces de generar una sensación de tiempo real. Como principio, estas aplicaciones cuentan con una serie de características resilientes; se ejecutan mejor cuando se despliegan en sistemas multi-core y multi-nodes, comúnmente en entornos basados en la nube; y, están diseñadas para cumplir con: •. Reacción a usuarios y otros componentes de la aplicación.. •. Reacción al fracaso: Recuperar cada tipo de componente al tener la resiliencia como característica central.. •. Reacción a la carga: Evitar la contención de recursos compartidos mediante la gestión de recursos discretos por separado. Esta restricción de diseño permite la elasticidad del sistema y su alto rendimiento.. •. Reacción a los mensajes: La filosofía principal es estar controlado a través de la mensajería asíncrona.. Básicamente estos conceptos están inspirados en el manifiesto reactivo, como se muestra a continuación. Responsivos. Los sistemas responden de una manera oportuna en la medida de lo posible. La responsividad es la piedra angular de la usabilidad y utilidad, pero más que esto, la responsividad refiere a problemas que pueden ser detectados rápidamente y 20.

(21) tratados de forma efectiva. Los sistemas responsivos se enfocan en proveer tiempos de respuesta rápidos y consistentes estableciendo límites superiores, de manera que puedan entregar calidad de servicio. Este comportamiento consistente se traduce en que la simplificación del tratamiento de errores construye confianza con el usuario final y alienta una mayor interacción. Resilientes. Los sistemas permanecen responsivos cuando enfrentan fallas. Esto aplica no solo a la alta disponibilidad, los sistemas de misión crítica –cualquier sistema que no es resiliente– no serán responsivos después de una falla. La resiliencia es alcanzada con replicación, contención, aislamiento y delegación. Las fallas son contenidas dentro de cada componente, aislando cada componente de los demás para asegurar, de este modo, que las partes del sistemas pueden fallar y recuperarse si comprometer el sistema como un todo. La recuperación de cada componente es delegada a otro (externo) y la alta disponibilidad es asegurada por replicación donde sea necesario. El cliente no es agobiado con tener que manejar las fallas de cada componente.. Elásticos. El sistema se mantiene responsivo bajo variaciones en la carga de trabajo. Los sistemas Reactivos pueden reaccionar a cambios en la frecuencia de peticiones incrementando o reduciendo los recursos asignados para servir dichas peticiones. Lo anterior, implica diseños que no tengan puntos de contención o cuellos de botella centralizados, como resultado se obtiene la habilidad de fragmentar o replicar componentes y distribuir las entradas a través de ellos. Los Sistemas Reactivos soportan algoritmos predictivos, así como Reactivos y de escalabilidad, proveyendo relevantes medidas de rendimiento en tiempo real; alcanzan elasticidad de una forma rentable sobre plataformas de bajo (o equilibrado) costo tanto en hardware como en software.. Orientados a Mensajes. Los Sistemas Reactivos confían en el intercambio de mensajes asíncronos para establecer límites entre componentes, esto asegura el bajo acoplamiento, el aislamiento y la transparencia de la ubicación y, proporciona los medios para delegar errores como mensajes. Con el empleo explícito del intercambio de mensajes ayuda en la administración de la carga, la elasticidad, y el control de flujo a través de la conformación y monitoreo de colas en el sistema y la aplicación de contrapresión cuando se considere necesario. La ubicación transparente de mensajes como medio de comunicación hace 21.

(22) posible a la administración de fallas el poder trabajar con los mismos bloques y semánticas a través de un cluster o dentro de un sólo nodo. La comunicación Nobloqueante permite que los receptores consuman recursos solo mientras dichos recursos estén activos, lo que lleva a una menor sobrecarga del sistema (The Reactive Manifesto, s.f.). 1.7.7. Akka Toolkit "Akka is a toolkit and runtime for building highly concurrent, distributed, and resilient message-driven applications on the JVM" (Typesafe Inc, 2016) Akka utiliza el modelo de actores para aumentar el nivel de abstracción y para proporcionar una plataforma que permita construir de manera correcta aplicaciones concurrentes y escalables. Adopta el modelo "Let it Crash" utilizado con gran éxito en las telecomunicaciones tolerantes a fallos que no se detienen. Además Akka es de código abierto bajo la licencia de Apache 2. The Akka concurrency toolkit. En la medida que el desarrollo de software ha utilizado frameworks para el manejo de la concurrencia que ocultan toda la lógica y dejan a un lado el análisis real en el diseño de la aplicación, los desarrolladores han encontrado la necesidad de tener mucha más flexibilidad y de determinar en cuáles puntos específicos utilizar determinado patrón. Pues bien, Akka no es un framework en su totalidad, provee un conjunto de herramientas para atender atributos de calidad puntuales. Herramientas Akka. Akka provee con conjunto de herramientas dentro de un nuevo paradigma de desarrollo concurrente: . Actores. Provee un esquema para implementar un diseño con Actores, un sistema consistente de supervisión y referencia a actores.. . Futuros. Los Actores, pese a que constituyen un mecanismo poderoso para el manejo de la concurrencia, no son la única solución posible. De hecho, para la solución a ciertos problemas no resultan adecuados. Donde estos no aplican, los Futuros puede ser una salida.. 22.

(23) . Timers. Esta característica es comúnmente necesaria en el desarrollo de aplicaciones donde la medición del tiempo o la ejecución de tareas futuras son importantes.. . Callbacks/Closures. El modelo shraed-state de concurrencia, usa callbacks y closures todo el tiempo. La sincronización de estos puede ser un problema. Akka lo abstrae de manera elegante.. Manejo de Errores. Las herramientas comúnmente usadas en la programación imperativa (excepciones y códigos de error) no ayudan cuando se trata de sistemas concurrentes complejos. Akka tiene presente este problema al considerar que los errores y las fallas hacen parte del diseño de una aplicación. Los creadores de Akka consideran que no es posible superar el hecho de que la vida real no se detendrá, entonces, se preguntan por qué no simplemente: Let it crash (Typesafe Inc, 2016) (Wyatt, 2013). No bloqueante por defecto. Los hilos son recursos preciosos (y muy costosos). Cuando se incorporan dentro de programas deben manejar cientos de operaciones concurrentes por segundo. Bloquear un hilo representa el camino libre de riesgos para asegurar que la aplicación no va a escalar. Cualquier toolkit que pretenda proveer un nuevo paradigma de desarrollo concurrente debe proporcionar un modo para proteger estos recursos preciosos (Wyatt, 2013). Akka, por defecto no bloquea los hilos de ejecución, además es ampliamente configurable con respecto al número y tiempo de vida de los hilos.. 1.7.8. Ciclo PHVA PHVA, es un método de gestión iterativo de cuatro pasos utilizado en las empresas para la mejora continua y para el control de los procesos y productos. Establece un marco de trabajo que puede ser utilizado para la ejecución de un proyecto investigativo, estableciendo en cada paso objetivos puntuales. El modelo ha evolucionado hasta convertirse en un marco de referencia que combina las preguntas: ¿Qué se quiere lograr? ¿Cómo saber que un cambio es una mejora? ¿Qué cambios se pueden hacer que se traduzcan en mejoras? con el ciclo PHVA se formó la base del modelo. Las tres preguntas definen el objetivo, las medidas y los posibles cambios. Setenta y dos conceptos de cambio se dan para proporcionar un punto 23.

(24) de partida para el uso del ciclo PHVA para el desarrollo, pruebas, implementación y difusión de los cambios transformados en mejoras (Moen & Norman, 2015). Los siguientes son los pasos definidos en el ciclo (Bulsuk, 2015) . Planear. En este paso se establecen las actividades de todo el proceso. Se identifican los objetivos y se establecen las tareas con tiempos claves.. . Hacer. Este paso implica ejecutar lo planeado, desarrollar el producto y documentar los problemas encontrados y las respectivas respuestas a estos.. . Verificar. Este paso se lleva a cabo una vez terminado el proyecto. Consiste en analizar las causas y consecuencias a partir de un estudiando detallado de los resultados obtenidos.. . Actuar. Luego de tener las causas de los problemas obtenidos, estos se solucionan, realizando las mejoras pertinentes. Una vez terminado el ciclo, este puede iniciar nuevamente para mejorar su implementación.. 1.8.. Delimitaciones. No es del alcance de este proyecto realizar los siguientes análisis o estudios en torno a: . Modelos y patrones de Acceso a Datos.. . Configuraciones de rendimiento sobre sistemas externos: Bases de datos, Servidor de correos, balanceadores, entre otros.. . Patrones para implementar mejores prácticas para consumir servicios externos.. . Otros esquemas para el manejo de concurrencia, como el uso directo de hilos con java o futuros en Scala.. . Modelos para la construcción de capa de presentación.. . Recuperación de mensajes por problemas de infraestructura como latencia o intermitencia de red.. 1.9.. Metodología. Dada la naturaleza del proyecto, como metodología para su ejecución se utilizará el ciclo PHVA (Planear, Hacer, Verificar y Actuar). Esta estructura metodológica cuenta con la. 24.

(25) ventaja de permitir la obtención de resultados visibles en corto tiempo; asimismo, permite el análisis de información y la realización de mejoras continuas que apuntan al cumplimiento de los objetivos. Dentro de cada fase se realizará una serie de actividades que se presentan a continuación: . Planear -. Conceptualizar el Modelo de Actores con Akka. -. Establecer los tiempos de ejecución para las tareas. -. Priorizar los elementos a construir con el Akka Toolkit. . Hacer -. Prueba de concepto el uso básico del Modelo de Actores. -. Diseñar un prototipo arquitectónico, que haga uso de Akka Toolkit. -. Desarrollar el prototipo establecido. . Verificar -. Realizar un análisis de rendimiento y estabilidad del prototipo.. -. Analizar el comportamiento de la cola mensajes de Akka.. -. Establecer las limitaciones del modelo según los resultados de las pruebas. . 25. Actuar -. Ajustar el diseño y la implementación del prototipo según las conclusiones.. -. Realizar pruebas de regresión. -. Relacionar alternativas de solución a Akka Toolkit..

(26) 1.10.. Cronograma.

(27) 1.11. Presupuesto. Personas involucradas en el proyecto. Tipo Tutor 1. Descripción Asesorías para la realización. Valor-Hora. Cantidad. Total. $ 60.000. 200. $ 12.000.000. $ 45.000. 600. $ 27.000.000. del proyecto. Desarrolladores. Un investigador que ejecute el proyecto.. Total. $ 39.000.000 Tabla 1. Costos de personal. . Fuente: El Autor.. Recursos físicos. Recurso Computadores. Descripción Equipos de escritorio para la. Valor Unitario. Cantidad. Total. $ 2.500.000. 2. $ 5.000.000. $0. 1. $0. ejecución del proyecto Repositorio. Servicio en la nube como repositorio de código. BitBucket. Internet. Servicio de internet por 6. $1.200.000. $1.200.000. $ 500.000. $ 500.000. $ 600.000. $ 600.000. meses Papelería Libros digitales. Compra o servicio por demanda de libros. (safaribooks). Total. $ 7.300.000 Tabla 2. Costos recursos físicos. . Fuente: El Autor.. 27.

(28) Instancias de Amazon Web Services (AWS). Recurso AWS- Instancia t2.micro AWS- Instancia t2.medium AWS- Instancia c3.2xlarge AWS- Instancia c4.8xlarge. Descripción Instancia EC2 de Amazon Web Service. Valor por Hora USD 0,013. Cantidad 6. 40. Total USD 3,12. 0,052. 4. 30. 6,24. 0,42. 2. 10. 8,4. 1,68. 1. 5. 8,4. Cambio de Tasa. Horas. Total USD 1 COP = 3,066. 26,16 80206,56. Tabla 3. Costos Instancias AWS. Fuente: El Autor.. Relación total de gastos. Recurso. Valor. Total Personas Involucradas. $ 39.000.000. Total Recursos Técnicos. $. 7.380.207. Costos imprevistos (10%). $. 4.638.000. TOTAL COSTO. $ 51.318.207. Tabla 4. Costos totales. Fuente: El Autor.. 28.

(29) 2.. DISEÑO DEL PROTOTIPO. Con el propósito de llevar a cabo la elaboración del diseño y conceptualizar el modelo de actores, se ejecuta en primera instancia, una prueba de concepto. Con base en esta prueba se pretende establecer los componentes base del Toolkit Akka a utilizar, así como su funcionamiento y su implementación. Estos componentes constituyen parte fundamental en el diseño del prototipo.. 2.1.. Conceptualización modelo de actores.. El modelo de actores brinda la facilidad de modelar un dominio específico representando sus entidades como actores, estos últimos pueden tener una responsabilidad propia y delegar funcionalidades o procesos a otros componentes que pueden, o no, hallarse abstraídos a través de actores. La información viaja entre estos a través de mensajes. En esta prueba inicial se utiliza el esquema base de mensajes del modelo de actores. Los mensajes indican a cada actor el inicio de una operación. De manera abstracta, también marcan el inicio y fin de una transacción. Esta construcción es la base del prototipo final al que se le agregan componentes adicionales. La Figura 2 “Esquema de actores para la prueba de concepto” representa la prueba a implementar.. Figura 2. Esquema de actores para la prueba de concepto. Fuente: El Autor.. 29.

(30) El actor ProcesadorMensajesActor recibe una serie de mensajes, mantiene un estado interno y se encarga de orquestar el mensaje entre los otros actores. Este actor representa una FSM (Finite State Machine) y tiene la responsabilidad de mantener el estado. de. la. transacción.. Los. actores. NotificadorActor,. PersistenciaActor. y. ValidadorActor tienen una responsabilidad propia, no dependiente: reciben mensajes y envían la respuesta del proceso al actor que envió el mensaje inicial, en este caso el ProcesadorMensajesActor. La Figura 3 ilustra el manejo de estados en la FSM:. Figura 3. Estados de la máquina finita de estados dentro del actor ProcesadorMensajesActor. La FSM representa los estado de una transacción, para este caso se pretende que el actor inicie y se detenga cuando termine la transacción, a este patrón se le conoce como Actor Per Request. El flujo de cambio de estados es el siguiente: 1). Inicia el actor, en el estado Disponible; 2). Recibe mensaje de inicio; 3). Envía el mensaje al validador; 4). Cambia su estado a Validando; 5). Se mantiene en el estado hasta recibir el mensaje Validado; 6). Envía mensaje a persistir; 7). Cambia su estado a Guardando; 8). Se mantiene en el estado hasta recibir el mensaje Guardado; 9). Envía mensaje a notificar; 10). Cambia su estado a Notificado; 11). Se mantiene en el estado hasta recibir el mensaje Notificado; 12). Cuando recibe el mensaje del actor que notifica, entonces se detiene. Fuente: El Autor.. 30.

(31) 2.1.1. Construcción de la prueba. Con el uso del Akka Toolkit se construye la definición de los actores extendiendo del trait Actor. Se debe implementar el método receive, este recibe el mensaje y retorna una función parcial, construida utilizando pattern matching que ejecuta la lógica de acuerdo al mensaje.. Figura 4. Implementación del trait Actor del Toolkit Akka. Fuente: El Autor.. La Figura 4, muestra que las clases NotificadorActor, PersistenciaActor y ValidadorActor implementan el trait Actor, de esa manera se define un Actor heredando todo su comportamiento. Para el caso de ProcesadorMensajesActor su implementación es diferente, porque está definido como una FSM:. Figura 5. Implementación FSM Fuente: El Autor.. 31.

(32) Una vez implementados todos los actores según el esquema presentado en la Figura 2 se ejecutan las pruebas unitarias con el propósito de validar el funcionamiento:. 1.. Escenario 1: El procesador de mensajes debe iniciar el proceso y enviar al validador el mensaje. a. Resultado esperado: Una vez recibido el mensaje, el procesador de mensajes envía el mensaje “Validar”. b. Resultado obtenido: Exitoso. El actor de prueba recibe el mensaje Validar.. 2.. Escenario 2: El procesador de mensajes debe iniciar y terminar el proceso terminando el actor. a. Validaciones dentro del escenario Validación 1:  Resultado esperado: El actor ProcesadorMensajesActor, al recibir el mensaje IniciarProceso debe enviar el mensaje “Validar”.  Resultado obtenido: Exitoso. El actor de prueba recibe el mensaje “Validar”. Validación 2:  Resultado esperado: El actor ProcesadorMensajesActor, al recibir el mensaje MensajeValidadoExitoso, debe enviar el mensaje “Guardar”.  Resultado obtenido: Exitoso. El actor de prueba recibe el mensaje “Guardar”. Validación 3:  Resultado esperado: El actor ProcesadorMensajesActor, al recibir el mensaje MensajeGuardadoExitoso debe enviar el mensaje “Notificar”.  Resultado obtenido: Exitoso. El actor de prueba recibe el mensaje “Notificar”. Validación 4:  Resultado esperado: El actor ProcesadorMensajesActor, al recibir el mensaje ProcesoNotificadoExitoso, debe detenerse.  Resultado obtenido: Exitoso. El actor ProcesadorMensajesActor se detiene.. Las pruebas se programan y ejecutan utilizando las JUnit y SacalaTest. La siguiente imagen corresponde a la lectura del reporte de las pruebas:. 32.

(33) Figura 6. Reporte pruebas unitarias de la prueba de concepto Fuente: El Autor.. 2.1.2. Características utilizadas del modelo de actores y el Toolkit Akka Máquina Finita de Estados (FSM). Una FSM es un modelo abstracto que consiste en un número finito de estados y eventos de entrada. Cuando el programa se encuentra en cada estado, puede recibir ciertos eventos. Cuando un evento llega y la máquina está en cierto estado, el programa ejecuta algunas acciones predeterminadas asociadas con ese estado y las transiciones a un nuevo estado; en este, se espera un nuevo evento. (Cesarini, Thompson, & Vinoski, 2015, pág. 110) Basado en esta lógica, el Toolkit Akka permite implementar una Máquina Finita de Estados. La Figura 7 representa la implementación en Akka.. Figura 7. Representación de una FSM en el Toolkit Akka. Fuente: (Suraj Atreya, 2016, pág. sp). 33.

(34) Una FSM se compone de tres elementos: estado, datos y eventos. El estado y los datos son propios de la máquina y los eventos generan dinámica. La implementación utilizada es una abstracción de un actor que adquiere características de una FSM. Con la combinación de colas de mensajes y la inmutabilidad se protege el estado de la FSM. Componentes de un Actor. La Figura 7 es una representación de las interacciones de los diferentes componentes que implementa el Toolkit Akka para ofrecer un Modelo de Actores:. Figura 8.Vista de los componentes de la implementación de actores en el Toolkit Akka. Fuente: (Wyatt, 2013, pág. 93). Los componentes involucrados son: Actor, Mailbox, Dispatcher y ActorRef.. Cuando se envía un mensaje al actor, realmente se envía al ActorRef. Este se encarga de enlazar al Dispatcher para poner el mensaje en el Mailbox del actor. Una vez realizado esto, el Dispatcher agrega el Mailbox a un hilo y en su ejecución se envía al actor. Propiedades de un Actor. A continuación se listan las propiedades más importantes sobre el concepto de un actor:. 34.

(35) . Entidades activas. Los Actores son objetos vivos, por esto son buenos modelando dominios que representan escenarios activos (Wyatt, 2013).. . Un proceso a la vez. Un actor puede ejecutar un proceso a la vez y liberarse. Es decir, un actor está diseñado para recibir un mensaje en secuencia. Esto permite, que, incluso trabajando bajo condiciones de alta concurrencia, el actor no sea afectado por esa concurrencia.. . Los actores están protegidos. Relacionado con la característica anterior, el actor trabaja de forma aislad, y no se ve afectado por otros comportamientos.. . Los actores están referenciados: Un actor tiene una ruta y esta actúa como una referencia; por lo tanto, si se conoce la ruta, entonces se puede enviar un mensaje.. Ciclo de vida del Actor.. Figura 9 Ciclo de Vida del Actor. Fuente: (Typesafe Inc, 2016). 35.

(36) Un path en un sistema de actores representa un lugar, que va a ser ocupado por un actor. Cuando actorOf es llamado el asigna un espacio y otras características. Básicamente, el actor es identificado por un path y un UID. El reinicio, solo refresca la instancia del Actor pero el UID se mantiene. (Typesafe Inc, 2016) El ciclo de vida termina cuando el actor es detenido. En ese caso, los eventos del ciclo de vida son llamados y los actores observadores son notificados de la terminación. Luego de que la instancia es detenida, el path puede ser reutilizado. En este caso, el UID será diferente. Un actor puede ser detenido por él mismo, por otro actor o por el sistema de actores. (Typesafe Inc, 2016).. 2.2.. Diseño. Se pretende construir un diseño que cumpla con características reactivas (Responsivo, Resiliente, Elástico y Orientado a Mensajes). Dado lo anterior, a partir del siguiente diseño se profundiza en los componentes relacionados con un arquitectura reactiva.. Figura 10. Diseño del prototipo Fuente: El Autor.. 36.

(37) 2.2.1. Resiliencia. En apartados anteriores se ha mencionado cómo para que un sistema sea responsivo es necesario que esté preparado para las fallas. Estas deben ser contenidas de manera aislada dentro de cada componente, aplicando las técnicas según el problema esperado. Para cumplir esto, se establece dentro del diseño un esquema de supervisión para los componentes que realizan operaciones de negocio, en este caso: NotificadorActor, PersistenciaActor y ValidadorActor. También habíamos señalado que en Akka un actor puede ser creado por otro actor, esto, de inmediato, convierte al segundo en actor padre. En este sentido, el actor padre puede aplicar lo que Akka denomina: Parental Supervision. En esa supervisión se pueden aplicar las siguientes decisiones frente un fallo: . Reanudar el subordinado manteniendo su estado interno acumulado.. . Reiniciar el subordinado limpiando su estado interno acumulado.. . Detener el subordinado de forma permanente.. . Escalar el error al supervisor.. Asimismo, existen dos estrategias para aplicar una decisión: . One-For-One Strategy. . All-For-One Strategy. Lo anterior define la manera como se manejan los errores de los actores hijos, la frecuencia con la que se permiten los fallos y el tiempo de espera antes de que se vuelve a crear el actor hijo. Como su nombre lo indica, la estrategia de One-For-One significa que se aplica sólo al actor que falló. La estrategia All-For-One significa que la supervisión se aplica a todos los actores del mismo nivel. (Munish K. Gupta, 2012, pág. sp). La Figura 111, ilustra la diferencia entre las estrategias explicadas anteriormente:. 37.

(38) Figura 11. Estrategias de supervisión. Fuente: (Munish K. Gupta, 2012, pág. sp). Para el diseño en cuestión, se implementa la estrategia One-For-One aplicando la decisión según la excepción recibida:. Figura 12.Supervisión en el diseño del prototipo Fuente: El Autor.. Se realiza una clasificación definida por tres tipos de error:  Error retornado por el Servicio  Error de conexión.  Error interno no controlado. 38.

(39) Para cada uno de los errores se define una decisión que aplicará el Actor Supervisor incluso cuando el máximo de reinicios permitidos se cumpla:  Error retorna servicio: Escalar  Error de conexión: Reiniciar  Error Interno: Detener  Máximo reintentos cumplidos: Detener. 2.2.2. Elasticidad. Para que un sistema sea responsivo, es necesario que atienda de manera sencilla a las variaciones de carga de la aplicación, por esta razón, debe tener la capacidad de escalar. Una aplicación puede hacerlo de dos maneras: Verticalmente y Horizontalmente. La primera, hace referencia al incremento de recursos de máquina (memoria, cpu, red); la segunda, a la distribución de tales recursos a través de la red y servidores. Respecto al crecimiento vertical, los Actores de Akka son configurables; es decir, se puede definir la cantidad de hilos que se van a utilizar para la creación y la operación de actores. Por otro lado, se estima que un actor en memoria ocupa alrededor de 300 bytes. Respecto al crecimiento horizontal, el diseño inicial determina que no existe un estado que mantener; esto permite agregar múltiples nodos sin mayor impacto, donde finalmente cada instancia expone un servicio Http. Para distribuir la carga entre estos, se puede utilizar fácilmente un software como Haproxy o un balanceador por Hardware. Sin embargo, se debe considerar un escenario como el que se expone a continuación:. Inicia una transacción a través del ProcesadorServices y la notificación del resultado se realizará mediante ProcesadorMensajesService. Se tienen instaladas dos instancias de la aplicación: Nodo1 y Nodo2. ¿Qué sucede entonces si la petición inicia por el Nodo1 y la conexión al notificador se realizó por el Nodo2?. ¿Cómo logra enterarse un nodo adyacente del resultado de una. operación que inició en otro nodo?. Para dar solución a este problema y cumplir con el propósito de elasticidad, el diseño prevé implementar un bus de eventos de manera distribuida. Para este propósito Akka. 39.

(40) provee el método Publish-Subscribe Channel, el cual es posible configurar para que soporte interacciones remotas. Antes de detallar la solución expuesta en el diseño, vale la pena resaltar los tipos de canales relacionados con los patrones de mensajería y el modelo de actores, según lo descrito por Vaughn Vernon (2015, pág. 149):. . Point-to-Point Channel. Es el método principal del modelo de actores. Este patrón demuestra el ordenamiento de mensajes y cómo los actores están preparados para recibir y enviar mensajes basados en su estado interno.. . Publish-Subscribe Channel: Un actor publica un mensaje que puede ser enviado a múltiples actores que estén suscritos a un canal. Este método puede ser aplicado de manera local o remota. . Datatype Channel: Un actor que está preparado para recibir un tipo específico de mensaje, puede rechazar cualquiera diferente sin interesar su contenido.. . Invalid Message Channel: Cuando un actor recibe un mensaje, y no está preparado para atenderlo, reenvía el mensaje a este canal.. . Dead Letter Channel: Si un mensaje se envía a un actor y este se encuentra detenido o no puede recibir el mensaje, entonces, el mensaje es enviado a este canal.. . Guaranteed Delivery: El modelo de actores no garantiza de manera natural la entrega de mensajes. La entrega se establece como "máximo una vez".. . Channel Adapter: Un mensaje puede ser recibido por un actor obsoleto, en ese caso, el mensaje puede enviarse a este canal para que se le dé tratamiento y se reenvíe.. . Message Bridge: Puede usarse cuando dos aplicaciones deben integrarse pero su sistema de mensajes no es interoperable.. . Message Bus: Es uno de los más complejos, pero muy útil en los sistemas empresariales. Pueden existir diferentes aplicaciones con esquemas de mensajes diferentes publicando mensajes a través de un bus que todas conozcan. Así logran integrarse de manera transparente.. El modelo utilizado en el diseño es: Publish-Subscribe Channel. 40.

(41) Figura 13. Modelo Publish-Subscribe Channel local Fuente: (Vernon, 2015, pág. 155). Básicamente, un actor puede publicar un mensaje a través de un bus de eventos a múltiples suscriptores. Esto se puede realizar de manera local o remota. La forma local corresponde a la descrita en la Figura 13 y se encuentra, también, en el esquema del diseño de la Figura 10. La siguiente figura describe el esquema remoto:. Figura 14. Modelo Publish-Subscribe Channel remoto Fuente: (Vernon, 2015, pág. 160).. 41.

(42) Este tipo de canal, Publish-Subscribe, proporciona los medios para publicar un mensaje a múltiples suscriptores en los nodos de un cluster. (Vernon, 2015, pág. 160) De acuerdo a la descripción anterior sobre el tipo de canal y el método a utilizar para enviar mensajes a través de diferentes nodos, y si se tiene en cuenta que esto equivale a escalar de manera horizontal, entonces, el bus de eventos incluido en el diseño se configura para que este en la capacidad de recibir y enviar mensajes a diferentes nodos.. 2.2.3. Orientación a mensajes (message-driven). Una arquitectura orientada a mensajes forma parte fundamental de las aplicaciones reactivas. Una aplicación message-driven puede estar orientada a eventos, basada en actores o una combinación de las dos. La diferencia entre los eventos y los mensajes, básicamente radica en que los mensajes se envían de manera directa y los eventos suceden. Las aplicaciones basadas en actores se basan en el paso asíncrono de mensajes. Como se ha venido mencionando, cada actor tiene un buzón de mensajes, maneja el estado de manera aislada y puede enviar mensajes a otros actores o a sí mismo. Un gran beneficio de la concurrencia basada en los actores es que el escalamiento a través de la red se hace de manera sencilla. Esto ocurre porque los mensajes son dirigidos a los actores. Este poderoso concepto hace que resulte fácil construir aplicaciones escalables. (Suraj Atreya, 2016, pág. sp) Por lo tanto, el diseño planteado basado en actores es, por definición, orientado a mensajes.. 2.2.4. Responsividad. Este elemento de las aplicaciones reactivas, es un factor crucial para asegurar positivamente la experiencia de usuario o de sistema consumidor. Por tal motivo, el sistema debe estar preparado para diferentes situaciones y lo logra a través de los tres elementos mencionados anteriormente: Resiliencia, Elasticidad y Orientación a Mensajes. Con esto, podemos concluir que el diseño para el prototipo propuesto es reactivo.. 42.

(43) 3.. DESARROLLO. De acuerdo al diseño establecido, se realiza el desarrollo implementando las tecnologías ampliamente referenciadas en este documento. Para describir el desarrollo y verificar su correcta aproximación al diseño, se utiliza el Modelo de Vistas 4+1 propuesto por Philippe Kruchten (Kruchten, 1995): . Vista lógica: Se concentra en la funcionalidad que el sistema provee a los usuarios finales u otros sistemas.. . Vista de Desarrollo: Ilustra el sistema desde la perspectiva de programadores. Está enfocada en la administración y la mantenibilidad del software.. . Vista de procesos: Se concentra en los aspectos dinámicos del sistema, explica el proceso y su comunicación.. . Vista Física: Detalla la topología del sistema mostrando sus componentes y conexiones en una capa física.. . 3.1.. Escenarios: Describen la interacción general del sistema.. Vista Lógica. La Figura 15 ilustra la vista lógica del desarrollo y muestra sus componentes principales. Se enfoca en los servicios que se exponen: . Procesador de mensajes. . Monitoreo -. Procesos. -. Verificación. -. Persistencia. -. Notificación. 43.

(44) Figura 15. Vista lógica Fuente: El Autor.. Con el uso del componente Akka-Http se exponen los servicios que son agrupados por el Enrutador. Cada uno de estos servicios utiliza una serie de componentes de acuerdo a su comportamiento.. 3.2.. Vista de Desarrollo. Enfocada en la perspectiva de desarrollo, la Figura 16 ilustra los actores y supervisores que soportan el comportamiento de los servicios expuestos.. 44.

(45) Figura 16. Vista de Desarrollo Fuente: El Autor.. La agrupación de los actores y supervisores se puede ver de la siguiente manera: . Actores o. Lógica de negocio -. Procesador de mensajes. -. Notificador. -. Persistencia. -. Validador. 45.

(46) o. . Monitoreo -. Monitor de Transacción. -. Monitor de notificaciones. -. Monitor de Persistencia. -. Monitor de Validación. Supervisores o. Procesador de mensajes. o. Notificador. o. Persistencia. o. Validador. En el caso de los actores de Persistencia y Notificación se evidencia la interacción con otros sistemas: . MongoDB: Base de datos no relacional. La única operación que se realiza es la inserción de registros.. . SMTP. Envío simple de correos a cuentas dentro de un mismo dominio.. Dentro de este prototipo, el propósito de estos componentes externos es generar un comportamiento de uso de recursos, para luego evaluar el rendimiento de los actores.. 3.3.. Vista de Proceso. La vista ilustrada en la Figura 17 pretende mostrar el proceso de ejecución cuando se inicia una transacción con el envío de un mensaje por el servicio de Procesador de Mensajes. Ocurre de la misma manera cuando se abre conexión con los servicios de Monitoreo.. 46.