Download Descargar

Framework de Desarrollo de Justicia
Versión 1.2
FRAMEWORK JUSTICIA
ARQUITECTURA
APLICACIONES WEB
Versión 1.2.2
Octubre 2009
Subdirección General de Desarrollo, Tecnología e Infraestructuras.
Página: 1
Framework de Desarrollo de Justicia
Versión 1.2
CONTROL DE CAMBIOS
Fecha
Versión
22/02/2008 1.2
Cambios
Modificado apartados:
1. Requisitos Generales
2.2 Entorno de desarrollo
3.3 Estructura de directorios (2 nuevos directorios)
3.12 Modelo de seguridad
3.14 Capa presentación
10 Referencias
Eliminado apartados por encontrarse en el documento
Desarrollo en Java:
2.2 Base de Datos
3.10 Test de pruebas
3.11 Documentación
3.2 Uso de convenciones en los proyectos
03/10/2008
1.2.1
29/10/2009
1.2.2
Nuevo apartado:
8 Otras cuestiones a tener en cuenta
Indicamos la página en la que se encuentran actualizadas las
librerias de JAXB
3.13.1 DATOS: Añadido el uso de JDBC para
procedimientos almacenados.
4, Compositor de documentos: Se sube a la versión 1.5 de
Velocity.
Subdirección General de Desarrollo, Tecnología e Infraestructuras.
Página: 2
Framework de Desarrollo de Justicia
Versión 1.2
INDICE
1
2
REQUISITOS GENERALES .............................................................................. 4
REQUISITOS DEL ENTORNO.......................................................................... 5
2.1
ARQUITECTURA DE SISTEMAS ................................................................ 5
2.2
ENTORNO DE DESARROLLO ..................................................................... 7
2.3
NAVEGADORES Y POB ............................................................................... 9
2.4
REQUISITOS ARQUITECTURA J2EE ....................................................... 10
3
CARACTERISTICAS DE LAS APLICACIONES........................................... 11
3.1
ESTRUCTURA DE DIRECTORIOS ............................................................ 11
3.2
ESTRUCTURA DE PAQUETES JAVA....................................................... 13
3.3
CONFIGURACIÓN ....................................................................................... 14
3.4
GENERACION DE TRAZAS DE LOG........................................................ 18
3.5
GESTION DE EXCEPCIONES..................................................................... 20
3.5.1
Reglas y recomendaciones...................................................................... 20
3.5.2
Uso excesivo de excepciones explícitas ................................................. 23
3.5.3
Resumen práctico ................................................................................... 23
3.6
SOPORTE INTERNACIONALIZACIÓN .................................................... 24
3.7
TAREAS ASINCRONAS (SCHEDULING)................................................. 24
3.8
AUDITORIA .................................................................................................. 25
3.9
MODELO DE SEGURIDAD......................................................................... 26
3.10 ARQUITECTURA DE LAS APLICACIONES ............................................ 28
3.11 CAPA PRESENTACION .............................................................................. 29
3.12 CAPA LOGICA DE NEGOCIO .................................................................... 31
3.13 CAPA PERSISTENCIA................................................................................. 31
3.13.1
DATOS................................................................................................... 32
3.13.2
DOCUMENTOS .................................................................................... 36
4
COMPOSITOR DE DOCUMENTOS ............................................................... 39
5
TRATAMIENTO DE FICHEROS XML........................................................... 41
6
GENERACION DE INFORMES....................................................................... 42
7
INTEROPERABILIDAD CON SISTEMAS EXTERNOS ............................... 43
8
OTRAS CUESTIONES A TENER EN CUENTA ............................................ 43
9
RESUMEN ......................................................................................................... 44
10
REFERENCIAS ................................................................................................. 45
11
ANEXOS............................................................................................................ 47
Subdirección General de Desarrollo, Tecnología e Infraestructuras.
Página: 3
Framework de Desarrollo de Justicia
REQUISITOS
1
Versión 1.2
REQUISITOS GENERALES
La presente guía establece un marco de trabajo común a todas las aplicaciones que
configuran el nuevo Sistema de Información Judicial de la Comunidad de Madrid. Para
ello, define una serie de requisitos de obligado cumplimiento por cada una de las
aplicaciones, desglosado en los diferentes elementos que configuran la arquitectura de las
mismas.
Adicionalmente a los requisitos explícitamente expuestos se deben cumplir los requisitos
especificados en la normativa general para el Desarrollo de aplicaciones Java y el
siguiente requisito:

El uso de cualquier nueva tecnología, producto, librería o componente, no incluido
en la presente guía, que se desee incorporar a las aplicaciones deberá ser
consensuado previamente por ICM.
Subdirección General de Desarrollo, Tecnología e Infraestructuras.
Página: 4
Framework de Desarrollo de Justicia
2
2.1
Versión 1.2
REQUISITOS DEL ENTORNO
ARQUITECTURA DE SISTEMAS
Las aplicaciones deberán desarrollarse teniendo en cuenta que 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. Ver anexo de Arquitectura de las
Aplicaciones de Justicia.
De esta arquitectura se desprenden los siguientes requisitos a tener en cuenta en el
desarrollo de las aplicaciones:

Minimizar el uso de la sesión. Como ya sabemos, cada petición al servidor recibe
su objeto Session, donde la aplicación puede guardar y recuperar información
específica para cada usuario haciendo uso de las variables de sesión.
REQUISITOS
Aunque parece una gran idea guardar grandes objetos, como la conexión a una
base de datos en una variable de sesión y así utilizarla en todas las páginas
mejorando (en teoría) el rendimiento, esto es absolutamente falso, por varias
razones.
Cada usuario que entra en la aplicación recibe su propio objeto Session personal.
Los objetos ocupan una gran cantidad de memoria del servidor. Almacenarlos en
una variable de sesión significa que rápidamente el servidor se va a quedar sin
memoria y la ejecución de los procesos va a ser mucho más lenta. Este deterioro
además, afectaría a cualquier tipo de petición, y además si un usuario entra y sale
a los 15 segundos de la aplicación, su copia del objeto permanecerá en memoria
hasta que termine el tiempo de caducidad de sesión, perjudicando y penalizando
sin justificación al sistema.
Reducir el tiempo de caducidad de sesión para evitar el problema anterior no es
buena solución, es más, sería un error, ya que la caducidad de la sesión obligaría
probablemente a realizar un nuevo registro en la aplicación a aquellos usuarios
que permanecieran inactivos durante un tiempo mayor a ese pequeño intervalo
establecido. Hablaríamos de que la sesión ha expirado y no es posible continuar
el proceso abierto sin comenzar de nuevo.
El otro extremo contrario es mucho peor: poner un TimeOut muy elevado por si
acaso, y así mantendremos el estado 100% seguro. Esto significa que si 100
usuarios llegan al mismo tiempo y se van en 10 minutos, tienes 100 objetos
Session malgastando memoria durante el resto de tiempo, lógicamente esto es
inaceptable.
Las variables de sesión son justificables sólo en ciertos aspectos puntuales. La
mayoría de las cosas se pueden hacer sin ellas, y evitamos todos los problemas
que conlleva, con cookies, formularios y querystrings.
Subdirección General de Desarrollo, Tecnología e Infraestructuras.
Página: 5
Framework de Desarrollo de Justicia
Versión 1.2
Además, otro de los errores más comunes es guardar en variables de sesión
cosas que no son específicas para cada usuario, como cadenas de conexión a
bases de datos, algún HTML que imprimimos siempre, como pie de página... Las
variables de sesión no están pensadas para eso.
Nunca se deben incluir en sesión colecciones de objetos ya que se desconoce su
tamaño.
El tamaño de la sesión nunca podrá exceder los límites que ICM defina en base a
la arquitectura de sistemas, este limite dependerá del nº de usuarios
concurrentes.

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, como se
verá en el apartado configuración. Esta ubicación corresponderá con un directorio
compartido por las distintas maquinas que compongan el cluster. Además hay
que tener en cuenta que cada aplicación va a tener un único directorio de trabajo
exclusivo para uso de dicha aplicación.

Las aplicaciones 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.
Subdirección General de Desarrollo, Tecnología e Infraestructuras.
Página: 6
Framework de Desarrollo de Justicia
2.2
Versión 1.2
ENTORNO DE DESARROLLO
El entorno de desarrollo Java recomendado por ICM se compone de los siguientes
elementos:





Eclipse 3.1
MyEclipse Enterprise Workbench 4.1
Apache Maven 2
Checkstyle
PMD
REQUISITOS
Los proveedores podrán utilizar cualquier entorno de desarrollo aunque deberán tener en
cuenta los siguientes requisitos a la hora de realizar las entregas software:

Dado que el entorno de mantenimiento de ICM utiliza Eclipse, el software
entregado deberá incluir los ficheros de proyecto que este entorno utiliza a fin de
facilitar su compilación, depuración, etc.

