CONSEJERÍA DE INNOVACIÓN, CIENCIA Y EMPRESA

Transcripción

1 CONSEJERÍA DE INNOVACIÓN, CIENCIA Y EMPRESA Marco metodológico para el desarrollo de software en proyectos ejecutados bajo la Orden de Incentivos a Proyectos de Innovación y Modernización de los Servicios Públicos de las Corporaciones Locales Andaluzas

2 Índice Parte A: Preparación para el desarrollo Introducción Objetivos generales Líneas generales de actuación Cómo está estructurado este documento Arquitectura de un componente Qué es un componente Descomposición en capas Problemas transversales No construir desde cero Gestores de contenido Servidor de portales Framewors de aplicaciones Hacer uso de patrones para la arquitectura y el diseño de componentes Tecnologías recomendadas según el tipo de componente Página web corporativa Intranet corporativa Portal web de servicios telemáticos Componentes transversales Componentes de back-office Conclusiones Consideraciones técnicas Lenguajes de programación Formatos de archivos Licencias Herramientas de desarrollo Sistemas de control de versiones Herramientas de construcción de software Entornos de desarrollo integrados (IDE)...17 Parte B: Diseño y construcción de un componente Construcción de la capa de Presentación Objetivo: Aislar y simplificar la capa de presentación Solución: Usar un gestor de contenido Solución: Aplicar el patrón MVC Solución: Utilizar JSF Conclusiones Objetivo: Implementar interfaces con AJAX Solución: utilizar una librería JavaScript Solución: utilizar JSF Conclusiones Objetivo: Crear páginas web accesibles W3C y WAI Técnicas para facilitar la accesibilidad Accesibilidad y AJAX Evaluar la accesibilidad Objetivo: Creación de interfaces personalizables...26 Documento: Marco Metodológico V. 01 Impreso el 11/08/08 Estado: Proyecto: Página 2 de 38

3 4.4.1 Técnicas para lograr interfaces personalizables Construcción de la capa de Lógica de negocio Servicios web Objetivo: permitir a otros componentes operar con el nuestro Cuándo publicar servicios web Qué servicios web publicar Solución: publicar WebServices Documentar servicios web Objetivo: utilizar la lógica de negocio de componentes externos Solución: consumir servicios web Solución: crear una capa de servicios web para componentes que no la implementen de serie Construcción de la capa de Persistencia Objetivo: Independizar el componente de la base de datos Solución: Utilizar una librería de mapeo objeto-relacional Solución: Utilizar el patrón DAO Solución mixta: DAOs con librerías OR Contraindicación: Utilizar procedimientos almacenados Conclusiones Problemas transversales Objetivo: promover un acceso único y centralizado Solución: Central Authentication System Solución: Kerberos y Generic Security Services Solución: OpenID Conclusiones Objetivo: promover un modelo único de gestión de usuarios...37 Documento: Marco Metodológico V. 01 Impreso el 11/08/08 Estado: Proyecto: Página 3 de 38

4 Parte A: Preparación para el desarrollo

5 1Introducción Este documento establece una serie de referencias metodológicas y tecnológicas para el desarrollo de software incentivado por Consejería de Innovación, Ciencia y Empresa, en su programa para el fomento de la innovación y modernización de las Administraciones Locales de Andalucía. Amplía los requisitos generales contemplados en el Anexo 06 de la ORDEN de 17 de junio de 2008, por la que se establecen las bases reguladoras del programa de incentivos para la innovación e impulso del acceso electrónico de los ciudadanos a los servicios públicos de las Administraciones Locales de Andalucía y se efectúa su convocatoria para los años 2008 y Objetivos generales Los objetivos generales que persigue el establecimiento del marco metodológico son: Fomentar la reusabilidad de los productos resultantes de la ejecución de los proyectos incentivados. Asegurar la interoperatividad entre los proyectos desarrollados y los componentes heredados. Asegurar la posibilidad de que todo el software desarrollado pueda funcionar exclusivamente con productos con licencia libre. Crear un estándar de calidad para los proyectos resultantes. 1.2Líneas generales de actuación Todas las soluciones aquí expuestas se basan en una serie de premisas básicas de partida: Adopción de arquitecturas basada en SOA: implementar una capa de servicios web para los componentes desarrollados. Utilización de software con licencia libre: no debería existir la necesidad de utilizar ninguna herramienta con software privativo ni para instalar, ejecutar o modificar el software resultante. Fomento de tecnologías avaladas por un estándar. Utilización de un framework de aplicaciones o un gestor de contenido como base del desarrollo. Diseño por capas: todos los componentes deben dividirse en partes aisladas, definidas y con dependencias claramente especificadas.

6 Utilización de bases de datos de código abierto (en especial MYSQL o PostgresSQL). En caso de desarrollar utilizando una base de datos con licencia privativa, el sistema construido deberá implementar la posibilidad de utilizar una con licencia libre. Se recomienda utilizar librerías de mapeado objeto-relacional para implementar la capa de persistencia. Se recomienda un modelo único de gestión de usuarios y, a ser posible, una solución de accesso único y centralizado (como por ejemplo Central Authentication Service) Se exigirá un nivel mínimo de accesibilidad en las páginas web desarrolladas. Se valorará la existencia de conjuntos de pruebas automatizadas para los distintos niveles (pruebas de unidad, funcionalidad, integración y estrés) Se recomienda el uso de herramientas de construcción y despliegue automáticas, como maven para el entorno Java. 1.3Cómo está estructurado este documento Este documento está dividido en tres secciones según la fase de desarrollo: preparación, construcción y entrega. Cada una de estas secciones está a su vez divida en una serie de capítulos que tratan una problemática particular de esa fase. En los capítulos se desarrollan una serie de objetivos específicos asociados a esa problemática así como soluciones propuestas y errores comunes. Se utilizan unas referencias visuales para distinguir en el texto soluciones recomendadas, aclaraciones o soluciones contraindicadas: Solución recomendada Aclaración Solución contraindicada Cuando estas recomendaciones o contraindicaciones se refieren a un determinado producto de software, aparecen incluidas en una tabla Producto de software recomendado Producto de software contraindicado

