Entorno WebLogic del Gobierno de AragónProducción : Entorno real de ejecución de las aplicaciones. A continuación se define la estructura del entorno de producción, siendo el

Entorno WebLogic del Gobierno de Aragón

Referencia: ESPEC_EspecificacionesTecnicasWebLogic.doc

Autor: Aragonesa de Servicios Telemáticos

Fecha de creación: 02/12/2013

Última actualización: 25/10/2017

Versión: v1.4

Clasificación: Uso Público

Especificaciones técnicas para el alojamiento de aplicaciones



Ref.: ESPEC_EspecificacionesTecnicasWebLogic.doc Fecha: 25.10.2017 Versión: v1.4 Pág. 3 de 25

Entidad Pública Aragonesa de Servicios TelemáticosAvda. Ruiz Picasso, 63 – Planta 3, Of. J • 50018 ZARAGOZA

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

Contenido

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

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

2.1. CAPA FRONTAL –SERVIDORES WEB- ..................................................................................... 6 2.2. CAPA MEDIA –SERVIDORES DE APLICACIONES- .................................................................. 6

2.2.1. Alta disponibilidad de recursos externos .................................................................................. 7 2.2.2. Librerías disponibles ................................................................................................................. 7 2.2.3. Driver de conexión con base de datos Oracle.......................................................................... 8

3. ESTRUCTURA DE ENTREGA DE APLICACIÓN ............. ................................................................ 9

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

3.1.1.1. Directorio lib ........................................................................................................................ 10 3.1.1.2. Directorio src/conf ............................................................................................................... 10 3.1.1.3. Componentes o módulos .................................................................................................... 10

3.1.2. Proyectos web simples ........................................................................................................... 12 3.1.3. Proyectos web complejos ....................................................................................................... 13

4. ESPECIFICACIONES DE DESARROLLO.................. ..................................................................... 15

4.1. CÓDIGO DE APLICACIÓN......................................................................................................... 15 4.2. VERSIÓN DE LA APLICACIÓN.................................................................................................. 15 4.3. NOMENCLATURA DE FICHERO EAR ...................................................................................... 15 4.4. NOMENCLATURA DE PAQUETES Y CLASES JAVA............................................................... 15 4.5. CONTEXTO DE APLICACIÓN ................................................................................................... 16 4.6. REFERENCIAS A LIBRERÍAS ................................................................................................... 16

4.6.1. En tiempo de compilación....................................................................................................... 16 4.6.2. En tiempo de ejecución........................................................................................................... 17

4.7. GESTIÓN DE EXCEPCIONES................................................................................................... 19 4.8. LOG DE APLICACIÓN................................................................................................................ 19

4.8.1. Borrado de logs....................................................................................................................... 19

4.9. FICHEROS DE PROPIEDADES................................................................................................. 19

4.9.1. Ubicación de los ficheros en el entregable ............................................................................. 20 4.9.2. Ubicación de los ficheros para distribuir ................................................................................. 20 4.9.3. Carga de las propiedades desde la aplicación ....................................................................... 20

4.10. CONEXIÓN A BASE DE DATOS................................................................................................ 21

4.10.1. Definición de data-source ....................................................................................................... 21 �� Relación de cadenas de conexión según base de datos ............................................................... 22

4.10.2. Ubicación del fichero de definición de data-source en el entregable ..................................... 22 4.10.3. Ubicación del fichero de definición de data-source para distribuir ......................................... 23

4.11. MONITORIZACIÓN DE LA APLICACIÓN .................................................................................. 23 4.12. FICHEROS ESTÁTICOS Y TEMPORALES ............................................................................... 24 4.13. USO DE FRAMEWORKS DE DESARROLLO ........................................................................... 24 4.14. HERRAMIENTAS NECESARIAS PARA DESARROLLOS JAVA EE ........................................ 24

4.14.1. Herramienta ANT .................................................................................................................... 24






5. DOCUMENTACIÓN DE ENTREGA ........................ ......................................................................... 25

�� Información general ....................................................................................................................... 25 �� Manual de instalación .................................................................................................................... 25 �� Manual de explotación ................................................................................................................... 25






1. Introducción

El presente documento define las especificaciones técnicas que aplican al desarrollo de aplicaciones JEE para su alojamiento en servidores de aplicaciones WebLogic del Gobierno de Aragón.

