Manual de desarrollo de aplicaciones J2EE (0.5Mb) - Gobierno del ...

Manual de Desarrollo de Aplicaciones J2EE

Manual de Desarrollo de Aplicaciones J2EE Versión 1.5 publicado 26-Junio-2006 Copyright © Gobierno del Principado de Asturias 2005

Tabla de contenidos 1. Presentación de openFWPA .............................................................................................. 1 Introducción .............................................................................................................. 1 Visión General de openFWPA ...................................................................................... 2 Empaquetamiento de openFWPA .......................................................................... 4 Requerimientos técnicos y de sistema ..................................................................... 5 Lista completa de funcionalidades ......................................................................... 5 Lista de componentes de terceras partes .................................................................. 6 Arquitectura de referencia ............................................................................................ 8 Desarrollo de aplicaciones .......................................................................................... 10 Estructura de directorios ..................................................................................... 10 Compilación y despliegue del sistema ................................................................... 11 Pruebas unitarias ............................................................................................... 11 Instalación de la aplicación de ejemplo (Sample App) .............................................. 11 2. Arquitectura Modelo -Vista- Controlador con openFWPA ..................................................... 13 MVC ...................................................................................................................... 13 Desarrollo de la Vista ................................................................................................ 14 Aspecto corporativo de las aplicaciones del Principado de Asturias ............................. 14 Cascading Style Sheets (CSS) ............................................................................. 14 Desarrollo del Controlador ......................................................................................... 16 Declaración de Actions ...................................................................................... 16 Jerarquía de Actions .......................................................................................... 17 Action Forms ............................................................................................. 29 Desarrollo de lógica de negocio .................................................................................. 31 Service Locator ................................................................................................ 31 Session EJBs .................................................................................................... 31 Value Objects .................................................................................................. 31 Excepciones ..................................................................................................... 32 Utilidades ........................................................................................................ 33 Otras clases de utilidad .............................................................................................. 33 PrincastMessageFmtter ............................................................................ 33 PrincastUtils ............................................................................................ 33 ParameterCaster ........................................................................................ 33 ServletPathUtils ...................................................................................... 33 DateDecorator ............................................................................................ 34 PrincastPathResolver .............................................................................. 34 PrincastOSCacheInterceptor .................................................................. 35 Providers ......................................................................................................... 35 3. Implementación de la Arquitectura de Referencia con openFWPA .......................................... 37 Inversión de Control en la Arquitectura de Referencia ..................................................... 37 Introducción al manejo de la Arquitectura con Spring ...................................................... 37 Estableciendo el Datasource ........................................................................................ 38 Enlazando con los DAOs ........................................................................................... 39 Enlazando con los Managers ....................................................................................... 40 Gestión de transacciones ............................................................................................ 41 Enlazado con los Delegates ........................................................................................ 42 Enlazado con las Actions ........................................................................................... 42 Acceso directo al ApplicationContext ................................................................. 43 BeanDoc para obtener la gráfica de arquitectura ............................................................. 43 Plugin SpringIDE para Eclipse .................................................................................... 43 4. Componentes para acceso a datos ..................................................................................... 45 Acceso a Bases de Datos Relacionales .......................................................................... 45

iv

Manual de Desarrollo de Aplicaciones J2EE

5.

6.

7.

8.

9.

El patrón DAO ................................................................................................. 45 Loggeo de las Excepciones en los DAO ................................................................ 47 Listas clave/valor .............................................................................................. 47 LookupPropertyBean .................................................................................. 49 Providers ......................................................................................................... 49 Generadores de Secuencia .................................................................................. 49 Pools de conexiones .......................................................................................... 50 Construccion de informes con openFWPA ......................................................................... 51 Generación de Informes ............................................................................................. 51 Creación de los diseños XML. ............................................................................ 51 Clases en el openFWPA para la renderización de informes. ...................................... 57 Operaciones ................................................................................................................. 61 Sistema de Inicialización y Arranque ............................................................................ 61 Declaración de objetos inicializables .................................................................... 61 Desarrollo de objetos inicializables ...................................................................... 62 Arranque de aplicaciones web ............................................................................. 63 Arranque manual .............................................................................................. 63 Sistema de Configuración de Aplicaciones .................................................................... 63 Implementación de objetos configurables .............................................................. 64 Plugins de Configuración ................................................................................... 66 Logging .................................................................................................................. 72 Log4J. Componentes ......................................................................................... 72 Configuración ................................................................................................... 74 Componentes del openFWPA para Logging. .......................................................... 75 Pista de auditoría .............................................................................................. 76 Pista de Rendimiento ......................................................................................... 77 Ficheros de Configuración .......................................................................................... 77 web.xml ........................................................................................................ 77 struts-config.xml .................................................................................... 79 Filtros web .............................................................................................................. 83 Filtros del openFWPA. PrincastFilter. ......................................................... 83 Configuración del filtro GZIPFilter ................................................................. 85 Configuración del filtro SecurityFilter ......................................................... 85 Filtro de navegación .......................................................................................... 85 Filtro de activación ........................................................................................... 86 Filtros de Activación ......................................................................................... 87 Consola de gestión .................................................................................................... 88 Seguridad en aplicaciones con openFWPA ......................................................................... 90 Seguridad ................................................................................................................ 90 Autentificación básica ........................................................................................ 90 Autentificación basada en formulario .................................................................... 90 Autentificación basada en el Filtro de Seguridad del openFWPA ............................... 90 Single Sign On ............................................................................................... 103 Integración de Sistemas ................................................................................................ 104 Tecnologías de Integración ....................................................................................... 104 XML Genérico: Configuración .......................................................................... 104 Pruebas ...................................................................................................................... 106 Pruebas unitarias ..................................................................................................... 106 Jerarquía de clases para las pruebas unitarias ........................................................ 106 Convenciones a seguir ..................................................................................... 107 Ejecución de las pruebas unitarias ...................................................................... 107 Consultando los resultados de los tests ................................................................ 107 Pruebas unitarias de objetos que acceden a bases de datos. ...................................... 108 Pruebas unitarias de Spring Beans ...................................................................... 112

v

Manual de Desarrollo de Aplicaciones J2EE Pruebas unitarias de objetos Configurables .................................................... Pruebas unitarias en contenedor ......................................................................... Pruebas unitarias de informes ............................................................................ Más información sobre la implementación de pruebas unitarias ................................ Pruebas de Rendimiento ........................................................................................... Modo de Prueba de Rendimiento .......................................................................

vi

112 113 114 115 116 116

Lista de figuras 1.1. Estructura de openFWPA ............................................................................................... 2 1.2. Arquitectura de Referencia ............................................................................................. 8 1.3. Estructura de directorios del proyecto Sample App. ........................................................... 10 2.1. Modelo Vista Controlador ............................................................................................ 13 2.2. Ciclo petición-acción-jsp de Struts ................................................................................. 13 2.3. Estructura de capas de las aplicaciones web con openFWPA ............................................... 14 2.4. Aspecto corporativo del portal princast.es ................................................................ 14 2.5. Aspecto de la aplicación de ejemplo (Sample App) ........................................................... 14 2.6. Jerarquía de Actions .................................................................................................... 17 2.7. Maquinaria de Estados de PrincastAction ................................................................ 18 2.8. Almacenamiento de la Action .................................................................................... 21 2.9. Esquema de la PrincastDispatchAction del ejemplo ............................................... 25 2.10. Esquema de las Actions para listados ............................................................................ 28 2.11. Estructura de la capa Modelo ...................................................................................... 31 2.12. Diagrama de Value Objects ........................................................................................ 32 2.13. Jerarquía de Excepciones ............................................................................................ 32 3.1. Ficheros de configuración de Beans ............................................................................... 37 3.2. Ejemplo de gráfica generada con BeanDoc ...................................................................... 43 3.3. Spring IDE para visualizar ficheros de Spring .................................................................. 44 4.1. Ejemplo de necesidad de lookup .................................................................................... 49 4.2. Navegación de una relación en BD con un LookupPropertyBean ......................................... 49 5.1. Proceso de generación de informes ................................................................................ 51 6.1. Estructura del sistema de configuración .......................................................................... 64 6.2. Jerarquía de Plugins .................................................................................................... 68 6.3. Estados del Sistema de Logging .................................................................................... 74 7.1. Esquema del sistema de autenticación ............................................................................ 91 9.1. Set de pruebas unitarias disponibles .............................................................................. 106 9.2. Autowiring de DAOs y DataSources ............................................................................ 110

