Hace tiempo escribí una entrada sobre la posibilidad de utilizar XMPP como elemento para SOA (service oriented arquitecture, arquitectura orientada al servicio), hoy vuelvo de nuevo con la idea y amplio un poco más gracias a este artículo (en inglés) que me ha llamado la atención sobre el hecho, ya no solo como sistema SOA, sino también como ESB (enterprise service bus, bús de servicio empresarial), para mantener comunicación entre todos los recursos de un sistema de la información.
La primera versión de la especificación de SOA permanecía a la espera de eventos. La comunicación era unidireccional y el modelo completamente cliente-servidor, con lo que el sistema servidor no podía comenzar la conversación debido al diseño. La nueva versión SOA 2.0 agrega comunicación bidireccional. Este nuevo diseño permite una mayor eficiencia en comunicaciones en tiempo real y una nueva variedad de servicios que con SOAP o REST no estaban disponibles. Por ello, esta versión recibe el sobrenombre de event-driven SOA (SOA dirigida por eventos).
En la definición que nos da la wikipedia sobre SOA 2.0 apreciamos que se toma como un sistema al que se le agregan disparadores. Es decir, eventos que se pueden disparar por acciones o por tiempo. Lo más clarificador que ofrece el artículo de la wikipedia son los ejemplos. El ejemplo del defecto a ingeniería, especifica un caso en el que recibiendo llamadas normales se pueda identificar un defecto en un producto y lanzar una alerta a ingeniería o producción avisando del posible defecto.
Al constituir un ESB para SOA 2.0 el protocolo HTTP se queda insuficiente para cumplir con el requisito de la bidireccionalidad. Aunque cabría la posibilidad de habilitar en cada elemento del ESB un servidor y un cliente, o un sistema de websocket, ya sería dificultar la capa del protocolo de transporte. Por ello es que se reemplaza por XMPP. El protocolo XMPP requiere de la figura de un servidor central que se encargue de mantener las conexiones TCP abiertas y enrutar paquetes XML (stanzas) entre los distintos elementos conectados (clientes, bots, componentes y otros servidores) pero ya tiene implícitas ciertas características de las que HTTP carece:
Considero que el uso de XMPP para redes internas e incluso de BOSH para conexiones desde dispositivos móviles es la opción más acertada para el montaje de una arquitectura SOA, atrás queda la arquitectura LAMP a la que para optimizarse debían de agregarse otros elementos más a la fórmula y aún así se quedaba corta en muchos aspectos y finalmente algo difícil de mantener.
Una arquitectura SOA 2.0 deja a la infraestructura muchos elementos que antes había que programarse uno mismo o integrar otro elemento que no era simple de integrar en el sistema que se pretendía desarrollar.