Se detallan tanto las características del entorno en el que deben funcionar correctamente las aplicaciones, como las normas de desarrollo y entrega que se deben seguir.






2. Arquitectura de plataforma tecnológica

En este apartado se detalla la arquitectura tecnológica para el entorno WebLogic 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 problemas en la puesta en producción de las aplicaciones.

Existen tres 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 y de integración con otros productos y servicios. Es un entorno no balanceado, y las aplicaciones aquí alojadas sólo están disponibles desde 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, funcionales y de validación de usuario, carga, disponibilidad, etc.

� Producción : Entorno real de ejecución de las aplicaciones.

A continuación se define la estructura del entorno de producción, siendo el entorno de preproducción idéntico tanto en componentes como en configuración. El entorno de integración no tiene alta disponibilidad.

2.1. Capa frontal –servidores web-

Está compuesta de servidores con la siguiente configuración:

� Sistema operativo: Red Hat Enterprise Linux 6.4 (x86_64) (Intel EM64T)

� Servidor web: Apache HTTP Server 2.2.x

Las aplicaciones se publican únicamente por HTTPS y bajo el dominio:

Entorno Dominio

Integración desaplicaciones.aragon.es

Preproducción preaplicaciones.aragon.es

Producción aplicaciones.aragon.es

2.2. Capa media –servidores de aplicaciones-

Está compuesta de servidores con la siguiente configuración:

� Sistema operativo: Oracle Solaris 11

� Versión de Java: Oracle JDK 1.8.0_101-b13

� Servidor de aplicaciones: Oracle WebLogic Server 12c (12.2.1.2.0), que es una implementación compatible de Java EE 7 (Java EE 7 Compatible)






Nota: todos los desarrollos nuevos deben desplegarse en esta infraestructura, pero se sigue manteniendo una capa media de versión anterior para las aplicaciones que ya están desplegadas allí, con las siguientes características:

Sistema operativo: Oracle Solaris 11

Versión de Java: Oracle JDK 1.7.0_141-b33

Servidor de aplicaciones: Oracle WebLogic Server 12c (12.1.3.0.0), que es una implementación compatible de Java EE 6 (Java EE 6 compliant)

2.2.1. Alta disponibilidad de recursos externos

Cada capa está compuesta por al menos 2 nodos. Existen dos mecanismos de alta disponibilidad para los recursos externos (ficheros y datos) de las aplicaciones:

� Almacenamiento externo NFS, para ficheros que deban ser compartidos entre todos los nodos de un cluster.

� Oracle (RAC) Database, para esquemas de bases de datos.

2.2.2. Librerías disponibles

Además de las librerías que ya proporciona el servidor WebLogic, una aplicación puede requerir el uso de librerías de terceros.

Con el objetivo de aligerar los entregables que se generan para desplegar en el servidor de aplicaciones, se va mantener una relación de las librerías que se utilizan con mayor frecuencia, desplegadas en WebLogic como “Paquetes opcionales”. De esta forma las aplicaciones no deberán proporcionar tales librerías; tan sólo referenciarlas.

Antes de solicitar un primer despliegue de una aplicación, se debe indicar qué librerías y versiones necesita utilizar; también con despliegues de nuevas versiones siempre que esas librerías cambien. Los administradores de los servidores decidirán cuáles de ellas se instalan en el servidor como paquetes opcionales, de modo que las aplicaciones no necesitarán incorporarlas en el fichero EAR generado, ni siquiera en el entregable.

AST proporcionará la relación de paquetes opcionales desplegados en los entornos WebLogic, y para cada uno de ellos, indicará:

� Extension-Name

� Specification-Version

� Implementation-Version

En el apartado “Especificaciones de desarrollo” se detalla cómo referenciar estas librerías desde las aplicaciones.






2.2.3. Driver de conexión con base de datos Oracle

El driver de conexión con base de datos es Oracle JDBC Thin Driver 12.1.0.2.0, que es compatible con bases de datos Oracle 11g y 12g.






3. Estructura de entrega de aplicación

Toda aplicación que se deba desplegar en los servidores WebLogic del Gobierno de Aragón deberá cumplir una estructura determinada de entrega, y cumplir las especificaciones que se detallan a continuación.

Se definen varios tipos de entregable según la complejidad del proyecto:

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

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

� Proyectos Java EE complejos: 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 se detalla la estructura.

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

