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.
¿Dónde entra XMPP en todo esto?
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:
- Encolado: en XMPP y la mayoría de servidores podemos encontrar sistemas de encolado para clientes (módulos de offline) que nos almacenan el mensaje cuando no estamos presentes.
- Alta disponibilidad: configurando los clientes con prioridades distintas, uno puede quedar conectado y a la espera de recibir un mensaje, mientras quien tiene la prioridad más alta los recibe y procesa. En caso de que cayese, el servidor envía todos los mensajes al usuario conectado que tenga la prioridad más alta.
- Balanceo: empleando componentes y ciertas versiones de servidores, cabe la posibilidad de no solo tener alta disponibilidad sino también balanceo de carga entre todos los componentes enlazados a un dominio específico.
- Seguridad: la comunicación puede ir sobre TLS y se realiza autenticación a cada elemento que se conecta a los servidores. Aunque esto es algo que se puede conseguir igualmente con HTTP, viene bien remarcar su existencia.
- Asincronía: los mensajes se envían y se pueden seguir enviando de forma paralela más mensajes. No hay bloqueo con respecto a ninguno de los componentes por lo que la existencia de interbloqueos a nivel de protocolo es inexistente.
- Presencia: se puede conocer en cada momento si el dispositivo con el que se quiere comunicar está o no activo e incluso a través de una suscripción de presencia, que nos informe del momento en el que deja de estar operativo.
- Difusión: a través de mecanismos como pub/sub, XMPP nos permite realizar multi-difusión de mensajes a todos los dispositivos suscritos. Esto facilita el envío de mensajes masivos ya que no hay que mantener un control de suscripción en cada elemento y enviar uno por uno cada mensaje sino que se envía a una única lista y la lista se encarga de realizar el trabajo pesado.
Conclusiones
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.
