ast-esp-especificaciones técnicas de los entornos … · especificaciones técnicas de los...

Especificaciones Técnicas de los Entornos J2EE del Gobierno de Aragón

Referencia: AST-ESP-Especificaciones Técnicas de los Entornos J2EE del Gobierno de Aragón.doc

Autor: AST

Fecha de creación: 31/08/2011

Última actualización: 31/08/2011

Versión: v2.0

Clasificación: Uso Público



Ref.: AST-ESP-Especificaciones Técnicas de los Entornos J2EE del Gobierno de Aragón.doc Fecha: 31.08.2011 Versión: v2.0

Pág. 2 de 78

Entidad Pública Aragonesa de Servicios TelemáticosPº María Agustín 25-27-29 • 50071 ZARAGOZA

Tel. 976 71 4495 • Fax. 976 71 4395www.aragon.es

Contenido

1. INTRODUCCIÓN................................................................................................................................. 5

2. ARQUITECTURA DE PLATAFORMA TECNOLÓGICA.......... .......................................................... 6

3. ESTRUCTURA DE UN PROYECTO .................................................................................................. 9

3.1.1. Directorios generales comunes a todos los tipos de proyecto ................................................. 9

3.1.1.1. Manual de instalación ......................................................................................................... 10

3.1.1.2. Directorio LIB ...................................................................................................................... 11

3.1.1.3. Directorio SRC/CONF ......................................................................................................... 11

3.1.1.4. Ficheros de propiedades .................................................................................................... 12

3.1.1.5. Scripts de BBDD ................................................................................................................. 12

3.1.1.6. Ficheros estáticos y temporales ......................................................................................... 13

3.1.1.7. Componentes o módulos .................................................................................................... 13

3.1.2. Proyectos web simples ........................................................................................................... 14

3.1.3. Proyectos web complejos ....................................................................................................... 16

3.1.4. Ejemplo de proyecto ............................................................................................................... 17

4. ESPECIFICACIONES DEL ENTORNO ................... ......................................................................... 18

4.1. CAPA FRONTAL ........................................................................................................................ 18

4.2. CAPA MEDIA O DE SERVIDOR DE APLICACIONES............................................................... 18

4.2.1. Versiones del producto (Oracle Application Server Release 3) ............................................. 19

4.2.2. Librerías comunes (OAS-R3) .................................................................................................. 19

4.2.3. Librerías compartidas entre varias aplicaciones (shared) ...................................................... 19

4.2.4. Configuración por defecto de una instancia OC4J ................................................................. 20

4.3. CAPA DE BASES DE DATOS .................................................................................................... 20

4.3.1. Balanceo de conexiones de BBDD ......................................................................................... 20

4.3.2. Configuración de BBDD (concurrencia de sesiones) ............................................................. 21

4.3.3. Formato del datasource para los OAS-R3 .............................................................................. 21

5. ESPECIFICACIONES DE DESARROLLO ................. ...................................................................... 23

5.1. CÓDIGO DE APLICACIÓN ......................................................................................................... 23

5.2. VERSIÓN DE LA APLICACIÓN .................................................................................................. 23

5.3. NOMENCLATURA DE PAQUETES Y CLASES JAVA............................................................... 23

5.4. GESTIÓN DE EXCEPCIONES ................................................................................................... 24

5.5. VERSIÓN DEL JDK .................................................................................................................... 24

5.6. USO DE NUEVOS FRAMEWORKS ........................................................................................... 24

5.7. INTEROPERABILIDAD ............................................................................................................... 24

5.8. UTILIZACIÓN DE PLATAFORMAS HORIZONTALES ............................................................... 24

5.9. HERRAMIENTAS NECESARIAS PARA DESARROLLOS J2EE ............................................... 25

5.9.1. Herramienta ANT .................................................................................................................... 25

5.9.2. JDK.......................................................................................................................................... 25

5.9.3. Log4j ....................................................................................................................................... 26

5.10. GESTIÓN DE USUARIOS .......................................................................................................... 26

5.10.1. Usuarios de aplicación ............................................................................................................ 26




Pág. 3 de 78



5.10.2. Usuarios de Base de Datos .................................................................................................... 27

5.11. DEFINICIÓN/CREACIÓN DE BASE DE DATOS ....................................................................... 27

5.12. INDICACIONES SOBRE ACCESIBILIDAD ................................................................................ 27

6. ESPECIFICACIONES DE DESPLIEGUE ................. ........................................................................ 29

6.1. PROCESO DE ALTA DE UN NUEVO PROYECTO ................................................................... 29

6.1.1. Solicitud de alta del CI ............................................................................................................ 29

6.1.2. Información específica a detallar ............................................................................................ 30

6.1.2.1. Descripción general de la aplicación .................................................................................. 30

6.1.2.2. Requisitos del aplicativo ..................................................................................................... 30

6.1.2.3. Descripción del modelo de datos ........................................................................................ 30

6.1.2.4. Arquitectura de aplicación................................................................................................... 30

6.1.2.5. Fuentes Java ...................................................................................................................... 30

6.1.2.6. Errores de aplicación .......................................................................................................... 31

6.1.2.7. Plan de pruebas .................................................................................................................. 31

6.1.2.8. Manual de usuario .............................................................................................................. 31

6.1.2.9. Manual de explotación ........................................................................................................ 31

6.2. ENTORNOS DE DESPLIEGUE DISPONIBLES ......................................................................... 31

6.3. PROCESO DE DESPLIEGUE DE UN PROYECTO................................................................... 31

6.3.1. Métodos de entrega ................................................................................................................ 31

6.3.2. Proceso de despliegue ........................................................................................................... 32

6.4. TIPOS DE DESPLIEGUE ........................................................................................................... 33

6.4.1. Despliegues Normales ............................................................................................................ 33

6.4.2. Despliegues Predefinidos ....................................................................................................... 33

6.4.3. Despliegues de urgencia ........................................................................................................ 33

6.4.4. Despliegue de “productos” ...................................................................................................... 34

6.5. POLÍTICA DE VERSIONADO ..................................................................................................... 34

6.5.1. Criterios de versionado ........................................................................................................... 34

6.5.1.1. Primer nivel X ...................................................................................................................... 35

6.5.1.2. Segundo nivel Y .................................................................................................................. 35

6.5.1.3. Tercer nivel Z ...................................................................................................................... 35

6.6. FORMATO DE LAS PETICIONES DE DESPLIEGUE ............................................................... 35

6.6.1. Lista de posibles entornos ...................................................................................................... 36

6.6.2. Flujo de peticiones/incidencias ............................................................................................... 37

6.7. VENTANAS DE DESPLIEGUE ................................................................................................... 37

7. REFERENCIAS ................................................................................................................................. 39

7.1. DOCUMENTACIÓN PREVIA EXISTENTE EN AST................................................................... 39

7.2. OTRAS REFERENCIAS ............................................................................................................. 40

ANEXO 1: RELACIÓN DE MÁQUINAS Y VERSIONES INSTALADA S (PRODUCCIÓN) ................. 41

ANEXO 2: ORACLE APPLICATION SERVER RELEASE 2 ...... ......................................................... 43

ANEXO 3: LIBRERÍAS OAS-R3 ......................... ................................................................................. 44

ANEXO 4: CONSIDERACIONES SOBRE CARGA DE CLASES LOCA LES ..................................... 47




Pág. 4 de 78



CARGA DE CLASES LOCALES EN LOS OAS-R2 .............................................................................. 47

CARGA DE CLASES LOCALES EN LOS OAS-R3 .............................................................................. 47

ANEXO 5: CONFIGURACIÓN DE PROFILES DE BBDD ........ ........................................................... 49

DESAPP0 .............................................................................................................................................. 49

DESAPP1 .............................................................................................................................................. 49

PREAPP0 .............................................................................................................................................. 50

PREAPP1 .............................................................................................................................................. 50

PROAPP0 .............................................................................................................................................. 51

PROAPP1 .............................................................................................................................................. 52

ANEXO 6: PARÁMETROS DE GLOBALIZACIÓN DE BBDD ...... ...................................................... 53

INSTANCE PARAMETERS .................................................................................................................. 53

DATABASE PARAMETERS ................................................................................................................. 53

ANEXO 7: PLATAFORMA DE FIRMA ELECTRÓNICA .......... ............................................................ 55

ANEXO 8: PLATAFORMA DE PASARELA DE PAGO ........... ............................................................ 57

ANEXO 9: AUTENTICACIÓN DE USUARIOS CON SAU ........ ........................................................... 58

ACTUACIONES EN SAU ...................................................................................................................... 58

ACTUACIONES EN APLICACIÓN JAVA ............................................................................................. 59

ACCIONES DE CONFIGURACIÓN ...................................................................................................... 60

ADMINISTRACIÓN DE USUARIOS ..................................................................................................... 61

ANEXO 10: AUTENTICACIÓN DE USUARIOS CON AUTOREGISTR O ........................................... 64

ANEXO 11: HERRAMIENTA ANT ......................... .............................................................................. 70

INSTALACIÓN DE LA HERRAMIENTA ANT ....................................................................................... 70

ANEXO 12: LOG4J ................................... ............................................................................................ 71

ANEXO 13: AUTENTICACIÓN DE USUARIOS CON LDAP ...... ........................................................ 72

ANEXO 14: MÉTODOS PARA GENERAR EL FICHERO EAR O JAR .............................................. 73

GENERACIÓN DEL ARCHIVO MANUALMENTE, MEDIANTE LA HERRAMIENTA JAR ................... 73

GENERACIÓN DEL ARCHIVO MEDIANTE LA HERRAMIENTA ANT ................................................ 73

ANEXO 15: DESPLIEGUE POR LÍNEA DE COMANDOS EN LOS O AS ........................................... 74

COMANDOS DEL DCM (SÓLO PARA LOS OAS-R2) ......................................................................... 74

DESPLIEGUE POR LÍNEA DE COMANDOS EN LOS OAS-R3 .......................................................... 74

ANEXO 16: USO DE UN PLAN DE DESPLIEGUE ............ ................................................................. 75

ANEXO 17: HTML VALIDATOR .......................... ................................................................................ 76

ANEXO 18: TAW3 (AA) ............................... ......................................................................................... 77




Pág. 5 de 78



1. Introducción

El presente documento define las especificaciones técnicas a seguir por toda aplicación que se despliegue en la arquitectura J2EE del Gobierno de Aragón.

Con el objetivo de facilitar la labor de desarrollo, integración y despliegue, el documento divide el escenario en varias partes diferenciadas:

� Parte I: Arquitectura : Breve descripción de todos los componentes que forman parte de la arquitectura del sistema, balanceo, servidor de aplicaciones, capa de datos,..

� Parte II : Estructura de un proyecto . Estructura organizativa que deberán cumplir los desarrollos J2EE.

� Parte III: Especificaciones del entorno. Configuración del entorno de servidores del Gobierno de Aragón.

� Parte III: Especificaciones de desarrollo. Directrices que se deberán seguir en el desarrollo de aplicaciones J2EE para los servidores del Gobierno de Aragón.

� Parte IV: Despliegue de aplicaciones: Políticas de despliegue de aplicaciones en los servidores del Gobierno de Aragón.

El documento va complementado con varios anexos con información más específica a modo de complemento.




Pág. 6 de 78



2. Arquitectura de plataforma tecnológica

A continuación se detalla la arquitectura tecnológica para el entorno J2EE en el Gobierno de Aragón. El objetivo es que antes de comenzar los desarrollos se tenga en cuenta el entorno final, de forma que se eviten conflictos a la hora de la puesta en producción de las aplicaciones.

Existen 3 entornos disponibles en los que se instalarán las aplicaciones de forma secuencial:

• Integración: Entorno para realizar el primer despliegue de la aplicación, además de pruebas básicas de funcionamiento. Se recuerda que es un servicio no balanceado y que este entorno sólo estará disponible en la red interna del Gobierno de Aragón.

• Preproducción: Entorno idéntico al de producción que facilitará la realización de las pruebas previas al paso a producción (integración, validación de usuario, estrés, etc).

• Producción: Entorno final.

El escenario que detallaremos a continuación define la estructura del entorno de producción, siendo el entorno de preproducción idéntico tanto en componentes como en configuración. Del mismo modo, el entorno de integración sirve para comprobar que la compilación se desarrolla adecuadamente y garantizar que las versiones de los productos coinciden con el escenario que nos vamos a encontrar en el entorno de producción.

La arquitectura tecnológica del Gobierno de Aragón está organizada en base a una estructura de 3 capas (Frontales web, capa de Servidor de Aplicaciones y capa de datos). Matizar que tanto las conexiones de base de datos como de servidores de aplicaciones, están balanceadas.




Pág. 7 de 78



La nomenclatura de los servidores sigue estos criterios:

CAPA ENTORNO TIPO MÁQUINA

f- frontal

m-medio

b-back

o –pro

e –pre

i -interno

f–físico

l – virtual ldom

v-virtual vmware




Pág. 8 de 78



De esta forma el prefijo “mof ” en mof-portal1 sería:

M - Capa Media / O - Producción / F - Físico

La siguiente tabla muestra la relación de los productos instalados divididos por capa en el entorno de producción:

DESCRIPCIÓN Componente (arquitectura)

INFRAESTRUCTURA TÈCNICA UTILIZADA

Sistema Versión Descripción detallada

Frontend Oracle Web

Cache fof-portal3 / fof-portal4 10.1.4.0.1

Oracle Application Server

Infrastructure 10g

Capa Media

Oracle Application

Server

mol-oas3 / mol-oas4 10.1.2.0.2

Oracle Application Server 10g

10.1.3.1.0 Oracle Application Server SOA Suite

mol-oas5 / mol-oas6 10.1.2.0.2 Oracle Application

Server 10g


Server 10g


Server 10g mol-oas11 / mol-

oas12 10.1.2.0.2


Single Sign On

mol-portal1 / mol-portal2

10.1.4.0.1 Oracle Application

Server Infrastructure 10g

Oracle Internet

Directory

mof-portal3 / mof-portal4



Backend Oracle Real Application

bof-portal1 / bof-portal2

10.1.2 RAC