7

8 2Arquitectura de un componente En este capítulo se propone una arquitectura general para el desarrollo de un componente de software: se trata de una serie de recomendaciones a la hora de organizar el código fuente de un componente. 2.1Qué es un componente En este documento se utilizará el término componente para referirnos a un desarrollo de software que provee de una serie de funcionalidades y que está pensado para ser incluido en el Repositorio de Software Libre de la Junta de Andalucía (y que, por lo tanto, deberá cumplir una serie de requisitos en cuanto a reusabilidad y licencias). 2.2Descomposición en capas En líneas generales, cualquier componente se debería poder descomponer en tres grandes secciones: Presentación: todo lo relacionado con la interacción de usuario con nuestro componente; generalmente requiere la generación de páginas web accesibles al usuario mediante un navegador. Lógica de negocio: todo lo relacionado con la gestión que hace nuestro componente. También incluye la publicación de estos procesos de gestión mediante servicios web así como la utilización de servicios publicados por otros componentes. Persistencia: todo lo relacionado con guardar datos en algún sistema de almacenamiento. A cada una de estas secciones se las suele denominar capas y tienen un doble propósito: reducir la complejidad, dividiendo el código en partes definidas, y reducir el impacto que las modificaciones en una parte del código provoca en el resto. Para conseguir estos objetivos, lo ideal es que cada capa se comunique única y exclusivamente con la capa inferior. Esto quiere decir que, por ejemplo, la capa de Presentación debería utilizar exclusivamente la capa de Negocio; la de Negocio sólo debería utilizar la capa de Persistencia. En este contexto, utilizar significa que la capa superior envia una petición a la inferior y ésta responde ejecutando una serie de operaciones y, opcionalmente, devolvuiendo una serie de datos. Estas tres partes o capas estarán presentes en la mayoría de los desarrollos, aunque el tamaño y complejidad de las mismas variará en función del tipo de componente que estemos desarrollando. También es posible que se deseen utilizar más de tres capas, aunque es poco frecuente.

9 2.3Problemas transversales Además de las tres partes (capas) fundamentales de los componentes arriba expuestas, existen una serie de subsistemas que afectan a todas estas capas: el gestor de autorización, de autenticación (seguridad), de usuarios, etcétera. Tratan una serie de problemas que afectan a todo el componente, independientemente de la capa en la que nos situemos. Llamaremos a éstos problemas transversales y trataremos los más importantes comentando distintas soluciones. 2.4No construir desde cero En todos los proyectos existe una serie de código que se encarga de actividades que poco tienen que ver con la funcionalidad sino con la infraestructura necesaria para implementar esa funcionalidad. Cuanto menos de este código tengamos que escribir, más tiempo podremos dedicar a implementar las funcionalidades reales del componente que estamos construyendo y reduciremos enormente los riesgos asociados al desarrollo. Por lo tanto, para evitar escribir este tipo de código (como el de, por ejemplo, conectar unas capas con otras) utilizaremos alguno de los productos de software pensados como base de desarrollos: gestores de contenido, gestores de portales o frameworks de aplicaciones Gestores de contenido Los CMS (Content Management Systems en su acepción inglesa) son productos de softwares pensandos para la publicación de datos en la web. Se encargan de implementar la capa de persistencia y de negocio y, al ser facilmente extensibles y personalizables, nos permiten usarlo como base de desarrollo concentrándonos en las funcionalidades específicas y en el aspecto, y acelerando el desarrolo. Suelen ser muy buenos para las tareas para las que están pensados, pero como contrapartida puede dificultar la implementación de funcionalidades más avanzadas. OpenCMS es el más extendido de este tipo de productos en el entorno Java: tiene una amplia base usuarios y documentación y se recomienda su uso. En la sección se analizan las ventajas e inconvenientes de usar un CMS como base del desarrollo.

10 2.4.2Servidor de portales Al igual que los gestores de contenido, los servidores de portales están pensandos para la publicación en la web, pero su estrategia difiere de la de los anteriores en que divididen el sistema de publicacion en muchas mini aplicaciones autónomas siendo la principal tarea del servidor la integración de las mismas. Suelen ser más complejos que los gestores de contenidos pero al mismo tiempo más potentes. Además cuentan con buenas características de integración con otros productos (a través, por ejemplo de ESBs). Liferay es uno de los gestores de portales más utilizados, con muchas posibilidades de integración y por lo tanto es la opción recomendada Framewors de aplicaciones Un framework es un conjunto de librerías cohesionadas junto con una metodología asociada. Puede ser que este conjunto de librerías esté dirigido a un área específica: Struts es un conocido framework Java para el desarrollo de la capa de presentación (y sólo esta capa) de aplicaciones web. Se puede dar el caso de que el framework cubra varios, si no todos, los aspectos del desarrollo, sirviendo así de guía en el diseño completo del componente. A este tipo de frameworks (algunas veces denominados full-stack solutions) son los que, de ahora en adelante, llamaremos frameworks de aplicaciones y, para ser considerados como tales, es necesario que aporten soluciones en las tres capas de la aplicación. La ventaja de utilizar este tipo de frameworks son varias: Reduce o elimina el código de comunicación entre capas. Aporta soluciones probadas a la mayoría de los problemas comunes. Ayudan a crear componentes más modulares Aseguran un nivel mínimo de calidad Según esta definición los conocidos Hibernate, Struts, Axis, ActiveRecord se denominarán librerías y no frameworks de aplicaciones. Los frameworks recomendados para el desarrollo son: En el entorno Java se recomienda SpringFramework y JBoss Seam: ambos se basan en el patrón de Inversión del Control. En el caso de usar otros frameworks, se aconseja que se estén basados en el mismo patrón. Si se desarrolla utilizando lenguajes dinámicos, se recomiendan Django y Zope para Python, Zend para PHP,

