3 Despliegue del aplicativo

ANEXO a la Guía de Estándares
Normativa de Empaquetado y
Entrega
1
Índice
1
Introducción _________________________________________________ 4
2
Empaquetado de los entregables ________________________________ 4
3
2.1
Empaquetado de los módulos_____________________________________ 4
2.2
Nombrado de los entregables _____________________________________ 5
2.3
Versionado de empaquetados ____________________________________ 6
2.4
Política de empaquetado de librerías _______________________________ 6
2.5
Elementos a excluir del empaquetado ______________________________ 8
Despliegue del aplicativo ______________________________________ 8
3.1
4
3.1.1
Contenido del EAR __________________________________________________ 9
3.1.2
Contenido del WAR _________________________________________________ 10
3.1.3
Contenido de módulos jar. ___________________________________________ 11
3.1.4
Recursos estáticos __________________________________________________ 11
3.1.5
Archivo con recursos dependientes del entorno __________________________ 11
3.1.6
Documentación ____________________________________________________ 12
3.2
Configuración de contexto ______________________________________ 13
3.3
Despliegues con EJBs ___________________________________________ 13
3.4
Despliegues con Webservices ____________________________________ 13
Configuración para arquitectura IAM WAS _______________________ 13
4.1
Descriptores de despliegue ______________________________________ 13
4.2
Configuración de Carga de clases _________________________________ 15
4.3
Configuración en el servidor WAS relativa a la aplicación ______________ 15
4.3.1
Configuración de la Sesión ___________________________________________ 15
4.3.2
Recarga de clases y JSPs _____________________________________________ 16
4.3.3
Propiedades personalizadas a nivel de servidor __________________________ 16
4.4
5
Componentes de la versión a desplegar _____________________________ 8
Configuración de propiedades específicas de la aplicación _____________ 18
Utilización de recursos ________________________________________ 19
2
5.1
Base de datos _________________________________________________ 19
5.1.1
Filegroup _________________________________________________________ 19
5.1.2
Nomenclatura de ficheros ___________________________________________ 19
5.1.3
Índices ___________________________________________________________ 19
5.1.4
Particionamiento __________________________________________________ 20
5.1.5
Acceso a base de datos desde WAS ___________________________________ 20
5.1.6
Requisitos para la ejecución de scripts _________________________________ 21
5.2
Ficheros de las aplicaciones _____________________________________ 22
3
1 Introducción
El objetivo de este documento es definir la normativa que se debe cumplir para
realizar las tareas de empaquetado y entrega de los aplicativos web J2EE del IAM, así
como permitir su validación antes del proceso de despliegue.
2 Empaquetado de los entregables
2.1 Empaquetado de los módulos
Se usará Maven 3.0.4 como herramienta de construcción de los artefactos.
Debe existir un pom.xml padre en la raíz del proyecto que contenga como mínimo la
siguiente configuración:



Módulos incluidos en el aplicativo.
Librerías del proyecto compartidas por sus módulos.
Java Development Kit (JDK) usado para compilar. Para el despliegue en
WAS 6.1 se debe compilar con JDK 5, mientras que para desplegar en
WAS 8 debemos compilar con JDK 6.
Cada módulo debe disponer también de su propio pom.xml que permite la
compilación y empaquetado de cada módulo.
Para realizar la compilación y empaquetado del aplicativo se ejecutará en la
raíz del proyecto el siguiente comando: mvn clean package. Adicionalmente se
pueden añadir distintas opciones (por ejemplo perfil a usar) que deberán ser indicadas
en la solicitud de auditoría.
Se debe generar al menos un entregable (EAR) correspondiente al aplicativo
que se colocará en la carpeta de despliegues. En caso de contener recursos (estáticos
o de configuración) se debe generar un fichero ZIP con los recursos estáticos y otro
fichero ZIP con los ficheros de configuración por cada entorno. En caso de tener
subsistemas (como puede ser internet e intranet) se crearan un directorio por
subsistema repitiendo el esquema.
A continuación se muestra un esquema donde se puede observar donde se
encuentra cada uno de los elementos descritos en esta apartado. Se supone una
entrega del proyecto CURSO en el tag V01.01.003
4
Ilustración 1. Esquema de la carpeta de despliegues de CURSO
2.2 Nombrado de los entregables
Cada entregable tendrá un nombre del proyecto más la versión a desplegar. La
normativa del proyecto y versión viene definida en el documento general de la Guía de
Estándares.
Los ficheros pom.xml indican la siguiente información:




<groupId> - nombre del paquete o grupo al que pertenece el proyecto.
En general será de la forma es.iam.grupoId, dónde grupoId es
[areaNegocio].[acronimoAplicativo].
<artifactId> - nombre del artefacto a empaquetar que representa.
<version> - versión del aplicativo que debe coincidir con el del
artefacto. No es necesario indicarlo si corresponde a un módulo debido
a que coincide con la versión definido en el pom padre.
<packaging>- indica el tipo de empaquetado: ear, war, jar, pom, ejb...
5
Los módulos JAR, WEB y EJB empaquetados dentro de un EAR deben tener la
misma versión que el EAR. Es obligatorio que el pom.xml que realiza el empaquetado
del EAR contenga la versión a entregar.
2.3 Versionado de empaquetados
Los empaquetados j2ee tienen un fichero especifico META-INF/MANIFEST.MF
que permite especificar propiedades de ese empaquetado (sea jar, war ó ear). Una de
las
propiedades de dicho fichero es "Implementacion-Version" que permite
especificar la versión del aplicativo. Esto permite conocer la versión desplegada de la
aplicación a través de la consola de WebSphere.
2.4 Política de empaquetado de librerías
Solo se podrán usar, y por tanto empaquetar, las librerías aprobadas por el IAM
que se encuentran publicadas en el gestor de artefactos corporativo.
Hay que tener en cuenta que algunas librerías, aunque estén publicadas en el
gestor de artefactos corporativo, solo deben usarse para compilar las fuentes o realizar
pruebas del sistema y por ese motivo no deben estar presentes en el empaquetado
final del aplicativo.
Las siguientes librerías se encuentran ya desplegadas en los servidores WAS
del IAM por lo que no deben ser incluidas en el empaquetado de los aplicativos.

API StandAlone eAS_TSP_v6.2.7

base.jar

classes12.jar

db2java.zip

db2jcc.jar

db2jcc_lidense_cu.jar

msbase.jar

msqlserver.jar

msutil.jar

ojdbc12.jar

ojdbc14_g.jar

ojdbc5.jar
6

spy.jar

sqlsever.jar

util.jar
No se deben tampoco incluir librerías propias de servidores de aplicaciones o
de la jdk, por ejemplo:

ant-antlr-*

core.jar

ffdc.jar

ffdc.jar

ivjejb35.jar

j2ee.jar

jaas.jar

jboss*.jar

jboss*.properties

jcert.jar

jdbc2_0-stdext.jar

jnet.jar

jsse.jar

jstl.jar

jta.jar

namespace.jar

rt.jar

server.jar

servlet.jar

xml.jar
No se deben empaquetar jar necesarios tan solo para realizar las pruebas del
sistema:
7

cactus*.jar

jmock*.jar

jtestcvase*.jar

junit*.jar

mockito*.jar

powermock*.jar

strutstest*.jar
2.5 Elementos a excluir del empaquetado
En este apartado se listan los elementos que no deben estar presentes en el
empaquetado final de ninguno de los módulos de un aplicativo.











Ficheros obsoletos, por ejemplo, con extensión .old
Ficheros duplicados con extensiones diferentes, por ejemplo, .desarrollo
y .producción.
Duplicación de una misma librería (.jar) con diferente versión.
Carpetas y ficheros propios del sistema de control de versiones.
Descriptores o ficheros de configuración propios de otros servidores de
aplicaciones.
Diferentes versiones de descriptores o ficheros de configuración
(web.xml.desarrollo)
Archivos con el código fuente no compilado (.java)
Clases de prueba de la aplicación (por ejemplo JUnit), ni clases que
implementen sentencias assert.
Clases que implementen un método main, puesto que son aplicaciones
WEB y no aplicaciones cliente.
Contenidos estáticos del aplicativo. Ver apartado Recursos estáticos
Archivos de configuración dependientes del entorno. Ver Archivo con
recursos dependientes del entorno
3 Despliegue del aplicativo
3.1 Componentes de la versión a desplegar
En esta arquitectura IAM WAS los artefactos del sistema se van a distribuir
entre los diferentes servidores y recursos. En este apartado se indican los artefactos
que deben formar parte de la versión que se entrega al Dpto. de Tecnologías Web.
8
3.1.1
Contenido del EAR
Solamente se permite el despliegue de artefactos EAR en el servidor WAS.
Consideramos la siguiente estructura estándar de directorios para los
aplicativos EAR:
/Directorio raíz del EAR








WAR 1
…
WAR N
EJB 1
…
EJB N
lib
META-INF
 application.xml
 MANIFEST.MF