Para más información sobre productos y versiones instaladas consulte el anexo I de este documento.




Pág. 9 de 78



3. Estructura de un proyecto

Todo proyecto que se entregue para ser desplegado en los servidores del Gobierno de Aragón, deberá tener una estructura determinada y cumplir con una serie de especificaciones que detallaremos a continuación.

Para la definición de la estructura de un proyecto deberán seguirse las convenciones tomadas en el documento “Project Conventions for Enterprise Applications Ear ly Access 1 ” definido dentro de las guías Java Blueprints .

El documento completo puede consultarse en:

http://java.sun.com/blueprints/code/projectconventions.html

Se definen varios tipos de proyecto según la complejidad que tengan. Esta complejidad define el formato de entrega. Existen tres tipos de proyectos:

• Componentes reutilizables o módulos : proyectos que forman parte de varios proyectos distintos y no pueden incluirse como parte de un solo proyecto complejo.

• Proyectos web simples: que definen una única aplicación web.

• Proyectos J2EE complejos: proyectos que incluyen varias aplicaciones web, tienen componentes que se reutilizan dentro de varios sistemas del propio proyecto, proyectos con EJBs, etc…

Para cada uno de estos tipos de proyectos vamos a analizar la estructura y detalles.

3.1.1. Directorios generales comunes a todos los ti pos de proyecto

Existe una serie de directorios que nos vamos a encontrar en todos los tipos de proyectos. Algunos de estos directorios tienen que formar parte de la estructura de la entrega y otros se generan durante el proceso de compilación (“build” y “dist”).

Algunos de los directorios que aparecen siempre en los proyectos son:

Directorio Contenido

docs/ Contiene toda la documentación relativa a un proyecto

lib/ Contiene librerías externas que son necesarias para la compilación o ejecución del proyecto.

src/ Dentro de este directorio se incluyen dos subdirectorios (si son necesarios los dos): “java” donde ubicamos los ficheros fuente y “conf ”, que contendrá los ficheros de configuración relacionados.

setup/ Este directorio contiene ficheros relacionados con la instalación del sistema, por ejemplo ficheros de configuración, manual de instalación, ficheros de creación de la base de datos, scripts a ejecutar, etc…




Pág. 10 de 78




test/ Contiene los ficheros necesarios para realizar las pruebas unitarias del sistema. Si está ubicado en un componente la prueba cubre únicamente al entorno del componente, si está ubicado en el directorio raíz del proyecto cubre todo el proyecto.

build/ Creado por la tarea BUILD de ANT. Contiene todos los componentes resultado de la compilación del proyecto (fuentes compilados, ficheros JARs, ficheros resultado de documentación generados con la herramienta Javadoc, etc.).

Si por ejemplo se generan otros resultados intermedios, por ejemplo un juego de pruebas unitarias, también generamos un directorio “BUILD ” dentro del directorio que contiene las pruebas unitarias.

dist/ Creado por la tarea DIST de ANT. Contiene una copia descomprimida de los binarios creados en el proyecto. Este directorio no es obligatorio que se genere.

Para la generación de todos los componentes del proyecto es necesario que se ejecuten las tareas que incluyen los ficheros build.xml. Deberá aparecer un fichero build.xml por cada componente/juego de pruebas que desarrollemos. Por ejemplo aparecerá un fichero build.xml para la generación de un fichero JAR, WAR o EAR, otro para la generación de juegos de pruebas unitarias, etc.

NOTA: Es imprescindible la entrega de un manual de instalación adecuado a la versión de la aplicación junto a los ficheros fuentes de la misma.

3.1.1.1. Manual de instalación

Deberá incluir obligatoriamente:

• Descripción de la aplicación y pasos para su instalación en cada entorno.

• Versión de la jdk que necesita para compilarse.

• Si es necesario que la aplicación se ejecute bajo http o https.

• Instrucciones de creación de directorios en el servidor, por ejemplo para ficheros de log de aplicación, ficheros temporales, etc.

o Explicación de los ficheros de configuración (distribuidos bajo el directorio “src/conf/” ) y valores que es necesario parametrizar para que la aplicación funcione correctamente en los entornos del Gobierno de Aragón.

o Creación de alias o directorios virtuales en el servidor web, en caso de ser necesario.

o Si se trata de una subida de versión, relación de cambios implementados respecto a la versión anterior.




Pág. 11 de 78



NOTA: Cualquier relación de dependencia de la aplicación con otros módulos, plataformas comunes, plataformas de autenticación propias de algún Departamento, etc, deberá ser indicada explícitamente en el manual de instalación.

NOTA: Cualquier ausencia de lo indicado anteriormente implicará el rechazo de las peticiones de despliegue hasta su subsanación.

3.1.1.2. Directorio LIB

Dentro del directorio “/lib” del directorio raíz tienen que incluirse todas las librerías en formato .JAR que se utilicen para el proceso de compilación del proyecto o que vayan a ser incluidas dentro del fichero WAR o EAR de las aplicaciones.

Excepción : no se deberá incluir en el envío las librerías comunes ya contenidas en los servidores de aplicaciones del Gobierno de Aragón.

Será necesario utilizar una propiedad en el fichero build.xml, de nombre oc4j.lib , que apuntará (en el momento de compilación de la aplicación) a una ruta que contendrá todas ellas.

NOTA: Sólo se aceptarán dentro del directorio “/lib” librerías desarrolladas por terceros, y para cada una deberá especificarse la versión exacta y la ubicación de donde puede descargarse.

En el caso de utilizar librerías comerciales, tendrá que consultarse primero con el grupo de despliegue, dependiendo la decisión final sobre su uso, del criterio de dichos técnicos. Se recomienda la utilización de librerías libres o que no precisen el pago de una licencia comercial.

NOTA: Las librerías con funcionalidades genéricas desarrolladas por la empresa en cuestión que se utilicen en el proyecto, no podrán ser incluidas en este directorio sino que tendrán que ser incluidas en el directorio “/components” como fuentes Java (*.java) y compiladas durante el proceso de compilación.

3.1.1.3. Directorio SRC/CONF

Dentro de este directorio se distribuirán todos los ficheros susceptibles de parametrización de un entorno a otro, como ficheros de propiedades, de configuración, de acceso a fuentes de datos, etc.

Estos ficheros se deberán entregar por triplicado, uno por cada uno de los entornos de ejecución de las aplicaciones (integración, preproducción, producción), de forma que el proveedor entregue la aplicación una única vez y desde despliegue se pueda generar un fichero desplegable para cada uno de los entornos, conforme la aplicación vaya pasando por éstos.

NOTA: Una misma entrega parametrizable se utilizará para el paso de la aplicación por los 3 entornos. En ningún caso se aceptarán entregas diferentes o con alguna corrección para preproducción o producción.




Pág. 12 de 78



Cualquier cambio en ficheros que no sean de propiedades deberá generar una nueva versión y, por consiguiente, una nueva entrega.

3.1.1.4. Ficheros de propiedades

No deberán tener un formato determinado, pero sí contener las propiedades comunes que queremos utilizar en la aplicación, evitando valores “hardcodeados” dentro de la misma.

Salvo parámetros que el proveedor desconoce y no pueden ser facilitados como accesos o contraseñas a distintas urls de la DGA, todos los demás parámetros de los properties deberán ser informados correctamente en cada fichero según el entorno para el que estén definidos.

3.1.1.5. Scripts de BBDD

NOTA: En todas las entregas se deberá incluir un manual con las instrucciones de ejecución de los scripts, así como las posibles acciones en caso de errores (continuar la ejecución o no, ejecutar scripts de borrado o regresión, etc...).

Los componentes para la instalación o modificación de la base de datos se proporcionarán en scripts SQL que deberán poder ser re-ejecutados, para lo cual se proporcionarán scripts para el borrado de los objetos y/o vaciado de tablas.

Son deseables scripts separados para:

• Creación de tablas

• Creación de claves ajenas (relaciones)

• Creación de índices

• Creación de secuencias

• Creación de vistas

• Creación de triggers

• Creación de paquetes, procedimientos y funciones

• Creación de jobs

• Creación de sinónimos

• Creación de roles

• Concesión de privilegios (Grants)

• Scripts para carga inicial de datos

• Otros




Pág. 13 de 78



NOTA: No se deberán incluir scripts para la creación de usuarios (propietarios de esquemas o no) y tablespaces. Para ellos existen plantillas de solicitud de usuarios/tablespaces.

3.1.1.6. Ficheros estáticos y temporales

Si la aplicación necesita directorios para ubicar ficheros estáticos o temporales, deberá indicarse en el manual de instalación o despliegue de la aplicación.

Deberán configurarse en la ruta “/compartido/app/cod_app/”.

NOTA: Siempre que sea necesario actualizar estos ficheros temporales, deberá indicarse en el Manual de Instalación de la versión correspondiente.

3.1.1.7. Componentes o módulos

La estructura a seguir, según el documento de la guía Blueprints es la que se muestra en el gráfico siguiente:

Los directorios que aparecen en esta estructura tienen que contener los siguientes ficheros:





Pág. 14 de 78




build/ Contendrá el resultado de la ejecución de ANT. Por ejemplo un fichero JAR con las clases empaquetadas, la documentación Javadoc, ficheros de plantillas de generación de pdfs compiladas, etc…

dist/ Contendrá el componente resultado descomprimido. Este directorio es opcional.

docs/ Contendrá toda la documentación relacionada con el componente. Donde se usa, cómo utilizar el componente, que librerías se están utilizando para la compilación del componente, de donde provienen las librerías, etc…

src/ Contendrá los fuentes (directorio java) y los ficheros de configuración (directorio conf) necesarios para la creación del componente. Por ejemplo en el directorio java contendrá los ficheros fuente .java y el directorio conf contendrá los ficheros de configuración del EJB o el fichero MANIFEST.MF que puedan ser editables.

test/ Contendrá los ficheros necesarios para la realización de las pruebas unitarias del componente. Cada prueba unitaria se define en un directorio con su nombre y se incluyen en él todos los ficheros necesarios. Para cada prueba se genera un fichero build.xml independiente y el resultado se deja en el directorio build.

Los ficheros que aparecen en el directorio raíz: build.properties.sample, license.txt y readme.txt son opcionales y se tienen que incluir sólo si se consideran necesarios.

3.1.2. Proyectos web simples

Esta estructura nos sirve para un proyecto en el que sólo generamos un fichero EAR resultado con un único WAR.

La estructura del proyecto es la siguiente:




Pág. 15 de 78



Las únicas novedades que distinguen este tipo de proyectos del anterior es la existencia del directorio “web” donde ubicamos todos los ficheros propios de la aplicación web y del directorio “setup” donde ubicamos los ficheros necesarios para la instalación de la aplicación.


setup/ Contiene los ficheros necesarios para la instalación de la aplicación.

web/ Contiene los ficheros estáticos necesarios para la generación del fichero WAR de aplicación: ficheros JSP, HTML, imágenes, javascript, CSS, etc.

web/WEB -INF/ Contiene ficheros de configuración como web.xml, faces-config.xml, u otros. Normalmente este directorio contiene ficheros que son copiados durante la compilación y no son modificados.

Los ficheros de configuración que tienen que ser modificados para la compilación y generación del resultado deberían ir en el directorio conf/ (por ejemplo un fichero .PROPERTIES con rutas y directorios que definimos a medida para la instalación en una máquina determinada)

web/WEB -INF/lib/

Contendrá las librerías necesarias para la ejecución de la aplicación web.

NOTA: En todo caso el resultado final será un fichero EAR.




Pág. 16 de 78



3.1.3. Proyectos web complejos

Esta estructura se adapta a proyectos más complejos en los que intervengan varios componentes, un WAR, varios EJBs, etc.

La estructura está preparada para incluir:

• Componentes que se reutilizan dentro del proyecto.

• Aplicaciones web J2EE con varios ficheros JAR, WAR dentro de un fichero EAR.

• Varias aplicaciones J2EE o de otro tipo (proceso de línea de comandos que reutiliza alguno de los componentes).

• Cualquier otra configuración compleja.

La estructura de proyecto a seguir es la siguiente:

Las novedades más importantes que podemos ver en esta estructura del proyecto son la existencia de los directorios “apps ” y “components ”. Estos directorios incluyen dentro las distintas aplicaciones y componentes que componen todo el sistema. Si una parte del proyecto se utiliza en




Pág. 17 de 78



varios puntos distintos hay que definir a esa parte como componente. En el caso de que sólo se utilice dentro de una aplicación se puede mantener dentro del directorio propio de la aplicación.

Los directorios más en detalle tienen que contener:


apps/ Contendrá un directorio con el nombre de cada aplicación que estemos creando.

apps/myapp1/ Contendrá un directorio con el nombre de cada componente propio de la aplicación. El nombre de los directorios tiene que determinar directamente que contiene cada uno.

apps/myapp1/build/ Contendrá el fichero EAR generado tras la compilación y ensamblado de toda la aplicación.

apps/myapp1/myapp1 -ejb/ Contendrá todos los ficheros necesarios para generar el EJB llamado myapp1. La estructura interna será igual que si se tratara de un componente.

apps/myapp1/myapp1 -war/

Contendrá todos los ficheros para la generación de un WAR llamado myapp1. La estructura interna será igual que si se tratara de un proyecto web simple.

apps/myapp1/src/conf/ Contendrá los ficheros de configuración para la generación del EAR de la aplicación, por ejemplo APPLICATION.XML y ORIONAPPLICATION. XML

components/ Contendrá un directorio con el nombre de cada componente que estemos creando.

comp onents/comp1/ Contendrá todos los ficheros necesarios para generar el componente COMP1.

3.1.4. Ejemplo de proyecto

En la siguiente URL pueden encontrarse ejemplos de este tipo de proyectos:

http://java.sun.com/j2ee/1.4/download.html#samples

En concreto el proyecto adventure1.0.1 que podemos encontrar dentro de la carpeta blueprints muestra claramente una estructura de proyecto compleja con todos los ficheros necesarios para generar el resultado final.




Pág. 18 de 78



4. Especificaciones del entorno

A continuación se detallan las características de la capa media y de datos, fundamentales para el desarrollo y despliegue de aplicaciones.