11 RubyOnRails para Ruby y Grails para Groovy. Especial cuidado hay que tener con Struts versión 1.x: a parte de no ser un framework de aplicación, ha demostrado tener graves problemas de diseño y se desaconseja encarecidamente su uso. 2.5Hacer uso de patrones para la arquitectura y el diseño de componentes En informática, un patrón es una solución detallada y comentada con sus pros y contras para resolver un problema común en el desarrollo de software. Existen muchos catálogos de patrones (tanto en Internet como en papel) que, a modo de recetario, recomiendan una solución u otra en función del problema y su contexto. Los patrones son una manera de sistematizar el conocimiento adquirido en el desarrollo de software en los últimos años. El uso de patrones aumenta el nivel de abstracción a la hora de desarrollar software. Un ejemplo sencillo: supongamos que tenemos que construir un edificio que tenga la posibilidad de albergar a un grupo de gente para hablar un tema concreto. Yo puedo describir la solución hablando de paredes, puertas, suelos inclinados, sillas, etcétera. También puedo decir que he construido un edificio una sala de conferencias y tres salas de reuniones (donde una sala de conferencia o una sala de reunión son patrones -soluciones- a esos problemas). Si a eso sumamos que existen una serie de catálogos que describen exactamente qué tiene que cumplir una sala para ser una sala de conferencias, es fácil ver las ventajas de usar patrones: Las soluciones expresadas en los patrones son el resultado de la experiencia de muchos desarrolladores a lo largo de los años, por lo que aumenta la confianza de que se está diseñando correctamente. Al aumentar el nivel de abstracción, mejoran la comunicación entre las partes involucradas en el desarrollo. Sirve como base de documentación de un diseño. El uso de patrones de diseño no tiene ninguna desventaja. En la actualidad se está convirtiendo en la manera estándar de diseñar aplicaciones. Sin ir más lejos, la solución anterior de dividir un componente en tres capas es un patrón arquitectónico muy extendido y perfectamente documentado.

12 2.6Tecnologías recomendadas según el tipo de componente El tipo de tecnologías en las que nos debemos basar para el desarrollo de componentes depende fundamentalmente de la funcionalidad que tiene que soportar Página web corporativa La página web corporativa es el lugar donde se proporciona información de interés para la ciudadanía, generalmente hablamos de contenidos estáticos modificables por el organismo del que dependa. En estos casos, la capa de presentación es aquí la más importante y factores como facilidad de personalización son claves en este componente. Para este tipo de desarrollos es recomendable valorar el uso de una herramienta de gestión de contenidos (como por ejemplo OpenCMS) que resuelve las capas de persistencia y lógica y nos permite concentrarnos en el desarrollo exclusivamente de la capa de presentación Intranet corporativa Es el front-office de los empleados públicos. Este tipo de componente suele delegar en componentes externos su lógica de negocio, por tanto la capa de presentación es clave así como una buena integración con componentes externos a través de servicios web. Se deberán buscar soluciones que implementen funcionalidades de integración y en los que sea fácil y potente crear la capa de presentación. Aquí las dos primeras opciones que se deberían barajar son los gestores de contenido y los portales. En el caso en el que la lógica de negocio a implementar sea bastante compleja o que la intranet deba coordinar varios servicios para realizar sus tareas (porque no exista un componente de integración) un application framework como SpringFramework o Seam puede ser la mejor opción Portal web de servicios telemáticos Componente parecido al anterior con la diferencia de que se dirige a ciudadanos en vez de empleados públicos. De nuevo, es común delegar la lógica de negocio, por lo que se puede aplicar las mismas recomendaciones arriba expuestas Componentes transversales Dentro de esta categoría se incluyen aquellos componentes destinados a dar servicios a otros (por ejemplo el gestor de flujos, gestor de documentos, etcétera).

13 Este tipo de componentes suele funcionar como integrador por lo que es importante utilizar tecnologías con buen soporte de servicios web. Además es probable que necesiten tener un alto grado de integración con las herramientas desarrolladas en el entorno de la Junta de Andalucía. Debido a que estas herramientas están escritas en Java y muchas de ellas no disponen de servicios web como mecanismo de interacción, es muy recomendable desarrollar estos componentes usando Java. Generalmente estos componentes no precisan de capa de presentación siendo esta sustituida por una capa de publicación de servicios web, por eso es necesario elegir herramientas con fuerte soporte en estas tecnologías. De nuevo SpringFramework o algún otro application framework junto con librerías como Axis deben ser opciones a tener en cuenta Componentes de back-office Dentro de este tipo de componentes podemos distinguir dos casos: aquellos que desarrollan la funcionalidad de principio a fin y los que utilizan un componente de back-office heredado ya sea para añadir funcionalidad al mismo como para añadir una capa de servicios y permitir su integración. De nuevo se recomienda usar application frameworks que aporten soluciones a las tres capas del componente y que proporcionen una fuerte integración con servicios web. 2.7Conclusiones En general hay que atender a las siguientes consideraciones a la hora de construir un componente: Todo componente debe estar dividido en al menos tres partes siguiendo un arquitectura por capas. Se recomienda encarecidamente el uso de un CMS, un servidor de portal o un framework de aplicaciones como base para el desarrollo. Se recomienda el uso de patrones para el diseño de las partes de un componente.