vii

Lista de tablas 1.1. Componentes necesarios para la ejecución del openFWPA ................................................... 7 1.2. Capas de la Arquitectura de Referencia de openFWPA ........................................................ 9

viii

Capítulo 1. Presentación de openFWPA Introducción openFWPA es el framework de desarrollo libre para sistemas de administración electrónica y gobierno electrónico desarrollado por el Gobierno del Principado de Asturias. Está basado en la tecnología J2EE y su objetivo es facilitar el diseño, implementación, implantación y mantenimiento de las aplicaciones. openFWPA es Software Libre / Open Source y está publicado bajo una doble licencia: LGPL 3.0 (o superior) y EUPL 1.0 (o superior). La Licencia Pública General Menor del proyecto GNU (LGPL) es una de las licencias desarrolladas y promovidas por la Free Software Foundation (FSF), y da permisos de reproducción, distribución, modificación y redistribución con copyleft, aunque no se impide la utilización de componentes privativos dentro del sistema. La Licencia Pública de la Unión Europea (EUPL) es una licencia de software libre con copyleft creada y apoyada por la Unión Europea para el impulso del Software Libre en las administraciones públicas. Los dos grandes objetivos del framework son: • Simplificación y homogeneización del proceso de desarrollo de aplicaciones. Para ello openFWPA proporciona una arquitectura reutilizable y un conjunto de herramientas y librerías que implementan algunos de los componentes más habituales, y de escritura más tediosa, en aplicaciones web. Todo ello debiera redundar en un menor coste total de propiedad (TCO) de las soluciones desarrolladas sobre openFWPA. • Definición de estándares de desarrollo, calidad y aceptación. Se trata de un conjunto de directrices, de obligado cumplimiento, para exigir y garantizar unos niveles mínimos de calidad en las aplicaciones J2EE [1]. Estos estándares son internos al Principado de Asturias, y son por tanto aplicables solamente dentro de aquellos proyectos desarrollados dentro del Principado de Asturias. El openFWPA posee las siguientes características: • Uso de software libre. Hay una serie de proyectos del mundo del software libre que poseen una excelente calidad, lo que los habilita para participar en aplicaciones de misión crítica. • Uso de patrones de diseño. El openFWPA promueve el uso de patrones de diseño, en dos sentidos importantes. En primer lugar, el framework está diseñado y construido sobre patrones. Por otro lado, las aplicaciones que se desarrollan sobre el framework hacen uso asimismo de patrones. Entre otros, las aplicaciones desarrolladas sobre openFWPA siguen una arquitectura Modelo2 , el estándar en aplicaciones web (se trata de una adaptación del famoso MVC). • Uso de estándares. En el diseño del openFWPA se ha promovido la utilización e incorporación de estándares (por ejemplo, XHTML [4] + CSS [14], etc.). El uso tanto de patrones de diseño como de estándares proporciona importantes ventajas en cuanto a la adaptabilidad y longevidad de las aplicaciones que los utilizan, al ser más fácilmente mantenidas, extendidas o reutilizadas. • Aspecto corporativo. Otra característica importante es que las aplicaciones deben integrarse con el resto de aplicaciones del Principado de Asturias, tanto a nivel funcional como de aspecto (look & feel). El openFWPA incluye un conjunto de plantillas y componentes para construir la capa de presentación de acuerdo a las guías de estilo corporativo del Principado de Asturias. En la versión publicada en portal, estas plantillas pueden modificarse de acuerdo a las necesidades de cada proyecto. Sin embargo, los proyectos internos han de seguir las directrices de estilo corporativo. • Integración de aplicaciones. La nueva funcionalidad, añadida al openFWPA en las últimas versiones, facilita la integración de las aplicaciones con otros sistemas del Principado de Asturias (sistema de seguridad, comunicaciones, bases de datos corporativas, sistemas de seguridad, sistemas de CRM, etc.).

1

Presentación de openFWPA

Esta funcionalidad solo está disponible para los proyectos internos, al carecer de interés en aplicaciones desarrolladas fuera de la organización. • Ciclo de vida. Las aplicaciones poseen un ciclo de vida más allá de su desarrollo y puesta en producción. Éstas han de ser configuradas, migradas y operadas en los diversos entornos. Por ejemplo, el framework proporciona piezas con una funcionalidad importante que facilita el soporte a la operación. Los componentes del framework están preparados para ser gestionados “en caliente” desde una consola de operaciones, y ofrece componentes para aspectos críticos de operación (como gestión adecuada de logging, pistas de auditoría, estadísticas de rendimiento y uso). En general, estos aspectos se incorporan al framework de manera transparente a las aplicaciones. Asimismo, se ofrece (opcionalmente) una serie de APIs avanzadas que permiten a las aplicaciones publicar funcionalidad en la consola de operaciones.

Visión General de openFWPA El framework de desarrollo J2EE del Principado de Asturias posee la siguiente estructura. Dentro de cada elemento se muestran los artefactos más relevantes:

Figura 1.1. Estructura de openFWPA

A continuación, se muestran en más detalle los diversos elementos que lo componen. Aceptación

Las aplicaciones desarrolladas con el framework para uso interno del Principado de Asturias deben pasar por una serie de controles de calidad. A tal efecto, se han desarrollado una serie de guías que deben seguirse para el desarrollo de estas aplicaciones. Dentro de esta guía de aceptación se define una arquitectura reutilizable que debieran seguir las aplicaciones.

Entorno de desarrollo

El framework de desarrollo es agnóstico en cuanto al entorno de desarrollo. Éste debiera poseer los siguientes elementos: • Entorno Integrado de desarrollo. Ofrece un entorno donde los desarrolladores pueden desarrollar, compilar, depurar y probar el software en construcción. • Herramientas de despliegue. Permite el despliegue de las aplicaciones en los distintos entornos (máquina local, máquinas del entorno de desarrollo, etc.). • Diseño de informes. Permite la construcción de informes en distintos formatos. • Gestión de la configuración. Permite la gestión del cambio de los distintos elementos del sistema (código fuente, scripts de construcción, pruebas, etc.). Se trata de un sistema de control de versiones. • Entorno de integración (semi) continua. El entorno de desarrollo debiera ofrecer funcionalidad avanzada de integración continua o semi-continua. Los proyectos arrancados dentro del Principado de Asturias deben poseer las herramientas definidas en el puesto estándar. Estas

2


herramientas deben instalarse y configurarse de manera estándar (igual para todas las estaciones de trabajo). Software Libre

Tras la definición de los requisitos del framework en términos de herramientas necesarias para el entorno de desarrollo, directrices de aceptación y diseño del runtime del framework, se realizó la selección de distintos componentes del mundo del código abierto o gratuito para su inclusión. Por ejemplo, se seleccionó Eclipse como Entorno Integrado de Desarrollo, o CVS para el Control de Versiones. Como elementos más relevantes, destaca el uso de Eclipse, Spring o Struts.

Sistema de tiempo de ejecución

El sistema de tiempo de ejecución es un conjunto de ficheros .jar que se despliegan con cada una de las aplicaciones del framework. Este sistema sigue las directrices de construcción de aplicaciones, y ofrece componentes reutilizables y una base extensible para el desarrollo basado fuertemente en patrones de diseño. De esta manera, las aplicaciones se reducen en tamaño y complejidad, teniendo todas la misma estructura interna (basada en una adaptación del patrón MVC llamada Modelo2). El sistema de tiempo de ejecución emplea diversos componentes del mundo de código abierto, usando lo mejor de cada uno de ellos e integrándolos. Esta aproximación ha facilitado enormemente el desarrollo, y emplea internamente dos frameworks – Struts y Spring.