4.1. Capa frontal

Esta capa está compuesta de servidores Apache, en los que se configurará el acceso http o https.

Se recuerda que las conexiones están balanceadas por hardware.

Los dominios DNS están definidos de forma que las URL´s de acceso a las aplicaciones sean las siguientes:

Entorno OAS-R2 OAS-R3

Integración http://desservicios.aragon.es/cod_app

https://desservicios.aragon.es/cod_app

http://desservicios3.aragon.es/cod_app

https://desservicios3.aragon.es/cod_app

Preproducción http://preservicios.aragon.es/cod_app

https://preservicios.aragon.es/cod_app

http://preservicios3.aragon.es/cod_app

https://preservicios3.aragon.es/cod_app

Producción http://servicios.aragon.es/cod_app

https://servicios.aragon.es/cod_app

http://servicios3.aragon.es/cod_app

https://servicios3.aragon.es/cod_app

4.2. Capa Media o de Servidor de Aplicaciones

La capa media se encuentra implementada con un Oracle Application Server 10G Release 3 (versión de OC4J para Java 1.5).

NOTA: Todos los desarrollos nuevos deberán ir dirigidos al OAS 10G Release 3 y deberán estar implementados con Java 1.5

Como anotación, indicar que existe también, solamente para aplicaciones ya implementadas con anterioridad, un Oracle Application Server 10G Release 2 (versión de OC4J para Java 1.4), que se describe en el anexo 2 de este documento.

De cara al desarrollador de software, es interesante conocer exactamente qué productos están instalados en la capa media (OC4J) para poder replicar el servidor de aplicaciones en sus instalaciones y así diseñar y probar las aplicaciones en un entorno compatible con el del Gobierno de Aragón.




Pág. 19 de 78



4.2.1. Versiones del producto (Oracle Application S erver Release 3)

El entorno OAS-R3 tiene como base varios servidores físicos (mof-portal1/mof-portal2/…), a partir de los cuales se define un único cluster virtual.

La relación de productos/versiones instaladas es la siguiente:

• Oracle Application Server SOA Suite 10.1.3.1.0

• Oracle Application Server PatchSet 10.1.3.3.0

Con los siguientes parches instalados:

• Oracle patch #6396636

4.2.2. Librerías comunes (OAS-R3)

Con objeto de evitar la sobrecarga de los servidores de aplicaciones, en estos se encuentran instaladas por defecto las librerías más comúnmente utilizadas por las aplicaciones de forma que estas no deberán incluirse en cada entrega.

La lista completa de librerías comunes para el OAS-R3 puede consultarse en el Anexo 3.

En caso de utilizar alguna versión superior de estas librerías será necesario incluirla en la carpeta /lib de la aplicación y definir correctamente los ficheros necesarios dentro de la misma (como el web.xml) para que trabaje con sus clases locales y no con las librerías comunes.

Para más información sobre la carga de clases locales consultar anexo 4 de este documento.

NOTA: Para la utilización de librerías externas tipo Spring, Hibernate, Struts, Axis, etc... es necesario asegurarse de que la versión utilizada es soportada por la versión 1.5 de java.

4.2.3. Librerías compartidas entre varias aplicacio nes (shared)

Con el fin de reducir la carga del servidor, en el caso de grupos/módulos de aplicaciones que utilicen librerías comunes y que no estén integradas en las librerías del servidor, existirá la posibilidad de crear un directorio “shared” dentro del contenedor donde estén desplegadas. Esto deberá ser advertido en el Manual de Instalación, indicando claramente todas las dependencias.




Pág. 20 de 78



4.2.4. Configuración por defecto de una instancia O C4J

Los contenedores OC4J en los que se despliegan las aplicaciones J2EE, se configurarán por defecto con las características mínimas y se irán revisando en función de las necesidades de las aplicaciones que contienen.

Los únicos parámetros que se indican en la creación de un contenedor son los siguientes:

-Djava.security.policy=/oracle/as/oc4j10.1/j2ee/MISC 01/config/java2.policy (descriptor de seguridad del contenedor)

-Djava.awt.headless=true (Para que las aplicaciones que invocan clases que esperan teclado, ratón o display, no fallen. Por ejemplo la creación de elementos gráficos).

En cuanto a las opciones de java, las mínimas serán las siguientes:

-Duser.country=ES

-Duser.language=es

-XX:MaxPermSize=128m

-XX:PermSize=128m

-Xms164m

-Xmx164m

NOTA: Toda necesidad específica de una aplicación en cuanto a la configuración del contenedor, deberá indicarse expresamente en el manual de instalación de la misma.

4.3. Capa de Bases de datos

La capa en la que residen los datos está implementada mediante ORACLE RAC, que integra varias instancias de Base de Datos, con las consideraciones que se indican a continuación.

4.3.1. Balanceo de conexiones de BBDD

Dentro de la arquitectura, se incluye un sistema de balanceo de las conexiones a nivel de base de datos para garantizar Alta Disponibilidad.

El sistema de balanceo de conexiones sigue el algoritmo Aleatorio o round robin, basado en configuración del cliente/servidor de aplicaciones.




Pág. 21 de 78



El balanceo se realiza así desde el cliente, modificando la URL de conexión del JDBC o la entrada del TNSNAMES.ORA.

4.3.2. Configuración de BBDD (concurrencia de sesio nes)

Los datos de configuración de las diferentes instancias de base de datos, en relación al máximo de sentencias y cursores soportados, son los siguientes:

Para ampliar información sobre los profiles de Base de Datos existentes y los parámetros de globalización, se puede consultar los anexos 5 y 6 de este documento.

4.3.3. Formato del datasource para los OAS-R3

El datasource u origen de datos que utilizan las aplicaciones para conectar con la BBDD deberá tener el siguiente formato:

<?xml version="1.0" standalone='yes'?>

<data-sources xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://xmlns.oracle.com/oracleas/schema/data-sources-10_1.xsd" schema-major-version="10" schema-minor-version="1" >

<connection-pool name="Pool de Oracle para Qmatic"> <connection-factory factory-class="oracle.jdbc.pool.OracleDataSource" user=""

NOMBRE PROAPP0 PROAPP1

sessions 2205 2755

processes 2000 2500




Pág. 22 de 78



password="" url="jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=backdes1.dga.es)(PORT=1523))(CONNECT_DATA=(SERVICE_NAME=desapp1.dga.es)))"> </connection-factory> </connection-pool> <managed-data-source name="jdbc/WebIntraDS" connection-pool-name="Pool de Oracle para Qmatic" jndi-name="jdbc/WebIntraDS"/>

</data-sources>

En función del entorno y de la instancia de base de datos los valores de la propiedad URL serán los siguientes:

Entorno Instancia de BBDD URL

Integración DESAPP0 url="jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=backdes1.dga.es)(PORT=1522))(CONNECT_DATA=(SERVICE_NAME=desapp0.dga.es)))">

DESAPP1 url="jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=backdes1.dga.es)(PORT=1523))(CONNECT_DATA=(SERVICE_NAME=desapp1.dga.es)))">

Preprod ucción PREAPP0 url="jdbc:oracle:thin:@(DESCRIPTION=(LOAD_BALANCE=on)(ADDRESS=(PROTOCOL=TCP)(HOST=vir_backpre1.dga.es)(PORT=1522))(ADDRESS=(PROTOCOL=TCP)(HOST=vir_backpre2.dga.es)(PORT=1522))(CONNECT_DATA=(SERVICE_NAME=preapp0.dga.es)))">

PREAPP1 url="jdbc:oracle:thin:@(DESCRIPTION=(LOAD_BALANCE=on)(ADDRESS=(PROTOCOL=TCP)(HOST=vir_backpre1.dga.es)(PORT=1522))(ADDRESS=(PROTOCOL=TCP)(HOST=vir_backpre2.dga.es)(PORT=1523))(CONNECT_DATA=(SERVICE_NAME=preapp1.dga.es)))">

Producción PROAPP0 url="jdbc:oracle:thin:@(DESCRIPTION=(LOAD_BALANCE=on)(ADDRESS=(PROTOCOL=TCP)(HOST=vir_backpro1.dga.es)(PORT=1522))(ADDRESS=(PROTOCOL=TCP)(HOST=vir_backpro2.dga.es)(PORT=1522))(CONNECT_DATA=(SERVICE_NAME=proapp0.dga.es)))">

PROAPP1 url="jdbc:oracle:thin:@(DESCRIPTION=(LOAD_BALANCE=on)(ADDRESS=(PROTOCOL=TCP)(HOST=vir_backpro1.dga.es)(PORT=1522))(ADDRESS=(PROTOCOL=TCP)(HOST=vir_backpro2.dga.es)(PORT=1523))(CONNECT_DATA=(SERVICE_NAME=proapp1.dga.es)))">




Pág. 23 de 78



5. Especificaciones de desarrollo

Previamente al desarrollo de una nueva aplicación deberá asegurarse de que se está en posesión de la última versión disponible del documento de especificaciones.

5.1. Código de Aplicación

Toda aplicación desplegada en los servidores del Gobierno de Aragón, debe estar registrada en la base de datos de “Gestión de la configuración” (CMDB). Por ello, es necesario que el código de aplicación sea único y el nombre suficientemente descriptivo para poder identificarla.

El código será alfanumérico, preferiblemente de 3 o 4 caracteres y, generalmente, estará formado por las iniciales del nombre de la aplicación. Será acordado entre la empresa desarrolladora y el grupo de desplieguej2ee al comienzo del proyecto. Para más información sobre cómo solicitar el código, puede consultarse el punto 6.1.1 de este documento.

5.2. Versión de la aplicación

En la página inicial de la aplicación, deberá hacerse referencia, a modo informativo, a la versión correspondiente de la misma.

5.3. Nomenclatura de paquetes y clases Java

Los nombres de los paquetes Java incluidos en la aplicación, se definirán según la siguiente estructura:

es.aragon.codigo_aplicacion

Así, por ejemplo, son nombres válidos de paquetes:

• es.aragon.codigo_aplicacion.dal : paquete de clases de acceso a datos almacenados en distintas fuentes de datos, como bases de datos, ficheros, directorios LDAP, etc.

• es.aragon.codigo_aplicacion.bl: paquete de clases que implementan la lógica de negocio de la aplicación.

• es.aragon.codigo_aplicacion.servlet: paquete que contiene las clases correspondientes a los servlets del aplicativo.

• es.aragon.codigo_aplicacion.util: paquete de utilidades genéricas de la aplicación.




Pág. 24 de 78



5.4. Gestión de excepciones

Con el fin de corregir posibles errores o determinar las causas de los mismos, es necesario realizar una correcta gestión de las excepciones de la aplicación.

Para ello se deberán crear las excepciones que se crean convenientes según cada aplicación para capturar los posibles errores y mostrar tanto por pantalla como en los logs de la aplicación errores claros y concisos.

También es recomendable, en el caso de que la aplicación contenga webservices que vayan a ser consumidos por terceros, incluir un pequeño resumen donde se muestre una relación entre los códigos de error y un texto descriptivo de los posibles errores (Catálogo de errores), para que los clientes de dichos webservices tengan la información necesaria para desarrollar.

5.5. Versión del JDK

Todas las aplicaciones de nuevo desarrollo deberán estar preparadas para compilarse utilizando la JDK 1.5.

Para las aplicaciones desarrolladas con anterioridad a este documento, se permitirá utilizar la JDK 1.4.

5.6. Uso de nuevos frameworks

Se permitirá el uso de cualquier framework que cumpla las siguientes condiciones:

• Deberá ser compatible con la versión 1.5 de java.

• En los casos particulares de JSF, Ajax o DWR que trabajan con la capa de presentación web, la aplicación deberá ser accesible con nivel AA.

• En el caso de Axis, sólo se permitirá Axis2.

5.7. Interoperabilidad

Para la realización de webservices, deberán cumplirse las especificaciones marcadas en el documento “AST-ESPEC-InteroperabilidadTecnicaWS.pdf”.

5.8. Utilización de plataformas horizontales

El Gobierno de Aragón dispone de servicios horizontales de uso común.

Para la integración con estos servicios, se requiere solicitud previa a AST a través del gestor de la aplicación o de la lista de soporte correspondiente. De la misma forma puede solicitarse también documentación relativa a la integración.

Las plataformas comunes existentes son:




Pág. 25 de 78



• Firma electrónica

• Pasarela de pago

• Gestor documental

• SMS

• Multicanalidad

• SOA

• Servicios de autenticación (SAU y Autoregistro), explicados más adelante.

Para más información consultar los anexos 7 al 10 de este documento.

El uso de estas plataformas deberá indicarse claramente en el manual de instalación de la aplicación.

5.9. Herramientas necesarias para desarrollos J2EE

Para unificar criterios de desarrollo y facilitar el despliegue de la aplicación, deberán utilizarse las herramientas que se definen a continuación.

5.9.1. Herramienta ANT

Utilizada para automatizar las tareas de compilación, empaquetado, distribución de proyectos, etc.

Las aplicaciones se entregarán preparadas para compilar con la herramienta ant , incluyendo en la entrega el fichero build.xml correspondiente.

NOTA: Sólo se permite la utilización de versiones de ANT iguales o inferiores a la 1.7.

La llamada a la herramienta ANT para compilar incluirá el valor adecuado para esta propiedad

ant –Doc4j.lib=/path/to/lib/

Existe información ampliada sobre la herramienta ant en el anexo 5 de este documento

5.9.2. JDK

Las herramientas que se utilizan para la compilación (javac), empaquetado (jar) y generación de documentación (javadoc) del proyecto están incluidas dentro de los kits de desarrollo SDKs de SUN disponibles para la versión 1.5.0:

JDK 1.5: http://www.oracle.com/technetwork/java/javase/index-136769.html




Pág. 26 de 78



5.9.3. Log4j

Toda aplicación deberá utilizar un sistema de log que escriba en disco los mensajes, generando un fichero por día (rolling diario). De esta forma, se tendrá un histórico del log almacenado en ficheros ordenados por día para que, en caso de ser solicitados, los ficheros se puedan enviar fácilmente al proveedor. Se utilizará obligatoriamente el sistema Log4j .