14 3Consideraciones técnicas En este capítulo se tratan algunas decisiones técnicas que hay que tomar antes del desarrollo de un componente. Los objetivos para este capítulo son: Reducir la complejidad de los desarrollos limitando el número de tecnologías posibles. Servir de guía para tomar decisiones tecnológicas que afectarán al todo el desarrollo. 3.1Lenguajes de programación En principio no existe ninguna limitación en el uso de los lenguajes de programación, pero si una serie de factores que condicionan la elección: Generalmente no es posible escribir un componente utilizando un único lenguaje de programación (por ejemplo, cuando escribimos código en la parte servidora y en la parte cliente). La proliferación de componentes con lenguajes de programación variados impacta negativamente en la reutilización de los mismos porque precisa de personas técnicas con conocimientos de esos lenguajes. El uso de lenguajes de programación poco extendidos tiene riesgos a la hora de realizar un mantenimiento de dicho componente y por lo tanto puede afectar a la vida útil del mismo. Gran cantidad del software presente en el Repositorio de Software Libre de la Junta de Andalucía está escrito en Java, por lo que la integración con este software es más sencillo si en los desarrollos se utiliza este mismo lenguaje. Los lenguajes de programación dinámicos pueden ser mucho más efectivos que los tradicionales para desarrollar algunos tipos de aplicaciones. Es necesario que los componentes desarrollados tengan independencia con respecto a la plataforma Como consecuencia de estas consideraciones, los lenguajes de programación deberán limitarse a los siguientes: Java: en la actualidad es el lenguaje de programación más extendido que resuelve la mayor parte de las consideraciones arriba expuestas. Sus puntos fuertes son la independencia de plataforma, la enorme cantidad de recursos (librerías, frameworks, documentación, soporte, entornos de desarrollo) y el rendimiento. Se recomienda su uso como lenguaje de programación principal.

15 JavaScript: prácticamente todos los componentes con interfaz gráfico basado en web utilizarán directa o indirectamente este lenguaje. PHP, Python y Ruby: estos tres lenguajes comparten que están muy extendidos y que son dinámicos. Entre sus puntos fuertes destacan que resuelven de manera muy efectiva problemas típicos en especial cuando se desarrollan aplicaciones con interfaz web (en general agilizan enormemente el desarrollo en comparación con Java). Sus puntos débiles son el rendimiento y la falta de herramientas de desarrollo sofisticadas (que incide directamente en el mantenimiento futuro del componente) y la dificultad a la hora de integrarse con software existente. Se deben estudiar detalladamente los pros y los contras antes de decidirse por su uso. Groovy, JRuby y Jython: Al igual que con los tres lenguajes anteriores, éstos tienen la ventaja de poderse ejecutar en una máquina virtual de Java y que, como consecuencia, la integración con otras aplicaciones en ese entorno es muy elevada. Aunque un poco más convenientes que los anteriores, se deben tomar en cuenta las mismas consideraciones. C y C++: son dependientes de la plataforma y por lo tanto se debe desacartar su uso. C#, VisualBasic y.net: aunque existe una plataforma que permite ejecutar muchos de los lenguajes.net en entornos linux ( éstos son altamente dependiente de windows (es decir, licencia privativa) y por lo tanto se desaconseja su uso. Es importante señalar que en la mayoría de los proyectos (en los que se usarán componentes de gestión electrónica desarrollados por la Junta de Andalucía) el uso de Java se hace prácticamente imprescindible para poder integrar dichos componentes con el que se está desarrollando. El uso de otros lenguajes de programación no mencionados aquí, debe hacerse con mucha cautela, justificando su uso e indicando claramente dónde se aplican. 3.2Formatos de archivos En ocasiones es necesario utilizar archivos para almacenar datos referidos al uso, configuración o personalización del componente. El objetivo fundamental a la hora de elegir un formato de archivo para guardar información es que no requiera grandes conocimientos técnicos ni para interpretar su contenido ni para modificarlo. Para cumplir este objetivo, los formatos de archivo elegidos deberán cumplir los siguientes requisitos: Deben ser legibles por humanos: se evitarán los formatos binarios para el almacenamiento de datos.

16 Deben ser de fácil lectura por máquinas: se utilizarán formatos estructurados o semi estructurados y se valorará la existencia de librerías que faciliten la tarea de lectura. Deben ser sencillos y útiles para la tarea encomendada. Deben adoptar algún estándar. Siguiendo estas consideraciones, los formatos de archivo posibles son: XML: cumple todos los requisitos anteriores y debería ser el formato de almacenamiento de datos por defecto. Archivos de propiedades (properties en Java, YAML en lenguajes dinámicos): recomendado para almacenar datos configurables extremadamente simples (por ejemplo: nombre de la base de datos y contraseña para conectarse a la misma). Archivos separados por comas: no se deberían usar este tipo de archivos porque es necesario información adicional para interpretar el contenido, son difíciles de leer y muy propensos a los errores. 3.3 Licencias Todo desarrollo de software para la Junta de Andalucía se deberá hacer bajo la licencia de software libre EUPL. Además, en todos los proyectos incentivados, debería ser posible construirlos (a partir del código fuente), instalarlos y ejecutarlos sin utilizar ningún software con licencia privativa. 3.4 Herramientas de desarrollo La elección de unas herramientas de desarrollo adecuadas es un factor importante para aumentar la productividad de un grupo de desarrollo. Aquí se comentan y recomiendan algunas de ellas Sistemas de control de versiones Estas herramientas son imprescindibles para desarrollar software. Permiten compartir el mismo código por un número de personas y al mismo tiempo llevar un control de los cambios que se van efectuando, con la ventaja doble de tener la evolución del desarrollo bajo control y de la posibilidad de deshacer cambios erróneos. Las alternativas más extendidas son: CVS: el sistema de control de versiones más popular hizo un excelente trabajo en los años 90 pero ha demostrado tener graves deficiencias que otros sistemas ya resuelven perfectamente. Se desaconseja su uso.