Existe una serie de directorios que aparecen 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/ Documentación relativa al proyecto

lib/ Librerías externas son necesarias para la compilación o ejecución del proyecto

src/java Ficheros fuente

src/conf Ficheros de configuración

setup/ Ficheros relacionados con la instalación del sistema, como manual de instalación, formularios de solicitud de creación de la base de datos, scripts de base de datos, etc.

test/ 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 se generan otros resultados intermedios, por ejemplo un juego de pruebas unitarias, también se genera 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. No es obligatorio que se genere.

La generación de todos los componentes del proyecto que se deban desplegar en los servidores se generarán a través de tareas ANT, definidas en ficheros build.xml.






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

3.1.1.1. Directorio lib

Dentro del directorio “/lib” del directorio raíz tienen que incluirse todas las librerías externas que se utilicen en el proyecto y no estén ya disponibles en los servidores WebLogic (proprocionadas por defecto por el servidor o desplegadas como paquetes opcionales). Las librerías deberán ir en formato .jar.

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 y 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.2. 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.

NOTA: Una misma versión de aplicación (entrega parametrizable) se utilizará para la distribución secuencial a los tres entornos. En ningún caso se aceptarán entregas diferentes o con alguna corrección para preproducción o producción.

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

3.1.1.3. Componentes o módulos

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






Estructura de componente o módulo

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


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. Dónde se usa, cómo utilizar el componente, qué librerías se están utilizando para la compilación del componente, de dónde 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, el MANIFEST.MF, y el weblogic-application.xml con las referencias a las librerías. Dichos ficheros 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 sirve para un proyecto en el que sólo se genera un fichero EAR con un único WAR. La estructura del proyecto que se debe seguir es la siguiente:

Estructura de proyecto web simple

Las únicas novedades que distinguen este tipo de proyecto del anterior es la existencia de los directorios:

� “web”, donde se ubican todos los ficheros propios de la aplicación web

� “setup”, contiene la información necesaria para la instalación de la aplicación


setup/ Información necesaria para la instalación de la aplicación.

web/ 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/ 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 deben ir en el directorio conf/; por ejemplo, un fichero .PROPERTIES con rutas y directorios que se definen a medida para la instalación en un entorno determinado.

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.






3.1.3. Proyectos web complejos

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

La estructura está preparada para incluir:

� Componentes que se reutilizan dentro del proyecto

� Aplicaciones web Java EE con varios ficheros JAR o WAR dentro de un fichero EAR

� Varias aplicaciones Java EE 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 que se debe seguir es la siguiente:

Estructura de proyecto web complejo






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 varios puntos distintos hay que definirla 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/ Un directorio con el nombre de cada aplicación que se genere.

apps/myapp1/ Un directorio con el nombre de cada componente propio de la aplicación. El nombre de los directorios tiene que determinar directamente qué contiene.

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

apps/myapp1/myapp1-ejb/

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/

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/ Los ficheros de configuración para la generación del EAR de la aplicación, por ejemplo weblogic-application.xml

components/ Un directorio con el nombre de cada componente que se genere.

components/comp1/ Todos los ficheros necesarios para generar el componente COMP1.






4. Especificaciones de desarrollo

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

4.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). Es necesario que el código de aplicación sea único y el título 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 título de la aplicación. Será acordado entre la empresa desarrolladora y el grupo de despliegue al comienzo del proyecto.

4.2. Versión de la aplicación

La información de versión de la aplicación se debe incluir en el fichero MANIFEST.MF del fichero EAR generado. Se deben completar al menos las siguientes propiedades:

� Implementation-Vendor: empresa desarrolladora. En caso de desarrollos de AST, el valor "Aragonesa de Servicios Telematicos" -sin acentos para evitar problemas de codificación de caracteres-.

� Implementation-Version: versión de la aplicación distribuida.

En la página inicial de la aplicación, la cabecera deberá mostrar la versión actual, que coincidirá con el valor indicado en la propiedad Implementation-Version.

4.3. Nomenclatura de fichero EAR

El nombre del fichero EAR generado para una aplicación deberá coincidir exactamente con el código de aplicación asignado: <cod_app>.ear

Se considerarán aplicaciones distintas las que se empaquetan en ficheros EAR distintos, y por tanto deberán estar inventariadas separadamente.