Las aplicaciones deberán incluir un proyecto Maven 2 o en su defecto scripts
compatibles con la librería Apache Ant 1.6.5 que permitan realizar las operaciones
básicas como: compilación del proyecto y generación del fichero ear.
Maven es una herramienta de gestión de información de proyectos. Maven está basado en el
concepto de un modelo de objetos del proyecto POM (Project Object Model) en el que todos los
productos (artifacts) generados por Maven son el resultado de consultar un modelo de proyecto
bien definido. Compilaciones, documentación, métricas sobre el código fuente y un
innumerable número de informes son todos controlados por el POM.
Maven tiene muchos objetivos, pero resumiendo Maven intenta hacer la vida del desarrollador
sencilla proporcionando una estructura de proyecto bien definida, unos procesos de desarrollo
bien definidos a seguir, y una documentación coherente que mantiene a los desarrolladores y
clientes informados sobre lo que ocurre en el proyecto. Maven aligera en gran cantidad lo que
la mayoría de desarrolladores consideran trabajo pesado y aburrido y les permite proseguir con
la tarea. Esto es esencial en proyectos de gran alcance donde hay que realizar una labor
importante de documentación y propagación de la información crítica sobre el proyecto que es
necesaria para atraer potenciales nuevos desarrolladores y clientes.
La ambición de Maven es hacer que el desarrollo interno del proyecto sea altamente manejable
con la esperanza de proporcionar más tiempo para el desarrollo entre proyectos. Se puede
llamar polinización entre proyectos o compartir el conocimiento sobre el desarrollo del proyecto.
Características:

El modelo de objetos del proyecto POM es la base de cómo Maven trabaja. El
desarrollo y gestión del modelo está controlado desde el modelo del proyecto.

Un único conjunto de métodos son utilizados para todos los proyectos que se
gestionan. Ya no hay necesidad de estar al tanto de innumerables sistemas de
compilación. Cuando las mejoras se hacen en Maven todos los usuarios se benefician.
Subdirección General de Desarrollo, Tecnología e Infraestructuras.
Página: 7
Framework de Desarrollo de Justicia
Versión 1.2

Integración con Gump, una herramienta usada en el proyecto Jakarta para ayudar a los
proyectos a mantener compatibilidad con versiones anteriores.

Publicación del sitio web basado en el POM. Una vez el POM es exacto los
desarrolladores pueden publicar fácilmente el contenido del proyecto, incluyendo la
documentación personalizada más el amplio conjunto de documentación generada por
Maven a partir del código fuente.

Publicación de distribuciones basada en el POM.

Maven alienta el uso de un repositorio central de librerías, utilizando un mecanismo que
permite descargar automáticamente aquellas necesarias en el proyecto, lo que permite
a los usuarios de Maven reutilizar librerías entre proyectos y facilita la comunicación
entre proyectos para asegurar que la compatibilidad entre distintas versiones es
correctamente tratada.

Guías para la correcta disposición de los directorios. Maven contiene documentación
sobre como disponer los directorios de forma que una vez es aprendida se puede ver
fácilmente cualquier otro proyecto que use Maven.
Más información en el Anexo de Apache Maven 2.
Subdirección General de Desarrollo, Tecnología e Infraestructuras.
Página: 8
Framework de Desarrollo de Justicia
REQUISITOS
2.3
Versión 1.2
NAVEGADORES Y POB
La aplicación debe funcionar correctamente con el POB de Justicia 5.7.2 y superior. En el
apartado de anexos se incluyen los requisitos de dicho POB.
Además debe de ser compatible con la versiones de Navegador Internet Explorer 6.0 o
superior y Mozilla Firefox 1.4 o superior.
Subdirección General de Desarrollo, Tecnología e Infraestructuras.
Página: 9
Framework de Desarrollo de Justicia
2.4
Versión 1.2
REQUISITOS ARQUITECTURA J2EE
Las aplicaciones que componen el nuevo Sistema de Información Judicial de la
Comunidad de Madrid deberán desarrollarse según la especificación J2EE (Java 2
Enterprise Edition) deberán cumplir los siguientes requisitos:

Deben ser compatibles con la especificación J2EE en su versión 1.4, lo cual fija
las especificaciones que deben cumplirse a nivel de las diferentes tecnologías
subyacentes, entre ellas:
REQUISITOS
Especificación
J2EE (Java 2 Enterprise Edition )
Java Servlet Specification
JavaServer Pages Specification
JDBC (Java Database Connectivity)
Java Transaction API Specification
Java Transaction Service
Specification
SOAP with Attachments API for Java
Specification
JavaMail API Specification
Java Message Service Specification
Versión
1.4
2.4
2.0
Specifications, 3.0, 2.1, and
Optional Package API (2.0)
1.0.1B
1.0
1.2
1.3
1.1

Las aplicaciones 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 certificados J2EE 1.4.

Las aplicaciones no deben usar funcionalidades o tecnologías dependientes del
sistema operativo sin la previa aprobación de ICM. En concreto, las aplicaciones
deberán soportar los sistemas operativos Linux (RedHat 3.0), Solaris y
Windows2000, aunque en producción las aplicaciones se ejecutarán sobre Linux
(RedHat 3.0).
Subdirección General de Desarrollo, Tecnología e Infraestructuras.
Página: 10
Framework de Desarrollo de Justicia
3
Versión 1.2
CARACTERISTICAS DE LAS APLICACIONES
3.1
ESTRUCTURA DE DIRECTORIOS
La estructura de directorios en todo proyecto ICM debe de colgar de una carpeta con el nombre
del proyecto “/proyecto/”, este nombre se corresponde con el nombre de Midax (4 letras). Esta
será la ruta raíz del árbol de proyecto. Como dentro de un proyecto podemos tener varios
módulos para cada módulo vamos a tener la estructura de directorios que se muestra a
continuación:
Path
Descripción
/modulo/
/doc/
/api/
Contiene los ficheros de configuración XML para el despliegue
automático con ANT. En esta estructura se desarrolla el
módulo de un proyecto. También contendrá los ficheros
.classpath y .project de Eclipse.
Toda aquella información que no se pueda catalogar en la
estructura subyacente.
Javadoc del aplicativo.
/gui/
TODA la información generada por el equipo de diseño gráfico:
archivos de photoshop, de freehand, de flash, jpeg, …
/man/
TODOS los manuales: de usuario, de operación e instalación.
/req/
Documento de especificaciones (contiene los requisitos
generales, información del modelo de datos y la arquitectura
del sistema). Todas las fichas de los requisitos y las fichas de
las tareas.
Toda la documentación referente con pruebas del aplicativo:
de aceptación, de carga, checklist de errores…
Todo el modelo UML recogido en los trabajos de diseño, es el
directorio en el cual trabajo la herramienta CASE de modelado.
TODAS las librerías que necesita el aplicativo (.jar, .zip, …),
estas librerías deben de estar clasificadas en directorios según
el tipo de servicio que prestan.
Contiene todo el código fuente (.java) sin incluir el interfaz
gráfico de usuario (.jsp, .html, …).
Estructura de paquetes con el código fuente del aplicativo
(.java). Se sustituye [package] por el paquete raíz que se
defina para el sistema.
De este directorio cuelga toda la estructura de pruebas
unitarias del aplicativo (.java). Se sustituye [package] por el
paquete raíz que se defina para el sistema.
De este directorio cuelgan todos los elementos necesarios
para la ejecución de las pruebas de selenium
De este directorio cuelgan todos los elementos necesarios
para la ejecución de las pruebas de jmeter
Ficheros para el despliegue de la aplicación web
/test/
/uml/
/lib/
/src/
/java/[package]
/test/[package]
/selenium
/jmeter
/WebRoot/
/css/
Hojas de estilo del aplicativo.
/html/
Directorio contenedor de páginas HTML.
/img/
Almacén de las imágenes del proyecto. Pueden almacenarse
en directorios contenidos en este principal.
/js/
Ficheros de javascript.
Subdirección General de Desarrollo, Tecnología e Infraestructuras.
Página: 11
Framework de Desarrollo de Justicia
Versión 1.2
/estandar /
Directorio para nuestros scripts de validación y utilidades que
no hacen uso de AJAX.
/librerias/
Directorio para incluir los ficheros de la librería DWR o
cualquier otra de la que se mantenga una dependencia.
Aquí se incluyen scripts generales usados por el resto de
scripts AJAX
/ajax/
/msg/
Ficheros de traducciones (xml) para i18n.
/ WEB-INF /
Toda la información de configuración del aplicativo, que es
necesaria, para los distintos contenedores de infraestructura:
Servidor web, servidor de aplicaciones, …
Lugar para dejar las clases compiladas para que el
Classloader (en el caso de Tomcat) los pueda localizar.
/classes/
/conf/
Ficheros de configuración
/dtd/
Ficheros de DTD
/jsp/
Directorio contenedor de páginas JSP.
/lib/
Directorio de despliegue de las librerías.
/tld/
Ficheros de TLD
[url + path]/temp/
Directorio auxiliar para contener los ficheros temporales,
intermedios de las operaciones de ANT, etc... Este directorio
podrá localizarse en cualquiera de las máquinas del cluster y
podrá ser compartido por otras aplicaciones. Existirá un
procesado automático para vaciar el contenido de este
directorio en base a unas políticas temporales.
[url + path]/log/
Ficheros de log del aplicativo. Este directorio podrá localizarse
en cualquiera de las máquinas del cluster. Existirá un
procesado automático para vaciar el contenido de este
directorio en base a unas políticas temporales.
Subdirección General de Desarrollo, Tecnología e Infraestructuras.
Página: 12
Framework de Desarrollo de Justicia
3.2
Versión 1.2
ESTRUCTURA DE PAQUETES JAVA
Para los paquetes de la aplicación se empleará la siguiente estructura haciendo uso de
los caracteres en minúscula y en ningún caso podrá utilizarse el nombre del proveedor
en tal estructura:
/[nombreproyecto]/
/unidadnegocio1/
Nombre de la aplicación o proyecto
Contenedor de la unidad organizativa de negocio.
Será una agrupación lógica de una funcionalidad a
desarrollar. (opcional, si no hay diferente unidades )
/acciones/
...
Contenedor para todas
ActionForm y de Struts.
las
clases
Action
y
/negocio/
...
Contenedor para las clases de negocio (DAO,
servicios y auxiliares) correspondientes a la
implementación del patrón propuesto.
/modelo/
...
/unidadnegocio2/
...
*
/unidadnegocio3/
...
*
/util/
...
...
Contenedor para los bean de datos y los ficheros de
mapping de hibernate, (hbm).
Contendor de clases auxiliares de utilidades de
alcance global y reutilizables.
Conjunto de clases y ficheros reutilizables,
resultado de la sobrecarga de struts para adaptarlos
a las necesidades del proyecto, control de
seguridad, etc…
* La estructura de la unidad de negoció se repetirá tantas veces como unidades organizativas de
funcionalidad se presenten.
Subdirección General de Desarrollo, Tecnología e Infraestructuras.
Página: 13
Framework de Desarrollo de Justicia
3.3
Versión 1.2
CONFIGURACIÓN
REQUISITOS
Los requisitos de configuración a cumplir por las aplicaciones son:

Las aplicaciones deberán centralizar su configuración/parametrización en un
único fichero de configuración XML.

Las aplicaciones dispondrán de mecanismos para aplicar los cambios en el
fichero de configuración sin necesidad de desplegar de nuevo la aplicación o
rearrancar el servidor de aplicaciones.

Los ficheros de configuración asociados a las diferentes librerías / tecnologías
utilizadas por la aplicación deberán centralizarse, siempre que sea posible, en un
único directorio, p. e. WEB-INF/conf siempre y cuando sea posible.

La gestión del fichero de configuración se realizará mediante la librería Apache
Jakarta Commons Configuration
Además de estos requisitos se deben cumplir los requisitos en cuanto a configuración
indicados en el documento de información general para desarrollos java.
A la hora de desarrollar una aplicación siempre nos encontramos con constantes y valores por
defecto. Incluirlos en el código es un grave error. Cada modificación implicaría una
recompilación del código. Un buen código no puede permitirse esos lujos y se hace
imprescindible utilizar mecanismos que nos permitan modificar la configuración de nuestros
programas de manera cómoda y efectiva. Tampoco es cuestión de hacer nada complejo: basta
con usar un fichero de configuración.
Debe existir un único fichero de configuración por aplicación, es decir un único punto de acceso
a la personalización del comportamiento de la aplicación, si bien esto no significa que solo haya
un fichero. En el directorio contenedor de los ficheros de configuración se recogerá el fichero
descriptor de la aplicación y el resto de ficheros de configuración requeridos por terceros:
librerías, servidores, etc…
Recordamos que los ficheros de configuración deben residir en el siguiente directorio dentro de
la estructura del proyecto ya propuesto con anterioridad en este documento.
/WebRoot/
/ WEB-INF /
/conf/
Ficheros para el despliegue de la aplicación web
Toda la información de configuración del aplicativo, que es
necesaria, para los distintos contenedores de infraestructura:
Servidor web, servidor de aplicaciones, …
Ficheros de configuración
En realidad el formato general de un fichero de configuración debiera ser muy simple, tanto
como sea posible ya que no solo debe de ser accesible mediante algún mecanismo desde la
aplicación, sino que debe poder interpretarse fácilmente con una lectura rápida del mismo.
Cada línea de una sección contiene palabras clave con uno o más argumentos, estos serán los
valores que parametrizarán la aplicación.
Subdirección General de Desarrollo, Tecnología e Infraestructuras.
Página: 14
Framework de Desarrollo de Justicia
Versión 1.2
Para tal propósito vamos a recurrir a describir este conjunto de parámetros y valores en un
fichero XML teniendo en cuenta las siguientes consideraciones.
1. Los nombres de los ficheros y parámetros deben seguir las mismas consideraciones
que las explicadas en el apartado de convenciones a seguir.
2. Los comentarios introducidos, deben aportar claridad, no abusar de ellos intentando
que el propio fichero sea auto descriptivo. Para ello ayudará la selección adecuada de
los nombre de los parámetros.
3. Los parámetros de configuración globales de la aplicación deberán ser los primeros en
aparecer en el fichero descritos como parámetros. Ejemplo de esto son datos como el
nombre de la aplicación, la versión, el idioma por defecto, directorio para temporales,
etc….
4. Los parámetros que hacen referencia a una misma funcionalidad deben ser incluidas
en un grupo de elementos adecuadamente comentados. Como ejemplo podemos
hacer referencia a los parámetros que configuran el comportamiento del gestor de
trazas.
5. 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 es la situación que se puede presentar cuando configuramos las
conexiones a base de datos, donde existen más de un datasource o cuando
trabajamos con correo electrónico, donde los datos de conexión y cuantas pueden ser
diferentes.
6. Cualquier grupo funcional debe poder ser accedido fácilmente por su id, luego este
debe de estar siempre presente y ser léxicamente significativo.
7. Introducir atributos de comentario es útil y ayuda a la comprensión del elemento. Para
ello se utilizara desc=”comentarios”.
8. Las contraseñas deben aparecer SIEMPRE encriptadas.
Seguidamente se muestra lo que podría considerarse como un fichero de configuración válido
para cumplir con estas consideraciones y puede ser utilizado como modelo inicial para llegar a
cubrir las necesidades del proyecto, ampliando el mismo en la medida que sea preciso.
Subdirección General de Desarrollo, Tecnología e Infraestructuras.
Página: 15
Framework de Desarrollo de Justicia
Versión 1.2
<?xml version="1.0" encoding="ISO-8859-1"?>
<system>
<param id="application.name" value="mi proyecto"/>
<param id="version" value="1.0"/>
<param id="default.locale" value="es,ES"/>
<param id="temp.url" value="/"/>
<param id="temp.dir" value="/usr/……./temp/8829"/>
<!-- log -->
<log id="log" desc="configuración de log4j">
<param id="path" value="/usr/………/log"/>
<param id="file" value="nombrelog"/>
<!-- active appenders -->
<param id="log4j.rootLogger" value="warn, stdout, file"/>
<!-- console appender setup -->
<paramid="log4j.appender.stdout" value="org.apache.log4j.ConsoleAppender"/>
<param id="log4j.appender.stdout.layout" value="org.apache.log4j.PatternLayout"/>
<param id="log4j.appender.stdout.layout.ConversionPattern" value="%5p [%t] (%F:%L) –
%m%n" desc="show filename and line number"/>
<!-- file appender setup -->
<param id="log4j.appender.file" value="org.apache.log4j.RollingFileAppender"/>
<param id="log4j.appender.file.File" value="${log.file}"/>
<param id="log4j.appender.file.MaxFileSize" value="100KB"/>
<param id="log4j.appender.file.MaxBackupIndex" value="4" desc="support four backup"/>
<param id="log4j.appender.file.layout" value="org.apache.log4j.PatternLayout"/>
<param id="log4j.appender.file.layout.ConversionPattern" value="%d{HH:mm:ss.SSS} %-5p
[%t] - %m\n"/>
<!—- notification mail -->
<param id="log4j.notification.enabled" value="true" desc="notificaciones de error"/>
<param id="log4j.notification.mail" value="[email protected]" desc="administrator mail"/>
</log>
Subdirección General de Desarrollo, Tecnología e Infraestructuras.
Página: 16
Framework de Desarrollo de Justicia
Versión 1.2
<!-- mail -->
<mail id="mail" desc="configuracuión de e-mail">
<param id="smtp.host" value="smtp.myserver.es" desc="smtp mail protocol"/>
<param id="pop3" value="pop3" desc="reveive protocol param"/>
<param id="pop3.host" value="mail.myserver.es" desc="reveive protocol param"/>
<param id="imap" value="imap" desc="imap protocol param"/>
<param id="imap.host" value="" desc="imap protocol param"/>
<param id="receiver.protocol" value="pop3" 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"/>
<group id="accounts" desc="group of mail accounts">
<group id="acc1">
<param id="address" value="[email protected]"/>
<param id="username" value="j8dkdma1"/>
<param id="password" value="DKKS02824K2LEKD902K2M3902M2E232"/>
<param
id="flag.authentication"
value="true"
desc="authentication
param"/>
</group>
</group>
</mail>
<!-- data base -->
<database id=”database” desc="configuración de las conexiones a BBDD">
<datasource id=”datasource1” desc="Conexión con el primer datasource">
<param id="nombre" value="nombre del datasource"/>
<param id="usuario" value="userlogin"/>
<param id="password" value="ALKASM093232MDSZ89023429023K42"/>
</datasource>
</database/>
...
</system>
Subdirección General de Desarrollo, Tecnología e Infraestructuras.
Página: 17
Framework de Desarrollo de Justicia
3.4
Versión 1.2
GENERACION DE TRAZAS DE LOG
Una traza es una descripción real de la evolución temporal de un sistema. Para generar esta
descripción se debe disponer de acceso a los parámetros del sistema que sean relevantes. La
generación de trazas se ha realizado generalmente por medio de librerías o unidades
dedicadas a ese efecto, tal como LOG4J.
En ocasiones, estas unidades deben combinarse con el código del programa o aplicación a
monitorizar y en otras puede hacerse por medio de una conexión al canal de comunicación o al
sistema hardware. Tanto de una forma como de otra, la traza deberá mantener la
correspondiente coherencia y homogeneidad en su creación.
La monitorización del sistema no deja de ser un método que pueda interferir en el
funcionamiento del mismo y en algunos casos si no se presta la debida atención a su
tratamiento, esta interferencia de la observación puede resultar problemática, dado que la
generación de la traza y el almacenado en un archivo es una tarea más en el sistema.
Las aplicaciones deberán tener presente el cumplimiento de los siguientes requisitos de
trazabilidad:

