2-NOR01-Normas Normativa de Desarrollo e Implantacion-01 ... · 2-NOR01-Normas-Estandares...

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


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


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


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.


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.


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:


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


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>


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>


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


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.


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


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;) .


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.


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)


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.


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.


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


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)


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.


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


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


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


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


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


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.


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


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.


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.


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.


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


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


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.


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


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í.


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.


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.


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.


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:


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.


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


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 .


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.


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>


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.


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.)


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:


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>




</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)


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.


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.


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.


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;

}


2-NOR01-Normas Normativa de Desarrollo e Implantacion-01 ... · 2-NOR01-Normas-Estandares...

Documents

Transcript of 2-NOR01-Normas Normativa de Desarrollo e Implantacion-01 ... · 2-NOR01-Normas-Estandares...