NOTA: La librería Log4j se encuentra instalada en los servidores de aplicaciones (versión 1.2.8) por lo que no deberá ser incluida en cada aplicación, a menos que se desee utilizar una versión superior de la misma, lo cual deberá ser indicado claramente en el Manual de Instalación de la aplicación.

La aplicación deberá configurarse obligatoriamente para que deje los logs en la ruta “/logs/app/codigo_aplicacion”.

Del mismo modo, se deberá configurar el nivel de log deseado (DEBUG, INFO, WARN, ERROR, FATAL) acorde con el entorno (integración, preproducción y producción).

• En integración se permitirá cualquier nivel de log.

• En preproducción se permitirá hasta DEBUG.

• En producción no estará permitido el nivel DEBUG, el máximo nivel permitido será ERROR.

NOTA: No están permitidos, en ningún entorno, los logs de librerías genéricas como Apache, Struts, Spring, Hibernate o Axis.

Para más información sobre la configuración de log4j y niveles de log que pueden utilizarse, consultar el anexo 12 de este documento.

NOTA: En los logs de aplicación no está permitido dejar datos restringidos, como IPs de máquinas, nombres de usuario, etc.

5.10. Gestión de usuarios

En referencia a la gestión de usuarios, distinguiremos entre usuarios de base de aplicación y usuarios de base de datos.

5.10.1. Usuarios de aplicación

Para la autenticación/autorización de usuarios en las aplicaciones, alternativamente a la implementación de un sistema propio de gestión de usuarios, existen varias soluciones con las que podrá integrarse:

• LDAP: Todo empleado del Gobierno de Aragón dispone de una cuenta en el directorio LDAP corporativo. Su utilización se describe en el Anexo 13 de este documento.

• Autoregistro: Adecuado para escenarios de usuarios externos (ciudadanos/empresas). Sus funciones se describen en el Anexo 10 de este documento.




Pág. 27 de 78



• SAU (Sistema de Autenticación de Usuarios) : Sistema que implementa Single Sign On para gestión de usuarios/aplicaciones. Sus funciones se describen en el Anexo 9 de este documento.

NOTA: La utilización de estas plataformas deberá solicitarse previamente a AST a través del gestor de la aplicación e indicarse claramente en el Manual de Instalación de la aplicación.

5.10.2. Usuarios de Base de Datos

A nivel de base de datos, se deberá diferenciar entre el usuario propietario del esquema de base de datos y el usuario/usuarios de conexión de la aplicación.

El usuario propietario del esquema será nombrado con el código de aplicación, y solo se utilizara para acciones de definición (DDL) del esquema y nunca como usuario de aplicación. Este usuario no será proporcionado al cliente.

Las aplicaciones deberán conectar a BBDD con otro usuario solicitado para tal efecto, al que le se asignará el rol correspondiente en función de las necesidades de la aplicación. Será nombrado con el código de aplicación seguido de “USER” (APP_USER). Es el usuario con el que conectará el datasource de la aplicación.

Para la creación de estos usuarios deberá cumplimentarse el formulario correspondiente, que podrá descargarse desde la web de la entidad.

5.11. Definición/Creación de Base de Datos

Para información sobre esquemas, usuarios, etc... consulte el documento completo “AST-ESPEC-BaseDatosOracle10g.pdf” .

5.12. Indicaciones sobre Accesibilidad

Las directrices de estilo, accesibilidad y usabilidad que deben cumplir todas las aplicaciones , independientemente de su público objetivo, vienen especificadas en la “Guía de Estilos del Portal de Internet del Gobierno de Aragón” (AST-ESPEC-GuiaEstilosPortalInternet.pdf).

Toda aplicación que se despliegue en los servidores del Gobierno de Aragón, a excepción de los componentes de firma electrónica, deberá cumplir con el Nivel de accesibilidad AA definido por el estándar w3c.

Como paso previo a la subida de la aplicación a producción, el grupo de despliegue comprobará la Accesibilidad de la versión de preproducción, para lo cual se utilizarán las siguientes herramientas:

� HTML Validator. Deberá superar el test con el algoritmo SGML Parser.

� TAW3 (AA).

NOTA: Toda excepción a estas normas deberá estar autorizada por el Gestor de la aplicación en AST.




Pág. 28 de 78






Pág. 29 de 78



6. Especificaciones de despliegue

Es el proceso mediante el cual una aplicación es instalada en el servidor de aplicaciones y queda accesible desde una URL determinada.

6.1. Proceso de alta de un nuevo proyecto

Cada vez que se comience a desarrollar un nuevo proyecto, además de las especificaciones de desarrollo, deberán tenerse en cuenta las indicaciones siguientes para su posterior despliegue.

6.1.1. Solicitud de alta del CI

Siguiendo la metodología ITIL, previamente al despliegue de la primera versión en el entorno de integración, la aplicación deberá darse de alta como elemento de configuración en la CMDB. Este paso se realizará mediante un mensaje a la lista de [email protected] con el siguiente asunto:

[COD_APP] Otros Solicitud código aplicación

Se deberán proporcionar los siguientes datos básicos:

• Código de aplicación propuesto

• Título

• Descripción

• Responsable funcional

• Responsable técnico

• Peticionario principal

• Departamento

• Tecnología

Sobre el código de aplicación, el proveedor propondrá una opción, que deberá ser confirmada desde el grupo de despliegue. Una vez recibida la petición, desde despliegue se comprobará, consultando la CMDB, que ese código no pertenece a ninguna aplicación anterior y se comunicará al usuario si puede utilizarlo o no para su desarrollo.

NOTA: Ya que el código de aplicación deberá usarse en algunos elementos de la misma como la nomenclatura del tablespace, se recomienda consultar este dato antes de comenzar el desarrollo.




Pág. 30 de 78



6.1.2. Información específica a detallar

NOTA: Toda esta información deberá detallarse, como se ha indicado anteriormente, en el manual de instalación/despliegue de la aplicación.

6.1.2.1. Descripción general de la aplicación

• Introducción a la aplicación, cuál es su objetivo, a qué público atiende, si responde a una normativa legal determinada, si su uso es continuo o en determinados periodos, volumen de usuarios esperados, horario de funcionamiento, requerimientos especiales de seguridad (como acceso mediante HTTPS), etc.

• Es necesario indicar si utiliza plataformas comunes como Firma, Pasarela de Pagos o el gestor documental y especificar que volumen de usuarios, periodos de tiempo, acciones a realizar, tamaño documentos a tratar, etc.

Todos estos datos serán evaluados y, en caso de un volumen de trabajo alto, será necesario aportar un plan de pruebas para evitar problemas de rendimiento de la aplicación una vez desplegada en producción y así evitar que afecte a las aplicaciones con las que comparta servidor.

6.1.2.2. Requisitos del aplicativo

Se detallarán las necesidades hardware y software del aplicativo, incluyendo entre otros los siguientes datos:

• Hardware: capacidad de disco necesaria (base de datos u otras fuentes de datos, otros ficheros de aplicación, ficheros temporales, ficheros de log), previsión de crecimiento, y otros requisitos particulares.

• Software: librerías específicas (no estándar del servidor) utilizadas por la aplicación, incluyendo la versión de las mismas.

6.1.2.3. Descripción del modelo de datos

Se describirán las fuentes de datos utilizadas por la aplicación, como el modelo relacional de la base de datos.

Para otro tipo de fuentes de datos (ficheros, directorio LDAP), se utilizará el formato que se considere más adecuado para su descripción.

6.1.2.4. Arquitectura de aplicación

Se describirá la arquitectura en componentes de la aplicación, y las relaciones entre ellos.

6.1.2.5. Fuentes Java

Se documentará adecuadamente los ficheros fuentes Java en el formato de la herramienta Javadoc. La documentación incluirá la descripción de todas las clases y métodos.




Pág. 31 de 78



NOTA: Se puede encontrar más información sobre la herramienta Javadoc y su utilización en la página http://java.sun.com/j2se/javadoc/writingdoccomments / “How to Write Doc Comments for the Javadoc Tool”.

6.1.2.6. Errores de aplicación

Se realizará una descripción de los posibles errores que se produzcan en la aplicación, incluyendo para cada uno su código de error, texto descriptivo y la actuación necesaria para su corrección, en caso de producirse.

La pantalla de error que se muestre al usuario deberá ser suficientemente descriptiva del error para permitir su identificación, mostrando su código y texto descriptivo, de forma que facilite la identificación de las posibles incidencias.

6.1.2.7. Plan de pruebas

En caso de que la aplicación tenga prevista un alto número de accesos, será necesario aportar un plan de pruebas de la aplicación: pruebas funcionales, de carga y de alta disponibilidad.

6.1.2.8. Manual de usuario

Se entregará, con cada versión de la aplicación, el manual de usuario detallado de la misma actualizado a dicha versión.

6.1.2.9. Manual de explotación

En el caso de que la aplicación requiera tareas de administración técnica.

6.2. Entornos de despliegue disponibles

El despliegue de aplicaciones J2EE se realiza en la capa media o de Servidor de Aplicaciones.

En esta capa, se encuentra el Servidor de aplicaciones Oracle Application Server 10g Release 3 (10.1.3.1).

La descripción detallada del OAS-R3 puede consultarse en el punto 4.2 de este documento.

6.3. Proceso de despliegue de un proyecto

6.3.1. Métodos de entrega

La entrega de una aplicación para su despliegue podrá realizarse mediante dispositivo físico, adjunta al email de la petición de despliegue o bien mediante un FTP que el cliente habilite para tal efecto, proporcionando en la propia petición de despliegue los datos de acceso al mismo.

El desarrollador podrá elegir el método qué más convenga a sus necesidades.




Pág. 32 de 78



6.3.2. Proceso de despliegue

Una vez que el proveedor realiza la solicitud de despliegue y el grupo de despliegue recibe la entrega, se realizarán los siguientes pasos:

- Verificación de la aplicación: Se comprobará que la aplicación cumple con las especificaciones detalladas tanto en este documento como en “AST-ESPEC-EspecificacionesTecnicasJ2EE.doc”. En caso de que no las cumpla, se rechazará el envío.

- Configuración de los ficheros parametrizables: Se configurarán los ficheros parametrizables por entorno (datasources, properties, etc), que se hayan indicado en el manual de instalación.

- Compilación de la aplicación: Se compilará la aplicación utilizando la herramienta ant según se ha indicado en las especificaciones y utilizando la lista de librerías comunes del entorno.

ant –Dentorno= des -Doc4j.lib=”/path/to/lib/”

Para ampliar información sobre la generación del archivo .ear consultar el anexo 14.

- Planificación del despliegue: Se planificará el despliegue, por lo general, en la siguiente ventana establecida para el entorno correspondiente y se comunicará al usuario la fecha y hora planificada.

- Despliegue de la aplicación: Se desplegará la aplicación en el servidor de aplicaciones. El propio proceso de despliegue y desempaquetado, se puede hacer de 2 formas diferentes: por consola administrativa o bien por línea de comandos.

La consola administrativa cuenta con un asistente que guía al técnico en el proceso de subida del fichero, desempaquetado y despliegue en el servidor.

Para ampliar información sobre el despliegue por línea de comandos, se recomienda consultar el anexo 15 de este documento.

Además hay 2 anexos más, que aportan información sobre ciertos aspectos del despliegue de aplicaciones:

Plan de despliegue: Se trata de un fichero en el que ya van configuradas las opciones de despliegue de una aplicación. Se suele utilizar para un redespliegue o bien para guardar configuraciones de un despliegue complicado. Más información sobre el uso de un plan de despliegue en los OAS en el anexo 16.

Carga de clases locales: Otra opción configurable en el proceso de despliegue es la forma en que la aplicación y el servidor manejan la carga de clases. Existe información detallada sobre la carga de clases locales en los OAS en el anexo 4.

- Configuración acceso: Se configurará el servidor para el acceso por seguro o no seguro, según indique el manual de instalación.

- Pruebas: Se comprobará la carga de la URL principal de la aplicación.

- Comunicación al usuario: Se comunicará al usuario el resultado del despliegue. En caso de que este no pudiera realizarse por problemas técnicos se replanificará para la siguiente ventana de despliegue y se transmitirá esta información al usuario.




Pág. 33 de 78



6.4. Tipos de despliegue

Dentro de la gestión del servicio, AST sigue la metodología ITIL, que implica una serie de prácticas en la gestión de cambios. Una de ellas, como método de control y seguridad para las subidas a producción, supone que toda aplicación nueva o subida de versión que incluya un cambio importante en su funcionalidad, deberá estar aprobada por un Comité de Cambios.

Este Comité de Cambios se reúne una vez por semana tratando todas las peticiones de cambios de la semana anterior, con lo que este plazo deberá ser tenido en cuenta por el desarrollador a la hora de planificar una subida a producción. De esta forma, se pretende evitar actuaciones de emergencia, que por definición son no planificadas, por el riesgo que implican para el entorno.

6.4.1. Despliegues Normales

Se trata de despliegues de aplicaciones con modificaciones “importantes” (aplicaciones nuevas, inclusión de nuevos módulos en una aplicación existente, integración con alguna plataforma común, etc).

Se corresponden con modificaciones en el primer dígito de la versión , según los criterios de versionado expuestos en este documento.

Serán revisados en la reunión del Comité de Cambios de la semana siguiente a la recepción de la petición y, en caso de ser aprobado su despliegue, se realizaría en la siguiente ventana de despliegue establecida.

6.4.2. Despliegues Predefinidos

Se corresponden con modificaciones de segundo y tercer nivel de versionado . Se realizarán, en la medida de lo posible, en la siguiente ventana de despliegue después de la recepción de la petición.

6.4.3. Despliegues de urgencia

Un despliegue de urgencia se sale de toda planificación y deberá estar debidamente justificado para poder ser autorizado.

NOTA: Será imprescindible indicar los motivos de la urgencia en la petición de despliegue. Toda petición sin justificar será rechazada.




Pág. 34 de 78



Todos aquellos despliegues no programados (urgencia) que requieran una actuación fuera de estas ventanas deberán ser autorizados por el Director de Infraestructuras.

6.4.4. Despliegue de “productos”

