FRAMEWORK JUSTICIA - ARQUITECTURA APLICACIONES WEB

Transcripción

1 FRAMEWORK JUSTICIA - ARQUITECTURA APLICACIONES WEB Versión Octubre 2009 Página: 1

2 CONTROL DE CAMBIOS Fecha Versión Cambis 22/02/ Mdificad apartads: 1. Requisits Generales 2.2 Entrn de desarrll 3.3 Estructura de directris (2 nuevs directris) 3.12 Mdel de seguridad 3.14 Capa presentación 10 Referencias Eliminad apartads pr encntrarse en el dcument Desarrll en Java: 2.2 Base de Dats 3.10 Test de pruebas 3.11 Dcumentación 3.2 Us de cnvencines en ls pryects Nuev apartad: 8 Otras cuestines a tener en cuenta 03/10/ Indicams la página en la que se encuentran actualizadas las librerias de JAXB 29/10/ DATOS: Añadid el us de JDBC para prcedimients almacenads. 4, Cmpsitr de dcuments: Se sube a la versión 1.5 de Velcity. Página: 2

3 INDICE 1 REQUISITOS GENERALES REQUISITOS DEL ENTORNO ARQUITECTURA DE SISTEMAS ENTORNO DE DESARROLLO NAVEGADORES Y POB REQUISITOS ARQUITECTURA J2EE CARACTERISTICAS DE LAS APLICACIONES ESTRUCTURA DE DIRECTORIOS ESTRUCTURA DE PAQUETES JAVA CONFIGURACIÓN GENERACION DE TRAZAS DE LOG GESTION DE EXCEPCIONES Reglas y recmendacines Us excesiv de excepcines explícitas Resumen práctic SOPORTE INTERNACIONALIZACIÓN TAREAS ASINCRONAS (SCHEDULING) AUDITORIA MODELO DE SEGURIDAD ARQUITECTURA DE LAS APLICACIONES CAPA PRESENTACION CAPA LOGICA DE NEGOCIO CAPA PERSISTENCIA DATOS DOCUMENTOS COMPOSITOR DE DOCUMENTOS TRATAMIENTO DE FICHEROS XML GENERACION DE INFORMES INTEROPERABILIDAD CON SISTEMAS EXTERNOS OTRAS CUESTIONES A TENER EN CUENTA RESUMEN REFERENCIAS ANEXOS Página: 3

4 1 REQUISITOS GENERALES REQUISITOS La presente guía establece un marc de trabaj cmún a tdas las aplicacines que cnfiguran el nuev Sistema de Infrmación Judicial de la Cmunidad de Madrid. Para ell, define una serie de requisits de bligad cumplimient pr cada una de las aplicacines, desglsad en ls diferentes elements que cnfiguran la arquitectura de las mismas. Adicinalmente a ls requisits explícitamente expuests se deben cumplir ls requisits especificads en la nrmativa general para el Desarrll de aplicacines Java y el siguiente requisit: El us de cualquier nueva tecnlgía, prduct, librería cmpnente, n incluid en la presente guía, que se desee incrprar a las aplicacines deberá ser cnsensuad previamente pr ICM. Página: 4

5 2 REQUISITOS DEL ENTORNO 2.1 ARQUITECTURA DE SISTEMAS Las aplicacines deberán desarrllarse teniend en cuenta que en el entrn de prducción pdrán ser desplegadas en md cluster, tant en varias instancias de un mism diferentes servidres de aplicacines. Ver anex de Arquitectura de las Aplicacines de Justicia. De esta arquitectura se desprenden ls siguientes requisits a tener en cuenta en el desarrll de las aplicacines: Minimizar el us de la sesión. Cm ya sabems, cada petición al servidr recibe su bjet Sessin, dnde la aplicación puede guardar y recuperar infrmación específica para cada usuari haciend us de las variables de sesión. Aunque parece una gran idea guardar grandes bjets, cm la cnexión a una base de dats en una variable de sesión y así utilizarla en tdas las páginas mejrand (en tería) el rendimient, est es abslutamente fals, pr varias raznes. REQUISITOS Cada usuari que entra en la aplicación recibe su prpi bjet Sessin persnal. Ls bjets cupan una gran cantidad de memria del servidr. Almacenarls en una variable de sesión significa que rápidamente el servidr se va a quedar sin memria y la ejecución de ls prcess va a ser much más lenta. Este deterir además, afectaría a cualquier tip de petición, y además si un usuari entra y sale a ls 15 segunds de la aplicación, su cpia del bjet permanecerá en memria hasta que termine el tiemp de caducidad de sesión, perjudicand y penalizand sin justificación al sistema. Reducir el tiemp de caducidad de sesión para evitar el prblema anterir n es buena slución, es más, sería un errr, ya que la caducidad de la sesión bligaría prbablemente a realizar un nuev registr en la aplicación a aquells usuaris que permanecieran inactivs durante un tiemp mayr a ese pequeñ interval establecid. Hablaríams de que la sesión ha expirad y n es psible cntinuar el prces abiert sin cmenzar de nuev. El tr extrem cntrari es much per: pner un TimeOut muy elevad pr si acas, y así mantendrems el estad 100% segur. Est significa que si 100 usuaris llegan al mism tiemp y se van en 10 minuts, tienes 100 bjets Sessin malgastand memria durante el rest de tiemp, lógicamente est es inaceptable. Las variables de sesión sn justificables sól en cierts aspects puntuales. La mayría de las csas se pueden hacer sin ellas, y evitams tds ls prblemas que cnlleva, cn ckies, frmularis y querystrings. Página: 5

6 Además, tr de ls errres más cmunes es guardar en variables de sesión csas que n sn específicas para cada usuari, cm cadenas de cnexión a bases de dats, algún HTML que imprimims siempre, cm pie de página... Las variables de sesión n están pensadas para es. Nunca se deben incluir en sesión cleccines de bjets ya que se descnce su tamañ. El tamañ de la sesión nunca pdrá exceder ls límites que ICM defina en base a la arquitectura de sistemas, este limite dependerá del nº de usuaris cncurrentes. Ls fichers generads pr las aplicacines y que se necesiten dejar en disc se ubicarán según se indique en un parámetr del ficher de cnfiguración, cm se verá en el apartad cnfiguración. Esta ubicación crrespnderá cn un directri cmpartid pr las distintas maquinas que cmpngan el cluster. Además hay que tener en cuenta que cada aplicación va a tener un únic directri de trabaj exclusiv para us de dicha aplicación. Las aplicacines se van a ejecutar en varias maquinas virtuales pr l tant ls bjets que se dejen en la memria de la maquina virtual n estarán replicads en las diferentes instancias. Página: 6