Los módulos Web y EJB se empaquetan en el directorio raíz del EAR.
El directorio lib debe contener las librerías compartidas por todos los módulos
empaquetados en el EAR, salvo las librerías compartidas a nivel de servidor definidas
en el apartado Política de empaquetado de librerías.
El fichero META-INF/MANIFEST.MF se genera durante el proceso de
empaquetado realizado con Maven. Debe contener la siguiente información:
Manifest-version : 1.0
Build-Jdk: <Versión del JDK usado para compilar>
Created-By: <uso de Maven como herramienta de empaquetado>
Implementacion-Version : <versión del aplicativo>
El descriptor de despliegue de la aplicación META-INF/application.xml debe
cumplir con la especificación J2EE 1.4 para WAS 6.1 o Java EE 6 para WAS 8. Debe
contener una referencia a los distintos módulos WEB o EJB a desplegar así como el
context root de cada módulo.
Respecto a los descriptores de despliegue, el EAR no debe incluir la carpeta
META-INF/ibmconfig, ya que deberán utilizarse los recursos definidos a nivel de
servidor WAS.
9
El nombre del fichero .EAR tiene que corresponderse con el context root del
módulo Web principal, el cual debe coincidir con el acrónimo de la aplicación y
contexto que se haya indicado en el documento Despliegue de Aplicación Web .
3.1.2
Contenido del WAR
Cada módulo Web (aplicación o servicio web) contenido en el EAR se
empaqueta en un fichero WAR que tendrá la siguiente estructura:
/Directorio raíz del WAR


WEB-INF
 jsp
 classes
 META-INF
 Archivos de configuración independientes del
entorno
 lib
 web.xml
META-INF
 MANIFEST.MF
Los archivos jsp deben estar bajo el directorio WEB-INF/jsp pudiendo este
tener subdirectorios para facilitar el ordenado de las jsp.
El directorio WEB-INF/classes contiene las clases java compiladas así como
los ficheros de recursos propios de la aplicación y no dependientes de entorno.
El directorio lib únicamente debe contener las librerías JAR usadas
exclusivamente por el módulo Web.
El fichero META-INF/MANIFEST.MF debe contener la siguiente información:
Manifest-version : 1.0
Build-Jdk: <Versión del JDK usado para compilar>
Created-By: <uso de Maven como herramienta de empaquetado>
Implementacion-Version : <versión del aplicativo>
El descriptor de despliegue WEB-INF/web.xml debe cumplir
especificación de servlets 2.4 para WAS 6.1 y servlets 3.0 para WAS 8.0
con
la
Cualquier fichero de configuración no dependiente del entorno irá incluido
dentro del directorio WEB-INF.
10
3.1.3
Contenido de módulos jar.
El fichero META-INF/MANIFEST.MF debe contener la siguiente información:
Manifest-version : 1.0
Build-Jdk: <Versión del JDK usado para compilar>
Created-By: <uso de Maven como herramienta de empaquetado>
Implementacion-Version : <versión del aplicativo>
En caso de que el jar contenga en su interior EJB se empaquetaran junto con
su descriptor de despliegue
3.1.4
Recursos estáticos
Podemos considerar recursos estáticos a los archivos html (.htm, .html), los
documentos de ayuda/manuales (.doc, .pdf), las carpetas con hojas de estilo (.css),
carpetas con imágenes (.jpg, .gif, .png) y archivos javascript (.js), etc.
Estos elementos deben entregarse en un archivo ZIP independiente al EAR tal
y como se indica en el apartado Empaquetado de los módulos, pues se
despliegan en el servidor web frontal IBM HTTP Server. Todo lo referente al runtime
de los Applets también tiene que ser entregado conjuntamente con la parte estática y
no con el EAR de la aplicación.
En una aplicación con varios módulos WAR, para poder diferenciar los posibles
context roots, los recursos estáticos deberán ubicarse bajo un directorio con el
identificativo de cada context root.
Al menos se debe incluir una página estática (home.htm, index.htm,...), la cual
será declarada en el descriptor web.xml como welcome file. Dicha página será el punto
de entrada inicial en las aplicaciones que requieren SSL.
3.1.5
Archivo con recursos dependientes del entorno
Si se dispone de ficheros de configuración (.properties, .XML, etc.) y sus
propiedades dependen del entorno en que se encuentra desplegado, se entregarán en
un archivo ZIP adicional tal y como se indica en el apartado “Empaquetado de los
módulos”, que se desplegará en el repositorio de recursos de los servidores WAS. Se
agruparán en una carpeta para su despliegue en preproducción y otra para su
despliegue en producción y cuando dichos recursos se modifican con la actualización
de versión (o es el primer despliegue) deben incluirse en la entrega.
Para aplicaciones a desplegar en plataforma WAS 8 se entregará en un único
fichero, denominado serviciosIAM.properties, todas aquellas propiedades de los
11
servidores IAM y/o acceso a los mismos, a cumplimentar por las unidades de
Sistemas.
Estos ficheros incluyen:

Ficheros con parámetros propios de la aplicación cuyos valores
dependen del entorno

Ficheros con datos de servicios externos (URLs, máquinas, usuarios de
conexión, etc.)

Log4J.properties o similar

Almacenes de certificados propios de la aplicación
Se debe declarar un perfil (profile) en el script de .pom padre que permita el
empaquetado del archivo ZIP para al menos el entorno de preproducción y producción.
Entorno de desa: mvn clean package –P desa
(o mvn clean package ya que es el de por defecto)
Entorno de pre: mvn clean package –P pre
Entorno de pro: mvn clean package –P pro
Para preproducción el perfil tendrá el identificador pre y para producción tendrá
el identificador pro. En caso de crear un perfil para desarrollo su identificador será
desa y este será el perfil por defecto. Así los comandos a ejecutar por entorno serán
como siguen.
Se podrán crear perfiles adicionales siempre y cuando se ejecuten junto con los
perfiles obligatorios. Por ejemplo mvn clean package –P pre,internet.
En el documento Manual Técnico de Despliegue de Aplicación Web, se
deberán indicar los parámetros dependientes de cada entorno, independientemente de
que los ficheros ya contengan dichas modificaciones, ya que se verificará que los
valores son correctos antes de proceder a su despliegue.
3.1.6
Documentación
La documentación a aportar, para solicitar la petición de despliegue de la
aplicación, se encuentra indicada en la guía de estándares en el apartado IAS.
12
3.2 Configuración de contexto
Los context roots deben ser únicos en todo el IAM para evitar problemas de
colisión con otras aplicaciones y se deben evitar contextos estereotipo como
“/servlets”. Para ello, se debe anteponer en el context root los 5 caracteres que se
correspondan con el acrónimo de la aplicación a la que pertenecen.
3.3 Despliegues con EJBs
Se prohíbe la utilización de EJB 2.x., que requiera generación de clases y
despliegues. En caso de ser necesario su uso deberá ser justificado y se indicará en el
documento “Manual Técnico de Despliegue de Aplicación Web” de la aplicación. Este
documento deberá indicar que la aplicación requiere el despliegue de los EJBs.
3.4 Despliegues con Webservices
La Guía de Estándares define pautas específicas para el desarrollo de servicios
web para el IAM en su anexo “Manual de Servicios Web”
En el documento “Manual Técnico de Despliegue de Aplicación Web” se debe
indicar que la aplicación requiere el despliegue de los servicios web, para que en la
instalación de dicho EAR se marque el despliegue de los mismos.
4 Configuración para arquitectura IAM WAS
4.1 Descriptores de despliegue
Los descriptores de despliegue son los ficheros XML normalizados que
contienen información como el context root de la aplicación web, la declaración de los
recursos de la aplicación (datasources, url,...), los módulos EJBs y Web, etc.
A parte de los descriptores application.xml y web.xml, el EAR a implantar en la
plataforma IAM debe incluir los descriptores necesarios para el despliegue en el
servidor WAS. Las propiedades que se indiquen en ellos para el despliegue de la
aplicación, serán comprobadas en la instalación. Si dichas propiedades no han sido
justificadas en el documento “Manual Técnico de Despliegue de Aplicación Web”,
pueden ser ignoradas o cambiadas en su instalación.
En concreto, se ignorarán las propiedades de los descriptores bajo la carpeta
META-INF\ibmconfig del EAR, ya que deberán utilizarse los recursos definidos a nivel
de servidor WAS.
13
Con respecto a las propiedades de despliegue de los módulos Web se
recomienda tener configurado en a los descriptores application.xml y web.xml los
siguientes elementos:

<display-name> (application.xml): debe coincidir con el contexto de la
aplicación, es decir, si hay varios módulos war indíquese el que se
considere como principal.

<context-root>: identificativo de la aplicación y proyecto; se
recomienda que el contexto de todos los módulos de las aplicaciones
del mismo proyecto comiencen por 3-4 letras relativas al mismo, por
ejemplo: GITE, GITE_INF, GITE_WS

<servlet-mapping>: mapeo de URLs a servlets

<welcome-file-list>: al menos debe declararse la página estática de
inicio entregada con los componentes estáticos, fundamentalmente si
se trata de aplicaciones que requieren SSL

<error-page>: mapeo de errores 4xx y 5xx a una página personalizada
de la aplicación

<resource-def>: para definición de los pool de conexiones a base de
datos, recursos URL, etc.
Respecto al descriptor ibm-web-ext.xmi de WAS, localizado en el directorio
WEB-INF del WAR, se tendrá en cuenta:

fileServingEnabled="false":deshabilita el servicio de páginas

serveServletsByClassnameEnabled="false": los servlets deben
servirse solamente a través de una URI Referente, sin embargo, si esta
propiedad está habilitada, el servlet puede ser invocado especificando
el nombre de la clase. Por motivos de seguridad, esta propiedad debe
de estar a false.

reloadingEnabled="false": deshabilitar la recarga de clases a nivel de
Web Module. En el servidor WAS esta recarga se habilita a nivel de
aplicación cuando es necesario.

jspAttributes reloadEnabled="false": específica si se habilita la
recarga de clases cuando un JSP es modificado. En el servidor WAS
esta recarga se habilita a nivel de aplicación cuando es necesario
No deberán entregarse descriptores propios de otros servidores de
aplicaciones (jboss-web.xml, etc.). También debe tenerse especial cuidado en no
entregar diferentes versiones de los descriptores (web.xml.desarrollo) o ficheros
obsoletos de los mismos (web.xml.old).
14
4.2 Configuración de Carga de clases
El classloader mode de la aplicación se recomienda que sea en modo
PARENT_FIRST, lo que implica la utilización de las librerías ya disponibles en WAS
siempre que sea posible, evitando sobrecargar la memoria del servidor java con clases
en exceso, pero se admite también carga de clases PARENT_LAST.
Por otra parte, si hay más de un módulo WEB, se recomienda que la política
del WAR esté a nivel de MODULE y en ese caso debe incluirse en la documentación
la carga de clases a aplicar en cada módulo.
4.3 Configuración en el servidor WAS relativa a la aplicación
Los parámetros que afecten al rendimiento de las aplicaciones desplegadas se
deben configurar a nivel de servidor y no ir embebidos en el código de la aplicación.
Esto tiene un doble objetivo:

La normalización del procedimiento de configuración

El cambio dinámico de las propiedades.
Teniendo en cuenta que varias aplicaciones van a compartir el mismo servidor
WAS, cualquier parámetro que una aplicación necesite cambiar a nivel de servidor,
debe de ser acordado y aprobado de antemano.
4.3.1
Configuración de la Sesión
No se debe incluir información sobre tiempo de sesión en el descriptor web.xml.
Este dato se configura a nivel de aplicación en el servidor WAS: Tiempo de expiración
de la sesión. El valor por defecto será de 30 minutos. No debe indicarse en el fichero
web.xml ni modificarse por código este valor, pues de esta forma, en el servidor WAS
se podrá modificar convenientemente el valor para la aplicación ya desplegada.
Por defecto los servidores de IAM no tendrán habilitada la réplica de sesión
para evitar utilizar procesamiento y recursos innecesarios por el propio aplicativo, ya
que esta opción incide en el rendimiento de la aplicación y puede ocasionar problemas
serios de gestión de la memoria. En el caso de que la aplicación necesite dicha
replica, habrá que indicarlo en el documento “Manual Técnico de Despliegue de
Aplicación Web” y asegurarse de:

Que si se utiliza HTTPSession, todo lo que esté incluido sea serializable.