Las aplicaciones utilizarán la librería Log4j como mecanismo de trazado.

Existirá un único archivo log por aplicación, utilizándose los mecanismos de Log4j
para gestionar su tamaño.

Las trazas de las aplicaciones deberán indicar como mínimo:
o
o
REQUISITOS
o

Las trazas no podrán mostrar cierto tipo de información como:
o
o

Instante en el que es lanzada la traza.
Descripción del punto exacto del lanzamiento de la traza: [Módulo / Clase
/ Método].
Mensaje de la traza.
Información que suponga un riesgo de seguridad como claves utilizadas
por los usuarios, claves de acceso a otros sistemas como bases de datos,
etc.
Información que viole la Ley Orgánica de Protección de Datos (LOPD)
como datos que identifiquen menores, intervinientes, etc.
Mediante parámetros de configuración las aplicaciones podrán activar un nivel de
trazado de acciones de BBDD que permita:
o
Trazar las consultas SQL lanzadas incluyendo:
 Consulta SQL completa y en el caso de sentencias
precompiladas o invocaciones a procedimientos almacenados se
deberán indicar los parámetros asociados a las mismas.
 Tiempos de preparación y/o ejecución de las consultas.
o
Trazar el ciclo de vida de las transacciones: inicio y fin (commit y
rollback).
Subdirección General de Desarrollo, Tecnología e Infraestructuras.
Página: 18
Framework de Desarrollo de Justicia
o