7 2.2 ENTORNO DE DESARROLLO El entrn de desarrll Java recmendad pr ICM se cmpne de ls siguientes elements: Eclipse 3.1 MyEclipse Enterprise Wrkbench 4.1 Apache Maven 2 Checkstyle PMD Ls prveedres pdrán utilizar cualquier entrn de desarrll aunque deberán tener en cuenta ls siguientes requisits a la hra de realizar las entregas sftware: REQUISITOS Dad que el entrn de mantenimient de ICM utiliza Eclipse, el sftware entregad deberá incluir ls fichers de pryect que este entrn utiliza a fin de facilitar su cmpilación, depuración, etc. Las aplicacines deberán incluir un pryect Maven 2 en su defect scripts cmpatibles cn la librería Apache Ant que permitan realizar las peracines básicas cm: cmpilación del pryect y generación del ficher ear. Maven es una herramienta de gestión de infrmación de pryects. Maven está basad en el cncept de un mdel de bjets del pryect POM (Prject Object Mdel) en el que tds ls prducts (artifacts) generads pr Maven sn el resultad de cnsultar un mdel de pryect bien definid. Cmpilacines, dcumentación, métricas sbre el códig fuente y un innumerable númer de infrmes sn tds cntrlads pr el POM. Maven tiene muchs bjetivs, per resumiend Maven intenta hacer la vida del desarrlladr sencilla prprcinand una estructura de pryect bien definida, uns prcess de desarrll bien definids a seguir, y una dcumentación cherente que mantiene a ls desarrlladres y clientes infrmads sbre l que curre en el pryect. Maven aligera en gran cantidad l que la mayría de desarrlladres cnsideran trabaj pesad y aburrid y les permite prseguir cn la tarea. Est es esencial en pryects de gran alcance dnde hay que realizar una labr imprtante de dcumentación y prpagación de la infrmación crítica sbre el pryect que es necesaria para atraer ptenciales nuevs desarrlladres y clientes. La ambición de Maven es hacer que el desarrll intern del pryect sea altamente manejable cn la esperanza de prprcinar más tiemp para el desarrll entre pryects. Se puede llamar plinización entre pryects cmpartir el cncimient sbre el desarrll del pryect. Características: El mdel de bjets del pryect POM es la base de cóm Maven trabaja. El desarrll y gestión del mdel está cntrlad desde el mdel del pryect. Un únic cnjunt de métds sn utilizads para tds ls pryects que se gestinan. Ya n hay necesidad de estar al tant de innumerables sistemas de cmpilación. Cuand las mejras se hacen en Maven tds ls usuaris se benefician. Página: 7

8 Integración cn Gump, una herramienta usada en el pryect Jakarta para ayudar a ls pryects a mantener cmpatibilidad cn versines anterires. Publicación del siti web basad en el POM. Una vez el POM es exact ls desarrlladres pueden publicar fácilmente el cntenid del pryect, incluyend la dcumentación persnalizada más el ampli cnjunt de dcumentación generada pr Maven a partir del códig fuente. Publicación de distribucines basada en el POM. Maven alienta el us de un repsitri central de librerías, utilizand un mecanism que permite descargar autmáticamente aquellas necesarias en el pryect, l que permite a ls usuaris de Maven reutilizar librerías entre pryects y facilita la cmunicación entre pryects para asegurar que la cmpatibilidad entre distintas versines es crrectamente tratada. Guías para la crrecta dispsición de ls directris. Maven cntiene dcumentación sbre cm dispner ls directris de frma que una vez es aprendida se puede ver fácilmente cualquier tr pryect que use Maven. Más infrmación en el Anex de Apache Maven 2. Página: 8

9 2.3 NAVEGADORES Y POB REQUISITOS La aplicación debe funcinar crrectamente cn el POB de Justicia y superir. En el apartad de anexs se incluyen ls requisits de dich POB. Además debe de ser cmpatible cn la versines de Navegadr Internet Explrer 6.0 superir y Mzilla Firefx 1.4 superir. Página: 9

10 2.4 REQUISITOS ARQUITECTURA J2EE Las aplicacines que cmpnen el nuev Sistema de Infrmación Judicial de la Cmunidad de Madrid deberán desarrllarse según la especificación J2EE (Java 2 Enterprise Editin) deberán cumplir ls siguientes requisits: Deben ser cmpatibles cn la especificación J2EE en su versión 1.4, l cual fija las especificacines que deben cumplirse a nivel de las diferentes tecnlgías subyacentes, entre ellas: REQUISITOS Especificación Versión J2EE (Java 2 Enterprise Editin ) 1.4 Java Servlet Specificatin 2.4 JavaServer Pages Specificatin 2.0 JDBC (Java Database Cnnectivity) Specificatins, 3.0, 2.1, and Optinal Package API (2.0) Java Transactin API Specificatin 1.0.1B Java Transactin Service 1.0 Specificatin SOAP with Attachments API fr Java 1.2 Specificatin JavaMail API Specificatin 1.3 Java Message Service Specificatin 1.1 Las aplicacines n deben usar funcinalidades prpietarias del servidr de aplicacines, sin la previa aprbación de ICM, para garantizar al máxim la prtabilidad entre servidres de aplicacines certificads J2EE 1.4. Las aplicacines n deben usar funcinalidades tecnlgías dependientes del sistema perativ sin la previa aprbación de ICM. En cncret, las aplicacines deberán sprtar ls sistemas perativs Linux (RedHat 3.0), Slaris y Windws2000, aunque en prducción las aplicacines se ejecutarán sbre Linux (RedHat 3.0). Página: 10

