Tipo de documento:
Descripción Técnica
Código del documento
2014-Interoperatividad_RedAbogacia-
v1_5.doc
Revisión
1.5
Fecha
04/12/2014
Página 1 de 47
Descripción Técnica
Interoperatividad Portal
Back to top
RedAbogacia
Descripción Técnica
Tipo de documento
Descripción Técnica
Código del documento
2014-Interoperatividad_RedAbogacia-v1_5.doc
Revisión
5
Nº total de páginas
47
Elaborado por
Dpto.Sistemas IT-CGAE
Modificaciones respecto a la versión anterior
Lista de distribución
Integradores de aplicaciones, Archivo Proyecto.
Revisado por:
Revisado por:
Aprobado por:
Firma
P.P.
Firma
Firma
Fecha
11-02-14
Fecha
Fecha
Tipo de documento:
Descripción Técnica
Código del documento
2014-Interoperatividad_RedAbogacia-
v1_5.doc
Revisión
1.5
Fecha
04/12/2014
Página 2 de 47
Back to top
Control de documentación
Histórico de versiones
Versión
Fecha
Documentos sustituidos / descripción / detalles
1.0
23/02/2004
Elaboración inicial del documento.
1.1
15/06/2004
Revisión 1. En ella se incluyen las características que deben cumplir las
aplicaciones Tipo II y Tipo III.
1.2
12/07/2004
Revisión 2. Se cambia la estructura del documento y se completa las
aplicaciones Tipo I.
1.3
01/03/2006
Revisión 3. Se cambia la estructura del documento y se añade el
módulo de Test.
1.4
11/02/2014
Revisión 4. Se añade las características de un nuevo tipo de aplicación
externa Tipo VI.
1.5
0412/2014
Revisión 5. Se actualiza la información sobre cómo una aplicación que
es invocada desde la intranet puede llegar a obtener la información del
certificado con el que se ha autenticado el usuario. Actualización de las
versiones de los diferentes productos que se utilizan en el portal
Cambios desde la última versión
Revisión 5. Se actualiza la información sobre cómo una aplicación que es
invocada desde la intranet puede llegar a obtener la información del certificado
(nombre y apellidos, si es abogado o personal, Nº DNI, nº colegiado en su caso…)
con el que se ha autenticado el usuario. Actualización de las versiones de los
diferentes productos que se utilizan en el portal.
Control de difusión
Propietario:
Dpto. IT-Abogacía
Aprobado por:
Fecha:
Distribución:
Documentación base para desarrolladores.
Referencias de archivo
Dpto. IT-Abogacía - CGAE
Pº Recoletos, 13 - 28004 Madrid
División de Dirección de Proyectos
Localización:
CLÁUSULA de CONFIDENCIALIDAD
Este documento ha sido generado para uso exclusivo del
legítimo receptor y su contenido es confidencial. Este
documento no puede ser difundido a terceros, ni utilizado
para otros propósitos que los que han originado su entrega,
sin el previo consentimiento del IT-CGAE. El propietario del
documento no podrá ser considerado responsable de
eventuales errores u omisiones en la edición del documento.
Tipo de documento:
Descripción Técnica
Código del documento
2014-Interoperatividad_RedAbogacia-
v1_5.doc
Revisión
1.5
Fecha
04/12/2014
Página 3 de 47
Tipo de documento:
Descripción Técnica
Código del documento
2014-Interoperatividad_RedAbogacia-
v1_5.doc
Revisión
1.5
Fecha
04/12/2014
Página 4 de 47
Back to top
Índice
1
INTRODUCCIÓN....................................................................................................................................... 6
1.1
OBJETIVO........................................................................................................................................... 6
1.2
ALCANCE ........................................................................................................................................... 6
1.3
ABREVIATURAS Y DEFINICIONES ............................................................................................... 7
1.3.1
ABREVIATURAS.............................................................................................................................. 7
1.3.2
DEFINICIONES............................................................................................................................... 7
2
TIPOS DE APLICACIONES..................................................................................................................... 8
2.1
APLICACIONES EXTERNAS............................................................................................................ 8
2.1.1
Aplicaciones Tipo 2. –Aplicaciones Externas o Independientes ...................................................... 8
2.1.2
Aplicaciones Tipo 6. –Aplicaciones Externas Con dependencias del Portal ................................... 8
2.2
APLICACIONES CENTRALIZADAS................................................................................................ 9
2.2.1
Aplicaciones Tipo 1. –Aplicaciones CENTRALIZADAS (acs) ......................................................... 9
2.2.2
Aplicaciones Tipo 3.......................................................................................................................... 9
2.2.3
Aplicaciones Tipo 4.......................................................................................................................... 9
2.2.4
Aplicaciones Tipo 5.......................................................................................................................... 9
3
RESUMEN DE ESPECIFICACIONES .................................................................................................. 10
3.1
ARQUITECTURA ............................................................................................................................. 10
3.2
FRAMEWORK .................................................................................................................................. 11
3.3
MULTILENGUAJE ........................................................................................................................... 12
3.4
INSTALACIÓN ................................................................................................................................. 12
4
01 -ESPECIFICACIONES DE ARQUITECTURA ............................................................................... 12
4.1
REQ-ARQ-01-001: ARQUITECTURA J2EE.................................................................................... 12
4.1.1
DESCRIPCIÓN .............................................................................................................................. 12
4.1.2
DETALLE....................................................................................................................................... 13
4.2
REQ-ARQ-01-002: FRONT END...................................................................................................... 14
4.2.1
DESCRIPCIÓN .............................................................................................................................. 14
4.2.2
DETALLE....................................................................................................................................... 14
4.3
REQ-ARQ-01-003: FRAMEWORK .................................................................................................. 14
4.3.1
DESCRIPCIÓN .............................................................................................................................. 14
4.3.2
DETALLE....................................................................................................................................... 14
4.4
REQ-ARQ-01-004: MODELO-VISTA-CONTROLADOR (MVC) .................................................. 14
4.4.1
DESCRIPCIÓN .............................................................................................................................. 14
4.4.2
DETALLE....................................................................................................................................... 15
4.5
REQ-ARQ-01-005: BASE DE DATOS.............................................................................................. 16
4.5.1
DESCRIPCIÓN .............................................................................................................................. 16
4.5.2
DETALLE....................................................................................................................................... 16
5
02 -ESPECIFICACIONES DE FRAMEWORK .................................................................................... 17
5.1
REQ-COR-02-001: MÓDULOS FUNCIONALES ............................................................................ 17
5.1.1
DESCRIPCIÓN .............................................................................................................................. 17
5.1.2
DETALLE....................................................................................................................................... 18
5.2
REQ-COR-02-002: ACCESO A BASE DE DATOS.......................................................................... 18
5.2.1
DESCRIPCIÓN .............................................................................................................................. 18
5.2.2
DETALLE....................................................................................................................................... 18
5.3
REQ-COR-02-003: GENERACION DE TRAZAS ............................................................................ 18
5.3.1
DESCRIPCIÓN .............................................................................................................................. 18
Tipo de documento:
Descripción Técnica
Código del documento
2014-Interoperatividad_RedAbogacia-
v1_5.doc
Revisión
1.5
Fecha
04/12/2014
Página 5 de 47
5.3.2
DETALLE....................................................................................................................................... 19
5.4
REQ-COR-02-004: MANEJO DE STRUTS ...................................................................................... 19
5.4.1
DESCRIPCIÓN .............................................................................................................................. 19
5.4.2
DETALLE....................................................................................................................................... 19
5.5
REQ-COR-02-005: GESTIÓN DE CACHÉ....................................................................................... 19
5.5.1
DESCRIPCIÓN .............................................................................................................................. 19
5.5.2
DETALLE....................................................................................................................................... 19
5.6
REQ-COR-02-006: INTERNACIONALIZACIÓN ........................................................................... 19
5.6.1
DESCRIPCIÓN .............................................................................................................................. 19
5.6.2
DETALLE....................................................................................................................................... 20
5.7
REQ-COR-02-008: SEGURIDAD ..................................................................................................... 20
5.7.1
DESCRIPCIÓN .............................................................................................................................. 20
5.7.2
DETALLE....................................................................................................................................... 20
5.8
REQ-COR-02-009: SESIÓN .............................................................................................................. 22
5.8.1
DESCRIPCIÓN .............................................................................................................................. 22
5.8.2
DETALLE....................................................................................................................................... 22
5.9
REQ-COR-02-010: CONFIGURABILIDAD .................................................................................... 22
5.9.1
DESCRIPCIÓN .............................................................................................................................. 22
5.9.2
DETALLE....................................................................................................................................... 22
5.10
REQ-COR-02-011: UTILIDADES GENÉRICAS ............................................................................. 23
5.10.1
DESCRIPCIÓN.......................................................................................................................... 23
5.10.2
DETALLE .................................................................................................................................. 23
5.11
REQ-COR-02-012: MAIL.................................................................................................................. 23
5.11.1
DESCRIPCIÓN.......................................................................................................................... 23
5.11.2
DETALLE .................................................................................................................................. 23
6
03 -ESPECIFICACIONES MULTILENGUAJE ................................................................................... 24
6.1
REQ-MLG-03-001: IDIOMA POR DEFECTO ................................................................................. 24
6.1.1
DESCRIPCIÓN .............................................................................................................................. 24
6.1.2
DETALLE....................................................................................................................................... 24
6.2
REQ-MLG-03-002: IDIOMAS SOPORTADOS................................................................................ 24
6.2.1
DESCRIPCIÓN .............................................................................................................................. 24
6.2.2
DETALLE....................................................................................................................................... 24
6.3
REQ-MLG-03-003: CODIFICACIÓN DE CADENAS DE CARÁCTERES..................................... 25
6.3.1
DESCRIPCIÓN .............................................................................................................................. 25
6.3.2
DETALLE....................................................................................................................................... 25
6.4
REQ-MLG-03-004: IMÁGENES CON TEXTO................................................................................ 25
6.4.1
DESCRIPCIÓN .............................................................................................................................. 25
6.4.2
DETALLE....................................................................................................................................... 25
7
04 -ESPECIFICACIONES INSTALACIÓN .......................................................................................... 26
7.1
REQ-INS-04-001: REQUERIMIENTOS DE LA APLICACIÓN...................................................... 26
7.1.1
DESCRIPCIÓN .............................................................................................................................. 26
7.1.2
DETALLE....................................................................................................................................... 26
7.2
REQ-INS-04-002: ALTA DE LA APLICACIÓN EN EL SISTEMA................................................. 27
7.2.1
DESCRIPCIÓN .............................................................................................................................. 27
7.2.2
DETALLE....................................................................................................................................... 28
8
05 -ESPECIFICACIONES DE UTILIZACIÓN DE LAS EXTENSIONES DEL CORE .................. 37
8.1
UTILIZACIÓN DE LA EXTENSIÓN MAIL .................................................................................... 37
8.2
UTILIZACIÓN DE LA EXTENSIÓN ACCESO A BASE DE DATOS ............................................ 40
8.3
UTILIZACIÓN DE LA EXTENSIÓN CERTIFICADO .................................................................... 43
8.4
UTILIZACIÓN DE LA EXTENSIÓN LOG4J..................................................................................... 44
9
DOCUMENTACIÓN DE REFERENCIA .............................................................................................. 47
Tipo de documento:
Descripción Técnica
Código del documento
2014-Interoperatividad_RedAbogacia-
v1_5.doc
Revisión
1.5
Fecha
04/12/2014
Página 6 de 47
Back to top
1 INTRODUCCIÓN
1.1
OBJETIVO
El objetivo de este documento es enumerar y describir todos los requisitos que deberán cumplir las
aplicaciones que vayan a integrarse en el portal Red de Abogacía.
1.2
ALCANCE
La elaboración de este documento se enmarca dentro del proyecto Red de Abogacía. Dado que una
de las posibilidades es la introducción de aplicaciones con una administración de usuarios y perfiles
centralizada a nivel de portal, este documento recogerá todos los requisitos que deben cumplir estas
aplicaciones.
Tipo de documento:
Descripción Técnica
Código del documento
2014-Interoperatividad_RedAbogacia-
v1_5.doc
Revisión
1.5
Fecha
04/12/2014
Página 7 de 47
1.3
ABREVIATURAS Y DEFINICIONES
1.3.1 ABREVIATURAS
ABREVIATURA
1.3.1.1.1
DESCRIPCIÓN
CGAE
Consejo General de la Abogacía Española.
ICA
Ilustre Colegio de Abogados.
......
1.3.2 DEFINICIONES
NOMBRE
1.3.2.1.1
DESCRIPCIÓN
ZONA PÚBLICA
Parte del Portal Red de Abogacía accesible a cualquier usuario, esté
o no autorizado.
ZONA PRIVADA
Zona de cada ICA residente en el Portal y que tiene acceso
restringido a los usuarios autorizados por dicho ICA.
AREA UNIVERSAL
Zona pública de cada zona privada a la que tiene acceso cualquier
usuario que acceda a dicha zona privada.
ÁREA PROPIA
Zona particularizada para cada ICA dentro de su zona privada y la
que solo tienen acceso los usuarios autorizados.
MODULO FUNCIONAL
Cada uno de los subsistemas, con funcionalidad propia, en que se
subdivide el sistema principal (Portal Red Abogacía).
APLICACIÓN
CENTRALIZADA
Aplicaciones totalmente integradas en el portal Red de Abogacía,
cuya administración de usuarios y perfiles se realiza de modo
centralizado desde el portal.
APLICACIÓN
EXTERNA
Aplicaciones que por sus especiales características no están
integradas en el portal y este únicamente contiene un link que
permite acceder a ellas.
FUNCIONALIDAD
Cada una de las subdivisiones básicas e indivisibles de las que se
compone un módulo funcional.
PERFIL
Conjunto de funcionalidades de un módulo funcional a las que se
restringe el acceso.
ROL
Conjunto de perfiles por sistema.
......
Tipo de documento:
Descripción Técnica
Código del documento
2014-Interoperatividad_RedAbogacia-
v1_5.doc
Revisión
1.5
Fecha
04/12/2014
Página 8 de 47
Back to top
2 TIPOS DE APLICACIONES
El portal Red Abogacía está concebido para servir de soporte o plataforma para aplicativos Web
desarrollados para el uso masivo de letrados pertenecientes a colegios inscritos dentro del proyecto
Red Abogacía.
Las ventajas de tener un conjunto de aplicaciones montadas sobre una misma plataforma son:
?
Administración centralizada de Usuarios, Perfiles y Roles.
?
Eficiencia en el mantenimiento de aplicaciones.
Se diferenciarán dos tipos de aplicaciones, externas y centralizadas, en función del grado de
integración en el portal.
2.1
APLICACIONES EXTERNAS
2.1.1 Aplicaciones Tipo 2. –Aplicaciones Externas o Independientes
Son aquellas aplicaciones que por sus características particulares no están integradas en el portal y
no se administran ni los perfiles ni los roles. En este caso el Portal es la plataforma de acceso a las
mismas a través de un link, y en el momento en el que se invocan pierde el control sobre las mismas.
Estas aplicaciones podrán estar alojadas dentro de la red del CGAE o fuera de ella.
Dentro de estas aplicaciones se pueden distinguir dos tipos:
a. Aplicaciones que no requieren autologado
?
Son aquellas aplicaciones que no tienen
ninguna restricción de acceso y autenticación, y simplemente pulsando en el link se accede
a las mismas.
b. Aplicaciones que requieren autologado
?
Son aquellas que requieren la introducción de
un Usuario y una Contraseña para poder acceder a ellas. En este caso el portal privado
ofrece la posibilidad de gestionar el acceso para usuarios que estén dados de alta en el
portal. Si los códigos de Usuario y Contraseña han sido almacenados previamente en el
sistema, el usuario que haya accedido mediante certificado digital a una zona privada podrá
acceder a este tipo de aplicación sin más que pulsar sobre el correspondiente link, haciendo
la validación transparente al usuario.
2.1.2 Aplicaciones Tipo 6. –Aplicaciones Externas Con dependencias
del Portal
Son aquellas aplicaciones que por sus características particulares no están integradas en el portal y
no se administran ni los perfiles ni los roles. En este caso el Portal es la plataforma de acceso a las
mismas a través de un link, y en el momento en el que se invoca pierde el control sobre las mismas.
Este tipo aplicaciones necesitan saber que la llamada proviene del Portal. Para ello se les manda un
parámetro que servirá de identificación cuando las aplicaciones comprueben que la llamada se hace
desde el portal.
Tipo de documento:
Descripción Técnica
Código del documento
2014-Interoperatividad_RedAbogacia-
v1_5.doc
Revisión
1.5
Fecha
04/12/2014
Página 9 de 47
2.2
APLICACIONES CENTRALIZADAS
Son aquellas que están integradas dentro del Portal Red Abogacía, con una gestión de usuarios,
roles y perfiles centralizada.
2.2.1 Aplicaciones Tipo 1. –Aplicaciones CENTRALIZADAS (acs)
Son aquellas aplicaciones integradas dentro del portal. Estas aplicaciones se ejecutarán dentro del
Portal Privado de RED ABOGACIA. El portal generará los menús dependiendo del perfilado del
usuario.
Estas aplicaciones a su vez podrán clasificarse en los siguientes tipos:
a.
Aplicaciones Externas (ACSE)
?
Son aplicaciones que no están desplegadas en el
Servidor de aplicaciones de Portal Red Abogacía o aún estando desplegadas en el mismo
servidor no utilizan el núcleo propio de Portal.
b.
Aplicaciones Internas (ACSI)
?
Son aplicaciones que están desplegadas en el Servidor de
aplicaciones Portal Red Abogacía y que están totalmente integradas en el mismo, utilizando
partes de núcleo.
2.2.2 Aplicaciones Tipo 3
Son aquellas aplicaciones integradas dentro del portal. Estas aplicaciones se ejecutarán dentro del
Portal Privado de RED ABOGACIA. El portal generará los menús dependiendo del perfilado del
usuario.
2.2.3 Aplicaciones Tipo 4.
Son aquellas aplicaciones que están integradas dentro del portal y que requieren de un action
específico para su correcto funcionamiento. Ejemplo
Docushare
.
2.2.4 Aplicaciones Tipo 5.
Son aplicaciones que están integradas dentro del portal y que tiene servicios que dependen unos de
otros. Ejemplo
Correos
.
Tipo de documento:
Descripción Técnica
Código del documento
2014-Interoperatividad_RedAbogacia-
v1_5.doc
Revisión
1.5
Fecha
04/12/2014
Página 10 de 47
Back to top
3 RESUMEN DE ESPECIFICACIONES
3.1
ARQUITECTURA
Requerimiento
Nombre
Descripción
REQ-ARQ-01-001
ARQUITECTURA J2EE
Las aplicaciones centralizadas del portal Red de
Abogacía cumplirán el estándar J2EE para
desarrollo de aplicaciones. El servidor de
Aplicaciones a utilizar será
Oracle WebLogic
Server 12c
por lo que además deberá cumplir los
propios de WEBLOGIC, tales como descriptores
propios del servidor.
REQ-ARQ-01-002
FRONT-END
Las aplicaciones tendrán un módulo Front-End
que estará ubicado en el servidor Web IIS 6.
REQ-ARQ-01-003
FRAMEWORK
El portal Red de Abogacía dispondrá de un
FRAMEWORK o núcleo compuesto por paquetes
de funcionalidades genéricas y reutilizables.
Entre estos paquetes se puede citar: Acceso a la
BBDD, Generación de Logs, Configuración de
properties, Utilización de una Cache propia , etc.
REQ-ARQ-01-004
MODELO-VISTA-
CONTROLADOR (MVC)
EL patrón de diseño utilizado en el portal red
abogacía es el Modelo-Vista-Controlador (MVC),
por lo que se recomienda que las aplicaciones
que vayan a ser integradas como aplicaciones
centralizadas utilicen este patrón.
REQ-ARQ-01-005
BASE DE DATOS
Cada aplicación podrá utilizar un espacio
reservado en el Servidor de Base de Datos para
el despliegue de tablas e índices que se necesite
para implementar la lógica de Negocio.
Tipo de documento:
Descripción Técnica
Código del documento
2014-Interoperatividad_RedAbogacia-
v1_5.doc
Revisión
1.5
Fecha
04/12/2014
Página 11 de 47
3.2
FRAMEWORK
Requerimiento
Nombre
Descripción
REQ-COR-02-001
MÓDULOS FUNCIONALES Las aplicaciones a desarrollar, para integrarlas en
el Portal Red de Abogacía, deberán utilizar el
núcleo funcional proporcionado para su perfecta
integración en el mismo.
REQ-COR-02-002
ACCESO A BASE DE
DATOS
El núcleo ofrecerá una interfaz para el acceso a
base de datos, de forma que las particularidades
de las diferentes fuentes de datos soportadas no
afecten a la lógica de negocio de la aplicación a
integrar en el portal.
REQ-COR-02-003 GENERACIÓN DE TRAZAS El núcleo ofrecerá un módulo de trazas o logs
configurable desde base de datos o desde un
fichero de properties. Permitirá escribir diferentes
niveles de trazas con una estructura definida,
facilitando la interpretación de las mismas y
optimizando el mantenimiento de la aplicación.
REQ-COR-02-004
MANEJO DE STRUTS
El
núcleo
ofrecerá
una
interfaz
para
la
manipulación de acciones, proporcionando la
‘información genérica para el desarrollo del
‘action’ particular de la funcionalidad de la lógica
de negocio y recubriendo y controlando los
acceso y posibles errores.
REQ-COR-02-005
GESTIÓN DE CACHÉ
El núcleo ofrecerá una interfaz para el acceso y
manipulación de una caché propia del portal.
REQ-COR-02-006
INTERNACIONALIZACIÓN El núcleo ofrecerá una interfaz para dar soporte a
la internacionalización de la aplicación, ya que el
portal es multilingüe.
REQ-COR-02-007
FILTROS
El núcleo ofrecerá una serie de filtros para
recoger toda la funcionalidad común a cualquier
acceso a la aplicación.
REQ-COR-02-008
SEGURIDAD
El núcleo ofrecerá la implementación de los
mecanismos de seguridad a aplicar a cualquier
aplicación a integrar en el sistema, siendo
transparente para la misma. Estos mecanismos
incluirán el manejo de certificados, SSL, firma de
formularios, entre otros.
REQ-COR-02-009
SESIÓN
El núcleo ofrecerá la interfaz para el manejo de la
sesión, estipulando la información necesaria a
comunicar a los módulos de la lógica de negocio
de la aplicación a integrar y facilitando los
métodos para la manipulación de la misma.
REQ-COR-02-010
CONFIGURABILIDAD
El núcleo ofrecerá la interfaz para el manejo de la
configuración de una aplicación. Los valores
configurables deberán registrarse en un fichero
de properties.
REQ-COR-02-011
UTILIDADES GENÉICAS
El núcleo ofrecerá un conjunto de utilidades
genéricas para facilitar determinadas tareas de
uso común por el resto de las aplicaciones.
REQ-COR-02-011
MAIL
El núcleo ofrecerá la interfaz para el envío de
correos. Los valores configurables deberán
registrarse en un fichero de properties o
accederse desde base de datos.
Tipo de documento:
Descripción Técnica
Código del documento
2014-Interoperatividad_RedAbogacia-
v1_5.doc
Revisión
1.5
Fecha
04/12/2014
Página 12 de 47
3.3
MULTILENGUAJE
Requerimiento
Nombre
Descripción
REQ-MLG-03-001
IDIOMA POR DEFECTO
Todas las aplicaciones a integrar en el portal de
Red de Abogacía deberán presentar su interfaz
de usuario en español, siendo este el idioma por
defecto.
REQ-MLG-03-002
IDIOMAS SOPORTADOS
El portal de Red de Abogacía soportará los
siguientes idiomas:
?
Español
?
Catalán
?
Gallego
?
Euskera
REQ-MLG-03-003
CODIFICACION DE
CADENAS DE
CARACTERES
Todas las cadenas de caracteres que se manejen
en la aplicación y que formen parte del interfaz de
usuario
deberán
estar
codificadas,
y
almacenados estos códigos en cada uno de los
ficheros de properties asociados a los idiomas
soportados por la aplicación.
REQ-MLG-03-004
IMÁGENES CONTEXTO
Si en la interfaz se presentan imágenes con
texto, deberán existir tantos ficheros para esa
imagen como idiomas soportados, cada uno con
el texto en el idioma correspondiente.
3.4
INSTALACIÓN
Requerimiento Nombre
Descripción
REQ-INS-04-001
DESPLIEGUE DE LA
APLICACIÓN
Se realizará el despliegue de la aplicación en los
diferentes Servidores.
REQ-INS-04-002 ALTA DE LA APLICACION EN
EL SISTEMA
El administrador del sistema realizará el alta de la
aplicación en el sistema una vez haya sido
desplegada la aplicación en el Servidor.
Back to top
4 01 -ESPECIFICACIONES DE ARQUITECTURA
4.1
REQ-ARQ-01-001: ARQUITECTURA J2EE
4.1.1 DESCRIPCIÓN
Las aplicaciones centralizadas del portal Red de Abogacía cumplirán el estándar J2EE para
desarrollo de aplicaciones. El servidor de Aplicaciones a utilizar será
Oracle WebLogic Server 12c
por lo que además deberán cumplir las especificaciones propias de WEBLOGIC, tales como
descriptores propios del servidor.
Tipo de documento:
Descripción Técnica
Código del documento
2014-Interoperatividad_RedAbogacia-
v1_5.doc
Revisión
1.5
Fecha
04/12/2014
Página 13 de 47
4.1.2 DETALLE
Las nuevas aplicaciones que vayan a ser integradas en el portal, deberán cumplir como mínimo los
estándares J2EE 1.5. Adicionalmente, para el desarrollo de componentes JAVA se utilizará la JDK
1.6.0_31.
Siguiendo los citados estándares se pretende conseguir:
1. Aplicaciones transaccionales
2. Escalabilidad
?
Permitirá que un aumento de carga de trabajo no implique
necesariamente modificaciones de software ni incremento de número de máquinas.
3. Disponibilidad.
4. Seguridad
?
Acceso a funcionalidades y datos de acuerdo con el perfil del usuario.
5. Interoperatividad
?
Permite interaccionar con distintos sistemas fácilmente.
6. Acceso a Base de Datos relaciónales.
Los estándares J2EE a los que se hace referencia son:
1. JSP 1.1
2. Servlets 2.2
3. EJB 1.1
4. JNDI 1.2
5. JDBC 2.0
6. JMS 1.0
Cada nueva aplicación o módulo funcional deberá ser una nueva aplicación de empresa dentro del
portal. Esta aplicación, que tendrá sus propios módulos Web y/o EJB’s, será desplegada en el
servidor de aplicaciones WEBLOGIC.
Tipo de documento:
Descripción Técnica
Código del documento
2014-Interoperatividad_RedAbogacia-
v1_5.doc
Revisión
1.5
Fecha
04/12/2014
Página 14 de 47
4.2
REQ-ARQ-01-002: FRONT END
4.2.1 DESCRIPCIÓN
Las aplicaciones tendrán un módulo Front-End que estará ubicado en el servidor Web IIS 6.
4.2.2 DETALLE
Las aplicaciones tendrán un módulo Front-End en el servidor de aplicaciones IIS. Se entiende por
módulo Front-End todos los ficheros de imágenes, HTML estático, bibliotecas Java Script y hojas de
estilo CSS. De está manera se liberará al servidor de aplicaciones de la carga de contenido estático.
Deberá especificarse si la aplicación pertenece o no a la zona segura a la hora de su instalación.
4.3
REQ-ARQ-01-003: FRAMEWORK
4.3.1 DESCRIPCIÓN
El portal Red de Abogacía dispone de un FRAMEWORK o núcleo compuesto por paquetes de
funcionalidades genéricas y reutilizables. Entre estos paquetes se puede citar: Acceso a la BBDD,
Generación de Logs, Configuración de
properties
, Utilización de una Cache propia, etc.
4.3.2 DETALLE
El portal
Red de Abogacía
tendrá un FRAMEWORK con funcionalidades que permitirá a las diferentes
aplicaciones interaccionar con el propio portal. La interacción se realizará a través de un API o
interfaz que facilitará la comunicación y simplificará el uso de las funcionalidades ofertadas.
Las ventajas que aportará la utilización del FRAMEWORK son:
1.
Mantenimiento de aplicaciones
. Al utilizar módulos comunes, todas las aplicaciones
tendrán la misma estructura lógica. Por esto, sólo se tendrá que conocer una estructura de
aplicación.
2.
Depuración de Errores
. Todas las aplicaciones utilizarán el mismo sistema de Logs por lo
que será más fácil interpretar las trazas.
3.
Accesos a BBDD únicos y controlados
. Se utilizará un único módulo de acceso a la
BBDD por lo que los accesos estarán controlados. Además todas las aplicaciones tendrán
que pasar unos filtros mínimos de acceso (Seguridad)
4.
Facilidad de integración
. Puesto que la estructura y filosofía de las aplicaciones será
similar, el procedimiento de instalación e integración será genérico.
5.
Optimización de desarrollo de nuevas Aplicaciones
. El desarrollo de nuevas
aplicaciones podrá centrarse en lógica de negocio.
4.4
REQ-ARQ-01-004: MODELO-VISTA-CONTROLADOR (MVC)
4.4.1 DESCRIPCIÓN
EL patrón de diseño utilizado en el portal red abogacía es el Modelo-Vista-Controlador (MVC), por lo
que se recomienda que las aplicaciones que vayan a ser integradas como aplicaciones centralizadas
utilicen este patrón.
Tipo de documento:
Descripción Técnica
Código del documento
2014-Interoperatividad_RedAbogacia-
v1_5.doc
Revisión
1.5
Fecha
04/12/2014
Página 15 de 47
4.4.2 DETALLE
El patrón MVC permite tener diferenciadas la capa de Presentación y la capa de Negocio gracias a la
acción de un controlador.
?
Capa de Presentación
?
Se utilizarán JSP para la capa de presentación. Se aconseja la
utilización de los TagLibs de Struts.
?
Capa de Controlador
?
El controlador será Struts 1.1. Con un controlador separaremos la
Lógica de Presentación de la Lógica de Negocio. Con Struts tendremos todos los accesos a
la Lógica controlados mediante un fichero XML. Todas las peticiones al Servidor pasarán por
el Controlador y será este el que gestione las acciones a seguir.
?
Capa de Negocio
?
Capa implementada mediante Ejb´s o Beans, que contiene únicamente
funcionalidades especificas del Negocio.
Tipo de documento:
Descripción Técnica
Código del documento
2014-Interoperatividad_RedAbogacia-
v1_5.doc
Revisión
1.5
Fecha
04/12/2014
Página 16 de 47
4.5
REQ-ARQ-01-005: BASE DE DATOS
4.5.1 DESCRIPCIÓN
Cada aplicación podrá utilizar un espacio reservado en el Servidor de Base de Datos para el
despliegue de tablas e índices que se necesite para implementar la lógica de Negocio.
4.5.2 DETALLE
Cada aplicación tendrá un espacio reservado (tablespace) para la creación de las tablas que
necesite. Este espacio será independiente del resto de la Base de Datos, pudiéndose modificar o
eliminar sin necesidad de involucrar al resto de aplicaciones que convivan en el Servidor de Base de
Datos.
La Base de Datos es
Oracle 10g
(se están migrando algunas bases de datos a
Oracle 11g
), por lo
que todas las aplicaciones crearán sus scripts de creación sobre esta BD.
En cualquier caso, una aplicación centralizada también podrá situar su Base de Datos fuera del
Servidor de Base de Datos dedicado al Portal.
Tipo de documento:
Descripción Técnica
Código del documento
2014-Interoperatividad_RedAbogacia-
v1_5.doc
Revisión
1.5
Fecha
04/12/2014
Página 17 de 47
Back to top
5 02 -ESPECIFICACIONES DE FRAMEWORK
En este apartado se detalla el contenido del FRAMEWORK desarrollado como base para la
integración de las diferentes aplicaciones en el Portal.
La siguiente figura muestra el modelo de arquitectura, despliegue de componentes y sus diferentes
interfaces que se plantea como base para la integración de aplicaciones en el Portal Red de
Abogacía:
Servidor Web
Java Script
Html
Imágenes
Servidor Aplicaciones
JDBC
JNDI
Framework J2EE
CONTROLADOR
NEGOCIO
CONTROLADOR
NEGOCIO
NUCLEO
GENERADOR
DE
TRAZAS
PERFILADOR
ACCESO
BD
CONFIGURACIÓN
CACHE
FILTRO
JAAS
JAXP
JTA
JMS
Java
Mail
Bean
EJB
VISTA
VISTA
STRUTS
JSP
INTERNACIONALIZACION
Java Script
Html
Imágenes
JSP
PORTAL
APLICACIONES
JSP
CSS
Servlet
STRUTS
Bean
EJB
Ilustración 1: Arquitectura propuesta utilizando un FRAMEWORD del Portal
5.1
REQ-COR-02-001: MÓDULOS FUNCIONALES
5.1.1 DESCRIPCIÓN
Las aplicaciones a desarrollar para integrarlas en el Portal Red de Abogacía podrán utilizar el núcleo
funcional proporcionado por el portal.
Tipo de documento:
Descripción Técnica
Código del documento
2014-Interoperatividad_RedAbogacia-
v1_5.doc
Revisión
1.5
Fecha
04/12/2014
Página 18 de 47
5.1.2 DETALLE
Las funcionalidades incluidas en el núcleo del portal son las siguientes:
?
Acceso a base de datos
?
Generación de trazas
?
Manejo de struts
?
Gestión de caché
?
Internacionalización
?
Seguridad
?
Sesión
?
Configurabilidad
?
Utilidades genéricas
La información relativa a la manera de utilizar los componentes que realizan estas funcionalidades se
encuentra en el API del núcleo de la plataforma del portal red abogacía:
5.2
REQ-COR-02-002: ACCESO A BASE DE DATOS
5.2.1 DESCRIPCIÓN
El núcleo ofrecerá una interfaz para el acceso a base de datos, de forma que las particularidades de
las diferentes fuentes de datos soportadas no afecten a la lógica de negocio de la aplicación a
integrar en el portal.
5.2.2 DETALLE
Se eliminará en la lógica de negocio implementada la manipulación de las conexiones a la base de
datos, y se encapsulará las particularidades de acceso a la información.
Los componentes que realizan esta funcionalidad son los siguientes:
com.pra.core.dataAccess.DataAccessFactory.java
com.pra.core.dataAccess.IObjectDataAccess.java
com.pra.core.dataAccess.Exceptions.DataExistException.java
com.pra.core.dataAccess.Exceptions.DataNotExistException.java
com.pra.core.dataAccess.Exceptions.ErrorDataAccess.java
com.pra.core.dataAccess.oracle.OracleDataAccessFactory.java
com.pra.core.dataAccess.oracle.OracleObjectDataAccess.java
com.pra.core.dataAccess.oracle.UtilidadesBD.java
5.3
REQ-COR-02-003: GENERACION DE TRAZAS
5.3.1 DESCRIPCIÓN
El núcleo ofrecerá un módulo de trazas o logs configurable. Permitirá escribir diferentes niveles de
trazas con una estructura definida, facilitando la interpretación de las mismas y optimizando el
mantenimiento de la aplicación.
Tipo de documento:
Descripción Técnica
Código del documento
2014-Interoperatividad_RedAbogacia-
v1_5.doc
Revisión
1.5
Fecha
04/12/2014
Página 19 de 47
5.3.2 DETALLE
La aplicación a integrarse en el portal deberá utilizar la funcionalidad de trazas proporcionada para la
emisión de sus logs.
Los componentes que realizan esta funcionalidad son los siguientes:
com.pra.core.trace.DefaultTrace.java
com.pra.core.trace.ILog.java
com.pra.core.trace.LogFactory.java
com.pra.core.trace.Trace.java
5.4
REQ-COR-02-004: MANEJO DE STRUTS
5.4.1 DESCRIPCIÓN
El núcleo ofrecerá una interfaz para la manipulación de acciones, proporcionando la ‘información
genérica para el desarrollo del ‘action’ particular de la funcionalidad de la lógica de negocio y
recubriendo y controlando los acceso y posibles errores.
5.4.2 DETALLE
La aplicación a integrarse en el portal deberá centrar su esfuerzo en desarrollar las particularidades
del ‘action’ asociado a su lógica de negocio, obviando los detalles genéricos, los cuales son
controlados por el núcleo.
Los componentes que realizan esta funcionalidad son los siguientes:
com.pra.core.struts.actions.DefaultAction.java
com.pra.core.struts.forms.DefaultForm.java
com.pra.core.struts.forms.util.PropertyValidator.java
5.5
REQ-COR-02-005: GESTIÓN DE CACHÉ
5.5.1 DESCRIPCIÓN
El núcleo ofrecerá una interfaz para el acceso y manipulación de una caché propia del portal.
5.5.2 DETALLE
La aplicación a integrarse en el portal podrá acceder a la caché del mismo para disponer sus propios
objetos. Si son objetos con escaso nivel de actualización puedan dejarse accesibles sin necesidad
de acceder a ellos en cada petición, mejorando así el rendimiento de la aplicación. Podrán
configurarse aspectos como la caducidad o el periodo de refresco.
Los componentes que realizan esta funcionalidad son los siguientes:
com.pra.core.cache.CacheFactory.java
com.pra.core.cache.ICache.java
com.pra.core.cache.testCache.java
com.pra.core.cache.UtilCache.java
5.6
REQ-COR-02-006: INTERNACIONALIZACIÓN
5.6.1 DESCRIPCIÓN
El núcleo ofrecerá una interfaz para dar soporte a la internacionalización de la aplicación, ya que el
portal es multilingüe.
Tipo de documento:
Descripción Técnica
Código del documento
2014-Interoperatividad_RedAbogacia-
v1_5.doc
Revisión
1.5
Fecha
04/12/2014
Página 20 de 47
5.6.2 DETALLE
La aplicación a integrarse en el portal deberá ceñirse a las especificaciones de internacionalización
aunque la misma sólo soporte un único idioma, para ello hará uso de las funcionalidad que con ese
fin se encuentra en el núcleo.
Los componentes que realizan esta funcionalidad son los siguientes:
com.pra.core.mlanguage.LocaleManager.java
com.pra.core.mlanguage.LocaleManagerFactory.java
com.pra.core.mlanguage.LocaleManagerImpl.java
5.7
REQ-COR-02-008: SEGURIDAD
5.7.1 DESCRIPCIÓN
El núcleo ofrecerá la implementación de los mecanismos de seguridad a aplicar a cualquier
aplicación a integrar en el sistema.
5.7.2 DETALLE
Esta funcionalidad ofrece una serie de sistemas o mecanismos de seguridad que pueden ser
utilizados tanto para la identificación de un usuario a una determinada aplicación como para la forma
de acceso a la aplicación. Estos mecanismos incluyen el manejo de certificados, SSL, encriptación y
firma digital de documentos. Dependiendo del tipo de aplicación a integrar deberán utilizarse o no
estos mecanismos de seguridad.
Los componentes que realizan esta funcionalidad son los siguientes:
Certificados
com.pra.core.security.certificate.aca.util.CertConstant.java
com.pra.core.security.certificate.aca.util.CNAdmin.java
com.pra.core.security.certificate.aca.util.GenDataCertAdmin.java
com.pra.core.security.certificate.aca.util.GenDataCertPJ.java
com.pra.core.security.certificate.aca.util.OAdmin.java
com.pra.core.security.certificate.aca.util.TipoPoliticaACA.java
com.pra.core.security.certificate.aca.util.utilGenCert.java
com.pra.core.security.certificate.exceptions.CertificadoNoValidoException.java
com.pra.core.security.certificate.exceptions.CertificadoRevocadoException.java
com.pra.core.security.certificate.exceptions.CNException.java
com.pra.core.security.certificate.exceptions.DNSinCNException.java
com.pra.core.security.certificate.exceptions.DNSinEException.java
com.pra.core.security.certificate.exceptions.DNSinNumSerieException.java
com.pra.core.security.certificate.exceptions.DNSinOException.java
com.pra.core.security.certificate.exceptions.DNSinOUException.java
com.pra.core.security.certificate.exceptions.DNSinTException.java
com.pra.core.security.certificate.exceptions.FechaCaducidadException.java
com.pra.core.security.certificate.exceptions.ListCrlsKOException.java
com.pra.core.security.certificate.exceptions.NoHayCertificadoException.java
com.pra.core.security.certificate.exceptions.OException.java
com.pra.core.security.certificate.exceptions.OIDKOException.java
com.pra.core.security.certificate.exceptions.UserAccesoAppBloqueadoException.java
com.pra.core.security.certificate.util.CN.java
com.pra.core.security.certificate.util.DN.java
com.pra.core.security.certificate.util.GenDataCert.java
com.pra.core.security.certificate.util.O.java
com.pra.core.security.certificate.util.utilCert.java
Tipo de documento:
Descripción Técnica
Código del documento
2014-Interoperatividad_RedAbogacia-
v1_5.doc
Revisión
1.5
Fecha
04/12/2014
Página 21 de 47
Encriptación
com.pra.core.security.encrypt.EncryptFactory.java
com.pra.core.security.encrypt.EncryptImpl.java
com.pra.core.security.encrypt.exception
com.pra.core.security.encrypt.IEncrypt.java
com.pra.core.security.encrypt.TestEncrypt.java
com.pra.core.security.encrypt.exception.EncryptException.java
com.pra.core.security.encrypt.exception.NotExitsEncriptsValues.java
Firma digital
com.pra.core.security.firma.asn1.AlgorithmIdentifier.java
com.pra.core.security.firma.asn1.ASN1.java
com.pra.core.security.firma.asn1.ASN1BadSyntaxException.java
com.pra.core.security.firma.asn1.ASN1BitString.java
com.pra.core.security.firma.asn1.ASN1Boolean.java
com.pra.core.security.firma.asn1.ASN1Class.java
com.pra.core.security.firma.asn1.ASN1DERBuffer.java
com.pra.core.security.firma.asn1.ASN1Element.java
com.pra.core.security.firma.asn1.ASN1ElementAndInt.java
com.pra.core.security.firma.asn1.ASN1Enumerated.java
com.pra.core.security.firma.asn1.ASN1Exception.java
com.pra.core.security.firma.asn1.ASN1GeneralizedTime.java
com.pra.core.security.firma.asn1.ASN1IA5String.java
com.pra.core.security.firma.asn1.ASN1Integer.java
com.pra.core.security.firma.asn1.ASN1InvalidDataException.java
com.pra.core.security.firma.asn1.ASN1Null.java
com.pra.core.security.firma.asn1.ASN1NumericString.java
com.pra.core.security.firma.asn1.ASN1OctetString.java
com.pra.core.security.firma.asn1.ASN1OID.java
com.pra.core.security.firma.asn1.ASN1Parser.java
com.pra.core.security.firma.asn1.ASN1PrintableString.java
com.pra.core.security.firma.asn1.ASN1Sequence.java
com.pra.core.security.firma.asn1.ASN1Set.java
com.pra.core.security.firma.asn1.ASN1T61String.java
com.pra.core.security.firma.asn1.ASN1Tagged.java
com.pra.core.security.firma.asn1.ASN1UTCTime.java
com.pra.core.security.firma.asn1.ASN1UTF8String.java
com.pra.core.security.firma.asn1.Attribute.java
com.pra.core.security.firma.asn1.AttrTypeAndValue.java
com.pra.core.security.firma.asn1.DistName.java
com.pra.core.security.firma.asn1.DNStringBadFormat.java
com.pra.core.security.firma.asn1.ExceptionIfEOFInputStream.java
com.pra.core.security.firma.asn1.GeneralName.java
com.pra.core.security.firma.asn1.IssuerSerial.java
com.pra.core.security.firma.asn1.ObjectID.java
com.pra.core.security.firma.asn1.RelDN.java
com.pra.core.security.firma.cms.CMSSignedData.java
com.pra.core.security.firma.cms.CMSSigner.java
com.pra.core.security.firma.cms.CMSVerifier.java
com.pra.core.security.firma.cms.CMSVerifyException.java
com.pra.core.security.firma.cms.CodigosErrorCMS.java
com.pra.core.security.firma.cms.SignerInfo.java
com.pra.core.security.firma.commons.BadFormatException.java
com.pra.core.security.firma.commons.BadParameterException.java
com.pra.core.security.firma.commons.CNBadFormatException.java
Tipo de documento:
Descripción Técnica
Código del documento
2014-Interoperatividad_RedAbogacia-
v1_5.doc
Revisión
1.5
Fecha
04/12/2014
Página 22 de 47
com.pra.core.security.firma.commons.ExceptionWithCause.java
com.pra.core.security.firma.commons.InternalErrorException.java
com.pra.core.security.firma.commons.NotSupportedException.java
com.pra.core.security.firma.commons.RevokedCertificateException.java
com.pra.core.security.firma.commons.SubjectAltNameException.java
com.pra.core.security.firma.util.B64Exception.java
com.pra.core.security.firma.util.Base64.java
com.pra.core.security.firma.util.CertParser.java
com.pra.core.security.firma.util.Control.java
com.pra.core.security.firma.util.Email.java
com.pra.core.security.firma.util.NIF.java
com.pra.core.security.firma.util.Util.java
com.pra.core.security.firma.util.ValidaCertificado.java
com.pra.core.security.hash.HashFactory.java
com.pra.core.security.hash.TestHash.java
5.8
REQ-COR-02-009: SESIÓN
5.8.1 DESCRIPCIÓN
El núcleo ofrecerá la interfaz para el manejo de la sesión, estipulando la información necesaria a
comunicar a los módulos de la lógica de negocio de la aplicación a integrar y facilitando los métodos
para la manipulación de la misma.
5.8.2 DETALLE
La aplicación a integrar en el portal debe utilizar esta funcionalidad que proporciona los objetos de
sesión que contienen la información necesaria que maneja una aplicación integrada en el portal.
Entre esta información se puede encontrar la información del usuario, información del colegio, e
información propia de la aplicación referente a la estructura de esta (menús).
Los componentes que realizan esta funcionalidad son los siguientes:
com.pra.core.sesion.SesionDefault.java
com.pra.core.sesion.SesionTO.java
com.pra.core.sessionMenus.UtilitiesMenu.java
com.pra.core.TO.MenuTO.java
com.pra.core.TO.SesionUsuarioTO.java
com.pra.core.TO.SesionZonaTO.java
5.9
REQ-COR-02-010: CONFIGURABILIDAD
5.9.1 DESCRIPCIÓN
El núcleo ofrecerá la interfaz para el manejo de la configuración de una aplicación. Los valores
configurables deberán registrarse en un fichero de properties.
5.9.2 DETALLE
La aplicación a integrar debe utilizar esta funcionalidad para definir los parámetros de configuración
de la propia aplicación. Esta funcionalidad ofrece métodos para acceder a las variables de
configuración de una aplicación que están registradas en un fichero properties.
Tipo de documento:
Descripción Técnica
Código del documento
2014-Interoperatividad_RedAbogacia-
v1_5.doc
Revisión
1.5
Fecha
04/12/2014
Página 23 de 47
Los componentes que realizan esta funcionalidad son los siguientes:
com.pra.core.settings.Configuration.java
com.pra.core.settings.ISettings.java
com.pra.core.settings.Settings.java
com.pra.core.settings.SettingsSingleton.java
com.pra.core.settings.TestSettings.java
com.pra.core.settings.exceptions.ConfigurationException.java
5.10 REQ-COR-02-011: UTILIDADES GENÉRICAS
5.10.1
DESCRIPCIÓN
El núcleo ofrecerá un conjunto de utilidades genéricas para facilitar determinadas tareas de uso
común por el resto de las aplicaciones.
5.10.2
DETALLE
La aplicación a integrar puede (si es necesario) utilizar estás utilidades genéricas para el desarrollo
de los módulos funcionales.
Los componentes que realizan esta funcionalidad son los siguientes:
com.pra.core.util.CalculateTime.java
com.pra.core.util.DateUtil.java
com.pra.core.util.Util.java
5.11 REQ-COR-02-012: MAIL
5.11.1
DESCRIPCIÓN
El núcleo ofrecerá un conjunto funcionalidades que permitirá de una manera sencilla el envío de
correos desde la plataforma CGAE.
5.11.2
DETALLE
La aplicación a integrar puede (si es necesario) utilizar estás utilidades genéricas para el desarrollo
de los módulos funcionales.
Los componentes que realizan esta funcionalidad son los siguientes:
com.pra.core.mail.IMail.java
com.pra.core.mail.MailAuthenticator.java
com.pra.core.mail.MailException.java
com.pra.core.mail.MailFactory.java
com.pra.core.mail.MailImpl.java
com.pra.core.mail.Exception.CertificadoFirmaCorreoCaducadoException.java
com.pra.core.mail.Exception.CertificadoFirmaKO.java
com.pra.core.mail.Exception.CertificadoNotFoundExceptio.java
com.pra.core.mail.Exception.DireccionCorreoIncorrectaException.java
com.pra.core.mail.Exception.DireccionDestinatarioKO.java
com.pra.core.mail.Exception.errorDescifraMensajeException.java
com.pra.core.mail.Exception.ErrorSignMessageException.java
Tipo de documento:
Descripción Técnica
Código del documento
2014-Interoperatividad_RedAbogacia-
v1_5.doc
Revisión
1.5
Fecha
04/12/2014
Página 24 de 47
com.pra.core.mail.Exception.FirmaHandlerKO.java
com.pra.core.mail.Exception.FirmaMailKOException.java
com.pra.core.mail.Exception.FirmaIncorrectaException.java
com.pra.core.mail.Exception.FirmaMailKOException.java
com.pra.core.mail.Exception.KeyStoreSignNotFoundException.java
com.pra.core.mail.Exception.MensajeConstruidoKO.java
com.pra.core.mail.Exception.PrivateKeyNotFoundException.java
com.pra.core.mail.firma.FirmaMailIAIK.java
Back to top
6 03 -ESPECIFICACIONES MULTILENGUAJE
6.1
REQ-MLG-03-001: IDIOMA POR DEFECTO
6.1.1 DESCRIPCIÓN
Todas las aplicaciones a integrar en el portal de Red de Abogacía deberán presentar su interfaz de
usuario en español, siendo este el idioma por defecto.
6.1.2 DETALLE
Los componentes que realizan esta funcionalidad son los siguientes:
com.pra.core.mlanguage.LocaleManager.java
com.pra.core.mlanguage.LocaleManagerFactory.java
com.pra.core.mlanguage.LocaleManagerImpl.java
6.2
REQ-MLG-03-002: IDIOMAS SOPORTADOS
6.2.1 DESCRIPCIÓN
El portal de Red de Abogacía soportará los siguientes idiomas:
?
Español
?
Catalán
?
Gallego
?
Euskera
6.2.2 DETALLE
Las aplicaciones que soporten multilenguaje lo harán de acuerdo a las restricciones impuestas por el
portal, es decir, únicamente soportaran los idiomas indicados.
Tipo de documento:
Descripción Técnica
Código del documento
2014-Interoperatividad_RedAbogacia-
v1_5.doc
Revisión
1.5
Fecha
04/12/2014
Página 25 de 47
6.3
REQ-MLG-03-003:
CODIFICACIÓN
DE
CADENAS
DE
CARÁCTERES
6.3.1 DESCRIPCIÓN
Todas las cadenas de caracteres que se manejen en la aplicación y que formen parte del interfaz de
usuario deberán estar codificadas, y almacenados estos códigos en cada uno de los ficheros de
properties asociados a los idiomas soportados por la aplicación.
6.3.2 DETALLE
Las aplicaciones deberán tener un fichero de properties por cada uno de lo idiomas soportados,
donde aparezcan los códigos de las cadenas de caracteres utilizadas y su traducción en el idioma
correspondiente.
6.4
REQ-MLG-03-004: IMÁGENES CON TEXTO
6.4.1 DESCRIPCIÓN
Si en la interfaz se presentan imágenes con texto, deberán existir tantos ficheros para esa imagen
como idiomas soportados, cada uno con el texto en el idioma correspondiente.
6.4.2 DETALLE
Los ficheros con las imágenes con texto se colocarán en directorios que indiquen el idioma que
soportan, de acuerdo a la codificación ISO-639 (/es, /ca,/eu,/gl).
Tipo de documento:
Descripción Técnica
Código del documento
2014-Interoperatividad_RedAbogacia-
v1_5.doc
Revisión
1.5
Fecha
04/12/2014
Página 26 de 47
7
04 -ESPECIFICACIONES INSTALACIÓN
7.1
REQ-INS-04-001: REQUERIMIENTOS DE LA APLICACIÓN
7.1.1 DESCRIPCIÓN
En este apartado se explicarán los requerimientos que tendrá que aportar el proveedor para la
inclusión de una aplicación en el Portal Red Abogacía según sea el tipo de aplicación.
7.1.2 DETALLE
Los requerimientos necesarios para la inclusión de una aplicación en el portal serán los siguientes.
1.
Aplicaciones Tipo 2.
a.
Aplicaciones sin autologado
?
Para su instalación se necesitará la URL de conexión a la
nueva aplicación.
b.
Aplicaciones con autologado
?
Para la conexión con estas aplicaciones, además de la
URL de acceso se necesitará la siguiente información:
-
Usuario y Contraseña de los usuarios. Está información será almacenada en la Base
de Datos de Red Abogacía de modo encriptada. Los datos de usuario y contraseña
estarán ‘mapeados’ contra un usuario real del sistema Red Abogacía.
-
API de interacción entre el sistema Red Abogacía y la nueva aplicación en el que se
definirá:
1.
Nomenclatura de los parámetros
. Nombre con los que espera la aplicación
los parámetros.
2.
Formato del valor de los parámetros
. Se detallará el formato que tendrán
los parámetros. En el caso en el que los parámetros necesiten ser enviados
encriptados, se facilitará el algoritmo de encriptación.
3.
Modo de envío de los parámetros
. Se especificará si el modo de envío de
los parámetros se realiza mediante el método GET (por URL) o mediante el
método POST (por la entrada estándar STDIO). En cualquier caso se
detallarán los nombre de los parámetros.
4. No se descarta otro tipo de comunicación, cómo por ejemplo EJB´s, Web
Services. En cualquier caso se detallará debidamente el API de
comunicación entre ambos sistemas.
c.
Aplicaciones con restricciones especiales de acceso
?.
Podrán existir aplicaciones que
necesiten otros parámetros distintos al usuario y contraseña para su correcta conexión, en
este caso se especificarán estos como en el apartado b. Aplicaciones con autologado.
2.
Aplicaciones Tipo 1.
Para la integración de una aplicación tipo 2 el proveedor deberá presentar
un documento en formato Word (Existirá una plantilla genérica) con los requerimientos
siguientes:
a.
Nombre de los módulos.
El proveedor de la nueva aplicación aportará un listado con el
nombre de todos los módulos que formarán la nueva aplicación.
b.
URL´s de los módulos.
Para dar de alta una nueva aplicación y sus módulos se necesitarán
las URL´s (Path absoluto) de los diferentes módulos que forman dicha aplicación. Esta URL
será la dirección a la readicionará el portal cuando un usuario pulse el link del módulo
correspondiente.
Tipo de documento:
Descripción Técnica
Código del documento
2014-Interoperatividad_RedAbogacia-
v1_5.doc
Revisión
1.5
Fecha
04/12/2014
Página 27 de 47
c.
Listado de perfiles.
Se aportará un listado con los posibles perfiles que existirán en la
aplicación y a los módulos a los que podrán acceder dichos perfiles.
d.
Listado de roles.
Los perfiles creados podrán pertenecer a un rol, por lo tanto en el caso
que sea necesario se ofrecerá un listado con la asociación rol-perfil.
e. En el caso de aplicaciones tipo 2 externas se aportará un documento técnico con toda la
información relativa a la configuración de la aplicación, ficheros de trazas, ficheros de
properties.
3.
Aplicaciones Tipo 6
:
a.
Salida o llamada a url externa:
en la llamada a la aplicación externa se incluirá el
parámetro idParameter:
-
idParameter:
número aleatorio que se genera cada vez que se llame a la aplicación
externa.
-
TIEMPO_MAX_TOKEN_ACCESO:
tiempo máximo para que una petición caduque. Se
guarda en tabla PAR_PARMETOS.
-
Tabla
AIN_ACCESO_INDEPENDIENTE:
almacena el valor de idParameter y el valor de
la fecha actual adelantado TIEMPO_MAX_TOKEN_ACCESO.
b.
Entrada o comprobación de servicio:
Desde la aplicación tipo 6 se recibirá:
-
URL
de
acceso:
La
ruta
de
recepción
de
aplicaciones
de
tipo
6
https://www.redabogacia.org/praseg/prasegssl/ControlActionRemoto.do
. Es un acceso
https que no requiere certificado.
-
Parámetros:
A la url se debe anexar el “idParameter” que se envió en la llamada de
salida. Este valor se anexará con el nombre de “token”. Así la url de comprobación de
servicio sería como esta:
https://www.redabogacia.org/praseg/prasegssl/ControlActionRemoto.do?token=idParmeter
-
Resultado:
El portal validará si la llamada ha caducado, esto es, comprobará en base de
datos si en la tabla AIN_ACCESO_INDEPENDIENTE hay una entrada para el token
recibido y la fecha actual es menor a la fecha almacenada junto al token.
-
Si la validación es incorrecta se devuelve el siguiente xml:
<?xml version="1.0" ?>
<respuesta>ko</respuesta>
Y si es correcta la validación será:
<?xml version="1.0" ?>
<respuesta>ok</respuesta>
7.2
REQ-INS-04-002: ALTA DE LA APLICACIÓN EN EL SISTEMA
7.2.1 DESCRIPCIÓN
El administrador del sistema REDABOGACIA realizará el alta de la aplicación en el sistema una vez
haya sido desplegada la aplicación en el Servidor. Según sea el tipo de la aplicación el alta será
diferente.
Tipo de documento:
Descripción Técnica
Código del documento
2014-Interoperatividad_RedAbogacia-
v1_5.doc
Revisión
1.5
Fecha
04/12/2014
Página 28 de 47
7.2.2 DETALLE
El alta de la aplicación en el sistema se realizará a través de un interfaz Web, donde se creará
el nuevo módulo funcional y todas las funcionalidades, se asignará el nuevo módulo a las
diferentes zonas, también se crearán los diferentes perfiles y roles en el caso que corresponda.
De esta manera, se dará de alta la aplicación en la Base de Datos y podrá ser accesible a los
usuarios del sistema. El procedimiento para dar de alta una aplicación dependerá del tipo al
que pertenezca esta.
1.
Aplicaciones Tipo2.
a. EL administrador del sistema accederá al portal REDABOGACIA a la zona CGAE
mediante un certificado válido.
Tipo de documento:
Descripción Técnica
Código del documento
2014-Interoperatividad_RedAbogacia-
v1_5.doc
Revisión
1.5
Fecha
04/12/2014
Página 29 de 47
b. Elegirá la opción Administración del Portal / Aplicaciones.
Tipo de documento:
Descripción Técnica
Código del documento
2014-Interoperatividad_RedAbogacia-
v1_5.doc
Revisión
1.5
Fecha
04/12/2014
Página 30 de 47
c. Seleccionará mediante el combo si la aplicación se va a desplegar en el portal
público o en el portal privado (SSL con certificado) y pulsará el botón
Nueva
Aplicación.
d. Rellenará el formulario con la siguiente información:
i.
Descripción
?
Descripción de la aplicación. (Obligatorio)
ii.
Etiqueta
?
Nombre de la etiqueta que habrá que meter en el fichero
‘properties’ con el nombre de la aplicación. Está información se necesita para
la internacionalización del portal. (Obligatorio)
iii.
URL de destino
?
url a la que se redirigirá la aplicación. (Obligatorio)
iv.
Apl. Obligatoria
?
Se chequeará en el caso de que la aplicación sea
universal.
v.
Url Imagen
?
Path de la Imagen en el caso de que el nombre de la aplicación
esté en una imagen.
vi.
Ventana nueva
?
Se chequeará en el caso que la nueva aplicación se ejecute
en una nueva ventana. (Obligatorio)
e. Añadirá las zonas donde se va a desplegar la aplicación mediante el botón
Añadir
Zonas.
f.
Pulsará la opción Aceptar para dar de alta la aplicación principal.
Una vez que se haya dado de alta la aplicación el sistema asociará a la aplicación un
código de aplicación.
En el caso en el que la aplicación que se ha dado de alta sea del portal publico la
operación de alta habrá finalizado, en caso contrario, y sea una aplicación que pertenece
al portal privado el administrador deberá dar de alta un perfil mediante la funcionalidad
Administración Portal/Perfiles.
Tipo de documento:
Descripción Técnica
Código del documento
2014-Interoperatividad_RedAbogacia-
v1_5.doc
Revisión
1.5
Fecha
04/12/2014
Página 31 de 47
Eligiendo la opción Nuevo Perfil se dará de alta el nuevo perfil.
A esta nueva funcionalidad se podrá acceder asociando el nuevo perfil a usuarios en
concreto mediante la funcionalidad
Administración Portal/Usuarios
o también se podrá
asociar la nueva funcionalidad a todos los usuarios que pertenezcan a un determinado rol
mediante la opción
Administración Portal/Roles
añadiendo a un rol existente el nuevo
perfil.
2. Aplicaciones Tipo 1 , Tipo 3, Tipo 4, Tipo 5, Tipo 6
Para dar de alta una aplicación tipo 1, tipo 3, tipo 4, tipo 5, tipo 6, ya sea interna o
externa, habrá que seguir los pasos expuestos en el apartado anterior para dar de alta la
aplicación principal.
a) El administrador del sistema accederá al portal REDABOGACIA a la zona CGAE
mediante un certificado válido.
Tipo de documento:
Descripción Técnica
Código del documento
2014-Interoperatividad_RedAbogacia-
v1_5.doc
Revisión
1.5
Fecha
04/12/2014
Página 32 de 47
b) Elegirá la opción Administración del Portal / Aplicaciones.
Tipo de documento:
Descripción Técnica
Código del documento
2014-Interoperatividad_RedAbogacia-
v1_5.doc
Revisión
1.5
Fecha
04/12/2014
Página 33 de 47
c) Seleccionará mediante el combo la opción portal privado (SSL con certificado) y
pulsará el botón Nueva Aplicación.
d) Rellenará el formulario con la siguiente información.
i.
Descripción
?
Descripción de la aplicación .(Obligatorio)
ii.
Etiqueta
?
Nombre de la etiqueta que habrá que meter en el fichero
‘properties’ con el nombre de la aplicación. Está información se necesita para
la internacionalización del portal. (Obligatorio)
iii.
URL de destino
?
url a la que se redirigirá la aplicación. (Obligatorio). En este
caso será la misma url para todas las nuevas aplicaciones
iv.
Tipo de Aplicación
. Diferentes tipos de aplicaciones que se pueden desplegar
en el portal RedAbogacia.
1.
Tipo 1
. la url de destino será libre. Los check Ventana nueva, Barra de
estado, barra de navegación y ventana redimensionable permanecerán
deshabilitados
2.
Tipo 3
. la url de destino será
/praseg/printNew.do?forward=new
. Los
check Ventana nueva, Barra de estado, barra de navegación y ventana
redimensionable permanecerán deshabilitados.
3.
Tipo 4
. la url de destino será libre. Los check Barra de estado, barra de
navegación y ventana redimensionable permanecerán deshabilitados. El
check ventana nueva aparecerá habilitado.
4.
Tipo 5
. la url de destino será libre. Los check Ventana nueva, Barra de
estado, barra de navegación y ventana redimensionable permanecerán
deshabilitados. El check ventana nueva aparecerá habilitado.
5.
Tipo 6
. la url de destino será libre. El check ventana nueva quedará
deshabilitado pero seleccionado sin posibilidad de modificar, y los check
barra de estado, barra de navegación y ventana redimensionable quedan
habilitados.
v.
Apl. Obligatoria
?
Se chequeará en el caso de que la aplicación sea
universal.
Tipo de documento:
Descripción Técnica
Código del documento
2014-Interoperatividad_RedAbogacia-
v1_5.doc
Revisión
1.5
Fecha
04/12/2014
Página 34 de 47
vi.
Url Imagen
?
Path de la Imagen en el caso de que el nombre de la aplicación
esté en una imagen.
vii.
Ventana nueva
?
Se chequeará en el caso que la nueva aplicación se ejecute
en una nueva ventana. (Obligatorio).
viii.
Barra de estado
?
Se chequeará en el caso que la nueva aplicación se abra
en una nueva ventana y se necesite visualizar la barra de estado del
navegador.
ix.
Barra de navegación
?
Se chequeará en el caso que la nueva aplicación se
abra en una nueva ventana y se necesite visualizar la barra de navegación del
navegador.
x.
Ventana redimensionable
?
Se chequeará en el caso que la nueva
aplicación se abra en una nueva ventana y se necesite que esta sea
redimensionable
e) Añadirá las zonas donde se va a desplegar la aplicación mediante el botón Añadir
Zonas.
f)
Pulsará la opción Aceptar para dar de alta la aplicación principal.
g) Si todo se ha realizado correctamente aparecerá un mensaje de confirmación.
Aparecerá el formulario con la información que la nueva aplicación dada de alta. El
campo etiqueta, que aparecerá en modo lectura, contiene la información del texto
que se deberá introducir en el fichero de
PraTextosIfaz.properties
para la
internacionalización del portal.
Se dará de alta la nueva etiqueta en el fichero PraTextosIfaz.properties y su
traducción en los ficheros correspondientes, catalán (PraTextosIfaz_ca.properties),
gallego (PraTextosIfaz_ga.properties), euskera (PraTextosIfaz_eu.properties) y
castellano (PraTextosIfaz_ca.properties).
En esta versión, se tiene que dar de alta manualmente las etiquetas, de modo que
para que la plataforma introduzca los cambios, se necesitará un redeploy del
servidor de aplicaciones.(Puede tardar unos segundos).
Tipo de documento:
Descripción Técnica
Código del documento
2014-Interoperatividad_RedAbogacia-
v1_5.doc
Revisión
1.5
Fecha
04/12/2014
Página 35 de 47
h) Una vez que se haya dado de alta la aplicación el sistema asociará a la aplicación
un código de aplicación. El administrador recogerá este valor consultando la
aplicación creada. Este código se utilizará para la creación de los scripts de Base
de Datos.
i)
En esta versión la carga de módulos pertenecientes a una aplicación se deberá
realizar mediante scripts de Base de Datos, en versiones posteriores se realizarán
a partir de un interfaz web cómo en el caso de la aplicación principal.
Creación de los Scripts de base de Datos para la inserción en BBDD de los
nuevos módulos.
EL formato del script de BBDD para dar de alta los módulos será el siguiente:
insert into SIS_SISTEMAS VALUES ('S010704', 'AVISOS',
'S0107', 'pra.ifaz.aplicacion.prueba',
'https://195.53.21.230/lexnet/AvisosVer?logindirecto=si',
null, sysdate, null, 'CARGA INICIAL', null, '1', '2', '5',
'0', null, null);
-
SIS_CODIGO
?
Será el valor del código del módulo. Este valor deberá seguir
un formato determinado
?
Código de la aplicación + Dos caracteres
secuenciales. Si la aplicación que se ha creado tiene el código S0107 el primer
módulo creado tendrá e código S010700. 'S010704'
-
SIS_DESC
?
Pequeña descripción del módulo.
'AVISOS'
-
SIS_DEP_SISTEMA
?
Código de la aplicación a la que pertenece el módulo.
'S0107'
-
SIS_LITERAL
?
Nombre de la etiqueta que se deberá insertar en los ficheros
.propeties para la internacionalización del portal.
'pra.ifaz.aplicacion.prueba'
-
SIS_URL_DESTINO
?
url que redirigirá a la funcionalidad del módulo creado.
'https://195.53.212.230/lexnet/AvisosVer?logindirecto=si'
-
SIS_URL_IMAGEN
?
url de la imagen, en el caso que el nombre de la
aplicación este representado en una imagen.
Null
-
SIS_ALTA
?
Fecha del alta del modulo.
Sysdate.
-
SIS_BAJA
?
Fecha de baja del módulo
. Null.
-
USU_LOGIN_ALTA
?
Usuario que ha dado de alta del módulo.
'CARGA
INICIAL'
-
USU_LOGIN_BAJA
?
Usuario que ha dado de baja del módulo.
Null.
-
SIS_OBLIGATORIA
?
Mostrará si la aplicación es obligatoria(1) o no (0).
‘1’.
-
SIS_NIVEL
?
Nivel de profundidad en el árbol de módulos. Para módulos que
pertenecen a una aplicación el nivel será ‘2’.
-
SIS_ORDEN
?
Orden en el que aparecerá el módulo en el menú.
‘5’.
-
SIS_WINDOW_OPEN
?
Indicará si la aplicación se ejecuta en una nueva
ventana (1) o la misma ventana desde donde se llama (0).
'0'.
-
SIS_MODIFICACIÓN
?
fecha de modificación del módulo.
Null.
-
USU_LOGIN_MODIFICACIÓN
?
Usuario que modifica el módulo.
Null
.
j)
Una vez lanzados los scripts en la Base de Datos (PRAPRO), se deberán dar de
alta las etiquetas de los módulos creados como en el caso de alta de aplicaciones,
es decir , introducir en el PraTextosIfaz.properties , los valores insertados en el
campo SIS_LITERAL de los scripts.(Opción 7).
k) Una vez se hayan dado de alta los módulos de la nueva aplicación se procederá a
dar de alta los perfiles mediante la funcionalidad Administración Portal/Perfiles.
Eligiendo la opción Nuevo Perfil, habiendo seleccionado previamente el nuevo
Tipo de documento:
Descripción Técnica
Código del documento
2014-Interoperatividad_RedAbogacia-
v1_5.doc
Revisión
1.5
Fecha
04/12/2014
Página 36 de 47
sistema, se irán dando de alta los nuevos perfiles, asociando para ello los módulos
de la aplicación a los perfiles (Consultar manual de usuario para más detalle).
A esta nueva funcionalidad se podrá acceder asociando el nuevo perfil a usuarios
en concreto mediante la funcionalidad
Administración Portal/Usuarios
o también
se podrá asociar la nueva funcionalidad a todos los usuarios que pertenezcan a un
determinado rol mediante la opción
Administración Portal/Roles
añadiendo a un
rol existente el nuevo perfil.
Tipo de documento:
Descripción Técnica
Código del documento
2014-Interoperatividad_RedAbogacia-
v1_5.doc
Revisión
1.5
Fecha
04/12/2014
Página 37 de 47
Back to top
8 05 -ESPECIFICACIONES DE UTILIZACIÓN DE LAS
Back to top
EXTENSIONES DEL CORE
El Core tiene un API para la correcta utilización, dentro del paquete com.pra.core.demos.src
existen test de ejemplo para la utilización de las diferentes extensiones del core.
8.1
UTILIZACIÓN DE LA EXTENSIÓN MAIL
Paquete:
com.pra.core.demos.src.mail
Configuración:
Modificar el fichero
java.security,
que se encuentra ubicado dentro de la carpeta del jre que
está utilizando el weblogic, de forma que aparezca IAIK como segundo proveedor
security.provider.1=sun.security.provider.Sun
security.provider.2=iaik.security.provider.IAIK
security.provider.3=com.sun.net.ssl.internal.ssl.Provider
security.provider.4=com.sun.rsajca.Provider
security.provider.5=com.sun.crypto.provider.SunJCE
security.provider.6=sun.security.jgss.SunProvider
Se deben tener definidas las siguientes properties en el fichero pra.properties o también se da
la opción de insertar estos parámetros en una tabla de la base de datos que utilice la aplicación
y obtenerlos desde allí:
config.smtp.smtphost=SERVIDOR_DE_CORREO
config.smtp.contenttype=text/html;charset="iso-8859-1"
config.smtp.defsubject=SUBJECT DEL MENSAJE
config.smtp.pwdstorefirma=PWD_CERTIFICADO_FIRMA
config.smtp.storefirma=RUTA_CERTIFICADO_FIRMA.PFX
Para probar la extensión de mail se han creado tres TEST:
1. TestMailHTMLFirmado
public class TestMailHTMLFirmado {
public static void main(String[] args) {
ISettings is = SettingsSingleton.getInstance();
if (args.length < 4) {
System.out.println("USO: TestMailHTMLFirmado mail_emisor asunto “ +
“ usuario_cta_correo pwd_cuenta_correo");
}else {
try {
//enviamos el correo
String mail_emisor=args[0];
String asunto=args[1];
// Generamos el texto del mail.
String usuario_mail=args[2];
String pass_mail =args[3];
System.out.println("USUARIO: " + usuario_mail + ", PWD: " + pass_mail);
Tipo de documento:
Descripción Técnica
Código del documento
2014-Interoperatividad_RedAbogacia-
v1_5.doc
Revisión
1.5
Fecha
04/12/2014
Página 38 de 47
IMail mail = MailFactory.getMail();
String textoMail="<html>esto es una prueba de <b>correo</b> html
<br><br> firmado </html>";
System.out.println("textoMail: " + textoMail );
try {
mail.sendMailHTML(usuario_mail, "servicios@redabogacia.org", asunto,
textoMail,usuario_mail, password_mail, true);
}
catch (MailException e) {
e.printStackTrace();
}
}
catch (MailException e) {
e.printStackTrace();
}
finally {
}
}
}
}
2. TestMailEnviarEml
Test para probar el envío de correos simples.
public class TestMailEnviarEml {
public static void main(String[] args) {
ISettings is = SettingsSingleton.getInstance();
if (args.length < 3) {
System.out.println("USO: TestMailEnviarEml fichero_Eml usuario_cta_correo “ +
“ pwd_cuenta_correo");
}else{
try {
//enviamos el correo
String ficheroEml=args[0];
// Generamos el texto del mail.
String usuario_mail=args[1];
String password_mail =args[2];
System.out.println("USUARIO: " + usuario_mail + "
PWD: " + password_mail);
IMail mail = MailFactory.getMail();
try {
mail.enviarEml(ficheroEml,usuario_mail,password_mail);
}
catch (FileNotFoundException e) {
e.printStackTrace();
}
catch (MessagingException e) {
e.printStackTrace();
}
}
Tipo de documento:
Descripción Técnica
Código del documento
2014-Interoperatividad_RedAbogacia-
v1_5.doc
Revisión
1.5
Fecha
04/12/2014
Página 39 de 47
catch (MailException e) {
e.printStackTrace();
}
finally {
}
}
}
}
3. TestMailTextoPlanoFirmado
public class TestMailTextoPlanoFirmado {
public static void main(String[] args) {
ISettings is = SettingsSingleton.getInstance();
if (args.length < 4) {
System.out.println("USO: TestMailTextoPlanoFirmado mail_emisor asunto”+
usuario_cta_correo pwd_cuenta_correo");
}else{
try {
//enviamos el correo
String mail_emisor=args[0];
String
asunto=args[1];
// Generamos el texto del mail.
String user_mail=args[2];
String pw_mail =args[3];
System.out.println("USUARIO: " + user_mail + "
PWD: " + pass_mail);
IMail mail = MailFactory.getMail();
String textoMail="Esto es una prueba de texto plano firmado";
System.out.println("textoMail: " + textoMail );
try {
mail.sendMailTextoPlanoFirmado(usuario_mail,
"servicios@redabogacia.org", asunto, textoMail, usuario_mail, password_mail);
}
catch (MailException e) {
e.printStackTrace();
}
}
catch (MailException e) {
e.printStackTrace();
}
finally {
}
}
}
}
Tipo de documento:
Descripción Técnica
Código del documento
2014-Interoperatividad_RedAbogacia-
v1_5.doc
Revisión
1.5
Fecha
04/12/2014
Página 40 de 47
8.2
UTILIZACIÓN DE LA EXTENSIÓN ACCESO A BASE DE
DATOS
Paquete:
com.pra.core.demos.src.dao
Las librerías a utilizar serán las siguientes:
?
j2ee.jar, la versión que acepta Weblogic es la 1.3
?
log4j-1.2.8.jar
Las propiedades que habrá que introducir en el pra.properties serán las siguientes:
?
config.nucleo.contextos.default.elementos=
factoria,url,dedicated
(Las propiedades que
se añadirán para realizar la conexión: representan las 6 siguientes)
?
config.nucleo.contextos.default.elementos.factoria.clave=java.naming.factory.initial
(nombre de la propiedad de la factoría: No se puede cambiar)
?
config.nucleo.contextos.default.elementos.factoria.valor=
XXX
(valor de la propiedad
anterior: se especifica la clase que inicia el contexto de la factoría)
?
config.nucleo.contextos.default.elementos.url.clave=java.naming.provider.url
(nombre
de la propiedad del provider: No se puede cambiar)
?
config.nucleo.contextos.default.elementos.url.valor=
XXX
(valor
de
la
propiedad
anterior: se especifica la url de conexión del pool)
?
config.nucleo.contextos.default.elementos.dedicated.clave=dedicated.connection
(nombre de la propiedad del proceso servidor como servidor dedicado)
?
config.nucleo.contextos.default.elementos.dedicated.valor=
true
(valor de la propiedad
anterior: booleano que indica si el proceso servidor es dedicado o compartido)
Las siguientes propiedades hacen referencia a la caché que mantiene el Core. Son
necesarias para el funcionamiento del acceso a datos, ya que el DataSource creado se
mantiene en la caché con el fin de realizar respuestas más rápidas.
?
config.cache.default.maxSize=
0
(Tamaño máximo de memoria: 0 Ilimitado)
?
config.cache.default.expireTime=
1000
(Tiempo de expiración)
?
config.cache.default.useSoftReference=
false
(Usar referencias )
Las siguientes propiedades hacen referencia a la librería log4j-1.2.8.jar. Para más
información: ver LogFactory.
?
log4j.rootCategory=
DEBUG, stdout
?
log4j.appender.stdout=org.apache.log4j.ConsoleAppender
?
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
?
log4j.appender.stdout.layout.ConversionPattern=
%-4r %d{HH:mm:ss} %-5p %c{4} -
%m%n
Tipo de documento:
Descripción Técnica
Código del documento
2014-Interoperatividad_RedAbogacia-
v1_5.doc
Revisión
1.5
Fecha
04/12/2014
Página 41 de 47
Control de uso (Teoría y Práctica):
El primer paso a realizar sería la obtención de una instancia de la clase
OracleDataAccessFactory
(extends DataAccessFactory). De este modo nos crearíamos una
factoría de acceso a datos para Oracle.
OracleDataAccessFactory
miFactoriaOracle =
(
OracleDataAccessFactory
)DataAccessFactory.getDataAccessFactory(DataAccessFactory.O
RACLE);
Una vez construida la instancia, hay que configurarla con unos parámetros determinados: host,
puerto y nombreDataSource. Para ello se envían estos parámetros a través del método
setFuenteDatos. Así mismo, se pueden recuperar y enviar otra serie de parámetros.
miFactoriaOracle.setFuenteDatos("
<host>","<puerto>","<nombreDataSource>
");
Una vez tenemos la instancia preparada, se realizará un intento de conexión (conectar()) a
través de la misma, la cual nos devolverá un objeto Connection con el que trabajar para realizar
las consultas necesarias.
Connection conexion = miFactoriaOracle.conectar();
El segundo paso (aunque no obligatorio) es crear una instancia de la clase
OracleObjectDataAccess
(manejador de sentencias). Esta clase nos proporciona métodos
con los que realizar las consultas, incluidos el commit y rollback.
OracleObjectDataAccess
objDA = new OracleObjectDataAccess(conexion);
String miConsulta = "SELECT * FROM TABLA";
ArrayList resultado = objDA.find(miConsulta);
Cuando el acceso a datos se de por finalizado, a través de la factoría creada, se cierra la
conexión (desconectar()).
miFactoriaOracle.desconectar(conexion)
El servlet de Test para realizar las pruebas oportunas es el siguiente:
public class TestDAO extends HttpServlet {
private static ISettings is = SettingsSingleton.getInstance();
private static String TABLA = "ejemplo.tabla"; //NOMBRE DE LA TABLA
private static String WEBLOGIC_HOST = "ejemplo.host"; //HOST
private static String WEBLOGIC_PORT = "ejemplo.puerto"; //PUERTO
//NOMBRE DEL DATASOURCE
private static String WEBLOGIC_DATASOURCE = "ejemplo.datasource";
/* (non-Javadoc)
* @see javax.servlet.http.HttpServlet#doGet(javax.servlet.http.HttpServletRequest,
javax.servlet.http.HttpServletResponse)
*/
protected void doGet(HttpServletRequest arg0, HttpServletResponse arg1)
throws ServletException, IOException {
super.doGet(arg0, arg1);
conectar();
}
Tipo de documento:
Descripción Técnica
Código del documento
2014-Interoperatividad_RedAbogacia-
v1_5.doc
Revisión
1.5
Fecha
04/12/2014
Página 42 de 47
/**
*<br><b>Name:</B> conectar<br>
*<p><b>Description:</b>Metodo para realizar la conexión y realizar una consulta</p>
* <li> ...
*<br><br>
*/
private static void conectar() {
OracleDataAccessFactory miFactoriaOracle = null;
Connection c = null;
try {
miFactoriaOracle =
(OracleDataAccessFactory)DataAccessFactory.getDataAccessFactory(DataAccessFactory.ORACLE);
try {
miFactoriaOracle.setFuenteDatos(
(String)is.getConfiguration().getProperty(WEBLOGIC_HOST),
(String)is.getConfiguration().getProperty(WEBLOGIC_PORT),
(String)is.getConfiguration().getProperty(WEBLOGIC_DATASOURCE));
}
catch (ConfigurationException e2) {
e2.printStackTrace();
}
c = miFactoriaOracle.conectar();
OracleObjectDataAccess ooda = new OracleObjectDataAccess(c);
String sql = null;
try {
sql = "SELECT * FROM " + (String)is.getConfiguration().getProperty(TABLA);
}
catch (ConfigurationException e4) {
e4.printStackTrace();
}
try {
ArrayList resultado = ooda.find(sql);
if (resultado != null)
System.out.println("Resultado de la búsqueda:\r\n" + resultado.toString());
}
catch (ErrorDataAccess e3) {
e3.printStackTrace();
}
catch (DataNotExistException e3) {
e3.printStackTrace();
}
}
catch (SQLException e) {
e.printStackTrace();
}
catch (ClassNotFoundException e1) {
e1.printStackTrace();
}
miFactoriaOracle.desconectar(c);
}
}
Tipo de documento:
Descripción Técnica
Código del documento
2014-Interoperatividad_RedAbogacia-
v1_5.doc
Revisión
1.5
Fecha
04/12/2014
Página 43 de 47
8.3
UTILIZACIÓN DE LA EXTENSIÓN CERTIFICADO
Paquete:
com.pra.core.demos.src.certificado
En este paquete se encuentra la clase TextCertificado.java que tiene un método main al cual se
le pasa como parámetro la ruta de un certificado y extrae la información de dicho certificado.
El CN debe tener el formato:
NOMBRE
Apellido1 Apellido2 Nombre -
NIF
nif
Clase:
GenDataCert.java
Clase que se emplea para obtener la información del certificado digital de un usuario, la clase
se encuentra en el core del proyecto por lo que hay que importar el core al proyecto en el cual
se quiera obtener los datos del certificado.
Para obtener correctamente los datos del certificado que presenta un usuario para acceder vía
SSL al portal habrá que realizar los siguientes pasos:
Modificar el fichero
java.security,
que se encuentra ubicado dentro de la carpeta del jre que
está utilizando el weblogic, de forma que aparezca IAIK como segundo proveedor
security.provider.1=sun.security.provider.Sun
security.provider.2=iaik.security.provider.IAIK
security.provider.3=com.sun.net.ssl.internal.ssl.Provider
security.provider.4=com.sun.rsajca.Provider
security.provider.5=com.sun.crypto.provider.SunJCE
security.provider.6=sun.security.jgss.SunProvider
Para obtener los datos del certificado se puede utilizar el siguiente código, la información del
certificado queda almacenada en el objeto
datosCertificado
del tipo GenDataCert
public void XXXX throws IOException {
.
.
.
X509Certificate[] certificados;
GenDataCert
datosCertificado
;
//obtenemos los datos del certificado que viene en la request
certificados =
(java.security.cert.X509Certificate[]) request.getAttribute("javax.servlet.request.X509Certificate");
X509Certificate certificadoCliente = certificados[0];
if (certificadoCliente != null) {
try {
//obtenemos los datos del certificado
datosCertificado
= new GenDataCert(certificadoCliente, true);
// ya se tiene los datos del certificado almacenados en el objeto
datosCertificado
System.out.println("Datos del certificado:" + certificadoCliente.toString());
System.out.println("DN: " + datosCertificado.getDn());
System.out.println("DN Emisor: " + datosCertificado.getDnEmisor());
System.out.println("CN " + datosCertificado.getCn_dn());
System.out.println("O " + datosCertificado.getO_dn().getCodigo() + " " +
datosCertificado.getO_dn().getAbreviatura() + " " + datosCertificado.getO_dn().getNombre());
System.out.println("OU " + datosCertificado.getOu_dn());
System.out.println("T " + datosCertificado.getT_dn());
Tipo de documento:
Descripción Técnica
Código del documento
2014-Interoperatividad_RedAbogacia-
v1_5.doc
Revisión
1.5
Fecha
04/12/2014
Página 44 de 47
System.out.println("Email " + datosCertificado.getE_dn());
System.out.println("CRLS " + datosCertificado.getUrlCrlList().toString());
System.out.println("NumeroSerie " + datosCertificado.getNum_serieHx());
System.out.println("HUELLA DIGITAL " + datosCertificado.getHuella_digitalStr());
}
catch (CertificateException e) {
logger.error("Error CertificateException: " + e.getMessage());
throw e;
}
catch (FechaCaducidadException e) {
logger.error("El formato de la fecha del certificado es incorrecta");
throw new Exception("El formato de la fecha del certificado es incorrecta");
}
catch (CNException e) {
logger.error("Error CNException: " + e.getMessage());
throw new Exception("Error CNException: " + e.getMessage());
}
catch (DNSinCNException e) {
logger.error("Error DNSinCNException: " + e.getMessage());
throw new Exception("Error DNSinCNException: " + e.getMessage());
}
catch (DNSinEException e) {
logger.error("Error DNSinEException: " + e.getMessage());
throw new Exception(("Error DNSinEException: " + e.getMessage());
}
catch (DNSinOUException e) {
logger.error("Error DNSinOUException: " + e.getMessage());
throw new Exception("Error DNSinOUException: " + e.getMessage());
}
catch (OIDKOException e) {
logger.error("Error OIDKOException: " + e.getMessage());
throw new Exception("Error OIDKOException: " + e.getMessage());
}
}
}
8.4
UTILIZACIÓN DE LA EXTENSIÓN log4j
Paquete:
com.pra.core.demos.src.log4j
Description:
Clase para testear el control de trazas de una aplicacion Web
Las siguientes propiedades se tienen que definir en los distintos ficheros de propiedades
Principal: pra.properties, Backend: backend.properties, FrontEnd: frontend.properties
log4j.rootCategory=ERROR, stdout // Indica el nivel de trazas a mostrar
La jerarquía de niveles de traceo, de mayor a menor nivel, es la siguiente: FATAL->ERROR-
>WARN->INFO->DEBUG
Siempre se muestran las trazas del nivel indicado y aquellas cuyo nivel jerárquico sea superior
Por ejemplo si el nivel establecido es WARN, las trazas mostradas serían del tipo WARN,
ERROR y FATAL
Para mostrar las trazas por consola:
log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
Tipo de documento:
Descripción Técnica
Código del documento
2014-Interoperatividad_RedAbogacia-
v1_5.doc
Revisión
1.5
Fecha
04/12/2014
Página 45 de 47
log4j.appender.stdout.layout.ConversionPattern=%-4r %d{HH:mm:ss} %-5p %c{4} - %m%n
Para guardar las trazas en un fichero de trazas:
log4j.appender.stdout=org.apache.log4j.RollingFileAppender
log4j.appender.stdout.File=c:/trazas.log // Nombre del fichero de trazas
log4j.appender.stdout.MaxFileSize=10000KB // Tamaño máximo del fichero de trazas
log4j.appender.stdout.MaxBackupIndex=5 // Número máximo de ficheros de trazas guardados
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.stdout.layout.ConversionPattern=%-4r %d{HH:mm:ss} %-5p %c{3} - %m%n
public class TestLog4j {
public static void main(String[] args) {
// Se pueden obtener distintas propiedades de configuración
// y por lo tanto distintos ficheros y modos de traceo
// para aplicarlos en las distintas partes de una aplicación.
// Por ejemplo se puede utilizar la referencia BackendLog
// para mostrar trazas en los EJB's y de esta forma identificar
// en que fichero de trazas se encuentran.
// La referencia FrontLog se puede utilizar para mostrar las
// trazas en la parte WEB de una aplicación
// Obtenemos una referencia del Interfaz que encapsula los
// métodos para mostrar las trazas
// En este caso obtenemos una referencia del log backend
// Las propiedades de configuración del Log se recogen del fichero
// indicando por la propiedad "config.nucleo.settings.properties.BackEnd.conffile"
// del fichero general de propiedades. En este caso el fichero es: backend.properties
ILog loggerBackEnd=LogFactory.getBackEndLog(TestLog4j.class.getName());
loggerBackEnd.fatal("\n");
loggerBackEnd.fatal("\n");
loggerBackEnd.fatal("BACKEND.PROPERTIES: ");
loggerBackEnd.debug("Traza de DEBUG");
loggerBackEnd.info("Traza de INFO");
loggerBackEnd.warn("Traza de WARN");
loggerBackEnd.error("Traza de ERROR");
loggerBackEnd.fatal("Traza de FATAL");
// Obtenemos una referencia del Interfaz que encapsula los
// métodos para mostrar las trazas
// En este caso obtenemos una referencia del log frontend
// Las propiedades de configuración del Log se recogen del fichero indicando
// por la propiedad "config.nucleo.settings.properties.FrontEnd.conffile"
// del fichero general de propiedades. En este caso el fichero es: frontend.properties
ILog loggerFrontEnd=LogFactory.getFrontEndLog(TestLog4j.class.getName());
loggerFrontEnd.fatal("\n");
loggerFrontEnd.fatal("\n");
loggerFrontEnd.fatal("FRONTEND.PROPERTIES: \n");
loggerFrontEnd.debug("Traza de DEBUG");
loggerFrontEnd.info("Traza de INFO");
loggerFrontEnd.warn("Traza de WARN");
Tipo de documento:
Descripción Técnica
Código del documento
2014-Interoperatividad_RedAbogacia-
v1_5.doc
Revisión
1.5
Fecha
04/12/2014
Página 46 de 47
loggerFrontEnd.error("Traza de ERROR");
loggerFrontEnd.fatal("Traza de FATAL");
// Obtenemos una referencia del Interfaz que encapsula los
// métodos para mostrar las trazas
// En este caso obtenemos una referencia del log principal
// Las propiedades de configuración del Log se recogen del
// fichero principal de propiedades: pra.properties
ILog logger=LogFactory.getCoreLog(TestLog4j.class.getName());
logger.fatal("PRA.PROPERTIES: \n");
logger.debug("Traza de DEBUG");
logger.info("Traza de INFO");
logger.warn("Traza de WARN");
logger.error("Traza de ERROR");
logger.fatal("Traza de FATAL");
// Prueba para la obtención de propiedades de configuración
// de los ficheros de propiedades
// Se pueden obtener propiedades de los tres ficheros
// de propiedades antes descritos:
// pra.properties para propiedades principales
// backend.properties para propiedades del backend
// frontend.properties para propiedades del frontend
ISettings is = SettingsSingleton.getInstance();
try {
Configuration isPrincipal = is.getConfiguration();
Configuration isBackend = is.getBackEndConfiguration();
Configuration isFrontend = is.getFrontEndConfiguration();
logger.debug("\n");
String logGeneral = isPrincipal.getProperty("property.principal");
logger.debug("LA propiedad property.principal tiene el valor: "+logGeneral);
String logBackEnd = isBackend.getProperty("property.backend");
logger.debug("LA propiedad property.backend tiene el valor: "+logBackEnd);
String logFrontEnd = isFrontend.getProperty("property.frontend");
logger.debug("LA propiedad property.frontend tiene el valor: "+logFrontEnd);
}
catch (ConfigurationException e) {
e.printStackTrace();
}
}
}
Tipo de documento:
Descripción Técnica
Código del documento
2014-Interoperatividad_RedAbogacia-
v1_5.doc
Revisión
1.5
Fecha
04/12/2014
Página 47 de 47
9
DOCUMENTACIÓN DE REFERENCIA
Título del documento
Nombre del fichero
Tipo
Versión
Arquitectura
PANEL_0053_04_DA_Arquitectura_v.1.0.doc
Doc
1.0
Procedimientos Operativos
PANEL_0053_04_DA_Procedimientos_v.1.0.doc
Doc
1.0
API-Documento
PANEL_0053_04_DA_API-Interoperatividad.zip
Zip
1.0
Back to top
