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>ARQUITECTURA DE SISTEMA SIMO</h1> <div class="level1"> </div> <h2>INTRODUCCIÓN</h2> <div class="level2"> <p> Esta página contiene la descripción arquitectónica del sistema SIMO. Esta arquitectura fue diseñada de acuerdo a los criterios presentados a continuación y naturalmente sufrió un proceso evolutivo a medida que se fue construyendo el sistema. </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> <li class="level2"> Acceso a la información</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> <h3>Acceso a la información</h3> <div class="level3"> <p> Este atributo era de particular importancia para el sistema, dado que una de las principales funciones del sistema es permitir al ciudadano encontrar empleos potenciales cuyas características se alineen apropiadamente a su experiencia laboral, habilidades y gustos. </p> <p> En este sentido, el sistema debía contar con un sistema de búsqueda más avanzado que permitiera encontrar empleos por criterios definidos (como rango salarial, nivel académico, convocatoria, entre otras) pero también por palabras clave y por aproximación de forma que la búsqueda no dependa de que los textos contengan exactamente una palabra. </p> <p> En general este tipo de búsquedas incorpora tecnologías relacionadas con el indexamiento de texto completo (Full Text Index) y pueden incorporar algoritmos como búsquedas fonéticas, raíces lexicográficas, n-gramas, entre otros </p> <p> En resumen, la arquitectura del sistema fue planeada para incorporar librerías que proporcionen estas capacidades de manera genérica </p> </div> <h2>ARQUITECTURA</h2> <div class="level2"> <p> La arquitectura del sistema se describe en 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. El modelo de dominio puede ser consultado en la siguiente página <a href="/cnscwiki/doku.php?id=simo:documentos:tecnicos:dominio" class="wikilink1" title="simo:documentos:tecnicos:dominio">Modelo de dominio</a> </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>