11 3 CARACTERISTICAS DE LAS APLICACIONES 3.1 ESTRUCTURA DE DIRECTORIOS La estructura de directris en td pryect ICM debe de clgar de una carpeta cn el nmbre del pryect /pryect/, este nmbre se crrespnde cn el nmbre de Midax (4 letras). Esta será la ruta raíz del árbl de pryect. Cm dentr de un pryect pdems tener varis móduls para cada módul vams a tener la estructura de directris que se muestra a cntinuación: Path /mdul/ /dc/ /api/ /gui/ /man/ /req/ /test/ /uml/ /lib/ /src/ /java/[package] /test/[package] /selenium /jmeter /WebRt/ /css/ /html/ /img/ /js/ Descripción Cntiene ls fichers de cnfiguración XML para el despliegue autmátic cn ANT. En esta estructura se desarrlla el módul de un pryect. También cntendrá ls fichers.classpath y.prject de Eclipse. Tda aquella infrmación que n se pueda catalgar en la estructura subyacente. Javadc del aplicativ. TODA la infrmación generada pr el equip de diseñ gráfic: archivs de phtshp, de freehand, de flash, jpeg, TODOS ls manuales: de usuari, de peración e instalación. Dcument de especificacines (cntiene ls requisits generales, infrmación del mdel de dats y la arquitectura del sistema). Tdas las fichas de ls requisits y las fichas de las tareas. Tda la dcumentación referente cn pruebas del aplicativ: de aceptación, de carga, checklist de errres Td el mdel UML recgid en ls trabajs de diseñ, es el directri en el cual trabaj la herramienta CASE de mdelad. TODAS las librerías que necesita el aplicativ (.jar,.zip, ), estas librerías deben de estar clasificadas en directris según el tip de servici que prestan. Cntiene td el códig fuente (.java) sin incluir el interfaz gráfic de usuari (.jsp,.html, ). Estructura de paquetes cn el códig fuente del aplicativ (.java). Se sustituye [package] pr el paquete raíz que se defina para el sistema. De este directri cuelga tda la estructura de pruebas unitarias del aplicativ (.java). Se sustituye [package] pr el paquete raíz que se defina para el sistema. De este directri cuelgan tds ls elements necesaris para la ejecución de las pruebas de selenium De este directri cuelgan tds ls elements necesaris para la ejecución de las pruebas de jmeter Fichers para el despliegue de la aplicación web Hjas de estil del aplicativ. Directri cntenedr de páginas HTML. Almacén de las imágenes del pryect. Pueden almacenarse en directris cntenids en este principal. Fichers de javascript. Página: 11

12 /msg/ /estandar / /librerias/ /ajax/ Directri para nuestrs scripts de validación y utilidades que n hacen us de AJAX. Directri para incluir ls fichers de la librería DWR cualquier tra de la que se mantenga una dependencia. Aquí se incluyen scripts generales usads pr el rest de scripts AJAX Fichers de traduccines (xml) para i18n. / WEB-INF / Tda la infrmación de cnfiguración del aplicativ, que es necesaria, para ls distints cntenedres de infraestructura: Servidr web, servidr de aplicacines, /classes/ Lugar para dejar las clases cmpiladas para que el Classlader (en el cas de Tmcat) ls pueda lcalizar. /cnf/ /dtd/ /jsp/ /lib/ /tld/ Fichers de cnfiguración Fichers de DTD Directri cntenedr de páginas JSP. Directri de despliegue de las librerías. Fichers de TLD [url + path]/temp/ Directri auxiliar para cntener ls fichers temprales, intermedis de las peracines de ANT, etc... Este directri pdrá lcalizarse en cualquiera de las máquinas del cluster y pdrá ser cmpartid pr tras aplicacines. Existirá un prcesad autmátic para vaciar el cntenid de este directri en base a unas plíticas temprales. [url + path]/lg/ Fichers de lg del aplicativ. Este directri pdrá lcalizarse en cualquiera de las máquinas del cluster. Existirá un prcesad autmátic para vaciar el cntenid de este directri en base a unas plíticas temprales. Página: 12

13 3.2 ESTRUCTURA DE PAQUETES JAVA Para ls paquetes de la aplicación se empleará la siguiente estructura haciend us de ls caracteres en minúscula y en ningún cas pdrá utilizarse el nmbre del prveedr en tal estructura: /[nmbrepryect]/ /unidadnegci1/ /accines/... Nmbre de la aplicación pryect Cntenedr de la unidad rganizativa de negci. Será una agrupación lógica de una funcinalidad a desarrllar. (pcinal, si n hay diferente unidades ) Cntenedr para tdas las clases Actin y ActinFrm y de Struts. /negci/... Cntenedr para las clases de negci (DAO, servicis y auxiliares) crrespndientes a la implementación del patrón prpuest. /mdel/... Cntenedr para ls bean de dats y ls fichers de mapping de hibernate, (hbm).... /unidadnegci2/ *... /unidadnegci3/ *... /util/... Cntendr de clases auxiliares de utilidades de alcance glbal y reutilizables. Cnjunt de clases y fichers reutilizables, resultad de la sbrecarga de struts para adaptarls a las necesidades del pryect, cntrl de seguridad, etc * La estructura de la unidad de negció se repetirá tantas veces cm unidades rganizativas de funcinalidad se presenten. Página: 13

14 3.3 CONFIGURACIÓN Ls requisits de cnfiguración a cumplir pr las aplicacines sn: Las aplicacines deberán centralizar su cnfiguración/parametrización en un únic ficher de cnfiguración XML. REQUISITOS Las aplicacines dispndrán de mecanisms para aplicar ls cambis en el ficher de cnfiguración sin necesidad de desplegar de nuev la aplicación rearrancar el servidr de aplicacines. Ls fichers de cnfiguración asciads a las diferentes librerías / tecnlgías utilizadas pr la aplicación deberán centralizarse, siempre que sea psible, en un únic directri, p. e. WEB-INF/cnf siempre y cuand sea psible. La gestión del ficher de cnfiguración se realizará mediante la librería Apache Jakarta Cmmns Cnfiguratin Además de ests requisits se deben cumplir ls requisits en cuant a cnfiguración indicads en el dcument de infrmación general para desarrlls java. A la hra de desarrllar una aplicación siempre ns encntrams cn cnstantes y valres pr defect. Incluirls en el códig es un grave errr. Cada mdificación implicaría una recmpilación del códig. Un buen códig n puede permitirse ess lujs y se hace imprescindible utilizar mecanisms que ns permitan mdificar la cnfiguración de nuestrs prgramas de manera cómda y efectiva. Tampc es cuestión de hacer nada cmplej: basta cn usar un ficher de cnfiguración. Debe existir un únic ficher de cnfiguración pr aplicación, es decir un únic punt de acces a la persnalización del cmprtamient de la aplicación, si bien est n significa que sl haya un ficher. En el directri cntenedr de ls fichers de cnfiguración se recgerá el ficher descriptr de la aplicación y el rest de fichers de cnfiguración requerids pr tercers: librerías, servidres, etc Recrdams que ls fichers de cnfiguración deben residir en el siguiente directri dentr de la estructura del pryect ya prpuest cn anteriridad en este dcument. /WebRt/ Fichers para el despliegue de la aplicación web / WEB-INF / Tda la infrmación de cnfiguración del aplicativ, que es necesaria, para ls distints cntenedres de infraestructura: Servidr web, servidr de aplicacines, /cnf/ Fichers de cnfiguración En realidad el frmat general de un ficher de cnfiguración debiera ser muy simple, tant cm sea psible ya que n sl debe de ser accesible mediante algún mecanism desde la aplicación, sin que debe pder interpretarse fácilmente cn una lectura rápida del mism. Cada línea de una sección cntiene palabras clave cn un más arguments, ests serán ls valres que parametrizarán la aplicación. Página: 14

