La pregunta del título de esta entrada puede resultar un poco curiosa. No quiero referirme a que en una arquitectura SOA, al menos una que de soporte a un gran número de servicios, deba o no tener un ESB. En mi anterior entrada llegaba a la conclusión de que sí era necesario si queríamos evitar un escenario del tipo espagueti web services en SOA.

Las ventajas que proporciona el uso de un ESB son varias, algunas de ellas serían estas:

  1. Enrutado basado en contenido. Es posible en función de uno o varios parámetros de entrada invocar a una lógica u otra.
  2. Transformación de mensajes. Es posible que la lógica de negocio a la que hay que invocar en última instancia necesite cierto tipo de parámetros especiales que no queremos exponer al cliente. También es posible que esta lógica se tenga que invocar bajo otro protocolo (por ejemplo una transaccion CICS en el HOST o mediante un mensaje RMI/IIOP si invocamos a un EJB). Mediante esta mediación es posible proporcionar al cliente un interfaz limpio (con los tipos de parámetros estándar) y con un protocolo amplicamente adoptado (SOAP sobre HTTP)
  3. Configuración y no programación. Normalemente los ESB se acompañan de herramientas de desarrollo que hacen énfasis en reducir lo máximo posible la codificación. En su lugar, proporcionan un entorno visual en el que las tareas o acciones a realizar (como una transformación de parámetros) se representan con cajas unidas por flechas que indican el flujo de los datos.
  4. Capa de abstracción de servicios. Esta característica hace referencia a la ventaja que otorga el hecho de tener una capa intermedia que te oculte el el servicio final. Por ejemplo es posible que este servicio tenga un grano demasiado fino para ser consumido por un cliente (por ejemplo una pantalla). Con esta a capa es posible modificar o adaptar este servicio de manera que sea realmente útil y sea “usable” por el cliente
  5. Auditorias y logs. Con el uso de un ESB, todas las invocaciones a las lógicas de negocio pasan por un sólo sitio. Por lo tanto es posible implantar una herramienta de monitorización y/o establecer un componente que escriba logs o trazas. De esta manera podremos saber a qué servicios se está llamando, quién lo hace y con qué frecuencia.
  6. Control de errores. Cada backend tendrá su propia manera de representar un error. Con la capa ESB de integración es posible tener un punto centralizado donde gestionar estos errores y además proporcionar al cliente un interfaz único de estos errores (mediante la transformación del error que viene del backend).
  7. Securización. Podemos establecer un modo de securización común y homogéneo para los diferentes backends que pueden tener una securización muy diferente.
  8. Registro de servicios. Acompañado del uso de ESB se tiene un registro de servicios (UDDI). Este registro contendrá el descriptor de despliegue del mismo (WSDL) y sobre todo el endpoint o punto de acceso del servicio (la URL donde hay que invocar el mismo). Con esto logramos independizar la localización física de la máquina donde se ejecuta el servicio (podremos cambiarlo sin que el cliente se entere).
  9. Validación, enriquecimiento. El ESB proporciona API y funcionalidades de validación de los mensajes (comprueba que los parámetros de entrada son correctos) y también puede enriquecer el mensaje. Por ejemplo, si la lógica necesita tres parámetros y uno de ellos es la fecha del sistema, se puede exponer un servicio al cliente con solo dos parámetros y este tercero se añadirá en el ESB antes de ejecutar la lógica. Con esto, podemos exponer servicios más simples y por lo tanto más fáciles de usar al cliente.

Como se ve todas estas ventajas son lo suficientemente importantes para justificar el uso de un ESB, sin embargo, puede haber situaciones en las que estas ventajas no resultan tan evidentes. Pongámonos en el siguiente escenario:

  1. Tenemos un backend que proporciona una lógica de negocio en formato web services y tenemos un frontend (una aplicación web con interfaz de usuario) que puede consumir este servicio.
  2. No es necesario enrutado, ni transformación ni enriquecimiento del mensaje. Tampoco es necesario una configuración especial de seguridad.
  3. Tampoco es necesaria ninguna composición ni integración de lógicas, es decir, el servico se consume tal cual sin combinarlo con ningún otro.

¿tiene sentido asumir el coste de desarrollo y despliegue de una mediación en el ESB? ¿tiene sentido asumir el coste de rendimiento de poner una capa intermedia entre el cliente y el proveedor del servicio?

Con todo lo dicho anteriormente, mi opinión personal es que sí, sí merece la pena tener un ESB aún en este caso tan extremo. Entre otras razones por lo siguiente:

  1. Perdemos la monitorización y control de acceso. Al no tener un ESB no podremos tener monitorizacion centralizada ni podremos saber quien llama a qué servicio, con qué frecuencia y con qué disponibilidad. Al no tener un endpoint común, como único punto de acceso (el del ESB), tendría os que delegar esto a cada lógica de negocio. En el caso de que lo haga, seguramente estos datos de acceso tendrán información y formato heterógeneo e imposibilitarán el poder tener informes integrados
  2. ¿sin logica de integración o composición? Si la adopción de SOA va medianamente bien a medio plazo el uso de lógicas puras o simples por parte de los clientes no se producirá. Precisamente una de las cosas que promete SOA es que en un futuro medianamente próximo no se programarán servicios sino que se compondrán. Es decir, que todos los servicios de negocio expuestos a los consumidores serán servicios compuestos. Y por lo tanto sera necesaria al menos una mínima lógica de integración. Y el mejor sitio para hacer esto es el ESB sin duda.
  3. n elevado a m conexiones. Sin ESB, en el caso que tengamos n diferentes clientes, por ejemplo una aplicación web Java, un batch y una aplicación Visual Basic, y m backend, tendremos que hacer n elevado a m conexiones. Esto es, para tres diferentes tipos de clientes y tres tipos de backend, 27 conectores (tienen que poder hablar todos con todos).

    ESB
    Con el uso de un ESB únicamente hará falta n x m conexiones, esto es 9 en total. Esto es así porque cada cliente y cada backend únicamente tiene que saber hablar con el ESB.

En conclusión: ¿ESB en SOA? Sí, gracias

Anuncios