Diferencias

Muestra las diferencias entre dos versiones de la página.

--- simo:documentos:tecnicos:recomendaciones [2017/11/14 20:59]
lgomez
+++ simo:documentos:tecnicos:recomendaciones [2017/11/14 21:26] (actual)
lgomez [Integración con Orfeo]
@@ Línea 6: / Línea 6: @@
 ===== Recomendaciones de alta prioridad =====
 ==== Protección CSRF ====
-Dificultad: Media
+**Dificultad: Media
 Impacto: Alto
 Tipo: Seguridad
 Responsables: Desarrollo/Infraestructura
+**
 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:
-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.
+  - 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.
-Activar protección CSRF en la configuración de seguridad de SIMO  (SecurityConfig.java)
+  - Activar protección CSRF en la configuración de seguridad de SIMO  (SecurityConfig.java)
-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.
+  - 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.
-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)
+  - 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)
 ==== Limpieza de archivos y recursos ====
-Dificultad: Baja
+**Dificultad: Baja
 Impacto: Medio
 Tipo: Eficiencia y escalabilidad
-Responsables: Infraestructura
+Responsables: Infraestructura**
 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.
-===== Compresión GZIP =====
+==== Compresión GZIP ====
-Dificultad: Baja
+**Dificultad: Baja
 Impacto: Alto
 Tipo: Eficiencia y escalabilidad
-Responsables: Infraestructura
+Responsables: Infraestructura**
 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).
-Creación y mantenimiento de índices de base de datos
-Dificultad: Media
+==== Creación y mantenimiento de índices de base de datos ====
+**Dificultad: Media
 Impacto: Alto
 Tipo: Eficiencia y escalabilidad
-Responsables: Infraestructura
+Responsables: Infraestructura**
 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.
@@ Línea 42: / Línea 44: @@
 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í)
-Replicación multimaster
+==== Replicación multimaster ====
-Dificultad: Alta
+**Dificultad: Alta
 Impacto: Alto
 Tipo: Eficiencia y escalabilidad
-Responsables: Infraestructura
+Responsables: Infraestructura**
 El cluster de base de datos de SIMO se basa actualmente en dos tecnologías complementarias
-PgPool (Balanceo de carga)
+  * PgPool (Balanceo de carga)
-Streaming Replication (Consistencia de datos entre nodos)
+  * Streaming Replication (Consistencia de datos entre nodos)
 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:
-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
+  - 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
-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.
+  - 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.
-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)
+  - 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)
-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.
+  - 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.
-Pruebas de stress
+==== Pruebas de stress ====
-Dificultad: Baja
+**Dificultad: Baja
 Impacto: Alto
 Tipo: Eficiencia y escalabilidad
-Responsables: Pruebas/Infraestructura
+Responsables: Pruebas/Infraestructura**
 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.
-Directivas de cache
+==== Directivas de cache ====
-Dificultad: Media
+**Dificultad: Media
 Impacto: Alto
 Tipo: Eficiencia y escalabilidad
-Responsables: Desarrollo/Infraestructura
+Responsables: Desarrollo/Infraestructura**
 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:
-Habilitar directiva cache-control para permitir almacenamiento de contenido estático
+  - Habilitar directiva cache-control para permitir almacenamiento de contenido estático
-Utilizar tiempos de expiración max-age concordantes con los tiempos de despliegue
+  - Utilizar tiempos de expiración max-age concordantes con los tiempos de despliegue
-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.
+  - 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.
-Recomendaciones a corto plazo
+  - Recomendaciones a corto plazo
-Análisis de vulnerabilidades
-Dificultad: Media
+==== Análisis de vulnerabilidades ====
+**Dificultad: Media
 Impacto: Medio
 Tipo: Seguridad
-Responsables:Infraestructura
+Responsables:Infraestructura**
 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 BackTrack.
-Revisión de log de auditoría
-Dificultad: Baja
+==== Revisión de log de auditoría ====
+**Dificultad: Baja
 Impacto: Medio
 Tipo: Seguridad
-Responsables: Desarrollo/Infraestructura
+Responsables: Desarrollo/Infraestructura**
 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.
-Uso de JsonViews
-Dificultad: Alta
+==== Uso de JsonViews ====
+**Dificultad: Alta
 Impacto: Bajo
 Tipo: Eficiencia y escalabilidad
-Responsables: Desarrollo
+Responsables: Desarrollo**
 El uso de JsonView 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 JsonView 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.
-Uso de Join Fetch
-Dificultad: Alta
+==== Uso de Join Fetch ====
+**Dificultad: Alta
 Impacto: Bajo
 Tipo: Eficiencia y escalabilidad
-Responsables: Desarrollo
+Responsables: Desarrollo**
 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 JsonView, se espera un impacto bajo por las razones expuestas anteriormente.
-Minificación y Versionamiento Javascript
-Dificultad: Alta
+==== Minificación y Versionamiento Javascript ====
+**Dificultad: Alta
 Impacto: Bajo
 Tipo: Eficiencia y escalabilidad
-Responsables: Desarrollo
+Responsables: Desarrollo**
 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:
-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
+  - 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
-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.
+  - 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.
-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.
+  - 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.
-Reingeniería a sistema de notificaciones y citaciones
+==== Reingeniería a sistema de notificaciones y citaciones ====
-Dificultad: Alta
+**Dificultad: Alta
 Impacto: Alto
 Tipo: Eficiencia y escalabilidad
-Responsables: Desarrollo
+Responsables: Desarrollo**
 Se requiere realizar una reimplementación al sistema de notificaciones que ataque los siguientes puntos:
-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)
+  - 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)
-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.
+  - 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.
 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