17 SVN: Actual sustituto del CVS. Comparte filosofía de trabajo, está soportado por la práctica totalidad de las herramientas de programación, es fácil de instalar y de usar. Es en la actualidad el estándar en este tipo de herramientas y se recomienda su uso. GIT y Mercurial: estas herramientas están destinadas a sustituir a las dos anteriores y aunque su aceptación ha aumentado enormemente en los últimos años, aún no tienen la misma que las anteriores. Perfectamente válidos para el desarrollo Herramientas de construcción de software El objetivo de estas herramientas es automatizar una serie de tareas repetitivas y complejas presentes en todo desarrollo de software (compilación, ejecución de tests, despliegue en servidores, etcétera). Las ventajas de utilizar este tipo de herramientas son: Permite la automatización de tareas necesarias y repetitivas ganando tiempo y reduciendo errores. Sistematiza ciertos procesos que normalmente se hacían de manera similar pero distinta dentro del mismo grupo de trabajo. Crea una metodología de trabajo dentro de un grupo. Ayuda a integrar sistemas de control de calidad dentro del proceso de desarrollo y facilita la generación de informes de este tipo. Aumentan la reusabilidad del componente desarrollado porque facilita su modificación. Entre los inconvenientes: No son herramientas sencillas y requieren un cierto aprendizaje inicial. Este aprendizaje se compensa con creces por los beneficios obtenidos. El uso de estas herramientas está afortunadamente cada vez más extendido y, como debería quedar claro, su uso está más que recomendado. Cada lenguaje de programación tiene sus propias herramientas de construcción (SCons, distutils y buildutils para Python, Rake para Ruby ). Dentro del la plataforma Java, las herramientas de este tipo más extendidas son Ant y Maven. Cualquiera de estas dos son adecuadas pero se preferirá Maven sobre Ant porque es más fácil de usar, tiene un nivel de abstracción más elevado, requiere menos programación y tiene mejor integración con herramientas de calidad de código Entornos de desarrollo integrados (IDE) Los entorno de desarrollo integrados son herramientas sumamente útiles a la hora de desarrollar software. Existen una variedad muy amplia de este tipo de herramientas y su uso es imprescindible.

18 Cualquiera de las alternativas de código abierto son perfectamente válidas aunque, dentro del entorno Java, recomendamos Eclipse y Netbeans por ser lás mas extendidas, potentes y por tener gran cantidad de extensiones.

19 Parte B: Diseño y construcción de un componente

20 4Construcción de la capa de Presentación La capa de presentación es la parte del componente que se encarga de la creación y funcionamiento de un interfaz con el usuario (generalmente a través de un navegador web) y de todos los asuntos relacionados tanto con la presentación como la introducción de datos. Los objetivos que persigue este capítulo son: Establecer unas guías que permitan simplificar la capa de presentación y reducir asi la complejidad inherente al desarrollo de esta parte del componente. Aislar la capa de presentación: ayuda a la modularidad y la reusabilidad del componente. Creación de interfaces gráficos accesibles: debido a que muchos de los desarrollos están destinados al uso en las administraciones públicas y ésta está obligada a dar servicio por igual a todos los ciudadanos, este tema es especialmente importante. Creación de interfaces gráficos personalizables: para garantizar un mínimo nivel de reutilización de nuestro componente es necesario proveer de unos mecanismos sencillos para adaptar el aspecto a las necesidades de la instalación. Cuando hablamos de crear interfaces gráficas dentro de este contexto nos estamos refiriendo a programas de software que generan documentos en HTML listos para ser visualizados en un navegador. Normalmente estos documentos contendrán una serie de enlaces para ejecutar acciones y, algunos de ellos, formularios que permiten al usuario enviar información. Estas páginas HTML se crean normalmente con lo que se suele denominar un lenguaje de generación basado en plantillas. En el entorno Java, el sistema estándar de generación de plantillas se denomina Java Server Pages (JSP). Existen este tipo de sistemas para cualquier lenguaje de programación. 4.1Objetivo: Aislar y simplificar la capa de presentación El error más común a la hora de implementar la capa de presentación consiste en introducir, dentro de esta capa, lógica que pertenece al dominio del problema, es decir, lógica de negocio. Mezclar lógica de negocio en la capa de presentación conlleva tener código difícil de entender y muy costoso de mantener. También dificulta (si no impide) enormemente la posibilidad de reutilización de este componente puesto que el qué hace (la lógica de negocio) está íntimamente ligado a cómo lo muestra.

21 Los sistemas de generación de plantillas se basan en introducir fragmentos pequeños de código dentro de la propia página HTML. Hay que tener especial cuidado en mantener esos fragmentos en la mínima expresión: varias líneas de código dentro de la plantilla o la aparición de sentencias condicionales nos debe hacer pensar que estamos mezclando lógica de negocio y de presentación Solución: Usar un gestor de contenido Un gestor de contenido (Content Management System, CMS) es una aplicación destinada a la publicación de información, y que proporciona mecanismos para que ciertos usuarios puedan gestionar esa información y para que administradores puedan configurar que gestor en si, tanto a nivel funcional como visual. Los gestores de contenido han ido evolucionando a lo largo de los años siendo ahora sofisticadas piezas de software que pueden ser perfectamente válidas como plataformas de desarrollo. Las ventajas de usar un gestor de contenido como plataforma de desarrollo son las siguientes: Resuelven una gran parte de los problemas comunes a todas las aplicaciones (gestión de usuarios, seguridad, etcétera) por lo que se inicia el desarrollo en un punto bastante más avanzado. Proporcionan herramientas sofisticadas para la gestión de contenidos: control de versiones, búsquedas, mecanismos de clasificación, etcétera Los inconvenientes: Generalmente los CMS tienen una estructura propia, con una sistema de configuración y ampliación no estándar y que necesita una tiempo de aprendizaje. Suelen ser muy buenos en las tareas para las que están capacitados pero dificultan (e incluso en algunos casos imposibilitan) la realización de otras tareas más complejas Solución: Aplicar el patrón MVC2 El patrón MVC es la solución más conocida y extendida para organizar el código fuente referido a la interacción con el usuario. Esta solución se creó pensando en aplicaciones de escritorio basado en componentes por lo que, la versión adaptada para aplicaciones web se conoce habitualmente como patrón MVC Model2 o patrón MVC2. El patrón MVC2 considera que la vista es una página HTML que se ha generado con un lenguaje de generación de plantillas. Lo que propone este patrón es que, antes de generar cualquier página, se debe ejecutar un bloque de código perteneciente a la capa de lógica de negocio para obtener una serie de datos que serán los que aparecerán en la página. A este bloque de código lo denomina controlador y a los datos que

