Fichero standalone del Servidor JBoss EAP

Vamos a echar hoy un vistazo a la estructura del fichero standalone del servidor JBoss EAP. Aunque JBoss se puede utilizar de forma bastante estándar sin modificar el standalone.xml, lo más normal es que queramos añadir algún tipo de adaptación específica para nuestro sistema. En ese caso, será muy conveniente que tengamos una idea global de la utilidad de cada uno de los bloques en los que se divide dicho fichero de configuración. Por supuesto, para proyectos sencillos no será necesario incorporar grandes modificaciones a la estructura por defecto, pero la cosa será muy diferente si estamos trabajando con aplicaciones empresariales. 

 

 

Mencionar que el servidor JBoss EAP se puede utilizar en modo "standalone" o en modo "domain". El modo "standalone" es el más comúnmente utilizado y se denomina así porque operamos con una única instancia del servidor. Por contra, el modo "domain" nos permitirá trabajar con un cluster de servidores, en el que podremos establecer una jerarquía de dependencias entre ellos. Como parece obvio, para configurar el arranque del servidor en modo standalone, tendremos que parametrizar el fichero standalone.xml contenido en la carpeta standalone/configuration de nuestro JBoss.

Fichero standalone del Servidor JBoss EAP

Una vez que tenemos clara la utilidad del fichero standalone.xml, vamos a tratar de detallar su configuración interna. Al abrir el XML lo primero que veremos es que mantiene una clara división con los siguientes bloques principales.

* <extensions>: En este apartado se indican cuáles con las extensiones que van a ser utilizadas por nuestro servidor. Una extensión es un módulo que amplía las capacidades estándar del servidor JBoss EAP (tanto en modo standalone como en modo domain).

* <management>: Configuración de los servicios de gestión empleados para controlar el servidor.

* <profile>: Configuración de las capacidades y atributos de los subsistemas del servidor JBoss EAP. Cada uno de estos subsistemas viene proporcionado por las extensiones definidas en el primer bloque.

* <interfaces>: Configuración de las interfaces de red disponibles para su utilización en el servidor.

* <socket-binding-group>: Configuración de los diferentes sockets requeridos para el arranque del JBoss y el despliegue de nuestra aplicación.

* <deployments>: En este apartado se enumeran las aplicaciones implementadas en la instancia del servidor. Se deben indicar los nombres de los .jar, .war o .ear.

Dentro de cada uno de esos bloques principales tendremos los subdivisiones necesarias en las que podremos ir incluyendo la configuración requerida para nuestra aplicación. Una de las grandes ventajas de JBoss es su flexibilidad, de manera que en este XML podremos ir añadiendo las capacidades que precisemos y eliminando aquellos otros componentes que no vayan a ser necesarios en nuestro sistema. Las combinaciones de configuración son casi ilimitadas.

Bloque Extensions del standalone de JBoss EAP

Dentro del bloque <extensions> habrá que ir incluyendo aquellas capacidades adicionales que queramos ir añadiendo a nuestra instancia del servidor. Al añadirlo en este bloque, el módulo quedará disponible para JBoss EAP.

Una vez añadido el módulo, para su correcto funcionamiento posteriormente tendremos que definir la configuración del mismo en el bloque <profile>. Por tanto, todo módulo del boque <extensions> tendrá asociado un subsistema en el bloque <profile>.

El nombre del módulo debe coincidir con la estructura de directorios que tengamos en la carpeta "modules" de nuestra instalación.

modules/system/layers/base

👉 Por ejemplo, si definimos el módulo siguiente:

<extension module="org.jboss.as.clustering.infinispan"/>

Entonces en nuestra instalación nos aparecerá una carpeta como la siguiente:

JBOSS_HOME\modules\system\layers\base\org\jboss\as\clustering\infinispan\main

Dentro de la carpeta "main" de dicha extensión tendremos un fichero "module.xml". En ese XML estarán informadas todas las librerias .jar correspondientes a dicho módulo, así como aquellas librerías de las que tiene dependencia.

Bloque Management del standalone de JBoss EAP

Dentro del bloque <management> se deberán ir definiendo las interfaces de administración. Dichas interfaces son las que van a permitir que los clientes remotos se conecten a JBoss con el fin de administrar la instancia. En el XML se deberá establecer la configuración requerida para cada una de las interfaces.

Las interfaces de administración concretamente se definen dentro del tag <management-interfaces> del bloque y pueden ser de dos tipos:

* http-interface: Interfaz HTTP. Si no queremos que nuestro entorno sea accesible mediante interfaz HTTP, entonces no se incluirá este tag en el XML. De esta forma, la consola de administración quedará deshabilitada para los accesos HTTP.

* native-interface: Interfaz nativa (utilizada en la interfaz de líneas de comandos CLI)

 

Una vez definidas las interfaces, los sockets asociados (tanto nativos como http) se deberán configurar en el bloque <socket-binding-group>. En el bloque de sockets es donde se detallarán los hosts/puertos en los que estarán escuchando las interfaces creadas en el bloque de management.