4.4. Nomenclatura de paquetes y clases Java

Los nombres de los paquetes Java incluidos en la aplicación se definirán a partir de la siguiente estructura:






es.aragon.<cod_app>

Por ejemplo, son nombres válidos de paquetes:

� es.aragon.<cod_app>.dal: paquete de clases de acceso a datos almacenados en distintas fuentes, como bases de datos, ficheros, directorios LDAP, etc.

� es.aragon.<cod_app>.bl: paquete de clases que implementan la lógica de negocio de la aplicación.

� es.aragon.<cod_app>.servlet: paquete que contiene las clases correspondientes a los servlets de la aplicación.

� es.aragon.<cod_app>.util: paquete de utilidades genéricas de la aplicación.

4.5. Contexto de aplicación

El contexto publicado por una aplicación debe coincidir exactamente con el código de aplicación asignado, <cod_app>. En caso de que una aplicación requiera publicar más de un contexto, todos empezarán por el código de aplicación.

Por ejemplo, para la aplicación cuyo código de aplicación es GPZ, algunas URLs válidas en entorno de producción son:

https://aplicaciones.aragon.es/gpz https://aplicaciones.aragon.es/gpz_publico https://aplicaciones.aragon.es/gpz_admin

4.6. Referencias a librerías

4.6.1. En tiempo de compilación

Para la compilación de los fuentes y empaquetado del proyecto en un fichero EAR, es necesario que en tiempo de compilación se resuelvan correctamente las dependencias con librerías proporcionadas por el servidor. Para ello, en el fichero build.xml se utilizarán dos propiedades:

� srv.lib, que en el momento de compilación de la aplicación apuntará a una ruta que contendrá las librerías que el servidor WebLogic proporciona por defecto.

� cmn.lib, que en el momento de compilación de la aplicación apuntará a una ruta a partir de la cual se encontrarán las librerías de terceros que estén desplegadas en WebLogic como paquetes opcionales.

A partir de la ruta ${cmn.lib} las librerías se estructuran en una jerarquía de directorios siguiendo la misma estructura que utilizan los repositorios de artefactos basados en Maven, es decir:

${cmn.lib}/<groupId>/<artifactId>/x.y.z/libreria-x. y.z.jar

Por ejemplo, supongamos que en los servidores WebLogic están desplegadas como paquetes opcionales las librerías:






� itext-1.2.3.jar

Extension-Name = itext

Specification-Version: 1.2.3

Implementation-Version: 1.2.3

� log4j-1.2.14.jar

Extension-Name = log4j

Specification-Version: 1.2.14

Implementation-Version: 1.2.14

Se quiere desplegar una aplicación que utiliza las mismas versiones de esas librerías, por lo que no se deben incluir en el entregable.

El fichero build.xml que ejecuta la tarea ant de generación del EAR debe incluir en el classpath la referencia a ambas librerías. Para ello se utiliza la variable cmn.lib y la ruta relativa de cada una:

<path id="classpath.ref"> <pathelement path="${classpath}" /> <fileset dir="./lib"> <include name="*.jar" /> </fileset> <fileset dir="${srv.lib}"> <include name="*.jar" /> </fileset> <fileset dir="${cmn.lib}"> <include name="/itext/itext/1.2.3/itext-1.2.3.ja r" /> <include name="/log4j/log4j/1.2.14/log4j-1.2.14. jar" /> </fileset> </path>

La invocación de la tarea ant deberá incluir la referencia a las dos variables:

-Dsrv.lib=”/ruta/a/librerias/servidor” -Dcmn.lib=”/ ruta/a/librerias/desplegadas”

4.6.2. En tiempo de ejecución

Las librerías que proporciona el servidor están disponibles en el classpath.

Las referencias desde una aplicación a los “Paquetes opcionales” desplegados en el servidor de aplicaciones se hace a través del fichero META-INF\MANIFEST.MF de la aplicación. Los atributos que se deben proporcionar son los siguientes:

Atributo Descripción

Extension-List nombre_logico [...] Identificador obligatorio que define el nombre lógico de la dependencia de un paquete opcional. Podemos indicar múltiples valores para describir la dependencia de diversos paquetes opcionales:

Extension-List: dependencia1 dependencia2

[nombre_logico-]Extension-Name Identificador obligatorio que identifica el nombre de la dependencia de






Atributo Descripción

