Esta página es de solo lectura. Puedes ver la fuente pero no puedes cambiarla. Pregunta a tu administrador si crees que esto es incorrecto.

<h1>Documento visión de SIMO y recomendaciones</h1> <div class="level1"> </div> <h2>Introducción</h2> <div class="level2"> <p> El presente documento es fruto del análisis del estado del sistema SIMO a la fecha en que es escrito (Octubre de 2017) con el objeto de realizar recomendaciones a corto, mediano y largo plazo y plasmar una visión a futuro. La organización del mismo es un reflejo de la prioridad e inmediatez de las recomendaciones a juicio del autor, por tanto se compone de cuatro secciones: Recomendaciones de alta prioridad, de corto plazo, de mediano plazo y largo plazo. Adicionalmente, cada recomendación incluye una descripción de su naturaleza, una estimación de la dificultad asociada a la misma, el impacto esperado y sugerencias de implementación. </p> </div> <h2>Recomendaciones de alta prioridad</h2> <div class="level2"> </div> <h3>Protección CSRF</h3> <div class="level3"> <p> <b>Dificultad: Media Impacto: Alto Tipo: Seguridad Responsables: Desarrollo/Infraestructura </b> </p> <p> Los ataques CSRF (Cross Site Request Forgery) están entre los ataques más comunes a sitios WEB. El framework Spring proporciona mecanismos de defensa genéricos contra este tipo de ataques, sin embargo, estos mecanismos requieren de código específico para poderlos aprovechar, (especialmente en el contexto de una aplicación con arquitectura REST, javascript y Ajax como la es SIMO). Para implementar la protección CSRF se recomienda entonces: </p> <ol> <li class="level1"> Revisar las políticas CORS (Cross Origin Resource Sharing) para que sean lo más estrictas posibles (No permitir peticiones de otros sitios), esta revisión puede requerir la implementación de https a nivel de Tomcat en cada uno de los nodos, lo cual también es una buena práctica. </li> <li class="level1"> Activar protección CSRF en la configuración de seguridad de SIMO (<a href="/cnscwiki/doku.php?id=simo:documentos:tecnicos:securityconfig" class="wikilink2" title="simo:documentos:tecnicos:securityconfig" rel="nofollow">SecurityConfig</a>.java)</li> <li class="level1"> Implementar un mecanismo de envío de token CSRF genérico en javascript (extendiendo, interceptando o modificando el código AJAX de Dojo Toolkit para envío de peticiones PUT, POST y DELETE, y opcionalmente GET. Esta modificación puede realizarse a nivel del módulo dojo/request o en algún punto cercano.</li> <li class="level1"> Cambiar el mecanismo de sesión del tradicional de J2EE a Spring Session, esto permite eliminar el sistema de Cookies (JSESSIONID) y reemplazarlo por un header http personalizado, a su vez facilita la interacción con el cliente móvil. Este cambio a Spring Session puede ir acompañado mediante el uso de un servidor REDIS para almacenar datos de sesión distribuidos (en el caso de SIMO es apropiado al contar con una infraestructura de tipo cluster). El uso de este servidor Redis eliminaría la dependencia del firewall para manejar sesiones pegadizas (sticky sessions) y permitiría a su vez implementar cachés de servidor compartidos entre nodos e índices Lucene compartidos (ver más adelante la recomendación (Implementar servidor REDIS)</li> </ol> </div> <h3>Limpieza de archivos y recursos</h3> <div class="level3"> <p> <b>Dificultad: Baja Impacto: Medio Tipo: Eficiencia y escalabilidad Responsables: Infraestructura</b> </p> <p> El modelo de datos del sistema, construido con base en el requerimiento funcional de tener que registrar exactamente los documentos con los que un ciudadano aplica a una convocatoria, hace que el sistema produzca registros y archivos huérfanos, es decir, que no están relacionados a ningún ciudadano ni a ninguna inscripción. Estos registros huérfanos y archivos huérfanos pueden ser eliminados de la base de datos y del file system, ahorrando espacio e incluso tiempos de procesamiento. Adicionalmente se sugiere revisar periódicamente los directorios temporales y las tablas temporales y eliminarlas sistemáticamente, en particular el directorio stage en el repositorio SIMO. Se sugiere la creación de scripts automatizados que sean ejecutados periódicamente mediante un agendador (por ejemplo cron) en horas de baja concurrencia. </p> </div> <h3>Compresión GZIP</h3> <div class="level3"> <p> <b>Dificultad: Baja Impacto: Alto Tipo: Eficiencia y escalabilidad Responsables: Infraestructura</b> </p> <p> La compresión GZIP en HTTP permite comprimir las respuestas HTTP para luego descomprimirlas en el navegador. Este cambio puede reducir el consumo de ancho de banda enormemente, y de hecho, en el momento ya se implementó para todos los archivos de texto con gran éxito, pero se sugiere evaluar si es posible implementarlo también con datos y sobre todo con los archivos pdf (documentos). </p> </div> <h3>Creación y mantenimiento de índices de base de datos</h3> <div class="level3"> <p> <b>Dificultad: Media Impacto: Alto Tipo: Eficiencia y escalabilidad Responsables: Infraestructura</b> </p> <p> Es necesario monitorear las consultas producidas por el sistema y catalogarlas según su frecuencia y duración. Aquellas más costosas (teniendo en cuenta ambos factores) deben ser revisadas y optimizadas. Se sugiere que como primera medida se informe a los desarrolladores sobre las mismas a ver si es posible y es conveniente realizar una optimización a nivel de código (utilizando <a href="/cnscwiki/doku.php?id=simo:documentos:tecnicos:jsonview" class="wikilink2" title="simo:documentos:tecnicos:jsonview" rel="nofollow">JsonView</a>, Join Fetch o simplemente reescribiendo algoritmos). Aquellas que no sean optimizadas en código deben ser optimizadas en base de datos mediante el análisis de ejecución de las mismas, utilizando herramientas como explain. A las consultas en las cuales se identifique que se está haciendo recorrido secuencial de tablas se les deben crear índices adecuados. Es importante que este tipo de análisis se lleve a cabo de manera periódica sobre el código desplegado, pero que también que se integre al proceso de despliegue de nuevas versiones junto con pruebas de stress que ayuden a producir las estadísticas de consultas necesarias. Adicionalmente se deben llevar a cabo las labores de mantenimiento de índices ya existentes y los demás afinamientos que se encuentren pertinentes por parte del equipo de infraestructura. Se sugiere en este caso revisar los parámetros de operación de postgres (a nivel de sistema operativo, de motor de base de datos y de la base de datos en sí) </p> </div> <h3>Replicación multimaster</h3> <div class="level3"> <p> <b>Dificultad: Alta Impacto: Alto Tipo: Eficiencia y escalabilidad Responsables: Infraestructura</b> </p> <p> El cluster de base de datos de SIMO se basa actualmente en dos tecnologías complementarias </p> <ul> <li class="level1"> <a href="/cnscwiki/doku.php?id=simo:documentos:tecnicos:pgpool" class="wikilink2" title="simo:documentos:tecnicos:pgpool" rel="nofollow">PgPool</a> (Balanceo de carga)</li> <li class="level1"> Streaming Replication (Consistencia de datos entre nodos)</li> </ul> <p> La replicación es imprescindible en este esquema de cluster puesto que el balanceador de cargas debe poder redirigir las operaciones de base de datos a cualquiera de los nodos del cluster y en consecuencia todos deben presentar una versión consistente de los datos (todos los nodos deben contener los mismos datos). El sistema de replicación actual ha funcionado hasta el momento debido a que cuenta con una buena velocidad de transferencia, sin embargo, este tipo de replicación es más apto para alta disponibilidad que para balanceo de cargas, sobretodo por el hecho de que solo permite un nodo maestro (aquel que recibe las operaciones de escritura). Se propone implementar un sistema de replicación multimaster basado en Postgres BDR el cual potencialmente puede mejorar el desempeño de la infraestructura debido a las siguientes razones: </p> <ol> <li class="level1"> Replicación asincrónica: Al igual que en Streaming Replication, este sistema realiza replicación asincrónica con lo cual se logran buenos tiempos de respuesta sin afectar el rendimiento de la operación de escritura original puesto que la replicación se realiza después del commit de la operación original</li> <li class="level1"> Replicación multimaster: Lo cual permitiría escribir en diferentes nodos. En la configuración actual es necesario escribir en el único nodo maestro, al tener varios nodos de escritura es posible crear esquemas de balanceo y replicación mucho más flexibles.</li> <li class="level1"> Replicación selectiva: Es posible configurar que se va a replicar, en este sentido se puede evitar la replicación de datos sin valor como las tablas temporales (lo cual ayudaría mucho a la ejecución de procedimientos almacenados), también se puede determinar que ciertas tablas no necesitan ser replicadas en tiempo real y posponer su replicación para un momento posterior (cuando haya baja concurrencia de usuarios)</li> <li class="level1"> Topología: Es posible crear esquemas de replicación en donde solo se replican ciertas tablas a ciertos nodos, esta característica resulta muy útil puesto que permite aprovechar el despliegue modular de SIMO, por ejemplo, se puede configurar para que las operaciones de los servidores IES escriban a un nodo de base de datos IES y este replique solamente a los otros nodos IES, sin necesidad de replicar inmediatamente a los nodos de ciudadano, esto es posible hacerlo teniendo en cuenta que los ciudadanos no requieren inmediatamente la información producida por las Universidades sino hasta el momento de hacer publicación de resultados.</li> </ol> </div> <h3>Pruebas de stress</h3> <div class="level3"> <p> <b>Dificultad: Baja Impacto: Alto Tipo: Eficiencia y escalabilidad Responsables: Pruebas/Infraestructura</b> </p> <p> Es necesario incorporar pruebas de stress como parte del ciclo de despliegue de SIMO, estas pruebas a su vez pueden generar la información temprana para realizar optimizaciones tempranas. Las pruebas de stress deben ser realizadas con cierta racionalidad, por ejemplo, no es realista disparar muchas peticiones simultáneas, sino que se debe generar una cantidad en un periódo de tiempo de acuerdo al comportamiento observado en producción. Por ejemplo, para probar la funcionalidad de verificación de requisitos mínimos no es razonable disparar 100 secuencias de calificación al tiempo, pero si lo es disparar 100 secuencias en 5 minutos, que podría corresponder a 100 analistas calificando simultáneamente. Finalmente, nótese que las pruebas de stress deben estar acompañadas herramientas de monitoreo, como logs de consultas, monitoreo de consumo de ancho de banda, memoria y procesador. </p> </div> <h3>Directivas de cache</h3> <div class="level3"> <p> <b>Dificultad: Media Impacto: Alto Tipo: Eficiencia y escalabilidad Responsables: Desarrollo/Infraestructura</b> </p> <p> En el momento, SIMO no permite que el contenido estático, es decir HTML, Javascript y CSS pueda ser almacenado en el caché de los navegadores cliente. Cuando un navegador almacena contenido estático, se reduce el consumo de ancho de banda puesto que no necesita volver a solicitar este contenido al servidor, el problema que puede surgir es que el navegador decida usar una versión obsoleta del contenido estático, problema particularmente peligroso en el caso de código Javascript. Un servidor no puede obligar a un navegador a almacenar contenido estático, (por ejemplo, un navegador en modo privado no almacena nada), sin embargo, las peticiones HTTP pueden incluir directivas de caché que indican al navegador si el contenido estático que está descargando está actualizado y si pueden ser almacenado por parte del navegador. Al momento de escribir este documento, el sistema SIMO envía directivas que indican a los navegadores que no deben almacenar el contenido estático, en consecuencia es necesario descargarlo cada vez que se necesita (lo cual ocurre cada vez que se navega a la página de bienvenida del sistema), esto aumenta considerablemente el consumo de ancho de banda y el procesamiento de los servidores Tomcat. Con base en esto se recomienda entonces: </p> <ol> <li class="level1"> Habilitar directiva cache-control para permitir almacenamiento de contenido estático</li> <li class="level1"> Utilizar tiempos de expiración max-age concordantes con los tiempos de despliegue</li> <li class="level1"> Combinar esta estrategia con minificación y versionamiento javascript (ver más adelante) para garantizar que se descargue un nuevo archivo minificado al existir un nuevo despliegue, de esta forma, el único recurso con directivas de caché sería el archivo unificado, por otro lado, index.html nunca debería ser almacenado (no importa porque es muy pequeño) y al contener la petición que descarga el archivo unificado, esta petición cambiaría de acuerdo a la versión de despliegue SIMO mediante un parámetro de versión.</li> <li class="level1"> Recomendaciones a corto plazo</li> </ol> </div> <h3>Análisis de vulnerabilidades</h3> <div class="level3"> <p> <b>Dificultad: Media Impacto: Medio Tipo: Seguridad Responsables:Infraestructura</b> </p> <p> Se recomienda realizar un análisis de vulnerabilidades o prueba de penetración orientado a aplicaciones Web basadas en arquitectura REST, javascript y Ajax, una posible herramienta para realizar este análisis es <a href="/cnscwiki/doku.php?id=simo:documentos:tecnicos:backtrack" class="wikilink2" title="simo:documentos:tecnicos:backtrack" rel="nofollow">BackTrack</a>. </p> </div> <h3>Revisión de log de auditoría</h3> <div class="level3"> <p> <b>Dificultad: Baja Impacto: Medio Tipo: Seguridad Responsables: Desarrollo/Infraestructura</b> </p> <p> Se recomienda realizar una revisión sistemática del log de auditoría en cuanto a que todos los servicios y controladores deben tener por lo menos una instrucción que escriba en log cuando se ingresa a un método y cuando se sale del mismo. Es posible implementar fácilmente algo genérico utilizando un aspecto, y además se pone a consideración del equipo de infraestructura, la habilitación del log a nivel de INFO teniendo en cuenta los requerimientos de espacio que consume este log. En opinión del autor, el consumo de espacio en disco es justificado por la traza de auditoría que se obtiene. Adicionalmente se sugiere incluir en las líneas de auditoría el usuario autenticado y el servidor tomcat que produce el log. </p> </div> <h3>Uso de JsonViews</h3> <div class="level3"> <p> <b>Dificultad: Alta Impacto: Bajo Tipo: Eficiencia y escalabilidad Responsables: Desarrollo</b> </p> <p> El uso de <a href="/cnscwiki/doku.php?id=simo:documentos:tecnicos:jsonview" class="wikilink2" title="simo:documentos:tecnicos:jsonview" rel="nofollow">JsonView</a> en los controladores de la aplicación reduce el consumo de ancho de banda al serializar solo los datos necesarios, pero aún más importante, reduce el número de consultas a base de datos (Cuando está acompañada con carga de entidades en modo LAZY). En específico, las <a href="/cnscwiki/doku.php?id=simo:documentos:tecnicos:jsonview" class="wikilink2" title="simo:documentos:tecnicos:jsonview" rel="nofollow">JsonView</a> minimizan el problema de consultas n+1, caracterizado por el hecho de que cargar una entidad produce una consulta básica más una más por cada entidad asociada mediante una relación cuyo Fetch Mode es de tipo Select. Si bien este tipo de ajuste tiene un impacto alto en la optimización, en este documento se marca como bajo porque ya se han realizado la mayoría de ajustes de este tipo y solo resta hacer una revisión más sistemática del código. Adicionalmente, no se espera mucha mejoría puesto que el impacto de esta optimización también depende del número de operaciones que se invoquen, y esto depende directamente del número de usuarios concurrentes, es decir, que el código que más podría mejorar es el asociado al perfil del ciudadano, que tiene una cantidad de usuarios vastamente mayor al de los otros módulos, sin embargo, este módulo ya ha sido optimizado previamente y solo se podrían encontrar puntos de optimización en los últimos desarrollos. Es ahí entonces, donde se deben centrar las actividades de análisis y corrección. </p> </div> <h3>Uso de Join Fetch</h3> <div class="level3"> <p> <b>Dificultad: Alta Impacto: Bajo Tipo: Eficiencia y escalabilidad Responsables: Desarrollo</b> </p> <p> El uso de Join Fetch en consultas JPQL (Como aquellas definidas en los repositorios SIMO) puede optimizar la carga de entidades al reducir el número de consultas precargando entidades asociadas y minimizando de esta forma el problema de consultas n+1. Nótese que esta optimización sólo es posible en las consultas JPQL y por tanto se debe analizar consulta por consulta haciéndolo un proceso engorroso y susceptible al error. Al igual que con la optimización de <a href="/cnscwiki/doku.php?id=simo:documentos:tecnicos:jsonview" class="wikilink2" title="simo:documentos:tecnicos:jsonview" rel="nofollow">JsonView</a>, se espera un impacto bajo por las razones expuestas anteriormente. </p> </div> <h3>Minificación y Versionamiento Javascript</h3> <div class="level3"> <p> <b>Dificultad: Alta Impacto: Bajo Tipo: Eficiencia y escalabilidad Responsables: Desarrollo</b> </p> <p> Una de las técnicas para reducir los tiempos de carga de la aplicación asociados a la transmisión vía internet es la compilación y minificación de javascript. La idea es llevar a cabo dos procesos complementarios: el primero es reducir el número de peticiones HTTP unificando los archivos Javascripts y de recursos en uno solo o en la menor cantidad posible, el segundo es reducir el tamaño de este archivo único eliminando espacios en blanco y con otras técnicas llamadas de minificación. Esta optimización ya se realizó parcialmente con éxito más sin embargo se pueden llevar a cabo las siguientes mejoras: </p> <ol> <li class="level1"> Incluir archivos de recursos html y css en la compilación del archivo único para reducir aún más el número de peticiones HTTP</li> <li class="level1"> Actualmente el máximo nivel de minificación es eliminar espacios en blanco, este nivel puede aumentarse al siguiente que es sustituir nombres de variables javascript, para ello es necesario alterar el código de minificación para que tenga en cuenta los archivos HTML que contienen referencias a variables Javascript, este proceso es bastante complejo y puede tomarse mucho tiempo.</li> <li class="level1"> Una vez se obtenga un archivo unificado, es posible asociar una versión al mismo, que puede ser igual a la versión de SIMO desplegada, el manejar esta versión en la petición HTTP que envía el archivo unificado al navegador puede permitir el uso de directivas de caché de forma segura (ver siguiente recomendación), evitando que se carguen versiones obsoletas.</li> </ol> </div> <h3>Reingeniería a sistema de notificaciones y citaciones</h3> <div class="level3"> <p> <b>Dificultad: Alta Impacto: Alto Tipo: Eficiencia y escalabilidad Responsables: Desarrollo</b> </p> <p> Se requiere realizar una reimplementación al sistema de notificaciones que ataque los siguientes puntos: </p> <ol> <li class="level1"> Rendimiento: La implementación del sistema de notificaciones actual no escaló al número de usuarios ciudadanos del sistema, en gran parte porque las técnicas utilizadas no son las óptimas, al igual que otros procesos intensivos en tratamiento de datos, como la publicación de resultados, es necesario reescribir la funcionalidad a nivel de base de datos mediante procedimientos almacenados y haciendo uso de trabajos asincrónicos (fuera de la máquina virtual de Java)</li> <li class="level1"> Citaciones: Se requiere implementar el sistema de citaciones usando el sistema de notificaciones, el modelo de datos actual del sistema de notificaciones no tiene la suficiente flexibilidad para soportar el sistema de citaciones.</li> </ol> <p> En el momento ya se tiene un diseño preliminar de la solución, es necesario concretar este diseño un poco más e implementarlo </p> </div> <h3>Actualización de librerías base</h3> <div class="level3"> <p> <b>Dificultad: Media Impacto: Medio Tipo: Arquitectura Responsables: Desarrollo/Pruebas</b> </p> <p> Las librerías Spring Boot y Dojo Toolkit se encuentran desactualizadas, se recomienda realizar una actualización a las últimas versiones, esto trae múltiples beneficios como: Corrección de bugs Nuevas capacidades y funcionalidades Seguridad Ajuste a las nuevas tecnologías Optimizaciones Según una evaluación previa, la actualización es muy transparente y no debe ocasionar mayores problemas, sin embargo, es indispensable realizar pruebas de regresión exhaustivas para garantizar que la actualización de librerías no afecte la correctitud del sistema. Por otro lado, también existen nuevas versiones de la librerías dgrid, sin embargo, esta nueva versión involucra que también se deba reemplazar el módulo dojo/store por la librería dstore, lo cual también hace necesario reescribir una muy buena parte del código Javascript, en consecuencia no se recomienda la actualización de esta librería a no ser que se haga en conjunto con la actualización del componente base <a href="/cnscwiki/doku.php?id=simo:documentos:tecnicos:simplecrud" class="wikilink2" title="simo:documentos:tecnicos:simplecrud" rel="nofollow">SimpleCrud</a> y sus clases de soporte. La actualización de este componente significa por sí misma una refactorización de la arquitectura del sistema, pero este tema se trata a mayor profundidad en una recomendación posterior. </p> </div> <h3>Revisión de indexamiento</h3> <div class="level3"> <p> <b>Dificultad: Baja Impacto: Medio Tipo: Mantenimiento Responsables: Desarrollo</b> </p> <p> SIMO cuenta con un sistema de indexamiento inverso basado en Hibernate Search y Lucene que le proporciona capacidades de búsqueda avanzada e inteligente, sin embargo, y con base en la experiencia adquirida tras su implementación, se observa que el indexamiento ha sido aplicado en porciones del código donde las necesidades de búsqueda no justifican la complejidad adicional impuesta por estas tecnologías. Es entonces que se recomienda revisar aquellas porciones de código que funcionan con indexamiento inverso y que no requieren de funcionalidades de búsqueda muy avanzadas y reemplazarlas por búsquedas tradicionales JPQL. En particular se recomienda revisar las funcionalidades asociadas a la entidad Convocatoria y si se determina que las funciones de búsqueda son lo suficiente simples para ser implementadas en JPQL (No necesita búsquedas inteligentes o por aproximación), entonces ajustar el controlador, servicio y repositorio respectivos para que implementen este tipo de búsqueda. El razonamiento tras esta recomendación es que dado que la entidad Convocatoria es central en el modelo de datos y tiene un gran nivel de transaccionalidad, el sistema de índices inversos y distribuidos impone un grado de complejidad que hace a la implementación muy susceptible al error. El anterior razonamiento puede ser extendido a otras entidades, pero no se recomienda eliminar el sistema de indexamiento puesto que resulta muy útil y eficiente por sobre todo en la funcionalidad de búsqueda de empleos, crítica para el ciudadano. </p> </div> <h2>Recomendaciones y desarrollos a mediano plazo</h2> <div class="level2"> </div> <h3>Visualización de pruebas escritas</h3> <div class="level3"> <p> <b>Dificultad: Media Impacto: Alto Tipo: Desarrollo Responsables: Desarrollo</b> </p> <p> La funcionalidad que permite a los aspirantes revisar sus exámenes escritos y confrontarlos contra las hojas de respuestas está proporcionada por un aplicativo separado, se recomienda integrar esta funcionalidad dentro de SIMO teniendo en cuenta que Se puede utilizar el sistema de autenticación existente Se puede integrar la funcionalidad al sistema de reclamaciones Es posible otorgar acceso a las hojas de respuesta en ventanas de tiempo específicas evitando cargas excesivas sobre el sistema, </p> </div> <h3>Cargue estructurado de preguntas y respuestas</h3> <div class="level3"> <p> <b>Dificultad: Media Impacto: Alto Tipo: Desarrollo Responsables: Desarrollo</b> </p> <p> El siguiente paso a desarrollar es crear una funcionalidad para cargar masivamente en el sistema las preguntas y respuestas de las pruebas escritas, el modelo de datos soporta parcialmente esta funcionalidad lo cual permitiría generar automáticamente el detalle de las pruebas escritas, complementando la visualización de hojas de respuestas del punto anterior. Más importante aún, es el hecho de poder realizar validaciones confrontando la calificación de la prueba y sus secciones contra las preguntas y respuestas del ciudadano. Para la implementación de esta funcionalidad se recomienda adoptar un estándar para la representación de pruebas de opción múltiple como QTI, el sistema SIMO recibiría los detalles de las pruebas de los ciudadanos en este estándar y podría integrar un visualizador que lo soportara. Las Universidades podrían utilizar sus propios sistemas de pruebas en línea dado que estos soportaran este estándar, o que se tuvieran herramientas de transformación que lo generaran. </p> </div> <h3>Pruebas virtuales</h3> <div class="level3"> <p> <b>Dificultad: Alto Impacto: Alto Tipo: Desarrollo Responsables: Desarrollo</b> </p> <p> El siguiente paso natural en esta línea de desarrollo, es integrar un sistema de pruebas virtuales al sistema, este sistema permitiría: Crear pruebas virtuales por parte de las Universidades Presentar pruebas por parte del ciudadano utilizando su usuario SIMO Obtener resultados preliminares de las pruebas inmediatamente tras su presentación e integrar estos resultados en la base de datos SIMO Almacenar pruebas en estándar QTI. </p> </div> <h3>Cachés de servidor distribuídos</h3> <div class="level3"> <p> <b>Dificultad: Baja Impacto: Medio Tipo: Arquitectura Responsables: Desarrollo/Infraestructura</b> </p> <p> En la actualidad el sistema SIMO cuenta con un sistema de almacenamiento en caché que proporciona enormes ganancias en rendimiento y relaja la carga sobre la base de datos. Estos cachés almacenan entidades JPA (objetos) en memoria, estas entidades se caracterizan por tener baja frecuencia de actualización y alta frecuencia de lectura. Actualmente, cada nodo del cluster SIMO tiene su propio caché desincronizado, esto produce que en algunos momentos los nodos presenten información inconsistente entre sí (un caché fue actualizado en un nodo pero no en los otros). Normalmente este problema se soluciona invalidando los cachés manualmente de modo que tengan que ser repoblados, sin embargo esta operación es manual y solo se realiza cuando se evidencian inconsistencias. Se recomienda entonces instalar un sistema de memoria distribuido como REDIS que proporciones una visión unificada de los cachés, este enfoque tiene las siguientes ventajas. Soportado transparentemente por el sistema de cachés de Spring Boot No necesita de mecanismos de replicación puesto que el servidor REDIS es desplegado en un solo nodo el cual es accedido por todos los nodos de SIMO a través de la red. Puede ser utilizado también para almacenar información de sesión evitando así depender de las sesiones pegadizas del firewall (Ver recomendación de CSRF) De muy fácil instalación y mantenimiento Puede ser utilizado también para almacenar índices Lucene (Ver siguiente recomendación) </p> </div> <h3>Directorios de índices Lucene</h3> <div class="level3"> <p> <b>Dificultad: Media Impacto: Bajo Tipo: Arquitectura Responsables: Desarrollo/Infraestructura</b> </p> <p> El sistema de búsqueda de SIMO, basado en Hibernate Search y Lucene, utiliza un concepto llamado Directorio para representar los mecanismos de almacenamiento de los índices invertidos Lucene. En la actualidad, el sistema SIMO utiliza directorios Infinispan locales a cada nodo del cluster, lo cual hace necesario que cuando haya una actualización de índices estos deban ser replicados manualmente a los otros nodos. En una primera instancia, se implementó un sistema distribuido Infinispan que mantenía sincronizados los índices, pero debido a la alta concurrencia y a que existían muchos más objetos indexados, este mecanismo fue desmontado en favor de los directorios Infinispan locales. Con el objeto de evitar la sincronización manual que actualmente se realiza, se recomienda adoptar alguna de las siguientes estrategias: Utilizar Infinispan respaldado por REDIS (Ver recomendación anterior). Al ser REDIS un servidor central no se tienen problemas de replicación de índices, puesto que cuando se actualiza un índice en un nodo, dicha actualización solo tiene que ser notificada al servidor REDIS y no a todos los otros nodos. Utilizar <a href="/cnscwiki/doku.php?id=simo:documentos:tecnicos:elasticsearch" class="wikilink2" title="simo:documentos:tecnicos:elasticsearch" rel="nofollow">ElasticSearch</a> como proveedor de los servicios de indexamiento, este enfoque minimiza la complejidad y es muy configurable y manejable pero reduce un poco el desempeño puesto que todo el sistema de indexamiento queda centralizado en un servidor central y es necesario acceder a las funciones de búsqueda a través de la red. Utilizar índices en <a href="/cnscwiki/doku.php?id=simo:documentos:tecnicos:filesystem" class="wikilink2" title="simo:documentos:tecnicos:filesystem" rel="nofollow">FileSystem</a> con replicación automática y preferiblemente utilizando una implementación en memoria como <a href="/cnscwiki/doku.php?id=simo:documentos:tecnicos:mmapdirectory" class="wikilink2" title="simo:documentos:tecnicos:mmapdirectory" rel="nofollow">MMapDirectory</a> para evitar el acceso continuo a disco. </p> </div> <h3>Sistema de archivos distribuido</h3> <div class="level3"> <p> <b>Dificultad: Media Impacto: Medio Tipo: Infraestructura Responsables:Infraestructura</b> </p> <p> Se recomienda cambiar el sistema de archivos distribuido actual basado en NFS por uno más moderno y eficiente, en particular se recomienda GFS, por su afinidad con CENTOS </p> </div> <h3>Actualización sistema PSE</h3> <div class="level3"> <p> <b>Dificultad: Media Impacto: Bajo Tipo: Mantenimiento Responsables:Desarrollo</b> </p> <p> Actualmente, el sistema de pagos en línea por PSE está implementado con controladores y servicios específicos, se recomienda por uniformidad de la aplicación, volver a escribirlo utilizando el sistema de trabajos fuera de línea. </p> </div> <h3>Recomendador</h3> <div class="level3"> <p> <b>Dificultad: Alta Impacto: Medio Tipo: Desarrollo Responsables:Desarrollo</b> </p> <p> Se propone implementar un recomendador basado en inteligencia artificial que sugiera empleos a los ciudadanos basados en su hoja de vida (estudios, experiencia laboral) y/o en empleos escogidos por ciudadanos con características similares. Para crear este sistema se debe Escoger un modelo de aprendizaje, es decir, el algoritmo y los datos Entrenar el modelo y validar Implementar algoritmo en producción y enlazarlo a la interfaz de usuario Por eficiencia es mejor calcular las recomendaciones en horas de baja concurrencia y solo hacerlo para los ciudadanos que hayan habilitado la función de recomendación. También es importante implementar una encuesta donde los ciudadanos califiquen si las recomendaciones han sido útiles y utilizar esta calificación como dato de aprendizaje </p> </div> <h2>Recomendaciones y desarrollos a largo plazo</h2> <div class="level2"> </div> <h3>Integración con Orfeo</h3> <div class="level3"> <p> <b>Dificultad: Medio Impacto: Medio Tipo: Desarrollo Responsables:Desarrollo-Desarrollo Orfeo</b> </p> <p> Se recomienda implementar una integración entre Orfeo y el sistema de reclamaciones de SIMO de tal forma que: Al radicar una PQR referente a SIMO en Orfeo se despliegue un formulario especial que cree una reclamación SIMO por medio de una URL REST Al contestar una reclamación SIMO se actualice la respuesta al radicado original en ORFEO </p> </div> <h3>Integración con BNLE</h3> <div class="level3"> <p> <b>Dificultad: Baja Impacto: Alta Tipo: Desarrollo Responsables:Desarrollo-Desarrollo BNLE</b> </p> <p> Se recomienda implementar una integración entre SIMO y BNLE de tal forma que: Al terminar una convocatoria, BNLE invoque una URL REST por medio de la cual obtenga la lista de elegibles y la cargue en su propia base de datos </p> </div>