ATLAS Normativa. Versión 1.2. Área de Integración y Arquitectura de Aplicaciones

Transcripción

1 ATLAS Versión 1.2 Área de Integración y Arquitectura de Aplicaciones

2 Hoja de Control Título Documento de Referencia Responsable TIVA Área de Integración y Arquitectura de Aplicaciones Versión 1.2 Fecha Versión 06/08/2010 Registro de Cambios Versión Causa del Cambio Responsable del Cambio Fecha 1.0 Versión inicial del documento, se parte de la normativa creada antes de desarrollar el framework Área de Integración y Arquitectura de Aplicaciones 24/05/2010 Modificaciones sobre versión 1.0: - Norma: JSFHttpSession: Se cambia la redacción de la norma ya que podía malinterpretarse Norma: JSFNavegacion: Se modifica la nomenclatura de la clase para el caso de haber varios bloques funcionales. - Norma: SNDependencias: Se modifica la norma para permitir varios ficheros de contexto. - Norma: DAODependencias: Nueva norma sobre versión 1.0. Se incluye una norma para la nomenclatura del fichero de contexto de los DAOS. Aunque esta norma no existía el arquetipo ya venía con esta nomenclatura. Begoña Delgado 02/07/ Modificaciones sobre versión 1.1: - applicationcontext-database.xml: Ya no se anotan las clases, se hace por paquete con la propiedad packagestoscan. - EntornoEjecucion: Se cambia de la jdk de Sun a la jrockit. Manuel Pereira 27/07/ de 168

3 Índice 1 INTRODUCCION AUDIENCIA OBJETIVO CONOCIMIENTOS PREVIOS DESCRIPCION PORTAL PARA EL DESARROLLO DE APLICACIONES ENTORNO DE DESARROLLO PROYECTOS, MODULOS Y ARQUETIPOS MODULO WEB MODULO LIBRERÍA MODULO SERVICIO WEB MODULO BATCH ARQUITECTURA CONSIDERACIONES GENERALES PRESENTACION PAGINAS JSF Manejo de eventos Recuperación de parámetros Validadores Conversores Internacionalización Estructura y decoración de la página Uso de javascript Normas de estilo Interfaces ricas de usuario (RIA) MANAGED BEANS Manejo de excepciones Navegación CONFIGURACIÓN DE JSF faces-config.xml faces-managed-beans.xml faces-navigation.xml Archivos de configuración adicionales y web.xml USO DE LA SESIÓN SERVICIOS DE NEGOCIO FACHADA SERVICIOS INYECCION DE DEPENDENCIAS MANEJO DE EXCEPCIONES TRANSACCIONALIDAD ACCESO A DATOS DATASOURCE Y SESIONES DE HIBERNATE CONFIGURACIÓN enviroment.properties applicationcontext-database.xml applicationcontext-dao.xml ENTIDADES DE DOMINIO Mapeo relacional Tipos de datos BLOB y CLOB (LOB) DATA ACCESS OBJECTS Manejo de excepciones Transaccionalidad LLAMADA A PROCEDIMIENTOS ALMACENADOS DESDE HIBERNATE CACHÉS EN HIBERNATE Las cachés de primer y segundo nivel de 168

4 Las cachés distribuidas La caché de consultas CONFIGURACION SERVICIOS BASICOS SERVICIO DE AUTENTICACION Y AUTORIZACION COMPONENTES DE PRESENTACION SERVICIO DE TRAZAS SERVICIO DE AUDITORIA DE SEGURIDAD INTEGRACION SERVICIO DE GESTIÓN DOCUMENTAL SERVICIO DE PLANIFICACION SERVICIO DE CERTIFICADOS DIGITALES SERVICIO DE BUSSINESS INTELLIGENT SERVICIO DE INVOCACIÓN DE SERVICIOS WEB SERVICIO DE PROCESOS DE NEGOCIO OTRAS SOLUCIONES REPORTING COMPOSICION DE DOCUMENTOS GESTION DE DOCUMENTOS EXCEL GESTION DE DOCUMENTOS PDF GENERACION DE GRAFICOS MANIPULACION DE ARCHIVOS MULTIMEDIA ACCESO A PLATAFORMA Y DISPOSITIVOS LOCALES XML ENVIO DE CORREO ENVIO DE SMS HERRAMIENTAS VALIDACION DE TIVA VALIDACION DE CODIFICACION JAVA PRUEBAS TIPOS DE PRUEBAS PLAN DE PRUEBAS DOCUMENTACION DEL CODIGO ENTREGA ENLACES RELACIONADOS A1.1 S A1.2 BUENAS PRACTICAS A1.3 MANUALES de 168

5 1 INTRODUCCION La presente guía presenta el framework de desarrollo para todas las aplicaciones de la Comunidad de Madrid y establece la normativa a cumplir en estos desarrollos. El framework se ha denominado Atlas y los desarrollos deben cumplirlo en su última versión públicada. En esta normativa se incluyen dos tipos de indicaciones para el correcto desarrollo de aplicaciones: o Normas: Son requisitos de obligado cumplimiento, y se encuentran definidas dentro de una caja de color azul: NombreDeNorma Contenido de la norma. o Buenas prácticas: Son recomendaciones para el desarrollo. No son de obligado cumplimiento aunque para un correcto funcionamiento se recomienda cumplirlas siempre que sea posible. Se encuentran definidas dentro de una caja de color BUENA PRACTICA NombreDeBuenaPractica Contenido de la Buena Práctica. 1.1 AUDIENCIA OBJETIVO Este documento va dirigido a jefes de proyecto, analistas y desarrolladores de proyectos que utilicen el framework Atlas. 5 de 168

6 1.2 CONOCIMIENTOS PREVIOS Para un completo entendimiento del documento, el lector deberá tener conocimientos previos sobre las tecnologías que forman parte del framework. A continuación se muestra una tabla con las distintas tecnologías utilizadas por cada uno de los elementos del framework. Servicio Tecnología Respositorio maven Gestión del proyecto IDE de desarrollo Artifactory Maven Eclipse Entorno de Desarrollo Servidor de Aplicaciones Oracle Weblogic 10.3 Motor de base de datos Oracle Control de versiones Integración continua Maquina virtual java Subversión Cruise Control JRockit JDK 1.6.0_XX Arquetipos Generación de nuevos proyectos Maven y Eclipse Arquitectura Presentación Servicios Acceso a Datos JSF, Tomahawk, RichFaces, Ajax4JSF, Facelets Spring Hibernate Servicios Web Axis 2 Servicios Básicos Servicio de Autenticación y Autorización Componentes de Presentación Servicio de Trazas Servicio de Auditoria Spring Security JSF, Tomahawk, RichFaces, Ajax4JSF, Facelets Spring AOP y Log4J Spring AOP e Hibernate Servicio de Gestión Documental Documentum 6.0 Servicio de Planificación Control M Integración Servicio de ASF ASF 3.5 Servicio de Bussiness Inteligent SAP Bussiness Objects XI 3.1 Servicio de Invocación de Servicios Web Axis 1.4 Servicio de Procesos de Negocio Oracle BPM 10 6 de 168

7 Documentos PDF IText Reporting Crystal Reports 2008 Otras soluciones Herramientas Composición de documentos Documentos Excel Generación de Gráficos Archivos multimedia Acceso a dispositivos locales XML Envío de correo Envio de SMS Monitorización Pruebas de carga Pruebas de aceptación Pruebas unitarias Validación normativa Validación estática de código Velocity Apache POI JFreechart Java Media FrameWork API (JMF) Applet Jaxb Java Mail Servicio web mentes_ws JMS y JMX JMeter Selenium JUnit Maven Checkstyle y PMD 7 de 168

8 2 DESCRIPCION El framework Atlas es un conjunto de componentes de software para simplificar el desarrollo de las aplicaciones, ya que implementan aquellos requisitos que son compartidos por muchas de ellas. Otra parte del framework es la normativa que garantiza la homogeneidad de los desarrollos y vela por conseguir un código de calidad. A continuación se muestra una imagen que contiene los distintos elementos del framework. o o o Entorno de desarrollo: Herramientas necesarias para el desarrollo de aplicaciones con el framework Atlas Arquitectura: Son los pilares que constituyen la base fundamental del Framework (JSF, Spring e Hibernate) Servicios Básicos: Servicios de uso común en la mayoría de los aplicaciones 8 de 168

9 o o o o Arquetipos: Generadores de nuevos proyectos con la estructura básica de un proyecto Atlas (plantillas de partida para el arranque de nuevos proyectos). Integración: Integración con otras tecnologías como Documentum, BPM, etc Herramientas: Utilidades de testing, validación y monitorización de aplicaciones. : de obligado cumplimiento para el desarrollo de aplicaciones con el framework. 9 de 168

10 3 PORTAL PARA EL DESARROLLO DE APLICACIONES Toda la documentación y recursos del framework Atlas se encuentra accesible en el portal para el desarrollo de aplicaciones de la Unidad de Arquitectura de Aplicaciones en la url: Esta web es el canal de comunicación de la Unidad de Arquitectura de Aplicaciones hacia los proveedores. Cada vez que se publica algo en la web se incluye una noticia indicando la actualización que se ha realizado. El proveedor por lo tanto tiene la responsabilidad de conectarse asiduamente a esta web para estar al corriente de las modificaciones. Las consultas relacionadas con el desarrollo de aplicaciones se deben dirigir a la Unidad de Arquitectura de Aplicaciones a través del portal para el desarrollo en el apartado Contactar con Arquitectura en la página de Inicio. 10 de 168

11 4 ENTORNO DE DESARROLLO Las siguientes imagenes muestran los elementos a grandes rasgos Entorno Desarrollo Proveedor Eclipse + plugin Maven (+ plugin subversion) Maven Repositorio Local Base de Datos (Oracle) Servidor de Aplicaciones (WebLogic) Artifactory Entorno ICM jar Arquetipos web Portal para el desarrollo Subversion batch service Artefactos CruiseControl docum Oracle Weblogic En el manual ATLAS_MUS_Preparacion_Entorno_Desarrollo detallan los productos y versiones de los mismos que son necesarios para el desarrollo de aplicaciones con el framework Atlas. Por otra parte se indica como preparar el entorno para comenzar a desarrollar aplicaciones. 11 de 168

12 Entorno El proveedor deberá replicar en sus instalaciones el entorno de desarrollo de ICM en cuanto a productos y versiones de los mismos. Las aplicaciones deberán desarrollarse teniendo en cuenta los siguientes aspectos relativos al entorno: En el entorno de producción podrán ser desplegadas en modo cluster, tanto en varias instancias de un mismo o diferentes servidores de aplicaciones. No deben usar funcionalidades o tecnologías dependientes del sistema operativo sin la previa aprobación de ICM. No deben usar funcionalidades propietarias del servidor de aplicaciones, sin la previa aprobación de ICM, para garantizar al máximo la portabilidad entre servidores de aplicaciones. Los ficheros generados por las aplicaciones y que se necesiten dejar en disco se ubicarán según se indique en un parámetro del fichero de configuración. Esta ubicación corresponderá con un directorio compartido por las distintas maquinas que compongan el cluster. Las aplicaciones web y servicios web se van a ejecutar en varias maquinas virtuales por lo tanto los objetos que se dejen en la memoria de la maquina virtual no estarán replicados en las diferentes instancias. EntornoEjecucion Las aplicaciones se desplegarán en el servidor de aplicaciones Oracle Weblogic 10.3 y se ejecutarán con la JDK JRockit 1.6.0_XX por lo tanto el codigo entregado deberá estar probado con esta versión de JDK y funcionar correctamente en este servidor de aplicaciones. 12 de 168

13 5 PROYECTOS, MODULOS y ARQUETIPOS Las aplicaciones de la Comunidad de Madrid se definirán en el marco de un proyecto, denominando a las distintas aplicaciones que se desarrollen para un proyecto módulos. Por lo tanto podemos decir que un proyecto es un conjunto de módulos. Todos los proyectos de la Comunidad de Madrid tienen un nombre de 4 letras que identifican al proyecto y que van a ser fundamentales en la nomenclatura de muchos de los elementos del proyecto por lo tanto es fundamental disponer de este identificador antes de abordar ningún tipo de desarrollo. A continuación se muestra la estructura de carpetas sobre como se debe crear un proyecto y sus correspondientes módulos. Atención xxxx se corresponde con el nombre del proyecto y como podemos ver este nombre forma parte del nombre de los módulos. Observar que el separador utilizado en el nombre de los módulos es el guión bajo. Dentro de los módulos de un proyecto nos podemos encontrar con módulos del framework Atlas o con otro tipo de módulos (por ejemplo un módulo de Documentum, un módulo de base de datos, etc). 13 de 168

14 Los distintos tipos de módulos que podemos implementar con el framework Atlas son: o Módulo web: Para implementar aplicaciones de tipo web. o Módulo librería: Para implementar librerías (jars). o Módulo servicio web: Para implementar servicios web. o Módulo batch: Para implementar aplicaciones o procesos que se ejecutarán en modo batch. Para más información sobre los posibles módulos y su nomenclatura consultar el manual NOMENCLATURA SOBRE OBJETOS ORACLE, MÓDULOS TÉCNICOS Y NOMBRES DE ARCHIVOS DE PROYECTO. Los arquetipos son plantillas de proyectos Maven que se utilizarán como punto de partida de cualquier módulo desarrollado con el framework Atlas. Arquetipos El desarrollo de cualquier módulo de un proyecto se debe hacer partiendo del arquetipo correspondiente. Actualmente se dispone de los siguientes arquetipos dentro del framework Atlas: ARQUETIPOS DESCRIPCION Tipo de módulo atlasfrm-arquetiposgenerador-web atlasfrm-arquetiposgenerador-servicioweb atlasfrm-arquetiposgenerador-documentumweb atlasfrm-arquetiposgenerador-batch Genera un proyecto Maven preparado para el desarrollo de módulos web con JSF, Spring e Hibernate. Genera un proyecto Maven de tipo web listo para desplegar un servicio web con Axis2, Spring e Hibernate Genera un proyecto Maven de tipo web listo para ser utilizado con aplicaciones que se integren con Documentum Genera un proyecto Maven preparado para el desarrollo de módulos de tipo batch, con sus scripts de ejecución preparada para distribución. Contiene Módulo web Módulo servicio web Módulo web Módulo batch 14 de 168

15 atlasfrm-arquetiposgenerador-jar configuraciones de Spring e Hibernate Genera un proyecto Maven preparado para el desarrollo de módulos de tipo librería (jar). Módulo librería NOMArchivo Los nombres de los archivos sólo pueden estar formados por caracteres [a-z] y guiones medio y bajo, no pudiéndose utilizar caracteres acentuados ni la letra eñe. En los nombres de los archivos pueden utilizarse letras mayúsculas cuando sea conveniente. NOMPaquetes Los nombres de los paquetes de clases Java sólo pueden estar formados por caracteres [a-z] en minúscula, no pudiéndose utilizar caracteres acentuados ni la letra eñe. 15 de 168

16 5.1 MODULO WEB Para el desarrollo de módulos web el framework Atlas incluye un arquetipo web que se deberá utilizar para la implementación del mismo. Para obtener más información sobre el arquetipo web consultar el manual ATLAS_MUS_Arquetipo_Web. IMPLWEB Para implementar un módulo/aplicación web se creará un módulo partiendo del arquetipo web y con la siguiente nomenclatura: donde xxxx_yyyy xxxx se corresponde con el nombre del proyecto yyyy se corresponde con el nombre descriptivo del web (No se puede poner en este nombre el sufijo web ya que se la va a incluir automáticamente al generar el módulo desde el arquetipo) 16 de 168

17 5.2 MODULO LIBRERÍA En algunos proyectos nos encontramos con que determinadas código debe de estar compartido por varios módulos del proyecto, en ese caso es necesario crear un nuevo módulo de tipo librería cuya dependencia será incluida en cada uno de los módulos que lo necesite. LIBCOMUN Cuando varios módulos de una o varias aplicaciones tengan código en común, ya sean métodos o clases, se deberá crear una librería de clases que servirá para compartir el código común anterior. Para el desarrollo de módulos librería el framework Atlas incluye un arquetipo jar que se deberá utilizar para la implementación del mismo. Para obtener más información sobre el arquetipo jar consultar el manual ATLAS_MUS_Arquetipo_Jar. IMPLLIB Para implementar un módulo librería se creará un módulo partiendo del arquetipo jar y con la siguiente nomenclatura: donde xxxx_lib_<yyyy> xxxx se corresponde con el nombre del proyecto yyyy se corresponde con el nombre descriptivo de la librería (Este nombre es opcional y debe distinguir a una librería de otra) 17 de 168

18 5.3 MODULO SERVICIO WEB Si existe la necesidad de que determinada funcionalidad de nuestra aplicación sea expuesta como un servicio web a otras aplicaciones se deberá crear un módulo específico que implemente el servicio web. El framework Atlas incluye un arquetipo de servicio web que se deberá utilizar para la implementación del mismo. Para obtener más información sobre el arquetipo de servicio web consultar el manual ATLAS_MUS_Arquetipo_Servicio_Web. IMPLWS Para implementar un servicio web se creará un módulo partiendo del arquetipo servicio web y con la siguiente nomenclatura: donde xxxx_ws_<yyyy> xxxx se corresponde con el nombre del proyecto yyyy se corresponde con el nombre descriptivo del servicio web (Este nombre es opcional y debe distinguir a un servicio web de otro) 18 de 168

19 5.4 MODULO BATCH Si existe la necesidad de que determinada funcionalidad de nuestra aplicación sea ejecute en modo batch se creará un módulo de tipo batch. El framework Atlas incluye un arquetipo de aplicaciones batch que se deberá utilizar para la implementación del mismo. Para obtener más información sobre el arquetipo de batch consultar el manual ATLAS_MUS_Arquetipo_Batch. IMPLBatch Para implementar un servicio web se creará un módulo partiendo del arquetipo servicio web y con la siguiente nomenclatura: donde xxxx_batch_<yyyy> xxxx se corresponde con el nombre del proyecto yyyy se corresponde con el nombre descriptivo del batch (Este nombre es opcional y debe distinguir a un programa batch de otro) 19 de 168

20 6 ARQUITECTURA El framework Atlas está basado fundamentalmente en tres tecnologías: JSF, Spring e Hibernate, que dan soporte a la implementación de las distintas capas de la aplicación: Presentación: Java Server Faces (JSF) Servicios: Spring Acceso a datos: Hibernate Es fundamental el conocimiento por parte del desarrollador de estas tres tecnologías para poder llevar a cabo con exito el desarrollo de una aplicación con el framework Atlas. 6.1 CONSIDERACIONES GENERALES A continuación se exponen una serie de normas que son de carácter general para el código Java a desarrollar. REFLEXION No está permitido el uso de la Reflectividad (bien sea para buscar e invocar métodos o bien para acceder a atributos de una clase), a no ser que sea previamente autorizada por ICM. GARBAGE No está permitida la invocación directa al garbage collector mediante System.gc(), a no ser que tras consultarlo sea autorizada por ICM. MULTIHILO En aplicaciones web o servicios web no pueden utilizarse hilos (threads) de ejecución distintos del hilo principal, a no ser que sea previamente autorizado por ICM. CLASESIGUALES No puede haber dos clases que se llamen igual aunque estén en dos paquetes distintos. 20 de 168

21 6.2 PRESENTACION La lógica de presentación de la aplicación abarca todos los aspectos relacionados con la presentación de información al usuario final. La arquitectura de Atlas se basa principalmente en el uso de la tecnología Java Server Faces (JSF) para la creación de la lógica de presentación de la aplicación, si bien hay ciertas funcionalidades que son responsabilidad de esta capa y que emplean algún framework o producto adicionales. No obstante para ciertas tipologías de aplicaciones (aplicaciones meramente informativas, esto es, aquellas cuyo principal objetivo es mostrar información al usuario final) el uso de esta tecnología complica la integración con la infraestructura actual de ICM. Tal es el caso de las aplicaciones o sitios Web que dependen de madrid.org implementados mediante las herramientas que ofrece el gestor de contenidos corporativo de ICM (Fatwire). Este tipo de aplicaciones están fuera del alcance del presente documento, las cuales están sujetas a una normativa propia. La arquitectura de componentes que proporciona JSF, incluye: Un API para representar componentes de interfaz de usuario y gestionar: o Su estado. o Los eventos generados por la interfaz. o La validación y conversión de datos en el lado del servidor. o La definición de las reglas de navegación entre páginas. o Los aspectos relacionados con internacionalización y accesibilidad. o Los puntos de extensión para todas estas características. Librerías de etiquetas personalizadas para implementar la interfaz de las Java Server Faces y para asociar los componentes a los objetos del lado del servidor. Desde el punto de vista del desarrollo, una aplicación JSF es como cualquier otra aplicación web Java. Típicamente, una aplicación JSF incluye las siguientes piezas principales: Un conjunto de páginas xhtml, que usarán etiquetas especiales definidas por la especificación JSF. Un conjunto de managed beans, que no son más que JavaBeans que definen propiedades y funciones para los componentes de interfaz de usuario de las páginas. Archivos de configuración para la aplicación, que definen las reglas de navegación y configuran los beans y los componentes a medida. Un descriptor de despliegue (el fichero web.xml de toda aplicación web). Los componentes y objetos a medida creados por el desarrollador para ampliar el modelo estándar (nuevos componentes visuales, validadores, conversores, etc.). 21 de 168

22 La siguiente figura muestra el modelo de componentes que propone JSF, además se resumen las principales funcionalidades aportadas por dicha tecnología y que se encuentran incluidas en el presente documento. Funcionalidades Componentes de IU Integración con modelo de objetos Gestión de contexto de usuario Modelo de renderizado Manejo de eventos en el servidor Conversión de tipos y validación Navegación Internacionalización Modelo Managed Beans Vista Controlador Componentes UI FacesServlet Una de las mayores ventajas de JSF es que ofrece una clara separación entre presentación y comportamiento. JSF permite hacer un mapeo de las peticiones HTTP a elementos específicos para el manejo de eventos además de manejar los elementos de interfaz de usuario como si fueran objetos con estado en el lado del servidor. Otra ventaja importante de la tecnología JSF es que permite utilizar los componentes de interfaz de usuario sobre cualquier otra tecnología de presentación para otro tipo de dispositivos. Y lo más importante, JSF aporta una arquitectura para manejar el estado de los componentes, el proceso de los datos, la validación de las entradas del usuario y el manejo de eventos. El uso de JSF aporta las siguientes ventajas adicionales: Es un estándar JEE. Esto asegura que los principales fabricantes de servidores de aplicaciones e IDEs sean compatibles con JSF. Al ser un modelo basado en componentes, la productividad es mayor y se fomenta la reutilización. Posibilita el uso de herramientas de diseño visuales. Ofrece una separación nítida entre presentación y lógica de negocio, y por tanto, de los roles involucrados. Flexibilidad. Permite a los desarrolladores la ampliación de los componentes de las librerías de etiquetas e incluso la creación de otros nuevos. Apta para la gestión de clientes heterogéneos (WML, Wap, HTML, XML, etc.). En la actualidad existen un extenso conjunto de librerías de componentes JSF, tanto comerciales como de código abierto. Para el desarrollo de aplicaciones Atlas pueden utilizarse alguna de ellas. JSFComponentes Para la implementación de la interfaz de usuario de las aplicaciones con JSF, sólo se podrán emplear los componentes propios de Atlas, los de MyFaces, RichFaces y sus extensiones. Las librerías para estos componentes ya se encuentran dentro del repositorio Maven de ICM. 22 de 168