15 Para tal prpósit vams a recurrir a describir este cnjunt de parámetrs y valres en un ficher XML teniend en cuenta las siguientes cnsideracines. 1. Ls nmbres de ls fichers y parámetrs deben seguir las mismas cnsideracines que las explicadas en el apartad de cnvencines a seguir. 2. Ls cmentaris intrducids, deben aprtar claridad, n abusar de ells intentand que el prpi ficher sea aut descriptiv. Para ell ayudará la selección adecuada de ls nmbre de ls parámetrs. 3. Ls parámetrs de cnfiguración glbales de la aplicación deberán ser ls primers en aparecer en el ficher descrits cm parámetrs. Ejempl de est sn dats cm el nmbre de la aplicación, la versión, el idima pr defect, directri para temprales, etc. 4. Ls parámetrs que hacen referencia a una misma funcinalidad deben ser incluidas en un grup de elements adecuadamente cmentads. Cm ejempl pdems hacer referencia a ls parámetrs que cnfiguran el cmprtamient del gestr de trazas. 5. Cuand existan grups funcinales deben indicarse intrduciend un nivel de anidamient más en esa estructura para agrupar claramente ls valres prpis para cada instancia. Esta es la situación que se puede presentar cuand cnfigurams las cnexines a base de dats, dnde existen más de un datasurce cuand trabajams cn crre electrónic, dnde ls dats de cnexión y cuantas pueden ser diferentes. 6. Cualquier grup funcinal debe pder ser accedid fácilmente pr su id, lueg este debe de estar siempre presente y ser léxicamente significativ. 7. Intrducir atributs de cmentari es útil y ayuda a la cmprensión del element. Para ell se utilizara desc= cmentaris. 8. Las cntraseñas deben aparecer SIEMPRE encriptadas. Seguidamente se muestra l que pdría cnsiderarse cm un ficher de cnfiguración válid para cumplir cn estas cnsideracines y puede ser utilizad cm mdel inicial para llegar a cubrir las necesidades del pryect, ampliand el mism en la medida que sea precis. Página: 15

16 <?xml versin="1.0" encding="iso "?> <system> <param id="applicatin.name" value="mi pryect"/> <param id="versin" value="1.0"/> <param id="default.lcale" value="es,es"/> <param id="temp.url" value="/"/> <param id="temp.dir" value="/usr/./temp/8829"/> <!-- lg --> <lg id="lg" desc="cnfiguración de lg4j"> <param id="path" value="/usr/ /lg"/> <param id="file" value="nmbrelg"/> <!-- active appenders --> <param id="lg4j.rtlgger" value="warn, stdut, file"/> <!-- cnsle appender setup --> <paramid="lg4j.appender.stdut" value="rg.apache.lg4j.cnsleappender"/> <param id="lg4j.appender.stdut.layut" value="rg.apache.lg4j.patternlayut"/> <param id="lg4j.appender.stdut.layut.cnversinpattern" value="%5p [%t] (%F:%L) %m%n" desc="shw filename and line number"/> <!-- file appender setup --> <param id="lg4j.appender.file" value="rg.apache.lg4j.rllingfileappender"/> <param id="lg4j.appender.file.file" value="${lg.file}"/> <param id="lg4j.appender.file.maxfilesize" value="100kb"/> <param id="lg4j.appender.file.maxbackupindex" value="4" desc="supprt fur backup"/> <param id="lg4j.appender.file.layut" value="rg.apache.lg4j.patternlayut"/> <param id="lg4j.appender.file.layut.cnversinpattern" value="%d{hh:mm:ss.sss} %-5p [%t] - %m\n"/> <! - ntificatin mail --> <param id="lg4j.ntificatin.enabled" value="true" desc="ntificacines de errr"/> <param id="lg4j.ntificatin.mail" value="admin@server.es" desc="administratr mail"/> </lg> Página: 16

17 <!-- mail --> <mail id="mail" desc="cnfiguracuión de "> <param id="smtp.hst" value="smtp.myserver.es" desc="smtp mail prtcl"/> <param id="pp3" value="pp3" desc="reveive prtcl param"/> <param id="pp3.hst" value="mail.myserver.es" desc="reveive prtcl param"/> <param id="imap" value="imap" desc="imap prtcl param"/> <param id="imap.hst" value="" desc="imap prtcl param"/> <param id="receiver.prtcl" value="pp3" desc="receive param"/> <param id="receiver.enabled" value="false" desc="receive param"/> <param id="freq" value="5000" desc="general param"/> <param id="flag.debug" value="false" desc="general param"/> <grup id="accunts" desc="grup f mail accunts"> <grup id="acc1"> <param id="address" value="user@myserver.es"/> <param id="username" value="j8dkdma1"/> <param id="passwrd" value="dkks02824k2lekd902k2m3902m2e232"/> <param id="flag.authenticatin" value="true" desc="authenticatin param"/> </grup> </grup> </mail> <!-- data base --> <database id= database desc="cnfiguración de las cnexines a BBDD"> <datasurce id= datasurce1 desc="cnexión cn el primer datasurce"> <param id="nmbre" value="nmbre del datasurce"/> <param id="usuari" value="userlgin"/> <param id="passwrd" value="alkasm093232mdsz k42"/> </datasurce> </database/>... </system> Página: 17

18 3.4 GENERACION DE TRAZAS DE LOG Una traza es una descripción real de la evlución tempral de un sistema. Para generar esta descripción se debe dispner de acces a ls parámetrs del sistema que sean relevantes. La generación de trazas se ha realizad generalmente pr medi de librerías unidades dedicadas a ese efect, tal cm LOG4J. En casines, estas unidades deben cmbinarse cn el códig del prgrama aplicación a mnitrizar y en tras puede hacerse pr medi de una cnexión al canal de cmunicación al sistema hardware. Tant de una frma cm de tra, la traza deberá mantener la crrespndiente cherencia y hmgeneidad en su creación. La mnitrización del sistema n deja de ser un métd que pueda interferir en el funcinamient del mism y en alguns cass si n se presta la debida atención a su tratamient, esta interferencia de la bservación puede resultar prblemática, dad que la generación de la traza y el almacenad en un archiv es una tarea más en el sistema. Las aplicacines deberán tener presente el cumplimient de ls siguientes requisits de trazabilidad: Las aplicacines utilizarán la librería Lg4j cm mecanism de trazad. Existirá un únic archiv lg pr aplicación, utilizándse ls mecanisms de Lg4j para gestinar su tamañ. Las trazas de las aplicacines deberán indicar cm mínim: Instante en el que es lanzada la traza. Descripción del punt exact del lanzamient de la traza: [Módul / Clase / Métd]. Mensaje de la traza. REQUISITOS Las trazas n pdrán mstrar ciert tip de infrmación cm: Infrmación que supnga un riesg de seguridad cm claves utilizadas pr ls usuaris, claves de acces a trs sistemas cm bases de dats, etc. Infrmación que vile la Ley Orgánica de Prtección de Dats (LOPD) cm dats que identifiquen menres, intervinientes, etc. Mediante parámetrs de cnfiguración las aplicacines pdrán activar un nivel de trazad de accines de BBDD que permita: Trazar las cnsultas SQL lanzadas incluyend: Cnsulta SQL cmpleta y en el cas de sentencias precmpiladas invcacines a prcedimients almacenads se deberán indicar ls parámetrs asciads a las mismas. Tiemps de preparación y/ ejecución de las cnsultas. Trazar el cicl de vida de las transaccines: inici y fin (cmmit y rllback). Página: 18

