Conselleria de Sanitat - Misser Mascó, 31 y 33 • 46010 VALÈNCIA • Tel. 96 386 66 00 • Fax 96 386 66 07
Normas:Normativa de desarrollo e
implantación
Nombre Archivo 2-NOR01-Normas Normativa deDesarrollo e Implantacion-01-02-131204.odt
Versión 01-02
Estado Publicado
Fecha Impresión
Fecha Salvado 04/12/2013 14:43:05
Fecha Caducidady/o Revisión
2-N
OR
01-N
orm
as-E
stan
dare
s de
sarr
ollo
e im
plan
taci
ón-0
0-00
-110
7201
12-
NO
R01
-Nor
mas
-Est
anda
res
desa
rrol
lo e
impl
anta
ción
-00-
00-1
1072
011
CONTROL DEL DOCUMENTOA. Versiones Publicadas del Documento
Versión Fecha 1 Promotor Descripción de la Versión
01.00 23/10/11 Amparo Izquierdo Primera versión01.01 30/09/13 Raúl Jiménez Revisión normas y estándares para facilitar la gestión de
las entregas y la evaluación de las mismas.Versionado de scripts de BBDD.Revisión de Estandares de Servidores de AplicaciónEliminación de contenidos obsoletos y/o redundantes.
01,02 04/12/13 Raúl Jiménez Revisión menor que incluye cambios consensuados conSGPTIC
B. Documentos relacionados
Título o nombre del fichero Naturaleza de la relació n
C. Destinatarios del documento• Categorización de Seguridad 2 • Lista de Distribución 3:
o Dirigido a: o Restringido a:
D. Participantes en la Edición
Rol 4 Nombre Organización / PuestoEditor Jose María Cubel GEES
E. Estatus de la versión en edición
Estado 5 V6 Fecha7 Autor Rol Observaciones del estado
Borrador 01.02 Jose Mª Cubel Editor
1Fecha: en la que se publica la versión del documento2 Categorización de Seguridad: ALTO si un riesgo de seguridad supone un perjuicio muy grave para la AVS, MEDIO para un
perjuicio grave y BAJO para un perjuicio limitado.3 Lista de Distribución: En caso que la distribución no se corresponda con el estándar de derechos de acceso, identifique las
personas o roles a los que positivamente se debe otorgar acceso y a cuales restringirlo.4 Rol: Registre su rol en la edición de este documento: Promotor, Redactor, Revisor, Publicador5 Estado: Borrador / Visado / Aprobado / Publicado / Revisado6V: Versión Mayor y Menor7Fecha: Especificar la fecha del Estado
Archivo: 2-NOR01-Normas-Estandares Desarrollo e implantacion-01.02-131204 Página 2 de 58Fecha de la última modificación: 04/12/13
BAJO
2-N
OR
01-N
orm
as-E
stan
dare
s de
sarr
ollo
e im
plan
taci
ón-0
0-00
-110
7201
12-
NO
R01
-Nor
mas
-Est
anda
res
desa
rrol
lo e
impl
anta
ción
-00-
00-1
1072
011
Estado V Fecha Autor Rol Observaciones del estado
Visado 01.02 04/12/13 Jose Mª CubelAprobado 01.02 04/12/13 Amparo Izquierdo
Raul JimenezResponsable AVS
Publicado 01.02 04/12/13 Ana Server Aranda GCAPRevisado
Archivo: 2-NOR01-Normas-Estandares Desarrollo e implantacion-01.02-131204 Página 3 de 58Fecha de la última modificación: 04/12/13
2-N
OR
01-N
orm
as-E
stan
dare
s de
sarr
ollo
e im
plan
taci
ón-0
0-00
-110
7201
12-
NO
R01
-Nor
mas
-Est
anda
res
desa
rrol
lo e
impl
anta
ción
-00-
00-1
1072
011
Índice 1PROPÓSITO DEL DOCUMENTO................................................................................................................................6
2ÁMBITO Y APLICACIÓN.............................................................................................................................................7
3ESTANDARES DE SISTEMAS BBDD.........................................................................................................................8
3.1ESTANDARES DE OBJETOS DE BASE DE DATOS.....................................................................................................................83.1.1Nomenclatura.....................................................................................................................................................8
3.1.2Permisos de Base de Datos.................................................................................................................................8
3.1.3Usuarios Propietarios........................................................................................................................................9
3.1.4Usuarios de Aplicaciones...................................................................................................................................9
3.1.5Usuarios de ejecución de trabajos de Base de Datos.......................................................................................10
3.2NOMENCLATURA DE OBJETOS DE BASE DE DATOS.............................................................................................................103.2.1Usuarios............................................................................................................................................................10
3.2.2Roles.................................................................................................................................................................10
3.2.3Database Lynks.................................................................................................................................................11
3.2.4Database Triggers............................................................................................................................................11
3.2.5Indices...............................................................................................................................................................11
3.2.6Vistas Materializadas.......................................................................................................................................12
3.2.7Snapshots..........................................................................................................................................................12
3.2.8Packages...........................................................................................................................................................12
3.2.9Sequences..........................................................................................................................................................12
3.2.10Tablas.............................................................................................................................................................12
3.2.11Vistas...............................................................................................................................................................13
3.2.12Tablespaces.....................................................................................................................................................13
3.3FORMATO ESTÁNDAR SCRIPTS DE BBDD..........................................................................................................................133.3.1Scripts DDL......................................................................................................................................................14
3.3.2Scripts DML......................................................................................................................................................15
3.3.3Versionado de scripts de BBDD.......................................................................................................................15
4ESTÁNDARES DE SERVIDORES DE APLICACIÓN............................................................................................17
4.1CONFIGURACIÓN: PROPERTIES Y LOGS..............................................................................................................................174.1.1Archivo de Configuración Común....................................................................................................................17
4.1.2Archivo de configuración Local de Aplicación................................................................................................17
4.1.3Archivo de Configuración de Log.....................................................................................................................18
4.2CERTIFICADOS DIGITALES...............................................................................................................................................194.3CONTENIDO ESTÁTICO....................................................................................................................................................204.4OTROS CONTENIDOS ......................................................................................................................................................214.5ESTRUCTURA DE APLICACIONES JEE...............................................................................................................................214.6DATASOURCE EN SERVIDOR DE APLICACIONES....................................................................................................................224.7USO DEL SISTEMA DE FICHEROS DE LA CONSELLERIA DE SANITAT.........................................................................................23
5ESTÁNDARES DE DESARROLLO............................................................................................................................24
5.1NOMENCLATURA...........................................................................................................................................................255.2INFRAESTRUCTURA DE DESARROLLO..................................................................................................................................25
5.2.1Requisitos de infraestructura............................................................................................................................25
5.2.2Requisitos en los nombres de ficheros y directorios........................................................................................26
5.2.3Prácticas...........................................................................................................................................................26
5.2.4Herramientas de desarrollo y generación de desplegables.............................................................................27
5.2.5Estructura de paquetes.....................................................................................................................................28
5.2.6Estructura de directorios..................................................................................................................................29
5.2.7Generación del entregable...............................................................................................................................29
5.3GESTIÓN DE VERSIONES..................................................................................................................................................305.4ARQUITECTURA DEL CÓDIGO............................................................................................................................................30
5.4.1Prácticas...........................................................................................................................................................30
5.4.2Aspectos transversales......................................................................................................................................30
5.4.2.1JavaDoc y documentación interna................................................................................................................30
5.4.2.2Logging........................................................................................................................................................31
Archivo: 2-NOR01-Normas-Estandares Desarrollo e implantacion-01.02-131204 Página 4 de 58Fecha de la última modificación: 04/12/13
2-N
OR
01-N
orm
as-E
stan
dare
s de
sarr
ollo
e im
plan
taci
ón-0
0-00
-110
7201
12-
NO
R01
-Nor
mas
-Est
anda
res
desa
rrol
lo e
impl
anta
ción
-00-
00-1
1072
011
5.4.2.3Manejo de excepciones................................................................................................................................32
5.4.2.4Transaccionalidad........................................................................................................................................32
5.4.2.5Contenido XML...........................................................................................................................................33
5.4.2.6Internacionalización (I18N)..........................................................................................................................345.4.3Modularización y capas....................................................................................................................................34
5.4.3.1Capa de presentación....................................................................................................................................35
5.4.3.2Capa de servicios..........................................................................................................................................35
5.4.3.3Capa de acceso a datos.................................................................................................................................355.4.4Otros.................................................................................................................................................................37
5.4.4.1Librerías comunes........................................................................................................................................37
5.4.4.2Generación de informes................................................................................................................................38
5.4.4.3Planificadores de tareas................................................................................................................................385.5BASE DE DATOS.............................................................................................................................................................38
5.5.1Oracle...............................................................................................................................................................38
5.6SEGURIDAD..................................................................................................................................................................395.7LOGIN.........................................................................................................................................................................40
5.7.1Single Sign-On y gestión de identidades..........................................................................................................40
5.7.2Accesos.............................................................................................................................................................40
5.8INTEGRACIONES.............................................................................................................................................................405.8.1Servicios Web....................................................................................................................................................40
5.8.2Rhapsody...........................................................................................................................................................42
5.8.3Envío y recepción de correos electrónicos.......................................................................................................42
5.9IMAGEN Y ASPECTO DE LAS APLICACIONES.........................................................................................................................425.10TESTEO......................................................................................................................................................................43
5.10.1Pruebas unitarias............................................................................................................................................44
5.11ASPECTOS METODOLÓGICOS TÉCNICOS.............................................................................................................................455.12ANÁLISIS ESTÁTICO DE LA APLICACIÓN............................................................................................................................46
ANEXO A. GLOSARIO DE TÉRMINOS Y SIGLAS.................................................................................................47
ANEXO B. DOSSIERS DE TECNOLOGÍAS DE DESARROLLO...........................................................................48
SPRING.............................................................................................................................................................................48Spring Test................................................................................................................................................................48
Spring AOP...............................................................................................................................................................48
HIBERNATE........................................................................................................................................................................48JSF.................................................................................................................................................................................49
Recomendaciones generales.....................................................................................................................................49
Managed Beans........................................................................................................................................................52
Navegación...............................................................................................................................................................52
Facelets.....................................................................................................................................................................52
Datatables.................................................................................................................................................................52
Event Handling.........................................................................................................................................................52
Composite.................................................................................................................................................................53
Ajax...........................................................................................................................................................................53
MAVEN.............................................................................................................................................................................53ANT.................................................................................................................................................................................56QUARTZ............................................................................................................................................................................57
ANEXO C. CLASE JAVA PARA CERTIFICADOS A TRAVÉS DE REVERSE PROXY....................................58
Archivo: 2-NOR01-Normas-Estandares Desarrollo e implantacion-01.02-131204 Página 5 de 58Fecha de la última modificación: 04/12/13
2-N
OR
01-N
orm
as-E
stan
dare
s de
sarr
ollo
e im
plan
taci
ón-0
0-00
-110
7201
12-
NO
R01
-Nor
mas
-Est
anda
res
desa
rrol
lo e
impl
anta
ción
-00-
00-1
1072
011
1 Propósito del documento
El objetivo de este documento es definir una norma que los Sistemas de
Información deben seguir en su ciclo de vida, principalmente desarrollo y despliegue, para
su perfecta adaptación a los diferentes entornos corporativos del CPD del Centro de
Informática de la Consellería de Sanidad y con el propósito que la implantación sea lo
más homogénea posible.
Archivo: 2-NOR01-Normas-Estandares Desarrollo e implantacion-01.02-131204 Página 6 de 58Fecha de la última modificación: 04/12/13
2-N
OR
01-N
orm
as-E
stan
dare
s de
sarr
ollo
e im
plan
taci
ón-0
0-00
-110
7201
12-
NO
R01
-Nor
mas
-Est
anda
res
desa
rrol
lo e
impl
anta
ción
-00-
00-1
1072
011
2 Ámbito y aplicación
Está enfocado principalmente en 3 grandes grupos:
• Desarrollos a medida.
• Parametrización de los Sistemas de Información propietarios residentes en el CPD
del Centro de Informática de la Consellería de Sanidad.
• Implantación de los Sistemas de Información en el CPD del Centro de Informática
de la Consellería de Sanidad.
Archivo: 2-NOR01-Normas-Estandares Desarrollo e implantacion-01.02-131204 Página 7 de 58Fecha de la última modificación: 04/12/13
2-N
OR
01-N
orm
as-E
stan
dare
s de
sarr
ollo
e im
plan
taci
ón-0
0-00
-110
7201
12-
NO
R01
-Nor
mas
-Est
anda
res
desa
rrol
lo e
impl
anta
ción
-00-
00-1
1072
011
3 Estandares de Sistemas BBDD
3.1 Estandares de objetos de Base de Datos.
Por cada aplicación existirá un esquema de Base de Datos diferente. Las
referencias a los objetos de cada uno de estos esquemas, se harán, siempre,
anteponiendo el nombre del esquema: en general, no se usarán sinónimos públicos y
privados.
Por otra parte en la BD no se permiten procedimientos ni funciones anónimas.
3.1.1 Nomenclatura.
Todos los objetos creados por el usuario propietario de una aplicación deberán
quedar perfectamente identificados como pertenecientes a él. Es recomendable que los
objetos del componente no almacenados en la BD (por ejemplo, ficheros del sistema
operativo), sigan también un esquema de nomenclatura que identifique perfectamente a
qué componente pertenece.
Como es evidente, se recomienda, además, no utilizar nombres de objetos de BD
con caracteres especiales o de longitud mayor de 18 caracteres. En el caso de usar
nombres con el carácter “_” habrá que asegurarse que si se eliminara ese carácter del
identificador, no se producen duplicados con otros identificadores.
Después del identificador del esquema, aparecerá un código de tipo de objeto. A
continuación vendrá el nombre asignado por el desarrollador al objeto siguiendo su propio
estándar. Por ejemplo para una tabla de SIA: US_SIA.TACONTACTO.
3.1.2 Permisos de Base de Datos.
No se concede ninguno de los roles predefinidos: connect, resource o dba. El
permiso de conexión se garantiza con el role conexión cuyo único privilegio es create
session. Este role estará concedido por defecto. En general, el resto de roles del usuario
estarán desactivados y será la aplicación la encargada vía modulo de seguridad o vía
aplicativo de activarlos explícitamente, es decir, no se utilizará set role all .
Los usuarios propietarios, además de este role, tendrán un role especial de creación
de objetos. Este role es el ROL_DESA y esta formado por los siguientes permisos de
sistema:
Archivo: 2-NOR01-Normas-Estandares Desarrollo e implantacion-01.02-131204 Página 8 de 58Fecha de la última modificación: 04/12/13
2-N
OR
01-N
orm
as-E
stan
dare
s de
sarr
ollo
e im
plan
taci
ón-0
0-00
-110
7201
12-
NO
R01
-Nor
mas
-Est
anda
res
desa
rrol
lo e
impl
anta
ción
-00-
00-1
1072
011
CREATE TYPE
CREATE TRIGGER
ALTER SESSION
CREATE VIEW
CREATE ANY CONTEXT
CREATE INDEXTYPE
CREATE TABLE CREATE DATABASE LINK
CREATE PROCEDURE
CREATE CLUSTER
CREATE DIMENSION
CREATE SEQUENCE
CREATE SYNONYM
CREATE MATERIALIZED VIEW
CREATE OPERATOR
Con estos permisos, el rol, ROL_DESA, debe bastar para desarrollar el esquema de
la aplicación. Por otra parte, aunque es desaconsejable, se acepta una anidación de
primer nivel en los roles.
3.1.3 Usuarios Propietarios.
Serán los que concedan permisos, mediante roles, al resto de usuarios que utilicen
la aplicación. Por defecto, estos usuarios no tendrán habilitado el permiso de conexión a
la BD. Se les habilitará cuando haya que realizar alguna modificación en sus objetos y se
les volverá a retirar cuando haya finalizado la actuación.
Cuando un usuario propietario de objetos de BD necesite permisos sobre objetos de
otras aplicaciones, se creará un role para asignar los permisos de cada uno de esos
componentes. De la misma forma, si lo que requiere son privilegios del sistema, deberán
asignarse también a través de un solo role creado al efecto. Aún así, es posible que el
usuario propietario requiera algunos permisos o privilegios asignados de forma directa,
caso de compilación de paquetes o procedimientos.
3.1.4 Usuarios de Aplicaciones.
En algunas ocasiones (pool de conexiones, usuarios de pruebas o de formación), el
usuario personalizado no es posible o no resulta práctico. Si se diera esta situación, el
nombre de estos usuarios deberá identificar la aplicación a la que pertenece y el uso para
el que ha sido creado.
No se concederán permisos directos sobre objetos a los usuarios finales: siempre a
través de roles . Además, estos roles identificarán unívocamente el perfil del usuario de
forma que haya un sólo role por perfil del usuario en el componente. Por otra parte, se
crearán roles
adicionales para los privilegios del sistema que sea necesario asignar. Como antes,
habrá un role con privilegios del sistema por cada perfil de usuario que los necesite. Por
Archivo: 2-NOR01-Normas-Estandares Desarrollo e implantacion-01.02-131204 Página 9 de 58Fecha de la última modificación: 04/12/13
2-N
OR
01-N
orm
as-E
stan
dare
s de
sarr
ollo
e im
plan
taci
ón-0
0-00
-110
7201
12-
NO
R01
-Nor
mas
-Est
anda
res
desa
rrol
lo e
impl
anta
ción
-00-
00-1
1072
011
último, si el usuario final requiere permisos sobre objetos de otras aplicaciones, se creará
un role por perfil y aplicación para asignarlos.
Se crearán distintos perfiles para garantizar que se cumplen las medidas de
seguridad acordes con el tipo de fichero declarado (por ejemplo número de login’s fallidos
permitidos, bloqueo de cuentas, tiempo máximo de inactividad...etc)
El usuario genérico con el que se realiza la conexión cumplirá todo lo dicho
anteriormente y será el aplicativo el que se encargará de garantizar el cumplimiento de la
legalidad vigente en materia de seguridad, así como de facilitar los permisos que necesita
dicho usuario y otorgarlos con el usuario propietario de la aplicación en un despliegue de
la misma.
3.1.5 Usuarios de ejecución de trabajos de Base de D atos.
Por otra parte, en el caso de programar procesos batch de base de datos, se
definirá un único usuario encargado de lanzar todos los procesos en esa BD por parte de
su aplicación. Este usuario deberá tener concedidos los permisos necesarios para
ejecutar todos estos trabajos, estos permisos debe concederlos el usuario propietario, y,
aunque se trata de un DCL (Data Control Language) deberán otorgarse en un despliegue
de la aplicación. Este usuario debe ser el encargado de la ejecución de los DML (Data
Manipulation Language) así como de la ejecución de los SQL que se soliciten.
3.2 Nomenclatura de Objetos de Base de Datos.
3.2.1 Usuarios.
Los nombres de usuarios propietarios de objetos en la BD seguirán el siguiente
esquema:
US_XXXXX. Dónde XXXXX es el identificativo de la aplicación y que debe venir
definido en su Ficha de Diseño.
Éstos cinco caracteres los utilizaremos en todos los objetos. Un detalle a tener en
cuenta es que existen nombres que no es posible o, por lo menos, no es conveniente
emplear. Se incluyen aquí palabras reservadas, funciones predefinidas, etc.
3.2.2 Roles.
El identificador de los roles creados para el funcionamiento de cada aplicación
seguirá la siguiente regla de nomenclatura:
ROXXXXX_<nombre role>
Archivo: 2-NOR01-Normas-Estandares Desarrollo e implantacion-01.02-131204 Página 10 de 58Fecha de la última modificación: 04/12/13
2-N
OR
01-N
orm
as-E
stan
dare
s de
sarr
ollo
e im
plan
taci
ón-0
0-00
-110
7201
12-
NO
R01
-Nor
mas
-Est
anda
res
desa
rrol
lo e
impl
anta
ción
-00-
00-1
1072
011
Donde “XXXXX” son los caracteres que identifican la aplicación dónde se utilizará el
role. El nombre del role hará referencia al colectivo de usuarios para el que se crea.
Si el role contiene los permisos sobre objetos de otra aplicación el formato de
identificador del role será:
ROXXXXXYYYYYY_<nombre role>
Donde “YYYYY” es el nombre del propietario de los objetos sobre los que se asigna
permisos y “XXXXX” el que los recibe.
Si lo que se asignan son privilegios del sistema, los caracteres “YYYYY” se
sustituyen por “SYS”:
ROXXXSYS<nombre role>
Hay que tener en cuenta que el tamaño máximo del nombre de un rol es de 30
caracteres.
3.2.3 Database Lynks.
Será del estilo aXXXXX donde XXXXX representa el sid de la base de datos a la
que se conecta.
3.2.4 Database Triggers.
El formato del nombre de los triggers de BD será:
TR_XXXXX_<nombre trigger>
3.2.5 Indices.
En general, los índices se nombrarán:
IN_<nombre de índice>
Sin embargo, si el índice se usa para implementar algún tipo de restricción sobre la
tabla base, deberá identificarse el tipo de restricción:
• Claves primarias. Se indicará que se trata de una clave primaria así:
IP_<nombre índice>
• Claves alternativas. Se utilizará el formato:
IU_<índice único>
• Claves ajenas. De la misma forma se usará:
IF_<índice para referencias>
Archivo: 2-NOR01-Normas-Estandares Desarrollo e implantacion-01.02-131204 Página 11 de 58Fecha de la última modificación: 04/12/13
2-N
OR
01-N
orm
as-E
stan
dare
s de
sarr
ollo
e im
plan
taci
ón-0
0-00
-110
7201
12-
NO
R01
-Nor
mas
-Est
anda
res
desa
rrol
lo e
impl
anta
ción
-00-
00-1
1072
011
3.2.6 Vistas Materializadas.
Seguirán el formato:
MV_XXXXX_<nombre vista materializada>
3.2.7 Snapshots.
Sus nombres tendrán el formato:
SN_<nombre de snapshot>
3.2.8 Packages.
Como de costumbre, el formato será:
PK_<nombre paquete>
3.2.9 Sequences.
Los identificadores de las secuencias seguirán el estándar:
SE<nombre secuencia>
3.2.10 Tablas.
Las tablas se nombrarán de la siguiente manera:
TA_XXXXX_<nombre tabla>
Adicionalmente, cada una de las restricciones definidas sobre las tablas seguirán el
siguiente formato:
Checks. A excepción de las validaciones de nulidad, se usará el siguiente nombre:
CH<nombre de validación>
Claves primarias. Se indicará que se trata de una clave primaria así:
PK_XXXXX_<nombre clave primaria>. El nombre de la clave primaria contendrá al
menos tres caracteres referentes a la tabla.
Claves alternativas. Se utilizará el formato:
AK_XXXXX_<clave alternativa>. El nombre de la clave alternativa contendrá al
menos tres caracteres referentes a la tabla.
Claves ajenas. De la misma forma, se usará:
FK_XXXXX_<clave>. El nombre de la clave primaria contendrá al menos tres
caracteres referentes a la tabla donde se define y
otros tres referentes a la tabla referenciada, en este orden.Archivo: 2-NOR01-Normas-Estandares Desarrollo e implantacion-01.02-131204 Página 12 de 58Fecha de la última modificación: 04/12/13
2-N
OR
01-N
orm
as-E
stan
dare
s de
sarr
ollo
e im
plan
taci
ón-0
0-00
-110
7201
12-
NO
R01
-Nor
mas
-Est
anda
res
desa
rrol
lo e
impl
anta
ción
-00-
00-1
1072
011
3.2.11 Vistas.
Por último, las vistas:
VI<nombre vista>
3.2.12 Tablespaces.
Se definirán los siguientes tablespaces por sistema:
App_Datos_Grandes: para objetos (excluyendo índices) de más de 300mb, y los
diferentes tipos de LOB
App_Datos: para el resto de objetos (excluyendo indices)
App_Indices_grandes: para aquellos superiores a 300mb
App_Indices: para el resto de los índices
Para cada uno de estos tablespaces se definirán los correspondientes datafiles para
el propietario con la misma notación a la que se añadirá un numeral al final.
3.3 Formato estándar scripts de BBDD
Para facilitar la ejecución de scripts en base de datos, ya sean despliegues o
peticiones, es necesario normalizar tanto el formato de los scripts como la nomenclatura
de los mismos.
Un despliegue puede implicar la necesidad de modificar objetos del esquema de
Base de Datos. En este caso, es necesario facilitar los scripts DDL, Data Definition
Language. Estos DDL debe estar organizados de manera que, en caso de error, la
marcha atrás sea lo mas sencilla posible. Se recomienda crear tantos scripts como
unidades de ejecución o puntos de control se consideren necesarios para, así, agilizar la
marcha atrás en caso que fuera necesario. También puede ser necesaria la actualización
de datos mediante DML, Data Manipulation Language, ya sea en un despliegue, por
necesidades del mismo, o por petición. Se recomienda extraer la ejecución de los DML de
los posibles despliegues ya que los errores en los que se puede incurrir podrían provocar
una marcha atrás de la versión, cuando, tal vez, esta ejecución podría haberse realizado
de manera independiente al despliegue.
Es recomendable seguir una nomenclatura que aclare la ejecución de los scripts por
eso, se ha optado por solicitar que los nombres de los scripts venga con un prefijo que
identifique el orden de ejecución así como la naturaleza del mismo. Los nombres de los
scripts deben ser:
#-DDD-xxxxxxxxx.sql
Archivo: 2-NOR01-Normas-Estandares Desarrollo e implantacion-01.02-131204 Página 13 de 58Fecha de la última modificación: 04/12/13
2-N
OR
01-N
orm
as-E
stan
dare
s de
sarr
ollo
e im
plan
taci
ón-0
0-00
-110
7201
12-
NO
R01
-Nor
mas
-Est
anda
res
desa
rrol
lo e
impl
anta
ción
-00-
00-1
1072
011
Donde # es el orden de ejecución desde el 1 en adelante y DDD es la naturaleza del
script ya sea DDL o DML, por ejemplo:
1-DDL-Creacion_tablas.sql
2-DDL-Creacion_indices.sql
3-DML-Inserts.sql
3.3.1 Scripts DDL
Los scripts DDL, como ya se ha mencionado, solo pueden solicitarse como parte de
un despliegue, ya que implican un cambio. Estos pueden contener tanto la creación de
objetos, modificación o borrado de los mismos, así como la concesión de permisos (DCL)
de los objetos a otros esquemas/aplicaciones.
Además de la nomenclatura que ya se ha definido anteriormente, es necesario tener
en cuenta que estos DDL deben ser ejecutados, exclusivamente por el propietario del
esquema, en ningún caso, por un usuario administrador. Sin embargo, para poder
ejecutar el script si que es necesario conceder el permiso de CONEXIÓN para poder
ejecutarse, por ese motivo la plantilla debe ser:prompt "NOTA"
prompt "Parámetro 1: Password de USU_ADM, DUMMY si no se usa"
prompt "Parámetro 2: Base de datos"
prompt "Parámetro 3: Nombre del fichero de log"
PROMPT 'Introducir password de USU_ADM (1) y Base de Datos (2)'
conn usu_adm/&1@&2
spool &3
grant conexion to US_APLICACION;
connect US_APLICACION/US_APLICACION@&2
select to_char(sysdate,'dd/mm/yyyy HH24:MI:SS') inicio from dual;
------------- Inicio script ---------------
--------------- fin script ----------------
select to_char(sysdate,'dd/mm/yyyy HH24:MI:SS') fin from dual;
spool off;
conn usu_adm/&1@&2
revoke conexión from US_APLICACION;
exit
Puede darse el caso que sea necesario algún parámetro más, en este caso se
puede modificar la plantilla añadiendo el parámetro necesario y documentandolo
correctamente en el formulario de despliegue.
Archivo: 2-NOR01-Normas-Estandares Desarrollo e implantacion-01.02-131204 Página 14 de 58Fecha de la última modificación: 04/12/13
2-N
OR
01-N
orm
as-E
stan
dare
s de
sarr
ollo
e im
plan
taci
ón-0
0-00
-110
7201
12-
NO
R01
-Nor
mas
-Est
anda
res
desa
rrol
lo e
impl
anta
ción
-00-
00-1
1072
011
3.3.2 Scripts DML
Los scripts DML, se usa para modificar o manipular los datos que contienen las
tablas de una aplicación, aunque puede ejecutarse dentro de un despliegue, si es posible,
recomendamos ejecutarlos mediante petición para evitar posibles errores en el
despliegue. Sin embargo, si la aplicación tiene como requisito para el despliegue la
actualización de datos, pueden incluirse.
La plantilla que se usa para la ejecución de DML se diferencia de la utilizada para la
ejecución de DDL, principalmente, en el usuario con que se conecta para llevar a cabo las
acciones. En los DML debe utilizarse el usuario US_APLICACION_OPER que, como se
ha definido, debe tener todos los permisos para consultar y modificar los datos que sean
necesarios.
Un ejemplo de la plantilla modificado sería:prompt "NOTA"
prompt "Parámetro 1: Password de US_APLICACION_OPER, DUMMY si no se usa"
prompt "Parámetro 2: Base de datos"
prompt "Parámetro 3: Nombre del fichero de log"
PROMPT 'Introducir password de US_APLICACION_OPER (1) y Base de Datos (2)'
conn US_APLICACION_OPER/&1@&2
spool &3
select to_char(sysdate,'dd/mm/yyyy HH24:MI:SS') inicio from dual;
------------- Inicio script ---------------
--------------- fin script ----------------
select to_char(sysdate,'dd/mm/yyyy HH24:MI:SS') fin from dual;
spool off;
exit
3.3.3 Versionado de scripts de BBDD
Los fuentes de la aplicación deben contemplar el versionado de los scripts de BBDD.
Incluirán tanto las SQLs necesarias para actualizar el modelo de datos la aplicación de a versión
actual, como todo el histórico de SQLs usadas en versiones anteriores. Uno de los objetivos
fundamentales de estos cambios, es poder realizar pruebas de integración de la aplicación con la
BBDD y análisis del modelo de datos.
Las SQLs incluidas en los fuentes deben permitir recrear el modelo de datos de la versión
desde cero, por lo que se exigirá la existencia de un script, cuya ejecución genere el modelo de
datos desde cero. Este script invocará secuencialmente las DDLs y DMLs de todas las versiones
Archivo: 2-NOR01-Normas-Estandares Desarrollo e implantacion-01.02-131204 Página 15 de 58Fecha de la última modificación: 04/12/13
2-N
OR
01-N
orm
as-E
stan
dare
s de
sarr
ollo
e im
plan
taci
ón-0
0-00
-110
7201
12-
NO
R01
-Nor
mas
-Est
anda
res
desa
rrol
lo e
impl
anta
ción
-00-
00-1
1072
011
de marcha adelante hasta la versión entregada. Será responsabilidad del proveedor evolucionar
este script a medida que evolucione el modelo de datos. Independientemente que la versión
entregada no modifique el modelo de datos, GEES ejecutará el script lanzador para poder realizar
pruebas de integración y asegurar que los scripts son consistentes.
Propuesta de estructura para organizar sqls en los fuentes y de nomenclatura de scripts:
Directorio sql en la raíz de los fuentes entregados
Un directorio para los scripts de cada versión, siguiendo la
nomenclatura de versiones especificada en normativa.
Un subdirectorio dentro de las sqls de la versión para los
scripts que actualizan el modelo (upgrade). Dentro de
ese directorio, un script (_upgrade.sql ) que invoque
secuencialmente a todas las sqls necesarias para
actualizar la versión (con esto se simplifica la instrucción
de ejecución de sqls de la versión). Este directorio
contendrá también las sqls a las que invoca el script
lanzador (DDL, DML, procedimientos almacenados, ...)
debiendo cumplir la normativa ya existente para nombrar
esos ficheros.
Un subdirectorio dentro de la versión para las sqls que hacen
la reversión (downgrade). Dentro de ese directorio, un
script (_downgrade.sql ) que invoque secuencialmente a
todas las sqls de reversión la versión. Este directorio
incluirá también las sqls a las que invoca el script
lanzador (DDL -tablas, índices, vistas, secuencias,
triggers, procedimientos almacenados- o DML) debiendo
seguir la normativa ya existente para nombrar esos
ficheros.
Un script (full.sql ) que invoque secuencialmente a los scripts
lanzadores de marcha adelante de cada versión
(1.0/upgrade/_upgrade.sql;1.1/upgrade/_upgrade.sql;1.2/
sql/_upgrade.sql;2.0/upgrade/_upgrade.sql;) .
Archivo: 2-NOR01-Normas-Estandares Desarrollo e implantacion-01.02-131204 Página 16 de 58Fecha de la última modificación: 04/12/13
2-N
OR
01-N
orm
as-E
stan
dare
s de
sarr
ollo
e im
plan
taci
ón-0
0-00
-110
7201
12-
NO
R01
-Nor
mas
-Est
anda
res
desa
rrol
lo e
impl
anta
ción
-00-
00-1
1072
011
4 Estándares de Servidores de Aplicación
La mayor parte de las aplicaciones hacen uso de archivos de propiedades para
definir parámetros de la aplicación: cadena de conexión a BD, URLs de acceso a otros
componentes, etc. así como de creación de ficheros de log para el análisis de errores y
mejoras en la aplicación. El mantenimiento de estos archivos no es trivial cuando se
engloba en el ámbito de la infraestructura de sistemas de los múltiples proyectos
abordados por la Consellería. Por ello en este documento vamos a describir la distinta
operativa de la que dispone la Consellería de Sanitat.
4.1 Configuración: Properties y Logs
4.1.1 Archivo de Configuración Común
Para simplificar el mantenimiento de ciertos parámetros relacionados con la
infraestructura de sistemas se van a unificar todos las propiedades comunes a todas las
aplicaciones de la Conselleria de Sanidad en un único archivo en una ubicación conocida:
/etc/app/conf/comun.properties ($APP_CONF)
Este archivo no se despliega con las aplicaciones y se mantiene de forma manual.
Este archivo es común a todos los entornos. Los parámetros globales a todas las
aplicaciones se definirían de esta forma:
# descripción del parámetro
nombre=valor
Los parámetros de aplicación usados por otras aplicaciones se definirían añadiendo
un prefijo distintivo delante del parámetro:
# descripción del parámetro
codapli.nombre=valor
4.1.2 Archivo de configuración Local de Aplicación.
Dado que hay parámetros que son diferentes en los distintos entornos, (aunque NO
entre las máquinas de un mismo entorno), y dado que cada aplicación necesitará también
definir determinados parámetros propios, será necesario mantener, además del archivo
global, otro archivo de configuración por cada aplicación.
Archivo: 2-NOR01-Normas-Estandares Desarrollo e implantacion-01.02-131204 Página 17 de 58Fecha de la última modificación: 04/12/13
2-N
OR
01-N
orm
as-E
stan
dare
s de
sarr
ollo
e im
plan
taci
ón-0
0-00
-110
7201
12-
NO
R01
-Nor
mas
-Est
anda
res
desa
rrol
lo e
impl
anta
ción
-00-
00-1
1072
011
La ubicación de este archivo será:
/etc/app/conf/$PROY/$APP/local.$APP.properties
Además, y dado que los proyectos actuales están formados por una mezcla de
desarrollos propios y de terceros, la configuración y parametrización de los distintos
componentes de un proyecto se pueden encontrar diseminados entre distintos ficheros de
configuración. Por ello, los proyectos podrán ubicar los distintos archivos que configuren
tanto sus desarrollos como los distintas librerías de las que se hace uso en el proyecto en
el mismo directorio:
/etc/app/conf/$PROY/$APP/
4.1.3 Archivo de Configuración de Log.
Todas las aplicaciones tendrán su propio fichero de log y se ubicará en la siguiente
ruta, usando el siguiente formato:
/etc/app/conf/$PROY/$APP/log.$APP.{properties|xml|j son}
Este fichero tiene que ser configurado tal y como se indica en las buenas practicas
de programación. Este fichero no sera mantenido por la Conselleria de Sanitat y sera
responsabilidad de las aplicaciones la correcta parametrización de este.
Queda terminantemente prohibido la utilización de la Consola o Salida estandar ó
Salida de error del Sistema en los logs de aplicación. Cualquier utilización de esta salida
debe ser comunicada y documentada para el estudio por parte de la Conselleria de
Sanitat.
Queda terminantemente prohibido la utilización de niveles de logado propios de un
entorno de desarrollo, estos niveles, penalizan gravemente los servicios y funcionamiento
de las aplicaciones, por lo que su utilización debe ser comunicada y documentada para el
estudio por parte de Conselleria de Sanitat. El log debe ser configurado por defecto en un
nivel de WARN para las clases de la aplicación y en un nivel de ERROR para frameworks
de terceros, Se debe poder parametrizar sus valores de una forma modular para de este
modo no perjudicar a los usuarios finales de las aplicaciones ni sobrecargar los sistemas
de la Conselleria de Sanitat.
Las aplicaciones dejarán los logs en la siguiente ruta:
/var/logs/app/$PROY/$APP/xxxxx ($APP_LOG)
Archivo: 2-NOR01-Normas-Estandares Desarrollo e implantacion-01.02-131204 Página 18 de 58Fecha de la última modificación: 04/12/13
2-N
OR
01-N
orm
as-E
stan
dare
s de
sarr
ollo
e im
plan
taci
ón-0
0-00
-110
7201
12-
NO
R01
-Nor
mas
-Est
anda
res
desa
rrol
lo e
impl
anta
ción
-00-
00-1
1072
011
El rotado de los logs de la aplicación sera responsabilidad de la propia aplicación.
Se define como tamaño maximo de un fichero de log de 200Mb, no se deberan rotar
ficheros de tamaño inferior. A partir de este tamaño los ficheros deberan rotarse
siguiendo el formato que se indica a continuacion :
xxxxx($APP_LOG)[YYYY-MM-DD.HH-mm]
Donde :
YYYY-MM-DD : Año-Mes-Dia
HH-mm : Hora(Formato 24 horas) - Minuto
4.2 Certificados Digitales.
Todas las aplicaciones de todos los Sistemas de Información que requieran del uso
de certificados digitales, dispondrán de un almacén de claves (keystore ) propio. Estos
certificados compartirán una ruta común y deberán nombrarse en función del nombre de
la propia aplicación:
/etc/app/cert/nom_certificado.XXX ($APP_CERT)
Esta ruta se especificará en el fichero de configuración de la aplicación.
Además, todas las CA's adicionales que se requieran por parte de estos
certificados, y que no estén disponibles ya en el truststore de la Consellería (almacén de
certificados con claves públicas único a nivel de servidor) serán requeridos para
instalarlos.
Archivo: 2-NOR01-Normas-Estandares Desarrollo e implantacion-01.02-131204 Página 19 de 58Fecha de la última modificación: 04/12/13
2-N
OR
01-N
orm
as-E
stan
dare
s de
sarr
ollo
e im
plan
taci
ón-0
0-00
-110
7201
12-
NO
R01
-Nor
mas
-Est
anda
res
desa
rrol
lo e
impl
anta
ción
-00-
00-1
1072
011
4.3 Contenido Estático
Todas las aplicaciones que tengan parte de contenido estático, deberán ubicarlo en
los frontales correspondientes.
El contenido estático es aquél que permanece invariable desde el momento en
que su autor lo crea.
Por tanto, si la aplicación separa los recursos estáticos del contenido dinámico,
desde el punto de vista del desarrollador es necesario saber cómo referenciarlo desde la
parte dinámica.
La tabla siguiente muestra los Alias que deben ser conocidos desde las
aplicaciones:
Entorno Alias Contenido
NISS
/downloads/software/ sofware como Acrobat Reader, jinit,... para
descargar a los pc clientes y común a todas
las aplicaciones.
/downloads/[app]/ficheros/ Contenido estático de la aplicación [app].
ALSIS/NEOS /downloads/[app]/ Contenido estático de la aplicación [app]
El despliegue de este tipo de recursos en cualquiera de los entornos se realiza por
el personal de CS/AVS.
Archivo: 2-NOR01-Normas-Estandares Desarrollo e implantacion-01.02-131204 Página 20 de 58Fecha de la última modificación: 04/12/13
2-N
OR
01-N
orm
as-E
stan
dare
s de
sarr
ollo
e im
plan
taci
ón-0
0-00
-110
7201
12-
NO
R01
-Nor
mas
-Est
anda
res
desa
rrol
lo e
impl
anta
ción
-00-
00-1
1072
011
4.4 Otros contenidos
Existen contenidos que forman parte de la aplicación y que, para evitar tener que
redesplegar la aplicación ante cambios de los mismos, se recomienda que se ubiquen en
una ruta del servidor de aplicaciones independiente del EAR.
Dentro de esta categoría se engloban:
• informes precompilados desarrollados con Jasper Reports
• recursos utilizados por esos informes
• plantillas XSL
• etc.
La ubicación de esa ruta será /datos/<app> y deberá estar referencias mediante el
fichero de configuración de la aplicación.
4.5 Estructura de Aplicaciones JEE.
La estructura de una aplicación JEE se encuentra claramente documentada en la
especificación JEE, por lo tanto no es ámbito de este documento explicar su estructura y
los componentes que forman parte de ella.
Dado que en la Consellería de Sanitat existen distintos servidores de aplicaciones,
será responsabilidad de la aplicación el desarrollo y configuración de la propia aplicación
para los niveles de especificación JEE que soportan los servidores de aplicaciones en los
cuales se instalará la aplicación en cuestión. Para ello las empresas desarrolladoras
deberán concretar con los responsables de aplicación el entorno en el cual se van a
desplegar y el servidor de aplicaciones que utilizaran.
Ejemplo:
NISS : OAS 10.1.3.5 → Especificación J2EE 1.5
ALSIS : JBoss 5 Especificación → JEE 6
NEOS: Weblogic 12c → Especificación JEE 7
Archivo: 2-NOR01-Normas-Estandares Desarrollo e implantacion-01.02-131204 Página 21 de 58Fecha de la última modificación: 04/12/13
2-N
OR
01-N
orm
as-E
stan
dare
s de
sarr
ollo
e im
plan
taci
ón-0
0-00
-110
7201
12-
NO
R01
-Nor
mas
-Est
anda
res
desa
rrol
lo e
impl
anta
ción
-00-
00-1
1072
011
Para simplificar el proceso de mantenimiento y el nivel de seguimiento de las
distintas aplicaciones que posee la Consellería de Sanitat se mantendrá como estándar la
inclusión en el fichero de application.xml (que deben incluir todas las aplicaciones), los
siguientes atributos como mínimo:
<application id="ID_aplicación" ><display-name> EjemploAplicacion.ear </display-name><description> Descripción de la aplicación. </<description><module id=" WebModule_1 ">
<web><web-uri> EjemploAplicacion.war </web-uri><context-root> /EjemploAplicacion </context-root>
</web></module>
</application>
Así mismo con el fin de mantener un control sobre los despliegues de aplicaciones y
los distintos elementos que se encuentran desplegados se deberá incluir en los fichero
MANIFEST la versión de las distintas librerías, aplicaciones web, etc. Este versionado se
encuentra claramente documentado en las diferentes especificaciones Java.
4.6 Datasource en servidor de aplicaciones.
Con la finalidad de mantener coherencia entre las aplicaciones y los datasources
que estos utilizan, se deberá mantener un estándar de nomenclatura. Para ello las
aplicaciones deberán informar del nombre (IMPORTANTE: No confundir con el jndi-name)
a asignar a los datasources como:
Nombre : DS_${APP_NAME}_TARGET
Donde ${APP_NAME} sera el nombre de la aplicación/modulo que utiliza el
datasource y TARGET será el nombre identificativo del esquema al que se quiere
acceder.
Ejemplos:
DS_SIA_SIA (datasource utilizado por SIA para acceder al esquema de SIA)
DS_SIA_CRC (datasource utilizado por SIA para acceder al esquema de CRC)
Archivo: 2-NOR01-Normas-Estandares Desarrollo e implantacion-01.02-131204 Página 22 de 58Fecha de la última modificación: 04/12/13
2-N
OR
01-N
orm
as-E
stan
dare
s de
sarr
ollo
e im
plan
taci
ón-0
0-00
-110
7201
12-
NO
R01
-Nor
mas
-Est
anda
res
desa
rrol
lo e
impl
anta
ción
-00-
00-1
1072
011
En la ficha de diseño de aplicación se deberan indicar los parámetros necesarios
para el correcto funcionamiento de la aplicación o aplicaciones que hagan uso de ellos,
pudiendo ser estos ajustados dependiendo de las necesidades de la Conselleria de
Sanitat.
4.7 Uso del sistema de ficheros de la Conselleria de Sanitat.
Las aplicaciones dispondrán del uso de un directorio temporal accesible a través de
las variables del sistema, para la escritura y lectura de ficheros temporales. Esta variable
se indica en el arranque del contenedor de la aplicación mediante las java-options y por
tanto su definición quedará de la siguiente forma:
-Djava.io.tmpdir=/var/tmp/
Ante cualquier necesidad de directorios persistentes o sistemas de ficheros
compartidos entre varias maquinas (NFS) se debera indicar su necesidad en la ficha de
diseño correspondiente a la aplicación en cuestión.
Archivo: 2-NOR01-Normas-Estandares Desarrollo e implantacion-01.02-131204 Página 23 de 58Fecha de la última modificación: 04/12/13
2-N
OR
01-N
orm
as-E
stan
dare
s de
sarr
ollo
e im
plan
taci
ón-0
0-00
-110
7201
12-
NO
R01
-Nor
mas
-Est
anda
res
desa
rrol
lo e
impl
anta
ción
-00-
00-1
1072
011
5 Estándares de desarrollo
Las infraestructuras de la CS/AVS dan soporte a una serie de entornos en los que
se despliegan aplicaciones de múltiples proveedores. Debido a las características
funcionales y asistenciales de estos sistemas, la naturaleza del entorno de
producción es crítica, y esta criticidad se transmite al resto de entornos de modo
que todos ellos son de vital importancia.
En este marco, la Consellería se ve obligada a estandarizar tanto las entregas
como los desarrollos. Sería inviable mantener entornos separados para cada una
de las aplicaciones, versiones distintas de los servidores, parches de sistema
operativo o máquina virtual, lenguajes, etc.
Tras la experiencia acumulada afianzando y estabilizando los sistemas y
aplicaciones, es necesario que la CS/AVS publique este manual del programador,
para fortalecer la madurez y fomentar la construcción de aplicaciones robustas y
actualizadas:
- Que sigan unas prácticas de desarrollo actualizadas y contrastadas
- Que puedan desplegarse en los entornos de forma ordenada
Un primer paso para ello es la elección de Java, y el modelo JavaEE, como
lenguaje con el que desarrollar todas estas aplicaciones.
Sobre esta premisa, este apartado lo componen buenas prácticas,
recomendaciones y normativas con respecto a las tecnologías empleadas y su
uso adecuado. Todo vendrá complementado, a modo de anexos, con una serie de
dossiers separados por tecnología para el caso en el que una aplicación los use.
Su objetivo es ayudar a los proveedores a generar aplicaciones que, desde el
inicio de su desarrollo, sean compatibles con el entorno y sigan una serie de
características que la CS/AVS considera vitales para su puesta en producción.
En ningún momento pretende sustituir la experiencia del proveedor en el campo
del desarrollo de software. Los proveedores de Conselleria se eligen acorde a
criterios de experiencia y exigencias de conocimientos, servicios y certificación
suficientemente exigentes. Sin embargo, la guía que presentamos tiene un
enfoque colaborativo y normativo. Sí es necesario concienciar a todos ellos que
las aplicaciones comparten entorno y se integran con otros desarrollos de
distintos proveedores. Además, su vida útil en producción suele ser larga, lo cual
conlleva necesidades de mantenimiento y mejora en un contexto de cambios
Archivo: 2-NOR01-Normas-Estandares Desarrollo e implantacion-01.02-131204 Página 24 de 58Fecha de la última modificación: 04/12/13
2-N
OR
01-N
orm
as-E
stan
dare
s de
sarr
ollo
e im
plan
taci
ón-0
0-00
-110
7201
12-
NO
R01
-Nor
mas
-Est
anda
res
desa
rrol
lo e
impl
anta
ción
-00-
00-1
1072
011
constantes de tecnología.
5.1 Nomenclatura
En manual del programador trata acerca de conceptos de naturaleza muy técnica.
Con respecto a las indicaciones establecidas, podemos encontrarnos 4 tipos cuya
explicación y representación podemos ver en la siguiente lista:
Símbolo Tipo Descripción
Norma Norma de obligado cumplimiento.
Recomendación
estandarizada
Sugerencia de uso. Por ejemplo, para las librerías que
CS/AVS aconseja utilizar.
Recomendación no
estandarizada
Es también una sugerencia pero no de estandarización de
librerías, sino de uso interno de estas.
Prohibición Cuando no está permitido realizar dicha acción
Además de los anteriores, también podemos encontrarnos con alguna reflexión o
detalle importante:
Observaciones: etc.
5.2 Infraestructura de desarrollo
Como base de los procesos de desarrollo entregados a Conselleria, requeriremos:
- Debe seguirse la nomenclatura definida en Java Code Conventions.
- Deben seguirse todos los procedimientos definidos en la AVS.
5.2.1 Requisitos de infraestructura
La infraestructura del desarrollo es responsabilidad del proveedor de software.
En caso de no estar pactado en el propio contrato del proyecto, ninguno de los
entornos existentes en CS/AVS puede considerarse como un entorno de desarrollo. La
entrega de software a la CS/AVS presupone la suficiente madurez a dicha entrega como
Archivo: 2-NOR01-Normas-Estandares Desarrollo e implantacion-01.02-131204 Página 25 de 58Fecha de la última modificación: 04/12/13
2-N
OR
01-N
orm
as-E
stan
dare
s de
sarr
ollo
e im
plan
taci
ón-0
0-00
-110
7201
12-
NO
R01
-Nor
mas
-Est
anda
res
desa
rrol
lo e
impl
anta
ción
-00-
00-1
1072
011
para que pase por una serie de pruebas y controles y finalmente se despliegue en
producción para empezar a explotarse.
Antes del arranque del desarrollo, el proveedor debe asegurarse de conocer la
siguiente información de los entornos de la AVS acerca de donde va
ejecutarse su desarrollo:
- Versiones exactas de:
o La JRE que se ejecuta en los entornos.
o Servidores de aplicaciones y librerías incluidas.
o Base de datos.
o Servidores web.
o Motores de integración y mensajería.
o Herramientas de gestión de usuarios / identidades.
- La tipología de cluster de los servicios mencionados anteriormente.
- Las reglas, nomenclaturas y estándares a seguir para que la aplicación sea
desplegable en los entornos.
5.2.2 Requisitos en los nombres de ficheros y direct orios
- Para facilitar el paso de ficheros entre entornos, solamente se permitirán nombres de
ficheros y directorios que cumplan los siguientes requisitos:
o Caracteres alfabéticos del inglés (sin eñes ni acentos)
o Números
o Los siguientes caracteres especiales: punto (.), subrallado (_) y guion (-).
- Los espacios en blanco en nombres de ficheros no están permitidos.
5.2.3 Prácticas
- Para la construcción de cadenas hay que evitar sumar muchos Strings (y sobre todo
evitar hacerlo dentro de bucles) pequeños, ya que estos son objetos inmutables. Es
Archivo: 2-NOR01-Normas-Estandares Desarrollo e implantacion-01.02-131204 Página 26 de 58Fecha de la última modificación: 04/12/13
2-N
OR
01-N
orm
as-E
stan
dare
s de
sarr
ollo
e im
plan
taci
ón-0
0-00
-110
7201
12-
NO
R01
-Nor
mas
-Est
anda
res
desa
rrol
lo e
impl
anta
ción
-00-
00-1
1072
011
preferible usar StringBuffer o preferiblemente StringBuilder (si la ejecución
es sobre Java5).
- Todo objeto que vaya a enviarse de algún modo de un destino a otro (en la sesión
HTTP, almacenado en disco, incluso los DTOs y Vos o POJOs, etc.) debe marcarsecomo Serializable .
- A la hora de construir objeto de tipo Collection , conviene aprovechar el
conocimiento funcional del caso de uso para darle un tamaño inicial.
- Deben usarse las colecciones de modo consistente:
o Usar ArrayList en lugar de Vector y HashMap en lugar de Hashtable .
o Deben declararse con el interfaz e instanciarse con la implementación.
- Aunque estemos usándolo desde la propia clase, hay que usar siempre la notaciónNombreClase.metodo() o NombreClase.atributo para invocar a un método o
atributo estático.
- No está permitido invocar a System.exit() en aplicaciones web.
- Hay que evitar la comparación de cadenas con == o ¡= . Estos operadores comparan
referencias, y no contenido.
- No hay que usar .equalsIgnoreCase() indiscriminadamente, sólo cuando sea
necesario.
- Se deben declarar los atributos de clase antes que los métodos y los constructores.
Los constructores irán antes que los métodos.
- Hay que evitar que la existencia de líneas de código comentadas crezca o sea una
práctica habitual. En CS/AVS consideraremos dicha práctica como síntoma de un mal
uso de control de versiones y problemas en el trabajo en equipo.
5.2.4 Herramientas de desarrollo y generación de des plegables
La AVS no impone que el proveedor use ningún IDE. Sin embargo la aplicación debe
cumplir las siguientes restricciones:
- El proceso de compilación, generación de documentación (JavaDoc ) y empaquetado
debe poder ejecutarse con una única línea de comandos con la JDK necesaria,
integrándose fácilmente con Ant o Maven (preferiblemente el segundo). Al final del
Archivo: 2-NOR01-Normas-Estandares Desarrollo e implantacion-01.02-131204 Página 27 de 58Fecha de la última modificación: 04/12/13
2-N
OR
01-N
orm
as-E
stan
dare
s de
sarr
ollo
e im
plan
taci
ón-0
0-00
-110
7201
12-
NO
R01
-Nor
mas
-Est
anda
res
desa
rrol
lo e
impl
anta
ción
-00-
00-1
1072
011
documento se incluyen dos anexos donde entra en más detalle en el uso de Ant y
Maven.
- El entorno de compilación es una máquina Linux. Por tanto, no son válidos para la
compilación scripts BAT (Windows).
- El código fuente debe poder consultarse y editarse con cualquier editor de texto,
siempre que la tecnología utilizada así lo permita
- Los fuentes serán compilados en CS/AVS por lo que los scripts de compilación deben
ser independientes del entorno. Esto también debe tenerse en cuenta en la
codificación de los fuentes, que deberá estar indicada donde sea necesario para
asegurar la correcta compilación.
- El código debe ser compilable por personal de CS/AVS sin necesidad de realizar
modificaciones sobre los fuentes entregados.
- Salvo caso justicable, los binarios que se desplegarán serán los obtenidos a partir de
la compilación de los fuentes por el personal de CS/AVS.
- Por adopción, y por ser abierto y gratuito la AVS recomienda el uso de Eclipse pero
siempre teniendo en cuenta que, todo proyecto generado con él, debe seguir las
reglas anteriores.
- Se recomienda entregar ficheros fuente con codificación UTF-8.
- Hay que configurar el IDE para que reemplacen tabuladores por espacios.
- Es conveniente incluir un fichero tipo howto en el proyecto en el que se explique cual
es el IDE (y versión) empleado y cómo configurarlo para poder abrir el proyecto con
él.
-
- Está prohibido el uso de rutas absolutas (C:\codigo , p. ej.) en los ficheros de
configuración de los scripts de compilación para que no haya dependencias con
máquinas personales
5.2.5 Estructura de paquetes
Todos los paquetes Java deben pertenecer al siguiente paquete:
es.gva.san
Archivo: 2-NOR01-Normas-Estandares Desarrollo e implantacion-01.02-131204 Página 28 de 58Fecha de la última modificación: 04/12/13
2-N
OR
01-N
orm
as-E
stan
dare
s de
sarr
ollo
e im
plan
taci
ón-0
0-00
-110
7201
12-
NO
R01
-Nor
mas
-Est
anda
res
desa
rrol
lo e
impl
anta
ción
-00-
00-1
1072
011
Y a continuación se usará el código / acrónimo de proyecto para identificar a sus
clases.
Posible excepción a esta regla son las librerías de utilidades propias que aporte el
proveedor al desarrollo.
Dichas librerías deben incluirse en el proyecto como dependencias en archivos jar,
no como fuentes si su desarrollo no depende del proyecto para la CS/AVS.
En caso de incluirlas junto al código fuente del proyecto, deben pertenecer a algúnsubpaquete es.gva.san .
5.2.6 Estructura de directorios
La estructura de directorios debe separar los siguientes tipos de fichero:
- Código fuente: Entendiendo como tal las propias clases Java y los ficheros SQL.
- Código autogenerado.
- Librerías.
- Recursos tales como imágenes, plantillas, etc.
- Ficheros de configuración y filtros.
- Documentación.
- Instrucciones (estilo HOWTO) de compilación, configuración, empaquetado y
despliegue.
Véase como ejemplo de buena práctica, la estructura de directorios por defecto de
los proyectos Maven .
5.2.7 Generación del entregable
- El proveedor entregará en los despliegues tanto el código fuente como el fichero a
desplegar. El personal de CS/AVS generará un desplegable a partir de los fuentes
proporcionados y lo comparará con el despleglable entregado. Una vez validado que
ambos desplegables son iguales, únicamente se facilitarán los fuentes de la
aplicación. La información acerca de cómo entregar estos paquetes se encuentra
descrita en el procedimiento de despliegue de aplicaciones.
Archivo: 2-NOR01-Normas-Estandares Desarrollo e implantacion-01.02-131204 Página 29 de 58Fecha de la última modificación: 04/12/13
2-N
OR
01-N
orm
as-E
stan
dare
s de
sarr
ollo
e im
plan
taci
ón-0
0-00
-110
7201
12-
NO
R01
-Nor
mas
-Est
anda
res
desa
rrol
lo e
impl
anta
ción
-00-
00-1
1072
011
- Es imprescindible que el mismo desplegable se despliegue en todos los entornos.
Esto sugiere la extracción de ficheros de propiedades que parametricen accesos o
uso según entorno fuera de la aplicación.
- El desplegable estará identificado con su número de versión.
5.3 Gestión de versiones
- La gestión del proyecto deberá incluir una gestión cercana al desarrollo que permita
incluir en los entregables ficheros RELEASE_NOTES en los que se indique:
o Información general del proyecto.
o Las nuevas funcionalidades de la versión actual.
o Los errores de la anterior versión que se hayan corregido.
- El versionado en desarrollo del proyecto es responsabilidad del proveedor. Excepto
en proyectos de desarrollo interno o mixto, en la CS/AVS realizaremos versionado de
entregas (tanto código como desplegable) pero no de cambios de desarrollo.
5.4 Arquitectura del código
5.4.1 Prácticas
- DTOs y VOs deben ser Serializable e implementar .toString() , .equals() y
.hashCode() . También debe ofrecerse un mecanismo sencillo para construirlos,
sea vía constructores o vía patrón Factory.
- Los nombres de atributos, métodos y clases deben explicar su significado.
- Hay que evitar el uso de herencia para relaciones entre objetos que no sean de tipo“es-un”. Para otros casos tiene que usarse o bien import static o bien una
llamada al método de otro objeto.
- Hay que reutilizar lo máximo posible todas las piezas del desarrollo y evitar código
duplicado a toda costa.
5.4.2 Aspectos transversales
5.4.2.1 JavaDoc y documentación interna
Archivo: 2-NOR01-Normas-Estandares Desarrollo e implantacion-01.02-131204 Página 30 de 58Fecha de la última modificación: 04/12/13
2-N
OR
01-N
orm
as-E
stan
dare
s de
sarr
ollo
e im
plan
taci
ón-0
0-00
-110
7201
12-
NO
R01
-Nor
mas
-Est
anda
res
desa
rrol
lo e
impl
anta
ción
-00-
00-1
1072
011
- Es necesario que el código esté documentado. Sin embargo, preferiremos la
ausencia de documentación a la existencia de documentación obsoleta o
incoherente.
- El anterior punto se basa en una premisa que es que hay que intentar siempre que el
propio código sea fácilmente legible y entendible.
- En el caso de los comentarios JavaDoc, estos deben indicar claramente (como
mínimo para las interfaces):
o Qué hace el método o para qué se usa el atributo.
o Valores válidos para los parámetros del método y cómo se comporta este ante
situaciones de error.
5.4.2.2 Logging
- Los logs generarán trazas:
o Estructuradas: El formato de cada línea de traza será coherente en toda la
aplicación. De forma que pueda explotarse su información mediante scripts
de sistema operativo.
o Suficientemente informativa (evitando posibles problemas de privacidad de
datos): de forma que puedan verse datos además de acciones.
o Que mostrarán información acerca de clase, paquete, método y tiempos.
- Para visualizar estos datos en las trazas hay que usar separadores que delimiten suinicio y su fin. Por ejemplo: “Usuario [01010101P] ”. Recomendamos que se
implementen los métodos .toString() teniendo esto en mente.
- Sea cual sea la librería de logging utilizada, debe ser única y usarse de forma
coherente en todo el proyecto.
- El nivel de trazas será parametrizable vía fichero .properties fuera del desplegable de
forma que cada entorno pueda usar un nivel distinto. Dentro del código se utilizarán
los niveles.
- También conviene incluir trazas antes y después de la ejecución de llamadas a base
de datos de forma que podamos medir, si lo creemos conveniente, tiempos de
acceso.
Archivo: 2-NOR01-Normas-Estandares Desarrollo e implantacion-01.02-131204 Página 31 de 58Fecha de la última modificación: 04/12/13
2-N
OR
01-N
orm
as-E
stan
dare
s de
sarr
ollo
e im
plan
taci
ón-0
0-00
-110
7201
12-
NO
R01
-Nor
mas
-Est
anda
res
desa
rrol
lo e
impl
anta
ción
-00-
00-1
1072
011
- No hay que abusar de las trazas para evitar problemas de rendimiento. En algunoscasos en los que la traza es compleja es conveniente usar isDebugEnabled() .
- En producción no se activarán las trazas a nivel debug si no es por causa mayor
debida a inestabilidad de la aplicación o por algún estudio concreto que haya
aprobado el SITIC de la CS/AVS.
- Queda terminantemente prohibido el uso de System.out , System.err o
e.printStackTrace() en las aplicaciones.
5.4.2.3 Manejo de excepciones
- En el uso directo de JDBC, es obligatorio usar bloques finally para cerrar
conexiones.
- Todo proyecto tendrá su jerarquía de excepciones, que partirá de NomAplException o
NomAplRuntimeException.
- No se crearán tipos de excepciones cuya semántica ya esté contemplada en los
paquetes básicos del lenguaje o en alguna de las librerías empleadas. En dichos
casos, hay que usar las existentes.
- Se preferirá el uso de excepciones unchecked (descendientes deRuntimeException ) a las checked (descendientes de Exception ). Esto hace el
código más mantenible: las signaturas de los métodos son más simples la
propagación de excepciones es menos costosa de implementar y más flexible de
modificar. Las excepciones de tipo checked se usarán para casos importantes. Un
síntoma de necesidad de cambio puede ser que se relancen muchas excepciones o
que tengamos bloques catch en los que no podamos hacer nada para dar respuesta
a la excepción.
5.4.2.4 Transaccionalidad
Cualquier estrategia que evite que la base de datos se quede en un estado
inconsistente tanto desde la perspectiva física como desde la de la lógica del negocio es
válida.
Archivo: 2-NOR01-Normas-Estandares Desarrollo e implantacion-01.02-131204 Página 32 de 58Fecha de la última modificación: 04/12/13
2-N
OR
01-N
orm
as-E
stan
dare
s de
sarr
ollo
e im
plan
taci
ón-0
0-00
-110
7201
12-
NO
R01
-Nor
mas
-Est
anda
res
desa
rrol
lo e
impl
anta
ción
-00-
00-1
1072
011
El ámbito transaccional debe abarcar, como mínimo, la capa de servicios; así que
también serían válidas otras estrategias como por ejemplo definir el ámbito transaccional
a nivel de petición HTTP, y/o mantener abierta la transacción durante la visualización de
la vista.
En todo caso, debe probarse el comportamiento del sistema en base a la
concurrencia de usuarios, carga y uso esperado de la aplicación. El modelo elegido debe
evitar los bloqueos de datos en la medida de lo posible.
Hay que asegurar que las transacciones se cierren en todo caso.
Es preferible usar, como abstracción de acceso a datos, JTA que es un API
estándar para manejar transacciones y que integra bien con todos los contenedores
(independientemente de que se use Spring o EJBs ).
En el caso de usar Spring , recomendamos el uso de Spring-AOP para controlar
con aspectos la transaccionalidad.
5.4.2.5 Contenido XML
- Averigua antes de empezar el desarrollo las versiones de librerías relacionadas con
el manejo de ficheros XML en el servidor de aplicaciones.
- Asegúrate de que las librerías que utilices no entran en conflictos con las existentes
en el servidor.
- Usa XSDs o DTDs para validar contenido.
- Define el contenido del fichero: <?xml version=”1.0” encoding=”UTF-8”>
- Estudia el uso de los métodos que impliquen parseo de ficheros XML y el tamaño de
estos ficheros para evaluar si es conveniente:
o La validación del contenido.
o El uso de un modelo secuencial (SAX) o uno orientado a la estructura
(DOM), o de uno mixto con StAX si el contenedor está arrancado con Java6.
Archivo: 2-NOR01-Normas-Estandares Desarrollo e implantacion-01.02-131204 Página 33 de 58Fecha de la última modificación: 04/12/13
2-N
OR
01-N
orm
as-E
stan
dare
s de
sarr
ollo
e im
plan
taci
ón-0
0-00
-110
7201
12-
NO
R01
-Nor
mas
-Est
anda
res
desa
rrol
lo e
impl
anta
ción
-00-
00-1
1072
011
- Intenta utilizar herramientas OXM para convertir de Objetos a XML y viceversa. En el
caso de estar manejando servicios web, es preferible usar JAXB.
5.4.2.6 Internacionalización (I18N)
- Las etiquetas, imágenes, formatos y estilos mostrados al usuario deben estar
preparados para I18N con ficheros de message bundle.
- Hay que cuidar la codificación de estos ficheros. La utilidad native2ascii de la JDK
puede ayudar a gestionar este encoding.
5.4.3 Modularización y capas
La infraestructura de la AVS está optimizada para aplicaciones multi-capa en las
que se reparten las tareas según estemos ejecutando lógica de presentación de datos al
usuario, lógica de negocio o lógica de acceso a datos.
Si bien la arquitectura de la aplicación no es fija, sí es obligatorio que:
- Las capas estén ocultas tras interfaces.
- Que estos interfaces públicos estén perfectamente documentados con JavaDoc o
similar.
- Que se programe en base a patrones de diseño actualizados y probados.
- Que las capas se conozcan de arriba a abajo y no de abajo a arriba. En el caso en el
que lo segundo fuese necesario, se empleará el patrón de diseño Observador para
implementar dicha característica.
No dictamos un modelo de capas fijo ya que la tipología de las aplicaciones es muy
amplia, pero sí que se eviten situaciones como las siguientes (aunque sea imposible
enumerarlas todas):
- Acceso a la base de datos desde las JSP.
- En aplicaciones cliente/servidor, que el proceso de login envíe la contraseña del
usuario (o peor, toda la tabla de usuarios y contraseñas) al cliente.
- Métodos de miles de líneas.
- Etc.Archivo: 2-NOR01-Normas-Estandares Desarrollo e implantacion-01.02-131204 Página 34 de 58Fecha de la última modificación: 04/12/13
2-N
OR
01-N
orm
as-E
stan
dare
s de
sarr
ollo
e im
plan
taci
ón-0
0-00
-110
7201
12-
NO
R01
-Nor
mas
-Est
anda
res
desa
rrol
lo e
impl
anta
ción
-00-
00-1
1072
011
5.4.3.1 Capa de presentación
- Hay que averiguar la versión de la especificación de Servlets/JSPs que interpreta el
servidor de aplicaciones y ajustar la definición (cabecera) del descriptor de
despliegue (web.xml) a esta. Una mala configuración de este parámetro puede
provocar que la aplicación no funcione correctamente o que el servidor atienda sus
peticiones en modo compatibilidad.
- El HTML generado debe incluir siempre en la cabecera el DOCTYPE usado. Todos
los componentes de presentación HTML deben usar el mismo DOCTYPE.
-
- Hay que minimizar/codificar los ficheros JavaScript para que sean ligeros de
transportar y de ejecutar.
- Hay que usar correctamente los mecanismos de cacheado de recursos que provee
HTTP.
- Preferiblemente se usará UTF-8 como encoding en la capa de presentación.
Esta codificación es estándar, la soportan todos los navegadores y todos los sistemas
operativos, representa prácticamente a todos los alfabetos del mundo y es bastante
eficiente a la hora de manejar alfabetos europeos (más eficiente que UTF-16, por
ejemplo).
En todo caso, hay que evitar el uso de código Java o scriptlets en la parte de
presentación pura (JSPs , por ejemplo).
5.4.3.2 Capa de servicios
- Recomendamos el uso de Spring para definir la arquitectura de las aplicaciones.
- En caso de usar EJBs , se evitará el uso de versiones anteriores a la 3.1.
5.4.3.3 Capa de acceso a datos
Archivo: 2-NOR01-Normas-Estandares Desarrollo e implantacion-01.02-131204 Página 35 de 58Fecha de la última modificación: 04/12/13
2-N
OR
01-N
orm
as-E
stan
dare
s de
sarr
ollo
e im
plan
taci
ón-0
0-00
-110
7201
12-
NO
R01
-Nor
mas
-Est
anda
res
desa
rrol
lo e
impl
anta
ción
-00-
00-1
1072
011
- Si se realizan SQL desde el código, estos estarán localizados en la capa de acceso a
datos. No se permitirá que estos estén desperdigados por todo el código.
- Se evitará la construcción sistemática de SQLs en el código en base a sumas de
cadenas de caracteres. Para hacerlo existen muchas posibilidades, entre las que
remarcamos:
o El uso de DbUtils de Apache Commons para externalizar las SQLs en
ficheros.
o El uso de PreparedStatements (o equivalente) para consultas con
parámetros.
- No realizar un SELECT COUNT(*) para comprobar si una tabla tiene datos. Con
SELECT * FROM table WHERE ROWNUN<1 es suficiente.
ORM: Mapeo Objeto-Relacional
- En caso de uso de una herramienta ORM, la CS/AVS recomienda el uso de
Hibernate .
- Se recomienda el uso de JPA como capa de abstracción.
Base de datos
- La base de datos debe incluir claves primarias, índices y claves ajenas. Debe
estudiarse la necesidad de índices conforme a las expectativas de uso de cada tabla.
- No debe incluir restricciones de integridad ni funcionalidades que correspondan a la
capa de negocio (procedimientos almacenados, triggers, etc.) a no ser que exista
justificación basada en aspectos no funcionales.
- El código PL/SQL es considerado código de aplicación, y como tal debe cumplir los
mismos requisitos de testeo que el código Java puro.
- El encoding de la base de datos debe consensuarse con los administradores del
entorno. En todo caso, resulta más eficiente usar el mismo encoding en la capa de
presentación y en la base de datos para evitar traducciones innecesarias.
- Deben versionarse los scripts SQL tal y como si fuesen código de aplicación, como
se indica en 3.3.3 Versionado de scripts de BBDD
Archivo: 2-NOR01-Normas-Estandares Desarrollo e implantacion-01.02-131204 Página 36 de 58Fecha de la última modificación: 04/12/13
2-N
OR
01-N
orm
as-E
stan
dare
s de
sarr
ollo
e im
plan
taci
ón-0
0-00
-110
7201
12-
NO
R01
-Nor
mas
-Est
anda
res
desa
rrol
lo e
impl
anta
ción
-00-
00-1
1072
011
- Todo despliegue debe acompañarse de:
o Scripts incrementales para actualizar el modelo de datos
o Scripts de marcha atrás para abortar la actualización.
o Scripts completos de creación de la base de datos desde cero.
- Debe añadirse una tabla DatabaseConfiguration al modelo que indique la
versión del esquema. La aplicación debe comprobar este valor con sus datos internos
de configuración para comprobar que se ha actualizado tanto la aplicación como el
modelo antes de arrancar.
- Para hacer un seguimiento de cambios sería recomendable una tablaDatabaseChanges , que guardase los scripts ejecutados sobre el esquema, en qué
versión de este y en qué fecha.
5.4.4 Otros
5.4.4.1 Librerías comunes
En el arranque del desarrollo hay que conocer las versiones de las librerías
incluidas ya en el servidor de aplicaciones. Estas librerías no hay que incluirlas en el
desplegable, a no ser que se acuerde con SITIC que se quiere sobrescribir su
comportamiento.
- Hay que evitar el uso de librerías propias incluidas en los ficheros fuente. En su caso,
incluirlas como ficheros jar.
- Hay que usar Apache Commons para utilidades básicas y evitar reprogramar todo lo
que en dicho proyecto esté ya resuelto.
- Para proyectos que incluyan las librerías en el paquete entregado hay que usar
siempre las librerías con nombre y versión de esta. Está terminantemente prohibido,
por ejemplo, renombrar spring-3.0.1.M2.jar a spring.jar.
Archivo: 2-NOR01-Normas-Estandares Desarrollo e implantacion-01.02-131204 Página 37 de 58Fecha de la última modificación: 04/12/13
2-N
OR
01-N
orm
as-E
stan
dare
s de
sarr
ollo
e im
plan
taci
ón-0
0-00
-110
7201
12-
NO
R01
-Nor
mas
-Est
anda
res
desa
rrol
lo e
impl
anta
ción
-00-
00-1
1072
011
5.4.4.2 Generación de informes
El mecanismo de generación de informes desde las aplicaciones debe acordarse
con el personal de SITIC e intentar encontrar una solución compatible con el entorno. Este
aspecto es crítico ya que no podemos permitir que un uso poco afortunado de la
aplicación en horario clave, influya en el funcionamiento de otros sistemas. Además, no
permitiremos que proliferen servicios de reporting individuales, sino que tenderemos a la
aparición de un servidor de informes.
5.4.4.3 Planificadores de tareas
Excepto excepciones consensuadas con SITIC, las propias aplicaciones se
encargarán de tareas periódicas de mantenimiento de procesos internos. Debe evitarse el
uso de tareas programadas del sistema operativo y de jobs de base de datos ya que
dispersan la localización del problema entre múltiples grupos de trabajo.
- La recomendación de la CS/AVS es el uso de Quartz para la gestión de tareas.
- La aplicación debe disponer de un API (no necesariamente gráfico) que permita ver el
estado de estas tareas, pararlas y arrancarlas.
Es obligatorio notificar y consensuar con las unidades de SITIC el horario
planificado y el impacto de las tareas para que evalúen su inclusión en los sistemas. En lo
que respecta al ámbito del análisis, también hay que acordar dichas planificaciones de
tareas con todas las aplicaciones que estén implicadas en la funcionalidad asociada.
5.5 Base de datos
En este apartado enlazaremos a documentos que definen una serie de reglas
asociadas la propia base de datos de la aplicación.
Independientemente de la base de datos, al desarrollar hay que preparar dos tipos
de usuarios:
- Usuarios propietarios del esquema: con permisos de DDL.
- Usuarios de aplicaciones: para acceder y realizar operaciones DML.
Debe evitarse el uso de usuarios personales.
5.5.1 Oracle
Véase el apartado de Nomenclatura de objetos de base de datos Oracle.Archivo: 2-NOR01-Normas-Estandares Desarrollo e implantacion-01.02-131204 Página 38 de 58Fecha de la última modificación: 04/12/13
2-N
OR
01-N
orm
as-E
stan
dare
s de
sarr
ollo
e im
plan
taci
ón-0
0-00
-110
7201
12-
NO
R01
-Nor
mas
-Est
anda
res
desa
rrol
lo e
impl
anta
ción
-00-
00-1
1072
011
No se permite hacer uso del API de JDBC de Oracle (paquetes oracle.jdbc y
oracle.sql). Debe usarse el API nativo de Java.
Conviene recordar aquí que se desaconseja el uso de database links como
mecanismo de integración con otros sistemas para evitar el alto acoplamiento que
conllevan.
Esta funcionalidad debe implementarse por aplicación, con un API bien definido a
modo de servicios web.
5.6 Seguridad
La normativa existente acerca de políticas de seguridad es responsabilidad de la
USO (Unidad de Seguridad y Organización) y debe consultarse con esta. Indicamos aquí
algunas sugerencias que deben complementar al cumplimiento de los requisitos indicados
en la LOPD y a la implementación de código carente de las vulnerabilidades
categorizadas por la OWASP, Open Web Application Security Project.
- Es obligatorio usar sentencias preparadas para evitar inyección de SQL.
- Se debe comprobar la validez de todos los datos introducidos (formato de cadenas,
fechas y números, valores nulos, divisiones por cero, rangos, etc.).
- Los métodos que pertenezcan a un API público y que no se puedan eliminar pordependencias y cambios de versión se marcarán como @deprecated .
Las aplicaciones dispondrán de una pantalla, sólo accesible para ciertos roles de
usuario administrador que permita una consulta básica de procesos vitales para su
correcto funcionamiento. Esta pantalla servirá para comprobar el estado de:
- Integraciones.
- Estado general de casos de uso críticos.
- Etc.
Dicha pantalla simplemente devolverá una serie de líneas en las que se indique:Archivo: 2-NOR01-Normas-Estandares Desarrollo e implantacion-01.02-131204 Página 39 de 58Fecha de la última modificación: 04/12/13
2-N
OR
01-N
orm
as-E
stan
dare
s de
sarr
ollo
e im
plan
taci
ón-0
0-00
-110
7201
12-
NO
R01
-Nor
mas
-Est
anda
res
desa
rrol
lo e
impl
anta
ción
-00-
00-1
1072
011
Nombre de la prueba : OK / WARNING / ERROR
El significado de estos avisos estará documentado y consensuado con los
responsables funcionales y de sistemas de la aplicación.
5.7 Login
- En una pantalla de login, no se mostrará la contraseña mientras se escribe, se
mostrarán asteriscos (*).
- No se permitirán contraseñas que sean igual que los nombres de usuario o que sean
nulas.
- No se pueden incluir datos de usuario / contraseña en el código. Deben encontrarse
en fuentes de datos externas y modificables.
5.7.1 Single Sign-On y gestión de identidades
Véase documentos y normativas existentes dictadas por la unidad de seguridad y
organización.
5.7.2 Accesos
En caso de que la la aplicación pueda ser accedida desde fuera de la red Arterias y
no utilice Single Sign-On, la aplicación deberá realizar la autenticación de usuarios de la
forma como se hace en la clase del Anexo C. Clase Java para certificados a través de
Reverse Proxy..
5.8 Integraciones
Las normativas y recomendaciones vigentes en cuanto a aspectos de integración
vienen marcadas por el proyecto SINAPSIS. Los proveedores deben dirigirse a los
responsables de este proyecto para capturar requisitos de implementación de
integraciones y para que se cataloguen estas.
Indicamos a continuación algunas recomendaciones básicas en lo que se refiere a
la implementación pura.
5.8.1 Servicios Web
Archivo: 2-NOR01-Normas-Estandares Desarrollo e implantacion-01.02-131204 Página 40 de 58Fecha de la última modificación: 04/12/13
2-N
OR
01-N
orm
as-E
stan
dare
s de
sarr
ollo
e im
plan
taci
ón-0
0-00
-110
7201
12-
NO
R01
-Nor
mas
-Est
anda
res
desa
rrol
lo e
impl
anta
ción
-00-
00-1
1072
011
- Cualquier aplicación que se planteé orientada para ofrecer servicios a otras
aplicaciones (del estilo de SIP o CRC) debe tener un interfaz de servicios web
adecuadamente documentado y securizado. Aunque tengan interfaz gráfico hay que
evitar que el modelo de integración consista en el acceso directo al modelo de datos
o en abrir aplicaciones desde dentro de otras.
- Reaprovecha lógica de negocio ya existente a la hora de implementar el servicio web.
- Intenta siempre implementar servicios web sin estado (aunque este puede sí ser
necesario para almacenar información de registro o autenticación) para fomentar la
escalabilidad del sistema.
- Incluir un punto en el servicio en el que se pueda consultar la versión del API de
Servicios Web publicada.
- Usa mecanismos de streaming para serializar recursos (por ejemplo DataHandler )
para evitar cargar estos recursos completamente en memoria ya que consumen
mucha.
- En el caso de implementar servicios RESTful:
o Recomendamos el uso de JAX-RS como API.
o Agrupa recursos relacionados en grupos.
o Enlaza recursos entre sí usando XLink.
o Asegúrate si accedes detrás de un proxy que este acepta peticiones
DELETE o PUT. En caso de no hacerlo, enmascáralas dentro de POST.
- En el caso de usar SOAP:
o Recomendamos el uso del API JAX-WS: Netro, AXIS o CXF como
implementación.
o Prueba los WSDL obtenidos con herramientas genéricas tales como SoapUI
como una primera prueba de interoperabilidad.
o Por mantenibilidad, recomendamos la generar los WSDL a partir de código
Java con anotaciones.
o Que cada servicio web de la aplicación contenga endpoints o métodos que
tengan una relación lógica entre sí.
Archivo: 2-NOR01-Normas-Estandares Desarrollo e implantacion-01.02-131204 Página 41 de 58Fecha de la última modificación: 04/12/13
2-N
OR
01-N
orm
as-E
stan
dare
s de
sarr
ollo
e im
plan
taci
ón-0
0-00
-110
7201
12-
NO
R01
-Nor
mas
-Est
anda
res
desa
rrol
lo e
impl
anta
ción
-00-
00-1
1072
011
5.8.2 Rhapsody
- A la hora de diseñar una integración, recomendamos tener muy presente su
escalabilidad. Es necesario informar a SITIC acerca de la naturaleza de este aspecto y
a las aplicaciones integradas para ver si todas las partes están preparadas para recibir
la carga.
- En las pruebas de carga del sistema, debe asegurarse que las colas de mensajería
están vacías. Debe monitorizarse su uso durante las cargas.
- Debe quedar traza en los logs del sistema de las situaciones de error en cualquiera de
los filtros o puntos de comunicación de una integración.
- En la entrega de un despliegue debe incluirse todo aquello que sea necesario para
realizarlo, no sólo el fichero .rlc. Además:
- La entrega estará versionada.
- Se usarán variables globales para parametrizar IPs, puertos, etc.
- Las variables globales llevarán un prefijo con el acrónimo de proyecto para evitar
solapamientos no deseados.
- Se entregarán los certificados que sea necesario cargar.
5.8.3 Envío y recepción de correos electrónicos
Deben usarse los mecanismos estándar de JavaEE para implementar envío y recepción.
Los servidores usados deben poder configurarse vía ficheros de propiedades. Estas
direcciones deben obtenerse vía comunicación con personal de SITIC para todos los
entornos en los que esté desplegada la aplicación.
5.8.4
5.9 Imagen y aspecto de las aplicaciones
- El UI debe advertir al usuario de todas las operaciones potencialmente no seguras
que realice.
- Deben incluirse páginas de error personalizadas para mostrar errores 4xx o 5xx.
- Debe primar el uso de CSS sobre el de estilos inline.
Archivo: 2-NOR01-Normas-Estandares Desarrollo e implantacion-01.02-131204 Página 42 de 58Fecha de la última modificación: 04/12/13
2-N
OR
01-N
orm
as-E
stan
dare
s de
sarr
ollo
e im
plan
taci
ón-0
0-00
-110
7201
12-
NO
R01
-Nor
mas
-Est
anda
res
desa
rrol
lo e
impl
anta
ción
-00-
00-1
1072
011
- Hay que definir la codificación que se utilizará para las páginas y utilizar siempre la
misma.
- Los mensajes (de error, de información…) que aparecen en la aplicación deben
ayudar al usuario final, no al desarrollador.
- Se deben utilizar plantillas para elementos comunes de la interfaz de usuario.
- Para no tener que escapar los caracteres en código JavaScript embebido en una
XHTML, hay que encapsular el texto con una expresión CDATA:
<script type="text/javascript">
/* <![CDATA[ */ // contenido del JavaScript /* ]]> */
</script>
- En el UI no habrá acceso a ninguna funcionalidad que no esté implementada aún.
- No deben mostrarse trazas de excepción al usuario. Este debe recibir el error
ocurrido y la traza debe volcarse en los logs del servidor, pero no debe mostrarse en
pantalla.
5.10Testeo
La puesta en marcha de aplicaciones en el entorno de la AVS requiere la definición
y ejecución de pruebas que promuevan la estabilidad y la funcionalidad de estas.
A continuación mostramos un listado de los entornos existentes y las pruebas que
deben ejecutarse en cada uno de ellos:
- Entorno de test:
Destinado a la ejecución de pruebas funcionales.
- Entorno de preproducción:
Destinado a la ejecución de pruebas de carga y de estrés del sistema.
- Entorno de integración continua:
Destinado a la ejecución de pruebas unitarias. En este entorno, se lanzan las pruebas
unitarias y se revisa la cobertura de código que estas suministran. Además, se
prueba tanto la generación de informes a partir de análisis estático del código, como
la compilación y el empaquetado de la aplicación.
Archivo: 2-NOR01-Normas-Estandares Desarrollo e implantacion-01.02-131204 Página 43 de 58Fecha de la última modificación: 04/12/13
2-N
OR
01-N
orm
as-E
stan
dare
s de
sarr
ollo
e im
plan
taci
ón-0
0-00
-110
7201
12-
NO
R01
-Nor
mas
-Est
anda
res
desa
rrol
lo e
impl
anta
ción
-00-
00-1
1072
011
5.10.1 Pruebas unitarias
Para ejecutar las pruebas unitarias en el entorno de integración continua existen dos
opciones:
1. El uso de bases de datos en memoria embebibles dentro de la aplicación en forma de
JAR, con el objeto de minimizar el coste de integrar la aplicación en este ciclo, o
incluso llegar a automatizar esta integración.
2. La generación del esquema de datos en el entorno de CI.
La segunda opción es la única válida si la aplicación contiene código dependiente
del SGBD (por ejemplo PL/SQL). En este caso, la ejecución de las pruebas debe dejar la
base de datos en el mismo estado en el que estaba antes de lanzarlas.
De los tests preparados para una aplicación se espera una cobertura de testeo alta,
alrededor del 75%, y un tasa de éxito del 100% en los tests.
Esto puede parecer una exigencia muy alta y podría argumentarse que las
pruebas unitarias son costosas de mantener, pero los tests no son código
extra: el mantenimiento de la aplicación se debe hacer en base a los resultados de dichos
tests.
Para construir pruebas unitarias:
- Hay que conseguir que los resultados de estas sean correctos.
- Se tienen que probar condiciones de frontera (listas vacías, extremos, valores nulos,
etc.). Para ello hay que tener en cuenta:
o Que haya conformidad con los resultados esperados.
o Que la ordenación de valores sea la correcta.
o Que los resultados estén dentro del rango de valores esperado.
o Que existen los valores devueltos y son los que se esperan.
- Hay que probar las relaciones entre objetos en ambos sentidos.
- Hay que intentar comprobar los resultados por otros medios distintos a los del test.
- Se tienen que provocar condiciones de error.
- Se puede comprobar que el rendimiento de las pruebas está dentro de los márgenes
esperados.
Archivo: 2-NOR01-Normas-Estandares Desarrollo e implantacion-01.02-131204 Página 44 de 58Fecha de la última modificación: 04/12/13
2-N
OR
01-N
orm
as-E
stan
dare
s de
sarr
ollo
e im
plan
taci
ón-0
0-00
-110
7201
12-
NO
R01
-Nor
mas
-Est
anda
res
desa
rrol
lo e
impl
anta
ción
-00-
00-1
1072
011
- Las pruebas unitarias deben ser deterministas (repetibles) e independientes del orden
en el que se ejecuten.
- Debe usarse JUnit 4.x (o Test NG 6.x) o superior. Se tiene que poder automatizar su
lanzamiento
- Antes de una prueba, debe asumirse que no hay datos en la base de datos. Es
responsabilidad de esta crearlos, probarlos y borrarlos.
- En las pruebas de garantía, prueba también los servicios web.
- Los nombres de los tests deben describir claramente qué hacen.
- Utiliza import static Assert.* para tener disponibles los métodos assert en
las clases de test.
5.11Aspectos metodológicos técnicos
Si bien la metodología es responsabilidad última del proveedor y del responsable de la
aplicación por parte de la CS/AVS, vamos a delimitar aquí algunos aspectos que sería
deseable que cumplieran las aplicaciones.
En mayor o menor medida, todos ellos van enfocados a facilitar los despliegues y a
la posibilidad de hacer configuraciones que no requieran despliegue de nueva versión.
Cualquier proveedor debe conocer los entornos por los que ha de pasar y ha de intentar
minimizar el impacto de cualquier cambio que se requiera.
Sería deseable que toda aplicación permitiese un rol de usuario que fuese
administrador de configuraciones y otro que fuese observador de estas. Estos usuarios
serían capaces de configurar u observar la configuración de tal forma que vía un interfaz
web restringido y adecuado a la imagen de la aplicación final se pudiera:
- Releer en caliente los ficheros de propiedades.
- Comprobar el estado de las integraciones (véase la sección 5.8).
- Evaluar o replanificar tareas programadas.
A la hora de realizar desarrollo no hemos restringido por IDE pero sí exigiremos que
los nuevos proyectos entreguen de tal forma que se pueden empaquetar aquí. Eso
supone que:
Archivo: 2-NOR01-Normas-Estandares Desarrollo e implantacion-01.02-131204 Página 45 de 58Fecha de la última modificación: 04/12/13
2-N
OR
01-N
orm
as-E
stan
dare
s de
sarr
ollo
e im
plan
taci
ón-0
0-00
-110
7201
12-
NO
R01
-Nor
mas
-Est
anda
res
desa
rrol
lo e
impl
anta
ción
-00-
00-1
1072
011
- El paquete entregado contiene todo lo necesario. Eso incluye scripts, .txt de
apoyo, tests, etc. Aquí incluimos como parte indivisible a la información creada o
configurada en la base de datos.
La aplicación entregada debe ser flexible para poder desplegarse en distintos
entornos. En el caso de los tests, estos deben poder ejecutarse de forma que el estado de
la base de datos se quede igual que antes de lanzarlos.
Debe plantearse la necesidad de implementar mocks o stubs para emular sistemas
externos cuando realicemos tests. En el caso de despliegue, esta debería estar preparada
para que fallen estas integraciones de modo que o bien se nos avise de su no.
La idea subyacente de estas prácticas es concienciar a que la aplicación debería
poder desplegarse en cualquier servidor siguiendo una serie de pasos o indicaciones
guiadas. Por ejemplo, no es aceptable que sea necesario realizar un dump de producción
para regenerar una nueva base de datos de la misma aplicación.
5.12Análisis estático de la aplicación
Las aplicaciones Java son analizadas por personal de CS/AVS usando la
herramienta de análisis Sonar.
Existe la posibilidad de definir exclusiones sobre código que no se desea analizar.
Sonar dispone de propiedades de análisis para definir patrones de exclusión (por ejemplo
sonar.exclusions o sonar.skippedModules)
Las clases susceptibles a ser excluidas son las siguientes:
• Código 100% autogenerado, no modificado tras su generación (por ejemplo, Stubs
generados por Axis2).
• DTOs
• POJOs
La responsabilidad de decidir de qué clases o módulos se excluyen del análisis
estático recae sobre el personal de CS/AVS, por lo que:
• No se tendrá en cuenta las exclusiones que puedan definirse en en la configuración
de la aplicación (ficheros pom.xml de Maven u otros scripts).
• Estas propiedades serán sobreescritas en el momento del análisis por los valores
que el personal de CS/AVS considere oportunos. Por tanto cualquier exclusión
deberá ser comunicada explícitamente para que sea evaluada y añadida a la lista
de exclusiones.
Archivo: 2-NOR01-Normas-Estandares Desarrollo e implantacion-01.02-131204 Página 46 de 58Fecha de la última modificación: 04/12/13
2-N
OR
01-N
orm
as-E
stan
dare
s de
sarr
ollo
e im
plan
taci
ón-0
0-00
-110
7201
12-
NO
R01
-Nor
mas
-Est
anda
res
desa
rrol
lo e
impl
anta
ción
-00-
00-1
1072
011
Anexo A. Glosario de términos y siglas- API: Application Program Interface
- DAO: Data Access Object
- CRUD: Create, Retrieve, Update, Delete
- DTO: Data Transfer Object
- EJB: Enterprise Java Bean
- HTML: HyperText Markup Language
- HTTP: HyperText Transfer Protocol
- JDK: Java Development Kit
- JPA: Java Persistence API
- JTA: Java Transaction API
- JRE: Java Runtime Edition
- JSF: JavaServer Faces
- JSP: Java Server Pages
- ORM: Object-Relational Mapping
- PL/SQL: Procedural Language SQL
- POJO: Plain Old Java Object
- REST: REpresentational State Transfer
- SQL: Standard Query Language
- SOAP: Simple Object Access Protocol
- SSL: Secure Sockets Layer
- SSO: Single Sign-On
- UTF: Unicode Transformation Format
- UI: User Interface
- VO: Value Object
- WSDL: Web Service Definition Language
Archivo: 2-NOR01-Normas-Estandares Desarrollo e implantacion-01.02-131204 Página 47 de 58Fecha de la última modificación: 04/12/13
2-N
OR
01-N
orm
as-E
stan
dare
s de
sarr
ollo
e im
plan
taci
ón-0
0-00
-110
7201
12-
NO
R01
-Nor
mas
-Est
anda
res
desa
rrol
lo e
impl
anta
ción
-00-
00-1
1072
011
Anexo B. Dossiers de tecnologías de desarrollo
Spring
- Para aplicaciones que se ejecuten sobre Java 5, recomendamos el uso de
anotaciones en lugar de XML para los ficheros ApplicationContext.
- El nombre de los beans será, siempre que sea posible y no haya duplicados, el
mismo que el nombre de clase siguiendo las convenciones de nomenclatura de
Spring. P. ej: usuariosDao para UsuariosDAO.java.
- No tenemos preferencias respecto al modelo de inyección de dependencias.
Recomendamos el basado en constructores ya que los errores de enlace son más
fáciles de detectar. Cualquiera que sea la opción elegida, lo que sí recomendamos es
ser consistente en todo el proyecto.
- En Spring NO se debe acceder al contexto directamente si no está justificado por
alguna carga dinámica de clases que dependa del nombre del bean o similar.
- Los ApplicationContext definidos en xml deben separarse por capas o por
funcionalidad. Desaconsejamos tener un único fichero con todos los beans.
Spring Test
- Recomendamos @Autowired para inyectar las dependencias a los beans en los
tests.
Spring AOP
- Recomendamos la creación de dos excepciones en todo proyecto:
NomAplNoRollbackRuntimeException y NomAplRollbackRuntimeException, ambas
descendientes de RuntimeException de tal forma que
NomAplRollbackRuntimeException se use en AOP para abortar transacciones
cuando ocurran ciertas condiciones y se rebase el interceptor.
Hibernate
- Utiliza genéricos para los métodos comunes de la capa de DAOs. Simplifican
enormemente el desarrollo de la capa de datos.
- Evitar, en la medida de lo posible, la edición manual de la configuración de mapeo y
usar herramientas para generar automáticamente este mapeo tales como Hibernate
Tools .
Archivo: 2-NOR01-Normas-Estandares Desarrollo e implantacion-01.02-131204 Página 48 de 58Fecha de la última modificación: 04/12/13
2-N
OR
01-N
orm
as-E
stan
dare
s de
sarr
ollo
e im
plan
taci
ón-0
0-00
-110
7201
12-
NO
R01
-Nor
mas
-Est
anda
res
desa
rrol
lo e
impl
anta
ción
-00-
00-1
1072
011
- Se recomienda dejar el atributo lazy siempre a true (valor por defecto) en la
configuración de mapeo, y usar "fetch joins" en aquellas consultas en las que se
desee cargar información de varias entidades al mismo tiempo por razones de
rendimiento.
- Para implementar el mapeo recomendamos una de estas dos opciones:
o Definir los ficheros hbm.xml y crear tanto el esquema como los POJOs a
partir de él con Hibernate Tools .
o Definir los mapeos mediante anotaciones JPA.
- Para la generación de identificadores automáticos, elige la opción native de forma
que la librería elija la transformación necesaria.
- En el caso de usar claves primarias de tipo natural, implementa .equals()
y .hashCode() .
- Utiliza bind variables para que se empleen PreparedStatements a partir del código
Hibernate e intenta externalizar las cadenas que contienen las SQL.
- No mezcles código ORM con código JDBC puro excepto si todas las partes coinciden
en que hay un cuello de botella.
- Utiliza siempre la sesión de Hibernate , no gestiones las conexiones directamente con
JDBC.
- Es preferible usar mapeos bidireccionales de relaciones.
- Ajusta las cachés de Hibernate teniendo en cuenta que la aplicación debe optimizar
el acceso a los datos pero a la vez que debe controlarse el consumo de memoria
utilizado (revisa tamaños y tiempos de expiración para la caché de sesión) y que la
aplicación se ejecutará en un cluster.
o Recuerda que la Query Cache no guarda estado sino identificadores.
o Estudia las implicaciones de las estrategias de cacheo de segundo nivel.
JSF
Recomendaciones generales
- Es preferible utilizar JSF 2.x o superior.
- Hay que evitar el uso de JSPs: Aunque se pueden utilizar, en JSF 2.0 no es
recomendable.
- Se debe de intentar mantener el enfoque de Convención sobre Configuración.
Archivo: 2-NOR01-Normas-Estandares Desarrollo e implantacion-01.02-131204 Página 49 de 58Fecha de la última modificación: 04/12/13
2-N
OR
01-N
orm
as-E
stan
dare
s de
sarr
ollo
e im
plan
taci
ón-0
0-00
-110
7201
12-
NO
R01
-Nor
mas
-Est
anda
res
desa
rrol
lo e
impl
anta
ción
-00-
00-1
1072
011
- Aconsejamos el uso de anotaciones en lugar de configurar faces-config.xml si la
máquina virtual sobre la que se va a ejecutar es 1.5 o superior.
- Está prohibido utilizar rutas codificadas (hardcoded paths) y rutas absolutas para
acceder a recursos ya que puede haber problemas dependiendo del contexto en el
que se instale la aplicación. Las alternativas existentes consisten en:
1. obtener dinámicamente contextPath:
<link rel="stylesheet" type="text/css"
href="#{facesContext.externalContext.requestContext Path}/recursos/css/st.css" />
� utilizar manejadores de recursos (JSF 2.0) que permitan indicar en
qué parte de la página (target) se deben visualizar. Estos recursos
deben residir en el directorio resources o en uno de sus
subdirectorios y esto los hace accesibles con: <h:outputScript> y
<h:outputStylesheet> .
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:ui="http://java.sun.com/jsf/facelets"
xmlns:h="http://java.sun.com/jsf/html">
<h:head>
...
</h:head>
<h:body>
< h:outputStylesheet library="css" name="styles.css" target="body"/>
< h:outputScript library="javascript" name="util.js" target="head"/ >
...
</h:body>
</html>
- Al cargar un Message Bundle de I18N, es más eficiente usar el elemento resource-
bundle (faces-config.xml) que el tag f:loadBundle .
- Recomendamos que los componentes lleven IDs explícitos en lugar de dejar que los
genere el propio framework. Esto facilita poder acceder a ellos a través de Ajax así
como integrar las páginas en frameworks de pruebas.
- Los mensajes de error de conversión y validación estándar pueden sobreescribirse
en el bundle de multiidioma.
- Uso del parámetro de contexto javax.faces.PROJECT_STAGE en web.xml para la
depuración de aplicaciones JSF. En PRO es obligatorio inicializarlo a Production (es el
valor por defecto).
<context-param>
<param-name>javax.faces.PROJECT_STAGE</param-name>
Archivo: 2-NOR01-Normas-Estandares Desarrollo e implantacion-01.02-131204 Página 50 de 58Fecha de la última modificación: 04/12/13
2-N
OR
01-N
orm
as-E
stan
dare
s de
sarr
ollo
e im
plan
taci
ón-0
0-00
-110
7201
12-
NO
R01
-Nor
mas
-Est
anda
res
desa
rrol
lo e
impl
anta
ción
-00-
00-1
1072
011
<param-value>Development</param-value>
</context-param>
- Debe usarse urlrewrite o similar para obtener urls amigables.
- Además de la estructura de directorios dictada en JEE, en JSF2 los recursos deben ir
en el directorio resources.
- Sugerimos la siguiente organización de las páginas XHTML:
o views: Para páginas accesibles desde el navegador.
o sections: Un directorio por página que componga las vistas y un directorio
shared.
o templates: Para plantillas.
o resources/components. Para usar composite components, se declara un
namespace y se utilizan tags. Este namespace siempre es
http://java.sun.com/jsf/composite más el nombre del directorio donde el
componente reside (bajo resouces). El nombre del componente es el
nombre del fichero XHTML, sin su extensión.
- Hay que evitar que se pueda acceder directamente a plantillas o fragmentos de
página.
Archivo: 2-NOR01-Normas-Estandares Desarrollo e implantacion-01.02-131204 Página 51 de 58Fecha de la última modificación: 04/12/13
2-N
OR
01-N
orm
as-E
stan
dare
s de
sarr
ollo
e im
plan
taci
ón-0
0-00
-110
7201
12-
NO
R01
-Nor
mas
-Est
anda
res
desa
rrol
lo e
impl
anta
ción
-00-
00-1
1072
011
Managed Beans
- Hay que hacer que los Beans de sesión sean serializables.
- Se deben usar de nombres de FaceBeans descriptivos. Recomendamos utilizar el
mismo nombre de la clase que lo implementa, teniendo estos un sufijo común
(*FaceBean.java o *FB.java).
- Se usará una nomenclatura uniforme para métodos del mismo tipo (mismo prefijo o
sufijo):
o Métodos de tipo action: action*() o *Action().
o Métodos de tipo actionListener: actionListener*() o *ActionListener().
Navegación
- Se debe intentar simplificar al máximo las navegaciones aprovechando las
convenciones de navegación que presenta JSF2.
- Por defecto, JSF hace uso de forwards para redirigir de una página a otra, pero
puede usarse redirect especificando el parámetro faces-redirect:
<h:commandButton label="Login" action="welcome?face s-redirect=true"/>
- Un método action debe devolver null para indicar que la misma vista debe ser
mostrada de nuevo. En este caso, el view scope se mantiene. Cualquier salida
distinta de null purgará este view scope, incluso si la vista resultante fuera la misma
que la actual.
o Hay que usar métodos action para cambios de página y action listener
siempre que el evento no requiera un cambio de vista ya que no interactúan
con el manejador de navegación.
Facelets
- Se debe de fomentar el uso de facelets en la creación de plantillas y componentes.
Datatables
- En algunos casos puede considerarse como alternativa el uso de ui:repeat para
generar tablas.
Event Handling
- Uso de immediate para los UIAction que no requieran actualizar el modelo (botones
de cancelación, vuelta atrás, etc.)
Archivo: 2-NOR01-Normas-Estandares Desarrollo e implantacion-01.02-131204 Página 52 de 58Fecha de la última modificación: 04/12/13
2-N
OR
01-N
orm
as-E
stan
dare
s de
sarr
ollo
e im
plan
taci
ón-0
0-00
-110
7201
12-
NO
R01
-Nor
mas
-Est
anda
res
desa
rrol
lo e
impl
anta
ción
-00-
00-1
1072
011
Composite
- Crea componentes pequeños de forma que sean más sencillos de mantener y
puedan reutilizarse combinándose para formar componentes más grandes.
- Empaqueta los componentes composite en ficheros .jar.
Ajax
- Para aportar mayor dinamismo a las páginas usa procesamiento y visualización
parcial con los atributos render y execute de la etiqueta f:ajax .
- Es preferible utilizar Ajax o frameworks JavaScript para implementar valiadaciones
tempranas de datos.
- Muestra siempre el progreso de las peticiones Ajax asociando funciones JavaScript
en el atributo onevent del tag f:ajax.
- Aconsejamos disponer de funciones JavaScript que manejen los posibles errores
producidos en la petición así como el control de su estado estado.
<f:ajax onerror="handleAjaxError" onevent=”showProg ress”/>
- JSF encola automáticamente las peticiones Ajax y las ejecuta secuencialmente. Sin
embargo no encola las peticiones HTTP, por lo que mezclarlas puede causar
situaciones no esperadas. A continuación mostramos un ejemplo de cómo hacer que
las peticiones HTTP sean también peticiones Ajax :
<h:form>
<h:inputText ...>
<f:ajax onblur="..."/>
</h:inputText> <h:commandButton value="submit" action="nextPage ">
<f:ajax/>
</h:commandButton>
</h:form>
Maven
- Para proyectos Maven con más de un módulo, los fuentes de la aplicación deberán
disponer en su directorio raíz de un pom multimódulo. Este pom servirá para
coordinar la compilación y empaquetado de todos sus módulos, así como para lanzar
los análisis de Sonar.
- Ejemplo de pom multimódulo:
Archivo: 2-NOR01-Normas-Estandares Desarrollo e implantacion-01.02-131204 Página 53 de 58Fecha de la última modificación: 04/12/13
2-N
OR
01-N
orm
as-E
stan
dare
s de
sarr
ollo
e im
plan
taci
ón-0
0-00
-110
7201
12-
NO
R01
-Nor
mas
-Est
anda
res
desa
rrol
lo e
impl
anta
ción
-00-
00-1
1072
011
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchem a-instance"
xsi:schemaLocation="http://maven.apache.or g/POM/4.0.0http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>es.san.gva.appId</groupId>
<artifactId> appId </artifactId>
<version> X.Y.Z </version>
<packaging>pom</packaging>
<name> appName</name>
<description> Descripción de la aplicación </description>
<modules>
<module> modulo1 </module>
<module> modulo2 </module>
<module> modulo3 </module>
<module> modulo4 </module>
</modules>
</project>
- La configuración de este fichero deberá ser revisada por GEES, para establecer el
groupId, artifactid, nombre y descripción adecuados. Una vez fijados los parámetros
de configuración del pom, se mantendrán constantes durante todas las entregas del
proyecto para facilitar el seguimiento de su evolución.
- El groupId siempre será es.gva.san.<appId>.
- El artifactId irá todo en minúscula.
- El name debe ser explicativo. Se permite que sea igual que el artifactId. No se
permitirá que dos módulos de un mismo proyecto tengan el mismo name.
- No se debe incluir referencias a número de versiones en los nombres de los
directorios de los módulos ni en el pom.xml multimódulo. De esta forma los nombres
de los directorios no variarán con los despliegues (mantendremos una estructura de
directorios homogénea a lo largo de las entregas) y será más sencillo mantener el
pom.xml entre versiones (no habrá que actualizar las referencias a los módulos, sólo
el campo versión de los pom).
- Es importante que el campo description esté rellenos y sea significativo, ya que esta
información se visualiza desde otras herramientas, como por ejemplo Maven o Sonar.
- La empresa desarrolladora indicará a CS/AVS el comando a utilizar para generar los
binarios de la aplicación (perfiles a incluir. propiedades, etc)
Archivo: 2-NOR01-Normas-Estandares Desarrollo e implantacion-01.02-131204 Página 54 de 58Fecha de la última modificación: 04/12/13
2-N
OR
01-N
orm
as-E
stan
dare
s de
sarr
ollo
e im
plan
taci
ón-0
0-00
-110
7201
12-
NO
R01
-Nor
mas
-Est
anda
res
desa
rrol
lo e
impl
anta
ción
-00-
00-1
1072
011
- La empresa desarrolladora facilitará al personal de CS/AVS la información necesaria
para resolver las dependencias del código (conjunto de repositorios públicos
utilizados, dependencias de terceros, etc).
- Cada release deberá incrementar el número de versión, No se permitirá la entrega de
dos versiones con distinto código fuente y mismo número de versión.
- Deberá establecerse correctamente las versión de Java usada para la compilación
(tanto en el source como en el target) y el encoding utilizado.
- La precompilación los de JSP de la aplicación, en caso de que sea un requisito,
deberá estar integrada en MVN
- En CS/AVS existe un repositorio de artefactos Nexus que agrupa una larga lista de
repositorios públicos. Si un artefacto se encuentra en un repositorio público, no se
aceptará el uso de otros groupId y artifactId no sean esos.
- Existe un repositorio para librerías 3rd party cuyo único propósito será contener
librerías que no se encuentran en repositorios públicos.
- En caso que estuviese justificada la utilización de drivers de Oracle, el proveedor
deberá adecuar el groupId y artifactid de la dependencia según las indicaciones del
personal de CS/AVS. Sólo está justificado este tipo de dependencia con scope test.
-
- Al usar Maven hay que definir propiedades configurables como variables que se lean
de ficheros de filtro. Sin embargo, hay que evitar usar este mecanismo para crear
entregables distintos dependiendo del entorno del cliente.
- Se debe definir el encoding del fichero pom.xml y se debe incluir toda la información
de localización de proyecto, así como el listado de desarrolladores involucrados.
- Aunque se usen plugins de IDE para gestionar el pom.xml de un proyecto, antes de la
entrega debe cuidarse el formato y el contenido de este y debe asegurarse que
funciona independientemente del plugin.
- El uso de Maven facilita la gestión de librerías así que hay que aprovechar la
instalación de Nexus implantada en CS / AVS. No se aceptarán dependencias de tipo
system.
Archivo: 2-NOR01-Normas-Estandares Desarrollo e implantacion-01.02-131204 Página 55 de 58Fecha de la última modificación: 04/12/13
2-N
OR
01-N
orm
as-E
stan
dare
s de
sarr
ollo
e im
plan
taci
ón-0
0-00
-110
7201
12-
NO
R01
-Nor
mas
-Est
anda
res
desa
rrol
lo e
impl
anta
ción
-00-
00-1
1072
011
- No se aceptarán el uso dependencias cuya versión sea SNAPSHOT. Este tipo de
versiones hacen referencia a artefactos que no han sido publicados. Normalmente
este tipo de versiones se usan en entornos de desarrollo. Este tipo de versiones que
pueden ser fuentes de problemas ya que el contenido de una versión SNAPSHOT
puede variar con el tiempo y por tanto no tenemos la certeza de que dos proyectos
que tengan la misma dependencia a una librería con este tipo de versionado, la
resuelvan correctamente. Necesitamos que el contenido de cada librería sea único en
cada versión y que no existan variantes de una librería con el mismo número de
versión.
- No se incluirán en los entregables librerías que estén ya en el servidor de
aplicaciones y que la CS / AVS haya marcado como corporativas. Para evitar esto,
hay que usar las dependencias de tipo provided.
Ant
- Deberá existir un target encargado de realizar todas las tareas necesarias para
compilar y empaquetar el código fuente para el entorno de CS/AVS. El proveedor
facilitará a CS/AVS la línea de comandos para lanzar dicho target.
- Para la generación de los binarios del entorno de CS/AVS no se permitirá la
utilización rutas absolutas ya que esta tarea debe ser independiente del entorno
donde se realice.
- Los fuentes proporcionados deberán incluir todas las librerías necesarias para la
correcta generación de los binarios.
- Los targets de compilación que se utilicen para compilar los fuentes en CS/AVS
deberán declarar explícitamente la JVM requerida para compilar el proyecto
(parámetro compiler), así como el encoding de los fuentes (parámetro encoding) . Los
binarios generados para el entorno de CS/AVS no deben incluir información de debug(debug=off). Ver https://ant.apache.org/manual/Tasks/javac.html
- El código fuente de la aplicación será analizado por CS/AVS usando la herramienta
Sonar, por lo que los fuentes deberán estar preparados para dicho análisis. Como
alternativas se permite tanto la integración de ANT con Sonar como el uso de ficheros
pom de Maven que complementen las tareas de ANT.
- La precompilación los de JSP de la aplicación, en caso de que sea un requisito,
deberá estar integrada en AntUsar ficheros .properties para parametrizar los scripts.
- Dentro de build.xml, separar claramente las secciones de:
o Definición de variables, librerías y rutas.
Archivo: 2-NOR01-Normas-Estandares Desarrollo e implantacion-01.02-131204 Página 56 de 58Fecha de la última modificación: 04/12/13
2-N
OR
01-N
orm
as-E
stan
dare
s de
sarr
ollo
e im
plan
taci
ón-0
0-00
-110
7201
12-
NO
R01
-Nor
mas
-Est
anda
res
desa
rrol
lo e
impl
anta
ción
-00-
00-1
1072
011
o Compilación y limpieza.
o Empaquetado.
o Compilación.
- Comentar todas las tareas que se definan y usen.
Quartz
La integración de Quartz supone la creación de una serie de tablas en nuestro
modelo de datos. Estas tablas forman parte de la aplicación y tienen que venir junto al
resto del despliegue.
Quartz permite guardar información en los triggers y en los jobs. Para guardar esta
información de forma física usaremos Strings. Puede guardarse cualquier objetoSerializable pero cualquier cambio en la signatura de este objeto puede hacer
irrecuperables los jobs actuales.
Archivo: 2-NOR01-Normas-Estandares Desarrollo e implantacion-01.02-131204 Página 57 de 58Fecha de la última modificación: 04/12/13
2-N
OR
01-N
orm
as-E
stan
dare
s de
sarr
ollo
e im
plan
taci
ón-0
0-00
-110
7201
12-
NO
R01
-Nor
mas
-Est
anda
res
desa
rrol
lo e
impl
anta
ción
-00-
00-1
1072
011
Anexo C. Clase Java para certificados a través deReverse Proxy.
Para facilitar a los proveedores la lectura de las cabeceras HTTP para la
extracción de los certificados de usuarios, en aquellas aplicaciones que no utilicen el
SSO para la autenticación de los mismos, se facilita el siguiente código JAVA.
public X509Certificate[] getSSLClientCertificateCha in(HttpServletRequest request)
throws CertificateException
{
X509Certificate[] certs = null;
String clientCert = request.getHeader("Http-Cer tificado");
String aux = "";
String sCadenaSinBlancos = "";
if (clientCert != null) {
clientCert = clientCert.replaceAll("% d% a" , "\n");
if (StringUtils.countMatches(clientCert, "- ----BEGIN CERTIFICATE-----") ==
0){
clientCert = "-----BEGIN CERTIFICATE--- --\n" + clientCert + "\n-----ENDCERTIFICATE-----";
} else {
StringTokenizer stTexto = new StringTok enizer(clientCert);
while (stTexto.hasMoreElements()){
sCadenaSinBlancos += stTexto.nextEl ement();
}
clientCert = sCadenaSinBlancos;
clientCert = clientCert.replaceAll("--- --BEGINCERTIFICATE-----", "-----BEGINCERTIFICATE-----\n"); clientCert = clientCert.replaceAll("-----ENDCERTIFI CATE-----", "\n-----ENDCERTIFICATE-----");
}
byte[] certBytes = new byte[clientCert.leng th()]; certBytes = clientCert.getBytes();
ByteArrayInputStream bais = new ByteArrayIn putStream(certBytes);
CertificateFactory cf = CertificateFactory. getInstance("X.509");
certs = new X509Certificate[1];
certs[0] = (X509Certificate) cf.generateCer tificate(bais);
}
return certs;
}
Archivo: 2-NOR01-Normas-Estandares Desarrollo e implantacion-01.02-131204 Página 58 de 58Fecha de la última modificación: 04/12/13