Módulos de integración

Los sistemas a construir dentro del ámbito de la Administración del Principado de Asturias presentan una fuerte componente de integración con otros sistemas. Se han escrito adaptadores para los distintos sistemas corporativos existentes dentro de la organización, de manera que se simplifica y homogeneíza enormemente las tareas de integración siguiendo un patrón proxy. Estos módulos solo están disponibles para aquellos proyectos realizados para el Principado de Asturias.

Seguridad

Es crucial que las aplicaciones desarrolladas posean un nivel de seguridad suficiente, y que esta seguridad pueda gestionarse centralmente desde los sistemas corporativos de seguridad. A este fin, se ha desarrollado toda una infraestructura de seguridad sobre estándares (X509, Java Authentication and Authorization Service, Web Services, etc.). Desde el punto de vista de la aplicación, se trata de realizar una parametrización. Toda esta infraestructura es extensible. Dado que determinados proyectos se desarrollan por equipos externos sin acceso a la infraestructura del Principado de Asturias, se incluye un simulador de autenticación, de manera que determinados escenarios pueden ejecutarse empleando un documento XML en local como repositorio de credenciales. Asimismo, esta infraestructura es extensible, de manera que pueden desarrollarse adaptadores a otros repositorios (LDAP, etc) en proyectos ajenos al Principado de Asturias.

Operación

Las aplicaciones han de ser operadas en los distintos entornos, de manera que el personal de operaciones pueda mantener la

3


aplicación en funcionamiento. El framework posee una serie de herramientas que facilitan esta operación, como pueden ser: • Filtro de compresión. El framework proporciona un filtro de compresión de las comunicaciones, de manera que se minimice la comunicación entre el servidor y el cliente. • Manual de Operaciones. En este documento se describen las operaciones que pueden realizarse sobre la aplicación desplegada. • Configuración. El framework posee un subsistema flexible de configuración, de manera que las aplicaciones se aislan de los repositorios de configuración. • Auditoría. Se proporciona funcionalidad para la generación de pistas de auditoría. • Gestión de logs. El framework proporciona un potente sistema de logs, de manera que (por configuración) puede enviarse los mensajes a una BD, a ficheros de texto, XML, HTML, etc. Esta configuración puede cambiarse en caliente. • Consola de Administración. Las aplicaciones desarrolladas con el framework poseen una consola de administración web para la modificación de los distintos componentes. • Métricas de uso. Pueden habilitarse diversas métricas de uso de la aplicación, de manera transparente para las aplicaciones. Documentación

Con el framework se entrega toda la documentación necesaria para el desarrollo y operación de aplicaciones. Se entregan una aplicación de ejemplo (con sus pruebas de rendimiento correspondientes) y una aplicación en blanco, con la estructura de directorios creada.

Soporte

Existe un sitio de soporte para la resolución de dudas, incidencias, etc. Este sitio web de soporte permite comunicar al equipo de mantenimiento del framework bugs detectados, etc. de manera que se pueda liberar una nueva entrega (release) con los defectos corregidos. A tal efecto, se crea un usuario para cada equipo de desarrollo que demande soporte, para que puedan realizar un seguimiento consistente de las incidencias que puedan surgir.

Empaquetamiento de openFWPA El conjunto completo de entregables que puede acompaña al openFWPA es el que sigue. En algunas distribuciones, pueden no estar disponibles determinados elementos: • Manual del desarrollador. (Este documento). • Manual de operaciones. • Manual de configuración de la seguridad. • Directrices de aceptación de aplicaciones J2EE del Principado de Asturias.

4


• Herramientas del desarrollador. • Guía de estilo del lenguaje Java • Guía de estilo del lenguaje JSP. • openFWPA. (binarios) • Aplicación de ejemplo: SampleApp (binarios y fuentes) • Aplicación en blanco: App Blank (binarios y fuentes)

Requerimientos técnicos y de sistema Para la correcta ejecución de las aplicaciones que utilizan el openFWPA es necesario disponer de los siguientes elementos: • Librerías de soporte (Ver “Lista de componentes de terceras partes”) • Servidor de aplicaciones Oracle10G OC4J (versión 10.1.2) con Java JRE 1.4.2 Determinadas partes de la aplicación requieren además, los siguientes componentes: a. Seguridad: • Certificado Raíz de la Fabrica Nacional de Moneda y Timbre (FNMT) • Fichero de certificados (cacerts) en la máquina virtual

Lista completa de funcionalidades Las funcionalidades soportadas por el openFWPA son las siguientes: • Extensión del framework Struts [8] con una colección propia de clases Action. • Acceso a datos a través de objetos DAO. • Automatización de la carga de consultas SQL desde ficheros de propiedades. • Plantillas (Tiles) para la creación rápida de páginas JSP. • Hojas de estilos con el look & feel del Principado de Asturias. • Facilidades para la generación de informes en formato PDF. • Etiquetas JSP para la inclusión de listas, barras de navegación, fechas y calendarios en las páginas web. • Integración de formularios (ActionForm) con entidades (ValueObject) de la aplicación. • Utilidades para la gestión de tablas de datos en formato {atributo, valor}. • Facilidades para la obtención de listas paginadas como resultado de consultas. • Herramienta para la generación automática de menús. 5


• Infraestructura para pruebas unitarias. • Infraestructura para pruebas unitarias en contenedor. • Integración de una consola de monitorización y gestión basada en el estándar JMX [19]. • Jerarquía propia de excepciones. • Monitorización y control integrado de errores • Sistema de configuración centralizado. • Sistema de inicialización y arranque configurable. • Componentes para el acceso a pools de conexiones. • Sistema de logging con varios niveles. • Gestión de logging desde la consola de administración. • Monitor de rendimiento. • Sistema de monitorización para las clases Action. • Generación de estadísticas de acceso a las aplicaciones. • Generación de estadísticas de excepciones no controladas en las aplicaciones. • Componente para monitorizar el estado del sistema sobre el que corre la aplicación. • Infraestructura para filtros gestionados “en caliente”. • Filtro para compresión GZIP. • Inicialización de componentes configurables. • Filtro de seguridad para integración con el Módulo de Autenticación del SAC del Principado de Asturias. • Conexión con backends del Principado de Asturias (Claves, Terceros, Siebel, Módulo Común de SMS).

Lista de componentes de terceras partes El framework de desarrollo del Principado de Asturias incorpora componentes de terceras partes. Las aplicaciones que se construyan sobre el framework han de utilizar las versiones enumeradas en

6

Fundación Apache. Struts Menu

sourceforge.net

struts-menu.jar struts-menu.tld struts-menu-el.tld Presentación de openFWPA

2.2

Librería para facilitar el desarrollo de menús en aplicaciones web.

Tabla necesarios para la ejecución Apache1.1. Ant Componentes ASF 1.6.1del openFWPA Herramienta

para la automatización de las operaciones de compilación, construcción y despliegue de proyectos.

Java SDK

Sun Microsystems

1.3.1_11 - 1.4.x

Conjunto herramientas librerías Java.

de y

Oracle AS9i

Oracle

9.0.3.0.0 - 10.1.2

Servidor aplicaciones Oracle.

de de

JMX Reference Sun Microsystems jmxri.jar Implementation jmxgrinder.jar jmxtools.jar

1.0

Librería para la gestión dinámica de aplicaciones Java (sólo es necesaria con OC4J 9.0.3).

Base de Oraclae

8.1.7.3

Sistema de Gestión de Bases de Datos.

0.6.0

Herramienta para la generación de informes en diferentes formatos: PDF, HTML, XLS, CSV y XML.

oc4.jar admin.jar

Datos Oracle

Jasper Reports

sourceforge.net

JSSE

Sun Microsystems jsse.jar

1.0.3_03

Proporciona soporte para la conexión bajo protocolo SSL.