Bloque Socket del standalone de JBoss EAP

Dentro del bloque <socket-binding-group> podemos ir incluyendo los sockets que nuestro JBoss vaya a necesitar para desplegar nuestra aplicación. Los valores de cada uno de ellos serán totalmente configurables.

En primer lugar, podremos configurar los sockets de gestión de JBoss, que serán los siguientes: 

* management-native: Puerto de la Consola de Gestión Web.

* management-http: Puerto empleado por la Consola de Gestión y la API de Gestión. 

* management-https: Puerto habilitado para HTTPS.

👉 Un ejemplo de esta configuración sería el siguiente:

<!-- Configuracion de sockets de gestion -->
<socket-binding-group name="standard-sockets" default-interface="public"
    port-offset="${jboss.socket.binding.port-offset:200}">
    <socket-binding name="management-native" interface="management"
        port="${jboss.management.native.port:9999}"/>
    <socket-binding name="management-http" interface="management"
        port="${jboss.management.http.port:9990}"/>
    <socket-binding name="management-https" interface="management"
        port="${jboss.management.https.port:9443}"/>
</socket-binding-group>   
<!-- -------------------------------------------------- -->   

Junto a los de gestión, también se pueden ir configurando el resto de tipologías de sockets. Disponemos de las siguientes capacidades: 

* ajp: Apache JServ Protocol. Se emplea para http clustering y balanceo de carga. 

* http: Puerto de despliegue de aplicaciones web. 

* https: Conexión SSL entre las aplicaciones web desplegadas y los clientes. 

* jacorb: Servicios CORBA para transacciones JTS. 

* jacorb-ssl: Servicios CORBA SSL.

* jgroups-mping: Multicast. Se emplea para detectar suscripciones iniciales en un cluster HA.

* jgroups-tcp: Unicast. Detecciones en clusters HA mediante TCP.

* jgroups-tcp-fd: Unicast. Detecciones fallidas.

* jgroups-udp: Multicast. Detecciones en clusters HA mediante UDP.

* jgroups-udp-fd: Multicast. Detecciones fallidas.

* modcluster: Multicast. Puerto de comunicación entre JBoss y el balanceador de carga HTTP. 

* remoting: Invocación de EJB remotos. 

* txn-recovery-environment: Gestor de recuperación de transacciones JTA. 

* txn-status-manager: Gestor de transacciones JTA / JTS.

👉 Un ejemplo de configuración de los diferentes sockets sería el siguiente:

<!-- Configuracion de sockets de JBoss -->
<socket-binding name="ajp" port="8009"/>
<socket-binding name="http" port="9080"/>
<socket-binding name="https" port="8443"/>
<socket-binding name="jgroups-mping" port="0"
    multicast-address="${jboss.default.multicast.address:230.0.0.4}"
    multicast-port="45700"/>
<socket-binding name="jgroups-tcp" port="7600"/>
<socket-binding name="jgroups-tcp-fd" port="57600"/>
<socket-binding name="jgroups-udp" port="55200"
    multicast-address="${jboss.default.multicast.address:230.0.0.4}"
    multicast-port="45688"/>
<socket-binding name="jgroups-udp-fd" port="54200"/>
<socket-binding name="modcluster" port="0"
    multicast-address="224.0.1.105"
    multicast-port="23364"/>
<socket-binding name="remoting" port="4447"/>
<socket-binding name="txn-recovery-environment" port="4712"/>
<socket-binding name="txn-status-manager" port="4713"/>
<outbound-socket-binding name="mail-smtp">
    <remote-destination host="localhost" port="25"/>
</outbound-socket-binding>  
<!-- -------------------------------------------------- -->

Bloque Profile del standalone de JBoss EAP

Uno de los apartados más importantes del standalone.xml del JBoss EAP es el denominado <profile>. Dentro de dicho apartado (perfil) aparecerá una colección de subsistemas, en función de los requisitos de nuestra aplicación. Cada uno de estos subsistemas viene proporcionado por las extensiones que previamente quedaron definidas en el bloque <extensions>. Estos subbloques sirven para configurar las capacidades y atributos de cada una de las extensiones del servidor JBoss. La configuración requerida por cada subsistema viene especificada en los ficheros ".xsd" que se encuentran en la siguiente carpeta:

JBOSS_HOME/docs/schema/

Hemos de tener en cuenta que, cuando se inicia una instancia JBoss, el servidor debe tener un perfil asociado. De este modo, cada subsistema que aparezca dentro del <profile> quedará a disposición del servidor que utilice dicho perfil. Puntualizar que en modo Standalone sólo tendremos un perfil disponible, mientras que en modo Dominio se podrán definir múltiples perfiles.

Los subsistemas que podemos encontrar en el bloque profile son los siguientes:

* logging: configuración de logs.

* datasources: se indican las conexiones que van a ser utilizadas para extraer la información de la Base de Datos que va a ser utilizada por nuestra aplicación. La configuración completa requerida se encuentra en el fichero jboss-as-datasources_1_2.xsd. 