Llamamos productos a aquellas aplicaciones que no han sido desarrolladas “a medida” y que no cumplen en su totalidad las especificaciones de entrega detalladas en este documento y en “AST-ESPEC-EspecificacionesTecnicasJ2EE.doc”.

Para que una aplicación sea tratada como “producto”, deberá estar autorizado por el gestor de la misma dentro de Aragonesa de Servicios Telemáticos.

NOTA: Se limitarán las comprobaciones previas desde el grupo de despliegue en las partes en las que no se ajuste a las especificaciones, pero se deberán respetar los plazos establecidos en función del tipo de despliegue.

6.5. Política de versionado

Cada entrega de una aplicación deberá ir adecuadamente versionada, incluyendo información sobre los cambios que motivan la nueva versión. La versión se especificará, además, obligatoriamente en el archivo MANIFEST.MF del fichero EAR generado.

Tanto al desplegar una aplicación en un entorno determinado, como al distribuir una librería para su uso propio o por terceros, es obligatorio añadir su información de versión.

Esto se puede hacer incluyendo las entradas adecuadas en el fichero MANIFEST.MF que se encuentra en el directorio META-INF del fichero ear (en el caso de una aplicación) o jar (en el caso de una librería).

Se indicarán, al menos, las siguientes entradas:

• Implementation-Vendor: empresa desarrolladora.

• Implementation-Version: valor de la versión de la aplicación o librería distribuida.

Implementation-Vendor: Aragonesa de Servicios Telematicos Implementation-Version: 2.0

NOTA: Es necesario incluir la tercera línea en blanco para que coja las dos propiedades.

El número de versión de la aplicación debe indicarse claramente en la página inicial de la misma.

6.5.1. Criterios de versionado

El versionado se define en base a tres niveles X.Y.Z que se explican a continuación:




Pág. 35 de 78



6.5.1.1. Primer nivel X

El primer nivel X define versiones mayores , lo que corresponde a una línea base en terminología de gestión de requisitos.

La versión 0.a.b corresponde a las versiones de un programa que no incorporan toda la funcionalidad definida para la línea base.

La versión 1.0.0 corresponde a la primera versión estable y completa de un programa que incorpora todas las funcionalidades definidas en el análisis.

La versión 2.0.0 corresponde a la versión 2 de un proyecto que se ha reestructurado completamente.

6.5.1.2. Segundo nivel Y

El segundo nivel Y define versiones menores , como modificación de algún requisito que implica cambios menores en un programa.

La versión 1.0.0 corresponde a la primera versión estable y completa de un programa que incorpora todas las funcionalidades definidas en el análisis.

La versión 1.1.0 corresponde con un cambio de un requisito pedido por el cliente y que cambia el planteamiento inicial. Sucesivos cambios irían incrementando este valor Y.

6.5.1.3. Tercer nivel Z

El tercer nivel Z define modificaciones muy pequeñas como corrección de bugs en desarrollos.

Una corrección simple en un programa puede hacer que pasemos de la versión 1.2.12 a la versión 1.2.13.

NOTA: Toda petición de despliegue de una aplicación que no esté correctamente versionada según estos criterios, podrá ser rechazada por el grupo de despliegue.

Para ello se comparará el número de versión con la relación de cambios que incorpora la aplicación, parte de la documentación obligatoria en las entregas.

6.6. Formato de las peticiones de despliegue

NOTA: Toda petición de despliegue de una aplicación J2EE en los servidores del Gobierno de Aragón deberá realizarse mediante mensaje a la lista de despliegue ([email protected]).

La única excepción son las aplicaciones que van destinadas al entorno JBOSS, que deberán solicitarse mediante petición de servicio a través del Help Desk ([email protected]).

Todos los correos remitidos a cualquier lista de despliegue, deberán tener necesariamente el siguiente formato en el asunto del mensaje:

[CodApp versión entorno] Asunto




Pág. 36 de 78



dónde:

• CodApp: código identificativo de la aplicación, tal como figura en el inventario de Aragonesa de Servicios Telemáticos (CMDB).

• Versión: versión de la aplicación a que se refiere el envío. Deberá tener el formato vx.y.z según las condiciones que se describen en el punto 5.1 de este documento.

• Entorno: codificación del entorno al que se refiere la petición (lista de posibles entornos detallada en el punto 7.1 de este documento).

• Asunto: únicamente una de estas tres opciones: Despliegue, Logs, Otros.

Unos ejemplos de peticiones relacionadas con la aplicación “TEST” serían:

[TEST v2.1.3 des] Despliegue

[TEST v1.0.1 pro] Despliegue

[TEST v2.1.3 pre] Logs

[TEST v1.0.1 pro] Logs

[TEST v1.0.1 pro] Otros

NOTA: Cualquier mensaje que no cumpla este formato será devuelto a su remitente.

NOTA: Los peticionarios, por motivos de seguridad, deben comprometerse a destruir los logs a las 24 horas de la recepción de los mismos.

6.6.1. Lista de posibles entornos

Actualmente existen los siguientes posibles entornos de desplieguej2ee:

Servidor Entorno Descripción

Servidor de aplicaciones OAS 10G (tanto Release 2 como Release 3)

des desservicios

pre preservicios

pro servicios

Portal del empleado des_pe Integración portal del empleado

pro_pe producción portal del empleado

NOTA: En caso de duda, se puede contactar con la correspondiente cuenta de despliegue




Pág. 37 de 78



6.6.2. Flujo de peticiones/incidencias

6.7. Ventanas de despliegue

Todos los despliegues de aplicaciones en los servidores del Gobierno de Aragón, deberán realizarse en unas ventanas concretas de trabajo, definidas de la siguiente forma en función del entorno:

• Producción : lunes y jueves a partir de las 16:00 h y como máximo hasta las 20:00. Para todos aquellos despliegues que por su complejidad no pudieran ser asumidos en estas ventanas, se realizaran fuera de horas (sábado y domingo), previa autorización.

• Preproducción : de lunes a jueves a partir de las 16:00 h y como máximo hasta las 20:00.

• Desarrollo : Todos los días a cualquier hora entre las 8:00 y las 20:00.

Además, se tendrán en cuenta estas indicaciones:

NOTA: Toda versión de una aplicación deberá pasar obligatoriamente por los 3 entornos.

El mecanismo de comunicación para cualquier despliegue de Servicios J2EE será la siguiente dirección de correo electrónico: [email protected].




Pág. 38 de 78



En el momento en que se procese la petición, el grupo de despliegue le indicará al peticionario fecha y ventana planificada para su despliegue y le mantendrá informado del estado del mismo.




Pág. 39 de 78



7. Referencias

7.1. Documentación previa existente en AST

• AST-ESPEC-EntregaAplicacionesJ2EE.pdf

Autor: AST

Fecha: 27/11/2007

• AST-ESPEC-GuiaEstilosPortalInternet.pdf

Autor: AST

Fecha: 19/08/2008

• AST-ESPEC-EspecificacionesTecnicasJ2EE.pdf

Autor: Natividad Porta

Fecha: 11/05/2009

• AST-ESPEC-InteroperabilidadTecnicaWS.pdf

Autor: AST

Fecha: 12/05/2009

• AST-NTEC-VersionadoAplicacionesJ2EE.pdf

Autor: AST

Fecha: 27/11/2007

• AST-ESPEC-EntregaAplicacionesJ2EE.pdf

Autor: AST

Fecha: 27/11/2007

• AST-TEC-PeticionesDespliegue.pdf

Autor: AMS

Fecha: 26/03/2010

• AST-NTEC-ParametrizarEntornosAnt.pdf

Autor: AST




Pág. 40 de 78



Fecha: 27/11/2007

• AST-NTEC-ParametrizarEntornosAnt.pdf

Autor: AST

Fecha: 27/11/2007

• AST-ESPEC-GuiaEstilosPortalInternet.pdf

Autor: AST

Fecha: 19/08/2008

7.2. Otras referencias

• “Oracle® Containers for J2EE Deployment Guide 10g R elease 3 (10.1.3)” http://download.oracle.com/docs/cd/B25221_04/web.1013/b14431/toc.htm




Pág. 41 de 78



ANEXO 1: Relación de máquinas y versiones instalada s (Producción)

Esta es una relación de los productos instalados en cada capa en el entorno de producción:

DESCRIPCIÓN Componente (arquitectura)

INFRAESTRUCTURA TÈCNICA UTILIZADA

Sistema Versión Descripción detallada

Frontend Oracle Web

Cache fof-portal3 / fof-portal4 10.1.4.0.1


Infrastructure 10g

Capa Media

Oracle Application

Server

mol-oas3 / mol-oas4 10.1.2.0.2


10.1.3.1.0 Oracle Application Server SOA Suite

mol-oas5 / mol-oas6 10.1.2.0.2 Oracle Application Server 10g


Server 10g


Server 10g mol-oas11 / mol-

oas12 10.1.2.0.2


Single Sign On

mol-portal1 / mol-portal2



Oracle Internet

Directory

mof-portal3 / mof-portal4 10.1.4.0.1


Infrastructure 10g

Backend Oracle Real Application

bof-portal1 / bof-portal2

10.1.2 RAC

A continuación se muestran los datos de cada máquina:

• Frontales:

FOF-PORTAL1/FOF-PORTAL2

Tipo de Sistema Sun Blade x6250 Fabricante Sun Microsystems

Sistema operativo Solaris 10 11/06 Memory size 32 GB Procesador 2 x INTEL Xeon QuadCore




Pág. 42 de 78



• Capa media:

MOF-PORTAL1 / MOF-PORTAL2

Tipo de Sistema Sun Blade T6320 Fabricante Sun Microsystems

Sistema operativo Solaris 10 10/08 s10s_u6wos_07b SPARC Versión de kernel SunOS 5.10 Generic_138888-03

Distribución de Solaris Entire Distribution Plus OEM Support (SUNWCXall) Dominio aragon.local

Procesador 1x SPARC T2+ Memoria 32640 Megabytes

Nivel de Parcheado EIS-DVD Versión 3.1.17

• Capa de datos:

BOF-PORTAL1/BOF -PORTAL2

Tipo de Sistema Sun Enterprise M5000 Fabricante Sun Microsystems

Sistema operativo Solaris 10 11/06 Memory size 64 GB Procesador 2X Sparc VII

Otros Oracle RAC IDM




Pág. 43 de 78



ANEXO 2: Oracle Application Server Release 2

En el entorno OAS-R2 existen 2 servidores físicos (mof-portal1/mof-portal2), en los que están configurados 8 nodos virtuales (mol-oas3/mol-oas10) formando 4 clusters, garantizando así alta disponibilidad.

Existen 2 nodos virtuales más (mol-oas11/ol-oas12) que a día de hoy no están clusterizados y no se utilizan para despliegue de aplicaciones.

La configuración de los clusters está parametrizada según Departamentos del Gobierno de Aragón, para intentar agrupar las aplicaciones por estos criterios.

• AGMA – Agricultura y Medio Ambiente

• SA – Salud e Industria.

• EC – Economía y Educación.

• MISC – Varios.

Dentro de cada cluster, existen varios contenedores OC4J para el despliegue de aplicaciones.

La relación de productos/versiones instaladas es la siguiente:

• Oracle Application Server 10g 10.1.2.0.2

• Oracle Application Server and Developer Suite 10g Rel 2 Software Update 10.1.2.2.0

• Oracle Application Server and Developer Suite 10g Rel 2 Software Update 10.1.2.2.1

Se han instalado los siguientes parches:



En este entorno se dará soporte únicamente para desarrollos desplegados anteriormente a la realización de este documento. Todo nuevo desarrollo deberá ir dirigido al OAS-R3.




Pág. 44 de 78



ANEXO 3: Librerías OAS-R3

Las librerías comunes instaladas en el Servidor de Aplicaciones (OAS-R3) son las siguientes:

� 45.423 activation.jar

� 485 admin.jar

� 515.957 bcel.jar

� 1.426.297 classes111.jar

� 1.440.343 classes111.zip

� 1.442.470 classes12.jar

� 1.454.520 classes12.zip

� 1.450.065 classes12dms.jar

� 37.377 classgen.jar

� 18.015 connector.jar

� 58.179 cos.jar

� 206.326 crimson.jar

� 19.550 dga-common.jar

� 9.877 dga-login.jar

� 540.540 dms.jar

� 6.634 dmsEmd.jar

� 1.453.811 dsv2.jar

� 12.859 ejb.jar

� 1.989.175 emSDK.jar

� 235.575 http_client.jar

� 1.289.884 iiop.jar

� 37.302 iiop_gen_bin.jar

� 144.049 iiop_rmic.jar

� 104.232 jaas.jar

� 13.629 javax77.jar




Pág. 45 de 78



� 31.860 javax88.jar

� 391.057 jaxen.jar

� 28.441 jaxp.jar

� 274.560 jazn.jar

� 673.123 jazncore.jar

� 13.136 jaznplugin.jar

� 11.358 jcert.jar

� 6.764 jdbc.jar

� 425.090 jem.jar

� 27.761 jms.jar

� 38.479 jmxgrinder.jar

� 353.586 jmxri.jar

� 102.431 jmxtools.jar

� 98.533 jndi.jar

� 5.867 jnet.jar

� 512.672 jsse.jar

� 8.711 jta.jar

� 389 loadbalancer.jar

� 352.668 log4j.jar

� 281.021 mail.jar

� 1.783.219 nls_charset11.jar

� 1.812.830 nls_charset11.zip

� 5.110.629 nls_charset12.jar

� 5.812.258 oc4j.jar

� 1.262.037 oc4jclient.jar

� 4.035 oc4j_interop.jar

� 55.434 ocrs12.jar

� 53.836 ocrs12.zip




Pág. 46 de 78



� 1.378.359 ojdbc14.jar

� 1.385.777 ojdbc14dms.jar

� 1.730.821 ojdbc14dms_g.jar

� 1.722.772 ojdbc14_g.jar

� 687.601 ojsp.jar

� 566 ojspc.jar

� 461.253 ojsputil.jar

� 173.976 oraclexsql.jar

� 5.110.629 orai18n.jar

� 105.864 ordjsptag.jar

� 4.462 osso.jar