Versión 1.2
Auditar el estado del pool de conexiones: tamaño, conexiones libres,
transacciones y asignación de conexiones a consultas/transacciones.
En función de diferentes niveles de trazado se deberá trazar a fin de facilitar la
depuración ante posibles problemas:
o
o
o
o
Inicio-fin de acciones y uso de componentes/servicios,
Volcado de errores con nivel, número y descripción,
Volcado de los parámetros de configuración a fin de certificar que la
aplicación está aplicando la configuración deseada,
Adicionalmente mandar un correo al administrador ante cierto tipo de
errores.
Para más información consultar el anexo Generación de Trazas con Log4J.
Subdirección General de Desarrollo, Tecnología e Infraestructuras.
Página: 19
Framework de Desarrollo de Justicia
3.5
Versión 1.2
GESTION DE EXCEPCIONES
La gestión de excepciones es un aspecto integrado en el lenguaje Java. El concepto de gestión
de errores con excepciones está previsto para crear código más fiable y fácil de mantener.
Java proporciona tres clases principales para el manejo de condiciones excepcionales:
excepciones explícitas (checked), excepciones en tiempo de ejecución (runtime) y errores
(errors).
Los errores indican un serio problema que una aplicación no debe capturar. La mayoría de
estos errores son condiciones anormales que se producen durante la ejecución del programa.
Existe cierta confusión entre programadores en lo referente a elegir el tipo apropiado de
excepción. Aunque la decisión no siempre es clara, hay reglas generales que ayudan bastante
a facilitar la elección.
3.5.1
Reglas y recomendaciones
La regla principal es “Usar excepciones explícitas para condiciones excepcionales de las
que el método cliente puede razonablemente recuperarse”. Al lanzarse una excepción
comprobada, se fuerza al método cliente a manejar la excepción o a propagarla. Obviamente,
el método cliente puede capturar la excepción e ignorarla, lo cual es normalmente una mala
decisión (ver segunda recomendación abajo).
Los errores y las excepciones en tiempo de ejecución son idénticos en comportamiento: No se
deben capturar. Si un programa lanza una excepción explícita o un error, generalmente no es
posible la recuperación de dicho error y continuar la ejecución puede causar más daños que
beneficios. Normalmente, el proceso en cuestión se detiene mostrando un mensaje aclaratorio.
La segunda regla es “Usar excepciones en tiempo de ejecución para indicar errores de
programación”. La gran mayoría de excepciones en tiempo de ejecución indica que se está
incumpliendo una precondición. Esto significa que el método cliente de una función no está
cumpliendo las precondiciones establecidas en la especificación de la función. Por ejemplo,
para acceder a un elemento de un array se establece que el índice debe estar comprendido
entre cero y la longitud del array menos uno. La excepción ArrayIndexOutOfBoundsException
indica que esta precondición no se ha cumplido.
Aunque la especificación del lenguaje Java no lo requiere, por convenio los errores están
reservados para que la máquina virtual pueda indicar deficiencias de recursos, fallos de
invariantes u otras condiciones que hacen imposible continuar la ejecución. Dada la casi
universal aceptación de este convenio, es mejor no implementar una nueva subclase de Error.
Todas las excepciones en tiempo de ejecución deberían ser subclase de RuntimeException
(directa o indirectamente).
En resumen, se deben usar excepciones explícitas para condiciones recuperables y
excepciones en tiempo de ejecución para errores de programación.
Para centrar este apartado, el constructor completo para el manejo de excepciones es:
try {
//
} catch
//
} catch
//
Código que puede lanzar una excepción
(Exception1 e) {
Código para manejar una condición excepcional
(Exception2 e) {
Código para manejar la siguiente condición excepcional
Subdirección General de Desarrollo, Tecnología e Infraestructuras.
Página: 20
Framework de Desarrollo de Justicia
Versión 1.2
} finally {
// Código que se ejecuta incondicionalmente
}
El código que puede lanzar una excepción va dentro de un bloque try. Un bloque catch se
ejecutará sólo si la excepción identificada ocurre (o una subclase de ésta). Sin embargo, el
código que va en el bloque finally se ejecutará siempre.
El bloque try es obligatorio. Adicionalmente, uno de los dos bloques, catch o finally, deben estar
presentes, o el compilador lo considerará error. Dado que puede haber varios bloques catch, el
sistema encontrará el primero que coincida con la condición excepcional. Por tanto, si hay un
bloque catch para una excepción IOException, y se produce una excepción
FileNotFoundException, se recogerá por el bloque que captura IOException.
Esto sugiere una primera recomendación para la gestión de excepciones: Se debe trabajar
siempre con la excepción más específica que sea posible. Por ejemplo, si se crea un método
que podría generar una excepción FileNotFoundException, no declarar que lanza una
IOException. Si esto se hace, se fuerza al método cliente a que maneje todas las excepciones
IOException posibles, no sólo FileNotFoundException.
La segunda recomendación es evitar bloques catch vacíos. En otras palabras, no ignorar
excepciones cuando ocurren. Por ejemplo:
// Este código no es aceptable. Se ignora la excepción
try {
...
} catch (Exception e) {}
Los diseñadores de librerías lanzan excepciones por una razón: Para señalar que sucedió una
condición excepcional. Ignorar una excepción es análogo a ignorar una alarma de fuego – si no
se hace nada, el resultado puede ser desastroso. Como mínimo, se debe guardar en una traza
(log) el mensaje.
Si se quiere ignorar una excepción, quizá porque se hace un reintento automático que ocurre
cada uno o dos minutos, lo recomendable es poner un comentario en el bloque catch para
aclarar que la condición excepcional se está ignorando.
// Recomendado
try {
...
} catch (Exception e) {
// El sistema reintenta automáticamente cada minuto. No se hace
nada hasta
// el próximo reintento
}
La tercera recomendación es documentar todas las excepciones lanzadas por cada método.
Una descripción de las excepciones lanzadas por un método supone una parte importante de la
documentación requerida para el uso adecuado del método. Por tanto, es crítico que se
documenten cuidadosamente todas las excepciones lanzadas por cada método.
La forma correcta de documentar excepciones es con el tag javadoc @throws. Lo
recomendable es documentar todas las excepciones “explícitas” (checked exceptions) para
cada método. Por ejemplo, en la siguiente declaración se documenta la excepción lanzada y la
causa que provoca la excepción. No se recomienda poner sólo el fragmento @throws
NombreDeExcepción, ya que no añade más información que la proporcionada por la
declaración del método:
Subdirección General de Desarrollo, Tecnología e Infraestructuras.
Página: 21
Framework de Desarrollo de Justicia
Versión 1.2
/**
* Carga la clase
*
* @param name
*
Nombre de clase
*
* @return Objeto <tt>Class</tt> resultante
*
* @throws ClassNotFoundException
*
Si la clase no se encuentra
*/
public Class loadClass(String name)
throws ClassNotFoundException {
...
}
La cuarta recomendación es usar encadenamiento y traducción de excepciones.
El encadenamiento de excepciones permite volver a lanzar una excepción, proporcionando
información adicional sin perder la causa originaria de la excepción. El encadenamiento de
excepciones fue introducido en la versión 1.4 de java.
El siguiente ejemplo muestra cómo usar encadenamiento de excepciones:
try {
...
} catch (IOException e) {
throw new EjemploDeExcepcion("Otra excepción IOException",
e);
}
Tal como se muestra, al capturar una excepción IOException, se crea una nueva excepción
EjemploDeExcepcion con la causa originaria adjuntada – la excepción IOException,
propagándose la cadena de excepciones al siguiente manejador de excepciones.
Este ejemplo también muestra la técnica denominada “traducción de excepciones”. El
objetivo de esta técnica es evitar que un método lance una excepción que no tenga nada que
ver en apariencia con la tarea realizada. Esto ocurre frecuentemente cuando un método
propaga una excepción que viene de otro método de una capa inferior. Además de
desconcertar, contamina el API de la capa superior con detalles de implementación. Si alguna
vez se cambia la implementación de la capa superior, la excepción que se lanza también puede
cambiar, afectando a los programas cliente.
Cuando sea posible, la mejor manera de tratar excepciones de capas inferiores será evitarlas,
asegurando que las llamadas a métodos de más bajo nivel siempre tengan éxito antes de
invocarlos. Esto se puede conseguir comprobando explícitamente la validez de los argumentos
de los métodos de alto nivel antes de pasarlos a capas inferiores. Si no se pueden evitar las
excepciones de bajo nivel, lo siguiente que se debe hacer es aislar al cliente de la capa
superior de los problemas en capas inferiores. En estas circunstancias, es apropiado guardar la
excepción en un log para su posterior investigación.
Hasta aquí se han enumerado las pautas principales recomendadas por SUN. El problema de
las pautas y reglas de SUN es que no siempre funcionan en la práctica. Al final, se impone el
criterio del usuario (el programador, en este caso). Muchos autores reconocidos como Bruce
Eckel abogan por usar como norma las excepciones en tiempo de ejecución, e incluso llegan a
cuestionarse la propia existencia de excepciones explícitas, considerándolas un experimento
fallido. (http://www.mindview.net/Etc/Discussions/CheckedExceptions). Eckel comenta que,
cuando uno examina pequeñas cantidades de código, las excepciones explícitas parecen una
Subdirección General de Desarrollo, Tecnología e Infraestructuras.
Página: 22
Framework de Desarrollo de Justicia
Versión 1.2
idea brillante y prometen evitar muchos errores. La experiencia, sin embargo, indica lo contrario
para grandes cantidades de código.
3.5.2
Uso excesivo de excepciones explícitas
El uso excesivo de excepciones explícitas provoca algunos problemas:
 Demasiado código
El usuario del método está obligado a capturar excepciones explícitas que no se pueden
manejar (del tipo “algo fue muy mal”) y puede acabar escribiendo código que las ignora (ver
segunda recomendación).
 Código ilegible
Capturar excepciones que no pueden ser apropiadamente manejadas y relanzarlas
(envueltas en otro tipo de excepción) ayuda poco y puede llegar a despistar.
 Nunca se termina de traducir excepciones
Una excepción explícita debe ser capturada o declarada en la cláusula throws del método
que la encuentra. Esto permite elegir entre relanzar un número creciente de excepciones, o
capturar las excepciones de bajo nivel y relanzarlas traducidas en una nueva de mayor
nivel, algo deseable si se añade información útil. Si por el contrario, la excepción de bajo
nivel es irrecuperable, no se consigue nada con traducirla.
 Signaturas frágiles de métodos
Cuando varias clases usan un método, añadir una nueva excepción explícita al interfaz
requerirá muchos cambios de código.
 Las excepciones explícitas no siempre funcionan bien con interfaces
Si se abusa de las excepciones explícitas en el diseño de interfaces, podemos crear
dependencias que no son deseables. Un ejemplo de esto sería un interfaz de acceso a
datos que lanza una excepción IOException. Si la clase que implementa el interfaz no
accede a ficheros y accede a una base de datos, esta excepción no tiene sentido, pero
está obligando al cliente a capturarla.
3.5.3
Resumen práctico
Lo recomendado es seguir las pautas que se han dado en este documento, pero teniendo
en cuenta que el abuso de excepciones explícitas puede acarrear problemas. También se
ha comentado que usar excepciones explícitas o no es algo que se debe decidir
cuidadosamente. Por ello, es muy importante documentar las decisiones que se tomen.
Subdirección General de Desarrollo, Tecnología e Infraestructuras.
Página: 23
Framework de Desarrollo de Justicia
REQUISITOS
3.6
Versión 1.2
SOPORTE INTERNACIONALIZACIÓN
Las aplicaciones de Justicia deberán utilizar los mecanismos de internacionalización
soportados por la arquitectura J2EE y en concreto por las diferentes librerías que
compondrán el marco tecnológico de las aplicaciones. De esta forma, todas las cadenas
de texto utilizadas en la capa de presentación (etiquetas de los componentes de los
formularios, mensajes de error, aviso, etc) se extraerán a ficheros de propiedades.
El requisito de internacionalización no aplica a mensajes incluidos en trazas al no ser
directamente visualizados por los usuarios.
La ubicación de los ficheros de recursos se realizará según la estructura definida en el
apartado 3.1.
3.7
TAREAS ASINCRONAS (SCHEDULING)
Las aplicaciones deberán tener en cuenta que ciertas operaciones como la generación de
informes complejos, pueden suponer un enorme perjuicio de rendimiento si se realizan de
forma síncrona.
REQUISITOS
Para evitar estos problemas, las aplicaciones ante este tipo de operaciones deberán
cumplir los siguientes requisitos:

Las aplicaciones deberán proporcionar los mecanismos para impedir que un
usuario puede invocar de forma repetida una operación que suponga mucho
tiempo de procesamiento.

Las aplicaciones deberán gestionar de forma asíncrona este tipo de operaciones,
de tal forma que el usuario siempre reciba una pronta respuesta a su operación,
pero tenga mecanismos para saber cuando ésta ha concluido y el estado de éxito
o error de la misma.

La gestión asíncrona de las operaciones se realizará mediante el mecanismo que
ICM especifique.
Subdirección General de Desarrollo, Tecnología e Infraestructuras.
Página: 24
Framework de Desarrollo de Justicia
REQUISITOS
3.8
Versión 1.2
AUDITORIA
Dada la sensibilidad de los datos que manejarán las aplicaciones del Sistema de
Información Judicial deberán cumplir los requisitos de auditoria especificados por la Ley
Orgánica de Protección de Datos.
Subdirección General de Desarrollo, Tecnología e Infraestructuras.
Página: 25
Framework de Desarrollo de Justicia
3.9
Versión 1.2
MODELO DE SEGURIDAD
Las aplicaciones implementarán el modelo de seguridad que define ICM. Dicho modelo
incluirá las siguientes especificaciones:
-
Identificación
o acceso a repositorio único de usuarios
o obtención del DNI como identificación de accesos
-
Autorización
o contenedor de permisos que posibilite el acceso por DNI
o permitir que un usuario pueda tener distintos perfiles bajo una aplicación.
El control de acceso a las aplicaciones se realizará del siguiente modo:
Usuario
Contraseña
REQUISITOS
Certificado Digital
LDAP
ASF
DNI
DNI
B.D. Centralizada
USUJ
Autenticación
El usuario se podrá identificar en el sistema mediante dos posibilidades:
a).- Certificado Digital
b).- Usuario y contraseña
Para el caso a) el aplicativo ha de validar que el certificado digital utilizado para la
conexión es válido y no está revocado, estas acciones se realizarán a través de la
plataforma multiPKI ASF disponible en ICM.
A partir del certificado digital se obtendrá el DNI del usuario.
Para el caso b) el aplicativo ha de validar que el usuario/contraseña exista en el directorio
LDAP correspondiente.
Subdirección General de Desarrollo, Tecnología e Infraestructuras.
Página: 26
Framework de Desarrollo de Justicia
Versión 1.2
A partir del acceso a LDAP se obtendrá el DNI del usuario.
Autorización
Hasta que no tengamos el sistema RBAC definitivo, como alternativa a este, utilizaremos
el repositorio de usuarios USUJ centralizado en una única base de datos donde se
almacenará toda la información respecto a la gestión de perfiles de usuarios para las
distintas aplicaciones.
El sistema USUJ será creado para que permita asociar a un usuario con varios perfiles
ante una aplicación ubicada en una base de datos determinada.


