Daw03 Serv Aplic
Daw03 Serv Aplic
Daw03 Serv Aplic
Contenido
1.- Protección del servidor de aplicaciones. ........................................................................................... 2
2.- Despliegue de aplicaciones en Tomcat. ............................................................................................ 4
2.1.- Creación de una aplicación web. .............................................................................................................5
2.2.- Despliegue de una aplicación web. ..........................................................................................................6
2.3.- Implementar el registro de acceso...........................................................................................................7
2.4.- Sesiones persistentes. .............................................................................................................................8
2.5.- Configurar Tomcat en cluster. .................................................................................................................9
3.- El servidor de aplicaciones JBoss. .................................................................................................... 11
3.1.- Instalación y configuración básica. ........................................................................................................12
3.2.- Despliegue de aplicaciones empresariales. ............................................................................................13
3.3.- Estructura de carpetas de una aplicación empresarial. Archivo EAR. .....................................................15
4.- Construcción y despliegue automático con Ant. ............................................................................. 16
4.1.- Instalación y configuración de Ant. ........................................................................................................17
4.2.- El archivo build.xml. ..............................................................................................................................18
4.3.- El objetivo .jar. ......................................................................................................................................19
4.4.- Despliegue de un archivo WAR. .............................................................................................................20
5.- El gestor de aplicaciones Web de Tomcat. ...................................................................................... 23
5.1.- Configuración del gestor. .......................................................................................................................23
5.2.- Conexión al gestor de aplicaciones web de Tomcat de forma remota. ...................................................24
5.3.- Incluir tareas Ant en Tomcat. .................................................................................................................25
Configuración y administración de servidores de aplicaciones Tema 3
Configuración y administración de
servidores de aplicaciones.
Caso práctico
En la empresa BK programación, Ada, junto con sus empleados Juan y María se ha reunido para
evaluar la posibilidad de configurar uno o dos servidores de aplicaciones para instalar en ellos demos,
o versiones beta (también denominado "betatest", indica un periodo en el que un software está técnicamente acabado, lo
cual significa que no se le añadirán de momento más funciones, y presumiblemente será lo suficientemente estable para
trabajar con normalidad. En contraste, la versión alfa, versión anterior a la beta, es más inestable y no está completa), de las
aplicaciones que desarrollan, de esta manera los clientes, o potenciales clientes, podrían probar los
productos de BK programación antes de adquirirlos.
Como resultado de dicha reunión han concluido que, previo paso a la instalación y puesta en
funcionamiento de servidores de aplicaciones, sería muy importante evaluar muchos parámetros que
afectarían al correcto funcionamiento de los servidores, además de las necesidades de los mismos.
Entre los parámetros a evaluar cabe destacar los siguientes:
Seguridad de los servidores de aplicaciones: medidas de seguridad a aplicar para evitar posibles
ataques o intrusiones.
Dimensionamiento del servidor donde se estudian las necesidades físicas del equipo servidor.
Tipo de servidor a instalar, características específicas del software de servidor seleccionado
(Tomcat, Jboss, etc.).
Despliegue de aplicaciones en el servidor donde habría que establecer qué herramientas se
deberían utilizar.
Administración de las conexiones remotas a los servidores.
Escalabilidad de los servidores, a tener en cuenta en función del número de conexiones
simultáneas que se pueden establecer.
Herramientas de automatización de tareas en el servidor (Ant, etc.).
Debido a la cantidad de parámetros que hay que administrar para poner en correcto funcionamiento
los servidores de aplicaciones, Ada ha decidido que sus empleados se documenten de todos y cada
uno de ellos y, si cabe, la posibilidad realizar algún curso de formación sobre la administración de
servidores de aplicaciones.
-1-
Despliegue de Aplicaciones Web José Luis Comesaña DAW
Un servidor de aplicaciones es, usualmente, un software que proporciona una serie de servicios de
aplicación a un número indeterminado de computadoras cliente que acceden a dichos servicios vía
web; las principales ventajas de este tipo de tecnología es la centralización y disminución de la
complejidad en el desarrollo de aplicaciones, sin embargo las aplicaciones web están así más
expuestas a ataques.
Hoy en día existen aplicaciones web para casi todo y que tienen acceso a información muy valiosa
como, por ejemplo, números de tarjetas de crédito, cuentas bancarias, historiales médicos,
información personal, etc. Con lo cual, representan un objetivo interesante al que atacar; estos
ataques se pueden clasificar en base a tres niveles:
Ataques a la computadora del usuario (cliente).
Ataques al servidor.
Ataques al flujo de información que se transmite entre cliente y servidor.
En cada uno de los niveles anteriores es necesario garantizar una seguridad mínima para conseguir la
seguridad de todo el proceso. A nivel de usuario éstos deben contar con navegadores y plataformas
seguras, libres de virus; a nivel del servidor hay que garantizar que los datos no sean modificados sin
autorización (integridad) y que sólo sea distribuida a las personas autorizadas (control de acceso) y,
en lo que se refiere al tránsito de la información, ésta no debe ser leída (confidencialidad),
modificada o destruida por terceros, al mismo tiempo que hay que garantizar un canal de
comunicación fiable que no se interrumpa con relativa facilidad.
Para conseguir aplicaciones web seguras hay que establecer mecanismos que garanticen:
Autenticación: permite identificar, en todo momento, quién es el usuario que está accediendo.
Para conseguirlo existen varios métodos:
Autenticación básica: solicitud de usuario y clave.
Autenticación con certificados.
HTTP DIGEST AUTH (HTTP Autenticación de texto implícita).
HTTP NTLM AUTH (HTTP Autentication Microsoft NT Lan Manager).
Autorización: permite, una vez autenticado, determinar a qué datos y módulos de la aplicación
puede acceder el usuario.
Validación de entradas, ya que se puede manipular el código de validación del lado del cliente.
Inyección de comandos SQL: técnica para explotar aplicaciones web que no validan la
información suministrada por el cliente para generar consultas SQL peligrosas.
Para conseguir aplicaciones web seguras hay que utilizar una serie de mecanismos y herramientas
entre las cuales destacamos:
Deshabilitación de servicios y cuentas no utilizadas.
Actualización del sistema operativo y aplicaciones (parches (Cuando se aplica asociado a software, se trata de
un conjunto de ficheros adicionales al software original de una herramienta o programa informático. Normalmente sirven para
solucionar alguna posible carencia, vulnerabilidad, o defecto de funcionamiento)).
Fortaleza en las contraseñas.
Utilización de Firewalls.
Back-ups periódicas.
-2-
Configuración y administración de servidores de aplicaciones Tema 3
Análisis periódico de logs (registro oficial de eventos durante un rango de tiempo en particular. Para los profesionales en
seguridad informática es usado para registrar datos o información sobre quién, qué, cuándo, dónde y por qué un evento ocurre para
un dispositivo en particular o aplicación).
Verificación periódica de servicios activos.
Cifrado del tráfico.
Establecimiento de políticas de seguridad.
Esta web surge con el objetivo de concienciar y ayudar a la gente para aumentar la seguridad
en la red, en ella aparece, de forma actualizada, amenazas, ataques, recomendaciones de
seguridad, etc.
http://www.seguridadenlared.org/
-3-
Despliegue de Aplicaciones Web José Luis Comesaña DAW
Una aplicación web puede ser desplegada empleando uno de los siguientes métodos:
Por medio de archivos WAR .
Editando los archivos web.xml y server.xml , este método es el que se pasa a tratar a
continuación.
Los directorios que forman una aplicación compilada suelen ser: www , bin , src , tomcat , gwt-cache .
La carpeta www contiene a su vez una carpeta, con el nombre y ruta del proyecto, que contiene los
ficheros que forman la interfaz (HTML, js, css...). La carpeta bin contiene las clases de java de la
aplicación.
-4-
Configuración y administración de servidores de aplicaciones Tema 3
6. Copiar el contenido de la carpeta bin de la aplicación en el subdirectorio WEB-INF/classes del
Tomcat.
7. Crear en WEB-INF un fichero de texto llamado web.xml , con las rutas de los servlets utilizados en
la aplicación.
8. Ya puede accederse a la aplicación en el servidor, el modo de hacerlo es poniendo en el
navegador la ruta del fichero HTML de entrada, que estará ubicado en la carpeta de la aplicación
en Tomcat.
Vamos a partir de una máquina con el sistema operativo Debian 6.0.1 en la cual tenemos el servidor
Tomcat corriendo para mostrar el proceso creación y despliegue de aplicaciones. Debido a que
pretendemos montar una plataforma LAMP , por sus ventajas derivadas de las características del
software libre, instalaremos también los siguientes componentes: MySql y PHP .
Recordemos, en primer lugar destacar que, para instalar cualquier versión de Tomcat es necesario
tener instalado JDK (Kit de desarrollo de Java), ya que el objetivo es que las peticiones a Apache se
redirijan a Tomcat empleando un conector proporcionado por Java en este caso.
El servidor de aplicaciones Tomcat cuenta con una serie de ejemplos, tanto de servlets como de JSP,
que sirven de ayuda para aprender a realizar las tareas creación y despliegue de aplicaciones web.
Es muy interesante crear dos variables de entorno: JAVA_HOME que indique la ubicación de los archivos
binarios de Java y CATALINA_HOME que apunta a la ubicación de los scripts (archivo de órdenes o archivo de
procesamiento por lotes, es un programa usualmente simple, que por lo regular se almacena en un archivo de texto plano) de Tomcat,
para ello podemos añadir el siguiente código al archivo /etc/profile .
CATALINA_HOME=/usr/local/apache-Tomcat-6.0.32/
JAVA_HOME=/usr/lib/jvm/java-6-openjdk/jre/
PATH=$PATH:$JAVA_HOME/bin:$CATALINA_HOME
export PATH JAVA_HOME CATALINA_HOME
El lenguaje Javascript se ejecuta del lado del cliente, es un lenguaje interpretado de scripting que no
permite acceder a información local del cliente ni puede conectarse a otros equipos de red.
En primer lugar crearemos una carpeta con el nombre que nos interese para
identificar la aplicación, en este ejemplo hemos optado por Aplic_Web una
estructura como la de la siguiente imagen:
La aplicación que pretendemos desarrollar contiene un archivo al que llamaremos index.jsp muy
sencillo con el siguiente contenido:
<html>
<head><title>C.F. DESARROLLO DE APLICACIONES WEB</title>
<script language="Javascript">
function popup(){
alert("U.T. 3: CONFIGURACION Y ADMINISTRACION DE SERVIDORES DE APLICACIONES");
}
</script>
-5-
Despliegue de Aplicaciones Web José Luis Comesaña DAW
</head>
<body>
<h1 align=center>DESPLIEGUE DE APLICACIONES WEB</h1>
<div align=center>
<form>
<input type="button" value="UNIDAD 3" onclick="popup()">
</form>
</div>
</body>
</html>
para acabar, solamente nos quedaría hacer una copia de la carpeta de nuestra aplicación en
$CATALINA_HOME/webapps y si, posteriormente desde un navegador, accedemos en local a
http://127.0.0.1:8080/Aplic_Web tendríamos la aplicación funcionando.
Los WARs simplemente son archivos Java de una aplicación web con una extensión diferente para
diferenciarlos de los comunmente usados JARs.
Antes de la especificación Servlet 2.2, era bastante diferente desplegar servlets entre diferentes
contenedores de servlets, anteriormente también llamados motores servlet. La especificación 2.2
estandarizó el despliegue entre contenedores, llevando así la portabilidad del código Java un paso
más allá.
El método más sencillo para desplegar una aplicación, que sobre todo se utiliza durante la etapa de
desarrollo de la misma, es el realizado en el punto anterior, es decir, copiar la carpeta
correspondiente a nuestra aplicación en la carpeta $CATALINA_HOME/webapps , teniendo en cuenta que
la variable $CATALINA_HOME es la ruta de los scripts que emplea Tomcat.
Siguendo con la aplicación desarrollada en el punto anterior ( Aplic_Web ), vamos a crear un fichero
descriptor del despliegue web.xml que es el encargado de describir las características de despliegue
de la aplicación.
<?xml version="1.0" encoding="ISO-8859-1"?>
<web-app xmlns="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
version="2.5">
Una vez consideramos terminada nuestra aplicación web podremos generar el archivo .WAR
perteneciente a la aplicación, para ello podemos aplicar los siguentes comandos:
-6-
Configuración y administración de servidores de aplicaciones Tema 3
#javac -d WEB-INF/classes *.java este comando tiene como finalidad la compilación de las clases
Java de nuestra aplicación.
#jar cvf Aplic_Web.war WEB-INF para crear el archivo .WAR .
Para conseguir obtener y poder configurar los registros de acceso a un servidor de aplicaciones
Tomcat, como es nuestro caso, empezaremos hablando de las válvulas de registro de acceso de
Tomcat, ya que será el método que emplearemos.
Las válvulas del Tomcat son una tecnología introducida a partir de Tomcat 4 que permite asociar una
instancia de una clase Java a un contenedor " Catalina ". Esta configuración permite que la clase
asociada actúe como un pre-procesador de las peticiones. Estas clases se llaman válvulas, y deben
implementar la interfaz " org.apache.catalina.Valve " interface o extender de la clase
" org.apache.catalina.valves.ValveBase ". Las válvulas son propias de Tomcat y no pueden ser usadas
en otros contenedores de servlet.
-7-
Despliegue de Aplicaciones Web José Luis Comesaña DAW
Request Dumper : es una herramienta de depuración que escribe en el log el detalle de cada
petición realizada.
<Valve className="org.apache.catalina.valves.RequestDumperValve"/>
Cualquier acceso a localhost:8080 tendrá asociado una serie de entradas en los logs.
Single Sign On : cuando queremos que los usuarios puedan identificarse en cualquier aplicación
de nuestro virtual host, y que su identidad sea reconocida por cualquier aplicación que esté en
ese host.
<Valve className="org.apache.catalina.authenticator.SingleSignOn"/>
Podemos implementar los ejemplos anteriores en $CATALINA_HOME/conf/server.xml , de este
modo dichos cambios afectarán a cualquier aplicación desplegada en el servidor.
Las sesiones activas por parte de clientes a aplicaciones web alojadas en servidores web Tomcat, por
defecto, están configuradas para mantenerse en caso de posibles pérdidas de conexión con el
servidor o posibles reinicios del mismo; a pesar de todo ello es posible establecer un control mayor
sobre dichas sesiones.
Por lo que respecta a las sesiones inactivas (pero todavía no caducadas) es posible configurarlas de
forma que se almacenen en disco liberando, como consecuencia de ello, los recursos de memoria
asociados. Al parar Tomcat las sesiones activas se vuelcan a disco de manera que, al volver a
arrancarlo, se podrán restaurar.
Las sesiones con un tiempo de vida que supere un límite se copian automáticamente a disco por
seguridad para evitar posibles bloqueos de sesión.
Para configurar las sesiones persistentes tendremos que gestionar el elemento <Manager> como un
subelemento de <Context> de foma que podemos actuar a dos niveles en función de si pretendemos
que la configuración establecida se aplique a todas las aplicaciones del servidor o a una aplicación
concreta.
Si configuramos las sesiones persistentes de forma global tenemos que manipular el archivo
/conf/context.xml , mientras que si queremos configurar las sesiones a nivel local a una aplicación
web determinada tendríamos que adaptar el archivo <CATALINA_HOME>/conf/context.xml
correspondiente a la aplicación.
Un ejemplo de configuración podría ser el siguiente (se emplean comentarios para explicar cada uno
de los parámetros):
<Context>
<!-- classname especifica la clase del servidor que implementa el gestor, es recomendable
utilizar el org.apache.catalina.session.PersistentManager -->
<Manager className="org.apache.catalina.session.PersistentManager">
<!--saveOnRestart=true para indicar que se guarden todas las sesiones al reiniciar el
servidor -->
saveOnRestart="true"
-8-
Configuración y administración de servidores de aplicaciones Tema 3
<!--maxActiveSession cuando se supera el límite aquí establecido se comienzan a enviar a
disco las nuevas sesiones. Se establece un valor -1 para indicar ilimitadas sesiones-->
maxActiveSession="3"
<!--minIdleSwap establece el número mínimo de segundos que transcurren antes de que una
sesión pueda copiarse al disco duro -->
minIdleSwap="0"
<!--maxIdleSwap indica el número máximo de segundos que transcurren antes de que una
sesión pueda copiarse al disco duro -->
maxIdleSwap="60"
<!--maxIdleBackup para indicar el número de segundos desde que una sesión estuvo activa
por última vez hasta que se envíe al disco. La sesión no es eliminada de memoria. Permite
restauración de la sesión en caso de caída del servidor. -->
maxIdleBackup="5">
<!--Store indica cómo y donde almacenar la sesión, están disponibles las siguientes
implementaciones: org.apache.catalina.session.FileStore y
org.apache.catalina.session.JDBCStore -->
<Store className="org.apache.catalina.session.FileStore"/>
</Manager>
</Context>
Las soluciones de clustering típicas ofrecen un paradigma de servidor que consiste en ofrecer un
sistema basado en ejecución distribuida, a pesar de que existe limitación respecto a la escalabilidad,
podemos observar el esquema de Jakarta Tomcat server engine works.
http://tomcat.apache.org/tomcat-6.0-doc/cluster-howto.html
El conector del servidor de cluster recibe la petición desde los clientes, y el procesador del servidor
de cluster encapsula las peticiones en los objetos " RequestEntry " y los escribe en JavaSpace . El
-9-
Despliegue de Aplicaciones Web José Luis Comesaña DAW
conector del Worker del cluster toma dichas peticiones y el procesador del worker del cluster
resuelve las peticiones.
Para establecer una configuración de cluster en Tomcat podremos seguir los siguientes pasos:
Todos los atributos de sesion deben implementar java.io.Serializable .
Descomentar el elemento Cluster en server.xml .
Descomentar Valve ( ReplicationValve ) en server.xml
Si las múltiples instancias de Tomcat están en la misma máquina el parámetro tcpListenPort
tiene que ser único para cada una de las instancias.
Establecer en el archivo web.xml el elemento <distributable/> o bien definirlo de forma <Context
distributable="true"/> .
El atributo jvmRoutes tiene que estar definido en el " Engine " <Engine name="Catalina"
jvmRoute="nodeX"> estableciendo su valor al nombre de la instancia en el cluster.
Sincronizar la hora de todos los nodos con un servicio NTP .
Configurar el parámetro loadbalancer en modo " sticky session ".
Esta web documenta los pasos a seguir para montar un cluster horizontal formado por dos
servidores con una instancia de Tomcat corriendo en cada uno de ellos.
http://es.wikibooks.org/wiki/Cluster_Tomcat_HOWTO
- 10 -
Configuración y administración de servidores de aplicaciones Tema 3
Mientras el Tomcat es un Servlet Container , JBoss es un Application Server, que soporta funciones
de J2EE, las más importantes son los EJB's y el clustering. Tomcat por sí solo simplemente sirve para
JSP's y servlets.
Uno de los rasgos más importantes de JBoss es su apoyo a la implementación "en caliente". Lo que
significa es que implementar un nuevo EJB es tan simple como copiar el archivo correspondiente en
el directorio correspondiente. Si esto se hace mientras el bean ya está cargado, JBOSS lo descarga
automáticamente, y entonces carga la nueva versión.
JBoss está compuesto por dos partes: un " Servlet Engine " y un " EJB Engine ", dentro del " Servlet
Engine " se ejecutan exclusivamente las clásicas aplicaciones de un servidor (JSP's y Servlets),
mientras el " EJB Engine ( Container )" es reservado para aplicaciones desarrolladas alrededor de EJB's
o Enterpise Java Bean's.
El creador de la primera versión de JBoss fué Marc Fleury quién fundó una empresa de servicios
llamada JBoss Inc., adquirida en 2006 por Red Hat.
- 11 -
Despliegue de Aplicaciones Web José Luis Comesaña DAW
Por ejemplo, el juego de los Sims online utiliza JBoss así como otros juegos multiusuario.
Vamos a partir de una máquina Debian 6.0.1 Squeeze, en la que realizaremos el proceso de
instalación y cónfiguración básica del servidor JBoss y que vamos a estructurar en los siguientes
pasos:
1. Descarga e instalación de Java Development Kit (JDK): En primer lugar, destacar que, para
instalar cualquier versión de JBoss, es necesario tener instalado JDK (Kit de desarrollo de Java),
ya que se trata de un servidor de aplicaciones basado e implementado al 100 % en Java, como se
ha dicho anteriormente, y puede ser ejecutado en cualquier sistema en el que se encuentre
operativo un JDK en su versión 1.5 o superior. Empezamos buscando el paquete de Java que
nos puede interesar. Con el siguiente comando obtendríamos la lista del entorno Java debido
a que Debian proporciona varias implementaciones, cada uno de estos paquetes tiene un
entorno de desarrollo (JDK) y un tiempo de ejecución conocido (JRE o Java Virtual Machines
JVM):
#aptitude search "?provides(java-runtime)"
2. Luego realizamos la instalación de esos paquetes empleando el comando siguiente, ello no
supondrá ningún tipo de complicación ya que se encuentran accesibles desde el repositorio
que tenemos por defecto:
#apt-get install default-jre openjdk-6-jdk
Para instalar la versión JDK de Sun (ahora ya de Oracle) en Debian 6 (Squeeze) tenemos que
agregar un repositorio, para ello editamos el archivo sources.list mediante el siguiente
comando:
#nano /etc/apt/sources.list y agregamos la siguiente línea:
deb http://ftp.ch.debian.org/debian/ squeeze main non-free
guardamos el archivo y, a continuación, ejecutamos el comando: #aptitude update ó #apt-get
update y, una vez se realice la actualización, instalaremos los siguientes paquetes Java de Sun
mediante el siguiente comando:
#aptitude install sun-java6-jre sun-java6-jdk
y, una vez instalado, lo seleccionamos mediante:
#update-alternatives –config java
que mostrará las opciones disponibles y seleccionaremos el número de opción que contiene la
máquina virtual de Java de Sun/Oracle.
3. Descarga e instalación de JBoss Application Server 6.0: Se pueden descargar las distintas
versiones del servidor JBoss del siguiente enlace, en este caso hemos decidido descargar el
paquete jboss-as-distribution-6.0.0.Final.zip.
http://www.jboss.org/jbossas/downloads/
Para proceder a su instalación simplemente nos situamos en la carpeta donde deseemos
instalarlo, en nuestro caso lo haremos en " /usr/local/jboss/ " y, una vez allí, descomprimimos
el paquete mediante:
#unzip jboss-as-distribution-6.0.0.Final.zip
4. Crear el usuario de JBoss que posee y dirige JBoss: Es recomendable ejecutar JBoss con una
cuenta de usuario no root, con privilegios mínimos. Para ello crearemos un grupo JBoss y un
- 12 -
Configuración y administración de servidores de aplicaciones Tema 3
usuario llamado JBoss al que pondremos contraseña y agregaremos al grupo creado; podemos
hacerlo del siguiente modo:
#groupadd jboss
#useradd -s /bin/bash -g jboss jboss
#passwd jboss
#usermod -d /usr/local/jboss/jboss-6.0.0.Final/ jboss
5. Establecer las variables de entorno JAVA_HOME y JBOSS_HOME : Estas variables son interesantes
para indicar las rutas donde se ha instalado Java y JBoss. Estás rutas serán empleadas en los
archivos de configuración de dichas aplicaciones, para ello simplemente agregamos, en nuestro
caso, el siguiente contenido al archivo /etc/profile :
JAVA_HOME=/usr/lib/jvm/java-6-sun/jre
JBOSS_HOME=/usr/local/jboss/jboss-6.0.0.Final
PATH=$PATH:$JAVA_HOME/bin:$JBOSS_HOME/bin
export PATH JAVA_HOME JBOSS_HOME
posteriormente ejecutaríamos #source /etc/profile para que el sistema recoja el contenido de
las variables creadas sin necesidad de reiniciar el equipo.
6. Crear un script para automatizar Jboss con los parámetros/funcionalidades
"start/stop/restart" y configurar JBoss para que se ejecute como un servicio: Existe un script
llamado " jboss_init_redhat.sh " en la carpeta $JBOSS_HOME/bin que nos va a servir para crear el
script que administre el servidor de JBoss; para ello copiamos dicho script a /etc/init.d y lo
renombramos a jboss #cp $JBOSS_HOME/bin/jboss_init_redhat.sh /etc/init.d/jboss luego
editamos el fichero copiado, en donde tenemos que reemplazar las siguientes líneas
adaptándolas a nuestra configuración, en nuestro caso:
JBOSS_HOME=${JBOSS_HOME:-"/usr/local/jboss/jboss-6.0.0.Final"}
JAVAPTH=${JAVAPTH:-"/usr/java/jdk1.6.0_24"}
y añadir la línea JBOSS_HOST="0.0.0.0" permitiendo así acceder a JBoss desde cualquier IP.
7. Acceder a la consola de administración de JBoss: Asegurarse que JBoss se ha iniciado y de que
conseguimos acceder a la consola JBoss desde las siguientes direcciones: http://ip_equipo:8080
y también http://localhost:8080 si se accede desde el propio servidor.
8. Cambiar la contraseña de administrador de JBoss:
Editamos para tal fin el archivo " /usr/local/jboss-
6.0.0.Final/server/default/conf/props/jmx-console-
users.properties " en donde introducimos la
contraseña que decidamos a continuación de admin= .
- 13 -
Despliegue de Aplicaciones Web José Luis Comesaña DAW
Las soluciones de JBoss Enterprise Middleware se distribuyen vía las "JBoss Subscription", que
incluyen el software certificado y actualizaciones, herramientas de gestión, políticas de
mantenimiento a largo plazo y un soporte técnico líder en la industria. Las suscripciones están
disponibles tanto para uso en producción como para desarrollo.
Las plataformas JBoss Enterprise, que se detallan a continuación, integran múltiples proyectos y
componentes, los más populares de la comunidad JBoss.org en distribuciones certificadas, estables y
seguras, con una única vía de parches y actualizaciones.
JBoss Enterprise Application Platform.
Diseñada para construir, desplegar y albergar servicios, y aplicaciones Java.
Integra el servidor de aplicaciones JBoss AS en cluster, un sistema de mapeo y persistencia
O/R y, además, un potente framework para la construcción de aplicaciones de nueva
generación Web 2.0.
JBoss Enterprise Web Platform.
Para aplicaciones web en Java y aplicaciones ricas basadas en Internet (RIA).
JBoss Enterprise Web Server.
Una única solución empresarial basada en open source para servidores web basados en
tecnología Apache y Tomcat.
JBoss Enterprise Portal Platform.
Diseñado para construir y desplegar portales para la interacción de usuario SOA y la
presentación personalizada.
Integra un framework de portal, funcionalidades CMS con workflow y JBoss Enterprise
Application Platfrom.
JBoss Enterprise SOA Platform.
Integra aplicaciones y orquesta servicios para automatizar procesos de negocio en una
arquitectura orientada a servicios.
Se construye sobre un bus de servicios e integra un motor de reglas, automatización de
proceso de negocio y JBoss Enterprise Application Platform.
JBoss Enterprise BRMS.
Un sistema basado en open source empresarial para administrar reglas de negocio que
facilita el desarrollo, el acceso y la gestión de los cambios de políticas y reglas de negocio.
JBoss Enterprise Data Services Platform.
Acaba con la desconexión entre los diversos orígenes de datos empresariales que existen y
los innovadores formatos de datos que requieren los nuevos proyectos, aplicaciones y
arquitecturas.
La estructura de una aplicación web en su forma más sencilla, debe contener la siguiente estructura
de directorios:
META-INF/
manifest.mf
WEB-INF/
classes/
src/
lib/
web.xml
conteniendo la carpeta META-INF , en aplicaciones .jar , el archivo manifest.mf , que contiene la lista
de contenidos de la aplicación, y que son generados al momento de crearla. El directorio WEB-INF
contiene todos los archivos necesarios para ejecutar la aplicación, y estructura su contenido en las
carpetas classes que contiene las clases compiladas para la aplicación, lib con las librerías
necesarias para la aplicación y src, con el código fuente de la aplicación.
Una vez que la aplicación JEE está correctamente construida, se realiza el empaquetado con el
comando:
- 14 -
Configuración y administración de servidores de aplicaciones Tema 3
#jar cvf nombre_aplicacion.jar carpetas/ficheros_a_empaquetar
Una vez tenemos la aplicación .jar para desplegarla, únicamente la copiamos a la carpeta
" $JBOSS_HOME/server/default/deploy " y el propio JBoss nos dará un mensaje similar a deploy,
ctxPath = / nombre_aplicacion , lo que quiere decir que la aplicación ha sido desplegada
correctamente; esto se conoce como despliegue en caliente.
Una aplicación empresarial Java EE (archivo .EAR ) es un conjunto de módulos, siendo un módulo una
aplicación web completa (empaquetada en un archivo .war ) o conjunto de objetos distribuidos EJBs
(empaquetados en un archivo .jar ).
Podemos resumir que la estructura del archivo EAR es:
/*.war : Archivos war.
/*.jar : Archivos (ejb) jar.
/META-INF/application.xml : Descriptor de despliegue del módulo EAR , en donde se dan de alta y
se declaran el nombre y descripción de la aplicación que se despliega, y los diferentes módulos
web y EJB que forman la aplicación.
Vamos a suponer una estructura lo más sencilla posible para una aplicación
web como la siguiente, y que es la que constituye el archivo
" aplicacion.war ":
donde observamos una página estática " index.html " y un descriptor del despliegue " web.xml ", a
partir de esta estructura pretendemos construir nuestro propio archivo EAR que contendrá un solo
archivo WAR con una página HTML estática.
Una vez situados en la carpeta " aplicacion ", mediante el comando #jar cvf aplicacion.war *
generaremos el archivo .WAR correspondiente a la aplicación; podremos comprobar que se trata de
un formato similar a los archivos .zip probando a abrirlo con un programa compresor.
Para construir el archivo .EAR , como mínimo, tendremos que crear un descriptor de despliegue al
que llamaremos " aplicacion.xml ", para ello creamos una carpeta llamada
" temporal " en donde situamos el archivo " aplicacion.war "; en la misma
ruta creamos una carpeta llamada " META-INF " donde vamos a crear el
descriptor; quedando la estructura del siguiente modo:
Nos situamos dentro de la carpeta " temporal " y creamos el archivo .ear mediante el comando:
#jar cvf aplicacion.ear *
- 15 -
Despliegue de Aplicaciones Web José Luis Comesaña DAW
ANT (siglas de "Another Neat Tool", en español "Otra Herramienta Pura", que en inglés significan
"hormiga") fue creado por James Duncan Davidson mientras realizaba la transformación del proyecto
Solar de Sun Microsystems en código abierto (concretamente la implementación del motor
JSP/Servlet de Sun, que luego se llamaría Jakarta Tomcat).
Apache Ant es una herramienta usada en programación para la realización de tareas mecánicas y
repetitivas, normalmente se centra en la fase de compilación y construcción (build). Es similar al
" make " empleado en Linux, pero desarrollado en Java; posee la ventaja de no depender de los
comandos shell de cada sistema operativo, ya que se basa en archivos de configuración XML y clases
Java, siendo idónea como solución multi-plataforma.
Trabajar sin Ant implica una compilación manual de todos los ficheros .java (sin un control de los
que han sido modificados y de los que no) incluir los classpath relativos adecuados, tener los
ficheros .class mezclados con el código fuente...; sin embargo con Ant, en el fondo, no estás más
que automatizando tareas, para que, al final, con un solo comando, puedas compilar desde cero tu
proyecto, ejecutar pruebas unitarias, generar la documentación, empaquetar el programa…
- 16 -
Configuración y administración de servidores de aplicaciones Tema 3
aplicaciones web
Ensamblado = construcción + despliegue
Similar a la herramienta make de linux
Se ocupa de:
Compilación
¿Para qué sirve? Generación de documentación
Empaquetamiento
Ejecución…
Automatiza tareas, para que al final con un solo comando:
Puedas compilar desde cero tu proyecto,
ejecutar pruebas unitarias,
Ventajas generar la documentación,
empaquetar el programa…
No depende de los comandos Shell de cada sistema operativo, ya que se basa
en archivos XML y clases Java, siendo idónea como sulución multi-plataforma.
Funciona a partir de un script de ensamblado en formato XML llamado
build.xml, definido en base a proyecto, targets y tasks
Proyecto
Uno por archivo y contiene targets
¿Cómo funciona? Target
Con un nombre y dependencias hacia otros targets
Contiene un conjunto de tasks
Tasks
Operaciones básicas (javac, java, jar, etc)
En esta página podemos encontrar toda la información que nos pueda interesar para
comenzar a trabajar con la herramienta Ant.
http://ant.apache.org/
recordemos que, como requisito para la instalación de Ant, es imprescindible una versión JDK 1.4 ó
superior.
Posteriormente procederemos a la descargar del paquete binario de Ant, que podemos descargarlo
de la siguiente forma:
#wget http://ant.apache.org/bindownload.cgi/apache-ant-1.8.2-bin.tar.gz
luego movemos la carpeta " apache-ant-1.8.2 " creada a " /usr/local ".
- 17 -
Despliegue de Aplicaciones Web José Luis Comesaña DAW
PATH=$PATH:$ANT_HOME/bin
y luego, para que el sistema recoja los cambios realizados, empleamos el comando: #source
/etc/profile .
Para comprobar que ant se ha instalado correctamente desde una consola de shell ejecutamos el
comando siguiente: #ant y deberíamos obtener un mensaje similar a:
Buildfile: build.xml does not exist!
Build failed
con lo que la herramienta ant estaría correctamente instalada y configurada para desempeñar su
función en nuestra máquina.
En el siguiente vídeo podemos ver que se muestra cómo realizar la instalación del paquete
Ant en un equipo con sistema operativo Microsoft Windows 7.
http://www.youtube.com/watch?feature=player_embedded&v=bcY4ZF1jt4o
La primera parte del vídeo nos explica cómo descargar el paquete Ant desde su web de
descarga, en dicha página podemos observar varios formatos y revisiones para el paquete
Ant y, en nuestro caso, se selecciona el .zip y se realiza la descarga del mismo.
Luego se extrae el archivo .zip descargado en la carpeta que nos interese, en este caso
"c:\kwit\apache-ant-1.8.2", en donde vemos la estructura de carpetas que Ant contiene,
entre otras, bin, docs, etc, lib...
Una vez instalado el paquete se pasa a configurar las variables de entorno de la aplicación;
para ello se accede a "Panel de control, configuraciones avanzadas y variables de entorno",
se selecciona la variable PATH y se actualiza su valor con la ruta donde se ha instalado Ant
seguido de \bin, es decir, para este caso concreto sería: "c:\kwit\apache-ant-1.8.2\bin" y,
por último, se abre un intérprete de comandos empleando el comando cmd y, mediante la
orden ant -version se comprueba que la instalación ha sido correcta y que queda la
aplicación operativa.
- 18 -
Configuración y administración de servidores de aplicaciones Tema 3
Pasamos a ver un simple ejemplo de archivo build.xml :
<?xml version="1.0"?>
<target name="compilar">
<javac srcdir="${fuente}" destdir="${destino}" />
</target>
</project>
Este sencillo fichero requiere poca explicación, simplemente declaramos el proyecto indicando, la
acción a realizar por defecto ( default="compilar" ), e indicamos que el directorio base es el actual
( basedir="." ).
Después indicamos en sendas etiquetas property los directorios de origen y de destino ( property
name="fuente" value="." y property name="destino" value="classes" ).
Por último declaramos un target llamado compilar, que es el que hemos declarado como por
defecto.
En este objetivo tenemos una única tarea, la de compilación javac , a la que por medio de los
atributos srcdir y destdir le indicamos los directorios fuente y destino, que recogemos de las
propiedades anteriormente declaradas con ${fuente} y ${destino} .
Lo único que nos queda es compilar nuestro código, así que, simplemente, estando situados en el
directorio donde tenemos nuestro build.xml , desde una ventana de MS-DOS o terminal GNU/Linux,
podemos hacer:
#[PATH_TO_ANT]ant
Esto funciona así porque hemos declarado compilar como el objetivo por defecto, aunque podría ser
otro así que por regla general pondríamos:
#[PATH_TO_ANT]ant nombre_objetivo
Ant se basa en ficheros XML, normalmente configuramos el trabajo a hacer con nuestra aplicación en
un fichero llamado build.xml .
Ant, al igual que otras herramientas de construcción, se basa en el concepto de objetivos o targets
cuya definición engloba tanto las dependencias previas como los pasos a seguir para conseguirlo.
Vamos a comenzar definiendo un objetivo de preparación llamado init que será el encargado de
crear un directorio classes donde guardaremos los ficheros " .class " resultantes de la compilación y
el directorio build para el .jar final. Para ello basta incluir dentro de <project> las siguientes líneas:
<target name="init">
<mkdir dir="classes" />
<mkdir dir="build" />
</target>
Como podemos ver los objetivos se delimitan con etiquetas <target> y un nombre. Dentro de ellos se
enumeran los pasos que se han de seguir para alcanzar el objetivo, en este caso ha de crear
directorios.
- 19 -
Despliegue de Aplicaciones Web José Luis Comesaña DAW
init:
[mkdir] Created dir: /home/profesor/proyecto/classes
[mkdir] Created dir: /home/profeosr/proyecto/build
BUILD SUCCESSFUL
Total time: 0 seconds
Es hora de compilar nuestro proyecto, vamos a definir el objetivo compile . Ahora bien, la compilación
depende de la creación del directorio " classes "que se realiza en el objetivo anterior. Con esto en
cuenta basta con incluir:
<target name="compile" depends="init">
<javac srcdir="src" destdir="classes" />
</target>
La dependencia se fija en la declaración del target de tal manera que se garantiza su cumplimiento
antes de comenzarla. Nuestro código está en el directorio " src " y el resultado de la compilación se
lleva al directorio " classes ".
Importante notar que esta vez estamos usando <javac> esto es lo que Ant denomina tarea. Hay
muchas tareas predefinidas.
Con nuestro proyecto compilado vamos a generar el .jar que distribuiremos haciendo uso de un
nuevo objetivo llamado build .
<target name="build" depends="compile">
<jar destfile="build/proyecto.jar" basedir="classes" />
</target>
Comprobamos que hay una dependencia de compile y se utiliza la tarea jar que se encarga de
empaquetar todo el contenido del directorio classes en el fichero proyecto.jar .
Finalmente incluiremos un nuevo objetivo para limpiar todo el entorno, el objetivo clean :
<target name="clean">
<delete dir="classes" />
<delete dir="build" />
</target>
Elimina los directorios de trabajo dejando el entorno limpio del proceso de compilación. Resumiendo
nuestro fichero build.xml es:
<project name="Proyecto">
<target name="init">
<mkdir dir="classes" />
<mkdir dir="build" />
</target>
<target name="compile" depends="init">
<javac srcdir="src" destdir="classes" />
</target>
<target name="build" depends="compile">
<jar destfile="build/proyecto.jar" basedir="classes" />
</target>
<target name="clean">
<delete dir="classes" />
<delete dir="build" />
</target>
</project>
- 20 -
Configuración y administración de servidores de aplicaciones Tema 3
Un módulo web es la más pequeña unidad de un recurso web que se pueda utilizar y desplegar. Un
módulo web Java EE corresponde con una aplicación web, como se define en la especificación de
Java Servlet.
Además de los componentes web y los recursos web, un módulo web puede contener otros ficheros:
Clases utilitarias del lado del servidor (beans (componente software que tiene la particularidad de ser reutilizable y
así evitar la tediosa tarea de programar los distintos componentes uno a uno) para bases de datos, carritos de
compras y demás). A menudo estas clases cumplen con la arquitectura JavaBeans .
Clases del lado del cliente (applets (componente de una aplicación que se ejecuta en el contexto de otro programa, por
ejemplo un navegador web) y clases utilitarias).
Un módulo web tiene una estructura específica. El directorio más alto de la jerarquía de directorios
de un módulo web es el raíz de documento de la aplicación. Es donde las páginas JSP, clases y
archivos del lado del cliente, y los recursos estáticos como imágenes, son almacenados.
El directorio raíz de los documentos contiene un subdirectorio llamado WEB-INF , que contiene los
siguientes ficheros y directorios:
web.xml : El descriptor de despliegue de aplicación.
classes : Un directorio que contiene las clases del lado del servidor: componentes Servlets, clases
utilitarias y JavaBean.
tags : Un directorio que contiene ficheros de etiquetas, que son implementaciones de librerías de
etiquetas.
lib : Un directorio que contiene los archivos JAR de las librerías llamadas por las clases del lado
del servidor.
Un módulo web debe ser empaquetado en un WAR en ciertos escenarios de despliegue y cuando se
quiera distribuir el módulo web. Se empaqueta un módulo web en un WAR ejecutando el comando
jar en un directorio ubicado en el formato de un módulo, utilizando la utilidad Ant o utilizando la
herramienta IDE de su elección.
Un módulo web puede ser desplegado como una estructura de ficheros sin empaquetar o puede ser
empaquetado en un fichero JAR conocido como un archivo web ( WAR ). Dado que el contenido y uso
de los ficheros WAR difieren de aquellos ficheros JAR , el nombre del fichero WAR utiliza una extensión
.WAR . El módulo web descrito es portátil, se puede desplegar en cualquier contenedor web que
cumpla con la especificación Java Servlet.
Existen una serie de tareas para Ant que podemos utilizar para la gestión de aplicaciones, entre las
cuales destacamos:
<deploy> : Despliega una aplicación web.
<start> : Inicia una aplicación web.
<stop> : Para una aplicación.
<undeploy> : Repliega (desinstala) una aplicación.
<trycatch> : Evita que falle un build aunque falle alguna tarea.
Se pueden emplear diversos tipos de servidores de aplicaciones web junto con la herramienta Ant,
por ejemplo JBoss o Tomcat.
- 21 -
Despliegue de Aplicaciones Web José Luis Comesaña DAW
Para desplegar un WAR con la herramienta Ant, abrimos una ventana de terminal o línea de
comando en el directorio donde se ha construido y empaquetado el WAR y ejecutamos ant deploy.
- 22 -
Configuración y administración de servidores de aplicaciones Tema 3
Mediante el enlace " Tomcat Manager " accedemos al gestor de aplicaciones Web de Tomcat. Esta
página permite desplegar un proyecto contenido en un fichero de extensión war , como ya hemos
visto en el punto "2.2 Despliegue de una aplicación web" de este tema, o simplemente copiar la
carpeta que contiene de la aplicación a la carpeta webapps que se encuentra en el directorio de
instalación deTomcat.
Vamos al Tomcat Manager y allí podremos ver un listado de las aplicaciones web que hay disponibles
en el servidor. Podemos comprobar, en nuestro caso, que si tenemos en la carpeta
usr/local/apache-Tomcat-6.0.32/webapps/ la carpeta de la aplicación " Aplic_Web " que desarrollamos
al principio de este tema, ya se mostraría en el listado que el gestor de aplicaciones de Tomcat nos
ofrece, o simplemente accediendo desde un navegador a la URL:
http://ip_servidor:8080/nombre_aplicacion (en el caso genérico), para nuestro caso podemos
probar con http://localhost:8080/Aplic_Web .
Si estás trabajando como administrador de sistemas en una empresa (supongamos que esBK
programación), en la que eres el encargado de administrar, entre otras, un máquina en la que hay un
servidor de aplicaciones web Tomcat.
¿Cómo solicitarías a los desarrolladores de aplicaciones que te enviasen las aplicaciones a desplegar
en dicho servidor?
- 23 -
Despliegue de Aplicaciones Web José Luis Comesaña DAW
Podemos asegurar Tomcat estableciendo que se permita el acceso a este contexto únicamente a las
direcciones IP de los equipos desde los que operan los administradores, esto lo podemos configurar
en el archivo: $CATALINA_HOME/work/Catalina/localhost/manager/context.xml .
<Context path="/manager" privileged="true" antiResourceLocking="false" docBase="/opt/apache-
tomcat6/webapps/manager">
<Valve className="org.apache.catalina.valves.RemoteAddrValve" allow="127.0.0.1,
direccion_ip1, direccion_ip2" />
</Context>
Para acceder a la administración de Tomcat es necesario crear el rol " manager ", " admin " y
usuario/s con dicho rol, para ello es necesario editar el archivo de usuarios de Tomcat
$CATALINA_HOME/conf/Tomcat-users.xml .
- 24 -
Configuración y administración de servidores de aplicaciones Tema 3
Recibe peticiones en protocolos específicos como AJP que son enviados por el frontend.
2. Standalone:
No hay un servidor web que actúe de frontend.
Todos los contenidos son servidos por Tomcat.
Recibe peticiones HTTP.
Los conectores son los componentes que proporcionan la interfaz externa al servidor, concretamente
el conector HTTP1.1 basado en Coyote es el conector por defecto para Tomcat. Los conectores se
definen en el archivo:
$CATALINA_HOME/conf/server.xml , aquí tenemos un ejemplo:
<Conector port="8080"
protocol="HTTP/1.1"
maxTherads="150"
connectionTimeout="2000"
redirectPort="8443"/>
debido a establecer medidas de seguridad para conexiones web al servidor, podremos configurar
para un conector HTTP/1.1 con SSL lo siguiente:
<Conector port="8080"
protocol="HTTP/1.1"
maxTherads="150"
scheme="https"
secure="true"
clientAuth="false"
sslProtocol="TLS"/>
en donde vemos que se han establecido los atributos scheme para el protocolo, y secure para
establecer que se trata de un conector SSL.
Tomcat define una serie de librerías que le permiten automatizar tareas como el despliegue y
repliegue de aplicaciones web, mediante Ant .
Para integrar las dos herramientas anteriores podemos seguir las siguientes operaciones:
Descargar Ant .
Descomprimir el fichero.
Configurar las variables de entorno ANT_HOME para que apunte a la raíz de la distribución.
Configurar la variable PATH para añadir la ruta hasta el directorio <ANT_HOME>/bin .
- 25 -
Despliegue de Aplicaciones Web José Luis Comesaña DAW
Para instalar una aplicación web, se le indica a Tomcat Manager que un nuevo contexto está
disponible, empleando para ello el comando #ant install que funciona tanto con archivos .WAR
como si se indica la ruta al directorio de la aplicación no empaquetada. Es necesario tener en cuenta
que el comando anterior no implica un despliegue permanente; si se reinicia Tomcat las aplicaciones
previamente instaladas no van a estar disponibles.
El comando #ant deploy se emplea para el despliegue permanente de las aplicaciones, y para ello es
necesario:
Que el Tomcat Manager se esté ejecutando en la localización especificada por el atributo url .
El despliegue de una aplicación en el contexto especificado por el atributo path y la localización
contenida en los archivos de la aplicación web especificada con el atributo war .
El archivo build.xml de una aplicación llamada " Hola " para " ant
deploy " podría ser el siguiente:
<target name="deploy" description="Deploy web application" depends="build">
<deploy url="${url}" username="${username}"
password="${password}"
path="${path}" war="file:${build}/${example}.war"/>
</target>
<taskdef name="deploy" classname="org.apache.catalina.ant.DeployTask" />
<property name="url" value="http://localhost:8080/manager" />
<property name="path" value="/${example}" />
<property name="example" value="hola" />
- 26 -