22 aparecerán los denomina modelo. En el entorno Java hay dos maneras de implementar este patrón: utilizando directamente JSP (para las vistas) y Servlets (para los controladores) o utilizando uno de las muchísimas librerías que ayudan y simplifican esta tarea. Desafortunadamente una de las primeras librerías MVC2 que se crearon en Java para este fin fue la conocida Struts que ha demostrado tener graves problemas de diseño, contribuye aplicar erróneamente el patrón MVC, y obliga al programador a escribir un código difícil de entender y de mantener. Por eso se desaconseja encarecidamente el uso de Struts (versión 1.x) como Framework de desarrollo. Dentro del entorno Java otra librerías más modernas, sin los problemas de la anterior, y también muy conocida es SpringMVC. En otros lenguajes tenemos: El módulo de plantillas de Django para Python, ActionController y ActionView para Ruby o Zend para PHP Solución: Utilizar JSF Java Server Faces es una tecnología que aumenta el nivel de abstracción a la hora de construir interfaces gráficas basadas en web. Permite utilizar componentes Java como bloques de construcción y estos componentes se traducen a HTML antes de ser enviados al cliente. La utilización de JSF tiene las siguientes ventajas: Define un sistema mucho más modular y por lo tanto mucho más susceptible de reutilización. Existen muchas librerías que implementan componentes complejos listos para ser usados. En el caso de interfaces complicadas con funcionalidad AJAX permite escribir toda la lógica de presentación sin tener que utilizar JavaScript. y los siguientes inconvenientes: Tiene un sistema basado en componentes, más complejo que las vistas del patrón MVC2 y por lo tanto más difícil de entender, programar y la curva de aprendizaje puede ser elevada. Existen múltiples librerías de componentes JSF de código libre, siendo las de Apache las más conocidas y se recomienda su uso. JBoss RichFaces también contituyen también una alternativa recomendable especialmente si se usa JBoss Seam como framework de aplicación Conclusiones Utilizaremos un CMS cuando estemos implementando una

23 aplicación con mucho contenido estático y con poca lógica de negocio. Utilizaremos un framework MVC2 cuando estemos desarrollando una aplicación con un interfaz web no demasiado complejo. Utilizaremos un framework basado en JSF cuando desarrollemos una aplicación web con un interfaz gráfico complejo. 4.2Objetivo: Implementar interfaces con AJAX AJAX (Asynchronous JavaScript And XML) es una técnica cada vez más extendida para crear interfaces gráficas interactivas basadas en páginas web. Consiste en utilizar código JavaScript en el navegador para comunicarse con el servidor y generar o modificar dinámicamente elementos HTML de la página que se está mostrando en función de la respuesta. Utilizar AJAX implica añadir una complejidad extra al desarrollo de interfaces gráficas, a parte de que aumentan los problemas de accesibilidad, pero su difusión es imparable y las ventajas para el usuario son enormes, por lo tanto no se debe limitar su uso sino solventar las problemas que pueden aparecen. Los problemas de AJAX relacionados con la accesibilidad se exponen en el apartado Solución: utilizar una librería JavaScript La manera tradicional de implementar interfaces con AJAX es usando una de las múltiples librerías escritas en JavaScript. Las ventajas de este procedimiento son: Es fácil para interfaces sencillas. Proporciona un alto grado de control y suele implicar menos cambios en el servidor. Como contrapartidas tenemos: La complejidad aumenta exponencialmente con la complejidad del interfaz que se está desarroando. Es necesario tener conocimientos de JavaScript Existen muchas librerías AJAX. Las recomendadas son jquery, prototype+script.aculo.us y dojo-framework. Dentro de éstas jquery destaca por si sencillez y al ser no-intrusiva, adolece de menos problemas de

24 accesibilidad Solución: utilizar JSF Aunque JSF se creó antes que el AJAX (y por lo tanto no es una solución AJAX), ha resultado ser una herramienta muy útil cuando se desea implementar interfaces complejas de este tipo. Las ventajas de utilizar JSF para implementar AJAX son las siguientes: No hay grandes diferencias entre utilizar JSF sin AJAX y con ella. Se aprovecha la inversión de aprender JSF. No es necesario tener conocimientos de JavaScript Una vez se ha aprendido JSF, utilizar componentes AJAX es una tarea muy sencilla. Entre las desventajas, destacamos: Puede ser demasiado complejo para interfaces simples No se tiene tanto control como usando librerías JavaScript y puede resultar en fuertes cambios en la parte servidora. Las mismas consideraciones generales para librerías JSF (MyFaces y RichFaces) se pueden hacer extensibles al uso de componentes AJAX Conclusiones Si estamos utilizando JSF como solución de Presentación, tiene sentido utilizar la misma tecnología para implementar AJAX. Si no hemos elegido JSF en la capa de Presentación, será más fácil implementar AJAX utilizando alguna librería JavaScript. Si la interfaz es muy compleja o requiere de mucho AJAX debería plantearse la migración a JSF. 4.3Objetivo: Crear páginas web accesibles Uno de los objetivos de la capa de presentación es asegurar un nivel mínimo de accesibilidad de las páginas web generadas. Una web es más accesible cuanto más independiente es de los dispositivos o de las circunstancias que se utilicen para acceder a ellas W3C y WAI La W3C es un organismo que trabaja para establecer detalladamente los