Protocolos de acceso seguro basados en HTTPS (SSL v2-v3 /TSL v1)
Firma digital de documentos a través de la plataforma multiPKI de ASF.
Para la implementación de los mecanismos indicados anteriormente de autenticación y
autorización de usuarios se ha desarrollado un webservice denominado usuj_ws que
todas las aplicaciones tienen que utilizar en lugar de implementar su propia gestión de
usuarios. En ningún caso las aplicaciones podrán acceder directamente a las tablas de
usuj.
Subdirección General de Desarrollo, Tecnología e Infraestructuras.
Página: 27
Framework de Desarrollo de Justicia
Versión 1.2
3.10 ARQUITECTURA DE LAS APLICACIONES
REQUISITOS
Las aplicaciones deberán desarrollarse basando su capa de presentación en el
Framework Apache Struts 1.2, el cual obliga implícitamente a utilizar patrones de diseño
recomendados por la especificación J2EE (J2EE Patterns) entre los que destacan:

Model-View-Controller: El modelo vista controlador (MVC) permite independizar la
presentación, de la lógica de navegación y de los datos de la aplicaciones.

Front-Controller: El procesamiento de la peticiones es gestionado de manera
centralizada, unificando y facilitando el desarrollo de políticas de seguridad,
trazabilidad entre otras.

Composite View: Permite gestionar la capa de presentación como la composición
de múltiples vistas (encabezado, pie de página, menús, contenido, etc).
Para más información consultar el anexo Struts.
Subdirección General de Desarrollo, Tecnología e Infraestructuras.
Página: 28
Framework de Desarrollo de Justicia
Versión 1.2
3.11 CAPA PRESENTACION
REQUISITOS
La capa de presentación de las aplicaciones utilizará las librerías de etiquetas y
funcionalidades proporcionadas por Struts 1.2. De ellas se deducen los siguientes
requisitos:

Las aplicaciones utilizarán la extensión Tiles para definir las estructura principal
de las aplicaciones (encabezado, menú, pie de página, etc) así como cualquier
otra estructura que sea reutilizada en diferentes páginas.

Cualquier validación que realice la aplicación en el navegador (cliente) deberá
replicarse de lado servidor para garantizar la robustez de la misma.

Las validaciones básicas se realizarán usando la extensión Struts Validator,
definiéndose nuevos tipos de validación en caso de ser necesario.

Las validaciones que sean muy específicas de un determinado formulario podrán
realizarse directamente en Javascript en lado cliente y en Java en lado servidor,
sin necesidad de usar la extensión Struts Validator.

Las funciones Javascript que sean propias de la aplicación deberán ser extraídas
a un único fichero Javascript (fichero con extensión .js).

Los componentes gráficos avanzados requeridos por las aplicaciones: menus,
calendarios, pestañas, etc, deberán ser validados previamente por ICM.

En las páginas jsp nuncan se podrá incluir código de acceso a base de datos.
A fin de proporcionar un interfaz rico y evitar refrescos de página innecesarios, se propone
el uso de la tecnología AJAX (Asynchronous JavaScript And XML) como mecanismo de
refresco de componentes de una página.
REQUISITOS
En el caso de uso de esta tecnología se deberán cumplir los siguientes requisitos:

Se utilizará la implementación DWR (Direct Web Remoting) de AJAX.

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.

Se debe limitar la cantidad de información intercambiada mediante AJAX. Es
preferible recargar la página a intercambiar mediante AJAX gran cantidad de
información.

Se deberá simplificar el número de clases Java de lado servidor cuyos
servicios/métodos sean exportados a la capa de presentación mediante AJAX, de
esta forma se facilitará la depuración y se reducirá el código Javascript
autogenerado por la librería DWR.
Subdirección General de Desarrollo, Tecnología e Infraestructuras.
Página: 29
Framework de Desarrollo de Justicia
Versión 1.2

El código javascript estará siempre en ficheros JS que además se dividirán en
aquellos que hace uso de AJAX y los que son utilidades comunes, validaciones
de campos, etc.

El contenido en nuestro caso será generado por nuestras clases de negocio,
estas nunca deben ocuparse del formateo de datos para su presentación o de la
generación de código HTML.

Crear cada script y objeto con una funcionalidad concreta en distintos ficheros .js,
de esta forma podremos incluir solo los ficheros necesarios en las distintas
páginas, conseguimos una mayor reutilización de nuestros componentes AJAX,
optimizamos el rendimiento de la aplicación y facilitando el mantenimiento de los
mismos.

Nunca se utilizará AJAX para actualización de datos en base de datos.

Mantener una estructura de directorios adecuada dentro de nuestra carpeta JS
para un fácil mantenimiento de los scripts, la opción propuesta para un uso de
AJAX como el mencionado anteriormente es la siguiente:
Directorio de despliegue de la aplicación
/WebRoot/
/js/
Contendor del javascript.
/estandar /
...
Directorio para nuestros scripts de validación y
utilidades que no hacen uso de AJAX.
/librerias/
...
Directorio para incluir los ficheros de la librería
DWR o cualquier otra de la que se mantenga
una dependencia.
/ajax/
...
Aquí se incluyen scripts generales usados por
el resto de scripts AJAX
Subdirección General de Desarrollo, Tecnología e Infraestructuras.
Página: 30
Framework de Desarrollo de Justicia
Versión 1.2
3.12 CAPA LOGICA DE NEGOCIO
Las aplicaciones deberán implementar la lógica de negocio atendiendo a los siguientes
requisitos:
REQUISITOS

La lógica se implementará en clases Java normales, comúnmente conocidas
como POJOs (Plain Old Java Object), de lo cual se deduce las siguientes normas:
o
Se prohíbe el uso de EJBs (Enterprise Java Beans).
o
Las clases serán independientes de cualquier framework usado en la
capa de presentación, es decir, deben ser clases independientes de las
acciones de Struts.
o
Estas clases accederán a las clases de las capa de persistencia para
acceder a los datos de la base de datos.
3.13 CAPA PERSISTENCIA
En la capa de persistencia se va a distinguir dos casuísticas:


Persistencia de datos entendida como la información que se va a almacenar en la base
de datos Oracle.
Persistencia de documentos referida a los documentos gestionados por las
aplicaciones, sean o no generados en el compositor de documentos.
Subdirección General de Desarrollo, Tecnología e Infraestructuras.
Página: 31
Framework de Desarrollo de Justicia
Versión 1.2
3.13.1 DATOS
La persistencia de los datos almacenados en la base de datos se realizará siguiendo el
patrón DAO (Data Access Object) y utilizando el motor de persistencia Hibernate.
El patrón DAO permite encapsular y ocultar el acceso a base de datos a la capa de lógica,
consiguiéndose independizar al máximo el desarrollo de las aplicaciones de la
implementación concreta de la persistencia.
REQUISITOS
El patrón DAO es uno de los patrones de diseño Standard de J2EE. 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 a sus clientes. Esencialmente, la capa DAO actúa como
adaptador.
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. La capa DAO
encapsula los detalles de persistencia subyacentes. Por ejemplo, cuando la capa DAO
accede por JDBC, todo el código desarrollado sobre JDBC queda ocultado por la propia
capa DAO y no se proporciona a clientes ni excepciones, estructuras de datos, objetos ni
interfaces que pertenezcan a los paquetes java.sql.* o javax.sql.*.
Diagrama de clases (extraído de “Core J2EE Patterns, Best Practices and Design
Strategies” por Deepak Alur, John Crupi y Dan Malks)
Subdirección General de Desarrollo, Tecnología e Infraestructuras.
Página: 32
Framework de Desarrollo de Justicia
Versión 1.2
Estás ideas generales se concretan en los siguientes requisitos:

Todos los accesos a base de datos realizados por las aplicaciones se deberán
encapsular en clases DAO.

Deberá realizarse una utilización cuidadosa del motor de persistencia Hibernate
evitándose la carga en memoria de estructuras complejas fruto del mapeo entre el
modelo de datos relacional y el modelo orientado a objetos de Java.

En el caso de que el rendimiento de la aplicación se vea afectado en
determinadas consultas por la utilización del motor de persistencia, se podrá
utilizar el API JDBC directamente. Este uso requiere de autorización previa por
parte de ICM.

Excepcionalmente se puede hacer uso de la API JDBC desde la capa de
persistencia, sin que se requiera autorización previa por parte de ICM. Siempre
que se cumplan las siguientes condiciones:
1. Para llamada a procedimientos almacenados.
2. La conexión a BBDD se obtendrá de la sesión de Hibernate.
3. La llamada al procedimiento almacenado debe estar mapeado en una entidad
de Hibernate.
4. El acceso a los parámetros será por nombre y no por índice.
La forma de implementarlo esta publicado en el anexo sobre Hibernate.

La configuración de Hibernate relativa a la correlación entre el modelo de datos
relacional y el de objetos podrá fragmentarse en diferentes XMLs (en función de
módulos o entidades) a fin de facilitar su mantenimiento.