El tamaño de HTTPSession debe reducirse al máximo.
15
4.3.2
Recarga de clases y JSPs
Aunque en el descriptor ibm-web-ext.xmi, localizado en el WEB-INF de la
aplicación, se hayan incluido los atributos relativos a la recarga de clases, estos serán
ignorados y configurados en el servidor WAS.
En el entorno de desarrollo se habilitará la recarga de clases a nivel de Web
Module, así como la recarga cuando un JSP es modificado. Además, se proporcionará
un procedimiento automático de parada-despliegue-arranque de la aplicación.
Sin embargo, en los entorno de preproducción, formación y producción la
recarga de clases y JSPs estará deshabilitada, pues no se realizan despliegues de
componentes aislados. Por defecto, tampoco se realizará una precompilación de JSP
en el despliegue de las aplicaciones para minimizar el tiempo de parada de servicio.
De ser necesaria la recarga de los JSP, debe ser expresamente documentado en el
Manual Técnico de Despliegue.
4.3.3
Propiedades personalizadas a nivel de servidor
En determinadas circunstancias puede ser necesario especificar propiedades
personalizadas que modifiquen el comportamiento por defecto del contenedor Web del
servidor de aplicaciones.
Análogamente, las propiedades personalizadas en la JVM se utilizan para
modificar el comportamiento de la JVM así como definir variables específicas que
estarán disponibles para su uso por las aplicaciones desplegadas en el servidor de
aplicaciones.
Algunas de estas propiedades ya están incorporadas por defecto en los
servidores de la plataforma IAM WAS, pero otras deben solicitarse expresamente y su
incorporación se realizará una vez esté aprobado el cambio, dado que afecta a todas
las aplicaciones en el servidor.
NIVEL
PROPIEDAD
PERSONALIZADA
USO
POR DEFECTO
Contenedor
WEB
com.ibm.ws.webcontainer.
Esta propiedad permite invocar
filtros en las peticiones que no
tienen definido un mapeo a un
servlet.
Sin
esta
propiedad
configurada,
WAS
comprobaría
primero si la URL está mapeada a
un servlet o a un fichero antes de
enviar las peticiones a la cadena de
filtros, de modo que se produciría
un error 404 si no existiera esta
No activa
invokefilterscompatibility
16
propiedad
Contenedor
WEB
com.ibm.ws.webcontainer.
Contenedor
WEB
com.ibm.ws.webcontainer.
Contenedor
Web
HttpSessionIdReuse
Esta propiedad determina si el
gestor de sesiones puede usar el
identificador de sesión enviado del
navegador para preservar los datos
a través de aplicaciones Web que se
están ejecutando en un mismo
dominio.
No activa
JVM
WAS61_RECURSOS
Esta propiedad se usa desde los
aplicativos para conocer la ruta de
los recursos de las aplicaciones.
Activa
Esta propiedad se usa desde los
aplicativos para conocer la ruta de
los ficheros de logs de las
aplicaciones
Activa
Esta propiedad permite conocer el
nombre del servidor de aplicaciones
en el que se está ejecutando la
aplicación. Este nombre puede
usarse
como
parte
de
la
nomenclatura de ficheros NAS.
Activa
Configuración
de
proxy
para
llamadas a servicios externos al
IAM.
No activa
disallowAllFileServing
disallowserveservletsbyclassna
me
WAS8_RECURSOS
JVM
WAS61_LOGS
WAS8_LOGS
JVM
WAS61_SERVER_NAME
WAS8_SERVER_NAME
JVM
http.nonProxyHosts (ó https)
http.proxyHost
Esta propiedad impide que las
aplicaciones
puedan
servir
contenido estático desde el servidor
de
aplicaciones,
independientemente de la propia
configuración de la aplicación. Todo
este tipo de contenido se deber
proporcionar a través del servidor
Web
Activa
Esta propiedad impide
puedan invocar a los
directamente a través del
de la clase para evitar
riesgos de seguridad.
Activa
que se
servlets
nombre
posibles
http.proxyPort
http.proxySet
En el Manual Técnico de Despliegue se especificarán los valores que deben
asignarse para cada uno de estos parámetros cuando no sean los valores por defecto.
17
Estos valores pueden variar entre el entorno de desarrollo y producción, pero siempre
deberán indicarse los que correspondan al entorno de producción, los cuales serán
aplicados también en el entorno de preproducción
4.4 Configuración de propiedades específicas de la aplicación
La especificación J2EE o Java EE recomienda acceder siempre a los recursos
externos mediante un Resource Manager, y en concreto, para los ficheros de
configuración propios de la aplicación, la forma adecuada es definirlos mediante URLs
gestionadas por el URL Resource Manager. Estos recursos URL deben ser creados en
el WAS la primera vez que se necesite por la aplicación y podrán ser reutilizados por el
resto de aplicaciones del proyecto. Es el caso de la dirección URL del webService de
uWeb, que ya está definido a nivel de servidor WAS y por tanto disponible para que
todas las aplicaciones tengan dicha información independizada del entorno.
La configuración de parámetros de la aplicación dependientes del entorno
seguirá estas pautas:

URLs generales del IAM, por ejemplo dirección del webService de uWeb: se
utilizarán recursos URL creados en el WAS.

URLs específicas de la aplicación, por ejemplo, llamadas a webservices
creados en el ámbito del proyecto: se agruparán en uno o varios ficheros
.properties o .xml.

Parámetros propios de la aplicación: se agruparán en uno o varios ficheros
.properties o .xml.

Direcciones de los recursos NAS propios de la aplicación: se incluirá ese dato
dentro de un fichero de propiedades

Ficheros de configuración de trazas (log4j.properties, etc.): se ubicarán junto
con los ficheros de propiedades.
Los ficheros de propiedades se ubicarán en un repositorio único de la
plataforma WAS y se accederá a ellos mediante el recurso URL url/miAplicacion, único
para cada aplicación.
Para aplicaciones a desplegar en plataforma WAS 8 se entregará en un único
fichero, denominado serviciosIAM.properties, todas aquellas propiedades de los
servidores IAM y/o acceso a los mismos, a cumplimentar por las unidades de
Sistemas.
18
5 Utilización de recursos
5.1 Base de datos
En lo relativo a base de datos se deben seguir las siguientes indicaciones tanto
a la hora de solicitar su creación como para acceder a ella desde una aplicación
desplegada en un servidor WAS.
5.1.1
Filegroup
La base de datos deberá tener definidos de forma obligatoria para el entorno
productivo los siguientes filegroup’s:





PRIMARY para albergar las tablas del sistema
FG_DATAnn para albergar tablas de datos. (nn >=01 <=99)
FG_IMGnn para albergar imágenes (si las hubiere).
FG_TEXnn para albergar textos (si los hubiere).
FG_INDnn para albergar índices no cluster.
5.1.2
Nomenclatura de ficheros
A la hora de crear la base de datos los nombres de los ficheros de base de
datos serán similares a:





G:\nombre_bd\Datos\primary_01.mdf
G:\nombre_bd\Datos\Nombre_fichero_data01.ndf
G:\nombre_bd\Imagenes\Nombre_fichero_img01.ndf
G:\nombre_bd\Indices\Nombre_fichero_ind01.ndf
G:\nombre_bd\Log\Nombre_fichero_log01.ldf
5.1.3





Índices
Todo índice no cluster deberá ubicarse en los file groups (FG_INDnn) definidos
para ello.
No definir índice por la clave primaria, pues la definición de la clave primaria ya
lleva implícita la creación de un índice.
Definir índices por las columnas sobre las cuales haya definida una relación de
integridad (foreign key).
Si se crean índices por varias columnas colocar primero la columna que sea
más selectiva, es decir, por la que no se repitan mucho los valores y después
las menos selectivas.
Los índices sobre columnas que tiene mucha información duplicada no son
eficientes.
19

Defina índices clustered si necesita hacer consultas sobre un rango de valores
u ordenar datos por medio de GROUP BY u ORDER BY.
5.1.4
Particionamiento
En aquellas tablas en las que se estime un número muy elevado de filas, del
orden de más de 1 millón, deberá implementarse el particionamiento de la misma
habilitando para ello la definición de función y esquema de particionamiento.
5.1.5
Acceso a base de datos desde WAS
Los servidores de Bases de Datos corporativos sobre los que las aplicaciones
desplegadas en entorno WAS deben trabajar fundamentalmente son SQL Server 2005
y Oracle 10g. En cualquier caso, los proveedores de datos para SQL Server que
deben utilizarse serán los incluidos en el servidor de aplicaciones para la versión WAS
6, debiéndose utilizar los drivers JDBC que proporciona Microsoft para la versión WAS
8:


WAS 6:
o WebSphere embedded ConnectJDBC driver for MS SQL Server (SQL
Server 2000 y 2005)
o Oracle JDBC Driver (Oracle 9 ó 10)
o DB2 Universal JDBC Driver Provider (DB2 v7 y v8)
o DB2 UDB for iSeries (Toolbox) (AS400)
WAS 8:
o Microsoft SQL Server JDBC Driver 2.0 / 3.0 (SQL Server 2000 y 2005)
o Oracle JDBC Driver (Oracle 9 ó 10g)
o DB2 Universal JDBC Driver Provider (DB2 v7, v8 y superiores)
o DB2 UDB for iSeries (Toolbox) (AS400)
Para el acceso a la base de datos las aplicaciones deberán hacer referenciar a
un recurso de tipo datasource creado a nivel de célula WAS, ofreciendo las ventajas
de los pool de conexiones gestionado por el propio servidor WAS. Esto significa que la
aplicación no debe incluir en su empaquetado librerías de proveedores para acceso a
las bases de datos, ni se deberán abrir conexiones directamente a la base de datos
sino haciendo uso de las conexiones proporcionadas por el pool definido en el
datasource del servidor WAS.
El fichero en el que queda reflejado esta referencia es el descriptor web.xml:
<resource-ref id="ResourceRef_1256212520375">
<description> breve descripción sobre la BD a la que se asociará </description>
<res-ref-name>jdbc/miDatasource</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
<res-sharing-scope>Shareable</res-sharing-scope>
</resource-ref>
20
Puesto que estos recursos pueden ser compartidos por las aplicaciones
desplegadas en la célula, se tendrá que estimar si una nueva aplicación puede o no
compartir el recurso ya creado, si debe ampliarse la capacidad de conexiones
máximas a base de datos o si necesita una configuración de parámetros específicos.
Todo ello debe venir debidamente documentado en el documento “Despliegue de
Aplicación Web”. En cuanto a la configuración de estos datasource:






El nombre JNDI del recurso seguirá el patrón jdbc/<nomBD>.
Debe indicarse si se precisa transacciones del tipo XA o no.
Nº mínimo de conexiones: por defecto se establecerá a 1.
Nº máximo de conexiones: por defecto a 10, se recomienda no superar las 30.
Tiempo de espera por la conexión: por defecto a 180 milisegundos.
Statement cache size: Especifica el número máximo de statements que puede
ser cacheado por conexión. Si la statement cache no es lo suficientemente
grande, es posible que ciertas ejecuciones de PrepareStatement y
CallableStatement sean desechadas para incluir otras nuevas. Hay que tener
en cuenta que este parámetro mejora el rendimiento de la aplicación, pero que
puede afectar a otros recursos como es la memoria.
 Nivel de aislamiento: propiedad personalizada que se configurará cuando
venga justificado en el documento “Manual Técnico de Despliegue de
Aplicación Web”
Respecto a los datos de autenticación utilizado para la conexión con la base de
datos:
 Los usuarios de autenticación para la conexión se definirán a nivel de servidor
WAS, pudiéndose crear más de un usuario para corresponderse con diferentes
perfiles de permisos en base de datos:
o La nomenclatura para usuarios con permisos de lectura/escritura
seguirá el patrón <nombreBD>WEB
o La nomenclatura para usuarios de sólo lectura seguirá el patrón
<nombreBD>DES
 El usuario será distinto del propietario de la base de datos u esquema Oracle,
definiendo en base de datos los permisos adecuados para cada perfil de
acceso.
 El usuario a utilizar para conectividad desde la aplicación web debe ser distinto
al utilizado desde procesos batch o aplicaciones cliente.
5.1.6
Requisitos para la ejecución de scripts
Los scripts entregados para su ejecución en bases de datos de los entornos de
preproducción y/o producción deberán incluir el lenguaje bajo el cual se van a ejecutar.
Por lo tanto deberá especificarse en cada script la siguiente sentencia: SET
LANGUAGE SPANISH ó SET LANGUAGE ENGLISH según corresponda para la
correcta ejecución del mismo.
21
En caso de utilizar gestor de base de datos Oracle (previa autorización del
comité de estándares), es imprescindible especificar el idioma, territorio y set de
caracteres de la base de datos. Por ejemplo, SPANISH, SPAIN y WE8ISO8859P1,
respectivamente.
5.2 Ficheros de las aplicaciones
No se debe hacer uso del disco local del servidor WAS generando documentos
desde las aplicaciones, lo que conlleva problemas de espacio y paralización del
servicio. Por el mismo motivo, no se puede usar el NAS propio de la plataforma
WAS ya que derivaría igualmente en una parada de los servicios.
Por ello, las aplicaciones a desplegar en WebSphere deberán venir
preparadas para trabajar con carpetas contenedoras NAS propias del aplicativo.,
aplicándose en la generación de:

Ficheros de traza de la aplicación a nivel INFO o DEBUG

Ficheros temporales generados por la aplicación, incluidos los ficheros
temporales de cualquiera de los frameworks o librerías de terceros que utiliza
la aplicación (AXIS, etc.)

Ficheros de tipo plantillas o formularios generados por la aplicación

Informes que se almacenen en disco

Archivos documentales o imágenes generados o almacenados por la aplicación
La dirección al recurso NAS deben configurarse mediante un recurso URL
del servidor WAS o en alguna propiedad incluida en los ficheros propios de la
aplicación, permitiendo su modificación en función del entorno de físico de ejecución
sin necesidad de alterar el EAR.
El recurso NAS será gestionado por el Dpto. de Desarrollo solicitante del
mismo, por lo que la política de borrado de ficheros o ampliación del espacio debe
asumirse dentro de dicha gestión. En cualquier caso, la aplicación puede verse
afectada si se queda sin espacio en dicho recurso, por lo que recomendamos:

Los ficheros temporales deben ser borrados por la propia aplicación lo
antes posible o en su defecto tener un mecanismo de borrado a través de
un proceso (batch) periódico.

El tamaño total de los ficheros temporales, documentales, de trazas, etc.,
no debe de superar nunca el tamaño máximo pedido en el entorno de
22
ejecución para cada aplicación. Para ello, la aplicación debe acotar
mediante configuración el tamaño de los ficheros y controlar las
excepciones por falta de espacio.

Obsérvese la importancia de diferenciar el servidor de origen en el nombre
del fichero pues si pudiera darse un conflicto en la arquitectura en cluster:
WAS 6: System.getProperty("WAS61_SERVER_NAME"));
WAS 8: System.getProperty("WAS8_SERVER_NAME"));
23