19 Auditar el estad del pl de cnexines: tamañ, cnexines libres, transaccines y asignación de cnexines a cnsultas/transaccines. En función de diferentes niveles de trazad se deberá trazar a fin de facilitar la depuración ante psibles prblemas: Inici-fin de accines y us de cmpnentes/servicis, Vlcad de errres cn nivel, númer y descripción, Vlcad de ls parámetrs de cnfiguración a fin de certificar que la aplicación está aplicand la cnfiguración deseada, Adicinalmente mandar un crre al administradr ante ciert tip de errres. Para más infrmación cnsultar el anex Generación de Trazas cn Lg4J. Página: 19

20 3.5 GESTION DE EXCEPCIONES La gestión de excepcines es un aspect integrad en el lenguaje Java. El cncept de gestión de errres cn excepcines está previst para crear códig más fiable y fácil de mantener. Java prprcina tres clases principales para el manej de cndicines excepcinales: excepcines explícitas (checked), excepcines en tiemp de ejecución (runtime) y errres (errrs). Ls errres indican un seri prblema que una aplicación n debe capturar. La mayría de ests errres sn cndicines anrmales que se prducen durante la ejecución del prgrama. Existe cierta cnfusión entre prgramadres en l referente a elegir el tip aprpiad de excepción. Aunque la decisión n siempre es clara, hay reglas generales que ayudan bastante a facilitar la elección Reglas y recmendacines La regla principal es Usar excepcines explícitas para cndicines excepcinales de las que el métd cliente puede raznablemente recuperarse. Al lanzarse una excepción cmprbada, se fuerza al métd cliente a manejar la excepción a prpagarla. Obviamente, el métd cliente puede capturar la excepción e ignrarla, l cual es nrmalmente una mala decisión (ver segunda recmendación abaj). Ls errres y las excepcines en tiemp de ejecución sn idéntics en cmprtamient: N se deben capturar. Si un prgrama lanza una excepción explícita un errr, generalmente n es psible la recuperación de dich errr y cntinuar la ejecución puede causar más dañs que beneficis. Nrmalmente, el prces en cuestión se detiene mstrand un mensaje aclaratri. La segunda regla es Usar excepcines en tiemp de ejecución para indicar errres de prgramación. La gran mayría de excepcines en tiemp de ejecución indica que se está incumpliend una precndición. Est significa que el métd cliente de una función n está cumpliend las precndicines establecidas en la especificación de la función. Pr ejempl, para acceder a un element de un array se establece que el índice debe estar cmprendid entre cer y la lngitud del array mens un. La excepción ArrayIndexOutOfBundsExceptin indica que esta precndición n se ha cumplid. Aunque la especificación del lenguaje Java n l requiere, pr cnveni ls errres están reservads para que la máquina virtual pueda indicar deficiencias de recurss, falls de invariantes u tras cndicines que hacen impsible cntinuar la ejecución. Dada la casi universal aceptación de este cnveni, es mejr n implementar una nueva subclase de Errr. Tdas las excepcines en tiemp de ejecución deberían ser subclase de RuntimeExceptin (directa indirectamente). En resumen, se deben usar excepcines explícitas para cndicines recuperables y excepcines en tiemp de ejecución para errres de prgramación. Para centrar este apartad, el cnstructr cmplet para el manej de excepcines es: try { // Códig que puede lanzar una excepción } catch (Exceptin1 e) { // Códig para manejar una cndición excepcinal } catch (Exceptin2 e) { // Códig para manejar la siguiente cndición excepcinal Página: 20

21 } finally { // Códig que se ejecuta incndicinalmente } El códig que puede lanzar una excepción va dentr de un blque try. Un blque catch se ejecutará sól si la excepción identificada curre ( una subclase de ésta). Sin embarg, el códig que va en el blque finally se ejecutará siempre. El blque try es bligatri. Adicinalmente, un de ls ds blques, catch finally, deben estar presentes, el cmpiladr l cnsiderará errr. Dad que puede haber varis blques catch, el sistema encntrará el primer que cincida cn la cndición excepcinal. Pr tant, si hay un blque catch para una excepción IOExceptin, y se prduce una excepción FileNtFundExceptin, se recgerá pr el blque que captura IOExceptin. Est sugiere una primera recmendación para la gestión de excepcines: Se debe trabajar siempre cn la excepción más específica que sea psible. Pr ejempl, si se crea un métd que pdría generar una excepción FileNtFundExceptin, n declarar que lanza una IOExceptin. Si est se hace, se fuerza al métd cliente a que maneje tdas las excepcines IOExceptin psibles, n sól FileNtFundExceptin. La segunda recmendación es evitar blques catch vacís. En tras palabras, n ignrar excepcines cuand curren. Pr ejempl: // Este códig n es aceptable. Se ignra la excepción try {... } catch (Exceptin e) {} Ls diseñadres de librerías lanzan excepcines pr una razón: Para señalar que sucedió una cndición excepcinal. Ignrar una excepción es análg a ignrar una alarma de fueg si n se hace nada, el resultad puede ser desastrs. Cm mínim, se debe guardar en una traza (lg) el mensaje. Si se quiere ignrar una excepción, quizá prque se hace un reintent autmátic que curre cada un ds minuts, l recmendable es pner un cmentari en el blque catch para aclarar que la cndición excepcinal se está ignrand. // Recmendad try {... } catch (Exceptin e) { // El sistema reintenta autmáticamente cada minut. N se hace nada hasta // el próxim reintent } La tercera recmendación es dcumentar tdas las excepcines lanzadas pr cada métd. Una descripción de las excepcines lanzadas pr un métd supne una parte imprtante de la dcumentación requerida para el us adecuad del métd. Pr tant, es crític que se dcumenten cuidadsamente tdas las excepcines lanzadas pr cada métd. La frma crrecta de dcumentar excepcines es cn el tag L recmendable es dcumentar tdas las excepcines explícitas (checked exceptins) para cada métd. Pr ejempl, en la siguiente declaración se dcumenta la excepción lanzada y la causa que prvca la excepción. N se recmienda pner sól el NmbreDeExcepción, ya que n añade más infrmación que la prprcinada pr la declaración del métd: Página: 21

22 /** * Carga la clase * name * Nmbre de clase * Objet <tt>class</tt> resultante * ClassNtFundExceptin * Si la clase n se encuentra */ public Class ladclass(string name) thrws ClassNtFundExceptin {... } La cuarta recmendación es usar encadenamient y traducción de excepcines. El encadenamient de excepcines permite vlver a lanzar una excepción, prprcinand infrmación adicinal sin perder la causa riginaria de la excepción. El encadenamient de excepcines fue intrducid en la versión 1.4 de java. El siguiente ejempl muestra cóm usar encadenamient de excepcines: try {... } catch (IOExceptin e) { thrw new EjemplDeExcepcin("Otra excepción IOExceptin", e); } Tal cm se muestra, al capturar una excepción IOExceptin, se crea una nueva excepción EjemplDeExcepcin cn la causa riginaria adjuntada la excepción IOExceptin, prpagándse la cadena de excepcines al siguiente manejadr de excepcines. Este ejempl también muestra la técnica denminada traducción de excepcines. El bjetiv de esta técnica es evitar que un métd lance una excepción que n tenga nada que ver en apariencia cn la tarea realizada. Est curre frecuentemente cuand un métd prpaga una excepción que viene de tr métd de una capa inferir. Además de descncertar, cntamina el API de la capa superir cn detalles de implementación. Si alguna vez se cambia la implementación de la capa superir, la excepción que se lanza también puede cambiar, afectand a ls prgramas cliente. Cuand sea psible, la mejr manera de tratar excepcines de capas inferires será evitarlas, asegurand que las llamadas a métds de más baj nivel siempre tengan éxit antes de invcarls. Est se puede cnseguir cmprband explícitamente la validez de ls arguments de ls métds de alt nivel antes de pasarls a capas inferires. Si n se pueden evitar las excepcines de baj nivel, l siguiente que se debe hacer es aislar al cliente de la capa superir de ls prblemas en capas inferires. En estas circunstancias, es aprpiad guardar la excepción en un lg para su psterir investigación. Hasta aquí se han enumerad las pautas principales recmendadas pr SUN. El prblema de las pautas y reglas de SUN es que n siempre funcinan en la práctica. Al final, se impne el criteri del usuari (el prgramadr, en este cas). Muchs autres recncids cm Bruce Eckel abgan pr usar cm nrma las excepcines en tiemp de ejecución, e inclus llegan a cuestinarse la prpia existencia de excepcines explícitas, cnsiderándlas un experiment fallid. ( Eckel cmenta que, cuand un examina pequeñas cantidades de códig, las excepcines explícitas parecen una Página: 22

23 idea brillante y prmeten evitar muchs errres. La experiencia, sin embarg, indica l cntrari para grandes cantidades de códig Us excesiv de excepcines explícitas El us excesiv de excepcines explícitas prvca alguns prblemas: Demasiad códig El usuari del métd está bligad a capturar excepcines explícitas que n se pueden manejar (del tip alg fue muy mal ) y puede acabar escribiend códig que las ignra (ver segunda recmendación). Códig ilegible Capturar excepcines que n pueden ser aprpiadamente manejadas y relanzarlas (envueltas en tr tip de excepción) ayuda pc y puede llegar a despistar. Nunca se termina de traducir excepcines Una excepción explícita debe ser capturada declarada en la cláusula thrws del métd que la encuentra. Est permite elegir entre relanzar un númer creciente de excepcines, capturar las excepcines de baj nivel y relanzarlas traducidas en una nueva de mayr nivel, alg deseable si se añade infrmación útil. Si pr el cntrari, la excepción de baj nivel es irrecuperable, n se cnsigue nada cn traducirla. Signaturas frágiles de métds Cuand varias clases usan un métd, añadir una nueva excepción explícita al interfaz requerirá muchs cambis de códig. Las excepcines explícitas n siempre funcinan bien cn interfaces Si se abusa de las excepcines explícitas en el diseñ de interfaces, pdems crear dependencias que n sn deseables. Un ejempl de est sería un interfaz de acces a dats que lanza una excepción IOExceptin. Si la clase que implementa el interfaz n accede a fichers y accede a una base de dats, esta excepción n tiene sentid, per está bligand al cliente a capturarla Resumen práctic L recmendad es seguir las pautas que se han dad en este dcument, per teniend en cuenta que el abus de excepcines explícitas puede acarrear prblemas. También se ha cmentad que usar excepcines explícitas n es alg que se debe decidir cuidadsamente. Pr ell, es muy imprtante dcumentar las decisines que se tmen. Página: 23

24 3.6 SOPORTE INTERNACIONALIZACIÓN REQUISITOS Las aplicacines de Justicia deberán utilizar ls mecanisms de internacinalización sprtads pr la arquitectura J2EE y en cncret pr las diferentes librerías que cmpndrán el marc tecnlógic de las aplicacines. De esta frma, tdas las cadenas de text utilizadas en la capa de presentación (etiquetas de ls cmpnentes de ls frmularis, mensajes de errr, avis, etc) se extraerán a fichers de prpiedades. El requisit de internacinalización n aplica a mensajes incluids en trazas al n ser directamente visualizads pr ls usuaris. La ubicación de ls fichers de recurss se realizará según la estructura definida en el apartad TAREAS ASINCRONAS (SCHEDULING) Las aplicacines deberán tener en cuenta que ciertas peracines cm la generación de infrmes cmplejs, pueden supner un enrme perjuici de rendimient si se realizan de frma síncrna. Para evitar ests prblemas, las aplicacines ante este tip de peracines deberán cumplir ls siguientes requisits: REQUISITOS Las aplicacines deberán prprcinar ls mecanisms para impedir que un usuari puede invcar de frma repetida una peración que supnga much tiemp de prcesamient. Las aplicacines deberán gestinar de frma asíncrna este tip de peracines, de tal frma que el usuari siempre reciba una prnta respuesta a su peración, per tenga mecanisms para saber cuand ésta ha cncluid y el estad de éxit errr de la misma. La gestión asíncrna de las peracines se realizará mediante el mecanism que ICM especifique. Página: 24

25 3.8 AUDITORIA REQUISITOS Dada la sensibilidad de ls dats que manejarán las aplicacines del Sistema de Infrmación Judicial deberán cumplir ls requisits de auditria especificads pr la Ley Orgánica de Prtección de Dats. Página: 25

26 3.9 MODELO DE SEGURIDAD Las aplicacines implementarán el mdel de seguridad que define ICM. Dich mdel incluirá las siguientes especificacines: - Identificación acces a repsitri únic de usuaris btención del DNI cm identificación de access - Autrización cntenedr de permiss que psibilite el acces pr DNI permitir que un usuari pueda tener distints perfiles baj una aplicación. El cntrl de acces a las aplicacines se realizará del siguiente md: Certificad Digital Usuari Cntraseña REQUISITOS ASF DNI LDAP DNI B.D. Centralizada USUJ Autenticación El usuari se pdrá identificar en el sistema mediante ds psibilidades: a).- Certificad Digital b).- Usuari y cntraseña Para el cas a) el aplicativ ha de validar que el certificad digital utilizad para la cnexión es válid y n está revcad, estas accines se realizarán a través de la platafrma multipki ASF dispnible en ICM. A partir del certificad digital se btendrá el DNI del usuari. Para el cas b) el aplicativ ha de validar que el usuari/cntraseña exista en el directri LDAP crrespndiente. Página: 26