� 29.871 regexp.jar

� 471 rmic.jar

� 53.426 servlet.jar

� 369.950 standard.jar

� 13.911 template.jar

� 1.390.642 vbjorb.jar

� 401.071 wfjlib.jar

� 559.775 xml.jar

� 10.034 xmlcomp2.jar

� 491.891 xmlmesg.jar

� 903.389 xmlparserv2.jar

� 124.926 xschema.jar

� 3.064 xsqlserializers.jar

� 24.662 xssapi.jar

� 194.368 xsu12.jar




Pág. 47 de 78



ANEXO 4: Consideraciones sobre carga de clases loca les

Carga de clases locales en los OAS-R2

En el OAS-R2, a diferencia del R3, no es posible indicar que cargue primero las clases locales desde la consola administrativa de despliegue.

Para solucionarlo, basta con incluir un archivo orion-web.xml al nivel del web.xml en la aplicación con este contenido:

Carga de clases locales en los OAS-R3

En los OAS-R3, desde la consola de administración y dentro del plan de despliegue, se puede definir la carga de clases de la aplicación.

Se muestra una lista con las bibliotecas compartidas en el servidor, permitiendo elegir si se importan o no en el proyecto. Además, en la parte inferior, podemos especificar si se desea que se carguen primero las clases locales de la aplicación, chequeando la casilla correspondiente.




Pág. 48 de 78



Al ir a “Configurar carga de clase” se hace visible un check por cada módulo de la aplicación donde podemos indicar si deberá buscar primero en las clases de la aplicación o en las del servidor.




Pág. 49 de 78



ANEXO 5: Configuración de profiles de BBDD

Desapp0

PROFILE LIMIT (SESSIONS_PER_USER)

DEFAULT 100

AGRICULT 25

INAGA DEFAULT

INAWEB 200

AGRIWEB 25

AGRIWEB2 DEFAULT

GOEM 20

PRUEBAS DEFAULT

TED DEFAULT

AGRICULT_15MIN 25

SISTEMA UNLIMITED

GESTION_USR_ADMIN 100

Desapp1


DEFAULT UNLIMITED

INAGA DEFAULT

INAWEB DEFAULT

AGRICULT 25

AGRIWEB 25

AGRIWEB2 DEFAULT

GOEM 20

PRUEBAS DEFAULT

TED DEFAULT

CREADORES 200




Pág. 50 de 78




APPWEB 10

SISTEMA UNLIMITED

PRUEBAS_CADUCIDAD DEFAULT


Preapp0


DEFAULT UNLIMITED

AGRICULT 25

AGRIWEB 25

APPWEB 10

CREADORES 200

JSCAN 10

OOEE 10

TRIBUTOS 80

INAGA 25

INAWEB 200

AGRICULT_15MIN 25

SISTEMA UNLIMITED

Preapp1


DEFAULT UNLIMITED

AGRICULT 25

AGRIWEB 25




Pág. 51 de 78




APPWEB 10

CREADORES 200

JSCAN 10

OOEE 10

TRIBUTOS 80

INAGA 25

INAWEB 25

SISTEMA UNLIMITED


Proapp0


DEFAULT UNLIMITED

AGRICULT 25

AGRIWEB 25

APPWEB 10

CREADORES 200

JSCAN 10

OOEE 10

TRIBUTOS 80

SISTEMA UNLIMITED





Pág. 52 de 78



Proapp1


AGRICULT 25

AGRIWEB 25

APPWEB 10

CREADORES 200

JSCAN 10

OOEE 10

TRIBUTOS 80

INAGA DEFAULT

INAWEB 200

CUARENTENA 40

CUARENTENA_2 150

SISTEMA UNLIMITED

AGRICULT_15MIN 25




Pág. 53 de 78



Anexo 6: Parámetros de globalización de BBDD

• NLS_DATABASE_PARAMETERS: Se configuran en la creación de la BBDD. Se trata de los parámetros comunes a todas las instancias. Se pueden consultar mediante esta consulta:

select * from nls_database_parameters;

• NLS_INSTANCE_PARAMETERS: Parámetros específicos de la instancia Se pueden consultar mediante esta consulta:

select * from nls_database_parameters;

Instance parameters

NLS_INSTANCE_PARAMETERS VALOR

NLS_LANGUAGE SPANISH

NLS_TERRITORY SPAIN

NLS_LENGTH_SEMANTICS CHAR

NLS_NCHAR_CONV_EXCP FALSE

Database parameters

NLS_DATABASE_PARAMETERS VALOR

NLS_LANGUAGE SPANISH

NLS_TERRITORY SPAIN

NLS_CURRENCY ?

NLS_ISO_CURRENCY SPAIN

NLS_NUMERIC_CHARACTERS ,.

NLS_CHARACTERSET AL32UTF8

NLS_CALENDAR GREGORIAN

NLS_DATE_FORMAT DD/MM/RR

NLS_DATE_LANGUAGE SPANISH

NLS_SORT SPANISH

NLS_TIME_FORMAT HH24:MI:SSXFF

NLS_TIMESTAMP_FORMAT DD/MM/RR HH24:MI:SSXFF

NLS_TIMESTAMP_TZ_FORMAT HH24:MI:SSXFF TZR

NLS_DUAL_CURRENCY ¿




Pág. 54 de 78



NLS_DATABASE_PARAMETERS VALOR

NLS_COMP BINARY

NLS_LENGTH_SEMANTICS BYTE

NLS_NCHAR_CONV_EXCP FALSE

NLS_NCHAR_CHARACTERSET AL16UTF16

NLS_RDBMS_VERSION 10.2.0.2.0




Pág. 55 de 78



ANEXO 7: Plataforma de firma electrónica

Las aplicaciones que integren con la plataforma de firma electrónica deberán tener en cuenta las siguientes consideraciones a la hora de enviar un entregable de la aplicación:

• No se deberá incluir en los entregables el componente cliente de firma. En los entornos locales de integración las aplicaciones puede utilizar el componente cliente en su aplicación, pero éste no deberá incluirse en los entregables.

• Las aplicaciones importaran el componente cliente del mismo dominio en que se encuentre desplegadas ya que el componente ya se encuentra instalado en los OAS-R2 y OAS-R3 (deservicios, desservicios3, preservicios, preservicios3, servicios y servicios3). La importación deberá realizarse mediante el uso de una propiedad de configuración que dependerá del entorno, y cuyo valor será:

o Integración (des): URL_WEBSIGNER = http://desservicios.aragon.es/firma/

o Integración (des3): URL_WEBSIGNER = http://desservicios3.aragon.es/firma/

o Preproducción (pre): URL_WEBSIGNER = http://preservicios.aragon.es/firma/

o Preproducción (pre3): URL_WEBSIGNER = http://preservicios3.aragon.es/firma/

o Producción (pro): URL_WEBSIGNER = http://servicios.aragon.es/firma/

o Producción (pro3): URL_WEBSIGNER = http://servicios3.aragon.es/firma/

Si la aplicación está alojada en protocolo seguro (https), la configuración de las url se define con https en lugar de http

• Dentro de la ruta indicada, las librerías javascript del componente cliente están alojadas en la carpeta js.

• Las urls de los servicios web de la plataforma de firma también deberán especificarse mediante propiedad de configuración por entorno. La plataforma de firma proporciona distintos servicios web en función de las operaciones que la aplicación realice.

En el fichero de configuración por entorno deberá existir una entrada por cada servicio web distinto que utilice la aplicación.

Las url´s correctas a utilizar en los distintos entornos aparecen detalladas en la documentación de integración que proporciona el grupo de soporte de firma a los integradores con la plataforma.

• También deberán configurarse como parámetros dependientes del entorno los siguientes valores relacionados con la plataforma de firma:

o Código de aplicación: En desarrollo y preproducción su valor será el determinado desde el grupo de soporte de firma para su utilización en entorno de pruebas. En producción deberá especificarse en la petición de despliegue de la aplicación en producción para configurarle el valor correcto.




Pág. 56 de 78



o Códigos de operaciones según las operaciones que realice la aplicación.

o Alias de certificado para firma en servidor : En desarrollo y preproducción su valor será el determinado desde el grupo de soporte de firma para su utilización en entorno de pruebas. En producción deberá especificarse en la petición de despliegue de la aplicación en producción para configurarle el valor correcto.

• Los códigos a utilizar en el entorno de pruebas aparecen detallados en la documentación de integración que proporciona el grupo de soporte de firma a los integradores con la plataforma.




Pág. 57 de 78



ANEXO 8: Plataforma de Pasarela de pago

Las aplicaciones que integren con la plataforma de pasarela de pago deberán tener en cuenta las siguientes consideraciones a la hora de enviar un entregable de la aplicación:

• La url del servicios web de la plataforma de pasarela de pago deberá especificarse mediante propiedad de configuración dependiente de entorno.

• La url correcta a utilizar en los distintos entornos aparece detallada en la documentación de integración que proporciona el grupo de soporte de pasarela de pagos a los integradores con la plataforma.

• También deberán tratarse como parámetros dependientes del entorno los siguientes valores relacionados con la plataforma de pasarela de pago:

o Código de aplicación

o Modelo

o Concepto

o Organismo

• En desarrollo y preproducción su valor será el determinado desde el grupo de soporte de pasarela de pago para su utilización en entorno de pruebas. En producción deberá especificarse en la petición de despliegue de la aplicación en producción para configurarle el valor correcto.




Pág. 58 de 78



ANEXO 9: Autenticación de usuarios con SAU

Pasamos a describir los pasos a seguir para que una aplicación Java se integre correctamente con esta plataforma.

Actuaciones en SAU

Por parte de los administradores de SAU, es necesario realizar las siguientes actuaciones para que la aplicación Java se integre correctamente.

1.- Alta de aplicación: Es necesario dar de alta la aplicación en SAU, y proporcionar a los desarrolladores que se deseen integrar los siguientes datos:

• Código de aplicación: Código que se ha asignado en SAU para la aplicación java. Su valor deberá ser configurado en el parámetro AppName del fichero de propiedades saufilter.properties .

• Clave filtro de autentificación: Cadena de caracteres asociada a la aplicación necesaria para que ésta sea identificada por SAU. Su valor deberá ser configurado en el parámetro PrivateKeyXML del fichero de propiedades saufilter.properties .

• URL de aplicación: Es importante que la url que se asocie a la aplicación java corresponda a un dominio *.aragon.es para la accesibilidad de las cookies generadas desde la aplicación y desde SAU. Un ejemplo de url válida sería http://prueba.aragon.es:8888/demosau/privado.

En el alta de aplicación hay que tener en cuenta que se deberá definir correctamente la URL para redirigir las peticiones que requieran autenticación.

SAU puede configurarse para su integración con autoregistro, de forma que cuando un usuario de autoregistro accede a la aplicación java, comprueba si el usuario ésta dado de alta en autoregistro, y si es así, migra sus datos desde autoregistro a SAU y asocia al usuario a la aplicación.

2.- Usuario webservices: En el proceso de validación de usuarios desde la aplicación java se requiere invocar a un webservice de SAU para realizar operaciones que validan la aplicación y los usuarios que desean logarse en ella.

Es necesario crear un usuario de SAU asociado a la aplicación Java para realizar la invocación de los webservice, y proporcionar a los desarrolladores que se deseen integrar los siguientes datos:

• Usuario: Código de usuario en SAU. Su valor deberá ser configurado en el parámetro LoginSAUWebService.

• Password: Clave en plano del usuario creado en SAU. Su valor deberá ser configurado en el parámetro PasswordSAUWebService.

• Código de aplicación asociada: El código de aplicación al que se ha asociado en SAU. Su valor deberá ser configurado en el parámetro AppSAUWebService.




Pág. 59 de 78



Importante recalcar que la aplicación configurada en AppSAUWebService deberá ser la aplicación java. Si se asociara al usuario para el webservice la aplicación Logon , se obligaría a los usuarios que deseen autenticarse en SAU desde la aplicación Java a tener también asociada la aplicación Logon .

• Usuario SAU : Finalmente, para autenticarse en SAU correctamente desde la aplicación Java, será necesario disponer de un usuario válido en SAU y que éste este asociado a la aplicación dada de alta en el paso 1.

Actuaciones en aplicación Java

Por parte de los administradores de la aplicación Java que deseen integrarse con SAU, se deberán realizar las siguientes acciones:

1.- Integrar la librería java saufilter en la aplicación Java, añadiendo la parametrización necesaria en la configuración de la aplicación web (fichero web.xml).

Como anotaciones a tener en cuenta:

• Importar la librería SAUFilter.jar al proyecto Java.

• Importar el fichero de configuración requerido por la librería, saufilter.properties , en el proyecto java, teniendo en cuenta que dicho fichero de configuración deberá ubicarse en la carpeta “/WEB-INF/classes/propertyFiles” de la aplicación web para que la librería recupere sus datos correctamente.

• Solicitar los datos asociados a la aplicación java que previamente han sido registrados en SAU.

• A la hora de definir una página de error asociada a la conexión con SAU, en el parámetro UrlError, asegurarse de que dicha página no se encuentra dentro de las direcciones sobre las que actúa el filtro SAUFilter, ya que en caso de no poder conectarse a SAU existe el riesgo de que se produzca un bucle de peticiones al servidor.

2.- Si se desea registrar las trazas generadas en la conectividad de la aplicación con SAU (recomendable para desarrollo), deberá configurarse correctamente el parámetro LogClass del fichero saufilter.properties.

3.- A la hora de estructurar el contenido privado de la aplicación para que posteriormente se configuren en el filtro definido en el fichero web.xml, hay que tener en cuenta que SAU sólo permite una ruta de acceso a la parte privada. Como ejemplo, si se asocia a la aplicación java definida en SAU la url http://prueba.aragon.es:8888/demosau/privado, en la aplicación java deberá considerarsecomo ruta raíz del contenido privado la carpeta “/demosau/privado”. Por lo tanto, todos los contenidos privados deberán ser del tipo “/privado/UsuarioServlet”, “/privado/PerfilServlet”, etc.