paquete opcional. Este valor debe coincidir con el atributo Extension-Name definido en el fichero manifest del paquete opcional.

Si estamos referenciando múltiples paquetes opcionales, deberemos definir una entrada Extension-Name para cada uno, anteponiendo el nombre lógico definido que le corresponda. Por ejemplo:

dependencia1-Extension-Name: paqueteOpcional1

dependencia2-Extension-Name: paqueteOpcional2

[logical_name-]Specification-Version Valor opcional para indicar la ‘specification version’ que se necesita de un paquete opcional. Si no se indica, utiliza por defecto el paquete opcional con mayor “specification version”. Si se utiliza el formato de major/minor version para indicar el valor de ‘specification version’, lo que sucede es que se utiliza el paquete que tenga el mayor número de ‘specification version’ que no sea inferior al valor configurado. Si todos los paquetes disponibles en el servidor son inferiores a los valores configurados de ‘specification version’, el despliegue no podría realizarse.

Si no se utiliza la convención de major/minor version para indicar el valor (por ejemplo, 9.2BETA), entonces es necesario que el paquete opcional tenga definido en el atributo Specification-Version de su fichero manifest exactamente el mismo valor para poder utilizarlo.

Si se referencian múltiples paquetes opcionales, se debe anteponer el nombre lógico definido que le corresponda.

[logical_name-]Implementation-Version

Valor obligatorio para indicar la ‘implementation version’ que se necesita de un paquete opcional. Si se utiliza el formato de major/minor version para indicar el valor de “implementation version”, lo que sucede es que utiliza el paquete que tenga el mayor número de ‘implementation version’ que no sea inferior al valor configurado. Si todos los paquetes disponibles en el servidor son inferiores a los valores configurados de ‘implementation version’, el despliegue no podría realizarse.

Si no se utiliza la convención de major/minor version para indicar el valor (por ejemplo, 9.2BETA), entonces es necesario que el paquete opcional tenga definido en el atributo Implementation-Version de su fichero manifest exactamente el mismo valor para poder utilizarlo.

Si se referencian múltiples paquetes opcionales, se debe anteponer el nombre lógico definido que le corresponda.

Por simplicidad, se recomienda utilizar como nombre lógico el mismo valor utilizado en Extension-Name.

Siguiendo con el ejemplo anterior, el fichero META-INF\MANIFEST.MF del EAR generado deberá incluir las referencias a las dos librerías desplegadas como paquetes opcionales:

Extension-List: itext log4j itext-Extension-Name: itext log4j-Extension-Name: log4j itext-Implementation-Version: 1.2.3 log4j-core-Implementation-Version: 1.2.14






4.7. Gestión de excepciones

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

Para ello se deberán capturar las excepciones para detectar los posibles errores y mostrar por pantalla mensajes explicativos orientados al usuario, y en los logs de la aplicación errores claros y concisos con toda la información necesaria para el diagnóstico.

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

4.8. Log de aplicación

Toda aplicación deberá utilizar un sistema de log que escriba en disco los mensajes, generando un fichero por día (rolling diario) para mayor facilidad en caso de necesitarse consultar.

La ruta donde se dejan los ficheros de log será configurable por parametrización en fichero de propiedades. Se utilizará la ruta /logs/app/<cod_app>, siendo <cod_app> el código de aplicación asignado.

El nivel de log, también configurable por propiedades, deberá adecuarse al entorno. En particular, en el entorno de producción no podrá utilizarse un nivel más detallado que ERROR.

No está permitido, en ningún entorno, la escritura de log o cualquier otro mensaje por salida estándar o en otra ruta de la asignada para la aplicación.

NOTA: En los logs de aplicación no está permitido volcar información restringida, como por ejemplo nombres de usuario y contraseñas.

4.8.1. Borrado de logs

Los ficheros de log de aplicación se borrarán automáticamente pasados siete días en los entornos de integración y preproducción, y pasados quince días en producción.

4.9. Ficheros de propiedades

Se deben incluir en ficheros .properties todas las propiedades comunes que se quieran utilizar en la aplicación, evitando así incluir valores fijos en el código fuente.

En la información de despliegue de la aplicación se debe incluir el significado de cada una de las propiedades y cuáles se deben configurar.