Todos los DAO deberán lanzar excepciones con significado. No deberán lanzar
java.lang.Exception, ya que es demasiado genérica y no transmite ninguna
información acerca de la raíz del problema. No deberán lanzar
java.sql.SQLException, es una excepción JDBC de bajo nivel. Un DAO deberá
esforzarse para encapsular el JDBC antes que mostrar el JDBC al resto de la
aplicación.

Si el código de acceso a datos captura una excepción, que no sea ignorada. Los
DAO's que ignoran una excepción capturada son problemáticos.

Usar chained exceptions para cambiar excepciones de bajo nivel a excepciones
de alto nivel.
Se activarán los mecanismos de trazabilidad de Hibernate integrados con Log4j,
extendiéndose en caso de ser necesarios, a fin de cumplir los requisitos de trazabilidad de
las aplicaciones del Sistema de Información Judicial especificados previamente.
Hibernate es un potente mapeador objeto/relacional y servicio de consultas para Java. Es la
solución ORM (Object-Relational Mapping) más popular en el mundo 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
Subdirección General de Desarrollo, Tecnología e Infraestructuras.
Página: 33
Framework de Desarrollo de Justicia
Versión 1.2
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 elegante y
sin restricciones con los más populares servidores de aplicaciones J2EE y contenedores web, y
por supuesto también puede utilizarse en aplicaciones standalone.
Características clave:
o
Persistencia transparente: Hibernate puede operar proporcionando persistencia de
una manera transparente para el desarrollador.
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.
o
Soporte para modelos de objetos con una granularidad muy fina: Permite una
gran variedad de mapeos para colecciones y objetos dependientes.
o
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.
o
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.
o
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.
o
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.
o
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.
Subdirección General de Desarrollo, Tecnología e Infraestructuras.
Página: 34
Framework de Desarrollo de Justicia
Versión 1.2
Para más información consultar el anexo Hibernate.
Subdirección General de Desarrollo, Tecnología e Infraestructuras.
Página: 35
Framework de Desarrollo de Justicia
Versión 1.2
REQUISITOS
3.13.2 DOCUMENTOS
Para la persistencia de los documentos se utilizará el repositorio de Centera, teniendo en
cuenta que Centera es un repositorio final de documentos. El uso de Centera para
documentos de carácter temporal no es el adecuado ya que Centera mantiene estos
documentos durante largos periodos de tiempo según la configuración realizada en el
repositorio donde estos se alojen.
Para el almacenado y recuperación de documentos en este repositorio se dispone de un
API java.
En el caso de que sea necesaria la utilización de un gestor documental o que sea preciso
localizar documentos en base al contenido del mismo, se estudiará una solución en ICM.
Como funciona CENTERA - Perspectiva de la aplicación
Centera 3G
Servidor/es
El Objeto se envía
a Centera vía API
sobre IP
El Objeto es creado o
utilizado por la
aplicación
Se devuelve la
dirección por
Contenido a la
aplicación
Centera genera
una dirección
única por
contenido
La Dirección por
Contenido se retiene para
futuras referencias de la
aplicación
© 2005 EMC Corporation. All rights reserved.
9
Centera es un buen gestor documental, robusto y con altas prestaciones para el
almacenamiento de grandes volúmenes de información. Es adecuado para entornos que
requieran un alto grado de seguridad ya que garantizan la estabilidad de los datos y buena
respuesta frente a operaciones de escritura y recuperación de documentos.
También cabe destacar que paralelo a este sistema de almacenamiento es necesario disponer
de un control de identificadores de documentos y dotarle de algún mecanismo de seguridad a
este registro, ya que el único punto de entrada para recuperar un documento es a través de
este número de identificador que se le asigna de forma automática al almacenar el documento,
y en caso de perder esta referencia sería imposible recuperar ese documento.
Existe una consola de administración para realizar ciertas operaciones de mantenimiento del
gestor, si bien es poco elaborada y el gestor en si no permite muchas operaciones.
Subdirección General de Desarrollo, Tecnología e Infraestructuras.
Página: 36
Framework de Desarrollo de Justicia
Versión 1.2
Para conectar con el gestor documental se requiere el EMC Centera API, que nos facilitará la
funcionalidad necesaria para realizar operaciones de almacenado y recuperación de ficheros,
así como llegar a poder trabajar con ciertos metadatos asociados al fichero con el que se está
trabajando.
La implementación del API de Centera es dependiente del sistema operativo y esta disponible
para los siguientes:
o
o
o
o
o
o
o
AIX
HP-UX
Iris
Linux
Solaris
Windows
z/OS
En Centera se trabajara con el objeto C-Clip para almacenar ficheros y es recomendable añadir
información específica del fichero en forma de metadatos para poder posteriormente
consultarlos. Esto lo obtenemos mediante el uso de FPClip_SetDescriptionAttribute()
y de FPClip_GetDescriptionAttribute().
Centera almacena internamente los ficheros junto con sus metadatos o por separado
dependiendo del valor del parámetro embeddedBlobsize. EL valor de este parámetro
indicará el tamaño para el cual los ficheros de menor tamaño se almacenarán conjuntamente y
los mayores por separado. Para obtener un mejor rendimiento es aconsejable que el valor de
este parámetro sea 10000.
En resumen, lo más importante a tener en cuenta quizás sea el tratamiento del id asociado al
fichero que nos devuelve el API cuando guardemos el fichero y entender Centera como un gran
repositorio con operaciones de grabado, lectura y borrado siendo estas realmente sencillas
como se muestra en el siguiente ejemplo que acompaña al empaquetado del API.
/**
* almacenaFichero
*
* @param filename
* @return clipID
* @throws FPLibraryException
*/
private static String almacenaFichero(String filename)throws FPLibraryException {
long retentionPeriod = 0;
String clipID = "";
String CLIP_NAME = "store-content-file";
String VENDOR_NAME = "EMC";
String APP_NAME = "storeContentExample";
String APP_VERSION = "2.3";
String TAG_NAME = "StoreContentObject";
try { // crea un nuevo C-Clip
FPClip theClip = new FPClip(thePool, CLIP_NAME);
theClip.setDescriptionAttribute("app-vendor", VENDOR_NAME);
theClip.setDescriptionAttribute("app-name", APP_NAME);
theClip.setDescriptionAttribute("app-version", APP_VERSION);
theClip.setRetentionPeriod(retentionPeriod);
FPFileInputStream inputStream = new FPFileInputStream(new File(filename));
FPTag topTag = theClip.getTopTag();
FPTag newTag = new FPTag(topTag, TAG_NAME);
topTag.Close();
newTag.setAttribute("filename", filename);
newTag.BlobWrite(inputStream);
clipID = theClip.Write();
System.out.println("Clip almacenado con id: " + clipID + ".");
inputStream.close();
Subdirección General de Desarrollo, Tecnología e Infraestructuras.
Página: 37
Framework de Desarrollo de Justicia
Versión 1.2
newTag.Close();
theClip.Close();
} catch (FileNotFoundException e) {
throw new IllegalArgumentException("No se puede abrir el fichero " + filename);
} catch (IOException e) {
System.err.println("Error leyendo del fichero " + filename);
e.printStackTrace();
}
return (clipID);
}
Subdirección General de Desarrollo, Tecnología e Infraestructuras.
Página: 38
Framework de Desarrollo de Justicia
4
Versión 1.2
COMPOSITOR DE DOCUMENTOS
Para la composición de documentos se va a utilizar Velocity 1.5.
Velocity 1.5 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 Modelo de la aplicación es dónde se va a realizar la fusión de las
plantillas utilizando el API Java de Velocity 1.5. 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.
REQUISITOS
En el desarrollo del compositor de documentos hay que tener en cuenta los siguientes
requisitos:

Las plantillas se crearan en formato RTF y los documentos generados
también va a ser RTF

Tanto las plantillas como los documentos se almacenarán en Centera. Este
punto se explica en el apartado correspondiente a persistencia de datos .

Se deberán utilizar los mecanismos que incorpora Velocity para que utilice
Log4J para los logs que se generen en el uso de esta librería.

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.

Utilizar sintaxis de etiquetas simple, escapando de notaciones más complejas
a no ser que esté justificada claramente su utilización.

No anidar bucles en la medida de lo posible. Estos procesos interactivos
complican los procesos de renderizado.

Hacer uso de las estructura de datos estándar: string, list y map. Su
procesado es rápido y eficaz.

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.
Subdirección General de Desarrollo, Tecnología e Infraestructuras.
Página: 39
Framework de Desarrollo de Justicia
Versión 1.2

Escapar de utilizar llamadas a macros de manera recursiva.

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 en
compositor de documentos solo realice la tarea de renderizado, la de
“dibujar” el documento.