25 requisitos que se han de cumplir las páginas web para que sean accesibles: una serie de puntos concretos (y comprobables) que un desarrollador web debe cumplir para hacer su página accesible. Estos puntos están divididos en tres grupos según la prioridad. Asimismo establece tres niveles de accesibilidad (A, AA y AAA) según se cumplan los puntos de cada uno de los grupos. La W3C tiene documentos explicando cuáles son cada uno de esos puntos (clasificados por prioridades) así como técnicas para lograr la accesibilidad, por lo que no tiene ningún sentido repetirlas aquí. También existe la Web Accessibility Initiative (WAI) que promueve la creación de contenidos accesibles y que ha desarrollado software para comprobar la accesibilidad e incluso ayudar a construir y reparar páginas web con problemas de este tipo Técnicas para facilitar la accesibilidad Aquí se presentan una serie de técnicas que, aplicadas, no logran que una página sea accesible pero que son el paso previo necesario para lograrlo. Hacer páginas web accesibles no es una tarea sencilla y por eso es importante planearlo desde un primer momento. Un objetivo general a la hora de escribir HTML debe ser el de tratar no mezclar el contenido ni con la estructura ni con el aspecto. Esto objetivo, que viene a ser una recomendación recurrente en todo este documento: dividir según un criterio preciso, se puede logar mediante: Utilizar XHTML y no HTML Elegir los elementos HTML (tags) por su significado semántico: ayuda a crear páginas mucho mejor estructuradas, fáciles de leer y mantener y, por lo tanto, más susceptibles de ser accesibles. Asegurar la funcionalidad básica de la página aún cuando deshabilitamos JavaScript en el navegador. No incluir información de estilo dentro del HTML Evitar utilizar tablas para posicionar los elementos en la página 4.3.3Accesibilidad y AJAX Debido a que la accesibilidad se resuelve con programas que analizan el contenido de las páginas web, todo generación dinámica (fundamental en interfaces AJAX) dificulta y puede llegar a impedir su identificación y por lo tanto hacer que la página deje de ser accesible. Esto no quiere decir que una página con AJAX sea inaccesible, sino que hay que poner aún más cuidado y esfuerzo para conseguir que la página siga siendo accesible a pesar de utilizar AJAX. También es interesante señalar que algunos de los componentes AJAX para JSF (por ejemplo MyFaces) tienen soporte para accesibilidad incluido.

26 4.3.4Evaluar la accesibilidad Gracias al trabajo de la W3C tenemos una serie herramientas públicas que permiten validar el nivel de cumplimiento de accesibilidad de las páginas web que producimos. TAW, por ejemplo, es la herramienta estándar de accesibilidad desarrollada en España. Asimismo navegadores como Firefox tienen un excelente soporte de herramientas en forma de plugins para comprobar la accesibilidad de un sitio web a medida que se desarrollan. 4.4Objetivo: Creación de interfaces personalizables Crear componentes en los que el aspecto visual se pueda modificar de manera sencilla es una de las mejores maneras de conseguir la reutilización de componentes. Se pueden clasificar los componentes por el grado de personalización posible o por el nivel técnico necesario para dicha personalización. Normalmente a mayor grado de personalización, mayor nivel técnico será necesario, aunque nuestro objetivo es mantener esta exigencia al menor nivel posible Técnicas para lograr interfaces personalizables No existe una única manera de permitir la personalización así como no existe un nivel de personalización mínimo. A continuación presentamos una serie de técnicas que nos ayudan en esta tarea: Utilizar un CMS como base de desarrollo Documentar exhaustivamente, especialmente en las partes susceptibles de ser modificadas Aplicar CSS de manera estricta: no introducir información de estilo en el HTML y utilizar enlaces en el CSS para introducir imágenes. Utilizar archivos de configuración: externalizar los parámetros modificables en archivos de texto sencillos (properties, YAML). Mantener una estructura de directorios coherente Mantener todos los archivos de configuración en el mismo lugar

27 5Construcción de la capa de Lógica de negocio La capa de Lógica de negocio es aquella encargada de implementar la funcionalidad del componente, bien sea porque se ha codificado o porque utilice una combinación de funcionalidades de componentes externos. Los desafíos técnicos relacionados con esta capa tienen más que ver con cómo disponer y hacer disponible la lógica de negocio que con la lógica en si misma. Los objetivos de este capítulo son: Asegurarnos de crear mecanismos que permitan la reutilización de esa lógica de negocio por otros componentes diferentes Definir un mecanismo estándar para poder utilizar la lógica de negocio de otros componentes disponibles en nuestro repositorio 5.1Servicios web Desde hace algunos años, la manera estándar de comunicar unos componentes con otros de una manera desacoplada es utilizando servicios web. Un servicio web es una parte de un sistema informático que permite a otros sistemas interaccionen con él a través de la red. Todos los servicios web disponen de: Un lenguaje de intercambio de datos: un lenguaje común y preestablecido tanto para el que publica como para el que consume. Un protocolo de comunicación: una serie de reglas para envío y recepción de datos así como para gestión de errores, autenticación y todo lo relativo al intercambio de datos. Un descriptor del servicio: un fichero con una serie de meta-datos sobre sí mismo: qué parámetros son imprescindibles y cuales opcionales para invocar el servicio, qué formato deben tener esos parámetros, etcétera, para que un consumidor pueda averiguar cómo invocar dicho servicio. Los descriptores de servicios están pensados para ser utilizados por un sistema informático y no para ser leídos por un humano, y por lo tanto, los no sustituyen a la necesaria documentación que hay que aportar sobre los servicios que se publican. Un servicio web es un concepto teórico y por lo tanto no está ligado a ninguna tecnología concreta. Hay varias implementaciones de un servicio web, siendo las dos más extendidas WebServices y RESTful Services. Es decir, en este documento distinguimos entre servicio web

