Diferencias

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

--- simo:documentos:tecnicos:recomendaciones [2017/11/14 21:16]
lgomez
+++ simo:documentos:tecnicos:recomendaciones [2017/11/14 21:26] (actual)
lgomez [Integración con Orfeo]
@@ Línea 13: / Línea 13: @@
 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 ====
@@ Línea 52: / Línea 52: @@
 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 ====
@@ Línea 80: / Línea 80: @@
 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 ====
@@ Línea 132: / Línea 132: @@
 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 ====
@@ Línea 144: / Línea 143: @@
 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
@@ Línea 156: / Línea 155: @@
 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.
@@ Línea 184: / Línea 183: @@
 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 ====
@@ Línea 206: / Línea 204: @@
 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 ====
@@ Línea 222: / 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 ====
@@ Línea 239: / 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 ====
@@ Línea 270: / Línea 267: @@
 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 =====
@@ Línea 286: / Línea 283: @@
 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 ====

Herramientas de usuario

Herramientas del sitio

Diferencias

Herramientas de la página