Salvo parámetros que el proveedor desconoce y no pueden ser facilitados, como contraseñas o accesos a servicios del Gobierno de Aragón, todos los demás parámetros de los properties deberán contener los valores correctos en cada fichero según el entorno para el que estén definidos.






Para evitar que a partir de un entregable, que corresponde a una versión de aplicación, se deban generar varios ficheros EAR, uno por cada entorno, los ficheros de propiedades que contengan valores que pueden cambiar de un entorno a otro se distribuirán a los servidores de forma independiente, es decir, no se incluirán en el fichero EAR generado.

4.9.1. Ubicación de los ficheros en el entregable

La ubicación de estos ficheros de propiedades en el entregable será dentro del directorio src/conf/properties/ en proyectos web simples o apps/<cod_app>/src/conf/properties/ en proyectos web complejos, y dentro de éste, en un directorio por cada entorno, de nombre des, pre y pro, dentro de los cuales estarán los ficheros necesarios.

Por ejemplo, para la aplicación de código gpz que se entrega como proyecto web simple:

src/conf/properties/des/log4j.properties src/conf/properties/des/gpz.properties src/conf/properties/pre/log4j.properties src/conf/properties/pre/gpz.properties src/conf/properties/pro/log4j.properties src/conf/properties/pro/gpz.properties

4.9.2. Ubicación de los ficheros para distribuir

