Blog Duroty.com

La solución a mis problemas

Configuración “all” en JBOSS (modalidad cluster)

En el post anterior se ha visto como arrancar y parar un servidor de aplicaciones JBOSS.

> /opt/jboss/bin/run.sh -c default

> /opt/jboss/bin/shutdown.sh -S

Para aproximarnos a un entorno real hay que añadir otros parámetros en el comando de arrancada. Además en este post se utiliza la configuración all para preparar un entorno clusterizable.

Para ver los posibles valores de arranca del servidor de aplicaciones podemos ejecutar los siguiente:

> /opt/jboss/bin/run.sh –help

Que devuelve las posibles opciones de arranque:

options:
-h, –help                    Show this help message
-V, –version                 Show version information
-D<name>[=<value>]            Set a system property
-d, –bootdir=<dir>           Set the boot patch directory; Must be absolute or url
-p, –patchdir=<dir>          Set the patch directory; Must be absolute or url
-n, –netboot=<url>           Boot from net with the given url as base
-c, –configuration=<name> Set the server configuration name
-B, –bootlib=<filename>      Add an extra library to the front bootclasspath
-L, –library=<filename>      Add an extra library to the loaders classpath
-C, –classpath=<url>         Add an extra url to the loaders classpath
-P, –properties=<url>        Load system properties from the given url
-b, –host=<host or ip> Bind address for all JBoss services
-g, –partition=<name> HA Partition name (default=DefaultDomain)
-u, –udp=<ip> UDP multicast address
-l, –log=<log4j|jdk>         Specify the logger plugin type

Como el propósito del ejemplo es montar un cluster empezamos utilizando la configuración all (que permite arrancar el servidor de aplicaciones en modo cluster, arrancar los web services, HA-JNDI, y otros).

Para arrancar el servidor de aplicaciones con las funcionalidades de cluster:

> /opt/jboss/bin/run.sh -c all

-b <host or ip>, –host=<host or ip>

Este parámetro es importante tenerlo en cuenta pues cambia dos propiedades del sistema jboss.bind.address y bind.address. JGroups -estos parámetros sobreescriben los por defecto en la configuración xml del propio servidor-

jboss.bind.address: indica la dirección donde los servicios Tomcat, jrmp/pooled invokers services,…etc escucharán.

bind.address. JGroups: utilizada para indicar a JGroups (JGroups is a toolkit for reliable multicast communication.) con que IP se hace el bind del cluster.

Se puede fijar a 0.0.0.0 como dirección IP para bindar a todas las direcciones. Existe más información en http://www.jboss.org/community/docs/DOC-9730

Para nuestro ejemplo utilizamos la ip 10.0.0.1 para levantar los servicios:

> /opt/jboss/bin/run.sh -c all -b 10.0.0.1

Finalmente podemos probar en el navegador si el arranque ha sido correcto con http://10.0.0.1:8080

Para parar el servidor de aplicaciones hay que indicar en que dirección IP está arrancado con el parametro -s y utilizar -S para indicar el shutdown:

> /opt/jboss/bin/shutdown.sh -s 10.0.0.1 -S

La primera cosa necesaria para la instalación del JBOSS AS es una distribución del mismo. Para todos los ejemplos J2EE que publicaré se ha utilizado la versión JBoss 4.2.0.GA,  pero deberian funcionar para las versiones posteriores.

La descarga de JBOSS AS se puede entrontrar a través de GOOGLE o en la página web oficial http://jboss.org/jbossas/downloads/.

Comprovar la versión de la JDK

Para la instalación del servidor de aplicaciones es necesario como mínimo la versión de jdk 1.5. Se puede comprobar la versión instalada con el siguiente comando:

> java -version
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_02-56)
Java HotSpot(TM) Client VM (build 1.5.0_02-36, mixed mode, sharing)

En caso de no disponer de la versión se puede realizar la descarga directamente de la página de sun para la plataforma que mas convenga – http://java.sun.com/javase/downloads/index.jsp

Estructura de directorios