JAAS

Sun Microsystems jaas.jar

1.0

Proporciona soporte para autentificación y autorización.

JCE

Sun Microsystems jce.jar 1.2.2 local_policy.jar sunjce_provider.jar US_export_policy.jar

Proporciona soporte para uso de protocolos de encriptación.

JDBC

Sun Microsystems jdbc2_0-stdext.jar

2.0

Extensiones JDBC para la compilación con versión 1.3.1_11 de la JDK.

Spring

Spring Framework spring.jar

1.2.6

Framework IoC.

Java Monitor API

JAMon API

JAMon.jar

1.1.2

Librería de monitorización y medición de tiempos

dwr.jar

1.0

Librería de AJAX

Direct Web Get Ahead Remoting (DWR)

jasperreports.jar

7


Arquitectura de referencia El framework de desarrollo del Principado de Asturias hace un uso intensivo de Patrones de Diseño. A fin de lograr una homogeneidad efectiva en las aplicaciones realizadas en el marco del Principado de Asturias, se propone una Arquitectura de Referencia que describe la arquitectura de las aplicaciones desarrolladas con el openFWPA. El uso de esta arquitectura de referencia es obligatorio, al ser parte de las Directrices de Aceptación de aplicaciones. Una arquitectura de referencia es una descripción de los elementos de los que se compone una aplicación, y de las relaciones entre estos elementos. Manejar arquitecturas de referencia es tremendamente beneficioso, ya que permite: Homogeneizar las aplicaciones. Al usar la arquitectura de referencia, las aplicaciones son estructuralmente iguales, cambiando sólo los elementos en concreto, pero no la forma que tienen de relacionarse. Esto tiene un impacto directo en el esfuerzo en desarrollo y mantenimiento. Extender las mejores prácticas y tecnologías. La arquitectura de referencia ha de mantenerse, de manera que se vayan introduciendo cambios basados en cambios tecnológicos o en el establecimiento de mejores prácticas. La arquitectura de referencia J2EE propuesta se basa en el patrón Modelo2 sobre una disposición en capas, y puede verse en el siguiente diagrama:

Figura 1.2. Arquitectura de Referencia

El concepto de separación en capas está claramente definido en esta arquitectura de referencia: La comunicación entre capas sólo puede existir a través de a) interfaces, b) Objetos de Datos (Value Objects). Los elementos de la arquitectura de referencia pueden verse en la siguiente tabla:

8


Tabla 1.2. Capas de la Arquitectura de Referencia de openFWPA Elemento

Descripción

Patrones relevantes

Capa de Acceso a Datos

Encapsula toda la lógica de acceso Data Access Object Proxy Value a datos. Asimismo, encapsula los Object Absctract Factory accesos a sistemas remotos.

Capa de Objetos de Datos

Representa las entidades del Value Object modelo, como objetos JavaBean y sin lógica de negocio.

Capa de Negocio

Implementa toda la lógica de Business Delegate Façade negocio, implementada como procesos sobre la capa de Acceso a Datos. Oculta toda la comlejidad a la capa superior.

Capa de Controlador

Transforma eventos en la vista a MVC Command eventos en el modelo, y viceversa.

Capa de Vista

Presenta el modelo al usuario, MVC y comunica sus acciones al controlador

Filtro web

Permiten filtrar las peticiones de Chain Of Responsibility los clientes, a fin de propor-cionar autenticación, asertos a toda la aplicación, compresión de datos, etc.

Datasource

Gestiona pools de conexiones, a fin de no crear una conexión por cliente a Base de Datos u otros repositorios.

Gestión de sesión

Gestiona la sesión de los clientes, de manera que desconecta a los inactivos.

Sistema externo

Representa cualquier sistema a integrar a través de un interfaz bien definido.

Dado el número de librerías que implementan el patrón MVC, tiene todo el sentido usar alguna de ellas en vez de implementarlo para un proyecto. El openFWPA da soporte para este patrón. Caso de ser una aplicación J2EE no construida sobre el openFWPA, debiera hacer uso del framework Struts. Una vez fijada la arquitectura de referencia, se ha acudido al mundo del software libre buscando implementaciones de los elementos reseñados en ella. Por ejemplo, para la capa del controlador se ha optado por usar una implementación de un proyecto del software libre en vez de proceder a realizar una implementación propia. Asimismo, el openFWPA ofrece soporte en la implementación de todas las capas, desde acceso a datos hasta presentación. En general, prácticamente todas las librerías utilizadas por el openFWPA provienen de la Apache Software Foundation (ASF) [5] y también pueden ser consideradas como estándares “de facto” en sus respectivas áreas. Las librerías proporcionadas por la ASF, son de código libre y abierto, están mantenidas por un nutrido grupo de desarrolladores de todo el mundo y son muy habituales en proyectos de desarrollo (principalmente Java) de cualquier índole.

9


Desarrollo de aplicaciones Antes de comenzar el desarrollo de una aplicación web con el openFWPA, es importante tener en cuenta las directrices y recomendaciones que se indican en este apartado.

Estructura de directorios Las aplicaciones definirán una estructura de directorios siguiendo la plantilla: • build, target: Contendrá los .class generados para el proyecto. • db: Contendrá los scripts de creación de la base de datos o la propia base de datos. En caso de darse soporte a más de una base de datos o más de una versión, ha de crearse un directorio para cada una de las BD. • config: Contendrá los ficheros necesarios para la creación del fichero EAR necesario para desplegar la aplicación en el contenedor J2EE (como por ejemplo application.xml), así como los ficheros con la información necesaria para la configuración de recursos que necesitará la aplicación (por ejemplo DataSources. En este caso podría incluirse un fichero data-sources.xml con la información a añadir al fichero data-soruces.xml del contenedor J2EE para la definición de los mismos). • src: Este directorio contendrá dos subdirectorios: • java: Contendrá los ficheros de código fuente Java y de recursos de la aplicación, y el fichero build.xml. • webapp: • pages: Contendrá el resto de ficheros de la aplicación: páginas HTML, JSP, imágenes, hojas de estilo CSS, etc. • WEB-INF: Contendrá los ficheros de configuración XML (web.xml, struts-config.xml, validation.xml, etc.), DTDs y TLDs. • lib: Contendrá las librerías que será necesario distribuir con la aplicación, puesto que no estarán incluidas en el contenedor J2EE. • ejbApp: • META-INF: Contendrá el fichero de MANIFEST.MF, así como los ficheros necesarios para el despliegue de EJBs en caso de que sean utilizados en la aplicación. Estos ficheros sería ejbjar.xml, orion-ejb-jar.xml, … y cualquier otro fichero que fuera necesario. • dist: Se trata de un directorio temporal empleado para la generación de los jars, ears,… necesarios para el proyecto. • javadoc: Contiene el javadoc generado con el target de Ant incluido al efecto. Como ejemplo se muestra la estructura de la aplicación de ejemplo (Sample App):

Figura 1.3. Estructura de directorios del proyecto Sample App.

10