Tras el proceso de generación del ear, los ficheros de propiedades quedarán en la ruta build/properties/<cod_entorno>/*.properties.

Por ejemplo, para la aplicación de código gpz que se entrega como proyecto web simple:

build/properties/des/log4j.properties build/properties/des/gpz.properties build/properties/pre/log4j.properties build/properties/pre/gpz.properties build/properties/pro/log4j.properties build/properties/pro/gpz.properties

Al desplegar el ear de la aplicación, también se distribuirán los ficheros de propiedades del directorio adecuado al entorno, a una ruta del servidor que se encuentra en el classpath. Dentro de ese directorio, habrá un directorio para cada una de las aplicaciones que lo requiera, de nombre el código de aplicación, que es donde se distribuirán los ficheros properties directamente, sin posibilidad de generar subdirectorios.

Por ejemplo, para la aplicación de código gpz, será una ruta de la forma:

/<ruta_que_esta_en_classpath>/gpz/

4.9.3. Carga de las propiedades desde la aplicación

Para cargar las propiedades desde la aplicación, la referencia a cada fichero de propiedades se hará vía classloader, nunca accediendo a los ficheros mediante filesystem. Para ello, se debe utilizar la ruta relativa desde el directorio de aplicación.

A continuación se muestra un ejemplo de acceso correcto para la aplicación de código gpz:

// Carga del fichero String propertiesName = "/gpz/gpz.properties ";






InputStream in= getClass().getResourceAsStream(prop ertiesName); Properties p = new Properties(); p.load(in); // Extraccion de parametros String datos = p.getProperty("URLAccesoServicioFirm a");

Los cambios realizados en estos ficheros, sólo tienen efecto si se redespliega la aplicación.

4.10. Conexión a base de datos

La conexión a base de datos por parte de las aplicaciones desplegadas sobre WebLogic se realizará siembre a través de uno o varios data-sources definidos a tal efecto en el servidor de aplicaciones, no dentro del ear de la aplicación.

En general, se utilizará un único data-source por base de datos a la que se conecte una aplicación (típicamente, sólo una).

La tecnología de persistencia a más alto nivel se deja a elección del desarrollador. Sin embargo, se recomienda la utilización del estándar Java Persistence API (JPA) para el manejo orientado a objetos del modelo de datos.

4.10.1. Definición de data-source

Para crear el data-source en el servidor de aplicaciones, en el entregable se incluirá un fichero <cod_app>Resources.properties con la siguiente información, en forma campo: valor:

� jdbc_DataSourceName: el nombre del data source: <cod_app>DataSource

� jdbc_DataSourceJNDIName: el nombre JNDI del data source: <cod_app>.<cod_app>DataSource

� jdbc_DataSourceDriver: el driver que se va a utilizar para llevar a cabo las operaciones que permiten una única fase para el manejo de la transaccionalidad: oracle.jdbc.OracleDriver

� jdbc_Tnsnames: cadena de conexión, que incluye el nombre del servicio de base de datos habilitado para la aplicación.

� jdbc_DataBaseUserName: el nombre del usuario de base de datos para realizar la conexión.

� jdbc_DataBasePassword: la contraseña que tiene el usuario de base de datos definido en el punto anterior. Esta información no la proporciona el proveedor.

Por ejemplo, para la aplicación de código gpz, que se conecta a la base de datos MULTIAST, para el entorno de integración:

jdbc_DataSourceName: gpzDataSource jdbc_DataSourceJNDIName: gpz.gpzDataSource jdbc_DataSourceDriver: oracle.jdbc.OracleDriver jdbc_Tnsnames: jdbc:oracle:thin:@BIZ-DESAST11-01.aragon.local:1532/desmultiastsrv.aragon.local jdbc_DataBaseUserName: gpz_usr jdbc_DataBasePassword: ********






�� Relación de cadenas de conexión según base de datos

Se incluye una relación de cadenas de conexión para las bases de datos Oracle.

Se indica el nombre de la base de datos, la versión de Oracle y el entorno (integración, preproducción y producción) que le corresponde, y la cadena de conexión que se debe completar en la propiedad “jdbc_Tnsnames”.

Para las bases de datos Oracle 11g, en entornos de preproducción y producción, <service_name> debe sustituirse por el nombre del servicio de base de datos habilitado para cada aplicación.

Base de datos Versión

Entorno jdbc_Tnsnames

DESAPP1 10g INT jdbc:oracle:thin:@backdes1.aragon.local:1523/desapp1.dga.es

DESAGMA 11g INT jdbc:oracle:thin:@BIZ-DESAST11-01.aragon.local:1530/desagmasrv.aragon.local

DESPAEGA11 11g INT jdbc:oracle:thin:@BIZ-DESAST11-01.aragon.local:1522/paega.aragon.local

DESECOHAC 11g INT jdbc:oracle:thin:@BIZ-DESAST11-01.aragon.local:1531/desecohacsrv.aragon.local

DESMAST 11g INT jdbc:oracle:thin:@BIZ-DESAST11-01.aragon.local:1532/desmultiastsrv.aragon.local

DESEDUCA 11g INT jdbc:oracle:thin:@BIZ-DESAST11-01.aragon.local:1533/deseducasrv.aragon.local

DESSOCSA 11g INT jdbc:oracle:thin:@BIZ-DESAST11-01.aragon.local:1534/dessocsansrv.aragon.local

DESSAE 11g INT jdbc:oracle:thin:@BIZ-DESAST11-01.aragon.local:1535/dessaesrv.aragon.local

DESMDEP 11g INT jdbc:oracle:thin:@BIZ-DESAST11-01.aragon.local:1536/desmdepsrv.aragon.local

PREAPP1 10g PRE jdbc_Tnsnames:jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=vir_backpre1.dga.es)(PORT=1523))(ADDRESS=(PROTOCOL=TCP)(HOST=vir_backpre2.dga.es)(PORT=1523))(LOAD_BALANCE=on)(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=preapp1.dga.es)))

PRE* 11g PRE jdbc:oracle:thin:@pre01-scan.aragon.local:47034/<service_name>

PROAPP1 10g PRO jdbc_Tnsnames:jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=vir_backpro1.dga.es)(PORT=1523))(ADDRESS=(PROTOCOL=TCP)(HOST=vir_backpro2.dga.es)(PORT=1523))(LOAD_BALANCE=on)(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=proapp1.dga.es)))

PRO* 11g PRO jdbc:oracle:thin:@pro01-scan.aragon.local:47017/<service_name>

4.10.2. Ubicación del fichero de definición de data -source en el entregable

La ubicación de estos ficheros de definición de data-sources en el entregable será dentro del directorio src/conf/data-sources/, y dentro de éste, en un directorio por cada entorno, de nombre des, pre y pro. Por ejemplo, para la aplicación de código gpz:

src/conf/data-sources/des/gpzResources.properties src/conf/data-sources/pre/gpzResources.properties






src/conf/data-sources/pro/gpzResources.properties

4.10.3. Ubicación del fichero de definición de data -source para distribuir

Tras el proceso de generación del ear, los ficheros de definición de data-sources quedarán en la ruta build/data-sources/<cod_entorno>/<cod_app>Resources.properties. Por ejemplo, para la aplicación de código gpz:

build/data-sources/des/gpzResources.properties build/data-sources/pre/gpzResources.properties build/data-sources/pro/gpzResources.properties

Al realizar el despliegue de la aplicación, se creará también el data-source en el servidor de aplicaciones con la información proporcionada en el fichero correspondiente al entorno.

4.11. Monitorización de la aplicación

Las aplicaciones deberán incluir una página que responda en la URL:

https://aplicaciones.aragon.es/<cod_app>/test.jsp https://preaplicaciones.aragon.es/<cod_app>/test.js p https://desaplicaciones.aragon.es/<cod_app>/test.js p

para poder invocarla desde la monitorización global, bien de forma permanente o en periodos críticos de uso o cuando se considere necesario. Por compatibilidad con el sistema de monitorización, esta página no puede hacer una redirección a otra, sino que debe devolver respuesta directamente.

La llamada a esta página no devolverá un contenido estático, sino que deberá permitir verificar que la aplicación está funcionando correctamente, realizando para ello las comprobaciones necesarias en función de sus dependencias. Son comprobaciones típicas:

� Conexión a la base de datos de la aplicación

� Conexión a directorio LDAP contra el que autentican los usuarios de aplicación

� Comunicación con sistemas externos de los que la aplicación dependa

La respuesta debe ser un texto con una serie de pares id/valor donde:

� id: identifica la comprobación realizada. Por ejemplo: BD, LDAP, etc.

� valor: OK / KO

El código de la página debe ser lo más ligero posible para no producir una sobrecarga en el servidor de aplicaciones. En particular, no debe incluir información de estilo, javascript, cabeceras ni imágenes.

Para cada posible error (cada respuesta “KO”) el manual de explotación debe indicar la causa, así como el procedimiento para subsanarlo.






No se permitirá en las aplicaciones ningún sistema de monitorización ajeno a los que proporciona Aragonesa de Servicios Telemáticos. En particular, no está permitido enviar información de eventos por correo electrónico, invocación a servicio web externo ni de ninguna otra forma que saque esa información fuera de los sistemas del Gobierno de Aragón. Si una aplicación tiene requerimientos especiales en ese sentido, deberá ser consensuado previamente con AST.

4.12. Ficheros estáticos y temporales

Si la aplicación necesita directorios para ubicar ficheros estáticos o temporales accesibles desde todos los nodos del cluster de servidor de aplicaciones, deberá indicarse en el manual de instalación o despliegue de la aplicación.

Deberán configurarse en la ruta “/compartido/app/<cod_app>/”, siendo <cod_app> el código de aplicación asignado.

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

4.13. Uso de frameworks de desarrollo

Cualquier framework de desarrollo que se quiera utilizar debe ser compatible con los productos detallados en estas especificaciones. Además, es necesario hacer un uso racional de librerías, evaluando si la funcionalidad aportada justifica su carga.

4.14. Herramientas necesarias para desarrollos Java EE

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

4.14.1. Herramienta ANT

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

Las aplicaciones se entregarán preparadas para compilar con la herramienta ANT v1.9.4, incluyendo en la entrega el fichero o los ficheros build.xml correspondiente(s).






5. Documentación de entrega

Toda aplicación deberá entregarse con la siguiente documentación, que deberá actualizarse con cada versión entregada:

�� Información general

Esta información se proporcionará antes de comenzar el desarrollo, para la reserva del código de aplicación, y se completará posteriormente si en ese momento no está completamente definida. Está recogida en la plantilla “CODAPP_InformacionAplicacion.xlt”.

�� Manual de instalación

Deberá incluir obligatoriamente:

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

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

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

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

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

� Dirección URL de comprobación del servicio, y contenido esperado, para dar por válido un despliegue.

� Dependencia con otros módulos, servicios horizontales, plataformas de autenticación, etc.

�� Manual de explotación

Documentación detallada de los posibles procedimientos específicos de explotación de la aplicación Java EE, en caso de que existan y apliquen:

� Procedimientos de operación específicos.

� Requisitos específicos en cuanto a realización de copias de seguridad y procedimientos de recuperación.

� Problemáticas conocidas y detalle de resolución.

� Relación de comprobaciones en la página de test.jsp, la causa en caso de error y el procedimiento para subsanarlo.

Documents

Entorno WebLogic del Gobierno de AragónProducción : Entorno real de ejecución de las aplicaciones. A continuación se define la estructura del entorno de producción, siendo el