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>PROPUESTA DE ARQUITECTURA SISTEMA SIGECA</h1> <div class="level1"> </div> <h2>INTRODUCCIÓN</h2> <div class="level2"> <p> En el marco del proyecto SIGECA, que busca unificar tecnológicamente los sistemas que soportan los procesos de los concursos de méritos y demás funciones misionales de la entidad, se hace necesario contar con una arquitectura de software uniforme que pueda ser implementada por los módulos que conformarán el sistema. </p> <p> Tal arquitectura debe ser definida a la luz de una serie de criterios que atraviesan lo tecnológico pero que también incluyen aspectos menos técnicos como el equipo de trabajo y las definiciones funcionales. </p> <p> Dadas estas premisas, la argumentación aqui presentada inicia con el análisis de los criterios y paulatinamente profundiza hasta llegar a las definiciones que constituyen la arquitectura en cuestión. </p> </div> <h2>CRITERIOS Y BASE LÓGICA</h2> <div class="level2"> <p> En general, la arquitectura de software busca dar respuesta a una cuestión principal: Dar alcance a una serie de cualidades o atributos de calidad, predominantemente no funcionales, que se han identificado como las más relevantes para el sistema y a su vez minimizar los riesgos identificados como los más peligrosos potencialmente. </p> <p> Los atributos de calidad resultan ser comunes a todos los sistemas de software y por tanto han sido identificados y estandarizados (Ver <a href="/cnscwiki/doku.php?id=ea:tobe:aplicaciones:sigeca:rnf" class="wikilink1" title="ea:tobe:aplicaciones:sigeca:rnf">gestion.cnsc.gov.co/cnscwiki/doku.php</a>), a continuación listamos los más relevantes en el marco del proyecto. </p> <ul> <li class="level1"> Mantenibilidad</li> <li class="level2"> Modularidad</li> <li class="level2"> Rendimiento y escalabilidad</li> <li class="level2"> Seguridad</li> <li class="level2"> Portabilidad y compatibilidad</li> <li class="level2"> Usabilidad</li> </ul> <p> Adicionalmente, existen también otros criterios que resultan importantes pero que no pueden ser clasificados estrictamente como atributos de calidad, entre estos criterios encontramos: </p> <ul> <li class="level1"> Experiencia y habilidades del equipo de trabajo</li> <li class="level2"> Metodología de desarrollo</li> </ul> <p> A continuación se analizan cada uno de estos criterios a la luz del sistema: </p> </div> <h3>Mantenibilidad</h3> <div class="level3"> <p> Esta cualidad indica que tan fácil es hacer mantenimiento y soporte a un sistema y por supuesto es una cualidad deseable y necesaria en cualquier software, cualitativamente, la mantenibilidad de un sistema se ve beneficiada por aspectos como la calidad de la documentación y la simplicidad del código. La calidad de la documentación depende más de la metodología de desarrollo y de la gestión del proyecto, por el contrario, la simplicidad en el código si puede ser influenciada por la arquitectura de software que se escoja, en este sentido, se debe procurar entonces utilizar una arquitectura que favorezca la simplicidad en el código. </p> </div> <h3>Modularidad</h3> <div class="level3"> <p> Esta propiedad afecta directamente la mantenibilidad y está orientada a que el software se construya mediante la interacción de módulos o componentes independientes que pueden ser reemplazados o modificados sin que se afecte radicalmente el funcionamiento de los otros módulos. De esta forma es posible hacer mantemiento focalizados en el módulo afectado por el problema o susceptible de mejora. En general la modularidad es favorecida al seguir los principios de bajo acoplamiento y alta cohesión, los cuales son maximizados al utilizar una arquitectura orientada a componentes y/o a servicios. En consecuencia la arquitectura a escoger utilizará un framework que favorezca estos paradigmas de programación, en concordancia con la arquitectura SOA propuesta (Poner referencia). </p> </div> <h3>Rendimiento y escalabilidad</h3> <div class="level3"> <p> El rendimiento resulta de vital importancia en el sistema, puesto que se espera una alta demanda por parte de los usuarios ciudadanos, (existe un número de usuarios potenciales correspondiente a la fuerza laboral del país). Adicionalmente se espera que haya picos de demanda sobre el aplicativo en momentos claves de la convocatoria como los cierres de los períodos de inscripciones. </p> <p> La escalabilidad está altamente relacionada con el rendimiento puesto que si un sistema es áltamente escalable, entonces podrá soportar demandas de servicios progresivamente más altas sin alterar el rendimiento. Cláramente se debe favorecer una arquitectura que favorezca el escalamiento y minimize el consumo de recursos, claro está, procurando mantener un equilibrio con los demás factores de decisión de la arquitectura. </p> </div> <h3>Seguridad</h3> <div class="level3"> <p> Dada la naturaleza de la información manejada en el sistema, que incluye datos personales y laborales de los usuarios y que atañe directamente al empleo que obviamente es de vital importancia para los usuarios, se hace necesario contar con un nivel de seguridad que garantice la privacidad, confidencialidad, integridad, autenticidad y no repudio de la información. Existe un extenso trabajo en seguridad a nivel de sistemas de información y la arquitectura es solo una parte de la solución. </p> <p> Si bien, pueden implementarse controles de seguridad áltamente sofisticados, estos controles pueden ir en detrimento de otros aspectos como la usabilidad del sistema, en consecuencia, la arquitectura propuesta debe incluir o facilitar la implementación de los controles de seguridad más ampliamente difundidos. </p> <p> La naturaleza Web del sistema, implica que muchos de los controles puedan ser implementados a nivel de infraestructura (por ejemplo la implementación de https/ssl o de sistemas cortafuegos y proxys), otros controles pueden ser implementados a nivel de middleware, como pueden ser los repositorios de la información de autenticación o los servicios de encripción de datos, en este caso, la arquitectura a implementar debería basarse o ser capaz de utilizar plataformas que proporcionen de antemano los servicios necesarios. </p> <p> Adicionalmente, también es necesario implementar controles tendientes a evitar la exposición y uso de vulnerabilidades, estos controles son aplicados muchas veces a nivel del sistema operativo sin embargo, muchos de ellos aplican específicamente al paradigma Web (por ejemplo, cross-site scripting, falsificación de sesiones, almacenamiento de contraseñas en el navegador), por tanto, la arquitectura a usar debería en lo posible implementar por defecto este tipo de controles. </p> <p> Por último, pero no menos importante, la arquitectura debe permitir la especificación diáfana de roles y usuarios que permita implementar los requisitos de autorización sobre las operaciones y datos del sistema, al respecto, el framework utilizado debería permitir la especificación abstracta (si es posible declarativa) de estos roles y permisos. </p> </div> <h3>Portabilidad y compatibilidad</h3> <div class="level3"> <p> Estos atributos de calidad resultan relevantes en dos situaciones específicas: </p> <p> La primera obedece a que se viene desarrollando en la entidad, una iniciativa de mejoramiento de la infraestructura tecnológica, esto plantea la necesidad de contar con aplicaciones que puedan ser portables fácilmente a nuevos tipos de infraestructura. Para empezar, se debe utilizar una arquitectura que utilice un lenguaje de programación portable, pero además de eso, es importante minimizar la dependencia de fabricantes de software específicos y se debe favorecer la aplicación de estándares y especificaciones de la forma más simple que sea posible. </p> <p> El segundo escenario surge de la necesidad de soporta clientes móviles sobretodo para los usuarios ciudadanos, en este sentido, la arquitectura debería permitir el desarrollo de interfaces de usuario optimizadas para ese tipo de clientes o en su defecto, las interfaces deberían poder indistintamente en navegadores tipo escritorio o clientes móviles. De cualquier forma la arquitectura debe proporcionar medios para desplegar la interfaz de usuarios en dispositivos móviles. </p> </div> <h3>Usabilidad</h3> <div class="level3"> <p> Este atributo es de suma importancia dado que se espera una constante interacción del usuario ciudadano con el sistema, y además a que no es posible delinear un perfil específico para los usuarios ya que los empleos ofrecidos en las convocatorias son extremadamente diversos y no es posible caracterizar al usuario que va a aplicar. </p> <p> Es por esta razón que las interfaces de usuario deben ser diseñadas de forma que puedan ser entendidas y usadas por cualquier persona, si bien esto es bastante difícil, puede ser un punto en el cual se puede obtener una mejora sustancial sobre el conglomerado de aplicaciones que conforman el sistema actual. </p> <p> El tema de la usabilidad es difícil de abordar desde el punto de vista de la arquitectura de software, sin embargo, como lineamiento general, se debería escoger una que favoreciera medios flexibles de interacción con el usuario, muy al estilo Web 2.0. Este tipo de interacciones se caracterizan por dar alcance a las características modernas de la Web que incluyen, pero no se limitan a peticiones asincrónicas y a aprovechar al máximo las prestaciones de los navegadores recientes. En particular, las interfaces de usuario deberían no solo ser compatibles con HTML5 sino también tratar de utilizar inteligentemente las nuevas características que este estándar ofrece. </p> </div> <h2>ARQUITECTURA PROPUESTA</h2> <div class="level2"> <p> Tras haber analizado dos posibles arquitecturas de sofware, y con base en los atributos de calidad descritos, se propone una arquitectura descrita por el siguiente diagrama: </p> <p> <a href="/cnscwiki/doku.php?id=ea:tobe:aplicaciones:sigeca:sigeca1.png&426x606}}" class="wikilink2" title="ea:tobe:aplicaciones:sigeca:sigeca1.png" rel="nofollow">sigeca1.png</a> </p> <p> El diagrama ilustra una arquitectura tipo SOA, basada en servicios Web Restful alojados en un servidor liviano construido con base en el framework de desarrollo Spring que se ejecuta sobre un contenedor Web Java. </p> <p> En naranja se pintan los componentes de la capa de adaptación que permiten el acceso a la persistencia (base de datos), en verde están los componentes de la capa de servicio, en azul se encuentran los componentes de la capa Web y en amarillo los de la capa de presentación o interfaz de usuario. En gris se pintan los componentes del framework que proporcionan los servicios middleware pero que no tienen que ser escritos por el desarrollados sino sólamente configurados. A continuación se explica cada uno: </p> <ol> <li class="level1"> <b><a href="/cnscwiki/doku.php?id=ea:tobe:aplicaciones:sigeca:framework" class="wikilink2" title="ea:tobe:aplicaciones:sigeca:framework" rel="nofollow">FrameWork</a> Spring + J2EE:</b> Este framework junto con los servicios J2EE del contenedor Web que aloja la aplicación, es el encargado de proveer todos los servicios de integración, seguridad, acceso a datos, transacciones, aspectos, inyección de dependencias e inversión de control, junto a varios más que dan soporte a la arquitectura del lado del servidor. Si bien Spring puede ser utilizado de muchas formas, en esta propuesta se utiliza para inplementar una arquitectura de tipo servidor liviano, donde se delega gran parte de la responsabilidad de renderización de la interfaz gráfica al navegador, permitiendo una reducción en el consumo de recursos del lado del servidor y facilitando su escalamiento. Del entorno J2EE se utilizan los componentes de la especificación Web (principalmente Servlets) por lo cual es posible desplegar la aplicación en un contenedor Web Java liviano como Apache Tomcat o Jetty.</li> <li class="level2"> <b>Entidad JPA:</b> Este componente representa un objeto de dominio (Referencia) y a su vez contiene la información que permite mapear los objetos de dominio a las tablas en el sistema de persistencia. Esta información sigue la especificación JPA de Java</li> <li class="level2"> <b>Hibernate:</b> Este componente se encarga de realizar el mapeo relacional a objeto y manejar el ciclo de vida de las entidades JPA</li> <li class="level2"> <b>Repositorio Spring JPA:</b> Este componente es una interfaz que al ser implementada por Spring proporciona las operaciones CRUD y los métodos de búsqueda definidos por el desarrollador. Solo basta definir las firmas de los métodos de búsqueda y Spring se encarga de proporcionar todo el código, para mantener la arquitectura SOA (referencia), lo ideal es crear un repositorio por Entidad principal (Objeto de dominio)</li> <li class="level2"> <b>Servicio Spring: </b> Este componente implementa los métodos de negocio de cada módulo, lo ideal es crear un servicio por repositorio Spring, a través de los mecanismos de inyección de dependencias de Spring, el componente obtiene referencias al repositorio Spring y a cualquier otro servicio que se requiera. Si no se requieren métodos de negocio distintos a las operaciones CRUD tradicionales, este componente puede ser obviado.</li> <li class="level2"> <b>Controlador REST:</b> Este componente se encarga de exponer los servicios del repositorio Spring y del Servicio Spring utilizando el estándar REST, también mediante inyección de dependencias, el controlador puede acceder a los métodos CRUD del repositorio Spring o a los métodos de negocio del Servicio Spring.. El estándar REST indica que las operaciones de inserción se debe realizar usando el método HTTP Post, las de consulta Get, las de modificación PUT y las de eliminación DELETE. Este componente se encarga de crear manejadores para cada uno de estos métodos HTTP y enlazarlos a los métodos en los otros componentes. La principal diferencia con los controladores tradicionales (Por ejemplo JSF) es que en este caso no se está generando HTML sino que se producen cadenas JSON que son intercambiadas con el navegador, estas cadenas son inherentemente más livianas y simples que HTML y proporcionan una mayor flexibilidad y una mejor separación de responsabilidades puesto que ofrecen una representación uniforme, simplificada y libre de información de formateo.</li> <li class="level2"> <b>Página HTML + Componentes DOJO: </b> La interfaz de usuario se crea y ejecuta enteramente en el servidor y consiste de páginas HTML y componentes DOJO que son componentes <a href="/cnscwiki/doku.php?id=simo:documentos:tecnicos:javascript" class="wikilink2" title="simo:documentos:tecnicos:javascript" rel="nofollow">JavaScript</a> modularizados bajo el estándar AMD. Se propone el uso de dos tipos de componentes DOJO que colaboran entre sí, por un lado los Widgets proporcionan los componentes gráficos y por otro, los store se encargan de acceder a los recursos REST en el servidor y adaptar esta información para los Widget, de esta forma se logra una interfaz de usuario ríca en funcionalidades, modular, simple y limpia.</li> </ol> </div>