human-329851_640

Me llega una consulta que creo muy interesante. Me preguntan si, en mi opinión, en determinadas ocasiones se puede prescindir del ESB y directamente invocar desde el cliente al servicio directamente.

Pues bien, aunque no estoy de acuerdo con las razones que se exponían en esta consulta para no pasar por el ESB, creo que sí que hay otras en las que puede estar justificado.

Lo primero que hay que decir es que el bus de servicios es realmente un patrón de diseño, no un producto. Por supuesto, en la gran mayoría de los casos, este patrón está implementado por un middleware del estilo del que proporciona IBM, Oracle, etc.

El ESB tiene un coste en términos de rendimiento

Evidentemente, siempre que ponemos una pieza en medio, por un muy optimizada que esta sea, tendremos una penalización en el rendimiento. Al menos, el bus tendrá que recibir una petición HTTP (o con otro protocolo) y seguramente volver a invocar a un servicio. Es lo que coloquialmente se conoce como “dar un salto”. Por supuesto, esto se puede complicar aún más.

El caso más palmario es el del tratamiento de ficheros anexados pesados. Aunque vayan en binario en un protocolo como MTOM dentro de los servicios SOAP tendríamos que “subir” los ficheros al ESB, y después volver a subirlos al backend. Es decir, tenemos una merma del rendimiento que puede ser más o menos importante. ¿Por qué no evitar este paso intermedio (este “salto”) si podemos?.

¿Por qué usar un Bus?

Ya conocemos las bondades del Bus (si quieres repasarlas podéis hacerlo aquí). Precisamente en este blog he defendido el uso del Bus por múltiples razones. Sin embargo, no siempre es todo blanco o negro y me explico.

El caso es que un ESB sirve básicamente para transformar el protocolo, el formato del mensaje, cambia el método de autenticación, etc. etc. Ahora bien, ¿que pasa si tienes un backend que ya expone, digamos un servicio SOAP? y resulta el que el cliente que tengas puede consumir perfectamente este servicio SOAP (que serán la mayoría).

En este caso, no es necesario cambiar el protocolo (ya es SOAP), ni transformar el mensaje (como añadir o quitar parámetros), ni cambiar la seguridad, etc. etc. entonces, en este caso, quizás no aporte mucho poner un ESB por el medio.

Bajo ciertas condiciones

Claro que esto de acceder directamente lo hay que hacer bajo ciertas reglas:

  • En primer lugar, el servicio al que llamamos no es un servicio compuesto. Es decir, es lo que se llama un servicio de backend (sólo invoca a un backend no a dos o a tres).
  • El backend lo expone directamente en un modo estándar (como SOAP o REST)… si seguimos los principios de SOA, nos faltaría el de desacoplamiento… por lo tanto, se tendría que usar un registry de servicios de donde el cliente sacaría el endpoint del servicio de backend… con esto evitamos que haya una integración punto a punto.

Si el día de mañana, hay que hacer por ejemplo una composición manteniendo el contrato de ese servicio, entonces sí que se podría implementar en el ESB, y se cambiará el endpoint del registry y los clientes no se darían cuenta (siempre claro que no cambie el contrato del servicio).

Anuncios