27 A partir del acces a LDAP se btendrá el DNI del usuari. Autrización Hasta que n tengams el sistema RBAC definitiv, cm alternativa a este, utilizarems el repsitri de usuaris USUJ centralizad en una única base de dats dnde se almacenará tda la infrmación respect a la gestión de perfiles de usuaris para las distintas aplicacines. El sistema USUJ será cread para que permita asciar a un usuari cn varis perfiles ante una aplicación ubicada en una base de dats determinada. Prtcls de acces segur basads en HTTPS (SSL v2-v3 /TSL v1) Firma digital de dcuments a través de la platafrma multipki de ASF. Para la implementación de ls mecanisms indicads anterirmente de autenticación y autrización de usuaris se ha desarrllad un webservice denminad usuj_ws que tdas las aplicacines tienen que utilizar en lugar de implementar su prpia gestión de usuaris. En ningún cas las aplicacines pdrán acceder directamente a las tablas de usuj. Página: 27

28 3.10 ARQUITECTURA DE LAS APLICACIONES Las aplicacines deberán desarrllarse basand su capa de presentación en el Framewrk Apache Struts 1.2, el cual bliga implícitamente a utilizar patrnes de diseñ recmendads pr la especificación J2EE (J2EE Patterns) entre ls que destacan: REQUISITOS Mdel-View-Cntrller: El mdel vista cntrladr (MVC) permite independizar la presentación, de la lógica de navegación y de ls dats de la aplicacines. Frnt-Cntrller: El prcesamient de la peticines es gestinad de manera centralizada, unificand y facilitand el desarrll de plíticas de seguridad, trazabilidad entre tras. Cmpsite View: Permite gestinar la capa de presentación cm la cmpsición de múltiples vistas (encabezad, pie de página, menús, cntenid, etc). Para más infrmación cnsultar el anex Struts. Página: 28