Compilación y despliegue del sistema Para la compilación y el despliegue de aplicaciones se utilizará la herramienta Ant [10] (http:// ant.apache.org). Ant es una herramienta de construcción basada en Java similar al clásico Make. Los ficheros de configuración de Ant están escritos en XML y tienen por nombre build.xml. Cada uno de ellos contiene un project y al menos un target (el default, que será el que se ejecutará si no se especifica ningún otro en la llamada a Ant). Cada uno de ellos será el encargado de la compilación, empaquetado, despliegue en el contenedor J2EE, etc. de la aplicación. Con las aplicaciones en blanco (Blank App) de ejemplo (Sample App) de distribuye un fichero build.xml. Los targets más relevantes son los siguientes: • all (default): Realiza lo mismo que make-ear. • compile: Compila los ficheros fuente Java de la aplicación. • javadoc: Genera la documentación Javadoc. • test.unit: Lanza las pruebas unitarias utilizando JUnit [11]. Busca en los paquetes de código fuente las clases cuyo nombre termine en Test (según el convenio de nombrado de JUnit), ejecuta las pruebas y genera informes con los resultados de las mismas en formato HTML. • make-war: Genera un fichero WAR (Web Application Archive) con la aplicación, necesario para la posterior generación del fichero EAR. • make-ear: Genera un fichero EAR (Enterprise Application Archive) con la aplicación, que podrá ser desplegado en un contenedor J2EE. • deploy.localhost: Despliega la aplicación en el contenedor J2EE instalado en la máquina local. • undeploy.localhost: Desinstala la aplicación del contenedor J2EE instalado en la máquina local. • deploy.desa: Despliega la aplicación en el contenedor J2EE instalado en la máquina cuya IP está contenida en la variable desa.test.host. • undeploy.desa: Desinstala la aplicación del contenedor J2EE instalado en la máquina cuya IP está contenida en la variable desa.test.host. • new: Crea un nuevo proyecto a partir del proyecto actual, para ello es necesario pasarle el nombre del proyecto nuevo mediante el parámetro -Dapp.name=proyectoNuevo. Esto copiará el proyecto actual, al mismo nivel de directorio y sustituye el nombre del proyecto en los ficheros de configuración que sea posible.

Pruebas unitarias Es muy recomendable la implementación de pruebas unitarias, al menos para todos los componentes críticos de la aplicación. Es también recomendable, en aplicaciones web, implementar pruebas unitarias para todos los objetos de acceso a datos (DAO). Para facilitar esta tarea se puede utilizar la librería dbUnit y la clase PrincastDatabaseTestCase, suministrada en el openFWPA.

Instalación de la aplicación de ejemplo (Sample App) Para instalar la aplicación de ejemplo (Carrito) se deben seguir los pasos descritos en los siguientes apartados.

11


Configuración de la seguridad Para habilitar la seguridad en la aplicación de ejemplo deben seguirse los pasos especificados en el documento [Manual de Operaciones].

Configuración de la base de datos Esta aplicación utiliza una base de datos MySQL. Se ha de copiar el driver JDBC para MySQL (mysqlconnector-java-3.0.12-production-bin.jar) en el directorio {OC4J_HOME}/j2ee/ home/applib. Para instalar la base de datos es necesario ejecutar la tarea ANT createdb incluida en build.xml (quizá sea necesario cambiar el usuario y contraseña para conectarse a MySQL). A continuación se edita el fichero data-sources.xml, que se encuentra en el directorio {OC4J_HOME}/j2ee/home/config, y se le define un nuevo origen de datos para la aplicación añadiéndole el siguiente código al fichero: Si el servidor de base de datos no se encuentra en la misma máquina que OC4J, sustituir localhost por el nombre o la dirección a dicha máquina. Hacer que los campos username y password coincidan con los de algún usuario de MySQL con privilegios para acceder a la base de datos. Llegados a este punto es necesario re iniciar el OC4J. Una vez re iniciado ejecutar el target deploy.localhost del fichero build.xml, si se ejecuta desde la máquina donde está instalado OC4J, o deploy.desa si se trata de una máquina remota (en este caso cambiar la variable desa.test.host del fichero build.xml debe apuntar a la IP del servidor). Una vez completado el proceso de instalación, la aplicación estará disponible desde la dirección http:// localhost:8888/carrito. Para tener acceso al sistema puede utilizar como parámetros de autenticación los siguientes: • Identificador de usuario: cliente. • Contraseña: cliente.

12

Capítulo 2. Arquitectura Modelo -VistaControlador con openFWPA MVC El patrón MVC – Model 2 puede ser visto como una implementación del lado del servidor del patrón de diseño Modelo-Vista-Controlador (MVC). Este patrón describe cómo debe implementarse una aplicación con tres elementos básicos: Modelo

Se trata de las entidades del dominio del problema, implementadas con total independencia de su presentación.

Vista (Presentación)

Esta capa se encarga de mostrar las entidades del modelo al usuario. En el openFWPA, se implementa esta capa sobre la tecnología JSP. En esta capa, no hay lógica de negocio

Controlador

Traduce eventos/operaciones realizadas sobre la vista a invocaciones de métodos en el modelo. En el openFWPA se emplean servlet para esta capa. Básicamente, en esta capa se procesa la petición de entrada de un cliente, se accede a las entidades del modelo y se coloca cualquier elemento a pasar a la vista en algún ámbito de aplicación (request, session, etc.). Asimismo, dispara un evento que se mapeará a una página jsp que mostará los resultados.

Esta estrategia da lugar a una separación entre presentación y contenido, produciéndose una clara definición de los roles y responsabilidades de los desarrolladores y diseñadores de páginas, en los equipos de programación. De hecho, cuanto más compleja sea la aplicación, mayores son los beneficios de utilizar la arquitectura de Modelo 2.

Figura 2.1. Modelo Vista Controlador

El proyecto Struts de la Apache Software Foundation es una implementación del MVC Modelo 2. El núcleo del framework Struts es una capa de control flexible basada en tecnologías estándar como servlets, JavaBeans, ResourceBundles y XML, así como varios paquetes del proyecto Jakarta Commons. (http://jakarta.apache.org/commons). Struts suministra su propio componente controlador (Controller) y se integra con otras tecnologías para proporcionar el Modelo y la Vista. Para el Modelo, Struts puede interactuar con tecnologías de acceso a datos estándar, como JDBC y EJB, así como con la mayoría de paquetes de terceras partes, como Hibernate, iBATIS, u Object Relational Bridge. Para la Vista, Struts trabaja bien con JSPs, incluyendo JSTL y JSF, así como con Velocity, XSLT y otros sistemas de presentación. Actualmente, el framework del Principado de Asturias sólo da soporte a JDBC y JSP. La figura siguiente muestra como es el ciclo petición-accion-jsp del framework Struts:

Figura 2.2. Ciclo petición-acción-jsp de Struts

Para obtener información más detallada sobre Struts consultar el tutorial que se adjunta en la documentación de openFWPA.

13

Arquitectura Modelo -VistaControlador con openFWPA

Figura 2.3. Estructura de capas de las aplicaciones web con openFWPA

Desarrollo de la Vista Aspecto corporativo de las aplicaciones del Principado de Asturias Las aplicaciones construidas bajo los estándares del openFWPA de desarrollo J2EE se integrarán en el portal del Principado de Asturias ya existente (http://www.princast.es) tanto en internet como intranet. Por lo tanto debe respe-tarse el “look & feel” del portal en la medida de lo posible. Se establece como premisa la construcción de un “look & feel” ligeramente diferenciado, pero que a su vez respete la imagen corporativa del Principado de Asturias. Para lograr este objetivo, se ha partido de la hoja de estilos general.css propiedad del Principado de Asturias, y en base a ella se han desarrollado nuevas hojas de estilos que establezcan el aspecto de la vista de las aplicaciones construidas bajo el framework. Estas hojas de estilo permiten separar las instrucciones de formateo (posición, color, tamaño, etc) del código HTML generado por la aplicación. Esto ofrece una mayor sencillez al desarrollo y una mayor adaptabilidad al cambio - en caso de ocurrir cambio de imagen corporativa, se minimiza el ámbito del cambio unas pocas hojas de estilo CSS.

Figura 2.4. Aspecto corporativo del portal princast.es

Figura 2.5. Aspecto de la aplicación de ejemplo (Sample App)

Cascading Style Sheets (CSS) La aplicación ejemplo (Sample App) maneja 5 hojas de estilos CSS. Debe tomarse esta implementación como referencia de posicionamiento y formateo de textos, bloques, párrafos, etc. En general, se prohíbe el uso de directrices de estilo dentro del código HTML. Cualquier estilo o posicionamiento de bloques deberá ir contenido en una hoja de estilos CSS.

Hojas de estilo en la aplicación de ejemplo (Sample App) Las hojas de estilo son enlazadas a través de la página head.jsp. En caso de necesitar nuevas hojas de estilo, se utilizará este componente para hacerlo, de forma que esta tarea quede totalmente centralizada. El código actual de la página head.jsp es:

14


Las hojas de estilo manejadas por la aplicación de ejemplo SampleApp son: general.css

proviene de la hoja de estilos de referencia con el mismo nombre, incluida en el portal princast.es. Ha sufrido ligeras modificaciones para adaptarse a las necesidades del framework PA. Establece los estilos para los elementos más comunes de una página HTML (enlaces, tablas, celdas, párrafos, listas, textos…)

position.css

define el posicionamiento de los bloques
dentro de la página. La estructura de una página se ha definido en base a bloques, de los cuales no todos tienen porque aparecer, según las necesidades de página. Para más información, véase los apartados correspondientes a los layouts tiles.

princast-ui.css

hoja de estilos para el estilo de los componentes de las etiquetas de princast para las páginas

tabs.css

hoja de estilos para el tabbed menu.

displaytag.css

hoja de estilos exclusiva para el aspecto de las tablas generadas por el tag displaytag (Ver ???). El displaytag genera listas paginadas.

carrito.css

Hoja de estilo para la ubicación y formato de componentes específicos de la aplicación de ejemplo.

Estos ficheros CSS definen los estilos para aplicaciones de tramitación. Además de estas hojas de estilo, se incluyen en el openFWPA ficheros CSS que definen estilos para aplicaciones de portal. Estas hojas de estilo son: componentsPortal.css, displaytagPortal.css y carritoPortal.css. Según lo expuesto, el código de las páginas JSP debe reducirse al mínimo imprescindible, obteniendo así un código mucho más claro y mantenible. Ejemplo: código JSP del cuerpo de una página de la aplicación Sample App:
2. En el mapeo de la action compuesta (DispatchAction) que tiene más de una entrada, dejar la definición de input vacía. 3. Para cada método de la Action, definir un forward utilizando el siguiente convenio de nombrado: “Input”. Actions para Listados Un subconjunto especial de Actions son aquellas que no tienen ninguna lógica de negocio especial. Su único objetivo es obtener un conjunto de objetos para ser mostrados. En función de si el listado se mostrará en una página HTML o en un PDF, se utilizará la PrincastListAction o la PrincastPDFReportAction.

Figura 2.10. Esquema de las Actions para listados

PrincastListAction Si una Action tiene únicamente como propósito obtener un listado, se puede utilizar la PrincastListAction. No hace falta sobrescribir ningún método del ciclo de vida de esta Action, basta con implementar el método getContentList() y devolver el objeto (o colección de objetos) que serán mostrados. El objeto devuelto quedará registrado en sesión, bajo la clave que se especifique en el atributo parameter, en el mapeo de ese action, en el fichero struts-config.xml.

28

Arquitectura Modelo -VistaControlador con openFWPA En caso de que no se especifique ningún valor para el atributo parameter se disparará una excepción de tipo PrincastActionProcessException Esta Action permite realizar paginación sin necesidad de reejecutar la lógica de negocio (Ver “Paginación sin reejecución de la lógica de negocio.”). PrincastPDFReportAction Esta Action permite obtener un listado en formato PDF utilizando las utilidades para generación de informes de openFWPA (Ver “Generación de Informes”). Para implementar una “Report Action”, basta con redefinir el método getReport(), devolviendo un objeto proveedor de contenido PDF (PDFProvider), por ejemplo, un objeto PrincastReport o PrincastMultiReport. Habitualmente, los informes compilados (en formato .jasper) se almacenan juntos en una misma carpeta. Para facilitar la carga de los ficheros “.jasper”, la clase PrincastPDFReportAction implementa el método loadReport() que devuelve el InputStream correspondiente al fichero del informe. Este método, supone que todos los informes se encuentran en la misma carpeta (por defecto: / WEB-INF/reports). Para buscar los informes en una carpeta distinta, se debe sobrescribir el método getRelativePathToReportFolder(). PrincastDispatchPDFReportAction Este Action es la versión dispatch de la PrincastPDFReportAction, permite definir varios métodos para obtener el PDFProvider, por ejemplo, si el parámetro pasado al Action es myMethod se ejecutaría el método myMethodGetReport. Para más información, consultar el Javadoc de la clase y la “Actions Compuestas (Dispatch)”. PrincastXMLAction Este Action permite servir contenido XML. Para servir una respuesta XML, basta con implementar el método getXMLProvider, que retorna un proveedor de contenido XML. El proveedor de contenido XML, será una clase que implemente el interfaz XMLProvider, el cual, obliga implementar el método writeXML(Writer writer). Donde simplemente se escribirá el XML, a servir. PrincastDispatchXMLAction Este Action es la versión dispatch de la PrincastXMLAction, permite definir varios métodos para obtener el XMLProvider, por ejemplo, si el parámetro pasado al Action es myMethod se ejecutaría el método myMethodGetXMLProvider. Para más información, consultar el Javadoc de la clase y la “Actions Compuestas (Dispatch)”.

Action Forms El openFWPA dispone de una clase base para el desarrollo de los beans de formulario. Se trata de la clase PrincastActionForm. Entre las propiedades destacables de esta clase se encuentran: mutable

Para evitar que una PrincastActionForm sea rellenada de forma automática al hacer un forward entre diferentes acciones, establezca el valor de mutable a true y asegúrese de que todos los setters comprueban el valor de dicha propiedad (if (isMutable()) this.field = field;).

locale

propiedad de la clase Locale. Si la instancia de la form es mutable, se le asigna la locale de sesión de Struts siempre que se llame a reset(). Para actualizar el locale de la sesión debe usarse putSessionLocale().

29

Arquitectura Modelo -VistaControlador con openFWPA En cuanto a los métodos: setSessionLocale(Locale)

Establece el atributo locale.

getSessionLocale()

Devuelve el atributo locale.

setMutable(boolean)

Establece el valor del atributo mutable.

isMutable()

Devuelve el valor del atributo mutable.

reset(ActionMapping, HttpServletRequest)

Las subclases que deseen resetear el valor de sus atributos deben comprobar el valor de éste atributo (if (isMutable()) ...)

resetSessionLocale(HttpServletRequest) Cambia el atributo locale al valor que tenga el objeto locale almacenado en la sesión e la petición en curso bajo la clave Globals.LOCALE_KEY. putSessionLocale(HttpServletRequest) Cambia el atributo Globals.LOCALE_KEY de la sesión por el atributo locale o por el Locale por defecto si el atributo locale es null. getLocaleDisplay()

Devuelve el Locale del usuario o el Locale por defecto.

setLocaleDisplay(String)

Cambia el atributo locale a un código de lenguaje ISO dado. Recibe como atributo un String con el código del país.

isBlank(String)

Comprueba si el String que se le pasa es null o la cadena vacía.

describe()

Devuelve un Map con las propiedades de esta PrincastActionForm. Se usa el método PropertyUtils.describe(). Sobrescriba el método si considera que alguna propiedad no debería ser mostrada de este modo, o si un nombre de una propiedad debería ser cambiado. Este método devuelve las propiedades públicas.

set(PrincastValueObject)

Rellena las propiedades de la clase con las del PrincastValueObject que se le pasa como parámetro. Se proporciona una implementación vacía de este método para que sea sobrescrito.

populate(PrincastValueObject) Permite cargar los datos del formulario sobre un Value Object. Este método recibe como parámetro el Value Object sobre el que se van a cargar los datos. Devuelve una referencia al objeto que contiene todos los datos del formulario. Para la definición de ActionForms dinámicos, se incluye en el openFWPA una clase base: PrincastDynaActionForm. Se incluye además una clase base para los formularios que van a ser utilizados por dispatch actions: PrincastDispatchActionForm. Este tipo de formularios incluyen un campo (method) para seleccionar el método de dispatch que se ejecutará para procesarlo. Las clases para la implementación de formularios se encuentran en el paquete: es.princast.framework.web.form. La clase LookupDispatchForm permite disponer de formularios con más de un botón de submit. Para obtener más información acerca de este tipo de forms, véase el apartado PrincastLookupDispatchAction en la sección dedicada a las Actions.

30


Desarrollo de lógica de negocio Es importante disponer de un buen diseño técnico antes de programar la lógica de negocio. En este área intervienen dos tipos de objetos: Business Delegates y Business Managers. Los objetos “Delegate” se encargarán de crear y gestionar los objetos de lógica de negocio y proporcionarán un interfaz, para la aplicación web, de los métodos de negocio. Los objetos "Manager", se encargarán de implementar la propia lógica de negocio.

Figura 2.11. Estructura de la capa Modelo

Utilizando esta estructura, se puede modificar la implementación del servicio sin que sea necesario modificar el resto de la aplicación. Un ejemplo de implementación puede verse en la aplicación de ejemplo (Sample App). En ningún caso la lógica de negocio ha de tener dependencias con el protocolo http (como por ejemplo hacer uso de la sesión), ya que sus servicios han de poder reutilizarse desde cualquier otro entorno (como Web Services, JMS, etc.). Las únicas dependencias al protocolo concreto de acceso han de estar en las acciones (View Adapters y Actions).

Service Locator El patrón de diseño “Service Locator” permite encapsular, en una clase, la localización y acceso a objetos de servidor. El openFWPA incluye un componente que implementa este patrón: la clase ServiceLocator. El ServiceLocator proporciona los siguientes métodos para la búsqueda de objetos: getDataSource()

Permite instanciar un DataSource definido en el servidor (En OC4J, en el fichero data-sources.xml)

getLocalHome()

Obtiene un interfaz ejbHome (local) para la creación de un EJB.

getRemotelHome()

Obtiene un interfaz ejbHome (remoto) para la creación de un EJB.

getQueue()

Obtiene una cola de mensajes JMS.

getQueueConnectionFactory() Obtiene una factory de conexiones a colas de mensajes JMS. getTopic()

Obtiene un Topic JMS.

getTopicConnectionFactory() Obtiene una factory de conexiones a Topics JMS

Session EJBs Habitualmente, es necesario, cuando se trabaja con Session EJBs, gestionar, para cada uno de ellos, de forma específica el mantenimiento del contexto de la sesión (SessionContext). Para evitar la obligación de implementar los métodos de mantenimiento de la sesión, se ha incluido en el openFWPA, una clase base para los Session EJBs: PrincastSessionEJBTemplate. Esta clase implementa los métodos setSessionContext() y unsetSessionContext(), dejando la instancia del contexto en la variable protegida “context”.

Value Objects Los objetos de datos (Patrón Value Object), en las aplicaciones desarrolladas sobre el openFWPA, deben implementar el interfaz PrincastValueObject.

31


Figura 2.12. Diagrama de Value Objects

Esta interfaz define el método toXML() que permite ver una descripción del objeto en formato XML. Para facilitar la implementación de Value Objects, se han incluído dos clases base: BasePrincastVO, que realiza una implementación por defecto para el método toXML() basada en reflectividad, y BasePrincastLazyLoadingVO, que debe ser utilizada si los Value Objects de la aplicación se van a usar en conjunción con Lazy loading de los Value Objects. Ambas clases extienden la clase AbstractBasePrincastVO, que define otro método de utilidad: toPropertyBeans(). En la clase BasePrincastVO, este método permite "desmenuzar" un VO, mapeándolo a una lista de objetos de tipo PropertyBean. El nombre de la propiedad se asignará al campo "value" del PropertyBean. El valor se asignará al campo "label". Si alguna de las propiedades del VO es un objeto compuesto (una lista, una tabla, un array u otro VO) estos serán, a su vez, descompuestos. Se seguirá el siguiente convenio de nombrado para las propiedades: Propiedades de tipo VO (PrincastValueObject)

Si una propiedad es de tipo PrincastValueObject, el nombre de cada una de sus propiedades se mapeará siguiendo el patrón: .

Propiedades de tipo List o arrays

El nombre de este tipo de propiedades se compone como sigue: []

Propiedades de tipo Map

El nombre de este tipo de propiedades se compone como sigue: ().

También se ha empaquetado en el Framework un tipo de Value Object muy habitual: PropertyBean. Este objeto es un Value Object que almacena pares {valor-etiqueta}. La clase PropertyBean también dispone de un método estático: pupulateList() que recibe como parámetro un Map y lo transforma en una lista de PropertyBeans. Debe tenerse en cuenta que la clase BasePrincastLazyLoadingVO tiene implementaciones vacías para los métodos toPropertyBeans() y toXML(), por lo que deberán ser sobreescritos por los Value Objects de la aplicación en caso de necesitar un comportamiento diferente.

Excepciones El openFWPA dispone de su propia jerarquía de excepciones. La política general de manejo de excepciones en el openFWPA es que se utilicen excepciones Runtime (no manejadas estáticamente).

Figura 2.13. Jerarquía de Excepciones

La clase base para la creación de excepciones es PrincastException. Existen dos ramas en esta jerarquía de excepciones runtime: excepciones de sistema (PrincastSystemException), reservadas para el openFWPA y sus componentes y excepciones de modelo (PrincastModelException), que son disparadas por las excepciones.

32

Arquitectura Modelo -VistaControlador con openFWPA Como norma general, las aplicaciones no beráin nunca extender las excepciones del sistema. Siempre deben extender PrincastModelException. Además, el openFWPA también tiene una clase base para la creación de excepciones gestionadas: PrincastRequiredHandlingException. La excepción DeprecatedAPIException se reserva para ser disparada desde métodos deprecados en los que no sea posible implementar una lógica alternativa.

Utilidades Junto con las excepciones, se incluye una clase (ToXMLExceptionHelper) auxiliar para facilitar el fromateo de las mismas y su traducción a XML.

Otras clases de utilidad Junto a las Actions, en el paquete web se incluyen algunas clases de utilidad para los componentes de la capa de aplicación.

PrincastMessageFmtter Clase para facilitar el formateo de cadenas de caracteres (mensajes, etc). Esta clase permite: • Reemplazar tokens en un String. Método replace(). • Formatear un mensaje, siendo éste una cadena con parámetros del tipo {0}, {1}, … {n}. Este método (format()) recibirá como parámetros una cadena de texto y un array de objetos. El objeto en la posición 0 se introducirá en lugar de la subcadena “{0}” y así sucesivamente.

PrincastUtils Contiene métodos de utilidad general. Actualmente únicamente implementa el método normalizePath() que tiene como objetivo normalizar los paths en los distintos sistemas operativos.

ParameterCaster Clase de utilidad para la capa web. Permite traducir el tipo (casting) de los parámetros que se reciben de una request http.

ServletPathUtils Clase de utilidad del paquete web que permite gestionar paths de peticiones http. Los métodos que define son: match()

Valida si un path se ajusta a un patrón URL (url-pattern) determinado.

extractRelativePath()

Obtiene el path relativo a partir de un path absoluto.

getCompleteURL()

A partir de una request, obtiene la URL solicitada completa, incluyendo los parámetros GET.

getURLParametersSeparator() A partir de una URL, determina si los parámetros que se vayan a añadir a continuación se preceden de un carácter ‘?’ ó ‘&’,

33

Arquitectura Modelo -VistaControlador con openFWPA en funciónd e si dicha URL ya tenía, o no, parámetros GET anteriormente.

DateDecorator Clase que facilita la escritura de fechas y horas con un formato determinado. Esta clase implementa el patrón “Decorator” sobre la clase java.util.Date, sobrescribiendo su método toString(). La clase es.princast.framework.core.util.DateDecorator permite definir el patrón de formato que se aplicará al obtener la representación textual de la fecha utilizando el método Date.toString(). Además, también define los patrones para los formatos de fecha más comunes: /** * Formato corto para las fechas tomando como separador el caracter /. */ public static final String SHORT_DATE = "dd/MM/yyyy"; /** * Formato corto para las fechas tomando como separador el caracter -. */ public static final String SHORT_DATE_DASH = "dd-MM-yyyy"; /** * Formato para mostrar sólo horas, minutos y segundos. Las horas varían en * el rango 0..24. */ public static final String ONLY_TIME = "HH:mm:ss"; /** * Formato largo para la fecha, tomando como caracteres de separación el * caracter / para día, mes, año y el caracter : para horas, minutos y * segundos. */ public static final String LONG_DATE = "dd/MM/yyyy HH:mm:ss"; /** * Formato largo para la fecha, tomando como caracteres de separación el * caracter - para día, mes, año y el caracter : para horas, minutos y * segundos. */ public static final String LONG_DATE_DASH = "dd-MM-yyyy HH:mm:ss";

PrincastPathResolver El objetivo del PrincastPathResolver es ofrecer, al programador de aplicaciones, un punto centralizado para resolver paths (a recursos) uniformemente. Este objeto (que implementa el patrón Singleton) define los siguientes métodos: resolvePath(path)

Resuelve un path, que se especifica por parámetro, devolviendo el path absoluto.

resolveToFile(path)

Resuelve un path, devolviendo el objeto File correspondiente.

34

Arquitectura Modelo -VistaControlador con openFWPA resolveToStream(path)

Resuelve un path, devolviendo un stream de lectura sobre el recurso que se halle en dicho path. Si no encuentra ninguno, dispara una FileNotFoundException.

Existen varios tipos de "path resolvers" en el openFWPA, en función del tipo de aplicación. En general, se puede asignar cualquier tipo de "path resolver" definido por el usuario. Para ello, basta con extender la clase PrincastPathResolver y utilizar el método PrincastPathresolver.registerResolver(). Los resolvers implementados en el openFWPA son: DefaultPathResolver

Implementación por defecto. Resuelve paths absolutos y relativos al classpath y al "working dir" de la aplicación.

WebAppPathResolver

Implementación por defecto en aplicaciones web (siempre que utilicen el PrincastStartupListener). Resuelve paths absolutos y relativos al classpath y al directorio de despliegue de la aplicación.

PrincastOSCacheInterceptor Esta clase permite a través de Spring y OSCache, realizar cacheos transparentes de las llamadas a cualquier método de cualquier bean de Spring. Esto es útil, por ejemplo para cachear las llamadas al sistema de Genéricos del Gobierno del Principado de Asturias. El uso de esta clase está documentado en la Javadoc. La funcionalidad por defecto establece una caché por método cacheado, donde la clave para buscar en la cache es la concatenación del toString, de los argumentos. Si dos llamadas al mismo método tienen el mismo toString concatenado de los argumentos se devuelve el resultado cacheado. Este comportamiento se puede sobreescribir heredando de la clase. El tiempo de refresco se establece en la definición de bean, por defecto son 600 segundos se recomienda ver la Javadoc, para ver la sintáxis de los tiempos de refresco en función del método.

Providers Para aislar la capa de acceso a datos de otras capas de la aplicación, habitualmente es buena idea definir interfaces “providers”. Estos interfaces proporcionan datos a la capa del controlador, o directamente a la vista, sin indicar donde ni cómo se obtienen esos datos. El controlador (o la vista) pueden manipular los “providers” directamente sin preocuparse de cómo éstos se han obtenido. Desde la versión 1.5 del openFWPA, los providers es.princast.framework.facilities.providers.

se

encuentran

en

el

paquete:

El openFWPA define un conjunto de providers habituales: EntityContentProvider

Se trata de un proveedor de entidades. Este interfaz devuelve una sola entidad que puede ser utilizada directamente. Por ejemplo, para mostrar sus datos en un formulario.

ListContentProvider

Provee conjuntos de entidades. Este interfaz devuelve listas de entidades. Se pueden utilizar para listados.

PaginatedContentProvider

Provee listas paginadas de entidades. Este interfaz proporciona listas que pueden recorrerse de forma paginada. Se pueden utilizar en listados en los cuales toda la lista no cabe en una sola página HTML

35

Arquitectura Modelo -VistaControlador con openFWPA PDFProvider

Provee documentos en formato PDF. Este interfaz proporciona un array de bytes que contienen un documento PDF. Se puede utilizar para la realización de informes o documentos.

XMLProvider

Provee contenido en formato XML. Este interfaz proporciona un método writeXML(Writer writer), donde se escribirá directamente el XML. Se puede utilizar para servir contenido XML, junto con la PrincastXMLAction . Un ejemplo de este tipo de Provider, incluido en el openFWPA, es el PrincastVelocityXMLProvider que provee contenido, a través del motor de plantillas Velocity. Su principal objetivo es la generación de contenido XML basado en plantillas, aunque se puede usar para generar cualquier tipo de contenido. Para mayor información acerca de su uso, se recomienda leer la Javadoc

PropertyBeansProvider

Es una implementación del ListContentProvider que provee a la aplicación de beans de propiedades (PropertyBean). El provider puede cargar estos beans de objetos Map o de ficheros de properties (.properties).

Para conocer con mayor detalle el interfaz de cada uno de los providers, consúltese la documentación Javadoc del openFWPA.

36

Capítulo 3. Implementación de la Arquitectura de Referencia con openFWPA Inversión de Control en la Arquitectura de Referencia A partir de la versión 1.5 de openFWPA, se hace un uso intensivo de la inversión de control (IoC), para implementar la arquitectura de referencia, en las aplicaciones realizadas con el openFWPA. Para ello, se hace uso de Spring Framework, que ofrece la implementación del patrón AbstractFactory basado en ficheros XML. Esto permite, eliminar los elementos de unión en las aplicaciones, como las factorías, y singletons. Además, permite tener la arquitectura modularizada en "piezas", que por estar definidas en un fichero XML, son intercambiables. Lo que deriva, en un sistema débilmente acoplado, más tolerable a cambios y modificaciones.

Introducción al manejo de la Arquitectura con Spring Para manejar la Arquitectura de referencia con Spring, se hace uso de una serie de ficheros XML, donde se definen los beans que forman parte de la arquitectura del sistema. Estos ficheros están ubicados en src/ java/beans y sigue la estructura de directorios, propuesta para la arquitectura.

Figura 3.1. Ficheros de configuración de Beans

Los ficheros siguen la sintaxis de definición de beans de Spring, al igual que el fichero de inicialización de openFWPA (princast-init-script.xml). Para hacer uso de la inversión de control, es necesario seguir una serie de pasos. Como ejemplo, se va a ver cómo se construye una clase Action dependiente de una clase Delegate desde cero. El proceso de inyectar la dependencia se ha denominado "enlazado", tomándolo como traducción libre del término "wiring", utilizado en el manual de referencia de Spring. La primera tarea que hay que hacer, es implementar el Action. Como se tiene una dependencia, con un Manager, se introduce un campo o propiedad (privado o protegido), en la clase Action. Además, se define un setter para ese campo, de esta forma se puede inyectar esa dependencia. A la hora de usar el objeto Delegate se utiliza normalmente, aunque parezca que al usarlo apunta a un valor nulo, el motor de inversión de control se encarga de inicializarlo. public class GetListaProductoAction extends PrincastListAction { // inyeccion de dependencia (/beans/web/action-beans.xml) protected CarritoDelegate carritoDelegate;

37

Implementación de la Arquitectura de Referencia con openFWPA public void setCarritoDelegate(CarritoDelegate carritoDelegate) { this.carritoDelegate = carritoDelegate; }

protected Object getContentList(ActionMapping mapping, ActionForm form, HttpServle //Llamamos al delegate para obtener la lista de productos. return carritoDelegate.getListaProducto(); } } Una vez programada la clase, se debe registrar en el fichero de beans correspondiente, en este caso, como se trata de un action, se registra en el fichero actions-beans.xml. Para ello se le da un identificador mediante el atributo id. Un nombre de clase con el atributo class, y mediante el atributo singleton, se especifica si se quiere que la clase sea un singleton o no (si no se especifica ese atributo, por defecto, será un singleton).