4.- Al realizarse la desconexión de la aplicación java (invalidando la sesión iniciada en la aplicación Java), se deberán eliminar las cookies generadas para la conexión con SAU desde la propia aplicación Java para que al volver a conectarse con SAU solicite el login en SAU.

Pág. 60 de 78



Acciones de configuración

Para la correcta integración es necesario realizar las siguientes actuaciones sobre la configuración de la aplicación:

1.- Fichero web.xml: Es necesario introducir las siguientes entradas:

<filter> <filter-name>SAUFilter</filter-name> <filter-class>es.aragon.sau.filter.SAUFilter</filter-class> </filter>   <filter-mapping> <filter-name>SAUFilter</filter-name> <url-pattern>/privado/*</url-pattern> </filter-mapping>  <listener> <listener-class>es.aragon.sau.listeners.SAUSessionListener</listener-class> </listener> <listener> <listener-class>es.aragon.sau.listeners.SAUSessionAttListener</listener-class> </listener>

2.- Fichero saufilter.properties: Fichero de configuración que deberá contener los siguientes parámetros:

// URL del formulario de autenticacion en SAU SAUUrl = http://sau.aragon.es/SAU/Logon.aspx // Clave privada asociada a la aplicación registrada en SAU PrivateKeyXML = PFJTQUtleVZhbHVlPjxNb2R1bHVzPnVZcUJ4ZmtiNjBzc2ZSNklPdGFUYUVpVGNMbjE4aEdRVlZuY3NJcklIMXl4QzN0bWZaT2h1dEdzcnJzUGlqQWtJcFQyMWlLa3dhNWZxT0lSVjJ3ZFNaN2w5SHoxNmE0MU9Ud3BBNThFYmpwUDFhOG9HWVc3cHljdXI5RU5TNFN0OFVQU2VkR251VmtrWEorM3N3ZERQdmZnZy9EWFlqb0poWk12djhHTjFDTT08L01vZHVsdXM+PEV4cG9uZW50PkFRQUI8L0V4cG9uZW50PjxQPjZHbE1vUWtlN0FmdkI3RWVFSmNaY2I5cXJGV1M1Q1NzQW5GWnBxdGY1K3lON2VDeFlpeWY0YUZzUGFKWHFJc3FGcXVzcCtwMVZxMVZpYURqdzZJbWl3PT08L1A+PFE+ekY5aXV5VkRQOXZFM0g2R0NxYjVKREJ4bkNoY3ZlbVFnZ2JHWkhlQkJIMjJuUWJqU214dklEcG1iS1dzRjZXOXFtamFFS0tvQTB6alJIWHJQSXZUeVE9PTwvUT48RFA+eHhyV3hDcjlLN1pNUittcjJRaXBpckl6SC9xYndnbk10cmNHMSt0L1dVQm1Bd0Y0MWFOblFUUTZkNzdwbkFIRkIvRUJGRVdmU3FkcVhXTFJYWnMvcXc9PTwvRFA+PERRPlV2cy82V0Q5NTBYaXJ1eW9uRmFqdm0vMUVVVEtNMHBNcEo3L212ZHk2VkhwL2VRNEVaWHBvUnBWVURRTXBpVmoxM2R2WTJYSDlsOFh3RXBvMDFLckVRPT08L0RRPjxJbnZlcnNlUT5LWFR1SjRLanMwYndqc3JFMmhKa3BFMVlSa1h3UzgrMG9lWWEwN3hvWWdkSWNSS0VaSkJvYmpVbGd3S3NvM1E0VWtQaDYzU1dQb29wc0poS3dFVStjdz09PC9JbnZlcnNlUT48RD5VTXZqQlU0Y2ZWTW9GWGhGUkxJS1VRQkJ6SFgraHlKazR2WVY1MzhYOUtoTnBMMWcvVkJidmxudVE4ekwwSlowTmViK3NuTTFvZTRJVkNmVisyYm1QVm5TMHphYURRV1A4R3hGK1BVT1hQdndtMCs4ekM4TVpvSmkwNnNSRU1ncnVEeHlkY1MwWlROTE1HQ0QrU1VPOUpHMU5SamRKcThYbW91OTk2R04xdkU9PC9EPjwvUlNBS2V5VmFsdWU+ // Código de la aplicación registrada en SAU AppName = JAVA_DEMO // Denominación de la variable que almacenará la informacion del usuario autenticado SessionAppName = SAU.USER // Pantalla de error a la que redirige SAUFilter en caso de detectar algún error en la comunicación con SAU UrlError = ../error.jsp // Denominación de la variable que almacenará el error detectado anteriormente NameAttError = MessageError // URL del webservice donde SAUFilter realiza las operaciones UrlSAUWebService = http://sau.aragon.es/webservice/Logon.asmx // Aplicacion en SAU utilizado por el webservice para realizar las operaciones AppSAUWebService = Logon // Usuario de SAU utilizado por el webservice para realizar las operaciones LoginSAUWebService = JAVA // Password del usuario de SAU utilizado por el webservice para realizar las operaciones PasswordSAUWebService = Wt_p5J4Lr




Pág. 61 de 78



// Clase java que realiza la escritura de trazas. Deberá implementar la clase ILog para que se registren las trazas de SAUFilter LogClass = es.aragon.ast.demosau.util.DemoLog

Administración de usuarios

En el caso de que la aplicación incluya un apartado de administración de usuarios que deberá integrarse con SAU, deberá tener en cuenta los siguientes puntos:

• En la tabla definida para el almacenamiento de usuarios, se deberá crear un campo que permita identificar el registro con el registro en SAU, para que desde la aplicación Java se permita actualizar el registro de SAU.

• Hay que tener en cuenta la longitud de los campos en la base de datos de SAU para que los datos enviados a SAU no excedan de esa longitud. La siguiente tabla muestra la longitud de los campos en SAU:

CAMPO DESCRIPCION PROPIEDADES

US_DNI Dni del usuario VARCHAR2(10)

US_NOMBRE Nombre VARCHAR2(150)

US_APELLIDO1 Primer apellido VARCHAR2(110)

US_APELLIDO2 Segundo apellido VARCHAR2(40)

US_PRV Provincia CHAR(2)

US_MUN Municipio CHAR(3)

US_LOGIN Login VARCHAR2(80)

US_PASSWORD Password VARCHAR2(30)

US_FC_VALIDEZ Fecha de validez DATE




Pág. 62 de 78



CAMPO DESCRIPCION PROPIEDADES

US_EMAIL Correo electrónico

VARCHAR2(80)

US_TELEFONO Teléfono VARCHAR2(30)

US_MOVIL Teléfono móvil VARCHAR2(30)

• De la misma forma que SAUFilter hace uso de los webservices proporcionados por SAU, la aplicación deberá implementar, al mismo nivel que las transacciones a base de datos con las operaciones que afectan a los usuarios, las invocaciones al webservice que gestiona los usuarios mediante el uso de la clase proporcionada por SAUFilter denominada WSLogonClient, iniciándola con los parámetros definidos en el fichero de configuración saufilter.properties.

Se puede consultar las operaciones que permite el webservice en la dirección

http://sau.aragon.es/webservice/Logon.asmx

El siguiente ejemplo muestra el uso correcto del webservice desde la aplicación:

// Iniciación del clase que invoca los webservices WSLogonClient ws = new WSLogonClient(Util.getValorConfiguracion("AppSAUWebService"), Util.getValorConfiguracion("LoginSAUWebService"), Util.getValorConfiguracion("PasswordSAUWebService"), Util.getValorConfiguracion("UrlSAUWebService")); conn = openConnection(); try { beginTransaction(conn); // Damos de alta al usuario en base de datos long idUsuarioInsertado = UsuariosDAL.insertUsuarios(conn, usuarioObject); // Damos de alta al usuario en SAU es.aragon.sau.webservices.proxy.Salida salida = ws.insertarUsuario(usuarioObject.getDniObject(),usuarioObject.getNombreObject(), usuarioObject.getPrimerApellidoObject(), usuarioObject.getSegundoApellidoObject(), usuarioObject.getProvinciaObject(), usuarioObject.getMunicipioObject(), usuarioObject.getLoginObject(), usuarioObject.getClaveObject(), usuarioObject.getFechaValidezObject() ,usuarioObject.getEmailObject(), usuarioObject.getTelefonoMovilObject(),usuarioObject.getTelefonoMovilObject(), false, false); if (!salida.getRespuesta().getValue().equals(Resultado._Correcto) ){ throw new UsuariosException(UsuariosException.ERROR_INSERTAR_WS); } // Actualizamos el campo que relaciona el registro en la aplicación con el registro en SAU usuarioObject.setIdUsuario(idUsuarioInsertado); usuarioObject.setIdUsuarioSauObject(new Long(salida.getUsuario())); UsuariosDAL.updateUsuarios(conn, usuarioObject);




Pág. 63 de 78



// Si todo ha ido OK, validamos el registro en base de datos. commitTransaction(conn); } catch (Exception e) { // Se se ha producido un error, se anula la inserción del registro rollbackTransaction(conn); log.error(e.toString(), e); throw new UsuariosException(e.toString()); } finally { closeConnection(conn); }

• Los únicos campos del usuario que se pueden modificar en SAU son los siguientes: Correo electrónico, teléfono, teléfono móvil y contraseña.

Indicar que en cada modificación del usuario el campo contraseña deberá informarse como vacío en lugar de cómo nulo, ya que si no es así la actualización exigirá modificar la contraseña.

• Se deberá tener en cuenta que el valor asociado al campo contraseña deberá cumplir una serie de condiciones impuestas por SAU, que son las siguientes:

o La contraseña no deberá coincidir con el login.

o Deberá tener una longitud de más de 8 caracteres.

o Deberá empezar por una letra.

o Deberá contener un carácter en mayúscula.

o Deberá contener un carácter en minúscula.

o Deberá contener 2 números.

o Deberá incluir un símbolo (!"#$%&()'*,+-/:;<=>?_\) entre las posiciones 2 y 6.

• El código de provincia y código de municipio corresponden a los siguientes campos de tablas públicas:

Provincia: Campo CODIGO_PROVINCIA de la tabla CES_PROVINCIAS.

Municipio: Campo CODIGO_MUNICIPIO de la tabla CES_MUNICIPIOS, de los municipios correspondientes a la provincia seleccionada.

• El campo Fecha de validez deberá ser una fecha mayor que la fecha actual.




Pág. 64 de 78



ANEXO 10: Autenticación de usuarios con Autoregistr o

La URL de la aplicación es la siguiente:

http://autoregistro.aragon.es/paa/menu.aspx

Para poder utilizar este servicio Web desde Java se puede emplear el asistente de Eclipse, AXIS u otras herramientas. En concreto en este apartado se describe la opción de AXIS.

AXIS permite generar las clases cliente a un servicio Web. Para más información acudir a los siguientes enlaces.

http://ws.apache.org/axis/

http://www.w3.org/TR/soap/

http://www.w3.org/TR/wsdl

En el package org.apache.axis.wsdl, existe la clase WSDL2Java a la que se le pasa como argumento un fichero wsdl que contiene la definición de un servicio Web.

java org.apache.axis.wsdl.WSDL2Java fichero.wsdl

Esta llamada genera las distintas clases y métodos asociados al servicio Web, que podrán ser empleadas en el proyecto correspondiente.

La url del servicio web en producción es:

http://autoregistro.aragon.es/WebService/WS_PAA.asmx

Este servicio ofrece una serie de operaciones para interactuar con la plataforma de Auto-Registro. Las operaciones que ofrece son las siguientes:

Método Descripción Parámetros Retorno

InsertarUsuario Método que inserta un usuario

Objeto Tipo usuario Tipo usuario con el identificador del usuario introducido

ModificarUsuario Modifica los datos de un usuario

Objeto Tipo Usuario Tipo ErrorBase

DetalleUsuario Devuelve los datos de un usuario

Int IdUsuario

String Email

Tipo Usuario

ValidaUsuario Valida un usuario String Email

String Id(Codigo Hash)

Tipo ErrorBase

LimpiarIdOlvido Limpia el identificador que se genera cuando el usuario solicita recordar la contraseña

String Email

String Id(Codigo Hash)

Tipo ErrorBase




Pág. 65 de 78




DarBajaUsuario Da de baja a un usuario

Int id (IdUsuario) Tipo ErrorBase

CambioPassword Modifica la contraseña de un usuario

String Email

String password(Nueva contraseña)

Tipo ErrorBase

EstablecerIdOlvido Establece el identificado de olvido porque el usuario ha solicitado recordar su contraseña

String email Tipo Usuario

EstablecerCertificado Encargado de cambiar el tipo de usuario de autorregistro a certificado

String nif Tipo ErrorBase

Autenticar Autentica a un usuario String email

String clave

String nif

String ip

Tipo ErrorUsuario

ListaAplicaciones Lista las aplicaciones asociadas al usuario

Int id (idUsuario) Array de Objetos Aplicación

ListaUsuariosAplicacion Lista los usuarios asociados a la aplicación

String id (idAplicacion)

Array de Objetos Usuarios

AsignaPermisos Da acceso a un usuario sobre una aplicación

Int idUsuario

String idAplicacion

Date fechaInicio

Date fechaFin

Tipo ErrorBase




Pág. 66 de 78




ModificaPermisos Modifica los permisos de un usuario sobre una aplicación

Int IdUsuario

String idAplicacion

EstadoPermiso: estado (es de tipo enum y tiene los valores: Alta, Baja y Denegado)

Date fechaInicio

Date fechaFin

Tipo ErrorBase

SolicitaAcceso Comprueba si un usuario puede acceder a una aplicación

Int IdUsuario

String idAplicacion

String ip

Tipo ErrorBase

Los tipos de datos utilizados son estos:

Tipo de datos Descripción Campos

ErrorBase Indica si se ha producido un error

Error: Booleano.

Código: String. Identifica el error con un código.

Mensaje: String. Describe el error

ErrorUsuario

Indica si se ha producido un error en el método Autenticar Error: ErrorBase.

IdUsuario: entero. Devuelve el identificador del usuario que se ha autenticado

Usuario Recoge toda la información que se puede obtener de un usuario IdUsuario: entero. Identificador del usuario.

Es obligatorio.

Personalidad . De tipo personalidad. Es de tipo enum con los valores física o jurídica. Indica el tipo de personalidad del usuario que se registra. Es obligatorio.

Fecha alta: date. Fecha en la que el usuario se dio de alta. Es obligatoria.

Fecha baja: date. Fecha en la que el usuario se dio de baja.




Pág. 67 de 78




Nif: String(10). Nº de identificación fiscal del usuario o empresa.

Nombre: String(30). Nombre del usuario.

Apellido1: String(40). Primer apellido del usuario o razón social de la empresa si se trata de personalidad jurídica. Es obligatorio.

Apellido2: String(40). Segundo apellido del usuario.

Empresa: String(80).

Email: String(80). Dirección de correo electrónico del usuario. Es obligatorio.

EmailAlternativo: String(80). Dirección de correo electrónico alternativo del usuario.

Domicilio: String(100)

Código postal: String(5)

NombreNotificacion: String(80)

CodProvincia: String(2)

CodMunicipio: String(3)

Provincia: String(80)

Municipio: String(80)

Telefono: String(30)

Movil: String(30)

NumeroConexiones: Entero.

FechaUltimaConexion : date.

TipoUsuario: De tipo TipoUsuario. Es de tipo enum y tiene los valores: autorregistro, certificado y reconocido. Indica la manera en la que se ha dado de alta el usuario en la aplicación.

FechaModificacionClave: date.

FechaInicioValidez: date. Fecha a partir de la cual la contraseña es válida.




Pág. 68 de 78




Estado . De tipo Estado. Es de tipo enum y tiene los valores: pendiente, alta, baja y denegado. Indica el estado en el que se encuentra el usuario.

IdOlvido: String(30) Identificador que se genera cuando el usuario ha solicitado recordar su contraseña.

EstadoPermiso: De tipo EstadoPermiso. Es de tipo enum y tiene los valores: Alta, Baja y Denegado. Indica el estado en el que se encuentra el permiso de conexión de un usuario a una aplicación.

FechaInicioPermiso: date. Fecha a partir de la que un usuario puede acceder a una aplicación. Es obligatoria.

FechaFinPermiso: date. Fecha hasta la que un usuario puede acceder a una aplicación.

NumeroEntradas: entero.. Nº de veces que un usuario ha accedido a una aplicación.

FechaUltimaEntrada : date.

Error: De tipo ErrorBase. Indica si ha habido un error con su código y su mensaje asociado.

Aplicacion Recoge los datos relacionados con una aplicación y el acceso por parte de los usuarios a ella.

IdAplicacion: String(10) Es obligatorio.

Descripción: String(80) Es obligatorio.

FechaAlta: Date. Es obligatorio.

NivelSeguridad: De tipo NivelSeguridad. Es de tipo enum y tiene los valores: Autorregistro, Certificado y Reconocido. Indica el nivel de seguridad de acceso a la aplicación.

FechaInicio: date. Fecha a partir de la cual la aplicación se ha empezado a utilizar.

Cerrada.

FechaBaja: date. Fecha a partir de la cual no se podrá acceder a la aplicación.

EstadoPermiso: De tipo EstadoPermiso. Es de tipo enum y tiene los valores: Alta, Baja y Denegado. Indica el estado en el que se




Pág. 69 de 78




encuentra el permiso de conexión de un usuario a una aplicación.

FechaInicioPermiso: date. Fecha a partir de la que un usuario puede acceder a una aplicación. Es obligatoria.

FechaFinPermiso: date. Fecha hasta la que un usuario puede acceder a una aplicación.

NumeroEntradas: entero. Nº de veces que un usuario ha accedido a una aplicación.

FechaUltimaEntrada: date. Fecha en la que el usuario accedió por última vez a la aplicación.

Para más información sobre los métodos y sus variables puede dirigir una consulta a través de la página de AST o del gestor de la aplicación.




Pág. 70 de 78



ANEXO 11: Herramienta ANT

ANT es una herramienta libre, desarrollada dentro de la comunidad Apache, que permite automatizar las tareas de compilación, empaquetado, distribución de proyectos, etc.

Los ficheros fuente del proyecto, los binarios y la documentación pueden descargarse libremente desde http://ant.apache.org/

Muy básicamente, ANT ejecuta las acciones definidas dentro de un fichero llamado build.xml. Este fichero build.xml incluye una serie de TARGETS que agrupan TASKS (tareas) a realizar para cada TARGET. Las TASKS son acciones del tipo: compila una serie de ficheros, crea directorio, copia fichero a un destino, genera fichero EAR…

Configuraciones más complejas pueden utilizar una serie de ficheros build.xml anidados que se referencien entre sí.

Instalación de la herramienta ANT

La herramienta ANT puede descargarse en dos formatos: fuentes y binarios.

La instalación en formato binario es muy sencilla. Solamente hay que descargar de la página anterior la versión de ANT en formato binario empaquetado en el formato que queramos, descomprimirlo en el directorio que elijamos y añadir el directorio BIN al PATH del sistema.

Los diferentes empaquetados que podemos encontrar en formato binario son:

• apache-ant-1.6.5-bin.zip en formato comprimido ZIP.

• apache-ant-1.6.5-bin.tar.gz en formato compactado con TAR y comprimido con GZIP.

• apache-ant-1.6.5-bin.tar.bz2 en formato compactado con TAR y comprimido con BZIP2.




Pág. 71 de 78



ANEXO 12: Log4j

Ejemplo de posible configuración de log4j:

(En el siguiente ejemplo es necesario sustituir la cadena cod_app por el código de la aplicación y la cadena nivel_log por el nivel de log deseado).

# cod_app = nombre del appender que se configura # nivel_log = DEBUG | INFO | WARN | ERROR | FATAL log4j.logger.cod_app=nivel_log, cod_app o log4j.es.aragon.cod_app=nivel_log, cod_app # almacena el fichero de log diariamente log4j.appender.cod_app=org.apache.log4j.DailyRollingFileAppender # path y nombre del fichero de log log4j.appender.cod_app.File=/logs/app/cod_app/cod_app.log # Se guarda el fichero de log de cada día log4j.appender.cod_app.DatePattern='.'yyyy-MM-dd #Definir el formato de salida del log por fichero log4j.appender.cod_app.layout=org.apache.log4j.PatternLayout # formato de escritura en el fichero de log # %d fecha # %p prioridad # %m mensaje # %n salto de línea log4j.appender.cod_app.layout.ConversionPattern= %d %p %m %n

NOTA: No se utilizará nunca la propiedad rootLogger.

Log4j permite estos niveles de log (de mayor (poco detalle) a menor (mucho detalle):

NIVEL LOG DESCRIPCIÓN

OFF Logs deshabilitados.

FATAL Se utiliza para mensajes críticos del sistema. Generalmente, después de guardar el mensaje, el programa abortará.

ERROR Se utiliza en mensajes de error de la aplicación que se desea guardar. Estos eventos afectan al programa pero lo dejan seguir funcionando, como por ejemplo que algún parámetro de configuración no es correcto y se carga el parámetro por defecto.

WARN Se utiliza para mensajes de alerta sobre eventos que se desea mantener constancia pero que no afectan al correcto funcionamiento del programa.

INFO Se utiliza para mensajes similares al modo "verbose" en otras aplicaciones.

DEBUG Se utiliza para escribir mensajes de depuración. Este nivel no debe rá estar activado cuando la aplicación se encuentre en producción.

TRACE Se utiliza para mostrar mensajes con un mayor nivel de detalle que “debug”.

ALL Nivel de máximo detalle, habilita todos los logs (en general equivale a TRACE).




Pág. 72 de 78



ANEXO 13: Autenticación de usuarios con LDAP

Este método autentica los usuarios contra el LDAP que configuremos en la aplicación.

• URLS del LDAP:

Preproducción Producción

Ldappre.aragon.local

Puerto 389

Ldap.aragon.es

Puerto 389

A continuación se muestra un código de ejemplo en J2EE para invocar al LDAP de PRE. Solamente se necesita importar la librería jndi.jar.

public boolean getConexionLdap(String user, String passwd) { DirContext contexto; Hashtable entorno = new Hashtable(); try { System.out.println("Intento de acceso del usuario " + user); entorno.put(Context.INITIAL_CONTEXT_FACTORY,"com.sun.jndi.ldap.LdapCtxFactory"); entorno.put(Context.PROVIDER_URL, "ldap://ldappre.aragon.local"); entorno.put(Context.SECURITY_AUTHENTICATION, "simple"); entorno.put(Context.SECURITY_PRINCIPAL, "uid=" + user + ", ou=People, o=aragon.es, o=isp"); entorno.put(Context.SECURITY_CREDENTIALS, passwd); System.out.println("Lanzando conexion LDAP"); contexto = new InitialDirContext(entorno); System.out.println("Usuario y contraseña valido"); return true; } catch(Exception excep) { System.out.println("Usuario o contraseña incorrecto"); System.out.println(excep); return false; }




Pág. 73 de 78



ANEXO 14: Métodos para generar el fichero ear o jar

Generación del archivo manualmente, mediante la her ramienta jar

Si se trata de una aplicación, se genera el ear con una instrucción similar a una de las siguientes:

• jar cvfm app.ear META-INF\MANIFEST.MF app.war META-INF\application.xml ...

• jar cvfm app.ear META-INF\MANIFEST.MF *

Si se trata de una librería, se genera el jar con una instrucción similar a la siguiente:

• jar cvfm librería.jar META-INF\MANIFEST.MF *

El comando "m" indica que se incluya la información de manifest del archivo especificado tras el nombre del archivo generado. El resto de parámetros son los ficheros que se incluyen.

Para más información sobre la herramienta jar:

http://java.sun.com/j2se/1.4.2/docs/guide/jar/jar.html

Generación del archivo mediante la herramienta ant

Si la aplicación o la librería se genera mediante la herramienta ANT, es necesario modificar el tag "jar" que crea el archivo para que incluya la información de manifest:

<jar destfile="${build.dir}/${destination.file}" manifest="META-INF/MANIFEST.MF"> <fileset dir="${build.dir}" includes="es/aragon/app/data/MiClase.class, … " /> </jar>




Pág. 74 de 78



ANEXO 15: Despliegue por línea de comandos en los O AS

Comandos del DCM (sólo para los OAS-R2)

Comando Descripción

dcmctl deployApplication -file [nombre ear] -a [nombre aplicación] -co [nombre_contenedor]

Desplegar aplicación nueva.

dcmctl redeployApplication -file [nombre ear] -a [nombre aplicación] -co [nombre_contenedor]

Redesplegar una aplicación existente.

dcmctl undeployApplication -file [nombre ear] -a [nombre aplicación] -co [nombre_contenedor]

Eliminar aplicación existente.

dcmctl getreturnstatus Estado del dcm.

listApplications -co [nombre contenedor] [-cl nombre cluster] | [-i nombre instancia]]

Lista de aplicaciones de un contenedor.

validateEarFile -file simple_ear_file

Validar un ear previo al despliegue.

Si no se especifica la instancia OC4J sobre la que se está ejecutando el comando, la operación se aplicará a todas las instancias existentes en el servidor.

Despliegue por línea de comandos en los OAS-R3

Se utiliza la librería admin_client.jar

La instrucción para desplegar una aplicación es la siguiente:

java -jar admin_client.jar uri adminId adminPassword -deploy -file path/filename -deploymentName appName [-bindAllWebApps [webSiteName ]] [-targetPath path ] [-parent appName ] [-deploymentDirectory path ] -enableIIOP [-iiopClientJar path/filename ]

La documentación de Oracle puede consultarse en esta URL:

http://download.oracle.com/docs/cd/B25221_04/web.1013/b14431/adminclient.htm#BABFHIEB




Pág. 75 de 78



ANEXO 16: Uso de un plan de despliegue

Un plan de despliegue es un fichero que incluye todos los datos de configuración necesarios para desplegar una aplicación en una instancia OC4J.

Este plan de despliegue se puede guardar/editar desde la propia consola de despliegue (OAS Release 3). Es especialmente útil en redespliegues ya que evita tener que seleccionar toda la configuración manualmente cada vez que se redespliega una aplicación.

Una vez que el fichero .ear es desplegado, el servidor oc4j utiliza la información contenida en el plan de despliegue para actualizar los ficheros de configuración.

Para más información se puede consultar la documentación de Oracle “Containers for J2EE Deployment Guide 10g Release 3 (10.1.3)” en la siguiente URL:

http://download.oracle.com/docs/cd/B25221_04/web.1013/b14431/toc.htm




Pág. 76 de 78



ANEXO 17: HTML Validator

Se utilizará este pluggin de Firefox para validar Accesibilidad. Se configurará con estas opciones:

Posteriormente se cargará la URL y se comprobará la lista de errores:

Sólo se permitirán estos 2 errores, que son habituales dependiendo del navegador:

� Error: there is no attribute "SRC"

� Error: element "SCRIPT" undefined




Pág. 77 de 78



ANEXO 18: TAW3 (AA)

Para comprobar la accesibilidad de una aplicación, una vez desplegada en el entorno correspondiente, navegaremos por ella e iremos almacenando en una carpeta todas las páginas de la misma.

Una vez hecho esto comprobaremos cada página con la aplicación Taw3.

NOTA: Todas las aplicaciones del Gobierno de Aragón deberán cumplir el nivel de accesibilidad AA definido por el estándar w3c.

Una vez seleccionada la ruta y ejecutado el proceso de Análisis, en la pestaña Resumen se muestran todos los errores localizados en la página.

� P1: Nivel A

� P2: Nivel AA

� P3: Nivel AAA

Se elaborará un informe de errores para remitir al proveedor de la aplicación detallando los detectados en las pestañas P1 y P2 para que se cumpla el nivel AA.




Pág. 78 de 78



Los errores se muestran en este formato: errores automáticos/errores manuales. No se deberá permitir ningún error automático y respecto a los manuales, los comprobaremos para asegurarnos de si realmente son errores o advertencias.

Para más información sobre estilos se puede consultar el documento “AST-ESPEC-GuiaEstilosPortalInternet.pdf”

ast-esp-especificaciones técnicas de los entornos … · especificaciones técnicas de los...

Documents