29 3.11 CAPA PRESENTACION La capa de presentación de las aplicacines utilizará las librerías de etiquetas y funcinalidades prprcinadas pr Struts 1.2. De ellas se deducen ls siguientes requisits: Las aplicacines utilizarán la extensión Tiles para definir las estructura principal de las aplicacines (encabezad, menú, pie de página, etc) así cm cualquier tra estructura que sea reutilizada en diferentes páginas. Cualquier validación que realice la aplicación en el navegadr (cliente) deberá replicarse de lad servidr para garantizar la rbustez de la misma. REQUISITOS Las validacines básicas se realizarán usand la extensión Struts Validatr, definiéndse nuevs tips de validación en cas de ser necesari. Las validacines que sean muy específicas de un determinad frmulari pdrán realizarse directamente en Javascript en lad cliente y en Java en lad servidr, sin necesidad de usar la extensión Struts Validatr. Las funcines Javascript que sean prpias de la aplicación deberán ser extraídas a un únic ficher Javascript (ficher cn extensión.js). Ls cmpnentes gráfics avanzads requerids pr las aplicacines: menus, calendaris, pestañas, etc, deberán ser validads previamente pr ICM. En las páginas jsp nuncan se pdrá incluir códig de acces a base de dats. A fin de prprcinar un interfaz ric y evitar refrescs de página innecesaris, se prpne el us de la tecnlgía AJAX (Asynchrnus JavaScript And XML) cm mecanism de refresc de cmpnentes de una página. En el cas de us de esta tecnlgía se deberán cumplir ls siguientes requisits: Se utilizará la implementación DWR (Direct Web Remting) de AJAX. REQUISITOS La invcación de funcinalidad AJAX debe ser siempre cnsecuencia de una interacción cn el usuari, pr ejempl, al seleccinar el valr de un cmb, se carga de manera dinámica ls valres de tr. En cncret, la carga inicial de una página n debe implicar la ejecución de funcinalidad AJAX. Se debe limitar la cantidad de infrmación intercambiada mediante AJAX. Es preferible recargar la página a intercambiar mediante AJAX gran cantidad de infrmación. Se deberá simplificar el númer de clases Java de lad servidr cuys servicis/métds sean exprtads a la capa de presentación mediante AJAX, de esta frma se facilitará la depuración y se reducirá el códig Javascript autgenerad pr la librería DWR. Página: 29

30 El códig javascript estará siempre en fichers JS que además se dividirán en aquells que hace us de AJAX y ls que sn utilidades cmunes, validacines de camps, etc. El cntenid en nuestr cas será generad pr nuestras clases de negci, estas nunca deben cuparse del frmate de dats para su presentación de la generación de códig HTML. Crear cada script y bjet cn una funcinalidad cncreta en distints fichers.js, de esta frma pdrems incluir sl ls fichers necesaris en las distintas páginas, cnseguims una mayr reutilización de nuestrs cmpnentes AJAX, ptimizams el rendimient de la aplicación y facilitand el mantenimient de ls misms. Nunca se utilizará AJAX para actualización de dats en base de dats. Mantener una estructura de directris adecuada dentr de nuestra carpeta JS para un fácil mantenimient de ls scripts, la pción prpuesta para un us de AJAX cm el mencinad anterirmente es la siguiente: /WebRt/ /js/ Directri de despliegue de la aplicación Cntendr del javascript. /estandar /... /librerias/... /ajax/... Directri para nuestrs scripts de validación y utilidades que n hacen us de AJAX. Directri para incluir ls fichers de la librería DWR cualquier tra de la que se mantenga una dependencia. Aquí se incluyen scripts generales usads pr el rest de scripts AJAX Página: 30