-Actualización de librerías base
-Dificultad: Media
+==== Actualización de librerías base ====
+**Dificultad: Media
 Impacto: Medio
 Tipo: Arquitectura
-Responsables: Desarrollo/Pruebas
+Responsables: Desarrollo/Pruebas**
 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
+  * Corrección de bugs
-Nuevas capacidades y funcionalidades
+  * Nuevas capacidades y funcionalidades
-Seguridad
+  * Seguridad
-Ajuste a las nuevas tecnologías
+  * Ajuste a las nuevas tecnologías
-Optimizaciones
+  * 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 SimpleCrud 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.
-Revisión de indexamiento
-Dificultad: Baja
+==== Revisión de indexamiento ====
+**Dificultad: Baja
 Impacto: Medio
 Tipo: Mantenimiento
-Responsables: Desarrollo
+Responsables: Desarrollo**
 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.
-Recomendaciones y desarrollos a mediano plazo
-Visualización de pruebas escritas
+===== Recomendaciones y desarrollos a mediano plazo =====
-Dificultad: Media
+==== Visualización de pruebas escritas ====
+**Dificultad: Media
 Impacto: Alto
 Tipo: Desarrollo
-Responsables: Desarrollo
+Responsables: Desarrollo**
 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 utilizar el sistema de autenticación existente
-Se puede integrar la funcionalidad al sistema de reclamaciones
+  - 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,
+  - Es posible otorgar acceso a las hojas de respuesta en ventanas de tiempo específicas evitando cargas excesivas sobre el sistema
-Cargue estructurado de preguntas y respuestas
+==== Cargue estructurado de preguntas y respuestas ====
-Dificultad: Media
+**Dificultad: Media
 Impacto: Alto
 Tipo: Desarrollo
-Responsables: Desarrollo
+Responsables: Desarrollo**
 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.
-Pruebas virtuales
-Dificultad: Alto
+==== Pruebas virtuales ====
+**Dificultad: Alto
 Impacto: Alto
 Tipo: Desarrollo
-Responsables: Desarrollo
+Responsables: Desarrollo**
 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
+  - Crear pruebas virtuales por parte de las Universidades
-Presentar pruebas por parte del ciudadano utilizando su usuario SIMO
+  - 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
+  - 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.
+  - Almacenar pruebas en estándar QTI.
-Cachés de servidor distribuídos
-Dificultad: Baja
+==== Cachés de servidor distribuídos ====
+**Dificultad: Baja
 Impacto: Medio
 Tipo: Arquitectura
-Responsables: Desarrollo/Infraestructura
+Responsables: Desarrollo/Infraestructura**
 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.
@@ Línea 192: / Línea 220: @@
 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
+  * 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.
+  * 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)
+  * 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
+  * De muy fácil instalación y mantenimiento
-Puede ser utilizado también para almacenar índices Lucene (Ver siguiente recomendación)
+  * Puede ser utilizado también para almacenar índices Lucene (Ver siguiente recomendación)
-Directorios de índices Lucene
+==== Directorios de índices Lucene ====
-Dificultad: Media
+**Dificultad: Media
 Impacto: Bajo
 Tipo: Arquitectura
-Responsables: Desarrollo/Infraestructura
+Responsables: Desarrollo/Infraestructura**
 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.
@@ Línea 207: / Línea 236: @@
 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 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 ElasticSearch 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 ElasticSearch 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 FileSystem con replicación automática y preferiblemente utilizando una implementación en memoria como MMapDirectory para evitar el acceso continuo a disco.
+  * Utilizar índices en FileSystem con replicación automática y preferiblemente utilizando una implementación en memoria como MMapDirectory para evitar el acceso continuo a disco.
-Sistema de archivos distribuido
-Dificultad: Media
+==== Sistema de archivos distribuido ====
+**Dificultad: Media
 Impacto: Medio
 Tipo: Infraestructura
-Responsables:Infraestructura
+Responsables:Infraestructura**
 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
-Actualización sistema PSE
-Dificultad: Media
+==== Actualización sistema PSE ====
+**Dificultad: Media
 Impacto: Bajo
 Tipo: Mantenimiento
-Responsables:Desarrollo
+Responsables:Desarrollo**
 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.
-Recomendador
-Dificultad: Alta
+==== Recomendador ====
+**Dificultad: Alta
 Impacto: Medio
 Tipo: Desarrollo
-Responsables:Desarrollo
+Responsables:Desarrollo**
 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
+  - Escoger un modelo de aprendizaje, es decir, el algoritmo y los datos
-Entrenar el modelo y validar
+  - Entrenar el modelo y validar
-Implementar algoritmo en producción y enlazarlo a la interfaz de usuario
+  - 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.
+  - 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
+  - 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
-Recomendaciones y desarrollos a largo plazo
-Integración con Orfeo
+===== Recomendaciones y desarrollos a largo plazo =====
-Dificultad: Medio
+==== Integración con Orfeo ====
+**Dificultad: Medio
 Impacto: Medio
 Tipo: Desarrollo
-Responsables:Desarrollo-Desarrollo Orfeo
+Responsables:Desarrollo-Desarrollo Orfeo**
 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 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
+  - Al contestar una reclamación SIMO se actualice la respuesta al radicado original en ORFEO
-Integración con BNLE
+==== Integración con BNLE ====
-Dificultad: Baja
+**Dificultad: Baja
 Impacto: Alta
 Tipo: Desarrollo
-Responsables:Desarrollo-Desarrollo BNLE
+Responsables:Desarrollo-Desarrollo BNLE**
 Se recomienda implementar una integración entre SIMO y BNLE de tal forma que:

Herramientas de usuario

Herramientas del sitio

Diferencias

Herramientas de la página