23 6.2.1 PAGINAS JSF En las páginas JSF se situan los distintos elementos que formaran las páginas a mostrar al usuario final de la aplicación. JSFXHTML Todos los ficheros JSF deberán ser documentos XHTML con extensión.xhtml. Como sistema de codificación se empleará UTF-8. Los componentes Web transmitirán todas las páginas con dicho sistema de codificación (encoding="utf-8"). Todas las páginas JSF se ubicarán en la carpeta src/main/webapp y subcarpetas. Para distinguir aquellas páginas cuyo acceso esté securizado estas se ubicarán en una carpeta llamada src/main/webapp/secure. Dentro de esta carpeta se podrán crear las subcarpetas necesarias para poder llevar una gestión de perfiles de acceso. JSFPOB Las páginas deben de ser compatibles con las versiones de Navegador Internet Explorer 6.0 o superior y Mozilla Firefox 2 o superior. Los módulos que se desarrollen para los usuarios de la Intranet deben funcionar correctamente con el POB (Puesto ofimático básico) que tienen instalado en su PC. A continuación se muestra un ejemplo de página JSF: Ejemplo de página JSF <?xml version="1.0" encoding="utf-8"?> <jsp:root xmlns:jsp=" xmlns:ui=" xmlns:h=" xmlns:f=" xmlns:t=" xmlns:atlas=" xmlns:c=" xmlns:fn=" xmlns:a4j=" xmlns:rich=" version="2.0"> <jsp:text> <![CDATA[ <?xml version="1.0" encoding="utf8"?> ]]> </jsp:text> <jsp:text> <![CDATA[ <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" " ]]> </jsp:text> <html xmlns=" 23 de 168

24 <ui:composition template="/web-inf/layout/vc.xhtml"> <ui:define name="rastromigas"> <ui:include src="/secure/rastromigas/rastro.xhtml" /> </ui:define> <ui:define name="menuvertical"> <ui:include src="/secure/menu/menu.xhtml" /> </ui:define>... <ui:define name="content"> <h:form id="mainpanel"> <t:savestate id="stateidcliente" value="#{clientesbean.cliente" /> <h:panelgroup> <h:panelgrid width="70%" columns="3"> <h:outputlabel id="outputlabelnombre" for="inputtextnombre" styleclass="label" value="#{bundle['inputtext.nombre']" /> <h:panelgroup> <h:inputtext id="inputtextnombre" size="50" maxlength="50" styleclass="cajatextoobligat" value="#{clientesbean.cliente.nombre" required="true" /> </h:panelgroup> <h:panelgroup> <t:message for="inputtextnombre" styleclass="mensajeerrortxt" showdetail="true" showsummary="false" detailformat="#{bundle['inputtext.error']" /> </h:panelgroup> <h:outputlabel id="outputlabelapellido1" for="inputtextapellido1" styleclass="label" value="#{bundle['inputtext.apellido1']" /> <h:panelgroup> <h:inputtext id="inputtextapellido1" size="50" maxlength="50" styleclass="cajatextoobligat" value="#{clientesbean.cliente.apellido1" required="true"> </h:inputtext> </h:panelgroup> <h:panelgroup> <t:message for="inputtextapellido1" styleclass="mensajeerrortxt" showdetail="true" showsummary="false" detailformat="#{bundle['inputtext.error']" /> </h:panelgroup> <h:outputtext styleclass="botonaplicaciontxt" value="#{bundle['boton.vuelta_atras'] " /> <h:graphicimage value="img/portal/filtro.jpg" alt="#{bundle['boton.vuelta_atras']" /> </h:commandlink> <h:commandlink id="guardarlink" action="#{clientesbean.guardarcliente" styleclass="buttonsrowleftcolumn"> <h:outputtext styleclass="botonaplicaciontxt" value="#{bundle['boton.guardar_cliente'] " /> <h:graphicimage value="img/portal/filtro.jpg" 24 de 168

25 ... </html> </jsp:root> alt="#{bundle['boton.guardar_cliente']" /> </h:commandlink> El acceso a la capa de negocio desde las páginas JSF se hará a través de clases java llamadas managed beans o beans de respaldo. La asociación de datos entre los componentes de las páginas y sus managed beans se puede hacer de dos maneras: Asociación de valores: permite configurar una propiedad de un componente de la página mediante un atributo de un bean. Ejemplo de asociación de valores <h:inputtext id="inputtextnombre" size="50" maxlength="50" styleclass="cajatextoobligat" value="#{clientesbean.cliente.nombre" required="true" /> Asociación a métodos: permite configurar una propiedad de un componente de la página con el resultado de la invocación a un método del bean. Ejemplo de asociación a métodos <h:commandli nk id= "guardarlink" action="#{clientesbean.guardarcliente" styleclass="buttonsrowleftcolumn"> <h:outputtext styleclass="botonaplicaciontxt" value="#{bundle['boton.guardar_cliente']" /> <h:graphicimage value="img/portal/filtro.jpg" alt="#{bundle['boton.guardar_cliente']" /> </h:commandlink> JSFManagedBean BUENA PRACTICA Se recomienda que desde cada página JSF solamente se acceda a un único managed bean que ofrecerá la interfaz necesaria para la invocación de esa página, salvo en el caso de varias páginas que gestionen el mismo tipo de invocaciones. 25 de 168