31 3.12 CAPA LOGICA DE NEGOCIO Las aplicacines deberán implementar la lógica de negci atendiend a ls siguientes requisits: REQUISITOS La lógica se implementará en clases Java nrmales, cmúnmente cncidas cm POJOs (Plain Old Java Object), de l cual se deduce las siguientes nrmas: Se prhíbe el us de EJBs (Enterprise Java Beans). Las clases serán independientes de cualquier framewrk usad en la capa de presentación, es decir, deben ser clases independientes de las accines de Struts. Estas clases accederán a las clases de las capa de persistencia para acceder a ls dats de la base de dats CAPA PERSISTENCIA En la capa de persistencia se va a distinguir ds casuísticas: Persistencia de dats entendida cm la infrmación que se va a almacenar en la base de dats Oracle. Persistencia de dcuments referida a ls dcuments gestinads pr las aplicacines, sean n generads en el cmpsitr de dcuments. Página: 31

32 DATOS La persistencia de ls dats almacenads en la base de dats se realizará siguiend el patrón DAO (Data Access Object) y utilizand el mtr de persistencia Hibernate. El patrón DAO permite encapsular y cultar el acces a base de dats a la capa de lógica, cnsiguiéndse independizar al máxim el desarrll de las aplicacines de la implementación cncreta de la persistencia. El patrón DAO es un de ls patrnes de diseñ Standard de J2EE. DAO permite encapsular el acces y manipulación de dats en una capa separada. Esta capa gestina la cnexión cn la fuente de dats (bases de dats relacinales, fichers plans, sistema de fichers remts, etc) para btener y almacenar dichs dats, ya que implementa el mecanism de acces necesari. Independientemente del tip de fuente de dats empleada, la capa DAO siempre prprcina un API unifrme a sus clientes, cultand ls detalles de implementación a sus clientes. Esencialmente, la capa DAO actúa cm adaptadr. REQUISITOS La capa DAO se implementa sin estad. N almacena en caché resultads de ninguna cnsulta ni dats que el cliente pueda necesitar psterirmente. Est prvca que ls bjets DAO sean simples y evita prblemas ptenciales de cncurrencia. La capa DAO encapsula ls detalles de persistencia subyacentes. Pr ejempl, cuand la capa DAO accede pr JDBC, td el códig desarrllad sbre JDBC queda cultad pr la prpia capa DAO y n se prprcina a clientes ni excepcines, estructuras de dats, bjets ni interfaces que pertenezcan a ls paquetes java.sql.* javax.sql.*. Diagrama de clases (extraíd de Cre J2EE Patterns, Best Practices and Design Strategies pr Deepak Alur, Jhn Crupi y Dan Malks) Página: 32

33 Estás ideas generales se cncretan en ls siguientes requisits: Tds ls access a base de dats realizads pr las aplicacines se deberán encapsular en clases DAO. Deberá realizarse una utilización cuidadsa del mtr de persistencia Hibernate evitándse la carga en memria de estructuras cmplejas frut del mape entre el mdel de dats relacinal y el mdel rientad a bjets de Java. En el cas de que el rendimient de la aplicación se vea afectad en determinadas cnsultas pr la utilización del mtr de persistencia, se pdrá utilizar el API JDBC directamente. Este us requiere de autrización previa pr parte de ICM. Excepcinalmente se puede hacer us de la API JDBC desde la capa de persistencia, sin que se requiera autrización previa pr parte de ICM. Siempre que se cumplan las siguientes cndicines: 1. Para llamada a prcedimients almacenads. 2. La cnexión a BBDD se btendrá de la sesión de Hibernate. 3. La llamada al prcedimient almacenad debe estar mapead en una entidad de Hibernate. 4. El acces a ls parámetrs será pr nmbre y n pr índice. La frma de implementarl esta publicad en el anex sbre Hibernate. La cnfiguración de Hibernate relativa a la crrelación entre el mdel de dats relacinal y el de bjets pdrá fragmentarse en diferentes XMLs (en función de móduls entidades) a fin de facilitar su mantenimient. Tds ls DAO deberán lanzar excepcines cn significad. N deberán lanzar java.lang.exceptin, ya que es demasiad genérica y n transmite ninguna infrmación acerca de la raíz del prblema. N deberán lanzar java.sql.sqlexceptin, es una excepción JDBC de baj nivel. Un DAO deberá esfrzarse para encapsular el JDBC antes que mstrar el JDBC al rest de la aplicación. Si el códig de acces a dats captura una excepción, que n sea ignrada. Ls DAO's que ignran una excepción capturada sn prblemátics. Usar chained exceptins para cambiar excepcines de baj nivel a excepcines de alt nivel. Se activarán ls mecanisms de trazabilidad de Hibernate integrads cn Lg4j, extendiéndse en cas de ser necesaris, a fin de cumplir ls requisits de trazabilidad de las aplicacines del Sistema de Infrmación Judicial especificads previamente. Hibernate es un ptente mapeadr bjet/relacinal y servici de cnsultas para Java. Es la slución ORM (Object-Relatinal Mapping) más ppular en el mund Java. Hibernate permite desarrllar clases persistentes a partir de clases cmunes, incluyend asciación, herencia, plimrfism, cmpsición y cleccines de bjets. El lenguaje de Página: 33

34 cnsultas de Hibernate HQL (Hibernate Query Language), diseñad cm una mínima extensión rientada a bjets de SQL, prprcina un puente elegante entre ls munds de bjets y relacinal. Hibernate también permite expresar cnsultas utilizand SQL nativ cnsultas basadas en criteris. Sprta tds ls sistemas gestres de bases de dats SQL y se integra de manera elegante y sin restriccines cn ls más ppulares servidres de aplicacines J2EE y cntenedres web, y pr supuest también puede utilizarse en aplicacines standalne. Características clave: Persistencia transparente: Hibernate puede perar prprcinand persistencia de una manera transparente para el desarrlladr. Mdel de prgramación natural: Hibernate sprta el paradigma de rientación a bjets de una manera natural: herencia, plimrfism, cmpsición y el framewrk de cleccines de Java. Sprte para mdels de bjets cn una granularidad muy fina: Permite una gran variedad de mapes para cleccines y bjets dependientes. Sin necesidad de mejrar el códig cmpilad (bytecde): N es necesaria la generación de códig ni el prcesamient del bytecde en el prces de cmpilación. Escalabilidad extrema: Hibernate psee un alt rendimient, tiene una caché de ds niveles y puede ser usad en un cluster. Permite inicialización perezsa (lazy) de bjets y cleccines. Lenguaje de cnsultas HQL: Este lenguaje prprcina una independencia del SQL de cada base de dats, tant para el almacenamient de bjets cm para su recuperación. Sprte para transaccines de aplicación: Hibernate sprta transaccines largas (aquellas que requieren la interacción cn el usuari durante su ejecución) y gestina la plítica ptimistic lcking autmáticamente. Generación autmática de claves primarias: Sprta ls diverss tips de generación de identificadres que prprcinan ls sistemas gestres de bases de dats (secuencias, clumnas autincrementales,...) así cm generación independiente de la base de dats, incluyend identificadres asignads pr la aplicación claves cmpuestas. Página: 34