Un poquito decepcionado con los ESB

esb image  Hace tiempo que oí hablar de los Enterprise Service Bus (ESB) y con ellos he estado jugueteando por mi cuenta algún tiempo, leyendo e informándome en general, hasta que ha llegado la posibilidad de aplicarlo en un proyecto real.

En mi proyecto real, antes de tomar la decisión de si meter o no ESB y cual de ellos meter, decidí hacer algunas pruebas más en serio con los casos concretos que me iba a encontrar.

El primer punto son sockets TCP/IP con protocolo propio, es decir, mensajes binarios con su propia cabecera y forma de delimitar los mensajes dentro del flujo de bytes que es un socket TCP/IP. Mi primera opción de ESB, por supuesto, los gratis y más conocidos, en concreto, Apache Servicemix, Así que con él voy a hacer la prueba. Lo primero, es que si el protocolo es binario y no un simple protocolo de texto delimitado por retornos de carro, te tienes que hacer una clase java que sea capaz de hacer este trabajo por Apache Servicemix. De acuerdo, me puse a ello y conseguí hacerla…. pero me costó un buen rato de investigación. La documentación es escasa y en ningún sitio pone cómo hacerlo. Al final rebuscando por los ejemplos y fuentes del propio Apache Servicemix encontré cómo hacerlo. Esa ha sido mi primera pega/decepción con este ESB, la documentación es bastante pobre.

Y una vez conseguido, me pongo a probar y me encuentro una segunda pega. Un ESB implementa los Enterprise Integration Patterns (EIP), Y en ellos, hay dos posibles flujos de mensajes: En los que uno sólo envía y el otro sólo recibe, es decir, una única dirección, o bien los petición/respuesta, es decir, uno pide y el otro responde, por cada mensaje de ida debe haber uno de vuelta. Y eso a mí no me vale, en mi proyecto necesito que cualquiera de los dos lados, de modo espontáneo, puedan enviar o recibir, sin necesidad de haber enviado o recibido previamente una petición.

Bien, podría convivir con eso y seguramente encontraría algún tipo de solución.

Y se me ocurre probar lo que en EIP se llama controlbus, es decir, la posibilidad de parar y re-arrancar un flujo de datos a voluntad. Pues bien, Apache Servicemix lo soporta, da métodos start y stop para parar definitivamente el canal y pause/resume para pararlo temporalmente. Casualmente, con el componente camel-netty (que es el que nos proporciona socket TCP/IP), no funciona el suspend/resume. 🙁

Y finalmente, decido hacer otra prueba que también necesito, socket multicast. Pues bien, aunque teóricamente están soportados por Apache Servicemix, no es cierto, símplemente no funcionan. Hay dos componentes que nos pueden dar esta funcionalidad: camel-mina y camel-netty. Camel-Mina directamente dice que no lo soporta. Camel-netty sí, pero si lo pones, salta una excepción de "bind" y no funciona. Y no, no es que el puerto ya esté ocupado. Te pones a rebuscar en el código de camel-netty y ves que el test de JUnit que verifica el multicast directamente está deshabilitado. Y si lo habilitas, falla.

Así que decido pasar de Apache Servicemix, ya que me está dando demasiados problemas: falta de documentación para tus propios desarrollos, no funcina multicast… 

Y me busco otro ESB gratis, voy por jboss-fuse, y lo descarto casi inmediatamente. Tanto Apache Servicemix como JBoss Fuse se basan por debajo en la librería apache camel y la documentación de jboss es casi una copia de la de Servicemix. Así que mismos problemas … con uno añadido. Una de las cosas que aporta Jboss fuse en un eclipse "tuneado" para Jboss fuse, que permite definir gráficamente las rutas que quieres crear en el ESB… y que falla más que una escopeta de feria al menos con el componente camel-netty. Pongo el componente gráfico, relleno los formularios que salen …. y en el xml por debajo me genera mal la URL del punto de conexión. La arreglo a mano, y en cuento me descuido, me la vuelve a estropear.

Así que voy por otro ESB. El siguiente en la lista es Mule ESB. Este está mucho más guay, mucho mejor documentado, mis pruebas fueron bien a la primera, sin demasiada complicación …. pero me da la impresión de que es un ESB de pago. Creo que  me he bajado el trial de 30 días….

Con todo esto, ya casi he desistido de poner un ESB en el proyecto. Voy a darle un vistazo a wso2, que tiene muy buena pinta, la documentación parece buena y tiene pinta de ser gratis. A ver qué tal.

He visto por encima otros como OpenESB, Talend, y Synapse, pero son quizás menos conocidos y en todos ellos, mirando por encima la documentación, he visto alguna cosilla que no me acaba de convencer.

Estoy seguro que los ESB funcionan bien, ya que son bastante conocidos y aparentemente muy usados. Pero me da la impresión de que funcionan muy bien si te atienes a los protocolos para los que están pensados, en concreto y sobre todo, Web Services, JMS, HTTP, FTP, etc.

Esta entrada ha sido publicada en Herramientas y etiquetada como , , , , , . Guarda el enlace permanente.

2 respuestas a Un poquito decepcionado con los ESB

  1. Jose Manuel Prieto dijo:

    Buenas,

    Yo he trabajado con WSO2. Creando un servicio web con CXF y la capa de seguridad la aportaba WSO2. La ventaja con respecto a MuleESB, es que en MuleESB te obliga a desarrollar con sus librerias y es de pago.
    SpringFramework, tiene una pequeña libreria para estos menesteres: Spring Integration.
    He visto en algunos casos que el uso de los ESB, es porque es la moda.
    Usar un ESB deberia estar supeditado a que tengas varios protocolos y necesites hacerlos converger en otros. De sockets a WebServices, de xml a json. Hay protocolos mas antiguos…

  2. GreenEyed dijo:

    Yo también me he mirado los afamados ESB dos veces y en ambas decidí que no merecía la pena tanta complicación. A no ser que realmente los necesites, me parecieron una camisa de fuerza y encima incomoda de narices.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.