* deployment-scanner: configuración de un scanner de implementación individual que nos permite escanear una ubicación en particular.

* ee: configuración de la extensión Java EE.

* ejb3: configuración de la extensión para EJB.

* infinispan: configuración del software Infinespan (plataforma de almacenamiento de datos no-SQL y de gestión de Caché distribuida).

* jaxrs: configuración de JAX-RS (Java API para Webservices RESTful).

* jca: configuración de Java EE Connector Arquitecture. Sirve para proporcionar una configuración general de los adaptadores de recursos.

* jdr: configuración del JBoss Diagnostic Reporter.

* jgroups: configuración de JGroups.

* jmx: configuración de JMX (Java Management Extensions).

* jpa: configuración de la extensión para JPA.

* jsf: configuración de la extensión para JSF.

* mail: configuración de mails.

* naming: configuración de servicios de nombrado (JNDI).

* remoting: configuración de los conectores remotos.

* resource-adapters: configuración de adaptadores de recursos.

* sar: configuración para la implementación de archivos sar (MBeans).

* security-manager: configuración del gestor de seguridad.

* threads: configuración del gestor de grupos de procesos y recursos. Este subsistema está obsoleto a partir de la versión 7 de JBoss EAP.

* transactions: configuración de las transacciones

* web: configuración del contenedor Web común de JBoss. Este subsistema está obsoleto a partir de la versión 7 de JBoss EAP.

* webservices: configuración de la extensión para Webservices.

* weld: configuración de Weld, que es la implementación de referencia de CDI (que, a su vez, es una API para Contextos, inyección de Dependencias y gestión de Beans).
 

👉 Un ejemplo de configuración de <datasources> dentro del <profile> sería el siguiente:

<!-- Configuracion de datasources de JBoss -->
<subsystem xmlns="urn:jboss:domain:datasources:1.2">
    <datatasource jta="true" jndi-name="java:/jdbc/A9Transaction"
        pool-name="A9Transaction" enabled="true" use-java-context="true"
        use-ccm="true">
        <connection-url>jdbc:db2://127.0.0.1:50000/DB2K</connection-url>
        <driver-class>com.ibm.db2.jcc.DB2Driver</driver-class>
        <driver>db2</driver>
        <security>
            <user-name>USERRA00</user-name>
            <password>PASSH466</password>
        </security>
        <validation>
            <validate-on-match>false</validate-on-match>
            <background-validation>false</background-validation>
        </validation>
        <timeout>
            <set-tx-query-timeout>false</set-tx-query-timeout>
            <blocking-timeout-millis>0</blocking-timeout-millis>
            <idle-timeout-minutes>0</idle-timeout-minutes>
            <query-timeout>0</query-timeout>
            <use-try-lock>0</use-try-lock>
            <allocation-retry>0</allocation-retry>
            <allocation-retry-wait-millis>0</allocation-retry-wait-millis>
        </timeout>
        <statement>
            <share-prepared-statements>false</share-prepared-statements>
        </statement>
    </datasource>
</subsystem>  
<!-- -------------------------------------------------- -->

Bloque Interfaces del standalone de JBoss EAP

En este bloque <interfaces> se realiza la configuración de las interfaces de red disponibles para su utilización en el servidor. Una interfaz es un nombre lógico (para una interfaz de red, una dirección IP o un nombre de Host) al que se podrá enlazar un socket determinado.

La instalación por defecto viene configurada con tres tipos de interfaces, pero adicionalmente se podrán definir todas las interfaces requeridas con el nombre lógico que deseemos. Los nombres lógicos de las interfaces por defecto son los siguientes:

* management: Interface de gestión.

* public: Interface pública.

* unsecure: Interface no segura.

 

👉 Un ejemplo de configuración de <interface> dentro del <interfaces> sería el siguiente:

 

<!-- Configuracion de interface de JBoss -->
<interface name="management">
    <inet-address value="${jboss.bind.address.management:127.0.0.1}"/>
</interface>

 

En principio, con lo que hemos visto hoy ya deberíamos tener una visión global de los apartados que componen el fichero de configuración standalone.xml del servidor JBoss EAP. Obviamente, las posibilidades de adaptación son casi ilimitadas, pero sería muy complicado ampliar el detalle en un post general como este. Quedémonos con la idea de que el fichero standalone nos permitirá configurar aquellas capacidades específicas que sean requeridas por nuestra aplicación. Ya en futuros posts trataremos de ir viendo ejemplos concretos de cómo se podrían configurar cada uno de los subbloques de este fichero.

Pues nada, eso es todo por hoy. Espero que el post haya servido para resolver alguna de las dudas que tuviéseis en relación con el standalone del JBoss EAP. Al menos, que os quede la idea de cómo podría ser una configuración básica de este fichero. Por supuesto, cualquier duda al respecto podéis dejármela aquí abajo...

Saludos.