28 (como concepto abstracto) y WebServices y RESTful Services como maneras diferentes de implementar este concepto. Los WebServices se caracterizan por utilizar XML como lenguaje de intercambio, SOAP como protocolo de comunicación y WDSL como formato de descripción del servicio. Este es el estándar definido por WS-I, organización que promueve la interoperabilidad de servicios web. Los RESTful Services son un tipo de servicios web que están en auge fundamentalmente porque son muy fáciles de implementar en determinadas circunstancias y son (supuestamente) más escalables al eliminar la necesidad de mantener ningún tipo de estado. Utilizan XML como lenguaje de intercambio, HTTP tanto como protocolo de comunicación como descriptor de servicio. En general es aconsejable utilizar e implementar servicios del tipo WebServices aunque se considerarán los RESTful Services en los casos en los que el objetivo es trabajar con listas de datos y las operaciones sobre estos datos son las definidas en el protocolo HTTP (GET, POST, PUT y DELETE) 5.2Objetivo: permitir a otros componentes operar con el nuestro En coherencia con lo definido anteriormente, el mecanismo que utilizaremos para cumplir este objetivo será publicando servicios web. Entendemos por publicar un servicio web el hecho de poner accesible y disponible una lógica de negocio mediante un mecanismo remoto Cuándo publicar servicios web El objetivo de publicar servicios web es el de proporcionar una interfaz definida para usar poder usar la funcionalidad que estamos desarrollando por otro componente externo. Un error muy frecuente consiste en utilizar los servicios web para conectar capas de un mismo componente. El ejemplo más habitual de este error es publicar una serie de servicios web para conectar la capa de negocio con la capa de persistencia con el fin de desacoplar ambas capas: se crea un componente con capa de persistencia y negocio y otro con capa de presentación y se conectan ambos con servicios web. Lo ideal es crear un solo componente con las tres capas y además publicar servicios web. Existen otras técnicas para lograr el desacoplamiento entre capas internas de otra aplicación (léase patrón DAO, patrón MVC, etcétera), por lo tanto no deben utilizarse servicios web para conectar capas de una misma aplicación. Por este motivo lo normal es que un componente no use sus propios servicios, sino que simplemente publique éstos para que otros componentes puedan usarlos.

29 5.2.2Qué servicios web publicar El problema general a la hora de desarrollar los servicios web tiene que ver con la granularidad, es decir, qué y cuántos servicios se publican. En general y por una cuestión de eficiencia, el nivel de granularidad debe ser lo más amplio posible: una llamada al servicio debe ser suficiente para cubrir la necesidad de un cliente de este componente. Un error común es duplicar un API utilizando servicios web. Las APIs tienen un nivel de granularidad mucho menor que los servicios web: una llamada a un servicio web generalmente es equivalente a varias llamadas a un API Solución: publicar WebServices En general (y como siempre) se desaconseja implementar WebServices sin hacer uso de alguna de las muchas librerías que existen para este propósito. Las librerías más conocidas y recomendadas dentro del entorno Java son Apache Axis2 y Spring WebService. NetBeans es una entorno de desarrollo integrado (IDE) que tiene un excelente soporte para el desarrollo de servicios web. Implementar WebServices incluye dos actividades: crear el archivo WDSL e implementar el código de ese servicio y existen dos estilos a la hora de implementarlos: crear el WDSL y generar el esqueleto del código o crear el código y generar el WDSL. Aunque la segunda técnica es más sencilla de implementar, el WDSL tiene la limitación de que no debería variar una vez hecho publico este servicio (porque significaría reescribir todos los componentes que utilizan el ese servicio) por lo que se recomienda escribir manualmente el WDSL (no generarlo) y controlar con cuidado los cambios que se introducen en él Documentar servicios web Es necesario aportar documentación sobre los servicios web que publica un componente. Como se ha comentado, aunque se puede obtener mucha información sobre el servicio utilizando el WDSL, éste nunca puede servir como sustituto de dicha documentación. En la documentación aportada debe figurar: Nombre y descripción funcional de cada uno de los servicios publicados Para cada uno de los servicios, qué parámetros necesita de entrada y qué devuelve (incluyendo el formato de la estructura XML resultante)

30 Para cada uno de los servicios, en qué URL se publica. 5.3Objetivo: utilizar la lógica de negocio de componentes externos En sistemas complejos es muy frecuente la necesidad de utilizar servicios que proporcionan componentes externos. La solución obvia: utilizar sus servicios web, pero no siempre estos componentes publican servicios web. Aquí ofrecemos soluciones para ambos casos Solución: consumir servicios web Consumir servicios web y en concreto WebServices es una tarea relativamente sencilla si se cuenta con las herramientas adecuadas. La práctica totalidad de los lenguajes de programación tienen librerías para este propósito y su uso es altamente recomendable. En concreto hay una operación necesaria y cuya escritura resulta tediosa, propensa a errores y fácilmente automatizable que consiste en convertir los datos en formato XML a objetos de la lógica de negocio. Se deberá utilizar una librería de conversión automática para este propósito. Uno de los objetivos de utilizar servicios web es el de desacoplar los componentes implicados, por lo tanto la primera medida que tenemos que aplicar para consumir servicios web consistirá en colocar todos los datos relativos al servicio (URL, puerto ) en archivos de configuración externos Solución: crear una capa de servicios web para componentes que no la implementen de serie Algunos de los componentes de aministración electónica más utilizados, aunque proveen mecanismos de interoperatibilidad, no suelen usar servicios web sino API propietarias en el lenguaje de implementación y por lo tanto la integración resulta costosa o imposible si no utilizamos el lenguaje original en que están implementados estos componentes (normalmente Java) La solución consistirá en escribir un pequeño componente que envuelva al componente original (wrapper) con una capa de servicios web, es decir: crear un componente cuya única capa sea la de negocio y cuyo único objetivo sea traducir llamadas a través de servicios web a llamadas al componente original. Antes de desarrollar este componente es preciso asegurarse de que otros proyectos no lo han hecho antes. Ya que uno de los objetivos globales es la reutilización y que el número de componentes sin servicios web es bastante limitado, puede ser que existan implementaciones presentes en el repositorio de software libre de la Junta de Andalucía.