26 JSFNegocio Desde las páginas JSF solamente se podrá acceder a managed beans. No está permitido la invocación a los objetos de acceso a datos (DAOs) de la aplicación ni objetos de servicio de negocio. Tampoco está permitido el uso de código Java directamente en la página JSF. BUENA PRACTICA JSFTamano Las páginas JSF se deberán diseñar y modularizar de tal forma que no tomen unas dimensiones excesivas Manejo de eventos El manejo de eventos debe realizarse mediante acciones siempre que sea posible. En el atributo action se debe indicar el método JSF que será invocado ante el click de un usuario en los elementos commandlink, commandbutton o cualquier componente que herede dicho comportamiento. Este método debe ser público, sin parámetros y retornar un String con la dirección que tomarán las reglas de navegación: En la página JSF <h:commandlink id="guardarlink" action="#{clientesbean.guardarcliente" styleclass="buttonsrowleftcolumn"> <h:outputtext styleclass="botonaplicaciontxt" value="#{bundle['boton.guardar_cliente'] " /> <h:graphicimage value="img/portal/filtro.jpg" alt="#{bundle['boton.guardar_cliente']" /> </h:commandlink> En el managed bean * Este metodo inserta o modifica un cliente en el sistema. * atlas.core.exceptions.serviceexception * Lanza atlas.core.exceptions.serviceexception ante cualquier error <code>java.lang.string</code> Devuelve la regla de navegacion * <code>navigationresults.volver_listado_clientes</code>. public String guardarcliente() throws ServiceException { try { facade.insertorupdatecliente(cliente); 26 de 168

27 Framework Atlas catch (ServiceException se) { AtlasFacesUtils.storeOnRequestError(FacesContext.getCurrentInstance(), "error.clientes_modificar", se); throw se; return NavigationResults.VOLVER_LISTADO_CLIENTES; Para más información sobre el uso de NavigationResults ver el apartado de Managed Beans. En caso de existir la necesidad de acceder a elementos de la interfaz de usuario durante la ejecución se puede capturar la llamada mediante un actionlistener, esto permite recibir información sobre el estado de los componentes visuales del cliente mediante el parámetro que es enviado: En la JSF <h:commandlink action= "#{mibean.accion" actionlistener="#{mibean.escuchadoraccion"> <h:outputtext value="#{bundle['texto_del_link']"/> </h:commandlink> En el managed bean: accion public String accion() { //Lógica de la accion. return NavigationResults.MOSTRAR_RESULTADO; En el managed bean: escuchadoraccion public void escuchadoraccion(actionevent evento) { //Lógica relacionada con los componentes UI del cliente por ejemplo, //recuperar los hijos y facets del componente: evento.getcomponent().getfacetsandchildren(); BUENA PRACTICA JSFAcciones Como norma general, se empleará el manejo de eventos mediante acciones (en lugar de ActionListeners) si bien se deberá elegir con cuidado que alternativa de las dos será la óptima en cada caso. En el caso de manejo de eventos mediante actionlisteners se recomienda que se realice en conjunción con acciones estándar, incluyendo la lógica de control de aplicación en estas últimas y delegando sólo las tareas relacionadas con manejo avanzado de los componentes de usuario a los actionlisteners. 27 de 168

28 Por otro lado, están los escuchadores de propiedades (ValueChangeListener) que permiten ejecutar métodos de un managed bean cuando cambia una propiedad de un componente de interfaz de usuario: En la página JSF <h:selectbooleancheckbox id="changecolormode" valuechangelistener="#{resumebean.changecolormode" immediate="true" onchange="submit()" /> En el managed bean public void changecolormode(valuechangeevent event) { boolean flag = ((Boolean) event.getnewvalue()).booleanvalue(); setusingcolornames(!flag); Recuperación de parámetros Como norma general no será necesario enviar parámetros adicionales ya que JSF se encargará de realizar llamadas a los métodos set de los atributos que representan los campos de un formulario, pero habrá casos en los que será necesario el envío de información adicional. Un claro ejemplo es el caso de una funcionalidad maestro-detalle donde se debe enviar un elemento de un listado para poder mostrar posteriormente el detalle del mismo. Para ello disponemos de dos mecanismos: o t:updateactionlistener o f:param El primero consiste en el envío del objeto completo al realizar la acción. Anidando el componente de tomahawk updateactionlistener dentro de un commandlink o un commandbutton conseguimos que JSF actualice los valores de propiedades e incluso objetos completos al realizar una acción: <atlas:listapaginada...> Ejemplo de updateactionlistener <h:column...> <h:commandbutton value="#{bundle['texto_del_boton']" action="#{mibean.mostrarcliente"> <t:updateactionlistener value="#{item" property="#{mibean.cliente"/> </h:commandbutton> </h:column> 28 de 168

29 </atlas:listapaginada> En este ejemplo cuando se invoca el método mostrarcliente en el atributo cliente se establece el valor item. Lamentablemente no siempre es posible hacer uso de esta estrategia, por ejemplo en acciones que tienen el atributo immediate="true". Para estas situaciones disponemos de otro método que nos permite enviar parámetros de tipos de dato primitivos (no objetos o arrays). Cualquier componente de tipo commandbutton, commandlink, outputlink o derivados de los mismos acepta componentes anidados de tipo f:param, que envía el valor asociado a una clave como parámetro de la request. Al ser enviado como parámetro de la request podemos recuperar dichos parámetros en cualquier punto del ciclo de vida de JSF, incluso en el constructor del Managed Bean si fuese necesario: En la JSF <atlas:listapaginada...> <h:column...> <h:commandbutton value="#{bundle['texto_del_boton']" action="#{mibean.mostrarcliente"> <f:param value="#{item.idcliente" name ="parametroidcliente"/> </h:commandbutton> </h:column> </atlas:listapaginada> public String mostrarcliente() { En el managed bean Long idcliente = (Long) FacesSupport.getParameter("parametroIdCliente"); //Cargamos el cliente a partir de su Id llamando a la fachada de //servicios this.cliente = gestionfacade.cargarcliente(idcliente); return NavigationResults.MOSTRAR_CLIENTE; Mediante estas técnicas y el uso del componente t:savestate que se explicará en detalle más adelante podemos reducir al máximo el uso de la sesión Validadores La arquitectura de JSF ofrece mecanismos para automatizar la validación de los datos de una aplicación. Del mismo modo, ofrece la posibilidad de crear validadores a medida. Las validaciones estándar de JSF se realizan en el servidor, aunque también es posible hacer validaciones en el cliente (mediante javascript). 29 de 168

30 Los errores de validación se pueden mostrar mediante los mensajes de JSF utilizando <h:message/> o <h:messages/>. Ejemplo de uso de un validador standard <h:inputtext id="number1" value="#{calcformbean.number1" maxlength="2" size="25" required="true"> <f:validatelongrange minimum="1" maximum="10" /> </h:inputtext> <h:message id="number1error" for="form1:number1" styleclass="error" /> Esta validación comprueba que se haya introducido un valor numérico en el campo number1, y que su longitud no supere los 2 caracteres. Además se comprueba que el número introducido esté entre el 1 y 10. Si los datos introducidos son erróneos, se mostrará un mensaje de error. También existen validadores estándar asociados a ciertos componentes de entrada de datos. Ejemplo de campo obligatorio <h:outputlabel id="outputlabelnombre" for="inputtextnombre" styleclass="label" value="#{bundle['inputtext.nombre']" /> <h:panelgroup> <h:inputtext id="inputtextnombre" size="50" maxlength="50" styleclass="cajatextoobligat" value="#{clientesbean.cliente.nombre" required="true" /> </h:panelgroup> <h:panelgroup> <t:message for="inputtextnombre" styleclass="mensajeerrortxt" showdetail="true" showsummary="false" detailformat="#{bundle['inputtext.error']"/> </h:panelgroup> En el ejemplo anterior hacemos uso de dicho componente para mostrar un error cuando el usuario no introduzca nada en el campo inputtextnombre. BUENA PRACTICA JSFMessages Si deseamos personalizar el mensaje de error a mostrar cuando se produzca un error de validación, es recomendable el uso del componente de tomahawk para mostrar los mensajes (<t:message/> o <t:messages/>). JSF también permite realizar validaciones a nivel de aplicación. Este tipo de validaciones se consideran validaciones de lógica de negocio. Básicamente, la validación a nivel de aplicación conlleva añadir código extra a los métodos de los managed beans, que hacen comprobaciones adicionales sobre los datos obtenidos. 30 de 168

31 Por ejemplo, en una aplicación que implemente un carrito de la compra, la validación a nivel de formulario comprobaría si una cantidad introducida es válida (previa conversión de la cantidad a un objeto java conocido), y la validación a nivel de aplicación podría validar si el usuario ha excedido su límite de crédito. JSFValidacion Todas las validaciones sobre campos de un formulario se han de implementar en el servidor. Si se desea realizar las validaciones en el cliente, deberá existir una comprobación idéntica en el lado del servidor, ya sea mediante validación estándar de JSF o mediante validación a nivel de aplicación. JSFCustomValidator Cuando sea necesario realizar una validación genérica para la que Atlas no ofrezca un validador estándar, se implementará uno a medida. Para crear un validador a medida se creará una clase Java que implemente la interfaz Validator, con la siguiente nomenclatura: o <nombre>validator Donde nombre será sustituido por el nombre del validador. Estas clases se incluirán en el paquete jsf.validators del bloque funcional correspondiente. En el caso de que sean validadores genéricos para todo el proyecto se pueden ponen en un bloque funcional común Conversores Los datos procedentes de una petición Http son cadenas de caracteres. Por eso es necesario un mecanismo de conversión de dichas cadenas al tipo de datos deseado (el declarado en el managed bean vinculado al campo del formulario). Ejemplo de uso de un conversor <h:outputtext value="#{user.dateofbirth"> <f:convertdatetime type="both" datestyle="full" /> </h:outputtext> 31 de 168

32 JSFCustomConversor Cuando sea necesario realizar un conversor particular para la que Atlas no ofrezca un conversor estándar, se implementará uno a medida. Para crear un conversor a medida se creará una clase Java que implemente la interfaz Converter, con la siguiente nomenclatura: o <nombre>converter Donde nombre será sustituido por el nombre del conversor. Estas clases se incluirán en el paquete jsf.converters del bloque funcional correspondiente. En el caso de que sean conversores genéricos para todo el proyecto se pueden ponen en un bloque funcional común Internacionalización El conjunto de elementos culturales, políticos y específicos de una región representados en una aplicación se denominan locale. Las aplicaciones deberían personalizar la presentación de los datos en función del locale preferido del usuario, de esta manera se puede definir el concepto de internacionalización (También conocida como I18n) como el proceso de separar las dependencias locale del código fuente de la aplicación. Ejemplos de dependencias locale pueden ser el conjunto de caracteres, encoding, moneda, formato de tiempo, calendarios, etc. El concepto de Localización (También conocido como L10n) es el proceso de adaptar una aplicación internacionalizada a un locale específico, por lo que las aplicaciones tendrán que estar internacionalizadas de forma previa a ser localizadas. JSF dispone de un potente soporte a la internacionalización y la localización. Para desarrollar una aplicación completamente internacionalizada, todos los literales incluyendo etiquetas, campos de fecha, campos numéricos, campos de texto, mensajes de error y textos mostrados como alternativa a las imágenes se han de externalizar a un archivo de propiedades. El entorno de ejecución de JSF determina el locale de un usuario en base a la configuración de su navegador, aunque se puede establecer por configuración el locale de la misma. JSF usa la clase ResourceBundle para cargar los mensajes de texto del archivo de propiedades y mostrarlos en los componentes de presentación. 32 de 168

33 JSFInternalizacion En las páginas JSF no puede haber literales de texto en un idioma específico. Las aplicaciones contendrán un fichero para almacenar los mensajes internacionalizados. Este fichero se ubicará en la carpeta src/main/resources/msg, con la siguiente nomenclatura: o messages_xx.properties Donde xx es el sufijo del locale al que corresponden los ficheros de mensajes. Este fichero contendrá todos los mensajes de la aplicación. El mecanismo de internacionalización no aplica a mensajes incluidos en trazas, al no ser directamente visualizados por los usuarios finales. Al menos se debe de entregar el fichero de mensajes del locale español (es). Los distintos arquetipos ya vienen preparados con estos ficheros de mensajes y la configuración necesaria para trabajar con ellos. Desde la página JSF cuando queramos acceder a los textos del fichero de internacionalización se utilizará el objeto bundle tal y como se muestra en el siguiente ejemplo: Ejemplo de uso de literales internacionalizados <h:outputlabel id="outputlabelnombre" for="inputtextnombre" styleclass="label" value="#{bundle['inputtext.nombre']" /> Estructura y decoración de la página En muchos casos surge la necesidad de implementar un mecanismo mediante el cual mantengamos una estructura ( layout ) consistente entre todas las páginas que conforman la aplicación Web, lo que implicará tener elementos comunes de página para ser implementados como componentes reutilizables. La tecnología elegida para lograr esto es Facelets, que permite incluir plantillas reutilizables de forma dinámica implementando de forma abstracta el patrón composite view y decorator. Facelets es un lenguaje basado en plantillas que utiliza el concepto de árbol de componentes fomentando la reutilización, permitiendo definir componentes como composición de otros componentes. Podemos destacar las siguientes características sobre Facelets: Trabajo basado en plantillas. Basado en la composición de componentes. 33 de 168

34 Creación de etiquetas lógicas a la medida. Soporte completo a EL, incluyendo funciones. Desarrollo amigable para el diseñador gráfico gracias al concepto de decorador. Creación de librerías de componentes. Lenguaje integrado son JSTL. No son necesarios ficheros de configuración XML. El API de facelets son totalmente independientes del contenedor. Dentro del framework Atlas se han creado los distintos layouts que tienen que utilizar las aplicaciones desarrolladas con este framework. El uso de estos layouts garantiza la homogeneidad de los desarrollos y facilita el mantenimiento de los mismos. Los layouts que ofrece el framework son: hc.xhtml (Horizontal+Contenido). Incluye un menú horizontal, y en el resto de la página se muestra el contenido. hvc.xhtml: (Horizontal+Vertical+Contenido). Incluye un menú horizontal, uno vertical y en el resto de la página se muestra el contenido. 34 de 168

35 hv.xhtml (Horizontal+Visual). Incluye un menú horizontal, y en el resto de la página se muestra el menú visual. hvv.xhtml (Horizontal+Vertical+Visual). Incluye un menú horizontal, menú vertical y en el resto de la página se muestra el menú visual. vc.xhtml (Vertical + Contenido). Incluye un menú vertical, y en el resto de la página se muestra el contenido. 35 de 168

36 vv.xhtml: (Vertical + Visual). Incluye un menú vertical, y en el resto de la página se muestra el menú visual. c.xhtml (Contenido) Incluye solamente la cabecera y el pie. JSFLayout El layout de páginas web debe ser alguno de los que ofrece el framework Atlas. Ejemplo de uso de layout con menú vertical <?xml version="1.0" encoding="utf-8"?> <jsp:root xmlns:jsp=" xmlns:ui=" xmlns:h=" xmlns:f=" xmlns:t=" xmlns:atlas=" xmlns:c=" xmlns:fn=" xmlns:a4j=" xmlns:rich=" version="2.0"> 36 de 168

37 <jsp:text> <![CDATA[ <?xml version="1.0" encoding="utf8"?> ]]> </jsp:text> <jsp:text> <![CDATA[ <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" " ]]> </jsp:text> <html xmlns=" <ui:composition template="/web-inf/layout/vc.xhtml"> <ui:define name="rastromigas"> <ui:include src="/secure/rastromigas/rastro.xhtml" /> </ui:define> <ui:define name="menuvertical"> <ui:include src="/secure/menu/menu.xhtml" /> </ui:define> <ui:define name="content">... Aqui se pondría el contenido de nuestra página </ui:define> </ui:composition> </html> </jsp:root> JSFPanel La ubicación de los distintos elementos que forman la página se realizará con los componentes que JSF ofrece: PanelGrids y PanelGroup. No se utilizarán directamente tablas de html. Para más información y ejemplos de layout acceder a la aplicación de componentes. 37 de 168

38 Uso de javascript JSFJavascript Se debe minimizar el uso de Javascript y el código javascript que se incluya debe ser compatible con los navegadores. En el caso de utilizar codigo javascript este se implementará mediante funciones que se ubicarán en ficheros js. Los ficheros de javascript deberán ubicarse dentro de la carpeta src/main/webapp/js. Los ficheros js que se incluyen en los arquetipos no pueden ser modificados Normas de estilo Existe un documento llamado Atlas Guía de Estilo que incluye información sobre: o o o Estilo de las aplicaciones Accesibilidad Usabilidad Es necesario leer este documento antes de abordar la implementación de las páginas JSF. JSFAccesiblidad Las aplicaciones de la Comunidad de Madrid que se publiquen en Internet tendrán que cumplir un Nivel de Conformidad "A" de WCAG, esto implicará que las aplicaciones sean estrictas en el cumplimiento de las normas de prioridad 1 especificadas en el Anexo Guía de Estilo del framework Atlas. JSFImagenes Las imágenes a utilizar en las aplicaciones del framework Atlas deberán ubicarse dentro de la carpeta src/main/webapp/img 38 de 168

39 JSFCSS Las hojas de estilo se ubicaran en la carpeta src/main/webapp/css. Dentro de esta carpeta se encuenta un fichero llamado atlas.css que incluye los estilos de Atlas. Este fichero no se puede modificar. En el caso de necesitar nuevos estilos estos se crearán dentro de un fichero con la siguiente nomenclatura xxxx.css Donde xxxx es el nombre de la aplicación. Nunca se podrán definir estilos directamente dentro de una página Interfaces ricas de usuario (RIA) Existen tecnologías que pretenden mejorar las aplicaciones web asemejándolas todo lo posible a las aplicaciones de escritorio tradicionales. La arquitectura de ICM permite crear aplicaciones RIA utilizando AJAX de dos maneras: Mediante la librería Ajax4JSF Usando los componentes JSF del framework Atlas que poseen comportamiento asíncrono con AJAX de forma transparente. Ajax4JSF se incluye dentro de los componentes RichFaces. Es una librería open source que se integra totalmente en la arquitectura de JSF y extiende la funcionalidad de sus etiquetas dotándolas con tecnología Ajax de forma limpia y sin añadir código Javascript. Mediante esta librería se puede variar el ciclo de vida de una petición JSF, recargar determinados componentes de la página sin necesidad de recargarla por completo, realizar peticiones al servidor automáticas, control de cualquier evento de usuario, etc. Esta aproximación tiene las siguientes ventajas: La cantidad de javascript que hay que escribir (y mantener) es mínima. Esto reduce enormemente el tiempo de depuración y pruebas necesarias cuando se trabaja en un entorno multi-navegador. Fácil integración: Ajax4JSF apenas requiere la modificación del código existente. Soporte Facelets: Es una solución que se integra a la perfección con la tecnología de decoración y estructura de páginas, es decir, facelets. Compatibilidad. No es necesario desarrollar otra aplicación para cuando el navegador no soporta AJAX. En este caso, la aplicación se comportará de la forma tradicional, refrescando la página completa. 39 de 168

40 JSFAjax Si se desea dotar de capacidades AJAX a las páginas JSF se utilizará Ajax4JSF. El uso de cualquier otra tecnología RIA deberá ser consensuado previamente con ICM. El arquetipo web ya viene configurado para trabajar con Ajax4JSF. La forma mas sencilla de incluir ajax4jsf en una página es incluir una región y todo lo que se incluya dentro de esta se refrescará parcialmente. Ejemplo de uso de región ajax <a4j:form id="allroomsform2" ajaxsubmit="true" rerender="roomstable,scroll_1,scroll_2" status="ajaxstatus"> <a4j:region id="region1" selfrendered="true">.. </a4j:region> </a4j:form> JSFAjaxInterac La invocación de funcionalidad AJAX debe ser siempre consecuencia de una interacción con el usuario, por ejemplo, al seleccionar el valor de un combo, se carga de manera dinámica los valores de otro. En concreto, la carga inicial de una página no debe implicar la ejecución de funcionalidad AJAX. BUENA PRACTICA JSFAjaxLimite Se recomienda limitar la cantidad de información intercambiada mediante AJAX. En ocasiones es preferible recargar la página de nuevo, a intercambiar mediante AJAX gran cantidad de información. 40 de 168

41 6.2.2 MANAGED BEANS Los managed beans o beans de respaldo son las clases que incluyen los atributos y métodos que van a ser invocados desde las páginas JSF. Los distintos métodos que puede tener un managed bean son: 1. Gettter y setter de los atributos 2. Métodos manejadores de eventos de acción 3. Métodos de manejo de eventos de cambio de valor 4. Métodos de acción JSFMBeansImpl Dentro de una aplicación en cada bloque funcional se han de crear los managed beans que darán cobertura a las peticiones de las páginas JSF. La nomenclatura de estas clases será: <nombre>bean Donde <nombre> debe ser sustituido por el nombre del Bean. Estas clases Java se crearán en el paquete jsf dentro del bloque funcional correspondiente. A continuación se muestra parte de un ejemplo de managed bean. El ejemplo completo se puede ver dentro del arquetipo de aplicaciones web. package ejpl.gestion.jsf; ClientesBean.java import * Esta clase representa el Backing Bean * para las páginas que hagan uso de la * entidad ejpl.gestion.domain.cliente. ICM public class ClientesBean { * Identificador del numero de serie para serializacion private static final long serialversionuid = 1L; * Servicio de la fachada 41 de 168

42 private GestionFacade facade; * Cliente actual private Cliente cliente = null; * Filtro para el nombre del cliente private String nombrecliente = null; * Constructor por defecto. * <p> * Se realizan las operaciones de * inicialización para los Managed Beans public ClientesBean() { this.cliente = new Cliente(); cliente.setestadocivil(new EstadoCivil()); <code>ejpl.gestion.domain.cliente</code> Devuelve el objeto de * dominio cliente asociado al Backing Bean. public Cliente getcliente() { return this.cliente; cliente <code>ejpl.gestion.domain.cliente</code> Modifica el * objeto de dominio asociado al Backing Bean. public void setcliente(cliente cliente) { this.cliente = cliente; * Este metodo obtiene un cliente a partir de un identificador/pk obtenida * de la request. * atlas.core.exceptions.serviceexception * Lanza atlas.core.exceptions.serviceexception ante cualquier error <code>java.lang.string</code> Devuelve la regla de navegacion * <code>navigationresults.modificar_cliente</code>. public String cargarcliente() throws ServiceException { String paramidcliente = AtlasFacesUtils.getFromRequest(FacesContext.getCurrentInstance(), "idcliente"); try { if (paramidcliente!= null) { Integer idcliente = Integer.valueOf(paramIdCliente); this.cliente = facade.obtenerclienteporid(idcliente); catch (ServiceException se) { 42 de 168

43 AtlasFacesUtils.storeOnRequestError(FacesContext.getCurrentInstance(), "error.clientes_obtener", se); // return NavigationResults.MOSTRAR_ERROR; throw se; return NavigationResults.MODIFICAR_CLIENTE; * Este metodo inserta o modifica un cliente en el sistema. * atlas.core.exceptions.serviceexception Lanza * atlas.core.exceptions.serviceexception ante cualquier error * producido. <code>java.lang.string</code> Devuelve la regla de navegacion * <code>navigationresults.volver_listado_clientes</code>. public String guardarcliente() throws ServiceException { try { facade.insertorupdatecliente(cliente); catch (ServiceException se) { AtlasFacesUtils.storeOnRequestError(FacesContext.getCurrentInstance(), "error.clientes_modificar", se); // return NavigationResults.MOSTRAR_ERROR; throw se; return NavigationResults.VOLVER_LISTADO_CLIENTES;... JSFAnotacion Las clases que representan los Managed Beans de JSF deberán tener la JSFMBAtributos Los atributos de un managed bean se definirán como privados, con métodos get y set para aquellas propiedades que vayan a ser vinculadas a un componente de una página JSF. BUENA PRACTICA JSFMBunico Se recomienda crear un managed bean por cada página JSF, de tal manera que tanto los datos como el comportamiento de esta página sean manejados por el bean en cuestión. Un managed bean no debería mezclar atributos o comportamientos de dos páginas que no estén relacionadas. 43 de 168

44 El acceso a los datos persistentes deberá realizarse a través de la capa de negocio, haciendo uso de la fachada que dicha capa expondrá a tal efecto. Además no está permitida la invocación directa a servicios de negocio sin pasar por la fachada. class jsf ClientesBean - cliente: Cliente = null - clientesscroller: HtmlDataScroller = new HtmlDataScr... - facade: GestionFacade - nombrecliente: String = null - orderandfilterclientes: OrderAndFilterBean = null - serialversionuid: long = 1L {readonly Página JSF + cargarcliente() : String + ClientesBean() + filtrar() : String + getcliente() : Cliente + getclientesscroller() : HtmlDataScroller + getfacade() : GestionFacade + getnombrecliente() : String + getorderandfilterclientes() : OrderAndFilterBean + gettimezone() : TimeZone + guardarcliente() : String + nuevocliente() : String + obtenerclientes(int, int, Object, Object) : List<Cliente> + obtenertotalclientes(object) : int + setcliente(cliente) : void + setclientesscroller(htmldatascroller) : void + setestadocivil(string) : void + setfacade(gestionfacade) : void + setidestadocivil(string) : void + setnombrecliente(string) : void + setorderandfilterclientes(orderandfilterbean) : void + volver() : String -facade «interface» facade::gestionfacade + deletecliente(cliente) : void + insertcliente(cliente) : void + insertorupdatecliente(cliente) : void + obtenerclienteporid(integer) : Cliente + obtenerclientes(int, int, Object, Object) : List<Cliente> + obtenertotalclientes(object) : int + updatecliente(cliente) : void JSFFacade El acceso a la capa de negocio desde los managed beans siempre se debe hacer a través de la fachada. Esto implica que desde las clases managed beans no se puede invocar ni DAOs ni ningún servicio que no sea la fachada Manejo de excepciones JSF no ofrece un mecanismo automático para el manejo de las excepciones producidas dentro de los managed beans, aunque si dispone de ciertos elementos que ayudan en la gestión de las mismas. Dentro del API de JSF existe una clase que permite mostrar mensajes genéricos (normalmente mensajes de error) llamada FacesMessage. Añadiendo un objeto de esta clase al contexto de la JSF, este mensaje se puede mostrar en cualquier JSF mediante una etiqueta estándar. Mediante el uso de esta clase, podemos tratar las excepciones de los beans de la aplicación, de forma que cuando se produzcan se almacene uno de estos mensajes: 44 de 168

45 JSFException Todos los métodos de los managed beans que hagan uso de la fachada, tratarán las excepciones que esta pueda lanzar, que siempre serán de tipo ServiceException o clases que hereden de esta. La forma de manejar la excepción dependerá del origen de la misma, distinguiendo entre excepciones de negocio (excepción creada a medida) y excepciones del sistema. o En el primer caso, se atrapará la excepción y se implementará el código que deseemos que se ejecute en base a las reglas de nuestro negocio. Es decir, si por ejemplo se produce una supuesta excepción (creada a medida) BlockedUserException indicando que un usuario está bloqueado, se podría implementar una funcionalidad que redirija la petición inicial a otra aplicación externa que permita desbloquear la cuenta del usuario. o En el segundo caso, siempre se redirigirá a una página de error que extraerá la excepción encapsulada dentro del ServiceException (como por ejemplo una DataAccessException ) mostrando un mensaje amigable al usuario final en función de la excepción manejada. Los métodos del bean podrían manejar las excepciones de la siguiente forma: Ejemplo de manejo de excepciones * Este metodo inserta o modifica un cliente en el sistema. * atlas.core.exceptions.serviceexception Lanza * atlas.core.exceptions.serviceexception ante cualquier error * producido. <code>java.lang.string</code> Devuelve la regla de navegacion * <code>navigationresults.volver_listado_clientes</code>. public String guardarcliente() throws ServiceException { try { facade.insertorupdatecliente(cliente); catch (ServiceException se) { AtlasFacesUtils.storeOnRequestError(FacesContext.getCurrentInstance(), "error.clientes_modificar", se); throw se; return NavigationResults.VOLVER_LISTADO_CLIENTES; Cuando se produce una excepción, el método está almacenando un mensaje en el contexto de JSF. Para presentar el error tendríamos que incluir en la página JSF la etiqueta t:message. 45 de 168

46 También se manejarán las excepciones que puedan producirse en otros puntos del bean (constructor, método init, listeners, etc.) Navegación JSFNavegacion Los valores posibles para la navegación dinámica de los managed beans se han de almacenar en una clase aparte, para tenerlos todos localizados en un mismo lugar. Esta clase debe llamarse NavigationsResults y ubicarse en el paquete jsf de cada bloque funcional. En el caso de que se tengan varios bloques funcionales hay que añadir por delante el nombre del bloque funcional para poder distinguir una clase de otra. (Ejemplo <bloquefuncional>navigationresults). En esta clase se definirán como constantes (public static final String) todos los caminos de la navegación. A continuación se muestra un ejemplo de esta clase package ejpl.gestion.jsf; NavigationResults.java * Esta clase representa constantes asociadas * a las reglas de navegacion de la aplicacion. ICM 1.0. Atlas public final class NavigationResults { * Constructor para que no se genere el publico por defecto protected NavigationResults() { * Operacion de navegacion: Resultado de la operacion correcto. public static final String SUCCESS = "success"; * Operacion de navegacion: Resultado de la operacion fallido. public static final String FAILURE = "failure"; 46 de 168

47 * Operacion de navegacion: Salir de la aplicacion. public static final String LOGOUT = "logout"; * Operacion de navegacion: Nuevo Cliente. public static final String NUEVO_CLIENTE = "nuevocliente"; * Operacion de navegacion: Modificar Cliente. public static final String MODIFICAR_CLIENTE = "modificarcliente"; * Operacion de navegacion: Eliminar Cliente. public static final String ELIMINAR_CLIENTE = "eliminarcliente"; * Operacion de navegacion: Volver al listado de Clientes. public static final String VOLVER_LISTADO_CLIENTES = "volverlistadoclientes"; * Operacion de navegacion: Mostrar pagina de error. public static final String MOSTRAR_ERROR = "mostrarerror"; Los métodos de las clases managed beans deberán utilizar estas variables en la respuesta de los métodos de acción tal y como se puede ver en los ejemplos anteriormente expuestos. Los elementos de navegación indicados en el fichero NavigationResults deberán ser utilizados en el fichero de JSF de configuración de la navegación tal y como se comenta en el apartado facesnavigation.xml Configuración de JSF Para realizar la configuración necesaria para los componentes JSF de las aplicaciones del framework Atlas tenemos que tener en cuenta que esta configuración se encuentra dentro de tres ficheros. Estos ficheros los podemos encontrar en el arquetipo web previamente configurados en el directorio src/main/webapp/web-inf. Fichero de configuración faces-config.xml faces-managed-beans.xml Descripción Fichero principal de configuración de JSF. No se puede modificar este fichero. Fichero donde se definen los managed beans de la aplicación. 47 de 168

48 faces-navigation.xml Fichero donde se configuran las reglas de navegación de la aplicación faces-config.xml El fichero de configuración faces-config.xml ya incluye: o Configuración de los resolver de variables y propiedades que permiter inyectar beans de Spring en los managed beans. o Configuración de los ficheros de mensajes y de los locales. JSFfacesconfigxml La configuración que se encuentra dentro del fichero faces-config.xml del arquetipo no se puede modificar. En el caso de que se desee modificar se debe solicitar la correspondiente autorización a ICM justificando dicha necesidad faces-managed-beans.xml El fichero de configuración faces-managed-beans.xml contiene los distintos managed beans que se van a utilizar dentro de las páginas JSF. Cada vez que se cree un nuevo managed bean hay que incluir su definición en este fichero de configuración: Ejemplo de configuración de managed bean <managed-bean> <description>bean de clientes</description> <managed-bean-name>clientesbean</managed-bean-name> <managed-bean-class> ejpl.gestion.jsf.clientesbean </managed-bean-class> <managed-bean-scope>request</managed-bean-scope> <managed-property> <property-name>facade</property-name> <value>#{facade</value> </managed-property> <managed-property> <property-name>orderandfilterclientes</property-name> <value>#{orderandfilterclientes</value> </managed-property> </managed-bean> Uso del contexto dentro del faces-managed-beans.xml El contexto de una aplicación Web permite el almacenamiento de información relevante a lo largo de la ejecución de diversas operaciones por parte del usuario. 48 de 168

49 Las decisiones sobre el mantenimiento del estado tienen impacto en el rendimiento de la aplicación, así como en la disponibilidad y la escalabilidad. Estas decisiones incluyen elegir la capa de la aplicación donde manejar el estado, el ámbito apropiado para cada elemento a almacenar y como mantener el estado en un entorno distribuido. En las aplicaciones JEE el estado tiene distintos ámbitos, entendiéndose como ámbito a los distintos lugares desde donde ese estado es accesible. Resumiendo, se puede decir que el estado en la capa de presentación se puede mantener en cuatro ámbitos. JSF amplia estos ámbitos, permitiendo guardar y restaurar el estado de los componentes para cada petición tanto en el cliente como en el servidor: Ámbito Página Petición Sesión Descripción Aplicable sólo a páginas JSF contiene datos que solo son válidos en el contexto de una página. Cuando una JSF redirige o incluye a otra, cada página define su propio estado. Permite almacenar información que será accesible por todos los componentes Web que intervengan en esa petición hasta que se genere la respuesta al usuario. Permite almacenar información que será accesible por todos los componentes Web durante la sesión del usuario, que durará desde que el usuario entre en la aplicación hasta que salga de ella o transcurra un tiempo máximo de inactividad. Aplicación Permite almacenar información que será accesible por todos los componentes de la aplicación web en cualquier momento (mientras la aplicación esté activa). Cliente Servidor El árbol de componentes JSF se guarda en un campo oculto dentro de la petición Http El árbol se almacena en la sesión Http Para definir el contexto de un managed bean se utiliza el atributo managed-bean-scope. JSFRequest Los managed beans deben ser siempre de ámbito request, pudiendo ser de ámbito sesión tan sólo en casos excepcionales y justificados. 49 de 168

50 MyFaces amplia este modelo haciendo posible escribir aplicaciones sin necesidad del uso del HttpSession. Toda la información tanto de la vista como del modelo (managed beans) puede ser codificada y enviada al cliente. Esto se lleva a cabo mediante una etiqueta presente en tomahawk: <t:savestate> <t:savestate id="save1" value="#{calcform.number1" /> El único requisito para poder almacenar un objeto completo, es que el bean implemente el interfaz java.io.serializable JSFSavestate BUENA PRACTICA El problema principal del almacenamiento de información (tanto del árbol de componentes como de los managed beans) es el rendimiento. El tiempo de serialización y deserialización de los objetos aumenta considerablemente el tiempo de respuesta ante una petición, del mismo modo que el ancho de banda consumido (y por tanto de tiempo de transferencia de las páginas). Por lo tanto se recomienda reducir el uso de savestate a casos imprescindibles faces-navigation.xml El fichero de configuración faces-navigation.xml incluye las reglas de navegación de JSF. Presenta dos tipos de navegación: Estática: cuando desde una página se va directamente a otra. Esto se hace definiendo las reglas de navegación en el fichero de configuración. Dinámica: cuando una acción o cierta lógica determina la página a la que navegar. Esto lo soporta permitiendo que los componentes definan como destino de su navegación el resultado de una consulta a un manejador de acciones, donde se codifica la navegación dinámica, frente a la definición de un destino fijo. A continuación se muestra un ejemplo de las reglas de navegación para una aplicación simple: 50 de 168

51 Ejemplo de faces-navigation.xml <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE faces-config PUBLIC "-//Sun Microsystems, Inc.//DTD JavaServer Faces Config 1.0//EN" " <!-- ============================================================== --> <!-- Fichero donde se definen todas --> <!-- las reglas de navegación de la aplicación --> <!-- ============================================================== --> <faces-config> <navigation-rule> <description> Reglas de navegacion para la pagina index.xhtml </description> <from-view-id>/secure/index.xhtml</from-view-id> <navigation-case> <from-outcome>nuevocliente</from-outcome> <to-view-id>/secure/formulariocliente.xhtml</to-view-id> </navigation-case> <navigation-case> <from-outcome>modificarcliente</from-outcome> <to-view-id>/secure/formulariocliente.xhtml</to-view-id> </navigation-case> <navigation-case> <from-outcome>eliminarcliente</from-outcome> <to-view-id>/secure/index.xhtml</to-view-id> </navigation-case> </navigation-rule> <navigation-rule> <description> Reglas de navegacion para la pagina formulariocliente.xhtml </description> <from-view-id>/secure/formulariocliente.xhtml</from-view-id> <navigation-case> <from-outcome>volverlistadoclientes</from-outcome> <to-view-id>/secure/index.xhtml</to-view-id> </navigation-case> </navigation-rule> </faces-config> JSFNavDes Se ha de ofrecer un comentario explicativo en el atributo description para cada regla de navegación definida en el archivo de configuración navigation-rule.xml Mediante reglas de navegación de JSF se puede hacer uso de patrones, de forma que una serie de páginas lleven a una dada: 51 de 168

52 Ejemplo de regla de navegación con patrones <navigation-rule> <description> Regla de navegación para todas las páginas de la carpeta pages </description> <from-view-id>/pages/*</from-view-id> <navigation-case> <from-outcome>menu</from-outcome> <to-view-id>/menu/main_main.jsp</to-view-id> </navigation-case> <navigation-case> <from-outcome>info</from-outcome> <to-view-id>/menu/info.jsp</to-view-id> </navigation-case> </navigation-rule> También se pueden especificar destinos globales de forma que desde cualquier página se pueda navegar una dada. El siguiente ejemplo muestra como con esta característica se puede implementar una opción de ayuda global para la aplicación: Ejemplo de regla de navegación global <navigation-rule> <navigation-case> <from-outcome>globalhelp</from-outcome> <to-view-id>/menu/generalhelp.jsp</to-view-id> </navigation-case> </navigation-rule> Archivos de configuración adicionales y web.xml JSFConfAdicional Si el tamaño de los ficheros faces-managed-beans.xml o faces-navigation.xml creciese en exceso, se permite crear ficheros adicionales que agrupen los beans/reglas por funcionalidad. Dichos ficheros deberán denominarse: - faces-managed-beans-yyyy.xml - faces-navigation-yyyy.xml Donde yyyy puede ser cualquier término en minúsculas que sea representativo de la funcionalidad que agrupan los ficheros. Además, en el parámetro javax.config.config_files del archivo web.xml del proyecto deberá añadirse referencias a los nuevos ficheros de configuración. 52 de 168

53 El fichero de configuración web.xml del arquetipo ya viene preconfigurado con todos los parámetros de configuración de JSF. JSFwebxml La configuración de JSF que se encuentra en el arquetipo dentro del fichero de configuración web.xml no se puede modificar (excepto el parámetro javax.config.config_files si se incluyesen ficheros de configuración adicionales). En el caso de que se desee modificar se debe solicitar la correspondiente autorización a ICM justificando dicha necesidad. 53 de 168

54 6.2.4 Uso de la Sesión En el servidor de aplicaciones se crea un objeto sesión por cada usuario que se conecta, y se mantiene allí durante un tiempo. Cuando una aplicación tiene mucha concurrencia, esto puede ser un problema grave en un entorno de producción debido a la cantidad de memoria ocupada por estas sesiones. La situación se complica en un entorno de clúster, en el que la información de sesión tiene que replicarse entre 2 o más instancias del servidor de aplicaciones. JSFSesion El contenido de la sesión nunca debe exceder los 4 Kbytes de tamaño Cuando sea necesario almacenar una cantidad de información importante (superior a 4Kbytes) durante un tiempo de vida superior a la petición, siempre y cuando haya sido previamente autorizado por ICM, se implementará el mecanismo de persistencia en BBDD indicado por el framework Atlas. En cualquier caso se deben eliminar de la sesión los datos cuando ya no sean necesarios. JSFHttpSession Se debe minimizar el uso del objeto HttpSession. En caso de que se necesite solamente se podrá utilizar el objeto HttpSesion desde los managed beans. JSFTiempoSesion El tiempo de vida de la sesión será establecido a nivel del servidor de aplicaciones, nunca se definirá a nivel de la aplicación. Por tanto las aplicaciones no podrán depender de un valor concreto de dicho tiempo para su correcto funcionamiento. JSFUsoSesion Cada vez que se acceda a un objeto de la sesión se debe comprobar previamente la existencia de dicho objeto y actuar en consecuencia, para prevenir errores ante una pérdida de sesión. 54 de 168

55 JSFCreacionSesion La sesión será creada automáticamente por el framework por lo tanto las aplicaciones no pueden crearla, esto significa que no se puede obtener el objeto sesión de la siguiente forma: request.getsession(true). 55 de 168

56 6.3 SERVICIOS DE NEGOCIO Los servicios de negocio son aquellos que implementan la lógica que complementa las operaciones de acceso a datos para cubrir los requisitos de negocio de una aplicación. La arquitectura de aplicaciones del framework Atlas busca simplificar la creación e integración de aplicaciones de negocio, por lo que está construida en base a una arquitectura orientada a servicios (SOA). En una arquitectura SOA, los servicios de negocio no tienen porqué ser implementados como servicios web. El uso de servicios web debería limitarse a aquellos casos en los que realmente se vaya a sacar provecho a esta aproximación. Como norma general, se expondrán como servicios web aquellos servicios con una funcionalidad de negocio que sea susceptible de ser reutilizada en otras aplicaciones, que ofrezcan una granularidad gruesa 1 e interfaces bien definidos. En este tipo de servicios, los interfaces han de definir el intercambio de datos de negocio, no el intercambio de objetos. Para obtener mas información sobre los servicios web dentro del framework Atlas ir al apartado 8. SERVICIOS WEB. Para el resto de casos se emplearán servicios de negocio implementados como clases Java simples (POJOs) con una clara orientación a servicio, haciendo uso de las funcionalidades que Spring ofrece. De esta forma en un momento dado uno de estos servicios puede ser expuesto como servicio web para ser empleado por otras aplicaciones. Los beneficios de esta aproximación son los siguientes: Simplificación en el desarrollo de componentes de negocio. Simplificación del ensamblaje y despliegue de soluciones de negocio construidas como redes de servicios. Aumento de la flexibilidad y agilidad. Protección de la inversión en tecnología y lógica de negocio existente. Simplificación de las pruebas. Dentro de la capa de servicios vamos a identificar dos tipos de elementos: o o Fachada Servicios La siguiente figura muestra un ejemplo de una parte de la capa de servicios del framework ATLAS: 1 Nivel de granularidad en la que el interfaz del servicio define relativamente pocos métodos de servicio para conseguir un objetivo de negocio, mediante parámetros orientados a documento 56 de 168

57 class facade «interface» GestionFacade + deletecliente(cliente) : void + insertcliente(cliente) : void + insertorupdatecliente(cliente) : void + obtenerclienteporid(integer) : Cliente + obtenerclientes(int, int, Object, Object) : List<Cliente> + obtenertotalclientes(object) : int + updatecliente(cliente) : void services::clienteserviceimpl - clientedao: ClienteDAO + ClienteServiceImpl() + deletecliente(cliente) : void + insertcliente(cliente) : void + insertorupdatecliente(cliente) : void + obtenerclienteporid(integer) : Cliente + obtenerclientes(int, int, Object, Object) : List<Cliente> + obtenertotalclientes(object) : int + setclientedao(clientedao) : void + updatecliente(cliente) : void GestionFacadeImpl - clienteservice: ClienteService + deletecliente(cliente) : void + GestionFacadeImpl() + insertcliente(cliente) : void + insertorupdatecliente(cliente) : void + obtenerclienteporid(integer) : Cliente + obtenerclientes(int, int, Object, Object) : List<Cliente> + obtenertotalclientes(object) : int + setclienteservice(clienteservice) : void + updatecliente(cliente) : void «interface» services::clienteservice + deletecliente(cliente) : void -clienteservice + insertcliente(cliente) : void + insertorupdatecliente(cliente) : void + obtenerclienteporid(integer) : Cliente + obtenerclientes(int, int, Object, Object) : List <Cliente> + obtenertotalclientes(object) : int + updatecliente(cliente) : void ATENCION Aunque en este ejemplo se muestra solamente un servicio lo normal es que la fachada acceda a varios servicios. Los servicios se separarán en bloques funcionales para facilitar el mantenimiento posterior de la aplicación. Cada bloque funcional estará formado por los objetos de dominio, los DAOs, los servicios y la fachada. 57 de 168

58 6.3.1 FACHADA En primer lugar nos encontramos con la fachada que será el punto central de acceso a los servicios de negocio de un bloque funcional. Los componentes de la capa de presentación invocarán por tanto a esta fachada. La fachada constituye el lugar idóneo para poder gestionar de forma sencilla los aspectos transversales a la arquitectura, tales como las transacciones, la seguridad, la auditoria de acceso a información protegida y las trazas. SNFacade Dentro de una aplicación en cada bloque funcional se ha de crear un servicio que haga de fachada 2 al resto de servicios de negocio. Las responsabilidades de esta fachada son las siguientes: o Manejar las peticiones de la capa de presentación. o Recuperar los datos (en forma de objetos de dominio) que requiere la capa de presentación. o Usar inyección de dependencias para crear los servicios de negocio. o Delegar la ejecución a los servicios de negocio. o Manejar las transacciones. Cada bloque funcional deberá tener una fachada y solo puede haber una fachada por cada bloque funcional. De esta manera, para acceder a la lógica de negocio de la aplicación se empleará siempre esta fachada. Esto reduce el número de objetos a usar desde el cliente y el acoplamiento con la capa de servicios de negocio, ya que un servicio puede ser reemplazado o modificado sin afectar a la capa de presentación de la aplicación. De forma general, la fachada delegará la ejecución de los métodos de negocio al correspondiente servicio de negocio, aunque también puede definir métodos de más alto nivel que impliquen el uso de varios servicios de negocio. 2 El patrón de diseño Facade (fachada) sirve para proveer de una interfaz unificada sencilla que haga de intermediaria entre un cliente y una interfaz o grupo de interfaces más complejas. 58 de 168

59 SNFacadeImpl Para crear una fachada se crearán dos clases, con la siguiente nomenclatura: o <nombre>facade (Interfaz de la fachada) o <nombre>facaceimpl (Implementación de la interfaz) Donde <nombre> debe ser sustituido por el nombre del bloque funcional al que pertenece la fachada. Estas clases se incluirán en el paquete services.facade del bloque funcional correspondiente. class facade «interface» GestionFacade + deletecliente(cliente) : void + insertcliente(cliente) : void + insertorupdatecliente(cliente) : void + obtenerclienteporid(integer) : Cliente + obtenerclientes(int, int, Object, Object) : List<Cliente> + obtenertotalclientes(object) : int + updatecliente(cliente) : void GestionFacadeImpl - clienteservice: ClienteService + deletecliente(cliente) : void + GestionFacadeImpl() + insertcliente(cliente) : void + insertorupdatecliente(cliente) : void + obtenerclienteporid(integer) : Cliente + obtenerclientes(int, int, Object, Object) : List<Cliente> + obtenertotalclientes(object) : int + setclienteservice(clienteservice) : void + updatecliente(cliente) : void Una de las implicaciones más importantes al trabajar con JSF es que de alguna manera lo que se presenta al usuario dentro de un formulario es el propio objeto de dominio, generados por la capa de acceso de datos y obtenidos a través de la fachada. SNDominio Los métodos de la fachada utilizarán objetos de dominio (esto es, los que representan los datos de la aplicación) cuando sea necesario. No es necesario crear clases adicionales (los viejos DTO, Data Transfer Objects) para enviar este tipo de datos. 59 de 168

60 A continuación se muestra un ejemplo de interfaz e implementación de una fachada. package ejpl.gestion.services.facade; Ejemplo de interfaz de una fachada import java.util.list; import ejpl.gestion.domain.cliente; import atlas.core.exceptions.serviceexception; * Esta interfaz representa las operaciones * de la facacha del sistema. ICM 1.0 ATLAS public interface GestionFacade { * Este metodo inserta un nuevo cliente en el sistema. * cliente Cliente a insertar. atlas.core.exceptions.serviceexception * Lanza atlas.core.exceptions.serviceexception ante cualquier error producido. void insertcliente(cliente cliente) throws ServiceException; * Este metodo obtiene un Cliente a partir de la PK. * idcliente PK del cliente. atlas.core.exceptions.serviceexception * Lanza atlas.core.exceptions.serviceexception ante cualquier error * <code>ejpl.gestion.domain.cliente</code> que representa el Cliente encontrado o null en caso contrario. Cliente obtenerclienteporid(integer idcliente) throws ServiceException; package ejpl.gestion.services.facade; Ejemplo de implementación de una fachada import java.util.list; import atlas.core.exceptions.serviceexception; import org.springframework.stereotype.service; import ejpl.gestion.domain.cliente; import ejpl.gestion.services.clienteservice; /* Esta clase representa la fachada del sistema. ICM 60 de 168

61 public class GestionFacadeImpl implements GestionFacade { * El Servicio de Clientes private ClienteService clienteservice; * Constructor sin argumentos. public GestionFacadeImpl() { * Este metodo inyecta el servicio ClienteService. clienteservice El servicio a inyectar. public void setclienteservice(clienteservice clienteservice) { this.clienteservice = clienteservice; * {@inheritdoc ejpl.gestion.services.facade.gestionfacade#insertcliente(ejpl.gestion.domain.cliente) public void insertcliente(cliente cliente) throws ServiceException { clienteservice.insertcliente(cliente); * {@inheritdoc * ejpl.gestion.services.facade.gestionfacade#obtenerclienteporid(java.lang. * Integer) public Cliente obtenerclienteporid(integer idcliente) throws ServiceException { return clienteservice.obtenerclienteporid(idcliente); 61 de 168

62 6.3.2 SERVICIOS Como ya se ha comentado anteriormente los servicios implementarán la lógica de negocio de la aplicación. SNServiceImpl Para crear un servicio se crearán dos clases, con la siguiente nomenclatura: o <nombre>service (Interfaz del servicio) o <nombre>serviceimpl (Implementación del servicio) Donde <nombre> debe ser sustituido por el nombre del servicio. Estas clases se incluirán en el paquete services del bloque funcional correspondiente. class services «interface» ClienteService + deletecliente(cliente) : void + insertcliente(cliente) : void + insertorupdatecliente(cliente) : void + obtenerclienteporid(integer) : Cliente + obtenerclientes(int, int, Object, Object) : List <Cliente> + obtenertotalclientes(object) : int + updatecliente(cliente) : void ClienteServiceImpl - clientedao: ClienteDAO + ClienteServiceImpl() + deletecliente(cliente) : void + insertcliente(cliente) : void + insertorupdatecliente(cliente) : void + obtenerclienteporid(integer) : Cliente + obtenerclientes(int, int, Object, Object) : List<Cliente> + obtenertotalclientes(object) : int + setclientedao(clientedao) : void + updatecliente(cliente) : void SNAnotacion Todos las implementaciones de los servicios deberán ir precedidos de la 62 de 168

63 A continuación se muestra un ejemplo de interfaz e implementación de un servicio. package ejpl.gestion.services; Ejemplo de interfaz de un servicio import java.util.list; import ejpl.gestion.domain.cliente; import atlas.core.exceptions.serviceexception; * Esta interfaz representa las operaciones * asociadas a la entidad Cliente. ICM 1.0 ATLAS public interface ClienteService { * Este metodo inserta un nuevo cliente en el sistema. * cliente Cliente a insertar. atlas.core.exceptions.serviceexception * Lanza atlas.core.exceptions.serviceexception ante cualquier error producido. void insertcliente(cliente cliente) throws ServiceException; * Este metodo obtiene un Cliente a partir de la PK. * idcliente PK del cliente. * atlas.core.exceptions.serviceexception * Lanza atlas.core.exceptions.serviceexception ante cualquier error producido. * <code>ejpl.gestion.domain.cliente</code> que representa el Cliente * encontrado o null en caso contrario. Cliente obtenerclienteporid(integer idcliente) throws ServiceException; package ejpl.gestion.services; Ejemplo de implementación de un servicio import java.util.list; import atlas.core.exceptions.serviceexception; import org.springframework.dao.dataaccessexception; import org.springframework.stereotype.service; import ejpl.gestion.dao.clientedao; import ejpl.gestion.domain.cliente; 63 de 168

64 * Esta clase representa el servicio con la operaciones * asociadas a la entidad Cliente. ICM public class ClienteServiceImpl implements ClienteService { * El DAO de Clientes private ClienteDAO clientedao; * Constructor sin argumentos. public ClienteServiceImpl() { * Este metodo inyecta el dao ClienteDAO. * clientedao El DAO a inyectar. * public void setclientedao(clientedao clientedao) { this.clientedao = clientedao; * {@inheritdoc ejpl.gestion.services.clienteservice#insertcliente(ejpl.gestion.domain.cliente) public void insertcliente(cliente cliente) throws ServiceException { try { this.clientedao.insertcliente(cliente); catch (DataAccessException dae) { throw new ServiceException(dae); * {@inheritdoc * * ejpl.gestion.services.facade.gestionfacade#obtenerclienteporid(ejpl.gestion.domain.cliente) public Cliente obtenerclienteporid(integer idcliente) throws ServiceException { try { return this.clientedao.findbyid(idcliente); catch (DataAccessException dae) { throw new ServiceException(dae); 64 de 168

65 SNMVC La capa de negocio debe ser totalmente independiente de la capa de presentación, es decir nunca se accederá de manera directa desde los servicios de negocio a información de otras capas (por ejemplo, a la sesión Http). Toda la información requerida por los métodos de un servicio se le ha de pasar como parámetro. Hay que tener en cuenta que cualquier servicio de negocio puede ser transformado en un servicio web en un momento dado, y por tanto debe ser independiente. 65 de 168

66 6.3.3 INYECCION DE DEPENDENCIAS La fachada y los servicios se deben incluir en los ficheros de configuración de Spring. Para homogeneizar los desarrollos se establece que los ficheros de configuración de Spring se incluyan en la carpeta src/main/resources/conf. SNSpring Los ficheros de configuración de Spring se incluirán en la carpeta src/main/resources/conf. A continuación se muestra un ejemplo de ficheros de configuración tal y como los podemos encontrar dentro de alguno de los arquetipos. SNDependencias El fichero de configuración de Spring donde se definen los servicios y la fachada se debe llamar applicationcontext-services.xml. En el caso de que este fichero se haga muy grande se podría dividir en varios ficheros con la nomenclatura applicationcontext-services-yyyy.xml donde yyyy es un nombre que identifica a este fichero. No se permite instanciar objetos de fachadas o servicios directamente. Los servicios de Spring se pueden construir en base a 5 ámbitos distintos de creación según las propiedades que se le deseen otorgar, dicho ámbitos serían: Singleton Ambito Descripción Solo se creará una instancia del servicio, la cual será compartida por contenedor Spring. Éste será el ámbito por defecto que adoptará Spring cuando no se especifique ningún otro. 66 de 168

67 Prototype Request Session Global Session Este ámbito resulta en la creación de una nueva instancia del servicio cada vez que se realice una petición sobre el mismo. El ámbito del servicio es el mismo que el ciclo de vida de una petición HttpRequest. Solo tiene sentido en aplicaciones web. (No se puede utilizar) El ámbito del servicio es el mismo que el ciclo de vida de una sesión Http. Solo tiene sentido en aplicaciones web. (No se puede utilizar) El ámbito del servicio es el mismo que el ciclo de vida de una sesión Http Global (Ámbito de aplicación). Solo tiene sentido en aplicaciones web. (No se puede utilizar) SNAmbitos El ámbito de creación de los servicios en Spring debe ser Singleton, pudiendo crear servicios de ámbito Prototype única y exclusivamente en ciertos casos excepcionales, totalmente justificados y autorizados previamente por ICM. Completando lo anterior, los ámbitos de creación en Spring denominados request, session y global session no se pueden de utilizar bajo ninguna circunstancia. A continuación se muestra un ejemplo de fichero de configuración de Spring de los servicios y la fachada: applicationcontext-services.xml <?xml version="1.0" encoding="utf-8"?> <beans xmlns=" xmlns:xsi=" xmlns:p=" xmlns:context=" xmlns:tx=" xsi:schemalocation=" <!-- ============================================================= --> <!-- Definicion de todos los servicios de la aplicacion --> <!-- ============================================================= --> <bean id="facade" class="ejpl.gestion.services.facade.gestionfacadeimpl" p:clienteservice-ref="clienteservice"/> <!-- Aqui van los servicios propios del proyecto--> <bean id="clienteservice" class="ejpl.gestion.services.clienteserviceimpl" p:clientedao-ref="clientedao"/> </beans> 67 de 168

68 SNAgrupacion BUENA PRACTICA Para mejor organización de los servicios dentro del fichero de contexto de Spring se recomienda organizarlos por bloques funcionales. De forma que por cada bloque funcional se incluya en el fichero de configuración de Spring lo siguiente: o Comentario con el nombre del bloque funcional o Definición del bean de la fachada o Definición de los bean de los distintos servicios. Esto facilitará tanto el desarrollo como el posterior mantenimiento de la aplicación. 68 de 168

69 6.3.4 MANEJO DE EXCEPCIONES Uno de los problemas con el manejo de excepciones es saber cuándo y cómo utilizarlas. En términos generales, las aplicaciones desarrolladas con el framework Atlas tendrán que ser capaces de manejar dos tipos de excepciones: Excepciones de negocio: Serán aquellas excepciones creadas a medida por el desarrollador. Estas excepciones permiten representar aquellos errores inherentes al negocio. Serán lanzadas y gestionas por el propio programador, indicando así el incumplimiento de una regla del negocio. Excepciones del sistema: En este grupo se engloban todas aquellas excepciones producidas de forma automática por el entorno. Serán excepciones propietarias del API, como por ejemplo, un fallo en la conexión a una base de datos, fallo de invocación a un servicio web, etc. Dentro de Atlas para normalizar el uso de excepciones se ha creado la clase ServiceException. Con esta clase lo que se pretende es que todas las excepciones que se generen en la capa de negocio y se propaguen a la capa de presentación sean de tipo ServiceException. SNThrowsException Todos los métodos de los servicios y de la fachada sólo pueden lanzar excepciones del tipo ServiceException o clases que hereden de ella. Ejemplo de excepción devuelta por un método void deletecliente(cliente cliente) throws ServiceException; Si en nuestra aplicación queremos crear excepciones propias del negocio las podemos crear heredando de la clase ServiceExcepcion. SNCustomException Cuando se desee implementar una excepción propia del negocio, esto es a medida, se deberá extender de la clase ServiceException. El nombre de la excepción será <nombre>serviceexception y se ubicará en el paquete exceptions del bloque funcional correspondiente. package ejpl.gestion.exceptions; Ejemplo de excepción propia del negocio 69 de 168

70 public class InvalidAccountServiceException extends ServiceException { private static final long serialversionuid = L; public InvalidAccountServiceException() { super(); public InvalidAccountServiceException(String message) { super(message); BUENA PRACTICA SNExcComunes Las excepciones que puedan ser comunes a varios bloques funcionales se pueden ubicar en el paquete exceptions de un bloque funcional común. Estas excepciones podrán ser utilizadas desde los otros bloques funcionales. SNNegocioException Cuando se lance una excepción propia del negocio, se deberá atrapar en el momento de producirse para encapsularla en otra de tipo ServiceException. Ejemplo de relanzado de excepciones de negocio Public void reserveroom(integer customerid, String account, Date expdate) throws InvalidAccountServiceException, RoomAvailabilityServiceException { if (customermanager.setreserve(customerid, account, expdate).booleanvalue()) { Room room = hotelmanager.getfirstavailableroom(); if (room!= null) { LOG.debug("getFirstAvailableRoom(): " + room.getroomnumber()); Customer customer = customermanager.getcustomer(customerid); room.setreservestatus(room.ocuppied); room.setcustomer(customer);... else { throw new RoomAvailabilityServiceException(); else { throw new InvalidAccountServiceException(); 70 de 168

71 SNSystemException Cuando se lance una excepción que no sea del negocio, se deberá atrapar en el momento de producirse para encapsularla en otra de tipo ServiceException. Ejemplo de relanzado de excepciones de Sistema Public Boolean setreserve(integer customerid, String saccount, Date dexpireddate) throws ServiceException { Boolean reserve = false; try { reserve = webservice.checkaccount(customerid, saccount, dexpireddate); catch (AxisFault axisex) { throw new ServiceException(axisex); catch (JmsException jmsex) { throw new ServiceException(jmsex); return reserve; SNDAOException Los servicios que invoquen de forma directa a los componentes de la capa de acceso a datos (formada por Spring-DAOs), deberán atrapar y gestionar las excepciones del tipo DataAccessException que se lancen, con objeto de encapsularlas y relanzarlas como excepciones de tipo ServiceException, ya sea a la fachada u otros servicios de más alto nivel. La capa de acceso a datos no hará ningún de tratamiento de las excepciones producidas, simplemente se limitará a lanzarlas a la capa de negocio para que sea esta la encargada de manejarlas. Ejemplo de captura de excepciones de la capa de acceso a datos public void deletecliente(cliente cliente) throws ServiceException { try { this.clientedao.deletecliente(cliente); catch (DataAccessException dae) { throw new ServiceException(dae); 71 de 168

72 6.3.5 TRANSACCIONALIDAD Una de funcionalidades más importantes aportadas por el framework Spring es la gestión de la transaccionalidad proporcionando una capa de abstracción hacia el gestor transaccional utilizado, aportando los siguientes beneficios: Proporciona un modelo de programación consistente entre diferentes APIs transaccionales tales como JTA, JDBC, Hibernate, JPA y JDO. Soporte a gestión declarativa de transacción. Totalmente integrado con la abstracción de acceso a datos de Spring. Proporciona un API para la gestión programática de transacciones más sencilla que las habituales. Permite gestión de transacciones mediante anotaciones aplicadas a cualquier clase, y no a clases especiales como EJBs. Ofrece reglas de rollback mediante anotaciones, de forma que se puede configurar el rollback automático de una transacción en caso de producirse cierto tipo de excepción. Esta característica no existe en el modelo de EJB. Spring permite adaptar el comportamiento de las transacciones, mediante AOP, por ejemplo para insertar un comportamiento personalizado en rollback de transacciones. A diferencia del modelo de EJB CMT, el cual esta ligado a JTA, la transacción anotacional de Spring trabaja en cualquier entorno. El modelo declarativo de Spring se basa en el soporte de proxies AOP y metadatos (XML o anotaciones solo soportadas por entornos J2SE 5 o superiores). Esta combinación de proxies y metadatos permite tener proxies AOP que usan un TransactionInterceptor en conjunción con el PlatformTransactionManager apropiado y gestionar las transacciones en la ejecución de métodos. El modelo transaccional de Spring se puede resumir en la siguiente figura: 72 de 168

73 El modelo que se deberá seguir es el basado en anotaciones. En los servicios de Spring, se la cual posee un conjunto de atributos que permitirán definir las reglas y políticas para aplicar sobre métodos. En concreto, podremos tener uno o más parámetros como los siguientes: Propagation: Es utilizado para especificar los límites de una transacción. Gracias a esta característica tendremos bastantes opciones para especificar comportamiento si un método transaccional es ejecutado cuando un contexto transaccional ya existe: Por ejemplo, podríamos ejecutar algo en la transacción en ejecución; suspender la transacción ejecución y crear una nueva transacción, etc. El catálogo de atributos transaccionales disponibles para Spring es: Propagation PROPAGATION_REQUIRED PROPAGATION_REQUIRES_NEW PROPAGATION_SUPPORTS Descripción Se ejecuta en la actual transacción. Si no existe, se crea una nueva. Siempre se crear una transacción nueva. Si existe una transacción previa se suspende. Si existe una transacción se ejecuta en la misma transacción. Si no existe una transacción se ejecutará sin contexto transaccional. PROPAGATION_NOT_SUPPORTED Se ejecuta sin contexto transaccional. Si existe una transacción se detiene. PROPAGATION_MANDATORY PROPAGATION_NEVER PROPAGATION_NESTED Se ejecuta en la actual transacción. Si no existe una transacción previa, se produce una excepción. Se ejecuta sin contexto transaccional. Si existe una transacción previa se produce una excepción. Se ejecuta en una transacción anidada si existe una transacción previa. En caso contrario se comporta exactamente igual que REQUIRED. Se debe tener cuidado al utilizar este atributo transaccional, debido a q solo es soportado por algunos gestores de transacciones Isolation Level: Con este atributo podremos indicar el control de concurrencia. Cuando múltiples transacciones se están ejecutando en paralelo se pueden dar dirty reads, non repeateable reads y phantom reads. 73 de 168

74 El estándar ANSI/ISO SQL define cuatro niveles de aislamiento transaccional en función de tres hechos que deben ser tenidos en cuenta entre transacciones concurrentes. Estos hechos no deseados son: Dirty read (lecturas sucias): Una transacción lee datos escritos por una transacción no esperada y no cursada (no ha hecho todavía el commit). Non-repeateable read (lecturas no repetibles): Una transacción vuelve a leer datos que previamente había leído y encuentra que han sido modificados por una transacción cursada. Phantom read (lectura fantasma): Una transacción vuelve a ejecutar una consulta, devolviendo un conjuto de filas que satisfacen una condición de búsqueda y encuentra que otras filas que satisfacen la condición han sido insertadas por otra transacción cursada. Así, el framework Spring nos proporciona un conjunto de niveles de aislamiento que podremos usar en base a la tolerancia del sistema: Isolation level ISOLATION_DEFAULT ISOLATION_READ_UNCOMMITTED ISOLATION_READ_COMMITTED ISOLATION_REPEATABLE_READ ISOLATION_SERIALIZABLE Descripción Usa la política de aislamiento por defecto del sistema persistente. Permite leer datos incluso cuando existan filas sin commit, esto podría causar dirty read, non repeteable read o phantom reads. Previenen lecturas dirty pero todavía se pueden dar lecturas non-repeateable o lecturas phantom. Previene lecturas dirty y non-repeateable pero se pueden dar lecturas phantom. Este nivel consigue ACID (Atomicity, concurrancy, isolation and durability). Pero al ser tan estricto puede causar problemas de rendimiento Read Only: En algunas ocasiones hay un requerimiento que es solo leer datos de la base de datos, en dichos casos utilizar este atributo puede proporcionar un buen rendimiento ya que la base de datos aplicará algunas optimizaciones. Esto solo puede ser hecho cuando una nueva transacción es arrancada en operaciones de tipo select, así este atributo solo tomará sentido si la propiedad de propagación es PROPAGATION_REQUIRED, PROPAGATION_REQUIRES_NEW, o PROPAGATION_NESTED. 74 de 168

75 TimeOut: Se utiliza para prevenir deadlocks o recursos bloqueados en el sistema. Permite especificar un timeout que matará la transacción después del periodo especificado. Al igual que en el caso anterior este atributo solo tomará sentido si la propiedad de propagación es PROPAGATION_REQUIRED, PROPAGATION_REQUIRES_NEW, o PROPAGATION_NESTED. A continuación se muestra un ejemplo que muestra como se deben implementar las transacciones mediante anotaciones. El servicio que se desea hacer transaccional: Ejemplo de servicio transaccional // La implementación del servicio transaccional package = true, propagation = Propagation.SUPPORTS) public class RoomServiceImpl implements RoomService { public Room getroom(string roomname) { throw new ServiceException(); public Room getroom(string roomname, Integer idroom) { throw new = false, propagation = Propagation.REQUIRED) public void insertroom(room room) { throw new = false) public void updateroom(room room) { throw new ServiceException(); Según el ejemplo anterior se puede definir atributos transaccionales a nivel de clase, de esta manera modelamos el comportamiento transaccional que por defecto tendrá cada uno de los métodos de la misma. A partir de ahí, se podrá sobrescribir dicho comportamiento transaccional por defecto, utilizando la sobre el método que se desee modificar. Los métodos getroom se ejecutarán en un contexto de solo lectura con soporte a transacción, el método insertroom en un contexto de lecturaescritura con transacción requerida y el método updateroom en un contexto de lectura-escritura con soporte a transacción. 75 de 168

76 BUENA PRACTICA SNGenericTransaction Si bien es cierto que el manejo de transacciones dependerá del negocio, en la mayoría de los casos las transacciones se podrán configurar tal y como se han expuesto en el ejemplo anterior por lo que se recomienda utilizar esta configuración por defecto a la hora de gestionar transacciones en los servicios de negocio. La gestión de las transacciones siempre deberá realizarse a nivel de la capa de servicios, nunca a nivel de la capa DAO. Se recomienda gestionar transacciones en la fachada por ser el punto de control de la capa de servicios. Desde un punto vista de la configuración, lo primero que se debe hacer es indicar el gestor transaccional que se quiere utilizar, en el caso del framework Atlas lo configuramos para utilizar Hibernate como gestor transaccional. Esta configuración ya viene preconfigurada en los arquetipos en el fichero applicationcontext-database.xml y no se debe modificar. A continuación se muestra como se ha configurado el gestor de transacciones en los arquetipos: Configuración del gestor de transacciones en applicationcontext-database.xml <!-- ========= CONFIGURACION DEL TRANSACTION MANAGER ===================== --> <bean id="transactionmanager" class="org.springframework.orm.hibernate3.hibernatetransactionmanager" p:sessionfactory-ref="sessionfactory" p:entityinterceptor-ref="atlasinterceptor"/> <!-- ==== GESTION DE TRANSACCIONES MEDIANTE ANOTACIONES ============== --> <tx:annotation-driven transaction-manager="transactionmanager"/> SNTransactionAnnotated Para el manejo de transacciones se empleará el modelo de anotaciones propuesto por Spring. SNTransactionDefault No esta permitido modificar los atributos Isolation Level y TimeOut respecto a sus valores por defecto. En caso de tener que alterarlo solo se podrá hacer previa autorización por parte de ICM. 76 de 168

77 La manera más sencilla de indicar a Spring que una transacción necesita hacer rollback será lanzar una excepción desde el código que se está ejecutando dentro del contexto transaccional. Spring atrapará cualquier excepción no manejada y marcará la transacción para rollback. SNTransactionRollback Se utilizará el mecanismo de rollback de transacción basado en anotaciones. Esto se conseguirá mediante la y los atributos rollbackfor, rollbackforclassname, norollbackfor, norollbackforclassname. Esto solo tendrá sentido para las excepciones de negocio gestionadas en la capa de servicios ya que las excepciones de tipo DataAccessException a nivel de DAO o RuntimeException se traducirán en un rollback automático. Por ejemplo, el código necesario para realizar un rollback de una transacción cuando se lance una excepción de negocio de tipo NotRoomFoundServiceException podría ser algo como: Ejemplo de definición de = false, propagation = Propagation.REQUIRED, rollbackforclassname = {"NotRoomFoundServiceException"). 77 de 168

78 6.4 ACCESO A DATOS El acceso a datos es una de las partes con mayor índice de criticidad que pueda existir en cualquier aplicación web. Para el acceso a los distintos sistemas relacionales la tecnología seleccionada es Hibernate. A continuación se muestra un diagrama general de la capa de acceso a datos desde el punto de vista de arquitectura del sistema. POJO Services POJOs Capa de Acceso a Datos Fachada POJO Services POJOs SPRING Capa SPRING de Acceso a Datos HibernateDaoSupport SPRING HibernateDaoSupport DAO Hibernate SPRING Hibernate Template SPRING Hibernate HIBERNATE HIBERNATE BD (Oracle, etc) Template Arquitectura de la capa de Acceso a Datos Para el acceso a la información se utilizará la solución ORM (Object-Relational Mapping) de Hibernate, la cual se erige como un potente mapeador objeto/relacional y servicio de consultas para Java. Hibernate permite desarrollar clases persistentes a partir de clases comunes, incluyendo asociación, herencia, polimorfismo, composición y colecciones de objetos. El lenguaje de consultas de Hibernate HQL (Hibernate Query Language), diseñado como una mínima extensión orientada a objetos de SQL, proporciona un puente elegante entre los mundos de objetos y relacional. Hibernate también permite expresar consultas utilizando SQL nativo o consultas basadas en criterios. Soporta todos los sistemas gestores de bases de datos SQL y se integra de manera sencilla y sin restricciones con prácticamente la totalidad de servidores de aplicaciones JEE y contenedores web, además de poder utilizarse en aplicaciones standalone. Se pueden enumerar las siguientes características clave: o Persistencia transparente: Hibernate puede operar proporcionando persistencia de una manera transparente para el desarrollador. 78 de 168

79 o o o o o o o Modelo de programación natural: Hibernate soporta el paradigma de orientación a objetos de una manera natural: herencia, polimorfismo, composición y el framework de colecciones de Java. Soporte para modelos de objetos con una granularidad muy fina: Permite una gran variedad de mapeos para colecciones y objetos dependientes. Sin necesidad de mejorar el código compilado (bytecode): No es necesaria la generación de código ni el procesamiento del bytecode en el proceso de compilación. Escalabilidad extrema: Hibernate posee un alto rendimiento, tiene una caché de dos niveles y puede ser usado en un cluster. Permite inicialización perezosa (lazy) de objetos y colecciones. Lenguaje de consultas HQL: Este lenguaje proporciona una independencia del SQL de cada base de datos, tanto para el almacenamiento de objetos como para su recuperación. Soporte para transacciones de aplicación: Hibernate soporta transacciones largas (aquellas que requieren la interacción con el usuario durante su ejecución) y gestiona la política optimistic locking automáticamente. Generación automática de claves primarias: Soporta los diversos tipos de generación de identificadores que proporcionan los sistemas gestores de bases de datos (secuencias, columnas autoincrementales,...) así como generación independiente de la base de datos, incluyendo identificadores asignados por la aplicación o claves compuestas. ADHibernate La gestión de persistencia sobre los datos almacenados en bases de datos relacionales se realizará utilizando el motor de persistencia Hibernate. El mecanismo elegido para realizar el mapeo de clases java a tablas de la base de datos será el basado en anotaciones, dichas anotaciones proporcionarán a Hibernate la información suficiente para saber cómo cargar y almacenar clases persistentes y se marcarán a nivel de atributo. Se deberán utilizar aquellas anotaciones proporcionadas por Hibernate y que formen parte del estándar JPA. Las anotaciones no correspondientes a JPA y que proporciona Hibernate tienen por objetivo potenciar las capacidades de mismo apartándose del estándar, por lo que solo se podrán utilizar si se ha consensuado previamente con ICM. 79 de 168

80 6.4.1 Datasource y Sesiones de Hibernate Todas las aplicaciones definirán un datasource para conectarse con la base de datos. DAODatasource En los arquetipos ya viene configurado el datasource de acceso a base de datos. Deberá utilizarse dicho datasource y nunca obtener directamente las conexiones jdbc. El acceso al datasource siempre se realizará a través de la sesión de Hibernate. La sesión en Hibernate representa la interfaz entre la aplicación Java e Hibernate. Dicha sesión permitirá realizar operaciones de creación, modificación, lectura y eliminación de instaciones mapeadas con la base de datos. Históricamente, la gestión de sesiones en Hibernate se ha considerado uno de los problemas más comunes que se encuentran en aplicaciones Web, para evitar esto han surgido un conjunto de buenas prácticas y/o patrones que nos indican como trabajar de forma optima, en base al entorno de trabajo establecido. De tal forma para entornos Web el modelo recomendado siempre será el patrón session-perview (Sesión por vista). En una sesión por vista, la sesión de Hibernate se mantiene abierta mientras dura el ciclo de vida de una petición Http. DAOSession En las aplicaciones Web se deberá utilizar el patrón session-per-view, para ello Spring proporciona un filtro que se encargará de tratar toda la problemática asociada a la gestión de sesiones Hibernate en cada petición. Este filtro ya se encuentra definido en el fichero web.xml y no se puede modificar. DAOFlushing Se deberá usar el mecanismo de flushing por defecto en Hibernate sobre las sesiones, esto es el denominado FlushMode.AUTO. Este valor por defecto deberán ser válidos para cualquier entorno. Solo se podrá optar por otra estrategia, previo consenso con ICM. Se deberá usar el mecanismo de fetching por defecto en Hibernate, este es lazy select fetching para colecciones y lazy proxy fetching para asociaciones single-valued. Estos valores por defecto deberán ser válidos para cualquier entorno. Solo se podrá optar por otra estrategia, previo consenso con ICM. 80 de 168

81 6.4.2 Configuración A continuación se muestran los distintos ficheros donde se encuentra la configuración de la capa de acceso a datos enviroment.properties El fichero enviroment.properties contiene las variables que dependen del entorno por lo tanto aquí es donde se tiene que configurar el datasource. A continuación se muestra la configuración del datasource que viene configurada en los arquetipos. environment.properties ###################################################### # Fichero de variables de configuración específicas # # para el entorno LOCAL # ###################################################### # Configuracion para acceso a base de datos datasourcename=${artifactid-webds jdbc.driverclassname=oracle.jdbc.oracledriver jdbc.url=jdbc:oracle:thin:@icm21.icm.es:1521:denivel2 jdbc.username=dba_ejpl jdbc.password=sis hibernate.dialect=org.hibernate.dialect.oracle9idialect Para más información sobre el fichero de configuración environment.properties consultar el manual de arquetipos applicationcontext-database.xml Nota El fichero applicationcontext-database.xml que incorpora el arquetipo contiene la configuración de todos los parámetros de conexión a base de datos, incluyendo el sessionfactory y el transactionmanager. En este fichero solamente se puede modificar la propiedad packagestoscan para incorporar los paquetes donde residen las distintas clases de dominio que sea necesario crear (solo es necesario incluir los paquetes raíz, los subpaquetes serán escaneados automáticamente). <?xml version="1.0" encoding="utf-8"?> applicationcontext-database.xml <!-- ============================================================== --> <!-- En este fichero se configuran todos los --> <!-- parametros de conexion a la base de datos --> <!-- incluyendo el sessionfactory y el transactionmanager --> <!-- ============================================================== --> <beans xmlns=" 81 de 168

82 xmlns:xsi=" xmlns:p=" xmlns:context=" xmlns:tx=" xsi:schemalocation=" <!-- ========== CONFIGURACION DE CONEXIONES PARA ACCESO A DATOS ============ --> <!-- DataSource Definition --> <!-- via JNDI definido en el contenedor de aplicaciones (hay que habilitar la seccion correspondiente, al --> <!-- final del fichero./src/main/webapp/web-inf/web.xml) --> <!-- Se activa el datasource o no, dependiendo del entorno --> <!-- ${enablefordevelopment1 <bean id="datasource" class="org.springframework.jndi.jndiobjectfactorybean"> <property name="jndiname" value="jdbc/${datasourcename" /> </bean> ${enablefordevelopment2 --> <!-- via Spring, esta opcion permite el uso de Jetty (mvn jetty:run) que facilita un desarrollo rapido --> <!-- ${enablefordevelopment3 <bean id="datasource" class="org.springframework.jdbc.datasource.drivermanagerdatasource"> <property name="driverclassname" value="${jdbc.driverclassname"/> <property name="url" value="${jdbc.url"/> <property name="username" value="${jdbc.username"/> <property name="password" value="${jdbc.password"/> </bean> ${enablefordevelopment4 --> <!-- ==== CONFIGURACION DEL SESSIONFACTORY DE HIBERNATE =================== --> <bean id="sessionfactory" class="org.springframework.orm.hibernate3.annotation.annotationsessionfactorybean"> <description> Bean que representa a la factoria de hibernate para crear sesiones con base de datos </description> <!-- Descomentar para auditoria <property name="configurationclass"> <value>atlas.audit.hibernate.cfg.annotationconfiguration</value> </property> --> <property name="schemaupdate"> <value>false</value> </property> <property name="packagestoscan"> <list> 82 de 168

83 <!-- ======== INCLUIR AQUI TODOS LOS PAQUETES DE CLASES ANOTADAS ===== --> <value>ejpl.gestion.domain</value> <!-- Necesario si se quiere utilizar el componente de calendario --> <value>atlas.componentes.domain</value> </list> </property> <property name="hibernateproperties"> <props> <prop key="hibernate.dialect">${hibernate.dialect</prop> <prop key="hibernate.show_sql">false</prop> <prop key="hibernate.format_sql">false</prop> <prop key="hibernate.use_sql_comments">false</prop> <!-- Descomentar para auditoria <prop key="atlas.audit.triggers">false</prop> <prop key="atlas.audit.console_output">false</prop> --> </props> </property> <property name="datasource" ref="datasource" /> </bean> <!-- ==== CONFIGURACION DEL TRANSACTION MANAGER =========================== --> <bean id="transactionmanager" class="org.springframework.orm.hibernate3.hibernatetransactionmanager" p:sessionfactory-ref="sessionfactory" p:entityinterceptorref="atlasinterceptor"/> <!-- ========== GESTION DE TRANSACCIONES MEDIANTE ANOTACIONES ============= --> <tx:annotation-driven transaction-manager="transactionmanager"/> <!-- ======== TRADUCTOR DE EXCEPCIONES DE SPRING ======================= --> <bean id="jdbcexceptiontranslator" class="org.springframework.jdbc.support.sqlerrorcodesqlexceptiontranslator"> <description> Bean que representa al traductor de codigos de error SQL a excepciones JAVA </description> <property name="datasource"> <ref bean="datasource" /> </property> </bean> <!-- ========DEFINICION DE HIBERNATETEMPLATE CON PROPIEDADES =============== --> <bean id="hibernatetemplate" class="org.springframework.orm.hibernate3.hibernatetemplate"> <description> Bean que representa la plantilla de hibernate. A este bean se le inyectan la factoria de sesiones y el traductor de sesiones JDBC </description> <property name="sessionfactory"> <ref bean="sessionfactory" /> </property> <property name="jdbcexceptiontranslator"> <ref bean="jdbcexceptiontranslator" /> </property> </bean> <!-- === DEFINICION DE BEAN auditconstants NECESARIO PARA AUDITORIA ======== --> <!-- Descomentar para auditoria 83 de 168

84 <bean id="auditconstants" class="atlas.audit.properties.auditconstants"> <property name="codaplicacion" value="ejpl"/> <property name="cdtpaccesologico" value="i"/> </bean> --> </beans> applicationcontext-dao.xml El fichero applicationcontext-dao.xml contiene la definición de los bean de los distintos DAOs en el contexto de Spring. <?xml version="1.0" encoding="utf-8"?> applicationcontext-dao.xml <beans xmlns=" xmlns:xsi=" xmlns:p=" xmlns:context=" xmlns:tx=" xsi:schemalocation=" <!-- ============================================================ --> <!-- Definicion de todos los DAO`s de la aplicacion --> <!-- ============================================================ --> <bean id="clientedao" class="ejpl.gestion.dao.clientedaoimpl" p:sessionfactory-ref="sessionfactory"/> </beans> El ámbito de creación de los DAOs será siempre el que adopta Spring por defecto, es decir Singleton. (por defecto si no se indica en el fichero de configuración) DAODependencias El fichero de configuración de Spring donde se definen los daos se debe llamar applicationcontext-dao.xml. En el caso de que este fichero se haga muy grande se podría dividir en varios ficheros con la nomenclatura applicationcontext-dao-yyyy.xml donde yyyy es un nombre que identifica a este fichero. No se permite instanciar objetos de daos directamente. 84 de 168

85 6.4.3 Entidades de dominio Las entidades de dominio son las clases Java que tienen una correspondencia con tablas del modelo de datos relacional. ADEntityImpl Las clases de dominio se incluirán en el paquete domain del bloque funcional correspondiente. No tendrán una nomenclatura específica ya que su nombre debe representar al objeto de dominio que implemente. Las clases de dominio deben: o Incluir la o o o Implementar la interface Serializable. Incluir atributos privados y sus correspondientes setter y getter Incluir un constructor sin argumentos o Implementar los métodos equals y hashcode para las entidades persistentes, ya que dichos métodos se harán indispensables en casos como: o o o Se necesitan almacenar instancias en un conjunto (Asociaciones 1-n). Se quieren utilizar las instancias como keys para un map. Se quieren usar métodos de colecciones como contains(), remove(), etc Atención Los métodos equal y hashcode se pueden generar desde Eclipse si pulsamos dentro del codigo de la clase el botón derecho del ratón y seleccionamos Source/Generate hashcode() and equals() method y si no se tiene otro requisito se deberían generar para todos los atributos. ADRendimiento. BUENA PRACTICA Hibernate puede ser una herramienta muy potente pero a su vez su utilización sin tener en cuenta la forma en la que trabaja Hibernate puede provocar problemas de rendimiento. Se debe evitar que el acceso a determinados datos suponga la carga en memoria de estructuras complejas o de demasiada información que en la mayoría de los casos no se va a necesitar. 85 de 168

86 A continuación se muestra un fragmento de la clase denominada Cliente, la cual representa una entidad persistente gestionada por el motor de Hibernate: package ejpl.gestion.domain; Cliente.java import java.util.date; import javax.persistence.column; import javax.persistence.entity; import javax.persistence.generationtype; import javax.persistence.id; import javax.persistence.joincolumn; import javax.persistence.manytoone; import javax.persistence.sequencegenerator; import javax.persistence.table; import javax.persistence.temporal; import javax.persistence.temporaltype; import javax.persistence.generatedvalue; * Cliente ICM 1.0. = "EJPL_CLIENTES") public class Cliente implements java.io.serializable { * Identificador del numero de serie para serializacion private static final long serialversionuid = 1L; * Representa el identificador/pk del cliente. private Integer idcliente; * Representa el nombre del cliente. private String nombre; * Representa el primer apellido del cliente. private String apellido1; * Representa el segundo apellido del cliente. private String apellido2; * Representa la direccion del cliente. 86 de 168

87 private String direccion; * Representa el telefono del cliente. private String telefono; * Representa la fecha de nacimiento del cliente. private Date fcnacimiento; * Representa el estado civil del cliente. private EstadoCivil estadocivil; * Constructor sin argumentos. public Cliente() { * Constructor para la entidad Cliente con los parametros minimos. idcliente Identificador nombre Nombre apellido1 Primer Apellido apellido2 Segundo Apelillido public Cliente(Integer idcliente, String nombre, String apellido1, String apellido2) { this.idcliente = idcliente; this.nombre = nombre; this.apellido1 = apellido1; this.apellido2 = apellido2; * Constructor para la entidad Cliente con los todos parametros posibles. idcliente Identificador nombre Nombre apellido1 Primer Apellido apellido2 Segundo Apelillido direccion Direccion telefono Telefono fcnacimiento Fecha de Nacimiento estadocivil Estado Civil public Cliente(Integer idcliente, String nombre, String apellido1, String apellido2, String direccion, String telefono, Date fcnacimiento, EstadoCivil estadocivil) { this.idcliente = idcliente; this.nombre = nombre; this.apellido1 = apellido1; this.apellido2 = apellido2; this.direccion = direccion; this.telefono = telefono; this.fcnacimiento = fcnacimiento; this.estadocivil = estadocivil; 87 de 168

88 <code>java.lang.integer</code> Devuelve el identificador/pk de la = GenerationType.AUTO, generator = = "EJPL_SECUENCIA_ID_CLIENTE", sequencename = = "ID_CLIENTE", unique = true, nullable = false, precision = 9, scale = 0) public Integer getidcliente() { return this.idcliente; idcliente Modifica el identificador/pk del cliente. public void setidcliente(integer idcliente) { this.idcliente = idcliente; <code>java.lang.string</code> Devuelve el nombre del = "NOMBRE", nullable = false, length = 50) public String getnombre() { return this.nombre; nombre Modifica el nombre del cliente. public void setnombre(string nombre) { this.nombre = nombre; <code>java.lang.string</code> Devuelve el primer apellido del = "APELLIDO1", nullable = false, length = 50) public String getapellido1() { return this.apellido1; apellido1 Modifica el primer apellido del cliente. public void setapellido1(string apellido1) { this.apellido1 = apellido1; <code>java.lang.string</code> Devuelve el segundo apellido del = "APELLIDO2", nullable = false, length = 50) public String getapellido2() { return this.apellido2; 88 de 168

89 apellido2 Modifica el segundo apellido del cliente. public void setapellido2(string apellido2) { this.apellido2 = apellido2; <code>java.lang.string</code> Devuelve la direccion del = "DIRECCION", length = 100) public String getdireccion() { return this.direccion; direccion Modifica la direccion del cliente. public void setdireccion(string direccion) { this.direccion = direccion; <code>java.lang.string</code> Devuelve el telefono del = "TELEFONO", length = 15) public String gettelefono() { return this.telefono; telefono Modifica el telefono del cliente. public void settelefono(string telefono) { this.telefono = telefono; <code>java.lang.string</code> Devuelve el estado civil = "FK_ESTADO_CIVIL") public EstadoCivil getestadocivil() { return this.estadocivil; estadocivil Modifica el estado civil del cliente. public void setestadocivil(estadocivil estadocivil) { this.estadocivil = estadocivil; <code>java.util.date</code> Devuelve la fecha de nacimiento del 89 de 168

90 @Column(name = "FC_NACIMIENTO", length = 7) public Date getfcnacimiento() { return this.fcnacimiento; fcnacimiento Modifica la fecha de nacimiento del cliente. public void setfcnacimiento(date fcnacimiento) { this.fcnacimiento = fcnacimiento; /* (non-javadoc) public int hashcode() { final int prime = 31; int result = 1; result = prime * result + ((apellido1 == null)? 0 : apellido1.hashcode()); result = prime * result + ((apellido2 == null)? 0 : apellido2.hashcode()); result = prime * result + ((direccion == null)? 0 : direccion.hashcode()); result = prime * result + ((estadocivil == null)? 0 : estadocivil.hashcode()); result = prime * result + ((fcnacimiento == null)? 0 : fcnacimiento.hashcode()); result = prime * result + ((idcliente == null)? 0 : idcliente.hashcode()); result = prime * result + ((nombre == null)? 0 : nombre.hashcode()); result = prime * result + ((telefono == null)? 0 : telefono.hashcode()); return result; /* (non-javadoc) public boolean equals(object obj) { if (this = = obj) { return true; if (obj == null ) { return false; if (getclass()!= obj.getclass()) { return false; Cliente other = (Cliente) obj; if (apellido1 == null) { if (other.apellido1!= null) { return false; else if (!apellido1.equals(other.apellido1)) { return false; if (apellido2 == null) { if (other.apellido2!= null) { 90 de 168

91 return false; else if (!apellido2.equals(other.apellido2)) { return false; if (direccion == null) { if (other.direccion!= null) { return false; else if (!direccion.equals(other.direccion)) { return false; if (estadocivil == null) { if (other.estadocivil!= null) { return false; else if (!estadocivil.equals(other.estadocivil)) { return false; if (fcnacimiento == null) { if (other.fcnacimiento!= null) { return false; else if (!fcnacimiento.equals(other.fcnacimiento)) { return false; if (idcliente == null) { if (other.idcliente!= null) { return false; else if (!idcliente.equals(other.idcliente)) { return false; if ( nombre == null) { if (other.nombre!= null) { return false; else if (!nombre.equals(other.nombre)) { return false; if (telefono == null) { if (other.telefono!= null) { return false; else if (!telefono.equals(other.telefono)) { return false; return true; Es recomendable que el índice de granularidad de las entidades persistentes sea el adecuado, intentando representar de forma estricta las entidades de negocio. 91 de 168

92 Mapeo relacional Las clases de dominio se mapearán mediante las correspondientes anotaciones de Hibernate. A continuación se muestra una tabla con algunas de las anotaciones de Hibernate más utilizadas. Aunque aquí solamente se muestran las más utilizadas se podrán utilizar todas las anotaciones proporcionadas por Hibernate que cumplen con el @Column Indica la tabla con la que se va a mapear Indica que este campo es identificador de la tabla Indica que este campo va a ser generado automáticamente Indica la secuencia a utilizar para este campo Indica el campo con el que se va a mapear este atributo ADMapeoTabla Cada clase de dominio será mapeada a una tabla de la base de datos, esto se hará con la Ejemplo de mapeo = "EJPL_CLIENTES") public class Cliente implements java.io.serializable { Nota No hay que olvidarse de que cada clase de domino anotada se debe incluir en el fichero de configuración applicationcontext-database.xml. ADIdentificador Todas las entidades persistentes deberán tener un atributo a modo de identificador único que permita distinguir un objeto de otro de forma unívoca. Este atributo será de tipo Integer y estará obligatoriamente generado por una secuencia. En el caso de que el modelo de datos ya exista en producción y no sea posible cumplir esta norma se solicitará una autorización excepcional a ICM. Este atributo se anotará con la Al margen de este atributo se podrán crear otros identificadores únicos propios de la gestión funcional de la tabla que no serán anotados 92 de 168

93 Ejemplo de = GenerationType.AUTO, generator = = "EJPL_SECUENCIA_ID_CLIENTE", sequencename = = "ID_CLIENTE", unique = true, nullable = false, precision = 9, scale = 0) public Integer getidcliente() { return this.idcliente; ADRelaciones No se permite el uso de relaciones muchos-a-muchos. Se deberán sustituir, siempre que sea posible, por relaciones uno-a-muchos y/o muchos-a-uno. En caso de no poder hacer dicha sustitución, se deberá consultar a ICM el uso de la posible relación muchos-a-muchos. ADDinamicos No se permite el uso de modelos dinámicos de Hibernate como sustitutivo de las entidades POJOs de persistencia. 93 de 168

94 Tipos de datos BLOB y CLOB (LOB) Los tipos de datos BLOB y CLOB hacen referencia a aquellos elementos utilizados en una bases de datos para almacenar entidades de gran tamaño que puedan cambiar de forma dinámica, estando los primeros enfocados a datos binarios (por ejemplo una imagen) y los segundos a datos de tipo carácter (por ejemplo un párrafo de texto con un tamaño considerable). ADLob Cuando surja la necesidad de gestionar y almacenar campos de tipo LOB, se deberán de almacenar en tablas pensadas a tal efecto, que básicamente contendrán el campo BLOB/CLOB con la información y una referencia a modo de clave ajena hacia otra tabla. En el caso de que el modelo de datos ya exista en producción y no sea posible cumplir esta norma se solicitará una autorización excepcional a ICM. Esto solo tendrá sentido en aquellos casos donde podamos establecer el modelo de datos desde un principio y sin restricciones, ya que en muchos casos tendremos modelos impuestos o heredados donde donde no se pueda aplicar la recomendación. ADLobAnot Los atributos de tipo Lob se anotarán con la y se le indicará que se traiga bajo demanda con la Ejemplo de definición de campo LOB * Devuelve el contenido del ficherote un = public Blob getcontenido() { return contenido; 94 de 168

95 6.4.4 Data Access Objects En una arquitectura Java Enterprise Edition (JEE) es fundamental contar con un elemento propio de acceso a datos que permita a las aplicaciones obtener y manipular los datos de la organización de una manera estandarizada y óptima que ofrezca a los desarrolladores una interfaz sencilla y homogénea que facilite los desarrollos aumentando la productividad y mejorando los tiempos de mantenimiento, a la vez que ofrezca unas elevadas prestaciones de rendimiento en tiempo de ejecución. El patrón DAO es uno de los patrones de diseño estándar de JEE. DAO permite encapsular el acceso y manipulación de datos en una capa separada. Esta capa gestiona la conexión con la fuente de datos (bases de datos relacionales, ficheros planos, sistema de ficheros remotos, etc.) para obtener y almacenar dichos datos, ya que implementa el mecanismo de acceso necesario. Independientemente del tipo de fuente de datos empleada, la capa DAO siempre proporciona un API uniforme a sus clientes, ocultando los detalles de implementación. La capa DAO se implementa sin estado. No almacena en caché resultados de ninguna consulta, ni datos que el cliente pueda necesitar posteriormente. Esto provoca que los objetos DAO sean simples y evita problemas potenciales de concurrencia Diagrama de clases (extraído de Core J2EE Patterns, Best Practices and Design Strategies por Deepak Alur, John Crupi y Dan Malks): Spring proporciona un mecanismo adicional que permite integrar herramientas ORM en objetos DAO de una forma mucho más sencilla, haciendo uso del componente Spring DAO. Los DAOs pueden ser configurados a través de la inyección de dependencias así como participar de los recursos y la gestión automática de transacciones que aporta Spring. La norma habitual en los desarrollos será hacer uso de Hibernate Spring DAO, proporcionando funcionalidades adicionales que harán más sencillo el uso de Hibernate. Las ventajas obtenidas al hacer uso de Spring DAO con Hibernate: Fácil de testear: La aproximación de inyección de dependencias aportada por Spring hace sencillo cambiar implementaciones y configurar la localización de instancias del objeto SessionFactory de 95 de 168

96 Hibernate, recursos JDBC, gestores de transacciones, etc. Esto hace sencillo aislar y testear cada pieza relacionada con la persistencia de forma independiente. Acceso común a excepciones: Spring puede mapear las excepciones producidas por la Hibernate, convirtiéndolas de propietarias a una jerarquía común de manejo de excepciones DataAccessException, permitiendo manejar excepciones no recuperables solo en las capas apropiadas. Gestión general de recursos: Spring maneja de forma automática la localización y configuración de instancias SessionFactory, Datasources, etc., por lo que Spring ofrece una manera sencilla y segura de poder acceder a los recursos. Por ejemplo, generalmente Hibernate necesita utilizar la misma sesión para hacer un manejo eficiente de las transacciones, Spring de forma transparente crea y enlaza sesiones al actual hilo de ejecución, etc. ADHibernateDAOImpl En cada bloque funcional de una aplicación se han de crear los DAOs que darán cobertura a los accesos a la base de datos. Para crear un DAO se crearán dos clases, con la siguiente nomenclatura: o <nombre>dao (Interfaz del DAO) o <nombre>daoimpl (Implementación del DAO) Donde <nombre> debe ser sustituido por el nombre del DAO. Estas clases se incluirán en el paquete dao del bloque funcional correspondiente. Las clases de implementación deben heredar de la clase HibernateDaoSupport, de esta forma se utiliza el modelo de DAO s proporcionado por Spring. package ejpl.gestion.dao; Ejemplo de Interface de DAO import java.util.list; import ejpl.gestion.domain.cliente; * Esta interfaz representa todas la operaciones de manipulacion * de datos asociadas a la entidad Cliente. ICM 1.0. public interface ClienteDAO { * Este metodo permite insertar un cliente. * 96 de 168

97 cliente Cliente a insertar. void insertcliente(cliente cliente); * Este metodo permite modificar un cliente. * cliente Cliente a modificar. void updatecliente(cliente cliente); * Este metodo permite añadir o modificar un cliente. * cliente Cliente a insertar/modificar. void insertorupdatecliente(cliente cliente); * Este metodo permite eliminar un cliente. * cliente Cliente a eliminar. void deletecliente(cliente cliente); * Este metodo recupera todos los clientes del sistema. * index Indice de paginacion actual. pagesize Tamaño de pagina. order Criterio de ordenacion. filter Filtro de busqueda. * <code>java.util.list</code> objecto que representa la lista de clientes. List<Cliente> findclientes(int index, int pagesize, Object order, Object filter); * Este metodo obtiene el numero total de clientes del sistema. * filter Filtro de busqueda. * <code>int</code> con el numero total de cliente encontrados. int findclientestotal(object filter); * Este metodo obtiene un Cliente a partir de la PK. * idcliente PK del cliente. * <code>ejpl.gestion.domain.cliente</code> que representa el Cliente * encontrado o null en caso contrario. Cliente findbyid(integer idcliente); 97 de 168

98 package ejpl.gestion.dao; Ejemplo de implementación de DAO import java.util.list; import org.hibernate.query; import org.springframework.orm.hibernate3.support.hibernatedaosupport; import org.springframework.stereotype.repository; import org.springframework.transaction.annotation.propagation; import org.springframework.transaction.annotation.transactional; import ejpl.gestion.domain.cliente; * Esta clase representa el DAO con todas la operaciones de manipulacion de * datos asociadas a la entidad Cliente. * ICM 1.0. = true, propagation = Propagation.SUPPORTS) public class ClienteDAOImpl extends HibernateDaoSupport implements ClienteDAO { * {@inheritdoc * cliente El cliente ejpl.gestion.dao.clientedao#insertcliente(ejpl.gestion.domain = false) public void insertcliente(cliente cliente) { this.gethibernatetemplate().save(cliente); * {@inheritdoc * ejpl.gestion.dao.clientedao#updatecliente(ejpl.gestion.domain = false) public void updatecliente(cliente cliente) { this.gethibernatetemplate().update(cliente); * {@inheritdoc * * ejpl.gestion.dao.clientedao#insertorupdatecliente(ejpl.gestion.domain = false) public void insertorupdatecliente(cliente cliente) { this.gethibernatetemplate().saveorupdate(cliente); 98 de 168

99 * * ejpl.gestion.dao.clientedao#deletecliente (ejpl.gestion.domain = false) public void deletecliente(cliente cliente) { this.gethibernatetemplate().delete(cliente); * {@inheritdoc * ejpl.gestion.dao.clientedao#findbyid(java.lang.integer) public Cliente findbyid(integer idcliente) { return (Cliente) gethibernatetemplate().get( "ejpl.gestion.domain.cliente", idcliente); * {@inheritdoc * ejpl.gestion.dao.clientedao#findclientes(int, int, java.lang.object, * public List<Cliente> findclientes(int index, int pagesize, Object order, Object filter) { StringBuffer query = new StringBuffer("from ejpl.gestion.domain.cliente cli "); // Concatena la cláusula where al filtro si es necesario String strfiltro = (filter == null)? null : filter.tostring(); if (strfiltro!= null &&!strfiltro.equals("")) { query.append(" where cli.nombre like :filtro "); // Concatena la cláusula order al filtro si es necesario String tmp = (order == null)? null : order.tostring(); if (tmp!= null &&!tmp.equals("")) { query.append(" order by cli.").append(tmp); // Selecciona el parámetro del filtro si es necesario Query tmpquery = gethibernatetemplate().getsessionfactory(). getcurrentsession().createquery(query.tostring()); if (strfiltro!= null &&!strfiltro.equals("")) { tmpquery.setstring("filtro", "%" + strfiltro + "%"); // Ejecuta la query return tmpquery.setfirstresult(index).setmaxresults(pagesize).list(); * {@inheritdoc 99 de 168

100 * ejpl.gestion.dao.clientedao#findclientestotal(java.lang.object) public int findclientestotal(object filter) { StringBuffer query = new StringBuffer( "select count(cli) from ejpl.gestion.domain.cliente cli "); // Concatena la cláusula where al filtro si es necesario String strfiltro = (filter == null)? null : filter.tostring(); if (strfiltro!= null &&!strfiltro.equals("")) { query.append(" where cli.nombre like :filtro "); // Selecciona el parámetro del filtro si es necesario Query tmpquery = gethibernatetemplate().getsessionfactory(). getcurrentsession().createquery(query.tostring()); if (strfiltro!= null &&!strfiltro.equals("")) { tmpquery.setstring("filtro", "%" + strfiltro + "%"); // Ejecuta la query return ((Long) tmpquery.uniqueresult()).intvalue(); ADDAOAnotacion Las clases de implementación de DAO tienen que tener la (No incluir la anotación en las interfaces) 100 de 168

101 class dao «interface» ClienteDAO + deletecliente(cliente) : void + findbyid(integer) : Cliente + findclientes(int, int, Object, Object) : List<Cliente> + findclientestotal(object) : int + insertcliente(cliente) : void + insertorupdatecliente(cliente) : void + updatecliente(cliente) : void ClienteDAOImpl HibernateDaoSupport + deletecliente(cliente) : void + findbyid(integer) : Cliente + findclientes(int, int, Object, Object) : List<Cliente> + findclientestotal(object) : int + insertcliente(cliente) : void + insertorupdatecliente(cliente) : void + updatecliente(cliente) : void domain::cliente - apellido1: String - apellido2: String - direccion: String - estadocivil: EstadoCivil - fcnacimiento: Date - idcliente: Integer - nombre: String - serialversionuid: long = 1L {readonly - telefono: String java.io.serializable + Cliente() + Cliente(Integer, String, String, String) + Cliente(Integer, String, String, String, String, String, Date, EstadoCivil) + equals(object) : boolean + getapellido1() : String + getapellido2() : String + getdireccion() : String + getestadocivil() : EstadoCivil + getfcnacimiento() : Date + getidcliente() : Integer + getnombre() : String + gettelefono() : String + hashcode() : int + setapellido1(string) : void + setapellido2(string) : void + setdireccion(string) : void + setestadocivil(estadocivil) : void + setfcnacimiento(date) : void + setidcliente(integer) : void + setnombre(string) : void + settelefono(string) : void ADDAOHibernateTemplate Todas las operaciones sobre la base de datos como insert, delete, select (equivalente a find en Hibernate), etc se deben realizar a través de la clase HibernateTemplate proporcionada por Spring, evitando el uso directo de la sesión de Hibernate. Ejemplo de uso de HibernateTemplate * {@inheritdoc * cliente El cliente ejpl.gestion.dao.clientedao#insertcliente(ejpl.gestion.domain = false) public void insertcliente(cliente cliente) { this.gethibernatetemplate().save(cliente); 101 de 168

102 ADDAONomenclatura Cuando los DAOs tengan operaciones de modificacion o alteración de datos seguirán la siguiente nomenclatura: o o Inserción: insertxxx, donde XXX será un nombre autodescriptivo, generalmente el nombre del objeto de domino. Actualización: updatexxx, donde XXX será un nombre autodescriptivo, generalmente el nombre del objeto de domino. o o Eliminación: deletexxx, donde XXX será un nombre autodescriptivo, generalmente el nombre del objeto de domino. Consultas: findxxx, donde XXX será un nombre autodescriptivo sobre la consulta a realizar. ADHQL BUENA PRACTICA Se deberá utilizar en la medida de lo posible el lenguaje de acceso a datos HQL, por ser un lenguaje más enfocado a objetos que el propio SQL. Aún así se podrá extender este modelo haciendo uso del lenguaje SQL siempre y cuando sea necesario. Esto será necesario en casos de querer usar querys SQL no ANSI-Estándar, querys que por su complejidad sea más adecuado SQL en lugar del mapeo objeto-relacional, operaciones de larga duración del tipo batch, streaming de BLOBs, operaciones de tipo select complejas, etc. ADSQL En el caso de utilizar SQL se implementará mediante los mecanimos que proporciona Hibernate para la ejecución de queries SQL nativas. (createsqlquery) Ejemplo de uso de SQL public List getquerydata(){ SQLQuery query= gethibernatetemplate().getsessionfactory(). getcurrentsession().createsqlquery(sql); query.setresulttransformer(transformers.alias_to_entity_map); return query.list(); Nota Los daos se deben inyectar en el contexto de Spring en el fichero applicationcontext-database.xml 102 de 168

103 ADSQLUso En el caso de utilizar SQL se deberan tener en cuenta las siguientes restricciones: No se podrán utilizar sentencias SQL-DML ni SQL-DDL desde el código ni utilizar los mecanismos de Hibernate que permitan realizar ese tipo de operaciones desde el código. No se deben utilizar las sentencias SELECT * en su lugar se incluirán los nombre de los campos que en realidad se van a consultar. En el caso de utilizar una sentencia SELECT FOR UPDATE se hará con la clausula NO WAIT. ADCatalogos No se permiten realizar actualizaciones en tablas de catálogos generales (SUCA, CATA, etc) ADRemoto El acceso a tablas remotas se debe hacer mediante sinónimos remotos y no por database link Manejo de excepciones Un DAO deberá esforzarse en aislar el manejo de excepciones gracias a Spring, por lo que solo podrá lanzar DataAccessException, de manera que el tratamiento de las excepciones que se pudiesen provocar a este nivel seria gestionadas en capas superiores (capa de negocio). Esto se justifica ya que por ejemplo carece de sentido lanzar java.lang.exception, ya que es demasiado genérica y no transmite ninguna información acerca de la raíz del problema. Tampoco tendrá sentido lanzar excepciones de tipo java.sql.sqlexception, ya que es una excepción JDBC de bajo nivel. DAOExcepciones Todos los métodos de los DAOs sólo podrán lanzar excepciones de tipo DataAccessException. 103 de 168

104 Transaccionalidad El uso del modelo de anotaciones que propone Spring permite gestionar de forma automática y sencilla la semántica transaccional, esto se pronuncia en un código portable con respecto al gestor transaccional utilizado, por ejemplo se podría alterar el uso del gestor transaccional de Hibernate por el de otro sistema de persistencia que soporte el estándar JTA. ADTransaccion La gestión de las transacciones se hará mediante anotaciones. Los DAOs tendrán por defecto todos los métodos como de lectura y propagación supports, esto se definirá con una a nivel de clase. (@Transactional(readOnly = true, propagation = Propagation.SUPPORTS) Los método de los DAOs que alteren datos (insert, update, delete) modificarán el comportamiento por defecto, mediante el atributo readonly=false. (@Transactional(readOnly = false)) De forma excepcional, se permite modificar el comportamiento por defecto de un método con respecto al atributo propagación Propagation.SUPPORTS por uno de tipo Propagation.REQUIRES_NEW. El uso de cualquier atributo de propagación que no sea Propagation.SUPPORTS o Propagation.REQUIRES_NEW deberá de justificarse y consesuarse con ICM. En el ejemplo de implementación de un DAO que podemos ver mas arriba podemos observar el uso de las anotaciones tal y como se indica en la norma. Aunque se comentó en la sección de servicios, recalcar que serán las capas superiores (servicios) la encargadas de gestionar el contexto transaccional y no la capa de acceso a datos, por lo que los DAOs se limitarán a ejecutar un método en un contexto transaccional (si al invocar dicho método el contexto ya está creado), o a ejecutar el método sin transacción (en caso de invocar al DAO sin un contexto transaccional). Esto se cumplirá en la mayoría de los casos, ya que al permitir (eventualmente) Propagation.REQUIRES_NEW, se permite que el propio DAO cree un contexto transaccional solo para la ejecución de un método concreto. 104 de 168

105 ADRollback Un DAO no puede gestionar rollback de transacción, es decir, se prohíbe el uso de o o rollbackfor = xxxexception.class, rollbackforclassname = {"xxxexception", o norollbackfor = xxxexception.class, o norollbackforclassname = {"xxxexception". Cuando los DAOs generen un error de tipo DataAccessException o RuntimeException se traducirá en un rollback automático. Según se comenta en el apartado de servicios de negocio, los atributos rollbackfor, rollbackforclassname, norollbackfor y norollbackforclassname solo tendrán sentido en la capa de servicios con objeto de poder realizar rollback para las excepciones de negocio. 105 de 168

106 6.4.5 Llamada a Procedimientos Almacenados desde Hibernate La llamada a procedimientos almacenados de Oracle desde Hibernate se puede realizar utilizando Named Queries según se muestra en el ejemplo de este apartado. ADStoredProc La llamada a procedimientos almacenados de Oracle desde Hibernate se realizará utilizando Named Queries, y no accediendo directamente a la conexión JDBC. A continuación se muestra un ejemplo de procedimiento almacenado que devuelve un cliente (el ejemplo puede implementarse en un arquetipo recien creado). 1) Creación de procedimiento almacenado: Ejemplo de procedimiento almacenado create or replace procedure EJPL_PROC_BUSCAR_POR_ID ( z_resultado out SYS_REFCURSOR, w_id IN integer) is begin OPEN z_resultado FOR SELECT ID_CLIENTE,NOMBRE,APELLIDO1,APELLIDO2, DIRECCION,TELEFONO,FC_NACIMIENTO,FK_ESTADO_CIVIL FROM EJPL_CLIENTES WHERE ID_CLIENTE = w_id; end EJPL_PROC_BUSCAR_POR_ID; 2) Modificación de la entidad de dominio para incluir la named query (Cliente.java): Ejemplo de entidad que define la = "buscarclienteporid", query = "call EJPL_PROC_BUSCAR_POR_ID(?,:w_id)", callable = true, resultclass = = "EJPL_CLIENTES") public class Cliente implements java.io.serializable { 3) Modificación del DAO de Clientes para obtener un cliente por su identificador utilizando el procedimiento almacenado creado (ClienteDAOImpl): Ejemplo de DAO que utiliza la Named Query public Cliente findbyid(final Integer idcliente) { // Implementación de ejemplo utilizando procedimiento almacenado List<Cliente> clientes = (List<Cliente>) gethibernatetemplate().execute(new HibernateCallback() { 106 de 168

107 public Object doinhibernate(final Session session) throws HibernateException, SQLException { return session.getnamedquery("buscarclienteporid") //.setparameter("w_id", idcliente) //.list(); ); Framework Atlas if(clientes!= null && clientes.size() > 0) { return clientes.get(0); return null; // Implementación sin utilizar procedimiento almacenado // return (Cliente) gethibernatetemplate().get( // "xxxx.bloquefuncionaln.domain.cliente", idcliente); 107 de 168

108 6.4.6 Cachés en Hibernate El uso adecuado de mecanismos de caché permitirá aumentar el rendimiento de aplicaciones que accedan a entornos persistentes de información al almacenar las estructuras de objetos en memoria, evitando volver a buscar dichos objetos en bases de datos, ahorrando multitud de accesos y por consiguiente grandes cantidades de tiempo. Los pasos comunes que se siguen en el acceso a datos mediante caches podrían resumirse como: Se realiza una consulta de acceso a datos. Se comprueba si los objetos requeridos se encuentran en caché. Si los objetos están en caché se devuelven directamente. Si los objetos no se encuentran en caché, se recuperan desde un almacén de datos persistente y se almacenan en caché para un uso futuro Las cachés de primer y segundo nivel Hibernate cuenta con dos tipos de cachés, la denominada caché de primer nivel y la de segundo nivel: Figura 1 : Caché de primer y segundo nivel en Hibernate La cache de primer nivel se corresponde al objeto sesión que se obtiene de la factoría de sesiones de Hibernate. Esta caché de primer nivel se encargará de almacenar los objetos que se recuperan de la base de datos. Otra ventaja obtenida en paralelo es que el objeto sesión actúa como fachada y situaciones como accesos, lazos circulares, etc. solo afecta a la propia sesión sin causar efectos colaterales al resto de sesiones abiertas. 108 de 168

109 Una norma fundamental cuando se utilizan cachés, es almacenar sólo lo que estamos seguros que se reutilizará. En otro caso, lo mejor es no utilizar la caché. Cuando se trabaje con una sesión y se mantenga activa en memoria, se debe tener en cuenta que es una caché de primer nivel, y se debe eliminar todo aquello que carezca de sentido su almacenaje en la misma. Se recomienda que cuando se desee eliminar objetos de la caché se invoque al método evict() para que se elimine de caché el objeto pasado como parámetro. Existe también un método clear() que permite eliminar todos los objetos que se encuentren en ese momento en la caché, limpiándola así por completo. Ambos métodos, son útiles para políticas de sincronización entre cachés. La caché de segundo nivel se acoplará a la sesión de Hibernate absorbiendo todos los fallos que se produzcan en ésta. La gran ventaja de utilizar una caché de segundo nivel es que desaparecen los problemas de actualizaciones concurrentes entre sesiones. La caché de segundo nivel se sitúa al mismo nivel que el objeto SessionFactory de Hibernate, recogiendo y coordinando los objetos con los que trabajan las diferentes sesiones. El problema de las actualizaciones concurrentes supone un grave quebradero de cabeza para cualquier sistema de caché. Sea cual sea el modelo que se desee utilizar siempre se tendrá algún problema en relación con las actualizaciones concurrentes, ya sea en mayor o menor medida. La gran ventaja de una caché de segundo nivel, es que ayuda a mitigar estos problemas, al tiempo que alivia de la responsabilidad de almacenar datos temporales, a la caché de primer nivel. La recomendación general con una caché de segundo nivel es utilizar una aproximación de sesión por transacción de aplicación (Sesión por vista). Con una caché de segundo nivel, el gran problema de no aprovechamiento de la caché de primer nivel del que adolecen algunos modelos, desaparece parcialmente. Si un objeto no se encuentra en la caché de primer nivel, Hibernate tratará de obtenerlo de la caché de segundo nivel, de modo que en caso de encontrarse ahí se consigue el ahorro de un hit en la base de datos. Cerrar las sesiones pues, ya no es un problema tan grave (a nivel de rendimiento), ya que aunque se tengan que realizar cientos y cientos de consultas recurrentes, los datos estarán en la caché de segundo nivel, y la pérdida de rendimiento ya no será tan grande. Hibernate permite habilitar individualmente la caché para cada una las entidades. De este modo, se podrá indicar que clases se beneficiarán del uso de una caché, ya que como según lo comentado anteriormente, puede que no todas las clases del sistema se beneficien. Además de esto, al habilitar la caché es necesario establecer la estrategia de concurrencia que Hibernate utilizará para sincronizar la caché de primer nivel con la caché de segundo nivel, y ésta última con la base de datos. Hay cuatro estrategias de concurrencia predefinidas. A continuación aparecen listadas por orden en base a restricciones expresadas en términos de aislamiento transaccional: 109 de 168

110 Transactional: Garantiza un nivel de aislamiento hasta repeatable read, si se necesita. Es el nivel más estricto. Se recomienda su uso cuando no se pueda permitir datos que queden desfasados. Esta estrategia sólo se puede utilizar en entornos basados en clusters, es decir, con cachés distribuidas. Read-write: Mantiene un aislamiento hasta el nivel de commited, utilizando un sistema de marcas de tiempo (timestamps). El caso de uso recomendable es el mismo que para la estrategia transactional pero con la diferencia de que esta estrategia no se puede utilizar en entornos basados en clusters. Nonstrict read-write: No ofrece ninguna garantía de consistencia entre la caché y la base de datos. Para sincronizar los objetos de la caché con la base de datos se utilizan timeouts, de modo que cuando caduca el timeout se recargan los datos. Con esta estrategia se tiene un intervalo en el cual existe el riesgo de obtener objetos desfasados. Cuando Hibernate realiza una operación de flush() en una sesión, se invalidan los objetos de la caché de segundo nivel. Aún así, esta es una operación asíncrona y nunca se tienen garantías de que otro usuario no pueda leer datos erróneos. A pesar de todo esto, esta estrategia es ideal para almacenar datos que no sean demasiado críticos. Read-only: Es la estrategia de concurrencia menos estricta. Ideal para datos que nunca cambian. El siguiente ejemplo muestra una clase junto a su definición de caché de segundo nivel: ADCache2nivel No se permite el uso de cachés de segundo nivel en Hibernate. En el caso de que se justifique su uso se solicitará una autorización excepcional a ICM Las cachés distribuidas Las aplicaciones con decenas de miles de usuarios probablemente necesiten ejecutarse en un entorno distribuido, es decir, en cluster. Llegado este momento, el único elemento de Hibernate que necesitaría configurarse es la caché de segundo nivel. Hay dos modos de configurar una caché de segundo nivel de Hibernate en un cluster: El más sencillo, sin ninguna duda, es colocar en cada nodo del cluster una instancia del proveedor de caché, por ejemplo EHCache, y confiar en los timeout para la sincronización de los proveedores de caché de los diferentes nodos. Este sistema es muy simple, y no presenta retardos de sincronización entre los nodos, ya que no existe sincronización alguna. El segundo modo, es instalar un proveedor de caché más avanzado que soporte la sincronización de las cachés de los diferentes nodos. El proveedor recomendado por Hibernate para esta tarea es JBossCache, un proveedor totalmente transaccional basado en la librería de multicasting, JGroups, 110 de 168

111 si bien no deja de ser una recomendación por lo que llegado el caso podrá optarse por otro proveedor certificado en Hibernate. DAOCacheDistribuida En concordancia con el apartado anterior, se debe justificar el uso de cachés distribuidas en entornos basados en cluster, especificando que ventajas aporta con respecto a otro tipo de soluciones que nos proporcione el entorno ya sea a nivel de bases de datos, servidores de aplicaciones, etc. Además el volumen de información a manejar crecerá sustancialmente (replicación) por lo que se tendrá que justificar su uso en contraposición con otros requisitos no funcionales (como alta disponibilidad), ausentes en el entorno de desarrollo/preproducción La caché de consultas La caché de consultas de Hibernate permite almacenar las consultas realizadas recientemente, de modo que si se vuelven a realizar posteriormente, se recuperen los resultados de un modo mucho más ágil (sin volver a ejecutar la select a base de datos). BUENA PRACTICA ADRendimiento Se desaconseja el uso de la caché de consultas de hibernate, excepto en aplicaciones que sólo realicen consultas (no realicen operación de inserción/borrado/actualización), y realmente hagan uso intensivo de esta caché. 111 de 168

112 7 CONFIGURACION En todas las aplicaciones es necesario establecer ciertos parámetros que permitan modificar el estado o la configuración del sistema. Así, por ejemplo, a la hora de desarrollar una aplicación se suelen definir constantes y valores predeterminados que quizás interese cambiar a lo largo del tiempo, por lo que incluirlos en el código sería un grave error ya que cada modificación implicaría una recompilación del código. Dentro de la configuración de una aplicación vamos a distinguir distintos tipos de configuraciones: o Configuración particular de la aplicación o Configuración de componentes comunes del framework Además dentro de estas configuraciones nos podemos encontrar con configuración que depende del entorno en el que se ejecute la aplicación (local, desarrollo, validación y producción) y la que no depende de dicho entorno. Las variables de configuración de una aplicación pueden estar situadas en distinto lugar, en función de la naturaleza de la variable: Librería de configuración común por entorno: Toda la configuración de componentes comunes del framework que es dependiente del entorno y no se necesita personalizar en las aplicaciones (por tanto sólo depende del entorno y no de la aplicación) se ubica en la librería atlascomunes-configuracion-lib. En los entornos de ICM (desarrollo, validación y producción) esta librería ya se encuentra configurada para dicho entorno y publicada en el servidor de aplicaciones para que todas las aplicaciones puedan acceder a ella, de manera que el proveedor no necesita realizar ninguna acción con esta librería. o Un ejemplo de configuración de este tipo podría ser las políticas de seguridad aplicadas en cada entorno, o la configuración del servidor de planificación ControlM. Fichero application.properties: Este fichero de configuración se encuentra incluido en el directorio src/main/resources/conf de las aplicaciones. En él se deben incluir todas las variables de configuración de la aplicación que NO dependan del entorno en el que esté desplegada (no dependen de que la aplicación se desplegue en local, desarrollo, validación o producción). o Un ejemplo de variable de configuración de este tipo es la que indica el nombre del fichero de menús de la aplicación (menu.xml). Si se trata de variables de configuración referentes a queries (tanto las queries del componente de lista de valores, como queries para la integración con documentum), estas variables se incluirán en el fichero queries.properties. Fichero environment.properties: Este fichero de configuración se encuentra incluido en el directorio src/main/resources de las aplicaciones. En él se deben incluir todas las variables de 112 de 168

113 configuración de la aplicación SI no dependan del entorno en el que esté desplegada (dependen de que la aplicación se desplegue en local, desarrollo, validación o producción). Durante el despliegue de una aplicación en los entornos de ICM, este fichero será sustituido por su homólogo correspondiente al entorno en el que se desea desplegar. o Un ejemplo de variable de configuración de este tipo es la que indica la ubicación física del fichero de log de la aplicación. CONFEntorno El fichero enviroment.properties deberá incluir todas las variables que son dependientes del entorno y que se definan a nivel de aplicación. Este es el único fichero que se actualizará a sus valores correspondientes en el despliegue del aplicativo a los distintos entornos. (local, desarrollo, validación, producción, etc) CONFParticular El fichero application.properties deberá incluir las variables que se definan a nivel de aplicación y que no dependan el entorno en el que está desplegada (local, desarrollo, validación, producción, etc.). También deberá incluir aquellas variables de componentes o servicios del framework que se necesite personalizar para la aplicación y que no dependan del entorno. Si se trata de variables de configuración referentes a queries (tanto las queries SQL/HQL del componente de lista de valores, como queries para la integración con documentum en DQL), estas variables se incluirán en el fichero queries.properties. Las variables de este fichero deberán empezar por querycode. y estarán agrupadas dentro del fichero de manera que se facilite su lectura. 113 de 168

114 CONFNomenclatura La nomenclatura de las variables propias de la aplicación será: xxxx.nombre Donde xxxx es el nombre del proyecto y nombre el nombre de la variable. Estas variables deberán incluir un comentario con la descripción de las mismas. Los comentarios deben aportar claridad, no abusar de ellos intentando que el propio fichero sea autodescriptivo. Para ello ayudará la selección adecuada de los nombres de los parámetros. Los parámetros que hacen referencia a una misma funcionalidad deben ser incluidas en un grupo de elementos adecuadamente comentados. Cuando existan grupos funcionales deben indicarse introduciendo un nivel de anidamiento más en esa estructura para agrupar claramente los valores propios para cada instancia. Esta situación se puede presentar cuando por ejemplo se trabaje con servidores de correo electrónico, donde los datos de conexión y cuentas pueden ser diferentes. CONFSEG Los ficheros de configuración no contendrán información que supongan riesgo de seguridad según lo establecido por la LOPD, como por ejemplo contraseñas no cifradas. A continuación se muestra un ejemplo de cómo obtener el valor de una variable de configuración definida en el fichero application.properites o environment.properties, desde un fichero de Spring: Ejemplo de fichero application.properties ó environment.properties politicas.url= Ejemplo de cómo obtener el valor de una variable de configuración desde Spring <bean id="mibean" class="paquete.miclase"> <property name="url" value="${politicas.url"/> </bean> Para obtener el valor de una variable de configuración desde Java, se recomienda inyectar el valor en la clase Java a través de un bean de Spring (según se muestra en el ejemplo anterior). Aunque menos recomendada para los casos habituales, existe otra forma alternativa que consiste en cargar el fichero de propiedades del que se desea obtener la variable y obteniendo su valor de este, según se muestra en el siguiente ejemplo: 114 de 168

115 Ejemplo de cómo obtener el valor de una variable de configuración desde Java import java.util.properties; import atlas.core.general.propertiesloader; public class EjemploProperties { singleton para cargar properties de fichero private static final Properties PROPS = PropertiesLoader.getInstance( new String[] {"conf/application.properties").getproperties(); Variable obtenida del fichero application.properties public static final String POLITICAS_URL = PROPS.getProperty("politicas.url"); * Devuelve el valor de la URL El valor de la URL leída del fichero application.properties public String geturlpoliticas() { return POLITICAS_URL; 115 de 168

116 8 SERVICIOS BASICOS El framework Atlas ofrece un conjunto de servicios básicos para cubrir aquellos requisitos comunes a la mayoría de las aplicaciones. Los arquetipos ya vienen preconfigurados para poder utilizar estos servicios básicos. A continuación se muestran con más detalle cada uno de estos servicios básicos. 8.1 SERVICIO DE AUTENTICACION Y AUTORIZACION La Comunidad de Madrid dispone de aplicaciones de carácter público y privado, dependiendo, tanto del tipo de función que desempeñan como del tipo de usuarios al que van dirigidas. En el framework Atlas se ha desarrollado el Servicio de Autenticación y Autorización para cubrir este requisito de gestión de accesos. Las aplicaciones de carácter privado limitaran su acceso a determinados usuarios. La forma de acceder a este tipo de aplicaciones puede ser mediante dos mecanismos: certificado digital y/o login/password. Los usuarios que tienen su acceso permitido a determinadas aplicaciones estarán dados de alta en alguno de los repositorios que la Comunidad de Madrid dispone. En estos repositorios de usuarios se encuentra toda la información de los usuarios y sus perfiles o roles de trabajo para cada aplicación. Estos repositorios son los que se muestran a continuación: Política LDAP USU USUI USUJ Repositorio a validar y acciones Almacena los datos de login de los usuarios de la intranet. Se utiliza para la autenticación de los usuarios. Repositorio de usuarios y perfiles de la Comunidad de Madrid. Se utiliza para la autorización de los usuarios. Repositorio de usuarios y perfiles de la Comunidad de Madrid con acceso desde Internet. Se utiliza para la autenticación y autorización de los usuarios. Repositorio de usuarios y perfiles de la Comunidad de Madrid para aplicaciones de Justicia. Se utiliza para la autenticación y autorización de los usuarios. Para el framework Atlas se han definido unas políticas de acceso para las aplicaciones que consisten en la definición de unas reglas de validación de acceso de los usuarios. Estas políticas indican cual es el mecanismo de acceso, contra que repositorios se deben llevar a cabo el proceso de autenticación, así como otras medidas a adoptar. A continuación se muestra una tabla con la lista de políticas de acceso que se han definido para Atlas y que se pueden utilizar en las aplicaciones web. 116 de 168

117 Política Público Público Certificado Usuario Intranet Usuario Internet Usuario Justicia Demo Repositorio a validar y acciones (no se realizará ninguna acción) Validar Certificado contra la plataforma multipki de ASF Validar el usuario contra LDAP y recoger el rol de USU Validar Certificado (multipki) o validar el usuario y recoger su rol en USUI Validar Certificado (multipki) o validar el usuario y recoger su rol en USUJ Política para desarrollo en la cual no es necesario disponer de ningún repositorio. Los usuarios de pruebas se definen en un fichero xml. En algunas aplicaciones se puede dar el caso de que, dependiendo del entorno desde donde se acceda a la aplicación, la forma de autenticación sea distinta. Por ejemplo: una autenticación con certificado si la aplicación es accedida desde internet y permitir acceso mediante usuario/contraseña para los accesos desde la intranet. El Servicio de Autenticación y Autorización de usuarios permite que dependiendo del dominio/host al que se conecte el usuario se presente una política de acceso u otra, según se haya definido en la aplicación a la que se está accediendo. SBAutenAuto Aquellas aplicaciones web que tengan que restringir el acceso a determinados usuarios deberán utilizar el Servicio de Autenticación y Autorización del framework Atlas y siempre utilizando alguna de las políticas ya definidas en el mismo. Para más información sobre el Servicio de Autenticación y Autorización consultar el manual ATLAS_MUS_Servicio_Autenticacion_y_Autorizacion 117 de 168

118 8.2 COMPONENTES DE PRESENTACION El framework Atlas ofrece un conjunto de componentes visuales para el desarrollo de las interfaces gráficas de usuario de las aplicaciones web. Estos componentes están basados en los siguientes productos: JSF estándar RichFaces Tomahawk Ajax4JSF Facelets Los componentes que ofrece el framework Atlas son: Componente Descripción Layouts Componentes de Menú Rastro de Migas Calendario Lista de Valores Lista Paginada Mensaje de Error Captcha Número de documento Código de Barras Arbol Jerárquico Arbol Accesible Solapas Plantillas para organizar la información dentro de la página Componentes para la construcción de menús en una aplicación. Existen 3 tipos de menús: Menú Vertical Menú Horizontal Menú Visual Indicador de navegación para situar al usuario en la estructura de contenidos Facilita al usuario introducir una fecha en un formulario mostrando en un panel emergente un calendario mensual. Facilita al usuario la introducción de un valor que está asociado a un catálogo Muestra una lista de datos de forma tabulada en una serie de páginas Panel para mostrar un mensaje de error Ofrece el mecanismo de prueba necesario para determinar cuando un usuario es humano o no. La prueba consiste en introducir por parte del usuario una serie de caracteres los cuales son mostrados de forma distorsionada por pantalla. Tiene por objetivo el validar identificadores legales (DNI, CIF, Pasaporte y Tarjeta de Residencia). Permite incrustar en una página un código de barras en diferentes formatos. Permite mostrar un conjunto de datos organizados jerárquicamente en forma de árbol Permite mostrar un conjunto de datos organizados jerárquicamente en forma de árbol cumpliendo con la accesibilidad de las aplicaciones Permite mostrar una barra de solapas para organizar formularios que incluyen muchos datos 118 de 168

119 Para más información se puede consultar cada uno de los manuales de cada componente. Estos manuales se llaman ATLAS_MUS_Componente_xxxxx 119 de 168

120 8.3 SERVICIO DE TRAZAS El Servicio de Trazas de Atlas proporciona a todas las aplicaciones una serie de logs automáticos (Inicio /Fin de métodos que deban ser traceados, Transacciones, SQL de las consultas, etc ) durante la ejecución de la aplicación además de formatear todos los logs (tanto generados automáticamente por el componente como los definidos por la propia aplicación) para su posterior uso en la Herramienta de Monitorización. SBTrazas Las aplicaciones deberán generar un único log de aplicación utilizando el Servicio de Trazas que el framework Atlas ofrece. Se deberá hacer un uso adecuado de los niveles de prioridad para los mensajes de logs. Las prioridades predefinidas ofrecidas son (ordenadas de mayor a menor detalle): DEBUG > INFO > WARN > ERROR > FATAL. Estableceremos los siguientes criterios para la explotación de los niveles de log desde nuestro código: DEBUG: Mensajes de depuración. Se puede utilizar para mostrar el valor de variables, parámetros de configuración, etc. Son mensajes que deberían ser entendidos y tratados por alguien que conoce el código de la aplicación. Incorporarán información sobre checkpoints que ayudarán a seguir el curso de la ejecución del algoritmo implementado. INFO: Mensajes de información. Se utilizan para anunciar el progreso en el flujo de la aplicación. Marcarán inicios y finalización de bloques de actividades con cómputos de tiempo empleado en realizarlas, etc. WARN: Mensajes de advertencia, usado dentro de la aplicación para dar aviso de excepciones esperadas y que nuestro código sepa tratarlas para evitar que la aplicación se interrumpa. ERROR: Mensajes de error, para dar aviso de errores inesperados que no lleguen a detener o afectar la ejecución de la aplicación, como por ejemplo que algún parámetro de configuración no sea correcto y se cargue el valor por defecto del mismo. FATAL: Mensajes de error, para dar aviso de errores inesperados que afectan o detienen la ejecución de la aplicación. 120 de 168

121 A continuación se muestra una figura que representa de forma piramidal la jerarquía de niveles de trazas así como la información a mostrar. INFO: Mensajes de información Inicio-fin de acciones y uso de componentes/servicios. Fecha, Hora, Nombre de clase, Nombre de método, tiempo de ejecución del método. Si la clase o el método accede a base de datos : Sentencia HQL/SQL con sus parámetros. Tiempos de preparación y/o ejecución de las consultas. Ciclo de vida de las transacciones: inicio y fin (commit y rollback), etc. Actividad del pool de conexiones Nombre del usuario que invoca al método. Volcado de errores con nivel, número y descripción. Volcado de los parámetros de configuración (al arrancar) FATAL: Mensajes de error críticos Implementar un sistema de alertas que avise de la caída del sistema y dejar notificación del envío en el fichero de log. Siempre que sea posible, almacenar información detallada sobre el error producido. Deberá integrarse con los sistemas de alertas ICM FATAL ERROR ERROR: Mensajes de error Añadirá un indicador de prioridad junto a información relevante que ayude a comprender el alcance del error: Nivel 1 : El proceso puede finalizar correctamente a pesar de las inconsistencias producidas. Nivel 2: Se desconoce si la finalización del proceso puede darse por válida. Nivel 3: El carácter del error es severo. WARN: Mensajes de advertencia Punto del sistema donde se produzca. Información relacionada sobre el posible impacto Las trazas deberán reflejar los datos de la operación que ha generado la excepción. Valores del fichero de configuración con la que se está realizando la operación. NIVEL MÍNIMO DE TRAZAS WARN INFO DEBUG DEBUG: Mensajes de depuración Información detallada de la ejecución de métodos: Entrada y salida de un método Valor de parámetros Hechos relevantes producidos dentro de un método: Construcción y destrucción de objetos relevantes Accesos a objetos locales y remotos Cualquier otra información que permita determinar que se esta realizando en un instante determinado El proceso detallado del flujo de invocaciones sobre toda la infraestructura Información de llamadas entre distintas capas y componentes del sistema Figura 2 : Niveles de trazas SBTrazasSeg El fichero de log no contendrá información que suponga riesgo de seguridad según lo establecido por la LOPD, como por ejemplo contraseñas no cifradas, datos que identifiquen a menores, minusvalías, etc. 121 de 168

122 8.4 SERVICIO DE AUDITORIA DE SEGURIDAD Los Sistemas de Información de la Comunidad de Madrid en algunos casos tratan datos de carácter personal que son especialmente protegidos por la Agencia de Protección de Datos. En estos casos es obligado que se recoja información sobre los accesos realizados a dichos datos. El Servicio de Auditoria de Atlas se encarga de auditar los accesos mencionados anteriormente. Para ello es necesario que la aplicación indique cuáles son aquellos datos susceptibles de ser auditados, basándose en los mecanismos que ofrecen los framework s Spring e Hibernate. El Servicio de Auditoria intercepta todas las operaciones de base de datos que se realizan a través de Hibernate y deja el registro de la auditoria en el esquema TRAZ a través del paquete de base de datos ATLAS.PACK.LOG. Para más información sobre la utilización de este servicio consultar el manual ATLAS_MUS_Servicio_Auditoria SBAudit Las aplicaciones que precisen auditar los accesos a los datos protegidos lo harán a través del Servicio de Auditoria del framework Atlas. 122 de 168

123 9 INTEGRACION El framework Atlas para cubrir los requisitos de integración con otros productos ofrece una serie de servicios adicionales que vamos a denominar servicios de integración. A continuación se muestran los distintos servicios que ofrece el framework. En el caso de que un proyecto tenga un requisito de integración con otro producto o tecnología se debe comunicar al Area de Integración y Arquitectura para que se valore la mejor forma de realizar dicha integración. 123 de 168

124 9.1 SERVICIO DE GESTIÓN DOCUMENTAL La solución de gestión documental para las aplicaciones de la Comunidad de Madrid es el gestor de documental de EMC Documentum. La plataforma EMC Documentum es una extensa suite de productos para la gestión documental que proporciona servicios para la creación, gestión, distribución y archivo de cualquier tipo de contenido documental. Sobre este producto se ha construido un servicio dentro del framework Atlas que permite un acceso a la plataforma de gestión documental independiente de la solución elegida. La integración con el gestor documental se realiza en dos ambitos: Acceso al core de documentum mediante programación Componentes visuales que acceden al gestor documental Para facilitar la configuración y uso de este servicio se ha creado el arquetipo web documental por lo tanto los módulos web que necesiten acceder a este servicio deberían partir de este arquetipo. Por otra parte en los proyectos que incluyen gestión documental es necesario crear un módulo que las definiciones de los tipos documentales y demás elementos necesarios. Para más información sobre este tipo de módulos consultar el manual ATLAS_MUS_Servicio_Gestion_Documental, y ATLAS_MUS_Arquetipo_Web_Documentum. SIGDOC Las aplicaciones que necesiten acceder a un gestor documental lo harán a través del Servicio de Gestión Documental y accediendo a través de los servicios web implementados dentro de este servicio. Actualmente este Servicio de Gestión Documental se ha implementado sobre Documentum. 124 de 168

125 9.2 SERVICIO DE PLANIFICACION En ocasiones es necesario ejecutar ciertas tareas a una hora concreta, en base a una planificación preestablecida. Tal es el caso de la ejecución de informes periódicos, o la generación de estadísticas. Este tipo de tareas suele conllevar una carga importante para la base de datos, cosa que puede empeorar el rendimiento de la aplicación (y de otros sistemas). Para este tipo de tareas normalmente pesadas, existe una solución simple: planificar la creación del informe para las horas cuando el sistema tiene menor carga de trabajo. La solución elegida para realizar la planificación de las tareas mencionadas anteriormente es el producto de BMC CONTROL-M. Figura 3 : Planificación de tareas con Control-M Para poder invocar a este tipo de tareas necesitamos crear un módulo batch que implementa la tarea a ejecutar y utilizar el Servicio de planificación para ejecutar o planificar la tarea. El Servicio de Planificación ofrece os siguientes elementos: Acceso al api de ControlM mediante programación Componentes visuales que muestran información obtenida de ControlM SIPLAN Las aplicaciones que necesiten invocar una tarea batch lo harán a través del Servicio de Planificación del framework Atlas. 125 de 168

126 9.3 SERVICIO DE CERTIFICADOS DIGITALES Las aplicaciones de la Comunidad de Madrid muchas veces requieren de la utilización de certificados digitales que posibilitan la tramitación electrónica. El Servicio de Certificados, provee las siguientes funcionalidades: Cifrado y descifrado de datos Firma electrónica en servidor Verificación de firmas electrónicas Validación de certificados digitales Obtención de datos de un certificado SICert Las aplicaciones que necesiten realizar operaciones con certificados digitales lo harán a través del Servicio de Certificados Digitales que ofrece el framework Atlas. Para más información sobre el uso del servicio de gestión documental consultar el manual ATLAS_MUS_Servicio_Certificados_Seguridad 126 de 168

127 9.4 SERVICIO DE BUSSINESS INTELLIGENT La solución de Bussiness Intelligent para los proyectos de la Comunidad de Madrid es Bussiness Objects de SAP. Sobre este producto se han definido dentro del framework Atlas una serie de componentes visuales que permite un acceso directo a la plataforma de Bussiness Objects. Business Objects XI ofrece, en una única solución, funciones de gestión de rendimiento, generación de informes, consulta y análisis e integración de datos, apoyando a una correcta toma de decisiones tanto a nivel ejecutivo y directivo como a nivel estratégico. Integra distintas fuentes de datos, abstrayendo dichas fuentes, así como los modelos subyacentes, creando una capa semántica con entidades entendibles para el usuario ejecutor y consumidor de los informes, sin necesidad de conocer los modelos de datos relacionales. Esta capa semántica es lo que se conoce en Business Objects XI por el concepto de Universo. Business Objects XI es un producto completamente autónomo y completo que unifica todo el ciclo de gestión y producción de informes. Las principales características aportadas por Business Objects XI son: Acceso y presentación de datos en diversos formatos. Integración de múltiples fuentes de datos. Abstracción de las fuentes de datos en un conjunto de entidades entendibles por parte del usuario que realiza los informes. Esta abstracción permite que los usuarios que realmente tienen necesidad de extraer información, puedan realizar informes sin necesidad de tener los conocimientos técnicos necesarios para comprender el modelo de datos subyacentes. Modificación y creación de reportes en tiempo de ejecución. Gestión eficiente y segura de reportes críticos para el negocio. Entrega de la información requerida a la gente adecuada en un momento determinado. Basado en un tecnología fuertemente probada. Escalabilidad y rendimiento adaptables en base al crecimiento del negocio. Soporte a distintos lenguajes de programación. Gestión de la seguridad en todos los niveles. Las siguientes tareas del ciclo de vida de generación de informes se deben realizar con las aplicaciones aportadas por el producto Business Objects XI: Tareas de extracción, transformación y carga (ETL). Definición de Universos. Organización en carpetas y subcarpetas. Definición de usuarios y permisos a nivel de datos, de carpetas y de informes. Creación de informes. Planificicación de informes. La integración con Business Objects XI de las aplicaciones desarrolladas con Atlas se limitará a las siguientes tareas: 127 de 168

128 Conexión al servidor Business Objects XI con las credenciales definidas en la implantación BO. Recorrido de carpetas autorizadas. Visionado de los informes de esas carpetas. Planificación de informes En proyectos que integren una solución completa de Business Objects XI, el ciclo de vida de la extracción de información se gestionará por medio de las aplicaciones que proporciona la plataforma Business Objects XI, y no desde la integración con Atlas. La integración con Atlas se limitará a la presentación, visionado y planificación de los informes generados por la plataforma Business Objects XI. SIBI Las aplicaciones que necesiten acceder a la plataforma de Bussiness Objects lo harán a través de los componentes establecidos en el framework Atlas. 128 de 168

129 9.5 SERVICIO DE INVOCACIÓN DE SERVICIOS WEB Muchas de las aplicaciones que se desarrollan para la Comunidad de Madrid necesitan acceder a servicios web tanto servicios que se han desarrollado específicamente para la tramitación electrónica como otros servicios web que incluso pueden estar fuera de nuestros entornos. Dada la amplia variedad de tipos de servicios web que nos podemos encontrar y los distintos tipos de seguridad que nos pueden requerir los citados servicios web se ha desarrollado el Servicio Invocador de Servicios. Para más información sobre este servicio consultar el manual ATLAS_MUS_Servicio_Invocador_de_Servicios. INTWS Para invocar a un servicio web se hará mediante la utilización del Servicio de Invocación de Servicios Web de Atlas. 129 de 168

130 9.6 SERVICIO DE PROCESOS DE NEGOCIO Un proceso de negocio es la representación del trabajo realizado por las personas y los sistemas de una organización, con el objetivo de ofrecer un servicio a sus clientes. Business Process Management (BPM) es el arte de formalizar la automatización de los procesos de negocio. Un BPM simplifica el desarrollo de aplicaciones que tengan alguno de los siguientes requerimientos: Orquestación de servicios de negocio: es la secuenciación de las diferentes tareas y servicios que forman parte de un proceso. La orquestación permite crear lógica dentro del proceso, ofreciendo funcionalidades tales como: o o o o o o Invocación sincrónica y asincrónica a servicios. Manejo de transacciones. Mecanismos de compensación y manejo de excepciones. Transformación de mensajes para adaptar la salida de un servicio a la entrada de otro (mapeo de datos). Manejo de condicionales, loops, etc. Orientación a flujos de trabajo: los BPM ofrecen herramientas para definir los procesos de negocio que comprenden un sistema. Los procesos de negocio pueden comprender tareas desempeñadas por personas, y tareas que se ejecutan de forma automática. Integración de personas dentro de los flujos de trabajo: cuando la ejecución de un proceso requiere que ciertas personas en la organización realicen funciones relacionadas con el proceso (aprobaciones, revisiones, etc.), el uso de un BPM simplifica la interacción con las mismas. Necesidades de integración con diferentes sistemas y fuentes de datos: los BPM disponen de conectores para acceder a diferentes sistemas comerciales existentes en grandes organizaciones (SAP, PeopleSoft, CICS, etc.), de forma que la creación de tareas en las que intervenga este tipo de productos se simplifica enormemente. Capacidades de seguimiento y gestión de las tareas definidas en los procesos de negocio: un BPM ofrece herramientas administrativas que permiten a ciertas personas poder hacer un seguimiento de los procesos y tareas que los comprenden. Medición, auditoría, control y reportes: asociado a un producto de este tipo se ofrecen herramientas para realizar métricas y análisis del funcionamiento global del sistema. Aplicación de reglas de negocio. Ejecución de procesos con estado. 130 de 168

131 La solución de BPM (procesos de negocio) para las aplicaciones de la Comunidad de Madrid es producto Oracle BPM. Sobre este producto se ha construido un servicio dentro del framework Atlas que permite un acceso a la plataforma de BPM independiente de la solución elegida, este servicio se denomina Servicio de Procesos de Negocio. La integración con el motor de procesos se realiza en dos ambitos: Acceso al core de Oracle BPM mediante programación Componentes visuales que muestran información obtenida del motor de procesos SIBPM Las aplicaciones que necesiten acceder a un motor de procesos lo harán a través del Servicio de Procesos de Negocio de Atlas. Actualmente este Servicio de Procesos de Negocio se ha implementado sobre el producto Oracle BPM. 131 de 168

132 9.7 OTRAS SOLUCIONES Por otra parte dentro del framework Atlas se ha seleccionado una serie de soluciones o librerías de terceros que nos cubren otras funcionalidades o requisitos que podamos tener a la hora de desarrollar nuestra aplicación. SOLLIB El uso de cualquier librería, producto de terceros o tecnología no incluido dentro del framework deberá ser previamente consensuado y autorizado por ICM. 132 de 168

133 9.7.1 REPORTING La solución de generación de listados e informes para las aplicaciones de la Comunidad de Madrid es Crystal Reports Para utilizar informes de Crystal Reports 2008 en las distintas aplicaciones de la Comunidad de Madrid, se ha optado por una solución centralizada que libera a la aplicación que va a utilizar los informes de la complejidad de su generación e interpretación. Para ello, la solución planteada propone albergar los informes en la plataforma corporativa Business Objects Enterprise, de manera que las aplicaciones que tengan que utilizar dichos informes accederán a ellos abriendo un navegador con una URL que hace referencia al informe en dicha plataforma. El acceder a la plataforma de informes requiere de una autenticación previa antes de poder acceder a los informes. Dicha autenticación se realizará accediendo a un Servicio Web, al que se proporciona unas credenciales, y devuelve una cadena de texto que sirve para identificarse en la plataforma. El siguiente esquema muestra a modo general la arquitectura de la solución propuesta, así como los tres pasos necesarios para mostrar un informe de Crystal Reports 2008: Publicación del informe, Autenticación en la Plataforma, y Apertura del informe: 133 de 168

134 Para incluir informes en nuestra aplicación en primer lugar debemos diseñar o crear dichos informes con la herramienta Crystal Reports SOLRpt La herramienta de creación de los informes de las aplicaciones será Crystal Reports El nombre del informe tendrá la siguiente nomenclatura: XXXXNombreDelInforme.rpt Donde xxxx es el nombre del proyecto y NombreDelInforme el nombre del informe que debe estar escrito en minúsculas, excepto la primera letra de cada palabra que estará en mayúsculas. Este nombre no puede contener espacios en blanco. La extensión debe ser rpt. 134 de 168

135 La conexión con la base de datos deberá ser JDBC y desde la propia herramienta se puede ejecutar el informe para ver el resultado del mismo. SOLRptConex El tipo de conexión con la base de datos debe ser JDBC. Los informes se desarrollarán integrando las sentencias SQL dentro del informe, no estando permitidas las opciones de ResultSet, RecordSet ni colecciones de objetos, a no ser que así se acuerde explícitamente con ICM. El nombre de las tablas de base de datos dentro del informe rpt desarrollado no deberán incluir el nombre de la instancia de base de datos. De esta forma será posible ejecutar los informes sobre distintas instancias (desarrollo, test, producción...) sin necesidad de modificar el fichero rpt. Una vez que tengamos los informes completados se deberán publicar en la plataforma de BO. En la entrega se agruparan los distintos informes dentro de un nuevo módulo de tipo reports. SOLRptModulo Todos los informes se entregaran en un módulo con la siguiente nomenclatura: xxxx_crbo Donde xxxx es el nombre del proyecto. Dentro se creará una carpeta llamada reports donde se incluirán todos los reports. Para acceder a los informes que se encuentran en la plataforma se implementará una clase de negocio llamada ServicioCR. En esta clase se tienen que implementar los siguientes pasos: Invocar al servicio web de autenticación con la plataforma. Esta llamada nos devuelve una cadena de texto (token) para poder acceder a la plataforma BOE. La url del servicio web en desarrollo es : Invocar a la url de opendocument. Una vez que hemos obtenido el token que nos autentica con la plataforma, es suficiente con acceder a la URL del servicio opendocument de la plataforma de BO, indicándole el documento que deseamos abrir, así como los parámetros que recibe. La url de opendocument será algo como: Ejemplo de url de invocación a opendocument urlrequest = " + servername + ":" + serverport + "/OpenDocument/opendoc/openDocument.jsp?sType=rpt + &sdocname=" + docname + "&soutputformat=p" // P=pdf, H=html, E=excel, W=word + "&token=" + logontoken; 135 de 168

136 Para más información sobre el uso del servicio opendocument de la plataforma de BO (paso de parámetros a documentos, etc.), consultar el documento Viewing Reports and Documents using URLs en la URL: Es necesario indicarle a la aplicación determinados parámetros de configuración sobre el servicio web y la plataforma de BO. Como estos parámetros dependen del entorno se deben definir en el fichero environment.properties. SOLRptConf El fichero de configuración environment.properties debe incluir las siguientes variables: bo_ws.webservice Apunta a la url del servicio web bo_ws bo_ws.nombreservidor Servidor de la plataforma BO bo_ws.puerto Puerto por el que acceder al servicio opendocument bo_ws.usuario Usuario con el que nos conectaremos a la plataforma de Bussiness Objects. bo_ws.clave Clave del usuario encriptada. 136 de 168

137 9.7.2 COMPOSICION DE DOCUMENTOS Este punto tiene por objetivo explicar como se realizará la generación dinámica de documentos Word y RTF, a partir de plantillas previamente definidas en este mismo formato. Para el relleno de las plantillas así como la transformación dinámica de las mismas se utilizará Velocity. Velocity es un motor de plantillas basado en Java que incluye un lenguaje de script, el Lenguaje de Plantillas de Velocity (VTL por sus siglas en inglés). El Lenguaje de Plantillas de Velocity (VTL) nos permite incorporar contenido dinámico dentro de un documento de tipo texto de una manera fácil y sencilla. Este lenguaje se utilizará para la creación de las plantillas. Desde la parte del negocio de la aplicación es dónde se va a realizar la fusión de las plantillas utilizando el API Java de Velocity. Se trata de que la fusión del documento se realice en el lado del servidor. El uso del API en java básicamente consiste en definir un contexto con las variables a mapear en el documento, aplicar este contexto a la plantilla y generar el nuevo documento. Documentos RTF Contenedor Web Petición JSF Respuesta JSF.doc,.rtf Documento generado Motor de plantillas velocity Plantilla Velocity VTL.doc,.rtf Documento generado.html, txt, etc Documento origen DOCUMENTUM Figura 4 : Generación de documentos RTF SOLCompositor Para la composición de documentos en Atlas se utilizará la solución de Velocity. Las plantillas se crearán en formato RTF y los documentos generados tendrán también formato RTF. Las plantillas se incluirán en la carpeta plantillas del proyecto. 137 de 168

138 SOLCompositor Se recomienda utilizar nombres significativos en las variables, y notaciones sencillas al hacer uso de las etiquetas que dote de claridad a la plantilla y sea fácilmente inteligible mediante una lectura rápida. Esto ayudará a realizar un buen mantenimiento de la misma cuando sea necesario aplicarla modificaciones. Se recomienda utilizar sintaxis de etiquetas simple, escapando de notaciones más complejas a no ser que esté justificada claramente su utilización. BUENAS PRACTICAS Se recomienda no anidar bucles en la medida de lo posible. Estos procesos interactivos complican los procesos de renderizado. Se recomienda hacer uso de las estructura de datos estándar: string, list y map. Su procesado es rápido y eficaz. Se recomienda incorporar macros a las plantillas cuando se prevea una reutilización del mismo en varios puntos del documento o cuando la operación de renderizado se presuponga compleja. En este último caso el macro deberá mostrar una interfaz clara en su llamada que aporte la máxima claridad a la plantilla. Se recomienda escapar de utilizar llamadas a macros de manera recursiva. Se recomienda delegar el menor trabajo posible al generador de documentos. A pesar de que incorporan cierta potencia de calculo, operaciones y operadores, manejo avanzado de estructuras de datos, etc prescindir cuando sea posible de ello, delegando esos cálculos a nuestra aplicación y dejando que el compositor de documentos sólo realice la tarea de renderizado, la de dibujar el documento, es decir los datos que alimentan la plantilla, deben de ir adecuadamente tratados y formateados. 138 de 168

139 9.7.3 GESTION DE DOCUMENTOS EXCEL La solución del framework Atlas para la generación o modificación de ficheros Excel es Jakarta POI. SOLExcel Para la gestión de documentos Excel en las aplicaciones del framework Atlas se utilizará la librería Jakarta POI. Desde las aplicaciones se usuará directamente este API desde la capa de negocio. 139 de 168

140 9.7.4 GESTION DE DOCUMENTOS PDF Para la generación y manipulación dinámica de PDFs se deberá utilizar la librería itext. Se debería utilizar esta librería en casos como: Generación dinámica de documentos PDF mediante APIs de desarrollo en base a varias alternativas de fuentes de datos como bases de datos, ficheros XML, etc. Crear mapas, libros electrónicos, dotar de interactividad a documentos PDF. Añadir bookmarks, números de página, filigranas, etc. Dividir y concatenar documentos pdf. SOLPDF Para la generación de documentos PDF desde las aplicaciones del framework Atlas se utilizará la librería IText. A pesar de que itext permite la generación de documento RTF, para esta finalidad ha de emplearse Velocity, ya que es un mecanismo más flexible y potente. 140 de 168

141 9.7.5 GENERACION DE GRAFICOS Para la generación de gráficos se utilizará la librería JFreeChart, una librería 100% Java que permite desarrollar gráficos, para poder incluirlos en aplicaciones, documentos e informes. Con JFreeChart podremos hacer diferentes tipos de gráficos que van desde los tipos comunes tales como gráficos circulares, gráficos de barras, áreas, gráficos de línea, histogramas, diagramas de Gantt y más específicos y menos frecuentemente utilizados como tipos Candlestick, Viento y Wafer Map. También se puede usar la familia Chart de Jenia4faces, que ofrece componentes JSF para la inclusión de gráficas realizadas mediante JFreeChart en una aplicación JSF. SOLGraficos La generación de gráficos de las aplicaciones del framework Atlas se hará con la librería JFreeChart y los componentes visuales Jenia4Faces. BUENA PRACTICA SOLGraficosGrandes Como norma general se recomienda tener especial cuidado con imágenes de JFreeChart que ocupen mucho espacio y puedan saturar el ancho de banda en aplicaciones con interfaz Web. 141 de 168

142 9.7.6 MANIPULACION DE ARCHIVOS MULTIMEDIA En muchas ocasiones surge la necesidad de utilizar un API que permita la incorporación de archivos audio, video, sonido u otro tipo de archivos multimedia en aplicaciones Java, extendiendo las capacidades multimedia por defecto de la plataforma Java 2 Standard Edition. La tecnología Java Media FrameWork API (JMF) permite manipular y gestionar ficheros de audio, video u otros archivos multimedia que formen parte integral de aplicaciones y applets. Este paquete opcional actúa sobre múltiples formatos, proporcionando a desarrolladores un control adicional escalable e independiente de la plataforma de proceso y renderizado de archivos multimedia. JMF esta diseñada en base a plugins proporcionando acceso directo a recursos multimedia y aportando a JMF las caracteríticas necesarias para personalizarlo y extenderlo en base a necesidades específicas. SOLMultimedia El API JMF 2.X será la tecnología a utilizar para cualquier manipulación sobre archivos multimedia. Este API no esta incluida por defecto en la plataforma Java 2 Standard Edition. Cuando se necesite extender las capacidades de la tecnología JMF en referencia a la manipulación de ficheros de imagen se podrá recurrir a las API s Java 2D, Java advanced Image (JAI) y JAI Image I/O. Se deberá utilizar el API Java 3D cuando se requieran capacidades adicionales sobre manipulaciones y renderizados de imágenes en tres dimensiones. 142 de 168

143 9.7.7 Acceso a plataforma y dispositivos locales La plataforma local define los elementos, herramientas, servicios y productos residentes en la máquina de cada usuario para dar soporte a la ejecución de las aplicaciones de la organización cubriendo la extensión de las aplicaciones web de cara a interactuar con elementos residentes en la plataforma local, como pueden ser dispositivos y aplicaciones. SOLAccesoLocal Para la integración con los dispositivos y aplicaciones de la plataforma local se utilizarán y desarrollarán componentes de tipo Applet. 143 de 168

144 9.7.8 XML Algunas aplicaciones tienen que gestionar ficheros XML para facilitar la gestión de los mismos se ha seleccionado la librería JAXB. JAXB aporta una forma sencilla de asociar un esquema XML a su representación en código Java. Esto hace simple el manejo de datos XML desde Java, sin necesidad de conocer mucho acerca de XML. JAXB consta de 3 componentes principales: El compilador de esquema, que transforma el esquema en una serie de elementos requeridos para el proceso de lectura (unmarshalling) y escritura (marshalling) de un XML. El generador de esquema, que convierte estos elementos (descritos mediante anotaciones Java) a un esquema XML. El framework de asociación (binding), que ofrece las operaciones de lectura (unmarshalling) y escritura (marshalling) para el acceso, manipulación y validación de contenido XML usando los elementos generados mediante las herramientas anteriores. El siguiente esquema muestra un diagrama de funcionamiento de estos elementos: SOLXML Cuando las aplicaciones necesiten trabajar con ficheros XML, tanto para generarlos como para leerlos, se utilizará la implementación de referencia de JAXB (Java Architecture for XML Binding). Los pasos para realizar la asociación entre un documento XML y un objeto Java con JAXB son los siguientes: 1. Generar las clases Java (a partir del esquema XML). 144 de 168

145 2. Compilar las clases. 3. Leer el documento origen (unmarshall). 4. Generar el árbol de contenido. El proceso de lectura genera un árbol de contenido a partir de las clases generadas. 5. Validar: antes de generar el árbol de contenido a partir del XML origen se puede validar dicho documento. También se puede validar el documento a generar (cuando sea el caso). 6. Procesar el contenido. La aplicación cliente puede modificar los datos del documento XML que representa el árbol de contenido a través de los interfaces generados por el compilador 7. Escritura (marshall), esto es, generar uno o más documentos XML a partir del árbol de contenidos. Como se dijo anteriormente, el contenido puede ser validado antes de este proceso. La siguiente imagen muestra de forma gráfica el proceso descrito: Figura 5 : Asociación de un documento XML con un objeto Java 145 de 168