Complementando a la anterior cabe insistir en la necesidad de que los datos
que alimentan la plantilla, deben de ir adecuadamente tratados y
formateados.
Subdirección General de Desarrollo, Tecnología e Infraestructuras.
Página: 40
Framework de Desarrollo de Justicia
5
Versión 1.2
TRATAMIENTO DE FICHEROS XML
Cuando las aplicaciones necesiten trabajar con ficheros XML, tanto para generarlos como
para leerlos, se utilizará el JAXB (Java Architecture for XML Binding ) que nos
proporciona un modo de mapear un esquema de un fichero xml con su representación en
clases Java.
REQUISITOS
.
Partiendo de un fichero de esquema de definición de xml se compilara y se generan las
correspondientes clases Java de la estructura definida en el esquema. Estas clases Java
se incorporan al proyecto.
Cuando se quiere leer un documento XML hay que realizar un unmarshal del fichero.
Cuando se quiere generar un documento XML hay que realizar un marshal del fichero.
Además nos permite validar los documentos XML.
Las versiones actualizadas de JAXB se encuentra la página web
https://jaxb.dev.java.net/
Va a realizar el mapeo de un fichero de datos en formato XML a un modelo de objeto, a
un bean de Java. La ventaja del objeto java es la facilidad de uso que presenta su
interfaz, muy conocido y posibilidad de serial izarlo para propagarlo en un entorno
clusterizado.
Para pasar al modelo de objetos (creación del bean), se requerirá de la definición de un
esquema XML para definir un mapeo en el que figurará la correlación entre el fichero de
datos y el objeto.
Este fichero de mapeo no soporta un DTD pero si incorpora la comprobación de la sintaxis
que nos garantizará su corrección. Esto es una gran ventaja.
La implementación de referencia utiliza SAX para parsear el documento lo que aporta un
menor consumo de memoria. El bean construido de XML ocupa menos que un árbol de
DOM.
Subdirección General de Desarrollo, Tecnología e Infraestructuras.
Página: 41
Framework de Desarrollo de Justicia
Versión 1.2
Una gran ventaja es la gran variedad de documentación disponible en castellano y con
muchos ejemplos.
Una amplia documentación puede encontrarse en las siguientes direcciones:
http://java.sun.com/webservices/jaxb/
http://java.sun.com/webservices/jaxb/faq.html
http://java.sun.com/webservices/docs/1.4/tutorial/doc/index.html
6
GENERACION DE INFORMES
La solución que se ha de utilizar para la generación de informes o listados es Crystal
Reports XI utilizando el Java Reporting Component. El Java Reporting Component (JRC)
se proporciona con las distribuciones de Crystal Reports XI Developer y Advanced
Developer.
El JRC es una solución de reporting en Java que procesa informes para ser visualizados o
exportados. Este componente debe ser utilizado en un servidor de aplicaciones Java y
puede ser usado para añadir funcionalidad de informes a aplicaciones Java sin la
necesidad de desplegar componentes como BusinessObjects Enterprise.
REQUISITOS
Aspectos del Java Reporting Component

Solución 100% Java que se ejecuta completamente dentro de un servidor de
aplicaciones Java.

Visualizador de informes en DHTML.

Visualizador de partes de un informe.

Soporta la capacidad enviar dinámicamente información a un report.

Soporta la capacidad de desde programación de cambiar la base de datos del
informe.

Soporta exportación a formatos RTF y PDF.
A la hora de utilizar el JRC hay que tener en cuenta los siguientes requisitos:



Los reports definidos deberán tener la extensión .rpt.
Serán incluidos en una carpeta que se encontrará dentro del ear de la
aplicación.
El api del JRC se utilizará en las clases Java del modelo y no en las jsp de la
capa de presentación.
Para más información consultar el anexo Crystal Reports XI.
Subdirección General de Desarrollo, Tecnología e Infraestructuras.
Página: 42
Versión 1.2
INTEROPERABILIDAD CON SISTEMAS EXTERNOS
Para comunicarse con Sistemas Externos se desarrollaran webservices apoyándose en el
la implementación SOAP del servidor de aplicaciones.
8
OTRAS CUESTIONES A TENER EN CUENTA
REQUISITOS
7
REQUISITOS
Framework de Desarrollo de Justicia
Además deberán cumplir los requisitos de seguridad que ICM defina en el modelo de
seguridad a adoptar para el Sistema de Información Judicial, es decir la firma del mensaje
SOAP se realizará a través de la plataforma multipki ASF utilizando el estandar XMLDSig.

En el caso de almacenar la sesión en Base de Datos no se debe utilizar la
variable JSESSION ID ya que el valor de esta variable no es único para los
dos nodos del cluster. La aplicación deberá generar un identificador único
cada vez que se cree una nueva sesión. Este identificador se debería meter
como una cookie de sesión para que se replique en todos los nodos del
cluster. El valor de esta cookie es el que va a identificar la sesión.

Se debe utilizar el fichero WEBLOGIC.XML que ICM suministre para los
desarrollos. (Este fichero estará disponible en la web de soja.
Subdirección General de Desarrollo, Tecnología e Infraestructuras.
Página: 43
Framework de Desarrollo de Justicia
9
Versión 1.2
RESUMEN
REQUISITO
SOLUCIÓN BASE
VERSION
AJAX
Direct Web Remoting (DWR)
1.0 ó 1.1 beta
Almacenamiento de
Documentos
Centera
3.0
Build tool
Maven 2 ó
Apache Ant 1.6.5
Compositor de
documentos
Apache Velocity
1.5
Configuración
Apache Jakarta Commons
Configuration
1.1
Documentación
Javadoc
Entrega del proyecto
Eclipse
Eclipse 3.1
Informes
Crystal Reports Java Reporting
Component
Crystal Reports
Developer
Devoloper XI
Modelo-VistaControlador
Apache Struts
1.2.x
Persistencia de
Datos
Hibernate
3.1.1
Test de pruebas
JUnit
StructsTestCase
Pruebas de carga y
stress
Apache JMeter
Tratamiento de
ficheros xml
JAXB (Java JWDP)
2.0
Trazabilidad
Apache Log4j
1.2.13 ó 1.2.x
Subdirección General de Desarrollo, Tecnología e Infraestructuras.
Página: 44
Framework de Desarrollo de Justicia
Versión 1.2
10 REFERENCIAS
PRODUCTO
URL
Ant
http://ant.apache.org/
Apache Maven
2
http://maven.apache.org/
Centera
http://www.emc.com/products/systems/centera.jsp
http://lighthouse.emc.com/portal/index.php
Crystal Reports
http://www.businessobjects.com/products/dev_zone/java/
DWR
http://getahead.ltd.uk/dwr/
Eclipse
http://www.eclipse.org/
Especificaciones
J2EE























J2EE Platform Specification 1.4
J2EE Connector Specification 1.5
J2EE Deployment API Specification 1.1
J2EE Management Specification 1.0
ECperf 1.1
Enterprise JavaBeans Specification 2.1
Enterprise JavaBeans to CORBA Mapping 1.1
Java API for XML Processing Specification 1.2
Java API for XML Registries Specification 1.0
Java API for XML-based RPC Specification 1.1
Java Authorization Contract for Containers 1.0
Java IDL API
Java Naming and Directory Interface Specification 1.2.1
Java Message Service Specification 1.1
Java Servlet Specification 2.4
Java Transaction API Specification 1.0.1B
Java Transaction Service Specification 1.0
JDBC Specifications, 3.0, 2.1, and Optional Package API
(2.0)
JavaBeans Activation Framework Specification 1.0.2
JavaMail API Specification 1.3
JavaServer Pages Specification 2.0
RMI over IIOP
SOAP with Attachments API for Java Specification 1.2
Hibernate
http://www.hibernate.org/
JAXB
http://java.sun.com/webservices/jaxb/
http://java.sun.com/webservices/jaxb/about.html
http://java.sun.com/webservices/jwsdp/index.jsp
Subdirección General de Desarrollo, Tecnología e Infraestructuras.
Página: 45
Framework de Desarrollo de Justicia
PRODUCTO
Versión 1.2
URL
JMeter
http://jakarta.apache.org/jmeter/
Selenium
http://selenium.openqa.org/
JUnit
http://junit.sourceforge.net/
Log4j
http://logging.apache.org/log4j/
MyEclipse
http://www.myeclipseide.com/
Struts
http://struts.apache.org/
StrutsTestCase
http://strutstestcase.sourceforge.net/
Tiles
http://struts.apache.org/struts-tiles/index.html
Velocity
http://jakarta.apache.org/velocity
Ckechstyle
http://checkstyle.sourceforge.net/index.html
PMD
http://pmd.sourceforge.net/
Subdirección General de Desarrollo, Tecnología e Infraestructuras.
Página: 46
Framework de Desarrollo de Justicia
Versión 1.2
11 ANEXOS













Guía de Estilo (PPT)
Nomenclatura de Oracle
Plantillas Word de Documentos del Área de Proyectos de Desarrollo. (carpeta Oficina
de Proyectos)
Guía de Erwin (GuiaDiseñoERWIN.DOC)
Detalle requisitos del POB
Arquitectura de Sistemas (Arquitectura.doc)
Apache Maven 2
Convenciones
Generación de trazas en Log4J
Test de pruebas
Struts
Hibernate
Crystal Reports XI
Subdirección General de Desarrollo, Tecnología e Infraestructuras.
Página: 47