Hablar XMPP desde Java: la librería Smack y la mensajería que sigue viva
Para enviar y recibir mensajes XMPP desde Java se usa Smack, la librería abierta de Ignite Realtime: se configura una conexión con dominio y credenciales, se abre la sesión y se mandan stanzas. Veinte líneas bastan para hablar con cualquier servidor federado.
La respuesta corta: Smack sigue siendo la vía estándar para hablar XMPP desde Java. La librería, mantenida por Ignite Realtime y documentada en su página de proyecto, expone la conexión como un objeto XMPPTCPConnection y los mensajes como stanzas. Para una empresa que no quiere atarse a la API propietaria de un proveedor de mensajería, el trato es sencillo: un protocolo abierto, servidores que se pueden hospedar en casa y un cliente Java que compila con el mismo JDK de siempre.
¿Qué es XMPP y por qué sigue usándose en sistemas empresariales?
XMPP (Extensible Messaging and Presence Protocol) es un estándar abierto de mensajería basado en un flujo XML persistente. Nació como Jabber en 1999, llegó al IETF en 2002 y quedó fijado como estándar en los RFC de 2004; la referencia normativa actual es el RFC 6120, que define el núcleo del protocolo. A diferencia de una API cerrada, cualquier servidor XMPP habla con cualquier otro: la federación funciona como el correo electrónico, donde cada dominio controla sus cuentas y se entiende con los demás. Por eso sobrevive en mensajería interna, alertas entre sistemas y dispositivos conectados, allí donde depender de un tercero es un riesgo de diseño. Los lectores que quieran el detalle de stanzas, JID y sesiones lo encuentran, en inglés, en la guía editorial que documenta el protocolo XMPP desde los textos de referencia.
¿Cómo se conecta un cliente Java a un servidor XMPP?
La conexión se describe con un XMPPTCPConnectionConfiguration: dominio del servidor, usuario y contraseña, y opciones de seguridad. Con eso se instancia la conexión, se llama a connect() y después a login():
XMPPTCPConnectionConfiguration config =
XMPPTCPConnectionConfiguration.builder()
.setUsernameAndPassword("alertas", "secreto")
.setXmppDomain("jabber.empresa.local")
.build();
AbstractXMPPConnection conexion = new XMPPTCPConnection(config);
conexion.connect();
conexion.login();
ChatManager chatManager = ChatManager.getInstanceFor(conexion);
Chat chat = chatManager.chatWith(
JidCreate.entityBareFrom("guardia@jabber.empresa.local"));
chat.send("La tablespace USERS ha llegado al 90 por ciento");
conexion.disconnect();El patrón se parece al de una conexión JDBC: un objeto de configuración, una sesión que hay que cerrar y operaciones que viajan por esa sesión. La diferencia está en lo que circula: no son sentencias SQL sino stanzas XML. Smack se integra con Maven o Gradle como una dependencia más, y funciona igual contra un servidor de empresa (ejabberd, Prosody, Openfire) que contra un servidor público federado.
¿Qué forma tienen las direcciones y los mensajes en la red?
Cada cuenta se identifica con un JID (Jabber ID) de la forma usuario@dominio/recurso: el recurso permite tener varias sesiones del mismo usuario, un portátil y un móvil, por ejemplo. Lo que viaja por la conexión son stanzas, los tres tipos básicos del protocolo: message para el envío de mensajes, presence para el estado (disponible, ausente, ocupado) y iq (info/query) para peticiones y respuestas tipo llamada. Un mensaje real es XML con esa pinta:
<message to="guardia@jabber.empresa.local/movil"
type="chat">
<body>La tablespace USERS ha llegado al 90 por ciento</body>
</message>Smack oculta casi todo ese XML tras objetos Java, pero conocer su forma ayuda cuando una sesión se queda en blanco y toca mirar el tráfico.
Dónde encaja en una arquitectura Java
El caso de uso habitual no es un chat de personas sino una notificación: un proceso batch que avisa al terminar, un monitor que alerta de un ORA, un servicio que recibe órdenes por mensajería. En ese papel, XMPP ofrece entrega confirmada, presencia y federación sin licencia por asiento, y Smack ofrece el cliente en el lenguaje que ya corre el resto del sistema. Para quien viene del puente entre lenguajes, la idea recuerda al paso de variables de Java a JavaScript: dos mundos que hablan un formato común y neutro.
La mensajería abierta no ha muerto: se ha quedado donde la API cerrada no llega, y desde Java sigue estando a una dependencia de distancia.