Para todos los ejemplos voy a suponer que el directorio de trabajo es /opt/jboss/*. Por lo tanto una vez descomprimido el servidor de aplicaciones dentro de /opt/jboss queda una estructura de directorios com la siguiente:

En la imagen se muestra que el directorio raiz es jboss-4.0-4, es importante y muy útil crear un alias “jboss” para acceder a cualquier versión que se tenga instalada de esta manera todos los scripts u otras aplicaciones no se verán afectados en el caso de una actualización del servidor de aplicaciones. Por lo tanto, para el ejemplo de la imagen anterior la ruta /opt/jboss/ será un alias a /opt/jboss-4.0-4 o /opt/jboss-XXX/

En la documentación oficial de jboss (http://docs.jboss.org/jbossas/jboss4guide/r5/html/ch01.html) existe una tabla que describe cada directorio. Aquí va un extracto:

The JBoss top-level directory structure

Directory	Description
bin	All the entry point JARs and start scripts included with the JBoss distribution are located in the bin directory.
client	The JARs that are required for clients that run outside of JBoss are located in the client directory.
server	The JBoss server configuration sets are located under the server directory. The default server configuration set is the server/default set. JBoss ships with minimal, default and all configuration sets. The subdirectories and key configuration files contained default configuration set are discussed in more detail in Section 1.3, “The Default Server Configuration File Set”
lib	The lib directory contains startup JARs used by JBoss. Do not place your own libraries in this directory.

The JBoss server configuration directory structure

Directory	Description
conf	The conf directory contains the jboss-service.xml bootstrap descriptor file for a given server configuration. This defines the core services that are fixed for the lifetime of the server.
data	The data directory is available for use by services that want to store content in the file system.
deploy	The deploy directory is the default location the hot deployment service looks to for dynamic deployment content. This may be overridden through the URLDeploymentScanner URLs attribute.
lib	The lib directory is the default location for static Java libraries that should not be hot deployed. All JARs in this directory are loaded into the shared classpath at startup.
log	The log directory is the directory log files are written to. This may be overridden through the conf/log4j.xml configuration file.
tmp	The tmp directory is used by JBoss to store temporarily files such as unpacked deployments.

Por defecto JBOSS AS presenta tres posibles configuraciones (se pueden modificar y crear las que se crean convenientes en función de configuraciones, clusters, etc.):

• minimal
  que arranca un microkernel JMX mínimo
• default
  arranca un servidor de aplicaciones completo pero sin funcionalidades de cluster, webservices, etc
• all
  como su nombre indica es la configuración completa con servidor de aplicaciones J2EE full, con clustering, webservices,  rmi-iiop, etc.

Para los que trabajan en windows y quieren simular un entorno linux os recomiendo la descarga cygwin.

Arrancando y parando el servidor de aplicaciones

Para arrancar el JBOSS con la configuración por defecto (default)

> /opt/jboss/bin/run.sh -c default

Probar en el navegador http://localhost:8080

Para parar una instancia de JBOSS

> /opt/jboss/bin/shutdown.sh -S

Los comandos anteriores nos permiten arrancar y parar el servidor de aplicaciones, pero para poder operar y trabajar correctamente hay que configurar un poco más. En las próximas entregas veremos como arrancar el servidor de aplicaciones sobre una IP, como arrancar todos los servicios a través de la configuración “all”, como preparse para la escalabilidad y clusterización, como instalar el servidor de aplicaciones como un servicio en linux, seguridad, accesos en el puerto 80, etc.

Empezaré las entregas sobre J2EE con la introducción a los servidores de aplicaciones. Existe en la Wikipedia una buena definición que os reescribo parcialmente aquí.

Mu gusta destacar que hablar de servidores de aplicaciones normalmente está directamente relacionado con J2EE – JAVA.

---

Extracto de http://es.wikipedia.org/wiki/Servidor_de_aplicaciones

En informática se denomina servidor de aplicaciones a un servidor en una red de computadores que ejecuta ciertas aplicaciones.

Usualmente se trata de un dispositivo de software que proporciona servicios de aplicación a las computadoras cliente. Un servidor de aplicaciones generalmente gestiona la mayor parte (o la totalidad) de las funciones de lógica de negocio y de acceso a los datos de la aplicación. Los principales beneficios de la aplicación de la tecnología de servidores de aplicación son la centralización y la disminución de la complejidad en el desarrollo de aplicaciones. Si bien el término es aplicable a todas las plataformas de software, hoy en día el término servidor de aplicaciones se ha convertido en sinónimo de la plataforma Java EE (antes J2EE) de Sun Microsystems.

Como consecuencia del éxito del lenguaje de programación Java, el término servidor de aplicaciones usualmente hace referencia a un servidor de aplicaciones Java EE. WebSphere (IBM) y WebLogic (Oracle, antes BEA Systems) están entre los servidores de aplicación Java EE privativos más conocidos. EAServer (Sybase Inc.) es también conocido por ofrecer soporte a otros lenguajes diferentes a Java, como PowerBuilder. El servidor de aplicaciones JOnAS, desarrollado por el consorcio ObjectWeb, fue el primer servidor de aplicaciones libre en lograr certificación oficial de compatibilidad con J2EE. JBoss es otro servidor de aplicaciones libre y muy popular en la actualidad, así como el GlassFish de SUN. Mucha gente confunde a Tomcat (The Apache Software Foundation) con un servidor de aplicaciones, sin embargo es sólamente un contenedor de servlets [1].

Java EE provee estándares que le permiten a un servidor de aplicaciones servir como “contenedor” de los componentes que conforman dichas aplicaciones. Estos componentes, escritos en lenguaje Java, usualmente se conocen como Servlets, Java Server Pages (JSPs) y Enterprise JavaBeans (EJBs) y permiten implementar diferentes capas de la aplicación, como la interfaz de usuario, la lógica de negocio, la gestión de sesiones de usuario o el acceso a bases de datos remotas.

La portabilidad de Java también ha permitido que los servidores de aplicación Java EE se encuentren disponibles sobre una gran variedad de plataformas, como Unix, Microsoft Windows y GNU/Linux.

---

Existen diferentes servidores de aplicaciones que cumplen el estándar J2EE en el mercado, pero me centraré en las próximas entregas y ejemplos en el que me “ha salvado la vida” en la mayoría de ocasiones y que es de código libre, el gran JBOSS AS. Un servidor de aplicaciones puro JAVA, que cumple los estándares J2EE 1.4, clusterizable, con soporte completo para JMX, EJB, JMS, etc.